Arquitectura de Software

II: Representación

Hernán Astudillo
Departamento de Informática
Universidad Técnica Federico Santa María
<hernan at acm.org>

Contenido del curso

P • 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

Sesión 02 Arquitectura de Software - 2

H.Astudillo

1
 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 - 3

H.Astudillo

Ejemplo de... ¿qué?

Sesión 02 Arquitectura de Software - 4

H.Astudillo

2
 En realidad...

¡¡¡ESTOS SON DIAGRAMAS !!!

¡¡¡NO MODELOS !!!

Sesión 02 Arquitectura de Software - 5

H.Astudillo

In reality…
• “These pictures are meant to entertain you. There is no
significant meaning to the arrows between the boxes.”
– (Citado en [Clements+ 2002])

Sesión 02 Arquitectura de Software - 6

H.Astudillo

3
 ¿Y esto?

Sesión 02 Arquitectura de Software - 7

H.Astudillo

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 (!)

Sesión 02 Arquitectura de Software - 8

H.Astudillo

4
 Stakeholders
analista sp
ec
s

arquitecto
arquitetura
revisor

arq
uit
ra
tu

etu
ite

ra
qu
ar

jefe de
implantador sis
projeto tem
a
QA sis
tem
a
admin

Sesión 02 Arquitectura de Software - 9

H.Astudillo

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

Sesión 02 Arquitectura de Software - 10

H.Astudillo

5
 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 - 11

H.Astudillo

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

Sesión 02 Arquitectura de Software - 12

H.Astudillo

6
 Complejidad
• Fuentes de complejidad
– Imprecisión
– Intangibilidad
– Concurrencia en ejecución
– Concurrencia en construcción
– Diversificación
• (líneas de productos)
– Tamaño

Sesión 02 Arquitectura de Software - 13

H.Astudillo

Vistas y Viewtypes

7
 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 ancladas
en 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 - 15

H.Astudillo

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

Sesión 02 Arquitectura de Software - 16

H.Astudillo

8
 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 - 17

H.Astudillo

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

Sesión 02 Arquitectura de Software - 18

H.Astudillo

9
 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)

Sesión 02 Arquitectura de Software - 19

H.Astudillo

Vistas históricas y en uso

10
 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 - 21

H.Astudillo

Vistas antes de “vistas”: Parnas

Parnas (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

Sesión 02 Arquitectura de Software - 22

H.Astudillo

11
 Booch y OMT

1. Visión Estructural

2. Visión Dinámica

3. Visión Funcional

Sesión 02 Arquitectura de Software - 23

H.Astudillo

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 estados
3. Vista funcional: procesamiento de informaci ón
• sobre: procesamiento de valores
• para: describir dependencia entre valores y funciones
• representaci ón: diagrama de flujo de datos

Sesión 02 Arquitectura de Software - 24

H.Astudillo

12
 Booch

Semántica dinámica

Semántica estática

Estructura de Clase
1. Visión lógica Estructura de Objeto

Arquitectura de Módulo
2. Visión física Arquitectura de Proceso

Sesión 02 Arquitectura de Software - 25

H.Astudillo

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

Sesión 02 Arquitectura de Software - 26

H.Astudillo

13
 ***DIBUJO***
• 4+1

Sesión 02 Arquitectura de Software - 27

H.Astudillo

Diferencias
• Orientado a proceso vs. producto
• Síncronas vs. diácronas
• Roles especializados vs. aspectos de un mismo especialista

Sesión 02 Arquitectura de Software - 28

H.Astudillo

14
 RM-ODP [1]
• Open Distributed Processing – Reference Model
– originalmente para describir sistemas de Telecom

Visión de
Empresa

política

Visión de Visión de
Información Computación

Visión de
Ingeniería

Visión de
Tecnología

Sesión 02 Arquitectura de Software - 29

H.Astudillo

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

Sesión 02 Arquitectura de Software - 30

H.Astudillo

15
 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 - 31

H.Astudillo

Hofmeister+

Sesión 02 Arquitectura de Software - 32

H.Astudillo

16
 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 - 33

H.Astudillo

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ógica
4. Vista física (tecnología)
5. Vista de proyecto
6. Vista del sistema listo (funciones)
• (ver notas)

Sesión 02 Arquitectura de Software - 34

H.Astudillo

17
 TM
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why
List of Things Important List of Processes the List of Locations in which List of Organizations List of Events Significant List of Business Goals/Strat
SCOPE to the Business Business Performs SCOPE
the Business Operates Important to the Business to the Business
(CONTEXTUAL) (CONTEXTUAL)

Planner ENTITY = Class of Function = Class of Node = Major Business Ends/Means=Major Bus. Goal/
Business Thing Business Process People = Major Organizations Time = Major Business Event Critical Success Factor
Planner
Location
e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan
ENTERPRISE ENTERPRISE
System
MODEL MODEL
(CONCEPTUAL) (CONCEPTUAL)

Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective Owner
Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy

e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System e.g. Human Interface e.g. Processing Structure e.g., Business Rule Model
Architecture Architecture
SYSTEM
SYSTEM MODEL
MODEL (LOGICAL)
(LOGICAL)

Node = I/S Function

Ent = Data Entity Proc .= Application Function People = Role Time = System Event
(Processor, Storage, etc) End = Structural Assertion Designer
Designer Reln = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverable Cycle = Processing Cycle Means =Action Assertion
e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design
TECHNOLOGY TECHNOLOGY
MODEL MODEL
(PHYSICAL) (PHYSICAL)

Node = Hardware/System
Builder Ent = Segment/Table/etc. Proc.= Computer Function Software People = User Time = Execute End = Condition Builder
Reln = Pointer/Key/etc. I/O = Data Elements/Sets Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action
e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED
DETAILED
REPRESEN- REPRESEN-
TATIONS TATIONS
(OUT-OF- (OUT-OF
CONTEXT) CONTEXT)

Sub-
Proc.= Language Stmt End = Sub-condition Sub-
Contractor Ent = Field Node = Addresses People = Identity Time = Interrupt
Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step Contractor

FUNCTIONING FUNCTIONING
e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
ENTERPRISE ENTERPRISE

John A. Zachman, Zachman International (810) 231-0531

Figura A.1 – Framework de Zachman

Sesión 02 Arquitectura de Software - 35

H.Astudillo

Notaciones para vistas

18
 Notaciones para vistas
• 2 grandes formas
– Gráfica
• UML, otros
– Formal
• “Arquitecture Description Languaegs” (ADLs)

Sesión 02 Arquitectura de Software - 37

H.Astudillo

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”)

Sesión 02 Arquitectura de Software - 38

H.Astudillo

19
 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 - 39

H.Astudillo

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

Sesión 02 Arquitectura de Software - 40

H.Astudillo

20
MM de interfaces de aplicaciones

Sesión 02 Arquitectura de Software - 41

H.Astudillo

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

Sesión 02 Arquitectura de Software - 42

H.Astudillo

21
 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 - 43

H.Astudillo

Darwin: pipes [1]

component Server {
provide p;
}
component Client {
require r;
}
component System
inst
A: Client;
B: server;
bind
A.r – B.p;
}

Sesión 02 Arquitectura de Software - 44

H.Astudillo

22
 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;
}

Sesión 02 Arquitectura de Software - 45

H.Astudillo

Algunos casos para estudio

crítico

23
 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 - 47

H.Astudillo

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)

Sesión 02 Arquitectura de Software - 48

H.Astudillo

24
 MINVU Obras [2]

Sesión 02 Arquitectura de Software - 49

H.Astudillo

MINVU Obras – Análisis

• Propósito
• Estilo
• Audiencias
• Destacamos:
– Explicación
– Refinamiento
– Rastreabilidad
• Evaluación
– Ajuste a propósito(s)

Sesión 02 Arquitectura de Software - 50

H.Astudillo

25
 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)

Sesión 02 Arquitectura de Software - 51

H.Astudillo

26