Ing Software

Fundamentos de desarrollo de sistemas
3 Paradigmas de la ingeniera de software

La Ingeniera de Software es reconocida como una disciplina legtima, digna de tener una investigacin 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, mtodos de ingeniera 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 ms disciplinado del software. Un paradigma de programacin es un modelo bsico de diseo y desarrollo de programas, que permite producir programas con una directriz especfica, tales como: estructura modular, fuerte cohesin, alta rentabilidad, etc. [11] Existen tres categoras de paradigmas de programacin: [11] a) Los que soportan tcnicas de programacin de bajo nivel (ejemplo: copia de ficheros frente estructuras de datos compartidos) b) Los que soportan mtodos de diseo de algoritmos (ejemplo: divide y vencers, programacin dinmica, etc.) c) Los que soportan soluciones de programacin de alto nivel, como los descritos en el punto anterior Los paradigmas relacionados con la programacin de alto nivel se agrupan en tres categoras de acuerdo con la solucin que aportan para resolver el problema: a) Solucin procedimental u operacional. Describe etapa a etapa el modo de construir la solucin. Es decir seala la forma de obtener la solucin. b) Solucin demostrativa. Es una variante de la procedimental. Especifica la solucin describiendo ejemplos y permitiendo que el sistema generalice la solucin 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 categora separada.
76 Paradigmas de la Ingeniera de Software
c) Solucin declarativa. Seala las caractersticas que debe tener la solucin, sin describir cmo procesarla. Es decir seala qu se desea obtener pero no cmo obtenerlo.
3.1 El enfoque estructurado

En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos) como principal herramienta para entender al sistema antes de plasmarlo a codigo fuente. DFD es un diagrama en el q participan procesos (metodos), flujo de datos (argumentos) y archivos (base de datos). Hay de diferentes niveles dependiendo la complejidad del sistema q analiza. hablando de lenguajes Tiene muchas diferencia con la OO. un minimo cambio en el codigo puede llegar alterar al resto del programa cosa que en uno OO bien encarado eso no sucede lo cual es una ventaja por que asi no se pierde tiempo en arreglar cosas ya hechas. Otra desventaja es que una porcion de codigo en lenguaje estructurado es dificil que pueda servir en otros proyectos, esto si es habitual en lenguajes OO, con solo importar clases ya hechas se escribe menos codigo y se ahorra tiempo.
3.1.1 Diagramas de flujos de datos [3]

El DFD (Data Flow Diagram) surgi de la necesidad de un nuevo mtodo de especificacin sencillo de implantar, fcil comprensin y comunicacin. El DFD fue desarrollado por De Marco en los aos 70s y fue popularizado por Yourdan. Es un mtodo de especificacin 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 representacin grfica de los procesos que se realizan con los datos en su organizacin, con el uso de tan solo cuatro smbolos, se puede crear una descripcin grafica de los procesos que, con el tiempo, contribuirn a desarrollar una slida documentacin del sistema.
En seguida mencionan las ventajas sobre las explicaciones descriptivas en relacin con la forma en que los datos se mueven a travs del sistema: 1. Libertad para emprender la implementacin tcnica del sistema en las primeras etapas. 2. Comprensin ms profunda de la interrelacin entre sistemas y subsistemas. 3. Comunicacin con los usuarios sobre el conocimiento del sistema actual mediante diagramas de flujos de datos. 4. Anlisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. La ventaja ms grande es la libertad conceptual para utilizar los cuatro smbolos, los DFDs hacen nfasis en el procesamiento o la transformacin conforme estos pasan por una variedad de procesos. En los DFDs lgicos no hay distincin entre procesos manuales o automatizados. Los procesos tampoco se representan grficamente en orden cronolgico. En vez de ello, se agrupan solo si el anlisis detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y los procesos automatizados tambin se pueden agrupar.
3.1.1.1 Simbologa
En los diagramas de flujos de datos se usan cuatro smbolos bsicos para graficar el movimiento de los datos: Un cuadrado doble, una flecha, un rectngulo con esquinas redondeadas(o una burbuja) y un rectngulo abierto (cerrado en el lado izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 a continuacin. Con la combinacin de estos cuatro smbolos se puede describir grficamente un sistema completo y varios subsistemas.
Entidad
Flujo de datos
Proceso
Almacn de datos Figura 3.1 Simbologa

Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo 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, tambin se llama origen o destino de datos, y se considera externa al sistema descrito. A cada entidad se le asigna un nombre adecuado. Aunque interacta con el sistema, se considera fuera de los lmites de este. La misma entidad se podra usar ms de una vez en un diagrama de flujo de datos en particular para evitar que las lneas 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 sealando hacia el destino de los datos. Los flujos de datos que ocurren simultneamente se pueden describir mediante flechas paralelas. Una flecha tambin puede se debe describir con un nombre, debido a que representan los datos de un apersona, lugar o cosa. Rectngulo con esquinas redondeadas se usa para mostrar la presencia de un proceso de transformacin. Los procesos siempre denotan un cambio en los
datos o una transformacin 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 fcilmente lo que hace un proceso. 1. 2. A los procesos de alto nivel asigna el nombre del sistema. Por Para nombrar un subsistema principal, se usa un nombre ejemplo: SISTEMA DE CONTROL DE VENTAS. 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 sustantivoverbo-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 especfico 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 nmero de identificacin nico y exclusivo, que indique su nivel en el diagrama. Podra 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 rectngulo abierto representa un almacn de datos. Estos smbolos se dibujan con el espacio suficiente para que quepan las letras de identificacin como
se muestra en la figura. En los diagramas de flujo de datos lgicos no se especifica el tipo de almacenamiento a un lugar. En este punto el smbolo del almacn de datos simplemente muestra un lugar de depsito para los datos que permite examinar, agregar y recuperar datos. El almacn de datos podra representar un almacn 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 almacn de datos, a cada uno asgnele un nmero 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 sistemtica. Primero se deben visualizar los flujos de datos desde una perspectiva jerrquica 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 organizacin en una lista con las cuatro categoras de entidad externa, flujo de datos, procesos, y almacn de datos. Esta lista a su vez ayudara a determinar los lmites del sistema que describir. Una vez que se haya recopilado una lista bsica de elementos de datos se empieza a dibujar el diagrama de contexto. Creacin de diagrama de contexto[3]
Con un enfoque jerrquico de arriba hacia abajo para diagramar el movimiento de los datos, los diagramas van de lo general a lo especfico. Aunque el primer diagrama ayuda a entender el movimiento bsico 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 bsicas, el sistema general y las salidas. Este diagrama ser el mas general, con una visin muy superficial del movimiento de los datos en el sistema y una visualizacin lo mas amplia posible del sistema. El diagrama de contexto es el nivel ms 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 ningn almacn de datos. Es bastante simple la creacin 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.
Entrada A Entidad 1
0
Salida C Entrada B
Nombre del Sistema
Entidad 3
Entidad 2
1
Entrada A Entidad 1
2
Flujo de datos B
Salida C
Proceso general AAA
Proceso general BBB
Entidad 3
Registro A Almacn de
Registro E Almacn de
D1
Datos 2
D2
Datos 2
Registro A
Registro E
3
Entrada B Entidad 2
4
Flujo de datos D
Proceso general CCC
Proceso general DDD
Figura 3.2 Representacin del diagrama de contexto y del diagrama cero

El diagrama cero es la ampliacin del diagrama de contexto y puede incluir hasta nueve procesos, esto se hace porque si se agregan ms procesos producir un diagrama difcil 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 grficamente 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
atrs. Si no esta seguro de lo que podra incluir en cualquier punto, tome una entidad externa, un proceso o un almacn 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 atrs a partir de un flujo de datos de salida. Examinamos los campos de salida de un documento o pantalla. (Este enfoque es ms sencillo si se han creado prototipos.) Se pregunta sobre cada campo de la salida: "De dnde 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 podran localizar en un archivo EMPLEADO, las HORAS TRABAJADAS podran encontrarse en un REGISTRO DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se tendran que calcular. Cada archivo y registro estara conectado al proceso que produce el recibo de nmina. 3. Examinamos el flujo de datos desde o hacia un almacn de datos. Se pregunta: "Qu procesos ponen los datos en el almacn?" o "Qu procesos usan los datos?" Observamos que un almacn de datos utilizado en el sistema en el que se esta trabajando podra ser producido por un sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya ningn flujo de datos hacia el almacn de datos. 4. Analizamos un proceso bien definido. Vea qu entrada de datos necesita el proceso y qu salida produce. Se hace un vnculo 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 problemticas podr realizar una lista de preguntas para las entrevistas de seguimiento con los usuarios clave. Creacin de diagramas hijos (niveles mas detallados) [3]
Cada proceso del Diagrama cero se puede, a su vez, ampliar para crear un diagrama hijo ms detallado. El proceso del Diagrama cero a partir del cual se realiza la ampliacin 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 tambin. 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 travs de muchos niveles de ampliacin. Si el diagrama cero presenta los procesos 1, 2 y 3 los diagramas hijos 1, 2 y 3 estarn 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 vaca del diagrama hijo. Si el proceso padre tiene un flujo de datos conectado a un almacn de datos, tambin el diagrama hijo podra incluir el almacn de datos. Adems, este diagrama de nivel inferior podra contener almacenes de datos que no se muestran en el proceso padre. Por ejemplo se podran incluir un archivo que contenga una tabla de informacin, como una tabla de impuestos, o un archivo que conecta dos procesos del diagrama hijo. En un diagrama hijo se podran incluir un flujo de datos de nivel inferior, como una lnea de error, aunque no se podra hacer lo mismo en el proceso padre. Los procesos se podran 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]
Revisin 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 direccin 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 direccin 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; slo se deben conectar con un proceso. Un archivo no interacta 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 conexin no se incluye en el diagrama de flujo de datos a menos que el sistema facilite la comunicacin. La elaboracin de un informe es un ejemplo de esta clase de comunicacin. Sin embargo, es necesario interponer un proceso entre las entidades para producir el informe.
Almacn de
D1
Datos 1 Registro A El flujo de datos coincidente
Entrada B Entidad 2
3
Proceso general CCC
Flujo de datos D
4
Proceso general DDD
Almacn de
El flujo de datos del proceso padre debe coincidir con el diagrama hijo
D1
Datos 1
Registro A Registro de transaccin 1
Entrada B
3.1
Proceso XXX detallado Error
Registro de transaccin
3
Proceso YYY detallado
D5
Archivo de Transaccin 1
En un diagrama hijo detallado se podran agregar lneas de error
En los diagramas de nivel inferior se podran agregar archivos de transacciones
Flujo de datos Z detallado
3
Proceso general CCC
Flujo de datos D
El flujo de salida debe coincidir con el proceso padre
Figura 3.3 Representacin del diagrama de contexto y del diagrama cero

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 ms de nueve procesos en un diagrama de flujo de datos. La inclusin de demasiados procesos origina un diagrama confuso difcil de entender y obstaculiza la comunicacin en lugar de facilitada. Si en un
sistema existen ms de nueve procesos, agrupe en un subsistema algunos de los procesos que trabajan en conjunto y pngalos 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 slo una entrada y una salida. El flujo de datos lineal no es muy comn, excepto en los diagramas de flujo de datos hijos muy detallados, su presencia normalmente indica que al diagrama le falta algn flujo de datos. 6. Crear una separacin (o ampliacin) desequilibrada en los diagramas hijos. Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida que el proceso padre, Una excepcin a esta regla son las salida menores, como las lneas 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 jerrquico 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 Almacn 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 asegrese de que sean significativos los nombres que haya asignado a cada proceso y flujo de datos. 6. Desarrolle un diagrama de flujo de datos fsico a partir del diagrama de flujo de datos lgico. 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 particin el diagrama de flujo de datos fsico separando o agrupando sus partes con el propsito de facilitar la programacin y la implementacin.
3.1.1.3 Diagramas de flujos de datos lgicos y fsicos [3]

Los diagramas de flujo de datos se catalogan como lgicos o fsicos. Un diagrama de flujo de datos lgico se enfoca en el negocio y en el funcionamiento de ste. No se ocupa de manera en que se construir el sistema. Ms 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 fsico muestra cmo 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 caractersticas de los modelos lgico y fsico. Observe que el modelo lgico refleja el negocio, mientras que el modelo fsico describe el sistema.
Caractersticas del diseo
Que describe el modelo
Lgico
Como funciona el negocio
Fsico
Como se implementar el sistema (o como funciona el sistema actual) Programas, mdulos del programa y procedimientos manuales Archivos y bases de datos fsicos, archivos manuales Archivos maestros, archivos de transicin. Cualesquier proceso que operen en dos momentos diferentes deben conectarse mediante un almacn de datos Muestra controles para validar los datos de entrada, para obtener un registro (el estado de un registro), para asegurar la realizacin exitosa de un proceso y para la seguridad del sistema
Que representan los procesos Que representan los almacenes de datos
Las actividades del negocio Colecciones de datos independientemente de como se almacenan.
Tipos de almacenes de datos
Muestra almacenes de datos que representan colecciones de datos permanentes
Que representan los almacenes de datos
Que representan los almacenes de datos
Tabla 3.1 Caractersticas modelos lgicos y fsicos

Diagrama de flujo de datos lgico actual
Obtenga el diagrama de flujo de datos lgico para el sistema actual examinando el diagrama de flujo de datos fsico y separando las actividades nicas del negocio
Nuevo diagrama de flujo de datos lgico Nuevo diagrama de flujo de datos fsico
Cree el diagrama de flujo de datos lgico para el nuevo sistema agregando al diagrama de flujo de datos lgico del sistema actual las entradas, salidas y procesos requeridos en el nuevo sistema
Obtenga el diagrama de flujo de datos fsico examinando los nuevos procesos en el nuevo diagrama lgico. Determine en donde deben existir la interfaz de usuario, la naturaleza de los procesos y los almacenes de datos necesarios Tabla 3.2 Progresin del diagrama de flujo de datos
Una ventaja de construir el diagrama de flujo de datos lgico del sistema actual es que puede usar para crear el diagrama de flujo de datos lgico del nuevo sistema. Los procesos innecesarios en el nuevo sistema se podran eliminar y agregar nuevas caractersticas, actividades, salidas, entradas y datos almacenados. Mediante este enfoque se garantiza que el nuevo sistema conservar las caractersticas esenciales del sistema anterior. Adems, el uso del modelo lgico del sistema actual como base para el sistema propuesto ofrece una transicin gradual para el diseo del nuevo sistema, Una vez desarrollado el modelo lgico para el nuevo sistema, se podra usar para crear un diagrama de flujo de datos fsico par tal sistema. Desarrollo de diagramas de flujo de datos lgicos [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 lgico, entre ellas: 1. Mejor comunicacin con los usuarios. 2. Sistemas ms estables.
3. Mejor entendimiento del negocio por parte de los analistas. 4. Flexibilidad y mantenimiento. 5. Eliminacin de redundancias y creacin ms sencilla del modelo fsico. Es ms fcil usar un modelo lgico al comunicarse con los usuarios del sistema porque se centra en las actividades del negocio. En consecuencia los usuarios estarn familiarizados con las actividades principales y con muchos de los requerimientos de informacin de cada actividad. Los diagramas de flujos de datos lgicos representan caractersticas de un sistema que deberan existir sin importar cuales sean los medios fsicos para llevarlas a cabo. Desarrollo de diagramas de flujos de datos fsicos [3] Despus de desarrollar el modelo lgico del nuevo sistema, se puede usar para crear un diagrama de flujo de datos fsico. El diagrama de flujo de datos fsico muestra como se crear el sistema, y generalmente contiene la mayora, si no es que todos, de los elementos siguientes: Procesos manuales Procesos para agregar, eliminar, cambiar y actualizar registros. Procesos de entrada y verificacin de datos Procesos de validacin para garantizar la precisin de la entrada de datos Distribucin 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 terminacin de tareas o condiciones de error
Los diagramas de flujo de datos fsicos tienen las siguientes ventajas. 1. Aclara qu procesos son manuales y cules son automatizados.
2. Describe los procesos con mayor detalle que los DFDs lgicos. 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 fsicos tambin tienen almacenes de datos intermedios, con frecuencia un archivo de transaccin o una tabla de base de datos temporal. A menudo, los almacenes de datos intermedios consisten en archivos de transaccin que se utilizan para almacenar datos entre procesos. Dado que es poco probable que la mayora de los procesos requieren acceso a un conjunto determinado de datos se ejecuten al mismo tiempo, los archivos de transaccin deben guardar los datos de un proceso para luego enviarlo al siguiente. Tambin se puede incluir informacin relacionada con el tiempo. Por ejemplo, un DFD fsico podra indicar que un programa de edicin se debe ejecutar antes que un programa de actualizacin. Las actualizaciones deben ejecutarse antes que la elaboracin de un informe resumido, o un pedido debe ingresarse en un sitio Web antes de verificar con la institucin financiera la cantidad cargada a una tarjeta de crdito. A causa de estas consideraciones, un diagrama de flujo de datos fsico podra tener una apariencia ms lineal que la de un modelo lgico.
Se debe de crear el diagrama de flujo de datos fsico para un sistema mediante el anlisis de su entrada y su salida. Al crear un diagrama de flujo de datos fsico, 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 enva como resultado de alguna actividad. Se determina qu campo o elementos de datos es necesario teclear. Estos campos se denominan elementos bsicos y se deben almacenar en un archivo. Los elementos que no se teclean sino que son resultados de un clculo o de una operacin lgica 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 cmputo. Analice cada procedo para determinar si debe ser un proceso manual o automatizado. Agrupe los procedimientos automatizados en una serie de programas de cmputo. Usualmente se traza una lnea punteada alrededor de un proceso o grupo de procesos que deben colocarse en un solo programa de cmputo. 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 fsicas de la compaa?. Si es as, se deben particionar en diferentes programas de cmputo. 2. Sintonizacin. 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 cmputo.
4. Eficiencia. En un programa se podra combinar varios procesos para realizar un procesamiento eficiente. 5. Consistencia de los datos. Los procesos se podran combinar en un solo programa para mantener la consistencia de los datos. 6. Seguridad. Los procesos se podran 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 creacin de un nombre significativo pero diferente al de otros componentes de datos existentes. Se ha propuesto el diccionario de datos como gramtica casi formal para describir el contenido de los objetos definidos durante el anlisis estructurado. Esta notacin 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 comprensin de las entradas, salidas, de los componentes de los almacenes y tambin los clculos intermedios. [2] Muchos sistemas de administracin de base de datos estn equipados con un diccionario de datos automatizado. Estos diccionarios pueden ser complejos o sencillos, algunos diccionarios de datos computarizados catalogan automticamente los elementos de datos cuando se hace la programacin; 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 cmo 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. Adems de proporcionar documentacin y eliminar la redundancia, el diccionario datos se podra 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 lgica para los procesos del diagrama de flujo de datos,
3.1.2.1 Depsito de datos [3] [2]

Aunque el diccionario de datos contiene informacin de los datos y
procedimientos, una coleccin ms grande de informacin de proyectos se llama depsito, El concepto depsito es uno de los muchos impactos de las herramientas CASE y podra contener lo siguiente: 1. Informacin sobre los datos mantenidos por el sistema, incluyendo flujos de datos, almacenes de datos, estructuras de registros y elementos. 2. Lgica de procedimientos. 3. Diseo de pantallas e informes. 4. Relaciones entre datos, por ejemplo cmo se vincula una estructura de datos con otra. 5. Requerimientos del proyecto y productos del sistema final.
6. Informacin sobre la administracin del proyecto, tal como itinerarios de entrega," problemas pendientes de solucin 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 observacin de los usuarios, y el anlisis de documentos y de otros sistemas existentes. La informacin capturada se puede resumir usando un formulario que contenga la siguiente informacin: 1. ID, un numero de identificacin opcional. A veces este se codifica usando un esquema para identificar el sistema y la aplicacin 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 descripcin general del flujo de datos. 4. La fuente del flujo de datos. Esta podra ser una entidad externa, un proceso o influjo de datos proveniente de un almacn de datos. 5. El destino del flujo de datos. Esta podra ser una entidad externa, un proceso o influjo de datos proveniente de un almacn 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, podran ser uno o varios elementos. 8. el volumen por unidad de tiempo. Los datos podran ser registros por da o cualquier otra unidad de tiempo. 9. Un rea para comentarios adicionales y anotaciones sobre el flujo de datos.
Descripcin de las estructuras de datos [3] Normalmente las estructuras de datos se describen usando una notacin algebraica. Este mtodo permite al analista producir la vista de los elementos que constituyen la estructura de datos junto con informacin referente a dichos elementos. La notacin algebraica usa los siguientes smbolos: 1. Un signo de igual (=) significa esta compuesto de. 2. Un signo de suma (+) significa y. 3. Las llaves { } indican elementos repetitivos, tambin llamados grupos de repeticin o tablas. En el grupo podra haber un elemento de repeticin o varios de ellos. El grupo de repeticin podra tener condiciones, tal como un nmero fijo de repeticiones o limites superiores e inferiores para el nmero de repeticiones. 4. Los corchetes [ ] representan una situacin de uno u otro. Se podra representar un elemento u otro, pero no ambos. Los elementos listados entre los corchetes son mutuamente excluyentes. 5. Los parntesis ( ) representan un elemento opcional. Los elementos opcionales se podran dejar en blanco en la entrada de las pantallas y podran contener espacios o ceros para campos numricos en las estructuras de archivos. Estructuras de datos Lgicas y Fsicas [3] Cuando son definidas las estructuras de datos por primera vez, slo son incluidos los elementos de datos que el usuario podr ver, tales como nombre, direccin y saldo. Esta etapa es el diseo lgico, mostrando cules datos necesita el negocio para su operacin diaria. Usando diseo lgico como base, el analista disea luego las estructuras de datos fsicas. Estas incluyen elementos adicionales para la implementacin del sistema. Ejemplos de elementos de diseo fsico: 1. Campos clave usados para localizar registros en una base de datos
2. 3. 4. 5. 6.
Cdigos para identificar el estado de registros maestros. Estos cdigos se pueden mantener en archivos que generen informacin de impuestos. Los cdigos de transaccin son utilizados para identificar tipos de registros cuando un archivo contiene tipos de registros diferentes. Las entradas de grupos repetidos contienen un contador sobre qu tantos conceptos hay en el grupo. Lmites sobre la cantidad de conceptos aceptables en un grupo repetido. Una contrasea 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 tambin se podra introducir previamente en un formulario de descripcin del elemento. Caractersticas de un formulario de descripcin de elementos: 1. 2. ID del elemento. Esta entrada opcional permite construcciones entradas de diccionario de datos El nombre del elemento. El nombre debe ser descriptivo, nico y basado en el propsito al cual esta destinado el elemento en la mayora de los programas o por el usuario principal del elemento. 3. 4. 5. Alias, son sinnimos u otros nombres para el elemento. Una descripcin breve del elemento Si el elemento es base o derivado. Elemento base es el que se teclea inicialmente en el sistema, nombre del cliente direccin o ciudad; se deben almacenar en archivos. Los elementos derivados son creados por procesos como resultado de clculo. 6. La longitud del elemento. Algunos elementos tienen longitudes estndar y otras veces pueden variar para otros elementos, aqu se debe decidir en conjunto con el usuario la longitud final.
7. 8. 9.
El tipo de datos: numrico, fecha, alfabtico o carcter que a veces se llama datos alfanumricos o de texto. Los formatos de entrada y salida se deben incluir, usando smbolos de codificacin especiales para indicar como se deben presentar los datos. Los criterios de validacin 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. Tambin los elementos derivados se podran 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 almacn de datos para cada registro estructural nico.
3.1.2.2 Creacin del diccionario de datos [3]

Las entradas del diccionario de datos se podran crear despus de completar el diagrama de flujo de datos, o se podran construir conforme se desarrolle el diagrama de flujo de datos. El uso de notacin algebraica y registros estructurales permite desarrollar el diccionario de datos y los diagramas de flujos de datos mediante un enfoque jerrquico de arriba a bajo. Despus 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, observacin y anlisis 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 estructurales y los elementos. Anlisis de las entradas y salidas [3] Un paso importante en la creacin del diccionario de datos es identificar y categorizar el flujo de datos de entrada y salida del sistema. Campos comnmente incluidos: 1. Nombre descriptivo para la entrada o la salida. Si el flujo de datos esta en un diagrama lgico, el nombre debe identificar el propsito de los datos. 2. El contacto del usuario responsable para la clarificacin de detalles adicionales, retroalimentacin del diseo y aprobacin final 3. Si los datos son de entrada o salida 4. El formato de flujo de datos. En la fase del diseo lgico, el formato podra 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 edicin. Desarrollo de almacenes de datos [3] Otra actividad es el desarrollo de los almacenes de datos. Esta informacin se describe en estructuras de datos. Sin embargo la informacin podra estar almacenada en diferentes lugares, y el almacn de datos podra ser diferente en mas detallado, incluyendo los registros
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 informacin 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 informacin. Uso del diccionario de datos [3] El diccionario de datos ideal es automatizado, interactivo, en lnea y evolutivo. Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la organizacin, 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 anlisis y diseo 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 histrica sino se mantiene actualizado.
3.1.3 Diseo de mdulos [2]

El concepto de modularidad se ha ido exponiendo desde hace casi cinco dcadas 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 mdulos, 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 monoltico (es decir, un programa grande formado por un nico modulo) no puede ser entendido fcilmente 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 consideracin el siguiente argumento basado en observaciones humanas sobre la resolucin de problemas. Pensemos que C(x) es una funcin que define la complejidad percibida de un problema x, y que E(x) es una funcin que define el esfuerzo (oportuno) que se requiere para resolver un problema x. para dos problemas p1 y p2, si C(p1) > C(p2) Implica que E(p1) > E(p2) (3.1b) (3.1a)
En general, este resultado es por intuicin obvio. Se tarda ms en resolver un problema difcil. Mediante la experimentacin humana en la resolucin de problemas se ha averiguado otra caracterstica interesante. Esta es, C(p1 + p2) > C(p1) + C(p2) (3.2)
La ecuacin 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 ecuacin (3.2) y la condicin implicada por la ecuacin (3.1) se establece que E(p1 + p2) > E(p1) + E(p2) (3.3)
Esto lleva a una conclusin: divide y vencers es ms fcil resolver un problema complejo cuando se rompe en piezas manejables. El resultado expresado en la ecuacin 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 ecuacin (3.3) que si subdividimos el software indefinidamente, el esfuerzo que se requiere para desarrollarlo sera mnimo. Desgraciadamente, intervienen otras fuerzas, que hacen que esta conclusin sea (tristemente) falsa. Como muestra la figura 3.4, el esfuerzo (costo) para desarrollar un mdulo software individual disminuye a medida que aumenta el nmero total de mdulos. Dado el mismo conjunto de requisitos: tener ms mdulos conduce a un tamao menor de mdulo. Sin embargo, a medida que aumenta el nmero de mdulos, tambin crece el esfuerzo (costo) asociado con la integracin de mdulos. Estas caractersticas conducen tambin a la curva total del costo o esfuerzo que se muestra en la figura. Existe un nmero M de mdulos que dara como resultado un costo mnimo de desarrollo, aunque no tenemos la sofisticacin necesaria para predecir M con seguridad.
Costo de Esfuerzo
Regin de costo mnimo
Costo total del software
Costo de Integracin
Costo/ modulo
Figura 3.4 Esfuerzo Costo en modularidad

Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 5 edicin
Nmero de mdulos
Las curvas de la Figura 3.4 proporcionan en efecto una gua til cuando se tiene en consideracin la modularidad. La modularidad deber aplicarse, pero teniendo cuidado de estar prximo a M. Se deber evitar modularizar de ms o de menos. Cuando se tiene en consideracin la modularidad surge otra pregunta importante. Cmo se define un modulo con un tamao adecuado? La respuesta se, encuentra en los mtodos utilizados para definir los mdulos dentro de un sistema. Meyer define cinco criterios que nos permitirn evaluar un mtodo de diseo en relacin con la habilidad de definir un sistema modular efectivo: Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un mecanismo sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el problema, consiguiendo de esta manera una solucin modular efectiva.
Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin modular que no inventa nada ya inventado.
Capacidad de comprensin modular. Si un mdulo se puede comprender como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de los efectos secundarios de los cambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin absurda y sus efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los errores.
Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso aunque su implementacin deba ser monoltica. 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 mnimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podr y deber disearse con modularidad como filosofa predominante. El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los beneficios de un sistema modular.
3.1.3.1 Diseo Modular Efectivo [2]

La modularidad se ha convertido en un enfoque aceptado en todas las disciplinas de ingeniera. Un diseo modular reduce la complejidad, facilita los cambios (un aspecto crtico de la capacidad de mantenimiento del software), y da como
resultado una implementacin ms fcil 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 abstraccin y ocultacin de informacin. En referencias obligadas sobre el diseo del software, Pamas y Wirth sugieren a las tcnicas de refinamiento que mejoran la independencia de mdulos. Trabajos posteriores de Stevens, Wyers y Constantine consolidaron el concepto. La independencia funcional se consigue desarrollando mdulos con una funcin determinante y una aversin a una interaccin excesiva con otros mdulos. Es necesario disear el software de manera que cada mdulo trate una subfuncin 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, mdulos independientes, es ms fcil de desarrollar porque la funcin se puede compartimentar y las interfaces se simplifican (tengamos en consideracin las ramificaciones cuando el desarrollo se hace en equipo). Los mdulos independientes son ms fciles de mantener (y probar) porque se limitan los efectos secundarios originados por modificaciones de diseo/cdigo; porque se reduce la propagacin de errores; y porque es posible utilizar mdulos usables. En resumen, la independencia funcional es la clave para un buen diseo y el diseo es la clave para la calidad del software. La independencia se mide mediante dos criterios cualitativos: la cohesin y el acoplamiento. La cohesin es una medida de la fuerza relativa funcional de un mdulo. El acoplamiento es una medida de la independencia relativa entre los mdulos.
3.1.3.2 Cohesin [2]

La cohesin es una extensin natural del concepto de ocultacin de informacin (la informacin que esta dentro de un modulo debe ser inaccesible a otros mdulos que no necesiten esa informacin). Un mdulo cohesivo lleva a cabo una sola tarea dentro de un procedimiento de software, lo cual requiere poca interaccin con los procedimientos que se llevan a cabo en otras partes de un programa. Dicho de manera sencilla, un mdulo cohesivo deber (idealmente) hacer una sola cosa. La cohesin se puede representar como un espectro. Siempre debemos buscar la cohesin ms alta, aunque la parte media del espectro suele ser aceptable. La escala de cohesin no es lineal. Es decir, la parte baja de la cohesin es mucho peor que el rango medio, que es casi tan bueno como la parte alta de la escala. En la prctica, un diseador no tiene que preocuparse de categorizar la cohesin en un mdulo especfico. Ms bien, se deber entender el concepto global, y as se debern evitar los niveles bajos de cohesin al disear los cdigos.
3.1.3.2.1 Niveles de cohesin

Cohesin Casual o Coincidental [8] [9] [2] La cohesin casual ocurre cuando existe poca o ninguna relacin entre los elementos de un mdulo. La cohesin casual establece un punto cero en la escala de cohesin. Es muy difcil encontrar mdulos puramente casuales. Puede aparecer como resultado de la modularizacin 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 confeccin de mdulos casualmente cohesivos, fue la mala prctica de la programacin estructurada, cuando los programadores mal entendan que modularizar consista en cambiar las sentencias GOTO por llamadas a subrutinas Finalmente diremos que si bien en la prctica es difcil encontrar mdulos casualmente cohesivos en su totalidad, es comn que tengan elementos casualmente cohesivos. Tal es el caso de operaciones de inicializacin y terminacin que son puestas juntas en un mdulo superior. Debemos notar que si bien la cohesin casual no es necesariamente perjudicial (de hecho es preferible un programa casualmente cohesivo a uno lineal), dificulta las modificaciones y mantenimiento del cdigo. Cohesin Lgica [8] [9] [2] Los elementos de un mdulo estn lgicamente asociados si puede pensarse en ellos como elementos que pertenecen a la misma clase lgica de funciones, es decir aquellas que pueden pensarse como lgicamente juntas. Por ejemplo, se puede combinar en un mdulo simple todos los elementos de procesamiento que caen en la clase de "entradas", que abarca todas las operaciones de entrada. Podemos tener un mdulo que lea desde consola una tarjeta con parmetros de control, registros con transacciones errneas de un archivo en cinta, registros con transacciones vlidas de otro archivo en cinta, y los registros maestros anteriores de un archivo en disco. Este mdulo que podra llamarse "Lecturas", y que agrupa todas las operaciones de entrada, es lgicamente cohesivo. La cohesin lgica es ms fuerte que la casual, debido a que representa un mnimo de asociacin entre el problema y los elementos del mdulo. Sin embargo podemos ver que un mdulo lgicamente cohesivo no realiza una funcin especfica, sino que abarca una serie de funciones.
Cohesin Temporal [8] [9] [2] Cohesin Temporal significa que todos los elementos de procesamiento de una coleccin ocurren en el mismo perodo de tiempo durante la ejecucin del sistema. Debido a que dicho procesamiento debe o puede realizarse en el mismo perodo de tiempo, los elementos asociados temporalmente pueden combinarse en un nico mdulo que los ejecute a la misma vez. Existe una relacin entre cohesin lgica y la temporal, sin embargo, la primera no implica una relacin de tiempo entre los elementos de procesamiento. La cohesin temporal es ms fuerte que la cohesin lgica, ya que implica un nivel de relacin ms: el factor tiempo. Si embargo la cohesin temporal an es pobre en nivel de cohesin y acarrea inconvenientes en el mantenimiento y modificacin del sistema. Un ejemplo comn de cohesin temporal son las rutinas de inicializacin (start-up) comnmente encontradas en la mayora de los programas, donde se leen parmetros de control, se abren archivos, se inicializan variables contadores y acumuladores, etc. Cohesin de Procedimiento [8] [9] [2] Elementos de procesamiento relacionados procedimentalmente son elementos de una unidad procedimental comn. Estos se combinan en un mdulo de cohesin procedimental que implica una secuencia de ejecucin de los pasos. Una unidad procedimental comn puede ser un proceso de iteracin (loop) y de decisin, o una secuencia lineal de pasos. En este ltimo caso la cohesin es baja y es similar a la cohesin temporal, con la diferencia que la cohesin temporal no implica una determinada secuencia de ejecucin de los pasos.
Al igual que en los casos anteriores, para decir que un mdulo tiene solo cohesin procedimental, los elementos de procesamiento deben ser elementos de alguna iteracin, decisin, o secuencia, pero no deben estar vinculados con ningn principio asociativo de orden superior. La cohesin procedimental asocia elementos de procesamiento sobre la base de sus relaciones algortmicas o procedimentales. Este nivel de cohesin comnmente se tiene como resultado de derivar una estructura modular a partir de modelos de procedimiento como ser diagramas de flujo, o diagramas Nassi-Shneiderman. Cohesin de Comunicacin [8] [9] [2] Ninguno de los niveles anteriores est fuertemente vinculado a una estructura de problema en particular. Cohesin de Comunicacin es el menor nivel en el cual se encuentra una relacin entre los elementos de procesamiento que es especficamente dependiente del problema.
Figura 3.5 Asociacin por comunicacin

Decir que un conjunto de elementos de procesamiento estn vinculados por comunicacin 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, estn asociados por comunicacin 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 mdulo estn asociados por comunicacin. Las relaciones por comunicacin presentan un grado de cohesin aceptable. La cohesin por comunicacin es comn en aplicaciones comerciales. Algunos ejemplos pueden ser: un mdulo que imprima o grabe un archivo de transacciones; un mdulo que reciba datos de diferentes fuentes, y los transforme y ensamble en una lnea de impresin.
Cohesin Secuencial [8] [9] [2] En este nivel de cohesin, los datos de salida (resultados) de un elemento de procesamiento sirven como datos de entrada al siguiente elemento de procesamiento. En trminos de un diagrama de flujo de datos de un problema, la cohesin secuencial combina una cadena linear de sucesivas transformaciones de datos. Este es claramente un principio asociativo relacionado con el dominio del problema. Cohesin Funcional [8] [9] [2] En el lmite superior del espectro de relacin funcional encontramos la cohesin funcional. simple. En trminos prcticos podemos decir que cohesin funcional es aquella que no es secuencial, por comunicacin, por procedimiento, temporal, lgica, o casual. Los ejemplos ms claros y comprensibles provienen del campo de las matemticas. Un mdulo para realizar el clculo de raz cuadrada ciertamente ser altamente cohesivo, y probablemente, completamente funcional. No es probable que haya elementos superfluos ms all de los absolutamente esenciales para realizar la funcin matemtica, y no es probable que elementos de procesamiento puedan ser agregados sin alterar el clculo de alguna forma. En contraste un mdulo que calcule raz cuadrada y coseno, es improbable que sea enteramente funcional (deben realizarse dos funciones ambiguas). En un mdulo completamente funcional, cada elemento de procesamiento, es parte integral de, y esencial para, la realizacin de una funcin
En adicin a estos ejemplos matemticos obvios, usualmente podemos reconocer mdulos funcionales que son elementales en naturaleza. Un mdulo llamado LEER-REGISTRO-MAESTRO, o TRATAR-TRANS-TIPO3, presumiblemente sern funcionalmente cohesivos, en cambio TRATAR-TODAS-TRANS presumiblemente realizar ms de una funcin y ser lgicamente cohesivo. Llegamos a la conclusin que no es necesario determinar el nivel preciso de cohesin. Ms bien, es importante intentar conseguir una cohesin alta y
reconocer cuando hay poca cohesin para modificar el diseo del software y
conseguir una mayor independencia funcional.
3.1.3.3 Acoplamiento [2]

El acoplamiento es una medida de interconexin entre mdulos dentro de una estructura de software. El acoplamiento depende de la complejidad de interconexin entre los mdulos, el punto donde se realiza una entrada o referencia a un mdulo, y los datos que pasan a travs de la interfaz. Los cuatro factores principales que influyen en el acoplamiento entre mdulos son: Tipo de conexin entre mdulos: Los sistemas normalmente conectados, tienen menor acoplamiento que aquellos que tienen conexiones patolgicas. Complejidad de la interfaz: Esto es aproximadamente igual al nmero de producto diferentes pasados (no cantidad de datos). Ms producto, mayor acoplamiento. Tipo de flujo de informacin en la conexin: 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 hbrido. Momento en que se produce el ligado de la Conexin: Conexiones ligadas a referentes fijos en tiempo de ejecucin, 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 linkageedicin, el cual tiene menos acoplamiento que el que se realiza realiza en tiempo de compilacin, todos los que a su vez tiene menos acoplamiento que cuando el ligado se realiza en tiempo de codificacin. En el diseo del software, intentamos conseguir el acoplamiento ms bajo posible. Una conectividad sencilla entre los mdulos da como resultado un software ms fcil de entender y menos propenso a tener un efecto ola causado cuando ocurren errores en un lugar y se propagan por el sistema.
Estructura de datos
Estructura de datos
a
Datos (variables)
Indicador de control
h rea de datos globales
Figura 3.6 Tipos de acoplamiento

La figura 3.6 proporciona ejemplos de diferentes tipos de acoplamiento de mdulos. Los mdulos a y d son subordinados a mdulos diferentes. Ninguno est relacionado y por tanto no ocurre un acoplamiento directo. El mdulo c es subordinado al mdulo 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 variacin del acoplamiento de datos,
llamado acoplamiento de marca (stamp), se da cuando una parte de la estructura de datos (en vez de argumentos simples) se pasa a travs de la interfaz. Esto ocurre entre los mdulos b y a. En niveles moderados el acoplamiento se caracteriza por el paso de control entre mdulos. El acoplamiento de control es muy comn en la mayora de los diseos de software y se muestra en la figura. 3.6 en donde un indicador de control (una variable que controla las decisiones en un mdulo superior o subordinado) se pasa entre los mdulos d y e. Cuando los mdulos estn atados a un entorno externo al software se dan niveles relativamente altos de acoplamiento. Por ejemplo, la E/S acopla un mdulo a dispositivos, formatos y protocolos de comunicacin. El acoplamiento externo es esencial, pero deber limitarse a unos pocos mdulos en una estructura. Tambin aparece un acoplamiento alto cuando varios mdulos hacen referencia a un rea global de datos. El acoplamiento comn, tal y como se denomina este caso, se muestra en la Figura 3.6. Los mdulos 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 mdulo c inicializa el elemento. Ms tarde el mdulo g vuelve a calcular el elemento y lo actualiza. Supongamos que se produce un error y que g actualiza el elemento incorrectamente. Mucho ms adelante en el procesamiento, el mdulo k lee el elemento, intenta procesado y falla, haciendo que se interrumpa el sistema. El diagnstico de problemas en estructuras con acoplamiento comn es costoso en tiempo y es difcil. Sin embargo, esto no significa necesariamente que el uso de datos globales sea malo. Significa que el diseador del software deber ser consciente de las consecuencias posibles, del acoplamiento comn y tener especial cuidado de prevenirse de ellos. El grado ms alto de acoplamiento, acoplamiento de contenido, se da cuando un mdulo hace uso de datos o de informacin de control mantenidos dentro de los lmites de otro mdulo. En segundo lugar, el acoplamiento de contenido ocurre
cuando se realizan bifurcaciones a mitad de mdulo. Este modo de acoplamiento puede y deber evitarse.
3.1.4 Descomposicin en procesos [2]

Las fases que generalmente caracterizan al proceso del software son: definicin desarrollo y soporte, se aplican a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniera del software que debe aplicar el equipo. El gestor del proyecto debe decidir que modelo de proceso es el ms adecuado para: 1. Los clientes que han solicitado el producto y la gente que realizara el trabajo; 2. Las caractersticas 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 descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades estructurales. Un equipo debera tener un grado significativo de flexibilidad en la eleccin del paradigma de ingeniera 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 pequeo 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 Comn de Procesos (ECP) se adapta a el. En todos los casos, la ECP (comunicacin con el cliente, planificacin, anlisis de riesgo, ingeniera, construccin, entrega y evaluacin del cliente) puede adaptarse al paradigma. Funcionara para modelos lineales, para modelos iterativos e incrementales, para modelos de evolucin 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 organizacin. Las tareas de trabajo reales si varan. La descomposicin del proceso comienza cuando el gestor del proyecto pregunta Cmo vamos a realizar esta actividad ECP? Un proyecto simple requiere las siguientes tareas para la actividad de comunicacin 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 exposicin 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 descomposicin del problema apropiado para proyectos pequeos relativamente sencillos. Si se considera un proyecto ms complejo que tenga un mbito ms amplio y un mayor impacto comercial. Un proyecto como se podra requerir las siguientes tareas para la actividad de comunicacin con el cliente: 1. 2. 3. 4. Revisar la peticin del cliente Planificar y programar una reunin formal con el cliente Realizar una investigacin para definir soluciones propuestas y Prepara un plan de trabajo y una agenda para la reunin formal
enfoques existentes.
5. 6. 7. 8. 9. 10.
Realizar la reunin Desarrollar conjuntamente mini-especificaciones que reflejen la Revisar todas las mini-especificaciones para comprobar su
informacin, funcin y caractersticas de comportamiento del software correccin , su consistencia la ausencia de ambigedades Ensamblar las mini-especificaciones de un documento de alcance revisar ese documento general con todo lo que pueda afectar modificar el documento de alcance del proyecto cuando se del proyecto
requiera
3.2 El enfoque orientado a objetos

El anlisis orientado a objetos (AOO) y el diseo orientado a objetos (DOO) constituyen un enfoque distinto de desarrollo de sistemas. Estas tcnicas se basan en los conceptos de la programacin orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelacin), un lenguaje estandarizado de modelacin en el cual los objetos generados no solo incluyen cdigo referente a los datos sino tambin instrucciones acerca de las operaciones que se realizaran sobre los datos. EL Paradigma Orientado a Objetos es una disciplina de ingeniera de desarrollo y modelado de software que permite construir ms fcilmente sistemas complejos a partir de componentes individuales. Objetos + Mensajes = Programa El proceso Orientado a Objetos se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es en esta parte donde se define el dominio del problema y se identifican las clases bsicas del problema. La planificacin y el anlisis de riesgos establecen una base para el plan de proyecto
OO. El trabajo tcnico asociado con la ingeniera del software OO sigue las siguientes tareas: 1. 2. 3. 4. 5. 6. Identificar clases candidatas Buscar clases en biblioteca Extraer nuevas clases si existen Desarrollar las clases sino existen Aadir las nuevas clases a la biblioteca Construir n-esima iteracin del sistema
La ingeniera de software hace hincapi en la reutilizacin. Por lo tanto las clases se buscan en una biblioteca (de clases existentes) antes de construirse Las Caractersticas del Enfoque Orientado a Objetos son: a) b) clase. c) d) e) f) Atributo: Describen la clase o el objeto de alguna manera Mensajes: Medio por el cual interactan los objetos Polimorfismo: Significa que una misma operacin puede Objeto: Los datos estn cuantificados en entidades discretas y Clase: Significa que los objetos con la misma estructura de datos distinguibles llamadas objetos. (atributos) y comportamiento (operaciones) se agrupa para formar una
comportarse de modos distintos en distintas clases. Herencia: Compartir atributos y operaciones entre clases tomando como base una relacin jerrquica. Objeto Un objeto es una unidad de cdigo compuesto de variables y mtodos relacionados.
Un objeto encapsula datos, operaciones, otros objetos, constantes y otra informacin relacionada. Pueden ser: Entidades externas, ocurrencias o eventos, papeles o roles, unidades organizacionales, lugares, estructuras. Los Objetos tienen caractersticas y comportamientos. Mantiene sus
caractersticas en una o ms "variables", e implementa su comportamiento con "mtodos". Un mtodo es una funcin o subrutina asociada a un objeto. Cuando a las caractersticas 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 caractersticas:

Informacin retenida Servicio necesario Atributos mltiples Atributos comunes Operaciones comunes Requisitos esenciales
Clase La clase es un modelo o prototipo que define las variables y mtodos comunes a todos los objetos de cierta clase. Una clase es una descripcin generalizada que describe una coleccin de objetos con caractersticas similares. Todos los objetos que existen dentro de una heredan sus atributos y las operaciones disponibles para la manipulacin de los atributos. Una superclase es una coleccin 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. Slo que el objeto es un trmino ms general, pero los objetos y las instancias son ambas representacin de una clase. Atributo Los Atributos estn 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 mayora de los casos, un dominio es simplemente un conjunto de valores especficos. En situaciones ms complejas el dominio puede ser un conjunto de clases. Mensajes Los mensajes son el medio a travs del cual los objetos intercambian informacin. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operacin. Un objeto es intil si est aislado. El medio empleado para que un objeto interacte con otro son los mensajes. Hablando en trminos un poco ms tcnicos, los mensajes son invocaciones a los mtodos de los objetos. Encapsulamiento El encapsulamiento significa que toda la informacin de un objeto se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificacin o componente de un programa. El encapsulamiento consiste en unir en la clase las caractersticas y comportamientos, esto es, las variables y mtodos. 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 abstraccin 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 slo 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 cmo lo hace. EL Ocultamiento es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer slo 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 dnde se validarn que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y mtodos. Herencia La herencia consiste en que una clase puede heredar sus variables y mtodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y mtodos propios, tiene incorporados los atributos y mtodos heredados de la superclase. De esta manera se crea una jerarqua de herencia. La herencia reduce el trabajo de la programacin usando fcilmente objetos comunes. Solo es necesario declarar que la clase A hereda de la clase B y despus proporcionar cualquier detalle
adicional. Los atributos y comportamientos de la clase B son parte de la clase A y no requiere ninguna programacin adicional. [7] Polimorfismo El polimorfismo permite que un nmero de operaciones diferentes tengan el mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno ms independiente.
3.2.1 Anlisis
El AOO ha sido muy exitoso en derribar problemas que se resisten al anlisis estructurado, como las interfaces de usuario. El AOO proporciona una transicin sin igual hacia el DOO y la programacin en lenguajes como Smalltalk, Ada y C++, y es el mtodo de anlisis preferido cuando los mtodos orientados a objetos van a ser utilizados posteriormente en la vida del sistema. Adems, los partidarios del AOO argumentan que los objetos dentro de un sistema son ms fundamentales (importantes, necesarios) para su naturaleza que las funciones que proporciona. Las especificaciones basadas en los objetos sern ms adaptables que las especificaciones basadas en las funciones. Los mtodos que marcan las directrices del AOO son: Coad-Yourdon Tcnica de modelado de objetos de Rumbaugh (Object Modelling Technique OMT) Shlaer-Mellor Booch ROOM Fusin
Coad y Yourdon
Coad y Yourdon describen un mtodo de Anlisis Orientado a Objetos basado en cinco actividades principales: Definicin de las clases y objetos Identificacin de estructuras Identificacin de temas Definicin de atributos Definicin 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 mtodo es identificar las clases y los objetos. La segunda tarea del mtodo es identificar las estructuras. Se reconocen dos tipos de estructuras: estructuras de generalizacin especializacin y estructuras globales [whole-part]. El primer tipo de estructura es como un rbol genealgico: 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 organizacin temtica, con cada (asunto, atributo, en lugar de tema) tema dedicado a un aspecto particular del problema. Por ejemplo, el modelo de objetos de un vehculo de motor puede tener una perspectiva mecnica o una perspectiva elctrica. Los atributos caracterizan a cada clase. Por ejemplo, un atributo de una mquina 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 mtodo de Coad y Yourdon es su descripcin 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 comn y reducen el empleo de modismos. La debilidad principal del mtodo es su notacin compleja, la cual es difcil de utilizar sin el apoyo de una herramienta. Algunos usuarios del mtodo Coad-Yourdon han utilizado la dotacin de diagramacin de OMT en su lugar. Tcnica de Modelado de Objetos La Tcnica de Modelado de Objetos (OMT, Object Modelling Technique) transforma la definicin del problema del usuario (como la que se documenta en un Documento de Requerimientos del Usuario) en tres modelos: Modelo de objetos Modelo dinmico Modelo funcional
Los tres modelos en conjunto crean el modelo lgico requerido por los Estndares de Ingeniera de Software. El modelo de. El procedimiento para construirlo es el siguiente: Identificacin de los objetos Identificacin de las clases de objetos Identificacin de las asociaciones (ejemplo: las relaciones) entre objetos Identificacin de los atributos de los objetos Uso de herencia para organizar y simplificar la estructura de clases Organizacin de las clases y asociaciones estrechamente acopladas dentro Acompaar a cada objeto con breves descripciones textuales
de mdulos
Los tipos ms importantes de asociacin son la adicin (es parte de) y la generalizacin (es un tipo de). El modelo dinmico 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 transicin 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 descomposicin 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 Identificar los objetos que son utilizados como almacenes de datos Identificar las operaciones de los objetos que comprenden cada proceso
valores de salida son computados a partir de los valores de entrada
El modelo funcional es sintetizado a partir de las operaciones de objetos, en vez de descomponerlo desde una funcin de alto nivel. Las operaciones de los objetos pueden ser definidos en cualquier etapa durante el modelado. Los aspectos ms importantes del OMT son sus capacidades simples aunque poderosas de notacin as como su madurez. Ha sido aplicado en varios proyectos por sus autores antes de ser publicado. La principal debilidad es la falta de tcnicas para integrar los modelos de objetos, los modelos dinmicos y los modelos funcionales.
Schlaer y Mellor Schlaer y Mellor comienzan el anlisis identificando el mbito del problema del sistema. Cada mbito es un mundo separado habitado por sus propias entidades conceptuales u objetos. Los mbitos ms grandes son divididos en subsistemas. Despus, cada mbito o subsistema es analizado de forma separada en tres etapas: Modelado de la informacin Modelado de estado Modelado de procesos
Las tres actividades de modelado crean en conjunto el modelo lgico requerido por los Estndares de Ingeniera de Software. El objetivo del modelado de informacin es identificar: Los objetos dentro del sistema Los atributos de cada objeto Las relaciones entre cada objeto
El modelo de informacin 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 comunicacin 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 accin Los atributos de cada objeto que son almacenados en cada accin
Los modelos de proceso son documentados mediante diagramas de accin de flujo de datos, mostrando las operaciones y el flujo de datos que ocurren en cada accin, y los diagramas de modelo de acceso de objeto, mostrando el acceso de datos entre objetos. Los procesos complejos tambin deben ser descritos. La fuerza del mtodo Schlaer-Mellor es su madurez (sus autores declaran haber estado desarrollndolo desde 1979) y la existencia de tcnicas para integrar los modelos de informacin, los modelos de estado y los modelos de proceso. La principal debilidad del mtodo es su complejidad. Booch Booch modela un diseo orientado a objetos desde un punto de vista lgico, el cual define las clases, los objetos y sus relaciones; y desde un punto de vista fsico, que define la arquitectura de mdulos y procesos. La perspectiva lgica corresponde al modelo lgico que deben construir los ingenieros de software de acuerdo a los requerimientos de los estndares de Ingeniera de Software. El mtodo orientado a objetos de Booch tiene cuatro pasos: 1. Identificacin de clases y objetos a un nivel dado de abstraccin 2. Identificacin de la semntica de estas clases y objetos 3. Identificacin de las relaciones entre esas clases y objetos 4. Implementacin 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 diseo orientado a objetos no es deductivo [top-down] ni inductivo [bottom Up], sino algo que l denomina roundtrip gestalt design [diseo gestalt (conocimiento) de viaje redondo]. El proceso desarrolla un sistema a manera de incrementos e iteraciones. A los usuarios del mtodo de Booch se les advierte que deben integrar las fases SR y AD en una sola fase de modelado. Booch ofrece cuatro tcnicas para la documentacin de la perspectiva lgica: Diagramas de clase: consiste en un conjunto de clases y relaciones entre ellas. Puede contener clases, clases paramtricas, utilidades y metaclases. Los tipos de relaciones son asociaciones, contenencia, herencia, uso, instanciacin y metaclase. Diagramas de objetos: muestra objetos en el sistema y su relacin lgica. Pueden ser diagramas de escenario, donde se muestra cmo colaboran los objetos en cierta operacin; o diagramas de instancia, que muestra la existencia de los objetos y las relaciones estructurales entre ellos Diagramas de estado-transicin: 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 informacin acerca de eventos externos y tiempo de llegada de los mensajes
Los libros de Booch sobre mtodos 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 anlisis y prctica de diseo en sus escritos. Sin embargo, la notacin de Booch es molesta y hay pocas herramientas disponibles.
ROOM ROOM es una metodologa de Modelado Orientada a Objetos en Tiempo Real desarrollado por la compaa Object Time Developer. Esta metodologa 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 tecnologa de computadoras (mtodos formales, el paradigma de objetos, interfaces grficas al usuario) Tambin, ROOM fue diseado explcitamente para tomar ventaja de la automatizacin basada en computadoras de las dems actividades mecnicas de desarrollo. Esto proporciona un potencial nico para beneficios significativos en productividad y calidad Estructura del modelado Utiliza sintaxis grfica para una fcil comprensin Abstracciones para tratar con fenmenos arquitectnicos de alto nivel de grandes sistemas de tiempo real. Protocolo basado en mltiples interfaces Objetos concurrentes (actores) Estructuras dinmicas Estructuras reproducidas
Modelado del comportamiento Alto nivel basado en sintaxis grfica Utiliza mquinas de estado jerrquicas; Permite elegir el modelado poderoso de capacidades, al tiempo que permite implementaciones automatizadas avanzadas y eficientes
Prioridad basada en la manipulacin de eventos para tratar con requerimientos de tiempo real Incorpora la industria de lenguajes de programacin estndar (por ejemplo: C++) para detalles especficos.
Experiencia Ms de cien diferentes proyectos industriales han utilizado ROOM Varios dominios de aplicacin:Incluyendo generacin de cdigo automtico completo Fusin El Mtodo Fusin est considerado como uno de los mtodos de desarrollo de Segunda Generacin. Proporciona elementos de desarrollo para y con reusabilidad y reingeniera. Los siguientes mtodos o tcnicas han influido en Fusin: OMT (Rumbaugh, 1991): El modelo Objeto es casi similar que en OMT. El modelo operacional es anlogo 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. Mtodos formales: pre y post condiciones son adoptados para describir formalmente qu es lo que hace un sistema. CRC: CRC extendido con informacin de comunicacin ha influenciado en grficas de interaccin de objetos. Diseo OO con Aplicaciones (Booch,1991):La visibilidad de las grficas son influenciadas por informacin de visibilidad en los diagramas Objeto de Booch. Fusin se basa en un pequeo pero comprensivo conjunto de tcnicas para creacin de diagramas bien definidas para la descripcin de las etapas de anlisis y diseo. Fusin consiste de 3 fases: anlisis, diseo e implementacin. Fusin
tambin proporciona reglas para verificar la consistencia e integridad del desarrollo de los modelos. En la fase de anlisis 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 realizacin de secuencias de esas operaciones. En la fase de diseo, 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 implementacin, la herencia, la referencia y los atributos de las clases son implementados en clases de un lenguaje de Programacin. Las interacciones entre objetos son programados como mtodos pertenecientes a la clase. Las mquinas estado (State Machines) son implementadas para reconocer secuencias permitidas de operaciones. En sus actividades se encuentran la codificacin, ejecucin y revisin. Fusin mantiene un diccionario de datos, un repositorio donde las diferentes entidades del sistema pueden ser nombradas y descritas.
3.2.2 Diseo [12][13]

El Diseo Orientado a Objetos (DOO) es un enfoque del diseo de software basado en objetos y clases. Un objeto es una abstraccin de algo en el dominio de un problema o su implementacin, reflejando las capacidades de un sistema para proporcionar informacin 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 Telemetra y Espectro, as como entidades ms simples con tipos de datos primitivos como nmeros reales, enteros y cadenas de caracteres. Una clase es definida por sus atributos y servicios. Por ejemplo, la clase Espectro tendra atributos como frecuencia mnima, frecuencia media, frecuencia mxima y servicios tales como calibrar. Las clases pueden ser divididas en subclases. Por ejemplo, pueden existir varios tipos de Paquetes de Telemetra, y pueden ser creadas subclases de Paquete de Telemetra tales como Paquete de Fotmetro y Paquete de Espectmetro. Las subclases comparten caractersticas 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 cdigo para ser implementados. El cdigo comn es automticamente localizado de una manera top-down. Los mtodos de diseo orientado a objetos, a diferencia de otros, ofrecen un mejor soporte para la reutilizacin. El mecanismo tradicional de reus bottom-up donde es perfectamente posible que un mdulo de aplicacin llame a un mdulo de librera. Adems, la caracterstica de herencia permite el reuso top-down de los atributos y las operaciones de la superclase. El DOO combina servicios e informacin, con esto incrementa la modularidad. Las estructuras de control y datos pueden ser definidas de una manera integrada. Otras caractersticas del enfoque orientado a objetos, adems de las clases, los objetos y la herencia son la transmisin de mensajes y el polimorfismo. Los objetos envan mensajes a otros objetos para dirigir sus servicios. Los mensajes tambin son utilizados para transmitir informacin. El polimorfismo es la capacidad, al momento de la ejecucin del programa, para referirse a las
instancias de varias clases. El polimorfismo es a menudo implementado para permitir enlaces dinmicos. Las caractersticas de la orientacin a objetos como polimorfismo recaen en la asignacin dinmica de memoria. Esto puede hacer imprevisible el desempeo 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 lmite definido tengan su procesamiento completamente definido al momento de la compilacin y no durante la ejecucin. El DOO es ms efectivo cuando se implementa mediante lenguajes de programacin orientado a objetos que soporten la definicin de objeto, herencia, intercambio de mensajes y polimorfismo. Smalltalk, C++, Eiffel y Object Pascal soportan todas estas caractersticas. Las tcnicas orientadas a objetos han demostrado ser mucho ms satisfactorias para la implementacin de software conducido por eventos, como las Interfaces Grficas de Usuario (GUIs), que los mtodos estructurados. Muchas herramientas CASE para los mtodos estructurados han sido mejoradas para las tcnicas orientadas a objetos. Si los mtodos 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 Anlisis Orientado a Objetos (OOA) ha sido utilizado en la fase de SR. La transicin del anlisis al diseo, y de este a la programacin es una de las mayores ventajas de los mtodos orientados a objetos, ya que facilita la interaccin. Uno de los primeros trabajos realizados por Booch, describe una tcnica para el diseo orientado a objetos. En la prctica los resultados no han sido satisfactorios. La perspectiva del anlisis estructurado est basado en las funciones y en los datos, y el enfoque de la orientacin a objetos
est basada es clases, objetos, atributos y servicios. Estos enfoques son muy diferentes y es difcil mantenerlos en mente simultneamente. Al igual que el diseo estructurado, el diseo orientado a objetos no es un mtodo nico, sino un nombre para designar una clase de mtodos. Los miembros (Members) de esta clase incluyen: Booch; Diseo Jerrquico Orientado a Objetos (HOOD); Coad-Yourdon; Tcnica del Modelado de Objetos (OMT) Shlaer-Mellor.
En seguida se describe cada uno de ellos. Booch Booch cre el diseo orientado a objetos, y contina jugando un papel principal en el desarrollo del mtodo. Booch modela un diseo orientado a objetos en trminos de un enfoque lgico, el cual define las clases, los objetos y sus relaciones, y un enfoque fsico, el cual define la arquitectura de mdulos y procesos. El enfoque lgico corresponde al modelo lgico que requieren los estndares de la Ingeniera del Software para construir en la fase de SR. El enfoque fsico corresponde al modelo fsico que estos mismos estndares requieren para construir en la fase AD. Booch proporciona dos tcnicas de diagramacin para documentar el enfoque fsico: Diagramas de mdulo, son utilizados para mostrar la asignacin de clases y objetos hacia los mdulos, como los programas, paquetes y tareas en el
diseo fsico (el trmino mdulo en el mtodo de Booch es utilizado para describir cualquier componente del diseo); Diagramas de procesos, muestran la asignacin de mdulos hacia los procesadores de hardware. Los libros de Booch en Diseo Orientado a Objetos contienen muchos anlisis sobre la prctica del buen diseo. Sin embargo, la notacin de Booch puede llegar a ser molesta y existen pocas herramientas disponibles. HOOD HOOD (Hierarchical Object-Oriented-Design) El diseo jerrquico orientado a objetos (HOOD) es miembro de una familia de mtodos orientados a objetos que tratan de integrar la orientacin a objetos con los mtodos de diseo estructurado. La jerarqua sigue naturalmente a la divisin del objeto raz del nivel ms alto. Al igual que en el diseo estructurado, las parejas de datos fluyen entre componentes del software. La principal diferencia entre HOOD y los mtodos 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 diseado para utilizarse con Ada, aunque Ada no soporta la herencia, y no es un lenguaje de programacin orientado a objetos. Este no es un problema serio para el diseo HOOD, porque el mtodo no utiliza clases para estructurar los sistemas. HOOD no tiene un mtodo de anlisis complementario. El modelo lgico normalmente es construido utilizando el anlisis estructurado. La transformacin del modelo lgico al modelo fsico es difcil, haciendo difcil la construccin de un diseo coherente.
HOOD ha sido incluido en aplicaciones Ada. Cuenta ya con un nicho, pero es poco probable que llegue a tener una difusin 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 anlisis y diseo orientado a objetos. Un diseo orientado a objetos es construido a partir de 4 componentes: Componente del mbito del problema; Componente de interaccin humana; Componente de administracin 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 (lgico) construido con el AOO en la fase de anlisis. 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 sern uno a uno, y el componente del mbito del problema podr ser programado directamente. Sin embargo, el refinamiento substancial del modelo lgico es normalmente requerido, resultando en la incorporacin de ms atributos y servicios. Las consideraciones de reuso, y la no disponibilidad de un lenguaje de programacin totalmente orientado a objetos, pueden hacer que el diseo del componente del mbito del problema parta de un ideal representado por el modelo de AOO. Los componentes poco amigables en la interaccin humana envan y reciben mensajes a y desde el usuario. Las clases y objetos en el componente de interaccin humana tiene nombres que son tomados desde el lenguaje de interfaz del usuario, por ejemplo: una ventana y un men. Muchos sistemas tendrn hilos mltiples de ejecucin, y el diseador debe construir un componente de manejo de tareas para organizar el procesamiento. El
diseador necesita definir tareas como manejo de eventos (event-driven) o manejo del tiempo (clock-driven), as como sus prioridades de manera crtica. El componente de la administracin de datos proporciona la infraestructura para guardar y recuperar objetos. Puede ser un simple sistema de archivos, un sistema de administracin de bases de datos relacional, o igualmente un sistema de administracin de bases de datos orientado a objetos. Los cuatro componentes juntos hacen el modelo fsico del sistema. En el nivel ms alto, todos los diseos de Coad y Yourdon Orientado-a-Objetos tienen la misma estructura. Las clases y los objetos son organizados en la generalizacin-especializacin y en las estructuras completas (wholepart). Las estructuras de generalizacin especializacin 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 mtodos 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 comn y el jargon es minimizado. El significado de debilidad del mtodo es su notacin compleja, la cual es difcil de utilizarla sin herramientas de soporte. Algunos usuarios han utilizado en lugar del mtodo Coad-Yourdon la notacin de diagramacin de OMT. OMT La Tcnica de Modelacin de Objetos (Object Modelling Technique OMT) en el diseo tiene un alto nivel estratgico y decisin para resolver los problemas. Los problemas grandes se deben ver desde el punto de anlisis y diseo, 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 polticas que deben guiarla adems un detalle del diseo. Se deben tener en cuenta los siguientes aspectos: Distinguir una arquitectura Elegir una implementacin para un control externo Si se usa base de datos elegir el paradigma de administracin de base de datos Determinar oportunidades para el reuso Elegir estrategia para interaccin de datos Elegir una forma de identificar los objetos Detallar el diseo
Durante el diseo del sistema se debe hacer un cuadro de estrategias y decisiones arquitecturales, tener una idea ms precisa de clases y mtodos individuales. Adicionalmente se puede mejorar el modelo de diseo para mejorar la implementacin. Se debe considerar los siguientes pasos: Uso de transformaciones para simplificar y optimizar el modelo de objetos desde el anlisis. Elaborar un modelo de objeto Elaborar un modelo funcional Evaluar la calidad del diseo del modelo Implementacin
El diseo es trasladado a un lenguaje de programacin actual y cdigo de base de datos. Este paso puede ser aplicado y considerado durante el anlisis y diseo
Shlaer y Mellor Shlaer y Mellor describen un Lenguaje de Diseo Orientado a Objetos (OODLE), derivado de la notacin de Booch y Buhr. Existen cuatro tipos de diagramas: Diagrama de Clases que muestran relaciones de utilizacin (cliente/servidor) y de amigos entre clases. Grfica 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 mtodos 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 grfica de la estructura de clase define la estructura del mdulo de la clase (class), el control y flujo de datos entre los mdulos de las clases. Existe una grfica 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 violacin de informacin ocultacin. Los diagramas de herencia muestran la herencia de relaciones entre clases.
BIBLIOGRAFA
[1] [2] [3]
Sommerville, Ian (2005), Ingeniera de software, Ed. Addison Wesley 7 Edicion. Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 5 edicin Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 edicin
REFERENCIAS WEB
[4]
Instituto Nacional de Estadstica e Informtica, Realidad Virtual Tecnologa Orientada a Objetos [En lnea], Per [Consulta: Septiembre de 2006], <http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/IND.htm>
[5]
Tejerina Martn, Monografas Lucas Morea, Sinexi SA, Programacin Orientada a Objetos, [Consulta: Marzo de 2006] <http://www.monografias.com/trabajos14/progorie/ progorie.shtml>
[6]
Departamento de Auditoria Informtica UNAM, Metodologas de Ingeniera de Software [En lnea], Mxico [Consulta: Marzo de 2006] <http://sistemas.dgsca.unam.mx/publica/ pdf/metodologias.PDF>
[7] [8]
Ciberaula, Tecnologa Orientada a Objetos [En lnea], Madrid Espaa [Consulta: Marzo de 2006], <http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/> A.U.S. GustavoTorossi, Apuntes de diseo estructurado: Cohesin [En lnea], 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, Cohesin y Acoplamiento [En lnea], Espaa [Consulta: Marzo de 2006], <http://elvex.ugr.es/decsai/java/pdf/4D-cohesion.pdf>
[10] A.U.S. GustavoTorossi, Apuntes de diseo estructurado: Acoplamiento [En lnea],

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, Metodologas usadas en ingeniera del software [En linea], Murcia
Espaa [Consulta: Marzo de 2006], <http://www.um.es/docencia/barzana/IAGP/ Iagp3.html>
[12] Javier Alberto Moya Espinoza, Copyright Ilustrados, Metodologa OMT [En lnea],
[Consulta: Marzo de 2006] <http://www.ilustrados.com/publicaciones/EpZVVyAky uqpxfFpAs.php
[13] Instituto Tecnolgico de la Laguna, Analisis y Diseo Orientado a Objetos Mtodos y

Modelos [En lnea], Mxico[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

Ing Software

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ing Software

Hochgeladen von

Copyright:

Verfügbare Formate

Fundamentos de desarrollo de sistemas

3 Paradigmas de la ingeniera de software

Fundamentos de desarrollo de sistemas

3.1 El enfoque estructurado

3.1.1 Diagramas de flujos de datos [3]

77 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

78 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

Almacn de datos Figura 3.1 Simbologa

79 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

80 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

3.1.1.2 Desarrollo de Diagramas de Flujos de Datos [3]

81 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

82 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

Nombre del Sistema

Proceso general AAA

Proceso general BBB

Proceso general CCC

Proceso general DDD

Figura 3.2 Representacin del diagrama de contexto y del diagrama cero

Fundamentos de desarrollo de sistemas

84 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

Fundamentos de desarrollo de sistemas

86 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

Datos 1 Registro A El flujo de datos coincidente

Registro A Registro de transaccin 1

En un diagrama hijo detallado se podran agregar lneas de error

En los diagramas de nivel inferior se podran agregar archivos de transacciones

Flujo de datos Z detallado

El flujo de salida debe coincidir con el proceso padre

Figura 3.3 Representacin del diagrama de contexto y del diagrama cero

87 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

Fundamentos de desarrollo de sistemas

3.1.1.3 Diagramas de flujos de datos lgicos y fsicos [3]

Que representan los procesos Que representan los almacenes de datos

Las actividades del negocio Colecciones de datos independientemente de como se almacenan.

Tipos de almacenes de datos

Muestra almacenes de datos que representan colecciones de datos permanentes

Que representan los almacenes de datos

Que representan los almacenes de datos

Tabla 3.1 Caractersticas modelos lgicos y fsicos

89 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

Diagrama de flujo de datos lgico actual

90 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

Fundamentos de desarrollo de sistemas

92 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

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

Fundamentos de desarrollo de sistemas

3.1.2 Diccionarios de datos [3]

94 Paradigmas de la Ingeniera de Software

Fundamentos de desarrollo de sistemas

3.1.2.1 Depsito de datos [3] [2]

95 Paradigmas de la Ingeniera de Software