desarrollo orientado a objetos en m etrica v. 3´rossi/prescasosuso.pdf · estructura del curso 1....
TRANSCRIPT
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
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 soluci on
4.2. Descripci on de alternativas de soluci on
Se describe el modelo de negocio.
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.3/45
Casos de Uso en Métrica 3
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.
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.4/45
Casos de Uso en Métrica 3
ASI 2. Establecimiento de requisitos
2.1. Obtenci on de requisitos
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
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.
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.
2.4. Validaci on de requisitos
Por parte del usuario.
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.7/45
Casos de Uso en Métrica 3
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.
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.8/45
Casos de Uso en Métrica 3
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
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
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
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
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
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
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.
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
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
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.30/45
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
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.32/45
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
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.33/45
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
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.34/45
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
c©2003 Carlos Rossi Jimenez. Universidad de Malaga – p.35/45
Relaciones
Extensi on 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
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
Extensi on 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 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