Arquitectura de Software II: Representaciónhernan/cursos/MII414-2004s2/... · 2004-09-07 ·...
-
Upload
nguyendien -
Category
Documents
-
view
216 -
download
0
Transcript of Arquitectura de Software II: Representaciónhernan/cursos/MII414-2004s2/... · 2004-09-07 ·...
1
Arquitectura de SoftwareII: Representación
Hernán AstudilloDepartamento de Informática
Universidad Técnica Federico Santa María<hernan at acm.org>
Sesión 02 Arquitectura de Software -H.Astudillo
2
Contenido del curso• Introducción, motivación y contexto• Representación de arquitecturas
– Vistas Viewtypes– Vistas históricas y en uso– Notaciones para vistas
• Elaboración de arquitecturas– Estilos– Patrones– Líneas de productos– Recuperación de arquitectura
• Principios y evaluación de arquitecturas– Principios y axiomas– Evaluación de arquitecturas
• Prácticas de arquitectura– Organizaciones y Mercados– Componentes
P
2
Sesión 02 Arquitectura de Software -H.Astudillo
3
II: Representación• Vistas
– Vistas y perspectivas– Vistas sincrónicas y diacrónicas– Booch, OMT, 4+1, RM-ODP, Zachman– “Viewtypes”
• Notaciones para vistas– UML– Lenguajes de RM-ODP– ADLs
Sesión 02 Arquitectura de Software -H.Astudillo
4
Ejemplo de... ¿qué?
3
Sesión 02 Arquitectura de Software -H.Astudillo
5
En realidad...
¡¡¡ESTOS SON DIAGRAMAS !!!
¡¡¡NO MODELOS !!!
Sesión 02 Arquitectura de Software -H.Astudillo
6
In reality…• “These pictures are meant to entertain you. There is no
significant meaning to the arrows between the boxes.”– (Citado en [Clements+ 2002])
4
Sesión 02 Arquitectura de Software -H.Astudillo
7
¿Y esto?
Sesión 02 Arquitectura de Software -H.Astudillo
8
Modelos• No todo diagrama es un modelo
– Modelo: representación simplificada de la realidad• que puede ser manipulada para comprender mejor la realidad• idealmente predictiva
• Modelos requeridos en arquitectura de SW– del dominio (el problema)– del sistema (software y computaciones) (la solución)– del proceso (para construir el sistema)
• Los stakeholders hacen lecturas diferentes– ...pero complementarias– ...y deben ser consistentes (!)
5
Sesión 02 Arquitectura de Software -H.Astudillo
9
Stakeholders
arquitecto
revisor
specs
sistema
implantador
arquitetura
QA
analista
arquitetura
admin
sistema
arquit
etura
jefe deprojeto
Sesión 02 Arquitectura de Software -H.Astudillo
10
Software y computaciones [1]• sw vs. computaciones
– sw: textos– computaciones: run-time
• en testing se distingue:– errores: por personas– defectos: en software– fallas: en ejecución
• debemos distinguir:– especificación del sistema: descripción razonada del sistema– sistema (software): textos a ser escritos– sistemas (computaciones): acciones deseadas
6
Sesión 02 Arquitectura de Software -H.Astudillo
11
Software y computaciones [2]• Nos interesan 5 niveles de descripción
– Computaciones: acciones del sistema• dueño: usuario (a diferencia del cliente)
– Desplegables: binarios, configs … para crear computaciones• dueño: admin del sistema
– Software: textos para construir desplegables• dueño: desarrollador
– Especificaciones de arquitectura: para construir software• dueño: arquitecto
– Proceso: actividades para construir especificaciones• dueño: jefe de proyecto
• Otras nociones pueden atarse a estos niveles– Calidad– Generación
Sesión 02 Arquitectura de Software -H.Astudillo
12
Software y computaciones [3]• Problema:
– Queremos poder hablar de “defecto de una arquitectura” (como en prueba de SW)
– …pero los problemas que nos interesan son problemas sistémicos (no trazables a un lugar único)
• Idea:– (cuadrar el círculo)– Describir arquitecturas en que permitan asociar “defectos” (de
arquitectura) y “fallas” (sistémicas)• Posible solución
– Hablar en políticas y mecanismos
7
Sesión 02 Arquitectura de Software -H.Astudillo
13
Complejidad• Fuentes de complejidad
– Imprecisión– Intangibilidad– Concurrencia en ejecución– Concurrencia en construcción– Diversificación
• (líneas de productos)– Tamaño
Vistas y Viewtypes
8
Sesión 02 Arquitectura de Software -H.Astudillo
15
Vistas de Arquitectura• De requisitos a arquitectura
– Hay varias soluciones de arquitectura para cada conjunto de requisitos
– En general, no hay una solución óptima– La solución escogida depende de compromisos entre los
“stakeholders”– La arquitectura de software debería facilitar las negociaciones
entre “stakeholders” y la captura de decisiones finales ancladasen los compromisos
• Espacios de decisión para compromisos [Hofmeister00]– Tecnológico– Organizacional– Producto
• Para justificar los compromisos hay que mirar la arquitectura desde diferentes perspectivas– Desde la organización al desarrollo y despliegue
Sesión 02 Arquitectura de Software -H.Astudillo
16
Tipos de vistas• “Viewtypes” [Clements+ 2002]
– Maneras simultáneas de pensar sobre sistemas de software– Restringen los elementos y relaciones disponibles en sus vistas
• 3 maneras propuestas:– módulos
• estructura como conjunto de unidades de implantación– componentes-y-conectores
• estructura como conjunto de elementos con comportamiento e interacciones durante ejecución
– “allocation” (asignación)• relación con estructuras no-software del ambiente
9
Sesión 02 Arquitectura de Software -H.Astudillo
17
Viewtype Módulos• Módulo: unidad de código que implementa un conjunto de
responsabilidades– Ejemplos: clase, colección de clases, capa…– Propiedades: responsabilidades, visibilidad, autor…– Relaciones: parte-de, hereda-de…
• Estilos de representación– Descomposición (en sistemas, subsistemas, etc.)– Uso (dependencias)– Generalización– En Capas
Sesión 02 Arquitectura de Software -H.Astudillo
18
Viewtype Componentes+Conectores• Expresa comportamiento en ejecución
– Elementos: componentes y conectores– Descomposición: conectores a componentes+conectores , etc.
• Estilos de representación– Pipe and filter– Shared data– Publish-subscribe– Cliente-servidor– Peer-to-peer– Communicating Processes
10
Sesión 02 Arquitectura de Software -H.Astudillo
19
Viewtype Asignación• Mapeo de elementos de software a elementos del ambiente• Estilos de representación
– Despliegue (deployment) (mapeo de procesos a hardware)– Implantación (módulos a infraestructura de desarrollo)– Asignación de trabajo (módulos a equipos de desarrollo)
Vistas históricas y en uso
11
Sesión 02 Arquitectura de Software -H.Astudillo
21
Vista• Representación de un (sub-)sistema...
– ...parcial– ...basada en una perspectiva
• Idea:– participantes necesitan razonar sobre el sistema– entregar información que suprima detalles irrelevantes
• Conceptos– Vista = representación de un conjunto de elementos y relaciones
del sistema [Clements+]– Perspectiva = preocupaciones propias de un stakeholder– Esquema de vistas = definiciones de vistas y perspectivas
asociadas
Sesión 02 Arquitectura de Software -H.Astudillo
22
Vistas antes de “vistas”: ParnasParnas (1974): “estructuras” (=unidad + relación)
1. módulos• sobre: asignaciones de trabajo, parte-de• para: razonar sobre construcción
2. usos• sobre: programas, depende-de• para: razonar sobre dependencias
3. procesos• sobre: procesos, trabaja-con• para: razonar sobre ejecución
12
Sesión 02 Arquitectura de Software -H.Astudillo
23
Booch y OMT
1. 1. VisiónVisión EstructuralEstructural
2. 2. VisiónVisión DinámicaDinámica
3. 3. VisiónVisión FuncionalFuncional
Sesión 02 Arquitectura de Software -H.Astudillo
24
Booch y OMT• OMT: Rumbaugh, Blaha, Premerlani, Eddy, Lorenson (1991)
1. Vista estructural: estructura estática del mundo real• sobre: objetos y relaciones• representación: diagrama de objetos
2. Vista dinámica: comportamiento del sistema• sobre: acciones en el tiempo• para: describir secuencias de interacciones y eventos• representación: diagrama de eventos (escenarios), diagrama de
flujo de eventos, diagrama de estados3. Vista funcional: procesamiento de información
• sobre: procesamiento de valores• para: describir dependencia entre valores y funciones• representaci ón: diagrama de flujo de datos
13
Sesión 02 Arquitectura de Software -H.Astudillo
25
Booch
SemánticaSemántica dinámicadinámica
SemánticaSemántica estáticaestática
EstructuraEstructura de de ClaseClase
EstructuraEstructura de Objetode Objeto
ArquitecturaArquitectura de Módulode Módulo
ArquitecturaArquitectura de de ProcesoProceso
1. 1. VisiónVisión lógicalógica
2. 2. VisiónVisión físicafísica
Sesión 02 Arquitectura de Software -H.Astudillo
26
Kruchten “4+1”• Kruchten (1995): 4+1 “views”
1. Vista lógica: requisitos funcionales• sobre: abstracciones clave del dominio (objetos/clases)• para: completitud de requisitos, síntesis de entidades y funciones
2. Vista de procesos: ejecución• sobre: procesos y máquinas• para: concurrencia/distribución, integridad, tolerancia a fallas
3. Vista de desarrollo: software y trabajo• sobre: módulos, asignación de requisitos, asignación de trabajo• para: planificar, evaluar costos, medir progreso, razonar sobre reuso
4.Vista física: requisitos no funcionales• sobre: mapeamiento de elementos a máquinas• para: razonar sobre requisitos no funcionales (disponibilidad, confiabilidad,
rendimiento, escalabilidad...)5.Vista de escenarios: combinación
• sobre: casos de uso
14
Sesión 02 Arquitectura de Software -H.Astudillo
27
***DIBUJO***• 4+1
Sesión 02 Arquitectura de Software -H.Astudillo
28
Diferencias• Orientado a proceso vs. producto• Síncronas vs. diácronas• Roles especializados vs. aspectos de un mismo especialista
15
Sesión 02 Arquitectura de Software -H.Astudillo
29
RM-ODP [1]• Open Distributed Processing – Reference Model
– originalmente para describir sistemas de Telecom
p o l í t i c a
Visión de Empresa
Visión deIngeniería
Visión deTecnología
Visión deInformación
Visión deComputación
Sesión 02 Arquitectura de Software -H.Astudillo
30
RM-ODP [2]1. Vista de la empresa
• sobre: propósito, ámbito y restricciones que rigen el negocio• para: extraer requisitos y estructuras de la organización
2. Vista da información• sobre: información (datos) requeridos por el sistema• representación: esquemas (estático, invariante, y dinámico)
3. Vista computacional• sobre: aplicaciones y objetos de infraestructura (interfaces,
actividades, contratos); modelos dinámicos• para: descomponer funcionalidad
4. Vista de ingeniería• sobre: objetos y canales • para: infraestructura de distribución
5. Vista tecnológica• sobre: hardware y software específicos• para: razonar sobre tecnología y productos
16
Sesión 02 Arquitectura de Software -H.Astudillo
31
Hofmeister+• Propuestas por [Hofmeister+]
– Vista Conceptual– Vista Tecnológica– Vista Física– Vista de Desarrollo
• Extensión de Rito-Silva para Fénix– Vista de Objetivos– Vista del Negocio
Sesión 02 Arquitectura de Software -H.Astudillo
32
Hofmeister+
17
Sesión 02 Arquitectura de Software -H.Astudillo
33
Vista de Objetivos• Permite [Rito-Silva]
– Identificación de los factores que influencian la arquitectura• Los “porqué”
– La definición de estrategias para la solución• Los “cómo”
• Decisiones de diseño se basarán en las estrategias aquí definidas
Sesión 02 Arquitectura de Software -H.Astudillo
34
Zachman• Marco metodológico para vistas
– Enfocado a organizaciones– Estructura lógica: clasifica y organizar elementos
empresariales necesarios para hacer sistemas• Vistas
1. Vista contextual (propósito del negocio)2. Vista conceptual (naturaleza del negocio)3. Vista arquitectural o lógica4. Vista física (tecnología)5. Vista de proyecto6. Vista del sistema listo (funciones)
• (ver notas)
18
Sesión 02 Arquitectura de Software -H.Astudillo
35
e.g. DATA
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE(CONTEXTUAL)
MODEL(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEMMODEL(LOGICAL)
TECHNOLOGYMODEL(PHYSICAL)
DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = FieldReln = Address
e.g. Physical Data Model
Ent = Segment/Table/etc.Reln = Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Ent i tyReln = Data Relationship
e.g. Semantic Model
Ent = Business EntityReln = Business Relationship
List of Things Importantto the Business
ENTITY = Class ofBusiness Thing
List of Processes theBusiness Performs
Function = Class ofBusiness Process
e.g. Application Architecture
I/O = User ViewsProc .= Application Function
e.g. System Design
I/O = Data Elements/SetsProc.= Computer Function
e.g. Program
I/O = Control BlockProc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business ProcessI/O = Business Resources
List of Locations in which the Business Operates
Node = Major BusinessLocation
e.g. Business Logistics System
Node = Business LocationLink = Business Linkage
e.g. Distributed System
Node = I /S Funct ion(Processor, Storage, etc)Link = Line Characteristics
e.g. Technology Architecture
Node = Hardware/SystemSof tware
Link = Line Specifications
e.g. Network Architecture
Node = AddressesLink = Protocols
e.g. NETWORK
Architecture
Planner
Owner
Builder
ENTERPRISEMODEL
(CONCEPTUAL)
Designer
SYSTEMMODEL
(LOGICAL)
TECHNOLOGYMODEL
(PHYSICAL)
DETAILEDREPRESEN-
TATIONS (OUT-OF
CONTEXT)
Sub-Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. Rule Design
End = Condit ionMeans = Action
e.g., Business Rule Model
End = Structural AssertionMeans =Action Assertion
End = Business ObjectiveMeans = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing CycleTime = System Event
e.g. Control Structure
Cycle = Component CycleTime = Execute
e.g. Timing Definition
Cycle = Machine CycleTime = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business EventCycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization UnitWork = Work Product
e.g. Human Interface
People = RoleWork = Deliverable
e.g. Presentation Architecture
People = UserWork = Screen Format
e.g. Security Architecture
People = IdentityWork = Job
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What H o w Where Who When W h y
John A. Zachman, Zachman International (810) 231-0531
SCOPE(CONTEXTUAL)
Architecture
e.g. STRATEGYENTERPRISE
e.g. Business Plan
TM
Figura A.1 – Framework de Zachman
Notaciones para vistas
19
Sesión 02 Arquitectura de Software -H.Astudillo
37
Notaciones para vistas• 2 grandes formas
– Gráfica• UML, otros
– Formal• “Arquitecture Description Languaegs” (ADLs)
Sesión 02 Arquitectura de Software -H.Astudillo
38
UML• UML es 3 cosas
– Notación• para describir cosas con orientación a objetos
– Meta-modelo de sistemas de software• clases, subsistemas, componentes, nodos
– Mecanismo extensible• para describir cosas usando orientación a objetos• estereotipos, perfiles…• lenguaje: OCL (“Object Constraints Language”)
20
Sesión 02 Arquitectura de Software -H.Astudillo
39
Vistas y diagramas• Los stakeholders leen/usan documentos
– Vistas describen aspectos del sistema– Diagramas son notación
• Relación M:N– Una vista puede requerir varios tipos de diagramas– Un tipo de diagrama puede ser usado en varias vistas
• Ejemplos– Perfiles de UML
• EDOC: Enterprise Distributed Object Computing• EAI: Enterprise Application Integration
– RM-ODP• “Lenguajes” para cada vista
Sesión 02 Arquitectura de Software -H.Astudillo
40
Perfil UML para EAI• Existe un perfil UML para EAI
– UML Profile for EAI• 2 metamodelos:
– MM de Integración: especializa el “Flow Composition Model”• (que especializa el “UML Profile for EDOC”)
– MM Común de Aplicaciones• MM de interfaces de aplicaciones• MM de lenguajes• MM de representaciones físicas
21
Sesión 02 Arquitectura de Software -H.Astudillo
41
MM de interfaces de aplicaciones
Sesión 02 Arquitectura de Software -H.Astudillo
42
ADLs• “Architecture Description Languages”
– Formales– Objetivo: permitir razonamiento automatizado
• Problemas propios de métodos formales– Más difícil (aún) probar que algo está correcto que escribirlo
varias veces
22
Sesión 02 Arquitectura de Software -H.Astudillo
43
ADL: Darwin• Darwin [Jazayeri/Ran/van der Linden]• Conceptos
– componentes con servicios (provistos y requeridos)– instanciación y “binding”– configuraciones: guardas y replicación
• (ver ejemplo)– interfaces compuestas– tipos genéricos– evaluación parcial
Sesión 02 Arquitectura de Software -H.Astudillo
44
Darwin: pipes [1]component Server {
provide p;}component Client {
require r;}component System
instA: Client;B: server;
bindA.r – B.p;
}
23
Sesión 02 Arquitectura de Software -H.Astudillo
45
Darwin: pipes [2]component pipeline (int n) {
provide input;require output;array F[n] : filter;forall k : 0..n-1 {
inst F[k ] (n, k);bind F[k ].output – output;when k < n-1
bind F[k].next – F[K+1].prev;
}bind
input – F[0].prev;F[n-1].next – output;
}
Algunos casos para estudio crítico
24
Sesión 02 Arquitectura de Software -H.Astudillo
47
Ejemplo: Cash-Link• Ejemplo publicado
– OOPSLA 2000 Practitioner Report• Comentarios
– largo (124 pp.)– dirigido a múltiples audiencias– cuenta una historia
• y ofrece una metáfora– exhibe rastreabilidad (refinamiento derivable)
Sesión 02 Arquitectura de Software -H.Astudillo
48
Ejemplo: MINVU Obras• Sistema público
– Requisitos disponibles en sitio Web del curso• …/ejemplos/MINVU_Obras-Bases_Tecnicas.PDF• …/ejemplos/MINVU_Obras-Plataforma.PDF
– Solución propuesta• ver notas• MINVU_Obras-Propuesta_Tecnica (42 pags)
25
Sesión 02 Arquitectura de Software -H.Astudillo
49
MINVU Obras [2]
Sesión 02 Arquitectura de Software -H.Astudillo
50
MINVU Obras – Análisis• Propósito• Estilo• Audiencias• Destacamos:
– Explicación– Refinamiento– Rastreabilidad
• Evaluación– Ajuste a propósito(s)
26
Sesión 02 Arquitectura de Software -H.Astudillo
51
Referencias• [Clements+ 2002]
– Paul Clements (Ed.), Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford
– Documenting Software Architectures: Views and Beyond– Addison Wesley (2002)
• [Kruchten 2000]– Philippe Kruchten– The Rational Unified Process: An Introduction (2nd Ed.)– Addison Wesley (2000)
• [Jazayeri+ 2000]– Mehdi Jazayeri, Alexander Ran, Frank van der Linden– Software Architectures for Product Families– Addison Wesley (2000)