![Page 1: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/1.jpg)
Diseño de Software
![Page 2: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/2.jpg)
2
Ejemplo Diseño de Software
![Page 3: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/3.jpg)
3
Ejemplo Diseño de Software
![Page 4: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/4.jpg)
4
Ejemplo Diseño de Software
![Page 5: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/5.jpg)
5
Ejemplo Diseño de Software
![Page 6: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/6.jpg)
6
Ejemplo Diseño de Software
![Page 7: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/7.jpg)
7
Diseño de Software
• Puente entre mundos• Fronteras difusas a diferencia de otras disciplinas…
Implementaciones
Arquitectura/Diseño de Software
RequerimientosRequerimientos
![Page 8: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/8.jpg)
8
Frenado del Airbus A320
Sistema de Frenado Airbus
A320
Controlador de Aceleración de
Reversa
Motor de Reversa
Piloto
señales de prendido y apagado de motor
prendido y apagado de motor
señal de habilitado y deshabilitado de aceleración de reversa
Ruedas
Sensorgiro pulsos
Sensorpeso
Sensor alt
![Page 9: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/9.jpg)
9
Frenado del Airbus A320
Sistema de Frenado Airbus
A320
Controlador de Aceleración de
Reversa
Motor de Reversa
Piloto
señales de prendido y apagado de motor
prendido y apagado de motor
señal de habilitado y deshabilitado de aceleración de reversa
Ruedas
Sensorgiro pulsos
![Page 10: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/10.jpg)
10
Recordatorio: La relación entre el problema y solución
Dependencia de la implementación
DependienteIndependiente
Menos Info
Mas Info
Nivel de Completitu
d
Enunciado de la
Implementación
Enunciado delProblema
![Page 11: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/11.jpg)
11
Requerimientos
Requerimientos
Requerimientos
Design
Design
Design
SistemaSistema
SubsistemSubsistemaa
ComponenComponentete
Requerimientos y Diseño: Una Visión Top-Down
• Ojo: Tomar decisiones de bajo nivel es compatible con esta visión...
![Page 12: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/12.jpg)
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
![Page 13: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/13.jpg)
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
![Page 14: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/14.jpg)
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
![Page 15: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/15.jpg)
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?
![Page 16: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/16.jpg)
19
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
![Page 17: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/17.jpg)
20
Introducción a POO
![Page 18: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/18.jpg)
21
Documentación
![Page 19: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/19.jpg)
22
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.)
![Page 20: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/20.jpg)
23
Vistas y stackeholders• La metáfora de D.Garlan
These views are needed by the cardiologist…
…but will these views work for the orthopedist?
I do bones,
not hearts.
D.Garlan
![Page 21: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/21.jpg)
24
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
![Page 22: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/22.jpg)
25
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, ...
![Page 23: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/23.jpg)
26
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
![Page 24: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/24.jpg)
27
Alternando caracteres: Module View
Alternar mayúsculas con minúsculas a partir de un stream de caracteres
mainmain
splitsplit lowerlower upperupper mergemerge
configconfig input/outputinput/output
Modularización en función del a relación de uso
Referencias
ModuloUsos
“sofTWareArchitecture” =>“SoFtWaReArCiTeCtUrE”
![Page 25: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/25.jpg)
28
Alternando caracteres: C&C View
splitsplit
lowerlower
upperupper
mergemerge
Componentes y Conectores(Pipe & Filter)
Referencias
FilterPipeBinding
![Page 26: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/26.jpg)
29
Diagramas y vistas en UML
![Page 27: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/27.jpg)
30
Vista Modular (Diagrama de Clases)
Este ejemplo enfatiza la agrupación de métodos y datos en Este ejemplo enfatiza la agrupación de métodos y datos en clases además de asociaciones (dependencias estructurales) y clases además de asociaciones (dependencias estructurales) y relaciones de herencia y contiene-arelaciones de herencia y contiene-a
![Page 28: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/28.jpg)
31
Vista Modular (2)
Otros niveles de abstracción...Otros niveles de abstracción...
![Page 29: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/29.jpg)
32
Vista Run-Time (Estructura: componentes & conectores…Objetos y
links)
![Page 30: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/30.jpg)
33
Ejemplo de Vista Run-Time (Comportamiento)
![Page 31: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/31.jpg)
34
Ejemplo de Vista Run-Time (Estructura)
Poner ejemplo con multiples instancias de un tipoPoner ejemplo con multiples instancias de un tipo
![Page 32: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/32.jpg)
35
Ejemplo de Vista de Deployment (1)
![Page 33: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/33.jpg)
36
Ejemplo de Vista de Deployment (2)
![Page 34: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/34.jpg)
37
Mezclando Vistas
![Page 35: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/35.jpg)
38
Mezclando Vistas
![Page 36: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/36.jpg)
39
Mezclando Vistas
![Page 37: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/37.jpg)
40
Generalizando los tipos de vista
Mas allá de UML
![Page 38: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/38.jpg)
41
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
![Page 39: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/39.jpg)
42
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
![Page 40: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/40.jpg)
43
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
![Page 41: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/41.jpg)
44
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
![Page 42: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/42.jpg)
45
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
![Page 43: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/43.jpg)
46
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
![Page 44: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/44.jpg)
47
Componentes y Conectores: Componentes y Conectores: EjemplosEjemplos
![Page 45: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/45.jpg)
48
ElementosElementos
• 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
![Page 46: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/46.jpg)
49
UtilidadUtilidad• ¿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?
![Page 47: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/47.jpg)
50
UtilidadUtilidad
• ¿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?
![Page 48: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/48.jpg)
51
PropiedadesPropiedades
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
![Page 49: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/49.jpg)
52
PropiedadesPropiedades• 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
![Page 50: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/50.jpg)
53
Para lo que NO sirvePara 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
![Page 51: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/51.jpg)
54
ResumenResumenConectoresConectores
• 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
![Page 52: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/52.jpg)
55
Ejemplo: IP 2000 Siemens
Source: Applied Software Architecture (Nord, Hofmeister)(Escaneado)
![Page 53: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/53.jpg)
56
Visión Conceptual
![Page 54: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/54.jpg)
57
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
![Page 55: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/55.jpg)
58
Vista de Módulos
![Page 56: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/56.jpg)
59
Vista de MódulosDescomposición
![Page 57: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/57.jpg)
60
Vista de MódulosDescomposición
![Page 58: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/58.jpg)
61
Visión ConceptualC&C
![Page 59: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/59.jpg)
62
C&C y Comportamiento
Sebastian Uchitel
![Page 60: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/60.jpg)
63
Visión ConceptualC&C - Descomposición
![Page 61: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/61.jpg)
64
Visión ConceptualComportamiento
![Page 62: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/62.jpg)
65
Visión ConceptualC&C
![Page 63: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/63.jpg)
66
Visión ConceptualConector PacketPipe
![Page 64: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/64.jpg)
67
Visión de Ejecución
![Page 65: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/65.jpg)
68
Principios de Diseño
![Page 66: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/66.jpg)
69
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
![Page 67: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/67.jpg)
70
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 variabilidadAdvertencia: Estos principios han nacido con la extensibilidad y
la modificabilidad como atributos de calidad preponderantes
![Page 68: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/68.jpg)
71
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...
![Page 69: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/69.jpg)
73
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...
![Page 70: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/70.jpg)
74
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.).
![Page 71: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/71.jpg)
75
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
![Page 72: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/72.jpg)
76
Distintos tipos de abstracciones
![Page 73: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/73.jpg)
80
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...
![Page 74: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/74.jpg)
81
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
• Común– Cuando comparten datos comunes– ej. una variable global
• Externo– Cuando comparten aspectos impuestos externamente al diseño.– ej. formato de datos, protocolo de comunicación, interfaz de dispositivo.
• Control– Cuando un módulo controla la lógica del otro– ej. pasándole un flag de comportamiento).
• Estampillado (Stamp)– 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.
• Datos– Módulos se comunican a través de datos en parámetros– ej. llamado de funciones de otro módulo
• Mensajes– Módulos se comunican a través de mensajes. Posiblemente no se conocen
explícitamente
![Page 75: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/75.jpg)
82
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– Aspectos funcionales
![Page 76: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/76.jpg)
83
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
![Page 77: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/77.jpg)
84
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.
![Page 78: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/78.jpg)
85
Interface Segregation Principle
• “Many client specific interfaces are better than one general purpose interface”.
• Objetivo: Separar interfaces para minimizar dependencias.
![Page 79: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/79.jpg)
86
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.
![Page 80: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/80.jpg)
87
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
![Page 81: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/81.jpg)
88
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• Lógico
– Existe una categoría lógica que agrupa elementos aunque hagan cosas muy distintas
– ej. todas las rutinas de I/O• Temporal
– 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 • Procedural
– Agrupadas por pertenecer a una misma sequencia de ejecución o política.– ej. funciones que chequean permisos y abren archivos
• Comunicacional– Agrupadas por operar sobre los mismo datos.– ej. objetos, operaciones sobre clientes.
• Secuencial– Agrupadas porque el output de uno es el input de otro
• Funcional– Agrupadas porque contribuyen a una tarea bien definida del módulo
Ed dice que estos
son aceptables
![Page 82: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/82.jpg)
89
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.
![Page 83: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/83.jpg)
90
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
![Page 84: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/84.jpg)
91
The Open Closed Principle usando Polimorfismo
![Page 85: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/85.jpg)
92
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?• ...
![Page 86: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/86.jpg)
93
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
![Page 87: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/87.jpg)
94
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
![Page 88: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/88.jpg)
95
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. )
![Page 89: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/89.jpg)
96
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.
![Page 90: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/90.jpg)
97
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….
![Page 91: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/91.jpg)
98
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; } }
![Page 92: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/92.jpg)
99
Design Patterns
![Page 93: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/93.jpg)
100
Design Patterns
![Page 94: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/94.jpg)
101
Design Patterns
![Page 95: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/95.jpg)
102
Design Patterns
![Page 96: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/96.jpg)
103
Design Patterns
![Page 97: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/97.jpg)
104
Design Patterns
![Page 98: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/98.jpg)
105
Design Patterns
![Page 99: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/99.jpg)
106
Design Patterns
![Page 100: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/100.jpg)
107
Design Patterns
![Page 101: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/101.jpg)
108
Design Patterns
![Page 102: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/102.jpg)
109
Design Patterns
![Page 103: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/103.jpg)
110
Design Patterns
• Strategy
• Relación con el “Open-Close principle”
![Page 104: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/104.jpg)
111
Design Patterns
![Page 105: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/105.jpg)
112
Design Patterns
![Page 106: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/106.jpg)
113
Design Patterns
![Page 107: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/107.jpg)
114
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
![Page 108: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/108.jpg)
115
Evaluación de Diseños• 3 grandes tipos de evaluación
Código
Diseño
Requerimientos
Código
Diseño
Requerimientos
Código
Diseño
Requerimientos
![Page 109: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/109.jpg)
116
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
![Page 110: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/110.jpg)
117
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
![Page 111: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/111.jpg)
121
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
![Page 112: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/112.jpg)
122
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
![Page 113: Diseño de Software. 2 Ejemplo Diseño de Software](https://reader036.vdocumento.com/reader036/viewer/2022081421/5665b47a1a28abb57c91ce30/html5/thumbnails/113.jpg)
123
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étricaPropiedad 4: Monotonía» La métrica para una combinación de clases no puede dar menos que
ninguna de las métricas de las componentesPropiedad 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