Apuntes AAG Tema2 2010

Anlisis de aplicaciones de gestin TEMA 2
1

TEMA 2

ANLISIS ESTRUCTURADO DE SISTEMAS SOFTWARE

2.1. INTRODUCCIN
2.1.1. CONCEPTOS BSICOS
2.1.2. PRINCIPIOS OPERATIVOS DEL ANLISIS
2.2. INGENIERA DE REQUISITOS
2.2.1. IDENTIFICACIN DE REQUISITOS
2.2.2. ANLISIS Y NEGOCIACIN DE REQUSISITOS
2.2.3. ESPECIFICACIN DE REQUISITOS
2.2.4. VALIDACIN DE REQUISITOS
2.2.5. GESTIN DE REQUISITOS
2.3 TCNICAS DE RECOGIDA DE REQUISITOS
2.3.1. TABLA DE REQUISITOS
2.3.2. ENTREVISTAS
2.3.3. REUNIONES
2.3.4. CUESTIONARIOS
2.3.5. SESIONES JAD Y JRP
2.3.6. PROTOTIPOS
2.4 TCNICAS DE ANLISIS ESTRUCTURADO
2.4.1. TCNICAS DE ANLISIS Y MODELADO DE FUNCIONES
2.4.1.1 Diagrama de Flujo de Datos
2.4.1.2 Tcnicas de especificacin de procesos
2.4.1.3 Diagrama de Descomposicin Funcional
2.4.1.4. Diccionario de datos
2.4.2. TCNICAS DE ANLISIS Y MODELADO DE DATOS
2.4.2.1 Diagrama de Entidad Relacin
2.4.2.2 Diagrama de estructura de datos
2.4.2.3 Normalizacin
2.4.3. TCNICAS DE MODELADO DE COMPORTAMIENTO
2.4.3.1 Diagrama de Transicin de estados
2.4.3.2. Diagrama de Historia de la vida de las entidades.
2.5. EL ANLISIS DE SISTEMAS SEGN LA METODOLOGA MTRICA V.3
2.5.1. ACTIVIDADES DEL PROCESO DE ANLISIS
2.5.2. TCNICAS A UTILIZAR EN EL PROCESO DE ANLISIS

2

2.1 INTRODUCCIN

En este tema se estudiarn mtodos y tcnicas de anlisis para especificar qu
debe hacer una aplicacin informtica.
2.1.1 CONCEPTOS BSICOS

SISTEMA: Conjunto de cosas que ordenadamente relacionadas entre si
contribuyen a un determinado objetivo. Los sistemas pueden contener
subsistemas. Un subistema es un sistema que pertenece a un sistema
mayor.

SISTEMA DE INFORMACIN: Sistema que procesa/gestiona
informacin. La gestin implica operaciones de creacin, destruccin,
modificacin y consulta).

SISTEMA DE INFORMACIN AUTOMATIZADO: Sistema de Informacin
con soporte informtico. Se trata de un sistema de informacin que funciona
sobre un sistema informtico.
Sistema de Informacin = Sistema Informtico (Hardware + Software de base)
+ Sistema Software (Aplicaciones + Bases de Datos)
(El sistema software se desarrolla como un proyecto de ingeniera del
software)
En la siguiente figura se muestra la relacin entre sistemas:
ff
Sistema Social (Pais)

Sistema de Negocio (Empresa)
Otros
Sistemas
Otros
Sistema de Informacin
S.I. Automatizado
Sistema
Informtico
HW
+
SW de base
Sistema
Software
Aplica
cin
+
BD

3

ANLISIS: Distincin y separacin de las partes de un todo hasta llegar a
conocer sus principios o elementos.

ANLISIS DE UN SISTEMA: Proceso de (a) investigacin de los requisitos
que ha de satisfacer el sistema, y (b) generacin de una especificacin del
sistema.

Un analista tiene que averiguar qu debe hacer el sistema (desde el
punto de vista del usuario), pero no cmo va a hacerlo internamente
(ya que ste es el objetivo del posterior diseo del software).

REQUISITO: Condicin o capacidad que debe cumplir o poseer un sistema
o uno de sus componentes.

ESPECIFICACIN: Documento que describe el funcionamiento y las
caractersticas de un sistema y las restricciones de su desarrollo, a travs
de un catlogo de requisitos y un conjunto de modelos (textuales o
grficos).

MODELO: Esquema de un sistema que representa su estructura y/o
funcionamiento.

Un modelo es una abstraccin o simplificacin de la realidad.

El objetivo de un modelo es comunicar las caractersticas de un sistema
y su comportamiento desde el punto de vista del usuario.

Existen modelos estructurados (Diagramas de Flujo de Datos,
Diagramas de entidad-relacin, etc.) y modelos orientados a objetos
(Diagramas de clases, Diagramas de secuencia, etc.).

4

2.1.2 PRINCIPIOS OPERATIVOS EL ANLISIS

Los siguientes principios han de tenerse en cuenta, segn Pressman (2001) en
todos los mtodos de anlisis de sistemas:
1. Debe representarse y entenderse el DOMINIO DE INFORMACIN

del
sistema.
- Pueden: (a) establecerse requisitos, y (b) crearse modelos;
relacionados con la informacin.
- Existen 3 visiones diferentes de la informacin: (1) Contenido
(significado), (2) Flujos de informacin (entrada/salida,
transformacin de la informacin), (3) Estructura (organizacin).
Los requisitos y modelos pueden estar relacionados con estos
diferentes puntos de vista.
2. Debe representarse y entenderse el DOMINIO FUNCIONAL

(o de
comportamiento) del sistema.
- Pueden: (a) establecerse requisitos, y (b) crearse modelos;
relacionados con la funcionalidad del sistema.
3. Si su complejidad lo aconseja, se deben particionar los dominios
anteriores en partes (subsistemas) que puedan entenderse fcilmente y
que ayuden al entendimiento global del sistema.
- La divisin de los modelos normalmente se hace por niveles con
un enfoque descendente.
NOTA: Tambin pueden utilizarse modelos nicos para definir
conjuntamente los dominios de informacin y funcionamiento. Por ejemplo,
los diagramas de clases en el caso de anlisis orientado a objetos.

5

2.2 INGENIERA DE REQUISITOS

En la actualidad, son muchos los procesos de desarrollo de software que
existen. Con el paso de los aos, la Ingeniera de Software ha introducido y
popularizado una serie de estndares para medir y certificar la calidad, tanto
del sistema a desarrollar, como del proceso de desarrollo en s. Se han
publicado muchos libros y artculos relacionados con este tema, con el
modelado de procesos del negocio y la reingeniera. Un nmero creciente de
herramientas automatizadas han surgido para ayudar a definir y aplicar un
proceso de desarrollo de software efectivo.
Hoy en da la economa global depende ms de sistemas automatizados
que en pocas pasadas. Esto ha llevado a los equipos de desarrollo a
enfrentarse con una nueva dcada de procesos y estndares de calidad.
Sin embargo, cmo explicamos la alta incidencia de fallos en los
proyectos de software? Por qu existen tantos proyectos de software vctimas
de retrasos, presupuestos mal dimensionados y con problemas de calidad?
Cmo podemos tener una produccin o una economa de calidad, cuando
nuestras actividades diarias dependen de la calidad un sistema que no la
tiene?
Tal vez suene ilgico pero, a pesar de los avances que ha dado la
tecnologa, an existen procesos de produccin informales, parciales y en
algunos casos no confiables.
Ante todo esto surge la siguiente pregunta:
Cmo puede asegurarse que se ha especificado un sistema que recoge
realmente las necesidades del usuario y satisface sus expectativas?
No hay una respuesta segura, pero la mejor solucin es llevar a cabo un
proceso de INGENIERA DE REQUISITOS durante el ANLISIS de un sistema.
La Ingeniera de Requerimientos cumple un papel primordial en el
proceso de produccin de software, ya que enfoca un rea fundamental: la
definicin de lo que se desea producir. Su principal tarea consiste en la
generacin de especificaciones correctas que describan con claridad, sin
ambigedades, en forma consistente y compacta, el comportamiento del
sistema. De esta manera, se pretende minimizar los problemas relacionados al
desarrollo de sistemas.
Existe una gran cantidad de proyectos de software que no llegan a
cumplir sus objetivos. El reemplazo de plataformas y tecnologas obsoletas, la
compra de sistemas completamente nuevos, las modificaciones de todos o de
casi todos los programas que forman un sistema, entre otras razones, llevan a
desarrollar proyectos en calendarios sumamente ajustados y en algunos casos
irreales. Esto ocasiona que se omitan muchos pasos importantes en el ciclo de
vida de desarrollo, entre estos, la definicin de los requerimientos.

6

En 1995 se realiz un estudio (informe CHAOS) sobre el resultado
general de los proyectos de software. El estudio fue demoledor a pesar de las
herramientas existentes

La INGENIERA DE REQUISITOS es el procedimiento adecuado para
comprender lo que quiere el usuario:
- analizando necesidades,
- confirmando su viabilidad,
- negociando una solucin razonable,
- especificando la solucin sin ambigedad,
- validando la especificacin,
- y gestionando los requisitos....
para que se transformen en un sistema operacional
(Thayer & Dorfman, Software Requirements Engineering, IEEE Press, 1997)
Algunas definiciones de Ingeniera de requisitos propuestas por diferentes
autores son:

Ingeniera de Requerimientos es la disciplina para desarrollar una
especificacin completa, consistente y no ambigua, la cual servir como
base para acuerdos comunes entre todas las partes involucradas y en
dnde se describen las funciones que realizar el sistema.

"Ingeniera de Requerimientos es el proceso por el cual se transforman los
requerimientos declarados por los clientes, ya sean hablados o escritos, a
especificaciones precisas, no ambiguas, consistentes y completas del
comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y
limitaciones".

"Es el proceso mediante el cual se intercambian diferentes puntos de vista
para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza
una combinacin de mtodos, herramientas y actores, cuyo producto es un
modelo del cual se genera un documento de requerimientos".

"Ingeniera de requerimientos es un enfoque sistmico para recolectar,
organizar y documentar los requerimientos del sistema. Es tambin el
proceso que establece y mantiene acuerdos sobre los cambios de
requerimientos, entre los clientes y el equipo del proyecto".

7

Una posible visin de la ingeniera de requerimientos es considerarla
como un proceso de construccin de una especificacin de requerimientos en
el que se avanza desde especificaciones iniciales, que no poseen las
propiedades idneas, hasta especificaciones finales completas, formales y
acordadas entre todos los participantes.
Segn Sommerville (Requirements Engineering, Wiley, 1997), el proceso de
Ingeniera de Requisitos implica los siguientes pasos (aunque no se trata de
actividades secuenciales, puesto que puede haber iteraciones y solapamientos
entre ellas):
1. IDENTIFICACIN O EXTRACCIN DE REQUISITOS:
Los usuarios descrubren, revelan, articulan y comprenden los requisitos que
desean.
2. ANLISIS Y NEGOCIACIN DE REQUISITOS:
Razonamiento sobre los requisitos anteriores, detectando y resolviendo
inconsistencias o conflictos, coordinando requisitos, etc.
3. ESPECIFICACIN DE REQUISITOS:
Redaccin o registro de los requisitos.
4. VALIDACIN DE REQUISITOS:
Confirmacin, por parte del usuario, de la validez de los requisitos.
5. GESTIN DE REQUISITOS:
Control de altas, bajas, modificaciones y consultas de los requisitos.
2.2.1 IDENTIFICACIN DE REQUISITOS

Identificar requisitos consiste en estudiar un sistema para conocer como
trabaja y donde es necesario efectuar mejoras.
Un requisito es una caracterstica que debe incluirse en el nuevo
sistema. Esta puede ser la inclusin de determinada forma para capturar o
procesar datos, producir informacin, controlar una actividad de la empresa o
brindar soporte a los directivos.
El cumplimiento de dichos requisitos ser una condicin bsica para la
aceptacin final del sistema por parte de los usuarios.
Los analistas de sistemas no trabajan como directivos o empleados de
los departamentos de usuarios, no tiene los mismos conocimientos, hechos y
detalles que los usuarios y directivos de estas reas. Por lo tanto el primer paso
del analista es comprender la situacin.
Los analistas estructuran su investigacin en base preguntas:

Cul es el proceso bsico que se est estudiando?

Qu datos utiliza o produce este proceso?

8

Qu frecuencia y volumen del proceso existe?

Qu controles utiliza para su realizacin?
Alguna de las fuentes ms comunes son:.

Usuarios del sistema

Formularios y documentos

Programas

Manual de procedimiento

Informes
El analista no puede sentarse y dibujar el modelo o definir las
necesidades del usuario desde su despacho. Deben pasar algn tiempo
estudiando el sistema, hablando con los usuarios y obteniendo informacin
sobre como trabajan.
Para ello se debe consultar a todos los usuarios para asegurarse de que
todo problema del sistema, necesidad de usuario y objetivo est identificado
Con la informacin recogida se empezar a elaborar un Catlogo de
Requisitos a satisfacer por el nuevo sistema.
Los requisitos identificados en la realizacin de estas actividades han de ser
definidos de modo que:

Sean cuantificables y medibles.

Sean lo suficientemente detallados para reducir cualquier tipo de
ambigedad y permitir validar si el nuevo sistema satisface las
necesidades de los usuarios.

Se minimice la duplicacin de los diferentes productos obtenidos en
la Fase de Anlisis.
Los requisitos pueden ser:
Requisitos funcionales. Describen lo que debe hacer el sistema en cuanto a:

Funciones de actualizacin de datos.

Funciones de consulta.

Informes proporcionados.

Datos manejados.

Interaccin con otros sistemas.
Requisitos no funcionales. Describen las facilidades que debe proporcionar el
sistema en cuanto a:

Rendimiento. Volumen y tamao de datos.

Frecuencia de tratamiento.

Requisitos de seguridad:
Control de accesos

9

Procedimientos de copias de respaldo y recuperacin
Integridad de la informacin

Requisitos especiales de comunicaciones.

Requisitos organizacionales
Directrices tcnicas y de gestin.
Requisitos generales a cumplir en cuanto a necesidades futuras de
informacin.
Tendencias de evolucin de la empresa.
La primera tarea de la Ingeniera de Requisitos es averiguar y enumerar las
necesidades del usuario, tratando de evitar (segn Christel y Kang, Issuesin
Requirements Elicitation, Software Engineering Institute, 1992) los siguientes
tres tipo de problemas:
- Problemas de alcance (p.ej. no entender las restricciones del sistema)
- Problemas de comprensin (p.ej. no entender el dominio del
problema)
- Problemas de volatilidad (por cambios de opinin del usuario)
Segn Sommerville (1997), durante la identificacin de requisitos se deberan
tener en cuenta las siguientes recomendaciones:
1. Valorar el impacto del sistema en el negocio y su viabilidad tcnica.
2. Identificar a las personas

que ayudarn a especificar requisitos y
contrastar su papel en la organizacin usuaria.
3. Definir el entorno tcnico

(hardware y software de base) sobre el que
funcionar el sistema.
4. Identificar restricciones de dominio

(especficas del negocio en el
dominio de la aplicacin) que limiten la funcionalidad y rendimiento del
sistema.
5. Definir ms de un mtodo de obtencin

de requisitos (p.ej. entrevistas,
reuniones, grupos de trabajo, equipos de discusin, prototipos, etc.)
6. Solicitar la participacin de muchas personas (muchos puntos de vista).
7. Identificar posibles requisitos ambiguos.
8. Elaborar una lista de requisitos iniciales

(agrupados por funcionalidad) y
las restricciones de dominio de cada uno.
TCNICAS DE IDENTIFICACIN DE REQUISITOS:

Observacin: el analista debe estar alerta y observar todo cuanto ocurre a nuestro
alrededor fijndonos en cualquier acontecimiento o actividad que pueda estar
relacionada con el sistema de informacin.

10

Examen de archivos: obtencin de informacin cuantitativa tal como volmenes,
frecuencias, ratios, etc. No se debe obtener informacin exclusivamente del usuario,
sino obtener otra fuente y luego contrastar lo dicho por el usuario. As observamos la
tendencia de las respuestas obtenidas (que exagere los nmeros, r ejemplo) y en caso
de no tener informacin sobre un rea podemos normalizar la respuesta del usuario
segn su tendencia.
Muestreos: son estudios sobre una muestra representativa del total de elementos, en
caso de que sea imposible estudiarlos todos.
Cuestionarios: lo mejor es evitarlos. Son muy difciles de elaborar y de
interpretar.
Entrevistas: es la tcnica principal para la identificacin de requisitos.
Reuniones, JAD, JRP, etc
2.2.2 ANLISIS Y NEGOCIACIN DE REQUISITOS

Una vez identificados (recopilados) los requisitos hay que examinar su
CONSISTENCIA, COMPLETITUD y AMBIGEDAD, y clasificarlos segn las
necesidades de los usuarios, estableciendo PRIORIDADES, y el RIESGO y el
IMPACTO en el coste y plazo del proyecto (estimacin del esfuerzo de
desarrollo), de cada requisito.
ANLISIS DE REQUISITOS

Se pueden utilizar LISTAS O CUESTIONARIOS DE COMPROBACIN que
establecen las propiedades que deben satisfacer cada uno de los requisitos. En
general, hay que comprobar que cada requisito sea:
1. CONSISTENTE: Es consistente con los objetivos del sistema?
2. ABSTRACTO: No tiene un nivel de detalle tcnico excesivo para la fase de
anlisis?
3. NECESARIO: Es necesario o representa una caracterstica aadida que
puede no ser esencial para la finalidad del sistema?
4. NO AMBIGUO: Est delimitado y sin ambigedad?, es decir, No se
presta a distintas interpretaciones?
5. RASTREABLE: Tiene procedencia? Existe un origen conocido? Qu
usuario lo defini?
6. COMPATIBLE: No es incompatible con algn otro requisito?No entra en
conflicto con ningn otro?
7. VIABLE: Es viable tcnicamente?
8. VERIFICABLE: Se puede probar (verificar) una vez implementado en el
sistema?
(Las propiedades 1, 2, 4, 5 y 8 son exigidas por el estndar IEEE std. 830-
1984: Guide to Software Requirements Specifications)

11

NEGOCIACIN DE REQUISITOS

Despus definir requisitos hay que aplicar un procedimiento iterativo de
negociacin ANALISTA-USUARIO para:
- Eliminar requisitos
- Modificar requisitos
- Combinar requisitos.
2.2.3 ESPECIFICACIN DE REQUISITOS

Una vez definidos los requisitos hay que documentarlos textual y/o
grficamente (mediante modelos) de forma que sean entendibles tanto por el
desarrollador como por el cliente .Se pueden utilizar plantillas para ello.
Un ejemplo de plantilla genrica de especificacin de un requisito podra ser la
siguiente:
IDENTIFICADOR Ej. RQ-001
VERSIN Ej. 1.0 (05/11/2001)
AUTOR Ej. Juan Garca
FUENTE Nombre del usuario que lo proporcion
TIPO Funcional, de seguridad, tcnico, de datos, de interfaz, ...
DESCRIPCIN Texto o redaccin del requisito
PRIORIDAD Muy alta, alta, media, baja, ...
COMENTARIOS .......

Pueden definirse plantillas especficas segn el tipo de requisito:
- Una plantilla especfica para requisitos funcionales que incluya un
apartado de lgica o algoritmo o secuencia de pasos del requisitos,
otro apartado de excepciones, otro de frecuencia de realizacin, etc.
- Una plantilla especfica para requisitos de informacin que incluya un
apartado para describir los datos (campos) de la informacin.
Las especificaciones de requisitos del sistema (ERS) son una especificacin
detallada y completa de los requisitos para un producto software en particular,
que debe realizar determinadas funciones en un entorno y dominio especfico.
Debe tener las siguientes caractersticas bsicas:

Incluir informacin real, es decir, que es coherente con las necesidades
del usuario.

Comunicar dicha informacin de forma eficaz.

No incluir requisitos innecesarios.

No describir ningn detalle del diseo, excepto los que supongan una
restriccin.

12

El anlisis es independiente del entorno tecnolgico. Se debe realizar
ignorando dicho entorno, salvo que el hardware restrinja los requisitos.
Los ERS deben ser:

Correctos.

No ambiguos.

Completos.

Consistentes.

Clasificados por su importancia.

Verificables.

Modificables.

Trazables.
Una ERS es correcta si, y solo si, cada requisito definido debe ser satisfecho
por el sistema software. Se trata de determinar si las ERS reflejan
correctamente las necesidades reales.
Una ERS es no ambigua si, y solo si, cada requisito definido en la misma tiene
una sola interpretacin. Como mnimo, ello exige que cada caracterstica del
sistema a desarrollar se describa utilizando un nico trmino.
En los casos en que el trmino usado en un contexto particular pueda tener
mltiples significados, el trmino debe ser incluido en un glosario en donde se
aclare su significado especfico.
Una ERS es completa si, y solo si, incluye los siguientes elementos:

Todos los requisitos significativos, sean relativos a funcionalidad,
rendimiento, restricciones de diseo o interfaces externas.

Definicin de la respuesta del sistema software a todas las clases y tipos
de entradas de datos en cualquier situacin que pueda presentarse. Hay
que tener presente que esto supone que deben especificarse tanto las
respuestas a entradas vlidas como a las que no lo son.

Referencia de todas las figuras, diagramas, tablas, etc.,.. y definicin de
todos los trminos y unidades de medida.
La consistencia se refiere a la conformidad de la ERS con documentos de
ms alto nivel o de algunos apartados de la ERS con otros apartados de la
propia ERS.
Una ERS es verificable si, y solo si, cada uno de los requisitos definidos es
verificable. A su vez, un requisito es verificable si, y solo si, existe algn
procedimiento por el que una persona o mquina pueda comprobar que el
sistema software cumple el requisito.
Si un requisito no es verificable debe ser eliminado o revisado.

13

Una ERS es modificable si, y solo si, su estructura y estilo es tal que
numerosos cambios de los requisitos pueden hacerse fcil, completa y
consistentemente manteniendo la misma estructura y estilo.
Una ERS es trazable si el origen de cada requisito es claro y si facilita la
referencia del mismo para futuros desarrollos o modificaciones. Son
recomendables dos tipos de trazabilidad:

Hacia atrs: Cuando cada requisito referencia explcitamente su fuente u
origen en documentos anteriores.

Hacia delante: Implica que cada requisito tienen un nico nombre o
nmero de referencia.
La estructura que establece IEEE/ANSI para el documento de especificacin
de
requisitos es:
1. Introduccin.
a. Objetivo del documento de requisitos.
b. Alcance del proyecto.
c. Definiciones, acrnimos y abreviaturas.
d. Referencias.
e. Visin general del documento.
2. Descripcin general.
a. Perspectiva del proyecto.
b. Funciones del proyecto.
c. Caractersticas del usuario.
d. Restricciones generales.
e. Asunciones y dependencias.
f. Aplazamiento de requisitos.
3. Requisitos especficos.
a. Interfaces externas (E/S).
b. Funcionalidad.
c. Requisitos de rendimiento.
d. Requisitos de la base de datos.
e. Restricciones de diseo.
f. Caractersticas de calidad y atributos del sistema.
4. Apndices.
5. Glosario
2.2.4 VALIDACIN DE REQUISITOS

Se trata de examinar las especificaciones para asegurar que todos los
requisitos del sistema han sido establecidos sin ambigedades, sin
inconsistencias, sin omisiones; que los errores detectados han sido corregidos
y que la especificacin se ajusta a los estndares establecidos.
Se puede utilizar la misma lista de comprobacin que durante el anlisis de
requisitos:
1. Consistentes

14

2. Abstractos
3. Necesarios
4. No ambiguos
5. Rastreables
6. Compatibles
7. Viables
8. Verificables
2.2.5 GESTIN DE REQUISITOS

La gestin de requisitos consiste en las actividades destinadas a identificar los
requisitos y controlar sus cambios
- Los requisitos se organizan en un CATALOGO DE REQUISITOS de forma
similar a una Base de Datos (Repositorio) con la posibilidad de realizar
ALTAS, BAJAS, MODIFICACIONES Y CONSULTAS sobre el catlogo (por
ejemplo con el lenguaje SQL si se trata de una base de datos). En el caso
de las bsquedas, stas se pueden realizar segn diferentes criterios de
bsqueda: autor, tipo, etc.
-
- Los requisitos se someten a la GESTION DE CONFIGURACIN como el
resto de productos de un proyecto para el control de versiones.
-
- Puede utilizarse una tcnicas llamada MATRIZ DE SEGUIMIENTO para
controlar la vinculacin de los requisitos a diferentes aspectos del sistema o
su entorno. Algunos ejemplos de matrices pueden ser las siguientes:
o Matriz de seguimiento de caractersticas del sistema (Requis-Caracteris.)
o Matriz de seguimiento de orgenes (Requisitos-Personas)
o Matriz de seguimiento de dependencias (Requisitos-Requisitos)
o Matriz de seguimiento de subsistemas (Requisitos-Subsistemas)
o Matriz de seguimiento de interfaces (Requisitos-Interfaces)
En general, suponiendo que X es uno de los aspectos anteriores, la matriz
quedara de la siguiente forma:
X=a X=b X=c X=.....
Requisito 01
Requisito 02
Req. .........

En las casillas se puede indicar simplemente si existe relacin entre el
requisito correspondiente y el aspecto del sistema considerado, o bien se
puede incluir una informacin complementaria.

15

2.3 TCNICAS DE RECOGIDA DE REQUISITOS

2.3.1 TABLAS DE REQUISITOS

Es una tcnica muy sencilla de representacin de los requisitos mediante
una simple tabla.
Un requisito se identifica mediante un cdigo cuya estructura responde a un
estndar fijado por la organizacin.
Junto al cdigo se procede a describir el requisito.
En el resto de la aplicacin permite indicar de una manera muy sencilla que
parte del desarrollo se encarga de satisfacer un requisito concreto.
2.3.2 ENTREVISTAS

Las entrevistas constituyen un medio para obtener la informacin que se
necesita sobre un determinado tema, como puede ser, el establecer el alcance
de un problema, identificar los requisitos a cubrir por un sistema de
informacin y analizar el funcionamiento de un sistema actual, entre otros, a
partir de las personas que tienen conocimiento sobre el mismo.
Se entiende por entrevista el encuentro que se realiza cara a cara entre un
usuario y la persona responsable de obtener la informacin.
Este es el mtodo ms corriente para recoger informacin del usuario.
Si no preparamos las entrevistas y no seguimos una estrategia concreta, la
entrevista puede resultar un desastre.

No sabemos que decir

No queremos que se nos malinterprete

Queremos que se acabe

Queremos que sea un xito
Para realizar la entrevista solo es necesario designar a las personas que
deben participar en ella y determinar el lugar en el que poder llevarla a cabo.
Es importante identificar a qu tipo de perfil va dirigida la entrevista, a quines
se va a entrevistar y cul es el momento ms oportuno, con el fin de evitar
situaciones embarazosas y conseguir que la entrevista sea eficaz y productiva.
Como paso previo a la realizacin de la entrevista se deben tener en cuenta
una serie de un mtodo concreto que se describe a continuacin:
Planificar la entrevista.
Realizar la entrevista.
- Terminar la entrevista y Consolidar el resultado de la entrevista.

16

Es conveniente planificar las entrevistas estudiando la secuencia en
que se van a llevar a cabo, en funcin de los distintos perfiles implicados y las
relaciones existentes entre los entrevistados. Segn la informacin a obtener y
dependiendo de las distintas fuentes que pueden proporcionarla, puede ser
necesario realizar una entrevista conjunta con varias personas. Para ello es
necesario obtener previamente la aprobacin de la empresa
Durante la preparacin de la entrevista es imprescindible remitir al
usuario un guin previo sobre los puntos a tratar, para que pueda estudiarlo
con tiempo y solicitar la informacin que estime conveniente para la entrevista.
Se debe pensar bien el tipo de guin, segn el perfil y las responsabilidades del
entrevistado y su extensin, de forma que se pueda conseguir la suficiente
informacin, sin provocar rechazo en el entrevistado. Si se considera apropiado
se pueden utilizar herramientas automatizadas.
Una vez que se dispone de la aprobacin para hablar con los usuarios,
se hace la convocatoria de la entrevista enviando la informacin oportuna y
fijando los objetivos, el mtodo de trabajo que se va a seguir y el tiempo del
que se dispone.
Los cinco pasos principales en la preparacin de una entrevista son:

Recoger el material histrico: obtener tanta informacin sobre los
entrevistados y su organizacin como sea posible. Con ello obtendremos
el vocabulario que utiliza la organizacin de tal forma que podamos
construir las preguntas de tal manera que el entrevistado pueda
entenderlas.

Establecer los objetivos de la entrevista: Incluye las fuentes de
informacin, los formatos de la informacin, la frecuencia en la toma de
decisiones, la calidad de la informacin y el estilo de la toma de
decisiones

Decidor a quien entrevistar: personas clave en todos los niveles afectados

Preparar la entrevista: se debe preparar a los entrevistados avisndoles
con el suficiente tiempo. Hay que organizar el tiempo de los encuentros.
Las entrevistas no deben durar mas de 45 o 60 minutos

Decidir el tipo de preguntas
Tipo de preguntas

Entrevistas estructuradas

Entrevistas no estructuradas (similar a una conversacin. Mas
tiempo)

Preguntas independientes del contexto
o De quin ha surgido la peticin de este proyecto?
o Quin va a utilizar la solucin?

Preguntas de mbito
o .Qu problemas resolver la solucin?
o Puede describirme el entorno en el que se utilizar la solucin.
o Alguna limitacin o aspecto especial de rendimiento

17

Preguntas de control
o Es Ud.. La persona adecuada para responder a estas
preguntas? Son oficiales sus respuestas?
o Estoy haciendo demasiadas preguntas?
o Hay algo ms que deba preguntarle?

Preguntas generales, no limitadas: Abiertas, sin limites en la respuesta

Ventajas: Usuario cmodo, vocabulario, numerosos detalles, obtener
posibles nuevas preguntas,...

Desventajas: detalles irrelevantes, perder control entrevistas, mucho
tiempo para la informacin generada..

Preguntas especificas: Respuestas concretas

Ventajas: ahorra tiempo, facilidad de comparar entrevistas, control de la
entrevista, obtener datos relevantes

Desventajas: Aburrir al entrevistado, no obtener detalles interesantes,
perder ideas principales

Sondeos: entrevista complementaria (pe por qu? podra darme algn
ejemplo) Sirven para obtener mas informacin
Para realizar la entrevista, es importante hacer un resumen general de
los temas a tratar, utilizar un estilo apropiado y crear desde su inicio un clima
de confianza entre los asistentes. Es posible que el entrevistado se resista a
aportar informacin, siendo til en estos casos utilizar tcnicas especficas de
comunicacin.

La entrevista debe llevarse a cabo en un ambiente apropiado y lo ms
exento posible de interrupciones.

Conviene ser puntual.

Hay que identificarse y explicar el objetivo de la entrevista.

Se establecen los procedimientos de entrevistas (duracin y lo que se
piensa obtener, as como conseguir permiso para tomar apuntes y notas
durante la entrevista).

Normalmente, es una buena idea empezar confirmando la informacin
obtenida en entrevistas anteriores o en alguna investigacin. Esto sirve
para situar al entrevistado y ayuda a encontrar errores en los datos. Una
vez que se est conforme, se sigue con ms detalle cualquier punto
relevante.

Ir de lo general a aspectos ms detallados.

Mantener un estilo apropiado (hacer preguntas segn el nivel del
usuario) La jerga informtica no se debe utilizar para impresionar al
usuario, los entrevistadores deben explicar las limitaciones del
ordenador en trminos cotidianos y describir al usuario cmo le puede
ayudar en su trabajo.

Es importante no imponer soluciones a los usuarios, sino el papel de

18

asesor. Recordar que el usuario es el experto en el tema.

El entrevistador siempre ser corts y respetar la oposicin y
necesidades del usuario
o No atacar al usuario.
o No interrumpir al usuario.

Evitar la tentacin de argumentar, dar consejos o envolver
emocionalmente al entrevistado.

Evitar la resistencia del usuario ( Est amenazando mi puesto de trabajo
o Usted no sabe nada del sistema ).

La discusin se debe enfocar en el anlisis y no en la implementacin.

Tener en cuenta que las manifestaciones de los problemas no son los
problemas.

No dejar puntos de informacin sin aclarar (imprecisin de
requisitos).Los entrevistadores debern asegurarse de obtener toda la
informacin necesaria de la entrevista. Para eso ayuda poner en
conocimiento del usuario la informacin que se pretende obtener con la
entrevista.
Antes de finalizar la entrevista es importante que el entrevistador
sintetice las conclusiones y compruebe que todos los asistentes estn de
acuerdo, dejando siempre abierta la posibilidad de volver a contactar para
aclarar temas que surjan al estudiar la informacin recopilada. Es buena
idea convenir la fecha para la siguiente entrevista, si se considera
necesaria.
Finalmente, el responsable depura y consolida el resultado de las
entrevistas, elaborando un informe de conclusiones. En algunos casos puede
ser conveniente elaborar un acta que refleje estas conclusiones y remitirla a los
entrevistados con el objetivo de asegurar que se han comprendido bien las
especificaciones dadas.
Objetivo de la entrevista

Obtener informacin de un sistema que se desea analizar e informatizar.

Nos permite conocer mejor el mbito del problema

Nos permite conocer mejor el entorno en el que funcionara el sistema

Conocemos en detalle procesos que tendr que realizar el nuevo sistema

Nos aseguramos que todo lo necesario ha sido considerado.

Factores de xito

El xito de la entrevista se base en la experiencia del entrevistador. Se
requiere una habilidad especial cuando los entrevistados no se sienten
cmodos.

Es un proceso continuo utilizado por el analista para construir gradualmente
un modelo del sistema y para obtener conocimientos sobre los problemas del
sistema.

Elegir a la persona a entrevistar. Buscar la persona clave.

19

Encontrar el camino correcto para dirigir la entrevista. Buscar la cooperacin
necesaria.

Se debe tener una idea de lo que se pretende conseguir con la entrevista y
formular preguntas directas para obtener es informacin.

Si el entrevistado no puede contrastar, se el preguntar dnde se podra
obtener dicha informacin.

No se debe esperar obtener toda la informacin necesaria de un usuario en
el curso de una entrevista
Formas de registrar la entrevista

o Grabar la entrevista. Se debe informar al entrevistado
o Ventajas: Grabacin exacta, agilidad, mejor contacto visual..
o Desventajas: Entrevistado nervioso y menos libre de contestar,
entrevistador menos atento, dificultad de localizar partes importantes
en una cinta larga. Incrementa costos
o Tomar notas:
o Ventajas: Mantiene al entrevistador alerta, Ayuda a insistir en lo
importante, dirigir la entrevista por la direccin correcta, inters del
entrevistador
o Desventajas: perdida de contacto visual, perdida de curso de la
conversacin,
2.3.3 REUNIONES

Las reuniones tienen como objetivo obtener informacin que se encuentra
repartida entre varias personas, tomar decisiones estratgicas, tcticas u
operativas, transmitir ideas sobre un determinado tema, analizar nuevas
necesidades de informacin, as como comunicar los resultados obtenidos
como consecuencia de un estudio.
Se pueden ver como una prolongacin de las entrevistas en las que se
involucran varios entrevistadores y varios entrevistados.
Suelen utilizarse en fases muy tempranas de la determinacin de requisitos.
Es una tcnica aplicable en muchas fases del proceso de desarrollo del
software:

.Anlisis del sistema a construir.

.Diseo del sistema a construir.

.Seguimiento del proceso de desarrollo.

Para realizar una reunin es necesario designar a las personas que deben
participar en ella y determinar el lugar en el que poder llevarla a cabo. Las
directrices bsicas de una reunin son:
o Preparar y convocar la reunin (orden del da).
o Realizar la reunin.

20

o Consolidar el resultado de la reunin.
o Elaborar el acta de reunin.
Previamente a la convocatoria de la reunin, se definen los objetivos, se
planifica el mtodo de trabajo que se va a seguir y el tiempo del que se
dispone, se eligen los participantes y se prepara el material necesario.
Despus de la preparacin, es imprescindible enviar al usuario la
convocatoria con el orden del da de la reunin. Este orden incluye la fecha,
hora de inicio, hora de finalizacin prevista, lugar, asistentes y los puntos a
tratar, detallando, entre otros, el tiempo que se dedicar a cada tema y la
persona responsable de exponerlo. Dicha convocatoria se enva con antelacin
suficiente para que los asistentes puedan organizar su agenda y prepararse
para la reunin con tiempo.
Al inicio de la reunin, es importante hacer un resumen general de los
temas a tratar, los objetivos que se persiguen, el mtodo de trabajo y la agenda
de la reunin.
Si se considera oportuno se puede utilizar la tcnica de presentacin.
Desde su inicio se debe crear un clima de confianza entre los asistentes.
La persona responsable de la reunin ejercita la dinmica de direccin de grupos,
estimulando la participacin, controlando el ritmo de la sesin y centrando o
clarificando el tema cuando sea necesario. Al finalizar, se sintetizan las conclusiones,
se comprueba si hay acuerdo o si quedan puntos pendientes de reflexin y se
propone fechas para prximas reuniones.
El responsable de tomar las notas en la reunin, levanta el acta y la remite a
los asistentes que deben confirmar su recepcin.
Estrategias para facilitar las reuniones

Reunin en un lugar neutral para tcnicos y clientes.

Reglas de preparacin y participacin (reunin preparatoria de la reunin).

Agenda formal para cubrir los puntos importantes.

Agenda informal para estimular el brain-storming.

Eleccin de un moderador.
2.3.4 CUESTIONARIOS

Hay personas que sugieren el cuestionario, en vez de las entrevistas, para
obtener informacin sobre el sistema.

El cuestionario contiene todas las preguntas que el usuario debe responder
para proporcionar la informacin que busca el analista.

El cuestionario se enva al usuario y el analista analiza las respuestas.

La experiencia sugiere que estos cuestionarios no son normalmente buenos
sustitutos de las entrevistas por el peligro de ambigedad de las preguntas.
o .'describa todos sus trabajos
o .'cules son los componentes principales del sistema?

Los cuestionarios, sin embargo, se utilizan cuando se busca la misma

21

informacin en usuarios distintos. Es el caso de informacin de naturaleza
cuantitativa.

Un cuestionario con esta pregunta es fcil enviarlo a todos los vendedores
de la organizacin.

Los cuestionarios se utilizan tambin como complemento de otras tcnicas.

Se usan para recoger datos numricos u obtener opiniones relativamente
simples de un nmero de personas.

No son efectivos para bsquedas detalladas ni para identificar problemas o
soluciones del sistema.
2.3.5 SESIONES JAD Y JRP

Las sesiones JAD tienen como objetivo reducir el tiempo de desarrollo
de un sistema manteniendo la calidad del mismo. Para ello se involucra a los
usuarios a lo largo de todo el desarrollo del sistema, es decir, desde la
identificacin de la necesidad, la propuesta de alternativas de solucin y sobre
todo en la especificacin de los requisitos que debe cubrir el sistema y en la
validacin de prototipos.
Las caractersticas de una sesin de trabajo tipo JAD se pueden resumir
en los siguientes puntos:

Se establece un equipo de trabajo cuyos componentes y
responsabilidades estn perfectamente identificados y su fin es
conseguir el consenso entre las necesidades de los usuarios y los
servicios del sistema en produccin.

Se llevan a cabo pocas reuniones, de larga duracin y muy bien
preparadas.

Durante la propia sesin se elaboran los modelos empleando
diagramas fciles de entender y mantener, directamente sobre
herramientas CASE.
Al finalizar la sesin se obtienen un conjunto de modelos que debern
ser aprobados por los participantes.
Es importante definir claramente el perfil y las responsabilidades de los
participantes de una sesin JAD. Se pueden distinguir los siguientes perfiles:
Moderador (lder Jad) con amplios conocimientos de la metodologa de
trabajo, dinmica de grupos, psicologa del comportamiento, as como de los
procesos de la organizacin objeto del estudio.
Promotor, persona que ha impulsado el desarrollo.
Jefe de proyecto, responsable de la implantacin del proyecto.
Especialista en modelizacin, responsable de la elaboracin de los modelos
en el transcurso de la sesin.
Desarrolladores, aseguran que los modelos son correctos y responden a los
requisitos especificados.
Usuarios, responsables de definir los requisitos del sistema y validarlos.

22

La sala en la que se llevarn a cabo este tipo de sesiones juega un papel muy
importante debido a que, en las reuniones largas donde se requiere una alta
concentracin de todos los integrantes del equipo, es necesario prestar
especial atencin a aspectos relacionados con la temperatura, los medios
audiovisuales, la buena visibilidad de los distintos participantes, etc.
Para llevar a cabo una sesin JAD, es necesario realizar una serie de
actividades antes de su inicio, durante el desarrollo y despus de su
finalizacin. Estas actividades se detallan a continuacin:
Inicio: se define el mbito y la estructura del proyecto, los productos a
obtener, se prepara el material necesario para la sesin, se determina el lugar
donde se van a llevar a cabo, se seleccionan los participantes y se sugiere una
agenda de trabajo.
Desarrollo: se identifican las salidas del proyecto y se debe conseguir el
consenso entre los participantes de modo que se materialice en los modelos.
Finalizacin: se valida la informacin de la sesin y se generan los
productos de la metodologa de trabajo propuesta. Si fuera necesario se
integran los productos de salida.
En las sesiones de trabajo tipo JAD se distinguen dos tipos de
productos:
De preparacin donde se incluye, entre otros, la historia y contexto del
proyecto, los objetivos y lmites, las actividades del entorno del negocio que
pueden afectar al xito del proyecto y los beneficios.
De resultado de las sesiones de trabajo, que se establecen con anterioridad al
inicio de las reuniones.
Las sesiones JRP tienen como objetivo potenciar la participacin activa
de la alta direccin como medio para obtener los mejores resultados en el
menor tiempo posible y con una mayor calidad de los productos.
Las caractersticas de las sesiones JRP y JAD son comunes en cuanto a
la dinmica del desarrollo de las sesiones y la obtencin de los modelos con el
soporte de las herramientas adecuadas. La diferencia radica en los productos
de salida y en los perfiles de los participantes.
En JRP son del nivel ms alto en la organizacin en cuanto a visin
global del negocio y capacidad de decisin.
Los perfiles implicados en una sesin JRP son los siguientes:
Moderador (lder JRP), debe tener una gran capacidad de relacin, habilidades
de negociacin y de gestin de dinmica de grupos, as como un alto nivel de

23

conocimiento de los procesos de la organizacin afectados por el Plan de
Sistemas de Informacin (PSI).
Promotor, persona que ha impulsado el Plan de Sistemas de Informacin y
tiene un compromiso econmico.
Director de proyecto, responsable de que el proyecto llegue a buen fin.
Consultores, responsable de traducir los requisitos especificados por el
usuario en informacin estructurada, de tal forma, que los usuarios puedan
entender y discutir los resultados.
Especialista en modelizacin, responsable de la elaboracin de los modelos
en el transcurso de la sesin.
Usuarios de alto nivel, responsables de definir los procesos de la
organizacin y los sistemas de informacin afectados por el Plan de Sistemas
de Informacin as como las prioridades para su implantacin a largo o medio
plazo en la organizacin.
La sala de reuniones juega un papel muy importante, siendo necesario
acondicionarla con el fin de facilitar el desarrollo de la sesin. Se debe prestar
especial atencin a aspectos como la temperatura, la luz, su orientacin, la
distribucin de los participantes en la sala, etc. Hay que asegurar que se
cuenta con los medios audiovisuales adecuados como pueden ser cmara de
vdeo y apuntadores lser, entre otros.
Para llevar a cabo una sesin JRP, es necesario realizar una serie de
actividades:
Iniciacin, se establece la necesidad del Plan de Sistemas de Informacin
(PSI), su alcance, los procesos de negocio implicados, las unidades
organizativas afectadas, as como los usuarios clave y los perfiles del equipo
JRP.
Bsqueda, se identifican los objetivos del Plan de Sistemas de Informacin, se
estudia la situacin actual y se busca la informacin relevante, que pueda ser
til.
Preparacin, se seleccionan los participantes, se prepara el material
necesario, acondicionando tambin la sala, y se establece la agenda de JRP.
Realizacin: se introduce la reunin y se empieza a trabajar en la consecucin
de los objetivos marcados en la agenda, elaborando los productos objeto de la
sesin
.
Finalizacin: se completan los productos y se presenta a los participantes que
corresponda.

24

La informacin de salida que se obtiene al finalizar una sesin JRP,
depender de la actividad del Plan de Sistemas de Informacin que se est
realizando, como por ejemplo:

Modelos de procesos de la organizacin.

Modelo de informacin.

Modelo de sistemas de informacin, etc.
2.3.6 PROTOTIPOS

El prototipado tiene como objetivo elaborar un modelo o maqueta de las
interfaces entre el sistema y el usuario (formatos de pantallas, informes,
formularios, etc.), que ayude al usuario a comprender cmo se producir la
interaccin con el sistema.
Es importante que el usuario colabore en su desarrollo sugiriendo los
cambios que considere oportunos y evale hasta que punto las funciones se
implementan de forma apropiada y cubren los requisitos identificados.
El prototipado constituye un medio a travs del cual se simula el aspecto
visual del sistema mediante la representacin de los conceptos, componentes,
objetos grficos, entradas y salidas requeridas para la ejecucin de cada
funcin en respuesta a las necesidades planteadas.
Con objeto de conseguir una interfaz eficiente y compatible con las
necesidades de los usuarios evitando as futuras frustraciones, es importante
contemplar, previamente, una serie de aspectos que son claves en el diseo de
prototipos.
El principal punto a considerar y que constituir la base sobre la que se
centrar el diseo de prototipos es la identificacin de los usuarios a los que va
dirigido, teniendo en cuenta que debe responder a diferentes individualidades,
con distintos conocimientos y habilidades. Cuando los usuarios se sienten a
gusto con la imagen del sistema, lo utilizan ms eficazmente y cometen menos
errores, mejorando su productividad.
Despus de estudiar los perfiles de usuarios se deben analizar las
funciones que va a soportar el sistema, con el fin de establecer las
dependencias existentes entre ellas y su secuencia de ejecucin. Adems, se
debe determinar el tipo de informacin que requerir el usuario para llevar a
cabo cada funcin, as como el estilo de interaccin ms eficaz.
Una vez considerados los dos elementos claves para el diseo de la
interfaz, es decir, quines son los usuarios y qu funciones tienen asignadas, la
forma en que se establezca la comunicacin entre el usuario y el sistema ser
decisiva para conseguir su aceptacin.

25

2.4 TCNICAS DE ANLISIS ESTRUCTURADO

Clasificacin (Yourdon):

Segn la forma de representacin:

Tcnicas grficas: Iconos, etc..Son las preferidas cuando se trata de
mostrar la conexin entre los diferentes componentes del sistema. Se
suelen utilizar en combinacin con otras.

Tcnicas textuales: Se utilizan para especificar con detalle los
componentes definidos en las tcnicas graficas haciendo uso de una
gramtica mas o menos formal o pseudocdigo (procesos).

Marcos o plantillas: Informacin relativa a un componente. Formulario
con campos.

Matriciales: No se consideran por si solas tcnicas de especificacin,
sino de comprobacin entre modelos (exactitud y completitud).

Segn el enfoque de modelacin bajo el que se crean los modelos en
base a su funcin, informacin y tiempo:

Dimensin de funcin:Muestran funciones del sistema y sus interfaces.
(Ej: DFD, DD,..)

Dimensin de la informacin: (Ej: D. Entidad-Relacin.)

Dimensin del tiempo: (Ej: Lista de eventos)

Mas importancia a una u otra dimensin dependiendo de lo que se
trata de modelar (bbdd. Sistema de tiempo real...)

Algunas tcnicas (informacin)

Diagramas E-R: Tcnica grafica para representar objetos (entidades) y
las relaciones entre ellos que forman parte de la estructura del sistema.
Modelacin de los datos del sistema.

Diagramas de estructura de datos: Utilizados en conjuncin con los DER
representan informacin del sistema a un nivel mas elevado que los DER.
Representacin de las relaciones 1-N entre objetos.

Matriz entidad / entidad: Se utilizan cuando el numero de entidades es
elevado. Matriz que aporta informacin de las relaciones existentes entre
las entidades.

Algunas tcnicas (Funcin)

DFD: Representa como la informacin se va moviendo por el sistema y
siendo sometida a trasformaciones. Especifica funcionalidades del
sistema. Se apoya del Diccionario de Datos y en las especificaciones de
procesos mediante rboles de decisin, tablas de decisin, diagramas de
accin y lenguajes estructurados.

Diagramas de descomposicin funcional: Tratan de mostrar la jerarqua

26

de procesos del sistemas a diferentes niveles de abstraccin en un
proceso de descomposicin de funciones globales hasta procedimientos
elementales.

Matriz Funcin / Entidad: Muestra la relacin existente entre las funciones
y la informacin que es sometida al procesamiento en las mismas.

Diccionario de Datos: Lista Organizada de datos utilizados por el sistema
y representados en los DFD

Algunas tcnicas (tiempo):

Lista de eventos: Relacin de eventos (cosas que ocurren y que producen
un cambio de datos)

Diagramas de transicin de estados: Representacin del comportamiento
de un sistema en tiempo real

Redes de petri: Los DTE pueden considerarse un subtipo de RP. Se
representan las transformaciones a las que estn sometidos los datos en
el tiempo.

Diagramas de Historia de la Vida de las entidades: Muestran el ciclo del
proceso de una entidad, desde su creacin hasta su desaparicin.

Matriz Entidad / Evento: Tcnica tabular que proporciona informacin
sobre las entidades que son afectadas por cada uno de los eventos
descritos.
2.4.1 TCNICAS DE ANLISIS Y MODELADO DE FUNCIONES

2.4.1.1 DIAGRAMA DE FLUJO DE DATOS
Es la tcnica mas difundida.
Aparece por la necesidad de los analistas de una tcnica que les ayude a
modelar funciones que debe realizar el sistema y los datos que fluyen entre
ellas
Un DFD es una representacin en forma de red que refleja el flujo de
informacin y las transformaciones que se aplican sobre ella al moverse desde
la entrada hasta la salida del sistema.
OBJETIVOS

Construir un modelo lgico del sistema que facilite la comprensin del mismo,
tanto por parte de los usuarios como del equipo de desarrollo.
ESTABLECER QU FUNCIONEN SE DEBEN DESARROLLAR, SIN
IMPLICAR CMO
Para ello se dividir el sistema en distintos niveles de detalle. Esta divisin
permitir:

Simplificar la complejidad del sistema, representando los diferentes
procesos sencillos de que consta un sistema complejo.

Repartir el trabajo entre los diferentes miembros del equipo de desarrollo.

27

Facilitar el mantenimiento del sistema.
Los fundamentos de la tcnica del Diagrama de Flujo de Datos (DFD) son los
siguientes:

Representar grficamente los lmites del sistema en estudio.

Mostrar el movimiento de los datos y la transformacin de los mismos a
travs del sistema.

Diferenciar las restricciones fsicas de las lgicas.
Para conseguir estos objetivos el resultado del anlisis debe ser:

Grafico.

Lgico, nunca referido a entornos fsicos.

Preciso y breve.

Comprensible.

Debidamente particionado.

Bien documentado.

Nunca redundante.

Establecer "que" funciones se deben desarrollar, sin implicar "como".

No ambiguo.
Como resultado se obtendr un modelo del sistema completamente
independiente de las restricciones fsicas del entorno, lo que facilitar su
mantenimiento y portabilidad. En los Diagramas de Flujo de Datos, no se
debern modelizar:

Procedimientos.

Punto de inicio y de terminacin del DFD.

Condiciones.

Tratamientos de errores poco relevantes.
ELEMENTOS BSICOS DE LOS DIAGRAMAS DE FLUJO DE DATOS

En cualquier Diagrama de Flujos de Datos, aparecern los objetos siguientes:

Entidad externa.

Proceso.

Almacn de datos.

Flujo de datos.
Algunos de ellos podrn tener alguna restriccin con respecto nicamente al
nivel en el cual pueden o deben aparecer. Esto ya se detallar ms adelante.
La tcnica de representacin dar lugar a un DFD (Diagrama de Flujo de
Datos) en el que se irn detallando los principales procesos o acciones a
desarrollar y que se irn detallando en mayor medida segn se vaya bajando
de nivel (EXPLOSIONANDO) cada uno de esos procesos. La comunicacin
existente entre esas actividades se representa entre el resto de los elementos.

28

Diagrama De Flujo De Datos
El diagrama de flujo de datos (DFD) proporciona una representacin del
sistema a nivel lgico y conceptual. Utiliza una notacin y unas reglas
predeterminadas. La Figura siguiente nos muestra un posible DFD para una
biblioteca.
Entidad Externa
Las Entidades Externas representan entes ajenos a nuestra aplicacin, pero
que aportan o reciben informacin de la misma. Se representa mediante una
elipse o un rectngulo con un nombre significativo dentro.
Reglas de construccin:
1. Representa personas, organizaciones o sistemas que no pertenecen al
sistema.
2. En el caso de que las entidades externas se comunicasen entre s,
esto no se contemplara en el diagrama, por estar fuera del mbito de
nuestro sistema.
3. Puede aparecer en los distintos niveles de DFD.
4. Puede aparecer varias veces en un mismo diagrama, para evitar
entrecruzamientos de lneas.
5. Suministra informacin acerca de la conexin del sistema con el
mundo exterior.

29

Proceso
Es una actividad que transforma o manipula datos. Se representa mediante un
rectngulo, de la siguiente manera:

En la parte de PROCESO se expresa el nombre del proceso correspondiente.
Dependiendo del nivel de detalle en que nos encontremos dentro de un DFD, el
nombre del proceso simbolizar bien el sistema concreto (nivel sistema), bien
el subsistema de que se trate (nivel subsistema), o bien acciones concretas y
detalladas en niveles inferiores.
En la parte superior izquierda se coloca un nmero identificativo del proceso.
Este nmero permitir adems indicar el nivel del DFD en que nos
encontramos; esto se explicar ms en detalle cuando se hable de la
descomposicin por niveles. Es importante hacer nfasis en que este nmero
no indica secuencia de realizacin del proceso, dado que los DFD no
representan una secuencialidad en el tratamiento de los datos.
La parte de localizacin expresa la Unidad o rea dentro de la organizacin
donde se realiza este proceso.
1. Cuando un Flujo de datos entra en un proceso sufre una transformacin.
Un proceso no es ni origen ni final de los datos, slo lugar de
transformacin de los mismos. Por ello, cualquier flujo de datos que
entre en un proceso ha de transformarse (ver Figura DFD3).

Regla de conservacin: Cuando a un proceso no llegan los datos
necesarios para obtener una salida -> Error de conservacin

Cuando un flujo de datos muere en un proceso -> perdida de
informacin
2. Un proceso puede transformar un dato en varios.
3. Es necesario un proceso como intermediario entre una Entidad Externa
y un Almacn de Datos.

30

Almacn De Datos
Un almacn de datos representa un depsito de informacin dentro del
sistema. Se representa dentro del DFD con la siguiente Figura:

En la parte derecha se indica el nombre del almacn de datos. En la parte
izquierda se representa la identificacin de dicho almacn dentro del DFD.
En el captulo 1.6 se dan una serie de recomendaciones de codificacin y
construccin de los almacenes de datos.
En el caso de que dentro de un DFD aparezca repetido el mismo almacn de
datos, se puede representar de la siguiente forma:

31

Es conveniente distinguir las diferentes utilidades que presentan los almacenes
de datos. En primer lugar, el almacenamiento permanente de datos, donde se
guardan los datos que sirven de referencia de uso del sistema, es decir, los
datos permanentes, sobre los que el sistema necesita guardar informacin
(ALMACENES PRINCIPALES).
Por otra parte, el almacenamiento transitorio de los datos antes de ser usados
por un proceso. Para entender el significado de estos almacenes transitorios,
se puede imaginar la situacin del ejemplo de la Figura DFD5.
En este ejemplo el proceso RECOGER SOLICITUDES, que se ejecuta
continuamente a lo largo de la jornada, genera los datos de salida
representados por el flujo de datos SOLICITUDES. Estos datos constituyen los
datos de entrada al proceso VALIDAR SOLICITUD, que se ejecuta al final de la
jornada, en el intervalo esos datos de solicitud "reposaran" en el almacn
SOLIC-PROV, cuya utilidad bsica es establecer una sincronizacin en el
funcionamiento de ambos procesos.

Los almacenes transitorios suelen representar restricciones fsicas del sistema
y por tanto en un DFD, que expresa la lgica de los tratamientos realizados por
el sistema, en muchos casos no ser necesario representarlos. Sin embargo
hay ocasiones en que estos almacenes simbolizan "ficheros de movimientos",
donde se guardan los datos porque el proceso siguiente necesita manejarlos
todos al mismo tiempo (por ejemplo, en un proceso que compara un conjunto
de registros, ser necesario mantenerlos guardados en un almacn transitorio,
para que dicho proceso los lea todos al mismo tiempo). En este caso s ser
conveniente representarlos.
Por ltimo, para asegurar la consistencia entre todas las tcnicas utilizadas en
la Fase de Anlisis, se establecer una relacin precisa entre los almacenes de
datos "principales" de un DFD y las entidades de los Diagramas de Estructura
de Datos (DED): cada almacn principal de un DFD representa un conjunto
completo de entidades del DED (una o varias entidades), y cada entidad de un

32

DED pertenece a un nico almacn principal de un DFD; esto facilitar las
validaciones cruzadas entre los dos diagramas.
1. Representa la informacin en reposo.
2. No puede crear, destruir ni transformar datos.
3. No puede estar comunicado directamente con otro Almacn o Entidad
Externa.
4. El flujo de datos (Entrada o Salida) no lleva nombre cuando incide sobre
su contenido completo.
5. El almacn de datos aparecer por vez primera en aquel nivel en que
sea accedido por dos o ms procesos y en modo lectura y/o escritura.
6. No debe estar referido al entorno fsico y por tanto, no se diferencian los
ficheros convencionales de las Bases de Datos.
7. No se representa la clave de acceso a ese almacn sino slo la
operacin que se realiza (lectura, escritura, actualizacin)
Flujo De Datos
Los Flujos de Datos establecen la comunicacin entre procesos, almacenes y
entidades externas, y llevan informacin necesaria para esos objetos.
1. El concepto de flujo de datos es similar al de una "tubera" a travs de la
cual fluye una informacin de estructura conocida.
1. Los datos no pueden ser creados ni destruidos por un flujo de datos.
2. Sirve para conectar el resto de los componentes del DFD.
3. No es un activador de procesos.
4. Cuando un proceso almacena datos, la flecha de flujo de datos se indica
en la direccin del almacn de datos y a la inversa si es el proceso el
que lee datos en el almacn.
Tipos de flujos:

Consulta: Utilizacin de la informacin del almacn.

Actualizacin: Alterar la informacin contenida en el almacn.
o Crear, borrar, modificar

Dialogo: Mnimo flujo de consulta y un flujo de actualizacin que no
tienen relacin directa

33

PRINCIPIOS FUNDAMENTALES DE LOS DIAGRAMAS DE FLUJO DE
DATOS

Descomposicin o Explosin Por Niveles:
Los Diagramas de Flujo de Datos han de representar el Sistema de la forma
ms clara posible, por ello se basarn en el principio de descomposicin o
explosin en distintos niveles de detalle.
La descomposicin por niveles permite analizar el sistema desde el mbito
general al detalle, pasando por sucesivos niveles intermedios (filosofa de
arriba a abajo o "top-down").
La utilizacin de esta tcnica implica la descomposicin o explosin de cada
proceso en otro DFD. El sistema deber contener:

34

Un diagrama de contexto (primer nivel).

Varios DFD en niveles intermedios.

Varios DFD en el ltimo nivel de detalle.
En la Figura siguiente se representan los distintos niveles que pueden surgir a
la hora de desarrollar nuestro sistema de informacin.
En cualquier momento puede aparecer un proceso que no necesite
descomponerse y es lo que se llama PROCESO PRIMITIVO (PP). En ellos,
slo se detallar la entrada y salida que tenga, adems de la descripcin
asociada que explique lo que realiza.

Un proceso puede dejar de explosionarse (proceso primitivo) cuando:
o Se puede especificar su funcionamiento en menos de una pagina
mediante tcnicas de especificacin de procesos
o Tenga pocos flujos de entrada y salida
Es conveniente que en un mismo nivel no aparezcan procesos primitivos junto
con otros que deban explosionarse
Conviene marcar los procesos primitivos mediante un * en la parte inferior
derecha.
El procedimiento a seguir para la representacin del sistema en diferentes
niveles de detalle se indica a continuacin:
1. Representar el Diagrama de Contexto.
2. Representar el DFD de primer nivel, indicando los distintos
subsistemas o reas funcionales en que se descompone nuestro
sistema.
3. Descomponer cada uno de los procesos que aparecen en el DFD de
primer nivel, hasta llegar a un nivel suficiente de detalle.

35

4. Si es necesario, reagrupar y reorganizar los distintos subsistemas que
se han identificado inicialmente, Esto implicar reasignar procesos a
otras reas funcionales, o incluso crear nuevas reas funcionales, es
decir, subir de nivel para redefinir las reas funcionales o subsistemas.
5. Repetir el proceso de descomposicin hasta llegar a un nivel suficiente
de detalle.
La identificacin de las reas funcionales o subsistemas se har atendiendo,
entre otros, a los siguientes criterios:

Funciones organizativas o administrativas propias del sistema a desarrollar
y especficas de la problemtica de la Unidad.

Homogeneidad de las funciones realizadas por los procesos
pertenecientes a un rea funcional o subsistema.

Localizacin geogrfica de los procesos.

Procesos que actualicen los mismos almacenes de datos se colocarn en
el mismo subsistema o rea funcional.
Durante las sucesivas descomposiciones se debe de cumplir la regla del
balanceo: Todos los flujos que entran o salen de un proceso deben ser
mantenidos en la explosin de ese proceso en un nivel inferior
El objetivo ltimo ser conseguir que las comunicaciones o enlaces entre
distintos subsistemas o reas funcionales sean lo ms reducidas y
homogneas posibles.
Con el fin de asegurar la consistencia con otras tcnicas utilizadas en la Fase
de Anlisis, se recomienda llegar hasta cuatro niveles de descomposicin en
los Diagramas de Flujo de Datos:
1. Nivel 0: Diagrama de contexto.
2. Nivel 1: Subsistemas.
3. Nivel 2: Funciones de cada subsistema.
4. Nivel 3: Subfunciones asociadas a cada uno de los eventos del
sistema.
5. Nivel 4: Procesos necesarios para el tratamiento de cada
subfuncin.
Las ventajas de esta descomposicin son las siguientes:

Es comprensible para usuarios no informticos.

Los procesos en el ltimo nivel estn relacionados lgicamente.

Los procesos en el nivel 3, de eventos, estn separados en el tiempo.

Facilita las referencias cruzadas con otros productos obtenidos en la
metodologa, concretamente con el Catlogo de Eventos obtenido en la
Tarea EFS 3.1 ("Construccin del Modelo entidad-evento")
.
Diagrama De Contexto
El objetivo es realizar una declaracin formal del dominio.

36

Un slo proceso representar el rea que se est estudiando.
El contexto queda definido por los flujos de entrada y salida y las entidades
externas.
Las entidades externas han de aparecer en este nivel y no en ningn otro
(salvo para mejorar la comprensin del resto de los DFD).
El primer DFD que va a aparecer es el que se va a llamar DIAGRAMA DE
CONTEXTO y es precisamente el grfico que va a proporcionar el mbito del
proyecto objeto de estudio. En l aparecer todo aquello que necesite o enve
datos del o hacia el sistema a desarrollar. Estos se representan por unos
objetos que se llaman Entidades Externas.
El diagrama de contexto tendr la forma siguiente:

El proceso representa el SI que se va a desarrollar.
TECNICAS PARA MEJORAR Y PROBAR LOS DIAGRAMAS DE FLUJO DE
DATOS.

A continuacin se detallan una serie de pruebas para comprobar la validez de
los diagramas:
. PRUEBAS DE CORRECCION
. PRUEBAS DE UTILIDAD (COMPRENSION).
. PRUEBAS DE COHESION.
Pruebas De Correccin
En la descomposicin de un proceso puede que se nos olvide alguno de los
Flujos de Datos (FD) del nivel superior, o que el FD de ese nivel superior se
descomponga pero se incluya algn flujo que no debera aparecer o nos falte
alguno.

Faltan flujos de datos requeridos por un proceso.

Flujos de datos de ningn valor para el proceso.

Faltan procesos.

Incoherencia entre niveles.

37

En los grficos siguientes se trata de dar una idea de qu es el cuadre entre
niveles sucesivos.
Ejemplo 1
Ver si es correcto el "Cuadre" de los Diagramas de Flujos de Datos siguientes:
Como resultado de la inspeccin visual, se detecta que en el proceso 3 del
DFD de nivel superior entran los flujos de datos M y N y sale el flujo de datos T.
Sin embargo, en el DFD resultado de la descomposicin del proceso 3,
representado en la parte inferior de la Figura, el flujo de datos de entrada es N
y los flujos de datos de salida son T y S.
Esto indica una inconsistencia entre ambos niveles de detalle.
Hay que tener en cuenta que los flujos de datos son, como se ha definido,
"tuberas" que contienen un conjunto de datos, los cuales estn descritos en
detalle en el diccionario de datos del proyecto. Por esto puede ocurrir que
aunque el nmero de flujos de datos netos de entrada y salida no coincida de
un nivel a otro, el contenido de dichos flujos s lo haga, al ser distinta su
denominacin en los distintos niveles, por ello ser necesario, para comprobar
la consistencia entre los distintos niveles, examinar el diccionario de datos del
proyecto.

38

Pruebas de utilidad
Estas pruebas son ms de sentido comn que de un estudio exhaustivo sobre
los DFD.

Comprobar si el diagrama es legible.

Analizar la complejidad de la interfase.

Comprobar que los nombres asignados ayudan a comprender sin
ambigedad el DFD.
Pruebas de cohesion
Si un proceso explosiona, el DFD al que da lugar ha de tener todos sus
elementos conectados. Si no, habr que redibujar el proceso del DFD padre.

Siempre que un diagrama de nivel inferior conste de elementos
desconectados se tendr que modificar el DFD "padre" y el DFD "hijo".

Comprobar la ausencia de redundancias.

Comprobar que no faltan procesos y que stos son totalmente coherentes.
Ejemplo 2
En este DFD, el proceso 2 vemos que da lugar por descomposicin a dos
grafos no conectados. Dar una solucin, sobre el diagrama correspondiente.

El DFD explosin del proceso 2 es:

39

Solucion:
Descomponer en el nivel superior el proceso 2 en los procesos 2' y 2''.

2.4.1.2. TECNICAS DE ESPECIFICACION DE PROCESOS.
Las especificaciones de procesos deben realizarse fundamentalmente para los
procesos de ultimo nivel, tambin llamados primitivos, pues en los de nivel
superior su descripcin se corresponde con el diagrama en el cual se
explosionan. Esta especificacin ha de hacerse de forma que:
- Pueda ser verificada tanto por el analista como por el usuario
(deseable).
- Debe hacerse de forma que sirva de elemento de comunicacin entre
el analista y el programador.
-
Para realizarla podemos emplear lenguajes estructurado, tablas de decisin,
pre y post condiciones, diagramas de flujos, etc.
Debern definirse en ms detalle slo las funciones o procesos primitivos, es
decir, aquellos que no se han descompuesto ms.

40

No se detallarn funciones que resulten obvias.
Cada especificacin de proceso debe describir cmo se logra transformar el
flujo de datos que llega en los flujos que salen.
Cada especificacin de proceso debe describir las normas que gobiernan la
transformacin, no el mtodo de implantar esas normas.
En todo caso, y como se indica en la gua de referencia de la Metodologa, se
han de incluir en la descripcin de los procesos de ltimo nivel los siguientes
aspectos:
1. Modo de acceso de los procesos a las entidades de datos del sistema.
2. Tipo de tratamiento (interactivo o por lotes).
3. Informacin sobre la frecuencia de ejecucin.
4. Caractersticas del proceso:

Actualizacin de datos del sistema.

Consultas e informes.

Realizacin de algoritmos especficos y descripcin de los mismos.
A la hora de describir los procesos de ltimo nivel de un DFD, se pueden
utilizar las siguientes tcnicas:

Narrativa tradicional.

Lenguaje estructurado.

Pre-Post condiciones

Tablas de decisin.

rboles de decisin.
A continuacin, se describen brevemente alguna de estas tcnicas.
Narrativa Tradicional
Tiene la debilidad inherente del lenguaje natural como herramienta para
especificar:

Imprecisa.

Redundante.

Llena de implicaciones y connotaciones.
Ejemplo:
"Para aplicar el descuento, el cliente debe tener una cifra de compra de ms de
3.000.000 de pesetas/ao y un buen historial de pagos o haber sido cliente
ms de 5 aos".
Cul es el significado de la anterior descripcin narrativa?

. 3.000.000 Pts. y un buen historial?

. 3.000.000 Pts y 5 aos?

. Basta con los 5 aos?

. Qu quiere decir un buen historial de pagos?

41

Lenguaje Estructurado
El lenguaje estructurado es lenguaje Espaol con algunas restricciones
sobre el tipo de frases que pueden usarse y la manera en que se juntan estas
frases. Algunas reglas a tener en cuenta son:

Puede utilizarse ecuaciones algebraicas del tipo A = A + B / 10

Son vlidos y deseables verbos orientados a acciones tales
como; aceptar, leer, mostrar, buscar, etc.

Los objetos que empleemos deben consistir solo en datos
definidos en el diccionario de datos o bien en trminos locales.

Es habitual utilizar algunas estructuras del tipo:

SI ... ENTONCES

CASO ...

HACER MIENTRAS ...

Debe ser comprensible para el informtico y el usuario.

Utiliza una sintaxis limitada sin llegar a ser tan rgida como una
codificacin.

Las descripciones deben ser precisas y concisas, evitando la
retrica del lenguaje.

Utilizar verbos precisos sin ambigedad, evitando, por ejemplo:
HACER, TRATAR, PROCESAR, CONTROLAR.

Los nombres utilizados deben estar definidos en el diccionario de
datos.

Los adjetivos utilizados deben ser auto-explicativos. Por ejemplo:
VALIDO, ERRONEO.

No deben utilizarse los adjetivos, adverbios y verbos que
expresan relatividad. Por ejemplo: Incrementar, reducir, escaso,
suficiente, etc.

Hay que indicar de forma inequvoca el objeto sobre el que debe
aplicarse la accin.
Sintaxis Del Lenguaje Estructurado

Sentencias declarativas simples.

Construcciones de decisin.

Construcciones de repeticin.

Combinaciones de ambas.
Las acciones escritas de esta forma son fciles de leer y de entender. Algunos
ejemplos de Lenguaje Estructurado se detallan a continuacin:
Secuencia:
ACCION 1
ACCION 2

42

ACCION 3
ACCION 4
ACCION 5
Decisin Mtodo De Los Casos
SI (CONDICION), PARA CADA TRANSACCION
ENTONCES SELECCIONAR:
ACCION 1 CASO 1: ACCION 1
CASO CONTRARIO,
Consejos Prcticos Para Utilizar El Lenguaje Estructurado:
La excesiva anidacin de sentencias condicionales (si/no) complica la
comprensin de las especificaciones.
Utilizar el mtodo de los casos cuando la lgica del proceso sea compleja, por
existir diversidad de opciones.
Evitar sentencias del tipo "HACER HASTA" o "HACER MIENTRAS".
Emplear expresiones positivas, evitando sentencias del tipo: "Si la transaccin
no es errnea..."
Evitar expresiones matemticas complejas.
Pre/Post Condiciones
Las pre/post condiciones son una manera de describir la funcin que
debe realizar el proceso, sin especificar mucho sobre el algoritmo que se
utilizar. Es til hacerlo:
- Cuando el usuario intenta expresarnos su poltica en terminos del
algoritmo que ya se esta utilizando o incluso es muy anticuado.
Las precondiciones describen todas las cosas que deben darse antes de
que el proceso pueda comenzar a ejecutarse. Tpicamente son:
a) Que entradas se encuentran disponibles
b) Que relacin debe existir entre las entradas
c) Que relacin debe existir entre las entradas y los
almacenamientos de datos.
d) Que relacin debe existir entre diferentes almacenamientos o
dentro de un almacenamiento
Las postcondiciones describen lo que debe darse cuando el proceso
halla finalizado, normalmente describen:
a) Las salidas que producir o generar el proceso
b) Las relaciones que existen entre los valores de salida y los
valores de entrada

43

c) Las relaciones que existen entre los valores de salida y los
valores en uno o varios almacenamientos.
d) Los posibles cambios que se hallan producido en los
almacenamientos
Tablas de decisin
Hay situaciones en las que ni el lenguaje estructurado ni las pre/post
condiciones son un buen mtodo para realizar las especificaciones de proceso,
esto se debe a que la decisin sobre la accin a realizar es compleja, pues se
basa en distintas variables que pueden tomar diversos valores. Por ejemplo:
1 2 3 4 5 6 7 8
Edad > 30 aos S S S S N N N N
Sexo M M F F M M F F
Peso > 80 Kg S N S N S N S N
Medicamento A dosis 500mg X X X
Medicamento A dosis 700mg X X X
Medicamento A dosis 900mg X X

Los pasos para crear una tabla de decisin son:
1- Identificar todas las condiciones o variables de la especificacin
identificando as mismo los valores que pueden tomar cada una de
esas variables.
2- Calcular el nmero de combinaciones de las condiciones. Si todos
son binarios entonces hay 2
n
combinaciones.
3- Identificar cada accin posible.
4- Construir la tabla de decisin listando todas las condiciones y
acciones en la parte izquierda y numerando todas las combinaciones
en la parte superior derecha.
5- Escribir todas las combinaciones de las condiciones, una por cada
columna.
6- Adjudicar a cada combinacin la accin a realizar.
7- Examinar las omisiones, contradicciones, ambigedades,...
Arboles de decisin
Sirven para organizar la informacin recopilada con respecto a la toma de
decisiones y no haya malas interpretaciones.
Caractersticas:
o La raz del rbol es donde comienza la secuencia de decisin, la
rama a seguir depende de las condiciones y de la decisin que
debe tomarse. La parte final es la accin.
o El problema de los rboles de decisin es el gran nmero de
ramas que puede tener un sistema complejo.

44

2.4.1.3 DIAGRAMA DE DESCOMPOSICIN FUNCIONAL
El objetivo del diagrama de descomposicin es representar la estructura
jerrquica de un dominio concreto.
La tcnica es una estructura por niveles que se lee de arriba abajo y de
izquierda a derecha, donde cada elemento se puede descomponer en otros de
nivel inferior y puede ser descrito con el fin de aclarar su contenido.
El diagrama de descomposicin, tambin conocido como diagrama jerrquico,
tomar distintos nombres en funcin del dominio al que se aplique. En el caso
de MTRICA Versin 3, se utilizan los diagramas de descomposicin funcional,
de descomposicin organizativo y de descomposicin en dilogos.
Los elementos del dominio que se est tratando se representan mediante un
rectngulo, que contiene un nombre que lo identifica. Las relaciones de unos
elementos con otros se representan mediante lneas que los conectan.
pendiente
asociado
de grado
senior
primero
segundo
tercero
primero
segundo
tercero
primero
segundo
tercero
primero
segundo
tercero
3
4
6
2
3
4
5
6
7
3
4
5
tipo


45

2.4.1.4 DICCIONARIO DE DATOS
Un diccionario de datos, es un deposito o almacn organizado de todos
los datos pertenecientes a nuestro sistema con definiciones precisas y
rigurosas para que todos los componentes del equipo de trabajo, as como el
usuario, tengan un entendimiento comn de todos las entradas, salidas,
componentes, etc. En el diccionario de datos hemos de definir:
a. Una descripcin del significado de los flujos y almacenes que se
muestran en los DFDs.
b. Una descripcin de la composicin de los paquetes de datos que se
mueven a lo largo de los flujos.
c. Una descripcin de la composicin de los paquetes de datos en los
almacenamientos.
d. Una especificacin de los valores y unidades relevantes de los
elementos de datos individuales de los flujos y almacenamientos.
e. Una descripcin de los detalles sobre las relaciones entre los
almacenes que se definirn en el diagrama entidad-relacin.
GESTIN DE
ALQUILERES
DE UN VIDEOCLUB
GESTIN DE
CLIENTES
GESTIN DE
PROVEEDORES
GESTIN DE
PELCULAS
GESTIONAR
PEDIDOS
GESTIONAR
ENTREGAS
GESTIONAR
FACTURAS
GESTIONAR
PAGOS
GESTIONAR
ALTAS/BAJAS
GESTIONAR
ALQUILERES
GESTIONAR
DEVOLUCIONES
GESTIONAR
RESERVAS
GESTIONAR
ALTAS/BAJAS
GESTIONAR
INFORMES
GESTIONAR
ALTAS/BAJAS

46

2.4.1.4.2 Notacin del diccionario de datos
A la hora de definir el diccionario de datos con la composicin de flujos,
almacenamientos, etc, es bastante habitual utilizar las siguientes notaciones:
a. = , indica que esta compuesto de.
b. +, equivale a y
c. ( ), lo que esta dentro es optativo
d. {}, representa una iteracin
e. [], su contenido ser una seleccin
f. |, tendremos que escoger entre el valor a la derecha o a la
izquierda
Por ejemplo: Alta = N empleado + Nombre + (primer apellido) + [soltero
| casado]
Con frecuencia en muchos sistemas se emplean alias, es decir, un
nombre alternativo para un dato. Esto es bastante habitual cuando se trata con
diversos grupos de usuarios. Es aconsejable que en el diccionario de datos
reflejemos que nombre es alias de cual otro.
2.4.1.3 Como mostrar el diccionario de datos al usuario
Habitualmente el diccionario de datos lo crea el analista durante el
desarrollo del modelo del sistema, pero el usuario debe ser capaz de leerlo y
entenderlo para poder verificar el modelo. Hay varios detalles que el analista
puede hacer sin la ayuda del usuario en el animo de tener un diccionario de
datos correcto, completo, consistente y no contradictorio, para ello simplemente
debemos hacernos las siguientes preguntas:

Se han definido en el diccionario de datos todos los flujos en el DFD?

Se han definido todos los componentes de los datos en el diccionario?

Se ha definido ms de una vez algn dato?

Hemos utilizado la notacin correcta para todas las definiciones del
diccionario de datos?

Hay elementos de datos en el diccionario que no estn relacionados no
con los DFDs ni con los diagramas entidad-relacin con con los diagramas
de transicin de estados?
2.4.1.4 Implementacin del diccionario de datos
Dentro de que la definicin de datos es una tarea que puede entenderse
como responsabilidad del analista, en los sistemas grandes o medianos la
definicin del diccionario de datos puede suponer una carga importante de
trabajo, por lo que su definicin se va haciendo conforme avanza el proyecto
por los distintos componentes del equipo de desarrollo.

47

2.4.2 TCNICAS DE ANLISIS Y MODELADO DE DATOS

La Modelizacin de Datos se orienta al conocimiento en profundidad de los
datos que va a manejar la unidad, con el fin de implantarlos de forma ptima.
La Base de Datos es un sistema de mantenimiento de registros basado en
ordenador, con un conjunto de programas que van a controlar el acceso y
recuperacin de la informacin.
__________________
MD + SGBD = BD
__________________
MD: MODELO DE DATOS
SGBD: SISTEMA GESTOR DE BASE DE DATOS
B.D.: BASE DE DATOS
Que es un modelo de datos?
Un Modelo de Datos es una representacin grfica orientada a la obtencin de
las estructuras de datos de una forma metdica y a la vez sencilla.
Es un "instrumento" que nos facilita la representacin de las necesidades del
usuario.
Ventajas de realizar un modelo de datos
Las ventajas de realizar una buena modelizacin de datos son, entre otras:

Control de los posibles errores desde el principio o, al menos, darse
cuenta de las deficiencias lo antes posible.

Obtencin de estructuras de datos independientes del entorno fsico.

Mejora del mantenimiento, por tener los datos localizados en las
distintas estructuras.
OBJETIVOS

El objetivo de la Modelizacin de Datos es el conocimiento profundo de los
datos que se van a manejar y de alguna forma agruparlos en unidades
mayores que se llamarn ENTIDADES. El Modelo de Datos debe ser una fiel
representacin del sistema de informacin objeto de estudio:

La estructura del Modelo de Datos debe ser el reflejo de la estructura del
sistema.

El contenido del Modelo de Datos debe representar el estado final al que
quiere llegar el sistema.

Cualquier cambio en el sistema de informacin se debe reflejar en el
Modelo y viceversa.

En el Modelo de Datos debe aparecer representada toda la informacin
que necesita la unidad.

48

El Modelo de Datos representa la parte lgica de la informacin. Se
dejan a un lado restricciones del sistema en que se van a implantar los
datos. Por ello, es independiente del entorno fsico y debe proporcionar
a los usuarios toda la informacin que necesitan y en la forma en que la
necesitan.
Por tanto, podramos decir que el objetivo fundamental del Modelo de Datos es
la obtencin de estructuras no redundantes, sin inconsistencias, seguras e
ntegras.
Al modelo que surge como primera aproximacin de ese mundo real se le llama
ESQUEMA CONCEPTUAL.
Cuando el usuario se plantea una serie de necesidades o cambios para su
unidad, es cuando el analista encargado del anlisis comienza a estudiar los
datos. De la narrativa tradicional o "mundo real" debe llegar grficamente al
ESQUEMA CONCEPTUAL de donde posteriormente podr deducirse el
ESQUEMA INTERNO y el EXTERNO (orientado a la mquina y al usuario
respectivamente).
As el esquema conceptual se considera como la "indireccin" entre los otros
dos, como indica la figura.

Cada uno de estos esquemas se podr representar mediante un conjunto de
modelos o tcnicas
Los tres esquemas de la Arquitectura de Datos

A. ESQUEMA EXTERNO.
Visin de los datos por las aplicaciones informticas.
B. ESQUEMA CONCEPTUAL.

49

Fiel reflejo de la realidad, prescindiendo de los requisitos informticos.
C. ESQUEMA INTERNO.
Forma de almacenar las estructuras que surgen.
A. ESQUEMA EXTERNO
El Esquema Externo es la visin que de los datos del sistema tienen las
aplicaciones informticas. As por ejemplo, existirn distintos modelos o
esquemas externos (una aplicacin COBOL, PLI, C, etc.) para el mismo
esquema conceptual.
B. ESQUEMA CONCEPTUAL
El Esquema Conceptual permite representar grficamente las necesidades del
usuario, sin tener en cuenta las restricciones del equipo fsico y lgico propios
del sistema en el que se va a hacer la implantacin.
En este esquema, al analista slo le concierne el aspecto global de la unidad o
rea funcional que se trata, y en l se definen las entidades de datos y las
relaciones entre ellas.
Se realizar un grfico previo mediante el cual se representan las entidades
detectadas en principio y sus relaciones. Posteriores entrevistas con el usuario
podrn aportar mejor informacin y habr que hacer correcciones sobre el
grfico para subsanar posibles deficiencias o errores.
Una vez realizado este grfico, se realizan sobre l una serie de refinamientos
dependiendo de la tcnica o modelo de representacin utilizado. As, los
refinamientos afectarn slo a las estructuras de los datos en el modelo
entidad-relacin de CHEN y tambin al grfico en el caso del Diagrama de
Estructura de Datos.
Una vez hecha este mejora, se establecern una serie de pasos para llegar a
estructuras de datos lo ms independientes posibles, aplicando la tcnica de
NORMALIZACION, con el fin de crear una definicin ms rigurosa de las
entidades de partida.
Este esquema debe ser independiente de los condicionamientos de
almacenamiento que se puedan tener.
C. ESQUEMA INTERNO.
El Esquema Interno est orientado a la forma en que se almacenan las tablas
en memoria.
Este esquema depende esencialmente de la memoria disponible y de los
Dispositivos de Almacenamiento de Acceso Directo que se vayan a utilizar.

50

El conocimiento de las claves y el uso de ndices predefinidos poda servir de
ayuda para la localizacin ptima de los datos.
Es en este momento cuando se comenzar a pensar en el lenguaje que se va a
manejar y el equipo fsico en el que se implantar. Por ello se encargar de
esta fase una persona conocedora de las posibles restricciones o limitaciones
existentes, que ser el ADMINISTRADOR del sistema.
La estructura que se va a obtener es, en general, transparente al usuario.
DEFINICIONES

Las tcnicas de Modelo de Datos que se tratarn, Modelo entidad-relacin de
CHEN y Diagrama de Estructura de Datos, varan en la filosofa de la
concepcin del Esquema Conceptual y grficamente en los iconos que utilizan.
En la figura se representan grficamente ambas tcnicas:

51

A pesar de ser distinta la forma de representacin, vamos a ver que
representan la misma informacin.
Antes de ello, vamos a pasar a definir una serie de trminos vlidos para
cualquiera de las tcnicas utilizadas:
ENTIDAD
Representan objetos, personas... sobre las que se quiere guardar informacin
por ser relevante para nuestro sistema.
Un conjunto de entidades con las mismas caractersticas es lo que forma un
Tipo de Entidad.
As, por ejemplo, el Tipo de Entidad EMPLEADO contendr a PEPE, JUAN...
que son las Entidades que lo forman, con todas sus caractersticas propias.
El tipo de entidad, internamente, se va a representar por medio de una TABLA.
A partir de ahora se utilizarn indistintamente los trminos entidad y tipo de
entidad.
ATRIBUTO
Cada Tipo de Entidad tendr una serie de caractersticas que sern necesarias
para describirla completamente. Cada una de esas caractersticas van a ser los
atributos de la Entidad. En algunas ocasiones se llaman ELEMENTO o
CAMPO.
Ms formalmente, se puede definir un atributo de una entidad como una unidad
bsica e indivisible de informacin acerca de dicha entidad, que sirve para
identificarla o describirla. Ejemplo: NOMBRE DEL EMPLEADO, DNI.
RELACION

52

Es la conexin que va a existir entre tipos de entidades.
TABLA
Representacin fsica de un Tipo de Entidad. Como se ver ms adelante, un
Tipo de Entidad podr dar lugar a una o varias tablas.
La informacin que contienen estar dispuesta en dos dimensiones.
FILA
Conjunto de atributos de una entidad. Se puede llamar OCURRENCIA o
TUPLA.
COLUMNA
Atributo elegido para el conjunto de entidades de un Tipo de Entidad.
GRADO DE UNA TABLA
Nmero de columnas de una tabla.
CLAVE
Atributo o conjunto de atributos concatenados perteneciente al mismo tipo de
entidad que hacen nico el acceso a una entidad u ocurrencia de la tabla, es
decir, que determinan de forma nica una entidad.

De la tabla que origina esa entidad alguno de los atributos debe permitirnos el
acceso nico a una fila, y puede ser un atributo o concatenacin de atributos
del dominio.
En un principio podemos pensar en la existencia de varias claves sobre la
misma tabla. Al conjunto de todas estas posibles claves se les va a llamar,

53

CLAVES CANDIDATAS, algunas de ellas pueden no servir por no darnos una
nica ocurrencia sobre la tabla.
Una vez seleccionada la clave, podremos ver si est compuesta por un nico
atributo: CLAVE SIMPLE, o por un conjunto de atributos CLAVE MULTIPLE o
CONCATENADA.
Otro concepto importante es el de CLAVE AJENA, esto es: "Atributo de una
tabla que es clave en otra".
Ser muy importante su localizacin para evitar inconsistencia de la
informacin contenida en las estructuras de datos: Integridad Referencial.
OCURRENCIA DE ENTIDAD
Cada uno de los posibles valores reales que puede tomar la clave de una
entidad. Se entiende por valor real aquel que tiene existencia propia dentro del
sistema en estudio.
CARDINALIDAD DE LA RELACION
Representa la participacin en la relacin de cada una de las entidades
afectadas, es decir, el nmero de las ocurrencias de una entidad que se
relacionan con ocurrencias de la otra entidad.
Conceptualmente, se pueden identificar tres clases:
(1,1) Una ocurrencia de una entidad con una ocurrencia de la otra entidad. Por
ejemplo, en nuestro contexto cultural, un hombre slo est casado con una
mujer y viceversa.
(1,m) Una ocurrencia de una entidad con varias ocurrencias de la otra entidad.
Por ejemplo, una Unidad tiene varios empleados y cada empleado est
asignado exclusivamente a una Unidad.
(m,n) Varias ocurrencias de una entidad con varias ocurrencias de la otra
entidad. Por ejemplo, un paciente puede tomar varias medicinas y una
medicina puede ser tomada por distintos pacientes.
ESTRATEGIAS DE DISEO

TOP-DOWN: "De arriba a abajo". Partimos de lo general para ir llegando al
detalle.
El usuario tiene una serie de necesidades y se va a llegar a las estructuras de
datos a implantar.
Se puede suponer que no existe nada hecho, esto es, ficheros en uso que
podemos aprovechar y por ello partimos de las nuevas necesidades.

54

BOTTOM-UP: "De abajo a arriba". Lo normal es que ya se est trabajando con
una serie de ficheros y lo que quiere el usuario es mejorar o modificar lo
existente por ampliacin de los servicios, por ejemplo.

2.4.2.1 DIAGRAMA DE ENTIDAD RELACIN


55

Peter Chen public en 1976 el modelo entidad relacin, el cual tuvo gran
aceptacin principalmente por su expresividad grfica. Sobre esta primera
versin han trabajado numerosos autores, generando distintas extensiones de
mayor o menor utilidad y de aceptacin variable en el medio acadmico y
profesional
Sirve para establecer una visin global de los datos de una organizacin o de
un sistema de informacin, en un nivel de abstraccin prxima al usuario e
independiente de las caractersticas fsicas del equipo donde se vaya a
instrumentar el sistema.
Constituye el Nivel Conceptual de la arquitectura ANSI
Consiste en describir la informacin de la organizacin mediante la definicin
de Entidades y asociaciones o interrelaciones entre ellas.
Propuesto por CHEN, es un Modelo N-ARIO, es decir, que las relaciones
pueden asociar una, dos o ms entidades. Se puede hablar de relaciones:
UNITARIAS: Una entidad consigo misma.
BINARIAS: Entidades relacionadas dos a dos.
TERNARIAS: Relacin entre tres entidades.
Los iconos utilizados en los grficos son:
ENTIDAD
Cualquier objeto real o abstracto sobre el cual
queremos tener informacin que tiene existencia
por s mismo y se puede identificar de manera
clara y precisa (empleados, artculos, clientes, planificaciones, estndares)
Una entidad se representar mediante un rectngulo con un nombre.
Para poner nombre a la entidad, normalmente se utiliza la forma singular. (y
maysculas)
La entidad ha de cumplir las siguientes caractersticas:
- Cada uno de sus miembros individuales (instancias), pueden ser identificados
unvocamente. Existe alguna manera de diferenciar dos instancias individuales
de la entidad
- Cada entidad juega una funcin dentro del sistema. El sistema no funciona sin
acceder a sus miembros instancias
- Cada entidad puede ser descrito por uno o mas datos elementales (atributos).
Los atributos se aplican a cada instancia de la entidad.
ATRIBUTOS
C
C
L
L
I
I
E
E
N
N
T
T
E
E

56

Cada una de las propiedades, caractersticas o unidades de informacin
bsicas de una entidad o interrelacin
Aquel o aquellos atributos que identifican unvocamente cada una de las
ocurrencias de la entidad se denomina identificador principal
Entidad : CLIENTES
Atributos: DNI, Nombre, direccin, telfono, etc...
Identificador Principal: DNI
Asociacin o correspondencia entre entidades
Cada instancia de la interrelacin representa una asociacin entre 0 o ms
ocurrencias de un objeto y 0 o ms ocurrencias de otro objeto
Ejemplo :
- instancia 1 : cliente 1 compra artculo 1
- instancia 2 : cliente 2 compra artculos 2 y 3
- instancia 3 : clientes 3 y 4 compran artculo 4
- instancia 4 : cliente 5 no compra ningn artculo
- instancia 5 : clientes 6, 7 y 8 compran artculos 5, y 6
Grado de la interrelacin: Nmero de entidades participantes

unitarias o reflexivas

Binarias

N-arias
Cardinalidad mxima o tipo de interrelacin
Numero mximo de ocurrencias de cada entidad que pueden intervenir en la
interrelacin que se esta tratando
1:1 Ejemplo: En nuestro modelo de sociedad, un hombre est casado con una

mujer y
una mujer est casada con un hombre
1:N Ejemplo: Un empleado pertenece a un

departamento y a un departamento pueden
pertenecer varios empleados
N:M Ejemplo: Un empleado puede trabajar en muchos proyectos y en un proyecto
pueden trabajar muchos empleados
Pasos generales a seguir para la construccin:
a. Identificar tipos de entidades.
b. Identificar tipos de interrelaciones.
c. Encontrar las cardinalidades.
CLIENTE
ARTICULO
compra

57

d. Identificar los atributos de cada tipo de entidad.
e. Identificar las claves de cada tipo de entidad.
La regla bsica es distinguir tipos de entidades e interrelaciones de atributos.
As, los atributos deben ser atmicos y caractersticos del tipo de entidad o
interrelacin que describan.

La cardinalidad se representa con un nmero cerca de la entidad y representa
el nmero de veces que sta puede aparecer. Se puede poner la mnima y la
mxima.
Para CHEN existen dos tipos de entidades representables:
ENTIDAD REGULAR.
Aquella sobre la que se puede definir la clave primaria dentro de sus propios
atributos, es decir, aquellas entidades que se identifican por s mismas.
ENTIDAD DEBIL.
Con sus atributos propios no se puede encontrar la clave, por estar asociada a
otra entidad.
Se representan tanto grficamente como mediante la clave de esta entidad,
que est formada por:
La Clave de la entidad de la cual dependen.

Un atributo identificativo de la ocurrencia de la entidad dbil.

58

Refinamiento del modelo entidad-relacin de Chen
Al modelo construido segn la tcnica de CHEN, se le aplican una serie de
refinamientos sucesivos, mediante los cuales se obtienen un conjunto de
tablas. Estas tablas sern posteriormente normalizadas aplicando las tcnicas
de NORMALIZACION que se estudiarn ms adelante.
2.4.2.2 DIAGRAMA DE ESTRUCTURA DE DATOS

Los Diagramas de Estructura de Datos tienen los siguientes elementos:
ENTIDAD: Se representa grficamente mediante un rectngulo.
RELACION ENTRE ENTIDADES: Una lnea recta que une las entidades que
estn relacionadas. Esta lnea puede terminar en un tridente o una flecha para
indicar una cardinalidad de tipo m.
Caractersticas del diagrama de estructura de datos

Es un modelo binario, es decir, permite representar grficamente las
relaciones o asociaciones entre pares de entidades.

Se consideran slo relaciones del tipo (1,m), procedindose para los otros
tipos de relaciones, del modo siguiente:

En el caso de las relaciones de cardinalidad (1,1), se agrupan las dos
entidades en una sola, aadindose los atributos de una entidad a la
otra.

En el caso de relaciones de cardinalidad (m,n), se crea una entidad
auxiliar que sirve de nexo entre las dos entidades iniciales,
crendose as dos relaciones (1,m).
Un ejemplo de esto puede verse en la figura.

59

Dada la funcin de nexo que cumple esta entidad auxiliar, puede no tener
existencia real, por lo que pueden existir dificultades a la hora de nombrarla, en
este caso se recomienda denominarla como "Enlace Entidad 1/Entidad 2".
La clave de este entidad de enlace estar formada por la concatenacin de las
claves de cada una de las entidades originales.

En una relacin de cardinalidad (1,m) entre dos entidades, la entidad
en el extremo 1, se denomina MAESTRA, y la entidad en el extremo
M, se denomina DETALLE.
Relaciones opcionales y exclusivas
Sea una relacin entre dos entidades A y B, siendo A la entidad maestra y B la
entidad detalle.

Si para toda ocurrencia de A debe existir siempre al menos una ocurrencia
de B asociada, y a la inversa, para una ocurrencia de B siempre existe
una ocurrencia de A asociada, se dice que la relacin es OBLIGATORIA
en ambos extremos.

Si para toda ocurrencia de A, pueden existir o no, una o varias ocurrencias
de B asociadas, pero para una ocurrencia de B siempre ha de haber una
ocurrencia de A asociada, se dice que larelacin es OPCIONAL en la
entidad maestra y OBLIGATORIA en la entidad detalle.

Si para una ocurrencia de A debe existir siempre al menos una ocurrencia
de B asociada, y para una ocurrencia de B puede existir o no una
ocurrencia de A asociada, esta relacin es OBLIGATORIA en la entidad
maestra y OPCIONAL en la entidad detalle.

Si para una ocurrencia de A puede existir o no una ocurrencia de B
asociada, y para una ocurrencia de B puede existir o no una ocurrencia de
A, esta relacin es OPCIONAL en ambos extremos.
Las relaciones opcionales en la entidad detalle se representan como indica la
figura

60

Se dice que unas relaciones entre varias entidades son EXCLUSIVAS, si la
existencia de una de esas relaciones entre dos entidades implica la no
existencia de las otras relaciones, como es el caso de la figura

Fases en la construccin del modelo conceptual

1. Identificar las entidades dentro del sistema
Para identificar las entidades el analista deber conocer el funcionamiento del
sistema en estudio. Para ello, deber basarse principalmente en:

Reuniones con los usuarios implicados.

Estudio de la documentacin existente sobre el funcionamiento de dicho
sistema.

Estudio de las necesidades de informacin (reflejadas en el anlisis de
requisitos del sistema).

Estudio de los principales tipos de informacin manejados por sistema
actual.
Para ir encontrando las diversas entidades, servir de ayuda pensar en:

Objetos reales (Mquinas, Edificios, Almacenes,...).

Personas (Empleados, Funcionarios,...)

Actividades del sistema (Licencias, Albaranes,...)

Objetos abstractos (Categoras de personal,...)
2. Determinar las claves o identificadores de las entidades

61

Para determinar las claves, se obtendrn aquellos atributos que identifiquen
unvocamente cada ocurrencia de cada entidad. Si para una entidad concreta
hubiera varios, se elegir uno de ellos.
Lgicamente, este atributo o conjunto de atributos que constituyen la clave, no
podr tener valores sin informacin (nulos), ya que esto no permitira
determinar claramente una ocurrencia de entidad.
3. Establecer las relaciones entre las entidades, describiendo el grado de
las mismas.
Para establecer las asociaciones o relaciones entre entidades, se estudia cada
una de las asociaciones de una entidad con las dems entidades identificadas,
para ver si dichas asociaciones tienen sentido e importancia para el sistema
que se estudia.
Para el conjunto de relaciones que se haya obtenido, se estudiar su
cardinalidad.
Asimismo, en el caso del Diagrama de Estructura de Datos, se estudiar si
dicha relacin es opcional o si es exclusiva.
4. Dibujar el modelo de datos
Se dibujar el diagrama, utilizando los smbolos que se han descrito.
5. Identificar y describir los atributos de cada entidad
Para identificar los atributos de cada entidad, habr que tener en cuenta todas
aquellas propiedades de cada entidad en las que el sistema tenga inters.
6. Verificaciones
Se realizarn las verificaciones sobre el diagrama, eliminando del mismo las
relaciones que sean redundantes. Una relacin o asociacin ser redundante si
puede expresarse exactamente por medio de una combinacin de varias
asociaciones.
Es conveniente ser prudente a la hora de suprimir las relaciones redundantes
dado que su existencia puede obedecer a especificaciones propias del sistema.
Para ilustrar esto ltimo supongamos el ejemplo de la figura.

62

En la figura anterior si todos los empleados pertenecen a un servicio y todos los
servicios a un departamento, la asociacin directa de
Departamento/Empleados es redundante.
En la figura siguiente, sin embargo, si se da la especificacin o requisito de
usuario de que un empleado puede trabajar en un departamento sin pertenecer
a l (en comisin de servicio) esta asociacin no sera redundante.

Por ltimo es conveniente transmitir una nota de tranquilidad con respecto al
diseo resultante, dado que el mismo ser validado y contrastado a posteriori.
2.4.2.3 NORMALIZACIN

La teora de la normalizacin tiene por objetivo la eliminacin de
dependencias entre atributos que originen anomalas en la actualizacin de los
datos, y proporcionar una estructura ms regular para la representacin de las
tablas, constituyendo el soporte para el diseo de bases de datos relacionales.
Como resultado de la aplicacin de esta tcnica se obtiene un modelo lgico de
datos normalizado.
Objetivos

Reducir las inconsistencias y redundancias de los datos.

63

Facilitar el mantenimiento de los datos y programas.

Evitar anomalas en operaciones de manipulacin de datos.

Reducir el impacto de los cambios en los datos.
Conceptos Bsicos

El resultado del anlisis relacional de datos ser un conjunto de tablas
normalizadas o "relaciones" en el que se representarn todos los datos del
sistema.
El objetivo ser obtener un modelo lgico normalizado, que represente
"ENTIDADES NORMALIZADAS" y las "INTERRELACIONES" entre ellas.
Este modelo se comparar con el que se obtuvo mediante la tcnica del
Diagrama de Estructura de Datos y de esa comparacin se obtendr el modelo
lgico de datos definitivo del sistema.
Es conveniente matizar que las entidades normalizadas obtenidas pueden
diferir de las entidades que se han identificado inicialmente de una manera
subjetiva.
A continuacin se definen una serie de conceptos que sern tiles a la hora de
normalizar.
Dependencia funcional: Un atributo B depende funcionalmente de otro
atributo A, de la misma entidad si a cada valor de A le corresponde slo un
valor de B. Ejemplo: En la entidad EMPLEADO cuyos atributos son:

Nmero de Empleado (clave).

Nombre.

Categora.

Direccin.

Los atributos Nombre, Categora y Direccin dependen funcionalmente de la
clave Nmero de Empleado.
Dependencia funcional completa: Un atributo B tiene dependencia funcional
completa de un grupo de atributos A de la misma entidad, si B depende
funcionalmente de A pero no de ningn subconjunto obtenido de los posibles
atributos que forman A.
Dependencia transitiva: Sean A, B y C tres atributos (o grupos de atributos)
de una relacin. Si B depende funcionalmente de A y C de B, pero A no
depende funcionalmente de B se dice que C depende transitivamente de A.
Estas definiciones previas nos proporcionan un medio de definir el
procedimiento de normalizacin, y su sentido quedar claramente explicado en
el captulo siguiente, mediante un ejemplo.
Procedimiento de Normalizacin

Primera Forma Normal

64

Se dice que una entidad est en primera forma normal (1FN) si no contiene
grupos repetitivos, es decir, todos los atributos dependen funcionalmente de la
clave.
Ejemplo: sea un documento o albarn de pedidos de una unidad, que se
identificar inicialmente como la ENTIDAD PEDIDO, que contiene los
siguientes atributos:
. Cdigo del Pedido.
. Fecha del Pedido.
. Cdigo del Proveedor.
. Nombre del Proveedor.
. Direccin del Proveedor.
. Cdigo del material.
. Descripcin del material.
. Cantidad pedida del material.
. Precio unitario del material.
La clave principal es: Cdigo del Pedido.
Evidentemente no se cumple la primera forma normal, ya que para un mismo
cdigo de pedido hay varios cdigos de material, es decir, el cdigo de material
no depende funcionalmente del cdigo de pedido.
Solucin: una vez identificados los atributos que no dependen funcionalmente
de la clave, se formar con ellos una nueva entidad y se eliminarn de la
antigua. La clave principal de la nueva entidad estar formada por la
concatenacin de uno o varios de sus atributos y la clave principal de la antigua
entidad.
En este caso quedar:
PEDIDO 1:
. Cdigo del Pedido (K)
. Fecha del Pedido.
PEDIDO 2:
. Cdigo del Pedido (1)
. Cdigo del Material (2)
. Descripcin del material.
. Cantidad pedida del Material.
. Precio unitario del Material.
(K) indica que este atributo es clave principal nica.

65

(1) y (2) indican que estos atributos estn concatenados para formar la clave
principal.
Segunda Forma Normal
Se dice que una entidad est en Segunda Forma Normal (2FN) si est en 1FN
y cada atributo que no pertenezca a la clave tiene una dependencia funcional
completa de la clave.
Dicho de otra forma, si cada uno de los atributos de la entidad depende de toda
la clave.
Ejemplo: En la entidad PEDIDO 2, se observa que los atributos "Descripcin
del Material" y "Precio Unitario del Material" no tienen una dependencia
funcional completa de la clave, sino que la tienen slo de una parte de la
misma: "Cdigo del Material"
Solucin: Una vez identificados los atributos que no dependen funcionalmente
de toda la clave, sino slo de parte de la misma, se formar con ellos una
nueva entidad y se quitan de la antigua. La clave principal de la nueva entidad
estar formada por la parte de la antigua de la que dependen funcionalmente.
PEDIDO21: PEDIDO 22:
Cdigo del pedido (1) Cdigo del Material (K)
Cdigo del Material (2) Descripcin del Material.
Cantidad Pedida del Material Precio Unitario.
Tercera Forma Normal
Una entidad est en tercera forma normal (3FN) si est en segunda forma
normal y cada atributo que no pertenezca a la clave no depende
transitivamente de dicha clave;en otras palabras, si cada uno de los atributos
de la entidad dependen slo de la clave.
Ejemplo: En la entidad PEDIDO1, cuyos atributos se repiten a continuacin:
PEDIDO1:
. Cdigo del Pedido (K)
. Fecha del Pedido.
se observa, revisando la definicin dada anteriormente, la siguiente
dependencia transitiva:

66

Para un Cdigo del Pedido (A) hay un nico Cdigo del Proveedor (B),
es decir, B depende funcionalmente de A.

Para un Cdigo del Proveedor (B), hay un nico Nombre del Proveedor y
Direccin del Proveedor (C), es decir, C depende funcionalmente de B.

Para un Cdigo del Proveedor (B), hay varios Cdigos del Pedido (A).
Se observa, pues, que C depende transitivamente de A. Esta entidad PEDIDO1
no est en 3FN.
Solucin: Una vez identificados los atributos que dependen de otro atributo
distinto de la clave (las dependencias transitivas), se formar con ellos una
nueva entidad y se quitarn de la antigua. La clave principal de la nueva
entidad ser el atributo del cual dependen. Este atributo, en la entidad antigua,
pasar a ser una clave ajena.
Se obtendr pues:
PEDIDO11: Cdigo del pedido (K).
. Fecha del Pedido.
PEDIDO12: Cdigo del Proveedor (K)
Productos Obtenidos: Siguiendo el procedimiento de Normalizacin, se han
obtenido, a partir de la entidad PEDIDO, las siguientes entidades en tercera
forma normal:
PEDIDO11: Cdigo del Pedido (K)
. Fecha del Pedido.
PEDIDO12: Cdigo del Proveedor (K)
PEDIDO21: Cdigo del Pedido (1)
. Cdigo del Material (2)
. Cantidad Pedida del Material.
PEDIDO22: Cdigo del Material (K)
. Descripcin del Material.
. Precio Unitario.
Se puede observar que a partir de la entidad no normalizada PEDIDO se han
obtenido cuatro entidades normalizadas. Las asociaciones entre ambas vienen
dadas mediante las claves comunes.

67

Se nombrarn las entidades normalizadas obtenidas, atendiendo a su
significado. En el ejemplo anterior: PEDIDO11 se llamar PEDIDO; PEDIDO12
se llamar PROVEEDOR; PEDIDO22 se llamar MATERIAL y PEDIDO21 se
llamar PEDIDO-MATERIAL.
Comparacin entre el diagrama de estructura de datos y la estructura de
registros normalizados

A partir de las entidades normalizadas obtenidas mediante la tcnica de
normalizacin, se puede obtener un Diagrama de Estructura de Datos (DED),
siguiendo el procedimiento que se indica a continuacin:

Cada entidad normalizada es una entidad del DED.

Las entidades normalizadas con clave compuesta se representan como
"entidades detalle" de las entidades que tienen las partes de esta clave
compuesta como clave primaria (PEDIDO11 es detalle de PEDIDO12 y
PEDIDO 21 es detalle de PEDIDO22). (Recordar que una entidad detalle es
aquella que, en una conexin (1, m), entre dos entidades, est en el
extremo m).

Las entidades normalizadas con claves ajenas son detalle de las entidades
que tienen esa clave ajena como clave primaria (PEDIDO11 es detalle de
PEDIDO22).
Una aproximacin sistemtica para resolver las inconsistencias entre ambos
modelos ser la siguiente:
1. Revisar los nombres de las entidades, dado que al normalizar puede ocurrir,
como se ha dicho, que se creen entidades diferentes de las existentes
inicialmente.
2. Tener en cuenta que pueden aparecer entidades diferentes como
consecuencia de la diferente aproximacin al estudio de los datos seguida por
ambas tcnicas. Resolver la conveniencia de incluir estas entidades diferentes
a la luz de los requisitos de usuario.
3. La tcnica del DED muestra una serie de smbolos, tales como relaciones
exclusivas o relaciones opcionales, que no aparecen en el modelo normalizado.
Dichas diferencias sern resueltas a la vista de los requisitos de usuario.
REGLAS DE INTEGRIDAD
Para asegurar un acceso eficiente a los datos del sistema, es necesario tener
en cuenta las siguientes reglas de integridad:
Integridad De Entidad
"La clave principal no puede tener valor nulo", es decir, tiene que
contener dato.

68

Si se permite valor nulo, poda existir ms de un atributo con ese mismo
valor, con lo cual el acceso puede no ser nico.
Integridad Referencial
"Si existe CLAVE AJENA, el valor ha de ser igual al atributo clave o bien
ser nulo". Si se da de baja, habr que buscarlo en cualquier otro sitio
que pueda aparecer y si no se da de baja al registro completo, al menos
se pondr el valor nulo a ese atributo.
OPTIMIZACIN DEL MODELO DE DATOS
Una vez obtenido el conjunto de tablas o entidades normalizadas en 3FN, es
necesario asegurar que este modelo de datos en 3FN satisface los requisitos
de rendimiento exigidos para el sistema, en cuanto a tiempos de respuesta.
En general, y como se indica en la Gua de Referencia de la Metodologa, se
estudiar la adecuacin del modelo de datos en 3FN a los requisitos de
rendimiento estipulados por las transacciones consideradas como crticas
dentro del sistema en desarrollo.
Este estudio puede llegar a la necesidad de desnormalizar el modelo de datos,
con el fin de reducir o simplificar el nmero de accesos a la base de datos, para
las transacciones crticas consideradas. Para ello se seguirn las
recomendaciones que a continuacin se indican:

Introducir redundancias en los elementos de datos.

Introducir elementos repetitivos.

Redefinir o aadir relaciones entre entidades para hacer ms directo el
acceso entre entidades.

Dividir entidades.

Modificar el tratamiento realizado por las transacciones crticas.

Combinar entidades, si los accesos para ellas son frecuentes dentro de la
misma transaccin.

Definir claves secundarias o ndices para permitir caminos de acceso
alternativos.
En cualquier caso, se ha de tener presente que la desnormalizacin puede
implicar problemas y anomalas en las operaciones de manipulacin de datos.
Por esto, la decisin de proceder a la desnormalizacin ser competencia del
Administrador de la Base de Datos (si lo hubiera) o de la persona responsable
de la gestin de los datos dentro de la instalacin.
2.4.3 TCNICAS DE MODELADO DE COMPORTAMIENTO

2.4.3.1 DIAGRAMA DE TRANSICION DE ESTADOS

Un diagrama de transicin de estados muestra el comportamiento
dependiente del tiempo de un sistema de informacin. Representa los estados

69

que puede tomar un componente o un sistema y muestra los eventos que
implican el cambio de un estado a otro.
Descripcin
Los dos elementos principales en estos diagramas son los estados y las
posibles transiciones entre ellos.
El estado de un componente o sistema representa algn
comportamiento que es observable externamente y que perdura durante un
periodo de tiempo finito. Viene dado por el valor de uno o varios atributos que
lo caracterizan en un momento dado.
Una transicin es un cambio de estado producido por un evento y refleja
los posibles caminos para llegar a un estado final desde un estado inicial.
Desde un estado pueden surgir varias transiciones en funcin del evento
que desencadena el cambio de estado, teniendo en cuenta que, las
transiciones que provienen del mismo estado no pueden tener el mismo
evento, salvo que exista alguna condicin que se aplique al evento.
Un sistema slo puede tener un estado inicial, que se representa
mediante una transicin sin etiquetar al primer estado normal del diagrama.
Pueden existir varias transiciones desde el estado inicial, pero deben tener
asociadas condiciones, de manera que slo una de ellas sea la responsable de
iniciar el flujo. En ningn caso puede haber una transicin dirigida al estado
inicial.
El estado final representa que un componente ha dejado de tener
cualquier interaccin o actividad. No se permiten transiciones que partan del
estado final. Puede haber varios estados finales en un diagrama, ya que es
posible concluir el ciclo de vida de un componente desde distintos estados y
mediante diferentes eventos, pero dichos estados son mutuamente
excluyentes, es decir, slo uno de ellos puede ocurrir durante una ejecucin del
sistema.
Los diagramas de transicin de estados comprenden adems otros dos
elementos que el significado de los distintos estados por los que pasa un
componente o sistema.
Estos elementos se conocen como acciones y actividades. Una accin es una
operacin instantnea asociada a un evento, cuya duracin se considera no
significativa y que se puede ejecutar: dentro de un estado, al entrar en un
estado o al salir del mismo. Una actividad es una operacin asociada a un
estado que se ejecuta durante un intervalo de tiempo hasta que se produce el
cambio a otro estado.
Para aquellos estados que tengan un comportamiento complejo, se
puede utilizar un diagrama de transicin de estados de ms bajo nivel. Estos
diagramas se pueden motrar por separado o bien incluirse en el diagrama de
ms alto nivel, dentro del contorno del estado que representa. En cualquier

70

caso su contenido formar un contexto independiente del resto, con sus
propios estados inicial y final.

ESTADO 1
ESTADO 2
Condicin de transicin
Accin, o acciones de
transicin
Transicin

71

Ejemplo:
2.4.3.2 DIAGRAMA DE HISTORIA DE LA VIDA DE LAS ENTIDADES

INTRODUCCIN

La tcnica de la Historia de la Vida de las Entidades (HVE) permite describir
la evolucin de las entidades de datos del sistema. Esta visin evolutiva de los
datos sirve de complemento a las representaciones del sistema efectuadas
hasta ahora:

La visin esttica de los datos, que muestra las interrelaciones entre las
entidades de datos del sistema, proporcionada por el Diagrama de
Estructura de Datos (DED)

La visin dinmica de los datos, que muestra el proceso de los flujos de
datos, proporcionada por los Diagramas de Flujo de Datos (DFD).
La elaboracin de las HVE se basa en las entidades de datos, identificadas y
descritas en los Diagramas de Estructura de Datos, y en las transacciones o
eventos del sistema, identificados en los Diagramas de Flujo de Datos. Por este
motivo las HVE son un poderoso instrumento para verificar la exactitud de
BARRERA
ABIERTA
ABRIENDO
BARRERA
CERRANDO
BARRERA
BARRERA
CERRADA
Tren aprox. dcha. o izda.
Cerrar barrera
Activar alarma
T=1
Barrera abierta
Desactivar alarma
T=1
cerrar barrera
Barrera cerrada
Desactivar alarma
(Tren sale dcha. o izda.) y T=1
T=0
Abrir barrera
Activar alarma
T=T+1
(Tren sale dcha. o izda.) y T>1
T=T-1

72

dichos modelos (DED y DFD) y garantizar la coherencia entre las tres visiones
del sistema.
OBJETIVOS DE LA TCNICA

Obtener un registro de la secuencia de los cambios de las entidades en el
tiempo.

Obtener los requisitos de tratamiento de las entidades.

Establecer los estados posibles de las entidades para que tengan lugar
transacciones externas, as como los cambios de estado de las entidades
originados por dichas transacciones.

Poner de manifiesto las posibles interacciones que producen los eventos o
sucesos.
DESCRIPCIN DETALLADA DE LA TCNICA

Elementos
En la tcnica de la Historia de la Vida de las Entidades se consideran los
siguientes elementos:

Entidades de datos
Cualquier objeto sobre el que el sistema guarda informacin. Las
entidades de datos estn caracterizadas por sus atributos.
Se construir una HVE para cada entidad del sistema. Mediante la HVE se
describe la "sucesin de eventos" que afectan a dicha entidad y cuyos
efectos son, en lneas generales:
o Crear o dar de alta la entidad en el sistema.
o Modificar cualquier aspecto o caracterstica de la entidad, es
decir, modificar sus atributos.
o Borrar o dar de baja la entidad del sistema.

Eventos
Cualquier suceso que activa a un proceso que actualiza datos del sistema.
Se pueden considerar tres tipos de eventos:
o Eventos producidos en el exterior del sistema, por ejemplo,
solicitudes de altas o modificaciones de los datos almacenados en
el sistema. Estos eventos "ponen en marcha" los procesos que
realizan dichas funciones de actualizacin.
o Eventos peridicos: se identifican en los Diagramas de Flujos de
Datos, estudiando aquellos procesos que actualizan los
almacenes de datos, sin un estmulo externo, con una
periodicidad temporal. Por ejemplo: En un sistema donde las

73

entidades a las que no se haya accedido en cierto tiempo, se
archiven, se identificara el evento peridico "Archivar entidades".
Otro ejemplo sera la actualizacin peridica de los valores de
determinados atributos de una entidad.
o Eventos reconocidos internamente, por ejemplo, prerrequisitos
que el sistema exige para activar el proceso de actualizacin.
Los eventos se asocian a las entidades a las que afectan por medio de
la correspondencia existente entre los almacenes de datos
representados en los DFD y las entidades de datos del sistema,
representadas en los DED:
o Un almacn de datos corresponde a un conjunto completo de
entidades de datos (una o ms).
o

Efectos:
Los efectos describen el resultado de la accin de un evento sobre una
entidad determinada.
Un evento puede tener diferentes efectos sobre distintas entidades de
datos, as por ejemplo:
El evento: SOLICITUD APERTURA CUENTA BANCARIA tiene los efectos:
o CREA ENTIDAD CLIENTE (o lo actualiza si el cliente ya
existe).
o CREA ENTIDAD CUENTA.
Asimismo, un mismo evento puede tener diferentes efectos sobre la misma
entidad de datos, en diferentes tiempos. Por ejemplo:

Dentro de un Banco se tiene la entidad de datos CUENTA.

El evento SOLICITUD DE TRANSFERENCIA tiene lugar entre dos
ocurrencias de la entidad cuenta.

Para una ocurrencia hace un apunte en el DEBE.

Para la otra ocurrencia hace un apunte en el HABER.
Los tres grandes tipos de efectos sobre una entidad son:
I: Insertar.
M: Modificar.
B: Borrar.
En el diagrama se representan los eventos y el efecto sobre la entidad de
que se trata dentro de una caja.
Nodo:

74

En la representacin grfica de la HVE, se utilizan los nodos como
medio de agrupar un conjunto de eventos que afectan a la entidad y
estructurar as mejor la figura. As por ejemplo, se podra introducir un
nodo que agrupase a los eventos que crean la entidad, otro nodo que
agrupase a los eventos que la modifican y otro que agrupase a los
eventos que la borran.
Cajas vacas:
Representan el caso en que ningn evento afecta a la entidad. Son tiles
para simbolizar, conjuntamente con la estructura de seleccin que se
estudiar ms adelante, los casos excepcionales en que una entidad
puede verse afectada por un evento determinado.
Representacin grfica
Las HVE se representan de forma jerrquica, comenzando, en la parte superior
del diagrama, con la entidad cuyo ciclo de vida se va a representar.
A continuacin, dependiendo jerrquicamente de la entidad, se representan los
eventos que actan sobre la entidad y los efectos que tienen dichos eventos.
Como se ha indicado, se pueden introducir nodos para estructurar mejor la
figura.
En la HVE se tienen los siguientes tipos de estructura:
Secuencia: Indica la sucesin temporal de los eventos sobre la entidad de que
se trata y se representa mediante cajas que se leen de izquierda a derecha.
Seleccin: Representa diferentes eventos alternativos en un momento dado
del ciclo de la vida de la entidad. Se representa mediante un (O).
Iteracin: Representa la repeticin de un evento o un conjunto de eventos (un
nodo) en un momento particular de la vida de la entidad. Se representa
mediante el smbolo:(*)
En la figura se representan estos tres tipos de estructura.

75

Estructuras paralelas: Este tipo de estructura se utiliza cuando, dentro de la
historia de la vida de la entidad, los eventos ocurren de forma simultnea en el
tiempo, o bien no se puede predecir exactamente su sucesin secuencial. Esto
se representa colocando este tipo de eventos simultneos debajo de una barra,
como indica la figura:


76

Otras convenciones

Salto
Dentro de la Historia de la Vida de la Entidad, existen eventos cuyo
resultado es la alteracin de la vida normal de esta entidad, de manera que
dicha entidad pasa a otro estado, dentro de los que puede tener.
Por ejemplo, en el caso de la entidad TARJETA DE CREDITO.
Se produce el evento: NOTIFICACION DE PERDIDA DE LA TARJETA.
Cuyo efecto es: BLOQUEO DE LA TARJETA.
Si en el caso de 5 das, el titular recupera la tarjeta y lo notifica, se
desbloquea la misma y puede operar normalmente con ella, si no, se borra
la tarjeta y el titular tendra que solicitar otra.
Esto se representa como indica la figura:

Se indica mediante Q: el estado en que se encuentra la entidad y
mediante R el estado a que salta, esto significa que el evento que sigue
en secuencia a la caja sealada con Q, es siempre la caja
sealada con R.
En el caso de que hubiese "saltos" entre varias cajas, se distinguirn
utilizando la notacin QX y RX siendo X un nmero.

Indicadores de estado
Sirven para determinar el estado de una entidad antes y despus de ser
actualizada por un evento, as como para entender la secuencia de los
acontecimientos y definir los posibles errores del sistema.
La convencin para designar los indicadores de estado es comenzar con el
valor 1 e incrementarlo cada vez que un evento afecta a la entidad.

77

Para cada caja que indica el efecto de un evento sobre la entidad de que se
trata, se pueden definir una serie de valores de los indicadores de estado de
la entidad, para los cuales dicho evento puede actuar sobre la entidad.
En el diagrama se representar de la forma X/Y, donde X indica el o los
posibles estados en que se debe encontrar la entidad para que el evento
pueda actuar sobre ella, e Y indica el estado en que se encuentra la entidad
despus de que el evento haya actuado.
En la figura se muestra un ejemplo de los indicadores de estado en una
HVE.

PASOS EN LA CONSTRUCCIN DE LA HISTORIA DE LA VIDA DE LAS
ENTIDADES (HVE)

A continuacin se indican los pasos a seguir en la construccin de las HVE:
1. Identificacin de los eventos.
2. Construccin de la Matriz Entidad-Evento.
3. Construccin de HVE iniciales para todas las entidades.
4. Refinamiento de las HVE.
5. Adicin de los indicadores de estado.
Seguidamente se describirn en detalle cada uno de estos pasos.
Con el fin de clarificar cada uno de los pasos se estudiar el ejemplo siguiente:
El caso en estudio es una empresa de alquiler de vehculos, en la cual se
quiere mecanizar todo el proceso de reservas con el fin de agilizar la
tramitacin de las mismas.

78

En el mdulo EFS (Estudio Funcional del Sistema) del anlisis del sistema se
ha obtenido el siguiente Diagrama de Flujo de Datos:

1. IDENTIFICACION DE LOS EVENTOS
El punto de partida para la elaboracin de las HVE ser la identificacin de los
eventos a partir de los DFD. Estos eventos causarn la creacin de la entidad,
su modificacin y, al final, el borrado de la misma.
El cumplimiento de los requisitos establecidos por el usuario, el estudio de los
atributos de las entidades de datos, as como el estudio de los Diagramas de
Estructura de Datos nos servirn de ayuda y comprobacin de que se han
considerado todos los eventos que afectan a las entidades del sistema.
Para el caso en estudio que estamos siguiendo, a partir del estudio del DFD
representado y de los procesos de asignacin de conductores, se han
detectado los siguientes eventos:
E1: Solicitud de reserva.
E2: Solicitud de reserva efectuada por cliente nuevo.
E3: Solicitud de confirmacin de reserva.
E4: Asignacin de un conductor a la reserva.

79

2. CONSTRUCCION DE LA MATRIZ ENTIDAD-EVENTO
La matriz entidad-evento es una tabla de la forma:
En las intersecciones fila/columna se coloca el efecto de un evento sobre la
entidad. Dichos efectos pueden ser:
I (Insertar)
M (Modificar)
B (Borrar)
A la hora de considerar los eventos y sus efectos sobre las entidades ser
de utilidad el estudio de los Diagramas de Estructura de Datos (DED), dado
que permiten estudiar las posibles repercusiones que los eventos que
actan sobre una entidad tienen en las entidades relacionadas con ella, y
viceversa. Un ejemplo de esto lo constituye el caso en que un evento o
suceso, que provoca el borrado de una ocurrencia de una entidad borra,
asimismo, las ocurrencias de otra entidad asociada a la primera.
Para tener en cuenta lo anterior, se recomienda iniciar la representacin de
las HVE, para aquellas entidades que, en el DED, aparecen representadas
con una o varias entidades "maestro" y sin entidades "detalle". Una entidad
"maestro" es aquella que est en el extremo 1, y una entidad "detalle" es la
que est en el extremo n, en una relacin (1:n).
A continuacin se seleccionaran los "maestros" de estas entidades y as
sucesivamente, hasta que se alcanzasen las entidades sin entidad
"maestro" asociada.
Este mtodo, "de abajo a arriba", de estudio de los efectos de los eventos
sobre las entidades, proporciona informacin adicional sobre los posibles
efectos que los eventos que actan sobre la entidad detalle pudieran tener
sobre las entidades "maestro", lo que facilita la construccin de la HVE de
dichas entidades maestro. En la figura siguiente se representa este mtodo.

80

Es conveniente revisar la matriz entidad-evento para comprobar que:

Para cada entidad, hay al menos un evento que la crea.

Se satisfacen todos los requisitos de usuario.

Todos los eventos estn identificados.
La parte de la Matriz entidad-evento para el caso que nos ocupa ser:

Donde para completar esta matriz, se han tenido en cuenta los siguientes
requisitos que ha de cumplir el sistema:
R1: Una vez que se hace la reserva, se asignar un conductor de la
empresa a este sistema.
R2: Una vez que se haya asignado el vehculo se confirmar la reserva
provisional.
3. CONSTRUCCION DE HVE INICIALES PARA TODAS LAS ENTIDADES.
Para ello se selecciona, de la matriz entidad-evento, una entidad y los
eventos que la afectan, y se representa grficamente la HVE, ordenando los
eventos segn los tres tipos de efectos (I,M,B), incluyendo selecciones e
iteraciones, dibujando nodos con el fin de estructurar mejor el grfico, y, en
fin, introduciendo saltos y estructuras paralelas, si es preciso.

81

La HVE obtenida para la entidad reserva, a partir de la matriz construida en
el caso anterior, ser:

El diagrama ilustra la utilizacin de las cajas vacas dentro de una estructura
de seleccin: Dentro de la solicitud de reserva de alquiler de vehculos, se
indica si se requiere o no un conductor.
En este caso es preciso representar las dos posibilidades, es pues una
estructura de seleccin, una de las posibilidades implica la actuacin del
evento "Asignacin de conductor", la otra posibilidad no implica ninguna
variacin sobre la entidad, por ello se representa mediante una caja vaca.
4. REFINAMIENTO DE LAS HISTORIAS DE LA VIDA DE LA ENTIDAD
Para ello se estudiarn en detalle los atributos que definen a la Entidad de
Datos para ver si todos estos atributos son creados por algn evento.
La Entidad de Datos Reserva, del ejemplo que se est siguiendo, tiene los
siguientes atributos:
RESERVA
. N de Reserva (1)
. N de Cliente (2)
. Categora del vehculo (3)
. Fecha de recepcin (4)
. Fecha de confirmacin (5)
. Fecha de comienzo (6)
. Fecha de fin (7)
. Conductor requerido/NO (8)
. N de conductor (9)
. N de factura (10)
Es conveniente plantear las siguientes preguntas para refinar la HVE:

Estn todos los atributos de la entidad creados por algunos de los
eventos identificados hasta ahora?

82

Parece evidente que todos los atributos, excepto nmero de factura,
han sido creados por los eventos:

Solicitud de Reserva: que introduce en el sistema los atributos
(1) (2) (3) (4) (6) (7) (8).

Confirmacin de Reserva, que introduce en el sistema el
atributo (5).

Asignacin de Conductor, que, en el caso de que se requiera
conductor, introduce en el sistema el atributo (9).
Se introducir pues, en la HVE de la entidad Reserva el
Evento:

Envo de factura, que introduce en el sistema el atributo (10).
La nueva HVE quedara como indica la figura:

Otra cuestin a estudiar para completar las HVE es considerar los
posibles cambios que pueden sufrir los elementos una vez que se
han creado. De la consideracin de los posibles cambios surge la
definicin de nuevos eventos.
As por ejemplo, en el caso que nos ocupa se podran considerar
cambios hechos por el cliente en los detalles de la reserva, como por
ejemplo alterar las fechas de comienzo y el fin de la misma,
exigiendo, como requisito del sistema, una confirmacin posterior.
De la consideracin de este nuevo evento:
PETICION DE CAMBIO
se construira la HVE como muestra la figura.

83

Donde se ha dado una estructura de iteracin, dado que los cambios
pueden ocurrir varias veces en el tiempo.

Adems se deben considerar los requisitos del sistema en cuanto al
borrado de las entidades, as por ejemplo, diversas consideraciones
legales o exigencias de usuario podran requerir que se guardase
informacin sobre la entidad durante un determinado tiempo antes de
su borrado. Esto implicara considerar un nuevo evento: Archivo. En
nuestro caso ejemplo existe como requisito de usuario el guardar
informacin sobre la entidad para referencias futuras. Con esto la
HVE sera como indica la figura:

Por ltimo, una vez construidas las HVE de este modo, se
completarn invirtiendo el mtodo de construccin utilizado
anteriormente, es decir, siguiendo los Diagramas de Estructura de
Datos de "arriba a abajo", con el fin de estudiar el efecto que el
borrado de las ocurrencias de las entidades "maestro" tiene sobre las
entidades "detalle".
Este efecto se puede resumir del modo siguiente:

No hay ningn efecto, lo que implica que no hay cambios en la
HVE.

84

Si se borra la entidad "maestro" se borra la entidad "detalle":
los eventos que implican un borrado de la entidad "maestro",
han de figurar en la HVE de la entidad "detalle".

No se puede borrar la entidad "maestro" hasta que no se haya
borrado la "entidad detalle": los eventos que borran la entidad
"detalle" se debern colocar antes del final de la HVE de la
entidad "maestro".
En el caso ejemplo que estamos siguiendo, se tiene la
siguiente "vista" del Diagrama de Estructura de Datos.

Si se borra la entidad CLIENTE, todas las reservas asignadas
desaparecen. La HVE quedara pues:


85

5. ADICION DE LOS INDICADORES DE ESTADO.
Por ltimo, para completar la HVE se aadiran los indicadores de estado,
como se ha explicado anteriormente.
El ejemplo que se est siguiendo quedara:

INTERRELACIN CON OTRAS TCNICAS

Una vez realizada la Historia de Vida de las Entidades del Sistema, habr que
asegurar la coherencia de la vista del sistema obtenido mediante esta tcnica,
Vista "evolutiva", con las dems vistas del sistema, vista "esttica", obtenida
mediante el Diagrama de Estructura de Datos (DED) y vista "dinmica"
obtenida con el Diagrama de Flujo de Datos (DFD).
Para ello habr que comprobar:

Que existe un proceso dentro de los DFD del sistema que trate cada uno
de los eventos identificados en la HVE.

Que el modelo de datos, representado mediante el DED, permita reflejar
las repercusiones que la actuacin de un evento sobre una entidad tiene
sobre otras entidades del sistema.
Esta interrelacin entre las tres vistas del sistema permite asegurar la
consistencia del anlisis y convierte a la tcnica de la Historia de la Vida de las
Entidades en una poderosa herramienta para asegurar la calidad de dicho
anlisis.
2.5. EL ANLISIS DE SISTEMAS SEGN LA METODOLOGA MTRICA V.3

Documento :
ftp://www.cc.uah.es/pub/Alumnos/I.T.I.G/analisis_de_aplicaciones_de_gestion/
ASI_Metrica3.pdf.

Apuntes AAG Tema2 2010

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apuntes AAG Tema2 2010

Загружено:

Авторское право:

Доступные форматы

Anlisis de aplicaciones de gestin TEMA 2

Вам также может понравиться