8. Frenado del Airbus A320
Sensor
Ruedas
giro
alt
Sensor
Sensor
Sistema de
Frenado Airbus
A320
pulsos
peso
señal de habilitado y
deshabilitado de
aceleración de reversa
Motor de
Reversa
prendido y
apagado de
motor
Controlador de
Aceleración de
Reversa
señales de
prendido y
apagado de
motor
Piloto
8
9. Frenado del Airbus A320
Ruedas
giro
Sensor
Sistema de
Frenado Airbus
A320
pulsos
señal de habilitado y
deshabilitado de
aceleración de reversa
Motor de
Reversa
prendido y
apagado de
motor
Controlador de
Aceleración de
Reversa
señales de
prendido y
apagado de
motor
Piloto
9
10. Recordatorio: La relación entre el
problema y solución
Independiente
Dependencia de la implementación
Dependiente
Menos Info
Nivel de
Completitud
Enunciado del
Problema
Enunciado de la
Implementación
Mas Info
10
11. Requerimientos y Diseño: Una Visión
Top-Down
Sistema
Requerimientos
Design
Subsistema
Requerimientos
Design
Component
e
Requerimientos
Design
• Ojo: Tomar decisiones de bajo nivel es
compatible con esta visión...
11
12. Diseño de Software
• Los Sistemas de Software Intensivo son entes
complejos
– millones de líneas de código, variables, posibles estados, etc...
• ¿Cómo lidiamos con la complejidad?
– Estructura y Abstracción...
– ...sí, pero cómo? qué abstracciones? qué relaciones?...
• Diseñar involucra estructurar la solución utilizando
abstracciones y relaciones entre las abstracciones
apropiadas para poder:
•
•
•
•
•
•
Documentar y Comprender la propuesta de solución
Razonar sobre su grado de adecuación c.r.a los requerimientos
Comunicarla
Implementarla
Verificar/Validar el producto final
Modificar/Adaptar la solución en la medida que cambien los
requerimientos
13. Diseño de Software
• Guía en la concepción de productos de software (requerimientos
complejos, integración de componentes existentes, tecnología,
familias de productos, etc.)
• Drivers: atributos de calidad/requerimientos no funcionales y
restricciones de proyecto y tecnología
– Usualmente en tensión
• A diferencia del mundo de los requerimientos:
– Denota conceptos del mundo de la solución (pero incluye
fenómenos de la interfase mundo máquina)
– En general se describen propiedades localizadas (unidad,
componente, módulo) y son de naturaleza operacional
13
14. Objetivos de la Etapa de Diseño
• Descomponer el sistema en entidades de diseño “más
chicas”
– ej qué paquetes, clases, módulos, componentes...
• Determinar la relación entre entidades.
– ej. identificar dependencias
• Fijar mecanismos de interacción
– ej. memoria compartida, RPC, llamadas a función
• Especificar interfaces y funcionalidad de entidades
– ej. operaciones y sus aridades, descripción formal/informal de
comportamiento
• Identificar oportunidades para el reuso
– tanto top-down como bottom-up
• Documentar todo lo anterior junto con la
fundamentación de las elecciones
15. Metodología de Diseño: Visión “Macro”
• El foco en el proceso de Diseño pasa:
– de los stakeholders externos (cliente, usuario, etc.)
a los internos (desarrolladores, testers, etc.)
– de Qué y Porqué a Qué y Cómo
• Pasos Macro
– Diseño Arquitectónico (o Arquitectura)
– Diseño Detallado (o Diseño)
• Proceso iterativo
– Decisiones clave primero
• ej. Requerimientos no-funcionales críticos
• ¿Qué va a cambiar?
16. El Diseño Detallado y la Tecnología de Construcción
de Soluciones
• Decisiones, patrones, notaciones, modelos y
“blueprints” de diseño pueden estar
fuertemente impactados por el paradigma de la
tecnología que se usa en la solución,
(especialmente si hablamos de un diseño detallado)
• Dónde está el límite entre codificar y diseñar?
…
• Veremos el caso cuando hablemos de POO
19
19. Vistas
• La descripción de un sistema complejo
no es unidimensional
• Es clave saber cuáles son las vistas
relevantes y vincularlas
• Relevancia: depende del propósito (e.g.,
enunciar la misión de implementación,
análisis de atributos de calidad,
generación automática de código,
planificación, etc.)
22
20. Vistas y stackeholders
• La metáfora de D.Garlan
I do bones,
not hearts.
These views are needed by
the cardiologist…
…but will these views work for
the orthopedist?
D.Garlan
23
21. Vistas
• Las vistas exponen atributos de calidad
en diferente grado:
– Vista modular: portabilidad…
– Vista de deployment: performace,
confiabilidad…
• Enfatizan aspectos e ignoran otros para
que el problema sea abordable
• Ninguna vista es “EL” diseño
24
22. Vistas Clásicas
• Vista Modular: ¿Cómo agrupamos el código?
– métodos, procedimientos, clases, librería, DLLs, APIs, paquetes,
módulos...
– usa, subclase, contiene, depende-de,...
– diagrama de clases y de paquetes
• Vista “Run-time” o de Componentes y Conectores:
¿Cómo son las entidades run-time?
– procesos, threads, objetos, protocolos, ciclos de vida
– se-comunica-con, bloquea, contiene, crea, destruye,...
– maquinas de estado, diagrama de secuencia y de colaboración,
diagrama de objetos, diagrama de componentes
• Vista de Deployment (de Despliegue): ¿Dónde residen
las distintas partes?
– Recursos y repositorios además de entidades dinámicas o estáticas
– procesos ejecuta-sobre server, código de módulos almacenado en
directorio, equipo de trabajo desarrolla paquete,...
– diagrama de despliegue, ...
25
23. Ejemplo: Módulos vs. Componentes
• Módulos: entidad en tiempo de diseño.
Enfatiza en encapsulamiento:
“information hiding” e interfaces.
• Componentes: tienen entidad en tiempo
de ejecución y de despliegue
26
24. Alternando caracteres:
Module View
Alternar mayúsculas con minúsculas a partir de
un stream de caracteres
main
main
split
split
lower
lower
“sofTWareArchitecture” =>
“SoFtWaReArCiTeCtUrE”
upper
upper
merge
merge
Referencias
config
config
input/output
input/output
Modularización en función del
a relación de uso
Modulo
Usos
27
27. Vista Modular (Diagrama de Clases)
Este ejemplo enfatiza la agrupación de métodos y datos en
clases además de asociaciones (dependencias estructurales) y
relaciones de herencia y contiene-a
30
38. Módulo
• Concepto proveniente de los 60’s y 70’s
• Basado en la noción de unidad de
software que provee servicios a través
de una interfaz bien definida
• La manera de modularización suele
determinar características como
modificabilidad, portabilidad y reuso
41
39. Elementos
• Un módulo es una unidad de código que
implementa un conjunto de
responsabilidades
– Una clase, una colección de clases, una capa
o cualquier descomposición de la unidad de
código
42
40. Relaciones
• Se distinguen tres tipos de relaciones
– es parte de que define la relación entre un
submódulo A y un módulo B
– depende de que define la dependencia
entre dos módulos A y B
– es un que define una relación de
generalización entre un modulo específico y
otro más general
43
41. Module Viewtype: utilidad
• Análisis
– A partir de estas vistas, es posible realizar
distinto tipos de análisis Por ejemplo:
• Trazabilidad de Requerimientos
– Analiza como los requerimientos funcionales
son soportados por las responsabilidades de
los distintos módulos
• Análisis de Impacto
– Permite predecir el efecto de las
modificación del sistema
44
42. Module Viewtype: utilidad
• Comunicación
– Estas vistas pueden ser utilizadas para
explicar las funcionalidades del sistema a
alguien no familiarizado con el mismo
– Distintos niveles de granularidad,
presentan una descripción top-down de las
responsabilidades del sistema
45
43. Module Viewtype: cuando no
• Es dificultoso utilizar este tipo de vistas para
realizar inferencias sobre el comportamiento
del sistema durante su ejecución
• Dada su naturaleza, no es de mucha utilidad
para la realización de análisis de performance,
confiabilidad u otras características
asociadas al tiempo de ejecución
– Múltiples instancias de objetos
– Relaciones existentes sólo en tiempo de ejecución
46
45. Elementos
• Son entidades con manifestación runtime que
consumen recursos de ejecución y contribuyen
al comportamiento en ejecución del sistema
• La configuración del sistema es un grafo
conformado por la asociación entre
componentes y conectores
• Las entidades runtime son instancias de tipos
de conector o componente
48
46. Utilidad
• ¿Cuales son los componentes ejecutables y
como interactúan?
• ¿Cuáles son los repositorios y que
componentes los acceden?
• ¿Qué partes del sistema son replicadas y
cuantas veces?
• ¿Cómo progresan los datos a los largo del
sistema a medida que éste se ejecuta?
49
47. Utilidad
• ¿Qué protocolos de interacción son usados
por las entidades comunicantes?
• ¿Qué partes del sistema se ejecutan en
paralelo?
• ¿Cómo la estructura del sistema puede
cambiar a medida que se ejecuta?
50
48. Propiedades
Confiabilidad
Podemos
usarlo para determinar la funcionalidad del
sistema en su conjunto
Performance
Tiempo
de respuesta / carga
Tiempo de latencia y volumen de procesamiento
Recursos
requeridos
Necesidades
de almacenamiento
Necesidades de procesamiento
51
49. Propiedades
• Funcionalidad
– Funciones mapeadas sobre el componente
• Protocolos
Patrones de eventos o acciones que pueden tener lugar en
una interacciones representada por el elemento
• Seguridad
Encripta
Audita
Autentica
52
50. Para lo que NO sirve
• No se debe usar para modelar elementos de
diseño que no tienen comportamiento runtime
• Una clase no es un componente. Un
componente no representa de ninguna manera
una visión estática de diseño
53
51. Resumen
Conectores
• C&C viewtype define modelo consistente de
elementos que tienen presencia runtime
• C&C viewtype incluye información sobre los
caminos de interacción entre los componentes
• Los componentes tienen interfaces llamadas
ports
• Los conectores tienen interfaces llamadas roles
54
54. Características del C&C
• Los componentes y conectores representan entidades
de tiempo de ejecución
• Los ports son las interfaces de comunicación de los
componentes agrupando señales de entrada y salida
que siguen algún tipo de secuenciamiento (protocolo)
• Los conectores tienen como función mediar en la
interacción entre componentes
• Los conectores pueden representar formas complejas
de interacción más allá del simple call return
sincrónico
• El conector debería especificar el protocolo bajo el
cual los componentes interactúan para cada uno de
sus roles
57
66. Herramientas Conceptuales: Principios
• Decomposición
– Divide & Conquer (piezas conocidas y tratables)
– Separación por niveles de abstracción y/o máquinas virtuales
– Separación por aspectos, etc.
• Modularidad
– Colección bien definida de partes e interacciones bien delimitadas
• Ocultamiento de la información
– Confinar el impacto del cambio (de un módulo)
– El ciente de un módulo no debe conocer los detalles de diseño difíciles o que
pueden cambiar
• Encapsulamiento
– Clara separación de interface e implementación
– Mecanismos para no conocer ni usar más de lo que la interface promete
• Abstracción
– Foco en lo esencial
69
67. Principios (Cont.)
• Explotar el Polimorfismo
– tratamiento uniforme de una entidad que puede tener múltiples
formas
– Sustitución Liskov/Wing
• Inversión de dependencia/control
– Depender en abstracciones e interfaces en lugar de clases concretas
– Ser invocado en lugar de invocar para reuso de abstracciones de
control
•
•
•
•
Segregación de interfaces
Una sola responsabilidad (cohesion)
Open-Close
Detección de puntos de variabilidad
Advertencia: Estos principios han nacido con la extensibilidad y la
modificabilidad como atributos de calidad preponderantes
70
68. Estrategias de Descomposición
• Problemas que sabemos resolver
– Ej. M. Jackson’s Problem Frames: Control, Visualizacion,
Correspondencia, etc
• Pasos de ejecución
– Ej. Filtros de procesamiento de imagenes
• Tempo de ejecución
– Ej. Acumulación vs Utilización de Información
• Funcional
– Ej. Facturación, Compras y Sueldos
• Modos de Operación
– Normal vs Excepcional
• Datos
– Ej. Guiado por el modelo conceptual. Clientes, Ambulancias...
71
69. Advertencia
• Divide and Conquer está muy bien...
• ...pero despues de descomponer hay que
integrar
• “Divide to Conquer and reunite to rule” M.
Jackson
• Hay que poder razonar sobre la composición...
73
70. Descomposición de software
• Módulos
– Agrupa estructuras de datos y código (y posiblemente otros
módulos)
– Entidad estática
– A veces, separa Interfaz de Implementación
• Interfaz bien definida
– A veces, es compilable de manera independiente
• Es una unidad de trabajo para desarrollo
• Componentes
– Entidades run-time
– Descomposición para cumplir con ciertos requerimientos no
funcionales distintos a los módulos (performance, distribución,
tolerancia a fallas, seguridad, adaptabilidad en run-time, etc.).
74
71. Abstracción
• Suprimir detalles de implementación permite
– Posponer ciertas decisiones de detalle que ocurren a distintos
niveles de análisis
– Simplificar el análisis, comprensión y justificación de la
decisión de diseño
• Tipos de Abstracción
– Procedural
• ej. Funciones, métodos, procedimientos
– Datos
• ej. TADs, modelos de componentes
– Control
• ej. loops, iteradores, frameworks
y multitasking
75
73. Acoplamiento
• Grado de dependencia del módulo sobre otros módulos y en
particular las decisiones de diseño que estos hacen
• Generalmente correlaciona inversamente con cohesión
– Bajo/Débil acoplamiento y Alta Cohesión
• Alto acoplamiento generalmente conlleva
– Propagación de cambios cuando se altera un módulo
– Módulos son difíciles de entender aisladamente
– Reuso y testeo de módulos es difícil ya que se requieren otros
módulos
• Acoplamiento se incrementa si
– Un módulo usa un tipo de otro módulo
– Si un módulo usa un servicio de otro módulo
– Si un módulo es un submódulo de otro
• Bajo acoplamiento puede significar peor performance
– Tradeoff...
80
74. Tipos de Acoplamiento
Ordenado de mayor a menor (segun E. Yourdon y L. Constantine...)
• Contenido
–
–
Cuando un módulo modifica o confía en el lo interno de otro
ej. acceso a datos locales o privados
–
–
Cuando comparten datos comunes
ej. una variable global
–
–
Cuando comparten aspectos impuestos externamente al diseño.
ej. formato de datos, protocolo de comunicación, interfaz de dispositivo.
–
–
Cuando un módulo controla la lógica del otro
ej. pasándole un flag de comportamiento).
–
–
Cuando comparten una estructura de datos pero cada uno usa sólo una porción
Paso de todo un registro cuando el módulo sólo necesita una parte.
–
–
Módulos se comunican a través de datos en parámetros
ej. llamado de funciones de otro módulo
–
Módulos se comunican a través de mensajes. Posiblemente no se conocen
explícitamente
•
Común
•
Externo
•
Control
•
Estampillado (Stamp)
•
Datos
•
Mensajes
81
75. Information Hiding / Encapsulamiento
• Esconder las decisiones de diseño que pueden
llegar a cambiar
• Minimizar el impacto de cambios futuros
• Minimizar la información en la interfaz
• Información a abstraer/esconder
–
–
–
–
–
–
Representación de datos
Algoritmos
Formatos de entrada y salida
Interfaces de bajo nivel
Separación de políticas y mecanismos
Decisiones estructurales de más bajo nivel
82
76. Programación basada en interfases
• Como usuario de una
abstracción, es
fundamental no depender
de los detalles de la
implementación
• Ejemplos
– Estándares de jure vs.
Implementaciones
– Estándares de facto vs.
variaciones
– Especificación vs.
Implementación
– Interfases (OO) vs. Clases
concretas
83
77. Dependency Inversion Principle
• “Depend upon Abstractions. Do not depend upon concretions.”
• Objetivo: Hacer un diseño más flexible, enfocando el diseño a
interfaces o clases abstractas, en lugar de a clases concretas.
84
78. Interface Segregation Principle
• “Many client specific interfaces are better than one
general purpose interface”.
• Objetivo: Separar interfaces para minimizar
dependencias.
85
79. Liskov Substitution Principle
• Un principio pensado para lenguajes de programación con
herencia...
• “Subclasses should be substitutable for their base classes”
• Una subclase puede ser usada donde su clase base es usada.
86
80. Cohesión
• Del diccionario
– cohesión. (Del lat. cohaesum, supino de cohaerēre, estar unido).
1. f. Acción y efecto de reunirse o adherirse las cosas entre sí o la
materia de que están formadas.
– cohesion. the action or fact of forming a united whole
• Grado de [foco | cuán bien trabajan juntos |
coherencia | unión] que tienen los distintos elementos
de un módulo
• Alta cohesión tiende a proveer:
–
–
–
–
–
–
Robustez
Confiabilidad
Reusabilidad
Comprensibilidad
Testeabilidad
Mantenibilidad
87
81. Tipos de Cohesión
Ordenado de peor a mejor (según E. Yourdon y L. Constantine en los 70’s)
• Coincidental
–
ej. mis funciones de uso frecuente, utils.lib
–
–
Existe una categoría lógica que agrupa elementos aunque hagan cosas muy distintas
ej. todas las rutinas de I/O
–
–
Agrupadas por el momento en que se ejecutaran
ej. Funciones que atajan un error de output, crean un error en un log y notifican al usuario
–
–
Agrupadas por pertenecer a una misma sequencia de ejecución o política.
ej. funciones que chequean permisos y abren archivos
–
–
Agrupadas por operar sobre los mismo datos.
ej. objetos, operaciones sobre clientes.
–
Agrupadas porque el output de uno es el input de otro
–
Agrupadas porque contribuyen a una tarea bien definida del módulo
•
Lógico
•
Temporal
•
Procedural
•
Comunicacional
•
Secuencial
•
Funcional
Ed dice
que estos
son
aceptables
88
82. Single Responsibility Principle
• “A class should have only one reason to change.”
• Objetivo: Obtener un alto grado de cohesión. Una clase
debe tener una y solo una responsabilidad.
89
83. Extensibilidad y Open/Closed Principle
• Los requerimientos cambian. El diseño debe
poder acomodar estos cambios.
• Un diseño extensible debe poder ser extendido
con facilidad para incorporar nueva
funcionalidad
• The open/closed principle
– Software entities should be open for extension but
closed for modification
– La idea es que la funcionalidad existente no debe
tocarse para no romper código existente, sólo
agregar.
– ej. Capacidad de lidiar con nuevos tipos de eventos
90
85. Preguntas para la Buena
Modularización
• Hay una jerarquía de módulos donde módulos grandes están
descompuestos en más pequeños?
• Cada módulo es comprensible de manera independiente
• Qué cambios de requerimientos podrían implicar un cambio en el
módulo?
– The Single Responsability Principle: A module should have only one
reason to change
• Qué impacto tiene un pequeño cambio en un módulo a otros?
• Qué impacto tiene el mal funcionamiento de un módulo sobre otros?
• Es excesivo el número de módulos con que un módulo se comunica
(fan-out)?
• Es excesivo el número de módulos que utilizan al módulo (fan-out)?
– Interface Segregation Principle: Many specific interfaces are better
than a general one.
• La interfaz de un módulo revela demasiado? Podría abstraerse?
• Es evidente del código cuando dos módulos se comunican?
• ...
92
86. Design Patterns
• Gamma, Helm, Johnson
& Vlissides, 1995 (Aka The gang of four)
• Soluciones esquemáticas (buen diseño) a
problemas recurrentes en el desarrollo
de software OO
• Catálogo de 23 patrones:
– fenómeno de definición terminológica
• Los Design Patterns se suponen que
incorporan los principios de diseño que
vimos
93
87. Design Patterns
• La descripción de un patrón de diseño debe
incluir:
Nombre: Debe ser significativo
Problema: una descripición del problema atacado por el patrón
Contexto: precondiciones bajo las que puede ocurrir
Fuerzas: restrciciones y cuestiones que la solución debe tratar
Solución: relación estáticas y dinámicas entre los componentes
del patrón. La solución resuelve las fuerzas en el contexto
dado
– Más
–
–
–
–
–
•
•
•
•
Ejemplos de uso
Patrones relacionados
Otros nombres usados del patrón
Ejemplo en código
94
88. Design Patterns
• Tipos de Patterns:
– De Creación: soluciones flexibles para la creación
de instancias (e.g., abstract factory, singleton, etc.)
– Estructurales: soluciones de organización (herencia,
composición, agregación, asociación) de clases e
interfaces para la extensibilidad y cambio (ej.,
composite, bridge, facade, adapter, etc.)
– De comportamiento: soluciones para la asignación
de responsabilidades y diseño de algoritmos.
Muestran relación estática y comunicación (ej.,
command, interpreter, mediator, observer,
memento, etc. )
95
89. Design Pattern: Singleton
• Nombre: Singleton
• Problema: Cómo definir una clase que debe tener una
sola instancia accesible desde toda la aplicación.
• Contexto: En algunas aplicaciones es importante que la
clase tenga exactamente una instancia. Una aplicación
de procesamiento de ventas podría tratar con ventas
de una sola compañía y necesitar datos de la misma
almacenado en un objeto que sería el único de la clase.
• Fuerzas: Usar una variable global no es un buen diseño.
Otra opción es no crear instancias sino usar métodos y
atributos estáticos pero no es es una buena solución
para explotar el polimorfismo sobre sublases singleton
y require un conocimiento global del tratamiento de la
instancia como singleton.
96
90. Design Pattern: Singleton
• Solución:Crear un método estático GetInstance().
Cuando accede por primera vez crea la instancia y
devuelve una referencia. Las otra veces que es
accedido retorna esa referencia. El patrón ofrece las
siguientes ventajas y desventajas….
97
91. Design Pattern: Singleton
Solución de Will Pugh (Thread Safe y Laizy load)
public class Singleton
{ // Protected constructor is sufficient to suppress unauthorized
calls to the constructor
protected Singleton() {}
/** * SingletonHolder is loaded on the first execution of
Singleton.getInstance() or the first access to
SingletonHolder.instance , not before. */
private static class SingletonHolder {
private final static Singleton instance = new Singleton(); }
public static Singleton getInstance() { return
SingletonHolder.instance; } }
98
107. Cuándo usar los Design Patterns
Hay un pattern para el problema
Propone una solución mejor
No hay una solución más simple
El contexto del problema es consistente
con el del pattern
• Las consecuencias de usarlo son
aceptables
•
•
•
•
114
108. Evaluación de Diseños
• 3 grandes tipos de evaluación
Requerimientos
Diseño
Código
Requerimientos
Diseño
Código
Requerimientos
Diseño
Código
115
109. Algunos Errores Comunes (1/2)
• Diseño Depth First
– Sólo satisface algunos requerimientos
• Refinamiento directo de la especificación de
requerimientos
– Puede llevar a un diseño ineficiente
• Olvidarse de cambios a futuro
– Diseñar para extensión (y contracción!)
• Diseñar demasiado en detalle
– Introduce demasiadas restricciones a implementación
– es muy caro, no vale la pena
• Diseñar exclusivamente top-down
– Primero los requerimientos críticos!
– No todo lo vamos a construir. Selección de COTS influye en la
descomposición
116
110. Algunos Errores Comunes (2/2)
• Diseño documentado ambiguamente
– Interpretado incorrectamente en tiempo de implementación
• Decisiones de diseño indocumentadas
– Diseñadores son necesarios durante la implementación
• Decisiones de diseño sin justificación
documentada
– Cambios mas adelante, aparentemente inofensivos, rompen el
diseño
• Diseño inconsistente
– Módulos funcionan, pero no encajan
– Divide to conquer, reunite to rule
117
111. Ejes para críticas de diseño
•
•
•
•
•
•
•
•
•
•
•
Coorrección: fallas sintácticas y semánticas
Completud: tareas relevantes de diseño incompletas
Consistencia: contradicciones internas del diseño
Optimización: mejores opciones para los parámetros de
diseño
Pertinencia: decisiones soportadas por requerimientos
Alternativas: otras elecciones para una decisión de
diseño
Evolución: asuntos que comprometen futuros cambios
Presentación: uso torpe de la notación
Herramientas: otras herramientas que podrían ser usadas
en una decisión de diseño
Experiencia: recordar experiencias pasadas relevantes
Organizacional: interses de otros stakeholders
121
112. Métricas de Software
1970s: Intentos para definir criterios cuantitativos simples de complejidad
del sofwtare y otras calidades
Halstead Complexity Measures
• Program Length = total operators + total operands
• Program Vocabulary = total distinct operators + total distinct
• operands
• Volume = Program Length * (log2Program Vocabulary)
• Difficulty = (total distinct operators/2) * (total operands/total
• distinct operands)
• Effort = Difficulty * Volume
McCabe Complexity Measure
• Cyclomatic Complexity = edges in call graph — nodes in call graph +
connected components
COCOMO modelo de costo para la estimación de costo, esfuerzo y
calendario
122
113. Crítica a las métricas: Weyuker et.al.
Weyuker y otros observaron que la mayoría de las métricas fallaban en
cumplir algunas propiedades obvias y deseables
Weyuker definió 9 propiedades deseables
Propiedad 3: Detalles de Deseño son importantes
» Dos clases con la misma funcionalidad no deberían necesariamente tener el
mismo valor para la métrica
Propiedad 4: Monotonía
» La métrica para una combinación de clases no puede dar menos que ninguna
de las métricas de las componentes
Propiedad 6: La interacción de clases incrementa la complejidad
» El valor de la métrica de un par de clases que interactuan es mayor a la
suma de los valores individuales
Shyam R. Chidamber, Chris F. Kemerer, ‘A Metrics Suite for Object Oriented Design’, IEEE
Transactions on Software Engineering, vol. 20, no. 6, pp. 476-493, Jun. 1994
123
Notas del editor
build systems compositionally from parts
assure that the system conforms to the architecture and has the desired properties
use standard integration architectures
reuse codified architectural design expertise
reduce costs through product-lines
Si tuvieramos cambiaramos la interfaz, tendriamos mas garanteias
Poner gráfico de sistema oseo y sistema circulatorio
Mención a las palabras de Gamma : la diferencia entre la estructura del programa en tiempo de ejecución y la estructura del código (congelada en tiempo de compilación como jerarquía de clases vs objetos comunicándose)
Un módulo puede no ser deployable.
Un compoenente se replica un módulo no
Un módulo pude vivir en muchos componentes.
Un módulo se caracteriza enumerando sus responsabilidades
El estilo del módulo determinará el tipo de dependencia
Cuándo no usarlo?
Qué tipo de notaciones conocen?
3.1 Introducción
The system contains a shared repository of customer accounts (Account DB) accessed by two servers and an administrative component.
A set of client tellers can interact with the account repository servers, embodying a client-sever style.
The purpose of the two servers (we learn from the supporting documentation) is to enhance reliability: if the main server goes down, the backup can take over.
There is a component that allows an administrator to access, and presumably maintain, the shared data store.
There are three types of connectors shown in this cartoon, each representing a different form of interaction among the connected parts.:
The client-server connector allows a set of concurrent clients to retrieve data synchronously via service requests and supports transparent failover to a backup server.
The database access connector supports authenticated administrative access for monitoring and maintaining.
The publish-subscribe connector supports asynchronous announcement and notification of events.
3.2 Elements, Relations, and Properties of the C&C Viewtype
Each of the elements in a C&C view of a system has a run-time manifestation as an entity that consumes execution resources, and contributes to the execution behavior of that system.
The relations of a C&C view associate components with connectors to form a graph that represents a run-time system configuration.
These run-time entities are instances of component and connector types. The available types are either defined by choosing a specific architectural style that prescribes a set of C&C building blocks (see Chapter 4) or they may be custom defined. In either case, the types are chosen because there is significant commonality among several components or connectors in the architecture. Defining or using a set of component and connector types provides a means for capturing this commonality, provides a specialized design vocabulary targeted to specific domains, and introduces constraints on how that vocabulary is used.
3.3 What the C&C Viewtype Is For, and What It’s Not For
The C&C viewtype is used to reason about run-time system quality attributes, such as performance, reliability, availability. In particular, a well documented view will allow architects to predict overall system properties, given estimates or measurements of properties of the individual elements and interactions. For example, to determine whether the overall system can meet its real-time scheduling requirements you must usually know the cycle time of each process in a process-oriented view. Similarly, knowing the reliability of individual elements and communication channels supports an architect when estimating or calculating overall system reliability. In some cases this kind of reasoning is supported by formal, analytical models and tools. In others, it is achieved by judicious use of rules of thumb and past experience.
C&C views allow one to answer questions such as:
• What are the system’s principal executing components and how do they interact?
• What are the major shared data stores?
• Which parts of the system are replicated, and how many times?
• How does data progress through a system as it executes?
• What protocols of interaction are used by communicating entities?
• What parts of the system run in parallel?
• How can the system’s structure change as it executes?
3.3 What the C&C Viewtype Is For, and What It’s Not For
C&C views allow one to answer questions such as:
• What are the system’s principal executing components and how do they interact?
• What are the major shared data stores?
• Which parts of the system are replicated, and how many times?
• How does data progress through a system as it executes?
• What protocols of interaction are used by communicating entities?
• What parts of the system run in parallel?
• How can the system’s structure change as it executes?
3.2 Elements, Relations, and Properties of the C&C Viewtype
A particular element may have a number of different kinds of associated properties including the name, type, and ports or roles of the element.
Other properties are possible and they should be chosen to support the usage intended for the particular component-and-connector view. For example, different properties might be chosen depending on whether the view is to be used as a basis for construction, analysis, or communication, as outlined below.
Here are some examples of typical properties and their uses:
• Reliability: What is the likelihood of failure for a given component or connector? This might be used to help determine overall system reliability.
• Performance: What kinds of response time will the component provide and under what loads? What kinds of latencies and throughputs can be expected for a given connector? This can be used (with other properties) to determine system properties such as latencies, throughput, and buffering needs.
• Resource requirements: What are the processing and storage needs of a component or connector? This can be used to determine if a proposed hardware configuration will be adequate.
3.2 Elements, Relations, and Properties of the C&C Viewtype
• Functionality: What functions does an element perform? This can be used to reason about overall computation performed by a system.
• Protocols: What patterns of events or actions can take place for an interaction represented component or connector? Protocols can be used to determine whether a particular interaction deadlock, whether specific components can legally participate in a given interaction, what are ordering constraints on an interaction, and how errors are handled.
• Security: Does a component or connector enforce or provide security features, such as encryption, audit trails, or authentication? This can be used to determine system security vulnerabilities.
3.3 What the C&C Viewtype Is For, and What It’s Not For
C&C views are not appropriate for representing design elements that do not have a run-time presence. For example, a class is not a component. A good rule of thumb is that if it doesn’t make sense to characterize the interface(s) of an element, it probably isn’t a component (although the inverse is clearly not necessarily true – there are many things with interfaces that are not components).
C
Java
HTML
Servicios Web
Corba
SQL
Represent an operation to be performed on the
elements of an object structure. Define a new operation
without changing the classes of the elements on which it
operates.
Aside from potentially improving separation of concerns, the visitor pattern has an additional advantage over simply calling a polymorphic method: a visitor object can have state. This is extremely useful in many cases where the action performed on the object depends on previous such actions.
Compose objects into tree structures to
represent part/whole hierarchies. The Composite lets
clients treat individual objects and compositions of
objects uniformly.
Muy usado en frameworks, hollywood inversion principle
The participants of the pattern are detailed below. Member functions are listed with bullets.
[edit] Subject
This abstract class provides an interface for attaching and detaching observers. Subject class also holds a private list of observers. Contains these functions (methods):
Attach - Adds a new observer to the list of observers observing the subject.
Detach - Removes an existing observer from the list of observers observing the subject
Notify - Notifies each observer by calling the notify() function in the observer, when a change occurs.
[edit] ConcreteSubject
This class provides the state of interest to observers. It also sends a notification to all observers, by calling the Notify function in its superclass (i.e, in the Subject class). Contains this function:
GetState - Returns the state of the subject.
[edit] Observer
This class defines an updating interface for all observers, to receive update notification from the subject. The Observer class is used as an abstract class to implement concrete observers. Contains this function:
Notify - An abstract function, to be overridden by concrete observers.
[edit] ConcreteObserver
This class maintains a reference with the ConcreteSubject, to receive the state of the subject when a notification is received. Contains this function:
Notify - This is the overridden function in the concrete class. When this function is called by the subject, the ConcreteObserver calls the GetState function of the subject to update the information it has about the subject's state.
When the event is raised each observer receives a callback. This may be either a virtual function of the observer class (called 'notify()' on the diagram) or a function pointer (more generally a function object or "functor") passed as an argument to the listener registration method. The notify function may also be passed some parameters (generally information about the event that is occurring) which can be used by the observer.
Each concrete observer implements the notify function and as a consequence defines its own behavior when the notification occurs.
The Strategy Design Pattern basically consists of decoupling an algorithm from its host, and encapsulating the algorithm into a separate class. More simply put, an object and its behaviour are separated and put into two different classes. This allows you to switch the algorithm that you are using at any time.
There are several advantages to doing this. First, if you have several different behaviours that you want an object to perform, it is much simpler to keep track of them if each behaviour is a separate class, and not buried in the body of some method. Should you ever want to add, remove, or change any of the behaviours, it is a much simpler task, since each one is its own class. Each such behaviour or algorithm encapsulated into its own class is called a Strategy.
When you have several objects that are basically the same, and differ only in their behaviour, it is a good idea to make use of the Strategy Pattern.. Using Strategies, you can reduce these several objects to one class that uses several Strategies. The use of strategies also provides a nice alternative to subclassing an object to achieve different behaviours. When you subclass an object to change its behaviour, that behaviour that it executes is static. If you wanted to change what it does, you'd have to create a new instance of a different subclass and replace that object with it. With Strategies, however, all you need to do is switch the object's strategy, and it will immediately change how it behaves. Using Strategies also eliminates the need for many conditional statements. When you have several behaviours together in one class, it is difficult to choose among them without resorting to conditional statements. If you use Strategies you won't need to check for anything, since whatever the current strategy is just executes without asking questions.
According to Strategy pattern, the behaviors of a class should not be inherited, instead they should be encapsulated using interfaces. As an example, consider a car class. Two possible behaviors of car are brake and accelerate.
Since accelerate and brake behaviors change frequently between models, a common approach is to implement these behaviors in subclasses. This approach has significant drawbacks: accelerate and brake behaviors must be declared in each new Car model. This may not be a concern when there are only a small number of models, but the work of managing these behaviors increases greatly as the number of models increases, and requires code to be duplicated across models. Additionally, it is not easy to determine the exact nature of the behavior for each model without investigating the code in each.
The strategy pattern uses composition instead of inheritance. In the strategy pattern behaviors are defined as separate interfaces and specific classes that implement these interfaces. Specific classes encapsulate these interfaces. This allows better decoupling between the behavior and the class that uses the behavior. The behavior can be changed without breaking the classes that use it, and the classes can switch between behaviors by changing the specific implementation used without requiring any significant code changes. Behaviors can also be changed at run-time as well as at design-time. For instance, a car object’s brake behavior can be changed from BrakeWithABS() to Brake() by changing the brakeBehavior member to:
brakeBehavior = new Brake();
1. Architectural Design Reviews
bring stakeholders together to determine feasibility of an architectural design to solve a particular problem
2. Product-line Engineering/Commonality Analysis
identify common requirements of a group of products
3. Rules-of-thumb and Automated Design Guidance
codify criteria and guidance for choosing appropriate architectural designs
4. Architecture-based Analysis
use analytic techniques to decide whether an architectural design will lead to a system that meets its requirements
Design Reviews:
Define a process of formal review of architecture that leads to list of issues that must be resolved
Prescribe guidelines for architectural description and rationale
May be done using corporate “design review boards” or by a product group itself
Used to produce corporate architectural assets
Checklists of issues to consider
Standard solutions to domain-specific problems
Case studies and examples
Measurement of costs/benefits
Architectural Missmatch