Mario Alberto Lugo Rivero

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 Faras 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
Telfono: 3 1-3-3289

Informo a usted que ha sido aprobado como tema de titulacin para obtener
el grado de
MAESTRO EN CIENCIAS AREA COMPUTACIN

El solicitado por usted bajo el ttulo:

SISTEMA DE NOMINA BASADO EN LA METODOLOGA 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
BIBLIOGRAFA

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

En cada uno de los ejemplares de titulacin que presente para examen, deber
aparecer en primer trmino copia del presente oficio.

A T E N T A M E N T E
ESTUDIA * LUCHA * TRABAJA
Coquimatln, Col., 27 de agosto del 2003.

M.C. RICARDO FUENTES COVARRUBIAS
DIRECTOR

c.c.p.-EXPEDIENTE ALUMNO.

Km 9 Carretera Colima-Coquimatln, Colima, Colima, Mxico, 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
Telfono: 3 l-3-3280

En cumplimiento al artculo: 13 y 14 del reglamento de titulacin, al artculo
40, Inciso A del reglamento de estudios de Posgrado vigente y al artculo: 46 de
las normas complementarias al reglamento de Posgrado, correspondientes al
Posgrado de la Facultad de Ingeniera Mecnica y Elctrica. Informamos a usted
que ha sido autorizado por este Consejo Tcnico del Posgrado su tema de Tesis
para obtener el grado de Maestro en Ciencias rea: Computacin titulado: SISTEMA
DE NOMINA BASADO EN LA METODOLOGA 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 BIBLIOGRAFA

As mismo hacemos de su conocimiento que de acuerdo con la lnea de
investigacin 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 aprobacin tendr como plazo un ao para presentar
su examen de grado, en caso contrario tendr usted derecho a una prrroga nica de
seis meses so pena de perder el registro de su proyecto.

Una vez concluidos los trmites de revisin de su documento de tesis e
integrado su expediente de titulacin deber recoger el oficio que acompaar el visto
bueno de su asesor de tesis, los cuales encabezarn cada uno de los ejemplares de su
tesis.

El Consejo Tcnico del Posgrado de la Facultad de Ingeniera Mecnica y
Elctrica 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 INGENIERA MECNICA Y ELCTRICA
CONSEJO TCNICO DE LA MAESTRA EN COMPUTACIN
PRESENTE.

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

Agradeciendo de antemano la atencin prestada al presente, quedo a sus
apreciables rdenes para cualquier aclaracin.

ESTUDIA*LUCHA*TRABAJA
COQUIMATLN, COL. 14 DE AGOSTO DE 2003

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

A MI S PADRES : A MI S HERMANOS :

Con todo cario, 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 HI J AS :

Con las que compart momentos
de desesperacin, angustia y
tambin alegra; pero lo ms
importante, su apoyo cuando ms lo
necesitaba.

A MI ESCUELA : A TI USUARI O :

Gracias por recibirme y Cuando consultes este
Cobijarme durante dos trabajo, espero te sirva
largos aos y contribuir algo de lo escrito en
a una mejor superacin esta investigacin.
personal.
INDICE GENERAL

RESUMEN EN ESPAOL............................................................................. 1

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

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

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

2.1 Introduccin........................................................................................ 12
2.2 Marco conceptual................................................................................ 27
2.3 Otras metodologas............................................................................. 29

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

3.1 Introduccin........................................................................................ 40
3.2 Diagrama de entidad relacin............................................................ 47
3.3 Diagrama de transicin 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 Introduccin....................................................................................... 86
4.2 Estructura del modelo esencial de empresa........................................... 89
4.3 Estrategias para la construccin y mantenimiento del EIA...................... 93
4.4 Heurstica para construir y refinar el EIA............................................... 94
4.5 Mantenimiento del aspecto de informacin de la empresa.................... 109

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

5.1 Introduccin..................................................................................... 114
5.2 Iniciacin del proyecto de sistema....................................................... 118
5.3 Construccin del modelo esencial de empresa...................................... 123

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

6.1 Introduccin...................................................................................... 128
6.2 Estructura del modelo esencial de sistema........................................... 133
6.3 Aspectos del modelo esencial de sistema............................................. 134
6.4 Aspecto de informacin...................................................................... 135
6.5 Aspecto ambiental............................................................................. 137
6.6 Aspecto funcional.............................................................................. 139
6.7 Aspecto de ejecucin......................................................................... 140

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

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

Sistema de Nmina basado en la metodologa de Coad Yourdon
Mtodo del sistema de Yourdon: (YSM)
1
Resumen en Espaol

Segn Kendall y Kendall [3], fue la aparicin del diseo y la programacin
estructurada alrededor de los aos 60s e inicios de los 70s, la que dieron cabida
al surgimiento del anlisis estructurado, ya que exista la necesidad de utilizar una
notacin grfica 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 - relacin etc. Pero las
preguntas que todos nos hacemos: qu nos espera en un futuro no muy lejano
del anlisis estructurado con la introduccin de nuevas variantes? desaparecer o
se mantendr?.

Tambin segn Seen [4] surge de la necesidad de buscar una forma interpretativa
ms rpida 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 exista eran grandes volmenes de informacin que haba que leer
por completo y que traan como consecuencia una serie de problemas de
monolismo, redundancia, ambigedad e imposibilidad de mantener. Es por ello
que surge una amplia variedad de diagramas que permiten representar las
especificaciones funcionales en forma sencilla y rpida, aumentando con ello el
grado de comunicacin entre las especificaciones funcionales y el usuario final
(analista, programador, diseador). El anlisis estructurado se ha transformado en
una de las metodologas ms divulgadas hoy en da. Para conceptuar esta
herramienta de apoyo a dicha metodologa, se estudia el anlisis de sistemas
como etapa del desarrollo de un sistema, as como tambin su contexto bajo el
enfoque sinttico.

Los requerimientos de automatizacin se derivan de los objetivos del anlisis de
sistemas. Especficamente tienen relacin con la consistencia, exactitud yen forma
completa, intra e inter componentes del modelo de la especificacin estructurada.

2
Resumen en Ingls

According to Kendall and Kendall [3], it was the appearance of the design and the
programming structured around the 60s 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

Propsito del trabajo de investigacin

Este trabajo de investigacin describe El Mtodo del Sistema de Yourdon (o
YSM) y la manera de cmo puede ser utilizado para el soporte y desarrollo de
sistemas. Provee de un informe definitivo de lo que constituye YSM en trminos
de modelos, herramientas y mtodos.

Lo que no contempla este trabajo de investigacin

No intenta actuar como un libro de texto o documento de adiestramiento, no sera
apropiado para ninguno de los dos casos. Tampoco trata de que sea ledo en
forma secuencial, pero s como una referencia sobre tpicos individuales tal como
una herramienta especfica de modelado, modelo o tcnica.

Versin del trabajo de investigacin

Es la primera parte del manual de referencia de YMS. Abarca el anlisis de
requerimientos de sistemas e informacin del mundo real. Partes adicionales,
cubrirn la implementacin de los modelos, la planeacin estratgica, las pruebas
especficas y la calidad asegurada.

De ninguna manera intenta de definir la posicin de YSM en todos los tpicos del
desarrollo y mantenimiento de sistemas. Este estudio trata de consolidar las ideas
utilizadas en cuanto a la enseanza y la cultura.

I ntroduccin

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 econmica
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
especfico. 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 ms 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.

Caractersticas adicionales del mtodo

El principal cambio que presenta ha sido una teora ms rigurosa con respecto al
mtodo. Esto a su vez permitir asegurarse de una mejor calidad y soporte para
las herramientas CASE.

Dos nuevas caractersticas del mtodo es el ciclo de vida de las entidades y
los tipos de dato abstractos.

I ntroduccin

5
Organizacin del trabajo de investigacin

Este trabajo est dividido en los siguientes captulos:

1. Introduccin: Contempla los antecedentes histricos y
las principales caractersticas de YMS.
2. Herramientas de modelado: Describe la grfica y las
herramientas de modelado textual que se utilizan para
construir modelos.
3. El modelo esencial de empresa: Describe cules son
los requerimientos de la empresa que van a ser
modelados.
4. La relacin entre el sistema y la empresa: Describen
cmo los proyectos de sistemas hacen uso de los recursos
de la empresa.
5. El modelo esencial de sistema: Describe cmo un
modelo esencial es construido para capturar los
requerimientos del sistema.

Tipografa utilizada en la investigacin

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

Los modelos de componentes estn en doble comillas por
ejemplo: captura de empleados.
Los trminos tcnicos estn con comilla simple, ejemplo:
fuera de.
Los ejemplos son mostrados en cajas sombreadas para los
fragmentos de texto en el modelo. Por ejemplo:

I ntroduccin

6

Los ejemplos largos para especificar herramientas de
modelado, estn dados por dobles cajas. Por ejemplo:

Pre condicin

Empleado <pertenece> Dependencia
I ntroduccin

7
El Ayuntamiento de Colima se caracteriza por ser una institucin que se encarga
de la prestacin de servicios a la sociedad en general, stos a su vez pueden ser
proporcionados de manera interna o externa; es decir, al pblico en general y a
los recursos humanos que la conforman.

Una de sus funciones internas principales es el pago de la nmina 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 tecnolgico que se tiene da
con da 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 metodologa de
Coad Yourdon y hacer un nuevo planteamiento del mismo para as poder lograr un
mejor diseo y desarrollo funcional de acuerdo a las necesidades que se tienen en
materia de informacin, logrando con esto una mayor eficiencia en la prestacin
de dichos servicios e ir a la vanguardia con la tecnologa que contamos
actualmente.

Tradicionalmente, el anlisis es visto como la definicin de los requisitos del
sistema. Por otro lado, el diseo establece una arquitectura para el software tal
que satisfaga dichos requisitos y permita una posterior implementacin ajustada a
ciertos criterios de calidad. Dicho de otro modo, el anlisis detalla el qu mientras
que el diseo desarrolla el cmo.

El Diseo Estructurado tuvo sus comienzos con la Programacin Estructurada (la
cual incorporaba las tres estructuras de control bsicas de un programa:
secuencia, seleccin e iteracin). El aporte del Diseo Estructurado fue considerar
el concepto de mdulo y la propiedad de modularidad de los sistemas
resultantes como atributo que caracterizaba la calidad de los mismos.

I ntroduccin

8

El Anlisis Estructurado aparece como complemento al Diseo Estructurado. Por lo
tanto, el propsito del Anlisis Estructurado es proveer una tcnica de anlisis que
permita una adecuada transicin hacia el Diseo Estructurado. El Anlisis
Estructurado est basado en el modelado de flujos de informacin y su
transformacin mediante procesos, es decir, el analista se preocupa
fundamentalmente de las funciones que debe llevar a cabo el sistema.

Las propuestas iniciales de Anlisis y Diseo Estructurado se centraban en el
modelado de procesos dejando en segundo trmino el modelado de datos. El
Enfoque Estructurado Moderno sugiere realizar paralelamente el modelado de
procesos y de datos (este ltimo mediante Diagramas Entidad-Relacin 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 especificacin con respecto a los
requerimientos de la funcin de los usuarios.

Si se logra el objetivo de poner en marcha esta nueva metodologa aunado con su
propio desarrollo e implantacin, tendremos como logro fundamental eliminar
todas aquellas deficiencias que se vienen arrastrando con el uso del sistema
anterior y por consiguiente hacer que la Direccin de Recursos Humanos del
Ayuntamiento de Colima contribuya a mejorar los servicios que proporciona y con
ello ir a la vanguardia con los avances tecnolgicos que se tienen da con da en
cuanto a sistemas de informacin se refiera y por ende contribuir a proporcionar
los servicios de una manera ms rpida, eficiente, en le menor tiempo posible y
con el mnimo esfuerzo.

I ntroduccin

9
Actualmente esta institucin, cuenta con toda la tecnologa 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 da con da.

I ntroduccin

10

CAPITULO 2

ANTECEDENTES HISTORICOS

2.1 Introduccin

Etapas en los mtodos del desarrollo de sistemas

La evolucin de los mtodos 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 mtodos en el desarrollo de
sistemas, estos fueron agrupados en 3 etapas las cuales son las siguientes:

Mtodos de la primera generacin
Mtodos de la segunda generacin
Mtodos de la tercera generacin

Mtodo de la primera generacin 1951-1958

Las computadoras de esta generacin emplearon bulbos para procesar
informacin. Los operadores ingresaban los datos y programas en cdigo especial
por medio de tarjetas perforadas. El almacenamiento interno se lograba con un
tambor que giraba rpidamente, sobre el cual un dispositivo de lectura/escritura
colocaba marcas magnticas. Esas computadoras de bulbos eran mucho ms
grandes y generaban ms calor que los modelos contemporneos. Eckert y
Mauchly contribuyeron al desarrollo de computadoras de la 1era Generacin
formando una compaa privada y construyendo UNIVAC I que el Comit del
cens utiliz para evaluar el de 1950. La IBM tena 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, bsculas para comestibles, relojes
Antecedentes Histricos

11
y otros artculos; sin embargo no haba logrado el contrato para el Censo de 1950.

Comenz entonces a construir computadoras electrnicas y su primera entrada
fue con la IBM 701 en 1953.

Despus 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 razn por la que IBM disfruta hoy de una gran parte del
mercado de las computadoras. La administracin de la IBM asumi un gran riesgo
y estim una venta de 50 computadoras. Este nmero 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 rpidamente
por las Compaas privadas y de Gobierno. A la mitad de los aos 50 IBM y
Remington Rand se consolidaban como lderes en la fabricacin de computadoras.

Esta etapa puede ser comparada con varias tcnicas estructuradas de desarrollo
durante los aos 1960s y 1970s. Estas tcnicas rompieron el problema complejo
que haba en los componentes pequeos, mediante relaciones internas bien
definidas entre los componentes. En la actualidad mucha gente todava confa en
esta tcnica como herramienta modeladora.

PROGRAMACION ESTRUCTURADA

Secuencia, seleccin, iteracin y evitando el uso de GOTO.


12

La primera tcnica estructurada contribuy a una mejor organizacin del cdigo
fuente.
Estas a su vez usan construcciones estndar, las cuales pueden ser usadas o
implementadas por cualquier algoritmo. Estos programas son construidos
utilizando bloques de secuencia, seleccin e iteracin.

A su vez estas construcciones estndar fueron reconocidas, sin embargo no todos
los lenguajes de programacin que se usan lo soportan.

DISEO MODULAR Y DIAGRAMAS DE ESTRUCTURA

Adems de estas construcciones, muchos lenguajes de programacin permitieron
que grupos de sentencias fueran reutilizadas. Una parte de estos es llamado:
Programa Modular y su uso es referido como programacin o diseo modular.

Los diagramas de estructura fueron usados para mostrar el sentido en que los
mdulos son conectados al programa.

ESTILOS DE PROGRAMACION

A menudo se usan construcciones estndar sin embargo, el cdigo sera complejo
y dificultara su comprensin o bien, simple y fcil de entender. Este es un estilo
poco usual por su salida tarda en los aos 70s. Las tcnicas de diseo datos que
se usaron en los aos 70s, fueron en su mayora costumbres pragmticas de
construccin de estructuras de datos y archivos para programas de soporte.

La organizacin CODASYL fue una importante influencia en la formulacin de ideas
sobre diseo de base de datos, durante el perodo de 1967 a 1972. En particular
se defini el modelo abstracto para una red de base de datos.


13

DISEO ESTRUCTURADO

Alcance Limitado de la Programacin Estructurada.

Las tcnicas de programacin estructurada solo son dirigidas al diseo en
pequeo. Esta como declaracin individual sera organizada entre un modelo y
una empresa de aceptacin. Este tipo de diseo se hizo a largo plazo, por lo tanto,
fueron diseados 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 diseos
de sistemas apropiados, existe todava un camino en el cual un proyecto pudo
faltar y hacer conveniente los requerimientos de usuario. Para sistemas pequeos,
el requerimiento puede ser entendido por una persona, quien tom la
responsabilidad para asegurase que el requerimiento fue el conveniente. An
cuando no hubo garanta los requerimientos fueron correctamente entendidos.

Con tales problemas, el fracaso o el buen xito del proyecto comienza como un
motivo casual.

Antecedentes Histricos.

14

Modelado de informacin

Al mismo tiempo que las tcnicas de anlisis estructurado fueron desarrolladas,
una aproximacin semntica de modelado de informacin fue formulada. Esta se
bas en entidades y relaciones del mundo real. Sin embargo, el acercamiento de
este modelado de datos fue en los aos 70s y es todava una tecnologa basada y
orientada en relaciones y estructuras de red. Tambin existieron diferentes
filosofas en el desarrollo de sistemas as como procesos y mtodos en cuanto al
manejo de datos. Durante la primera generacin de mtodos estructurados,
analistas y diseadores 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
informacin, particularmente en trminos de identificacin
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
difciles y costosos; Las tcnicas estructuradas fueron avanzando lentamente y
fueron conocidas en forma general y utilizadas hasta los aos 80s.

15
Mtodo de la segunda generacin 1 19 95 59 9- -1 19 96 64 4

Transistor Compatibilidad limitada. El invento del transistor hizo posible una nueva
generacin de computadoras, ms rpidas, ms pequeas y con menores
necesidades de ventilacin. Sin embargo el costo segua siendo una porcin
significativa del presupuesto de una Compaa. Las computadoras de la 2da.
generacin tambin utilizaban redes de ncleos magnticos en lugar de tambores
giratorios para el almacenamiento primario. Estos ncleos contenan pequeos
anillos de material magntico, enlazados entre s, en los cuales podran
almacenarse datos e instrucciones. Los programas de computadoras tambin
mejoraron. El COBOL desarrollado durante la 1era generacin estaba ya disponible
comercialmente. Los programas escritos para una computadora podan
transferirse a otra con un mnimo esfuerzo. El escribir un programa ya no requera
entender plenamente el hardware de la computacin.

Las computadoras de la 2da Generacin eran substancialmente ms pequeas y
rpidas que las de bulbos, y se usaban para nuevas aplicaciones, como en los
sistemas para reservacin en lneas areas, control de trfico areo y simulaciones
para uso genera. Las empresas comenzaron a aplicar las computadoras a tareas
de almacenamiento de registros, como manejo de inventarios, nmina y
contabilidad. La marina de E.U. utiliz las computadoras de la Segunda Generacin
para crear el primer simulador de vuelo (Whirlwind I). HoneyWell se coloc como
el primer competidor durante la segunda generacin de computadoras. Burroughs,
Univac, NCR, CDC, HoneyWell, los ms grandes competidores de IBM durante los
60s se conocieron como el grupo BUNCH (siglas). La segunda generacin tambin
se caracteriza por haber un mayor acercamiento al modelado de sistemas. En la
primera generacin los mtodos desarrollados fueron procesos orientados o
datos orientados y usando modelados en una va justamente informal. En
todos los mtodos de la segunda generacin el esfuerzo principal que se hizo, fue
la construccin y el chequeo de los modelos.


16
En los mtodos de la primera generacin, 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
mtodos de la segunda generacin se consideraron funciones de sistemas y datos
como dos aspectos igualmente importantes del mismo sistema. El uso de software
de computadora ayud en la construccin de sistemas que no fueron comunes
hasta los aos 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 generacin

En la segunda generacin las tcnicas 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 continuacin, 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
difcil de controlar. Las reglas de chequeo de los cruces tambin empiezan a ser
complicados y poco manejables, cuando el nmero de diagramas y
especificaciones se incrementan. Los mtodos de la tercera generacin fueron
distinguidos por una filosofa que es ms concerniente con el todo y poco con las
partes. Estas tcnicas continan con el uso de grficas, pero estos diagramas
sern ms una va de captura y verificacin del modelo antes de l mismo. Este es
el cambio fundamental que constituye la tercera generacin. YSM est
considerado como un mtodo de la tercera generacin.

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 sern 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 dainas.

Los modelos usados por YSM son la fundacin del mtodo. En un sentido general,
un modelo es una es una representacin simple que ayuda a simplificar clculos o
predicciones. En los modelos abstractos, la principal caracterstica es que se
encuentra bajo evaluacin y est de una forma ms utilizable que la propia cosa
real. Con base a resultados del modelo las decisiones pueden ser tomadas. Esto es
mostrado a continuacin:


18
R Empresas
E Abstraccin
A
L
I Los clculos 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 ingeniera son dos ejemplos muy obvios. YSM reserva el trmino
modelo para estructuras especficas 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 difcil 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 especificacin 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 descripcin se parece mucho a la proporcionada por el modelo de la segunda
generacin, donde los modelos fueron definidos como una coleccin de vistas.
La diferencia es que:

Para los mtodos de la segunda generacin, el modelo es igual a
la coleccin de vistas.
Para los mtodos de la tercera generacin, 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 continuacin:

Cada modelo estndar (por ejemplo el modelo esencial de sistema) tiene una
estructura interna la cual es una representacin de toda la informacin en el
modelo (por ejemplo, sistemas especficos y requerimientos esenciales).

Vista A

Vista B

Vista C

Vista D

MODELO
INTERNO

20
El modelado interacta 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 continuacin:

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 estndar, el diagrama de
entidad relacin y el entidad especificacin. Es importante sealar que YSM es un
mtodo de la tercera generacin y que puede ser utilizado para soportar
sofisticadas herramientas CASE. Tambin puede ser usado sin soportar CASE.

Entidades = a,b,g,l;
Relacin d,a,b;
Relacin s,f,m;
Relacin 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. Funcin. Aqu se indica lo siguiente: Qu es lo que el sistema
hace?.
2. Tiempo. Qu pasa cundo?.
3. Informacin. Cul informacin 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. Dimensin de tiempo
2. Dimensin de informacin
3. Dimensin de funcin


22
Caractersticas de los sistemas

Cada sistema tiene una cierta complejidad en trminos de funcionalidad,
funcionamiento en tiempo extra y el uso de informacin. Esto es dado
por los perfiles del sistema, los cuales pueden ser obtenidos por los trazos
y la complejidad por cada dimensin, la definicin usando estos tres puntos de
vista y el origen. Dos de estos perfiles son mostrados a continuacin:

Informacin Informacin

Funcin Tiempo Funcin tiempo

YSM usa los conceptos de aspectos para formalizar esto con respecto al negocio o
empresa. Un aspecto es una coleccin de vistas juntas que especifican los
elementos sobresalientes. Dos aspectos nombrados de un modelo son los que se
ilustran a continuacin:

23

Aspecto de Aspecto
Informacin 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
informacin ilustra sta y que es utilizada por el sistema. Un modelo puede tener
varios aspectos, dependiendo de cmo 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
guas para asegurarse de que es completo, consistente y correcto.

Los modelos pueden ser considerados como secuencia evolucionaria de los
mismos. Como una primera aproximacin, no obstante el siguiente diagrama, nos
proporciona una buena vista:

M O D E L O

ERD
Especificacin
de
Entidad
Especificacin
de
Atributo
Especificacin
de
Evento
Diagrama
de
Contexto
Especificacin
del
Flujo de dato

24

Secuencia de
desarrollo

Una de las actividades de la empresa es la planeacin estratgica. Esta examina
las prcticas actuales y futuras, las entradas y las estrategias de costo - efectivo
para llevar a cabo su terminacin. Muchos proyectos diferentes deben ser
iniciados y para ello debern incluir:

Se consigue equipo nuevo, sitios o invariablemente otras
compaas.
Se aprovecha la infraestructura de la compaa
Provisin de nuevos sistemas que estn por razones especficas.

Modelo
esencial de
sistema
I mplementac.
del modelo
proceso
I mplemantac.
del modelo
de software
I mplementac.
del modelo
de cdigo
I mplemantac.
del modelo
manual
I mplementac.
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: informacin, bases de datos y dems recursos en diferentes
vas por todas partes del ciclo de vida, tal como se muestra a continuacin:

Esta empresa soporta mltiples proyectos de sistema, cada uno de los cuales es
probable que est en una diferente etapa del ciclo de vida.

ANALISIS
DI SEO
IMPLEMENTACION
MANTENIMIENTO
MODELO ESENCI AL
DE EMPRESA
BI BLI OTECA 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 anlisis de sistemas se defini un modelo
de etapas de desarrollo de un sistema de informacin:

Introduccin
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 Anlisis de
Sistemas. Sin embargo, todas coinciden en que en esencia es una actividad de
comunicacin entre las personas que realizan el anlisis y los usuarios finales del
sistema de informacin que se desea implantar.

En el mbito del desarrollo de sistemas informticos, el anlisis consiste en
identificar y especificar el conjunto de subfunciones que han de conformar el
sistema. Para ello, es preciso identificar la estructura de la funcin sometida a
tratamiento informtico, es decir descomponindola en subfunciones e interfases y
luego estudiar su composicin y determinar los cambios estructurales necesarios,
e incorporando, eliminando, agrupando o separando las interfases y as
establecer, cules de ellas sern automatizadas y cules sern manuales, con el
propsito de reinsertarla nuevamente en la organizacin una vez concluida su
construccin e implantacin, ahora definida estructuralmente y con nuevos niveles
de soporte automatizado para el tratamiento de datos y la generacin de
informacin.

Marco Conceptual

28
Entre las metodologas de anlisis de sistemas y tcnicas de especificacin de
requerimientos ms relevantes, se tiene:

a) Structured Requeriments Definition (SRD): metodologa creada por K.
Orr y definida como: Output- Oriented.
b) Diseo Lgico de Sistemas de Informacin Administrativos: metodologa
desarrollada por: O. Barros.
c) Anlisis Estructurado de Sistemas: desarrollada inicialmente por:
Yourdon.

Esta ltima metodologa es la adoptada para nuestro caso de estudio y anlisis.

Marco Conceptual

29
2.3 Otras metodologas

El desarrollo de las metodologas de la ingeniera en software fue propiciado por
la necesidad de atender problemas especficos de la produccin de sistemas cada
vez ms complejos. Si se lleva a cabo un anlisis de los mtodos, puede notarse
una evolucin en la especializacin y el enfoque de los mismos, ya que mientras
en los primeros mtodos cada uno trataba de dar sus propias respuestas, los
nuevos mtodos (particularmente UML) tienen la ventaja de fundamentar sus
propuestas en un estudio crtico de los mtodos anteriores, con el objetivo de
ofrecer una metodologa ms prxima a un estndar.

A continuacin se muestra la cronologa de algunas de las metodologas ms
importantes de la Ingeniera de Software:

v Anlisis estructurado / Diseo estructurado (AS/ DS)
v Desarrollo estructurado de J ackson (J SD)
v Desarrollo de sistemas estructurados de datos (SDSD)
v Anlisis estructurado y la tcnica de diseo (SADT)
v Tcnicas de modelado de objetos (OMT)
v Ingeniera de software orientada a objetos de J acobsen
v Anlisis y diseo con aplicaciones orientadas a objetos de
Boosh
v El lenguaje unificado de modelado (UML)
v Orientacin a agentes

Las metodologas 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 Metodologas

30
Clasificacin de las metodologas:

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 J errquicos.
v No jerrquicos.
v Orientadas a Objetos
v Revolucionarios
v Sintetistas

El anlisis orientado a objetos difiere del anlisis estructurado en dos aspectos:
1. Construir un modelo de objeto, en vez de un modelo funcional, como por
ejemplo la jerarqua 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 continuacin describiremos brevemente las metodologas de mayor importancia
que se utilizaron en el desarrollo del software:

Anlisis estructurado / Diseo estructurado (AS/ SD)

Este tipo de modelo admite los tres grandes modelos ortogonales que son: el
modelo de objetos, el funcional y el dinmico; Esta metodologa hace hincapi en
la descomposicin funcional ya que proporciona una o ms soluciones finales al
usuario final.

Otras Metodologas

31
El AS/DS lo podemos encontrar en todas partes ya que por lo regular se encuentra
bien documentado y adems se utiliza en la solucin de muchos problemas reales
de acuerdo a las propias necesidades.

En el SA/SD durante la fase de anlisis, se utilizan diagramas de flujo de
datos, especificacin de procesos, diagramas de contexto, de flujo, de
transicin estado y de entidad relacin con el propsito de describir
lgicamente el sistema. En la fase de diseo, los diagramas de flujo de datos se
convierten en descripciones de cartas estructurales del cdigo del lenguaje de
programacin.

Coad & Yourdon, han sido los pioneros en el estudio de SA/SD, ya que se
considera este tipo de anlisis como uno de los mtodos orientado a objetos de
los ms sencillos de comprender.

En el caso del Anlisis Orientado a Objetos se ha tenido mucho xito al derribar
problemas que se resisten al anlisis estructurado, como las interfaces de usuario.

Para Coad & Yourdon el acercamiento orientado a objetos consiste de clases,
objetos, herencia y comunicacin 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

Tambin describen un mtodo de Anlisis Orientado a Objetos basado en cinco
actividades principales:
Otras Metodologas

32
1. Localizar las clases y los objetos
2. I dentificar estructuras
3. Identificar asuntos
4. Definir atributos
5. Definir servicios

Coad & Yourdon han publicado un enfoque integral para el anlisis y diseo
orientado a objetos. Para ellos, un diseo orientado a objetos es construido a
partir de 4 componentes que tienen que ser diseados para estas capas:

1. Componente del mbito del problema.
2. Componente de la interaccin humana.
3. Componente del manejo de tareas.
4. Componente del manejo de datos.

A continuacin 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 (lgico) construido con el OOA
en la fase de anlisis. 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 sern uno a uno, y el componente del mbito del
problema podr ser programado directamente. Sin embargo, el refinamiento
sustancial del modelo lgico es normalmente requerido, resultando en la
incorporacin de ms atributos y servicios.

Otras Metodologas

33
2. Los componentes poco amigables en la interaccin humana envan y reciben
mensajes desde el usuario. Las clases y objetos en el componente de
interaccin humana tienen nombres que son tomados desde el lenguaje de
interfaz del usuario, por ejemplo: una ventana y un men.

3. Muchos sistemas tendrn hilos mltiples de ejecucin y el diseador debe
construir un componente de manejo de tareas para organizar el
procesamiento. El diseador necesita definir tareas como manejo de eventos o
manejo del tiempo, as como sus prioridades de manera crtica.

4. El componente de la administracin de datos proporciona la infraestructura
para guardar y recuperar objetos. Puede ser un simple sistema de archivos, un
sistema de administracin de base de datos relacional, o igualmente un
sistema de administracin de bases de datos orientado a objetos.

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

Diversos aspectos del anlisis estructurado han cambiado gradualmente a lo largo
de los ltimos aos.

Las principales reas de cambio incluyen lo siguiente, segn Yourdon:

a) Cambios de terminologa.
b) Particin de acontecimientos.
c) La desenfatizacin del modelado fsico actual.
d) Herramientas de modelado en tiempo real.
e) Integracin ms cercana del modelado de procesos
y datos.

Otras Metodologas

34
En un futuro no muy lejano se piensa que se darn, si es que ya no se estn
dando, los siguientes cambios o pautas en el mbito total en lo que se refiere a
anlisis segn Yourdon:

Mayor difusin del anlisis de sistemas, sobre todo en los siguientes grupos: los
niveles superiores de administracin en organizaciones gubernamentales y de
negocios, los nios y profesionales de la computacin en los pases del tercer
mundo.

Impacto sobre la industria de software del tercer mundo.

Proliferacin de las herramientas automatizadas, aunque no todos los analistas
tienen acceso a las ltimas herramientas de anlisis.

Impacto de los desastres de mantenimiento.

Integracin del anlisis estructurado con la inteligencia artificial.

Podemos adicionar que el futuro del anlisis estructurado va a depender mucho
tambin de qu tan rpido pueda ajustarse el mismo a los cambios tecnolgicos
que se viven hoy en da, debido a que han estado surgiendo ms tcnicas 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 anlisis y diseo de sistemas, es el anlisis y
diseo de sistemas orientados a objetos (O-O). Las tcnicas orientadas a objetos
que se basan en los conceptos de programacin orientada a objetos, pueden
ayudar a responder las demandas organizacionales para nuevos sistemas que
requieran mantenimiento, adaptacin y rediseo continuo.

Otras Metodologas

35
Bsicamente en la programacin orientada a objetos son creados objetos que
incluyen no solamente cdigo acerca de los datos sino tambin instrucciones
acerca de las operaciones que se pueden realizar con ellos.

Usando el enfoque Coad & Yourdon al anlisis 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 anlisis y diseo estructurado proporciona un enfoque sistemtico para el
diseo y construccin de sistema de informacin de calidad. A lo largo de las fases
de anlisis y diseo, el analista debe proceder paso a paso, obteniendo
retroalimentacin de los usuarios y analizando el diseo, buscando omisiones de
errores. El pasar demasiado rpido a la siguiente fase puede requerir que el
analista tenga que regresar para volver a trabajar en partes anteriores del diseo.

Adems de las herramientas CASE se puede usar lo siguiente en diversas partes
del ciclo de vida de anlisis y diseo:

a) Software de administracin: Para administrar la ubicacin de personas y
recursos del proyecto.

b) Software para crear prototipos: Pantallas y reportes que revisen y
modifiquen los usuarios.

c) Herramientas para el diseo de formas: Ayudan en el diseo de formas
de documentos fuente.

d) Software de grficos y de presentacin: Ayudan en la creacin de
ilustraciones y producen una presentacin profesional para los usuarios.

Otras Metodologas

36
2.3.1 Desarrollo estructurado de J ackson (J SD)

Esta metodologa utiliza modelos grficos para desarrollar sistemas. Los modelos
J SD describen el mundo real en trminos de: entidades, secuencias y acciones,
estructura de entidades, modelo inicial, planificacin e implementacin del
sistema.

2.3.2 Desarrollo de sistemas estructurados de datos (SDSD)

Esta metodologa es conocida como de Warnier - Orr. Desarroll una notacin
jerrquica para representar la informacin las cuales son:

a) De secuencia
b) De seleccin
c) De repeticin

2.3.3 Anlisis estructurado y Tcnica de diseo (SDSD)

Esta metodologa se compone de procedimientos que permiten al analista
descomponer las funciones del software o sistema en una notacin grfica, el
actigrama y el datagrama.

2.3.4 Tcnica 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 diseo.

Otras Metodologas

37
Descripcin del modelo:

v Desarrollar el mbito del problema
v Desarrollar un modelo de objetos
v Desarrollar un modelo dinmico
v Desarrollar un modelo funcional

2.3.5 Ingeniera de software orientada a objetos de J acobson

Esta metodologa describe cmo el usuario logra tener una accin interactiva con
el producto o sistema. A continuacin haremos un bosquejo general de este
proceso de J acobson:

v Identificar los usuarios del sistema
v Construir un modelo de requisitos
v Construir un modelo de anlisis

2.3.6 Anlisis y diseo con aplicaciones orientadas a objetos
de Boosh

Esta metodologa abarca un micro y un macro proceso de desarrollo. A
continuacin detallamos brevemente el micro proceso de desarrollo:

v Identificar clases y objetos
v Identificar la semntica 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 Metodologas

38

2.3.7 El lenguaje unificado de modelado (UML)

Es una metodologa de lenguaje modelado que se utiliza para visualizar,
especificar, construir y documentar los mecanismos de un sistema de software.
UML es una combinacin de los mtodos de Rumbaugh, Booch y J acobson,
adems incorpora unas mejoras con el propsito de lograr un acercamiento de
tipo estndar. UML maneja los siguientes conceptos para un sistema:

v Clasificacin Estructural

Vista esttica
Vista de casos de uso
Vista de implementacin
Vista de despliegue

v Comportamiento dinmico

Vista de mquina de estados
Vista de actividad
Vista de interaccin

v Gestin del modelo

Vista de gestin del modelo

UML es una de las metodologas ms simples pero siempre cuenta con la
capacidad de modelar cualquier tipo de sistema que se requiera.

Como conclusin podemos decir que todas estas metodologas han sido utilizadas
ampliamente para el desarrollo y construccin de sistemas, tanto la estructurada
como la orientada a objetos, no han sido del todo suficientes y eficientes para la
solucin de problemas ms complejos que actualmente la sociedad reclama y de
acuerdo a los avances tecnolgicos que se tienen da con da.

Otras Metodologas

39
2.3.8 Orientacin Agentes (OA)

El desarrollo de software Orientado Agentes resulta ser un nuevo enfoque para
abstraer y conceptualizar de la realidad, la solucin 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
nmero de componentes autnomos los cuales pueden ser operados de
manera independiente.

b) El concepto de organizacin que se refiere a la agrupacin de componentes
que se pueden reunir en jerarquas 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 especificacin se obtiene los requerimientos del sistema, se
definen las propiedades del sistema y los protocolos de interaccin.

En la fase de implementacin se estudia el cambio de la especificacin
abstracta a un sistema computacional en particular.

Finalmente en la fase de verificacin se utilizan dos mecanismos de
verificacin los cuales son: el ciclo de vida y el de verificacin formal.

Otras Metodologas

40
CAPITULO 3

HERRAMIENTAS DE MODELADO

3.1 Introduccin

No existe una manera obvia en la cual las herramientas seran organizadas;
probablemente la organizacin ms lgica debera ser en orden alfabtico. A
continuacin sealaremos cual sera la forma progresiva a seguir:

Herramientas para modelado informacin
Herramientas para modelado de funciones
Herramientas para modelado en tiempo y dinamismo.

Esta organizacin no es nada estricta ni ptima. Por lo tanto eSTDs y las tablas de
eventos y entidades son grupos que estn ms debajo de las herramientas
modeladoras.

Tipos de herramientas de modelado

Existen 4 (cuatro) tipos de herramientas modeladoras que son usadas en el YSM
(Mtodo del sistema de Yourdon) las cuales son las siguientes:

Grfica
Tabular
Frame
Textutal

A continuacin describiremos brevemente de cada una de ellas.

Herramientas de Modelado

41
Herramientas grficas

YSM usa herramientas de modelado grfico, para mostrar los componentes de alto
nivel desde el punto de vista particular de los aspectos del modelo. Estos
grficos, son el tipo preferido de modelo cuando la conexin entre componentes
es importante. Cada grfica tiene un conjunto de iconos que pueden ser usados.
Los iconos pueden ser conectados en un sentido bien definido.

Las herramientas grficas usadas en el modelado esencial son principalmente de
naturaleza semntica. El efecto de la notacin seleccionada es la manera de estar
pensando acerca de los requerimientos del sistema, la cual es sutil y an
importante. La comunicacin gramtica, en otras palabras, la convencin grfica
predetermina la forma de pensar sobre el problema.

En el ejemplo especfico del diagrama de entidad relacin, la eleccin de notacin
presupone una va al pensar que es en trminos de entidades, relaciones,
subtipos, etc.

Para la implementacin de modelos, hay grficas que muestran la unidad llevada a
cabo. Estas herramientas son ms concernientes con la unidad actual seleccionada
y la manera de como estn ellas conectadas.

El modelo esencial se refiere principalmente con el significado o semntica; la
implementacin se refiere ms bien en lo que respecta a la estructura y a la
sintaxis.

Para vistas grficas, 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 deberan tener comentarios excesivos. Muchos comentarios
significan que se trata de un modelo bastante pobre.

Herramientas tabulares

Alguna informacin es almacenada en forma til en una forma tabular. Por
ejemplo, la relacin entre entidades y eventos pueden ser visualizadas en una
tabla de entidad-evento. Algunos modelos grficos tienen una presentacin
tabular en forma alternativa. Esta puede ser til en algunas circunstancias,
particularmente si el sujeto experto en la materia encuentra el modelo grfico
difcil 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 trmino frame es utilizado informalmente para un cierto tipo de herramientas
de especificacin. Este marco es usado para especificar toda la informacin
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
trminos de un tipo de dato abstracto. YSM ha evitado que la notacin del marco
del diccionario de datos, sea muy extenso. Esto es por alguna de las siguientes
razones:

1. La notacin del diccionario de datos ya es bastante complicado.


43

2. Es textual y por lo tanto no es tan fcil de entender como otros modelos. Con
el correcto soporte de las grficas, y los frame, son fciles de entender.
3. En algunos casos fue ambiguo y se abri a la interpretacin personal. En estas
reas, la notacin fue reemplazada.

El mtodo por lo tanto proporciona una va ms flexible de especificaciones hacia
el modelo de componentes declarado en las vistas grficas. Es inevitable tener un
perodo de transicin antes de que tales herramientas de software estn
disponibles, pero el concepto de especificaciones frame proporcionara una ligera
progresin ascendente. El uso de especificaciones frame en ambientes tcnicos
diferentes varan. En ambientes automatizados el soporte es visto completamente
bajo el concepto de YSM. En cualquier ambiente automatizado de lpiz y papel los
frame extensos pueden ser reducidos en cuanto a la cantidad de cruces o lneas
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 especfico de la empresa y del funcionamiento del
sistema, YSM cuenta con el recurso de la gramtica textual en algunas
situaciones. Cuando este es requerido, el siguiente principio tiene que ser llevado
a cabo:

1. La gramtica fue original y formalmente definida usando el meta-lenguaje o la
teora de conjuntos. Sin embargo, esta usualmente slo se les permita a los
desarrolladores CASE.
2. Fue entonces reescrita en un lenguaje ordinario, la cual fue nombrada como
forma de relajamiento de la gramtica.
3. Existe la esperanza de que las prcticas del YSM, seran capaces de inferir la
sintaxis correcta de esta, sin necesidad de usar algn apndice.

44

4. Actualizacin de modelos en ambientes de soporte automatizados.

Al tratar con informacin que aparece en diversas vistas es muy dependiente del
ambiente de soporte tcnico. Por ejemplo, una entidad aparece en:

Empresa ERD: Esta muestra la entidad y alguna relacin o subtipo que
aparecen.
Especificacin 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 sera
terminado como una simple accin. Si todas las vistas superiores o de mayor nivel
fuese necesario cambiarlas, entonces el enfoque sera a lpiz y papel.

En un ambiente que soporte visibilidades mltiples en diferentes vistas, all puede
estar el control apropiado para que la informacin sea meramente desplegada.
Algunos otros criterios tambin tienen que ser encontrados. As, los criterios para
actualizacin de un artculo visible en una vista son:

El artculo 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 actualizacin no debe comprometer la integridad
del modelo en el cual el artculo es un componente.

En este caso no resulta del todo visible soportar los conceptos antes mencionados
usando papel y lpiz, excepto cuando se trata de una va muy informal.

45

Interdependencia de modelos

Existen vas anlogas en las cuales un modelo de importacin 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 mnimas: Estas definen las funciones del
sistema en trminos de conexin, 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 Anotacin

En ambientes de soporte automatizados, la mayora de los comentarios en el
diagrama deben evitarse, ya que esto se podra hacer tranquilamente a lpiz y
papel. Un mejor acercamiento sera permitir requerimientos de informacin
adicional, sobre el diagrama a ser presentado por alguna otra va.


46

Referencias cruzadas

Los modelos descritos anteriormente, son usados para capturar requerimientos y
adems son parte de modelos bien definidos. Por lo tanto, es importante proveer
de referencias a las fuentes de informacin, incluyendo entrevistas a usuarios,
documentos de texto, estndares de gobierno y especificaciones de hardware.

En ambientes de lpiz 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 podran ser un registro que haga referencia a un
modelo de componente, al requerimiento externo, cundo fue identificado y quin
estuvo de acuerdo.


47
3.2 Diagrama de Entidad Relacin

3.2.1 Propsito

El diagrama de entidad relacin (ERD) es una herramienta usada para desarrollar
un modelo particular de importancia para la empresa, as como la relacin entre
ellas. Es considerada como un auxiliar semntico, la cual ayuda a clarificar los
conceptos.

La ERD es usada para identificar y organizar la informacin. Organiza todos los
datos que la compaa maneja, no slo el almacenado de informacin. ERDs
tambin puede ser utilizado como una herramienta para descubrir reglas y
eventos. Cada una de las vistas muestra una coleccin 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 relacin que se usan en el
Sistema Empresa

El modelo esencial de empresa usa ERDs para definir entidades y la relacin entre
ellas. Un diagrama de entidad relacin que se usa de esta manera, es referenciado
como un diagrama de relacin 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 informacin.


48
3.2.3 Componentes que conforman el diagrama entidad
relacin (ERDs)

Entidad Asociativa

En una entidad asociativa, ambas relacin y entidad actan de igual forma. La
primera indica que existe una asociacin al mundo - real. Como sucede en toda
relacin, una ocurrencia de tipo asociativa no puede haber sin una anterior (o
creacin simultnea).

Una relacin debera ser reemplazada por una entidad asociativa, si esta tiene
atributos o bien, acta como una entidad en otra; si esto sucede, se dice que
ambas son relacin y entidad.

Los atributos de una entidad asociativa, no describen las entidades que participan
en toda relacin, pero s la ocurrencia de la asociacin entre ellas. Por ejemplo;
dada la siguiente relacin:

Para este caso, el nivel salarial especfico del puesto que fue asignado, debera ser
importante. En este caso lo que describe es, cundo la ocurrencia de la relacin
fue dada o puesta. Este modelo es reemplazado por la relacin se la asigna por
la entidad asociativa Catlogo de puestos con nivel salarial como su atributo.

Empleados
Se le
Asigna

Puestos

D
I
A
G
R
A
M
A

D
E

E
N
T
I
D
A
D

R
E
L
A
C
I
O
N

D
E
L

S
I
S
T
E
M
A

D
E

N
O
M
I
N
A

(
D
E
R
)

M

1

M

M

M

M

M

1

M

M

F
i
g
u
r
a

A

E
m
p
l
e
a
d
o
s

I
d
_
d
e
p
t
o
.

N
o
m
b
r
e

I
d
_
p
u
e
s
t
o

D
i
r
e
c
c
i
n

I
d
_
e
m
p
l
.

T
e
l
f
o
n
o

P
e
r
t
e
n
e
c
e

a

D
e
p
e
n
d
e
n
c
i
a
s

I
d
_
d
e
p
t
o
.

D
e
s
c
r
i
p
.

T
i
t
u
l
a
r

T
i
e
n
e

u
n

P
u
e
s
t
o
s

I
d
_
p
t
s
o
.

N
i
v
_
s
a
l

S
a
l
a
r
i
o

D
e
s
c
r
i
p
.

T
i
e
n
e

u
n
o

o

v
a
r
i
o
s

P
r
s
t
a
m
o
s

T
i
e
n
e

u
n
a

o

v
a
r
i
a
s

P
e
d
e
v
a
r

I
d
_
p
d
v
a
r

I
d
_
e
m
p
l
.

s
t
a
t
u
s

I
m
p
o
r
t
e

D
e
s
c
r
i
p
.

T
i
e
n
e

u
n
a

o

v
a
r
i
o
s

P
a
g
e
x
t

D
.

A
u
s
.

P
r
i
m
a

d
.

H
r
s
.
E
x
t
.

D
e
s
c
r
i
p
.

I
d
_
p
a
g
e
x
t

I
d
_
e
m
p
l

I
d
_
p
r
e
s
t
.

N
o
.
q
n
a
s
.

I
d
_
e
m
p
l
.

D
e
s
c
r
i
p
.

I
m
p
o
r
t
e

F
i
g
u
r
a

B

E
M
P
L
E
A
D
O
S

T
A
B
L
A

D
E
L

S
U
B
S
I
D
I
O

P
U
E
S
T
O
S

D
E
P
E
N
D
E

P
a
g
o
s

E
x
t
r
a
s

P
E
D
E
V
A
R

P
R
E
S
T
A
M
O
S

T
A
B
L
A

D
E
L

I
M
P
U
E
S
T
O

T
A
B
L
A

D
E
L

C
R
E
D
I
T
O

A
L

S
A
L
A
R
I
O

G
e
n
e
r
a
n

A
R
C
H
I
V
O

D
E

P
A
G
O
S

A

E
M
P
L
E
A
D
O
S

N
.
E

N
o
m
b
r
e

d
i
r
e
c
c
i
n

D
e
s
c
r
i
p
.

N
i
v
e
l

s
a
l
.

c
v
e
d
e
p

c
v
e
p
u
e

D
e
s
c
r
i
p
.

c
v
e
p
r
e

N
.
E
.

C
v
e
p
a
g

N
.
E
.

I
m
p
o
r
t
e

N
.
E
.

c
v
e
p
e
r

I
m
o
p
r
t
e

49

Esta entidad asociativa retiene la propiedad de una relacin existente. Cada
ocurrencia de registros Catlogo de puestos, es el hecho de que a un empleado
le fue asignado un puesto junto con un nivel especfico.

3.2.4 Relaciones

Una relacin representa una posible ocurrencia que se puede dar entre entidades.
Cada suceso de la relacin, corresponde a una especfica de estas entidades
existentes y que son enlazadas por dicha asociacin. La relacin puede ser
considerada como un patrn de hechos, los cuales hacen referencia a entidades
especficas, que pueden ser agregadas para obtener sucesos concretos acerca del
mundo - real. Por ejemplo:

Llnese con el empleado requerido Llnese con el pago extra que se trate

Se le
Asigna

Empleados

Puestos

Catlogo de
Puestos

Personal

PagExt
J uan Prez Se le asigna Horas extras
Pedro Pramo Se le asigna Prima dominical
J os Sordo Se le asigna Prima dominical

50
Cada ocurrencia de la relacin, corresponde a una asociacin exacta de las
entidades que pertenecen a ella. Estas tambin pueden ser representadas como
diagramas de instancias.

J uan Prez Horas extras

Pedro Pramo Prima dominical

J os 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 podran aparecer como un diagrama de
entidad relacin. Ejemplo:


51

Los subtipos tambin 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 teora
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 automticamente depende de
pede o lo que es lo mismo, un subtipo hereda las propiedades del supertipo.

Pede
Otra
Deduccin
Otra
Percepcin
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 adems tiene dos tipos de propiedades comunes:


53
3.3 Diagrama de transicin entidad - estado

Los diagramas de transicin 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 ms patrones de cambio llamados
ciclos de vida. Cada ciclo es nombrado por una caracterstica especfica descrita
como una variable estado. El eSTD es usado para modelar los diferentes estados
que las variables puedan tomar. La declaracin 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, habra un eSTD. Los eSTD muestran como una ocurrencia de entidad
estado, cambian cuando se producen eventos especficos.

3.3.1 Diagramas de transicin 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 transicin de estado entidad empresa,
entidad empresa STD, o empresa eSTD.

3.3.2 Diagrama de transicin 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 estn al alcance del
sistema, es referenciado como un diagrama de transicin de estado entidad
sistema, entidad sistema STD o sistema eSTD. A continuacin mediante un
diagrama ejemplificaremos lo explicado anteriormente, ver figura C.


54
3.3.3 Especificacin de atributos

Cada atributo tiene una especificacin 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 especificacin es visible al modelo
esencial de sistema. Ejemplo:

A continuacin, haremos una breve descripcin de cada uno de los componentes
que la conforman:

ENTI DAD: Personal
ATRI BUTO: N.E.
SIGNIFICADO: Una corta descripcin que se usa dentro de la
organizacin para propsito de identificacin.
RETENCION: Almacenamiento
TYPI NG: Abstracto
ADT: Alfanumrico
PARAMETROS: Longitud mnima: 3
Longitud mxima: 5
RESTRICCIONES: Primer carcter alfabtico

D
I
A
G
R
A
M
A

D
E

T
R
A
N
S
I
C
I
O
N

E
N
T
I
D
A
D

-

S
I
S
T
E
M
A

[
e
S
T
D
]

F
i
g
u
r
a

C

E
m
p
l
e
a
d
o
s

c
a
t
a
l
o
g
a
d
o
s

p
o
r

l
a

D
.
R
.
H

C
r
e
a
r

C
o
n
s
u
l
t
a
s

d
e

E
m
p
l
e
a
d
o
s

C
a
n
c
e
l
a

c
a
p
t
u
r
a

I
n
i
c
i
a
l

L
e
e
r

O
p
e
r
a
d
o
r

c
a
n
c
e
l
a

L
e
e
r

C
a
p
t
u
r
a

I
n
i
c
i
a

c
a
p
t
u
r
a

e
m
p
l
e
a
d
o
s

B
o
r
r
a
r

A
c
t
u
a
l
i
z
a

C
o
n
s
u
l
t
a

d
e

e
m
p
l
e
a
d
o
s

F
i
n

d
e

c
a
p
t
u
r
a

C
a
p
t
u
r
a

c
a
n
c
e
l
a
d
a

L
e
e

y

a
c
t
u
a
l
i
z
a

A
c
t
u
a
l
i
z
a
c
i
n

D
i
a
g
r
a
m
a

p
a
r
c
i
a
l

d
e

i
l
u
s
t
r
a
c
i
n

E
N
T
I
D
A
D
:

C
a
t
l
o
g
o

P
e
r
s
o
n
a
l

V
A
R
I
A
B
L
E

E
S
T
A
D
O
:

S
t
a
t
u
s

A
B
R
I
R

E
J
E
C
U
T
A
N
D
O

C
O
M
P
L
E
T
A
D
O

F
I
N
A
L
I
Z
A
D
O

O
P

O
P

E
n
t
i
d
a
d

V
a
r
i
a
b
l
e

e
s
t
a
d
o

T
r
a
n
s
i
c
i
n

i
n
i
c
i
a
l

E
s
t
a
d
o

i
n
i
c
i
a
l

T
r
a
n
s
i
c
i
n

E
v
e
n
t
o

A
c
c
e
s
o

E
s
t
a
d
o

C
o
n
e
c
t
o
r

E
n
t
i
d
a
d

m
u
e
r
t
a

C
o
m
e
n
t
a
r
i
o

55
ENTI DAD: Aqu es donde se declara el nombre y se usa para
ayudar a identificar la existencia de atributos definidos.
ATRI BUTO: 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 clculos
intermedios.
v Derivado: Se usa para recalcular
informacin cada vez que el valor sea
requerido.

YSM hace la siguiente recomendacin: Cualquier tipo de informacin deber
contener atributos; todo tipo de dato siempre nos habla acerca de algo; por lo
tanto, no toda informacin necesita ser guardada o almacenada.

El valor del atributo puede corresponder a cualquier tipo de dato abstracto. (ADT)
o bien ser listado en forma explcita. Los ADTs pueden ser utilizados con cualquier
operacin 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 Especificacin 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 representacin fsica. 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.

TI PO DE DATO ABSTRACTO: Mes en cual se le efectuar el primer
descuento a un empleado.
SI GNI FI CADO: usualmente son 12 meses
ESTRUCTURA: Simple
NUMERO DE VALORES: Finito
VALOR DE DEFINICION: Lista de valores
VALORES: Ene, Feb, Mar, Abr, May, J un, J ul, Ago, Sep, Oct, Nov, Dic.
ORDENAMI ENTO: Cclico

57
En la estructura, YSM permite ADTs simples y compuestos que estn bien
definidos. Esto se indica por el valor en la estructura del campo.

Simple: Tiene un nico valor e indivisible. Ejemplo: Mes del ao.
Compuesto: Cuenta con algunas partes componentes es decir,
puede ser uno u otro.

Un tipo de dato compuesto tiene dos o ms componentes. Ejemplo de este tipo:

ORDENAMI ENTO: 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 trminos significantes
v Lineal: Cuando los valores son comparados unos con otros.
v Cclico: Ene, Feb, Mar, etc.

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

TI PO DE DATO ABSTRACTO: La direccin de cada empleado
SI GNI FI CADO: Utilizado por alguna entidad para enviar informacin
COMPONENTES:

Componente Tipo

Casa Residencia
Calle Alfabtico
Ciudad Alfabtico
Cdigo postal Numrico

58

<<<<

Tabla 3.1

Orden

Operacin Nmero 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 propsito. Las fuentes para las entradas y salidas, tambin son
mostradas por este tipo de diagrama. Estas pueden ser otros sistemas,
dispositivos de hardware, personas y otras organizaciones. A manera de
implicacin, 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 diseador. Cualquier cambio
en el contenido o la propia estructura de la interfase, solo puede ser llevada a
cabo despus de una previa negociacin 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 sern usados en un
sistema dado. Los flujos de eventos slo son probables que ocurran si el
funcionamiento del sistema cambia en horas extras de trabajo. Los flujos de
eventos slo podrn ser encontrados cuando el sistema controla el medio
ambiente. Para lograr una mejor comprensin 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 sern solicitados, si el sistema monitorea o controla el estado
de los dispositivos en ese ambiente; el almacenamiento es utilizado, si la
informacin disponible a la vez, es necesitada subsecuentemente.

El siguiente ejemplo es tomado de un sistema de control de procesos que
controla el proceso de clculo de la nmina, ver figura E.

D
I
A
G
R
A
M
A

D
E

C
O
N
T
E
X
T
O

D
E
L

S
I
S
T
E
M
A

D
E

N
M
I
N
A

D
e
p
e
n
d
e
n
c
i
a
s

a
s
i
g
n
a
d
a
s

T
r
m
i
t
e
s

p
a
r
a

l
a

c
a
p
t
u
r
a

C
o
n
f
i
r
m
a
c
i
n

d
e

e
m
p
l
e
a
d
o
s

d
e

l
a

c
a
p
t
u
r
a

A
s
i
g
n
a
c
i
n

d
e

D
e
p
e
n
d
e
n
c
i
a
s

P
u
e
s
t
o
s

a
s
i
g
a
n
d
o
s

A
s
i
g
n
a
c
i
n

d
e

P
u
e
s
t
o
s

C
o
n
f
i
r
m
a
c
i
n

d
e

l
a

a
s
i
g
n
a
c
i
n

A
s
i
g
n
a
c
i
n

d
e

p
r
s
t
a
m
o
s

d
e

p
r
s
t
a
m
o
s

O
t
r
a
s

p
e
r
c
.

y

d
e
d
u
c
.

a
s
i
g
n
a
d
a
s

A
s
i
g
n
a
c
i
n

d
e

P
e
r
c
e
p
c
i
o
n
e
s

y

d
e
d
u
c
c
i
o
n
e
s

v
a
r
i
a
b
l
e
s

I
n
c
i
d
e
n
c
i
a
s

v
a
r
i
a
s

a
s
i
g
n
a
d
a
s

T
r
m
i
t
e
s

p
a
r
a

l
a

c
a
p
t
u
r
a

d
e

i
n
c
i
d
e
n
c
i
a
s

T
r
m
i
t
e
s

p
a
r
a

s
o
l
i
c
i
t
a
r

C
o
n
f
i
r
m
a
c
i
n

d
e

l
a

e
l
a
b
o
r
a
c
i
n

d
e

l
o
s

T
a
l
e
s

c
o
m
o
:

H
o
r
a
s

e
x
t
r
a
s
,

e
t
c
.

R
e
c
i
b
o

d
e

s
u
e
l
d
o
s

r
e
c
i
b
o
s

d
e

s
u
e
l
d
o

(
R
e
p
o
r
t
e
s
)

P
a
r
a

e
l

p
a
g
o

c
o
r
r
e
s
p
o
n
d
i
e
n
t
e

A

l
o
s

e
m
p
l
e
a
d
o
s

F
i
g
u
r
a

D

S
i
s
t
e
m
a

d
e

N
m
i
n
a

d
e
l

H
.

A
y
u
n
t
a
m
i
e
n
t
o

d
e
l

C
o
l
i
m
a
.

E
m
p
l
e
a
d
o
s

D
e
p
e
n
d
e
n
c
i
a
s

P
u
e
s
t
o
s

P
r
s
t
a
m
o
s

P
e
d
e
v
a
r

P
a
g
e
x
t

P
a
g
o
s
N

E
m
p
l
e
a
d
o
s
D
e
p
e
n
d
e
n
c
i
a
s

P
u
e
s
t
o
s

P
r
s
t
a
m
o
s

P
e
d
e
v
a
r

P
a
g
e
x
t

P
a
g
o
s
N

Listado de archivos

Proceso
cancelado

Peticin de datos

Programa en
ejecucin
Listado de
archivos

Conjunto de
archivos

Archivos nuevos

Ejecucin
correcta

Proceso de E/ D Conjunto de archivos
clculo

Archivos
generados
Tablas
Reqmto.
de
datos

Comentario

DIAGRAMA DE FLUJ O DE DATOS (DFD) Figura E
DFD # : 1
NOMBRE DFD: Clculo de Nmina
DFD # : 1 Nombre del
DFD

Movimiento Habilitar /
deshabilitar

Proceso
Clculo
Nmina

Checa
Existencia
de
archivos
Controla la
ejecucin
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
procporeso
Dilogo 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
informacin almacenada para llevar a cabo un determinado propsito. Los datos
almacenados corresponden a las entidades o relaciones. En el DFD, sta se indica
en trminos generales.

3.5.2 Proceso de entrada

Un flujo de acceso de un almacenamiento muestra que el proceso usa informacin
almacenada y que esta puede corresponder a:

Accesos match: Una ocurrencia de entidad o relacin tienen criterios
particulares.
Acceso de lectura: El proceso usa los valores de uno o ms 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
relacin.
Eliminacin de accesos: Se usa para borrar una o ms ocurrencias de la
entidad
Actualizacin de accesos: Es utilizado para modificar el valor de un
atributo.
Cambio de accesos: El cambio de condicin 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 coordinacin o activacin de los mismos. Este a su vez puede utilizar flujo de
eventos continuos en forma boleana. Los procesos tambin 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 funcin
especfica. 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,
tambin puede ser puesto en movimiento habilitndolo o deshabilitndolo en
forma explcita 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 activacin y se etiquetan con la letra T. Sirven para poner
en marcha un proceso discreto; los cuales pueden ser la ejecucin completa del
proceso o la detencin del mismo en alguna parte del mismo.


63
3.5.8 Distincin 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 Distincin entre flujo de eventos y flujo de datos

Pueden ser distinguidos por el nmero 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, slo puede transformar o comunicar alguna
informacin que ha acontecido desde el punto de vista del tiempo en cambio, uno
continuo transfiere informacin que es verdadera ciertas veces y falsa otras. El
flujo de datos, transfiere informacin a ser almacenada, usada en clculos, etc.

3.5.10 Dilogo del flujo de datos

Este contiene algunos flujos que actan como una especie de interfase. El nivel
ms bajo puede tener doble flujo en relacin 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 dilogo par. La salida de este tipo de dilogo 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 Dilogo 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 descripcin es exactamente un dilogo de flujo de datos.

3.5.12 Habilitar y deshabilitar

Es la representacin 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:

I nicializar: Si existe lo limpia y lo pone como cero eventos.
Comprender
lo que el
empleado
reclama

65
Seal: Si no hay procesos esperando un evento, este adiciona
uno o ms ocurrencias del mismo.
Wait: Si hay eventos detenidos en el almacn, el nmero
presente es decrementado en uno; si no hay almacenado
ninguno, el proceso es suspendido y puesto en cola.

3.5.13 Especificacin de procesos

Esta especificacin describe el tipo, nmero de instancias y mecanismos de
activacin para algn proceso. Existe una especificacin 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 transicin y
tablas de accin.

En un ambiente de soporte automatizado, sta herramienta de especificacin
acta como un soporte directo para los DFD. Cada proceso en un DFD cuenta con
uno propio de especificacin. Cada una de stas hace referencia aun minispec,
bSTD, o un nivel bajo que es usado para sealar la funcin en este caso.

Ejemplo:

PROCESOS: Actualizacin de salarios de los Empleados
SI GNI FI CADO: Autorizar el incremento de sueldo pactado
TI PO DE PROCESO: Data

66

Proceso

Se encarga de especificar el nombre que se le asigna al proceso.

Significado

Es utilizado para dar una descripcin general o algn comentario acerca del
proceso; es decir, la funcin que realizar el mismo.

Tipo de proceso

Los tipos de procesos pueden ser:

PERSI STENCI A: Discreta
MECANISMO DE ACTIVACIN: Estmulos
ESTIMULOS: Proporcionar el pago
NUMERO DE I NSTANCI AS: 1
ESPECIFICACION: Minispec
TIEMPO MEDIO ENTRE FRACASOS O QUIEBRAS: 6 Meses
TI EMPO MEDI O PARA REPARAR: 1 da
TIEMPO DE RESPUESTA: 1 da
PROCESAMI ENTO / ACTI VACI ON: 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 funcin. Es puesto en marcha en
forma explcita o mediante requerimiento de estmulos.

Se dice que si el proceso es continuo, entonces es especficamente
habilitado/deshabilitado o bien, es siempre activo; en cambio, si es discreto se
dice que hay un mecanismo de activacin que causa que dicha funcin sea llevada
a cabo.

Mecanismo de activacin

Este es slo para procesos discretos. El mecanismo de activacin, es usado para
hacer que se efecte la ejecucin del proceso. Los valores permitidos son:

Estmulos: En este caso, existe un dato discreto o flujo de
evento que se encarga de actuar como un estmulo 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 especfico lo
identifica como una necesidad, por s mismo no tiene
control sobre este, ni tampoco sabe nada sobre alguna
cosa en particular antes o despus de ejecutarse en la
corrida reciente.
Tiempo: El proceso es ejecutado cuando ocurre un evento
temporal.

Estmulos

Todo proceso de datos discreto puede tener un flujo como un estmulo. Un control
de procesos discreto puede tener un flujo de evento discreto, tambin como un
estmulo.

La interaccin de habilitar/ deshabilitar y los estmulos

Para procesos discretos, la distincin entre habilitar y la activacin de los mismos
cuando ocurre un estmulo, es importante. Considere un proceso a ser
habilitado/deshabilitado. Cuando se habilita espera un estmulo 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 transicin estado.

Habilita Deshabilitar

Ocurrencias de estmulos
Procesos en marcha

Proceso deshabil.
Proceso habilitado

69
El diagrama que se ilustra a continuacin, muestra la relacin entre persistencia,
mecanismo de activacin y estmulos:

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 estmulos
deshabilitado

cuando ocurren los estmulos y el
proceso est habilitado.
Permanente

1. Cualquier proceso es uno u otro es decir, continuo o discreto
2. Los procesos continuos estn 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
Nmero de instancias

Algunos procesos tienen ms de una instancia y el nmero que puede tener son:

Constante: El nmero de instancias son 1,2,3,..., pero este
nmero no vara sobre el tiempo de vida del sistema.
Variable: El nmero de instancias cambia en perodo de tiempo
y es menor que la vida del sistema.

Especificacin

Este define la manera en la cual los procesos son especificados. Los valores
permitidos en tipo control son bSTD, estado de transicin y accin en tablas y
minispec. Para data es minispec o modificacin. Finalmente, para grupo son:
Diagrama de flujo de datos o modificacin.

Hay exactamente una especificacin usada para definir la funcin de los procesos
estas son:

Diagrama de flujo de datos
Minispecs
BSTDs
Estado de transicin y accin en tablas


71
3.5.14 Minispec

Estn condicionados para dar una especificacin rigurosa por cada proceso de
datos del sistema. En ciertas circunstancias, son tambin utilizados sealar 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 ms 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 declaracin de los procesos se lleva a cabo mediante una gran variedad de
formas. Sin embargo, existen estndares YSM para hacer esto, pero no hay un
rango de estilos y herramientas de modelado que satisfagan a todas.

Ejemplo:


72

PROCESOS: Actualizacin de sueldos al personal con nivel salarial
< 6
ENTRADAS DE FLUJ O DE DATOS: Porcentaje de incremento
SALIDAS DE FLUJ O DE DATOS: Incrementos otorgados
ENTRADAS DEL FLUJ O DE EVENTOS: __
SALIDAS DEL FLUJ O DE EVENTOS: __
DATOS DE ENTRADA ALMACENADOS: <Puestos> (Atributos:
cvepue, nivsal, etc.)
DATOS DE SALI DA ALMACENADOS: <Puestos> (Atributos:
salario)
NOTA TEMPORAL: Nombre Valores
Incremento de sueldo moneda corriente
TERMINOS LOCALES: <Puestos anterior>: : = <Puestos> con
nivel salarial < 6
FUNCI ONES LOCALES: __
FUNCI ON (EXTERNA): ___
FUNCI ON (I NTERNA):

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 Especificacin de operacin

Muchas de las operaciones simples son proporcionadas por YSM:

Hay operaciones permitidas por cada tipo de dato estndar
abstracto.
Operaciones tales como: seales.
Una gramtica de acceso de datos.

Estas operaciones resultan ser del todo prometedoras, para un mayor nmero de
empresas.

YSM tambin permite nuevas operaciones a ser definidas y adicionadas a
aquellas que estn disponibles. Cada una que es agregada en esta forma, requiere
de negociacin de especificacin. Adems solicitan de una o ms entradas para
retornar uno o ms resultados.

Ejemplo:

OPERACIN: Clculo de quinquenios
SI GNI FI CADO: calcula el no. de quinquenios que le corresponde
a cada empleado, con base a su fecha de ingreso.
ARGUMENTOS: Argumento Tipo Direccin

N.E. No. de empleado entrada
Fec_ing Fecha de ingreso entrada
No_quinq. Nmero de quinquenios salida

74

3.5.16 Especificacin 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
especificacin.

Cuando este tipo de flujo contiene algunos datos de que ocurren al mismo tiempo,
la informacin que acontece cada vez es llamada como un grupo de datos. Ambos
flujos de datos discretos y continuos pueden estar contenidos en forma mltiple.

Ejemplos:

USO:

Operaciones aritmticas: No empleado y fecha de ingreso
Procedimiento de clculo: Clculo (N.E. y F.I) retorna N.Q.
Texto: Proceso de clculo tomando como base el nmero de
empleado y la fecha de ingreso.
DEFINICION:

A:= Int(N.E.)
B:= Date(F.I.)
FLUJ O DE DATO: Solicitud de prstamo a corto plazo
SI GNI FI CADO: Registro de informacin de las veces en la cual el
empleado ha solicitado un prstamo.

75

FLUJ O DE DATO: Nombre del empleado
ESTRUCTURA: Elemental
ENTI DAD: Prstamo
ATRI BUTO: Nombre

FLUJ O DE DATO: Checa el fondo acumulado
ESTRUCTURA: Elemental
SI GNI FI CADO: Al aval se informar que en caso de que el empleado no
pague el prstamo, l tendr que responder por si mismo.
ENTI DAD: ___
TYPI NG: Abstracto
ADT: Nombre y direccin
ESTRUCTURA: Grupo
COMPOSICION: Nombre del empleado
+ Checa fondo acumulado | contactar con la dependen-
cia que otorga los prstamos.
+ Si solicita ms de lo ahorrado, necesita aval.
+ 1 {Fondo acumulado ms la parte del aval}

76
Flujo de datos

Cada flujo contiene un nico nombre que es usado para su propia especificacin.
Los que no son componentes pueden tener el mismo nombre como cualquier otro
o ser parte de l. Si se da un dilogo, la primera entrada vendra 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 ms ocurrencias de este paquete de datos.
Dilogo par: Slo puede ser especificado como un dilogo par,
si han sido proporcionados dos nombres.
Mltiples: Es una representacin de muchos flujos, los cuales no
tienen conexin temporal.


77
Composicin

Si la estructura es de Grupo, la composicin de entrada proporciona los
contenidos del flujo y la estructura de una ocurrencia en el mismo. Se dice que si
el tipo es mltiple, no tiene una composicin. Un grupo est conformado haciendo
uso de la inclusin, seleccin, iteracin y construcciones opcionales.

Inclusin

Cada uno de los componentes son listados, separados un + los cuales son ledos
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 contratacin. En este caso se dice que
tanto el nombre como el tipo, no se pueden dar en forma independiente.

Seleccin

Este es usado para indicar que exactamente un posible componente, estara
presente en algn tiempo determinado. Ejemplo:

La primera seleccin nos muestra cmo 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 prstamo]

78
Iteracin

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 ledo
como una iteracin de. Por ejemplo:

El nmero 1 (uno) que est antes de abrir la llave, indica las iteraciones a ser
llevadas a cabo, en este caso es el ms bajo. Ejemplo:

1 {en cuntas quincenas descontar el prstamo} 20, en este caso se dice que las
iteraciones sern 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 algn flujo es declarado
como grupo, deber estar compuesto por discretos. Los continuos slo pueden ser
contenidos por mltiples.

Typing

Para datos elementales que no tienen atributos, los estados de los valores de los
elementos de datos, son definidos en trminos de un tipo de dato abstracto o
bien, dado como una lista de valores explcitos.

1 {Fondo propio + la parte correspondiente del aval}

79
Adt (Tipo de dato abstracto)

Las dos especificaciones (Nombre + direccin) ambos usan ADT, por lo tanto
deben ser definidos como:

TI PO DE DATO ABSTRACTO: Nombre + direccin
SI GNI FI CADO: Se utiliza para poder proporcionar informacin sobre los
empleados.
ESTRUCTURA: Compuesta
COMPONENTES: Componente Tipo

Nombre Alfanumrico
Direccin Alfanumrico

80
3.5.17 Tabla entidad funcin

La tabla entidad funcin es utilizada como una herramienta de modelado de alto
nivel, para visualizar la relacin entre funciones llevadas a cabo y la informacin
requerida para soportar esas funciones.

Esta herramienta es til en lo siguiente:

Planeacin estratgica: Las tablas de entidad funcin
pueden ser usadas para estudios de dependencia entre
unidades de empresas econmicas o de algunos posibles
sistemas. Los estudios son relacionados a las actividades
de planeacin estratgica.
Modelando proyectos: La tabla puede ser utilizada para
proporcionar informacin de las funciones entre un
sistema.
Uso de tablas de entidad funcin en la empresa y
sistema: Una tabla entidad - funcin usada como parte
del modelo esencial de empresa, es referido como una
tabla de funcin entidad empresa. Ejemplo:

Tabla de entidad - funcin
(Parte 1)

Funcin
Listado y admon.
Producc. Empl. de empleados. Avisos
DEPENDENCI AS Crear, borrar,
actualizar

Nombre de
la tabla

Funcin

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
Seleccin <Ticon> Crear, borrar, leer, Leer,
Checar, cambiar Checar

<Ticon> asignado a Crear, leer,
borrar, match
empleado
<Tipo Contratacin> Crear, leer Leer

Entidad

Relacin
Entidad
Asociativa

Subtipo

82
3.5.18 Accesos

Son otorgados por la vista para el uso de relaciones o entidades para la funcin.
Los accesos permitidos son:

v Crear: La funcin una nueva ocurrencia de la entidad o relacin.
v Match: La funcin necesita saber si una ocurrencia especfica de
la entidad o relacin existen.
v Lee (slo para entidades): La funcin necesita conocer de la
existencia de valores de atributos, que han sido previamente
asignados en una creacin o actualizacin.
v Actualizacin (slo entidades): La funcin puede cambiar o
asignar valores de atributos para una entidad.
v Borrar: La funcin puede destruir una o ms ocurrencias de la
entidad o relacin.
v Checar: La funcin 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 funcin 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 contratacin Sindicalizado o Confianza
<Ticon>.


83
Esto indica que la entidad asociativa listado de dependencias, acta como una
relacin y adems se refiere a la <Depende>, <Puestos> y <Ticon> como
entidades.

Especificacin de datos almacenados

Este se encarga de definir cules 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 informacin almacenada haciendo uso de un
nombre, el cual contiene informacin relacionada con una o ms entidades y/o
relaciones. La especificacin de un dato almacenado es el que define exactamente
cules entidades y relaciones estn 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 relacin que exista en el propio
almacenamiento. Por ejemplo:

DATO ALMACENADO: Puesto seleccionado
ENTI DADES:___
RELACIONES: <Empleado> se asigna un <Catlogo de Puestos>
ALMACENAMIENTO INCLUIDO:__

84

Esta relacin 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>.

Especificacin del flujo de acceso

Esta forma de especificacin se encarga de proporcionar un detalle especfico el
cual, accesa el dato almacenado. Todos los flujos de este tipo cuentan con
especificaciones dependiendo de las tcnicas de soporte. El uso de esta
herramienta de modelado, es opcional. La informacin que est contenida en esta
especificacin es enteramente redundante, con su propio contenido del dato de
acceso almacenado. Ejemplo:

<Empleado> se le asigna un <Catlogo de puestos>
STORE: Tipos de contratacin

PROCESOS: Checar el tipo de asignacin
FLUJ O DE ACCESO:__
Composicin: <Ticon> (<Titular de la dependencia> solicita sea
asignado a un empleado un <Ticon> para un empleado de un
departamento en particular)
Crear(atributos: tipo contratacin y descripcin),
Actualizar(atributos: tipo contratacin y descripcin),
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.

Especificacin del sistema evento

Se dice que un evento es algo que:

v Ocurre fuera del lmite 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 cuestin. La especificacin del sistema evento describe
cmo un sistema especfico trata con el propio evento.


86
CAPITULO 4

EL MODELO ESENCIAL DE EMPRESA

4.1 Introduccin

El modelo esencial de empresa (EEM) es un modelo de la informacin de la
empresa. Eventos y funciones se utilizan en la compaa y sirven para integrar
sistemas, de tal manera que la empresa pueda ser pensada verdaderamente como
una Constitucin de sistemas diversos. El EMM no es una implementacin
supuesta, sino que ms 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 informacin de la empresa. Los usos
especficos del EMM son:

Planeacin estratgica: Como su nombre lo indica, es la fase
planeacin e iniciacin de los proyectos de sistemas requeridos por la
empresa.
El uso de la misma informacin, por ms de un sistema.
I dentificacin 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 lmites permitidos.

El Modelo Esencial de Empresa

87
Con respecto de cada aplicacin basada en computadora como un sistema
independiente, resulta ser una estrategia que permitir a largo plazo una ineficacia
aunado a problemas de operacin. Las funciones y la informacin estn 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 informacin y funciones que son usadas por
la misma compaa.

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 construccin de sistemas. El EEM es la definicin de
toda la informacin y funcin que utiliza la empresa.

Suposicin de modelos

El EEM se concentra bsicamente en el significado o el sentido de la informacin.
Funciones y eventos, antes que cualquier otra tcnica son llevados a cabo para
soportar estos tipos de requerimientos. Tambin puede ser asumida para ser
soportada por tecnologas perfectas. Este almacenaje y procesamiento ideal, tiene
las siguientes caractersticas:

Capacidad de almacenamiento ilimitada
Cero instruccin de tiempo
La informacin es organizada haciendo uso de entidades, relaciones con
atributos y variables estado.

88
La informacin nunca se pierde, borra o corrompe, fuera de un acceso
deliberado de una actividad de solicitud de borrado.
Derivaciones, reglas de relacin y de integracin y participacin
restringida, son definidas en el EEM.
Las operaciones son llevadas a cabo con precisin infinita.

Naturaleza estratgica del modelo esencial de empresa

Para construir un EEM se requiere de un mayor empeo 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 duplicacin de esfuerzos, inconsistencias
de informacin en algunos sistemas, etc. En algunas organizaciones, la naturaleza
estratgica de informacin es claramente reconocida y no es difcil para obtener
recursos y manejarlos de manera corporativa. Los EEM son de mayor importancia
en cuanto a la planeacin estratgica propiamente dicha.

El EEM describe la suma total de la informacin. Funciones y eventos son
utilizados por toda organizacin. Cada usuario debe ser enterado de alguna parte
de este modelo. Hay por consiguiente mltiples vistas, cada una corresponde al
subconjunto de actividades de la empresa a la que un usuario en particular es
comprometido. (En este contexto, el trmino usuario se refiere a algn agente que
lleva a cabo parte del trabajo de la empresa, Incluye a ambos gente y sistemas de
aplicacin).


89
4.2 Estructura del modelo esencial de empresa

Muchas de las herramientas de modelado usadas en el EEM son tambin
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 relacin 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 informacin de la empresa: Se encarga de describir
la informacin que es utilizada por la propia empresa.
Aspecto del funcionamiento de la empresa: Describe las fracciones
de eventos y el nmero de ocurrencias del aspecto de los componentes
de la informacin.

4.2.2 Aspectos de la informacin de la empresa

Estos aspectos se encargan de describir la informacin que se usa en la empresa.
El ERD es implementado para destacar las caractersticas estticas de la
informacin. Tambin proporciona la mayor semntica en cuanto al significado de
la misma.

Los diagramas de transicin estado son utilizados para destacar las dinmicas de
los efectos que acontecen en esta informacin y cundo.


90
Nota: El tipo de dato abstracto y las especificaciones de operacin de la compaa,
son parte de la librera de recursos de la misma. Las especificaciones de texto son
implementadas para definir el detalle al nivel ms bajo.

En particular, este detalle incluye los atributos de las entidades y las reglas de
participacin de la relacin. Estas vistas apropiadas son mostradas a continuacin
de manera junta, con enlaces entre componentes mostrados por lneas entre ellos.

Modelo esencial de
Empresa

Librera de
Recursos de la
Empresa

Diagrama de
entidad-relac.
tabla de
entidad-evento
Tabla de
entidad-funcin
Diagrama de
Transicin E-S
Subtipos de
especificacin
Relacin de
especificacin
Entidad de
especificacin
Entidad asociat.
de especific.
Atributos de
especificacin
Especificacin
operacin-emp.
ADT de
especificacin

91
4.2.3 Estructura del aspecto de la informacin

Diagrama de entidad relacin: Esta es la principal herramienta de
modelado que se utiliza para declarar los componentes de los aspectos
de informacin de la empresa. Nos muestra entidades, asociaciones,
relaciones y subtipos.
Tabla de entidad evento: Muestra la interaccin de eventos empresa
con entidades y relaciones de un alto nivel.
Tabla de entidad funcin: Nos ensea un panorama general de todas
las funciones dentro de la empresa, as como el uso que se le da a la
informacin. Puede proporcionar un mayor detalle, mostrando funciones
individuales que estn al alcance de los sistemas de mayor importancia.
Diagrama de transicin entidad - estado (eSTD): Cada entidad
puede contar con una o ms 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 especificacin: Cada entidad que no es asociativa, tiene
una correspondiente de especificacin, la cual incluye una definicin de
atributos.
Relacin de especificacin: Al igual que la anterior, cada relacin
tiene una correspondiente de especificacin.
Especificacin de entidad asociativa: Cada entidad asociativa,
cuenta con una correspondiente de especificacin de la misma. Esta
incluye la definicin de los atributos de la entidad.
Especificacin de subtipos: Cada subtipo de una entidad. Tiene una
correspondiente de especificacin.
Especificacin de atributos: Cada atributo de una entidad, cuenta
con una correspondiente de especificacin. Esta entidad deber
aparecer por lo menos en un ERD.


92
4.2.4 Visibilidad del ERDs en la empresa

El principal componente de informacin aparece en un ERDs. Aunque algunos
pueden aparecer en ms de uno. Las entidades pueden aparecer en ms de un
ERD. Debern hacerse presente por lo menos en uno. No existe ninguna notacin
especial para mostrar que una entidad aparezca en algunos ERDs.

Toda relacin debe aparecer en un ERD. Usualmente no aparecen en ms de un
ERD, aunque stas dependen mucho de la tcnica de soporte que se use. En
ambientes automatizados, no poseen problema alguno. En una entidad asociativa
podrn aparecer una o ms vistas como una sola.

Subtipos en ERDs

Estos son mostrados en forma cotidiana en un diagrama de entidad relacin ERD.


93
4.3 Estrategias para la construccin y mantenimiento de la
EI A

Si no hay EIA existentes, entonces forzosamente necesitan ser creadas; si hay
EIA, habr que mantenerlas como requerimientos de cambio de informacin para
la empresa.

4.3.1 Principales estrategias para la recoleccin de
informacin

Existen tres estrategias principales que pueden ser adoptadas en la construccin y
aspectos de informacin de la empresa:

1. Factor de recoleccin: Las entidades, relaciones y atributos que son del todo
relevantes para las actividades de la empresa, se modelan sin considerar
cualquier implementacin de especificacin o uso, ya sea en forma presente o
futura.
2. Modelando usos de informacin existentes: Es la presencia de datos en
forma de archivos, registros, bases de datos, etc. En este caso se efecta un
estudio para identificar el contenido de la informacin. A esto tambin se le
llama como una especie de Ingeniera Contraria, donde las decisiones de un
diseo previo de actividades estn sin o por hacerse.
3. I dentificacin de la informacin para el soporte de las funciones de la
empresa: Las funciones especficas de la empresa son examinadas y su
informacin es usada para identificar los requerimientos. Estas funciones,
tambin pueden ser una especie de sistemas anticipados o bien catalogados
dentro de una planeacin estratgica.


94

4.4 Heursticas para construir y refinar el EIA.

Tcnicas para la construccin de un nuevo EIA, usando
factores basados en el modelado de informacin.

La captura del modelado de informacin y los aspectos abstractos ms
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
representacin y la organizacin de los mismos.

Los factores de informacin basados en este tipo de anlisis resultan ser muy
efectivos, ya que la informacin recolectada y la tcnica de sntesis pueden
utilizarse para construir un modelo. Como un ejemplo de sta tcnica supone el
factor de seguimiento que ha sido establecido durante la intervencin de los
usuarios.

Como podemos observar, este es un factor de modelo con dos componentes
ligados entre s. Empleados y departamentos resulta ser una generalizacin de
todo un conjunto de hechos provenientes del mundo real.

Los empleados son asignados a los departamentos
J uan Prez es asignado al departamento de Contabilidad
Pedro Pramo es asignado al departamento de Calidad

95
Esto es, donde J uan Prez y Pedro Pramo ambos son similares en el sentido
de que ellos son empleados. Adems, el modelo es elemental desde el punto de
vista de que no pueden ser descompuestos en unidades ms pequeas sin que
pierdan el significado. Los componentes atmicos son Empleados y
Departamentos. Ahora supongamos los siguientes factores de modelado:

Estos tambin son del tipo elemental e involucran a dos componentes atmicos.
Sin embargo, estos factores modelo son de un tipo diferente de procedimientos.
En este caso. Empleados y Departamentos resultan ser una abstraccin los
cuales pueden desempear 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 Recoleccin de Hechos

El modelado de informacin 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, declaracin de polticas en la empresa, documentos y estndares
externos.
2. Resumidos: Los hechos se encuentran a menudo en una forma muy
especfica, por ejemplo: J uan se encarga de llevar el orden Prez, Lpez y
Martnez 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 va tal, que mantenga la integridad y su entendibilidad.

Tcnicas 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 recoleccin de
hechos. Esto a su vez alentara confianza en cuanto a la habilidad del analista para
comunicar y no alarmar al usuario con un mtodo de intimidacin.

Las siguientes tcnicas son tiles para identificar entidades, relaciones y atributos.
La seleccin depender de la reaccin y adiestramiento del usuario:

1. El ERD puede ser dibujado interactivamente durante la entrevista. Estos
hechos con cuestiones o preguntas adicionales tales como: Que informacin
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 ms tarde y dibujados en un ERD. A continuacin
Ejemplificaremos este patrn de hechos:

Un <Empleado> est asignado a <Dependencias>

97
Esto nos ayuda a clarificar que hay entidades llamadas Empleados y
dependencias con una relacin entre ellas.

3. Usar representaciones tabulares de la informacin requerida. Esta es una
tcnica de acercamiento a bajo nivel pero que trabaja bien. Para entidades
incluyendo las asociativas una representacin tabular de los atributos puede
ser muy til. Por ejemplo: Cuando hablamos de la entidad asociativa
asignacin, 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, relacin o de
asociatividad. El uso de tablas induce a una reaccin 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
Asignacin Dependencias Asignacin

98

4.4.2 Establecimiento de los ciclos de vida de las entidades

Cada entidad puede tener una o ms variables estado. Estas a su vez, describen
una caracterstica de los cambios que sufren las entidades fuera de tiempo. No
todas las entidades tienen variables estado, aunque hay algunas que tienen ms
de una. Por ejemplo en el archivo Empleados las variables estado son: estatus
del empleado, estado civil.

Identificacin de eventos que afectan una entidad

Las siguientes preguntas son lo suficientemente productivas para este caso:

Se cuenta con ms de un posible evento creacin? 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

Asignacin

Empleado

99
Existen algunos eventos que causan valores a ser asignados a atributos,
despus 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 adems una buena
estrategia.
Hay algn evento que cause que la entidad participe en una relacin?. Si
el evento crea una ocurrencia de la relacin pero no requiere de un
acceso a la entidad, este evento no aparecer en el eSTD.
Hay algn 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 relacin entre ellas. El uso de la tabla
entidad evento nos proporciona una mejor visibilidad al respecto.
Hay alguna funcin conocida que utilice esta entidad?. Si los hay, los
eventos del mundo real de esta funcin responden a ser probablemente
uno de los que requieren acceso a esta entidad.

Una vez identificado la versin 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
accin 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 participacin en una relacin u otra
memoria acontecieron en el pasado.

100
4.4.3 Normalizacin

Principios generales

El concepto general de normalizacin se refiere a que hay ciertos criterios de
deseables de naturaleza estructural para que todo modelo de informacin deba o
pueda ser conformado. Estos criterios han sido dados en forma de nmeros
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 normalizacin sea meramente estructural
como muchos de los criterios involucrados con semnticas, pero es ciertamente
ms concerniente con la sintaxis que con el propio significado, comparado con el
modelo de entidad relacin ERD. Sin embargo, normalizacin es una tcnica muy
til particularmente organizando un modelo de datos almacenados o bien, para
checar que las tcnicas de semntica aplicadas o defendidas por YSM hayan sido
correctamente aplicadas.

Bsicamente las reglas de normalizacin estn encaminadas a eliminar
redundancias e inconsistencias de dependencia, en el diseo de las tablas.

Representacin tabular de los datos

Para llevar a cabo la normalizacin imaginemos una tabla de valores. Esta a su
vez, puede ser transcrita de una estructura de archivo. Alternativamente para una
entidad propuesta la asociacin o la relacin, 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 clula 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 relacin: La entrada en la columna corresponde
a una va de identificacin de una fila a otra de la tabla. Este tipo de
columna es usualmente llamada llave o clave fornea. YSM reemplaza
las llaves forneas por la relacin equivalente y documentada
acordemente. En documentaciones de archivos existentes no podr
aparecer inmediatamente ya que hay llaves forneas.

Normalizacin entonces, se aplica a pruebas o test semejantes a tablas, cualquiera
que sea original. La normalizacin es esencialmente aplicada solo a datos
almacenados. Est dirigido permanentemente para evitar la duplicacin de los
datos con problemas consecuentes en el mantenimiento e integridad. YSM permite
la falta de atributos almacenados para ser derivados de otros.

A continuacin haciendo uso de nuestro ejemplo de estudio del sistema de
nmina, llevaremos a cabo la normalizacin de algunas tablas con el propsito de
tener un panorama ms 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 formalizacin normalizacin (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 informacin de los empleados
de nmina de nuestro caso de estudio y los datos a guardar son los siguientes:

Nombre del empleado, nombre de la empresa, direccin de la
dependencia, descripcin del puesto, tipo de puesto e-mail o url si es
que lo tienen.

En principio comenzaramos por definir la siguiente tabla:

Empleados
Nombre Dependen. Direccin Puesto Tipo puesto url1 url2
J uan 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 normalizacin cero
(0), ya que ninguna de nuestras reglas de normalizacin ha sido aplicada. Observe
los campos url1 y url2 Qu haremos cuando en nuestra aplicacin necesitemos
una tercer url?. Quieres agregar otro campo columna a tu tabla y tener que
reprogramar toda la entrada de datos de tu cdigo?. Obviamente no, lo que se
quiere es crear un sistema funcional que pueda crecer y adaptarse fcilmente a
los nuevos requerimientos. Para dar solucin a este problema, recurramos a la
regla de primer nivel de normalizacin 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 bsicamente
que hay que poner un campo tipo contador autoincrementable para cada registro.

103
De otra manera, Qu pasara si tuviramos dos empleados llamados J uan y
queramos diferenciarlos?. Una vez aplicado el primer nivel de formalizacin
normalizacin (F/N), nos conducira a la siguiente tabla:

Empleados
I d_ empl Nombre Dependen. Direccin Puesto Tipo puesto Url1
1 J uan Sistemas T. Q. 80 Encargado A C Abc.com
1 J uan 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 limitacin del
campo url. Ms 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 formalizacin normalizacin

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

Hemos separado el campo url en otra tabla, de tal forma que vamos a poder
aadir registros en el futuro sin tener que duplicar los dems datos. Por
consiguiente, tambin vamos a utilizar la clave primaria para relacionar estos
campos.


104
Empleados
I d_ empl Nombre Dependencia Direccin Puesto Tipo puesto
1 J uan Sistemas T. Q. 80 Encargado A C
2 Pedro R. Humanos 16 Sep. 266 Aux. Admvo B S
Tabla 4.4

I d_ url RelI d_ 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. Ms
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 formalizacin normalizacin

a) Eliminar aquellos campos que no dependan de llave o clave.

El nombre de la dependencia as como el de la direccin de la misma, la
descripcin del puesto y el tipo de puesto no tienen nada que ver con campo
Id_empl; por lo tanto, debern tener su propio Id_dep e Id_psto.


105
Empleados
I d_ empl Nombre RelI d_ dep RelI d_ psto
J uan J uan 1 1
Pedro Pedro 2 2
Tabla 4.6

I d_dep Descripcin de la dependen. Direccin de la dependencia
1 Sistemas Torres Quintero no. 80
2 Recursos Humanos 16 de septiembre no. 266
Tabla 4.7

Puestos
I d_ psto Descripcin del puesto Tipo de Puesto
1 Encargado A Confianza
2 Auxiliar administrativo B Sindicalizado
Tabla 4.8

I d_ url RelI d_ 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 I d_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 aadir 150 empleados, mientras que nada
ms se necesita insertar una vez el nombre de la dependencia sistemas.

Nuestra tabla de empleados y urls podrn crecer todo lo que sea necesario, con la
seguridad de que no habr duplicacin ni corrupcin de datos.

La mayora de los analistas y desarrolladores dicen que con tercer nivel de
normalizacin es ms que suficiente; sin embargo veremos la cuarta y quinta
forma normal aunque no sean del todo necesarias.

Antes de definir este cuarto nivel de formalizacin normalizacin, 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 normalizacin. Ahora bien, imaginemos por un momento que ponemos el
campo url en una tabla separada y cada vez que introduzcamos un registro
tambin agregamos una sola fila en la tabla de urls. Entonces tendramos una
relacin de uno a uno: cada fila en el archivo empleados tendra exactamente
una fila correspondiente a cada url. Para efectos y propsitos de nuestra
aplicacin, no sera til la normalizacin. 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 relacin de uno a muchos y resulta ser
el tipo ms comn.

La relacin varios con varios, resulta ser ligeramente un poco ms 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 estn relacionados con muchos urls, con lo cual
las tablas quedaran de la siguiente manera:


107
Empleados
I d_ empl Nombre RelI d_ dep RelI d_ psto
J uan J uan 1 1
Pedro Pedro 2 2
Tabla 4.10

Dependencias
I d_dep Descripcin de la dependen. Direccin de la dependencia
1 Sistemas Torres Quintero no. 80
2 Recursos Humanos 16 de septiembre no. 266
Tabla 4.11

Puestos
I d_ psto Descripcin 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
Relacin_url
I d_ relacin RelacinI d_ url RelacinI d_ empl
1 1 1
2 1 2
3 2 1
4 2 2
Tabla 4.14

Para disminuir la duplicacin de los datos (este proceso nos conducir al cuarto
nivel de normalizacin), hemos creado una tabla que slo tiene claves externas y
primarias Relacin_url.

Adems, fuimos capaces de reconocer las entradas duplicadas en la tabla urls
creando la tabla relacin_url, con lo cual podemos decir que la relacin que ambos
J uan 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 slo se
aplican a las relaciones muchos - con muchos.

La mayora 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 normalizacin, se dice
que existe un quinto nivel de forma normal el cual resulta un poco esotrico, ya
que en la mayora de los casos, no es necesario para lograr una mejor
funcionalidad en nuestra aplicacin.


109
4.5 Mantenimiento del aspecto de informacin de la empresa

El mantenimiento del aspecto de informacin 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 informacin de la compaa.

El mantenimiento de actividades puede ser dividido en las siguientes categoras:

1. Adicin de nuevos datos: Estos pueden ser ambos:

v No es identificado como parte de la informacin de la empresa,
aunque de hecho hayan sido utilizadas. Esta omisin necesitar ser
remediada.
v Nuevos requerimientos de informacin de la empresa. Cambios
consecuentes en las actividades de la compaa 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 (suposicin).

2. Borrado de datos: Sobre un perodo de tiempo la operacin de la
empresa puede cambiar, as que cierta informacin 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 vas o caminos de identificacin 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 relacin o tienen una lista de
atributos muy similares, entonces ellos podrn ser supuestos (aliases)
an cuando sus nombres sean diferentes.
v Dos relaciones son parecidas si tienen el mismo orden y se refieren a la
misma entidad, entonces podrn 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 podrn 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 Tcnicas para adicionar nuevos requerimientos en un
modelo existente

Estas peticiones o solicitudes pueden ser propuestas en forma manual o
electrnicamente, pueden ser semiautomticas en ambientes CASE sofisticados
que tienen facilidades para construir modelos de sistemas y soportados por la
empresa como manejador de recursos de informacin. Estas operaciones y
decisiones son visibles y controladas por el analista de informacin.


111
4.5.2 Adiciones para el EIA (Aspecto de informacin de la
empresa)

Comparando el uso de informacin con el EI A, resulta conveniente llevarla a cabo
por medio de Laying (Colocacin) el sistema de informacin 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 informacin 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 EI A, este
puede ser un serio candidato a ser desaparecido del modelo. Esto puede ocurrir
por un excesivo entusiasmo del modelado de informacin que fue ms all
del alcance de las actividades de la empresa.

Por lo tanto, tambin se puede hacer que esto sea ms 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 especfico, 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 algn tiempo futuro.


114
CAPITULO 5

LA RELACION ENTRE EL SISTEMA Y LA EMPRESA

5.1 Introduccin

El sistema y el medio ambiente

El sistema es una coleccin de funciones e informacin organizada para uno o
varios propsitos especficos. Este a su vez puede existir o bien estar en plan de
construccin.

Un sistema es apropiado en un gran medio ambiente conteniendo organizaciones,
personas y dispositivos con los cuales el sistema interacta. El lmite 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 coleccin de sistemas

La empresa consiste de muchos sistemas. Desde otro punto de vista, es por s
mismo un sistema. Conteniendo funciones e informacin, en forma ordenada para
alcanzar o lograr la misin que se propuso la compaa.

De hecho, la distincin entre la empresa y un sistema es un relativo uno. La
empresa es un sistema en el cual pueden haber otros pequeos o subsistemas.

Ciclos de vida del sistema

Algunos proyectos de sistemas se ejecutarn en paralelo y lo harn dentro de la
empresa.
Relacin entre Sistema y Empresa

115

Los modelos de empresa deben soportar estas actividades simultneamente, en
forma continua o muchas veces mientras estn todava bajo construccin.

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 compaa
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 informacin 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 compaa.


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 continuacin en la siguiente figura:

Biblioteca de recursos
de la empresa

tipos de dato Operaciones Alquiler de
abstractos de empresa de proyectos

Requerimientos
estratgicos

Requerimientos
para el soporte Requerim.
esencial de sistema de los empleados

modelo esencial modelo esencial
de empresa de sistema

I mplementacin Proyectos
de los planes Implementacin de charter
de la los requerimientos
empresa para el soporte
del sistema

I mplementacin
de los
requerim.
del
empleado

Implementacin Biblioteca de Implementacin
de los modelos de recursos de la de los modelos de
empresa empresa sistema

Mantto.del
modelo
esencial de
empresa
Identific.
del sistema
de
Nmina
Facilidades
para el
diseo de la
empresa

Diseo
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 compaa. Al usar esta biblioteca, se cuenta con los
siguientes beneficios:

v Re Utilizacin de las funciones lgicas y de las especificaciones:
Las operaciones de especificacin permiten que las funciones sean
definidas una vez y utilizadas en muchos sistemas.
v Abstraccin en la representacin de los datos: Los tipos de datos
abstractos pueden ser especificados aunque no tengan atributos o algn
otro tipo de dato elemental que haya sido definido como ADT.
v Implementacin de recursos compartidos: esto se da sin
necesidad de duplicar el trabajo. Estos recursos incluyen bases de datos,
bibliotecas de objetos, subrutinas y algn software en comn.

La relacin entre la biblioteca de recursos de la empresa el modelo esencial de la
misma y el sistema se muestran a continuacin:
SEM

EEM Biblioteca de recursos de la empresa

Aspectos
de
informacin
Aspectos del
funcionamiento
Aspectos de
informacin
Atributos
Operaciones
Tipos de dato
abstractos ADT
Minispec

118
5.2 Iniciacin del proyecto de sistema

Al decidir cules sistemas se van a construir y cundo, es un importante problema
de tipo estratgico. Por lo tanto, las metas de la compaa son examinadas y en
consecuencia se toman decisiones en las cuales se eligen los lmites del sistema y
cundo los proyectos debern ser iniciados.

5.2.1 Modelos de empresa y planeacin estratgica

Los proyectos de sistema son iniciados para el beneficio de la empresa. Toda una
disciplina de negocios sabe cuando una planeacin estratgica existe con el
propsito de ayudar en la propia identificacin y comienzo del sistema. El modelo
esencial de empresa (EEM) puede ayudar en la planeacin estratgica de la
compaa con el fin de decidir cual sistema tendr el mayor costo efectivo para
comenzar con la apropiada distribucin 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 definicin del protocolo para la investigacin y posible
construccin de un sistema. Puede incluir identificacin preliminar sobre el alcance
del sistema, en trminos de eventos, funciones, entidades y relaciones entre el
responsable del mismo.

La tabla entidad - funcin (vista anteriormente) es muy til en cuanto a
planeacin estratgica se refiere.


119
Esta se encarga de mostrar las relaciones entre las funciones llevadas a cabo y la
informacin requerida para soportar las mismas. Estas tablas tambin pueden ser
usadas para estudiar las dependencias entre las unidades econmicas de la
empresa o de algunos posibles sistemas. Estos estudios son actividades de
planeacin estratgica.

Por ejemplo, supongamos tres posibles sistemas que estn bajo consideracin.
Especficamente si el sistema A es definido como la creacin de una entidad (o
relacin) 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
Ano ha sido construido previamente. Esto implica una relacin de dependencia
entre sistemas.

Si B depende de A y C de B (posiblemente de A tambin). En este caso no hay
mucho problema, ya que el sistema A debe ser construido primero despus B y
luego C. Pero desgraciadamente las cosas no resultan ser tan simples, es ms
probable que B dependa de A, C de B y A de C. Cuando esto ocurre hay dos tipos
de eleccin:

Desarrollo de algunos sistemas en paralelo
Reorganizacin de los lmites del sistema propuesto y re-examinar
la dependencia.

Es para esta segunda opcin que la tabla entidad funcin resulta del todo til
para visualizar la relacin entre funciones.

Este concepto es bastante til. La informacin 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 lmites. La informacin es
verdaderamente compartida entre sistemas y de ninguno es
propia.

Un sistema es definido como una unidad propia de informacin, 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 informacin 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 funcin. El siguiente ejemplo muestra tres sistemas propuestos
as como tambin, los modelos de componentes de informacin 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 sealado con
un sombreado. (Las variables de estado fueron omitidas de la tabla para efectos
de simplificacin).


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
Informacin
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 tendran
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 tambin ser clarificada
cambiando a una forma diagonal para clarificar la relacin entre los sistemas:


122

SISTEMAS Y FUNCIONES INCLUIDAS
SISTEMA A SISTEMA B SISTEMA C
Componente
de
Informacin
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 funcin. Puede ser
difcil evitar elegir los lmites del sistema que vengan a prevenir ms, teniendo la
responsabilidad de crear ocurrencias de una entidad. Por ejemplo en una
compaa de servicios como puede ser nuestro caso de estudio de Nmina del H.
Ayuntamiento de Colima, habr muchas actividades de la institucin que causen
una nueva ocurrencia de empleados a ser identificados.


123
5.3 Construccin 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 domstico sobre un contrato especfico para
soportar un cliente. La economa 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 estaran todava en construccin.

5.3.1 Construccin en primer lugar del modelo esencial de
empresa

Los modelos de empresa pueden ser construidos independientemente de cualquier
actividad del proyecto de sistema. La construccin de modelos empresa comienza
por ser proyectos a s mismos. Una vez que los modelos de empresa estn en un
sitio determinado, los proyectos cuentan con toda la informacin disponible. La
elaboracin de un modelo de sistema comienza a manera de ordenamiento de las
partes que son de inters, adems de una reorganizacin de las vistas
especializadas para el sistema.

Hay una primera desventaja en la construccin de modelos de empresa.
Dependiendo del tamao de la misma elaborar estos modelos puede tomar un
largo tiempo y por ende mayores recursos. A fuerzas la compaa 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 econmico.
Relacin entre sistema y Empresa

124
Permitir que los proyectos de sistema continen como antes y
profundizar en los problemas de alias y de integridad de datos malos
o muy pobres.
Soportar ambos la independencia y coordinacin en la construccin
de modelos, los cuales requieren de un mayor cuidado y de ms
recursos.

5.3.2 Solicitud para el mantenimiento del modelo de empresa

En casos donde los modelos de empresa no estn completos o bien estn 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 informacin que provenga de aquellos
modelos. Si como acontece a menudo el proyecto de sistema descubre alguna
informacin no contenida en aqul, 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 razn esto no
ocurre, el grupo del modelado de empresa no es soportado largamente por los
proyectos de sistema que se estn ejecutando. Si no es soportado por otros
proyectos de sistema, los de modelado es muy probable que fallen. Estos a su vez
sern 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 tambin 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 informacin similar. La mayor
diferencia es un punto de vista: los modelos de empresa captan informacin
considerando a la empresa de manera total; stos a su vez se enfocan a las
necesidades especficas de tal manera que la informacin 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 propsito de sugerir cul
proyecto de sistema debe comenzar o continuar. Entonces, a condicin de que
exista una coordinacin 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 elaboracin 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 informacin necesaria del modelo de empresa
antes que esta pueda continuar.


126
5.3.4 La relacin entre la empresa y los aspectos del sistema
de informacin

El aspecto de informacin de la empresa es un modelo esttico que describe cada
entidad dentro de la misma, atributos y relaciones entre entidades. Este aspecto
junto a aquellas partes de informacin, entidades, relaciones y eventos que estn
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 informacin. Los modelos de sistema pueden, mostrar nuevas
reas de informacin 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 participacin.
3. Para cualquier relacin de sistema habr una correspondiente relacin de
empresa o entidad asociativa, haciendo referencia a las ocurrencias de la
misma con sus respectivas reglas de participacin.
4. Para cualquier atributo visto en el sistema de especificacin entidad habr
un atributo de especificacin en el EEM. Los atributos deben ser para la
misma entidad.
5. Para cualquier relacin de acceso vista en una tabal de sistema entidad
evento habr un idntico acceso en la misma tabla.


127
6. Cualquier condicin vista en un sistema eSTD debe ser vista en la
correspondiente empresa eSTD. Esta condicin puede ser una transicin
entre el origen similar y los estados destino junto con la accin en que
dicha transicin deba ser igual.
7. Cada sistema evento debe tener uno correspondiente de especificacin
empresa (tambin tiene un evento de especificacin de sistema como parte
del modelo esencial de empresa. (SEM).
8. Cada funcin mostrada en una tabla de sistema funcin entidad debe
tener una correspondiente funcin en una tabla de empresa entidad
funcin.


128
CAPITULO 6

EL MODELO ESENCIAL DE SISTEMA (SEM)

6.1 Introduccin

Papel que desempea el modelo esencial de sistema

Un modelo esencial de sistema es una representacin underlying de un sistema de
Nmina. Esta poltica deber llevarse a cabo sin importar qu tipo de
implementacin ser elegida.

El SEM es una declaracin 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
confusin 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 declaracin
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 estn involucrados o
familiarizados con la poltica funcional del sistema: Diseadores,
nuevos empleados, administradores, etc. Pueden observar al sistema
en cada nivel a detalle, para tener un panorama ms general al
respecto.

Libertad de tecnologas previstas o predispuestas

El SEM se encarga de documentar un sistema con el propsito de suprimir
cualquier aspecto de implementacin del proceso o de los requerimientos de
almacenamiento. Por ejemplo, un SEM de un sistema de Nmina debera mostrar
el Nmero del empleado y las horas trabajadas como todo un sistema de
entrada. Por lo tanto, sera incorrecto que muestre la tarjeta registradora. El
uso de una tarjeta de papel contendr esta informacin como una implementacin
especfica. El modelo permite la captura de la solicitud de entrada nmero de
empleado y horas trabajadas. Esto a su vez permite la concentracin de la
informacin, antes que el medio lleve o transporte la misma.

El SEM proporciona la poltica de underlying para poder llevarse a cabo con una
variedad de implementaciones viejas y nuevas. Una organizacin puede ejecutar o
correr una Nmina 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
poltica esencial con implementaciones incluidas no asumidas:
v Libertad para disear el mejor sistema utilizando cualquier
tecnologa no permitida.
v El SEM est hecho para suprimir pequeas tecnologas. Esto
permite ser entendido fuera de los detalles tcnicos, haciendo al
modelo un poco ms largo y difcil de revisar.
v El modelo es una forma que puede ser comprendido por expertos
en la materia, quienes no estn del todo confrontados con los
detalles tcnicos e irrelevantes a cerca de la implementacin.

El concepto de Tecnologa perfecta

Ayuda a suprimir la implementacin de los detalles; el SEM puede ser visualizado
como una perfecta tecnologa en ejecucin. Este proceso es ideal en ambientes
que son definidos como una ejecucin en un procesador conceptual, con:

v Infinita capacidad de almacenamiento no voltil
v cero instruccin de tiempo
v Habilidad para correr varios de procesos simultneamente
v No errores
v Toas las entradas / salidas son llevadas a cabo en tiempo zero,
utilizando una forma conceptual, antes que cualquier tecnologa
especfica.


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; tambin pueden estar en tiempos discretos o
continuos.
v Una entidad relacin 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 mquinas de estado.
Cada uno de estas puede a su vez comunicarse con otras
mquinas de estado haciendo uso de los flujos de eventos. Estos
equipos pueden activarse (Habilitar / deshabilitar y ser disparados
o puestos en movimiento) por otras mquinas y tambin 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 tecnologa 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 inversin significativa, por lo tanto el analista debe intentar evitar
elaborar un SEM para el cual no exista una plena justificacin de llevarlo a cabo.

Se estima que el costo de implementacin 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 documentacin de requerimientos de usuarios
para el sistema y tambin a la organizacin de los mismos, como referencia a las
personas que construyen y dan mantenimiento al sistema.

Como los requerimientos del sistema son la parte ms crtica 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 iteracin del mismo. Los requerimientos son la base para el diseo; como stos
cambian, los diseos tambin lo hacen en forma por lo ms dramtica.

133
6.2 Estructura del modelo esencial de sistema

El SEM resulta ser demasiado grande para ser comprendido en una sola sesin 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
resea en particular o bien de la recoleccin de requerimientos. Todo tipo de vista
se disea, evala y se revisa por un rea especfica 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 declaracin de
propsito. 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 posicin aproximada, en un tringulo de funcin informacin 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 estndar del SEM
se muestran a continuacin:

Este aspecto del modelo destaca Estos aspectos se enfocan en el uso
el alcance del sistema y la de los sistemas y la modificacin
razn para que ste exista. de la informacin. Adems, la tabla
Se construye antes del aspecto entidad evento se usa para enlazar
funcional. Este aspecto en el medio ambiente;
la tabla entidad funcin se
utiliza
para enlazar el aspecto de
informacin con la del
funcionamiento.

Este aspecto destaca el funcional Este aspecto destaca las salidas como
y dinmico 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
Informacin
Declaracin de Propsito
Aspecto de ejecucin

Informacin Mapa de vistas del
modelo esencial de
sistema

Tiempo
Funcin

Figura F
Diagrama de entidad
relacin
sistema
Tabla entidad
funcin
sistema
Tabla entidad
Evento
sistema
Diagrama de
contexto
Especif.
Entidad sist.
Lista de
eventos
Especif. de
terminac.

Minispec
Especif. de
Evento
almacenad
o
Especif. del
Flujo de
eventos
Diagrama
Funcional de
transicin
estado
Especif.
del
Flujo de
acceso
Especif.
del
Flujo de
acceso
Especif.
de
procesos

Diagrama de
Flujo de
datos
Diagrama de
transicin
entidad
estado
Especific. de
datos
almacenados
Especif.
Entidad
asoc.
sistema
Especif.
Entidad
sist.
Especif. de
Relacin
sistema
DECLARACI ON DE PROPOSI TO

135
6.4 Aspecto de informacin

Los aspectos de informacin cuentan con el papel principal de enlazar el modelo
esencial de sistema con el aspecto de informacin de empresa. Estoas aspectos
incluyen:

Diagramas de entidad relacin 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
relacin
sistema
Especif.
entidad
sistema
Diagrama de
transicin
entidad estado
sistema
Relacin de
especificacin
sistema
Especif.
entidad
asoc.
sistema
Relacin
especif.
sistema

136
Diagramas de transicin entidad estado sistema (eSTDs
sistema): se usa para definir los cambios de estado de las
entidades.
Especificacin de entidad sistema: Se utiliza para definir el uso de
los sistemas de entidades.
Especificacin de relacin sistema: Para definir el uso de sistema de
relacin.
Especificacin 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 funcin sistema: Esta se encarga de mostrar
cules son las funciones de acceso del sistema y cules son las
partes del aspecto de informacin.


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
terminacin

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.
Especificacin de terminacin: Hay uno para cada terminador
Especificacin del flujo de datos: Existe uno para cada flujo de
datos, el cual se muestra en el diagrama de contexto.
Especificacin del flujo de eventos: Hay uno para cada flujo, el
se observa en el diagrama.
Especificacin de datos almacenados: Cada almacenamiento
es visto en el diagrama. Estos adems definen cuales
entidades y relaciones estn en l.
Lista de eventos: Define los eventos que el sistema debe
responder.
Especificacin del flujo de acceso: Para cada flujo de acceso
nombrado, este debe ser observado en el diagrama.
Especificacin de evento: Cada evento cuenta con una
especificacin, ambos en el frame o en el formato de la tabla.


139
6.6 Aspecto funcional

Diagrama de
flujo de
datos
Comportamiento
del diagrama
transicin 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 Ejecucin

El aspecto de ejecucin es usado para capturar los requerimientos acerca del
sistema en funcin.

Estas formas de ejecucin incluyen:

Especificacin 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 (nmero de instrucciones) para cada activacin
a su vez es definida.

Especif.
de
procesos
Especif.
de
transicin
Comportamiento
del diagrama de
transicin estado

141
Los procesos continuos cuentan con una muestra discreta de
frecuencia la cual pueden exceder en un momento dado.
Comportamiento de la especificacin de transicin estado:
Cada cambio de estado debe tener un tiempo mximo de
estado, para que la transicin pueda ser completada despus
de convertirse la condicin en verdadera.
Especificacin de terminacin: Cada terminador puede ser
simple o bien multifuncional.


142
CAPITULO 7

CONCLUSIONES

Como primera instancia se puede decir segn SEEN que el anlisis estructurado
permite al analista conocer un sistema o proceso (actividad) en forma
lgica y manejable. Por lo tanto, el objetivo final de ste tipo de anlisis es
organizar las tareas asociadas con la determinacin de los requerimientos y as
tener una comprensin completa y exacta de una situacin dada.

A finales de los aos 60s y los inicios de los 70s el anlisis estructurado surge de
la necesidad de buscar una forma interpretativa ms rpida y eficiente, en donde
se puedan definir los requerimientos del usuario y del sistema. Sin embrago esto
todava no se daba, debido a que existan grandes volmenes de informacin que
haba que leer los cuales a su vez, traan como consecuencia problemas de tipo:
monoltico, redundancia y ambigedad.

Como consecuencia de esto, surge una gran variedad de diagramas que permiten
representar las especificaciones funcionales en forma sencilla y de manera rpida,
aumentando con ello el grado de comunicacin entre las especificaciones
funcionales y el usuario final (analista, diseador y programador).

Posteriormente, a mediados de los aos 70s estando el anlisis estructurado en
su apogeo y de acuerdo a los avances tecnolgicos, trae una serie de
consecuencias que limitan al analista hacer un buen desempeo de sus
actividades. Entre estos problemas segn Yourdon estn los siguientes:

v Distincin poca y difusa entre los modelos lgicos y fsicos.
v Limitacin para modela<r sistema en tiempo real.

Conclusiones

143
v El modelo de datos se haca de una manera muy primitiva.

Estas y otras razones dieron el nacimiento a grandes mejoras en cuanto al
desarrollo estructurado clsico tales como:

v Diagramas de entidad relacin
v Diagramas de transicin estado
v Divisin de eventos
v Modelos esenciales
v Modelos de implantacin

Con la incorporacin de estas mejoras surge el Mtodo del Sistema Yourdon,
el cual en su momento vino a revolucionar todo lo referente en materia de Anlisis
y diseo estructurado ya que a partir de los aos 90s y en la actualidad, se sigue
aplicando para el desarrollo de cualquier tipo de sistema, sin importar los cambios
tecnolgicos que se dan da con da.

Para corrobar lo expuesto anteriormente sobre este mtodo, es el estudio que se
hizo del Sistema de Nmina aplicando dicha metodologa la cual vino a
comprobar que en la actualidad todava es operante, ya que no le pide nada a
ningn otro tipo de paradigma que exista en el mercado del Anlisis y diseo de
sistemas.

Pero a pesar de todo esto segn Yourdon, se siguieron dando problemas tales
como:

v Tras la segunda y tercera correccin de un diagrama, el analista estaba
expuesto a hacer ms cambios.
v Debido a la cantidad de trabajo que se requera, 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 despus de la fase de anlisis 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 estn utilizando para facilitar la fase de anlisis,
disminuyendo con esto la serie de errores que se cometan anteriormente.

Los diversos aspectos del anlisis estructurado han cambiado gradualmente a lo
largo de los ltimos aos. Estos principales esquemas de cambio contemplan lo
siguiente segn Yourdon:

v Cambios de metodologa
v Particin de acontecimientos
v Herramientas de modelado en tiempo real
v Integracin ms cercana del modelado de procesos y datos

Y en un futuro no muy lejano se darn si es que ya no se estn dando, los
siguientes cambios:

v Mayor difusin del anlisis de sistemas en niveles
superiores y organizaciones gubernamentales.
v Impacto sobre la industria del software.
v Mayor proliferacin de las herramientas automatizadas.
v Integracin del anlisis estructurado con la inteligencia
artificial.

Finalmente un enfoque nuevo y diferente al anlisis y diseo de sistemas es el
Orientado a objetos (O-O). Los cuales estn basados en los conceptos de la
programacin orientada a objetos.
Conclusiones

145
Estas a su vez pueden ayudar a responder las demandas organizacionales para
nuevos sistemas que requieran mantenimiento, adaptacin y rediseo contnuo.

Bsicamente, en este tipo de programacin los objetos son creados e incluyen no
solamente cdigo acerca de los datos, sino tambin instrucciones sobre las
operaciones que se realizan con ellos.

Usando el enfoque de Coad y Yourdon al anlisis 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 anlisis y diseo estructurado proporciona un enfoque semntico para el diseo
y construccin de sistemas de calidad. A lo largo de las fases el analista debe
proceder paso a paso para obtener retroalimentacin de los usuarios buscando
omisin de errores, ya que al pasar demasiado rpido de una fase a otra, puede
provocar que el analista regrese a corregir partes anteriores del diseo.

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 ms eficiente
diseo o rediseo del mismo, con respecto del sistema que actualmente se
encuentra funcionando.

Con base al estudio realizado, esperamos obtener los mejores y ms eficientes
resultados de nuestro sistema, ya que vendr a subsanar todas aquellas
deficiencias que se tenan en cuanto a operacin y funcionamiento.
Conclusiones

146
Este tipo de metodologa es aplicable a cualquier tipo de estudio, ya que un
problema por ms complejo que sea, siempre podr ser resuelto de una manera
fcil y sencilla.

Esta investigacin se limit en saber si el mtodo del sistema de yourdon, era
aplicable a nuestro caso de estudio: El Sistema de Nmina. Con base a esto
podemos decir que s cumpli con las expectativas finales, ya que se adapt de
una manera fcil y rpida con respecto a lo que se plane desde un principio.

Finalmente cabe hacer mencin, que en un futuro no muy lejano es necesario
hacer uso de otra herramienta como es el caso del anlisis orientado a objetos
(OOA/OOD), ya que es una metodologa que hace uso de una descripcin 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 comn y por ende reducen
el empleo de modismos.

Conclusiones

147
CAPITULO 8

BIBLIOGRAFA

[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, Anlisis y Diseo de Sistemas.
[4] Senn, Anlisis y Diseo de Sistemas de Informacin.
[5] Apuntes de Metodologas en el Desarrollo de Software.
[6] J ames Martin J ames J . Odell, Anlisis Orientado a Objetos.
[7] J acobson, Ingeniera de Softweare Orientado a Objetos.
[8] J uan Guillermo Lalinde, Tecnologas Orientadas a Objetos.
[9] Booch, Anlisis y Diseo de Aplicaciones Orientadas a Objetos.
[10] Ral Crdova, Comparacin entre tcnivas Orientadas a Procesos, Datos y
Objetos.
[11] Yourdon, Objected Oriented Analisys, Press 1991.
[12] Coad & Yourdon, El anlisis Orientado a Objetos: El Mtodo.
[13] Faras M.N., Ramos C.F.F. MultiAgents Systems Methodology Based on a
Study of Agents Interaction. Proc. of the 2 J ornada Ibero Americana de
Engenharia de Software e Engenharia de Conhecimento. Salvador Bahia
Brasil, 2002.

Mario Alberto Lugo Rivero

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Mario Alberto Lugo Rivero

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidad de Colima

SISTEMA DE NOMINA BASADO EN LA METODOLOGIA DE COAD

Anda mungkin juga menyukai