viernes, 9 de diciembre de 2016
Diagramas de caso de uso
El diagrama de casos de uso representa la forma en como
un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo
y orden en como los elementos interactúan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes
elementos:
Elementos
Una definición
previa, es que un Actor es un rol que un usuario juega con respecto
al sistema. Es importante destacar el uso de la palabra rol, pues con esto
se especifica que un Actor no necesariamente representa a una persona en
particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la
definición anterior, tenemos el caso de un sistema de ventas en que el rol de
Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por
el Jefe de Local. (htt4)
Es una
operación/tarea específica que se realiza tras una orden de algún agente
externo, sea desde una petición de un actor o bien desde la invocación desde
otro caso de uso.
Relaciones:
Asociación
Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha
relación se denota con una flecha simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en
la cual una clase depende de otra, es decir, se instancia (se crea). Dicha
relación se denota con una flecha punteada.
Generalización
Este tipo de relación es uno de los más utilizados,
cumple una doble función dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o
de Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente para
casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es
similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto
de características que son similares en más de un caso de uso y no se desea
mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo
paradigma en diseño y modelamiento de clases, en donde esta la duda clásica
de usar o heredar.
Qué es UML
El Lenguaje
Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar
para modelar sistemas orientados a objetos, y describe la semántica esencial de
lo que estos diagramas y símbolos significan. Mientras que ha habido muchas
notaciones y métodos usados para el diseño orientado a objetos, ahora los
modeladores sólo tienen que aprender una única notación. UML se puede usar para
modelar distintos tipos de sistemas: sistemas de software, sistemas de
hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los
cuales modelar sistemas. (htt1)
• Diagramas de
Casos de Uso para modelar los procesos ’business’.
• Diagramas de Secuencia para modelar el paso de mensajes
entre objetos.
• Diagramas de Colaboración
para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de
los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento
de los Casos de Uso, objetos u operaciones. • Diagramas de Clases para modelar
la estructura estática de las clases en el sistema.
• Diagramas de
Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de
Componentes para modelar componentes.
• Diagramas de Implementación para modelar la
distribución del sistema.
UML es una consolidación de muchas de las notaciones y
conceptos más usadas orientados a objetos. Empezó como una consolidación del
trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de
las metodologías orientadas a objetos más populares. En 1996, el Object
Management Group (OMG), un pilar estándar para la comunidad del diseño
orientado a objetos, publicó una petición con propósito de un metamodelo
orientado a objetos de semántica y notación estándares. UML, en su versión 1.0,
fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras
cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de
las propuestas, unieron su trabajo y presentaron al OMG un documento revisado
de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en
Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG
está actualmente en proceso de mejorar una edición técnica de esta
especificación, prevista su finalización para el 1 de abril de 1999. (htt)
Extensiones UML
Los mecanismos de de extensibilidad incorporados permiten a
UML ser una especie de especificación abierta que puede cubrir aspectos de
modelado no especificados en el documento
1.1. Estos mecanismos permiten extender la notación y
semática de UML.
2.3.1. Esteroetipos Los estereotipos son el mecanismo de
extensibilidad incorporado más utilizado dentro de UML. Un estereotipo
respresenta una distinción de uso. Puede ser aplicado a cualquier elemento de
modelado, incluyendo clases, paquetes, relaciones de herencia, etc.
Por ejemplo, una clase con estereotipo ’actor’ es una clase
usada como un agente externo en el modelado de negocio. Una clase patrón es
modelada como una clase con estereotipo parametrizado, lo que significa que
puede contener parámetros.
2.3.2. Extensiones de Modelado de Negocio Un documento
separado dentro de la especificación UML define clases y estereotipos de
asociación específicos que extienden UML hasta cubrir conceptos de modelado de
negocio. Esto incluye ’stereotyping’ una clase como un actor, un trabajador
(’both internal and case’), o una entidad, y ’stereotyping’ una asociación como
una comunicación simple, o una subcripción entre un origen y un objetivo. (htt2)
2.3.3. Lenguaje restrictivo (constraint) de objetos (OCL)
Una imagen puede describir muchas palabras. De igual modo, un modelo gráfico
puede describir una cierta parte del comportamiento, después de la cual es
necesario rellenar detalles adicionales con palabras. Describiendo algo con
palabras, sin embargo, casi siempre desemboca en ambiguedades; por ejemplo,
"¿que quería decir cuando escribió eso?". El Lenguaje Restrictivo
(constraint) de Objetos (OCL) está incorporado en UML como un estándar para
especificar detalles adicionales, o precisar detalles en la estrucutura de los
modelos. Desarrollado dentro de la IBM Insurace Division como un lenguaje de
modelado de negocio, el OCL es un lenguaje formal diseñado para ser fácil de
leer y de escribir. OCL es más funcional que el lenguaje natural, pero no tan
preciso como un lenguaje de programación - no puede ser usado para escribir
lógicas de lógica de programación o control de flujo. Puesto que OCL es un
lenguaje para la expresión pura, sus declaraciones están garantizadas de no
tener efectos laterales - simplemente transportan un valor y nunca pueden
cambiar el estado del sistema. (htt3)
Suscribirse a:
Entradas (Atom)