You are on page 1of 16

Ingeniera del Software 2 Curso 2009-2010

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

Ingeniera del Software 2 Curso 2009-2010

31

15. Introduccin al diseo arquitectnico


Qu es la arquitectura de software? Analoga: proceso de construccin de un puente... (proceso de decisiones similar en IS). o Anlisis de requisitos decidir dnde debe comenzar y terminar el puente, y qu tipo de cargas debe soportar. o Diseo arquitectnico elegir entre puente colgante, puente volado, puente tensado, u otro tipo que satisfaga los requisitos: esto son arquitecturas de puente (elegir un estilo arquitectnico es elegir un tipo de solucin). Diseo encontrar soluciones a problemas complejos. o Fundamentalmente mediante la descomposicin de la solucin, es un proceso iterativo. o Arquitectura = tipos de elementos en la solucin, tipos de relaciones entre ellos. Interaccin arquitectura-requisitos Es probable que la descomposicin del sistema en subsistemas (arquitectura) influya en la forma de estructurar los requisitos, para lograr una ms clara correspondencia entre los requisitos y el diseo. El anlisis y el diseo se entrelazan en un proceso iterativo. El diseo puede por tanto influir en el anlisis, pero cuidando de no influir en exceso. Madurez de la arquitectura del software Las arquitecturas limpias y elegantes facilitan implementaciones libres de defectos y son ms fciles de mantener, extender y reutilizar. Aunque tenga mucho de arte, la arquitectura de software debe superar la inmadurez: o Antes: creacin de diseos ad hoc a partir de la nada, reutilizacin de diseos encontrados por casualidad. o Ahora: diseo metdico y disciplinado. El diseo de software metdico y disciplinado consiste en descomponer la solucin en elementos y relaciones entre elementos (metdico, pero no automatizable...). La arquitectura se refiere principalmente a la descomposicin del software en mdulos relacionados entre s (arquitectura lgica, arquitectura del software), y secundariamente a su distribucin entre las partes fsicas (arquitectura fsica, arquitectura del hardware). La especificacin clara de arquitecturas software, importante para todas las aplicaciones, es indispensable en el trabajo en equipo: modularizacin y ensamblaje. Cmo lograr una descomposicin modular eficaz? Mxima cohesin, mnimo acoplamiento. o Cohesin dentro de un mdulo: grado de comunicacin entre sus elementos. o Acoplamiento entre mdulos diferentes: grado de comunicacin entre ellos. Alta intra-cohesin, bajo inter-acoplamiento = minimizar dependencias. o Estas dos caractersticas hacen la arquitectura mucho ms fcil de modificar, ya que los cambios slo tienen efectos locales. Por lo tanto... disear para el cambio, disear para la extensin (= mantenibilidad). Descomposicin modular recursiva No es difcil escribir pequeos programas. El principal problema de las aplicaciones grandes es la complejidad: no tanto el nmero de lneas de cdigo, sino sus interrelaciones (dependencias entre elementos). La mejor arma contra la complejidad es la descomposicin modular, de tal forma que cada mdulo sea como un pequeo programa, tambin en su grado de dificultad.

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

Ingeniera del Software 2 Curso 2009-2010

34

16. Modelado arquitectnico con UML


Nociones de mdulo, paquete, subsistema, componente y clase Cuando hablamos de descomposicin arquitectnica, estos cinco trminos son prcticamente sinnimos, ya que todos ellos responden a la siguiente definicin: o un X es una unidad autnoma, reemplazable y reutilizable, habitualmente ejecutable, o que encapsula el estado y comportamiento de una parte de la implementacin de un sistema, o que proporciona una o ms interfaces a otros Xs y requiere una o ms interfaces de otros Xs, o y que puede a su vez descomponerse en uno o ms Xs. No obstante, en determinadas metodologas, lenguajes o entornos tecnolgicos, estos trminos se usan a menudo con matices que pueden distinguirlos: o Mdulo tiene un aire ms de diseo estructurado y es menos frecuente usarlo en el paradigma orientado a objetos. o Paquete se usa para designar un contenedor totalmente genrico, que define un espacio de nombres y es utilizado para organizar los elementos de un modelo (puede contener, por ejemplo, requisitos, clases, actores, casos de uso, diagramas, colaboraciones, etc.). o Subsistema se usa para designar los elementos resultantes del primer nivel de descomposicin de un sistema (un sistema se descompone en subsistemas). En UML1 un subsistema es un tipo especial de paquete. En UML2 un subsistema es un tipo especial de componente. o Componente se usa para designar los elementos resultantes del segundo nivel de descomposicin (un subsistema se descompone en componentes) y hasta el penltimo nivel (componente de nivel 2, componente de nivel 3, ... componente de nivel n-1). o Clase se usa para designar los elementos resultantes del ltimo nivel de descomposicin (un componente se descompone en componentes, o finalmente en clases). Aqu clase significa clase de implementacin, es decir, representacin simblica de un fragmento de cdigo en un lenguaje de programacin orientado a objetos. No olvidar que clase, en general, no siempre representa un fragmento de cdigo: por ejemplo, clases de dominio, que representan conceptos del entorno del sistema; o clases arquitectnicas, que an deben ser refinadas, y tal vez descompuestas en otras clases, para llegar a las clases de implementacin. Algunos autores (por ejemplo, UML1) reservan el trmino componente para el penltimo nivel de descomposicin, utilizando para los dems el trmino subsistema (un sistema se descompone en subsistemas, que a su vez se descomponen en subsistemas o finalmente en componentes, que a su vez se descomponen en clases). Es obvio que aqu no hay ninguna diferencia conceptual sino meramente terminolgica. En UML 1 hay que tener en cuenta que un componente no puede anidar otros componentes, por lo que es necesario usar subsistemas (paquetes) hasta llegar al penltimo nivel. Esta restriccin ha desaparecido en UML 2. En el estndar ESA se utiliza el trmino componente en el sentido genrico explicado ms arriba: todo son componentes, desde el nivel ms alto (subsistemas) hasta el ms bajo (clases). Esto hay que tenerlo en cuenta a la hora de adaptar este estndar a la terminologa UML. Nocin de dependencia La clave para lograr una descomposicin modular eficaz es minimizar las dependencias. La relacin de dependencia (representada como una flecha discontinua) significa que: o el elemento dependiente requiere la presencia del elemento independiente, y o los cambios en el elemento independiente pueden afectar al elemento dependiente. La dependencia puede establecerse entre cualesquiera dos elementos (componentes, clases).

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

Ingeniera del Software 2 Curso 2009-2010

37

17. Herramientas de modelado UML (laboratorio)


Instalacin, licencias y requisitos hardware y software Instalacin: http://www.altova.com/download/umodel/uml_tool_enterprise.html Licencias Requisitos hardware y software Visin general de la herramienta Creacin de un proyecto Modelos, vistas y diagramas Organizacin en paquetes Exportacin de diagramas Diagramas de componentes (o de estructura) y de despliegue Componentes, Interfaces, Cableado, Anidamiento, etc. Ejercicio prctico: representar los diagramas de la unidad anterior. Otras herramientas alternativas Visio: http://www.softwarestencils.com/uml/index.html Telelogic Tau swReuser

Ingeniera del Software 2 Curso 2009-2010

38

18. Vistas arquitectnicas


Por qu es necesario hablar de vistas arquitectnicas Recapitulacin (IEEE Std 1471-2000): la arquitectura del software es o la organizacin fundamental de un sistema o encarnada en sus componentes, o las relaciones entre ellos y con el entorno, o y los principios que orientan su diseo y evolucin. La arquitectura de software no puede reducirse al aspecto de la descomposicin del software en mdulos (de cdigo) interrelacionados. o Por el contrario, necesitamos distintos tipos de planos para representar distintos aspectos (concerns) del sistema en desarrollo. No basta un nico lenguaje descriptivo (por ejemplo, mdulos de cdigo y relaciones entre ellos). o La arquitectura es la parte del diseo que trata de dominar la complejidad de todos los aspectos del sistema en desarrollo, no slo la descomposicin del cdigo en mdulos. o La arquitectura debe tener muy en cuenta todos los requisitos no funcionales. Las diferentes vistas de un sistema software no pueden obtenerse como proyeccin (subconjunto) de una vista global. La analoga con las vistas en arquitectura civil es limitada. o Por ejemplo, podemos considerar que en un nico plano es posible representar la estructura mecnica de un edificio, as como el saneamiento, las conducciones elctricas, el mobiliario, etc. De esta nica representacin global es fcil obtener representaciones parciales mediante proyeccin: el subsistema elctrico, etc. o En cambio, no existe una nica vista o plano de un sistema informtico, del que se puedan obtener por proyeccin, por ejemplo, la vista de ejecucin (los procesos) y la vista de implementacin (el cdigo). Por lo tanto, necesitamos integrar distintas vistas para expresar la arquitectura de un sistema. Segn IEEE Std 1471-2000, cada punto de vista est dirigido a un conjunto de stakeholders, trata aspectos bien determinados, y usa lenguajes y tcnicas de modelado especficos. No define ningn punto de vista en particular, tan solo especifica cmo hay que definirlos. Ejemplo: el estndar ODP (Open Distributed Processing) define cinco puntos de vista para la arquitectura: Enterprise, Information, Computational, Engineering, Technology. El modelo de 4+1 vistas (Philippe Kruchten) Se ha hecho clsica la representacin de la arquitectura de un sistema mediante 4+1 vistas: o Vista lgica (o conceptual) o Vista de proceso (o de ejecucin) o Vista de desarrollo (o de implementacin) o Vista fsica (o de despliegue) o Vista de casos de uso: unifica (supuestamente) las otras cuatro vistas y sus relaciones. En cada vista podemos distinguir diferentes caractersticas: o Aspecto del sistema tratado de modo especial en la vista (complementario a los dems). o A quin va dirigida de modo particular esta vista (stakeholders). o Tipos de requisitos relacionados ms estrechamente con la vista. o Notacin: elementos y conectores esenciales en el lenguaje diagramtico de cada vista. No todas las vistas son igualmente necesarias e importantes en cada proyecto. Relaciones entre las cuatro vistas: o VL VP: identificar las clases que tendrn un hilo de control propio (clases activas). o VL VD: descomponer en subsistemas de clases estrechamente relacionadas (minimizar dependencias); aparecen nuevas clases de diseo que no son conceptuales. o VP y VD VF: tener en cuenta los requisitos no funcionales de la vista fsica. En proyectos grandes no debe esperarse una correspondencia 1-1 entre las distintas vistas.

Ingeniera del Software 2 Curso 2009-2010

39

19. Estilos arquitectnicos


Clasificacin de arquitecturas segn Shaw & Garlan Estas arquitecturas pueden ser adecuadas para un problema dado, o al menos pueden dar ideas para la modularizacin. Cada estilo promueve de distinta forma la extensibilidad, modificabilidad, simplicidad y eficiencia. o Ejemplo: aadir nuevos filtros o tuberas. Tambin se los denomina en algunos libros patrones arquitectnicos (pero no confundir con los patrones de diseo, que son de ms bajo nivel y orientados a la programacin). Arquitecturas de flujo de datos (Dataflow Architectures) Adecuadas para aplicaciones que se entienden mejor en trminos de datos que fluyen entre unidades de procesamiento: procesamiento distribuido con serializacin. Los DFDs ilustran esta perspectiva de transformaciones funcionales. o Cada unidad de procesamiento es diseada con dependencias bien definidas respecto de las otras: sus entradas/salidas de datos. o Los datos tienen una fuente/origen y terminan en uno o varios sumideros/destinos. o No hay correspondencia inmediata entre DFDs y modelos de clases; las unidades funcionales podran ser objetos, o podran ser mtodos. o El tiempo no est representado en los DFDs las flechas no indican secuencia temporal. o Analoga con los sistemas lineales de procesamiento de la seal. o Ejemplo: simulacin de clientes y cajeros; clculo del IRPF. Arquitectura de tuberas y filtros (pipe and filter). o Los elementos de proceso (filtros) aceptan una corriente de entrada (secuencia de datos uniformes) en cualquier momento, y producen corrientes de salida. o Cada filtro debe ser independiente de los otros. Ventajas: modularidad. Arquitectura secuencial por lotes (batch sequential). o Los filtros trabajan con lotes de datos, y la transaccin tpicamente implica el procesamiento del lote completo, en contraste con el procesamiento continuo de la arquitectura pipe and filter. Ha sido la forma ms comn de expresar arquitecturas, no desaparecer de inmediato. Arquitecturas de componentes independientes Consiste en componentes que operan en paralelo (en principio) y se comunican entre ellos de tiempo en tiempo. Ejemplo: WWW, con miles de servidores y millones de navegadores. Arquitectura cliente-servidor. o El componente servidor sirve las necesidades del cliente, expresadas como peticiones. o La relacin c/s es muy natural en ingeniera del software con equipos de trabajo separados: diferentes paquetes de clases encargados a personas o grupos de desarrollo distintos, con relaciones c/s entre paquetes. o No es necesario que los mdulos software se encuentren en partes hardware distintas. o Ventaja: bajo acoplamiento. Problema: los servicios requeridos se encuentran en distintos estadios de desarrollo a medida que progresa el proyecto. o Un componente acta ms eficazmente como servidor cuando su interfaz es estrecha, es decir, la interfaz (bsicamente, una coleccin de funciones) no contiene partes innecesarias, est recogida en un nico sitio, y est claramente definida. Arquitectura de procesos paralelos (Parallel Comunicating Processors). o Los componentes son procesos que se ejecutan en paralelo (threads en Java). o Debe usarse si resulta ms natural que el modelado sin paralelismo. o Ejemplo: sesiones de conexin a un sistema bancario. o Precaucin: no adoptar decisiones prematuras acerca de la concurrencia de un sistema.

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

Ingeniera del Software 2 Curso 2009-2010

43

20. Qu es diseo orientado a objetos (artculo)


Lectura obligatoria y examen Wayne Haythorn. What is Object-Oriented Design? Journal of Object-Oriented Programming 7(1): 67-78 (1994). Diseo basado en objetos vs. Diseo orientado a objetos Diseo basado en objetos (ingenuo o inicial): identificacin de tipos de cosas a partir de los objetos del dominio Diseo orientado a objetos (sistemtico): uso de clases abstractas y polimorfismo para reducir la complejidad del sistema (es decir, de los cambios que habra que hacer para mantener el sistema) Cmo se logra un diseo mantenible? Para encontrar las clases abstractas adecuadas: Anticipar una lista de posibles cambios Examinar crticamente el diseo inicial, evaluar la mantenibilidad Encapsular posibles variaciones dentro de clases abstractas Un buen diseo debe localizar los efectos de los posibles cambios anticipados Encapsular decisiones de diseo difciles o arriesgadas Las clases abstractas nos protegen de posibles variaciones futuras Todo lo contario de simular entidades del mundo real No creamos clases abstractas porque son evidentes en el dominio, las creamos porque hay cambios que pueden venir del dominio y queremos controlar su impacto en el sistema Esta tcnica recibe diversos nombres: anlisis defensivo (Haythorn), anlisis de robustez (Jacobson), objetificar las variaciones (Gamma) Ejemplos. Parchs: tablero, jugadores, turnos, reglas... El papel del mantenimiento en la economa del software
Punto de partida: un proyecto software no termina cuando se entrega, sino cuando se retira. El coste marginal en economa se define como el incremento del coste total que supone la produccin adicional de una unidad de un determinado bien. Cuando se ha realizado una gran inversin para producir determinados bienes (un fbrica de zapatos), el coste marginal para producir una unidad ms (un par de zapatos) es muy pequeo. La diferencia entre el coste marginal y el precio obtenido por su venta es lo que amortiza la inversin inicial, adems de proporcionar los beneficios. En la ingeniera del software no producimos artefactos materiales, como zapatos o coches. El producto verdaderamente anlogo al zapato o al coche no es una nueva instalacin del sistema del sistema producido. El coste marginal de esta nueva instalacin es ridculo, comparado con la inversin necesaria para su desarrollo. Rentabilizar la inversin inicial mediante la venta de nuevas instalaciones elevara excesivamente el precio de stas, habitualmente ms all de lo que el cliente percibe como razonable. Esto es una dificultad seria en el negocio informtico. En la ingeniera del software el coste marginal hay que buscarlo en el mantenimiento: el anlogo al coche o al zapato es la accin de mantenimiento. El cliente percibe bien el valor de las acciones de mantenimiento. Si conseguimos que su coste sea reducido, entonces podemos transformar la venta de instalaciones en venta de acciones de mantenimiento, y estaremos rentabilizando mucho mejor la produccin de software. Ejemplo: tenemos uno o dos proyectos en desarrollo, por los que no cobramos todo lo que nos cuesta; y muchos ms proyectos en mantenimiento, por los que cobramos ms de lo que nos cuesta mantenerlos, gracias a que el mantenimiento nos cuesta muy poco. De esta forma aplicamos al negocio del software lo que funciona en otros mbitos de la industria y la economa. El negocio informtico se transforma: de ofrecer bienes a ofrecer servicios. El cliente ya no se ve obligado a realizar un gran desembolso inicial, muchas veces inseguro de si el producto que ofrecemos es lo que realmente necesita, sino que podemos ofrecer una tarifa plana por el servicio continuado de mantenimiento. Al cliente le puede interesar mucho ms pagar por un ao de servicio que pagar por el producto entregado. As puede cambiar ms fcilmente su sistema informtico, sin necesidad de amortizarlo hasta el final. Conclusin: los diseos mantenibles tienen un impacto directo en el negocio informtico.

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.

You might also like