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

11

Capítulo 4Enterprise Modeling

Prof. Nelliud D. Torres

22

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)

33

CICLO DE DESARROLLO DE SISTEMAS

ANÁLISIS

MANTENIMIENTO

PLANIFICACIÓN

DISEÑO

DESARROLLOIMPLANTACIÓN

Especificaciones de Input, Output,

Processing y control

Aprobación del usuario

Pruebas, conversión, adiestramientos y documentación.

Vida útil

HCI – Human computer interface

Capítulo 2Capítulos 3 - 5

Capítulos 6 - 8

Capítulo 9 Capítulos 6 - 8

Capítulo 10

44

FASE DE ANÁLISIS

ANÁLISIS

REQUIREMENTSMODELING(Capítulo 3)

DATA AND PROCESSMODELING(Capítulo 4)

DEVELOPMENT STRATEGIES

(Capítulo 5)

55

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.

66

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.

77

Data Flow Diagrams• 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)

88

Data Flow Diagrams

• Existen dos tipos de diagramas:

• Gane and Sarson symbol set

• Yourdon symbol set

99

Data Flow Diagrams

Nosotros vamos a utilizar: Gane and Sarson

1010

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.

1111

Data Flow Diagrams - ProcessLos procesos pueden ser bien sencillos o

complejos. Algunos ejemplos pueden ser:

1. Calcular tendencia de ventas.

2. Llenar una reclamación de seguro en línea.

3. Ordenar inventario de un sistema de suplidores.

4. Verificar el e-mail de un cliente de Web.

1212

Data Flow Diagrams - ProcessEl símbolo de un proceso es un rectángulo con las

esquinas redondeadas. Otras características importantes son:

1. El nombre del proceso aparece dentro del rectángulo.

2. Identifica una función específica del sistema.3. Consiste de un verbo (y un adjetivo si hace falta)

seguido de un nombre en singular.4. Algunos ejemplos son:

• APPLY RENT PAYMENT• CALCULATE COMMISION• ASSIGN FINAL GRADE• VERIFY ORDER• FILL ORDER

1313

Data Flow Diagrams – Data flow

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:

1. Puede consistir de un solo data item (ej. número de estudiante) o un conjunto de varios datos.

2. No detalla el contenido de los datos (eso lo hace el data dictionary).

1414

Data Flow Diagrams – Data flow

1. El símbolo consiste de una línea con una flecha sencilla o doble en la punta.

2. El nombre del data flow casi siempre aparece arriba de la línea,pero puede ser abajo también.

3. El nombre consiste de un nombre singular y de un adjetivo si hace falta.

4. Algunos ejemplos de nombres son:• DEPOSIT• INVOICE• PAYMENT• STUDENT GRADE• ORDER• COMMISSION

1515

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.

1616

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)

1717

Data Flow Diagrams – Data Store

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

1818

Data Flow Diagrams – Data Store

• 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

1919

Data Flow Diagrams – Combinaciones Correctas - Data Store

2020

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.

2121

Data Flow Diagrams - Entity

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

2222

Data Flow Diagrams - Entity

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

2323

Data Flow Diagrams – Combinaciones Correctas - Entity

2424

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.

2525

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

2626

Creating a Set of DFDsGuías para dibujar el Context Diagram1. Dibuja el context diagram de modo que quepa en una

sola página.

2. Usa el nombre del sistema como el nombre del proceso inicial en el context diagram

3. Utiliza nombres únicos en cada conjunto de símbolos

4. No tires líneas que se cruzen

5. Provee un nombre y número de referencia único para cada proceso.

6. Busca insumo (input) y retroalimentación (feedback) de parte del usuario.

2727

Creating a Set of DFDsDibuja el Context Diagram de un sistema de registro

2828

Creating a Set of DFDsDibuja el Context Diagram de un sistema de orden de compra

2929

Creating a Set of DFDsDibuja el Context Diagram de un sistema de manufactura

3030


• 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

3131


• 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

3232

Diagrama 0 - Registro

3333

Diagrama 0 – Orden de Compra

3434

Diagrama 0 - Manufactura

3535


• 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

3636

Creating a Set of DFDs• Ejemplo de como descomponer el proceso 1

(FILL ORDER) del sistema de compras

3737


• 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

3838

Diagrama 0 – Sistema de Compras

Vamos a detallar este

diagrama

3939

Detalle Proceso 3 – Sistema de Compras

Mantiene los mismos data

flows anteriores en adición a los que se crean

nuevos.

4040

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

4141

Creating a Set of DFDs – Ejemplo 2En 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.

4242

Ejemplo DFD de SSS del grupo Alphasolutions

4343

Ejemplo DFD de SSS del grupo Alphasolutions

4444

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

4545

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

4646

Contenido de un Data Dictionary

4747

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

4848

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 commentsA continuación se muestra una forma que se puede utilizar para

documentar los data elements. (Pag: 168)

4949

EJEMPLO FORMA DOCUMENTAR DATA ELEMENTS

5050

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

5151

Data Dictionary

• Documentando los Data Stores– Los atributos típicos

son:• Data store name or label• Description• Alternate name(s)• Attributes• Volume and frequency

5252

Data Dictionary

• Documentando los Procesos– Los atributos típicos

son:• Process name or label• Description• Process number• Process description

5353

Data Dictionary

• Documentando las Entidades– Los atributos típicos son:

• Entity name• Description• Alternate name(s)• Input data flows• Output data flows

5454

Data Dictionary

• Documentando los Records– Los atributos típicos

son:• Record or data structure

name• Definition or description• Alternate name(s)• Attributes

5555

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.

5656

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)

5757


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

1. Sequence

2. Selection

3. Iteration - looping

5858

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.

5959

Selection• El completar uno o más pasos depende

del resultado de una prueba o condición anterior.

6060

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

6161


• 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

6262


• Structured English– Como se puede apreciar, es similar al pseudocode

6363

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

6464

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

6565

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

6666

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

6767


• 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

6868


• Four-Model Approach1. Desarrolle un modelo físico del sistema

corriente

2. Un modelo lógico del sistema corriente

3. Un modelo lógico del nuevo sistema

4. Un modelo físico del nuevo sistema– La única desventaja de este método es el

tiempo y costo adicional

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

Documents