modelo estructurado

Ingeniería de Sistemas II

IND-225

Capítulo 1

Capítulo No. 1 Modelo de Implementación 1. 1

Definic Definic ión ión :

Este modelo define “cómo” se podrá en práctica el diseño lógico del sistema, sin p e rd er d e vista vista que q ue "Dis Dise ño es e s el pro pro c e so de d e ap a p lica ic a r d isti istintas ntas téc nica s y principios con el propósito de definir un dispositivo, proceso, o sistema, con los suficientes detalles como para permitir su realización física" (E.S.Taylor, An Inte rim , Massachusetts Institute of Technology, 1959) Re p o rt o n Eng ine ering ering De sig n Este mod mo d elo se d esarro esarro lla lla e n tres tres etap eta p a s: a . Desa Desa rrolla olla r el Mod M odelo elo d e Pr P rogr og ra mas (In (Inge geni nierí ería a de Softwar oftwa re) b. Definir la plataforma de Hardware y el Software de Base sobre los que funcionará el sistema. c . De Dessa rro lla lla r e l Dise Diseño Físic Físico o de d el Sistema istema . 1. 2

El Mo d e lo d e Prog ram a s: Dis Dise ñ o Estruc truc tura d o

Se lla ma Dis Diseño Estruc tructur tura a d o a l proc proc eso eso d e dec de c idir los comp c ompone onentes ntes nec esa esa rios, ios, y la inter intercc onex one xión entr e ntre e los mis mismos, mos, pa ra soluciona oluc ionarr un un pr p robl ob lema d e softwar oftwa re bien especificado". El d iseño es una a c tivi tivid d a d que q ue c omienza omienza c uando ua ndo el ana lista de d e sis sistema temass ha produc prod ucido ido un conjunt c onjunto o d e requer eq ueriimientos mientos func funciona ionalles lóg lógico icoss pa ra un sis sistema tema,, y fina finalliza c uando ua ndo el diseña diseñad d or ha es e spec pe c ifi ific a d o los c ompone omp onentes ntes d el si sistema y las relaciones entre los mismos. Por ta ta nto, este este modelo mod elo tiene tiene c omo obj ob jetivo etivo defini d efinirr c uál uá les d e los p ro c esos esos que forma forman n par pa rte del de l M odelo od elo Es Esenc ia l serán automatiz a utomatiza a dos do s (ll (llevado eva doss a un computador) Una vez ve z que esos esos p roc esos esos hayan ha yan si sid o defini d efinido doss, el M odelo od elo de d e Progr Prog ra mas debe de be ser c a pa z d e interpr interpreta etarr el leng lengua uajje es e struc tructur tura a do y tr tra nsfor nsforma marrlo en e n un conjunt c onjunto o de programas, gracias al apoyo de herramientas gráficas. Frecuentemente analista y diseñador son la misma persona, sin embargo es neces nec esa a rio que q ue se se rea reallic e un cambio c ambio de d e enf e nfoq oque ue mental mental al pas pa sa r de una una etapa a 1 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

la otra otra . A l a b o r d a r la e t a p a d e d ise ño , la la p e r so so n a d e b e q u iitt a rse e l so so m b re r o d e . a na lista y c o lo c a rse el so so m b re ro d e d ise ñ a d o r Una vez que q ue se han ha n es e stab le c ido los re q uisit uisito o s d e l so so ftwar ftwa re (en el aná a nállisis isis), ), el dise dise ño d el softwa softwarre es la la p rimera mera de tres tres ac tivi tivida da des de s técni téc nicc a s: d ise ño , c o d ific fic a c ión, y p r u e b a . C a da a c tivi tivida da d tra tra nsfor nsforma ma la inform nforma a c ión de d e forma forma que finalm finalmente ente se se obti ob tiene ene un softwar software e pa p a ra c omputador omputad ora a válido válido.. La s fases fases d el diseño diseño,, cod c odif ifiic a c ión y prueba a bsorbe bsorben n el 75 75% o más má s d el cos c osto to de d e la ingeni nge nierí ería a d el softwa softwarre (excluyend (excluyendo o el mantenimiento). mantenimiento). Es Es a quí donde do nde se toman toma n fec tará á n finalm finalmente ente al a l éxi éxito de la implementac mplementac ión del d el prog progrra ma decisiones que a fectar y, con co n igua iguall import importa a nci nc ia , a la fac ilida d de mantenimi mantenimiento ento que q ue tendr tend rá el softwar software. e. Estas dec de c isiones one s se lleva llevan n a c a bo d ura ura nte nte el e l d iseño del de l softwar oftwa re, hac ha c iendo end o que q ue sea sea un pas pa so f u n d a m e n t a l de fa se de d e des d esa a rrollo. ollo. la fas La importa mporta nci nc ia del de l dis diseño del de l softwar software e se p uede sentar con co n una únic únic a pal pa la bra: El diseño diseño es el proces proc eso o en el e l que se a sienta la c a lid a d d el des de sa rrollo ollo d el c a l i d a d . El softwar oftwa re. El El d iseño p roduc od uce e las la s repr ep resenta esentacc iones one s d el softwa softwarre de d e las la s que puede pue de evaluarse su calidad. El diseño diseño sirve c omo ba se pa ra toda tod a s la s pos po steri teriores etapa eta pa s d el des d esa a rrollo ollo y de la fas fa se d e mantenimi ma ntenimiento ento.. Sin Sin diseño diseño nos no s a rriesga iesga mos a c o nstr nstrui uirr un sis sistema tema inesta inestab b le, un sistema que falle cuando se realicen pequeños cambios, un sistema que pueda se difícil de probar, un sistema cuya calidad no pueda ser evaluada hasta más adel ad elante ante en el proc proc eso eso d e ingeni ingenier eríía de softwa oftwarre, cuando c uando quede qued e poc p oc o tiempo tiempo y se haya ha ya ga g a stado tad o ya mucho di d inero. nero. 1.3

O b je tivo s De l Dise Dise ñ o Estruc tura d o

"El d ise ñ o e struc truc tura d o , tie tie nd e a tra tra nsform nsform a r e l d e sa rro llo d e so so ftw a re d e u na p rác tic tic a a rte sa na l a un a d isc ip lina d e ing e nierí a ". Per Pe rmitir mitirá á lo lo g ra r: Eficiencia Mantenibilidad Modificabilidad Flexibilidad Generalidad Utilidad

Es el proces proc eso o q ue "Dis Dise eñ o " sig nific nific a p la ne a r la fo rm a y m é to d o d e un a so luc ión . Es

d e termin termina a las c a ra c terís terístic tic a s p rincipa incip a le s d e l sis sistema tema fina final,l, esta esta b le c e lo s límit ímites es en 2 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

la otra otra . A l a b o r d a r la e t a p a d e d ise ño , la la p e r so so n a d e b e q u iitt a rse e l so so m b re r o d e . a na lista y c o lo c a rse el so so m b re ro d e d ise ñ a d o r Una vez que q ue se han ha n es e stab le c ido los re q uisit uisito o s d e l so so ftwar ftwa re (en el aná a nállisis isis), ), el dise dise ño d el softwa softwarre es la la p rimera mera de tres tres ac tivi tivida da des de s técni téc nicc a s: d ise ño , c o d ific fic a c ión, y p r u e b a . C a da a c tivi tivida da d tra tra nsfor nsforma ma la inform nforma a c ión de d e forma forma que finalm finalmente ente se se obti ob tiene ene un softwar software e pa p a ra c omputador omputad ora a válido válido.. La s fases fases d el diseño diseño,, cod c odif ifiic a c ión y prueba a bsorbe bsorben n el 75 75% o más má s d el cos c osto to de d e la ingeni nge nierí ería a d el softwa softwarre (excluyend (excluyendo o el mantenimiento). mantenimiento). Es Es a quí donde do nde se toman toma n fec tará á n finalm finalmente ente al a l éxi éxito de la implementac mplementac ión del d el prog progrra ma decisiones que a fectar y, con co n igua iguall import importa a nci nc ia , a la fac ilida d de mantenimi mantenimiento ento que q ue tendr tend rá el softwar software. e. Estas dec de c isiones one s se lleva llevan n a c a bo d ura ura nte nte el e l d iseño del de l softwar oftwa re, hac ha c iendo end o que q ue sea sea un pas pa so f u n d a m e n t a l de fa se de d e des d esa a rrollo. ollo. la fas La importa mporta nci nc ia del de l dis diseño del de l softwar software e se p uede sentar con co n una únic únic a pal pa la bra: El diseño diseño es el proces proc eso o en el e l que se a sienta la c a lid a d d el des de sa rrollo ollo d el c a l i d a d . El softwar oftwa re. El El d iseño p roduc od uce e las la s repr ep resenta esentacc iones one s d el softwa softwarre de d e las la s que puede pue de evaluarse su calidad. El diseño diseño sirve c omo ba se pa ra toda tod a s la s pos po steri teriores etapa eta pa s d el des d esa a rrollo ollo y de la fas fa se d e mantenimi ma ntenimiento ento.. Sin Sin diseño diseño nos no s a rriesga iesga mos a c o nstr nstrui uirr un sis sistema tema inesta inestab b le, un sistema que falle cuando se realicen pequeños cambios, un sistema que pueda se difícil de probar, un sistema cuya calidad no pueda ser evaluada hasta más adel ad elante ante en el proc proc eso eso d e ingeni ingenier eríía de softwa oftwarre, cuando c uando quede qued e poc p oc o tiempo tiempo y se haya ha ya ga g a stado tad o ya mucho di d inero. nero. 1.3

O b je tivo s De l Dise Dise ñ o Estruc tura d o

"El d ise ñ o e struc truc tura d o , tie tie nd e a tra tra nsform nsform a r e l d e sa rro llo d e so so ftw a re d e u na p rác tic tic a a rte sa na l a un a d isc ip lina d e ing e nierí a ". Per Pe rmitir mitirá á lo lo g ra r: Eficiencia Mantenibilidad Modificabilidad Flexibilidad Generalidad Utilidad

Es el proces proc eso o q ue "Dis Dise eñ o " sig nific nific a p la ne a r la fo rm a y m é to d o d e un a so luc ión . Es

d e termin termina a las c a ra c terís terístic tic a s p rincipa incip a le s d e l sis sistema tema fina final,l, esta esta b le c e lo s límit ímites es en 2 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

per pe rformanc formance e y ca lida d que q ue la la mejor implementac mplementac ión puede pue de a lc a nza nza r, y pued e determinar a que costos se alcanzará. El diseño diseño se c a ra c teriz teriza a usua usuallmente por p or un gra gra n número número d e dec de c isi isiones one s técni téc nicc a s individuales. En orden de transformar el desarrollo de software en una disciplina de ingenier ingenie ría , se se d e b e sistema istemati tizza r tales dec de c isione isioness, hac ha c e rlas más má s explíc explíc ita ita s y té té c nica s, y menos implícitas y artesanales. Dis Dise ñ o e struc truc tura tura d o y c a lid lid a d d el so so ftw ftw a re

Un conc c onc epto ep to import importa a nte nte a c onsi onsider de ra r es el de c a l i d a d . Dentr Dentro de este este c onc epto, ep to, se deb d eben en tomar enc uenta uenta : 

Efic fic ienci enc ia : Se refi refier ere e al a l incr nc remento de la veloc veloc ida d de d e ej e jec uci uc ión y d ismi isminuc nución ión de d e lo s requeri eq uerimi miento entoss d e memor memo ria c e ntra ntra l. Es Estos rec rec urs urso s no incl nc luyen sola solamente mente pr p roc esa esa d or y memo memorria , ta ta mbién inc inc luyen a lmac enami ena miento ento sec sec undar unda rio, tiempo tiempo de per pe riféri féric os de entra entra da sa lida , tiemp tiempo o de d e línea línea s de telep teleprroc eso, titiempo emp o de d e pers p erso o nal na l, y más má s.



C onfiabi onfiab ilida d. Es impor mpo rtante notar no tar que si si bien bien la c onfiabil onfiab iliid a d del de l softwar oftwa re puede ser vista como un problema de depuración de errores en los p rogr og ra mas, mas, es tambi tamb ién un probl prob lema de diseño diseño.. La La c onfiabi onfiab ilid a d se se ex e xpresa presa en como MTBF (Mean Time Between Fairules: tiempo medio entre fallas).



Ma ntenibi ntenibillida d. Se defi de fine ne como: co mo:

M an ante nib ilid a d d el el siste ma =

____M TBF___ M TBF + M TTR

donde: MTBF: tiempo medio entre fallas (mean time between fairules) M TTR: tiempo tiempo medi med io d e repa ep a ra c ión (mea (me a n time time to repa ep a ir) ir) Diremo Diremoss q ue un si sistema es mantenible mante nible si si per pe rmite mite la d e tec c ión, aná a nállisis isis,, red redis iseño eño,, y corrección de errores fácilmente. 1.3

Identificación de Procesadores.

Es el primer primer p a so en el e l des de sa rrollo ollo d el Mode Mo dello d e Implementac Implementa c ión. Ti Tiene c omo propós prop ósiito as a signa r c a d a uno de d e los proc esos esos que forma forman n pa rte del de l sistema istema a un 3 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

PROCESADOR, que se encargará de desarrollar el proceso. Esta etapa se desarrolla a nivel del DFD: PROC ESADOR #1

PROC ESADOR #2 PROC ESADOR #3 No puede quedar ningún proceso sin asignar. 1.4

Diagramas de Estructura

Tiene como objetivo básico el tratar d enfoc ar la programac ión a través de MÓ DULOS, de manera que c ada uno de ellos pueda ser programado de manera independiente. Características de los Diagramas de Estructura: 

Es gráfico y, por tanto, conc iso, fácil de leer, senc illo de preparar. 4

Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS

Ingeniería de Sistemas II   

IND-225

Capítulo 1

El diagrama de estructura muestra la descomposición de un sistema en módulos. Presenta un formato TOP-DOWN: pasar de la forma globa l a la detallada. Presenta una estructura jerárquica. Los módulos se c onsideran c ajas negras de las que se c onoce: - Entrada s que rec iben. - Salidas que generan. - La función que lleva a cabo. - Un diagrama de estructura tiene forma de á rbol y refleja: i. J erarquía de control qué módulos pueden invocar a otros módulos. ii. Parámetros que se pasan en los llamadas.

En cambio no muestra: - Aspec tos de proc esamiento del software: sec uencias, alternativas o bucles. - Ni da tos internos de los módulos. Debe ser pa rte de la documentación del programa y del sistema, así como debe servir de ayuda para el mantenimiento y mejoras del sistema. DEFINICIÓN DE MÓDULO

Un módulo se define como un conjunto de sentencias de programa c on c uatro atributos bá sicos: -

Entrada s/ Salida s: Datos que rec ibe cuando lo invoc an y datos que devuelve al módulo que lo llamó. Función: Qué hace con las entradas para producir las salidas. Mecánica: La lógica mediante la c ual lleva a cabo su función. Datos internos: Zona de da tos a los que únicamente puede referirse él.

Además posee otros atributos adicionales cómo: - Un nombre, por el cual puede ser referenciado c omo un todo. Puede invocar o ser invocado por otros módulos. Un módulo debe manejarse como una “caja negra”, funcionalmente independiente, que puede entenderse en forma separada . El c o n c e p to d e C a j a N e g r a : Una

caja negra es un sistema (o un componente) con entradas conocidas, salidas conocidas, y generalmente transformaciones conocida s, pero del cual no se conoc e el contenido en su interior. En la vida diaria existe innumerable cantidad de ejemplos de uso cotidiano: una radio, un televisor, 5 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

un automóvil, son c ajas negras que usamos a diario sin conocer (en general) como funciona en su interior. Solo conocemos como controlarlos (entradas) y las respuestas que podemos obtener de los artefactos (salida s). El concepto de caja negra utiliza el principio de a b s t r a c c i ó n . Este concepto es de suma utilidad e importancia en la ingeniería en general, y por ende en el desarrollo de software. 1.5 Co m p a ra c ión en tre la s estruc tura s a d m inistra tiva s y e l d iseñ o e struc tura d o

Uno de los aspec tos más interesantes del diseño de programas es la relac ión que puede establec erse c on las estructuras de orga nización humanas, particularmente la jerarquía de administración encontrada en la mayoría de las grandes organizaciones. Observemos por ejemplo el siguiente diagrama de organización de una empresa

A simple vista podemos apreciar que el presidente de la empresa tiene demasiados subordinad os, y consec uentemente su traba jo involucrará el manejo de demasiados da tos y la toma de demasiada s decisiones, demasiada complejidad, que lo llevará a cometer posibles errores. Podemos establec er una analogía con la estructura de programas y es razonable pensar que un módulo que tenga demasiados módulos subordinados a quienes controlar, sea sumamente c omplejo, y susceptible a fallas. Vea mos otro ejemplo

6 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

Podemos aprec iar a simple vista que la tarea de los jefes A, X, Y, es relativamente trivial y podría se c omprimida en una sola jefatura. Establec iendo un comparación con la estructura de programas, si tenemos un módulo c uya única función es llamar a otro, y este a su vez a otro, el cual llama a uno que finalmente rea lizará la tarea, los módulos intermedios podrán comprimirse un único módulo de control. Podemos decir que en una organización perfec ta, los administradores no realizan ninguna tarea operativa. Su labor consiste en coordinar informac ión entre los subordinados y tomar decisiones. Los niveles inferiores son los que realizan el traba jo operativo. Análoga mente, podemos argumentar que los módulos de nivel alto en un programa o sistema solamente c oordinan y controlan la ejec ución de los módulos de menor nivel, quienes son los que realizan los cómputos y procesos que el sistema requiere. Finalmente observaremos que los administradores suministran a sus subordinados únicamente la información que estrictamente necesitan. Análogamente los módulos inferiores solo deben tener acceso a la información que necesitan, y no a otras. El establecimiento de un p aralelo entre las estructuras organizativas humanas y los programas de c omputadora nos será muy útil en el estudio del diseño estructurado. 1 .6

M a n e j o d e la c o m p l e j id a d

En principio diremos que escribir un programa "grande" generalmente lleva más tiempo que escribir un "pequeño". Esto es valedero si medimos "grande" y "pequeño" en unidades apropiadas. Claramente, el número de instrucciones de un programa no es una medida de complejidad ya que existe instrucciones más complejas que otras, y algoritmos más complejos que otros. En rea lida d lo que diremos es que e s m ás d ifíc il reso lve r un p ro b lem a d ifíc il! , e intentaremos realizar un análisis sobre c omo disminuir la complejida d de un determinado problema. Si asumimos que hemos podemos medir por algún método la complejidad de un problema P (no importa a quí que método), diremos que la c omplejida d del mismo será M(P), y que el costo de realizar un programa que resuelva el problema P será C(P). Los enunciados previos responderá a la siguiente regla: da dos dos problemas P y Q observaremos lo siguiente Si M (P) > M(Q ) en to nc es C (P) > C(Q )

es dec ir el costo de resolver un determinado problema es direc tamente proporcional al tamaño del mismo. 7 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

Intentaremos tomar dos problemas separados y en lugar de escribir dos programas, crea r un programa combinado. Si juntamos los dos problemas, obtendremos uno mayor que si tomamos los dos por separado. La razón fundamental pa ra no c ombinar los problemas, es que los humanos tenemos inconvenientes pa ra tratar adecuadamente grandes complejida des, y en la medida que esta se incrementa somos susceptibles a cometer un mayor número de errores. En virtud de esto podemos afirmar que y consec uentemente

M (P+Q) > M (P) + M(Q ) C (P+Q ) > C(P) + C(Q )

Siempre será preferible c rea r dos piezas pequeñas que una sola más grande, si ambas solucionan el mismo problema. Este fenómeno no es solo válida pa ra el campo de la computac ión. Es verda dero en c ualquier campo de la solución de problemas (matemática, física, etc.). 1.7 Nota c ión d e los Dia g ra m a s d e Estruc tura

a. Módulo: Representa un grupo de instrucciones que rea liza una única función determinada. Un módulo asocia a uno ó más de los procesos definidos en el Diseño Lógico. Cada módulo tiene c ierta informac ión de entrada y genera cierta información de salida. El módulo debe tener un nombre dentro el rectángulo que lo representa. 8 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


Módulo

IND-225

Capítulo 1

CALCULAR SALDOS

Nombre del Módulo b.

Flecha de Invocación. Se presenta c omo una flec ha que va desde el módulo que llama hasta el que es invocado. Como describe una relación jerárquica , su direc ción es siempre hacia abajo:

Módulo Jefe

(Invocador)

Módulo Subordinado

(Invocado)

Un módulo puede invocar a varios otros que dependen de él:

A su vez, un módulo puede ser invocado por varios módulos



c.

IND-225

Capítulo 1

Flecha (Cupla)

Representa a pa rámetros de información que pasan a través de los módulos. El sentido de la flec ha indica la direc ción del flujo.

d.

Condicional.- Muestra la existencia de un proceso de selección.

1.8. Formato General de un Diagrama de Estructura

En resumen, un Diagrama de Estructura ilustra la partición del sistema en módulos funcionales independientes, cada uno de los cuales se programará ba jo ese concepto 10 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Ejemplos

1.9 A c o p la m ie n t o y C o h e sió n .

El Acoplamiento es la medida de la fuerza de relac ión entre los módulos La cohesión es la fuerza de la relac ión entre los elementos de un módulo 11 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS

Capítulo 1


IND-225

1.10 Estrategias de Transformación


Capítulo 1


IND-225

Capítulo 1

Proceso de Transformación Se deben identificar: Ramas Aferentes: Procesos que leen y validan los datos a la entrada del sistema. Para identificarlas se buscan los puntos de entrada de datos a la transacción (normalmente Entidades Externas que proporcionan datos al sistema) y se recorre la rama del DFD hasta llegar a un flujo de da tos completamente valida do. Ramas Eferentes: Procesos que dan el formato adecuado a los datos para ser emitidos (visualizados, impresos, guardados, ...) al exterior. Para identificarlas se buscan los puntos de salida de datos de la transacción (normalmente Entidades Externas que reciben datos del sistema) y se recorre la rama del DFD hasta llegar a un flujo de datos lógico, antes de ser formateado. Transformación Central: Los procesos que no son aferentes, ni eferentes pertenecen a la transformación central (procesos de cálculo, procesamiento de datos, actualización de datos, ...).



IND-225


Capítulo 1


IND-225

Capítulo 1

Ejemplos de transformación de Diagrama de Flujo de Datos a Diagrama de Estructura

Diagrama Intermedio (Alquilar un jefe)

Antes de desarrollar el Diagrama de Estructura podemos hacer un diagrama intermedio, entre el DFD y el DE, que sirva como aproximación. Existen dos maneras de hacerlo: alquilar un jefe o promover un proceso a jefe. En este caso hemos escogido la primera. El proc eso ‘alquilado’ es un proc eso que no se c orresponde con ningún otro del DFD y que se c onvertirá en el módulo principal de la transacción. Del proc eso jefe alquilado se ‘c uelgan’ las ramas aferentes, eferentes y los proc esos de la transformación central, como sigue:



IND-225

Resultado Final:


Capítulo 1


IND-225

Ejemplo 2

Primer nivel de Factorización

Final


Capítulo 1


IND-225

Capítulo 1

Lectura Complementaria: Análisis de Transformaciones El principal enfoque del aná lisis de transformac iones es convertir un DFD, resultado del análisis estructurado, en un diagrama de estructura. La principal ventaja de este enfoque es que, el diagrama de estructura resultante tiene una forma tal que permite un fácil desarrollo y mantenimiento más barato que la mayoría de los diagramas de estructura que podamos construir ad-hoc. Como será visto mas adelante, cuando los criterios de calidad son aplicados en los diagramas de estructura, el resultado es un DE donde, la mayoría de los módulos son independientes de los dispositivos de entrada y salida, esto es: describe el diseño de un sistema b a l a n c e a d o . La figura 1 describe los pasos realizados durante el análisis de transformac iones.

nálisis Estructurado

DFDs resultantes del Proceso de Analisis

Análisis de la Especificación del Problema

DFDs sin detalles de más y sin ocultar transformaciones de datos

Identificar el Centro de Transformación Marcar el Centro de Transf ormación; Caminos Aferentes y Eferentes

Producción de un Primer DE (First-Cut)

Especificación del Analisis

Funcionalmente Equivalentes

Mejoramiento del DE

Centro de Transformación=Raiz Caminos Aferentes=Izquierda Caminos Eferentes=Derecha Cohesión, Acoplamiento, etc

Diseño de buena Cal idad

Asegurar la Funcionalidad del Diseño

Implementación, Testeo, etc.

Diseño Estructurado d e buena Calidad(mantenimiento; eficiencia; claridad; etc)

Fig.1: Pasos del Análisis de Transformaciones



IND-225

Capítulo 1

Análisis de la Especificación del Problema

Si un diseño estructurado está siendo desarrollado, luego del análisis estructurado, entonces habrá un conjunto de DFDs que describen el problema, para los cuales se debe diseñar una solución. Si el análisis estructurado no precede al diseño, entonc es se pueden reconocer dos situaciones muy diferentes: Un p ro b le m a m u y sim p le : Si el problema p uede ser representado en la m e m o ria d e u n a p e rso n a [DeMarco 86], es muy simple y no precisa mayor esfuerzo que la especificación. En ese caso las herramientas del Análisis no son necesrias y el DE puede ser desarrollado ad-hoc. Sin embargo, el análisis estructurado ofrece una colección de técnicas y criterios que permiten analizar y especificar un problema cuando es muy complejo para ser comprendido y especificado con una simple declaración narrativa. Según DeMarco [DeMarco 86], un modelo es una m a q u e t a de una realidad donde algunas características son estudiadas y, se construyen diferentes modelos de la misma realidad (cada uno de ellos representando diferentes características) para estudiar diferentes pa rtes del problema por separado. Un p ro b le m a c o m p le jo : La mayoría de las veces, el problema es mayor que la capacidad de n u e s t r a m e m o r i a p r i n c i p a l y diversos modelos deberán ser desarrollados, en el proceso de análisis estructurado, para conseguir una buena comprensión y especificación. En ese caso, será necesario construir algunos DFDs a partir de la narrativa del problema (declaraciones surgidas de las entrevistas con los diversos usuarios involucrados). •

•

Para obtener un buen resultado con el análisis de transformaciones, los DFDs no deben llegar a un nivel de detalle en el que se tenga demasiada cantidad de procesos. Si un DFD es muy detallado puede ser necesario que se necesite hacer abstracción de algunos procesos (para reducir la cantidad). El DFD tampoco puede ser demasiado abstracto y ocultar algunas características que el análisis de transformaciones debe estudiar. Además, puede ser necesario descender un nivel (describiendo los flujos de datos y los procesos interiores de algunos procesos mostrados en el DFD) para que, el DFD presente todas las transformaciones de da tos producidas pa ra llevar los flujos de entrada en direc ción de generar los flujos de salida .



IND-225

Capítulo 1

Identificar el Centro de Transformación

El centro de transformación es la parte del DFD que contiene la funcionalidad principal del sistema y es independiente de la implementación particular de las entradas y salidas. Por ejemplo, considere el DFD de la figura 2.

Fig. 2: Generación de Informe de Movimientos de una Cuenta Corriente

El diseñador podría considerar al proceso Reunir Movimientos del Cliente como la transformación principal del DFD, si un proceso tiene mas flujos de entrada que de salida, la pregunta que deberá ser respondida es: ¿Qué proceso hace el trabajo principal de la funcionalidad que representa el DFD?. Claramente, el principal trabajo no es hecho por los procesos: Leer Movimiento del Cliente, Leer Información del Cliente, Calcular Total o Imprimir Línea. Tampoco es hecho por alguno de los procesos: Formatear Encabezado, Formatear Línea del Reporte o Formatear Total por separado. La función que el DFD modela, con certeza, no es Reunir Movimientos del Cliente, podría corresponderse con un proceso de abstracción mayor, tal vez llamado Generar Reporte de Movimientos, que incluya los procesos: Formatear Encabezado, Formatear Línea de Reporte y Formatear Total.



IND-225

Capítulo 1

La elección del centro de transformaciones no es una actividad simple, generalmente requiere una interpretación detallada de la funcionalidad descripta por el DFD, y, en muchos casos, podría incluir mas de un proceso. Para eso existe una estrategia basada en la estructura del DFD, independiente de la interpretación particular de los procesos, que permite obtener una buena aproximación de la porción del DFD que debe incluir el centro de transformaciones. No es un algoritmo, ya que no establece una secuencia de etapas y tampoco garantiza la obtención acertada del centro de transformaciones. Una vez identificada la porción del DFD que incluye el centro de transformaciones, se debe interpretar detalladamente la función de los procesos incluidos para determinar si alguno de ellos representa la t ra n sf o rm a c ió n p rin c ip a l del DFD o si una actividad de abstracción mayor deberá ser escogida. Estrategia para Determinar el Centro de Transformación La estrategia intenta identificar la transformación central siguiendo los caminos de datos aferentes y eferentes. Este proceso puede ser desarrollado a través de los tres pasos siguientes: 1. Marcar cada camino aferente partiendo del lado externo del DFD (los flujos provenientes de depósitos de datos, agentes externos o porciones del DFD no incluidas en el Análisis1), y terminar en cada flujo eferente alcanzado (los flujos dirigidos pa ra depósitos de datos, agentes externos o porciones de DFD no incluidas en el Análisis). 2. Diseñar una curva que una los puntos de intersección de caminos diferentes. Los procesos incluidos en el interior de la curva son candidatos iniciales para el centro de transformación. 3. Finalmente, analizar los límites del centro. Generalmente, en el límite, se puede reconocer la finalización del refinamiento de las entradas (para los caminos de entrada o aferentes) y el comienzo del refinamiento de las salidas (para los caminos de salida o eferentes). Si no es así, modifique el contorno, yendo hacia el interior o exterior de forma tal que, el interior, incluya solamente datos en estado lógico (independiente de las fuentes y destinos y totalmente refinados).

1 El DFD analizado es solamente una porción correspondiente a una transformación identificable. Como separar un DFD proveniente del Analisis en porciones correspondientes a transformaciones es una actividad muy intuitiva, quedará mas claro cuando sea presentado el Analisis de Transaccioness.



IND-225

Capítulo 1

En el ejemplo de la figura 3 se ilustra la actividad descripta arriba. Primero se marcan todos los caminos de datos a través del DFD comenzando por los flujos de comienzo de los caminos aferentes y finalizando en los flujos de finalización de los caminos eferentes. En el ejemplo, los flujos de datos C a m p o y Re g istro M a e stro son flujos de comienzo de caminos aferentes y, Nue vo Re g istro M a e stro y Lín e a d e Informe son flujos de finalización de caminos eferentes. En el segundo paso se hace una curva uniendo los puntos de intersección de caminos. La curva reúne los procesos candidatos para centros de transformación, en el ejemplo, reúne los procesos: Aparear Transacción con Registro Maestro, Actualizar Registro Maestro y Formatear Nuevo Registro Maestro.

Editar Campo

Fin de Camino Eferente

Reunir Transacciones

Campo Invalido Campo Editado

Transacción

Campo Editado

Campo

Transacción Inválida

Efectuar Transacción Validación Válida Cruzada Registro aestro Válido

Registro aestro Inválido Registro aestro

nicio de Camino ferente

Validar Registro Maestr

Transacción sin Registro Maestro

Aparear Transacción Registro con Registro aestro Maestro Juntado Registro aestro sin Transacción

Nuevo Registro aestro

rchivo

Linea de Informe

Formatear Linea de Informe

Transacción Aplicada

Actualizar Registro Maestro

Formatear Nuevo Registro Maestro

Registro aestro Actualizado

Fin de Camino Eferente

Fig. 3: Ejemplo de Análisis de Transformac iones La s lí ne a s p unte a d a s m a rca n los d iferent es ca m ino s d e d a to s a través d el DFD. Hay d o s Ca m inos Aferente s q ue c om ienzan e n los flujos C a m p o y Reg istro Ma estro y do s Ca m ino s Efe rent e s q ue fina liza n e n los flujo s Nue vo Reg istro M ae stro y Líne a d e Info rm e . Lo s p roc e so s en el interior de la c urva son c a nd id a tos a integ ra r el ce ntro d e transforma c ione s, ellos son Aparear Transacción con Registro Maestro y Actualizar Registro Maestro.

La curva también indica la finalización de los caminos aferentes y el comienzo de los caminos eferentes, verificar eso es el objetivo del tercer paso. La primera tarea es verificar que, en el interior de la curva, no haya transformaciones de refinamiento de los flujos de entrada o salida. En el ejemplo, el flujo de datos Tra nsa c c ión V álid a es la versión mas refinada de los datos que comenzaron con el flujo C a m p o y, el proceso Aparear Transacción con Registro Maestro procesan datos de los dos caminos aferentes para crear una salida muy diferente (el Re g ist ro M a e st ro A p a re a d o ). 22 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

Con los caminos eferentes no ocurre la misma cosa. El proceso Formatear Nuevo Registro Maestro, aunque sea integrante del selecto grupo de procesos candidatos para centro de transformación, ejecuta una tarea de refinamiento de datos de salida. La tarea de transformación real de datos fue realizada por los procesos Aparear Transacción con Registro Maestro y Actualizar Registro Maestro. El módulo Formatear Nuevo Registro Maestro simplemente refina el Registro M a e st ro A c t u a liza d o o el Re g istro M a e stro sin Tra nsa c c ión para generar el N u e v o Re g istro M a e stro . Así el proceso Formatear Nuevo Registro Maestro no c ompone el centro de transformación e incrementa el camino eferente. Como podemos ver, existe subjetividad en la elección de la transformación central, raramente surgen grandes acuerdos relativos a esa elección. El diseñador se podrá preguntar sobre un proceso aquí o allá, sin embargo, eso parece hacer poca diferencia en el diseño final. Por eso, si hubiera dudas sobre un proceso, ése no debe pertenecer al centro de transformación. En sistemas de información el centro de transformación está compuesto por una pequeña porción del DFD y no incluye procesos de edición, formateo o verificación y correc ción de errores. Producir un Primer Diagrama de Estructura (First-Cut)

Una vez reconocido el centro de transformación y los caminos aferentes y eferentes, una primera versión del DE puede ser desarrollada aplicando los cuatro pasos siguientes: 1. Convertir el DFD en una jerarquía de módulos: Tirar el DFD desde los procesos marcados como participantes del centro de transformaciones y dejar caer los otros procesos, por acción de la graveda d. b A

a

B

c

e

d

k

f g

C

i j

q

G

n

X

F

c b

f

d

B

E

m

C

e

E

l

D

h

o

m

F

g

H

l

D

h

p

i

k j

G

n q

X

A

o H

p

a

2. Substituir los depósitos de datos por módulos de lectura o grabación (dependiendo de la orientación del flujo), los agentes externos por módulos de captación o presentación de datos y adicionar módulos debajo de los flujos sin destinatario u origen. 23 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

Se deben asociar nombres adecuados a los módulos adicionales, dependiendo de la actividad de lectura (captación) o escritura (presentación) que d eben ejecutar.

g

D

h C

e

F

B

c a ?

i

d

?

A

k

?

?

l

n

G

q

j Leer

E

m

Gra

b ?

3. Convertir los flujos de datos en invocaciones (apuntando al módulo invocado) y los datos transportados por los flujos en cuplas. Cada uno de los módulos deberá ser D l analizado para determinar y adicionar E g los datos de entrada necesarios. Por m o k h n ejemplo, el módulo Leer X debe recibir Em G F C H e como entrada la clave de acceso q p i Leer para la lec tura del registro. Gra B Et Er Or d

c a

A

b 4. Indicar un único módulo como raíz del DE, sea por selección de uno de los Ic Ec módulos participantes del centro de transformaciones o, por la incorporación de un módulo nuevo.

Mejorar el Diagrama de Estructura Obtenido

El diagrama de estructura resultante del paso anterior, con certeza, puede ser mejorado. Eso simplemente es una primera aproximación y se debe beneficiar con la aplicación de los criterios de calidad (presentados mas adelante), especialmente Descomposición, C ohesión y Ac oplamiento. Por lo menos, la siguiente revisión debería ser hec ha en el diagrama de estructura: Reorganizar, y descomponer si fuese necesario, los módulos aferentes y eferentes. Descomponer la transformación central, si fuese necesario, usando el DFD como base. Los niveles del DFD son útiles en este c aso. Adicionar los módulos de manipulac ión de errores. Adicionar detalles de inicialización y terminación (si son requeridos). •

•

•

•


o H

p

?

Ingeniería de Sistemas II •

•

•

IND-225

Capítulo 1

Tener c erteza que todos los módulos tengan nombres correspondientes a su representación en la jerarquía. Adicionar todas las cuplas necesarias (de datos y de control). Chequear todos los criterios de calidad y mejorar el diseño de acuerdo con esos criterios.

De esta manera, aplicando los cuatro pasos en el DFD de la figura 3, el DE resultante es el siguiente: Actualizar Archivo Maestro

Transacción Válida

FTV

# Cuenta

Obtener Transacción Válida Transacción

Obtener Registro Maestro

RMV

Leer Registro Maestro Campo Editado FCE

Obtener Campo Editado Campo FC

Obtener Campo

Juntar Registro Maestro

Generar Registro Maestro

Nuevo Reg aestro

Transacción plicada

Grabar Nuevo Registro Maestro

Fin de Campo Fin de Campo Editado Fin de Transacción

TV RMV TV

Transacción plicada

TV

Actualizar Registro Maestro

Nuevo Reg aestro Fmt

Formatear Nuevo Registro Maestro C CE T

Informar Transacción Errónea

RMV Reg Maestro ctualizado

Reg Maestro sinTrans

Obtener Transacció

TV

Reg Maestro

# Cuenta

FT

Campo Editado FCE

Reg aestro Valido

Transacción sin Registro Maestro

Imprimir Transacción Aplicada

Línea de Error

Línea

Formatear Línea de Informe

Imprimir Línea de Informe

Fin de Transacción Válida Registro Maestro Válido Transacción Válida

Fig. 4: Resultado de Aplicar Análisis de Transformaciones en el DFD de la figura 3

Garantizar la Funcionalidad del Diseño

El paso final es el paso más importante: tener certeza que el DE es funcionalmente equivalente al DFD de origen. El propósito del análisis de transformaciones, es obtener rápidamente un DE que implemente correctamente la especificación del problema y cumpla los criterios de calidad.



IND-225

Capítulo 1

Análisis de Transacción

El análisis de transformaciones es la principal estrategia para convertir un DFD (de transformación de datos) en un DE. Sin emba rgo, una pregunta está sin responder: ¿que criterio puede ser aplicable para particionar un DFD mayor en un conjunto de DFDs de transformac ión? Una técnica suplementaria, llamada análisis de transacción es extremadamente valiosa para dividir un DFD de alto grado de complejidad en DFDs de menor complejidad. Esta técnica divide en distintos DFDs, uno para cada transformación que el sistema procesa. Esos DFDs menores serán suficientemente simples como para permitir su conversión por medio del análisis de transformaciones en Diagramas de Estructura (DE). El análisis de transacción también puede ser usado para combinar los diagramas de estructura individuales (de transacciones separada s) en un diagrama de estructura mayor y más flexible. Una transacción, en general, es un estímulo para un sistema que posee un conjunto de actividades a ser realizadas internamente. Ejemplos de transacciones son: incluir un nuevo cliente, generar una factura por venta de mercaderías, actualizar el stock de un producto, disminuir la temperatura de un reactor nuclear, actualizar archivo maestro o generar el reporte de movimientos de cuenta corriente. Aplicar Transacción Tipo de Transacción

Obtener Tipo de Transacción

Transacción Tipo A

Transacción Tipo B

Transacción Tipo C

Fig.5: La Estructura Típica de los DE Generados por Análisis de Transacción



IND-225

Capítulo 1

Los DE que resultan del análisis de transacción tienen la forma descripta por la figura 5. De manera similar al análisis de transformaciones, la actividad principal para derivar un DE a partir del DFD, en el análisis de transacción, es identificar el centro de transacción. Frecuentemente, es muy fácil reconocer transacciones, centros de transacciones y procesos de transacción a través del formato del diagrama. Siempre que un flujo de datos entra en un proceso que determina su tipo y lo envía a un proceso relacionado con el tipo, se puede tener certeza que fue loc alizado un centro de transacciones. El DFD para un centro de transacción de operaciones en cuenta corriente está representado en la figura 7. Registro del Cliente Saldo

Generar Informe de Movimiento # de Cuenta Operación Deseada

# de Cuenta

# de Cuenta

Iniciar Operaçión Deseada

Clientes

ovimiento

Cuenta Consultar Saldo de Cuenta

ovimiento Saldo ovimiento

# de Cuenta

# de Cuenta

Registrar Depósito ovimiento

Registrar Extracciones Valor

Fig. 7: Ejemplo de DFD de Transac ciones

El proceso Iniciar Operación Deseada contiene el centro de transacción el cual activa el proceso apropiado dependiendo de la O p e r a c i ó n D e s e a d a . Sin embargo, la manifestación del centro de transacción en un DFD es frecuentemente más sutil.



IND-225

Parámetro de Direccionamiento

Capítulo 1

Direccionar el Barco

Parámetro de Curso Terminal de Control

Ángulo de Direccionamiento

Timón

Ajustar Curso

Parámetro de Seguimiento

Curso Corriente Localizar

Coordenadas dcl objetivo

Objetivo

Parámetro de Disparo Disparar Mísil

Giroscópo

Detalle del Disparo

Misil

Fig.8: Ejemplo de DFD de Transac ciones sin Mostrar el Centro

En el DFD de la figura 8, las diferentes transacciones son identificadas claramente pero, ¿dónde está el centro de transacción?. Una posibilidad es adicionar un proceso que recibe todos los flujos de entrada y determine la transacción adecuada pero, esa situación artificial complicaría innecesariamente el diseño y tornaría el sistema inflexible (ya que un único proceso debería preocuparse de todos los tipos de transacciones del sistema). La solución mas adecuada es incorporar un proceso de control que solamente reciba la información de control necesaria para determinar la transacción que tiene que ser ejecutada. En la realidad, un centro de transacción tiene la mayoría de las veces la funcionalidad de un proceso de control. Así, el DFD de la figura ¡Error! Marcador no definido., con el centro de transacción incorporado, es mostrado en la figura 9. Parámetro de Direcionamiento

Direccionar el Barco

Parámetro de Curso Terminal de Control

Señal de Control

Ángulo de Direcionamiento

Timón

Ajustar Curso

Curso Corriente Parámetro de Seguimiento Localizar Objetivo

Giroscópo

Coordenadas del Objetivo

Parámetro de

Inv. Op. Adecuada

Disparo

Disparar Mísil

Detalle del Disparo

Misil

Fig.9 : Ejemplo de DFD de Transacciones Incorporando el Centro 28 Jimmy Camacho Villazón Docente Titular Ingeniería de Sistemas FCyT - UMSS


IND-225

Capítulo 1

El ejemplo de las transacciones bancarias de la figura ¡Error! Marcador no definido. es un poco diferente. El centro de transacción Iniciar Operación Deseada no fue incluido artificialmente. Eso se muestra en el DFD, tal vez, por algún motivo de modelado y puede traer alguna otra funcionalidad diferente a la de control. Ese es un proceso normal que tiene el rol de control y además tiene la función de control; ese hecho, puede ser modelado de la forma mostrada en la figura 10. Registro del Cliente

Saldo

Generar Reporte de Movimientos

# de Cuenta Operación Deseada

# de Cuenta

Iniciar Operación Deseada

# de Cuenta

Clientes

Movimiento Cuenta Corriente

Movimiento

Consultar Saldo de Cuenta

Saldo Movimiento

# de Cuenta

Registrar Depósito

Movimiento

# de Cuenta Registrar Extracción

Valor

Fig. 10: Ejemplo de DFD de Transacciones

Una vez identificado el centro de transacción, el DFD original resulta subdividido en un número de DFDs menores, uno por cada transacción, que pueden ser derivados por análisis de transformaciones o, nuevamente, por análisis de transacción. La figura muestra el DE resultante para los ejemplos de las figuras ¡Error! Marcador no definido. y ¡Error! Marcador no definido..


modelo estructurado

Recommend Documents