TALLER DE SISTEMAS DE CASO DE USOS DE EMPRESA

TALLER DE SISTEMAS DE CASO DE USOS DE EMPRESA

EJERCICIO Nª 1

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).

REQUERIMIENTOS

CASOS DE USO

aller DEPENDENCIAS/RELACIONES DE CASOS DE USOS

  DEPENDENCIAS/RELACIONES DE CASOS DE USOS 

INCLUSIONES 

Modelo de Casos de Uso - Relación Include

Esta es la tercera entrega de la serie modelo de casos de uso. Una vez más buscamos una unificación de conceptos que rodean a los casos de uso, en este caso queremos adentrar un poco en el concepto de relaciones de casos de uso, especificamente en este artículo trataremos la relación de inclusión (Include). Una relación de inclusión es aquella que conecta un caso de uso base a un caso de uso de inclusión. El caso de uso de inclusión siempre es abstracto. Describe un segmento del comportamiento que se inserta en una instancia de caso de uso que ejecuta el caso de uso base. El caso de uso base tiene control de la relación para la inclusión y puede depender del resultado de que se lleve a cabo la inclusión, pero ni la base ni la inclusión pueden acceder a los atributos entre sí. En este sentido, la inclusión está encapsulada y representa el comportamiento que se puede reutilizar en casos de uso base diferentes.

EXTENSIONES

En muchas ocasiones el uso de características avanzadas de los casos de uso generan dudas en los equipos de desarrollo. La razón básica es que estos modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el uso de las relaciones de inclusión y extensión, entre otras características.

Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad y sencillez, existen situaciones en que hacer uso de una relación avanzada entre casos de uso mejora en lugar de reducir, la claridad del modelo de requisitos. De ahí por tanto que todo analista de requisitos debe comprender perfectamente el significado de estas relaciones. En el presente post abordamos la relación de extensión <<extend>>.

taller PROCESOS DE NEGOCIOS

PROCESOS DE NEGOCIOS

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. Es, por ejemplo, el proceso a través del que una organización ofrece sus servicios a sus clientes.

Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de trabajo que efectúan las tareas de una organización. Los procesos poseen las siguientes características:

1.   Pueden ser medidos y están orientados al rendimiento

2.   Tienen resultados específicos

3.   Entregan resultados a clientes o “stakeholders”

4.   Responden a alguna acción o evento específico

5.   Las actividades deben agregar valor a las entradas del proceso.

Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Las dos formas principales de visualizar una organización, son la vista funcional y la vista de procesos.

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.

En los últimos años se viene observando una tendencia a gestionar de forma sistemática y centralizada las reglas de negocio, de modo que sea fácil y sencillo consultarlas, entenderlas, utilizarlas, cambiarlas, etc. Para ello se puede utilizar un motor de reglas de negocio. El motor de reglas de negocio es un sistema que se configura para dar servicio a las necesidades de negocio a través de la definición de objetos y reglas de negocio, el software se rige por flujos que derivan responsabilidades a los distintos cargos de la empresa repartiendo así el trabajo equitativamente y cuantitativamente, cuando, quien y donde tiene que desempeñar la tarea asignada.

taller Requerimientos

Requerimientos 

DEFINICIÓN

En la ingeniería de sistemas, un requisito (del inglés requirement: ‘requisito’) es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.

En la ingeniería clásica, los requisitos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen qué debe hacer el sistema, pero no cómo hacerlo.

La fase de captura, elicitación y registro de requisitos de requisitos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requisitos, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño 

Los Casos de Uso son requerimientos funcionales que describen

de  una  mane r a  de t a l l ada   e l   compor t ami ento de l   s i s t ema   con

l o s   d i s t i n t o s   A c t o r e s   q u e   i n t e r a c t ú a n   c o n   é l .

No   d e f i n e n   t o d o s   l o s   r e q u e r imi e n t o s   ( p o r   e j .   l o s   t i p o s   d e

da tos ,   int e r f a c e s   ext e rna s ,  ni v e l e s  de   r endimi ento  e spe r ado,

e t c . ) ,  pe ro  repre s ent an  e l  hi lo  conduc tor  que   v incul a   a   todos

l o s   r e q u e r imi e n t o s   p o s i b l e s   ( a c t u a l e s   y   f u t u ro s )   d e   u n a

a p l i c a c i ó n .

USO DE LOS DIAGRAMAS DE CASO DE USOS

Los diagramas de casos 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 comunicación con el cliente.

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso.

 Los personajes o entidades que participarán en un caso de uso se denominan actores.En el contexto deingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

EXPLICACIÓN DE HERRAMIENTAS PARA ANÁLISIS DISEÑO(STARUML)

Objetivo

Conocer una herramienta de modelado para la solución de problemas utilizando

programación orientada a objetos. 

• Conocer los diferentes tipos de diagramas para análisis y diseño básicos en UML 

• Utilizar una de las herramientas para elaborar diagramas UML

Introducción

¿Que es UML? El Lenguaje de Modelado Unificado (UML - Unified Modeling Language)

es un lenguaje gráfico de propósito general, estándar de la industria para visualizar,

especificar y documentar cada una de las partes que comprende el Desarrollo de

Sistemas a través del uso de diagramas y texto de soporte.

¿Para qué sirve?

• Visualizar como es un sistema o como queremos que sea.

• Especificar la estructura y/o comportamiento de un sistema.

• Hacer una plantilla que guíe la construcción de los sistemas

• Documentar las decisiones que hemos tomado

Para esta práctica usaremos los diagramas de casos de uso, diagramas de secuencia, y

los diagramas de clase.

Los diagramas de casos de uso y de secuencia, nos servirán para realizar el análisis

necesario para poder hacer un diseño basado en diagramas de clase.

Procedimiento

Iniciando StarUML.

Selecciona el icono de lanzamiento de la aplicación. Dado que un proyecto se puede

realizar siguiendo distintos enfoques, StarUML nos  pregunta cuál queremos utilizar. En

esta práctica utilizaremos el “Default Approach”.


TALLER DE SISTEMAS