diseno de la arquitectura, principios y...

3/9/2012

1

Diseno de la arquitectura, principios y métodos

V1.0

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

Objetivos de la sesión

• Los objetivos de esta sesión son que el alumno

– Reconozca el concepto de diseño

– Identifique dos métodos de diseño de arquitectura

– Reconozca los pasos del método ADD

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

3/9/2012

2

Diseño

• ¿ Qué significa la palabra “diseño” ?


Diseño

• ¿ Qué significa diseño ?– De acuerdo a [Wand] no existe una definición [ ]

precisa y aceptada de forma general de lo que es el diseño

• Definición propuesta– Diseño como un objeto: “La especificación de un

sujeto con el fin de alcanzar objetivos, en un entorno particular, usando un conjunto de

t i iti ti f


componentes primitivos, que satisface un conjunto de requerimientos y que está sujeto a diversas restricciones”

– Diseño como actividad: “La creación de un diseño (con los 6 elementos previos”

3/9/2012

3

Diseño

• Sujeto– Se refiere al artefacto diseñado

• Entorno– El contexto o escenario dentro del cual existe u

opera el sujeto• Objetivos

– Conjunto de propósitos que el sujeto debe lograr, en término de los efectos deseados sobre el entorno


entorno• Requerimientos

– Conjunto de propiedades que el sujeto debe tener. Separados en dos categorías: funcionales y no-funcionales

Diseño

• Componentes primitivos– El conjunto de tipos de elementos (componentes) que

l j tcomponen al sujeto• Restricciones

– Conjunto de restricciones de comportamiento y forma sobre el sujeto

• La especificación es la salida de la actividad de diseño– Es una descripción detallada del sujeto en termino de los


Es una descripción detallada del sujeto en termino de los componentes utilizados (de acuerdo al conjunto de elementos primitivos) y sus conexiones. Puede ser provista usando una representación simbólica (documentos y diagramas), aunque también puede existir unicamente en la mente de alguien, como modelo físico y embebido en el sujeto mismo

3/9/2012

4

Diseño en arquitectura

• En el contexto de la arquitectura de software, el diseño se refiere a tomar decisiones que lleven a la creación de las estructuras que forman a lacreación de las estructuras que forman a la arquitectura (son los componentes primitivos de la definición)– Dinámicas– Lógicas– De asignación

• Se puede hablar de dos objetivos principales del diseño

Técnico: Crear diversas estructuras que permitan


– Técnico: Crear diversas estructuras que permitan satisfacer los requerimientos que influyen en la arquitectura (drivers) y principalmente los atributos de calidad

– Administrativo: Definir una estructura que permita guiar el desarrollo

Entradas al diseño

Requerimientosde negocio

Categoría funcional Categoría no-funcional

Documento de visión y alcance

Documento de casos de uso

de negocio

Casos de uso

Reglasde negocio

Atributos decalidad

Negocio

Usuario


Especificación de requerimientos

Requerimientosfuncionales detalladosRequerimientos

de sistemaRestricciones

Interfacesexternas

Sistema

Fuente: Wiegers

3/9/2012

5

Diseño

• Actividad de diseño como transformación

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

Diseño

• Actividad de diseño como transformación

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

El diseño involucra actividades creativas

pero, ¿puede realizarse de manera

sistemática?


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/9/2012

6

Diseño

• El diseño debería ser realizado de forma sistemática (metódica)

Decisiones de diseño justificadas– Decisiones de diseño justificadas

• El arquitecto debe ser responsable de las decisiones de diseño (accountability)– Decisiones de diseño registradas

• De lo contrario el diseño de la arquitectura es una actividad mística realizada por gurús


p g

Métodos de diseño

• Existen métodos que apoyan en la creación sistemática del diseño:sistemática del diseño:

– ACDM: Architecture-Centric Design Method

– ADD: Attribute Driven Design


3/9/2012

7

Métodos de diseño: ACDM

• Architecture – Centric Design Methodg– La etapa 3 se enfoca en

el diseño

• A diferencia de ADD,ACDM no detalla tantolas actividades de diseño yel método se enfocamás en cubrir todo el


más en cubrir todo elciclo de desarrollo dela arquitectura

Métodos de diseño: ADD

• Diseño guiado por atributos


3/9/2012

8


• Diseño guiado por atributosp

• Este método proporciona pasos muy detallados para hacer el diseño, lo cual facilita realizar


facilita realizar diseño de forma sistemática


• Paso 1: Confirmar que hay suficiente q yinformación de requerimientos

• Dos consideraciones:– Hay información

Requerimientos


– Requerimientos priorizados

3/9/2012

9

Priorización de drivers

• Antes de entrar al diseño, se debe asegurar que los atributos de calidad han sido priorizados

N l t d b í t– Normalmente uno no debería entrar con un numero muy elevado de escenarios al diseño

• Si se siguió QAW, los escenarios deberían estar priorizados– Técnica del 30% de votos

Priorización de atributos de calidad se puede


• Priorización de atributos de calidad se puede hacer en base a técnica propuesta por ATAM, a lo largo de dos dimensiones (Alta, Media Baja)– Importancia para el negocio– Riesgo técnico

Priorización de Atributos de

Calidad• Ejemplo

ID Escenario Importancia para cliente Dificultad de implementació PrioritarioRNF-AC-001 A A SIRNF-AC-002 A M SIRNF-AC-003 A B posiblementeRNF-AC-004 M A SIRNF-AC-005 M M SIRNF-AC-006 M B NORNF-AC-007 B A NORNF-AC-008 B M NO


RNF-AC-009 B B NO

3/9/2012

10

Priorización de Casos de uso

• La manera en que se estructura el sistema normalmente no impacta el hecho de que se p qpuedan satisfacer los requerimientos funcionales del sistema– Ej. Consulta de catálogo

• Sin embargo, al diseñar la arquitectura es necesario asegurarse que la estructura contiene los elementos necesarios para satisfacer los


los elementos necesarios para satisfacer los requerimientos funcionales– Para realizar el diseño se toma un sub-conjunto de

requerimientos funcionales del sistema


• Se deben considerar como primarios los casos de uso del sistema que

Sean críticos para el negocio– Sean críticos para el negocio– Estén asociados a algún escenario priortario– Impliquen un grado alto de complejidad o dificultad de

implementación– Requieran de la interacción de un gran número de elementos

de la arquitectura– Ilustren un punto particular– Representan un riesgo que se debe mitigar– Otra opción es identificar “familias” de casos de uso y elegir


Otra opción es identificar familias de casos de uso y elegir un representante de cada “familia”

• Nota: Sólo unos pocos casos de uso resultan prioritarios (ej. 10 – 20%)

3/9/2012

11


• Se deben considerar como primarios los RU del sistema que

Sean críticos para el negocio– Sean críticos para el negocio– Estén asociados a algún escenario priortario– Impliquen un grado alto de complejidad o dificultad de

implementación– Requieran de la interacción de un gran número de elementos

de la arquitectura– Ilustren un punto particular– Representan un riesgo que se debe mitigar– Otra opción es identificar “familias” de RU y elegir un


Otra opción es identificar familias de RU y elegir un representante de cada “familia”

• Nota: Sólo unos pocos casos de uso resultan prioritarios (ej. 10 – 20%)

Restricciones

• Las restricciones limitan las decisiones de diseño y en ese sentido es necesario tener claridad al yrespecto

• Antes de iniciar el diseño, se deben identificar las restricciones– Identificar el entorno de uso del sistema– Sistemas legados

Et


– Etc…

3/9/2012

12

Ejercicio

• Por equipo, tomar los casos de uso del caso de estudio y elegir aquellos que van a ser prioritarios, y g q q pjustificando la elección.

• Identificar, a partir de la información que se tiene y particularmente el documento de visión, las restricciones que serán impuestas sobre el sistema.

• Tiempo: 30 minutos


• Tiempo: 30 minutos

• Nota: El resultado de esto y el ejercicio de QAW nos permite tener los drivers


• Paso 2: Elegir elemento del sistema a descomponer

• Nota: este es el inicio del proceso iterativo de diseño


3/9/2012

13

Elección de un elemento

• En caso de que se tenga algo g gexistente (ej. pre-arquitectura) o que ya se hayan hecho iteraciones previas, se debe elegir un elemento del diseño que hay


q yhasta el momento

Criterios de elección

• Algunos criterios para elegir el elemento son:– Conocimiento de la arquitectura actual: Si es el único

elemento que se puede seleccionar, como en el caso de que l últi l t i d l

q p , qsea el último elemento que se quiera descomponer o el número de dependencias que tiene con los demás elementos del sistema.

– Riesgo y dificultad: Qué tan difícil será alcanzar los requerimientos asociados al elemento o cómo se van a alcanzar los requerimientos asociados al él o los riesgos relacionados con alcanzar los requerimientos relacionados con el elemento.

– Criterio de negocio: El papel que tiene el elemento en el desarrollo incremental del sistema y en las liberaciones de funcionalidad o si el elemento se va a construir o se va a comprar o el impacto que tendrá en el mercado etc


comprar o el impacto que tendrá en el mercado, etc.– Criterio de la organización: El impacto que tendrá el elemento

en los recursos ya utilizados, el nivel– de habilidad de los desarrolladores o que alguna persona con

autoridad seleccione el elemento.

3/9/2012

14

Elección de un elemento

• En la etapa de diseño de un sistema, se deben considerar dos posibilidades distintas:p– Se está partiendo de cero (“greenfield”)– Se está partiendo de algo existente (“brownfield”)

• En caso de que sea un desarrollo de cero, el primer elemento a descomponer es el sistema visto como un bloque único


SISTEMA


• Paso 3: Identificación de drivers


3/9/2012

15


• En ADD, la priorización de drivers hasta este punto sólo involucra la prioridad dada por los involucrados (Alta, Media o Baja)j )

• ADD sugiere complementar esa prioridad asignando una prioridad asociada al impacto sobre la arquitectura o la dificultad de implementacion (Alta, Media o Baja)

• Se privilegían drivers con media / alta importancia para el cliente y medio / alto impacto sobre la arquitectura

ID Escenario Importancia para cliente Dificultad de implementació Prioritario


p p pRNF-AC-001 A A SIRNF-AC-002 A M SIRNF-AC-003 A B posiblementeRNF-AC-004 M A SIRNF-AC-005 M M SIRNF-AC-006 M B NORNF-AC-007 B A NORNF-AC-008 B M NORNF-AC-009 B B NO


• Paso 4: Elección de “conceptos de pdiseño” que satisfagan los drivers


3/9/2012

16

Conceptos de diseño

• Esta es una etapa fundamental dentro del proceso de diseño. El elemento elegido se descompone en g psub-elementos, pero la elección de estos elementos no se debe hacer de forma arbitraria.

• Al momento de diseñar, es importante no re-inventar la rueda y utilizar soluciones “probadas”


– Patrones– Tácticas– Frameworks VS.

Ejemplo de patrón

• Ejemplo– Cuando se transforma un modelo de dominio (182) en ( )

una arquitectura técnica […] se debe soportar el desarrollo y evolución independiente de las partes

– Por ello:• Definir una o más capas para el sistema que se está

desarrollando, cada capa debe tener una responsabilidad distinta y específica


3/9/2012

17

Táctica

• ¿ Qué son las tácticas ?– Son decisiones de diseño que influencian el control de q

la respuesta de un atributo de calidad.– Las tácticas buscan controlar respuestas a estímulos


Framework

• Los frameworks son soluciones en código a problemas recurrentes de desarrollo. p– Originalmente, los frameworks se usaban haciendo uso

de herencia, sin embargo hoy en día se usan otros enfoques como configuración vía XML o uso de anotacionesProblema Framework Uso

Mapeo OO – Relacional Hibernate XML, anotaciones

Interfaz de usuario local Swing Herencia

C ió d t S i XML A t i


– En general un framework engloba patrones y tácticas

Conexión de componentes Spring XML, Anotaciones

Pruebas unitarias JUnit Herencia, Anotaciones

Interfaz de usuario web JSF XML

3/9/2012

18

Paso 4

• ADD sugiere que durante el paso 4 se exploren diversas decisiones que permitan satisfacer los q pdrivers

• Es importante tener la disciplina de documentar la razón por la cual se favorece una decisión sobre la otra– Lo que en inglés se conoce como “rationale”



• Paso 5: Instanciar los elementos arquitecturales y asignar responsabilidades


3/9/2012

19

Instanciando un patrón

• Ejemplo– La descripción del patrón de capas no nos dice cuántas p p p

capas debe haber en el sistema. Al decidir cuántas capas escogemos, creamos una “instancia” del patrón


Ejemplo• Un esquema típico es la

separación en 3 capas:– Presentación

Capa de PresentaciónPresentación

– Negocio– Datos

• Puede ser necesario poner otras capas, dependiendo de los requerimientos

• El patrón impone ciertasrestricciones En este caso

SISTEMACapa de Negocio


restricciones. En este casola capa de presentaciónno debe comunicarse conla de acceso a datos deforma directa

Capa de acceso a datos

3/9/2012

20

Ejemplo• Una vez que es instanciado

el patrón, se asignanresponsabilidades Capa de Presentaciónp

• Ej.– La capa de presentación

contendrá toda la lógicarelacionada con la interaccióncon el usuario

– La capa de negocio contendrátoda la lógica relacionada conlos procesos y reglas de negocio

– La capa de datos contendrá



La capa de datos contendrátoda la lógica relacionadacon la persistencia de losobjetos en una base de datosrelacional



• Paso 5: Instanciar los elementos arquitecturales y asignar responsabilidades


3/9/2012

21

Paso 5

• Las interfaces son los “contratos” que existen entre los elementos dependientes y que permitirán p y q plograr una interacción exitosa entre los mismos.

• En etapas iniciales del diseño no es necesario definir muy detalladamente las interfaces

• Es fundamental, sin embargo, definir las interfaces


, g ,de servicios comunes y también de los componentes que serán sujetos a diseño detallado durante la construcción

Plantilla de documentación de

interfazSección 1. Presentación Primaria

Versión enó

Plantilla para una Interfaz

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

entexto

ó


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

3/9/2012

22

Detalles 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 decirlo más esencial es la firma de la interfaz, es decir el conjunto de métodos que la componen

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

Restricciones


– Restricciones– Parámetros– Valor de Retorno– Excepciones

Detalles de interfaz

• Ejemplo de plantilla


3/9/2012

23


• Paso 7: Verificar y refinar requerimientos y hacerlos restricciones para los elementos instanciados


Paso 7

• En esta etapa se verifica que la descomposición realizada durante ladescomposición realizada durante la iteración cubre los drivers.

• Si no se satisfacen los drivers se puede– Delegar el driver para ser satisfecho por uno

o más sub-elementos


• Los requerimientos no satisfechos se tienen que tratar en la iteración siguiente

3/9/2012

24

Paso 7

• Tabla de seguimiento– En cada iteración se evalua el grado de– En cada iteración se evalua el grado de

satisfacción de drivers

Driver Iteración 1 Iteración 2 Iteración 3 Iteración 4

CU-010 no

CU-017 no

CU-035 no


AC-001 no

AC-003 no

AC-005 parcial

RES-001 completo

RES-003 no

Criterios de terminación

• El proceso de diseño continua a lo largo de varias iteraciones

H t h iti d t d l i– Hasta que se han mitigado todos los riesgos más importantes

– Hasta que se han tomado decisiones de diseño relativas a los drivers

– Hasta que se acaba el tiempo planeado• Nota: Dependiendo del ciclo de desarrollo

del sistema los ciclos de desarrollo de la


del sistema, los ciclos de desarrollo de la arquitectura se realizan todos “en bloque” o bien a lo largo de los ciclos de desarrollo del sistema la arquitectura se refina.

3/9/2012

25

Proceso Unificado:Analisis & Design



• Iteraciones subsecuentes


3/9/2012

26

Iteraciones subsecuentes

• Para las iteraciones subsecuentes, se puede elegir continuar descomponientopuede elegir continuar descomponiento los elementos siguiendo un enfoque “en anchura” (breadth) o “en profundidad” (depth)

1era iteración


1era iteración

2a iteración

Ejemplo

• Iteración 2: El arquitectose quiere enfocar en Capa de Presentaciónqdespomponer las capaspara soportar lafuncionalidad (paso 2 de ADD). El driver elegidoson los casos de usoprimarios (paso 3). SISTEMA

Capa de Negocio


• Paso 4: ¿Qué patrón(es) usar ?


3/9/2012

27

Paso 4

• POSA 4 nos ayuda mucho…

Qué elegir?


Paso 4



Conviene registrar el por qué de ésta decisión de diseño…

3/9/2012

28

Paso 4



Conviene registrar el por qué de ésta decisión de diseño…

Ejemplo

• Paso 5: Instanciando Domain Capa de Presentación

Objects, explicit interfacey encapsulatedimplementation para un caso de uso primario– Este ejemplo muestra que se

pueden elegir más de un patrón a la vez.



• Enfoque en anchura Capa de acceso a datos

3/9/2012

29

Ejemplo

• Paso 5: Asignación de responsabilidades Capa de Presentaciónp


El componente “VistaTransferencia” contiene todo el código que soporta la

interacción con el usuario para el caso de uso CU-010

Realizar Transferencia*



* Supongamos que éste es uno de los casos de uso primarios elegido dentro de los drivers

Ejemplo



El componente “ServicioTransferencia”

contiene toda la lógica de negocio para soporter el caso

de uso CU-010 Realizar Transferencia*




3/9/2012

30

Ejemplo



El componente “PersistenciaTransferencia”

contiene toda la lógica relacionada con la

persistencia necesaria para llevar a cabo el caso de uso



CU-010 Realizar Transferencia*


Ejemplo

• Paso 6: Definición de interfaces Capa de Presentación

– En este momento podemos comenzar a identificar los métodos que deben tener las interfaces de los componentes que soportan el caso de uso

• ¿Qué técnica usar?SISTEMA

Capa de Negocio



3/9/2012

31

Paso 6

• Identificación de métodos de interfaces mediante diagramas de secuenciamediante diagramas de secuencia

CapaPresentacion Servicio CapaAccesoADatos MicroServicio Entidad

1 : solicitud()2 : recupera()

3 4 : invoca()

5 : modifica()


6 : actualiza()

7

Nota: Diagrama con fines ilustrativos, los elementos no corresponden al ejemplo

Paso 7

• Tabla de seguimiento– En cada iteración se evalua el grado de– En cada iteración se evalua el grado de

satisfacción de drivers

Driver Iteración 1 Iteración 2 Iteración 3 Iteración 4

CU-010 no Completo

CU-017 no

CU-035 no


AC-001 no

AC-003 no

AC-005 parcial

RES-001 completo

RES-003 no

3/9/2012

32


• Iteraciones subsecuentes


Iteraciones subsecuentes

• Ya que se realizó la estructuración general y se asignarongeneral y se asignaron responsabilidades para cubrir funcionalidad podemos enfocarnos en los atributos de calidad (diseño en profundidad). Aquí se usan también

Di ñ fí i


– Diseño físico

– Tácticas

– Frameworks

64

3/9/2012

33

Diseño físico

• En etapas iniciales de descomposición, conviene pensar también en laconviene pensar también en la estructuración física y posiblemente aplicar tácticas para soportar aspectos como disponibilidad

Servidor BDServidor aplicativoPC


Servidor BD

BD

Servidor aplicativoPC

Capa de Presentación Capa de Negocio Capa de acceso a datosNavegador

Frameworks• La elección de frameworks es parte del proceso de diseño.

Problema Framework Uso

• RecomendacionesNo elegir frameworks “porque están de moda”

Mapeo OO – Relacional Hibernate XML, anotaciones

Interfaz de usuario local Swing Herencia

Conexión de componentes Spring XML, Anotaciones

Pruebas unitarias JUnit Herencia, Anotaciones

Interfaz de usuario web JSF XML


– No elegir frameworks porque están de moda– Considerar curva de aprendizaje del equipo– Considerar grado de madurez del framework, sobre todo si es

open source

66

3/9/2012

34

Discusión

• ¿Cómo aplicarían alguna táctica en el diseño del sistema?diseño del sistema?

• ¿Cómo aplicarían un framework en el diseño del sistema?


Consideraciones finales

• Conviene que el diseño no se quede en algo conceptual sino que durante el g p qdiseño se elaboren prototipos que culminen en una “arquitectura ejecutable”

• Conviene registrar las decisiones de diseño importantes al momento de


ptomarlas pues de lo contrario es probable que se olviden después– Estas estarán plasmadas en la vista

68

3/9/2012

35

Consideraciones finales

• El diseño de la arquitectura no es un diseño “de alto nivel”, puede llegar a ser , p gmuy detallado– El arquitecto debe detallar tanto como sea

necesario para mitigar riesgos y satisfacer los atributos de calidad


• El diseño es una tarea compleja– Lo ideal en el diseño es combinar teoría y

experiencia

69

Conclusión

• En arquitectura, el diseño se refiere a la ió d t t t lcreación de estructuras para soportar los

drivers

• Existen diversos métodos de diseño

• ADD es el método que proporciona pasos más detallados para realizar un diseño sistemático


detallados para realizar un diseño sistemático

3/9/2012

36

¿Preguntas?

• Gracias


diseno de la arquitectura, principios y...

Documents