Examen Parcial

HOTEL

El dueño de un hotel nos pide desarrollar un programa para consultar las habitaciones disponibles y poder reservar habitaciones en su hotel.
El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y dos tipos de clientes: habituales y esporádicos. Una reserva almacena datos del cliente, de la habitación reservada, la fecha de comienzo y el número de días que será ocupada la habitación.

El recepcionista del hotel debe poder hacer las siguientes operaciones:
a) Obtener un listado de las habitaciones disponible de acuerdo a su tipo.

b) Preguntar por el precio de una habitación de acuerdo a su tipo.

c) Preguntar por el descuento ofrecido a los clientes habituales.

d) Preguntar por el precio total para un cliente dado, especificando su número de reserva, tipo de habitación y número de noches.

e) Dibujar en pantalla la foto de una habitación de acuerdo a su tipo.

f) Reservar una habitación especificando el número de la pieza, reserva y nombre del cliente.

g) Eliminar una reserva especificando el número de la habitación.

El administrador puede usar el programa para:
a) Cambiar el precio de una habitación de acuerdo a su tipo.

b) Cambiar el valor del descuento ofrecido a los clientes habituales.

c) Calcular las ganancias que tendrán en un mes especificado (considere que todos los meses tienen treinta días).

Dependencias/Relaciones de Casos de Usos

LA RELACION INCLUDE ENTRE LOS CASOS DE USO
Como se establece en [17], una relación include entre dos Casos de Uso indica que el comportamientodefinido en el Caso de Uso a adicionar, es incluído en un lugar dentro de la secuencia del comportamientorealizado por una instancia del Caso de Uso base. Cuando una instancia del Caso de Uso«llega al lugar» donde el comportamiento de otro Caso de Uso debe ser incluído, ejecuta todo elcomportamiento descripto por el Caso de Uso incluído y luego continúa de acuerdo a su Caso de Usooriginal. El Caso de Uso incluído no depende del Caso de Uso base. En este sentido, el Caso de Uso incluído representa comportamiento encapsulado que puede ser reusado en varios Casos de Uso.

LA RELACION EXTEND ENTRE LOS CASOS DE USO

La relación extend establece que un Caso de Uso puede ser extendido con algún comportamientoadicional definido en otro Caso de Uso. La relación contiene una condición y referencia unasecuencia de puntos de extensión en el Caso de Uso base. Una vez que una instancia del Caso deUso ejecuta un comportamiento referenciado por el primer punto de extensión de la relación, lacondición es evaluada. Si se cumple, la secuencia de la instancia se extiende para incluir lasecuencia del Caso de Uso extensión. Las diferentes partes del Caso de Uso extensión soninsertadas en los lugares definidos por la secuencia de puntos de extensión de la relación: unaparten cada punto de extensión referenciado.

LA RELACION GENERALIZATION ENTRE LOS CASOS DE USO
Una relación de generalización entre Casos de Uso implica que el Caso de Uso hijo hereda todos losatributos, secuencias de comportamiento, puntos de extensión y relaciones definidos en el Caso deUso padre. El Caso de Uso hijo puede definir nuevas operaciones, como también redefinir o enriquecercon nuevas secuencias de acciones operaciones ya existentes en el Caso de Uso padre. Para distinguir si la especialización está redefiniendo una operación del padre o agregándole secuencias de acciones, sugerimos la inclusión de un estereotipo (elemento de UML) <<redefine>> para el primer caso o <<enrichment>> para el segundo, en la operación en cuestión.

Procesos de Negocios

DEFINICION DE PROCESOS DE NEGOCIO

Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado
 de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben
tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método,
 tendremos ciertas salidas resultantes. 
Es una colección de actividades estructurales relacionadas que producen un valor para la organización, sus
inversores o sus clientes. 

REGLAS DE NEGOCIO
Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las políticas, normas, operaciones, definiciones y restricciones presentes en una organización y que son de vital importancia para alcanzar los objetivos misionales.

Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000".

Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos.

Requerimientos

Requerimientos y Casos de Uso
Los Casos de Uso son requerimientos funcionales que describen de una manera detallada el comportamiento del sistema con los distintos Actores que interactúan con él.
No definen todos los requerimientos (por ej. los tipos de datos, interfaces externas, niveles de rendimiento esperado,etc.), pero representan el hilo conductor que vincula a todos los requerimientos posibles (actuales y futuros) de una aplicación.

Determinacion de los Requerimientos

La determinación de los requerimientos es el estudio del sistema actual del negocio a fin de encontrar como trabaja y donde debe mejorase. Los estudios del sistema son el resultado de una evaluación para conocer como funcionan los métodos actuales o si son necesarios o posibles  algunos ajustes; elaborar preguntas en relación con los sistemas manuales y los computarizados.

Dado que los analistas de sistemas no trabajan como gerentes o empleados en los departamentos para usuarios (como mercadotecnia, contabilidad, venta, compra o producción), no tienen los mismos conocimientos sobre hechos y datos que los gerentes y usuarios de esas áreas; por lo tanto un paso inicial en la investigación  es entender la situación.

Existen ciertos tipos de requerimientos tan fundamentales que son comunes a todas las situaciones. Contestar los grupos específicos de preguntas que analizan esta secciones, permitirá comprender estos requerimientos básicos.

Tecnicas de Recoleccion de Datos

TÉCNICAS DE RECOLECCION DE DATOS

Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.

LA ENTREVISTA 

Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.

Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevistas es un intercambio de información que se efectúa cara a cara.

Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.

LA ENCUESTA
Una "encuesta" recoge información de una "muestra." Una "muestra" es usualmente sólo una porción de la población bajo estudio.
El estándar de la industria para todas las organizaciones respetables que hacen encuestas es que los participantes individuales nunca puedan ser identificados al reportar los hallazgos. Todos los resultados de la encuesta deben presentarse en resúmenes completamente anónimos, tal como tablas y gráficas estadísticas. 

CUESTIONARIO
Los cuestionarios proporcionan una alternativa muy útil para la entrevista; si embargo, existen
ciertas características que pueden ser apropiada en algunas situaciones e inapropiadas en otra.Al igual que la entrevistas, deben diseñarse cuidadosamente para una máxima efectividad.

Cuestionario Abierto
Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito, es un medio.
El formato abierto proporciona una amplia oportunidad para quienes respondan escriba las razones de sus ideas. Algunas personas sin embargo, encuentran más fácil escoger una de un conjunto de respuestas preparadas que pensar por sí mismas.

Cuestionario Cerrado
El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma su opinión sobre los aspectos importantes.

LA OBSERVACIÓN
Otra técnica útil para el analista en su progreso de investigación, consiste en observar a las personas cuando efectúan su trabajo. Como técnica de investigación, la observación tiene amplia aceptación científica.
Los sociólogos, sicólogos e ingenieros industriales utilizan extensamente ésta técnica con el fin de estudiar a las personas en sus actividades de grupo y como miembros de la organización. El propósito de la organización es múltiple: permite al analista determinar que se está haciendo, como se está haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, dónde se hace y por que se hace.

Tipos de Observación
El analista de sistemas puede observar de tres maneras básicas. Primero, puede observar a una persona o actitud sin que el observado se dé cuenta y su interacción por aparte del propio analista. Quizá esta alternativa tenga poca importancia para el análisis de sistemas, puesto que resulta casi imposible reunir las condiciones necesarias. Segundo, el analista puede observar una operación sin intervenir para nada, pero estando la persona observada enteramente consciente de la observación. Por último, puede observar y a la vez estar en contacto con las personas observas. La interacción puede consistir simplemente en
preguntar respecto a una tarea específica, pedir una explicación, etc.

DICCIONARIO DE DATOS
Un diccionario de datos es una lista de todos los elementos incluido en el conjunto de los diagramas de flujo de datos que describen un sistema. Los elementos principales en un sistema, estudiados en las secciones anteriores, son el flujo de datos, el almacenamiento de datos y los procesos. El diccionario de datos almacena detalles y descripciones de estos elementos.

Diagramas de Caso de Uso

DIAGRAMAS DE CASOS DE USO
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo 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.

Componentes de un Diagrama de Casos de Uso

ACTORES
Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.


ASOCIACIONES DE CASO DE USO

*Comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso. 

*Usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro. 

*Extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas).

EJEMPLO DE DIAGRAMA DE CASOS DE USO

Modelo de Ciclo de Vida

MODELO CASCADAEl modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

MODELO V
El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.