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

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

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

FASE DE ANÁLISIS

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.

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.

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

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

Data Flow Diagrams Nosotros vamos a utilizar: Gane and Sarson

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

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 e-mail de un cliente de Web. 1

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

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

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

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.

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)

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.

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

Data Flow Diagrams – Combinaciones Correctas - Data Store

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.

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.

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.

Data Flow Diagrams – Combinaciones Correctas - Entity

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.

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

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.

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

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

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

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

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

Diagrama 0 - Registro Paso 2

Diagrama 0 – Orden de Compra Paso 2

Diagrama 0 - Manufactura Paso 2

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

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

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

Diagrama 0 – Sistema de Compras Vamos a detallar este diagrama

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

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

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.

Ejemplo DFD de SSS del grupo Alphasolutions

Ejemplo DFD de SSS del grupo Alphasolutions

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

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

Contenido de un Data Dictionary

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

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)

EJEMPLO FORMA DOCUMENTAR DATA ELEMENTS

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

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

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

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

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

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.

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)

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

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.

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

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

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

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

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

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

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

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

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

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