pruba de "sdf"

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.

76Paradigmas de la Ingeniería de Software


c) Solución declarativa. Señala las características que debe tener la solución,

sin describir cómo procesarla. Es decir señala qué se desea obtener pero

no cómo obtenerlo.

3.1 El enfoque estructurado

3.1.1 Diagramas de flujos de datos [3]

El DFD (Data Flow Diagram) surgió de la necesidad de un nuevo método de

especificación sencillo de implantar, fácil comprensión y comunicación.

El DFD fue desarrollado por De Marco en los años 70’s y fue popularizado por

Yourdan. Es un método de especificación utilizado hasta la fecha. Para empezar

se puede preguntar ¿Que son los diagramas de flujos de Datos?

Un diagrama de flujo de datos (DFD) es una representación gráfica de los

procesos que se realizan con los datos en su organización, con el uso de tan solo

cuatro símbolos, se puede crear una descripción grafica de los procesos que, con

el tiempo, contribuirán a desarrollar una sólida documentación del sistema.

En seguida mencionan las ventajas sobre las explicaciones descriptivas en

relación con la forma en que los datos se mueven a través del sistema:

1. Libertad para emprender la implementación técnica del sistema en las

primeras etapas.

2. Comprensión más profunda de la interrelación entre sistemas y

subsistemas.

3. Comunicación con los usuarios sobre el conocimiento del sistema actual

mediante diagramas de flujos de datos.

4. Análisis de un sistema propuesto para determinar si se han definido los

datos y procesos necesarios.



La ventaja más grande es la libertad conceptual para utilizar los cuatro símbolos,

los DFD’s hacen énfasis en el procesamiento o la transformación conforme estos

pasan por una variedad de procesos. En los DFD’s lógicos no hay distinción entre

procesos manuales o automatizados. Los procesos tampoco se representan

gráficamente en orden cronológico. En vez de ello, se agrupan solo si el análisis

detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y

los procesos automatizados también se pueden agrupar.

3.1.1.1 Simbología

En los diagramas de flujos de datos se usan cuatro símbolos básicos para graficar

el movimiento de los datos: Un cuadrado doble, una flecha, un rectángulo con

esquinas redondeadas(o una burbuja) y un rectángulo abierto (cerrado en el lado

izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 a

continuación. Con la combinación de estos cuatro símbolos se puede describir

gráficamente un sistema completo y varios subsistemas.


Entidad

Flujo de datos

Proceso

Almacén de datos

Figura 3.1 SimbologíaKendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed


El cuadrado doble se usa para describir una entidad externa (otro

departamento, un negocio, una persona o una maquina) que puede enviar datos al

sistema o recibirlos de el. La entidad externa, o solo entidad, también se llama

origen o destino de datos, y se considera externa al sistema descrito. A cada

entidad se le asigna un nombre adecuado. Aunque interactúa con el sistema, se

considera fuera de los límites de este. La misma entidad se podría usar más de

una vez en un diagrama de flujo de datos en particular para evitar que las líneas

se crucen en el flujo de datos.

La flecha muestra el movimiento de los datos de un punto a otro, con la punta

de la flecha señalando hacia el destino de los datos. Los flujos de datos que

ocurren simultáneamente se pueden describir mediante flechas paralelas. Una

flecha también puede se debe describir con un nombre, debido a que representan

los datos de un apersona, lugar o cosa.

Rectángulo con esquinas redondeadas se usa para mostrar la presencia de un

proceso de transformación. Los procesos siempre denotan un cambio en los

datos o una transformación de estos; por lo tanto el flujo de datos que sale de un

proceso siempre se designa de forma diferente al que entra en el. Los procesos

representan trabajo que se realiza en el tema y se deben nombrar usando uno de

los formatos siguientes:

• Se le debe asignar un nombre claro ya que este permite reconocer

fácilmente lo que hace un proceso.

1. A los procesos de alto nivel asigna el nombre del sistema. Por

ejemplo: SISTEMA DE CONTROL DE VENTAS.

2. Para nombrar un subsistema principal, se usa un nombre como

SUBSISTEMA DE INFORMACION DE VENTAS O SISTEMAS DE

CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET.

3. Para los procesos detallados se usa un formato de sustantivo-verbo-

adjetivo. El sustantivo indica cual es el resultado principal del

proceso, tal como INFORME O REGISTRO. El verbo describe el tipo



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.


0

Nombre del

Sistema

Entrada A

Entrada B

Salida CEntidad 1

Entidad 2

Entidad 3

1

Proceso general

AAA

2

Proceso general

BBB

3

Proceso general

CCC

4

Proceso general

DDD

Entrada A

D2 Almacén de Datos 2


Entrada B

Salida CFlujo de datos B

Registro E

Registro E

Registro A

Registro A

Entidad 1

Entidad 2

Entidad 3

Flujo de datos D

Figura 3.2 Representación del diagrama de contexto y del diagrama ceroKendall 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 NOMBRE DEL

EMPLEADO y la DIRECCION se podrían localizar en un archivo EM-

PLEADO, las HORAS TRABAJADAS podrían encontrarse en un

REGISTRO DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se

tendrían que calcular. Cada archivo y registro estaría conectado al proceso

que produce el recibo de nómina.

3. Examinamos el flujo de datos desde o hacia un almacén de datos. Se

pregunta: "¿Qué procesos ponen los datos en el almacén?" o "¿Qué

procesos usan los datos?" Observamos que un almacén de datos utilizado

en el sistema en el que se esta trabajando podría ser producido por un



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 sustantivo-verbo-adjetivo. Cada flujo

de datos se debe describir con un sustantivo.

4. Incluir más de nueve procesos en un diagrama de flujo de datos. La

inclusión de demasiados procesos origina un diagrama confuso difícil de


3

Proceso general

CCC

Entrada B

Registro A

Entidad 2

El flujo de datos coincidente

Registro de

transacción


D5 Archivo de Transacción 1

Flujo de datos D

Registro A

Flujo de datos Z detallado

Registro de

transacción 1

Flujo de datos D


4

Proceso general

DDD

3

Proceso YYY

detallado

3

Proceso general

CCC

3.1

Proceso XXX

detallado

Entrada B

Error

En un diagrama hijo detallado se podrían agregar líneas de error

En los diagramas de nivel inferior se podrían agregar archivos de transacciones

El flujo de salida debe coincidir con el proceso padre

El flujo de datos del proceso padre debe coincidir con el diagrama hijo

Figura 3.3 Representación del diagrama de contexto y del diagrama ceroKendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed


entender y obstaculiza la comunicació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


Tabla 3.1 Características modelos lógicos y físicosKendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed

Características del diseño

Lógico Físico

Que describe el modelo Como se implementará el sistema (o como funciona el sistema actual)

Como funciona el negocio

Que representan los procesos

Las actividades del negocio Programas, módulos del programa y procedimientos manuales

Que representan los almacenes de datos

Colecciones de datos independientemente de como se almacenan.

Archivos y bases de datos físicos, archivos manuales

Tipos de almacenes de datos

Muestra almacenes de datos que representan colecciones de datos permanentes

Archivos maestros, archivos de transición. Cualesquier proceso que operen en dos momentos diferentes deben conectarse mediante un almacén de datos



Muestra controles para validar los datos de entrada, para obtener un registro (el estado de un registro), para asegurar la realización exitosa de un proceso y para la seguridad del sistema

Diagrama de flujo de datos lógico actual

Nuevo diagrama de flujo de datos lógico

Nuevo diagrama de flujo de datos físico

Obtenga el diagrama de flujo de datos lógico para el sistema actual examinando el diagrama de flujo de datos físico y separando las actividades únicas del negocio

Cree el diagrama de flujo de datos lógico para el nuevo sistema agregando al diagrama de flujo de datos lógico del sistema actual las entradas, salidas y procesos requeridos en el nuevo sistema

Obtenga el diagrama de flujo de datos físico examinando los nuevos procesos en el nuevo diagrama lógico. Determine en donde deben existir la interfaz de usuario, la naturaleza de los procesos y los almacenes de datos necesarios

Tabla 3.2 Progresión del diagrama de flujo de datosKendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed


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 registros

cuando un archivo contiene tipos de registros diferentes.

4. Las entradas de grupos repetidos contienen un contador sobre qué tantos

conceptos hay en el grupo.

5. Límites sobre la cantidad de conceptos aceptables en un grupo repetido.

6. Una contraseña usada por un cliente que accede a un sitio web seguro.

Elementos de datos [3]

Cada elemento de datos se debe definir una vez en el diccionario de datos y

también se podría introducir previamente en un formulario de descripción del

elemento.

Características de un formulario de descripción de elementos:

1. ID del elemento. Esta entrada opcional permite construcciones entradas de

diccionario de datos

2. El nombre del elemento. El nombre debe ser descriptivo, único y basado en

el propósito al cual esta destinado el elemento en la mayoría de los

programas o por el usuario principal del elemento.

3. Alias, son sinónimos u otros nombres para el elemento.

4. Una descripción breve del elemento

5. Si el elemento es base o derivado. Elemento base es el que se teclea

inicialmente en el sistema, nombre del cliente dirección o ciudad; se deben

almacenar en archivos. Los elementos derivados son creados por procesos

como resultado de cálculo.

6. La longitud del elemento. Algunos elementos tienen longitudes estándar y

otras veces pueden variar para otros elementos, aquí se debe decidir en

conjunto con el usuario la longitud final.



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.


Costo total del software

Costo de Integración

Costo/ modulo

Región de costo mínimo

M

Número de módulos

Cos

to d

e E

sfue

rzo

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


• 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 (start-up)

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

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

Ninguno de los niveles anteriores está fuertemente vinculado a una estructura de

problema en particular. Cohesión de Comunicación es el menor nivel en el cual se

encuentra una relación entre los elementos de procesamiento que es

específicamente dependiente del problema.


a

b

c

d

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


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

LEER-REGISTRO-MAESTRO, o TRATAR-TRANS-TIPO3, presumiblemente serán

funcionalmente cohesivos, en cambio TRATAR-TODAS-TRANS presumiblemente

realizará más de una función y será lógicamente cohesivo.

Llegamos a la conclusión que no es necesario determinar el nivel preciso de

cohesión. Más bien, es importante intentar conseguir una cohesión alta y

reconocer cuando hay poca cohesión para modificar el diseño del software y

conseguir una mayor independencia funcional.

3.1.3.3 Acoplamiento [2]

El acoplamiento es una medida de interconexión entre módulos dentro de una

estructura de software. El acoplamiento depende de la complejidad de

interconexión entre los módulos, el punto donde se realiza una entrada o

referencia a un módulo, y los datos que pasan a través de la interfaz.

Los cuatro factores principales que influyen en el acoplamiento entre módulos son:

• Tipo de conexión entre módulos: Los sistemas normalmente conectados,

tienen menor acoplamiento que aquellos que tienen conexiones

patológicas.

• Complejidad de la interfaz: Esto es aproximadamente igual al número de

producto diferentes pasados (no cantidad de datos). Más producto, mayor

acoplamiento.

• Tipo de flujo de información en la conexión: los sistemas con acoplamiento

de datos tienen menor acoplamiento que los sistemas con acoplamiento de

control, y estos a su vez menos que los que tienen acoplamiento híbrido.

• Momento en que se produce el ligado de la Conexión: Conexiones ligadas a

referentes fijos en tiempo de ejecución, resultan con menor acoplamiento

que cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su ver



menor acoplamiento que cuando el ligado se realiza en tiempo de linkage-

edición, el cual tiene menos acoplamiento que el que se realiza realiza en

tiempo de compilación, todos los que a su vez tiene menos acoplamiento

que cuando el ligado se realiza en tiempo de codificación.

En el diseño del software, intentamos conseguir el acoplamiento más bajo posible.

Una conectividad sencilla entre los módulos da como resultado un software más

fácil de entender y menos propenso a tener un “efecto ola” causado cuando

ocurren errores en un lugar y se propagan por el sistema.

La figura 3.6 proporciona ejemplos de diferentes tipos de acoplamiento de

módulos. Los módulos a y d son subordinados a módulos diferentes. Ninguno está

relacionado y por tanto no ocurre un acoplamiento directo. El módulo c es

subordinado al módulo a y se accede a él mediante una lista de argumentos por la

que pasan los datos. Siempre que tengamos una lista convencional simple de

argumentos (es decir, el paso de datos; la existencia de correspondencia uno a

uno entre elementos), se presenta un acoplamiento bajo (llamado acoplamiento

de datos) en esta parte de la estructura. Una variación del acoplamiento de datos,


a

cb

d

f

e

g h

j

i

k

Estructura de datos

Estructura de datos

Datos (variables)

Indicador de control

Área de datos

globales

Figura 3.6 Tipos de acoplamientoPressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición


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 mini-especificaciones que reflejen la

información, función y características de comportamiento del

software

7. Revisar todas las mini-especificaciones para comprobar su

corrección , su consistencia la ausencia de ambigüedades

8. Ensamblar las mini-especificaciones de un documento de alcance

del proyecto

9. revisar ese documento general con todo lo que pueda afectar

10.modificar el documento de alcance del proyecto cuando se

requiera

3.2 El enfoque orientado a objetos

El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO)

constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan

en los conceptos de la programación orientada a objetos, que han sido codificados

en UML (Lenguaje Unificado de Modelación), un lenguaje estandarizado de

modelación en el cual los objetos generados no solo incluyen código referente a

los datos sino también instrucciones acerca de las operaciones que se realizaran

sobre los datos.

EL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo y

modelado de software que permite construir más fácilmente sistemas complejos a

partir de componentes individuales.

Objetos + Mensajes = Programa

El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que

comienza con la comunicación con el usuario. Es en esta parte donde se define el

dominio del problema y se identifican las clases básicas del problema. La



planificación y el análisis de riesgos establecen una base para el plan de proyecto

OO. El trabajo técnico asociado con la ingeniería del software OO sigue las

siguientes tareas:

1. Identificar clases candidatas

2. Buscar clases en biblioteca

3. Extraer nuevas clases si existen

4. Desarrollar las clases sino existen

5. Añadir las nuevas clases a la biblioteca

6. Construir n-esima iteración del sistema

La ingeniería de software hace hincapié en la reutilización. Por lo tanto las clases

se buscan en una biblioteca (de clases existentes) antes de construirse

Las Características del Enfoque Orientado a Objetos son:

a) Objeto: Los datos están cuantificados en entidades discretas y

distinguibles llamadas objetos.

b) Clase: Significa que los objetos con la misma estructura de datos

(atributos) y comportamiento (operaciones) se agrupa para formar

una clase.

c) Atributo: Describen la clase o el objeto de alguna manera

d) Mensajes: Medio por el cual interactúan los objetos

e) Polimorfismo: Significa que una misma operación puede

comportarse de modos distintos en distintas clases.

f) Herencia: Compartir atributos y operaciones entre clases tomando

como base una relación jerárquica.

Objeto

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

relacionados.



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:

• Coad-Yourdon

• Técnica de modelado de objetos de Rumbaugh (Object Modelling

Technique OMT)

• Shlaer-Mellor

• 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 [whole-part]”. El primer tipo de estructura es como un árbol genealógico:

es posible la herencia entre los miembros de una estructura. El segundo tipo de

estructura es utilizado para modelar relaciones de entidades (por ejemplo: cada

motor contiene una armadura).

Los modelos grandes y complejos pueden necesitar una organización ‘temática’,

con cada (asunto, atributo, en lugar de tema) tema dedicado a un aspecto

particular del problema. Por ejemplo, el modelo de objetos de un vehículo de

motor puede tener una perspectiva mecánica o una perspectiva eléctrica.

Los atributos caracterizan a cada clase. Por ejemplo, un atributo de una máquina

puede ser el “numero de cilindros”. Cada objeto tendrá un valor para ese atributo.

Los servicios definen lo que los objetos hacen. Definir los servicios es equivalente

a definir las funciones del sistema.



La importancia fundamental del método de Coad y Yourdon es su descripción

breve y concisa, así como el uso de textos generales como fuentes para las

definiciones; de modo que las definiciones se enmarcan dentro del sentido común

y reducen el empleo de modismos. La debilidad principal del método es su

notación compleja, la cual es difícil de utilizar sin el apoyo de una herramienta.

Algunos usuarios del método Coad-Yourdon han utilizado la dotación de

diagramación de OMT en su lugar.

Técnica de Modelado de Objetos

La Técnica de Modelado de Objetos (OMT, Object Modelling Technique)

transforma la definición del problema del usuario (como la que se documenta en

un Documento de Requerimientos del Usuario) en tres modelos:

• Modelo de objetos

• Modelo dinámico

• Modelo funcional

Los tres modelos en conjunto crean el modelo lógico requerido por los Estándares

de Ingeniería de Software.

El modelo de. El procedimiento para construirlo es el siguiente:

• Identificación de los objetos

• Identificación de las clases de objetos

• Identificación de las asociaciones (ejemplo: las relaciones) entre objetos

• Identificación de los atributos de los objetos

• Uso de herencia para organizar y simplificar la estructura de clases

• Organización de las clases y asociaciones estrechamente acopladas dentro

de módulos

• Acompañar a cada objeto con breves descripciones textuales



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 Schlaer-Mellor es su madurez (sus autores declaran haber

estado desarrollándolo desde 1979) y la existencia de técnicas para integrar los

modelos de información, los modelos de estado y los modelos de proceso. La

principal debilidad del método es su complejidad.

Booch

Booch modela un diseño orientado a objetos desde un punto de vista lógico, el

cual define las clases, los objetos y sus relaciones; y desde un punto de vista

físico, que define la arquitectura de módulos y procesos. La perspectiva lógica

corresponde al modelo lógico que deben construir los ingenieros de software de

acuerdo a los requerimientos de los estándares de Ingeniería de Software. El

método orientado a objetos de Booch tiene cuatro pasos:

1. Identificación de clases y objetos a un nivel dado de abstracción

2. Identificación de la semántica de estas clases y objetos

3. Identificación de las relaciones entre esas clases y objetos

4. Implementación de las clases y objetos



Las primeras tres etapas deben ser completadas dentro de la etapa de

Requerimientos del Sistema. La última etapa es realizada dentro de las fases de

AD y DD. Booch sostiene que el proceso de diseño orientado a objetos no es

deductivo [top-down] ni inductivo [bottom Up], sino algo que él denomina ‘round-

trip gestalt design’ [diseño gestalt (conocimiento) de viaje redondo]. El proceso

desarrolla un sistema a manera de incrementos e iteraciones. A los usuarios del

método de Booch se les advierte que deben integrar las fases SR y AD en una

sola ‘fase de modelado’.

Booch ofrece cuatro técnicas para la documentación de la perspectiva lógica:

• Diagramas de clase: consiste en un conjunto de clases y relaciones entre

ellas. Puede contener clases, clases paramétricas, utilidades y metaclases.

Los tipos de relaciones son asociaciones, contenencia, herencia, uso,

instanciación y metaclase.

• Diagramas de objetos: muestra objetos en el sistema y su relación lógica.

Pueden ser diagramas de escenario, donde se muestra cómo colaboran los

objetos en cierta operación; o diagramas de instancia, que muestra la

existencia de los objetos y las relaciones estructurales entre ellos

• Diagramas de estado-transición: muestran los estados posibles de cada

clase, así como los eventos que ocasionan las transiciones de un estado a

otro

• Diagramas de tiempo: aumenta un diagrama de objetos con información

acerca de eventos externos y tiempo de llegada de los mensajes

Los libros de Booch sobre métodos orientados a objetos han sido descritos por

Stroustrup, el inventor de C++, como los únicos y mejores libros sobre el tema.

Este cumplido revela los diversos alcances y la profundidad de un buen análisis y

práctica de diseño en sus escritos. Sin embargo, la notación de Booch es molesta

y hay pocas herramientas disponibles.



ROOM

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

top-down.

Los métodos de diseño orientado a objetos, a diferencia de otros, ofrecen un mejor

soporte para la reutilización. El mecanismo tradicional de reusó “bottom-up” donde

es perfectamente posible que un módulo de aplicación llame a un módulo de

librería. Además, la característica de herencia permite el reuso “top-down” de los

atributos y las operaciones de la superclase.

El DOO combina servicios e información, con esto incrementa la modularidad. Las

estructuras de control y datos pueden ser definidas de una manera integrada.

Otras características del enfoque orientado a objetos, además de las clases, los

objetos y la herencia son la transmisión de mensajes y el polimorfismo. Los

objetos envían mensajes a otros objetos para dirigir sus servicios. Los mensajes

también son utilizados para transmitir información. El polimorfismo es la

capacidad, al momento de la ejecución del programa, para referirse a las



instancias de varias clases. El polimorfismo es a menudo implementado para

permitir “enlaces dinámicos”.

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

• Coad-Yourdon;

• Técnica del Modelado de Objetos (OMT)

• Shlaer-Mellor.

En seguida se describe cada uno de ellos.

Booch

Booch creó el diseño orientado a objetos, y continúa jugando un papel principal en

el desarrollo del método.

Booch modela un diseño orientado a objetos en términos de un enfoque lógico, el

cual define las clases, los objetos y sus relaciones, y un enfoque físico, el cual

define la arquitectura de módulos y procesos. El enfoque lógico corresponde al

modelo lógico que requieren los estándares de la Ingeniería del Software para

construir en la fase de SR. El enfoque físico corresponde al modelo físico que

estos mismos estándares requieren para construir en la fase AD.

Booch proporciona dos técnicas de diagramación para documentar el enfoque

físico:

• Diagramas de módulo, son utilizados para mostrar la asignación de clases y

objetos hacia los módulos, como los programas, paquetes y tareas en el



diseño físico (el término “módulo” en el método de Booch es utilizado para

describir cualquier componente del diseño);

• Diagramas de procesos, muestran la asignación de módulos hacia los

procesadores de hardware.

Los libros de Booch en Diseño Orientado a Objetos contienen muchos análisis

sobre la práctica del buen diseño. Sin embargo, la notación de Booch puede llegar

a ser molesta y existen pocas herramientas disponibles.

HOOD

HOOD (Hierarchical Object-Oriented-Design) El diseño jerárquico orientado a

objetos (HOOD) es miembro de una familia de métodos orientados a objetos que

tratan de integrar la orientación a objetos con los métodos de diseño estructurado.

La jerarquía sigue naturalmente a la división del objeto raíz del nivel más alto. Al

igual que en el diseño estructurado, las parejas de datos fluyen entre

componentes del software. La principal diferencia entre HOOD y los métodos

estructurados es que los componentes del software obtienen su identidad de su

correspondencia con cosas en el mundo real, en vez de las funciones que el

sistema tiene que realizar.

HOOD fue originalmente diseñado para utilizarse con Ada, aunque Ada no soporta

la herencia, y no es un lenguaje de programación orientado a objetos. Este no es

un problema serio para el diseño HOOD, porque el método no utiliza clases para

estructurar los sistemas.

HOOD no tiene un método de análisis complementario. El modelo lógico

normalmente es construido utilizando el análisis estructurado. La transformación

del modelo lógico al modelo físico es difícil, haciendo difícil la construcción de un

diseño coherente.



HOOD ha sido incluido en aplicaciones Ada. Cuenta ya con un nicho, pero es poco

probable que llegue a tener una difusión y un apoyo tan amplio por parte de las

herramientas como, por ejemplo, OMT



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 (event-driven) o manejo

del tiempo (clock-driven), así como sus prioridades de manera crítica.

El componente de la administración de datos proporciona la infraestructura para

guardar y recuperar objetos. Puede ser un simple sistema de archivos, un sistema

de administración de bases de datos relacional, o igualmente un sistema de

administración de bases de datos orientado a objetos.

Los cuatro componentes juntos hacen el modelo físico del sistema. En el nivel más

alto, todos los diseños de Coad y Yourdon Orientado-a-Objetos tienen la misma

estructura.

Las clases y los objetos son organizados en la “generalización-especialización” y

en las estructuras completas (wholepart). Las estructuras de generalización

especialización son “familiar de árboles”, con hijos heredando los atributos de sus

padres. Estructuras de partes completas (whole-part) son formadas cuando un

objeto es descompuesto.

La fuerza de los métodos Coad y Yourdon son sus instrucciones, descripciones

breves y su uso de texto general como fuentes de definiciones, así que las

definiciones se ajustan al sentido común y el jargon es minimizado. El significado

de debilidad del método es su notación compleja, la cual es difícil de utilizarla sin

herramientas de soporte. Algunos usuarios han utilizado en lugar del método

Coad-Yourdon la notación de diagramación de OMT.

OMT

La Técnica de Modelación de Objetos (Object Modelling Technique OMT) en el

diseño tiene un alto nivel estratégico y decisión para resolver los problemas. Los

problemas grandes se deben ver desde el punto de análisis y diseño, este sistema

se divide en subsistemas, a su vez este subsistema puede ser dividido en otros



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 cliente-servidor existe cuando una clase (el cliente) llama en las

operaciones a otras clases (el servidor).

Una dependencia de amistad existe cuando una clase accede al dato interno de

otra clase. Esto es una violación de información ocultación.

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



BIBLIOGRAFÍA

[1] Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª Edicion.

[2] Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición

[3] Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª

edición

REFERENCIAS WEB

[4] Instituto Nacional de Estadística e Informática, Realidad Virtual “Tecnología Orientada a

Objetos” [En línea], Perú [Consulta: Septiembre de 2006],

<http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/IND.htm>

[5] Tejerina Martín, Monografías Lucas Morea, Sinexi SA, “Programación Orientada a

Objetos”, [Consulta: Marzo de 2006] <http://www.monografias.com/trabajos14/progorie/

progorie.shtml>

[6] Departamento de Auditoria Informática UNAM, “Metodologías de Ingeniería de Software”

[En línea], México [Consulta: Marzo de 2006] <http://sistemas.dgsca.unam.mx/publica/

pdf/metodologias.PDF>

[7] Ciberaula, “Tecnología Orientada a Objetos” [En línea], Madrid España [Consulta: Marzo

de 2006], <http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/>

[8] A.U.S. GustavoTorossi, “Apuntes de diseño estructurado: Cohesión” [En línea], Provincia

de Chaco Republica de Argentina [Consulta: Marzo de 2006] <http://www.chaco.gov.ar/

utn/disenodesistemas/apuntes/de/Unidad_5.html>

[9] Fernando Berzal, “Cohesión y Acoplamiento” [En línea], España [Consulta: Marzo de

2006], <http://elvex.ugr.es/decsai/java/pdf/4D-cohesion.pdf>

[10] A.U.S. GustavoTorossi, “Apuntes de diseño estructurado: Acoplamiento” [En línea],

Provincia de Chaco Republica de Argentina [Consulta: Marzo de 2006]

<http://www.chaco.gov.ar/utn/disenodesistemas/apuntes/de/Unidad_4.html>

[11] Creative Commons, “Metodologías usadas en ingeniería del software” [En linea],

Murcia España [Consulta: Marzo de 2006], <http://www.um.es/docencia/barzana/IAGP/

Iagp3.html>

[12] Javier Alberto Moya Espinoza, Copyright © Ilustrados, “Metodología OMT” [En línea],

[Consulta: Marzo de 2006] <http://www.ilustrados.com/publicaciones/EpZVVyAky

uqpxfFpAs.php

[13] Instituto Tecnológico de la Laguna, Analisis y Diseño Orientado a Objetos “Métodos y

Modelos” [En línea], México[Consulta: Marzo de 2006], <http://www.itlalaguna.edu.mx/

academico/carreras/sistemas/Analisis%20y%20dise%F1o%20orientado%20a

%20objetos/cap2.pdf#search=%22metodo%20hood%22


pruba de "sdf"

Software

Transcript of pruba de "sdf"