Capítulo 4 Enterprise Modeling Prof. Nelliud D. Torres.

Presentación del tema: "Capítulo 4 Enterprise Modeling Prof. Nelliud D. Torres."— Transcripción de la presentación:

1 Capítulo 4 Enterprise Modeling Prof. Nelliud D. Torres

2 Introducción En este capítuo se van a utilizar las técnicas enterprise modeling para desarrollar un modelo lógico del sistema propuesto y para documentar los requerimientos del sistema. Logical model – Muestra lo que el sistema debe hacer. Physical model – Describe como es que el sistema será construido. (Fase de Diseño) 4

3 CICLO DE DESARROLLO DE SISTEMAS
Capítulos 3 - 5 Capítulo 2 Aprobación del usuario Vida útil Capítulos 6 - 8 Capítulo 10 HCI – Human computer interface Pruebas, conversión, adiestramientos y documentación. Capítulos 6 - 8 Capítulo 9

4 FASE DE ANÁLISIS

5 Enterprise Modeling Tools
Los analistas de sistemas utilizan muchas técnicas gráficas para describir un Sistema de Información Dos herramientas populares son el entity-relationship diagram (Se discutirá en el capítulo 7) y el data flow diagram (DFD) Un data flow diagram (DFD) utiliza varios símbolos para mostrar como el sistema transforma datos de input en información útil.

6 Data Flow Diagrams Un data flow diagram (DFD) muestra como la data se mueve en un Sistema de Información sin mostrar pasos de lógica o de procesos. Un conjunto de DFDs muestran un modelo lógico que explica lo que el sistema hace y no como lo hace. El analista utiliza con frecuencia ayudas visuales durante las presentaciones.

7 Data Flow Diagrams 1 2 3 4 Símbolos del DFD
Los DFDs utilizan 4 símbolos básicos que representan: processes (procesos), data flows(flujo de datos), data stores (almanecamiento de datos), y entities (entidades) 1 2 3 4

8 Data Flow Diagrams Existen dos tipos de diagramas:
Gane and Sarson symbol set Yourdon symbol set

9 Data Flow Diagrams Nosotros vamos a utilizar: Gane and Sarson

10 Data Flow Diagrams - Process
Símbolos DFD Process symbol (proceso) Recibe data de input y produce output que tiene un formato o contenido diferente o ambos. Contiene la lógica del negocio también conocida como reglas (rules) Se le define también como una caja negra. 1

11 Data Flow Diagrams - Process
Los procesos pueden ser bien sencillos o complejos. Algunos ejemplos pueden ser: Calcular tendencia de ventas. Llenar una reclamación de seguro en línea. Ordenar inventario de un sistema de suplidores. Verificar el de un cliente de Web. 1

12 Data Flow Diagrams - Process
El símbolo de un proceso es un rectángulo con las esquinas redondeadas. Otras características importantes son: El nombre del proceso aparece dentro del rectángulo. Identifica una función específica del sistema. Consiste de un verbo (y un adjetivo si hace falta) seguido de un nombre en singular. Algunos ejemplos son: APPLY RENT PAYMENT CALCULATE COMMISION ASSIGN FINAL GRADE VERIFY ORDER FILL ORDER 1

13 Data Flow Diagrams – Data flow
2 Es un sendero (path) o data que se mueve de una parte a otra en un Sistema de Información. Otras características importantes son: Puede consistir de un solo data item (ej. número de estudiante) o un conjunto de varios datos. No detalla el contenido de los datos (eso lo hace el data dictionary).

14 Data Flow Diagrams – Data flow
2 El símbolo consiste de una línea con una flecha sencilla o doble en la punta. El nombre del data flow casi siempre aparece arriba de la línea,pero puede ser abajo también. El nombre consiste de un nombre singular y de un adjetivo si hace falta. Algunos ejemplos de nombres son: DEPOSIT INVOICE PAYMENT STUDENT GRADE ORDER COMMISSION

15 Data Flow Diagrams – Combinaciones correctas
Data Flow & Process Por lo menos debe entrar y salir un símbolo tipo data flow hacia y desde un símbolo process. Los procesos pueden tener más de un data flow de input o output. Un data flow debe tener por lo menos un proceso en una de sus extremidades. Un proceso se puede conectar a otro proceso a través de un data flow.

16 Data Flow Diagrams – Combinaciones INcorrectas
No puede haber un proceso con dos outputs y sin ningún input (spontaneous generation) Tampoco puede haber un proceso con dos inputs y sin ningún output (black hole) Si el input no es suficiente para generar eloutput también está incorrecto. (gray hole)

17 Data Flow Diagrams – Data Store
3 DFD Symbols Data store symbol Representa data que el sistema almacena Las características físicas del almacenamiento de los datos no es importante ya que solo estamos enfocado con el modelo lógico. Es importante almacenar los datos para referencias futuras (Ej. W2) Su almacenamiento puede durar solo segundos o años. Lo importante es destacar que más adelante algún proceso va a necesitar esos datos.

18 Data Flow Diagrams – Data Store
3 Su forma es de un rectángulo el cual está abierto en la parte derecha y cerrado en la izquierda. El nombre del Data Store aparece adentro e identifica la data que contiene. Su nombre es plural y consiste de un nombre y adjetivo si hace falta. Ejemplos de nombres pueden ser: STUDENTS ACCOUNTS RECEIVABLE PRODUCTS DAILY PAYMENTS PURCHASE ORDERS OUTSTANDING CHECKS INSURANCE POLICIES EMPLOYEES

19 Data Flow Diagrams – Combinaciones Correctas - Data Store

20 Data Flow Diagrams – Combinaciones INcorrectas - Data Store
No se pueden conectar dos data store sin que haya de intermediario un proceso. Cada data store debe tener un data flow de input y de output.

21 Data Flow Diagrams - Entity
4 DFD Symbols Entity Symbol Denota entidades externas. Estas entidades proveen data al sistema o reciben algún tipo de output. Muestra como el sistema se relaciona (interface) con el mundo exterior. También se llaman terminators debido a que originan o reciben datos. Source – La entidad suple data al sistema. Sink – La entidad recibe data del sistema.

22 Data Flow Diagrams - Entity
4 DFD Symbols Entity Symbol El símbolo es un rectángulo con sombra que de la apariencia de 3D. El nombre de la entidad aparece adentro del símbolo. Algunos ejemplos de entidades pueden ser: Cliente que somete una orden Paciente que suple de data un sistema médico Dueño de un hogar que recibe un cobro de propiedad inmueble. Sistema de cuentas a pagar que recibe datos del sistema de compras.

23 Data Flow Diagrams – Combinaciones Correctas - Entity

24 Data Flow Diagrams – Combinaciones INcorrectas - Entity
No se pueden conectar dos entidades. Una entidad tiene que estar conectada a un proceso y no directamente a un data store. Sea de input o de output.

25 Creating a Set of DFDs Se va a crear un modelo gráfico de un sistema basado en los resultados encontrados (fact finding) Se ejecutan tres tareas principales: Step 1: Dibujar un context diagram Step 2: Dibujar un diagrama 0 DFD Step 3: Dibujar los diagramas de menor nivel

26 Guías para dibujar el Context Diagram
Creating a Set of DFDs Guías para dibujar el Context Diagram Dibuja el context diagram de modo que quepa en una sola página. Usa el nombre del sistema como el nombre del proceso inicial en el context diagram Utiliza nombres únicos en cada conjunto de símbolos No tires líneas que se cruzen Provee un nombre y número de referencia único para cada proceso. Busca insumo (input) y retroalimentación (feedback) de parte del usuario.

27 Creating a Set of DFDs Paso 1
Dibuja el Context Diagram de un sistema de registro Paso 1

28 Creating a Set of DFDs Paso 1
Dibuja el Context Diagram de un sistema de orden de compra Paso 1

29 Dibuja el Context Diagram de un sistema de manufactura
Creating a Set of DFDs Dibuja el Context Diagram de un sistema de manufactura Paso 1

30 Creating a Set of DFDs Paso 2 Dibuje el Diagram 0 DFD Diagram 0
Expande el context diagram y muestra los procesos más importantes, el flujo de datos y los data storages. Tiene que mantener todas las conecciones que se definieron anteriomente (data flow) Cada proceso tiene un numero propio Diverging data flow

31 Creating a Set of DFDs Paso 2 Dibujar el Diagrama 0 DFD
Si la misma data fluye en ambas direcciones, se puede utilizar la flecha con doble cabeza. El Diagrama 0 representa una visión más amplia del proceso 0. Se establece una relación Parent – Child entre ambos diagramas. Functional primitive

32 Diagrama 0 - Registro Paso 2

33 Diagrama 0 – Orden de Compra
Paso 2

34 Diagrama 0 - Manufactura
Paso 2

35 Creating a Set of DFDs Paso 3 Dibujar los niveles de menor nivel
El analista debe ir creando niveles hasta que pueda descomponer el Sistema en todos sus procesos Debe utilizar técnicas de niveles (leveling) y balanceo (balancing) Leveling Se van detallando los DFD hasta que se describan todos los componentes del sistema Esta técnica se conoce también como exploding, partitioning, o decomposing

36 Creating a Set of DFDs Ejemplo de como descomponer el proceso 1 (FILL ORDER) del sistema de compras

37 Creating a Set of DFDs Draw the Lower-Level Diagrams Balancing
Se asegura de que los data flows de input y output del DFD padre (parent) se siguen manteniendo en el DFD hijo (child) A continuación se muestra un ejemplo

38 Diagrama 0 – Sistema de Compras
Vamos a detallar este diagrama

39 Detalle Proceso 3 – Sistema de Compras
Mantiene los mismos data flows anteriores en adición a los que se crean nuevos.

40 Creating a Set of DFDs – Ejemplo 2
Contex Diagram de un Sistema. Tiene dos inputs y dos outputs data flow

41 Creating a Set of DFDs – Ejemplo 2
En el próximo nivel se puede observar que se mantienen los data flows originales y se crean cuatro data flows internos, dos data store y tres procesos.

42 Ejemplo DFD de SSS del grupo Alphasolutions

43 Ejemplo DFD de SSS del grupo Alphasolutions

44 Data Dictionary Un data dictionary, o data repository, es un central storehouse de información relacionada a la data del sistema Un analista utiliza el data dictionary para colectar, documentar y organizar factores en específicos del sistema. También define y describe todos los data elements y sus combinaciones significativas con otros data elements

45 Data Dictionary Un data element, también llamado un data item o campo (field), es el componente de data menor que tiene significado en el sistema Los data elements se combinan para componer records, también llamados data structures Un record es una combinación significativa de data elements relacionados que se mencionan en los data flows y en los data store

46 Contenido de un Data Dictionary

47 Data Dictionary Documentando los Data Elements
Se debe documentar cada data element en el data dictionary El objetivo es proveer información clara y comprensiva sobre los datos y procesos que componene el sistema

48 Data Dictionary Documentando los Data Elements
Los siguientes atributos usualmente se incluyen en la documentación Data element name or label Alias Type and length Default value Acceptable values - Domain and validity rules Source Security Responsible user(s) Description and comments A continuación se muestra una forma que se puede utilizar para documentar los data elements. (Pag: 168)

49 EJEMPLO FORMA DOCUMENTAR DATA ELEMENTS

50 Data Dictionary Documentando los Data Flows Los atributos típicos son:
Data flow name or label Description Alternate name(s) Origin Destination Record Volume and frequency

51 Data Dictionary Documentando los Data Stores
Los atributos típicos son: Data store name or label Description Alternate name(s) Attributes Volume and frequency

52 Data Dictionary Documentando los Procesos Los atributos típicos son:
Process name or label Description Process number Process description

53 Data Dictionary Documentando las Entidades Los atributos típicos son:
Entity name Description Alternate name(s) Input data flows Output data flows

54 Data Dictionary Documentando los Records Los atributos típicos son:
Record or data structure name Definition or description Alternate name(s) Attributes

55 Data Dictionary Data Dictionary Reports
Puede generar muchos reportes importantes: Todos los data elements en orden alfabético por nombre. Reporte que describe cada data element e indica el usuario o departamento responsable de entrar el dato, actualizarlo o eliminarlo Reporte de todos los data flows y data stores que utilizan un data element en particular Reporte detallado que muestre todas las caracteristicas de los data elements, records, data flows, processes, o cualquier otro item del data dictionary.

56 Process Description Tools
Un process description documenta los detalles de un functional primitive (el proceso mas pequeño de un DFD), y representa un conjunto específico de pasos relacionados a la lógica del negocio (business logic)

57 Process Description Tools
Modular Design Se basa en la combinación de tres estructuras lógicas también llamadas control structures que sirven como definiciones claves (building blocks) para el proceso. Las tres estructuras son: Sequence Selection Iteration - looping

58 Sequence Completa los pasos en orden secuencial uno detras del otro. Uno o más de esos pasos puede representar un sub-proceso que contenga estructuras (instrucciones) lógicas adicionales.

59 Selection El completar uno o más pasos depende del resultado de una prueba o condición anterior.

60 Iteration - looping El completar una serie de pasos que se repiten hasta que una condición en particular cambia.

61 Process Description Tools
Structured English Debe seguir las siguientes reglas: Solo utilizar las tres estructuras anteriores Utilizar indentación para mayor claridad Utilizar un vocabulario limitado que incluya termninos estandar y palabras específicas que describan las reglas de procesamiento

62 Process Description Tools
Structured English Como se puede apreciar, es similar al pseudocode

63 Process Description Tools
Decision Tables Muestra una estructura lógica con todas las posibles combinaciones de condiciones y resultados (accciones) Es importante considerar cada posible resultado para asegurarse de que se cubrieron todas las posibilidades

64 Process Description Tools
Decision Tables Debe tener más de dos posibles resultados En muchas ocasiones es la mejor forma de evaluar un grupo complejo de condiciones

65 Process Description Tools
Decision Trees Representación gráfica de las condiciones, acciones y reglas que se encuentran en un decision table Si se va a utilizar un decision table o un decision tree es cuestión de preferencia

66 Logical Versus Physical Models
Mientras que estas herramientas (tools) se utilizan para desarrollar modelos lógicos para un nuevo sistema, también se pueden utilizar para desarrollar modelos físicos de un sistema nuevo de información. Recordatorio – Un modelo físico muestra como los requerimientos del sistema son implementados

67 Logical Versus Physical Models
Sequence of Models Muchos analistas crean el modelo físico del sistema corriente y luego crean un modelo lógico también del sistema corriente antes de crear el modelo lógico del nuevo sistema. El hacer estos pasos extra, le ayuda al analista a entender mejor como funciona el sistema actual

68 Logical Versus Physical Models
Four-Model Approach Desarrolle un modelo físico del sistema corriente Un modelo lógico del sistema corriente Un modelo lógico del nuevo sistema Un modelo físico del nuevo sistema La única desventaja de este método es el tiempo y costo adicional