Portada

Índice

1. Especificación de requerimientos del software (ERS)

Caso de estudio

Se desea modelar un sistema informático para gestionar las transacciones en un recinto ferial de subastas.
Cualquier persona que haya logrado acceso al recinto de la feria puede conectarse al sistema a través de alguno de
los muchos terminales disponibles, y participar en las subastas que tengan lugar, en alguna de las modalidades
ofrecidas por el sistema, es decir, como comprador, como vendedor, o como simple observador.

Para subastar algún artículo es necesario darse de alta como vendedor. El vendedor puede registrar artículos en la
subasta, rellenando una ficha por cada artículo, que sale así inmediatamente a subasta.

Análogamente, para participar en una puja es necesario darse de alta como comprador. El comprador puede pujar
por cualquiera de los artículos subastados en la feria. Cuando no se produce ninguna nueva puja, el artículo queda
definitivamente adjudicado al comprador. Si un artículo no ha recibido ninguna puja, el vendedor puede modificar
alguno de sus datos.

Cualquier persona puede participar como observador en una subasta, es decir, puede consultar la lista de artículos
subastados y seleccionar uno de ellos para examinar la lista de pujas, pero necesita registrarse como vendedor o
comprador para participar activamente.

1.1. Diagrama de caso de uso y plantillas

1.2. Diagrama clase
1.3. Diagrama de actividad
1.4. Diagrama de secuencia

Directrices:

1.1. Diagrama de caso de uso y plantillas

 Debe contener todos los casos de usos según el caso de estudio.
 Se evaluará:

Diseño estructura con actores involucrados y caso de uso relacionado.

Actores actores bien especificados y necesarios en el sistema.

Casos de uso sintaxis aplicando numeración ordenada, verbos en infinitivo + objeto.

Comunicación extend, include y herencia justificada según el requerimiento.

Plantilla de caso de uso
 Debe contener al menos 3 o 4 plantillas donde se aplique extend, include, especificando el caso de uso
correspondiente

Código
Nombre:
Autor:
Fecha:
Prioridad:
Riesgo
Descripción:

Actores:

Precondición(es):

Flujo Normal:

Flujo Alternativo:

Postcondición (es):
1.2. Diagrama clase
 Debe contener todas las clases según el caso de estudio.
 Se evaluará:

Clases nombres de las clases debe ser sustantivos y empiecen con mayúsculas.

cada clase debe estructurarse: atributos y métodos importantes.

Atributos nombres de los atributos debe ser sustantivos o adjetivos.

tipo de dato y visibilidad

Métodos nombres de los métodos deben ser verbos, y expresar claramente una
acción u operación de la clase.

argumentos, tipo de dato, tipo de valor de retorno y visibilidad.

Asociaciones cardinalidades
roles
dirección de navegación de todas las asociaciones

1.3. Diagrama de actividad

 Debe contener al menos 2 diagramas especificando el caso de uso correspondiente en la que realizaron
plantilla.
 Se evaluará:

nombre del diagrama (caso de uso)

Diseño
distribución de carriles

Nodo nodo inicial, nodo final de flujo y nodo final

flujo base y flujo alterno representado según lo descrito en la

Actividad
especificación de casos de uso (plantilla)

Flujo de objetos flujo de control y control de decisión.

1.4. Diagrama de secuencia

 Debe contener al menos 2 diagramas especificando el caso de uso correspondiente en la que realizaron
plantilla.
 Se evaluará:

nombre del diagrama (caso de uso)

Diseño
distribución de objetos, mensajes y activación
Objetos (actor, interfaz, control, entidad/objeto) involucrados
activación de cada uno de los objetos durante el lapso de tiempo que
Línea de tiempo
corresponde.
numeración de los mensajes
Mensajes
comunicación sincrónica o asincrónica