Introducción a UML

Introducción a UML
David Pinelo
Marzo – 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 general
Bloques de construcción
Elementos
Estructurales
Comportamiento
●Agrupación
●Anotación
●
●
Reglas
Diagramas
Clases
●Objetos
●Casos de Uso
●Secuencia
●Colaboración
●Estados
●Componente
●Despliegue
●
Nombres
Alcance
●Visibilidad
●Integridad
●
Afectan
●
Afectan
Colaboran
Mecanismos
Relaciones
Dependencia
●Asociación
●Generalización
●Realización
●
Especificaciones
●Adornos
●Divisiones Comunes
●Extensibilidad
●
Actúan
UML. Diagramas
Diagramas
Diagramas de
Estructura
Diagramas de
Clases
Diagramas de
Componentes
Diagramas de
Objetos
Diagramas de
comportamiento
Diagramas de
Despliegue
Diagramas de
Estructura
Compuesta
Diagramas de
Actividad
Diagramas de
Paquetes
Diagramas de
Secuencia
Diagramas de
Interacción
Diagramas de
Colaboración
Diagramas de
Estados
Diagramas de
Casos de uso
Diagrama
Global de
Interacción
Diagramas de
Tiempos
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 y
Ivar Jacobson)
Digital Equipment
Hewlett-Packard
i-Logix (David Harel)
IBM
ICON Computing
(Desmond D'Souza)
Intellicorp and James
Martin & co. (James Odell)
MCI Systemhouse
Microsoft
ObjecTime
Oracle Corp.
Platinium Technology
Sterling Software
Taskon
Texas Instruments
Unisys
Bloques de construcción
• Elementos estructurales
– Clases
– Colaboración
Descripción de un conjunto
de objetos que comparten
los mismos atributos,
operaciones, relaciones y
semántica.
– Interfaz
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
Cadena de
responsabilidad
– Casos de uso
Login de usuario
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
– Nodos
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.
Servidor
Es igual que una clase,
excepto que sus objetos
representan elementos
cuyo comportamiento es
concurrente con otros
elementos.
– Componente
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
dibujar
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)
• Elementos de agrupación
– Paquete
– Máquinas de estados
Waiting
• Elementos de
anotación
Bloques de construcción (IV)
• Relaciones
– Dependencia
– Asociació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).
– Generalización
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.
*
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.
– Realización
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
•
Vocabulario
•
Funcionalidad
•
Ensamblado del
sistema
•
Gestión de las
configuraciones
Vista de
Diseño
Vista de
Implementación
Vista de los
Casos de Uso
Vista de
procesos
Vista de
despliegue
•
Funcionamiento
•
•
Capacidad de
crecimiento
Topología del
sistema
•
Distribución
•
Rendimiento
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
Nombre
Persona
1..*
Trabaja para
empleado
*
Empresa
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)
• 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
• 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
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)
– Un paquete forma un espacio de
nombres.
GestiónUsuarios
Usuario
Accesos
Permisos
• 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)
• Un caso de uso representa un requisito funcional del
sistema
• 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.
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