1

Un Proceso Basado en UML para Sistemas de Información.

Lic. Espìnoza Robles Armando David.

2

Introducción• Se explica como aplicar el Proceso basado en

UML, para desarrollar sistemas de información.• Primero se deben identificar los Procesos del

Negocio: que se definen como “Un Objetivo estratégico de la Organización”.

• Con los proceso del Negocio pretendemos identificar las actividades de alto nivel que desarrolla la empresa.

• Identificar buenos procesos de negocio influye en la organización de los diagramas UML.

3

Modelado de Negocio• Paso 1. Identificar los procesos de Negocio

– Se listan los procesos que observamos en la organización, para luego abordarlos uno a uno.

– No confundir un subsistema de la organización con un proceso del negocio. Por ejem. La sección “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”

4

Descripción del Proceso Negocio

• El sistema deberá realizar la solicitud automática de productos, según el nivel mínimo 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 también 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.

5

Paso 2: Identificar los usuarios, departamentos o elementos de la organización implicados en el

proceso del Negocio.

• El PN arranca cuando el sistema decide de forma automática realizar un pedido a un proveedor o cuando un operario lo indica de forma explicita por lo que ambos están 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.

6

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

7

• 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 interacción de roles pude ser:• El solicitante del pedido realiza un pedido en el sistema. El

pedido es enviado al responsable de abastecimiento para su evaluación. 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 distribución, un operario se encargara de registrar la llegada del pedido.

8

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

9

• Diagrama de roles.

Soli.PedidoProveedor

Resp.Abaste.

ProveedorOperario

10

Paso 4. Diagrama de Actividades.

11

• El Pedido fluirá entre las acciones cambiando de estado.

• Se debe destacar que el Proveedor queda fuera de la organización. Aunque para tramitar un pedido se necesita conocer el pedido este conocimiento se obtendrá a través de la orden de pedido, lo que se entrega al Operario cuando se registre la llegada del pedido.

12

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

13

• 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 ambigüedad en los requerimientos, en una fase temprana del desarrollo.

14

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.

15

Paso 7: Reglas del Negocio

• Se consideran como una serie de restricciones de la organización 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:

16

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

17

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.

18

19

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

20

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

21

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

22

CU. Realizar PedidoCaso 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

23

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

24

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 modificación

Extenciones:

Cuestiones:

25

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

26

CU. Aprovar Pedido

• Cansultando con el cliente nos dice que la comunicación 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.

27

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

28

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

29

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

30

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

31

• 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

32

33

include

34

35

• 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

36

• 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 guían el proceso de desarrollo. En el siguiente ciclo se tendrá en cuenta las simplificaciones y se incluirá los CU dejados pendiente.

37

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

38

• 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 distribución– Stock– Catalogo Productos– Registro de pedidos

39

• 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

40

– 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

41

• 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 mínimo, nivel normal

– Pedido: cantidad

– Pedido Asociado: cantidad

– Pedido Especial: cantidad

• El resto de atributos Irán apareciendo en la siguiente fase del desarrollo

• Se construye un glosario de términos, donde se documenta los conceptos y atributos.

42