Elementos de la Descripciones...

1

Arquitectura de software - UML1

Elementos de la Descripciones Arquitectónica

2


Descripción Arquitectónica

• Modelo del Sistema– Es una representación abstracta del sistema creada para

comprender su estructura y operación.

• Descripción Arquitectónica– “Es un documento, producto u otro artefacto - utilizado para

comunicar o registrar la arquitectura del sistema”. (IEEE ArchitectureWorking Group).

– Incluye un conjunto de vistas (views) las cuales describen determinados aspectos de la arquitectura del sistema.

3



Modelos delnegocio

Modelos de requerimientos

de software

Modelos de Diseño

Modelos de Componentes

Modelo del Sistema

Vista de Requerimientos

Vista Lógica (diseño)

Vista de Procesos

Vista de Componentes

Vista de Despliegue

Modelo 4 + 1 (Kruchten)

Vistas

4



VistaDiseño


Vista de Procesos

Vista de Despliegue

Vista de Casos de Uso


5



• Vistas de una Arquitectura (4+1)– Las 5 vistas de la Arquitectura de un Sistema.

• Vista de Casos de Uso (Escenarios)– Describe el comportamiento del sistema, basado en los

principales casos de uso, visto desde la perspectiva de los usuarios, analistas y testers.

• Vista de Diseño (Lógica)– Describe el modelo desde los elementos de diseño y de las

colaboraciones entre ellos.

• Vista de Procesos– Describe aspectos de sincronización y concurrencia.

6



• Vistas de una Arquitectura (4+1) (P. Kruchten)

• Vista de Componentes– Describe la organización estática en su ambiente de desarrollo.

• Vista de Despliegue– Describe la relación entre el software y el hardware y aspectos de

su distribución.

7



• Elementos genéricos de las descripciones arquitectónicas

• Componentes

• Conectores

• Restricciones

• Dependen de la vista a la que pertenezcan

8


Descripción Arquitectónica• Componentes

– Elementos estructurales (datos, unidades computacionales) • Pueden ser simples o compuestos• Ejemplos

– Ejecutables– Bibliotecas dinámicas– Componentes activex– Servidores de aplicaciones– Bases de datos– Clases, objetos y módulos– Paquetes– Procesadores, impresoras– redes– etc.

9



• Conectores– Elementos que modelan las interacciones entre

componentes.

– Ejemplos• Llamadas a procedimientos

• Protocolos (TCP/IP)

• Variables globales

• Asociaciones, dependencias, herencia, etc.

• Mecanismos de IPC (interprocess communictation)

• Links de radio

10



• Restricciones– Representan las leyes que el sistema debe cumplir.

– Son aplicables a componentes y conectores

11


Arquitectura

• Lecturas – The 4+1 View Model of Architecture. P. Kruchten

(Pbk4p1.PDF)

– Toward a Recommended Practice for ArchitecturalDescription. Ellis, et. al. (ieee_white_paper.PDF)

– Foundations for the Study of Software Architecture. D. Perry, A. Wolf (PW92.PDF)

– Capitulo 2. Software Architecture in Practice. L.Bass, P. Clements, R. Kazman

12


Elementos de Descripción de Arquitecturas en UML 2

13


UML

• Unified Modeling Language (UML)– Lenguaje estándar para el modelado de sistemas de

software– Definido por Rational Corp. y actualmente

propiedad del Object Management Group (OMG)– Es extensible y adaptable.– Útil para:

• Visualizar• Especificar y documentar• Mapeable con las construcciones de los lenguajes de

programación

14


UML

• UML comprende:– Elementos estáticos

– Elementos comportamentales

– Elementos de agrupación

– Elementos de anotación

– Elementos de Extensión

15


Arquitectura y Diseño - UML

• Mecanismos de extensión– Stereotype (estereotipo)

• Permite definir nuevos elementos en el metamodelo de UML.

• Es un mecanismo de extensión del lenguaje.

<<nombre_estereotipo>>

Se puede asociar un icono a cada estereotipo.

16



• Mecanismos de extensión – Tagged Values (valores etiquetados)

• Son metadatos que se pueden asociar a los elementos de la notación. Permiten agregar nueva información a los elementos de la notación (estándares o estereotipados)

• Por ejemplo; a los casos de uso se les podría asociar un tag que describa los requerimientos no-funcionales asociados al caso de uso.

{req_no_funcional = “tiempo de respuesta 3 seg.”}

{RAM_procesador = “512 Mb”}

17



VistaDiseño


Vista de Procesos

Vista de Despliegue



18



• Vista de Casos de Uso– Describe el comportamiento observable del sistema

visto desde la perspectiva de los accionistas.• Normalmente incluye:

– Requerimientos funcionales

– Requerimientos no funcionales asociados a los requerimientos funcionales

– Elementos del dominio

19



• Vista de Casos de Uso– Elementos

• Actores

• Casos de Uso

• Colaboraciones

– Relaciones• Asociaciones

• Relaciones de:– extensión

– generalización

– inclusión

20



21



Ejemplo: Realización de un Caso de Uso

22


Arquitectura y Diseño - UMLEjemplo: Realización de un Caso de Uso. Colaboración Búsqueda

23


Arquitectura y Diseño - UMLEjemplo: Realización de un Caso de Uso. Colaboración Búsqueda

24



VistaDiseño


Vista de Procesos

Vista de Despliegue



25



• Vista de Diseño (Lógica)– Describe cómo se soportan los requerimientos

funcionales del sistema.

26



• Vista de Diseño (Lógica)– Elementos

• Clases

• Interfaces

• Paquetes

• Objetos

• Colaboraciones


• Dependencia

• Generalización

• Realiza

• links

27



• Representación de clases en UML

Cliente

_nombre : string_cedula : string_direccion : string_fechaDeIngreso : Date_numero : Integer

obtenerNombre( )guardarNombre( )obtenerCedula( )guardarCedula( )obtenerFacturas( )guardarFacturas( )añosComoCliente( )saldo( )

+ public- private# protected

Métodos:de clase en subrayadoabstractos en itálica

28



• Clases con EstereotiposX

Y< < utility> >

Z< < m oduloV B > >

c lientes< < Tabla > >

P roduc to< < E ntidad> >

29



• Interfaz– Es una colección de operaciones que se utilizan para

especificar un servicio de una clase o componente.

– La interfaz y su implementación se asocian mediante la relación Realize (realiza).

– Cuando un componente utiliza una interfaz se indica mediante una dependencia.

F<<Interfaz>>

30



Persona

GetNombre()SetNombre()GetCedula()SetCedula()

<<Interface>>

Cliente

GetNombre()SetNombre()GetCedula()SetCedula()CalcularSaldo()

Empleado

GetNombre()SetNombre()GetCedula()SetCedula()CalcularSueldo()

• Notación Interfaz

31


Notación Interfaz

32


Notación Interfaz

Interfaces provistas y requeridas

33


Arquitectura y Diseño - UML• Package (Paquete)

– Son elementos de la notación que permiten particionar lógicamente el sistema.

– Dentro de un paquete se pueden agrupar, clases, paquetes, colaboraciones, y/o casos de uso.

– Los elementos dentro del

paquete pertenecen al paquete.

NombrePaquete::NombreElemento

34



Cliente(from Cl iente)

Fact ura(from Cl iente)

Recibo(from Cl iente)

Cliente

+ Recibo+ Factura+ Cliente

35



36



37



38



• Paquete– Un paquete puede EXPORTAR los elementos

públicos que contiene a otros paquetes que los IMPORTAN. Lo que implica que existen asociaciones de algún tipo entre los elementos de cada paquete.

– Esta relación se representa mediante dependencias con el estereotipo <<importa>>

C l ie n te

+ R e c ib o+ F a c tu ra+ C li e n te

In te r fa zU s u a r io <<importa>>

39



• Paquete y Estereotipos– Facade (Fachada)- el paquete es una vista de algún

otro paquete

– Subsystem (subsistema)- el paquete es una parte independiente del sistema que modelamos.

– System (sistema)- el paquete representa al todo el sistema que estamos modelando.

– Framework - el paquete representa un framework

40



• Colaboraciones– Definición

• Una colaboración describe una estructura de elementos que colaboran - cada uno realizando un función especializada – y que colectivamente implementan una funcionalidad deseada (UML 2)

• Su principal propósito es explicar cómo funciona un sistema (o mecanismo) y por lo tanto solamente muestra aquellos aspectos de la realidad que son relevantes.

41



• Colaboraciones– Comprenden aspectos estructurales y de

comportamiento.

– Se utilizan para especificar como se llevan a cabo:• Mecanismos y patrones de diseño

• Casos de uso

• Métodos

• Clases nombre

42



• Colaboraciones– Estructura

• Especifica las clases, interfaces, asociaciones, etc. que colaboran para llevar a cabo la colaboración.

• Los elementos que participan en una colaboración no pertenecen a la misma, sino que referencian elementos de los distintos modelos.

• La estructura se representa mediante diagramas de clases o diagramas de objetos asociados a la colaboración.

43



• Colaboraciones– Comportamiento

• Especifica las interacciones entre las instancias de los elementos que participan en la colaboración.

• Se representa mediante diagramas de interacción o colaboración asociados a la colaboración.

44



• Colaboraciones– Para especificar la relación entre el elemento que la

colaboración “realiza” y la colaboración, se utiliza la relación Realiza.

Caso de Uso

colaboración

45



Reserva

Registro Cliente

Check-out

Conserje


46



Registrar

Registro


47



Ejemplo: Realización de un Caso de Uso. Colaboración Registrar

F o r m R e g i s t r o

( f r o m U I )

R e s e r v a

o b t e n e r D a t o s R e s e r v a ( )

( f ro m D o m )

F a c tu r a

c e r r a r ( )S e t R e s e r v a ( )o b t e n e r D a to s G e n e r a l e s ( )c a l c u l a r s e rv i c i o s ( )p a g o ( )

( f ro m D o m )

1

1

1

1

C l ie n t e

o b t e n e r R e s e r v a ( )

( f r o m D o m )

1 . . *1

1 . . *1

48


Arquitectura y Diseño - UMLEjemplo: Realización de un Caso de Uso. Colaboración Registrar

: C ons er je : F orm Regis t ro re : R eserv a f a : F ac t urac l : C li ent e : Sis hot el

1: I D c lient e( )

2: re= bus c arR eserv a(I D , f ec ha )

3: re= obt enerRes erv a( )

5: A Cepta( )6: Regis t rar( )

7: Regis t rar( )

4: obt enerDat os Res erv a( )

8: f a= c reat e

9: S et R eserv a(re )

49



• Colaboraciones genéricas

Observer

SubjectObserver

CMiView

CDocument

<<bind>>

<<bind>>

subject

observer

50



ConcreteSubject

obtenerDatos( )

ConcreteObserver

update( )

observers

*

Observer

update( )1

Subject

metodo( )attach( )detach( )notify( )

*1

notify para todos los observadores o.update(this);

update s->obtenerDatos()

Colaboración Observer

51



sujeto : ConcreteSubject

observador : ConcreteObserver

otroObservador : ConcreteObserver

1: guardarDatos ( )

2: notify ( )

3: update (Subject s)

4: obtenerDatos ( )

5: update (Subject s)

Colaboración Observer

52



VistaDiseño


Vista de Procesos

Vista de Despliegue



53



• Vista de Componentes– Describe la organización de los componentes que

comprenden el sistema (bibliotecas, dlls, etc).

54



• Vista de Componentes– Elementos

• Paquetes

• Componentes y variaciones

• Interfaces

• puertos

– Relaciones• Dependencia

• Generalización

• Realiza

• Conector (delegate)

55



• Componentes (UML 2)– Es una unidad modular de un sistema con interfaces

bien definidas. Es reemplazable dentro de su ambiente

56



• Vistas de un componente– Vista externa

• Se representa mediante símbolos de interfaz o mediante compartimientos que muestran las operaciones y atributos

– Vista interna• Se representa mediante instancias dentro del componente

o mediante diagramas asociados

57



Com ponenteA

Cliente

Clientes UI< < A ppl et> >

E m pleado

E m plad osU I< < A pplic ation> >

58



59



60



• Puertos (UML 2)– Un puerto especifica un punto de interacción entre un

componente (o clase) y sus partes internas o entre el componente y su entorno.

– Los puertos se conectan mediante conectores a las propiedades del componente y es la forma de indicar la invocación de los elementos comportamentales del componente.

– Los puertos pueden especificar los servicios que el componente ofrece o requiere.

61



• Conector de delegación– Especifica que el comportamiento disponible en una

instancia de un componente la implementa una instancia de otro componente (o clase).

– Se utiliza para modelar la descomposición jerárquica del comportamiento, donde los servicios provistos por un componente se implementan por componentes embebidos dentro de él

62



63



VistaDiseño


Vista de Procesos

Vista de Despliegue



64



• Vista de Despliegue– Describe los nodos que conforman la topología de

hardware donde se ejecuta el sistema.

– Diagramas:• Diagramas de Despliegue

65



• Vista de Despliegue– Elementos

– Nodo• Es un elemento físico que existe en tiempo de ejecución

y representa un recurso computacional que tiene por lo menos algo de memoria, y algunas veces, capacidad de procesamiento (UMLUG).

• Se pueden especificar atributos– Velocidad– Memoria– etc.

Procesador 1

66



• Artefactos– Especifican un elemento físico de información

utilizado o producido por un proceso de desarrollo, o por el despliegue o operación de un sistema.

– Ejemplos: Archivos, scripts, ejecutables, documentos, etc.

– Se representan con el símbolo de clase con estereotipos

67



• Vista de Despliegue– Relaciones

• Dependencia

• Asociación– Representa una conexión física entre nodos

• Generalización

68



C atá logo

<<D LL>> RegistroVehiculos

P C - M o s t r ad o r

Procesadores, dispositivos y Componentes

69



PC-Biblioteca

ServidorIsis

<<Ethernet>>

Impresora<<Impresora Tarjetas>>

70



PC-Sylvana PC-Daniel

<<Red>> Red Académica

Vax 1 <<Red>> Red Laboratorios

Modem56kbps

71


My Sql

BaseDatos

Pc Operario (k6 II)

UIAplicOperario(.class)

UIAplicTaxologo

Servidor Web

Aplic Web

Pc Supervisor

UIAplicSupervis(.class)

Pc Gerencia (k6 II)

UIAplicGerencia(.class)

Servidor Aplicaciones

AplicGerente(library)

AplicOperador(library)

AplicSupervis(library)

AplicTaxologo(library)

Coneccion

ADMINFuncionarios

Comunicacion Login

ProveedoresContabiliad

ADMINInfoBD

Consultas

Chat

Ethernet

Created with Visio

72



VistaDiseño


Vista de Procesos

Vista de Despliegue



73



• Vista de Procesos– Describe requerimientos no-funcionales

relacionados con concurrencia, sincronización, threads de control, etc.

– Muestra • Procesos y hilos de control (objetos activos)

• Comunicación entre procesos

74



• Vista de Procesos– Elementos

• Paquetes

• Clases activas

• Objetos

• Interfaces

• Colaboraciones


• Dependencia

• Generalización

• Realiza

• Links

75



• Vista de Procesos– Diagramas:

• Diagramas de Clases

• Diagramas de Objetos

• Diagramas de Interacción

• Diagramas de Estados

• Diagramas de Actividad.

76



• Vista de Procesos– Tipos de Flujos de Control

• Secuencial– Hay un solo flujo de control.

– Las operaciones se despachan una tras la otra.

• Concurrente– Hay varios flujos de control simultáneos.

77



• Vista de Procesos– Objeto Activo

• Es un objeto que es dueño de un proceso o hilo(thread). Tienen flujo de control independiente.

– Clase Activa• Los objetos activos pertenecen a clases activas.

78


Arquitectura y Diseño - UML• Vista de Procesos

– Proceso (heavywieght process)• Es un flujo de control que puede ejecutar

concurrentemente con otro proceso.

• Ejecuta en un espacio de dirección independiente.

– Thread (ligthweight process)• Es un flujo de control que puede ejecutar

concurrentemente con otro thread dentro de un proceso.

• Ejecutan en el espacio de dirección del proceso al que pertenecen.

79



Manejador De Comunicaciones<<Process>>

StreamAudioPlayer<<Thread>>

• Vista de Procesos– Clases Activas y Estereotipos

80



• Vista de ProcesosFormas de comunicación entre objetos

– activos - pasivos• Invocación de métodos.

– activos - activos• Comunicación entre procesos (IPC).

– Sincrónica» El que llama invoca el método y espera al llamado.

– Asincrónica» El que llama invoca el método y No espera el al llamado.

81



• Mecanismos de IPC– FIFO (named pipes)

– Colas de Mensajes

– Memoria compartida

– Sockets

– Remote Procedure Calls

– Software Middleware

82



• Vista de Procesos– Sincronización

• Cuando más de un thread accede a un objeto se pueden producir interferencias de dos tipos:

– Varios flujos de control sobre un método de un objeto

– Varios flujos de control sobre distintos métodos de un objeto

83



• Comunicación

Un sol o Thread

As incronic o

Time-outunb : B

unb : B

unb : Buna : A

una : A

una : A

m etodo (int)

m etodo1 ( )

m etodo2 ( )

84


Relación entre modelos

85



Modelos delnegocio

Modelos de requerimientos

de software

Modelos de Diseño

Modelos de Componentes

Modelo del Sistema

Vista de Requerimientos

Vista Lógica (diseño)

Vista de Procesos


Vista de Despliegue


Vistas

86


Arquitectura y Diseño - UMLModelo

Casos de Uso

Modelo Análisis

Modelo Diseño

Modelo Componentes

Modelo Despliegue

Trazabilidad entre modelos

87



• Lecturas– Sección 6 UMLUG

• Referencias– Sección 3, Capítulo 22 UMLUG

– UML 2.0 Superstructure Specification, OMG

Elementos de la Descripciones...

Documents

Transcript of Elementos de la Descripciones...