universidad de colima sistema de nomina basado en la

Universidad de Colima

SISTEMA DE NOMINA BASADO EN LA METODOLOGIA DE COAD

& YOURDON

Tesis para obtener el grado de

MAESTRO EN CIENCIAS AREA COMPUTACION

Presenta

Mario Alberto Lugo Rivero

Asesor

Dr. Nicandro Farías Mendoza

Colima, col. 27 de Agosto de 2003

EXPEDIENTE: 595 NUM. 98-0384

C. MARIO ALBERTO LUGO RIVERO Domicilio: AV. PABLO SILVA GARCIA NO. 535 Localidad: VILLA DE ALVAREZ Teléfono: 3 1-3-3289

Informo a usted que ha sido aprobado como tema de titulación para obtener el grado de

MAESTRO EN CIENCIAS AREA COMPUTACIÓN

El solicitado por usted bajo el título:

“SISTEMA DE NOMINA BASADO EN LA METODOLOGÍA DE COAD & Y OURDON”

Desarrollado bajo los siguientes puntos:

I INTRODUCCION II ANTECEDENTES HISTORICOS III HERRAMIENTAS DE MODELADO IV EL MODELO ESENCIAL DE EMPRESA V LA RELACION ENTRE EL SISTEMA Y LA EMPRESA VI EL MODELO ESENCIAL DE SISTEMA VII CONCLUSIONES

BIBLIOGRAFÍA

Al mismo tiempo informo a usted que ha sido designado como asesor de titulación al C. DR. NICANDRO FARIAS MENDOZA

En cada uno de los ejemplares de titulación que presente para examen, deberá aparecer en primer término copia del presente oficio.

A T E N T A M E N T E ESTUDIA * LUCHA * TRABAJA

Coquimatlán, Col., 27 de agosto del 2003.

M.C. RICARDO FUENTES COVARRUBIAS DIRECTOR

c.c.p.-EXPEDIENTE ALUMNO.

Km 9 Carretera Colima-Coquimatlán, Colima, Colima, México, C.P. 28400 Tel. 01 (312) 316 11 65, Ext. 51451, Ext. Fax 51454.Exp. No.: 595

Exp. No.: 595 Fecha: 26 de agosto de 2003 Acta No.:_______________

C. MARIO ALBERTO LUGO RIVERO Domicilio: AV. PABLO SILVA GARCIA NO. 535 Localidad: VILLA DE ALVAREZ Teléfono: 3 l-3-3280

En cumplimiento al artículo: 13 y 14 del reglamento de titulación, al artículo 40, Inciso A del reglamento de estudios de Posgrado vigente y al artículo: 46 de las normas complementarias al reglamento de Posgrado, correspondientes al Posgrado de la Facultad de Ingeniería Mecánica y Eléctrica. Informamos a usted que ha sido autorizado por este Consejo Técnico del Posgrado su tema de Tesis para obtener el grado de Maestro en Ciencias Área: Computación titulado: “SISTEMA DE NOMINA BASADO EN LA METODOLOGÍA DE COAD & YOURDON” para ser desarrollado bajo los siguientes puntos:

I INTRODUCCION II ANTECEDENTES HISTORICOS III HERRAMIENTAS DE MODELADO IV EL MODELO ESENCIAL DE EMPRESA V LA RELACION ENTRE EL SISTEMA Y LA EMPRESA VI EL MODELO ESENCIAL DE SISTEMA VII CONCLUSIONES VIII BIBLIOGRAFÍA

Así mismo hacemos de su conocimiento que de acuerdo con la línea de

investigación en la cual se enmarca su proyecto ha sido autorizado como asesor de tesis al C. DR. NICANDRO FARIAS MENDOZA

A partir de la fecha de aprobación tendrá como plazo un año para presentar su examen de grado, en caso contrario tendrá usted derecho a una prórroga única de seis meses so pena de perder el registro de su proyecto.

Una vez concluidos los trámites de revisión de su documento de tesis e integrado su expediente de titulación deberá recoger el oficio que acompañará el visto bueno de su asesor de tesis, los cuales encabezarán cada uno de los ejemplares de su tesis.

A T E N T A M E N T E

El Consejo Técnico del Posgrado de la Facultad de Ingeniería Mecánica y Eléctrica de la Universidad de Colima. _______________________________________________ ______________________________________ M.C. ANDRES GERARDO FUENTES COVARRUBIAS M.C. RICARDO FUENTES COVARRUBIAS _________________________________________ _____________________________________ M.C. VICTOR HUGO CAS T ILLO TOPETE M.C. RODOLFO GALLARDO ROSALES.

FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA CONSEJO TÉCNICO DE LA MAESTRÍA EN COMPUTACIÓN PRESENTE.

Tomando como base la revisión del trabajo recepcional del C. Lic. Mario Alberto Lugo Rivero, titulado: SISTEMA DE NOMINA BASADO EN LA METODOLOGÍA DE COAD & YOURDON, informo a este Consejo que el Lic. Mario Alberto, cumplió con los requisitos de forma y fondo requeridos para la sustentación de su examen de grado.

Agradeciendo de antemano la atención prestada al presente, quedo a sus apreciables órdenes para cualquier aclaración.

A T E N T A M E N T E ESTUDIA*LUCHA*TRABAJA

COQUIMATLÁN, COL. 14 DE AGOSTO DE 2003

C.C.P. Interesado C.C.P. Archivo

AGRADECIMIENTOS

A MIS PADRES : A MIS HERMANOS : Con todo cariño, respeto Que aunque lejos, siempre y el sacrificio de no contar con me impulsaron a seguir ellos en virtud de vivir lejos de a seguir adelante. mí, siempre me brindaron su apoyo para seguir adelante.

A MI ESPOSA E HIJAS : Con las que compartí momentos de desesperación, angustia y también alegría; pero lo más importante, su apoyo cuando más lo necesitaba. A MI ESCUELA : A TI USUARIO : Gracias por recibirme y Cuando consultes este Cobijarme durante dos trabajo, espero te sirva largos años y contribuir algo de lo escrito en a una mejor superación esta investigación. personal.

INDICE GENERAL

RESUMEN EN ESPAÑOL............................................................................. 1

RESUMEN EN INGLES ............................................................................... 2

1. INTRODUCCION .................................................................. 3

2. ANTECEDENTES HISTORICOS ........................................... 10

2.1 Introducción........................................................................................ 12

2.2 Marco conceptual................................................................................ 27

2.3 Otras metodologías............................................................................. 29

3. HERRAMIENTAS DE MODELADO ....................................... 40

3.1 Introducción........................................................................................ 40

3.2 Diagrama de entidad – relación............................................................ 47

3.3 Diagrama de transición entidad – estado.............................................. 53

3.4 Diagrama de contexto.......................................................................... 59

3.5 Diagrama de flujo de datos.................................................................. 61

4. EL MODELO ESENCIAL DE EMPRESA ................................. 86

4.1 Introducción....................................................................................... 86

4.2 Estructura del modelo esencial de empresa........................................... 89

4.3 Estrategias para la construcción y mantenimiento del EIA...................... 93

4.4 Heurística para construir y refinar el EIA............................................... 94

4.5 Mantenimiento del aspecto de información de la empresa.................... 109

5. LA RELACION ENTRE EL SISTEMA Y LA EMPRESA .......... 114

5.1 Introducción..................................................................................... 114

5.2 Iniciación del proyecto de sistema....................................................... 118

5.3 Construcción del modelo esencial de empresa...................................... 123

6. EL MODELO ESENCIAL DE SISTEMA ................................ 128

6.1 Introducción...................................................................................... 128

6.2 Estructura del modelo esencial de sistema........................................... 133

6.3 Aspectos del modelo esencial de sistema............................................. 134

6.4 Aspecto de información...................................................................... 135

6.5 Aspecto ambiental............................................................................. 137

6.6 Aspecto funcional.............................................................................. 139

6.7 Aspecto de ejecución......................................................................... 140

7. CONCLUSIONES ............................................................... 142

8. BIBLIOGRAFIA .................................................................147

Sistema de Nómina basado en la metodología de Coad Yourdon

Método del sistema de Yourdon: (YSM)

1

Resumen en Español

Según Kendall y Kendall [3], fue la aparición del diseño y la programación

estructurada alrededor de los años 60´s e inicios de los 70’s, la que dieron cabida

al surgimiento del análisis estructurado, ya que existía la necesidad de utilizar una

notación gráfica para representar los datos y los procesos que los transforman".

Es por ello que surgen una serie de temas afines tales como: herramientas

automatizadas (CASE), prototipos, diagramas de entidad - relación etc. Pero las

preguntas que todos nos hacemos: ¿qué nos espera en un futuro no muy lejano

del análisis estructurado con la introducción de nuevas variantes? ¿desaparecerá o

se mantendrá?.

También según Seen [4] surge de la necesidad de buscar una forma interpretativa

más rápida y eficiente, de tal forma que se pudiesen definir los requerimientos del

usuario y las especificaciones funcionales del sistema. Pero esto no se daba

porque lo que existía eran grandes volúmenes de información que había que leer

por completo y que traían como consecuencia una serie de problemas de

monolismo, redundancia, ambigüedad e imposibilidad de mantener. Es por ello

que surge una amplia variedad de diagramas que permiten representar las

especificaciones funcionales en forma sencilla y rápida, aumentando con ello el

grado de comunicación entre las especificaciones funcionales y el usuario final

(analista, programador, diseñador). El análisis estructurado se ha transformado en

una de las metodologías más divulgadas hoy en día. Para conceptuar esta

herramienta de apoyo a dicha metodología, se estudia el análisis de sistemas

como etapa del desarrollo de un sistema, así como también su contexto bajo el

enfoque sintético.

Los requerimientos de automatización se derivan de los objetivos del análisis de

sistemas. Específicamente tienen relación con la consistencia, exactitud yen forma

completa, intra e inter componentes del modelo de la especificación estructurada.



2

Resumen en Inglés

According to Kendall and Kendall [3], it was the appearance of the design and the

programming structured around the 60´s and beginning of the 70's, that gave

entrance to the emergence of the structured analysis, since the necessity existed

of using a graphic notation to represent data and the processes that transform

them. For that reason, arise a series of topics such as: automated tools (CASE),

prototypes, entity diagrams - relationship etc. But the questions that we ask

ourselves is: what awaits for us in the near future of the structured analysis with

the introduction of new variants? Will it disappear or will it remain?

Also according to Seen [4] arises the necessity of searching for a quicker and

more efficient interpretive form, in such a way that can be defined by the user's

requirements and the systems functional specifications. But this was not given

because what did exist was big volumes of information that were necessary to be

completely read and that resulted in a series of monolism problems, redundancy,

ambiguity and impossibility of maintaining. For this reason arises a wide variety of

diagrams that allow you to represent the functional specifications in simple and

quick form, increasing the communication grade between the functional

specifications and the final user (analyst, programmer, designer). The structured

analysis has become one of the methodologies more disclosed today in day. To

consider this support tool to this methodology, it is studied the analysis of systems

like stage of the development of a system, as well as their low context the

synthetic focus.

The automation requirements are derived of the objectives of the analysis of

systems. Specifically they have a consistency relationship, accuracy and complet,

intra and inter components of the pattern of the structured specification.



3

CAPITULO 1

INTRODUCCION

Propósito del trabajo de investigación

Este trabajo de investigación describe “El Método del Sistema de Yourdon” (o

YSM) y la manera de cómo puede ser utilizado para el soporte y desarrollo de

sistemas. Provee de un informe definitivo de lo que constituye YSM en términos

de modelos, herramientas y métodos.

Lo que no contempla este trabajo de investigación

No intenta actuar como un libro de texto o documento de adiestramiento, no sería

apropiado para ninguno de los dos casos. Tampoco trata de que sea leído en

forma secuencial, pero sí como una referencia sobre tópicos individuales tal como

una herramienta específica de modelado, modelo o técnica.

Versión del trabajo de investigación

Es la primera parte del manual de referencia de YMS. Abarca el análisis de

requerimientos de sistemas e información del mundo real. Partes adicionales,

cubrirán la implementación de los modelos, la planeación estratégica, las pruebas

específicas y la calidad asegurada.

De ninguna manera intenta de definir la posición de YSM en todos los tópicos del

desarrollo y mantenimiento de sistemas. Este estudio trata de consolidar las ideas

utilizadas en cuanto a la enseñanza y la cultura.

Introducción



4

Alcance o cobertura de este trabajo

YSM contempla lo siguiente:

• Las actividades de la empresa y el manejo de los

recursos. Una empresa es cualquier unidad económica

que cuenta con recursos y que es manejada como una

unidad. Una empresa puede constituir toda la empresa,

una parte de la misma o bien un informe del manejo

específico. YSM provee de modelos para capturar y

mantener los requerimientos de la empresa.

• Modelando sistemas. Un sistema es parte de la

empresa. Estos a su vez, usualmente tienen un ciclo de

vida obviamente más corto que la propia empresa. Son

construidos, modificados y eventualmente reemplazados.

YSM provee modelos de sistemas que pueden ser

utilizados para producir sistemas de calidad en tiempo y

presupuesto.

Características adicionales del método

El principal cambio que presenta ha sido una teoría más rigurosa con respecto al

método. Esto a su vez permitirá asegurarse de una mejor calidad y soporte para

las herramientas CASE.

Dos nuevas características del método es el ciclo de vida de las entidades y

los tipos de dato abstractos.

Introducción



5

Organización del trabajo de investigación

Este trabajo está dividido en los siguientes capítulos:

1. Introducción: Contempla los antecedentes históricos y

las principales características de YMS.

2. Herramientas de modelado: Describe la gráfica y las

herramientas de modelado textual que se utilizan para

construir modelos.

3. El modelo esencial de empresa: Describe cuáles son

los requerimientos de la empresa que van a ser

modelados.

4. La relación entre el sistema y la empresa: Describen

cómo los proyectos de sistemas hacen uso de los recursos

de la empresa.

5. El modelo esencial de sistema: Describe cómo un

modelo esencial es construido para capturar los

requerimientos del sistema.

Tipografía utilizada en la investigación

Las siguientes convenciones han sido utilizadas en nuestro caso de estudio:

• Los modelos de componentes están en doble comillas por

ejemplo: “captura de empleados”.

• Los términos técnicos están con comilla simple, ejemplo:

‘fuera – de’.

• Los ejemplos son mostrados en cajas sombreadas para los

fragmentos de texto en el modelo. Por ejemplo:

Introducción



6

• Los ejemplos largos para especificar herramientas de

modelado, están dados por dobles cajas. Por ejemplo:

Pre – condición Empleado <pertenece> Dependencia

Introducción



7

El Ayuntamiento de Colima se caracteriza por ser una institución que se encarga

de la prestación de servicios a la sociedad en general, éstos a su vez pueden ser

proporcionados de manera interna o externa; es decir, al público en general y a

los recursos humanos que la conforman.

Una de sus funciones internas principales es el pago de la nómina a sus

trabajadores. Para poder hacerlo de una manera eficiente y oportuna, hace uso de

un sistema el cual fue desarrollado de acuerdo a las necesidades de la misma. Sin

embargo, con el transcurrir del tiempo y el avance tecnológico que se tiene día

con día en cuanto a hardware y software, ha rebasado las expectativas actuales

en cuanto a funcionamiento y operatividad.

Debido a la ineficiencia que se tiene en cuanto al funcionamiento de este sistema

nos hemos propuesto actualizar el mismo, haciendo uso de la metodología de

Coad Yourdon y hacer un nuevo planteamiento del mismo para así poder lograr un

mejor diseño y desarrollo funcional de acuerdo a las necesidades que se tienen en

materia de información, logrando con esto una mayor eficiencia en la prestación

de dichos servicios e ir a la vanguardia con la tecnología que contamos

actualmente.

Tradicionalmente, el análisis es visto como la definición de los requisitos del

sistema. Por otro lado, el diseño establece una arquitectura para el software tal

que satisfaga dichos requisitos y permita una posterior implementación ajustada a

ciertos criterios de calidad. Dicho de otro modo, el análisis detalla el qué mientras

que el diseño desarrolla el cómo.

El Diseño Estructurado tuvo sus comienzos con la Programación Estructurada (la

cual incorporaba las tres estructuras de control básicas de un programa:

secuencia, selección e iteración). El aporte del Diseño Estructurado fue considerar

el concepto de módulo y la propiedad de modularidad de los sistemas

resultantes como atributo que caracterizaba la calidad de los mismos.

Introducción



8

El Análisis Estructurado aparece como complemento al Diseño Estructurado. Por lo

tanto, el propósito del Análisis Estructurado es proveer una técnica de análisis que

permita una adecuada transición hacia el Diseño Estructurado. El Análisis

Estructurado está basado en el modelado de flujos de información y su

transformación mediante procesos, es decir, el analista se preocupa

fundamentalmente de las funciones que debe llevar a cabo el sistema.

Las propuestas iniciales de Análisis y Diseño Estructurado se centraban en el

modelado de procesos dejando en segundo término el modelado de datos. El

Enfoque Estructurado Moderno sugiere realizar paralelamente el modelado de

procesos y de datos (este último mediante Diagramas Entidad-Relación y

modelado relacional de datos). En este documento nos concentraremos en el

modelado de procesos en SA.

Objetivos:

a) Maximizar la calidad del modelo actual

b) Maximizar la calidad de la especificación con respecto a los

requerimientos de la función de los usuarios.

Si se logra el objetivo de poner en marcha esta nueva metodología aunado con su

propio desarrollo e implantación, tendremos como logro fundamental eliminar

todas aquellas deficiencias que se vienen arrastrando con el uso del sistema

anterior y por consiguiente hacer que la Dirección de Recursos Humanos del

Ayuntamiento de Colima contribuya a mejorar los servicios que proporciona y con

ello ir a la vanguardia con los avances tecnológicos que se tienen día con día en

cuanto a sistemas de información se refiera y por ende contribuir a proporcionar

los servicios de una manera más rápida, eficiente, en le menor tiempo posible y

con el mínimo esfuerzo.

Introducción



9

Actualmente esta institución, cuenta con toda la tecnología suficiente para

soportar todos los cambios que se requieran y de ahí la importancia de lograr un

mejor desarrollo del mismo y tener como consecuencia un mejor funcionamiento

de acuerdo a las exigencias actuales y la realidad que se vive día con día.

Introducción



10

CAPITULO 2

ANTECEDENTES HISTORICOS

2.1 Introducción

Etapas en los métodos del desarrollo de sistemas

La evolución de los métodos en el desarrollo de sistemas ha sido gradual y mucha

gente ha contribuido para lograr un mejoramiento y por consiguiente, un mayor

funcionamiento. Conforme fueron evolucionando los métodos en el desarrollo de

sistemas, estos fueron agrupados en 3 etapas las cuales son las siguientes:

Ø Métodos de la primera generación

Ø Métodos de la segunda generación

Ø Métodos de la tercera generación

Método de la primera generación 1951-1958

Las computadoras de esta generación emplearon bulbos para procesar

información. Los operadores ingresaban los datos y programas en código especial

por medio de tarjetas perforadas. El almacenamiento interno se lograba con un

tambor que giraba rápidamente, sobre el cual un dispositivo de lectura/escritura

colocaba marcas magnéticas. Esas computadoras de bulbos eran mucho más

grandes y generaban más calor que los modelos contemporáneos. Eckert y

Mauchly contribuyeron al desarrollo de computadoras de la 1era Generación

formando una compañía privada y construyendo UNIVAC I que el Comité del

censó utilizó para evaluar el de 1950. La IBM tenía el monopolio de los equipos de

procesamiento de datos con base a tarjetas perforadas y estaba teniendo un gran

auge en productos como rebanadores de carne, básculas para comestibles, relojes

Antecedentes Históricos



11

y otros artículos; sin embargo no había logrado el contrato para el Censo de 1950.

Comenzó entonces a construir computadoras electrónicas y su primera entrada

fue con la IBM 701 en 1953.

Después de un lento pero excitante comienzo la IBM 701 se convirtió en un

producto comercialmente viable. Sin embargo en 1954 fue introducido e l modelo

IBM 650, el cual es la razón por la que IBM disfruta hoy de una gran parte del

mercado de las computadoras. La administración de la IBM asumió un gran riesgo

y estimó una venta de 50 computadoras. Este número era mayor que la cantidad

de computadoras instaladas en esa época en E.U. De hecho la IBM instaló 1000

computadoras. El resto es historia.

Aunque caras y de uso limitado las computadoras fueron aceptadas rápidamente

por las Compañías privadas y de Gobierno. A la mitad de los años 50 IBM y

Remington Rand se consolidaban como líderes en la fabricación de computadoras.

Esta etapa puede ser comparada con varias “técnicas estructuradas” de desarrollo

durante los años 1960s y 1970s. Estas técnicas rompieron el problema complejo

que había en los componentes pequeños, mediante relaciones internas bien

definidas entre los componentes. En la actualidad mucha gente todavía confía en

esta técnica como herramienta modeladora.

PROGRAMACION ESTRUCTURADA

Secuencia, selección, iteración y evitando el uso de “GOTO”.




12

La primera técnica estructurada contribuyó a una mejor organización del código

fuente.

Estas a su vez usan construcciones estándar, las cuales pueden ser usadas o

implementadas por cualquier algoritmo. Estos programas son construidos

utilizando bloques de ‘secuencia’, ‘selección’ e ‘iteración’.

A su vez estas construcciones estándar fueron reconocidas, sin embargo no todos

los lenguajes de programación que se usan lo soportan.

DISEÑO MODULAR Y DIAGRAMAS DE ESTRUCTURA

Además de estas construcciones, muchos lenguajes de programación permitieron

que grupos de sentencias fueran reutilizadas. Una parte de estos es llamado:

“Programa Modular” y su uso es referido como “programación o diseño modular”.

Los diagramas de estructura fueron usados para mostrar el sentido en que los

módulos son conectados al programa.

ESTILOS DE PROGRAMACION

A menudo se usan construcciones estándar sin embargo, el código sería complejo

y dificultaría su comprensión o bien, simple y fácil de entender. Este es un estilo

poco usual por su salida tardía en los años 70s. Las técnicas de diseño datos que

se usaron en los años 70s, fueron en su mayoría costumbres pragmáticas de

construcción de estructuras de datos y archivos para programas de soporte.

La organización CODASYL fue una importante influencia en la formulación de ideas

sobre diseño de base de datos, durante el período de 1967 a 1972. En particular

se definió el modelo abstracto para una red de base de datos.




13

DISEÑO ESTRUCTURADO

Alcance Limitado de la Programación Estructurada.

Las técnicas de programación estructurada solo son dirigidas al “diseño en

pequeño”. Esta como declaración individual sería organizada entre un modelo y

una empresa de aceptación. Este tipo de diseño se hizo a largo plazo, por lo tanto,

fueron diseñados para solucionar este problema.

Estas formas de programar fueron usadas para simples y largos proyectos de

software, conteniendo muchos componentes. Al igual que los principales diseños

de sistemas apropiados, existe todavía un camino en el cual un proyecto pudo

faltar y hacer conveniente los requerimientos de usuario. Para sistemas pequeños,

el requerimiento puede ser entendido por una persona, quien tomó la

responsabilidad para asegurase que el requerimiento fue el conveniente. Aún

cuando no hubo garantía los requerimientos fueron correctamente entendidos.

Con tales problemas, el fracaso o el buen éxito del proyecto comienza como un

motivo casual.

Antecedentes Históricos.



14

Modelado de información

Al mismo tiempo que las técnicas de análisis estructurado fueron desarrolladas,

una aproximación semántica de modelado de información fue formulada. Esta se

basó en entidades y relaciones del mundo real. Sin embargo, el acercamiento de

este modelado de datos fue en los años 70s y es todavía una tecnología basada y

orientada en relaciones y estructuras de red. También existieron diferentes

filosofías en el desarrollo de sistemas así como procesos y métodos en cuanto al

manejo de datos. Durante la primera generación de métodos estructurados,

analistas y diseñadores tendieron a ser uno u otro:

♦ Procesos – orientados: concentrando funciones de

sistemas en lo que respecta a los datos existentes para

soportar dichas funciones.

♦ Datos – orientados: Concentrando requerimientos de

información, particularmente en términos de identificación

de datos a ser almacenados en la base de datos. Las

funciones de sistemas fueron consideradas a ser las menos

importantes.

A pesar de la evidencia en el control de grandes proyectos, éstos fueron muy

difíciles y costosos; Las técnicas estructuradas fueron avanzando lentamente y

fueron conocidas en forma general y utilizadas hasta los años 80s.




15

Método de la segunda generación 11995599--11996644

Transistor Compatibilidad limitada. El invento del transistor hizo posible una nueva

generación de computadoras, más rápidas, más pequeñas y con menores

necesidades de ventilación. Sin embargo el costo seguía siendo una porción

significativa del presupuesto de una Compañía. Las computadoras de la 2da.

generación también utilizaban redes de núcleos magnéticos en lugar de tambores

giratorios para el almacenamiento primario. Estos núcleos contenían pequeños

anillos de material magnético, enlazados entre sí, en los cuales podrían

almacenarse datos e instrucciones. Los programas de computadoras también

mejoraron. El COBOL desarrollado durante la 1era generación estaba ya disponible

comercialmente. Los programas escritos para una computadora podían

transferirse a otra con un mínimo esfuerzo. El escribir un programa ya no requería

entender plenamente el hardware de la computación.

Las computadoras de la 2da Generación eran substancialmente más pequeñas y

rápidas que las de bulbos, y se usaban para nuevas aplicaciones, como en los

sistemas para reservación en líneas aéreas, control de tráfico aéreo y simulaciones

para uso genera. Las empresas comenzaron a aplicar las computadoras a tareas

de almacenamiento de registros, como manejo de inventarios, nómina y

contabilidad. La marina de E.U. utilizó las computadoras de la Segunda Generación

para crear el primer simulador de vuelo (Whirlwind I). HoneyWell se colocó como

el primer competidor durante la segunda generación de computadoras. Burroughs,

Univac, NCR, CDC, HoneyWell, los más grandes competidores de IBM durante los

60s se conocieron como el grupo BUNCH (siglas). La segunda generación también

se caracteriza por haber un mayor acercamiento al modelado de sistemas. En la

primera generación los métodos desarrollados fueron procesos – orientados o

datos – orientados y usando modelados en una vía justamente informal. En

todos los métodos de la segunda generación el esfuerzo principal que se hizo, fue

la construcción y el chequeo de los modelos.




16

En los métodos de la primera generación, los sistemas desarrollados tendieron a

ser modelos desde un punto de vista con modelado relativamente pobre desde

otro punto de vista es decir, fase – orientada o modelo orientado. En los

métodos de la segunda generación se consideraron funciones de sistemas y datos

como dos aspectos igualmente importantes del mismo sistema. El uso de software

de computadora ayudó en la construcción de sistemas que no fueron comunes

hasta los años 80s. Aunque tales herramientas empezaron a estar disponibles

desde 1975. A mediados de los 80s la demanda de esta herramienta de

incrementó grandemente. Actualmente estos productos son conocidos como

herramientas (CASE).

CASE en la segunda generación

En la segunda generación las técnicas que se utilizaban eran principalmente

“Diagramas orientados”. En otras palabras la unidad de modelado es un

diagrama. Los diagramas son dibujados y checados. Los componentes de los

diagramas son especificados. Son revisados otra vez uno a otro. Un ejemplo de

esto se muestra a continuación, con 4 modelos de componente.

Componente A

Componente B

Componente C

Componente D




17

El modelo de componentes aparece en muchas especificaciones, es redundante y

difícil de controlar. Las reglas de chequeo de los cruces también empiezan a ser

complicados y poco manejables, cuando el número de diagramas y

especificaciones se incrementan. Los métodos de la tercera generación fueron

distinguidos por una filosofía que es más concerniente con el todo y poco con las

partes. Estas técnicas continúan con el uso de gráficas, pero estos diagramas

serán más una vía de captura y verificación del modelo antes de él mismo. Este es

el cambio fundamental que constituye la tercera generación. YSM está

considerado como un método de la tercera generación.

Naturaleza del modelo orientado de YSM

Durante el desarrollo de un sistema, muchas decisiones tienen que ser tomadas

acerca de las necesidades del usuario y como estos requerimientos deben ser

encontrados. Si éstas decisiones no son modeladas cuidadosamente, los

requerimientos serán perdidos y no comprendidos. Algunas veces los sistemas son

construidos con funciones que no son actualmente requeridas. Algunas de estas

fallas son potencialmente costosas y dañinas.

Los modelos usados por YSM son la fundación del método. En un sentido general,

un modelo es una “es una representación simple que ayuda a simplificar cálculos o

predicciones”. En los modelos abstractos, la principal característica es que se

encuentra bajo evaluación y está de una forma más utilizable que la propia cosa

real. Con base a resultados del modelo las decisiones pueden ser tomadas. Esto es

mostrado a continuación:




18

R Empresas

E Abstracción

A

L

I Los cálculos nos

D llevan a las

decisiones,

A Acciones los cuales nos

conducen

D a las acciones.

Los modelos han sido utilizados para soportar muchas actividades humanas. La

arquitectura y la ingeniería son dos ejemplos muy obvios. YSM reserva el término

“modelo” para estructuras específicas que son completas y checadas. Cada

modelo tiene una estructura bien definida y permite checar completamente su

consistencia. Los sistemas son complejos y en ocasiones un modelo de sistema

puede ser difícil de entender. Las vistas de los modelos son utilizadas por expertos

en la materia para verificar la aplicabilidad de los sistemas con el medio ambiente.

Una vista es un diagrama, tabla u otra especificación usada como elemento

sobresaliente en un área del negocio o empresa. Cada vista muestra parte del

modelo y es utilizada para discutir un conjunto de salidas. Ejemplo:

M O D E L O

M O D E L O

Vista 1

Vista 2

Vista 3




19

La descripción se parece mucho a la proporcionada por el modelo de la segunda

generación, donde los modelos fueron definidos como una “colección de vistas”.

La diferencia es que:

♦ Para los métodos de la segunda generación, el modelo es igual a

la colección de vistas.

♦ Para los métodos de la tercera generación, las vistas son

derivadas desde el modelo.

En el modelo interno pueden haber muchas vistas. Cada una muestra parte del

modelo total en un formato de usuario amigable. Esto se muestra a continuación:

Cada modelo estándar (por ejemplo el modelo esencial de sistema) tiene una

estructura interna la cual es una representación de toda la información en el

modelo (por ejemplo, sistemas específicos y requerimientos esenciales).

Vista A

Vista B

Vista C

Vista D

MODELO INTERNO




20

El modelado interactúa por medio de vistas dentro del modelo. Cada vista muestra

parte del modelo interno y es seleccionada como una vista existente. Al cambiar

cualquier parte del modelo, el sistema de modelado modifica la vista. Cualquier

cambio hecho, es reflejado en el modelo interno. Esto se muestra a continuación:

En el diagrama de arriba, el modelo interno contiene entidades tales como a,b;

relaciones como d; atributos como c. Las dos vistas que se muestran son

generadas usando dos herramientas de modelado estándar, el diagrama de

entidad relación y el entidad especificación. Es importante señalar que YSM es un

método de la tercera generación y que puede ser utilizado para soportar

sofisticadas herramientas CASE. También puede ser usado sin soportar CASE.

Entidades = a,b,g,l; Relación d,a,b; Relación s,f,m; Relación f,m,a,d; Atributo a,c,y; Atributo b,d,z;

a d b

Entidad: a

Atributos: c




21

Es útil pensar que existen tres principales puntos de vista desde los cuales el

sistema puede ser visto:

1. Función. Aquí se indica lo siguiente: ¿“Qué es lo que el sistema

hace”?.

2. Tiempo. ¿“Qué pasa cuándo”?.

3. Información. ¿”Cuál información es usada por el sistema”?.

Por consiguiente, los sistemas pueden ser pensados de una manera

“tridimensional”. Para las tres principales dimensiones, la herramienta de

modelado primario es:

1. Dimensión de tiempo

2. Dimensión de información

3. Dimensión de función




22

Características de los sistemas

Cada sistema tiene una cierta complejidad en términos de “funcionalidad”,

“funcionamiento en tiempo extra” y el “uso de información”. Esto es dado

por los “perfiles del sistema”, los cuales pueden ser obtenidos por los “trazos”

y la complejidad por cada dimensión, la definición usando estos tres puntos de

vista y el origen. Dos de estos perfiles son mostrados a continuación:

Información Información

Función Tiempo Función tiempo

YSM usa los conceptos de aspectos para formalizar esto con respecto al negocio o

empresa. Un aspecto es una colección de vistas juntas que especifican los

elementos sobresalientes. Dos aspectos nombrados de un modelo son los que se

ilustran a continuación:



23

Aspecto de Aspecto

Información ambiental

Estos son de hecho, aspectos del modelo esencial de sistema. El aspecto

ambiental muestra la interfase del sistema con el medio ambiente; el aspecto de

información ilustra ésta y que es utilizada por el sistema. Un modelo puede tener

varios aspectos, dependiendo de cómo es desarrollado, verificado y usado.

Modelos YSM

Como un directorio, cualquier modelo deber ser lo suficientemente completo y

concebible para alguna arquitectura. Por cada modelo, YSM provee de reglas y

guías para asegurarse de que es completo, consistente y correcto.

Los modelos pueden ser considerados como secuencia evolucionaria de los

mismos. Como una primera aproximación, no obstante el siguiente diagrama, nos

proporciona una buena vista:

M O D E L O

ERD

Especificación de

Entidad

Especificación de

Atributo

Especificación de

Evento

Diagrama de

Contexto

Especificación del

Flujo de dato




24

Secuencia de

desarrollo

Una de las actividades de la empresa es la planeación estratégica. Esta examina

las prácticas actuales y futuras, las entradas y las estrategias de costo - efectivo

para llevar a cabo su terminación. Muchos proyectos diferentes deben ser

iniciados y para ello deberán incluir:

♦ Se consigue equipo nuevo, sitios o invariablemente otras

compañías.

♦ Se aprovecha la infraestructura de la compañía

♦ Provisión de nuevos sistemas que están por razones específicas.

Modelo esencial de

sistema

Implementac. del modelo

proceso

Implemantac. del modelo de software

Implementac. del modelo de código

Implemantac. del modelo

manual

Implementac. del modelo

de hardware




25

Soporte de la empresa para proyectos de sistema

Un proyecto de sistema a construir puede servir para soportar las actividades de la

empresa, tales como: información, bases de datos y demás recursos en diferentes

vías por todas partes del ciclo de vida, tal como se muestra a continuación:

Esta empresa soporta múltiples proyectos de sistema, cada uno de los cuales es

probable que esté en una diferente etapa del ciclo de vida.

ANALISIS DISEÑO IMPLEMENTACION

MANTENIMIENTO

MODELO ESENCIAL DE EMPRESA

BIBLIOTECA DE RECURSOS DE LA EMPRESA




26

Proyecto

Esfuerzo

Tiempo

Proyecto 2 Proyecto 3 Soporte de la empresa Proyecto 1




27

2.2 Marco conceptual

Como marco conceptual para situar el análisis de sistemas se definió un modelo

de etapas de desarrollo de un sistema de información:

• Introducción

• Herramientas de modelado

• El modelo esencial de empresa

• Las relaciones entre el sistema y la empresa

• El modelo esencial de sistema

• Conclusiones

Existen en la literatura diversas definiciones de lo que se entiende por “Análisis de

Sistemas”. Sin embargo, todas coinciden en que en esencia es una actividad de

comunicación entre las personas que realizan el análisis y los usuarios finales del

sistema de información que se desea implantar.

En el ámbito del desarrollo de sistemas informáticos, el análisis consiste en

identificar y especificar el conjunto de subfunciones que han de conformar el

sistema. Para ello, es preciso identificar la estructura de la función sometida a

tratamiento informático, es decir descomponiéndola en subfunciones e interfases y

luego estudiar su composición y determinar los cambios estructurales necesarios,

e incorporando, eliminando, agrupando o separando las interfases y así

establecer, cuáles de ellas serán automatizadas y cuáles serán manuales, con el

propósito de reinsertarla nuevamente en la organización una vez concluida su

construcción e implantación, ahora definida estructuralmente y con nuevos niveles

de soporte automatizado para el tratamiento de datos y la generación de

información.

Marco Conceptual



28

Entre las metodologías de análisis de sistemas y técnicas de especificación de

requerimientos más relevantes, se tiene:

a) Structured Requeriments Definition (SRD): metodología creada por K.

Orr y definida como: “Output- Oriented”.

b) Diseño Lógico de Sistemas de Información Administrativos: metodología

desarrollada por: O. Barros.

c) Análisis Estructurado de Sistemas: desarrollada inicialmente por:

Yourdon.

Esta última metodología es la adoptada para nuestro caso de estudio y análisis.

Marco Conceptual



29

2.3 Otras metodologías

El desarrollo de las metodologías de la ingeniería en software fue propiciado por

la necesidad de atender problemas específicos de la producción de sistemas cada

vez más complejos. Si se lleva a cabo un análisis de los métodos, puede notarse

una evolución en la especialización y el enfoque de los mismos, ya que mientras

en los primeros métodos cada uno trataba de dar sus propias respuestas, los

nuevos métodos (particularmente UML) tienen la ventaja de fundamentar sus

propuestas en un estudio crítico de los métodos anteriores, con el objetivo de

ofrecer una metodología más próxima a un estándar.

A continuación se muestra la cronología de algunas de las metodologías más

importantes de la Ingeniería de Software:

v Análisis estructurado / Diseño estructurado (AS/DS)

v Desarrollo estructurado de Jackson (JSD)

v Desarrollo de sistemas estructurados de datos (SDSD)

v Análisis estructurado y la técnica de diseño (SADT)

v Técnicas de modelado de objetos (OMT)

v Ingeniería de software orientada a objetos de Jacobsen

v Análisis y diseño con aplicaciones orientadas a objetos de

Boosh

v El lenguaje unificado de modelado (UML)

v Orientación a agentes

Las metodologías se suelen englobar en dos grandes tendencias: estructuradas y

las orientadas a objetos, dentro de ellas existen especializaciones que se detallan

en el siguiente esquema:

Otras Metodologías



30

Clasificación de las metodologías:

v Estructuradas

v Orientadas a procesos

v Diagramas de flujos de datos.

v Diccionario de datos.

v Especificaciones de procesos.

v Orientadas a datos

v Jerárquicos.

v No jerárquicos.

v Orientadas a Objetos

v Revolucionarios

v Sintetistas

El análisis orientado a objetos difiere del análisis estructurado en dos aspectos:

1. Construir un modelo de objeto, en vez de un modelo funcional, como por

ejemplo la jerarquía de los diagramas de flujo de datos.

2. Integrar los objetos, atributos y operaciones en vez de separarlos entre el

modelo de datos y el modelo funcional.

A continuación describiremos brevemente las metodologías de mayor importancia

que se utilizaron en el desarrollo del software:

Análisis estructurado / Diseño estructurado (AS/SD)

Este tipo de modelo admite los tres grandes modelos ortogonales que son: el

modelo de objetos, el funcional y el dinámico; Esta metodología hace hincapié en

la descomposición funcional ya que proporciona una o más soluciones finales al

usuario final.

Otras Metodologías



31

El AS/DS lo podemos encontrar en todas partes ya que por lo regular se encuentra

bien documentado y además se utiliza en la solución de muchos problemas reales

de acuerdo a las propias necesidades.

En el SA/SD durante la fase de análisis, se utilizan diagramas de flujo de

datos, especificación de procesos, diagramas de contexto, de flujo, de

transición estado y de entidad relación con el propósito de describir

lógicamente el sistema. En la fase de diseño, los diagramas de flujo de datos se

convierten en descripciones de cartas estructurales del código del lenguaje de

programación.

Coad & Yourdon, han sido los pioneros en el estudio de SA/SD, ya que se

considera este tipo de análisis como uno de los métodos orientado a objetos de

los más sencillos de comprender.

En el caso del Análisis Orientado a Objetos se ha tenido mucho éxito al derribar

problemas que se resisten al análisis estructurado, como las interfaces de usuario.

Para Coad & Yourdon el acercamiento orientado a objetos consiste de clases,

objetos, herencia y comunicación con mensajes. Así, el resultado de aplicar

OOA/OOD produce un diagrama principal de OOA conteniendo las cinco capas

siguientes:

1. Capa sujeta como un mecanismo divisor: “¿Qué buscar?”

2. Capa clase – objeto que se utiliza para capturar las clases

y los objetos

3. Capa de estructura de todo - parte

4. Capa de atributos

5. Capa de servicios

También describen un método de Análisis Orientado a Objetos basado en cinco

actividades principales:

Otras Metodologías



32

1. Localizar las clases y los objetos

2. Identificar estructuras

3. Identificar asuntos

4. Definir atributos

5. Definir servicios

Coad & Yourdon han publicado un enfoque integral para el análisis y diseño

orientado a objetos. Para ellos, un diseño orientado a objetos es construido a

partir de 4 componentes que tienen que ser diseñados para estas capas:

1. Componente del ámbito del problema.

2. Componente de la interacción humana.

3. Componente del manejo de tareas.

4. Componente del manejo de datos.

A continuación se describe brevemente en qué consiste cada uno de los

componentes:

1. Cada componente está compuesto de clases y objetos. El componente del

ámbito del problema está basado en el modelo (lógico) construido con el OOA

en la fase de análisis. Define el tema de estudio del sistema y sus

responsabilidades. Si el sistema va a ser implementado en un lenguaje

orientado a objetos, la correspondencia entre las clases y los objetos del

ámbito del problema serán uno a uno, y el componente del ámbito del

problema podrá ser programado directamente. Sin embargo, el refinamiento

sustancial del modelo lógico es normalmente requerido, resultando en la

incorporación de más atributos y servicios.

Otras Metodologías



33

2. Los componentes poco amigables en la interacción humana envían y reciben

mensajes desde el usuario. Las clases y objetos en el componente de

interacción humana tienen nombres que son tomados desde el lenguaje de

interfaz del usuario, por ejemplo: una ventana y un menú.

3. Muchos sistemas tendrán hilos múltiples de ejecución y el diseñador debe

construir un componente de manejo de tareas para organizar el

procesamiento. El diseñador necesita definir tareas como manejo de eventos o

manejo del tiempo, así como sus prioridades de manera crítica.

4. El componente de la administración de datos proporciona la infraestructura

para guardar y recuperar objetos. Puede ser un simple sistema de archivos, un

sistema de administración de base de datos relacional, o igualmente un

sistema de administración de bases de datos orientado a objetos.

Estos cuatro tipos de componentes de manera conjunta, conforman el modelo

físico.

Diversos aspectos del análisis estructurado han cambiado gradualmente a lo largo

de los últimos años.

Las principales áreas de cambio incluyen lo siguiente, según Yourdon:

a) Cambios de terminología.

b) Partición de acontecimientos.

c) La desenfatización del modelado físico actual.

d) Herramientas de modelado en tiempo real.

e) Integración más cercana del modelado de procesos

y datos.

Otras Metodologías



34

En un futuro no muy lejano se piensa que se darán, si es que ya no se están

dando, los siguientes cambios o pautas en el ámbito total en lo que se refiere a

análisis según Yourdon:

Mayor difusión del análisis de sistemas, sobre todo en los siguientes grupos: los

niveles superiores de administración en organizaciones gubernamentales y de

negocios, los niños y profesionales de la computación en los países del tercer

mundo.

Impacto sobre la industria de software del tercer mundo.

Proliferación de las herramientas automatizadas, aunque no todos los analistas

tienen acceso a las últimas herramientas de análisis.

Impacto de los desastres de mantenimiento.

Integración del análisis estructurado con la inteligencia artificial.

Podemos adicionar que el futuro del análisis estructurado va a depender mucho

también de qué tan rápido pueda ajustarse el mismo a los cambios tecnológicos

que se viven hoy en día, debido a que han estado surgiendo más técnicas en otras

áreas como lo es la orientada a objetos; la cual preveé un buen futuro y muchas

mejoras para los sistemas actuales.

Un nuevo y muy diferente enfoque al análisis y diseño de sistemas, es el análisis y

diseño de sistemas orientados a objetos (O-O). Las técnicas orientadas a objetos

que se basan en los conceptos de programación orientada a objetos, pueden

ayudar a responder las demandas organizacionales para nuevos sistemas que

requieran mantenimiento, adaptación y rediseño continuo.

Otras Metodologías



35

Básicamente en la programación orientada a objetos son creados objetos que

incluyen no solamente código acerca de los datos sino también instrucciones

acerca de las operaciones que se pueden realizar con ellos.

Usando el enfoque Coad & Yourdon al análisis O-O, empleamos un modelo de

cinco capas consistiendo de: (1) capa clase/objeto, (2) capa de estructura, (3)

capa de atributos, (4) capa de servicio y (5) capa de áreas.

El análisis y diseño estructurado proporciona un enfoque sistemático para el

diseño y construcción de sistema de información de calidad. A lo largo de las fases

de análisis y diseño, el analista debe proceder paso a paso, obteniendo

retroalimentación de los usuarios y analizando el diseño, buscando omisiones de

errores. El pasar demasiado rápido a la siguiente fase puede requerir que el

analista tenga que regresar para volver a trabajar en partes anteriores del diseño.

Además de las herramientas CASE se puede usar lo siguiente en diversas partes

del ciclo de vida de análisis y diseño:

a) Software de administración: Para administrar la ubicación de personas y

recursos del proyecto.

b) Software para crear prototipos: Pantallas y reportes que revisen y

modifiquen los usuarios.

c) Herramientas para el diseño de formas: Ayudan en el diseño de formas

de documentos fuente.

d) Software de gráficos y de presentación: Ayudan en la creación de

ilustraciones y producen una presentación profesional para los usuarios.

Otras Metodologías



36

2.3.1 Desarrollo estructurado de Jackson (JSD)

Esta metodología utiliza modelos gráficos para desarrollar sistemas. Los modelos

JSD describen el mundo real en términos de: entidades, secuencias y acciones,

estructura de entidades, modelo inicial, planificación e implementación del

sistema.

2.3.2 Desarrollo de sistemas estructurados de datos (SDSD)

Esta metodología es conocida como de Warnier - Orr. Desarrolló una notación

jerárquica para representar la información las cuales son:

a) De secuencia

b) De selección

c) De repetición

2.3.3 Análisis estructurado y Técnica de diseño (SDSD)

Esta metodología se compone de procedimientos que permiten al analista

descomponer las funciones del software o sistema en una notación gráfica, el

actigrama y el datagrama.

2.3.4 Técnica de modelado de objetos (OMT)

Fue desarrollada por Rumbaugh está basada en el desarrollo de un modelo de

sistema con tres partes, que posteriormente se refinan y optimizan para construir

un diseño.

Otras Metodologías



37

Descripción del modelo:

v Desarrollar el ámbito del problema

v Desarrollar un modelo de objetos

v Desarrollar un modelo dinámico

v Desarrollar un modelo funcional

2.3.5 Ingeniería de software orientada a objetos de Jacobson

Esta metodología describe cómo el usuario logra tener una acción interactiva con

el producto o sistema. A continuación haremos un bosquejo general de este

proceso de Jacobson:

v Identificar los usuarios del sistema

v Construir un modelo de requisitos

v Construir un modelo de análisis

2.3.6 Análisis y diseño con aplicaciones orientadas a objetos

de Boosh

Esta metodología abarca un “micro y un macro proceso de desarrollo”. A

continuación detallamos brevemente el micro proceso de desarrollo:

v Identificar clases y objetos

v Identificar la semántica de las clases y objetos

v Identificar las relaciones entre clases y objetos

v Llevar a cabo una serie de refinamientos

v Implementar las clases y objetos

Otras Metodologías



38

2.3.7 El lenguaje unificado de modelado (UML)

Es una metodología de lenguaje modelado que se utiliza para visualizar,

especificar, construir y documentar los mecanismos de un sistema de software.

UML es una combinación de los métodos de Rumbaugh, Booch y Jacobson,

además incorpora unas mejoras con el propósito de lograr un acercamiento de

tipo estándar. UML maneja los siguientes conceptos para un sistema:

v Clasificación Estructural

• Vista estática

• Vista de casos de uso

• Vista de implementación

• Vista de despliegue

v Comportamiento dinámico

• Vista de máquina de estados

• Vista de actividad

• Vista de interacción

v Gestión del modelo

• Vista de gestión del modelo

UML es una de las metodologías más simples pero siempre cuenta con la

capacidad de modelar cualquier tipo de sistema que se requiera.

Como conclusión podemos decir que todas estas metodologías han sido utilizadas

ampliamente para el desarrollo y construcción de sistemas, tanto la estructurada

como la orientada a objetos, no han sido del todo suficientes y eficientes para la

solución de problemas más complejos que actualmente la sociedad reclama y de

acuerdo a los avances tecnológicos que se tienen día con día.

Otras Metodologías



39

2.3.8 Orientación Agentes (OA)

El desarrollo de software Orientado Agentes resulta ser un nuevo enfoque para

abstraer y conceptualizar de la realidad, la solución de problemas distribuidos y

colaborativos. Esto se basa en los siguientes conceptos:

a) El concepto de granularidad en la cual un problema se divide en un

número de componentes autónomos los cuales pueden ser operados de

manera independiente.

b) El concepto de organización que se refiere a la agrupación de componentes

que se pueden reunir en jerarquías de control o en grupos de componentes del

mismo tipo.

c) El concepto de interoperabilidad en el cual se pueden manejar las

interacciones entre los agentes en contextos distribuidos y abiertos tal como es

el caso del Internet y el Web.

En la fase de especificación se obtiene los requerimientos del sistema, se

definen las propiedades del sistema y los protocolos de interacción.

En la fase de implementación se estudia el cambio de la especificación

abstracta a un sistema computacional en particular.

Finalmente en la fase de verificación se utilizan dos mecanismos de

verificación los cuales son: el ciclo de vida y el de verificación formal.

Otras Metodologías



40

CAPITULO 3

HERRAMIENTAS DE MODELADO

3.1 Introducción

No existe una manera obvia en la cual las herramientas serían organizadas;

probablemente la organización más lógica debería ser en orden alfabético. A

continuación señalaremos cual sería la forma progresiva a seguir:

• Herramientas para modelado información

• Herramientas para modelado de funciones

• Herramientas para modelado en tiempo y dinamismo.

Esta organización no es nada estricta ni óptima. Por lo tanto eSTDs y las tablas de

eventos y entidades son grupos que están más debajo de las herramientas

modeladoras.

Tipos de herramientas de modelado

Existen 4 (cuatro) tipos de herramientas modeladoras que son usadas en el YSM

(Método del sistema de Yourdon) las cuales son las siguientes:

• Gráfica

• Tabular

• Frame

• Textutal

A continuación describiremos brevemente de cada una de ellas.

Herramientas de Modelado



41

Herramientas gráficas

YSM usa herramientas de modelado gráfico, para mostrar los componentes de alto

nivel desde el punto de vista particular de los aspectos del modelo. Estos

gráficos, son el tipo preferido de modelo cuando la conexión entre componentes

es importante. Cada gráfica tiene un conjunto de iconos que pueden ser usados.

Los iconos pueden ser conectados en un sentido bien definido.

Las herramientas gráficas usadas en el modelado esencial son principalmente de

naturaleza semántica. El efecto de la notación seleccionada es la manera de estar

pensando acerca de los requerimientos del sistema, la cual es sutil y aún

importante. La comunicación gramática, en otras palabras, la convención gráfica

predetermina la forma de pensar sobre el problema.

En el ejemplo específico del diagrama de entidad relación, la elección de notación

presupone una vía al pensar que es en términos de entidades, relaciones,

subtipos, etc.

Para la implementación de modelos, hay gráficas que muestran la unidad llevada a

cabo. Estas herramientas son más concernientes con la unidad actual seleccionada

y la manera de como están ellas conectadas.

El modelo esencial se refiere principalmente con el significado o semántica; la

implementación se refiere más bien en lo que respecta a la estructura y a la

sintaxis.

Para vistas gráficas, hay ciertas normas que son siempre relevantes,

independientemente de la herramienta usada. Mayormente, estas son evidentes

por sí mismas, por ejemplo:




42

§ Todo texto usado en un diagrama debe ser legible para toda persona con vista

normal.

§ Los diagramas no deberían tener comentarios excesivos. Muchos comentarios

significan que se trata de un modelo bastante pobre.

Herramientas tabulares

Alguna información es almacenada en forma útil en una forma tabular. Por

ejemplo, la relación entre entidades y eventos pueden ser visualizadas en una

tabla de entidad-evento. Algunos modelos gráficos tienen una presentación

tabular en forma alternativa. Esta puede ser útil en algunas circunstancias,

particularmente si el sujeto experto en la materia encuentra el modelo gráfico

difícil de relacionar. Hablando en forma general, todas las tablas YSM son

formatos de “hojas extensas, con una simple entrada o lista de entradas en cada

celda.

Marco de especificaciones (Frame)

El término “frame” es utilizado informalmente para un cierto tipo de herramientas

de especificación. Este marco es usado para especificar toda la información

relevante, acerca del modelo componente que ha sido declarado en un diagrama o

en otro frame.

Algunos frame tienen variantes. Por ejemplo, cuentan con diferentes entradas

dependiendo en todo caso, de que los valores hayan sido listados o definidos en

términos de un tipo de dato abstracto. YSM ha evitado que la notación del marco

del diccionario de datos, sea muy extenso. Esto es por alguna de las siguientes

razones:

1. La notación del diccionario de datos ya es bastante complicado.




43

2. Es textual y por lo tanto no es tan fácil de entender como otros modelos. Con

el correcto soporte de las gráficas, y los frame, son fáciles de entender.

3. En algunos casos fue ambiguo y se abrió a la interpretación personal. En estas

áreas, la notación fue reemplazada.

El método por lo tanto proporciona una vía más flexible de especificaciones hacia

el modelo de componentes declarado en las vistas gráficas. Es inevitable tener un

período de transición antes de que tales herramientas de software estén

disponibles, pero el concepto de especificaciones frame proporcionaría una ligera

progresión ascendente. El uso de especificaciones frame en ambientes técnicos

diferentes varían. En ambientes automatizados el soporte es visto completamente

bajo el concepto de YSM. En cualquier ambiente automatizado de lápiz y papel los

frame “extensos” pueden ser reducidos en cuanto a la cantidad de cruces o líneas

referenciadas. Muchos de los requerimientos descritos, son declarados como el

comienzo de atributos y de entidades asociativas en este modelo-meta. Esto

corresponde al Frame y al tipo de formato.

Herramientas textuales

En el orden completamente específico de la empresa y del funcionamiento del

sistema, YSM cuenta con el recurso de la gramática textual en algunas

situaciones. Cuando este es requerido, el siguiente principio tiene que ser llevado

a cabo:

1. La gramática fue original y formalmente definida usando el meta-lenguaje o la

teoría de conjuntos. Sin embargo, esta usualmente sólo se les permitía a los

desarrolladores CASE.

2. Fue entonces reescrita en un lenguaje ordinario, la cual fue nombrada como

forma de relajamiento de la gramática.

3. Existe la esperanza de que las prácticas del YSM, serían capaces de inferir la

sintaxis correcta de esta, sin necesidad de usar algún apéndice.




44

4. Actualización de modelos en ambientes de soporte automatizados.

Al tratar con información que aparece en diversas vistas es muy dependiente del

ambiente de soporte técnico. Por ejemplo, una entidad aparece en:

• Empresa ERD: Esta muestra la entidad y alguna relación o subtipo que

aparecen.

• Especificación de entidad empresa: Estas definen propiedades tales

como atributos, identificadores y el estado que guardan cada una de las

variables.

Estas no pueden ser consideradas como vistas independientes, ya que son formas

alternativas de la entidad. Cambiando el nombre de la entidad, es algo que sería

terminado como una simple acción. Si todas las vistas superiores o de mayor nivel

fuese necesario cambiarlas, entonces el enfoque sería a lápiz y papel.

En un ambiente que soporte visibilidades múltiples en diferentes vistas, allá puede

estar el control apropiado para que la información sea meramente desplegada.

Algunos otros criterios también tienen que ser encontrados. Así, los criterios para

actualización de un artículo visible en una vista son:

• El artículo modelo debe ser el apropiado para la vista.

• El usuario debe tener un correcto acceso a los privilegios.

• El usuario debe tener abierta alguna vista donde muestre el componente

a actualizar.

• El intento de cualquier actualización no debe comprometer la integridad

del modelo en el cual el artículo es un componente.

En este caso no resulta del todo visible soportar los conceptos antes mencionados

usando papel y lápiz, excepto cuando se trata de una vía muy informal.




45

Interdependencia de modelos

Existen vías análogas en las cuales un modelo de “importación” se define y se

especifica desde otro. Por ejemplo, el modelo esencial de sistema incluye:

• Sistema ERD: Este define cual de las entidades y relaciones de empresa

es usada por el sistema.

• Especificaciones del sistema entidad: Estas heredan muchas

propiedades de la empresa correspondiente y de la entidad que fue

especificada.

• Minispecs o especificaciones mínimas: Estas definen las funciones del

sistema en términos de conexión, junto con funciones primitivas bien

definidas, llamadas operaciones. Estas a su vez pueden ser reutilizadas,

en diferentes sistemas.

Conceptualmente, cada modelo puede ser considerado como completo y suficiente

por sí mismo. Sin embargo, cuando nos referimos a un modelo, este puede ser

apropiado por otro. Por ejemplo, no se permite que un sistema modelador sea

renombrado como una entidad empresa.

Diagramas de Anotación

En ambientes de soporte automatizados, la mayoría de los comentarios en el

diagrama deben evitarse, ya que esto se podría hacer tranquilamente a lápiz y

papel. Un mejor acercamiento sería permitir requerimientos de información

adicional, sobre el diagrama a ser presentado por alguna otra vía.




46

Referencias – cruzadas

Los modelos descritos anteriormente, son usados para capturar requerimientos y

además son parte de modelos bien definidos. Por lo tanto, es importante proveer

de referencias a las fuentes de información, incluyendo entrevistas a usuarios,

documentos de texto, estándares de gobierno y especificaciones de hardware.

En ambientes de lápiz y papel, las referencias pueden ser agregadas como una

parte extra; es decir, texto sin estructura alguna. En ambientes automatizados,

cada una de las referencias podrían ser un registro que haga referencia a un

modelo de componente, al requerimiento externo, cuándo fue identificado y quién

estuvo de acuerdo.




47

3.2 Diagrama de Entidad Relación

3.2.1 Propósito

El diagrama de entidad relación (ERD) es una herramienta usada para desarrollar

un modelo particular de importancia para la empresa, así como la relación entre

ellas. Es considerada como un auxiliar semántico, la cual ayuda a clarificar los

conceptos.

La ERD es usada para identificar y organizar la información. Organiza todos los

datos que la compañía maneja, no sólo el almacenado de información. ERDs

también puede ser utilizado como una herramienta para descubrir reglas y

eventos. Cada una de las vistas muestra una colección de hechos del mundo -

real, los cuales son significativos para la empresa. Estos se refieren a los aspectos

de la realidad que no son negociables. Ejemplo de ERD de nuestro caso de

estudio, ver figuras: A y B.

3.2.2 Diagramas de entidad relación que se usan en el

Sistema – Empresa

El modelo esencial de empresa usa ERDs para definir entidades y la relación entre

ellas. Un diagrama de entidad relación que se usa de esta manera, es referenciado

como un diagrama de relación entidad empresa, o empresa ERD. El modelo

esencial de sistema hace uso de los ERDs para mostrar las entidades y la

responsabilidad que este tiene para colectar la información.




48

3.2.3 Componentes que conforman el diagrama entidad

relación (ERDs)

Entidad Asociativa

En una entidad asociativa, ambas relación y entidad actúan de igual forma. La

primera indica que existe una asociación al mundo - real. Como sucede en toda

relación, una ocurrencia de tipo asociativa no puede haber sin una anterior (o

creación simultánea).

Una relación debería ser reemplazada por una entidad asociativa, si esta tiene

atributos o bien, actúa como una entidad en otra; si esto sucede, se dice que

ambas son relación y entidad.

Los atributos de una entidad asociativa, no describen las entidades que participan

en toda relación, pero sí la ocurrencia de la asociación entre ellas. Por ejemplo;

dada la siguiente relación:

Para este caso, el nivel salarial específico del puesto que fue asignado, debería ser

importante. En este caso lo que describe es, cuándo la ocurrencia de la relación

fue dada o puesta. Este modelo es reemplazado por la relación “se la asigna” por

la entidad asociativa “Catálogo de puestos” con nivel salarial como su atributo.

Empleados

Se le Asigna

Puestos


DIA

GR

AM

A D

E EN

TID

AD

REL

AC

ION

DEL

SIS

TEM

A D

E N

OM

INA

(D

ER)

M

1

M

M

M

M

M

1

M

M

Fig

ura

A

Em

ple

ad

os

Id_

dep

to.

No

mb

re

Id_

pu

esto

Dir

ecci

ón

Id_

emp

l.

Tel

éfo

no

P

ert

en

ece

a

Dep

end

enci

as

Id_

dep

to.

Des

crip

.

Titu

lar

Tien

e

un

P

ues

tos

Id_

pts

o.

Niv

_sa

l S

alar

io

Des

crip

.

Tien

e

un

o o

va

rio

s

Pré

stam

os

Tien

e

un

a o

va

ria

s P

edev

ar

Id_

pd

var

Id_

emp

l.

stat

us

Imp

orte

Des

crip

.

Tien

e

un

a o

va

rio

s P

ag

ex

t D

. Au

s.

Pri

ma

d.

Hrs

.Ex

t.

Des

crip

. Id

_p

agex

t Id

_em

pl

Id_

pre

st.

No

.qn

as.

Id_

emp

l.

Des

crip

.

Imp

orte

Magnolia A Castrejon Delgado

Fi

gu

ra B

EM

PLE

AD

OS

TA

BLA

DE

L S

UB

SID

IO

PU

ES

TO

S

D

EP

EN

DE

P

ag

os

Ex

tra

s

PE

DE

VA

R

PR

ES

TA

MO

S

TA

BLA

DE

L IM

PU

ES

TO

TA

BLA

DE

L C

RE

DIT

O A

L S

AL

AR

IO

Ge

ne

ran

AR

CH

IVO

DE

P

AG

OS

A

EM

PLE

AD

OS

N.E

N

om

bre

dir

ecc

ión

Des

crip

.

Niv

el

sal.

cve

de

p

cvep

ue

Des

crip

.

cve

pre

N.E

.

Cve

pag

N.E

.

Imp

ort

e

N.E

.

cve

pe

r

Imo

prt

e



49

Esta entidad asociativa retiene la propiedad de una relación existente. Cada

ocurrencia de registros “Catálogo de puestos”, es el hecho de que a un empleado

le fue asignado un puesto junto con un nivel específico.

3.2.4 Relaciones

Una relación representa una posible ocurrencia que se puede dar entre entidades.

Cada suceso de la relación, corresponde a una específica de estas entidades

existentes y que son enlazadas por dicha asociación. La relación puede ser

considerada como un patrón de hechos, los cuales hacen referencia a entidades

específicas, que pueden ser agregadas para obtener sucesos concretos acerca del

mundo - real. Por ejemplo:

Llénese con el empleado requerido Llénese con el pago extra que se trate

Se le Asigna

Empleados

Puestos

Catálogo de

Puestos

Personal

PagExt

Juan Pérez Se le asigna Horas extras

Pedro Páramo Se le asigna Prima dominical

José Sordo Se le asigna Prima dominical




50

Cada ocurrencia de la relación, corresponde a una asociación exacta de las

entidades que pertenecen a ella. Estas también pueden ser representadas como

diagramas de instancias.

Juan Pérez Horas extras

Pedro Páramo Prima dominical

José Sordo

3.2.5 Subtipos

Un subtipo de una entidad es un grupo bien definido de ocurrencias de la misma,

la cual es considerada con derechos propios.

Como un ejemplo, consideremos la entidad de percepciones y deducciones

(Pede). Ocurrencias individuales de ésta corresponden a: Bono de renta, Bono

despensa, quinquenios, descuentos varios, etc.

Un grupo bien definido es la entidad pede, debido a que tiene ocurrencias

individuales. Otras deducciones son un subtipo de pede; otros de esta son:

“Bonos” y Otras percepciones, los cuales podrían aparecer como un diagrama de

entidad relación. Ejemplo:




51

Los subtipos también pueden ser representados por medio de un diagrama de

venn, en las cuales una entidad se muestra como un área plana, con sus

respectivas ocurrencias dentro de la misma. (Como se trata de una teoría

convencional, en este conjunto dado utilizaremos nombres en plural):

Descrip.

Bonos

En este caso podemos observar, que una ocurrencia de subtipo es por

consiguiente una misma de supertipo; un bono automáticamente depende de

pede o lo que es lo mismo, un subtipo hereda las propiedades del supertipo.

Pede

Otra Deducción

Otra Percepción

Bono

supertipos

Subtipos medios

Subtipos

Pedes Otras percep.

Otras deduc. PerDeducc.

Bonos

+ +

B. renta

B. desp.




52

3.2.6 Subtipos medios

Indican que la empresa considera a la entidad como existente, ya que identifica a

grupos distintos, donde cada uno de los cuales es referido por un subtipo.

3.2.7 Supertipo

Es considerado como un grupo general de algunas entidades, lo cual significa que

tiene sus propios derechos y además tiene dos tipos de propiedades comunes:




53

3.3 Diagrama de transición entidad - estado

Los diagramas de transición entidad estado (eSTDs), son usados para cambios

significativos en el modelo de las propiedades de las entidades (incluyendo las

asociativas). Una entidad puede tener uno o más patrones de cambio llamados

ciclos de vida. Cada ciclo es nombrado por una característica específica descrita

como una variable estado. El eSTD es usado para modelar los diferentes estados

que las variables puedan tomar. La declaración de variables de estado se discuten

en el punto 2.5.2.3.5 del manual de Yourdon [1].

No todas las entidades tienen variable de estado. Por cada una que tenga la

entidad, habría un eSTD. Los eSTD muestran como una ocurrencia de entidad

estado, cambian cuando se producen eventos específicos.

3.3.1 Diagramas de transición de estado entidad- empresa

Cada entidad con variables, tienen un ciclo de vida por cada una de ellas. Este

eSTD es parte del modelo esencial de empresa. Un eSTD utilizado en esta parte,

es referenciado como un diagrama de transición de estado entidad empresa,

entidad empresa STD, o empresa eSTD.

3.3.2 Diagrama de transición estado sistema – entidad

Un sistema puede tratar con solo alguno de los eventos que afectan una entidad.

Este a su vez, no puede ser siempre responsable de los cambios que sufra dicha

entidad. Un diagrama eSTD que muestra los eventos que están al alcance del

sistema, es referenciado como un diagrama de transición de estado entidad

sistema, entidad sistema STD o sistema eSTD. A continuación mediante un

diagrama ejemplificaremos lo explicado anteriormente, ver figura C.




54

3.3.3 Especificación de atributos

Cada atributo tiene una especificación que es parte del modelo esencial de

empresa. Esta a su vez describe el valor y significado del mismo. Si un sistema

usa un atributo de una entidad, entonces esta especificación es visible al modelo

esencial de sistema. Ejemplo:

A continuación, haremos una breve descripción de cada uno de los componentes

que la conforman:

ENTIDAD: Personal

ATRIBUTO: N.E.

SIGNIFICADO: Una corta descripción que se usa dentro de la organización para propósito de identificación.

RETENCION: Almacenamiento

TYPING: Abstracto

ADT: Alfanumérico

PARAMETROS: Longitud mínima: 3 Longitud máxima: 5

RESTRICCIONES: Primer carácter alfabético


DIA

GR

AM

A D

E T

RA

NS

ICIO

N

EN

TID

AD

- S

ISTE

MA

[eS

TD

]

Fi

gu

ra C

Empl

eado

s ca

talo

gado

s po

r la

D.R

.H

Cre

ar

Con

sulta

s de

Em

plea

dos

Can

cela

cap

tura

Inic

ial

L

eer

O

pera

dor

canc

ela

L

eer

C

aptu

ra

In

icia

cap

tura

em

plea

dos

Bor

rar

Ac

tual

iza

Con

sulta

de

empl

eado

s

Fi

n de

cap

tura

Cap

tura

can

cela

da

Le

e y

actu

aliz

a

Act

ualiz

ació

n

Dia

gram

a pa

rcia

l

d

e ilu

stra

ción

EN

TID

AD:

Cat

álog

o Pe

rson

al

VA

RIA

BLE

ES

TA

DO

: St

atus

AB

RIR

EJE

CU

TA

ND

O

CO

MP

LET

AD

O

FIN

ALI

ZA

DO

O

P

OP

E

nti

da

d

Var

iab

le

est

ad

o

Tra

nsi

ció

n

inic

ial

Est

ad

o

inic

ial

Tra

nsi

ció

n

Eve

nto

Acc

eso

E

sta

do

C

on

ecto

r

En

tid

ad

m

uer

ta

Co

men

tari

o



55

♦ ENTIDAD: Aquí es donde se declara el nombre y se usa para

ayudar a identificar la existencia de atributos definidos.

♦ ATRIBUTO: A este se le asocia un valor de cada una de las

ocurrencias suscitadas en la entidad.

♦ SIGNIFICADO: Este corresponde a la cualidad que tienen los

nombres de los atributos de cada ocurrencia de la entidad.

♦ RETENCION: Este se encarga de definir el tipo de atributo:

v Almacenado: Se le asigna un valor en un

punto en el tiempo.

v Temporal: Es usado para cálculos

intermedios.

v Derivado: Se usa para recalcular

información cada vez que el valor sea

requerido.

YSM hace la siguiente recomendación: Cualquier tipo de información deberá

contener atributos; todo tipo de dato siempre nos habla acerca de algo; por lo

tanto, no toda información necesita ser guardada o almacenada.

El valor del atributo puede corresponder a cualquier tipo de dato abstracto. (ADT)

o bien ser listado en forma explícita. Los ADTs pueden ser utilizados con cualquier

operación bien definida. Los valores permitidos en esta entrada son para tipos de

listas; si la entrada es abstracta, esta no estará presente

♦ ADT: Todo atributo definido en esta forma puede ser:

v Comparado con otro del mismo tipo de dato abstracto

v Comparado con un valor contenido en flujo de datos del

mismo tipo de ADT.

v Comparado con valor fijo, usando una constante en unidades

que sean soportadas por el ADT. (Kg., mg., etc.).




56

Ejemplos de uso de ADTs: Fechas, alturas, pesos, etc.

♦ RESTRICCIONES: Si la entrada para typing es abstracta, entonces

los posibles valores para el atributo son heredados por el tipo de

dato.

3.3.4 Especificación del tipo de dato abstracto

Un ADT es un conjunto de valores, junto con las operaciones permitidas sobre

estos valores. Lo abstracto en el nombre significa que no hay compromiso alguno

con la representación física. En YSM todos los datos (atributos, no atributos

elementales del flujo de dato, temporales) tienen un tipo de dato abstracto. En las

operaciones de la empresa son definidos para operar con ciertos tipos y solo

estos. Resulta del todo inusual e ilegal en YSM, tratar de utilizarlo con un tipo de

dato incorrecto. Ejemplo: declarar un real y tratar de almacenar un string.

TIPO DE DATO ABSTRACTO: Mes en cual se le efectuará el primer descuento a un empleado.

SIGNIFICADO: usualmente son 12 meses

ESTRUCTURA: Simple

NUMERO DE VALORES: Finito

VALOR DE DEFINICION: Lista de valores

VALORES: Ene, Feb, Mar, Abr, May, Jun, Jul, Ago, Sep, Oct, Nov, Dic.

ORDENAMIENTO: Cíclico




57

En la estructura, YSM permite ADTs simples y compuestos que estén bien

definidos. Esto se indica por el valor en la estructura del campo.

♦ Simple: Tiene un único valor e indivisible. Ejemplo: Mes del año.

♦ Compuesto: Cuenta con algunas partes componentes es decir,

puede ser uno u otro.

Un tipo de dato compuesto tiene dos o más componentes. Ejemplo de este tipo:

♦ ORDENAMIENTO: Un ADT ordenado, son cuando los valores

tienen un orden significativo. No todos los ADTs cuentan con un

ordenamiento. Los valores que pueden tomar son los siguientes:

v Ninguno: No hay términos significantes

v Lineal: Cuando los valores son comparados unos con otros.

v Cíclico: Ene, Feb, Mar, etc.

La tabla siguiente nos muestra la disponibilidad del orden de operadores:

TIPO DE DATO ABSTRACTO: La dirección de cada empleado

SIGNIFICADO: Utilizado por alguna entidad para enviar información

COMPONENTES: Componente Tipo Casa Residencia Calle Alfabético Ciudad Alfabético Código postal Numérico




58

<<<<

Tabla 3.1

Orden

Operación Número Finito Discreto Continuo Finito Continuo

Primero Y Y Y Ultimo Y Y Y Siguiente Y Y Y Anterior Y Y Y < Y Y Y <= Y Y Y = Y Y Y Y # Y Y Y Y >= Y Y Y > Y Y Y




59

3.4 Diagrama de contexto

El diagrama de contexto muestra la interfase entre el sistema y el medio

ambiente. Cabe destacar los requerimientos de entradas y salidas para llevar a

cabo este propósito. Las fuentes para las entradas y salidas, también son

mostradas por este tipo de diagrama. Estas pueden ser otros sistemas,

dispositivos de hardware, personas y otras organizaciones. A manera de

implicación, el diagrama de contexto define el alcance de todo sistema. Resulta

del todo necesario transformar las entradas proporcionadas en requerimientos de

salida.

La interfase entre el sistema y el medio ambiente, no se puede cambiar de

manera unilateral por el analista de sistemas o por el diseñador. Cualquier cambio

en el contenido o la propia estructura de la interfase, solo puede ser llevada a

cabo después de una previa negociación con las otras partes que intervienen y

que son del todo ajenas al alcance del sistema.

El diagrama de contexto es un flujo de datos, el cual muestra al sistema como un

simple grupo de procesos. De hecho, es un particular tipo de flujo en el que hay

un simple proceso y terminadores. No todos los componentes serán usados en un

sistema dado. Los flujos de eventos sólo son probables que ocurran si el

funcionamiento del sistema cambia en horas extras de trabajo. Los flujos de

eventos sólo podrán ser encontrados cuando el sistema controla el medio

ambiente. Para lograr una mejor comprensión de lo mencionado anteriormente,

ejemplificaremos este tipo de diagrama con nuestro caso de estudio, ver figura

D.




60

4.2 Diagrama de flujo de Datos

No todos los componentes posibles del diagrama de flujo de datos son requeridos

por un sistema en especial. El control de procesos y el flujo de eventos se

solicitan, si el comportamiento del sistema cambia fuera de tiempo; los flujos

continuos solamente serán solicitados, si el sistema monitorea o controla el estado

de los dispositivos en ese ambiente; el almacenamiento es utilizado, si la

información disponible a la vez, es necesitada subsecuentemente.

El siguiente ejemplo es tomado de un sistema de control de procesos que

controla el proceso de cálculo de la nómina, ver figura E.


DIA

GR

AM

A D

E C

ON

TEX

TO D

EL S

ISTE

MA

DE

NÓ

MIN

A

D

epen

denc

ias

asig

nada

s

T

rám

ites

para

la c

aptu

ra

Con

firm

ació

n

de

em

plea

dos

de la

cap

tura

Asi

gnac

ión

de

Dep

ende

ncia

s

Pues

tos

asig

ando

s

Asi

gnac

ión

de

Pu

esto

s

C

onfir

mac

ión

de la

asi

gnac

ión

Asi

gnac

ión

de p

rést

amos

de

pré

stam

os

O

tras

per

c. y

ded

uc.

asig

nada

s

Asi

gnac

ión

de

Pe

rcep

cion

es y

ded

ucci

ones

var

iabl

es

I

ncid

enci

as

var

ias

asig

nada

s

Trám

ites

para

la c

aptu

ra d

e in

cide

ncia

s

Trá

mite

s pa

ra s

olic

itar

Con

firm

ació

n de

la e

labo

raci

ón d

e lo

s

Tale

s co

mo:

Hor

as e

xtra

s, e

tc.

Rec

ibo

de s

ueld

os

reci

bos

de s

ueld

o (R

epor

tes)

Pa

ra e

l pag

o co

rres

pond

ient

e

A lo

s em

plea

dos

Fi

gu

ra D

Sis

tem

a d

e N

óm

ina

de

l H

. A

yun

tam

ien

to

del

Co

lima.

Em

ple

ad

os

Dep

end

enci

as

Pu

est

os

Pré

sta

mo

s

Pe

de

var

Pag

ext

Pa

go

sN

Em

ple

ad

os D

ep

en

de

nci

as

Pu

esto

s

Pré

sta

mo

s

Pe

de

var

Pag

ext

Pa

go

sN


Listado de archivos Proceso cancelado Petición de datos Programa en

ejecuciòn Listado de archivos Conjunto de archivos

Archivos nuevos Ejecuciòn correcta Proceso de E/D Conjunto de archivos cálculo

Archivos generados Tablas Reqmto. de datos Comentario DIAGRAMA DE FLUJO DE DATOS (DFD) Figura E

DFD # : 1

NOMBRE DFD: Càlculo de Nòmina

DFD # : 1 Nombre del DFD

Movimiento Habilitar / deshabilitar

Proceso Cálculo Nómina

Checa Existencia

de archivos

Controla la ejecución

del programa

Generar archivos de movtos.

Archivos Nuevos

generados

Flujo de datos continuos

Flujo de acceso Continuo

Flujo de evento continuo

Proceso de datos

Control de procesos

Grupo de procesos

procporesoDiálogo del

flujo de evento

Evento almacenado

Datos almacenados

Flujo de acceso discreto

Flujo de Datos

Discreto

Flujo de Evento Discreto

Simple comentario





61

3.5.1 Flujo de acceso

Un flujo de acceso es usado para mostrar que un proceso hace uso o cambia

información almacenada para llevar a cabo un determinado propósito. Los datos

almacenados corresponden a las entidades o relaciones. En el DFD, ésta se indica

en términos generales.

3.5.2 Proceso de entrada

Un flujo de acceso de un almacenamiento muestra que el proceso usa información

almacenada y que esta puede corresponder a:

♦ Accesos match: Una ocurrencia de entidad o relación tienen criterios

particulares.

♦ Acceso de lectura: El proceso usa los valores de uno o más atributos

para seleccionar la ocurrencia de una entidad.

♦ Chequeos de accesos: El valor de una variable de estado, necesita ser

revisado.

3.5.3 Proceso de salida

♦ Crea accesos: Se encarga de crear ocurrencias de una entidad o

relación.

♦ Eliminación de accesos: Se usa para borrar una o más ocurrencias de la

entidad

♦ Actualización de accesos: Es utilizado para modificar el valor de un

atributo.

♦ Cambio de accesos: El cambio de condición de una variable estado.




62

3.5.4 Proceso de datos

Este proceso especifica que solamente transforma a los datos. No es responsable

de la coordinación o activación de los mismos. Este a su vez puede utilizar flujo de

eventos continuos en forma boleana. Los procesos también pueden ser continuos

o discretos. Si es discreto, no podrá generar datos continuos.

3.5.5 Procesos continuos

Es aquel que toma un determinado tiempo para llevar a cabo una función

específica. Solo estos pueden generar salidas continuas y se dice que son

persistentes.

3.5.6 Procesos discretos

Es aquel que puede iniciar y finalizar inmediatamente cuando es ejecutado,

también puede ser puesto en movimiento habilitándolo o deshabilitándolo en

forma explícita por un proceso de control o bien, ser desactivado

permanentemente y no puede producir salidas continuas y tampoco es

persistente.

3.5.7 Triggers

Son mecanismos de activación y se etiquetan con la letra “T”. Sirven para poner

en marcha un proceso discreto; los cuales pueden ser la ejecución completa del

proceso o la detención del mismo en alguna parte del mismo.




63

3.5.8 Distinción entre flujo de datos y datos almacenados

Si un dato es almacenado entre dos procesos, éstos a su vez, son descontrolados;

en cambio, si es entre procesos, se encarga de sincronizarlos.

3.5.9 Distinción entre flujo de eventos y flujo de datos

Pueden ser distinguidos por el número de bits que llevan cuando éstos ocurren,

los cuales pueden ser:

♦ 0 Bits: Flujo de evento discreto

♦ 1 Bit: Flujo de evento continuo

♦ Muchos bits: Flujo de datos

Un flujo de datos discreto, sólo puede transformar o comunicar alguna

información que ha acontecido desde el punto de vista del tiempo en cambio, uno

continuo transfiere información que es verdadera ciertas veces y falsa otras. El

flujo de datos, transfiere información a ser almacenada, usada en cálculos, etc.

3.5.10 Diálogo del flujo de datos

Este contiene algunos flujos que actúan como una especie de interfase. El nivel

más bajo puede tener doble flujo en relación directa uno con otro: Una causa que

la otra ocurra, tal es el caso de una pregunta y una respuesta. A éste se le conoce

como diálogo par. La salida de este tipo de diálogo debe ser parte de la respuesta

de la entrada. Por ejemplo si un empleado reclama una respuesta inmediata, el

reclamo y la respuesta deben ser de tipo par. Ejemplo:




64

Empleado reclama

respuesta

Empleado

reclama

3.5.11 Diálogo del flujo de evento

Es un paquete de algunos flujos de eventos entre dos procesos (o entre un

proceso y un terminador). Excepto que dichos flujos, son eventos antes que flujo

de datos y su descripción es exactamente un diálogo de flujo de datos.

3.5.12 Habilitar y deshabilitar

Es la representación de un proceso existente habilitado o deshabilitado en un

control de procesos. Un E/D representa el hecho de que el control lo habilita en un

tiempo subsecuentemente. Turn on es equivalente a “E” y turn off a “D”.

Evento almacenado:

Es un mecanismo para almacenar eventos relacionados con recursos hasta que

puedan ser usados por un proceso de control. Hay tres tipos de operaciones que

se usan:

♦ Inicializar: Si existe lo limpia y lo pone como cero eventos.

Comprender lo que el empleado reclama




65

♦ Señal: Si no hay procesos esperando un evento, este adiciona

uno o más ocurrencias del mismo.

♦ Wait: Si hay eventos detenidos en el almacén, el número

presente es decrementado en uno; si no hay almacenado

ninguno, el proceso es suspendido y puesto en cola.

3.5.13 Especificación de procesos

Esta especificación describe el tipo, número de instancias y mecanismos de

activación para algún proceso. Existe una especificación de procesos por cada

modelo esencial de sistema. La funcionalidad del proceso es descrita por otras

herramientas de modelado tales como:

♦ Diagramas de flujo de datos (DFD)

♦ Minispecs

♦ BTDSs ó comportamiento del estado de transición y

tablas de acción.

En un ambiente de soporte automatizado, ésta herramienta de especificación

actúa como un soporte directo para los DFD. Cada proceso en un DFD cuenta con

uno propio de especificación. Cada una de éstas hace referencia a un minispec,

bSTD, o un nivel bajo que es usado para señalar la función en este caso.

Ejemplo:

PROCESOS: Actualización de salarios de los Empleados

SIGNIFICADO: Autorizar el incremento de sueldo pactado

TIPO DE PROCESO: Data




66

Proceso

Se encarga de especificar el nombre que se le asigna al proceso.

Significado

Es utilizado para dar una descripción general o algún comentario acerca del

proceso; es decir, la función que realizará el mismo.

Tipo de proceso

Los tipos de procesos pueden ser:

PERSISTENCIA: Discreta

MECANISMO DE ACTIVACIÓN: Estímulos

ESTIMULOS: Proporcionar el pago

NUMERO DE INSTANCIAS: 1

ESPECIFICACION: Minispec

TIEMPO MEDIO ENTRE FRACASOS O QUIEBRAS: 6 Meses

TIEMPO MEDIO PARA REPARAR: 1 día

TIEMPO DE RESPUESTA: 1 día

PROCESAMIENTO / ACTIVACION: 8.5 M instrucciones




67

♦ Control

♦ Data

♦ Grupos

Persistencia

Nos indica si el proceso es:

♦ Continuo: En este caso se dice que produce salidas

continuas.

♦ Discreto: Especifica instantes de tiempo para llevar a

cabo una determinada función. Es puesto en marcha en

forma explícita o mediante requerimiento de estímulos.

Se dice que si el proceso es continuo, entonces es específicamente

habilitado/deshabilitado o bien, es siempre activo; en cambio, si es discreto se

dice que hay un mecanismo de activación que causa que dicha función sea llevada

a cabo.

Mecanismo de activación

Este es sólo para procesos discretos. El mecanismo de activación, es usado para

hacer que se efectúe la ejecución del proceso. Los valores permitidos son:

♦ Estímulos: En este caso, existe un dato discreto o flujo de

evento que se encarga de actuar como un estímulo para el

proceso. Se dice que cuando este flujo ocurre, se ejecuta.




68

♦ Disparo o puesta en marcha “Trigger”: El proceso es

puesto en movimiento. Cuando un control específico lo

identifica como una necesidad, por sí mismo no tiene

control sobre este, ni tampoco sabe nada sobre alguna

cosa en particular antes o después de ejecutarse en la

corrida reciente.

♦ Tiempo: El proceso es ejecutado cuando ocurre un evento

temporal.

Estímulos

Todo proceso de datos discreto puede tener un flujo como un estímulo. Un control

de procesos discreto puede tener un flujo de evento discreto, también como un

estímulo.

La interacción de habilitar/deshabilitar y los estímulos

Para procesos discretos, la distinción entre habilitar y la activación de los mismos

cuando ocurre un estímulo, es importante. Considere un proceso a ser

habilitado/deshabilitado. Cuando se habilita espera un estímulo de flujo de datos,

para poder ocurrir. Cuando no ocurre, se dice que corre completo (no toma

tiempo) y entonces espera que corran otra vez. Esto puede ser mostrado como un

diagrama de transición estado.

“Habilita” “Deshabilitar”

Ocurrencias de estímulos

Procesos en marcha

Proceso deshabil.

Proceso habilitado




69

El diagrama que se ilustra a continuación, muestra la relación entre persistencia,

mecanismo de activación y estímulos:

Procesos

Activos

Habilitado y deshabilitado

Continuamente, mientras esté

Continuos habilitado

Permanente todo el tiempo

Cuando son puestos en marcha

Procesos disparados

habilitado /

Discretos cuando ocurren los estímulos

deshabilitado

cuando ocurren los estímulos y el

proceso está habilitado.

Permanente

1. Cualquier proceso es uno u otro es decir, continuo o discreto

2. Los procesos continuos están habilitados, deshabilitados o permanentes

3. Un proceso discreto puede ser habilitado y deshabilitado o disparado como se

muestra en el DFD. Otros procesos discretos son permanentes.

4. Para ambos procesos, estos solo pueden correr en un cierto tiempo.




70

Número de instancias

Algunos procesos tienen más de una instancia y el número que puede tener son:

♦ Constante: El número de instancias son 1,2,3,..., pero este

número no varía sobre el tiempo de vida del sistema.

♦ Variable: El número de instancias cambia en período de tiempo

y es menor que la vida del sistema.

Especificación

Este define la manera en la cual los procesos son especificados. Los valores

permitidos en tipo control son “bSTD”, “estado de transición y acción en tablas” y

“minispec”. Para data es “minispec” o “modificación”. Finalmente, para grupo son:

“Diagrama de flujo de datos” o “modificación”.

Hay exactamente una especificación usada para definir la función de los procesos

estas son:

♦ Diagrama de flujo de datos

♦ Minispecs

♦ BSTDs

♦ Estado de transición y acción en tablas




71

3.5.14 Minispec

Están condicionados para dar una especificación rigurosa por cada proceso de

datos del sistema. En ciertas circunstancias, son también utilizados señalar el

control de procesos.

Los minispec deben ser:

♦ Precisos: Pueden ser convertidos para transmitir

componentes de sistema, que puedan ser probados de

nuevo por el minispec.

♦ Comprensibles: Pueden ser emitidos por sujetos

especialistas en la materia.

Los criterios más importantes para un minispec son que las especificaciones

muestran el estado de las reglas que relatan las salidas y las entradas. Los

minispec, permiten declaraciones internas y externas. Las externas son usadas

para definir el efecto del proceso y para examinar la prueba formal de

correcciones. Las otras son usadas para describir como los procesos son

construidos.

La declaración de los procesos se lleva a cabo mediante una gran variedad de

formas. Sin embargo, existen estándares YSM para hacer esto, pero no hay un

rango de estilos y herramientas de modelado que satisfagan a todas.

Ejemplo:




72

PROCESOS: Actualización de sueldos al personal con nivel salarial < 6

ENTRADAS DE FLUJO DE DATOS: Porcentaje de incremento

SALIDAS DE FLUJO DE DATOS: Incrementos otorgados

ENTRADAS DEL FLUJO DE EVENTOS: __

SALIDAS DEL FLUJO DE EVENTOS: __

DATOS DE ENTRADA ALMACENADOS: <Puestos> (Atributos: cvepue, nivsal, etc.)

DATOS DE SALIDA ALMACENADOS: <Puestos> (Atributos: salario)

NOTA TEMPORAL: Nombre Valores Incremento de sueldo moneda corriente

TERMINOS LOCALES: <Puestos anterior>: : = <Puestos> con nivel salarial < 6

FUNCIONES LOCALES: __

FUNCION (EXTERNA): ___

FUNCION (INTERNA):

1. Por cada <Puesto anterior> ejecuta las siguientes 3 operaciones:

1.1. Pago del incremento <Puesto anterior>. Multiplica por el porcentaje de aumento 1.2. <Puesto anterior>. Sueldo incrementado 1.3. <Puesto anterior> < 6 El resultado es: el incremento otorgado a esos niveles




73

3.5.15 Especificación de operación

Muchas de las operaciones simples son proporcionadas por YSM:

♦ Hay operaciones permitidas por cada tipo de dato estándar

abstracto.

♦ Operaciones tales como: “señales”.

♦ Una gramática de acceso de datos.

Estas operaciones resultan ser del todo prometedoras, para un mayor número de

empresas.

YSM también permite nuevas operaciones a ser definidas y adicionadas a

aquellas que están disponibles. Cada una que es agregada en esta forma, requiere

de negociación de especificación. Además solicitan de una o más entradas para

retornar uno o más resultados.

Ejemplo:

OPERACIÓN: Cálculo de quinquenios

SIGNIFICADO: calcula el no. de quinquenios que le corresponde a cada empleado, con base a su fecha de ingreso.

ARGUMENTOS: Argumento Tipo Dirección N.E. No. de empleado entrada Fec_ing Fecha de ingreso entrada No_quinq. Número de quinquenios salida




74

3.5.16 Especificación del flujo de datos

Es usado para especificar flujos de datos y sus componentes. Por lo tanto,

cualquier flujo de datos visto en forma de DFD tiene uno correspondiente de

especificación.

Cuando este tipo de flujo contiene algunos datos de que ocurren al mismo tiempo,

la información que acontece cada vez es llamada como un grupo de datos. Ambos

flujos de datos discretos y continuos pueden estar contenidos en forma múltiple.

Ejemplos:

USO: Operaciones aritméticas: No empleado y fecha de ingreso Procedimiento de cálculo: Cálculo (N.E. y F.I) retorna N.Q. Texto: Proceso de cálculo tomando como base el número de empleado y la fecha de ingreso.

DEFINICION: A:= Int(N.E.) B:= Date(F.I.)

FLUJO DE DATO: Solicitud de préstamo a corto plazo

SIGNIFICADO: Registro de información de las veces en la cual el empleado ha solicitado un préstamo.




75

FLUJO DE DATO: Nombre del empleado

ESTRUCTURA: Elemental


ENTIDAD: Préstamo

ATRIBUTO: Nombre

FLUJO DE DATO: Checa el fondo acumulado

ESTRUCTURA: Elemental

SIGNIFICADO: Al aval se informará que en caso de que el empleado no pague el préstamo, él tendrá que responder por si mismo.


ENTIDAD: ___

TYPING: Abstracto

ADT: Nombre y dirección

ESTRUCTURA: Grupo

COMPOSICION: Nombre del empleado + Checa fondo acumulado | contactar con la dependencia que otorga los préstamos. + Si solicita más de lo ahorrado, necesita aval. + 1 {Fondo acumulado más la parte del aval}




76

Flujo de datos

Cada flujo contiene un único nombre que es usado para su propia especificación.

Los que no son componentes pueden tener el mismo nombre como cualquier otro

o ser parte de él. Si se da un diálogo, la primera entrada vendría a ser el iniciador

y la segunda la respuesta.

Significado

Esta entrada otorga la verdadera significancia del dato para el sistema.

Estructura

Esta entrada puede contener alguno de los siguientes cuatro valores:

♦ Elemental: Es un flujo de dato que es simple o único y que es

una parte indivisible del dato. Para datos continuos son datos de

cantidad y para discretos cada vez que exista, este tiene un solo

valor en una instancia de tiempo.

♦ Grupo: Es un flujo discreto, que consiste de algunas partes del

dato. Cada vez que es definido como un grupo existente, hay una

o más ocurrencias de este paquete de datos.

♦ Diálogo par: Sólo puede ser especificado como un diálogo par,

si han sido proporcionados dos nombres.

♦ Múltiples: Es una representación de muchos flujos, los cuales no

tienen conexión temporal.




77

Composición

Si la estructura es de “Grupo”, la composición de entrada proporciona los

contenidos del flujo y la estructura de una ocurrencia en el mismo. Se dice que si

el tipo es múltiple, no tiene una composición. Un grupo está conformado haciendo

uso de la inclusión, selección, iteración y construcciones opcionales.

Inclusión

Cada uno de los componentes son listados, separados un “+” los cuales son leídos

como “juntamente” o bien Y. Dos campos que son unidos por el signo “+” ocurren

al mismo tiempo. Como ejemplo podemos mencionar el siguiente:

Nombre del empleado + tipo de contratación. En este caso se dice que

tanto el nombre como el tipo, no se pueden dar en forma independiente.

Selección

Este es usado para indicar que exactamente un posible componente, estaría

presente en algún tiempo determinado. Ejemplo:

La primera selección nos muestra cómo se abre un corchete, seguido del

delimitador “|” el cual es utilizado por esta referencia.

[Checa el fondo acumulado | Persona con quien contacta | Dependencia que otorga el préstamo]




78

Iteración

Un dato puede consistir de algunas iteraciones de otros datos. Esto es denotado

por lo mostrado a ser repetido dentro de un par de llaves. Esto debe ser leído

como una “iteración de”. Por ejemplo:

El número 1 (uno) que está antes de abrir la llave, indica las iteraciones a ser

llevadas a cabo, en este caso es el más bajo. Ejemplo:

1 {en cuántas quincenas descontar el préstamo} 20, en este caso se dice que las

iteraciones serán de 1 a 20.

Persistencia

Para un flujo de dato declarado como elemental, éste se da si el flujo es discreto o

continuo; por lo tanto, ambos valores son permitidos. Si algún flujo es declarado

como grupo, deberá estar compuesto por discretos. Los continuos sólo pueden ser

contenidos por múltiples.

Typing

Para datos elementales que no tienen atributos, los estados de los valores de los

elementos de datos, son definidos en términos de un tipo de dato abstracto o

bien, dado como una lista de valores explícitos.

1 {Fondo propio + la parte correspondiente del aval}




79

Adt (Tipo de dato abstracto)

Las dos especificaciones (Nombre + dirección) ambos usan ADT, por lo tanto

deben ser definidos como:

TIPO DE DATO ABSTRACTO: Nombre + dirección

SIGNIFICADO: Se utiliza para poder proporcionar información sobre los empleados.

ESTRUCTURA: Compuesta

COMPONENTES: Componente Tipo Nombre Alfanumérico Dirección Alfanumérico




80

3.5.17 Tabla entidad – función

La tabla entidad – función es utilizada como una herramienta de modelado de alto

nivel, para visualizar la relación entre funciones llevadas a cabo y la información

requerida para soportar esas funciones.

Esta herramienta es útil en lo siguiente:

♦ Planeación estratégica: Las tablas de entidad función

pueden ser usadas para estudios de dependencia entre

unidades de empresas económicas o de algunos posibles

sistemas. Los estudios son relacionados a las actividades

de planeación estratégica.

♦ Modelando proyectos: La tabla puede ser utilizada para

proporcionar información de las funciones entre un

sistema.

♦ Uso de tablas de entidad – función en la empresa y

sistema: Una tabla entidad - función usada como parte

del modelo esencial de empresa, es referido como una

tabla de función entidad empresa. Ejemplo:

Tabla de entidad - función

(Parte 1)

Función Listado y admon. Producc. Empl. de empleados. Avisos DEPENDENCIAS Crear, borrar, actualizar

Nombre de la tabla

Función

Acceso




81

Tabla 3.2

EMPLEADOS Crear, borrar, Checar y leer Leer actualizar

EMPLEADOS Crear, borrar, Checar y leer Leer actualizar

Listado de depend. (<Depend.> es selecc. Crear, leer, Para asignarse a un borrar, checar Leer Empleado con <Psto.> Respectivo.

Puesto “Sindicalizado” Crear, leer, borrar, Checar, cambiar Leer

Puesto “Confianza” Crear, leer, borrar, Checar, cambiar Leer Match, actualizar Selección <Ticon> Crear, borrar, leer, Leer, Checar, cambiar Checar

<Ticon> asignado a Crear, leer,

borrar, match empleado <Tipo Contratación> Crear, leer Leer

Entidad

Relación

Entidad Asociativa

Subtipo




82

3.5.18 Accesos

Son otorgados por la vista para el uso de relaciones o entidades para la función.

Los accesos permitidos son:

v Crear: La función una nueva ocurrencia de la entidad o relación.

v Match: La función necesita saber si una ocurrencia específica de

la entidad o relación existen.

v Lee (sólo para entidades): La función necesita conocer de la

existencia de valores de atributos, que han sido previamente

asignados en una creación o actualización.

v Actualización (sólo entidades): La función puede cambiar o

asignar valores de atributos para una entidad.

v Borrar: La función puede destruir una o más ocurrencias de la

entidad o relación.

v Checar: La función se encarga de examinar el estado correcto de

una variable, para determinar una respuesta correcta.

v Cambiar: Cambia de estado a una variable estado.

Entidad Asociativa

Si una entidad asociativa es usada por un grupo de funciones, entonces el nombre

es apropiado aquí y la fila nos da el uso que cada función hace. Ejemplo:

Listado de dependencias

(<Depende> es seleccionada para asignarla a un empleado al cual le

corresponde un puesto <Puestos>) y que por consiguiente

conlleva a un tipo de contratación “Sindicalizado” o “Confianza”

<Ticon>.




83

Esto indica que la entidad asociativa “listado de dependencias”, actúa como una

relación y además se refiere a la “<Depende>”, “<Puestos>” y “<Ticon>” como

entidades.

Especificación de datos almacenados

Este se encarga de definir cuáles entidades y relaciones son incluidas en el

almacenamiento. Es utilizado para checar el interlineado que se da entre un DFD

y un ERD. Los DFD muestran información almacenada haciendo uso de un

nombre, el cual contiene información relacionada con una o más entidades y/o

relaciones. La especificación de un dato almacenado es el que define exactamente

cuáles entidades y relaciones están representadas por un icono de

almacenamiento. Ejemplo:

El nombre es proporcionado por el propio almacenamiento. En todo sistema, cada

dato guardado tiene un único nombre el cual servirá para identificarlo.

Relaciones

Este tipo de entrada identifica cualquier relación que exista en el propio

almacenamiento. Por ejemplo:

DATO ALMACENADO: Puesto seleccionado

ENTIDADES:___

RELACIONES: <Empleado> se asigna un <Catálogo de Puestos>

ALMACENAMIENTO INCLUIDO:__




84

Esta relación corresponde a una de tipo binaria. Es decir, cada ocurrencia se

refiere a una de la entidad <Empleados> y la otra a la de <Puestos>.

Especificación del flujo de acceso

Esta forma de especificación se encarga de proporcionar un detalle específico el

cual, accesa el dato almacenado. Todos los flujos de este tipo cuentan con

especificaciones dependiendo de las técnicas de soporte. El uso de esta

herramienta de modelado, es opcional. La información que está contenida en esta

especificación es enteramente redundante, con su propio contenido del dato de

acceso almacenado. Ejemplo:

<Empleado> se le asigna un <Catálogo de puestos>

STORE: Tipos de contratación

PROCESOS: Checar el tipo de asignación

FLUJO DE ACCESO:__

Composición: <Ticon> (<Titular de la dependencia> solicita sea asignado a un empleado un <Ticon> para un empleado de un departamento en particular) Crear(atributos: tipo contratación y descripción), Actualizar(atributos: tipo contratación y descripción), Checar(Estado de la variable: status), Cambia(variable estado: status).

SIGINIFICADO:__




85

En este caso Store es el nombre del flujo, el cual es especificado e identificado

por: El nombre del flujo, nombre del proceso y el del acceso. El nombre del

proceso es el acceso para el almacenamiento especificado.

Especificación del sistema evento

Se dice que un evento es algo que:

v Ocurre fuera del límite permitido de un sistema.

v El sistema debe responder.

Estos eventos se dice que son externos al sistema, porque ocurre en cualquier

otra parte de la empresa. En cualquier caso, son eventos que se dan fuera del

entorno del sistema en cuestión. La especificación del sistema evento describe

cómo un sistema específico trata con el propio evento.




86

CAPITULO 4

EL MODELO ESENCIAL DE EMPRESA

4.1 Introducción

El modelo esencial de empresa (EEM) es un modelo de la información de la

empresa. Eventos y funciones se utilizan en la compañía y sirven para integrar

sistemas, de tal manera que la empresa pueda ser pensada verdaderamente como

una “Constitución de sistemas diversos”. El EMM no es una implementación

supuesta, sino que más bien es conceptual o esencial. El EMM es la empresa

equivalente al modelo esencial de sistema; por lo que cada uno de ellos es un

subconjunto del EMM.

El EMM permite modelos de sistemas para ser construidos con accesos

consistentes en funciones y eventos para la información de la empresa. Los usos

específicos del EMM son:

♦ Planeación estratégica: Como su nombre lo indica, es la fase

planeación e iniciación de los proyectos de sistemas requeridos por la

empresa.

♦ El uso de la misma información, por más de un sistema.

♦ Identificación de eventos y efectos de algunos sistemas: Esto

suele ser importante en las correctas determinaciones y alcances del

sistema.

♦ Modelando las interfaces entre los diferentes sistemas, pero

respetando los límites permitidos.

El Modelo Esencial de Empresa



87

Con respecto de cada aplicación basada en computadora como un sistema

independiente, resulta ser una estrategia que permitirá a largo plazo una ineficacia

aunado a problemas de operación. Las funciones y la información están propensas

a ser duplicadas y con posibles inconsistencias.

Links (enlaces) para la biblioteca de recursos de la empresa

Esta biblioteca contiene recursos que son utilizados por la empresa, contrastando

con el EMM, el cual contiene todo la información y funciones que son usadas por

la misma compañía.

Diferencia entre el EEM y la biblioteca de recursos de la

empresa

La biblioteca de recursos de la empresa contiene componentes “útiles”, que

pueden ser utilizados para la construcción de sistemas. El EEM es la definición de

toda la información y función que utiliza la empresa.

Suposición de modelos

El EEM se concentra básicamente en el significado o el sentido de la información.

Funciones y eventos, antes que cualquier otra técnica son llevados a cabo para

soportar estos tipos de requerimientos. También puede ser asumida para ser

soportada por tecnologías perfectas. Este almacenaje y procesamiento ideal, tiene

las siguientes características:

♦ Capacidad de almacenamiento ilimitada

♦ Cero instrucción de tiempo

♦ La información es organizada haciendo uso de entidades, relaciones con

atributos y variables estado.




88

♦ La información nunca se pierde, borra o corrompe, fuera de un acceso

deliberado de una actividad de solicitud de borrado.

♦ Derivaciones, reglas de relación y de integración y participación

restringida, son definidas en el EEM.

♦ Las operaciones son llevadas a cabo con precisión infinita.

Naturaleza estratégica del modelo esencial de empresa

Para construir un EEM se requiere de un mayor empeño o compromiso de

recursos para ponerse en marcha, sobre una escala de tiempo larga. Sin embargo,

es importante que todo esfuerzo que se haga en este sentido, evite problemas

como resultado de un desarrollo no coordinado de algunas aplicaciones por

computadora. Estos conflictos incluyen duplicación de esfuerzos, inconsistencias

de información en algunos sistemas, etc. En algunas organizaciones, la naturaleza

estratégica de información es claramente reconocida y no es difícil para obtener

recursos y manejarlos de manera corporativa. Los EEM son de mayor importancia

en cuanto a la planeación estratégica propiamente dicha.

El EEM describe la suma total de la información. Funciones y eventos son

utilizados por toda organización. Cada usuario debe ser enterado de alguna parte

de este modelo. Hay por consiguiente múltiples vistas, cada una corresponde al

subconjunto de actividades de la empresa a la que un usuario en particular es

comprometido. (En este contexto, el término usuario se refiere a algún agente que

lleva a cabo parte del trabajo de la empresa, Incluye a ambos gente y sistemas de

aplicación).




89

4.2 Estructura del modelo esencial de empresa

Muchas de las herramientas de modelado usadas en el EEM son también

incorporadas como vistas en el modelo esencial de sistema.

Para distinguir estos dos usos de la misma herramienta de modelado, un prefijo

identificador es adicionado. Así un diagrama de entidad relación empresa (ERD

empresa), es usado como parte del EEM; un ERD sistema es usado como parte

de un modelo esencial de sistema.

4.2.1 Aspectos del modelo esencial de empresa

Este modelo comprende dos aspectos:

♦ Aspecto de la información de la empresa: Se encarga de describir

la información que es utilizada por la propia empresa.

♦ Aspecto del funcionamiento de la empresa: Describe las fracciones

de eventos y el número de ocurrencias del aspecto de los componentes

de la información.

4.2.2 Aspectos de la información de la empresa

Estos aspectos se encargan de describir la información que se usa en la empresa.

El ERD es implementado para destacar las características “estáticas” de la

información. También proporciona la mayor semántica en cuanto al significado de

la misma.

Los diagramas de transición estado son utilizados para destacar las “dinámicas” de

los efectos que acontecen en esta información y cuándo.




90

Nota: El tipo de dato abstracto y las especificaciones de operación de la compañía,

son parte de la librería de recursos de la misma. Las especificaciones de texto son

implementadas para definir el detalle al nivel más bajo.

En particular, este detalle incluye los atributos de las entidades y las reglas de

participación de la relación. Estas vistas apropiadas son mostradas a continuación

de manera junta, con enlaces entre componentes mostrados por líneas entre ellos.

Modelo esencial de

Empresa

Librería de

Recursos de la

Empresa

Diagrama de entidad-relac.

tabla de entidad-evento

Tabla de entidad-función

Diagrama de Transición E-S

Subtipos de especificación

Relación de especificación

Entidad de especificación

Entidad asociat. de especific.

Atributos de especificación

Especificación operación-emp.

ADT de especificación




91

4.2.3 Estructura del aspecto de la información

♦ Diagrama de entidad relación: Esta es la principal herramienta de

modelado que se utiliza para declarar los componentes de los aspectos

de información de la empresa. Nos muestra entidades, asociaciones,

relaciones y subtipos.

♦ Tabla de entidad evento: Muestra la interacción de eventos empresa

con entidades y relaciones de un alto nivel.

♦ Tabla de entidad función: Nos enseña un panorama general de todas

las funciones dentro de la empresa, así como el uso que se le da a la

información. Puede proporcionar un mayor detalle, mostrando funciones

individuales que estén al alcance de los sistemas de mayor importancia.

♦ Diagrama de transición entidad - estado (eSTD): Cada entidad

puede contar con una o más variables estado. Por cada una de éstas, la

STD muestra la secuencia en la cual los eventos ocurren y los cambios

que se dan en las variables.

♦ Entidad de especificación: Cada entidad que no es asociativa, tiene

una correspondiente de especificación, la cual incluye una definición de

atributos.

♦ Relación de especificación: Al igual que la anterior, cada relación

tiene una correspondiente de especificación.

♦ Especificación de entidad asociativa: Cada entidad asociativa,

cuenta con una correspondiente de especificación de la misma. Esta

incluye la definición de los atributos de la entidad.

♦ Especificación de subtipos: Cada subtipo de una entidad. Tiene una

correspondiente de especificación.

♦ Especificación de atributos: Cada atributo de una entidad, cuenta

con una correspondiente de especificación. Esta entidad deberá

aparecer por lo menos en un ERD.




92

4.2.4 Visibilidad del ERDs en la empresa

El principal componente de información aparece en un ERDs. Aunque algunos

pueden aparecer en más de uno. Las entidades pueden aparecer en más de un

ERD. Deberán hacerse presente por lo menos en uno. No existe ninguna notación

especial para mostrar que una entidad aparezca en algunos ERDs.

Toda relación debe aparecer en un ERD. Usualmente no aparecen en más de un

ERD, aunque éstas dependen mucho de la técnica de soporte que se use. En

ambientes automatizados, no poseen problema alguno. En una entidad asociativa

podrán aparecer una o más vistas como una sola.

Subtipos en ERDs

Estos son mostrados en forma cotidiana en un diagrama de entidad relación ERD.




93

4.3 Estrategias para la construcción y mantenimiento de la

EIA

Si no hay EIA existentes, entonces forzosamente necesitan ser creadas; si hay

EIA, habrá que mantenerlas como requerimientos de cambio de información para

la empresa.

4.3.1 Principales estrategias para la recolección de

información

Existen tres estrategias principales que pueden ser adoptadas en la construcción y

aspectos de información de la empresa:

1. Factor de recolección: Las entidades, relaciones y atributos que son del todo

relevantes para las actividades de la empresa, se modelan sin considerar

cualquier implementación de especificación o uso, ya sea en forma presente o

futura.

2. Modelando usos de información existentes: Es la presencia de datos en

forma de archivos, registros, bases de datos, etc. En este caso se efectúa un

estudio para identificar el contenido de la información. A esto también se le

llama como una especie de “Ingeniería Contraria”, donde las decisiones de un

diseño previo de actividades están sin o por hacerse.

3. Identificación de la información para el soporte de las funciones de la

empresa: Las funciones específicas de la empresa son examinadas y su

información es usada para identificar los requerimientos. Estas funciones,

también pueden ser una especie de sistemas anticipados o bien catalogados

dentro de una planeación estratégica.




94

4.4 Heurísticas para construir y refinar el EIA.

Técnicas para la construcción de un nuevo EIA, usando

factores basados en el modelado de información.

La captura del modelado de información y los aspectos abstractos más

importantes del mundo real son factores usados por la empresa. Estos a su vez no

son creados por el analista, pero es el responsable para formular una

representación y la organización de los mismos.

Los factores de información basados en este tipo de análisis resultan ser muy

efectivos, ya que la información recolectada y la técnica de síntesis pueden

utilizarse para construir un modelo. Como un ejemplo de ésta técnica supone el

factor de seguimiento que ha sido establecido durante la intervención de los

usuarios.

Como podemos observar, este es un factor de modelo con dos componentes

ligados entre sí. Empleados y departamentos resulta ser una generalización de

todo un conjunto de hechos provenientes del mundo real.

Los empleados son asignados a los departamentos

Juan Pérez es asignado al departamento de Contabilidad

Pedro Páramo es asignado al departamento de Calidad




95

Esto es, donde “Juan Pérez” y “Pedro Páramo” ambos son similares en el sentido

de que ellos son empleados. Además, el modelo es elemental desde el punto de

vista de que no pueden ser descompuestos en unidades más pequeñas sin que

pierdan el significado. Los componentes atómicos son “Empleados” y

“Departamentos”. Ahora supongamos los siguientes factores de modelado:

Estos también son del tipo elemental e involucran a dos componentes atómicos.

Sin embargo, estos factores modelo son de un tipo diferente de procedimientos.

En este caso. ”Empleados” y ”Departamentos” resultan ser una abstracción los

cuales pueden desempeñar un papel de objetos basados en el mundo real.

“Nombre y salario” corresponde a las propiedades descritas por cada ocurrencia

del empleado. Hay por lo tanto, atributos de modelado de “Empleados”. En forma

sintetizada se muestra en la siguiente figura:

4.4.1 Recolección de Hechos

El modelado de información requiere forzosamente que los hechos sean basados

en el mundo real:

Los empleados tienen nombres

Los empleados tienen salarios

Empleado Departamento Es Asignado

a




96

1. Capturados: Las fuentes para estos hechos incluyen entrevistas a los

usuarios, declaración de políticas en la empresa, documentos y estándares

externos.

2. Resumidos: Los hechos se encuentran a menudo en una forma muy

específica, por ejemplo: “Juan se encarga de llevar el orden “Pérez, López y

Martínez trabajan en el procesamiento”, etc.

3. Organizados: El EIM es un modelo integrado que está organizado para

muchas vistas. El modelo individual de componentes debe estar localizado en

una vía tal, que mantenga la integridad y su entendibilidad.

Técnicas de entrevistas

El punto principal es el establecimiento de hechos, así las entrevistas deben ser

organizadas para que puedan finalizar. Un acercamiento informal no estructurado,

es probablemente apropiado para iniciar entrevistas con usuarios quienes no han

sido comprometidos o involucrados en tales ejercicios para la recolección de

hechos. Esto a su vez alentaría confianza en cuanto a la habilidad del analista para

comunicar y no alarmar al usuario con un método de intimidación.

Las siguientes técnicas son útiles para identificar entidades, relaciones y atributos.

La selección dependerá de la reacción y adiestramiento del usuario:

1. El ERD puede ser dibujado interactivamente durante la entrevista. Estos

hechos con cuestiones o preguntas adicionales tales como: “Que información

vamos a necesitar para almacenar X?” donde “X” es el nombre de la entidad en

el diagrama.

2. Captura de una serie de patrones de hechos durante la entrevista: Estos

pueden ser sintetizados más tarde y dibujados en un ERD. A continuación

Ejemplificaremos este patrón de hechos:

Un <Empleado> está asignado a <Dependencias>




97

Esto nos ayuda a clarificar que hay entidades llamadas “Empleados” y

“dependencias” con una relación entre ellas.

3. Usar representaciones tabulares de la información requerida. Esta es una

técnica de acercamiento a bajo nivel pero que trabaja bien. Para entidades

incluyendo las asociativas una representación tabular de los atributos puede

ser muy útil. Por ejemplo: Cuando hablamos de la entidad asociativa

“asignación”, el analista deberá dibujar una tabla con el siguiente formato:

Tabla 4.1

Cada fila de la tabla corresponde a una ocurrencia de la entidad, relación o de

asociatividad. El uso de tablas induce a una reacción positiva del usuario. Sin

embargo, tiene algunos riesgos en el sentido de que los enlaces entre tablas no

son claramente visualizados. Para evitar esta serie de problemas que se generan

habrá que establecer el siguiente fragmento del ERD:

No. de Listado de Empleado Titular Fecha de Asignación Dependencias Asignación




98

4.4.2 Establecimiento de los ciclos de vida de las entidades

Cada entidad puede tener una o más variables estado. Estas a su vez, describen

una característica de los cambios que sufren las entidades fuera de tiempo. No

todas las entidades tienen variables estado, aunque hay algunas que tienen más

de una. Por ejemplo en el archivo “Empleados” las variables estado son: “estatus

del empleado”, “estado civil”.

Identificación de eventos que afectan una entidad

Las siguientes preguntas son lo suficientemente productivas para este caso:

♦ Se cuenta con más de un posible evento creación? Diferentes eventos

del mundo real pueden ocurrir, los cuales causan que la empresa cree

una ocurrencia de la entidad, posiblemente con atributos.

Titular

Listado de Dependencia

s

Asignación

Empleado




99

♦ Existen algunos eventos que causan valores a ser asignados a atributos,

después de que la ocurrencia de la entidad haya sido creada?.

Observando cada atributo de la entidad, resulta un poco molesto decidir

si siempre habrá un valor, si debe cambiar y si es además una buena

estrategia.

♦ Hay algún evento que cause que la entidad participe en una relación?. Si

el evento crea una ocurrencia de la relación pero no requiere de un

acceso a la entidad, este evento no aparecerá en el eSTD.

♦ Hay algún evento relacionado para las entidades que participen en

relaciones con esta entidad?. A menudo existen eventos que afectan a

un grupo de entidades y la relación entre ellas. El uso de la tabla

entidad – evento nos proporciona una mejor visibilidad al respecto.

♦ Hay alguna función conocida que utilice esta entidad?. Si los hay, los

eventos del mundo real de esta función responden a ser probablemente

uno de los que requieren acceso a esta entidad.

Una vez identificado la versión del primer corte de los eventos que afectan la

entidad, el siguiente paso será localizar los estados. Por cada estado y evento uno

de los siguientes debe ser verdadero:

♦ El evento es siempre tratado con el mismo sentido; en este caso, la

acción no es requerida y el estado está hacia la izquierda de éste.

♦ El evento siempre es ignorado otra vez, no hay problema y el estado de

éste se encuentra hacia la izquierda.

♦ El evento es tratado algunas veces en un sentido y otro; esto puede ser

debido a que las reglas de participación en una relación u otra

“memoria” acontecieron en el pasado.




100

4.4.3 Normalización

Principios generales

El concepto general de normalización se refiere a que hay ciertos criterios de

deseables de naturaleza estructural para que todo modelo de información deba o

pueda ser conformado. Estos criterios han sido dados en forma de números

arbitrariamente y si el modelo de componentes que lo conforman está dicho para

ser sucesivamente en primera, segunda, tercera, etc. Forma normal. Por lo tanto,

no es del todo verdadero decir que la normalización sea meramente estructural

como muchos de los criterios involucrados con semánticas, pero es ciertamente

más concerniente con la sintaxis que con el propio significado, comparado con el

modelo de entidad relación ERD. Sin embargo, normalización es una técnica muy

útil particularmente organizando un modelo de datos almacenados o bien, para

checar que las técnicas de semántica aplicadas o defendidas por YSM hayan sido

correctamente aplicadas.

Básicamente las reglas de normalización están encaminadas a eliminar

redundancias e inconsistencias de dependencia, en el diseño de las tablas.

Representación tabular de los datos

Para llevar a cabo la normalización imaginemos una “tabla de valores”. Esta a su

vez, puede ser transcrita de una estructura de archivo. Alternativamente para una

entidad propuesta la asociación o la relación, las ocurrencias del modelo de

componentes deben ponerse como filas en la tabla, ya que las columnas

corresponden a uno de los siguientes:




101

♦ Atributos: La entrada en la célula corresponde al valor del atributo

para las ocurrencias de la entidad la cual se encuentra en la fila de la

tabla.

♦ Variables de estado: La entrada en la columna corresponde al

estatus actual de la variable para la ocurrencia de la entidad

correspondiente a la fila.

♦ Referencias de relación: La entrada en la columna corresponde

a una vía de identificación de una fila a otra de la tabla. Este tipo de

columna es usualmente llamada llave o clave foránea. YSM reemplaza

las llaves foráneas por la relación equivalente y documentada

acordemente. En documentaciones de archivos existentes no podrá

aparecer inmediatamente ya que hay llaves foráneas.

Normalización entonces, se aplica a pruebas o test semejantes a tablas, cualquiera

que sea original. La normalización es esencialmente aplicada solo a datos

almacenados. Está dirigido permanentemente para evitar la duplicación de los

datos con problemas consecuentes en el mantenimiento e integridad. YSM permite

la falta de atributos almacenados para ser derivados de otros.

A continuación haciendo uso de nuestro ejemplo de estudio del “sistema de

nómina”, llevaremos a cabo la normalización de algunas tablas con el propósito de

tener un panorama más claro al respecto. Existen 5 pasos progresivos para

normalizar una base de datos, pero para ello habrá que considerar que es

necesario crear una base de datos (BD) funcional y eficiente.

1. Primer nivel de formalización – normalización (F/N)

Se dice que una tabla está en formar normal, si la tabla es rectangular con un

simple valor e cada columna y una ocurrencia en cada fila.




102

Supongamos que queremos crear una tabla con la información de los empleados

de nómina de nuestro caso de estudio y los datos a guardar son los siguientes:

Nombre del empleado, nombre de la empresa, dirección de la

dependencia, descripción del puesto, tipo de puesto e-mail o url si es

que lo tienen.

En principio comenzaríamos por definir la siguiente tabla:

Empleados

Nombre Dependen. Dirección Puesto Tipo puesto url1 url2

Juan Sistemas T. Q. 80 Encargado A C Abc.com Xyz.com

Pedro R. humanos 16 Sep. 266 Aux. AdmvoB S Abc.com Xyz.com

Tabla 4.2

En este caso podemos decir que nuestra tabla está en nivel de normalización cero

(0), ya que ninguna de nuestras reglas de normalización ha sido aplicada. Observe

los campos url1 y url2 ¿Qué haremos cuando en nuestra aplicación necesitemos

una tercer url?. ¿Quieres agregar otro campo columna a tu tabla y tener que

reprogramar toda la entrada de datos de tu código?. Obviamente no, lo que se

quiere es crear un sistema funcional que pueda crecer y adaptarse fácilmente a

los nuevos requerimientos. Para dar solución a este problema, recurramos a la

regla de primer nivel de normalización y la apliquemos a nuestra tabla.

a) Elimina los grupos repetitivos de las tablas individuales

b) Crea una tabla separada por cada grupo de datos relacionados

c) Identifica cada grupo de datos relacionados con una clave primaria.

En este caso estamos rompiendo la primera regla cuando repetimos url1 y url2.

¿Qué pasa con la tercera regla, la clave primaria?. Esta regla significa básicamente

que hay que poner un campo tipo contador autoincrementable para cada registro.




103

De otra manera, ¿Qué pasaría si tuviéramos dos empleados llamados Juan y

queramos diferenciarlos?. Una vez aplicado el primer nivel de formalización –

normalización (F/N), nos conduciría a la siguiente tabla:

Empleados

Id_empl Nombre Dependen. Dirección Puesto Tipo puesto Url1

1 Juan Sistemas T. Q. 80 Encargado A C Abc.com

1 Juan Sistemas T. Q. 80 Encargado A C Xyz.com

2 Pedro R. humanos 16 Sep. 266 Aux. AdmvoB S Abc.com

2 Pedro R. Humanos 16 Sep. 266 Aux. AdmvoB S Xyz.com

Tabla 4.3

Como podemos observar, se ha solucionado el problema de la limitación del

campo url. Más sin embrago, nos encontramos con otros inconvenientes; cada vez

que introducimos un nuevo registro en la tabla empleados tenemos que duplicar el

nombre de la dependencia y del puesto, para solucionar esto apliquemos el

segundo nivel de F/N.

2. Segundo nivel de formalización – normalización

a) Crear tablas separadas para aquellos grupos de datos que se aplican a

varios registros.

b) Se relacionan estas tablas mediante una clave externa o foránea.

Hemos separado el campo url en otra tabla, de tal forma que vamos a poder

añadir registros en el futuro sin tener que duplicar los demás datos. Por

consiguiente, también vamos a utilizar la clave primaria para relacionar estos

campos.




104

Empleados

Id_empl Nombre Dependencia Dirección Puesto Tipo puesto

1 Juan Sistemas T. Q. 80 Encargado A C

2 Pedro R. Humanos 16 Sep. 266 Aux. Admvo B S

Tabla 4.4

Id_url RelId_empl url

1 1 Abc.com

2 1 Xyz.com

3 2 Abc.com

4 2 Xyz.com

Tabla 4.5

Ahora hemos creado tablas separadas y la clave primaria en la tabla empleados

id_empl, está relacionado con la clave externa en la tabla urls relId_empl. Más

sin embargo, ¿Qué sucede cuando queramos agregar otro empleado a la

dependencia sistemas?, ¿O 150 empleados?. Nos encontramos con el nombre de

la dependencia duplicados; esto mismo sucede para el caso de puesto. Para

resolver este problema tendremos que aplicar la tercera forma normal.

3. Tercer nivel de formalización – normalización

a) Eliminar aquellos campos que no dependan de llave o clave.

El nombre de la dependencia así como el de la dirección de la misma, la

descripción del puesto y el tipo de puesto no tienen nada que ver con campo

Id_empl; por lo tanto, deberán tener su propio Id_dep e Id_psto.




105

Empleados

Id_empl Nombre RelId_dep RelId_psto

Juan Juan 1 1

Pedro Pedro 2 2

Tabla 4.6

Id_dep Descripción de la dependen. Dirección de la dependencia

1 Sistemas Torres Quintero no. 80

2 Recursos Humanos 16 de septiembre no. 266

Tabla 4.7

Puestos

Id_psto Descripción del puesto Tipo de Puesto

1 Encargado A Confianza

2 Auxiliar administrativo B Sindicalizado

Tabla 4.8

Id_url RelId_empl Url

1 1 Abc.com

2 1 Xyz.com

3 2 Abc.com

4 2 Xyz.com

Tabla 4.9

En este caso ya tenemos la llave primaria Id_dep en la tabla de dependencias

relacionada con la clave externa relid_dep en empleados. Esto mismo sucede en

el caso de los puestos.

Dependencias

Urls




106

Como consecuencia de esto se podrá añadir 150 empleados, mientras que nada

más se necesita insertar una vez el nombre de la dependencia “sistemas”.

Nuestra tabla de empleados y urls podrán crecer todo lo que sea necesario, con la

seguridad de que no habrá duplicación ni corrupción de datos.

La mayoría de los analistas y desarrolladores dicen que con tercer nivel de

normalización es más que suficiente; sin embargo veremos la cuarta y quinta

forma normal aunque no sean del todo necesarias.

Antes de definir este cuarto nivel de formalización – normalización, recordemos los

3 tipos de relaciones que se dan entre los datos: Uno – a - uno, uno – a –

muchos y muchos – con – muchos. Observemos la tabla empleados en el primer

nivel de normalización. Ahora bien, imaginemos por un momento que ponemos el

campo url en una tabla separada y cada vez que introduzcamos un registro

también agregamos una sola fila en la tabla de urls. Entonces tendríamos una

relación de uno – a – uno: cada fila en el archivo empleados tendría exactamente

una fila correspondiente a cada url. Para efectos y propósitos de nuestra

aplicación, no sería útil la normalización. Ahora bien, observemos las tablas en el

ejemplo de la segunda forma normal. Estas a su vez, permiten a un solo empleado

tener asociadas varias urls. Esta es una relación de uno – a – muchos y resulta ser

el tipo más común.

La relación varios – con – varios, resulta ser ligeramente un poco más compleja.

Echemos un vistazo al ejemplo del tercer nivel de forma normal, en el cual un

empleado está relacionado con varias urls. Vamos a cambiar la estructura para

permitir que varios trabajadores estén relacionados con muchos urls, con lo cual

las tablas quedarían de la siguiente manera:




107

Empleados

Id_empl Nombre RelId_dep RelId_psto

Juan Juan 1 1

Pedro Pedro 2 2

Tabla 4.10

Dependencias

Id_dep Descripción de la dependen. Dirección de la dependencia

1 Sistemas Torres Quintero no. 80

2 Recursos Humanos 16 de septiembre no. 266

Tabla 4.11

Puestos

Id_psto Descripción del puesto Tipo de Puesto

1 Encargado A Confianza

2 Auxiliar administrativo B Sindicalizado

Tabla 4.12

Urls

Id_url Url

1 Abc.com

2 Xyz.com

Tabla 4.13




108

Relación_url

Id_relación RelaciónId_url RelaciónId_empl

1 1 1

2 1 2

3 2 1

4 2 2

Tabla 4.14

Para disminuir la duplicación de los datos (este proceso nos conducirá al cuarto

nivel de normalización), hemos creado una tabla que sólo tiene claves externas y

primarias “Relación_url”.

Además, fuimos capaces de reconocer las entradas duplicadas en la tabla urls

creando la tabla relación_url, con lo cual podemos decir que la relación que ambos

Juan y Pedro tienen entre cada uno de ellos son las urls.

Con base a lo anterior, veamos exactamente qué es lo que el cuarto nivel

supone:

a) En las relaciones varios – con – varios, entidades independientes

no pueden ser almacenadas en la misma tabla. Estos sólo se

aplican a las relaciones muchos - con – muchos.

La mayoría de los analistas y desarrolladores pueden ignorar esta regla en forma

correcta. Pero resulta bastante útil en ciertas situaciones tal como ésta. Hemos

optimizado la tabla urls eliminando duplicados y hemos puesto las relaciones en su

propia tabla. Finalmente, para concluir con este punto de normalización, se dice

que existe un quinto nivel de forma normal el cual resulta un poco esotérico, ya

que en la mayoría de los casos, no es necesario para lograr una mejor

funcionalidad en nuestra aplicación.




109

4.5 Mantenimiento del aspecto de información de la empresa

El mantenimiento del aspecto de información para la empresa, es una actividad de

abrir - finalizar. El modelo necesitará ser cambiado para tomar en cuenta las

modificaciones en cuanto a los requerimientos de información de la compañía.

El mantenimiento de actividades puede ser dividido en las siguientes categorías:

1. Adición de nuevos datos: Estos pueden ser ambos:

v No es identificado como parte de la información de la empresa,

aunque de hecho hayan sido utilizadas. Esta omisión necesitará ser

remediada.

v Nuevos requerimientos de información de la empresa. Cambios

consecuentes en las actividades de la compañía o en el medio

ambiente bajo el cual operan. En cualquier caso, el modelo de

entidad empresa (EEM) debe ser extendido para incluir el o los

nuevos datos. Un problema que aparece, es que es potencialmente

un nuevo dato, aunque es de hecho así, un dato existente es

referenciado bajo otro nombre. Esto se lleva a cabo mediante un

“aliasing” (suposición).

2. Borrado de datos: Sobre un período de tiempo la operación de la

empresa puede cambiar, así que cierta información ya no será requerida.

Esto entonces lleva a ser removida del aspecto de la empresa.

Esto no es un problema trivial, porque en una empresa grande muchos nombres

diferentes son probables de ser usados por la misma cosa.




110

Si esta inquietud no es tomada en cuenta, un modelo de componente puede ser

duplicado con nombre diferente. Este es un problema general y no existen

rigorosas vías o caminos de identificación de aliases (supuestos). Sin embargo, la

similitud entre dos componentes es la principal pista para los aliases. Por ejemplo:

v Si dos entidades participan en la misma relación o tienen una lista de

atributos muy similares, entonces ellos podrán ser supuestos (aliases)

aún cuando sus nombres sean diferentes.

v Dos relaciones son parecidas si tienen el mismo orden y se refieren a la

misma entidad, entonces podrán supuestos. Aunque se parezcan, se

refieren a diferentes entidades y pueden ser las mismas con alias.

v Si dos atributos de una entidad tienen el mismo tipo de dato abstracto

ADT, entonces podrán ser supuestos (aliases). Si tienen uno o dos

valores que son distintos, entonces viene a ser la pista menos fuerte y

así sucesivamente.

4.5.1 Técnicas para adicionar nuevos requerimientos en un

modelo existente

Estas peticiones o solicitudes pueden ser propuestas en forma manual o

electrónicamente, pueden ser semiautomáticas en ambientes CASE sofisticados

que tienen facilidades para construir modelos de sistemas y soportados por la

empresa como manejador de recursos de información. Estas operaciones y

decisiones son visibles y controladas por el analista de información.




111

4.5.2 Adiciones para el EIA (Aspecto de información de la

empresa)

Comparando el uso de información con el EIA, resulta conveniente llevarla a cabo

por medio de “Laying” (Colocación) el sistema de información con vistas “on

top” del diagrama de empresa. Por ejemplo, todo el sistema ERDs debe

corresponder a la parte de un ERD empresa, conteniendo todas las entidades y

relaciones usadas por el sistema. Conceptualmente, podemos mostrar los sistemas

de información que se usan como parte de este largo ERD con algunos

componentes destacados o sobresalientes. Por ejemplo:

En un sentido similar al ciclo de vida entidad empresa, debe ser un subconjunto

de los ciclos de vida de la empresa. Atributos usados deben ser incluidos en

aquellos que han sido especificados como existencias disponibles.




112

Para que todo esto funcione de una manera adecuada y funcional, se debe hacer

lo siguiente:

♦ Se modifica el modelo existente

♦ Resolviendo aliases (suposiciones)

♦ Adicionando nuevas entidades

♦ Adicionando nuevas relaciones

♦ Convirtiendo relaciones en entidades asociativas

♦ Adicionando nuevos atributos

♦ agregando nuevos subtipos

♦ Incorporando nuevos tipos de datos abstractos (ADT)

Si no se hizo uso de un sistema existente o planeado de un componente EIA, este

puede ser un serio candidato a ser desaparecido del modelo. Esto puede ocurrir

por un “excesivo entusiasmo” del modelado de información que fue más allá

del alcance de las actividades de la empresa.

Por lo tanto, también se puede hacer que esto sea más funcional llevando a cabo

lo siguiente:

♦ Retirando atributos no utilizados

♦ Quitando relaciones no usadas

♦ Suprimiendo entidades que no nos sirvan

♦ Eliminando entidades asociativas

♦ Retirando subtipos que no sean del todo útiles.




113

4.5.3 Efectos sobre la biblioteca de recursos de la empresa

Si no se usan atributos como un tipo de dato abstracto específico, no será

requerido por la empresa y puede ser removido de la ERL (Biblioteca de recursos

de la empresa).

Esta es una vista extrema y no toma en cuenta la posibilidad de que los atributos

puedan ser seleccionados para usar este ADT en algún tiempo futuro.




114

CAPITULO 5

LA RELACION ENTRE EL SISTEMA Y LA EMPRESA

5.1 Introducción

El sistema y el medio ambiente

El sistema es una colección de funciones e información organizada para uno o

varios propósitos específicos. Este a su vez puede existir o bien estar en plan de

construcción.

Un sistema es apropiado en un gran medio ambiente conteniendo organizaciones,

personas y dispositivos con los cuales el sistema interactúa. El límite o la frontera

entre el sistema y el medio ambiente, define el alcance del sistema o bien, qué tan

grande es el sistema.

La empresa como una colección de sistemas

La empresa consiste de muchos sistemas. Desde otro punto de vista, es por sí

mismo un sistema. Conteniendo funciones e información, en forma ordenada para

alcanzar o lograr la misión que se propuso la compañía.

De hecho, la distinción entre la empresa y un sistema es un relativo uno. La

empresa es un sistema en el cual pueden haber otros pequeños o subsistemas.

Ciclos de vida del sistema Algunos proyectos de sistemas se ejecutarán en paralelo y lo harán dentro de la

empresa.

Relación entre Sistema y Empresa



115

Los modelos de empresa deben soportar estas actividades simultáneamente, en

forma continua o muchas veces mientras estén todavía bajo construcción.

La empresa y los modelos de sistemas

La empresa y los modelos de sistemas sirven para diferentes necesidades, pero

pueden traslaparse en muchas otras áreas. Estos son beneficios para la compañía

y los proyectos de sistemas pero deben ser controlados y explotados para un

completo aprovechamiento.

Soporte de la empresa para modelos esenciales de sistemas

El modelo esencial de empresa (EEM) define la suma total de la información a

cerca de la empresa. Cada sistema cuenta con un modelo esencial de sistema

(SEM) el cual se encarga de definir las partes de la compañía.




116

El mantenimiento del EEM requiere de un equipo de modelado de sistema para

garantizar que el modelo a construir sea consistente con el EEM, tal como se

muestra a continuación en la siguiente figura:

Biblioteca de recursos de la empresa tipos de dato Operaciones Alquiler de abstractos de empresa de proyectos Requerimientos estratégicos Requerimientos para el soporte Requerim. esencial de sistema de los empleados modelo esencial modelo esencial de empresa de sistema Implementación Proyectos de los planes Implementación de charter de la los requerimientos empresa para el soporte del sistema Implementación de los requerim. del empleado Implementación Biblioteca de Implementación de los modelos de recursos de la de los modelos de empresa empresa sistema

Mantto.del modelo

esencial de empresa

Identific. del sistema

de Nómina

Facilidades para el

diseño de la empresa

Diseño

del sistema




117

Biblioteca de recursos de la empresa

La empresa como biblioteca de recursos, define todos los recursos que se

encuentran disponibles en la compañía. Al usar esta biblioteca, se cuenta con los

siguientes beneficios:

v Re Utilización de las funciones lógicas y de las especificaciones:

Las operaciones de especificación permiten que las funciones sean

definidas una vez y utilizadas en muchos sistemas.

v Abstracción en la representación de los datos: Los tipos de datos

abstractos pueden ser especificados aunque no tengan atributos o algún

otro tipo de dato elemental que haya sido definido como ADT.

v Implementación de recursos compartidos: esto se da sin

necesidad de duplicar el trabajo. Estos recursos incluyen bases de datos,

bibliotecas de objetos, subrutinas y algún software en común.

La relación entre la biblioteca de recursos de la empresa el modelo esencial de la

misma y el sistema se muestran a continuación:

SEM

EEM Biblioteca de recursos de la empresa

Aspectos

de información

Aspectos del funcionamiento

Aspectos de información

Atributos

Operaciones

Tipos de dato abstractos ADT

Minispec




118

5.2 Iniciación del proyecto de sistema

Al decidir cuáles sistemas se van a construir y cuándo, es un importante problema

de tipo estratégico. Por lo tanto, las metas de la compañía son examinadas y en

consecuencia se toman decisiones en las cuales se eligen los límites del sistema y

cuándo los proyectos deberán ser iniciados.

5.2.1 Modelos de empresa y planeación estratégica

Los proyectos de sistema son iniciados para el beneficio de la empresa. Toda una

disciplina de negocios sabe cuando una planeación estratégica existe con el

propósito de ayudar en la propia identificación y comienzo del sistema. El modelo

esencial de empresa (EEM) puede ayudar en la planeación estratégica de la

compañía con el fin de decidir cual sistema tendrá el mayor costo – efectivo para

comenzar con la apropiada distribución de los recursos. El costo beneficio y el

estudio de factibilidad puede efectuarse para garantizar oportunamente el inicio

de un proyecto de sistema.

5.2.2 Proyectos charters

Un proyecto charter es una definición del protocolo para la investigación y posible

construcción de un sistema. Puede incluir identificación preliminar sobre el alcance

del sistema, en términos de eventos, funciones, entidades y relaciones entre el

responsable del mismo.

La tabla entidad - función (vista anteriormente) es muy útil en cuanto a

planeación estratégica se refiere.




119

Esta se encarga de mostrar las relaciones entre las funciones llevadas a cabo y la

información requerida para soportar las mismas. Estas tablas también pueden ser

usadas para estudiar las dependencias entre las unidades económicas de la

empresa o de algunos posibles sistemas. Estos estudios son actividades de

planeación estratégica.

Por ejemplo, supongamos tres posibles sistemas que están bajo consideración.

Específicamente si el sistema “A” es definido como la creación de una entidad (o

relación) y “B” como lectura de un atributo de la entidad o del conjunto de

relaciones, entonces “B” es dependiente de “A” o bien “B” no podrá trabajar si

“A” no ha sido construido previamente. Esto implica una relación de dependencia

entre sistemas.

Si B depende de A y C de B (posiblemente de A también). En este caso no hay

mucho problema, ya que el sistema A debe ser construido primero después B y

luego C. Pero desgraciadamente las cosas no resultan ser tan simples, es más

probable que B dependa de A, C de B y A de C. Cuando esto ocurre hay dos tipos

de elección:

♦ Desarrollo de algunos sistemas en paralelo

♦ Reorganización de los límites del sistema propuesto y re-examinar

la dependencia.

Es para esta segunda opción que la tabla entidad – función resulta del todo útil

para visualizar la relación entre funciones.

Este concepto es bastante útil. La información puede estar organizada en los

siguientes tipos:

♦ Privada: se usa solamente dentro de un sistema




120

♦ Propia: es propia de un sistema el cual es responsable de la

integridad.

♦ Compartida: Usada dentro de algunos límites. La información es

verdaderamente compartida entre sistemas y de ninguno es

propia.

Un sistema es definido como una unidad propia de información, si todos los

puntos siguientes son verdaderos:

♦ El sistema es el responsable de crear y usualmente borrar las

ocurrencias del dato.

♦ Si el dato es una entidad, el sistema es el responsable de asignar

valores a los atributos y de cambiar las variables de estado.

♦ Si el dato es una entidad, otros sistemas no asignan valores a los

atributos o cambios en las variables de estado.

♦ Otros sistemas no crean ni borran ocurrencias del dato.

Cualquier información que no sea propia o privada es compartida. Aunque los

datos privados no tienen implicaciones de dependencia ambos, es decir, propios y

compartidos si lo tienen. Un dato que es propio de un sistema y utilizado por otro,

crea una dependencia entre dos sistemas. Esto puede ser visualizado usando una

tabla de entidad – función. El siguiente ejemplo muestra tres sistemas propuestos

así como también, los modelos de componentes de información C1, C2, C3, ....

entre cada sistema, las posibles funciones son F1, F2, F3, las cuales fueron

permitidas. Cualquier dato que sea creado actualizado o borrado es señalado con

un sombreado. (Las variables de estado fueron omitidas de la tabla para efectos

de simplificación).




121

Estos datos son potencialmente propios (si otros sistemas no tienen un sombreado

en la celda en esta fila), compartidos (si dos sistemas tienen un sombreado en la

celda de esta fila) y finalmente son privados (si otra celda en esta fila no tienen

una entrada).

SISTEMAS Y FUNCIONES INCLUIDAS

SISTEMA A SISTEMA B SISTEMA C

Cc componente

de

Información F1 F2 F3 F4 F5 F6 F7 F8 F9 F10

C1 c r d r

C2 c,r,u,d r r

C3 R r,u,d c r

C4 r c d u r

C5 B c,u d r

C6 r c d r

C7 c,u R d R r r

C8 r c d r r

C9 r C,u U,d

Tabla 5.1

Debe ser claro que si F4 es reasignado del sistema B al A, entonces estos tendrían

una simple dependencia, así que A es construido antes que B, el cual a su vez

debe ser construido antes que C. La tabla puede también ser clarificada

cambiando a una forma diagonal para clarificar la relación entre los sistemas:




122

SISTEMAS Y FUNCIONES INCLUIDAS SISTEMA A SISTEMA B SISTEMA C

Componente de

Información F1 F2 F3 F4 F5 F6 F7 F8 F9 F10

C1 c r D r

C2 c,r,u,d r r

C3 R,u,d c r

C7 C,u R d r r r

C8 r c d r r

C4 r c d u r C9 r C,u U,d

C5 C,u d r

Tabla 5.2

Esta forma diagonal es la preferida de las tablas entidad – función. Puede ser

difícil evitar elegir los límites del sistema que vengan a prevenir más, teniendo la

responsabilidad de crear ocurrencias de una entidad. Por ejemplo en una

compañía de servicios como puede ser nuestro caso de estudio de Nómina del H.

Ayuntamiento de Colima, habrá muchas actividades de la institución que causen

una nueva ocurrencia de “empleados” a ser identificados.




123

5.3 Construcción del modelo esencial de empresa

Cuando el sistema es la empresa

En algunas situaciones, el alcance cubierto por un sistema es toda la empresa. Un

ejemplo puede ser un software doméstico sobre un contrato específico para

soportar un cliente. La economía de la empresa para este tipo de software es

precisamente la empresa. Entonces el alcance de los modelos de empresa y

sistema son lo mismo, ya que pueden ser desarrollados en paralelo por el mismo

personal. Sin embargo, todos los modelos estarían todavía en construcción.

5.3.1 Construcción en primer lugar del modelo esencial de

empresa

Los modelos de empresa pueden ser construidos independientemente de cualquier

actividad del proyecto de sistema. La construcción de modelos empresa comienza

por ser proyectos a sí mismos. Una vez que los modelos de empresa están en un

sitio determinado, los proyectos cuentan con toda la información disponible. La

elaboración de un modelo de sistema comienza a manera de ordenamiento de las

partes que son de interés, además de una reorganización de las vistas

especializadas para el sistema.

Hay una primera desventaja en la construcción de modelos de empresa.

Dependiendo del tamaño de la misma elaborar estos modelos puede tomar un

largo tiempo y por ende mayores recursos. A fuerzas la compañía debe elegir una

de las siguientes opciones:

♦ Suspender todos los proyectos de sistema que puedan utilizar estos

modelos, mientras sean proyectos existentes. Esto no resulta del

todo factiblemente económico.

Relación entre sistema y Empresa



124

♦ Permitir que los proyectos de sistema continúen como antes y

profundizar en los problemas de alias y de integridad de datos malos

o muy pobres.

♦ Soportar ambos la independencia y coordinación en la construcción

de modelos, los cuales requieren de un mayor cuidado y de más

recursos.

5.3.2 Solicitud para el mantenimiento del modelo de empresa

En casos donde los modelos de empresa no están completos o bien estén siendo

creados o ya existan, el proyecto de sistema puede pedir que el modelado de

empresa soporte su área y que tenga una alta prioridad independiente del propio

modelado.

El sistema es restringido para usar solo información que provenga de aquellos

modelos. Si como acontece a menudo el proyecto de sistema descubre alguna

información no contenida en aquél, tal como un evento, o un atributo requerido

de una entidad en particular, éstas peticiones deben ir inmediatamente a los

modelados de empresa.

Si porque los recursos son limitados o bien por cualquier otra razón esto no

ocurre, el grupo del modelado de empresa no es soportado largamente por los

proyectos de sistema que se están ejecutando. Si no es soportado por otros

proyectos de sistema, los de modelado es muy probable que fallen. Estos a su vez

serán forzados para que finalicen y abandonen en forma tentativa y de manera

sincronizada con las necesidades de la empresa a largo plazo y por lo tanto el

sistema no será consistente con las definiciones del mismo. Existe también la

posibilidad de no ser del todo consistente con otros o futuros sistemas.




125

5.3.3 Desarrollo de la empresa y los modelos de sistemas en

paralelo

La empresa y los modelos de sistema captan información similar. La mayor

diferencia es un punto de vista: los modelos de empresa captan información

considerando a la empresa de manera total; éstos a su vez se enfocan a las

necesidades específicas de tal manera que la información esté en el sistema.

Todos los modelos de sistema dependen de la preexistencia de uno de empresa.

En realidad la empresa no le puede tomar todo el tiempo para detener las

actividades de los proyectos de sistema, si no hasta finalizar con todo el conjunto

de modelos de empresa.

La empresa puede construir suficientes modelos con el propósito de sugerir cuál

proyecto de sistema debe comenzar o continuar. Entonces, a condición de que

exista una coordinación cuidadosa y de un buen manejo, la empresa y los modelos

pueden realizarse en el mismo lapso de tiempo.

Para construir un sistema y un modelo de empresa en paralelo, los recursos

necesarios, el tiempo y movimiento para la elaboración de las partes requeridas de

los modelos de empresa debe coexistir con la necesidad de recursos de tiempo y

movimiento para poder completar un proyecto de sistema. Si no, el proyecto

padecerá en tratar de conseguir la información necesaria del modelo de empresa

antes que esta pueda continuar.




126

5.3.4 La relación entre la empresa y los aspectos del sistema

de información

El aspecto de información de la empresa es un modelo estático que describe cada

entidad dentro de la misma, atributos y relaciones entre entidades. Este aspecto

junto a aquellas partes de información, entidades, relaciones y eventos que están

dentro del alcance del sistema. Estas vistas deben ser un subconjunto consistente

de que está ya en el modelo esencial de empresa. (SEM). El modelo de empresa

se alimenta de información. Los modelos de sistema pueden, mostrar nuevas

áreas de información o recursos que los de empresa no incluyen.

5.3.5 Consistencia entre la empresa y el modelo esencial de sistema

1. Para cualquier sistema entidad habrá una correspondiente entidad empresa

o una asociativa.

2. Para cualquier sistema de entidad asociativa habrá una correspondiente

entidad asociativa de empresa haciendo referencia a las ocurrencias de la

misma con reglas de participación.

3. Para cualquier relación de sistema habrá una correspondiente relación de

empresa o entidad asociativa, haciendo referencia a las ocurrencias de la

misma con sus respectivas reglas de participación.

4. Para cualquier atributo visto en el sistema de especificación entidad habrá

un atributo de especificación en el EEM. Los atributos deben ser para la

misma entidad.

5. Para cualquier relación de acceso vista en una tabal de sistema entidad –

evento habrá un idéntico acceso en la misma tabla.




127

6. Cualquier condición vista en un sistema eSTD debe ser vista en la

correspondiente empresa eSTD. Esta condición puede ser una transición

entre el origen similar y los estados destino junto con la acción en que

dicha transición deba ser igual.

7. Cada sistema evento debe tener uno correspondiente de especificación

empresa (también tiene un evento de especificación de sistema como parte

del modelo esencial de empresa. (SEM).

8. Cada función mostrada en una tabla de sistema función – entidad debe

tener una correspondiente función en una tabla de empresa entidad –

función.




128

CAPITULO 6

EL MODELO ESENCIAL DE SISTEMA (SEM)

6.1 Introducción

Papel que desempeña el modelo esencial de sistema

Un modelo esencial de sistema es una representación underlying de un sistema de

Nómina. Esta política deberá llevarse a cabo sin importar qué tipo de

implementación será elegida.

El SEM es una declaración o un informe de requerimientos para todo sistema. El

modelo está enfocado en los negocios, al mundo real o alguna otra materia. Este

mismo modelo forma parte del esencial de empresa (EEM). Las vistas que son

parte del SEM son descritas por el “sistema” y es algo que la “empresa” prefija. En

todos los casos, el sistema “prefijo” puede abandonarse cuando ocasione

confusión con respecto al resultado.

Usos

El SEM sirve como auxiliar en:

♦ Valida los requerimientos de los empleados o usuarios: Como el

modelo es libre de salidas no relacionadas para el mismo asunto, los

usuarios finales pueden decidir si el modelo es una declaración

exacta de los propios requerimientos.

El Modelo Esencial de Sistema



129

♦ Verifica contra otros documentos que contengan requerimientos: La

estructura del modelo permite checar de nuevo los documentos y

requisitos escritos en el sistema, para revisar que hayan sido

cubiertos.

♦ Verifica los sistemas existentes: La estructura del modelo permite el

seguimiento de los componentes o partes del sistema existente, para

garantizar en forma total su consistencia.

♦ Comunicar los requerimientos a todos los que estén involucrados o

familiarizados con la política funcional del sistema: Diseñadores,

nuevos empleados, administradores, etc. Pueden observar al sistema

en cada nivel a detalle, para tener un panorama más general al

respecto.

Libertad de tecnologías previstas o predispuestas

El SEM se encarga de documentar un sistema con el propósito de suprimir

cualquier aspecto de implementación del proceso o de los requerimientos de

almacenamiento. Por ejemplo, un SEM de un sistema de Nómina debería mostrar

el “Número del empleado” y las “horas trabajadas” como todo un sistema de

entrada. Por lo tanto, sería incorrecto que muestre la “tarjeta registradora”. El

uso de una tarjeta de papel contendrá esta información como una implementación

específica. El modelo permite la captura de la solicitud de entrada “número de

empleado” y “horas trabajadas”. Esto a su vez permite la concentración de la

información, antes que el medio lleve o transporte la misma.

El SEM proporciona la política de underlying para poder llevarse a cabo con una

variedad de implementaciones viejas y nuevas. Una organización puede ejecutar o

correr una Nómina en papel o bien de manera computarizada y en cualquiera de

las dos formas se tendrá los requerimientos esenciales.




130

Beneficios del modelo esencial de sistema (SEM)

Algunos de los beneficios que resultan del SEM son usados para capturar la

política esencial con implementaciones incluidas no asumidas:

v Libertad para diseñar el mejor sistema utilizando cualquier

tecnología no permitida.

v El SEM está hecho para suprimir pequeñas tecnologías. Esto

permite ser entendido fuera de los detalles técnicos, haciendo al

modelo un poco más largo y difícil de revisar.

v El modelo es una forma que puede ser comprendido por expertos

en la materia, quienes no están del todo confrontados con los

detalles técnicos e irrelevantes a cerca de la implementación.

El concepto de “Tecnología perfecta”

Ayuda a suprimir la implementación de los detalles; el SEM puede ser visualizado

como una perfecta tecnología en ejecución. Este proceso es ideal en ambientes

que son definidos como una ejecución en un procesador conceptual, con:

v Infinita capacidad de almacenamiento no volátil

v cero instrucción de tiempo

v Habilidad para correr varios de procesos simultáneamente

v No errores

v Toas las entradas / salidas son llevadas a cabo en tiempo zero,

utilizando una forma conceptual, antes que cualquier tecnología

específica.




131

Suposiciones del modelo esencial de sistema

Hay una arquitectura que se asume para el modelo esencial de sistema (SEM).

Esta es:

v El procesamiento puede llevarse a cabo mediante procesos de

datos. Muchos de éstos pueden estar activos en el mismo lapso

de tiempo; también pueden estar en tiempos discretos o

continuos.

v Una entidad relación es un estilo de modelo de datos

almacenados con cero tiempos de acceso y una infinita capacidad

de almacenamiento.

v El control y la secuencia se lleva a cabo por máquinas de estado.

Cada uno de estas puede a su vez comunicarse con otras

máquinas de estado haciendo uso de los flujos de eventos. Estos

equipos pueden activarse (Habilitar / deshabilitar y ser disparados

o puestos en movimiento) por otras máquinas y también por

procesos de datos.

Sistemas Viables

Algunos sistemas pueden ser posibles de manera conceptual pero muy costosa

para ser implementados haciendo del que ya existe y de la tecnología disponible.

Aunque es posible construir y verificar el SEM de tal sistema, es responsabilidad

del analista hacer que el cliente se dé cuenta de las implicaciones del costo.

El SEM es una inversión significativa, por lo tanto el analista debe intentar evitar

elaborar un SEM para el cual no exista una plena justificación de llevarlo a cabo.

Se estima que el costo de implementación debe ser comunicada al cliente de

manera inmediata, con el fin de revisar si es posible refinar el alcance del mismo.




132

El modelo esencial de sistema y el ciclo de vida

El SEM sirve a ambos como una documentación de requerimientos de usuarios

para el sistema y también a la organización de los mismos, como referencia a las

personas que construyen y dan mantenimiento al sistema.

Como los requerimientos del sistema son la parte más crítica para el desarrollo de

los mismos el SEM resulta de vital importancia en el ciclo de vida de un sistema.

Este debe ser siempre el primer modelo a construir, por lo que garantiza al menos

la iteración del mismo. Los requerimientos son la base para el diseño; como éstos

cambian, los diseños también lo hacen en forma por lo más dramática.



133

6.2 Estructura del modelo esencial de sistema

El SEM resulta ser demasiado grande para ser comprendido en una sola sesión y

en forma total. Los modelos son utilizados de acuerdo a las diferentes vistas que

lo conforman. Cada vista muestra parte del modelo que se está usando en una

reseña en particular o bien de la recolección de requerimientos. Todo tipo de vista

se diseña, evalúa y se revisa por un área específica de la empresa.

El SEM requiere de muchas vistas a ser definidas para completar el modelo.

Algunos tipos de vistas son “instancias simples” por ejemplo la declaración de

propósito. Otras a su vez tienen muchas instancias tales como el minispec.

El siguiente diagrama muestra las vistas utilizadas en el SEM colocados de acuerdo

a su posición aproximada, en un triángulo de función – información – tiempo, ver

figura F.



134

6.3 Aspectos del modelo esencial de sistema

Un aspecto es un grupo de vistas en un modelo seleccionando un elemento

sobresaliente de un tipo de negocio en particular. Los aspectos estándar del SEM

se muestran a continuación:

Este aspecto del modelo destaca Estos aspectos se enfocan en el uso

el alcance del sistema y la de los sistemas y la modificación

razón para que éste exista. de la información. Además, la tabla

Se construye antes del aspecto entidad evento se usa para enlazar

funcional. Este aspecto en el medio ambiente;

la tabla entidad – función se

utiliza

para enlazar el aspecto de

información con la del

funcionamiento.

Este aspecto destaca el funcional Este aspecto destaca las salidas como

y dinámico comportamiento del sistema. tiempos de respuesta, el tiempo

Este a su vez es el responsable de las medio entre fallas, la cantidad de

demandas del medio ambiente, y procesos en una unidad de tiempo,

del aspecto ambiental. etc.

Aspecto Ambiental

Aspecto funcional

Aspecto de

Información

Declaración de Propósito

Aspecto de ejecución


Información Mapa de vistas del modelo esencial de sistema

Tiempo Función

Figura F

Diagrama de entidad relación sistema

Tabla entidad función sistema

Tabla entidad Evento sistema

Diagrama de contexto Especif.

Entidad sist.

Lista de eventos

Especif. de terminac.

Minispec

Especif. de Evento

almacenado

Especif. del Flujo de eventos

Diagrama Funcional de

transición estado

Especif. del

Flujo de acceso

Especif. del

Flujo de acceso

Especif. de

procesos

Diagrama de Flujo de

datos

Diagrama de transición

entidad estado

Especific. de datos

almacenados

Especif. Entidad

asoc. sistema

Especif. Entidad

sist.

Especif. de Relación sistema

DECLARACION DE PROPOSITO



135

6.4 Aspecto de información

Los aspectos de información cuentan con el papel principal de “enlazar” el modelo

esencial de sistema con el aspecto de información de empresa. Estoas aspectos

incluyen:

♦ Diagramas de entidad – relación sistema: se utilizan para declarar las

entidades de la empresa y las relaciones usadas por el sistema.

Tabla de entidad evento sistema

Diagrama de entidad relación sistema

Especif. entidad sistema

Diagrama de transición

entidad estado sistema

Relación de especificación

sistema

Especif. entidad

asoc. sistema

Relación especif. sistema




136

♦ Diagramas de transición entidad – estado sistema (eSTDs

sistema): se usa para definir los cambios de estado de las

entidades.

♦ Especificación de entidad – sistema: Se utiliza para definir el uso de

los sistemas de entidades.

♦ Especificación de relación sistema: Para definir el uso de sistema de

relación.

♦ Especificación de entidad – asociativa sistema: se usa para definir el

uso de sistemas en las entidades asociativas.

♦ Tabla de entidad – evento sistema: Nos muestra el acceso a las

entidades y relaciones cuando los eventos ocurren.

♦ Tabla de entidad – función sistema: Esta se encarga de mostrar

cuáles son las funciones de acceso del sistema y cuáles son las

partes del aspecto de información.




137

6.5 Aspecto ambiental

Diagrama de contexto

Lista de eventos

Especif. del flujo de datos Especif.

del flujo de acceso

Especif. del

flujo de eventos

Especif. de

eventos

Especif. de datos

almacenados

Especif. de terminación




138

Estos aspectos incluyen:

♦ El diagrama de contexto: Es el modelo de interfaces del

sistema. Este puede ser un simple diagrama o bien puede ser

roto en forma parcial del diagrama de contexto.

♦ Especificación de terminación: Hay uno para cada terminador

♦ Especificación del flujo de datos: Existe uno para cada flujo de

datos, el cual se muestra en el diagrama de contexto.

♦ Especificación del flujo de eventos: Hay uno para cada flujo, el

se observa en el diagrama.

♦ Especificación de datos almacenados: Cada almacenamiento

es visto en el diagrama. Estos además definen cuales

entidades y relaciones están en él.

♦ Lista de eventos: Define los eventos que el sistema debe

responder.

♦ Especificación del flujo de acceso: Para cada flujo de acceso

nombrado, este debe ser observado en el diagrama.

♦ Especificación de evento: Cada evento cuenta con una

especificación, ambos en el frame o en el formato de la tabla.




139

6.6 Aspecto funcional

Diagrama de flujo de datos

Comportamiento del diagrama

transición estado

Minispec

Especific. de

procesos

Especif. del flujo de datos Especif. del

Flujo de evento

Especif. de Evento

almacenado

Especific. del dato

almacenado

Especif. del flujo de acceso




140

6.7 Aspecto de Ejecución

El aspecto de ejecución es usado para capturar los requerimientos acerca del

sistema en función.

Estas formas de ejecución incluyen:

♦ Especificación de procesos: Cada proceso requiere de un

tiempo de respuesta, el tiempo medio entre fallas (MTBF) y

el tiempo medio para repararlas (MTTR). El procesamiento

requiere de un (número de instrucciones) para cada activación

a su vez es definida.

Especif. de

procesos

Especif. de

transición

Comportamiento del diagrama de

transición estado




141

♦ Los procesos continuos cuentan con una muestra discreta de

frecuencia la cual pueden exceder en un momento dado.

♦ Comportamiento de la especificación de transición estado:

Cada cambio de estado debe tener un tiempo máximo de

estado, para que la transición pueda ser completada después

de convertirse la condición en verdadera.

♦ Especificación de terminación: Cada terminador puede ser

simple o bien multifuncional.




142

CAPITULO 7

CONCLUSIONES

Como primera instancia se puede decir según SEEN que el análisis estructurado

“permite al analista conocer un sistema o proceso (actividad) en forma

lógica y manejable”. Por lo tanto, el objetivo final de éste tipo de análisis es

organizar las tareas asociadas con la determinación de los requerimientos y así

tener una comprensión completa y exacta de una situación dada.

A finales de los años 60’s y los inicios de los 70’s el análisis estructurado surge de

la necesidad de buscar una forma interpretativa más rápida y eficiente, en donde

se puedan definir los requerimientos del usuario y del sistema. Sin embrago esto

todavía no se daba, debido a que existían grandes volúmenes de información que

había que leer los cuales a su vez, traían como consecuencia problemas de tipo:

monolítico, redundancia y ambigüedad.

Como consecuencia de esto, surge una gran variedad de diagramas que permiten

representar las especificaciones funcionales en forma sencilla y de manera rápida,

aumentando con ello el grado de comunicación entre las especificaciones

funcionales y el usuario final (analista, diseñador y programador).

Posteriormente, a mediados de los años 70’s estando el análisis estructurado en

su apogeo y de acuerdo a los avances tecnológicos, trae una serie de

consecuencias que limitan al analista hacer un buen desempeño de sus

actividades. Entre estos problemas según Yourdon están los siguientes:

v Distinción poca y difusa entre los modelos lógicos y físicos.

v Limitación para modela<r sistema en tiempo real.

Conclusiones



143

v El modelo de datos se hacía de una manera muy primitiva.

Estas y otras razones dieron el nacimiento a grandes mejoras en cuanto al

desarrollo estructurado clásico tales como:

v Diagramas de entidad – relación

v Diagramas de transición – estado

v División de eventos

v Modelos esenciales

v Modelos de implantación

Con la incorporación de estas mejoras surge el Método del Sistema Yourdon,

el cual en su momento vino a revolucionar todo lo referente en materia de Análisis

y diseño estructurado ya que a partir de los años 90’s y en la actualidad, se sigue

aplicando para el desarrollo de cualquier tipo de sistema, sin importar los cambios

tecnológicos que se dan día con día.

Para corrobar lo expuesto anteriormente sobre este método, es el estudio que se

hizo del Sistema de Nómina aplicando dicha metodología la cual vino a

comprobar que en la actualidad todavía es operante, ya que no le pide nada a

ningún otro tipo de paradigma que exista en el mercado del Análisis y diseño de

sistemas.

Pero a pesar de todo esto según Yourdon, se siguieron dando problemas tales

como:

v Tras la segunda y tercera corrección de un diagrama, el analista estaba

expuesto a hacer más cambios.

v Debido a la cantidad de trabajo que se requería, el analista dejaba a veces de

dividir el modelo del sistema en los de menor nivel, trayendo como

consecuencia funciones primitivas.

Conclusiones



144

v A menudo no se incorporaban en el modelo del sistema los cambios en los

requerimientos del usuario, sino hasta después de la fase de análisis del

proyecto.

Para subsanar esta serie de dificultades surgen las herramientas CASE las cuales

se utilizan para dibujar diagramas de flujo y de datos entre otros. En la actualidad

muchas de estas herramientas se están utilizando para facilitar la fase de análisis,

disminuyendo con esto la serie de errores que se cometían anteriormente.

Los diversos aspectos del análisis estructurado han cambiado gradualmente a lo

largo de los últimos años. Estos principales esquemas de cambio contemplan lo

siguiente según Yourdon:

v Cambios de metodología

v Partición de acontecimientos

v Herramientas de modelado en tiempo real

v Integración más cercana del modelado de procesos y datos

Y en un futuro no muy lejano se darán si es que ya no se están dando, los

siguientes cambios:

v Mayor difusión del análisis de sistemas en niveles

superiores y organizaciones gubernamentales.

v Impacto sobre la industria del software.

v Mayor proliferación de las herramientas automatizadas.

v Integración del análisis estructurado con la inteligencia

artificial.

Finalmente un enfoque nuevo y diferente al análisis y diseño de sistemas es el

Orientado a objetos (O-O). Los cuales están basados en los conceptos de la

programación orientada a objetos.

Conclusiones



145

Estas a su vez pueden ayudar a responder las demandas organizacionales para

nuevos sistemas que requieran mantenimiento, adaptación y rediseño contínuo.

Básicamente, en este tipo de programación los objetos son creados e incluyen no

solamente código acerca de los datos, sino también instrucciones sobre las

operaciones que se realizan con ellos.

Usando el enfoque de Coad y Yourdon al análisis O-O, empleamos cinco capas

las cuales consisten en lo siguiente:

1. Capa de clase / objeto

2. Capa de estructura

3. Capa de atributos

4. Capa de servicios

5. Capa de áreas

El análisis y diseño estructurado proporciona un enfoque semántico para el diseño

y construcción de sistemas de calidad. A lo largo de las fases el analista debe

proceder paso a paso para obtener retroalimentación de los usuarios buscando

omisión de errores, ya que al pasar demasiado rápido de una fase a otra, puede

provocar que el analista regrese a corregir partes anteriores del diseño.

El objetivo final que nos planteamos en un principio para nuestro caso de estudio

cumplió con las expectativas reales, ya que se logró un mejor y más eficiente

diseño o rediseño del mismo, con respecto del sistema que actualmente se

encuentra funcionando.

Con base al estudio realizado, esperamos obtener los mejores y más eficientes

resultados de nuestro sistema, ya que vendrá a subsanar todas aquellas

deficiencias que se tenían en cuanto a operación y funcionamiento.

Conclusiones



146

Este tipo de metodología es aplicable a cualquier tipo de estudio, ya que un

problema por más complejo que sea, siempre podrá ser resuelto de una manera

fácil y sencilla.

Esta investigación se limitó en saber si el método del sistema de yourdon, era

aplicable a nuestro caso de estudio: El Sistema de Nómina. Con base a esto

podemos decir que sí cumplió con las expectativas finales, ya que se adaptó de

una manera fácil y rápida con respecto a lo que se planeó desde un principio.

Finalmente cabe hacer mención, que en un futuro no muy lejano es necesario

hacer uso de otra herramienta como es el caso del análisis orientado a objetos

(OOA/OOD), ya que es una metodología que hace uso de una descripción breve y

concisa, así como el uso de textos generales como fuentes para las definiciones;

de tal modo que éstas se enmarcan dentro del sentido común y por ende reducen

el empleo de modismos.

Conclusiones



147

CAPITULO 8

BIBLIOGRAFÍA

[1] Yourdon Inc. YOURDON™ Systems Method: Model-Driven Systems

Development.

[2] Henry F. Koth – Abraham Silberschats, Fundamentos de Bases de

Datos.

[3] Kendall y Kendall, Análisis y Diseño de Sistemas.

[4] Senn, Análisis y Diseño de Sistemas de Información.

[5] Apuntes de Metodologías en el Desarrollo de Software.

[6] James Martin – James J. Odell, Análisis Orientado a Objetos.

[7] Jacobson, Ingeniería de Softweare Orientado a Objetos.

[8] Juan Guillermo Lalinde, Tecnologías Orientadas a Objetos.

[9] Booch, Análisis y Diseño de Aplicaciones Orientadas a Objetos.

[10] Raúl Córdova, Comparación entre técnivas Orientadas a Procesos, Datos y

Objetos.

[11] Yourdon, Objected – Oriented Analisys, Press 1991.

[12] Coad & Yourdon, El análisis Orientado a Objetos: El Método.

[13] Farías M.N., Ramos C.F.F. MultiAgents Systems Methodology Based on a

Study of Agent’s Interaction. Proc. of the 2ª Jornada Ibero Americana de

Engenharia de Software e Engenharia de Conhecimento. Salvador Bahia

Brasil, 2002.

universidad de colima sistema de nomina basado en la

Documents