TALLER DE SISTEMAS DE CASO DE UNOS DE EMPRESA





Taller de documentación de

Requisitos - Casos de uso

Empresa de transportes

1. Enunciado

Una empresa de transporte de mercancías por carretera tiene a su disposición

una flota propia de camiones y una serie de conductores particulares que tienen camión

propio. Cada camión tiene una fecha de alta como vehículo, una matrícula y un peso

máximo que puede transportar.

Cada conductor particular puede tener en su propiedad varios camiones, y tiene

su propia tarifa de precio por kilo y kilómetro. Los camiones correspondientes a la flota

de la empresa se asignan dinámicamente a los conductores que ésta tiene en nómina, y

tienen todos la misma tarifa que es estipulada por la propia empresa. Cada conductor,

por tanto, puede estar trabajando por cuenta propia o por cuenta ajena. De los mismos se

guardará además, nombre, apellidos, DNI, dirección, provincia, población y teléfono.

Todo conductor (particular o contratado) tiene un código único asignado

automáticamente por el sistema.

La empresa opera sobre un conjunto de ciudades las cuales están enlazadas por

carretera entre sí. El sistema de información conocerá el número de kilómetros entre

cada ciudad que está unida directamente por carretera y el tiempo medio que se tarda en

recorrer dicho tramo. Cada carretera se identifica a través de un número de carretera

único introducido por el operador. La empresa puede tener en estas ciudades un parque

donde almacenar remolques cargados o descargados. Cada remolque tiene una

matrícula, un peso y, caso de estar cargado, un peso de la carga.

A la empresa llegan pedidos. Un pedido consta de un número, una fecha, CIF del

cliente y varias líneas de pedido. Cada línea consiste en un remolque, el volumen de la

carga en kilos, la ciudad de partida, la ciudad de destino, la fecha de partida y la de

destino.

Existe una tabla de movimientos de caja con los campos fecha, importe, un

campo lógico que indique si es un pago o un ingreso, y un identificador del pedido si

fuera un ingreso, o del conductor pagado, si fuera un pago.

2. Diagramas de caso de uso



Figura 1. Diagrama de casos de uso del sistema







Figura 2. Diagrama de casos de uso del subsistema de camiones









Figura 3. Diagrama de casos de uso del subsistema de conductores









Figura 4. Diagrama de casos de uso del subsistema de gestión de caja








Figura 5. Diagrama de casos de uso del subsistema de gestión de remolques

Figura 6. Diagrama de casos de uso del subsistema de gestión de trayectos

Figura 7. Diagrama de casos de uso del subsistema de pedidos

Figura 8. Diagrama de casos de uso del subsistema de rutas



DEPENDENCIAS/RELACIONES DE CASOS DE USOS

DEPENDENCIAS/RELACIONES DE CASOS DE USOS

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

Técnicamente como para el glosario, la relación de extensión <<extend>> se define como:

Relación <<extend>> Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relación que apunta del caso extendido al caso base y la conexión se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensión que este haya definido.

La notación gráfica es la siguiente:





Fig. 1 - Relación de extensión <<extend>>





La relación del ejemplo significa que un caso de uso ya existente (el caso “A”) se aprovecha en la definición de un segundo caso (el caso “B”). Dado que la reutilización que requerimos agrega funcionalidad pero no altera al caso base, se ha optado por la relación de extensión. Dicha relación se ha denotado gráficamente con una flecha de dependencia desde el caso extendido (el caso “B”) al caso base (el caso “A”). La dependencia la hemos estereotipado con <<extend>> para que quede claro lo que pretendemos decir.

A nivel de los flujos de eventos, se podría decir que el flujo principal del caso base no se ve alterado, pero que en cambio, el flujo de eventos del caso extendido hace referencia al primero, de manera tal que no puede ser entendido en ausencia de los pasos del caso base.

A fin de contar con un ejemplo completo, consideremos un sistema de compras electrónico. Digamos que este sistema va a atender tanto a clientes finales como a clientes corporativos, permitiendo que adquieran productos en nuestra tienda en línea. La diferencia será que los clientes corporativos hacen compras masivas, quizás programando la entrega a lo largo de un periodo de tiempo de lo que compraron. Esta visión la podemos expresar en el siguiente diagrama:



Fig. 2 – Ejemplo de relación <<extend>> en un sistema
de tienda electrónica en Internet



Ahora si vamos al caso de uso base “Compra artículo (UC-0100)” podríamos tener la funcionalidad de escoger el artículo a comprar y el de pagar con tarjeta de crédito, por ejemplo. Esta funcionalidad esta disponible a los clientes finales, tal como se ve en el diagrama.

Por su parte, los clientes corporativos pueden escoger el artículo a comprar y el modo de pago: digamos tarjetas de crédito. Además el caso de uso captura también la funcionalidad de programar la entrega parcial de lo comprado a lo largo de un periodo de tiempo. Dado que gran parte del caso de uso “Compra masiva (UC-0200)” es idéntica a la encontrada en el caso del cliente final, optamos por reutilizar la especificación por vía de la relación de extensión.

Los criterios a aplicar para saber si la relación de extensión es aplicable son los siguientes:

1. Hay cuando menos un caso base y un caso extendido.
2. El caso base no se ve modificado por la existencia del caso extendido.
3. El caso base es un caso concreto atado a cuando menos un actor.
4. El caso extendido incorpora al caso base por completo.

La relación de extensión guarda relación con todos los restantes tipos de reutilización que están definidas para los casos de uso; en particular la relación es muy intima con la relación de inclusión <<include>> sin embargo la diferencia primordial entre <<extend>> e <<include>> es la modificación del caso base. Extensión no implica cambio, en tanto que la inclusión añade funcionalidad al caso base.

Otra relación, la herencia, es similar también a la extensión. En este caso la diferencia es que la herencia cambia o puede cambiar, la naturaleza de lo dicho en el caso base. Por ejemplo, podemos decir que aquello que fue llamado “artículo” en el caso base es ahora referido más detalladamente como “libro” o “juguete”. La herencia de casos de uso reutiliza al caso base sí, pero nos permite alterar la semántica de los detalles; algo que la relación de extensión (ni la de inclusión) pueden hacer.

Por tanto concluyamos: la relación de extensión permite reutilizar una especificación pero sin modificar al caso base.

UML

EJEMPLOS DE (UML)

 

EJEMPLO DE BANCO

EJEMPLO DE UNA BIBLIOTECA

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:

-Pueden ser medidos y están orientados al rendimiento

-Tienen resultados específicos

-Entregan resultados a clientes o “stakeholders”

-Responden a alguna acción o evento específico

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

Definiciones

La norma internacional ISO-9001 define un proceso como “una actividad que utiliza recursos, y que se gestiona con el fin de permitir que los elementos de entrada se transformen en resultados” (ISO, 2000; pp. 6). Oscar Barros hace una importante distinción, al introducir el concepto de valor agregado en la definición de proceso, señalando que “un proceso es un conjunto de tareas lógicamente relacionadas que existen para conseguir un resultado bien definido dentro de un negocio; por lo tanto, toman una entrada y le agregan valor para producir una salida. Los procesos tienen entonces clientes que pueden ser internos o externos, los cuales reciben a la salida, lo que puede ser un producto físico o un servicio. Éstos establecen las condiciones de satisfacción o declaran que el producto o servicio es aceptable o no” (Barros, 1994; pp.56).

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.

Requerimientos

Determinación de 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.

Uso de los diagramas de caso de usos

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 de ingenierí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

Objetivo

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

pragramació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

¿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 que 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.

TÉCNICAS DE RECOLECCIÓN DE DATOS

INTRODUCCIÓN

La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos.
Todas estos instrumentos se aplicará en un momento en particular, con la finalidad de buscar información que será útil a una investigación en común. En la presente investigación trata con detalle los pasos que se debe seguir en el proceso de recolección de datos, con las técnicas ya antes nombradas.

TÉCNICAS PARA HALLAR 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.

¿Qué es una encuesta?

Se ha dicho que Estados Unidos ya no es una "sociedad industrial", sino una "sociedad de información". Esto es, nuestros mayores problemas y tareas ya no giran principalmente en la producción de bienes y servicios necesarios para nuestra supervivencia y comodidad
Hoy en día la palabra "encuesta" se usa más frecuentemente para describir un método de obtener información de una muestra de individuos. Esta "muestra" es usualmente sólo una fracción de la población bajo estudio.

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.

Diccionario de datos

Los diccionarios de datos son el segundo componente del análisis del flujo de datos. En sí mismos los diagramas de flujo de datos no describen por completo el objeto de la investigación. El diccionario de datos proporciona información adicional sobre el sistema. Esta sección analiza que es un diccionario de datos, por qué se necesita en el análisis de flujo de datos y como desarrollarlo. Se utilizará el ejemplo del sistema de contabilidad para describir los diccionarios 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.

Descripción de los Datos en el Diccionario

Cada entrada en el diccionario de dato consiste en un conjunto de detalles que describen los datos utilizados o producidos en el sistema. Cada articulo se identifica por un nombre de dato, descripción, sinónimo y longitud de campo y tiene valores específicos que se permiten para éste en el sistema estudiado.

Nombre de los Datos

Para distinguir un dato de otro, los analista les asigna nombre significativos que se utilizan para tener una referencia de cada elemento a través del proceso total de desarrollo de sistemas. Por lo tanto, debe tenerse cuidado para seleccionar, en forma significativa y entendible, los nombres de los datos, por ejemplo la fecha de factura es más significativa si se llama FECHA FACTURA que si se le conoce como ABCXXX.

Descripción de los Datos

Establece brevemente lo que representa el dato en el sistema; por ejemplo, la descripción para FECHA-DE-FACTURA indica que es la fecha en la cual se está preparando la misma (para distinguirla de la fecha en la que se envió por correo o se recibió.
Las descripciones de datos se deben escribir suponiendo que a gente que los lea no conoce nada en relación del sistema. Deben evitarse termino especiales o argot, todas las palabras deben se entendible para el lector

Diagramas de Casos de Uso

Diagramas de Casos de Uso

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.

Definición y Usos

Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.

Un Uso-Caso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interactúa con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo".

Un Uso-Caso es empleado con más frecuencia en alguna de las siguientes etapas :

• Determinación de Requerimientos: Por lo general nuevos requerimientos de sistema generan nuevos usos-casos, conforme es analizado y diseñado el sistema.
• Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto.
• Generación de pruebas de Sistemas: A través de los diagramas uso-caso se pueden generar una serie de pruebas de sistema.

En la siguiente sección se describen los diversos elementos que componen un diagrama Uso-Caso.