Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Segundo Cuatrimestre de 2008 Clase 7: Documentación de Arquitecturas - Viewtypes Buenos Aires, 11 de Septiembre de 2008

2 Un ejemplo de una arquitectura Cuáles son los problemas de este diagrama? 2

3 Problemas Hay muchas cosas sin definir: Qué clase de componentes? Qué clase de conectores? Qué significan las cajas y las líneas? Qué significa la distribución de las cajas en el diagrama? Por qué el proceso de control está en un nivel más alto? Los diagramas de cajas y líneas no son arquitecturas, son sólo el comienzo 3

4 Vistas de una arquitectura En la clase introductoria al tema de arquitecturas, dijimos que la arquitectura representaba distintas estructuras del sistema. Las estructuras pueden dividirse principalmente en tres grupos: De Módulos: los módulos son unidades de implementación, una forma de ver al sistema basada en el código. De Componentes y Conectores: aquí los elementos son unidades de run-time y los conectores son los mecanismos de comunicación entre esos conectores. Estructuras de alocación o asignación ( allocation ): Muestra la relación entre elementos de software y los elementos en uno o más entornos externos en los que el software se crea y ejecuta. Llamamos Viewtypes a las vistas de arquitecturas orientadas a estas tres estructuras 4

5 Estructuras Vistas de Módulos Enumera las principales unidades de implementación del sistema o módulos, y las relaciones entre ellas. Los módulos son unidades con interfaces bien definidas que proveen conjuntos de servicios y ocultan parcialmente los detalles de estructura y algoritmos. Determina Cómo el código es dividido en partes separables Qué puede cada parte asumir acerca de los servicios provistos por las otras partes? Cómo componemos partes en agrupaciones de mayor tamaño? Esto determina en gran medida las características como modificabilidad, portabilidad y reuso

6 Estructuras del tipo módulo Un módulo es una unidad de código que implementa un conjunto de responsabilidades Una clase, una colección de clases, una capa o cualquier descomposición de la unidad de código Relaciones: Descomposición ( es parte de ): los módulos tiene relación del tipo es un submódulo de Usos ( depende de ): los módulos tienen relación del tipo usa a. Se dice que un módulo A usa a B, si la correcta ejecución de B es necesaria para la correcta ejecución de A (no es lo mismo que invocación). Clases ( es un ): los módulos en este caso son clases las relaciones son hereda de u otras asociaciones. 6

7 Propiedades Expresan información importante asociada a cada módulo Permiten agregar restricciones a los módulos La lista de propiedades pertinentes para cada módulo, dependerá de muchos factores Nombre: Debe sugerir su rol dentro del sistema. Responsabilidades Qué es lo que el módulo hace en el contexto del sistema Visibilidad de las interfaces Interfaces qué publica y cuáles son internas

8 Vistas de Módulos: utilidad Construcción Puede proveer un blueprint para el código fuente Generalmente es posible establecer mapeos entre módulos y estructuras físicas (como archivos de código fuente o directorios) Análisis A partir de estas vistas, es posible realizar distinto tipos de análisis Por ejemplo: Trazabilidad de Requerimientos Analiza como los requerimientos funcionales son soportados por las responsabilidades de los distintos módulos Análisis de Impacto Comunicación Permite predecir el efecto de las modificación del sistema Pueden ser utilizadas para explicar las funcionalidades del sistema a alguien no familiarizado con el mismo

9 Vistas de Módulos: cuando no Inferencias sobre el comportamiento del sistema durante su ejecución No es de mucha utilidad para la realización de análisis de performance, confiabilidad u otras características asociadas al tiempo de ejecución Múltiples instancias de objetos Relaciones existentes sólo en tiempo de ejecución

10 Relación con otras vistas Las vistas de módulo pueden ser fácilmente mapeadas a vistas de componentes y conectores Los módulos pueden ser mapeados con los componentes que se ejecutan en tiempo de ejecución Este mapeo puede ser tan simple como una relación uno a uno, o mucho más complejos: fragmentos de módulos pueden corresponderse con fragmentos de componentes

11 Vista de módulos Event HTTP request Controller (Servlet) Dispatch Business Logic (Action) Client (Browser) Forward struts-config.xml Update HTTP response View (JSP) Get <tag> Model (App State) 11

12 Realización de Caso de Uso (clases) 12

13 Una vista lógica en UML <<business component>> Auction Catalog <<business component>> Auction Management <<business component>> User Account Management <<layer>> Presentation Logic (from Auction Catalog) <<layer>> Presentation Logic (from Auction Management) <<layer>> Presentation Logic (from User Account Management) <<layer>> BusinessLogic (from Auction Catalog) <<layer>> Business Logic (from Auction Management) <<layer>> Business Logic (from User Account Management) Common Elements and Services 13

14 Vistas de Módulos con UML A Clase Es parte de B Paquete A Depende de B <<subsistema>> Subsistema A Es un B 14

15 Vista de descomposición con UML Muestra las partes que componen una parte mayor Util para: Soporte al proceso de aprendizaje sobre el sistema Comunicación de la estructura funcional Definición de items de configuración Input para vista de asignación ( work assignments ) Dos formas disponibles para la notación en UML A A B C D B C D 15

16 Ejemplo Tessellator El software del Robot Tessellator se divide inicialmente en dos grupos: on board y off board. Los primeros incluyen el módulo MAPS para posicionamiento de la base móvil, EEPS para posicionamiento del brazo, VISION para el sistema de visión y RKW para el manejo de la herramienta de impermeabilización. Los subisistemas off-board incluyen el Control Maestro y de Acceso a la Base de Datos (DBA). Tessellator Software On-Board Software Off-Board Software MAPS EEPS WP Tool Vision Master Control Database 16

17 Vista de usos Para mostrar dependencias en los diagramas Util para análisis de impacto HLC <<uses>> MAPS <<uses>> <<uses>> EEPS <<uses>> Low Level Routines 17

18 Vista de generalización La relación entre módulos indica es un En la clausura transitiva de la relación, un módulo que hereda información es llamado descendant, y el que la provee es un ancestor. Se usa para mostrar diseños orientados a objetos, para entender módulos como variaciones de otros y mostrar oportunidades para el reuso Polígono Avión Vehículos de Pasajeros A <<Interfaz>> <<Implementación>> Triángulo Rectángulo Hexágono Avión de pasajeros B 18

19 Vista tipo layered Caso particular de usos restringido Suele mostrarse con diagramas informales Informales UML Business Layer <<puede usar>> Data Access Layer Idea de Core 19

20 Relaciones entre módulos de cada nivel Puede haber restricciones en cuanto a los elementos a acceder de un nivel inferior Business Layer Equivale a Business Layer <<puede usar>> <<puede usar>> Data Access Layer Data Access Layer Data Access Layer Data Access Layer Data Access Layer Data Access Layer <<puede usar>> <<puede usar>> Database Database 20

21 Estructuras de componentes y conectores Estas estructuras están centradas en procesos que se comunican. Sus elementos son entidades con manifestación runtime que consumen recursos de ejecución y contribuyen al comportamiento en ejecución del sistema La configuración del sistema es un grafo conformado por la asociación entre componentes y conectores Las entidades runtime son instancias de tipos de conector o componente 21

22 Componentes Identificamos componentes con un nombre que nos de una pista sobre su función Los componentes son instancias de un tipo de componente El tipo de componente nos indica las interfaces que provee y las propiedades requeridas Muchas veces los tipos de componente son heredados del estilo Los componentes tienen puertos que deben encontrarse documentados

23 Conectores Un conector representa un camino en la interacción en tiempo de ejecución entre dos o más componentes El tipo de conector indica la cardinalidad (cantidad de componentes en la interacción), las interfaces que soporta y las propiedades requeridas El tipo de conector se hereda generalmente del estilo El conector asume un conjunto de roles dentro de la arquitectura

24 Utilidad Cuales son los componentes ejecutables y como interactúan? Cuáles son los repositorios y que componentes los acceden? Qué partes del sistema son replicadas y cuantas veces? Cómo progresan los datos a los largo del sistema a medida que éste se ejecuta? Qué protocolos de interacción son usados por las entidades comunicantes? Qué partes del sistema se ejecutan en paralelo? Cómo la estructura del sistema puede cambiar a medida que se ejecuta?

25 Para qué no sirve No se debe usar para modelar elementos de diseño que no tienen comportamiento runtime Una clase no es un componente. Un componente no representa de ninguna manera una visión estática de diseño Estar atento a que si no tiene sentido caracterizar la interfaz de un elemento probablemente no sea un componente

26 Vista de procesos (J2EE) 26

27 Descripciones de componentes y conectores con UML Filtros como objetos Filtros como packages PipeFilter PipeFilter Grep: filter Grep Splitter: filter MergeSort: filter Splitter MergeSort Procesos como Componentes UML HLC Motion Executor Motors Manager EEPS Planner 27

28 Estructuras de alocación o asignación Deployment: muestra cómo el software se asigna a hardware y elementos de comunicación. Implementación: muestra cómo los elementos de software se mapean a estructuras de archivos en repositorios de control de la configuración o entornos de desarrollo. Asignación de trabajo ( work assignment ): asigna la responsabilidad del desarrollo y la implementación a equipos de programadores. 28

29 Vista de deployment Client Application Server Database Server Browser EJB Container Web Container Close Auction Process SQL Server 29

30 Vista de implementación (código fuente) 30

31 Vistas a modelar - Allocation Tenemos tres grupos: de deployment, de implementación y tipo work assignment. Las vistas de deployment pueden ser fácilmente representadas con UML, mientras que para las otras dos se suelen usar notaciones informales. Diagramas de deployment en UML Nodo Componente Asociación Componente UML 1.* Dependencia Componente UML

32 Ejemplo 32

33 Al documentar, qué vistas elegir Cada estructura tiene una vista Los diferentes stakeholders necesitan distintas vistas Distintos tipos de sistemas pueden implicar distintas vistas Un proceso para definir vistas: 1. Hacer una lista de vistas candidatas 2. Combinar vistas. Ejemplos: implementación con módulos, una vista de niveles con la vista de módulos, vista de deploy con vistas de componentes y conectores. 3. Definir prioridades 33

34 Html estático Html dinámico Ejemplo de vista combinada Sistema XX Capa de Presentación Capa de Negocios Imgs M1 M2 M3 Usuario http Docs Objetos comunes M4 M7 M5 M8 M10 M6 M9 Adm Capa de Interacción c/ Otros Sistemas webservices Sistema / Módulo Externo http SOAP WSDL UDDI XML Marshaller Capa de Acceso a Datos AD Access Data Base DAO Interfaces S1 S2 S3 Otros S4 Sistemas Otros Sistemas Ex file 1 Ex file 2 Windows Active Directory Base de Datos Local Sistemas externos 34

35 Vista combinada: módulos y layers Front-Controller Delegate Action Encapsulate Data Action / Command Data Transfer Object (DTO) Encapsulate Data Access Business Lay er Business Delegate Presentation & Control Layer Data Transfer Object (DTO) Encapsulate Data Mediate Business Processing Encapsulate Data Session Façade Access Business Serv ices Message Façade Create objects Access entity objects Factory DAO Business Model (Entity Objects) Business Logic Layer O/R mapping Data Access Layer 35

36 Indicadores de calidad en un diagrama de arquitectura Malo: Las líneas son todas iguales Las flechas no significan nada Las flechas significan distintas cosas No se explica qué significa cada elemento del diagrama Bueno Las cajas y líneas tienen distintas formas / colores / sombras y se explica más abajo qué significa cada una Se usan tablas para explicar elecciones Los diagramas no tratan de explicar demasiado. Se usan distintas vistas. Cada vista entra en una página 36

37 Puntos clave para documentar una arquitectura El documento está escrito para el lector, no quien lo escribe Evitar ambigüedad Explicar la notación claves Adjuntar información adicional, por ejemplo de interfaces Usar una organización estándar Qué vistas, template a usar Registrar los motivos Explicar el por qué de las decisiones tomadas Mantenerla actualizada, pero no demasiado Revisarla 37

38 Elementos esenciales Descripción de los requerimientos Contexto del negocio, rationale para el producto, dominio Descripción del contexto Sistemas con quienes interactúa, interfaces externas Uso de diagramas de arquitectura Con prosa y descripción de cajas y líneas Consideración de restricciones de implementación En la medida en que impactan la arquitectura Explicación del diseño arquitectónico Como ataca los requerimientos y las restricciones de diseño Alternativas 38

39 El template de RUP para documentar arquitecturas 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview 2. Architectural Representation ( Cómo la representamos?) 3. Architectural Goals and Constraints 4. Use-Case View 4.1 Use-Case Realizations 5. Logical View (descomposición en subsistemas o packages ) 5.1 Overview 5.2 Architecturally Significant Design Packages (para cada uno incluir clases más importantes) 39

40 El Template de RUP para documentar arquitecturas (cont.) 6. Process View (descomposición en threads de control ) 7. Deployment View (hardware, redes) 8. Implementation View 9. Data View (optional) 10. Size and Performance 11. Quality 40

41 Un ejemplo de índice de un documento de arquitectura Introduction Purpose and audience of this document Evolution of this document Reference Materials Terms and acronyms Goals and Constraints of the architecture Overview of the XX System Main Characteristics of XX Overview of the Application Architecture High level view of the application architecture Description of the application layers and modules WebServices Application Architecture Major Design Decisions 4.1 Implementation of the Model-View-Controller Pattern 4.2 Use of Patterns 41

42 Un índice de un documento de arquitectura (cont.) 4 5 Application Architecture Major Design Decisions 4.3 Implementation of the View (Usability) 4.4 Error Handling Strategy 4.5 Logging Strategy 4.6 Object Persistence 4.7 Implementation of the entity locking solution 4.8 Managing Historical Data 4.9 Database usage for batch processing 4.10 Client State Administration 4.11 Implementation of the Internationalization Features 4.12 Implementation of the Security Features 4.13 The use of a workflow system 4.14 Integration Strategy Significant Use Cases of the system 5.1 Data manipulation processes 5.2 Workflow processes 5.3 Batch processes 5.4 Application of XX s architectural definitions 42

43 Un índice de un documento de arquitectura (cont.) 6 Base Software 6.1 EJB Version 6.2 J2EE Version 6.3 Version and edition of the Oracle Application Server 6.4 Version of the Oracle Database 6.5 Operating System 7 Servers Architecture 7.1 Most Reliable alternative 7.2 Reliable Alternative 7.3 Basic Reliable alternative 7.4 Basic Solution 7.5 Alternatives for each country 43