Especificacion de Sistemas de Software en UML

Ernest Teniente Lpez
Dolors Costal Costa

M. Ribera Sancho Sams
Especificacin de sistemas
software en UML
POLITEXT 153
software en UML
POLITEXT
Dolors Costal Costa

M. Ribera Sancho Sams
Ernest Teniente Lpez
software en UML
EDICIONS UPC
Primera edicin: setiembre de 2003
Diseo de la cubierta:
Manuel Andreu
Los autores, 2003
De la traduccin, Sergio Morales Garca, 2003
Edicions UPC, 2003

Edicions de la Universitat Politcnica de Catalunya, SL
Jordi Girona Salgado 31, 08034 Barcelona
Tel.: 934 016 883 Fax: 934 015 885
Edicions Virtuals: www.edicionsupc.es
E-mail: edicions-upc@upc.es
Produccin:
CPET (Centre de Publicacions del Campus Nord)

La Cup. Gran Capit s/n, 08034 Barcelona
Depsito legal: B-33082-2003

ISBN: 84-8301-723-7
Quedan rigurosamente prohibidas, sin la autorizacin escrita de los titulares del copyright, bajo las sanciones establecidas en las leyes, la reproduccin total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la reprografa y el tratamiento informtico, y la distribucin de ejemplares de
ella mediante alquiler o prstamo pblicos.
ndice
1
Introduccin a la ingeniera del software
Requisitos y especificacin
17
Introduccin a la orientacin a objetos
27
3.1 Motivacin y orgenes .........................................................................................................27

3.2 Aspecto esttico...................................................................................................................32
3.3 Aspecto dinmico ................................................................................................................33
3.4 El lenguaje UML (Unified Modeling Language) ................................................................36
El lenguaje UML
39
4.1 Modelo conceptual de datos en UML..................................................................................39

4.2 El lenguaje OCL (Object Constraint Language)..................................................................58
4.3 Modelo de casos de uso en UML.........................................................................................67
4.4 Modelo del comportamiento en UML .................................................................................77
4.5 Modelo de los estados en UML ...........................................................................................94
El proceso unificado de desarrollo del software
101
Coleccin de ejercicios
107
Software
Importancia
Evolucin
Caractersticas
Crisis del software
Ingeniera del software

Definiciones
Caractersticas
Visin genrica
Paradigmas
Ciclo de vida clsico
Prototipaje
Modelo en espiral
Bibliografa
Evolucin de Costes del hardware y del software
100%
HARDWARE
SOFTWARE
1960
70
80
Los autores, 2003; Edicions UPC, 2003
90
Evolucin del software
Distribucin
Hardware barato
Software de consumo
Batch
Poca distribucin
A medida
Multiusuario
Tiempo real
Bases de datos
Software de producto
1950
60
70
Aplicaciones web
Sistemas sobremesa
Sistemas expertos
Clculo paralelo
80
90
2000
10
Caractersticas del software
Se desarrolla, no se fabrica.
No se estropea.
Mantenimiento ms difcil que el hardware.
Se construye a medida, no se reusa demasiado.
Fallos H/S
ndice
Fallos
hardware
software
tiempo
11
Aplicaciones del software

Sistemas
Tiempo real
Gestin
De ingeniera
Cientfico
Empotrado
De PC
De inteligencia artificial
Crisis del software

Crisis?
Afliccin crnica!
Problemas:
Evolucin continua
Insatisfaccin de los usuarios
Poca calidad
Mantenimiento difcil
Causas:
Naturaleza del software
Complejidad
Gestin
Mitos:
De gestin
De los clientes
De los diseadores
12
Resultados de proyectos de software
Acabado y operativo, pero

fuera de plazo, de presupuesto
y sin satisfacer todos los
requisitos
In fo rm e C H A O S (19 9 4 )
Acabado en el plazo y
presupuesto, satisfaciendo los
requisitos
16,2 %
52,7 %
Cancelado durante el
desarrollo
31,1 %
Ingeniera del software
Establecimiento y uso de principios de ingeniera orientados a

obtener software:
Econmico
Fiable
Que funcione eficientemente
Que satisfaga las necesidades de los usuarios
13
10
Un ingeniero ...
Dispone de un abanico de tcnicas probadas que dan resultados
precisos.
Se preocupa de la fiabilidad y del rendimiento.
Trata de reducir costes y complejidad.
Basa sus modelos en teoras matemticas slidas.
Construye prototipos de los nuevos diseos.
Utiliza diagramas formales.
11
El proceso de la ingeniera
Formulacin
Anlisis
Generacin
Seleccin
Especificacin
Implementacin
Modificacin
14
12
Visin genrica de la ingeniera del software

Definicin:
Anlisis del sistema
Planificacin del proyecto
Anlisis de requisitos del software
Desarrollo:
Diseo del software
Codificacin
Prueba
Mantenimiento:
Correccin
Adaptacin
Mejora
13
Ciclo de vida clsico

ANLISIS REQS.
ESPECIFICACIN
DISEO
CODIFICACIN
PRUEBA
MANTENIMIENTO
15
14
Prototipaje
ANLISIS
REQUISITOS
DISEO
RPIDO
PRODUCTO
PROTO_
TIPO
REFI_
NAMIENTO
EVALUACIN
15
Modelo en espiral
Anlisis de riesg s
Planificacin
Evaluacin
Ingeniera
16
16
Bibliografa
Pressman, R.S
software Engineering: A Practitioners Approach.
5a edicin.
McGraw Hill, 2001. (Cap. 1y 2)
The CHAOS Report, 1994

http://www.standishgroup.com/sample_research/chaos_1994_1.php
Requisitos y especificaciones
Determinacin de los requisitos del software

Requisitos del sistema vs requisitos del software
Etapas
Estrategias
Especificaciones de sistemas software

Requisitos funcionales y no funcionales
Propiedades deseables de las especificaciones
Estndares de documentacin
Bibliografa
17
Requisitos del sistema vs. requisitos del software
Requisito: Condicin o capacidad necesitada por un usuario con

tal de solucionar un problema o conseguir un objetivo
La solucin al problema se puede realizar con software, hardware,
manualmente, o con una combinacin de los tres.
Si la solucin es compuesta, antes de disear los detalles de un
componente software concreto hay que disear el sistema global.
Ejemplo de sistema compuesto: refinera automatizada
Ejemplo de sistema slo software: control de stock
Etapas de la ingeniera de sistemas
Determinar requisitos del sistema global

Especificar requisitos del sistema global
Diseo del sistema global
HARDWARE
SOFTWARE
PERSONAS
Determinar
requisitos
Especificar
requisitos
Diseo
Ingeniera
del hardware
Ingeniera
del software
Ingeniera de sistemas
18
Determinar requisitos del sistema global

Comprensin de los objetivos y necesidades del usuario
Definir el conjunto de sistemas que podran satisfacer las necesidades u
objetivos y evaluarlos
Escoger el sistema ms adecuado
QU SISTEMA HAY QUE CONSTRUIR?
ALMACN
Sistema que recibe y verifica los productos

solicitados a los proveedores y los almacena en las
estanteras
Especificar los requisitos del sistema global

Describir el comportamiento externo del sistema, desde el punto de
vista del usuario o del entorno
QU HA DE HACER EL SISTEMA?
error
1. Comprobar si esperado
error
2. Comprobar correspondencia
albarn
3. Control de calidad
4. Actualizar pedido
defectuoso
5. Determinar dnde va
PEDIDO A
PROVEEDOR
PRODUCTOS
ESTANTERAS
6. Almacenar
PRODUCTOS EN ESTANTERAS
19

Determinar la arquitectura general del sistema que mejor satisfaga
los requisitos en trminos de:
componentes fsicos: hardware, software, personas
comunicacin entre ellos
error
1. Comprobar si esperado
error
2. Comprobar correspondencia
albarn
3. Control de calidad
defectuoso
4. Actualizar pedido
5. Determinar dnde va
orden
PEDIDO A
PROVEEDOR
PRODUCTOS
ESTANTERAS
6. Almacenar
SOFTWARE
MANUAL
PRODUCTOS EN ESTANTERAS
HARDWARE
Recepcin
pedido
albarn
aviso
defectuoso
resultado
albarn
Sistema
Inf rmtic
orden
errores
Transp rte
20
Determinar requisitos del software
Es el subconjunto de los requisitos del sistema global que han sido

asignados al componente software concreto
aviso
pedido
albarn
SISTEMA
INFORMTICO
resultado
orden
errores
Especificar los requisitos del software

Describir con detalle el comportamiento externo del componente
software concreto
albarn
error
pedido
Recibir
pedidos
Tratar
albaranes
pedidos
Actualizar
pedidos
resultado
productos
estanteras
Emitir
orden
orden
21
10
Estrategias de determinacin de los requisitos
Solicitarlos al usuario.
Extraerlos de un sistema software existente.
Sintetizarlos a partir del sistema global.
Descubrirlos mediante experimentacin.
11
Requisitos del software

Funcionales
Describen todas las entradas y salidas y la relacin entre ambas
de datos
de proceso
No funcionales
Definen las cualidades generales que ha de tener el sistema al
realizar su funcin
Eficiencia
Tipos de interfaces
Econmicos
Estructurales
Polticos
Calidad
22
12
Factores de calidad del software

Eficiencia
Flexibilidad
Integridad
Mantenibilidad
Portabilidad
Fiabilidad
Actualidad
Reusabilidad
Testability
Usabilidad
Interoperabilidad
13
Factores de calidad del software: Conflictos

Eficiencia
Flexibilidad
Integridad
Mantenibilidad
Portabilidad
Fiabilidad
Actualidad
Reusabilidad
Testability
Usabilidad
Interoperabilidad
23
14
Propiedades deseables de las especificaciones
No ambiguas
Completas
Verificables
Consistentes
Modificables
Trazables
Usables durante la operacin y el mantenimiento
15
Cmo organizar una especificacin de requisitos?

Estndar de documentacin ANSI/IEEE (I)
1. Introduccin
1.1 Propsito de la especificacin
1.2 Alcance del producto
1.3 Definiciones y abreviaturas
1.4 Referencias
1.5 Visin general de la especificacin
2. Descripcin general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Caractersticas de los usuarios
2.4 Restricciones generales
2.5 Suposiciones y dependencias
3. Requisitos especficos
4. Apndices
5. ndice
24
16
Cmo organizar una especificacin de requisitos?

Estndar de documentacin ANSI/IEEE (II)
3. Requisitos especficos
3.1 Requisitos de interfaces externas
3.2 Requisitos funcionales
3.3 Requisitos de rendimiento
3.4 Requisitos lgicos de la base de datos
3.5 Restricciones de diseo
3.6 Atributos del sistema software
a) Fiabilidad
b) Disponibilidad
c) Seguridad
d) Mantenibilidad
e) Portabilidad
3.7 Organizacin de los requisitos especficos

3.8 Otros requisitos
17
Bibliografa
Shumate, K.; Keller, M.

Software Specification and Design - A Disciplined Approach for RealTime Systems.
John Wiley, 1992. (Cap. 3)
Davis, A. M.
Software Requirements - Objects, Functions and States.
Prentice-Hall, 1993. (Cap. 1-5)
IEEE Recommended Practice for Software Requirements

Specifications
IEEE Std 830-1998 , 20 Oct 1998.
25
Motivacin y orgenes
Visin de un sistema software

Aspecto esttico
Aspecto dinmico
La notacin UML
27
Motivacin
- Aparicin de los lenguajes de programacin orientados a objetos
SIMULA: finales de los aos 60
SMALLTALK: principios de los aos 70
- El uso de estos lenguajes requiere un nuevo enfoque de anlisis y

de diseo.
- Otros factores:
Desarrollo de nuevas aplicaciones
nfasis principal en la estructura de datos
Aparicin de los primeros mtodos de diseo y de anlisis

orientados a objetos
Orgenes
Fusion
Martin-Odell
OOSE
Procesos y modelos
recomendados
BOOCH
OMT
Shlaer &
Mellor
UML
Rumbaugh, Blaha, Premerlani (OMT) - 1991

Coad, Yourdon - 1991
Shlaer, Mellor - 1992
Booch - 1992
Odell, Martin - 1992
Jacobson (OOSE) - 1993
Fusion - 1994
Booch, Rumbaugh, Jacobson (UML) - 1997
28
Visin de un sistema software
Objetos
Objeto:
Entidad que existe en el mundo real.
Tienen identidad y son distinguibles entre ellos.
el avin con
matrcula 327
una manzana
la factura 3443
un semforo
el avin con
matrcula 999
29
Clases de objetos
Clase de objetos: Describe un conjunto de objetos con:
- las mismas propiedades
- comportamiento comn
- idntica relacin con otros objetos
- semntica comn
abstraccin
clase avin
Avin
Abstraccin: eliminar distinciones entre objetos para poder

observar aspectos comunes.
Los objetos de una clase tienen las mismas propiedades y los
mismos patrones de comportamiento.
Atributos
Atributo: Es una propiedad compartida por los objetos de una clase.
Ejemplos:
Persona => nombre, direccin, telfono, ...
Avin => modelo, capacidad, color, ...
Persona
Nombre
Direccin
Telfono
Fecha_nacimiento
Edad
Avin
Modelo
Capacidad
Color
- Cada atributo tiene un valor (probablemente diferente) para cada objeto.

- Los atributos pueden ser bsicos o derivados.
30
Operaciones (I)
Operacin: Es una funcin o transformacin que se puede aplicar a
los objetos de una clase.
Persona
Nombre
Direccin
Telfono
Avin
Modelo
Capacidad
Color
Cambio_direccin
Cambio_trabajo
Reparar
Mover
- Las operaciones de un objeto son invocadas por otros objetos.

Mtodo: especificacin procedimental (implementacin) de una
operacin dentro de una clase.
Encapsulacin: Consiste en separar los aspectos externos de un objeto
de los detalles de implementacin.
Operaciones (II)
- En las operaciones, hay que indicar tambin el tipo de los argumentos y
del resultado.
Tringulo
Cuadrado
Color
Color
Posicin
Posicin
Girar (ngulo: Real)
Girar (ngulo: Real)
Seleccionar (p:Punto):Booleano
Polimorfismo:
- Una misma operacin se puede aplicar a diferentes clases.
- Su implementacin depende de cada clase.
31
10
Asociaciones
Asociacin:
Define la manera de enlazar o conectar objetos de
diferentes clases.
Ejemplo: Un pas tiene una nica capital.

Pas
Nombre
Habitantes
Ciudad
tiene_capital
Nombre
Habitantes
11
Generalizacin / Especializacin
Generalizacin: Es el acto o resultado de distinguir un concepto
que es ms general que otro.
Empleado
Nombre
Sueldo
Contratar
Pagar_sueldo
Jubilar
Especializacin
Directivo
Generalizacin
Viajante
Periodo contrato
Desp. autor.
Autorizar gastos
Jubilar
...
Regin
Cuota
Asignar regin
Asignar cuota
Herencia: Permite que las propiedades y las operaciones de una clase sean
accesibles en sus subclases.
32
12
Orientacin a objetos (I)
Aspecto esttico: Describe la estructura esttica de los objetos del

sistema y sus interrelaciones.
Intra - objeto
Aspecto
esttico
Clases de objetos
Atributos
Operaciones
Inter - objetos
Asociacin
Generalizacin
...
13
Descripcin del comportamiento (I)

Los objetos se comunican mediante la invocacin de operaciones
de otros objetos.
33
Descripcin del comportamiento (II)

Aspecto dinmico (de comportamiento): Describe los aspectos de un
sistema que cambian con el tiempo.
El aspecto dinmico de un sistema describe:

- Interacciones entre los objetos
- Posibles estados de un objeto
- Transiciones entre estados
- Qu eventos se producen
- Qu operaciones se ejecutan
Existe mucha divergencia entre los mtodos actuales en el momento

de tratar el aspecto dinmico.
14
15
Descripcin del comportamiento (III)

Diagrama de transicin de estados: Especifica el
cambio de estado de un objeto causado por los
eventos.
nacimiento
Ejemplo: estado civil de una persona

Soltera
boda
Casada
divorcio
Divorciada
boda
divorcio
boda
separacin
enviudar
Separada
Viuda
enviudar
34
16
Descripcin del comportamiento (IV)

Esquema de eventos: Permite especificar la interaccin entre
diferentes objetos (usado por el mtodo de Martin y Odell [MO92]).
Cliente enva
pedido
Aceptar
pedido
Preparar
pedido
Entregar
pedido
pedido
entregado
Cerrar
pedido
pedido
preparado
Enviar
factura
Cliente paga
factura
factura
enviada
factura
pagada
pedido
cerrado
17
Orientacin a objetos (II)

Aspecto esttico: Describe la estructura esttica de los objetos del
sistema software y sus interrelaciones.
Aspecto dinmico (de comportamiento): Describe los aspectos de un
sistema software que cambian con el tiempo.
Intraobjeto
Aspecto
esttico
Aspecto
dinmico
Clases de objetos
Atributos
Operaciones
Diagrama de
transicin de
estados
Interobjetos
Asociacin
Generalizacin
...
Esquema de eventos
35
Anlisis y diseo orientados a objetos

Anlisis:
- Creacin de una especificacin del problema y de los requisitos
- Qu ha de hacer el sistema software
Diseo:
- Definicin de una solucin software que satisfaga los requisitos
- Cmo lo har el sistema
orientados a objetos
Se usan los mismos conceptos en anlisis y diseo.

Es difcil determinar dnde acaba el anlisis orientado a objetos y
dnde comienza el diseo:
- estrategia de desarrollo iterativa
- diferencias de criterios segn los autores
18
19
El lenguaje UML (Unified Modeling Language)

Mayo01 OMG adopta UML 1.4
UML 1.4
Noviembre97 OMG adopta UML 1.1

como estndar
Enero97 - Publicacin del UML 1.0
public
feedback
Industrialitzacin
UML 1.1
Estandarizacin
UML 1.0
UML Partners
Expertise
Junio96 & Octubre96
UML 0.9 & UML 0.91
Unificacin
OOPSLA 95
Unified Method 0.8
Booch93 OMT-2
Other methods Booch 91
OMT-1
OOSE
Fragmentacin
36
20
El tringulo del xito

Notacin
U.M.L.
Proceso
(metodologa)
Craig Larman
The Unified Process
Herramienta
Rational Rose,
Objecteering,
Visio, etc.
21
Modelo de anlisis (especificacin)

Modelo
de anlisis
Modelo de
casos de uso
Modelo
conceptual de
los datos
Casos de uso
- nivel alto
- esencial
Diagramas
estticos de
estructura
para objetos
del dominio
Diagramas de
casos de uso
Modelo del
comportamiento
del sistema
Modelo de los
estados
Diagramas de
secuencia
del sistema
Diagramas
de estado de
objetos y
casos de uso
Contratos
para las
operaciones
del sistema
37
22
Bibliografa
Pressman, R.S.
Software Engineering: A Practiotioners Approach (5th edition)
Mc-Graw-Hill, 2001 (Cap. 20 y 21)
Booch, G.
Object-Oriented Analysis and Design
Benjamin/Cummings, 1994
Jacobson, I. et al.
Object Oriented Software Engineering: A Use Case Driven Approach
Addison-Wesley, 1992
Rumbaugh, J. et al.
Object-Oriented Modelling and Design
Prentice-Hall, 1991
Larman, C.
Applying UML and Patterns
An Introduction to Object-Oriented Analysis and Design
Prentice-Hall 1998
Jacobson, I.; Booch, G.; Rumbaugh, J.
The Unified Software Development Process
Modelo conceptual de los datos en UML

Introduccin
Objetos y clases de objetos
Atributos
Asociaciones
Clase asociativa
Generalizacin/Especializacin
Agregacin y composicin
Ampliaciones
Ejemplos
39

Modelo
de anlisis
Modelo de
casos de uso
Modelo
conceptual de
los datos
Modelo del
comportamiento
del sistema
Casos de uso
- nivel alto
- esencial
Diagramas
estticos de
estructura
de objetos
del dominio
Diagramas de
secuencia
del sistema
Diagramas de
casos de uso
Contratos
para las
operaciones
del sistema
Modelo de los
estados
Diagramas
de estado de
objetos y
casos de uso
Modelo conceptual de los datos
Es la representacin de los conceptos (objetos) significativos en

el dominio del problema.
Muestra, principalmente:
clases de objetos
asociaciones entre clases de objetos
atributos de las clases de objetos
restricciones de integridad
40
Objetos
Objeto:
Entidad que existe en el mundo real
Tienen identidad y son distinguibles entre ellos
el avin con
matrcula 327
una manzana
la factura 3443
un semforo
el avin con
matrcula 999
Clase de objetos
Clase de objetos: Describe un conjunto de objetos con:
- las mismas propiedades
- comportamiento comn
- idntica relacin con otros objetos
- semntica comn
abstraccin
clase avin
Avin
Abstraccin: Eliminar distinciones entre objetos para poder

observar aspectos comunes.
Los objetos de una clase tienen las mismas propiedades y
los mismos patrones de comportamiento.
41
Ejemplo: Terminal punto de venta

Un terminal de punto de venta (TPV) es un sistema computerizado usado para registrar
las ventas y gestionar pagos. Se usa principalmente en supermercados y grandes
almacenes. Incluye componentes hardware (como el ordenador y el escner del cdigo de
barras) y software para ejecutar el sistema.
Se nos pide que especifiquemos el software de este sistema.
Ejemplo TPV: Clases de objetos
TPV
Supermercado
Lnea de venta
Cliente
Venta
Producto
Pago
42
Ejemplo TPV: Atributos

Un atributo es una propiedad compartida por los objetos de una clase.
Supermercado
Venta
nm-pv: Integer
direccin: String
nombre: String
fecha: Date
hora: Time
Lnea de venta
Cliente
TPV
cantidad: Integer
Pago
nombre: String
telfs [1..*]: Integer
tipcli: TipoCliente
Producto
upc:Integer
descripcin [0..1]:String
precio: Integer
importe: Integer
Los atributos:
- Pueden tomar valores nulos (por ejemplo: descripcin).
- Pueden ser multivaluados (por ejemplo: telfs).
- Pueden ser definidos por el usuario mediante enumeraciones.
-Por ejemplo, TipoCliente se define a parte como una enumeracin con los
valores que puede tener y que son: Normal y Preferente.
Asociaciones
Es la representacin de relaciones entre dos o ms objetos.
- direccin de lectura
Vive en
Persona
Ciudad
- nombre de asociacin
43
10
Asociaciones de orden superior a dos
Alumno
Cuatrimestre
Asignatura
Se matricula
11
Multiplicidad de las asociaciones binarias

Dada una instancia a de la clase A cualquiera, la multiplicidad del
extremo B define cuntas instancias de B se pueden asociar con a en
un momento de tiempo determinado.
1
1..*
0..*
0..1
2..5
A
B
2, 5
A
B
A
1..3,7..10,15..*
B
B
B
B
B
44
12
Multiplicidad en las asociaciones ternarias
Dadas una instancia a de A y una instancia b de B cualesquiera,

la multiplicidad en el extremo C nos dice cuntas instancias de
C se pueden asociar con la pareja (a,b).
0..2
13
Multiplicidad en las asociaciones ternarias Ejemplos

Profesor
1..2
*
Asignatura
Cuatrimestre
Se responsabiliza
Segn este esquema, para toda pareja de asignatura y cuatrimestre, ha de haber como
mnimo un profesor reponsable.
Alumno
0..500
*
Asignatura
* Cuatrimestre
Se matricula
Este esquema permite que haya alguna pareja de asignatura y cuatrimestre para la cual
no hay ningn alumno que se haya matriculado de la asignatura en el cuatrimestre.
45
14
Restricciones textuales
Las restricciones que no se pueden especificar grficamente con la notacin UML se
especifican de forma textual
La especificacin textual se puede hacer con lenguaje natural, con OCL, etc.
Especialidad
Pertenece a
nom-esp
Equipo mdico
cod-equipo
*
Tiene
Mdico
*
num-col
Asignado a
*
1- Dos especialidades diferentes no pueden tener el mismo nom-esp.

Restricciones de
2- Dos equipos mdicos diferentes no pueden tener el mismo cod-equipo.
clave externa
3- Dos mdicos diferentes no pueden tener el mismo num-col.
4- Un mdico no puede estar asignado a un equipo mdico que pertenezca a una
especialidad que el mdico no tiene.
15
Nombre de rol en las asociaciones

Cada extremo de una asociacin es un rol, que tiene diversas propiedades como:
- nombre
- multiplicidad
El nombre de rol identifica un extremo de la asociacin y describe el papel
jugado por los objetos en la asociacin.
Vuela hacia
Vuelo
1
destino
Ciudad
Nombre de Rol
Describe el Rol de una
ciudad en la asociacin
vuela hacia
46
16
Asociaciones recursivas
Asociaciones en las que una misma clase de objetos participa ms
de una vez (con papeles diferentes o no).
Persona
*
hijo
0..2
padre
Tiene
Persona
*
Tiene por amigo
17
Clase asociativa
Representa una asociacin que se puede ver como una clase.
Estudiante
Asignatura
EstMatriculado
direccin
nombre
nombre
* crditos
Matrcula
nota
Empresa
Clase asociativa
Los atributos hacen referencia a la
asociacin
Su vida depende de la asociacin
Persona
Emplea
nombre
nombre
direccin
Contrato
sueldo
47
18
Ejemplo de clase asociativa

Participante
Proyecto
Asiste
Reunin
Empleado
Participa
No es equivalente a:
Reunin
*
Proyecto
Asistir
*
Empleado
19
Identificar elementos comunes entre los objetos definiendo relaciones de
superclase (objeto general) y subclase (objeto especializado).
superclase
Persona
E
G
{disjoint, complete}
sexo
Mujer
Hombre
discriminador - Es el nombre de la particin. Ha de ser nico entre los

atributos y roles de la superclase.
subclase
disjoint Un descendiente no puede ser de ms de una subclase.

overlapping Un descendiente puede ser de ms de una subclase.
complete Se han especificado todas las subclases.
incomplete La lista de subclases es incompleta.
La clasificacin puede ser esttica o dinmica.
48
20
Permite entender los conceptos en trminos ms generales, refinados y abstractos.
Hace los diagramas ms expresivos.
Todos los objetos de la subclase lo son tambin de la superclase.
La definicin de la superclase tiene que ser aplicable a la subclase
- atributos
- asociaciones
- restricciones
(- operaciones)
Pago
Paga por
cantidad: Dinero
tipo
Pago
en metlico
Venta
Pago
a crdito
Pago
con taln
21
Motivaciones para particionar una clase en subclases
La subclase tiene atributos adicionales.
La subclase tiene asociaciones adicionales.
La subclase es tratada o manipulada de forma diferente a las otras subclases.
La subclase se comporta de manera diferente a la superclase o a otras subclases.
Paga por
1
Pago
cantidad: Dinero
Atributos y
asociaciones comunes
tipo
Pago
a crdito
Pago
en metlico
Pago
con taln
*
Identifica crdito
1
Tarjeta
Cada pago se
trata diferente
Venta
asociaciones
adicionales
nm-taln: Integer
49
22
Motivaciones para definir una superclase
Las subclases potenciales representan variaciones de un mismo concepto.
Las subclases tienen atributos que pueden ser factorizados y expresados en las
superclases.
Las subclases tienen asociaciones que pueden ser factorizadas y relacionadas con la
superclase.
Atributos y
asociaciones comunes
Paga por
1
Pago
cantidad: Dinero
Pago
en metlico
Cada pago se
trata diferente
Venta
asociaciones
adicionales
tipo
Pago
a crdito
*
Identifica crdito
1
Tarjeta
Pago
con taln
nm-taln: Integer
23
Agregacin
La agregacin es un tipo de asociacin usada para modelar relaciones parte-todo
entre objetos.
El todo se denomina compuesto y las partes componentes.
Contiene
Ruta
1..*
Usa
Men
Segmento
Receta
La distincin entre asociacin y agregacin es a menudo subjetiva.

La nica restriccin que aade la agregacin respecto a la asociacin es que las
cadenas de agregaciones entre instancias de objetos no pueden formar ciclos.
*
A1
B1
*
*
C1
B2
C3
C2
A2
A3
A4
50
24
Composicin
La composicin es un tipo de agregacin por la cual:
- La multiplicidad del extremo compuesto puede ser como mximo 1 (como
mximo un componente lo es de un compuesto).
- Si un componente est asociado a un compuesto y el compuesto se borra
entonces el componente tambin se ha de borrar (no lo puede sobrevivir).
Tiene
Mano
1
Dedos
0..5
Contiene
Venta
1
0..*
Contiene
Catlogo
0..1
1..*
LneadeVenta
Especificacin
de Producto
25
Agregacin y composicin - Cundo mostrarla
Agregacin/Composicin
Existe una semejanza todo-parte fsica o lgica.
Algunas propiedades del todo se propagan a las partes
(como destruccin, movimiento...).
Composicin
La vida de la parte est incluida en la vida del compuesto.
Existe una dependencia crear-borrar de la parte respecto al
compuesto.
51
26
Informacin derivada
Un elemento (atributo o asociacin) es derivado si se puede calcular a partir de otros
elementos.
Se incluye cuando mejora la claridad del modelo conceptual.
Una constraint (regla de derivacin) ha de especificar cmo se deriva.
Atributo derivado
Departamento
Tiene
Empleado
nombre
/nm_empleados
El nmero de empleados de un departamento d es igual

al nmero de ocurrencias de Tiene donde aparece d.
Asociacin derivada
Departamento
Est situado en
1 Ciudad
*
Tiene
Empleado
La ciudad donde trabaja un empleado

es la ciudad donde est situado su
departamento.
*
/Trabaja en
27
Multiplicidad de clase
La multiplicidad de clase establece el rango de posibles cardinalidades para
las instancias de una clase.
Por defecto, es indefinida.
En algunos casos es til establecer una multiplicidad finita, especialmente en
casos de clases que pueden tener una sola instancia (y que se denominan
singleton).
- multiplicidad de clase
1
La Puntual, S.A.
NIF
direccin
52
28
Otras restricciones sobre asociaciones

A parte de la multiplicidad, es posible expresar otras restricciones sobre las asociaciones:
- Xor
- Subset
Xor
Une diversas asociaciones ligadas a una misma clase bsica.
Una instancia de la clase bsica puede participar como mximo en una de las
asociaciones unidas por xor.
persona propietaria
* Persona
Cuenta
cuenta per
*
{xor}
*
cuenta emp
1
empresa propietaria
Empresa
Subset
Indica que una asociacin es un subconjunto de otra asociacin
*
Persona
Pertenece a
*
Comisin
{subset}
1
Preside
29
Cambiabilidad
La cambiabilidad indica si los valores de un atributo o el extremo de una
asociacin pueden cambiar o no.
Cambiable (changeable)
Persona
telfono {changeable}
- opcin por defecto -
Vive en
*
residente
*
Ciudad
ciudad-res
{changeable}
telfono y ciudad-res son cambiables
Congelado (frozen)
Persona
Naci en
*
fecha-nac {frozen} per-nacida
1
ciudad-nac
{frozen}
Ciudad
fecha-nac y ciudad-nac son congelados
Slo-aadir (addOnly)
Persona
Ha residido en
*
*
Ciudad
residente
ciudad-res
{addOnly}
ttulo-aca y ciudad-res son slo-aadir
ttulo-aca {addOnly}
53
30
Generalizacin/Especializacin - Ejemplos discriminador

Pago
Pago
num-pago
tipo-pago
importe
{disj., inc.}
tipo-pago
{disj., inc.}
Efectivo
Efectivo
Tarjeta
cambio
cambio
num-tarjeta
Empleado
nombre-empleado
sueldo
/dept
{disj., inc.}
num-pago
importe
Trabaja en
*
/dept
tipo-pago
Tarjeta
num-tarjeta
Departamento
nombre-dept: Tdept
/dept de un empleado es el nombre-dept del

departamento donde trabaja el empleado.
Direccin
Produccin
matr-coche
precio-hora-ext
Tdept es una enumeracin de Direccin, Produccin y

Administracin.
31
Clasificacin mltiple
Variante de generalizacin/especializacin en la cual una superclase puede tener

diversas jerarquas de especializacin en funcin de diferentes discriminadores.
Persona
estado
sexo
Hombre
Soltera
Mujer
Casada
Divorc.
Viuda
54
32
Herencia mltiple
Variante de generalizacin/especializacin en la cual una subclase tiene
ms de una superclase.
Estudiante
universidad
{disjoint, incomplete}
EstUPC
EstUAB
estudios
{disjoint, incomplete}
EstUB
{incomplete}
Inform.
Mates
{incomplete}
InformUPC
Slo se puede utilizar si no hay conflictos de herencia.
Conflicto de herencia: Una clase tiene ms de una superclase con un
mismo atributo/asociacin/(operacin) que no proviene de un nico
antecesor.
Empres.
33
Equivalencias notacionales (I)

En UML:
Polgono
nmero_lados
Tringulo
Rectngulo
Pentgono
...
Pentgono
...
es equivalente a:
Polgono
Tringulo
Rectngulo
Problema?
55
34
Equivalencias notacionales (II)

En UML:
Docencia_Asignatura
1
*
Clase_Teora
*
Clase_Probl
*
Clase_Lab
es equivalente a:
Docencia_Asignatura
1
*
Clase_Teora
*
Clase_Probl
*
Clase_Lab
35
Ejemplos (I)
Qu solucin es mejor?
Persona_UPC
nombre
num-asignaturas [0..1]
sueldo [0..1]
con valores nulos
Persona_UPC
nombre
tipo
{overlapping, incomplete}
Empleado
Estudiante
num-asignaturas
sueldo
sin valores nulos
56
36
Ejemplos (II)
Qu solucin es mejor?
Persona_UPC
nombre
telfono [0..1]
con valores nulos
Persona_UPC
nombre
tener_telfono
Persona_con_telfono
telfono
sin valores nulos
37
Ejemplos (III)
Empleado
Proyecto
nombre: Texto
proy_emp: Proyecto
cod_proy: Texto
descripcin: Texto
Un atributo no puede tomar valores de una de las clases del modelo conceptual.
Este caso es una asociacin.
Empleado
nombre: Texto
Trabaja en
Proyecto
cod_proy: Texto
descripcin: Texto
57
Bibliografa
Booch, G.; Rumbaugh, J.; Jacobson, I.
The Unified Modeling Language User Guide
Rumbaugh, J.; Jacobson, I.; Booch, G.
The Unified Modeling Language Reference Manual
Larman, C.
Applying UML and Patterns
An Introduction to Object-Oriented Analysis and Design and
the Unified Process (second edition)
Prentice-Hall 2002
Cap. 10, 11, 12, 26 y 27
38
Object Constraint Language (OCL)
Para qu sirve?
Propiedades del modelo conceptual
Colecciones: conjuntos, bolsas y secuencias
Navegacin para clases asociativas
Cmo especificar en OCL
58
Para qu sirve OCL?
Los modelos grficos no son suficientes para una especificacin precisa y

no ambigua.
OCL:
Es un lenguaje formal.
Es un lenguaje de navegacin que permite definir expresiones (o sea, no tiene
efectos laterales).
No es un lenguaje de programacin, sino de especificacin.
Es un lenguaje tipificado.
Se usa para:
Especificar invariantes (restricciones y reglas de derivacin) del modelo
conceptual.
Especificar precondiciones, postcondiciones y salidas de las operaciones.
Ejemplo
Persona
*
director
Empresa
empresasDirigidas
fechaNacimiento: Fecha 1
nombre: String
nombre: String
empleado
contratador /nmEmpleados: Integer
apellido: String
sexo: SexoVlido
1..*
*
/estCasado: Boolean
/estParado: Boolean
esposa
/edad: Integer
0..1
esposo 0..1
Trabajo
Matrimonio
l gar : String
fecha: Fecha
tt lo: String
fechaInicio: Fecha
salario: Integer
SexoVlido se define como en meracin de Hombre y M jer.
59
Propiedades de los objetos
Cada expresin OCL:

se escribe en el contexto de una instancia de un tipo determinado.
define una propiedad de esta instancia.
Una propiedad puede hacer referencia a:

atributos de una clase de objetos.
navegacin a travs de las asociaciones.
Propiedades de los atributos de una clase de objetos:
Propiedad: edad de una persona -- entero

context Persona inv
la expresin ha de ser cierta para todas
las instancias de la clase
self.edad
instancia contextual de la expresin (punto de partida)
Restriccin de la propiedad: la edad de las personas ha de ser superior o igual a

cero
context Persona inv
self.edat >= 0
o, alternativamente: context p:Persona inv

p.edat >= 0
Propiedades de los objetos (II)

Propiedades de una navegacin a travs de asociaciones:
Partiendo de un objeto concreto, podemos navegar a travs de las asociaciones
del modelo conceptual para referirnos a otros objetos y a sus propiedades.
Cmo se navega?
Objeto.nombre-de-rol
objeto de partida
nombre de rol de una asociacin del objeto
Resultado: conjunto de objetos del otro extremo de nombre-de-rol
Si no hay nombre de rol especificado, se puede usar el nombre de la clase de objetos del
otro extremo de la asociacin (con minsculas).
Ejemplos de navegacin:
context Empresa inv
self.director
self.director.nombre
self.empleado
self.empleado.esposo
-- director de la empresa -- Persona

-- nombre del director -- String
-- empleados de la empresa -- set(Persona)
-- esposos de los empleados -- set(Persona)
60
Colecciones: conjuntos, bolsas y secuencias

Una coleccin de elementos puede ser del tipo:
Conjunto: cada elemento aparece una nica vez en la coleccin.

Bolsa (multiconjunto): la coleccin puede contener elementos repetidos.
Secuencia: bolsa donde los elementos estn ordenados.
Ejemplo:
nmero de trabajadores diferentes que trabajan para una persona

context Persona inv
num-trab = self.empresasDirigidas.empleado -> size()
Incorrecto: el resultado es una bolsa y puede contener repetidos.
context Persona inv
num-trab = self.empresasDirigidas.empleado -> asSet() -> size()
Reglas de navegacin:
Si la multiplicidad de la asociacin es 1, el resultado es un objeto (o un conjunto de un

nico objeto).
Si la multiplicidad de la asociacin es >1, el resultado es un conjunto.
Si se navega por ms de una asociacin y la multiplicidad de alguna de ellas es >1, el
resultado es una bolsa, aunque a veces puede ser un conjunto.
Operaciones bsicas sobre colecciones (I)

Select: Especifica un subconjunto de la coleccin.
personas mayores de 50 aos que trabajan en una empresa
context Empresa inv

self.empleado -> select(edad>50)
context Empresa inv
self.empleado -> select(p | p.edad>50)
context Empresa inv
self.empleado -> select(p:Persona | p.edad>50)
Collect: Especifica una coleccin que se deriva de otra, pero que contiene
objetos diferentes.
edades (con repetidos) de los empleados de una empresa
context Empresa inv

self.empleado -> collect(fechaNacimiento)
versin simplificada: self.empleado.fechaNacimiento
61
Operaciones bsicas sobre colecciones (II)

forAll: Expresin que han de satisfacer todos los elementos.
todos los empleados de la empresa se llaman Jack

context Empresa inv
self.empleado -> forAll(nombre=Jack)
la clave externa de Empresa es su nombre

context Empresa inv
Empresa.allInstances -> forAll(e1,e2 | e1<> e2 implies e1.nombre<>e2.nombre)
Exists: Condicin que satisface al menos un elemento.
como mnimo un empleado de la empresa se ha de llamar Jack

context Empresa inv
self.empleado -> exists(nombre=Jack)
IsUnique: Devuelve cierto si la expresin se evala a un valor diferente

para cada elemento de la coleccin.
la clave externa de Empresa es su nombre

context Empresa inv
Empresa.allInstances -> isUnique(nombre)
Combinacin de propiedades
Las propiedades se pueden combinar para formar expresiones ms

complejas.
Las personas casadas han de ser mayores de edad

context Persona inv
self.esposa -> notEmpty() implies self.esposa.edad >= 18
and self.esposo -> notEmpty() implies self.esposo.edad >= 18
Una empresa tiene como mximo 50 empleados

context Empresa inv
self.empleado -> size() <= 50
Una persona no puede tener a la vez un esposo y una esposa

context Persona inv
not ((self.esposa -> size()=1) and (self.esposo -> size()=1)
Definicin del atributo derivado numEmpleados

context Empresa inv
numEmpleados = (self.empleado -> size())
Definicin del atributo derivado estParado

context Persona inv
estParado = if self.contratador-> isEmpty() then true else false
62
Navegacin por clases asociativas

Navegacin a una clase asociativa:
Se utiliza el nombre de la clase asociativa (en minscula).
Los sueldos de las personas que trabajan en la UPC han de ser ms altos que
1000
context Persona inv
(self.contratador -> select(nombre=UPC)).trabajo)

-> forAll (t | t.salario > 1000)
Navegacin desde una clase asociativa:

Se usa el nombre de rol del extremo hacia donde se quiere navegar.
Si no se ha especificado nombre de rol, se usa el nombre de la clase.
Las personas que trabajan no pueden estar paradas

context Trabajo inv
self.empleado.estParado = false
Un matrimonio ha de ser entre una mujer y un hombre

context Matrimonio inv
self.esposa.sexo = #mujer and self.esposo.sexo = #hombre
10
11
Generalizacin - Especializacin (herencia)

CuentaCorriente
num-cc: Integer
entidad: String
efecta
1
Transaccin
fecha: Date
cantidad: Integer
Navegacin:
Ingreso
Extraccin
c-oficina: Integer
persona: String
Acceso directo a las propiedades de la superclase

context Ingreso inv
self.cuentaCorriente.num-cc -- nmero de cuenta de un ingreso
Acceso a las propiedades definidas en el nivel de subclase

context CuentaCorriente inv
self.transaccin.oclAsType(Extraccin).persona -> asSet()
-- personas que han extrado dinero de

una cuenta corriente
Aspectos adicionales:
Seleccin de objetos que pertenecen a la subclase.

self.transaccin -> select(oclIsTypeOf=Ingreso) -- ingresos de una cuenta
Las propiedades de las subclases se pueden ignorar.

self.transaccin -> select(fecha.isafter(5-4-1998)) -- transacciones de una cuenta posteriores al 5-4-1998
63
12
Cmo especificar en OCL
Una expresin OCL se especifica siempre comenzando en una clase de

objetos determinada: instancia contextual .
Una expresin se puede especificar de diversas maneras, segn la instancia

contextual de partida.
Los dos miembros de un matrimonio no pueden trabajar en la misma empresa
context Empresa inv
self.empleado.esposa -> intersection(self.empleado) -> isEmpty()
context Persona inv
self.esposa.contratador -> intersection(self.contratador) -> isEmpty()
Indicaciones para escoger la instancia contextual

Si la restriccin restringe el valor del atributo de una clase, sta es la clase
candidata.
Si la restriccin restringe el valor de los atributos de ms de una clase,
cualquiera de stas es la candidata.
Normalmente, cualquier restriccin debera navegar a travs del menor nmero
posible de asociaciones.
13
Cmo especificar en OCL: Ejemplos
El esposo y la esposa de un matrimonio han de ser mayores de edad

context Matrimonio inv
self.esposa.edad >= 18 and self.esposo.edad >= 18
-- es preferible a
context Persona inv

self.esposa -> notEmpty() implies self.esposa.edad >= 18 and
self.esposo -> notEmpty() implies self.esposo.edad >= 18
Todas las personas han de ser mayores de edad

context Persona inv
self.edad >= 18
-- es preferible a
context Empresa inv

self.empleado -> forAll (edad >= 18)
Nadie puede ser director y empleado de una empresa

context Empresa inv
not(self.empleado -> includes(self.director))
context Persona inv
not(self.empresasDirigidas.empleado -> includes(self))
-- cul es preferible en este caso?
64
14
Operaciones estndar de tipo booleano
Operacin
or
and
or exclusivo
negacin
igualdad
desigualdad
implicacin
if-then-else
Notacin
Resultado
a or b
a and b
a xor b
not a
a=b
a <> b
a implies b
if a then b else b
boolean
boolean
boolean
boolean
boolean
boolean
boolean
tipo de b b
15
Operaciones estndar de tipo string

Operacin
concatenacin
tamao
substring
igualdad
desigualdad
Notacin
Resultado
string.concat(string)
string.size()
string.substring(int,int)
string1 = string2
string1 <> string2
string
integer
string
boolean
boolean
Operaciones estndar de una clase de objetos

Operacin
Resultado
allInstances
Retorna el conjunto de todos los elementos de la clase de objetos
65
16
Operaciones estndar de tipo coleccin

Operacin
Resultado
size()
count(object)
includes(object)
includesAll(collection)
Nmero de elementos de la coleccin

Nmero de ocurrencias del objeto
Cierto si el objeto pertenece a la coleccin
Cierto si los elementos del parmetro collection estn en la
coleccin actual
Cierto si el objeto no pertenece a la coleccin
Cierto si los elementos del parmetro collection no estn en la
coleccin actual
Cierto si la coleccin est vaca
Cierto si la coleccin no est vaca
suma de todos los elementos (los elementos se han de poder
sumar)
expression es cierta para algn elemento?
expression es cierta para todos los elementos?
Cierto si expression evala a un valor diferente para cada
excludes(object)
excludesAll(collection)
isEmpty()
notEmpty()
sum()
exists(expression)
forAll(expression)
isUnique(expression)
elemento de la coleccin actual
17
Operaciones estndar (especficas) de tipo conjunto
Operacin
Resultado
select(expression)
Selecciona el subconjunto de elementos del conjunto actual para

los cuales expression es cierta
Elimina el subconjunto de elementos del conjunto actual para los
cuales expression es cierta
Resultado de unir los dos conjuntos
Resultado de la interseccin de los dos conjuntos
Resultado de unir el conjunto actual con la bag
Resultado de la interseccin del conjunto actual con la bag
reject(expression)
union(set)
intersection(set)
union(bag)
intersection(bag)
66
18
Bibliografa
OMG - Unified Modeling Language

Object Constraint Language Specification, v. 1.4.
Septiembre 2001.
Warmer, J.; Kleppe, A.

The Object Constraint Language: precise modeling with UML
Addison-Wesley, 1999.
Pginas web con informacin de OCL:
http://www.omg.org
http://www.software.ibm.com/ad/ocl
http://www.rational.com
Modelo de casos de uso en UML
Propsito
Casos de uso
Diagrama de casos de uso
Especificacin de casos de uso
Estructuracin de casos de uso
Identificacin de casos de uso
67

Modelo
de Anlisis
Modelo de
casos de uso
Modelo
conceptual de
los datos
Modelo del
comportamiento
del sistema
Casos de uso
- nivel alto
- esencial
Diagramas
estticos de
estructura
de objetos
del dominio
Diagramas de
secuencia
del sistema
Diagramas de
casos de uso
Modelo de los
estados
Diagramas
de estado de
objetos y
casos de uso
Contratos
para las
operaciones
del sistema
Determinacin de requisitos de un sistema software:

Identificar y categorizar las funciones del sistema (requisitos funcionales).
Identificar y categorizar los atributos del sistema (requisitos no funcionales).
Relacionar los requisitos no funcionales con los funcionales.
Especificacin de los requisitos de un sistema software:

Comprensin de los requisitos.
Organizar los requisitos segn las funciones del sistema.
Delimitar la frontera del sistema.
Modelo de casos de uso: Cules son las funciones del sistema PARA CADA ACTOR?
nfasis: USOS del sistema, valor aadido para cada actor.
68
Casos de uso
Caso de uso: Documento que describe una secuencia de eventos que
realiza un actor (agente externo) que usa el sistema para llevar
a cabo un proceso que tiene algn valor para el [Jacobson 92].
Extraccin de
dinero del
cajero
Actor: - Entidad externa al sistema que participa en la secuencia de

eventos del caso de uso.
- Puede ser una persona, un conjunto de personas, un sistema
hardware, un sistema software o un reloj.
Iniciador: Genera el estmulo que provoca la ejecucin del proceso (nico).
Participante: Interviene en el proceso.
Diagrama de casos de uso
Muestra conjuntamente los diferentes casos de uso de un sistema

software, los actores y las relaciones entre actores y casos de uso.
Entorno del sistema

Nombre del sistema
Caso de uso 1
Actor1
Caso de uso 2
Actorn
Caso de uso i
Comunicacin
69
Especificacin de casos de uso

De alto nivel: Descripcin breve de las acciones del caso de uso.
Caso de uso: Nombre del caso de uso
Actores: Lista de actores, iniciador
Propsito: Objetivo del caso de uso
Resumen: Descripcin breve de las actividades que se han de realizar
Tipo: 1 - primario, secundario, opcional
2 - real o esencial
Expandida: Descripcin detallada de las acciones y los requisitos
Aade a la especificacin de alto nivel:
Referencias cruzadas: Requisitos a los que hace referencia
Curso tpico de eventos: Descripcin detallada de la interaccin
(conversacin) entre los actores y el sistema
Descripcin de los eventos paso a paso
Cursos alternativos: Describe excepciones al curso tpico
Ejemplo: Terminal de punto de venta
Un terminal de punto de venta (TPV) es un sistema computerizado usadao para registrar

las ventas y gestionar pagos. Se usa principalmente en supermercados y grandes
almacenes. Incluye componentes hardware (como el ordenador y el escner del cdigo de
barras) y software para ejecutar el sistema.
Se nos pide que especifiquemos el software de este sistema.
70
Ref #
R1.1
R1.2
R1.3
R1.4
R1.5
R1.6
R1.7
R2.1
R2.2
R2.3
Ejemplo TPV: Funciones bsicas

Funcin
Registrar la venta actual - los productos comprados.
Calcular el total de la venta actual, incluyendo impuestos y clculo de
puntos de cliente.
Capturar la informacin de los productos comprados de un cdigo de
barras, usando un escner o bien a partir de la entrada manual del
cdigo de barras (Universal Product Code).
Descontar las cantidades vendidas del stock, cuando se confirme.
Guardar informacin sobre les ventas realizadas.
El cajero ha de identificarse al iniciar una sesin con un identificador
y una clave de acceso.
Mostrar la descripcin y el precio de cada producto comprado.
Tratar los pagos en efectivo capturando la cantidad entregada
por el cliente y calculando el cambio.
Tratar los pagos con tarjeta de crdito capturando el nmero de la
tarjeta desde un lector de tarjetas o manualmente, pedir confirmacin
del pago al servicio de autorizacin de crdito (externo) con una
conexin va mdem.
Registrar los pagos con tarjeta con tal que puedan ser facturados.
Categora
evident
evident
evident
hidden
hidden
evident
evident
evident
evident
hidden
Ejemplo TPV: Diagrama de casos de uso

Terminal Punto de Venta
Iniciar sesin
Cajero
Compra de productos
Devolver producto
Cliente
Acabar sesin
Responsable
de compras
Fijar pPrecio
Comprar a proveedores
Proveedor
Hacer ofertas
Director
comercial
71
10
Ejemplo TPV: Entorno del sistema

supermercado tradicional
Compra de
productos
CAJERO
Devolver
producto
CLIENTE
Iniciar
sesin
supermercado electrnico
Compra de
productos
CLIENTE
Devolver
Producto
11
Ejemplo TPV: Especificacin del caso de uso compra de productos en efectivo

Caso de uso: Compra de productos en efectivo.
Actores: Cliente (iniciador), Cajero.
Propsito: Capturar una venta y su pago en efectivo.
Resumen: Un cliente llega a la caja con productos para comprar.
El cajero registra los productos y gestiona el pago en efectivo.
Al acabar, el cliente se va con los productos.
Tipo: Primario y esencial.
Referencias cruzadas: R1.1, R1.2, R1,3, R1.7, R2.1
Curso tpico de eventos
Respuesta del sistema
Acciones de los actores
1. El caso de uso comienza cuando un Cliente llega

a la caja con los productos para comprar.
2. El Cajero indica que comienza una nueva venta 3. Registra el inicio de una nueva venta.
5. Determina el precio del producto y aade
4. El Cajero registra el identificador de
su informacin a la cuenta.
cada producto.
Si hay ms de una unidad del producto el
Cajero puede introducir la cantidad.
7. Calcula y muestra el total de la cuenta.
6. Al acabar la entrada de productos el
Cajero lo indica.
(contina)
72
12

8. El Cajero dice el total al cliente.
9. El Cliente entrega una cantidad de
dinero posiblemente ms grande que el
total de la cuenta.
10. El Cajero indica el dinero que ha
recibido.
13. El Cajero deposita el dinero recibido
en la caja y extrae el cambio.
El Cajero da el cambio y el recibo al
Cliente.
14. El Cliente se va con los productos
comprados.
11. Calcula y muestra el cambio al Cliente.

Imprime un recibo.
12. Registra la venta que se acaba de
hacer.
Cursos Alternativos
Lnea 4: Se introduce un identificador de producto inexistente. Indicar error.
Lnea 9: El Cliente no tiene suficiente dinero. Cancela la venta.
13
Casos de uso esenciales vs casos de uso reales
Esencial (muy abstracto)
Real
(muy concreto)
Independiente interfaces y tecnologa
Esencial
Accin del actor
1. El cliente se identifica.
3. Etc...

2. El sistema valida la identificacin.
4. Etc...
Real
Accin del actor
1. El cliente inserta la tarjeta.
3. Teclea el PIN por teclado.
5. Etc...

2. Solicita el PIN.
4. Muestra el men de opciones.
6. Etc...
73
14
Estructuracin de casos de uso: Secciones

Caso de uso: Compra de productos
Propsito: Capturar una venta y su pago en efectivo o con tarjeta.
1. El caso de uso comienza cuando un Cliente llega

2. (pasos intermedios excluidos)...
9. El Cliente escoge la forma de pago:
a. If en efectivo, see section pagar en efectivo.
b. If con tarjeta see section pagar con tarjeta.
10. Registra la venta que se acaba de hacer.
11. Imprime un recibo.
12. El Cajero da el recibo al cliente.
13. El Cliente se va con los productos
comprados.
15
Estructuracin de casos de uso: Secciones

Section: Pagar en efectivo

1. El Cliente entrega una cantidad de dinero
posiblemente ms grande que el total de la
cuenta.
2. El Cajero indica el dinero que ha
recibido.
4. El Cajero deposita el dinero recibido y
extrae el cambio.
El Cajero da el cambio al Cliente.
3. Calcula y muestra el cambio al Cliente.
Cursos alternativos
Lnea 4: Efectivo insuficiente para devolver el cambio. Pedir cambio a otra persona.
Section: Pagar con tarjeta
Cursos tpicos y alternativos para la historia del pago con tarjeta.
74
16
Estructuracin de casos de uso: Relacin <<include>>

<<include>>: Relacin de un caso de uso concreto con uno abstracto en la cual la conducta
definida por el caso concreto incluye (usa) la conducta definida en el abstracto.
Permite reducir la redundancia cuando una secuencia de acciones est compartida por
diversos casos de uso.
Cajero
Compra de productos
<<include>>
Pagar con tarjeta
Cliente
caso de uso que se efecta realmente
Compra de productos + Pagar con tarjeta
Cliente
Cajero
17
Ejemplo TPV: <<include>>

Cajero
<<include>>
Comprar
productos
Pagar en
efectivo
Cliente
<<include>>
Pagar con
tarjeta
<<include>>
<<include>>
Devolver producto
Servicio de
autorizacin
de crdito
Contabilidad
1. El caso de uso comienza cuando un cliente llega

2. (Pasos intermedios excluidos)...
10. Registra la venta que se acaba de
9. El Cliente escoge el tipo de pago:
hacer.
a. If en efectivo include
Pagar en efectivo.
b. If con tarjeta include
Pagar con tarjeta.
11. Imprime un recibo.
12. El Cajero da el recibo al cliente.
13. El Cliente se va con los productos comprados
75
18
Identificacin de casos de uso

Mtodo basado en los actores
1. Identificar los actores relativos al sistema.
2. Para cada actor, identificar los procesos que inicia
o en los cuales participa.
Mtodo basado en los eventos

1. Identificar los eventos externos a los que el
sistema ha de responder.
2. Relacionar los eventos con los actores y
casos de uso.
19
Bibliografa
Larman, C.
Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and the Unified Process (second edition)
Prentice-Hall, 2002. (Cap. 6, 9, 25)
Cockburn, A.
Writing Effective Use Cases

The Unified Software Development Process
Addison-Wesley, 1999. (Cap. 6,7)
76
Modelo del comportamiento en UML
Introduccin
Diagramas de secuencia del sistema
Contratos de las operaciones del sistema
Otras consideraciones
Comparticin de informacin entre las operaciones de un diagrama

Informacin elemental vs informacin compuesta
Nmero de eventos del diagrama de secuencia
Redundancia entre los modelos
Bibliografa
77

Modelo
de anlisis
Modelo de
casos de uso
Modelo
conceptual de
los datos
Modelo del
comportamiento
del sistema
Casos de uso
- nivel alto
- esencial
Diagramas
estticos de
estructura
de objetos
del dominio
Diagramas de
secuencia
del sistema
Diagramas de
casos de uso
Contratos
para las
operaciones
del sistema
Modelo de los
estados
Diagramas
de estado de
objetos y
casos de uso
Descripcin del comportamiento en OO

Los objetos se comunican mediante la invocacin de operaciones
de otros objetos
78
Especificacin del comportamiento en OO

SISTEMA
Consideramos un tipo especial sistema que engloba a todos los objetos.

La especificacin del comportamiento se hace con el modelo del
comportamiento del sistema.
Modelo del comportamiento del sistema
Diagramas de secuencia del sistema:

Muestran la secuencia de eventos entre los actores y el sistema.
Permiten identificar las operaciones del sistema.
Contratos para las operaciones del sistema:

Describen el efecto de las operaciones del sistema.
79
Objetivos:
Punto de partida:
Identificar los eventos y las operaciones del sistema.

Casos de uso.
La descripcin de los diagramas de secuencia del sistema es posterior a la descripcin
de los casos de uso.
Casos de uso:
Describen cmo los actores interactan con el sistema software.

El actor genera eventos hacia el sistema que exigen la ejecucin de alguna operacin
como respuesta (durante la interaccin).
A partir de los casos de uso podemos identificar cules son los eventos que van de los
actores hacia el sistema.
Muestra para un escenario particular de un caso de uso:

los eventos generados por los actores externos
su orden
los eventos internos del sistema (operaciones) que resultan de la
invocacin
Definiremos un diagrama de secuencia para cada curso

relevante de eventos de un caso de uso.
80
Ejemplo: Comprar producto

sistema como caja negra
actor
:Cajero
:Sistema
inicioVenta(pv)
:venta
entrarProd(venta,prod,cant)
finVenta(venta)
:importe
pago(venta,importePago)
:cambio
evento del sistema

invoca operacin
Construccin de un diagrama de secuencia
1. Dibujar una lnea vertical que representa el sistema.

2. Dibujar una lnea para cada actor que interacta directamente
con el sistema.
3. Del curso de eventos del caso de uso, identificar los eventos
externos generados por los actores. Mostrarlos en el diagrama.
81
10
Representacin de iteraciones de eventos
:Actor
:Sistema
evento1()
iteracin de un
nic event
*
*
iteracin de una
secuencia de event s
evento2()
evento3()
evento4()
11
Diagramas de secuencia: <<include>>
Los casos de uso definidos mediante <<include>> requieren un diagrama de

secuencia para la parte comn y uno para cada caso de uso que es incluido.
Ejemplo: caso de uso comprar productos

:Cajero
:Sistema
inicioVenta(pv)
:venta
<<include>> pagar con

tarjeta o en efectivo
finVenta(venta)
:importe
Parte especfica: pagar con tarjeta

:Gestin Tarjetas
:Cajero
:Sistema
pagTarjetaCrdito(nm-t,fecha-cad)
:Sist. Autor. Crdito

solicitudAprob(nm-t)
tratarRespTarjeta(respuesta)
aadeAprobacin(respuesta)
82
12
Eventos y operaciones
Evento del sistema: Evento externo generado por un actor

Operacin del sistema: Operacin interna que se ejecuta como
respuesta a la comunicacin del evento
La comunicacin de un evento del sistema provoca la ejecucin de

una operacin del sistema con el mismo nombre y los mismos
parmetros.
13
Operaciones del sistema
Las operaciones del sistema se agrupan como operaciones del tipo

especial sistema.
En cambio, las operaciones no se asignan a objetos concretos
durante la etapa de especificacin.
Ejemplo:
SISTEMA
inicioVenta(pv) :venta
finVenta(venta) :importe
pago(venta,importePago): cambio
83
14
Eventos y el lmite del sistema
Para identificar los eventos del sistema es necesario haber

delimitado claramente la frontera del sistema.
Los eventos del sistema son los que estimulan directamente el
sistema.
Ejemplo:
:Cajero
:Sistema
inicioVenta
El actor cliente no interacta

directamente con el sistema,
slo lo hace el cajero.
entrarProd
finVenta
pago
frontera del
sistema
15
Contratos de las operaciones
Contrato de una operacin

Describe el comportamiento del sistema en trminos de:
cules son los cambios de estado de la base de informacin
cules son las salidas que el sistema proporciona
cuando se invoca la operacin.
El tipo de descripcin es declarativo:

El nfasis se pone en qu har la operacin ms que en cmo lo har.
Los contratos de las operaciones incluyen primordialmente:

precondiciones y postcondiciones que describen los cambios de estado
salidas
84
16
Contratos de las operaciones: Componentes

Nombre: Nombre y argumentos de la operacin (cabecera de la operacin)
Responsabilidades:
Descripcin informal del propsito de la operacin
Excepciones:
Descripcin de la reaccin del sistema a situaciones excepcionales
Precondiciones:
Suposiciones sobre el estado del sistema antes de la invocacin de la operacin
Postcondiciones:
Cambios de estado que se han producido:
- altas/bajas de instancias de clases de objetos
- altas/bajas de instancias de asociaciones
- modificacin de atributos
- generalizacin de un objeto
- especializacin de un objeto
- cambio de subclase de un objeto
Salida:
Descripcin de la salida que proporciona la operacin en pseudo-OCL
Observad el vnculo que existe entre los contratos de las

operaciones y el esquema conceptual.
17
Ejemplo: Esquema conceptual de partida
PuntoDeVenta
num-pv
1
tiene
Venta
1..* LneaDeVenta
1
da
consta de
cantidad
hora
*
/importe
corresponde a
1
Producto
cdigo
precio
descripcin
RI textuales:
1- La clave externa de PuntoDeVenta es num-pv.
2- La clave externa de Producto es cdigo.
3- Un punto de venta no puede tener ms de una venta con el mismo da y hora.
85
Ejemplo: Operacin inicioVenta

Nombre: inicioVenta(pv) :venta
Responsabilidades:
Iniciar el registro de una venta.
Excepciones:
Si no existe ningn PuntoDeVenta con num-pv=pv, indicar error.
Precondiciones:
Existe un PuntoDeVenta con num-pv=pv.
Postcondiciones:
- Alta de una instancia V de Venta con el da y la hora actuales.
- Alta de una instancia de la asociacin tiene que asocia la venta V y la
instancia de PuntoDeVenta con num-pv=pv.
Salida: V
18
19
Ejemplo: Operacin entrarProd

Nombre: entrarProd(venta,prod,cant)
Responsabilidades:
Registrar una lnea de una venta.
Excepciones:
Si no existe ningn Producto con cdigo=prod, indicar error.
Precondiciones:
Existe un Producto con cdigo=prod.
Postcondiciones:
- Alta de una instancia de LneaDeVenta L con cantidad=cant.
- Alta de una instancia de la asociacin consta de que asocia L y venta.
- Alta de una instancia de la asociacin corresponde a que asocia L y el
Producto con cdigo=prod.
Salida:
86
Ejemplo: Operacin finVenta

Nombre: finVenta(venta) :importe
Responsabilidades:
Finalizar el registro de una venta y mostrar el importe a pagar.
Excepciones:
Precondiciones:
Postcondiciones:
Salida: importe = venta.importe
20
21
Ejemplo: Operacin pago

Nombre: pago(venta,importePago): cambio
Responsabilidades:
Mostrar el cambio a devolver.
Excepciones:
Si importePago < venta.importe indicar error.
Precondiciones:
importePago venta.importe.
Postcondiciones:
Sortida: cambio = importePago - venta.importe
87
22
Comparticin de informacin entre las operaciones de un diagrama
UML no precisa de qu manera las operaciones de un diagrama de secuencia

pueden compartir informacin.
Dos posibles soluciones son:
Mediante argumentos
adicionales de las operaciones
:Cajero
:Sistema
Mediante informacin adicional en

el esquema conceptual
:Caixer
:Sistema
inicioVenta(pv)
inicioVenta(pv)
:venta
entrarProd(pv, prod,cant)
finVenta(venta)
Venta
da
hora
/importe
finVenta(pv)
:importe
:importe
pago(pv,importePago)
:cambio
:cambio
Restriccin implcita: El valor del argumento

venta es el mismo en todos los eventos del
diagrama.
VentaEnCurso
23
Informacin elemental vs informacin compuesta
La informacin tratada por una operacin se expresa tanto a nivel de los

parmetros como de la salida que aparecen en la cabecera de la
operacin.
Hay dos tipos de informacin:

Informacin elemental: contiene un nico elemento de informacin indivisible.
Propiedad
Clase de objetos predefinida: Integer, Real, ...
Informacin compuesta: es una composicin de informaciones elementales (y,
por tanto, hay que especificar cmo se define la composicin).
Ejemplo: ResumenVentas(num-pv) que devuelve un listado de ventas con la informacin:
Para cada Producto p vendido en aquel PuntoDeVenta num-pv mostrar
- el cdigo del producto
- la cantidad total vendida de p en num-pv
ResumenVentas (num-pv:Integer): ???
88
24
Informacin Compuesta - Definicin

Problema: Cmo se especifica el contenido de una informacin compuesta?
En la actualidad, UML no propone ninguna solucin.
Utilizaremos una adaptacin de la definicin de flujos de datos que se hace en
el anlisis estructurado (Yourdon, 1993).
Mecanismos bsicos de definicin de informacin compuesta
Inclusin: i1 = i2 + i3 + i4
Seleccin: i1 = [i2 l i3 l i4]
Repeticin: i1 = {i2 + i3 + i4}
Opcionalidad: i1 = i2 + (i3 + i4)
Ejemplo:
ListadoVentas = num-pv + {cod-prod + cantidad}
num-pv = Integer; codi-prod = Integer; quantitat = Integer
ResumenVentas(num-pv:Integer) : ListadoVentas
25
Informacin compuesta - Contratos de las operaciones
Las operaciones necesitarn mecanismos para manipular (acceder, construir,

etc.) la informacin compuesta que aparece en su cabecera.
Se necesita ectender OCL para poder manipular informacin compuesta.

Ejemplo: contracto de la operacin ResumenVentas (num-pv): ListadoVentas
Nom: ResumenVentas (num-pv): ListadoVentas
Responsabilitats: Emitir el resumen de ventas solicitado
Tipus: sistema
Excepcions:Precondiciones: Postcondiciones: Salida:
Mostrar (num-pv)
Para cada Producto p resultante de
Producto.allInstances ->
select (p | p.LneaDeVenta.Venta.PuntoDeVenta.num-pv->includes(num-pv)
Hacer
cant = p.LneadeVenta ->
select (lv | lv.Venta.PuntoDeVenta.num-pv = num-pv).cantidad -> sum()
Mostrar (p.cdigo)
Mostrar (cant)
89
26
Diagrama de secuencia: Cuntos eventos?
El nmero de eventos de un diagrama de secuencia depende de cmo se

produzca la interaccin entre los actores y el sistema software.
:Cajero
:Sistema-X
:Sistema
inicioVenta(pv): venta
:Sistema
hacer-Venta(infoVenta)
entrarProd(venta, prod, cant)
finVenta(venta): importe
infoVenta = pv + {prod + cant} + importePago
pago(venta, importePago): cambio
Ambos diagramas suponen la misma

entrada de informacin al sistema.
Los dos diagramas de secuencia pueden

ser correctos, segn las circunstancias.
27
Redundancia - Ejemplo
El esquema conceptual contiene restricciones de integridad (grficas y textuales).
Los contratos de las operaciones tienen precondiciones, que son requisitos del
contenido del esquema conceptual para poder ejecutar una transaccin.
Es necesario que las precondiciones incluyan la comprobacin de las restricciones del

modelo conceptual?
Empleado
cod-emp
sueldo
R.I. textual: dos empleados no
pueden tener el mismo cdigo.
Nombre: AltaEmpleado (cod-emp, sueldo)

Responsabilidades: dar de alta al empleado
Excepciones: Precondiciones: no existe Empleado con cod-emp
Postcondiciones:
creacin de un nuevo objeto Empleado con
cod-emp y sueldo
Salida: -
Hay que poner esta precondicin?
90
Redundancia - Definicin
Una especificacin es redundante si un mismo aspecto del sistema

software est especificado diversas veces.
La redundancia dificulta la modificabilidad de la especificacin

porque si vara aquel aspecto hay que modificar todos los modelos
donde se le hace referencia.
La especificacin no debera ser redundante!
Redundancias posibles:
Entre el esquema conceptual y los contratos
Entre los diagramas de secuencia y los contratos
...
28
29
Redundancia - Esq. conceptual y contratos (I)

Persona
nom-p
tiene
0..3
Coche
matr
ao
Significado habitual:
:Persona
:Sistema
CompraCoche(nom-p,matr)
Significado alternativo:
Nombre: CompraCoche (nom-p,matr)

Responsabilidades: compra de un coche
Excepciones:
(las que se deducen de las prec.)
Precondiciones:
- existe Persona p con nom-p
- existe Coche c con matr
- p no tiene c
- p no tiene ya 3 coches
Postcondiciones:
- creacin de una asociacin tiene
entre p y c
Salida: -
Nombre: CompraCoche (nom-p,matr)

Responsabilidades: compra de un coche
Excepciones:
(las que se deducen de las prec.)
Precondiciones:
- existe Persona p con nom-p
- existe Coche c con matr
- p no tiene c
Postcondiciones:
- Si p tiene ya 3 coches entonces
eliminar la asociacin entre p y el
coche c de ms antigedad
- creacin de una asociacin tiene
entre p y c
Salida: -
91
30
Redundancia - Esq. conceptual y contratos (II)
Cmo se han de interpretar los contratos en relacin al modelo

conceptual?
Precondiciones:
Qu ha de contener el Modelo Conceptual para intentar ejecutar una
operacin.
Restricciones del modelo conceptual:

Estn garantizadas despus de la ejecucin de todas las operaciones
que participan en un caso de uso.
Se rechazan todas las operaciones de un caso de uso si su ejecucin
viola (globalmente) alguna restriccin de integridad del modelo
conceptual.
31
Redundancia - Esq. conceptual y contratos (III)

Persona
nombre
direccin
Caso de uso: Aadir-Persona-1

:Persona
:Sistema
AltaPersona(nombre,direccin)
habla
1..*
Idioma
nombre
nm-parlantes
Caso de uso: Aadir-Persona-2

:Persona
:Sistema
AltaPersona(nombre,direccin)
* HablaIdioma(nombre, idioma)
No permite aadir nunca una persona!

Nombre: AltaPersona(nombre,direccin)
Precondiciones:
Postcondiciones:
- creacin de un objeto Persona con
el nombre y la direccin especificados
Salida:
Nombre: HablaIdioma(nombre,idioma)
Precondiciones:
- existe Idioma con nombre=idioma
- no existe la asociacin habla entre nombre
e idioma
Postcondiciones:
- creacin de una asociacin habla entre
la Persona con nombre=nombre y el Idioma
Salida:
92
32
Redundancia - Diagramas de secuencia y contratos

Los diagramas de secuencia definen un orden de invocacin de las
operaciones.
Las operaciones no han de incorporar informacin para garantizar
que este orden se cumpla.
:Cajero
:Sistema
entrarProd(venta, prod, cant)
finVenta(venta): importe
pago(venta, importePago): cambio
Nombre: pago (venta, importePago): cambio
Precondiciones:
- existe Venta venta
- la Venta venta ha finalizado
Postcondiciones:
...
Salida:
son redundantes
33
Bibliografa
Larman, C.
Prentice-Hall, 2002. (Cap. 13, 15)
Rumbaugh, J.; Jacobson, I.; Booch, G.

The Unified Modeling Language Reference Manual

93
Modelo de los estados en UML
Introduccin
Uso de los diagramas de estado
Ejemplos
Acciones y condiciones de una transicin
Estados imbricados
Bibliografa
94

Modelo
de anlisis
Modelo de
casos de uso
Modelo
conceptual de
los datos
Modelo del
comportamiento
del sistema
Casos de uso
- nivel alto
- esencial
Diagramas
estticos de
estructura
de objetos
del dominio
Diagramas de
secuencia
del sistema
Diagramas de
casos de uso
Contratos
para las
operaciones
del sistema
Modelo de los
estados
Diagramas
de estado de
objetos y
casos de uso
Modelo de los estados
Objetivos:
Crear diagramas de estado para objetos y casos de uso.
Eventos, estados y transiciones:

Evento:
aquello que requiere una respuesta del sistema software
Estado:
condicin de un objeto o de un caso de uso en un momento del
tiempo
Transicin:
cambio de estado como consecuencia de un evento
95
Diagrama de estados
Un diagrama de estados muestra la secuencia de estados que pasa un objeto (o una
interaccin) durante su vida en repuesta a los estmulos recibidos, junto con sus respuestas.
Nombre super estado

Nombre Estado
Variable: tipo=valor inicial
Ev.(argumentos)[condicin@/accin
Nombre Estado
Entry/accin
do/actividad
exit/accin
event/accin
Cambio de estado civil de una persona

Persona
Soltera
nacimiento
estadocivil
Casada
Separada
Divorciada
Soltera
Viuda
boda
Casada
divorcio
Divorciada
boda
divorcio
boda
separacin
Separada
enviudar
Viuda
enviudar
96
Uso de los diagramas de estado
Un diagrama de estados se puede especificar para:

Clase de objetos:
para describir por qu los objetos cambian de subclase
las subclases de un diagrama de estados no tienen por qu aparecer
explcitamente en el esquema conceptual
para describir clases de objetos con importante comportamiento
dinmico
Caso de uso:
para describir la secuencia legal en la que los eventos se pueden
producir en el mundo real
Ejemplo: En una compra de producto no se puede hacer el pago hasta
que no se haya cerrado la venta.
Diagrama de estados del caso de uso comprar productos

entrarProd
Esperando
venta
inicioVenta
entrarProd
Esperando
producto
Introduciendo
productos
finVenta
Esperando
pago
pagoEnMetlico
tratarRespTarjeta
Autorizando
pago
PagTarjetaCrdito
97
Diagrama de estados de un telfono

estado inicial
estado
libre
descolgar
activo
colgar
transicin
evento
Acciones y condiciones de una transicin
condicin
libre
descolgar [abonadoVlido]
activo
/marcarTono
colgar
accin
98
10
Estados imbricados
descolgar [abonadoVlido]
/marcarTono
Activo
Emetiendo Tono
Marcar
libre
Charlando
dgito
dgito
colgar
conectado
Marcando
Conectando
completo
11
Bibliografa
Larman, C.
Prentice-Hall, 2002.

Powel Douglass, B.
Real-Time UML.
99
Proceso unificado de desarrollo de software
El proceso unificado de desarrollo de software
Etapas del proceso iterativo de desarrollo del software

Ciclos de desarrollo
Ejemplo: Compra de productos
Bibliografa
101
Proceso de desarrollo del software - Macro Nivel
1. Planificar y elaborar - Planificar, definir requisitos,

construir prototipos...
2. Construir - Desarrollo del sistema (especificacin, diseo, etc.)
3. Implantar - Implantar el sistema para su uso.
Plan y
elaboracin
Construccin
Implantacin
Etapa de planificacin y elaboracin

Incluye la concepcin inicial del proyecto, deteccin de problemas, determinacin de
objetivos, investigacin de alternativas de cambio, planificacin y especificacin de los
requisitos.
Plan y
Elaboracin
Construccin
Implantacin
1. Definir el plan inicial
2. Informe de inv. preliminar
3. Definir requisitos
4. Definir trminos glosario
5. Implementar prototipo
6. Definir casos de uso
7. Definir modelo conceptual
8. Definir esq. de arquitectura
9. Refinar el plan
Plan: calendario, presupuesto, etc.

Informe de investigacin preliminar: motivacin, alternativas, necesidades de negocio.
Especificacin de requisitos: descripcin declarativa de los requisitos
Glosario: diccionario de trminos (conceptos, nombres) y cualquier informacin asociada
102
Etapa de construccin
Plan y
Elaboracin
Ciclo de
desarrollo 1
Refinar
plan
Sincr.
artefactos
Construccin
Ciclo de
desarrollo 2
Anlisis
Diseo
Implantacin
...
Construccin
Prueba
Ventajas:
La complejidad nunca sobrepasa al diseador.
Primeras impresiones muy rpidamente, porque la implementacin
de una pequea parte del sistema se hace muy rpidamente.
Etapa de construccin: Ciclos de desarrollo (I)

La etapa de construccin incluye diversos ciclos de desarrollo en los cuales el
sistema se va extendiendo de forma progresiva.
Ciclo de desarrollo 1
Refinar plan
...
Anlisis
Sincr. artefactos
Diseo
Construccin
1. Definicin de los casos

de uso esenciales
2. Refinar los
diagramas
3. Refinar el modelo
conceptual
4. Refinar el
glosario
5. Definir diagramas
de secuencia
6. Definir contratos
de operacin
Prueba
7. Definir diagramas
de estado
103
Etapa de construccin: Ciclos de desarrollo (II)
Refinar plan
...
Sincr. artefactos
Anlisis
Diseo
Construccin
Prueba
1. Definicin de los casos

de uso reales
2. Definir informes e
interfaces de usuario
3. Refinar la arquitectura
del sistema
4. Definir los diagramas

de interaccin
5. Definir el diagrama de
clases de diseo
6. Definir el esquema de la
base de datos
Ordenar y priorizar casos de uso

Ciclo de
desarrollo
Ciclo de
desarrollo
Caso de uso A
Versin
Simplificada
...
...
Caso de uso A
Versin
Completa
...
...
Cmo priorizar?
a. Incluyen funciones arriesgadas, crticas o complejas.
b. Involucra tecnologa nueva o arriesgada.
c. Representan procesos primordiales para el negocio.
d. Impacto significativo en el diseo (aade muchas clases
al dominio o requiere muchos servicios).
e. Permite obtener informacin significativa respecto al
diseo con poco esfuerzo.
Ciclo de
desarrollo
Caso de uso B
...
...
...
Caso de uso C
...
...
...
104
Ejemplo: Compra de productos
En un primer ciclo de desarrollo puede no interesarnos distinguir entre las diversas

formas posibles de pago.
:Cajero
:Sistema
inicioVenta(pv)
:venta
finVenta(venta)
:importe
hacerPago
Interesa desarrollar el subsistema necesario para poder efectuar una compra.
El contrato de pago habra de ser suficientemente genrico para no entrar en

detalles de su forma de pago.
Compra de productos 2 ciclo
Tenemos tantos diagramas de secuencia como formas de pago posibles.

Todos estos diagramas parten del diagrama que se ha hecho en el primer ciclo de
desarrollo.
:Cajero
:Sistema
Interaccin comn a
todo tipo de pago
Interaccin especfica del pago en metlico

:Cajero
:Sistema
:cambio
105
10
Interaccin especfica del pago con tarjeta

:Gestin Tarjetas
:Cajero
:Sistema
pagTarjCrdito(nm-t,fecha-cad)
:Sist. Autor. Crdito

solicitudAprov(nm-t)
tratarRespTarj(respuesta)
aadixAprovacin(respuesta)
Nombre: pagTarjCrdito (nm-t, fecha-cad)

Responsabilidades: pagar con la tarjeta de crdito
Excepciones:
Precondiciones:
Postcondiciones:
- Creacin de un nuevo PagoConTarjeta pct
- Nueva asociacin entre pct y la venta actual
- ...
Salida:
- Se enva una solicitud de aprovacin al
servicio de autorizacin de crdito
Nombre: tratarRespTarj (respuesta)

Responsabilidades:
responder a la respuesta de aprovacin recibida
Excepciones:
Precondiciones:
Postcondiciones:
- ...
Salida:
- Se enva una aprovacin al sistema de Gestin
de Tarjetas para que la registre
11
Bibliografa
Larman, C.
Applying UML and Patterns.
An Introduction to Object-Oriented Analysis and Design.
Prentice Hall, 1998. (Cap. 13, 32)

The Unified Software Development Process.
106
Especificacin de sistemas software en UML
Coleccin de ejercicios
1 Conceptos bsicos
1 Conceptos bsicos
1.
Da y justifica una definicin de ingeniera del software.
2. El ciclo de vida denominado modelo espiral est basado en cuatro actividades: planificacin,
anlisis de riesgos, ingeniera y evaluacin. Comenta brevemente el objetivo de cada una de estas
actividades y cmo se encadenan.
3.
Da una definicin de requisito de un sistema y de especificacin de requisitos de un sistema.
4.
Indica la diferencia entre requisitos de un sistema y requisitos del software.
5.
Resume las cuatro estrategias para determinar los requisitos.
109
6. Define y describe brevemente tres requisitos no funcionales, de diferente tipo, relativos al

proyecto realizado durante el curso.
7. Una de las propiedades deseables de las especificaciones es que sean trazables (traceability).
Define esta propiedad.
8. Una de las propiedades deseables de las especificaciones es que sean verificables. Define cundo
se puede decir que una especificacin determinada cumple esta propiedad. Pon un ejemplo de un
fragmento cualquiera de una especificacin que sea verificable y otro que no lo sea.
9. Mucha gente argumenta que el trmino mantenimiento es incorrecto aplicado al software que
las actividades asociadas al mantenimiento del software son totalmente mantenimiento. Qu
piensas t? (Ejercicio 1.11 de Pressman 93)
10. Indica qu relacin existe (si es que la hay) entre la construccin de prototipos y el modelo de
desarrollo de software en espiral.
11. Indica los tres tipos de mantenimiento de software que hay y explcalos brevemente.
12. Explica brevemente la diferencia entre requisitos funcionales y requisitos no funcionales de un
sistema software. Define y describe brevemente dos requisitos funcionales y dos requisitos no
funcionales, de diferente tipo, relativos al proyecto realizado durante el curso.
13. Define brevemente el concepto de paradigma de desarrollo de software (tambin denominado

ciclo de vida). Di el nombre de dos paradigmas que conozcas.
14. Di cules son las ventajas e inconvenientes principales, si los hay, del ciclo de vida basado en el
prototipaje en relacin al ciclo de vida clsico.
15. Haz el modelo conceptual de datos con notacin UML de un sistema que gestione un conjunto
de escaleras mecnicas de una gran superficie comercial. Cada escalera se identifica por un cdigo. En
un momento determinado, una escalera puede estar en funcionamiento o en reparacin.
Independientemente de esto, una escalera puede estar subiendo, bajando o parada, pero si est en
reparacin est, necesariamente, parada.
Si una escalera est en reparacin, el sistema guarda cul era el estado (subiendo, bajando, parada)
que tena la escalera en el momento de pasar a reparacin.
16. Considera un modelo conceptual de datos, especificado con notacin UML, de los datos de un
sistema que contiene slo una relacin ternaria R entre las entidades A, B y C. Sean a, b y c
ocurrencias cualesquiera de las entidades A, B y C, respectivamente. Indica cmo se deberan
expresar en este modelo las restricciones siguientes:
1. Ningn c puede participar en ms de 10 ocurrencias de R.
2. Una pareja a,b cualquiera puede estar relacionada, va R, con un mximo de 3 ocurrencias de C.
3. Un tro a,b,c cualquiera puede estar relacionado, va R, como mximo una vez.
110
17. Considera un modelo conceptual de datos, especificado con notacin UML, de los datos de un
sistema que contiene slo una relacin ternaria R entre las entidades A, B y C. Sean a, b y c
ocurrencias cualesquiera de las entidades A, B y C, respectivamente. Indica cmo se deberan
expresar en este modelo las restricciones siguientes:
1. Todos los c han de participar como mnimo en dos ocurrencias de R.
2. Una pareja a,b cualquiera ha de estar relacionada, va R, con un mnimo de 3 ocurrencias de C.
3. Una ocurrencia c cualquiera ha de estar relacionada como mximo con tres ocurrencias distintas de B.
4. Un tro a,b,c cualquiera puede estar relacionado, va R, como mximo una vez, y como mnimo
ninguna.
18. Explica brevemente las diferencias existentes entre los dos modelos conceptuales de datos
siguientes por lo que respecta a la informacin que puede guardarse en r. Ilustra las explicaciones
mediante instanciaciones de los modelos.
0..2
M1
B
y
0..1
- Restricciones de clave: A --> x,

B --> y
- x, y y z son atributos univaluados
0..2
- Restricciones de clave: A --> x,

B --> y
- x, y y z son atributos univaluados
M2
1 Conceptos bsicos
19. Da tres motivos diferentes que justifiquen el hecho de particionar un tipo en subtipos o bien de
definir un supertipo.
20. Considera los modelos conceptuales a) y b) siguientes, especificados con la notacin UML:
a)
b)
Informtico
ProyectoSw
participa-en
Informtico
ProyectoSw
asignar
Etapa
Participacin
asignada
Etapa
Indica cmo se deberan expresar en cada uno de estos modelos a) y b) las restricciones siguientes:
r1- Un informtico est en, como mnimo, tres proyectos.
r2- Un proyecto tiene, como mximo, cuatro informticos para una determinada etapa.
r3- Un informtico no puede estar dos veces en la misma etapa para un determinado
proyecto.
21. Dado el modelo conceptual de la figura siguiente, di cul de las cinco afirmaciones dadas es la
correcta.
Persona
habitante
vive
vivienda
1..*
{subset}
propietario
posee
* propiedad
*
Piso
(a) No puede ser que una persona posea un piso y viva en otro.
(b) Una persona puede vivir slo en aquellos pisos que posea ella misma.
(c) El modelo es incorrecto porque las multiplicidades de las dos asociaciones son incompatibles.
(d) Son ciertas (a) y (b).
(e) Ninguna de las anteriores.
Sesin reserva
Asiento
nombre
fila, butaca
* precio
da, hora *
Claves: Sesin -> (nombre, da, hora)
Aiento -> (fila, butaca)
22. Explica la utilidad de los diagramas de estado de los casos de uso.
23. Dados el curso tpico de eventos y el modelo conceptual siguientes, construye el(los)
diagrama(s) de secuencia correspondiente(s):
111
Caso de uso: Reserva de asientos para una sesin de una obra

Actores: Cliente (iniciador), Empleado
Curso tpico de eventos:
1. El caso de uso se inicia cuando el cliente se
dirige al empleado para reservar asientos para
una sesin de una obra.
2. El empleado introduce los datos de la sesin
(nombre, da y hora).
3. El sistema comprueba la existencia de aquella

sesin y proporciona informacin de todos sus
asientos libres (fila, butaca y precio de cada
asiento).
4. El empleado comunica al cliente la
informacin de los asientos.
5. El cliente dice al empleado qu asientos quiere
reservar.
6. El empleado introduce uno a uno los asientos
que indica el cliente (fila y butaca).
7. Para cada asiento, el sistema comprueba su
disponibilidad y registra la reserva.
112
8. El cliente se va contento -.
24. Justifica por qu los casos de uso correspondientes a la etapa de especificacin se clasifican
siempre como esenciales (en el apartado tipo de la especificacin del caso de uso).
25. Modelo del comportamiento en UML:
a) Es posible en UML que la especificacin del contrato de una operacin no tenga ni precondicin
ni postcondicin, pero en cambio s que tenga salida?
b) Es posible en UML que la especificacin del contrato de una operacin no tenga precondicin,
pero en cambio s que tenga postcondicin?
En ambos casos, justifica brevemente tu respuesta y, si lo crees conveniente, ilstrala mediante un
ejemplo.
26. Di en qu casos es til construir un diagrama de estados para una clase de objetos. Pon un
ejemplo en el que este diagrama no sea til y explica el porqu.
27. En un diagrama de estados UML, tiene sentido especificar una transicin que lleve de un estado
a s mismo como consecuencia de un evento determinado? Justifica tu respuesta y, en caso afirmativo,
pon un ejemplo que ilustre el porqu.
28. Sean los elementos de una especificacin siguientes: diagrama de casos de uso, especificacin de
los casos de uso, esquema conceptual y diagramas de secuencia. Di cules de ellos es imprescindible
consultar para poder hacer los contratos de las operaciones. Justifica brevemente la respuesta.
1 Conceptos bsicos
29. Dados el modelo conceptual, el diagrama de secuencia (para borrar un ejemplar de un libro) y
los contratos (abreviados) siguientes, di qu partes de la precondicin de los contratos sobran (si las
hay) y, si es el caso, di cules faltan. En caso que sobren partes de las precondiciones, indica para
cada una si es redundante o no.
Libro
ISBN
autor
Restricciones textuales:
- ISBN es clave de Libro
- un libro no puede tener dos
ejemplares con el mismo nm
Ejemplar
tiene
nm
1
3..* estado
obtenerLibro(x): l
borraEjemplar(l, n)
obtenerLibro(x): l
pre (1) Libro l con ISBN = x
post --sal l
borrar
borraEjemplar(l, n)
pre (2) l.ISBN = x
(3) el libro l tiene al menos 4 ejemplares
(4) Ejemplar e con nm = n
(5) e.estado = defectuoso
post borrar la instancia (l, e) de la asociacin tiene;
e
30. Cules son las ventajas y los inconvenientes principales, si los hay, del proceso unificado de
desarrollo de software de UML en relacin al ciclo de vida clsico?
31. Cules son las ventajas y los inconvenientes principales, si los hay, del ciclo de vida basado en
el desarrollo incremental e iterativo de UML en relacin al ciclo de vida clsico, en cascada?
32. Enumera criterios de priorizacin de los casos de uso para la etapa de construccin del proceso
unificado de desarrollo de software.
113
2 Modelo conceptual de datos en UML

1. Haz el modelo conceptual de datos con notacin UML de un sistema que contiene el horario y
las asignaturas de la Facultad, de una sola ingeniera.
Una asignatura tiene un cdigo, un nombre y un cierto nmero de crditos (no distinguiremos entre
teora, problemas y laboratorios), y est asignada a un departamento. Las asignaturas pueden ser
obligatorias u opcionales. Las asignaturas pueden estar relacionadas por pre-requisitos, pre/corequisitos y co-requisitos.
115
El horario indica para cada grupo de una asignatura (por ejemplo, Ingeniera del software grupo 10)
qu das de la semana hay clase, en qu aula y a qu horas. Puedes suponer que los periodos de clase
son de una hora. Cada asignatura tiene un cierto nmero de horas de clase (no hace falta distinguir
entre horas de teora, problemas y laboratorios, ni tener en cuenta el concepto de subgrupo).
Expresa grficamente todas las restricciones que puedas. Las restricciones que no se puedan expresar grficamente
y las reglas de derivacin de los atributos derivados, si los hay, especifcalos con el lenguaje OCL.
2. Haz el modelo conceptual de datos con notacin UML de una empresa de transportes que
contiene informacin relativa a rutas, carreteras y poblaciones.
La empresa cubre un mbito geogrfico comprendido por unas 1000 poblaciones. Cada poblacin tiene un
cdigo y un nombre. Estas poblaciones estn unidas por unas 50 carreteras. Cada carretera tiene un cdigo.
Una carretera consta de una serie de tramos consecutivos. De media, hay 100 tramos por carretera. Un tramo
de una carretera se define por las dos poblaciones que une y la distancia en kilmetros entre ellas. Tambin
se considera la duracin del trayecto, en minutos, entre estas dos poblaciones, que, en caso general, puede
ser diferente segn sea un sentido o el otro. Por una misma poblacin pueden pasar diversas carreteras. Un
ejemplo con 9 poblaciones, 3 carreteras y 10 tramos podra ser:
El trayecto que ha de recorrer un camin de la empresa es una ruta. Hay unas 30 rutas, cada una de las
cuales tiene un cdigo. Una ruta parte y acaba en una misma poblacin, y consta de una serie de
tramos consecutivos de la misma o diferentes carreteras, que se han de recorrer en una cierta
direccin. Por ejemplo, la ruta 10 podra ser:
(B,C,autA2),(C,F,com12),(F,E,com12),(E,H,loc1),(H,E,loc1),(E,D,autA2),
(D,C,autA2),(C,B,com12)
autA2
com12
loc1
A
I
D
3. Considera una empresa que se dedica a la fabricacin de aparatos electromecnicos y est

interesada en construir un sistema que incluya, entre otras cosas, informacin sobre la composicin de
los aparatos. Cada aparato consta de una o ms unidades de uno o ms componentes. Un componente
puede ser una materia prima u otro aparato (que al mismo tiempo tendr componentes). Una materia
prima es un producto que se adquiere a un (y slo uno) proveedor, y no es fabricada por la empresa.
Tanto los aparatos como las materias primas tienen un cdigo identificador de tipo string(5) y un
nombre de tipo string(50).
116
Por ejemplo, el aparato A requiere 5 unidades del aparato B, 8 unidades del aparato C y 4 unidades de la materia
prima D (la cual es suministrada por el proveedor P1). El aparato B consta de 10 unidades de la materia prima E
(del proveedor P2). El aparato C consta de una unidad del aparato F, el cual consta de 5 unidades de la meteria
prima G (del proveedor P1).
En la fabricacin de un cierto aparato un componente puede tener ninguno o varios sustitutos. Un

sustituto es otro componente que se puede utilizar si no se dispone del previsto en la fabricacin de un
aparato determinado.
Por ejemplo, si no se dispone de un aparato B cuando se fabrica el A se puede utilizar el F en su lugar.
Un sustituto de un componente que es un aparato puede ser una materia prima u otro aparato. Un
sustituto de un componente que es una materia prima slo puede ser otra materia prima del mismo
proveedor.
Por ejemplo, si no se dispone de la materia prima G cuando se fabrica el aparato F, se puede utilizar en su lugar la
materia prima H. Esta materia prima H es suministrada por P1. Por tanto, cumple la restriccin indicada.
Haz el modelo conceptual de datos de este sistema con notacin UML. Expresa grficamente todas las
restricciones que puedas. Las restricciones que no se puedan expresar grficamente y las reglas de
derivacin de los atributos derivados, si los hay, especifcalos con el lenguaje OCL. Has de indicar
tambin, necesariamente, la instanciacin del modelo con los datos del ejemplo que se ha dado. Si al
hacer este ejercicio necesitas ms informacin, haz las suposiciones que creas ms adecuadas e
indcalas bien claramente.
4. Considera un comit organizador de un congreso que est interesado en construir un sistema que
incluya, entre otras cosas, informacin sobre las ponencias que se presentarn. Cada ponencia tiene un
cdigo y un ttulo y est escrita por uno o ms autores. Una vez recibidas, cada ponencia se enva a
uno o ms revisores. Los revisores no pueden ser autores de ninguna ponencia. Al cabo de un tiempo, los
revisores envan sus informes de cada ponencia que han de revisar. A veces, un revisor no enva ninguno
de los informes, o no enva alguno de los que tena que hacer. De todas maneras, siempre se tiene al
menos un informe de cada ponencia. Cada informe, cuando se recibe, da una puntuacin (de 0 a 10) de la
ponencia y clasifica la ponencia en una de las sesiones que habr en el congreso. Cada sesin
corresponde a uno de los das del congreso, con una hora inicial y una hora final.
Por ejemplo, la ponencia 10, de ttulo YSM, est escrita por los autores A1 y A2. La ponencia se envia a los
revisores Ra, Rb y Rc. El primero le da un 5 y la clasifica en la sesin Anlisis Estructurada Moderna. El segundo
le da un 8 y la clasifica en la sesin Nuevos mtodos de especificacin. El tercero se olvid de enviar el informe.
La ponencia 23, de ttulo La importancia de los eventos, est escrita por los autores A2 y A5 y se enva al revisor
Rb, que no contesta, y al Rd, que la califica con un 3 y la clasifica en la sesin Nuevos mtodos de especificacin.
De cada autor o revisor, el sistema tiene un cdigo identificador, su nombre y su direccin.

En una cierta fecha, el comit se rene y, partiendo de los informes, decide qu ponencias acepta y
cules rechaza. Las ponencias aceptadas se asignan a una sesin, que ha de ser una de las sugeridas
por los revisores. Para las ponencias rechazadas, se guarda el motivo. Todas las ponencias acaban
siendo aceptadas o rechazadas.
Por ejemplo, se decide aceptar la ponencia 10 y asignarla a la sesin Anlisis estructurada moderna. La sesin
Anlisis estructurada moderna se har el da 29/04/03, de 11 a 13. La ponencia 23 se rechaza por el motivo
demasiado larga.
Haz el modelo conceptual de datos de este sistema con la notacin UML. Expresa grficamente todas
las restricciones que puedas. Las restricciones que no se puedan expresar grficamente y las reglas de
indcalas claramente.
5. Considera el caso de una federacin de ciclismo que quiere construir un sistema que trate, entre
otras cosas, los resultados de las carreras ciclistas. Las carreras se organizan en ediciones de series.
Cada serie consta de ediciones, que se van haciendo peridicamente. Una serie se identifica por un
nombre y una edicin por la serie y el ao. Una edicin consta de un conjunto de etapas, que varan de
una edicin a otra. Cada etapa tiene un nmero de etapa, una longitud, una poblacin de inicio y una
poblacin final.
Por ejemplo, de la serie Volta a Catalunya se han hecho tres ediciones. La tercera edicin tena dos etapas. La
primera iba de Barcelona a Montserrat (50 Km.) y la segunda de Montserrat a Poblet (200 Km.).
Otro ejemplo puede ser la serie Tour de France, de la cual se han hecho 20 ediciones. La ltima tena cinco
etapas. La primera de stas iba de Pars a Lin, etc.
Interesa tambin que el sistema registre los ciclistas y su participacin en las carreras. De cada ciclista
se deber saber su nombre, fecha de nacimiento, etc. Cada ciclista que participa en una carrera la
puede acabar o no. Si la acaba es en una cierta posicin (clasificacin) y si no la acaba es por un cierto
motivo, e interesa saber en qu etapa corri por ltima vez. Tambin se debe guardar el resultado de
117
los ciclistas en cada etapa. Como es obvio, un ciclista slo puede tener un resultado en una etapa si
participaba en la carrera correspondiente.
Por ejemplo, los ciclistas C1, C2 y C3 participan en la tercera edicin de la Volta a Catalunya. C3 fue el
primero, C1 el segundo y C2 no acab, por enfermedad. La ltima etapa que hizo fue la de Barcelona a
Montserrat. En la primera etapa el primero fue C3, el segundo C2 y el tercero C1. En la segunda etapa, el
primero fue C3 y el segundo C1.
Algunas etapas tienen Premio de Montaa en la meta. Para estas etapas, se debe registrar cul de los
ciclistas que particip gan el premio.
Por ejemplo, la etapa Barcelona-Montserrat de la carrera que estamos considerando tena este premio (la otra, no).
El premio lo gan C2, que, naturalmente, haba participado en la etapa.
118
6. Considera una empresa que est interesada en construir un sistema que incluya, entre otras cosas,
informacin sobre sus empleados. Cada empleado tiene un nmero de documento de identidad, un
nombre y una direccin. Los empleados estn asignados a un, y slo uno, departamento. Cada
departamento tiene un nombre. Los departamentos estn estructurados jerrquicamente, y cada
departamento puede depender como mximo de otro departamento. Cada departamento tiene un nico
director, que ha de ser uno de los empleados que le estn asignados.
Por ejemplo, Juan, Mara, Rosa, Alberto y Jorge son empleados de la empresa. Juan trabaja en el departamento de
Ventas, Mara en el Servicio Tcnico Postventa, Rosa en el Laboratorio, y Alberto y Jorge en Recepcin. Ventas
depende de Direccin Comercial que, a su vez, depende de Direccin General. El Servicio Tcnico Postventa
depende de Ventas, etc. La directora del Laboratorio es Rosa. El director de Recepcin es Jordi.
Cada empleado es de una sola categora determinada. Slo hay tres categoras: Vendedor, Tcnico
y Administrativo. De cada categora se han de guardar los das de vacaciones y el plus del sueldo
que tienen.
Por ejemplo, la categora Vendedor tiene 30 das de vacaciones y un plus de 60 euros. La categora Administrativo
tiene 20 das de vacaciones y 120 euros de plus. Juan es vendedor, Mara y Rosa son tcnicos y Alberto es
administrativo.
Para los empleados que son vendedores se ha de registrar la zona donde trabajan. Una zona tiene
un cdigo y un nombre. Un vendedor slo trabaja en una zona. Para los empleados que son
tcnicos se han de registrar los estudios que tienen. Cada estudio tiene un cdigo, un nombre y el
Centro donde se imparte. Un mismo tcnico puede tener diversos estudios. Para los empleados que
son administrativos se han de registrar los cursos de perfeccionamiento que han hecho. Cada curso
tiene tambin un cdigo, un ttulo y una fecha de realizacin. Un mismo administrativo puede
haber hecho diversos cursos.
Por ejemplo, Juan trabaja en la zona de Gerona. Mara tiene los estudios de ingeniera en informtica, y Rosa los de
elecrnica y los de mecnica. Alberto ha hecho dos cursos de perfeccionamiento: mecanografa y archivo.
7. Considera el caso de un aficionado a la msica rock que quiere construir un sistema que gestione
informacin sobre su fonoteca. El sistema ha de permitir guardar y consultar datos sobre los discos
(compactos, eleps o cassettes) y sus intrpretes.
Los discos son editados por casas discogrficas. Cada casa discogrfica se identifica por un nombre, y
cada disco se identifica por un cdigo alfanumrico y tambin tiene un nombre. Los discos se
estructuran en secuencias de cortes. Un corte es una grabacin continuada, normalmente de una nica
cancin, y se identifica mediante un cdigo alfanumrico.
Tambin tienen un nombre y una fecha de grabacin. En un disco compacto hay una sola secuencia de
cortes y cada corte aparece en una cierta posicin de la secuencia. En un LP o un cassette hay una
secuencia de cortes por cada cara y cada corte aparece en una posicin de una cara. Un mismo corte
puede aparecer en diversos discos (por ejemplo, en el disco original y en una recopilacin) pero no
puede aparecer ms de una vez en el mismo disco.
Por ejemplo, la casa discogrfica Zafiro ha editado el disco compacto D1 y el disco LP D2. D1 tiene la cancin C1
como primer corte y la cancin C2 como segundo corte. El disco D2 tiene la cancin C1 como primer corte de la
primera cara, y la cancin C3 como primer corte de la segunda cara, y no tiene ms cortes.
Tambin se quiere tener informacin sobre los intrpretes de cada corte. Un intrprete se identifica
mediante un cdigo alfanumrico; tiene un nombre, un ao de nacimiento y, si ya est muerto, un ao
de defuncin. Un intrprete puede participar en la grabacin de un corte interpretando diversos
papeles (vocal, guitarra solista, piano, batera, etc.), pero un instrumento determinado de un corte slo
lo puede tocar un intrprete. Desgraciadamente, a veces se desconocen los intrpretes de un corte, o
los instrumentos que han tocado.
Por ejemplo, el intrprete I1 naci el ao 1930 y todava vive. I2 naci el 1920 y muri el 1965. Ambos
participaban en la grabacin de C1: I1 como vocalista y piano, e I2 como batera.
8. Considera el caso de una compaa ferroviaria que quiere construir un sistema que mantenga los
horarios previstos de sus trenes y los horarios reales.
119
Cada lnea de tren tiene un cdigo que la identifica, un tipo de tren, una estacin de origen y una hora de
salida (prevista). Supondremos que cada lnea de tren circula diariamente. Cada lnea consta de una serie
de tramos, que van de una estacin a otra. Las estaciones se identifican por un cdigo. Como mnimo hay
un tramo, que sale de la estacin origen de la lnea. Para cada tramo de una lnea, nos interesar mantener
la hora de salida prevista de la estacin origen y la hora de llegada prevista a la estacin destino.
Podemos suponer que la hora de llegada y la de salida de una estacin son del mismo da.
Por ejemplo, la lnea R12 sale de Manresa, cada da a las 10:00. Es un tren Talgo y consta de dos tramos. Va de
Manresa a Tarrasa (a donde ha de llegar a las 10:15 y salir a las 10:17) y de Tarrasa a Barcelona (a donde ha de
llegar a las 10:31).
La lnea C240 sale de Barcelona, cada da a las 23:00. Es un tren correo y consta de 3 tramos. Va de Barcelona a
Tarrasa (a donde ha de llegar a las 23:20 y salir a las 23:30), de all a Monistrol (a donde ha de llegar a las 00:05 y
salir a las 00:15) y de aqu a Sant Vicen de Castellet (a donde ha de llegar a las 01:00).
Cada da, el jefe de la estacin origen de una lnea de tren registra la hora de salida real del tren y se la
comunica inmediatamente al sistema. Si el tren no ha podido salir (es decir, se se ha cancelado) se
apunta el motivo. Todos estos datos, y los que se mencionan posteriormente, se han de registrar en el
sistema, a efectos de informacin al pblico y estadsticos. Supondremos que, si los trenes salen de la
estacin origen, acaban llegando a la estacin final.
120
Por ejemplo, el da 26/04/03 el tren de la lnea R12 sali de Manresa a las 10:01. En cambio, el da 27/04/03 este
tren no pudo salir por Tormenta.
En cada estacin que para un tren, el jefe de estacin correspondiente registra la hora real de llegada
y, si no es la estacin final, la hora real de salida, y tambin se lo comunica inmediatamente al sistema.
Como es natural, los trenes slo paran en las estaciones en que est previsto que paren.
Por ejemplo, el tren de la lnea R12 del da 26/04/03 lleg a Tarrasa a las 10:14 y sali a las 10:17. El mismo tren
lleg a Barcelona a las 10:33.
Finalmente, si el maquinista observa alguna anomala en un tramo, registra el tramo correspondiente

(que ser un tramo de la lnea), la hora de observacin y la anomala detectada. Estas observaciones se
comunican al sistema al llegar el tren a la estacin final.
Por ejemplo, en el tramo de Tarrasa a Barcelona, el maquinista del tren de la lnea R12, del da 26/04/03, observ
que Hay un corte de corriente a las 10:23.
9. Considera una compaa de seguros que est interesada en un sistema para el control de los
siniestros en que intervienen los coches que tiene asegurados. Un siniestro lo tiene un coche
determinado, siendo conducido por una cierta persona, y ocurre en una cierta fecha. La compaa
identifica los coches por su matrcula, y necesita registrar su marca y su modelo, entre otros datos. Las
personas se identifican por su documento de identidad, registrndose tambin otros datos como su
nombre y su direccin. No es imposible que un coche tenga dos siniestros, con el mismo o diferente
conductor, pero sera en das diferentes.
Por ejemplo, el coche 10 (marca Renault, modelo R6) tuvo un siniestro el da 10/10/02, cuando lo conduca Juan.
Algunos siniestros requieren que el coche accidentado se lleve a un (o ms) taller(es) para su
reparacin. La compaa tiene fichados los talleres posibles, con un cdigo identificador, su nombre
comercial, direccin, etc. No todos los siniestros acaban con el coche en un taller. La compaa indica
a qu talleres se ha de llevar el coche y los das en que se ha de llevar. El sistema ha de anotar dnde
se asignan los coches.
Por ejemplo, como consecuencia del siniestro anterior, haba que llevar el coche a dos talleres. Primero, el da
15/10/02, a El Mecnico, y despus, el 20/10/02, a El Pintor de Coches.
Un taller tratar de reparar el coche siniestrado, en la parte que le corresponda. Para ello emplear un
cierto nmero de horas de mano de obra. Por otro lado, la reparacin puede exigir (aunque no
siempre) el uso de unas ciertas cantidades de materiales determinados. La compaa tiene codificados
estos materiales, y para cada uno de ellos tiene tambin su nombre y su precio unitario. Cuando un
taller acaba una reparacin, lo comunica a la compaa, indicando los datos mencionados, que el
sistema ha de registrar.
Por ejemplo, la reparacin indicada anteriormente requiri en el taller El Pintor de Coches 15 horas de mano de
obra y el uso de 2 litros de pintura azul y 1 litro de pintura blanca. La pintura azul tiene el cdigo ABC y est a 6
euros el litro, etc.
De vez en cuando, los talleres facturan a la compaa de seguros las reparaciones que han
hecho. Una factura puede incluir diversas reparaciones, pero una reparacin slo puede estar
incluida en una factura (las reparaciones no se facturan parcialmente). De cada factura se
guarda su nmero y la fecha de la factura. El sistema ha de poder saber, de una forma u otra,
el cdigo del taller emisor de la factura. Una factura no puede incluir reparaciones de dos o
ms talleres distintos.
Por ejemplo, el taller El Pintor de Coches nombrado emiti la factura n 100 el da 30/12/02. La factura inclua la
reparacin anterior y la de otros coches.
10. Considera una mutua sanitaria que est interesada en un sistema para el control de los ingresos
hospitalarios en que intervienen sus socios. Un ingreso es de una persona determinada en un cierto
centro mdico y ocurre en una cierta fecha. La mutua identifica sus socios por el nmero de asociado
y guarda tambin su nombre y su direccin. Los centros mdicos se identifican por su nombre y se
121
guarda tambin la informacin de si el centro tiene firmado un convenio o no con la mutua. Es

imposible que una misma persona tenga dos ingresos en centros mdicos en una misma fecha, aunque
s puede tener diversos ingresos en fechas distintas.
Por ejemplo, la socio nmero 17 (nombre Mara, direccin C/Diputacin) fue ingresada en el hospital de Santa
Mara del Mar (que no tiene convenio con la mutua) el da 8/8/2003.
Los ingresos requieren que a la persona ingresada se le administren uno o ms medicamentos para
su curacin. El sistema guarda informacin de los posibles medicamentos, que tienen un cdigo
identificador, un nombre y un precio unitario. Todos los ingresos requieren la administracin de
algn medicamento, indicndose en cada caso cul es el nombre diario de unidades a administrar y
la fecha de inicio y la fecha final de administracin. Un mismo medicamento se puede administrar
en diversas ocasiones durante un ingreso. El sistema ha de registrar nicamente cules son los
medicamentos administrados a un paciente que est ingresado en un centro que no tiene convenio
con la mutua.
Por ejemplo, como consecuencia del ingreso anterior, la socio 17 recibi tres medicamentos. El medicamento 3,
en una cantidad de 3 unidades diarias, desde el da 8/8/2003 hasta el 10/8/2003. El medicamento 5, en una
cantidad de 5 unidades diarias, desde el da 8/8/2003 hasta el 11/8/2003. Finalmente, una segunda
administracin del medicamento 3, en una cantidad de 7 unidades diarias, desde el da 12/8/2003 hasta el
14/8/2003.
122
El sistema conoce tambin los medicamentos que son incompatibles para los socios. Un socio puede
tener ms de un medicamento incompatible y se registrar, para cada medicamento, el motivo de la
incompatibilidad. Durante un ingreso, no se pueden administrar a un socio medicamentos que sean
incompatibles.
Por ejemplo, el medicamento 33 es incompatible para la socio 17 ya que contiene penicilina.
11. Considera que la federacin de hockey sobre patines est interesada en el control de los partidos
que se disputan en el transcurso de una liga. Para simplificar, supondremos que conviene registrar
solamente la informacin correspondiente a una nica liga. Un partido de hockey sobre patines se
celebra entre un equipo que juega en casa y un equipo que juega fuera. Un partido corresponde a una
determinada jornada. En una jornada se juegan siempre ocho partidos. Los equipos se identifican por
su nombre y se registra tambin su direccin y el color de la camiseta. Las jornadas se identifican por
un nmero de jornada. Es imposible que un mismo equipo juegue dos partidos diferentes en una
misma jornada. Tampoco puede ser que un equipo juegue en su campo dos jornadas distintas contra el
mismo equipo visitante.
Por ejemplo, el equipo Vic (direccin C/Guilleries, color blanco) jug contra el equipo Voltreg (direccin C/
Osona, color azul) en la jornada 3. El Tordera es un equipo de hockey con direccin C/ Riera y color amarillo.
La federacin tambin quiere guardar informacin de los jugadores que juegan los partidos de la liga
y de los rbitros que arbitran estos partidos. Tanto jugadores como rbitros se identifican por su
documento de identidad, y se registra tambin su nombre en ambos casos. No puede ser que alguien
sea jugador y rbitro al mismo tiempo. En el caso de los jugadores hay que registrar tambin cul es
su posicin (puedes suponer que un jugador tiene una nica posicin: portero, defensa, medio, etc.) y
el nombre del equipo al que pertenece. La federacin de hockey sobre patines quiere registrar tambin
la informacin de los rbitros que estn recusados por los diversos equipos. En una liga los equipos
pueden recusar un mximo de 3 rbitros si consideran que stos les han perjudicado en ligas
anteriores, guardndose en cada caso el motivo de la recusacin.
Por ejemplo, Juan tiene el DNI 111, es portero y pertenece al Vic. Pedro tiene el DNI 222, es delantero y pertenece
al Voltreg. Oriol tiene el DNI 333 y es rbitro. El Tordera ha recusado a Oriol porque les pit un penalti injusto.
Los jugadores de los equipos participan en partidos durante un determinado nmero de minutos. Un
jugador slo puede participar en partidos en los que juega su equipo. Adems, hay que registrar
tambin la informacin del nmero de goles marcados por un jugador en un partido. Un jugador slo
puede marcar goles en los partidos en los que participa. El sistema conoce tambin los rbitros que
arbitran los partidos y cul es la calificacin otorgada al rbitro cada vez que pita un partido. Un
rbitro puede arbitrar ms de un partido (siempre que sean de jornadas distintas) y un partido lo
arbitra un nico rbitro. Un rbitro no puede pitar un partido en el que juega un equipo que lo ha
recusado.
123
Por ejemplo, Juan jug 40 minutos y Pedro 25 del partido mencionado anteriormente. Pedro marc 3 goles en este
partido. El partido fue arbitrado por Oriol, que fue calificado con Notable.
12. Considera el caso de una entidad bancaria que est interesada en un sistema para el control de
peticiones y de concesiones de prstamos hipotecarios. Los prstamos solicitados se identifican por
un cdigo y se registra tambin la cantidad de dinero solicitada y el nmero de aos en que se
devolver el prstamo. Un prstamo est solicitado por una o ms personas. Las personas se
identifican por su nombre y se guarda tambin informacin de su direccin y edad. Todo prstamo
tiene un nico primer titular. El primer titular de un prstamo ha de ser una de las personas que lo
ha solicitado.
Por ejemplo, Juan (direccin C/ Valencia, 25 aos) y Mara (C/ Prat, 24 aos) han solicitado el prstamo con
cdigo 111 (por un valor de 180.000 euros, a devolver en 15 aos). Mara es el primer titular de este prstamo.
Carmen (C/ Balmes, 27 aos) ha solicitado el prstamo 222 (300.000 euros, 20 aos) y es el primer y nico titular.
Los prstamos solicitados son asignados a uno o ms evaluadores (que se identifican por su nombre y
de los cuales se conoce tambin su direccin y edad) para que los estudien. Un evaluador no puede
haber solicitado ningn prstamo en aquella entidad bancaria. Al cabo de un tiempo, los evaluadores
envan los informes de los prstamos que les han sido asignados. A veces, un evaluador no enva
alguno de los informes que se le haban asignado. Cada informe, cuando se recibe, dice si el evaluador
aconseja o no la concesin del prstamo. En caso afirmativo, hay que indicar tambin el tipo de
inters con el cual se debera hacer efectivo el prstamo, y en caso negativo el motivo por el cual no se
debera conceder el prstamo.
Por ejemplo, el prstamo 111 se ha asignado a los evaluadores Jorge, Ana y Rosario. Jorge y Rosario consideran
que hay que conceder el prstamo con un inters del 5,5% y 6%, respectivamente, y Ana no enva el informe
preceptivo. Por otro lado, el prstamo 222 se enva a los revisores Pablo y Ana, que envan un informe negativo con
el motivo de que se ha solicitado una cantidad excesiva.
En una cierta fecha, la entidad bancaria decide si conceder o no un prstamo solicitado a partir de
los informes de los evaluadores. A los prstamos concedidos se les asigna un tipo de inters igual
al promedio de los tipos de inters sugeridos por los revisores que haban emitido un informe
positivo. Para los prstamos denegados, hay que registrar el motivo por el cual la entidad bancaria
ha decidido no concederlos. Un prstamo no se puede conceder si tiene un mnimo de dos informes
negativos. Hay que guardar tambin informacin de la fecha en que se ha hecho la evaluacin del
prstamo. Para los prstamos concedidos, hay que guardar tambin la informacin de la cuenta
corriente de la cual se habr de extraer el dinero (nica para cada prstamo, identificada por
nmero de cuenta) y el da del mes en que se efectuar el traspaso del dinero de la cuenta a la
entidad bancaria.
124
Por ejemplo, el prstamo 111 ha sido condedido el da 5/4/03 con un inters del 5,75%. El pago de este prstamo se
har a partir de la cuenta C567, el da 4 de cada mes. El prstamo 222 ha sido denegado el da 7/4/03 porque lo
haba solicitado una nica persona.
13. Considera el caso de una compaa propietaria de diversos teatros y que est interesada en un
sistema para el control de las compras de entradas de las obras que se representan en sus teatros. Las
obras de teatro se identifican por su nombre y se registra tambin su autor, su director y el nmero de
actores que intervienen. Las obras de teatro se representan en diversas sesiones (cada una de las cuales
se identifica por el da y por el orden dentro del da) y en un determinado teatro. Hay que guardar
tambin la informacin de la hora de inicio de la representacin.
Los teatros se identifican por su nombre y se registra tambin su aforo (nmero total de butacas
de que dispone) y la ciudad donde se encuentran. En un mismo da no se pueden representar
obras de teatro diferentes en un mismo teatro. Una obra de teatro no se puede proyectar en tatros
diferentes un mismo da. En una determinada representacin de un teatro se representa una nica
obra.
Por ejemplo, el teatro Monumental est en Figueras y tiene un aforo de 400 butacas. La obra El visitante es de E.
Schmidt, est dirigida por R. M. Sard y participan 25 actores. En la tercera sesin del 26/4/03 se representar en el
teatro Monumental la obra El visitante. Esta representacin comenzar a las 21 horas.
Cada teatro tiene un cierto nmero de butacas, cada una de las cuales se identifica (para un teatro
determinado) por el nmero de la fila y el nmero de asiento en la fila. El sistema ha de guardar
tambin la informacin de las entradas que se han vendido para una determinada representacin. Las
entradas se pueden vender de dos maneras distintas: directamente en ventanilla o bien por telfono.
Para las entradas vendidas directamente en ventanilla hay que registrar la representacin para la cual
se ha vendido la entrada y la butaca asignada.
En el caso de entradas vendidas por telfono hay que registrar la misma informacin que para el caso
de entradas vendidas en ventanilla y, adems, el nmero de documento de identidad de la persona que
ha comprado la entrada y el nmero de tarjeta de crdito a la que hay que hacer el cargo de la venta.
En una representacin no se pueden vender entradas para las que se asigne una butaca que no exista
en el teatro donde se hace la representacin.
Por ejemplo, se han vendido tres entradas de la representacin anterior: dos a ventanilla y una por telfono. Las
entradas vendidas a ventanilla ocupan las butacas (1,18) y (1,20), donde 1 corresponde al nmero de fila y 18 y 20
al nmero de asiento en la fila. La entrada vendida por telfono ocupa la butaca (5,20), ha sido comprada por una
persona con documento de identidad 111, y se ha de cargar a la tarjeta de crdito 333.
El sistema ha de almacenar tambin informacin de las personas que estn abonadas a la compaa.
Un abonado se identifica por su documento de identidad y se registra tambin su nombre y su
direccin. Slo pueden comprar entradas por telfono las personas que estn abonadas a la compaa
propietaria del teatro.
Por ejemplo, Juan est abonado a la compaa, tiene el documento de identidad 111 y vive en la C/ Matadero.
14. Considera una federacin de entidades excursionistas que est interesada en un sistema para el
control de las expediciones efectuadas para los centros excursionistas adscritos a la federacin. Una
expedicin la efecta un centro excursionista a una cierta montaa, con una fecha de inicio y una de
finalizacin. La federacin identifica los centros excursionistas por su nombre y registra tambin su
direccin. Las montaas se identifican por su nombre y se registra tambin su altitud. Un centro
excursionista puede efectuar diversas expediciones a la misma montaa, en fechas diferentes. A una
montaa se pueden hacer diversas expediciones, pero en una fecha concreta slo puede haber un
mximo de 5 expediciones.
Por ejemplo, el centro excursionista CEC (direccin Gran Va) efectu una expedicin al Everest (altitud 8848 m.)
del da 5/5/2003 al 20/7/2003.
En una expedicin participan diversas personas (como mnimo una). Una persona puede participar en
ms de una expedicin. El sistema guarda informacin de todas las personas (que tienen el dni como
identificador, un nombre y una edad) que han participado en alguna expedicin. Alguno de los
componentes de una expedicin puede alcanzar la cima. En este caso, se registrar este hecho y
125
tambin la fecha en que se ha alcanzado la cima. Una persona puede alcanzar la cima ms de una vez
en una misma expedicin.
Por ejemplo, las personas con DNI 111 (nombre Juan, edad 25 aos), 222 (Mara, 23), 333 (Pedro, 24) y 444 (Ana,
22) participaron en la expedicin anterior. Las personas 111 y 222 alcanzaron la cima el da 24/6/2003. Adems, la
persona 222 volvi a llegar a la cima el da 30/6/2003.
Cuando una persona participa en una expedicin juega un determinado papel. Para simplificar,
supondremos que los posibles papeles son: mdico, alpinista, encargado de material y jefe de
expedicin. En una expedicin un papel puede ser interpretado por ms de una persona. Una misma
persona puede interpretar ms de un papel en una expedicin. No todos los papeles tienen por qu
interpretarse en una expedicin.
Cuando una persona hace de alpinista en una expedicin, el sistema ha de registrar tambin el seguro
mdico (que tiene un nombre de seguro identificador y el nombre de la mutua que la cubre) contratada
para la ocasin. En el caso de que una persona de una expedicin haga de mdico, hay que registrar
tambin el nombre del centro mdico en el que trabaja actualmente (que supondremos que es nico).
Por ejemplo, las cuatro personas eran alpinistas en la expedicin anterior y tenan un seguro de nombre Accidentes
en el Himalaya (cubierta por la Mutua de Tarrasa). La persona 222 era el mdico de la expedicin y trabajaba en el
Hospital del Mar. La persona 444 era el jefe de la expedicin.
126
15. Considera que un club de tenis est interesado en el control de los partidos que disputan sus
socios en el torneo social del club. Para simplificar, supondremos que conviene registrar slo la
informacin correspondiente a un nico torneo. Un partido de tenis se celebra entre dos socios y
corresponde a una determinada jornada. En una jornada se juegan siempre veinte partidos. Los
socios se identifican por su nombre y se registra tambin su direccin y edad. Las jornadas se
identifican por un nmero de jornada. Es imposible que un mismo socio juegue dos partidos
diferentes en una misma jornada. Tampoco puede ser que dos jugadores se enfrenten entre ellos en
dos jornadas distintas.
Por ejemplo, Juan (direccin C/ Guilleries, 27 aos) jug contra Jos (C/ Osona, 25 aos) en la jornada 3.
El club de tenis quiere guardar tambin informacin de los jueces principales que arbitran los partidos
disputados. Los jueces, como los socios, se identifican por su nombre y se registra tambin su
direccin y edad. No puede ser que alguien sea socio del club de tenis y juez de la competicin a la
vez. El club de tenis quiere registrar tambin la informacin de los jueces que han sido recusados por
los socios.
En un torneo los socios pueden recusar hasta un mximo de 5 jueces si consideran que stos les han
perjudicado en torneos anteriores, registrndose para cada caso el motivo de la recusacin. El
sistema conoce tambin los jueces que arbitran los partidos y cul es la calificacin otorgada al
juez cada vez que arbitra un partido. Un juez puede arbitrar ms de un partido, y un partido lo
arbitra un nico juez. Un juez no puede arbitrar un partido en el que participe un jugador que lo
haya recusado.
Por ejemplo, Oriol vive en C/ Tortosa, tiene 29 aos y es juez. Mara vive en C/ del Mar, tiene 29 aos y es juez.
Juan ha recusado a Oriol porque el ao pasado le hizo perder un partido. El partido entre Juan y Jos fue arbitrado
por Mara, que fue calificada con Excelente.
Cada partido de tenis se disputa al mejor de tres sets. Gana el partido el primer jugador que gane dos
sets. El club de tenis quiere guardar tambin informacin de los resultados de todos los sets de un
partido y, en caso que un set se decida por tie-break (es decir, si el resultado final del set es de 7-6),
hay que guardar tambin el resultado del tie-break.
Por ejemplo, el partido entre Juan y Jos dur tres sets. El primero lo gan Juan por 6 a 2. El segundo lo gan Jos
por 7 a 6 (7-2 en el tie-break). El tercero lo volvi a ganar Jos por 6 a 3.
16. Considera el caso de una biblioteca que est interesada en el control de los prstamos y de las
reservas que efectan sus usuarios. La biblioteca dispone de un amplio fondo bibliogrfico de
libros y de un gran nmero de ejemplares de cada libro. Los libros se identifican por su ttulo (esto
lo hacemos para simplificar) y se registra tambin su autor y el nombre de la editorial. Los
ejemplares de un libro se identifican por un nmero de ejemplar correlativo (comenzando desde el
1) dentro de cada libro.
Por ejemplo, del libro titulado Oriente, Occidente (escrito por M. de la Pau Janer y publicado por la editorial
Columna) se tienen dos ejemplares: el 1 y el 2. Del libro El Atlas furtivo (Alfred Bosch, Columna) se tienen cinco
ejemplares: el 1, el 2, el 3, el 4 y el 5.
La biblioteca admite que todos sus usuarios puedan hacer tanto prstamos como reservas. Un usuario
se identifica por un nmero de usuario y el sistema guarda tambin informacin de su nombre y
direccin. Una reserva la hace un usuario, para un libro determinado, con una fecha de recogida de la
reserva y se indica tambin el nmero de das reservados. Un prstamo la hace un usuario, para un
ejemplar de libro determinado, en una cierta fecha y se indica tambin la fecha lmite en que el usuario
puede devolver el ejemplar que se lleva prestado.
Un usuario puede hacer como mximo 3 reservas para una misma fecha. Un usuario puede hacer un
nico prstamo de un mismo ejemplar en un mismo da. Un mismo ejemplar de un libro en un cierto
da se puede prestar a como mximo una nica persona. No se puede hacer una reserva de un libro si
no queda ningn ejemplar disponible de aquel libro durante todo el periodo para el cual se quiere
reservar. No se puede prestar un ejemplar si no est disponible durante todo el periodo de prstamo o
bien si hacer efectivo este prstamo afecta la disponibilidad de las reservas ya hechas.
127
Por ejemplo, el socio nmero 22 (de nombre Bernardo y direccin C/ Cristina) ha hecho dos prstamos distintos del
ejemplar 3 del libro El Atlas furtivo. El primero de estos prstamos lo hizo el da 1/9/02 con fecha mxima de
devolucin el 15/9/02. El segundo lo hizo el da 20/1/03 con fecha mxima de devolucin el 20/2/03. El rocio 33
(Ruth, C/ Buenaventura) ha hecho una reserva del libro El Atlas furtivo con fecha de recogida el 10/2/03 y para un
total de 15 das.
Los prstamos que se han hecho se devuelven en una cierta fecha. El sistema ha de registrar qu
prstamos se han devuelto y la fecha en que se hizo efectiva la devolucin. Las reservas que se hacen
se pueden recoger en la fecha que se haba indicado al hacer la reserva. El sistema ha de registrar el
ejemplar del libro que se ha asignado a la reserva. Una reserva slo se puede recoger en la fecha de
recogida que se haba indicado inicialmente (es decir, ni antes ni despus).
Por ejemplo, el primero de los prstamos que haba hecho el socio 22 fue devuelto el da 14/9/02. La reserva que
haba hecho la socio 33 del libro El Atlas furtivo fue recogida el da 10/2/03 y se le asign el ejemplar nmero 5 de
aquel libro.
128
17. Considera el caso de una guardera que est interesada en construir un sistema que incluya, entre
otras cosas, informacin sobre los nios que tiene a su cargo. Cada nio tiene un nombre, que lo
identifica, una direccin y una fecha de nacimiento. Los nios tienen diversas personas adultas que
son sus responsables y que los pueden recoger en la escuela. De cada adulto que es responsable de
algn nio, la guardera quiere conocer su nombre (que lo identifica), su nmero de telfono y el tipo
de responsabilidad que ejerce respecto al nio (padre, madre, abuelo, abuela, canguro, etc.). Como te
puedes imaginar, hay adultos que son responsables de ms de un nio (por ejemplo, de hermanos que
van juntos a la guardera). Cada nio est incluido en la cobertura mdica de un adulto, que ha de ser
uno de sus adultos responsables. En este caso es necesario conocer el nmero de seguridad social (o
pliza mdica) del adulto.
Por ejemplo, Alberto, Iris, Judith y Ariadna son nios de la guardera. Alberto tiene tres adultos responsables: su
madre (Mara), su padre (Jos) y su abuela (Concepcin), y est incluida en la pliza mdica de Jos (nmero
5643578).
Cada nio est asignado a una (sola) clase. Slo hay tres clases: Bebs, Pulgarcitos y Lobos. De cada
clase se ha de conocer su nombre, el nombre de la educadora y el aula que ocupa. No puede ser que un
nio de ms de un ao sea beb. Para los nios que son bebs hay que registrar la leche que toman (las
leches se identifican por su nombre y se guarda tambin su composicin). Para los bebs y los pulgarcitos
se debe conocer los paales que usan (que tambin se identifican por su nombre y se guarda informacin
tambin de las posibles contraindicaciones). Un nio puede usar diferentes tipos de paales.
Por ejemplo, la clase de los Lobos la lleva Dolores y ocupa el aula A1; la de los Bebs la lleva Carmen y ocupa el aula
A2; y la de los Pulgarcitos la lleva Isabel y ocupa el aula A3. Ariadna es un Beb, Iris es un Pulgarcito y Alberto y
Judith son Lobos. Ariadna toma la leche Dorlat y usa los paales Dodot y Ausonia. Iris usa los paales Dodot.
Para coordinarse entre ellos, los padres de los nios de cada clase organizan una cadena de
comunicacin, que ha de estar registrada. De esta manera, cuando es necesario que todo el mundo se
entere de algo, se llaman los unos a los otros en el orden que establece la cadena. En una cadena,
todos los nios son de la misma clase. Adems, en la guardera se hacen informes diarios de cada nio
donde se indica: cmo ha dormido la siesta (bien o mal) y cmo ha comido (todo, poco o nada). A
veces puede ocurrir que un da no se haga el informe de algn nio.
Por ejemplo, en la clase de los Lobos la primera de la cadena es Judith, la sigue Alberto y as sucesivamente hasta
completar todos los nios de la clase. El da 1/11/02 Alberto se lo comi todo y durmi bien la siesta. En cambio, el
da 2/11/02 Alberto durmi mal la siesta y no comi nada.
18. Considera un centro de enseanza que est interesado en un sistema para la gestin de las
preguntas que se hacen en los exmenes efectuados en el centro. Un examen corresponde a una
cierta asignatura, a un cierto curso en el que la asignatura se imparte y se realiza en una fecha
determinada. El centro identifica las asignaturas por su nombre y registra tambin su rea. Los
cursos se identifican por su nombre y se registra la edad habitual de los alumnos que la cursan. Una
asignatura puede impartirse en ms de un curso. El sistema registra los crditos que tiene una
asignatura en un curso determinado y el hecho de si una asignatura es obligatoria u opcional en un
curso. Se pueden hacer como mximo 5 exmenes por asignatura y curso en el que la asignatura se
imparte.
Por ejemplo, la asignatura Biologa (rea Ciencias) se imparte en ESO-1 (edad 12) como opcional y con 6 crditos.
Se hizo un examen de Biologa en el curso ESO-1 el da 24/3/2003.
El sistema gestiona informacin de preguntas que se han puesto en algn examen o que pueden
ponerse en algn examen futuro. Las preguntas se identifican por un nmero y se registra tambin su
texto, su tipo (terica, prctica, test), su asignatura y el profesor que es su autor. Los profesores se
identifican por su nombre y se registra tambin su telfono.
Por ejemplo, la pregunta nmero 1 (texto Explicad los descubrimientos de Mendel, tipo terica) es de Biologa y
su autor es Juan (telfono 935286748). La pregunta 2 (texto Encontrad el factor Rh que se puede obtener de ...,
tipo prctica) es de Biologa y su autora es Nuria (telfono 937226432). La pregunta nmero 3 (texto Decid qu
..., tipo test) es tambin de Biologa y su autor es Luis (telfono 937226432).
Todos los exmenes que se efectan en el centro tienen un nico profesor organizador del examen. En
un examen se han de poner entre 1 y 10 preguntas de las que el sistema tiene registradas. Todas las
preguntas han de ser de la asignatura del examen. Para cada pregunta de un examen, se registra el peso
que tiene y la nota promedio que han obtenido los alumnos para la pregunta en aquel examen.
Por ejemplo, el examen anterior lo organiza Nuria y tiene tres preguntas: la nmero 1 (peso 0.4, nota promedio 5),
la nmero 2 (peso 0.4, nota promedio 7.5) y la nmero 3 (peso 0.2, nota promedio 3).
129
Para las preguntas tericas de un examen, el sistema ha de registrar tambin la nota mnima y la nota
mxima que se ha obtenido, para las preguntas prcticas el porcentaje de alumnos que han contestado
la pregunta y para las preguntas de test los puntos negativos que tienen las respuestas errneas.
Por ejemplo, en el examen anterior la pregunta 1 tiene una nota mnima de 1.5 y una mxima de 10, la pregunta 2
tiene un porcentaje de respuestas del 90 por ciento y la pregunta 3 tiene 5 puntos negativos si es errnea.
Haz el modelo conceptual de datos de este sistema con la notacin UML. Expresa grficamente todas las
restricciones que puedas (las otras, si las hay, escrbelas en forma de texto). Has de indicar tambin
necesariamente la instanciacin del modelo con los datos del ejemplo que se ha dado. Si al hacer este
ejercicio necesitas ms informacin, haz las suposiciones que creas ms adecuadas e indcalas claramente.
19. Considera que un consorcio de empresas est interesado en informatizar el seguimiento de los
proyectos informticos que desarrolla. Todos los proyectos desarrollados en el consorcio son
proyectos subcontratados. Es decir, en cualquier caso, una empresa subcontrata a otra empresa (o a
ella misma) para que lleve a cabo el proyecto. Todo proyecto informtico se inicia en una cierta fecha
y se almacena tambin la fecha prevista de finalizacin. Lgicamente, una empresa puede subcontratar
diversas veces a otra empresa para desarrollar proyectos diferentes. Las empresas se identifican por su
cdigo y se registra tambin su poblacin. Una empresa no puede subcontratar a una misma empresa
dos proyectos diferentes con una misma fecha de inicio.
130
Por ejemplo, la empresa 111 (de El Vendrell) subcontrat la empresa 222 (de Altafulla) para desarrollar un proyecto
informtico que comenzaba el 2-2-2002 y se prevea acabar el 5-5-2002. Adems, la empresa 111 subcontrat
tambin la empresa 222 para desarrollar un proyecto del 3-3-2002 al 4-4-2002.
Todo proyecto informtico ha de llevar a cabo alguna de las etapas tradicionales del ciclo de vida
de un proyecto software (es decir, especificacin, diseo o implementacin). Lgicamente, no todo
proyecto ha de comprender todas las etapas, y una etapa se lleva a cabo una nica vez en un
proyecto.
Por ejemplo, el primero de los proyectos anteriores comprenda las etapas de especificacin, diseo e
implementacin. En cambio, el segundo proyecto consista slo en una implementacin.
El sistema ha de guardar tambin la informacin de los empleados (identificados por nombre y de los
que se registra tambin su direccin y edad) que trabajan en las empresas. Para simplificar,
supondremos que un empleado comienza a trabajar en una empresa en una cierta fecha y que no se da
nunca de baja. Los empleados que trabajan en una empresa pueden participar en los proyectos que
aquella empresa est desarrollando a partir de una cierta fecha (para simplificar, supondremos tambin
que cuando un empleado comienza a trabajar en un proyecto no lo deja nunca). Un empleado slo
puede participar en un proyecto en el que su empresa es la subcontratada.
Por ejemplo, Montse (Camino Real, 21) trabaja en la empresa 111 desde el 1-1-2001, y Juan (Calle Mayor, 22) y
Mara (Calle del Torrente, 20) trabajan en la empresa 222 desde el 2-2-2001. Juan y Mara participan en el primero
de los proyectos anteriores; Juan desde el 2-2-2002 y Mara desde el 3-3-2002.
Cuando un empleado trabaja en un proyecto, lo hace en el marco de alguna de las etapas de desarrollo
del proyecto. Hay que registrar la informacin de las etapas a las que se ha asignado cada empleado
(en el marco de un proyecto) y de las horas trabajadas en esta etapa.
Por ejemplo, en el marco del primer proyecto informtico, Juan fue asignado a la etapa de especificacin y dedic
40 horas. En cambio, Mara fue asignada a la etapa de diseo, dedicando tambin 40 horas, y a la etapa de
implementacin, dedicando 60 horas.
las restricciones que puedas (las otras, si las hay, escrbelas en forma de texto). Has de indicar tambin
ejercicio necesitas ms informacin, haz las suposiciones que creas ms adecuadas e indcalas
claramente.
20. Considera el caso de una ciudad de la isla de Menorca que est interesada en construir un
sistema que le permita gestionar, entre otras cosas, la informacin de las propiedades y los alquileres
de sus fincas y de los pisos de stas. Para poder localizar las fincas, se necesita saber la informacin
de las calles (identificadas por nombre y de las que se registra tambin su barrio) que forman la
ciudad. Una finca se identifica por un nmero en una calle. Por tanto, dos fincas de una misma calle
han de tener nmeros diferentes. Toda calle ha de contener alguna finca. Una finca puede estar
dividida en diferentes pisos, que se identifican por el nmero de piso y nmero de puerta en la finca.
Por ejemplo, la calle Son Saura (barrio del Puerto) y la calle Mahn (barrio del Centro) son calles de la ciudad. La
calle Son Saura tiene dos fincas, situadas en los nmero 2 y 26, y la calle Mahn tiene una situada en el nmero 17.
La finca situada en el nmero 2 de la calle Son Saura tiene dos pisos (1-1 y 1-2) y la finca del nmero 17 de la
calle Mahn tiene dos (1-1 y 1-2).
Las fincas son propiedad de personas (identificadas por nombre y de las que se registra tambin su direccin).
Una persona puede poseer diversas fincas, y una finca puede ser propiedad de diversas personas. Una persona
posee una cierta finca a partir de una fecha y en un determinado porcentaje. Lgicamente, la suma de los
porcentajes de posesin de una finca no puede superar el 100%. Para simplificar, supondremos que el
porcentaje de posesin de una finca por parte de una persona no vara nunca.
Por ejemplo, la finca situada en el nmero 2 de la calle Son Saura es propiedad de Juan (C/ Algaiarens) en un 40%
desde el 1-1-2002 y de Mara (C/ Macarella) en un 60% desde el 2-2-2002. En cambio, la finca de la calle Mahn
es propiedad ntegra de Mara.
Las personas pueden alquilar pisos de las fincas. Una persona alquila un piso, desde una cierta fecha y
para un nmero de meses determinado. Una persona puede tener diversos pisos alquilados a la vez.
Dada una fecha de inicio y un nmero de meses de alquiler, un piso es alquilado por una nica
persona. Una persona puede alquilar diversas veces el mismo piso, pero con fechas diferentes. Una
persona no puede alquilar un pso de una finca que posee.
Por ejemplo, Juan ha alquilado el 1-1 de la finca del nmero 17 de la calle Mahn desde el 4-4-2002, para 3
meses. Marta (C/ Macarelleta) ha alquilado el 1-2 del nmero 2 de la calle Son Saura desde el 3-3-2002, para 12
meses.
Los alquileres de un piso se facturan a un propietario de la finca donde se encuentra situado el piso,
concretamente al propietario que tiene el porcentaje de posesin ms alto de aquella finca (al que
podramos denominar propietario principal). Hay que registrar la informacin del nmero de cuenta
corriente al que se ha de efectuar el pago. Si una persona es propietaria principal de diversas fincas, la
cuenta corriente a la que se facturan sus alquileres puede ser diferente para cada finca.
131
Por ejemplo, el alquiler de Marta se facturaba a Mara como propietaria principal de la finca donde estaba situado
el piso, a cargo de la cuenta corriente 1234. En cambio, el alquiler de Juan que tambin se facturaba a Mara como
propietaria principal se ingresaba en la cuenta 6789.
las restricciones que puedas (las otras, si las hay, escrbelas en forma de texto). Has de indicar tambin
ejercicio necesitas ms informacin, haz las suposiciones que creas ms adecuadas e indcalas
claramente.
21. Considera el caso de una empresa que est interesada en construir un sistema software que
incluya, entre otras cosas, informacin sobre sus empleados. Cada empleado tiene un nmero de
documento de identidad (que lo identifica), un nombre y una fecha de ingreso en la empresa. En el
transcurso de su vida laboral, los empleados se van asignando a diversos departamentos. Cada
departamento tiene un nombre (que lo identifica), una direccin y est en una ciudad. La empresa
tiene un total de 10 departamentos. Cuando se asigna un empleado a un departamento, se registra la
fecha de asignacin y, cuando se desasigna, la fecha de deseasignacin.
132
Un empleado se puede asignar como mximo tres veces al mismo departamento, pero siempre con
fechas de inicio diferentes y en periodos que no se solapen entre s. En toda su vida laboral, un
empleado se puede asignar como mximo a cinco departamentos diferentes. En un momento
determinado, un empleado puede no estar asignado a ningn departamento, y todas las asignaciones se
han de hacer en fechas posteriores a la fecha de ingreso en la empresa.
Por ejemplo, el empleado con DNI 111 (Pedro Mrtir, 1-10-02) fue asignado al departamento de Ventas
(C/Crcega, Colera) desde el 1-10-2001 al 5-9-2002 y desde el 5-10-2002 hasta el 20-10-2002 y al departamento de
Gerencia (C/Cerdea, Darnius) desde el 21-10-2002 al 1-11-2002. La empleada con DNI 222 (Mara Dulcet, 2-202) est asignada al departamento de Mrketing desde el 2-2-2002.
Cuando un empleado est asignado al departamento de Ventas o al de Mrketing, el sistema ha de

guardar informacin adicional. Un empleado puede pertenecer a la vez al departamento de Ventas
y al de Mrketing. Para los empleados asignados al departamento de Ventas, hay que registrar los
cargos que ha desempeado. Hay tres cargos posibles: Vendedor, Responsable de Ventas y
Director General de Ventas, y hay que registrar la fecha en que el empleado comenz a ocupar el
cargo en cuestin.
Por ejemplo, cuando el empleado con DNI 111 estuvo en el departamento de Ventas durante el periodo
comprendido del 1-10-2001 al 5-9-2002 desempe dos cargos: Vendedor (desde el 1-10-2001) y Responsable de
Vendas (desde el 1-1-2002). En cambio, cuando volvi a estar en el departamento de Ventas, hizo de Vendedor
(desde el 6-10-2002) y de Director General de Ventas (desde el 10-10-2002).
Los empleados asignados al departamento de Mrketing participan en diversos proyectos. Un

proyecto se identifica por un nombre y tiene una duracin determinada. Cuando los empleados
participan en proyectos llevan a cabo ciertas actividades (que se identifican por el nombre de la
actividad) y dedican un determinado nmero de horas semanales a hacer esta actividad. Un empleado
del departamento de Mrketing puede hacer ms de una actividad en el proyecto. Una actividad y un
proyecto cualesquiera han de tener como mnimo la participacin de un empleado del departamento
de Mrketing.
Por ejemplo, mientras el empleado con dni 222 ha estado en el departamento de Mrketing, ha participado en el
proyecto Ara, Lleida y ha realizado las actividades de Responsable de Imagen, dedicndole 20 horas semanales,
y de Relacin con los medios de comunicacin, con una dedicacin de 7 horas por semana.
Dada su importancia estratgica, el departamento de Mrketing puede rechazar empleados. Un

empleado rechazado por el departamento de Mrketing no se puede asignar nunca a este
departamento.
Por ejemplo, el empleado con DNI 111 fue rechazado por el departamento de Mrketing y, por tanto, no se podr
asignar nunca a dicho departamento.
las restricciones que puedas (las otras, si las hay, y los posibles atributos derivados, escrbelos en
forma textual). Indica los atributos de las clases de objetos y, si es el caso, los atributos de las
asociaciones. Has de indicar tambin necesariamente la instanciacin del modelo con los datos del
ejemplo que se ha dado. Si al hacer este ejercicio necesitas ms informacin, haz las suposiciones que
creas ms convenientes e indcalas claramente.
22. Considera una empresa que se dedica a la organizacin de congresos y que est interesada en un
sistema para la gestin de las ponencias y de los asistentes a los diversos congresos que organiza. Un
congreso tiene unas siglas y un ao que lo identifican y es necesario que el sistema registre tambin el
idioma que se se utiliza en el congreso, la ciudad donde se realiza y el precio de la inscripcin.
Por ejemplo, el congreso ER del ao 2002 tiene: idioma ingls, ciudad Singapur y precio 300 euros. El congreso
ER del ao 2003 tiene: idioma ingls, ciudad Pars y precio 360 euros.
A cada congreso se envan muchas ponencias. A cada ponencia se le asigna un cdigo que la identifica y
tambin se registra su ttulo y quines son sus autores. De cada autor, el sistema ha de tener su nombre,
que se considerar identificador, y tambin su e-mail. Algunas de las ponencias enviadas son escogidas
para ser presentadas en el congreso. Todas las ponencias escogidas para un determinado congreso han de
estar entre las que se haban enviado para aquel congreso. Es posible que una misma ponencia se presente
a diversos congresos pero entonces puede ser escogida como mximo en uno. De las ponencias
escogidas, el sistema ha de registrar la puntuacin que se les ha otorgado.
Por ejemplo, al ER del 2003 se ha presentado la ponencia de cdigo C125 (ttulo Evolucin de jerarquas) que
tiene por autores a Jorge (email: jorge@fib.upc.es) y Rosa (email: rosa@fib.upc.es). Esta ponencia ha sido escogida
y se le ha otorgado una puntuacin de 7.
Un congreso se estructura en sesiones. Cada sesin tiene un nombre que indica la temtica de la sesin
y que no se puede repetir en sesiones diferentes de un mismo congreso pero s se puede repetir en
congresos diferentes. Cada ponencia escogida se asigna a una sesin del congreso para el cual se la ha
escogido. A una sesin se pueden asignar como mximo cuatro ponencias.
Por ejemplo, al ER de 2003 hay una sesin que tiene por nombre Modelado conceptual y la ponencia C125 ha
sido asignada a dicha sesin.
Las personas que quieren asistir a un congreso se han de inscribir y el sistema ha de registrar su
nombre, que se considera identificador, y su e-mail. Hay dos tipos de inscripciones: las inscripciones
133
normales y las inscripciones de estudiantes. Para las inscripciones de estudiantes hay que registrar el
nombre de los estudios que est realizando la persona inscrita en el momento de la inscripcin. Hay
que considerar que una misma persona puede tener inscripciones de tipos diferentes (para congresos
distintos) y tambin que una persona puede tener diversas inscripciones como estudiante cada una de
las cuales con unos estudios diferentes.
Por ejemplo, al ER de 2001 se inscribi Jorge como estudiante (nombre estudios Informtica). Al ER de 2002 se ha
inscrito Jorge con inscripcin normal y Rosa tambin con inscripcin normal. Otra persona, Mara (email:
maria@fib.upc.es) se ha inscrito al ER de 2002 con inscripcin normal.
Para cada congreso existen algunos hoteles que servirn para alojar a los inscritos en el congreso que
as lo deseen (no obligatoriamente). El sistema ha de registrar cules son los hoteles de cada congreso.
Los hoteles se identifican por su nombre. Hay que registrar tambin todos los alojamientos de las
personas inscritas en un congreso correspondientes a hoteles del congreso. De cada alojamiento se
registrar la fecha de inicio y el nmero de noches. Se considerar que una persona inscrita en un
congreso puede tener diversos alojamientos diferentes en periodos que no se solapen.
Por ejemplo, los hoteles del ER de 2002 son el Montmartre y el Sena. Jorge, para su inscripcin al ER de 2002, se
aloja en el hotel Montmartre durante 2 noches desde el 5-11-2002, se aloja en el hotel Sena durante 2 noches desde
el 7-11-2002 y se aloja en el Montmartre durante 3 noches desde el 9-11-2002.
134
23. Considera el caso de una cadena de tiendas de ropa que est interesada en construir un sistema
software que incluya, entre otras cosas, informacin sobre sus productos y las tiendas donde se venden.
Cada producto tiene un cdigo (que lo identifica), una descripcin, un precio, una fecha de alta y, si
ya no se fabrica, una fecha de baja. De cada producto se disean diversas tallas y de cada talla se
fabrican diversas piezas (esta cadena de tiendas no disea modelos exclusivos). Las tallas se identifican
por el nmero de talla. Los productos pueden ser de tres tipos: infantil, juvenil y adulto. Un producto se
considera de tipo infantil si se ha diseado por alguna talla entre la 2 y la 12; de tipo juvenil si se ha
diseado para alguna talla entre la 34 y la 38; y de tipo adulto si se han diseado tallas superiores a la 38.
Nada impide que un producto sea de ms de un tipo (por ejemplo, infantil y juvenil).
Por ejemplo, el producto con cdigo 333 (forro polar de flores, 39 euros, 1-9-2003) se dise en las tallas
2, 4 y 6. El producto con cdigo 444 (abrigo azul marino, 72 euros, 1-9-2001) se dise en las tallas 12,
34 y 36, y se dio de baja el 30-6-2002). El producto con cdigo 555 (guantes de lana, 9 euros, 1-9-2001)
se dise en las tallas 2 y 4. Por tanto, los productos 333 y 555 son infantiles, y el producto 444 es infantil
y juvenil.
Las tiendas de la cadena tienen un nmero, que las identifica, y una direccin. El sistema ha de
guardar, para cada producto, la cantidad de piezas de cada talla que estn disponibles (a la venta) en
cada tienda.
Por ejemplo, en la tienda nmero 1 (Rambla Catalua) del producto 333 tienen tres piezas de la talla 4, una pieza
de la talla 2 y la talla 6 est agotada. En la tienda nmero 2 (Diagonal) del producto 444 tienen dos piezas de la talla
12, una pieza de la talla 34 y una pieza de la talla 36.
En ocasiones, las tiendas hacen promocin de productos. El sistema ha de registrar la tienda, el

producto promocionado, las fechas de inicio y final de la promocin y el descuento que se aplica al
precio del producto. Un producto puede ser promocionado hasta 3 veces en una misma tienda, pero
con fechas de inicio distintas. En una tienda determinada no puede haber ms de 10 productos en
promocin simultneamente.
Por ejemplo, en la tienda nmero 2 se promociona el producto 444 desde el da 28-12-2002 hasta el da 30-1-2003
aplicando un descuento del 50%.
Un par de veces al ao la empresa elabora los catlogos de sus productos para promocionarlos en las
temporadas de primavera/verano y otoo/invierno, respectivamente. Se elaboran tres tipos de
catlogos: el infantil, el juvenil y el adulto. El sistema ha de registrar, para cada tipo de catlogo y
temporada, la fecha en que entra en vigor y el conjunto de productos que lo conforman. Como es
natural, en el catlogo infantil slo puede haber productos de tipo infantil, en el juvenil productos de
tipo juvenil y en el adulto productos de tipo adulto.
Por ejemplo, en el catlogo infantil otoo/invierno02 (1-9-2002) encontramos el producto 333 y el producto 555.
135
24. Considera un club de jubilados que est interesado en un sistema que gestione los viajes que
organizan en el club. Los jubilados se identifican por su nombre y es necesario que el sistema
registre su ao de nacimiento.
Los viajes se identifican por un nmero y hay que registrar el tipo de transporte que se utiliza. Los
jubilados que desean hacer un viaje han de hacer una reserva para el viaje (que se ha de registrar).
Tambin hay que registrar qu jubilados de entre los que haban reservado un viaje lo han hecho
finalmente junto con su grado de satisfaccin por el transcurso del viaje. Si un viaje no tiene como
mnimo dos personas que lo hagan, el viaje se anula y el sistema no lo registra.
Por ejemplo, Juan (ao nacimiento 1930), Carmen (ao nacimiento 1933) y Carlos (ao nacimiento 1931) son
jubilados del club. Se ha organizado un viaje de nmero 25 (tipo transporte autobs). Para el viaje 25 se han hecho
tres reservas: una de Juan, una de Carmen y una de Carlos. Finalmente, los que han hecho el viaje 25 han sido Juan
con un grado de satisfaccin de 5 y Carmen con un grado de 10.
Cuando un jubilado hace un viaje tiene la posibilidad de contratas un seguro para el viaje. En estos
casos, se registra el nmero del seguro y la mutua aseguradora.
Para el viaje 25, Juan ha contratado un seguro que tiene el nmero 111 de la mutua Seguro.
En un viaje se hacen paradas en diversas localidades. Para cada parada del viaje hay que registrar la
localidad, la fecha de inicio de la parada y la fecha de fin de la parada. En una determinada fecha un
viaje no puede iniciar una parada en ms de una localidad. Un viaje puede parar como mximo dos
veces en la misma localidad y puede hacer un mximo de diez paradas en total. Las localidades se
identifican por el nombre y se quiere saber tambin su nmero de habitantes.
El viaje 25 tiene una parada en Figueras (30000 habitantes) que se inicia el da 6-10-2003 y finaliza el da 8-102003. Tambin tiene una parada en Castell de Ampurias (5000 habitantes) que se inicia el 8-10-2003 y finaliza el
9-10-2003.
Las paradas de un viaje pueden incluir diversas visitas. A cada visita se le asigna un nmero
identificador y el sistema ha de registrar para cada visita a qu parada corresponde (una sola), el
nombre de la visita, y su fecha.
Por ejemplo, la parada que el viaje 25 inicia el da 6-10-2003 en Figueras incluye la visita nmero 1234 (nombre
Museo Dal, fecha 7-10-2003). La parada que el viaje 25 inicia el da 8-10-2003 en Castell de Ampurias incluye
la visita nmero 1235 (nombre Museo de la Catedral, fecha 8-10-2003).
Los jubilados que hacen un viaje pueden dar, si quieren, su valoracin (muy buena, buena, regular,
mala) de las visitas incluidas en las paradas del viaje. Estas valoraciones han de ser registradas por el
sistema.
136
Por ejemplo, Juan ha valorado la visita 1234 como regular y la visita 1235 como muy buena.
Entre los jubilados que hacen un viaje se hace un sorteo y el ganador recibe un regalo. El sistema ha
de registrar quin es el ganador y cul ha sido su regalo.
Por ejemplo, para el viaje 25 la ganadora del sorteo ha sido Carmen que ha tenido como regalo un reloj.
25. La Asociacin de Posadas de Catalua (APC) est interesada en desarrollar un sistema
software para la gestin de los convites que se organizan en sus posadas. Una posada tiene un
nombre (que la identifica), una direccin y est situada en una ciudad. Una posada dispone de
diversas salas que se pueden utilizar para hacer los convites. Una sala se identifica por un nmero
dentro de la posada.
Por ejemplo, la posada La Cuadra, situada en la calle Mayor de Maanet de Cabrenys, dispone de tres salas: la 1,
la 2 y la 3. Por otro lado, la posada El Hostal de la Plaza, situada en la plaza de la Iglesia de Cabrils, tiene dos
salas: la 1 y la 2.
Las personas, identificadas por DNI y de las que se registra tambin el nombre, pueden organizar
convites en las posadas de la asociacin. Un convite lo organiza una persona, en una posada y para
una fecha determinada e interesa guardar tambin la informacin de la fecha en que se ha hecho la
reserva del convite y de su precio. Lgicamente, una persona puede reservar en una misma fecha dos o
ms convites en una misma posada, siempre que los convites se hagan en fechas distintas. Por otro
lado, una persona no puede organizar ms de un convite en posadas diferentes para una misma fecha.
Por ejemplo, la persona de DNI 111 y de nombre Juan ha organizado un convite en La Cuadra para el 12-5-2003 y
ha organizado otro en La Cuadra para el da 24-6-2003. Ambas reservas las hizo el 1-1-2003. El primer convite
tena un precio de 12 euros y el segundo de 15. En cambio, Ana, que tiene el DNI 222, ha organizado un convite en
el Hostal de la Plaza el da 28-7-2003 y lo reserv el 1-3-2003 con un precio de 36 euros.
La APC ofrece diversos tipos de convite, que se identifican por un nombre y de los que se registra
tambin el nmero de platos diferentes de los que consta cada tipo de convite. Los convites son de un
tipo determinado. Si un convite es del tipo Buffet libre, entonces hay que registrar tambin qu salas
de la posada se usarn para hacer el convite. Si un convite es del tipo Men, entonces hay que
registrar tambin las personas que asistirn al convite. No hay que guardar ninguna informacin
adicional si un convite no es de ninguno de estos dos tipos.
Por ejemplo, el tipo de convite Buffet libre consta de 25 platos, el tipo Men de 5 platos y el tipo Rgimen de 1
nico plato. El convite de Juan en la Cuada para el da 12-5-2003 es de tipo Buffet libre y el otro convite de Juan es
de tipo Men. El primero de estos convites se har en las salas 1 y 2 de La Cuadra y al otro convite asistirn Jorge (de
DNI 333) y Montse (de DNI 444). Montse tambin asistir al convite de Ana que tambin es de tipo Men.
137
Cuando una persona asiste a un convite de tipo Men puede especificar si quiere comida
vegetariana o no. Slo se permite que los asistentens soliciten comida vegetariana si el precio del
convite es superior a 21 euros.
Por ejemplo, Montse pidi comida vegetariana en el convite de Ana y no pidi comida vegetariana en el
convite de Juan.
26. Considera el caso de una refinera automatizada que est interesada en un sistema para el control
de su servicio de mantenimiento. Dado que sus instalaciones no se pueden parar, este servicio trabaja
da y noche cada da de la semana, incluyendo fines de semana y festivos. Los empleados se
identifican por su nombre y se guarda tambin informacin de su direccin y edad. Los empleados del
servicio de mantenimiento trabajan en equipos. Los equipos se identifican por un nmero. Cada
persona est asignada a un nico equipo de mantenimiento. Cada equipo tiene un jefe de turno que
necesariamente ha de ser uno de sus miembros.
Por ejemplo, Juan (direccin C/Valencia, 25 aos), Jos (Gran Va, 24 aos) y Alberto (C/Aribau, 30 aos)
pertenecen al equipo de mantenimiento nmero 2. Jos es el jefe de turno de este equipo. Pedro (C/Mallorca, 25
aos), Flix (C/Guipzcoa, 29 aos) y Nuria (C/Carlos Alts, 30 aos) pertenecen al equipo de mantenimiento
nmero 1. Nuria es la jefe de turno de este equipo.
Para configurar el calendario de trabajo, los das se estructuran en turnos. Los das no festivos tienen
tres turnos de ocho horas (maana, tarde y noche) y los das festivos tienen dos turnos de 12 horas (da
y noche). Cada turno de cada da se asigna a un equipo de mantenimiento.
Por ejemplo, viernes 6 de noviembre el equipo 1 trabajar en el turno de maana, el equipo 2 en el turno de tarde y
el equipo 3 en el turno de noche. Sbado da 7 de noviembre el equipo 1 trabajar de da y el equipo 2 de noche; el
equipo 3 no trabaja.
Para coordinar los diferentes equipos, se programa la realizacin de los trabajos que se han de llevar a
cabo cada turno de cada da. Los trabajos se identifican por un cdigo y tienen una descripcin. A
veces, no todos los trabajos programados se pueden realizar, porque surgen imprevistos. Al acabar la
jornada, el jefe de turno ha de indicar cules de los trabajos programados se han podido realizar y
cules no. De los trabajos que no se han podido realizar se ha de indicar el motivo y de los que se han
realizado hay que indicar la hora de inicio y de fin del trabajo y una descripcin del desarrollo del
trabajo. Por descontado, la empresa tambin quiere tener informacin de los trabajos que se han
tenido que hacer improvisadamente. En este caso el jefe de turno da la misma informacin que para
los trabajos programados realizados.
138
Por ejemplo, jueves 5 de noviembre por la noche estaba programado el 1: revisar la mquina 303, 2:
cambiar los filtros de las mquinas de las salas 2 y 4 y tambin el trabajo 3: preparar la instalacin de la
nueva mquina en la sala 3. Los trabajos 1 y 2 se pudieron realizar, pero el trabajo 3 no, porque fall un centro
de transformacin durante la noche y se tuvo que reparar. El trabajo 1 se realiz entre las 10 y las 12 de la
noche, el trabajo 2 desde las 12 hasta las 3 de la madrugada, y la reparacin del centro de transformacin se
acab a las 6 de la maana.
El equipo de turno, al realizar sus trabajos, usa ciertos materiales. Se quiere tener informacin de qu
materiales se han usado para cada trabajo y en qu cantidad.
27. Un palacio de ferias necesita un sistema que gestione informacin de las ferias que se
organizan. Una feria se identifica por su nombre y el sistema ha de registrar la fecha de inicio y de
fin de la feria. No puede haber simultneamente ms de una feria en el palacio. Para cada feria que
se organiza se hace una divisin del palacio en parcelas. Cada parcela tiene un nmero que es
diferente para todas las parcelas de una misma feria, pero que puede coincidir en parcelas de ferias
diferentes. De cada parcela se desea registrar su superficie. Tambin se desea registrar qu parcelas
son limtrofes (slo pueden ser limtrofes parcelas de una misma feria). Una parcela puede tener
como mximo dos parcelas limtrofes y puede haber parcelas aisladas que no tienen ninguna
parcela limtrofe.
Por ejemplo, la feria Construmat03 comienza el 6-3-2003 y acaba el 10-3-2003. La divisin del palacio para esta
feria feria consta de 3 parcelas: la nmero 1 (superficie 10), la nmero 2 (superficie 20) y la nmero 3 (superficie
30). La parcela 1 no limita con ninguna parcela. La parcela 2 limita con la 3 y la parcela 3 limita con la 2. La feria
Informat03 comienza el 3-4-2003 y acaba el 7-4-2003. Para Informat03, el palacio se ha dividido en dos parcelas:
la nmero 1 (superficie 40) y la nmero 2 (superficie 10). La parcela 1 de esta feria limita con la 2 y la parcela 2
limita con la 1.
Las parcelas de una feria son contratadas por empresas que desean exponer sus productos. Se desea
registrar qu empresa (una sola) ha contratado cada parcela. Las empresas se identifican por su
nombre y se desea registrar tambin su telfono. Algunas parcelas pueden quedar sin contratar.
Por ejemplo, la empresa Rajolsa (telfono 933333333) ha contratado la parcela 1 y la parcela 2 de la feria
Construmat03. La empresa CAD (telfono 911111111) ha contratado la parcela 3 de la feria Construmat03 y ha
contratado la parcela 2 de la feria Informat03.
A las parcelas se asignan personas que se encargan de atender a los asistentes de la feria que estn
interesados en lo que se expone en la parcela. Estas asignaciones tienen una fecha de inicio y una
fecha de fin que estarn incluidas entre las fechas de inicio y de fin de la feria correspondiente a la
parcela. Hay que tener en cuenta que una misma persona puede tener diversas asignaciones que se
solapen temporalmente. De las personas asignadas, hay que registrar su titulacin y su poblacin de
residencia. Supondremos, para simplificar, que podemos identificar a las personas por su nombre.
Por ejemplo, a la parcela 1 de la feria Construmat03 se ha asignado a Ana (titulacin arquitecta y poblacin
Girona) desde el 6-3-2003 hasta el 7-3-2003, a Juan (titulacin aparejador y poblacin Barcelona) desde el 6-32003 hasta el 10-3-2003 y a Ana otra vez desde el 9-3-2003 hasta el 10-3-2003. A la parcela 2 de la feria
Construmat03 se ha asignado a Nuria (titulacin delineante y poblacin Reus) desde el 6-3-2003 haste el 10-32003. Finalmente, a la parcela 2 de la feria Informat03 se ha asignado a Juan desde el 3-4-2003 hasta el 7-4-2003.
Las personas que quieren asistir a una feria se han de inscribir y el sistema ha de registrar su nombre
(que como ya hemos explicado consideramos que identifica a las personas), su poblacin de
residencia y su e-mail. Las personas que estn asignadas a parcelas de una determinada feria no
pueden estar inscritas en la misma feria. La mayora de inscripciones son vlidas para todos los das
que dura la feria pero existe la posibilidad de hacer una inscripcin de tipo parcial que incluya slo
alguno de los das de la feria no necesariamente consecutivos y con un mximo de 3 das. El sistema
ha de registrar las fechas incluidas en cada una de las inscripciones que sean de tipo parcial. Las
inscripciones pueden pagarse slo de dos maneras: en efectivo o mediante tarjeta. De las inscripciones
pagadas en efectivo, hay que registrar qu porcentaje de descuento se les ha aplicado (considerando
que se puedan aplicar porcentajes diferentes a inscripciones de una misma feria) y, de las pagadas con
tarjeta, el nmero de tarjeta utilizado.
Por ejemplo, Ana (e-mail: ana@coac.com) se ha inscrito a Informat03. El pago ha sido en efectivo y se le ha
aplicado un descuento del 10%. Gustavo (e-mail: gustamante@cons.com y poblacin Logroo) se ha inscrito a
Construmat03 con una inscripcin parcial que incluye los das 7-3-2003 y 9-3-2003. En este caso el pago ha sido
con la tarjeta nmero 333.
139
28. Una agencia de viajes est interesada en desarrollar un sistema software para la gestin de los viajes
que se contratan en sus oficinas. La agencia tiene diversas oficinas (identificadas por nmero y de las que
se registra tambin su direccin). Una persona (identificada por nombre y de la que queremos saber
tambin su edad) puede ser cliente de alguna oficina de la agencia desde una cierta fecha. Una oficina
emplea diversas personas, pero una persona trabaja como mximo en una nica oficina. El sistema slo
ha de guardar informacin de los clientes y de los empleados de la agencia y no puede pasar que una
persona sea al mismo tiempo cliente de la agencia y sea empleada de alguna oficina.
Por ejemplo, Juan (20 aos) es cliente de las oficinas 1 (C/Mayor) y 2 (C/Menor), en ambos casos desde el 25 de
octubre del 2002, y Mara (19 aos) es cliente de la oficina 1 desde el 3 de noviembre de 2002. Marta (22 aos) e
Isabel (21 aos) trabajan en la oficina 1 y Pablo (22 aos) trabaja en la oficina 2.
Cuando una persona es cliente de una oficina, puede pedir presupuestos de viajes en la oficina. La
peticin de presupuesto de un viaje se hace en una cierta fecha y para un cierto pas de destino. Para
simplificar, consideraremos que un viaje se hace a un nico pas. Interesa saber tambin la fecha de
inicio y la duracin del viaje. En una misma fecha un cliente puede pedir diversos presupuestos de
viajes a pases distintos, pero no puede pedir en una oficina dos presupuestos para el mismo pas. Una
persona no puede pedir presupuesto de viaje en una oficina si no es cliente de aquella oficina.
140
Por ejemplo, el da 4 de noviembre del 2002 Juan pidi presupuesto de un viaje a Noruega en la oficina 1. El viaje
tena que comenzar el 27 de diciembre del 2002 y durar 7 das. El mismo da, Juan pidi presupuesto de un viaje a
Italia, que comenzara el 10 de febrero del 2003 y durara 15 das, en la oficina 2.
Las peticiones de presupuestos de viajes son evaluadas por un mximo de 3 empleados de la oficina y
se indicar, para cada evaluacin, el precio aproximado del viaje. Una vez se tiene alguna evaluacin
de un viaje presupuestado, el cliente puede decidir contratar este viaje. El precio del viaje contratado
ser el promedio de precios de todas las evaluaciones hechas del viaje presupuestado. No se puede
contratar un viaje presupuestado que no tenga ninguna evaluacin.
Por ejemplo, Marta e Isabel hicieron una evaluacin del viaje que Juan haba pedido el da 4 de noviembre del 2002
para ir a Noruega. Marta sugiri un precio aproximado del 600 euros e Isabel de 900. Juan decidi contratar este
viaje por el precio resultante de 750 euros.
Un viaje contratado puede usar diversos medios de transporte (identificados por nombre del medio y
de los que se registra tambin su grado de seguridad). Esta informacin ha de registrarse en el sistema
y, adems, para los viajes que usen el avin habr que registrar tambin la informacin de los
aeropuertos (identificados por cdigo y del que se sabe tambin la ciudad) por donde pasa el avin en
aquel viaje.
Por ejemplo, el anterior viaje contratado usaba el barco (97% de seguridad) y el avin (98%). El avin pasaba por
los aeropuertos de BCN (Barcelona), CPN (Copenhaguen) y OSL (Oslo).
3 Object Constraint Language (O.C.L.)
3 Object Constraint Language (O.C.L.)

1. A partir del modelo conceptual de datos siguiente, expresa en OCL las restricciones textuales a)
y b). La clase Persona tiene un nico atributo nombre y la clase Coche un nico atributo matrcula,
ambos identificadores.
Posee
propietario
1..*
posedo
propiedad
Persona
Coche
*
Conduce
1..*
conductor
conducido
conduccin
a) Una persona no puede conducir un coche que no posee.

b) Todo conductor de un coche ha de ser uno de los propietarios de aquel coche.
2. A partir del modelo conceptual de datos siguiente, expresa en OCL una expresin que d el
conjunto (sin repeticiones) de todos los habitantes de los pisos que tienen ms de un propietario.
Persona
habitante *
vive
vivienda
1..* propietario
{subset}
posee
* propiedad
*
Piso
3. Dado el modelo conceptual de la figura siguiente, expresa en OCL las restricciones textuales r1)
y r2).
141
Empleado
cdigo
*
vive-en
1..*
trabaja-en
Ciudad
nombre
Departamento
nmero
*
situado-en
RT: La clave de empleado es cdigo, la clave de departamento es nmero y la clave de ciudad es

nombre.
r1) Un empleado slo puede trabajar en departamentos situados en la ciudad donde vive.
r2) Un empleado ha de trabajar como mnimo en un departamento situado en la ciudad donde vive.
4. Dado el modelo conceptual de la figura siguiente, escribe en OCL una expresin que d, sin
repeticiones, los nombres de los msicos que alguna vez han tocado algn instrumento del que no son
expertos.
142
Msico
nombre
*
es-experto-en
*
Instrumento
interpreta
*
*
ObraMusical
Interpretacin
toca
RT: La clave de msico es nombre.
4 Modelo de casos de uso y modelo del comportamiento

1. Considerad una facultad universitaria que est interesada en un sistema para la definicin de los
horarios de los grupos de las diferentes asignaturas. El horario indica, para cada grupo de una
asignatura (por ejemplo, IS:E grupo 10) qu das de la semana hay clase y a qu hora (para
simplificar, supondremos que los periodos de clase son siempre de una hora). Adems, tambin hay
que guardar la informacin del aula de cada horario.
El sistema que se debe desarrollar slo ha de consultar los datos de ASIGNATURA y las
FRACCIONES HORARIAS, dado que existe otro sistema encargado de darlos de alta. Los diversos
nmero de GRUPO se dan de alta a medida que se conocen los horarios de alguno de ellos. El modelo
conceptual de datos en UML de este sistema es el siguiente:
FRACCIN-HORARIA
da
hora
0, 3
ASIGNATURA
cdigo
nombre
GRUPO
Hace-clase
0..1 nmero
HORARIO
{incomplete}
HO-COMPLETO
aula
El sistema ha de permitir efectuar las funcionalidades siguientes: definicin-de-horarios-de-un-grupo,

asignacin-de-aula, listado-de-horarios-sin-aula y listado-de-horarios de todas las asignaturas.
Cuando el Jefe de Estudios define el horario de un grupo, indica el cdigo de la asignatura, el nmero
de grupo a dar de alta y, para cada fraccin horaria en que se hace clase de aquel grupo de la
asignatura, el da y la hora. Es el propio Jefe de Estudios quien comunica estos datos al sistema. Haz
que la interaccin necesaria para llevar a cabo esta funcionalidad requiera ms de un evento.
143
Cuando se efecta una asignacin de aula, se indica el cdigo de la asignatura, el nmero de grupo, el
da, la hora y el aula asignada. Esta operacin es efectuada por los empleados de secretara cuando as
lo requiere el Jefe de Estudios.
Para solicitar el listado de horarios sin aula de una asignatura determinada, el Jefe de Estudios indica
al sistema el cdigo de la asignatura y el sistema muestra, para cada horario de aquella asignatura sin
aula asignada, el nmero de grupo, el da y la hora.
En cualquier momento, cualquier usuario de este sistema (incluidos profesores y alumnos) puede pedir
el listado de horarios de todas las asignaturas. El sistema muestra, para cada asignatura, su cdigo y,
para cada grupo de la asignatura, su nmero, los das y horas en que se hace clase y, si se conoce, el
aula.
Os pedimos que hagis los modelos siguientes (todos ellos mediante la notacin UML). En todos los
casos, hay que realizar todas las comprobaciones que sean necesarias. Si las hay, hay que indicar las
modificaciones necesarias a hacer en el modelo conceptual de datos de partida.
144
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso de la
asignacin de aula.
x Modelo del comportamiento del sistema: todos los diagramas de secuencia y contratos de las
operaciones correspondientes a la definicin de los horarios de un grupo y al listado de horarios sin
aula de una asignatura.
2. Considerad una empresa de transportes que est interesada en un sistema para la definicin de
los recorridos de las rutas de distribucin de sus camiones. Una ruta est formada por una serie de
tramos consecutivos (que se distinguen por el nmero de tramo dentro de la ruta). Un tramo se define
por un apoblacin de origen, una de destino y una carretera que une las dos poblaciones. Adems,
tambin hay que guardar la informacin de la distancia y de la duracin de recorrido de un tramo.
El sistema que se debe desarrollar slo ha de consultar los datos de POBLACIN y de
CARRETERA, dado que existe otro sistema encargado de darlos de alta. El modelo conceptual de
datos en UML de este sistema es el siguiente:
POBLACIN
nombre-p
habitantes
0.. 2
(origen)
Hacen-tramo
0.. 2
CARRETERA
*
(destino)
TRAMO
distancia
duracin
De-la
*
cdigo-c
RUTA
* cdigo-ruta
TRAMO-RUTA
nm-tramo
R.I. textuales:
- La poblacin destino de un tramo de la ruta ha de coincidir con la poblacin origen del tramo siguiente de la misma ruta.
- La poblacin origen y la poblacin destino de un tramo han de ser diferentes.
El sistema ha de permitir efectuar las funcionalidades siguientes: alta-tramo, alta-ruta, listado-detramos-sin-ruta y listado-de-tramos-de-ruta.
Cuando se da de alta un tramo, se indica el nombre de la poblacin de origen, el nombre de la
poblacin de destino, el cdigo de la carretera, la distancia y la duracin del tramo. Esta operacin es
efectuada por los empleados de la empresa, a peticin del Director de Distribucin.
Cuando el Director de Distribucin da de alta una ruta, indica l mismo al sistema el cdigo de la ruta
y, para cada tramo que forma parte de la ruta que se est dando de alta, las poblaciones de origen y
destino del tramo, el cdigo de carretera y el nmero de tramo dentro de la ruta. Haced que la
interaccin necesaria para llevar a cabo esta funcionalidad requiera ms de un evento.
El listado de los tramos sin ruta asignada se emite siempre a final de mes y va dirigido al Director de
Distribucin. El resultado de este listado incluye, para cada tramo que no est asignado a ninguna ruta,
el nombre de las poblaciones de origen y destino del tramo y el cdigo de la carretera que las une.
En cualquier momento, los empleados de la empresa pueden solicitar el listado de los tramos de una
ruta. El sistema muestra, para cada tramo de la ruta indicada por el empleado, el nombre de la
poblacin de origen y de destino, el cdigo de la carretera, la distancia y la duracin del tramo y el
nmero de tramo dentro de la ruta.
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso del alta de
tramo.
x Modelo del comportamiento del sistema: Todos los diagramas de secuencia. Contratos de las
operaciones correspondientes al alta de ruta y al listado de los tramos de una ruta.
3. Considerad una agencia inmobiliaria de un pueblo turstico del Alt Empord que est interesada
en un sistema para gestionar los alquileres de las fincas que posee en el pueblo. El sistema guarda
informacin de las calles (identificadas por nombre) donde tiene situadas las fincas (identificadas por
nmero dentro de la calle) y de los alquileres de las fincas que hacen los clientes de la agencia
(identificados por dni). Los alquileres hacen referencia a un piso de la fina (1 1, 1 2, etc.) y pueden
ser temporales o bien indefinidos. El sistema ha de guardar tambin informacin del precio del
alquiler y de atributos especficos para cada tipo de alquiler. Adems, el sistema slo ha de consultar
los datos de CLIENTE, dado que hay otro sistema encargado de darlos de alta. El modelo conceptual
de datos en UML de este sistema es el siguiente:
145
CALLE
nombre-c
1..*
Con
FINCA
* Alquilada-por
nm-f
ALQUILER
piso
precio
tipo
tipo
TEMPORAL
fecha-fin
* CLIENTE
dni
nombre
{Disj., Comp.}
INDEFINIDO
aumento
R.I. textuales:
- Claves de las clases no asociativas: (Calle,nombre-c), (Cliente, dni).
- Una calle no puede tener dos fincas con el mismo
El sistema ha de permitir efectuar las funcionalidades siguientes: alta-calle, alta-alquileres-finca, bajaalquileres y listado-de-alquileres-con-aumento-elevado.
146
Cuando se da de alta una calle, se indica el nombre de la calle y, para cada finca de aquella calle, su
nmero de finca. Esta operacin es efectuada por los empleados de la agencia, a peticin de la
Directora de la agencia.
Cuando el Responsable de Alquileres da de alta todos los alquileres de una finca, indica l mismo al
sistema el nombre de la calle, el nmero de la finca y, para cada alquiler de aquella finca que se da de
alta, el DNI del cliente, el piso alquilado, el precio, el tipo de alquiler (temporal o indefinido) y la
fecha-fin o el aumento anual establecido, segn proceda. Haced que la interaccin necesaria para
llevar a cabo esta funcionalidad requiera ms de un evento.
Al final del da, se dan de baja automticamente todos los alquileres que finalizan en esta fecha.
Adems, el sistema genera un listado que incluye, para cada alquiler dado de baja, el nombre de la
calle, el nmero de finca, el DNI del cliente y el piso.
En cualquier momento, todos los empleados de la empresa pueden pedir el listado de los alquileres
con aumento elevado. El sistema muestra, para cada alquiler indefinido con un aumento superior al
5%, el nombre de la calle, el nmero de finca y el nombre del cliente que tiene el piso alquilado.
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso de alta calle.
operaciones correspondientes al alta de alquileres de una finca y al listado de los alquileres con
aumentos elevados.
4. Considerad un centro excursionista que ha decidido organizar la travesa de los Pirineos a
pie, desde Biarritz a Cabo de Creus. Esta travesa consta de diversas jornadas (identificadas por
un nmero) que se recorren entre una poblacin de inicio y otra final. Toda jornada tiene una
serie de controles (identificados por un nmero dentro de la jornada) para garantizar que ningn
participante se pierde. Las personas se pueden inscribir en una jornada de la travesa. El sistema
almacena tambin las horas de paso de todos los participantes para cada uno de los controles que
pasan. Adems, el sistema slo ha de consultar los datos de PERSONA dado que hay otro
sistema encargado de darlos de alta. El modelo conceptual de datos en UML de este sistema es
el siguiente:
JORNADA
Se-inscribe
PERSONA
dni
nombre-p
Nm-jorn
Pob-inicio
* Pob-fin
Con
1..*
*
CONTROL
nm-cont
lugar
Pasa-por
*
PARTICIPACIN
CONTROL PARTICIPANTE
hora-de-paso
R.I. textuales:
- Claves de las clases no asociativas: (Jornada, nm-jorn), (Persona, dni).
- Una jornada no puede tener dos controles con el mismo nm-cont.
- La poblacin final de una jornada y la de inicio de la jornada siguiente han de coincidir
- La persona que participa en control-participante ha de estar inscrita en la jornada de aquel control
El sistema ha de permitir efectuar las funcionalidades siguientes: alta-jornada, alta-participante,

asignar-pasos-por-control y listado-de-controles-de-jornada.
Cuando se da de alta una jornada, se indica el nmero de la jornada, la poblacin de inicio, la poblacin
final y, para cada control de aquella jornada que se est dando de alta en aquel momento, su nmero de
control y el lugar. Las jornadas no se dan de alta todas a la vez, sino que se van comunicando al sistema a
medida que se toma la decisin de su recorrido concreto. Adems, ya no se pueden dar de alta jornadas
una vez se conocen los primeros controles de paso de la travesa. El alta de jornadas es efectuada por los
empleados de la agencia, a peticin del Responsable de Recorrido. Hay que hacer que la interaccin
necesaria para llevar a cabo esta funcionalidad requiera ms de un evento.
Cuando una persona quiere participar en una jornada de la travesa, lo hace saber al empleado que es
quien comunica esta informacin al sistema. Basta con indicar el DNI de la persona y el nmero de
jornada.
Cuando el Controlador Jefe da de alta todos los controles de los participantes de una jornada, indica l
mismo al sistema el nmero de jornada y, para cada persona que ha participado en aquella jornada, el
nmero de control y la hora de paso de todos los controles por los que ha pasado. La interaccin
necesaria para llevar a cabo esta funcionalidad ha de requerir tambin ms de un evento.
En cualquier momento, el Controlador Jefe puede solicitar un listado de los controles de una jornada.
Dada una jornada, que es indicada por l mismo al sistema, ste muestra el DNI del participante, el
nmero de control y la hora de paso de todos los controles de participante.
147
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso de alta
jornada.
operaciones correspondientes al alta de controles y al listado de controles.
5. Considerad una facultad universitaria que est interesada en un sistema para la definicin de
grupos de las diferentes asignaturas. Una asignatura puede tener diversos grupos (por ejemplo,
grupos 10 y 20 de la asignatura FBD; grupos 10, 20 y 30 de IS:E, etc.). Una matrcula se define por
un estudiante y por un grupo donde el estudiante se matricula. Las matrculas pueden ser de dos
tipos: de evaluacin continua y de evaluacin no continua. Para las matrculas de evaluacin no
continua se registra la nota final del estudiante. Para las de evaluacin continua se registran las
diversas notas parciales del estudiante. El modelo conceptual de datos en UML de este sistema es
el siguiente:
ASIGNATURA
148
cdigo-asig
nombre
crditos
ESTUDIANTE
GRUPO
1 Tiene * nmero * Se-matric * dni
nombre
capacidad
telfono
MATRCULA
PARCIAL
nm-parcial
NOTA
nota
Corresponde
*
tipo
EVALUACIN
CONTINUA
EVALUACIN
NO CONTINUA
nota-final
R.I. textuales:
- Claves de las clases no asociativas: (Asignatura, cdigo-asig), (Estudiante, dni), (Parcial, nmparcial).
- No puede haber ninguna asignatura que tenga dos grupos con el mismo nmero.
- Un estudiante no puede matricularse de ms de un grupo de la misma asignatura.
El sistema que se debe desarrollar slo ha de consultar los datos de ASIGNATURA, ESTUDIANTE y
PARCIAL, dado que existe otro sistema encargado de darlos de alta. El sistema ha de permitir
efectuar entre otras las funcionalidades siguientes: alta-grupos-asignatura, matrcula-estudiante,
asignacin-notas-parciales, consulta-estudiantes-con-notas-finales-aprobadas.
Cuando el Jefe de Estudios quiere definir los grupos de una asignatura, indica el cdigo de la
asignatura y, para cada grupo a dar de alta, el nmero de grupo y la capacidad del grupo. Es el propio
Jefe de Estudios quien comunica estos datos al sistema. Haced que la interaccin necesaria para llevas
a cabo esta funcionalidad requiera ms de un evento.
Cuando un estudiante se matricula en un grupo, indica el cdigo de la asignatura, el nmero de grupo,

su DNI y el tipo de matrcula (evaluacin continua o no). Esta operacin es efectuada por el propio
estudiante.
Cuando un profesor quiere hacer una asignacin de notas parciales a estudiantes con matrcula de
evaluacin continua en un determinado grupo, se indica el cdigo de la asignatura, el nmero de grupo
y el nmero de parcial y, para cada estudiante que tiene nota parcial, el DNI del estudiante y la nota.
Esta operacin es efectuada por el empleado de secretara a peticin del profesor. Haced que la
El Jefe de Estudios en cualquier momento puede consultar los estudiante con notas finales aprobadas.
El sistema muestra, para cada matrcula de evaluacin no continua con nota final mayor o igual que 5,
el DNI del estudiante, el cdigo de la asignatura y el nmero de grupo.
x Modelo de casos de uso: Diagrama de casos de uso (para las funcionalidades especificadas).
Especificacin del caso de uso del alta de grupos de una asignatura.
operaciones correspondientes a la asignacin de notas parciales y a la consulta de estudiantes con
notas finales aprobadas.
6. Considerad una empresa que se dedica a la organizacin de congresos y que est interesada en
un sistema para la gestin de las sesiones, de las ponencias y de los asistentes a los diversos congresos
que organiza. Un congreso se estructura en sesiones. Cada sesin de un congreso se dedica a la
presentacin de diversas ponencias. Las ponencias tienen diversos autores. Las personas que quieren
asistir a un congreso se han de inscribir. Las inscripciones pueden ser de dos tipos: de tipo normal o
de tipo estudiante. Para las inscripciones de estudiantes se registra el nombre de la universidad
donde est estudiando la persona inscrita en el momento de la inscripcin. Para las inscripciones
normales se registra la profesin de la persona inscrita en el momento de la inscripcin. El modelo
conceptual de datos en UML de este sistema es el siguiente:
Congreso
Sesin
Tiene
siglas
ao
precio
nom-sesin
* duracin
Ponencia
Se-presenta
1
Asiste-a
Inscripcin
tipo
Ins. Normal
Ins.Estudiante
profesin
universidad
cdigo
ttulo
0..4
Es-autor
*
*
1..*
Persona
nombre
149
R.I. textuales:
- Claves de clases no asociativas: (Congreso: siglas, ao), (Ponencia: cdigo), (Persona: nombre).
- No puede haber ningn congreso que tenga dos sesiones con el mismo nombre de sesin.
El sistema que se debe desarrollar no ha de dar de alta los datos de las inscripciones, dado que existe
otro sistema encargado de hacerlo. El sistema ha de permitir efectuar entre otras las funcionalidades
siguientes: alta-congreso-y-sesiones, alta-ponencias-sesin y consulta-estudiantes-y-autores.
Cuando el Presidente del Comit Organizador de un congreso quiere dar de alta el congreso y sus
sesiones, indica las siglas, ao y precio del congreso y, para cada sesin del congreso, el nombre de
la sesin y su duracin. Es el propio Presidente del Comit Organizador quien comunica estos
datos al sistema. Finalmente, el sistema muestra el nmero total de sesiones dadas de alta por el
congreso. Haced que la interaccin necesaria para llevar a cabo esta funcionalidad requiera ms de
un evento.
150
Cuando el Presidente del Comit de Programa de un congreso quiere dar de alta las ponencias de una
sesin del congreso, se indican las siglas y ao del congreso y tambin el nombre de la sesin.
Adems, para cada ponencia de la sesin, se indican el cdigo y ttulo de la ponencia junto con los
nombres de todos los autores de la ponencia. Hay que considerar que algunos de estos autores
existirn en la base de informacin mientras otros no. Tambin hay que tener en cuenta que no se
pueden dar de alta ponencias en sesiones de congresos que ya tienen alguna persona inscrita. Este alta
es efectuada por un administrativo de la empresa a peticin del Presidente del Comit de Programa.
Haced que la interaccin de esta funcionalidad requiera ms de un evento.
Finalmente, cuando una persona cualquiera indica que quiere hacer una consulta de estudiantes y
autores, el sistema muestra los nombres de las personas que asisten con inscripcin de estudiante a
algn congreso y que, al mismo tiempo, son autores de alguna ponencia que se presenta en alguna
sesin del mismo congreso.
Os pedimos que hagis los modelos siguientes (todos ellos mediante la notacin UML):
x Modelo del comportamiento del sistema: Diagramas de secuencia y contratos de las operaciones
correspondientes al alta de congreso y sesiones, al alta de las ponencias de una sesin y a la consulta
de estudiantes y autores. Expresad las salidas de las operaciones con la ayuda del lenguaje OCL.
7. Considerad una agencia de viajes que est interesada en desarrollar un sistema software para
gestionar los viajes que hacen sus clientes. La agencia dispone de informacin de las personas que
quieren hacer algn viaje, identificadas por DNI y de las que se registra tambin su nombre. Tambin
se guarda informacin de las ciudades en las que la agencia ofrece viajes. Concretamente, se registra
el nombre y, si son ciudades de mar, se guarda informacin de sus hoteles.
8.
Adems, el sistema guarda informacin de los viajes planeados por las personas. Un viaje planeado
puede ser presupuestado (cuando inicialmente el cliente conoce el presupuesto), reservado (si al
cliente le parece bien el presupuesto y da un apaga y seal para garantizar su viaje) y confirmado
(cuando se asegura que el viaje reservado se har y se dice, si el viaje se hace a una ciudad de mar, en
qu hotel se alojar la persona). El modelo conceptual de datos en UML de este sistema es el
siguiente:
Fecha
Persona
1
dni
nombre
fecha
/Tiene-presupuestados
Ciudad
inicio
0.. 3
Quiere-viajar
{incomplete}
Viaje-planeado
Mar
Presupuestado
precio
Reservado
avance
nombre
1
Confirmado
*
De-la
Se-aloja-en
*
Hotel
0..1
nombre
R.I. textuales:
- Claves clases no asociativas: (Persona, dni); (Fecha, fecha); (Ciudad, nombre).
- Una Ciudad no puede tener ms de un Hotel con el mismo nombre.
- Un viaje confirmado se hace a un Hotel de la misma ciudad donde se hace el viaje.
- Una persona no puede tener ms de un viaje confirmado con una misma fecha de inicio.
Info. derivada:
- Tiene-presupuestados: una Persona tiene-presupuestados un conjunto de Viajes planeados.
151
El sistema que se debe desarrollar no ha de dar de alta los datos de Persona, Fecha, Ciudad y Mar,
dado que existe otro sistema encargado de hacerlo. El sistema ha de permitir efectuar las
funcionalidades siguiente: alta-viajes-planeados, confirmar-viaje y listado-coincidencias-hotel.
Los clientes quieren que la agencia les planee los viajes para una cierta fecha. Cuando esto pasa, un
empleado de la agencia indica al sistema el DNI del cliente, la fecha de los viajes planeados y, para
cada ciudad a la que el cliente haya planeado viajar en aquella fecha, el nombre de la ciudad y el
precio del viaje. Como consecuencia de esta interaccin, el cliente pasa a tener tantos viajes
presupuestados en aquella fecha como ciudades se hayan especificado. Tal y como se muestra en el
modelo conceptual de datos, una persona no puede tener ms de tres viajes planeados a diferentes
ciudades en una cierta fecha. Haced que la interaccin necesaria para llevar a cabo esta funcionalidad
requiera ms de un evento.
Cuando un cliente quiere confirmar un viaje planeado, un empleado de la agencia indica al sistema el
DNI de la persona, la fecha del viaje, la ciudad donde quiere viajar y, si la ciudad es de mar, el
nombre del hotel donde se alojar el cliente. Un viaje slo se puede confirmar si estaba reservado.
Si un cliente quiere saber las personas, sin repeticiones, que se han alojado en el pasado en algn hotel
en el que l tambin ha estado, indica l mismo al sistema su dni. El sistema muestra, para cada una de
estas personas, su nombre.
x Modelo del comportamiento del sistema: Todos los diagramas de secuencia. Contratos de todas las
operaciones que aparecen en los diagramas de secuencia. Expresad las salidas de las operaciones con
la ayuda del lenguaje OCL.
9. Considerad un club de jubilados que est interesado en un sistema que gestione los viajes que
organiza el club. Un viaje consta de diversas paradas. Cada parada de un viaje se hace en una
localidad desde una determinada fecha de inicio y hasta una fecha de finalizacin. Cada parada puede
incluir diversas visitas. Una visita est incluida en una nica parada. Un jubilado del club se puede
inscribir a diversos viajes y un viaje puede tener diversos jubilados inscritos. El modelo conceptual de
datos en UML de este sistema es el siguiente:
Jubilado
nombre_jub
ao_nac
Visita
nm
nombre
fecha_vis *
152
Viaje
* nm_viaje
tipo_transp
Se-inscribe
*
Parar
0..1
Incluye
1
Parada
fecha_fin
Fecha
fecha_in
Localidad
nombre_loc
nm_hab
R.I. textuales:
- Claves de clases no asociativas: (Jubilado: nombre_jub), (Viaje: nm_viaje), (Fecha: fecha_in),
(Localidad: nombre_loc), (Visita: nm).
- Las paradas de un viaje no se pueden solapar temporalmente.
- La fecha_fin de una parada ha de ser posterior a su fecha_inicio.
- La fecha_visita de una visita ha de estar entre la fecha_inicio y la fecha_fin de la parada que
incluye la visita.
El sistema que se debe desarrollar no ha de dar de alta los datos de los jubilados ni de sus
inscripciones, dado que existe otro sistema encargado de hacerlo. El sistema ha de permitir efectuar
entre otras las funcionalidades siguientes: alta-viaje, cambio-fechas-parada y consulta-viajeslocalidad.
Cuando el administrativo del club de jubilados quiere dar de alta un viaje, indica su nmero y el tipo
de transporte. A continuacin, para cada parada del viaje indica su fecha de inicio, su fecha de fin, el
nombre de la localidad donde para, el nmero de habitantes de la localidad (slo en caso de que la
localidad no existiera en la base de informacin) y, adems, la informacin de todas las visitas que
incluya la parada (nmero, nombre y fecha). Haced que la interaccin necesaria para llevar a cabo esta
funcionalidad requiera ms de un evento.
Cuando el administrativo del club de jubilados quiere hacer un cambio de fechas de una parada indica
al sistema el nmero de viaje, la fecha de inicio y el nombre de la localidad de la parada. Tambin
indica la nueva fecha de inicio y la nueva fecha de fin de la parada. Hay que tener en cuenta que no se
puede hacer este cambio de fechas si el viaje de la parada tiene algn jubilado inscrito.
Finalmente, cuando un jubilado del club quiere hacer una consulta de viajes a una localidad, l mismo
indica al sistema un nombre de localidad. Entonces el sistema muestra el nmero de viaje de todos los
viajes que tienen alguna parada en la localidad indicada.
correspondientes a alta-viaje, cambio-fechas-parada y consulta-viajes-localidad. Expresad las salidas
de las operaciones con la ayuda del lenguaje OCL.
10. Considerad una empresa que est interesada en un sistema para la gestin de sus proyectos
informticos. Los proyectos se identifican por cdigo y se guarda su fecha de inicio. Un proyecto
puede constar como mximo de tres etapas: especificacin, diseo o implementacin. De cada etapa
se conoce su nombre (que la identifica) y el precio a facturar por hora de trabajo.
Una etapa de un proyecto es dirigida por un empleado, identificado por DNI y de quien se registra
tambin su nombre y plus de sueldo. Adems, un empleado puede participar en diversas etapas de
proyectos. Una participacin se hace en la etapa de especificacin, en la de diseo o en la de
implementacin (segn el nombre de la etapa correspondiente en aquella etapa del proyecto). El
modelo conceptual en UML de este sistema es el siguiente:
Proyecto
cdigo: String
fecha-ini: Fecha
Empleado
1
director
Dirige
Consta-de
Etapa
0.. 3
nombre: String
precio-h: Entero
edp-dir
*
dni: String
*
0..10
Participa
nombre: String
edp-part
participante
plus: Entero
Participacin
153
EtapaDelProy
nm-h: Entero
nombre
Especificacin
Implementacin
Diseo
Usa
Material
*
cdigo: Entero
R.I. textuales:
- Claves clases no asociativas: (Proyecto, cdigo); (Empleado, dni); (Etapa, nombre); (Material, cdigo).
- El nombre de una etapa puede ser slo Especificacin, Diseo o Implementacin.
- Un proyecto no puede constar de la etapa de implementacin si no consta tambin de la de diseo.
- Un empleado no puede dirigir ms de 3 etapas de diseo en total.
El sistema que se debe desarrollar no ha de dar de alta los datos de Etapa, Empleado y Material, dado
que hay otro sistema encargado de hacerlo. El sistema ha de permitir efectuar, entre otras, las
funcionalidades: alta-proyecto, nueva-participacin y listado-proy-con-directivos-participantes.
Cuando el gerente de la empresa quiere dar de alta un proyecto, indica (l mismo) al sistema el cdigo
y la fecha de inicio del proyecto y, para cada etapa de que constar el proyecto, el nombre de la etapa
y el DNI del empleado que dirigir esta etapa del proyecto. Como consecuencia de esta interaccin, el
gerente recibe un listado que indica, para cada empleado que dirige una etapa del proyecto, el nombre
del empleado y el nmero de etapas de otros proyectos dirigidas por aquel empleado. Lgicamente, un
proyecto se da de alta una nica vez. Haced que la interaccin necesaria para llevar a cabo esta
funcionalidad requiera ms de un evento.
El encargado de proyectos, a peticin del gerente, puede dar de alta nuevas participaciones en etapas
de un proyecto. En este caso, se indicar el cdigo del proyecto, el nombre de la etapa, el DNI del
empleado, el nmero de horas de la participacin y, si la etapa es de diseo, el cdigo de los
materiales que se usarn.
Los empleados de la empresa pueden pedir en cualquier momento el listado de proyectos con
directivos participantes. Entonces, el sistema devolver un listado con el cdigo y la fecha de inicio de
los proyectos en que el director de alguna de sus etapas es tambin uno de los participantes de la
etapa.
casos, hay que realizar todas las comprobaciones que sean necesarias.
x Modelo de casos de uso: Diagrama de casos de uso (de las funcionalidades especificadas).
x Modelo del comportamiento del sistema: Todos los diagramas de secuencia y contratos de todas
las operaciones que aparecen. Expresad las salidas con la ayuda del lenguaje OCL.
11. Considerad el caso de la escuela que hace actividades extraescolares del primer parcial de la
asignatura. Suponed que una parte del modelo conceptual en UML de este sistema es el siguiente:
Actividad
154
nombre:string
Edificio
nombre: string
direccin: string *
telfono: entero
Actividad
programada
se_hace_en
*
se_programa
inicio:date
Curso
ao1: ao
ao2:ao
Horario
hora_inicio:hora
hora_fin: hora
Dia_Semana
Actividad
en_edificio
tiene_horario
nombre:string
1
*
Grupo de
actividad
nombre: string
profe: string
matricula
Estudiante
*
cdigo: entero
nombre: string
R.I. textuales:
Claves clases no asociativas: (Curso: ao1,ao2); (Actividad: nombre); (Edificio: nombre);
(Dia_semana: nombre); (Grupo de actividad: nombre, actividad_en_edificio).
Una misma actividad no se puede hacer simultneamente en ms de un edificio.
En un edificio no se pueden hacer ms de cinco actividades en un da.
El sistema ha de permitir efectuar, entre otras, las funcionalidades: programacin de actividades de un

curso y listado de aceptacin de actividades.
El personal de administracin, a peticin del director, programa las actividades de un curso. Indica al
sistema el curso (ao1, ao2) que quiere programar. Entonces, para cada actividad indica su nombre y
la fecha de inicio. Si la actividad no exista previamente, hay que darla de alta en este momento.
Opcionalmente, tambin puede indicar los edificios en que se har la actividad. Para cada edificio
indicar su nombre. Haced que la interaccin necesaria para llevar a cabo esta funcionalidad requiera
ms de un evento.
El director de la escuela puede pedir, en cualquier momento, el listado de aceptacin de las
actividades en un curso determinado. Indicar el curso y un nmero de matriculados. Entonces el
sistema ha de proporcionar un listado de todas las actividades programadas por el curso indicado que
superen en estudiantes matriculados el nmero indicado. El listado mostrar, para cada actividad, su
nombre y el nmero total de estudiantes.
casos, hay que realizar todas las comprobaciones que sean necesarias.
x Modelo de casos de uso: Diagrama de casos de uso (de las funcionalidades especificadas).
x Modelo del comportamiento del sistema: Todos los diagramas de secuencia y contratos de las
operaciones que aparecen. Expresad las salidas con la ayuda del lenguaje OCL.
155
5 Problemas de especificacin en UML

1. Considerad un sistema sencillo de control de prstamos en una biblioteca. El sistema ha
de admitir altas y bajas de socios y de libros. Los socios pueden pedir libros en prstamo,
pero no se pueden tener ms de tres libros prestados en un momento determinado. Los libros
se han de devolver antes de un mes de la fecha del prstamo. Cada vez que un socio devuelve
un libro ms all de la fecha de devolucin, se penaliza reduciendo en una unidad el nmero
de libros que puede tener simultneamente. Cuando llega a cero, el socio se da de baja
automticamente.
157
x
x
x
x
Modelo conceptual de datos

Modelo de casos de uso: diagrama de casos de uso y especificacin de los casos de uso
Modelo del comportamiento del sistema: diagramas de secuencia y contratos de las operaciones
Modelo de estados: diagrama de estados para objetos y casos de uso
2. Considerad un sistema sencillo de reserva y utilizacin de pistas de tenis de un club. El uso de

las pistas est reservado a los socios del club, y se ha de preveer las altas y bajas de socios. El club
tiene tres pistas, que se pueden reservar por bloques de una hora. Las reservas se pueden cancelar si
no son para el mismo da. No hay lmite en las reservas que puede hacer un socio, pero no se pueden
hacer reservas para dentro de ms de un mes. Cada final de mes se enva una factura a los socios,
cargando el uso que han hecho de las pistas durante el mes. Cada hora reservada cuesta un cierto
precio y el importe de la factura se calcula multiplicando la suma de las horas reservadas durante el
mes por aquel precio.
Hay que tener en cuentas si las pistas reservadas se ocupan o no. La primera no ocupacin de una
pista durante un ao natural no se cargar en la factura del socio, pero el resto se cargarn como si se
hubieran utilizado realmente.
x
x
x
x

3. Considera el caso de una empresa que se dedica a gestionar la adopcin de perros. La

empresa dispone de unos perros, cada uno de los cuales tiene un identificador y es de una raza
determinada. Estos perros pueden ser adoptados por los clientes de la empresa. Cada cliente
tiene un identificador y una raza preferida de perros. En un momento determinado, cada cliente
puede tener adoptado ninguno o un perro. Un perro puede estar libre o adoptado por un cliente
determinado. El sistema ha de responder a tres eventos: alta de perro, alta de cliente y cambio de
perro.
Cuando se produce un alta de un perro, nos comunican su identificador y su raza. Si hay algn
cliente cualquiera que est esperando perros de esta raza, se le asigna el nuevo perro, y se produce
una salida Adopcin realizada, indicando el identificador del perro y el del cliente. En caso
contrario, el perro queda libre para ser adoptado en el futuro. No se considera que los perros se
puedan dar de baja.
Cuando se produce un alta de un cliente, nos comunican su identificador y la raza que prefiere. Si
hay algn perro cualquiera de esta raza libre, se le asigna al cliente y se produce una salida
Adopcin realizada, indicando el identificador del perro y el del cliente. En caso contrario, el
cliente resta a la espera de adoptar un perro en el futuro. No se considera que los clientes se puedan
dar de baja.
158
Cuando se produce el evento de Cambio de perro, nos comunican el identificador de la persona que
nos devuelve el perro (no es necesario que nos indiquen el perro que devuelve). El cambio slo se
acepta si tenemos algn otro perro libre de la raza preferida por el cliente.
En este caso, se asigna un perro cualquiera de estos al cliente y se produce una salida Adopcin
realizada, indicando el identificador del perro y el del cliente. No es necesario guardar la historia de
las adopciones hechas por los clientes. Podis suponer que las razas estn codificadas.
x
x
x
x

4. Considera un sistema que registra las compras que hacen los clientes, y que las factura. El
sistema ha de responder a tres eventos: nueva compra, hacer facturas y fin de ao. Cuando se produce
una nueva compra nos comunican el cdigo del cliente que la ha hecho, el cdigo del producto que ha
comprado, la cantidad comprada de este producto y la fecha de la compra. Se supone que en una
compra el cliente slo compra un nico producto.
El sistema accede a dos archivos ya existentes: Productos y Clientes. El archivo de productos
contiene, para cada producto, su cdigo, la descripcin y el precio unitario. El archivo de cliente
contiene, para cada cliente, su cdigo, su nombre y el total comprado en el ltimo ao.
Un producto puede ser comprado por un nmero indeterminado de clientes. Al mismo tiempo, un
cliente puede llegarnos a comprar un nmero indeterminado de productos. Un cliente puede
comprarnos el mismo productor en diversas ocasiones.
Cuando se produce el evento hacer facturas, el sistema ha de generar facturas de todas las compras
que an no se han facturado. Una factura se identifica por un nmero de factura (que el sistema asigna
correlativamente). Interesa registrar, de cada factura, la fecha en que se ha hecho y su importe. Se ha
de generar una factura para cada cliente que tiene una o ms compras no facturadas. El importe de la
factura es la suma de los importes de las compras. Al acabar el proceso, ha de salir un mensaje que
diga el primer y el ltimo nmero de factura generado o, si no ha generado ninguna (porque todas las
compras ya estaban facturadas), el aviso: Ninguna factura realizada. (No tendremos en cuenta el
listado de las facturas.)
Cuando se produce el evento fin de ao, el sistema ha de calcular, para cada cliente, el importe total
de las compras que nos ha hecho durante el ao, y registrarlo en el archivo Clientes.
x
x
x
x

5. Una federacin de ciclismo ha decidido facilitar la organizacin de carreras por etapas para
aficionados. Con esta intencin ha encargado a una empresa de software la construccin de un sistema
informtico capaz de gestionar los datos de una nica carrera.
La carrera consta de diversas etapas, numeradas correlativamene. Los ciclistas tienen un nmero de
dorsal y se quiere conocer tambin su nombre y el de su equipo. En cada etapa, los corredores llegan
en un cierto orden y habiendo tardado un determinado tiempo. La clasificacin general de la carrera se
establece segn el tiempo acumulado durante todas las etapas disputadas.
El sistema ha de responder a los tres eventos siguientes: dar de alta un corredor, registrar los
resultados de una etapa y generar un listado con la clasificacin general. Para dar de alta un
corredor se proporciona su nmero de dorsal, su nombre y el de su equipo. El sistema ha de
comprobar que no exista otro ciclista con el mismo nmero. Los resultados de una etapa se
registran una vez llegan todos los corredores (exceptuando aquellos que abandonan o llegan fuera
de control). Para cada uno de ellos se introduce el nmero, la posicin en la que ha llegado y el
tiempo que ha consumido. El sistema comprueba que los datos entrados son correctos, genera un
nmero de etapa (el ms alto que ya exista ms uno) y almacena los resultados. Adems, se
imprime un listado en el cual se muestra el nmero de etapa y, para cada corredor, la clasificacin,
el nmero, el tiempo, el nombre y el equipo. En cualquier momento se puede solicitar un listado
con la clasificacin general (que ser provisional si no ha acabado la carrera). Se ha de mostrar el
nmero de la ltima etapa recorrida y, para cada corredor que la ha acabado, la clasificacin, el
nmero, el tiempo acumulado, el nombre y el equipo.
x
x
x
x

159
6. Los gestores de El sptimo sello, una sala de cine, han decidido ofrecer a sus clientes un servicio
de reserva por telfono de entradas numeradas. Con este propsito, han encargado a un estudiante de
IS:E la construccin de un sistema informtico.
Los films se proyectan en sesiones, cada una de las cuales se identifica por el da y por el orden dentro
del da. Cada sesin comienza en una hora determinada y proyecta una determinada pelcula (de la
cual slo nos interesa su nombre). En un mismo da, se pueden proyectar pelculas diferentes. La sala
dispone de un nmero fijo de butacas, cada una de las cuales se identifica por el nmero de la fila y el
nmero dentro de la fila.
De todos los eventos a los cuales ha de responder el sistema, slo nos interesan cuatro: 1) compra
directa en ventanilla (sin reserva previa) de una entrada, 2) peticin (telefnica) de reserva de una
entrada, 3) recogida y pago (en ventanilla) de una entrada reservada y 4) consulta de la ocupacin de
una sesin. Otros eventos (p.ej.: altas y bajas de sesiones) pueden ignorarse.
160
Para comprar directamente una entrada se proporciona la sesin, la fila y el nmero de la butaca. Una
vez hechas las comprobaciones pertinentes, se anota la ocupacin de la butaca y se imprime la entrada
con los datos necesarios. En el caso de una reserva se requieren los mismos datos y el DNI de la
persona que ha de recoger la entrada. Despus de las validaciones oportunas, se anota la reserva con el
DNI. Para recoger una reserva se vuelve a introducir la misma informacin; se hacen, como siempre,
las comprobaciones necesarias, se registra que la entrada ha sido pagada y se imprime como en el caso
de la compra directa. Finalmente, la ocupacin de una sesin se puede consultar mediante su
identificador. Como respuesta se obtiene una lista de butacas reservadas y/o compradas directamente,
y una lista de butacas libres.
x
x
x
x

7. El presidente de un comit de programa de un congreso internacional quiere construir un sistema

software que le ayude a controlar las ponencias enviadas al congreso, las personas que revisarn estas
ponencias y las revisiones que stas hacen.
Cada ponencia tiene un cdigo, que la identifica, un ttulo y est escrita por una o ms personas. De
todos los autores de una ponencia hay uno que es el autor principal y el resto se consideran autores
secundarios. Una vez recibida, cada ponencia se enva a uno o ms revisores.
Las personas se identifican por su nombre. Puede ser que una persona sea revisora de una ponencia y
autora de otras ponencias.
El sistema ha de responder a los cinco eventos siguientes: dar de alta un revisor, recepcin de una
ponencia, asignar una ponencia a un revisor, registrar la valoracin que un revisor hace de una
ponencia y generar un listado con las revisiones pendientes de valoracin.
Para dar de alta un revisor se proporciona su nombre. El sistema ha de comprobar que no existe
ningn otro revisor con el mismo nombre.
Cuando se recibe una ponencia, se indica el cdigo de la ponencia, su ttulo, el autor principal y el
resto de autores.
El presidente del comit de programa asigna cada ponencia a diversos revisores indicando, para cada
asignacin, el cdigo de la ponencia y el nombre del revisor. Un mismo revisor puede tener asignadas
diversas ponencias. No se puede asignar un aponencia a un revisor que sea autor de esta misma
ponencia.
Al cabo de unos das, los revisores envan el resultado de la revisin que han hecho de una ponencia
indicando el cdigo de la ponencia, el nombre del revisor y la calificacin que expresa, en una escala
de 0 a 10, la valoracin global que el revisor hace de la ponencia. Como es lgico, un revisor no
puede enviar la valoracin de una ponencia que no le haba sido asignada. Por otro lado, un revisor no
puede enviar dos valoraciones de una misma ponencia.
En cualquier momento, el presidente puede pedir un listado con las revisiones pendientes de
valoracin. Se ha de mostrar, para cada ponencia pendiente de valoracin por parte de un revisor, el
cdigo de la ponencia, su ttulo y el nombre del revisor.
x
x
x
x

8. Considerad una federacin de entidades excursionistas que est interesada en un sistema para el
control de las expediciones efectuadas por los centros excursionistas adscritos a la federacin. Una
expedicin la efecta un centro excursionista a una cierta montaa, con una fecha de inicio y una de
fin. La federacin identifica los centros excursionistas por su nombre y registra tambin su altura. Un
centro excursionista puede efectuar diversas expediciones a la misma montaa, con fechas de inicio
diferentes. A una misma montaa se pueden hacer diversas expediciones, pero en una fecha cualquiera
puede haber como mximo 5 expediciones.
En una expedicin participan diversas personas (como mnimo una). Una persona puede participar en
ms de una expedicin. El sistema guarda informacin nicamente de las personas (que tienen el DNI
como identificador, un nombre y una edad) que han participado en alguna expedicin que tena como
objetivo una montaa de ms de 8000 metros.
Alguno de los componentes de una expedicin a una montaa de ms de 8000 metros puede alcanzar
la cima. En este caso, se registrar este hecho y tambin la fecha en que se ha llegado a la cima. Para
simplificar, suponed que una persona puede alcanzar la cima una nica vez en una misma expedicin.
El sistema que se debe desarrollar nicamente ha de consultar los datos referentes a centros
excursionistas y montaas, dado que ya existe otro sistema encargado de mantenerlos.
El sistema ha de permitir efectuar las operaciones siguiente: alta de expedicin, alta de participante a
una expedicin a una montaa de ms de 8000 metros, alta de persona que ha alcanzado la cima y
emitir un listado de los datos de una expedicin determinada.
161
Cuando se efecta una alta de expedicin, hay que indicar el nombre del centro excursionista, el
nombre de la montaa a la que se efecta la expedicin, la fecha de inicio y la fecha de final de
expedicin.
Cuando se efecta un alta de un participante a una expedicin a una montaa de ms de 8000 metros,
se indica el DNI de la persona, el nombre del centro excursionista que hace la expedicin, la montaa
y la fecha de inicio de la expedicin.
Cuando se efecta un alta de persona que ha llegado a la cima se indica el nombre del centro
excursionista que hace la expedicin, la montaa y la fecha de inicio de la expedicin, el DNI de la
persona y la fecha en que alcanza la cima.
Para pedir el listado de los datos de una expedicin hay que indicar el nombre del centro excursionista que
hace la expedicin, la montaa y la fecha de inicio de la expedicin. Se muestran el nombre del centro, la
montaa, su altura, la fecha de inicio y final de expedicin y, si es el caso, el nombre de todas las personas
que han participado en la expedicin y, opcionalmente, la fecha en que han llegado a la cima.
En todas las operaciones anteriores, hay que realizar todas las comprobaciones que se consideren
adecuadas.
162
x
x
x
x

9. Una gran organizacin ha decidido poner en funcionamiento un sistema que le permita gestionar
los cursos de fomracin a los que asisten sus empleados, ya sea como oyentes o bien mediante una
matrcula oficial.
Los empleados se identifican por cdigo, y tienen tambin un nombre y una categora. Los cursos de
formacin se identifican por nombre, y se registra tambin quin es el organizador. En ambos casos, el
sistema a desarrollar nicamente ha de consultar sus datos, dado que ya existe otro sistema que
mantiene tanto los datos de empleados como de cursos de formacin.
Un empleado se inscribe en un curso de formacin en una cierta fecha. Cada inscripcin hace
referencia a un curso concreto. Un empleado se puede inscribir a tantos cursos como quiera y en un
curso se pueden inscribir diversos empleados. Un empleado se inscribe una nica vez en un mismo
curso de formacin. La inscripcin de un empleado en un curso de formacin puede ser de dos tipos:
como oyente o bien como matrcula oficial. En el primer caso, el sistema guardar informacin
nicamente del motivo por el cual se ha realizado la inscripcin. En el segundo, se registrarn tanto el
motivo como el precio de la inscripcin.
En el caso de las inscripciones correspondientes a matrculas oficiales, el empleado tiene un mximo
de tres convocatorias con tal de aprobar el curso al cual se ha inscrito. Para cada una de las
convocatorias a las que tiene derecho un empleado para un curso determinado, ser necesario registrar
tambin su nota.
El sistema ha de permitir efectuar las operaciones siguiente: nueva inscripcin, asignar nota, emitir un
listado de inscripciones de un empleado y emitir un listado de convocatorias.
Cuando se efecta una nueva inscripcin, hay que indicar el cdigo de empleado, el nombre del curso,
la fecha de inscripcin, el motivo que la justifica, el tipo de inscripcin y, en caso de tratarse de una
matrcula oficial, el precio.
Cuando se asigna una nota de una convocatoria, se indica el cdigo de empleado, el nombre del curso
y la nota correspondiente. El nmero de la convocatoria se asignar, automticamente y de forma
correlativa, por el propio sistema y se mostrar al usuario si la operacin se ha podido efectuar
satisfactoriamente.
Las inscripciones de un empleado se pueden consultar indicando su cdigo y, opcionalmente, el tipo
de inscripcin (si se proporciona slo se listan las inscripciones de aquel tipo). Se muestran, para cada
curso de formacin en el que se ha inscrito el empleado, el nombre del curso, su organizador, la fecha
de inscripcin, el motivo, y, si es el caso, el precio.
Para solicitar el listado de convocatorias hay que indicar el cdigo del empleado y el nombre del curso
de los cuales se pide el listado. Se muestran el nombre y la categora del empleado, el nombre del
curso y, para cada convocatoria de aquel empleado en aquel curso, el nmero de la convocatoria y su
nota.
163
En todas las operaciones anteriores, se deben realizar todas las comprobaciones que se consideren
adecuadas.
x
x
x
x

10. Considerad un club de automovilistas que est interesado en desarrollar un sistema software para
gestionar seguros de vehculos. Un vehculo (identificado por su nmero de matrcula y del que se
registra tambin su modelo) es comprado por un nico conductor (identificado por nmero de licencia
y del que se conoce el nombre) en una cierta fecha. Un conductor puede haber comprado diversos
vehculos. El sistema guardar la informacin de los conductores que han comprado algn vehculo.
Todo vehculo comprado ha de contratar un seguro de accidentes a alguna compaa. Cuando se hace
uno de estos contratos, se registra tambin la fecha de inicio del mismo. Un vehculo no puede estar
contratado en ms de una compaa, mientras que una compaa puede tener diversos contratos de
vehculos diferentes. De las compaas de seguros nos interesa registrar su nombre y la direccin (que
supondremos nica para cada compaa).
Se debe registrar tambin la informacin de los conductores que no son aceptados por las compaas
de seguros, conjuntamente con el motivo de la no aceptacin. Lgicamente, una compaa no podr
tener seguros de coches comprados por conductores que no son aceptados por la compaa. Un
conductor puede no ser aceptado por diversas compaas.
Para simplificar, supondremos que la informacin de conductores, vehculos y compras de vehculos es

matenida por algn sistema externo y, por tanto, el sistema a desarrollar nicamente la tendr que consultar. En
cambio, el sistema que se debe desarrollar ha de permitir efectuar altas de contratos de seguro, bajas de
contratos, registar conductores no aceptados por las compaas y listado de seguros de una compaa.
Cuando se quiere hacer un alta de contrato de seguro hay que indicar la matrcula del coche, el nombre de
la compaa donde se hace el seguro y la fecha en que se hace efectivo el contrato. Cuando se quiere dar
de baja un contrato, se indica la matrcula del coche y el nombre de la compaa. En ambos casos, son los
empleados quienes comunican los datos al sistema, a peticin de algn conductor.
Las compaas de seguros envan al club de automovilistas los listados de conductores que no son
aceptados por la compaa. Algn empleado del club, cuando as lo considere conveniente,
comunicar al sistema el listado de todos los conductores no aceptados por las diversas compaas. Se
indicar, para cada compaa, el nmero de licencia de cada uno de los conductores no aceptados.
Haced que la interaccin necesaria para llevar a cabo esta funcionalidad requiera ms de un evento.
Para pedir el listado de los contratos de una compaa, el director del club de automovilistas indica
directamente al sistema el nombre de la compaa y el sistema muestra, para cada contrato de seguros
de aquella compaa, la matrcula del coche, el nmero de licencia de su propietario y la fecha de
contratacin del seguro. En todos los casos, se deben realizar todas las comprobaciones que se
consideren adecuadas.
164
x Modelo conceptual de datos, que ha de incluir todas las restricciones textuales necesarias y una
instanciacin del modelo que demuestre su validez.
x Modelo de casos de uso:
- Diagrama de casos de uso
- Especificacin del caso de uso del alta de contrato, que ha de incluir todas las
comprobaciones a realizar
x Modelo del comportamiento del sistema:
- Diagramas de secuencia de registrar conductores no aceptados y de listado de
contratos de una compaa
- Contratos de las operaciones correspondientes a estos diagramas de secuencia
11. Considerad un centro de gestin electoral que est interesado en desarrollar un sistema software
para gestionar las candidaturas y resultado de las sucesivas elecciones municipales.
Una candidatura se identifica mediante el partido que la presenta, el municipio al cual corresponde y las
elecciones para las que se ha confeccionado. A cada candidatura se presenta un conjunto de personas
candidatas (como mnimo 3) que pueden presentarse como candidatos independientes o no. Una misma
persona no puede estar en ms de una candidatura por eleccin. El sistema debe tener registradas cules
son las personas candidatas de cada candidatura y tambin si se presentan como independientes o no (tipo
de candidato). Las personas se identifican por su DNI y tambin se quiere registrar su nombre.
Cada una de las elecciones municipales se identifica por su ao de realizacin, los municipios se
identifican por su nombre y los partidos por sus siglas. Adems, el sistema ha de registrar el nombre
de cada partido y la comarca de cada municipio.
Una vez se han efectuado unas elecciones, para las candidaturas que hayan obtenido representacin, el sistema
deber permitir tener registrado el nmero total de representantes obtenido y cules son los candidatos (de la
candidatura) que quedan escogidos como representantes. Para las candidaturas que no hayan obtenido
representacin, el sistema deber permitir registrar el nmero de votos obtenidos por la candidatura.
Para simplificar, supondremos que la informacin de elecciones, municipios, partidos y personas es
mantenida por algn sistema externo y, por tanto, el sistema a desarrollar nicamente la consultar. En
cambio, el sistema a desarrollar ha de permitir efectuar altas de candidaturas, entradas de resultados
de candidaturas sin representacin, entradas de resultados de candidaturas con representacin y
listados de candidatos escogidos de una candidatura.
Cuando se quiere dar de alta una candidatura hay que indicar las siglas del partido, el nombre del
municipio, el ao de las elecciones y, para cada candidato, el DNI, el nombre y su tipo (independiente
o no). Una candidatura se da de alta toda a la vez y, una vez dado el alta, no se pueden aadir
candidatos. Adems, no se pueden dar de alta nuevas candidaturas para elecciones que ya tengan
algn resultado introducido. El alta de candidaturas es efectuada por los empleados del centro a
peticin de los interlocutores de los partidos. Haced que la interaccin necesaria para llevar a cabo
esta funcionalidad requiera ms de un evento.
Cuando un empleado del centro quiere introducir los resultados de una candidatura sin representacin,
indica l mismo al sistema las siglas del partido, el nombre del municipio, el ao de las elecciones y el
nmero de votos obtenido por la candidatura.
Cuando un empleado del centro quiere introducir los resultados de una candidatura con
representacin, indica l mismo al sistema las siglas del partido, el nombre del municipio y el ao de
las elecciones. Adems, para cada candidato que queda escogido como representante, indica su DNI.
Los resultados de una candidatura con representacin se introducen todos a la vez. Haced que la
En cualquier momento, los interlocutores de los partidos pueden pedir un listado de candidatos
escogidos de una candidatura. Entonces, un empleado del centro indica las siglas del partido, el
nombre del municipio y el ao de las elecciones de la candidatura. Como respuesta el sistema muestra,
para cada candidato de la candidatura que haya quedado escogido como representante, el DNI, el
nombre y el tipo de candidato (independiente o no). Evidentemente, para poder pedir este listado, la
candidatura ha de tener representacin.
x Modelo conceptual de datos, que ha de incluir todas las restricciones textuales y atributos
derivados necesarios (en narrativa, no en OCL) y una instanciacin del modelo que demuestre su
validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso de la entrada
de resultados de una candidatura con representacin (que incluya todas las comprobaciones).
x Modelo del comportamiento del sistema: Diagramas de secuencia de alta candidatura y listado
de candidatos escogidos de una candidatura. Contratos de las operaciones correspondientes a estos
diagramas de secuencia (que incluyan todas las comprobaciones a realizar). Si hay, indicad las
modificaciones necesarias en el modelo conceptual de datos de partida. Expresad las salidas con la
ayuda del lenguaje OCL.
165
12. Considerad una biblioteca que est interesada en desarrollar un sistema software para gestionar
los ejemplares de los libros de que dispone y los prstamos de estos ejemplares.
La biblioteca identifica todos los ejemplares de libros mediante un cdigo que asigna la propia
biblioteca. Cada ejemplar corresponde a un determinado libro. De todos los libros de los cuales la
biblioteca tiene algn ejemplar, hay que registrar el ISBN (que los identifica), el ttulo, los autores, la
editorial, el ao de edicin y el nmero mximo de das que el libro se puede dejar en prstamo.
Los socios se identifican por su DNI y tambin se quiere registrar su nombre y telfono. Los socios
pueden realizar prstamos. Para cada prstamo, se debe conocer el socio que lo ha hecho, el ejemplar
prestado, la fecha de inicio del prstamo y la fecha de finalizacin del prstamo. Las fechas de
finalizacin de los prstamos han de respetar el mximo de das que se puede dejar en prstamo el
libro correspondiente al ejemplar.
Un socio no puede llevarse ms de 10 ejemplares en prstamo en una misma fecha de inicio.
Evidentemente, para un determinado ejemplar, puede haber diversos prstamos siempre que sean en
periodos que no se solapen. Tambin puede pasar que un socio haya realizado diversos prstamos de
un mismo ejemplar (que puede no coincidir con la fecha de finalizacin del prstamo).
166
A veces, un socio desea llevarse un ejemplar de un libro que no est disponible porque todos sus
ejemplares estn prestados. Entonces puede hacer una reserva del libro. El sistema registra todas las
reservas de libros que an no han sido satisfechas. De cada reserva, se debe tener la fecha, hora y
minuto en que se ha hecho con tal de poder priorizar las ms antiguas.
El sistema a desarrollar ha de permitir efectuar las funcionalidades siguientes (entre otras): el alta del
prstamo de un ejemplar, el alta de un libro y todos sus ejemplares y el listado de prstamos no
devueltos de un libro.
Cuando un socio quiere hacer un prstamo de un ejemplar, el bibliotecario comunica al sistema el
cdigo del ejemplar y el DNI del socio. El sistema muestra cul es la fecha mxima que se puede
escoger para la finalizacin del prstamo (que depende del nmero mximo de das que el libro del
ejemplar se puede dejar en prstamo). A continuacin, el bibliotecario comunica esta fecha mxima al
socio. Entonces, el socio da una fecha de finalizacin del prstamo. El bibliotecario comunica esta
fecha al sistema as como la fecha en que se realiza el prstamo. Finalmente, el sistema emite un
comprobante del prstamo, que incluye el ttulo y autores del libro, el cdigo del ejemplar, el DNI del
socio y la fecha de finalizacin del prstamo.
Se debe considerar que si un libro tiene reservas no siempre se podr dejar en prstamo un
ejemplar de aquel libro. Concretamente, si el socio que se quiere llevar el ejemplar no tiene
reserva, es necesario que haya ms ejemplares disponibles (sin prstamos no devueltos) que
reservas tiene el libro. Si el socio que se quiere llevar el ejemplar tiene una reserva del libro
correspondiente, tiene que haber ms ejemplares disponibles que reservas tiene el libro ms
antiguas que la suya.
Cuando el bibliotecario quiere dar de alta un libro y todos sus ejemplares comunica al sistema el
ISBN, el ttulo, los autores, la editorial, el ao de edicin y el nmero mximo de das que el libro se
puede dejar en prstamo. Adems, para cada ejemplar del libro indica el cdigo del ejemplar.
Finalmente, el sistema muestra el ISBN, el ttulo del libro y el nmero de ejemplares que se han dado
de alta. Haced que la interaccin necesaria para llevar a cabo esta funcionalidad requiera ms de un
evento. Suponemos, para simplificar, que todos los ejemplares de un libro se dan de alta de una vez.
Cuando el bibliotecario quiere un listado de prstamos no devueltos de un libro comunica al sistema el
ISBN del libro. Como respuesta, el sistema muestra, para cada prstamo no devuelto correspondiente
a un ejemplar del libro, el cdigo del ejemplar prestado, el DNI del socio que ha hecho el prstamo y
la fecha de finalizacin del prstamo.
validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso del alta del
prstamo de un ejemplar.
x Modelo del comportamiento del sistema: Diagramas de secuencia del alta del prstamo de un
ejemplar, del alta de un libro y todos sus ejemplares y del listado de prstamos no devueltos de un
libro. Contratos de las operaciones correspondientes al alta de un libro y todos sus ejemplares y al
listado de prstamos no devueltos de un libro. Expresad las salidas con la ayuda del lenguaje OCL.
13. Considerad una empresa que est interesada en desarrollar un sistema software para gestionar la
informacin relativa a sus empleados. La empresa tiene diversos departamentos (identificados por
nombre y de los que se registra tambin su direccin) en los que pueden trabajar los empleados
(identificados por cdigo de empleado y de los que se registra tambin su sueldo que, como ya
veremos, depende de los departamentos donde trabaja y de las categoras que ste ocupe).
Un empleado puede trabajar en diversos departamentos, pero en una fecha un empleado slo puede
comenzar a trabajar en un departamento. De cada departamento donde trabaja un empleado, se debe
conocer el sueldo base que percibir el empleado por pertenecer al departamento. No hay que guardar
un histrico de esta informacin porque a la empresa le basta con saber slo en qu departamentos
trabajan actualmente sus empleados.
Mientras trabaja en un departamento, un empleado puede tener diversas categoras (de las que se
registra slo su nombre, que las identifica). De cada categora que el empleado tiene dentro de un
departamento, hay que registrar su fecha de inicio y el plus de sueldo que supone para el empleado.
En una fecha concreta, una categora slo puede ser asignada a cinco empleados de la empresa y un
empleado que trabaja en un departamento no puede tener ms de 3 categoras dentro de aquel
departamento. Si un empleado trabaja en diversos departamentos, entonces puede tener categoras
diferentes en cada departamento. Tampoco es necesario guardar un histrico de asignaciones de
categoras.
Adems, el empleado tiene Gerente o Vendedor como categoras asignadas, el sistema debe
registrar informacin adicional. Un gerente tiene entre una y tres personas que lo pueden sustituir.
Para cada posible sustitucin, hay que registrar el orden de prioridad de la sustitucin. Un sustituto
de un gerente ha de ser un empleado cualquiera que trabaje en el mismo departamento, pero que no
tenga la categora de gerente. Lgicamente, un gerente no se puede tener a l mismo como
sustituto. Para los vendedores hay que registrar tambin su da de descanso semanal (o sea, lunes,
martes, etc.).
167
El sueldo global de un empleado es la suma de sueldos de los departamentos donde trabaja. El sueldo
de un empleado en un departamento es igual al sueldo base de aquel empleado en el departamento
ms la suma de pluses de todas las categoras del empleado dentro del departamento.
Para simplificar, supondremos que la informacin de departamentos, empleados y fechas la mantiene
algn sistema externo y, por tanto, el sistema a desarrollar nicamente la deber consultar. En cambio,
el sistema ha de permitir asignar categoras bsicas a un empleado de un departamento, asignar
sustitutos a un gerente, emitir un listado de empleados de un departamento y conocer los empleados
que son gerentes de ms de un departamento.
Cuando se quieren asignar categoras bsicas a un empleado de un departamento, un administrativo de
la empresa indica al sistema (a peticin del responsable de recursos humanos) el nombre del
departamento, el cdigo del empleado, la fecha de las asignaciones y, para cada asignacin, el nombre
de la categora y el plus de sueldo. Para poder asignar la categora, el empleado ha de trabajar ya en el
departamento y no se pueden asignar categoras a empleados de un departamento si ste tiene ms de
100 empleados. Para simplificar, haced que el resultado de la ejecucin de esta funcionalidad no
permita asignar la categora de gerente ni la de vendedor. La interaccin necesaria para llevar a cabo
esta funcionalidad ha de requerir ms de un evento.
168
Cuando un administrativo, a peticin del director general de la empresa, asigna sustitutos al gerente de
un departamento indica al sistema el nombre del departamento, el cdigo del empleado y, para cada
empleado que lo puede sustituir, su cdigo y el orden de prioridad de la sustitucin.
Cuando un empleado quiere emitir el listado de empleados de un departamento, indica l mismo al
sistema el nombre del departamento. Como resultado recibe un listado donde se indica para cada
empleado del departamento su cdigo y la fecha en que comenz a trabajar ms, para cada categora
del empleado, el nombre de la categora.
En cualquier momento, el director general puede obtener un listado del cdigo de los empleados que
son gerentes de ms de un departamento.
validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso de la
asignacin de sustitutos de un gerente.
x Modelo del comportamiento del sistema: Diagramas de secuencia de asignar categoras bsicas,
listado de empleados de un departamento y listado de los gerentes de ms de un departamento.
Contratos de las operaciones correspondientes a estos diagramas de secuencia (que incluyan todas las
comprobaciones a realizar). Expresad las salidas con la ayuda del lenguaje OCL.
14. Como probablemente ya sabis, con motivo del 25 aniversario de la FIB, se ha
celebrado por primera vez la Festibity, que pretende ser la cena anual del sector de las
tecnologas de la informacin. Los organizadores de esta velada (FIB y Cercle Fiber) nos
piden que los ayudemos especificando un sistema que d soporte a algunas de las actividades
relacionadas con la cena.
De la Festibity se harn diversas ediciones. Cada edicin se identifica por el da, mes y ao de su
celebracin. Tambin se quiere conocer el lugar en que se celebra y el precio. En cada edicin se
establecen posibles descuentos. Un descuento se identifica por el concepto dentro de la edicin a la
que pertenece y se registra el tanto por ciento de descuento.
La Festibity tiene un conjunto de empresas que hacen de patrocinador en algunas ediciones. Los
patrocinadores se identifican por su NIF y el sistema tambin quiere conocer su nombre, direccin,
telfono y el nombre de la persona de contacto. Cada vez que una empresa hace de patrocinador de
una edicin de la Festibity hay que registrar el tipo de patrocinio, la aportacin realizada y el nmero
mximo de invitaciones que se le asignan.
El sistema ha de mantener informacin actualizada sobre las personas del sector que han asistido a
alguna Festibity. Las personas se identifican por su nombre y tambin se quiere conocer el nombre de
su empresa, su telfono y el cargo que ocupa.
De todas las ediciones de la Festibity, hay una que ha de tener un tratamiento especial en el sistema: la
edicin en curso (la prxima que se celebrar). Para esta edicin hay que mantener informacin sobre
los asistnetes. Hay dos maneras de asistir a la Festibity: comprando una entrada o bien siendo
invitado. Como es natural, no se puede comprar una entrada si se ha sido invitado. Para las persona
que compran una entrada hay que registrar si se aplica alguno de los descuentos establecidos para esta
edicin. Se puede aplicar un descuento como mximo. Las personas invitadas no se consideran
asistentes hasta que han confirmado su asistencia. Cuando lo hacen, el sistema registra la fecha de
confirmacin. El nmero de asistentes a la edicin en curso se calcula sumando las entradas vendidas
y los invitados que han confirmado.
Por otro lado, por lo que respecta a los invitados, se quiere distinguir entre los que lo son por parte de
la FIB y los que lo son por parte de los patrocinadores. Para los invitados de la FIB se ha de conocer
la fecha en que se les envi la carta de invitacin. Para los invitados de los patrocinadores se quiere
saber cul es el patrocinador que los invita. Naturalmente, slo los pueden invitar los patrocinadores
que lo son de la edicin actual y un patrocinador no puede invitar a ms personas que el nmero
mximo de invitaciones asignado.
El sistema ha de permitir efectuar las funcionalidades siguientes (entre otras): invitar a una persona
y listado de los ms colaboradores. El sistema no ha de dar de alta los patrocinadores, los
descuentos ni las ediciones de la Festibity, porque hay otro sistema que se encarga de ello.
Cuando se quiere invitar a una persona, un administrativo de la FIB indica al sistema cul es la persona
que se quiere invitar. Si la persona ya ha asistido a alguna edicin, slo hay que indicar su nombre. Si no,
habr que indicar tambin el nombre de su empresa, el telfono y el cargo que ocupa, con tal de que el
sistema lo pueda dar de alta. Si es un invitado de la FIB, se considera que la fecha de envo de la carta es
la fecha actual. Si es un invitado de un patrocinador, hay que indicar el nombre del patrocinador. Podis
suponer que el sistema siempre conoce la fecha actual (denotada por fechaActual). Haced que la
Cuando el decano de la FIB quiere saber cules son las empresas ms colaboradoras con la
Festibity, l mismo lo solicita al sistema. Como respuesta el sistema muestra el nombre y la
aportacin total de las empresas que han patrocinado la Festibity como patrocinador principal
ms de tres veces.
169
x Modelo conceptual, que ha de incluir todas las restricciones textuales y atributos derivados
necesarios (en narrativa, no en OCL).
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso invitar a una
persona; por motivos de brevedad, basta con que escribis los cursos de eventos (tpico y
alternativos).
correspondientes a los casos de uso invitar a una persona y listado de los ms colaboradores. Por
lo que respecta a los contratos, basta con que escribis la cabecera de cada operacin, la precondicin,
la postcondicin y la salida. Expresad las salidas con la ayuda del lenguaje OCL.
15. Considerad una cadena hotelera que est interesada en desarrollar un sistema software para
gestionar las reservas de habitaciones que se hacen en sus hoteles. La cadena hotelera identifica sus
hoteles por un nombre y registra tambin su direccin. Un hotel tiene diversas habitaciones. Las
habitaciones de un hotel se identifican por un nmero de habitacin dentro del hotel (obviamente, dos
hoteles diferentes pueden tener dos habitaciones con el mismo nmero) y se registra tambin si son
individuales o dobles.
170
Los clientes (identificados por DNI y de los que se guarda tambin el nombre y la direccin) pueden
hacer reservas en los hoteles. Cuando se hace una reserva se debe conocer el cliente que la hace, en
qu fecha se hace la reserva, qu tipo de habitacin se quiere (individual o doble) y las fechas de
inicio y de fin de la reserva. No se puede hacer una reserva si el hotel no tiene, como mnimo, una
habitacin del tipo especificado que est disponible durante todos los das que se quiere reserar.
Lgicamente, una persona puede hacer diversas reservas en una misma fecha pero, para simplificar,
supondremos que en una fecha determinada un cliente no puede hacer ms de una reserva en un
mismo hotel. Adems, supondremos que dos reservas diferentes de un mismo cliente pueden tener
periodos de reserva (definidos por las fechas de inicio y final de la reserva) que se solapen (incluso en
reservas de un mismo hotel).
Peridicamente, la cadena hotelera asigna las reservas que tiene a las habitaciones de los hoteles.
Cada reserva da lugar a una asignacin. Un asignacin se define por el cliente y la fecha de la reserva
y la habitacin del hotel que se asigna a la reserva. Como es lgico, no puede haber dos asignaciones
de una misma habitacin que se solapen entre s. Adems, el tipo de la habitacin asignada ha de
coincidir con el tipo de habitacin solicitada en la reserva y el hotel de la habitacin ha de ser tambin
el de la reserva.
Para simplificar, supondremos que la informacin de los hoteles y de sus habitaciones la mantiene
algn sistema externo y, por tanto, slo la habremos de consultar. En cambio, el sistema a desarrollar
ha de permitir efectuar las funcionalidades siguientes (entre otras): hacer-reerva, asignar-reservas y
listado-habitaciones-disponibles.
Cuando se quiere hacer una reserva, un empleado de la cadena (a peticin del cliente) comunica al
sistema el cdigo del cliente que hace la reserva, el hotel, la fecha actual, el tipo de habitacin y las
fechas de inicio y de final de la reserva.
Cuando se quieren asignar reservas a los hoteles de la cadena, un empleado de la empresa (a peticin
del director de ocupaciones) indicar al sistema, para cada hotel de la cadena, su nombre y, para cada
habitacin del hotel a la que se le asigna una reserva, el nmero de la habitacin, el cliente y la fecha
en que se ha hecho la reserva. Haced que la interaccin necesaria para llevar a cabo esta funcionalidad
requiera ms de un evento.
Cuando un empleado quiere un listado de las habitaciones disponibles de un hotel en una fecha, l
mismo indica al sistema el nombre del hotel y la fecha y el sistema muestra, para cada habitacin que
no tenga una asignacin en aquella fecha, el nmero de la habitacin y su tipo.
x Modelo conceptual, que ha de incluir todas las restricciones textuales y atributos derivados
necesarios (en narrativa, no en OCL) y una instanciacin del modelo que demuestre su validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificacin del caso de uso de hacerreserva.
x Modelo del comportamiento del sistema: Diagramas de secuencia correspondientes a todos los
casos de uso. Contratos de las operaciones correspondientes a asignar-reservas y listadohabitaciones-disponibles. Expresad las salidas con la ayuda del lenguaje OCL.
171

Especificacion de Sistemas de Software en UML

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Especificacion de Sistemas de Software en UML

Uploaded by

Copyright:

Available Formats

Ernest Teniente Lpez

Dolors Costal Costa

Dolors Costal Costa

Primera edicin: setiembre de 2003

Los autores, 2003

De la traduccin, Sergio Morales Garca, 2003

Edicions UPC, 2003

CPET (Centre de Publicacions del Campus Nord)

Depsito legal: B-33082-2003

Introduccin a la ingeniera del software

Introduccin a la orientacin a objetos

3.1 Motivacin y orgenes .........................................................................................................27

4.1 Modelo conceptual de datos en UML..................................................................................39

El proceso unificado de desarrollo del software

Introduccin a la ingeniera del software

Introduccin a la ingeniera del software

Ingeniera del software

Introduccin a la ingeniera del software

Evolucin de Costes del hardware y del software

Los autores, 2003; Edicions UPC, 2003

Introduccin a la ingeniera del software

Evolucin del software

Introduccin a la ingeniera del software

Caractersticas del software

Los autores, 2003; Edicions UPC, 2003

Introduccin a la ingeniera del software

Introduccin a la ingeniera del software

Aplicaciones del software

Los autores, 2003; Edicions UPC, 2003

Introduccin a la ingeniera del software

Crisis del software

Introduccin a la ingeniera del software

Resultados de proyectos de software

Acabado y operativo, pero

Los autores, 2003; Edicions UPC, 2003

Introduccin a la ingeniera del software

Ingeniera del software

Establecimiento y uso de principios de ingeniera orientados a

Introduccin a la ingeniera del software

Los autores, 2003; Edicions UPC, 2003

Introduccin a la ingeniera del software

Introduccin a la ingeniera del software

Visin genrica de la ingeniera del software

Los autores, 2003; Edicions UPC, 2003

Introduccin a la ingeniera del software

Ciclo de vida clsico

Introduccin a la ingeniera del software

Los autores, 2003; Edicions UPC, 2003

Introduccin a la ingeniera del software

Introduccin a la ingeniera del software

The CHAOS Report, 1994

Los autores, 2003; Edicions UPC, 2003

Determinacin de los requisitos del software

Especificaciones de sistemas software

Requisitos del sistema vs. requisitos del software

Requisito: Condicin o capacidad necesitada por un usuario con

Los autores, 2003; Edicions UPC, 2003

Etapas de la ingeniera de sistemas

Determinar requisitos del sistema global

Determinar requisitos del sistema global

Sistema que recibe y verifica los productos

Los autores, 2003; Edicions UPC, 2003

Especificar los requisitos del sistema global

Diseo del sistema global