proyecto videoclib

77
Metodología para el Análisis de Requisitos de Sistemas Software Versión 2.1 Amador Durán Toro Beatriz Bernárdez Jiménez Departamento de Lenguajes y Sistemas Informáticos Facultad de Informática y Estadística Sevilla, noviembre de 2000 Este trabajo ha sido financiado por Ministerio de Educación y Ciencia de España a través del proyecto "MENHIR"de la CICYT TIC 97–0593–C05

Upload: saul-velasco-garcia

Post on 11-Mar-2015

903 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: proyecto videoclib

Metodología para el Análisisde Requisitos de Sistemas Software

Versión 2.1

Amador Durán Toro

Beatriz Bernárdez Jiménez

Departamento de Lenguajes y Sistemas Informáticos

Facultad de Informática y Estadística

Sevilla, noviembre de 2000

Este trabajo ha sido financiado por Ministerio de Educación y Ciencia de Españaa través del proyecto "MENHIR"de la CICYT TIC 97–0593–C05

Page 2: proyecto videoclib
Page 3: proyecto videoclib

Lista de cambiosNúm. Fecha Descripción Autor/es

0 14/12/1998 Versión 1.0 A. Durán y B.Bernárdez

1 29/11/1999 En la versión 2.0 se han introducido numerosos cambios, los prin-cipales son los siguientes:

A. Durán

El título cambia de Norma para el Análisis de Requisitos de un SistemaSoftware a Metodología para el Análisis de Requisitos de Sistemas Soft-wareLa primera sección del documento pasa de denominarse Objetivo yalcance a Objetivo de la metodologíaLa tarea 3 pasa a denominarse Desarrollar prototipos en lugar de De-sarrollar y validar prototipos. Los aspectos de validación se contem-plarán en una metodología aparteSe ha cambiado el contenido de las secciones Introducción y Objeti-vos del sistema del DASSe ha contemplado la posibilidad de no incluir los requisitos nofuncionales en la matriz de rastreabilidadSe han eliminado las referencias a las operaciones de clases y aso-ciaciones para pasar a una especificación más declarativaSe han añadido los campos correspondientes a la plantilla de esce-nario para poder especificar las pre y postcondiciones en lenguajenatural además de hacerlo en OCLSe ha reescrito la mayor parte del ejemplo de aplicación de la me-todología

3 29/11/1999 Versión 2.0 A. Durán4 27/11/2000 En la versión 2.1 se han corregido algunos errores ortográficos.

Queda pendiente la sincronización con la versión realizada en latesis doctoral de A. Durán [Durán 2000].

A. Durán

5 27/11/2000 Versión 2.1 A. Durán

Page 4: proyecto videoclib
Page 5: proyecto videoclib

Índice General

1 Objetivo de la metodología 1

2 Tareas recomendadas 12.1 Tarea 1: Desarrollar el modelo estático del sistema . . . . . . 2

2.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 22.1.3 Productos internos . . . . . . . . . . . . . . . . . . . . 22.1.4 Productos entregables . . . . . . . . . . . . . . . . . . 22.1.5 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Tarea 2: Desarrollar el modelo de comportamiento del sistema 32.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 32.2.3 Productos internos . . . . . . . . . . . . . . . . . . . . 32.2.4 Productos entregables . . . . . . . . . . . . . . . . . . 32.2.5 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Tarea 3: Desarrollar prototipos . . . . . . . . . . . . . . . . . 42.3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 42.3.3 Productos internos . . . . . . . . . . . . . . . . . . . . 42.3.4 Productos entregables . . . . . . . . . . . . . . . . . . 42.3.5 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Productos entregables 43.1 Documento de análisis del sistema . . . . . . . . . . . . . . . 5

3.1.1 Portada . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.2 Lista de cambios . . . . . . . . . . . . . . . . . . . . . 53.1.3 Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.4 Listas de figuras y tablas . . . . . . . . . . . . . . . . . 83.1.5 Introducción . . . . . . . . . . . . . . . . . . . . . . . . 8

i

Page 6: proyecto videoclib

3.1.6 Diagramas de clases de análisis . . . . . . . . . . . . . 83.1.7 Catálogo de clases y asociaciones de análisis . . . . . 83.1.8 Clase X . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.9 Asociación Y entre A, B, . . . , C . . . . . . . . . . . . . . 93.1.10 Catálogo de escenarios de análisis . . . . . . . . . . . 103.1.11 Escenario Z . . . . . . . . . . . . . . . . . . . . . . . . 103.1.12 Matriz de rastreabilidad . . . . . . . . . . . . . . . . . 103.1.13 Glosario de términos . . . . . . . . . . . . . . . . . . . 103.1.14 Apéndices . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Técnicas 114.1 Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Plantillas para especificación de clases de análisis . . . . . . 11

4.2.1 Plantilla de clase . . . . . . . . . . . . . . . . . . . . . 124.2.2 Plantillas de atributos . . . . . . . . . . . . . . . . . . 134.2.3 Plantillas de enlaces . . . . . . . . . . . . . . . . . . . 144.2.4 Plantilla de invariante . . . . . . . . . . . . . . . . . . 16

4.3 Plantillas para especificación de asociaciones entre clases deanálisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3.1 Plantilla de asociación . . . . . . . . . . . . . . . . . . 174.3.2 Plantilla de rol . . . . . . . . . . . . . . . . . . . . . . . 18

4.4 Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . 194.5 Plantilla de escenario . . . . . . . . . . . . . . . . . . . . . . . 194.6 Diagrama de traza de eventos . . . . . . . . . . . . . . . . . . 204.7 Construcción de prototipos . . . . . . . . . . . . . . . . . . . 21

A Ejemplo: gestión de un vídeo–club 23A.1 Diagramas de clases de análisis . . . . . . . . . . . . . . . . . 23A.2 Clases y asociaciones de análisis . . . . . . . . . . . . . . . . 26

A.2.1 Paquete Películas y Cintas . . . . . . . . . . . . . . . . 26A.2.2 Clase Actor . . . . . . . . . . . . . . . . . . . . . . . . 26

ii

Page 7: proyecto videoclib

A.2.3 Clase ArtistaCine . . . . . . . . . . . . . . . . . . . . . 27A.2.4 Clase Cinta . . . . . . . . . . . . . . . . . . . . . . . . 28A.2.5 Clase Director . . . . . . . . . . . . . . . . . . . . . . . 30A.2.6 Clase Película . . . . . . . . . . . . . . . . . . . . . . . 31A.2.7 Clase Productora . . . . . . . . . . . . . . . . . . . . . 33A.2.8 Asociación actúaEn entre Actor y Película . . . . . . . 34A.2.9 Asociación contiene entre Cinta y Película . . . . . . 35A.2.10 Asociación dirige entre Director y Película . . . . . . 36A.2.11 Asociación produce entre Productora y Película . . . 37A.2.12 Asociación tieneAlquilada entre Película y Cinta . . . 38A.2.13 Asociación tieneDisponible entre Película y Cinta . . 39A.2.14 Paquete Socios y Alquileres . . . . . . . . . . . . . . . 40A.2.15 Clase Alquiler . . . . . . . . . . . . . . . . . . . . . . . 40A.2.16 Clase Cargo . . . . . . . . . . . . . . . . . . . . . . . . 43A.2.17 Clase CargoAlquiler . . . . . . . . . . . . . . . . . . . 44A.2.18 Clase CargoMulta . . . . . . . . . . . . . . . . . . . . 45A.2.19 Clase Cuenta . . . . . . . . . . . . . . . . . . . . . . . 46A.2.20 Clase Ingreso . . . . . . . . . . . . . . . . . . . . . . . 47A.2.21 Clase Movimiento . . . . . . . . . . . . . . . . . . . . 48A.2.22 Clase Socio . . . . . . . . . . . . . . . . . . . . . . . . 49A.2.23 Asociación corresponde entre CargoAlquiler y Al-

quiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A.2.24 Asociación esObjetoDe entre Cinta y Alquiler . . . . 53A.2.25 Asociación esObjetoActualmenteDe entre Cinta y Al-

quiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.2.26 Asociación motivadoPor entre CargoMulta y Alquiler 55A.2.27 Asociación realiza entre Socio y Alquiler . . . . . . . 56A.2.28 Asociación realizaActualmente entre Socio y Alquiler 57A.2.29 Asociación tiene entre Socio y Cuenta . . . . . . . . . 58A.2.30 Asociación tieneAlquilada entre Socio y Cinta . . . . 59

A.3 Escenarios de análisis . . . . . . . . . . . . . . . . . . . . . . . 60

iii

Page 8: proyecto videoclib

A.3.1 Escenario AltaDeSocio . . . . . . . . . . . . . . . . . . 60A.3.2 Escenario AlquilerCinta . . . . . . . . . . . . . . . . . 63A.3.3 Escenario ConsultarPelícula . . . . . . . . . . . . . . . 66

A.4 Cambios en los requisitos originales . . . . . . . . . . . . . . 67

iv

Page 9: proyecto videoclib

Índice de Figuras

1 Estructura del Documento de Análisis del Sistema . . . . . . 62 Portada del Documento de Análisis del Sistema . . . . . . . 73 Lista de cambios del Documento de Análisis del Sistema . . 74 Matriz de rastreabilidad del Documento de Análisis del Sis-

tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Plantilla de descripción de clase . . . . . . . . . . . . . . . . . 126 Plantilla de descripción de atributo constante . . . . . . . . . 147 Plantilla de descripción de atributo variable . . . . . . . . . . 148 Plantilla de descripción de atributo derivado . . . . . . . . . 149 Plantilla de descripción de enlace primitivo . . . . . . . . . . 1510 Plantilla de descripción de enlace derivado . . . . . . . . . . 1511 Asociaciones 1 : n con restricción subset . . . . . . . . . . . . 1612 Plantilla de descripción de invariante de clase . . . . . . . . 1613 Plantilla de descripción de asociación . . . . . . . . . . . . . 1714 Plantilla de descripción de rol . . . . . . . . . . . . . . . . . . 1815 Plantilla de descripción de escenario . . . . . . . . . . . . . . 1916 Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . 2417 Diagrama de clases del paquete Películas y Cintas . . . . . . . 2418 Diagrama de clases del paquete Alquileres y Socios . . . . . . 2519 Diagrama de estados de la clase Cinta . . . . . . . . . . . . . 2920 Diagrama de traza de eventos del escenario AltaDeSocio . . . 6121 Interfaz de usuario del escenario AltaDeSocio . . . . . . . . . 6222 Diagrama de traza de eventos del escenario AlquilerCinta . . 6423 Interfaz de usuario del escenario AlquilerCinta . . . . . . . . 6524 Interfaz de usuario del escenario ConsultarPelícula . . . . . . 66

v

Page 10: proyecto videoclib

vi

Page 11: proyecto videoclib

Objetivo de la metodología 1

1 Objetivo de la metodología

El objetivo de esta metodología es la definición de las tareas a realizar,los productos a obtener y las técnicas a emplear durante la actividad deanálisis de requisitos de la fase de ingeniería de requisitos del ciclo de vida dela ingeniería del software.

En esta metodología se distinguen dos tipos de productos: los produc-tos entregables y los productos no entregables o internos. Los productos en-tregables son aquellos que se entregan oficialmente al cliente como partedel desarrollo en fechas previamente acordadas, mientras que los no entre-gables son productos internos al desarrollo que no se entregan al cliente.

El único producto entregable definido en esta metodología es el Docu-mento de Análisis del Sistema (DAS), definido en la sección 3.1, pág. 5.

La estructura de este documento es la siguiente: en la sección 2 se des-criben las tareas recomendadas para obtener el DAS, en la sección 3 sedefinen los productos entregables, en este caso el DAS, y por último, en lasección 4 se describen las técnicas recomendadas para obtener los produc-tos. También se incluye como apéndice un ejemplo de aplicación de estametodología.

2 Tareas recomendadas

Las tareas recomendadas para obtener los productos resultantes de la faseson:

Tarea 1: Desarrollar el modelo estático del sistema

Tarea 2: Desarrollar el modelo de comportamiento del sistema

Tarea 3: Desarrollar prototipos

El orden recomendado de realización para estas tareas es: 1, 2 y 3, aun-que las tareas 1 y 2 pueden realizarse simultáneamente y el tipo de sistemapuede determinar un orden u otro. La tarea 3 es opcional, dependiendodel ciclo de vida adoptado en el desarrollo.

En las siguientes secciones se describen cada una de las tareas mencio-nadas.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 12: proyecto videoclib

2 Metodología para el Análisis de Requisitos de Sistemas Software

2.1 Tarea 1: Desarrollar el modelo estático del sistema

2.1.1 Objetivos

• Modelar los aspectos estáticos del sistema

• Analizar los requisitos de almacenamiento de información

2.1.2 Descripción

En esta tarea se debe obtener el modelo estático del sistema a partir de losrequisitos de almacenamiento de información obtenidos en la fase ante-rior. Se deben identificar las clases de objetos que forman el sistema, asícomo sus asociaciones, agregaciones y clasificaciones.

2.1.3 Productos internos

No hay productos internos en esta tarea.

2.1.4 Productos entregables

• Diagramas de clases de análisis como parte del DAS (ver sección3.1.6, pág. 8)

• Catálogo de clases y asociaciones de análisis como parte del DAS(ver sección 3.1.7, pág. 8)

2.1.5 Técnicas

• Diagrama de clases (ver sección 4.1, pág. 11)

• Plantillas para clases de análisis (ver sección 4.2, pág. 11)

• Plantillas para asociaciones de análisis (ver sección 4.3, pág. 17)

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 13: proyecto videoclib

Tarea 2: Desarrollar el modelo de comportamiento del sistema 3

2.2 Tarea 2: Desarrollar el modelo de comportamiento delsistema

2.2.1 Objetivos

• Modelar los aspectos de comportamiento del sistema

• Analizar los requisitos funcionales

2.2.2 Descripción

En esta tarea se debe obtener el modelo de comportamiento del sistema apartir de los requisitos funcionales obtenidos en la fase anterior. Se debenespecificar tanto los escenarios como los estados y transiciones de las cla-ses de objetos identificadas en la tarea anterior que tengan un dinamismosignificativo.

2.2.3 Productos internos

No hay productos internos en esta tarea.

2.2.4 Productos entregables

• Catálogo de clases y asociaciones de análisis como parte del DAS(ver sección 3.1.7, pág. 8)

• Catálogo de escenarios de análisis como parte del DAS (ver sección3.1.10, pág. 10)

2.2.5 Técnicas

• Plantilla para escenarios de análisis (ver sección 4.5, pág. 19)

• Diagrama de traza de eventos (ver sección 4.6, pág. 20)

• Diagrama de estados (ver sección 4.4, pág. 19)

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 14: proyecto videoclib

4 Metodología para el Análisis de Requisitos de Sistemas Software

2.3 Tarea 3: Desarrollar prototipos

2.3.1 Objetivos

• Definir la interfaz de usuario

• Comprobar propiedades del sistema

2.3.2 Descripción

En esta tarea se deben desarrollar prototipos que permitan al cliente teneruna idea más clara del sistema a desarrollar e identificar nuevos requisitosque hayan permanecidos ocultos hasta el momento. Lo más habitual esque el prototipo sea desechable, es decir, que una vez que se haya utilizadono se desarrolle tomando su código como base.

2.3.3 Productos internos

• Prototipo del sistema

2.3.4 Productos entregables

• Catálogo de escenarios de análisis como parte del DAS (ver sección3.1.10, pág. 10)

2.3.5 Técnicas

• Prototipado de sistemas software (ver sección 4.7, pág. 21).

3 Productos entregables

El único producto entregable que se contempla en esta norma es el Docu-mento de Análisis del Sistema (DAS).

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 15: proyecto videoclib

Documento de análisis del sistema 5

3.1 Documento de análisis del sistema

La estructura del DAS puede verse en la figura 1. En las siguientes seccio-nes se describe con detalle cada sección del DAS.

3.1.1 Portada

La portada del DAS debe tener el formato que puede verse en la figura 2.Los elementos que deben aparecer son los siguientes:

• Nombre del proyecto: el nombre del proyecto al que pertenece elDAS.

• Versión: la versión del DAS que se entrega al cliente. La versión secompone de dos números X e Y . El primero indica la versión, y sedebe incrementar cada vez que se hace una nueva entrega formal alcliente. Cuando se incremente el primer número, el segundo debevolver a comenzar en cero. El segundo número indica cambios den-tro de la misma versión aún no entregada, y se debe incrementar ca-da vez que se imprima una versión con cambios respecto a la últimaque se imprimió y que no se vaya a entregar formalmente todavía.Este tipo de versiones pueden ser internas al equipo de desarrollo oser entregadas al cliente a título orientativo.

• Fecha: fecha de la publicación de la versión.

• Equipo de desarrollo: nombre de la empresa o equipo de desarrollo.

• Cliente: nombre del cliente, normalmente otra empresa.

3.1.2 Lista de cambios

El documento debe incluir una lista de cambios en la que se especifiquen,para cada versión del documento, los cambios producidos en el mismocon un formato similar al que puede verse en la figura 3. Para cada cambiorealizado se debe incluir el número de orden, la fecha, una descripción ylos autores.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 16: proyecto videoclib

6 Metodología para el Análisis de Requisitos de Sistemas Software

PortadaLista de cambiosÍndiceLista de figurasLista de tablas

1 Introducción

2 Diagramas de clases de análisis

3 Catálogo de clases y asociaciones de análisis

3.1 Clase X3.1.1 Descripción clase X3.1.2 Atributos clase X3.1.3 Enlaces clase X3.1.4 Invariante clase X3.1.5 Diagrama de estados clase X [opcional]

3.2 Asociación Y entre A,B,. . . ,C3.2.1 Descripción asociación Y(A,B,. . . ,C)3.2.2 Roles asociación Y(A,B,. . . ,C)3.2.3 Atributos asociación Y(A,B,. . . ,C) [opcional]3.2.4 Enlaces asociación Y(A,B,. . . ,C) [opcional]3.2.5 Invariante asociación Y(A,B,. . . ,C) [opcional]3.2.6 Diagrama de estados asociación Y(A,B,. . . ,C) [opcional]

4 Catálogo de escenarios de análisis

4.1 Escenario Z4.1.1 Descripción escenario Z4.1.2 Diagrama de traza de eventos escenario Z [opcional]4.1.3 Interfaz de usuario escenario Z [opcional]

5 Matriz de rastreabilidad

6 Glosario de términos [opcional]

Apéndices [opcional]

Figura 1: Estructura del Documento de Análisis del Sistema

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 17: proyecto videoclib

Documento de análisis del sistema 7

Proyecto nombre del proyecto

Documento deAnálisis del Sistema

Versión X.YFecha fecha

Realizado por equipo de desarrolloRealizado para cliente

Figura 2: Portada del Documento de Análisis del Sistema

Núm. Fecha Descripción Autor/es0 fecha0 Versión x.y autor01 fecha1 descripción cambio1 autor1

......

......

n fechan descripción cambion autorn

Figura 3: Lista de cambios del Documento de Análisis del Sistema

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 18: proyecto videoclib

8 Metodología para el Análisis de Requisitos de Sistemas Software

3.1.3 Índice

El índice del DAS debe indicar la página en la que comienza cada sección,subsección o apartado del documento. En la medida de lo posible, se san-grarán las entradas del índice para ayudar a comprender la estructura deldocumento.

3.1.4 Listas de figuras y tablas

El DAS deberá incluir listas de las figuras y tablas que aparezcan en el mis-mo. Dichas listas serán dos índices que indicarán el número, la descripcióny la página en que aparece cada figura o tabla del DAS. El formato paradichas listas será similar al empleado en este mismo documento.

3.1.5 Introducción

Esta sección debe contener una descripción breve de las principales ca-racterísticas del sistema software que se va a desarrollar, la situación ac-tual que genera la necesidad del nuevo desarrollo, la problemática que seacomete, y cualquier otra consideración que sitúe al posible lector en elcontexto oportuno para comprender el resto del documento.

3.1.6 Diagramas de clases de análisis

Este apartado debe contener los diagramas de clases (ver sección 4.1, pág.11) del modelo del sistema construido durante el análisis. Para sistemascomplejos puede ser conveniente agrupar los diagramas en paquetes, talcomo se describe en [Booch et al. 1999].

3.1.7 Catálogo de clases y asociaciones de análisis

Esta sección se divide en los siguientes apartados en los que se describenlas clases y asociaciones identificadas durante el análisis. Si en los diagra-mas de clases se han agrupado las clases y asociaciones en paquetes, elcatálogo de clases y asociaciones deberá reflejar también dicha división.

Tanto las clases como las asociaciones deben estar ordenadas alfabéti-camente por su nombre dentro de cada paquete.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 19: proyecto videoclib

Documento de análisis del sistema 9

3.1.8 Clase X

Este apartado, que se repite para cada clase X identificada en el análisis,debe tener el siguiente contenido:

• Descripción: descripción de la clase mediante la plantilla de clase(ver sección 4.2.1, pág. 12).

• Atributos: descripción, ordenada alfabéticamente, de los atributosde la clase mediante las plantillas de atributo (ver sección 4.2.2, pág.13).

• Enlaces: descripción, ordenada alfabéticamente, de los enlaces de laclase mediante las plantillas de enlace (ver sección 4.2.3, pág. 14).

• Invariante: descripción de la invariante de la clase mediante la plan-tilla de invariante (ver sección 4.2.4, pág. 16).

• Diagrama de estados: diagrama de estados correspondiente a la cla-se, si se ha identificado alguno (ver sección 4.4, pág. 19).

3.1.9 Asociación Y entre A, B, . . . , C

Este apartado, que se repite para cada asociación Y entre las clases A, B,. . . , C identificada en el análisis, debe tener el siguiente contenido, muysimilar al de las clases:

• Descripción: descripción de la asociación mediante la plantilla deasociación (ver sección 4.3.1, pág. 17).

• Roles: descripción, ordenada alfabéticamente, de los roles que jue-gan las clases participantes en la asociación mediante la plantilla derol (ver sección 4.3.2, pág. 18).

• El resto del contenido de este apartado es opcional y su descripcióncoincide con el de la descripción de clases:

– Atributos– Enlaces– Invariante– Diagrama de estados

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 20: proyecto videoclib

10 Metodología para el Análisis de Requisitos de Sistemas Software

3.1.10 Catálogo de escenarios de análisis

Esta sección se divide en los siguientes apartados en los que se describenlos escenarios identificados durante el análisis.

3.1.11 Escenario Z

Este apartado, que se repite para cada escenario Z identificado en el análi-sis, debe tener el siguiente contenido:

• Descripción: descripción del escenario mediante la plantilla de es-cenario (ver sección 4.5, pág. 19).

• Diagrama de traza de eventos: diagrama de traza de eventos co-rrespondiente al escenario, si se considera oportuno (ver sección 4.6,pág. 20).

• Interfaz de usuario: interfaz de usuario asociada al escenario, en elcaso de que se haya construido y validado algún prototipo (ver sec-ción 4.7, pág. 21). Se deberán mostrar la/s pantalla/s y/o informesasociados al escenario así como su descripción.

3.1.12 Matriz de rastreabilidad

Este apartado debe contener una matriz requisito–elemento de análisis, deforma que para cada requisito identificado en el Documento de Requisitosdel Sistema se pueda conocer con qué clases, asociaciones y escenarios es-tá asociado. El formato de la matriz de rastreabilidad puede verse en lafigura 4.

Dado que los requisitos no funcionales no suelen recogerse en el mo-delo del sistema, si se considera oportuno pueden eliminarse de la matrizde rastreabilidad.

3.1.13 Glosario de términos

Esta sección, que se incluirá si se considera oportuno, deberá contener unalista ordenada alfabéticamente de los términos específicos del dominio delproblema, acrónimos y abreviaturas que aparezcan en el documento y quese considere que su significado deba ser aclarado. Cada término deberáacompañarse de su significado.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 21: proyecto videoclib

Técnicas 11

RI–01 RI–02 . . . RF–01 RF–02 . . . RNF–01 RNF–02 . . .Clase X1 • •Clase X2 •

. . .Asoc. Y1 •Asoc. Y2 • •

. . .Esce. Z1 •Esce. Z2 •

. . .

Figura 4: Matriz de rastreabilidad del Documento de Análisis del Sistema

3.1.14 Apéndices

Los apéndices se usarán para proporcionar información adicional a la do-cumentación obligatoria del documento. Sólo deben aparecer si se consi-deran oportunos y se identificarán con letras ordenadas alfabéticamente:A, B, C, etc.

4 Técnicas

A continuación, se describen algunas de las técnicas que se proponen enesta metodología para obtener los productos de las tareas que se han des-crito.

4.1 Diagrama de clases

Los diagramas de clases permiten expresar gráficamente aspectos estáti-cos del modelo de un sistema. En esta metodología se propone que losdiagramas de clases usen la notación UML [Booch et al. 1999].

4.2 Plantillas para especificación de clases de análisis

En esta norma se propone el siguiente conjunto de plantillas para especi-ficar las clases identificadas en el análisis de los requisitos:

• Plantilla de clase: una por clase

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 22: proyecto videoclib

12 Metodología para el Análisis de Requisitos de Sistemas Software

• Plantilla de atributo: una por cada atributo de cada clase. Hay tresversiones distintas de está plantilla, según el atributo sea constante,variable o derivado.

• Plantilla de enlace: una por cada enlace de cada clase.

• Plantilla de invariante: una por clase

En las siguientes secciones se describen cada una de estas plantillas.Todas ellas tienen un apartado de comentarios cuya descripción es la si-guiente:

• Comentarios: en este apartado se deben recoger otras consideracio-nes que no se hayan especificado en otros apartados de la plantilla.

4.2.1 Plantilla de clase

El formato de la plantilla para describir las clases de análisis puede verseen la figura 5. Los apartados específicos de esta plantilla son los siguientes:

Clase <nombre clase>Descripción Esta clase { abstracta, concreta } representa [concepto que repre-

senta la clase]Requisitos asociados <Requisitos asociados>Superclases <Superclases directas de la clase>Subclases <Subclases directas de la clase> ({ disjuntas, solapadas }, {com-

pletas, incompletas})Componentes Nombre Tipo Mult.

<nombre componente> <tipo OCL> <multiplicidad>. . . . . . . . .

Comentarios <Comentarios adicionales sobre la clase en formato libre>

Figura 5: Plantilla de descripción de clase

• Nombre clase: cada clase se identifica por un nombre único en elmodelo que podrá utilizarse como referencia en cualquier parte dela documentación. Se recomienda que el nombre sea un sustantivo osimilar en singular.

• Descripción: en este apartado se indica si la clase es abstracta o con-creta y se describe el concepto que representa la clase. En este con-texto, se entenderá que una clase es abstracta si los conjuntos de ins-tancias o extensiones de sus subclases forman una partición sobre laextensión de la clase que se está describiendo.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 23: proyecto videoclib

Plantillas para especificación de clases de análisis 13

• Requisitos asociados: en este apartado se indican los requisitos delDocumento de Requisitos del Sistema (DRS) a los que está asociada laclase, es decir, aquellos requisitos que justifican la existencia de laclase.

• Superclases: en este apartado se indican las superclases directas dela clase.

• Subclases: en este apartado se indican las subclases directas de laclase, especificando si son disjuntas o solapadas y si la clasificaciónes o no completa [Booch et al. 1999].

• Componentes: en este apartado se indican los componentes de laclase, es decir aquellas clases agregadas por la clase. Para cada com-ponente se incluyen los siguientes apartados:

– Nombre: nombre del enlace por el que el objeto agregado acce-de a sus componentes.

– Tipo: tipo OCL del enlace por el que el objeto agregado accedea sus componentes.

– Multiplicidad: multiplicidad de la agregación.

4.2.2 Plantillas de atributos

Dentro de los atributos de una clase se distingue entre atributos constan-tes, variables y derivados. Los formatos de las plantillas para describirestos tres tipos de atributos pueden verse en las figuras 6, 7 y 8. Los apar-tados comunes de las tres plantillas son los siguientes:

• Nombre atributo: cada atributo se identifica por un nombre únicodentro de una clase que podrá utilizarse como referencia en cual-quier parte de la documentación. Se recomienda que el nombre seaun sustantivo o similar. El nombre del atributo deberá ir precedidodel nombre de la clase con el formato clase::atributo.

• Descripción: en este apartado se proporciona una breve descripcióndel atributo.

Los apartados comunes de las plantillas de atributos constantes y va-riables son los siguientes:

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 24: proyecto videoclib

14 Metodología para el Análisis de Requisitos de Sistemas Software

Atributo constante <nombre clase>::<nombre atributo>Descripción <Descripción del atributo>Tipo <Tipo OCL del atributo>Comentarios <Comentarios adicionales sobre el atributo en formato libre>

Figura 6: Plantilla de descripción de atributo constante

Atributo variable <nombre clase>::<nombre atributo>Descripción <Descripción del atributo>Tipo <Tipo OCL del atributo>Valor inicial <Valor inicial del atributo>Comentarios <Comentarios adicionales sobre el atributo en formato libre>

Figura 7: Plantilla de descripción de atributo variable

• Tipo: en este apartado se indica el tipo OCL del atributo.

Los apartados específicos para los atributos variables son los siguien-tes:

• Valor inicial: en este apartado se indica el valor inicial del atributo.

Atributo derivado <nombre clase>::<nombre atributo>Descripción <Descripción del atributo>Expresión <Expresión OCL asociada al atributo>Comentarios <Comentarios adicionales sobre el atributo en formato libre>

Figura 8: Plantilla de descripción de atributo derivado

Los apartados específicos para los atributos derivados son los siguien-tes:

• Expresión: en este apartado se indica la expresión OCL asociada a laevaluación del atributo.

4.2.3 Plantillas de enlaces

Dentro de los enlaces de una clase se distingue entre enlaces primitivosy derivados. Los formatos de las plantillas para describir estos dos tiposde enlaces pueden verse en las figuras 9 y 10. Los apartados comunes deambas plantillas son los siguientes:

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 25: proyecto videoclib

Plantillas para especificación de clases de análisis 15

Enlace <nombre clase>::<nombre enlace>Descripción <Descripción del enlace>Tipo <Tipo OCL del enlace>Asociación <Asociación de la que proviene el enlace>Comentarios <Comentarios adicionales sobre el enlace en formato libre>

Figura 9: Plantilla de descripción de enlace primitivo

Enlace derivado <nombre clase>::<nombre enlace>Descripción <Descripción del enlace>Expresíón <Expresión OCL asociada al enlace>Asociación <Asociación de la que proviene el enlace>Comentarios <Comentarios adicionales sobre el enlace en formato libre>

Figura 10: Plantilla de descripción de enlace derivado

• Nombre enlace: cada enlace se identifica por un nombre único den-tro de una clase, que podrá utilizarse como referencia en cualquierparte de la documentación. Dicho nombre deberá coincidir con elnombre del rol que juegue la clase en la asociación de la que pro-viene el enlace. Se recomienda que el nombre sea un sustantivo osimilar. El nombre del enlace deberá ir precedido del nombre de laclase con el formato clase::enlace.

• Descripción: en este apartado se proporciona una breve descripcióndel enlace.

• Asociación: en este apartado se indica la asociación de la que pro-viene el enlace.

Los apartados específicos para los enlaces primitivos son los siguientes:

• Tipo: en este apartado se indica el tipo OCL del enlace. Dicho tipodeberá coincidir con el tipo del rol del mismo nombre que el enlaceen la asociación de la que proviene el enlace.

Los apartados específicos para los enlaces derivados son los siguientes:

• Expresión: en este apartado se indica la expresión OCL asociada a laevaluación del enlace.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 26: proyecto videoclib

16 Metodología para el Análisis de Requisitos de Sistemas Software

4.2.3.1 Nota sobre la necesidad de especificación de enlaces

Cuando entre dos clases se establezcan dos (o más) asociaciones demultiplicidad 1 : n con una restricción de subset entre ellas no será necesa-rio especificar dos enlaces distintos para los enlaces correspondientes a losroles con cardinalidad 1. Por ejemplo, en la figura 11, la clase B no tienedos enlaces distintos a la clase A, sólo uno, ya que por la restricción desubset ambos enlaces deben ser la misma instancia de A.

A

rolB2

{subset}

B

rolB1 * *

Figura 11: Asociaciones 1 : n con restricción subset

4.2.4 Plantilla de invariante

El formato de la plantilla para describir el invariante de las clases de análi-sis puede verse en la figura 12. Los apartados específicos de esta plantillason los siguientes:

Invariante <nombre clase>Descripción <Descripción del invariante>Expresión <Expresión OCL del invariante>Comentarios <Comentarios adicionales sobre el invariante en formato libre>

Figura 12: Plantilla de descripción de invariante de clase

• Descripción: en este apartado se proporciona una descripción enlenguaje natural del invariante para facilitar la compresión de la ex-presión OCL del apartado siguiente.

• Expresión: en este apartado se indica la expresión OCL que forma elinvariante de la clase, asumiendo el contexto de la clase [IBM 1997,pág. 3].

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 27: proyecto videoclib

Plantillas para especificación de asociaciones entre clases de análisis 17

4.3 Plantillas para especificación de asociaciones entre cla-ses de análisis

En esta metodología se propone el siguiente conjunto de plantillas paraespecificar las asociaciones identificadas en el análisis:

• Plantilla de asociación: una por asociación

• Plantilla de rol: una por cada rol de cada asociación.

Además, dada la similitud entre clase y asociación (sobre todo aso-ciación como clase), pueden usarse las siguientes plantillas de clase paraespecificar una asociación cuando se considere oportuno:

• Plantilla de atributo: una por cada atributo de la asociación, pudien-do ser el atributo de tipo constante, variable o derivado.

• Plantilla de enlace: una por cada enlace de la asociación, excluyendolos enlaces intrínsecos a la propia asociación.

• Plantilla de invariante: una por asociación.

En las siguientes secciones se describen las plantillas específicas de aso-ciación. Todas tienen un apartado de comentarios cuya descripción es lamisma que para las plantillas de clase (ver sección 4.2, pág. 11).

4.3.1 Plantilla de asociación

El formato de la plantilla para describir las asociaciones entre clases deanálisis puede verse en la figura 13. Los apartados específicos de estaplantilla son los siguientes:

Asociación <nombre asociación> entre <participantes>Descripción Esta asociación {derivada} representa [concepto que representa

la asociación]Requisitos asociados <Requisitos asociados a la asociación>Comentarios <Comentarios adicionales sobre la asociación en formato libre>

Figura 13: Plantilla de descripción de asociación

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 28: proyecto videoclib

18 Metodología para el Análisis de Requisitos de Sistemas Software

• Nombre asociación y participantes: cada asociación se identificapor una combinación de nombre de asociación y de nombres de par-ticipantes única en el modelo, que podrá utilizarse como referenciaen cualquier parte de la documentación. Se recomienda que el nom-bre sea una forma verbal o similar, de forma que tenga sentido alconstruir una frase con el nombre de la asociación y los participan-tes. Por ejemplo la asociación Trabaja en entre Empleado y Empresa.Para hacer referencia a la asociación se utilizará el formato:

asociación(A, B, ..., C )

por ejemplo: trabajaEn( Empleado, Empresa )

• Descripción: en este apartado se describe el concepto que representala asociación y si se trata de una asociación derivada o no.

• Requisitos asociados: en este apartado se indican los requisitos delDocumento de Requisitos del Sistema (DRS) a los que está asociada laasociación, es decir, aquellos requisitos que justifican la existencia dela asociación.

4.3.2 Plantilla de rol

El formato de la plantilla para describir los roles de las asociaciones entreclases de análisis puede verse en la figura 14. Los apartados específicos deesta plantilla son los siguientes:

Rol <nombre clase> juega rol <nombre rol> en <nombre asociación>Descripción <Descripción del rol>Tipo <Tipo OCL del rol>Multiplicidad <Multiplicidad del rol>Comentarios <Comentarios adicionales sobre el rol en formato libre>

Figura 14: Plantilla de descripción de rol

• Nombre rol: cada rol se identifica por una combinación de nombrede asociación y de nombre de rol única en el modelo que podrá utili-zarse como referencia en cualquier parte de la documentación, siem-pre que no haya posibilidad de ambigüedades [IBM 1997, pág. 8].Se recomienda que el nombre sea un sustantivo o similar. El nombredel rol deberá ir precedido del nombre de asociación con el formatoasociación(A, B, . . . , C)::rol.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 29: proyecto videoclib

Diagrama de estados 19

• Descripción: en este apartado se proporciona una breve descripcióndel rol.

• Tipo: en este apartado se especifica el tipo OCL del rol.

• Multiplicidad: en este apartado se indica la multiplicidad del rol.

4.4 Diagrama de estados

Los diagramas de estados permiten expresar aspectos de comportamientoa nivel de una clase de objetos. En esta metodología se propone que losdiagramas de estados se realicen utilizando la notación UML [Booch et al.1999].

4.5 Plantilla de escenario

En esta metodología se propone la plantilla que puede verse en la figura 15para especificar los escenarios identificados en el análisis. Los apartadosespecíficos de esta plantilla son los siguientes:

Escenario <nombre escenario>Descripción <Descripción del escenario>Requisitos asociados <Requisitos asociados>Parámetros par1 : Tipo1 -- descripción par1

par2 : Tipo2 -- descripción par2...parN : TipoN -- descripción parN

Precondición <Descripción de la precondición en lenguaje natural>Precondición (OCL) <Expresión OCL de la precondición>Precondición <Descripción de la postcondición en lenguaje natural>Postcondición (OCL) <Expresión OCL de la postcondición>Comentarios <Comentarios adicionales sobre el escenario en formato libre>

Figura 15: Plantilla de descripción de escenario

• Nombre escenario: cada escenario se identifica por un nombre únicoen el modelo que podrá utilizarse como referencia en cualquier partede la documentación. Se recomienda que el nombre sea una formaverbal o similar.

• Descripción: en este apartado se proporciona una breve descripcióndel escenario.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 30: proyecto videoclib

20 Metodología para el Análisis de Requisitos de Sistemas Software

• Requisitos asociados: en este apartado se indican los requisitos delDocumento de Requisitos del Sistema (DRS) a los que está asociado elescenario, es decir, aquellos requisitos que justifican la existencia delescenario.

• Parámetros: en este apartado se deben enumerar los parámetros delescenario siguiendo la sintáxis de OCL con el formato

nombre : tipo -- descripción

siendo:

– nombre: nombre del parámetro.

– tipo: tipo OCL del parámetro

– descripción: descripción del parámetro.

• Precondición: en este apartado se describen en lenguaje natural lasprecondiciones del escenario.

• Precondición (OCL): en este apartado se indica la expresión OCLcorrespondiente a la precondición del escenario [IBM 1997], definidapreviamente en lenguaje natural.

• Postcondición: en este apartado se describen en lenguaje natural laspostcondiciones del escenario.

• Postcondición (OCL): en este apartado se indica la expresión OCLcorrespondiente a la postcondición del escenario [IBM 1997], defini-da previamente en lenguaje natural.

4.6 Diagrama de traza de eventos

Los diagramas de traza de eventos permiten expresar aspectos de compor-tamiento a nivel de varias clases de objetos o a nivel de todo el sistema. Enesta metodología se propone que los diagramas de traza de eventos utili-cen la notación UML [Booch et al. 1999], en la que se denominan diagramasde secuencia.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 31: proyecto videoclib

Construcción de prototipos 21

4.7 Construcción de prototipos

Esta metodología no establece ninguna restricción para la elaboración deprototipos. Se podrán utilizar herramientas de desarrollo rápido, prototi-pos en papel o cualquier otra técnica que se considere oportuna.

Referencias

[Booch et al. 1999] G. Booch, J. Rumbaugh, y I. Jacobson. The Unified Mo-deling Language User Guide. Addison–Wesley, 1999.

[Durán 2000] A. Durán. Un Entorno Metodológico de Ingeniería de Requisitospara Sistemas de Información. Tesis doctoral, Universidad de Sevilla, 2000.

[IBM 1997] IBM Corporation. Object Constraint Language Specification, 1.1edición, Septiembre 1997. Disponible en http://www.rational.com .

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 32: proyecto videoclib

22 Metodología para el Análisis de Requisitos de Sistemas Software

Está página está intencionalmente en blanco

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 33: proyecto videoclib

Ejemplo: gestión de un vídeo–club 23

A Ejemplo: gestión de un vídeo–club

En este apéndice se ofrecen algunos ejemplos de aplicación de las técnicaspropuestas en esta norma. Para ello se ha continuado con el ejemplo dela gestión de un pequeño vídeo–club que se utilizó en la Metodología parala Elicitación de Requisitos de Sistemas Software, aunque no se han incluidotodos los escenarios correspondientes a los casos de uso identificados enel ejemplo citado.

Aunque no están definidos en la actual versión de OCL [IBM 1997],se han asumido los tipos básicos Date y Time para representar fechasy horas respectivamente. Se ha asumido también que se ha definido laoperación menor o igual sobre ambos tipos (<=) y que Date.today yTime.now devuelven la fecha y hora actual respectivamente.

Para simplificar las expresiones de las postcondiciones de las operacio-nes en las que se crean o destruyen objetos se han asumido dos propie-dades derivadas aplicables a cualquier tipo de objetos, new y dead , quecorresponden a las siguientes expresiones para cualquier tipo T:

T.new = T.allInstances - [email protected] = T.allInstances@pre - T.allInstances

y que representan, respectivamente, el conjunto de objetos creados duran-te la operación y el conjunto de objetos destruidos durante la operación.

En los escenarios especificados se ha asumido que se ha desarrolladoun prototipo de la interfaz de usuario del sistema.

También se incluyen aquellos cambios que sería necesario hacer enlos requisitos identificados inicialmente como resultado del análisis de losmismos.

A.1 Diagramas de clases de análisis

Los diagramas de clases correspondientes al modelo, y realizados utilizan-do la notación UML [Booch et al. 1999], pueden verse en las figuras 17 y18. Para mayor claridad se han divido en dos paquetes que pueden verseen la figura 16.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 34: proyecto videoclib

24 Metodología para el Análisis de Requisitos de Sistemas Software

<<subsistema>>

Películas yCintas

<<subsistema>>

Socios yAlquileres

Figura 16: Diagrama de paquetes

3URGXFWRUD

nombre : String

$UWLVWD&LQH

{abstracto}

nombre : String

$FWRU 'LUHFWRU

3HOtFXOD

título : Stringaño : Integertema : enum { Infantil, Acción, Ciencia-Ficción, Terror, Adultos }duración : Time

DFW~D(Q GLULJHSURGXFH

protagonista

&LQWD

FRQWLHQH�WLHQH$OTXLODGD�WLHQH'LVSRQLEOH

{subset}{subset}

disponible alquiladanúmero : Integer/ estáAlquilada

{solapada, completa}

1

1

1 1 1

Figura 17: Diagrama de clases del paquete Películas y Cintas

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 35: proyecto videoclib

Diagramas de clases de análisis 25

Socio

número : Integerdni : Stringnombre : StringfechaNacimiento : Datesexo : enum { Hombre, Mujer }fechaAlta : Datedirección : Stringteléfonos : Set( Integer )

tiene

Alquiler

fechaAlquiler : DatehoraAlquiler : TimefechaDevolución : DatehoraDevolución : TimeestáDevuelto : Boolean = false

Cinta(Películas y Cintas)

/tieneAlquilada

realiza

{ordered}

esObjetoDe

{ordered}

/esObjetoActualmenteDe

alquilerActual{subset}

{subset}

alquilerActual

/realizaActualmente

*0..1

*

*

0..1

*

1

11

1

1 1

fecha : Dateimporte : Integer

Movimiento{abstracto}

{ordered}

Ingreso

estáPendiente : Boolean = true

Cargo{abstracto}

CargoMulta CargoAlquiler

*

{disjunta, completa}

Cuenta

/ saldo

{disjunta, completa}

AlquilermotivadoPor corresponde

1

11

0..1

Figura 18: Diagrama de clases del paquete Alquileres y Socios

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 36: proyecto videoclib

26 Metodología para el Análisis de Requisitos de Sistemas Software

A.2 Clases y asociaciones de análisis

A.2.1 Paquete Películas y Cintas

Este paquete contiene las clases y asociaciones relacionadas con las pelícu-las y cintas del vídeo–club.

A.2.2 Clase Actor

A.2.2.1 Descripción clase Actor

Clase ActorDescripción Esta clase concreta representa a los actores protagonistas de

las películas del vídeo–clubRequisitos asociados • RI–01 Información sobre películasSuperclases ArtistaCineSubclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.2.2 Atributos clase ActorNo se han identificado atributos para esta clase.

A.2.2.3 Enlaces clase Actor

Enlace Actor::películaDescripción Conjunto de películas en las que el actor es protagonistaTipo Set( Película )Asociación actúaEn(Actor,Película)Comentarios Ninguno

A.2.2.4 Invariante clase ActorNo se han identificado restricciones para esta clase.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 37: proyecto videoclib

Clases y asociaciones de análisis 27

A.2.3 Clase ArtistaCine

A.2.3.1 Descripción clase ArtistaCine

Clase ArtistaCineDescripción Esta clase abstracta representa a los artistas de cine (actores y

directores) de las películas del vídeo–clubRequisitos asociados • RI–01 Información sobre películasSuperclases –Subclases Actor, Director (solapadas)Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Puede haber artistas de cine que sean actores y directores a la

vez, por ejemplo Woody Allen

A.2.3.2 Atributos clase ArtistaCine

Atributo constante ArtistaCine::nombreDescripción Nombre del artista de cineTipo StringComentarios Ninguno

A.2.3.3 Enlaces clase ArtistaCineEsta clase no participa en ninguna asociación.

A.2.3.4 Invariante clase ArtistaCine

Invariante ArtistaCineDescripción • No puede haber dos artistas de cine con el mismo nombre (nombre

es clave)Expresión ArtistaCine.allInstances->forall( a1, a2 |

(a1 <> a2) = (a1.nombre <> a2.nombre) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 38: proyecto videoclib

28 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.4 Clase Cinta

A.2.4.1 Descripción clase Cinta

Clase CintaDescripción Esta clase concreta representa a las cintas actualmente en po-

der del vídeo–clubRequisitos asociados • RI–01 Información sobre películasSuperclases –Subclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.4.2 Atributos clase Cinta

Atributo derivado Cinta::estáAlquiladaDescripción Indica si la cinta está alquilada actualmenteExpresión self .alquilerActual->notEmptyComentarios Ninguno

Atributo constante Cinta::númeroDescripción Número identificativo de la cintaTipo IntegerComentarios Se debe generar automáticamente; es imprescindible para

que el empleado del vídeo–club localice las cintas en los es-tantes

A.2.4.3 Enlaces clase Cinta

Enlace Cinta::alquilerDescripción Alquileres de los que ha sido o es objeto la cintaTipo Sequence( Alquiler )Asociación esObjetoDe(Cinta,Alquiler)Comentarios Los alquileres están ordenados por fecha de alquiler

Enlace derivado Cinta::alquilerActualDescripción Alquiler en curso de la cintaExpresión self .alquiler->select( a | not a.estáDevuelto )Asociación esObjetoActualmenteDe(Cinta,Alquiler)Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 39: proyecto videoclib

Clases y asociaciones de análisis 29

Enlace Cinta::películaDescripción Película contenida en la cintaTipo PelículaAsociación contiene(Cinta, Película)Comentarios Ninguno

Enlace derivado Cinta::socioDescripción Socio que tiene alquilada la cinta actualmenteExpresión self .alquilerActual.socioAsociación tieneAlquilada(Socio,Cinta)Comentarios Ninguno

A.2.4.4 Invariante clase Cinta

Invariante CintaDescripción • No puede haber dos cintas con el mismo número (número es clave)

• Los alquileres deben estar ordenados por fecha de alquiler• No hay alquileres duplicados• La cinta sólo puede tener pendiente un alquiler a la vez

Expresión Cinta.allInstances->forAll( c1, c2 |( c1 <> c2 ) = ( c1.número <> c2.número ) )

andSequence{1.. self .alquiler->size - 1}->forAll( i : Integer |

self .alquiler->at( i ).fechaAlquiler <=self .alquiler->at( i + 1 ).fechaAlquiler )

andself .alquiler->size = self .alquiler->asSet->sizeandself .alquilerActual->size <= 1

Comentarios Ninguno

A.2.4.5 Diagrama de estados clase Cinta

Disponible AlquiladaAdquirirCinta

AlquilarCinta

DevolverCintaDestruirCinta

Figura 19: Diagrama de estados de la clase Cinta

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 40: proyecto videoclib

30 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.5 Clase Director

A.2.5.1 Descripción clase Director

Clase DirectorDescripción Esta clase concreta representa a los directores de las películas

del vídeo–clubRequisitos asociados • RI–01 Información sobre películasSuperclases ArtistaCineSubclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.5.2 Atributos clase DirectorNo se han identificado atributos para esta clase.

A.2.5.3 Enlaces clase Director

Enlace Director::películaDescripción Conjunto de películas dirigidas por el directorTipo Set( Película )Asociación dirige(Director,Película)Comentarios Ninguno

A.2.5.4 Invariante clase DirectorNo se han identificado restricciones para esta clase.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 41: proyecto videoclib

Clases y asociaciones de análisis 31

A.2.6 Clase Película

A.2.6.1 Descripción clase Película

Clase PelículaDescripción Esta clase concreta representa a las películas que han estado

o están disponibles en el vídeo–clubRequisitos asociados • RI–01 Información sobre películasSuperclases –Subclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.6.2 Atributos clase Película

Atributo constante Película::añoDescripción Año en el que se estrenó la películaTipo IntegerComentarios Ninguno

Atributo constante Película::duraciónDescripción Duración de la películaTipo TimeComentarios Ninguno

Atributo constante Película::temaDescripción Tema de la películaTipo enum { Infantil, Acción, Ciencia-Ficción,

Terror, Adultos }Comentarios Ninguno

Atributo constante Película::títuloDescripción Título de la películaTipo StringComentarios Ninguno

A.2.6.3 Enlaces clase Película

Enlace derivado Película::alquiladaDescripción Cintas de la película actualmente alquiladasExpresión self .cinta->select( c | c.estáAlquilada )Asociación tieneAlquilada(Película,Cinta)Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 42: proyecto videoclib

32 Metodología para el Análisis de Requisitos de Sistemas Software

Enlace Película::cintaDescripción Cintas de la película de las que dispone actualmente el vídeo–clubTipo Set( Cinta )Asociación contiene(Cinta,Película)Comentarios Ninguno

Enlace Película::directorDescripción Director de la películaTipo DirectorAsociación dirige(Director,Película)Comentarios Ninguno

Enlace derivado Película::disponibleDescripción Cintas de la película actualmente disponibles (no alquiladas)Expresión self .cinta->select( c | not c.estáAlquilada )Asociación tieneDisponible(Película,Cinta)Comentarios Ninguno

Enlace Película::productoraDescripción Productora de la películaTipo ProductoraAsociación produce(Productor,Película)Comentarios Ninguno

Enlace Película::protagonistaDescripción Conjunto de actores protagonistas de la películaTipo Set( Actor )Asociación actúaEn(Actor,Película)Comentarios Ninguno

A.2.6.4 Invariante clase Película

Invariante PelículaDescripción • Las cintas alquiladas y no alquiladas forman una partición de todas

las cintas de la películaExpresión self .cinta = self .disponible->union( self .alquilada )

andself .disponible->intersection( self .alquilada )->isEmpty

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 43: proyecto videoclib

Clases y asociaciones de análisis 33

A.2.7 Clase Productora

A.2.7.1 Descripción clase Productora

Clase ProductoraDescripción Esta clase concreta representa a las productoras de las pelícu-

las del vídeo–clubRequisitos asociados • RI–01 Información sobre películasSuperclases –Subclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.7.2 Atributos clase Productora

Atributo constante Productora::nombreDescripción Nombre de la productoraTipo StringComentarios Ninguno

A.2.7.3 Enlaces clase Productora

Enlace Productora::películaDescripción Conjunto de películas producidas por la productoraTipo Set( Película )Asociación produce(Productora,Película)Comentarios Ninguno

A.2.7.4 Invariante clase Productora

Invariante ProductoraDescripción • No puede haber dos productoras con el mismo nombre (nombre es

clave)Expresión Productora.allInstances->forall( a1, a2 |

(a1 <> a2) = (a1.nombre <> a2.nombre) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 44: proyecto videoclib

34 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.8 Asociación actúaEn entre Actor y Película

A.2.8.1 Descripción asociación actúaEn(Actor,Película)

Asociación actúaEn entre Actor y PelículaDescripción Esta asociación representa el hecho de que un actor es prota-

gonista en una películaRequisitos asociados • RI–01 Información sobre películasComentarios Ninguno

A.2.8.2 Roles asociación actúaEn(Actor,Película)

Rol Actor juega rol protagonista en actúaEn(Actor,Película)Descripción Actor protagonista de una películaTipo Set( Actor )Multiplicidad 0..nComentarios Ninguno

Rol Película juega rol película en actúaEn(Actor,Película)Descripción Películas en la que un actor es protagonistaTipo Set( Película )Multiplicidad 0..nComentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 45: proyecto videoclib

Clases y asociaciones de análisis 35

A.2.9 Asociación contiene entre Cinta y Película

A.2.9.1 Descripción asociación contiene(Cinta,Película)

Asociación contiene entre Cinta y PelículaDescripción Esta asociación representa el hecho de que una cinta de vídeo

contiene una películaRequisitos asociados • RI–01 Información sobre películasComentarios Ninguno

A.2.9.2 Roles asociación contiene(Cinta,Película)

Rol Cinta juega rol cinta en contiene(Cinta,Película)Descripción Cinta que contiene una películaTipo Set( Cinta )Multiplicidad 0..nComentarios Ninguno

Rol Película juega rol película en contiene(Cinta,Película)Descripción Película contenida en una cintaTipo PelículaMultiplicidad 1Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 46: proyecto videoclib

36 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.10 Asociación dirige entre Director y Película

A.2.10.1 Descripción asociación dirige(Director,Película)

Asociación dirige entre Director y PelículaDescripción Esta asociación representa el hecho de que un director dirige

una películaRequisitos asociados • RI–01 Información sobre películasComentarios Ninguno

A.2.10.2 Roles asociación dirige(Director,Película)

Rol Director juega rol director en dirige(Director,Película)Descripción Director de una películaTipo DirectorMultiplicidad 1Comentarios Ninguno

Rol Película juega rol película en dirige(Director,Película)Descripción Películas dirigidas por un directorTipo Set( Película )Multiplicidad 0..nComentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 47: proyecto videoclib

Clases y asociaciones de análisis 37

A.2.11 Asociación produce entre Productora y Película

A.2.11.1 Descripción asociación produce(Productora,Película)

Asociación produce entre Productora y PelículaDescripción Esta asociación representa el hecho de que una productora

produce una películaRequisitos asociados • RI–01 Información sobre películasComentarios Ninguno

A.2.11.2 Roles asociación produce(Productora,Película)

Rol Película juega rol película en produce(Productora,Película)Descripción Películas producidas por una productoraTipo Set( Película )Multiplicidad 0..nComentarios Ninguno

Rol Productora juega rol productora en produce(Productora,Película)Descripción Productora de una películaTipo ProductoraMultiplicidad 1Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 48: proyecto videoclib

38 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.12 Asociación tieneAlquilada entre Película y Cinta

A.2.12.1 Descripción asociación tieneAlquilada(Película,Cinta)

Asociación tieneAlquilada entre Película y CintaDescripción Esta asociación derivada representa el hecho de que una pe-

lícula tiene alquiladas cintasRequisitos asociados • RI–01 Información sobre películasComentarios Ver invariante

A.2.12.2 Roles asociación tieneAlquilada(Película,Cinta)

Rol Cinta juega rol alquilada en tieneAlquilada(Película,Cinta)Descripción Cinta alquiladaTipo Set( Cinta )Multiplicidad 0..nComentarios Ninguno

Rol Película juega rol película en tieneAlquilada(Película,Cinta)Descripción Película contenida en una cintaTipo PelículaMultiplicidad 1Comentarios Ninguno

A.2.12.3 Invariante asociación tieneAlquilada(Película,Cinta)

Invariante tieneAlquilada(Película,Cinta)Descripción • Un par (película,cinta) pertenece a esta asociación si y sólo si la cinta

contiene a la película y la cinta está alquiladaExpresión Película.allInstances->forAll( p |

Cinta.allInstances->forall( c |( c.película = p and c.estáAlquilada ) =p.alquilada->includes( c ) ) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 49: proyecto videoclib

Clases y asociaciones de análisis 39

A.2.13 Asociación tieneDisponible entre Película y Cinta

A.2.13.1 Descripción asociación tieneDisponible(Película,Cinta)

Asociación tieneDisponible entre Película y CintaDescripción Esta asociación derivada representa el hecho de que una pe-

lícula tiene disponibles cintas para alquilarRequisitos asociados • RI–01 Información sobre películasComentarios Ver invariante

A.2.13.2 Roles asociación tieneDisponible(Película,Cinta)

Rol Cinta juega rol disponible en tieneDisponible(Película,Cinta)Descripción Cinta disponbile para alquilarTipo Set( Cinta )Multiplicidad 0..nComentarios Ninguno

Rol Película juega rol película en tieneDisponible(Película,Cinta)Descripción Película contenida en una cintaTipo PelículaMultiplicidad 1Comentarios Ninguno

A.2.13.3 Invariante asociación tieneDisponible(Película,Cinta)

Invariante tieneDisponible(Película,Cinta)Descripción • Un par (película,cinta) pertenece a esta asociación si y sólo si la cinta

contiene a la película y la cinta no está alquiladaExpresión Película.allInstances->forAll( p |

Cinta.allInstances->forall( c |( c.película = p and not c.estáAlquilada ) =p.disponible->includes( c ) ) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 50: proyecto videoclib

40 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.14 Paquete Socios y Alquileres

Este paquete contiene las clases y asociaciones relacionadas con los sociosy alquileres del vídeo–club.

A.2.15 Clase Alquiler

A.2.15.1 Descripción clase Alquiler

Clase AlquilerDescripción Esta clase concreta representa a los alquileres de cintas actua-

les y pasados realizados por parte de los socios del vídeo–club

Requisitos asociados • RI–02 Información sobre socios• RI–03 Información sobre cuentas de socios

Superclases –Subclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Esta clase no se ha modelado como una asociación como clase

porque un socio puede alquilar una misma cinta más de unavez

A.2.15.2 Atributos clase Alquiler

Atributo variable Alquiler::estáDevueltoDescripción Indica si el socio ha devuelto la cinta alquiladaTipo BooleanValor inicial falseComentarios Ninguno

Atributo constante Alquiler::fechaAlquilerDescripción Fecha en la que el socio retira la cintaTipo DateComentarios Ninguno

Atributo constante Alquiler::fechaDevoluciónDescripción Fecha tope en la que el socio debe devolver la cintaTipo DateComentarios Ninguno

Atributo constante Alquiler::horaAlquilerDescripción Hora en la que el socio retira la cintaTipo TimeComentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 51: proyecto videoclib

Clases y asociaciones de análisis 41

Atributo constante Alquiler::horaDevoluciónDescripción Hora tope en la que el socio debe devolver la cintaTipo TimeComentarios Ninguno

A.2.15.3 Enlaces clase Alquiler

Enlace Alquiler::cargoAlquilerDescripción Cargo correspondiente al alquilerTipo AlquilerAsociación corresponde(CargoAlquiler,Alquiler)Comentarios Ninguno

Enlace Alquiler::cargoMultaDescripción Cargo correspondiente a la multa por devolución tardíaTipo Set( Alquiler ) o AlquilerAsociación motivadoPor(CargoMulta,Alquiler)Comentarios Los enlaces asociados a los roles con cardinalidad 0..1 puede ac-

tuar como conjuntos o como objetos en OCL

Enlace Alquiler::cintaDescripción Cinta que es objeto del alquilerTipo CintaAsociación esObjetoDe(Cinta,Alquiler)Comentarios Ninguno

Enlace Alquiler::socioDescripción Socio que realiza el alquilerTipo SocioAsociación realiza(Socio,Alquiler)Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 52: proyecto videoclib

42 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.15.4 Invariante clase Alquiler

Invariante AlquilerDescripción •No puede haber dos alquileres de la misma cinta en la misma fecha

y hora• No puede haber dos alquileres pendientes de la misma cinta• La fecha y hora de devolución tienen que ser posteriores o igualesa las de alquiler

Expresión Alquiler.allInstances->forAll( a1, a2 |( a1 <> a2 ) = (

a1.cinta <> a2.cinta ora1.fechaAlquiler <> a2.fechaAlquiler ora1.horaAlquiler <> a2.horaAlquiler ) )

andAlquiler.allInstances->forAll( a1, a2 |

( a1 <> a2 and a1.cinta = a2.cinta ) implies( a1.estáDevuelto or a2.estáDevuelto ) )

andself .fechaAlquiler <= self .fechaDevoluciónand( self .fechaAlquiler = self .fechaDevolución ) implies

( self .horaAlquiler < self .horaDevolución )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 53: proyecto videoclib

Clases y asociaciones de análisis 43

A.2.16 Clase Cargo

A.2.16.1 Descripción clase Cargo

Clase CargoDescripción Esta clase abstracta representa a los cargos de las cuentas de

los socios del vídeo–clubRequisitos asociados • RI–03 Información sobre cuentas de sociosSuperclases MovimientoSubclases CargoMulta, CargoAlquiler (disjuntas)Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.16.2 Atributos clase Cargo

Atributo variable Cargo::estáPendienteDescripción Indica si el cargo está pendiente de pagoTipo BooleanValor inicial trueComentarios Cuando se realiza un cargo, si no hay saldo disponible para

pagarlo se considera pendiente de pago hasta que haya saldosuficiente

A.2.16.3 Enlaces clase CargoNo se han identificado enlaces para esta clase.

A.2.16.4 Invariante clase Cargo

Invariante CargoDescripción • El importe del movimiento es negativoExpresión self .importe <= 0

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 54: proyecto videoclib

44 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.17 Clase CargoAlquiler

A.2.17.1 Descripción clase CargoAlquiler

Clase CargoAlquilerDescripción Esta clase concreta representa a los cargos de las cuentas de

los socios del vídeo–club correspondientes a los alquileres decintas

Requisitos asociados • RI–03 Información sobre cuentas de sociosSuperclases CargoSubclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.17.2 Atributos clase CargoAlquilerNo se han identificado atributos para esta clase.

A.2.17.3 Enlaces clase CargoAlquiler

Enlace CargoAlquiler::alquilerDescripción El alquiler al que corresponde el cargoTipo AlquilerAsociación corresponde(CargoAlquiler,Alquiler)Comentarios Ninguno

A.2.17.4 Invariante clase CargoAlquilerNo se han identificado restricciones para esta clase.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 55: proyecto videoclib

Clases y asociaciones de análisis 45

A.2.18 Clase CargoMulta

A.2.18.1 Descripción clase CargoMulta

Clase CargoMultaDescripción Esta clase concreta representa a los cargos de las cuentas de

los socios del vídeo–club correspondientes a las multas pordevoluciones tardías

Requisitos asociados • RI–03 Información sobre cuentas de sociosSuperclases CargoSubclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.18.2 Atributos clase CargoMultaNo se han identificado atributos para esta clase.

A.2.18.3 Enlaces clase CargoMulta

Enlace CargoMulta::alquilerDescripción El alquiler con devolución tardía que motiva el cargo por multaTipo AlquilerAsociación motivadoPor(CargoMulta,Alquiler)Comentarios Ninguno

A.2.18.4 Invariante clase CargoMultaNo se han identificado restricciones para esta clase.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 56: proyecto videoclib

46 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.19 Clase Cuenta

A.2.19.1 Descripción clase Cuenta

Clase CuentaDescripción Esta clase concreta representa a las cuentas de los socios del

vídeo–clubRequisitos asociados • RI–03 Información sobre cuentas de sociosSuperclases –Subclases –Componentes Nombre Tipo Mult.

movimiento Sequence( Movimiento ) 0..nComentarios Los movimientos están ordenados por fecha

A.2.19.2 Atributos clase Cuenta

Atributo derivado Cuenta::saldoDescripción Saldo actual de la cuentaExpresión self .movimiento->collect( importe )->sumComentarios Ninguno

A.2.19.3 Enlaces clase Cuenta

Enlace Cuenta::socioDescripción El socio de la cuentaTipo SocioAsociación tiene(Socio,Cuenta)Comentarios Ninguno

A.2.19.4 Invariante clase Cuenta

Invariante CuentaDescripción • Los movimientos están ordenados por fechaExpresión Sequence{1.. self .movimiento->size - 1}->forAll( i : Integer |

self .movimiento->at( i ).fecha <=self .movimiento->at( i + 1 ).fecha )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 57: proyecto videoclib

Clases y asociaciones de análisis 47

A.2.20 Clase Ingreso

A.2.20.1 Descripción clase Ingreso

Clase IngresoDescripción Esta clase concreta representa a los ingresos de las cuentas de

los socios del vídeo–clubRequisitos asociados • RI–03 Información sobre cuentas de sociosSuperclases MovimientoSubclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.20.2 Atributos clase IngresoNo se han identificado atributos para esta clase.

A.2.20.3 Enlaces clase IngresoNo se han identificado enlaces para esta clase.

A.2.20.4 Invariante clase Ingreso

Invariante IngresoDescripción • El importe del movimiento es positivoExpresión self .importe > 0

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 58: proyecto videoclib

48 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.21 Clase Movimiento

A.2.21.1 Descripción clase Movimiento

Clase MovimientoDescripción Esta clase abstracta representa a los movimientos de las cuen-

tas de los socios del vídeo–clubRequisitos asociados • RI–03 Información sobre cuentas de sociosSuperclases –Subclases Ingreso, Cargo (disjuntas)Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.21.2 Atributos clase Movimiento

Atributo constante Movimiento::fechaDescripción Fecha en la que se realiza el movientoTipo DateComentarios Ninguno

Atributo constante Movimiento::importeDescripción Cantidad correspondiente al importe del movimientoTipo IntegerComentarios Ninguno

A.2.21.3 Enlaces clase MovimientoNo se han identificado enlaces para esta clase.

A.2.21.4 Invariante clase MovimientoNo se han identificado restricciones para esta clase.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 59: proyecto videoclib

Clases y asociaciones de análisis 49

A.2.22 Clase Socio

A.2.22.1 Descripción clase Socio

Clase SocioDescripción Esta clase concreta representa a los socios actuales del vídeo–

clubRequisitos asociados • RI–02 Información sobre sociosSuperclases –Subclases –Componentes Clase Nombre rol Multiplicidad Tipo enlace

– – – –Comentarios Ninguno

A.2.22.2 Atributos clase Socio

Atributo variable Socio::direcciónDescripción Dirección actual del socioTipo StringValor inicial ”Comentarios Ninguno

Atributo constante Socio::dniDescripción Número del Documento Nacional de Identidad del socioTipo StringComentarios Ninguno

Atributo constante Socio::fechaAltaDescripción Fecha de alta del socioTipo DateComentarios Ninguno

Atributo constante Socio::fechaNacimientoDescripción Fecha de nacimiento del socioTipo DateComentarios Ninguno

Atributo constante Socio::nombreDescripción Nombre y apellidos del socioTipo StringComentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 60: proyecto videoclib

50 Metodología para el Análisis de Requisitos de Sistemas Software

Atributo constante Socio::númeroDescripción Número identificativo del socioTipo IntegerComentarios Se debe generar automáticamente

Atributo constante Socio::sexoDescripción Sexo del socioTipo enum { Hombre, Mujer }Comentarios Ninguno

Atributo variable Socio::teléfonosDescripción Teléfonos del socioTipo Set( Integer )Valor inicial Set{}Comentarios Ninguno

A.2.22.3 Enlaces clase Socio

Enlace Socio::alquilerDescripción Conjunto de alquileres pasados y presentes del socioTipo Sequence( Alquiler )Asociación realiza(Socio,Alquiler)Comentarios No se permiten duplicados en la secuencia de alquileres y deben

estar ordenados por fecha de alquiler (ver invariante)

Enlace derivado Socio::alquilerActualDescripción Conjunto de alquileres actualesExpresión self .alquiler->select( a | not a.estáDevuelto )Asociación realizaActualmente(Socio,Alquiler)Comentarios Ninguno

Enlace derivado Socio::cintaDescripción Conjunto de cintas actualmente alquiladas por el socioExpresión self .alquilerActual.cinta->asSetAsociación tieneAlquilada(Socio,Cinta)Comentarios Ninguno

Enlace Socio::cuentaDescripción Cuenta del socioTipo CuentaAsociación tiene(Socio,Cuenta)Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 61: proyecto videoclib

Clases y asociaciones de análisis 51

A.2.22.4 Invariante clase Socio

Invariante SocioDescripción • No puede haber dos socios con el mismo DNI ni con el mismo nú-

mero (dni y número son clave)• Los alquileres deben estar ordenados por fecha de alquiler• No hay alquileres duplicados

Expresión Socio.allInstances->forAll( s1, s2 |( s1 <> s2 ) =( s1.dni <> s2.dni and s1.número <> s2.número ) )

andSequence{1.. self .alquiler->size - 1}->forAll( i : Integer |

self .alquiler->at( i ).fechaAlquiler <=self .alquiler->at( i + 1 ).fechaAlquiler )

andself .alquiler->size = self .alquiler->asSet->size

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 62: proyecto videoclib

52 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.23 Asociación corresponde entre CargoAlquiler y Alquiler

A.2.23.1 Descripción asociación corresponde(CargoAlquiler,Alquiler)

Asociación corresponde entre CargoAlquiler y AlquilerDescripción Esta asociación representa el hecho de que un cargo por al-

quiler corresponde a un determinado alquilerRequisitos asociados • RI–03 Información sobre cuentas de sociosComentarios Ninguno

A.2.23.2 Roles asociación corresponde(CargoAlquiler,Alquiler)

Rol Alquiler juega rol alquiler en correspon-de(CargoAlquiler,Alquiler)

Descripción Alquiler correspondiente al cargoTipo AlquilerMultiplicidad 1Comentarios Ninguno

Rol CargoAlquiler juega rol cargoAlquiler en correspon-de(CargoAlquiler,Alquiler)

Descripción Cargo correspondiente al alquilerTipo CargoAlquilerMultiplicidad 1Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 63: proyecto videoclib

Clases y asociaciones de análisis 53

A.2.24 Asociación esObjetoDe entre Cinta y Alquiler

A.2.24.1 Descripción asociación esObjetoDe(Cinta,Alquiler)

Asociación esObjetoDe entre Cinta y AlquilerDescripción Esta asociación representa el hecho de que una cinta es objeto

de alquileresRequisitos asociados • RI–02 Información sobre socios

• RI–03 Información sobre cuentas de sociosComentarios Ninguno

A.2.24.2 Roles asociación esObjetoDe(Cinta,Alquiler)

Rol Alquiler juega rol alquiler en esObjetoDe(Cinta,Alquiler)Descripción Alquileres de los que ha sido objeto una cintaTipo Sequence( Alquiler )Multiplicidad 0..nComentarios Los alquileres están ordenados por fecha de alquiler

Rol Cinta juega rol cinta en esObjetoDe(Cinta,Alquiler)Descripción Cinta que es objeto del alquilerTipo CintaMultiplicidad 1Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 64: proyecto videoclib

54 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.25 Asociación esObjetoActualmenteDe entre Cinta y Alquiler

A.2.25.1 Descripción asociación esObjetoActualmenteDe(Cinta,Alquiler)

Asociación esObjetoActualmenteDe entre Cinta y AlquilerDescripción Esta asociación derivada representa el hecho de que una cinta

es objeto actualmente de un alquilerRequisitos asociados • RI–02 Información sobre socios

• RI–03 Información sobre cuentas de sociosComentarios Ninguno

A.2.25.2 Roles asociación esObjetoActualmenteDe(Cinta,Alquiler)

Rol Alquiler juega rol alquilerActual en esObjetoActualmente-De(Cinta,Alquiler)

Descripción Alquiler actual (aún no devuelto) del que es objeto la cintaTipo Alquiler o Set( Alquiler )Multiplicidad 0..1Comentarios Los roles con cardinalidad 0..1 puede actuar como conjuntos o como

objetos en OCL

Rol Cinta juega rol Cinta en esObjetoActualmenteDe(Cinta,Alquiler)Descripción Cinta que es objeto de alquilerTipo CintaMultiplicidad 1Comentarios Ninguno

A.2.25.3 Invariante asociación esObjetoActualmenteDe(Cinta,Alquiler)

Invariante esObjetoActualmenteDe(Cinta,Alquiler)Descripción • Un par (cinta,alquiler) pertenece a esta asociación si y sólo existe

un alquiler en el que la cinta es alquilada y dicho alquiler está sindevolver

Expresión Cinta.allInstances->forAll( c |Alquiler.allInstances->forall( a |

( a.cinta = c and not a.estáDevuelto ) =c.alquilerActual = a ) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 65: proyecto videoclib

Clases y asociaciones de análisis 55

A.2.26 Asociación motivadoPor entre CargoMulta y Alquiler

A.2.26.1 Descripción asociación motivadoPor(CargoMulta,Alquiler)

Asociación motivadoPor entre CargoMulta y AlquilerDescripción Esta asociación representa el hecho de que un cargo por mul-

ta por alquiler con devolución tardía corresponde a un deter-minado alquiler

Requisitos asociados • RI–03 Información sobre cuentas de sociosComentarios Ninguno

A.2.26.2 Roles asociación motivadoPor(CargoMulta,Alquiler)

Rol Alquiler juega rol alquiler en motivadoPor(CargoMulta,Alquiler)Descripción Alquiler correspondiente al cargo por multaTipo AlquilerMultiplicidad 1Comentarios Ninguno

Rol CargoMulta juega rol cargoMulta en motivado-Por(CargoMulta,Alquiler)

Descripción Cargo correspondiente a la multa por alquiler con devolución tardíaTipo Set( CargoAlquiler ) o CargoAlquilerMultiplicidad 0..1Comentarios Los roles con cardinalidad 0..1 puede actuar como conjuntos o como

objetos en OCL

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 66: proyecto videoclib

56 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.27 Asociación realiza entre Socio y Alquiler

A.2.27.1 Descripción asociación realiza(Socio,Alquiler)

Asociación realiza entre Socio y AlquilerDescripción Esta asociación representa el hecho de que un socio realiza

alquileres de cintasRequisitos asociados • RI–02 Información sobre sociosComentarios Ninguno

A.2.27.2 Roles asociación realiza(Socio,Alquiler)

Rol Alquiler juega rol alquiler en realiza(Socio,Alquiler)Descripción Alquileres realizados por el socioTipo Sequence( Alquiler )Multiplicidad 0..nComentarios Los alquileres están ordenados por fecha de alquiler

Rol Socio juega rol socio en realiza(Socio,Alquiler)Descripción Socio que realiza el alquilerTipo SocioMultiplicidad 1Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 67: proyecto videoclib

Clases y asociaciones de análisis 57

A.2.28 Asociación realizaActualmente entre Socio y Alquiler

A.2.28.1 Descripción asociación realizaActualmente(Socio,Alquiler)

Asociación realizaActualmente entre Socio y AlquilerDescripción Esta asociación derivada representa el hecho de que un socio

realiza actualmente alquileres de cintasRequisitos asociados • RI–02 Información sobre sociosComentarios Ninguno

A.2.28.2 Roles asociación realizaActualmente(Socio,Alquiler)

Rol Alquiler juega rol alquilerActual en realizaActualmen-te(Socio,Alquiler)

Descripción Alquileres realizados actualmente (aún no devueltos) por el socioTipo Set( Alquiler )Multiplicidad 0..nComentarios Ninguno

Rol Socio juega rol socio en realizaActualmente(Socio,Alquiler)Descripción Socio que realiza el alquilerTipo SocioMultiplicidad 1Comentarios Ninguno

A.2.28.3 Invariante asociación realizaActualmente(Socio,Alquiler)

Invariante realizaActualmente(Socio,Alquiler)Descripción • Un par (socio,alquiler) pertenece a esta asociación si y sólo si el socio

tiene dicho alquiler sin devolverExpresión Socio.allInstances->forAll( s |

Alquiler.allInstances->forall( a |( a.socio = s and not a.estáDevuelto ) =s.alquilerActual->includes( a ) ) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 68: proyecto videoclib

58 Metodología para el Análisis de Requisitos de Sistemas Software

A.2.29 Asociación tiene entre Socio y Cuenta

A.2.29.1 Descripción asociación tiene(Socio,Cuenta)

Asociación tiene entre Socio y CuentaDescripción Esta asociación representa el hecho de que un socio tiene una

cuenta en el vídeo–clubRequisitos asociados • RI–03 Información sobre cuentas de sociosComentarios Ninguno

A.2.29.2 Roles asociación tiene(Socio,Cuenta)

Rol Cuenta juega rol cuenta en tiene(Socio,Cuenta)Descripción Cuenta del socioTipo CuentaMultiplicidad 1Comentarios Ninguno

Rol Socio juega rol socio en tiene(Socio,Cuenta)Descripción Socio titular de la cuentaTipo CuentaMultiplicidad 1Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 69: proyecto videoclib

Clases y asociaciones de análisis 59

A.2.30 Asociación tieneAlquilada entre Socio y Cinta

A.2.30.1 Descripción asociación tieneAlquilada(Socio,Cinta)

Asociación tieneAlquilada entre Socio y CintaDescripción Esta asociación derivada representa el hecho de que un socio

tiene actualmente cintas alquiladas (sin devolver)Requisitos asociados • RI–02 Información sobre sociosComentarios Ninguno

A.2.30.2 Roles asociación tieneAlquilada(Socio,Cinta)

Rol Cinta juega rol cinta en tieneAlquilada(Socio,Cinta)Descripción Cintas alquiladas actualmente (aún no devueltas) por un socioTipo Set( Cinta )Multiplicidad 0..nComentarios Ninguno

Rol Socio juega rol socio en tieneAlquilada(Socio,Cinta)Descripción Socio que tiene alquilada la cintaTipo Set( Cinta ) o CintaMultiplicidad 0..1Comentarios Los roles con cardinalidad 0..1 puede actuar como conjuntos o como

objetos en OCL

A.2.30.3 Invariante asociación tieneAlquilada(Socio,Cinta)

Invariante tieneAlquilada(Socio,Cinta)Descripción • Un par (socio,cinta) pertenece a esta asociación si y sólo existe un

alquiler no devuelto realizado por el socio en el que la cinta es alqui-lada

Expresión Socio.allInstances->forAll( s |Cinta.allInstances->forall( c |

( Alquiler.allInstances->exists( a |a.socio=s and a.cinta=c and not a.estáDevuelto ) ) =( s.cinta->includes( c ) and c.socio = s ) ) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 70: proyecto videoclib

60 Metodología para el Análisis de Requisitos de Sistemas Software

A.3 Escenarios de análisis

A.3.1 Escenario AltaDeSocio

A.3.1.1 Descripción escenario AltaDeSocio

Escenario AltaDeSocioDescripción El empleado del vídeo–club da de alta un nuevo socioRequisitos asociados • RF–01 Alta de socioParámetros dni : String -- DNI del nuevo socio

n : String -- nombre y apellidos del nuevo sociofn : Date -- fecha nacimiento del nuevo socios : enum{ Hombre, Mujer } -- sexo del nuevo sociod : String -- dirección del nuevo sociot : Set( Integer ) -- teléfonos del nuevo socio

Precondición • No existe ningún socio con el mismo número de D.N.I.Precondición (OCL) not Socio.allInstances->exists( s | s.dni = dni )

Postcondición • Existe un nuevo socio, y sólo uno, con los valores de atribu-tos correspondientes a los parámetros y sin ningún alquiler• Existe una nueva cuenta, y sólo una, correspondiente alnuevo socio y sin ningún movimiento

Postcondición (OCL) Socio.new->exists( s |s.dni = dni ands.nombre = n ands.fechaNacimiento = fn ands.sexo = s ands.fechaAlta = Date.today ands.dirección = d ands.teléfonos = t ands.alquiler->isEmpty andCuenta.new->exists( c |

s.cuenta = c andc.socio = s andc.movimiento->isEmpty

))andSocio.new->size = 1andCuenta.new->size = 1

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 71: proyecto videoclib

Escenarios de análisis 61

A.3.1.2 Diagrama de traza de eventos escenario AltaDeSocio

SocioEmpleado del

vídeo-clubSistema

Vídeo-Club

AltaDeSocio( dni, n, fn, s, d, t )

carnet desocio

Mensaje( "El nuevo socio ya es socio" )

Excepción:el nuevo socioya es socio

Figura 20: Diagrama de traza de eventos del escenario AltaDeSocio

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 72: proyecto videoclib

62 Metodología para el Análisis de Requisitos de Sistemas Software

A.3.1.3 Interfaz de usuario escenario AltaDeSocio

Vídeo--Club Ejemplo Núm: 23456-------------------------------------------------------dirección y teléfono del vídeo--club

CARNET DE SOCIO

Nombre: Amador Durán ToroDirección: Departamento de Lenguajes y Sistemas Infor-máticos, Avda. Reina Mercedes s/n, 41012 Sevilla

DNI: 12345678-X FirmaFecha alta: 21/12/1998

Figura 21: Interfaz de usuario del escenario AltaDeSocio

En el diálogo, el empleado del vídeo–club introduce los datos del nuevosocio. El número del socio y la fecha de alta son proporcionados por elsistema. Una vez que se finaliza pulsando el botón OK el sistema imprimeel carnet de socio.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 73: proyecto videoclib

Escenarios de análisis 63

A.3.2 Escenario AlquilerCinta

A.3.2.1 Descripción escenario AlquilerCinta

Escenario AlquilerCintaDescripción Un socio alquila una cinta de vídeoRequisitos asociados • RF–06 Alquiler de cintas de vídeoParámetros s : Socio -- socio que realiza el alquiler

p : Película -- película que se alquilai : Integer -- importe del alquilerfd : Date -- fecha de devoluciónhd : Time -- hora de devoluciónfp : enum{ Contado, Cuenta } -- forma de pago

Precondición • La película tiene cintas disponibles• El importe del alquiler no es negativo• La fecha de devolución es posterior a la actual

Precondición (OCL) p.disponible->notEmpty andi <= 0 andfd >= Date.today

Postcondición • Existe una cinta de la película que antes no estaba alquilada• Existe un nuevo alquiler no devuelto de dicha cinta corres-pondiente al socio• Existe un nuevo cargo, y sólo uno, en la cuenta del sociocorrespondiente al alquiler• Si se paga al contado existe un nuevo ingreso correspon-diente , y sólo uno, en la cuenta del socio

Postcondición (OCL) Cinta.allInstances->exists( c |c.película = p and( not [email protected]áAlquilada) andAlquiler.new->exists( a |

a.socio = s anda.cinta = c anda.fechaAlquiler = Date.today anda.horaAlquiler = Time.now anda.fechaDevolución = fd anda.horaDevolución = hd and( not a.estáDevuelto) andCargoAlquiler.new->exists( ca |

ca.cuenta = s.cuenta andca.alquiler = a andca.importe = -i andca.fecha = Date.today ) ) )

andAlquiler.new->size = 1andCargoAlquiler.new->size = 1and( fp = #Contado implies

( Ingreso.new->exists( i |i.cuenta = s.cuenta andi.fecha = Date.today andi.importe = i )

andIngreso.new->size = 1 ) )

Comentarios Ninguno

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 74: proyecto videoclib

64 Metodología para el Análisis de Requisitos de Sistemas Software

A.3.2.2 Diagrama de traza de eventos escenario AlquilerCinta

Empleado delvídeo-club

SistemaVídeo-Club

AlquilerCinta( s, p, i, fd, hd, fp)

Ticket

Excepción:no hay cintadisponible

Socio

Mensaje("No haycinta disponible")

Alternativa:si el socio paga enmetálico haydevolver un ticket

Figura 22: Diagrama de traza de eventos del escenario AlquilerCinta

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 75: proyecto videoclib

Escenarios de análisis 65

A.3.2.3 Interfaz de usuario escenario AlquilerCinta

Vídeo--Club Ejemplo-------------------------------------------------------dirección y teléfono del vídeo--club

TICKET DE ALQUILER

Socio: 23456 (Amador Durán Toro)Cinta: 1234 (La guerra de las galaxias)Fecha alquiler : 21/12/1998 18:05:32Devolver antes de : 22/12/1998 21:30:00

Son 300 Ptas

Figura 23: Interfaz de usuario del escenario AlquilerCinta

En el diálogo, el empleado del vídeo–club introduce el número del socioque realiza el alquiler y selecciona el nombre de la película. El sistema lemuestra el nombre y el saldo del socio y le propone una cinta disponible(si hay) de la película. El sistema propone la fecha y hora de devoluciónasí como el importe del alquiler. El empleado puede aceptar los valorespropuestos o cambiarlos. Por último el empleado indica la forma de pago.Una vez que se finaliza pulsando el botón OK el sistema imprime el ticket.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 76: proyecto videoclib

66 Metodología para el Análisis de Requisitos de Sistemas Software

A.3.3 Escenario ConsultarPelícula

A.3.3.1 Descripción escenario ConsultarPelícula

Escenario ConsultarPelículaDescripción El empleado del vídeo–club consulta una películaRequisitos asociados • RF–10 Consulta de una películaParámetros p : Película -- película que se consulta

Precondición –Precondición (OCL) –Postcondición –Postcondición (OCL) –Comentarios Ninguno

A.3.3.2 Interfaz de usuario escenario ConsultarPelícula

Consulta de película 21/12/1998-------------------------------------------------------Título: La Guerra de las GalaxiasTema: Ciencia-FicciónProductora: 20th Century Fox (1977)Protagonistas:

Mark HamillHarrison FordAlec Guinnes

Cintas disponibles: 2

Figura 24: Interfaz de usuario del escenario ConsultarPelícula

A. Durán, B. Bernárdez Sevilla, Noviembre 2000

Page 77: proyecto videoclib

Cambios en los requisitos originales 67

En el diálogo, el empleado del vídeo–club introduce el nombre de la pelí-cula que quiere consultar y el sistema le muestra la información asociada.El empleado puede avanzar o retroceder en orden alfabético por la pelícu-las utilizando los botones » y «. Si lo desea, puede imprimir los datos dela película pulsando el botón con una imagen de impresora. La consultafinaliza una vez que se pulsa el botón OK.

A.4 Cambios en los requisitos originales

Como resultado del análisis realizado, se deberían realizar los siguientescambios en los requisitos originales:

• Recoger en algún requisito de almacenamiento de información quecada cinta debe tener un número identificativo para que el empleadodel vídeo–club las pueda localizar en las estanterías.

• Añadir un requisito de almacenamiento de información nuevo querecoja explícitamente la información que se debe guardar sobre losalquileres, por ejemplo la fecha y la hora del alquiler.

• Modificar el requisito RI-03 (Información sobre cuentas de socios)para dejar claro que cuando el socio paga en metálico también seconsidera un ingreso en su cuenta, y cambiar el intervalo de sólopresente a pasado y presente. También se debe clarificar el conceptode pago pendiente, definiéndolo como aquellos cargos para los que nohay saldo suficiente en la cuenta del socio.

A. Durán, B. Bernárdez Sevilla, Noviembre 2000