Especificacion de Sistemas de Software en Uml PDF

Ernest Teniente López
Dolors Costal Costa

M. Ribera Sancho Samsó
Especificación de sistemas
software en UML
POLITEXT 153
software en UML
POLITEXT
Dolors Costal Costa

M. Ribera Sancho Samsó
Ernest Teniente López
software en UML
EDICIONS UPC
Primera edición: setiembre de 2003
Diseño de la cubierta: Manuel Andreu
© Los autores, 2003
© De la traducción, Sergio Morales García, 2003
© Edicions UPC, 2003

Edicions de la Universitat Politècnica 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
Producción: CPET (Centre de Publicacions del Campus Nord)

La Cup. Gran Capità s/n, 08034 Barcelona
Depósito legal: B-33082-2003

ISBN: 84-8301-723-7
Quedan rigurosamente prohibidas, sin la autorización escrita de los titulares del copyright, bajo las san-
ciones establecidas en las leyes, la reproducción total o parcial de esta obra por cualquier medio o pro-
cedimiento, comprendidos la reprografía y el tratamiento informático, y la distribución de ejemplares de
ella mediante alquiler o préstamo públicos.
Índice
1 Introducción a la ingeniería del software 9
2 Requisitos y especificación 17
3 Introducción a la orientación a objetos 27
3.1 – Motivación y orígenes .........................................................................................................27

3.2 – Aspecto estático...................................................................................................................32
3.3 – Aspecto dinámico ................................................................................................................33
3.4 – El lenguaje UML (Unified Modeling Language) ................................................................36
4 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
5 El proceso unificado de desarrollo del software 101
6 Colección de ejercicios 107

Introducción a la ingeniería del software 1
Introducción a la ingeniería del software

• Software
– Importancia
– Evolución
– Características
– Crisis del software
• Ingeniería del software
– Definiciones
– Características
– Visión genérica
• Paradigmas
– Ciclo de vida clásico
– Prototipaje
– Modelo en espiral
• Bibliografía
Evolución de Costes del hardware y del software
100%
HARDWARE
SOFTWARE
1960 70 80 90
© Los autores, 2003; © Edicions UPC, 2003

Evolución del software
Batch Distribución
Poca distribución Hardware barato
A medida Software de consumo Aplicaciones web
Multiusuario
Tiempo real Sistemas sobremesa
Bases de datos Sistemas expertos
Software de producto Cálculo paralelo
1950 60 70 80 90 2000
10
Características del software
• Se desarrolla, no se fabrica.
• No se estropea.
• Mantenimiento más difícil 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
• Gestión
• De ingeniería
• Científico
• Empotrado
• De PC
• De inteligencia artificial

Crisis del software

• ¿Crisis?
– ¡Aflicción crónica!
• Problemas:
– Evolución continua
– Insatisfacción de los usuarios
– Poca calidad
– Mantenimiento difícil
• Causas:
– Naturaleza del software
– Complejidad
– Gestión
• Mitos:
– De gestión
– De los clientes
– De los diseñadores
12
Resultados de proyectos de software
Acabado y operativo, pero In fo rm e C H A O S (19 9 4 )

Acabado en el plazo y
fuera de plazo, de presupuesto presupuesto, satisfaciendo los
y sin satisfacer todos los requisitos
requisitos
16,2 %
52,7 %
Cancelado durante el
desarrollo
31,1 %

Ingeniería del software
Establecimiento y uso de principios de ingeniería orientados a

obtener software:
• Económico
• Fiable
• Que funcione eficientemente
• Que satisfaga las necesidades de los usuarios
13
Un ingeniero ...
• Dispone de un abanico de técnicas probadas que dan resultados

precisos.
• Se preocupa de la fiabilidad y del rendimiento.
• Trata de reducir costes y complejidad.
• Basa sus modelos en teorías matemáticas sólidas.
• Construye prototipos de los nuevos diseños.
• Utiliza diagramas formales.

El proceso de la ingeniería
Formulación
Análisis
Generación
Selección
Especificación
Implementación
Modificación
14
Visión genérica de la ingeniería del software
• Definición:
• Análisis del sistema
• Planificación del proyecto
• Análisis de requisitos del software
• Desarrollo:
• Diseño del software
• Codificación
• Prueba
• Mantenimiento:
• Corrección
• Adaptación
• Mejora

Ciclo de vida clásico

ANÁLISIS REQS.
ESPECIFICACIÓN
DISEÑO
CODIFICACIÓN
PRUEBA
MANTENIMIENTO
15
Prototipaje
ANÁLISIS
REQUISITOS
PRODUCTO DISEÑO
RÁPIDO
REFI_ PROTO_
NAMIENTO TIPO
EVALUACIÓN

Modelo en espiral
Planificación Análisis de riesg s
Evaluación Ingeniería
16
Bibliografía
• Pressman, R.S
software Engineering: A Practitioner’s Approach.
5a edición.
McGraw Hill, 2001. (Cap. 1y 2)
• The CHAOS Report, 1994

http://www.standishgroup.com/sample_research/chaos_1994_1.php

Requisitos y especificaciones 1
Requisitos y especificaciones
• Determinación 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
– Estándares de documentación
• Bibliografía
17
Requisitos del sistema vs. requisitos del software
Requisito: Condición o capacidad necesitada por un usuario con

tal de solucionar un problema o conseguir un objetivo
• La solución al problema se puede realizar con software, hardware,

manualmente, o con una combinación de los tres.
• Si la solución es compuesta, antes de diseñar los detalles de un

componente software concreto hay que diseñar el sistema global.
Ejemplo de sistema compuesto: refinería automatizada

Ejemplo de sistema sólo software: control de stock

Etapas de la ingeniería de sistemas
• Determinar requisitos del sistema global

• Especificar requisitos del sistema global
• Diseño del sistema global
HARDWARE SOFTWARE PERSONAS
Determinar
requisitos
Especificar
requisitos
Diseño
Ingeniería Ingeniería
del hardware del software
Ingeniería de sistemas
18
Determinar requisitos del sistema global
• Comprensión de los objetivos y necesidades del usuario

• Definir el conjunto de sistemas que podrían satisfacer las necesidades u
objetivos y evaluarlos
• Escoger el sistema más adecuado
¿QUÉ SISTEMA HAY QUE CONSTRUIR?
ALMACÉN
Sistema que recibe y verifica los productos

solicitados a los proveedores y los almacena en las
estanterías

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
albarán
3. Control de calidad
defectuoso 4. Actualizar pedido PEDIDO A

PROVEEDOR
5. Determinar dónde va
PRODUCTOS
ESTANTERÍAS
6. Almacenar
PRODUCTOS EN ESTANTERÍAS
19
Diseño del sistema global

• Determinar la arquitectura general del sistema que mejor satisfaga
los requisitos en términos de:
– componentes físicos: hardware, software, personas
– comunicación entre ellos
error
1. Comprobar si esperado
error
2. Comprobar correspondencia
albarán
3. Control de calidad
defectuoso 4. Actualizar pedido PEDIDO A

PROVEEDOR
5. Determinar dónde va PRODUCTOS

ESTANTERÍAS
orden
6. Almacenar
SOFTWARE
MANUAL PRODUCTOS EN ESTANTERÍAS
HARDWARE

Diseño del sistema global
Recepción
albarán pedido
aviso albarán
defectuoso resultado
Sistema
Inf rmátic
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
pedido aviso
SISTEMA
albarán INFORMÁTICO orden
resultado errores

Especificar los requisitos del software

• Describir con detalle el comportamiento externo del componente
software concreto
albarán pedido
Tratar Recibir
albaranes pedidos
error
pedidos
resultado Actualizar
pedidos productos
estanterías
Emitir
orden
orden
21
Estrategias de determinación de los requisitos
• Solicitarlos al usuario.
• Extraerlos de un sistema software existente.
• Sintetizarlos a partir del sistema global.
• Descubrirlos mediante experimentación.

Requisitos del software

• Funcionales
– Describen todas las entradas y salidas y la relación entre ambas
• de datos
• de proceso
• No funcionales
– Definen las cualidades generales que ha de tener el sistema al
realizar su función
• Eficiencia
• Tipos de interfaces
• Económicos
• Estructurales
• Políticos
• Calidad
22
Factores de calidad del software
• Eficiencia
• Flexibilidad
• Integridad
• Mantenibilidad
• Portabilidad
• Fiabilidad
• Actualidad
• Reusabilidad
• Testability
• Usabilidad
• Interoperabilidad

Factores de calidad del software: Conflictos
• Eficiencia
• Flexibilidad
• Integridad
• Mantenibilidad
• Portabilidad
• Fiabilidad
• Actualidad
• Reusabilidad
• Testability
• Usabilidad
• Interoperabilidad
23
Propiedades deseables de las especificaciones
• No ambiguas
• Completas
• Verificables
• Consistentes
• Modificables
• “Trazables”
• Usables durante la operación y el mantenimiento

¿Cómo organizar una especificación de requisitos?

Estándar de documentación ANSI/IEEE (I)
1. Introducción
1.1 Propósito de la especificación
1.2 Alcance del producto
1.3 Definiciones y abreviaturas
1.4 Referencias
1.5 Visión general de la especificación
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características de los usuarios
2.4 Restricciones generales
2.5 Suposiciones y dependencias
3. Requisitos específicos
4. Apéndices
5. Índice
24
¿Cómo organizar una especificación de requisitos?

Estándar de documentación ANSI/IEEE (II)
3. Requisitos específicos
3.1 Requisitos de interfaces externas
3.2 Requisitos funcionales
3.3 Requisitos de rendimiento
3.4 Requisitos lógicos de la base de datos
3.5 Restricciones de diseño
3.6 Atributos del sistema software
a) Fiabilidad
b) Disponibilidad
c) Seguridad
d) Mantenibilidad
e) Portabilidad
3.7 Organización de los requisitos específicos
3.8 Otros requisitos

Bibliografía
• Shumate, K.; Keller, M.

Software Specification and Design - A Disciplined Approach for Real-
Time 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

Introducción a la orientación a objetos 1
Introducción a la orientación a objetos
• Motivación y orígenes
• Visión de un sistema software

– Aspecto estático
– Aspecto dinámico
• La notación UML
27
Motivación
- Aparición de los lenguajes de programación orientados a objetos

SIMULA: finales de los años 60
SMALLTALK: principios de los años 70
- El uso de estos lenguajes requiere un nuevo enfoque de análisis y

de diseño.
- Otros factores:
Desarrollo de nuevas aplicaciones
Énfasis principal en la estructura de datos
Aparición de los primeros métodos de diseño y de análisis

orientados a objetos

Orígenes
Fusion
OOSE Martin-Odell
Procesos y modelos
recomendados Shlaer &
BOOCH Mellor
OMT 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
Visión de un sistema software

Objetos
Objeto:
Entidad que existe en el mundo real.
Tienen identidad y son distinguibles entre ellos.
el avión con una manzana un semáforo

matrícula 327
la factura 3443 el avión con

matrícula 999
29
Clases de objetos
Clase de objetos: Describe un conjunto de objetos con:
- las mismas propiedades
- comportamiento común
- idéntica relación con otros objetos
- semántica común
abstracción clase avión

Avión
Abstracción: 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, dirección, teléfono, ...
Avión => modelo, capacidad, color, ...
Persona Avión
Nombre Modelo
Dirección Capacidad
Teléfono Color
Fecha_nacimiento
Edad
- Cada atributo tiene un valor (probablemente diferente) para cada objeto.
- Los atributos pueden ser básicos o derivados.
30
Operaciones (I)
Operación: Es una función o transformación que se puede aplicar a

los objetos de una clase.
Persona Avión
Nombre Modelo
Dirección Capacidad
Teléfono Color
Cambio_dirección Reparar
Cambio_trabajo Mover
- Las operaciones de un objeto son invocadas por otros objetos.
Método: especificación procedimental (implementación) de una

operación dentro de una clase.
Encapsulación: Consiste en separar los aspectos externos de un objeto

de los detalles de implementación.

Operaciones (II)
- En las operaciones, hay que indicar también el tipo de los argumentos y

del resultado.
Triángulo Cuadrado
Color Color
Posición Posición
Girar (ángulo: Real)
Girar (ángulo: Real)
Seleccionar (p:Punto):Booleano
Polimorfismo:
- Una misma operación se puede aplicar a diferentes clases.
- Su implementación depende de cada clase.
31
Asociaciones
Asociación:
Define la manera de enlazar o conectar objetos de
diferentes clases.
Ejemplo: Un país tiene una única capital.
País Ciudad
tiene_capital
Nombre Nombre
Habitantes Habitantes

Generalización / Especialización
Generalización: Es el acto o resultado de distinguir un concepto
que es más general que otro.
Empleado
Nombre
Sueldo
Especialización Contratar Generalización
Pagar_sueldo
Jubilar
Directivo Viajante ...

Periodo contrato Región
Desp. autor. Cuota
Autorizar gastos Asignar región
Jubilar Asignar cuota
Herencia: Permite que las propiedades y las operaciones de una clase sean
accesibles en sus subclases.
32
Orientación a objetos (I)
Aspecto estático: Describe la estructura estática de los objetos del

sistema y sus interrelaciones.
Intra - objeto Inter - objetos
Clases de objetos Asociación

Aspecto Atributos Generalización
estático Operaciones ...

Descripción del comportamiento (I)
Los objetos se comunican mediante la invocación de operaciones

de otros objetos.
33
Descripción del comportamiento (II)
Aspecto dinámico (de comportamiento): Describe los aspectos de un

sistema que cambian con el tiempo.
El aspecto dinámico 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 métodos actuales en el momento

de tratar el aspecto dinámico.

Descripción del comportamiento (III)
Diagrama de transición de estados: Especifica el

cambio de estado de un objeto causado por los
eventos.
nacimiento
Ejemplo: estado civil de una persona
Soltera
boda
divorcio Casada
Divorciada boda boda
divorcio separación enviudar
Separada Viuda
enviudar
34
Descripción del comportamiento (IV)
Esquema de eventos: Permite especificar la interacción entre

diferentes objetos (usado por el método de Martin y Odell [MO92]).
Cliente envía Aceptar

pedido pedido
pedido
entregado
Preparar Entregar Cerrar
pedido
pedido pedido pedido
cerrado
pedido
preparado
factura
Enviar Cliente paga pagada
factura factura
factura
enviada

Orientación a objetos (II)
Aspecto estático: Describe la estructura estática de los objetos del

sistema software y sus interrelaciones.
Aspecto dinámico (de comportamiento): Describe los aspectos de un

sistema software que cambian con el tiempo.
Intraobjeto Interobjetos
Clases de objetos Asociación

Aspecto
Atributos Generalización
estático
Operaciones ...
Aspecto Diagrama de Esquema de eventos

dinámico transición de
estados
35
Análisis y diseño orientados a objetos

Análisis:
- Creación de una especificación del problema y de los requisitos
- Qué ha de hacer el sistema software
Diseño:
- Definición de una solución software que satisfaga los requisitos
- Cómo lo hará el sistema
… orientados a objetos
• Se usan los mismos conceptos en análisis y diseño.
• Es difícil determinar dónde acaba el análisis orientado a objetos y

dónde comienza el diseño:
- estrategia de desarrollo iterativa
- diferencias de criterios según los autores

El lenguaje UML (Unified Modeling Language)
Mayo‘01 – OMG adopta UML 1.4 UML 1.4

Industrialitzación
Noviembre‘97 – OMG adopta UML 1.1 UML 1.1

como estándar Estandarización
Enero‘97 - Publicación del UML 1.0 UML 1.0
public UML Partners’

feedback Junio‘96 & Octubre‘96 Expertise
UML 0.9 & UML 0.91
Unificación
OOPSLA ‘ 95 Unified Method 0.8
Booch’93 OMT-2
Other methods Booch‘ 91 OMT-1 OOSE

Fragmentación
36
El triángulo del éxito
U.M.L. Notación
Proceso Herramienta
(metodología)
Rational Rose,
Craig Larman Objecteering,
The Unified Process Visio, etc.

Modelo de análisis (especificación)
Modelo
de análisis
Modelo de Modelo Modelo del Modelo de los

casos de uso conceptual de comportamiento estados
los datos del sistema
Casos de uso Diagramas Diagramas de Diagramas

- nivel alto estáticos de secuencia de estado de
- esencial estructura del sistema objetos y
para objetos casos de uso
del dominio
Diagramas de Contratos
casos de uso para las
operaciones
del sistema
37
Bibliografía
• Pressman, R.S.
Software Engineering: A Practiotioner’s 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 1
Modelo conceptual de los datos en UML
• Introducción
• Objetos y clases de objetos
• Atributos
• Asociaciones
• Clase asociativa
• Generalización/Especialización
• Agregación y composición
• Ampliaciones
• Ejemplos
39
Modelo
de análisis


de objetos casos de uso
del dominio
operaciones
del sistema

Modelo conceptual de los datos
Es la representación 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 avión con una manzana un semáforo

matrícula 327
la factura 3443 el avión con

matrícula 999

Clase de objetos
Clase de objetos: Describe un conjunto de objetos con:
- las mismas propiedades
- comportamiento común
- idéntica relación con otros objetos
- semántica común
abstracción clase avión

Avión
Abstracción: 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 escáner del código 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 Venta
Línea de venta Cliente Producto
Pago
42
Ejemplo TPV: Atributos
Un atributo es una propiedad compartida por los objetos de una clase.
Supermercado Venta
TPV
dirección: String fecha: Date
núm-pv: Integer
nombre: String hora: Time
Línea de venta Cliente Producto

cantidad: Integer nombre: String upc:Integer
telfs [1..*]: Integer descripción [0..1]:String
Pago tipcli: TipoCliente precio: Integer
importe: Integer
Los atributos:
- Pueden tomar valores nulos (por ejemplo: descripción).
- Pueden ser multivaluados (por ejemplo: telfs).
- Pueden ser definidos por el usuario mediante enumeraciones.
-Por ejemplo, TipoCliente se define a parte como una enumeración con los
valores que puede tener y que son: Normal y Preferente.

Asociaciones
Es la representación de relaciones entre dos o más objetos.
- dirección de lectura
Vive en
Persona Ciudad
- nombre de asociación
43
Asociaciones de orden superior a dos
Alumno
Asignatura Cuatrimestre
Se matricula

Multiplicidad de las asociaciones binarias
Dada una instancia a de la clase A cualquiera, la multiplicidad del

extremo B define cuántas instancias de B se pueden asociar con a en
un momento de tiempo determinado.
1
A B
2..5
A B
1..*
A B
2, 5
A B
*
A B
1..3,7..10,15..*
A B
0..*
A B
0..1
A B
44
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 cuántas instancias de
C se pueden asociar con la pareja (a,b).
A B
0..2
C

Multiplicidad en las asociaciones ternarias – Ejemplos
Profesor
1..2
* * Cuatrimestre
Asignatura
Se responsabiliza
Según este esquema, para toda pareja de asignatura y cuatrimestre, ha de haber como
mínimo un profesor reponsable.
Alumno
0..500
* * Cuatrimestre
Asignatura
Se matricula
Este esquema permite que haya alguna pareja de asignatura y cuatrimestre para la cual
no hay ningún alumno que se haya matriculado de la asignatura en el cuatrimestre.
45
Restricciones textuales
Las restricciones que no se pueden especificar gráficamente con la notación UML se
especifican de forma textual
La especificación textual se puede hacer con lenguaje natural, con OCL, etc.
Especialidad 1 Pertenece a *
Equipo médico
nom-esp cod-equipo
* *
Tiene Médico Asignado a
* *
num-col
1- Dos especialidades diferentes no pueden tener el mismo nom-esp.

2- Dos equipos médicos diferentes no pueden tener el mismo cod-equipo. Restricciones de
3- Dos médicos diferentes no pueden tener el mismo num-col. clave externa
4- Un médico no puede estar asignado a un equipo médico que pertenezca a una
especialidad que el médico no tiene.

Nombre de rol en las asociaciones

Cada extremo de una asociación es un rol, que tiene diversas propiedades como:
- nombre
- multiplicidad
El nombre de rol identifica un extremo de la asociación y describe el papel

jugado por los objetos en la asociación.
* Vuela hacia 1
Vuelo Ciudad
destino
Nombre de Rol
Describe el Rol de una
ciudad en la asociación
vuela hacia
46
Asociaciones recursivas
Asociaciones en las que una misma clase de objetos participa más

de una vez (con papeles diferentes o no).
Persona
0..2 *
padre hijo
Tiene
Persona
* *
Tiene por amigo

Clase asociativa
Representa una asociación que se puede ver como una clase.
Estudiante Asignatura
EstáMatriculado
dirección nombre
nombre * * créditos
Matrícula
nota Clase asociativa
Los atributos hacen referencia a la
asociación
Su vida depende de la asociación
Empresa Persona
Emplea
nombre * * nombre
dirección
Contrato
sueldo
47
Ejemplo de clase asociativa

Asiste
Participante * * Reunión
Proyecto * * Empleado
Participa
No es equivalente a:
Reunión
*
* Asistir
Proyecto * Empleado

Generalización/Especialización
Identificar elementos comunes entre los objetos definiendo relaciones de

superclase (objeto general) y subclase (objeto especializado).
superclase
Persona
E G
sexo {disjoint, complete}
Hombre Mujer
subclase
discriminador - Es el nombre de la partición. Ha de ser único entre los
atributos y roles de la superclase.
disjoint – Un descendiente no puede ser de más de una subclase.
overlapping – Un descendiente puede ser de más de una subclase.
complete – Se han especificado todas las subclases.
incomplete – La lista de subclases es incompleta.
La clasificación puede ser estática o dinámica.
48
Permite entender los conceptos en términos más generales, refinados y abstractos.
Hace los diagramas más expresivos.
• Todos los objetos de la subclase lo son también de la superclase.

• La definición de la superclase tiene que ser aplicable a la subclase
- atributos
- asociaciones
- restricciones
(- operaciones)
Pago Paga por

Venta
cantidad: Dinero
tipo {disjoint, complete}
Pago Pago Pago

en metálico a crédito con talón

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
Atributos y 1 Venta
asociaciones comunes Pago
asociaciones
cantidad: Dinero
adicionales
{disjoint, complete} tipo
Pago Pago Pago

* núm-talón: Integer
Identifica crédito
Cada pago se
1
trata diferente
Tarjeta
49
Generalización/Especialización
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.
Paga por 1
Atributos y 1 Venta
asociaciones comunes Pago
asociaciones
cantidad: Dinero adicionales
{disjoint, complete} tipo
Pago Pago Pago

* núm-talón: Integer
Identifica crédito
Cada pago se
1
trata diferente
Tarjeta

Agregación
La agregación es un tipo de asociación usada para modelar relaciones “parte-todo”
entre objetos.
El “todo” se denomina compuesto y las “partes” componentes.
Ruta Contiene
Segmento
* *
* Usa 1..*
Menú Receta
La distinción entre asociación y agregación es a menudo subjetiva.

La única restricción que añade la agregación respecto a la asociación es que las
cadenas de agregaciones entre instancias de objetos no pueden formar ciclos.
A1
A * * B
* * B1 B2
* C * C1 C2 C3
A2 A3 A4
50
Composición
La composición es un tipo de agregación por la cual:
- La multiplicidad del extremo compuesto puede ser como máximo 1 (como

máximo un componente lo es de un compuesto).
- Si un componente está asociado a un compuesto y el compuesto se borra

entonces el componente también se ha de borrar (no lo puede sobrevivir).
Tiene
Mano Dedos
1 0..5
Contiene
Venta LíneadeVenta
1 0..*
Contiene
Catálogo Especificación
1..* de Producto
0..1

Agregación y composición - Cuándo mostrarla
Agregación/Composición
• Existe una semejanza todo-parte física o lógica.
• Algunas propiedades del todo se propagan a las partes
(como destrucción, movimiento...).
Composición
• La vida de la parte está incluida en la vida del compuesto.
• Existe una dependencia crear-borrar de la parte respecto al
compuesto.
51
Información derivada
Un elemento (atributo o asociación) es derivado si se puede calcular a partir de otros
elementos.
Se incluye cuando mejora la claridad del modelo conceptual.
Una constraint (regla de derivación) ha de especificar cómo se deriva.
Atributo derivado
Departamento
* Tiene *
Empleado
nombre
/núm_empleados
El número de empleados de un departamento d es igual
al número de ocurrencias de Tiene donde aparece d.
Asociación derivada
* Está situado en 1 Ciudad

Departamento
1 1
La ciudad donde trabaja un empleado
es la ciudad donde está situado su
* departamento.
*
Empleado
Tiene /Trabaja en

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
dirección
52
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 básica.
Una instancia de la clase básica puede participar como máximo en una de las
asociaciones unidas por xor.
persona propietaria
* Persona
cuenta per
* {xor}
Cuenta
*
cuenta emp
Empresa
1
empresa propietaria
Subset
Indica que una asociación es un subconjunto de otra asociación
* Pertenece a *
Persona {subset} Comisión
1 Preside *

Cambiabilidad
La cambiabilidad indica si los valores de un atributo o el extremo de una
asociación pueden cambiar o no.
Cambiable (changeable) - opción por defecto -
Persona Vive en *
*
Ciudad
teléfono {changeable} residente ciudad-res
{changeable}
teléfono y ciudad-res son “cambiables”
Congelado (frozen)
Persona Nació en 1
*
Ciudad
fecha-nac {frozen} per-nacida ciudad-nac
{frozen}
fecha-nac y ciudad-nac son “congelados”
Sólo-añadir (addOnly)
Persona Ha residido en
* *
Ciudad
título-aca {addOnly} residente ciudad-res
{addOnly}
título-aca y ciudad-res son “sólo-añadir”
53
Generalización/Especialización - Ejemplos discriminador

Pago Pago
num-pago num-pago
tipo-pago importe
importe
{disj., inc.} tipo-pago
{disj., inc.} tipo-pago
Efectivo Tarjeta Efectivo Tarjeta

cambio
cambio num-tarjeta num-tarjeta
Empleado Departamento
nombre-empleado Trabaja en
sueldo nombre-dept: Tdept
/dept * 1
{disj., inc.} /dept

/dept de un empleado es el nombre-dept del
departamento donde trabaja el empleado.
Dirección Producción Tdept es una enumeración de Dirección, Producción y

Administración.
matr-coche precio-hora-ext

Clasificación múltiple
Variante de generalización/especialización en la cual una superclase puede tener

diversas jerarquías de especialización en función de diferentes discriminadores.
Persona
sexo estado
{disjoint, complete} {disjoint, complete}
Hombre Mujer Soltera Casada Divorc. Viuda
54
Herencia múltiple
Variante de generalización/especialización en la cual una subclase tiene
más de una superclase.
Estudiante
universidad estudios
{disjoint, incomplete} {disjoint, incomplete}
EstUPC EstUAB EstUB Inform. Mates Empres.
{incomplete} {incomplete}
InformUPC
Sólo se puede utilizar si no hay conflictos de herencia.
Conflicto de herencia: Una clase tiene más de una superclase con un

mismo atributo/asociación/(operación) que no proviene de un único
antecesor.

Equivalencias notacionales (I)

En UML:
Polígono
número_lados
Triángulo Rectángulo Pentágono ...
es equivalente a:
Polígono
Triángulo Rectángulo Pentágono ...
¿Problema?
55
Equivalencias notacionales (II)
En UML:
Docencia_Asignatura
1 1 1
* * *
Clase_Teoría Clase_Probl Clase_Lab
es equivalente a:
Docencia_Asignatura
1
* * *
Clase_Teoría Clase_Probl Clase_Lab

Ejemplos (I)
¿Qué solución es mejor?
Persona_UPC
nombre
num-asignaturas [0..1]
sueldo [0..1] con valores nulos
Persona_UPC
nombre
tipo
{overlapping, incomplete}
Estudiante Empleado
num-asignaturas sueldo
sin valores nulos
56
Ejemplos (II)
¿Qué solución es mejor?
Persona_UPC
nombre
teléfono [0..1]
con valores nulos
Persona_UPC
nombre
tener_teléfono
Persona_con_teléfono
teléfono
sin valores nulos

Ejemplos (III)
Empleado Proyecto
nombre: Texto cod_proy: Texto
proy_emp: Proyecto descripción: Texto
Un atributo no puede tomar valores de una de las clases del modelo conceptual.
Este caso es una asociación.
Empleado *
Proyecto
*
nombre: Texto cod_proy: Texto
Trabaja en descripción: Texto
57
Bibliografía
• 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

Object Constraint Language (OCL) 1
Object Constraint Language (OCL)
• ¿Para qué sirve?

• Propiedades del modelo conceptual
• Colecciones: conjuntos, bolsas y secuencias
• Navegación para clases asociativas
• Generalización / Especialización
• Cómo especificar en OCL
58
¿Para qué sirve OCL?
• Los modelos gráficos no son suficientes para una especificación precisa y

no ambigua.
• OCL:
– Es un lenguaje formal.
– Es un lenguaje de navegación que permite definir expresiones (o sea, no tiene
efectos laterales).
– No es un lenguaje de programación, sino de especificación.
– Es un lenguaje tipificado.
• Se usa para:
– Especificar invariantes (restricciones y reglas de derivación) del modelo
conceptual.
– Especificar precondiciones, postcondiciones y salidas de las operaciones.

Ejemplo
Persona director * Empresa

fechaNacimiento: Fecha 1 empresasDirigidas
nombre: String nombre: String
apellido: String empleado contratador /númEmpleados: Integer
sexo: SexoVálido * 1..*
/estáCasado: Boolean
/estáParado: Boolean esposa
/edad: Integer
0..1
esposo 0..1
Trabajo
Matrimonio
tít lo: String
l gar : String fechaInicio: Fecha
fecha: Fecha salario: Integer
SexoVálido se define como en meración de Hombre y M jer.
59
Propiedades de los objetos
• Cada expresión 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.
– navegación a través de las asociaciones.
Propiedades de los atributos de una clase de objetos:

• Propiedad: edad de una persona -- entero
context Persona inv
la expresión ha de ser cierta para todas
las instancias de la clase
self.edad
instancia contextual de la expresión (punto de partida)
• Restricción de la propiedad: “la edad de las personas ha de ser superior o igual a
cero”
context Persona inv o, alternativamente: context p:Persona inv
self.edat >= 0 p.edat >= 0

Propiedades de los objetos (II)

Propiedades de una navegación a través de asociaciones:
Partiendo de un objeto concreto, podemos navegar a través de las asociaciones
del modelo conceptual para referirnos a otros objetos y a sus propiedades.
• ¿Cómo se navega? Objeto.nombre-de-rol
objeto de partida nombre de rol de una asociación 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 asociación (con minúsculas).
• Ejemplos de navegación:
context Empresa inv
self.director -- director de la empresa -- Persona
self.director.nombre -- nombre del director -- String
self.empleado -- empleados de la empresa -- set(Persona)
self.empleado.esposo -- esposos de los empleados -- set(Persona)
60
Colecciones: conjuntos, bolsas y secuencias

Una colección de elementos puede ser del tipo:
• Conjunto: cada elemento aparece una única vez en la colección.
• Bolsa (multiconjunto): la colección puede contener elementos repetidos.
• Secuencia: bolsa donde los elementos están ordenados.
Ejemplo:
• “número 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 navegación:
• Si la multiplicidad de la asociación es 1, el resultado es un objeto (o un conjunto de un
único objeto).
• Si la multiplicidad de la asociación es >1, el resultado es un conjunto.
• Si se navega por más de una asociación y la multiplicidad de alguna de ellas es >1, el
resultado es una bolsa, aunque a veces puede ser un conjunto.

Operaciones básicas sobre colecciones (I)
Select: Especifica un subconjunto de la colección.

– “personas mayores de 50 años 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 colección 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)
versión simplificada: self.empleado.fechaNacimiento
61
Operaciones básicas sobre colecciones (II)
forAll: Expresión 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: Condición que satisface al menos un elemento.

– “como mínimo un empleado de la empresa se ha de llamar Jack”
context Empresa inv
self.empleado -> exists(nombre=‘Jack’)
IsUnique: Devuelve cierto si la expresión se evalúa a un valor diferente

para cada elemento de la colección.
– “la clave externa de Empresa es su nombre”
context Empresa inv
Empresa.allInstances -> isUnique(nombre)

Combinación de propiedades
• Las propiedades se pueden combinar para formar expresiones más
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 máximo 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)
– “Definición del atributo derivado numEmpleados”

context Empresa inv
numEmpleados = (self.empleado -> size())
– “Definición del atributo derivado estáParado”

context Persona inv
estáParado = if self.contratador-> isEmpty() then true else false
62
Navegación por clases asociativas
Navegación a una clase asociativa:

Se utiliza el nombre de la clase asociativa (en minúscula).
• “Los sueldos de las personas que trabajan en la UPC han de ser más altos que
1000”
context Persona inv
(self.contratador -> select(nombre=‘UPC’)).trabajo)
-> forAll (t | t.salario > 1000)
Navegación 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.estáParado = false
• “Un matrimonio ha de ser entre una mujer y un hombre”
context Matrimonio inv
self.esposa.sexo = #mujer and self.esposo.sexo = #hombre

Generalización - Especialización (herencia)

CuentaCorriente efectúa Transacción
num-cc: Integer 1 * fecha: Date
entidad: String cantidad: Integer
{disjoint, complete}
Ingreso Extracción
Navegación:
c-oficina: Integer persona: String
• Acceso directo a las propiedades de la superclase
context Ingreso inv
self.cuentaCorriente.num-cc -- número de cuenta de un ingreso
• Acceso a las propiedades definidas en el nivel de subclase

context CuentaCorriente inv
self.transacción.oclAsType(Extracción).persona -> asSet() -- personas que han extraído dinero de
una cuenta corriente
Aspectos adicionales:
• Selección de objetos que pertenecen a la subclase.
self.transacción -> select(oclIsTypeOf=Ingreso) -- ingresos de una cuenta
• Las propiedades de las subclases se pueden ignorar.

self.transacción -> select(fecha.isafter(5-4-1998)) -- transacciones de una cuenta posteriores al 5-4-1998
63
Cómo especificar en OCL

• Una expresión OCL se especifica siempre comenzando en una clase de
objetos determinada: instancia contextual .
• Una expresión se puede especificar de diversas maneras, según 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 restricción restringe el valor del atributo de una clase, ésta es la clase
candidata.
– Si la restricción restringe el valor de los atributos de más de una clase,
cualquiera de éstas es la candidata.
– Normalmente, cualquier restricción debería navegar a través del menor número
posible de asociaciones.

Cómo 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))
-- ¿cuál es preferible en este caso?
64
Operaciones estándar de tipo booleano
Operación Notación Resultado

or a or b boolean
and a and b boolean
or exclusivo a xor b boolean
negación not a boolean
igualdad a=b boolean
desigualdad a <> b boolean
implicación a implies b boolean
if-then-else if a then b else b’ tipo de b ó b’

Operaciones estándar de tipo string
Operación Notación Resultado
concatenación string.concat(string) string

tamaño string.size() integer
substring string.substring(int,int) string
igualdad string1 = string2 boolean
desigualdad string1 <> string2 boolean
Operaciones estándar de una clase de objetos
Operación Resultado
allInstances Retorna el conjunto de todos los elementos de la clase de objetos
65
Operaciones estándar de tipo colección
size() Número de elementos de la colección

count(object) Número de ocurrencias del objeto
includes(object) Cierto si el objeto pertenece a la colección
includesAll(collection) Cierto si los elementos del parámetro collection están en la
colección actual
excludes(object) Cierto si el objeto no pertenece a la colección
excludesAll(collection) Cierto si los elementos del parámetro collection no están en la
colección actual
isEmpty() Cierto si la colección está vacía
notEmpty() Cierto si la colección no está vacía
sum() suma de todos los elementos (los elementos se han de poder
sumar)
exists(expression) ¿expression es cierta para algún elemento?
forAll(expression) ¿expression es cierta para todos los elementos?
isUnique(expression) Cierto si expression evalúa a un valor diferente para cada
elemento de la colección actual

Operaciones estándar (específicas) de tipo conjunto
select(expression) Selecciona el subconjunto de elementos del conjunto actual para

los cuales expression es cierta
reject(expression) Elimina el subconjunto de elementos del conjunto actual para los
cuales expression es cierta
union(set) Resultado de unir los dos conjuntos
intersection(set) Resultado de la intersección de los dos conjuntos
union(bag) Resultado de unir el conjunto actual con la bag
intersection(bag) Resultado de la intersección del conjunto actual con la bag
66
Bibliografía
• 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.
Páginas web con información de OCL:
• http://www.omg.org
• http://www.software.ibm.com/ad/ocl
• http://www.rational.com

Modelo de casos de uso en UML 1
Modelo de casos de uso en UML
• Propósito
• Casos de uso
• Diagrama de casos de uso
• Especificación de casos de uso
• Estructuración de casos de uso
• Identificación de casos de uso
67
Modelo
de Análisis


del dominio
operaciones
del sistema

Determinación 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.
Especificación de los requisitos de un sistema software:
• Comprensión de los requisitos.

• Organizar los requisitos según las funciones del sistema.
• Delimitar la frontera del sistema.
Modelo de casos de uso: ¿Cuáles son las funciones del sistema PARA CADA ACTOR?
Énfasis: USOS del sistema, valor añadido 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 algún valor para el [Jacobson 92].
Extracción 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 estímulo que provoca la ejecución 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
Comunicación
69
Especificación de casos de uso
De alto nivel: Descripción breve de las acciones del caso de uso.
Caso de uso: Nombre del caso de uso

Actores: Lista de actores, iniciador
Propósito: Objetivo del caso de uso
Resumen: Descripción breve de las actividades que se han de realizar
Tipo: 1 - primario, secundario, opcional
2 - real o esencial
Expandida: Descripción detallada de las acciones y los requisitos

Añade a la especificación de alto nivel:
Referencias cruzadas: Requisitos a los que hace referencia

Curso típico de eventos: Descripción detallada de la interacción
(conversación) entre los actores y el sistema
Descripción de los eventos paso a paso
Cursos alternativos: Describe excepciones al curso típico

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 escáner del código de
barras) y software para ejecutar el sistema.
Se nos pide que especifiquemos el software de este sistema.
70
Ref # Función Ejemplo TPV: Funciones básicas Categoría

R1.1 Registrar la venta actual - los productos comprados. evident
R1.2 Calcular el total de la venta actual, incluyendo impuestos y cálculo de evident
“puntos de cliente”.
R1.3 Capturar la información de los productos comprados de un código de evident
barras, usando un escáner o bien a partir de la entrada manual del
código de barras (Universal Product Code).
R1.4 Descontar las cantidades vendidas del stock, cuando se confirme. hidden
R1.5 Guardar información sobre les ventas realizadas. hidden
R1.6 El cajero ha de identificarse al iniciar una sesión con un identificador evident
y una clave de acceso.
R1.7 Mostrar la descripción y el precio de cada producto comprado. evident
R2.1 Tratar los pagos en efectivo capturando la cantidad entregada evident
por el cliente y calculando el cambio.
R2.2 Tratar los pagos con tarjeta de crédito capturando el número de la evident
tarjeta desde un lector de tarjetas o manualmente, pedir confirmación
del pago al servicio de autorización de crédito (externo) con una
conexión vía módem.
R2.3 Registrar los pagos con tarjeta con tal que puedan ser facturados. hidden

Ejemplo TPV: Diagrama de casos de uso
Terminal Punto de Venta
Iniciar sesión
Cajero Compra de productos
Devolver producto Cliente
Acabar sesión
Responsable
de compras Fijar pPrecio
Comprar a proveedores
Director
comercial
Hacer ofertas
Proveedor
71
Ejemplo TPV: Entorno del sistema
supermercado tradicional
Compra de
productos
CAJERO Devolver CLIENTE
producto
Iniciar
sesión
supermercado electrónico
Compra de
productos
CLIENTE
Devolver
Producto

Ejemplo TPV: Especificación del caso de uso “compra de productos en efectivo”

Caso de uso: Compra de productos en efectivo.
Actores: Cliente (iniciador), Cajero.
Propósito: 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 típico de eventos
Acciones de los actores Respuesta del sistema

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.
4. El Cajero registra el identificador de 5. Determina el precio del producto y añade
cada producto. su información a la cuenta.
Si hay más de una unidad del producto el
Cajero puede introducir la cantidad.
6. Al acabar la entrada de productos el 7. Calcula y muestra el total de la cuenta.
Cajero lo indica.
(continúa)
72

8. El Cajero dice el total al cliente.
9. El Cliente entrega una cantidad de
dinero posiblemente más grande que el
total de la cuenta.
10. El Cajero indica el dinero que ha 11. Calcula y muestra el cambio al Cliente.
recibido. Imprime un recibo.
13. El Cajero deposita el dinero recibido 12. Registra la venta que se acaba de
en la caja y extrae el cambio. hacer.
El Cajero da el cambio y el recibo al
Cliente.
14. El Cliente se va con los productos
comprados.
Cursos Alternativos
• Línea 4: Se introduce un identificador de producto inexistente. Indicar error.

• Línea 9: El Cliente no tiene suficiente dinero. Cancela la venta.

Casos de uso esenciales vs casos de uso reales
Esencial (muy abstracto) Real

Independiente interfaces y tecnología (muy concreto)
Esencial
Acción del actor Respuesta del sistema

1. El cliente se identifica. 2. El sistema valida la identificación.
3. Etc... 4. Etc...
Real
Acción del actor Respuesta del sistema

1. El cliente inserta la tarjeta. 2. Solicita el PIN.
3. Teclea el PIN por teclado. 4. Muestra el menú de opciones.
5. Etc... 6. Etc...
73
Estructuración de casos de uso: Secciones

Caso de uso: Compra de productos
Propósito: 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.

Estructuración de casos de uso: Secciones

Section: Pagar en efectivo
1. El Cliente entrega una cantidad de dinero

posiblemente más grande que el total de la
cuenta.
2. El Cajero indica el dinero que ha 3. Calcula y muestra el cambio al Cliente.
recibido.
4. El Cajero deposita el dinero recibido y
extrae el cambio.
El Cajero da el cambio al Cliente.
Cursos alternativos
• Línea 4: Efectivo insuficiente para devolver el cambio. Pedir cambio a otra persona.
Section: Pagar con tarjeta
Cursos típicos y alternativos para la historia del pago con tarjeta.
74
Estructuración de casos de uso: Relación <<include>>
<<include>>: Relación 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 <<include>>
Compra de productos Pagar con tarjeta
Cliente
caso de uso que se efectúa realmente
Compra de productos + Pagar con tarjeta
Cajero Cliente

Ejemplo TPV: <<include>>
Cajero Comprar Cliente

<<include>> productos <<include>>
Pagar en Pagar con
efectivo tarjeta Servicio de
autorización
<<include>> <<include>> de crédito
Devolver producto
Contabilidad
1. El caso de uso comienza cuando un cliente llega
2. (Pasos intermedios excluidos)...
9. El Cliente escoge el tipo de pago: 10. Registra la venta que se acaba de
a. If en efectivo include hacer.
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
Identificación de casos de uso
Método 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.
Método 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.

Bibliografía
• 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 1
Modelo del comportamiento en UML
• Introducción
• Diagramas de secuencia del sistema
• Contratos de las operaciones del sistema
• Otras consideraciones
– Compartición de información entre las operaciones de un diagrama
– Información elemental vs información compuesta
– Número de eventos del diagrama de secuencia
– Redundancia entre los modelos
• Bibliografía
77
Modelo
de análisis


del dominio
operaciones
del sistema

Descripción del comportamiento en OO
Los objetos se comunican mediante la invocación de operaciones

de otros objetos
78
“Especificación” del comportamiento en OO
SISTEMA
• Consideramos un tipo especial “sistema” que engloba a todos los objetos.

• La especificación 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
Diagramas de secuencia del sistema
• Objetivos:
– Identificar los eventos y las operaciones del sistema.
• Punto de partida:
– Casos de uso.
– La descripción de los diagramas de secuencia del sistema es posterior a la descripción
de los casos de uso.
• Casos de uso:
– Describen cómo los actores interactúan con el sistema software.
– El actor genera eventos hacia el sistema que exigen la ejecución de alguna operación
como respuesta (durante la interacción).
– A partir de los casos de uso podemos identificar cuáles 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
invocación
• Definiremos un diagrama de secuencia para cada curso

relevante de eventos de un caso de uso.
80
Ejemplo: Comprar producto
actor sistema como caja negra
:Cajero :Sistema
inicioVenta(pv)
:venta
entrarProd(venta,prod,cant)
*
finVenta(venta)
:importe
pago(venta,importePago)
:cambio
evento del sistema

invoca operación

Construcción de un diagrama de secuencia
1. Dibujar una línea vertical que representa el sistema.

2. Dibujar una línea para cada actor que interactúa 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
Representación de iteraciones de eventos
:Actor :Sistema
evento1()
iteración de un
únic event evento2()
*
evento3()
*
iteración de una evento4()
secuencia de event s

Diagramas de secuencia: <<include>>

• Los casos de uso definidos mediante <<include>> requieren un diagrama de
secuencia para la parte común 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 específica: pagar con tarjeta
:Gestión Tarjetas :Cajero :Sistema :Sist. Autor. Crédito

pagTarjetaCrédito(núm-t,fecha-cad)
solicitudAprob(núm-t)
tratarRespTarjeta(respuesta)
añadeAprobación(respuesta)
82
Eventos y operaciones
• Evento del sistema: Evento externo generado por un actor

• Operación del sistema: Operación interna que se ejecuta como
respuesta a la comunicación del evento
La comunicación de un evento del sistema provoca la ejecución de

una operación del sistema con el mismo nombre y los mismos
parámetros.

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 especificación.
Ejemplo:
SISTEMA
inicioVenta(pv) :venta
finVenta(venta) :importe
pago(venta,importePago): cambio
83
Eventos y el límite 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
entrarProd
El actor “cliente” no interactúa *
directamente con el sistema,
sólo lo hace el “cajero”. finVenta
pago
frontera del
sistema

Contratos de las operaciones
• Contrato de una operación

Describe el comportamiento del sistema en términos de:
– cuáles son los cambios de estado de la base de información
– cuáles son las salidas que el sistema proporciona
cuando se invoca la operación.
• El tipo de descripción es declarativo:

– El énfasis se pone en qué hará la operación más que en cómo lo hará.
• Los contratos de las operaciones incluyen primordialmente:

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

Nombre: Nombre y argumentos de la operación (cabecera de la operación)
Responsabilidades:
Descripción informal del propósito de la operación
Excepciones:
Descripción de la reacción del sistema a situaciones excepcionales
Precondiciones:
Suposiciones sobre el estado del sistema antes de la invocación de la operación
Postcondiciones:
Cambios de estado que se han producido:
- altas/bajas de instancias de clases de objetos
- altas/bajas de instancias de asociaciones
- modificación de atributos
- generalización de un objeto
- especialización de un objeto
- cambio de subclase de un objeto
Salida:
Descripción de la salida que proporciona la operación en pseudo-OCL
Observad el vínculo que existe entre los contratos de las

operaciones y el esquema conceptual.

Ejemplo: Esquema conceptual de partida
PuntoDeVenta 1 * Venta 1 1..* LíneaDeVenta

num-pv día
tiene consta de cantidad
hora
/importe *
corresponde a
1
Producto
código
precio
RI textuales: descripción
1- La clave externa de PuntoDeVenta es num-pv.
2- La clave externa de Producto es código.
3- Un punto de venta no puede tener más de una venta con el mismo día y hora.
85
Ejemplo: Operación inicioVenta
Nombre: inicioVenta(pv) :venta
Responsabilidades:
Iniciar el registro de una venta.
Excepciones:
Si no existe ningún 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 día y la hora actuales.
- Alta de una instancia de la asociación ‘tiene’ que asocia la venta V y la
instancia de PuntoDeVenta con num-pv=pv.
Salida: V

Ejemplo: Operación entrarProd
Nombre: entrarProd(venta,prod,cant)
Responsabilidades:
Registrar una línea de una venta.
Excepciones:
Si no existe ningún Producto con código=prod, indicar error.
Precondiciones:
Existe un Producto con código=prod.
Postcondiciones:
- Alta de una instancia de LíneaDeVenta L con cantidad=cant.
- Alta de una instancia de la asociación ‘consta de’ que asocia L y venta.
- Alta de una instancia de la asociación ‘corresponde a’ que asocia L y el
Producto con código=prod.
Salida:
86
Ejemplo: Operación 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

Ejemplo: Operación 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
Compartición de información entre las operaciones de un diagrama

• UML no precisa de qué manera las operaciones de un diagrama de secuencia
pueden compartir información.
• Dos posibles soluciones son:
Mediante argumentos Mediante información adicional en
adicionales de las operaciones el esquema conceptual
:Cajero :Sistema
:Caixer :Sistema
inicioVenta(pv)
inicioVenta(pv)
:venta
Venta
* entrarProd(venta,prod,cant) día
entrarProd(pv, prod,cant)
* hora
/importe
finVenta(venta)
finVenta(pv)
:importe
:importe
pago(pv,importePago) VentaEnCurso
:cambio
:cambio
Restricción implícita: El valor del argumento

‘venta’ es el mismo en todos los eventos del
diagrama.

Información elemental vs información compuesta
• La información tratada por una operación se expresa tanto a nivel de los

parámetros como de la salida que aparecen en la cabecera de la
operación.
• Hay dos tipos de información:

– Información elemental: contiene un único elemento de información indivisible.
• Propiedad
• Clase de objetos predefinida: Integer, Real, ...
– Información compuesta: es una composición de informaciones elementales (y,

por tanto, hay que especificar cómo se define la composición).
Ejemplo: ResumenVentas(num-pv) que devuelve un listado de ventas con la información:
Para cada Producto p vendido en aquel PuntoDeVenta num-pv mostrar
- el código del producto
- la cantidad total vendida de p en num-pv
ResumenVentas (num-pv:Integer): ???
88
Información Compuesta - Definición
Problema: ¿Cómo se especifica el contenido de una información compuesta?

– En la actualidad, UML no propone ninguna solución.
– Utilizaremos una adaptación de la definición de flujos de datos que se hace en
el análisis estructurado (Yourdon, 1993).
• Mecanismos básicos de definición de información compuesta

– Inclusión: i1 = i2 + i3 + i4
– Selección: i1 = [i2 l i3 l i4]
– Repetición: 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

Información compuesta - Contratos de las operaciones

• Las operaciones necesitarán mecanismos para manipular (acceder, construir,
etc.) la información compuesta que aparece en su cabecera.
• Se necesita ectender OCL para poder manipular información compuesta.
Ejemplo: contracto de la operación 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.LíneaDeVenta.Venta.PuntoDeVenta.num-pv->includes(num-pv)
Hacer
cant = p.LíneadeVenta ->
select (lv | lv.Venta.PuntoDeVenta.num-pv = num-pv).cantidad -> sum()
Mostrar (p.código)
Mostrar (cant)
89
Diagrama de secuencia: ¿Cuántos eventos?
• El número de eventos de un diagrama de secuencia depende de cómo se

produzca la interacción entre los actores y el sistema software.
:Cajero :Sistema :Sistema-X :Sistema
inicioVenta(pv): venta 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 información al sistema.
• Los dos diagramas de secuencia pueden
ser correctos, según las circunstancias.

Redundancia - Ejemplo
• El esquema conceptual contiene restricciones de integridad (gráficas y textuales).

• Los contratos de las operaciones tienen precondiciones, que son requisitos del
contenido del esquema conceptual para poder ejecutar una transacción.
¿Es necesario que las precondiciones incluyan la comprobación de las restricciones del
modelo conceptual?
Empleado Nombre: AltaEmpleado (cod-emp, sueldo)

cod-emp Responsabilidades: dar de alta al empleado
sueldo Excepciones: -
Precondiciones: no existe Empleado con cod-emp
R.I. textual: dos empleados no Postcondiciones:
pueden tener el mismo código. creación de un nuevo objeto Empleado con
cod-emp y sueldo
Salida: -
¿Hay que poner esta precondición?
90
Redundancia - Definición
• Una especificación es redundante si un mismo aspecto del sistema

software está especificado diversas veces.
• La redundancia dificulta la modificabilidad de la especificación

porque si varía aquel aspecto hay que modificar todos los modelos
donde se le hace referencia.
¡La especificación no debería ser redundante!
• Redundancias posibles:
– Entre el esquema conceptual y los contratos

– Entre los diagramas de secuencia y los contratos
– ...

Redundancia - Esq. conceptual y contratos (I)
Persona Coche :Persona :Sistema

* tiene 0..3
nom-p matr
año CompraCoche(nom-p,matr)
• Significado habitual: • Significado alternativo:

Nombre: CompraCoche (nom-p,matr) Nombre: CompraCoche (nom-p,matr)
Responsabilidades: compra de un coche Responsabilidades: compra de un coche
Excepciones: Excepciones:
… (las que se deducen de las prec.) … (las que se deducen de las prec.)
Precondiciones: Precondiciones:
- existe Persona p con nom-p - existe Persona p con nom-p
- existe Coche c con matr - existe Coche c con matr
- p no tiene c - p no tiene c
- p no tiene ya 3 coches Postcondiciones:
Postcondiciones: - Si p tiene ya 3 coches entonces
- creación de una asociación tiene eliminar la asociación entre p y el
entre p y c coche c’ de más antigüedad
Salida: - - creación de una asociación tiene
entre p y c
Salida: -
91
Redundancia - Esq. conceptual y contratos (II)
• ¿Cómo se han de interpretar los contratos en relación al modelo

conceptual?
– Precondiciones:
• Qué ha de contener el Modelo Conceptual para intentar ejecutar una

operación.
– Restricciones del modelo conceptual:
• Están garantizadas después de la ejecución de todas las operaciones

que participan en un caso de uso.
• Se rechazan todas las operaciones de un caso de uso si su ejecución

viola (globalmente) alguna restricción de integridad del modelo
conceptual.

Redundancia - Esq. conceptual y contratos (III)
Persona Idioma
* habla 1..* nombre
nombre
dirección núm-parlantes
Caso de uso: Añadir-Persona-1 Caso de uso: Añadir-Persona-2
:Persona :Sistema :Persona :Sistema
AltaPersona(nombre,dirección)
AltaPersona(nombre,dirección)
* HablaIdioma(nombre, idioma)
¡No permite añadir nunca una persona!
Nombre: HablaIdioma(nombre,idioma)
Nombre: AltaPersona(nombre,dirección) …
… Precondiciones:
Precondiciones: - existe Idioma con nombre=idioma
Postcondiciones: - no existe la asociación ‘habla’ entre nombre
- creación de un objeto Persona con e idioma
el nombre y la dirección especificados Postcondiciones:
Salida: - creación de una asociación ‘habla’ entre
la Persona con nombre=nombre y el Idioma
Salida:
92
Redundancia - Diagramas de secuencia y contratos
Los diagramas de secuencia definen un orden de invocación de las

operaciones.
Las operaciones no han de incorporar información para garantizar

que este orden se cumpla.
:Cajero :Sistema
Nombre: pago (venta, importePago): cambio
…
inicioVenta(pv): venta
Precondiciones:
- existe Venta “venta”
entrarProd(venta, prod, cant)
* - la Venta “venta” ha finalizado
finVenta(venta): importe Postcondiciones:

... son redundantes
pago(venta, importePago): cambio Salida:

Bibliografía
• 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 1
Modelo de los estados en UML
• Introducción
• Uso de los diagramas de estado
• Ejemplos
• Acciones y condiciones de una transición
• Estados imbricados
• Bibliografía
94
Modelo
de análisis


del dominio
operaciones
del sistema

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:
• condición de un objeto o de un caso de uso en un momento del
tiempo
– Transición:
• 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

interacción) durante su vida en repuesta a los estímulos recibidos, junto con sus respuestas.
Nombre super estado
Nombre Estado
Variable: tipo=valor inicial

Ev.(argumentos)[condición@/acción
Entry/acción Nombre Estado
do/actividad
exit/acción
event/acción

Cambio de estado civil de una persona
Persona
nacimiento
estado- {disjoint, complete}
civil
Soltera
Soltera Casada Separada Divorciada Viuda
boda
divorcio Casada
Divorciada boda boda
divorcio separación enviudar
Separada 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
explícitamente en el esquema conceptual
• para describir clases de objetos con importante “comportamiento
dinámico”
– 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
entrarProd
inicioVenta Introduciendo
Esperando Esperando
productos
venta producto
finVenta
Esperando
pagoEnMetálico pago
Autorizando
tratarRespTarjeta pago PagTarjetaCrédito
97
Diagrama de estados de un teléfono
estado inicial
estado
descolgar
libre activo
colgar
transición evento

Acciones y condiciones de una transición
condición
descolgar [abonadoVálido]
libre activo
/marcarTono
colgar
acción
98
Estados imbricados
descolgar [abonadoVálido]
/marcarTono Activo
Emetiendo Tono
Charlando
Marcar
libre
dígito conectado
dígito Marcando Conectando

colgar completo

Bibliografía
• Larman, C.
Prentice-Hall, 2002.

• Powel Douglass, B.
Real-Time UML.
99

Proceso unificado de desarrollo de software 1
El proceso unificado de desarrollo de software
• Etapas del proceso iterativo de desarrollo del software

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

construir prototipos...
2. Construir - Desarrollo del sistema (especificación, diseño, etc.)
3. Implantar - Implantar el sistema para su uso.
Plan y
Construcción Implantación
elaboración

Etapa de planificación y elaboración

Incluye la concepción inicial del proyecto, detección de problemas, determinación de
objetivos, investigación de alternativas de cambio, planificación y especificación de los
requisitos.
Plan y Construcción Implantación
Elaboración
1. Definir el plan inicial 2. Informe de inv. preliminar 3. Definir requisitos
4. Definir términos 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 investigación preliminar: motivación, alternativas, necesidades de negocio.
• Especificación de requisitos: descripción declarativa de los requisitos
• Glosario: diccionario de términos (conceptos, nombres) y cualquier información asociada
102
Etapa de construcción
Plan y Construcción Implantación

Elaboración
Ciclo de Ciclo de
desarrollo 1 desarrollo 2 ...
Refinar Sincr. Análisis Diseño Construcción Prueba

plan artefactos
Ventajas:
• La complejidad nunca sobrepasa al diseñador.
• Primeras impresiones muy rápidamente, porque la implementación
de una pequeña parte del sistema se hace muy rápidamente.

Etapa de construcción: Ciclos de desarrollo (I)
La etapa de construcción incluye diversos ciclos de desarrollo en los cuales el

sistema se va extendiendo de forma progresiva.
Ciclo de desarrollo 1 Ciclo de desarrollo 2 ...
Refinar plan Sincr. artefactos Análisis Diseño Construcción Prueba
1. Definición de los casos 2. Refinar los 3. Refinar el modelo

de uso esenciales diagramas conceptual
4. Refinar el 5. Definir diagramas 6. Definir contratos

glosario de secuencia de operación
7. Definir diagramas
de estado
103
Etapa de construcción: Ciclos de desarrollo (II)
Ciclo de desarrollo 1 Ciclo de desarrollo 2 ...
Refinar plan Sincr. artefactos Análisis Diseño Construcción Prueba
1. Definición de los casos 2. Definir informes e 3. Refinar la arquitectura

de uso reales interfaces de usuario del sistema
4. Definir los diagramas 5. Definir el diagrama de 6. Definir el esquema de la

de interacción clases de diseño base de datos

Ordenar y priorizar casos de uso
Ciclo de Ciclo de Ciclo de

desarrollo desarrollo desarrollo
Caso de uso A Caso de uso A Caso de uso B

Versión Versión ...
Simplificada Completa ...
... ... ...
... ...
¿Cómo priorizar? Caso de uso C

a. Incluyen funciones arriesgadas, críticas o complejas. ...
b. Involucra tecnología nueva o arriesgada. ...
...
c. Representan procesos primordiales para el negocio.
d. Impacto significativo en el diseño (añade muchas clases
al dominio o requiere muchos servicios).
e. Permite obtener información significativa respecto al
diseño con poco esfuerzo.
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 habría de ser suficientemente genérico 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
inicioVenta(pv): venta
Interacción común a
todo tipo de pago * entrarProd(venta,prod,cant)
Interacción específica del pago en metálico
:Cajero :Sistema
:cambio
105
Interacción específica del pago con tarjeta
:Gestión Tarjetas :Cajero :Sistema :Sist. Autor. Crédito

pagTarjCrédito(núm-t,fecha-cad) solicitudAprov(núm-t)
tratarRespTarj(respuesta)
añadixAprovación(respuesta)
Nombre: pagTarjCrédito (núm-t, fecha-cad) Nombre: tratarRespTarj (respuesta)

Responsabilidades: pagar con la tarjeta de crédito Responsabilidades:
Excepciones: responder a la respuesta de aprovación recibida
Precondiciones: Excepciones:
Postcondiciones: Precondiciones:
- Creación de un nuevo PagoConTarjeta pct Postcondiciones:
- Nueva asociación entre pct y la venta actual - ...
- ... Salida:
Salida: - Se envía una aprovación al sistema de Gestión
- Se envía una solicitud de aprovación al de Tarjetas para que la registre
servicio de autorización de crédito

Bibliografía
• 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

Especificación de sistemas software en UML
Colección de ejercicios
1 Conceptos básicos
1. Da y justifica una definición de ingeniería del software.
2. El ciclo de vida denominado modelo espiral está basado en cuatro actividades: planificación,
análisis de riesgos, ingeniería y evaluación. Comenta brevemente el objetivo de cada una de estas
actividades y cómo se encadenan.
3. Da una definición de requisito de un sistema y de especificación de requisitos de un sistema.

109
4. Indica la diferencia entre requisitos de un sistema y requisitos del software.
5. Resume las cuatro estrategias para determinar los requisitos.
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 cuándo
se puede decir que una especificación determinada cumple esta propiedad. Pon un ejemplo de un
fragmento cualquiera de una especificación que sea verificable y otro que no lo sea.
9. Mucha gente argumenta que el término “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é relación existe (si es que la hay) entre la construcción de prototipos y el modelo de
desarrollo de software en espiral.
11. Indica los tres tipos de mantenimiento de software que hay y explícalos 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 (también denominado

ciclo de vida). Di el nombre de dos paradigmas que conozcas.
14. Di cuáles son las ventajas e inconvenientes principales, si los hay, del ciclo de vida basado en el
prototipaje en relación al ciclo de vida clásico.
15. Haz el modelo conceptual de datos con notación UML de un sistema que gestione un conjunto
de escaleras mecánicas de una gran superficie comercial. Cada escalera se identifica por un código. En
un momento determinado, una escalera puede estar en funcionamiento o en reparación.
Independientemente de esto, una escalera puede estar subiendo, bajando o parada, pero si está en
reparación está, necesariamente, parada.
Si una escalera está en reparación, el sistema guarda cuál era el estado (subiendo, bajando, parada)
que tenía la escalera en el momento de pasar a reparación.
16. Considera un modelo conceptual de datos, especificado con notación UML, de los datos de un
sistema que contiene sólo una relación 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 cómo se deberían
expresar en este modelo las restricciones siguientes:
1. Ningún c puede participar en más de 10 ocurrencias de R.
2. Una pareja a,b cualquiera puede estar relacionada, vía R, con un máximo de 3 ocurrencias de C.
3. Un trío a,b,c cualquiera puede estar relacionado, vía R, como máximo una vez.
110
17. Considera un modelo conceptual de datos, especificado con notación UML, de los datos de un
sistema que contiene sólo una relación 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 cómo se deberían
expresar en este modelo las restricciones siguientes:
1. Todos los c han de participar como mínimo en dos ocurrencias de R.
2. Una pareja a,b cualquiera ha de estar relacionada, vía R, con un mínimo de 3 ocurrencias de C.
3. Una ocurrencia c cualquiera ha de estar relacionada como máximo con tres ocurrencias distintas de B.
4. Un trío a,b,c cualquiera puede estar relacionado, vía R, como máximo una vez, y como mínimo
ninguna.
18. Explica brevemente las diferencias existentes entre los dos modelos conceptuales de datos
siguientes por lo que respecta a la información que puede guardarse en r. Ilustra las explicaciones
mediante instanciaciones de los modelos.
r
A r 0..2 B A * 0..2 B
*
x y x 0..1 y
C C
z z
- Restricciones de clave: A --> x, - Restricciones de clave: A --> x,
B --> y B --> y
- x, y y z son atributos univaluados - x, y y z son atributos univaluados
M1 M2
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 notación UML:
a) b)
participa-en
Informático ProyectoSw Informático ProyectoSw
asignar
asignada
Etapa Participación Etapa
Indica cómo se deberían expresar en cada uno de estos modelos a) y b) las restricciones siguientes:
r1- Un informático está en, como mínimo, tres proyectos.
r2- Un proyecto tiene, como máximo, cuatro informáticos para una determinada etapa.
r3- Un informático no puede estar dos veces en la misma etapa para un determinado
proyecto.
21. Dado el modelo conceptual de la figura siguiente, di cuál de las cinco afirmaciones dadas es la 111
correcta.
Persona
habitante 1..* propietario
*
{subset} posee
vive
vivienda * * propiedad
Piso
(a) No puede ser que una persona posea un piso y viva en otro.
(b) Una persona puede vivir sólo 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.
Sesión reserva Asiento

nombre fila, butaca
día, hora * * precio
Claves: Sesión -> (nombre, día, hora)

Aiento -> (fila, butaca)
22. Explica la utilidad de los diagramas de estado de los casos de uso.
23. Dados el curso típico de eventos y el modelo conceptual siguientes, construye el(los)
diagrama(s) de secuencia correspondiente(s):
Caso de uso: Reserva de asientos para una sesión de una obra

Actores: Cliente (iniciador), Empleado
Curso típico de eventos:

1. El caso de uso se inicia cuando el cliente se
dirige al empleado para reservar asientos para
una sesión de una obra.
2. El empleado introduce los datos de la sesión
(nombre, día y hora).
3. El sistema comprueba la existencia de aquella
sesión y proporciona información de todos sus
asientos libres (fila, butaca y precio de cada
asiento).
4. El empleado comunica al cliente la
información 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
112 disponibilidad y registra la reserva.
8. El cliente se va contento -.
24. Justifica por qué los casos de uso correspondientes a la etapa de especificación se clasifican
siempre como esenciales (en el apartado tipo de la especificación del caso de uso).
25. Modelo del comportamiento en UML:

a) ¿Es posible en UML que la especificación del contrato de una operación no tenga ni precondición
ni postcondición, pero en cambio sí que tenga salida?
b) ¿Es posible en UML que la especificación del contrato de una operación no tenga precondición,
pero en cambio sí que tenga postcondición?
En ambos casos, justifica brevemente tu respuesta y, si lo crees conveniente, ilústrala 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 transición 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 especificación siguientes: diagrama de casos de uso, especificación de
los casos de uso, esquema conceptual y diagramas de secuencia. Di cuáles de ellos es imprescindible
consultar para poder hacer los contratos de las operaciones. Justifica brevemente la respuesta.
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 precondición de los contratos sobran (si las
hay) y, si es el caso, di cuáles faltan. En caso que sobren partes de las precondiciones, indica para
cada una si es redundante o no.
Restricciones textuales:
Libro tiene Ejemplar
- ISBN es clave de Libro
ISBN núm
1 3..* estado - un libro no puede tener dos
autor
ejemplares con el mismo núm
obtenerLibro(x): l
borraEjemplar(l, n)
obtenerLibro(x): l borraEjemplar(l, n)
pre (1) Libro l con ISBN = x pre (2) l.ISBN = x
(3) el libro l tiene al menos 4 ejemplares
post --- (4) Ejemplar e con núm = n
(5) e.estado = defectuoso 113
sal l post borrar la instancia (l, e) de la asociación tiene;
borrar
e
30. ¿Cuáles son las ventajas y los inconvenientes principales, si los hay, del proceso unificado de
desarrollo de software de UML en relación al ciclo de vida clásico?
31. ¿Cuáles son las ventajas y los inconvenientes principales, si los hay, del ciclo de vida basado en
el “desarrollo incremental e iterativo” de UML en relación al ciclo de vida clásico, en cascada?
32. Enumera criterios de priorización de los casos de uso para la etapa de construcción del proceso
unificado de desarrollo de software.
2 Modelo conceptual de datos en UML

1. Haz el modelo conceptual de datos con notación UML de un sistema que contiene el horario y
las asignaturas de la Facultad, de una sola ingeniería.
Una asignatura tiene un código, un nombre y un cierto número de créditos (no distinguiremos entre
teoría, 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/co-
requisitos y co-requisitos.
115
El horario indica para cada grupo de una asignatura (por ejemplo, Ingeniería del software grupo 10)
qué días 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 número de horas de clase (no hace falta distinguir
entre horas de teoría, problemas y laboratorios, ni tener en cuenta el concepto de subgrupo).
Expresa gráficamente todas las restricciones que puedas. Las restricciones que no se puedan expresar gráficamente
y las reglas de derivación de los atributos derivados, si los hay, especifícalos con el lenguaje OCL.
2. Haz el modelo conceptual de datos con notación UML de una empresa de transportes que
contiene información relativa a rutas, carreteras y poblaciones.
La empresa cubre un ámbito geográfico comprendido por unas 1000 poblaciones. Cada población tiene un
código y un nombre. Estas poblaciones están unidas por unas 50 carreteras. Cada carretera tiene un código.
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 kilómetros entre ellas. También
se considera la duración del trayecto, en minutos, entre estas dos poblaciones, que, en caso general, puede
ser diferente según sea un sentido o el otro. Por una misma población pueden pasar diversas carreteras. Un
ejemplo con 9 poblaciones, 3 carreteras y 10 tramos podría ser:
El trayecto que ha de recorrer un camión de la empresa es una ruta. Hay unas 30 rutas, cada una de las
cuales tiene un código. Una ruta parte y acaba en una misma población, y consta de una serie de
tramos consecutivos de la misma o diferentes carreteras, que se han de recorrer en una cierta
dirección. Por ejemplo, la ruta 10 podría 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 F
com12
loc1
A B C E
I
D
H
G
3. Considera una empresa que se dedica a la fabricación de aparatos electromecánicos y está

interesada en construir un sistema que incluya, entre otras cosas, información sobre la composición de
los aparatos. Cada aparato consta de una o más unidades de uno o más 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 sólo uno) proveedor, y no es fabricada por la empresa.
Tanto los aparatos como las materias primas tienen un código identificador de tipo string(5) y un
nombre de tipo string(50).
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
116 (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 fabricación 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 fabricación 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 sólo 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 restricción indicada.
Haz el modelo conceptual de datos de este sistema con notación UML. Expresa gráficamente todas las
restricciones que puedas. Las restricciones que no se puedan expresar gráficamente y las reglas de
derivación de los atributos derivados, si los hay, especifícalos con el lenguaje OCL. Has de indicar
también, necesariamente, la instanciación del modelo con los datos del ejemplo que se ha dado. Si al
hacer este ejercicio necesitas más información, haz las suposiciones que creas más adecuadas e
indícalas bien claramente.
4. Considera un comité organizador de un congreso que está interesado en construir un sistema que
incluya, entre otras cosas, información sobre las ponencias que se presentarán. Cada ponencia tiene un
código y un título y está escrita por uno o más autores. Una vez recibidas, cada ponencia se envía a
uno o más revisores. Los revisores no pueden ser autores de ninguna ponencia. Al cabo de un tiempo, los
revisores envían sus informes de cada ponencia que han de revisar. A veces, un revisor no envía ninguno
de los informes, o no envía alguno de los que tenía que hacer. De todas maneras, siempre se tiene al
menos un informe de cada ponencia. Cada informe, cuando se recibe, da una puntuación (de 0 a 10) de la
ponencia y clasifica la ponencia en una de las sesiones que habrá en el congreso. Cada sesión
corresponde a uno de los días del congreso, con una hora inicial y una hora final.
Por ejemplo, la ponencia 10, de título ‘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 sesión ‘Análisis Estructurada Moderna’. El segundo
le da un 8 y la clasifica en la sesión ‘Nuevos métodos de especificación’. El tercero se olvidó de enviar el informe.
La ponencia 23, de título ‘La importancia de los eventos’, está escrita por los autores A2 y A5 y se envía al revisor
Rb, que no contesta, y al Rd, que la califica con un 3 y la clasifica en la sesión ‘Nuevos métodos de especificación’.
De cada autor o revisor, el sistema tiene un código identificador, su nombre y su dirección.
En una cierta fecha, el comité se reúne y, partiendo de los informes, decide qué ponencias acepta y
cuáles rechaza. Las ponencias aceptadas se asignan a una sesión, 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 sesión ‘Análisis estructurada moderna’. La sesión
‘Análisis estructurada moderna’ se hará el día 29/04/03, de 11 a 13. La ponencia 23 se rechaza por el motivo 117
“demasiado larga”.
Haz el modelo conceptual de datos de este sistema con la notación UML. Expresa gráficamente todas
las restricciones que puedas. Las restricciones que no se puedan expresar gráficamente y las reglas de
indícalas claramente.
5. Considera el caso de una federación 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 periódicamente. Una serie se identifica por un
nombre y una edición por la serie y el año. Una edición consta de un conjunto de etapas, que varían de
una edición a otra. Cada etapa tiene un número de etapa, una longitud, una población de inicio y una
población final.
Por ejemplo, de la serie “Volta a Catalunya” se han hecho tres ediciones. La tercera edición tenía 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 tenía cinco
etapas. La primera de éstas iba de París a Lión, etc.
Interesa también que el sistema registre los ciclistas y su participación 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 posición (clasificación) y si no la acaba es por un cierto
motivo, e interesa saber en qué etapa corrió por última vez. También se debe guardar el resultado de
los ciclistas en cada etapa. Como es obvio, un ciclista sólo 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 edición 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 Montaña en la meta. Para estas etapas, se debe registrar cuál de los
ciclistas que participó ganó el premio.
Por ejemplo, la etapa Barcelona-Montserrat de la carrera que estamos considerando tenía este premio (la otra, no).
El premio lo ganó C2, que, naturalmente, había participado en la etapa.
118 6. Considera una empresa que está interesada en construir un sistema que incluya, entre otras cosas,
información sobre sus empleados. Cada empleado tiene un número de documento de identidad, un
nombre y una dirección. Los empleados están asignados a un, y sólo uno, departamento. Cada
departamento tiene un nombre. Los departamentos están estructurados jerárquicamente, y cada
departamento puede depender como máximo de otro departamento. Cada departamento tiene un único
director, que ha de ser uno de los empleados que le están asignados.
Por ejemplo, Juan, María, Rosa, Alberto y Jorge son empleados de la empresa. Juan trabaja en el departamento de
Ventas, María en el Servicio Técnico Postventa, Rosa en el Laboratorio, y Alberto y Jorge en Recepción. Ventas
depende de Dirección Comercial que, a su vez, depende de Dirección General. El Servicio Técnico Postventa
depende de Ventas, etc. La directora del Laboratorio es Rosa. El director de Recepción es Jordi.
Cada empleado es de una sola categoría determinada. Sólo hay tres categorías: Vendedor, Técnico
y Administrativo. De cada categoría se han de guardar los días de vacaciones y el plus del sueldo
que tienen.
Por ejemplo, la categoría Vendedor tiene 30 días de vacaciones y un plus de 60 euros. La categoría Administrativo
tiene 20 días de vacaciones y 120 euros de plus. Juan es vendedor, María y Rosa son técnicos y Alberto es
administrativo.
Para los empleados que son vendedores se ha de registrar la zona donde trabajan. Una zona tiene
un código y un nombre. Un vendedor sólo trabaja en una zona. Para los empleados que son
técnicos se han de registrar los estudios que tienen. Cada estudio tiene un código, un nombre y el
Centro donde se imparte. Un mismo técnico puede tener diversos estudios. Para los empleados que
son administrativos se han de registrar los cursos de perfeccionamiento que han hecho. Cada curso
tiene también un código, un título y una fecha de realización. Un mismo administrativo puede
haber hecho diversos cursos.
Por ejemplo, Juan trabaja en la zona de Gerona. María tiene los estudios de ingeniería en informática, y Rosa los de
elecrónica y los de mecánica. Alberto ha hecho dos cursos de perfeccionamiento: mecanografía y archivo.
7. Considera el caso de un aficionado a la música rock que quiere construir un sistema que gestione
información sobre su fonoteca. El sistema ha de permitir guardar y consultar datos sobre los discos
(compactos, elepés o cassettes) y sus intérpretes.
Los discos son editados por casas discográficas. Cada casa discográfica se identifica por un nombre, y
cada disco se identifica por un código alfanumérico y también tiene un nombre. Los discos se
estructuran en secuencias de cortes. Un corte es una grabación continuada, normalmente de una única
canción, y se identifica mediante un código alfanumérico.
También tienen un nombre y una fecha de grabación. En un disco compacto hay una sola secuencia de
cortes y cada corte aparece en una cierta posición de la secuencia. En un LP o un cassette hay una
secuencia de cortes por cada cara y cada corte aparece en una posición de una cara. Un mismo corte 119
puede aparecer en diversos discos (por ejemplo, en el disco original y en una recopilación) pero no
puede aparecer más de una vez en el mismo disco.
Por ejemplo, la casa discográfica Zafiro ha editado el disco compacto D1 y el disco LP D2. D1 tiene la canción C1
como primer corte y la canción C2 como segundo corte. El disco D2 tiene la canción C1 como primer corte de la
primera cara, y la canción C3 como primer corte de la segunda cara, y no tiene más cortes.
También se quiere tener información sobre los intérpretes de cada corte. Un intérprete se identifica
mediante un código alfanumérico; tiene un nombre, un año de nacimiento y, si ya está muerto, un año
de defunción. Un intérprete puede participar en la grabación de un corte interpretando diversos
papeles (vocal, guitarra solista, piano, batería, etc.), pero un instrumento determinado de un corte sólo
lo puede tocar un intérprete. Desgraciadamente, a veces se desconocen los intérpretes de un corte, o
los instrumentos que han tocado.
Por ejemplo, el intérprete I1 nació el año 1930 y todavía vive. I2 nació el 1920 y murió el 1965. Ambos
participaban en la grabación de C1: I1 como vocalista y piano, e I2 como batería.
8. Considera el caso de una compañía ferroviaria que quiere construir un sistema que mantenga los
horarios previstos de sus trenes y los horarios reales.
Cada línea de tren tiene un código que la identifica, un tipo de tren, una estación de origen y una hora de
salida (prevista). Supondremos que cada línea de tren circula diariamente. Cada línea consta de una serie
de tramos, que van de una estación a otra. Las estaciones se identifican por un código. Como mínimo hay
un tramo, que sale de la estación origen de la línea. Para cada tramo de una línea, nos interesará mantener
la hora de salida prevista de la estación origen y la hora de llegada prevista a la estación destino.
Podemos suponer que la hora de llegada y la de salida de una estación son del mismo día.
Por ejemplo, la línea R12 sale de Manresa, cada día 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 línea C240 sale de Barcelona, cada día 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 día, el jefe de la estación origen de una línea 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 información al público y estadísticos. Supondremos que, si los trenes salen de la
estación origen, acaban llegando a la estación final.
120 Por ejemplo, el día 26/04/03 el tren de la línea R12 salió de Manresa a las 10:01. En cambio, el día 27/04/03 este
tren no pudo salir por ‘Tormenta’.
En cada estación que para un tren, el jefe de estación correspondiente registra la hora real de llegada
y, si no es la estación final, la hora real de salida, y también se lo comunica inmediatamente al sistema.
Como es natural, los trenes sólo paran en las estaciones en que está previsto que paren.
Por ejemplo, el tren de la línea R12 del día 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 anomalía en un tramo, registra el tramo correspondiente

(que será un tramo de la línea), la hora de observación y la anomalía detectada. Estas observaciones se
comunican al sistema al llegar el tren a la estación final.
Por ejemplo, en el tramo de Tarrasa a Barcelona, el maquinista del tren de la línea R12, del día 26/04/03, observó
que ‘Hay un corte de corriente’ a las 10:23.
9. Considera una compañía 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 compañía
identifica los coches por su matrícula, y necesita registrar su marca y su modelo, entre otros datos. Las
personas se identifican por su documento de identidad, registrándose también otros datos como su
nombre y su dirección. No es imposible que un coche tenga dos siniestros, con el mismo o diferente
conductor, pero sería en días diferentes.
Por ejemplo, el coche 10 (marca Renault, modelo R6) tuvo un siniestro el día 10/10/02, cuando lo conducía Juan.
Algunos siniestros requieren que el coche accidentado se lleve a un (o más) taller(es) para su
reparación. La compañía tiene “fichados” los talleres posibles, con un código identificador, su nombre
comercial, dirección, etc. No todos los siniestros acaban con el coche en un taller. La compañía indica
a qué talleres se ha de llevar el coche y los días en que se ha de llevar. El sistema ha de anotar dónde
se asignan los coches.
Por ejemplo, como consecuencia del siniestro anterior, había que llevar el coche a dos talleres. Primero, el día
15/10/02, a “El Mecánico”, y después, 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 número de horas de mano de obra. Por otro lado, la reparación puede exigir (aunque no
siempre) el uso de unas ciertas cantidades de materiales determinados. La compañía tiene codificados
estos materiales, y para cada uno de ellos tiene también su nombre y su precio unitario. Cuando un
taller acaba una reparación, lo comunica a la compañía, indicando los datos mencionados, que el
sistema ha de registrar. 121
Por ejemplo, la reparación 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 código ABC y está a 6
euros el litro, etc.
De vez en cuando, los talleres facturan a la compañía de seguros las reparaciones que han
hecho. Una factura puede incluir diversas reparaciones, pero una reparación sólo puede estar
incluida en una factura (las reparaciones no se facturan parcialmente). De cada factura se
guarda su número y la fecha de la factura. El sistema ha de poder saber, de una forma u otra,
el código del taller emisor de la factura. Una factura no puede incluir reparaciones de dos o
más talleres distintos.
Por ejemplo, el taller “El Pintor de Coches” nombrado emitió la factura nº 100 el día 30/12/02. La factura incluía la
reparación 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 médico y ocurre en una cierta fecha. La mutua identifica sus socios por el número de asociado
y guarda también su nombre y su dirección. Los centros médicos se identifican por su nombre y se
guarda también la información de si el centro tiene firmado un convenio o no con la mutua. Es

imposible que una misma persona tenga dos ingresos en centros médicos en una misma fecha, aunque
sí puede tener diversos ingresos en fechas distintas.
Por ejemplo, la socio número 17 (nombre María, dirección C/Diputación) fue ingresada en el hospital de Santa
María del Mar (que no tiene convenio con la mutua) el día 8/8/2003.
Los ingresos requieren que a la persona ingresada se le administren uno o más medicamentos para
su curación. El sistema guarda información de los posibles medicamentos, que tienen un código
identificador, un nombre y un precio unitario. Todos los ingresos requieren la administración de
algún medicamento, indicándose en cada caso cuál es el nombre diario de unidades a administrar y
la fecha de inicio y la fecha final de administración. Un mismo medicamento se puede administrar
en diversas ocasiones durante un ingreso. El sistema ha de registrar únicamente cuáles 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 día 8/8/2003 hasta el 10/8/2003. El medicamento 5, en una
cantidad de 5 unidades diarias, desde el día 8/8/2003 hasta el 11/8/2003. Finalmente, una segunda
administración del medicamento 3, en una cantidad de 7 unidades diarias, desde el día 12/8/2003 hasta el
14/8/2003.
122
El sistema conoce también los medicamentos que son incompatibles para los socios. Un socio puede
tener más 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 federación 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 información 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 también su dirección y el color de la camiseta. Las jornadas se identifican por
un número 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 (dirección C/Guilleries, color blanco) jugó contra el equipo Voltregá (dirección C/
Osona, color azul) en la jornada 3. El Tordera es un equipo de hockey con dirección C/ Riera y color amarillo.
La federación también quiere guardar información 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 también 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 también cuál es
su posición (puedes suponer que un jugador tiene una única posición: portero, defensa, medio, etc.) y
el nombre del equipo al que pertenece. La federación de hockey sobre patines quiere registrar también
la información de los árbitros que están recusados por los diversos equipos. En una liga los equipos
pueden recusar un máximo de 3 árbitros si consideran que éstos les han perjudicado en ligas
anteriores, guardándose en cada caso el motivo de la recusación.
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 número de minutos. Un
jugador sólo puede participar en partidos en los que juega su equipo. Además, hay que registrar
también la información del número de goles marcados por un jugador en un partido. Un jugador sólo
puede marcar goles en los partidos en los que participa. El sistema conoce también los árbitros que
arbitran los partidos y cuál es la calificación otorgada al árbitro cada vez que pita un partido. Un
árbitro puede arbitrar más 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 préstamos hipotecarios. Los préstamos solicitados se identifican por
un código y se registra también la cantidad de dinero solicitada y el número de años en que se
devolverá el préstamo. Un préstamo está solicitado por una o más personas. Las personas se
identifican por su nombre y se guarda también información de su dirección y edad. Todo préstamo
tiene un único primer titular. El primer titular de un préstamo ha de ser una de las personas que lo
ha solicitado.
Por ejemplo, Juan (dirección C/ Valencia, 25 años) y María (C/ Prat, 24 años) han solicitado el préstamo con
código 111 (por un valor de 180.000 euros, a devolver en 15 años). María es el primer titular de este préstamo.
Carmen (C/ Balmes, 27 años) ha solicitado el préstamo 222 (300.000 euros, 20 años) y es el primer y único titular.
Los préstamos solicitados son asignados a uno o más evaluadores (que se identifican por su nombre y
de los cuales se conoce también su dirección y edad) para que los estudien. Un evaluador no puede
haber solicitado ningún préstamo en aquella entidad bancaria. Al cabo de un tiempo, los evaluadores
envían los informes de los préstamos que les han sido asignados. A veces, un evaluador no envía
alguno de los informes que se le habían asignado. Cada informe, cuando se recibe, dice si el evaluador
aconseja o no la concesión del préstamo. En caso afirmativo, hay que indicar también el tipo de
interés con el cual se debería hacer efectivo el préstamo, y en caso negativo el motivo por el cual no se
debería conceder el préstamo.
Por ejemplo, el préstamo 111 se ha asignado a los evaluadores Jorge, Ana y Rosario. Jorge y Rosario consideran
que hay que conceder el préstamo con un interés del 5,5% y 6%, respectivamente, y Ana no envía el informe
preceptivo. Por otro lado, el préstamo 222 se envía a los revisores Pablo y Ana, que envían 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 préstamo solicitado a partir de
los informes de los evaluadores. A los préstamos concedidos se les asigna un tipo de interés igual
al promedio de los tipos de interés sugeridos por los revisores que habían emitido un informe
positivo. Para los préstamos denegados, hay que registrar el motivo por el cual la entidad bancaria
ha decidido no concederlos. Un préstamo no se puede conceder si tiene un mínimo de dos informes
negativos. Hay que guardar también información de la fecha en que se ha hecho la evaluación del
préstamo. Para los préstamos concedidos, hay que guardar también la información de la cuenta
corriente de la cual se habrá de extraer el dinero (única para cada préstamo, identificada por
número de cuenta) y el día del mes en que se efectuará el traspaso del dinero de la cuenta a la
entidad bancaria.
124 Por ejemplo, el préstamo 111 ha sido condedido el día 5/4/03 con un interés del 5,75%. El pago de este préstamo se
hará a partir de la cuenta C567, el día 4 de cada mes. El préstamo 222 ha sido denegado el día 7/4/03 porque lo
había solicitado una única persona.
13. Considera el caso de una compañía 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 también su autor, su director y el número de
actores que intervienen. Las obras de teatro se representan en diversas sesiones (cada una de las cuales
se identifica por el día y por el orden dentro del día) y en un determinado teatro. Hay que guardar
también la información de la hora de inicio de la representación.
Los teatros se identifican por su nombre y se registra también su aforo (número total de butacas
de que dispone) y la ciudad donde se encuentran. En un mismo día 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 día. En una determinada representación 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 sesión del 26/4/03 se representará en el
teatro Monumental la obra “El visitante”. Esta representación comenzará a las 21 horas.
Cada teatro tiene un cierto número de butacas, cada una de las cuales se identifica (para un teatro
determinado) por el número de la fila y el número de asiento en la fila. El sistema ha de guardar
también la información de las entradas que se han vendido para una determinada representación. Las
entradas se pueden vender de dos maneras distintas: directamente en ventanilla o bien por teléfono.
Para las entradas vendidas directamente en ventanilla hay que registrar la representación para la cual
se ha vendido la entrada y la butaca asignada.
En el caso de entradas vendidas por teléfono hay que registrar la misma información que para el caso
de entradas vendidas en ventanilla y, además, el número de documento de identidad de la persona que
ha comprado la entrada y el número de tarjeta de crédito a la que hay que hacer el cargo de la venta.
En una representación no se pueden vender entradas para las que se asigne una butaca que no exista
en el teatro donde se hace la representación.
Por ejemplo, se han vendido tres entradas de la representación anterior: dos a ventanilla y una por teléfono. Las
entradas vendidas a ventanilla ocupan las butacas (1,18) y (1,20), donde 1 corresponde al número de fila y 18 y 20
al número de asiento en la fila. La entrada vendida por teléfono 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 crédito 333.
El sistema ha de almacenar también información de las personas que están abonadas a la compañía.
Un abonado se identifica por su documento de identidad y se registra también su nombre y su
dirección. Sólo pueden comprar entradas por teléfono las personas que están abonadas a la compañía
propietaria del teatro. 125
Por ejemplo, Juan está abonado a la compañía, tiene el documento de identidad 111 y vive en la C/ Matadero.
14. Considera una federación de entidades excursionistas que está interesada en un sistema para el
control de las expediciones efectuadas para los centros excursionistas adscritos a la federación. Una
expedición la efectúa un centro excursionista a una cierta montaña, con una fecha de inicio y una de
finalización. La federación identifica los centros excursionistas por su nombre y registra también su
dirección. Las montañas se identifican por su nombre y se registra también su altitud. Un centro
excursionista puede efectuar diversas expediciones a la misma montaña, en fechas diferentes. A una
montaña se pueden hacer diversas expediciones, pero en una fecha concreta sólo puede haber un
máximo de 5 expediciones.
Por ejemplo, el centro excursionista CEC (dirección Gran Vía) efectuó una expedición al Everest (altitud 8848 m.)
del día 5/5/2003 al 20/7/2003.
En una expedición participan diversas personas (como mínimo una). Una persona puede participar en
más de una expedición. El sistema guarda información de todas las personas (que tienen el dni como
identificador, un nombre y una edad) que han participado en alguna expedición. Alguno de los
componentes de una expedición puede alcanzar la cima. En este caso, se registrará este hecho y
también la fecha en que se ha alcanzado la cima. Una persona puede alcanzar la cima más de una vez
en una misma expedición.
Por ejemplo, las personas con DNI 111 (nombre Juan, edad 25 años), 222 (María, 23), 333 (Pedro, 24) y 444 (Ana,
22) participaron en la expedición anterior. Las personas 111 y 222 alcanzaron la cima el día 24/6/2003. Además, la
persona 222 volvió a llegar a la cima el día 30/6/2003.
Cuando una persona participa en una expedición juega un determinado papel. Para simplificar,
supondremos que los posibles papeles son: médico, alpinista, encargado de material y jefe de
expedición. En una expedición un papel puede ser interpretado por más de una persona. Una misma
persona puede interpretar más de un papel en una expedición. No todos los papeles tienen por qué
interpretarse en una expedición.
Cuando una persona hace de alpinista en una expedición, el sistema ha de registrar también el seguro
médico (que tiene un nombre de seguro identificador y el nombre de la mutua que la cubre) contratada
para la ocasión. En el caso de que una persona de una expedición haga de médico, hay que registrar
también el nombre del centro médico en el que trabaja actualmente (que supondremos que es único).
Por ejemplo, las cuatro personas eran alpinistas en la expedición anterior y tenían un seguro de nombre “Accidentes
en el Himalaya” (cubierta por la Mutua de Tarrasa). La persona 222 era el médico de la expedición y trabajaba en el
Hospital del Mar. La persona 444 era el jefe de la expedición.
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 sólo la
información 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 también su dirección y edad. Las jornadas se
identifican por un número 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 (dirección C/ Guilleries, 27 años) jugó contra José (C/ Osona, 25 años) en la jornada 3.
El club de tenis quiere guardar también información de los jueces principales que arbitran los partidos
disputados. Los jueces, como los socios, se identifican por su nombre y se registra también su
dirección y edad. No puede ser que alguien sea socio del club de tenis y juez de la competición a la
vez. El club de tenis quiere registrar también la información de los jueces que han sido recusados por
los socios.
En un torneo los socios pueden recusar hasta un máximo de 5 jueces si consideran que éstos les han
perjudicado en torneos anteriores, registrándose para cada caso el motivo de la recusación. El
sistema conoce también los jueces que arbitran los partidos y cuál es la calificación otorgada al
juez cada vez que arbitra un partido. Un juez puede arbitrar más 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 años y es juez. María vive en C/ del Mar, tiene 29 años y es juez.
Juan ha recusado a Oriol porque el año pasado le hizo perder un partido. El partido entre Juan y José fue arbitrado
por María, 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 también información 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 también 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.
hacer este ejercicio necesitas más información, haz las suposiciones que creas más adecuadas e 127
16. Considera el caso de una biblioteca que está interesada en el control de los préstamos y de las
reservas que efectúan sus usuarios. La biblioteca dispone de un amplio fondo bibliográfico de
libros y de un gran número de ejemplares de cada libro. Los libros se identifican por su título (esto
lo hacemos para simplificar) y se registra también su autor y el nombre de la editorial. Los
ejemplares de un libro se identifican por un número 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 préstamos como reservas. Un usuario
se identifica por un número de usuario y el sistema guarda también información de su nombre y
dirección. Una reserva la hace un usuario, para un libro determinado, con una fecha de recogida de la
reserva y se indica también el número de días reservados. Un préstamo la hace un usuario, para un
ejemplar de libro determinado, en una cierta fecha y se indica también la fecha límite en que el usuario
puede devolver el ejemplar que se lleva prestado.
Un usuario puede hacer como máximo 3 reservas para una misma fecha. Un usuario puede hacer un
único préstamo de un mismo ejemplar en un mismo día. Un mismo ejemplar de un libro en un cierto
día se puede prestar a como máximo una única persona. No se puede hacer una reserva de un libro si
no queda ningún 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 préstamo o
bien si hacer efectivo este préstamo afecta la disponibilidad de las reservas ya hechas.
Por ejemplo, el socio número 22 (de nombre Bernardo y dirección C/ Cristina) ha hecho dos préstamos distintos del
ejemplar 3 del libro El Atlas furtivo. El primero de estos préstamos lo hizo el día 1/9/02 con fecha máxima de
devolución el 15/9/02. El segundo lo hizo el día 20/1/03 con fecha máxima de devolución 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 días.
Los préstamos que se han hecho se devuelven en una cierta fecha. El sistema ha de registrar qué
préstamos se han devuelto y la fecha en que se hizo efectiva la devolución. Las reservas que se hacen
se pueden recoger en la fecha que se había indicado al hacer la reserva. El sistema ha de registrar el
ejemplar del libro que se ha asignado a la reserva. Una reserva sólo se puede recoger en la fecha de
recogida que se había indicado inicialmente (es decir, ni antes ni después).
Por ejemplo, el primero de los préstamos que había hecho el socio 22 fue devuelto el día 14/9/02. La reserva que
había hecho la socio 33 del libro El Atlas furtivo fue recogida el día 10/2/03 y se le asignó el ejemplar número 5 de
aquel libro.
128 indícalas claramente.
17. Considera el caso de una guardería que está interesada en construir un sistema que incluya, entre
otras cosas, información sobre los niños que tiene a su cargo. Cada niño tiene un nombre, que lo
identifica, una dirección y una fecha de nacimiento. Los niños tienen diversas personas adultas que
son sus responsables y que los pueden recoger en la escuela. De cada adulto que es responsable de
algún niño, la guardería quiere conocer su nombre (que lo identifica), su número de teléfono y el tipo
de responsabilidad que ejerce respecto al niño (padre, madre, abuelo, abuela, canguro, etc.). Como te
puedes imaginar, hay adultos que son responsables de más de un niño (por ejemplo, de hermanos que
van juntos a la guardería). Cada niño está incluido en la cobertura médica de un adulto, que ha de ser
uno de sus adultos responsables. En este caso es necesario conocer el número de seguridad social (o
póliza médica) del adulto.
Por ejemplo, Alberto, Iris, Judith y Ariadna son niños de la guardería. Alberto tiene tres adultos responsables: su
madre (María), su padre (José) y su abuela (Concepción), y está incluida en la póliza médica de José (número
5643578).
Cada niño está asignado a una (sola) clase. Sólo hay tres clases: Bebés, 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
niño de más de un año sea “bebé”. Para los niños que son bebés hay que registrar la leche que toman (las
leches se identifican por su nombre y se guarda también su composición). Para los bebés y los pulgarcitos
se debe conocer los pañales que usan (que también se identifican por su nombre y se guarda información
también de las posibles contraindicaciones). Un niño puede usar diferentes tipos de pañales.
Por ejemplo, la clase de los Lobos la lleva Dolores y ocupa el aula A1; la de los Bebés 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 pañales Dodot y Ausonia. Iris usa los pañales Dodot.
Para coordinarse entre ellos, los padres de los niños de cada clase organizan una “cadena de
comunicación”, 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 niños son de la misma clase. Además, en la guardería se hacen informes diarios de cada niño
donde se indica: cómo ha dormido la siesta (bien o mal) y cómo ha comido (todo, poco o nada). A
veces puede ocurrir que un día no se haga el informe de algún niño.
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 niños de la clase. El día 1/11/02 Alberto se lo comió todo y durmió bien la siesta. En cambio, el
día 2/11/02 Alberto durmió mal la siesta y no comió nada.
18. Considera un centro de enseñanza que está interesado en un sistema para la gestión de las
preguntas que se hacen en los exámenes 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 también su área. Los 129
cursos se identifican por su nombre y se registra la edad habitual de los alumnos que la cursan. Una
asignatura puede impartirse en más de un curso. El sistema registra los créditos 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 máximo 5 exámenes por asignatura y curso en el que la asignatura se
imparte.
Por ejemplo, la asignatura Biología (área Ciencias) se imparte en ESO-1 (edad 12) como opcional y con 6 créditos.
Se hizo un examen de Biología en el curso ESO-1 el día 24/3/2003.
El sistema gestiona información de preguntas que se han puesto en algún examen o que pueden
ponerse en algún examen futuro. Las preguntas se identifican por un número y se registra también su
texto, su tipo (teórica, práctica, test), su asignatura y el profesor que es su autor. Los profesores se
identifican por su nombre y se registra también su teléfono.
Por ejemplo, la pregunta número 1 (texto “Explicad los descubrimientos de Mendel”, tipo teórica) es de Biología y
su autor es Juan (teléfono 935286748). La pregunta 2 (texto “Encontrad el factor Rh que se puede obtener de ...”,
tipo práctica) es de Biología y su autora es Nuria (teléfono 937226432). La pregunta número 3 (texto “Decid qué
...”, tipo test) es también de Biología y su autor es Luis (teléfono 937226432).
Todos los exámenes que se efectúan 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 número 1 (peso 0.4, nota promedio 5),
la número 2 (peso 0.4, nota promedio 7.5) y la número 3 (peso 0.2, nota promedio 3).
Para las preguntas teóricas de un examen, el sistema ha de registrar también la nota mínima y la nota
máxima que se ha obtenido, para las preguntas prácticas el porcentaje de alumnos que han contestado
la pregunta y para las preguntas de test los puntos negativos que tienen las respuestas erróneas.
Por ejemplo, en el examen anterior la pregunta 1 tiene una nota mínima de 1.5 y una máxima de 10, la pregunta 2
tiene un porcentaje de respuestas del 90 por ciento y la pregunta 3 tiene 5 puntos negativos si es errónea.
Haz el modelo conceptual de datos de este sistema con la notación UML. Expresa gráficamente todas las
restricciones que puedas (las otras, si las hay, escríbelas en forma de texto). Has de indicar también
necesariamente la instanciación del modelo con los datos del ejemplo que se ha dado. Si al hacer este
ejercicio necesitas más información, haz las suposiciones que creas más adecuadas e indícalas claramente.
19. Considera que un consorcio de empresas está interesado en informatizar el seguimiento de los
proyectos informáticos 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 informático se inicia en una cierta fecha
y se almacena también la fecha prevista de finalización. Lógicamente, una empresa puede subcontratar
diversas veces a otra empresa para desarrollar proyectos diferentes. Las empresas se identifican por su
código y se registra también su población. 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
informático que comenzaba el 2-2-2002 y se preveía acabar el 5-5-2002. Además, la empresa 111 subcontrató
también la empresa 222 para desarrollar un proyecto del 3-3-2002 al 4-4-2002.
Todo proyecto informático ha de llevar a cabo alguna de las etapas tradicionales del ciclo de vida
de un proyecto software (es decir, especificación, diseño o implementación). Lógicamente, 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 comprendía las etapas de especificación, diseño e
implementación. En cambio, el segundo proyecto consistía sólo en una implementación.
El sistema ha de guardar también la información de los empleados (identificados por nombre y de los
que se registra también su dirección 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 también
que cuando un empleado comienza a trabajar en un proyecto no lo deja nunca). Un empleado sólo
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
María (Calle del Torrente, 20) trabajan en la empresa 222 desde el 2-2-2001. Juan y María participan en el primero
de los proyectos anteriores; Juan desde el 2-2-2002 y María 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 información 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 informático, Juan fue asignado a la etapa de especificación y dedicó
40 horas. En cambio, María fue asignada a la etapa de diseño, dedicando también 40 horas, y a la etapa de
implementación, dedicando 60 horas.
las restricciones que puedas (las otras, si las hay, escríbelas en forma de texto). Has de indicar también
ejercicio necesitas más información, haz las suposiciones que creas más adecuadas e indícalas
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 información de las propiedades y los alquileres
de sus fincas y de los pisos de éstas. Para poder localizar las fincas, se necesita saber la información
de las calles (identificadas por nombre y de las que se registra también su barrio) que forman la
ciudad. Una finca se identifica por un número en una calle. Por tanto, dos fincas de una misma calle
han de tener números diferentes. Toda calle ha de contener alguna finca. Una finca puede estar
dividida en diferentes pisos, que se identifican por el número de piso y número de puerta en la finca.
Por ejemplo, la calle Son Saura (barrio del Puerto) y la calle Mahón (barrio del Centro) son calles de la ciudad. La
calle Son Saura tiene dos fincas, situadas en los número 2 y 26, y la calle Mahón tiene una situada en el número 17.
La finca situada en el número 2 de la calle Son Saura tiene dos pisos (1ª-1ª y 1ª-2ª) y la finca del número 17 de la
calle Mahón tiene dos (1ª-1ª y 1ª-2ª). 131
Las fincas son propiedad de personas (identificadas por nombre y de las que se registra también su dirección).
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. Lógicamente, la suma de los
porcentajes de posesión de una finca no puede superar el 100%. Para simplificar, supondremos que el
porcentaje de posesión de una finca por parte de una persona no varía nunca.
Por ejemplo, la finca situada en el número 2 de la calle Son Saura es propiedad de Juan (C/ Algaiarens) en un 40%
desde el 1-1-2002 y de María (C/ Macarella) en un 60% desde el 2-2-2002. En cambio, la finca de la calle Mahón
es propiedad íntegra de María.
Las personas pueden alquilar pisos de las fincas. Una persona alquila un piso, desde una cierta fecha y
para un número de meses determinado. Una persona puede tener diversos pisos alquilados a la vez.
Dada una fecha de inicio y un número 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 pìso de una finca que posee.
Por ejemplo, Juan ha alquilado el 1º-1ª de la finca del número 17 de la calle Mahón desde el 4-4-2002, para 3
meses. Marta (C/ Macarelleta) ha alquilado el 1º-2ª del número 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 posesión más alto de aquella finca (al que
podríamos denominar propietario principal). Hay que registrar la información del número 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.
Por ejemplo, el alquiler de Marta se facturaba a María 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 también se facturaba a María como
propietaria principal se ingresaba en la cuenta 6789.
las restricciones que puedas (las otras, si las hay, escríbelas en forma de texto). Has de indicar también
ejercicio necesitas más información, haz las suposiciones que creas más adecuadas e indícalas
claramente.
21. Considera el caso de una empresa que está interesada en construir un sistema software que
incluya, entre otras cosas, información sobre sus empleados. Cada empleado tiene un número 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 dirección 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 asignación y, cuando se desasigna, la fecha de deseasignación.
Un empleado se puede asignar como máximo 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 máximo a cinco departamentos diferentes. En un momento
132 determinado, un empleado puede no estar asignado a ningún 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 Mártir, 1-10-02) fue asignado al departamento de Ventas
(C/Córcega, 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/Cerdeña, Darnius) desde el 21-10-2002 al 1-11-2002. La empleada con DNI 222 (María Dulcet, 2-2-
02) está asignada al departamento de Márketing desde el 2-2-2002.
Cuando un empleado está asignado al departamento de Ventas o al de Márketing, el sistema ha de

guardar información adicional. Un empleado puede pertenecer a la vez al departamento de Ventas
y al de Márketing. Para los empleados asignados al departamento de Ventas, hay que registrar los
cargos que ha desempeñado. 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 cuestión.
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 Márketing participan en diversos proyectos. Un

proyecto se identifica por un nombre y tiene una duración 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 número de horas semanales a hacer esta actividad. Un empleado
del departamento de Márketing puede hacer más de una actividad en el proyecto. Una actividad y un
proyecto cualesquiera han de tener como mínimo la participación de un empleado del departamento
de Márketing.
Por ejemplo, mientras el empleado con dni 222 ha estado en el departamento de Márketing, ha participado en el
proyecto “Ara, Lleida” y ha realizado las actividades de “Responsable de Imagen”, dedicándole 20 horas semanales,
y de “Relación con los medios de comunicación”, con una dedicación de 7 horas por semana.
Dada su importancia estratégica, el departamento de Márketing puede rechazar empleados. Un

empleado rechazado por el departamento de Márketing no se puede asignar nunca a este
departamento.
Por ejemplo, el empleado con DNI 111 fue rechazado por el departamento de Márketing 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, escríbelos en
forma textual). Indica los atributos de las clases de objetos y, si es el caso, los atributos de las
asociaciones. Has de indicar también necesariamente la instanciación del modelo con los datos del
ejemplo que se ha dado. Si al hacer este ejercicio necesitas más información, haz las suposiciones que
creas más convenientes e indícalas claramente.
22. Considera una empresa que se dedica a la organización de congresos y que está interesada en un
sistema para la gestión de las ponencias y de los asistentes a los diversos congresos que organiza. Un
congreso tiene unas siglas y un año que lo identifican y es necesario que el sistema registre también el
idioma que se se utiliza en el congreso, la ciudad donde se realiza y el precio de la inscripción. 133
Por ejemplo, el congreso ER del año 2002 tiene: idioma inglés, ciudad Singapur y precio 300 euros. El congreso
ER del año 2003 tiene: idioma inglés, ciudad París y precio 360 euros.
A cada congreso se envían muchas ponencias. A cada ponencia se le asigna un código que la identifica y
también se registra su título y quiénes son sus autores. De cada autor, el sistema ha de tener su nombre,
que se considerará identificador, y también 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 habían enviado para aquel congreso. Es posible que una misma ponencia se presente
a diversos congresos pero entonces puede ser escogida como máximo en uno. De las ponencias
escogidas, el sistema ha de registrar la puntuación que se les ha otorgado.
Por ejemplo, al ER del 2003 se ha presentado la ponencia de código ‘C125’ (título ‘Evolución de jerarquías’) 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 puntuación de 7.
Un congreso se estructura en sesiones. Cada sesión tiene un nombre que indica la temática de la sesión
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 sesión del congreso para el cual se la ha
escogido. A una sesión se pueden asignar como máximo cuatro ponencias.
Por ejemplo, al ER de 2003 hay una sesión que tiene por nombre ‘Modelado conceptual’ y la ponencia ‘C125’ ha
sido asignada a dicha sesión.
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
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 inscripción. Hay
que considerar que una misma persona puede tener inscripciones de tipos diferentes (para congresos
distintos) y también 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 Informática). Al ER de 2002 se ha
inscrito Jorge con inscripción normal y Rosa también con inscripción normal. Otra persona, María (email:
maria@fib.upc.es) se ha inscrito al ER de 2002 con inscripción normal.
Para cada congreso existen algunos hoteles que servirán para alojar a los inscritos en el congreso que
así lo deseen (no obligatoriamente). El sistema ha de registrar cuáles son los hoteles de cada congreso.
Los hoteles se identifican por su nombre. Hay que registrar también 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 número 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 inscripción 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 Haz el modelo conceptual de datos de este sistema con la notación UML. Expresa gráficamente todas
23. Considera el caso de una cadena de tiendas de ropa que está interesada en construir un sistema
software que incluya, entre otras cosas, información sobre sus productos y las tiendas donde se venden.
Cada producto tiene un código (que lo identifica), una descripción, un precio, una fecha de alta y, si
ya no se fabrica, una fecha de baja. De cada producto se diseñan diversas tallas y de cada talla se
fabrican diversas piezas (esta cadena de tiendas no diseña modelos “exclusivos”). Las tallas se identifican
por el número de talla. Los productos pueden ser de tres tipos: infantil, juvenil y adulto. Un producto se
considera de tipo infantil si se ha diseñado por alguna talla entre la 2 y la 12; de tipo juvenil si se ha
diseñado para alguna talla entre la 34 y la 38; y de tipo adulto si se han diseñado tallas superiores a la 38.
Nada impide que un producto sea de más de un tipo (por ejemplo, infantil y juvenil).
Por ejemplo, el producto con código 333 (“forro polar de flores”, 39 euros, 1-9-2003) se diseñó en las tallas
2, 4 y 6. El producto con código 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 código 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 número, que las identifica, y una dirección. El sistema ha de
guardar, para cada producto, la cantidad de piezas de cada talla que están disponibles (a la venta) en
cada tienda.
Por ejemplo, en la tienda número 1 (Rambla Cataluña) 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 número 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 promoción de productos. El sistema ha de registrar la tienda, el

producto promocionado, las fechas de inicio y final de la promoción 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 más de 10 productos en
promoción simultáneamente.
Por ejemplo, en la tienda número 2 se promociona el producto 444 desde el día 28-12-2002 hasta el día 30-1-2003
aplicando un descuento del 50%.
Un par de veces al año la empresa elabora los catálogos de sus productos para promocionarlos en las
temporadas de primavera/verano y otoño/invierno, respectivamente. Se elaboran tres tipos de
catálogos: el infantil, el juvenil y el adulto. El sistema ha de registrar, para cada tipo de catálogo y
temporada, la fecha en que entra en vigor y el conjunto de productos que lo conforman. Como es
natural, en el catálogo infantil sólo 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 catálogo infantil otoño/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 año de nacimiento.
Los viajes se identifican por un número 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).
También hay que registrar qué jubilados de entre los que habían reservado un viaje lo han hecho
finalmente junto con su grado de satisfacción por el transcurso del viaje. Si un viaje no tiene como
mínimo dos personas que lo hagan, el viaje se anula y el sistema no lo registra.
Por ejemplo, Juan (año nacimiento 1930), Carmen (año nacimiento 1933) y Carlos (año nacimiento 1931) son
jubilados del club. Se ha organizado un viaje de número 25 (tipo transporte autobús). 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 satisfacción 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 número del seguro y la mutua aseguradora.
Para el viaje 25, Juan ha contratado un seguro que tiene el número 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 más de una localidad. Un viaje puede parar como máximo dos
veces en la misma localidad y puede hacer un máximo de diez paradas en total. Las localidades se
identifican por el nombre y se quiere saber también su número de habitantes.
El viaje 25 tiene una parada en Figueras (30000 habitantes) que se inicia el día 6-10-2003 y finaliza el día 8-10-
2003. También 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 número
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 día 6-10-2003 en Figueras incluye la visita número 1234 (nombre
‘Museo Dalí’, fecha 7-10-2003). La parada que el viaje 25 inicia el día 8-10-2003 en Castelló de Ampurias incluye
la visita número 1235 (nombre ‘Museo de la Catedral’, fecha 8-10-2003).
Los jubilados que hacen un viaje pueden dar, si quieren, su valoración (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 quién es el ganador y cuál 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 Asociación de Posadas de Cataluña (APC) está interesada en desarrollar un sistema

software para la gestión de los convites que se organizan en sus posadas. Una posada tiene un
nombre (que la identifica), una dirección 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 número
dentro de la posada.
Por ejemplo, la posada “La Cuadra”, situada en la calle Mayor de Maçanet 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 también el nombre, pueden organizar
convites en las posadas de la asociación. Un convite lo organiza una persona, en una posada y para
una fecha determinada e interesa guardar también la información de la fecha en que se ha hecho la
reserva del convite y de su precio. Lógicamente, una persona puede reservar en una misma fecha dos o
más convites en una misma posada, siempre que los convites se hagan en fechas distintas. Por otro
lado, una persona no puede organizar más 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 día 24-6-2003. Ambas reservas las hizo el 1-1-2003. El primer convite
tenía 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 día 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
también el número 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 también qué salas
de la posada se usarán para hacer el convite. Si un convite es del tipo “Menú”, entonces hay que
registrar también las personas que asistirán al convite. No hay que guardar ninguna información
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 “Régimen” de 1
único plato. El convite de Juan en la Cuada para el día 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 asistirán Jorge (de
DNI 333) y Montse (de DNI 444). Montse también asistirá al convite de Ana que también es de tipo “Menú”.
137
Cuando una persona asiste a un convite de tipo “Menú” puede especificar si quiere comida
vegetariana o no. Sólo 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 refinería 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
día y noche cada día de la semana, incluyendo fines de semana y festivos. Los empleados se
identifican por su nombre y se guarda también información de su dirección y edad. Los empleados del
servicio de mantenimiento trabajan en equipos. Los equipos se identifican por un número. 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 (dirección C/Valencia, 25 años), José (Gran Vía, 24 años) y Alberto (C/Aribau, 30 años)
pertenecen al equipo de mantenimiento número 2. José es el jefe de turno de este equipo. Pedro (C/Mallorca, 25
años), Félix (C/Guipúzcoa, 29 años) y Nuria (C/Carlos Altés, 30 años) pertenecen al equipo de mantenimiento
número 1. Nuria es la jefe de turno de este equipo.
Para configurar el calendario de trabajo, los días se estructuran en turnos. Los días no festivos tienen
tres turnos de ocho horas (mañana, tarde y noche) y los días festivos tienen dos turnos de 12 horas (día
y noche). Cada turno de cada día se asigna a un equipo de mantenimiento.
Por ejemplo, viernes 6 de noviembre el equipo 1 trabajará en el turno de mañana, el equipo 2 en el turno de tarde y
el equipo 3 en el turno de noche. Sábado día 7 de noviembre el equipo 1 trabajará de día y el equipo 2 de noche; el
equipo 3 no trabaja.
Para coordinar los diferentes equipos, se programa la realización de los trabajos que se han de llevar a
cabo cada turno de cada día. Los trabajos se identifican por un código y tienen una descripción. A
veces, no todos los trabajos programados se pueden realizar, porque surgen imprevistos. Al acabar la
jornada, el jefe de turno ha de indicar cuáles de los trabajos programados se han podido realizar y
cuáles 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 descripción del desarrollo del
trabajo. Por descontado, la empresa también quiere tener información de los trabajos que se han
tenido que hacer improvisadamente. En este caso el jefe de turno da la misma información que para
los trabajos programados realizados.
Por ejemplo, jueves 5 de noviembre por la noche estaba programado el 1: “revisar la máquina 303”, 2:
“cambiar los filtros de las máquinas de las salas 2 y 4” y también el trabajo 3: “preparar la instalación de la
nueva máquina en la sala 3”. Los trabajos 1 y 2 se pudieron realizar, pero el trabajo 3 no, porque falló un centro
138 de transformación 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 reparación del centro de transformación se
acabó a las 6 de la mañana.
El equipo de turno, al realizar sus trabajos, usa ciertos materiales. Se quiere tener información de qué
materiales se han usado para cada trabajo y en qué cantidad.
27. Un palacio de ferias necesita un sistema que gestione información 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 simultáneamente más de una feria en el palacio. Para cada feria que
se organiza se hace una división del palacio en parcelas. Cada parcela tiene un número 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. También se desea registrar qué parcelas
son limítrofes (sólo pueden ser limítrofes parcelas de una misma feria). Una parcela puede tener
como máximo dos parcelas limítrofes y puede haber parcelas aisladas que no tienen ninguna
parcela limítrofe.
Por ejemplo, la feria Construmat’03 comienza el 6-3-2003 y acaba el 10-3-2003. La división del palacio para esta
feria feria consta de 3 parcelas: la número 1 (superficie 10), la número 2 (superficie 20) y la número 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
Informat’03 comienza el 3-4-2003 y acaba el 7-4-2003. Para Informat’03, el palacio se ha dividido en dos parcelas:
la número 1 (superficie 40) y la número 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 también su teléfono. Algunas parcelas pueden quedar sin contratar.
Por ejemplo, la empresa ‘Rajolsa’ (teléfono 933333333) ha contratado la parcela 1 y la parcela 2 de la feria
Construmat’03. La empresa ‘CAD’ (teléfono 911111111) ha contratado la parcela 3 de la feria Construmat’03 y ha
contratado la parcela 2 de la feria Informat’03.
A las parcelas se asignan personas que se encargan de atender a los asistentes de la feria que estén
interesados en lo que se expone en la parcela. Estas asignaciones tienen una fecha de inicio y una
fecha de fin que estarán 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 titulación y su población de
residencia. Supondremos, para simplificar, que podemos identificar a las personas por su nombre.
Por ejemplo, a la parcela 1 de la feria Construmat’03 se ha asignado a Ana (titulación arquitecta y población
Girona) desde el 6-3-2003 hasta el 7-3-2003, a Juan (titulación aparejador y población Barcelona) desde el 6-3-
2003 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 139
Construmat’03 se ha asignado a Nuria (titulación delineante y población Reus) desde el 6-3-2003 haste el 10-3-
2003. Finalmente, a la parcela 2 de la feria Informat’03 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 población de
residencia y su e-mail. Las personas que están asignadas a parcelas de una determinada feria no
pueden estar inscritas en la misma feria. La mayoría de inscripciones son válidas para todos los días
que dura la feria pero existe la posibilidad de hacer una inscripción de tipo parcial que incluya sólo
alguno de los días de la feria no necesariamente consecutivos y con un máximo de 3 días. El sistema
ha de registrar las fechas incluidas en cada una de las inscripciones que sean de tipo parcial. Las
inscripciones pueden pagarse sólo 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 número de tarjeta utilizado.
Por ejemplo, Ana (e-mail: ana@coac.com) se ha inscrito a Informat’03. El pago ha sido en efectivo y se le ha
aplicado un descuento del 10%. Gustavo (e-mail: gustamante@cons.com y población Logroño) se ha inscrito a
Construmat’03 con una inscripción parcial que incluye los días 7-3-2003 y 9-3-2003. En este caso el pago ha sido
con la tarjeta número 333.
28. Una agencia de viajes está interesada en desarrollar un sistema software para la gestión de los viajes
que se contratan en sus oficinas. La agencia tiene diversas oficinas (identificadas por número y de las que
se registra también su dirección). Una persona (identificada por nombre y de la que queremos saber
también 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 máximo en una única oficina. El sistema sólo
ha de guardar información 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 años) es cliente de las oficinas 1 (C/Mayor) y 2 (C/Menor), en ambos casos desde el 25 de
octubre del 2002, y María (19 años) es cliente de la oficina 1 desde el 3 de noviembre de 2002. Marta (22 años) e
Isabel (21 años) trabajan en la oficina 1 y Pablo (22 años) trabaja en la oficina 2.
Cuando una persona es cliente de una oficina, puede pedir presupuestos de viajes en la oficina. La
petición de presupuesto de un viaje se hace en una cierta fecha y para un cierto país de destino. Para
simplificar, consideraremos que un viaje se hace a un único país. Interesa saber también la fecha de
inicio y la duración del viaje. En una misma fecha un cliente puede pedir diversos presupuestos de
viajes a países distintos, pero no puede pedir en una oficina dos presupuestos para el mismo país. Una
persona no puede pedir presupuesto de viaje en una oficina si no es cliente de aquella oficina.
Por ejemplo, el día 4 de noviembre del 2002 Juan pidió presupuesto de un viaje a Noruega en la oficina 1. El viaje
tenía que comenzar el 27 de diciembre del 2002 y durar 7 días. El mismo día, Juan pidió presupuesto de un viaje a
140 Italia, que comenzaría el 10 de febrero del 2003 y duraría 15 días, en la oficina 2.
Las peticiones de presupuestos de viajes son evaluadas por un máximo de 3 empleados de la oficina y
se indicará, para cada evaluación, el precio aproximado del viaje. Una vez se tiene alguna evaluación
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 evaluación.
Por ejemplo, Marta e Isabel hicieron una evaluación del viaje que Juan había pedido el día 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 también su grado de seguridad). Esta información ha de registrarse en el sistema
y, además, para los viajes que usen el avión habrá que registrar también la información de los
aeropuertos (identificados por código y del que se sabe también la ciudad) por donde pasa el avión en
aquel viaje.
Por ejemplo, el anterior viaje contratado usaba el barco (97% de seguridad) y el avión (98%). El avión 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 matrícula,
ambos identificadores.
propietario
Posee poseído
1..* *
propiedad
Persona Coche
141
Conduce
1..* *
conductor conducido
conducción
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 expresión que dé el
conjunto (sin repeticiones) de todos los habitantes de los pisos que tienen más de un propietario.
Persona
habitante * 1..* propietario
{subset}
vive posee
vivienda * * propiedad
Piso
3. Dado el modelo conceptual de la figura siguiente, expresa en OCL las restricciones textuales r1)
y r2).
Empleado Departamento
* 1..*
código trabaja-en número
* *
vive-en situado-en
1 Ciudad 1
nombre
RT: La clave de empleado es código, la clave de departamento es número y la clave de ciudad es

nombre.
r1) Un empleado sólo puede trabajar en departamentos situados en la ciudad donde vive.
r2) Un empleado ha de trabajar como mínimo en un departamento situado en la ciudad donde vive.
4. Dado el modelo conceptual de la figura siguiente, escribe en OCL una expresión que dé, sin
repeticiones, los nombres de los músicos que alguna vez han tocado algún instrumento del que no son
expertos.
Músico
142 * * ObraMusical
nombre interpreta
*
es-experto-en
* Interpretación
*
Instrumento * toca
RT: La clave de músico 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 definición 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é días de la semana hay clase y a qué hora (para
simplificar, supondremos que los periodos de clase son siempre de una hora). Además, también hay
que guardar la información del aula de cada horario.
El sistema que se debe desarrollar sólo ha de consultar los datos de ASIGNATURA y las
143
FRACCIONES HORARIAS, dado que existe otro sistema encargado de darlos de alta. Los diversos
número 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:
FRACCIÓN-HORARIA
día
hora
ASIGNATURA 0, 3 GRUPO
código * Hace-clase
0..1 número
nombre
HORARIO
{incomplete}
HO-COMPLETO
aula
El sistema ha de permitir efectuar las funcionalidades siguientes: definición-de-horarios-de-un-grupo,

asignación-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 código de la asignatura, el número
de grupo a dar de alta y, para cada fracción horaria en que se hace clase de aquel grupo de la
asignatura, el día y la hora. Es el propio Jefe de Estudios quien comunica estos datos al sistema. Haz
que la interacción necesaria para llevar a cabo esta funcionalidad requiera más de un evento.
Cuando se efectúa una asignación de aula, se indica el código de la asignatura, el número de grupo, el
día, la hora y el aula asignada. Esta operación es efectuada por los empleados de secretaría 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 código de la asignatura y el sistema muestra, para cada horario de aquella asignatura sin
aula asignada, el número de grupo, el día 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 código y,
para cada grupo de la asignatura, su número, los días y horas en que se hace clase y, si se conoce, el
aula.
Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación 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.
x Modelo de casos de uso: Diagrama de casos de uso. Especificación del caso de uso de la
asignación de aula.
x Modelo del comportamiento del sistema: todos los diagramas de secuencia y contratos de las
operaciones correspondientes a la definición de los horarios de un grupo y al listado de horarios sin
144 aula de una asignatura.
2. Considerad una empresa de transportes que está interesada en un sistema para la definición de
los recorridos de las rutas de distribución de sus camiones. Una ruta está formada por una serie de
tramos consecutivos (que se distinguen por el número de tramo dentro de la ruta). Un tramo se define
por un apoblación de origen, una de destino y una carretera que une las dos poblaciones. Además,
también hay que guardar la información de la distancia y de la duración de recorrido de un tramo.
El sistema que se debe desarrollar sólo ha de consultar los datos de POBLACIÓN 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:
0.. 2 (origen)
POBLACIÓN
CARRETERA
nombre-p Hacen-tramo
* código-c
habitantes (destino)
0.. 2
TRAMO RUTA
De-la
distancia
* * código-ruta
duración
TRAMO-RUTA
núm-tramo
R.I. textuales:
- La población destino de un tramo de la ruta ha de coincidir con la población origen del tramo siguiente de la misma ruta.
- La población origen y la población destino de un tramo han de ser diferentes.
El sistema ha de permitir efectuar las funcionalidades siguientes: alta-tramo, alta-ruta, listado-de-

tramos-sin-ruta y listado-de-tramos-de-ruta.
Cuando se da de alta un tramo, se indica el nombre de la población de origen, el nombre de la

población de destino, el código de la carretera, la distancia y la duración del tramo. Esta operación es
efectuada por los empleados de la empresa, a petición del Director de Distribución.
Cuando el Director de Distribución da de alta una ruta, indica él mismo al sistema el código 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 código de carretera y el número de tramo dentro de la ruta. Haced que la
interacción necesaria para llevar a cabo esta funcionalidad requiera más de un evento.
El listado de los tramos sin ruta asignada se emite siempre a final de mes y va dirigido al Director de
Distribución. 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 código 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
población de origen y de destino, el código de la carretera, la distancia y la duración del tramo y el
número de tramo dentro de la ruta.
Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML). En todos los 145
x Modelo de casos de uso: Diagrama de casos de uso. Especificación 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 turístico del Alt Empordà que está interesada
en un sistema para gestionar los alquileres de las fincas que posee en el pueblo. El sistema guarda
información de las calles (identificadas por nombre) donde tiene situadas las fincas (identificadas por
número 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 también información del precio del
alquiler y de atributos específicos para cada tipo de alquiler. Además, el sistema sólo 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:
CALLE FINCA
1 1..* * Alquilada-por * CLIENTE
nombre-c Con núm-f dni
ALQUILER nombre
piso
precio
tipo
tipo {Disj., Comp.}
TEMPORAL INDEFINIDO
fecha-fin 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, baja-

alquileres y listado-de-alquileres-con-aumento-elevado.
Cuando se da de alta una calle, se indica el nombre de la calle y, para cada finca de aquella calle, su
número de finca. Esta operación es efectuada por los empleados de la agencia, a petición de la
146 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 número 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, según proceda. Haced que la interacción necesaria para
llevar a cabo esta funcionalidad requiera más de un evento.
Al final del día, se dan de baja automáticamente todos los alquileres que finalizan en esta fecha.
Además, el sistema genera un listado que incluye, para cada alquiler dado de baja, el nombre de la
calle, el número 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 número de finca y el nombre del cliente que tiene el piso alquilado.
x Modelo de casos de uso: Diagrama de casos de uso. Especificación 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 travesía de los Pirineos a

pie, desde Biarritz a Cabo de Creus. Esta travesía consta de diversas jornadas (identificadas por
un número) que se recorren entre una población de inicio y otra final. Toda jornada tiene una
serie de controles (identificados por un número dentro de la jornada) para garantizar que ningún
participante se pierde. Las personas se pueden inscribir en una jornada de la travesía. El sistema
almacena también las horas de paso de todos los participantes para cada uno de los controles que
pasan. Además, el sistema sólo 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:
Con CONTROL
JORNADA 1 1..*
núm-cont
Núm-jorn * lugar
Pob-inicio
* Pob-fin
Se-inscribe
Pasa-por
PERSONA *
*
dni PARTICIPACIÓN CONTROL PARTICIPANTE
nombre-p
hora-de-paso
R.I. textuales:
- Claves de las clases no asociativas: (Jornada, núm-jorn), (Persona, dni).
- Una jornada no puede tener dos controles con el mismo núm-cont. 147
- La población 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 número de la jornada, la población de inicio, la población
final y, para cada control de aquella jornada que se está dando de alta en aquel momento, su número 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 decisión de su recorrido concreto. Además, ya no se pueden dar de alta jornadas
una vez se conocen los primeros controles de paso de la travesía. El alta de jornadas es efectuada por los
empleados de la agencia, a petición del Responsable de Recorrido. Hay que hacer que la interacción
necesaria para llevar a cabo esta funcionalidad requiera más de un evento.
Cuando una persona quiere participar en una jornada de la travesía, lo hace saber al empleado que es
quien comunica esta información al sistema. Basta con indicar el DNI de la persona y el número de
jornada.
Cuando el Controlador Jefe da de alta todos los controles de los participantes de una jornada, indica él
mismo al sistema el número de jornada y, para cada persona que ha participado en aquella jornada, el
número de control y la hora de paso de todos los controles por los que ha pasado. La interacción
necesaria para llevar a cabo esta funcionalidad ha de requerir también más 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
número de control y la hora de paso de todos los controles de participante.
x Modelo de casos de uso: Diagrama de casos de uso. Especificación 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 definición 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 matrícula se define por
un estudiante y por un grupo donde el estudiante se matricula. Las matrículas pueden ser de dos
tipos: de evaluación continua y de evaluación no continua. Para las matrículas de evaluación no
continua se registra la nota final del estudiante. Para las de evaluación continua se registran las
diversas notas parciales del estudiante. El modelo conceptual de datos en UML de este sistema es
el siguiente:
ASIGNATURA GRUPO ESTUDIANTE

148 código-asig 1 Tiene * número * Se-matric * dni
nombre capacidad nombre
créditos teléfono
MATRÍCULA
PARCIAL * {disjoint, complete}
tipo
núm-parcial Corresponde
*
NOTA EVALUACIÓN EVALUACIÓN
CONTINUA NO CONTINUA
nota
nota-final
R.I. textuales:
- Claves de las clases no asociativas: (Asignatura, código-asig), (Estudiante, dni), (Parcial, núm-
parcial).
- No puede haber ninguna asignatura que tenga dos grupos con el mismo número.
- Un estudiante no puede matricularse de más de un grupo de la misma asignatura.
El sistema que se debe desarrollar sólo 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, matrícula-estudiante,
asignación-notas-parciales, consulta-estudiantes-con-notas-finales-aprobadas.
Cuando el Jefe de Estudios quiere definir los grupos de una asignatura, indica el código de la
asignatura y, para cada grupo a dar de alta, el número de grupo y la capacidad del grupo. Es el propio
Jefe de Estudios quien comunica estos datos al sistema. Haced que la interacción necesaria para llevas
a cabo esta funcionalidad requiera más de un evento.
Cuando un estudiante se matricula en un grupo, indica el código de la asignatura, el número de grupo,

su DNI y el tipo de matrícula (evaluación continua o no). Esta operación es efectuada por el propio
estudiante.
Cuando un profesor quiere hacer una asignación de notas parciales a estudiantes con matrícula de
evaluación continua en un determinado grupo, se indica el código de la asignatura, el número de grupo
y el número de parcial y, para cada estudiante que tiene nota parcial, el DNI del estudiante y la nota.
Esta operación es efectuada por el empleado de secretaría a petición 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 matrícula de evaluación no continua con nota final mayor o igual que 5,
el DNI del estudiante, el código de la asignatura y el número de grupo.
x Modelo de casos de uso: Diagrama de casos de uso (para las funcionalidades especificadas).
Especificación del caso de uso del alta de grupos de una asignatura.
operaciones correspondientes a la asignación de notas parciales y a la consulta de estudiantes con 149
notas finales aprobadas.
6. Considerad una empresa que se dedica a la organización de congresos y que está interesada en
un sistema para la gestión de las sesiones, de las ponencias y de los asistentes a los diversos congresos
que organiza. Un congreso se estructura en sesiones. Cada sesión de un congreso se dedica a la
presentación 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 inscripción. Para las inscripciones
normales se registra la profesión de la persona inscrita en el momento de la inscripción. El modelo
conceptual de datos en UML de este sistema es el siguiente:
Congreso Sesión Ponencia

siglas Tiene nom-sesión Se-presenta código
año 1 * duración 1 0..4 título
precio
* *
Asiste-a
Es-autor
1..*
Inscripción Persona
*
tipo {disjoint, complete} nombre
Ins. Normal Ins.Estudiante

profesión universidad
R.I. textuales:
- Claves de clases no asociativas: (Congreso: siglas, año), (Ponencia: código), (Persona: nombre).
- No puede haber ningún congreso que tenga dos sesiones con el mismo nombre de sesión.
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-sesión 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, año y precio del congreso y, para cada sesión del congreso, el nombre de
la sesión y su duración. Es el propio Presidente del Comité Organizador quien comunica estos
datos al sistema. Finalmente, el sistema muestra el número total de sesiones dadas de alta por el
congreso. Haced que la interacción necesaria para llevar a cabo esta funcionalidad requiera más de
un evento.
Cuando el Presidente del Comité de Programa de un congreso quiere dar de alta las ponencias de una
sesión del congreso, se indican las siglas y año del congreso y también el nombre de la sesión.
Además, para cada ponencia de la sesión, se indican el código y título de la ponencia junto con los
nombres de todos los autores de la ponencia. Hay que considerar que algunos de estos autores
existirán en la base de información mientras otros no. También 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
150 es efectuada por un administrativo de la empresa a petición del Presidente del Comité de Programa.
Haced que la interacción de esta funcionalidad requiera más 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 inscripción de estudiante a
algún congreso y que, al mismo tiempo, son autores de alguna ponencia que se presenta en alguna
sesión del mismo congreso.
Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación 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 sesión 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 información de las personas que
quieren hacer algún viaje, identificadas por DNI y de las que se registra también su nombre. También
se guarda información de las ciudades en las que la agencia ofrece viajes. Concretamente, se registra
el nombre y, si son ciudades de mar, se guarda información de sus hoteles.
8.
Además, el sistema guarda información 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 señal 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:
Persona Fecha
dni * fecha
1 Ciudad
nombre * inicio
0.. 3 nombre
Quiere-viajar {incomplete}
/Tiene-presupuestados
Viaje-planeado Mar
{disjoint, complete}
1
De-la
Presupuestado Reservado Confirmado *
* Hotel
precio avance
* Se-aloja-en 0..1
nombre
R.I. textuales:
- Claves clases no asociativas: (Persona, dni); (Fecha, fecha); (Ciudad, nombre).
- Una Ciudad no puede tener más 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 más 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 interacción, 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 más de tres viajes planeados a diferentes
ciudades en una cierta fecha. Haced que la interacción necesaria para llevar a cabo esta funcionalidad
requiera más 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 sólo se puede confirmar si estaba reservado.
Si un cliente quiere saber las personas, sin repeticiones, que se han alojado en el pasado en algún hotel
en el que él también 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 finalización. 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 Viaje Fecha

Se-inscribe *
* fecha_in
nombre_jub
año_nac * * núm_viaje Parar
tipo_transp
0..1
Visita Localidad
núm Incluye Parada nombre_loc
nombre fecha_fin núm_hab
fecha_vis * 1
R.I. textuales:
- Claves de clases no asociativas: (Jubilado: nombre_jub), (Viaje: núm_viaje), (Fecha: fecha_in),
(Localidad: nombre_loc), (Visita: núm).
152 - 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-viajes-
localidad.
Cuando el administrativo del club de jubilados quiere dar de alta un viaje, indica su número y el tipo
de transporte. A continuación, para cada parada del viaje indica su fecha de inicio, su fecha de fin, el
nombre de la localidad donde para, el número de habitantes de la localidad (sólo en caso de que la
localidad no existiera en la base de información) y, además, la información de todas las visitas que
incluya la parada (número, nombre y fecha). Haced que la interacción necesaria para llevar a cabo esta
funcionalidad requiera más de un evento.
Cuando el administrativo del club de jubilados quiere hacer un cambio de fechas de una parada indica
al sistema el número de viaje, la fecha de inicio y el nombre de la localidad de la parada. También
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 algún 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 número 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 gestión de sus proyectos
informáticos. Los proyectos se identifican por código y se guarda su fecha de inicio. Un proyecto
puede constar como máximo de tres etapas: especificación, diseño o implementación. 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
también su nombre y plus de sueldo. Además, un empleado puede participar en diversas etapas de
proyectos. Una participación se hace en la etapa de especificación, en la de diseño o en la de
implementación (según el nombre de la etapa correspondiente en aquella etapa del proyecto). El
modelo conceptual en UML de este sistema es el siguiente:
Proyecto Etapa 3
* Consta-de 0.. 3
código: String nombre: String
fecha-ini: Fecha precio-h: Entero
Empleado 1 Dirige edp-dir 153
director *
dni: String 0..10 Participa * EtapaDelProy
nombre: String edp-part
participante
plus: Entero
Participación
núm-h: Entero
{disjoint, complete} nombre
Material
Especificación Implementación Diseño * Usa *
código: Entero
R.I. textuales:
- Claves clases no asociativas: (Proyecto, código); (Empleado, dni); (Etapa, nombre); (Material, código).
- El nombre de una etapa puede ser sólo Especificación, Diseño o Implementación.
- Un proyecto no puede constar de la etapa de implementación si no consta también de la de diseño.
- Un empleado no puede dirigir más de 3 etapas de diseño 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-participación y listado-proy-con-directivos-participantes.
Cuando el gerente de la empresa quiere dar de alta un proyecto, indica (él mismo) al sistema el código
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 interacción, el
gerente recibe un listado que indica, para cada empleado que dirige una etapa del proyecto, el nombre
del empleado y el número de etapas de otros proyectos dirigidas por aquel empleado. Lógicamente, un
proyecto se da de alta una única vez. Haced que la interacción necesaria para llevar a cabo esta
funcionalidad requiera más de un evento.
El encargado de proyectos, a petición del gerente, puede dar de alta nuevas participaciones en etapas
de un proyecto. En este caso, se indicará el código del proyecto, el nombre de la etapa, el DNI del
empleado, el número de horas de la participación y, si la etapa es de diseño, el código de los
materiales que se usarán.
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 código y la fecha de inicio de
los proyectos en que el director de alguna de sus etapas es también 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:
154 Actividad
nombre:string
*
Edificio Actividad
se_hace_en se_programa
nombre: string programada
*
dirección: string * inicio:date
*
teléfono: entero Curso
año1: año
Horario año2:año
hora_inicio:hora
hora_fin: hora
Dia_Semana
Actividad nombre:string
* tiene_horario *
en_edificio
*
Grupo de
actividad matricula Estudiante
* * código: entero
nombre: string
profe: string nombre: string
R.I. textuales:
- Claves clases no asociativas: (Curso: año1,año2); (Actividad: nombre); (Edificio: nombre);
(Dia_semana: nombre); (Grupo de actividad: nombre, actividad_en_edificio).
- Una misma actividad no se puede hacer simultáneamente en más de un edificio.
- En un edificio no se pueden hacer más de cinco actividades en un día.
El sistema ha de permitir efectuar, entre otras, las funcionalidades: programación de actividades de un

curso y listado de aceptación de actividades.
El personal de administración, a petición del director, programa las actividades de un curso. Indica al
sistema el curso (año1, año2) que quiere programar. Entonces, para cada actividad indica su nombre y
la fecha de inicio. Si la actividad no existía previamente, hay que darla de alta en este momento.
Opcionalmente, también puede indicar los edificios en que se hará la actividad. Para cada edificio
indicará su nombre. Haced que la interacción necesaria para llevar a cabo esta funcionalidad requiera
más de un evento.
El director de la escuela puede pedir, en cualquier momento, el listado de aceptación de las

actividades en un curso determinado. Indicará el curso y un número 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 número indicado. El listado mostrará, para cada actividad, su
nombre y el número 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 especificación en UML

1. Considerad un sistema sencillo de control de préstamos en una biblioteca. El sistema ha
de admitir altas y bajas de socios y de libros. Los socios pueden pedir libros en préstamo,
pero no se pueden tener más de tres libros prestados en un momento determinado. Los libros
se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve
un libro más allá de la fecha de devolución, se penaliza reduciendo en una unidad el número
de libros que puede tener simultáneamente. Cuando llega a cero, el socio se da de baja
automáticamente.
157
x Modelo conceptual de datos

x Modelo de casos de uso: diagrama de casos de uso y especificación de los casos de uso
x Modelo del comportamiento del sistema: diagramas de secuencia y contratos de las operaciones
x Modelo de estados: diagrama de estados para objetos y casos de uso
2. Considerad un sistema sencillo de reserva y utilización 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 día. No hay límite en las reservas que puede hacer un socio, pero no se pueden
hacer reservas para dentro de más de un mes. Cada final de mes se envía 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 ocupación” de una
pista durante un año natural no se cargará en la factura del socio, pero el resto se cargarán como si se
hubieran utilizado realmente.

3. Considera el caso de una empresa que se dedica a gestionar la adopción 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 algún
cliente cualquiera que esté esperando perros de esta raza, se le asigna el nuevo perro, y se produce
una salida “Adopción 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 algún perro cualquiera de esta raza libre, se le asigna al cliente y se produce una salida
“Adopción 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.
Cuando se produce el evento de Cambio de perro, nos comunican el identificador de la persona que
158 nos devuelve el perro (no es necesario que nos indiquen el perro que devuelve). El cambio sólo se
acepta si tenemos algún 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 “Adopción
realizada”, indicando el identificador del perro y el del cliente. No es necesario guardar la historia de
las adopciones hechas por los clientes. Podéis suponer que las razas están codificadas.

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 año. Cuando se produce
una nueva compra nos comunican el código del cliente que la ha hecho, el código 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 sólo compra un único producto.
El sistema accede a dos archivos ya existentes: Productos y Clientes. El archivo de productos

contiene, para cada producto, su código, la descripción y el precio unitario. El archivo de cliente
contiene, para cada cliente, su código, su nombre y el total comprado en el último año.
Un producto puede ser comprado por un número indeterminado de clientes. Al mismo tiempo, un
cliente puede llegarnos a comprar un número 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 aún no se han facturado. Una factura se identifica por un número 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 más 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 número 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 año”, el sistema ha de calcular, para cada cliente, el importe total
de las compras que nos ha hecho durante el año, y registrarlo en el archivo Clientes.

5. Una federación de ciclismo ha decidido facilitar la organización de carreras por etapas para
aficionados. Con esta intención ha encargado a una empresa de software la construcción de un sistema
informático capaz de gestionar los datos de una única carrera. 159
La carrera consta de diversas etapas, numeradas correlativamene. Los ciclistas tienen un número de
dorsal y se quiere conocer también su nombre y el de su equipo. En cada etapa, los corredores llegan
en un cierto orden y habiendo tardado un determinado tiempo. La clasificación general de la carrera se
establece según 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 clasificación general. Para dar de alta un
corredor se proporciona su número de dorsal, su nombre y el de su equipo. El sistema ha de
comprobar que no exista otro ciclista con el mismo número. 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 número, la posición en la que ha llegado y el
tiempo que ha consumido. El sistema comprueba que los datos entrados son correctos, genera un
número de etapa (el más alto que ya exista más uno) y almacena los resultados. Además, se
imprime un listado en el cual se muestra el número de etapa y, para cada corredor, la clasificación,
el número, el tiempo, el nombre y el equipo. En cualquier momento se puede solicitar un listado
con la clasificación general (que será provisional si no ha acabado la carrera). Se ha de mostrar el
número de la última etapa recorrida y, para cada corredor que la ha acabado, la clasificación, el
número, el tiempo acumulado, el nombre y el equipo.

6. Los gestores de El séptimo sello, una sala de cine, han decidido ofrecer a sus clientes un servicio
de reserva por teléfono de entradas numeradas. Con este propósito, han encargado a un estudiante de
IS:E la construcción de un sistema informático.
Los films se proyectan en sesiones, cada una de las cuales se identifica por el día y por el orden dentro
del día. Cada sesión comienza en una hora determinada y proyecta una determinada película (de la
cual sólo nos interesa su nombre). En un mismo día, se pueden proyectar películas diferentes. La sala
dispone de un número fijo de butacas, cada una de las cuales se identifica por el número de la fila y el
número dentro de la fila.
De todos los eventos a los cuales ha de responder el sistema, sólo nos interesan cuatro: 1) compra
directa en ventanilla (sin reserva previa) de una entrada, 2) petición (telefónica) de reserva de una
entrada, 3) recogida y pago (en ventanilla) de una entrada reservada y 4) consulta de la ocupación de
una sesión. Otros eventos (p.ej.: altas y bajas de sesiones) pueden ignorarse.
Para comprar directamente una entrada se proporciona la sesión, la fila y el número de la butaca. Una
vez hechas las comprobaciones pertinentes, se anota la ocupación 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. Después de las validaciones oportunas, se anota la reserva con el
DNI. Para recoger una reserva se vuelve a introducir la misma información; se hacen, como siempre,
las comprobaciones necesarias, se registra que la entrada ha sido pagada y se imprime como en el caso
160 de la compra directa. Finalmente, la ocupación de una sesión 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.

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 revisarán estas
ponencias y las revisiones que éstas hacen.
Cada ponencia tiene un código, que la identifica, un título y está escrita por una o más 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 envía a uno o más 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, recepción de una
ponencia, asignar una ponencia a un revisor, registrar la valoración que un revisor hace de una
ponencia y generar un listado con las revisiones pendientes de valoración.
Para dar de alta un revisor se proporciona su nombre. El sistema ha de comprobar que no existe
ningún otro revisor con el mismo nombre.
Cuando se recibe una ponencia, se indica el código de la ponencia, su título, el autor principal y el
resto de autores.
El presidente del comité de programa asigna cada ponencia a diversos revisores indicando, para cada
asignación, el código 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 días, los revisores envían el resultado de la revisión que han hecho de una ponencia
indicando el código de la ponencia, el nombre del revisor y la calificación que expresa, en una escala
de 0 a 10, la valoración global que el revisor hace de la ponencia. Como es lógico, un revisor no
puede enviar la valoración de una ponencia que no le había 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
valoración. Se ha de mostrar, para cada ponencia pendiente de valoración por parte de un revisor, el
código de la ponencia, su título y el nombre del revisor.

x Modelo de casos de uso: diagrama de casos de uso y especificación de los casos de uso 161
8. Considerad una federación de entidades excursionistas que está interesada en un sistema para el
control de las expediciones efectuadas por los centros excursionistas adscritos a la federación. Una
expedición la efectúa un centro excursionista a una cierta montaña, con una fecha de inicio y una de
fin. La federación identifica los centros excursionistas por su nombre y registra también su altura. Un
centro excursionista puede efectuar diversas expediciones a la misma montaña, con fechas de inicio
diferentes. A una misma montaña se pueden hacer diversas expediciones, pero en una fecha cualquiera
puede haber como máximo 5 expediciones.
En una expedición participan diversas personas (como mínimo una). Una persona puede participar en
más de una expedición. El sistema guarda información únicamente de las personas (que tienen el DNI
como identificador, un nombre y una edad) que han participado en alguna expedición que tenía como
objetivo una montaña de más de 8000 metros.
Alguno de los componentes de una expedición a una montaña de más de 8000 metros puede alcanzar
la cima. En este caso, se registrará este hecho y también 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 expedición.
El sistema que se debe desarrollar únicamente ha de consultar los datos referentes a centros
excursionistas y montañas, dado que ya existe otro sistema encargado de mantenerlos.
El sistema ha de permitir efectuar las operaciones siguiente: alta de expedición, alta de participante a
una expedición a una montaña de más de 8000 metros, alta de persona que ha alcanzado la cima y
emitir un listado de los datos de una expedición determinada.
Cuando se efectúa una alta de expedición, hay que indicar el nombre del centro excursionista, el
nombre de la montaña a la que se efectúa la expedición, la fecha de inicio y la fecha de final de
expedición.
Cuando se efectúa un alta de un participante a una expedición a una montaña de más de 8000 metros,
se indica el DNI de la persona, el nombre del centro excursionista que hace la expedición, la montaña
y la fecha de inicio de la expedición.
Cuando se efectúa un alta de persona que ha llegado a la cima se indica el nombre del centro
excursionista que hace la expedición, la montaña y la fecha de inicio de la expedición, el DNI de la
persona y la fecha en que alcanza la cima.
Para pedir el listado de los datos de una expedición hay que indicar el nombre del centro excursionista que
hace la expedición, la montaña y la fecha de inicio de la expedición. Se muestran el nombre del centro, la
montaña, su altura, la fecha de inicio y final de expedición y, si es el caso, el nombre de todas las personas
que han participado en la expedición 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
9. Una gran organización ha decidido poner en funcionamiento un sistema que le permita gestionar
los cursos de fomración a los que asisten sus empleados, ya sea como oyentes o bien mediante una
matrícula oficial.
Los empleados se identifican por código, y tienen también un nombre y una categoría. Los cursos de
formación se identifican por nombre, y se registra también quién 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 formación.
Un empleado se inscribe en un curso de formación en una cierta fecha. Cada inscripción 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 formación. La inscripción de un empleado en un curso de formación puede ser de dos tipos:
como “oyente” o bien como “matrícula oficial”. En el primer caso, el sistema guardará información
únicamente del motivo por el cual se ha realizado la inscripción. En el segundo, se registrarán tanto el
motivo como el precio de la inscripción.
En el caso de las inscripciones correspondientes a matrículas oficiales, el empleado tiene un máximo

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
también su nota.
El sistema ha de permitir efectuar las operaciones siguiente: nueva inscripción, asignar nota, emitir un
listado de inscripciones de un empleado y emitir un listado de convocatorias.
Cuando se efectúa una nueva inscripción, hay que indicar el código de empleado, el nombre del curso,
la fecha de inscripción, el motivo que la justifica, el tipo de inscripción y, en caso de tratarse de una
“matrícula oficial”, el precio.
Cuando se asigna una nota de una convocatoria, se indica el código de empleado, el nombre del curso
y la nota correspondiente. El número de la convocatoria se asignará, automáticamente y de forma
correlativa, por el propio sistema y se mostrará al usuario si la operación se ha podido efectuar
satisfactoriamente.
Las inscripciones de un empleado se pueden consultar indicando su código y, opcionalmente, el tipo

de inscripción (si se proporciona sólo se listan las inscripciones de aquel tipo). Se muestran, para cada
curso de formación en el que se ha inscrito el empleado, el nombre del curso, su organizador, la fecha
de inscripción, el motivo, y, si es el caso, el precio.
Para solicitar el listado de convocatorias hay que indicar el código del empleado y el nombre del curso
de los cuales se pide el listado. Se muestran el nombre y la categoría del empleado, el nombre del
curso y, para cada convocatoria de aquel empleado en aquel curso, el número de la convocatoria y su
nota.
163
En todas las operaciones anteriores, se deben realizar todas las comprobaciones que se consideren
adecuadas.

10. Considerad un club de automovilistas que está interesado en desarrollar un sistema software para
gestionar seguros de vehículos. Un vehículo (identificado por su número de matrícula y del que se
registra también su modelo) es comprado por un único conductor (identificado por número de licencia
y del que se conoce el nombre) en una cierta fecha. Un conductor puede haber comprado diversos
vehículos. El sistema guardará la información de los conductores que han comprado algún vehículo.
Todo vehículo comprado ha de contratar un seguro de accidentes a alguna compañía. Cuando se hace
uno de estos contratos, se registra también la fecha de inicio del mismo. Un vehículo no puede estar
contratado en más de una compañía, mientras que una compañía puede tener diversos contratos de
vehículos diferentes. De las compañías de seguros nos interesa registrar su nombre y la dirección (que
supondremos única para cada compañía).
Se debe registrar también la información de los conductores que no son aceptados por las compañías
de seguros, conjuntamente con el motivo de la no aceptación. Lógicamente, una compañía no podrá
tener seguros de coches comprados por conductores que no son aceptados por la compañía. Un
conductor puede no ser aceptado por diversas compañías.
Para simplificar, supondremos que la información de conductores, vehículos y compras de vehículos es

matenida por algún 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 compañías y listado de seguros de una compañía.
Cuando se quiere hacer un alta de contrato de seguro hay que indicar la matrícula del coche, el nombre de
la compañía 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 matrícula del coche y el nombre de la compañía. En ambos casos, son los
empleados quienes comunican los datos al sistema, a petición de algún conductor.
Las compañías de seguros envían al club de automovilistas los listados de conductores que no son
aceptados por la compañía. Algún empleado del club, cuando así lo considere conveniente,
comunicará al sistema el listado de todos los conductores no aceptados por las diversas compañías. Se
indicará, para cada compañía, el número de licencia de cada uno de los conductores no aceptados.
Haced que la interacción necesaria para llevar a cabo esta funcionalidad requiera más de un evento.
Para pedir el listado de los contratos de una compañía, el director del club de automovilistas indica
directamente al sistema el nombre de la compañía y el sistema muestra, para cada contrato de seguros
de aquella compañía, la matrícula del coche, el número de licencia de su propietario y la fecha de
contratación 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
instanciación del modelo que demuestre su validez.
x Modelo de casos de uso:
- Diagrama de casos de uso
- Especificación 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 compañía”
- Contratos de las operaciones correspondientes a estos diagramas de secuencia
11. Considerad un centro de gestión 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 mínimo 3) que pueden presentarse como candidatos independientes o no. Una misma
persona no puede estar en más de una candidatura por elección. El sistema debe tener registradas cuáles
son las personas candidatas de cada candidatura y también si se presentan como independientes o no (tipo
de candidato). Las personas se identifican por su DNI y también se quiere registrar su nombre.
Cada una de las elecciones municipales se identifica por su año de realización, los municipios se
identifican por su nombre y los partidos por sus siglas. Además, 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 representación, el sistema
deberá permitir tener registrado el número total de representantes obtenido y cuáles son los candidatos (de la
candidatura) que quedan escogidos como representantes. Para las candidaturas que no hayan obtenido
representación, el sistema deberá permitir registrar el número de votos obtenidos por la candidatura.
Para simplificar, supondremos que la información de elecciones, municipios, partidos y personas es

mantenida por algún 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 representación, entradas de resultados de candidaturas con representación 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 año 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 añadir
candidatos. Además, no se pueden dar de alta nuevas candidaturas para elecciones que ya tengan
algún resultado introducido. El alta de candidaturas es efectuada por los empleados del centro a
petición de los interlocutores de los partidos. Haced que la interacción necesaria para llevar a cabo
esta funcionalidad requiera más de un evento.
Cuando un empleado del centro quiere introducir los resultados de una candidatura sin representación,
indica él mismo al sistema las siglas del partido, el nombre del municipio, el año de las elecciones y el
número de votos obtenido por la candidatura. 165
Cuando un empleado del centro quiere introducir los resultados de una candidatura con
representación, indica él mismo al sistema las siglas del partido, el nombre del municipio y el año de
las elecciones. Además, para cada candidato que queda escogido como representante, indica su DNI.
Los resultados de una candidatura con representación 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 año 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 representación.
x Modelo conceptual de datos, que ha de incluir todas las restricciones textuales y atributos
derivados necesarios (en narrativa, no en OCL) y una instanciación del modelo que demuestre su
validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificación del caso de uso de la entrada
de resultados de una candidatura con representación (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.
12. Considerad una biblioteca que está interesada en desarrollar un sistema software para gestionar
los ejemplares de los libros de que dispone y los préstamos de estos ejemplares.
La biblioteca identifica todos los ejemplares de libros mediante un código que asigna la propia
biblioteca. Cada ejemplar corresponde a un determinado libro. De todos los libros de los cuales la
biblioteca tiene algún ejemplar, hay que registrar el ISBN (que los identifica), el título, los autores, la
editorial, el año de edición y el número máximo de días que el libro se puede dejar en préstamo.
Los socios se identifican por su DNI y también se quiere registrar su nombre y teléfono. Los socios
pueden realizar préstamos. Para cada préstamo, se debe conocer el socio que lo ha hecho, el ejemplar
prestado, la fecha de inicio del préstamo y la fecha de finalización del préstamo. Las fechas de
finalización de los préstamos han de respetar el máximo de días que se puede dejar en préstamo el
libro correspondiente al ejemplar.
Un socio no puede llevarse más de 10 ejemplares en préstamo en una misma fecha de inicio.
Evidentemente, para un determinado ejemplar, puede haber diversos préstamos siempre que sean en
periodos que no se solapen. También puede pasar que un socio haya realizado diversos préstamos de
un mismo ejemplar (que puede no coincidir con la fecha de finalización del préstamo).
A veces, un socio desea llevarse un ejemplar de un libro que no está disponible porque todos sus
ejemplares están prestados. Entonces puede hacer una reserva del libro. El sistema registra todas las
166 reservas de libros que aún 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 más antiguas.
El sistema a desarrollar ha de permitir efectuar las funcionalidades siguientes (entre otras): el alta del
préstamo de un ejemplar, el alta de un libro y todos sus ejemplares y el listado de préstamos no
devueltos de un libro.
Cuando un socio quiere hacer un préstamo de un ejemplar, el bibliotecario comunica al sistema el

código del ejemplar y el DNI del socio. El sistema muestra cuál es la fecha máxima que se puede
escoger para la finalización del préstamo (que depende del número máximo de días que el libro del
ejemplar se puede dejar en préstamo). A continuación, el bibliotecario comunica esta fecha máxima al
socio. Entonces, el socio da una fecha de finalización del préstamo. El bibliotecario comunica esta
fecha al sistema así como la fecha en que se realiza el préstamo. Finalmente, el sistema emite un
comprobante del préstamo, que incluye el título y autores del libro, el código del ejemplar, el DNI del
socio y la fecha de finalización del préstamo.
Se debe considerar que si un libro tiene reservas no siempre se podrá dejar en préstamo un
ejemplar de aquel libro. Concretamente, si el socio que se quiere llevar el ejemplar no tiene
reserva, es necesario que haya más ejemplares disponibles (sin préstamos 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 más ejemplares disponibles que reservas tiene el libro más
antiguas que la suya.
Cuando el bibliotecario quiere dar de alta un libro y todos sus ejemplares comunica al sistema el
ISBN, el título, los autores, la editorial, el año de edición y el número máximo de días que el libro se
puede dejar en préstamo. Además, para cada ejemplar del libro indica el código del ejemplar.
Finalmente, el sistema muestra el ISBN, el título del libro y el número de ejemplares que se han dado
de alta. Haced que la interacción necesaria para llevar a cabo esta funcionalidad requiera más 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 préstamos no devueltos de un libro comunica al sistema el

ISBN del libro. Como respuesta, el sistema muestra, para cada préstamo no devuelto correspondiente
a un ejemplar del libro, el código del ejemplar prestado, el DNI del socio que ha hecho el préstamo y
la fecha de finalización del préstamo.
validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificación del caso de uso del alta del
préstamo de un ejemplar.
x Modelo del comportamiento del sistema: Diagramas de secuencia del alta del préstamo de un
ejemplar, del alta de un libro y todos sus ejemplares y del listado de préstamos no devueltos de un
libro. Contratos de las operaciones correspondientes al alta de un libro y todos sus ejemplares y al
listado de préstamos 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
información relativa a sus empleados. La empresa tiene diversos departamentos (identificados por 167
nombre y de los que se registra también su dirección) en los que pueden trabajar los empleados
(identificados por código de empleado y de los que se registra también su sueldo que, como ya
veremos, depende de los departamentos donde trabaja y de las categorías que éste ocupe).
Un empleado puede trabajar en diversos departamentos, pero en una fecha un empleado sólo 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 histórico de esta información porque a la empresa le basta con saber sólo en qué departamentos
trabajan actualmente sus empleados.
Mientras trabaja en un departamento, un empleado puede tener diversas categorías (de las que se
registra sólo su nombre, que las identifica). De cada categoría 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 categoría sólo puede ser asignada a cinco empleados de la empresa y un
empleado que trabaja en un departamento no puede tener más de 3 categorías dentro de aquel
departamento. Si un empleado trabaja en diversos departamentos, entonces puede tener categorías
diferentes en cada departamento. Tampoco es necesario guardar un histórico de asignaciones de
categorías.
Además, el empleado tiene “Gerente” o “Vendedor” como categorías asignadas, el sistema debe
registrar información adicional. Un gerente tiene entre una y tres personas que lo pueden sustituir.
Para cada posible sustitución, hay que registrar el orden de prioridad de la sustitución. Un sustituto
de un gerente ha de ser un empleado cualquiera que trabaje en el mismo departamento, pero que no
tenga la categoría de gerente. Lógicamente, un gerente no se puede tener a él mismo como
sustituto. Para los vendedores hay que registrar también su día de descanso semanal (o sea, lunes,
martes, etc.).
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
más la suma de pluses de todas las categorías del empleado dentro del departamento.
Para simplificar, supondremos que la información de departamentos, empleados y fechas la mantiene

algún sistema externo y, por tanto, el sistema a desarrollar únicamente la deberá consultar. En cambio,
el sistema ha de permitir asignar categorías básicas 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 más de un departamento.
Cuando se quieren asignar categorías básicas a un empleado de un departamento, un administrativo de

la empresa indica al sistema (a petición del responsable de recursos humanos) el nombre del
departamento, el código del empleado, la fecha de las asignaciones y, para cada asignación, el nombre
de la categoría y el plus de sueldo. Para poder asignar la categoría, el empleado ha de trabajar ya en el
departamento y no se pueden asignar categorías a empleados de un departamento si éste tiene más de
100 empleados. Para simplificar, haced que el resultado de la ejecución de esta funcionalidad no
permita asignar la categoría de gerente ni la de vendedor. La interacción necesaria para llevar a cabo
esta funcionalidad ha de requerir más de un evento.
Cuando un administrativo, a petición del director general de la empresa, asigna sustitutos al gerente de
un departamento indica al sistema el nombre del departamento, el código del empleado y, para cada
168 empleado que lo puede sustituir, su código y el orden de prioridad de la sustitución.
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 código y la fecha en que comenzó a trabajar más, para cada categoría
del empleado, el nombre de la categoría.
En cualquier momento, el director general puede obtener un listado del código de los empleados que
son gerentes de más de un departamento.
validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificación del caso de uso de la
asignación de sustitutos de un gerente.
x Modelo del comportamiento del sistema: Diagramas de secuencia de “asignar categorías básicas”,
“listado de empleados de un departamento” y “listado de los gerentes de más 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 sabéis, 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
tecnologías de la información. 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 harán diversas ediciones. Cada edición se identifica por el día, mes y año de su
celebración. También se quiere conocer el lugar en que se celebra y el precio. En cada edición se
establecen posibles descuentos. Un descuento se identifica por el concepto dentro de la edición 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 también quiere conocer su nombre, dirección,
teléfono y el nombre de la persona de contacto. Cada vez que una empresa hace de patrocinador de
una edición de la Festibity hay que registrar el tipo de patrocinio, la aportación realizada y el número
máximo de invitaciones que se le asignan.
El sistema ha de mantener información actualizada sobre las personas del sector que han asistido a
alguna Festibity. Las personas se identifican por su nombre y también se quiere conocer el nombre de
su empresa, su teléfono 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
edición en curso (la próxima que se celebrará). Para esta edición hay que mantener información 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
edición. Se puede aplicar un descuento como máximo. Las personas invitadas no se consideran
asistentes hasta que han confirmado su asistencia. Cuando lo hacen, el sistema registra la fecha de 169
confirmación. El número de asistentes a la edición 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 invitación. Para los invitados de los patrocinadores se quiere
saber cuál es el patrocinador que los invita. Naturalmente, sólo los pueden invitar los patrocinadores
que lo son de la edición actual y un patrocinador no puede invitar a más personas que el número
máximo de invitaciones asignado.
El sistema ha de permitir efectuar las funcionalidades siguientes (entre otras): “invitar a una persona”
y “listado de los más 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 cuál es la persona
que se quiere invitar. Si la persona ya ha asistido a alguna edición, sólo hay que indicar su nombre. Si no,
habrá que indicar también el nombre de su empresa, el teléfono 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 envío de la carta es
la fecha actual. Si es un invitado de un patrocinador, hay que indicar el nombre del patrocinador. Podéis
suponer que el sistema siempre conoce la fecha actual (denotada por “fechaActual”). Haced que la
Cuando el decano de la FIB quiere saber cuáles son las empresas más colaboradoras con la
Festibity, él mismo lo solicita al sistema. Como respuesta el sistema muestra el nombre y la
aportación total de las empresas que han patrocinado la Festibity como “patrocinador principal”
más de tres veces.
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. Especificación del caso de uso “invitar a una
persona”; por motivos de brevedad, basta con que escribáis los cursos de eventos (típico y
alternativos).
correspondientes a los casos de uso “invitar a una persona” y “listado de los más colaboradores”. Por
lo que respecta a los contratos, basta con que escribáis la cabecera de cada operación, la precondición,
la postcondición 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 también su dirección. Un hotel tiene diversas habitaciones. Las
habitaciones de un hotel se identifican por un número de habitación dentro del hotel (obviamente, dos
hoteles diferentes pueden tener dos habitaciones con el mismo número) y se registra también si son
individuales o dobles.
Los clientes (identificados por DNI y de los que se guarda también el nombre y la dirección) pueden
hacer reservas en los hoteles. Cuando se hace una reserva se debe conocer el cliente que la hace, en
170 qué fecha se hace la reserva, qué tipo de habitación 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 mínimo, una
habitación del tipo especificado que esté disponible durante todos los días que se quiere reserar.
Lógicamente, una persona puede hacer diversas reservas en una misma fecha pero, para simplificar,
supondremos que en una fecha determinada un cliente no puede hacer más de una reserva en un
mismo hotel. Además, 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).
Periódicamente, la cadena hotelera asigna las reservas que tiene a las habitaciones de los hoteles.
Cada reserva da lugar a una asignación. Un asignación se define por el cliente y la fecha de la reserva
y la habitación del hotel que se asigna a la reserva. Como es lógico, no puede haber dos asignaciones
de una misma habitación que se solapen entre sí. Además, el tipo de la habitación asignada ha de
coincidir con el tipo de habitación solicitada en la reserva y el hotel de la habitación ha de ser también
el de la reserva.
Para simplificar, supondremos que la información de los hoteles y de sus habitaciones la mantiene
algún sistema externo y, por tanto, sólo 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 petición del cliente) comunica al
sistema el código del cliente que hace la reserva, el hotel, la fecha actual, el tipo de habitación 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 petición
del director de ocupaciones) indicará al sistema, para cada hotel de la cadena, su nombre y, para cada
habitación del hotel a la que se le asigna una reserva, el número de la habitación, el cliente y la fecha
en que se ha hecho la reserva. Haced que la interacción necesaria para llevar a cabo esta funcionalidad
requiera más 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 habitación que
no tenga una asignación en aquella fecha, el número de la habitación 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 instanciación del modelo que demuestre su validez.
x Modelo de casos de uso: Diagrama de casos de uso. Especificación del caso de uso de “hacer-
reserva”.
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 “listado-
habitaciones-disponibles”. Expresad las salidas con la ayuda del lenguaje OCL.
171

Especificacion de Sistemas de Software en Uml PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Especificacion de Sistemas de Software en Uml PDF

Cargado por

Copyright:

Formatos disponibles

Ernest Teniente López

Dolors Costal Costa

Dolors Costal Costa

Diseño de la cubierta: Manuel Andreu

© Los autores, 2003

© De la traducción, Sergio Morales García, 2003

© Edicions UPC, 2003

Producción: CPET (Centre de Publicacions del Campus Nord)

Depósito legal: B-33082-2003

1 Introducción a la ingeniería del software 9

3 Introducción a la orientación a objetos 27

3.1 – Motivación y orígenes .........................................................................................................27

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

5 El proceso unificado de desarrollo del software 101

6 Colección de ejercicios 107

Introducción a la ingeniería del software

Introducción a la ingeniería del software 2

Evolución de Costes del hardware y del software

© Los autores, 2003; © Edicions UPC, 2003

Evolución del software

Introducción a la ingeniería del software 4

Características del software

• Mantenimiento más difícil que el hardware.

• Se construye a medida, no se reusa demasiado.

© Los autores, 2003; © Edicions UPC, 2003

Introducción a la ingeniería del software 6

Aplicaciones del software

© Los autores, 2003; © Edicions UPC, 2003

Crisis del software

Introducción a la ingeniería del software 8

Resultados de proyectos de software

Acabado y operativo, pero In fo rm e C H A O S (19 9 4 )

© Los autores, 2003; © Edicions UPC, 2003

Ingeniería del software

Establecimiento y uso de principios de ingeniería orientados a

• Que funcione eficientemente

• Que satisfaga las necesidades de los usuarios

Introducción a la ingeniería del software 10

• Dispone de un abanico de técnicas probadas que dan resultados

© Los autores, 2003; © Edicions UPC, 2003

Introducción a la ingeniería del software 12

Visión genérica de la ingeniería del software

© Los autores, 2003; © Edicions UPC, 2003

Ciclo de vida clásico

Introducción a la ingeniería del software 14

© Los autores, 2003; © Edicions UPC, 2003

Planificación Análisis de riesg s

Introducción a la ingeniería del software 16

• The CHAOS Report, 1994

© Los autores, 2003; © Edicions UPC, 2003

• Determinación de los requisitos del software

• Especificaciones de sistemas software

Requisitos del sistema vs. requisitos del software

Requisito: Condición o capacidad necesitada por un usuario con

• La solución al problema se puede realizar con software, hardware,

• Si la solución es compuesta, antes de diseñar los detalles de un

Ejemplo de sistema compuesto: refinería automatizada

© Los autores, 2003; © Edicions UPC, 2003

Etapas de la ingeniería de sistemas

• Determinar requisitos del sistema global

HARDWARE SOFTWARE PERSONAS

Determinar requisitos del sistema global

• Comprensión de los objetivos y necesidades del usuario