Arquitectura 4+1 Vistas

Zulaima Chiquin Sistemas de Informacin - Universidad Simn

Fase de Elaboracin

Fase de Elaboracin: Objetivos

Especficos:

Obtener un entendimiento ms detallado de los requerimientos Disear, implementar, validar y generar una lnea base para la arquitectura:

Definir los subsistemas, los componentes claves y sus interfaces Usar los casos de uso significativos arquitectnicamente para dirigir la arquitectura Disear los casos de uso crticos; consolidar y empaquetar las clases identificadas Disear la BD

Fase de Elaboracin
Arquitectura del Software (AS):

La fase de elaboracin se enfoca en obtener una Arquitectura de Software Estable que satisfaga los requerimientos La arquitectura de software es usada en RUP como un artefacto primario para conceptualizar, gerenciar, construir y hacer evolucionar el sistema en desarrollo.

Fase de Elaboracin: Artefactos

Arquitectura de Software Modelacin

Uno de los fundamentos de RUP es la modelacin. Los modelos ayudan a entender y compartir el problema y la solucin Desde esta perspectiva un modelo no es suficiente para cubrir todos los aspectos del desarrollo del software, por lo tanto necesitamos mltiples modelos para resaltar a cada contexto. Los modelos pueden ser coordinados para asegurar su consistencia y no redundancia.

Arquitectura de Software Organizacin

Entendimiento del propsito Por qu la arquitectura es importante? Qu beneficios brinda ese enfoque de arquitectura? Cmo se puede desarrollar? Representacin de la arquitectura Cmo lograr que el concepto de arquitectura no sea tan difuso y se disponga de un acuerdo en la forma de representarla? Y por ende de comunicarla, revisarla, comentarla y mejorarla sistemticamente Procesos de arquitectura Cmo crear y validar la arquitectura que satisface las necesidades del proyecto?, Quin lo hace? Qu artefactos y atributos de calidad son propios de esta tarea?

Arquitectura de Software

Paul Clements (1996):

La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones.

Conceptos Fundamentales Vistas & Frameworks

Zachman (Niveles) Alcance Empresa Sistema lgico Tecnologa Representacin Funcionamiento TOGAF (Arquitecturas) Negocios Datos Aplicacin Tecnologa 4+1 (Vistas) Lgica Proceso Fsica Desarrollo Casos de uso [BRJ99] (Vistas) Diseo Proceso Implementacin Despliegue Casos de uso POSA (Vistas) Lgica Proceso Fsica Desarrollo Microsoft (Vistas) Lgica Conceptual Fsica

Tabla 1 Vistas en los marcos de referencia Tabla 1: Vistas que- proponen diferentes Frameworks

La mayora de los frameworks proponen entre tres y seis vistas. Una vista, puede considerarse como el subconjunto resultante de practicar una seleccin o abstraccin sobre una realidad, desde un punto de vista determinado.

Vistas de UML
UML especifica nueve (9) clases correspondientes a ocho (8) vistas:
rea Estructural Vista Vista esttica Vista de casos de uso Vista de implementacin Vista de despliegue Dinmica Vista de mquinas de estados Vista de actividad Vista de interaccin Gestin del modelo Diagramas Diagrama de clases Diagramas de casos de uso Diagrama de componentes Diagrama de despliegue Diagrama de estados Diagrama de actividad Diagrama de secuencia Diagrama de colaboracin Diagrama de clases

de

diagramas

Conceptos principales Clase, asociacin, generalizacin, dependencia, realizacin, interfaz Caso de uso, actor, asociacin, extensin, inclusin, generalizacin de casos de uso Componente, interfaz, dependencia, realizacin Nodo, componente, dependencia, localizacin Estado, evento, transicin, accin Estado, actividad, transicin de terminacin, divisin, unin Interaccin, objeto, mensaje, activacin Colaboracin, interaccin, rol de colaboracin, mensaje Paquete, subsistema, modelo

Vista de gestin del modelo Tabla 2 - Vistas y 2. Vistas y de UML, basado en [RJB00: 22] Tabla diagramas Diagramas de UML

Estilos Arquitectnicos

Estilos de Flujo de Datos Tubera y filtros Estilos Centrados en Datos Arquitecturas de Pizarra o Repositorio Estilos de Llamada y Retorno Model-View-Controller (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes Estilos Derivados C2 GenVoca REST

Estilos de Cdigo Mvil Arquitectura de Mquinas Virtuales Estilos heterogneos Sistemas de control de procesos Arquitecturas Basadas en Atributos Estilos Peer-to-Peer Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios (SOA) Arquitecturas Basadas en Recursos

Arquitectura de Software

Disear la AS, es definir los aspectos estructurales como una composicin de componentes, las estructuras globales de control, los protocolos de comunicacin, la sincronizacin y acceso a los datos, la asignacin de la funcionalidad a los elementos del diseo, la composicin de estos elementos, su distribucin fsica, su escalabilidad y su desempeo.

Arquitectura de Software es
Vista estructural de alto nivel, descomposicin del sistema en
subsistemas, mdulos, componentes, hasta alcanzar el nivel de granularidad deseado

Define un estilo o combinacin de estilos para una solucin. Un

estilo es un concepto descriptivo que define una forma de articulacin u organizacin arquitectnica. Conjuga elementos o componentes, conectores, configuraciones y restricciones

Se concentra en requerimientos no funcionales Los requerimientos funcionales se satisfacen mediante

modelado y diseo de aplicacin

Esencial para xito o fracaso de un proyecto

Arquitectura 4+1 Vistas

El Modelo 4+1 Vistas organiza la descripcin de la arquitectura de un software usando cinco (5) vistas concurrentes, cada una de las cuales est dirigida a un conjunto especfico de conceptos Los arquitectos exponen sus decisiones de diseo en cuatro (4) vistas y usan la quinta vista para ilustrar y validar dichas decisiones.

EL MODELO DE ARQUITECTURA 4+1 VISTAS

Usuarios finales funcionalidad Vista Lgica Vista Lgica Programadores gerencia del software Vista de Desarrollo Vista de Desarrollo Escenarios Escenarios Vista de Proceso Vista de Proceso Integradores de sistemas desempeo escalabilidad rendimiento Vista Fsica Vista Fsica Ingenieros de sistemas topologa del sistema entregas instalacin telecomunicacin

Arquitectura 4+1 Vistas

VISTA LGICA Utiliza el mtodo de diseo OO; se puede usar un enfoque alterno para desarrollar alguna otra forma de vista lgica. Comprende las abstracciones fundamentales del sistema a partir del dominio del problema. Trata de clases y subsistemas, soporta los requerimientos funcionales, identifica mecanismos y disea elementos comunes a travs del sistema VISTA DE PROCESO Describe los aspectos de diseo relacionados con la concurrencia y la sincronizacin. Especifica las lneas de mando que ejecutan cada operacin en cada una de las clases sealadas en la vista lgica. Los diseadores realizan esta vista en varios niveles de abstraccin, adems de dividir el software en conjuntos independientes de tareas, es decir, se empaqueta en pequeos programas o libreras del subsistema.

Arquitectura 4+1 Vistas

VISTA DE IMPLEMENTACIN Describe la organizacin esttica del software en el ambiente de desarrollo. VISTA IMPLANTACIN (FSICA) Describe el mapa del SW dentro del HW, refleja los aspectos de distribucin. Toma en cuenta los requerimientos no funcionales del sistema, tales como confiabilidad, respuesta y escalabilidad. CASOS DE USO (ESCENARIOS) Los diseadores de software organizan la descripcin de sus decisiones arquitecturales alrededor de estas cuatro (4) vistas, y las ilustran con una pequea seleccin de casos de uso o escenarios, constituyendo as la quinta vista. La arquitectura est parcialmente producida por esos escenarios.

ARQUITECTURA 4+1 VISTAS

a)
Vista Lgica Vista de Implementacin Programadores Gerencia de Software

b)

Usuario Final Funcionalidad

Vista Lgica
Clases , interfaces, Colaboracin Vista

Vista de Implementacin
Componentes

Funcional
Vista de Proceso Vista de Casos de Uso Vista de Implantacin Integradores del Sistema Desempeo Escalabilidad Productividad Ingeniera de Sistema Topologa del Sistema Entrega, instalacin Comunicacin

de Casosde

Us Vista de o Proceso Vista de Implantacin

Clases Activas Nodos

Conceptual

Fsica

Organizacin Dinmicas Package, Subsistema Interaccin Mquina Estados de

b)

a) Modelo 4+1 Vistas Modelo 4+1 Vistas y elementos de UML (Booch, 1999)

Entregables
Modelo conceptual Diagrama de clases Diagramas de estados Distribucin en capas Plataforma de software Libreras, paquetes y patrones

Vista Lgica Vista Lgica

Vista de implementacin Vista de implementacin (Desarrollo) (Desarrollo)

Casos de Uso (Escenarios) Casos de Uso (Escenarios) Casos de uso (diagrama y desc.) Casos de uso (diagrama y desc.) Diagramas de secuencia Diagramas de secuencia Vista de Proceso Vista de Proceso Diagrama de procesos Vista Implantacin Vista Implantacin (Fsica) (Fsica) Descripcin de hardware

Vista de Casos de Uso

Esta vista es redundante con respecto a las otras, pues representa como una especie de compendio de las otras cuatro, de all que venga el +1, sin embargo juega dos papeles crticos (Kruchten-1, 1995): (1) Acta como un manejador para ayudar a los diseadores a descubrir los elementos arquitecturales durante el diseo de la arquitectura.

Vista de Casos de Uso

(2) Valida e ilustra el diseo de la arquitectura en papel y tambin se utiliza como punto de partida de las pruebas de un prototipo arquitectural. Esta vista contiene los escenarios o casos de uso claves, para cada uno de los cuales se describen las secuencias de interaccin entre objetos y procesos.

Vista de Casos de Uso

(Kruchten-1, 1995) Para ello se crean los diagramas de secuencia y los diagramas de colaboracin para mostrar la manera en que los diversos elementos del diseo interactan para producir el comportamiento deseado (Quatrani, 1998) Los escenarios consisten en instancias de los casos de uso y son, hasta cierto punto, una abstraccin de los requerimientos ms importantes. Para disearlos se utilizan los diagramas de interaccin de objetos y los diagramas de escenarios de objetos (Kruchten-1, 1995).

Vista de Casos de Uso

Por lo tanto, en esta vista de la arquitectura se incluyen: los casos de uso (diagramas y descripciones), los diagramas de interaccin (diagramas de secuencia o diagramas de colaboracin) y cualquier otro diagrama que se considere necesario para comprender mejor la funcionalidad del sistema, tales como los diagramas de estados, diagramas de actividades, entre otros.

Vista Lgica

Incluye el modelo conceptual y el diagrama de clases para el sistema. Una vez construido el diagrama de clases, se proceder a ilustrar como es la distribucin de las clases por paquetes, conservando en un mismo paquete aquellas clases que se encuentren estrechamente relacionadas por expresar o referirse a un mismo concepto del dominio del problema.

Vista Lgica
Proceso para elaborar estos diagramas:

Modelo conceptual. Tomando como base el modelo de procesos del negocio y el modelo de objetos del negocio, se procede a identificar los conceptos ms resaltantes que forman parte del dominio del problema. Luego, se establecen las relaciones que existen entre ellos. Diagrama de clases. Tomando como base el modelo conceptual, se identifican aquellos conceptos sobre los cuales se requiere hacer algn tipo de procesamiento de la informacin que representan, en el contexto de la aplicacin a desarrollar.

En resumen

Dominio del problema

conceptos reglas dominio

Process Sale

Payment Authorization Service

restricciones

Cashier Process Rental Accounting System Cash In HR System

Visin

Caso del negocio

ERS

Manage Users Syst em Administrator Mangage Accounts

...

Lista de riesgos

Proc ess Sale

Payment Authorization Service

Casos de Uso del Sistema

Cashier Process Rental Accounting System Cash In HR System Manage Users Syst em Administ rat or Mangage Accounts

...

Glosario

Casos de Uso del Negocio

Descripciones de CU

En resumen

Dominio de la solucin

Anlisis y Diseo

Validacin

Process Sale

Payment Authorization Service

Cashier Process Rental Accounting System Cash In HR System

Glosario

DAS

Manage Users Syst em Administrator Mangage Accounts

: Cashier makeNewSale() enterIt em(id,quantity)

System

: Payment Authorization Service

endSale()

...
makePayment(amount)

Casos de Uso
performed

validatePayment() ok

Customer

POSRegister
Payment ammount : Double described-by ProductSpecification

Diagramas de Secuencia
ad d file

Pays-for 1 Captured-on

Sale

makePayment () creat ePayment() POS Payment POS Sale makePayment() amount : Money getTotal()
Op en nin g a d d file [ nu m b e rO ffil e ==M AX ] / fl ag O FF

n cotains Store ProductCatalog

W r iting

1 Register

clo se fil e

c lo se file R e ad in g

Clo sin g

Modelo Conceptual (atributos-relaciones)

Diseo Clases (atributos/operaciones-relaciones)

Diagramas Estados

Modelado Visual del Software

Diagramas Estado Diagramas de Clases Diagramas Componentes

Modelo
Diagramas Escenarios Diagramas Desarrollo Diagramas Casos de Uso

Vista Lgica Diagrama Conceptual

Vista Lgica Diagrama Conceptual

Vista Lgica Diagrama de Clases

Vista Lgica Diagrama de Clases

Describen la estructura del sistema

RegistrationForm ScheduleAlgorithm

0..* 1

RegistrationManager

addStudent(Course, Student)

1 RegistrationUser
name name

Course 0..*
numberCredits open() addStudent(Student)

Student
major

3..10

Professor
tenureStatus

4 CourseOffering 1 0..4
location open() addStudent(Student}

1..*

Diagrama de Clases

Un sistema OO se construye, fundamentalmente, definiendo clases. Los objetos identificados en el dominio de aplicacin son agrupados en clases, cada una de las cuales representa una categora de objetos que tienen iguales propiedades (atributos) y comportamientos (operaciones, mtodos o servicios). La clase como componente principal del sistema, y las relaciones entre sta y otras clases, hacen posible la estructuracin lgica de un sistema OO.

Diagrama de Clases

Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. El primer bloque de la figura representa el nombre de la clase, el segundo bloque contiene los atributos, y el tercer bloque contiene las operaciones Modelar el vocabulario de un sistema. Hay que identificar aquellas cosas que utilizan los usuarios para describir el problema o la solucin

Diagrama de Clases

Las clases casi nunca se encuentran aisladas. Por lo general, la mayora de ellas colaboran con otras de varias maneras. Hay que modelar la forma en que las clases se relacionan En el modelado orientado a objetos hay tres tipos de relaciones: Dependencias Generalizaciones Asociaciones

Diagrama de Clases

Una dependencia es una relacin de uso, que declara que un cambio en la especificacin de un elemento (por ejemplo, la clase Evento) puede afectar a otro elemento que la utiliza (por ejemplo, la clase Ventana), pero no necesariamente a la inversa (la flecha va dirigida hacia el elemento del cual se depende). Una dependencia quiere decir que un elemento utiliza a otro.

Diagrama de Clases

Una generalizacin conecta una clase general (superclase o padre) con otra clase ms especializada (subclase o hijo). Es una relacin "es-un" o "es-una". CuadroDialogo es una Ventana. Por ejemplo, el

Diagrama de Clases

Las asociaciones son relaciones estructurales entre instancias, que especifican que los objetos de un elemento estn conectados con los objetos de otro. Es posible que los objetos de una clase estn conectados con objetos de la misma clase.

Hay cuatro tipos de "adornos"

que se le pueden poner a estas relaciones: nombre, rol, multiplicidad y agregacin

Diagrama de Clases

Nombre: Una
asociacin puede tener un nombre, que se utiliza para describir la naturaleza de la relacin. Para evitar ambigedades, se puede indicar una direccin al nombre, es decir, la direccin en que se debe leer el nombre.

Rol: Un rol es la cara

que la clase de un extremo de la asociacin presenta a la clase del otro extremo. Es el rol que juega la clase en la asociacin.

Multiplicidad:
Representa el nmero de objetos que pueden conectarse a travs de una relacin de asociacin. Se puede indicar una multiplicidad de exactamente uno (1), cero o uno (0..1), muchos (0..*), o uno o ms (1..*). Tambin se puede indicar un valor exacto (por ejemplo, 3).

Diagrama de Clases
Agregacin: A veces se desea modelar una
relacin de tipo "todo/parte", en la cual una clase representa algo grande (el todo), que consta de elementos ms pequeos (las partes). Este tipo de relacin se denomina agregacin, y es una relacin "tiene-un" o "tiene-una".

Composicin: Es un tipo especial de asociacin,

que tambin modela relaciones "todo/parte". La diferencia es que tiene una fuerte relacin de pertenencia de la parte con el todo. Las "partes" pueden crearse despus del "todo", pero una vez creadas, viven y mueren con el "todo" (se pueden eliminar explcitamente antes). Quiere decir que una "parte", solamente puede estar relacionada con un "todo.

Diagrama de Clases Ejemplo 1

Diagrama de Clases Ejemplo 2

Gracias por su atencin