Contenido del curso

motivación y contexto P•• Introducción, Representación de arquitecturas

Arquitectura de Software II: Representación

– Vistas – Calidad

• Elaboración de arquitecturas – Patrones – Líneas de productos

• Procesos y evaluación de arquitecturas – Procesos (incl. taller)

Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María

• Prácticas de arquitectura

– Organizaciones y Mercados – Componentes

Sesión 02 [2004-ii-17]

II: Representación

Arquitectura de Software H.Astudillo

2

Ejemplo de... ¿qué?

• Fuentes de diversidad • Vistas – Vistas y perspectivas – Vistas sincrónicas y diacrónicas – Booch, OMT, 4+1, RM-ODP, Zachman

• Notaciones para vistas – UML, lenguajes de RM-ODP, ADLs

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

3

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

Otro ejemplo

4

En realidad...

[*** CORBA ***]

ESTOS SON DIAGRAMAS !!! NO MODELOS !!!

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

5

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

6

1

Modelos

Stakeholders

• No todo diagrama es un modelo – Modelo: representación simplificada de la realidad • que puede ser manipulado para comprender mejor la realidad • idealmente predictivo

analista

sp ec s

arquitecto

• Modelos requeridos en arquitectura de SW

arquitetura revisor ar qu ite tu ra

jefe de projeto

• Los stakeholders hacen lecturas diferentes

ra tu ite qu ar

– del dominio (el problema) – del sistema (software y computaciones) (la solución) – del proceso (para construir el sistema)

implantador

– ...pero complementarias – ...y deben ser consistentes (!)

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

7

Sesión 02 [2004-ii-17]

sis tem a

QA

sis tem a

admin

Arquitectura de Software H.Astudillo

8

Complejidad • Fuentes de complejidad – – – – –

Imprecisión Intangibilidad Concurrencia en ejecución Concurrencia en construcción Diversificación

Vistas

• (líneas de productos)

– Tamaño

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

9

Vistas

Modelo conceptual (Clements et al.) • [*** unidades y relaciones ***]

• 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 [2004-ii-17]

Arquitectura de Software H.Astudillo

11

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

12

2

Vistas antes de “vistas”: Parnas Parnas (1974): “estructuras” (=unidad + relación)

• sw vs. computaciones

1. módulos • •

– sw: textos – computaciones: run-time

sobre: asignaciones de trabajo, parte-de para: razonar sobre construcción

• en testing se distingue:

2. usos • •

– errores: por personas – defectos: en software – fallas: en ejecución

sobre: programas, depende-de para: razonar sobre dependencias

3. procesos • •

• debemos distinguir:

sobre: procesos, trabaja-con para: razonar sobre ejecución

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

Software y computaciones [1]

– especificación del sistema: descripción razonada del sistema – sistema (software): textos a ser escritos – sistemas (computaciones): acciones deseadas 13

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

Software y computaciones [2]

14

Booch y OMT

• Para aclarar ideas – Software: textos – Computaciones: acciones – “Herencia”: subclases != subtipos

1. Visión Estructural

• reuso de código vs. substitutabilidad (“conformance”)

2. Visión Dinámica 3. Visión Funcional

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

15

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

Booch y OMT

16

Booch

• OMT: Rumbaugh, Blaha, Premerlani, Eddy, Lorenson (1991) 1. Vista estructural: estructura estática del mundo real • sobre: objetos y relaciones

Semántica dinámica

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

Semántica estática

1. Visión lógica

3. Vista funcional: procesamiento de información • sobre: procesamiento de valores • para: describir dependencia entre valores y funciones • Representación: diagrama de flujo de dados Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

2. Visión física

17

Sesión 02 [2004-ii-17]

Estructura de Clase Estructura de Objeto Arquitectura de Módulo Arquitectura de Proceso

Arquitectura de Software H.Astudillo

18

3

Kruchten “4+1” [1] • Kruchten (1995): 4+1 “views”

Kruchten “4+1” [2] 4.Vista física: requisitos no funcionales • •

1. Vista lógica: requisitos funcionales

• sobre: abstracciones clave del dominio (objetos/clases) • para: completitud de requisitos, síntesis de entidades y funciones

sobre: mapeamiento de elementos a máquinas para: razonar sobre requisitos no funcionales (disponibilidad, confiabilidad, rendimiento, escalabilidad...)

5.Vista de escenarios: combinación

2. Vista de procesos: ejecución

•

• sobre: procesos y máquinas • para: concurrencia/distribución, integridad, tolerancia a fallas

sobre: casos de uso

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

• (Cont.)

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

19

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

RM-ODP [1/2]

RM-ODP [2/2] 1. Vista de la empresa

• Open Distributed Processing – Reference Model

•

– originalmente para describir sistemas de Telecom

•

Visión de Empresa

•

política

Visión de Información

• •

sobre: información (datos) requeridos por el sistema representación: esquemas (estático, invariante, y dinámico)

3. Vista computacional •

Visión de Tecnología

Arquitectura de Software H.Astudillo

sobre: propósito, ámbito y restricciones que rigen el negocio para: extraer requisitos y estructuras de la organización de la empresa representación: “enterprise language” (ver ejemplo)

2. Vista da información

Visión de Computación

Visión de Ingeniería

Sesión 02 [2004-ii-17]

20

• 21

sobre: aplicaciones y objetos de infraestructura (interfaces, actividades, contratos); modelos dinámicos para: descomponer funcionalidad

Sesión 02 [2004-ii-17]

RM-ODP (Cont.)

Arquitectura de Software H.Astudillo

22

Otros esquemas de vistas

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 [2004-ii-17]

Arquitectura de Software H.Astudillo

23

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

24

4

ENTERPRISE ARCHITECTURE - A FRAMEWORK

Zachman •

Enfocado a organizaciones Estructura lógica: clasifica y organizar elementos empresariales necesarios para hacer sistemas

Planner ENTERPRISE MODEL (CONCEPTUAL)

Owner

Vistas 1. 2. 3. 4. 5. 6.

•

SCOPE (CONTEXTUAL)

What

List of Things Important to the Business

FUNCTION

How

List of Processes the Business Performs

NETWORK

PEOPLE

Where

List of Locations in which the Business Operates

Who

List of Organizations Important to the Business

TIME

When

List of Events Significant to the Business

TM

MOTIVATION

Why

List of Business Goals/Strat

SCOPE (CONTEXTUAL)

Marco metodológico para vistas – –

•

DATA

ENTITY = Class of Business Thing

Function = Class of Business Process

Node = Major Business Location

e.g. Semantic Model

e.g. Business Process Model

e.g. Business Logistics System

Ent = Business Entity Reln = Business Relationship

Proc. = Business Process I/O = Business Resources

Node = Business Location Link = Business Linkage

e.g. Logical Data Model

e.g. Application Architecture

e.g. Distributed System Architecture

Ent = Data Entity Reln = Data Relationship

Proc .= Application Function I/O = User Views

Node = I/S Function (Processor, Storage, etc) Link = Line Characteristics

People = Role Work = Deliverable

Time = System Event Cycle = Processing Cycle

End = Structural Assertion 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

Ent = Segment/Table/etc. Reln = Pointer/Key/etc.

SYSTEM MODEL (LOGICAL)

Vista contextual (propósito del negocio) Vista conceptual (naturaleza del negocio) Vista arquitectural o lógica Vista física (tecnología) Vista de proyecto Vista del sistema listo (funciones)

Designer TECHNOLOGY MODEL (PHYSICAL)

Builder DETAILED REPRESENTATIONS (OUT-OFCONTEXT) SubContractor

(ver notas)

FUNCTIONING ENTERPRISE

People = Major Organizations

Time = Major Business Event

e.g. Work Flow Model

e.g. Master Schedule

People = Organization Unit Work = Work Product

e.g. Human Interface Architecture

Proc.= Computer Function I/O = Data Elements/Sets

Node = Hardware/System Software Link = Line Specifications

e.g. Data Definition

e.g. Program

e.g. Network Architecture

Ent = Field Reln = Address

Proc.= Language Stmt I/O = Control Block

Node = Addresses Link = Protocols

People = Identity Work = Job

e.g. DATA

e.g. FUNCTION

e.g. NETWORK

e.g. ORGANIZATION

People = User Work = Screen Format

e.g. Security Architecture

Time = Business Event Cycle = Business Cycle

e.g. Processing Structure

Time = Execute Cycle = Component Cycle e.g. Timing Definition

Time = Interrupt Cycle = Machine Cycle e.g. SCHEDULE

Ends/Means=Major Bus. Goal/ Critical Success Factor

e.g. Business Plan

Planner ENTERPRISE MODEL (CONCEPTUAL)

Owner

End = Business Objective Means = Business Strategy e.g., Business Rule Model

SYSTEM MODEL (LOGICAL)

Designer TECHNOLOGY MODEL (PHYSICAL)

Builder

End = Condition Means = Action

DETAILED REPRESENTATIONS (OUT-OF CONTEXT)

e.g. Rule Specification

SubContractor

End = Sub-condition Means = Step e.g. STRATEGY

FUNCTIONING ENTERPRISE

John A. Zachman, Zachman International (810) 231-0531 Figura A.1 – Framework de Zachman

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

25

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

26

UML • UML son 3 cosas – notación – meta-modelo de sistemas de software

Notaciones para vistas

• clases, subsistemas, componentes, nodos

– mecanismo extensible para describir cosas usando orientación a objetos

Sesión 02 [2004-ii-17]

Vistas y diagramas • Los stakeholders leen/usan documentos

Arquitectura de Software H.Astudillo

28

Perfil UML para EAI • Existe un perfil UML para EAI

– Vistas describen aspectos del sistema – Diagramas son notación

– UML Profile for EAI

• 2 metamodelos:

• Relación M:N

– MM de Integración: especializa el “Flow Composition Model”

– Una vista puede requerir varios tipos de diagramas – Un tipo de diagrama puede ser usado en varias vistas

• (que especializa el “UML Profile for EDOC”)

– MM Común de Aplicaciones

• Ejemplos

• MM de interfaces de aplicaciones • MM de lenguajes • MM de representaciones físicas

– Perfiles de UML • EDOC: Enterprise Distributed Object Computing • EAI: Enterprise Application Integration

– RM-ODP • Lenguajes para vistas Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

29

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

30

5

ADLs

MM de interfaces de aplicaciones • “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 [2004-ii-17]

Arquitectura de Software H.Astudillo

31

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

ADL: Darwin • Darwin [Jazayeri/Ran/van der Linden] • Conceptos

32

Darwin: pipes [1] component Server { provide p;

} component Client {

– componentes con servicios (provistos y requeridos) – instanciación y “binding” – configuraciones: guardas y replicación

require r;

} component System

• (ver ejemplo)

– interfaces compuestas – tipos genéricos – evaluación parcial

inst A: Client; B: server;

bind A.r – B.p;

} Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

33

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

34

Darwin: pipes [2] component pipeline (int n) { provide input; require output; array F[n] : filter; forall k : 0..n-1 {

Estudio crítico de caso

inst F[k] (n, k); bind F[k].output – output; when k < n-1

} bind

}

bind F[k].next – F[K+1].prev;

input – F[0].prev; F[n-1].next – output;

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

35

6

Ejemplo: Cash-Link • Ejemplo publicado

Ejemplo: MINVU Obras • Sistema público

– OOPSLA 2000 Practitioner Report

– Requisitos disponibles en sitio Web del curso • www.astudillo.biz/eci2003arquitectura/ejemplos/MINVU_Obras-Bases_Tecnicas.PDF • www.astudillo.biz/eci2003arquitectura/ejemplos/MINVU_Obras-Plataforma.PDF

• Comentarios – largo (124 pp.) – dirigido a múltiples audiencias – cuenta una historia

– Solución propuesta

• y ofrece una metáfora

• ver notas • MINVU_Obras-Propuesta_Tecnica (42 pags)

– exhibe rastreabilidad (refinamiento derivable)

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

37

Sesión 02 [2004-ii-17]

MINVU Obras [2]

Arquitectura de Software H.Astudillo

38

MINVU Obras – Análisis • • • •

Propósito Estilo Audiencias Destacamos: – Explicación – Refinamiento – Rastreabilidad

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

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

39

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

40

Referencias • 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)

• Philippe Kruchten – The Rational Unified Process: An Introduction (2nd Ed.), Addison Wesley (2000)

• Mehdi Jazayeri, Alexander Ran, Frank van der Linden

– Software Architectures for Product Families, Addison Wesley (2000)

Sesión 02 [2004-ii-17]

Arquitectura de Software H.Astudillo

41

7