Propuesta de Software “Downtime”

Entrega 2 del Proyecto de Aula: Estructuras de Datos

EXTRACTO
Descripción General de la propuesta de trabajo para la construcción de producto de
software e identificación de los diferentes requerimientos para su desarrollo. Incluye
una propuesta de GUI. Presentado al tutor del Módulo Ing. Nelsón Orlando Pérez
Echeverri. Politécnico Grancolombiano. Septiembre 14 de 2015.
 Segunda Entrega
Proyecto de Aula
Estructuras de datos - 20152

Tabla de contenido
Primera Entrega.................................................................................. 2
Introducción...............................................................................................2
1. Integrantes...........................................................................................3
2. Nombre del proyecto.............................................................................3
3. Objetivos..............................................................................................3
4. Resultados esperados............................................................................3
5. Descripción...........................................................................................4
6. Aplicabilidad de los temas del módulo....................................................5
7. Requerimientos funcionales...................................................................6

INTRODUCCIÓN
De acuerdo a lo solicitado en la primera entrega del “Proyecto de Aula” del módulo de “Estructuras
de Datos” el propósito esperado es la definición de los objetivos y metas del proyecto, estableciendo los
requerimientos funcionales del producto y hacer un análisis del problema; enuncia, para cada funcionalidad,
sus precondiciones y sus pos condiciones junto a una estrategia de solución.
Así mismo, el presente documento define lo que se quiere lograr con el desarrollo del proyecto y si es
viable la implementación del proyecto en las semanas que dura el módulo. Por otra parte, muestra ¿Qué se
tendrá como resultado del proyecto? Liado al relato, en lenguaje natural, de lo que debería hacer el software
a construir. Es decir, una lista de servicios que ofrecerá al usuario el producto final y la interacción con el
usuario a través de una interfaz gráfica. Se describir á́ en forma detallada las interfaces de usuario, de
software y los requerimientos del problema objeto de análisis como de los correspondientes atributos del
sistema.
Antes de esto, el presente trabajo ilustra ¿Cómo se piensa vincular el contenido del módulo con el
desarrollo del proyecto? Para el presente trabajo, se requiere presentar, por parte del grupo de trabajo, 3
informes de progreso. Los informes a entregar son: primer entrega (14 de septiembre): Identificar el
problema y contextualizarlo; segunda entrega (28 de septiembre): describirlo con casos de uso y
pseudocódigos; Informe final (12 de octubre): diseño final de la propuesta y entrega del producto de
software (incluida sustentación).
Con relación a la especificación de requerimientos de software (SRS) del sistema a construir, el
propósito principal es el de contener la información necesaria que ayude, posteriormente, en la fase de
desarrollo del software; que sirva como herramienta para el análisis y comprensión de todos los requisitos y
requerimientos que se esperan obtener en el desarrollo del presente trabajo académico de Estructuras de
datos. Que describa lo que el realmente se desea obtener, y poder lograr tener un documento necesario
cuya información sirva para el desarrollo del software, es decir en la codificación correcta del mismo.
 Entrega 1

1. NOMBRE DEL PROYECTO.

“Downtime”.
1.1. Descripción General del Proyecto
Sistema para la solicitud de un servicio de atención basado en turnos, denominado “Downtime”,
mediante un aplicativo de Software, codificado en lenguaje de Programación JAVA y utilizando diversas
estructuras de Datos.

2. OBJETIVOS.
2.1. Objetivo General
- Desarrollar un sistema de software que permita la gestión de servicio por turnos de
disponibilidad, a través de la utilización de diferentes estructuras de datos que permitan
la manipulación de la información.

2.2. Objetivos específicos

- Aprender la construcción de algoritmos que incluyan estructuras de datos (listas.
sistemas circulares, listas enlazadas, arboles binarios, grafos, entre otros) y aplicarlos en
la construcción del proyecto de software.
- Identificar los recursos y herramientas para desarrollar un correcto proceso de modelado,
siguiendo cada una de las fases del proceso de construcción de software, así como de su
presentación y preparación de informes a través del estándar UML.
- Desarrollar una implementación que satisfaga los requerimientos funcionales y no
funcionales.
3. RESULTADOS ESPERADOS.
Se espera que al terminar las 6 semanas de duración de la actividad, se pueda contar con un
sistema de software que permita la gestión de solicitudes de servicio, basado en turnos de las enfermeras
de una clínica de reposo. Este producto contará, además, con un documento de modelado a partir de los
“casos de uso” y algunas herramientas del estándar UML.
Adicionalmente, se trabajan algunas estructuras de datos, a fin de evidenciar el conocimiento y
manejo de algoritmos para casos específicos de manipulación de información, por lo que, durante las fases
posteriores, se harán mejoras y adaptación para vincular los conocimientos adquiridos en el desarrollo del
módulo de “Estructuras de Datos”, para poder incluirlos en el producto de software final.
La idea, es lograr la completitud de la propuesta. Es decir, lograr dar una respuesta eficiente a los
diferentes requerimientos solicitados en la presente fases de análisis. Por un lado, respecto a los
requerimientos funcionales y no funcionales, como a la presencia de una interfaz gráfica que permita la
interacción con el usuario.
4. DESCRIPCIÓN.
De acuerdo a los enunciados propuestos por el profesor, el grupo ha decidido tomar como selección
el enunciado numero dos que dice lo siguiente:
Enunciado 2
En una Casa de Reposo se debe permitir a un médico solicitar una enfermera para
 atender a un paciente. Como no es muy usual esto, las enfermeras están organizadas
de manera que en todo momento solo haya una disponible.

Cada enfermera se identifica por su nombre y tiene asignado en minutos la duración

de su turno. La enfermera que está de turno, sabe además el tiempo que le falta para
terminar su turno y si está ocupada con un paciente.

Los turnos de las enfermeras están organizados de manera circular.

Al principio no había ni tantos pacientes, ni médicos, ni enfermeras y se llevaba a

mano la bitácora con ayuda del tradicional reloj de pared, pero ahora se necesita de
un sistema más automático.

Los doctores requieren saber cuántas enfermeras hay en el hospicio, conocer cual
está de turno, indicar cuánto le falta a una enfermera (dado su id) para comenzar su
turno. Ocupar a la enfermera de turno con un paciente (retorna la enfermera de turno
si no está ocupada, o null en caso contrario); la enfermera se libera al terminar la
atención (la enferma de turno que estaba ocupada atendiendo a un paciente queda de
nuevo disponible, salvo que su turno haya terminado en cuyo caso pasa a la última
posición, si no estaba ocupada informa del error).

El sistema debe avanzar turno un minuto, de tal suerte que la enfermera que está de
turno disminuye el tiempo que le falta en 1. Si llega a 0, se inicia el turno de la
siguiente enfermera que no esté ocupada con paciente, pasando la que salió de turno
a ocupar la última posición.

Además, las enfermeras por supuesto entran y salen de trabajar de acuerdo con la
necesidad de la entidad, de tal suerte que al ingresar al trabajo una enfermera se
coloca en la última posición y al salir la enfermera del asilo se retira del sistema
circular.

En resumen, a continuación presentamos la descripción particular que se hace de la misma referencia, con
las correspondientes consideraciones, cambios, o comprensiones que se tienen del ejercicio.
El propósito es construir un sistema para la solicitud, por parte de un doctor, de una
enfermera para la atención de un paciente.
Como podemos observar, tenemos tres sujetos (actores) que intervienen en este concepto: Doctor,
enfermera, paciente; y por tanto debe existir un registro de doctores, de enfermeras y de pacientes. En el
caso de las enfermeras,
cada enfermera se identifica por su nombre y tiene asignado en minutos la duración
de su turno.
Mientras que los pacientes, tienen asociados un pabellón y una habitación. Los doctores un nombre.
Estimamos que el turno de la enfermera dura 8 horas, lo que equivale a 480 minutos en turno y un
descanso de 960 minutos. Ahora, del numero de enfermeras que están de turno,
están organizadas de manera que en todo momento solo haya una disponible y sus
turnos están organizados de manera circular.

Por otra parte, el sistema debe permitir conocer cierta información, tal como:
 La enfermera de turno, sabe además el tiempo que le falta para terminar su turno

La enfermera de turno, sabe si está ocupada con un paciente.

Los doctores requieren saber cuántas enfermeras hay en el hospicio,

Los doctores requieren conocer cual está de turno,

Los doctores requieren saber cuánto le falta a una enfermera (dado su id) para
comenzar su turno.

Los doctores y las enfermeras requieren saber si ha cambiado el estado de

disponibilidad de una enfermera en particular (Ocupar a la enfermera de turno con un
paciente)

Para dicha gestión de estados, el sistema muestra la enfermera disponible, las que están en turno y las que
están de descanso. Para una mejor comprensión del siguiente párrafo,

retorna la enfermera de turno si no está ocupada, o null en caso contrario; la

enfermera se libera al terminar la atención (la enferma de turno que estaba ocupada
atendiendo a un paciente queda de nuevo disponible, salvo que su turno haya
terminado en cuyo caso pasa a la última posición, si no estaba ocupada informa del
error).

Vamos a considerar los siguientes aspectos:

El doctor hace la solicitud de la enfermera que tiene estado disponible, la cual acepta
el servicio y cambia su estado a “ocupada”. La siguiente enfermera de turno, pasa a
estado “disponible”. Al terminar el servicio, la enfermera que estaba ocupada pasa al
final de la lista de enfermeras de turno hasta que concluya dicho turno. Cuando una
enfermera entra, cambia su estado “de descanso” a “en turno” (ver nota siguiente) y
ocupa el final de la lista de turnos en espera de “disponible”.

Nota: Además, las enfermeras por supuesto entran y salen de trabajar de acuerdo con
la necesidad de la entidad, de tal suerte que al ingresar al trabajo una enfermera se
coloca en la última posición y al salir la enfermera del asilo se retira del sistema
circular

Por otro lado, el sistema gestiona el tiempo, tanto para los turnos como para indicar la hora de acuerdo a los
siguientes criterios:

Al principio no había ni tantos pacientes, ni médicos, ni enfermeras y se llevaba a

mano la bitácora con ayuda del tradicional reloj de pared, pero ahora se necesita de
un sistema más automático.

El sistema debe avanzar turno un minuto, de tal suerte que la enfermera que está de
turno disminuye el tiempo que le falta en 1. Si llega a 0, se inicia el turno de la
siguiente enfermera que no esté ocupada con paciente, pasando la que salió de turno
a ocupar la última posición.
Para este último aspecto, las enfermeras que están “en descanso”, ocupan la posición “en turno” cuando
una enfermera termina su turno y cambia su estado a “en descanso”.

5. APLICABILIDAD DE LOS TEMAS DEL MÓDULO.

Como ya se ha expuesto anteriormente, la idea central del presente proyecto
es trabajar diversas estructuras de datos (en memoria principal). Por ejemplo,
manejo de listas (arreglos) en el caso de los datos obtenidos. Sistemas circulares
como se expresa en la forma en que están organizados los turnos y disponibilidades
de las enfermeras.
Así mismo, se hará uso de algoritmos de búsqueda, ordenamiento, vectores y
matrices, Arboles binarios y n-arios, grafos, entre otros. Para algunas
funcionalidades, utilizaremos pilas o colas según el caso; bien sea, porque una
enfermera deja de atender un paciente y vuelve al final del grupo; o porque va
siguiéndose en turno un grupo, el cual esta mediado por factores temporales.
Desde luego, y algo que va muy ligado a las estructuras de datos, son los
algoritmos, ya que estos permitirán manejar la información, recuperarla
transformarla y/o modificarla, agregar y o eliminar registros, entre otros.
6. REQUERIMIENTOS FUNCIONALES.
El sistema que se va ha desarrollar es independiente, y tendr á́ un diseño modular para gestionar cuatro
aspectos de una clínica de reposo: Consultas, Registro, Estados y Solicitudes. Estos son los cuatro ejes
principales del sistema, en orden de importancia.

Registro Estados Solicitud Consultas

Así mismo, la funcionalidad del producto plantea la siguiente estructura:

Downtime

Gestión de Registro Asignacion

turnos personas es

Control de Enfermera Solicitud

estados s servicios

Consulta
de Aceptacion
informació Pacientes servicios
n

Mostrar Terminacio
tiempo Doctores n servicios
Se han establecido como actores del sistema los siguientes (el actor paciente no tiene interacción con el
sistema y por tanto no tiene numeración):

Actor Enfermera # 001

Casos de Solicitar Enfermera, Asignar Estado, Gestionar Turno, Listar
Uso Turno
Tipo Secundario
Descripción Es una actor importante respecto a la interacción, sin embargo,
no realiza ninguna gestión en el sistema. Usa el sistema como
medio de consulta y acepta y termina solicitudes.
Condiciones Estar registrada en el sistema
especiales

Actor Doctor # 002

Casos de Validar Doctor, Solicitar Enfermera, Asignar Estado, Registrar
Uso Persona, Gestionar Turno, Consultar Tiempos, Listar Turno.
Tipo Primario
Descripción Es el actor principal, lleva el registro y gestiona la información
del sistema, además que envía solicitudes y puede consultar
cualquier información que se haya generado.
Condiciones
especiales

Actor System
Casos de Gestionar Turno, Contar Tiempos de turno, Consultar Tiempos y
Uso listar Turno
Tipo Primario
Descripción Sistema externo para el control de los turnos y los tiempos
((métodos CRUD),
Condiciones Sistema Lógico de tratamiento de datos.
especiales

Dentro de los requerimientos no funcionales encontramos

Actor Reloj
Casos de Mostrar Tiempo
Uso
Tipo No esencial
Descripción Muestra el día y la hora, a fin de simular el esquema de trabajo
que existía antes de la automatización del sistema.
Condiciones Ninguna
especiales

Los siguientes son los requisitos específicos del sistema:

 CODIG NOMBRE DEL OBJETIVO
O REQUERIMIENTO
RF01 Validar Doctor Permitir al Médico Operar el sistema

RF02 Solicitar Enfermera Solicitar, por parte del médico, una enfermera para atender un paciente

Asignar una enfermera Como "Disponible" y cambiar estado a "Ocupada" cuando su servicio es
RF03 Asignar Estado
solicitado

Ingresar al sistema los datos de una enfermera, de un paciente o de un medico según el caso y
RF04 Registrar Persona
almacenar dicha información para posteriores consultas

RF05 Gestionar Turno Permitir el ingreso y liberación de enfermeras de un turno

RF06 Contar Tiempos de Turnos Contabiliza los tiempos de los turnos de las enfermeras

Consultar el tiempo que le queda a una enfermera en particular, para terminar su turno o para
RF07 Consultar Tiempos
ingresar al turno
Listar a las enfermeras (TODAS) que hay en el Hospicio, indicando cuales estàn de turno para
RF08 Listar Turno
ser consultadas por los doctores

La siguiente es una propuesta de interfaz gráfica de usuario del sistema en una versión preliminar.

Ventana Principal, desde donde se gestiona todo el sistema.

Ventana para la selección del Registro, cuando el doctor se vincula a la función Registrar.
Formulario de Registro de Pacientes. La variación con los formularios de enfermera y doctor, radican
únicamente en los datos que se capturan.

A continuación presentamos una propuesta preliminar del diagrama de Clases (esta estructura junto a los
demás elementos expuestos en esta entrega, serán mejorados respecto a la forma de presentar la
información mediante el estándar UML, ya que la segunda entrega define los casos de uso, junto a otros
aspectos que modifican estas clases, ya que cada vez el trabajo será más específico).
 Entrega 2

2.1. LOS CASOS DE USO

Una definición concreta de que es un caso de uso lo podemos definir como “Los casos de uso
describen secuencias de acciones que realiza un sistema y que lleva a un resultado de valor a un actor
específico”. Dada la definición nos lleva a pensar que los casos de uso nos permiten estructurar las
secuencias de pasos para identificar, organizar y definir dichas actividades llevara a un resultado
compuesto, Los Casos de Uso representan lo que un actor desea que haga el Sistema.
Los casos de uso definen una secuencia de acciones ejecutadas por un sistema que producen un
resultado observable de valor para un actor. De igual forma podemos definir los casos de usos de otras
formas: “Un caso de uso es un conjunto de escenarios que tienen una meta de usuario en común Martin
Fowler”, “Caso de Uso: Es una descripción de un proceso fina-fin, relativamente largo, que incluye varias
etapas o transacciones”, “Es una manera específica de utilizar el sistema, es una historia que describe un
uso particular del sistema”. Dentro de sus ventajas están?
- La técnica de caso de uso tiene éxito en sistemas interactivos.
- Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades
del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en
informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
- Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no
establecen requisitos funcionales ni permiten determinar los requisitos no funcionales.
- Los casos de uso deben complementarse con información adicional como reglas de negocio,
requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema.
Sin embargo la sobre el funcionamiento especifica que cada caso crítico del uso debe tener un
requisito no funcional centrado en el funcionamiento asociado.
Podemos considerar que los casos de uso son de vital importancia en los proyectos de software
(Procesos Guiados por Casos de Uso), también describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el punto de vista de un usuario y permiten definir los límites del
sistema y las relaciones entre el sistema y su entorno característica que es muy importante. Los casos de
uso evitan la sintaxis técnica, prefiriendo la lengua de usuario final o del experto del campo del saber al que
se va a aplicar. En la mayoría de casos son elaborados en colaboración por los analistas de requerimientos
y los clientes con el fin de describir y desglosar en lo posible el diseño.
Cada caso de uso se basa en describir cómo alcanzar una única meta o solución a una tarea. Desde
una perspectiva tradicional de la ingeniería de software, un caso de uso describe una característica del
sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario
especificar varios casos de uso para definir completamente el nuevo sistema. Los casos de uso pretenden
ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso de uso
contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el
software o el sistema.
Un caso de uso describe desde el punto de vista de los actores, un grupo de actividades de un
sistema que produce un resultado concreto y tangible. Cuando se trabaja con casos de uso, es importante
tener presentes algunas reglas: Cada caso de uso está relacionado como mínimo con un actor, Cada caso de
uso es un iniciador (es decir, un actor), Cada caso de uso lleva a un resultado. Un caso de uso debe:
Describir una tarea del negocio que sirva a una meta de negocio, Tener un nivel apropiado del detalle, Ser
bastante sencillo con una idea concreta.
Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más
comunes entre casos de uso son:
- <<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso
de uso
 - <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de
extensión) un caso de uso será extendido por otro.
- Generalización que especifica que un caso de uso hereda las características del «super» caso de uso,
y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre
clases.
“Un actor es una entidad externa que interacciona con el sistema participando (y normalmente
iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros
ordenadores o eventos externos”. “Los actores no representan a personas físicas o a sistemas, sino su rol.
Esto significa que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo
diferentes papeles), estará representado por varios actores. Por ejemplo, una persona que proporciona
servicios de atención telefónica a clientes y realiza pedidos para los clientes estaría representada por un
actor «equipo de soporte» y por otro actor «representante de ventas»”
Los casos de uso no muestran ninguna funcionalidad interna del sistema, ni como se solucionara.
Simplemente muestran los pasos que el actor sigue para realizar una tarea.
Dentro de los Tipos de Actores encontramos:
- Primarios : Interaccionan con el sistema para explotar su funcionamiento, trabajan directamente
con el software
- Secundarios: Soporte del sistema para que los actores primarios puedan trabajar
- Iniciadores: No utilizan directamente el sistema pero desencadenan el trabajo de otro actor.
Los casos de uso, como el resto de los requisitos, deben tener una redacción cuidadosa para no
tener problemas o malos entendidos con su interpretación. Este debe describir qué debe hacer el sistema a
desarrollar su funcionamiento pero no como hacerlo. Es decir, solo debe mostrar la parte funcional y su
nombre, debe mostrar el objetivo que pretende alcanzar. Se debe ser cuidadoso al usar estructuras
condicionales en la descripción del caso de uso, ya que los clientes y usuarios no suelen estar familiarizados
con este tipo de estructuras, especialmente si son complejas.
El funcionamiento principal y por el cual se acude a desarrollar un caso es de uso es para que un
ingeniero analista o programador pueda tener una idea más claras y verlo desde un buen punto de vista,
además la persona puede ver el avance de los procesos y darle orden a cada secuencia y a casa paso con el
fin de encontrar la solución, incluso puede detallar posibles inconvenientes de diseño que se pueden
presentar.
Al momento de desarrollar una aplicación compleja o con varios procesos es muy importante realizar
un buen análisis. Para que el análisis sea lo mejor posible es necesario tener hecho un buen diagrama de
casos de uso. No se debe confundir un caso de uso con un diagrama de casos de uso; aunque relacionados
no son lo mismo, un diagrama de casos de uso es un poco más resumido. Toda la elaboración diseño y
construcción de un caso de uso se puede resumir en 5 pasos como mínimo.
- Conocer los requerimientos del proyecto que vas a desarrollar. Por ejemplo si se trata de un
proyecto de prestaciones de servicios médicos, debes conocer y estar en constante investigación
sobre (hospitales servicios horarios medicamentos etc)
- Cuando tengas un conocimiento amplio del proyecto a desarrollar, en una hoja o en el ordenador usa
un sistema de listas que te ayudará a vislumbrar el diagrama de casos de uso definitivo.
- Haz una primera lista con todas las acciones posibles que se puedan llevar a cabo en la aplicación.
- Después hacer una lista más específica con una selección de instrucciones más relevantes que se
realizarán en la aplicación. Estas acciones serán las que aparezcan en el diagrama final.
 Fig. 1. Caso de Uso.
Un diagrama de casos de uso es una forma de diagrama de comportamiento UML mejorado.
“El Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar casos de uso
llamada modelo de casos de uso”. Los diagramas de casos de uso son muy confundidos con los casos de
uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los
diagramas de casos de uso.
La interacción de actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial
para una descripción de lo deseado, quizás los límites del sistema o del caso de uso deban de ser re-
examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el
caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa
pueden jugar varios papeles o roles.
Los diagramas de casos de uso muestran las relaciones entre los casos de uso del sistema y sus
actores; dan son una sola visión general del modelo de casos de uso donde el 90 % del contenido del
modelo de casos de uso está en las descripciones de los casos, ya que ayudan interpretar y esclarecer los
casos de uso Se suelen elaborar durante el análisis inicial del caso de uso. Las partes que lo componen
incluyen:
- Actores
- Casos de uso
- Relaciones
- Puede aparecer un rectángulo que muestre los límites del sistema
- Los casos de uso se representa mediante elipses con el nombre del caso
- Los actores pueden representarse mediante un o mediante rectángulos en que se indique <<actor
>>
- En los diagramas, tanto los actores como los casos de uso representan no las instancias particulares,
sino los conjuntos de todos los actores de un tipo y de todos los escenarios.

Las asociaciones entre actores y casos de uso:

- Se representan mediante una línea continua
- Significan la participación del actor en el caso de uso
- Pueden indicarse restricciones de cardinalidad
- Generalización especialización entre actores
- Indicarían que un actor es más general que otro
- si A es una especialización de B, una instancia de A podría comunicarse con los mismos casos de
uso que B
 En internet, existen muchos recursos que facilitan el aprendizaje y comprensión de los temás para el
modelado de sistema informáticos a través del estándar UML, y son multiples los ejemplos en los que
podemos identificar los elementos y principales caracte risticas de los casos de uso. Uno de ellos, que nos
parecio muy interesante es el del modelo de la maquina recicladora, que se encuentra disponible en.
http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html para una construcción personal, hemos
especificado todos los elementos de este método de análisis de los requerimiento de software, en el caso
que trabajamos en el proyecto de aula.
Una Máquina Recicladora
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe
controlar y/o aceptar:
• Registrar el número de ítemes ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
a Describe lo depositado
b El valor de cada item
c Total
• El usuario/cliente presiona el botón de comienzo
• Existe un operador que desea saber lo siguiente:
a Cuantos ítemes han sido retornados en el día.
b Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
• El operador debe además poder cambiar:
a Información asociada a ítemes.
b Dar una alarma en el caso de que:
i Item se atora.
ii No hay más papel.
Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información
de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún
item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

2.2. ELABORACIÓN DE CASOS DE USO DEL SISTEMA “DOWNTIME".
Para consultar este contenido remitirse al archivo de Excel adjunto a esta entrega llamado “Casos de
Uso Downtime”. Allí encontrará los diferentes Casos de uso en un formato elaborado por nosotros, a partir
de los hallazgos obtenidos de la consulta de diferentes autores y diferentes modelos para exponer la
información. Aunque el modelo del RUP es más sencillo, hemos preferido poder abordar los casos de uso en
su totalidad, analizando el mayor números de elementos. La primer hoja de este archivo presenta los
Requerimientos Funcionales y la última los correspondientes Diagramas de Casos de Uso del sistema de
software manejado.
Nota? Archivo adjunto en Excel “Casos de Uso Downtime”.. Fuentre “Los autores”.
2.3. PSEUDOCÓDIGOS.
RF0
Validar Doctor Permitir al Médico Operar el sistema
1
procedimiento Validar
Si (usuario registrado)
user <- "name"
pas <- "codXXX"
intentos <- 3
usu_def <- " "
pas_def <- " "
Repetir
intentos <- intentos - 1
Escribir "Username: "
leer usu_def
escribir "Password: "
leer pas_def
si pas_def <> pas y usu_def <> user Entonces
escribir "Usuario y/o contraseña incorrecta!"
escribir "Tienes ",intentos," intentos."
FinSi

Si usu_def = usuario y pas_def = pas entonces

Escribir "Acceso permitido, bienvenido " ,usuario, "."
Acepta
Abrir vPrincipal
FinSi

Hasta Que usu_def = usuario & pas_def = pas o intentos = 0

si intentos = 0 Entonces
escribir "Llegaste a tu limite de intentos."
FinSi

sino (usuario no registrado)

Registrar Persona
Abrir vRegistroDoctor
FinSi
fin procedimiento

RF0 Solicitar Enfermera Solicitar, por parte del médico, un enfermera para atender un
 2 paciente

RF0 Asignar una enfermera Como "Disponible" y cambiar estado a

Asignar Estado
3 "Ocupada" cuando su servicio es solicitado

Ingresar al sistema los datos de una enfermera, de un paciente

RF0
Registrar Persona o de un medico según el caso y almacenar dicha información
4
para posteriores consultas

RF0
Gestionar Turno Permitir el ingreso y liberación de enfermeras de un turno
5

Este algoritmo nos puede ser útil para crear la cola (sistema circular)

tipo Cola = registro

Cabeza, Final: 1..TamañoMáximo,
TamañoCola : 0..TamañoMáximo,
Lista : Arraylist [1..TamañoMáximo]
de TipoElemento
fin registro

procedimiento Crear ( e )
e.TamañoCola := 0;
e.CabezaCola := 1;
e.Final := TamañoMáximo
fin procedimiento

procedimiento incrementar ( x ) (* privado *)

si x = TamañoMáximo
entonces
x := 1 sino x := x + 1
fin procedimiento

procedimiento Insertar ( x, e )
si e.TamañoCola = TamañoMáximo
entonces
error “la lista está llena”,
sino
e.TamañoCola := e.TamañoCola + 1;
incrementar(e.Final);
e.Arraylist[e.Final] := x;
fin procedimiento

función ColaVacía ( e ) : test

devolver e.TamañoCola = 0
fin función

función QuitarCabeza ( e ) : TipoElemento si ColaVacía ( e ) entonces

error Cola vacía sino
e.TamañoCola := e.TamañoCola - 1;
x := e.Arraylist[C.CabezaCola];
incrementar(e.CabezaCola);
devolver x
fin función

función Buscar ( x, e ) : posición primer o null

p := eˆ.Sig;
mientras p <> null y pˆ.Elemento <> x hacer
p := pˆ.Sig;
devuelve p
fin función

función Primero ( e ) : TipoElemento

si ColaVacía ( e ) entonces error “La Lista está vacía”
sino
devolver Arraylist[e.CabezaCola]
fin función

función Ultimo ( p ) : test { privada }

devolver pˆ.Sig = null;
fin función

función Temporal ( x, e ) : posición primer

t := e.Sig;
mientras x <> null y t.Elemento <> x hacer
t := e.Sig - 1;
t = x;
devuelve x
fin función
RF0 Contar Tiempos de
Contabiliza los tiempos de los turnos de las enfermeras
6 Turnos

RF0 Consultar el tiempo que le queda a una enfermera en

Consultar Tiempos
7 particular, para terminar su turno o para ingresar al turno

Listar a las enfermeras (TODAS) que hay en el Hospicio,

RF0
Listar Turno indicando cuales estàn de turno para ser consultadas por los
8
doctores
 BIBLIOGRAFIA

- El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson. Addison Wesley

Iberoamericana, 1999.
- Object-Oriented Analysis and Design. G. Booch. Benjamin/Cummings, 1994.
- The UML Specification Document. G. Booch, I. Jacobson and J. Rumbaugh. Rational Software Corp.,
1997.
- Object-Oriented Software Engineering: A Use Case Driven Approach. I. Jacobson. Addison-Wesley,
1992.
- UML y Patrones. C. Larman. Prentice Hall, 1999.
- Object-Oriented Modeling and Design. J. Rumbaugh et al.Prentice- Hall,1991.
- UML Resource Center. Rational Software. http://www.rational.com/uml/
- UML Distilled, Martin Fowler, Pearson Addison-Wesley 2da. Edición
- El Lenguaje Unificado de Modelado, Booch, Rumbaugh, Jacobson, Pearson Addison-Wesley 1ra.
Edición.

LISTA DE REFERENCIAS CIBERGRÁFICAS

2015). Recuperado 28 Septiembre 2015, de
http://www.codecompiling.net/files/slides/UML_clase_02_UML_casos_de_uso.pdf
(2015). Recuperado 28 Septiembre 2015, de
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416
(2015). Recuperado 28 Septiembre 2015, de Docs.kde.org
(2015). Elementos de UML. Recuperado 28 Septiembre 2015, de
https://docs.kde.org/stable4/es/kdesdk/umbrello/uml-elements.html
Es.wikipedia.org,. (2015). Diagrama de casos de uso. Recuperado 28 Septiembre 2015, de
https://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso
Juntadeandalucia.es,. (2015). Guía para la redacción de casos de uso | Marco de Desarrollo de la
Junta de Andalucía. Recuperado 28 Septiembre 2015, de
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416
Maria, G., Maria, G., & perfil, V. (2011). INGENIERIA DEL SOFTWARE: EJEMPLOS DE CASOS DE USO.
Ingsoftwaremartin.blogspot.com.co. Recuperado 28 Septiembre 2015, de
http://ingsoftwaremartin.blogspot.com.co/2011/11/ejemplos-de-casos-de-uso.html
perfil, V. (2009). DISEÑO UML: PARA QUE SIRVE UN CASO DE USO. Carolmfguml.blogspot.com.co.
Recuperado 28 Septiembre 2015, de http://carolmfguml.blogspot.com.co/2009/04/para-que-sirve-un-
caso-de-uso_21.html
Sites.google.com,. (2015). Estructuración y Especificación de Casos de Uso - alfonsoperezr.
Recuperado 28 Septiembre 2015, de
https://sites.google.com/site/alfonsoperezr/investigacion/estructuracin-y-especificacin-de-casos-de-uos
Sites.google.com,. (2015). Estructuración y Especificación de Casos de Uso - alfonsoperezr.
Recuperado 28 Septiembre 2015, de
https://sites.google.com/site/alfonsoperezr/investigacion/estructuracin-y-especificacin-de-casos-de-uos
(2015). Cómo crear un diagrama de casos de uso. wikiHow. Recuperado 28 Septiembre 2015, de
http://es.wikihow.com/crear-un-diagrama-de-casos-de-uso