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


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


4

Ejemplo de... ¿qué?

3


5

En realidad...

¡¡¡ESTOS SON DIAGRAMAS !!!

¡¡¡NO MODELOS !!!


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


7

¿Y esto?


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


9

Stakeholders

arquitecto

revisor

specs

sistema

implantador

arquitetura

QA

analista

arquitetura

admin

sistema

arquit

etura

jefe deprojeto


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


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


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


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


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


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


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


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


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


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


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


23

Booch y OMT

1. 1. VisiónVisión EstructuralEstructural

2. 2. VisiónVisión DinámicaDinámica

3. 3. VisiónVisión FuncionalFuncional


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


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


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


27

***DIBUJO***• 4+1


28

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

15


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


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


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


32

Hofmeister+

17


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


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


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


37

Notaciones para vistas• 2 grandes formas

– Gráfica• UML, otros

– Formal• “Arquitecture Description Languaegs” (ADLs)


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


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


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


41

MM de interfaces de aplicaciones


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


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


44

Darwin: pipes [1]component Server {

provide p;}component Client {

require r;}component System

instA: Client;B: server;

bindA.r – B.p;

}

23


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


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)


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


49

MINVU Obras [2]


50

MINVU Obras – Análisis• Propósito• Estilo• Audiencias• Destacamos:

– Explicación– Refinamiento– Rastreabilidad

• Evaluación– Ajuste a propósito(s)

26


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)

Arquitectura de Software II: Representaciónhernan/cursos/MII414-2004s2/... · 2004-09-07 ·...

Documents

Transcript of Arquitectura de Software II: Representaciónhernan/cursos/MII414-2004s2/... · 2004-09-07 ·...