documentación arquitecturaliim.izt.uam.mx/.../10_documentaciondelaarquitectura.pdf · 2019. 9....

3/13/2012

1

Documentación de la arquitectura

V1.0

MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información

1

Objetivos de la sesión

• Los objetivos de la sesión son que el alumnoalumno– Recuerde los distintos tipos de estructuras

que forman una arquitectura

– Identifique distintos métodos de documentación orientados a vistas

Identifique las partes que forman un

MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información 2

– Identifique las partes que forman un documento de vista

– Identifique la manera en que se documentan interfaces

3/13/2012

2

Contenido

• Recordando

• Tipos de estructuras• Tipos de estructuras

• Métodos de documentación

• Documentación de vistas

• Documentación de interfaces

Concl sión


• Conclusión

Contenido

• Recordando





Concl sión


• Conclusión

3/13/2012

3

Recordando• Definición de arquitectura de software

– “La arquitectura de software es la estructura o qestructuras del sistema que comprende elementos de software, las propiedades visibles de forma externa de estos elementos, y las relaciones entre los elementos”

• La definición habla de varias estructuras


La definición habla de varias estructuras– Estas estructuras corresponden a distintos tipos

de elementos (de ejecución, lógicos, físicos)– Deben ser representadas de manera

independiente

Recordando

• Durante el diseño, el arquitecto toma decisionesdecisiones

RUs / RFs

Atributos de calidad

Decisiones

Presen tacion

Dato s

Negocio

Control de Pujas

De spachador de solicitudes de Pujas

«Front Control le r»

Despachador de Peticiones Generale s

IRece ptorPuja s

IDespacha dorPeticionesGenerale s

IAdministradorAcce so

IControlPuj as

Cola Puj as

IColaPuja s

Se sepa ra en Recep tor d e Sol icitudes de Puja y Despacha dor de Peticiones debido a que el primero d ebe usar cola segú n requerimientos y el segund o de be u sar hi l os para

mejo rar el desemp eño (guiado por requ erimientos)

IAdminis tradorCRUDSubastas

Subas tas ::Administrador CRUD Subasta s

«o bserver»Observ ador

Subas tas

IControlNotific acionesServ er

«S trate gy»Control Puj as

Subasta InglesaIControlPuj asEspecifico

« Strate gy»Control Puj as

Subasta Sellada

Notifica ciones::Control Notificac ion Inscritos

+ enviarNoti fica cio n(Noti fi cacion) : void

Notific aciones::Control Notifica cion Participantes

+ enviarNotificacion(Noti fi cacion ) : void

IAdministradorNotificacionInscritos

IAdministradorNotificac ionPa rticipantes

De ntro de este se

imple me nta el BDRS-RNF-13

Notifica ciones::Administra dor de Ac cesos

«DAO»

IPe rsiste ncia Pujas

Pujas::Pe rsiste ncia de Puj as

Pujas ::Realizar Puja

DatosNegocioPresentación

« interface»

:IAdministrarSubastas

«inte rface»

:IDetalleSubastas

:Administrador

«ISeccionDetalleSubast...

:Subasta Inglesa

«in terface»

:IAdministradorCRUDSubastas

«interface»

:IPersistenciaSubastas

«interface»

:ISeccionDetal le

Esta selección se puede hacer:- Con una tabla que asocie Tipo de clase y la interfaz ISeccionDetal leSubasta-Uti li zar el Patrón Chain of Responsibil ity

"Al ta de Subasta"()

despl iegaDetal le(Subasta)

seleccionarComponenteSubastaEspecífico(Subasta) :IDetal leSubasta

«create»

desplegarDetal leSubastas(Subasta)

despl iiegaDetalle(Subasta)

"Datos generales"()

"Datos Especificos"()

"Salvar"()

val idarDatosGenerales()

<<usa>>

<<produce>>


Restricciones- De este punto en adelan te se maneja el tipo genérico Subasta

val idarDatosEspeci fi cos()

salvar(Subasta)

salvar(Subasta) :Subasta

Serv idor BDServ idor Aplicaciones SIRE

Serv idor Aplicaciones

PC

«BD»Informix

Negocio

«database access layer»Datos

Web Browser

«cliente pesado»Presentacion

En un momento dado existen múltiples PC cliente conectadas al sistema

«JDBC»

«JDBC»«RMI»

«HTTPS»

IPersistencia

INegocio

ArquitectoRequerimientos(drivers)

Diseño

3/13/2012

4

Recordando

• Durante el diseño, el arquitecto toma decisiones Estas decisiones decisiones

RUs / RFs

Atributos de calidad

Decisiones

Presen tacion

Dato s

Negocio

Control de Pujas

De spachador de solicitudes de Pujas

«Front Control le r»

Despachador de Peticiones Generale s

IRece ptorPuja s

IDespacha dorPeticionesGenerale s

IAdministradorAcce so

IControlPuj as

Cola Puj as

IColaPuja s

Se sepa ra en Recep tor d e Sol icitudes de Puja y Despacha dor de Peticiones debido a que el primero d ebe usar cola segú n requerimientos y el segund o de be u sar hi l os para

mejo rar el desemp eño (guiado por requ erimientos)

IAdminis tradorCRUDSubastas

Subas tas ::Administrador CRUD Subasta s

«o bserver»Observ ador

Subas tas

IControlNotific acionesServ er

«S trate gy»Control Puj as

Subasta InglesaIControlPuj asEspecifico

« Strate gy»Control Puj as

Subasta Sellada

Notifica ciones::Control Notificac ion Inscritos

+ enviarNoti fica cio n(Noti fi cacion) : void

Notific aciones::Control Notifica cion Participantes

+ enviarNotificacion(Noti fi cacion ) : void

IAdministradorNotificacionInscritos

IAdministradorNotificac ionPa rticipantes

De ntro de este se

imple me nta el BDRS-RNF-13

Notifica ciones::Administra dor de Ac cesos

«DAO»

IPe rsiste ncia Pujas

Pujas::Pe rsiste ncia de Puj as

Pujas ::Realizar Puja

DatosNegocioPresentación

« interface»

:IAdministrarSubastas

«inte rface»

:IDetalleSubastas

:Administrador

«ISeccionDetalleSubast...

:Subasta Inglesa

«in terface»

:IAdministradorCRUDSubastas

«interface»

:IPersistenciaSubastas

«interface»

:ISeccionDetal le

Esta selección se puede hacer:- Con una tabla que asocie Tipo de clase y la interfaz ISeccionDetal leSubasta-Uti li zar el Patrón Chain of Responsibil ity

"Al ta de Subasta"()

despl iegaDetal le(Subasta)

seleccionarComponenteSubastaEspecífico(Subasta) :IDetal leSubasta

«create»

desplegarDetal leSubastas(Subasta)

despl iiegaDetalle(Subasta)

"Datos generales"()

"Datos Especificos"()

"Salvar"()

val idarDatosGenerales()

<<usa>>

<<produce>>

deben comunicarse


Restricciones- De este punto en adelan te se maneja el tipo genérico Subasta

val idarDatosEspeci fi cos()

salvar(Subasta)

salvar(Subasta) :Subasta



PC

«BD»Informix

Negocio


Web Browser



«JDBC»

«JDBC»«RMI»

«HTTPS»

IPersistencia

INegocio

ArquitectoRequerimientos(drivers)

Diseño

Comunicación del diseño

• La comunicación del diseño de la arquitectura es un aspecto fundamental q pdel desarrollo que permite– comprender la manera en que está

estructurado el sistema para su desarrollo o mantenimiento

– realizar la evaluación temprana del diseño l fi d id tifi i bl


con el fin de identificar riesgos y problemas– reutilizar los diseños

• ¿ Cómo se comunica el diseño ?

3/13/2012

5

Contenido

• Recordando





Concl sión


• Conclusión

Estructuras

• En general, se puede hablar de distintos tipos de estructuras:tipos de estructuras:– Lógicas (módulo)

– Dinámicas (componentes y conectores)

– Físicas (de asignación)


3/13/2012

6

Estructuras lógicas

• Las estructuras lógicas representan estructuras modularesestructuras modulares– Un módulo es una unidad de implementación

de software que provee un conjunto coherente de funcionalidad


• Uso:– Estructuración general del sistema

– Asignación de responsabilidades

– Mantenimiento del sistema

Estructuras lógicas

• Elementos UML correspondientes a estas estructuras– Clases

– Componentes

– Packages (para capas)

• Relaciones– Relaciones entre clases (asociación, todo / parte,

herencia)


herencia)

– Relaciones de uso (dependencias)

– Contenido

3/13/2012

7

Estructuras lógiccas: ejemplo

• Vista lógica– Capas son

packages

Capa de Presentación

Interfaz de usuario

Pantalla<<xhtml>>

packages– Componentes

son agrupamientos enfocados en preocupaciones particulares que implementan

Capa de Negocio

Capa de servicios

Modelo de dominio

Servicios aplicativosWorkflows

<<coordina>>

Lógica de presentación

Controlador<<ManagedBean>>

faces-config.xml

EntidadA

ServicioCU

iServicioCU


implementan interfaces

– Clases por ejemplo en modelo de dominio

Capa de acceso a datos

Manejo de persistencia

EntidadDAO LdapDAO

iEntidadDAO

iLdapDAO

BD

Conexión a servidor LDAP

EntidadBServicioEspecifico

iServicioEspecifico

WorkflowCU

iWorkflowCU

Estructuras dinámicas

• Las estructuras dinámicas representan elementos que existen en tiempo de ejecución así como elementos que apoyan la interacción de los primeros ( t )

q p y p(conectores)

• Dentro de las estructuras dinámicas generalmente aparecen instancias de elementos descritos en las estructuras lógicas para mostrar algún escenario de importancia

U


• Usos– Modelado de soporte de atributos de calidad (tolerancia a

fallas, seguridad, concurrencia, manejo de errores)– Análisis del sistema

3/13/2012

8

Estructuras dinámicas

• Elementos UML correspondientes a estas estructuras– Objetos

– Hilos y procesos

– Instancias de componentes

– Instancias de nodos

• Relaciones– Relaciones directas entre elementos (ej Paso de


– Relaciones directas entre elementos (ej. Paso de mensajes)

– Conectores interpuestos entre elementos

Estructuras dinámicas: ejemplo

: Usuario

: Pantalla : Controlador : ServicioCU : WorkflowCU : iEntidadDAO : EntidadA

1 : "datos"1 : datos

2 : setDatos()3 : metodoServicio()

4 : verificaSeguridad()

5 : iniciaTransaccion()

6 : retrieve()7

<<create>>

89 : inicia()

10 : set()

11


11 12 : update()

13 : terminaTransaccion()

1415

16 : refresh()

3/13/2012

9

Estructuras dinámicas: ejemplo

Hilo de recepción de pujasHilo de cierre de subastasProceso

ActivityIni tial

Solici tud de puja (inglesa)«process»

Arrancar hilos de aplicación

«thread»Arrancar hilo

«idle»Esperar

Checar subastas

Hay subastas que deban ser cerradas?

Solici tud de puja (inglesa)

«thread»Arrancar hilo

Procesar solicitud

Es ultimominuto de lasubasta?

Incrementar tiempo deb

Bloquear subasta

«bloqueada»:Subasta

[procesamientoexitoso]

[si ]

[si]

[t_ahora > t_ultimo + 60s]

[no]


?

Cerrar Subastas Puja procesada

subasta

Liberar subasta

Hay subastasbloqueadas?

«idle»Esperar desbloqueo de

subasta

«liberada»:Subasta

[no]

[si]

[no]

[si]

[subastasdesbloqueadas]

Leyenda:ProcesoHiloHilo en espera

Lieberman, B., “Using UMLActivity Diagrams for the ProcessView”, Rational Edge, Mayo 2001

Notación: UML extendido

Estructuras Físicas

• Las estructuras físicas, o de asignación, presentan mapeos de los elementos representados en las estructuras lógicas o dinámicas hacia elementosestructuras lógicas o dinámicas hacia elementos físicos que pueden incluir– Hardware– Sistema de archivos– Recursos humanos

• Uso


– Implantación del sistema– Implementación (estructuración del ambiente de

desarrollo)– Asignación de trabajo

3/13/2012

10

Estructuras físicas

• Estas estructuras no forzosamente se representan en UMLrepresentan en UML– Implantación (deployment): Diagramas de

implantación de UML

– Implementación: Descripción de la estructura del entorno de desarrollo

Asignación de trabajo: Matriz que asocia


– Asignación de trabajo: Matriz que asocia módulos o grupos de módulos a individuos

Estructuras físicas: ejemplo

PC


Negocio


Web Browser



«HTTPS»

IPersistencia

INegocio



«BD»Informix

«JDBC»

«JDBC»«RMI»

3/13/2012

11


• Carpetas delproyectoproyecto



• Asignación de trabajo

Componente \ Recurso Ing. 1 Ing. 2 Ing. 3 Ing. 4 Ing. 5Modelo de Dominio √ √DAOs

DAO Cliente √DAO Cuenta √Reportes

Reporte estatus cuentas √Reporte clientes activos √Negocio

Servicio alta de usuarios √


Servicio de modificación de cuenta √Presentación

Pantalla alta de usuarios √Pantalla de modificación de cuenta √

3/13/2012

12

Contenido

• Recordando





Concl sión


• Conclusión

Métodos

• Existen distintos enfoques para la documentación de arquitecturasdocumentación de arquitecturas– 4 + 1 Views

– IEEE 1471

– Views and Beyond


• Todos ellos consideran el concepto de “vista”

3/13/2012

13

Métodos: 4+1 views

• 4+1 Views. El enfoque (o modelo) 4+1 vistas es muy popular particularmentevistas es muy popular, particularmente porque está asociado al proceso de desarrollo RUP.


Métodos: 4+1 views

• Vista lógica– Modela elementos que soportan la funcionalidad que el sistema provee al usuario final de un

punto de vista estático o dinámico mediante diagramas tales como clases, paquetes y secuencia.

Vi t d• Vista de proceso– Esta vista opcional modela los aspectos dinámicos del sistema y captura aspectos tales como

concurrencia y sincronización mediante diagramas tales como el de actividades.

• Vista de desarrollo– Modela la organización estática del software en su ambiente de desarrollo, típicamente mediante

diagramas de componentes.

• Vista física– Modela el mapeo del software con el hardware, típicamente con diagramas de implantación.

Vi t d d


• Vista de casos de uso– Esta es la vista adicional (+1) que es central al modelo y que agrupa escenarios de casos de uso

principales. Para su representación se puede usar un diagrama de casos de uso acompañado de descripciones textuales de los escenarios. Las otras vistas deben permitir comprender la manera en que los escenarios de casos de uso son soportados por la arquitectura.

3/13/2012

14

Métodos: IEEE 1471

• Estándar de la IEEE para la descripción arquitectural de sistemas intensivos de software. – Define un marco conceptual que relaciona los conceptosDefine un marco conceptual que relaciona los conceptos

de sistema, descripción arquitectural y vista. – En éste marco, las vistas se deben ajustar a un viewpoint

(punto de vista), el cual especifica las convenciones para construir y usar una vista, e incluye elementos tales como los lenguajes que pueden ser usados para describir la vista así como los métodos de modelado y las técnicas de análisis que pueden ser aplicados a las representaciones de la vista.


p– Una descripción arquitectural incluye uno o más

viewpoints, los cuales se seleccionan con base en los involucrados hacia los cuales está dirigida la arquitectura.

Método Views and Beyond


3/13/2012

15

Método Views and Beyond

• Enfoque desarrollado por el SEI– La documentación de una arquitectura de software

involucra la elección de las vistas relevantes de lainvolucra la elección de las vistas relevantes de la arquitectura, la documentación de cada una de esas vistas, así como la documentación de la información que aplica a más de una vista o a un conjunto de vistas en su totalidad.

– Los detalles del enfoque incluyen el método para elegir las vistas más relevantes para los involucrados de la arquitectura, plantillas estándar


para documentar las vistas, información necesaria para documentar información que aplica a través de varias vistas, así como definiciones del contenido de las plantillas.

– A diferencia del enfoque 4+1 vistas, Views and Beyond no especifica el número de vistas a usar.

Contenido

• Recordando





Concl sión


• Conclusión

3/13/2012

16

Documentación de vistas

• La representación de una estructura es una vistauna vista– Una estructura está compuesta por

elementos (con propiedades) y relaciones

• Un diagrama es un punto de partida


apropiado para documentar una vista– Sin embargo, solamente tener el diagrama

no es suficiente

Ejemplo


Fuente: http://fxa.noaa.gov/ALPS/ALPS_displayArch.html

3/13/2012

17

Documento de vista

• En general un diagrama no es Sección 1. Presentación Primariadiagrama no es suficiente para representar una vista

Sección 2. Catálogo de Elementos2.1 Elementos2.2 Relaciones2.3 Interfaces2.4 Propiedades2.5 Comportamiento

Sección 3. Diagrama de Contexto de la Vista

Versión en

textoó


Sección 4. Guía de VariaciónSección 5. Decisiones de Diseño

Presentación primaria

• El diagrama, o presentación primaria, es una representación de la estructurauna representación de la estructura correspondiente a la vista– La documentación de esta parte es

indispensable


• Este diagrama normalmente es creado como parte de las actividades de diseño de la arquitectura

3/13/2012

18

Catálogo de elementos

• Elementos– Para poder comprender un diagrama, es necesario describir

brevemente cada uno de los elementos que se presentan dentro de éste junto con sus responsabilidades (y propiedades)

– A menos que sea muy obvio, esta parte es indispensable

• Propiedades


– No siempre se pueden identificar propiedades, sin embargo éstas pueden ser útiles por ejemplo para vistas físicas


• Ejemplo Capa de Presentación

Capa de Negocio

Capa de servicios

La capa de servicios contiene componentes que orquestan operaciones que mapean directamente con los casos de uso del sistema. Los componentes de esta capa se ejecutan en un contenedor que permite soportar



Modelo de dominioServicios aplicativosWorkflowscontenedor que permite soportar aspectos no-funcionales. Proveen interfaces de granularidad alta y se comunican con la capa de presentación mediante el envío y recepción de Data Transfer Objects.

3/13/2012

19


• Relaciones– Al igual que con los elementos, muchas veces g q

es necesario proveer información adicional que permita comprender las relaciones entre los elementos del diagrama

– A menos que sea muy obvio, esta parte es indispensable


• Al describir una relación, conviene mencionar los elementos que se encuentran en los extremos de la relación


• Comportamiento– La documentación del comportamiento es

ti l t útil l t i tparticularmente útil para complementar vistas lógicas

– Se presenta un punto de vista dinámico de los elementos mostrados en la vista lógica

– Generalmente se toma un escenario de caso de uso o no funcional y se muestra el intercambio de mensajes a través de un diagrama de


j gsecuencia

• Dependiendo del tipo de vista, puede no incluirse

3/13/2012

20


• Ejemplo decomportamientocomportamiento

: Usuario

: Pantalla : Controlador : ServicioCU : WorkflowCU : iEntidadDAO : EntidadA

1 : "datos"

2 : setDatos()3 : metodoServicio()

4 : verificaSeguridad()

5 : iniciaTransaccion()

6 : retrieve()7

<<create>>

8


89 : inicia()

10 : set()

11 12 : update()

13 : terminaTransaccion()

1415

16 : refresh()


• El estudio del comportamiento de los elementos permite identificar las propiedades públicas de éstos que debenpropiedades públicas de éstos que deben verse reflejadas en sus interfaces

– Más adelante hablaremos al respecto de este tema en mas detalle


• Dependiendo del tipo de vista, puede no incluirse– Aplica particularmente para vistas lógicas y

deployment

3/13/2012

21

Diagrama de contexto

• Muchas veces un diagrama presenta un aspecto particular de la arquitectura del sistema– Para poder entender este diagrama generalmente

es necesario proveer un diagrama de contexto (o alguna explicación) que permita ubicar el detalle dentro del contexto general

– Ojo: No confundir el diagrama de contexto de una vista con el diagrama de contexto general del


vista con el diagrama de contexto general del sistema

• Dependiendo del tipo de vista, puede no incluirse


• Ejemplo: Vista lógica con detalle de la capa de negociocapa de negocio

Capa de Negocio

Capa de servicios

Modelo de dominio

<<coordina>>

ServicioCU

iServicioCU

Capa de Presentación

Capa de Negocio

Capa de servicios

Modelo de dominioServicios aplicativosWorkflows

<<coordina>> <<coordina>> <<coordina>>

iServicios

+solicitud()


Servicios aplicativosWorkflows

iEntidadDAO

EntidadA

EntidadBServicioEspecifico

iServicioEspecifico

WorkflowCU

iWorkflowCU


p


3/13/2012

22

Guía de variación

• La guía de variación proporciona información útil sobre posiblesinformación útil sobre posibles variaciones que pueden ser realizadas sobre la porción del diseño que se documenta. Esta guía debe proporcionar información sobre cómo y cuándo se p eden reali ar las ariaciones


pueden realizar las variaciones

Contenido

• Recordando





Concl sión


• Conclusión

3/13/2012

23

Documentación de interfaces

• Las interfaces juegan un papel fundamental dentro del diseño del sistema pues son el punto de contacto entre los componentes definidos por la arquitecturaentre los componentes definidos por la arquitectura

• Las interfaces representan un contrato que deben


Las interfaces representan un contrato que deben satisfacer los componentes del sistema para poder participar dentro de colaboraciones que soporten los escenarios tanto funcionales como no funcionales

Documentación de interfaces

• En el contexto de una vista, y principalmente de una vista lógica, se deben documentar las interfaces de los componentes presenteslas interfaces de los componentes presentes en la presentación primaria

– Esta documentación se obtiene a partir del análisis de comportamiento

• El análisis de comportamiento representa la i t ió d l t d l i t


interacción de los componentes de la vista primaria para soportar algún escenario funcional o no funcional relativo a algún driver arquitectural

3/13/2012

24

Plantilla

Sección 1. Presentación Primaria

Sección 2. Catálogo de Elementos2.1 Elementos2.2 Relaciones2.3 Interfaces2.4 Propiedades2.5 Comportamiento

Sección 3. Diagrama de Contexto de la Vista

Versión en

textoó

Plantilla para una Interfaz


g

Sección 4. Guía de VariaciónSección 5. Decisiones de Diseño

Métodos de interfaz

• Existen varios aspectos que es importante documentar de una interfaz particular, sin embargo lo más esencial es la “firma” de la interfaz, es decir elmás esencial es la firma de la interfaz, es decir el conjunto de métodos que la componen

• Es importante que para cada método se documente– Pré-condiciones– Post-condiciones– Restricciones

P á t


– Parámetros– Valor de Retorno– Excepciones

3/13/2012

25

Métodos de interfaz

• Ejemplo de plantilla


Contenido

• Recordando





Concl sión


• Conclusión

3/13/2012

26

Resumen• La documentación del diseño de la

arquitectura es una tarea fundamental ya que esta actividad permite que se transmita el conocimiento relativo al diseño a otros involucrados para permitir– La evaluación del diseño– El desarrollo del sistema

El t i i t d l i t


– El mantenimiento del sistema

• El diseño se documenta a través de diversas vistas

¿Comentarios?¿Preguntas?


documentación arquitecturaliim.izt.uam.mx/.../10_documentaciondelaarquitectura.pdf · 2019. 9....

Documents