Anda di halaman 1dari 9

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

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).
147
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.

4. REGLAS DE MODELIZACIÓN
Entidad. Si es regular se representa con un
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
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
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.
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.

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

150

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.

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.

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:

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.

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
intermedia entre lenguaje humano y uno de programación. Su
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
estructuras de programación.
Convenios de facto, podrían ser que las sentencias de control, se
codifiquen de forma similar a un lenguaje de programación. Por
ejemplo MIENTRAS [condición]... FIN-MIENTRAS; SI [condición]
ENTONCES... FIN-SI. Las primitivas pueden codificarse como
ESCRIBIR, LEER, etc. Para asignar valores, usar >, :=, →, etc.
Los subprogramas deben declararse de forma nítida. Por ejemplo
SUBPROGRAMA [nombre] [...] FIN-SUBPROGRAMA. Los
comentarios podrán ponerse entre asteriscos, /*, etc. A la
derecha se muestra un ejemplo de programa que identifica un
número par, realizado con seudocódigo.

PROGRAMA pares
VARIABLES
n : Entero
EMPIEZA
LEER n
SI RESTO (N/2)==0 ENTONCES
ESCRIBIR “el número es par”
SI NO
ESCRIBIR “el número es impar”
FIN-SI
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.