Temario Oposición a

Técnicos Auxiliares de Informática

(BOE 03 NOV 2015)

Considerando los Reyes, de gloriosa memoria, cuánto era provechoso e honroso

que a estos sus Reinos se truxiesen libros de otras partes, para que con ellos se
ficiesen los hombres letrados, quisieron e ordenaron: que de los libros non se
pagase alcabala, y porque de pocos días a esta parte, algunos mercaderes
nuestros, naturales y extranjeros, han trahido y cada día trahen libros mucho
buenos, lo cual, por este que redunda en provecho universal de todos, e
ennoblecimiento de nuestros Reinos; por ende, ordenamos e mandamos que,
allende de la dicha franquiza, de aquí en adelante, de todos los libros que se
truxeren a estos nuestros Reinos, así por mar como por tierra, non se pida, nin se
pague, nin lleve almoxarifazgo, nin diezmo, nin portazgo, nin otros derechos algunos
por los nuestros Almoxarifes, nin los Desmeros, nin Portazgueros, nin otras
personas algunas, así como las cibdades e villas e lugares de nuestra Corona Real,
como de Señoríos e órdenes e behenias; más que de todos los dichos derechos o
almoxarifazgos sean libres e francos los dichos libros.
Orden de los Reyes Católicos

1
 TODOS LOS TEXTOS DE ESTOS APUNTES LLEVAN LA
SIGUIENTE LICENCIA, EXCEPTO SI SE INDICA LO CONTRARIO

Edición: 1ª Edición Julio 2.015

Título: Temario Oposición a Técnicos Auxiliares de Informática

Autor: http://apuntedecaramelo.blogspot.com.es/

2
TEMA 1. MODELO CONCEPTUAL DE DATOS. ENTIDADES, ATRIBUTOS Y RELACIONES. REGLAS DE
MODELADO. DIAGRAMA DE FLUJO DE DATOS. REGLAS DE CONSTRUCCIÓN. DESCOMPOSICIÓN
EN NIVELES. FLUJOGRAMAS

1. INTRODUCCIÓN
2. MODELO CONCEPTUAL DE DATOS
3. ENTIDADES, ATRIBUTOS Y RELACIONES
4. REGLAS DE MODELIZACIÓN
5. DIAGRAMA DE FLUJO DE DATOS
6. REGLAS DE CONSTRUCCIÓN
7. DESCOMPOSICIÓN EN NIVELES
8. FLUJOGRAMAS

144
1. INTRODUCCIÓN
Para desarrollar un SI, lo primero es saber qué hace, para modelarlo, es decir, describir su arquitectura:
estructura y funcionalidad. Es decir, su modelo estructural (caja blanca) y funcional (caja negra). En un SI, el
modelo estructural, los componentes se asocian a los datos. El funcional, a las operaciones (métodos, etc.).
La definición de la arquitectura (el modelado) de un SI se puede hacer a partir de cualquiera de ambos
modelos; es decisión del analista. En general, se hace poco a poco, en paralelo. Pero, suele ser mejor
incidir más en el modelado estructural; los datos; porque da mayor estabilidad temporal. El modelo funcional
es más volátil. Efectivamente, en un sistema es más probable que varíen sus operaciones que sus datos.
Por eso, el enfoque del sistema desde la perspectiva de datos asegura la continuidad de la arquitectura sw.
El modelado, así, comienza con la captura de requisitos: qué hace el sistema. Un requisito representa una
funcionalidad del sistema por eso se habla de “requisitos funcionales”. Como se suelen obtener del usuario,
también se los refiere a veces y por abuso, como “requisitos de usuario”.
Los requisitos funcionales hay que detallarlos: analizarlos y describir sus condiciones iniciales, finales,
caminos alternativos, etc. Este análisis suele hacerse con la técnica de “Casos de Uso”. Un caso de uso
puede definirse como el detalle de un requisito funcional de un SI. En el fondo una secuencia de acciones
del SI con un fin; representa su comportamiento. Si un caso de uso es complejo, como siempre, a dividir
para vencer. Especificar casos de uso puede usar técnicas distintas: texto, diagramas, etc.
Hasta aquí, se comienza el modelado desde el punto de vista funcional. Los métodos de diseño clásico
usan el enfoque top-down. Esto particulariza más la especificación del SI, no favoreciendo la reutilización. Si
lo favorece un enfoque más extendido por combinación de elementos, el enfoque bottom-up. El diseño top-
down es útil en programas pequeños y algoritmos simples. Sus ventajas son a corto plazo. El enfoque del
modelado conceptual de datos, estructural, ofrece compatibilidad, reutilización y persistencia.
El modelo conceptual de datos puede desarrollarse a partir de los casos de uso. Supone una primera idea,
una nebulosa oscura, que se va aclarando al identificar entidades, atributos y relaciones. El modelo se
representa con distintas técnicas, como los diagramas de flujo de datos.
Los estándares son métodos elaborados que usan técnicas. Como la AAPP es un referente, es lógico usar
su referencia, Métrica v3, una metodología de sistematización de actividades del ciclo de vida sw para
desarrollar un SI. Intenta obtener productos sw de calidad, con énfasis en el análisis de requisitos y mejorar
la productividad. Contempla aspectos de gestión para asegurar que se cumplen objetivos en términos de
calidad, coste y plazos. Identifica 4 interfaces como procesos de apoyo: Gestión de Proyectos,
Configuración, Aseguramiento de Calidad y Seguridad.
2. MODELO CONCEPTUAL DE DATOS
Dittrich, en el ámbito de las BBDD lo define por como el conjunto de herramientas conceptuales para
describir la representación de la información en términos de datos. El modelo conceptual de datos incluye
aspectos como estructuras y tipos de datos, operaciones y restricciones.
La acción de crear el modelo, el modelado conceptual, tiene por objeto identificar la información del mundo
real a representar: describe los datos del SI. Por tanto, el modelado conceptual se traza a la etapa de
análisis y se hace paralelo al modelado funcional.
El proceso abstrae detalles de implementación, que se abordan en la etapa de diseño (diseño estructurado
de datos). El modelado se hace con técnicas que lo facilitan, con características de capacidad semántica
alta y cercanía al humano. La técnica protagonista del diseño es el “Modelo relacional”.
La figura muestra la relación entre el
modelado conceptual (análisis) y el diseño
de datos en el proceso de desarrollo. La
diferencia, es que el análisis incluye también
el modelado funcional (procesos).
El modelado conceptual de datos, suele
usar la técnica relacional, que lo describe
con un dibujo: el diagrama entidad-relación.
El modelado conceptual de funciones, modelado de procesos o funcional sule usar las técnicas de casos de
uso y diagramas de flujo de datos (DFD). El conocimiento adquirido con el modelado de datos permite
comprender el por qué de los datos de una organización y, entonces, su funcionamiento. Permite obtener la
estructura de la información inherente, controlar errores o desviaciones y mejorar el mantenimiento.
Una estructura de datos sólida genera información consistente, accesible según la necesidad de cada
usuario, de forma inmune a cambios organizativos.

145
La técnica relacional se conoce como modelo entidad / relación (E-R). Se centra en los datos de forma
independiente a su proceso y consideraciones de bajo nivel. El objetivo es abstraer el entorno físico y
representar el SI para ofrecer la información necesaria en forma y tiempo. En la literatura se puede hablar
de modelo E-R extendido. Las diferencias radican en mejoras. El modelo (la técnica) identifica 3 elementos:
entidades, atributos y relaciones.
Preguntas de EXAMEN
Qué característica relacionada con los modelos conceptuales de datos es FALSA:
a) Representan la visión estática del dominio de la información del Sistema de Información a modelar
b) Ayudan a representar las necesidades del usuario
c) Representan toda la información que va a tratar el Sistema de Información objeto del análisis
d) Representan la estructura física de la información que maneja el Sistema de Información
Dada una relación N:M entre 2 entidades en el Modelo Conceptual de Datos de una aplicación, al
implementarla como relación normalizada en una BBDD relacional, cuántas tablas se necesitarán:
a) 1 b) 2 c) 3 d) 4
Qué modelo no es conceptual en el diseño de BBDD:
a) Modelo E/R b) Modelo RM/T c) Modelo semántico d) Modelo Codasyl
3. ENTIDADES, ATRIBUTOS Y RELACIONES
Los elementos fundamentales del modelo E-R son entidades, atributos y relaciones.
Entidad. Es el objeto, real o abstracto, sobre el que se desea almacenar información. La estructura genérica
de un conjunto de entidades (idea de objeto en POO) con las mismas características se llama tipo de
entidad (idea de clase en POO). Se identifican 2 tipos de entidades: regulares (existen por sí mismas, idea
de clase padre) y débiles (su existencia depende de otra; clase hija).
Las entidades cumplen 3 reglas: poseer existencia propia; cada ocurrencia de un tipo debe poder
distinguirse de las demás; y todas las ocurrencias de un tipo deben tener los mismos atributos.
Relación. Es una asociación entre una o varias entidades. Igual que las entidades, son regulares si asocian
entidades regulares o débiles si asocian una entidad regular con una débil.
Las relaciones débiles distinguen dependencia en existencia e identificación. Es en existencia si la entidad
débil no ocurre sin la ocurrencia de la regular de la que depende. Es en identificación si además de lo
anterior, el tipo débil no se puede identificar sólo con sus atributos; hay que añadir el identificador (clave) de
la regular de la que depende.
Además, se dice que una relación es exclusiva cuando la existencia de una relación entre entidades implica
la no existencia de las otras relaciones. Una relación se caracteriza por:
Nombre La distingue del resto
Correspondencia Máximo de ocurrencias de cada tipo de entidad que intervienen en una relación
Cardinalidad Número máximo y mínimo de ocurrencias de un tipo de entidad relacionada con
otra. La cardinalidad máxima es la correspondencia (o tipo de correspondencia)
Dada una relación, la correspondencia de cardinalidades puede ser:
Relaciones 1:1: Cada ocurrencia de una entidad se relaciona con una y sólo una de otra entidad
Relaciones 1:N: Cada ocurrencia de una entidad puede relacionarse con 0, 1 o varias ocurrencias de
la otra entidad
Relaciones M:N: Cada ocurrencia de una entidad puede estar relacionada con 0, 1 o varias
ocurrencias de la otra entidad y viceversa
Según la cardinalidad, una relación es obligatoria u opcional. Obligatoria si toda ocurrencia de un tipo de
entidad implica al menos una ocurrencia del tipo asociado. Opcional si para toda ocurrencia de un tipo de
entidad, pueden existir o no ocurrencias del tipo asociado.
Atributo. Es una propiedad de un tipo de entidad. Representa la unidad básica de información (dato) que la
identifica o describe. Un atributo se define sobre, o pertenece a un dominio. Cada tipo de entidad ha de
tener un conjunto mínimo de atributos que identifiquen unívocamente su ocurrencia. Es el atributo o
conjunto de atributos denominados identificador principal (la clave).

146
Se pueden definir restricciones sobre atributos, distinguiendo entre univaluados y obligatorios. El univaluado
sólo puede tomar un valor para cada una de las ocurrencias de su tipo de entidad. El obligatorio debe tomar
al menos un valor para todas y cada una de las ocurrencias de su tipo de entidad.
Dominio. Es un conjunto nominado de valores homogéneos. Tiene existencia propia con independencia de
entidad, relación o atributo. También: el conjunto posible de valores de un atributo.
Existen extensiones del modelo E-R que incorporan abstracciones para facilitar la representación de las
estructuras del mundo real:
Generalización. Permite abstraer a partir de tipos de entidad (subtipos), un tipo de entidad de nivel superior
(supertipo). Los atributos comunes y relaciones de los subtipos se asignan al supertipo. Por ejemplo, los
atributos comunes a un turismo, camión y autobús se pueden generalizar en un supertipo “vehículo”.
Especialización. Operación inversa a la generalización. Un supertipo se descompone en subtipos que
heredan todos los atributos y relaciones del supertipo e incorporan otros propios. Por ejemplo el supertipo
vehículo puede especializarse en los subtipos turismo, camión y autobús.
Categorías. Es el subtipo resultado de la unión de varios tipos de entidad. Por tanto, habrá varios supertipos
y un sólo subtipo. Por ejemplo, los supertipos persona y compañía, se relacionan con vehículo, se puede
crear propietario como un subtipo unión de los dos primeros.
Agregación. Construye un nuevo tipo de entidad como composición de otros y su tipo de relación. Permite
manejar un nivel de abstracción mayor. Por ejemplo, las entidades empresa y candidato se asocian con el
tipo de relación entrevista. Si una entrevista responde a una oferta de empleo, al no poder asociar tipos de
relación, se puede crear un tipo de entidad que englobe a las entidades empresa, candidato y su relación
entrevista y relacionarla con la entidad oferta de empleo. El proceso inverso se denomina desagregación.
Asociación. Consiste en relacionar 2 tipos de entidades que normalmente son de dominios independientes,
pero coyunturalmente se asocian.
Los supertipos y subtipos, dispuestos en niveles definen una jerarquía, que permite representar una
restricción del mundo real. Construido el modelo E-R, hay que analizar las redundancias. Para asegurar su
existencia se deben estudiar las cardinalidades mínimas y la semántica de las relaciones.
Los atributos redundantes derivados de otros elementos mediante algún cálculo, deben eliminarse del
modelo E-R o marcarse como redundantes. Las relaciones redundantes deben eliminarse, comprobando
que no afectan a las relaciones, en un sentido y el inverso.
Preguntas de EXAMEN
En el modelo E-R, el número de tipos de entidad que participan en un tipo de relación es:
a) Participación b) Grado c) Agregación d) Cardinalidad
Dentro del modelo E-R se puede definir el dominio de un atributo como:
a) El número mínimo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad
b) Es una correspondencia o asociación entre dos o más entidades con los mismos atributos
c) El conjunto de todos los valores posibles que puede tomar el atributo
d) El número de tuplas o filas de un atributo
En el modelo entidad-relación:
a) Sólo las entidades pueden tener atributos
b) Sólo las relaciones pueden tener atributos
c) Entidades y relaciones pueden tener atributos
d) Los atributos son independientes
Señale la respuesta FALSA con respecto al modelo E-R:
a) Permite establecer una visión global de los datos de un sistema a nivel de abstracción cercano al usuario
b) No tiene en cuenta restricciones de espacio de almacenamiento o tiempos de respuesta
c) Representa la visión estática del dominio de información de un problema
d) La representación obtenida es dependiente de las características del equipo donde se vaya a implantar

147
4. REGLAS DE MODELIZACIÓN

Entidad. Si es regular se representa con un Modelización de Entidad

rectángulo etiquetado con su nombre. Si es
débil se representa con un rectángulo dentro de
otro con su nombre en el interior.
Relación. Se representa con un rombo unido
con líneas a las entidades asociadas. La
Modelización de Relación
correspondencia se representa con una
etiqueta 1:1, 1:N o M:N, cerca de los vértices
del rombo o la entidad.
La representación de las cardinalidades usa
una etiqueta tipo (0,1), (1,1), (0,n) o (1,n), en el
extremo de la entidad. Si se representan
cardinalidades, el tipo de correspondencia es
redundante.
Atributo. Se representa con una elipse, con su Modelización de Atributo
nombre dentro, unida con una línea al tipo de
entidad o relación. En lugar de una elipse
puede usarse un círculo con el nombre dentro,
o un círculo más pequeño con el nombre del
atributo al lado. También pueden representarse
en una lista asociada a la entidad. El
identificador aparece con el nombre marcado o
subrayado o con su círculo en negro.
Exclusividad. En relaciones exclusivas se incluye un arco sobre las líneas que conectan el tipo de entidad
los 2 o más tipos de relación.
Jerarquía (tipos y subtipos). Se representa con un triángulo invertido, con la base paralela al rectángulo del
supertipo y los lados conectados a los subtipos. Si la división en subtipos se determina con valores de un
atributo discriminante, éste se representará asociado al triángulo.

Modelización de Exclusividad Modelización de Jerarquía

En el triángulo se representa con una letra “d” el hecho de que los subtipos sean disjuntos, con un círculo o
una “O” si los subtipos pueden solaparse y con una “U” el caso de uniones por categorías. La presencia de
una jerarquía total se representa con una doble línea entre el supertipo y el triángulo.

Jerarquía total Categoría (Unión) Subtipos no disjuntos Subtipos disjuntos

Ejemplo. Para clarificar los conceptos, se propone un ejemplo de modelado de datos con una notación
habitual, recomendada en Métrica v3, pero no obligatoria.

148
La figura muestra el modelo E-R extendido para un sistema
de gestión de técnicos y su asignación a proyectos en una
organización.
En el diagrama, la entidad TÉCNICO es un subtipo de
EMPLEADO, generado por especialización, necesario para
establecer la relación. Trabaja en PROYECTO. No todos
los empleados de la empresa trabajan en proyectos.
TÉCNICO heredará atributos de EMPLEADO más el
atributo nivel. Los tipos de correspondencia entre
DEPARTAMENTO y EMPLEADO son 1:N, pues un
departamento tiene 1 o varios empleados. Entre TÉCNICO
y PROYECTO, M:N, pues un técnico puede trabajar en 1 o
varios proyectos, y en un proyecto 1 o varios técnicos.
Se han incluido atributos que caracterizan la relación
“Trabaja en”, como la fecha de cese o asignación, ya que
un técnico puede trabajar en un proyecto en cierto periodo.
5. DIAGRAMA DE FLUJO DE DATOS
El diagrama de flujo de datos (DFD) es una forma abstracta de representar el modelo lógico de procesos
que representa el SI. Pretende facilitar la comprensión a usuarios y equipo de desarrollo.
El sistema se divide en distintos niveles de detalle para simplificar la complejidad de los procesos de que
consta y facilitar su mantenimiento.
La técnica del DFD es apropiada para reflejar los procesos que conforman el SI. Representa gráficamente
los límites del sistema y la lógica de procesos, estableciendo las funciones a desarrollar. Muestra el flujo de
datos y su transformación a través de los procesos del sistema. La técnica completa consiste en
descomponer sucesivamente los procesos, desde un nivel general, hasta uno de detalle que refleje la
semántica del sistema en estudio. El DFD se compone de los siguientes elementos:
Entidad externa. Representa un ente ajeno al SI que proporciona o recibe información. No se estudian
relaciones entre entidades externas. Puede aparecer varias veces en un mismo DFD o en distintos niveles
para mejorar la claridad.
Proceso. Representa una funcionalidad del sistema para manipular datos. El proceso generará los flujos de
datos de salida a partir de los de entrada, más información adicional del proceso. El proceso nunca es el
origen ni el final de los datos, puede transformar un flujo de datos de entrada en varios de salida y siempre
es necesario como intermediario entre una entidad externa y un almacén de datos.
Almacén de datos. Representa la información en reposo del sistema (ficheros, BBDD…). Contiene la
información necesaria para la ejecución del proceso. El almacén no puede crear, transformar o destruir
datos, no puede estar comunicado con otro almacén o entidad externa y aparecerá por primera vez en
aquel nivel en que dos o más procesos accedan a él.
Flujo de datos. Representa el movimiento de datos estableciendo la comunicación entre procesos y
almacenes de datos o entidades externas. Un flujo de datos entre dos procesos sólo es posible cuando la
información es síncrona, es decir, el proceso destino comienza cuando el proceso origen finaliza. Los flujos
de datos que comunican procesos con almacenes pueden ser de los siguientes tipos:
De consulta. Representan el uso de valores de uno o más campos de un almacén o la
comprobación de que los valores de los campos seleccionados cumplen unos criterios.
De actualización. Representan la alteración de los datos de un almacén como consecuencia de la
creación de un nuevo elemento, por eliminación o modificación de otros ya existentes.
De diálogo. Flujo entre un proceso y un almacén que representa una consulta o actualización.
Existen sistemas que precisan de información orientada al control de datos y requieren flujos y procesos de
control, así como los mecanismos que desencadenan su ejecución. Para que resulte adecuado el análisis
de estos sistemas, se ha ampliado la notación de los DFD incorporando los siguientes elementos:
Proceso de control. Representa procesos que coordinan y sincronizan actividades de procesos del DFD.
Flujo de control. Representa el flujo entre un proceso de control y otro. El flujo de control que sale de un
proceso de control activa al que lo recibe y le informa de la situación. A diferencia del flujo normal, el de
control no representa datos con valores, sino eventos que activan los procesos (señales o interrupciones).

149
6. REGLAS DE CONSTRUCCIÓN
Las reglas de construcción de DFD consisten en normas de notación para representar cada elemento.
Entidad externa. Se representa mediante una elipse con un identificador y un nombre en su interior. Si la
entidad se repite en un mismo DFD, se usa una línea inclinada en el ángulo superior izquierdo.

Representación de Entidad Externa Representación de Proceso

Proceso. Se representa por un rectángulo subdividido en tres casillas donde se indica el nombre del
proceso, un número identificativo y la localización. Si el proceso es de último nivel, se representa con un
asterisco en el ángulo inferior derecho separado con una línea inclinada.
El nombre del proceso debe ser representativo. Normalmente un verbo más sustantivo. El número
identificativo se representa en la parte superior izquierda e indica el nivel del DFD en que se está. No indica
orden de ejecución entre procesos ya que en un DFD no se representa secuencia de tratamiento de los
datos. El número que identifica el proceso es único en el sistema y sigue el siguiente estándar:
El proceso del diagrama de contexto se numera como cero
Los procesos del siguiente nivel se enumeran desde 1 y de forma creciente hasta completar el
número de procesos del diagrama.
En los niveles inferiores se forma con el número del proceso en el que está incluido seguido de un
número que lo identifica en ese contexto.
La localización expresa el nombre del proceso origen de la descomposición que se esté tratando.

Representación de Representación de Flujo de Datos Representación de Proceso

Almacén de Datos y Flujo de Control

Almacén de datos. Se representa con 2 líneas paralelas cerradas en un extremo y una línea vertical que las
une. En la parte derecha se indica el nombre del almacén de datos y en la izquierda su identificador en el
DFD. Si un almacén aparece repetido se puede representar con 2 líneas verticales entre el ID y el nombre,
como muestra la figura.
Flujo de datos. Se representa por una flecha
que indica la dirección de los datos etiquetada
con un nombre, como muestra la figura.
Proceso de control. Se representa por un
rectángulo, con trazo discontinuo, subdividido
en tres casillas donde se indica el nombre del
proceso, número identificativo y la localización.
Flujo de control. Se representa por una flecha
con trazo discontinuo que indica la dirección de
flujo y que se etiqueta con un nombre
representativo.
La figura muestra un ejemplo de un DFD de un
Sistema Gestor de Pedidos. Se representan
todos los elementos que pueden intervenir en
un DFD.
Con respecto a DFD, preguntas típicas de examen son:

150
Preguntas de EXAMEN
En relación a los DFD…
a) Todo proceso, independientemente del nivel del diagrama, debe tener al menos una entrada y una salida
b) Los procesos incluidos en el diagrama de nivel 0 pueden no tener entrada o salida
c) Los flujos de datos del DFD de nivel 0 pueden dividirse en varios en DFDs de niveles posteriores
d) Todos los flujos de datos deben terminar en un almacén de datos, o en un proceso
En los DFD NO existen los flujos de datos de:
a) Consulta b) Actualización c) Optimización d) Diálogo
Un Diagrama de Flujo de Datos (DFD) se compone de los siguientes elementos:
a) Entrada, Proceso, Conector, Almacen y Salida
b) Entidad Externa, Proceso, Almacén de Datos y Flujo de Datos
c) Entidad, Relación, Dominio y Atributo
d) Actores, Casos de Uso y Relaciones
Los flujos de datos que comunican procesos con almacenes en un DFD NO pueden ser:
a) De consulta b) De actualización c) De diálogo d) De control
7. DESCOMPOSICIÓN EN NIVELES
Los DFD representan el sistema y su construcción se basa en el principio de descomposición o explosión en
niveles de detalle. Se realiza de arriba abajo (top-down); del nivel general al detallado. Así se divide el
sistema para facilitar su estudio y desarrollo. La explosión de cada proceso de un DFD origina otro DFD que
obliga a mantener la consistencia entre ellos, es decir, la información de E/S de un proceso es la del DFD
en que se descompone. En una explosión puede aparecer un proceso que no necesite descomposición. A
éste se le denomina Proceso primitivo y sólo detalla su E/S y su función. Es bueno evitar la descomposición
desigual, es decir, que un nivel contenga un proceso primitivo, y otro explote en más niveles. El modelo de
procesos debe contener:
Un diagrama de contexto (Nivel 0)
Un diagrama 0 (Nivel 1)
Tantos diagramas 1, 2, 3... n como funciones haya en el diagrama 0 (Nivel 2)
Tantos niveles intermedios como sea necesario y varios DFD en el último nivel de detalle
Un diagrama de contexto limita el ámbito del SI con el
mundo exterior definiendo sus interfaces. Se representa
un único proceso (el sistema), entidades externas (la
procedencia y destino de la información) y flujos de datos.
El proceso que representa el SI se descompone en otro
DFD, para procesos principales o subsistemas (conjunto
de procesos con funcionalidades comunes). Se identifican
por criterios como funciones homogéneas de procesos,
organizativas o administrativas del sistema, localización
geográfica de los mismos, etc.
Cada proceso principal se descompone en otros que
representan funciones más simples. Se descompone
hasta que los procesos se detallen con una funcionalidad
concreta, es decir, sean procesos primitivos.  El resultado
es un modelo de procesos del SI formado por un conjunto
de DFD en niveles de abstracción, en que cada uno ofrece
una visión más detallada de una parte de nivel superior.
Además de los DFD, el modelo de procesos incluye flujos, almacenes de datos y detalle de procesos
primitivos, que debe incluir de manera más o menos formal, cómo obtener flujos de datos de salida a partir
de los de entrada y sus características. Según el tipo de proceso se puede describir usando un lenguaje
estructurado o pseudocódigo, apoyados en tablas o árboles de decisión. La figura muestra un ejemplo que
representa la descomposición jerárquica de los DFD.
151
8. FLUJOGRAMAS
Las técnicas descriptivas de algoritmos definen cómo trabaja el algoritmo, detallando pasos y proceso.
Sirven de ayuda en el diseño. Las técnicas usadas habitualmente son seudocódigo y flujogramas. En
general, se usa, por abuso de notación, el término de flujograma y DFD como sinónimos. La diferencia, un
tanto sutil, estriba en que el DFD se refiere a un nivel superior (análisis) y el flujograma describe también un
proceso, pero más particular, el de un algoritmo, que se programará (diseño).
La exposición de DFD expuesta está trazada con Métrica v3, como se indicó. La notación para flujogramas
está también normalizada. Siendo ortodoxos, un DFD sería la denominación general, dividida en 2 tipos:
organigramas y ordinogramas.
Los organigramas indican el flujo de datos de un sistema sin detalles. Responden a la idea de DFD que se
ha presentado.
Los ordinogramas detallan la secuencia de un algoritmo.
El seudocódigo consiste en escribir un algoritmo de forma PROGRAMA pares
intermedia entre lenguaje humano y uno de programación. Su
VARIABLES
esencia obviar detalles de implementación y centrar el diseño. No
existen estándares; basta aplicar la lógica, con claridad y típicas n : Entero
estructuras de programación.
EMPIEZA
Convenios de facto, podrían ser que las sentencias de control, se
codifiquen de forma similar a un lenguaje de programación. Por LEER n
ejemplo MIENTRAS [condición]… FIN-MIENTRAS; SI [condición] SI RESTO (N/2)==0 ENTONCES
ENTONCES… FIN-SI. Las primitivas pueden codificarse como
ESCRIBIR, LEER, etc. Para asignar valores, usar >, :=, →, etc. ESCRIBIR “el número es par”

Los subprogramas deben declararse de forma nítida. Por ejemplo SI NO

SUBPROGRAMA [nombre] […] FIN-SUBPROGRAMA. Los ESCRIBIR “el número es impar”
comentarios podrán ponerse entre asteriscos, /*, etc. A la
derecha se muestra un ejemplo de programa que identifica un FIN-SI
número par, realizado con seudocódigo. FIN-PROGRAMA
Un flujograma es un DFD de tipo ordinograma. Es un esquema visual que presenta la secuencia de proceso
de datos. Permiten representar varios niveles de concreción. Los organigramas usan símbolos para
representar soportes, E/S, dispositivos de almacenamiento, etc. y líneas de flujo que enlazan los soportes
con los procesos. Representan algoritmos al detalle. Cuentan con símbolos como los de inicio y fin (óvalo),
proceso (rectángulo), E/S (paralelogramo), alternativa (rombo), subprograma (rectángulo con lados
verticales dobles), conectores (círculos pequeños para unir líneas de flujo o páginas) y líneas de flujo. La
figura presenta los símbolos habituales, con su significado y un ejemplo de utilización de éstos símbolos.
Símbolo Significado Símbolo Significado

Inicio o fin del Proceso o

programa  instrucciones de
programa

Operación de E/S  Decisión o bifurcación

Líneas de flujo  Salida por impresora

Lazo o instrucción de control repetitiva.

Preguntas de EXAMEN
Respecto al seudocódigo:
a) No puede ser compilado, si interpretado b) Sirve para un lenguaje de programación dado
c) Se usa en la actividad Diseño físico de datos d) Permite codificar un programa con más agilidad

152