Orientado a Objetos usando UML

Orientado a Objetos usando UML
Modelado de Software Orientado a Objetos usando UML Dr. Pedro Mejia Alvarez Departamento de Computacion CINVESTAV-IPN

Contenido Fundamentos del Modelado OO Requisitos del software
Interacción entre objetos Clases y relaciones entre clases Diagramas de UML

Diagramas de UML Los diagramas expresan gráficamente partes de un modelo Use Case Diagrams Diagramas de Casos de Uso Scenario Colaboración State Componentes Component Distribución Objetos Estados Secuencia Clases Actividad Modelos

Diagrama de Clases El Diagrama de Clases es el diagrama principal para el análisis y diseño del sistema Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia La definición de clase incluye definiciones para atributos y operaciones El modelo de casos de uso debería aportar información para establecer las clases, objetos, atributos y operaciones

Objetos Objeto = unidad atómica que encapsula estado y comportamiento
La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento La cohesion es la medida de la cercania de las relaciones entre sus componentes. El acoplamiento es una medida de la fuerza de las interconecciones entre los componentes en el diseño. Un objeto puede caracterizar una entidad física (coche) o abstracta (ecuación matemática)

Clases y Objetos En UML, para distinguir una clase y una instancia de la clase (un objeto) se representa por un rectángulo con un nombre subrayado Objeto = Identidad + Estado + Comportamiento El estado está representado por los valores de los atributos los cuales tienen una visibilidad. Un atributo toma un valor en un dominio concreto.

Clases y objetos La clase define el ámbito de definición de un conjunto de objetos Cada objeto pertenece a una clase Los objetos se crean por instanciación de las clases Para distinguir entre una clase (el tipo) y un objeto (una instancia del tipo), un objeto se muestra subrayado. Un objeto puede representarse como anObject, anotherObject:Class, o :Class. Las clases y los objetos forman parte de varios diagramas UML.

Clases: Notación Gráfica
Cada clase se representa en un rectángulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase - Un atributo es semánticamente equivalente a una composición (composite aggreation). La sintaxis por defecto para los atributos es: visibilidad nombre [multiplicidad] : tipo = valor-inicial {propiedades} - tipo es una especificación dependiente del lenguaje de implementación - Para indicar que un atributo es constante se puede poner la propiedad frozen - Ejemplos usando multiplicidad: colores [3]: Color puntos [2..*]: Punto nombre [0..1]: String - Un atributo de clase (del ámbito de clase y no de objeto) se indica subrayándolo

Clases: Encapsulación
La encapsulación permite la cohesion y presenta dos ventajas básicas: Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye Favorece la modularidad y el mantenimiento Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos

Los niveles de encapsulación están heredados de los niveles de C++, y explican si estos son visibles desde el exterior de la clase: (-) Privado : es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++) (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)

Ejemplo: Reglas de visibilidad + Atributo público : Integer # Atributo protegido : Integer - Atributo privado : Integer + "Operación pública"() # "Operación protegida"() - "Operación privada"()

Diagramas de Clases Asociación Generalización/especialización
Un diagrama de clases describe los tipos de objetos en el sistema y los distintos tipos de relaciones estáticas que existen entre ellos. Existen cuatro relaciones: Asociación Generalización/especialización Agregación/composición Dependencia

Asociación Permite asociar objetos.
La asociacion se representa mediante una línea que une las cajas de los dos objetos.

Asociación Una asociación se representa mediante una línea que une las cajas de las dos clases. Esta asociacion tiene un nombre y opcionalmente una pequeña cabeza de flecha que indica la dirección en la cual se debe leer el nombre de la asociación. En cada extremo de la línea se sitúa la multiplicidad o cuantas instancias de una clase se relacionan con una instancia de la otra. Se puede usar una flecha de línea (“stick arrow”) para representar la dirección de la navegabilidad.

Asociación Ejemplo:

Asociación Especificación de multiplicidad (mínima...máxima)
1 Uno y sólo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) * Cero o muchos 0..* Cero o muchos 1..* Uno o muchos (al menos uno) La multiplicidad mínima >= 1 establece una restricción de existencia

Generalización Esta es una relación de tipo: es-un.
Una generalización se representa como una flecha que une a las subclases (hijos) a la superclase (padre), con la flecha tocando la caja de la superclase.

Generalización Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases Se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general

... Generalización Nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas La Generalización y Especialización son equivalentes en cuanto al resultado: la jerarquía y herencia establecidas Generalización y Especialización no son operaciones reflexivas ni simétricas pero sí transitivas

Relacion de Dependencia entre Clases
Se usa para mostrar relaciones entre paquetes (grupos de clases) Cliente Proveedor

Agregacion de Objetos En este modelo se muestra como las clases pueden estar compuestas por otras clases. Existe la relacion de agregacion y la de composicion. Son similares a los modelos de entidad-relacion.

Agregacion de Objetos Estas son relaciones todo/parte.
La relación de composición (representada con un diamante relleno) es la forma más fuerte de relación todo/parte que la relación de agregación (mostrada por un diamante vacío). El diamante toca la caja de clase de la clase (todo) compuesta/agregada.

Ejemplos Son parte de Esta compuesta de

Diagrama de Casos de Uso
Es una técnica para capturar información sobre los servicios que un sistema proporciona a su entorno, desde el punto de vista del usuario. Es una técnica para captura y especificación de requisitos Cada Caso de Uso puede estar definido por: secuencia de pasos (flujo de eventos) ejecutados dentro del caso de uso texto que lo describe precondiciones y postcondiciones para que el caso de uso comience o termine mezclando las anteriores

Casos de Uso Los Casos de Uso describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación Es posible identificarlos a partir de los puntos de vista (Metod VORD de Sommerville). Algunas similitudes y diferencias entre DFDs y D. de Casos de Uso: Un caso de uso es una función (servicio o transacción) atómica ofrecida por el sistema al entorno (actores), mientras que un proceso de un DFD puede ser detallado en un DFD hijo. Así, el concepto de “explosión de proceso” sólo se aplica a los DFDs. Aunque en cierta forma con relaciones de inclusión entre casos de uso (que se explican más adelante) puede mostrarse la factorización de un caso de uso, esto no llega a ser equivalente a explosión de proceso. Aunque un caso de uso y un proceso modelan una pieza de funcionalidad del sistema su especificación es diferente. En un caso de uso interesa expresar la funcionalidad mediante la interacción (pasos de comunicación) actor(es) – sistema. En un proceso la funcionalidad se expresa mediante la transformación que se hace de los flujos de entrada para producir flujos de salida. Un caso de uso en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visión externa del sistema. La excepción a lo anterior podría producirse al factorizar funcionalmente un caso de uso para establecer una relación de inclusión (que se explica más adelante). Un DFD, según sea el nivel de detalle, puede mostrar descomposición funcional interna del sistema. La diferencia entre Captura de Requisitos y Análisis radica esencialmente en el grado de detalle que se obtiene respecto del particionamiento del problema (funcional y de datos). La Captura de Requisitos ofrece un particionamiento en el contexto del usuario y adecuado para su comprensión. El Análisis provee un particionamiento que pueda ser utilizado como entrada para el Diseño del Sistema. Así, se puede afirmar que los D. de Casos de Uso son una herramienta exclusivamente de Captura de Requisitos mientras que los DFD podrían utilizarse en ambas actividades. En captura de requisitos para un DFD una entidad externa equivale a un actor, un almacén único y global evita entrar en análisis de datos y los procesos establecidos sólo hasta el nivel de transacciones externas se corresponderían con casos de uso. Las relaciones de extensión y de generalización entre casos de uso no tienen correspondencias en los DFDs. ...

Casos de Uso Ejemplo:

Casos de Uso Actores: Principales: personas que usan el sistema Secundarios: personas que mantienen o administran el sistema Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados Otros sistemas: sistemas con los que el sistema interactúa La misma persona física puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeñado

Casos de Uso Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario (Metodo VORD). Un escenario es una instancia de un caso de uso Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso

Casos de Uso: Ejemplo Passajero Usado durante para la obtencion y analisis de los requerimientos para representar el comportamiento de sistema, visible desde el exterior. Comprar boleto Un Actor representa un rol, o un tipo de usuario en el sistema Un caso de uso representa un tipo de funcionalidad del sistema

Ejemplo: Actores Un actor es un modelo que permite representar una entidad externa que interactua (comunica) con el sistema: Usuario Sistema externo (otro sistema) Ambiente fisico Un actor tiene un nombre unico y una descripcion opcional. Ejemplos: Pasajero: Una persona en el tren Satelite GPS: Sistema externo que provee coordenadas de ubicacion. Pasajeros Descripcion opcional Nombre

Caso de uso • Los casos de uso pueden ser descritos textualmente, describiendo el flujo de eventos entre el actor y el sistema. • La descripcion textual del caso de uso incluye 6 partes: Nombre unico Actores participantes Condiciones de entrada Condiciones de Salida Flujo de eventos Requisitos especiales Compra boleto

Ejemplo de caso de uso textual
5. Flujo de eventos: 1. El pasajero selecciona la zona de destino da donde quiere viajar 2. El vendedor de boletos despliega el monto del boleto a ese destino 3. El pasajero entrega al menos el monto de dinero requerido 4. El vendedor regresa el cambio, en caso de que sea necesario 5. El vendedor entrega el boleto 6. Requerimientos especiales: Especificar el tipo de transporte: Tren o autobus. Pasajero Compra boleto 1. Nombre: Compra boleto 2. Actor: Pasajero 3. Condicion de entrada: El pasajero se dirige al la ventanilla de boletos El pasajero cuenta con suficiente dinero para comprar el boleto 4. Condicion de salida: EL pasajero compro el boleto

Casos de Uso: Relaciones
UML define cuatro tipos de relación en los Diagramas de Casos de Uso: Comunicación Inclusion Extension Herencia

Casos de Uso: Relaciones
Pasajero Comunicación: permite comunicar al actor con su caso de uso. Compra multiples boletos Compra un boleto <<includes>> <<includes>> Recoge el dinero No cambio <<extends>> Cambio de moneda Cancela

… Casos de Uso: Relaciones
Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino. La relación <<include>> pretende evitar duplicación de interacciones en distintos casos de uso Para la explicación de las relaciones entre casos de uso se han identificado como “caso de uso origen” y “caso de uso destino” sólo para indicar el sentido del símbolo (flecha de generalización).

Relacion <<includes>>
Pasajero La relacion <<includes>> representa una funcionalidad comun necesaria en mas de un caso de uso La funcionalidad de <<includes>> puede reutilizarse La direcion de la relacion <<includes>> es hacia el caso de uso (de forma distinta que la relacion <<extends>>). Compra multiples boletos Compra un boleto <<includes>> <<includes>> Recoge el dinero No cambio <<extends>> Cambio de moneda Cancela

Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino La relación <<extends>> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso. Las relaciones <<include>> y <<extend>> corresponden ambas a factorizaciones del comportamiento de un caso de uso, es decir, el caso de uso incluido y el caso de uso que extiende representan un fragmento de interacción de otro caso de uso. Sin embargo, la intensión es diferente; la relación <<include>> pretende evitar duplicación de interacciones en distintos casos de uso, la relación <<extends>> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso.

Relacion <<extends>>
Pasajero Compra boleto La relacion <<extends>> modela casos exceptional, o casos de uso auto invocados EL flujo de eventos excepcionales pueden detallarse para claridad del caso de uso La direccion de la relacion <<extends>> es hacia el caso de uso Los casos de uso representando flujos excepcionales pueden extender mas de un caso de uso. <<extends>> <<extends>> <<extends>> <<extends>> Fuera de servicio Tiempo agotado Cancela No hay cambio

Otro ejemplo <<include>> y <<extend>>:

Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía En el documento UML no se proporcionan reglas específicas respecto de las modificaciones y ampliaciones posibles en el caso de uso hijo. Lo intuitivo es pensar que un caso de uso obtenido por especialización tiene en principio los mismos pasos de interacción que el caso de uso padre pero que puede insertar nuevos y/o reescribir los pasos heredados.

Casos de Uso: Construcción
Un caso de uso debe ser simple, inteligible, claro y conciso Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave: ¿cuáles son las tareas del actor? ¿qué información crea, guarda, modifica, destruye o lee el actor? ¿debe el actor notificar al sistema los cambios externos? ¿debe el sistema informar al actor de los cambios internos?

… Casos de Uso: Construcción
La descripción del Caso de Uso comprende: el inicio: cuándo y qué actor lo produce? el fin: cuándo se produce y qué valor devuelve? la interacción actor-caso de uso: qué mensajes intercambian ambos? objetivo del caso de uso: ¿qué lleva a cabo o intenta? cronología y origen de las interacciones repeticiones de comportamiento: ¿qué operaciones son iteradas? situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

CU-<id-requisito> Nombre <nombre del requisito funcional>
Identificador CU-<id-requisito> Nombre <nombre del requisito funcional> Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>} Precondición <precondición del caso de uso> Secuencia Normal Paso Acción 1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso CU-x> 2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso CU-x> … Postcondición <postcondición del caso de uso> Excepciones Si <condición de excepción>,{el <actor> , el sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso CU-x>, a continuación este caso de uso {continua, aborta} Rendimiento Cota de tiempo n segundos Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales> Esta es una posible plantilla para utilizar al especificar un caso de uso (adaptada desde )

Diagrama de Secuencia Describe el comportamiento dinamico del los objetos en el sistema Los Diagramas de Secuencia y de Colaboración son usados para describir gráficamente un caso de uso o un escenario

Diagrama de Secuencia Actor Mensajes Objeto Lifeline return Activacion
:Watch :WatchUser Actor Mensajes Objeto Lifeline :LCDDisplay :Time pressButton1() blinkHours() pressButton1() blinkMinutes() return pressButton2() incrementMinutes() refresh() pressButton1and2() commitNewTime() stopBlinking() Activacion

Diagrama de Secuencia

Diagrama de Secuencia El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones Muestra la secuencia de mensajes entre objetos durante un escenario concreto Cada objeto viene dado por una barra vertical El tiempo transcurre de arriba abajo Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua

Diagrama de Secuencia Usada durante el analisis
Pasajero Usada durante el analisis Refina la descripcion de casos de uso Util para descubrir objetos Usada durante el diseño Para refinar interfaces de subsistemas Las instancias se representan mediantes rectangulos. Actores mediantes figuras Los flujos de control mediante lineas punteadas Los Mensajes mediante flechas Las activaciones mediante rectangulos pequeños. Maquina de Boletos seleccionadestino() retiracambio() Retiraboleto() insertamonedas() zone2price Selec-destino() insertamoneda() retiracambio() retiraboleto() Maquina de Boletos

Diagrama de secuencia Lifeline Activacion Mensaje:Flujo de control
Pasajero Maquina de Boletos seleccionadestino() retiracambio() Retiraboleto() insertamonedas() Lifeline Activacion Mensaje:Flujo de control

Lifeline y Especificacion de la ejecucion
El lifeline (linea de vida) representa una participacion de un objeto particular en la interaccion Consiste de un rectangulo seguido de una linea vertical (que puede ser punteada) que representa el tiempo de vida del participante La especificacion de la execucion especifica el comportamiento o la interaccion con la linea de vida. Se representa mediante un rectangulo delgado vertical.

Mensajes Define una comunicacion particular entre los “lifelines” de una interaccion. Ejemplos de comunicacion Enviar una señal Invocar una operacion Crear o destruir una instancia Es necesario especificar quien envia y quien recibe (sender y receiver) Se muestran como una linea que se enviar de enviador al receptor Distintas formas de flechas reflejan las propiedades el mensaje Creation Message Synchronous/Asynchronous Message

Tipos de mensajes Asincronos Sincronos Llamada(Call) y creacion
de un objeto Reply Lost Found Asincrono

Etiquetas de las flechas

Tipos de flechas

Flujo de Datos Flujo de Datos
Pasajero Selecciona destino() Botondestinoo TarifasS Diespiliegue lookupPrice(selection) Despliegaprecio(precio) precio Flujo de Datos Los diagramas de secuencia tambien pueden modelar flujo de datos El origen de una flecha indica la activacion que envia el mensaje Las flechas horizontales punteadas indican flujo de datos.

Iteracion y Condicion * Iteracion Condicion
Pasajero Procesador de Cambios Dispensa Moneda Identif.demonedas Diespliegue * insertacambio(moneda) checamoneda(moneda) precio Iteracion displiegaprecio(precio) Condicion [Monto<0] returnCambio(-cambio) La iteracion se denota por un simbolo * seguido de un nombre de mensaje La condicion se denota mediante una expresion booleana en [] antes del nombre del mensaje

Creacion y destruccion
Pasajero Creacion del boleto Proc.de Cambios BoletoT creaboletoT(seleccion) print() Destruccion del boleto free() La creacion se denota mediante un mensaje sobre una flecha apuntando al objeto La destruccion se denota mediante una X que marca el fin de la activacion

Propiedades del diagrama de secuencia
Representa comportamiento en terminos de interacciones Util para identificar o encontrar objetos Complemento al diagrama de flujo de datos y al diagrama de clases.

Diagrama de Secuencia(ejemplo)

Diagrama de Colaboración
Modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección Ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Muestran una vista dinamica del sistema. El diagrama de secuencia muestra el ordenamiento en el tiempo de los mensajes mientras que el diagrama de colaboracion expone la estructura organizacional de los mensajes. Los diagramas de colaboracion muestran el flujo de mensajes entre objetos en un sistema, y tambien exponen las relaciones (asociaciones) entre sus clases. Los diagramas de colaboracion son tambien diagramas de interaccion. Manejan la misma informacion que los diagramas de secuencia pero se enfocan mas en los roles de los objetos que en los tiempos en que los mensajes son enviados. El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Notacion del Diagrama de Colaboración
Representa una colaboracion o una interaccion. Colaboracion: conjunto de objetos y su interaccion dentro de un contexto. Interaccion: conjunto de mensajes intercambiados en una colaboracion para producir un resultado deseado. Objetos: Rectangulos conteniendo una firma del objeto. Firma del objeto: nombre del objeto : clase del objeto. nombre de la clase (obligatoria): comienza con letra mayuscula. Objetos conectados mediante lineas. Puede existir uno o mas actores. Mensajes: Se etiquetan como las llamadas a funciones en Java. Seguidas de brackets redondeados, pueden tener parametros y valores de retorno. Incluyen una flecha que indica direccion. Los mensajes se numeran, comenzando con el numero 1. El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Notacion del Diagrama de Colaboración
Firma del mensaje Guardia. condicion aplicada al mensaje en brackets redondos al principio del mensaje. Numeros secuenciales. numeros separados por puntos, con terminacion en coma. Valor de retorno nombre seguido de “:=“ Nombre de la operacion Lista de argumentos. nombres separados por comas, dentro de brackets redondeados. El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Tipos de Mensajes Simple Indican flujo de control – el que envia espera hasta que el receptor procesa el mensaje. default: mostrada mediante una flecha: Sincrono. indica flujo de control anidado. usado para asegurar que el estado no pueda ser interrumpido por factores externos. mostrado mediante una flecha llena. Asincrono muestra una señal de un objeto a otro. se indica mediante una flecha a la mitad El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

1. Trazado del diagrama: a nivel de instancia y especificacion. 2. Mensajes. 3. Conectores (Links) El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Diagramas a nivel de instancia: usuados para explorar las caracteristicas del diseño de los objetos. Estos diagramas muestran interacciones entre objetos (instancias). El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Diagramas a nivel de especificacion: se usan para analizar y explorar los roles de las clases en el sistema. El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Mensajes en el Diagrama de Colaboración
sequenceNumber loopIndicator: returnValue := methodName(parameters) El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Ligas (links) en el Diagrama de Colaboración
El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema Las lineas o ligas entre las clases representan instancias de las Relaciones, que pueden incluir, asociaciones, agregaciones, composiciones y dependencias.

Diagrama de Estados Modela el comportamiento de una parte del sistema

Diagrama de UML: Statechart
Estado inicial Evento button1&2Pressed button1Pressed button2Pressed Increment Minutes Hours Blink Seconds Stop Blinking Transicion Estado Represent behavior of single objects with interesting dynamic behavior in terms of states and transitions The behavior of the single object Watch, for example, has several different interesting states, BlinkHours, BlinkMinutes, BlinkSeconds, Because in each state pressing a button or two yields a different result. Estado final

Diagrama de Actividades
Es un caso especial de un diagrama de state-chart en donde los estados son actividades (“funciones”). Es util para dibujar los flujos de trabajo (workflows) en un sistema Puede especificar: (1)El comportamiento de los objetos de una clase (2) Las actividades del sistema (3) La lógica de una operación (método) (4) Parte o toda la descripción de un Caso de uso (5) La descripción de un Flujo de Trabajo

Nodos de actividades y flechas
Un diagrama de actividad consiste de nodos y flechas (edges) Hay 3 tipos de nodos de actividades Nodos de control Nodos executables: acciones Nodos de objetos Una flecha (edge) es una coneccion directa entre nodos Control de flujo Flujo de objetos

Notacion del Diagrama Fork node Join node Merge node Initial node
Control flow Final node Initial Node (Control) Decision Node Action Object node Object flow

Permite modelar desiciones
Decision

Modelacion de concurrencia
Sincronizacion de multiples actividades Separacion de el flujo de control en multiples threads Splitting Synchronization

Agrupamiento de actividades
Las actividades pueden agruparse para denotar el objeto o el subsistema que implementa las actividades Dispatcher Allocate Resources Open Coordinate Archive Incident Resources Incident FieldOfficer Document Incident

Diagrama de Componentes
Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones Permite modelar la estructura del software y la dependencia entre componentes, en donde un componente es un grupo de clases que trabajan estrechamente. Los componentes pueden corresponder código fuente, binario o ejecutable. Una relación de dependencia indica que un componente utiliza otro, por lo cual depende de él

Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente

Diagrama de Despliegue
Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos

Modela la distribución en tiempo de ejecución de los elementos de procesamiento y componentes de software, junto a los procesos y objetos asociados Se modelan los nodos y la comunicación entre ellos Cada nodo puede contiene instancias de componentes

Los estereotipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse

Ejemplo de conexión entre nodos: <<Cliente>> <<Servidor>> Terminal Punto de Venta <<TCP/IP>> Base de Datos <<RDSI>> <<RDSI>> Podemos distinguir tipos de nodos y conexiones por estereotipado Control

… Diagramas de Despliegue
Ejemplo:

… Diagramas de Despliegue
Ejemplo: Component Diagram: videoStoreServer Client videoStoreApplication DBServer

Diagrama de Despliegue en Rational
Servidor Central Punto de Venta Terminal de Consulta

Paquetes en UML Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado Se representan gráficamente como:

… Paquetes en UML Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema) Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está definido en) sólo un paquete Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes

… Paquetes en UML Todos los elementos no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa El operador “::” permite designar una clase definida en un contexto distinto del actual

...Paquetes en Rational Rose
Customers Banking

… Paquetes en UML

Los modelos se usan para describir al sistema de software
Modelo del sistema: Modelo de objetos + modelo funcional + modelo dinamico Modelo de objetos: Cual es la estructura del sistema? Cuales son los objetos y cual es su relacion? Notacion UML: Diagramas de clases Modelo funcional: Cuales son las funciones del sistema? Como fluyen los datos en el sistema? Notacion UML: Diagramas de casos de uso Modelo dinamico: Como reaccciona el sistema a eventos externos (e internos) y cual es el flujo de eventos? Notacion UML: Diagramas de secuencia, state charts y de actividad.

Modos de utilizacion de UML
Ingenieria hacia adelante(Forward Engineering) Se comienza con un modelo antes de producir codigo Ingenieria en reversa (Reverse Engineering) Se crea un modelo a partir de algun codigo Proyectos de interfaces o re-ingenieria Ingenieria ciclica (Roundtrip Engineering) Se mueve constantemente entre ingenieria hacia adelante y en reversa. Util en proyectos que utilizan el modelo de procesos evolutivo, o cuando los requerimientos cambian frecuentemente. Se asume que a partir de UML se puede producir codigo, pero en donde se ubica UML dentro del proceso de Diseño ?.

Proceso de Desarrollo Unificado basado en UML
Propuesta de Rational Unified Process (RUP) M. de Casos de Uso del Negocio (Business Use-Case Model) M. de Objetos del Negocio (Business Object Model) M. de Casos de Uso (Use-Case Model) M. de Análisis (Analysis Model) M. de Diseño (Design Model) M. de Despliegue (Deployment Model) M. de Datos (Data Model) M. de Implementación (Implementation Model) M. de Pruebas (Test Model)

Resumen UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos El modelo de proceso RUP utiliza UML para el modelado.

Tendencias Nuevas versiones de UML, uff!
Extensiones de UML (SysML, Generación automática de código a partir de modelos Model-Driven Development (MDD), Model-Driven Architecture (MDA), Compiladores de Modelos Round-trip engineering. Convergencia entre herramientas CASE e IDEs Extendiendo UML mediante Profiles ( Modelado y generación de código en dominios específicos (más allá de UML) Eclipse Modeling Framework (EMF, download.eclipse.org/tools/emf/scripts/home.php) Microsoft Tools for Domain Specific Languagues Domain-Specific Modeling (DSM, Meta CASE Tools ( OO usando BD relacionales En el 2002 IBM compró Rational Software por US$ y Borland pagó US$ 185 por TogetherSoft. Se rumoreaba que Microsoft estaba interesada en adquirir ambas.

Diagramas en UML 2.0

Bibliografía Adicional
UML Meta-links Martin Fowler, autor de “UML Destilled” (“UML Gota a Gota”) Herramientas CASE Herramientas basadas en UML International Council in SE (INCOSE) Otras Revista IEEE Software, Conferencias: OOPSLA, ECOOP Patrones Foro UML en yahoo:

Orientado a Objetos usando UML

Presentaciones similares

Presentación del tema: "Orientado a Objetos usando UML"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Orientado a Objetos usando UML

Presentaciones similares

Presentación del tema: "Orientado a Objetos usando UML"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback