Post on 19-Sep-2018
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
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.
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
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
Meta-Modelos
Adaptado de P. Kruchten, B. Selic, W. Kozaczynski. “Describing Software Architecture with UML”, 2001
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
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
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.
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
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.
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.
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, …)
Métodos de Diseño • ABD Quality-driven
• Artefact-driven
• Use Case/Scenario-
driven --> RUP
• Pattern-driven
• Domain-driven
• Functionality-based
• ABAS
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.
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...
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.
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
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
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
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
Pattern-driven
• Inicia con la especificación de requerimientos
• Selecciona los patrones apropiados desde una base de patrones
• Organizar o componer los patrones seleccionados
Functionality-based
• Jan Bosch propone el método de diseño, verificar el texto 1999
ABAS
• Estilo Arquitectónico Basado en Atributos (Attribute-Based Architectural Style - ABAS)
ABAS
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
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.
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.
Modelamiento de Decisiones Arquitectónicas usando ABAS
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.
Use Case/Scenario-driven RUP “4+1”
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
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]
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]
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]
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
Documentar vistas: plantilla
Adaptado de [11]
(elementos y relaciones)
(relación de vista con el medio)
(como variar la vista)
“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
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
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]
Vista lógica (de diseño): notación
Tomado de [3]
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]
Vista de procesos: notación
Tomado de [3]
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]
Vista de desarrollo (implementación): notación
Tomado de [3]
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]
Vista físicas (de despliegue): notación
Tomado de [3]
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]
Relación entre las vistas
Vista lógica Vista de Implementación
Vista de Procesos
Vista de Despliegue
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.
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
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
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.
Iteraciones y Arquitectura
Use case Model
Design Model
Deployment Model
Test Model
Implementation Model
Content
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
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
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]
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]
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
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
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
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
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
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
CONCLUSION
Los módulos deben ser lo más cohesivos (unidos) posible y lo menos dependientes posible.
65
Arquitectura y dependencias
Las arquitecturas de acuerdo a las definiciones (Perry, 1992) están conformadas por:
• Componentes
• Conectores
• Forma
• Razonamiento (rationale)
66
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
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
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
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
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.”
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
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)
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
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.
• 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)
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.
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.
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!!!
Independencia Funcional
84
“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
• 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
• 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
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
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
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
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
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
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
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
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
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
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
Cohesión
𝐶𝑜ℎ𝑒𝑠𝑖ó𝑛𝑡𝑜𝑡𝑎𝑙 = 𝑐𝑜ℎ𝑒𝑠𝑖ó𝑛
7
𝑘=1
𝑀ó𝑑𝑢𝑙𝑜𝑖𝑘
𝑁
𝑖=1
98
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
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
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
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
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
1. Indirecto No existe ninguna relación entre los módulos
porque dependen de módulos distintos.
Ejemplo :
Tipos de acoplamiento
104
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
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
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
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
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
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
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
Acoplamiento
𝐴𝑐𝑜𝑝𝑙𝑎𝑚𝑖𝑒𝑛𝑡𝑜𝑡𝑜𝑡𝑎𝑙 = 𝑎𝑐𝑜𝑝𝑙𝑎𝑚𝑖𝑒𝑛𝑡𝑜
𝑁
𝑗=1
𝑀ó𝑑𝑢𝑙𝑜𝑖𝑗
𝑁
𝑖=1
112
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
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
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
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
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
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