desarrollo orientado a objetos en m etrica v. 3´rossi/prescasosuso.pdf · estructura del curso 1....

Desarrollo Orientado a Objetosen Metrica v. 3

Carlos Rossi Jimenez

c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.1/45

Estructura del curso

1. Estructura de Métrica v. 3

2. Técnicas orientadas a objetos en Métrica v. 3

• Diagramas de casos de uso

• Diagramas de clases

• Diagramas de interacción

• Diagramas de estados

• Modelización de interfaces de usuario

• Diseño físico de bases de datos

• Diagramas de despliegue

• Diagramas de componentes


Diagramas de casos de uso

Casos de Uso en Métrica 3

EVS 4. Estudio de alternativas de soluci on

4.2. Descripci on de alternativas de soluci on

Se describe el modelo de negocio.



EVS 6. Selecci on de la soluci on

6.2. Evaluaci on de las alternativas de soluci on

Incluye los modelos de negocio de cada una.

ASI 1. Definici on del sistema

1.1. Determinaci on del alcance del sistema

Se usa el modelo de negocio.



ASI 2. Establecimiento de requisitos

2.1. Obtenci on de requisitos

Se utilizan los casos de uso para establecer los requisitos

funcionales.



2.2. Especificaci on de casos de uso

Cada caso de uso se especifica mediante:

• Descripción del escenario

• Pre- y post-condiciones

• Identificación de interfaces de usuario

• Condiciones de fallo

Para casos de uso complejos se pueden emplear diagramas de

transición de estados o casos de uso anidados.



2.3. Analisis de requisitos

Se optimiza el modelo de casos de uso.

2.4. Validaci on de requisitos

Por parte del usuario.



ASI 3. Identificaci on de subsistemas de

analisis

3.1. Determinaci on de subsistemas de an alisis

Se asignan requisitos y casos de uso a cada subsistema.

3.2. Integraci on de subsistemas de an alisis

Se coordinan los modelos de cada subsistema.



ASI 4. An alisis de los casos de uso

Se identifican las clases necesarias para cada caso de uso.

ASI 9. An alisis de consistencia y

especificaci on de requisitos

9.1. Verificaci on de los modelos



9.2. Analisis de consistencia entre modelos

Por ejemplo:

• Análisis de la realización de casos de uso/interfaz de

usuario.

• Los subsistemas satisfacen los casos de uso.



9.3. Validaci on de los modelos

Según:

• El catálogo de requisitos.

• El usuario.

9.3. Elaboraci on de la especificaci on de requisitos

software


Objetivos

• Capturar los requisitos funcionales del sistema

• Guiar el proceso de desarrollo

• Proporcionar una herramienta de comunicación entre

usuarios, analistas y diseñadores.

• Proporcionar una visión del sistema como “caja negra”

• Constituir una especificación abstracta del sistema


Descripción

Un diagrama de casos de uso es un grafo constituido por:

• actores

• casos de uso

• relaciones entre elementos


Elementos

Caso de uso

• Especifica el comportamiento del sistema de información o

de una parte de él según una manera específica de dar

respuesta a los usuarios.

• Representación de un requisito funcional del sistema.

• Describe el conjunto de secuencias de acciones

(incluyendo variantes) que ejecuta el sistema para producir

un resultado observable de interés para un actor.

• Conjunto de transacciones entre el sistema y los actores.


Elementos

Caso de uso

• Sirve para validar la arquitectura del sistema y verificar el

sistema en desarrollo.

• Punto de partida para la generación de casos de prueba.

• Un caso de uso se representa gráficamente mediante una

elipse. En su interior se incluye el nombre del caso de uso.


Elementos

Especificaci on de casos de uso

Los niveles de especificación pueden ser:

• Una descripción general

• Establecimiento de pre- y post-condiciones

• Enumerar y describir los diferentes escenarios del caso de

uso

• Casos de uso anidados (diagrama jerárquico)

• Diagrama de estados


Elementos

Escenario

• Cada uno de los diferentes caminos que pueden darse en

un caso de uso, dependiendo de las condiciones que se

den en su realización.

• Flujo de eventos a través de una variante de un caso de

uso.

• Secuencia específica de acciones que ilustra un

comportamiento.

• Instancia de un caso de uso.


Elementos

Descripci on de un escenario

• Flujo básico de eventos:

• Cómo y cuándo empieza y acaba el caso de uso

• Cuándo interactúa con los actores y qué información se

intercambian

• Flujos alternativos de comportamiento.


Caso práctico

Un programa de clasificación electrónica (PCE) puede

emplearse para almacenar y recuperar documentos de texto.

Cualquier documento creado por un procesador de texto, un

editor o por otros medios puede archivarse en el sistema de

clasificación electrónica. Los documentos pueden clasificarse

en base a palabras clave, autores, y/o una descripción del

documento o resumen que describa el documento. Los

documentos archivados en el sistema también pueden ser

eliminados o borrados.


Caso práctico

Para una rápida recuperación de los documentos almacenados

usando el PCE se emplean índices. Los documentos se pueden

recuperar según esquemas adecuados que no se encuentran en

las clasificaciones convencionales; por ejemplo, los usuarios

pueden recuperar o localizar un documento según su contenido,

descripción, autor(es), o según palabras clave definidas por el

usuario. Por tanto, la descripción del documento, los autores, las

palabras clave y/o el mismo texto del documento pueden ser

objeto de búsqueda.


Caso práctico

Un usuario puede especificar criterios de búsqueda, cuyo

resultado sea una colección de documentos que cumplen

dichos criterios. Entonces, los documentos encontrados pueden

ser vistos o impresos.

Al usuario se le da la posibilidad de especificar palabras

"intrascendentes", que no serán buscadas ni indexadas, como,

por ejemplo, y, o, no, el, la, los, las,si, etc. El usuario puede

especificar también qué caracteres alfanuméricos de un

documento que serán indexados o buscados (el conjunto de

caracteres de clasificación), limitando de esta forma la

búsqueda y los índices sólo a porciones de documentos.


Caso práctico: Escenarios

Escenario normal del caso de uso Archivar un documento:

El usuario quiere archivar un documento

El usuario especifica el directorio y el archivo del documento

El usuario introduce un resumen del documento, las palabras clave y/o el(los)

autor(es)

El usuario solicita que se archive el documento

El documento es archivado


Caso práctico: escenarios

Escenario de excepción del caso de uso Archivar un documento:

El usuario quiere archivar un documento

El usuario especifica el directorio del documento

El usuario solicita que se archive el documento

El sistema muestra un mensaje de error y solicita al usuario que especifique el

archivo del documento

El usuario cancela la operación


Elementos

Actor

• Un actor es algo o alguien que se encuentra fuera del

sistema y que interactúa con él.

• En general los actores son personas u otros sistemas.

• Un único actor puede representar a varios usuarios

distintos, y un usuario puede actuar como diferentes

actores. Por ejemplo:

• el actor Cliente representa a varias personas distintas

• la persona J. Pérez puede actuar como el actor Cliente y

como el actor Director


Elementos

Actor

• Un caso de uso tiene un efecto tangible para un actor

determinado:

• cálculo de un resultado

• generación de un objeto

• cambio de estado de un objeto

• Un actor se representa gráficamente mediante un monigote

con su nombre debajo.


Elementos

Paquete

• Se emplean para la organización de diagramas

• Se determina una partición del sistema y a cada una de las

divisiones se le asocia un paquete en el que se incluyen los

casos de uso correspondientes

• Se representa gráficamente con una carpeta con el nombre

en su interior


Relaciones

Tipos de relaciones:

• Relaciones entre actores y casos de uso

• Relaciones entre casos de uso:

• Especialización

• Inclusión

• Extensión

• Relaciones de especialización entre actores


Relaciones

Actor - Caso de uso

• Es una relación de comunicación

• Puede ser uni- o bi-direccional

• Se representa gráficamente mediante una línea continua


Relaciones

Actor-Actor

• Relación de generalización: se pueden definir categorías

generales de actores (por ejemplo Cliente) y especializarlos

(por ejemplo Cliente Preferencial)

• Esta relación se representa gráficamente mediante una

flecha con la cabeza hueca dirigida al actor más general


Relaciones

Generalizaci on de casos de uso

• Un caso de uso (hijo) hereda el comportamiento y el

significado otro caso de uso (padre)

• El caso de uso hijo puede añadir comportamiento o bien

redefinir el del padre.

• Ejemplo: un caso de uso Validar usuario puede tener como

hijos los casos de uso Comprobar clave y Comprobar firma

• Se representa gráficamente con una flecha hueca dirigida al

caso de uso padre


Relaciones

Inclusi on de casos de uso

• Representa un comportamiento común entre varios casos

de uso:

un caso de uso base A incorpora explícitamente el

comportamiento de otro caso de uso B en el lugar

especificado en el caso de uso base

• Gráficamente se representa mediante una flecha etiquetada

con el estereotipo � usa � (o � include �) que parte del

caso de uso base

• Teóricamente el caso de uso incluido nunca se encuentra

aisladoc©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.31/45

Caso práctico

Se presenta una relación de inclusión entre loscasos de uso:

• Ver un documento y Buscar un documento

• Imprimir un documento y Buscar un documento


Caso práctico

Escenario normal del caso de uso Ver undocumento:incluir(Buscar un documento)El usuario selecciona un documento entre los encontradosEl usuario requiere ver el documentoEl sistema muestra el documento


Caso práctico

Escenario de excepción del caso de uso Ver undocumento:incluir(Buscar un documento)El usuario requiere ver el documentoEl sistema muestra un mensaje de error indicando quedebe seleccionar un documentoEl usuario finaliza la petición


Relaciones

Extensi on de casos de uso

• Esta relación representa un comportamiento opcional de un

caso de uso:

un caso de uso base A incorpora implícitamente el

comportamiento de otro caso de uso B (en el lugar

especificado en el primero)

• A es el comportamiento habitual del sistema y, dependiendo

de alguna condición, tiene un comportamiento adicional o

ligeramente diferente representado por B


Relaciones


• Se representa gráficamente mediante una flecha etiquetada

con el estereotipo � extiende � (o � extends �) que llega

al caso de uso base

• El caso de uso base, por tanto, bajo ciertas condiciones

incorpora el comportamiento de otro caso de uso en un

punto concreto de su especificación denominado punto de

extensión.

• Un caso de uso base puede tener varias relaciones de

extensión y, en consecuencia, varios puntos de extensión.


Relaciones


Ejemplo:

Consideremos el caso de uso base Hacer pedido con una relación

de extensión con otro caso de uso Hacer pedido urgente.

La especificación de un escenario normal sería:

El cliente solicita hacer un pedido

El usuario proporciona los datos del pedido

(establecer prioridad)

Procesar el pedido


Técnicas comunes de modelado

Pasos para la elaboración de un diagrama de casos de uso:

1. Identificar los actores que interactúan con el sistema

2. Organizar los actores identificando tanto los roles generales

como los especializados

3. Considerar las formas más importantes que tiene cada

actor de interactuar con el sistema

4. Considerar las formas excepcionales en las que cada actor

puede interactuar con el sistema

5. Organizar los comportamientos como casos de uso,

utilizando las relaciones de inclusión y extensión


Técnicas comunes de modelado

Hay dos formas de aplicar los diagramas de casos de uso:

1. Modelado del contexto de un sistema:Se determina qué actores quedan fuera del sistema e

interactúan con él.

2. Modelado de los requisitos de un sistema:

• Se especifica qué debe hacer el sistema,

independientemente de cómo se haga.

• Se especifica el comportamiento del sistema como una

caja negra.


Modelado del contexto de un sistema

• Se trata de diferenciar entre elementos del sistema y

elementos externos al sistema:

• Los elementos del sistema desarrollan el

comportamiento de éste

• Los elementos externos interactúan con el sistema

• El contexto del sistema se puede definir como los

elementos externos que interactúan con el sistema.



Para modelar el contexto de un sistema:

1. Identificar los actores en torno al sistema considerando:

• Qué grupos requieren funciones del sistema para

desarrollar sus tareas.

• Qué grupos son necesarios para que el sistema

desarrolle sus tareas.

• Qué grupos interactúan con hardware externo o con

otros sistemas.

• Qué grupos realizan tareas secundarias de

administración y mantenimiento.



2 Organizar los actores similares en jerarquías de

generalización/especialización.

3 Introducir los actores en el diagrama de casos de uso y

especificar las vías de comunicación de cada actor con los

casos de uso.


Modelado de los requisitos de un sistema

• Un requisito se puede definir como una característica de

diseño, propiedad o comportamiento de un sistema.

• El establecimiento de los requisitos determina un contrato

entre el sistema y sus elementos externos.

• Los requisitos funcionales se pueden expresar mediante

casos de uso.


Modelado de los requisitos de un sistema

Para modelar los requisitos hay que seguir los siguientes pasos:

1. Establecer el contexto del sistema, identificando los actores.

2. Considerar qué comportamiento del sistema espera cada

actor.

3. Nombrar los comportamientos como casos de uso.

4. Factorizar el comportamiento común (relación de uso) en

nuevos casos de uso y factorizar el comportamiento

variante (relación de extensión) como nuevos casos de uso.

5. Modelar los casos de uso, actores y relaciones en

diagramas de casos de uso.


Caso práctico


desarrollo orientado a objetos en m etrica v. 3´rossi/prescasosuso.pdf · estructura del curso 1....

Documents