Modelado arquitectónico con UML

Transcripción

1 Modelado arquitectónico con UML Qué es la arquitectura de software El modelo de 4+1 vistas arquitectónicas Cohesión y acoplamiento Cómo lograr una descomposición modular eficaz Criterios para la selección de una arquitectura Diagrama de componentes Noción de componente y dependencia Noción de interfaz Uso de interfaces en OO Diseño por contratos Noción de contrato Especificación formal del contrato: sintaxis y semántica Uso de pre- y post- condiciones Invariantes de clase Contratos y herencia: subcontratación 95 Arquitectura del software: definiciones Paul Clements 1996 La arquitectura del software es a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. Len Bass 1998 La arquitectura del software de un programa o sistema de computación es la estructura o las estructuras del sistema, que contienen componentes de software, las propiedades externamente visibles de dichos componentes y las relaciones entre ellos. IEEE Std La arquitectura del software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y con el entorno, y los principios que orientan su diseño y evolución. 96

2 El modelo de 4+1 vistas arquitectónicas Vista lógica (conceptual) Vista de desarrollo (implementación) Práctica: capítulo 4 Vista de casos de uso Práctica: capítulo 5 Vista de proceso (ejecución) Vista física (despliegue) Vistas que no entran en la práctica 97 Características de cada vista en el modelo 4+1 Vista Lógica (conceptual) Proceso (ejecución) Desarrollo (implementación) Física (despliegue) Aspecto Modelo de información Concurrencia y sincronización Organización del software en el entorno de desarrollo Correspondencia software-hardware Stakeholders Usuarios finales Integradores del sistema Programadores Ingenieros de sistemas Requisitos Funcionales Rendimiento Disponibilidad Fiabilidad Concurrencia Distribución Seguridad Gestión del software Reuso Portabilidad Mantenibilidad Restricciones impuestas por la plataforma o el lenguaje Rendimiento Disponibilidad Fiabilidad Escalabilidad Topología Comunicaciones Notación Clases y asociaciones Procesos y comunicaciones Componentes y relaciones de uso Nodos y rutas de comunicación Proyecto Práctico de Diseño de Software 98

3 Relaciones entre las cuatro vistas minimizar dependencias nuevas clases de diseño Vista lógica (conceptual) Vista de desarrollo (implementación)? identificar clases activas Vista de proceso (ejecución) Vista física (despliegue) requisitos no funcionales Proyecto Práctico de Diseño de Software 99 Cohesión y acoplamiento 1 componente componente Alta cohesión Puente 5 6 Bajo acoplamiento Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 100

4 Cómo lograr una buena descomposición modular A B C A D E D E F B C F Mal Bien Cómo acertar de antemano? Estilos arquitectónicos 101 Criterios para la selección de una arquitectura Criterios clásicos: Extensibilidad: facilitar la adición de nuevas caracterísiticas Hace más complejo el diseño. Aporta mayor grado de abstracción. Ejemplo: arquitectura que soporte no este juego de tablero particular, sino cualquier tipo de juego de tablero. Generalizar requiere invertir tiempo en el diseño: decidir qué tipo de extensiones pueden surgir, etc. La distinción de requisitos opcionales/deseables es útil aquí, ya que señala hacia dónde apunta el desarrollo del sistema. Modificabilidad: facilitar el cambio de requisitos. Es distinto del anterior, aunque requiera técnicas similares. Ejemplo: posibilidad de cambiar las reglas del juego. Simplicidad: hacer fácil de entender, hacer fácil de implementar. Difícil de coordinar con los dos anteriores. Eficiencia: lograr alta velocidad o pequeño tamaño. Otros criterios: Reuso, Escalabilidad, Coste, Requisitos no funcionales 102

5 Noción de componente y dependencia <<component>> A Dependencia A C: A requiere la presencia de C Los cambios de C pueden afectar a A <<component>> B <<component>> C E F 103 Dependencia respecto a una interfaz Dos componentes pueden ofrecer la misma interfaz Dos interfaces no necesariamente disjuntas 104

6 Representación de interfaces: abreviada y completa Novedad en UML2 105 Noción de interfaz Encapsulamiento: separación de interfaz e implementación: una clase/componente puede realizar una o varias interfaces. una interfaz puede ser realizada por una o varias clases/componentes. Interfaz: conjunto de operaciones que ofrecen un servicio coherente: no contiene la implementación de las operaciones (métodos). una interfaz no puede tener atributos ni asociaciones navegables (esta restricción ha desaparecido en UML 2.0). análoga a una clase abstracta con todas sus operaciones abstractas: no puede tener instancias directas. Impresora Imprimible Impresora uso Documento Documento Notaciones para uso y realización de interfaces «interface» Imprimible imprimir( ) realización 106

7 Generalización vs. Realización La realización puede entenderse como una generalización débil : se hereda la interfaz, pero no la implementación: reduce la dependencia. disminuye la reutilización. alternativa a la generalización múltiple, no soportada por muchos lenguajes. Las interfaces son elementos generalizables: jerarquías mixtas de interfaces y clases. Criterio de diseño: comprometerse sólo con la interfaz. declarar el tipo de las variables y parámetros de operaciones como interfaces, no como clases. servirá cualquier instancia compatible con la interfaz. Ejemplo: Figura f = new Cuadrado ( ); f.imprimir Círculo «interface» Imprimible «interface» Figura Rectángulo Cuadrado 107 Interfaces proporcionadas y requeridas proporciona, realiza requiere, usa 108

8 Diagrama de componentes ball and socket cableado independiente cableado en árbol cableado con dependencia 109 Cómo instanciar las interfaces de un componente (1) package GestiónEmpleados; public interface iempleado { public modificar( ) { ; public class EmpleadoFijo implements iempleado { public modificar( ) { ; public class EmpleadoTemporal implements iempleado { public modificar( ) { ; ==================== class Departamento { iempleado e = new EmpleadoFijo( ); e.modificar( ); El componente proporciona sólo una interfaz, el tipo abstracto de datos. Es necesario que la clase cliente (Departamento) conozca las clases concretas EmpleadoFijo, etc.: estas clases deben ser públicas. Nada le impide usarlas sólo para invocar los constructores (salvo el buen estilo del programador). La dependencia es potencialmente peligrosa. 110

9 Cómo instanciar las interfaces de un componente (2) package GestiónEmpleados; public interface igestorempleados { public int crearempleado( ); // el gestor debe mantener algún tipo de lista public modificarempleado(int e); class EmpleadoFijo { // no visible desde fuera, idem EmpleadoTemporal public class GestorEmpleados implements igestorempleados { public int crearempleado( ) {; // usa new EmpleadoFijo( ) public modificarempleado (int e) {; // usa EmpleadoFijo.modificar( ) ==================== class Departamento { int e = ge.crearempleado ( ); // se supone que existe GestorEmpleados ge ge.modificarempleado(e); El componente proporciona sólo una interfaz, el gestor. GestorEmpleados no puede recibir ni devolver valores de tipo EmpleadoFijo, EmpleadoTemporal, etc. Es necesario un mecanismo de traducción de los identificadores públicos a las instancias de EmpleadoFijo, etc. (una lista interna). La clase cliente sólo usa el gestor y los identificadores públicos. 111 Cómo instanciar las interfaces de un componente (3) package GestiónEmpleados; public interface iempleado { public modificar( ) { ; El componente proporciona dos interfaces, el tipo abstracto de datos y el gestor. public interface igestorempleados { public iempleado crearempleado( ); // el gestor debe mantener algún tipo de lista public modificarempleado(iempleado e); ==================== class Departamento { iempleado e = ge.crearempleado ( ); // se supone que existe GestorEmpleados ge e.modificar( ); La clase cliente no puede usar el constructor directamente, pero sí el tipo abstracto en el resto de operaciones. 112

10 Cómo instanciar las interfaces de un componente (4) Caso 3 (parámetros iempleado) Caso 1 Caso 2 (parámetros int) 113 Diseño por contratos: PPCs e invariantes PPCs de operación CuentaCorriente.meterDinero(cantidad: Moneda) Pre: Post: saldo = saldo + cantidad CuentaCorriente.sacarDinero(cantidad: Moneda) Pre: saldo cantidad 0 Post: saldo = saldo cantidad CuentaCorriente saldo meterdinero(cantidad) sacardinero(cantidad) Invariantes de clase CuentaCorriente: saldo 0 114

11 Diseño por contratos: subcontratación PPC s de operación CuentaCorriente.sacarDinero(cantidad: Moneda) Pre: saldo cantidad 0 Post: saldo = saldo cantidad PPC s de operación redefinida en la subclase CuentaCredito.sacarDinero(cantidad: Moneda) Pre: saldo + credito cantidad 0 Post: saldo = saldo cantidad Pre: menos restrictiva, o igual Post: más restrictiva, o igual Invariantes de clase (más restrictivo, o igual) CuentaCorriente: saldo 0 CuentaCredito: (credito 0) AND (saldo + credito 0) CuentaCorriente saldo sacardinero(cantidad) CuentaCredito credito sacardinero(cantidad) Es correcta esta generalización? 115 Diseño por contratos: uso correcto de jerarquías CaminoOblicuo.distancia.post d = ( x y x1) + ( y2 1) CaminoEsquinado.distancia.post d = ( x2 x1) + ( y2 y1) (x 2, y 2 ) (x 1, y 1 ) Cuál sería correcta? CaminoOblicuo origen: Punto destino: Punto distancia( ): Float CaminoEsquinado origen: Punto destino: Punto distancia( ): Float 116