UML

Necesidad modelado
Diagramas de clase
Diagramas de secuencia
Casos de uso

UML
Necesidad modelado
Use cases
Diagramas de clase
Diagramas de secuencia

Objetivos al desarrollar
software
Satisfacer las necesidades de los
usuarios.
Entregar el software en tiempo y
con un costo predecible.
Comprender mejor el sistema que se
est construyendo.

Acciones para alcanzar los

objetivos

Realizar una buena elicitacin de

requerimientos.

Desarrollar un modelo del sistema.

Que es un modelo?
Simplificacin de la realidad.
Incluir
los elementos que son
importantes y omitir los elementos
que no son relevantes para ese nivel
de abstraccin.

Que es un modelo?
Diferentes modelos
Modelos estructurales
Modelos de comportamiento

Construccin de una casa para

fido

Puede hacerlo una sola persona

Requiere:
Modelado mnimo
Proceso simple
Herramientas simples

Construccin de una casa

Construida eficientemente y en un tiempo

razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas ms sofisticadas
8

Claves en Desarrollo de SI
Notacin

Herramientas

Proceso

Abstraccin - Modelado Visual

(MV)
El modelado captura las
partes esenciales del sistema
Orden
Item

envo

Proceso de Negocios
Sistema Computacional
10

MV promueve la
reutilizacin
Mltiples Sistemas

Componentes
Reutilizados

11

MV para definir la Arquitectura

del SW
Interfaz de Usuario
(Visual Basic,
Java, ..)

Lgica del Negocio

(C++, Java, ..)

Servidor de BDs
(C++ & SQL, ..)

Modelar el sistema independientemente

del lenguaje de implementacin
12

Etapas en la construccin
de un proceso de software

Qu es lo que va a construir?

Cmo lo va a construir?

Qu tecnologa usar?

Cmo lo documentar?
13

Etapas en la construccin
de un proceso de software
Anlisis
Diseo
Refinamiento del diseo
Implementacin
Documentacin

14

Requerimientos Funcionales
Los requerimientos/requisitos de un
sistema describen los servicios que
ha de ofrecer el sistema y las
restricciones asociadas a su
funcionamiento.
Requerimientos:
Propiedades o restricciones
determinadas de forma precisa que
deben satisfacerse.

15

Requerimientos funcionales:
Expresan la naturaleza del
funcionamiento del sistema (cmo
interacciona el sistema con su entorno
y cules van a ser su estado y
funcionamiento).

Importante: A veces, tambin es

conveniente indicar lo que no har
el sistema.

16

Requerimientos no funcionales:
Restricciones sobre el espacio de
posibles soluciones.

Rendimiento del sistema:

Fiabilidad, tiempo de respuesta,
disponibilidad
Interfaces: Dispositivos de E/S,
usabilidad, interoperabilidad
Proceso de desarrollo: Estndares,
herramientas, plazo de entrega
17

Requerimientos Funcionales y
Requerimientos No Funcionales
Los requisitos funcionales definen
qu debe hacer un sistema.

Los requisitos no funcionales definen

cmo debe ser el sistema.

18

Requerimientos No
Funcionales
A los requisitos no funcionales se les
suele llamar coloquialmente
cualidades del sistema [-ilities en
ingls] y pueden dividirse en dos
categoras:

Cualidades de ejecucin, como la seguridad o la

usabilidad, observables en tiempo de ejecucin.
Cualidades de evolucin,
como la testabilidad, mantenibilidad, extensibilidad o
escalabilidad, determinadas por la estructura esttica del
software.
19

Como especificar los

Requerimientos
Los requerimientos
se suelen especificar en lenguaje
natural,
se expresan de forma individual
(p.ej. esquemticamente),
se organizan de forma jerrquica
(a distintos niveles de detalle),
a menudo, se numeran (para facilitar
su gestin),
20

Los requerimientos han

de ser
claros y concretos
(evitando imprecisiones y
ambigedades) p.ej. Uso de puntos
suspensivos, etctera
concisos
(sin rodeos ni figuras retricas),
completos y consistentes,

21

Los requerimientos han

de indicar
lo que se espera que haga el
sistema (qu?),
su justificacin
(por qu ha de ser as? quin lo
propuso?) y,
en su caso, los criterios de
aceptacin que sean aplicables
(cmo se verifica su
cumplimiento?).
22

Los requerimientos funcionales

deben estar redactados de tal forma

que sean comprensibles para usuarios
sin conocimientos tcnicos avanzados
(de Informtica, se entiende),
deben especificar el comportamiento
externo del sistema y evitar, en la
medida de lo posible, establecer
caractersticas de su diseo,
deben priorizarse (al menos, se ha de
distinguir entre requisitos obligatorios
23
y requisitos deseables).

Los requerimientos no
funcionales

han de especificarse
cuantitativamente, siempre que sea
posible (para que se pueda verificar
su cumplimiento).

24

Ejemplos:
MAL
Para facilitar el uso del editor grfico, se podr activar y
desactivar una rejilla que permitir alinear las figuras del
diagrama. Cuando se ajuste la figura al tamao de la
pantalla, se reducir el nmero de lneas de la rejilla para
que no se dificulte la visualizacin del diagrama.

Por qu?
Amalgama de varios requisitos.

25

Ejemplos:
BIEN
El editor permitir el uso de una rejilla de lneas horizontales
y verticales que aparecern dibujadas tras el diagrama.

Justificacin: La rejilla facilita la creacin de diagramas

cuidados en los que las figuras se puedan alinear con
facilidad (Manual Prctico de Usabilidad, seccin 15.3).

Por qu?
Preciso, conciso y justificado correctamente.

26

Ejemplos:

MAL

El sistema ser lo ms fcil de utilizar posible.

El sistema proporcionar una respuesta rpida al usuario.
El sistema se recuperar automticamente tras producirse un
fallo.
Por qu?
Objetivos generales, vagos y abiertos a distintas
interpretaciones.

27

Ejemplos:

BIEN

Un usuario experimentado debe ser capaz de

utilizar todas las funciones del sistema tras un
entrenamiento de 2 horas, tras el cual no cometer
ms de 3 errores diarios en media.
Cuando haya hasta 100 usuarios accediendo
simultneamente al sistema, su tiempo de
respuesta no ser en ningn momento superior a 2
segundos.

28

Ejemplos:
BIEN
Ante un fallo en el software del
sistema, no se tardar ms de 5
minutos en restaurar los datos del
sistema (en un estado vlido) y volver
a poner en marcha el sistema.
Por qu?
Requisitos verificables.
29

Qu problemas se pueden Presentar:

En la elaboracin de Requerimientos?
La existencia de un requerimiento ha de
estar debidamente justificada (debemos
saber por qu es un requisito del sistema).
Un requerimiento es, a veces, difcil de
verificar (especialmente, si es un requisito
no funcional). Adems, si somos incapaces
de especificarlo, cmo sabemos que
realmente es un requisito?
30

EJEMPLO: REQUERIMIENTOS FUNCIONALES

Matriculacin

La matrcula ser realizada de forma interactiva. Se le

preguntar al alumno cul es el plan de estudios en que
desea matricularse (pueden ser varios).
Se podr generar una copia impresa de la matrcula (sin
valor oficial) en el ordenador desde donde se realice el
proceso de matriculacin.
Se podr generar el impreso de pago debidamente
cumplimentado.
Para la matriculacin se consultarn los datos del expediente
y se realizarn las validaciones necesarias, descritas a
continuacin
31

EJEMPLO: REQUERIMIENTOS FUNCIONALES

Pago de matrcula:

La aplicacin generar un impreso para que el

alumno realice el pago correspondiente a la
matrcula en 1 2 plazos (segn las fechas
establecidas).
Si el alumno tiene matrculas de honor de cursos
anteriores o disfruta de algn tipo de beca, la
aplicacin deber calcular automticamente los
descuentos correspondientes
Organizados jerrquicamente
y desglosados en requisitos individuales
32

EJEMPLO: REQUERIMIENTOS NO
FUNCIONALES
Interfaces
Hardware: El sistema se debe implementar
sobre la infraestructura existentes en
y las
so
i
c
aulas de prcticas de la Materia
n de Analisis
o
C
,
s
de Sistemas.
to
e
r
nc
o
C
Software:
,
s
ro
a
l
No existeitoposibilidad
de adquirir licencias de
sC
is les
u
q
software.
Re
cab
fi
i
r
ve

La aplicacin deber funcionar sobre Oracle.

33

Tabal de Requerimientos (Ficha)

Nombre Requerimiento:
ID Requerimiento:

Ingreso Usuarios
RF-001

Entradas:

Usuario y Contrasea

Salidas:

El usuario Ingresa al sistema

El usuario recibe mensaje de Error

Prerrequisito:

No aplica

Opciones:

Ingresar , Cancelar

Restricciones:

Los dos campos son obligatorios

El usuario debe estar creado en el sistema

Descripcin del proceso

El usuario ingresa al sistema mediante autenticacin, usuario y contrasea, el sistema valida si los datos
estn correctos, si estn errados presenta en la pantalla un mensaje de error, si son vlidos ingresa a la
aplicacin y se activan las formas y opciones asignadas segn el perfil.

34

UML
Es una notacin grfica
modelar.
Es un lenguaje de modelado.

35

para

UML aglutina enfoques OO

Rumbaugh
Booch

Jacobson

Odell

Meyer
Pre- and Post-conditions

Shlaer-Mellor
Object life cycles

UML
Harel

State Charts

Gamma et. al.

Frameworks, patterns,
notes

Embly

Singleton classes

Wirfs-Brock
Fusion

Responsabilities

Operation descriptions,
message numbering

36

II. Breve Tour por UML

... Diagramas de UML

Los diagramas expresan grficamente partes de un modelo

Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Secuencia

Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Casos de Uso

Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Colaboracin
Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Estados

State
State
Diagramas de
Diagrams
Diagrams
Clases

Modelo

Diagramas de
Actividad

State
State
Diagramas de
Diagrams
Diagrams
Objetos
State
State
Diagramas de
Diagrams
Diagrams
Componentes

Component
Component
Diagrams
Diagramas
Diagrams de

Distribucin

37

... Diagramas seleccionados

Diagramas de
Secuencia

Diagramas de
Casos de Uso

Diagramas de
Clases

38

Modelos y Diagramas

Un

modelo

captura

una

vista

de

un

sistema del mundo real. Es una abstraccin

de dicho sistema, considerando un cierto
propsito.

As,

completamente

el

modelo

aquellos

describe

aspectos

del

sistema que son relevantes al propsito del

modelo, y a un apropiado nivel de detalle.

39

Modelos y Diagramas

Diagrama: una representacin grfica de

una coleccin de elementos de modelado.

40

... Modelos y Diagramas

Un proceso de desarrollo de software debe
ofrecer un conjunto de modelos que permitan
expresar el producto desde cada una de las
perspectivas de inters
El cdigo fuente del sistema es el modelo ms
detallado del sistema (y adems es ejecutable).
Sin embargo, se requieren otros modelos ...

41

UML
Necesidad modelado
Casos de uso
Diagramas de clase
Diagramas de secuencia

42

Casos de Uso
Un caso de uso es una interaccin
entre el usuario y el sistema para
lograr cierto objetivo.
Objetivo de los mismos.
Son de tamao variable.
Se debe especificar todos los cursos
alternativos.

43

 Casos de Uso
Actores:

Roles de los usuarios

Otros sistemas: sistemas con los que el

sistema interacta (el otro sistema
necesita algo del sistema que se
desarrolla)

44

Ejemplos

Supervisor

Administrativo

Verificar Situacin del Cliente

Preparar Catlogo

Sistema
Inventario

45

III. El Paradigma OO: Diagrama de Casos de Us

Casos de Uso
Ejemplo:

Actor A

Caso de Uso A

Caso de Uso B

Actor B

46

 Casos de Uso

Identificacin de casos de usos

Eventos ante los cuales se debe
reaccionar
Actores que intervienen

47

 Casos de Uso

Representacin de escenarios
alternativos

48

 Ejemplos

Venta Normal
Ventas

Venta en Rebajas
Venta en Ofertas

Vendedor

49

Casos de Uso
Los Casos de Uso (Ivar Jacobson)
describen bajo la forma de acciones y
reacciones el comportamiento de un
sistema desde el p.d.v. del usuario
Permiten definir los lmites del sistema y
las relaciones entre el sistema y el entorno
Los Casos de Uso son descripciones de la
funcionalidad del sistema independientes
de la implementacin
50

 Casos de Uso
Los Casos de Uso se determinan observando y
precisando, actor por actor, las secuencias de
interaccin, los escenarios, desde el punto de
vista del usuario
Un escenario es una instancia de un caso de uso
Los casos de uso intervienen durante todo el
ciclo de vida. El proceso de desarrollo estar
dirigido por los casos de uso

51

Casos de Uso: Relaciones

UML define tres tipos de relacin en los
Diagramas de Casos de Uso:
Comunicacin

Actor

Caso de Uso

52

III. El Paradigma OO: Diagrama de Casos de Us

Casos de Uso: Relaciones

Inclusin(uses)

: una instancia
del Caso de Uso origen incluye
tambin
el
comportamiento
descrito por el Caso de Uso destino
<<include>>

Caso de Uso Origen

Caso de Uso Destino

<<include>> reemplaz al
denominado <<uses>>

53

 Casos de Uso: Relaciones

Extensin

: el Caso de Uso origen

extiende el comportamiento del
Caso de Uso destino
<<extend>>

Caso de Uso Origen

Caso de Uso Destino

54

 Casos de Uso: Relaciones

Ejemplo:
<<include>>

Cliente

Identificacin

Transferencia

<<extend>>

Transferencia en Internet

55

Casos de Uso: Construccin

Un caso de uso debe ser
inteligible, claro y conciso
Generalmente
hay
pocos
asociados a cada Caso de Uso

56

simple,
actores

Casos de Uso: Construccin

Preguntas clave:
cules

son las tareas del actor?

qu informacin crea, guarda,
modifica, destruye o lee el actor?
debe el actor notificar al sistema
los cambios externos?
debe el sistema informar al actor
de los cambios internos?
57

 Casos de Uso:
Construccin
La descripcin del Caso de Uso
comprende:
el inicio: cundo y qu actor lo
produce?
el fin: cundo se produce y qu valor
devuelve?
la interaccin actor-caso de uso: qu
mensajes intercambian ambos?
58

 Casos de Uso:
Construccin
objetivo del caso de uso: qu lleva a
cabo o intenta?
cronologa y origen de las interacciones
repeticiones de comportamiento: qu
operaciones son iteradas?
situaciones opcionales: qu escenarios
alternativos se presentan en el caso de
uso?

59

Ejemplo Plantilla

Imagen

60

UML
Necesidad modelado
Casos de uso
Diagramas de clase
Diagramas de secuencia

61

Implementacin

Clases: abstracciones del mundo

real. Perspectiva ms usada

62

Clasificacin
El mundo real puede ser visto desde
abstracciones diferentes (subjetividad)
Mecanismos de abstraccin:
Clasificacin

/ Instanciacin
Composicin / Descomposicin
Agrupacin / Individualizacin
Especializacin / Generalizacin
63

Clases: Notacin Grfica

Cada clase se representa en un
rectngulo con tres
cuenta
compartimientos:
nombre

de la clase
atributos de la clase
operaciones de la clase

titular

saldo
depositar
extraer
transferir

64

Clases: Notacin Grfica

Otros ejemplos:
lista
conjunto
primero
ultimo
aadir
quitar
cardinalidad

intersecar
unir
cardinalidad

65

II. Breve Tour por UML

Diagrama de Clases
El Diagrama de Clases es el diagrama
principal para el anlisis y diseo
Un diagrama de clases presenta las
clases del sistema con sus relaciones
estructurales y de herencia
La
definicin
de
clase
incluye
definiciones
para
atributos
y
operaciones
66

Diagrama de Clases

El modelo de casos de uso aporta

informacin para establecer las
clases,
objetos,
atributos
y
operaciones

67

II. Breve Tour por UML

Ejemplos (Generalizacin)

Trabajador

{ disjunta, completa }

Directivo

Administrativo

Obrero

68

II. Breve Tour por UML

Ejemplos (Clase Asociacin)

Empresa

empleador

trabajadores

Empleado

1..*

Cargo
nombre
sueldo

superior
0..1

subordinado 1..*

69

Ejemplos (Clase y Visibilidad)

Alumno
DNI : char[10]
nmero_exp : int
nombre : char[50]
alta()
poner_nota(asignatura : char , ao : int, nota : float)
matricular(cursos : asignatura, ao : int)
listar_expediente()

70

 Ejemplos (Asociacin)

Departamento

dirige
0..1

director

Profesor

71

UML
Necesidad modelado
Casos de uso
Diagramas de clase
Diagramas de secuencia

72

Diagrama de Secuencia
Este diagrama (tambin llamado diagrama de interaccin)
muestra las interacciones entre un conjunto de objetos
(clases, actores), ordenadas segn el tiempo en que tienen
lugar. Es decir, muestra el orden de las llamadas en el
sistema. Se utiliza un diagrama para cada llamada a
representar. Es imposible representar en un solo diagrama la
secuencia de todas las llamadas posibles del sistema, es por
ello que se escoge un punto de partida. El diagrama se
compone con los objetos que forman parte de la secuencia,
estos se sitan en la parte superior de la pantalla,
normalmente a la izquierda se sita el que inicia la accin.
De estos objetos sale una lnea que indica su vida en el
sistema. Esta lnea simple se convierte en una lnea gruesa
cuando representa que el objeto tiene el foco del sistema, es
decir cuando l esta activo.
73

Diagrama de Secuencia

El objeto puede existir slo durante la ejecucin

de la interaccin, se puede crear o puede ser
destruido durante la ejecucin de la interaccin.
En este tipo de diagramas tambin intervienen
los mensajes, que son la forma en que se
comunican los objetos: el objeto origen solicita
(llama a) una operacin del objeto destino. El
diagrama de secuencia puede ser obtenido de
dos partes, desde el Diagrama Esttico de Clases
o desde el de Casos de Usos.

74

Elementos Diagrama de
Secuencia
Lnea de vida

Un objeto (o actor) se representa como una lnea vertical

punteada con un rectngulo de encabezado y con
rectngulos a travs de la lnea principal que denotan la
ejecucin de mtodos (activacin). El rectngulo de
encabezado contiene el nombre del objeto y el de su
clase.

75

Elementos Diagrama de
Secuencia
Activacin
Muestra el periodo de tiempo en el cual el objeto
se encuentra desarrollando alguna operacin, bien
sea por s mismo o por medio de delegacin a
alguno de sus atributos. Se denota como un
rectngulo delgado sobre la lnea de vida del
objeto.

76

Elementos Diagrama de
Secuencia
Mensajes

El envo de mensajes entre objetos se denota

mediante una lnea slida dirigida, desde el objeto
que emite el mensaje hacia el objeto que lo
ejecuta. Representa la llamada de un mtodo
(operacin) de un objeto en particular.
77

Elementos Diagrama de
Secuencia

Tambin es posible visualizar llamadas a mtodos

desde el mismo objeto en estudio.

78

Ejemplo

79

80

81

82

83

84

85

86

87

88

89

Diagrama de Secuencia
Muestra la secuencia de mensajes
entre objetos durante un escenario
concreto.
Cada objeto viene dado por una
barra vertical. Se llama lnea de
vida.
El tiempo transcurre de arriba
abajo.
90

Diagrama de Secuencia
Cada mensaje se representa
mediante una flecha entre las lneas
de vida.
Cuando existe demora entre el envo
y la atencin se puede indicar
usando una lnea oblicua.
Cada mensaje se etiqueta con el
nombre del mensaje y pueden
incluirse los argumentos

91

Diagrama de Secuencia

Los rectngulos en las lneas de vida

indican el tiempo en el cual un
mtodo est activo.

92

Diagrama de Secuencia
: Encargado

:WInPrstamos

:Socio

:Video

:Prstamo

prestar(video, socio)
verificar situacin socio
verificar situacin video
registrar prstamo
entregar recibo

93

Diagrama de Secuencia
Ventana de
entrada
de pedidos

Un Pedido

una Lnea
de pedido

un artculo
de inventario

prepara( )
*[para cada lnea
de pedido] prepara( )
hayExistencia:=revisa( )

Objeto

Mensaje

Condicin

[hayExistencia]
necesitaReorden:

descuenta( )

=necesitaReordenar ( )

Autodelegacin

94

 Diagrama de Secuencia

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

Modelado de SI: Algunas

Reflexiones

Modelar para la comprensin del sistema

y/o
para
el
mantenimiento
y
la
documentacin.

Pragmatismo,
tiles.

Sencillez y Elegancia.

Distintos nivel de abstraccin, diferentes

modelos.

Seguimiento de transformaciones durante

el proceso (Traceability).

los

modelos

deben

127

ser

Modelado de SI: Algunas

Reflexiones

Sincronizacin de modelos.

Dificultades para la introduccin de

tcnicas y herramientas de modelado.

128

Resumen
UML define una notacin que se expresa
como diagramas sirven para representar
modelos/subsistemas o partes de ellos
El 80 por ciento de la mayora de los
problemas pueden modelarse usando
alrededor del 20 por ciento de UML-- Grady
Booch

129