Professional Documents
Culture Documents
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
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.
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
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
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
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.
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
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
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
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