Fundamentos de desarrollo de sistemas
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.
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.
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.

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
sustantivoverboadjetivo. El sustantivo indica cual es el
resultado principal del proceso, tal como INFORME O REGISTRO. El
verbo describe el tipo 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.
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.
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.

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
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 NOM­BRE 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 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 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 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
sustantivoverboadjetivo. 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 comu­nicación en lugar de
facilitada. Si en un 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 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.


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.
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.
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.
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.
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 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.
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.
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
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 re­gistros 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.
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 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 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.
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)
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.

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 se, 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 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 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.
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.
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 (startup) comúnmente encontradas en la mayoría de los
programas, donde se leen 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 NassiShneiderman.
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.

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.
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 provienen 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).
En adición a estos ejemplos matemáticos obvios, usualmente podemos
reconocer módulos funcionales que son elementales en naturaleza. Un
módulo llamado LEERREGISTROMAESTRO, o TRATARTRANSTIPO3,
presumiblemente serán funcionalmente cohesivos, en cambio
TRATARTODASTRANS 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 menor acoplamiento que cuando el
ligado se realiza en tiempo de linkageedició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, 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 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.
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
5.
Realizar la reunión
6.
Desarrollar conjuntamente miniespecificaciones que reflejen la
información, función y características de comportamiento del
software
7.
Revisar todas las miniespecificaciones para comprobar su
corrección , su consistencia la ausencia de ambigüedades
8.
Ensamblar las miniespecificaciones 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 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 nesima 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.
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.
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 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ólo 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 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:
*
CoadYourdon
*
Técnica de modelado de objetos de Rumbaugh (Object Modelling
Technique OMT)
*
ShlaerMellor
*
Booch
*
ROOM
*
Fusión
Coad y Yourdon
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 [wholepart]”. 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.
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 CoadYourdon 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
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.
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
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 SchlaerMellor 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 AD y DD. Booch sostiene que el proceso de diseño orientado a
objetos no es deductivo [topdown] ni inductivo [bottom Up], sino algo
que él denomina ‘roundtrip 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 estadotransició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
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
*
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.
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”.
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 topdown.
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ó “bottomup” 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 “topdown” 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”.
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.
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);
*
CoadYourdon;
*
Técnica del Modelado de Objetos (OMT)
*
ShlaerMellor.
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.
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 ObjectOrientedDesign) 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
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 diseñador necesita definir tareas como manejo de
eventos (eventdriven) o manejo del tiempo (clockdriven), 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
OrientadoaObjetos tienen la misma estructura.
Las clases y los objetos son organizados en la
“generalizaciónespecializació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 (wholepart) 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
CoadYourdon 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 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
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 clienteservidor 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.
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],

5.
Tejerina Martín, Monografías Lucas Morea, Sinexi SA, “Programación
Orientada a Objetos”, [Consulta: Marzo de 2006]

6.
Departamento de Auditoria Informática UNAM, “Metodologías de
Ingeniería de Software” [En línea], México [Consulta: Marzo de
2006]
7.
Ciberaula, “Tecnología Orientada a Objetos” [En línea], Madrid
España [Consulta: Marzo de 2006],

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]
9.
Fernando Berzal, “Cohesión y Acoplamiento” [En línea], España
[Consulta: Marzo de 2006],

10.
A.U.S. GustavoTorossi, “Apuntes de diseño estructurado:
Acoplamiento” [En línea], Provincia de Chaco Republica de
Argentina [Consulta: Marzo de 2006]

11.
Creative Commons, “Metodologías usadas en ingeniería del software”
[En linea], Murcia España [Consulta: Marzo de 2006],

12.
Javier Alberto Moya Espinoza, Copyright © Ilustrados, “Metodología
OMT” [En línea], [Consulta: Marzo de 2006]
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], academico/carreras/sistemas/Analisis%20y%20dise%F1o%20orientado%20a%20objetos/cap2.pdf#search%22metodo%20hood%22
141
Paradigmas de la Ingeniería de Software