SDF p3

Fundamentos de desarrollo de sistemas
3.1 El enfoque estructurado 3.1.1 Diagramas de flujos de datos [3]

El DFD (Data Flow Diagram) surgi de la necesidad de un nuevo mtodo de especificacin sencillo de implantar, fcil comprensin comunicacin! fue populari'ado por
El DFD fue desarrollado por De "arco en los a#os $%&s
(ourdan! Es un mtodo de especificacin utili'ado )asta la fec)a! *ara empe'ar se puede preguntar +,ue son los diagramas de flu-os 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 venta-as so/re las e0plicaciones descriptivas en relacin con la forma en 1ue los datos se mueven a travs del sistema2 3! Libertad para emprender la implementacin tcnica del sistema en las primeras etapas! 4! Comprensin ms profunda de la interrelacin entre sistemas su/sistemas! 3! Comunicacin con los usuarios so/re el conocimiento del sistema actual mediante diagramas de flu-os de datos! 5! Anlisis de un sistema propuesto para determinar si se )an definido los datos procesos necesarios!
6a venta-a ms grande es la li/ertad conceptual para utili'ar los cuatro s7m/olos, los DFD&s )acen nfasis en el procesamiento o la transformacin conforme estos pasan por una variedad de procesos! En los DFD&s lgicos no )a distincin entre
$8 *aradigmas de la 9ngenier7a de :oftware
procesos manuales o automati'ados! 6os procesos tampoco se representan grficamente en orden cronolgico! En ve' de ello, se agrupan solo si el anlisis detallado dicta 1ue tiene sentido )acerlo! 6os procesos manuales se agrupan, los procesos automati'ados tam/in se pueden agrupar!
3.1.1.1 Simbolog a
En los diagramas de flu-os de datos se usan cuatro s7m/olos /sicos para graficar el movimiento de los datos2 ;n cuadrado do/le, una flec)a, un rectngulo con es1uinas redondeadas(o una /ur/u-a) i'1uierdo un rectngulo a/ierto (cerrado en el lado a/ierto en el derec)o), como se muestra en la Figura 3!3 a varios su/sistemas!
continuacin! <on la com/inacin de estos cuatro s7m/olos se puede descri/ir grficamente un sistema completo
Entidad
Flu-o de datos
*roceso
=lmacn de datos "igura 3.1 :im/olog7a

>endall >ennet) E! ? >endall @ulie E!, =nlisis dise#o de sistemas, Ed! *rentice Aall 8B ed
El cuadrado doble se usa para descri/ir una entidad e!terna (otro departamento, un negocio, una persona o una ma1uina) 1ue puede enviar datos al sistema o reci/irlos de el! 6a entidad e0terna, o solo entidad, tam/in se llama
$$ *aradigmas de la 9ngenier7a de :oftware
origen o destino de datos,
se considera e0terna al sistema descrito! = cada
entidad se le asigna un nom/re adecuado! =un1ue interactCa con el sistema, se considera fuera de los l7mites de este! 6a misma entidad se podr7a usar ms de una ve' en un diagrama de flu-o de datos en particular para evitar 1ue las l7neas se crucen en el flu-o de datos! 6a flec#a muestra el mo$imiento de los datos de un punto a otro, con la punta de la flec)a se#alando )acia el destino de los datos! 6os flu-os de datos 1ue ocurren simultneamente se pueden descri/ir mediante flec)as paralelas! ;na flec)a tam/in puede se de/e descri/ir con un nom/re, de/ido a 1ue representan los datos de un apersona, lugar o cosa! %ectngulo con esquinas redondeadas se usa para mostrar la presencia de un proceso de transformacin! 6os procesos siempre denotan un cam/io en los datos o una transformacin de estosD por lo tanto el flu-o de datos 1ue sale de un proceso siempre se designa de forma diferente al 1ue entra en el! 6os procesos representan tra/a-o 1ue se reali'a en el tema los formatos siguientes2 :e le de/e asignar un nombre claro fcilmente lo 1ue )ace un proceso! 3! = los procesos de alto nivel asigna el nom/re del sistema! *or e-emplo2 :9:EE"= DE <FGEHF6 DE IEGE=:! 4! *ara nom/rar un su/sistema principal, se usa un nom/re como :;J:9:EE"= DE 9GFFH"=<9FG DE IEGE=: F :9:EE"=: DE <;"*69"9EGEF DE *ED9DF: DE6 <69EGEE EG 9GEEHGEE! 3! *ara los procesos detallados se usa un formato de sustantivoKver/oK ad-etivo! El sustanti$o indica cual es el resultado principal del proceso, tal como 9GFFH"E F HEL9:EHF! El ver/o descri/e el tipo de actividad, tal como <=6<;6=H, IEH9F9<=H, *HE*=H=H, 9"*H9"9H F =LHEL=H! El adjeti$o descri/e el resultado espec7fico 1ue se produce tal como G;EIF *ED9DF o 9GIEGE=H9F! a 1ue este permite reconocer se de/en nom/rar usando uno de
$M *aradigmas de la 9ngenier7a de :oftware
E-emplos de nom/res de procesos son <=6<;6=H 9"*;E:EF: DE IEGE=:, IEH9F9<=H E:E=DF: DE <;EGE= DE6 <69EGEE, *HE*=H=H F=<E;H= DE EGI9F, 9"*H9"9H 9GFFH"E DE G;EIF: *ED9DF:, EGI9=H <FGF9H"=<9FG =6 <69EGEE *FH <FHHEF E6E<EHFG9<F, IEH9F9<=H :=6DF DE E=H@EE= DE <HED9EF ( =LHEL=H HEL9:EHF DE 9GIEGE=H9F! = un proceso se le de/e de asignar un n&mero de identificacin &nico ' e!clusi$o, 1ue indi1ue su nivel en el diagrama! *odr7a )a/er varios flu-os de datos 1ue entren flu-o de entrada perdidos! El rectngulo abierto representa un almac(n de datos! Estos s7m/olos se di/u-an con el espacio suficiente para 1ue 1uepan las letras de identificacin como se muestra en la figura! En los diagramas de flu-o de datos lgicos no se especifica el tipo de almacenamiento a un lugar! En este punto el s7m/olo del almacn de datos simplemente muestra un lugar de depsito para los datos 1ue permite e0aminar, agregar recuperar datos! salgan de cada proceso! 6os procesos con solo un salida se de/en e0aminar en /usca de flu-os de datos
El almacn de datos podr7a representar un almacn manual, tal como un ga/inete de arc)ivo, un arc)ivo o una /ase de datos de computadora! = los almacenes de datos se les asigna un nom/re de/ido a 1ue representan a una persona, lugar o cosa! 6os almacenes de datos temporales, tales como papel /orrador o un arc)ivo temporal de computadora, no se inclu en en el diagrama de flu-o de datos! *ara identificar el nivel del almacn de datos, a cada uno as7gnele un nCmero de referencia Cnica, tal como D3, D4, D3 etc!
3.1.1.) Desarrollo de Diagramas de "lujos de Datos [3]
$N *aradigmas de la 9ngenier7a de :oftware
6os diagramas de flu-os de datos se pueden
de/en di/u-ar de manera
sistemtica! *rimero se de/en visuali'ar los flu-os de datos desde una perspectiva -err1uica de arri/a a /a-o! En seguida se descri/en los pasos a seguir! 6ista de actividades [3] *ara empe'ar un diagrama de flu-o de datos, se de/e sinteti'ar la narrativa(o )istoria) del sistema de la organi'acin en una lista con las cuatro categor7as de entidad e0terna, flu-o de datos, procesos, almacn de datos! Esta lista a su ve' a udara a determinar los l7mites del sistema 1ue descri/ir! ;na ve' 1ue se )a a recopilado una lista /sica de elementos de datos se empie'a a di/u-ar el diagrama de conte0to! <reacin de diagrama de conte0to [3] <on un enfo1ue -err1uico de arri/a )acia a/a-o para diagramar el movimiento de los datos, los diagramas van de lo general a lo espec7fico! =un1ue el primer diagrama a uda a entender el movimiento /sico de los datos, lo general de su naturale'a limita su utilidad! El diagrama de conte0to inicial de/e de mostrar un panorama glo/al 1ue inclu a las entradas /sicas, el sistema general movimiento de los datos en el sistema de datos las salidas! Este diagrama ser el mas general, con una visin mu superficial del una visuali'acin lo mas amplia posi/le del sistema! El diagrama de conte0to es el nivel ms alto en un diagrama de flu-o contiene un solo proceso, 1ue representa a todo el sistema! =l proceso )acia dic)as se le asigna el numero cero! En este diagrama se muestran todas las entidades e0ternas, as7 como los flu-os de datos principales 1ue van desde la creacin a 1ue se conocen las entidades e0ternas )acia ellas! Di/u-o del diagrama % (el siguiente nivel) [3] entidades! El diagrama no contiene ningCn almacn de datos! Es /astante simple el flu-o de datos desde
M% *aradigmas de la 9ngenier7a de :oftware
=l ampliar los programas se puede lograr un ma or detalle 1ue con los diagramas de conte0to! 6as entradas salidas especificadas en el primer diagrama permanecen constantes en todos los diagramas 1ue le siguen! :in em/argo, el resto del diagrama original se amplia para incluir de tres a nueve procesos mostrar almacenes de datos nuevos flu-os de datos de menor nivel! <ada diagrama ampliado de/e ocupar una sola )o-a de papel! =l ampliar los DFDs para representar su/procesos, en este paso se empie'an a completar los detalles del movimiento de los datos! El mane-o de e0cepciones se ignora en los primero dos o tres niveles del diagrama de flu-o de datos!
Entrada = Entidad 3
%
Gom/re del :istema
:alida < Entidad 3
Entrada J Entidad 4
3
Entrada = Entidad 3
4
Flu-o de datos J
*roceso general ===
*roceso general JJJ
:alida < Entidad 3
Hegistro = =lmacn de
Hegistro E =lmacn de
D3
Datos 4
D4
Datos 4
Hegistro =
Hegistro E
3
Entrada J Entidad 4
5
Flu-o de datos D
*roceso general <<<
*roceso general DDD
"igura 3.) Hepresentacin del diagrama de conte0to

>endall >ennet) E! ? >endall @ulie E!, =nlisis
del diagrama cero
dise#o de sistemas, Ed! *rentice Aall 8B ed
El diagrama cero es la ampliacin del diagrama de conte0to
puede incluir )asta
nueve procesos, esto se )ace por1ue si se agregan ms procesos producir un

M3 *aradigmas de la 9ngenier7a de :oftware
diagrama dif7cil de entender! *or lo general, cada proceso se numero con un entero, empe'ando en la es1uina superior i'1uierda del diagrama terminando en todas la es1uina inferior derec)a! En el diagrama cero se inclu en los principales almacenes de datos del sistema (1ue representan a los arc)ivos maestros) conte0to el diagrama cero! las entidades e0ternas! 6a figura 3!4 representa grficamente el diagrama de
De/ido a 1ue un diagrama de flu-o de datos es /idimensional (en lugar de lineal), se puede empe'ar en cual1uier punto del diagrama e ir )acia delante o )acia atrs! :i no esta seguro de lo 1ue podr7a incluir en cual1uier punto, tome una entidad e0terna, un proceso o un almacn de datos diferente el flu-o a partir de l2 3! Empe'amos con el flu-o de datos de una entidad en el lado de la entrada! :e )acen preguntas como2 +,u sucede con los datos 1ue entran en el sistema. +:e almacenan. +Esta entrada es para varios procesos. 4! Era/a-amos )acia atrs a partir de un flu-o de datos de salida! E0aminamos los campos de salida de un documento o pantalla! (Este enfo1ue es ms sencillo si se )an creado prototipos!) :e pregunta so/re cada campo de la salida2 O+De dnde viene.O o O+:e calcula o almacena en un arc)ivo.O *or e-emplo, cuando la salida es un HE<9JF DE GF"9G=, el GF"JHE DE6 E"*6E=DF *6E=DF, las la D9HE<<9FG se podr7an locali'ar en un arc)ivo E"K AFH=: EH=J=@=D=: podr7an encontrarse en un el :;E6DF JH;EF las DED;<<9FGE: se empiece a di/u-ar
HEL9:EHF DE6 E9E"*F
tendr7an 1ue calcular! <ada arc)ivo 1ue produce el reci/o de nmina!
registro estar7a conectado al proceso
3! E0aminamos el flu-o de datos desde o )acia un almacn de datos! :e pregunta2 O+,u procesos ponen los datos en el almacn.O o O+,u procesos usan los datos.O F/servamos 1ue un almacn de datos utili'ado en el sistema en el 1ue se esta tra/a-ando podr7a ser producido por un sistema diferente! *or lo tanto, desde su punto de vista, tal ve' no )a a ningCn flu-o de datos )acia el almacn de datos!
5! =nali'amos un proceso /ien definido! Iea 1u entrada de datos necesita el proceso 1u salida produce! :e )ace un v7nculo la entrada las entidades adecuadas! la salida con los almacenes de datos
P! Eome nota de cual1uier rea confusa en donde no est seguro de lo 1ue se de/e incluir o de la entrada o la salida 1ue se re1uiera! =l conocer las reas pro/lemticas podr reali'ar una lista de preguntas para las entrevistas de seguimiento con los usuarios clave! <reacin de diagramas )i-os (niveles mas detallados) [3] <ada proceso del Diagrama cero se puede, a su ve', ampliar para crear un diagrama )i-o ms detallado! El proceso del Diagrama cero a partir del cual se reali'a la ampliacin se llama proceso padre, el diagrama 1ue se produce se llama diagrama hijo. 6a regla principal para crear diagramas )i-os, es el e1uili/rio vertical, estipula 1ue un diagrama )i-o no puede producir salida o no puede reci/ir entrada 1ue el proceso padre no produ'ca o reci/a tam/in! Eodos los flu-os de datos )acia dentro o )acia fuera del proceso padre se de/en mostrar flu endo )acia dentro o )acia fuera del diagrama )i-o! =l diagrama )i-o se le asigna el mismo numero 1ue a su proceso padre en el Diagrama cero! 6os procesos del diagrama )i-o se numeran usando el numero del proceso padre, un punto decimal un solo numero para cado proceso )i-o! <on 3 los diagramas )i-os esto se puede locali'ar una serie de procesos a travs de muc)os niveles de ampliacin! :i el diagrama cero presenta los procesos 3, 4 3, 4 3 estarn en el mismo nivel!
*or lo regular las entidades no se muestran en los diagramas )i-os de/a-o del diagrama cero! El flu-o de datos 1ue coincide con el flu-o padre se llama flujo de datos de interfaz se representa con una flec)a 1ue parte de un rea vac7a del diagrama )i-o! :i el proceso padre tiene un flu-o de datos conectado a un almacn de datos, tam/in el diagrama )i-o podr7a incluir el almacn de datos! =dems, este diagrama de nivel inferior podr7a contener almacenes de datos 1ue no se
muestran en el proceso padre! *or e-emplo se podr7an incluir un arc)ivo 1ue contenga una ta/la de informacin, como una ta/la de impuestos, o un arc)ivo 1ue conecta dos procesos del diagrama )i-o! En un diagrama )i-o se podr7an incluir un flu-o de datos de nivel inferior, como una l7nea de error, aun1ue no se podr7a )acer lo mismo en el proceso padre! 6os procesos se podr7an ampliar o no ampliar, dependiendo de su nivel de comple-idad! <uando no se amplia un proceso, se dice 1ue es funcionalmente primitivo se llama proceso primitivo! En la figura 3!3 se ilustran niveles detallados de un diagrama de flu-os de datos )i-o! [3] Hevisin de Errores en lo diagramas [3] <uando se di/u-an diagramas de flu-os de datos se pueden cometer varios errores comunes como los siguientes2 3! Flvidar incluir un flu-o de datos o apuntar con una flec)a en la direccin incorrecta! ;n e-emplo es un proceso di/u-ado 1ue muestra todos sus flu-os de datos como entrada o salida! <ada proceso transforma datos reci/ir una entrada de/e producir una salida! Este tipo de error ocurre
generalmente cuando el analista olvida incluir un flu-o de datos o coloca una flec)a 1ue apunta en la direccin incorrecta! 4! <onectar directamente entre s7 almacenes de datos 6os almacenes de datos entidades e0ternas! las entidades e0ternas no se de/en conectar
entre s7D slo se de/en conectar con un proceso! ;n arc)ivo no interactCa con otro arc)ivo sin la a uda de un programa o una persona 1ue mueva los datos! 6as entidades e0ternas no tra/a-an directamente con los arc)ivos! Dos entidades e0ternas conectadas directamente indican 1ue desean comunicarse entre s7! Esta cone0in no se inclu e en el diagrama de flu-o de datos a menos 1ue el sistema facilite la comunicacin! 6a ela/oracin de un informe es un e-emplo de esta clase de comunicacin! :in em/argo, es necesario interponer un proceso entre las entidades para producir el informe!
D3
=lmacn de
Datos 3 Hegistro =
El flu-o de datos coincidente
Entidad 4
Entrada J
3
*roceso general <<<
Flu-o de datos D
5
*roceso general DDD
D3
=lmacn de
El flu-o de datos del proceso padre de/e coincidir con el diagrama )i-o
Datos 3
Hegistro =
Entrada J
3!3
*roceso RRR detallado Error
Hegistro de transaccin
Hegistro de transaccin 3
3
*roceso ((( detallado
Flu-o de datos Q detallado
DP
=rc)ivo de Eransaccin 3
En un diagrama )i-o detallado se podr7an agregar l7neas de error
En los diagramas de nivel inferior se podr7an agregar arc)ivos de transacciones
3
*roceso general <<<
Flu-o de datos D
El flu-o de salida de/e coincidir con el proceso padre
"igura 3.3 Hepresentacin del diagrama de conte0to

del diagrama cero
3! =signar nom/res incorrectos a los procesos o al flu-o de datos! Es necesario revisar el diagrama flu-o de datos para asegurar 1ue cada o/-eto o flu-o de datos tenga un nom/re adecuado! ;n proceso de/e indicar el nom/re del sistema o usar el formato sustantivoKver/oKad-etivo! <ada flu-o de datos se de/e descri/ir con un sustantivo! 5! 9ncluir ms de nueve procesos en un diagrama de flu-o de datos! 6a inclusin de demasiados procesos origina un diagrama confuso dif7cil de entender o/staculi'a la comunicacin en lugar de facilitada! :i en un
MP *aradigmas de la 9ngenier7a de :oftware
sistema e0isten ms de nueve procesos, agrupe en un su/sistema algunos de los procesos 1ue tra/a-an en con-unto pngalos en un diagrama )i-o, una P! Fmitir un flu-o de datos! E0amine su diagrama en /usca de flu-o lineal, es decir, flu-o de datos en el cual cada proceso tiene slo una entrada salida! El flu-o de datos lineal no es mu comCn, e0cepto en los diagramas de flu-o de datos )i-os mu detallados, su presencia normalmente indica 1ue al diagrama le falta algCn flu-o de datos! 8! <rear una separacin (o ampliacin) dese1uili/rada en los diagramas )i-os! <ada diagrama )i-o de/e tener el mismo flu-o de datos de entrada salida 1ue el proceso padre, ;na e0cepcin a esta regla son las salida menores, como las l7neas de error, 1ue se inclu en solamente en el diagrama )i-o! En seguida se sinteti'an los pasos para desarrollar efica'mente diagramas de flu-o de datos, usando un enfo1ue -err1uico de arri/a a /a-o2 3! Aaga una lista de las actividades del negocio siguiente2 Entidades e0ternas Flu-os de datos *rocesos =lmacn de datos los )acia el sistema! Go muestre e-emplos ni Csela para determinar lo
4! <rear un diagrama de conte0to 1ue muestre las entidades e0ternas flu-os de datos desde almacenes de datos detallados!
3! Di/u-ar el diagrama %(el siguiente nivel)! "uestre procesos, pero 1ue sean generales! En este nivel muestre almacenes de datos! 5! <ree un diagrama )i-o para cada uno de los procesos del Diagrama % P! Hevise 1ue no )a a errores asegCrese de 1ue sean significativos los flu-o de datos! los procesos manuales nom/res 1ue )a a asignado a cada proceso flu-o de datos lgico! Distinga entre
8! Desarrolle un diagrama de flu-o de datos f7sico a partir del diagrama de automati'ados, descri/a los arc)ivos reales los informes por nom/re
agregue controles para indicar cuando se completan los procesos o cuando ocurren errores! $! =)ora se )ace una particin el diagrama de flu-o de datos f7sico separando o agrupando sus partes con el propsito de facilitar la programacin implementacin! la
3.1.1.3 Diagramas de flujos de datos lgicos ' f sicos [3]

6os diagramas de flu-o de datos se catalogan como lgicos o f7sicos! ;n diagrama de flu-o de datos lgico se enfoca en el negocio eventos 1ue ocurren en el negocio en el funcionamiento de ste! Go producidos por cada las se ocupa de manera en 1ue se construir el sistema! "s /ien, descri/e los los datos re1ueridos evento! *or el contrario, un diagrama de flu-o de datos f7sico muestra cmo se implementar el sistema, inclu endo el )ardware, el software, los arc)ivos compara las caracter7sticas de los modelos lgico personas involucradas en el sistema! En la Ea/la 3!3 se muestra un cuadro 1ue f7sico! F/serve 1ue el modelo lgico refle-a el negocio, mientras 1ue el modelo f7sico descri/e el sistema!
Caracter sticas del dise+o
,ue descri/e el modelo
Lgico
<omo funciona el negocio
" sico
<omo se implementar el sistema (o como funciona el sistema actual) *rogramas, mdulos del programa procedimientos manuales =rc)ivos /ases de datos f7sicos, arc)ivos manuales =rc)ivos maestros, arc)ivos de transicin! <uales1uier proceso 1ue operen en dos momentos diferentes de/en conectarse mediante un almacn de datos "uestra controles para validar los datos de entrada, para o/tener un registro (el estado de un registro), para asegurar la reali'acin e0itosa de un proceso para la seguridad del sistema
,ue representan los procesos ,ue representan los almacenes de datos Eipos de almacenes de datos
6as actividades del negocio
<olecciones de datos independientemente de como se almacenan! "uestra almacenes de datos 1ue representan colecciones de datos permanentes
,ue representan los almacenes de datos
,ue representan los almacenes de datos
*abla 3.1 <aracter7sticas modelos lgicos

f7sicos
M$ *aradigmas de la 9ngenier7a de :oftware
Diagrama de flujo de datos lgico actual
F/tenga el diagrama de flu-o de datos lgico para el sistema actual e0aminando el diagrama de flu-o de datos f7sico separando las actividades Cnicas del negocio
,ue$o diagrama de flujo de datos lgico ,ue$o diagrama de flujo de datos f sico
<ree el diagrama de flu-o de datos lgico para el nuevo sistema agregando al diagrama de flu-o de datos lgico del sistema actual las entradas, salidas procesos re1ueridos en el nuevo sistema F/tenga el diagrama de flu-o de datos f7sico e0aminando los nuevos procesos en el nuevo diagrama lgico! Determine en donde de/en e0istir la interfa' de usuario, la naturale'a de los procesos los almacenes de datos necesarios *abla 3.) *rogresin del diagrama de flu-o de datos
;na venta-a de construir el diagrama de flu-o de datos lgico del sistema actual es 1ue puede usar para crear el diagrama de flu-o de datos lgico del nuevo sistema! 6os procesos innecesarios en el nuevo sistema se podr7an eliminar nuevas caracter7sticas, actividades, salidas, entradas agregar datos almacenados!
"ediante este enfo1ue se garanti'a 1ue el nuevo sistema conservar las caracter7sticas esenciales del sistema anterior! =dems, el uso del modelo lgico del sistema actual como /ase para el sistema propuesto ofrece una transicin gradual para el dise#o del nuevo sistema, ;na ve' desarrollado el modelo lgico para el nuevo sistema, se podr7a usar para crear un diagrama de flu-o de datos f7sico par tal sistema! Desarrollo de diagramas de flu-o de datos lgicos [3] *ara desarrollar un diagrama de este tipo, primero se constru e un diagrama de flu-o de datos para el sistema actual! Aa varias venta-as al usar un modelo lgico, entre ellas2 3! "e-or comunicacin con los usuarios! 4! :istemas ms esta/les!
MM *aradigmas de la 9ngenier7a de :oftware
3! "e-or entendimiento del negocio por parte de los analistas! 5! Fle0i/ilidad mantenimiento! creacin ms sencilla del modelo f7sico! P! Eliminacin de redundancias
Es ms fcil usar un modelo lgico al comunicarse con los usuarios del sistema por1ue se centra en las actividades del negocio! En consecuencia los usuarios estarn familiari'ados con las actividades principales re1uerimientos de informacin de cada actividad! 6os diagramas de flu-os de datos lgicos representan caracter7sticas de un sistema 1ue de/er7an e0istir sin importar cuales sean los medios f7sicos para llevarlas a ca/o! Desarrollo de diagramas de flu-os de datos f7sicos [3] Despus de desarrollar el modelo lgico del nuevo sistema, se puede usar para crear un diagrama de flu-o de datos f7sico! El diagrama de flu-o de datos f7sico muestra como se crear el sistema, *rocesos manuales *rocesos para agregar, eliminar, cam/iar *rocesos de entrada verificacin de datos actuali'ar registros! generalmente contiene la ma or7a, si no es 1ue todos, de los elementos siguientes2 con muc)os de los
*rocesos de validacin para garanti'ar la precisin de la entrada de datos Distri/ucin de los procesos para reorgani'ar el orden de los registros *rocesos para producir cada salida Cnica del sistema =lmacenes de datos intermedios Gom/res de arc)ivos reales para almacenar datos <ontroles para descri/ir la terminacin de tareas o condiciones de error
6os diagramas de flu-o de datos f7sicos tienen las siguientes venta-as!

MN *aradigmas de la 9ngenier7a de :oftware
3! =clara 1u procesos son manuales
cules son automati'ados!
4! Descri/e los procesos con ma or detalle 1ue los DFDs lgicos! 3! Distri/u e en un orden particular los procesos 1ue se de/en reali'ar! 5! 9dentifica los almacenes de datos temporales! P! Especifica los nom/res reales de arc)ivos 8! =grega controles para asegurar 1ue adecuadamente = menudo estos diagramas son tan comple-os de/ido a la gran cantidad de almacenes de datos 1ue inclu e un sistema! Frecuentemente se usan la siglas <6=E (<H;D2 <reate, Head, ;pdate and Delete) para denotar las actividades <rear, 6eer, =ctuali'ar Eliminar, 1ue un sistema de/e e-ecutar en cada arc)ivo maestro! ;na matri' <6=E es una )erramienta 1ue sirve para representar en 1ue parte del sistema ocurre cada uno de estos procesos! 6os diagramas de flu-o de datos f7sicos tam/in tienen almacenes de datos intermedios, con frecuencia un arc)ivo de transaccin o una ta/la de /ase de datos temporal! = menudo, los almacenes de datos intermedios consisten en arc)ivos de transaccin 1ue se utili'an para almacenar datos entre procesos! Dado 1ue es poco pro/a/le 1ue la ma or7a de los procesos re1uieren acceso a un con-unto determinado de datos se e-ecuten al mismo tiempo, los arc)ivos de transaccin de/en guardar los datos de un proceso para luego enviarlo al siguiente! Eam/in se puede incluir informacin relacionada con el tiempo! *or e-emplo, un DFD f7sico podr7a indicar 1ue un programa de edicin se de/e e-ecutar antes 1ue un programa de actuali'acin! 6as actuali'aciones de/en e-ecutarse antes 1ue la ela/oracin de un informe resumido, o un pedido de/e ingresarse en un sitio Se/ antes de verificar con la institucin financiera la cantidad cargada a una tar-eta de crdito! = causa de estas consideraciones, un diagrama de flu-o de datos f7sico podr7a tener una apariencia ms lineal 1ue la de un modelo lgico! documentos impresos! los procesos se realicen
N% *aradigmas de la 9ngenier7a de :oftware
:e de/e de crear el diagrama de flu-o de datos f7sico para un sistema mediante el anlisis de su entrada su salida! =l crear un diagrama de flu-o de datos f7sico, el el flu-o de flu-o de datos de entrada proveniente de una entidad e0terna en ocasiones se denomina detonador por1ue inicia las actividades de un proceso, datos de salida de una entidad e0terna se denomina respuesta por1ue se env7a como resultado de alguna actividad! :e determina 1u campo o elementos de datos es necesario teclear! Estos campos se denominan elementos bsicos se de/en almacenar en un arc)ivo! 6os elementos 1ue no se teclean sino 1ue son resultados de un clculo o de una operacin lgica se conocen como elementos derivados!
3.1.1.- .articionamiento de los diagramas de flujos de datos [3]

Este es un proceso de e0aminar un diagrama de flu-o de datos como se de/e dividir en colecciones de procedimientos manuales se determina colecciones
de programas de cmputo! =nalice cada procedo para determinar si de/e ser un proceso manual o automati'ado! =grupe los procedimientos automati'ados en una serie de programas de cmputo! ;sualmente se tra'a una l7nea punteada alrededor de un proceso o grupo de procesos 1ue de/en colocarse en un solo programa de cmputo! E0isten seis ra'ones para particionar diagramas de flu-os de datos2 3! Diferentes grupos de usuarios! +6os procesos son reali'ados por varios grupos de usuarios diferentes, con frecuencia en distintas u/icaciones f7sicas de la compa#7a.! :i es as7, se de/en particionar en diferentes programas de cmputo! 4! :intoni'acin! En esta parte se de/e e0aminar 1ue los procesos se sincronicen! :i dos procesos se reali'an en diferentes momentos, no se puede agrupar en un programa!
N3 *aradigmas de la 9ngenier7a de :oftware
3! Eareas similares! :i dos procesos e-ecutan tareas similares, es posi/le agruparlos en un solo programa de cmputo! 5! Eficiencia! En un programa se podr7a com/inar varios procesos para reali'ar un procesamiento eficiente! P! <onsistencia de los datos! 6os procesos se podr7an com/inar en un solo programa para mantener la consistencia de los datos! 8! :eguridad! 6os procesos se podr7an particionar en diferentes programas por ra'ones de seguridad!
3.1.) Diccionarios de datos [3]

El diccionario de datos surge de la necesidad de catalogar los procesos, flu-os almacenes estructuras elementos de datos! 6os nom/res 1ue se usan son mu importantes! <uando se tiene la oportunidad de asignar nom/re a los componentes de los sistemas orientados a datos, es necesario tra/a-ar en la creacin de un nom/re significativo pero diferente al de otros componentes de datos e0istentes! :e )a propuesto el diccionario de datos como gramtica casi formal para descri/ir el contenido de los o/-etos definidos durante el anlisis estructurado! Esta notacin )a sido definida de la siguiente forma por (ourdon en 3NMN2 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 tambi n los clculos intermedios. [4] "uc)os sistemas de administracin de /ase de datos estn e1uipados con un diccionario de datos automati'ado! Estos diccionarios pueden ser comple-os o sencillos, algunos diccionarios de datos computari'ados catalogan
automticamente los elementos de datos cuando se )ace la programacinD otros simplemente proporcionan una plantilla para motivar a la persona 1ue llene el diccionario a 1ue lo )aga de una manera uniforme para cada entrada! = pesar de la e0istencia de los diccionarios de datos automati'ados, entender 1u datos conforman un diccionario de datos, las convenciones usadas en estos Cltimos y cmo se desarrolla un diccionario de datos, son pro/lemas 1ue el analista de sistemas de/e tener siempre presentes durante el esfuer'o de sistemas! Entender el proceso de compilar un diccionario de datos puede a udar al analista de sistemas a visuali'ar el sistema y su funcionamiento! =dems de proporcionar documentacin y eliminar la redundancia, el diccionario datos se podr7a usar para2 3! Ialidar la integridad y e0actitud del diagrama de flu-o de datos! 4! *roporcionar un punto de partida para desarrollar pantallas e informes, 3! Determinar el contenido de los datos almacenados en arc)ivos! 5! Desarrollar la lgica para los procesos del diagrama de flu-o de datos,
3.1.).1 Depsito de datos [3] [4]

=un1ue el diccionario de datos contiene informacin de los datos y
procedimientos, una coleccin ms grande de informacin de pro ectos se llama depsito, El concepto depsito es uno de los muc)os impactos de las )erramientas <=:E y podr7a contener lo siguiente2 3! 9nformacin so/re los datos mantenidos por el sistema, inclu endo flu-os de datos, almacenes de datos, estructuras de registros y elementos! 4! 6gica de procedimientos! 3! Dise#o de pantallas e informes! 5! Helaciones entre datos, por e-emplo cmo se vincula una estructura de datos con otra! P! He1uerimientos del pro ecto y productos del sistema final!
8! 9nformacin so/re la administracin del pro ecto, tal como itinerarios de entrega,O pro/lemas pendientes de solucin y usuarios del pro ecto! *or lo general, los flu-os de datos son los primeros elementos 1ue se definen! 6as entradas salidas del sistema se determinan mediante las entrevistas el anlisis de documentos la o/servacin de los usuarios, de otros sistemas
e0istentes! 6a informacin capturada se puede resumir usando un formulario 1ue contenga la siguiente informacin2 3! 9D, un numero de identificacin opcional! = veces este se codifica usando un es1uema para identificar el sistema te0to 1ue de/e aparecer en el diagrama descripciones 1ue usen el flu-o de datos! 3! ;n a descripcin general del flu-o de datos! 5! 6a fuente del flu-o de datos! Esta podr7a ser una entidad e0terna, un proceso o influ-o de datos proveniente de un almacn de datos! P! El destino del flu-o de datos! Esta podr7a ser una entidad e0terna, un proceso o influ-o de datos proveniente de un almacn de datos! 8! =lgo 1ue indi1ue si el flu-o de datos es un registro 1ue esta entrando o saliendo de un arc)ivo o un registro 1ue contiene un informe, formulario o pantalla! :i el flu-o de datos contiene datos 1ue se usan entre los procesos, se designa como interno! $! El nom/re de la estructura de datos 1ue descri/e los elementos encontrados en este flu-o de datos! *ara un flu-o de datos simple, podr7an ser uno o varios elementos! M! el volumen por unidad de tiempo! 6os datos podr7an ser registros por d7a o cual1uier otra unidad de tiempo! N! ;n rea para comentarios adicionales anotaciones so/re el flu-o de datos! la aplicacin del sistema! se de/e referenciar en todas las 4! ;n solo nom/re descriptivo para este flu-o de datos! Este nom/re es el
Descripcin de las estructuras de datos [3] Gormalmente las estructuras de datos se descri/en usando una notacin alge/raica! Este mtodo permite al analista producir la vista de los elementos 1ue constitu en la estructura de datos -unto con informacin referente a dic)os elementos! 6a notacin alge/raica usa los siguientes s7m/olos2 3! ;n signo de igual (T) significa Uesta compuesto deV! 4! ;n signo de suma (W) significa U V! 3! 6as llaves X Y indican elementos repetitivos, tam/in llamados grupos de repeticin o ta/las! En el grupo podr7a )a/er un elemento de repeticin o varios de ellos! El grupo de repeticin podr7a tener condiciones, tal como un nCmero fi-o de repeticiones o limites superiores e inferiores para el nCmero de repeticiones! 5! 6os corc)etes [ ] representan una situacin de uno u otro! :e podr7a representar un elemento u otro, pero no am/os! 6os elementos listados entre los corc)etes son mutuamente e0clu entes! P! 6os parntesis ( ) representan un elemento opcional! 6os elementos opcionales se podr7an de-ar en /lanco en la entrada de las pantallas podr7an contener espacios o ceros para campos numricos en las estructuras de arc)ivos! Estructuras de datos 6gicas F7sicas [3]
<uando son definidas las estructuras de datos por primera ve', slo son incluidos los elementos de datos 1ue el usuario podr ver, tales como nom/re, direccin saldo! Esta etapa es el dise#o lgico, mostrando cules datos necesita el negocio para su operacin diaria! ;sando dise#o lgico como /ase, el analista dise#a luego las estructuras de datos f7sicas! Estas inclu en elementos adicionales para la implementacin del sistema! E-emplos de elementos de dise#o f7sico2 3! <ampos clave usados para locali'ar registros en una /ase de datos
NP *aradigmas de la 9ngenier7a de :oftware
4! 3! 5! P! 8!
<digos para identificar el estado de registros maestros! Estos cdigos se pueden mantener en arc)ivos 1ue generen informacin de impuestos! 6os cdigos de transaccin son utili'ados para identificar tipos de registros cuando un arc)ivo contiene tipos de registros diferentes! 6as entradas de grupos repetidos contienen un contador so/re 1u tantos conceptos )a en el grupo! 67mites so/re la cantidad de conceptos acepta/les en un grupo repetido! ;na contrase#a usada por un cliente 1ue accede a un sitio we/ seguro!
Elementos de datos [3] <ada elemento de datos se de/e definir una ve' en el diccionario de datos tam/in se podr7a introducir previamente en un formulario de descripcin del elemento! <aracter7sticas de un formulario de descripcin de elementos2 3! 4! 9D del elemento! Esta entrada opcional permite construcciones entradas de diccionario de datos El nom/re del elemento! El nom/re de/e ser descriptivo, Cnico programas o por el usuario principal del elemento! 3! 5! P! =lias, son sinnimos u otros nom/res para el elemento! ;na descripcin /reve del elemento :i el elemento es /ase o derivado! Elemento /ase es el 1ue se teclea inicialmente en el sistema, nom/re del cliente direccin o ciudadD se de/en almacenar en arc)ivos! 6os elementos derivados son creados por procesos como resultado de clculo! 8! 6a longitud del elemento! =lgunos elementos tienen longitudes estndar otras veces pueden variar para otros elementos, a1u7 se de/e decidir en con-unto con el usuario la longitud final! /asado en el propsito al cual esta destinado el elemento en la ma or7a de los
$! M! N!
El tipo de datos2 numrico, fec)a, alfa/tico o carcter 1ue a veces se llama datos alfanumricos o de te0to! 6os formatos de entrada salida se de/en incluir, usando s7m/olos de codificacin especiales para indicar como se de/en presentar los datos! 6os criterios de validacin para asegurar 1ue el sistema capture los datos correctos! 6os elementos pueden ser discretos, lo cual significa 1ue tiene ciertos valores fi-os o continuos, con un rango pare-o de valores!
3%!
<ual1uier valor predeterminado 1ue pudiera tener el elemento! El valor predeterminado se despliega en las pantallas de entrada se usa para reducir la cantidad de datos 1ue tuviera 1ue teclear el operador!
33!
;n rea adicional para o/servaciones o comentarios!
=lmacenes de datos [3] Eodos lo elementos /ase se de/en almacenar en el sistema! Eam/in los elementos derivados se podr7an almacenar en el sistema, tal como, para un empleado, el sueldo /ruto acumulado a la fec)a! 6os almacenes de datos se crean, cuando los elementos /ase de un flu-o de datos se agrupan para formar un registro estructural, se crea un almacn de datos para cada registro estructural Cnico!
3.1.).) Creacin del diccionario de datos [3]

6as entradas del diccionario de datos se podr7an crear despus de completar el diagrama de flu-o de datos, o se podr7an construir conforme se desarrolle el diagrama de flu-o de datos! El uso de notacin alge/raica permite desarrollar el diccionario de datos mediante un enfo1ue -err1uico de arri/a a /a-o! Despus de reali'ar varias entrevistas adicionales para descu/rir los detalles del sistema, se puede e0tender el diagrama de flu-o de datos se crearan los registros estructurales los diagramas de flu-os de datos
N$ *aradigmas de la 9ngenier7a de :oftware
diagramas )i-os! *osteriormente se modifica el diccionario de datos para incluir los nuevos registros estructurales o/servacin elementos reca/ados en las entrevistas, anlisis de documentos posteriores!
<ada nivel de un diagrama de flu-o de datos de/e usar datos adecuados para el nivel! El diagrama % de/e incluir Cnicamente formularios, pantallas informes registros! <onforme se creen los diagramas )i-os, el flu-o de datos 1ue entre salga de los procesos ser cada ve' estructurales los elementos! salidas [3] mas detallado, inclu endo los registros
=nlisis de las entradas
;n paso importante en la creacin del diccionario de datos es identificar categori'ar el flu-o de datos de entrada incluidos2 3! Gom/re descriptivo para la entrada o la salida! :i el flu-o de datos esta en un diagrama lgico, el nom/re de/e identificar el propsito de los datos! 4! El contacto del usuario responsa/le para la clarificacin de detalles adicionales, retroalimentacin del dise#o 3! :i los datos son de entrada o salida 5! El formato de flu-o de datos! En la fase del dise#o lgico, el formato podr7a ser indeterminado! P! Elementos 1ue indican la secuencia de los datos en un informe o pantalla! 8! ;na lista de elementos, inclu endo sus nom/res, longitudes derivados sus criterios de edicin! si son /ase o apro/acin final salida del sistema! <ampos comCnmente
Desarrollo de almacenes de datos [3] Ftra actividad es el desarrollo de los almacenes de datos! Esta informacin se descri/e en estructuras de datos! :in em/argo la informacin podr7a estar almacenada en diferentes lugares, el almacn de datos podr7a ser diferente en
NM *aradigmas de la 9ngenier7a de :oftware
cada lugar! "ientras 1ue los flu-os de datos representan datos en movimiento, los almacenes de datos representan datos en reposo! 6os almacenes de datos contienen informacin de una naturale'a permanente o semipermanente! <uando los almacenes de datos se crean para un solo informe o pantalla nos referimos a ellos como Uvistas del usuarioV, por1ue representan la manera en 1ue el usuario 1uiere ver la informacin! ;so del diccionario de datos [3] El diccionario de datos ideal es automati'ado, interactivo, en l7nea evolutivo!
<onforme el analista de sistemas descu/re cosas nuevas de los sistemas de la organi'acin, se agregan elementos de datos al diccionario de datos! El diccionario de datos no es un fin en si mismo verse como una actividad paralela al anlisis nunca de/e serlo, siempre de/e dise#o de sistemas!
El diccionario de datos de/e vincular a varios programas de sistemas para 1ue cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo mismo en la /ase de datos! El diccionario de datos se vuelve una curiosidad )istrica sino se mantiene actuali'ado!
3.1.3 Dise+o de mdulos [4]

El concepto de modularidad se )a ido e0poniendo desde )ace casi cinco dcadas en el software de computadora! 6a ar1uitectura de computadora e0presa la modularidadD es decir, el software se divide en componentes nom/rados a/ordados por separado, llamados frecuentemente mdulos, 1ue se integran para satisfacer los re1uisitos del pro/lema!
NN *aradigmas de la 9ngenier7a de :oftware
:e )a afirmado 1ue U6a modularidad es el Cnico atri/uto del software 1ue permite gestionar un programa intelectualmenteV! El software monol7tico (es decir, un programa grande formado por un Cnico modulo) no puede ser entendido fcilmente por el lector! 6a cantidad de rutas de control, la amplitud de referencias, la cantidad de varia/les la comple-idad glo/al )ar 1ue el entendimiento este mu cerca de ser imposi/le! *ara ilustrar este punto, tomemos en consideracin el siguiente argumento /asado en o/servaciones )umanas so/re la resolucin de pro/lemas! *ensemos 1ue <(0) es una funcin 1ue define la comple-idad perci/ida de un pro/lema 0, 1ue E(0) es una funcin 1ue define el esfuer'o (oportuno) 1ue se p4, si re1uiere para resolver un pro/lema 0! para dos pro/lemas p3 <(p3) Z <(p4) 9mplica 1ue E(p3) Z E(p4) (3!3/) (3!3a)
En general, este resultado es por intuicin o/vio! :e tarda ms en resolver un pro/lema dif7cil! "ediante la e0perimentacin )umana en la resolucin de pro/lemas se )a averiguado otra caracter7stica interesante! Esta es, <(p3 W p4) Z <(p3) W <(p4) (3!4)
6a ecuacin 3!4 implica 1ue la comple-idad perci/ida de un pro/lema 1ue com/ina p3 p4, es ma or 1ue la comple-idad perci/ida cuando se considera cada la condicin pro/lema por separado! Eeniendo en cuenta la ecuacin (3!4) implicada por la ecuacin (3!3) se esta/lece 1ue E(p3 W p4) Z E(p3) W E(p4) (3!3)
3%% *aradigmas de la 9ngenier7a de :oftware
Esto lleva a una conclusin2 Udivide
vencersV es ms fcil resolver un pro/lema al
comple-o cuando se rompe en pie'as mane-a/les! El resultado e0presado en la ecuacin 3!3 implica 1ue es importante en lo 1ue respecta a la modularidad software! Es, de )ec)o, un argumento para la modularidad! Es posi/le concluir de la ecuacin (3!3) 1ue si su/dividimos el software indefinidamente, el esfuer'o 1ue se re1uiere para desarrollarlo ser7a m7nimo! Desgraciadamente, intervienen otras fuer'as, 1ue )acen 1ue esta conclusin sea (tristemente) falsa! <omo muestra la figura 3!5, el esfuer'o (costo) para desarrollar un mdulo software individual disminu e a medida 1ue aumenta el nCmero total de mdulos! Dado el mismo con-unto de re1uisitos2 tener ms mdulos conduce a un tama#o menor de mdulo! :in em/argo, a medida 1ue aumenta el nCmero de mdulos, tam/in crece el esfuer'o (costo) asociado con la integracin de mdulos! Estas caracter7sticas conducen tam/in a la curva total del costo o esfuer'o 1ue se muestra en la figura! E0iste un nCmero ! de mdulos 1ue dar7a como resultado un costo m7nimo de desarrollo, aun1ue no tenemos la sofisticacin necesaria para predecir ! con seguridad!
3%3 *aradigmas de la 9ngenier7a de :oftware
<osto de Esfuer'o
Hegin de costo m7nimo
"
<osto total del software
<osto de 9ntegracin
<osto[ modulo
GCmero de mdulos
"igura 3.- Esfuer'o <osto en modularidad

*ressman Hoger :! 9ngenier7a del software, Ed! "c Lraw Aill, PB edicin
6as curvas de la Figura 3!5 proporcionan en efecto una gu7a Ctil cuando se tiene en consideracin la modularidad! 6a modularidad de/er aplicarse, pero teniendo cuidado de estar pr0imo a "! :e de/er evitar modulari'ar de ms o de menos! <uando se tiene en consideracin la modularidad surge otra pregunta importante! +<mo se define un modulo con un tama#o adecuado. 6a respuesta se, encuentra en los mtodos utili'ados para definir los mdulos dentro de un sistema! "e er define cinco criterios 1ue nos permitirn evaluar un mtodo de dise#o en relacin con la )a/ilidad de definir un sistema modular efectivo2 Capacidad de descomposicin modular! :i un mtodo de dise#o proporciona un mecanismo sistemtico para descomponer el pro/lema en su/pro/lemas, reducir la comple-idad de todo el pro/lema, consiguiendo de esta manera una solucin modular efectiva!
Capacidad de empleo de componentes modulares ! :i un mtodo de dise#o permite ensam/lar los componentes de dise#o (reusa/les) e0istentes en un sistema nuevo, producir una solucin modular 1ue no inventa nada a inventado!
Capacidad de comprensin modular ! :i un mdulo se puede comprender como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir de cam/iar!
Continuidad modular! :i pe1ue#os cam/ios en los re1uisitos del sistema provocan cam/ios en los mdulos individuales, en ve' de cam/ios generali'ados en el sistema, se minimi'ar el impacto de los efectos secundarios de los cam/ios!
.roteccin modular! :i dentro de un mdulo se produce una condicin a/surda sus efectos se limitan a ese mdulo, se minimi'ar el impacto de los efectos secundarios inducidos por los errores!
Finalmente, es importante destacar 1ue un sistema se puede dise#ar modularmente, incluso aun1ue su implementacin de/a ser Umonol7ticaV! E0isten situaciones (por e-emplo, software en tiempo real, software empotrado) en donde no es admisi/le 1ue los su/programas introdu'can so/recargas de memoria tales situaciones el software podr de velocidad por m7nimos 1ue sean (por e-emplo, su/rutinas, procedimientos)! En de/er dise#arse con modularidad como filosof7a predominante! El cdigo se puede desarrollar Uen l7neaV! =un1ue el cdigo fuente del programa puede no tener un aspecto modular a primera vista, se )a mantenido la filosof7a modular! el programa proporcionar los /eneficios de un sistema
3.1.3.1 Dise+o /odular Efecti$o [4]

6a modularidad se )a convertido en un enfo1ue aceptado en todas las disciplinas de ingenier7a! ;n dise#o modular reduce la comple-idad, facilita los cam/ios (un aspecto cr7tico de la capacidad de mantenimiento del software), 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 conceptos de a/straccin so/re el dise#o del software, *amas :tevens, S ers de los
ocultacin de informacin! En referencias o/ligadas Sirt) sugieren a las tcnicas de
refinamiento 1ue me-oran la independencia de mdulos! Era/a-os posteriores de <onstantine consolidaron el concepto!
6a independencia funcional se consigue desarrollando mdulos con una funcin UdeterminanteV re1uisitos una UaversinV a una interaccin e0cesiva con otros mdulos! Es necesario dise#ar el software de manera 1ue cada mdulo trate una su/funcin de tenga una interfa' sencilla cuando se o/serva desde otras partes de la estructura del programa! +*or 1u es importante la independencia. El software con una modularidad efectiva, es decir, mdulos independientes, es ms fcil de desarrollar por1ue la funcin se puede compartimentar desarrollo se )ace en e1uipo)! 6os mdulos independientes son ms fciles de mantener ( pro/ar) por1ue se limitan los efectos secundarios originados por modificaciones de dise#o[cdigoD por1ue se reduce la propagacin de erroresD por1ue es posi/le utili'ar mdulos usa/les! En resumen, la independencia funcional es la clave para un /uen dise#o el dise#o es la clave para la calidad del software! 6a independencia se mide mediante dos criterios cualitativos2 la co)esin el las interfaces se simplifican (tengamos en consideracin las ramificaciones cuando el
acoplamiento! 6a cohesin es una medida de la fuer'a relativa funcional de un mdulo! El acoplamiento es una medida de la independencia relativa entre los mdulos!
3.1.3.) Co#esin [4]

6a co)esin es una e0tensin natural del concepto de ocultacin de informacin (la informacin 1ue esta dentro de un modulo de/e ser inaccesi/le a otros mdulos 1ue no necesiten esa informacin)! ;n mdulo co)esivo lleva a ca/o una sola tarea dentro de un procedimiento de software, lo cual re1uiere poca interaccin con los procedimientos 1ue se llevan a ca/o en otras partes de un programa! Dic)o de manera sencilla, un mdulo co)esivo de/er (idealmente) )acer una sola cosa! 6a co)esin se puede representar como un UespectroV! :iempre de/emos /uscar la co)esin ms alta, aun1ue la parte media del espectro suele ser acepta/le! 6a escala de co)esin no es lineal! Es decir, la parte /a-a de la co)esin es muc)o UpeorV 1ue el rango medio, 1ue es casi tan U/uenoV como la parte alta de la escala! En la prctica, un dise#ador no tiene 1ue preocuparse de categori'ar la co)esin en un mdulo espec7fico! "s /ien, se de/er entender el concepto glo/al, se de/ern evitar los niveles /a-os de co)esin al dise#ar los cdigos! as7
3.1.3.).1 ,i$eles de co#esin

<o)esin <asual o <oincidental [M] [N] [4] 6a cohesin casual ocurre cuando e0iste poca o ninguna relacin entre los elementos de un mdulo! 6a co)esin casual esta/lece un punto cero en la escala de co)esin! Es mu dif7cil encontrar mdulos puramente casuales! *uede aparecer como resultado de la modulari'acin de un programa a escrito, en el cual el programador encuentra un determinada secuencia de instrucciones 1ue se repiten de forma aleatoria, decide por lo tanto agruparlas en una rutina!
3%P *aradigmas de la 9ngenier7a de :oftware
Ftro factor 1ue influenci muc)as veces la confeccin de mdulos casualmente co)esivos, fue la mala prctica de la programacin estructurada, cuando los programadores mal entend7an 1ue modulari'ar consist7a en cam/iar las sentencias ULFEFV por llamadas a su/rutinas Finalmente diremos 1ue si /ien en la prctica es dif7cil encontrar mdulos casualmente co)esivos en su totalidad, es comCn 1ue tengan elementos casualmente co)esivos! Eal es el caso de operaciones de iniciali'acin terminacin 1ue son puestas -untas en un mdulo superior! De/emos notar 1ue si /ien la co)esin casual no es necesariamente per-udicial (de )ec)o es preferi/le un programa casualmente co)esivo a uno lineal), dificulta las modificaciones mantenimiento del cdigo!
<o)esin 6gica [M] [N] [4] 6os elementos de un mdulo estn lgicamente asociados si puede pensarse en ellos como elementos 1ue pertenecen a la misma clase lgica de funciones, es decir a1uellas 1ue pueden pensarse como lgicamente -untas! *or e-emplo, se puede com/inar en un mdulo simple todos los elementos de procesamiento 1ue caen en la clase de OentradasO, 1ue a/arca todas las operaciones de entrada! *odemos tener un mdulo 1ue lea desde consola una tar-eta con parmetros de control, registros con transacciones errneas de un arc)ivo en cinta, registros con transacciones vlidas de otro arc)ivo en cinta, llamarse O6ecturasO, lgicamente co)esivo! 6a co)esin lgica es ms fuerte 1ue la casual, de/ido a 1ue representa un mnimo de asociacin entre el problema y los elementos del mdulo ! :in em/argo podemos ver 1ue un mdulo lgicamente co)esivo no realiza una funcin especfica, sino que abarca una serie de funciones.
los
registros maestros anteriores de un arc)ivo en disco! Este mdulo 1ue podr7a 1ue agrupa todas las operaciones de entrada, es
<o)esin Eemporal [M] [N] [4] "ohesin #emporal significa que todos los elementos de procesamiento de una coleccin ocurren en el mismo perodo de tiempo durante la ejecucin del sistema ! De/ido a 1ue dic)o procesamiento de/e o puede reali'arse en el mismo per7odo de tiempo, los elementos asociados temporalmente pueden com/inarse en un Cnico mdulo 1ue los e-ecute a la misma ve'! E0iste una relacin entre co)esin lgica la temporal, sin em/argo, la primera no
implica una relacin de tiempo entre los elementos de procesamiento! 6a co)esin temporal es ms fuerte 1ue la co)esin lgica, a 1ue implica un nivel de relacin ms2 el factor tiempo! :i em/argo la co)esin temporal aCn es po/re en nivel de co)esin sistema! ;n e-emplo comCn de co)esin temporal son las rutinas de iniciali'acin (startKup) comCnmente encontradas en la ma or7a de los programas, donde se leen parmetros de control, se a/ren arc)ivos, se iniciali'an varia/les contadores acumuladores, etc! <o)esin de *rocedimiento [M] [N] [4] Elementos de procesamiento relacionados procedimentalmente son elementos de una unidad procedimental comCn! Estos se combinan en un mdulo de cohesin procedimental que implica una secuencia de ejecucin de los pasos ! ;na unidad procedimental comCn puede ser un proceso de iteracin (loop) de decisin, o es similar una secuencia lineal de pasos! En este Cltimo caso la co)esin es /a-a determinada secuencia de e-ecucin de los pasos! acarrea inconvenientes en el mantenimiento modificacin del
a la co)esin temporal, con la diferencia 1ue la co)esin temporal no implica una
3%$ *aradigmas de la 9ngenier7a de :oftware
=l igual 1ue en los casos anteriores, para decir 1ue un mdulo tiene solo co)esin procedimental, los elementos de procesamiento de/en ser elementos de alguna iteracin, decisin, o secuencia, pero no de/en estar vinculados con ningCn principio asociativo de orden superior! 6a co)esin procedimental asocia elementos de procesamiento so/re la /ase de sus relaciones algor7tmicas o procedimentales! Este nivel de co)esin comCnmente se tiene como resultado de derivar una estructura modular a partir de modelos de procedimiento como ser diagramas de flu-o, o diagramas GassiK:)neiderman! <o)esin de <omunicacin [M] [N] [4] Ginguno de los niveles anteriores est fuertemente vinculado a una estructura de pro/lema en particular! <o)esin de <omunicacin es el menor nivel en el cual se encuentra una relacin entre los elementos de procesamiento 1ue es espec7ficamente dependiente del pro/lema!
/ c
"igura 3.0 =sociacin por comunicacin

3%M *aradigmas de la 9ngenier7a de :oftware
$ecir 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!P podemos o/servar 1ue los elementos de procesamiento a, /, c, estn asociados por comunicacin so/re la corriente de d se vinculan por los datos de salida! datos de entrada, en tanto 1ue /, c,
6os diagramas de flu-o de datos (DFD) son un medio o/-etivo para determinar si los elementos en un mdulo estn asociados por comunicacin! 6as relaciones por comunicacin presentan un grado de co)esin acepta/le! 6a co)esin por comunicacin es comCn en aplicaciones comerciales! =lgunos e-emplos pueden ser2 un mdulo 1ue imprima o gra/e un arc)ivo de transaccionesD un mdulo 1ue reci/a datos de diferentes fuentes, ensam/le en una l7nea de impresin! los transforme
3%N *aradigmas de la 9ngenier7a de :oftware
<o)esin :ecuencial [M] [N] [4] En este nivel de co)esin, 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 flu-o de datos de un pro/lema, la co)esin secuencial com/ina una cadena linear de sucesivas transformaciones de datos! Este es claramente un principio asociativo relacionado con el dominio del pro/lema! <o)esin Funcional [M] [N] [4] En el l7mite superior del espectro de relacin funcional encontramos la cohesin funcional! simple! En trminos prcticos podemos decir 1ue co)esin funcional es aquella que no es secuencial, por comunicacin, por procedimiento, temporal, lgica, o casual ! 6os e-emplos ms claros ser altamente co)esivo, comprensi/les provienen del campo de las pro/a/lemente, completamente funcional! Go es no es pro/a/le 1ue elementos de En un mdulo completamente funcional, cada elemento de procesamiento, es parte integral de, y esencial para, la realizacin de una funcin
matemticas! ;n mdulo para reali'ar el clculo de raz cuadrada ciertamente pro/a/le 1ue )a a elementos superfluos ms all de los a/solutamente esenciales para reali'ar la funcin matemtica, procesamiento puedan ser agregados sin alterar el clculo de alguna forma! En contraste un mdulo 1ue calcule ra7' cuadrada coseno, es impro/a/le 1ue
sea enteramente funcional (de/en reali'arse dos funciones am/iguas)!
33% *aradigmas de la 9ngenier7a de :oftware
En adicin a estos e-emplos matemticos o/vios, usualmente podemos reconocer mdulos funcionales 1ue son elementales en naturale'a! ;n mdulo llamado 6EEHKHEL9:EHFK"=E:EHF, o EH=E=HKEH=G:KE9*F3, presumi/lemente sern funcionalmente co)esivos, en cam/io EH=E=HKEFD=:KEH=G: presumi/lemente reali'ar ms de una funcin ser lgicamente co)esivo!
6legamos a la conclusin 1ue no es necesario determinar el nivel preciso de co)esin! "s /ien, es importante intentar conseguir una co)esin alta
reconocer cuando )a poca co)esin para modificar el dise#o del software

conseguir una ma or independencia funcional!
3.1.3.3 Acoplamiento [4]

El acoplamiento es una medida de intercone0in entre mdulos dentro de una estructura de software! El acoplamiento depende de la comple-idad de intercone0in entre los mdulos, el punto donde se reali'a una entrada o referencia a un mdulo, los datos 1ue pasan a travs de la interfa'!
6os cuatro factores principales 1ue influ en en el acoplamiento entre mdulos son2 Eipo de cone0in entre mdulos2 6os sistemas normalmente conectados, tienen menor acoplamiento 1ue a1uellos 1ue tienen cone0iones patolgicas! <omple-idad de la interfa'2 Esto es apro0imadamente igual al nCmero de producto diferentes pasados (no cantidad de datos)! "s producto, ma or acoplamiento! Eipo de flu-o de informacin en la cone0in2 los sistemas con acoplamiento de datos tienen menor acoplamiento 1ue los sistemas con acoplamiento de control, estos a su ve' menos 1ue los 1ue tienen acoplamiento )7/rido! "omento en 1ue se produce el ligado de la <one0in2 <one0iones ligadas a referentes fi-os en tiempo de e-ecucin, resultan con menor acoplamiento 1ue cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su ver
333 *aradigmas de la 9ngenier7a de :oftware
menor acoplamiento 1ue cuando el ligado se reali'a en tiempo de lin\ageK edicin, el cual tiene menos acoplamiento 1ue el 1ue se reali'a reali'a en tiempo de compilacin, todos los 1ue a su ve' tiene menos acoplamiento 1ue cuando el ligado se reali'a en tiempo de codificacin! En el dise#o del software, intentamos conseguir el acoplamiento ms /a-o posi/le! ;na conectividad sencilla entre los mdulos da como resultado un software ms fcil de entender menos propenso a tener un Uefecto olaV causado cuando se propagan por el sistema! ocurren errores en un lugar
Estructura de datos
Estructura de datos
a
Datos (varia/les)
9ndicador de control
) ]rea de datos glo/ales
"igura 3.1 Eipos de acoplamiento

6a figura 3!8 proporciona e-emplos de diferentes tipos de acoplamiento de mdulos! 6os mdulos a relacionado su/ordinado al mdulo a d son su/ordinados a mdulos diferentes! Ginguno est se accede a l mediante una lista de argumentos por la por tanto no ocurre un acoplamiento directo! El mdulo c es
1ue pasan los datos! :iempre 1ue tengamos una lista convencional simple de argumentos (es decir, el paso de datosD la e0istencia de correspondencia uno a uno entre elementos), se presenta un acoplamiento /a-o (llamado acoplamiento de datos& en esta parte de la estructura! ;na variacin del acoplamiento de datos,
llamado acoplamiento de marca %stamp&, se da cuando una parte de la estructura de datos (en ve' de argumentos simples) se pasa a travs de la interfa'! Esto ocurre entre los mdulos b a.
En niveles moderados el acoplamiento se caracteri'a por el paso de control entre mdulos! El acoplamiento de control es mu comCn en la ma or7a de los dise#os de software se muestra en la figura! 3!8 en donde un Uindicador de controlV (una e. varia/le 1ue controla las decisiones en un mdulo superior o su/ordinado) se pasa entre los mdulos d
<uando los mdulos estn atados a un entorno e0terno al software se dan niveles relativamente altos de acoplamiento! *or e-emplo, la E[: acopla un mdulo a dispositivos, formatos protocolos de comunicacin! El acoplamiento e'terno es esencial, pero de/er limitarse a unos pocos mdulos en una estructura! Eam/in aparece un acoplamiento alto cuando varios mdulos )acen referencia a un rea glo/al de datos! El acoplamiento com(n, tal muestra en la Figura 3!8! 6os mdulos c, g como se denomina este caso, se ) acceden a elementos de datos en
un rea de datos glo/al (por e-emplo, un arc)ivo de disco o un rea de memoria totalmente accesi/le)! El mdulo c iniciali'a el elemento! "s tarde el mdulo g vuelve a calcular el elemento lo actuali'a! :upongamos 1ue se produce un error falla, )aciendo 1ue g actuali'a el elemento incorrectamente! "uc)o ms adelante en el procesamiento, el mdulo ) lee el elemento, intenta procesado acoplamiento comCn es costoso en tiempo 1ue se interrumpa el sistema! El diagnstico de pro/lemas en estructuras con es dif7cil! :in em/argo, esto no significa necesariamente 1ue el uso de datos glo/ales sea UmaloV! :ignifica 1ue el dise#ador del software de/er ser consciente de las consecuencias posi/les, del acoplamiento comCn tener especial cuidado de prevenirse de ellos!
El grado ms alto de acoplamiento, acoplamiento de contenido, se da cuando un mdulo )ace uso de datos o de informacin de control mantenidos dentro de los l7mites de otro mdulo! En segundo lugar, el acoplamiento de contenido ocurre
cuando se reali'an /ifurcaciones a mitad de mdulo! Este modo de acoplamiento puede de/er evitarse!
3.1.- Descomposicin en procesos [4]

6as fases 1ue generalmente caracteri'an al proceso del software son2 definicin desarrollo y soporte, se aplican a todo software! El pro/lema es seleccionar el modelo de proceso apropiado para la ingenier7a del software 1ue de/e aplicar el e1uipo! El gestor del pro ecto de/e decidir 1ue modelo de proceso es el ms adecuado para2 3! 6os clientes 1ue )an solicitado el producto tra/a-oD 4! 6as caracter7sticas del producto en si 3! El entorno del pro ecto en el 1ue tra/a-a el e1uipo de software! <uando se selecciona un modelo de proceso, el e1uipo define entonces un plan de pro ecto preliminar /asado en con-unto de actividades estructurales! ;na ve' esta/lecido el plan preliminar, empie'a la descomposicin del proceso! Es decir, se de/e crear un plan completo refle-ando las tareas re1ueridas a las personas para cu/rir las actividades estructurales! ;n e1uipo de/er7a tener un grado significativo de fle0i/ilidad en la eleccin del paradigma de ingenier7a de software 1ue resulte me-or para el pro ecto elegido! ;n pro ecto cuando es relativamente pe1ue#o se de/e reali'ar con un enfo1ue secuencial lineal! :i )a limites de tiempo mu severos apropiado es tomar una estrategia incremental! le pro/lema se puede compartir, el modelo apropiado es el DH=! :i se tiene el tiempo limitado lo mas de las tareas de ingeniera del software 1ue conforman el modelo de proceso una ve' la gente 1ue reali'ara el
;na ve' 1ue )emos elegido el modelo de proceso, la Estructura "om(n de *rocesos %E"*& se adapta a el! En todos los casos, la E<* (comunicacin con el cliente, planificacin, anlisis de riesgo, ingenier7a, construccin, entrega 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 ensam/la-e de componentes! El E<* es invaria/le sirve como /ase para todo el tra/a-o de software reali'ado por una organi'acin! 6as tareas de tra/a-o reales si var7an! 6a descomposicin del proceso comien'a cuando el gestor del pro ecto pregunta +<mo vamos a reali'ar esta actividad E<*. ;n pro ecto simple re1uiere las siguientes tareas para la actividad de comunicacin con el cliente2 3! Desarrollar una lista de aspectos 1ue se de/en aclarar 4! Heunirse con el cliente para aclara los aspectos de la lista 3! Desarrollar en con-unto una e0posicin del m/ito del pro ecto 5! Hevisar el alcance del pro ecto con todos los implicados P! "odificar el alcance del pro ecto cuando se re1uiera! Este tipo de acontecimientos pueden ocurrir en un periodo de menos de 5M )rs! Hepresentan una descomposicin del pro/lema apropiado para pro ectos pe1ue#os relativamente sencillos! :i se considera un pro ecto ms comple-o 1ue tenga un m/ito ms amplio tareas para la actividad de comunicacin con el cliente2 3! Hevisar la peticin del cliente 4! *lanificar programar una reunin formal con el cliente 3! Heali'ar una investigacin para definir soluciones propuestas enfo1ues e0istentes! 5! *repara un plan de tra/a-o una agenda para la reunin formal un
ma or impacto comercial! ;n pro ecto como se podr7a re1uerir las siguientes
33P *aradigmas de la 9ngenier7a de :oftware
P! Heali'ar la reunin 8! Desarrollar con-untamente miniKespecificaciones 1ue refle-en la informacin, funcin software $! Hevisar todas las miniKespecificaciones para compro/ar correccin , su consistencia la ausencia de am/ig^edades M! Ensam/lar las miniKespecificaciones de un documento de alcance del pro ecto N! revisar ese documento general con todo lo 1ue pueda afectar 3%! modificar el documento de alcance del pro ecto cuando se re1uiera su caracter7sticas de comportamiento del

SDF p3

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SDF p3

Diunggah oleh

Hak Cipta:

Format Tersedia

Fundamentos de desarrollo de sistemas

3.1 El enfoque estructurado 3.1.1 Diagramas de flujos de datos [3]

El DFD fue desarrollado por De "arco en los a#os $%&s

Fundamentos de desarrollo de sistemas

=lmacn de datos "igura 3.1 :im/olog7a

$$ *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

origen o destino de datos,

se considera e0terna al sistema descrito! = cada

$M *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

3.1.1.) Desarrollo de Diagramas de "lujos de Datos [3]

$N *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

6os diagramas de flu-os de datos se pueden

de/en di/u-ar de manera

M% *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

*roceso general ===

*roceso general JJJ

:alida < Entidad 3

*roceso general <<<

*roceso general DDD

"igura 3.) Hepresentacin del diagrama de conte0to

del diagrama cero

dise#o de sistemas, Ed! *rentice Aall 8B ed

El diagrama cero es la ampliacin del diagrama de conte0to

puede incluir )asta

nueve procesos, esto se )ace por1ue si se agregan ms procesos producir un

Fundamentos de desarrollo de sistemas

HEL9:EHF DE6 E9E"*F

tendr7an 1ue calcular! <ada arc)ivo 1ue produce el reci/o de nmina!

registro estar7a conectado al proceso

M4 *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

Fundamentos de desarrollo de sistemas

Fundamentos de desarrollo de sistemas

El flu-o de datos coincidente

En un diagrama )i-o detallado se podr7an agregar l7neas de error

En los diagramas de nivel inferior se podr7an agregar arc)ivos de transacciones

El flu-o de salida de/e coincidir con el proceso padre

"igura 3.3 Hepresentacin del diagrama de conte0to

del diagrama cero

dise#o de sistemas, Ed! *rentice Aall 8B ed

MP *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

Fundamentos de desarrollo de sistemas

3.1.1.3 Diagramas de flujos de datos lgicos ' f sicos [3]

6as actividades del negocio

,ue representan los almacenes de datos

,ue representan los almacenes de datos

*abla 3.1 <aracter7sticas modelos lgicos

dise#o de sistemas, Ed! *rentice Aall 8B ed

M$ *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

Diagrama de flujo de datos lgico actual

>endall >ennet) E! ? >endall @ulie E!, =nlisis

dise#o de sistemas, Ed! *rentice Aall 8B ed

MM *aradigmas de la 9ngenier7a de :oftware

Fundamentos de desarrollo de sistemas

6os diagramas de flu-o de datos f7sicos tienen las siguientes venta-as!

Fundamentos de desarrollo de sistemas

3! =clara 1u procesos son manuales