Desarrollo Orientado a Objetos en Métrica v. 3

Transcripción

1 Desarrollo Orientado a Objetos en Métrica v. 3 Carlos Rossi Jiménez c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.1/45

2 Estructura del curso 1. Estructura de Métrica v 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 Jiménez. Universidad de Málaga p.2/45

3 Diagramas de casos de uso Casos de Uso en Métrica 3 EVS 4. Estudio de alternativas de solución 4.2. Descripción de alternativas de solución Se describe el modelo de negocio. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.3/45

4 Casos de Uso en Métrica 3 EVS 6. Selección de la solución 6.2. Evaluación de las alternativas de solución Incluye los modelos de negocio de cada una. ASI 1. Definición del sistema 1.1. Determinación del alcance del sistema Se usa el modelo de negocio. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.4/45

5 Casos de Uso en Métrica 3 ASI 2. Establecimiento de requisitos 2.1. Obtención de requisitos Se utilizan los casos de uso para establecer los requisitos funcionales. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.5/45

6 Casos de Uso en Métrica Especificación 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. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.6/45

7 Casos de Uso en Métrica Análisis de requisitos Se optimiza el modelo de casos de uso Validación de requisitos Por parte del usuario. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.7/45

8 Casos de Uso en Métrica 3 ASI 3. Identificación de subsistemas de análisis 3.1. Determinación de subsistemas de análisis Se asignan requisitos y casos de uso a cada subsistema Integración de subsistemas de análisis Se coordinan los modelos de cada subsistema. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.8/45

9 Casos de Uso en Métrica 3 ASI 4. Análisis de los casos de uso Se identifican las clases necesarias para cada caso de uso. ASI 9. Análisis de consistencia y especificación de requisitos 9.1. Verificación de los modelos c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.9/45

10 Casos de Uso en Métrica Análisis 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 Jiménez. Universidad de Málaga p.10/45

11 Casos de Uso en Métrica Validación de los modelos Según: El catálogo de requisitos. El usuario Elaboración de la especificación de requisitos software c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.11/45

12 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 Jiménez. Universidad de Málaga p.12/45

13 Descripción Un diagrama de casos de uso es un grafo constituido por: actores casos de uso relaciones entre elementos c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.13/45

14 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 Jiménez. Universidad de Málaga p.14/45

15 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 Jiménez. Universidad de Málaga p.15/45

16 Elementos Especificación 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 c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.16/45

17 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. Instanciadeuncasodeuso. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.17/45

18 Elementos Descripción 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. c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.18/45

19 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 Jiménez. Universidad de Málaga p.19/45

20 Caso práctico Para una rápida recuperación de los documentos almacenados usando el PCEse 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 Jiménez. Universidad de Málaga p.20/45

21 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 Jiménez. Universidad de Málaga p.21/45

22 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 Jiménez. Universidad de Málaga p.22/45

23 Caso práctico: escenarios E scenario 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 Jiménez. Universidad de Málaga p.23/45

24 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 Jiménez. Universidad de Málaga p.24/45

25 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 Jiménez. Universidad de Málaga p.25/45

26 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 Jiménez. Universidad de Málaga p.26/45

27 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 Jiménez. Universidad de Málaga p.27/45

28 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 Jiménez. Universidad de Málaga p.28/45

29 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 Jiménez. Universidad de Málaga p.29/45

30 Relaciones Generalización 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 c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.30/45

31 Relaciones Inclusión 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 aislado c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.31/45

32 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 Jiménez. Universidad de Málaga p.32/45

33 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 Jiménez. Universidad de Málaga p.33/45

34 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 Jiménez. Universidad de Málaga p.34/45

35 Relaciones Extensión 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 c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.35/45

36 Relaciones Extensión de casos de uso 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 incorporaelcomportamientodeotrocasodeusoenun 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 Jiménez. Universidad de Málaga p.36/45

37 Relaciones Extensión de casos de uso 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 Jiménez. Universidad de Málaga p.37/45

38 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 Jiménez. Universidad de Málaga p.38/45

39 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 Jiménez. Universidad de Málaga p.39/45

40 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 Jiménez. Universidad de Málaga p.40/45

41 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 Jiménez. Universidad de Málaga p.41/45

42 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 Jiménez. Universidad de Málaga p.42/45

43 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 Jiménez. Universidad de Málaga p.43/45

44 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 Jiménez. Universidad de Málaga p.44/45

45 Caso práctico c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.45/45