Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos

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 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




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




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



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


• 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


• 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


• 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.



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


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


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


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


• 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 :


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


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


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


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


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.


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


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.


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


• 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


• 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


• 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

Documents

Diseño de Software basado en Patronescbustaca/docencia/DSBP-2016-03... · Meta-Modelos Software Architecture ... Cliente Conocimiento del Dominio Especificación Requerimientos