TEMA 4: ANÁLISIS ESTRUCTURADO

1. ANÁLISIS DE REQUISITOS DEL SISTEMA

Se va a realizar el siguiente paso del ciclo de vida, análisis del sistema, que
consiste en analizar los requisitos para centrarse en qué debe hacer el
sistema.

Con el análisis del sistema se pretende:

1º) organizar la información. Es decir, reflejar la información del

problema en un formato gráfico más fácil de manejar. Este formato hace
que los requisitos sean entendibles para el diseñador y a la vez facilita la
comunicación con el usuario.

2º) depurar todo aquello que no interesa y concentrarse en lo que

debe de hacer el sistema.

3º) sacar a la superficie y resolver posibles conflictos.

4º) dividir el problema en subproblemas más fáciles de resolver.

Toda aplicación se apoya en tres pilares o consta de tres partes principales:

a) PROCESOS. Son la parte funcional de la aplicación. Reflejan las

funciones o tareas que debe realizar la aplicación.

b) DATOS. Son la parte estática de la aplicación. Se refieren a la

información que se necesita almacenar.

c) EVENTOS. Son la parte dinámica de la aplicación. Muestran los

aspectos del sistema que cambian con el tiempo. Provocan la
ejecución de la operación adecuada en cada momento. Son los
que se activan la aplicación y propagan esa activación a lo largo
de la ejecución de otras operaciones.

Los procesos dicen qué hay que hacer. Los datos indican con qué hay que
hacerlo. Y los eventos muestran cuándo hay que hacerlo.

Los tres pilares son complementarios, no tiene más importancia uno que
otro, se necesitan los tres. Para especificar cada uno de los tres pilares se
utilizan modelos. Un modelo es una representación abstracta de la realidad.

Por lo tanto, como resultado del análisis se obtendrán:

a)Modelo de procesos. Recoge qué funciones, actividades, tareas,

acciones debe realizar la aplicación y cómo manejar los datos.
 b)Modelo de datos. Describe la información que maneja la aplicación,
es decir, los datos que debe almacenar. Y muestra cómo organizarla.

c)Modelo de eventos. Indica en qué momento debe ejecutarse cada

acción.

2. ANÁLISIS ESTRUCTURADO DE PROCESOS

El modelo de procesos se obtiene a partir de los requisitos funcionales

recogidos en el catálogo de requisitos. Es esencial identificar procesos y
datos.

Existen diversas técnicas para facilitar la identificación de procesos y datos

a partir del catálogo de requisitos. La técnica más importante del análisis
estructurado de procesos es la de los diagramas de flujos de datos. (DFD)

Es una técnica gráfica y va en estrecha relación con las técnicas específicas

para describir datos (diccionario de datos) y procesos (especificaciones
formales).

2.1_ ÁRBOLES DE DECISIÓN

Como su nombre indica, se utiliza una estructura arborescente para

documentar un proceso de decisión. La raíz del árbol es el punto de
arranque, mientras que las ramas indican las decisiones que conducen a la
acción concreta según los casos.

EJ. | PROCESO: Descuento en compra según pago e importe.

IMPORTE > 1000 € _APLICAR 10%

PAGO CONTADO 500 € < IMPORTE < 1000 € __5%

* IMORTE < 500 €___________2%

PAGO INDIFERIDO _____________________________0%

2.2 TABLAS DE DECISIÓN

En las tablas de decisión relacionamos condiciones y acciones mediante lo

que se denomina REGLAS DE DECISIÓN que establecen las condiciones que
deben darse para ejecutar una acción. Es muy importante evitar
redundancias y contradicciones.

EJ. | Descuento en compra según pago e importe.

- PAGO AL CONTADO S S S N N N

- IMPORTE MAYOR 1000 € S N N S N N

- IMPORTE ENTRE 500 Y 1000 € N S N N S N

- IMPORTE MENOR 500 €

- APLICAR 10% DTO X

- APLICAR 5% DTO X

- APLICAR 2% DTO X

- APLICAR 0% DTO X X X

2.3 DIAGRAMAS DE FLUJO DE DATOS (DFD)

Un DFD es un diagrama en forma de red que representa el flujo de datos y

las transformaciones que se aplican sobre ellos al moverse desde la entrada
hasta la salida del sistema.

Los DFD están formados por símbolos que representan los componentes del
sistema. Las notaciones más comúnmente empleados son:

-Yourdon / de Marco

-Gane y Sarson

-Métrica. SSADM

Los componentes de un DFD son:

1º) Procesos _ son los componentes funcionales del sistema.

2º) Almacenes _ representan datos almacenados.

3º) Entidades externas _ representan la fuente y/o el destino de la
información del sistema.

4º) Flujos de datos _ representan los datos que fluyen entre las funciones.

1.GESTIÓ
N USUARIO
PRÉSTAM
BIBLIOTECA
RIO
PRÉSTAM
LIBRO
O
Alta/baja S

libro

3. GESTIÓN 2.GESTIÓN
ALTAS- DEVOLUCI
BAJAS ÓN

3 .ANÁLISIS ESTRUCTURADO DE DATOS

En el modelo de datos debe aparecer reflejada aquella información del

mundo real de interés para la aplicación. Se pretende que este modelo
contenga aquellos conceptos que representan a dicha información.

El modelo de datos representa la parte estática de la aplicación. Por ello se

fija única y exclusivamente en los datos. Un dato es toda aquella
información que la aplicación debe recordar.

Para desarrollar el modelo de datos se parte del modelo de procesos.

El modelo entidad/relación es la técnica de análisis y especificación de datos

más ampliamente utilizada, que se ubica en el plano conceptual pues
consiste en diseñar el sistema de información sin considerar ningún
concepto ligado a la organización de la empresa, desde el puto de vista de
los datos. Es un modelo gráfico de representación y por ello se tiene que
completar con documentación adicional en forma de texto (diccionario de
datos).

3.1 DICCIONARIO DE DATOS

 Un diccionario de datos contiene información sobre los datos utilizados en
un sistema y se desarrolla con los documentos recesados y el análisis de
flujo de datos.

El DD contiene dos tipos de descripciones dentro del sistema:

1º) Elementos de datos

2º) Estructuras de datos.

Los elementos de datos se agrupan para formar una estructura de datos.

3.1.1 ELEMENTO DATO O CAMPO

Son los bloques básicos para todos los demás datos del sistema. Por sí
mismos no conllevan suficiente significado para ningún usuario.

-DESCRIPCIÓN DE LOS ELEMENTOS DATO

Cada entrada en el DD consiste de un conjunto de detalles que describen

los datos utilizados o producidos por el sistema. Cada uno está identificado
con:

1º) Un número y un nombre_ Para distinguir un dato de otro, los

analistas les asignan nombres que sean significativos.

Además se le asigna un número que identifique al dato. Este será único.

2º) Descripción de los datos_ La descripción de un dato indica de

manera breve lo que este representa en el sistema.

3º) Estructura (tipo de dato y longitud)_ El tipo de dato indica de qué

tipo es el dato: alfabéticoA, alfanuméricoX, numérico9.

La longitud identifica el número de letras, números o símbolos necesarios

para cada dato.

4º) Tipo_ indica cómo se obtiene el valor del dato: Elemental (E) o
Concentrado (C), Memorizado (M) o Calculado (Cl).

5º) Valores de datos_ En algunos procesos sólo son permitidos valores

muy específicos para los datos.

6º) Ejemplos_ Contienen algunos ejemplos de valores posibles del

dato.

7º) Comentarios_ Aclaración sobre el dato.

Nº NOMBRE DESCRIPCI ESTRUC TIPO VALORES EJEMPLOS COMENTAR

ÓN TURA DE LOS IOS
DATOS
1 DOMIPR Domicili X (30) Concatena C/Gaabilond Está
O o del do/Memoriz o. compues
proveed ado Av. De ta por C/
 or Segovia 15 o Ctra. O
Av. O
Plza.
2 EDADCL Edad del 9 (3) Elemental / 20, 80, 100 La edad
I cliente Memorizad tiene que
o ser >=
18

3.1.2 ESTRUCTURAS DE DATOS

Es un grupo de datos elementales que están relacionados con otros y que

en conjunto describen un componente del sistema.

Existen dos tipos de estructuras de datos: las entidades tipo y las relaciones
tipo.

a) DESCRIPCIÓN DE LAS ESTRUCTURAS DE DATOS (Entidades tipo)

.Nombre_ Para distinguir una estructura de otra se le asignan nombres que

sean significativos.

.Descripción_ Indica de manera breve lo que éste representa en el sistema.

.Contenido_ Se indican los números y nombres de todos los datos que

contiene la estructura. Además hay que subrayar los datos que identifican a
la estructura.

.Longitud_ Se indica la suma de las longitudes de los datos que forman la

estructura de datos.

EJ. ||

NOMBRE DESCRIPCIÓN CONTENIDO LONGITUD

Productos con los 31 IDENPRO
PRODUCTO que trabaja el 32 DESIPRO 54
almacén 33 UNIPRO
29 PREUNI

b) DESCRIPCIÓN DE LAS ESTRUCTURAS DE DATOS (Relaciones tipo)

Nos permiten relacionar entidades tipo. Cada una se identifica por:

.Nombre_ para distinguir una estructura de otra. Se le asignan nombres que

sean significativos, normalmente verbos.

.Descripción_ indica de manera breve lo que este representa en el sistema.

.Entidades tipo_ se indican los nombres de las entidades_ tipo que relaciona
.Cardinalidad_ indica el número de veces en las que cada valor de una
entidad tipo participa en una estructura.

.Contenido_ se indican los números y los nombres de todos los datos que
contiene la estructura.

.Longitud_ indica las sumas de las longitudes de los datos que forman la
estructura de datos.

EJ.||

NOMBR DESCRIPCIÓN ENTIDADES_TIPO CARDINALIDA CONTENID LONGITU

E D O D
Los . Entrenadores 0,1
Entrena entrenadores 40 2
n entrenan a . Equipos 1, n NUMAÑOS
equipos

3.2 MODELO CONCEPTUAL DE DATOS_ MODELO ENTIDAD/RELACIÓN

(E/R)

a) ENTIDAD_ se puede definir como aquel objeto (real o abstracto) acerca

del cual queremos almacenar información. Denominaremos a la estructura
genérica, en su sentido abstracto tipo de entidad, mientras que entidad será
cada una de las ocurrencias o instancias de este tipo de entidad.

La representación gráfica de un tipo de entidad es un rectángulo etiquetado

con el nombre de entidad.

LIBROS EJ.

Tres reglas generales que debe de cumplir cualquier entidad son:

1º Tiene que tener existencia propia.

2º Cada ocurrencia de un tipo debe poder distinguirse de las demás.

3º Todas las ocurrencias de un tipo de entidad deben tener los

mismos tipos de características (atributos).

Existen dos clases de tipos de entidades:

1) Regulares o fuertes, que tienen existencia por ellas mismas.

2) Débiles, cuya existencia depende de otro tipo de entidad. Los tipos de
entidad débil se representan con dos rectángulos concéntricos con su
nombre en el interior.

EJ.
PISOS

b)RELACIÓN _ Se entiende por relación a la estructura genérica del conjunto

de relaciones existentes entre dos o más tipos de entidad.

Se denomina grado del tipo de relación al número de tipos de entidades que

participa en él.

El tipo de relación se representa mediante un hexágono etiquetado con el

nombre de la relación, unido mediante arcos a los tipos de entidad que
asocia.

AUTORES LIBROS
escribe

Entre dos tipos de entidades puede existir más de un tipo de relación.

AUTORES

ESCRIBE EDITA
N N

LIBROS

c)ELEMENTOS DE UN TIPO DE RELACIÓN

En un tipo de relación existen los siguientes elementos.

 1 Nombre que lo distingue del resto de los elementos del mundo
E.R

2 Grado. Número de tipos de entidad que participan en el tipo de

relación. Pueden ser de grado 1, 2, 3, etc.

3 Cardinalidad. El número máximo de ocurrencias de cada tipo de

entidad que pueden intervenir en el tipo de relación tratada. Para
representarlo gráficamente se ponen flechas y etiquetas que representan
1:1, 1:n, n:m, según corresponda a ocurrencias uno a uno, uno a muchos o
muchos a muchos respectivamente.

*) Cardinalidad 1:1 Cuando en la relación solo puede aparecer

como máximo una ocurrencia del tipo de entidad por cada ocurrencia del
otro.

*) Cardinalidad 1:n Si para uno de los tipos de entidad puede

haber un número indefinido (>1) de ocurrencias.

*) Cardinalidad n:m Si para ambos tipos de entidad hay un

número indefinido (>1) de ocurrencias.

Para representar gráficamente los distintos tipos de cardinalidades, se

puede poner una etiqueta que lo indique al lado del hexágono que
representa el tipo de relación y, un punta de flecha hacia el tipo de entidad
que participa con una ocurrencia en la relación y con dos puntas de flecha
hacia el tipo de entidad que participa con más de una ocurrencia en la
relación.
 4 Papel o Rol. Es la función que cada uno de los tipos de entidad
realiza en el tipo de relación. El nombre del papel se suele colocar junto al
arco que cada tipo de entidad con el tipo de relación.

D )ATRIBUTO, DOMINIO, CLAVE: Un tipo de entidad o de relación tiene

distintas propiedades o características (atributos) que pueden tomar
diferentes valores por cada ocurrencia de 1 tipo de entidad relación.
El conjunto de todos los posibles valores que puede tomar cierta
característica se denomina dominio.

La representación gráfica de un atributo consiste en el nombre del

atributo en el interior de la entidad tipo o en la relación tipo.

Entre los atributos de un tipo de entidad debemos elegir 1 o varios

que identifiquen unívocamente cada una de las ocurrencias de este
tipo de entidad. Ese atributo o conjunto de atributos se denomina
clave principal , clave primaria o identificador, y los atributos que lo
componen deben ser mínimos en el sentido de que la eliminación de
cualquiera de ellos le haría perder su carácter identificador. Puede
ocurrir que exista más de un conjunto de atributos que sea
identificador univoco y mínimo para un tipo de entidad, por lo que
denominaremos a cada uno de ellos como una clave candidata. De
todos modos solo se elige uno como clave principal.

Los atributos que forman la clave principal se representan de la

misma forma, pero con el nombre del atributo subrayado.

De la misma forma que se diferencian entidades hay que diferenciar

relaciones. La clave de un tipo de relación está formada por los
identificadores de los tipos de entidades participantes y no se
representa en el modelo.
E ) CONTROL DE REDUNDANCIAS EN LOS DIAGRAMAS E/R: Una vez
construido un diagrama entidad-relación hay que analizar si
presentan redundancias ya que puede acarrear problemas. Además
de la existencia de atributos redundantes, como los que derivan de
otro mediante algún cálculo, hay que estudiar detenidamente los
ciclos en el diagrama entidad-relación ya que pueden indicar la
existencia de relaciones redundantes.

Un ciclo en un diagrama E/R es un grupo de tipos de entidad unidos

en forma circular o cíclica a través de ciertas relaciones.
Se puede decir como norma general que la existencia de un ciclo no
implica la existencia de relaciones redundantes. Habrá que analizar
si, al eliminar una relación tipo, es siempre posible el paso, tanto en
un sentido como en el inverso, entre las 2 entidades tipo que
relaciona, y habrá que comprobar también que no pierden atributos al
eliminar la relación tipo.

F)CONSIDERACIONES: No es posible garantizar de ninguna forma que

un modelo entidad-relación propuesto es correcto. Se podrá decir que
se ajusta o no a las reglas de construcción del modelo pero no se
puede saber si la traducción de la realidad es correcta. Será el
usuario el que tendrá que validar este modelo, por lo tanto tiene que
ser auto-explicativo, para que se pueda entender.

G ) REGLAS PARA LA CONSTRUCCIÓN DEL MODELO ENTIDAD /

RELACIÓN (E / R):

1. Los tipos de entidad son sujetos pasivos y se les nombra

con un nombre.

2. Los tipos de relación indican actividad y se les nombra con

un verbo.
3. La organización que se está modelando no debe aparecer
en el modelo entidad relación.

4. Si un valor de un atributo es importante en mi modelo,

dicho atributo puede ser modelado como un tipo de entidad.

5. Muchas veces en relaciones tipo 1:N se tiende a poner

atributos de los tipos de relación en los tipos de entidad.

6.

7. En algunas ocasiones se tiende a poner un atributo fecha en

el tipo de relación cuando tendría que ser un tipo de
entidad.
3.3 MODELO DE ENTIDAD / RELACIÓN EXTENDIDO.

Las extensiones al modelo de entidad / relación más interesantes por

su funcionalidad y uso son :

3.3.1. Cardinalidad de un tipo de entidad:

Se define como el número máximo y mínimo de ocurrencias de un

tipo de entidad que pueden estar relacionadas con una ocurrencia de
otro u otros tipos de entidad que participan en la relación. Su
representación grafica es una etiqueta del tipo: (0,1),(1,1),(0,N),(1,N).
Según corresponda el significado de cada una es:

-(0,1): Para una ocurrencia determinada de los otros tipos de

entidades que participan en la relación, el valor mínimo de
ocurrencias de la entidad que se trata es cero y el número máximo es
1.

-(1,1): Para una ocurrencia determinada de los otros tipos de

entidades que participan en la relación, debe existir una, y solo una,
ocurrencia de la entidad que se trata.

-(0,N): Para una ocurrencia determinada de los otros tipos de

entidades que participan en la relación, el valor mínimo de
ocurrencias de la entidad que se trata es cero y el número máximo es
N.

-(1,N): Para una ocurrencia determinada de los otros tipos de

entidades que participan en la relación, debe existir como mínimo
una ocurrencia de la entidad que se trata, no habiendo límite en el
número de veces que dicha ocurrencia puede aparecer en la relación.
3.3.2.Dependencia en existencia y en identificación:

Como en el caso de los tipos de entidad, los tipos de relación se

clasifican también en regulares y en débiles, según estén asociados 2
tipos de entidades regulares o un tipo de entidad débil, con un tipo de
entidad regular respectivamente.

Dentro del tipo de relación débil hay que distinguir:

1. Dependencia en existencia: Cuando las ocurrencias de un tipo de

entidad, entidad débil, no pueden existir si desparece la ocurrencia
de la entidad regular de la cual depende. El hexágono que representa
la relación tipo va etiquetado con una “E”.

2. Dependencia en identificación: Cuando además de cumplirse la

condición anterior, las ocurrencias de tipo entidad débil no se pueden
identificar únicamente mediante los atributos propios de la misma y
exigen añadir la clave del tipo de entidad regular de la cual
dependen. El hexágono que representa la relación tipo va etiquetado
con “id”.

3.3.3. Relaciones tipo exclusivas:

 Decimos que 2 o más tipos de relación son exclusivos cuando cada
ocurrencia de un tipo de entidad solo puede pertenecer a un tipo de
relación.

3.3.4. Generalización y Herencia:

La descomposición de tipos de entidad en varios subtipos es una

necesidad muy habitual en el modelado. La relación que se establece
entre un supertipo y sus subtipos corresponde a la noción de “Es un”
del inglés (“Is A”)

Este tipo de relación especial se representa a través de un triángulo

invertido con la base paralela al rectángulo que representa al
supertipo y conectado a sus subtipos.

Una característica muy importante de esta clase de interrelaciones es la

herencia, ya que en principio todo atributo del supertipo pasa a ser
un atributo del subtipo.

En este tipo de abstracción los atributos comunes a todos los subtipos se

asignan al supertipo mientras que los atributos específicos se asocian
al subtipo correspondiente. Del mismo modo las relaciones que
afectan a todos los subtipos se asocian al supertipo dejándose para
los subtipos las relaciones específicas para cada uno de ellos. Por lo
tanto un instancia de un subtipo hereda:

1. Todos los atributos del supertipo de entidad.

2. Toda relación tipo en la que participa el supertipo.

La división en subtipos puede venir determinada por una condición

predefinida, en cuyo caso se representará la condición indicando el
atributo discriminante asociado al triángulo que representa la
relación.

Se pueden distinguir cuatro clases de generalización, atendiendo a si

los subtipos se solapan o son disjuntos, y si la unión de los subtipos
recubre o no el supertipo (total o parcial). Representaremos por un
arco el hecho de que los subtipos sean disjuntos y con un circulo la
presencia de una jerarquía total.

Subtipos disjuntos: Si una instancia del supertipo puede ser miembro

de, como máximo, uno de los subtipos.
 Subtipos solapados: Si una instancia del supertipo puede ser a la vez
miembro de más de 1 subtipo.

Especialización total: Indica que toda instancia del supertipo también

debe ser instancia de algún subtipo.

Especialización parcial: Indica que es posible que alguna instancia del

supertipo no pertenezca a ningún subtipo.

3.3.5. Relaciones –tipo ternarias (Grado 3)

Lo habitual es encontrar relaciones tipo binarias en los modelos de

entidad relación. Sin embargo pueden existir relaciones tipo de orden
superior, aunque siempre es conveniente tratar de reducirlas a tipo
binarias siempre que sea posible.
3.3.6. Relaciones-tipo repulsivas:

Puede suceder que dentro de un mismo tipo de entidad, dos

entidades estén relacionadas entre sí.

Sea el tipo de entidad empleado, dentro de este habría empleados

que sean jefes de otros empleados:

El problema en la representación de estas relaciones, es poder

diferenciar las entidades que son superiores y las entidades que son
inferiores. Una solución es utilizar IsA, es decir, construir
subconjuntos ateniendo al papel que juega cada entidad dentro de la
relación.
 4. ANÁLISIS ESTRUCTURADO DE EVENTOS

- Evento es un suceso que ocurre y que el sistema debe detectar y dar

una respuesta.

Algunos ejemplos de sucesos son: mover el ratón, presionar una tecla, etc.,
son sucesos de bajo nivel. Mientras que baja de un usuario, introducción de
un nuevo dato, etc., son sucesos de alto nivel.

El modelo de eventos se va a centrar principalmente en los sucesos de alto

nivel.
Del conjunto de sucesos que ocurren, un evento es solo aquel suceso que
importa la aplicación, la cual debe detectarlo y reaccionar ante él. Nunca se
debe quedar parada la ejecución por la llegada de un evento no esperado.

La importancia de los eventos radica en que llevan el control de la

aplicación, introduciendo el dinamismo necesario para su ejecución.

Con el modelo de eventos se describe la parte dinámica de la aplicación.

Para obtener dicho modelo se debe:
 1º) Identificar los eventos e incluirlos en un catálogo de eventos.
Para ello se parte del modelo de procesos.

2º) Construir la matriz entidad evento. Para cada evento se observa a

qué entidad tipo o relación tipo afecta y cual es el efecto que produce.
(Inserción, modificación o borrado)