Tema 4b: Introducción a UML

(1)

Tema 4b:

Introducción a UML

Marcos López Sanz

Ingeniería del Software de Gestión

(2)

Índice

 Introducción a UML

 Generalidades y evolución histórica

 Mecanismos de extensión

 Vistas y diagramas

 Ciclo de vida en el PUD

(3)

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

(4)

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

(5)

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

(6)

Características Generales

Modelado

 ¿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 stakeholders del 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.

(7)

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

(8)

Breve evolución histórica

(9)

Influencias

(10)

Participantes en UML 1.0

 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

(11)

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

(12)

 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 UML

Clasificación estructural

(13)

Vistas de UML

Comportamiento 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

(14)

Vistas de UML Gestió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

(15)

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

(16)

Mecanismos de extensión

 Ejemplo

(17)

Áreas, vistas y diagramas

(18)

Á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

(19)

Áreas, vistas y diagramas

 Otra clasificación (UML 2.0)

(20)

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

(21)

Vista estática

Elementos

 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

(22)

Vista estática

Elementos

 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

(23)

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

(24)

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

(25)

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 de

encapsulación)

Visibilidad

+ público

# protegido

- privado

(26)

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

(27)

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

Multiplicidad 0..1 N..M 0..* 3..*

1..* 2..5 1 3..4, 6..*

* Dirección de lectura de la relación

Navegabilidad (uni/bi-direccional)

roles

(28)

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 Num_Butaca Entrada

1 1..*

Presentacion Diapositiva

1 {ordered}

1..*

Cuenta * Persona

or

Empresa

*

(29)

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 Estudiante

1..* 1..*

Universidad Departamento

1 1..*

(30)

Diagrama de clases:

Relaciones entre clases

 Consideraciones sobre la composición

 Una 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

(31)

 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}

Estereotipo

(32)

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

(33)

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() -Num_Placa : int +Apodo

-Puntería -Experiencia

Policia

«interfaz»

MiembroSeguridad

(34)

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

(35)

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

* 1

1 * 1 *

unBanco : Banco

cliente01 : Cliente

cliente02 : Cliente

cta0101 : Cuenta

cta0201 : Cuenta

cta0202 : Cuenta

(36)

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

(37)

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 (Object Oriented Software Engineering)

 Diagramas de Casos de Uso: Actores + Caso de uso

(38)

Diagrama de Casos de Uso

Actor

 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

(39)

Diagrama de Casos de Uso

Caso 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)

(40)

Diagrama de Casos de Uso

Ejemplo

 Cajero automático (CA)

Administración Operador

Extracción

(from Extraccion)

Transferencia Cliente

(f rom Actors)

Depósito

Sistema Central

(f rom Actors)

(41)

Diagrama de Casos de Uso

Descripció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.

(42)

Diagrama de Casos de Uso

Descripció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}

(43)

Diagrama de Casos de Uso

Relaciones

 Inclusión

 Secuencias comunes a varios casos de uso

Procesar Tarjeta

Extracción Transferencia Depósito

<<include>>

(44)

Diagrama de Casos de Uso

Relaciones

 Extensión:

 Partes opcionales de un caso de uso

Extracción

Estadística Extracción

Monitoreo Extracción

<<extend>> <<extend>>

(45)

Diagrama de Casos de Uso

Relaciones

 Generalización:

 Distintas variantes de un caso de uso. (“es un tipo de”)

Extracción

Extracción Pesos Extracción Dólares

(46)

Diagrama de Casos de Uso

Ejemplo

«» «»

Hacer Pedido

<<extend>> «» «»

Silicitar Catálogo

«» «»

Suministro de datos de

clientes

<<include>>

«» «»

Pedir Producto

<<include>>

«» «»

Pagar

<<include>>

«» «»

Pagar al contado

«» «»

Acordar

Crédito

(47)

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)

(48)

Vista de Interacción

Diagramas 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

(49)

Vista de Interacción

Diagramas 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éstamo

5: entregar recibo

(50)

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)

(51)

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

(52)

 Estados y Transiciones

Diagramas de Transición de Estados

A B

Evento [condición] / Acción

El evento se considera instantáneo

(53)

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

pop

pop (size = 1)

(54)

Diagramas de Transición de Estados

Eventos

 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

(55)

Diagramas de Transición de Estados

Eventos

(56)

Diagramas de Transición de Estados

Acciones

 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

(57)

Diagramas de Transición de Estados

Estados Compuestos

(58)

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

(59)

Diagrama de Actividades

Elementos

(60)

Diagrama de Actividades

Calles y flujo de objetos

(61)

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

(62)

Diagrama de Componentes (UML 1.5)

(63)

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

(64)

Diagrama de Despliegue

(65)

Diagrama de Despliegue

Cliente

APP Server

DB Server

* *

* Web Browser

* Servlets

* JSP

* JDBC

(66)

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

(67)

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.

(68)

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

(69)

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

(70)

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

(71)

4+1 vistas de P. Kruchten

Vista Lógica

Vista de

Procesos Vista de

Distribución Vista de Realización Vista de los

Casos de Uso

(72)

Ciclo de Vida en el PUD

(73)

Ciclo de Vida en el PUD

(74)

Ciclo de Vida en el PUD

(75)

Ciclo de Vida en el PUD

(76)

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