Professional Documents
Culture Documents
29
Tema III. DISEO ARQUITECTNICO (diseo de alto nivel) 14. Presentacin / La transicin del anlisis al diseo
Presentacin de IS2 Profesorado. Web de la asignatura Relacin con otras asignaturas: IS1 + IS2 Objetivos de la asignatura Programa de la asignatura: teora Programa de la asignatura: prcticas o Reestructuracin de equipos: alumnos nuevos, alumnos que no continan, etc. Documentacin entregada Descripcin de la prctica Formato de los documentos o Trabajo excesivo? Promedio de 58 horas/alumno dedicadas a la prctica en IS1 Programa de la asignatura: calendario Trabajo en equipo y dedicacin a la prctica Evaluacin de la asignatura Bibliografa La transformacin de modelos: del anlisis al diseo Ambos representan lo mismo (el sistema), pero desde una perspectiva diferente. Anlisis: estudiar los requisitos sin tomar decisiones de implementacin. o Representa un vista lgica del sistema que se desea construir. o No introduce artefactos de diseo o implementacin. o Su objetivo es especificar y clarificar los requisitos, y los conceptos utilizados en ellos. Diseo: establecer cmo debe construirse el sistema antes de construirlo. o Representa tambin el sistema que se desea construir: vista fsica del sistema. o Omite ms o menos detalles de implementacin, mientras que el modelo de anlisis omite la implementacin misma. o La diferencia es ms radical todava con el modelo del dominio, que no representa el sistema, sino el mundo real. Dos niveles de abstraccin en los modelos de diseo: o Diseo de alto nivel, diseo arquitectnico, diseo preliminar, arquitectura del software: la finalidad es plantear las grandes lneas de la solucin. o Diseo de bajo nivel, diseo detallado: la finalidad es describir en detalle cada una de las partes de la solucin. La transicin del anlisis al diseo no es fcil, inmediata ni automtica, ni tiene por qu serlo. o La estructura de la solucin no tiene por qu imitar la estructura del problema. o Entran en juego los requisitos NF, que no influyeron en el modelo de anlisis. Transformacin metdica pero no determinista, sino creativa. Relacin lgico-temporal entre el anlisis y el diseo El proceso de desarrollo iterativo e incremental posibilita la evolucin en paralelo de los distintos flujos de trabajo, y por tanto el trabajo en paralelo de distintos equipos de personas. No hay precedencia temporal estricta anlisis-diseo: o Son modelos interdependientes, pueden evolucionar en paralelo. o El anlisis es anterior al diseo slo dentro de cada trayectoria de versin. Las distintas versiones de los documentos/modelos producidas en cada iteracin no necesariamente son compatibles entre s: necesidad de organizar bien la documentacin.
Ingeniera del Software 2 Curso 2009-2010 El documento de diseo arquitectnico en el estndar ESA Lo que dice cada uno de los documentos: o ESA software engineering standards (PSS-05-0). o Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1). o Guide to the software architectural design phase (PSS-05-04). Nociones importantes: o Modelo fsico = modelo de componentes (descomposicin en subsistemas). o Diversas formas de reutilizacin: libreras, marcos, patrones o Criterios de calidad del diseo: nmero de elementos, grado de reutilizacin, profundidad de las jerarquas, cohesin y acoplamiento, modularidad Contenido del documento. El documento de diseo detallado en el estndar ESA Lo que dice cada uno de los documentos: o ESA software engineering standards (PSS-05-0). o Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1). o Guide to the software detailed design and production phase (PSS-05-05). Nociones importantes: o En diseo detallado, los elementos del diseo arquitectnico se descomponen en partes que tienen correspondencia directa con mdulos del lenguaje de programacin elegido. o Diseo defensivo: anticipar una lista de posibles problemas. o Omitir los aspectos de produccin: codificacin, pruebas, integracin, etc. Contenido del documento.
30
31
Ingeniera del Software 2 Curso 2009-2010 Una buena descomposicin modular es de importancia crtica, y lograrla constituye un reto de primer orden para el diseo. La descomposicin debe ser recursiva: los mdulos se descomponen a su vez en submdulos. o Cada mdulo, paquete o componente debe contener un nmero pequeo de submdulos (orientativo: 72), tanto en proyectos grandes como pequeos. o Los proyectos grandes se distinguen porque el nmero de niveles de anidamiento es mayor, no por tener ms submdulos en cada mdulo. La descomposicin perfecta (con pocas dependencias) es difcil, y no slo en ingeniera del sofware. Cmo lograrla de antemano, sin conocer an las dependencias entre componentes? o Ejemplo: el requisito de ajustar en un espacio pequeo los componentes de un aparato electrnico puede establecer fuertes dependencias entre ellos. Diseo arquitectnico = primer nivel de descomposicin: o Elegir subsistemas/componentes/mdulos y relaciones entre ellos. Criterios para la seleccin de una arquitectura (o estilo arquitectnico) Para un proyecto software dado puede haber varias arquitecturas apropiadas. Se elige una teniendo en cuenta los objetivos, que deben estar priorizados, ya que unas arquitecturas satisfacen mejor unos objetivos que otros. Criterios clsicos: o Extensibilidad: facilitar la adicin de nuevas caractersiticas (features). Hace ms complejo el diseo. Aporta mayor grado de abstraccin. Ejemplo: arquitectura que soporte no este juego de tablero particular, sino cualquier tipo de juego de tablero. Generalizar requiere invertir tiempo en el diseo: decidir qu tipo de extensiones pueden surgir, etc. La distincin de requisitos opcionales/deseables es til aqu, ya que seala hacia dnde apunta el desarrollo del sistema. o Modificabilidad: facilitar el cambio de requisitos. Es distinto del anterior, aunque requiera tcnicas similares. Ejemplo: posibilidad de cambiar las reglas del juego. o Simplicidad: hacer fcil de entender, hacer fcil de implementar. Difcil de coordinar con los dos anteriores. o Eficiencia: lograr alta velocidad o pequeo tamao. Otros criterios: reuso, escalabilidad, coste, requisitos no funcionales... Los requisitos no funcionales guan la seleccin de la arquitectura ms conveniente. Ej: o Rendimiento Componentes de grano grueso (reducen comunicaciones). o Mantenibilidad Componentes de grano fino (simplifican modificaciones). o Disponibilidad Componentes redundantes (si uno falla, otro sigue funcionando). Reutilizacin de diseos La mala costumbre de reinventar la rueda en ingeniera del software impide su desarrollo como disciplina de ingeniera. Una posible razn: organizacin inadecuada de arquitecturas, diseos y cdigo, que hace casi imposible la reutilizacin. Otras dificultades del diseo para el reuso: o Es ms difcil, requiere ms tiempo, pero los plazos siguen siendo ajustados. o Aumenta la complejidad, por tanto puede reducir el rendimiento. o La clasificacin y recuperacin de componentes requiere bsqueda por contenido. El uso de tecnologas de objetos y componentes facilita la reutilizacin: Microsoft MFC, controles VB, objetos COM, Java Beans, etc.
32
Ingeniera del Software 2 Curso 2009-2010 Sin fiabilidad no hay reusabilidad. Un componente reutilizado debera ser tan fiable (correcto y robusto) como la mquina sobre la que funciona. Tambin es esencial que estn perfectamente especificados los contratos de operacin del componente reutilizado. Eleccin de un componente para reutilizarlo: o Est documentado tanto como el resto de la aplicacin? o Hay que adaptar el componente o la aplicacin para poder usarlo? (proxy, recubrimiento). o Ha sido probado tanto como el resto de la aplicacin? Reutilizar tanto desarrollos (marcos, componentes) como ideas (patrones). Marcos de trabajo (frameworks) Al inventar el modelo de clases puede ser recomendable utilizar o desarrollar una coleccin de software preexistente que forma la base de una familia de aplicaciones similares: esta coleccin es lo que llamamos un marco de trabajo (framework). Un marco (anlogo a librera o toolkit) es una coleccin de clases interrelacionadas e incluidas en un paquete, que pueden ser usadas por varias aplicaciones diferentes. Las clases de un marco pueden ser abstractas, es decir, pensadas para usarse slo a travs de herencia. Ejemplo: Java Application Programming Interface (API) o Los paquetes de la aplicacin se relacionan con los paquetes marco a travs de herencia o agregacin (en realidad, asociacin o tipado de atributos). o Java Abstract Windowing Toolkit: las clases propias de la aplicacin heredan de clases awt, o agregan objetos awt en forma de atributos (el paquete awt no se modifica). Los marcos pueden ser de propsito general o especfico, y ambos tipos pueden encontrarse en una misma aplicacin: o General: sirven para un rango de aplicaciones muy variado (Java API) o Especfico: desarrollados a la vez que una aplicacin determinada, slo servirn normalmente para aplicaciones muy semejantes. Algunos creen que los marcos slo deberan desarrollarse si van a ser usados por un gran nmero de aplicaciones. No obstante, tambin hay ventajas (extensibilidad y mantenibilidad) en desarrollar un marco especfico en paralelo con una aplicacin, aunque no vaya a ser empleado en muchas otras aplicaciones. Ejemplos de marcos especficos: o Encounter: marco para juegos de rol en general. o Parchs: marco para juegos de tablero y fichas.
33
34
Ingeniera del Software 2 Curso 2009-2010 Nocin de interfaz La dependencia queda mejor definida si se establece con respecto a una interfaz. o De esta manera se establece una dependencia parcial o restringida: la dependencia ya no es hacia el componente/clase, sino slo hacia la interfaz. o Una misma interfaz puede ser realizada por varios componentes/clases. o Un componente UML equivale aproximadamente a un paquete Java. Dos formas alternativas de representacin: o Abreviada: icono circular. o Completa: rectngulo interface con compartimentos para atributos y operaciones. Caractersticas de una interfaz: o No contiene la implementacin de las operaciones (mtodos). o Puede contener tambin atributos (properties). Esto es nuevo en UML2. o Si un componente/clase realiza una interfaz, se compromete a implementar todas las operaciones definidos en la interfaz. Puede tener ms operaciones, pero no menos. o Dos interfaces ofrecidas por un mismo componente no son necesariamente disjuntas. Cmo se deben nombrar las interfaces: o Suelen nombrarse empezando por i (regla de estilo no obligatoria). o El nombre de la interfaz debe escogerse para que signifique adecuadamente el nombre comn (en singular) de todas sus instancias indirectas. Ejemplos: iCaminante: implementada por Hormiga, Robot(operaciones: avanzar, girar). iImprimible: implementada por Texto, Imagen (operaciones: imprimir). Definicin de interfaz: o De modo general (no slo en OO/UML, tambin en programacin estructurada) una interfaz es un conjunto de operaciones que ofrecen un servicio coherente. o Pero en OO/UML toda operacin se invoca sobre una instancia (salvo el caso especial de las operaciones estticas): Para usar las operaciones de la interfaz es necesario crear en el componente una clase que realiza (o implementa) la interfaz, y es necesario instanciar esta clase. Las operaciones se invocan sobre las instancias indirectas de la interfaz (instancias de la clase o clases compatibles con la interfaz). o As pues, una interfaz define un tipo (un tipo abstracto de datos) que proporciona un conjunto coherente de operaciones sobre las instancias compatibles con ese tipo. o Anloga a una clase abstracta con todas sus operaciones abstractas: no puede tener instancias directas. Cmo usar/instanciar las interfaces de un componente: o Problema: para crear una instancia indirecta de una interfaz necesito una operacin (las interfaces no tienen constructores), pero slo puedo utilizar la operacin si previamente ya tengo una instancia sobre la que invocarla. o Existen dos soluciones generales, ms una intermedia: Proporcionar una o ms clases pblicas compatibles, usar sus constructores. Proporcionar una fbrica y gestor de instancias (patrn AbstractFactory). Proporcionar la interfaz, pero no las clases concretas. o Ejemplo: componente GestinEmpleados: interfaz iEmpleado, clases pblicas EmpleadoFijo, EmpleadoTemporal, etc.: ms flexibilidad, menos encapsulacin (las clases se puede usar en cualquier lugar). interfaz iGestorEmpleados, clase pblica GestorEmpleados, clases de paquete (no visibles desde fuera del mismo) EmpleadoFijo, etc.: ms encapsulacin, menos flexibilidad (las operaciones de GestorEmpleados no pueden recibir ni devolver valores de tipo Empleado). interfaz iGestorEmpleados, interfaz iEmpleado, clase pblica GestorEmpleados clases privadas EmpleadoFijo, etc.: situacin intermedia (no se puede usar el constructor directamente, pero s el tipo abstracto iEmpleado).
35
Ingeniera del Software 2 Curso 2009-2010 Interfaces proporcionadas y requeridas Un componente/clase puede relacionarse de dos formas distintas con una interfaz: o El componente proporciona (realiza, implementa) la interfaz: interface realization. o El componente requiere (usa, depende de) la interfaz: interface usage. Es posible mostrar las interfaces requeridas sin mostrar quin las proporciona. Diagrama de componentes (o de estructura) Muestra principalmente componentes e interfaces, y relaciones entre ellos. Distintas formas de expresar el cableado (wiring) de componentes: o Dependencia y realizacin. o Uso y realizacin (conector de ensamblaje ball and socket). Cableado en rbol: cuando varios componentes requieren/proporcionan una misma interfaz. o Las dos representaciones (independiente/en rbol) son totalmente equivalentes. o Aunque en el diagrama se puede expresar que dos o ms componentes proporcionan la misma interfaz, habr que escoger uno de ellos en el diseo final (no si requieren). Anidamiento de componentes Los subcomponentes/clases que constituyen un componente se muestran en su interior. No hay lmite en el nmero de niveles de anidamiento, ni en el cableado interno. La correspondencia entre interfaces super/sub componente requiere: o Definicin de puertos para las interfaces externas del supercomponente. o Conectores de delegacin entre puertos e interfaces internas (dependencia). El sentido de la dependencia de delegacin siempre es: o Desde el puerto hacia la interfaz interna proporcionada. o Desde la interfaz interna requerida hacia el puerto. Un puerto tiene nombre y tipo (opcionales), puede contener varias interfaces proporcionadas y requeridas, y puede delegar hacia/desde varias interfaces internas. Pero debe mantenerse una definicin consistente de los puertos, sin mezclar interfaces que tengan poco que ver entre s. Un puerto UML equivale aproximadamente a una clase pblica de un paquete Java (patrn Fachada). Diagrama de despliegue (arquitectura fsica del sistema) Un nodo representa un recurso computacional en tiempo de ejecucin. Pueden estar anidados. o Los nodos se interconectan mediante rutas de comunicacin, incluso con multiplicidad. o Pueden representar tanto dispositivos hardware como entornos de ejecucin software. Un artefacto representa una pieza fsica de informacin localizada en un nodo. o Ejemplos: hoja de estilos, script, componente ejecutable, base de datos, DLL, etc. o La localizacin puede indicarse mediante anidamiento o con una dependencia deploy. o La relacin de un artefacto con componentes u otros elementos lgicos (uno o ms) puede indicarse con una dependencia manifest.
36
37
38
39
Ingeniera del Software 2 Curso 2009-2010 Arquitectura de sistema de eventos. o En esta arquitectura la aplicacin es un conjunto de componentes que esperan a que ocurra un evento que les afecte. o Ejemplos: procesador de textos, aplicacin interactiva en general. Arquitectura de mquina virtual En esta arquitectura se define un lenguaje especial, con el que es posible escribir diversos programas, que son interpretados y ejecutados en la mquina virtual. La mquina virtual requiere la construccin de un intrprete, que interpreta expresiones (programas completos, partes de programa, expresiones primitivas). Adecuada para gramticas pequeas y velocidad poco relevante. Como hay que construir un intrprete del lenguaje, esta arquitectura rinde ms si hay que escribir varios programas o aplicaciones. Ejemplos: intrprete de instrucciones de ensamblaje de ordenadores; intrprete de frmulas matemticas para clculo numrico; programador de calefaccin; intrprete SQL. Ventaja: facilidad de generar nuevas aplicaciones en el lenguaje de propsito especial. Esta arquitectura puede ser ventajosa para el procesamiento de scripts, escritos en un lenguaje accesible para usuarios de formacin media. Arquitecturas de repositorio Son arquitecturas construidas principalmente en torno a los datos. Desacoplan los componentes clientes de los que proporcionan persistencia y gestin de datos. Ejemplos: o Sistema de transacciones contra una base de datos. o Entornos de desarrollo interactivos (IDEs). o Editores de texto, aplicaciones ofimticas. o Repositorio (en sentido restringido): acceso uniforme a una coleccin de BD. Es adecuada cuando el procesamiento es despreciable frente al formateado y almacenamiento de los datos; extensibilidad y modificabilidad en la estructura de datos. Peligro: que haya una gran candidad de procesamiento escondido entre los datos; complicar la base de datos con procedimientos ad hoc almacenados que pervierten el diseo limpio de la aplicacin. Arquitectura en capas o niveles (Layered Architectures) Una capa arquitectnica es una coleccin coherente de artefactos software (componentes). Objetivo: reducir dependencias entre artefactos situndolos en capas lgicas: o cada capa depende del servicio prestado por la capa inferior... o y presta un servicio a la capa superior. La construccin de aplicaciones en capas puede simplificar (o complicar) el trabajo. o Ventajas: simplicidad conceptual, reutilizacin, mantenimiento... o Desventajas: mayor coste de desarrollo inicial. Ejemplos: o Arquitectura cliente-servidor (2 capas). Problema: alto grado de interdependencia. Solucin: arquitectura en tres capas, insertar una capa intermedia que las asle; puede seleccionar dinmicamente un servidor entre varios, por ejemplo. o Modelo OSI (7 capas). o Juegos interactivos: representacin grfica, definicin del juego, ejecucin.
40
Ingeniera del Software 2 Curso 2009-2010 Arquitectura MVC (Model - View - Controller) Fue un concepto introducido por los creadores del lenguaje Smalltalk en los aos 80, con la idea de agrupar las clases en funcin del rol que desempean en la aplicacin. Versin original (sistemas antiguos sin GUI propiamente dicha): o Modelo: modelo conceptual, clases resultantes del anlisis (refinadas en diseo). o Vista: clases dedicadas a la presentacin (grfica) de la aplicacin (interfaz de salida). o Controlador: gestiona los mensajes recibidos del usuario (interfaz de entrada) y los traduce a mensajes comprensibles por el modelo conceptual; es responsable, tambin, del flujo de la aplicacin y del control de la navegacin entre ventanas. Analoga: Vista: los ojos del usuario, Controlador: sus manos, Modelo: su mente. Versin moderna (adaptada a la unificacin de interfaces de entrada/salida en el GUI): o Modelo: idem. o Vista: engloba View original y la parte de interfaz de entrada de Controller, y se aade la posibilidad tecnolgica de generarla mediante aplicaciones de generacin de GUI. o Controlador: centrado en el control interno de la aplicacin, gestiona los mensajes recibidos de los distintos componentes del GUI, los verifica (correctos/completos), los traduce para el modelo conceptual, y aplica las reglas de negocio que estn definidas. Ni la versin original ni la moderna son verdaderas arquitecturas en capas, ya que las dependencias cruzan la capa intermedia. Ahora bien, esto no es necesariamente un defecto. Variantes: RUP/BCE (Boundary-Control-Entity), PAC (Presentation-Abstraction-Control), Model-2 de Java, etc. Algunas de estas variantes son verdaderas arquitecturas en capas (eliminan la dependencia Vista-Modelo, todo pasa a travs del Controlador). Consecuencias: o (+) Fcil de explicar y entender. o (+) Reduce dependencias y potencia la reutilizacin (cambiar interfaz sin tocar el resto). o (+) Permite dividir el trabajo en base a distintos roles (el diseador grfico no tiene por qu saber cmo se ha implementado el resto de componentes). o () No es pura: las dependencias cruzan varias capas. o () Complejidad (valorar costes). Arquitectura en cuatro capas (Four Layer Achitecture) La factorizacin propuesta por MVC facilita la reutilizacin (separando representacin, modelo y control), pero no cubre aspectos de bajo nivel (protocolos de red, persistencia...). sta combina arquitectura en capas pura con MVC para aprovechar las ventajas de ambas: o Vista: Vista del MVC. o Modelo de Aplicacin: Controlador del MVC. o Modelo Conceptual: Modelo del MVC. o Infraestructura: Alberga clases que abstraen mecanismos de conexin con dispositivos o sistemas en los que se apoya la aplicacin: acceso a BDs, directorios, puerto serie, etc. Todos los mensajes que llegan al controlador lo hacen a travs del interfaz, y la interfaz se comunica con el modelo slo a travs del controlador. Consecuencias: o (+) Ventajas de MVC y Capas. o (+) Permite independizar la aplicacin de la representacin y los mecanismos de persistencia (en general, plataforma). o () Ms restrictivo (ej. no existe comunicacin directa interfaz-modelo).
41
Ingeniera del Software 2 Curso 2009-2010 Arquitectura en Tres Escalones (Three-Tier Architecture) Propsito: optimizar el uso de componentes y recursos en aplicaciones distribuidas mediante la distribucin de la funcionalidad del sistema. Solucin: arquitectura que divida la responsabilidad en tres escalones de procesamiento. o Cliente: Destinado a interpretar y mostrar la informacin. Es el componente donde se lleva a cabo la interaccin usuario-aplicacin. De este modo, deber optimizarse para la visualizacin de la interfaz de usuario y proporcionar una interfaz fsica de red con capacidad suficiente (clientes ligeros: thin client). o Servidor Departamental (o servidor de dominio): Posee mayor capacidad de computacin que los clientes, as como ms memoria y disco. Estos recursos le permiten actuar como cach de informacin compartida entre varios clientes, reduciendo la necesidad de almacenamiento en los mismos, as como el trfico hacia el Servidor Empresarial. Tambin mejora la seguridad. o Servidor Empresarial (o servidor de negocio, o servidor de persistencia): Tpicamente un servidor de altas prestaciones (mainframe). Aunque no suele poseer la ltima tecnologa (tpicamente heredados, legacy systems), poseen altas prestaciones en cuanto a capacidad y velocidad en el proceso de transacciones. Consecuencias: o (+) Proporciona la mejor arquitectura para nuevos desarrollos, aprovechando los sistemas existentes (amortizacin de inversiones: servidores heredados). o (+) Permite desacoplar los clientes del servidor empresarial y reduce las necesidades de los clientes (clientes ligeros). o (+) Reduciendo las dependencias entre el servidor departamental y el empresarial, permite la retirada/renovacin paulatina del segundo. o () Complejidad (valorar costes). o () Mayor carga de administracin. Uso combinado de arquitecturas Es normal que una misma aplicacin use distintas arquitecturas (en distintos niveles de descomposicin) para resolver distintos aspectos del mismo problema. Ejemplo: Parchs. o Base de datos para Partidas realizadas. o Procesos paralelos para los Jugadores (humanos, artificiales). o Sistema de eventos para el Control General. Las distintas arquitecturas estudiadas tienen muchos puntos en comn: o Mquina virtual Arquitectura multicapa. o Repositorio de datos Cliente-servidor. o Sistema de eventos Procesos paralelos. o Tuberas y filtros Procesos paralelos, etc.
42
43
Ingeniera del Software 2 Curso 2009-2010 1. Qu caracteriza el diseo orientado a objetos frente al diseo basado en objetos? Por qu es insuficiente el diseo basado en objetos desde el punto de vista de la mantenibilidad? Cmo ayuda la orientacin a objetos a reducir la complejidad de un programa? Uso de herencia y polimorfismo frente a meras clases y asociaciones. El diseo basado en objetos es es insuficiente porque es incapaz de hacer frente a los cambios en los requisitos. La complejidad depende de la cantidad de lgica de ramificacin condicional que contenga el cdigo. En la orientacin a objetos se sustituyen las ramificaciones condicionales por invocaciones polimrficas, porque facilitan el mantenimiento del cdigo cuando se aadan nuevos tipos de datos/objetos.
44
2. Describa brevemente en qu consiste el mtodo propuesto por Wayne Haythorn para obtener clases magnficas, y qu beneficios aporta. Cmo se aplica el mtodo para evaluar y comparar diseos? Elaborar una lista de cambios previsibles. Disear clases abstractas (interfaces) que encapsulen la variabilidad identificada y as defiendan el diseo frente a ella. Medir y comparar las modificaciones que requerira cada diseo para hacer frente a esos cambios.