Sei sulla pagina 1di 9

1.

4 DIAGRAMAS
1.4.1 ACTIVIDAD
El diagrama de Actividad es un diagrama de flujo del proceso multi-propsito que
se usan para modelar el comportamiento del sistema. Los diagramas de actividad
se pueden usar para modelar un Caso de Uso, o una clase, o un mtodo
complicado.
En UML un diagrama de actividad se usa para mostrar la secuencia de
actividades. Los diagramas de actividad muestran el flujo de trabajo desde un
punto de inicio hasta el punto final detallando muchas de las rutas de decisiones
que existen en el progreso de eventos contenidos en la actividad. Estos tambin
pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir
en la ejecucin de algunas actividades.

Las siguientes secciones describen los elementos que constituyen un diagrama de


actividades:
Actividades

Una actividad es la especificacin de una secuencia


parametrizada de comportamientos. Una actividad
muestra un rectngulo con las puntas redondeadas
adjuntando todas las acciones, flujos de control y
otros elementos que constituyen la actividad.
Acciones
Una accin representa un solo paso dentro de una
actividad. Las acciones se denotan por rectngulos con
las puntas redondeadas.

Restriccin de Accin
Las restricciones se pueden adjuntar a una accin.

Flujo de control
Un flujo de control muestra el flujo de control de una accin a otra. Su notacin es
una lnea con una punta de flecha.

Nodo inicial
Un nodo inicial o de comienzo se describe por un gran punto
negro.

Nodo Final

Hay dos tipos de nodos finales: nodos finales de actividad


y de flujo. El nodo final de actividad se describe como un
crculo con punto dentro del mismo.
El nodo final se flujo se describe
como un circulo con una cruz dentro
del mismo.

La diferencia entre los dos tipos de nodos es que el nodo final del flujo denota el
final de un solo flujo de control, y el nodo final de actividad denota el final de todos
los flujos finales dentro de la actividad.
Flujo de objetos y Objeto
Un flujo de objeto en la ruta a lo largo de la cual pueden
pasar objetos o datos. Un objeto se muestra cmo un
rectngulo. Un flujo de objeto se muestra como un conector
con una punta de flecha denotando la direccin a la cual se est pasando el
objeto.
Un almacn de clave se muestra como un objeto con las
claves <<datastore>>

Nodos de Decisin y Combinacin

Los nodos de decisin y combinacin tiene la


misma notacin: una forma de diamante. Los
dos de pueden nombrar. Los flujos de control
que provienen de un nodo de decisin tendrn
condiciones de guarda que permitirn el control
para fluir si la condicin de guara se realiza. El siguiente diagrama muestra el uso
de un nodo de decisin y un nodo de combinacin.
Nodos de Bifurcacin y Unin
Las bifurcaciones y uniones tienen la misma notacin: tanto una barra horizontal
como vertical (la orientacin depende de si el flujo de control va de derecha a
izquierda o hacia abajo y arriba. Estos indican el comienzo y final de hilos actuales
de control.
Una unin es diferente de una combinacin ya
que la unin sincroniza dos flujos de entrada y
produce un solo flujo de salida. El flujo de salida
desde una unin no se puede ejecutar hasta que
todos los flujos se hayan recibido. Una combinacin pasa cualquier flujo de control
directamente a travs de esta. Si dos o ms flujos se hayan recibido. Una
combinacin pasa cualquier flujo de control directamente a travs de esta. Si dos o
ms flujos de entrada se reciben por un smbolo de combinacin, la accin a la
que el flujo de salida apunta se ejecuta dos o ms veces.
Regin de Expansin
Una regin de expansin es una regin de actividad
estructurada que se ejecuta muchas veces. Los
nodos de expansin de salida y entrada se dibujan
como un grupo de tres casillas representando una
seleccin mltiple de tems. La clave reiterativa,
paralelo, o flujo se muestra en la esquina izquierda arriba de la regin.
Gestores de Excepcin

Los gestores de excepcin se pueden modelar en


diagrama de actividad como en siguiente ejemplo.
Regin de Actividad Interrumpible
Una regin de actividad interrumpida rodea un grupo de
acciones que se pueden interrumpir.
Particin
Una particin de una actividad e muestra como calles
horizontales o verticales.
1.4.2 MODELADO A DISTINTOS NIVELES
Los modelos a distintos niveles, conocidos tambin
como lineales jerrquicos, modelos anidados, modelos
mixtos, entre otros nombres) son modelos estadsticos de parmetro que varan
en ms de un nivel. Estos modelos pueden ser vistos como generalizaciones de
modelos lineales, aunque tambin pueden extender los modelos no lineales.,
aunque tambin pueden extender los modelos no lineales. Aunque
Distintos niveles
Alto nivel en etapas tempranas
-

Destinado a Stakeholders no tcnicos


Exploracin Conceptual del Problema
Refinamiento va modelos medios detallados

Modelos de niveles medios


-

Especificacin de Capacidades escenciales del sistema


Historicamente: ERs, DFDs, , FSMs, etc.
Recientemente: Escenarios, Patrones de Diseo, etc.

1.4.3 DIAGRAMAS DE CASO DE USO


Los diagramas de caso de uso documentan el comportamiento de un sistema
desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los

requisitos funcionales del sistema, es decir, representan las funciones que un


sistema puede ejecutar.
Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean
especialmente tiles en la comunicacin con el cliente.

Elementos bsicos
Actores: Los actores representan un tipo de usuario del sistema. Se entiende
como usuario cualquier cosa externa que interacta con el sistema. No
tiene por qu ser un ser humano, puede ser otro sistema informtico o
unidades organizativas o empresas.
Siempre hay que intentar independizar los actores de la forma en que se
interacta con el sistema. Un actor en un diagrama de caso de uso representa un
rol que alguien puede estar jugando, no un individuo particular por lo tanto puede
haber personas particulares que pueda estar usando el sistema de formas
diferentes en diferentes ocasiones.
Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del
sistema que se est desarrollando. Se representa mediante un
ovulo. Cada caso de uso debe detallarse habitualmente mediante
una descripcin textual.

Asociaciones: hay una asociacin entre un actor y un caso de uso si el actor


interactua con el sistema para llevar a cabo el caso de uso. Un caso de uso debe
especificar un comportamiento deseado, pero no imponer como se llevara a cabo

ese comportamiento, es decir, debe decir QU pero no CMO. Esto se realiza


utilizando escenarios.

Escenario: es una interaccin entre el sistema y los actores, que


pueden ser descritos mediante una secuencia de mensajes. Un caso de uso es
una generalizacin de un escenario.

Tipo de acciones.
Existen tres tipos de asociacin o relaciones en los diagramas de casos de uso:
Include: Se puede incluir una relacin entre dos casos de uso de tipo include si
se desea especificar comportamiento comn en dos o ms casos de uso.

Las ventajas de esta asociacin son:


-

Las descripciones de los casos de uso son ms cortas y se entienden

mejor.
La identificacin de funcionalidad comn puede ayudar a descubrir el
posible uso de componentes ya existentes en la implementacin.

Las desventajas son:


-

La inclusin de estas relaciones hace que los diagramas sean ms difcil


de leer, sobre todo para los clientes.

Extend: Se puede incluir una relacin entre dos casos de uso de tipo include si
se desea especificar diferentes variantes del mismo caso de uso. Es decir, esta
relacin implica que el comportamiento de un caso de uso es diferente
dependiendo de ciertas circunstancias. En principio esas variaciones pueden

tambin mostrarse como diferentes descripciones de

escenarios asociadas al

mismo caso de uso.

Generalizaciones: En un diagrama de casos de uso tambin pueden mostrarse


generalizaciones (relaciones de herencia) para
mostrar

que

diferentes

elementos

estn

relacionados como tipos de otros. Son aplicables a


actores o casos de uso, pero para estos ltimos la
semntica es muy similar a las relaciones extend.
Limites del sistema: Resulta til dibujar los lmites
del sistema cuando se pretende hacer un diagrama
de casos de uso para parte del sistema.

1.4.4 RELACION CON LOS REQUISITOS

El objetivo principal de esta herramienta es poder mostrar al usuario, desde los


momentos iniciales del diseo, el aspecto que tendr la aplicacin una vez
desarrollada. Ello facilitar la aplicacin de los cambios que se consideren
necesarios, todava en la fase de diseo.
La herramienta ser tanto ms til, cuanto ms rpidamente permita la
construccin del prototipo y por tanto antes, se consiga la implicacin del usuario
final en el diseo de la aplicacin. Asimismo, es importante poder aprovechar
como base el prototipo para la construccin del resto de la aplicacin.
Actualmente,

es

imprescindible

utilizar

productos

que

incorporen

esta

funcionalidad por la cambiante tecnologa y necesidades de los usuarios. Los


prototipos han sido utilizados ampliamente en el desarrollo de sistemas

tradicionales, ya que proporcionan una realimentacin inmediata, que ayudan a


determinar los requisitos del sistema. Las herramientas CASE estn bien dotadas,
en general, para crear prototipos con rapidez y seguridad.
Tiene que existir una relacin con los requisitos en:
-

Dependencia
Asociacin
Generalizacin
Realizacin

Potrebbero piacerti anche