UML

IN73J – Arquitectura, Diseño y

Construcción de un Negocio con
Apoyo TI

Carlos Reveco D.
creveco@dcc.uchile.cl
 Contenido

I. Introducción
– Modelado de Software
– UML
Construcción de una casa para “Cachupin”

Puede hacerlo una sola persona

Requiere:
Modelado mínimo
Proceso simple
Herramientas simples

Fuente: “Software Architecture and UML” de Grady Booch (Rational Software).

 Construcción de una casa

Construida eficientemente y en un
tiempo
razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas

Fuente: “Software Architecture and UML” de Grady Booch (Rational Software).

 Construcción de un rascacielos

Fuente: “Software Architecture and UML” de Grady Booch (Rational Software).

 Objetivo
6

“El modelado captura las

partes esenciales del sistema”

Orden

Item

envío

Proceso de Negocios

Sistema Computacional
Que Rol Cumple la arquitectura y BPMN en UML
7

 BPMN Modela el negocio.

 UML especifica requerimientos de Software.

 BPMN trata de disminuir la Brecha entre estos 2

mundos
 ¿Qué es UML?

▪ UML = Unified Modeling Language

▪ Un lenguaje de propósito general para el modelado
orientado a objetos. Impulsado por el Object
Management Group (OMG, www.omg.org)
▪ Documento “OMG Unified Modeling Language
Specification”
▪ UML combina notaciones provenientes desde:
 Modelado Orientado a Objetos
 Modelado de Datos
 Modelado de Componentes
 Modelado de Flujos de Trabajo (Workflows)
 Situación de Partida

▪ Diversos métodos y técnicas OO, con muchos aspectos en

común pero utilizando distintas notaciones
▪ Inconvenientes para el aprendizaje, aplicación,
construcción y uso de herramientas, etc.
▪ Pugna entre distintos enfoques (y correspondientes
gurús)

Objetivo: Establecer una notación estándar

Historia UML
10
 UML

 El Lenguaje de Modelamiento Unificado (UML -

Unified Modeling Language)
 Lenguaje gráfico para visualizar, especificar y
documentar cada una de las partes que comprende
el desarrollo de software.
 Entrega una forma de modelar cosas conceptuales
como lo son procesos de negocio .
 Participación de metodólogos influyentes
 Participación de importantes empresas
 Estándar del OMG
 UML
12
• Diagrama de casos de uso
Modelado de
requerimientos
• Diagrama de clases
Modelado de la estructura • Diagrama de objetos

• Diagrama de secuencias
Modelado de la interacción • Diagrama de colaboraciones

• Diagrama de estados
Modelado del
• Diagrama de actividades
comportamiento
• Diagrama de componentes
Herramientas de diseño • Diagrama de despliegue

• Diagrama de paquetes
Organización del modelo
 Organización de Modelos

4+1 vistas de Kruchten (1995)

Vista de
Vista Lógica
Realización
Vista de los
Casos de Uso

Vista de Vista de

Procesos Distribución

Este enfoque sigue el browser de Rational Rose

 ... Organización de Modelos

Propuesta de Rational Unified Process (RUP)

▪ M. de Casos de Uso del Negocio (Business Use-Case Model)
▪ M. de Objetos del Negocio (Business Object Model)
▪ M. de Casos de Uso (Use-Case Model)
▪ M. de Análisis (Analysis Model)
▪ M. de Diseño (Design Model)
▪ M. de Despliegue (Deployment Model)
▪ M. de Datos (Data Model)
▪ M. de Implementación (Implementation Model)
▪ M. de Pruebas (Test Model)
 Organización de Modelos
15

 Propuesta Barros
 Modelo de negocio y Pocisionamiento estrategica

 Arquitectura Macroprocesos

 Sub-procesos

 Actividades en BPMN

 Diagrama de Paquetes

 Diagrama Casos de Usos

 Diagrama de Clases

 Diagrama de Secuencia
 Diagrama de Paquetes

▪ Los paquetes ofrecen un mecanismo general para la

organización de los modelos/subsistemas agrupando
elementos de modelado

▪ Se representan gráficamente como:

Nombre de
paquete
 Diagrama de Paquetes

▪ Cada paquete corresponde a un submodelo

(subsistema) del modelo (sistema)

▪ Un paquete puede contener otros paquetes, sin

límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete

▪ Una clase de un paquete puede aparecer en otro

paquete por la importación a través de una relación
de dependencia entre paquetes
 Diagrama de Paquetes

▪ Todos los elementos no son

necesariamente visibles desde el
exterior del paquete, es decir, un
paquete encapsula a la vez que
agrupa

▪ El operador “::” permite designar

una clase definida en un contexto
distinto del actual
 Diagrama de Paquetes
19

 Permite administrar la complejidad del sistema al

subdividirlo en porciones de menor tamaño

 Se pueden aplicar a diferentes elementos de

modelado, no sólo a clases

 Permite establecer las dependencias entre paquetes

(que no son de carácter transitivo) a fin de reducirlas

 También permite reducir los bucles de dependencias

Diagrama de Paquetes
 Diagrama de Casos de Uso
21

 ¿Qué es un Caso de Uso?

“Descripción de un conjunto de secuencias de acciones

que un sistema ejecuta y que produce un resultado
observable de interés para un actor particular”
 Diagrama de Casos de Uso

▪ Casos de Uso es una técnica para capturar información

respecto de los servicios que un sistema proporciona a su
entorno

▪ No pertenece estrictamente al enfoque orientado a objeto,

es una técnica para captura y especificación de requisitos
 Diagrama de Casos de Uso
23

 Actor:
 Una definición previa, es que un Actor es un rol que
un usuario juega con respecto al sistema. Es
importante destacar el uso de la palabra rol, pues con
esto se especifica que un Actor no necesariamente
representa a una persona en particular, sino más
bien la labor que realiza frente al sistema.
 Diagrama de Casos de Uso
24

 Caso de Uso:
 Es una operación/tarea específica que se realiza tras
una orden de algún agente externo, sea desde una
petición de un actor o bien desde la invocación desde
otro caso de uso.
 Diagrama de Casos de Uso
25

 Asociación Es el tipo de relación más básica que

indica la invocación desde un actor o caso de uso a
otra operación (caso de uso). Dicha relación se
denota con una flecha simple.

 Dependencia o Instanciación Es una forma muy

particular de relación entre clases, en la cual una
clase depende de otra, es decir, se instancia (se crea).
Dicha relación se denota con una flecha punteada.
 Diagrama de Casos de Uso
26

 Generalización Este tipo de relación es uno de los

más utilizados, cumple una doble función
dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o de Herencia (<<extends>>).
 Este tipo de relación esta orientado exclusivamente
para casos de uso (y no para actores)
 Diagrama de Casos de Uso
27

 extends: Se recomienda utilizar cuando un caso de

uso es similar a otro (características).
 uses: Se recomienda utilizar cuando se tiene un
conjunto de características que son similares en más
de un caso de uso y no se desea mantener copiada la
descripción de la característica.
 De lo anterior cabe mencionar que tiene el mismo
paradigma en diseño y modelamiento de clases, en
donde esta la duda clásica de usar o heredar.
 Ejemplos

Ejemplo:

Retirar dinero

Consultar Extracto
Cliente

Realizar transferencia
 Diagrama de Clases

▪ El Diagrama de Clases es el diagrama principal para el

análisis y diseño del sistema

 Un diagrama de clases presenta las clases del sistema

con sus relaciones estructurales y de herencia
▪ La definición de clase incluye definiciones para
atributos y operaciones

▪ El modelo de casos de uso debería aportar

información para establecer las clases, objetos,
atributos y operaciones
 Diagrama de Clases
30

 Un diagrama de clases esta compuesto por los

siguientes elementos:
 Clase: atributos, métodos y visibilidad.
 Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.
 Diagrama de Clases
31

 Clase: s la unidad básica que encapsula

toda la información de un Objeto
 Superior: Contiene el nombre de la Clase
 Intermedio: Contiene los atributos (o
variables de instancia) que caracterizan a la
Clase (pueden ser private, protected o public).
 Inferior: Contiene los métodos u
operaciones, los cuales son la forma como
interactúa el objeto con su entorno
(dependiendo de la visibilidad: private,
protected o public).
 Diagrama de Clases
32

 Relaciones
 uno o muchos: 1..* (1..n)

 0 o muchos: 0..* (0..n)

 número fijo: m (m denota el número).

 Herencia
 Agregación
 Asociación
 Dependencia o Instanciación (uso):

 Clase Abstracta
 Diagrama de Clases
33
 Relaciones
 Herencia (Especialización
/ Generalización): Indica
que una subclase hereda los
métodos y atributos
especificados por una Super
Clase, por ende la Subclase
además de poseer sus propios
métodos y atributos, poseerá
las características y atributos
visibles de la Super Clase
(public y protected),
 Diagrama de Clases
34
 Agregación
 Cuando se requiere
componer objetos que son
instancias de clases
definidas por el
desarrollador de la
aplicación, tenemos dos
posibilidades:
 Por Valor
 Por Referencia
 Diagrama de Clases
35
 Asociación
 La relación entre clases
conocida como
Asociación, permite
asociar objetos que
colaboran entre si. Cabe
destacar que no es una
relación fuerte, es decir,
el tiempo de vida de un
objeto no depende del
otro.
 Diagrama de Clases
36
 Dependencia o
Instanciación (uso)
 Representa un tipo de
relación muy particular,
en la que una clase es
instanciada (su
instanciación es
dependiente de otro
objeto/clase). Se denota
por una flecha punteada.
 Diagrama de Clases
37
 Clase Abastracta
 Una clase abstracta se denota
con el nombre de la clase y de
los métodos con letra
“cursiva". Esto indica que la
clase definida no puede ser
instanciada pues posee
métodos abstractos (aún no
han sido definidos, es decir,
sin implementación). La única
forma de utilizarla es
definiendo subclases, que
implementan los métodos
abstractos definidos.
 Diagrama de Clases
38

 Pasos recomendados:
 Elaborar una lista de clases candidatas detectar clases con
diferentes niveles de abstracción
 Definir las clases y colocarles sus atributos y comportamientos

 Elegir la clase más representativa y colocarla en el centro del

modelo
 Asociar una a una el resto de las clases

 Determinar multiplicidad y condicionalidad

 Incorporar clases asociativas

 Incorporar agregación y generalización

 Verificar y validar el modelo contra los requerimientos

 Diagrama de Secuencia
39

 El diagrama de interacción, representa la forma en

como un Cliente (Actor) u Objetos (Clases) se
comunican entre si en petición a un evento. Esto
implica recorrer toda la secuencia de llamadas, de
donde se obtienen las responsabilidades claramente.
 Dicho diagrama puede ser obtenido de dos partes,
desde el Diagrama Estático de Clases o el de Casos de
Uso (son diferentes).
 Diagramas de Secuencia
40

 Es uno de los dos diagramas de interacción que se

propone en UML.
 Describe la forma en la que colaboran entre sí los
objetos para llevar a cabo sus respectivas
responsabilidades.
 Cada diagrama representa la funcionalidad de un
único caso de uso.
 Permite ver cómo se suceden cronológicamente los
mensajes entre los objetos.
 Diagramas de Secuencia
41
 Elementos
 Objeto/Actor:
 El rectángulo representa
una instancia de un
Objeto en particular, y la
línea punteada
representa las llamadas a
métodos del objeto.
 Diagramas de Secuencia
42
 Mensaje a Otro
Objeto:
 Se representa por una
flecha entre un objeto y
otro, representa la
llamada de un método
(operación) de un objeto
en particular.
 Diagramas de Secuencia
43
 Mensaje al Mismo
Objeto:
 No solo llamadas a
métodos de objetos
externos pueden
realizarse, también es
posible visualizar
llamadas a métodos
desde el mismo objeto en
estudio.
Diagramas de Secuencia
44

 Mensaje Sincrono

 Mnesaje Asincrono

 Mensaje sincrono con

respuesta nmediata

 mensaje simple
 Diagrama de Secuencia

:WInPréstamos :Socio :Video :Préstamo

: Encargado

prestar(video, socio)
verificar situación socio

verificar situación video

registrar préstamo

entregar recibo
 Ejercicio Casos de Uso
46

 Como ejemplo esta el caso de una Máquina Recicladora:

 Sistema que controla una máquina de reciclamiento de botellas, tarros y
jabas. El sistema debe controlar y/o aceptar:
 Registrar el número de ítemes ingresados.
 Imprimir un recibo cuando el usuario lo solicita:
 Describe lo depositado
 El valor de cada item
 Total
 El usuario/cliente presiona el botón de comienzo
 Existe un operador que desea saber lo siguiente:
 Cuantos ítemes han sido retornados en el día.
 Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
 El operador debe además poder cambiar:
 Información asociada a ítemes.
 Dar una alarma en el caso de que:
 Item se atora.
 No hay más papel.
 Ejercicio Casos de Uso
47

 Como una primera aproximación identificamos a los

actores que interactúan con el sistema:
 Ejercicio Casos de Uso
48

 Luego, tenemos que un Cliente puede Depositar

Items y un Operador puede cambiar la información
de un Item o bien puede Imprimir un informe:
 Ejercicio Casos de Uso
49

 Además podemos notar que un item puede ser una

Botella, un Tarro o una Jaba.

 Ejercicio Casos de Uso
50

 Otro aspecto es la impresión de comprobantes, que

puede ser realizada después de depositar algún item
por un cliente o bien puede ser realizada a petición
de un operador.
 Ejercicio Casos de Uso
51

 Entonces, el diseño completo del diagrama Casos de

uso para el ejemplo es:
 Otros Diagramas UML
52

 Diagramas de Colaboracion
 Diagrama de estados
 Diagrama de despliege
 Diagramas de Colaboracion
53

 Es otro de los diagramas de interacción que se

incluye en UML
 No permite observar gráficamente la cronología de
los mensajes
 Facilita la organización de los objetos en paquetes
 Destaca la conexión estática entre los objetos
 Mientras el diagrama de secuencias pone énfasis en
el tiempo, el decolaboración lo hace en el espacio
 Diagrama de Colaboración
:Socio

:Video

2: verificar situación socio

1: prestar(video, socio) 3: verificar situación video

:WInPréstamos

5: entregar recibo
: Encargado 4: registrar préstamo

:Préstamo
 Diagrama de Estados
55

 Describe los estados posibles en la vida de los objetos

 Permite observar cómo cambian de estado los

objetos a medida queocurren los eventos

 Cada diagrama se utiliza para representar el ciclo de

vida de los objetos de una única clase
 Diagrama de Estados

alta baja

número_préstamos = 0
sin préstamos

Socio
número : int
nombre : char[50]
número_prestamos : int = 0
prestar devolver[ número_préstamos = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date) número_préstamos > 0

con préstamos

prestar

devolver[ número_préstamos > 1 ]

 57

 No posee antecedentes claros entre las herramientas de

los autores de UML en sus propios métodos
 Proviene de varias técnicas, como diagramas de eventos
de Odell y redes de Petri
 Permite destacar y sincronizar las operaciones
concurrentes y establecer caminos alternativos
 Muestra el comportamiento combinado de varias clases,
aunque éstas no se identifican si no se lo hace
explícitamente
 Al igual que los diagramas de estado, se emplea para
describir
 Diagrama de Actividad
Buscar Bebida [ no hay café ] [ no zumo ]

[ hay café ]
[ hay zumo ]

Poner café Añadir agua Coger taza

en filtro al depósito Coger
zumo

Poner filtro
en máquina

Encender
máquina

/ cafetera.On

Café en
preparación

indicador de fin

Servir café Beber

 59

 Este diagrama, junto al de despliegue, corresponde al

grupo de herramientas de implementación de UML
 Representa módulos físicos de código
 Es importante que cada componente sea equivalente
a un paquete
 De esta manera, las dependencias entre
componentes con lasmismas que las existentes entre
los paquetes
 Diagrama Componentes

Interfaz de Terminal
Control y Análisis

Gestión de Cuentas Rutinas de conexión Acceso a BD

 Diagrama de Despliegue
61

 Muestra las relaciones entre los componentes de

hardware y software del sistema

 Permite observar dónde se encuentran físicamente

los paquetes en el sistema
 Diagrama de Despliegue
Servidor Central Control y Análisis

Acceso a BD Comment

Comment

Rutinas de Coneccion
Comment

Terminal de Consulta
Interfaz de Terminal
Rutinas de Coneccion
Comment Comment

Punto de Venta
Rutinas de Coneccion
Comment

Gestión de Cuentas Interfaz de Terminal

Comment Comment
 Diagrama de Despliegue en Rational
Control y Análisis

Acceso a BD
Servidor Central
Component Diagram:
Components / Servidor Rutinas de conexión

Central
Servidor Central

Rutinas de conexión
Punto de Venta
Punto de Venta Terminal de
Consulta Gestión de Cuentas Interfaz de Terminal

Terminal de Consulta
Rutinas de conexión Interfaz de Terminal
Component Diagram: Component Diagram:
Components / Punto de Components / Terminal
Venta de Consulta
 Programas
64

 Rational Rose
 IBM Rational
 Dia (Opensource)
 En U-cursos

 StarUML
 En U-cursos

 Manual en U-cursos
 UML

65

IN73J – Arquitectura, Diseño y

Construcción de un Negocio con
Apoyo TI

Carlos Reveco D.
creveco@dcc.uchile.cl
Ejemplos (Clase y Visibilidad)
 … Ejemplos (Asociación)

dirige director
Departamento Profesor
0..1 1
… Ejemplos (Clase Asociación)

empleador trabajadores
Empresa Empleado
* 1..*

Cargo
superior
nombre
sueldo 0..1

subordinado 1..*
… Ejemplos (Generalización)

Trabajador

{ disjunta, completa }

Directivo Administrativo Obrero

 … Ejemplos

Motor Piloto Vendedor de billetes

1..4 1..2 1

1 n
n
1 n 1 n
Avión Vuelo Reserva

n
{ disjunta, completa }

Avión militar Avión comercial Línea aérea

{ disjunta, completa }

Avión de carga Avión de pasajeros