Desarrollo Orientado a Objetos ´ en 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 c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.2/45

Diagramas de casos de uso Casos de Uso en Métrica 3 ´ EVS 4. Estudio de alternativas de solucion ´ de alternativas de solucion ´ 4.2. Descripcion Se describe el modelo de negocio.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.3/45

Casos de Uso en Métrica 3 ´ de la solucion ´ EVS 6. Seleccion ´ de las alternativas de solucion ´ 6.2. Evaluacion Incluye los modelos de negocio de cada una.

´ del sistema ASI 1. Definicion ´ del alcance del sistema 1.1. Determinacion Se usa el modelo de negocio.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.4/45

Casos de Uso en Métrica 3 ASI 2. Establecimiento de requisitos ´ de requisitos 2.1. Obtencion Se utilizan los casos de uso para establecer los requisitos funcionales.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.5/45

Casos de Uso en Métrica 3 ´ de casos de uso 2.2. Especificacion 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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.6/45

Casos de Uso en Métrica 3 ´ 2.3. Analisis de requisitos Se optimiza el modelo de casos de uso.

´ de requisitos 2.4. Validacion Por parte del usuario.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.7/45

Casos de Uso en Métrica 3 ´ de subsistemas de ASI 3. Identificacion ´ analisis ´ de subsistemas de analisis ´ 3.1. Determinacion Se asignan requisitos y casos de uso a cada subsistema.

´ de subsistemas de analisis ´ 3.2. Integracion Se coordinan los modelos de cada subsistema.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.8/45

Casos de Uso en Métrica 3 ´ ASI 4. Analisis de los casos de uso Se identifican las clases necesarias para cada caso de uso.

´ ASI 9. Analisis de consistencia y ´ de requisitos especificacion ´ de los modelos 9.1. Verificacion

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.9/45

Casos de Uso en Métrica 3 ´ 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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.10/45

Casos de Uso en Métrica 3 ´ de los modelos 9.3. Validacion Según: • El catálogo de requisitos. • El usuario.

´ de la especificacion ´ de requisitos 9.3. Elaboracion software

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.11/45

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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.12/45

Descripción Un diagrama de casos de uso es un grafo constituido por: • actores • casos de uso • relaciones entre elementos

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.13/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.14/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.15/45

Elementos ´ de casos de uso Especificacion 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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.16/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.17/45

Elementos ´ de un escenario Descripcion • 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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.18/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.19/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.20/45

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. c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.21/45

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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.22/45

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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.23/45

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 c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.24/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.25/45

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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.26/45

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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.27/45

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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.28/45

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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.29/45

Relaciones ´ de casos de uso Generalizacion • 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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.30/45

Relaciones ´ de casos de uso Inclusion • 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

aislado c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.31/45

Caso práctico Se presenta una relación de inclusión entre los casos de uso: • Ver un documento

y Buscar un documento

• Imprimir un documento

y Buscar un documento

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.32/45

Caso práctico Escenario normal del caso de uso Ver un documento: incluir(Buscar un documento) El usuario selecciona un documento entre los encontrados El usuario requiere ver el documento El sistema muestra el documento

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.33/45

Caso práctico Escenario de excepción del caso de uso Ver un documento: incluir(Buscar un documento) El usuario requiere ver el documento El sistema muestra un mensaje de error indicando que debe seleccionar un documento El usuario finaliza la petición

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.34/45

Relaciones ´ de casos de uso Extension • 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

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.35/45

Relaciones ´ de casos de uso Extension • 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. c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.36/45

Relaciones ´ de casos de uso Extension 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 c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.37/45

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 c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.38/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.39/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.40/45

Modelado del contexto de un 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. c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.41/45

Modelado del contexto de un sistema 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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.42/45

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.

c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.43/45

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. c 2003 Carlos Rossi Jimenez. ´ ´
Universidad de Malaga – p.44/45

Caso práctico

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