Trabajo 1
Analisis y diseño de sistema
Integrantes:
Rusbel Dimas 8898650
Yumar Solórzano 11004494
Rocny Suárez 13030072
Juan Maestre
140155512
1.- Para que sirve UML
- Torres,P (s/n) Unified Modeling
Language Es una herramienta que sirve
como enlace entre quien tiene la
idea y el desarrollador, ya que ayuda a capturar la idea de un sistema
para comunicarla posteriormente a quien esté involucrado en su proceso de
desarrollo, esto se lleva a cabo mediante un conjunto de símboloas y diagramas. Cada diagrama tiene fines
distintos dentro de un proceso de desarrollo.
Hernández,
E (2005) Se ha convertido en ese estándar tan ansiado
para representar y modelar la información con la que se trabaja en las fases de
análisis y, especialmente, de diseño. Otro objetivo de este modelado visual es que
sea independiente del lenguaje de implementación, de tal forma que los diseños
realizados usando UML se puedan implementar en cualquier lenguaje que soporte
las posibilidades de UML (principalmente lenguajes orientados a objetos).
Extraido de http://es.wikipedia.org/wiki/UML
(S/A) CONSULTADO Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de
sistemas de software
más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje
gráfico para visualizar, especificar, construir y documentar un sistema de
software. UML ofrece un estándar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes
de programación, esquemas de bases de datos y componentes de software
reutilizables.
Es
importante resaltar que UML es un "lenguaje" para especificar y no
para describir métodos o procesos. Se utiliza para definir un sistema de
software, para detallar los artefactos en el sistema y para documentar y
construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en una gran variedad de formas para dar soporte a una
metodología de desarrollo de software (tal como el Proceso Unificado Racional o
RUP), pero no
especifica en sí mismo qué metodología o proceso usar.
UML
no puede compararse con la programación estructurada, pues UML significa
(Lengua de Modelación Unificada), no es programación, solo se diagrama la
realidad de una utilización en un requerimiento. Mientras que, programación
estructurada, es una forma de programar como lo es la orientación a objetos,
sin embargo, la orientación a objetos viene siendo un complemento perfecto de
UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos
UML
es además un método formal de modelado. Esto aporta las siguientes ventajas:
• Mayor rigor en
la especificación.
• Permite
realizar una verificación y validación del modelo realizado.
• Se pueden
automatizar determinados procesos y permite generar código a partir de los mode-los y a la inversa (a partir del código fuente ge-nerar los modelos). Esto permite que el modelo y el código
estén actualizados, con lo que siem-pre se puede mantener la visión en el diseño, de más alto
nivel, de la estructura de un proyecto.
Las
objetivos de UML son muchos, pero se pue-den
sintetizar sus funciones:
• Visualizar:
UML permite expresar de una for-ma
gráfica un sistema de forma que otro lo puede entender.
• Especificar:
UML permite especificar cuáles son las características de un sistema antes de
su construcción.
Construir: A
partir de los modelos especifica-dos se pueden construir los sistemas
diseñados.
• Documentar: Los
propios elementos gráficos sirven como documentación del sistema des-arrollado
que pueden servir para su futura re-visión.
2.- Modelos o diagramas que contienen.
Descripción. Características Ejemplos.
Un
modelo UML esta compuesto por tres clases de bloques de construcción:
• Elementos: Los
elementos son abstracciones de cosas reales o ficticias (objetos, acciones,
etc.)
• Relaciones:
relacionan los elementos entre sí.
• Diagramas: Son
colecciones de elementos con sus relaciones.
Un diagrama es la representación gráfica de un
conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una
vista del sistema a modelar. Para poder representar correctamente un sistema,
UML ofrece una amplia variedad de diagramas para visualizar el sistema desde
varias perspectivas. UML incluye los siguientes diagramas:
• Diagrama de
casos de uso.
• Diagrama de
clases.
• Diagrama de
objetos.
• Diagrama de
secuencia.
Diagrama de colaboración.
• Diagrama de
estados.
• Diagrama de
actividades.
• Diagrama de
componentes.
• Diagrama de
despliegue.
Los
diagramas más usados son los de casos de
uso, clases y secuencia,. Pare ello, se utilizará
ejemplos de un sistema de venta de entradas de cine por Internet.
El diagrama
de casos de usos representa gráficamente los casos de uso que tiene un
sistema. Se define un caso de uso como cada interacción supuesta con el sistema
a desarrollar, donde se representan los requisitos funcionales. Es decir, se
está diciendo lo que tiene que hacer un sistema y cómo. En la figura 3 se mues-tra un ejemplo de casos de
uso, donde se muestran tres actores (los clientes, los taquilleros y los jefes
de taquilla) y las operaciones que pueden realizar (sus roles).
3. Utilidad de cada uno de los diagramas.
Los diferentes diagramas
soportados por UML son los siguientes:
Diagrama
de clases. Muestra las clases, interfaces, colaboraciones y sus relaciones. Son
los más comunes y dan una vista estática del proyecto.
Diagrama
de objetos. Es un diagrama de instancias de las clases mostradas en el diagrama de
clases. Muestra las instancias y como se relacionan entre ellas. Se da una
visión de casos reales.
Diagrama
de componentes. Muestra la organización de los componentes del sistema. Un componente
se corresponde con una o varias clases, interfaces o colaboraciones.
Diagrama
de despliegue. Muestra los nodos y sus relaciones. Un nodo es un conjunto de
componentes. Se utiliza para reducir la complejidad de los diagramas de clases
y componentes de un gran sistema. Sirve como resumen e índice.
Diagrama
de casos de uso. Muestra los casos de uso, actores y sus relaciones.
Muestra quien puede hacer que y las relaciones existen entre acciones (casos de
uso). Son muy importantes para modelar y organizar el comportamiento del
sistema.
Diagrama
de secuencia y diagrama de colaboración. Muestran a los diferentes
objetos y las relaciones que pueden tener entre ellos, los mensajes que se
envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a
otro sin perdida de información, pero que dan puntos de vista diferentes del
sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.
Diagrama
de estados. Muestra los estados, eventos, transiciones y actividades de los
diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
Diagrama
de actividades. Es un caso especial del diagrama de estados. Muestra
el flujo entre los objetos. Se utilizan para modelar
el funcionamiento del sistema y el flujo de control entre objetos.
2.9.4 Diagramas de Casos de Uso.
Los diagramas de casos de uso
se emplean para visualizar el comportamiento del sistema, una parte de él o de
una sola clase. De forma que se pueda conocer como responde esa parte del
sistema. El diagrama casos de uso es muy útil para definir como debería
ser el comportamiento de una parte del sistema, ya que solo especifica como
deben comportarse y no como están implementadas las partes que define. Por ello
es un buen sistema de documentar partes del código que deban ser reutilizables
por otros desarrolladores. El diagrama también puede ser utilizado para que los
expertos de dominio se comuniquen con los informáticos sin llegar a niveles de
complejidad. Un caso de uso especifica un requerimiento funcional, es decir
indica esta parte debe hacer esto cuando pase esto.
Los
casos de uso permiten a los usuarios estructurar y articular sus deseos; les
obligan a definir la manera como querrían interactuar con el sistema, a
precisar qué informaciones quieren intercambiar y a describir lo que debe
hacerse para obtener el resultado esperado. Los casos de uso concretan el
futuro sistema en una formalización próxima al usuario; favorecen la definición
de un cuaderno de cargas que refleja realmente las necesidades, incluso en
ausencia de un sistema a criticar.
El modelo de casos de uso
comprende los actores, el sistema y los propios casos de uso. El conjunto de
funcionalidades de un sistema se determina examinando las necesidades
funcionales de cada actor, expresadas en forma de familias de interacciones en
los casos de uso.
Sistema. Éste identifica
las diferentes partes del sistema y contiene los casos de uso que lo forman. Se
representan mediante un cuadro u hoja (Ver Figura 2.9).
Figura 2.9. Representación
de un sistema en un diagrama de casos de uso
Casos
de Uso. Es una manera específica de utilizar el sistema. Es la imagen de una
funcionalidad del sistema, desencadenada en respuesta a la estimulación de un
actor externo. Se representan mediante una elipse (Ver Figura 2.10).
Los casos de uso tienen las
siguientes características:
-Son interacciones o diálogos
entre el sistema y los actores, incluyendo mensajes intercambiados y acciones
realizadas por el sistema.
-Son iniciados por actores, y
pueden incluir la participación de varios de ellos. Los casos de uso deben
proveer valor a al menos uno de los actores participantes.
-Pueden tener puntos de
extensión que definen puntos específicos en una interacción, en la cual otros
casos de uso pueden ser insertados.
Las clases de casos de uso
tienen instancias ú objetos llamadas escenarios, que representan interacciones
específicas. Los escenarios representan una secuencia única de escenarios e
interacciones.
Figura 2.10. Representación
de un caso de uso en un diagrama UML.
Actores.
Un actor representa un papel
interpretado por una persona o una cosa que interactúa con el sistema. Los actores
se determinan observando los usuarios directos del sistema, los responsables de
su uso o de su mantenimiento, así como los otros sistemas que interactúan con
el sistema en cuestión. La misma persona física puede interpretar el papel de
varios actores (vendedor, cliente). Por otra parte, varias personas pueden
interpretar el mismo papel y actuar por tanto, como el mismo actor (todos los
clientes). El nombre del actor describe el papel interpretado por el mismo. Los
actores se representan con un muñeco (Ver Figura 2.11).
Los actores tienen las
siguientes características:
· Son externos al
sistema.
· Interactúan con el
sistema. Los actores pueden utilizar funcionalidades provistas por el sistema,
pero también pueden proveer funcionalidad al sistema. Los actores pueden
obtener o ingresar información al sistema.
· Las clases de
actores, tienen instancias ú objetos que representan actores específicos.
Figura 2.11. Representación
de un actor en un diagrama de casos de uso.
Relaciones.
“Las relaciones de asociación
entre actores y casos de uso, son utilizadas para indicar participación y
comunicación entre estos elementos. Estas relaciones son denotadas como líneas
sólidas o caminos”. [5]. Las puntas de las flechas indican quién es el destino
de la interacción, es decir, el lado contrario de la asociación al que tiene la
punta de la flecha, es quien inicia la interacción (Ver Figura 2.12).
Relación
de asociación. “Indica la participación de un actor en un caso de uso; esto significa
que, un instancia del actor y una instancia del caso de uso se comunican un con
el otro. Éste es el único tipo de relación entre actores y casos de uso”. [3]
Se representa con una línea sólida entre los elementos y una flecha abierta
puede indicar quién inicia la relación. La representación puede ser adornada
con la etiqueta <<comunicate>> o también
con multiplicidad.
Figura 2.12. Representación
de una relación de comunicación en un caso de uso.
Relación
de inclusión. Una relación de inclusión de un caso de uso A a
un caso de B indica que una instancia del caso de uso A contiene el
comportamiento especificado por una instancia del caso de uso B. Se representa
con una línea punteada entre los elementos y una flecha abierta puede indicar
quién inicia la relación, sobre la línea debe ir la etiqueta <<include>> (Ver Figura 2.13).
Figura 2.13. Representación
de una relación de inclusión en un caso de uso.
Relación
de extensión. Indica que un caso de uso base puede ser aumentado por un caso de uso
de extensión, en caso de que se satisfaga una condición de extensión. Un caso
de uso base define un punto de extensión, mientras que un caso de uso de
extensión define la condición de extensión que debe ser satisfecha de manera
que se inserte la extensión del caso de uso, en el caso de uso base. Inserción
de un caso de extensión implica la ejecución del caso de uso base hasta el
punto de extensión, para luego probar la condición de extensión, e insertar y
ejecutar el caso de uso de extensión, en caso de que la condición haya sido
satisfecha (Ver Figura 2.14).
Relación
de Generalización. Las relaciones de generalización de casos de uso son
utilizadas, para indicar que un caso de uso de especialización es consistente
un caso de uso generalizado y puede agregarle más información. Un caso de uso
de especialización puede ser utilizado en lugar de un caso de uso generalizado
y puede utilizar cualquier porción de la interacción del caso de uso
generalizado.
Las relaciones de generalización
también se pueden utilizar con los actores de la misma forma que con los casos
de uso. En la Figura 2.15 se muestra un ejemplo de un caso de uso con
relaciones de generalización.
Figura 2.15. Ejemplo de
relaciones de generalización en un diagrama UML.
Los
diagramas de clases expresan de manera general la estructura estática de un
sistema, en términos de clases y de relaciones entre estas clases. Al igual que
una clase describe un conjunto de objetos, una asociación describe un conjunto
en enlaces; los objetos son instancias de clases y los enlaces son instancias
de relaciones. Un diagrama de clases no expresa nada de particular sobre los
enlaces de un objeto dado, pero describe de manera abstracta los enlaces
potenciales de un objeto hacia otros objetos.
Clases.
La clase describe el ámbito
de definición de un conjunto de objetos. Cada objeto pertenece a una clase. Las
generalidades están contenidas la clase y las particularidades en los objetos.
Las clases son representadas por rectángulos con compartimientos. El primero
contiene el nombre de la clase. Una clase es una descripción abstracta y
condensada de un conjunto de objetos del ámbito de la aplicación. Los otros dos
compartimientos contienen respectivamente los atributos y operaciones de la
clase.
El rectángulo que simboliza
la clase puede contener también un estereotipo y propiedades. UML define los
estereotipos estándar de clase siguientes:
<<signal>> o <<señal>>, es una
ocurrencia remarcable que desencadena una transacción en un autómata.
<<interface>> o <<interfaz>>, una
descripción de las operaciones visibles.
<<metaclass>> o <<metaclase>>,
la clase de una clase.
<<utility>> o <<utilidad>>, es una
clase reducida al concepto de un módulo y a partir de la cual no se pueden
crear objetos.
Atributos
y Operaciones.
Los atributos y operaciones
pueden ser mostrados de manera exhaustiva o no en los comportamientos de las
clases. Por convención el primer compartimiento tiene los atributos y el
segundo las operaciones.
Para describir los atributos
se debe seguir la siguiente sintaxis:
Nombre_Atributo: Tipo_Atributo
= Valor_Inicial
Esta descripción puede
completarse progresivamente en la transición del análisis hacia el diseño.
Ocurre que se especifican propiedades redundantes en el análisis de las
necesidades.
La sintaxis seguida para la
descripción para la descripción de las operaciones es la siguiente:
Nombre_Operación (Nombre_Argumento:
Tipo_Argunmento = Valor_Predeterminado,...):
Tipo_Devuelto
UML define tres niveles de
visibilidad para los atributos y operaciones:
Publico: que hace el elemento
visible a todos los clientes de la clase.
Privado: que hace el elemento
visible sólo para la clase
Protegido: que hace el
elemento visible a las subclases de la clase.
La información de seguridad
no figura siempre de manera explícita en los diagramas de clases, lo que no
quiere decir que la visibilidad no sea definida en el modelo. De modo
predeterminado, el nivel de visibilidad se simboliza por los caracteres +, # y
-, que corresponden respectivamente, a loos niveles público, protegido y privado
(una notación parecida utiliza un candado para el nivel privado, una llave para
el protegido y nada para el público, así como un rombo azul para los atributos
y uno morado para las operaciones) (Ver Figura 2.16).
Ciertos atributos y/o
operaciones pueden ser visibles globalmente, en toda la amplitud léxica de la
clase. Estos elementos, también llamados variables y operaciones de la clase o
compartidos, se representan como un objeto por un nombre subrayado. La notación
se justifica por el hecho de que una variable de clase aparece como un objeto
compartido por las instancias de una clase. Por extensión, las operaciones de
clase también son subrayadas.
También existen una clase de
atributos, llamados atributos derivados, estas propiedades son derivadas a
partir de otras propiedades ya asignadas. Generalmente implican un cálculo a
partir de otras propiedades. Ejemplo en una clase persona, donde el atributo
Nombre es “María” y el atributo Apellido es “López”, el atributo derivado Nombre_Completo puede ser “María López”. Éstos se señalan
con el signo /.
Figura 2.16. Ejemplo de la
representación de una clase en un diagrama UML.
Interfaces.
Una interfaz utiliza un tipo
para describir el comportamiento visible de una clase, de un componente o de un
paquete. Una interfaz es un estereotipo de un tipo. UML representa las
interfaces por medio de pequeños círculos enlazados por un trazo al elemento
que proporciona los servicios descritos por la interfaz. (Ver Figura 2.17).
Las interfaces también se
pueden representar mediante clases estereotipadas. Una interfaz proporciona una
vista total o parcial de un conjunto de servicios ofrecidos por uno o varios
elementos. Los dependientes de una interfaz utilizan todos o parte de los
servicios descritos en la interfaz.
Figura 2.17. Ejemplo de la
representación de las interfaces en un diagrama UML.
Clases
Parametrizables.
Las clases parametrizables
son modelos de clases. Una clase parametrizable puede ser utilizada tal cual.
Conviene primero crear una instancia de la misma, a fin de obtener una clase
real que podrá a su vez ser instanciada a fin de
crear objetos. En la creación de las instancias, los parámetros efectivos
personalizan la clase real obtenida a partir de la clase parametrizable. Las
clases parametrizables permiten construir colecciones universales, con tipo por
los parámetros efectivos (Ver Figura 2.18).
Figura 2.18. Representación
de una clase parametrizable en un diagrama de clases.
Clases
Utilitarias.
Son una agrupación de
elementos (funciones generalmente) dentro de un módulo, que constituyen una
clase completa, pero que pueden ser representados gráficamente como una clase
convencional (Ver Figura 2.19). Éstas no pueden ser instanciadas,
ya que no son un tipo de datos, pero tampoco deben ser confundidas con las
clases abstractas (éstas son clases que tampoco pueden ser instanciadas,
pero que únicamente sirven como base para la creación de otras clases mediante
la herencia).
Figura 2.19. Ejemplos de
clases utilitarias en un diagrama de clases.
Asociaciones.
Las asociaciones presentan
relaciones estructurales entre clases. Una asociación en general es una línea
que une dos o más símbolos (Ver Figura 2.20). Pueden tener varios tipos de
adornos, que definen su semántica y características.
La mayoría de las
asociaciones se llaman binarias porque relacionan dos clases.
Figura 2.20. Representación
de una asociación entre clases en un diagrama UML.
Pueden existir, sin embargo,
relaciones superiores y se representan entonces por medio de un rombo al que
llegan los diferentes componentes de la asociación. Las asociaciones n-arias
pueden representarse generalmente promoviendo la asociación al rango de clase y
añadiendo una restricción que expresa que las múltiples ramas de la asociación
se instancian todas simultáneamente, en un mismo
enlace. Como en las asociaciones binarias, los extremos de una asociación
n-aria se llaman funciones y pueden tener un nombre.
El extremo de una asociación
se llama función. Cada asociación binaria posee dos funciones, una en cada
extremo. La función describe cómo una clase ve a la otra a través de una
asociación. Una función se nombre por medio de una forma nominal. Visualmente,
el nombre de una función se distingue del nombre de la asociación porque se
coloca cerca de un extremo de la asociación. Estas funciones también pueden ser
públicas, privadas o protegidas.
Cada función de una
asociación lleva una indicación de multiplicidad que muestra cuántos objetos de
la clase considerada pueden ser relacionados con un objeto de la otra clase. La
multiplicidad es una información consecuencia de la función bajo la forma de
una expresión entera acotada (Ver Figura 2.21).
Figura 2.21. Ejemplo de
asociaciones con multiplicidad en un diagrama de clases.
Los valores de multiplicidad
expresan restricciones relacionadas con el ámbito de la aplicación, válidas
durante toda la existencia de los objetos. Las multiplicidades no deben
considerarse durante los regímenes transitorios, como en la creación o destrucción
de objetos.
Todo tipo de restricciones
pueden definirse sobre una relación o sobre un grupo de relaciones. La
multiplicidad es una de ellas. Otras restricciones se pueden representar en el
diagrama como expresiones encerradas entre llaves (Ver Figura 2.22).
Figura 2.22. Representación
de asociaciones con restricciones en un diagrama de clases.
Las asociaciones pueden en
lazar también una clase a sí misma, como el caso de las estructuras recursivas.
Este tipo de asociación se llama asociación reflexiva.
Clases
Asociaciones.
Una asociación puede
representarse mediante una clase, en algunos casos para añadir atributos y
operaciones a la asociación. Estas son llamadas clases asociativas o
clases-asociación. La notación utiliza una línea punteada para vincular una
clase a una asociación (Ver Figura 2.23). Una asociación que contiene atributos
sin participar en relaciones con otras clases se llama asociación atribuida. En
este caso, la clase vinculada a la asociación puede no recibir un nombre
específico.
Figura 2.23. Representación
de una clase asociativa en un diagrama de clases.
Navegación.
Los enlaces pueden ser vistos
como canales de navegación entre los objetos. Estos canales permiten
desplazarse en el modelo y realizar las formas de colaboración que corresponden
a los diferentes escenarios.
En principio, las
asociaciones son navegables en ambas direcciones. En ciertos casos sólo es útil
una dirección de navegación; esto se representa por una flecha orientada por la
función hacia la que la navegación es posible (Ver Figura 2.24). La ausencia de
ésta indica que la asociación es navegable en ambos sentidos.
Figura 2.24. Representación
de una asociación navegable en un diagrama de clases.
Calificativos.
El calificativo en una
asociación consiste en seleccionar un subconjunto de objetos entre el conjunto
de objetos que participan en una asociación. El calificativo se realiza por
medio de una tupla de atributos particulares (llamada
clave) y se utiliza conjuntamente con un objeto de la clase de partida. La
clave representa sobre la función de la clase de partida, en un compartimiento
rectangular (Ver Figura 2.25). La clave pertenece plenamente a la asociación y
no a las clases asociadas.
Figura 2.25. Representación
de una asociación con calificativos en un diagrama UML.
Agregaciones.
Una agregación representa una
asociación no simétrica en la que uno de los extremos cumple un papel
predominante respecto al otro extremo. Sea cual sea la multiplicidad, la
agregación sólo afecta a una función de una asociación. La agregación se
representa añadiendo un pequeño rombo al lado agregado (Ver Figura 2.26).
Figura 2.26. Representación
de una asociación de agregación en un diagrama de clases.
Los criterios siguientes
implican una agregación:
· Una clase forma
parte de otra clase.
· Los valores de
atributo de una clase se propagan en los valores de atributos de otra clase
· Una acción sobre
una clase implica una acción sobre la otra clase.
· Los objetos de una
clase son subordinados a los objetos de otra clase.
Generalizaciones.
La relación de generalización
denota una relación de herencia entre clases. Se representa dibujando un
triángulo sin rellenar en el lado de la superclase (Ver Figura 2.27). La
subclase hereda todos los atributos y mensajes descritos en la superclase.
Figura 2.27. Representación
de una relación de generalización en un diagrama de clases.
Clases Abstractas.
Las
clases abstractas no instanciables directamente; no
dan lugar a objetos, sino que sirven de especificación más general para
manipular los objetos instancias de una o varias de sus subclases.
Las
clases abstractas forman una base para los programas extensibles. El conjunto
de mecanismos generales se describe en los términos de especificaciones de las
clases abstractas sin tener en cuenta especificidades reunidas en las clases
concretas. Las nuevas necesidades, las extensiones y las mejoras se concentran
en nuevas subclases, cuyos objetos pueden ser manipulados de manera
transparente por los mecanismos ya implementados. Las clases abstractas se representan
en el diagrama, como las demás clases, pero con el nombre escrito en letras
itálicas (Ver Figura 2.28).
Figura 2.28. Representación
de una clase abstracta en un diagrama de clases.
Los diagramas de objetos
muestran objetos y enlaces. Como los diagramas de clases, los diagramas de
objetos muestran la estructura estática. La notación seguida en los diagramas
de objetos es derivada de la de los diagramas de clase; los elementos que son
instancias van subrayados.
Objetos.
Los objetos se representan
por un rectángulo que contiene bien el nombre del objeto, bien la clase y el
nombre (separados por dos puntos), o bien solamente la clase del objeto
(entones el objeto se le llama anónimo) (Ver Figura 2.29).
El nombre de la clase puede
contener el camino completo, compuesto a partir de los nombres de los distintos
paquetes superiores, separados por dos puntos dobles. También se puede colocar
en el segundo compartimiento del rectángulo los valores de los atributos, sin
necesidad de especificar su tipo, ya que ya están especificados en el diagrama
de clases.
Figura 2.29. Representación
de un objeto en un diagrama UML.
Enlaces.
Los objetos se vinculan por
enlaces, que son instancias de las relaciones entre las clases de los objetos
considerados. Los enlaces instancia de asociaciones reflexivas pueden vincular
a un objeto a sí mismo. En este caso, el enlace se representa por un bucle
vinculado a un solo objeto.
2.9.6 Diagrama de Colaboración.
Los
diagramas de colaboración muestran interacciones entre objetos, insistiendo más
particularmente en la estructura espacial estática que permite la colaboración
de un grupo de objetos. Los diagramas de colaboración expresan a la vez el
contexto de un grupo de objetos, a través de enlaces, y la interacción entre
estos objetos, a través de mensajes. Los diagramas de colaboración son una
extensión de los diagramas de objetos.
Interacciones.
El contexto de una
interacción comprende los argumentos, las variables locales creadas durante la
ejecución, así como los enlaces entre los objetos que participan en la
interacción.
Una interacción se realiza
por un grupo de objetos que colaboran intercambiando mensajes. Los mensajes se
representan a los largo de los enlaces entre los objetos por medio de flechas
orientadas hacia el destinatario del mensaje.
En un diagrama de
colaboración, el tiempo no se representa implícitamente, de modo que los
diferentes mensajes se numeran para indicar el orden de los envíos.
Adicionalmente, la notación
permite representar de manera condensada una familia de enlaces, instancias de
una misma asociación. Esta aproximación es particularmente interesante cuando
el grupo de objetos considerado se trata de manera uniforme siendo, por
ejemplo, destino de un mismo mensaje.
La notación permite incluir a
un actor en el diagrama de colaboración para representar el desencadenamiento
de las interacciones por un elemento externo al sistema (Ver Figura 2.30).
Figura 2.30. Ejemplo de un
diagrama de colaboración UML.
Los mensajes enviados pueden
tener representados en sí su nombre, parámetro(s), resultado, sincronización o
también su secuencia (iteraciones).
Los diagramas de secuencia
muestran interacciones entre objetos según un punto de vista temporal. El
contexto de los objetos no se presenta de manera explícita como en los
diagramas de colaboración. La representación se concentra sobre la expresión de
las interacciones.
Interacciones.
Igual que en otros diagramas
los objetos se representan con un rectángulo pero también tiene una barra
vertical que indica la línea de vida del objeto. Los objetos se comunican
intercambiando mensajes representados por medio de flechas horizontales,
orientadas al emisor del mensaje hacia el destinatario. El orden de envío de
los mensajes viene dado por la posición sobre el eje vertical. El eje vertical
puede ser graduado para expresar con precisión las restricciones temporales en
el caso.
Los mensaje pueden ser síncronos o asíncronos. Los síncronos
se representan con una flecha y los asíncronos por una media flecha. Los
mensajes también pueden ser reflexivos, es decir, un objeto se puede enviar un
mensaje a sí mismo (Ver Figura 2.31).
Los diagramas de secuencia
pueden completarse con indicaciones textuales, expresadas en forma de texto
libre o pseudocódigo. Así se puede indicar el momento
en el que se transmite el mensaje (transición), y también la representación de
bucles y bifurcaciones.
Figura 2.31. Ejemplo de un
diagrama de secuencias UML.
Los diagramas de estados
visualizan autómatas de estados finitos, desde el punto de vista de los estados
y las transiciones.
Autómatas.
El comportamiento de los
objetos de una clase, puede ser descrito formalmente en términos de estados y
eventos, mediante un autómata vinculado a esa clase.
Los objetos que no
representan un comportamiento reactivo muy marcado pueden considerarse como
objetos que siempre están en mismo estado, en este caso no poseen ningún
autómata.
Un autómata es la abstracción
de los comportamientos posibles, a imagen de los diagramas de clases que son
abstracciones de la estructura estática. Cada objeto sigue globalmente el
comportamiento descrito en el autómata asociado a su clave y se encuentra en un
momento dado en un estado que caracteriza sus condiciones dinámicas.
Estados.
Cada objeto está en un
momento dado, en un estado particular. Los estados se representan mediante
rectángulos redondeados; cada estado posee un nombre que lo identifica. Los
estados iniciales y finales tienen una representación distinta, el primero se
representa con un punto negro grande, y el segundo también es un punto negro
grande con un círculo alrededor (Ver Figura 2.32).
Transiciones.
Los diagramas de estados, son
grafos dirigidos, lo que permite que los estados estén vinculados por
conexiones unidireccionales, llamadas transiciones. Éstas se representan con
una flecha, y pueden ser reflexivas. Las transiciones pueden ir acompañadas de
una acción a ejecutar instantáneamente en momento en que la transición sea
desencadenada (Ver Figura 2.32).
Eventos.
Los eventos corresponden a la
ocurrencia de una situación especificada en el ámbito del problema.
Generalmente un evento desencadena una transición y por tanto está asociado a
ella. Los eventos también pueden tener parámetros como si fueran operaciones y
son representados colocando su nombre adyacente a la transición que
desencadenan (Ver Figura 2.32).
Guardas.
Los guardas son condiciones
que validan el desencadenamiento de una transición en la ocurrencia de un
evento. Se representan al lado del nombre del evento con la condición dentro de
corchetes (Ver Figura 2.32).
Figura 2.32. Ejemplo de un
diagrama de estados UML.
2.9.9 Diagrama de Actividades.
Los diagramas de actividades
son una variante de los diagramas de estados, organizados respecto a las
acciones y principalmente destinados a representar el comportamiento interno de
un método o de un caso de uso.
Actividades.
Un diagrama de actividades
representa el estado de la ejecución de un mecanismo bajo la forma de un
desarrollo de etapas agrupadas secuencialmente en
ramas paralelas de flujo de control.
Como en el diagrama de
estados también existen las transiciones entre actividades, que pueden regirse
por condiciones, que pueden o no representarse mediante un rombo. Las transiciones
también pueden tener argumentos, guardas y acciones (Ver Figura 2.33).
Los diagramas de actividades
pueden representar sincronizaciones entre flujos de control por medio de barras
de sincronización. Éstas permiten abrir y cerrar ramas paralelas dentro de un
flujo de ejecución de un método o de un caso de uso.
Los diagramas de actividades
también pueden contener estados y eventos representados de la misma manera que
en el diagrama de estados.
Figura 2.33. Ejemplo de un
diagrama de actividades UML.
2.9.10 Diagrama de Componentes
Los diagramas de componentes
describen los elementos físicos y sus relaciones en el entorno de realización.
Los diagramas de componentes muestran las opciones realización.
Módulos.
Los módulos representan todos
los tipos de elementos físicos que entran en la fabricación de aplicaciones
informáticas.
En principio cada clase del
modelo lógico se realiza con dos componentes: la especificación y el cuerpo. La
especificación contiene a interfaz de la clase mientras que el cuerpo contiene
la realización de la clase. La especificación puede ser genérica para clases
parametrizables (Ver Figura 2.34).
Figura 2.34. Representación
de un módulo en diagrama de componentes.
Los componentes pueden estar enlazados a través de
relaciones de dependencia. Ésta se representa por una flecha punteada que
apunta desde el usuario hacia el proveedor (Ver Figura 2.35).
Figura 2.35. Representación
de una relación de dependencia entre componentes en diagrama UML.
Procesos
y Tareas.
Las tareas corresponden a
componentes que poseen su propio flujo. Éstas pueden estar contenidas en otros
componentes (Ver Figura 2.36).
Figura 2.36. Representación
de una tarea en un diagrama de componentes.
Programas
Principales.
Los programas principales son
los punto de entrada a las aplicaciones, generalmente son el programa
ejecutable correspondiente a la aplicación (Ver Figura 2.37).
Figura 2.37. Representación
de un programa principal en un diagrama de componentes.
Subprogramas.
Los subprogramas agrupan
procedimientos y funciones no pertenecientes a ninguna clase (Ver Figura 2.38).
Figura 2.38. Representación
de un subprograma en un diagrama de componentes
Subsistemas.
Los diferentes componentes de
las aplicaciones pueden agruparse en paquetes según un criterio lógico. Los
subsistemas organizan la vista de realización de un sistema; cada subsistema
puede contener componentes y otros subsistemas (Ver Figura 2.39).
Figura 2.39. Ejemplo de un
subsistema en un diagrama de componentes.
2.9.11 Diagrama de Despliegue.
Los diagramas de despliegue
muestran la disposición física de los distintos materiales (nodos) que entran
en la composición del sistema y el reparto de los programas ejecutables sobre
estos materiales.
Nodos.
Los nodos son recursos
materiales que se presentan como cubos, evocando la presencia física del equipo
en el sistema. La naturaleza del equipo puede precisarse mediante el
estereotipo. Los nodos pueden ser clases ú objetos, en tal caso se utilizarán
las notaciones acostumbradas para distinguirlos.
Los nodos pueden estar
enlazados, a través de líneas que pueden tener relaciones de multiplicidad (Ver
Figura 2.40).
Figura 2.40. Ejemplo de un
diagrama de despliegue UML.
2.9.12 Extensiones UML para aplicaciones Web.
Aunque es claro que UML no
encaja perfectamente con todos los tipos de desarrollo de aplicaciones, su
extensibilidad permite adaptarlo a nuevas necesidades, como es el caso de las
aplicaciones Web. Las extensiones UML para Web son un conjunto de estereotipos,
valores etiquetados y restricciones que permiten el modelado de aplicaciones
Web. Estos elementos pueden ser aplicados a ciertos componentes que pueden ser
particulares de las aplicaciones Web y que pueden ser representados en los
mismos modelos y diagramas que el resto del sistema.
Página de Servidor.
Las páginas de servidor
representan una página Web con scripts que son
ejecutados en el servidor. En este caso las operaciones del objeto representan
las funciones de scripts y los atributos las
variables utilizadas dentro de la página. Las páginas de servidor solo pueden
tener relación con objetos en el servidor y posee un valor etiquetado llamado “Script Engine” que indica el
lenguaje en el que serán realizados los scripts (Ver
Figura 2.40).
Figura 2.40. Representación
de una página de servidor en un diagrama de clases.
Página de Cliente.
Una instancia de una página
cliente es una página HTML formateada. Estas pueden tener scripts
que corran en el cliente, por tanto los atributos y métodos de éstos scripts se pueden mostrar dentro de la página cliente. Las
páginas de cliente generalmente están asociadas a otras páginas, tanto de
cliente como de servidor (Ver Figura 2.41).
Figura 2.41. Representación
de una página de cliente en un diagrama de clases.
Enlace (Link).
Es un tipo de asociación en
el que una página de cliente está enlazada mediante un hipervínculo con otra
página (cliente o servidor). El enlace puede contener parámetros (Ver Figura
2.43).
Formulario (Form).
Los formularios están
directamente relacionados con los formularios de las páginas, éstos pueden
contener campos de entradas que pueden ser representados como sus atributos
(Ver Figura 2.42).
Figura 2.42. Representación
de un formulario HTML en un diagrama de clases.
Envío (Submit).
Es una asociación que se
cumple entre un formulario y una página de servidor, donde el formulario le
envía al servidor la información suministrada por el usuario en el mismo (Ver
Figura 2.43).
Construcción (Build).
Muchas veces las páginas
clientes son construidas a partir de una página servidor, en este caso existe
una asociación de construcción entre ellas. Una página de servidor puede
construir muchas páginas clientes, pero una página cliente solo puede ser
construida por una página de servidor (Ver Figura 2.43).
Inclusión (Include).
Las
relaciones de inclusión indican que una página está incluyendo para dentro de
sí todas las funcionalidades de otra página. Esto generalmente se hace con la
finalidad de reutilizar el código ya escrito en la página fuente (Ver Figura
2.43).
Redirección (Redirect).
Es
una asociación unidireccional de una página con otra, desde una página cliente
o desde una página de servidor. En caso de ser una página de servidor indica
que el procesamiento actual debe continuar en otra página. Por el contrario, en
las páginas clientes, se hace referencia a otra página para que el navegador
sea enviado a ésta, sin requerimiento del usuario (Ver Figura 2.43).
Figura 2.43. Ejemplo de un
diagrama de clases utilizando extensiones Web para UML.
4. Herramientas de Software que apoyan
el modelado UML. Ejemplos y demos.
Programas más populares para el modelado en UML
·
Software Libre
Estos
programas
están bajo licencias libres, siendo posible su libre uso, estudio y
modificación.
- ArgoUML:
es una aplicación de diagramado de UML escrita en Java y publicada bajo la
Licencia BSD open source.
Dado que es una aplicación Java, está disponible en cualquier plataforma
soportada por Java.
- BOUML: Ligera herramienta de modelado UML y
generación de código C++, Java e IDL. Disponible para Windows, Unix/Linux y Mac OS X.
- Fujaba: No solo sirve para modelar sino que puede
generar código Java automáticamente. También es capaz de hacer ingeniería
inversa y crear los diagramas a partir del código Java.
- Dia: Puede
ser usado para modelar varios tipos de diagramas UML.
- gModeler: Herramienta para modelado de UML basada en
Flash (utilizable desde el navegador), que permite generar código Action Script 2.0
Compatible.
- MonoUML: Herramienta CASE para la plataforma mono.
- Papyrus: Herramienta gráfica basada en Eclipse para el modelado con UML2, es de
código abierto y se ofrece bajo licencia EPL.
- StarUML: Herramienta de modelado para Windows
desarrollada en Delphi. Bastante estable y
utilizable.
- TCM (Toolkit for Conceptual Modeling):
herramienta para crear diversos tipos de diagramas incluidos UML.
- Umbrello:
Herramienta para modelado UML para el entorno KDE.
- UMLet: Herramienta para modelado rápido de UML
también escrita en Java.
- Netbeans: módulo UML.
·
Freeware para modelado en UML
Aunque gratuitos,
estos programas se encuentran bajo licencias que no permiten el estudio y
modificación de los mismos.
- JUDE Community:
Herramienta de modelado UML.
- Omondo plugin para Eclipse: Herramienta de
modelado UML para Java.
- Oracle JDeveloper Un IDE para Java con soporte de diagramas
UML.
- Visual
Paradigm for UML: Herramienta de modelado UML y herramienta CASE
que cuenta con una versión gratuita denominada Community
Edition.
·
Otro software
Software comercial de modelado UML:
- Enterprise Architect
de Sparx Systems: es la herramienta más potente y
flexible para la plataforma de Windows. Una herramienta de análisis de
negocio y UML orientada a objetos para el desarrollo completo del
ciclo de vida, Enterprise Architect
provee el límite competitivo para el desarrollo de software,
administración de proyecto, administración de requerimientos y análisis de
negocio -a un precio muy conveniente.
- Borland Together
creado para generar negocios de
importación y proceso de ejecución de las lenguas con las definiciones de
Servicios Web (BPEL4WS)
Aumentar la productividad y la calidad mediante la automatización de diseño y el código de evaluación que incluyen auditorías y métricas en el modelo y el código de nivel. - Microsoft
Visio facilita a los
profesionales empresariales y de TI la visualización, el análisis y la
comunicación de información compleja. Pase de texto y tablas complicadas y
difíciles de comprender a diagramas de Visio que comunican información de
un vistazo. En lugar de imágenes estáticas, crea diagramas de Visio
conectados a datos que muestran información, son fáciles de actualizar y
pueden aumentar espectacularmente la productividad.
- MagicDraw UML Esta versión de la 4 ª generación de negocios y
requisitos de software agrega herramienta de gestión de la extrema
flexibilidad para los usuarios empresariales para definir las necesidades
de su negocio que satisfagan sus procesos y objetivos de negocio.
Ejemplos y demos
Software Libre
- Dia
- Fujaba
- StarUML
Umbrello
Freeware para
modelado en UML
- Visual Paradigm for UML
Otro Sotfware
MagicDraw UML
5. Caso Práctico. Aplicar el Diagrama
de Casos de Uso a una Problemática presentada en su empresa
5.1. Problemática
Presentada en la Empresa
En relación con el origen del problema que se presenta se puede hacer
referencia a que, a escala mundial los procedimientos administrativos y
tecnológicos vienen a transformarse en rutinas que al paso del tiempo se van
modificando con el desempeño mismo de las tareas cotidianas, el creciente grado
de especialización, como consecuencia de la división del trabajo, hace
necesario el uso de una herramienta que establezca los lineamientos en el
desarrollo de cada actividad dentro de una estructura organizacional, así pues
los sistemas de información representan una alternativa para este problema.
En la empresa para la cual
laboramos: PDVSA PETRORITUPANO S.A. del estado Anzoátegui, actualmente tiene
problema en el manejo de inventario del Almacén Principal, ya que para dar de
alta o de baja a los suministros y equipos, se hace de forma manual, mediante
una hoja de cálculo en excel; este método es inseguro
y muy lento, es decir, cada suministro o equipo tiene que ser tecleado y cada
cambio a las existencias tiene que ser capturada nuevamente. La confiabilidad
del Inventario de la empresa: PDVSA PETRORITUPANO S.A. del estado Anzoátegui,
depende del cuidado con que se realicen estas tareas tan importantes como lo es
dar de alta y baja a los suministros y equipos, en una hoja de cálculo de excel.
La estrategia a seguir se basará en el desarrolló de
un estudio encaminado al “Desarrollo de un Sistema para la Administración y
Control de Suministros y Equipos del Almacén Principal de la Empresa PDVSA
Petroritupano S.A. del estado Anzoátegui”. El modelo pretende establecer las
políticas óptimas del inventario, considerando el carácter aleatorio de la
demanda y los tiempos de entrega. La solución propuesta tiene como finalidad
disminuir la tasa de faltantes y el alto nivel de inventario que afecta a la
empresa. Como producto final de la investigación, se desarrollará el sistema
antes mencionado que utiliza el modelo propuesto para estimar en forma óptima
cuánto y cuándo pedir; además de las cantidades mínimas adecuadas y los niveles
de reserva. El sistema automatizado realizará también una clasificación de los
suministros y equipos, clientes y proveedores en pro de prestar mayor control y
eficiencia en la administración de las existencias.
Así mismo, para el departamento de
almacén es indispensable, ya que le permitirá contar con una herramienta para
obtener información rápida y oportuna ya que con el mismo se lleva la
administración y el control de los suministros y equipos.
5.2. Aplicación del Diagrama de Casos de Uso
5.2.1.
Identificación de Actores
Los actores tienen las siguientes características:
· Son externos al sistema.
· Interactúan con el sistema. Los actores pueden
utilizar funcionalidades provistas por el sistema, pero también pueden proveer
funcionalidad al sistema. Los actores pueden obtener o ingresar información al
sistema.
5.2.1.1. Actores principales e identificados del
sistema
- Usuario: Persona encargada de dirigir las
actividades del Almacén, el usuario necesita del sistema para controlar y
administrar las actividades de dicho almacén.
- Manejador de Base de Datos (BDdatos):
Se considera un actor debido a que interactúa directamente con el sistema.
Toda la información que el sistema manipula está contenida en esta base de
datos (BDdatos) distribuidas en tablas diseñadas
exclusivamente para su uso.
- Manejador de Ayuda: Sistema que permite
codificar la ayuda del sistema.
5.2.2.
Identificación de Casos de Uso
Luego de haber identificado los actores principales,
se procede a identificar los casos de uso que servirán como medio de
interacción entre estos y el Sistema. En la Figura 1., se muestran los casos de
uso necesarios que satisfacen los requerimientos del Sistema.
Figura 1.
Diagrama de Casos de Uso del SISTEMA
El caso de
uso Accesar al Sistema se estableció debido a que se necesitaba
controlar el acceso al sistema. Luego se creó el caso de uso Controlar
Suministros para llevar a cabo el control general, referente al manejo de los
suministros y equipos.
Para manejar
o agrupar los datos de los proveedores a los cuales se les realizan los pedidos de suministros y
equipos para el Almacén Principal, se estableció el caso de uso Manipular
Información de Proveedores. Por otra parte se necesitaba respaldar la
información generada mediante el sistema y es por eso que se implanto el caso
de uso Respaldar Información. Y por todas las necesidades planteadas por los
encargados del control de las actividades del Almacén se crearon los otros
casos de uso: Aplicar Opciones Avanzadas para permitir manipular opciones
avanzadas disponibles sólo para usuarios autorizados. Generar Reportes para
generar los reportes requeridos por el usuario, pueden ser generados por
pantalla o impresora. Utilizar ayuda facilita un conjunto de ayudas del
sistema.
5.2.2.1. Casos de Uso detallados
Los diagramas de casos de uso, dirigen todo el
proceso de desarrollo debido a que la mayoría de las actividades como el
análisis, diseño y prueba se llevan a cabo partiendo de estos diagramas.
Caso de Uso: Accesar al
Sistema
Actores: Usuario, Manejador de Base de Datos (BDdatos)
Descripción: Permite al usuario tener acceso al
Sistema, mediante la verificación de los datos.
Estado Inicial: El sistema está en espera de los
datos del usuario.
Flujo de Sucesos:
- El usuario ingresa sus datos al sistema.
- El usuario confirma o cancela.
- El sistema verifica los datos si el usuario
confirma.
- El sistema se cierra si el usuario cancela.
- El sistema muestra un mensaje de “acceso negado”
si el usuario coloca los datos incorrectos.
- El sistema permite tres intentos de datos
incorrectos.
- Si los datos son correctos el sistema permite el
acceso al usuario.
- Finaliza el caso de uso.
Caso de Uso: Controlar Suministros
Actores: Usuario, Manejador de Base de Datos (BDdatos)
Descripción: Este caso de uso es fundamental para el
Sistema, ya que permite el control general referente al manejo de los
suministros y equipos.
Estado Inicial: Una vez iniciado el Sistema es
posible que se ejecute la opción de controlar suministros.
Flujo de Sucesos:
- El usuario solicita controlar suministros.
- El sistema muestra las opciones de controlar
suministros.
- El usuario selecciona la opción de su
preferencia.
- El sistema presenta al usuario una pantalla
perteneciente a la opción elegida.
- El usuario realiza su objetivo.
- Cuando el usuario lo decida finaliza el caso de
uso.
Caso de Uso: Manipular Información de Proveedores
Actores: Usuario, Manejador de Base de Datos (BDdatos)
Descripción: Maneja o agrupa los datos de los
proveedores a los cuales se les realizan los pedidos de suministros y equipos
para el almacén.
Estado Inicial: Se encuentra en espera de ser
ejecutado por el usuario.
Flujo de Sucesos:
- El usuario solicita registro de proveedores.
- El sistema muestra una lista con los datos de
los proveedores.
- El usuario desea eliminar un proveedor.
- El sistema borra ese proveedor.
- El usuario desea modificar los datos de un
proveedor.
- El sistema modifica los datos de ese proveedor.
- El usuario desea agregar un proveedor.
- El sistema agrega el proveedor.
- Cuando el usuario lo decida finaliza el caso de
uso.
Caso de Uso: Respaldar Información
Actores: Usuario, Manejador de Base de Datos (BDdatos)
Descripción: Este caso de uso permite respaldar la
información generada por el Sistema.
Estado Inicial: Una vez iniciados el Sistema es
posible respaldar la información.
Flujo de Sucesos:
- El usuario solicita respaldar información.
- El sistema emite un mensaje al usuario, para que
éste prepare la unidad a la que desea copiar la información.
- El usuario confirma la opción de respaldar
información.
- El sistema guarda la información.
- Cuando el usuario lo decida finaliza el caso de
uso.
Caso de Uso: Aplicar Opciones Avanzadas
Actores: Usuario, Manejador de Base de Datos (BDdatos)
Descripción: Permite un conjunto de opciones
avanzadas disponibles sólo para usuarios autorizados.
Estado Inicial: El usuario autorizado desea tener
acceso a las opciones avanzadas.
Flujo de Sucesos:
- El usuario autorizado desea acceder a las
opciones avanzadas.
- El sistema muestra las opciones al usuario.
- El usuario elige una opción.
- El sistema muestra una pantalla relacionada a la
opción elegida por el usuario.
- Este caso de uso finaliza cuando el usuario lo
decida.
Caso de Uso: Generar Reportes
Actores: Usuario, Manejador de Base de Datos (BDdatos)
Descripción: Este caso de uso facilita generar el
reporte requerido por el usuario.
Estado Inicial: Luego de estar cargados los datos al
Sistema es posible ejecutar la opción de generar reportes.
Flujo de Sucesos:
- El usuario desea generar un reporte.
- El Sistema muestra el reporte solicitado por el
usuario.
- El usuario elige si sólo quiere ver el reporte
por pantalla o imprimirlo.
- El Sistema responde a la decisión del usuario.
- Cuando el usuario así lo desee, finalizará el
caso de uso.
Caso de Uso: Utilizar Ayuda
Actores: Usuario, Manejador de Ayuda
Descripción: Facilita un mecanismo de ayuda al
usuario.
Estado Inicial: El usuario solicita una ayuda
referente al Sistema.
Flujo de Sucesos:
- El usuario solicita ayuda al Sistema.
- El Sistema accede al manejador de ayuda, el cual
muestra al usuario los tópicos que abarca.
- El usuario selecciona el tópico y solicita la
información.
- El manejador de ayuda muestra la información
solicitada,
- El usuario puede solicitar toda la información
que desee, que esté contemplada entre los tópicos del sistema de ayuda.
- Este caso de uso finaliza cuando el usuario lo
decida.
Además, se efectuará la realización del caso de uso Controlar
Suministros. Este se puede considerar como uno de los Casos de uso
fundamentales para el Sistema, debido a que el control de suministros es el
principio básico del Sistema. En la Figura
2. se
muestra el diagrama de realización del caso de usos Controlar Suministros.
Figura 2. Diagrama de realización del caso de usos
Controlar Suministros
El caso de uso Controlar Suministros es creado
para llevar a cabo el control general, referente al manejo de los suministros y
equipos.
Ingresar Suministros muestra al usuario la información necesaria para el
ingreso de suministros o equipos al almacén, ésta información dependerá de, si
se activa el caso de uso Ingresar Suministros Nuevos, éste permite
ingresar información referente a suministros o equipos que no existen en el
almacén, es decir, son ingresados por primera vez, ahora bien, si se activa Ingresar
Suministros Existentes, éste caso de uso permite el ingreso de información
relacionada a suministros o equipos que existen en el almacén.
Los casos de uso Ingresar Suministros Nuevos y
Ingresar Suministros Existentes están relacionados con el caso de uso Ingresar
Suministros mediante el estereotipo <<extend>>.
El caso de uso Retirar Suministros facilita la
información relacionada al control de entrega
de suministros o equipos al personal solicitante.
Verificar Existencia permite verificar la existencia de un suministro o
equipo en inventario, esta ubicación se puede hacer mediante el Código o el
Número de Parte.
Ubicar Suministros maneja la información de ubicación de los suministros o equipos para
saber el sitio exacto en donde se encuentran dentro del almacén.
Ingresar Suministros, Retirar Suministros, Verificar
Existencia y Ubicar Suministros,
estos casos de uso son accedidos desde el sub-sistema
de controlar suministros como una opción adicional, ya que se relacionan con el
caso de uso Controlar Suministros mediante
el estereotipo <<include>>.
5.2.2.2.
Casos de Uso detallados
La
descripción de los nuevos casos de uso identificados son los siguientes:
Caso de Uso: Controlar Suministros
Actores:
Usuario Aprobado, Manejador de Base
de Datos (BDdatos)
Descripción: Este caso de uso es fundamental para el Sistema, ya
que permite el control general referente al manejo de los suministros y
equipos.
Estado
Inicial: Una vez iniciado el sistema
es posible que se ejecute la opción de controlar suministros.
Flujo
de Sucesos:
7.
El usuario
solicita controlar suministros.
8.
El sistema
muestra las opciones de controlar suministros.
9.
El usuario
selecciona la opción de su preferencia.
10.
El sistema
presenta al usuario una pantalla perteneciente a la opción elegida.
11.
El usuario
realiza su objetivo.
12.
Cuando el
usuario lo decida finaliza el caso de uso.
Caso de Uso: Ingresar Suministros
Actores:
Usuario Aprobado, Manejador de Base
de Datos (BDdatos)
Descripción: Muestra al usuario la información necesaria para el
ingreso de suministros o equipos al almacén.
Estado
Inicial: Luego de ser seleccionada
la opción controlar suministros es posible que se ejecute la opción de ingresar
suministros.
Flujo
de Sucesos:
a.
El usuario
solicita ingresar suministros.
b.
Las opciones de
ingresar suministros nuevos e ingresar suministros existentes son mostradas por
el sistema.
c.
El usuario elige
una opción.
d.
Una pantalla
perteneciente a la opción elegida es presentada por el sistema.
e.
El usuario
realiza su objetivo.
f.
Este caso de uso
finaliza cuando el usuario así lo desee.
Caso de Uso: Ingresar Suministros Nuevos
Actores:
Usuario Aprobado, Manejador de Base
de Datos (BDdatos)
Descripción: Éste permite ingresar información referente a
suministros o equipos que no existen en el almacén, es decir, son ingresados
por primera vez.
Estado
Inicial: Una vez elegida la opción
ingresar suministros es posible que sea seleccionada la opción de ingresar
suministros nuevos.
Flujo
de Sucesos:
1.
El usuario
solicita ingresar suministros nuevos.
2.
El sistema
muestra una pantalla perteneciente a la opción elegida.
3.
El usuario
realiza el objetivo deseado.
4.
El caso de
uso finaliza cuando el usuario así lo desee.
Caso de Uso: Ingresar Suministros Existentes
Actores:
Usuario Aprobado, Manejador de Base
de Datos (BDdatos)
Descripción: Permite el ingreso de información relacionada a
suministros o equipos que existen en el almacén.
Estado
Inicial: Ingresar suministros
existentes es posible que sea seleccionada luego de ser elegido la opción de
ingresar suministros.
Flujo
de Sucesos:
1.
El usuario
solicita ingresar suministros existentes.
2.
El sistema
muestra una pantalla perteneciente a la opción elegida.
3.
El usuario
realiza el objetivo deseado.
4.
Éste caso de
uso finaliza cuando el usuario lo decida.
Caso de Uso: Retirar Suministros
Actores:
Usuario Aprobado, Manejador de Base
de Datos (BDdatos)
Descripción: Facilita la información relacionada al control de
entrega de suministros o equipos al
personal solicitante.
Estado
Inicial: Luego de ser seleccionada
la opción controlar suministros es posible que se ejecute la opción de retirar
suministros.
Flujo
de Sucesos:
1.
El usuario
elige retirar suministros.
2.
Una pantalla
perteneciente a la opción elegida es presentada por el sistema.
3.
El usuario
realiza lo deseado.
4.
Cuando el
usuario quiera, finaliza este caso de uso.
Caso de Uso: Verificar Existencia
Actores:
Usuario Aprobado, Manejador de Base
de Datos (BDdatos)
Descripción: Éste caso de uso permite verificar la existencia de
un suministro o equipo en inventario.
Estado
Inicial: La opción de verificar
existencia puede ser seleccionada luego de ser elegida la opción de controlar
suministros.
Flujo
de Sucesos:
1.
El usuario
selecciona la opción de verificar existencia.
2.
El sistema
muestra una pantalla perteneciente, en donde le permite dos opciones por las
cuales el usuario pueda decidirse.
3.
El usuario
elige una opción.
4.
El sistema
presenta una pantalla dependiendo de la opción elegida.
5.
El usuario
realiza el objetivo deseado.
6.
Éste caso de
uso finaliza cuando el usuario lo desee.
Caso de Uso: Ubicar Suministros
Actores:
Usuario Aprobado, Manejador de Base
de Datos (BDdatos)
Descripción: Maneja la información de ubicación de los
suministros o equipos para saber el sitio exacto en donde se encuentran dentro
del almacén.
Estado
Inicial: Una vez elegida la opción
controlar suministros es posible que sea seleccionada la opción de ubicar
suministros.
Flujo
de Sucesos:
1.
El usuario
solicita ubicar suministros.
2.
El sistema
presenta al usuario una pantalla perteneciente a la opción elegida.
3.
El usuario
realiza su objetivo.
4.
Cuando el
usuario lo decida finaliza el caso de uso.
Bibliografía
http://es.wikipedia.org/wiki/UML
(S/A) CONSULTADO 24-09-08
http://www.objectsbydesign.com/tools/umltools_byCompany.html