Paradigmas de ingenieria del software

Paradigmas de ingenieria del software

1. Fundamentos de desarrollo de sistemas

76
Paradigmas de la Ingeniería de Software
3 Paradigmas de la ingeniería de software

La Ingeniería de Software es reconocida como una disciplina legítima, digna de
tener una investigación seria, un estudio cuidadoso y ha generando una gran
controversia. En la industria el Ingeniero del software ha sustituido al programador
como titulo de trabajo preferente. Los modelos de procesos de software, métodos
de ingeniería de software y herramientas se han adoptado con éxito en el amplio
espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la
necesidad de un enfoque más disciplinado del software.

Un paradigma de programación es un modelo básico de diseño y desarrollo de
programas, que permite producir programas con una directriz específica, tales
como: estructura modular, fuerte cohesión, alta rentabilidad, etc. [11]

Existen tres categorías de paradigmas de programación: [11]
a) Los que soportan técnicas de programación de bajo nivel (ejemplo: copia de
ficheros frente estructuras de datos compartidos)
b) Los que soportan métodos de diseño de algoritmos (ejemplo: divide y
vencerás, programación dinámica, etc.)
c) Los que soportan soluciones de programación de alto nivel, como los
descritos en el punto anterior

Los paradigmas relacionados con la programación de alto nivel se agrupan en tres
categorías de acuerdo con la solución que aportan para resolver el problema:
a) Solución procedimental u operacional. Describe etapa a etapa el modo de
construir la solución. Es decir señala la forma de obtener la solución.
b) Solución demostrativa. Es una variante de la procedimental. Especifica la
solución describiendo ejemplos y permitiendo que el sistema generalice la
solución de estos ejemplos para otros casos. Aunque es fundamentalmente
procedimental, el hecho de producir resultados muy diferentes a ésta, hace
que sea tratada como una categoría separada.

2. Fundamentos de desarrollo de sistemas

77
Paradigmas de la Ingeniería de Software
c) Solución declarativa. Señala las características que debe tener la solución,
sin describir cómo procesarla. Es decir señala qué se desea obtener pero
no cómo obtenerlo.

3.1 El enfoque estructurado

3.1.1 Diagramas de flujos de datos [3]

El DFD (Data Flow Diagram) surgió de la necesidad de un nuevo método de
especificación sencillo de implantar, fácil comprensión y comunicación.

El DFD fue desarrollado por De Marco en los años 70’s y fue popularizado por
Yourdan. Es un método de especificación utilizado hasta la fecha. Para empezar
se puede preguntar ¿Que son los diagramas de flujos de Datos?

Un diagrama de flujo de datos (DFD) es una representación gráfica de los
procesos que se realizan con los datos en su organización, con el uso de tan solo
cuatro símbolos, se puede crear una descripción grafica de los procesos que, con
el tiempo, contribuirán a desarrollar una sólida documentación del sistema.

En seguida mencionan las ventajas sobre las explicaciones descriptivas en
relación con la forma en que los datos se mueven a través del sistema:
1. Libertad para emprender la implementación técnica del sistema en las
primeras etapas.
2. Comprensión más profunda de la interrelación entre sistemas y
subsistemas.
3. Comunicación con los usuarios sobre el conocimiento del sistema actual
mediante diagramas de flujos de datos.
4. Análisis de un sistema propuesto para determinar si se han definido los
datos y procesos necesarios.

3. Fundamentos de desarrollo de sistemas

78
Paradigmas de la Ingeniería de Software
La ventaja más grande es la libertad conceptual para utilizar los cuatro símbolos,
los DFD’s hacen énfasis en el procesamiento o la transformación conforme estos
pasan por una variedad de procesos. En los DFD’s lógicos no hay distinción entre
procesos manuales o automatizados. Los procesos tampoco se representan
gráficamente en orden cronológico. En vez de ello, se agrupan solo si el análisis
detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y
los procesos automatizados también se pueden agrupar.

3.1.1.1 Simbología

En los diagramas de flujos de datos se usan cuatro símbolos básicos para graficar
el movimiento de los datos: Un cuadrado doble, una flecha, un rectángulo con
esquinas redondeadas(o una burbuja) y un rectángulo abierto (cerrado en el lado
izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 a
continuación. Con la combinación de estos cuatro símbolos se puede describir
gráficamente un sistema completo y varios subsistemas.



Entidad
Flujo de datos
Proceso
Almacén de datos
Figura 3.1 Simbología
Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed

4. Fundamentos de desarrollo de sistemas

79
Paradigmas de la Ingeniería de Software
El cuadrado doble se usa para describir una entidad externa (otro
departamento, un negocio, una persona o una maquina) que puede enviar datos al
sistema o recibirlos de el. La entidad externa, o solo entidad, también se llama
origen o destino de datos, y se considera externa al sistema descrito. A cada
entidad se le asigna un nombre adecuado. Aunque interactúa con el sistema, se
considera fuera de los límites de este. La misma entidad se podría usar más de
una vez en un diagrama de flujo de datos en particular para evitar que las líneas
se crucen en el flujo de datos.

La flecha muestra el movimiento de los datos de un punto a otro, con la punta
de la flecha señalando hacia el destino de los datos. Los flujos de datos que
ocurren simultáneamente se pueden describir mediante flechas paralelas. Una
flecha también puede se debe describir con un nombre, debido a que representan
los datos de un apersona, lugar o cosa.

Rectángulo con esquinas redondeadas se usa para mostrar la presencia de un
proceso de transformación. Los procesos siempre denotan un cambio en los
datos o una transformación de estos; por lo tanto el flujo de datos que sale de un
proceso siempre se designa de forma diferente al que entra en el. Los procesos
representan trabajo que se realiza en el tema y se deben nombrar usando uno de
los formatos siguientes:
 Se le debe asignar un nombre claro ya que este permite reconocer
fácilmente lo que hace un proceso.
1. A los procesos de alto nivel asigna el nombre del sistema. Por
ejemplo: SISTEMA DE CONTROL DE VENTAS.
2. Para nombrar un subsistema principal, se usa un nombre como
SUBSISTEMA DE INFORMACION DE VENTAS O SISTEMAS DE
CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET.
3. Para los procesos detallados se usa un formato de sustantivo-verbo-
adjetivo. El sustantivo indica cual es el resultado principal del
proceso, tal como INFORME O REGISTRO. El verbo describe el tipo

5. Fundamentos de desarrollo de sistemas

80
Paradigmas de la Ingeniería de Software
de actividad, tal como CALCULAR, VERIFICAR, PREPARAR,
IMPRIMIR O AGREGAR. El adjetivo describe el resultado específico
que se produce tal como NUEVO PEDIDO o INVENTARIO.
Ejemplos de nombres de procesos son CALCULAR IMPUESTOS DE
VENTAS, VERIFICAR ESTADOS DE CUENTA DEL CLIENTE,
PREPARAR FACTURA DE ENVIO, IMPRIMIR INFORME DE
NUEVOS PEDIDOS, ENVIAR CONFIRMACION AL CLIENTE POR
CORREO ELECTRONICO, VERIFICAR SALDO DE TARJETA DE
CREDITO Y AGREGAR REGISTRO DE INVENTARIO.
 A un proceso se le debe de asignar un número de identificación único y
exclusivo, que indique su nivel en el diagrama. Podría haber varios flujos
de datos que entren y salgan de cada proceso. Los procesos con solo un
flujo de entrada y salida se deben examinar en busca de flujos de datos
perdidos.

El rectángulo abierto representa un almacén de datos. Estos símbolos se
dibujan con el espacio suficiente para que quepan las letras de identificación como
se muestra en la figura. En los diagramas de flujo de datos lógicos no se
especifica el tipo de almacenamiento a un lugar. En este punto el símbolo del
almacén de datos simplemente muestra un lugar de depósito para los datos que
permite examinar, agregar y recuperar datos.

El almacén de datos podría representar un almacén manual, tal como un gabinete
de archivo, un archivo o una base de datos de computadora. A los almacenes de
datos se les asigna un nombre debido a que representan a una persona, lugar o
cosa. Los almacenes de datos temporales, tales como papel borrador o un archivo
temporal de computadora, no se incluyen en el diagrama de flujo de datos. Para
identificar el nivel del almacén de datos, a cada uno asígnele un número de
referencia única, tal como D1, D2, D3 etc.

6. Fundamentos de desarrollo de sistemas

81
Paradigmas de la Ingeniería de Software
3.1.1.2 Desarrollo de Diagramas de Flujos de Datos [3]

Los diagramas de flujos de datos se pueden y deben dibujar de manera
sistemática. Primero se deben visualizar los flujos de datos desde una perspectiva
jerárquica de arriba a bajo. En seguida se describen los pasos a seguir.

Lista de actividades [3]

Para empezar un diagrama de flujo de datos, se debe sintetizar la narrativa(o
historia) del sistema de la organización en una lista con las cuatro categorías de
entidad externa, flujo de datos, procesos, y almacén de datos. Esta lista a su vez
ayudara a determinar los límites del sistema que describirá. Una vez que se haya
recopilado una lista básica de elementos de datos se empieza a dibujar el
diagrama de contexto.

Creación de diagrama de contexto[3]

Con un enfoque jerárquico de arriba hacia abajo para diagramar el movimiento de
los datos, los diagramas van de lo general a lo específico. Aunque el primer
diagrama ayuda a entender el movimiento básico de los datos, lo general de su
naturaleza limita su utilidad. El diagrama de contexto inicial debe de mostrar un
panorama global que incluya las entradas básicas, el sistema general y las
salidas. Este diagrama será el mas general, con una visión muy superficial del
movimiento de los datos en el sistema y una visualización lo mas amplia posible
del sistema. El diagrama de contexto es el nivel más alto en un diagrama de flujo
de datos y contiene un solo proceso, que representa a todo el sistema. Al proceso
se le asigna el numero cero. En este diagrama se muestran todas las entidades
externas, así como los flujos de datos principales que van desde y hacia dichas
entidades. El diagrama no contiene ningún almacén de datos. Es bastante simple
la creación ya que se conocen las entidades externas y el flujo de datos desde y
hacia ellas.

7. Fundamentos de desarrollo de sistemas

82
Paradigmas de la Ingeniería de Software
Dibujo del diagrama 0 (el siguiente nivel) [3]

Al ampliar los programas se puede lograr un mayor detalle que con los diagramas
de contexto. Las entradas y salidas especificadas en el primer diagrama
permanecen constantes en todos los diagramas que le siguen. Sin embargo, el
resto del diagrama original se amplia para incluir de tres a nueve procesos y
mostrar almacenes de datos y nuevos flujos de datos de menor nivel. Cada
diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs para
representar subprocesos, en este paso se empiezan a completar los detalles del
movimiento de los datos. El manejo de excepciones se ignora en los primero dos o
tres niveles del diagrama de flujo de datos.

0

Nombre
del
Sistema
Entrada A
Entrada B
Salida C
Entidad 1
Entidad 2
Entidad 3
1

Proceso
general
AAA
2

Proceso
general
BBB
3

Proceso
general
CCC
4

Proceso
general
DDD
Entrada A
D2
Almacén de
Datos 2

D1
Almacén de
Datos 2

Entrada B
Salida C Flujo de
datos B
Registro E
Registro E
Registro A
Registro A
Entidad 1
Entidad 2
Entidad 3
Flujo de
datos D
Figura 3.2 Representación del diagrama de contexto y del diagrama cero
Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed

8. Fundamentos de desarrollo de sistemas

83
Paradigmas de la Ingeniería de Software
El diagrama cero es la ampliación del diagrama de contexto y puede incluir hasta
nueve procesos, esto se hace porque si se agregan más procesos producirá un
diagrama difícil de entender. Por lo general, cada proceso se numero con un
entero, empezando en la esquina superior izquierda del diagrama y terminando en
la esquina inferior derecha. En el diagrama cero se incluyen los principales
almacenes de datos del sistema (que representan a los archivos maestros) y todas
las entidades externas. La figura 3.2 representa gráficamente el diagrama de
contexto y el diagrama cero.

Debido a que un diagrama de flujo de datos es bidimensional (en lugar de lineal),
se puede empezar en cualquier punto del diagrama e ir hacia delante o hacia
atrás. Si no esta seguro de lo que podría incluir en cualquier punto, tome una
entidad externa, un proceso o un almacén de datos diferente y empiece a dibujar
el flujo a partir de él:
1. Empezamos con el flujo de datos de una entidad en el lado de la entrada.
Se hacen preguntas como: ¿Qué sucede con los datos que entran en el
sistema? ¿Se almacenan? ¿Esta entrada es para varios procesos?
2. Trabajamos hacia atrás a partir de un flujo de datos de salida. Examinamos
los campos de salida de un documento o pantalla. (Este enfoque es más
sencillo si se han creado prototipos.) Se pregunta sobre cada campo de la
salida: "¿De dónde viene?" o "¿Se calcula o almacena en un archivo?" Por
ejemplo, cuando la salida es un RECIBO DE NOMINA, el NOMBRE DEL
EMPLEADO y la DIRECCION se podrían localizar en un archivo EM -
PLEADO, las HORAS TRABAJADAS podrían encontrarse en un
REGISTRO DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se
tendrían que calcular. Cada archivo y registro estaría conectado al proceso
que produce el recibo de nómina.
3. Examinamos el flujo de datos desde o hacia un almacén de datos. Se
pregunta: "¿Qué procesos ponen los datos en el almacén?" o "¿Qué
procesos usan los datos?" Observamos que un almacén de datos utilizado
en el sistema en el que se esta trabajando podría ser producido por un

9. Fundamentos de desarrollo de sistemas

84
Paradigmas de la Ingeniería de Software
sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya
ningún flujo de datos hacia el almacén de datos.
4. Analizamos un proceso bien definido. Vea qué entrada de datos necesita el
proceso y qué salida produce. Se hace un vínculo la entrada y la salida con
los almacenes de datos y las entidades adecuadas.
5. Tome nota de cualquier área confusa en donde no esté seguro de lo que se
debe incluir o de la entrada o la salida que se requiera. Al conocer las áreas
problemáticas podrá realizar una lista de preguntas para las entrevistas de
seguimiento con los usuarios clave.

Creación de diagramas hijos (niveles mas detallados) [3]

Cada proceso del Diagrama cero se puede, a su vez, ampliar para crear un
diagrama hijo más detallado. El proceso del Diagrama cero a partir del cual se
realiza la ampliación se llama proceso padre, y el diagrama que se produce se
llama diagrama hijo. La regla principal para crear diagramas hijos, es el equilibrio
vertical, estipula que un diagrama hijo no puede producir salida o no puede recibir
entrada que el proceso padre no produzca o reciba también.

Todos los flujos de datos hacia dentro o hacia fuera del proceso padre se deben
mostrar fluyendo hacia dentro o hacia fuera del diagrama hijo.

Al diagrama hijo se le asigna el mismo numero que a su proceso padre en el
Diagrama cero. Los procesos del diagrama hijo se numeran usando el numero del
proceso padre, un punto decimal y un solo numero para cado proceso hijo. Con
esto se puede localizar una serie de procesos a través de muchos niveles de
ampliación. Si el diagrama cero presenta los procesos 1, 2 y 3 los diagramas hijos
1, 2 y 3 estarán en el mismo nivel.

Por lo regular las entidades no se muestran en los diagramas hijos debajo del
diagrama cero. El flujo de datos que coincide con el flujo padre se llama flujo de
datos de interfaz y se representa con una flecha que parte de un área vacía del
diagrama hijo. Si el proceso padre tiene un flujo de datos conectado a un almacén

10. Fundamentos de desarrollo de sistemas

85
Paradigmas de la Ingeniería de Software
de datos, también el diagrama hijo podría incluir el almacén de datos. Además,
este diagrama de nivel inferior podría contener almacenes de datos que no se
muestran en el proceso padre. Por ejemplo se podrían incluir un archivo que
contenga una tabla de información, como una tabla de impuestos, o un archivo
que conecta dos procesos del diagrama hijo. En un diagrama hijo se podrían
incluir un flujo de datos de nivel inferior, como una línea de error, aunque no se
podría hacer lo mismo en el proceso padre.

Los procesos se podrían ampliar o no ampliar, dependiendo de su nivel de
complejidad. Cuando no se amplia un proceso, se dice que es funcionalmente
primitivo y se llama proceso primitivo. En la figura 3.3 se ilustran niveles detallados
de un diagrama de flujos de datos hijo. [3]

Revisión de Errores en lo diagramas [3]

Cuando se dibujan diagramas de flujos de datos se pueden cometer varios errores
comunes como los siguientes:
1. Olvidar incluir un flujo de datos o apuntar con una flecha en la dirección
incorrecta. Un ejemplo es un proceso dibujado que muestra todos sus flujos
de datos como entrada o salida. Cada proceso transforma datos y debe
recibir una entrada y producir una salida. Este tipo de error ocurre
generalmente cuando el analista olvida incluir un flujo de datos o coloca una
flecha que apunta en la dirección incorrecta.
2. Conectar directamente entre sí almacenes de datos y entidades externas.
Los almacenes de datos y las entidades externas no se deben conectar
entre sí; sólo se deben conectar con un proceso. Un archivo no interactúa
con otro archivo sin la ayuda de un programa o una persona que mueva los
datos. Las entidades externas no trabajan directamente con los archivos.
Dos entidades externas conectadas directamente indican que desean
comunicarse entre sí. Esta conexión no se incluye en el diagrama de flujo
de datos a menos que el sistema facilite la comunicación. La elaboración de
un informe es un ejemplo de esta clase de comunicación. Sin embargo, es

11. Fundamentos de desarrollo de sistemas

86
Paradigmas de la Ingeniería de Software
necesario interponer un proceso entre las entidades para producir el
informe.

3. Asignar nombres incorrectos a los procesos o al flujo de datos. Es
necesario revisar el diagrama flujo de datos para asegurar que cada objeto
o flujo de datos tenga un nombre adecuado. Un proceso debe indicar el
nombre del sistema o usar el formato sustantivo-verbo-adjetivo. Cada flujo
de datos se debe describir con un sustantivo.
4. Incluir más de nueve procesos en un diagrama de flujo de datos. La
inclusión de demasiados procesos origina un diagrama confuso difícil de
entender y obstaculiza la comunicación en lugar de facilitada. Si en un
3

Proceso
general
CCC
Entrada B
Registro A
Entidad 2
El flujo de datos
coincidente
Registro
de
transacción
D1
Almacén de
Datos 1

D5
Archivo de
Transacción 1

Flujo de
datos D
Registro A
Flujo de datos
Z detallado
Registro
de
transacción
1
Flujo de datos D
D1
Almacén de
Datos 1

4

Proceso
general
DDD
3

Proceso
YYY
detallado
3

Proceso
general
CCC
3.1

Proceso
XXX
detallado
Entrada B
Error
En un diagrama
hijo detallado se
podrían agregar
líneas de error
En los diagramas
de nivel inferior se
podrían agregar
archivos de
transacciones
El flujo de salida
debe coincidir con
el proceso padre
El flujo de datos
del proceso padre
debe coincidir con
el diagrama hijo
Figura 3.3 Representación del diagrama de contexto y del diagrama cero
Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed

12. Fundamentos de desarrollo de sistemas

87
Paradigmas de la Ingeniería de Software
sistema existen más de nueve procesos, agrupe en un subsistema algunos
de los procesos que trabajan en conjunto y póngalos en un diagrama hijo,
5. Omitir un flujo de datos. Examine su diagrama en busca de flujo lineal, es
decir, flujo de datos en el cual cada proceso tiene sólo una entrada y una
salida. El flujo de datos lineal no es muy común, excepto en los diagramas
de flujo de datos hijos muy detallados, su presencia normalmente indica
que al diagrama le falta algún flujo de datos.
6. Crear una separación (o ampliación) desequilibrada en los diagramas hijos.
Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida
que el proceso padre, Una excepción a esta regla son las salida menores,
como las líneas de error, que se incluyen solamente en el diagrama hijo.

En seguida se sintetizan los pasos para desarrollar eficazmente diagramas de flujo
de datos, usando un enfoque jerárquico de arriba a bajo:
1. Haga una lista de las actividades del negocio y úsela para determinar lo
siguiente:
 Entidades externas
 Flujos de datos
 Procesos
 Almacén de datos
2. Crear un diagrama de contexto que muestre las entidades externas y los
flujos de datos desde y hacia el sistema. No muestre ejemplos ni
almacenes de datos detallados.
3. Dibujar el diagrama 0(el siguiente nivel). Muestre procesos, pero que sean
generales. En este nivel muestre almacenes de datos.
4. Cree un diagrama hijo para cada uno de los procesos del Diagrama 0
5. Revise que no haya errores y asegúrese de que sean significativos los
nombres que haya asignado a cada proceso y flujo de datos.
6. Desarrolle un diagrama de flujo de datos físico a partir del diagrama de
flujo de datos lógico. Distinga entre los procesos manuales y
automatizados, describa los archivos reales y los informes por nombre y

13. Fundamentos de desarrollo de sistemas

88
Paradigmas de la Ingeniería de Software
agregue controles para indicar cuando se completan los procesos o cuando
ocurren errores.
7. Ahora se hace una partición el diagrama de flujo de datos físico separando
o agrupando sus partes con el propósito de facilitar la programación y la
implementación.

3.1.1.3 Diagramas de flujos de datos lógicos y físicos [3]

Los diagramas de flujo de datos se catalogan como lógicos o físicos. Un diagrama
de flujo de datos lógico se enfoca en el negocio y en el funcionamiento de éste. No
se ocupa de manera en que se construirá el sistema. Más bien, describe los
eventos que ocurren en el negocio y los datos requeridos y producidos por cada
evento. Por el contrario, un diagrama de flujo de datos físico muestra cómo se
implementará el sistema, incluyendo el hardware, el software, los archivos y las
personas involucradas en el sistema. En la Tabla 3.1 se muestra un cuadro que
compara las características de los modelos lógico y físico. Observe que el modelo
lógico refleja el negocio, mientras que el modelo físico describe el sistema.

Tabla 3.1 Características modelos lógicos y físicos
Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed
Características del
diseño
Lógico Físico
Que describe el modelo Como se implementará el
sistema (o como funciona el
sistema actual)
Como funciona el negocio
Que representan los
procesos
Las actividades del negocio Programas, módulos del
programa y procedimientos
manuales
Que representan los
almacenes de datos
Colecciones de datos
independientemente de
como se almacenan.
Archivos y bases de datos
físicos, archivos manuales
Tipos de almacenes de
datos
Muestra almacenes de
datos que representan
colecciones de datos
permanentes
Archivos maestros, archivos
de transición. Cualesquier
proceso que operen en dos
momentos diferentes deben
conectarse mediante un
almacén de datos
Que representan los
almacenes de datos
Que representan los
almacenes de datos
Muestra controles para
validar los datos de entrada,
para obtener un registro (el
estado de un registro), para
asegurar la realización
exitosa de un proceso y
para la seguridad del
sistema

14. Fundamentos de desarrollo de sistemas

89
Paradigmas de la Ingeniería de Software

Una ventaja de construir el diagrama de flujo de datos lógico del sistema actual es
que puede usar para crear el diagrama de flujo de datos lógico del nuevo sistema.
Los procesos innecesarios en el nuevo sistema se podrían eliminar y agregar
nuevas características, actividades, salidas, entradas y datos almacenados.
Mediante este enfoque se garantiza que el nuevo sistema conservará las
características esenciales del sistema anterior. Además, el uso del modelo lógico
del sistema actual como base para el sistema propuesto ofrece una transición
gradual para el diseño del nuevo sistema, Una vez desarrollado el modelo lógico
para el nuevo sistema, se podría usar para crear un diagrama de flujo de datos
físico par tal sistema.

Desarrollo de diagramas de flujo de datos lógicos [3]

Para desarrollar un diagrama de este tipo, primero se construye un diagrama de
flujo de datos para el sistema actual. Hay varias ventajas al usar un modelo lógico,
entre ellas:
1. Mejor comunicación con los usuarios.
2. Sistemas más estables.
Diagrama de
flujo de
datos lógico
actual

Nuevo
diagrama
de flujo de
datos
lógico
Nuevo
diagrama
de flujo de
datos físico
Obtenga el diagrama de flujo de datos lógico para el
sistema actual examinando el diagrama de flujo de datos
físico y separando las actividades únicas del negocio
Cree el diagrama de flujo de datos lógico para el nuevo
sistema agregando al diagrama de flujo de datos lógico
del sistema actual las entradas, salidas y procesos
requeridos en el nuevo sistema
Obtenga el diagrama de flujo de datos físico examinando
los nuevos procesos en el nuevo diagrama lógico.
Determine en donde deben existir la interfaz de usuario,
la naturaleza de los procesos y los almacenes de datos
necesarios
Tabla 3.2 Progresión del diagrama de flujo de datos
Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed

15. Fundamentos de desarrollo de sistemas

90
Paradigmas de la Ingeniería de Software
3. Mejor entendimiento del negocio por parte de los analistas.
4. Flexibilidad y mantenimiento.
5. Eliminación de redundancias y creación más sencilla del modelo físico.

Es más fácil usar un modelo lógico al comunicarse con los usuarios del sistema
porque se centra en las actividades del negocio. En consecuencia los usuarios
estarán familiarizados con las actividades principales y con muchos de los
requerimientos de información de cada actividad.

Los diagramas de flujos de datos lógicos representan características de un
sistema que deberían existir sin importar cuales sean los medios físicos para
llevarlas a cabo.

Desarrollo de diagramas de flujos de datos físicos [3]

Después de desarrollar el modelo lógico del nuevo sistema, se puede usar para
crear un diagrama de flujo de datos físico. El diagrama de flujo de datos físico
muestra como se creará el sistema, y generalmente contiene la mayoría, si no es
que todos, de los elementos siguientes:
 Procesos manuales
 Procesos para agregar, eliminar, cambiar y actualizar registros.
 Procesos de entrada y verificación de datos
 Procesos de validación para garantizar la precisión de la entrada de datos
 Distribución de los procesos para reorganizar el orden de los registros
 Procesos para producir cada salida única del sistema
 Almacenes de datos intermedios
 Nombres de archivos reales para almacenar datos
 Controles para describir la terminación de tareas o condiciones de error

Los diagramas de flujo de datos físicos tienen las siguientes ventajas.
1. Aclara qué procesos son manuales y cuáles son automatizados.

16. Fundamentos de desarrollo de sistemas

91
Paradigmas de la Ingeniería de Software
2. Describe los procesos con mayor detalle que los DFDs lógicos.
3. Distribuye en un orden particular los procesos que se deben realizar.
4. Identifica los almacenes de datos temporales.
5. Especifica los nombres reales de archivos y documentos impresos.
6. Agrega controles para asegurar que los procesos se realicen
adecuadamente

A menudo estos diagramas son tan complejos debido a la gran cantidad de
almacenes de datos que incluye un sistema. Frecuentemente se usan la siglas
CLAE (CRUD: Create, Read, Update and Delete) para denotar las actividades
Crear, Leer, Actualizar y Eliminar, que un sistema debe ejecutar en cada archivo
maestro. Una matriz CLAE es una herramienta que sirve para representar en que
parte del sistema ocurre cada uno de estos procesos.

Los diagramas de flujo de datos físicos también tienen almacenes de datos
intermedios, con frecuencia un archivo de transacción o una tabla de base de
datos temporal. A menudo, los almacenes de datos intermedios consisten en
archivos de transacción que se utilizan para almacenar datos entre procesos.
Dado que es poco probable que la mayoría de los procesos requieren acceso a un
conjunto determinado de datos se ejecuten al mismo tiempo, los archivos de
transacción deben guardar los datos de un proceso para luego enviarlo al
siguiente.

También se puede incluir información relacionada con el tiempo. Por ejemplo, un
DFD físico podría indicar que un programa de edición se debe ejecutar antes que
un programa de actualización. Las actualizaciones deben ejecutarse antes que la
elaboración de un informe resumido, o un pedido debe ingresarse en un sitio Web
antes de verificar con la institución financiera la cantidad cargada a una tarjeta de
crédito. A causa de estas consideraciones, un diagrama de flujo de datos físico
podría tener una apariencia más lineal que la de un modelo lógico.

17. Fundamentos de desarrollo de sistemas

92
Paradigmas de la Ingeniería de Software
Se debe de crear el diagrama de flujo de datos físico para un sistema mediante el
análisis de su entrada y su salida. Al crear un diagrama de flujo de datos físico, el
flujo de datos de entrada proveniente de una entidad externa en ocasiones se
denomina detonador porque inicia las actividades de un proceso, y el flujo de
datos de salida de una entidad externa se denomina respuesta porque se envía
como resultado de alguna actividad. Se determina qué campo o elementos de
datos es necesario teclear. Estos campos se denominan elementos básicos y se
deben almacenar en un archivo. Los elementos que no se teclean sino que son
resultados de un cálculo o de una operación lógica se conocen como elementos
derivados.

3.1.1.4 Particionamiento de los diagramas de flujos de datos [3]

Este es un proceso de examinar un diagrama de flujo de datos y se determina
como se debe dividir en colecciones de procedimientos manuales y colecciones
de programas de cómputo. Analice cada procedo para determinar si debe ser un
proceso manual o automatizado. Agrupe los procedimientos automatizados en una
serie de programas de cómputo. Usualmente se traza una línea punteada
alrededor de un proceso o grupo de procesos que deben colocarse en un solo
programa de cómputo.

Existen seis razones para particionar diagramas de flujos de datos:
1. Diferentes grupos de usuarios. ¿Los procesos son realizados por varios
grupos de usuarios diferentes, con frecuencia en distintas ubicaciones
físicas de la compañía?. Si es así, se deben particionar en diferentes
programas de cómputo.
2. Sintonización. En esta parte se debe examinar que los procesos se
sincronicen. Si dos procesos se realizan en diferentes momentos, no se
puede agrupar en un programa.
3. Tareas similares. Si dos procesos ejecutan tareas similares, es posible
agruparlos en un solo programa de cómputo.

18. Fundamentos de desarrollo de sistemas

93
Paradigmas de la Ingeniería de Software
4. Eficiencia. En un programa se podría combinar varios procesos para
realizar un procesamiento eficiente.
5. Consistencia de los datos. Los procesos se podrían combinar en un solo
programa para mantener la consistencia de los datos.
6. Seguridad. Los procesos se podrían particionar en diferentes programas
por razones de seguridad.

3.1.2 Diccionarios de datos [3]

El diccionario de datos surge de la necesidad de catalogar los procesos, flujos
almacenes estructuras y elementos de datos. Los nombres que se usan son muy
importantes. Cuando se tiene la oportunidad de asignar nombre a los
componentes de los sistemas orientados a datos, es necesario trabajar en la
creación de un nombre significativo pero diferente al de otros componentes de
datos existentes.

Se ha propuesto el diccionario de datos como gramática casi formal para describir
el contenido de los objetos definidos durante el análisis estructurado. Esta
notación ha sido definida de la siguiente forma por Yourdon en 1989:

El diccionario de datos es un listado organizado de todos los elementos de datos
que son pertinentes para el sistema, con definiciones precisas y rigurosas que
permiten que el usuario y el analista del sistema tenga una misma comprensión de
las entradas, salidas, de los componentes de los almacenes y también los cálculos
intermedios. [2]

Muchos sistemas de administración de base de datos están equipados con un
diccionario de datos automatizado. Estos diccionarios pueden ser complejos o
sencillos, algunos diccionarios de datos computarizados catalogan
automáticamente los elementos de datos cuando se hace la programación; otros

19. Fundamentos de desarrollo de sistemas

94
Paradigmas de la Ingeniería de Software
simplemente proporcionan una plantilla para motivar a la persona que llene el
diccionario a que lo haga de una manera uniforme para cada entrada.

A pesar de la existencia de los diccionarios de datos automatizados, entender qué
datos conforman un diccionario de datos, las convenciones usadas en estos
últimos y cómo se desarrolla un diccionario de datos, son problemas que el
analista de sistemas debe tener siempre presentes durante el esfuerzo de
sistemas. Entender el proceso de compilar un diccionario de datos puede ayudar
al analista de sistemas a visualizar el sistema y su funcionamiento.

Además de proporcionar documentación y eliminar la redundancia, el diccionario
datos se podría usar para:
1. Validar la integridad y exactitud del diagrama de flujo de datos.
2. Proporcionar un punto de partida para desarrollar pantallas e informes,
3. Determinar el contenido de los datos almacenados en archivos.
4. Desarrollar la lógica para los procesos del diagrama de flujo de datos,

3.1.2.1 Depósito de datos [3] [2]

Aunque el diccionario de datos contiene información de los datos y
procedimientos, una colección más grande de información de proyectos se llama
depósito, El concepto depósito es uno de los muchos impactos de las
herramientas CASE y podría contener lo siguiente:
1. Información sobre los datos mantenidos por el sistema, incluyendo flujos de
datos, almacenes de datos, estructuras de registros y elementos.
2. Lógica de procedimientos.
3. Diseño de pantallas e informes.
4. Relaciones entre datos, por ejemplo cómo se vincula una estructura de
datos con otra.
5. Requerimientos del proyecto y productos del sistema final.

20. Fundamentos de desarrollo de sistemas

95
Paradigmas de la Ingeniería de Software
6. Información sobre la administración del proyecto, tal como itinerarios de
entrega," problemas pendientes de solución y usuarios del proyecto.

Por lo general, los flujos de datos son los primeros elementos que se definen. Las
entradas y salidas del sistema se determinan mediante las entrevistas y la
observación de los usuarios, y el análisis de documentos y de otros sistemas
existentes. La información capturada se puede resumir usando un formulario que
contenga la siguiente información:
1. ID, un numero de identificación opcional. A veces este se codifica usando
un esquema para identificar el sistema y la aplicación del sistema.
2. Un solo nombre descriptivo para este flujo de datos. Este nombre es el
texto que debe aparecer en el diagrama y se debe referenciar en todas las
descripciones que usen el flujo de datos.
3. Un a descripción general del flujo de datos.
4. La fuente del flujo de datos. Esta podría ser una entidad externa, un
proceso o influjo de datos proveniente de un almacén de datos.
5. El destino del flujo de datos. Esta podría ser una entidad externa, un
proceso o influjo de datos proveniente de un almacén de datos.
6. Algo que indique si el flujo de datos es un registro que esta entrando o
saliendo de un archivo o un registro que contiene un informe, formulario o
pantalla. Si el flujo de datos contiene datos que se usan entre los procesos,
se designa como interno.
7. El nombre de la estructura de datos que describe los elementos
encontrados en este flujo de datos. Para un flujo de datos simple, podrían
ser uno o varios elementos.
8. el volumen por unidad de tiempo. Los datos podrían ser registros por día o
cualquier otra unidad de tiempo.
9. Un área para comentarios adicionales y anotaciones sobre el flujo de datos.

21. Fundamentos de desarrollo de sistemas

96
Paradigmas de la Ingeniería de Software
Descripción de las estructuras de datos [3]

Normalmente las estructuras de datos se describen usando una notación
algebraica. Este método permite al analista producir la vista de los elementos que
constituyen la estructura de datos junto con información referente a dichos
elementos. La notación algebraica usa los siguientes símbolos:
1. Un signo de igual (=) significa “esta compuesto de”.
2. Un signo de suma (+) significa “y”.
3. Las llaves { } indican elementos repetitivos, también llamados grupos de
repetición o tablas. En el grupo podría haber un elemento de repetición o
varios de ellos. El grupo de repetición podría tener condiciones, tal como un
número fijo de repeticiones o limites superiores e inferiores para el número
de repeticiones.
4. Los corchetes [ ] representan una situación de uno u otro. Se podría
representar un elemento u otro, pero no ambos. Los elementos listados
entre los corchetes son mutuamente excluyentes.
5. Los paréntesis ( ) representan un elemento opcional. Los elementos
opcionales se podrían dejar en blanco en la entrada de las pantallas y
podrían contener espacios o ceros para campos numéricos en las
estructuras de archivos.

Estructuras de datos Lógicas y Físicas [3]

Cuando son definidas las estructuras de datos por primera vez, sólo son incluidos
los elementos de datos que el usuario podrá ver, tales como nombre, dirección y
saldo. Esta etapa es el diseño lógico, mostrando cuáles datos necesita el negocio
para su operación diaria. Usando diseño lógico como base, el analista diseña
luego las estructuras de datos físicas. Estas incluyen elementos adicionales para
la implementación del sistema. Ejemplos de elementos de diseño físico:
1. Campos clave usados para localizar registros en una base de datos

22. Fundamentos de desarrollo de sistemas

97
Paradigmas de la Ingeniería de Software
2. Códigos para identificar el estado de registros maestros. Estos códigos se
pueden mantener en archivos que generen información de impuestos.
3. Los códigos de transacción son utilizados para identificar tipos de registros
cuando un archivo contiene tipos de registros diferentes.
4. Las entradas de grupos repetidos contienen un contador sobre qué tantos
conceptos hay en el grupo.
5. Límites sobre la cantidad de conceptos aceptables en un grupo repetido.
6. Una contraseña usada por un cliente que accede a un sitio web seguro.

Elementos de datos [3]

Cada elemento de datos se debe definir una vez en el diccionario de datos y
también se podría introducir previamente en un formulario de descripción del
elemento.

Características de un formulario de descripción de elementos:
1. ID del elemento. Esta entrada opcional permite construcciones entradas de
diccionario de datos
2. El nombre del elemento. El nombre debe ser descriptivo, único y basado en
el propósito al cual esta destinado el elemento en la mayoría de los
programas o por el usuario principal del elemento.
3. Alias, son sinónimos u otros nombres para el elemento.
4. Una descripción breve del elemento
5. Si el elemento es base o derivado. Elemento base es el que se teclea
inicialmente en el sistema, nombre del cliente dirección o ciudad; se deben
almacenar en archivos. Los elementos derivados son creados por procesos
como resultado de cálculo.
6. La longitud del elemento. Algunos elementos tienen longitudes estándar y
otras veces pueden variar para otros elementos, aquí se debe decidir en
conjunto con el usuario la longitud final.

23. Fundamentos de desarrollo de sistemas

98
Paradigmas de la Ingeniería de Software
7. El tipo de datos: numérico, fecha, alfabético o carácter que a veces se llama
datos alfanuméricos o de texto.
8. Los formatos de entrada y salida se deben incluir, usando símbolos de
codificación especiales para indicar como se deben presentar los datos.
9. Los criterios de validación para asegurar que el sistema capture los datos
correctos. Los elementos pueden ser discretos, lo cual significa que tiene
ciertos valores fijos o continuos, con un rango parejo de valores.
10. Cualquier valor predeterminado que pudiera tener el elemento. El valor
predeterminado se despliega en las pantallas de entrada y se usa para
reducir la cantidad de datos que tuviera que teclear el operador.
11. Un área adicional para observaciones o comentarios.

Almacenes de datos [3]

Todos lo elementos base se deben almacenar en el sistema. También los
elementos derivados se podrían almacenar en el sistema, tal como, para un
empleado, el sueldo bruto acumulado a la fecha. Los almacenes de datos se
crean, cuando los elementos base de un flujo de datos se agrupan para formar un
registro estructural, se crea un almacén de datos para cada registro estructural
único.

3.1.2.2 Creación del diccionario de datos [3]

Las entradas del diccionario de datos se podrían crear después de completar el
diagrama de flujo de datos, o se podrían construir conforme se desarrolle el
diagrama de flujo de datos. El uso de notación algebraica y registros estructurales
permite desarrollar el diccionario de datos y los diagramas de flujos de datos
mediante un enfoque jerárquico de arriba a bajo.

Después de realizar varias entrevistas adicionales para descubrir los detalles del
sistema, se puede extender el diagrama de flujo de datos y se crearan los

24. Fundamentos de desarrollo de sistemas

99
Paradigmas de la Ingeniería de Software
diagramas hijos. Posteriormente se modifica el diccionario de datos para incluir los
nuevos registros estructurales y elementos recabados en las entrevistas,
observación y análisis de documentos posteriores.

Cada nivel de un diagrama de flujo de datos debe usar datos adecuados para el
nivel. El diagrama 0 debe incluir únicamente formularios, pantallas informes y
registros. Conforme se creen los diagramas hijos, el flujo de datos que entre y
salga de los procesos será cada vez mas detallado, incluyendo los registros
estructurales y los elementos.

Análisis de las entradas y salidas [3]

Un paso importante en la creación del diccionario de datos es identificar y
categorizar el flujo de datos de entrada y salida del sistema. Campos comúnmente
incluidos:
1. Nombre descriptivo para la entrada o la salida. Si el flujo de datos esta en
un diagrama lógico, el nombre debe identificar el propósito de los datos.
2. El contacto del usuario responsable para la clarificación de detalles
adicionales, retroalimentación del diseño y aprobación final
3. Si los datos son de entrada o salida
4. El formato de flujo de datos. En la fase del diseño lógico, el formato podría
ser indeterminado.
5. Elementos que indican la secuencia de los datos en un informe o pantalla.
6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o
derivados y sus criterios de edición.

Desarrollo de almacenes de datos [3]

Otra actividad es el desarrollo de los almacenes de datos. Esta información se
describe en estructuras de datos. Sin embargo la información podría estar
almacenada en diferentes lugares, y el almacén de datos podría ser diferente en

25. Fundamentos de desarrollo de sistemas

100
Paradigmas de la Ingeniería de Software
cada lugar. Mientras que los flujos de datos representan datos en movimiento, los
almacenes de datos representan datos en reposo.

Los almacenes de datos contienen información de una naturaleza permanente o
semipermanente.

Cuando los almacenes de datos se crean para un solo informe o pantalla nos
referimos a ellos como “vistas del usuario”, porque representan la manera en que
el usuario quiere ver la información.

Uso del diccionario de datos [3]

El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo.
Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la
organización, se agregan elementos de datos al diccionario de datos. El
diccionario de datos no es un fin en si mismo y nunca debe serlo, siempre debe
verse como una actividad paralela al análisis y diseño de sistemas.

El diccionario de datos debe vincular a varios programas de sistemas para que
cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo
mismo en la base de datos. El diccionario de datos se vuelve una curiosidad
histórica sino se mantiene actualizado.

3.1.3 Diseño de módulos [2]

El concepto de modularidad se ha ido exponiendo desde hace casi cinco décadas
en el software de computadora. La arquitectura de computadora expresa la
modularidad; es decir, el software se divide en componentes nombrados y
abordados por separado, llamados frecuentemente módulos, que se integran para
satisfacer los requisitos del problema.

26. Fundamentos de desarrollo de sistemas

101
Paradigmas de la Ingeniería de Software
Se ha afirmado que “La modularidad es el único atributo del software que permite
gestionar un programa intelectualmente”. El software monolítico (es decir, un
programa grande formado por un único modulo) no puede ser entendido
fácilmente por el lector. La cantidad de rutas de control, la amplitud de referencias,
la cantidad de variables y la complejidad global hará que el entendimiento este
muy cerca de ser imposible. Para ilustrar este punto, tomemos en consideración el
siguiente argumento basado en observaciones humanas sobre la resolución de
problemas.

Pensemos que C(x) es una función que define la complejidad percibida de un
problema x, y que E(x) es una función que define el esfuerzo (oportuno) que se
requiere para resolver un problema x. para dos problemas p1 y p2, si

C(p1) > C(p2) (3.1a)
Implica que
E(p1) > E(p2) (3.1b)

En general, este resultado es por intuición obvio. Se tarda más en resolver un
problema difícil.

Mediante la experimentación humana en la resolución de problemas se ha
averiguado otra característica interesante. Esta es,

C(p1 + p2) > C(p1) + C(p2) (3.2)

La ecuación 3.2 implica que la complejidad percibida de un problema que combina
p1 y p2, es mayor que la complejidad percibida cuando se considera cada
problema por separado. Teniendo en cuenta la ecuación (3.2) y la condición
implicada por la ecuación (3.1) se establece que

E(p1 + p2) > E(p1) + E(p2) (3.3)

27. Fundamentos de desarrollo de sistemas

102
Paradigmas de la Ingeniería de Software

Esto lleva a una conclusión: “divide y vencerás” es más fácil resolver un problema
complejo cuando se rompe en piezas manejables. El resultado expresado en la
ecuación 3.3 implica que es importante en lo que respecta a la modularidad y al
software. Es, de hecho, un argumento para la modularidad.

Es posible concluir de la ecuación (3.3) que si subdividimos el software
indefinidamente, el esfuerzo que se requiere para desarrollarlo sería mínimo.
Desgraciadamente, intervienen otras fuerzas, que hacen que esta conclusión sea
(tristemente) falsa. Como muestra la figura 3.4, el esfuerzo (costo) para desarrollar
un módulo software individual disminuye a medida que aumenta el número total de
módulos. Dado el mismo conjunto de requisitos: tener más módulos conduce a un
tamaño menor de módulo. Sin embargo, a medida que aumenta el número de
módulos, también crece el esfuerzo (costo) asociado con la integración de
módulos. Estas características conducen también a la curva total del costo o
esfuerzo que se muestra en la figura. Existe un número M de módulos que daría
como resultado un costo mínimo de desarrollo, aunque no tenemos la sofisticación
necesaria para predecir M con seguridad.

Costo total
del software
Costo de
Integración
Costo/ modulo
Región de costo
mínimo
M
Número de módulos
Costo de Esfuerzo

Figura 3.4 Esfuerzo Costo en modularidad
Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición

28. Fundamentos de desarrollo de sistemas

103
Paradigmas de la Ingeniería de Software
Las curvas de la Figura 3.4 proporcionan en efecto una guía útil cuando se tiene
en consideración la modularidad. La modularidad deberá aplicarse, pero teniendo
cuidado de estar próximo a M. Se deberá evitar modularizar de más o de menos.

Cuando se tiene en consideración la modularidad surge otra pregunta importante.
¿Cómo se define un modulo con un tamaño adecuado? La respuesta s e,
encuentra en los métodos utilizados para definir los módulos dentro de un sistema.
Meyer define cinco criterios que nos permitirán evaluar un método de diseño en
relación con la habilidad de definir un sistema modular efectivo:
 Capacidad de descomposición modular . Si un método de diseño
proporciona un mecanismo sistemático para descomponer el problema en
subproblemas, reducirá la complejidad de todo el problema, consiguiendo
de esta manera una solución modular efectiva.
 Capacidad de empleo de componentes modulares . Si un método de
diseño permite ensamblar los componentes de diseño (reusables)
existentes en un sistema nuevo, producirá una solución modular que no
inventa nada ya inventado.
 Capacidad de comprensión modular. Si un módulo se puede comprender
como una unidad autónoma (sin referencias a otros módulos) será más fácil
de construir y de cambiar.
 Continuidad modular. Si pequeños cambios en los requisitos del sistema
provocan cambios en los módulos individuales, en vez de cambios
generalizados en el sistema, se minimizará el impacto de los efectos
secundarios de los cambios.
 Protección modular. Si dentro de un módulo se produce una condición
absurda y sus efectos se limitan a ese módulo, se minimizará el impacto de
los efectos secundarios inducidos por los errores.

Finalmente, es importante destacar que un sistema se puede diseñar
modularmente, incluso aunque su implementación deba ser “monolítica”. Existen
situaciones (por ejemplo, software en tiempo real, software empotrado) en donde

29. Fundamentos de desarrollo de sistemas

104
Paradigmas de la Ingeniería de Software
no es admisible que los subprogramas introduzcan sobrecargas de memoria y de
velocidad por mínimos que sean (por ejemplo, subrutinas, procedimientos). En
tales situaciones el software podrá y deberá diseñarse con modularidad como
filosofía predominante. El código se puede desarrollar “en línea”. Aunque el código
fuente del programa puede no tener un aspecto modular a primera vista, se ha
mantenido la filosofía y el programa proporcionará los beneficios de un sistema
modular.

3.1.3.1 Diseño Modular Efectivo [2]

La modularidad se ha convertido en un enfoque aceptado en todas las disciplinas
de ingeniería. Un diseño modular reduce la complejidad, facilita los cambios (un
aspecto crítico de la capacidad de mantenimiento del software), y da como
resultado una implementación más fácil al fomentar el desarrollo paralelo de las
diferentes partes de un sistema.

El concepto de independencia funcional es la suma de la modularidad y de los
conceptos de abstracción y ocultación de información. En referencias obligadas
sobre el diseño del software, Pamas y Wirth sugieren a las técnicas de
refinamiento que mejoran la independencia de módulos. Trabajos posteriores de
Stevens, Wyers y Constantine consolidaron el concepto.

La independencia funcional se consigue desarrollando módulos con una función
“determinante” y una “aversión” a una interacción excesiva con otros módulos. Es
necesario diseñar el software de manera que cada módulo trate una subfunción de
requisitos y tenga una interfaz sencilla cuando se observa desde otras partes de la
estructura del programa.

¿Por qué es importante la independencia?
El software con una modularidad efectiva, es decir, módulos independientes, es
más fácil de desarrollar porque la función se puede compartimentar y las

30. Fundamentos de desarrollo de sistemas

105
Paradigmas de la Ingeniería de Software
interfaces se simplifican (tengamos en consideración las ramificaciones cuando el
desarrollo se hace en equipo).

Los módulos independientes son más fáciles de mantener (y probar) porque se
limitan los efectos secundarios originados por modificaciones de diseño/código;
porque se reduce la propagación de errores; y porque es posible utilizar módulos
usables. En resumen, la independencia funcional es la clave para un buen diseño
y el diseño es la clave para la calidad del software.

La independencia se mide mediante dos criterios cualitativos: la cohesión y el
acoplamiento. La cohesión es una medida de la fuerza relativa funcional de un
módulo. El acoplamiento es una medida de la independencia relativa entre los
módulos.

3.1.3.2 Cohesión [2]

La cohesión es una extensión natural del concepto de ocultación de información
(la información que esta dentro de un modulo debe ser inaccesible a otros
módulos que no necesiten esa información). Un módulo cohesivo lleva a cabo una
sola tarea dentro de un procedimiento de software, lo cual requiere poca
interacción con los procedimientos que se llevan a cabo en otras partes de un
programa. Dicho de manera sencilla, un módulo cohesivo deberá (idealmente)
hacer una sola cosa.

La cohesión se puede representar como un “espectro”. Siempre debemos buscar
la cohesión más alta, aunque la parte media del espectro suele ser aceptable. La
escala de cohesión no es lineal. Es decir, la parte baja de la cohesión es mucho
“peor” que el rango medio, que es casi tan “bueno” como la parte alta de la escala.
En la práctica, un diseñador no tiene que preocuparse de categorizar la cohesión
en un módulo específico. Más bien, se deberá entender el concepto global, y así
se deberán evitar los niveles bajos de cohesión al diseñar los códigos.

31. Fundamentos de desarrollo de sistemas

106
Paradigmas de la Ingeniería de Software
3.1.3.2.1 Niveles de cohesión

Cohesión Casual o Coincidental [8] [9] [2]

La cohesión casual ocurre cuando existe poca o ninguna relación entre los
elementos de un módulo.

La cohesión casual establece un punto cero en la escala de cohesión. Es muy
difícil encontrar módulos puramente casuales. Puede aparecer como resultado de
la modularización de un programa ya escrito, en el cual el programador encuentra
un determinada secuencia de instrucciones que se repiten de forma aleatoria, y
decide por lo tanto agruparlas en una rutina.

Otro factor que influenció muchas veces la confección de módulos casualmente
cohesivos, fue la mala práctica de la programación estructurada, cuando los
programadores mal entendían que modularizar consistía en cambiar las
sentencias “GOTO” por llamadas a subrutinas

Finalmente diremos que si bien en la práctica es difícil encontrar módulos
casualmente cohesivos en su totalidad, es común que tengan elementos
casualmente cohesivos. Tal es el caso de operaciones de inicialización y
terminación que son puestas juntas en un módulo superior.

Debemos notar que si bien la cohesión casual no es necesariamente perjudicial
(de hecho es preferible un programa casualmente cohesivo a uno lineal), dificulta
las modificaciones y mantenimiento del código.

Cohesión Lógica [8] [9] [2]

Los elementos de un módulo están lógicamente asociados si puede pensarse en
ellos como elementos que pertenecen a la misma clase lógica de funciones, es
decir aquellas que pueden pensarse como lógicamente juntas.

32. Fundamentos de desarrollo de sistemas

107
Paradigmas de la Ingeniería de Software
Por ejemplo, se puede combinar en un módulo simple todos los elementos de
procesamiento que caen en la clase de "entradas", que abarca todas las
operaciones de entrada. Podemos tener un módulo que lea desde consola una
tarjeta con parámetros de control, registros con transacciones erróneas de un
archivo en cinta, registros con transacciones válidas de otro archivo en cinta, y los
registros maestros anteriores de un archivo en disco. Este módulo que podría
llamarse "Lecturas", y que agrupa todas las operaciones de entrada, es
lógicamente cohesivo.

La cohesión lógica es más fuerte que la casual, debido a que representa un
mínimo de asociación entre el problema y los elementos del módulo. Sin embargo
podemos ver que un módulo lógicamente cohesivo no realiza una función
específica, sino que abarca una serie de funciones.

Cohesión Temporal [8] [9] [2]

Cohesión Temporal significa que todos los elementos de procesamiento de una
colección ocurren en el mismo período de tiempo durante la ejecución del sistema.
Debido a que dicho procesamiento debe o puede realizarse en el mismo período
de tiempo, los elementos asociados temporalmente pueden combinarse en un
único módulo que los ejecute a la misma vez.

Existe una relación entre cohesión lógica y la temporal, sin embargo, la primera no
implica una relación de tiempo entre los elementos de procesamiento. La cohesión
temporal es más fuerte que la cohesión lógica, ya que implica un nivel de relación
más: el factor tiempo. Si embargo la cohesión temporal aún es pobre en nivel de
cohesión y acarrea inconvenientes en el mantenimiento y modificación del
sistema.

Un ejemplo común de cohesión temporal son las rutinas de inicialización (start-up)
comúnmente encontradas en la mayoría de los programas, donde se leen

33. Fundamentos de desarrollo de sistemas

108
Paradigmas de la Ingeniería de Software
parámetros de control, se abren archivos, se inicializan variables contadores y
acumuladores, etc.

Cohesión de Procedimiento [8] [9] [2]

Elementos de procesamiento relacionados procedimentalmente son elementos de
una unidad procedimental común. Estos se combinan en un módulo de cohesión
procedimental que implica una secuencia de ejecución de los pasos. Una unidad
procedimental común puede ser un proceso de iteración (loop) y de decisión, o
una secuencia lineal de pasos. En este último caso la cohesión es baja y es similar
a la cohesión temporal, con la diferencia que la cohesión temporal no implica una
determinada secuencia de ejecución de los pasos.

Al igual que en los casos anteriores, para decir que un módulo tiene solo cohesión
procedimental, los elementos de procesamiento deben ser elementos de alguna
iteración, decisión, o secuencia, pero no deben estar vinculados con ningún
principio asociativo de orden superior.

La cohesión procedimental asocia elementos de procesamiento sobre la base de
sus relaciones algorítmicas o procedimentales.

Este nivel de cohesión comúnmente se tiene como resultado de derivar una
estructura modular a partir de modelos de procedimiento como ser diagramas de
flujo, o diagramas Nassi-Shneiderman.

Cohesión de Comunicación [8] [9] [2]

Ninguno de los niveles anteriores está fuertemente vinculado a una estructura de
problema en particular. Cohesión de Comunicación es el menor nivel en el cual se
encuentra una relación entre los elementos de procesamiento que es
específicamente dependiente del problema.

34. Fundamentos de desarrollo de sistemas

109
Paradigmas de la Ingeniería de Software


Decir que un conjunto de elementos de procesamiento están vinculados por
comunicación significa que todos los elementos operan sobre el mismo conjunto
de datos de entrada o de salida.

En el diagrama de la figura 3.5 podemos observar que los elementos de
procesamiento a, b, y c, están asociados por comunicación sobre la corriente de
datos de entrada, en tanto que b, c, y d se vinculan por los datos de salida.

Los diagramas de flujo de datos (DFD) son un medio objetivo para determinar si
los elementos en un módulo están asociados por comunicación.

Las relaciones por comunicación presentan un grado de cohesión aceptable.

La cohesión por comunicación es común en aplicaciones comerciales. Algunos
ejemplos pueden ser: un módulo que imprima o grabe un archivo de
transacciones; un módulo que reciba datos de diferentes fuentes, y los transforme
y ensamble en una línea de impresión.


a
b
c
d
Figura 3.5 Asociación por comunicación
Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición

35. Fundamentos de desarrollo de sistemas

110
Paradigmas de la Ingeniería de Software
Cohesión Secuencial [8] [9] [2]

En este nivel de cohesión, los datos de salida (resultados) de un elemento de
procesamiento sirven como datos de entrada al siguiente elemento de
procesamiento.

En términos de un diagrama de flujo de datos de un problema, la cohesión
secuencial combina una cadena linear de sucesivas transformaciones de datos.

Este es claramente un principio asociativo relacionado con el dominio del
problema.

Cohesión Funcional [8] [9] [2]

En el límite superior del espectro de relación funcional encontramos la cohesión
funcional. En un módulo completamente funcional, cada elemento de
procesamiento, es parte integral de, y esencial para, la realización de una función
simple.

En términos prácticos podemos decir que cohesión funcional es aquella que no es
secuencial, por comunicación, por procedimiento, temporal, lógica, o casual.

Los ejemplos más claros y comprensibles proviene n del campo de las
matemáticas. Un módulo para realizar el cálculo de raíz cuadrada ciertamente
será altamente cohesivo, y probablemente, completamente funcional. No es
probable que haya elementos superfluos más allá de los absolutamente
esenciales para realizar la función matemática, y no es probable que elementos de
procesamiento puedan ser agregados sin alterar el cálculo de alguna forma.

En contraste un módulo que calcule raíz cuadrada y coseno, es improbable que
sea enteramente funcional (deben realizarse dos funciones ambiguas).

36. Fundamentos de desarrollo de sistemas

111
Paradigmas de la Ingeniería de Software
En adición a estos ejemplos matemáticos obvios, usualmente podemos reconocer
módulos funcionales que son elementales en naturaleza. Un módulo llamado
LEER-REGISTRO-MAESTRO, o TRATAR-TRANS-TIPO3, presumiblemente serán
funcionalmente cohesivos, en cambio TRATAR-TODAS-TRANS presumiblemente
realizará más de una función y será lógicamente cohesivo.

Llegamos a la conclusión que no es necesario determinar el nivel preciso de
cohesión. Más bien, es importante intentar conseguir una cohesión alta y
reconocer cuando hay poca cohesión para modificar el diseño del software y
conseguir una mayor independencia funcional.

3.1.3.3 Acoplamiento [2]

El acoplamiento es una medida de interconexión entre módulos dentro de una
estructura de software. El acoplamiento depende de la complejidad de
interconexión entre los módulos, el punto donde se realiza una entrada o
referencia a un módulo, y los datos que pasan a través de la interfaz.

Los cuatro factores principales que influyen en el acoplamiento entre módulos son:
 Tipo de conexión entre módulos: Los sistemas normalmente conectados,
tienen menor acoplamiento que aquellos que tienen conexiones
patológicas.
 Complejidad de la interfaz: Esto es aproximadamente igual al número de
producto diferentes pasados (no cantidad de datos). Más producto, mayor
acoplamiento.
 Tipo de flujo de información en la conexión: los sistemas con acoplamiento
de datos tienen menor acoplamiento que los sistemas con acoplamiento de
control, y estos a su vez menos que los que tienen acoplamiento híbrido.
 Momento en que se produce el ligado de la Conexión: Conexiones ligadas a
referentes fijos en tiempo de ejecución, resultan con menor acoplamiento
que cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su ver

37. Fundamentos de desarrollo de sistemas

112
Paradigmas de la Ingeniería de Software
menor acoplamiento que cuando el ligado se realiza en tiempo de linkage-
edición, el cual tiene menos acoplamiento que el que se realiza realiza en
tiempo de compilación, todos los que a su vez tiene menos acoplamiento
que cuando el ligado se realiza en tiempo de codificación.

En el diseño del software, intentamos conseguir el acoplamiento más bajo posible.
Una conectividad sencilla entre los módulos da como resultado un software más
fácil de entender y menos propenso a tener un “efecto ola” causado cuando
ocurren errores en un lugar y se propagan por el sistema.


La figura 3.6 proporciona ejemplos de diferentes tipos de acoplamiento de
módulos. Los módulos a y d son subordinados a módulos diferentes. Ninguno está
relacionado y por tanto no ocurre un acoplamiento directo. El módulo c es
subordinado al módulo a y se accede a él mediante una lista de argumentos por la
que pasan los datos. Siempre que tengamos una lista convencional simple de
argumentos (es decir, el paso de datos; la existencia de correspondencia uno a
uno entre elementos), se presenta un acoplamiento bajo (llamado acoplamiento de
datos) en esta parte de la estructura. Una variación del acoplamiento de datos,
a
c b
d
f
e
g h
j
i
k
Estructura
de datos
Estructura
de datos
Datos
(variables)
Indicador de
control
Área de
datos
globales
Figura 3.6 Tipos de acoplamiento
Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición

38. Fundamentos de desarrollo de sistemas

113
Paradigmas de la Ingeniería de Software
llamado acoplamiento de marca (stamp), se da cuando una parte de la estructura
de datos (en vez de argumentos simples) se pasa a través de la interfaz. Esto
ocurre entre los módulos b y a.

En niveles moderados el acoplamiento se caracteriza por el paso de control entre
módulos. El acoplamiento de control es muy común en la mayoría de los diseños
de software y se muestra en la figura. 3.6 en donde un “indicador de control” (una
variable que controla las decisiones en un módulo superior o subordinado) se pasa
entre los módulos d y e.

Cuando los módulos están atados a un entorno externo al software se dan niveles
relativamente altos de acoplamiento. Por ejemplo, la E/S acopla un módulo a
dispositivos, formatos y protocolos de comunicación. El acoplamiento externo es
esencial, pero deberá limitarse a unos pocos módulos en una estructura. También
aparece un acoplamiento alto cuando varios módulos hacen referencia a un área
global de datos. El acoplamiento común, tal y como se denomina este caso, se
muestra en la Figura 3.6. Los módulos c, g y k acceden a elementos de datos en
un área de datos global (por ejemplo, un archivo de disco o un área de memoria
totalmente accesible). El módulo c inicializa el elemento. Más tarde el módulo g
vuelve a calcular el elemento y lo actualiza. Supongamos que se produce un error
y que g actualiza el elemento incorrectamente. Mucho más adelante en el
procesamiento, el módulo k lee el elemento, intenta procesado y falla, haciendo
que se interrumpa el sistema. El diagnóstico de problemas en estructuras con
acoplamiento común es costoso en tiempo y es difícil. Sin embargo, esto no
significa necesariamente que el uso de datos globales sea “malo”. Significa que el
diseñador del software deberá ser consciente de las consecuencias posibles, del
acoplamiento común y tener especial cuidado de prevenirse de ellos.

El grado más alto de acoplamiento, acoplamiento de contenido, se da cuando un
módulo hace uso de datos o de información de control mantenidos dentro de los
límites de otro módulo. En segundo lugar, el acoplamiento de contenido ocurre

39. Fundamentos de desarrollo de sistemas

114
Paradigmas de la Ingeniería de Software
cuando se realizan bifurcaciones a mitad de módulo. Este modo de acoplamiento
puede y deberá evitarse.

3.1.4 Descomposición en procesos [2]

Las fases que generalmente caracterizan al proceso del software son: definición
desarrollo y soporte, se aplican a todo software. El problema es seleccionar el
modelo de proceso apropiado para la ingeniería del software que debe aplicar el
equipo. El gestor del proyecto debe decidir que modelo de proceso es el más
adecuado para:
1. Los clientes que han solicitado el producto y la gente que realizara el
trabajo;
2. Las características del producto en si y
3. El entorno del proyecto en el que trabaja el equipo de software.

Cuando se selecciona un modelo de proceso, el equipo define entonces un plan
de proyecto preliminar basado en conjunto de actividades estructurales. Una vez
establecido el plan preliminar, empieza la descomposición del proceso. Es decir,
se debe crear un plan completo reflejando las tareas requeridas a las personas
para cubrir las actividades estructurales.

Un equipo debería tener un grado significativo de flexibilidad en la elección del
paradigma de ingeniería de software que resulte mejor para el proyecto y de las
tareas de ingeniera del software que conforman el modelo de proceso una vez
elegido.

Un proyecto cuando es relativamente pequeño se debe realizar con un enfoque
secuencial lineal. Si hay limites de tiempo muy severos y le problema se puede
compartir, el modelo apropiado es el DRA. Si se tiene el tiempo limitado lo mas
apropiado es tomar una estrategia incremental.

40. Fundamentos de desarrollo de sistemas

115
Paradigmas de la Ingeniería de Software
Una vez que hemos elegido el modelo de proceso, la Estructura Común de
Procesos (ECP) se adapta a el. En todos los casos, la ECP (comunicación con el
cliente, planificación, análisis de riesgo, ingeniería, construcción, entrega y
evaluación del cliente) puede adaptarse al paradigma. Funcionara para modelos
lineales, para modelos iterativos e incrementales, para modelos de evolución e
incluso para modelos concurrentes o de ensamblaje de componentes. El ECP es
invariable y sirve como base para todo el trabajo de software realizado por una
organización.

Las tareas de trabajo reales si varían. La descomposición del proceso comienza
cuando el gestor del proyecto pregunta ¿Cómo vamos a realizar esta actividad
ECP? Un proyecto simple requiere las siguientes tareas para la actividad de
comunicación con el cliente:
1. Desarrollar una lista de aspectos que se deben aclarar
2. Reunirse con el cliente para aclara los aspectos de la lista
3. Desarrollar en conjunto una exposición del ámbito del proyecto
4. Revisar el alcance del proyecto con todos los implicados
5. Modificar el alcance del proyecto cuando se requiera.

Este tipo de acontecimientos pueden ocurrir en un periodo de menos de 48 hrs.
Representan una descomposición del problema apropiado para proyectos
pequeños relativamente sencillos.

Si se considera un proyecto más complejo que tenga un ámbito más amplio y un
mayor impacto comercial. Un proyecto como ése podría requerir las siguientes
tareas para la actividad de comunicación con el cliente:
1. Revisar la petición del cliente
2. Planificar y programar una reunión formal con el cliente
3. Realizar una investigación para definir soluciones propuestas y
enfoques existentes.
4. Prepara un plan de trabajo y una agenda para la reunión formal

41. Fundamentos de desarrollo de sistemas

116
Paradigmas de la Ingeniería de Software
5. Realizar la reunión
6. Desarrollar conjuntamente mini-especificaciones que reflejen la
información, función y características de comportamiento del
software
7. Revisar todas las mini-especificaciones para comprobar su
corrección , su consistencia la ausencia de ambigüedades
8. Ensamblar las mini-especificaciones de un documento de alcance
del proyecto
9. revisar ese documento general con todo lo que pueda afectar
10. modificar el documento de alcance del proyecto cuando se
requiera

3.2 El enfoque orientado a objetos

El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO)
constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan
en los conceptos de la programación orientada a objetos, que han sido codificados
en UML (Lenguaje Unificado de Modelación), un lenguaje estandarizado de
modelación en el cual los objetos generados no solo incluyen código referente a
los datos sino también instrucciones acerca de las operaciones que se realizaran
sobre los datos.

EL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo y
modelado de software que permite construir más fácilmente sistemas complejos a
partir de componentes individuales.

Objetos + Mensajes = Programa

El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que
comienza con la comunicación con el usuario. Es en esta parte donde se define el
dominio del problema y se identifican las clases básicas del problema. La

42. Fundamentos de desarrollo de sistemas

117
Paradigmas de la Ingeniería de Software
planificación y el análisis de riesgos establecen una base para el plan de proyecto
OO. El trabajo técnico asociado con la ingeniería del software OO sigue las
siguientes tareas:
1. Identificar clases candidatas
2. Buscar clases en biblioteca
3. Extraer nuevas clases si existen
4. Desarrollar las clases sino existen
5. Añadir las nuevas clases a la biblioteca
6. Construir n-esima iteración del sistema

La ingeniería de software hace hincapié en la reutilización. Por lo tanto las clases
se buscan en una biblioteca (de clases existentes) antes de construirse

Las Características del Enfoque Orientado a Objetos son:
a) Objeto: Los datos están cuantificados en entidades discretas y
distinguibles llamadas objetos.
b) Clase: Significa que los objetos con la misma estructura de datos
(atributos) y comportamiento (operaciones) se agrupa para formar
una clase.
c) Atributo: Describen la clase o el objeto de alguna manera
d) Mensajes: Medio por el cual interactúan los objetos
e) Polimorfismo: Significa que una misma operación puede
comportarse de modos distintos en distintas clases.
f) Herencia: Compartir atributos y operaciones entre clases tomando
como base una relación jerárquica.

Objeto

Un objeto es una unidad de código compuesto de variables y métodos
relacionados.

43. Fundamentos de desarrollo de sistemas

118
Paradigmas de la Ingeniería de Software
Un objeto encapsula datos, operaciones, otros objetos, constantes y otra
información relacionada. Pueden ser: Entidades externas, ocurrencias o eventos,
papeles o roles, unidades organizacionales, lugares, estructuras.

Los Objetos tienen características y comportamientos. Mantiene sus
características en una o más "variables", e implementa su comportamiento con
"métodos". Un método es una función o subrutina asociada a un objeto. Cuando a
las características del objeto le ponemos valores decimos que el objeto tiene
estados. Las variables almacenan los estados de un objeto en un determinado
momento.

Para ser considerado como valido un objeto debe de tener las siguientes
características:
 Información retenida
 Servicio necesario
 Atributos múltiples
 Atributos comunes
 Operaciones comunes
 Requisitos esenciales

Clase

La clase es un modelo o prototipo que define las variables y métodos comunes a
todos los objetos de cierta clase.

Una clase es una descripción generalizada que describe una colección de objetos
con características similares.

Todos los objetos que existen dentro de una heredan sus atributos y las
operaciones disponibles para la manipulación de los atributos.

Una superclase es una colección de clases y una instancia de una clase.

44. Fundamentos de desarrollo de sistemas

119
Paradigmas de la Ingeniería de Software
Una instancia de una clase es otra forma de llamar a un objeto. En realidad no
existe diferencia entre un objeto y una instancia. Sólo que el objeto es un término
más general, pero los objetos y las instancias son ambas representación de una
clase.

Atributo

Los Atributos están asociados a clases y objetos, ellos describen la clase y el
objeto de alguna manera. Un atributo puede tomar un valor definido por un
dominio enumerado. En la mayoría de los casos, un dominio es simplemente un
conjunto de valores específicos. En situaciones más complejas el dominio puede
ser un conjunto de clases.

Mensajes

Los mensajes son el medio a través del cual los objetos intercambian información.
Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor.
El comportamiento se realiza cuando se ejecuta una operación.

Un objeto es inútil si está aislado. El medio empleado para que un objeto
interactúe con otro son los mensajes. Hablando en términos un poco más
técnicos, los mensajes son invocaciones a los métodos de los objetos.

Encapsulamiento

El encapsulamiento significa que toda la información de un objeto se encuentra
empaquetada bajo un nombre y puede reutilizarse como una especificación o
componente de un programa.

El encapsulamiento consiste en unir en la clase las características y
comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola

45. Fundamentos de desarrollo de sistemas

120
Paradigmas de la Ingeniería de Software
entidad. En los lenguajes estructurados esto era imposible. Es evidente que el
encapsulamiento se logra gracias a la abstracción y el ocultamiento.

La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya
que tendremos a las Clases como cajas negras donde sól o se conoce el
comportamiento pero no los detalles internos, y esto es conveniente porque nos
interesará será conocer qué hace la clase pero no será necesario saber cómo lo
hace.

EL Ocultamiento es la capacidad de ocultar los detalles internos del
comportamiento de una Clase y exponer sólo los detalles que sean necesarios
para el resto del sistema. [7]

El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir
porque habrá cierto comportamiento privado de la Clase que no podrá ser
accedido por otras Clases. Y controlar porque daremos ciertos mecanismos para
modificar el estado de nuestra Clase y es en estos mecanismos dónde se
validarán que algunas condiciones se cumplan. En Java el ocultamiento se logra
usando las palabras reservadas: public, private y protected delante de las
variables y métodos.

Herencia

La herencia consiste en que una clase puede heredar sus variables y métodos a
varias subclases (la clase que hereda es llamada superclase o clase padre). Esto
significa que una subclase, aparte de los atributos y métodos propios, tiene
incorporados los atributos y métodos heredados de la superclase. De esta manera
se crea una jerarquía de herencia. La herencia reduce el trabajo de la
programación usando fácilmente objetos comunes. Solo es necesario declarar
que la clase A hereda de la clase B y después proporcionar cualquier detalle

46. Fundamentos de desarrollo de sistemas

121
Paradigmas de la Ingeniería de Software
adicional. Los atributos y comportamientos de la clase B son parte de la clase A y
no requiere ninguna programación adicional. [7]

Polimorfismo

El polimorfismo permite que un número de operaciones diferentes tengan el
mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno
más independiente.

3.2.1 Análisis

El AOO ha sido muy exitoso en derribar problemas que se resisten al análisis
estructurado, como las interfaces de usuario. El AOO proporciona una transición
sin igual hacia el DOO y la programación en lenguajes como Smalltalk, Ada y C++,
y es el método de análisis preferido cuando los métodos orientados a objetos van
a ser utilizados posteriormente en la vida del sistema. Además, los partidarios del
AOO argumentan que los objetos dentro de un sistema son más fundamentales
(importantes, necesarios) para su naturaleza que las funciones que proporciona.
Las especificaciones basadas en los objetos serán más adaptables que las
especificaciones basadas en las funciones.

Los métodos que marcan las directrices del AOO son:
 Coad-Yourdon
 Técnica de modelado de objetos de Rumbaugh (Object Modelling
Technique OMT)
 Shlaer-Mellor
 Booch
 ROOM
 Fusión

Coad y Yourdon

47. Fundamentos de desarrollo de sistemas

122
Paradigmas de la Ingeniería de Software

Coad y Yourdon describen un método de Análisis Orientado a Objetos basado en
cinco actividades principales:
 Definición de las clases y objetos
 Identificación de estructuras
 Identificación de temas
 Definición de atributos
 Definición de servicios

Estas actividades son usadas para construir cada capa de un modelo de objetos
de “cinco niveles”. Los objetos existen en el ámbito del problema. Las clases son
abstracciones de objetos. Los objetos son instancias de clases. La primera tarea
del método es identificar las clases y los objetos.

La segunda tarea del método es identificar las estructuras. Se reconocen dos tipos
de estructuras: “estructuras de generalización especialización” y “estructuras
globales [whole-part]”. El primer tipo de estructura es como un árbol genealógico:
es posible la herencia entre los miembros de una estructura. El segundo tipo de
estructura es utilizado para modelar relaciones de entidades (por ejemplo: cada
motor contiene una armadura).

Los modelos grandes y complejos pueden necesitar una organización ‘temática’,
con cada (asunto, atributo, en lugar de tema) tema dedicado a un aspecto
particular del problema. Por ejemplo, el modelo de objetos de un vehículo de
motor puede tener una perspectiva mecánica o una perspectiva eléctrica.

Los atributos caracterizan a cada clase. Por ejemplo, un atributo de una máquina
puede ser el “numero de cilindros”. Cada objeto tendrá un valor para ese atributo.
Los servicios definen lo que los objetos hacen. Definir los servicios es equivalente
a definir las funciones del sistema.

48. Fundamentos de desarrollo de sistemas

123
Paradigmas de la Ingeniería de Software
La importancia fundamental del método de Coad y Yourdon es su descripción
breve y concisa, así como el uso de textos generales como fuentes para las
definiciones; de modo que las definiciones se enmarcan dentro del sentido común
y reducen el empleo de modismos. La debilidad principal del método es su
notación compleja, la cual es difícil de utilizar sin el apoyo de una herramienta.
Algunos usuarios del método Coad-Yourdon han utilizado la dotación de
diagramación de OMT en su lugar.

Técnica de Modelado de Objetos

La Técnica de Modelado de Objetos (OMT, Object Modelling Technique)
transforma la definición del problema del usuario (como la que se documenta en
un Documento de Requerimientos del Usuario) en tres modelos:
 Modelo de objetos
 Modelo dinámico
 Modelo funcional

Los tres modelos en conjunto crean el modelo lógico requerido por los Estándares
de Ingeniería de Software.

El modelo de. El procedimiento para construirlo es el siguiente:
 Identificación de los objetos
 Identificación de las clases de objetos
 Identificación de las asociaciones (ejemplo: las relaciones) entre objetos
 Identificación de los atributos de los objetos
 Uso de herencia para organizar y simplificar la estructura de clases
 Organización de las clases y asociaciones estrechamente acopladas dentro
de módulos
 Acompañar a cada objeto con breves descripciones textuales

49. Fundamentos de desarrollo de sistemas

124
Paradigmas de la Ingeniería de Software
Los tipos más importantes de asociación son la adición (es parte de) y la
generalización (es un tipo de).

El modelo dinámico muestra el comportamiento del sistema, especialmente la
secuencia de interacciones. El procedimiento para construirlo es el siguiente:
 Identificar las secuencias de eventos dentro del ámbito del problema y
documentarlo en el ‘seguimiento (rastreo) de eventos’
 Construir un diagrama de transición de estados para cada objeto que sea
afectado por los eventos, mostrando los mensajes que fluyen, las acciones
que son realizadas y los cambios en el estado de los objetos que tienen
lugar cuando ocurren los eventos.

El modelo funcional muestra la forma en que se obtienen los valores, sin
considerar el momento en que sean computadas. El procedimiento para
construirlo no requiere el uso de la descomposición funcional, sino de:
 Identificar la entrada y salida de valores que el sistema recibe y produce
 Construir diagramas de flujo de datos que muestren la forma en que los
valores de salida son computados a partir de los valores de entrada
 Identificar los objetos que son utilizados como ‘almacenes de datos’
 Identificar las operaciones de los objetos que comprenden cada proceso

El modelo funcional es sintetizado a partir de las operaciones de objetos, en vez
de descomponerlo desde una función de alto nivel. Las operaciones de los objetos
pueden ser definidos en cualquier etapa durante el modelado. Los aspectos más
importantes del OMT son sus capacidades simples aunque poderosas de notación
así como su madurez. Ha sido aplicado en varios proyectos por sus autores antes
de ser publicado. La principal debilidad es la falta de técnicas para integrar los
modelos de objetos, los modelos dinámicos y los modelos funcionales.

50. Fundamentos de desarrollo de sistemas

125
Paradigmas de la Ingeniería de Software
Schlaer y Mellor

Schlaer y Mellor comienzan el análisis identificando el ámbito del problema del
sistema. Cada ámbito es un mundo separado habitado por sus propias entidades
conceptuales u objetos. Los ámbitos más grandes son divididos en subsistemas.
Después, cada ámbito o subsistema es analizado de forma separada en tres
etapas:
 Modelado de la información
 Modelado de estado
 Modelado de procesos

Las tres actividades de modelado crean en conjunto el modelo lógico requerido
por los Estándares de Ingeniería de Software.

El objetivo del modelado de información es identificar:
 Los objetos dentro del sistema
 Los atributos de cada objeto
 Las relaciones entre cada objeto

El modelo de información es documentado mediante diagramas y definiciones de
objetos, atributos y relaciones.

El objetivo del modelo de estado es identificar:
 Los estados de cada objeto, y las acciones que se realizan sobre ellos
 Los eventos que causan que los objetos pasen de un estado a otro
 Las secuencias de estados que forman el ciclo de vida de cada objeto
 Las secuencias de mensajes que comunican los eventos que fluyen entre
los objetos y los subsistemas

Los modelos de estado son documentados mediante diagramas de modelo de
estados (mostrando las secuencias de estados), diagramas de modelos de

51. Fundamentos de desarrollo de sistemas

126
Paradigmas de la Ingeniería de Software
comunicación de objetos (mostrando los mensajes que fluyen entre los estados), y
listas de eventos.
El objetivo del modelo de proceso es identificar:
 Las operaciones de cada objeto requeridas durante cada acción
 Los atributos de cada objeto que son almacenados en cada acción

Los modelos de proceso son documentados mediante diagramas de acción de
flujo de datos, mostrando las operaciones y el flujo de datos que ocurren en cada
acción, y los diagramas de modelo de acceso de objeto, mostrando el acceso de
datos entre objetos. Los procesos complejos también deben ser descritos.

La fuerza del método Schlaer-Mellor es su madurez (sus autores declaran haber
estado desarrollándolo desde 1979) y la existencia de técnicas para integrar los
modelos de información, los modelos de estado y los modelos de proceso. La
principal debilidad del método es su complejidad.

Booch

Booch modela un diseño orientado a objetos desde un punto de vista lógico, el
cual define las clases, los objetos y sus relaciones; y desde un punto de vista
físico, que define la arquitectura de módulos y procesos. La perspectiva lógica
corresponde al modelo lógico que deben construir los ingenieros de software de
acuerdo a los requerimientos de los estándares de Ingeniería de Software. El
método orientado a objetos de Booch tiene cuatro pasos:
1. Identificación de clases y objetos a un nivel dado de abstracción
2. Identificación de la semántica de estas clases y objetos
3. Identificación de las relaciones entre esas clases y objetos
4. Implementación de las clases y objetos

Las primeras tres etapas deben ser completadas dentro de la etapa de
Requerimientos del Sistema. La última etapa es realizada dentro de las fases de

52. Fundamentos de desarrollo de sistemas

127
Paradigmas de la Ingeniería de Software
AD y DD. Booch sostiene que el proceso de diseño orientado a objetos no es
deductivo [top-down] ni inductivo [bottom Up], sino algo que él denomina ‘round-
trip gestalt design’ [diseño gestalt (conocimiento) de viaje redondo]. El proceso
desarrolla un sistema a manera de incrementos e iteraciones. A los usuarios del
método de Booch se les advierte que deben integrar las fases SR y AD en una
sola ‘fase de modelado’.

Booch ofrece cuatro técnicas para la documentación de la perspectiva lógica:
 Diagramas de clase: consiste en un conjunto de clases y relaciones entre
ellas. Puede contener clases, clases paramétricas, utilidades y metaclases.
Los tipos de relaciones son asociaciones, contenencia, herencia, uso,
instanciación y metaclase.
 Diagramas de objetos: muestra objetos en el sistema y su relación lógica.
Pueden ser diagramas de escenario, donde se muestra cómo colaboran los
objetos en cierta operación; o diagramas de instancia, que muestra la
existencia de los objetos y las relaciones estructurales entre ellos
 Diagramas de estado-transición: muestran los estados posibles de cada
clase, así como los eventos que ocasionan las transiciones de un estado a
otro
 Diagramas de tiempo: aumenta un diagrama de objetos con información
acerca de eventos externos y tiempo de llegada de los mensajes

Los libros de Booch sobre métodos orientados a objetos han sido descritos por
Stroustrup, el inventor de C++, como los únicos y mejores libros sobre el tema.
Este cumplido revela los diversos alcances y la profundidad de un buen análisis y
práctica de diseño en sus escritos. Sin embargo, la notación de Booch es molesta
y hay pocas herramientas disponibles.

ROOM

53. Fundamentos de desarrollo de sistemas

128
Paradigmas de la Ingeniería de Software
ROOM es una metodología de Modelado Orientada a Objetos en Tiempo Real
desarrollado por la compañía Object Time Developer. Esta metodología ofrece
varios puntos importantes:
 La complejidad esencial de reactivar sistemas es suficientemente alta para
requerir conceptos de modelado especializado.
 ROOM toma ventajas de muchos desarrollos recientes de la tecnología de
computadoras (métodos formales, el paradigma de objetos, interfaces
gráficas al usuario)
 También, ROOM fue diseñado explícitamente para tomar ventaja de la
automatización basada en computadoras de las demás actividades
mecánicas de desarrollo.
 Esto proporciona un potencial único para beneficios significativos en
productividad y calidad

Estructura del modelado
 Utiliza sintaxis gráfica para una fácil comprensión
 Abstracciones para tratar con fenómenos arquitectónicos de alto nivel de
grandes sistemas de tiempo real.
 Protocolo basado en múltiples interfaces
 Objetos concurrentes (actores)
 Estructuras dinámicas
 Estructuras reproducidas

Modelado del comportamiento
 Alto nivel basado en sintaxis gráfica
 Utiliza máquinas de estado jerárquicas; Permite elegir el modelado
poderoso de capacidades, al tiempo que permite implementaciones
automatizadas avanzadas y eficientes
 Prioridad basada en la manipulación de eventos para tratar con
requerimientos de tiempo real

54. Fundamentos de desarrollo de sistemas

129
Paradigmas de la Ingeniería de Software
 Incorpora la industria de lenguajes de programación estándar (por ejemplo:
C++) para detalles específicos.

Experiencia
 Más de cien diferentes proyectos industriales han utilizado ROOM
 Varios dominios de aplicación:Incluyendo generación de código automático
completo

Fusión

El Método Fusión está considerado como uno de los métodos de desarrollo de
“Segunda Generación”. Proporciona elementos de desarrollo para y con
reusabilidad y reingeniería. Los siguientes métodos o técnicas han influido en
Fusión:
 OMT (Rumbaugh, 1991): El modelo Objeto es casi similar que en OMT. El
modelo operacional es análogo al modelo funcional en OMT; los diagramas
de flujo de datos de OMT no son apropiados de acuerdo con Coleman y
han sido formalizados con pre y post condiciones.
 Métodos formales: pre y post condiciones son adoptados para describir
formalmente qué es lo que hace un sistema.
 CRC: CRC extendido con información de comunicación ha influenciado en
gráficas de interacción de objetos.
 Diseño OO con Aplicaciones (Booch,1991):La visibilidad de las gráficas son
influenciadas por información de visibilidad en los diagramas Objeto de
Booch.

Fusión se basa en un pequeño pero comprensivo conjunto de técnicas para
creación de diagramas bien definidas para la descripción de las etapas de análisis
y diseño. Fusión consiste de 3 fases: análisis, diseño e implementación. Fusión
también proporciona reglas para verificar la consistencia e integridad del desarrollo
de los modelos.

55. Fundamentos de desarrollo de sistemas

130
Paradigmas de la Ingeniería de Software

En la fase de análisis se define el comportamiento propuesto del sistema. Los
modelos en esta fase describen las clases de objetos, las relaciones entre clases,
las operaciones que pueden ser ejecutadas en el sistema y permite la realización
de secuencias de esas operaciones.

En la fase de diseño, los modelos producidos muestran la forma en que las
operaciones del sistema son implementadas por objetos interactivos, referencias
entre clases, relaciones de herencia, atributos de clases y operaciones en clases.

En la fase de implementación, la herencia, la referencia y los atributos de las
clases son implementados en clases de un lenguaje de Programación. Las
interacciones entre objetos son programados como métodos pertenecientes a la
clase. Las máquinas estado (State Machines) son implementadas para reconocer
secuencias permitidas de operaciones. En sus actividades se encuentran la
codificación, ejecución y revisión.

Fusión mantiene un diccionario de datos, un repositorio donde las diferentes
entidades del sistema pueden ser nombradas y descritas.

3.2.2 Diseño [12][13]

El Diseño Orientado a Objetos (DOO) es un enfoque del diseño de software
basado en objetos y clases. Un objeto es una abstracción de algo en el dominio de
un problema o su implementación, reflejando las capacidades de un sistema para
proporcionar información acerca de él mismo, interactuar con él o con ambos; es
un encapsulamiento de valores de atributo y sus servicios exclusivos. Una clase
describe un conjunto de objetos con atributos y servicios comunes. Un objeto es
una “instancia” de una clase, y el acto de crear un objeto se denomina:
“instantiation”.

56. Fundamentos de desarrollo de sistemas

131
Paradigmas de la Ingeniería de Software
Las clases pueden ser entidades con tipos de datos abstractos, como el “Paquete
de Telemetría” y “Espectro”, así como entidades más simples con tipos de datos
primitivos como números reales, enteros y cadenas de caracteres. Una clase es
definida por sus atributos y servicios. Por ejemplo, la clase “Espectro” tendría
atributos como “frecuencia mínima”, “frecuencia media”, “frecuencia máxima” y
servicios tales como “calibrar”.
Las clases pueden ser divididas en subclases. Por ejemplo, pueden existir varios
tipos de Paquetes de Telemetría, y pueden ser creadas subclases de Paquete de
Telemetría tales como “Paquete de Fotómetro” y “Paquete de Espectómetro”. Las
subclases comparten características familiares, y el DOO permite para ello, que
las subclases hereden operaciones y atributos de sus padres. Esto conduce hacia
sistemas modulares y estructurados, que requieren menos código para ser
implementados. El código común es automáticamente localizado de una manera
top-down.

Los métodos de diseño orientado a objetos, a diferencia de otros, ofrecen un mejor
soporte para la reutilización. El mecanismo tradicional de reusó “bottom-up” donde
es perfectamente posible que un módulo de aplicación llame a un módulo de
librería. Además, la característica de herencia permite el reuso “top-down” de los
atributos y las operaciones de la superclase.

El DOO combina servicios e información, con esto incrementa la modularidad. Las
estructuras de control y datos pueden ser definidas de una manera integrada.
Otras características del enfoque orientado a objetos, además de las clases, los
objetos y la herencia son la transmisión de mensajes y el polimorfismo. Los
objetos envían mensajes a otros objetos para dirigir sus servicios. Los mensajes
también son utilizados para transmitir información. El polimorfismo es la
capacidad, al momento de la ejecución del programa, para referirse a las
instancias de varias clases. El polimorfismo es a menudo implementado para
permitir “enlaces dinámicos”.

57. Fundamentos de desarrollo de sistemas

132
Paradigmas de la Ingeniería de Software
Las características de la orientación a objetos como polimorfismo recaen en la
asignación dinámica de memoria. Esto puede hacer imprevisible el desempeño del
software orientado a objetos. Debe tenerse cuidado al momento de programar
aplicaciones de tiempo real para asegurar que las funciones que deben
completarse dentro de un límite definido tengan su procesamiento completamente
definido al momento de la compilación y no durante la ejecución.

El DOO es más efectivo cuando se implementa mediante lenguajes de
programación orientado a objetos que soporten la definición de objeto, herencia,
intercambio de mensajes y polimorfismo. Smalltalk, C++, Eiffel y Object Pascal
soportan todas estas características.

Las técnicas orientadas a objetos han demostrado ser mucho más satisfactorias
para la implementación de software conducido por eventos, como las Interfaces
Gráficas de Usuario (GUIs), que los métodos estructurados. Muchas herramientas
CASE para los métodos estructurados han sido mejoradas para las técnicas
orientadas a objetos.

Si los métodos orientados a objetos van a ser utilizados, esto debe hacerse a todo
lo largo del ciclo de vida. Esto significa que el DOO solamente debe ser
seleccionado para la fase AD si el Análisis Orientado a Objetos (OOA) ha sido
utilizado en la fase de SR. La transición del análisis al diseño, y de este a la
programación es una de las mayores ventajas de los métodos orientados a
objetos, ya que facilita la interacción. Uno de los primeros trabajos realizados por
Booch, describe una técnica para el diseño orientado a objetos. En la práctica los
resultados no han sido satisfactorios. La perspectiva del análisis estructurado está
basado en las funciones y en los datos, y el enfoque de la orientación a objetos
está basada es clases, objetos, atributos y servicios. Estos enfoques son muy
diferentes y es difícil mantenerlos en mente simultáneamente.

58. Fundamentos de desarrollo de sistemas

133
Paradigmas de la Ingeniería de Software
Al igual que el diseño estructurado, el diseño orientado a objetos no es un método
único, sino un nombre para designar una clase de métodos. Los miembros
(Members) de esta clase incluyen:
 Booch;
 Diseño Jerárquico Orientado a Objetos (HOOD);
 Coad-Yourdon;
 Técnica del Modelado de Objetos (OMT)
 Shlaer-Mellor.

En seguida se describe cada uno de ellos.

Booch

Booch creó el diseño orientado a objetos, y continúa jugando un papel principal en
el desarrollo del método.

Booch modela un diseño orientado a objetos en términos de un enfoque lógico, el
cual define las clases, los objetos y sus relaciones, y un enfoque físico, el cual
define la arquitectura de módulos y procesos. El enfoque lógico corresponde al
modelo lógico que requieren los estándares de la Ingeniería del Software para
construir en la fase de SR. El enfoque físico corresponde al modelo físico que
estos mismos estándares requieren para construir en la fase AD.

Booch proporciona dos técnicas de diagramación para documentar el enfoque
físico:
 Diagramas de módulo, son utilizados para mostrar la asignación de clases y
objetos hacia los módulos, como los programas, paquetes y tareas en el
diseño físico (el término “módulo” en el método de Booch es utilizado para
describir cualquier componente del diseño);
 Diagramas de procesos, muestran la asignación de módulos hacia los
procesadores de hardware.

59. Fundamentos de desarrollo de sistemas

134
Paradigmas de la Ingeniería de Software
Los libros de Booch en Diseño Orientado a Objetos contienen muchos análisis
sobre la práctica del buen diseño. Sin embargo, la notación de Booch puede llegar
a ser molesta y existen pocas herramientas disponibles.

HOOD

HOOD (Hierarchical Object-Oriented-Design) El diseño jerárquico orientado a
objetos (HOOD) es miembro de una familia de métodos orientados a objetos que
tratan de integrar la orientación a objetos con los métodos de diseño estructurado.
La jerarquía sigue naturalmente a la división del objeto raíz del nivel más alto. Al
igual que en el diseño estructurado, las parejas de datos fluyen entre
componentes del software. La principal diferencia entre HOOD y los métodos
estructurados es que los componentes del software obtienen su identidad de su
correspondencia con cosas en el mundo real, en vez de las funciones que el
sistema tiene que realizar.

HOOD fue originalmente diseñado para utilizarse con Ada, aunque Ada no soporta
la herencia, y no es un lenguaje de programación orientado a objetos. Este no es
un problema serio para el diseño HOOD, porque el método no utiliza clases para
estructurar los sistemas.

HOOD no tiene un método de análisis complementario. El modelo lógico
normalmente es construido utilizando el análisis estructurado. La transformación
del modelo lógico al modelo físico es difícil, haciendo difícil la construcción de un
diseño coherente.

HOOD ha sido incluido en aplicaciones Ada. Cuenta ya con un nicho, pero es poco
probable que llegue a tener una difusión y un apoyo tan amplio por parte de las
herramientas como, por ejemplo, OMT

60. Fundamentos de desarrollo de sistemas

135
Paradigmas de la Ingeniería de Software
Coad y Yourdon

Coad y Yourdon han publicado un enfoque integral para el análisis y diseño
orientado a objetos. Un diseño orientado a objetos es construido a partir de 4
componentes:
 Componente del ámbito del problema;
 Componente de interacción humana;
 Componente de administración de tareas;
 Componente de administrador de datos.

Cada componente está compuesto de clases y objetos. El componente del ámbito
del problema está basado en el modelo (lógico) construido con el AOO en la fase
de análisis. Define el tema de estudio del sistema y sus responsabilidades. Si el
sistema va a ser implementado en un lenguaje orientado a objetos, la
correspondencia entre las clases y los objetos del ámbito del problema serán uno
a uno, y el componente del ámbito del problema podrá ser programado
directamente. Sin embargo, el refinamiento substancial del modelo lógico es
normalmente requerido, resultando en la incorporación de más atributos y
servicios. Las consideraciones de reuso, y la no disponibilidad de un lenguaje de
programación totalmente orientado a objetos, pueden hacer que el diseño del
componente del ámbito del problema parta de un ideal representado por el modelo
de AOO.

Los componentes poco amigables en la interacción humana envían y reciben
mensajes a y desde el usuario. Las clases y objetos en el componente de
interacción humana tiene nombres que son tomados desde el lenguaje de interfaz
del usuario, por ejemplo: una ventana y un menú.

Muchos sistemas tendrán hilos múltiples de ejecución, y el diseñador debe
construir un componente de manejo de tareas para organizar el procesamiento. El

61. Fundamentos de desarrollo de sistemas

136
Paradigmas de la Ingeniería de Software
diseñador necesita definir tareas como manejo de eventos (event-driven) o manejo
del tiempo (clock-driven), así como sus prioridades de manera crítica.

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

Los cuatro componentes juntos hacen el modelo físico del sistema. En el nivel más
alto, todos los diseños de Coad y Yourdon Orientado-a-Objetos tienen la misma
estructura.

Las clases y los objetos son organizados en la “generalización-especialización” y
en las estructuras completas (wholepart). Las estructuras de generalización
especialización son “familiar de árboles”, con hijos heredando los atributos de sus
padres. Estructuras de partes completas (whole-part) son formadas cuando un
objeto es descompuesto.

La fuerza de los métodos Coad y Yourdon son sus instrucciones, descripciones
breves y su uso de texto general como fuentes de definiciones, así que las
definiciones se ajustan al sentido común y el jargon es minimizado. El significado
de debilidad del método es su notación compleja, la cual es difícil de utilizarla sin
herramientas de soporte. Algunos usuarios han utilizado en lugar del método
Coad-Yourdon la notación de diagramación de OMT.

OMT

La Técnica de Modelación de Objetos (Object Modelling Technique OMT) en el
diseño tiene un alto nivel estratégico y decisión para resolver los problemas. Los
problemas grandes se deben ver desde el punto de análisis y diseño, este sistema
se divide en subsistemas, a su vez este subsistema puede ser dividido en otros

62. Fundamentos de desarrollo de sistemas

137
Paradigmas de la Ingeniería de Software
subsistemas de manera que puedan ser manejados y cada componente pueda se
comprensible.

En esta etapa se deben crear estrategias, formular una arquitectura para el
sistema y las políticas que deben guiarla además un detalle del diseño. Se deben
tener en cuenta los siguientes aspectos:
 Distinguir una arquitectura
 Elegir una implementación para un control externo
 Si se usa base de datos elegir el paradigma de administración de base de
datos
 Determinar oportunidades para el reuso
 Elegir estrategia para interacción de datos
 Elegir una forma de identificar los objetos
 Detallar el diseño

Durante el diseño del sistema se debe hacer un cuadro de estrategias y
decisiones arquitecturales, tener una idea más precisa de clases y métodos
individuales. Adicionalmente se puede mejorar el modelo de diseño para mejorar
la implementación. Se debe considerar los siguientes pasos:
 Uso de transformaciones para simplificar y optimizar el modelo de objetos
desde el análisis.
 Elaborar un modelo de objeto
 Elaborar un modelo funcional
 Evaluar la calidad del diseño del modelo
 Implementación

El diseño es trasladado a un lenguaje de programación actual y código de base de
datos. Este paso puede ser aplicado y considerado durante el análisis y diseño

63. Fundamentos de desarrollo de sistemas

138
Paradigmas de la Ingeniería de Software
Shlaer y Mellor

Shlaer y Mellor describen un Lenguaje de Diseño Orientado a Objetos (OODLE),
derivado de la notación de Booch y Buhr. Existen cuatro tipos de diagramas:
 Diagrama de Clases que muestran relaciones de utilización
(cliente/servidor) y de amigos entre clases.
 Gráfica de la estructura de Clase (class) que muestran el aspecto externo
de la clase de forma similar a Booch.;
 Diagrama de Dependencias muestran la estructura de los métodos de la
clase, el flujo de datos y de control;
 Diagrama de Herencia: representan la herencia.

Existe un diagrama de clase para cada clase. El diagrama de clase define las
operaciones y atributos de la clase. La gráfica de la estructura de clase define la
estructura del módulo de la clase (class), el control y flujo de datos entre los
módulos de las clases. Existe una gráfica de la estructura de la clase para cada
clase.

Los diagramas de Dependencia muestran las dependencias entre clases, las
cuales pueden ser:
 Cliente - servidor;
 Amigables.

Una dependencia cliente-servidor existe cuando una clase (el cliente) llama en las
operaciones a otras clases (el servidor).

Una dependencia de amistad existe cuando una clase accede al dato interno de
otra clase. Esto es una violación de información ocultación.

Los diagramas de herencia muestran la herencia de relaciones entre clases.

64. Fundamentos de desarrollo de sistemas

139
Paradigmas de la Ingeniería de Software
BIBLIOGRAFÍA

[1] Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª Edicion.
[2] Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición
[3] Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª
edición

REFERENCIAS WEB

[4] Instituto Nacional de Estadística e Informática, Realidad Virtual “Tecnología Orientada a
Objetos” [En línea], Perú [Consulta: Septiembre de 2006],
<http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/IND.htm>
[5] Tejerina Martín, Monografías Lucas Morea, Sinexi SA, “Programación Orientada a
Objetos”, [Consulta: Marzo de 2006] <http://www.monografias.com/trabajos14/progorie/
progorie.shtml>
[6] Departamento de Auditoria Informática UNAM, “Metodologías de Ingeniería de Software”
[En línea], México [Consulta: Marzo de 2006] <http://sistemas.dgsca.unam.mx/publica/
pdf/metodologias.PDF>
[7] Ciberaula, “Tecnología Orientada a Objetos” [En línea], Madrid España [Consulta: Marzo
de 2006], <http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/>
[8] A.U.S. GustavoTorossi, “Apuntes de diseño estructurado: Cohesión” [En línea], Provincia
de Chaco Republica de Argentina [Consulta: Marzo de 2006] <http://www.chaco.gov.ar/
utn/disenodesistemas/apuntes/de/Unidad_5.html>
[9] Fernando Berzal, “Cohesión y Acoplamiento” [En línea], España [Consulta: Marzo de
2006], <http://elvex.ugr.es/decsai/java/pdf/4D-cohesion.pdf>
[10] A.U.S. GustavoTorossi, “Apuntes de diseño estructurado: Acoplamiento” [En línea],
Provincia de Chaco Republica de Argentina [Consulta: Marzo de 2006]
<http://www.chaco.gov.ar/utn/disenodesistemas/apuntes/de/Unidad_4.html>
[11] Creative Commons, “Metodologías usadas en ingeniería del software” [En linea],
Murcia España [Consulta: Marzo de 2006], <http://www.um.es/docencia/barzana/IAGP/
Iagp3.html>
[12] Javier Alberto Moya Espinoza, Copyright © Ilustrados, “Metodología OMT” [En línea],
[Consulta: Marzo de 2006] < http://www.ilustrados.com/publicaciones/EpZVVyAky
uqpxfFpAs.php
[13] Instituto Tecnológico de la Laguna, Analisis y Diseño Orientado a Objetos “Métodos y
Modelos” [En línea], México[Consulta: Marzo de 2006], <http://www.itlalaguna.edu.mx/
academico/carreras/sistemas/Analisis%20y%20dise%F1o%20orientado%20a%20objetos
/cap2.pdf#search=%22metodo%20hood%22