Arquitectura De Software

  • Uploaded by: snoopy_240
  • 0
  • 0
  • February 2021
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Arquitectura De Software as PDF for free.

More details

  • Words: 1,448
  • Pages: 25
Loading documents preview...
Arquitectura de Software

Introducción Arquitecturas de Software

Introducción  El diseño arquitectónico se interesa por entender cómo debe organizarse un sistema y cómo tiene que diseñarse la estructura global de ese sistema.  El diseño arquitectónico es la primera etapa en el proceso de diseño del software, identifica los principales componentes estructurales en un sistema y la relación entre ellos.

Introducción (Cont.)

Modelo abstracto de la arquitectura para un sistema de robot de empaquetado, que indica los componentes que tienen que desarrollarse.

Definición  La arquitectura de software es vista como la estructura del sistema en función de la definición de los componentes y sus interacciones.  Esta estructura se constituye de componentes -módulos o piezas de código que nacen de la noción de abstracción, cumpliendo funciones específicas, e interactuando entre sí con un comportamiento definido

Definición (Cont.) • • • •

La arquitectura es una abstracción del sistema. Los sistema pueden tener y tienen una estructura. Todo sistema tiene una arquitectura. Tener una arquitectura no es lo mismo que tener una arquitectura conocida por todos. • Si no se desarrolla la arquitectura explícitamente, se obtendrá una de todas formas, pero puede no gustarnos lo que obtenemos.

Definición (Cont.) Importancia  La descomposición arquitectónica es necesaria para estructurar y organizar la especificación.  Por lo tanto, como parte del proceso de ingeniería de requerimientos, se debe proponer una arquitectura de sistema abstracta donde se asocien grupos de funciones de sistemas o características con componentes o subsistemas a gran escala.  Puede usar esta descomposición para discutir los requerimientos y las características del sistema.

Definición (Cont.) 8

¿Por qué es importante la Arquitectura? •

Representa las decisiones de diseño más tempranas

• • •



Es el primer artefacto de diseño



Esencial para la reutilización sistemática





lo más difícil de cambiar lo más difícil de tener correcto vehículo de comunicación entre los interesados se ocupa de performance, modificabilidad, confiabilidad, seguridad transferible, abstracción reutilizable

Una buena arquitectura sienta las bases para un sistema exitoso Una mala arquitectura generalmente provoca alguna forma de desastre

Los Requisitos Determinan el Diseño

Conocimiento disponible

Variadas formas de requisitos

Host

Sistema

Cámara

Sensores

Sistema de Visión

Controlador

Arquitecto Arquitectura

Motores

Definición (Cont.) • Las arquitecturas de software se diseñan en dos niveles de abstracción: Arquitectura en pequeño se interesa por la arquitectura de programas individuales. En este nivel, uno se preocupa por la forma en que el programa individual se separa en componentes. Arquitectura en grande se interesa por la arquitectura de sistemas empresariales complejos que incluyen otros sistemas, programas y componentes de programa. Tales sistemas empresariales se distribuyen a través de diferentes computadoras, que diferentes compañías administran y poseen.

Definición (Cont.) • La arquitectura de software es importante porque afecta el desempeño y la potencia, así como la capacidad de distribución y mantenimiento de un sistema (Bosch, 2000). • Bass y sus colaboradores (2003) analizan tres ventajas de diseñar y documentar de manera explícita la arquitectura de software:

Definición (Cont.) 1. Comunicación con los participantes. Puede usarse como un enfoque para la discusión. 2. Análisis del sistema. En una etapa temprana en el desarrollo del sistema, aclarar la arquitectura del sistema requiere cierto análisis 3. Reutilización a gran escala. Un modelo de una arquitectura de sistema es una descripción corta y manejable de cómo se organiza un sistema y cómo inter operan sus componentes. Por lo general, la arquitectura del sistema es la misma para sistemas con requerimientos similares y, por lo tanto, puede soportar reutilización de software a gran escala.

Modelado • Las arquitecturas de sistemas se modelan con frecuencia usando diagramas de bloques simples. Cada recuadro en el diagrama representa un componente. Los recuadros dentro de recuadros indican que el componente se dividió en subcomponentes. Las flechas significan que los datos y/o señales de control pasan de un componente a otro en la dirección de las flecha

Modelado (Cont.) • Los diagramas de bloque presentan una imagen de alto nivel de la estructura del sistema e incluyen fácilmente a individuos de diferentes disciplinas que intervienen en el proceso de desarrollo del sistema. • Los diagramas de bloque son una forma adecuada para describir la arquitectura del sistema durante el proceso de diseño.

Decisiones en el diseño arquitectónico • El diseño arquitectónico es un proceso creativo en el cual se diseña una organización del sistema que cubrirá los requerimientos funcionales y no funcionales de éste. • Es útil pensar en el diseño arquitectónico como un conjunto de decisiones a tomar en vez de una secuencia de actividades.

Decisiones en el diseño arquitectónico (Cont.) • La arquitectura de un sistema de software puede basarse en un patrón o un estilo arquitectónico particular. • Un patrón arquitectónico es una descripción de una organización del sistema (Garlan y Shaw, 1993), tal como una organización cliente-servidor o una arquitectura por capas. • Es necesario elegir la estructura más adecuada, como cliente-servidor o estructura en capas, que le permita satisfacer los requerimientos del sistema.

Decisiones en el diseño arquitectónico (Cont.) Estructura en capas

• Se utiliza para dividir sistemas de software complicados.

Decisiones en el diseño arquitectónico (Cont.) 1. Capa de Presentación: Referente a la interacción entre el usuario y el software. Puede ser tan simple como un menú basado en líneas de comando o tan complejo como una aplicación basada en formas. Su principal responsabilidad es mostrar información al usuario, interpretar los comandos de este y realizar algunas validaciones simples de los datos ingresados.

Decisiones en el diseño arquitectónico (Cont.) 2. Capa de Reglas de Negocio (Empresarial): También denominada Lógica de Dominio, esta capa contiene la funcionalidad que implementa la aplicación. Involucra cálculos basados en la información dada por el usuario y datos almacenados y validaciones. Controla la ejecución de la capa de acceso a datos y servicios externos.

Decisiones en el diseño arquitectónico (Cont.) 3. Capa de Datos: Esta capa contiene la lógica de comunicación con otros sistemas que llevan a cabo tareas por la aplicación. Estos pueden ser monitores transaccionales, otras aplicaciones, sistemas de mensajerías, etc. Para el caso de aplicaciones empresariales, generalmente esta representado por una base de datos, que es responsable por el almacenamiento persistente de información.

Decisiones en el diseño arquitectónico (Cont.) Cliente-servidor

• Patrón arquitectónico para el desarrollo de sistemas distribuidos. • Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. • Cliente (parte activa) • Demanda servicios a los servidores • Se asume que cada petición deberá obtener respuesta • Diseñado para soportar la interacción con el usuario final.

• Servidor (parte pasiva) • Espera las peticiones de los clientes • Procesa esas peticiones y envía una respuesta • Diseño orientado a maximizar la eficiencia.

Decisiones en el diseño arquitectónico (Cont.) • Debido a la estrecha relación entre los requerimientos no funcionales y la arquitectura de software, el estilo y la estructura arquitectónicos particulares que se elijan para un sistema dependerán de los requerimientos de sistema no funcionales: 1. Rendimiento: Si el rendimiento es un requerimiento crítico, la arquitectura debe diseñarse para localizar operaciones críticas dentro de un pequeño número de componentes, con todos estos componentes desplegados en la misma computadora en vez de distribuirlos por la red.

Decisiones en el diseño arquitectónico (Cont.) 2. Seguridad: Si la seguridad es un requerimiento crítico, será necesario usar una estructura en capas para la arquitectura con un alto nivel de validación de seguridad aplicado a dichas capas. 3. Protección: la arquitectura debe diseñarse de modo que las operaciones relacionadas con la protección se ubiquen en algún componente individual o en un pequeño número de componentes. Esto reduce los costos y problemas de validación de la protección, y hace posible ofrecer sistemas de protección relacionados que, en caso de falla, desactiven con seguridad el sistema.

Decisiones en el diseño arquitectónico (Cont.) 4. Disponibilidad: la arquitectura tiene que diseñarse para incluir componentes redundantes de manera que sea posible sustituir y actualizar componentes sin detener el sistema. 5. Mantenibilidad: la arquitectura del sistema debe diseñarse usando componentes autocontenidos de grano fino que puedan cambiarse con facilidad. Los productores de datos tienen que separarse delos consumidores y hay que evitar compartir las estructuras de datos.

Ejercicios 1. Cuando se describe un sistema, explique por qué es posible que deba diseñar la arquitectura del sistema antes de completar la especificación de requerimientos. 2. Se le pide preparar y entregar una presentación a un administrador no técnico para justificarla contratación de un arquitecto de sistemas para un nuevo proyecto. Escriba una lista que establezca los puntos clave de su presentación. Por supuesto, debe explicar qué se entiende por arquitecto de sistemas. Mínimo una cuartilla por cada ejercicio, anexa ambos documentos a tu Portafolio de evidencias.

Related Documents