Modelo del negocio.

MODELAMIENTO DEL NEGOCIO Sumario 1. Modelamiento del negocio. 2. Modelo de casos de uso del negocio.
2.1Diagrama de casos de uso del negocio.

2.2
3.1

Estructuracin de los casos de uso del negocio.

Descripcin textual.

3. Realizacin de los casos de uso del negocio. 3.2 3.3 Diagrama de actividades. Diagrama de clases.

4. Reglas de negocio. Objetivos

Que los estudiantes:

Conozcan el flujo de trabajo que se realiza como parte del modelamiento del negocio, los trabajadores que participan y los artefactos que se elaboran. Conozcan el vocabulario, las reglas y las construcciones especficas de UML que se emplean en la elaboracin de los diagramas de casos de uso del negocio, actividad y de clase del modelo de objetos. Conozcan los elementos que se tienen en cuenta cuando se describe un proceso de negocio. Conozcan las bases para identificar actores, trabajadores, actividades, procesos, entidades y reglas del negocio asociados al campo de accin que se negocio que se modela. Adquieran habilidades en la identificacin de actores, trabajadores, actividades, procesos, entidades y reglas de negocio; en la modelacin del mismo utilizando los diagramas de casos de uso, de actividades y del diagrama de clases del modelo de objetos y describiendo textualmente los procesos de negocio y de las reglas del negocio que hay que tomar en cuenta.

Indicaciones metodolgicas
Es una clase de 4 horas, subdividida en 2 actividades, separadas en el tiempo, de 2 horas cada una. En las primeras dos horas el profesor har una exposicin sobre el tema en la que

abordar los principales conceptos y ejemplificar cada uno. Para ello cuenta con una presentacin en PowerPoint y la pizarra.

Las dos ltimas horas pretenden que el estudiante adquiera habilidades en el modelamiento de un negocio. Para ello se propone que se utilice como referencia el proyecto que estn desarrollando para la presentacin de su tesis. El profesor asesorar este trabajo y har las aclaraciones y explicaciones grupales que considere pertinentes de acuerdo al trabajo que desarrollen los estudiantes. Es necesario que los estudiantes se preparen para esta actividad llevando la propuesta de modelamiento de negocio, lo que harn en horario extraclase. Adems de la bibliografa dela clase, se pondr a disposicin de los estudiantes un caso de estudio (Galera de arte Arte peruano) resuelto completamente hasta el alcance de la clase. Bibliografa Rational Unified Process. Jacobson, I.; Booch, G. y Rumbaugh, J.; El Proceso Unificado de Desarrollo de software. 2000. Addison-Wesley. Pginas 115-119. Booch, G.: Rumbaugh, J. y Jacobson, I.; El Lenguaje Unificado de Modelado. 2000. Addison-Wesley. Pginas 197-201, 225-239. Rumbaugh, J.; Jacobson, I. y Booch, G.; El Lenguaje Unificado de Modelado. Manual de referencia. 2000. Addison-Wesley. Pginas 120-121, 157-162, 305-312. Von Hallen, B.; Building a Business http://www.Kpiusa.com/ReadingRoom /ReadingRoom.htm . Rules.

Aguall,P.; Desarrollo Cliente / servidor: ubicacin de las reglas de negocio. http://www.ctv.es /USERS/pagullo /arti/esbr/esbr.htm . Falo, H. y Fontes, J.; En quin se pone el foco?. Identificando stakeholders para la formulacin de la misin organizacional. Revista del CLAD Reforma y Democracia. No. 15 (Octubre 1999). Caracas. Anlisis de las partes interesadas.Http://wbln0018.wordbank.org/caribbean/CaribbeanCMUOL.nsf/ FILE/Db-an-pi.doc . Gonzlez, E.; La empresa ante sus grupos de intereses: Una aproximacin desde la literatura del anlisis de los stakeholders. Papeles de tica y Direccin, No. 4, 1999.

Introduccin

Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema informtico1(Figura 1). Un proceso define quin est haciendo qu, cundo y cmo alcanzar un determinado objetivo.

Requisitos del usuario

Sistema informtico

Figura 1 Proceso de Desarrollo de Software. Definicin. El Proceso Unificado de Desarrollo (RUP) propone un esquema iterativo y funcional que se estructura en una forma bidimensional, tal como se muestra en la figura 2. En el eje vertical estn las distintas etapas del desarrollo en cascada (flujos de trabajo), y e el eje horizontal la evolucin en el tiempo, que se da en 4 fases.

Figura 2 Flujos de trabajo y fases que propone RUP2. Obtener los requisitos funcionales que se derivarn en un producto de software nuevo o la mejora de uno existente, requiere de un estudio de la organizacin. Este estudio est contemplado dentro del flujo de trabajo de Modelamiento del negocio, desarrollndose la mayora de sus actividades dentro de la fase de Concepcin (o Inicio).

Jacobson, I.; Booch, G. y Rumbaugh, J.; El Proceso Unificado de Desarrollo de software. 2000. Addison-Wesley. Pgina 4. 2 Tomado de Rational Unified Process.

La fase de Concepcin tiene por finalidad definir la visin, los objetivos y alcance del proyecto; obtenindose como resultado los requerimientos del sistema que satisfacen las necesidades de la organizacin.

Reglas de negocio. Las reglas de negocio describen polticas que deben cumplirse o condiciones que deben satisfacerse, por lo que regulan algn aspecto del negocio. El proceso de especificacin implica que hay que identificarlas dentro del negocio, evaluar si son relevantes dentro del campo de accin que se est modelando e implementarlas en la propuesta de solucin. Son mltiples las clasificaciones que se dan a las reglas de negocio. Sin pretender hacer un tratado sobre el tema, podra asumirse la siguiente clasificacin:
1. Reglas de estructura Trmino: Conceptos

en el contexto del negocio. Ejemplo: Estudiante, Libro Modelo de datos: Controla que la informacin bsica almacenada para cada atributo o propiedad de un concepto es vlida. Ejemplo: La cantidad de libros de un mismo ttulo es mayor que cero.

Relacin: Controla las relaciones entre los datos. Ejemplo: El estudiante solicita un libro. A la asociacin entre el libro y el estudiante se le denomina Prstamo.

2. Reglas de derivacin Inferencia: Especifican que un hecho es cierto por inferencia. Ejemplo: Un estudiante que debe un prstamo de un libro se convierte en un estudiante moroso.

Clculo: Controla la obtencin de informacin que se puede calcular a partir de la ya existente. Ejemplo: La cantidad de libros que un estudiante tiene en prstamo es la suma de los prstamos en los que est involucrado.

3. Reglas de accin Flujo: Determinan y limitan cmo fluye la informacin a travs de un sistema. Ejemplo: Un estudiante solicita un libro en prstamo en una biblioteca, el personal que lo atiende verifica si es un

estudiante moroso. En caso negativo, el personal procede a registrar el prstamo y le entrega el libro. Si no es posible, se le informa y recoge el libro para colocarlo en su estante. Restricciones de operaciones: Especifican condiciones que deben ser ciertas para asegurarse que una operacin se ejecute correctamente. Ejemplo: A un estudiante no se le puede prestar otro libro si est clasificado como moroso.

Estmulo y respuesta: Restringen el comportamiento especificando cundo y qu condiciones deben cumplirse para que una operacin de respuesta sea inmediatamente ejecutada. Ejemplo: Si se ha llegado a la fecha en que un estudiante debe entregar un libro y no lo ha hecho, se procede a enviarle un e-mail.

La descripcin que se hace de las reglas de negocio es independiente de su implementacin y puede expresarse en espaol estructurado, diagramas o descripciones textuales. No es importante que durante el proceso de identificacin se clasifiquen siguiendo los criterios anteriores u otros criterios; lo necesario es que queden formuladas en algn lenguaje. Un algoritmo que puede ayudarnos es realizar el anlisis, para cada caso de uso de negocio, siguiendo el orden que se muestra en la figura 23.

Describir el flujo de trabajo Determinar relacin con otros sistemas dispositivos

Encontrar entidades que participan en el flujo de trabajo

Definir interaccin de los usuarios con el flujo de trabajo

Especificar restricciones sobre los datos y la ejecucin del flujo de trabajo

Figura 23 Algoritmo para obtener las reglas de negocio asociadas a un proceso de negocio.

1. Modelamiento del negocio Un sistema, por pequeo que sea, generalmente es complicado. Por eso se necesita dividirlo en piezas si se pretende comprenderlo y gestionar su complejidad. Esas piezas se pueden representar a travs de modelos que permitan abstraer sus caractersticas esenciales. De ah, que en el campo del software tambin resulte til la creacin de modelos que organicen y presenten los detalles importantes de problemas reales que se vinculan con el sistema informtico a construir. Estos modelos deben cumplir una serie de propiedades, entre ellas la de ser coherentes y relacionados. Uno de los modelos tiles previo al desarrollo de un software es el modelo del negocio.
El modelado del negocio es una tcnica para comprender los procesos del negocio de la organizacin. Los propsitos que se persiguen al realizarse el modelado del negocio, son:

Entender la estructura y la dinmica de la organizacin. Entender los problemas actuales e identificar mejoras potenciales. Asegurarse de que los clientes, usuarios finales y desarrolladores tienen una idea comn de la organizacin. Derivar los requerimientos del sistema a partir del modelo de negocio que se obtenga. Para alcanzar estos objetivos, el workflow de la modelacin del negocio, describe cmo desarrollar la visin de la nueva organizacin que se pretende alcanzar, y sobre la base de esta visin, definir los procesos, roles y responsabilidades de esa organizacin en el modelo de casos de uso del negocio y el modelo de objetos del negocio. El flujo de trabajo, de acuerdo a RUP, se desarrolla segn se indica en la figura 3.

Describir negocio actual de manera resumida

Evaluacin del negocio se necesita modela completamente el negocio? [S] [No ] Identificar procesos de negocio Refinar procesos de negocio Disear realizaciones del proceso de negocio Refinar roles y responsabilidades Explorar automatizacin de procesos de Negocio Desarrollar un modelo del dominio

Figura 3 Flujo de trabajo para el modelamiento del negocio segn RUP. Evaluacin del estado del Negocio consiste en bsicamente en evaluar el estado actual de la organizacin en la cual el sistema ser explotado. Dependiendo de la situacin o escenario que se presente, hay varias alternativas de desarrollar este proceso: Si se determina que no es necesario un modelo completo del negocio se realizar lo que se conoce como un modelamiento del dominio.
Un modelo del dominio captura los tipos ms importantes de objetos que existen o los eventos que suceden en el entorno donde estar el sistema.

El modelo del dominio se considera en RUP un subconjunto del llamado modelo de objetos del negocio. Ms adelante se hablar de ese modelo. Se puede desarrollar un modelo de objetos del negocio enfocado a la explicacin de los productos, entregables o eventos que son importantes en el negocio. Esos modelos, que no incluyen las responsabilidades de las personas que ejecutan las actividades, se refieren a veces como modelo del dominio). Si se determina que no habrn cambios importantes en los procesos de negocio, se necesitarn describir esos procesos y derivar los requerimientos del sistema de informacin. Es decir, si los procesos estn claramente definidos y no se van a introducir cambios entonces solo es necesario modelar el negocio propuesto. En este escenario basta con conocer el mapa de la organizacin y los procesos para comprender mejor los requerimientos de la aplicacin a construir. En este caso no se pretende cambiar la organizacin, aunque en realidad la implantacin del sistema siempre incluye algn nivel de mejora del negocio. Si se realiza el modelamiento con la intencin de lograr una reingeniera del negocio existente, se debera modelar tanto el negocio actual como el

nuevo negocio (Por ejemplo, de una subasta pblica a una subasta en Internet, de ventas directas en una tienda a una tienda virtual). La descripcin del negocio actual consiste en entender los procesos y la estructura de la organizacin (sin entrar en detalles), identificando claramente los objetivos estratgicos de la organizacin y los procesos que los soportan, el flujo actual de los procesos involucrados en el campo de accin, el anlisis crtico de cmo se ejecutan esos procesos y el anlisis comparativo con otras soluciones presentes en el mercado. La descripcin del negocio propuesto en detalle tendr entre sus actividades principales la identificacin de los procesos de negocio, delimitacin el modelo de casos de uso del negocio, la estructuracin y la especificacin de los casos de uso del negocio, la identificacin de trabajadores y entidades del negocio que ejecutan las realizaciones de los casos de uso del negocio y detallar la definicin de las entidades del negocio y las responsabilidades de los trabajadores del negocio. La exploracin de la automatizacin del proceso de negocio significa explorar qu partes del negocio pueden y deben ser automatizadas. Esto implicar la especificacin de los requerimientos del software y la elaboracin del modelo de casos de uso del sistema en una primera aproximacin. Estos tres grupos de actividades se pueden desarrollar en paralelo. En cualquier caso, hasta que todas las actividades no estn concluidas, no culmina el modelamiento del negocio. En resumen, el objetivo del modelo del negocio es describir los procesos, existentes u observados, con el propsito de comprenderlos. Se especifican aqu qu procesos del negocio sorportar el sistema. Adems de identificar los objetos del dominio o del negocio implicados, este modelo establece las competencias que se requieren de cada proceso: sus trabajadores, sus responsabilidades y las operaciones que llevan a cabo. El flujo de trabajo de la modelacin del negocio est relacionado con otros flujos de trabajo: El workflow de Requerimientos hace uso de los modelos del negocio como una importante entrada para lograr la comprensin de los requerimientos del sistema. El workflow de Anlisis y Diseo hace uso de las entidades del negocio como una entrada el proceso de identificacin de las clases entidades en el modelo de diseo. Los trabajadores del negocio que intervienen en la realizacin de estas actividades son: Analista de procesos de negocio: Responsable de la arquitectura del negocio por lo que dirige y coordina el proceso de modelamiento del negocio. Decide cules son actores y los procesos del negocio y las relaciones entre ellos y cules son las reglas de negocio a tener en cuenta. Diseador del negocio: Describe los procesos de negocio y como parte de la realizacin de estos procesos identifica a las entidades y

trabajadores del negocio y sus relaciones. Define cules son los requerimientos en la automatizacin. Stakeholders: Personas u organizaciones que estn activamente implicadas en el negocio ya sea porque participan en l o porque sus intereses se ven afectados con los resultados del proyecto. Pueden ser los propietarios, la direccin, quienes financian, los clientes, los trabajadores, los proveedores, la competencia, la comunidad local, etc. Revisor del modelo de negocio: Revisa formalmente el modelo de casos de uso del negocio y de objetos de negocio obtenido.

Los principales artefactos que se obtienen como resultado del modelamiento del negocio son: Modelo de casos de uso del negocio: Describe los procesos de negocio de una empresa en trminos de casos de uso y actores del negocio, que se corresponden con los procesos del negocio y los clientes, respectivamente. Modelo de objetos del negocio: Es un modelo de objetos que describe cmo colaboran los trabajadores y las entidades del negocio dentro del flujo de trabajo del proceso de negocio. Especificaciones complementarias del negocio: Otras descripciones contenidas en documentos u obtenidas por otras vas; que permitan un mayor entendimiento del negocio y que contribuyan a su modelamiento. Glosario de trminos: Lista de concepto asociados al negocio que son comnmente usados y que deben ser del dominio del equipo de desarrollo para pode modelar el negocio y dar una solucin a la problemtica encontrada.

2. Modelamiento de casos de uso del negocio El modelo del negocio describe el negocio en trminos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos.
El modelo de Casos de Uso del Negocio es un modelo que describe los procesos de un negocio (casos de uso del negocio) y su interaccin con elementos externos (actores), tales como socios y clientes, es decir, describe las funciones que el negocio pretende realizar y su objetivo bsico es describir cmo el negocio es utilizado por sus clientes y socios.

Actor del Negocio

Caso de Uso del Negocio

Figura 4 Estereotipos usados en el modelo de casos de uso del negocio. El modelo de caso de uso del negocio implicar la determinacin de los actores y casos de uso del negocio. Con esta actividad se pretende:

Identificar los procesos en el negocio. Definir las fronteras del negocio que van a modelarse. Definir quin y qu interacturn con el negocio. Crear diagramas del modelo de casos de uso del negocio.

Actores del negocio: Un actor del negocio es cualquier individuo, grupo, entidad, organizacin, mquina o sistema de informacin externos; con los que el negocio interacta. Lo que se modela como actor es el rol que se juega cuando se interata con el negocio para beneficiarse de sus resultados. Son actores candidatos del negocio: Socios Proveedores Autoridades (legales, reguladoras, etc.) Propietarios sin no estn dentro del negocio que se modela. Sistemas de informacin externos al negocio. Otras partes del negocio si este es grande y esas partes no estn dentro del campo de accin del negocio que se modela.

Para cada actor del negocio que se identifica se debe escribir una breve descripcin que incluya sus responsabilidades y por qu interacta con el negocio. Casos de uso del negocio: Un proceso de negocio es un grupo de tareas relacionadas lgicamente que se llevan a cabo en una determinada secuencia y manera y que emplean los recursos de la organizacin para dar resultados en apopo a sus objetivos. Un caso de uso del negocio representa a un proceso de negocio, por lo que se corresponde con una secuencia de acciones que producen un resultado observable para ciertos actores del negocio. Desde la perspectiva de un actor

individual, define un flujo de trabajo completo que produce resultados deseables. Para identificar los procesos de negocio es muy importante tener en cuenta que deben generar un valor para el negocio o mitigar los costos del negocio. Para encontrar casos de uso del negocio se pueden clasificar los procesos de negocio en tres categoras: Ncleo: Considere qu valor reciben los actores del negocio primarios y ms importantes: los clientes. Busque los procesos del negocio respondiendo a la pregunta: cules son los servicios bsicos que un cliente recibe del negocio?. Soporte: Contiene las actividades que no benefician al cliente directamente. Para identificarlos se pueden buscar actividades como las siguientes: desarrollo y mantenimiento de personal, de las tecnologas de informacin y de la oficina, seguridad y actividades legales. Gerencial: Estos procesos se encuentran bucando los procesos que tienen que ver con el manejo del negocio en su coonjunto. Normalmente se relacionan con el actor propietario. Busque actividades como la siguientes. Desarrollar y poporcionar informacin sobre el negocio a los dueo e inversionistas, preparar las metas del presupuesto a largo plazo, etc.

Clasificar un proceso en alguna de estas categoras dependen del campo de accin que se est modelando por que, por ejemplo, si el campo de accin involucra la Gestin de Recursos Humanos, puede que los procesos de desarrollo y mantenimiento del personal sean del ncleo y no de soporte. En definitiva lo importante no es clasificar los procesos sino tener una gua para orientarse. En la figura 5 se muestra un ejemplo asociado con la prestacin de servicios en un restaurante, en el que se han identificado los tres tipos de procesos.

Cliente

Client e

Comprar suministros

p ot

Marketing

Experto en relaciones pblicas

nc ial

Servicio de comida

Proveedor Figura 5 Ejemplo de los tipos de procesos. Otra manera de encontrar los casos de uso del negocio es que los expertos del dominio describan cada actividad en el negocio existente, y entonces se agrupan estas actividades en procesos de negocio. Esta forma de identificacin est asociada con el concepto de funcin (un grupo funcional que responde a un objetivo de la organizacin y que puede involucrar a varias reas). Para una empresa cualquiera productora, podrn definirse las funciones y procesos que se decriben en la tabla 1. Tabla 1 Ejemplo de funciones y procesos de negocio. Funcin Distribuci n Compras Procesos de negocio Recepcin Embarque Tranportacin Inventarios Eleccin de proveedore Pago a proveedores Despacho Cubrimiento de plantilla Capacitacin Beneficios Pago a trabajadores Presupuesto Costos

Personal

Finanzas

Otro punto de partida partida para definir los procesos de negocio pueden ser los objetivos estratgicos de la organizacin. Dado que estos pueden ser de mucha abstraccin, cada uno suele descomponerse en subobjetivos mapas concretos. Para cada subobjetivo no descompuesto se pudiera asignar un proceso de negocio que est asociado a un caso de uso del negocio. Por ejemplo, una empresa de servicios puede tener como un objetivo estratpegico Satisfacer pedidos de un cliente. Este puede subdividirse , entre otros, en: Atender pedidos de clientes y Solicitar insumos a proveedores. Estos objetivos pueden servir de base para los procesos de negocio de la figura 6.

Cliente

Atender pedido

Proveedor

Comprar suministros

Figura 6 Ejemplo de procesos de negocio derivados de los objetivos estrgicos de la organizacin. El nombre de un caso de uso del negocio debe expresar qu sucede cuando la instancia del caso de uso sea ejecutada. Por tanto debe ser nombrado en forma activa, comnmente en gerundo (Por ejemplo, Chequeo de equipaje, Compra de suministros) o un verbo (Por ejemplo, Chequear equipaje, Comprar suministros).
Algunas consideraciones acerca de actores del negocio Todo lo que interacciona con el ambiente del negocio se modela con actores.

Cada actor humano expresa un rol, no una persona especfica. Cada actor modela algo fuera del negocio.

Cada actor se involucra con un caso de uso, al menos como regla. Cada actor tiene una descripcin y un nombre que explica su rol en relacin al negocio.
Su nombre y descripcin breve son claras y fciles de comprender, incluso para personas externas al equipo que modela el negocio.

Algunas consideraciones acerca de los casos del uso del negocio

Cada caso de uso del negocio es completo desde la perspectiva de un actor externo. Por ejemplo, el caso de uso Manejar Reclamos en una compaa de seguros comienza cuando el cliente hace un reclamo. El caso de uso del negocio Manejar Reclamos no es completo a menos que incluya acerca de la decisin de la compaa de seguros con respecto al cliente y del pago por compensacin, de ser apropiado. Cada caso de uso del negocio normalmente se involucra con, al menos, un actor. Los casos de uso del negocio se inician por actores, interacta con actores para realizar las actividades y enva resultados. Es posible que un caso de uso de apoyo no interacte con ningn actor. Esto es cierto si el caso de uso del negocio se inicia por evento interno y no tiene que interactuar con un actor para realizar las actividades.

2.1 Diagrana de casos de uso del negocio. Un diagrama de casos de uso del negocio representa grficamente a los procesos del negocio y su interaccin con los actores del negocio. En la figura 7 se muestra cmo quedara el diagrama para el ejemplo del restaurante visto anteriormente.

Cliente potencial

Marketing

Gerente de Relaciones Pblicas

Comprar Proveedor Figura 7 Ejemplo de Diagrama de casos de uso del negocio. Servicio de comida suministros Cli ente
Se pueden agrupar casos de uso del negocio para particionar el diagrama en subdiagramas ms pequeos; de manera que se definiran paquetes y estos a su vez

podran relacionarse entre s. Un paquete ( estereotipo: ) es un mecanismo de prposito general para organizar en grupos los elementos.

Los criterios para agrupar podran ser los siguientes:

Casos de uso de negocio que se ocupan de la misma informacin. Casos de uso de negocio usados por el mismo grupo de actores. Casos de uso de negocio que se ejecutana menudo en una sucesin. Los casos de uso de negocio ms importantes. Un caso de uso de negocio especfico y sus relaciones con los actoes de negocio y otros casos de uso de negocio.

Subdividir el diagrama en varios subdiagranas debe hacerse si se hace ms claro el modelo de casos de uso del negocio. Algunos convenios que se adoptan en la representacin del Diagrama de casos de uso del negocio son: Un caso de uso de negocio puede asociarse con uno o varios actores del negocio. Un caso de uso de negocio se comunica con al menos un actor, sino hay error en el modelo, excepto cuando se trata de un caso de uso abstracto o un caso de uso en una relacin de generalizacin/especializacin si en el padre se describe toda la comunicacin.

Los actores del negocio actan recprocamente con el negocio. Ambas partes pueden tomar la iniciativa en la interaccin. La navegabilidad indica quin inicia la comunicacin en la interaccin y se muentra con una flecha. Por cada flecha de comunicacin se asume un mensaje de retorno. El sentido de la flecha indica: Si apunta al caso de uso del negocio, la comuniccin la inicia el actor del negocio (Figura 8a). Si apunta al actor del negocio, entonces la comunicacin la inicia el caso de uso del negocio (Figura 8b). Si la comunicacin la puede iniciar cualquiera de los dos, se muestra sin saetas (Figura 8c).

a)

b)

c)

Figura 8 Navegabilidad en las relaciones de comunicacin entre actores del negocio y casos de uso del negocio. No se debe confundir navegabilidad con flujos de datos, la navegabilidad inidica relacin de inicicin. Algunos convenios que se usarn en la representacin de la navegabilidad son: La flecha de iniciacin del actor al caso de uso de negocio siempre se muestra, an si ms tarde el caso de uso de negocio inicia la comunicacin con el actor que lo mostr. En este ltimo caso solo se pone la flecha del actor al caso de uso del negocio. El resto de las flechas pueden ser omitidas e incluirlas para esclarecer el diagrama.

Tambin se puede representar la multiplicidad de la asociacin, lo cual indica con cuntas instancias de un caso de uso de negocio una instancia de un actor de negocio puede actuar recprocamente y, al mismo tiempo, muestra con cuntas instancias de un actor de negocio un caso de uso de negocio puede interactuar. En la figura 9 se muestra la relacin del actor Pasajero con el caso de uso del negocio Check-in individual, en la que queda claro que un Pasajero solo chequea una vez y que el chequeo individual se realiza a muchos pasajeros.

n Pasajero

1 Check-in individual

Figura 9 Ejemplo de multiplicidad entre actores del negocio y casos de uso del negocio. El convenio que usaremos ser representar la navegabilidad, pero no la multiplicidad, an cuando no hay problemas si esta ltima se representa.

2.2 Estructuracin de los casos de uso del negocio.

Para hacer que los casos de uso de negocio sean ms fciles de comprender, reutilizar partes del flujo que se comparte entre varios casos de uso del negocio y facilitar el mantenimiento del modelo de casos de uso del negocio, es que se propone estructurar los casos de uso del negocio.

La actividad consiste en extraer el comportamiento en casos de uso del negocio que necesitan considerarse como casos de uso abstractos. El trmino abstracto se refiere a aquellos casos de uso que existen solamente para que otros casos de uso lo reutilicen. Ejemplos de tal comportamiento lo son: comportamiento comn a varios casos de uso y comportamiento opcional en un caso de uso. La mayora de los workflows (flujho de trabajo: secuencia de actividades que producen un resultado de valor, que son realizados por trabajadores del negocio y que utilizan o generan objetos) pueden concebirse como varios subflujos que constituyen el flujo total. Algunas veces varios casos de uso del negocio tienen un subflujo comn, o el mismo flujo aparece en diferentes puntos de un caso de uso del negocio. Si este comportamiento comn tiene un volumen importante y forma una parte independiente y delimitada de manera natural; el modelo puede ser ms claro si este comportamiento se extrae a un caso de uso del negocio separado. Este nuevo caso de uso entonces es incluido en el caso de uso original (relacin include), es una extensin de aqul(relacin extend) o un caso de uso padre de aqul (relacin de generalizacin ). Por tanto, en la estructuracin del modelo se consideran 3 tipos de relaciones entre los casos de uso del negocio. De manera general el caso de uso del negocio que representa la modificacin se le llama caso de uso de adicin y el caso de uso del negocio que se modifica se le llama caso de uso base.
Relacin de Inclusin.

Una relacin include es una relacin desde un caso de uso base a un caso de uso de inclusin, que especifica cmo el comportamiento definido para el caso de uso de inclusin se inserta explcitamente dentro del comportamieto definido para el caso de uso base.

Se utiliza para dividir partes de un flujo de trabajo de cuyos resultados, y no del mtodo para obtenerlo, depende el caso de uso base. Se puede hacer esta particin si simplifica la comprensin del caso de uso base o si el comportamiento separado puede reutilizarse en otros casos de uso. En la figura 10 se muestra un ejemplo de reutilizacin en el que, independientemente de si el chequeo del equipaje es un inters de un pasajero o un gua de turista que atiende a un grupo de pasajeros, hay un subflujo comn que asociada al proceso de manipulacin del equipaje.

Pasajero

Check-In Individual

<<include>>

Manipular <<include>> Equipaje

Gua de turismo

Check-In de Grupo

Figura 10 Ejemplo de relaciones de inclusin por reutilizacin. E la figura 11 se muestra un ejemplo de particionamiento en el que puede definirse un subflujo completo que involucra a varias actividades y del que se obtiene un resultado. Este es un caso en el que el particionamiento permite una mejor comprensin del modelo.

<<include>> Cliente Venta de producto Verificar poltica de descuento Figura 11 Ejemplo de relaciones de inclusin por particionamiento. Ms de un nivel de relaciones de incluisn dificulta la comprensin del modelo. Una instancia de un caso de uso de negocio que sigue la descripcin de un caso de uso base, tambin seguir la descripcin del caso de uso incluido. Una inclusin de un caso de uso de negocio siempre es abstracto y no necesita tener relaciones con un actor.

Relacin de extensin

Es una relacin de un caso de uso de extensin a un caso de uso base, que especifica cmo el comportamiento definido por el caso de uso de extensin puede insertarse dentro del comportamiento definido por el caso de uso base. Una vez identificado el flujo de un caso de uso del negocio, se puede encontrar un comportamiento que es condicional u opcional. Si esa parte del comportamiento es relevante es probable que se desee describirla por separado. Una forma natural de hacerlo es describirla en una seccin separada dentro de la documentacin del flujo, pero otra alternativa es describirla como un caso de uso separado que sea una extensin del caso de uso original. Esta ltima opcin es recomendada si la parte extraida es relevante, delimitada de forma natural y si se desea mantener lo suficientemente simple el caso de uso original, o si esa parte extraida es relevante a varios casos de uso. Condicionalmente agrega un flujo al caso de uso del negocio que ya est completo de por s. Por tanto, una relacin de este tipo (extend) se emplea para mostrar alguna de las siguientes situaciones: Comportamiento opcional Comportamiento que es ejecutado solamente bajo ciertas condiciones (Ej: disparo de una alarma) Flujos distintos que pueden ejecutarse en base a la seleccin del actor
Una instancia de un caso de uso de negocio que est opcionalmente extendido por otro caso de uso, primero sigue la descripcin del caso de uso base y, entonces, si se dan las condicione que disparan el el caso de uso extendido, se sigue la descripcin de ese caso de uso. Cuando se alcanza el fin del caso de uso extendido, se vuelve a seguir la descripcin del caso de uso base.

En la figura 12 se retoma el proceso de negocio Check-in individual, en el cual se muestra que algunos pasajeros tienen que pasar un proceso adicional al que se llema Manejo especial de equipaje.

Check-In Individual

pas ajer o

Pasajero

<
>

<<extend >> <extend> Manejo Especial de Equipaje

Figura 12 Ejemplo de extensin. Los casos de uso base que son extendidos tienen que tener significado y ser completos en s mismos, aun cuando el workflow del caso de uso

extendido no se ejecute. La mayora de los casos de uso de negocio que se extienden no pueden ejecutarse solos.
Generalizacin/Especializacin entre casos de uso de negocio

Un caso de uso generalizacin es una relacin de un caso de uso hijo a un caso de uso padre que especifica cmo el hijo puede especializar todo el comportamiento y caractersticas descritas para el padre. Se utiliza para mostrar que los flujos comparten la estructura, objetivo y comportamiento. Un caso de uso padre puede especializarse en uno o ms casos de uso hijos que representan formas ms especficas del padre. Una vez identificado el flujo de cada caso de uso del negocio, se pueden encontrar estructuturas y comportamientos que son comunes a varios casos de uso. Para no tener que describir el mismo flujo varias veces, se puede colocar el comportamiento comn en un caso de uso del negocio. Una instancia del caso de uso que ejecuta un caso de uso hijo seguir el flujo de eventos descrito para el caso de uso padre, pero insertando comportamiento adicional y modificando el comportamiento de acuerdo al flujo de eventos del caso de uso hijo. En la figura 13 se muestra un ejemplo de un proceso que decribe las visitas que un vendedor realiza a los clientes. Este proceso tiene varios puntos en comn al inicio y trmino de la vistas, pero su desarrollo es diferente en dependencia de si la visita es a un cliente nuevo o ha uno que ya ha tenido contactos con la empresa.

Realizar visitas Jefe zonal

Realizar visitas a clientes registrados Realizar Visitas a clientes potenciales

Figura 13 Ejemplo de generalizacin/especializacin entre casos de uso del negocio.

Relacin de Generalizacin/Especializacin entre actores

Una relacin de generalizacin de una clase hija de actor del negocio a otra clase padre de actor del negocio indica que el hijo hereda el rol que la clase padre pude jugar respecto a un caso de uso del negocio. Varios actores del negocio pueden jugar el mismo rol en una caso de uso particular del negocio. Por ejemplo, en la figura 14 se muestra algunos procesos de negocio vinculados en la gestin de un hospital, que en el que se han identificado, entre otros, a los actores del negocio: Administrador de consulta externa y Administrador de hopitatalizacin; que cuando interactan con el proceso de negocio Despachar medicamentos en farmacia, juegan el mismo rol: Cliente. Para el campo de accin que se est modelando de un hospital, es importante describir los procesos Asignar citas y Asignar camas, siendo los interesados en estos procesos el Administrador de consulta externa y el Administrador de hospitalizacin, respectivamente, por lo que se modelan los actores de negocio.

C lie nte

D e s p a c ha r m e d ic a m e nto s e n fa rm a c ia

A s ig na r c itaA d m inis tra d o r A d m inis tr a d o r A s ig na r c a m a s s C o ns ulta E xte rna Ho s p ita liza c i n

Figura 14 Ejemplo de generalizacin/especializacin entre actores de negocio. 3- Realizacin de los casos de uso del negocio. La realizacin de un caso de uos de negocio muestra cmo colaboran los trabajadores y entidades de negocio para ejecutar el proceso. Cada realizacin se puede documentar y utilizando los diagramas de actividad, secuencia y clases y descripciones textuales. Consideramos que los diagramas de actividad y clases y una descripcin textiual, es sufiiciente para describir completamente el proceso de negocio y dan infromacin necesaria para los flujos de trabajo que se ejecutan posteriormente. No obstante, se puede construir un diagrama de secuencia por cada caso de uso de megocio en el que se muestre grficamente los detalles de la interaccin entre los trabajadores del negocio y de estos los actores del negocio; y cmo se tiene acceso a las entidades de negocio durante la ejecucin del caso de uso del negocio.

Un trabajador del negocio es una abstraccin de una persona (o grupo de personas), una mquina o un sistema automatizado; que acta en el negocio realizando una o varias actividades, interactuando con otros trabajadores del negocio y manipulando entidades del negocio. Representa un rol. Las entidades de negocio representa a los objetos que los trabajadores del negocio toman, inspeccionan, manipulan, producen o utilizan durante la realizacin de los casos de uso de negocio. Comnmente representan un documento o una parte esencial de un producto. Algunas veces representa cosas no tangibles como el conocimiento acerca de un mercado o cliente. 3.1 Descripcin textual. La descripcin textual de un caso de uso de negocio se formaliza en un documento generalmente llamado Especificacin del caso de uso de negocio2. Este documento puede tener el siguiente formato: Nombre del caso de uso Nombre del negocio: Actores del negocio: Propsito: Resumen:
Descripcin del proceso completo inidicando quin inicia y cmo se inicia, cul es el flujo de trabajo a grandes rasgos y quin finaliza el proceso y cmo se hace. La descripcin debe mencionar a los actores y trabajadores del negocio y a las actividades ms importantes que se ejecutan.

Lista de actores que se relacionan con el caso de uso, indicando quin lo inicia. Breve descripcin del objetivo del proceso.

Casos de uso asociados:

Listado de casos de uso incluidos y extendidos de este caso de uso base, indicando el tipo de relacin. Respuesta del negocio

Flujo de tabajo Accin del actor Se inidica al actor (o actores) y la Se describe el glujo de trabajo interaccin que tiene con el negocio. inficando todas las actividades del negocio que ocurren en el orden que se suceden, cul es el trabajador del negocio que las realiza y su relacin con las entidades del negocio. Deben quedar claros los puntos intermedios en los que puede finalizar el proceso. Prioridad: Mejoras: Indicar cul es la prioridad de este proceso dentro del negocio que se modela. Mejoras que tendr el proceso cuando algunas de sus activiades sean automatizadas.

Cursos alternos:
Comportamiento que no est en el flujo normal y que ocurre bajo ciertas condiciones que pueden darse en el flujo normal.

El flujo de trabajo normal de un caso de uso de negocio puede tener un flujo bsico de actividades y flujos alternativos de actividades. El flujo bsico cubre lo que siempre ocurre cuando el caso de uso de negocio es ejecutado, y el flujo alternativo describe alternativas que pueden darse cuando se produce el caso de uso, pero que no se dan de forma excepcional como ocurre con los flujos alternativos. Por ejemplo, en la descripcin de la produccin de una pieza, en dependencia de qu pieza se va a construir, hay un grupo de actividades diferentes porque pasan por diferentes mquinas y la actividad es realizada por trabajadores diferentes. Para ejemplificar los artefactos que pueden utilizarse para describir la realizacin de los casos de uso del negocio, se usar como ejemplo el subdiagrama que se presenta en la figura 15.

Proyectista

Atender proyecto nuevo

Figura 15 Ejemplo utilizado para describir los artefactos usados en la realizacin de los casos de uso de negocio. La descripcin textual de este caso de uso quedara: Nombre del caso de uso del Atender proyecto nuevo negocio: Actores del negocio: Propsito: Resumen:
El caso de uso se inicia cuando el Proyectista presenta al Jefe de la obra un nuevo proyecto para su evaluacin. Una vez que el Jefe de obra y el Econmico evala, tcnica y econmicamente su viabilidad, se registra el proyecto. El caso de uso finaliza con la notificacin al Proyectista sobre la aceptacin o rechazo de su proyecto.

Proyectista (Inicia) Registrar nuevos proyectos que sean viables de realizar tcnica y econmicamente.

Casos de uso asociados: Flujo de tabajo Accin del actor 1

Respuesta del negocio El Jefe de la obra recibe el nuevo proyecto y analiza su vaibilidad tcnica. a) Si no es viable tcnicamente, informa al Proyectista.

El Proyectista entrega las 2 caractersticas y plano de un nuevo pyecto para su evaluacin.

b) En caso contrario, se solicita al Econmico que analice la viablidad econmica y se pasa al paso 4. 3 El proyectista recibe la notificacin de que su proyecto ha sido rechazado, finaliza el proceso. 4 5 El Econmico evala econmicamente el proyecto y entrega los reslutados al Jefe de obra. El Jefe de obra verifica la evaluacin emitida. a) Si no es viable econmicamente, informa al proyectista y se pasa al paso 3. b) En caso aprobado. 6 7 El Proyectista recibe la notificacin de que el proyecto ha sido aprobado. Es el primer paso dentro del proceso de ejecucin de un obra El registro de la informacin sobre los proyecto aumentar el control de la obra y facilitar su seguimiento.
La automatizacin de los procesos de evaluacin reducir el tiempo de respuesta y permitir a estos trabajadores mejorar su gestin.

contrario,

registra

el

proyecto

El Jefe de la obra notifica al proyectista que su proyecto ha sido aprobado.

Prioridad: Mejoras:

Cursos alternos: Los caso de uso que tienen relaciones de generalizacin/especializacin tiene comportamiento silimar y actividades que los diferencias. Para estos casos de uso se propone segmentar la descripcin de los casos de uso en segmentos iguales (con todas las actividades del padre que se hace igual en los hijos, aunque los hijos pueden redefinirlos) y segmentos que los hijos realizan de forma diferente. Para el subdiagra de la figura 13, las descripciones de los procesos de negocio quedarn como sigue:
Caso de uso Padre Nombre del caso de uso del negocio:

Realizar Visitas
Jefe Zonal (Inicia)

Actores del negocio:

Propsito: Casos de uso asociados

Realizar una visita a un cliente para vender algn servicio. -

Resumen: El caso de uso se inicia cuando el Jefe de Zona comunica al vendedor el plan de visitas del da. El vendedor realiza todas las visitas en plan. Al finalizar entrega los formulari que se han ido llenando en cada visita.
Flujo de trabajo

Accin del actor

Segmento 1: Iniciar visitas

Respuesta del negocio

1. El Jefe de Zona comunica el plan de visitas del da al Vendedor 2. El Vendedor recoge los formularios necesarios segn el plan de visitas del da

3. Una vez en la casa del Cliente el Vendedor llen el formulario con los datos generales del Client

4. El Vendedor registra la fecha y hora de comien de la visita

Segmento 2: Desarrollo de la visita

Segmento 3: Terminar visitas

1. El Vendedor registra hora de fin de visita 3. El Jefe Zonal recibe todos los documentos generados durante las visitas. Prioridad: Mejoras: Cursos alternos: -

2. El vendedor entrega al final del da todos los formularios con los datos de las visitas realizadas Jefe de Zona.

El registro de la informacin mejorar el control que se tiene sobr trabajo de los vendedores. Se propone que tendrn una term porttil de procesamiento de datos

Casos de uso Hijos Nombre del caso de uso del negocio:

Realizar Visitas a Clientes Potenciales Jefe Zonal (Inicia) -

Actores del negocio:

Propsito:

Realizar una visita a un cliente potencial para vender algn servicio

Casos de uso asociados

Resumen: El caso de uso se inicia cuando el Jefe de Zona comunica al vendedor el plan de visitas del da. El vendedor realiza todas las visitas a los posibles nuevos clientes comunicndoles los servicios que ofrece la empresa y creando contratos de intencin con aquellos clientes potenciales que soliciten algunos de los servicios ofrecidos. Al finalizar entrega los formularios que se han ido llenando en cada visita.
Flujo de tabajo

Accin del actor

Segmento 1: Iniciar visitas

Respuesta del negocio

Segmento 2: Desarrollo de la visita

1. El Vendedor comunica al Cliente los servicios que ofrece la empresa.

2. Si el cliente potencial solicita algn servicio de los ofertados establecen los trminos del contrato y se firma una Intencin Contrato. En caso contrario el vendedor registra la negativa del Client pasa a 4.

3. Si el Cliente ha solicitado algn servicio, el Vendedor pacta la fech hora de la prxima visita. 4. El Cliente firma constancia de visita.
Segmento 3: Terminar visitas

Prioridad: Mejoras:

El registro de la informacin mejorar el control que se tiene sobre el trabajo de vendedores. Se propone que tendrn una terminal porttil de procesamiento datos.

Cursos alternos: Nombre del caso de uso del negocio:

Realizar Visitas a Clientes Registrados Jefe Zonal (Inicia) Realizar una visita a un cliente registrado para vender algn servicio.

Actores del negocio:

Propsito:

Casos de uso asociados

Resumen: El caso de uso se inicia cuando el Jefe de Zona comunica al vendedor el plan de visitas del da. El vendedor realiza todas las visitas a los clientes para cobrar las plizas de seguro segn los trminos de sus contratos y comunicarles los nuevos servicios que ofrece empresa. Al finalizar entrega los formularios que se han ido llenando en cada visita.
Flujo de tabajo

Accin del actor Segmento 1: Iniciar visitas

Respuesta del negocio

Segmento 2: Desarrollo de la visita 1. El Vendedor cobra pliza de seguro

2. El Vendedor comunica nuevos servicios y/o modalidades de servicios nuevas promociones.

3. Si el Cliente se acoge a una promocin, nueva modalidad, o a un nue servicio se establecen los trminos para actualizar el contrato y el Vendedor lo registra en el formulario. 4. El Vendedor pacta fecha y hora de prxima visita y lo registra en el formulario. Segmento 3: Terminar visitas Prioridad: Mejoras: Cursos alternos: Cuando hay casos de uso incluidos o extendidos, en la descripcin d ser invocados en el punto de inclusin o extensin indicando los resultados que se tienen de su ejecucin y, para el caso de los extendidos, la condicin que tiene que cumplirse. -

El registro de la informacin mejorar el control que se tiene sobre el trabajo de vendedores. Se propone que tendrn una terminal porttil de procesamiento datos.

Conclusiones

El propsito del modelo de negocio es ayudarlo a usted a lograr una mejor comprensin del problema que su software tiene que resolver. De hecho, los requerimientos para la aplicacin pueden ser derivados a partir del modelo de negocio.
El modelo de negocio consiste en el modelo de casos de uso del negocio y el modelo de objeto del negocio. El modelo de casos de uso del negocio describe la forma, en que el negocio es utilizado por los usuarios y los partners. Los workflows de los casos de uso del negocio se describen detalladamente utilizndose los diagramas de actividades. El modelo de objeto del negocio, que contiene las entidades del negocio y los trabajadores del negocio, identifica todos los roles y las cosas en el negocio.

Jacobson, Rumbaugh y Booch no solo nos dicen qu debemos hacer, tambin han elaborado lista de chequeos que nos permiten revisar y perfeccionar el trabajo realizado.
Modelo de Caso de Uso de Negocio

Cada Caso de Uso de Negocio debe describir un flujo de trabajo que produzca un resultado de valor para un Actor de Negocio. Cada Caso de Uso de Negocio debe estar completo desde la perspectiva de los que estn fuera (Actores). Los Casos de Uso de Negocio deben ejecutar slo las actividades que forman parte del negocio. Si el Diagrama de Actividad asociado a un Caso de Uso de Negocio slo consta de una actividad no es un Caso de Uso de Negocio pues no es un proceso. No se deben considerar como Casos de Uso los distintos pasos de un mismo proceso.

Los nombres de los Casos de Uso deben ser claros y reflejar el propsito. Para ello se deben utilizar verbos en infinitivo. Las relaciones entre Casos de Uso slo pueden ser de inclusin (debe aparecer el estereotipo <include>), de extensin (aparecer el estereotipo <extend>) o de generalizacin-especializacin. No pueden haber Casos de Uso de Negocio que no estn vinculados a ningn Actor de Negocio. La excepcin la constituyen los Casos de Usos extendidos, incluidos y los generalizados. No pueden haber Actores de Negocio que no estn vinculados a ningn Caso de Uso de Negocio. Cada Actor de Negocio debe corresponderse con un rol y no con una persona fsica (un mismo rol puede ser jugado por varias personas fsicas y una misma persona fsica puede desempear varios roles a la vez). Una generalizacin-especializacin entre Actores de Negocio slo tiene sentido si todos estn asociados con al menos un Caso de Uso de Negocio. Para un Caso de Uso un Trabajador de Negocio no puede ser considerado como Actor y viceversa. En todo Diagrama de Casos de Uso de Negocio se debe indicar quien inicia la comunicacin entre Actores y Casos de Uso. Una flecha del Actor al Caso de Uso indica que el Actor inici la comunicacin. Una flecha del Caso de Uso al Actor indica que se desea comunicar un resultado o se le solicita una informacin al Actor. Demasiados Casos de Uso dificultan la comprensin. Casos de Uso muy extensos dificultan la comprensin.

Un ejemplo: la maquina de gaseosas

Suponga que empezar a disear una mquina despachadora de gaseosas. Para obtener el punto de vista del interesado, entrevistar a varios usuarios potenciales respecto a la manera en que utilizarn dicha mquina. Dado que la funcin principal de una mquina de gaseosas es permitir a un cliente adquirir una lata de gaseosa, probablemente las personas le dirn que se enfrentara a diversos escenarios -un caso de USO, en otras palabras- que podra etiquetar como Comprar gaseosa. Examinemos cada posible escenario en este caso de uso. Recuerde que tales escenarios podran aparecer durante la conversacin con los usuarios.

El caso de uso Comprar gaseosa

El actor, en este caso de uso, es un cliente que desea comprar una lata de gaseosa. El escenario iniciar cuando el cliente inserte dinero, posteriormente realizar una seleccin; y si todo funciona bien, la mquina contar con, a1 menos, una lata de la gaseosa elegida, misma que pondr a1 alcance del cliente. Adems de la secuencia, hay otros aspectos del escenario anterior que merecen cierta consideracin. Que condiciones llevaron a1 cliente a iniciar el escenario en el caso de uso Comprar gaseosa? La sed es la mis obvia. Que se obtiene como resultado de tal escenario? Nuevamente, lo obvio es que el cliente tenga una gaseosa en su poder. Lo que he descrito aqu es la nica posibilidad de Comprar gaseosa? Habra otras cuestiones que saltaran a la vista; por ejemplo, es posible que la mquina no tenga la gaseosa que desee el cliente; tambin es posible que el cliente no tenga el importe exacto de la gaseosa. Como diseara a la mquina de gaseosas para controlar tales escenarios? Veamos el caso en que la mquina se haya quedado sin gaseosa, otra secuencia de pasos en el caso de uso Comprar gaseosa. Imagnelo como una ruta alternativa dentro del caso de uso. El cliente inicia el caso de uso a1 insertar dinero en la mquina y posteriormente hace una seleccin. La mquina no cuenta con ninguna lata de la gaseosa seleccionada, por lo que mostrar un mensaje a1 cliente que indicar que no tiene de esa marca. Lo ideal seria que el mensaje le pida a1 cliente que haga otra seleccin. La maquina tambin debera dar la opcin de devolver el dinero a1 cliente. En este punto, el cliente selecciona otra marca que la maquina entregar (siempre y cuando cuente con provisiones de esta marca), o devolver el dinero. La condici6n

previa es un cliente sediento y el resultado es una lata de gaseosa o la devolucin del dinero.

Analicemos ahora el escenario de la cantidad de dinero incorrecta. Nuevamente, el usuario inicia el caso de uso en la forma usual y posteriormente hace una seleccin. Asumamos que la mquina tiene provisin de la marca elegida. En la mquina hay una reserva de moneda fraccionaria y devuelve la diferencia a1 despachar la gaseosa. Si la mquina no cuenta con una reserva de moneda fraccionaria, devolver el dinero y mostrar un mensaje que pida a1 usuario el importe exacto. La condicin previa es la ya indicada. El resultado ser una lata de gaseosa junto con el cambio, o la devolucin del dinero originalmente depositado. Otra posibilidad es que tan pronto como se agote la moneda fraccionaria, aparezca un mensaje que informe a los clientes que se requiere el importe exacto. El mensaje permanecera a la vista hasta que la mquina sea reabastecida con moneda fraccionaria.

Casos de uso adicionales

Ya ha examinado a la mquina de gaseosas desde el punto de vista de un usuario: el cliente. Hay otros usuarios que intervienen, como el proveedor que tiene que reabastecer a la mquina, el recolector de dinero (que tal vez sea el mismo que el proveedor) que tiene que recoger el dinero acumulado en la alcanca de la mquina, etctera. Esto nos indica que debemos crear a1 menos dos casos de uso: Reabastecer y Recolectar dinero, cuyos detalles surgirn durante las entrevistas con los proveedores y los recolectores. Veamos el caso de uso de Reabastecer. El proveedor inicia este caso de uso dado que algn intervalo (digamos, dos semanas) ha pasado. El representante del proveedor le quita el seguro a la mquina (tal vez mediante una llave y un cerrojo, pero eso entra dentro de la implementacin), jala la puerta para abrir la mquina, y llena el compartimiento de cada marca hasta su capacidad. El representante tambin rellena la reserva de moneda fraccionaria. Luego, cierra el frente de la mquina y vuelve a poner el seguro. La condicin previa es el paso del intervalo, el resultado es que el proveedor cuenta con un nuevo conjunto de ventas potenciales. Para el caso de uso de Recolectar el dinero, el recolector inicia debido tambin a que ha pasado cierto tiempo. La persona deber seguir la misma secuencia que en Reabastecer para abrir la mquina. El recolector sacar el dinero de la mquina y seguir los pasos de Reabastecer para cerrar y poner el seguro a la mquina. La condicin previa es el paso del intervalo y el resultado es el dinero en las manos del recolector.

Vea que cuando derivamos un caso de uso, no nos preocupamos por la forma de implementarlo. En nuestro ejemplo, no nos interesamos en los aspectos internos de la mquina de gaseosas. Tampoco por la forma en que funcione el mecanismo de refrigeracin, o por la forma en que la mquina controle la cantidad de dinero que contenga. Tan solo intentamos ver la forma en que la mquina lucid para alguien que tenga que utilizarla. El objetivo es derivar una coleccin de casos de uso que, finalmente, mostraremos a las personas que disean la maquina de gaseosas y a las personas que la construirn. Por aadidura, nuestros casos de uso reflejan lo que los clientes, recolectores y proveedores desean, por lo que el resultado ser una mquina que todos esos grupos puedan utilizar con facilidad.

Inclusin de los casos de uso

En los casos de uso Reabastecer y Recolectar dinero, tal vez distingui ciertos pasos en comn. Ambos empezaban con abrir la mquina, y finalizaban con el cierre de la mquina y su aseguramiento. Podramos eliminar la duplicaci6n de pasos de un caso de uso al otro?
Si podemos. La forma de hacerlo es tomar cada secuencia de pasos en comn y

conformar un caso de uso adicional a partir de ellos. Combinemos los pasos necesarios para quitar el seguro y abrir la mquina y 1lammoslos Exhibir el interior y los pasos cerrar la mquina y asegurarla en otro caso de uso llamado Cubrir el interior. Con estos nuevos casos de uso a la mano, el caso de uso Reabastecer iniciara con el caso de uso Exhibir el interior. Luego, el representante del proveedor seguira los pasos ya indicados, y concluira con el caso de uso Cubrir el interior. De forma similar, el caso de uso Recolectar dinero iniciara con Exhibir el interior, procedera como se indico, y finalizara con el caso de uso Cubrir el interior. Como ve, Reabastecer y Recolectar dinero incluyen los nuevos casos de uso. Por ello, a esta tcnica de aprovechamiento de un caso de uso se le conoce como inclusin de un caso de U SO .

Extensin de los casos de uso

Es posible volver a utilizar un caso de uso de una forma distinta a una inclusin. En ocasiones crearemos un caso de uso agregndole algunos pasos a un caso de uso existente. Regresemos a1 caso de uso Reabastecer. Antes de colocar nuevas latas de gaseosas en la mquina, suponga que el representante del proveedor nota las

marcas que se han vendido bien, as como las que no se han vendido tan bien. En lugar de solo reabastecer todas las marcas, el representante podra sacar aquellas que no se han vendido bien, y reemplazarlas por latas de las marcas que han probado ser mis populares. De esta forma, tendra que indicar a1 frente de la mquina el nuevo surtido de marcas disponibles. Si agregamos estos pasos a Reabastecer, tendremos un nuevo caso de uso que llamaramos Reabastecer de acuerdo a las ventas. Este nuevo caso de uso es una extensin del original, accin a la que se le conoce como extensin de un caso de U SO

lnicio del anlisis de un caso de uso

En nuestro caso, nos hemos involucrado directamente con los casos de uso y nos hemos enfocado en algunos de ellos. En el mundo real, por lo general, seguir un conjunto de procedimientos cuando empiece un anlisis de casos de uso. Empezar con entrevistas a los clientes (y entrevistas con expertos) que lo lleven a los diagramas iniciales de clases que indicamos en la hora 3. Esto le dar cierta idea del rea en la que trabajar y una familiaridad con los trminos que utilizar. Posteriormente, contar con un fundamento para hablar con los usuarios. Entrevistara a los usuarios (preferentemente en grupos) y les pedir que le indiquen todo lo que ellos haran con el sistema que usted disear. Sus respuestas conformarn un conjunto candidato de casos de uso. Luego, es importante describir brevemente cada caso de uso. Tambin tendr que derivar una lista de todos los actores que iniciarn y se beneficiarn de los casos de uso. Cuanta mas informacin obtenga en esta fase, aumentar su aptitud para hablar con los usuarios en su propio idioma. Los casos de uso aparecern en varias fases del proceso de desarrollo. ayudarn con el diseo de una interfaz del usuario, coadyuvarn con las L e opciones de desarrollo de los programadores y establecern las bases para probar el sistema recin generado. Para mayor informaci6n en el tema del anlisis de los casos de uso, va a tener que aplicar el UML, y ello se har en la siguiente hora.

Resumen
El caso de uso es una estructura para describir la forma en que un sistema lucir para los usuarios potenciales. Es una coleccin de escenarios iniciados por una entidad llamada actor (una persona, un componente de hardware, un lapso u otro sistema). Un caso de uso debera dar por resultado algo de valor ya sea para el actor que lo inicio o para otro. Es posible volver a utilizar casos de uso. Una forma (inclusin) es utilizar los pasos de un caso de uso como parte de la secuencia de pasos de otro caso de uso. Otra forma (extensin) es crear un nuevo caso de uso mediante la adicin de pasos a un caso de uso existente.

La entrevista directa con los usuarios es la mejor tcnica para derivar casos de uso. Cuando se deriva un caso de uso, es importante destacar las condiciones para iniciar el caso de uso, y los resultados obtenidos como consecuencia del mismo. Haga las entrevistas a los usuarios despus de entrevistar a los clientes y generar una lista de prospectos de clases. Esto le dar un fundamento en la terminologa que utilizar para hablar con los usuarios. Es una buena idea entrevistar a un grupo de usuarios. El objetivo es derivar un conjunto candidato de casos de uso y todos los posibles actores.
Conclusiones El proceso de modelacin permite obtener una visin de la organizacin que permita definir los procesos, roles y responsabilidades de la organizacin en los modelos de casos de uso del negocio y de objetos. El modelacin del negocio como flujo de trabajo permite: Comprender la estructura y la dinmica de la organizacin en la cual se va a implantar un sistema. Comprender los problemas actuales de la organizacin e identificar las mejoras potenciales. Asegurar que los consumidores, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin. Derivar los requerimientos del sistema que va a soportar la organizacin. El modelo del dominio por su parte no es ms que un caso especial de modelo de negocio ms completo.

Ejercicios
1. En el caso del ejemplo de la maquina de gaseosas, Cree otro caso de uso 2. Una gran tienda de equipos de cmputo que venda hardware, perifricos

incluya a los casos de uso Exhibir el interior y Cubrir el interior.

y software. Quines serian los actores? Cuales serian algunos de los principales casos de uso? Cuales seran algunos de los escenarios dentro de cada caso de uso?

Diagramas de casos de uso

El caso de uso es un poderoso concepto que ayuda a un analista a comprender la forma en que un sistema deber comportarse. Le ayuda a obtener los requerimientos desde el punto de vista del usuario. Es necesario aprender a visualizar los conceptos del caso de uso que conoci en anteriormente. Temas: Representacin de un modelo de caso de uso Concepcin de las relaciones entre casos de uso

Diagramas de casos de uso en el proceso de anlisis Aplicacin de los modelos de caso de uso Vera la idea general del UML

El caso de uso es muy poderoso, pero lo es an ms cuando se visualiza por medio del UML. Esta visualizacin le permitir mostrar los casos de uso a los usuarios para que ellos le puedan dar mayor informacin. Es un hecho que los usuarios con frecuencia saben ms de lo que dicen: el caso de uso ayuda a romper el hielo. A su vez, una representacin visual le ayuda a combinar los diagramas de casos de uso con otro tipo de diagramas. Una de las finalidades del proceso de anlisis de un sistema es generar una coleccin de casos de uso. La idea es tener la posibilidad de catalogar y hacer referencia a esta coleccin, que sirve como el punto de vista de los usuarios acerca del sistema. Cuando llegue el momento de actualizar el sistema, el catlogo de casos de uso funcionar como un fundamento para obtener los requerimientos de la actualizacin.

Representacin de un modelo de caso de uso

Hay un actor que inicia un caso de uso y otro (posiblemente el que inicio, pero no necesariamente) que recibir algo de valor de 1. La representacin grfica es directa. Una elipse representa a un caso de uso, una figura agregada representa a un actor. El actor que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El nombre del actor aparece justo debajo de 1, y el nombre del caso de uso aparece ya sea dentro de la elipse o justo debajo de ella. Una lnea asociativa conecta a un actor con el caso de uso, y representa la comunicacin entre el actor y el caso de uso. La lnea asociativa es slida, como la que conecta a las clases asociadas. Uno de los beneficios del anlisis del caso de uso es que le muestra los confines entre el sistema y el mundo exterior. Generalmente, los actores estn fuera del sistema, mientras que los casos de uso estn dentro de 1. Utilizar un rectngulo (con el nombre del sistema en algn lugar dentro de 1) para representar el confn del sistema. El rectngulo envuelve a los casos de uso del sistema.
Los actores, casos de uso y lneas de interconexin componen un modelo de

caso de uso. La figura 7.1 le muestra estos smbolos.

Una nueva visita a la maquina de gaseosas

Apliquemos los smbolos a1 ejemplo de la hora anterior. Como recuerda, desarrollo los casos de uso para una mquina de gaseosas. El caso de uso Comprar gaseosa se encuentra dentro del sistema junto con Reabastecer y Recolectar dinero. Los actores son el Cliente, Representante del proveedor y el Recolector. La figura 7.2 le muestra un modelo UML de caso de us0 para una mquina de gaseosas.

Secuencia de pasos en los escenarios

Cada caso de uso es una coleccin de escenarios y cada escenario es una secuencia de pasos. Como puede ver, tales pasos no aparecen en el diagrama. No se encuentran en notas adjuntas a los casos de uso. Aunque el UML no lo prohbe, la claridad es clave en la generacin de cualquier diagrama y el adjuntar notas a cada caso de uso podra volverlo confuso. Cmo y donde hara la secuencia de pasos? El uso de los diagramas de casos de uso ser, por lo general, parte de un documento de diseo que el cliente y el equipo de diseo tomarn como referencia. Cada diagrama tendr su propia pgina, de igual manera, cada escenario de caso de uso tendr su propia pgina, donde se listar en modo de texto a: El actor que inicia a1 caso de uso Condiciones previas para el caso de uso Pasos en el escenario Condiciones posteriores cuando se finaliza el escenario El actor que se beneficia del caso de uso Tambin puede enumerar las conjeturas del escenario (por ejemplo, que un cliente a la vez utilizar la mquina de gaseosas) y una breve descripcin de una sola frase del escenario.