DIAGRAMAS DEL MODELO 4+1

Desarrollo de Proyectos de Software

Guel Villela David Arturo 11/03/2013

MODELO 4+1
El modelo 4+1 de Kruchten, es un modelo de vistas diseado por el profesor Philippe Kruchten y que encaja con el estndar IEEE 1471-2000 (Recommended Practice for Architecture Description of Software-Intensive Systems ) que se utiliza para describir la arquitectura de un sistema software intensivo basado en el uso de mltiples puntos de vista.

VISTAS DEL DIAGERAMA

VISTA LOGICA
Vista Lgica: En esta vista se representa la funcionalidad que el sistema proporcionara a los usuarios finales. Es decir, se ha de representar lo que el sistema debe hacer, y las funciones y servicios que ofrece. Para completar la documentacin de esta vista se pueden incluir los diagramas de clases, de comunicacin o de secuencia de UML.

DIAGRAMA DE CLASES
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento. Un diagrama de clases esta compuesto por los siguientes elementos: Clase: atributos, mtodos y visibilidad. Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

ELEMENTOS
Clase Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectngulo que posee tres divisiones:

En donde: Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

ATRIBUTOS
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son: public (+, ): Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. private (-, ): Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar). protected (#, ): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de las subclases que se deriven (ver herencia).

METODOS
Los mtodos u operaciones de una clase son la forma en como sta interacta con su entorno, stos pueden tener las caractersticas: public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden accesar). protected (#, ): Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de mtodos de las subclases que se deriven (ver herencia).

RELACIN ENTRE CASES

Ahora ya definido el concepto de Clase, es necesario explicar como se
pueden interrelacionar dos o ms clases (cada uno con caractersticas y objetivos diferentes). Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relacin y stas pueden ser:

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) nmero fijo: m (m denota el nmero).

DIAGRAMA DE COMUNICACIN
Un diagrama de Comunicacin modela las interacciones entre objetos o partes en trminos de mensajes en secuencia. Los diagramas de Comunicacin representan una combinacin de informacin tomada desde el diagrama de Clases, Secuencia, y Diagrama de casos de uso describiendo tanto la estructura esttica como el comportamiento dinmico de un sistema.

Un diagrama de Comunicacin modela las interacciones entre objetos o partes en trminos de mensajes en secuencia. Los diagramas de Comunicacin representan una combinacin de informacin tomada desde el diagrama de Clases, Secuencia, y Diagrama de casos de uso describiendo tanto la estructura esttica como el comportamiento dinmico de un sistema. Los diagramas de comunicacin y de secuencia describen informacin similar, y con ciertas transformaciones, pueden ser transformados unos en otros sin dificultad. Para mantener el orden de los mensajes en un diagrama de comunicacin, los mensajes son etiquetados con un nmero cronolgico y colocado cerca del enlace por el cual se desplaza el mensaje. Leer un diagrama de comunicacin conlleva comenzar en el mensaje, y seguir los mensajes desde un objeto hasta el siguiente, sucesivamente.

SIMBOLOGA
ACTORES: QUIENES PARTICIPAN EN EL DIAGRAMA

ASOCIACION: RELACION ESTRE DOS ELELMENTOS

COMENTARIO: PERMITE ADICIONAR EXPLICACIONES.

HERENCIA: INDICA QUE UN EJEMPLO ES UNA ESPECIALIZACION DE OTRO.

VENTAJAS
1. PUEDEN AYUDAR A CORREJIR LA LOGICA INCOMPLETA O INCORRECTA. 2. TIENEN UN DISEO DE FORMA LIBRE

3. REPRESENTA UNA COMBINACION DE LA

INFORMACION

DESVENTAJAS
1. NO PUEDEN USAR POCOS ESCENARIOS 2. SOLO SE PUEDEN UTILIZAR EN LA FASE DE DISEO O EN LA IMPLEMENTACION.

3. A MEDIDA DE QUE SE EJECUTAN LOS MENSAJES NO

SIEMPRE SE MUESTRA SU ORDEN.

DIAGRAMA DE SECUENCIA
El diagrama de secuencias en UML muestra la forma en que los objetos se comunican entre s al transcurrir el tiempo. El diagrama muestra Los objetos participando en la interaccin La secuencia de mensajes intercambiados . Un diagrama de secuencia contiene: Objetos con sus lneas de vida Mensajes intercambiados entre objetos en una secuencia ordenada Lnea de Vida Activa (opcional)

OBJETOS
El diagrama de secuencias consta de objetos que se representan del modo usual: rectngulos con nombre (subrayado), mensajes entre los objetos representados por lneas

continuas con una punta de flecha y el tiempo representado como una progresin
vertical. Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama.

La extensin que est debajo (y en forma descendente) de cada objeto ser una lnea
discontinua conocida como la lnea de vida de un objeto. Junto con la lnea de vida de un objeto se encuentra un pequeo rectngulo conocido como activacin, el cual representa la ejecucin de una operacin que realiza el objeto. La

longitud del rectngulo se interpreta como la duracin de la activacin.

MENSAJES
Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto a la de otro. Un objeto puede enviarse un objeto a s mismo (es decir, de su lnea de vida a su propia lnea de vida). Un mensaje puede ser simple, sncrono o asncrono. Un mensaje simple es la transferencia del control de un objeto a otro. Un mensaje sncrono es aquel en el que el objeto espera la respuesta a ese mensaje antes de continuar con su trabajo. Un mensaje asncrono es aquel en el que el objeto no espera la respuesta a ese mensaje antes

de continuar.
En el diagrama de secuencias, los smbolos del mensaje varan. Por ejemplo, la punta de la flecha de un mensaje simple est compuesta por dos lneas, la punta de flecha de un mensaje sncrono es un tringulo relleno, y la de uno asncrono solo tiene una sola lnea.

INSTANCIAS Y GENERICOS

RECURSIVIDAD
En ocasiones un objeto posee una operacin que se invoca a s misma. A esto se le conoce como recursividad, y es una caracterstica

fundamental de varios lenguajes de programacin. Por ejemplo,

supongamos que una calculadora forma parte de los objetos de nuestro sistema y que una de sus operaciones sea el clculo de intereses. Para calcular el inters compuesto para un periodo que

incluya otros periodos, la operacin clculo de intereses del objeto

tendr que invocarse a si misma varias veces. Para representar esto en UML, dibujaremos una flecha de mensaje fuera de la activacin, y un pequeo rectngulo encima de la activacin.

EJEMPLO

VISTA DE DESPLIEGUE
En esta vista se muestra el sistema desde la perspectiva de un

programador y se ocupa de la gestin del software; o en otras

palabras, se va a mostrar como esta dividido el sistema software en componentes y las dependencias que hay entre esos componentes. Para completar la documentacin de esta vista se pueden incluir los diagramas de componentes y de paquetes de UML.

DIAGRAMA DE COMPONENTES
Un componente es una parte fsica y reemplazable de un sistema, conforma
con un conjunto de interfaces y realiza esas interfaces. Grficamente en UML:

Un componente debe tener un nombre: simple, ej. cliente.java o de camino, cuando est incluido en un paquete. ej. system::dialog.dll Un componente puede contener adornos, valores etiquetados e informacin adicional. Ej. referencia a las interfaces que realiza.

Un componente posee caractersticas similares a una clase: tiene nombre, realiza interfaces, puede participar de relaciones, puede tener instancias, puede participar en interacciones.

Porqu se diferencian?
Un componente representa un elemento fsico (bits). Una clase es una abstraccin lgica.

El componente se puede representar en nodos fsicos, la clase no.

Las operaciones de un componente solo se alcanzan a travs de interfaces. Las de una clase podran ser accesibles directamente.

Una interfaz contiene una coleccin de operaciones y se utiliza para especificar los servicios de una clase o de un componente. Una interfaz se conecta al componente que la implementa a travs de una relacin de realizacin, y al componente que utiliza sus servicios con una dependencia.

Grficamente:

TIPOS DE COMPONENTES
Componentes de despliegue: necesarios y suficientes para formar un sistema ejecutable. Por ejemplo: bibliotecas dinmicas (dll), ejecutables (exe). Componentes productos de trabajo: surgen durante el proceso de desarrollo y quedan al final del mismo. Por ejemplo: buscarCliente.jar, cliente.db. Componentes de ejecucin: se crean como consecuencia de un sistema en ejecucin. Por ejemplo: objetos que se instancian a partir de una dll.

DIAGRAMAS DE PAQETS
Un paquete es un mecanismo utilizado para agrupar elementos de UML Permite organizar los elementos modelados con UML,facilitando de sta forma el manejo de los modelos de un sistema complejo Define un espacio de nombres: Dos elementos de UML pueden tener el mismo nombre, con tal y estn en paquetes distintos

En este sentido, son similares a los namespaces en C++ o a los

paquetes en Java

Permiten dividir un modelo para agrupar y encapsular sus elementos en unidades lgicas individuales En general, pueden tener una interfaz (mtodos de clases e interfaces exportadas) y una realizacin de stas interfaces (clases internas que

implementan dichas interfaces)

Se pueden utilizar para plantear la arquitectura del sistema a nivel macro

VISTA DE PROCESOS
En esta vista se muestran los procesos que hay en el sistema y la forma en la que se comunican estos procesos; es decir, se representa desde la perspectiva de un integrador de sistemas, el flujo de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. Para completar la documentacin de esta vista se puede incluir el diagrama de actividad de UML.

DIAGRAMA DE ACTIVIDAD
En UML un diagrama de actividades se usa para mostrar la secuencia de
actividades. Los diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos tambin pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la ejecucin de algunas actividades. Los Diagramas de Actividades son tiles para el Modelado de Negocios donde se usan para detallar el proceso involucrado en las actividades de negocio.

Un ejemplo de un diagrama de actividades se muestra a continuacin

ELEMENTOS
Actividades: Una actividad es la especificacin de una secuencia parametrizada de comportamiento. Una actividad muestra un rectngulo con las puntas redondeadas adjuntando todas las acciones, flujos de control y otros elementos que constituyen la actividad.

Acciones: Una accin representa un solo paso dentro de una actividad. Las

acciones se denotan por rectngulos con las puntas redondeadas.

Restricciones de Accin: Las restricciones se pueden adjuntar a una accin. El siguiente diagrama muestra una accin con pre y post condiciones locales.

Flujo de Control: Un flujo de control muestra el flujo de control de una accin a otra. Su notacin es una lnea con una punta de flecha.

Nodo Inicial Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a continuacin.

Nodo Final: Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo final de actividad se describe como un crculo con un punto dentro del mismo.

VISTA FISICA
En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los componentes fsicos del sistema as como las conexiones fsicas entre esos componentes que conforman la solucin (incluyendo los servicios). Para completar la documentacin de esta vista se puede incluir el diagrama de despliegue de UML.

DIAGRAMA DE DESPLIEGUE
Los Diagramas de Despliegue muestran las relaciones fsicas de los

distintos nodos que componen un sistema y el reparto de los

componentes sobre dichos nodos. La vista de despliegue representa la disposicin de las instancias de componentes de ejecucin en instancias de nodos conectados por enlaces de comunicacin. Un nodo es un recurso de ejecucin tal como un computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria

Dependencias.-

Un nodo es un objeto fsico en tiempo de ejecucin que representa un recurso

computacional, generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o tipos de nodos que se representa como un cubo 3D en los diagramas de implementacin.

Las instancias de componentes de software muestran unidades de software en tiempo de

ejecucin y generalmente ayudan a identificar sus dependencias y su localizacin en

nodos. Pueden mostrar tambin qu interfaces implementan y qu objetos contienen. Su representacin es un rectngulo atravesado por una elipse y dos rectngulos ms pequeos.

Instancia de Nodo Una instancia de nodo se puede mostrar en un diagrama. Una instancia se puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de los dos puntos. El siguiente diagrama muestra una instancia nombrada de una computadora. Estereotipo de Nodo Un nmero de estereotipos estndar se proveen para los nodos, nombrados cdrom, cdrom, computer, disk array, pc, pc client, pc server, secure, server, storage, unix server, user pc. Estos mostrarn un icono apropiado en la esquina derecha arriba del smbolo nodo. del artefacto, el estereotipo artifact y

un icono de documento, como a continuacin.

Artefacto Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (e.g. modelos de Casos de Uso, modelos de Diseo, etc.), archivos fuente, ejecutables, documentos de diseo, reportes de prueba, prototipos, manuales de usuario y ms. Un artefacto se denota por un rectngulo mostrando el nombre del artefacto, el estereotipo artifact y un icono de documento, como a continuacin.

Asociacin En el contexto del diagrama de despliegue, una asociacin representa una ruta de comunicacin entre los nodos. El siguiente diagrama muestra un diagrama de despliegue para una red, mostrando los protocolos de red como estereotipos y tambin mostrando

multiplicidades en los extremos de la asociacin.

VISTA +1
Esta vista va a ser representada por los casos de uso software y va a tener la funcin de unir y relacionar las otras 4 vistas, esto quiere decir que desde un caso de uso podemos ver como se van ligando las otras 4 vistas, con lo que tendremos una trazabilidad de componentes, clases, equipos, paquetes, etc., para realizar cada caso de uso. Para completar la documentacin de esta vista se pueden incluir el

diagramas de casos de uso de UML.

DIAGRAMA DE CASO DE USO

Un modelo de casos de uso se describe en UML mediante un diagrama de casos de uso (use-case diagram) y puede dividirse en varios diagramas de casos de uso. Un diagrama de casos de uso contiene elementos del modelo para el sistema, los

actores y los casos de uso, y muestra las diferentes relaciones entre estos elementos.
Estos diagramas dan una visin del modelo, pero las descripciones reales de los casos de uso suelen ser textuales, usando el lenguaje y terminologa del cliente/usuario.

Un sistema en un diagrama de casos de uso se describe mediante un rectngulo que

contiene el nombre del sistema y los smbolos de los casos de uso en el sistema.

ACTORES
Un actor es alguien o algo que interacta con el sistema, pero que es
externo al sistema. El actor enva o recibe mensajes a y desde el sistema, o intercambia informacin con el sistema. Un caso de uso siempre es iniciado por un actor que le enva un mensaje o estmulo (stimulus). Los actores llevan a cabo casos de uso. Cuando un caso de uso se realiza, el caso de uso podra enviar

mensajes a uno o ms actores. Estos mensajes tambin puede ir a

otros actores adems del que inici el caso de uso.

Un actor es una clase, no una instancia. El actor representa un papel, no a un usuario individual del sistema. Por ejemplo, una persona puede ser diferentes actores en el sistema, dependiendo de su papel en ste. Los papeles que una persona puede tener en un sistema pueden estar restringidos. Por ejemplo, puede estar prohibido que la misma persona registre

una factura y la apruebe.

Un actor tiene un nombre que debera reflejar el papel del actor.

Para identificar los actores, se establecen las entidades interesadas en usar e interactuar con el sistema: Los usuarios de la funcionalidad principal del sistema (actores primarios). Por ejemplo, en un sistema de seguros, un actor primario podra ser uno que maneja el registro y administracin de los seguros. Los que mantienen, administran y tienen el sistema en funcionamiento (actores secundarios). Un ejemplo de actor secundario podra ser una tarjeta que usa las funciones del sistema para recuperar estadsticas sobre los negocios o la compaa. Los dispositivos hardware que necesita manejar el sistema. Los otros sistemas con que necesita interactuar, que incluyen otros sistemas computadores, as como otras

aplicaciones en el computador en que operar este sistema.

Los que tienen inters en los resultados que produce el sistema. Un actor debe tener alguna asociacin con uno o ms casos de uso. Aunque un actor podra no iniciar un caso de uso, ese actor se comunicar con uno en algn punto. Un actor activo inicia un caso de uso, mientras que un actor pasivo nunca inicia un caso de uso, sino que

slo participa en uno o ms casos de uso.

RELACIONES ENTRE ACTORES

Los actores en UML son clases con el estereotipo <<actor>> y tienen un

estereotipo icono estndar. El nombre de la clase es el nombre del actor.

Una clase actor puede tener atributos y comportamiento. Los actores pueden tener las mismas relaciones que las clases. Cuando varios actores, como parte de sus papeles, tambin representan un papel ms generalizado, se describe mediante una relacin de generalizacin. El comportamiento del papel general se describe en una superclase actor. Los actores especializados heredan el comportamiento de la superclase y extienden

ese comportamiento de algn modo.

Un caso de uso se representa en UML mediante una elipse que contiene el nombre del caso de uso, o con el nombre del caso de uso debajo. Los casos de uso se conectan a los actores mediante asociaciones, denominadas lneas de comunicacin (communication lines). Las asociaciones muestran con qu actores se comunica el caso de uso, incluyendo el actor que inicia la ejecucin del caso de uso. La asociacin normalmente es una relacin uno a uno sin direccin. Esto

significa que una instancia de actor se comunica con una instancia de caso de
uso y que pueden comunicarse en ambas direcciones.

Un caso de uso es un tipo de clasificador que describe la funcionalidad como un todo, incluyendo posibles alternativas, errores y excepciones que puedan ocurrir durante la ejecucin del caso de uso en colaboracin con uno o ms actores. Los casos de uso se determinan precisando actor por actor: Las funciones que requiere el actor del sistema, si el actor necesita leer, crear, destruir, modificar o almacenar alguna clase de informacin en el sistema. Si hay que informar al actor de los eventos del sistema o el actor necesita notificar algo al sistema y qu representan esos eventos en trminos de funcionalidad. Si se podra simplificar o hacer ms eficiente el trabajo del actor aadiendo nuevas funciones del sistema. Las entradas/salidas que necesita el sistema. Los principales problemas de la implementacin actual del sistema.