Vista de Procesos - Departamento de Ingeniería de Sistemas

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
1
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-presenciacorrecta-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-activodespué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.
2.
(elementos y relaciones)
Presentación
Catalogo de elementos
–
–
–
–
3.
4.
5.
Diagrama de contexto (relación de vista con el medio)
(como variar la vista)
Guía de variabilidad
Antecedentes de la arquitectura
–
–
–
6.
7.
Elementos y sus propiedades
Relaciones
Interfaces
Comportamiento
Razonamiento (rationale)
Análisis de resultados
Suposiciones (assumptions)
Información adicional
Vistas relacionadas
“4+1 vistas”
Logical View
End-user
Functionality
Implementation View
Scenarios
Process View
System integrators
Performance
Scalability
Throughput
Conceptual
Programmers
Software management
Deployment View
System engineering
System topology
Delivery, installation
Communication
Physical
Vistas de la arquitectura de un
sistema - adaptada a UP
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
Vista de
realidad en varios tipos de
Vista de diseño
implementación modelo o vistas, cada una
Vista de
centrada en un aspecto o
punto de vista del sistema. En
casos de
general, independientemente
uso
del proceso que se emplee, se
Vista de
Vista de
puede encontrar las siguientes
procesos
despliegue
vistas
Vistas de la arquitectura de un sistema
vocabulario,
funcionalidad
Vista de
implementación
Vista de
casos de
uso
Vista de
Vista de
procesos
despliegue
Vista de diseño
comportamiento
Funcionamiento,
capacidad de
crecimiento,
rendimiento
ensamblado del
sistema,
gestión de
configuraciones
topología del
sistema,
distribución,
entrega,
instalación
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 Diagramas de casos de
como es percibido por los: usuarios finales, ana- uso
listas y encargados de las pruebas. Especifica
las fuerzas que configuran la arquitectura del
sistema.
Diagramas de interacción
Diagramas de estados
Vista de diseño
Soporta los requisitos funcionales del sistema: Diagramas de clases
servicios proporcionados a los usuarios finales. Diagramas de objetos
Vocabulario del problema y su solución: clases,
interfaces y colaboraciones.
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de procesos
Cubre el funcionamiento, capacidad de creci- Diagramas de clases
miento y rendimiento del sistema. Mecanismos (activas)
de sincronización y concurrencia del sistema: Diagramas de objetos
hilos y procesos.
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de implementación
Cubre la gestión de configuraciones de las distin- Diagramas de compotas versiones de un sistema a partir de compo- nentes
nentes y archivos quasi-independientes. Ensamblado y disponibilidad del sistema: componentes
y archivos.
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de despliegue Contiene los nodos que forman la arquitectura Diagramas de desplie(topología) hardware sobre la que se ejecuta el gue
sistema a través de sus componentes. Está destinada a representar la distribución, entrega e
instalación de las partes que forman el sistema
informático físico.
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
VISTAS Y DIAGRAMAS EN UML
Diagrama de
Casos de
Uso
Vista de Casos Estática
de Uso
Dinámica
Vista de
Diseño
Estática
Dinámica
Vista de
Procesos
Estática
Dinámica
Vista de
Implementación
Vista de
Despliegue
Estática
Dinámica
Estática
Dinámica
Diagrama
de
InteracciónSecuencia
Diagrama Diagrade
ma de
Interacción- Clases
Colaboración
Diagrama de
Objetos
Diagrama Diagrama Diagrama
de
de
de CompoEstados
Activida- nentes
des
Diagrama
de Despliegue
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
Implementation
Model
Content
Deployment
Model
Test
Model
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
Implementation view
Deployment 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
•
•
•
•
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
•
Página de título
Historia de cambios
Tabla de contenido
Lista de figuras
Alcance
Referencias
Arquitectura de software
Metas y restricciones arquitectónicas
Arquitectura lógica
Arquitectura de procesos
Arquitectura de desarrollo
Arquitectura física
Escenarios
Tamaño y desempeño
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
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.
Structural Diagrams
Behavioral Diagrams
Package
Use Case
Class
Analysis
Object
Activity
Composite Structure
Component
State
Communication
Sequence
Deployment
Custom
Timing
Interaction
Requerimientos
Requerimientos
custom Manage Users
REQ016 -Add
Users
REQ017 -Remove
User
REQ011 - Manage
User Accounts
REQ025 - Store
User Details
REQ018 - Report
on User Account
REQ024 - Secure
Access
REQ026 - Validate
User
Stakeholders - Requerimientos
custom Stakeholders Interests
REQ001 - Relation between
orders and email inquires.
Process Manager
REQ006 - Efficient stock
control management.
Business Manager
REQ002 - Create a secure
on-line ordering system.
Chief Executiv e Officer
REQ003 - High Volume
Through-put
Modelo del negocio
Casos de Uso
analysis Login
Client
LoginAcount
Login
(from Actors)
Account
analysis View History
Account
View History
Client
(from Actors)
Transaction
Casos de Uso
Trazabilidad
Casos de Uso con
los
Requerimientos
Vista de
Componentes
Vista de Desarrollo
Vista de Desarrollo
deployment HO Serv ers
DMZ
Web Serv er :Dell
Pow erEdge 2650
Disk Controller = RAID 5
Disks = 4 x 80 GB
Processor = 2 x 2.8 GHZ
RAM = 2 x 1024 MB
216.239.46.96 :
Ethernet Adaptor
FRR01 :Intel 19510
Frame Relay Router
HOES01 :Ethernet
Sw itched Hub
WebDataServ er :Dell
Pow erEdge 6650
Vista de
Despliegue
Disk Controller = RAID 5
Disks = 3 x 120 GB
Processor = 3.0 GHz
RAM = 1024 Mb
+Internet
+DMZ
HOFW :
WatchGuard III
Firew all
216.239.46.95 :
Ethernet Adaptor
+LAN
LAN
192.168.02 :
Ethernet Adaptor
Mail Serv er :HP ProLiant
DL380
Disk Controller = RAID 5
Disks = 4
Processor = 3.0 Ghz
RAM = 2048 Mb
HOES02 :Ethernet
Sw itched Hub
Client Data Serv er :Dell
Pow erEdge 1650
192.168.0.3 :
Ethernet Adaptor
Disk Controller = RAID 5
Disks = 4 x 120 GB
RAM = 1024 MB
Processor = 3.0 GHZ
Vista de Despliegue
deployment HO Serv er Images
DMZ
«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
Web Serv er :Dell
Pow erEdge 2650
FRR01 :Intel 19510 Frame
Relay Router
HOES01 :Ethernet
Sw itched Hub
+Internet
+DMZ
HOFW :WatchGuard
III Firew all
«secure»
216.239.46.95 :
Ethernet Adaptor
WebDataServ er :Dell
Pow erEdge 6650
«pc server»
RAM = 1024 Mb
Processor = 3.0 GHz
Disks = 3 x 120 GB
Disk Controller = RAID
5
Vista de Despliegue