Especificacion de Sistemas de Software en UML

Ernest Teniente López Dolors Costal Costa M. Ribera Sancho Samsó

Especificación de sistemas software en UML

POLITEXT 153


POLITEXT

Dolors Costal Costa M. Ribera Sancho Samsó Ernest Teniente López


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: [email protected]

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 sanciones establecidas en las leyes, la reproducción total o parcial de esta obra por cualquier medio o procedimiento, 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

2

Requisitos y especificación

17

3

Introducción a la orientación a objetos

27

9

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


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

9


2

Evolución de Costes del hardware y del software

100%

HARDWARE

SOFTWARE

1960

70

80

© Los autores, 2003; © Edicions UPC, 2003

90


3

Evolución del software

Distribución Hardware barato Software de consumo

Batch Poca distribución A medida

Multiusuario Tiempo real Bases de datos Software de producto

1950

60

70

Aplicaciones web

Sistemas sobremesa Sistemas expertos Cálculo paralelo

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.


4


5

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


6


7

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


8

Resultados de proyectos de software

Acabado y operativo, pero fuera de plazo, de presupuesto y sin satisfacer todos los requisitos

In fo rm e C H A O S (19 9 4 ) Acabado en el plazo y presupuesto, satisfaciendo los requisitos 16,2 %

52,7 %

Cancelado durante el desarrollo 31,1 %



9

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


10

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.



11

El proceso de la ingeniería Formulación

Análisis

Generación

Selección

Especificación

Implementación

Modificación

14


12

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



13

Ciclo de vida clásico ANÁLISIS REQS.

ESPECIFICACIÓN

DISEÑO CODIFICACIÓN

PRUEBA

MANTENIMIENTO

15


14

Prototipaje

ANÁLISIS REQUISITOS DISEÑO RÁPIDO

PRODUCTO

PROTO_ TIPO

REFI_ NAMIENTO EVALUACIÓN



15

Modelo en espiral Análisis de riesg s

Planificación

Evaluación

Ingeniería

16


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


•

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


2

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



3

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 del hardware

Ingeniería del software Ingeniería de sistemas

18


4

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



5

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 4. Actualizar pedido

defectuoso

5. Determinar dónde va

PEDIDO A PROVEEDOR PRODUCTOS ESTANTERÍAS

6. Almacenar

PRODUCTOS EN ESTANTERÍAS

19


6

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 5. Determinar dónde va orden

PEDIDO A PROVEEDOR PRODUCTOS ESTANTERÍAS

6. Almacenar SOFTWARE MANUAL

PRODUCTOS EN ESTANTERÍAS

HARDWARE



7

Diseño del sistema global

Recepción pedido

albarán aviso defectuoso

resultado

albarán

Sistema Inf rmátic orden

errores

Transp rte

20


8

Determinar requisitos del software

• Es el subconjunto de los requisitos del sistema global que han sido asignados al componente software concreto aviso

pedido albarán

SISTEMA INFORMÁTICO

resultado

orden errores



9

Especificar los requisitos del software • Describir con detalle el comportamiento externo del componente software concreto albarán

error

pedido Recibir pedidos

Tratar albaranes

pedidos

Actualizar pedidos

resultado

productos estanterías

Emitir orden

orden

21


10

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.



11

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


12

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



13

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

23


14

Propiedades deseables de las especificaciones

• No ambiguas • Completas • Verificables • Consistentes • Modificables • “Trazables” • Usables durante la operación y el mantenimiento



15

¿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


16

¿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



17

Bibliografía •

Shumate, K.; Keller, M. Software Specification and Design - A Disciplined Approach for RealTime Systems. John Wiley, 1992. (Cap. 3)

•

Davis, A. M. Software Requirements - Objects, Functions and States. Prentice-Hall, 1993. (Cap. 1-5)

•

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998 , 20 Oct 1998.

25



1


•

Motivación y orígenes

•

Visión de un sistema software – Aspecto estático – Aspecto dinámico

•

La notación UML

27


2

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



3

Orígenes Fusion Martin-Odell

OOSE Procesos y modelos recomendados

BOOCH

OMT

Shlaer & Mellor

UML

Rumbaugh, Blaha, Premerlani (OMT) - 1991 Coad, Yourdon - 1991 Shlaer, Mellor - 1992 Booch - 1992 Odell, Martin - 1992 Jacobson (OOSE) - 1993 Fusion - 1994 Booch, Rumbaugh, Jacobson (UML) - 1997

28


Visión de un sistema software


4


5

Objetos Objeto: Entidad que existe en el mundo real. Tienen identidad y son distinguibles entre ellos.

el avión con matrícula 327

una manzana

la factura 3443

un semáforo


29


6

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.



7

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 Nombre Dirección Teléfono Fecha_nacimiento Edad

Avión Modelo Capacidad Color

- Cada atributo tiene un valor (probablemente diferente) para cada objeto. - Los atributos pueden ser básicos o derivados.

30


8

Operaciones (I) Operación: Es una función o transformación que se puede aplicar a los objetos de una clase. Persona Nombre Dirección Teléfono

Avión Modelo Capacidad Color

Cambio_dirección Cambio_trabajo

Reparar 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.



9

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


10

Asociaciones

Asociación: Define la manera de enlazar o conectar objetos de diferentes clases.

Ejemplo: Un país tiene una única capital. País Nombre Habitantes

Ciudad tiene_capital

Nombre Habitantes



11

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 Contratar Pagar_sueldo Jubilar

Especialización

Directivo

Generalización

Viajante

Periodo contrato Desp. autor. Autorizar gastos Jubilar

...

Región Cuota Asignar región Asignar cuota

Herencia: Permite que las propiedades y las operaciones de una clase sean accesibles en sus subclases.

32


12

Orientación a objetos (I)

Aspecto estático: Describe la estructura estática de los objetos del sistema y sus interrelaciones.

Intra - objeto Aspecto estático

Clases de objetos Atributos Operaciones

Inter - objetos Asociación Generalización ...



13

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.


14


15

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

Casada

divorcio

Divorciada

boda

divorcio

boda

separación

enviudar

Separada

Viuda enviudar

34


16

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 pedido

Aceptar pedido

Preparar pedido

Entregar pedido

pedido entregado

Cerrar pedido

pedido preparado

Enviar factura

Cliente paga factura factura enviada


factura pagada

pedido cerrado


17

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 Aspecto estático Aspecto dinámico

Clases de objetos Atributos Operaciones Diagrama de transición de estados

Interobjetos Asociación Generalización ... Esquema de eventos

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


18


19

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

UML 1.4

Noviembre‘97 – OMG adopta UML 1.1 como estándar Enero‘97 - Publicación del UML 1.0 public feedback

Industrialitzación

UML 1.1

Estandarización

UML 1.0 UML Partners’ Expertise

Junio‘96 & Octubre‘96

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


20

El triángulo del éxito Notación

U.M.L.

Proceso (metodología)

Craig Larman The Unified Process


Herramienta

Rational Rose, Objecteering, Visio, etc.


21

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

Modelo de casos de uso

Modelo conceptual de los datos

Casos de uso - nivel alto - esencial

Diagramas estáticos de estructura para objetos del dominio

Diagramas de casos de uso

Modelo del comportamiento del sistema

Modelo de los estados

Diagramas de secuencia del sistema

Diagramas de estado de objetos y casos de uso

Contratos para las operaciones del sistema

37


22

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 Addison-Wesley, 1999


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


2






Diagramas estáticos de estructura de objetos del dominio








3


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


4

Objetos Objeto: Entidad que existe en el mundo real Tienen identidad y son distinguibles entre ellos


una manzana

la factura 3443

un semáforo




5

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


6

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.



7

Ejemplo TPV: Clases de objetos

TPV

Supermercado

Línea de venta

Cliente

Venta Producto

Pago

42


8

Ejemplo TPV: Atributos Un atributo es una propiedad compartida por los objetos de una clase.

Supermercado

Venta

núm-pv: Integer

dirección: String nombre: String

fecha: Date hora: Time

Línea de venta

Cliente

TPV

cantidad: Integer Pago

nombre: String telfs [1..*]: Integer tipcli: TipoCliente

Producto upc:Integer descripción [0..1]:String 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.



9

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


10

Asociaciones de orden superior a dos

Alumno

Cuatrimestre

Asignatura Se matricula



11

Multiplicidad de las asociaciones binarias Dada una instancia a de la clase A cualquiera, la multiplicidad del extremo B define cuántas instancias de B se pueden asociar con a en un momento de tiempo determinado. 1

A

1..*

A

*

A

0..*

A

0..1

A

B

2..5

A B

2, 5

A B A

1..3,7..10,15..*

B B B

B B

44


12

Multiplicidad en las asociaciones ternarias

Dadas una instancia a de A y una instancia b de B cualesquiera, la multiplicidad en el extremo C nos dice cuántas instancias de C se pueden asociar con la pareja (a,b).

A

B

0..2

C



13

Multiplicidad en las asociaciones ternarias – Ejemplos Profesor 1..2 *

Asignatura

*

Cuatrimestre

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 *

Asignatura

* Cuatrimestre

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


14

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

*

nom-esp

Equipo médico cod-equipo

*

* Tiene

Médico *

num-col

Asignado a *

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



15

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

*

Vuelo

1 destino

Ciudad

Nombre de Rol Describe el Rol de una ciudad en la asociación vuela hacia

46


16

Asociaciones recursivas Asociaciones en las que una misma clase de objetos participa más de una vez (con papeles diferentes o no).

Persona * hijo

0..2 padre Tiene

Persona *

*

Tiene por amigo



17

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

Empresa

Clase asociativa Los atributos hacen referencia a la asociación Su vida depende de la asociación

Persona

Emplea

*

nombre

nombre dirección

*

Contrato sueldo

47


18

Ejemplo de clase asociativa Participante

Proyecto

*

Asiste

*

*

*

Reunión

Empleado

Participa

No es equivalente a:

Reunión * Proyecto

*

Asistir *


Empleado


19

Generalización/Especialización Identificar elementos comunes entre los objetos definiendo relaciones de superclase (objeto general) y subclase (objeto especializado).

superclase Persona E

G {disjoint, complete}

sexo

Mujer

Hombre

discriminador - Es el nombre de la partición. Ha de ser único entre los atributos y roles de la superclase.

subclase

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


20

Generalización / Especialización 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

cantidad: Dinero tipo Pago en metálico

Venta

{disjoint, complete} Pago a crédito


Pago con talón


21

Generalización / Especializació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 Pago cantidad: Dinero

Atributos y asociaciones comunes

{disjoint, complete}

1

tipo

Pago a crédito

Pago en metálico

Pago con talón

* Identifica crédito 1 Tarjeta

Cada pago se trata diferente

Venta

asociaciones adicionales

núm-talón: Integer

49


22

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. Atributos y asociaciones comunes

Paga por 1 Pago cantidad: Dinero {disjoint, complete}

Pago en metálico Cada pago se trata diferente

1

Venta

asociaciones adicionales

tipo

Pago a crédito * Identifica crédito 1 Tarjeta


Pago con talón núm-talón: Integer


23

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. Contiene

Ruta

*

*

1..*

Usa

*

Menú

Segmento

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. *

A

A1

*

B

*

B1

* *

C1

*

C

B2 C3

C2 A2

A3

A4

50


24

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 1

Dedos 0..5

Contiene

Venta 1

0..* Contiene

Catálogo 0..1

1..*

LíneadeVenta

Especificación de Producto



25

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


26

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 Departamento

*

Está situado en

1 Ciudad

1

1

* Tiene

Empleado

La ciudad donde trabaja un empleado es la ciudad donde está situado su departamento.

* /Trabaja en



27

Multiplicidad de clase La multiplicidad de clase establece el rango de posibles cardinalidades para las instancias de una clase. Por defecto, es indefinida. En algunos casos es útil establecer una multiplicidad finita, especialmente en casos de clases que pueden tener una sola instancia (y que se denominan singleton).

- multiplicidad de clase

1 La Puntual, S.A. NIF dirección

52


28

Otras restricciones sobre asociaciones A parte de la multiplicidad, es posible expresar otras restricciones sobre las asociaciones: - Xor - Subset Xor Une diversas asociaciones ligadas a una misma clase 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

cuenta per *

{xor}

* cuenta emp 1 empresa propietaria

Empresa

Subset Indica que una asociación es un subconjunto de otra asociación * Persona

Pertenece a

* Comisión

{subset} 1

Preside

*



29

Cambiabilidad La cambiabilidad indica si los valores de un atributo o el extremo de una asociación pueden cambiar o no. Cambiable (changeable) Persona teléfono {changeable}

- opción por defecto -

Vive en * residente

* Ciudad ciudad-res {changeable}

teléfono y ciudad-res son “cambiables”

Congelado (frozen) Persona Nació en * fecha-nac {frozen} per-nacida

1 ciudad-nac {frozen}

Ciudad

fecha-nac y ciudad-nac son “congelados”

Sólo-añadir (addOnly) Persona

Ha residido en * * Ciudad residente ciudad-res {addOnly} título-aca y ciudad-res son “sólo-añadir”

título-aca {addOnly}

53


30

Generalización/Especialización - Ejemplos discriminador Pago

Pago

num-pago tipo-pago importe

{disj., inc.}

tipo-pago

{disj., inc.}

Efectivo

Efectivo

Tarjeta

cambio

cambio

num-tarjeta

Empleado nombre-empleado sueldo /dept

{disj., inc.}

num-pago importe

Trabaja en *

/dept

1

tipo-pago

Tarjeta num-tarjeta

Departamento nombre-dept: Tdept

/dept de un empleado es el nombre-dept del departamento donde trabaja el empleado.

Dirección

Producción

matr-coche

precio-hora-ext

Tdept es una enumeración de Dirección, Producción y Administración.



31

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 estado

sexo



Hombre

Soltera

Mujer

Casada

Divorc.

Viuda

54


32

Herencia múltiple Variante de generalización/especialización en la cual una subclase tiene más de una superclase. Estudiante universidad {disjoint, incomplete}

EstUPC

EstUAB

estudios {disjoint, incomplete}

EstUB

{incomplete}

Inform.

Mates

{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.


Empres.


33

Equivalencias notacionales (I) En UML: Polígono número_lados

Triángulo

Rectángulo

Pentágono

...

Pentágono

...

es equivalente a: Polígono

Triángulo

Rectángulo

¿Problema?

55


34

Equivalencias notacionales (II) En UML:

Docencia_Asignatura 1 * Clase_Teoría

1

1

* Clase_Probl

* Clase_Lab

es equivalente a: Docencia_Asignatura 1 * Clase_Teoría

* Clase_Probl

* Clase_Lab



35

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}

Empleado

Estudiante num-asignaturas

sueldo

sin valores nulos

56


36

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



37

Ejemplos (III) Empleado

Proyecto

nombre: Texto proy_emp: Proyecto

cod_proy: Texto descripción: Texto

Un atributo no puede tomar valores de una de las clases del modelo conceptual.

Este caso es una asociación.

Empleado

*

*

nombre: Texto

Trabaja en

Proyecto cod_proy: Texto descripción: Texto

57


Bibliografía • Booch, G.; Rumbaugh, J.; Jacobson, I. The Unified Modeling Language User Guide Addison-Wesley, 1999 • Rumbaugh, J.; Jacobson, I.; Booch, G. The Unified Modeling Language Reference Manual Addison-Wesley, 1999 • Larman, C. Applying UML and Patterns An Introduction to Object-Oriented Analysis and Design and the Unified Process (second edition) Prentice-Hall 2002 Cap. 10, 11, 12, 26 y 27


38

Object Constraint Language (OCL)

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


2

¿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.



3

Ejemplo Persona * director Empresa empresasDirigidas fechaNacimiento: Fecha 1 nombre: String nombre: String empleado contratador /númEmpleados: Integer apellido: String sexo: SexoVálido 1..* * /estáCasado: Boolean /estáParado: Boolean esposa /edad: Integer 0..1 esposo 0..1

Trabajo

Matrimonio l gar : String fecha: Fecha

tít lo: String fechaInicio: Fecha salario: Integer

SexoVálido se define como en meración de Hombre y M jer.

59


4

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 self.edat >= 0

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



5

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 self.director.nombre self.empleado self.empleado.esposo

-- director de la empresa -- Persona -- nombre del director -- String -- empleados de la empresa -- set(Persona) -- esposos de los empleados -- set(Persona)

60


6

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.



7

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)


8


9

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


10


11

Generalización - Especialización (herencia) CuentaCorriente num-cc: Integer entidad: String

efectúa 1

*

Transacción fecha: Date cantidad: Integer {disjoint, complete}

Navegación: •

Ingreso

Extracció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. context CuentaCorriente inv self.transacción -> select(oclIsTypeOf=Ingreso) -- ingresos de una cuenta

•

Las propiedades de las subclases se pueden ignorar. context CuentaCorriente inv self.transacción -> select(fecha.isafter(5-4-1998)) -- transacciones de una cuenta posteriores al 5-4-1998

63


12

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.



13

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


14

Operaciones estándar de tipo booleano

Operación or and or exclusivo negación igualdad desigualdad implicación if-then-else

Notación

Resultado

a or b a and b a xor b not a a=b a <> b a implies b if a then b else b’

boolean boolean boolean boolean boolean boolean boolean tipo de b ó b’



15

Operaciones estándar de tipo string Operación concatenación tamaño substring igualdad desigualdad

Notación

Resultado

string.concat(string) string.size() string.substring(int,int) string1 = string2 string1 <> string2

string integer string boolean 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


16

Operaciones estándar de tipo colección Operación

Resultado

size() count(object) includes(object) includesAll(collection)

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

excludes(object) excludesAll(collection) isEmpty() notEmpty() sum() exists(expression) forAll(expression) isUnique(expression)

elemento de la colección actual



17

Operaciones estándar (específicas) de tipo conjunto

Operación

Resultado

select(expression)

Selecciona el subconjunto de elementos del conjunto actual para los cuales expression es cierta Elimina el subconjunto de elementos del conjunto actual para los cuales expression es cierta Resultado de unir los dos conjuntos Resultado de la intersección de los dos conjuntos Resultado de unir el conjunto actual con la bag Resultado de la intersección del conjunto actual con la bag

reject(expression) union(set) intersection(set) union(bag) intersection(bag)

66


18

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


• 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


2

Modelo de análisis (especificación) Modelo de Análisis













3

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


4

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.



5

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


6

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



7

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 # R1.1 R1.2 R1.3

R1.4 R1.5 R1.6 R1.7 R2.1 R2.2

R2.3

8

Ejemplo TPV: Funciones básicas Función Registrar la venta actual - los productos comprados. Calcular el total de la venta actual, incluyendo impuestos y cálculo de “puntos de cliente”. Capturar la información de los productos comprados de un código de barras, usando un escáner o bien a partir de la entrada manual del código de barras (Universal Product Code). Descontar las cantidades vendidas del stock, cuando se confirme. Guardar información sobre les ventas realizadas. El cajero ha de identificarse al iniciar una sesión con un identificador y una clave de acceso. Mostrar la descripción y el precio de cada producto comprado. Tratar los pagos en efectivo capturando la cantidad entregada por el cliente y calculando el cambio. Tratar los pagos con tarjeta de crédito capturando el número de la 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. Registrar los pagos con tarjeta con tal que puedan ser facturados.


Categoría evident evident evident

hidden hidden evident evident evident evident

hidden


9

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

Proveedor

Hacer ofertas

Director comercial

71


10

Ejemplo TPV: Entorno del sistema supermercado tradicional Compra de productos CAJERO

Devolver producto

CLIENTE

Iniciar sesión supermercado electrónico Compra de productos CLIENTE Devolver Producto



11

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 Respuesta del sistema

Acciones de los actores

1. El caso de uso comienza cuando un Cliente llega a la caja con los productos para comprar. 2. El Cajero indica que comienza una nueva venta 3. Registra el inicio de una nueva venta. 5. Determina el precio del producto y añade 4. El Cajero registra el identificador de su información a la cuenta. cada producto. Si hay más de una unidad del producto el Cajero puede introducir la cantidad. 7. Calcula y muestra el total de la cuenta. 6. Al acabar la entrada de productos el Cajero lo indica. (continúa)

72


12

Acciones de los actores 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 recibido. 13. El Cajero deposita el dinero recibido en la caja y extrae el cambio. El Cajero da el cambio y el recibo al Cliente. 14. El Cliente se va con los productos comprados.

Respuesta del sistema

11. Calcula y muestra el cambio al Cliente. Imprime un recibo. 12. Registra la venta que se acaba de hacer.

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.



13

Casos de uso esenciales vs casos de uso reales

Esencial (muy abstracto)

Real (muy concreto)

Independiente interfaces y tecnología

Esencial Acción del actor 1. El cliente se identifica. 3. Etc...

Respuesta del sistema 2. El sistema valida la identificación. 4. Etc...

Real Acción del actor 1. El cliente inserta la tarjeta. 3. Teclea el PIN por teclado. 5. Etc...

Respuesta del sistema 2. Solicita el PIN. 4. Muestra el menú de opciones. 6. Etc...

73


14

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. Curso típico de eventos Acciones de los actores


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



15

Estructuración de casos de uso: Secciones Section: Pagar en efectivo Curso típico de eventos Respuesta del sistema

Acciones de los actores 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 recibido. 4. El Cajero deposita el dinero recibido y extrae el cambio. El Cajero da el cambio al Cliente.

3. Calcula y muestra el cambio al Cliente.

Cursos alternativos • 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


16

Estructuración de casos de uso: Relación <> <>: 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

Compra de productos

<> Pagar con tarjeta

Cliente caso de uso que se efectúa realmente Compra de productos + Pagar con tarjeta

Cliente

Cajero



17

Ejemplo TPV: <> Cajero

<>

Comprar productos

Pagar en efectivo

Cliente

<> Pagar con tarjeta

<> <> Devolver producto Acciones de los actores

Servicio de autorización de crédito

Contabilidad Respuesta del sistema

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

75


18

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.



19

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 Addison-Wesley, 2001.

•

Jacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process Addison-Wesley, 1999. (Cap. 6,7)

76


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

2














3


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

78

4


“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”.



5


•

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


6

Diagramas de secuencia del sistema •

Objetivos:

•

Punto de partida:

– – –

•

Identificar los eventos y las operaciones del sistema. 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.



7


Diagramas de secuencia del 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

8


Ejemplo: Comprar producto sistema como caja negra

actor

:Cajero

:Sistema inicioVenta(pv) :venta

*

entrarProd(venta,prod,cant)

finVenta(venta) :importe pago(venta,importePago) :cambio

evento del sistema invoca operación


9


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

10


Representación de iteraciones de eventos

:Actor

:Sistema

evento1() iteración de un únic event

* *

iteración de una secuencia de event s

evento2() evento3() evento4()


11


Diagramas de secuencia: <> •

Los casos de uso definidos mediante <> 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


<> pagar con tarjeta o en efectivo

*

entrarProd(venta,prod,cant) finVenta(venta) :importe

Parte específica: pagar con tarjeta :Gestión Tarjetas

:Cajero

:Sistema pagTarjetaCrédito(núm-t,fecha-cad)

:Sist. Autor. Crédito solicitudAprob(núm-t)

tratarRespTarjeta(respuesta) añadeAprobación(respuesta)

82

12


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.


13


Operaciones del sistema • •

Las operaciones del sistema se agrupan como operaciones del tipo especial “sistema”. En cambio, las operaciones no se asignan a objetos concretos durante la etapa de especificación. Ejemplo: SISTEMA inicioVenta(pv) :venta entrarProd(venta,prod,cant) finVenta(venta) :importe pago(venta,importePago): cambio

83

14


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

El actor “cliente” no interactúa directamente con el sistema, sólo lo hace el “cajero”.

*

entrarProd

finVenta

pago

frontera del sistema



15

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


16

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.


17


Ejemplo: Esquema conceptual de partida

PuntoDeVenta num-pv

*

1 tiene

Venta 1..* LíneaDeVenta 1 día consta de cantidad hora * /importe corresponde a 1

Producto código precio descripción

RI textuales: 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


18


19

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


20

21


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

22


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 adicionales de las operaciones :Cajero

:Sistema

Mediante información adicional en el esquema conceptual

:Caixer

:Sistema

inicioVenta(pv) inicioVenta(pv)

:venta

*


*

entrarProd(pv, prod,cant)

finVenta(venta)

Venta día hora /importe

finVenta(pv)

:importe

:importe pago(venta,importePago) pago(pv,importePago)

:cambio

:cambio

Restricción implícita: El valor del argumento ‘venta’ es el mismo en todos los eventos del diagrama.


VentaEnCurso


23

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


24

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


25


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

26


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-X

:Sistema inicioVenta(pv): venta

*

:Sistema

hacer-Venta(infoVenta)

entrarProd(venta, prod, cant)

finVenta(venta): importe

infoVenta = pv + {prod + cant} + importePago

pago(venta, importePago): cambio

•

Ambos diagramas suponen la misma entrada de información al sistema.

•

Los dos diagramas de secuencia pueden ser correctos, según las circunstancias.


27


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 cod-emp sueldo R.I. textual: dos empleados no pueden tener el mismo código.

Nombre: AltaEmpleado (cod-emp, sueldo) Responsabilidades: dar de alta al empleado Excepciones: Precondiciones: no existe Empleado con cod-emp Postcondiciones: 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 – ...


28

29


Redundancia - Esq. conceptual y contratos (I) Persona nom-p

•

*

tiene

0..3

Coche matr año

Significado habitual:

:Persona

:Sistema CompraCoche(nom-p,matr)

•

Significado alternativo:

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

Nombre: CompraCoche (nom-p,matr) Responsabilidades: compra de un coche Excepciones: … (las que se deducen de las prec.) Precondiciones: - existe Persona p con nom-p - existe Coche c con matr - p no tiene c Postcondiciones: - Si p tiene ya 3 coches entonces eliminar la asociación entre p y el coche c’ de más antigüedad - creación de una asociación tiene entre p y c Salida: -

91


30

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.


31


Redundancia - Esq. conceptual y contratos (III) Persona nombre dirección

*

Caso de uso: Añadir-Persona-1 :Persona

:Sistema

AltaPersona(nombre,dirección)

habla

1..*

Idioma nombre núm-parlantes

Caso de uso: Añadir-Persona-2 :Persona

:Sistema

AltaPersona(nombre,dirección)

* HablaIdioma(nombre, idioma)

¡No permite añadir nunca una persona! Nombre: AltaPersona(nombre,dirección) … Precondiciones: Postcondiciones: - creación de un objeto Persona con el nombre y la dirección especificados Salida:

Nombre: HablaIdioma(nombre,idioma) … Precondiciones: - existe Idioma con nombre=idioma - no existe la asociación ‘habla’ entre nombre e idioma Postcondiciones: - creación de una asociación ‘habla’ entre la Persona con nombre=nombre y el Idioma Salida:

92

32


Redundancia - Diagramas de secuencia y contratos Los diagramas de secuencia definen un orden de invocación de las operaciones. Las operaciones no han de incorporar información para garantizar que este orden se cumpla. :Cajero


*

entrarProd(venta, prod, cant)

finVenta(venta): importe

pago(venta, importePago): cambio

Nombre: pago (venta, importePago): cambio … Precondiciones: - existe Venta “venta” - la Venta “venta” ha finalizado Postcondiciones: ... Salida:


son redundantes

33


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. 13, 15)

•

Rumbaugh, J.; Jacobson, I.; Booch, G. The Unified Modeling Language Reference Manual Addison-Wesley, 1999.

•

Booch, G.; Rumbaugh, J.; Jacobson, I. The Unified Modeling Language User Guide Addison-Wesley, 1999.

93


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

2














3


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

4


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

Nombre Estado

Entry/acción do/actividad exit/acción event/acción


5


Cambio de estado civil de una persona Persona

Soltera

nacimiento


estadocivil Casada

Separada

Divorciada

Soltera

Viuda boda

Casada

divorcio

Divorciada

boda

divorcio

boda

separación

Separada

enviudar

Viuda enviudar

96

6


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.


7


Diagrama de estados del caso de uso “comprar productos” entrarProd

Esperando venta

inicioVenta

entrarProd

Esperando producto

Introduciendo productos finVenta

Esperando pago

pagoEnMetálico

tratarRespTarjeta

Autorizando pago

PagTarjetaCrédito

97

8


Diagrama de estados de un teléfono estado inicial estado

libre

descolgar

activo

colgar

transición

evento


9


Acciones y condiciones de una transición

condición

libre

descolgar [abonadoVálido]

activo

/marcarTono

colgar

acción

98

10


Estados imbricados

descolgar [abonadoVálido] /marcarTono

Activo Emetiendo Tono Marcar

libre

Charlando

dígito dígito colgar

conectado

Marcando

Conectando completo


11


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.

•

Booch, G.; Rumbaugh, J.; Jacobson, I. The Unified Modeling Language User Guide Addison-Wesley, 1999

•

Powel Douglass, B. Real-Time UML. Addison-Wesley, 1998.

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


2

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 elaboración

Construcción


Implantación


3

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 Elaboración

Construcción

Implantació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


4

Etapa de construcción Plan y Elaboración

Ciclo de desarrollo 1

Refinar plan

Sincr. artefactos

Construcción


Análisis

Diseño

Implantación

...

Construcción

Prueba

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.



5

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.


Refinar plan

...


Análisis

Sincr. artefactos

Diseño

Construcción

1. Definición de los casos de uso esenciales

2. Refinar los diagramas

3. Refinar el modelo conceptual

4. Refinar el glosario

5. Definir diagramas de secuencia

6. Definir contratos de operación

Prueba

7. Definir diagramas de estado

103


6

Etapa de construcción: Ciclos de desarrollo (II)


Refinar plan

...


Sincr. artefactos

Análisis

Diseño

Construcción

Prueba

1. Definición de los casos de uso reales

2. Definir informes e interfaces de usuario

3. Refinar la arquitectura del sistema

4. Definir los diagramas de interacción

5. Definir el diagrama de clases de diseño

6. Definir el esquema de la base de datos



7

Ordenar y priorizar casos de uso Ciclo de desarrollo

Ciclo de desarrollo

Caso de uso A Versión Simplificada ... ...

Caso de uso A Versión Completa ... ...

¿Cómo priorizar? 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.

Ciclo de desarrollo Caso de uso B ... ... ...

Caso de uso C ... ... ...

104


8

Ejemplo: Compra de productos •

En un primer ciclo de desarrollo puede no interesarnos distinguir entre las diversas formas posibles de pago. :Cajero


*


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.



9

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


Interacción común a todo tipo de pago

*


Interacción específica del pago en metálico :Cajero

:Sistema pago(venta,importePago) :cambio

105


10

Interacción específica del pago con tarjeta :Gestión Tarjetas

:Cajero

:Sistema pagTarjCrédito(núm-t,fecha-cad)

:Sist. Autor. Crédito solicitudAprov(núm-t) tratarRespTarj(respuesta)

añadixAprovación(respuesta)

Nombre: pagTarjCrédito (núm-t, fecha-cad) Responsabilidades: pagar con la tarjeta de crédito Excepciones: Precondiciones: Postcondiciones: - Creación de un nuevo PagoConTarjeta pct - Nueva asociación entre pct y la venta actual - ... Salida: - Se envía una solicitud de aprovación al servicio de autorización de crédito

Nombre: tratarRespTarj (respuesta) Responsabilidades: responder a la respuesta de aprovación recibida Excepciones: Precondiciones: Postcondiciones: - ... Salida: - Se envía una aprovación al sistema de Gestión de Tarjetas para que la registre



11

Bibliografía

•

Larman, C. Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design. Prentice Hall, 1998. (Cap. 13, 32)

•

Jacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process. Addison-Wesley, 1999.

106



Colección de ejercicios

1 Conceptos básicos

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.

4.

Indica la diferencia entre requisitos de un sistema y requisitos del software.

5.

Resume las cuatro estrategias para determinar los requisitos.

109

6. Define y describe brevemente tres requisitos no funcionales, de diferente tipo, relativos al proyecto realizado durante el curso. 7. Una de las propiedades deseables de las especificaciones es que sean “trazables” (traceability). Define esta propiedad. 8. Una de las propiedades deseables de las especificaciones es que sean verificables. Define 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.

A

*

r

x

0..2

B

A

y

x

*

r

C

z

z

M1

B y

0..1

C

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

0..2

- Restricciones de clave: A --> x, B --> y - x, y y z son atributos univaluados M2


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)

Informático

ProyectoSw

participa-en

Informático

ProyectoSw

asignar Etapa

Participación

asignada

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 correcta. Persona habitante

vive vivienda

*

1..*

{subset}

propietario

posee

* propiedad

* Piso

(a) No puede ser que una persona posea un piso y viva en otro. (b) Una persona puede vivir 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 * precio día, hora * 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):

111


Caso de uso: Reserva de asientos para una sesión de una obra Actores: Cliente (iniciador), Empleado Curso típico de eventos: Acciones de los actores 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 disponibilidad y registra la reserva.

112 8. El cliente se va contento -.

24. Justifica por qué los casos de uso correspondientes a la etapa de 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.

Libro ISBN autor

Restricciones textuales: - ISBN es clave de Libro - un libro no puede tener dos ejemplares con el mismo núm

Ejemplar tiene núm 1 3..* estado

obtenerLibro(x): l borraEjemplar(l, n)

obtenerLibro(x): l pre (1) Libro l con ISBN = x post --sal l borrar

borraEjemplar(l, n) pre (2) l.ISBN = x (3) el libro l tiene al menos 4 ejemplares (4) Ejemplar e con núm = n (5) e.estado = defectuoso post borrar la instancia (l, e) de la asociación tiene; 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.

113

2 Modelo conceptual de datos en UML

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/corequisitos 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

E

C

I D

G

H

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

116

Por ejemplo, el aparato A requiere 5 unidades del aparato B, 8 unidades del aparato C y 4 unidades de la materia prima D (la cual es suministrada por el proveedor P1). El aparato B consta de 10 unidades de la materia prima E (del proveedor P2). El aparato C consta de una unidad del aparato F, el cual consta de 5 unidades de la meteria prima G (del proveedor P1).

En la 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 “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 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 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

117


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.

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 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 claramente.

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.

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 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 claramente. 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 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.

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 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 claramente. 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.

119


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.

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 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 claramente. 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. 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.

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 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 claramente. 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

121


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.

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 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 claramente. 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.

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 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 claramente. 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.

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 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 claramente. 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. Por ejemplo, Juan está abonado a la compañía, tiene el documento de identidad 111 y vive en la C/ Matadero.

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 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 claramente. 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

125


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 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 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 claramente. 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.

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 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 claramente. 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.

127


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

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

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 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 claramente. 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 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).

129


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.

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. 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ª).

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.

131


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.

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

132

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 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-202) 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.

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, 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. 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: [email protected]) y Rosa (email: [email protected]). 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

133


normales y las inscripciones de estudiantes. Para las inscripciones de estudiantes hay que registrar el nombre de los estudios que está realizando la persona inscrita en el momento de la 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: [email protected]) 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 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. 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 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, 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. 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-102003. 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.

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, 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. 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.

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, 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. 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.

138

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 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. 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, 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. 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-32003 hasta el 10-3-2003 y a Ana otra vez desde el 9-3-2003 hasta el 10-3-2003. A la parcela 2 de la feria Construmat’03 se ha asignado a Nuria (titulación delineante y población Reus) desde el 6-3-2003 haste el 10-32003. 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: [email protected]) se ha inscrito a Informat’03. El pago ha sido en efectivo y se le ha aplicado un descuento del 10%. Gustavo (e-mail: [email protected] 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.

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, 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.

139


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.

140

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

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, 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.

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.

Posee

propietario

1..*

poseído

*

propiedad

Persona

Coche *

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 *

vive vivienda

1..* propietario

{subset}

posee

* propiedad

* Piso

3. Dado el modelo conceptual de la figura siguiente, expresa en OCL las restricciones textuales r1) y r2).

141


Empleado código * vive-en

*

1..*

trabaja-en

1

Ciudad nombre

1

Departamento número * situado-en

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.

142

Músico nombre * es-experto-en * Instrumento

*

*

interpreta

* *

ObraMusical

Interpretación

toca

RT: La clave de músico es nombre.

4 Modelo de casos de uso y modelo del comportamiento

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 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 0, 3

ASIGNATURA código nombre

GRUPO Hace-clase

*

0..1 número

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.

143


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.

144

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 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:

POBLACIÓN nombre-p habitantes

0.. 2

(origen)

Hacen-tramo 0.. 2

CARRETERA *

(destino)

TRAMO distancia duración

De-la *

código-c

RUTA * código-ruta

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-detramos-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 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 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:

145


CALLE nombre-c

1

1..* Con

FINCA

* Alquilada-por

núm-f ALQUILER piso precio tipo tipo TEMPORAL fecha-fin

* CLIENTE dni nombre

{Disj., Comp.} INDEFINIDO

aumento

R.I. textuales: - Claves de las clases no asociativas: (Calle,nombre-c), (Cliente, dni). - Una calle no puede tener dos fincas con el mismo

El sistema ha de permitir efectuar las funcionalidades siguientes: alta-calle, alta-alquileres-finca, bajaalquileres y listado-de-alquileres-con-aumento-elevado.

146

Cuando se da de alta una calle, se indica el nombre de la calle y, para cada finca de aquella calle, su número de finca. Esta operación es efectuada por los empleados de la agencia, a petición de la Directora de la agencia. Cuando el Responsable de Alquileres da de alta todos los alquileres de una finca, indica él mismo al sistema el nombre de la calle, el 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. 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 alta calle. x Modelo del comportamiento del sistema: Todos los diagramas de secuencia. Contratos de las 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:

JORNADA

Se-inscribe PERSONA dni nombre-p

1

Núm-jorn Pob-inicio * Pob-fin

Con

1..* *

CONTROL núm-cont lugar

Pasa-por

* PARTICIPACIÓN

*

CONTROL PARTICIPANTE

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

147


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 alta jornada. x Modelo del comportamiento del sistema: Todos los diagramas de secuencia. Contratos de las 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

148

código-asig nombre créditos

ESTUDIANTE GRUPO 1 Tiene * número * Se-matric * dni nombre capacidad teléfono MATRÍCULA

PARCIAL núm-parcial

*

NOTA nota

Corresponde *

tipo EVALUACIÓN CONTINUA

{disjoint, complete} EVALUACIÓN NO CONTINUA

nota-final

R.I. textuales: - Claves de las clases no asociativas: (Asignatura, código-asig), (Estudiante, dni), (Parcial, númparcial). - 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 interacción necesaria para llevar a cabo esta funcionalidad requiera más de un evento. 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. 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 (para las funcionalidades especificadas). Especificación del caso de uso del alta de grupos de una asignatura. x Modelo del comportamiento del sistema: Todos los diagramas de secuencia. Contratos de las operaciones correspondientes a la asignación de notas parciales y a la consulta de estudiantes con 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 Tiene

siglas año precio

1

nom-sesión * duración

*

Ponencia Se-presenta 1

Asiste-a

Inscripción tipo


Ins. Normal

Ins.Estudiante

profesión

universidad

código título

0..4

Es-autor *

* 1..*

Persona nombre

149


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.

150

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 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 de casos de uso: Diagrama de casos de uso (para las funcionalidades especificadas). 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:


Fecha

Persona 1

dni nombre

fecha

*

/Tiene-presupuestados

*

Ciudad

inicio

0.. 3

Quiere-viajar

{incomplete}

Viaje-planeado

Mar


*

Presupuestado precio

Reservado avance

nombre

1 Confirmado *

De-la Se-aloja-en

* Hotel 0..1

nombre

R.I. textuales: - Claves clases no asociativas: (Persona, dni); (Fecha, fecha); (Ciudad, nombre). - Una Ciudad no puede tener 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x Modelo de casos de uso: Diagrama de casos de uso (para las funcionalidades especificadas). 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 nombre_jub año_nac

*

Visita núm nombre fecha_vis *

152

Viaje * núm_viaje tipo_transp

Se-inscribe

*

* Parar 0..1

Incluye 1

Parada fecha_fin

Fecha fecha_in Localidad nombre_loc núm_hab

R.I. textuales: - Claves de clases no asociativas: (Jubilado: nombre_jub), (Viaje: núm_viaje), (Fecha: fecha_in), (Localidad: nombre_loc), (Visita: núm). - Las paradas de un viaje no se pueden solapar temporalmente. - La fecha_fin de una parada ha de ser posterior a su fecha_inicio. - La fecha_visita de una visita ha de estar entre la fecha_inicio y la fecha_fin de la parada que incluye la visita. El sistema que se debe desarrollar no ha de dar de alta los datos de los jubilados ni de sus inscripciones, dado que existe otro sistema encargado de hacerlo. El sistema ha de permitir efectuar entre otras las funcionalidades siguientes: alta-viaje, cambio-fechas-parada y consulta-viajeslocalidad. Cuando el administrativo del club de jubilados quiere dar de alta un viaje, indica su 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML):


x Modelo de casos de uso: Diagrama de casos de uso (para las funcionalidades especificadas). x Modelo del comportamiento del sistema: Diagramas de secuencia y contratos de las operaciones 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 código: String fecha-ini: Fecha Empleado

1 director

Dirige

Consta-de

*

Etapa

0.. 3

3

nombre: String precio-h: Entero

edp-dir

* dni: String * 0..10 Participa nombre: String edp-part participante plus: Entero Participación

153 EtapaDelProy

núm-h: Entero nombre


Especificación

Implementación

Diseño

*

Usa

Material *

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. 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. x Modelo de casos de uso: Diagrama de casos de uso (de las funcionalidades especificadas). x Modelo del comportamiento del sistema: Todos los diagramas de secuencia y contratos de todas las operaciones que aparecen. Expresad las salidas con la ayuda del lenguaje OCL. 11. Considerad el caso de la escuela que hace actividades extraescolares del primer parcial de la asignatura. Suponed que una parte del modelo conceptual en UML de este sistema es el siguiente:

Actividad

154

nombre:string Edificio nombre: string dirección: string * teléfono: entero

*

Actividad programada

se_hace_en *

se_programa

*

inicio:date

Curso año1: año año2:año

Horario hora_inicio:hora hora_fin: hora

Dia_Semana Actividad en_edificio

*

tiene_horario

*

nombre:string

1 *

Grupo de actividad nombre: string profe: string

matricula

*

Estudiante *

código: entero 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. 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. 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

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 Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x

Modelo conceptual de datos Modelo de casos de uso: diagrama de casos de uso y especificación de los casos de uso Modelo del comportamiento del sistema: diagramas de secuencia y contratos de las operaciones Modelo de estados: diagrama de estados para objetos y casos de uso

2. Considerad un sistema sencillo de reserva y 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x



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.

158

Cuando se produce el evento de Cambio de perro, nos comunican el identificador de la persona que nos devuelve el perro (no es necesario que nos indiquen el perro que devuelve). El cambio 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x


4. Considera un sistema que registra las compras que hacen los clientes, y que las factura. El sistema ha de responder a tres eventos: nueva compra, hacer facturas y fin de 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x


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. 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x


159


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.

160

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 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x


7. El presidente de un comité de programa de un congreso internacional quiere construir un sistema software que le ayude a controlar las ponencias enviadas al congreso, las personas que 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x


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.

161


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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML):

162 x x x x


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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): x x x x


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 Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): 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. 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 interacción necesaria para llevar a cabo esta funcionalidad requiera más de un evento. 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): 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.

165


12. Considerad una biblioteca que está interesada en desarrollar un sistema software para gestionar los ejemplares de los libros de que dispone y los 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).

166

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 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): 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 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 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.).

167


El sueldo global de un empleado es la suma de sueldos de los departamentos donde trabaja. El sueldo de un empleado en un departamento es igual al sueldo base de aquel empleado en el departamento 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.

168

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 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): 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 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 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 interacción necesaria para llevar a cabo esta funcionalidad requiera más de un evento. 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.

169


Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): 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). x Modelo del comportamiento del sistema: Diagramas de secuencia y contratos de las operaciones 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.

170

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 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. Os pedimos que hagáis los modelos siguientes (todos ellos mediante la notación UML): 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 “hacerreserva”. x Modelo del comportamiento del sistema: Diagramas de secuencia correspondientes a todos los casos de uso. Contratos de las operaciones correspondientes a “asignar-reservas” y “listadohabitaciones-disponibles”. Expresad las salidas con la ayuda del lenguaje OCL.

171

Especificacion de Sistemas de Software en UML

Recommend Documents