Un Proceso Basado en UML para Sistemas de Informacin.

Lic. Espnoza Robles Armando David.

Introduccin
Se explica como aplicar el Proceso basado en UML, para desarrollar sistemas de informacin. Primero se deben identificar los Procesos del Negocio: que se definen como Un Objetivo estratgico de la Organizacin. Con los proceso del Negocio pretendemos identificar las actividades de alto nivel que desarrolla la empresa. Identificar buenos procesos de negocio influye en la organizacin de los diagramas UML.

Modelado de Negocio
Paso 1. Identificar los procesos de Negocio
Se listan los procesos que observamos en la organizacin, para luego abordarlos uno a uno. No confundir un subsistema de la organizacin con un proceso del negocio. Por ejem. La seccin Centro Comercial Virtual no es PN, de la empresa. Es una parte del SI, que har de intermediario entre la empresa y el cliente. Elegimos un proceso del negocio Realizar Pedidos a Proveedores
3

Descripcin del Proceso Negocio

El sistema deber realizar la solicitud automtica de productos, segn el nivel mnimo establecido para cada tipo de producto para conseguir un aprovisionamiento a nivel normal, y sujetos a las restricciones temporales, establecidas por los proveedores y comerciantes. Un operario tambin puede decidir realizar un pedido a proveedor. El sistema deber evitar la duplicidad de pedidos. Todos los pedidos han de ser aprobados, y pueden ser modificados por el responsable de abastecimiento. Este es el encargado de solucionar los conflictos que pueden aparecer como por ejemplo que un comerciante necesite un pedido lo antes posible y el proveedor no lo entregue hasta dentro de una semana. En este caso deber decidir si tramitar un pedido especial, consultado, si es necesario al comerciante.
4

Paso 2: Identificar los usuarios, departamentos o elementos de la organizacin implicados en el proceso del Negocio. El PN arranca cuando el sistema decide de forma automtica realizar un pedido a un proveedor o cuando un operario lo indica de forma explicita por lo que ambos estn jugando el rol de solicitante de perdido a proveedor. El responsable de abastecimiento: encargado de aprobar los pedidos y resolver conflictos. Proveedor: al que se le comunica un pedido aprobado.
5

 Operario: encargado de recibir los pedidos de los proveedores. Los agentes implicados en el proceso de negocios son:
Solicitante Pedido a proveedor Responsable de abastecimiento Operario Proveedor.

 Paso 3. Acciones para realizar PN.

Se describen de forma informal las interacciones entre roles (agentes) para que se cumpla el proceso de negocio con excit. Esta interaccin de roles pude ser:
El solicitante del pedido realiza un pedido en el sistema. El pedido es enviado al responsable de abastecimiento para su evaluacin. Este podr decidir modificarlo o no. Independiente de lo que haga, deber decidir si aprueba el pedido. Si lo aprueba, enviara la solicitud de pedido al proveedor. Este tramitara el pedido y lo entregara en el plazo establecido en la solicitud. Cuando llegue al centro de distribucin, un operario se encargara de registrar la llegada del pedido.

 En la secuencia anterior se puede identificar las acciones que realizan cada agente:
Solicitante pedido a proveedor
Realizar pedido a proveedor

Responsable de abastecimiento
Evaluar pedido Modificar pedido Aprobar pedido Rechazar pedido

Proveedor
Tramitar pedido

Operador
Registrar la llegada de un pedido.
8

 Diagrama de roles.
Soli.Pedido Proveedor Resp.Abaste.

Operario

Proveedor

Paso 4. Diagrama de Actividades.

10

 El Pedido fluir entre las acciones cambiando de estado. Se debe destacar que el Proveedor queda fuera de la organizacin. Aunque para tramitar un pedido se necesita conocer el pedido este conocimiento se obtendr a travs de la orden de pedido, lo que se entrega al Operario cuando se registre la llegada del pedido.
11

Paso 5: listar las actividades

La lista de actividades en proceso de negocio son:
Realizar pedido Evaluar pedido Modificar pedido Aprobar pedido Rechazar pedido Registrar llegada de pedido

12

 Se omite la accion Tramitar Pedido ya que queda fuera de nuestro sistema. Pertenece al sistema del proveedor. Cada una de las actividades esta asociada a un CU. Debemos especificar la actividades, nos ayudara a comprendelas y evitar ambigedad en los requerimientos, en una fase temprana del desarrollo.

13

Paso 6: listar las informaciones

Debemos listar las informaciones que fluyen a traves del diagrama de actividades: en el ejemplo solo hay : Pedido. Nos sera de ayuda para construir el sistema conceptual. Seguro existen mas informaciones de las que aparecen en el diagrama, solo se muestra las informaciones que intercambian acciones Se documenta las informaciones para detectar atributos en este caso Pedido tendra como atributo Producto, cantidad, proveedor.
14

Paso 7: Reglas del Negocio

Se consideran como una serie de restricciones de la organizacin ha la hora de realizar alguna actividad, o puede aparecer asociada a una informacion. En el proceso se identifican tres. Dos que afectan la forma de realizar el pedido y una que establece el modo de resolver los conflictos en los pedidos. Por lo que las reglas del negocio son:
15

 Cuando se realice un pedido a proveedor se debe especificar la cantidad necesaria para llegar al nivel normal de Stock. Debe evitarce la duplicidad de pedidos. No debe existir dos pedidos a proveedor para un mismo producto. Cuando aparesca algun conflicto en un pedido de un asociado, el reponsable consultara con el asociado la forma de resolver el conflicto: esperar a que llegue el producto, o realizar pedido especial.
16

Modelado de Requisitos
Paso 1: Identificar los CU.
Una vez realizado el modelo de negocios construimos un diagrama de CU a partir de los diagramas de Actividades. Considerar cada activida como un CU, y el agente que la realiza como el Actor del CU.

El diagrama inicial de CU seria.

17

18

 El Diagrama de CU resulta sencillo. En general a este nivel no conviene bucar realciones extend o include en los CU, a no ser que resulten evidentes. Por ejem. Si Aprovar Pedido permite modificar datos del pedido antes de su aprobacion, incluiriamos una relacion include entre Aprovar Pedido y Modificar pedido. Estas realciones iran apareciendo conforme desarollemos las plantillas de CU.
19

 Se debe evitar una descomposicion funcional del diagrama de CU. Si un CU consta de varios pasos o etapas no hay que definir un CU, para cada uno de esos pasos y una relacion include entre el CU original y los nuevos. En casos en que dos o mas CU posean una etapa comun, podemos considerar su factorizacion.
20

Paso 2: describir los casos de uso

Se usan plantillas. UML no propone ninguna, cada cual puede definir su propia plantilla siempre que use la misma todo el proyecto. Se propone una a continuacion.
Caso de Uso: Nombre de Caso de Uso Objetivo: descripcion informacion de los objetivos CU. Actores: que intervienen en el CU. Principales u secunadarios Precondicones: condiciones que deben cumplirce para realizar el CU. Pasos: secuencia de pasos para que el CU se desarrolle. Mostrar las interecciones de actores y acciones del sistema Variaciones: en la secuencia de pasos Extenciones: puntos de extencion de CU Cuestiones: planteadas durante la especificacion del CU
21

CU. Realizar Pedido

Caso de Uso: Realizar Pedido Objetivo: realizar pedido a proveedor con la cantidad necesaria del producto para conseguir un nivel de stock, evitando la duplicidad de pedidos. Actores: solicitante de pedido Precondiciones: Pasos: 1.A: indica el producto para el que se va a realizar el pedido 2.S: comprobar que no exista un pedido para ese producto 3.S: calcular la cantidad a pedir 4.S: registrar el pedido Variaciones: 2. a: existe un pedido para el producto 2.a.1 indicar error 2.a.2. Finalizar cdu (caso de uso) Extenciones: 1. Modo de realizar el pedido automatico o manual Cuestiones: 1. puede el actor modificar la cantidad calculada por el sistema
22

 El apartado referente a las extenciones nos dice que existe dos modos de realizar un pedido, automatico o manual. En automatico no se podra modificar la cantidad a pedir, en el manual si. En modo manual el actor debera confirmar el pedido. Teniendo en cuenta lo anterior aparecen dos nuevos casos de uso.
23

Caso de Uso: Realizar Pedido manual extiende Realizar Pedido Objetivo: realizar pedido a proveedor con la cantidad necesaria del producto para conseguir un nivel de stock, evitando la duplicidad de pedidos y permitiendo cierta modificacion. Actores: solicitante de pedido Precondiciones: Pasos: 1.A: indica el producto para el que se va a realizar el pedido 2.S: comprobar que no exista un pedido para ese producto 3.S: calcular la cantidad a pedir 4.A:[repetir de 0..n] modificar la cantidad a pedir 5.A: confirmar pedido 6.S: Registrar pedido Variaciones: 2. a: existe un pedido para el producto 2.a.1 indicar error 2.a.2. Finalizar cdu (caso de uso) 4 a. Cantidad introducida no esta dentro de los limites 4 a.1 no permite la modificacin Extenciones: Cuestiones:
24

Caso de Uso: Realizar Pedido automatico extiende Realizar pedido Objetivo: realizar pedido a proveedor con la cantidad necesaria del producto para conseguir un nivel de stock, evitando la duplicidad de pedidos. Actores: solicitante de pedido Precondiciones: Pasos: 1.A: indicar el producto para el que se va a realizar el pedido 2.S: comprobar que no exista un pedido para ese producto 3.S: calcular la cantidad a pedir 4.S: registrar el pedido Variaciones: 2. a: existe un pedido para el producto 2.a.1 indicar error 2.a.2. Finalizar cdu (caso de uso) Extenciones: Cuestiones
25

CU. Aprovar Pedido

Cansultando con el cliente nos dice que la comunicacin con el provedor debe realizarce por fax o por correo electronico. Lo que se pretende que el proveedor disponga de algun documento que identifique el pedido. El CU base Aprovar pedido tendra dos CU que lo extiendan. Para lo que se creara el CU comunicar pedido que tendra una relacion include con CU aprobar pedido El CU. Comunicar pedido tendra dos CU como extend.
26

Caso de Uso: Aprovar Pedido Objetivo:aprovar un pedido a proveedor y comunicar al proveedor la solicitud del pedido Actores: Responsable de abastecimiento Precondiciones: Pasos: 1.A: aprovar pedido 2.A: cdu Comunicar pedido Variaciones: Extenciones: Cuestiones

27

Caso de Uso: Comunicar Pedido Objetivo: comunicar un pedido a un proveedor Actores: responsable de abastecimiento Precondiciones: Pasos: 1.A: Comunicar Pedido Variaciones: Extenciones: Modos de comunicar con el Proveedor Cuestiones

28

Caso de Uso:Comunicar Pedido por fax extiende Comunicar Pedido Objetivo: comunicar un pedidos a un proveedor por fax Actores: Responsable de abastecimiento Precondiciones: Pasos: 1.A: comunicar pedido por fax Variaciones: 1.a. El proveedor no tiene fax 1.a.1. Indicar el error Extenciones: Cuestiones

29

Caso de Uso:Comunicar Pedido por e-mail extiende Comunicar Pedido Objetivo: comunicar un pedidos a un proveedor por e-mail Actores: Responsable de abastecimiento Precondiciones: Pasos: 1.A: comunicar pedido por e-mail Variaciones: 1.a. El proveedor no dispone de e-mail 1.a.1. Indicar el error Extenciones: Cuestiones

30

 El proceso que hemos seguido hasta el monento ha sido partir de las actividades del diagrama de actividades del PN, para construir un diagrama inicial de CU. Hemos rellenado las plantillas para cada CU, y vemos como surge nuevos CU y nuevas relaciones entre ellos. Finalmente no quedara el siguiente diagrama de casos de uso
31

32

include

33

34

 Una ves identificados todos lo CU, hay que priorizarlos. El cliente decidira la funcionalidad que se desarrollara primero Los CU en los que nos centraremos en el primer ciclo de desarrollo son:
Realizar Pedido Manual Modificar Pedido Aprovar Pedido Comunicar pedido por fax Registrar llegada de pedido
35

 Ademas se simplifican varios CU sobre el apartado variaciones. El CU Registrar llegada de Pedido supondremos que pedido llega correcto. Es importante dar prioridad a los CU y simplificarlos. Los CU guan el proceso de desarrollo. En el siguiente ciclo se tendr en cuenta las simplificaciones y se incluir los CU dejados pendiente.
36

Paso 3 Crear el modelo Conceptual

Del diagrama de actividades tomamos la lista de informaciones: en este caso es el Pedido siendo sus atributos: Proveedor, cantidad, producto. Por lo que los siguientes conceptos inicales son:
Pedido Proveedor Producto
37

 Usando la tecnica de identificacion de nombres encontramos los siguientes conceptos:

Solicitante de pedido Responsable de abastecimiento Operario Proveedor Comerciante Pedido Pedido especial Pedido asociado Producto Centro de distribucin Stock Catalogo Productos Registro de pedidos
38

 Ver las asociaciones: en este nivel del analisis no es importate encontrar todas las asociaciones. Identificaremos solo las necesarisas:
Solicitante Pedido solicita Pedido Responsable abastecimiento aprueba/rechaza/ modifica Pedido Operario registra llegada Pedido Proveedor Sirve Pedido Registro de pedido contiene Pedidos Pedido asociado - Producto
39

 Pedido especial esta sociado Pedido Asociado Pedido Asociado realizado por Asociado Centro de Distribucion posee Registro de pedidos Centro de distribucion posee Catalogo Catalogo contiene Producto Centro de distribucion posee Stock Centro de distribucion tiene contrato Proveedor Proveedor suministra - Producto
40

 Existe una relacion de generalizacion entre Pedido y Pedido Especial. Identificamos los atributosde los conceptos, en la especificaciones solo se hace referencia a los siguientes atributos
Stock: cantidad : nivel mnimo, nivel normal Pedido: cantidad Pedido Asociado: cantidad Pedido Especial: cantidad

El resto de atributos Irn apareciendo en la siguiente fase del desarrollo Se construye un glosario de trminos, donde se documenta los conceptos y atributos.
41

42