MODELADO DE CASOS DE USO
ORIGEN
La
idea de casos de uso nace desde la década de los 80' con Ivar Jacobson, quien
propuso una forma de describir los requisitos funcionales que se identificaban
a partir de las necesidades de los usuarios. Unos años después, Alistair
Cockburn propuso un modelo para materializar estas descripciones, y definio que
son y como describirlos.Este mismo autor describe a un caso de uso como “Historia de uso de un sistema”, y lo cual resulto ser una excelente técnica para entender y describir requerimientos.
DEFINICION
El
modelado de casos de uso es una técnica más efectiva y a la vez más simple para
modelar los requisitos del sistema desde la perspectiva del usuario.
·Elipse: Figura geométrica curva y cerrada, con dos ejes perpendiculares desiguales, que resulta de cortar la superficie de un cono por un plano no perpendicular a su eje, y que tiene la forma de un círculo achatado.
El
modelado de casos de uso es una técnica más efectiva y a la vez más simple para
modelar los requisitos del sistema desde la perspectiva del usuario.
-Los casos de uso describen bajo la forma de acciones y
reacciones el comportamiento de un sistema desde el punto de vista del usuario,
permiten definir los límites del sistema y las relaciones entre el sistema y el
entorno.
Los componentes primarios de un modelo de
casos de uso (case-use model) son los casos de uso (use cases), los actores y
el sistema modelado. • Los casos de uso son descripciones funcionales del
sistema; describen cómo los actores pueden usar un sistema.
– Los límites del sistema se definen por la
funcionalidad que se maneja en el sistema.
– La
funcionalidad se representa mediante diversos casos de uso, especificando cada
uno una funcionalidad completa (desde su inicio por parte de un actor externo
hasta que haya realizado la funcionalidad requerida). Un caso de uso siempre
debe devolver algún valor a un actor, siendo el valor cualquier cosa que el
actor desee del sistema.
– El actor es una entidad externa que tiene
interés en interactuar con el sistema. A menudo, es una persona que usa el
sistema, pero también puede ser otro sistema o alguna clase de dispositivo
hardware que necesita interactuar con el sistema.
OBJETIVO
El
objetivo final en cualquier diseño de software es satisfacer las necesidades y
requisitos del usuario para el sistema. Estos requisitos pueden ser: requisitos
de software, requisitos de productos o requisitos de pruebas. La meta de
capturar y comprobar los requisitos del usuario s asegurar que todos los
requisitos son completados por el diseño, y que el diseño es acorde con los
requisitos.
Los propósitos primarios de los casos de uso
son:
– Decidir y describir los requerimientos
funcionales del sistema, dando lugar a un acuerdo entre el cliente (y/o usuario
final) y los programadores que desarrollan el sistema.
– Dar una descripción clara y consistente
de lo que debería hacer el sistema, de modo que el modelo se use a lo largo del
proceso de desarrollo.
– Proporcionar una base para realizar
verificaciones (tests) del sistema que comprueben su funcionamiento.
– Proporcionar la capacidad para rastrear
requerimientos funcionales en clases y operaciones reales del sistema,
verificando los casos de uso afectados por cambios y extensiones al sistema.
DIAGRAMA
DE CASOS DE USO
Un
modelo de casos de uso se describe en UML mediante un diagrama de casos de uso
(use-case diagram) y puede dividirse en varios diagramas de casos de uso.
Un
diagrama de casos de uso contiene elementos del modelo para el sistema, los
actores y los casos de uso, y muestra las diferentes relaciones entre estos
elementos.
Un
sistema en un diagrama de casos de uso se describe mediante un rectángulo que
contiene el nombre del sistema y los símbolos de los casos de uso en el
sistema.
ACTOR:
Un
actor es alguien o algo que interactúa con el sistema, pero que es externo al
sistema.
Un
actor es una clase, no una instancia. El actor representa un papel, no a un
usuario individual del sistema.
RELACION ENTRE ACTORES:
Los
actores en UML son clases con el estereotipo <> y tienen un
estereotipo icono estándar. El nombre de la clase es el nombre del actor.
Cuando
varios actores, como parte de sus papeles, también representan un papel más
generalizado, se describe mediante una relación de generalización
CASO DE USO:
Un caso de uso
representa una funcionalidad completa tal como la percibe un actor.
Un caso de uso en
UML se define como una secuencia de acciones que realiza un sistema y que
conduce a un resultado observable. – Las acciones pueden envolver comunicación
con diversos actores.
Un caso de uso se
representa en UML mediante una elipse que contiene el nombre del caso de uso, o
con el nombre del caso de uso debajo.
Los casos de uso
se conectan a los actores mediante asociaciones, denominadas líneas de
comunicación (communication lines).
RELACIONES ENTRE CASOS DE USO:
- Relación de extensión (extend): un caso de
uso añade acciones, que pueden ser opcionales, al comportamiento de un caso de
uso general.
- Relación de inclusión (include): un caso de
uso incluye el comportamiento completo de un caso de uso general.
- Relación de generalización: en el caso de
uso especializado se especifican los pasos extra que es necesario añadir al
caso de uso general, para representar una funcionalidad diferente a la
original.
ANALISIS DE REQUERIMIENTOS
El proceso
de análisis de requerimientos debe producir una definición clara de los requerimientos
para el nuevo sistema desde la cual puedan trabajar los desarrolladores y
contra la cual puedan validarse los resultados.
Durante el análisis del negocio se producen
un modelo d la forma en que actualmente funciona la empresa. Durante el análisis
de requerimientos, se modela como la empresa operara utilizando el nuevo
sistema.
El punto de arranque el análisis de
requerimientos depende del contexto en el cual una aplicación es desarrollada. Cuando
el dominio del negocio para la aplicación es pequeño y bien comprendido,
entonces la fase de análisis del negocio es muy breve. El análisis de
requerimientos parte de los modelos del análisis del negocio que contiene muy
poco detalle.
Se describen 3 diagramas:
A. MODELO
DE CASOS DE USO DEL NEGOCIO (MCUN)
Permite describir los procesos
generales del negocio y sus relaciones con los participantes externos, como
clientes y socios.
B. MODELO
DE OBJETOS DEL NEGOCIO (MON)
Este modelado de objetos se
puede realizar en simultáneo con el
modelado de procesos de negocio. Sin embargo se recomienda comenzar modelando
los objetos ya que son la esencia de este enfoque.
Modelo de objetos de vender productos
Modelo de objetos de seguimiento y consulta de productos
Modelo de objetos de reponer stock
Modelo de objetos de modificar catalogo
Modelo de objetos de realizar entrega
C. MODELO
DEL DOMINIO(MD)
Es una representación visual estatica del entorno real objeto del
proyecto. Es un diagrama con los objetos que existen
(reales) relacionados con el proyecto que se va a desarrollar y las relaciones que
hay entre ellos. Pero no son clases de
software (aunque algunos objetos del Modelo de Dominio pueden terminar siéndolo).
RESUMEN
•
Un caso de uso especifica un comportamiento deseado
del sistema.
•
Representan los requisitos funcionales del sistema.
“Un caso de uso
especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor
para un particular actor.”
•
Describen qué
hace el sistema, no cómo lo hace.
•
Un actor representa un
conjunto coherente de roles que juegan los usuarios de los casos de uso al
interaccionar con el sistema.
•
Un caso de uso describe un conjunto de secuencias de interacciones entre actores y
el sistema.
•
Un escenario es una instancia de un caso de uso
•
Con un caso de uso se describe un comportamiento
esperado del sistema, pero no se especifica cómo se implementa.
SUMMARY
• A use case
specifies a desired system behavior.
• Represent the
functional requirements of the system.
" A use case
specifies a set of sequences of actions , including variants , the system can
run and produce an observable result of value to a particular actor. "
• describe what
the system does, not how.
• An actor
represents a coherent set of roles that users of use cases interact with the
system to play .
• A use case
describes a set of sequences of interactions between actors and the system.
• A scenario is an
instance of a use case
• In a case of
using an expected system behavior described , but did not specify how it is
implemented .
RECOMENDACIONES:
•
Especificar casos de uso no es una actividad de
dibujar diagramas sino de escribir con el detalle necesario el flujo principal y
los flujos alternativos: “centrado en la escritura en vez del dibujo”.
•
No hay que preocuparse demasiado por las relaciones
entre casos de uso ni entre actores.
•
El objetivo inicial es identificar los actores y a
partir de sus objetivos encontrar los casos de uso, ya que el diagrama de casos
de uso es una ayuda visual.
•
Los actores deben interactuar con el sistema.
CONCLUSIONES:
La
diagramación de casos de uso puede dirigir el proceso de desarrollo. Los
diagramas de Casos de Uso guían el diseño, la implementación y las pruebas del
sistema.
A
pesar que son parte del desarrollo orientado a objetos, son una excelente
entrada para introducirse en este paradigma.
GLOSARIO DE TERMINOS:
·Elipse: Figura geométrica curva y cerrada, con dos ejes perpendiculares desiguales, que resulta de cortar la superficie de un cono por un plano no perpendicular a su eje, y que tiene la forma de un círculo achatado.
·Programador: Persona que se dedica a elaborar programas
informáticos.
·Líderes una persona que actúa como guía o jefe de un grupo.
· Implantación: Efecto de implantar.
·Simultaneo: Que ocurre o se hace al mismo tiempo que
otra cosa.
· Nodo: Es un espacio en el que confluyen parte de
las conexiones de otros espacios reales o abstractos que comparten sus mismas
características y que a su vez también son nodos.
· Tabulares: Expresar valores, magnitudes
u otros datos por medio de tablas.
· Dependencia: Situación de la persona o
cosa que depende de otras.
· Generalización: Es la base esencial de
toda inferencia deductiva válida.
· Prototipo: Persona o cosa que reúne en grado máximo
las características principales de cierto tipo de cosas y puede representarlas.
LINKOGRAFIA
No hay comentarios:
Publicar un comentario