![Page 1: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/1.jpg)
1
Diseño de Software basado en Patrones
Métodos de Diseño
César Julio Bustacara Medina
Facultad de Ingeniería Pontificia Universidad Javeriana
![Page 2: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/2.jpg)
Meta-Modelos
• Se provee un meta-modelo que es una abstracción de varias técnicas de diseño arquitectónico.
• Este modelo será usado para analizar y comparar las técnicas actuales de diseño.
![Page 3: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/3.jpg)
Architecture Qualities
Process
Architecture
Representation
The “what” The “why”
The “how” The “who”
System
Features
Architecture S/W Requirements
System
Quality Attributes
Satisfies
Constrain
Organization
Architect
Skills
Stakeholders
Defines role
Produces
Follows
Defines Technology
Meta-Modelos
![Page 4: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/4.jpg)
Meta-Modelos Software
Architecture
Software
Architecture
Description
Architectural
view
is made of
is represented by
Architecture
Design Process
produces
Form
Component
Connection
Architectural
Pattern
is a
is made of
Software
Architects
are actors in
Logical view
Process
view
Implemen-
tation view
Deployment
view
Requirements
satisfies
Architectural sty le
has
has
has
is a
Sy stem
architecture
is part
of
Architecture
Style guide
Constraints
constrains
constrains
Use case
view
relates to
Architectural
Blueprint
depicts
![Page 5: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/5.jpg)
Meta-Modelos
Adaptado de P. Kruchten, B. Selic, W. Kozaczynski. “Describing Software Architecture with UML”, 2001
![Page 6: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/6.jpg)
Cliente Conocimiento
del Dominio
Especificación
Requerimientos Conocimiento
del Dominio
Artefactos
Abstracción
de la solución
Conocimiento
del Dominio
Descripción
Arquitectura
Capturar
Requerimientos
Extraer
estructuras
de la solución
Especificación
arquitectura
Meta-modelos
![Page 7: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/7.jpg)
Conocimiento
del Dominio
Conocimiento del
Dominio del
Problema
Conocimiento del
Dominio del
Negocio
Conocimiento del
Dominio de la
Solución
Conocimiento
General
Conocimiento del
Sistema/
Producto
es-un
Conocimiento del Dominio
![Page 8: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/8.jpg)
Conocimiento
del Dominio
Conocimiento del
Dominio del
Problema
Conocimiento del
Dominio del
Negocio
Conocimiento del
Dominio de la
Solución
Conocimiento
General
Conocimiento del
Sistema/
Producto
es-un
Se refiere al conocimiento sobre el problema desde una perspectiva del cliente.
Incluye documentos de especificación de requerimientos, entrevistas con clientes, prototipos sugeridos por los clientes, etc.
![Page 9: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/9.jpg)
Conocimiento
del Dominio
Conocimiento del
Dominio del
Problema
Conocimiento del
Dominio del
Negocio
Conocimiento del
Dominio de la
Solución
Conocimiento
General
Conocimiento del
Sistema/
Producto
es-un
Se refiere al conocimiento sobre el problema desde una perspectiva del proceso de negocio.
Incluye conocimiento sobre el proceso del negocio y también vista de los clientes y reportes de análisis de mercado
![Page 10: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/10.jpg)
Conocimiento
del Dominio
Conocimiento del
Dominio del
Problema
Conocimiento del
Dominio del
Negocio
Conocimiento del
Dominio de la
Solución
Conocimiento
General
Conocimiento del
Sistema/
Producto
es-un
Se refiere al conocimiento que proveen los conceptos del dominio para resolver el problema y el cual esta separado de los requerimientos específicos y el conocimiento sobre como se producen los sistemas de software.
Esta clase de conocimiento esta incluido en libros, revistas científicas, y manuales, entre otros.
![Page 11: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/11.jpg)
Conocimiento
del Dominio
Conocimiento del
Dominio del
Problema
Conocimiento del
Dominio del
Negocio
Conocimiento del
Dominio de la
Solución
Conocimiento
General
Conocimiento del
Sistema/
Producto
es-un
Se refiere a los antecedentes (background) generales y experiencias del ingeniero de software y también puede incluir reglas generales.
![Page 12: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/12.jpg)
Conocimiento
del Dominio
Conocimiento del
Dominio del
Problema
Conocimiento del
Dominio del
Negocio
Conocimiento del
Dominio de la
Solución
Conocimiento
General
Conocimiento del
Sistema/
Producto
es-un
Se refiere al conocimiento sobre un sistema, una familia de sistemas o a un producto (JEE, .NET, …)
![Page 13: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/13.jpg)
Métodos de Diseño • ABD Quality-driven
• Artefact-driven
• Use Case/Scenario-
driven --> RUP
• Pattern-driven
• Domain-driven
• Functionality-based
• ABAS
![Page 14: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/14.jpg)
ABD- Architecture Based Design
• Diseño Basado en la Arquitectura (Architecture Based Design - ABD)
• El promotor principal es Bachmann, quien provee una estructura para producir la arquitectura conceptual de un sistema.
• ABD determina las direcciones arquitecturales para el sistema.
• Es la combinación de requerimientos del negocio, de calidad y funcionales que influyen en la arquitectura.
![Page 15: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/15.jpg)
ABD (Continue)
• Elementos:
– Descomposición funcional usando acoplamiento y cohesión
– Realización de los requerimientos de calidad y negocio a través de la selección de un estilo arquitectónico
– Uso de plantillas de software para describir un sistema de software de un tipo particular. Como deben interactuar los elementos...
![Page 16: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/16.jpg)
Quality-driven
• Esta basado en la utilización de estilos
arquitectónicos y patrones como un principio
de diseño de arquitecturas de alta calidad.
• Jan Bosch promueve este método, y
considera que el diseño de arquitecturas de
software toman ventaja de los requerimientos
de calidad desde las etapas tempranas de
desarrollo.
![Page 17: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/17.jpg)
Artefact-driven
• Inicia a partir del texto de los requerimientos
• Mira tipos de artefactos en el método y trata de identificar artefactos desde la especificación de requerimientos usando reglas heurísticas
• Agrupa los artefactos relacionados en SUBSISTEMAS, estos son los componentes arquitectónicos
• Define las relaciones entre los subsistemas
![Page 18: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/18.jpg)
Artefact-driven (Continue)
• Técnicas que extraen la descripción de la arquitectura a partir del artefacto descripciones del método
• Ejemplos:
– Métodos de Análisis y Diseño Orientado a
Objetos tales como OMT y OAD
![Page 19: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/19.jpg)
Use Case/Scenario-driven
• Basado en los casos de uso
• Extraer los casos de uso
• Identificar las clases fundamentales a partir de los casos de uso
• Agrupar las clases en packages, estos son los componentes arquitectónicos
• Definir las relaciones entre los packages
![Page 20: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/20.jpg)
RUP
• Esta centrado en las vistas de diferentes modelos del sistema, casos de uso, análisis, diseño, implementación y despliegue
• Basado en el modelo "4+1" de Krutchen
![Page 21: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/21.jpg)
Pattern-driven
• Inicia con la especificación de requerimientos
• Selecciona los patrones apropiados desde una base de patrones
• Organizar o componer los patrones seleccionados
![Page 22: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/22.jpg)
Functionality-based
• Jan Bosch propone el método de diseño, verificar el texto 1999
![Page 23: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/23.jpg)
ABAS
• Estilo Arquitectónico Basado en Atributos (Attribute-Based Architectural Style - ABAS)
![Page 24: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/24.jpg)
ABAS
![Page 25: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/25.jpg)
Attribute-Based Architectural Styles (ABAS)
• Un ABAS agrega un framework de modelamiento basado-atributos para un estilo arquitectónico.
• ¿Por qué esto?
– para hacer diseño arquitectónico más fácil y fiable
– para tener un conjunto estándar de preguntas de análisis basado en los atributos asociados al estilo
– para reducir la brecha entre el diseño y el análisis
![Page 26: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/26.jpg)
Definición
1. La topología de los tipos de componentes y la descripción del patrón de datos y control, y la interacción entre los componentes.
2. Un modelo específico de los atributos de calidad que proporcione un método de razonar sobre el comportamiento de los tipos de componentes que interactúan en el patrón definido.
3. El razonamiento que resulta de aplicar el modelo específico de atributos a la interacción de los tipos de componentes.
![Page 27: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/27.jpg)
Caracterizaciones
• Para cada atributo, la caracterización describe: – los estímulos del interés
– los parámetros arquitectónicos
– las respuestas
• Para ayudar en la estructuración de un ABAS y entender cada atributo, se utilizan las caracterizaciones de los atributos.
![Page 28: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/28.jpg)
Modelamiento de Decisiones Arquitectónicas usando ABAS
![Page 29: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/29.jpg)
Estructuras de un ABAS 1. Descripción del Problema: el problema que está siendo
solucionado por este ABAS, indicado informal.
2. Estimulo/Respuestas: una caracterización de los estímulos que el ABAS responde a, y las medidas de los atributos de calidad de las respuestas.
3. Estilo arquitectónico: componentes, conectores, propiedades/características, parámetros, topología, restricciones.
4. Análisis: una descripción de cómo los modelos de atributos de calidad se relacionan formalmente con el estilo arquitectónico.
5. Ejemplos: cómo se utiliza este ABAS.
![Page 30: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/30.jpg)
Use Case/Scenario-driven RUP “4+1”
![Page 31: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/31.jpg)
Cliente Modelo del
Dominio
Especificación
Informal
Artefacto
Modelos de
Análisis/Diseño
Descripción
Arquitectura
Paquetes
1. Describe
2. Realiza
Conocimiento
General 3. Agrupa
Abstracción de la solución
4. Composición
Modelo del
Negocio
Modelo de
Casos de Uso
Especificación de Requerimientos
![Page 32: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/32.jpg)
Vistas
• Una vista es una representación de un conjunto de elementos del sistema y sus relaciones.
• Es una representación de alguna de las muchas estructuras presentes simultáneamente en un sistema de software.
[11]
![Page 33: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/33.jpg)
Tipos de vistas
Unidades de
implementación
o áreas de responsabilidad
Funcional
Unidades de computo y
vehículos de comunicación
entre ellas (almacenes,
paralelismo...)
Relación entre elementos
de software y del ambiente
de creación o ejecución
(procesadores, archivos, roles)
Adaptado de [3]
![Page 34: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/34.jpg)
Elegir vistas
Producir lista de vistas candidatas Generar una tabla de interesados vs. intereses,
indicando cuánto detalle necesita cada interesado de cada interés (idealmente con un taller)
Combinar vistas Identificar aquellas vistas en la tabla que solo
requieren una descripción general o interesan a pocos
Identificar aquellas vistas que se pueden combinar
[11]
![Page 35: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/35.jpg)
Elegir vistas
Priorizar vistas
Mejor un enfoque de amplitud y no profundidad en principio
Algunos intereses son más prioritarios
Tiene prioridad lo que ayude a determinar el cumplimiento con la misión
![Page 36: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/36.jpg)
Documentar vistas: plantilla
Adaptado de [11]
(elementos y relaciones)
(relación de vista con el medio)
(como variar la vista)
![Page 37: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/37.jpg)
“4+1 vistas”
Logical View
End-user
Functionality
Implementation View
Programmers
Software management
Process View
Performance
Scalability
Throughput
System integrators
Deployment View
System topology
Delivery, installation
Communication
System engineering
Conceptual Physical
Scenarios
![Page 38: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/38.jpg)
Vista de diseño
Vista de
procesos
Vista de
despliegue
Vista de
implementación
Vista de
casos de uso
vocabulario,
funcionalidad
comportamiento
Funcionamiento,
capacidad decrecimiento,rendimiento
topología del
sistema,distribución,entrega,
instalación
ensamblado del
sistema,gestión deconfiguracionesVista de diseño
Vista de
procesos
Vista de
despliegue
Vista de
implementación
Vista de
casos de uso
vocabulario,
funcionalidad
comportamiento
Funcionamiento,
capacidad decrecimiento,rendimiento
topología del
sistema,distribución,entrega,
instalación
ensamblado del
sistema,gestión deconfiguraciones
Vistas de la arquitectura de un sistema
UP
![Page 39: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/39.jpg)
Vista lógica (de diseño)
• Descomposición orientada a objetos
• Estilo: Orientado a objetos
• Soporta requerimientos funcionales, descompuestos en abstracciones (objetos).
• Puede acompañarse de descripción dinámica con diagramas de estado.
[3]
![Page 40: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/40.jpg)
Vista lógica (de diseño): notación
Tomado de [3]
![Page 41: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/41.jpg)
Vista de procesos
• Descomposición en procesos • Considera los requerimientos no-funcionales como
desempeño, disponibilidad, concurrencia, integridad, tolerancia a fallos...
• Se puede representar como un conjunto de redes de procesos.
• Proceso: grupo de tareas • Tareas: hilos separados de control que pueden ser
planificados individualmente en un nodo de procesamiento.
• Estilo: tubos y filtros, cliente/servidor...
[3]
![Page 42: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/42.jpg)
Vista de procesos: notación
Tomado de [3]
![Page 43: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/43.jpg)
Vista de desarrollo (implementación)
• Descomposición en subsistemas
• Se enfoca en la organización de los módulos en el ambiente de desarrollo como una jerarquía de niveles
• Estilo: por niveles (4 a 6)
[3]
![Page 44: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/44.jpg)
Vista de desarrollo (implementación): notación
Tomado de [3]
![Page 45: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/45.jpg)
Vista física (de despliegue)
• Mapear el software al hardware
• Se ocupa de requerimientos no-funcionales como disponibilidad, confiabilidad, desempeño y escalabilidad.
• El software se ejecuta en nodos de procesamiento
• Se deben mapear las redes, procesos, tareas y objetos a dichos nodos.
[3]
![Page 46: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/46.jpg)
Vista físicas (de despliegue): notación
Tomado de [3]
![Page 47: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/47.jpg)
Vista de escenarios (casos de uso)
• Unirlo todo
• Los escenarios son instancias de los casos de uso, que constituyen guiones (scripts) del sistema
• Esta vista es redundante con las otras, sirve para:
– Ayudar a descubrir los elementos arquitectónicos
– Validar y explicar el diseño arquitectónico
[3]
![Page 48: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/48.jpg)
Relación entre las vistas
Vista lógica Vista de Implementación
Vista de Procesos
Vista de Despliegue
![Page 49: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/49.jpg)
Tipos de resultados
• Cada una de las vistas presenta:
• Aspectos estáticos: mediante los diagramas estructurales de UML.
• Aspectos dinámicos: mediante diagramas dinámicos de UML.
• Ejemplo: se puede trabajar con la vista de casos de uso estática y la vista de casos de uso dinámica, la vista de diseño estática y la vista de diseño dinámica, y así sucesivamente.
![Page 50: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/50.jpg)
Vistas y Diagramas en UML Nombre Descripción Aspectos
Estáticos Aspectos
Dinámicos
Vista de casos de uso
Proyecta el comportamiento del sistema tal y como es percibido por los: usuarios finales, analistas y en-cargados de las pruebas. Especifica las fuerzas que configuran la arquitectura del sistema.
Diagramas de casos de uso
Diagramas de interacción
Diagramas de estados
Vista de diseño Soporta los requisitos funcionales del sistema: servi-cios proporcionados a los usuarios finales. Vocabula-rio del problema y su solución: clases, interfaces y colaboraciones.
Diagramas de clases
Diagramas de objetos
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de procesos Cubre el funcionamiento, capacidad de crecimiento y rendimiento del sistema. Mecanismos de sincroniza-ción y concurrencia del sistema: hilos y procesos.
Diagramas de clases (activas)
Diagramas de objetos
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de implemen-tación
Cubre la gestión de configuraciones de las distintas versiones de un sistema a partir de componentes y archivos quasi-independientes. Ensamblado y dispo-nibilidad del sistema: componentes y archivos.
Diagramas de componen-tes
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de despliegue Contiene los nodos que forman la arquitectura (topo-logía) hardware sobre la que se ejecuta el sistema a través de sus componentes. Está destinada a repre-sentar la distribución, entrega e instalación de las partes que forman el sistema informático físico.
Diagramas de despliegue Diagramas de interacción
Diagramas de estados
Diagramas de actividades
![Page 51: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/51.jpg)
Diagra-
ma de
Casos de
Uso
Diagrama
de
Interac-
ción-
Secuen-
cia
Diagrama
de
Interacción-
Colabora-
ción
Diagra-
ma de
Clases
Diagra-
ma de
Objetos
Diagrama
de
Estados
Diagrama
de
Activida-
des
Diagrama
de Compo-
nentes
Diagrama
de Desplie-
gue
Estática
Dinámica
Estática
Dinámica
Estática
Dinámica
Estática
Dinámica
Estática
Dinámica
Vista de
Despliegue
Vista de Casos
de Uso
Vista de
Diseño
Vista de
Procesos
Vista de
Implemen-
tación
VISTAS Y DIAGRAMAS EN UML
![Page 52: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/52.jpg)
Cuántas vistas pueden existir?
• Pueden existir modelos simplificados que se ajusten al
contexto
• No todos los sistemas requieren todas las vistas:
– Simple procesador: Eliminar la vista de despliegue
– Simple Proceso: Eliminar la vista de procesos
– Programas muy pequeños: eliminar la vista de implementación
• Adicionar vistas:
– Vista de Datos, Vista de Seguridad, etc.
![Page 53: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/53.jpg)
Iteraciones y Arquitectura
Use case Model
Design Model
Deployment Model
Test Model
Implementation Model
Content
![Page 54: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/54.jpg)
Diseño Arquitectonico
• Identifica, selecciona, y valida elementos “significativos arquitectonicamente”
• No todo es una arquitectura – Main “business” classes
– Important mechanisms
– Processors and processes
– Layers and subsystems
– Interfaces
• Produce un Documento de la Arquitectura de Software
![Page 55: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/55.jpg)
Secuencia en el diseño Arquitectónico
• Seleccionar escenarios: críticos y de riesgo • Identificar clases principales y
su responsabilidad
• Distribuir el comportamiento sobre las clases
• Estructurar en subsistemas, layers, definir interfaces
• Define distribución y concurrencia • Implementar un prototipo arquitectónico • Derivar pruebas a partir de los casos de uso • Evaluar la arquitectura
Iterar
Use case view
Logical view
Deployment view
Implementation view
Process view
![Page 56: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/56.jpg)
Proceso iterativo de desarrollo de arquitectura
• Empezar
– Se eligen un pequeño número de escenarios (casos de uso)
– Se elabora un prototipo arquitectónico
– Se identifican y representan los elementos según las 4 vistas
– Se implementa, prueba, mide y analiza la arquitectura
– Se capturan las lecciones aprendidas
• Iteración
– Se reevalúan los riesgos
– Se extiende el grupo de escenarios a considerar
– Se eligen los escenarios que tengan menor riesgo y mayor cobertura
– Se hace un guión de los escenarios acorde con la arquitectura existente
– Se descubren elementos arquitectónicos adicionales
– Se actualizan las vistas
– Se actualiza la implementación
– Se prueba y mide en el ambiente de producción si es posible
– Se revisan las 5 vistas
– Se actualizan las guías y racionalidad de la arquitectura
– Se capturan las lecciones aprendidas
[3]
![Page 57: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/57.jpg)
Documentar la arquitectura: plantilla
• Página de título
• Historia de cambios
• Tabla de contenido
• Lista de figuras
Alcance
Referencias
Arquitectura de software
Metas y restricciones arquitectónicas
Arquitectura lógica
Arquitectura de procesos
Arquitectura de desarrollo
Arquitectura física
Escenarios
Tamaño y desempeño
Calidad
• Apéndices
– Acrónimos y abreviaciones
– Glosario
– Principios de diseño
[3]
![Page 58: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/58.jpg)
Cliente
Conocimiento
General
Especificación
Requerimientos Artefacto
Modelos de
Análisis/Diseño
Descripción
Arquitectura
Subsistemas
1. Describe
2. Busca
Conocimiento
General 3. Agrupa
Abstracción
de la solución
4. Composición
![Page 59: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/59.jpg)
![Page 60: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/60.jpg)
Arquitectura y dependencias
• El diseño de muchas aplicaciones de software inician como una imagen en la mente del diseñador.
Pero no siempre llevan a una solución adecuada!!!
60
![Page 61: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/61.jpg)
Detección de un diseño degradado
Síntomas de un diseño degradado
• RIGIDEZ: Tendencia del software a ser difícil de cambiar. – Un diseño rígido, involucra que al cambiar los
requerimientos de diseño deberán realizarse cambios muy grandes del mismo.
– Significa que el diseño no tiene la capacidad de separarse en módulos independientes.
61
![Page 62: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/62.jpg)
Detección de un diseño degradado
• FRAGILIDAD: Un cambio en alguna parte del software, ocasiona cambios en otros sectores. – Tal software causa la sospecha de administradores
y consumidores de que los diseñadores y desarrolladores han perdido control de su software.
– Genera desconfianza y se pierde la credibilidad.
62
![Page 63: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/63.jpg)
Detección de un diseño degradado
• INMOVILIDAD: Inhabilidad de reusar software
• Por ejemplo: un ingeniero descubre que puede utilizar módulos que ya ha diseñado, pero debido a la inmovilidad de su diseño, deberá volver a reescribir dicho módulo para este caso específico.
• Cuando un módulo resuelve un problema que puede llegar a aparecer en otro momento es muy importante tener en cuenta el concepto de inmovilidad.
63
![Page 64: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/64.jpg)
Detección de un diseño degradado
• VISCOSIDAD: Enfrentados a un cambio, los ingenieros usualmente encuentran más de una forma de realizarlo.
• De entorno: Entorno de desarrollo ineficiente.
• De diseño: Cuando los métodos de preservar el diseño son mas difícil de emplear que los métodos que no preservan el diseño.
64
![Page 65: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/65.jpg)
CONCLUSION
Los módulos deben ser lo más cohesivos (unidos) posible y lo menos dependientes posible.
65
![Page 66: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/66.jpg)
Arquitectura y dependencias
Las arquitecturas de acuerdo a las definiciones (Perry, 1992) están conformadas por:
• Componentes
• Conectores
• Forma
• Razonamiento (rationale)
66
![Page 67: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/67.jpg)
Qué es un Componente?
• OMG Unified Modeling Language Specification [OMG01] define un componente como – “… a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a set of interfaces.”
• OO view: un componente contiene un conjunto de clases colaborando
• Conventional view: lógica, las estructuras de datos internas que son requeridas para implementar el procesamiento lógico, y una interface que habilita al componente para ser invocado (llamada y datos).
67
![Page 68: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/68.jpg)
Componente OO
Prin t Job
c om put eJob
in i t ia t eJob
number Of Pages
number Of Sides
paper Type
paper Weight
paper Size
paper Color
magnif icat ion
color Requir ement s
pr oduct ionFeat ur es
collat ionOpt ions
bindingOpt ions
cover St ock
bleed
pr ior it y
t ot alJobCost
WOnumber
PrintJob
comput ePageCost ( )
comput ePaper Cost ( )
comput ePr odCost ( )
comput eTot alJobCost ( )
buildWor kOr der ( )
checkPr ior it y ( )
passJobt o Pr oduct ion( )
elaborated design c lass< < in t er f ace> >
co m p u t eJo b
comput ePageCost ( )
comput ePaper Cost ( )
comput ePr odCost ( )
comput eTot alJobCost ( )
< < in t er f ace> >
in it iat eJo b
buildWor kOr der ( )
checkPr ior it y ( )
passJobt o Pr oduct ion( )
design c om ponent
num berOf Pages
num berOf Sides
paperTy pe
m agni f ic a t ion
produc t ionFeat ures
Prin t Job
c om put eJobCost( )
passJobt oPrin t er( )
analy sis c lass
68
![Page 69: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/69.jpg)
Componente convencional
ComputePageCost
design component
accessCostsDB
getJobData
elaborated module
PageCost
in: job size in: color=1, 2 , 3, 4
in: pageSize = A, B, C, B out : BPC
out : SF
in: numberPages in: numberDocs
in: sides= 1, 2 in: color=1, 2 , 3, 4
in: page size = A, B, C, B out : page cost
job size ( JS) =
num berPages * num berDocs;
lookup base page cost ( BPC) -->
accessCost sDB ( JS, co lor) ;
lookup size fact or ( SF) -->
accessCost DB ( JS, co lor, size)
job com plexit y fact or ( JCF) =
1 + [ ( sides-1) * sideCost + SF]
pagecost = BPC * JCF
get JobDat a ( num berPages, num berDocs,
sides, co lor, pageSize, pageCost )
accessCost sDB (jobSize, co lor, pageSize,
BPC, SF)
com put ePageCost( )
69
![Page 70: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/70.jpg)
Diseño de componentes basados en clases
• Antes de pensar en toda una arquitectura de software, es necesario identificar si un componente esta bien diseñado.
• Sugerencia Usar los principios de diseño, acompañados de los principios de dependibilidad (cohesión y acoplamiento)
70
![Page 71: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/71.jpg)
Principios de diseño básicos
71
• The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification.
• The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base classes.
• Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions.”
• The Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one general purpose interface.
• The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of release.”
• The Common Closure Principle (CCP). “Classes that change together belong together.”
• The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be grouped together.”
![Page 72: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/72.jpg)
The Open-Closed Principle (OCP)
• Debemos ser capaz de modificar los módulos sin modificar la fuente de código de dicho modulo.
• La abstracción es la clave para el OCP.
• Las clases abstractas presentan un nivel de "abstracción" tan elevado que no sirven para instanciar objetos de ellas y solo sirven para derivar otras clases.
• Técnicas: Polimorfismo dinámico – Polimorfismo estático
72
![Page 73: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/73.jpg)
73
Ejemplo: public class Animal(){ public void habla(){ System.out.println("No se que soy"); } } public class Perro() extends Animal{ public void() habla(){ System.out.println("Guau"); } } public class Gato() extends Animal{ public void() habla(){ System.out.println("Miau"); } public class Zoo(){ public static void main(String[] args) { Animal animal = new Gato(); animal.habla(); animal=new Perro(); animal.habla(); } } El resultado por consola será: "Miau" "Guau"
Polimorfismo dinámico: es aquél en el que el código no incluye ningún tipo de especificación sobre el tipo de datos sobre el que se trabaja. Así, puede ser utilizado a todo tipo de datos compatible.
The Open-Closed Principle (OCP)
![Page 74: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/74.jpg)
The Open-Closed Principle (OCP)
74
Ejemplo: public class Animal(){ public void habla(int a){ if a=1 System.out.println("Guau"); else if a=2 System.out.println("Miau"); } } public class Zoo(){ public static void main(String[] args) { Animal animal = new Animal(); animal.habla(1); animal.habla(2); } } El resultado por consola será: "Miau" "Guau"
Polimorfismo estático: es aquél en el que los tipos a los que se aplica el polimorfismo deben ser explicitados y declarados uno por uno antes de poder ser utilizados
![Page 75: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/75.jpg)
The Liskov Substitution Principle (LSP)
• Las clases se deben diseñar de forma que cualquier clase derivada sea aceptable donde lo sea su superclase.
76
Ejemplo: el circulo en si es un elipse, todos los círculos son elipses que coinciden en sus focos por esto podemos modelar al circulo como un caso particular de elipse y no al revés.
Las subclases deben ser sustitutas de sus clases base. Un usuario de una clase base debe continuar funcionando correctamente si se le pasa una instancia de una clase extendida.
Violaciones del LSP son violaciones latentes del OCP.
![Page 76: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/76.jpg)
• Depende de abstracciones y no depende de implementaciones.
–Usar clases abstractas o interfaces para que las clases cliente que utilizan estas abstracciones, no conozcan nada de las implementaciones que se harían en las clases que extienden de las abstractas o implementan las interfaces.
77
The Dependency Inversion Principle (DIP)
![Page 77: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/77.jpg)
The Dependency Inversion Principle (DIP)
• Arquitectónicamente, los módulos de alto nivel tratan con las políticas de alto nivel de la aplicación. A estas políticas generalmente no le interesan los detalles de sus implementaciones.
78
Cualquier cosa concreta es volátil. La no volatilidad no es un reemplazo para la capacidad de sustitución de una interface abstracta.
![Page 78: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/78.jpg)
The Interface Segregation Principle (ISP)
• Los clientes de una clase no deberían depender de interfaces que no utilizan
82
Ejemplo: La figura muestra un sistema de clientes y una gran interface para atenderlos, como vemos si necesitamos realizar un cambio en uno de los métodos del cliente A esto afectara al cliente B y cliente C. Por lo tanto será necesario recompilar y redistribuirlos.
![Page 79: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/79.jpg)
The Interface Segregation Principle (ISP)
83
Solución: utilizar para cada cliente una interfaz específica. De este modo si la interface para el cliente A necesita un cambio los clientes B y cliente C no serán afectados.
Como con todos los principios, se debe cuidar de no exagerar en su uso!!!
![Page 80: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/80.jpg)
Independencia Funcional
84
![Page 81: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/81.jpg)
“Este modulo tiene una sola entrada y no necesita de otro para
funcionar”
El diseño de software debiera ser tal que cada modulo direcciones una
subfunción especifica de los requerimientos y tenga una interfaz simple
cuando se lea desde otra estructura.
Se alcanza desarrollando módulos con una sola función y además debemos
tener una aversión al excesivo uso de los módulos.
Calcular Sueldo neto
•Calcular sueldo base
•Cálculo leyes sociales
•Cálculo de impuesto
Ejemplo :
Modularidad (acoplamiento y cohesión)
85
![Page 82: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/82.jpg)
• Importancia de la independencia funcional
• El software con modularidad efectiva es fácil de
desarrollar debido a que la función puede ser
compartida y las interfaces pueden simplificarse.
• Los módulos independientes son más fáciles de
mantener ya que los efectos de modificaciones se
limitan al modulo evitando la propagación de
errores.
• La independencia funcional es la clave para el buen
diseño y la clave para desarrollar un buen software.
Modularidad (acoplamiento y cohesión)
86
![Page 83: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/83.jpg)
• Es una medida de la fortaleza funcional
relativa de un módulo
• Un módulo cohesivo ejecuta solo una sola
tarea en un procedimiento de software y
requiere poca interacción con otros
procedimientos que se ejecutan en otra
parte del software, es decir, un modulo cohesivo ejecuta una sola cosa.
Cohesión
87
![Page 84: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/84.jpg)
Baja Espectro de la cohesión Alta
Coincidencial
Lógica
Temporal
Procedural o por
procedimiento
Comunicacional
Secuencial
Funcional
Menos deseable Deseable
Tipos de Cohesión
88
![Page 85: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/85.jpg)
Viajar en auto
Viajar a
caballo
Viajar en tren
Viajar en bus
Tipos de Cohesión
1. Coincidencial Se encuentra cuando los elementos o tareas en un modulo no tienen
relación dentro de ellas. Se puede encontrar cuando un programa
grande es dividido en módulos pequeños en forma arbitraria sin aplicar
criterios en la división.
2. Lógica Un modulo es cohesionado lógicamente si sus elementos manifiestan
relaciones en torno a tareas de una categoría general.
89
![Page 86: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/86.jpg)
3. Temporal Es aquella cuyos elementos están relacionados por el hecho de
que todos sus elementos deben ejecutarse en un mismo margen
de tiempo.
Ejemplo: Modulo encargado de Inicializar un sistema.
4. Procedimental Es cuando todos los elementos del modulo están relacionados en
forma tal que no involucra relación de actividades sino que en un
conjunto de reglas se caracteriza porque el control fluye de una
actividad a otra. Los elementos de un modulo están relacionados y
deben desarrollarse en un orden especifico.
Ejemplo: Limpiar utensilios de cocina, preparar almuerzo.
"El orden es meramente coyuntural y no existe una lógica de operación
derivada de un proceso específico."
Tipos de Cohesión
90
![Page 87: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/87.jpg)
Tipos de Cohesión
5. Comunicacional Es aquella cuyos elementos participan en actividades cuyos
elementos usan los mismos datos de entrada y salida.
Ejemplo : Impresión
Grabación de archivo.
6. Secuencial Se presenta cuando los elementos están involucrados en
actividades tales de manera que los datos de un a actividad sirven
como entrada a la próxima actividad.
Ejemplo : Leer siguiente transacción
Actualizar maestro
91
![Page 88: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/88.jpg)
Tipos de Cohesión
7. Funcional
Todos lo elementos de un modulo se
encuentran relacionados al desempeño de una
sola función.
Ejemplo : Cálculo sueldo neto
92
![Page 89: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/89.jpg)
Ejemplo : Verbo imperativo Objeto
Leer Registro de transacción
Calcular Sueldo neto
Para determinar la cohesión de un modulo
1. Se debe escribir una frase describiendo la
función del módulo y luego hacer un análisis de
esa frase, si de ese análisis el módulo puede
ser expresado como un verbo imperativo
preciso y el predicado como un objeto
específico => hay cohesión funcional.
93
![Page 90: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/90.jpg)
Para determinar la cohesión de un modulo
2. Si el módulo puede ser expresado en forma de un cierto número de acciones, ej: validar transacciones, actualizar maestro, es decir, encontramos más de una relación del verbo imperativo estamos en presencia de una cohesión secuencial.
3. Si el módulo puede ser expresado en término de cierto nº de funciones que están realizando sus tareas con los mismos datos estamos en presencia de una cohesión comunicacional.
Ejemplo : un módulo que permita calcular promedio,
salario mínimo y salario máximo de los empleados.
Las 3 tareas se ejecutarán con los mismos datos.
94
![Page 91: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/91.jpg)
Para determinar la cohesión de un modulo
4. Si el módulo se puede expresar en función de nombres típicos de diagrama de flujo (rutina, switch, módulo) cohesión procedural. La definición describe el procedimiento y el contenido.
5. Si los módulos pueden asociarse a nombre relacionados con cuentas temporales cohesión temporal
Ejemplo : END-OF-FILE
START-UP
95
![Page 92: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/92.jpg)
Para determinar la cohesión de un modulo
6. Si el módulo puede expresarse en propósitos generales más que propósitos específicos habrá cohesión lógica.
7. Si los nombres de módulo son poco significativos hay cohesión coincidencial. Aquí es muy difícil ponerle un nombre significativo al módulo jefe ya que no tienen ninguna relación.
En esencia el tipo de cohesión se puede determinar a
través de una serie de preguntas.
Ejemplo: Editar datos
Editar datos numéricos (FLAG)
96
![Page 93: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/93.jpg)
Para determinar la cohesión de un modulo
• Es importante alcanzar una cohesión alta y
reconocer una cohesión baja de manera
que el diseño de software pueda alcanzar
una mayor independencia funcional.
• Entre más baja es la cohesión el
particionamiento no es el mejor, por lo
tanto, hay que hacer un reparticionamiento
del problema.
97
![Page 94: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/94.jpg)
Cohesión
𝐶𝑜ℎ𝑒𝑠𝑖ó𝑛𝑡𝑜𝑡𝑎𝑙 = 𝑐𝑜ℎ𝑒𝑠𝑖ó𝑛
7
𝑘=1
𝑀ó𝑑𝑢𝑙𝑜𝑖𝑘
𝑁
𝑖=1
98
![Page 95: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/95.jpg)
Acoplamiento
• Es el grado de relación o interdependencia que existe entre los módulos de una estructura de programas.
• Para medirlo se toma en cuenta el nº y tipo de conexiones y la información comunicada a través de ellos.
• Mientras menos sea el nº de conexiones y más simples sean éstas será el indicador de un mejor diseño.
99
![Page 96: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/96.jpg)
Acoplamiento
• La conexión simple entre módulos dará como resultado un software fácil de comprender y menos propenso a un efecto en cadena que es causado cuando los errores ocurren en un lugar y se propagan a través del sistema.
• La idea es minimizar el acoplamiento.
• Un bajo acoplamiento va a ser un indicador de un buen diseño (buen particionamiento).
100
![Page 97: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/97.jpg)
Acoplamiento
Se obtiene un buen acoplamiento:
- Eliminando las relaciones innecesarias.
- Reduciendo el nº de relaciones necesarias
- Minimizando la cantidad de elementos
pasados en una relación (transformando
elementos en paquetes de información).
101
![Page 98: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/98.jpg)
Acoplamiento
Se busca obtener un bajo acoplamiento porque:
• Las réplicas de un error son menores.
• Al intercambiar un módulo se asegura que el riesgo de tener que cambiar otro sea mínimo.
• Cuando se hace mantenimiento a un módulo no se desea conocer detalles internos de otros módulos.
• Que sea un sistema muy simple de entender.
102
![Page 99: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/99.jpg)
Bajo Espectro de Acoplamiento Alto
Indirecto
Por datos
Por
estructuras
de datos
Por control
Externo
Común
Por
contenido
Deseable Menos deseable
Tipos de acoplamiento
103
![Page 100: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/100.jpg)
1. Indirecto No existe ninguna relación entre los módulos
porque dependen de módulos distintos.
Ejemplo :
Tipos de acoplamiento
104
![Page 101: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/101.jpg)
2. Por Datos
Dos módulos son de acoplamiento por datos si ellos
se comunican por parámetros, cada parámetro
puede ser un campo simple o una tabla homogénea
( arreglo en que cada elemento tiene información
del mismo.
Ejemplo :
Monto
Kms
Dias
Tipo-auto
Calcular monto
Generar factura de
Alquiler automóvil
Tipos de acoplamiento
105
![Page 102: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/102.jpg)
3. Por estructuras de Datos Dos módulos están acoplados por estructuras si
ambos se refieren a la misma estructura de datos ( registro).
Registro Cliente -Rol socio automóvil
-Nro de licencia
-Tipo de Automóvil
-Km
-Días
-Gasolina usada
-Nro teléfono del socio
Generar factura de
alquiler automóvil
Calcular monto base
Monto por gasolina
Reg
Cliente
Monto
base
Reg
Cliente
Monto
por
gasolina
Tipos de acoplamiento
106
![Page 103: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/103.jpg)
El módulo invocado necesita solo algunos campos, pero igual recibe el registro completo.
Limitaciones:
• Cualquier cambio que se produzca en el registro ya sea en el formato o en la estructura, afectará todos los módulos donde el regitro está asociado y a aquellos módulos que no hagan referencia a los campos modificados.
• Crea dependencia entre módulos y un cambio en uno de ellos afecta a otros aunque no tengan relación
107
Tipos de acoplamiento
![Page 104: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/104.jpg)
El módulo que invoca decide que parte del subordinado debe
ejecutarse.
4. Por Control
Dos módulos estan acoplados por control si uno entrega al otro
información interna de otro módulo.
Ejemplo:
MOD 1
MOD 2
MOD 2
FLAG
FLAG
FLAG
A B
C
Tipos de acoplamiento
108
![Page 105: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/105.jpg)
5. Externo Dos módulos son de acoplamiento externo si
ambos están ligados a un ambiente externo al
software.
Ejemplo: operación de entrada y salida se conecta
a un módulo de dispositivos específicos, formatos y
protocolos de comunicación.
Este debe estar presente en número muy pequeño
dentro de una estructura.
Tipos de acoplamiento
109
![Page 106: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/106.jpg)
6. Común Dos módulos son de acoplamiento común cuando ambos
hacen referencia a una misma área de datos globales.
Ejemplo :
Encontrar nombre de parte Reducir Stock
Tabla de partes ERRORES
Stock insuficiente
Nº de partes
Nº de unidad reducir
Nombre parte
Nombre parte
Nº de parte inexistente
Nº de parte antigua
Nº
Parte
Tipos de acoplamiento
110
![Page 107: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/107.jpg)
7. Por contenido
Dos módulos son de acoplamiento por contenido si
uno de ellos hace referencia al interior del otro,
esto se puede dar cuando un módulo se refiere o
cambia los datos de otro módulo.
Es el tipo de acoplamiento menos deseable dentro
de una arquitectura de software.
Tipos de acoplamiento
111
![Page 108: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/108.jpg)
Acoplamiento
𝐴𝑐𝑜𝑝𝑙𝑎𝑚𝑖𝑒𝑛𝑡𝑜𝑡𝑜𝑡𝑎𝑙 = 𝑎𝑐𝑜𝑝𝑙𝑎𝑚𝑖𝑒𝑛𝑡𝑜
𝑁
𝑗=1
𝑀ó𝑑𝑢𝑙𝑜𝑖𝑗
𝑁
𝑖=1
112
![Page 109: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/109.jpg)
Lineamientos de diseño
• Componentes
– Convención para nombrar los componentes debe ser establecida. Esta lista forma parte del modelo arquitectural que luego será refinado para alcanzar el modelo de componentes.
• Interfaces
– Proveen información importante sobre la comunicación y colaboración (ayudan para alcanzar el OPC)
• Dependencias y Herencia
– Es una buena idea modelar las dependencias de izquierda a derecha y la herencia desde abajo (clases derivadas) hacia arriba (clases base)
113
![Page 110: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/110.jpg)
Diseño a nivel de Componentes
• Paso 1. – Identificar todas las clases de diseño que
corresponden al dominio del problema.
– Identificar todos los componentes que corresponden al dominio del problema.
• Paso 2. – Identificar todas las clases de diseño que
correspondan al dominio de la infraestructura.
– Identificar todos los componentes de diseño que correspondan al dominio de la infraestructura.
116
![Page 111: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/111.jpg)
Diseño a nivel de Componentes
• Paso 3.
– Elaborar el diseño de clases que no son adquiridas como componentes reusables.
– Elaborar el diseño de componentes que no son adquiridos como componentes reusables.
Paso 3a. Specify message details when classes or component collaborate. (UML collaboration diagram)
Paso 3b. Identify appropriate interfaces for each component.
Paso 3c. Elaborate attributes and define data types and data structures required to implement them.
Paso 3d. Describe processing flow within each operation in detail. (UML activity diagram)
117
![Page 112: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/112.jpg)
Diseño a nivel de Componentes
• Paso 4. – Describa las fuentes de datos persistentes (bases
de datos y archivos) e identifique las clases requeridas para manejarlos
– Describa las fuentes de datos persistentes (bases de datos y archivos) e identifique los componentes requeridos para manejarlos
• Paso 5. – Desarrolle y elabore representaciones de
comportamiento para las clases – Desarrolle y elabore representaciones de
comportamiento para los componentes (UML statechart)
118
![Page 113: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/113.jpg)
Diseño a nivel de Componentes
• Paso 6. – Elabore los diagramas de despliegue para
proveer detalles de implementación adicional.
• Paso 7. –Obtenga la representación final (diseño) del
componente y evalúelo.
119
![Page 114: Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos](https://reader031.vdocumento.com/reader031/viewer/2022020109/5ba1ce1f09d3f2bb6a8d10a2/html5/thumbnails/114.jpg)
Principios de arquitectura de paquetes
La cohesión de los paquetes
• The Release Reuse Equivalency Principle (REP) – Principio de equivalencia de liberación y reuso
– The Common Closure Principle (CCP)
– The Common Reuse Principle (CRP)
• Principios de Acoplamiento de Paquetes – The Acyclic Dependencies Principle (ADP)
– The Stable Dependencies Principle (SDP)
– The Stable Abstractions Principle (SAP)
120