Introducción a UML

David PineloDavid Pinelo

Marzo – Abril de 2009Marzo – Abril de 2009

Índice

• Introducción a UML– Vista general

– Arquitectura

– Bloques de construcción

• Modelado Estructural– Diagramas de clases

– Diagramas de objetos

• Modelado del comportamiento– Diagramas de interacción

• Diagramas de secuencia

• Diagramas de colaboración

– Casos de uso• Diagramas de casos de uso

• Diagramas de actividades

• Diagramas de despliegue

• Diagramas de paquetes

• Diagramas de tiempos

• Nuevos diagramas en UML 2.0

• Herramientas CASE

• XMI

Introducción. Objetivos

• Se presentará la revision 2 del OMG (Object Management Group) de noviembre de 2007.

• UML: Unified Modeling Language• El objetivo de UML es “proporcionar a

desarrolladores de software, arquitectos de sistemas e ingenieros de software de herramientas para el análisis, diseño e implementación de sistemas basados en software, así como modelar procesos de negocio y similares

• El modelado captura las partes esenciales del sistema

Introducción. Objetivos (II)

• UML es un lenguaje con un alcance muy grande y que cubre diversos conjuntos de dominios arquitectónicos en el diseño de aplicaciones.

• Por ello, no todas sus capacidades de modelados son necesariamente útiles en todos los dominios o aplicaciones.

• UML permite seleccionar sólo aquellas partes del lenguaje que sean realmente útiles.

• “El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML” - Grady Booch

Modelado

• Busca representar los planos del software• El modelado es la espina dorsal del desarrollo de

software de calidad• Modelo: Simplificación de la realidad• UML busca

– Visualizar cómo es o queremos que sea un sistema– Especificar la estructura o el comportamiento de un

sistema– Proporcionar plantillas que nos guíen en la

construcción de un sistema– Documentar las decisiones que hemos adoptado

Modelado (II)

• Principios básicos del modelado– Seleccionar el modelo adecuado para cada

momento, y dependiendo de qué modelo se elija se obtendrán diferentes beneficios y diferentes costes

• El modelado orientado a objetos proporciona sistemas más flexibles y readaptables.

– Todo modelo puede ser expresado en base a diferentes niveles de precisión

– Obtener modelos que representen la realidad lo más claramente posible

– Un único modelo no es suficiente

UML. Qué proporciona

• Proporciona un vocabulario y las reglas para utilizarlo para así tener una representación conceptual y física de un sistema

• Utiliza gráficos y textos– Los modelos pueden ser interpretados por personas que

no participaron en su diseño, sin ninguna ambigüedad

UML. Vista generalBloques de construcción

Elementos

●Estructurales●Comportamiento●Agrupación●Anotación

Diagramas

●Clases●Objetos●Casos de Uso●Secuencia●Colaboración●Estados●Componente●Despliegue

Relaciones

●Dependencia●Asociación●Generalización●Realización

Colaboran

●Nombres●Alcance●Visibilidad●Integridad

Reglas

●Especificaciones●Adornos●Divisiones Comunes●Extensibilidad

Mecanismos

Afectan

Afectan

Actúan

UML. Diagramas

Diagramas

Diagramas deDespliegue

Diagramas decomportamiento

Diagramas deClases

Diagramas deObjetos

Diagramas deComponentes

Diagramas deEstructura Compuesta

Diagramas deEstructura

Diagramas dePaquetes

Diagramas deInteracción

Diagramas deActividad

Diagramas deCasos de uso

Diagramas deEstados

Diagramas deSecuencia

Diagramas deColaboración

DiagramaGlobal de

Interacción

Diagramas deTiempos

UML. Lo imprescindible de historia

• En 2000 se aprueba UML 1.4 que supone una revisión mayor. Es la “habitual” hoy día

• En 2007 se aprueba la revisión 2.0 que introducen bastantes novedades, que se están implantando hoy día

• Participantes

Rational Software(Grady Booch, Jim Rumbaugh yIvar Jacobson)Digital EquipmentHewlett-Packardi-Logix (David Harel)IBMICON Computing(Desmond D'Souza)Intellicorp and James

Martin & co. (James Odell)MCI SystemhouseMicrosoftObjecTimeOracle Corp.Platinium TechnologySterling SoftwareTaskonTexas InstrumentsUnisys

Bloques de construcción

– Clases

• Elementos estructurales

– Interfaz

– Colaboración

Cadena deresponsabilidad

– Casos de uso

Login de usuario

Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

Colección de operaciones que especifican un servicio de una determinada clase o componente.

Describe el comportamiento visible externamente de ese elemento. Puede mostrar el comportamiento completo o sólo una parte del mismo. No muestra su implementación

Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Tienen una dimensión tanto estructural como de comportamiento. Una misma clase puede participar en diferentes colaboraciones. Representan la implementación de patrones que forman un sistema.

Descripción de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de interés para un actor particular.

Se utiliza para organizar los aspectos del comportamiento en un modelo. Es realizado por una colaboración.

Bloques de construcción (II)• Elementos estructurales

– Clase Activa

– Componente

– Nodos

Servidor

Clase cuyos objetos tienen uno o más procesos o hilos de ejecución por lo y tanto pueden dar lugar a actividades de control.

Es igual que una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.

Parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto.

Representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones.

Elemento físico que existe en tiempo de ejecución y representa un recurso computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.

Bloques de construcción (III)• Elementos estructurales

– Interacción – Máquinas de estados

dibujar

Waiting

• Elementos de agrupación

– Paquete

• Elementos de anotación

Comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para conseguir un propósito específico.

Involucra otros muchos elementos, incluyendo mensajes, secuencias de acción (comportamiento invocado por un objeto) y enlaces (conexiones entre objetos)

Bloques de construcción (IV)• Relaciones

– Dependencia – Asociación

– Generalización – Realización

0..1 *

Es una relación semántica entre dos elementos en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semántica del otro elemento (elemento dependiente).

Relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación y representa una relación estructural entre un todo y sus partes.

Es una relación de especialización / generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre.

Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá.

Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan.

Arquitectura• Es el conjunto de

decisiones significativas sobre– La organización del

sistema– Elementos estructurales

y sus interfaces– Comportamiento– Composición de los

elementos estructurales y de comportamiento en subsistemas más grandes

– Estilo arquitectónico

Vista deDiseño

Vista deImplementación

Vista deprocesos

Vista dedespliegue

Vista de losCasos de Uso

• Vocabulario

• Funcionalidad

• Ensamblado del sistema

• Gestión de las configuraciones

• Funcionamiento

• Capacidad de crecimiento

• Rendimiento

• Topología del sistema

• Distribución

Modelado Estructural. Índice• Clases• Responsabilidades• Relaciones

– Dependencia

– Generalización

– Asociación

• Interfaces– Relaciones de Realización

• Roles• Paquetes• Instancias• Diagramas de clases• Diagramas de objetos

Modelado Estructural• Modelado: Parte del UML que se ocupa de identificar

todas las partes importantes de un sistema, así como sus interacciones.

• Modelado estructural: Se modelan los aspectos estáticos de un sistema

• Se utilizan clases

Nombre

Atributos

Operaciones

Estereotipos

• Para cada clase hay que determinar un conjunto de responsabilidades y posteriormente determinar los atributos y las operaciones necesarias para llevar a cabo las responsabilidades de la clase

Modelado Estructural (II)

• Responsabilidades: – Fin para el que es creada una clase. – Obligaciones

• Es buena práctica iniciar especificando las responsabilidades de cada clase.

• Objetivo: Abstraer lo necesario y suficiente. No dar demasiadas responsabilidades a una sola clase ni obtener clases con muy pocas responsabilidades.

Modelado Estructural (III)

• Relaciones– Manera de representar las interacciones entre clases– OJO: Si se modela en exceso, se obtendrán diagramas

con un alto nivel de dificultad para poder leerlos. Si se modela insuficiente, se obtendrán diagramas sin la semántica suficiente.

• Relación de dependencia

– Un cambio en la especificación del elemento independiente puede afectar al otro elemento implicado en la relación

Modelado Estructural (IV)• Relación de Generalización

– Se establece entre un elemento general (superclase o padre) y un caso más específico de ese elemento (subclase o hijo). Es el caso de la Herencia

– Los objetos hijos se pueden utilizar en cualquier lugar donde aparece el padre

– Puede modelarse herencia simple y múltiple

– Polimorfismo: así es como el hijo extiende la funcionalidad del padre en su ámbito.

Modelado Estructural (V)• Relación de Asociación

– Los objetos de un elemento están conectados con los objetos de otros

– Puede existir relaciones recursivas (conexión con otros objetos de la misma clase)

– “Adornos” para facilitar su comprensión• Nombre: Utilizado para describir la naturaleza de la relación

• Rol: Cara que una clase presenta a la clase que en encuentra en el otro extremo de la asociación

• Multiplicidad: Indica cuántos objetos se pueden conectar a traes de una instancia de la asociación

• Agregación: Relación estructural entre iguales. Sirve para modelar relaciones del tipo “todo/parte”

• Composición: Como la agregación simple, pero existe una fuerte relación de pertenencia y vidas coincidentes de la parte del todo.

Modelado Estructural (VI)• Ejemplo de asociación simple

Persona Empresa 1..* Trabaja para *

Nombre

empleado Patrón

Rol

• Ejemplo de agregación

• Ejemplo de composición

Modelado Estructural (VII)• Interfaces

– Colección de operaciones que sirven para especificar el servicio que una clase o componente da al resto de las partes involucradas en un sistema

– UML las utiliza para modelar las líneas de separación de un sistema

– Puede participar en relaciones de realización

– Una interfaz especifica un contrato para una clase o componente sin dictar su implementación

Representación 1

Representación 2

Modelado Estructural (VIII)

• Roles– Una clase puede implementar varios interfaces. Un rol

denota un comportamiento de una entidad en un contexto particular.

Lo habitual es utilizar la notación en forma de círculo para denotar líneas de separación del sistema cuando utilizamos componentes, y utilizar la notación expandida en las relaciones de realización

• Relación de realización (en interfaces)– La clase que implementa garantiza que

hará las veces de la interfaz. Es una relación mucho más fuerte que la generalización

Modelado Estructural (IX)• Paquetes

– Mecanismo de propósito general para organizar elementos de modelado en grupos

– Se puede controlar la visibilidad de los elementos de un paquete (algunos podrán ser visibles, otros estarán ocultos)

GestiónUsuarios

Usuario Permisos

Accesos

– Un paquete forma un espacio de nombres.

• GestiónUsuarios::Usuario

– Los paquetes se pueden anidar, pero deben evitarse paquetes muy anidados. Dos o tres niveles de anidamiento como máximo.

Modelado Estructural (X)

• Instancias– Sinónimo de objeto. Representa la manifestación

concreta de una abstracción (clase, nodo, casos de uso, asociaciones...)

– Sus operaciones se denotan como• u.getPermisos()

– Los valores concretos de sus atributos determinan su estado

usuario

Diagramas de clases• Diagrama que muestra un conjunto de clases,

interfaces, colaboraciones y sus relaciones• Usos

– Modelar el vocabulario de un sistema (abstracciones que son parte del sistema y las que no lo son)

– Modelar colaboraciones simples• Colaboración: Sociedad de clases, interfaces y otros elementos

que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de todos sus elementos.

– Modelar el esquema lógico de una base de datos.

• Se utilizan para visualizar los aspectos estáticos de los bloques de construcción del sistema.

Diagrama de clases (II)

• Uso: Colaboraciones simples. Pasos a seguir– Identificar los mecanismos que se quieren modelar

• Mecanismo: Función o comportamiento de parte del sistema que se está modelando y que resulta de la interacción de una sociedad de clases, interfaces y otros elementos.

– Para cada elemento, identificar las clases, interfaces y otras colaboraciones que participan en esta colaboración, así como las relaciones entre estos elementos

– Usar escenarios para recorrer la interacción entre estos elementos. Se descubrirán partes del modelo que faltaban y las que son semánticamente incorrectas

– Dotar a estos elementos de contenido: Equilibrar el reparto de responsabilidades entre clases, y convertir las responsabilidades en atributos

Diagrama de clases (III)

Diagrama de objetos (I)

• Contiene un conjunto de instancias (objetos) de los elementos encontrados en un diagrama de clases

• Expresa la parte estática de una interacción, mostrando los objetos que colaboran pero sin ninguno de los mensajes enviados entre ellos

• Un diagrama de objetos congela un instante del tiempo• Hay quienes los consideran como un caso particular de

diagrama de clases• Usos

– Modelar estructuras de datos estáticas para así sustentar los requisitos funcionales de un sistema.

– Visualizar, especificar, construir y documentar la estructura de objetos, especialmente en estructuras de datos complejas.

– Mostrar significativamente conjuntos interesantes de objetos concretos o prototípicos

Diagramas de objetos (II)

• Pasos a seguir:– Identificar el mecanismo a modelar

– Para cada mecanismo, identificar las clases, interfaces y otros elementos que participan en esta colaboración, así como las relaciones entre estos elementos

– Considerar un escenario en el que intervenga este mecanismo. Congelar este escenario en un momento concreto y representar cada objeto que participe en el mecanismo

– Mostrar el estado y valores de los atributos de cada uno de esos objetos, si son necesarios para comprender el escenario

– Mostrar los enlaces de esos objetos, que representarían instancias de las asociaciones entre ellos

Modelado del Comportamiento. Índice• Interacciones

– Enlaces

– Mensajes

– Modelado de un flujo de control

– Diagramas de interacción• Modelado de flujos de control por ordenación temporal

– Diagramas de secuencia

• Modelado de flujos de control por organización– Diagramas de colaboración

• Casos de uso– Actores

– Flujo de eventos

– Escenarios

– Colaboraciones

– Modelado del comportamiento de un elemento

• Diagramas de actividades

Modelado del comportamiento (I)

• Se modelan los aspectos dinámicos de un sistema mediante interacciones

• Interacción: Comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto para lograr un propósito

• Utilizada para modelar el flujo de control dentro de una operación, una clase, un componente, un caso de uso el propio sistema

• Un mensaje es la especificación de una comunicación entre objetos que transmite información, con la expectativa de que se desencadenará una actividad

Modelado del comportamiento (II)• ¿Dónde aparecen las interacciones?

– En la colaboración de objetos existentes en el contexto de un sistema o un subsistema

– Entre los objetos de un mismo subsistema en la implementación de una operación

– En el contexto de una clase (cómo los atributos y diferentes operaciones interaccionan entre sí para dar lugar a una nueva operación)

• Los objetos que participan en una interacción son o bien elementos concretos (objetos) o bien elementos prototípicos (clases, nodos y casos de uso

• Enlace: Instancia de una asociación. Siempre que exista un enlace entre dos objetos, un objeto puede mandar un mensaje al otro

Modelado del comportamiento (III)• Mensajes: Especificación de una comunicación entre

objetos que transmite información, con la expectativa de que se desencadenará alguna actividad

• Tipos de mensajes– Llamada: Invoca una operación sobre un objeto– Retorno: Devuelve un valor al invocador– Envío: Envía una señal a un objeto– Creación– Destrucción

Modelado del comportamiento (IV)• Modelado de un flujo de control: Construir una

representación gráfica (a modo de diagrama de secuencias o de colaboración) de las acciones que tienen lugar entre un conjunto de objetos. Método base.– Establecer el contexto de la interacción

– Establecer el escenario identificando qué objetos juegan un rol, estableciendo sus propiedades iniciales (estado = valores de sus atributos)

– Identificar los enlaces que conectan los objetos y que son relevantes para los flujos de mensajes que tienen lugar en la interacción

– Especificar los mensajes que pasan de un objeto a otro mediante una organización temporal

– Adornar cada objeto con su estado y rol siempre que sea preciso

Diagramas de Interacción

• Representaciones gráficas de escenarios que implican la interacción de ciertos objetos interesantes y los mensajes enviados entre ellos, para modelar aspectos dinámicos.

• Dos formas de construirlos– Destacando la ordenación temporal de los mensajes

• Diagramas de secuencias

– Destacando la relación estructural de los objetos que interactúan

• Diagramas de colaboración

Diagrama de secuencias (I)

• Destaca la ordenación temporal de los mensajes• Se obtiene una representación visual clara del

flujo de control a lo largo del tiempo• Características

– Línea de vida. Representa la existencia de un objeto a lo largo de un período de tiempo. Si se crean o destruyen objetos durante la interacción, sus líneas de vida aparecen y desaparecen cuando reciben los mensajes estereotipados

• <<create>>

• <<destroy>>

– Foco de control. Representa el período de tiempo durante el cual un objeto ejecuta una acción

Diagrama de secuencias (II)• Clasificación de mensajes

– Síncronos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Se representan con flechas con la cabeza llena.

– Asíncronos, estos mensajes terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

• También se representa la respuesta a un mensaje con una flecha discontinua.

Diagramas de secuencias (III)• Modelado de flujos de control por ordenación temporal

– Establecer el contexto de la interacción (sistema, subsistema, clase, caso de uso...). Típicamente se escoge un caso de uso

– Establecer un escenario de la interacción: identificar qué objetos juegan un rol. Los objetos se organizan en el diagrama de izquierda a derecha, colocando los objetos más importantes a la izquierda y sus objetos vecinos a la derecha.

– Establecer la línea de vida de cada objeto. La mayoría persisten la interacción completa. Para los que no, debe indicar explícitamente su creación y destrucción

– A partir del mensaje que inicia la interacción, hay que ir colocando los mensajes subsiguientes de arriba a abajo entre las líneas de vida, mostrando las propiedades de cada mensaje (sus parámetros, por ejemplo). Establecer si los mensajes son síncronos o asíncronos

– Adornar cada mensaje con marca de tiempo si son necesarias restricciones de tiempo

– Se pueden incluir pre y poscondiciones.

Diagrama de secuencias (IV) Ejemplo

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tiene modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.

Diagrama de colaboración (I)• Desde UML 2.0 tenemos el diagrama de comunicación, versión

simplificada del diagrama de colaboración

• Destaca la organización de los objetos que participan en una interacción

• Ofrece una representación clara del flujo de control en el contexto de la organización estructural de los objetos que colaboran

• Características– Para indicar cómo se enlaza un objeto a otro, se puede asociar un

estereotipo de camino al extremo más lejano de un enlace• <<local>>

• <<parameter>>

• <<global>>

• <<self>>

– Número de secuencia para indicar la ordenación temporal de un mensaje y su anidamiento: numeración decimal de Dewey

Diagrama de colaboración (II)• Modelado de flujos de control por organización

– Establecer el contexto de la interacción

– Establecer un escenario de la interacción, identificando qué objetos juegan un rol en ella. Los objetos deben organizarse en el diagrama de colaboración como los nodos del grafo, colocando los objetos más importantes en el centro y sus objetos vecinos en el exterior

– Establecer las propiedades iniciales de cada uno de estos objetos. Si los valores de los atributos, valores etiquetados, estado o rol de algún objeto cambia de forma significativa durante la interacción, hay que colorar un objeto duplicado en el diagrama, actualizado con los nuevos valores y conectarlo con un mensaje estereotipado como become o copy

– Especificar los enlaces entre esos objetos, juntos con los mensajes que pueden pasarse

• Colocar los enlaces de asociaciones en primer lugar

• Colocar los demás enlaces a continuación, y adornarlos con los estereotipos de camino adecuados (como global y local) para especificar explícitamente cómo se conectan estos objetos entre sí

Diagrama de colaboración (III)

• Modelado de flujos de control por organización (II)– Comenzando por le mensaje que inicia la interacción, hay que asociar

cada mensaje subsiguiente al enlace apropiado, estableciendo su número de secuencia. Los anidamientos se representan con la numeración decimal de Dewey

– Si es necesario especificar restricciones de tiempo, hay que adornar cada mensaje con una marca de tiempo

– Si es necesario, pueden agregarse pre y postcondiciones

Diagrama de colaboración (IV)

Modelado del comportamiento (IV)• Casos de uso: Especifica el comportamiento de un sistema o

una parte del mismo, y es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable para un actor

• Se emplean para capturar el comportamiento deseado del sistema en desarrollo sin tener que especificar cómo se implementa ese comportamiento.

• Proporcionan un medio para que desarrolladores y usuarios finales del sistema lleguen a una comprensión común del sistema.

• No especifican cómo se implementa: especifican un comportamiento deseado, pero no indican cómo se lleva a cabo

• Normalmente se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

Modelado del comportamiento (V)

• Actores– Los actores representan un rol que puede ser

jugado por una persona, un dispositivo hardware o incluso otro sistema

– Se pueden representar categorías de actores más generales

– Sólo se pueden conectar a los casos de uso a través de asociaciones

• Variantes: Casos de uso que son versiones especializadas de otros casos de uso.

• Pueden aplicarse al sistema completo o partes del sistema.

• Un caso de uso representa un requisito funcional del sistema

Modelado del comportamiento (VI)• El comportamiento de un caso de uso se puede

especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo entienda fácilmente

• Una vez especificados en modo texto se pueden especificar gráficamente mediante diagramas de interacción– Se usa un diagrama de secuencia para especificar el

flujo principal de un caso de uso– Variantes del diagrama de secuencia para especificar

los flujos excepcionales

Modelado del comportamiento (VII)

Modelado del comportamiento (VIII)• Importancia de los casos de uso

– Permite a los analistas especificar su vista externa del sistema a nivel suficiente para que los desarrolladores construyan su vista interna• Proporcionan un foro común donde desarrolladores,

analistas y usuarios finales pueden intercambiar opiniones

– Los casos de uso proporcionan a los desarrolladores una forma de abordar y comprender un elemento• Permiten que el creador de un elemento comunique

su intención sobre cómo se debería usar– Sirven de base para probar cada elemento según

evoluciona durante el desarrollo

Modelado del comportamiento (IX)

• Modelado del comportamiento de un elemento– Identificar los actores que interactúan con el elemento

– Organizar los actores identificando tanto los roles más generales como los más especializados

– Considerar las formas más importantes que tiene cada actor de interactuar con el elemento

– Considerar las interacciones que implican el cambio de estado del elemento o su entorno o que involucren una respuesta ante algún evento

– Considerar las formas excepcionales en las que cada actor puede interactuar con el elemento

– Organizar estos comportamientos como casos de uso

Diagramas de casos de uso (I)

• Sirve para visualizar el comportamiento del sistema: Los servicios visibles externamente que proporciona el sistema en el contexto de su entorno. Usos– Modelar el contexto de un sistema– Modelar los requisitos de un sistema

Diagramas de casos de uso (II)• Modelado del contexto de un sistema

– Hay que identificar los actores en torno al sistema considerando los siguientes grupos

• Los que requieren ayuda del sistema para llevar a cabo sus tareas

• Los necesarios para ejecutar las funciones del sistema

• Los que interactúan con el hardware externo o con otros sistemas software

• Los que realizan funciones secundarias de administración y mantenimiento

– Organizar los actores similares en jerarquías de generalización / especialización

– Proporcionar un estereotipo a cada uno de esos actores

– Introducir esos actores en un diagrama de casos de uso y especificar las vías de comunicación con cada uno de los casos de uso del sistema

Diagramas de casos de uso (III)

Diagrama de casos de uso (IV)

• Modelado de los requisitos de un sistema– Establecer el contexto del sistema, identificando los

actores a su alrededor– Considerar el comportamiento que cada actor espera

del sistema o requiere que éste le proporcione– Nombrar esos comportamientos comunes como casos

de uso– Factorizar el comportamiento común en nuevos casos

de uso que puedan ser utilizado por otros– Adornar los casos de uso con notas que enuncien los

requisitos no funcionales

Diagrama de casos de uso (V)

Diagrama de Actividades (I)• Muestra el flujo de las actividades software de alto nivel en la

ejecución de un sistema, pero sin profundizar en los detalles internos de mensajes

• Actividad: Ejecución no atómica en curso, dentro de una máquina de estados. Las actividades producen finalmente alguna acción

• Las acciones incluyen llamadas a otras operaciones, envío de señales, creación o destrucción de objetos o simples cálculos, como la evaluación de una expresión

• Los diagramas de estado contienen– Estados de actividades

– Estados de acción

– Transiciones

– Objetos

• Especialmente útil para visualizar los flujos de trabajo y los procesos de negocio

Diagrama de Actividades (II)• Estados de acción: Estados del sistema. Representan la

ejecución de una acción. – Ejemplos

• Evaluar una expresión• Invocar una operación sobre un objeto• Enviar una señal a un objeto• Crear o destruir un objeto

– No se pueden descomponer. Son atómicos (no se interrumpe su ejecución)

– Su ejecución conlleva un tiempo insignificante

• Estados de actividad. Elemento compuesto cuyo flujo de control se compone de otro estado de actividad y estados de acción– No son atómicos. Se pueden descomponer– Su ejecución conlleva un tiempo

Diagrama de Actividades (III)• Transiciones• Bifurcaciones: Especifica caminos

alternativos, elegidos según el valor de alguna expresión booleana

• División y Unión: Utilizadas para modelar flujos concurrentes (estas pueden ser realmente concurrentes o secuenciales pero con ilusión de concurrencia)

Diagrama de Actividades (IV)

• Calles (o Swimlanes): Dividir los estados de actividad de un diagrama de actividades en grupos, donde cada uno representa la parte de la organización responsable de esas actividades.

• Cada calle representa una responsabilidad de alto nivel de una parte de actividad global de un diagrama de actividades, y cada calle puede ser implementada en última instancia por una o más clases

Diagrama de Actividades (VI)

• Usos:– Se usan en el contexto del sistema global, un

subsistema, una operación o una clase.– Se pueden asociar diagramas de actividades a un caso

de uso (se modela un escenario) y a las colaboraciones (se modelan aspectos dinámicos de una sociedad de objetos)

– Modelar un flujo de trabajo (se ve el sistema desde el punto de vista de los actores)

– Modelar una operación (utilizado como diagrama de flujo u organigrama)

Diagrama de despliegue• Utilizados para modelar el hardware utilizado en las

implementaciones de sistemas y las relaciones entre sus componentes

• Elementos usados – nodos (representados como un prisma)

– componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo)

– asociaciones

• Artefacto: un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes

• Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales

Diagrama de despliegue (II)

• La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Diagrama de despliegue (III)

Diagrama de paquetes• Muestra como un sistema está dividido en agrupaciones

lógicas mostrando las dependencias entre esas agrupaciones

Diagrama de tiempos

• Gráfica de formas de onda digitales que muestra la relación temporal entre varias señales, y cómo varía cada señal en relación a las demás.

Nuevos diagramas en UML 2.0

• Diagrama de estructura compuesta– Muestra la estructura interna de una clase y las

colaboraciones que esta estructura hace posibles

• Diagrama global de interacciones– Es un diagrama de comportamiento, más precisamente,

uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados

– Algunos elementos gráficos están tomados del diagrama de actividades

Inconvenientes de UML

• Problemas típicamente achacados a UML– Carencia de una semántica precisa, lo que ha dado

lugar a que la interpretación de un modelo UML no pueda ser objetiva.

– No se presta con facilidad al diseño de sistemas distribuidos (¿cómo se modela transmisión, serialización, persistencia, que un objeto es persistente o remoto?)

• UML no es una metodología, pero “se entiende as픕 Solución: UML sí acepta la creación de nuestros

propios componentes para este tipo de modelado

Ciclo de vida de un proyecto software

Herramientas CASE

• Computer Aided Software Engineering: Ingeniería de Software Asistida por Ordenador)

• Aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero.

• Nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.

Herramientas CASE. Objetivos• Mejorar la productividad en el desarrollo y mantenimiento del software

• Aumentar la calidad del software

• Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos

• Mejorar la planificación de un proyecto

• Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos

• Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto

• Ayuda a la reutilización del software, portabilidad y estandarización de la documentación

• Gestión global en todas las fases de desarrollo de software con una misma herramienta

• Facilitar el uso de las distintas metodologías propias de la ingeniería del software

Algunas Herramientas CASE

• ArgoUML• CASE Studio 2 • CASEWise• Eclipse - Sitio Web• GNU Ferret• MetaCASE• Rational Rose• Umbrello• Microsoft Visio

XMI

• XMI o XML Metadata Interchange (XML de Intercambio de Metadatos) es una especificación para el Intercambio de Diagramas

• La especificación para el intercambio de diagramas fue escrita para proveer una manera de compartir modelos UML entre diferentes herramientas de modelado