Evaluación de la arquitecturaliim.izt.uam.mx/.../download/11_EvaluacionDeArquitectura.pdf23/03/2012...

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


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


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

ó


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


Riesgos, puntos sensibles y compromisos

Conclusión

6

23/03/2012

4

Índice




Ejemplo




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


– 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


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


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


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


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


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


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


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


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


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


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


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


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




Ejemplo




Conclusión

20

23/03/2012

11

ACDM


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


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


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


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.


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.


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


(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


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


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


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ó


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


23/03/2012

17

ACDM


Índice




Ejemplo




Conclusión

34

23/03/2012

18

ATAM

Architectura Tradeoff Analysis Method


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


– 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


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


– Anotador de escenarios– Guía de proceso– Medidor de tiempo– Cuestionador(es)

38

23/03/2012

20

Fases ATAM


La evaluación es realizada en 4 fases

39

Fases ATAM


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


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


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


9.- Presentación de resultados

Fase 1

Fase 2

43

Árbol de Utilidad

Propósito: Identificación de drivers


23/03/2012

23

Flujo conceptual ATAM


Índice




Ejemplo




Conclusión

46

23/03/2012

24

Ejemplo

Siguiendo los pasos de ACDM



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


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


– 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


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


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


RU-005: Administar usuarios

RU-006: Administrar permisosAdministrador

RU-007: Consultar bitácoras de eventos

51


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


– 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


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









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


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


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


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


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


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


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


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


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


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


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 ?


Índice




Ejemplo




Conclusión

66

23/03/2012

34

Ejemplo









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


– 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


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


– 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


– 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


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


Índice




Ejemplo




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


¿Preguntas?

Gracias


Evaluación de la arquitecturaliim.izt.uam.mx/.../download/11_EvaluacionDeArquitectura.pdf23/03/2012...

Documents

Transcript of Evaluación de la arquitecturaliim.izt.uam.mx/.../download/11_EvaluacionDeArquitectura.pdf23/03/2012...