Universidad
Yacambu
Especialización
en Gerencia Mención Redes y Telecomunicaciones
FASE II
MATERIA: ANALISIS Y DISEÑOS DE
AUTORES: Gabriela Pestana. C.I: 14.045.538
Maria Pestana. C.I: 14.045.539
Edward Arevalo. C.I: 15.016.166
TRABAJO Nº 1
Modelado de Sistemas de Información. Unified Model
Language (UML)
Según Orallo, E (S/A).
Recuperado el 20 de septiembre del 2008 de http://www.disca.upv.es/enheror/pdf/ActaUML.PDF,
define : ”UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario
y una reglas para permitir una comunicación. En este caso, este lenguaje se centra
en la representación gráfica de un sistema”.
Para que sirve UML.
Según
Villalta, J. (2008). Recuperado el 20 de Septiembre del 2008 de http://www.vico.org/aRecursosPrivats/TRAD_introUML.pdf (2008), define que UML sirve
para:
· Representar
visualmente las reglas de creación, estructura y comportamiento de un grupo
relacionado de objetos y procesos.
· Visualizar
de manera eficiente la complejidad de un sistema o una organización en un
reducido número de diagramas.
· Mantener
mucho más ágilmente las especificaciones ante los cambios y nuevos enfoques de
arquitectura
Sigue
señalando el autor con relación a la utilidad de UML:
·
Definir
un problema que afecta a una organización (análisis)
·
Plantear
una solución de diseño (abstracción)
·
Modelar
procesos de negocio (optimización de flujos de trabajo)
·
Construir
un producto de software (concreción de una abstracción)
·
Certificar
la coherencia, completitud y usabilidad del producto (calidad)
·
Evaluar
la arquitectura de una organización (conocimiento)
2. Modelos o
Diagramas que contiene.
Según Orallo, E (S/A).
Recuperado el 20 de septiembre del 2008 de http://www.disca.upv.es/enheror/pdf/ActaUML.PDF,
define :
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
está compuesto por los siguientes diagramas, Según Kendall, K (2005):
1. Diagramas
de Caso de uso: Describe como se usa el sistema. Los analistas empiezan con
este diagrama.
2. Escenario
de caso de uso, técnicamente no es un diagrama, es una descripción verbal de
las excepciones para el comportamiento principal descrito por el caso de uso.
3. Diagrama
de Actividades: Ilustra el flujo general de actividades, cada caso de uso
podría crear un diagrama de actividades.
4. Diagramas
de Secuencias: muestran la secuencia de actividades y las relaciones de las
clases. Cada caso e uso podría crear uno ó más diagramas de secuencias, es un
diagrama de colaboración, el cual contiene la misma información en formato
diferente.
5. Diagramas
de Clases: Muestran las clases y las relaciones. Los diagramas de secuencias se
usan para determinar las clases.
6. Diagramas
de gráficos de estados, muestra las transiciones de estado. Cada clase podría
crear un diagrama de grafico para ayudar a determinar las operaciones. (p.664)
Diagramas
de Caso de uso.
·
Proporciona
medios eficaces de comunicación entre el equipo del negocio y el equipo del
desarrollo.
·
Divide
la funcionabilidad del sistema en comportamientos, servicios y respuestas.
·
El
analista debe recordar lo que es importante para el usuario e incluirlo en el
diagrama de caso de uso.
·
Un
caso de uso proporciona una visión de lo que quieren los usuarios, no contiene
detalles técnicos.
·
Un
caso de uso escribe siempre tres cosas; Un actor ( inicia el evento), Evento
(activa un caso de uso), Caso de uso (desempeña las acciones). (Ibídem)
|
Relación |
Símbolo |
Significado |
||
|
Comunica |
|
Un actor se conecta
a un caso de uso usando una línea sin puntas de flecha |
||
|
Incluye |
<<incluir>>
|
Un caso de uso
contiene un comportamiento que es más común que otro caso de uso. La flecha
apunta al caso de uso común. |
||
|
Extiende |
..................<<extender>>
|
Un caso de uso
diferente maneja las excepciones del caso de uso básico. La flecha apunta
desde el caso de uso extendido hacia el básico. |
||
|
Generaliza |
|
Una “cosa” de UML
es mas general que otra “cosa”. La flecha apunta a la “cosa” general. |
Fuente: Kendall & Kendall. (p.667)
Ejemplo:

Fuente: Orallo, Enrique. Disponible en http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
Diagrama
de Actividades.
·
Muestran
las secuencias de actividades de un proceso, incluyendo las actividades
secuenciales, paralelas y as decisiones que se toman.
·
Se
crean preguntando qué pasa en primer lugar, que pasa en segundo lugar y así
sucesivamente.
·
Se
debe determinar si las actividades se realizan en secuencia ó en paralelo.
·
Los
diagramas de actividades se podrían crear examinando todos los escenarios para
un caso de uso.
|
Símbolo |
Significado |
|
|
Evento. Los eventos
representan cosas que ocurren en un lugar determinado. |
|
|
Decisión. Tienen
una flecha que entra en el diamante y varias que salen de él. |
|
|
Actividades. Podría
representar un evento entrando y varios eventos saliendo de la misma, lo que
se conoce como bifurcación. |
|
|
Estado Inicial. |
|
|
Estado Final. |
Fuente: Kendall & Kendall. (p.671)
Diagramas
de Secuencias.
·
Pueden
ilustrar una sucesión de interacciones entre clases ó instancias de objetos en
un periodo determinado.
·
El
tiempo se despliega de arriba abajo
·
Los
diagramas de secuencia se refinan durante la fase de diseño del sistema para
derivar los métodos e interacciones entre las clases.
Ejemplo:

Fuente: Orallo, Enrique. Disponible en http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
Diagramas
de Clases.
·
Muestran
las características estáticas del sistema, no representan ningún procedimiento
en particular.
·
El
diagrama de clases denota los requerimientos de almacenamiento de datos así
como los de procesamiento.
·
Tienen
cuatro categorías de clases; Entidad ( elementos de vida real), Limite ó
Interfaz (Ofrece al usuario un medio para trabajar con el sistema), Abstractas
(Vinculadas con las clases concretas, se denotan como gen/spec) y de Control (Controlan el flujo de actividades y
funcionan como coordinadoras). (Ibídem)
Ejemplo:

Fuente: Orallo, Enrique. Disponible en http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
Diagramas
de Estados.
·
Se
usa para determinar los diferentes estados que podría tener un objeto.
·
Se
crea para una sola clase, por lo general, los objetos se crean, sufren cambios
y se eliminan.
·
No
se crean diagramas de estados para todas las clases, estos se crean cuando:
o
Una
clase tiene un ciclo de vida complejo
o
Una
clase tiene un ciclo de vida operacional
o
Dos
clases dependen entre si
o
El
comportamiento actual del objeto dependo de lo que haya ocurrido antes.
(Ibídem)
Ejemplo:

Fuente: Lamadrid, Victor. Disponible en http://www.informatizate.net/articulos/pdfs/uml_y_el_empleo_de_los_digramas_de_estados_20021012.pdf
Según Lamadrid, Victor. Recuperado el 24 de septiembre del 2008, Disponible en http://www.informatizate.net/articulos/pdfs/uml_y_el_empleo_de_los_digramas_de_estados_20021012.pdf
La
figura anterior muestra una porción de un diagrama de clases en el cual se
puede apreciar la relación existente entre la clase Documento y la clase
Revisión. Pues bien, lo que se da a entender con la asociación entre estas 2
clases es que un documento en particular puede pasar por uno o mas procesos de
revisión. Además este escenario plantea controlar el estado del proceso de
revisión asociado a un documento, por lo que debemos agenciarnos de un
mecanismo que nos permita representar los estados por los que puede transitar
un proceso de revisión durante su ciclo de vida

Fuente: Lamadrid, Victor. Disponible en http://www.informatizate.net/articulos/pdfs/uml_y_el_empleo_de_los_digramas_de_estados_20021012.pdf
3. Utilidad de cada uno de los diagramas.
Según Orallo, E (S/A).
Recuperado el 20 de septiembre del 2008 de http://www.disca.upv.es/enheror/pdf/ActaUML.PDF, define:
·
El diagrama de casos de usos se utiliza para representar 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.
·
El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste
es el diagrama más común a la hora de describir el diseño de los sistemas
orientados a objetos.
·
En el diagrama de secuencia se muestra la interacción de los
objetos que componen un sistema de forma temporal.
Según Popkin Software and Systems. Recuperado el 20 de
Septiembre del 2008 de http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf,
define:
4. Herramientas de
Software que apoyan el modelado UML. Ejemplos y demostración.
Según Popkin Software and Systems. Recuperado el
20 de Septiembre del 2008 de http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf,
define:
Una
característica que beneficia a los modeladores, UML también hace más fácil
escoger una herramienta de modelado. Hace tiempo, el modelador primero tenía
que seleccionar una notación de metodología, y después estaba limitado a
seleccionar una herramienta que la soportara. Ahora con UML como estándar, la
elección de notación ya se ha hecho para el modelador. Y con todas las
herramientas de modelado soportando UML, el modelador puede seleccionar la
herramienta basada en las áreas claves de funcionalidad soportadas que permiten
resolver los problemas y documentar las soluciones.
Según el Hensgen, P. (s/a)., Recuperado
el 22 de septiembre de 2008 de http://docs.kde.org/stable/es/kdesdk/umbrello/working-with-umbrello.html,
define que La
herramienta Umbrello UML Modeller es una aplicación que permite estructurar el
modelado UML en forma sencilla accesible a través del menú y de las barras de
herramientas, pero Umbrello UML Modeller basa su operatividad mediante el uso
constante del botón derecho del ratón.
Los siguientes ejemplos y
demostraciones corresponden al manual antes referenciado el cual establece lo
siguiente:
La
ventana principal de Umbrello UML Modeller está dividida en tres áreas que le
ayudarán a mantener una visión general de todo el sistema y a acceder
rápidamente a los diferentes diagramas mientras trabaja en su proyecto.
Esas
áreas reciben el nombre de:

Fuente: Manual
de Umbrello UML Modeller
La
vista en árbol está situada en la parte superior izquierda de la ventana,
muestra todos los diagramas, clases, actores y casos de uso de los que está
compuesto su esquema. Permite tener una perspectiva de los elementos que
componen su esquema. La vista en árbol también proporciona una forma rápida de
pasar de un diagrama a otro de su esquema así como de introducir elementos de
su esquema en el diagrama actual.
La
ventana de documentación es una ventana pequeña situada al fondo a la izquierda
de Umbrello UML Modeller, la cual permite pre visualizar rápidamente la
documentación para el objeto seleccionado..
El
área de trabajo es el la ventana principal de Umbrello UML Modeller y donde
todo se lleva a cabo la parte importante del trabajo. Aquí es donde editará y
verá los diagramas de su esquema. El área de trabajo muestra el diagrama sobre
el que se está trabajando en cada momento, sólo es posible mostrar uno cada
vez.
Para
empezar a modelar en Umbrello UML Modeller es necesario
crear un esquema sobre el que trabajar. Cuando se inicia Umbrello UML Modeller, siempre se carga el último esquema sobre el
que se ha estado trabajando o crea uno vacío (según la configuración
establecida en preferencias). Esto
permitirá empezar a trabajar inmediatamente.
Si
en algún momento necesita crear un nuevo esquema, hágalo seleccionando (
o pinchando sobre el icono Nuevo en la barra de
herramientas. Si está trabajando en un esquema que ha sido modificado, Umbrello UML Modellerle preguntará si quiere o no guardar sus
cambios antes de cargar el nuevo esquema.
Umbrello UML
Modeller
también le permite ir guardando su trabajo automáticamente cada cierto tiempo.
Puede indicar si desea o no esta opción así como el intervalo de tiempo en .
Umbrello UML
Modeller
sólo puede trabajar en un sólo esquema al mismo tiempo, esto hace que si
intenta cargar un nuevo esquema en el programa cuando ha realizado alguna
modificación sobre el que está trabajando, Umbrello UML Modeller le preguntará
si quiere guardar sus cambios antes de cerrarlo y abrir el nuevo. Puede iniciar
dos o más instancias de Umbrello UML Modeller al mismo
tiempo, también puede copiar y pegar entre dos instancias.
En
Umbrello UML Modeller existen básicamente dos formas de editar los
elementos de su modelo.
·
Editar
los elementos del esquema directamente a través de la vista en árbol.
·
Editarlos
a través de un diagrama.
Usando
el menú contextual de los distintos elementos de la vista en árbol podrá
añadir, eliminar y modificar casi todos los elementos de su esquema. Pinchando
con el botón del ratón sobre las
carpetas en la vista en árbol también podrá crear diferentes tipos de diagramas
dependiendo si la carpeta en cuestión es vista de caso de uso o vista lógica,
actores, casos de uso, clases, etc...
Una
vez que ha añadido algún elemento a su modelo, podrá editarlo mediante su
diálogo de propiedades al que podrá acceder seleccionando la opción Propiedades
en el menú contextual que aparece al pinchar con el botón en los objetos de la vista en árbol.
Su
esquema UML está formado por un conjunto de
elementos de UML y las asociaciones entre ellos.
Dado que no es posible ver el esquema directamente, se usan diagramas
para ello.
Para
crear un nuevo diagrama en su esquema seleccione el tipo de diagrama que
necesita en del menú y asígnele un
nombre. Se creará el diagrama y podrá verlo en la vista de árbol
Si
desea eliminar un diagrama de su esquema, puede hacerlo activándolo y
seleccionando desde el menú . También puede
eliminarlo seleccionado desde el menú contextual
del diagrama en la vista en árbol.
Si
quiere cambiar el nombre de un diagrama ya existente, puede hacerlo
seleccionando Renombrar desde el menú que le aparece al sobre la vista de árbol.
Una
vez que ha creado sus diagramas, es hora de editarlos. Algún novato observador
habrá observado la diferencia entre editar un diagrama y editar el esquema.
Como ya sabrá, los diagramas son vistas de su esquema. Por ejemplo, si crea una
clase editando un diagrama de clases estará editando el diagrama y el modelo,
pero si cambia el color o otra opción visual en un diagrama de clases, estará
editando sólo el diagrama sin modificar el esquema.
Una
de las primeras cosas que hará cuando edite un nuevo diagrama es insertar
elementos en ellos (clases, actores, casos de uso, etc.).
Existen básicamente dos formas de hacer esto:
·
Arrastrando
elementos ya existentes en su esquemas desde la vista en árbol.
·
Crear
nuevos elementos en su modelo y añadirlos a su diagrama al mismo tiempo usando
alguna de las herramientas de edición de la barra de herramientas.
Para
introducir elementos ya existentes en su esquema, simplemente arrástrelos desde
la vista en árbol y suéltelos en el lugar del diagrama donde quiere situarlos.
Siempre podrá mover elementos en los diagramas empleando la herramienta
'Seleccionar'.
Aunque
la edición de propiedades de todos los objetos ya haya sido tratada en la
sección anterior, las clases merecen una explicación adicional debido a su
mayor complejidad y a que poseen más opciones que la mayoría de los elementos
de UML.
En
el diálogo de propiedades de una clase es posible configurar cualquier
parámetro, desde el color que emplea hasta sus atributos y operaciones.
La
pestaña de preferencias generales del diálogo de propiedades se explica por si
mismo. Desde ahí podrá cambiar el nombre de la clase, la visibilidad, la
documentación, etc.. Esta pestaña siempre está
disponible.
En
la configuración de atributos podrá añadir, editar o borrar atributos
(variables) de una clase. Puede mover atributos arriba y abajo en la lista
pulsando la flecha del lateral de la ventana. Esta pestaña siempre está
disponible.
De
modo similar a la página de configuración de atributos, aquí podrá añadir,
editar y borrar operaciones de su clase. Cuando añada o edite una operación,
deberá insertar la información básica en el diálogo Propiedades de operaciones.
Si lo que desea es añadir parámetros a su operación deberá pulsar sobre
para que se muestre el diálogo Propiedades del parámetro. Esta página siempre está
disponible.
Desde
ahí podrá añadir plantillas de clase, es decir clases no especificas o tipos de
datos. En Java 1.5 recibirán el nombre de genéricas.
La
página de asociaciones de clase muestra todas las
asociaciones de esa clase en el diagrama actual. Si hace doble click sobre una
asociación podrá ver sus propiedades y, dependiendo del tipo de asociación
podrá modificar algunos parámetros tales como el nombre del rol o incluir multiplicidad.
Si la asociación no permite que estas opciones sean modificadas, el diálogo de
propiedades de asociación será de sólo lectura y sólo podrá modificar la
documentación asociada con esta asociación.
Las
asociaciones relacionan dos objetos UML entre si.
Normalmente, las asociaciones se definen entre dos clases, sin embargo algunos
tipos de asociación también pueden darse entre casos de uso y actores.
Para
crear una asociación seleccione la herramienta adecuada en la barra de herramientas
de trabajo (asociación genérica, generalización, agregación, etc.) y pinche primero sobre el primer elemento de la
asociación y luego sobre el segundo. Observe que lo que hacemos son dos clics, no
arrastrar el clic de un objeto a otro.
Umbrello UML
Modeller
puede generar código fuente en varios lenguajes de programación, a partir de la
maqueta UML para ayudar a comenzar la implementación de su proyecto. El código
generado consta de declaraciones de clases con sus métodos y atributos, de
forma que usted pueda “rellenar los espacios en blanco”
proporcionando la funcionalidad de las operaciones de sus clases.
El
primer paso es seleccionar las clases para las que desea generar código fuente.
De forma predeterminada se seleccionan todas las clases de la maqueta, y usted
puede eliminar aquellas para las que no desea generar código eliminándolas de
la lista de la izquierda.
El
siguiente paso del asistente le permite modificar los parámetros que el
generador de código utilizará en el proceso. Las opciones disponibles son las
siguientes:

Opciones de
generación de código en Umbrello UML Modeller
La
opción Escribir comentarios de documentación aún si está vacía instruye al
Generador de código a escribir comentarios del tipo /** blah */ aún cuando el
bloque de comentarios se encuentre vacío. Si usted ya agregó documentación a
sus clases, métodos o atributos en su Maqueta, el Generador de código escribirá
estos comentarios como documentación Doxygen sin
importar lo que haya definido aquí, pero si selecciona esta opción Umbrello UML Modeller escribirá comentarios para todas sus clases,
métodos y atributos aún cuando no exista documentación en
Escribir comentarios para las
secciones incluso si la sección está vacía producirá que Umbrello UML Modeller escriba comentarios en el código fuente para
delimitar las diferentes secciones de una clase. Por ejemplo “Métodos públicos” o “Atributos”
antes de la sección correspondiente. Si selecciona esta opción Umbrello UML Modeller escribirá los comentarios para todas las
secciones de las clases aún si la sección está vacía. Por ejemplo, escribirá un
comentario diciendo “Métodos protegidos” aún si no
existen métodos protegidos en su clase. (Ibídem)
Escribir todos los archivos generados
a la carpeta.
Aquí debe seleccionar la carpeta donde desea que Umbrello
UML Modeller
guarde los archivos fuente generados.
La
opción Incluir archivos de cabecera desde la carpeta le permite insertar
un encabezado al comienzo de cada archivo generado. Los archivos de encabezado
pueden contener información acerca del copyright o la licencia, y contener
variables que son evaluadas al momento de generación. Usted puede mirar a modo
de ejemplo los archivos de encabezamiento distribuidos con Umbrello UML Modeller para ver como se utilizan estas variables
para reemplazar su nombre o la fecha y hora del momento de generación.
Esta
opción le dice a Umbrello UML Modeller qué hacer si el archivo que desea crear ya
existe en la carpeta de destino. Umbrello UML Modeller no puede modificar
archivos fuente existentes, por lo que debe elegir entre sobrescribir
el existente, saltar la generación de ese archivo en particular, o dejar que Umbrello UML Modeller elija un nombre diferente para el archivo.
Umbrello UML
Modeller
generará por omisión código fuente en el lenguaje que usted haya seleccionado
como Lenguaje activo, pero con el Asistente para la generación de código usted
tiene la opción de cambiar esto a otro idioma.
El
tercero y último paso del asistente le mostrará el estado del proceso de
generación de código. Usted necesitará hacer clic en el botón de Generación de
código para que las clases sean escritas para usted.
Recuerde
que las opciones que seleccione en el asistente de generación de código sólo
son válidas para esa generación en concreto, la siguiente vez que ejecute el
asistente deberá volver a seleccionar todas las opciones aunque sean las
mismas. Puede evitar esto definiendo en la sección Generación
de código
del menú ->Umbrello UML
Modeller
Si
ha ha establecido las opciones del asistente de generación de código y quiere
generar directamente algún código sin el asistente, seleccione
desde el menú Código. Esto generará código para todas las clases de su esquema
con la configuración actual (incluso la carpeta de salida y las opciones de sobre
escritura así que tenga cuidado).
Umbrello
UML Modeller puede importar código fuente de sus proyectos actuales para
ayudarle a crear los esquemas de sus sistemas. Umbrello UML Modeller 1.2 sólo
puede hacerlo con C++ aunque en el futuro estará disponible para más lenguajes.
Para
importar clases en su esquema seleccione la entrada Importar clases desde el
menú Código. Una vez ahí, seleccione los archivos que contengan las
declaraciones de clases de C++ y pulse aceptar. Se importaran las clases y
pasarán a ser parte de su esquema en la vista en árbol. Recuerde que Umbrello
UML Modeller no creará ningún tipo de diagrama para mostrar sus clases, sólo
las importará a su esquema para que pueda usarlas luego en cualquier diagrama. (ibídem)
5. Caso Práctico.
Aplicar el Diagrama de Casos de Uso a una problemática presentada en su
empresa.
Descripción General
Ante
la decisión de controlar la operatividad del Archivo Central de
Entorno del Sistema
Las
acciones y reacciones del comportamiento del sistema, definen sus límites y sus
relaciones con el entorno, para expresar esto gráficamente a continuación se
incluyen una serie de diagramas.
Diagrama 1

En
el diagrama número 1 se muestra una vista general del entorno del sistema de
Archivo Central de
A
continuación de destaca por su importancia en el funcionamiento del archivo,
una serie de operaciones no informáticas ejecutadas en la recepción de
expedientes.
Diagrama 2

Objetivo: Los responsables de la diferentes Dependencias
(Jefes y Directores) que integran el órgano contralor entregan un conjunto de
expedientes para ser almacenados en el Archivo Central.
Actores: Funcionarios responsables (Jefes y Directores),
Funcionario Archivo Central.
Flujo de eventos principal:
·
Los funcionarios responsables (Jefes y
Directores) entregan un conjunto de cajas archivadoras con los expedientes.
·
El conjunto de cajas es controlado por un
funcionario del Archivo Central
(Include Control de cajas).
·
(Excepción: Existen diferencias entre el contenido
de las cajas y lo declarado)
·
El Usuario del Archivo Central para esto
clasifica los expedientes recibidos (Include: Clasificación de expedientes)
Flujo de eventos excepcional:
·
(Excepción: Existen diferencias entre el
contenido de las cajas y lo declarado) Se observa la operación.
Descripción
Funcional
A
efectos de mostrar una descripción funcional del sistema, se presentan las
funcionalidades a cubrir. Se incluyen una serie de diagramas de casos de uso.
Estos describen la funcionalidad del sistema cuando se desencadena una
respuesta a la estimulación de un actor externo.
Ingresos de expedientes
Luego
de haber recibido los lotes de expedientes y terminado con todos los controles
manuales sobre el estado de los mismos, los funcionarios proceden al ingreso de
la información en el sistema.
A
continuación se describe este caso de uso.
Nombre: Ingreso al archivo.
Objetivo: Ingresar al sistema informático los datos
correspondientes a los expedientes recibidos.
Flujo de eventos principal:
·
El usuario con el rol de maker, ingresa los
datos de cada expediente (Include: Ingreso datos al Sistema).
·
El usuario con el rol de checker, verifica los
datos ingresados (include: Validación de datos).
·
(Excepción: Existen errores en el ingreso de la
información).
·
Finaliza
la operación imprimiendo una etiqueta para cada expediente ingresado (Include:
Imprimir).
Flujo de eventos excepcional:
·
(excepción: Existen errores en el ingreso de la
información) El usuario checker solicita al maker la corrección de los mismos.
Diagrama 3

El
diagrama 4 describe el flujo de operaciones desencadenado por los eventos que
inician y envían al sistema los usuarios del Archivo Central en el caso de uso
“Ingreso al archivo”.
Diagrama 4

La
operación se inicia con el ingreso de datos por un usuario maker,
posteriormente estos son verificados por un usuario chequer, si se encuentran
errores no se valida el ingreso y se solicita al usuario maker que corrija el
ingreso. El usuario maker revisa el ingreso y define si debe modificar los
datos o eliminar el registro. Si los datos son modificados, el usuario ckecker
vuelve a revisar el ingreso, si esta correcto valida la operación, asigna e
imprime una clave que referencia físicamente la ubicación del expediente en el
archivo
Egresos de expedientes
En
el desarrollo de la actividad de
Una
vez realizada la solicitud de desincorporación, los funcionarios del Archivo
Central proceden a ubicar, registrar y devolver estos expedientes. A
continuación se describe este caso de uso.
Nombre: Solicitud de desincorporación.
Objetivo: Devolver a
Actores:
Flujo de evento principal:
·
La Contraloría General del Estado Falcón
solicita expedientes y este pedido es recibido por un usuario del Archivo
Central.
·
(Excepción: No existe el expediente)
·
(Excepción: El solicitante no esta habilitado
para el retiro del expediente pedido)
Flujo de eventos excepcional:
(Excepción:
No existe el expediente) No se puede satisfacer el pedido.
(Excepción:
El solicitante no esta habilitado para el retiro del expediente pedido) Solo un
administrador del Archivo Central puede habilitar el retiro.
Diagrama 5

El diagrama 6 describe el flujo de operaciones
desencadenado por los eventos que inician y envían al sistema los actores en el
caso de uso “Solicitud de desincorporación”.
Diagrama
6

La desincorporación del archivo se inicia cuando una
dependencia de
Reingreso de
expedientes
Finalizadas las instancias posteriores a una
desincorporación, las dependencias de
Nombre: Reintegro de
expedientes.
Objetivo: Las
dependencias devuelven un expediente al Archivo Central.
Actores:
Flujo
de eventos principal:
·
La Contraloría General del Estado Falcón devuelve un
expediente y este es recibido por un usuario del Archivo Central.
Diagrama
7

En el diagrama
8 se describe el flujo de actividad desencadenando por los eventos que envían
los actores al sistema en el caso de uso “Reintegro de expedientes”.
Diagrama 8

Consulta
en sala
El Archivo
Central también brinda servicios al público en general. Todo ciudadano puede
presentarse en la oficina y solicitar cualquier expediente para su consulta en
la sala de lectura del Archivo. A continuación se describe este caso de uso.
Nombre:
Consulta en sala.
Objetivo: Cualquier
persona solicita información sobre unos expedientes.
Actores: Público,
usuario Archivo Central.
Flujo
de eventos principal:
·
Un individuo solicita información sobre un expediente
y este pedido es recibido por un usuario del Archivo Central
·
(Excepción: No existe el expediente)
·
Finaliza la operación obteniendo la información
solicitada relativa al expedientes
Flujo
de eventos Excepcional:
(Excepción no
existe el expediente) No se puede satisfacer el pedido
Diagrama
9

En el diagrama 10 se describe el flujo de actividad
desencadenado por los eventos en envían los actores al sistema en el caso de
uso “Consulta”.

Bibliografía.
Kendall & Kendall. “Análisis
y Diseño de Sistemas” . Ed. Pretince Hall. México. 2005.
Consultas on line.
HENSGEN, Paul. (s/a).Trabajando con Umbrello UML Modeller. Disponible: http://docs.kde.org/stable/es/kdesdk/umbrello/working-with-umbrello.html.
[Pagina Web en Línea].
[Consultado, 2008, Septiembre 22]
Popkin Software and Systems. (s/a). Modelado de Sistemas con UML. Disponible: http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf.
[Pagina
Web en Línea]. [ Consultado, 2008, Setiembre 20]
LAMADRID,
Víctor.(s/a). UML. Disponible en http://www.informatizate.net/articulos/pdfs/uml_y_el_empleo_de_los_digramas_de_estados_20021012.pdf.
[Pagina Web en Línea]. [ Consultado, 2008, Setiembre 24]
ORALLO, Enrique (s/a). El
Lenguaje Unificado de Modelado UML. Disponible: http://www.disca.upv.es/enheror/pdf/ActaUML.PDF.
[Pagina Web en Línea]. [Consultado, 2008,Septiembre 20]
VILALTA,
Joseph (2008). Introducción a UML.
Disponible: http://www.vico.org/aRecursosPrivats/TRAD_introUML.pdf.
[Pagina Web en Línea]. [Consultado, 2008, Setiembre 20]