Upload
dangtuyen
View
232
Download
0
Embed Size (px)
Citation preview
Ingeniería del Software de Gestión www.kybele.es
Tema 4b:Introducción a UML
Marcos López SanzIngeniería del Software de Gestión
Ingeniería del Software de Gestión www.kybele.es
Índice
Introducción a UML
Generalidades y evolución histórica
Mecanismos de extensión
Vistas y diagramas
Ciclo de vida en el PUD
Ingeniería del Software de Gestión www.kybele.es
UML
Unified Modeling Language (Lenguaje unificado de modelado)
Mitos sobre UML
UML es un lenguaje de programación
Aprender UML es aprender el paradigma de objetos.
UML es una metodología de desarrollo.
UML es solo para modelos de objetos
Ingeniería del Software de Gestión www.kybele.es
Características Generales
Lenguaje
Características generales: Incluye conceptos semánticos, notación y reglas de creación
de diferentes tipos de diagramas
Permite capturar información acerca de la estructura estática y el comportamiento dinámico de un sistema
Lenguaje de modelado visual de propósito general usado para: Especificar Modelos precisos, no ambiguos, completos Visualizar Representar y comunicar ideas Construir Trasladar a un lenguaje de programación Documentar Los artefactos construidos durante un proyecto de
desarrollo de un sistema software
Ingeniería del Software de Gestión www.kybele.es
Características Generales
Unificado
Lenguaje = sintaxis + semántica
Unificado a través de:
Métodos y notaciones históricas integradas
Usado en múltiples etapas del ciclo de desarrollo (de requerimientos a implementación)
Gran diversidad de dominios de aplicación
Amplia variedad de lenguajes y plataformas de implementación representables
Aplicable en diferentes procesos de desarrollo
Ingeniería del Software de Gestión www.kybele.es
Características GeneralesModelado
¿Qué es un modelo? Una abstracción que representa algún aspecto de la realidad Una representación en algún medio que captura los aspectos
importantes del sistema modelado desde un determinado punto de vista
Un modelo de un sistema software es realizado en un lenguaje de modelado
Propósito de los modelos Capturar y precisar requerimientos de un dominio de
conocimiento, que sea comprensible por todos los stakeholdersdel proyecto.
Pensar sobre un diseño de un sistema. Capturar decisiones de diseño de un sistema. Explorar posibles soluciones a un problema económicamente. Generar productos de trabajo útiles. Documentar.
E = M * C2
Ingeniería del Software de Gestión www.kybele.es
Breve evolución histórica
Evolución: Oct. 1994: G. Booch y J. Rumbaugh se unen en Rational. Intentan unificar
OMT (Object Modeling Tool) y Booch (método) Oct. 1995: I. Jacobson se une a Rational Unified Method v0.8 Nov. 1997: OMG (Object Management Group) aprueba UML (v1.1) 2003: versión 1.5 de UML Oct. 2004: versión 2.0 de UML 2005: convertido en estándar
ISO/IEC 19501:2005 Information technology — Open Distributed Processing —Unified Modeling Language (UML) Version 1.4.2.
Cambios entre versiones: Refinamiento y extensión de modelos Ampliación de semántica Cambio en las restricciones de uso de elementos en modelos
Ingeniería del Software de Gestión www.kybele.es
Breve evolución histórica
Ingeniería del Software de Gestión www.kybele.es
Influencias
Ingeniería del Software de Gestión www.kybele.es
Participantes en UML 1.0
Rational Software
Grady Booch, Jim Rumbaugh y IvarJacobson
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
Ingeniería del Software de Gestión www.kybele.es
Vistas de UML
¿Qué es una vista? Una vista es un subconjunto de construcciones de modelado
que se enfocan en un aspecto particular del sistema
Proyección del sistema completo en un modelo
Cada vista cuenta con uno o más diagramas representativos
Las vistas pueden agruparse en tres áreas: Estructural
Comportamiento dinámico
Gestión del modelo
Ingeniería del Software de Gestión www.kybele.es
Describe los elementos del sistema (clasificadores) y sus relaciones Clasificadores más comunes:
Clases Casos de Uso Componentes Nodos
Vistas y diagramas asociados: Vista Estática
Diagrama de clases Diagrama de objetos
Vista de Casos de uso Diagrama de casos de uso
Vista de Implementación Diagrama de componentes Diagrama de despliegue
Vistas de UMLClasificación estructural
Ingeniería del Software de Gestión www.kybele.es
Vistas de UMLComportamiento dinámico
Describe el comportamiento del sistema a través del tiempo
Vistas y diagramas asociados: Vista de Interacción: modela como interactúan los objetos
para realizar una funcionalidad del sistema Diagrama de colaboración
Diagrama de secuencia
Vista de Máquina de estados: modela el ciclo de vida de una instancia de una clase en estados y transiciones. Diagrama de transición de estados
Vista de Actividades: modela flujos de trabajo (workflows) Diagrama de Actividades
Ingeniería del Software de Gestión www.kybele.es
Vistas de UMLGestión del modelo
Describe la organización de los modelos en unidades jerárquicas
Permite manejar la complejidad mediante la identificación de agrupaciones de clasificadores
Elementos utilizados:Paquetes
Subsistemas
Modelos
Ingeniería del Software de Gestión www.kybele.es
Mecanismos de extensión
Permiten adaptar los elementos de modelado asignándole una semántica particular. Estereotipos:
Extienden la semántica del elemento sobre el que se aplica Permite representar una variación de un elemento existente que posee otra
intención, o distinción de uso Puede indicarse textualmente (entre << y >>) o gráficamente
Valores etiquetados Extiende las propiedades de un elemento de UML, permitiendo añadir nueva
información en la especificación del elemento Cadenas con el nombre de la etiqueta, un signo igual y un valor
Restricciones Notación matemática formal OCL Lenguaje de programación o pseudocódigo
Ingeniería del Software de Gestión www.kybele.es
Mecanismos de extensión
Ejemplo
Ingeniería del Software de Gestión www.kybele.es
Áreas, vistas y diagramas
Ingeniería del Software de Gestión www.kybele.es
Áreas, vistas y diagramas
Otra clasificación (UML 1.5) Diagramas estáticos (o estructurales *)
Diagramas de clases
Diagramas de objetos
Diagramas de componentes
Diagramas de despliegue
Diagramas dinámicos (o de comportamiento)
Diagramas de casos de uso*
Diagramas de secuencia
Diagramas de colaboración
Diagramas de estados
Diagramas de actividades
Ingeniería del Software de Gestión www.kybele.es
Áreas, vistas y diagramas
Otra clasificación (UML 2.0)
Ingeniería del Software de Gestión www.kybele.es
Vista estática
Propósito:
Capturar la estructura del sistema en base a elementos (clasificadores) que lo definen
Es la base sobre la que se construyen las otras vistas
Diagramas:
Diagrama de Clases
Diagrama de Objetos
Ingeniería del Software de Gestión www.kybele.es
Vista estáticaElementos
Clasificador es un concepto discreto en el modelo que tiene identidad, estado,
comportamiento, y relaciones
Tipos de Clasificadores Elementos del Sistema:
Clase Interfaz Tipos de datos
Conceptos de Comportamiento: Caso de Uso
Cosas del entorno: Actor
Estructuras de implementación: Componente Nodo Subsistema
Ingeniería del Software de Gestión www.kybele.es
Vista estáticaElementos
Clase Conjunto de objetos con estructura, comportamiento, relaciones, y
semántica común.
Objeto = estructura + operaciones + estado interno + identidad Un objeto es una instancia de una clase.
Ejemplos algo físico → Avión algo del negocio → Pedido un concepto lógico → Horario algo de la aplicación → Window, Botón, Menú algo del comportamiento → Tarea, Proceso
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases
El diagrama de clases representa la vista estática de un sistema software
Los elementos que aparecen en este diagrama son aquellos conceptos que tienen significado dentro de una aplicación
Elementos principales de este diagrama: Clasificadores: elementos que describen cosas Relaciones entre clasificadores
La definición de cada concepto del mundo real se identifica con una clase de este diagrama
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:Clase
Clase: se representa en un rectángulo con tres compartimientos
nombre de la clase
atributos de la clase
operaciones de la clase
#Patrullar()
-Entrenar()
+MostrarCondecoraciones()
-Num_Placa : int
-Nombre
-Apellidos
+Apodo
-AñosServicio : int = 0
-Condecoraciones
-Puntería
-Experiencia
Policia Nombre de la clase
Atributos
Operaciones
Tipos de los atributos
Valor inicial
{<10} Restricción sobre el valor
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:Visibilidad
Determina el nivel de encapsulamiento de los elementos de una clase (-) Privado: Los atributos/operaciones son visibles solo desde la propia
clase.
(#) Los atributos/operaciones protegidos están visibles para la propia clase 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 deencapsulación)
Visibilidad+ público# protegido- privado
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:Relaciones entre clasificadores
Las posibles relaciones entre clasificadores son: Asociación (conocimiento)
Agregación / Composición
Generalización
Dependencia
Realización
Enlace: Instancia de una asociación
Lista ordenada de referencias a objetos
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:Relaciones entre clases
Asociación:
Conexión semántica entre instancias de clases
Proporciona una conexión para el envio de mensajes
#Patrullar()
-Entrenar()
+MostrarCondecoraciones()
-Num_Placa : int
+Apodo
-Puntería
-Experiencia
Policia
#Robar()
-Escapar()
+MostrarHistorial()
-IDLadron : int
+Apodo
-Tipo : int = 0
-Encarcelaciones
-Puntería
Ladrón
-perseguidor
1..*
-delincuente
1..*
Persigue4
Multiplicidad
Multiplicidad0..1 N..M0..* 3..*1..* 2..51 3..4, 6..**
Nombre de la relación
Dirección de lectura de la relación
Navegabilidad (uni/bi-direccional)roles
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases: Asociación: casos especiales
Asociación como clase (clase de asociación)
Asociación calificada
Asociación ordenada
Restricción
Teatro Obra
-Fecha
-Hora
Presentacion
* *
Presentacion EntradaNum_Butaca
1 1..*
Presentacion Diapositiva
1
{ordered}
1..*
CuentaPersona
1
*
or
Empresa
*
*
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:
Relaciones entre clases
Agregación: relación entre un todo y sus partes
Lógica: la parte puede pertenecer a varios agregados
Física (o composición): las partes sólo existen asociadas al compuesto (acceso a través de él)
Universidad Estudiante1..* 1..*
Universidad Departamento1 1..*
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:
Relaciones entre clases
Consideraciones sobre la composiciónUna composición es una forma de asociación más fuerte
en la cual el compuesto es responsable de gestionar sus partes, por ejemplo asignación y desasignación
La composición implica tres cosas: Dependencia existencial. El elemento dependiente
desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo
Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene
Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto
Ingeniería del Software de Gestión www.kybele.es
Dependencia: Indica una relación semántica entre dos o más elementos del modelo en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia
Diagrama de clases:
Relaciones entre clases
#Robar()
-Escapar()
+MostrarHistorial()
-IDLadron : int
+Apodo
-Tipo : int = 0
-Encarcelaciones
-Puntería
Ladrón
+usar()
+aprenderUso()
-material
-fuerza
Herramienta«uses»
Mecanismos de extensión de UML
• Estereotipos <<excepción>>• Valores etiquetados {versión=3.1}• Restricción {edad>18}
Estereotipo
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:
Relaciones entre clases
Generalización:
Relación taxonómica entre una descripción general y otra más específica que la extiende
Relación “es un tipo de”
Representación del concepto de herencia
#Patrullar()
-Entrenar()
+MostrarCondecoraciones()
-Num_Placa : int
+Apodo
-Puntería
-Experiencia
Policia
-Origen
+Especialidad
Criminalista
+Riesgo
-Pistola
Patrullero
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:
Relaciones entre clases
Realización: Es una relación que implica que la parte realizante cumple con una serie
de especificaciones propuestas por la clase realizada
Situaciones de aplicación: Interfaces y las clases y componentes que lo implementan
Casos de uso y colaboraciones que lo realizan
#Patrullar()
-Entrenar()
+MostrarCondecoraciones()
-Num_Placa : int
+Apodo
-Puntería
-Experiencia
Policia
«interfaz»
MiembroSeguridad
Ingeniería del Software de Gestión www.kybele.es
Diagrama de clases:Interfaces
Describen un protocolo de comportamiento sin especificar su implementación.
Contienen operaciones pero no atributos.
Una interfaz puede ser implementada por varias clases
Ingeniería del Software de Gestión www.kybele.es
Diagramas de Clases vs.Diagramas de Objetos
Ambos pertenecen a dos vistas complementarias del modelo Diagrama de Clases: muestra la abstracción de una parte del dominio
Diagrama de Objetos: representa una situación concreta del dominio
Banco Cliente
*1
Cuenta
*11 * 1 *
unBanco : Banco
cliente01 : Cliente
cliente02 : Cliente
cta0101 : Cuenta
cta0201 : Cuenta
cta0202 : Cuenta
Ingeniería del Software de Gestión www.kybele.es
Ejercicio
Se desea modelar el sistema de control de un reproductor de MP3 que tiene las siguientes características:
Un reproductor tiene una marca y modelo determinado. Las operaciones que permite este aparato son: escuchar música (de la memoria), escuchar la radio o configurar el dispositivo
El módulo de memoria permite: conocer la capacidad de la memoria, el número de canciones almacenadas, seleccionar una canción (aleatoriamente o por su título) y borrar una canción
De cada canción se conoce su título, intérprete, duración, tamaño que ocupa, y tipo de compresión (en kbps)
El módulo de radio permite: seleccionar un dial concreto (preseleccionado o manualmente), cambiar de AM a FM y viceversa y preseleccionar emisoras.
Cada emisora se caracteriza por estar en una banda (AM/FM), por un número de frecuencia y por una cobertura
El módulo para la configuración del equipo permite: modificar el brillo y colores del display, consultar el estado de la batería y modificar la ecualización del sonido.
Diseñar el diagrama de clases UML correspondiente a estas especificaciones
Ingeniería del Software de Gestión www.kybele.es
Vista de Casos de Uso
Diagramas de casos de uso: Capturan los requerimientos funcionales del sistema Describen la forma de usar el sistema tal como se la ve desde
el exterior Visión de “caja negra” del sistema. No es un modelo orientado a objetos. Particiona la funcionalidad del sistema en unidades
discretas: los casos de uso.
Concepto introducido por I.Jacobson en OOSE (ObjectOriented Software Engineering)
Diagramas de Casos de Uso: Actores + Caso de uso
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoActor
Representa algo que interactúa con el sistema
Puede ser humano u otro sistema (externo)
Reside fuera del sistema sirve para describir el entorno del sistema
Describe un “rol” que asume un usuario
La misma persona física puede asumir distintos roles
Ejemplos: Cliente del Banco
Cajero
Pasarela bancaria
Sistema de sensores Cliente del Banco
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoCaso de uso
Secuencia de transacciones realizadas por el sistema que brinda un resultado de valor a un actor
Describe una “forma” de utilizar el sistema o una “razón” por la que el usuario interactúa con el sistema
Funciones: Capturan requisitos funcionales del sistema Estructuran los modelos de objetos en vistas manejables
Un caso de uso puede tener varios caminos de acción o “escenarios”
Los casos de uso sirven como hilo conductor del proceso de desarrollo (en el PUD)
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoEjemplo
Cajero automático (CA)
AdministraciónOperador
(f rom Actors)
Extracción
(from Extraccion)
TransferenciaCliente
(f rom Actors)
Depósito
Sistema Central(f rom Actors)
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoDescripción textual (flujo de eventos)
CU Extracción – Camino Estándar
1 Un mensaje de bienvenida está en espera en la pantalla del CA.
2 El cliente inserta su tarjeta en el CA.
3 El CA lee el codigo de la banda magnética y verifica que sea aceptable.
4 Si la tarjeta es aceptable, el CA solicita al cliente su código PIN.
5 El cliente ingresa su código PIN.
6 Si el código PIN es correcto, el CA solicita al cliente el tipo de transacción a realizar.
7 El cliente selecciona <extracción> y el CA envía el código PIN al Sistema bancario
solicitando los datos de la cuenta del cliente.
8 Los datos de la cuenta recibidos se despliegan en la pantalla.
9 El cliente selecciona una cuenta y el monto a extraer.
10 El CA envia al sistema bancario el requerimiento de extracción.
11 El CA preparan los billetes a ser dispensados.
12 El CA imprime el comprobante del movimiento.
13 Los billetes son dispensados al cliente.
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoDescripción textual (completa)
RF- <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>
Autores <autor>
Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
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>
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 RF-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 RF-x>
3
4
5
6
Secuencia Normal
n
Postcondición <postcondición del caso de uso>
Paso Acción 1 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 RF-x>, a continuación este caso de uso {continua, aborta}
2
Excepciones
3
Rendimiento Paso Cota de tiempo
1 n segundos
2 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>
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoRelaciones
Inclusión
Secuencias comunes a varios casos de uso
Procesar Tarjeta
Extracción Transferencia Depósito
<<include>>
<<include>>
<<include>>
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoRelaciones
Extensión:
Partes opcionales de un caso de uso
Extracción
Estadística
Extracción
Monitoreo
Extracción
<<extend>> <<extend>>
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoRelaciones
Generalización:
Distintas variantes de un caso de uso. (“es un tipo de”)
Extracción
Extracción Pesos Extracción Dólares
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Casos de UsoEjemplo
«»
«»
Hacer Pedido
<<extend>>
«»
«»
Silicitar
Catálogo
«»
«»
Suministro de
datos de
clientes
<<include>>
«»
«»
Pedir Producto
<<include>>
«»
«»
Pagar
<<include>>
«»
«»
Pagar al
contado
«»
«»
Acordar
Crédito
Ingeniería del Software de Gestión www.kybele.es
Vista de Interacción
Representa como interactúan cooperativamente los objetos para implementar el comportamiento definido por los casos de uso
Colaboración Interacción entre un conjunto de objetos para implementar un
comportamiento del sistema. Una colaboración <<realiza>> la funcionalidad definida en un
casos de uso
Interacción Una interacción es un conjunto de mensajes que se intercambian
dentro del contexto de una colaboración por instancias de clases (objetos) a través de enlaces (instancias de asociación)
Ingeniería del Software de Gestión www.kybele.es
Vista de InteracciónDiagramas de Secuencia
Énfasis en la secuencia cronológica de los mensajes
: Encargado:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
Ingeniería del Software de Gestión www.kybele.es
Vista de InteracciónDiagramas de Colaboración
Énfasis en la distribución física y relaciones de los objetos
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo5: entregar recibo
Ingeniería del Software de Gestión www.kybele.es
Vista de Máquina de Estados
Describe el comportamiento dinámico de los objetos, modelando su ciclo de vida: Autómatas finitos con estados y transiciones
Cada objeto se trata en forma aislada, el que se comunica con el resto del mundo detectando eventos y respondiendo a ellos.
Es útil modelar solo para objetos con comportamiento estado-dependiente
Uso de Diagramas de Transición de Estados (DTE)
Ingeniería del Software de Gestión www.kybele.es
Diagramas de Transición de Estados
Cada objeto está en un estado en cierto instante El estado describe un período de tiempo caracterizado por:
Conjunto de valores de atributos y relaciones del objeto Período de tiempo durante el que se espera que ocurra un evento Período de tiempo durante el cual el objeto realiza una actividad
El estado en el que se encuentra un objeto determina su comportamiento
Cada objeto sigue el comportamiento descrito en el diagrama de transición de estados asociado a su clase
La transición entre estados es instantánea y se debe a la ocurrencia de un evento
Ingeniería del Software de Gestión www.kybele.es
Estados y Transiciones
Diagramas de Transición de Estados
A B
Evento [condición] / Acción
El evento se considera instantáneo
Ingeniería del Software de Gestión www.kybele.es
Diagramas de Transición de Estados
Ejemplo: Pila (TAD)
Pila
Vacía
Pila no vacía
ni llena
Pila
llena
evento (cond)
acción
push
borrar pila
crear pila pop
error
pop (size > 1)
push (size+1 <> full)
borrar pila
borrar pila
push (size+1 = full)
push
error
pop
pop (size = 1)
Ingeniería del Software de Gestión www.kybele.es
Diagramas de Transición de EstadosEventos
Acontecimiento significativo que tiene localización en tiempo y espacio
No tiene duración. Instantáneo
Tipo de eventos Señal: comunicación asíncrona entre objetos
Llamada: invocación sincrónica de método del objeto que recibe el evento
Cambio: satisfacción de una condición lógica que depende de valores de un atributo
Tiempo: instante absoluto, o lapso transcurrido
Pueden modelarse con clases y jerarquías
Ingeniería del Software de Gestión www.kybele.es
Diagramas de Transición de EstadosEventos
Ingeniería del Software de Gestión www.kybele.es
Diagramas de Transición de EstadosAcciones
Una acción es un cómputo atómico y breve:
una sentencia de asignación
una operación aritmética
el envío de una señal a otro objeto
la invocación de una operación propia
asignación de valores de retorno
creación o destrucción de objetos
una secuencia de acciones simples
Acciones específicas de entrada, salida, durante, un estado o por un evento
estado A
entry: acción por entrar
exit: acción por salir
do: acción mientras en estado
on evento: acción
Ingeniería del Software de Gestión www.kybele.es
Diagramas de Transición de EstadosEstados Compuestos
Ingeniería del Software de Gestión www.kybele.es
Vista de Actividades
Variante de la máquina de estados para modelar flujos de trabajo
Utilización de diagramas de actividad Caso particular de los diagramas de estado
Los estados representan estados de actividad no de un objeto
Ingeniería del Software de Gestión www.kybele.es
Diagrama de ActividadesElementos
Ingeniería del Software de Gestión www.kybele.es
Diagrama de ActividadesCalles y flujo de objetos
Ingeniería del Software de Gestión www.kybele.es
Vista de Implementación
Tipo de vista “física”
Modela el empaquetado físico del sistema en unidades reutilizables llamadas “componentes” Componente una unidad física de implementación con interfaces
definidas pensada para ser utilizada como parte reemplazable del sistema.
Cada componente implementa una o más clases del diseño
Incluyen código fuente, binario, o ejecutable
Los componentes se vinculan por relaciones de dependencia
Se utilizan diagramas de componentes
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Componentes (UML 1.5)
Ingeniería del Software de Gestión www.kybele.es
Vista de Despliegue
Modela la disposición física de los recursos de ejecución computacional
Nodo: es un objeto físico de ejecución que representa un recurso computacional. Pueden tener estereotipos (CPU, memorias, disco duro, etc.)
Las asociaciones entre nodos representan líneas de comunicación.
Se representa con diagramas de despliegue
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Despliegue
Ingeniería del Software de Gestión www.kybele.es
Diagrama de Despliegue
Cliente
APP
Server
DB Server
**
**
* Web Browser
* Servlets
* JSP
* JDBC
Ingeniería del Software de Gestión www.kybele.es
Vista de Gestión
La Vista de Gestión del modelo está compuesta por paquetes y relaciones de dependencia entre paquetes
Paquete: es una unidad de organización del modelo
Los paquetes ofrecen un mecanismo general para la organización de los modelos / subsistemas agrupando elementos de modelado
Los paquetes contienen elementos del modelo como clases, diagramas de casos de uso, interacciones, etc.
Los paquetes también pueden contener otros paquetes
Ingeniería del Software de Gestión www.kybele.es
Vista de Gestión
Todos los elementos del modelo deben pertenecer a un paquete
Los paquetes pueden organizarse según el criterio del diseñador: Por la vista (estática, casos de uso, etc.)
Por subsistema
Por etapa del ciclo de desarrollo.
Una buena organización refleja la arquitectura de alto nivel del sistema.
Ingeniería del Software de Gestión www.kybele.es
Vista de Gestión
Modelo vs. Subsistema
Un modelo es un paquete que abarca una descripción completa de una vista particular de un sistema. Proporciona una descripción cerrada de un sistema a partir de un punto de vista. P. ej.: modelo de análisis, de diseño, de implementación
Un subsistema es un paquete que tiene piezas separadas de especificación y de realización. Representa una partición del sistema P. ej.: subsistema de transacciones, de gestión de datos
Ingeniería del Software de Gestión www.kybele.es
Vista de Gestión
Dependencias de acceso / importación: Todas las clases 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
Ingeniería del Software de Gestión www.kybele.es
Vista de Gestión
Dependencias de acceso / importación: La dependencia de acceso no modifica el espacio de nombres del cliente.
Solo concede permiso para establecer referencias
La dependencia de importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como sinónimos de los caminos completos
Ingeniería del Software de Gestión www.kybele.es
4+1 vistas de P. Kruchten
Vista Lógica
Vista de Procesos
Vista de Distribución
Vista deRealización
Vista de los Casos de Uso
Ingeniería del Software de Gestión www.kybele.es
Ciclo de Vida en el PUD
Ingeniería del Software de Gestión www.kybele.es
Ciclo de Vida en el PUD
Ingeniería del Software de Gestión www.kybele.es
Ciclo de Vida en el PUD
Ingeniería del Software de Gestión www.kybele.es
Ciclo de Vida en el PUD
Ingeniería del Software de Gestión www.kybele.es
Bibliografía
Título Autor ISBN
El Lenguaje Unificado de Modelado
Manual de Referencia
James Rumbaugh 8478290370
El Lenguaje Unificado de Modelado
Guía del Usuario
Grady Booch 8478290281
UML Gota a gota Martin Fowler 9684443641
UML y Patrones Craig Larman 8420534382
http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml