23/03/2012
1
Evaluación de la arquitectura
V1.0
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información1
Objetivos de la sesión
Los objetivos de esta sesión son que el alumno
– Reconozca la importancia de realizar la evaluación de un diseño de arquitectura de software, reconozca tipos de evaluaciones de arquitectura y exprese el concepto de evaluación basada en escenarios
– Reconozca las etapas del proceso de evaluación de arquitectura incluyendo la manera de armar el paquete de evaluación y la manera de estructurar la presentación
– Identifique el concepto de riesgo y compromiso a nivel de la
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
q p g y pevaluación de una arquitectura basada en escenarios
– Reconozca la manera de documentar los defectos resultantes de una evaluación
2
23/03/2012
2
Recordando: Requerimientos
Drivers– Requerimientos funcionales primarios– Atributos de calidad– Restricciones
Atributos de calidad especificados como escenarios
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Fuente de estímulo
Estímulo
Entorno
Respuesta
Medida de respuesta
Artefacto
3
Recordando: 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>>
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
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
4
23/03/2012
3
Recordando: Documentación
Secció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
ó
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Sección 4. Guía de VariaciónSección 5. Decisiones de Diseño
5
Índice
Introducción a la evaluación de arquitecturaq
Métodos de evaluación: ACDM
Métodos de evaluación: ATAM
Ejemplo
Riesgos puntos sensibles y
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Riesgos, puntos sensibles y compromisos
Conclusión
6
23/03/2012
4
Índice
Introducción a la evaluación de arquitecturaq
Métodos de evaluación: ACDM
Métodos de evaluación: ATAM
Ejemplo
Riesgos puntos sensibles y
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Riesgos, puntos sensibles y compromisos
Conclusión
7
¿Qué es la evaluación de la arquitectura ?
La evaluación de la arquitectura es una actividad que permite comprender qué q p p qtan adecuado es el diseño arquitectural
– Se evalúan las decisiones de diseño para saber si permiten o limitan la satisfacción de los requerimientos que influyen a la arquitectura
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– La evaluación produce una lista de defectos y un reporte en donde se da respuesta a esta inquietud
8
23/03/2012
5
Propósito de la evaluación
La evaluación busca responder a la pregunta
L it t ti f l– ¿ La arquitectura satisface losdrivers ?
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()
val idarDatosEspeci fi cos()
<<usa>>
<<produce>>
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Restricciones- De este punto en adelan te se maneja el tipo genérico Subasta
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 exi sten múltiples PC cliente conectadas al si stema
«JDBC»
«JDBC»«RMI»
«HTTPS»
IPersistencia
INegocio
ArquitectoRequerimientos(drivers)
Diseño
9
¿Por qué evaluar la arquitectura?
La evaluación tiene varios propósitos
Evaluar qué tan bien se satisfacen los– Evaluar qué tan bien se satisfacen los atributos de calidad
– Detectar problemas y riesgos de diseño de manera temprana
– Comunicar el diseño
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información10
23/03/2012
6
Costo de corrección de defectos
El costo de corrección de defectos aumenta enormemente entre más tiempo ptranscurre entre el momento en que se inyecta el defecto y el momento en que se corrige
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información11
Importancia de evaluar la arquitectura
De lo que hemos visto en este curso, la arquitectura de software es un artefacto fundamental en el proceso de desarrolloproceso de desarrollo
La estructuración del sistema es lo que permitirá o no que el sistema satisfaga los drivers arquitecturales y es la guía principal durante el desarrollo
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Las decisiones que se toman al momento de diseñar la arquitectura tienen mucho impacto en el sistema
12
23/03/2012
7
¿Cuándo se realiza?
Cuando se construye un sistema
– Dado que la arquitectura se diseña en etapas tempranas, la evaluación también se puede realizar en etapas tempranas del p p pdesarrollo
– Frecuentemente las evaluaciones se realizan de manera tardía para controlar daños
Cuando se modifica un sistema
– La evaluación permite comprender la manera en que la arquitectura soportará los cambios
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Cuando se adquiere un sistema
– La evaluación permite comprender las capacidades y atributos de calidad del sistema
13
¿ Cuándo se realiza ?
Idealmente, la evaluación se debe realizar poco después de que han terminado las actividades de diseño y documentación
Necesidades de negocio
Requerimientos
Diseño arquitectural
Diseño no-arquitectural*
Codificación
Captura y especificación de requerimientos arquitectónicos
Diseño de la arquitectura
Documentación preliminar del diseño arquitectural
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Pruebas
Implantación
Mantenimiento
*Diseño detallado
Evaluación del diseño arquitectural
Documentación detallada del diseño arquitectural+ otras actividades relacionadas con arquitectura
14
23/03/2012
8
Métodos de evaluación
El uso de métodos estructurados de evaluación permite mitigar riesgos de forma temprana a bajo costo
En sistemas en creación, la evaluación se debe realizar en etapas tempranas del desarrollo
– En cuanto terminó la etapa de diseño y documentación preliminar de la arquitectura
Existen diversas técnicas para realizar evaluaciones, cada una tiene costo distinto y provee informaciones distintas
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
una tiene costo distinto y provee informaciones distintas
– Métodos de cuestionamiento– Métodos de medición
15
Métodos de cuestionamiento
Técnicas basadas en escenarios
– Los escenarios describen interacciones entre involucrados y el sistema
– El arquitecto explica la manera en que la arquitectura soporta los escenarios considerados por los evaluadores
– ATAM es el método más conocido
Técnicas basadas en cuestionarios
– El arquitecto responde una lista preparada de preguntas enfocadas ya sea a la arquitectura o al proceso
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
enfocadas ya sea a la arquitectura o al proceso
Técnicas basadas en checklists
– Generalmente se basan en evaluaciones previas de sistemas similares
16
23/03/2012
9
Métodos de medición
Las métricas son interpretaciones cuantitativas de medidas observables (ej. complejidad). Las evaluaciones basadas en métricas se enfocan en
– Escoger un conjunto apropiado de métricas– El resultado de aplicar las métricas– Las suposiciones detrás de la interpretación de las métricas
Simulaciones, prototipos y experimentos
– Involucran la construcción de modelos de la arquitectura específicos al sistema o al dominio
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
específicos al sistema o al dominio• Ej. modelo de desempeño• Es complicado realizar modelos fieles a la realidad
– Pueden ser usados para responder preguntas de evaluación
17
¿Quién participa en la evaluación?
En la evaluación participa principalmente involucrados dentro del proyecto y un
ité d l dcomité de evaluadores– Dentro de los involucrados del proyecto se
encuentran principalmente el arquitecto y el líder de proyecto
– El comité de evaluadores está compuesto por otros arquitectos
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– Los miembros del comité de evaluación no forman parte del proyecto para fomentar objetividad
– Pueden participar otros involucrados
18
23/03/2012
10
Evaluación vs. Inspección
Las inspecciones son una técnica estándar para mejorar la calidad de los sistemas
L i ió (TSP) La inspección (TSP)
– Los participantes reciben documentación y la revisan de forma individual, al final entregan un reporte de inspección
– Es realizada por miembros del equipo que podrían tener menos experiencia técnica que el arquitecto
La evaluación (basada en escenarios)
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
La evaluación (basada en escenarios)
– Es realizada por un equipo de evaluadores con alto nivel técnico que tienen más posibilidad de identificar problemas de diseño y que son externos al equipo
– Es más parecida a un “walkthrough”
19
Índice
Introducción a la evaluación de arquitecturaq
Métodos de evaluación: ACDM
Métodos de evaluación: ATAM
Ejemplo
Riesgos puntos sensibles y
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Riesgos, puntos sensibles y compromisos
Conclusión
20
23/03/2012
11
ACDM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información21
Revisión arquitectural
Propósito
“El propósito de la revisión arquitectural es– El propósito de la revisión arquitectural es de exponer decisiones arquitecturales problemáticas e identificar compromisos entre enfoques o decisiones arquitecturales”
Pasos
Paso Descripción Rol responsable
1 Introducciones y expectativas Líder de proyecto
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Pasos 2 Revisión de objetivos de negocio y Ing. de requerimientos
motivantes arquitecturales - RFs de alto nivel - Restricciones - Atributos de calidad
3 Presentación del “bosquejo” arquitectural Arquitecto
4 Análisis arquitectural Líder y arquitecto
22
23/03/2012
12
Paso 1Introducciones y expectativas
El líder explica la intención de la junta de revisión, explicando el propósitoexplicando el propósito– Asegurarse que todos los participantes comprenden los
drivers arquitecturales– Introducir a participantes al “bosquejo” arquitectural– Identificar decisiones problemáticas
El propósito de la reunión no es
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
El propósito de la reunión no es– Arreglar problemas o discutir soluciones detalladas– Criticar miembros de las organizaciones cliente o de
desarrollo– Discutir problemas de proceso o de la organización
23
Paso 2Revisión de objetivos de negocio y drivers
El equipo de desarrollo presenta los objetivos de negocio y los drivers arquitecturales (RFs, Atributos de Calidad, Restricciones)q ( )
– Permite a todos los participantes refrescar su memoria con respecto a los requerimientos
– Permite corroborar que los atributos de calidad satisfacen los objetivos de negocio
– Permite corroborar si la información original sigue siendo válida o no
Se revisan los atributos de calidad obtenidos en la etapa de captura y documentación
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
captura y documentación
– Se verifica nuevamente la lista inicial
– Es posible agregar nuevos escenarios, en este caso deben volver a ser priorizados)
24
23/03/2012
13
Paso 3Presentación del “bosquejo”
arquitectural
En este paso, el arquitecto presenta la arquitectura a los participantes de manera general.
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
El arquitecto presenta cada una de las vistas explicando la estructuración y funcionamiento del sistema
25
Paso 4Análisis arquitectural
En esta etapa, la arquitectura se analiza con respecto a los escenarios priorizados después de su captura en la fase de
i i tp p p
requerimientos
1.- Se escoge un escenario
2.- Se lee el escenario al grupo
3.- Se le pide al arquitecto que muestre la manera en que la arquitectura responde al estímulo dentro del valor definido dado el estímulo y el entorno.
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
4.- El arquitecto realiza un recorrido de la arquitectura a partir de las vistas mostrando la manera en que se responde al estímulo.
– Durante el recorrido, los participantes pueden cuestionar al arquitecto
– En caso de que el arquitecto no sepa responder, se captura un riesgo. También se identifican compromisos.
26
23/03/2012
14
Riesgos y compromisos
Un riesgo se define como una decisión arquitectural que no satisface adecuadamente un driver arquitectural
– Los riesgos ponen en peligro el poder alcanzar los objetivos de os esgos po e e pe g o e pode a ca a os objet os denegocio
Un compromiso es una decisión arquitectural que tendrá un efecto sobre dos o más atributos de calidad
– Por ejemplo: La decisión de introducir un número elevado de intermediarios con el fin de aumentar la cantidad de puntos en los cuales se verifica que el usuario tiene acceso a los datos (seguridad) impacta negativamente en el desempeño del
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
(seguridad) impacta negativamente en el desempeño del sistema
– Si el desempeño es más importante que la seguridad, esto es un riesgo
27
ACDM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información28
23/03/2012
15
Decisión go / no go
Esta es una etapa corta en la cual el equipo decide si está listo para comenzar a producir el sistema o si es necesario continuar a refinar lasistema o si es necesario continuar a refinar la arquitectura– Esto se realiza a partir de la evaluación de los
riesgos descubiertos en la etapa anterior
¿ Cómo saber en qué momento la arquitectura es “madura” ?
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información29
Signos de madurez
La arquitectura ha madurado los suficiente como para guiar a los diseñadores detallados.
– Las fronteras de componentes están definidas
– Las responsabilidades de los elementos están definidas
– Las interfaces están definidas.
Durante la revisión, el arquitecto respondió adecuadamente sobre la manera en que la arquitectura satisface los escenarios prioritarios
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
No se encontraron riesgos durante la evaluación que pongan en riesgo a la implementación
No aparecieron nuevas motivantes durante la evaluación que requieran cambios significativos
30
23/03/2012
16
Signos de inmadurez
El arquitecto no supo responder a las preguntas relativas a la arquitectura
Existen partes aún no definidas de la arquitectura
El arquitecto tuvo que dibujar una cantidad importante de diagramas adicionales para responder a las preguntas
– La documentación es pobre
S id tifi ú d i d t l l ió
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Se identificaron un gran número de riesgos durante la evaluación
Se identificaron cambios importantes en los objetivos de negocio o drivers arquitecturales
31
ACDM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información32
23/03/2012
17
ACDM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información33
Índice
Introducción a la evaluación de arquitecturaq
Métodos de evaluación: ACDM
Métodos de evaluación: ATAM
Ejemplo
Riesgos puntos sensibles y
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Riesgos, puntos sensibles y compromisos
Conclusión
34
23/03/2012
18
ATAM
Architectura Tradeoff Analysis Method
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información35
Enfoque de ATAM ATAM es un método que permite que los involucrados
hagan preguntas apropiadas con respecto a la arquitectura y que con ello descubran decisiones de diseño problemáticasproblemáticas
– No busca realizar análisis precisos (es decir predecir si los atributos de calidad son satisfechos), el propósito es de descubrir riesgos resultantes de decisiones arquitecturales
Los riesgos que se descubren pueden derivar en actividades de mitigación tales como
– Realización de mayor diseño
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– Realización de mayor diseño– Realización de análisis más detallado– Realización de prototipos
También se identifican y documentan compromisos
36
23/03/2012
19
Pré-condiciones para evaluación
1.- Debe existir una arquitectura– El método no es útil si la arquitectura aún no existe
– El arquitecto debe preparar una presentación de la arquitectura
2.- El cliente debe preparar una presentación de objetivos de negocio
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
3.- Se ha conformado un equipo de evaluación que se ha familiarizado con la arquitectura a través del estudio de documentos
37
Roles ATAM El equipo ATAM consiste de un líder y al menos
otros tres miembrosNo es necesario que sean expertos en el dominio– No es necesario que sean expertos en el dominio
– Deben ser arquitectos con experiencia– Deben tener habilidades de comunicación
Roles de equipo ATAM– Moderador
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– Anotador de escenarios– Guía de proceso– Medidor de tiempo– Cuestionador(es)
38
23/03/2012
20
Fases ATAM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
La evaluación es realizada en 4 fases
39
Fases ATAM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Fase 0: Previa a la evaluación técnica
– Explicaciones acerca del método y del sistema a ser evaluado– Acuerdo de evaluación– Definición de equipo de evaluación
40
23/03/2012
21
Fases ATAM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Fases 1 y 2: La evaluación en sí
– La fase 1 es realizada por un grupo reducido de involucrados y se enfoca en capturar y analizar información detallada de la arquitectura
– La fase 2 participan más involucrados y se enfoca en capturar puntos de vista y verificar resultados de la fase 1
41
Fases ATAM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Fase 3: Seguimiento de la evaluación– Producción de un reporte final de evaluación
42
23/03/2012
22
Pasos ATAM 1.- Presentación del ATAM
2.- Presentación de objetivos de negocio
3 Presentación de la arquitectura 3.- Presentación de la arquitectura
4.- Identificación de enfoques arquitectónicos
5.- Generación de árbol de atributos de calidad
6.- Análisis de enfoques arquitecturales
7.- Lluvia de ideas y priorización de escenarios
8.- Análisis de enfoques arquitecturales
9 P t ió d lt d
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
9.- Presentación de resultados
Fase 1
Fase 2
43
Árbol de Utilidad
Propósito: Identificación de drivers
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información44
23/03/2012
23
Flujo conceptual ATAM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información45
Índice
Introducción a la evaluación de arquitecturaq
Métodos de evaluación: ACDM
Métodos de evaluación: ATAM
Ejemplo
Riesgos puntos sensibles y
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Riesgos, puntos sensibles y compromisos
Conclusión
46
23/03/2012
24
Ejemplo
Siguiendo los pasos de ACDM
Paso Descripción Rol responsable
1 Introducciones y expectativas Líder de proyecto
2 Revisión de objetivos de negocio y Ing. de requerimientosmotivantes arquitecturales - RFs de alto nivel - Restricciones - Atributos de calidad
3 Presentación del “bosquejo” arquitectural Arquitecto
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
3 Presentación del bosquejo arquitectural Arquitecto
4 Análisis arquitectural Líder y arquitecto
47
Posible estructura para presentación
Presentación general del sistema– Objetivos de negocio
Di d t t– Diagrama de contexto– Modelo de casos de uso
Lista de drivers
Escenario 1– Decisiones de diseño
Escenario n
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– Decisiones de diseño
Estatus de satisfacción de drivers
Riesgos y problemas latentes
48
23/03/2012
25
Necesidades Problemática: Se ha desarrollado una colección de
sistemas específicos para un cliente que desea poder controlar el acceso a los sistemas de forma
t li dpcentralizada
Las necesidades son:– Implementar un punto único de acceso a todos los
sistemas específicos– Soportar el acceso a todos los sistemas específicos con
una sola contraseña
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
una sola contraseña– Soportar la administración de usuarios y permisos de
todos los sistemas específicos de forma centralizada– Llevar una bitácora centralizada de los eventos
realizados por los usuarios dentro de los sistemas específicos
49
Diagrama de Contexto
Diagrama de contexto
Sistema de controlCentralizado de
Seguridad (SiCCS)
Usuario de sistemaespecífico
Sistemaespecífico
Solicitud de ingresoa sistema especifico
Sistemaespecífico
Permisos de accesode usuarios
Bitácoras deeventos
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
AdministradorDatos de usuariosDatos de permisosDatos de s. específicos
Flujo de información
Entidad externa
El sistema
Información deeventos
50
23/03/2012
26
Casos de uso
CU Primarios: 003, 002, 001, 004 y 007SystemSistema de Control Centralizado de Seguridad (SiCCS) y
Sistema Específico
RU-001: Controlar ingreso a sistema específico
Usuario
RU-002: Proporcionar permisos de acceso de usuarios
Sistema de Control Centralizado de Seguridad (SiCCS)
RU-003: Ingresar a sistema específico
RU-004: Almacenar evento
<<include>>
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
RU-005: Administar usuarios
RU-006: Administrar permisosAdministrador
RU-007: Consultar bitácoras de eventos
51
Atributos de calidad
Escalabilidad– En un momento normal de operación el sistema debe
soportar 500 usuarios concurrentessoportar 500 usuarios concurrentes
Desempeño– Un usuario realiza una solicitud a SiCCS de ingreso a un
sistema específico en un momento normal de operación. La operación es atendida en un tiempo no mayor a 20 segundos
DisponibilidadUna falla ocurre en SiCCS durante el periodo
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– Una falla ocurre en SiCCS durante el periodo comprendido entre las 9:00 y las 18:00. La falla es registrada y la operación del sistema continúa con una interrupción no mayor a 5 minutos
52
23/03/2012
27
Restricciones Interfaz de usuario
– La pantalla de ingreso a los sistemas específicos deberá apegarse al estándar institucionalapegarse al estándar institucional
Entorno de usuario– Los usuarios acceden a las aplicaciones especificas
usando un navegador IE6.0 o superior o Firefox 2.0 o superior
Base de datos– La información de eventos, usuarios y permisos será
almacenada en la base de datos de la institución (Oracle
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
almacenada en la base de datos de la institución (Oracle Vx.x)
Comunicación en red– La comunicación entre SiCCS y los sistemas específicos
se realiza a través de una red con un ancho de banda máximo de 1024kbps
53
Ejemplo
Siguiendo los pasos de ACDM
Paso Descripción Rol responsable
1 Introducciones y expectativas Líder de proyecto
2 Revisión de objetivos de negocio y Ing. de requerimientosmotivantes arquitecturales - RFs de alto nivel - Restricciones - Atributos de calidad
3 Presentación del “bosquejo” arquitectural Arquitecto
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
3 Presentación del bosquejo arquitectural Arquitecto
4 Análisis arquitectural Líder y arquitecto
54
23/03/2012
28
Presentación de escenario
La siguiente etapa es la parte central de la evaluación. Se elige un driver y el arquitecto describe la manera en que el sistema losdescribe la manera en que el sistema los soporta
Se puede iniciar mostrando escenarios funcionales y después enfocarse en escenarios de atributos de calidad
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Durante la presentación del escenario, los evaluadores toman nota sobre puntos que consideren que sea necesario cuestionar
55
Análisis de escenario funcional
Se elige un escenario para CU-003
System
Sistema Específico
RU-001: Controlar ingreso a sistema específico
Usuario
RU-002: Proporcionar permisos de acceso de usuarios
Sistema de Control Centralizado de Seguridad (SiCCS)
RU-003: Ingresar a sistema específico
<<include>>
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
RU-005: Administar usuarios
RU-006: Administrar permisosAdministrador
RU-004: Almacenar evento
RU-007: Consultar bitácoras de eventos
56
23/03/2012
29
Escenario Funcional
CU-003: Ingresar a sistema específico, flujo principal
Pré-condición:
– Usuario dado de alta
– Usuario no se ha autentificado
Escenario (flujo principal)
– El actor ingresa a la página del portal de aplicaciones
– El sistema solicita identificación
– El usuario introduce login y password
– El sistema muestra el catálogo de sistemas específicos disponibles al usuario
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– El usuario selecciona un sistema específico
– El sistema proporciona los permisos del usuario al sistema específico seleccionado (CU-002) y transfiere el control hacia este
Post-condición
– El usuario se encuentra dentro del sistema específico elegido
57
Vista física
Diagrama de implantación
Servidor SiCCS<<clustered>>
Sistema SICCSSistema SICCSServidor BD
BDBD<<JDBC>>
Servidor Sistema Específico
Sistema EspecíficoSistema Específico<<HTTP/SOAP>>
<<HTTP>>
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
PC Usuario
NavegadorNavegador
<<HTTP>>
58
23/03/2012
30
Vista lógica
Capas y componentes del escenario
Capa presentación
Capa negocio
Login<<JSF>>
LoginServiceImpl
LoginService
ContolAccesoSistemaEspecificoImpl
ControlAccesoSE
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Capa datos
DAOUsuarioImpl
DAOPermisoImpl
DAOPermiso
DAOUsario
ControlAccesoSE
59
Ejemplo: Vista dinámica
Diagrama de secuencia del escenario : Login : LoginService : DAOUsario : DAOPermiso : ControlAccesoSE
: Usuario
g g : ControlAccesoSE
1 : URL SiCCS
2 : Login y Password
3 : valida()
4 : ingresaUsuario()5 : recupera()
6 : Usuario
7 : validaAcceso()
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
7 : validaAcceso()
8 : recupera()
9 : Permisos10 : enviaPermisos()
1112 : Redireccion()
60
23/03/2012
31
Preguntas de evaluación
Ejemplo
¿Qué tamaño tiene (en promedio) una lista– ¿Qué tamaño tiene (en promedio) una lista de permisos que se transfiere a un sistema específico?
• ¿En qué formato se transfiere la lista de permisos al sistema específico?
• ¿En un momento dado si se realiza un número
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
elevado de ingresos al sistema, la cantidad de información no excederá el ancho de banda permitido ?
– ¿Los paquetes de permisos se envían “en claro”?
61
Análisis de Escenario de
atributo de calidad Disponibilidad
Una falla ocurre en SiCCS durante el– Una falla ocurre en SiCCS durante el periodo comprendido entre las 9:00 y las 18:00. La falla es registrada y la operación del sistema continúa con una interrupción no mayor a 5 minutos
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información62
23/03/2012
32
Vista física
Implantación: RedundanciaStationary IP
Servidor SiCCS ServidorSiCCS2
ServiceGuard
PC Usuario<<HTTP>>
Stationary IP
Stationary IP
Uses relocatable IP
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Servidor BD
<<JDBC>> <<JDBC>>
High Availability Disk Array
Activo
63
Vista dinámica
Diagrama de secuencia: fallo
: PC Usuario : Servidor SiCCS : ServiceGuard : ServidorSiCCS2
1 : mensaje()
2 : latido()
El servidor SiCCS deja de emitir latidos
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
j
3 : activa()
4 : transfiereIP()
5 : mensaje()
64
23/03/2012
33
Preguntas de evaluación
¿ Qué pasa con la transferencia de estado ?
¿ Qué pasa si falla Service Guard ?
¿ Cuánto tiempo toma la activación del servidor redundante ?
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información65
Índice
Introducción a la evaluación de arquitecturaq
Métodos de evaluación: ACDM
Métodos de evaluación: ATAM
Ejemplo
Riesgos puntos sensibles y
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Riesgos, puntos sensibles y compromisos
Conclusión
66
23/03/2012
34
Ejemplo
Siguiendo los pasos de ACDM
Paso Descripción Rol responsable
1 Introducciones y expectativas Líder de proyecto
2 Revisión de objetivos de negocio y Ing. de requerimientosmotivantes arquitecturales - RFs de alto nivel - Restricciones - Atributos de calidad
3 Presentación del “bosquejo” arquitectural Arquitecto
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
3 Presentación del bosquejo arquitectural Arquitecto
4 Análisis arquitectural Líder y arquitecto
67
Riesgos, puntos sensibles y
compromisos Dependiendo de las respuestas que
hace el arquitecto se identifican issues qasociados con el diseño
Estos issues pueden ser de distintos tipos:
– Riesgos
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– Puntos sensibles
– Compromisos
68
23/03/2012
35
Riesgos Se refieren a decisiones de diseño en la
arquitectura que– No han sido tomadas– Cuyas consecuencias no se comprenden
totalmente
Ejemplo
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
j p– Un riesgo puede ser que no se ha
considerado la falla del coordinador (Service Guard)
69
Puntos Sensibles
Un puntos sensible se refiere a una decisión de diseño que que afectan directamente en la respuesta de un atributo de calidad particular
Ejemplo:– El tamaño de los paquetes de permisos
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– El tamaño de los paquetes de permisos influye sobre la cantidad de peticiones simultáneas que se pueden soportar
70
23/03/2012
36
Compromisos Un compromiso se refiere a una decisión
de diseño que impacta en la respuesta de más de un atributo de calidad de manera simultánea
Ejemplo– El nivel de encriptación que se use para
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
– El nivel de encriptación que se use para transmitir los paquetes de permisos influye positivamente sobre la seguridad pero impacta negativamente en el desempeño
71
Ejemplos Riesgo
– Se optó por hacer un mecanismo de login centralizado p p gad-hoc en vez de reutilizar alguna solución existene
Punto sensible
– El tamaño de los paquetes de permisos influye sobre la cantidad de peticiones simultáneas que se pueden soportar
Compromiso
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Compromiso
– El nivel de encriptación que se use para transmitir los paquetes de permisos influye positivamente sobre la seguridad pero impacta negativamente en el desempeño
72
23/03/2012
37
Plantilla de documentación
Ejemplo: ATAM
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información73
Índice
Introducción a la evaluación de arquitecturaq
Métodos de evaluación: ACDM
Métodos de evaluación: ATAM
Ejemplo
Riesgos puntos sensibles y
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información
Riesgos, puntos sensibles y compromisos
Conclusión
74
23/03/2012
38
Conclusión La evaluación del diseño de la
arquitectura de software es una actividad fundamental que permite eliminar defectos de manera temprana
Es distinta de la inspección
Se enfoca en la identificación de riesgos relativos al diseño
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información75
¿Preguntas?
Gracias
MIS‐ Arquitectura de Software / PCyTI Posgrado en Ciencías y Tecnologías de la información76