Diseo de Software

*

Ejemplo Diseo de Software

*

Ejemplo Diseo de Software

*

Ejemplo Diseo de Software

*

Ejemplo Diseo de Software

*

Ejemplo Diseo de Software

*

Diseo de Software

Puente entre mundosFronteras difusas a diferencia de otras disciplinasImplementacionesArquitectura/Diseo de SoftwareRequerimientos

*

Frenado del Airbus A320Sistema de Frenado Airbus A320Controlador de Aceleracin de ReversaMotor de ReversaPilotoseales de prendido y apagado de motor prendido y apagado de motorseal de habilitado y deshabilitado de aceleracin de reversaRuedasSensorgiropulsosSensorpesoSensoralt

*

Frenado del Airbus A320Sistema de Frenado Airbus A320Controlador de Aceleracin de ReversaMotor de ReversaPilotoseales de prendido y apagado de motor prendido y apagado de motorseal de habilitado y deshabilitado de aceleracin de reversaRuedasSensorgiropulsos

*

Recordatorio: La relacin entre el problema y solucinDependencia de la implementacinDependienteIndependienteMenos InfoMas InfoNivel de CompletitudEnunciado de la ImplementacinEnunciado del Problema

*

RequerimientosRequerimientosRequerimientosDesignDesignDesignSistemaSubsistemaComponenteRequerimientos y Diseo: Una Visin Top-DownOjo: Tomar decisiones de bajo nivel es compatible con esta visin...

Diseo de SoftwareLos Sistemas de Software Intensivo son entes complejosmillones de lneas de cdigo, variables, posibles estados, etc... Cmo lidiamos con la complejidad?Estructura y Abstraccin......s, pero cmo? qu abstracciones? qu relaciones?...Disear involucra estructurar la solucin utilizando abstracciones y relaciones entre las abstracciones apropiadas para poder:Documentar y Comprender la propuesta de solucinRazonar sobre su grado de adecuacin c.r.a los requerimientosComunicarlaImplementarlaVerificar/Validar el producto finalModificar/Adaptar la solucin en la medida que cambien los requerimientos

*

Diseo de SoftwareGua en la concepcin de productos de software (requerimientos complejos, integracin de componentes existentes, tecnologa, familias de productos, etc.)

Drivers: atributos de calidad/requerimientos no funcionales y restricciones de proyecto y tecnologaUsualmente en tensin

A diferencia del mundo de los requerimientos:Denota conceptos del mundo de la solucin (pero incluye fenmenos de la interfase mundo mquina)En general se describen propiedades localizadas (unidad, componente, mdulo) y son de naturaleza operacional

Objetivos de la Etapa de DiseoDescomponer el sistema en entidades de diseo ms chicasej qu paquetes, clases, mdulos, componentes...Determinar la relacin entre entidades.ej. identificar dependencias Fijar mecanismos de interaccinej. memoria compartida, RPC, llamadas a funcinEspecificar interfaces y funcionalidad de entidadesej. operaciones y sus aridades, descripcin formal/informal de comportamientoIdentificar oportunidades para el reusotanto top-down como bottom-upDocumentar todo lo anterior junto con la fundamentacin de las elecciones

Metodologa de Diseo: Visin MacroEl foco en el proceso de Diseo pasa:de los stakeholders externos (cliente, usuario, etc.) a los internos (desarrolladores, testers, etc.)de Qu y Porqu a Qu y CmoPasos MacroDiseo Arquitectnico (o Arquitectura)Diseo Detallado (o Diseo)Proceso iterativo Decisiones clave primeroej. Requerimientos no-funcionales crticosQu va a cambiar?

*

HistoriaSimula 67 Programming Language (1967) First appearance of object-oriented concepts

On the Criteria to Be Used in Decomposing Systems intoModules (Parnas, 1972) Information hiding

The Mythical Man-Month (Brooks, 1975) Importance of maintaining conceptual integrity of the design And concerns about the advisability of information hiding!

*

HistoriaProgramming-in-the-Large versus Programming-in-the-Small (DeRemer & Kron, 1976) Structuring a large collection of modules to form a system is anessentially distinct and different intellectual activity from that ofconstructing the individual modules. Correspondingly, webelieve that essentially distinct and different languages should beused for the two activities.

Designing Software for Ease of Extension and Contraction(Parnas, 1979) Program families Uses relation

*

HistoriaNo Silver Bullet: Essence and Accidents of Software Engineering (Brooks, 1985)There is no single development, in technology or management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.Must instead grow great designersAnd a concession to Parnas about information hiding! Foundations for the Study of Software Architecture (Perry & Wolf, 1992)Components, connectors, configurationsArchitectural styles

Design Patterns (Gamma, Helm, Johnson, Vlissides, 1995)

*

El Diseo Detallado y la Tecnologa de Construccin de Soluciones

Decisiones, patrones, notaciones, modelos y blueprints de diseo pueden estar fuertemente impactados por el paradigma de la tecnologa que se usa en la solucin, (especialmente si hablamos de un diseo detallado)

Dnde est el lmite entre codificar y disear?

Veremos el caso cuando hablemos de POO

*

Introduccin a POO

*

Documentacin

*

VistasLa descripcin de un sistema complejo no es unidimensional

Es clave saber cules son las vistas relevantes y vincularlas

Relevancia: depende del propsito (e.g., enunciar la misin de implementacin, anlisis de atributos de calidad, generacin automtica de cdigo, planificacin, etc.)

*

Vistas y stackeholdersLa metfora de D.GarlanD.Garlan

*

VistasLas vistas exponen atributos de calidad en diferente grado:Vista modular: portabilidadVista de deployment: performace, confiabilidad

Enfatizan aspectos e ignoran otros para que el problema sea abordable

Ninguna vista es EL diseo

*

Vistas Clsicas

Vista Modular: Cmo agrupamos el cdigo? mtodos, procedimientos, clases, librera, DLLs, APIs, paquetes, mdulos...usa, subclase, contiene, depende-de,...diagrama de clases y de paquetesVista Run-time o de Componentes y Conectores: Cmo son las entidades run-time?procesos, threads, objetos, protocolos, ciclos de vidase-comunica-con, bloquea, contiene, crea, destruye,... maquinas de estado, diagrama de secuencia y de colaboracin, diagrama de objetos, diagrama de componentesVista de Deployment (de Despliegue): Dnde residen las distintas partes?Recursos y repositorios adems de entidades dinmicas o estticasprocesos ejecuta-sobre server, cdigo de mdulos almacenado en directorio, equipo de trabajo desarrolla paquete,...diagrama de despliegue, ...

*

Ejemplo: Mdulos vs. ComponentesMdulos: entidad en tiempo de diseo. Enfatiza en encapsulamiento: information hiding e interfaces.

Componentes: tienen entidad en tiempo de ejecucin y de despliegue

*

Alternando caracteres: Module ViewAlternar maysculas con minsculas a partir de un stream de caracteresModularizacin en funcin del a relacin de usosofTWareArchitecture => SoFtWaReArCiTeCtUrE

*

Alternando caracteres: C&C ViewComponentes y Conectores (Pipe & Filter)

*

Diagramas y vistas en UML

*

Vista Modular (Diagrama de Clases)Este ejemplo enfatiza la agrupacin de mtodos y datos en clases adems de asociaciones (dependencias estructurales) y relaciones de herencia y contiene-a

*

Vista Modular (2)Otros niveles de abstraccin...

*

Vista Run-Time (Estructura: componentes & conectoresObjetos y links)

*

Ejemplo de Vista Run-Time (Comportamiento)

*

Ejemplo de Vista Run-Time (Estructura) Poner ejemplo con multiples instancias de un tipo

*

Ejemplo de Vista de Deployment (1)

*

Ejemplo de Vista de Deployment (2)

*

Mezclando Vistas

*

Mezclando Vistas

*

Mezclando Vistas

*

Generalizando los tipos de vistaMas all de UML

*

MduloConcepto proveniente de los 60s y 70s

Basado en la nocin de unidad de software que provee servicios a travs de una interfaz bien definida

La manera de modularizacin suele determinar caractersticas como modificabilidad, portabilidad y reuso

*

ElementosUn mdulo es una unidad de cdigo que implementa un conjunto de responsabilidades

Una clase, una coleccin de clases, una capa o cualquier descomposicin de la unidad de cdigo

*

RelacionesSe distinguen tres tipos de relaciones

es parte de que define la relacin entre un submdulo A y un mdulo B

depende de que define la dependencia entre dos mdulos A y B

es un que define una relacin de generalizacin entre un modulo especfico y otro ms general

*

Module Viewtype: utilidadAnlisisA partir de estas vistas, es posible realizar distinto tipos de anlisis Por ejemplo:

Trazabilidad de RequerimientosAnaliza como los requerimientos funcionales son soportados por las responsabilidades de los distintos mdulos

Anlisis de ImpactoPermite predecir el efecto de las modificacin del sistema

*

Module Viewtype: utilidadComunicacinEstas vistas pueden ser utilizadas para explicar las funcionalidades del sistema a alguien no familiarizado con el mismo

Distintos niveles de granularidad, presentan una descripcin top-down de las responsabilidades del sistema

*

Module Viewtype: cuando noEs dificultoso utilizar este tipo de vistas para realizar inferencias sobre el comportamiento del sistema durante su ejecucin

Dada su naturaleza, no es de mucha utilidad para la realizacin de anlisis de performance, confiabilidad u otras caractersticas asociadas al tiempo de ejecucinMltiples instancias de objetosRelaciones existentes slo en tiempo de ejecucin

*

Componentes y Conectores: Ejemplos

*

ElementosSon entidades con manifestacin runtime que consumen recursos de ejecucin y contribuyen al comportamiento en ejecucin del sistema

La configuracin del sistema es un grafo conformado por la asociacin entre componentes y conectores

Las entidades runtime son instancias de tipos de conector o componente

*

UtilidadCuales son los componentes ejecutables y como interactan?

Cules son los repositorios y que componentes los acceden?

Qu partes del sistema son replicadas y cuantas veces?

Cmo progresan los datos a los largo del sistema a medida que ste se ejecuta?

*

UtilidadQu protocolos de interaccin son usados por las entidades comunicantes?

Qu partes del sistema se ejecutan en paralelo?

Cmo la estructura del sistema puede cambiar a medida que se ejecuta?

*

Propiedades

ConfiabilidadPodemos usarlo para determinar la funcionalidad del sistema en su conjunto

PerformanceTiempo de respuesta / cargaTiempo de latencia y volumen de procesamiento

Recursos requeridosNecesidades de almacenamientoNecesidades de procesamiento

*

PropiedadesFuncionalidadFunciones mapeadas sobre el componente

ProtocolosPatrones de eventos o acciones que pueden tener lugar en una interacciones representada por el elemento

SeguridadEncriptaAuditaAutentica

*

Para lo que NO sirve

No se debe usar para modelar elementos de diseo que no tienen comportamiento runtime

Una clase no es un componente. Un componente no representa de ninguna manera una visin esttica de diseo

*

ResumenConectoresC&C viewtype define modelo consistente de elementos que tienen presencia runtime

C&C viewtype incluye informacin sobre los caminos de interaccin entre los componentes

Los componentes tienen interfaces llamadas ports

Los conectores tienen interfaces llamadas roles

*

Ejemplo: IP 2000 SiemensSource: Applied Software Architecture (Nord, Hofmeister) (Escaneado)

*

Visin Conceptual

*

Caractersticas del C&CLos componentes y conectores representan entidades de tiempo de ejecucinLos ports son las interfaces de comunicacin de los componentes agrupando seales de entrada y salida que siguen algn tipo de secuenciamiento (protocolo)Los conectores tienen como funcin mediar en la interaccin entre componentesLos conectores pueden representar formas complejas de interaccin ms all del simple call return sincrnicoEl conector debera especificar el protocolo bajo el cual los componentes interactan para cada uno de sus roles

*

Vista de Mdulos

*

Vista de MdulosDescomposicin

*

Vista de MdulosDescomposicin

*

Visin ConceptualC&C

*

C&C y ComportamientoSebastian Uchitel

*

Visin ConceptualC&C - Descomposicin

*

Visin ConceptualComportamiento

*

Visin ConceptualC&C

*

Visin ConceptualConector PacketPipe

*

Visin de Ejecucin

*

Principios de Diseo

*

Herramientas Conceptuales: PrincipiosDecomposicinDivide & Conquer (piezas conocidas y tratables)Separacin por niveles de abstraccin y/o mquinas virtualesSeparacin por aspectos, etc.ModularidadColeccin bien definida de partes e interacciones bien delimitadasOcultamiento de la informacinConfinar el impacto del cambio (de un mdulo)El ciente de un mdulo no debe conocer los detalles de diseo difciles o que pueden cambiar EncapsulamientoClara separacin de interface e implementacinMecanismos para no conocer ni usar ms de lo que la interface prometeAbstraccinFoco en lo esencial

*

Principios (Cont.)Explotar el Polimorfismotratamiento uniforme de una entidad que puede tener mltiples formasSustitucin Liskov/WingInversin de dependencia/controlDepender en abstracciones e interfaces en lugar de clases concretasSer invocado en lugar de invocar para reuso de abstracciones de controlSegregacin de interfacesUna sola responsabilidad (cohesion)Open-CloseDeteccin de puntos de variabilidadAdvertencia: Estos principios han nacido con la extensibilidad y la modificabilidad como atributos de calidad preponderantes

*

Estrategias de DescomposicinProblemas que sabemos resolver Ej. M. Jacksons Problem Frames: Control, Visualizacion, Correspondencia, etcPasos de ejecucinEj. Filtros de procesamiento de imagenesTempo de ejecucinEj. Acumulacin vs Utilizacin de InformacinFuncionalEj. Facturacin, Compras y SueldosModos de OperacinNormal vs ExcepcionalDatos Ej. Guiado por el modelo conceptual. Clientes, Ambulancias...

*

Ejemplo de Descomposicin

*

AdvertenciaDivide 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 composicin...

*

Descomposicin de software

MdulosAgrupa estructuras de datos y cdigo (y posiblemente otros mdulos) Entidad estticaA veces, separa Interfaz de ImplementacinInterfaz bien definidaA veces, es compilable de manera independienteEs una unidad de trabajo para desarrollo

ComponentesEntidades run-timeDescomposicin para cumplir con ciertos requerimientos no funcionales distintos a los mdulos (performance, distribucin, tolerancia a fallas, seguridad, adaptabilidad en run-time, etc.).

*

AbstraccinSuprimir detalles de implementacin permitePosponer ciertas decisiones de detalle que ocurren a distintos niveles de anlisisSimplificar el anlisis, comprensin y justificacin de la decisin de diseoTipos de AbstraccinProceduralej. Funciones, mtodos, procedimientosDatosej. TADs, modelos de componentesControlej. loops, iteradores, frameworks y multitasking

*

Distintos tipos de abstracciones

*

Information Hiding: EjemploDiseo de Message_Queue es una lista doblemente encadenada de Message_BlocksManejo eficiente de listas no acotadasEncapsulamiento y parametrizacin de otros aspectos en cabecerasincronizacin, asignacin de memoria y contador de referencias pueden ser agregados/intercambinads luego.

*

FrameworksUn diseo reutilizable / una implementacin parcialColeccin de mdulos o clases con mecanismos de interaccin y colaboracin prefijadascon implementaciones parcialesTarea del usuario: Implementar los huecos de manera especfica a la aplicacin siendo construidaTpicamente implementado en lenguajes OOCompletamos la implementacin con subclasesDiferencias con librerasInversion of Control or Hollywood Principle: Dont call us, well call youLas subclasses son invocadas desde el frameworkDesventajasCdigo en excesoDificultad de comprensin y seleccin de framework adecuado

*

InterfasesElementos ProvistosEj. mtodos, procedimientos, eventos

Elementos RequeridosEj. mtodos, procedimientos, eventos, objetos

Control de accesoEj. servicios ofrecidos para algunos clientes. Uid, groups, pivate/protected/public

*

AcoplamientoGrado de dependencia del mdulo sobre otros mdulos y en particular las decisiones de diseo que estos hacenGeneralmente correlaciona inversamente con cohesinBajo/Dbil acoplamiento y Alta CohesinAlto acoplamiento generalmente conllevaPropagacin de cambios cuando se altera un mduloMdulos son difciles de entender aisladamenteReuso y testeo de mdulos es difcil ya que se requieren otros mdulosAcoplamiento se incrementa siUn mdulo usa un tipo de otro mduloSi un mdulo usa un servicio de otro mduloSi un mdulo es un submdulo de otroBajo acoplamiento puede significar peor performanceTradeoff...

*

Tipos de AcoplamientoOrdenado de mayor a menor (segun E. Yourdon y L. Constantine...)ContenidoCuando un mdulo modifica o confa en el lo interno de otroej. acceso a datos locales o privadosComnCuando comparten datos comunesej. una variable globalExternoCuando comparten aspectos impuestos externamente al diseo.ej. formato de datos, protocolo de comunicacin, interfaz de dispositivo.ControlCuando un mdulo controla la lgica del otroej. pasndole un flag de comportamiento).Estampillado (Stamp)Cuando comparten una estructura de datos pero cada uno usa slo una porcinPaso de todo un registro cuando el mdulo slo necesita una parte.DatosMdulos se comunican a travs de datos en parmetrosej. llamado de funciones de otro mduloMensajesMdulos se comunican a travs de mensajes. Posiblemente no se conocen explcitamente

*

Information Hiding / EncapsulamientoEsconder las decisiones de diseo que pueden llegar a cambiarMinimizar el impacto de cambios futuros

Minimizar la informacin en la interfazInformacin a abstraer/esconderRepresentacin de datosAlgoritmosFormatos de entrada y salidaInterfaces de bajo nivelSeparacin de polticas y mecanismosDecisiones estructurales de ms bajo nivelAspectos funcionales

*

Programacin basada en interfasesComo usuario de una abstraccin, es fundamental no depender de los detalles de la implementacinEjemplosEstndares de jure vs. ImplementacionesEstndares de facto vs. variacionesEspecificacin vs. ImplementacinInterfases (OO) vs. Clases concretas

*

Dependency Inversion PrincipleDepend upon Abstractions. Do not depend upon concretions.Objetivo: Hacer un diseo ms flexible, enfocando el diseo a interfaces o clases abstractas, en lugar de a clases concretas.

*

Interface Segregation PrincipleMany client specific interfaces are better than one general purpose interface.Objetivo: Separar interfaces para minimizar dependencias.

*

Liskov Substitution PrincipleUn principio pensado para lenguajes de programacin con herencia...Subclasses should be substitutable for their base classesUna subclase puede ser usada donde su clase base es usada.

*

CohesinDel diccionariocohesin. (Del lat. cohaesum, supino de cohaerre, estar unido).1. f. Accin y efecto de reunirse o adherirse las cosas entre s o la materia de que estn formadas.cohesion. the action or fact of forming a united whole

Grado de [foco | cun bien trabajan juntos | coherencia | unin] que tienen los distintos elementos de un mduloAlta cohesin tiende a proveer:RobustezConfiabilidadReusabilidad ComprensibilidadTesteabilidadMantenibilidad

*

Tipos de CohesinOrdenado de peor a mejor (segn E. Yourdon y L. Constantine en los 70s)Coincidentalej. mis funciones de uso frecuente, utils.libLgicoExiste una categora lgica que agrupa elementos aunque hagan cosas muy distintasej. todas las rutinas de I/OTemporalAgrupadas por el momento en que se ejecutaranej. Funciones que atajan un error de output, crean un error en un log y notifican al usuario ProceduralAgrupadas por pertenecer a una misma sequencia de ejecucin o poltica.ej. funciones que chequean permisos y abren archivosComunicacionalAgrupadas por operar sobre los mismo datos.ej. objetos, operaciones sobre clientes.SecuencialAgrupadas porque el output de uno es el input de otroFuncionalAgrupadas porque contribuyen a una tarea bien definida del mduloEd dice que estos son aceptables

*

Single Responsibility PrincipleA class should have only one reason to change.

Objetivo: Obtener un alto grado de cohesin. Una clase debe tener una y solo una responsabilidad.

*

Extensibilidad y Open/Closed PrincipleLos requerimientos cambian. El diseo debe poder acomodar estos cambios.Un diseo extensible debe poder ser extendido con facilidad para incorporar nueva funcionalidadThe open/closed principleSoftware entities should be open for extension but closed for modificationLa idea es que la funcionalidad existente no debe tocarse para no romper cdigo existente, slo agregar.ej. Capacidad de lidiar con nuevos tipos de eventos

*

The Open Closed Principle usando Polimorfismo

*

Preguntas para la Buena ModularizacinHay una jerarqua de mdulos donde mdulos grandes estn descompuestos en ms pequeos?Cada mdulo es comprensible de manera independienteQu cambios de requerimientos podran implicar un cambio en el mdulo?The Single Responsability Principle: A module should have only one reason to changeQu impacto tiene un pequeo cambio en un mdulo a otros?Qu impacto tiene el mal funcionamiento de un mdulo sobre otros?Es excesivo el nmero de mdulos con que un mdulo se comunica (fan-out)?Es excesivo el nmero de mdulos que utilizan al mdulo (fan-out)? Interface Segregation Principle: Many specific interfaces are better than a general one.La interfaz de un mdulo revela demasiado? Podra abstraerse?Es evidente del cdigo cuando dos mdulos se comunican?...

*

Design PatternsGamma, Helm, Johnson & Vlissides, 1995 (Aka The gang of four)Soluciones esquemticas (buen diseo) a problemas recurrentes en el desarrollo de software OOCatlogo de 23 patrones: fenmeno de definicin terminolgicaLos Design Patterns se suponen que incorporan los principios de diseo que vimos

*

Design PatternsLa descripcin de un patrn de diseo debe incluir:Nombre: Debe ser significativoProblema: una descripicin del problema atacado por el patrnContexto: precondiciones bajo las que puede ocurrirFuerzas: restrciciones y cuestiones que la solucin debe tratarSolucin: relacin estticas y dinmicas entre los componentes del patrn. La solucin resuelve las fuerzas en el contexto dadoMsEjemplos de usoPatrones relacionadosOtros nombres usados del patrnEjemplo en cdigo

*

Design PatternsTipos de Patterns:De Creacin: soluciones flexibles para la creacin de instancias (e.g., abstract factory, singleton, etc.)Estructurales: soluciones de organizacin (herencia, composicin, agregacin, asociacin) de clases e interfaces para la extensibilidad y cambio (ej., composite, bridge, facade, adapter, etc.)De comportamiento: soluciones para la asignacin de responsabilidades y diseo de algoritmos. Muestran relacin esttica y comunicacin (ej., command, interpreter, mediator, observer, memento, etc. )

*

Design Pattern: SingletonNombre: SingletonProblema: Cmo definir una clase que debe tener una sola instancia accesible desde toda la aplicacin.Contexto: En algunas aplicaciones es importante que la clase tenga exactamente una instancia. Una aplicacin de procesamiento de ventas podra tratar con ventas de una sola compaa y necesitar datos de la misma almacenado en un objeto que sera el nico de la clase.Fuerzas: Usar una variable global no es un buen diseo. Otra opcin es no crear instancias sino usar mtodos y atributos estticos pero no es es una buena solucin para explotar el polimorfismo sobre sublases singleton y require un conocimiento global del tratamiento de la instancia como singleton.

*

Design Pattern: SingletonSolucin:Crear un mtodo esttico GetInstance(). Cuando accede por primera vez crea la instancia y devuelve una referencia. Las otra veces que es accedido retorna esa referencia. El patrn ofrece las siguientes ventajas y desventajas.

*

Design Pattern: SingletonSolucin 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; } }

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Design PatternsStrategy

Relacin con el Open-Close principle

*

Design Patterns

*

Design Patterns

*

Design Patterns

*

Cundo usar los Design PatternsHay un pattern para el problemaPropone una solucin mejor No hay una solucin ms simpleEl contexto del problema es consistente con el del patternLas consecuencias de usarlo son aceptables

*

Evaluacin de Diseos3 grandes tipos de evaluacin

*

Algunos Errores Comunes (1/2)Diseo Depth FirstSlo satisface algunos requerimientosRefinamiento directo de la especificacin de requerimientosPuede llevar a un diseo ineficienteOlvidarse de cambios a futuroDisear para extensin (y contraccin!)Disear demasiado en detalleIntroduce demasiadas restricciones a implementacines muy caro, no vale la penaDisear exclusivamente top-downPrimero los requerimientos crticos!No todo lo vamos a construir. Seleccin de COTS influye en la descomposicin

*

Algunos Errores Comunes (2/2)Diseo documentado ambiguamenteInterpretado incorrectamente en tiempo de implementacinDecisiones de diseo indocumentadasDiseadores son necesarios durante la implementacinDecisiones de diseo sin justificacin documentadaCambios mas adelante, aparentemente inofensivos, rompen el diseoDiseo inconsistenteMdulos funcionan, pero no encajanDivide to conquer, reunite to rule

*

Algunas reglas para cuando diseamos (1)Asegurarse que el problema est claroEn la medida de lo razonable, requerimientos claros, consistentes y completosQu antes que cmoEn la medida de lo posible, pensar en interfases primeroSeparar aspectos ortogonalesNo conectar lo que es independiente...Mantener las cosas lo ms simple posible, pero no ms.Diseos chetos tienden a tener mas errores, ser ms difciles de testear y ser mas ineficientesTrabajar a mltiples niveles de abstraccin...pero entender la relacin entre estos niveles

*

Algunas reglas para cuando diseamos (2)Pensar en la posiblidad de prototiparVertical vs. Horizontal, para evolucionar vs. para tirarMantener las representaciones consistentesUtilizar, en la medida de lo posible, patrones y esquemas conocidos No reinventar la ruedaSer auto-crticoUsar principios de diseo para evaluar el diseo No asumir que las reglas aqu expuestas sonAbsolutasCompletas

*

AntiPatterns

*

Ejes para crticas de diseoCoorreccin: fallas sintcticas y semnticasCompletud: tareas relevantes de diseo incompletasConsistencia: contradicciones internas del diseoOptimizacin: mejores opciones para los parmetros de diseoPertinencia: decisiones soportadas por requerimientosAlternativas: otras elecciones para una decisin de diseoEvolucin: asuntos que comprometen futuros cambiosPresentacin: uso torpe de la notacinHerramientas: otras herramientas que podran ser usadas en una decisin de diseoExperiencia: recordar experiencias pasadas relevantesOrganizacional: interses de otros stakeholders

*

Mtricas de Software1970s: Intentos para definir criterios cuantitativos simples de complejidad del sofwtare y otras calidades

Halstead Complexity MeasuresProgram Length = total operators + total operandsProgram Vocabulary = total distinct operators + total distinctoperandsVolume = Program Length * (log2Program Vocabulary)Difficulty = (total distinct operators/2) * (total operands/totaldistinct operands)Effort = Difficulty * Volume

McCabe Complexity MeasureCyclomatic Complexity = edges in call graph nodes in call graph + connected componentsCOCOMO modelo de costo para la estimacin de costo, esfuerzo y calendario

*

Crtica a las mtricas: Weyuker et.al.Weyuker y otros observaron que la mayora de las mtricas fallaban en cumplir algunas propiedades obvias y deseablesWeyuker defini 9 propiedades deseables

Propiedad 3: Detalles de Deseo son importantes Dos clases con la misma funcionalidad no deberan necesariamente tener el mismo valor para la mtricaPropiedad 4: Monotona La mtrica para una combinacin de clases no puede dar menos que ninguna de las mtricas de las componentesPropiedad 6: La interaccin de clases incrementa la complejidad El valor de la mtrica 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

*build systems compositionally from parts assure that the system conforms to the architecture and has the desired propertiesuse standard integration architecturesreuse codified architectural design expertisereduce costs through product-lines

**Si tuvieramos cambiaramos la interfaz, tendriamos mas garanteiasPoner grfico de sistema oseo y sistema circulatorioMencin a las palabras de Gamma : la diferencia entre la estructura del programa en tiempo de ejecucin y la estructura del cdigo (congelada en tiempo de compilacin como jerarqua de clases vs objetos comunicndose)Un mdulo puede no ser deployable. Un compoenente se replica un mdulo no Un mdulo pude vivir en muchos componentes.

Un mdulo se caracteriza enumerando sus responsabilidades

El estilo del mdulo determinar el tipo de dependencia

Cundo no usarlo?Qu tipo de notaciones conocen?3.1 Introduccin 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 ViewtypeEach 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 Its 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 systems 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 systems structure change as it executes?

*3.3 What the C&C Viewtype Is For, and What Its Not For

C&C views allow one to answer questions such as: What are the systems 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 systems 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 Its 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 doesnt make sense to characterize the interface(s) of an element, it probably isnt a component (although the inverse is clearly not necessarily true there are many things with interfaces that are not components).

*CJavaHTMLServicios WebCorbaSQL*Represent an operation to be performed on theelements of an object structure. Define a new operationwithout changing the classes of the elements on which itoperates.*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 torepresent part/whole hierarchies. The Composite letsclients treat individual objects and compositions ofobjects uniformly.*Muy usado en frameworks, hollywood inversion principle

The participants of the pattern are detailed below. Member functions are listed with bullets.[edit] SubjectThis 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] ConcreteSubjectThis 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] ObserverThis 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] ConcreteObserverThis 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 objects brake behavior can be changed from BrakeWithABS() to Brake() by changing the brakeBehavior member to:brakeBehavior = new Brake();

*1. Architectural Design Reviewsbring stakeholders together to determine feasibility of an architectural design to solve a particular problem2. Product-line Engineering/Commonality Analysisidentify common requirements of a group of products3. Rules-of-thumb and Automated Design Guidancecodify criteria and guidance for choosing appropriate architectural designs4. Architecture-based Analysisuse analytic techniques to decide whether an architectural design will lead to a system that meets its requirementsDesign Reviews:

Define a process of formal review of architecture that leads to list of issues that must be resolvedPrescribe guidelines for architectural description and rationaleMay be done using corporate design review boards or by a product group itselfUsed to produce corporate architectural assetsChecklists of issues to considerStandard solutions to domain-specific problemsCase studies and examplesMeasurement of costs/benefits

Architectural Missmatch