1

De los Procesos de Negocio a los Casos de Uso

Lic. David Espinoza Robles

2

Introduccion

• UML es adoptado por OMG como el elenguaje estandar para le modelado se han defindo un buen numero de modelos de procesos para el desarrollo de aplicaciones OO.

• Las propuesta estan dirigidas por casos de uso, que definen los requisitos funcionales del sistema.

3

• Los casos de uso actualmente son mal interpretados.

• No existen guias precisas para resolver los aspectos que tienen que ver con la organización.

• Se discuten cuestiones tales como la granularidad de los CU asi como el nivel de detalle que deben describirse.

• O la convenienza de crear jerarquias de CU.

4

• Inspirados en la arquitectura de de Tres Modelos de Ooran y el metodo IDEA, se propone un proceso basado en UML orientado a sistemas de informacion.

• Este Proceso incluye:– Fase de Modelado de Negocios– Versión inicial del Modelo Conceptual y de

Casos de Uso.

• El modelo de Negocios se describe haciendo uso de diagramas de actividades UML

5

• Posteriormente se identifican los casos de Uso del sistema, a partir de las actividades y los conceptos (clases del dominio) a partir de los datos: objetos de informacion que fluyen entre las actividades.

6

Motivacion

• Problema de la Utilizacion de CU.– Los Procesos propuestos para UML se definen

como Dirigidos por CU.– Un CU se define como una secuencia de

acciones incluyendo variaciones que el sistema puede ejecutar y que produce un resultado observable de valor para un actor que interactúa con el sistema.

– Los CU son intuitivos pero existe dificultades para obtener y especificación de CU.

7

• No existe consenso sobre como usarlos y manejarlos.

• Por esto en necesario obtener un conjunto de guías para la identificación, descripción, y organización de CU.

• Algunos sugieren que los CU., deben ser organizados jerárquicamente y establecer que:– I) cada nivel de CU no debe añadir nuevos

requisitos sino refinar los del nivel superior.

8

– II) la jerarquía de los CU no debe ser el resultado de una descomposición funcional, y ha de ser desarrollado de manera iterativa e incremental.

• Por otro lado se utiliza el concepto de objetivo para organizar jerárquicamente los CU. Se distingue básicamente:– Objetivo estratégico (los procesos del negocio

de la organización)– Objetivo de usuario: (las funcione del sistema)– Objetivo compuesto: que corresponde bien a un

conjunto de objetivos de usurario o bien a un objetivo estratégico.

9

• Otro asunto importante es la ubicación del modelado de CU dentro del modelo de proceso.

• Normalmente se ubica el modelado de CU como un paso previo al modelo conceptual.

• Sin embargo no es posible crear CU adecuado e implementarlos sin comprender el dominio

• Por lo tanto el modelado de CU y el modelo conceptual se deben realizar en paralelo.

10

La Propuesta.• Los CU son elicitados de forma intuitiva, a

partir de las especificaciones del sistema.

• Posteriormente las entidades del modelo conceptual se extraen a partir de las especificaciones de los CU.

• Se presenta una propuesta para obtener de manera sistemática tanto el modelo de CU como el modelo conceptual, a partir de un modelo de negocios de acuerdo al esquema.

11

12

• Inspirados en la arquitectura de tres modelos de Ooran, el modelado del negocio se realiza mediante:– Diagrama de actividades UML.– Los CU se elicitan y estructuran a partir de las

actividades de cada proceso.– Las entidades del modelo conceptual se obtiene

de los datos que fluyen entre tales actividades.

• Además se identifican las reglas del negocio y se incluyen en un glosario.

• El modelado de CU y modelo conceptual se realizan al mismo tiempo.

13

Modelado del Negocio.

• Para conseguir sus objetivos una empresa organiza sus actividades por medio de un conjunto de procesos de Negocios. (PN)

• Los PN se caracterizan por una colección de datos que son producidos y manipulados mediante un conjunto de tareas.

• En las Tareas participan agentes (trabajadores o departamentos) de acuerdo a un flujo de trabajo determinado.

14

• Los procesos se hallan sujetos a una serie de reglas del negocio que determinan las políticas y la estructura de la información.

• Por tanto la finalidad del Modelado del Negocio es describir cada proceso del negocio, especificando sus datos, actividades (tareas), roles (agentes) y reglas del negocio

• El primer paso del modelado del negocio es capturar los procesos del negocio.

15

• Los procesos del negocio definen los limites del proceso de modelado posterior.

• Los procesos del negocio se capturan a partir de los objetivos principales de la empresa.– Primero considerar los objetivos estratégicos de

la organización.– Se descompone estos objetivos estratégicos en

subobjetivos, que deberán cumplirse– Los subobjetivos pueden ser descompuestos de

manera que se defina una jerarquía de objetiv.

16

• Para cada subobjetivo de segundo nivel definimos un proceso de negocio que deberá dar soporte ha dicho subobjetivo.

• Representamos cada proceso del negocio como un Caso de Uso del Negocio.que será descrito de forma textual.

17

• Por Ejemplo: sea una compañía que fabrica productos bajo demanda: (esquema just in time):– Objetivos estratégicos:

• Satisfacer pedido de un cliente• Incrementar en un 25% las ventas• Disminuir en un 15% el tiempo de fabricación

– El objetivo : Satisfacer Pedido de un cliente• Subobjetivos:

– Registrar Pedido del cliente– Fabricar Producto pedido– Gestionar almacén– Realizar pedido a proveedores

18

Identificación de los Roles del Entorno del Negocio.

• Una vez identificados los procesos de negocio, hay que encontrar los agentes involucrados en su realización.

• Cada uno de estos agentes o actores del negocio desempeñan cierto papel o rol cuando colaboran con otros para llevar a cabo las actividades que conforman el CU.

• Los agentes pueden ser propios de la empresa ( trabajadores del negocio) o agentes externos (actores del negocio)

• Nos concentraremos en los actores del negocio.

19

• El diagrama de CUN dará una visión general de los diferentes procesos del negocio.

• En el diagrama de CUN aparece cada proceso del negocio como un CUN.

• Este diagrama nuestra los limites y entorno de la organización en estudio.

• Solo se muestran los actores del negocio. Que corresponde a los roles externos al sistema.

20

• Así los CUN en los que tomen parte los roles internos a la organización, no estarán conectados a ningún actor.

• En nuestro ejemplo el agente cliente esta conectado e un CUN y arranca la realización del CU.

• El Agente Proveedor solo participa en el CU asociado.

21

22

Descripción del CU de Negocio

• El siguiente paso es introducirse en cada CUN identificado, para describirlo en detalle.

• Nos centraremos en le CUN Registrar pedido para describirlo

• Esta descripción debe ser validada por los usuarios.

23

24

• A continuación se determinan los agentes internos que juegan un rol en cada CUN.

• Para lo cual se estudia la descripción de cada CUN y observar el conjunto de roles involucrados tanto externos como internos

• Los roles del CUN Registrar Pedido son Cliente, Comercial, Jefe Técnico, Jefe de Producción. Siendo los tres últimos internos al sistema.

25

• El aspecto de la colaboración entre los roles para llevar a cabo un CUN se puede representar en un diagrama de Roles

• Cada rol es una clase UML y aparece asociada con los roles que puede colaborar y expresa el conocimiento que unos roles tienen sobre otros así como su multiplicidad.

• Este diagrama permite mostrar las características de los roles como sus atributos y responsabilidades

26Diagrama de Roles para CU de Negocio Registrar Pedido

27

• Después se crean escenarios para mostrar el comportamiento de la colaboración.

• Para lo cual usaremos diagramas de secuencias UML. En los que los objetos son los roles que intervienen en la interacción.

• Se puede distinguir el flujo básico o normal de la interacción( solicitud de un perdido aceptado) y los posibles flujos alternativos (rechazo o cancelación de un pedido)

• Para lo que es conveniente asociar varios escenarios a un caso de uso de Negocio

28

29

• El Modelo de Negocios se representa por una vista de procesos en la cual se muenstra el flujo de trabajo a realizar , indicando que roles realizan cada actividad y cuales son los datos requeridos y producidos.

• Estos diagramas puden adaptarse en UML usando diagramas de actividades con calles. Y a estos diagramas lo llamaremos diagrama de procesos.

30

• En el diagrama de procesos, existe una calle por cada rol participante en el escenario, que incluye las actividades que realiza dicho rol.

• El diagrama nuestra la informacion que necesita y produce cada actividad. Y la cincronizacion entre las diferentes actividades.

• Los datos aparecen como objetos que fluyen entre las actividades y pueden tener un estado.

31

32

• Durante la descripcion de un proceso de negocio mediante un diagrama de procesos es posible encontrar una actividad cuya complejidad se tal que necesite discribirla mediante otro diagrama de proceso adicional.

• De este modo los procesos de negocio se organizan jerarquicamente.

33

Especificacion de Reglas del Negocio

• En las organizaciones los datos y los procesos estan restringidos por reglas del negocio.

• Se distingue entre:– Reglas de restricción

• Regla de estimulo respuesta• Regla de restricción de operación• Reglas estructurales

– Reglas de derivación

34

• Se recogen de manera explicita estas reglas en el modelo del negocio mediante la especificacion de las actividades y objetos de informacion, que aparen en los diagramas de procesos.

• Estas especificaciones se resumen en un glosario

• En la figura 7 se mostrara las especificaciones del objeto de informacion Pedido y de las actividades Ordenar Fabricacion, Notificar Aceptacion de pedido

35

36

• Cada objeto de informacion se describe mediante un conjunto de atributosy sus restricciones de integridad. Por tanto se establece explicitamente las reglas estructurales y de derivacion.

• Las especificacion de la semantica de cada actividad contendra:– Origen : actividades que la preceden– Agente responsable de llevar a cabo la

actividad– Pre y post condiciones: que debe cumplirse

antes y después de cada actividad

37

• Las pre y post condiciones coresponde con las reglas de operación. Las reglas de estimulo respuesta quedan reflejadas en el origen.

• El glosario tendrá una estructura de hipertexto (referencia cruzada) con el objeto de mantener la trazabilidad entre procesos del negocio y las clases y los CU.

38

Analisis de Requisitos: Modelo Conceptual y de CU iniciales

• Los requisitos elicitados y especificados en esta fase seran incluidos en un documento de especificacion de requisitos del software (ERS) atraves de una plantilla.

• A partir del modelo de negocios se puede obtener la colección de casos de uso del Sistema como el modelo conceptual preliminar.

39

Transicion al Modelo Inicial de Casos de Uso del Sistema

• Las actividades del diagrama de procesos tienen el nivel de granulidad adecuado para ser asociadas a un caso de uso del sistema.

• Crearemos un CU del sistema por cada actividad del diagrama de proceso que deba ser soportada por el sistema software.

• El rol que lleva a cabo la actividad sera el actor principaldel CU.

40

• No todas las actividades del diagrama de procesos seran consideradas como casos de uso, sino solo las que sean de valor para el actor. (ejemplo el rol cliente y la actividad rellenar Pedido).

• Algunos CU no se obtendran directamente a partir de los diagramas de procesos. Esto nuevos CU se detectaran al describir los CU identificados y al adquirir un mayor conocimientos sobre los requisitos.

41

• En el ejemplo para Analizar Viabilidad es necesario buscara el catalogo de productos, por lo que este debe permanecer actualizado, por lo que se añade el CU Mantener Productos del Catalogo , otro CU seria Mantener Plantillas de Fabricacion.

• Los CU se pueden organizar en varios niveles (dos o tres) de acuerdo a la descomposicion jerarquica del Modelo de Negocio

42

43

• Cada caso de Uso se describe mediante una plantilla que se rellena a partir de la especificacion de la actividad asociada que se encuentra en el glosario de requisitos.

• Una vez descrito el CU se conectara a la especificacion de la actividad asociada en el glosario, con el objeto de mentener la trazabilidad entre los CUN y los CUS

• Tambien se podra encontrar relaciones entre CU de Include y Extend. Sin embargo no se debe abusar de estas relaciones.

• Para completar este fase se establece los requisitos no Funcionales.

44

• Caso de Uso Ordenar Fabricación•  • Descripción Se crearán órdenes de trabajo para cada producto solicitado en el

pedido, y serán enviadas al jefe de producción para su planificación.

•  • Actores Jefe técnico•  • Asunciones - Es viable la fabricación de cada producto solicitado en el pedido.

– - Existe una plantilla de fabricación para cada producto solicitado.• Pasos

– 1 REPETIR– 1.1 Obtener un producto del pedido.– 1.2 Buscar la plantilla de fabricación asociada al producto.– 1.3 Crear la orden de trabajo.– 1.4 Almacenar la orden de trabajo con el estado pendiente.

•  • Variaciones --• Req. No Funcionales --

Cuestiones --•  • Fig. 9. Descripción del caso de uso del sistema Ordenar Fabricación

45

Obtencion de Modelo Conceptual Inicial• Los objetos de informacion que fluyen entre las

actividades de CUN representan datos del dominio . Los que se toman como base para crear el Modelo conceptual inicial. Mediante un diagrama de clases de UML.

• Cada objeto de informacion del Diag de Proceso, se combierte en un concepto que dara lugar a una clase.

• A partir de la especificacion de un objeto de informacion obtendremos la definicion del concepto.

46

• Por ejemplo: con la especificacion de Pedido, obtenemos:– I) los atributos codigo, fechaSolicitud, FechaCreacion,

FechaMaxEntrega, importeTotal, estadoActual.

– Ii) las asociaciones Cliente – Pedido y Pedido – Producto

– Iii) restricciones que se pueden expresar como {fechaMaxEntrega > fechaCreacion}

Las responsabilidades se obtienen a partir de las restricciones especificadas en el glosario. Ejemplo la clase Pedido con responsabilidades:

ObtenerProductos, CalcularFechaMaxEntrega, CalcularImporteTotal o CambiarEstado

47

48

• En esta etapa del desarrollo nos detenemos en la identificacion de los conceptos y no tanto entre las relaciones entre ellos.

• Se concentra en las asociaciones del tipo debe – conocer. Por ejemplo podemos establecer que un Perdido debe conocer al cliente que lo realiza y los Productos que lo componen. De este modo algunos roles identificados en el Modelo de Negocio podran ser incluidos como una clase en el modelo conceptual. La clase Cliente en nuestro caso

49

• A partir del modelo de Negocios es posible identificar que clases tienen un comportamiento que depende de un conjunto no trivial de estados alcanzables.

• En esto casos se puede definir una maquina de estados mediante un diagrana de estados de UML.

• En nuestro ejemplo: con Pedido se puede construir una Maq. De estados que nuestre los estados de: propuesto, en_evaluacion, evaluado, aceptado, y rechazado con sus respectivos eventos