Tema IV Diseño.
La fase de diseño permite modelar al sistema y encontar su forma (incluida su arquitectura) acorde a la tecnología de
implantación. Se incorporan los requisitos funcionales, no funcionales.
La entrada al diseño es el modelo de análisis, resultado de la comprensión detallada de los requisitos.
El diseño tiene como propósito:
+ Dar una compresión a profundidad de los requisitos no funcionales y restricciones relacionadas con las tecnologías de
sofware utilizada
+ Dar el punto de partida a las actividades de implementación
+ Permite descomponer los trabajos de implementación para asignarlos a distintos equipos de desarrollo.
Las características del modelo de diseño son:
+ Modelo físico, es un plano o mapa de la implementación
+ No genérico, específico a una implementación
+El tipo de clases o estereotipos puede ser cualquiera
+ Es mas formal que el análisis
+ Centrado en el modelo dinámico, por medio de diagramas de secuencia
+ Debe mantenerse en todo el ciclo de vida del software
+ Da forma al sistema y preserva la estructura definida por el modelo de análisis
El Proceso Unificado de Desarrollo de Software (PUDS) indica una serie de artefactos, trabajadores y flujos para aplicar la
fase de diseño.
El punto importante es que el diseño se puede dividir en dos subfases, el diseño de sistemas y el diseño de objetos.
En el diseño de sistemas se definen los objetivos de diseño del proyecto, la filosofía central, se seleccionan estrategias
para construir el sistema, plataforma de hardware y software, arquitectura de almacenamiento de datos. Al final se obtiene
un arquitectura con los componentes de hardware y software
En el diseño de objetos se da una descripción detallada del modelo de objetos, tanto en el aspecto estático y dinámico;
dejando un detalle fino sobre como construir la implantación.
4.1 Arquitectura.
Una arquitectura es el mas alto nivel de concepto de un sistema en su medio ambiente.
La arquitectura de un sistema de software (en un punto del tiempo) es su organización o estructura de componentes significativos
que interactuan por medio de interfases, dichos componentes están compuestos de pequeños componentes e interfaces.
Una arquitectura de software incluye la descomposición del sistema,
el flujo de control global, las políticas de manejo de errores
y los protocolos de comunicación entre subsistemas
Es un estructura organizacional de un sistema
Una arquitectura puede ser descompuesta recursivamente en partes que
interactuan por interfaces, relaciones que conectan partes y
restricciones para ensamblar las partes. Las partes que interactuan por interfases incluyen clases, componentes y subsistemas
Entonces, la función del diseño de sistemas es elegir la arquitectura que aplique al problema que se requiere solucionar.
4.1.1 Acoplamiento y cohesión
Acoplamiento. Un sistema está acoplado a otro sistema cuando
existe una dependencia entre ambos.
En otra perspectiva, el acoplamiento mide el efecto de un cambio
en un módulo, como se refleja en los módulos relacionados.
Acoplamiento fuerte, es cuando un cambio en un modulo implica
un esfuerzo grande en los módulos relacionados.
Acoplamiento debil, es cuando un cambio en un modulo implica
un esfuerzo mínimo en los módulos relacionados.
Lo recomendable es tener un conjunto de módulos debilmente acoplados.
Cuando los desarrolladores se "atan" al cómo de los modulos
de software, el acoplamiento se fortalece.
Para debilitar el acoplamiento, se debe recurrir a tecnicas
de encapsulamiento, herencia, polimorfismo y diseño por interfases.
Cohesión. En una estructura de módulos, la cohesión es el
grado de comunicación que hay entre elementos del módulo. Esto
es, se debe procurar relacionar todos los objetos de un mismo
módulo o paquete.
Una cohesión baja, es cuando los objetos de un paquete o módulo
no tienen nada que ver entre sí.
Una cohesión alta, es cuando los objetos de un paquete o módulo
están completamente relacionados.
En resumen, para poder lograr un sistema bien diseñado, la
cohesion debe ser alta y el acoplamiento debe ser debil.
Con una cohesión alta se lograr independizar un módulo de software
de otro, y con un acoplamiento débil, los módulos no se ven
afectados ante cambios en otros módulos relacionados
4.1.2 Clasificación de las arquitecturas.
Un sistema se puede diseñar bajo distintos tipos de arquitecturas.
Es factible que una persona invente su propia arquitectura, pero
lo recomendable es recurrir a arquitecturas ya existentes y probadas.
Se tiene la siguiente clasificación:
Arquitecturas de flujos de datos
+ Procesamiento secuencial o batch
+ Tuberías y filtros
Arquitecturas de repositorio
+ Bases de datos
+ Hipertexto
+ Pizarrón
Arquitecturas de componentes independientes
+ Sistemas cliente/servidor
+ Peer to Peer (P2P) o Par-A-Par
+ Procesamiento de comunicación paralela
+ Sistemas de eventos
Arquitectura de máquinas virtuales
+ Sistemas como interpretes de gramáticas
Arquitecturas en capas
4.2 Marcos de Aplicación.
Con la programación estructurada era normal encontrar un conjunto de librerias o bibliotecas de módulos que dan un conjunto
de funcionalidades que pueden incorporarse a varios tipos de programas. Los componentes de una librería son invocados por
los programas que los necesiten, es decir, los componentes solo son llamados por los programas
Con la filosofía orientada a objetos, se pueden seguir dando liberias (un ejemplo es todo el API de Java). Sin embargo
existe un concepto mas, que es el de marcos de aplicación o trabajo (frameworks)
Un marco de aplicación es una aplicación parcial reutilizable que puede
especializarse para producir aplicaciones personalizadas.
Otra definició elaborda es "Una microarquitectura que proporciona una plantilla
o molde incompleto para sistemas de un determinado
dominio (problema en particular).
Es decir, un conjunto de desarrolladores encapsulan en un módulo de software una serie de algoritmos para manipular un problema
general. Se dejan todos los métodos y/o clases gancho necesarias para que otro desarrollador incorpore módulos específicos para
resolver un problema aterrizado. La filosofía consiste en que el framework invoca a los componentes desarrollados por el
programador, el cual los incorpora usando mecanismos de reutilización y extensibilidad. Es decir, en lugar de que un programa
incorpore llamadas al framewok; el programador incorpora su módulo al framework y espera por ser llamado por los mecanismos del
framework.
En resumen, la fase de diseño debe orientarse a crear arquitecturas, incorporando patrones de diseño,librerias y frameworks para
lograr un sistema que sea flexible.
4.3 Artefactos.
4.3.1 Modelo de diseño.
Es un modelo de objetes que describe la realizcación de casos de uso
centrandose en los requisitos funcionales y no funcionales,
y sirve como una abstracción del model de implementación
Incorpora los siguientes artefactos: clase del diseño, Realización del caso de uso-diseño, interfaz y subsistema de diseño
Fig. 01
4.3.2 Clase del diseño.
Es una descripción de un conjunto de objetos que comparten las mismas responsabilidades, relaciones, operaciones, atributos y
semántica
Fig. 02
4.3.3 Realización del caso de uso-diseño.
Describe como un caso de uso en particular es realizado en el modelo de diseño, en términos de objetos que están colaborando
Fig. 03
4.3.4 Interfaz
Un elemento de modelado el cual define un conjunto de acciones o comportamiento (un conjunto de operaciones) ofrecidos por
una clase o subsistema de diseño. Una interfaz puede ser adoptada por varias clases o subsistemas de diseño
Fig. 04
4.3.5 Subsistema de diseño.
Un elemento que contiene a otros elementos de diseño, tales como clases o subsistemas de diseño.
Las acciones del sistema son provistas por las clases y subsistemas que contiene e implanta una o mas interfaces, de
las cuales toma el comportamiento a efectuar.
Fig. 05
4.3.6 Modelo de despliegue.
Es un modelo de objetos que describe la distribución física del sistema en términos de cómo se distribuye la funcionalidad
entre los nodos de cómputo.
Fig. 06
4.3.7 Descripción de la arquitectura.
Es la vista de la arquitectura del model de diseño. Permite visualizar la filosofía de diseño, y la organización de todos
los artefactos de diseño para lograr una coherencia e integración, acorde al modelo de análisis.
4.4 Trabajadores.
El arquitecto es responsable del modelo de diseño, que da una vision de la arquitectura de software; y del modelo de despliegue,
que da una vision de la arquitectura de hardware. En un documento, denominado, la descripción de la arquitectura, plasma
la filosofía de diseño
El ingeniero de casos de uso se encarga de dar seguimiento a los casos de uso, o requisitos, para cuidar que sean completamente
considerados en la fase de diseño
El ingeniero de componentes toma el modelo de análisis, generando clases de diseño, subsistemas de diseño e interfases para que
puedan cumplir con el compromiso de realizar los casos de uso.
Fig. 07
4.5 Flujo de trabajo
El diagrama de actividad es el siguiente:
Fig. 8
4.5.1 Diseño de la arquitectura
Como se comentaba al principio de este capítulo, esta actividad es conocida como el diseño de sistemas
Las actividades que se tienen que realizar para diseñar una arquitectura son las siguientes:
4.5.1.1 Establecer la correspondencia entre los subsistemas y los nodos de procesamiento
4.5.1.2 Descomposición o identficación de subsistemas
4.5.1.3 Identificar clases de diseño relevantes para la arquitectura
4.5.1.4 Aplicar patrones de diseño
Acerca de los patrones de diseño, ver la siguiente liga
4.5.2 Diseño de un caso de uso
4.5.3 Diseño de clases
En el Diseño de Objetos, la primera parte es obtener clases, relaciones e interfases
4.5.4 Diseño de subsistemas
Con el fin de separar el trabajo de los equipos de desarrolladores, siempre es necesario generar módulos o subsistemas
que agrupen distintos tipos de clases orientadas a resolver un segmento de funcionalidades del sistema