1

Diseño y Evaluación de Arquitecturas de Software

Documentación

César Julio Bustacara Medina

Facultad de Ingeniería Pontificia Universidad Javeriana

11/09/2015

Arquitectura de Software

Introducción

• Representan un aspecto parcial de una Arquitectura de Software mostrando propiedades específicas de un sistema de software

¿Para qué documentar?

• Las arquitecturas tiene importancia para sistemas a largo plazo.

• Comunicar la arquitectura a los interesados es tan importante como crearla.

• Para entender, pues si los interesados no entienden la arquitectura (y la analizan, mantienen y aprenden), se pierde el esfuerzo de haberla hecho.

• Analizar arquitecturas alternativas

• Planear la migración de sistemas legados a nuevos

¿Para qué documentar?

• Para certificar el cumplimiento del sistema con la arquitectura

• Como insumo de las otras etapas del desarrollo

• Planeación y presupuesto de desarrollo

• Especificación de líneas de producto (familias)

Interesados e intereses

• Interesados (stakeholders) como mínimo:

–Usuarios del sistema

–Compradores (cliente)

–Desarrolladores

–Mantenedores

Interesados e intereses

• Intereses (concerns) como mínimo:

–Propósito o misión del sistema

–Adecuación del sistema para cumplir su misión

– Factibilidad de construir el sistema

–Riesgos de desarrollo y operación

–Requerimientos no funcionales como mantenibilidad, evolución, despliegue...

Vistas

• Una vista es una representación de un conjunto de elementos del sistema y sus relaciones.

• Es una representación de alguna de las muchas estructuras presentes simultáneamente en un sistema de software.

Tipos de vistas

Unidades de

implementación

o áreas de responsabilidad

Funcional

Unidades de computo y

medios de comunicación

entre ellas (almacenes,

paralelismo...)

Relación entre elementos

de software y del ambiente

de creación o ejecución

(procesadores, archivos, roles)

Tipos de vistas

• Lista 1. Arquitecturas:

– “Arquitectura Conceptual: Componentes y conectores”.

– “Arquitectura por Módulos: Subsistemas, módulos, exportaciones e importaciones”

– “Arquitectura por Código: Archivos, directorios, librerías e inclusiones”

– “Arquitectura de Ejecución: Tareas, hilos y procesos”

Tipos de vistas

• Lista 2.

– “Vista lógica: El modelo de objetos de diseño o el modelo correspondiente como un diagrama ER”

– “Vista de Procesos: Aspectos de concurrencia y sincronización”

– “Vista Física: El mapeado del software al hardware y sus aspectos distribuidos”

– “Vista de Desarrollo: La organización estática del software en el ambiente de desarrollo”

Tipos de vistas

• Lista 3. Estructuras:

– “Estructura Modular: Las unidades son asignaciones de trabajo”

– “Estructura Conceptual o Lógica: Las unidades son abstracciones de los requerimientos funcionales del sistema”.

– “Estructura de Procesos o de Coordinación: Maneja los aspectos dinámicos de un sistema en ejecución. Las unidades son procesos o hilos”

– “Estructura Física: Muestra el mapeado del software al hardware”

– “Estructura de Usos: Las unidades son procedimientos o módulos. Se conectan mediante relaciones asume-la-presencia-correcta-de”

Tipos de vistas

– “Estructura de Llamados: Las unidades son usualmente (sub)procedimientos los cuales se relacionan por las relaciones de llamados o invocaciones”

– “Flujo de Datos: Las unidades son programas o módulos y las relaciones se llaman debe-enviar-información-a”

– “Flujo de Control: Las unidades son programas, módulos o estados del sistema. La relación es se-convierte-activo-después-de”

– “Estructura de Clase: Las unidades son objetos. La relación es hereda-de o es-instancia-de”

Elegir vistas

1. Producir lista de vistas candidatas Generar una tabla de interesados vs. intereses,

indicando cuánto detalle necesita cada interesado de cada interés (idealmente con un taller)

2. Combinar vistas Identificar aquellas vistas en la tabla que sólo

requieren una descripción general o interesan a pocos

Identificar aquellas vistas que se pueden combinar

Elegir vistas

3. Priorizar vistas

Mejor un enfoque de amplitud y no profundidad en principio

Algunos intereses son más prioritarios

Tiene prioridad lo que ayude a determinar el cumplimiento con la misión

Documentar vistas: plantilla 1. Presentación 2. Catalogo de elementos

– Elementos y sus propiedades – Relaciones – Interfaces – Comportamiento

3. Diagrama de contexto 4. Guía de variabilidad 5. Antecedentes de la arquitectura

– Razonamiento (rationale) – Análisis de resultados – Suposiciones (assumptions)

6. Información adicional 7. Vistas relacionadas

(elementos y relaciones)

(relación de vista con el medio)

(como variar la vista)

“4+1 vistas”

Logical View

End-user

Functionality

Implementation View

Programmers

Software management

Process View

Performance

Scalability

Throughput

System integrators

Deployment View

System topology

Delivery, installation

Communication

System engineering

Conceptual Physical

Scenarios

Lo primero que se debe hacer para comenzar a desarrollar un

proyecto con UML, es seleccionar una metodología de desarrollo

que defina la naturaleza concreta del proceso a seguir.

El modelo a definir en base al

proceso elegido, se divide en

realidad en varios tipos de

modelo o vistas, cada una

centrada en un aspecto o

punto de vista del sistema. En

general, independientemente

del proceso que se emplee, se

puede encontrar las siguientes

vistas

Vistas de la arquitectura de un sistema - adaptada a UP

Vista de diseño Vista de

implementación

Vista de procesos

Vista de despliegue

Vista de casos de

uso

Vista de diseño Vista de

implementación

Vista de procesos

Vista de despliegue

Vista de casos de

uso

Vistas de la arquitectura de un sistema

vocabulario,

funcionalidad

comportamiento

Funcionamiento,

capacidad de

crecimiento,

rendimiento

topología del

sistema,

distribución,

entrega,

instalación

ensamblado del

sistema,

gestión de

configuraciones

Vista lógica (de diseño)

• Descomposición orientada a objetos • Estilo: Orientado a objetos

• Soporta requerimientos funcionales, descompuestos en abstracciones (objetos).

• Puede acompañarse de descripción dinámica con diagramas de estado.

Vista lógica (de diseño): notación

Vista de procesos

• Descomposición en procesos • Considera los requerimientos no-funcionales como

desempeño, disponibilidad, concurrencia, integridad, tolerancia a fallos...

• Se puede representar como un conjunto de redes de procesos.

• Proceso: grupo de tareas

• Tareas: hilos separados de control que pueden ser planificados individualmente en un nodo de procesamiento.

• Estilo: tubos y filtros, cliente/servidor...

Vista de procesos: notación

Vista de desarrollo (implementación)

• Descomposición en subsistemas

• Se enfoca en la organización de los módulos en el ambiente de desarrollo como una jerarquía de niveles

• Estilo: por niveles (4 a 6)

Vista de desarrollo (implementación): notación

Vista física (de despliegue)

• Mapear el software al hardware

• Se ocupa de requerimientos no-funcionales como disponibilidad, confiabilidad, desempeño y escalabilidad.

• El software se ejecuta en nodos de procesamiento

• Se deben mapear las redes, procesos, tareas y objetos a dichos nodos.

Vista físicas (de despliegue): notación

Vista de escenarios (casos de uso)

• Unirlo todo

• Los escenarios son instancias de los casos de uso, que constituyen guiones (scripts) del sistema

• Esta vista es redunante con las otras, sirve para:

– Ayudar a descubrir los elementos arquitectónicos

– Validar y explicar el diseño arquitectónico

Correspondencia entre vistas

• Mapeo entre vista lógica y de proceso:

– De adentro hacia afuera: definir tareas que multiplexen un solo hilo de control

– De afuera hacia adentro: Partiendo de la arquitectura física, definir los procesos que manejen los estímulos externos (peticiones)

• Mapeo entre vista lógica y de desarrollo

– Una clase usualmente se implementa como un módulo

– Otros criterios para definir subsistemas: organización del equipo, tamaño del código, reutilización, capas, políticas de promoción y gestión de configuración

• Mapeo entre vista de procesos y física:

– Los procesos y grupos de proceso se mapean al hardware tanto para pruebas como para despliegue.

Relación entre las vistas

Vista lógica Vista de Implementación

Vista de Procesos

Vista de Despliegue

Tipos de resultados

• Cada una de las vistas presenta:

• Aspectos estáticos: mediante los diagramas estructurales de UML.

• Aspectos dinámicos: mediante diagramas dinámicos de UML.

• Ejemplo: se puede trabajar con la vista de casos de uso estática y la vista de casos de uso dinámica, la vista de diseño estática y la vista de diseño dinámica, y así sucesivamente.

Tipos de resultados

Nombre Descripción Aspectos Estáticos

Aspectos Dinámicos

Vista de casos de uso

Proyecta el comportamiento del sistema tal y como es percibido por los: usuarios finales, ana-listas y encargados de las pruebas. Especifica las fuerzas que configuran la arquitectura del sistema.

Diagramas de casos de uso

Diagramas de interacción

Diagramas de estados

Vista de diseño Soporta los requisitos funcionales del sistema: servicios proporcionados a los usuarios finales. Vocabulario del problema y su solución: clases, interfaces y colaboraciones.

Diagramas de clases

Diagramas de objetos

Diagramas de interacción

Diagramas de estados

Diagramas de actividades

Vista de procesos Cubre el funcionamiento, capacidad de creci-miento y rendimiento del sistema. Mecanismos de sincronización y concurrencia del sistema: hilos y procesos.

Diagramas de clases (activas)

Diagramas de objetos

Diagramas de interacción

Diagramas de estados

Diagramas de actividades

Vista de implemen-tación

Cubre la gestión de configuraciones de las distin-tas versiones de un sistema a partir de compo-nentes y archivos quasi-independientes. Ensam-blado y disponibilidad del sistema: componentes y archivos.

Diagramas de compo-nentes

Diagramas de interacción

Diagramas de estados

Diagramas de actividades

Vista de despliegue Contiene los nodos que forman la arquitectura (topología) hardware sobre la que se ejecuta el sistema a través de sus componentes. Está des-tinada a representar la distribución, entrega e instalación de las partes que forman el sistema informático físico.

Diagramas de desplie-gue

Diagramas de interacción

Diagramas de estados

Diagramas de actividades

Diagra-

ma de

Casos de

Uso

Diagrama

de

Interac-

ción-

Secuen-

cia

Diagrama

de

Interacción-

Colabora-

ción

Diagra-

ma de

Clases

Diagra-

ma de

Objetos

Diagrama

de

Estados

Diagrama

de

Activida-

des

Diagrama

de Compo-

nentes

Diagrama

de Desplie-

gue

Estática

Dinámica

Estática

Dinámica

Estática

Dinámica

Estática

Dinámica

Estática

Dinámica

Vista de

Despliegue

Vista de Casos

de Uso

Vista de

Diseño

Vista de

Procesos

Vista de

Implemen-

tación

VISTAS Y DIAGRAMAS EN UML

Cuántas vistas pueden existir?

• Pueden existir modelos simplificados que se ajusten al contexto

• No todos los sistemas requieren todas las vistas:

– Simple procesador: Eliminar la vista de despliegue

– Simple Proceso: Eliminar la vista de procesos

– Programas muy pequeños: eliminar la vista de implementación

• Adicionar vistas:

– Vista de Datos, Vista de Seguridad, etc.

Iteraciones y Arquitectura

Use case Model

Design Model

Deployment Model

Test Model

Implementation Model

Content

Diseño Arquitectonico

• Identifica, selecciona, y valida elementos “significativos arquitectónicamente”

• No todo es una arquitectura – Main “business” classes

– Important mechanisms

– Processors and processes

– Layers and subsystems

– Interfaces

• Produce un Documento de la Arquitectura de Software

Secuencia en el diseño Arquitectónico

• Seleccionar escenarios: críticos y de riesgo • Identificar classes principales y

su responsabilidad

• Distribuir el comportamiento sobre las clases

• Estructurar en subsistemas, layers, definir interfaces

• Define distribución y concurrencia • Implementar un prototipo arquitectónico • Derivar pruebas a partir de los casos de uso • Evaluar la arquitectura

Iterar

Use case view

Logical view

Deployment view

Implementation view

Process view

Proceso iterativo de desarrollo de arquitectura

• Empezar

– Se eligen un pequeño número de escenarios (casos de uso)

– Se elabora un prototipo arquitectónico

– Se identifican y representan los elementos según las 4 vistas

– Se implementa, prueba, mide y analiza la arquitectura

– Se capturan las lecciones aprendidas

• Iteración

– Se reevalúan los riesgos

– Se extiende el grupo de escenarios a considerar

– Se eligen los escenarios que tengan menor riesgo y mayor cobertura

– Se hace un guion de los escenarios acorde con la arquitectura existente

– Se descubren elementos arquitectónicos adicionales

– Se actualizan las vistas

– Se actualiza la implementación

– Se prueba y mide en el ambiente de producción si es posible

– Se revisan las 5 vistas

– Se actualizan las guías y racionalidad de la arquitectura

– Se capturan las lecciones aprendidas

[3]

Documentar la arquitectura: plantilla • Página de título • Historia de cambios • Tabla de contenido • Lista de figuras 1. Alcance 2. Referencias 3. Arquitectura de software 4. Metas y restricciones arquitectónicas 5. Arquitectura lógica 6. Arquitectura de procesos 7. Arquitectura de desarrollo 8. Arquitectura física 9. Escenarios 10. Tamaño y desempeño 11. Calidad • Apéndices

– Acrónimos y abreviaciones – Glosario – Principios de diseño

[3]

Ejemplo

• Se instancia un ejemplo a la plataforma de Enterprise Architect

class UML 2.0 Diagrams

UML 2.0 Diagram Types

Structural Diagrams

Below are some examples of the UML 2.0 diagrams types supported in Enterprise

Architect. This section gives examples of all 13 diagram types supported.

Behavioral Diagrams

Activity

DeploymentTiming

Analysis

Composite Structure

Object

Package Use Case

Communication

Sequence

Interaction

State

Class

Custom

Component

Requerimientos

Requerimientos

custom Manage Users

REQ011 - Manage

User Accounts

REQ025 - Store

User Details

REQ018 - Report

on User Account

REQ024 - Secure

Access

REQ017 -Remove

User

REQ026 - Validate

User

REQ016 -Add

Users

Stakeholders - Requerimientos

custom Stakeholders Interests

Chief Executiv e Officer

REQ001 - Relation between

orders and email inquires.

Business Manager

Process Manager

REQ002 - Create a secure

on-line ordering system.

REQ003 - High Volume

Through-put

REQ006 - Efficient stock

control management.

Modelo del negocio

Casos de Uso

Casos de Uso

analysis Login

LoginClient

(from Actors)

Account

LoginAcount

analysis View History

View HistoryClient

(from Actors)

Account

Transaction

Trazabilidad Casos de Uso con los Requerimientos

Vista de Componentes

Vista de Desarrollo

Vista de Desarrollo

Vista de Despliegue

deployment HO Serv ers

LAN

DMZ

HOFW :

WatchGuard III

Firewall

FRR01 :Intel 19510

Frame Relay Router HOES01 :Ethernet

Switched Hub

Web Serv er :Dell

PowerEdge 2650

Disk Controller = RAID 5

Disks = 4 x 80 GB

Processor = 2 x 2.8 GHZ

RAM = 2 x 1024 MB

HOES02 :Ethernet

Switched Hub

216.239.46.96 :

Ethernet Adaptor

Mail Serv er :HP ProLiant

DL380

Disk Controller = RAID 5

Disks = 4

Processor = 3.0 Ghz

RAM = 2048 Mb

192.168.02 :

Ethernet Adaptor

WebDataServ er :Dell

PowerEdge 6650

Disk Controller = RAID 5

Disks = 3 x 120 GB

Processor = 3.0 GHz

RAM = 1024 Mb

216.239.46.95 :

Ethernet Adaptor

192.168.0.3 :

Ethernet Adaptor

Client Data Serv er :Dell

PowerEdge 1650

Disk Controller = RAID 5

Disks = 4 x 120 GB

RAM = 1024 MB

Processor = 3.0 GHZ

+Internet

+LAN

+DMZ

deployment HO Serv er Images

DMZ

HOFW :WatchGuard

III Firewall

«secure»

FRR01 :Intel 19510 Frame

Relay RouterHOES01 :Ethernet

Switched Hub

Web Serv er :Dell

PowerEdge 2650

«pc server»

RAM = 2 x 1024 MB

Processor = 2 x 2.8

GHZ

Disks = 4 x 80 GB

Disk Controller =

RAID 5

216.239.46.96 :

Ethernet

Adaptor

WebDataServ er :Dell

PowerEdge 6650

«pc server»

RAM = 1024 Mb

Processor = 3.0 GHz

Disks = 3 x 120 GB

Disk Controller = RAID

5

216.239.46.95 :

Ethernet Adaptor

+Internet

+DMZ

Vista de Despliegue

Vista de Despliegue