Ingeniería de Software 2015
3.1 Descomposición Modular:
Técnicas Generales de Diseño de Software El diseño de software es una actividad que requiere tener cierta experiencia previa. En este tema se hace un repaso a las técnicas más importantes de diseño que se emplean habitualmente. Con carácter general, todas las técnicas tratan de conseguir como objetivos inmediatos del diseño los siguientes ! "a descomposici#n modular del sistema. $plicar el concepto de modularidad % obtener una divisi#n del sistema en partes o m#dulos. ! &ecidir sobre los algoritmos %'o las estructuras de datos fundamentales que se deben utili(ar para la reali(aci#n del sistema $ continuaci#n se estudian las técnicas de diseño propiamente dichas, agrupadas en ). &ise &iseño ño mod modul ular ar des desce cend nden ente te *. &iseño orientado a objetos +. &iseño de datos DESCM!S"C"#$ MD%&'(
odas las técnicas de diseño están de acuerdo en la necesidad de reali(ar una descomposici#n modular del sistema como actividad fundamental del diseño % para lograrlo es necesario concretar los siguientes aspectos ! -dentificar los m#dulos ! &escribir cada m#dulo ! &escribir las relaciones entre m#dulos "a diferencia fundamental entre las distintas técnicas de diseño es precisamente lo que se entiende por m#dulo en cada una de ellas % los criterios que se deben emplear para su identificaci#n. Con carácter mu% general, se puede decir que un m#dulo es un fragmento de un sistema software que se puede elaborar con relativa independencia de los demás. "a idea básica es precisamente que la elaboraci#n de los diferentes m#dulos se pueda encargar a personas distintas % que todas ellas trabajen en paralelo. "os tipos de m#dulos son innumerables, algunos de ellos pueden ser los siguientes si guientes Có di*o *o fuen fu ente te.+ .+ Contiene texto fuente escrito en el lenguaje de programaci#n elegido. Es el tipo de ) Códi m#dulo que se usa con ma%or frecuencia. u formato % organi(aci#n dependen mucho de la técnica % el lenguaje empleado. ) Ta,la de Datos.+ e utili(a para tabular ciertos daos de iniciali(aci#n, experimentales o simplemente de dif/cil obtenci#n. ) Confi*uración.+ 0n sistema se puede concebir para trabajar con entornos diversos seg1n las necesidades de cada cliente. En estos casos, interesa agrupar en un mismo m#dulo toda aquella informaci#n que permite configurar el entorno concreto de trabajo. ) tros.+ En general, un m#dulo puede servir para agrupar ciertos elementos del sistema relacionados entre s/ % que se puedan tratar de forma separada del resto. ambién se elaboran por separado los ficheros de a%uda en l/nea, los manuales de usuario, etc.
Ingeniería de Software 2015
El formato concreto de cada tipo de m#dulo depende de la técnica, metodolog/a o herramienta utili(ados. 2ormalmente el objetivo fundamental de cualquier diseño es conseguir un sistema mantenible % solo en casos excepcionales se sacrificará este objetivo para lograr una ma%or velocidad de proceso o un menor tamaño de c#digo. 2o obstante, la experiencia acumulada permite establecer que una descomposici#n modular debe poseer ciertas cualidades m/nimas para que se pueda considerar suficientemente válida. Estas cualidades son las que veremos a continuaci#n. "ndependencia -uncional
En la matri( reuisitos/componentes del final de los documentos $&& % &&& es necesario indicar qué componente 3m#dulo4 se encargará de reali(ar cada uno de los requisitos 3funciones4 indicados en el documento 5&. Como primer paso de la descomposici#n se puede establecer que cada funci#n se podrá reali(ar en un m#dulo distinto. i el análisis está bien hecho % las funciones son independientes, estos m#dulos tendrán independencia funcional entre ellos. 6osteriormente % en sucesivos pasos de refinamiento del diseño se agruparán funciones afines en un mismo m#dulo o se subdividirán ciertos m#dulos en otros varios más sencillos. 6ara que un m#dulo posea independencia funcional debe reali(ar una funci#n concreta o un conjunto de funciones afines, sin apenas ninguna relaci#n con el resto de los m#dulos del sistema. 0na ma%or independencia redunda en una ma%or facilidad de mantenimiento o sustituci#n de un m#dulo por otro % aumenta la posibilidad de reutili(aci#n del m#dulo. 6ara medir de una forma relativa la independencia funcional que ha% entre varios m#dulos se utili(an fundamentalmente fundamentalmente dos criterios acoplamiento % co0esión. 1. 'coplamiento
El grado de acoplamiento entre m#dulos es una medida de la interrelaci#n que existe entre ellos tipo de conexi#n % complejidad de la interfase. 6ara medir de una forma cualitativa el grado de acoplamiento entre m#dulos se utili(a la siguiente escala
El objetivo que se persigue es que durante durante el diseño, el acoplamiento sea m/nimo por lo que habrá que buscar descomposiciones con acoplamiento débil o como mucho moderado. $coplamiento por Contenido e produce cuando desde un m#dulo se pueden cambiar los datos locales e incluso el c#digo de otro m#dulo. Este tipo de acoplamiento s#lo se puede lograr utili(ando un lenguaje ensamblador o de mu% bajo nivel % puede % debe ser evitado siempre. $coplami $cop lamiento ento Com1n Com 1n e emplea una (ona (ona com1n de datos a la que que tienen acceso varios o todos todos los m#dulos del sistema. "a depuraci#n % el mantenimiento de un sistema con esta descomposici#n, al igual que el anterior, resulta mu% dif/cil % siempre que se puede se debe evitar. $coplami $cop lamiento ento Externo Exte rno Está constituida por alg1n dispositivo externo 3disco, sensor, sensor, etc.4 al que están ligados ligados todos los m#dulos. "a estructura de la (ona com1n la impone el formato de los datos que maneja el dispositivo % cualquier modificaci#n modificaci#n exige el cambio de todos todos los m#dulos.
Ingeniería de Software 2015
$coplamiento de Control o acoplamiento moderado En este este caso, caso, una señal 3s4 o dato de control que se pasa de un m#dulo 3$4 a otro 374 es lo que determina la l/nea de ejecuci#n que se debe seguir dentro de este 1ltimo 374.
$coplamiento &ébil &ébil e produce s#lo a través tr avés del intercambio de aquellos datos que un m#dulo necesita de otro. i el intercambio se reali(a estrictamente con los 1nicos datos que se necesitan tenemos un acoplamiento de &atos. Este es el mejor tipo posible de acoplamiento. Cuando en el intercambio se suministra una referencia que facilita el acceso no s#lo a los datos estrictamente necesarios sino también a la estructura completa 3pila, vector, árbol, grafo, etc.4 tenemos un acoplamiento por Etiqueta. $mbos tipos de acoplamiento débil son los más deseables en una descomposici#n modular. Evidentemente el acoplamiento más débil es el que no existe. Este caso es el que se produce entre los m#dulos E % 7, entre los que no existe ning1n tipo de acoplamiento directo. . Co0esión
El criterio de cohesi#n es complementario al de acoplamiento. $demás de buscar un acoplamiento débil entre m#dulos es necesario lograr que el contenido de cada m#dulo tenga coherencia. Cuando se descompone un sistema se debe buscar un objetivo espec/fico para cada m#dulo. $ continuaci#n, se tratará de agrupar en el mismo m#dulo todos aquellos elementos afines o que estén relacionados con el objetivo fijado para dicho m#dulo. Como escala para medir de forma cualitativa la cohesi#n de un m#dulo se utili(a la siguiente
Cohesi#n Cohesi# n Coincidental Coincide ntal Es la peor posible % se produce produce cuando cualquier relaci#n entre los elementos del m#dulo es una 8pura coincidencia9, es decir, no guardan absolutamente ninguna relaci#n entre ellos. Cohesi# Cohe si#nn "#gica "#g ica e produce cuando cuando se agrupan en un mismo m#dulo elementos que reali(an funciones similares desde un punto de vista de usuario. Esta misma cohesi#n es la que existe en los m#dulos de entrada' salida o cuando se diseña un m#dulo para el manejo de todos los mensajes de error que se producen en el sistema. Cohesi# Cohe si#nn temporal temp oral Es el resultado de agrupar agrupar en un mismo m#dulo aquellos elementos elementos que se ejecutarán en un mismo momento. Esta es la situaci#n que se produce en la fase de iniciali(aci#n o finali(aci#n del sistema en que necesariamente se deben 8arrancar9 o 8parar9 dispositivos completamente heterogéneos teclado, pantalla, rat#n, impresora, etc.
Ingeniería de Software 2015
"a cohesi#n 7$:$ debe evitarse prácticamente siempre. siempre. &e hecho, tan solo se podr/a justificar una cohesi#n l#gica o temporal % solamente en los casos dados como ejemplo u otros semejantes. Cohesi# Cohe si#nn de Comunic Comu nicaci# aci#n n Es aquella que se produce produce cuando todos los elementos el m#dulo operan con el mismo conjunto de datos de entrada o producen el mismo conjunto de datos de salida. Cohesi# Cohe si#nn ecuenc ecu encial ial e produce cuando cuando todos los elementos del del m#dulo trabajan de forma secuencial. Esto es, la salida de un elemento del m#dulo es la entrada del siguiente de una manera sucesiva. Con una cohesi#n ;E&-$ se puede reducir el n1mero de m#dulos. in embargo, esto no se debe reali(ar a costa de aumentar el grado de acoplamiento entre m#dulos. Cohesi# Cohe si#nn
"a dinámica del proceso de diseño e implementaci#n de un sistema hace que los cambios sean más frecuentes de lo que ser/a deseable. 6osteriormente, los cambios contin1an durante la fase de mantenimiento hasta que se sustitu%e el sistema por otro nuevo. 6ara facilitar e incluso posibilitar estos cambios es necesario que cada m#dulo sea comprensible de forma aislada. El primer factor que facilita la comprensi#n de un m#dulo es su independencia funcional. Como se ha visto antes, con una cohesi#n alta % un acoplamiento débil, el m#dulo tiene menor dependencia del resto del sistema % por tanto será más fácil entender su funcionamiento de manera aislada. 6ero además es necesario cuidar los siguientes factores ). -dentificaci#n Elegir adecuadamente adecuadamente el nombre del m#dulo % de los nombres de cada uno de sus elementos. elementos. "os nombres deben reflejar de manera sencilla el objetivo de la entidad que representan. *. &ocumentaci#n "a labor de documentaci#n de cada m#dulo m#dulo % del sistema en general debe servir para facilitar la comprensi#n. e deben establecer normas % convenios de documentaci#n que evitar problemas de comprensi#n. Estas normas formarán parte del &ocumento de &iseño &etallado 3&&&4. +. implicidad "as soluciones sencillas sencillas son siempre las mejores. mejores. 0n esfuer(o fundamental del diseñador diseñador debe estar dedicado a simplificar al máximo las soluciones propuestas.
Ingeniería de Software 2015
'dapta,ilidad
"a independencia funcional % la comprensibilidad son dos cualidades esenciales que debe tener cualquier diseño para posibilitar su adapta,ilidad. >tros factores adicionales para facilitar la adaptabilidad son los siguientes ). 6revisi#n 5esulta mu% complicado complicado prever prever qué evoluci#n futura tendrá tendrá un determinado sistema. olo olo la experiencia previa nos podr/a indicar qué partes del sistema han sido más dados a cambios o adaptaciones en otros sistemas semejantes. *. $ccesibilidad $ntes de abordar la nueva adaptaci#n de un sistema, es necesario necesario conocerlo con la suficiente suficiente profundidad. Este trabajo s#lo es posible si resulta sencilla la accesibilidad a todos los documentos de especificaci#n, diseño e implementaci#n. +. Consistencia Cuando se reali(an reali(an adaptaciones sucesivas, es vital vital mantener la consistencia entre todos los documentos de especificaci#n, diseño e implementaci#n para cada nueva adaptaci#n. Existen herramientas para el 8control de versiones % configuraci#n9 que permiten mantener automáticamente la consistencia en cada adaptaci#n. TEC$"C'S DE D"SE2 -%$C"$'& DESCE$DE$TE
En este grupo de técnicas se inclu%en todas aquellas en que la descomposici#n del sistema se hace desde un punto de vista funcional, es decir, se atiende fundamentalmente a la funci#n o funciones que ha de reali(ar el sistema, que se van expresando poco a poco mediante funciones más sencillas, las cuales se encomiendan a m#dulos separados. &esde el punto de vista de la codificaci#n, cada m#dulo corresponde esencialmente a un subprograma. 6or esta ra(#n estas técnicas de diseño conducen a estructuras modulares que pueden implementarse bien casi con cualquier lenguaje de programaci#n. Desarrollo por refinamiento pro*resio
Esta técnica corresponde a la aplicaci#n en la fase de diseño de la metodolog/a de programaci#n conocida como pro*ramación estructurada , % que condujo a la construcci#n de programas mediante refinamientos sucesios . "a programaci#n estructurada recomienda emplear en la construcci#n de programas s#lo estructuras de control claras % sencillas, con un 1nico punto inicial % un 1nico punto final de ejecuci#n. En particular son la secuencia, la selección entre alternativas, % la iteración. El concepto de refinamiento consiste en plantear inicialmente el programa como una operaci#n global, 1nica, e irla descomponiendo poco a poco en funci#n de otras operaciones más sencillas. Ejemplo de refinamientos sucesivos
!ro*ramación estructurada de 4ac5son
Esta técnica sigue las ideas de la programaci#n estructurada en cuanto a las estructuras recomendadas 3secuencia, selecci#n e iteraci#n4 % el método de refinamientos sucesivos para construir la estructura del programa en forma descendente. "a técnica original de la programaci#n estructurada de :ac?son se basa en los siguientes pasos ). $nali(ar $nali(ar el entorno entorno del del problema problema % describi describirr las estructu estructuras ras de datos datos a procesar. procesar. *. Construir la estructura estructura del programa basada en las estructuras de datos. +. &efinir las tareas tareas a reali(ar reali(ar en términos términos de las operaciones operaciones elementales elementales disponibles, disponibles, % situarlas en los m#dulos apropiados de la estructura del programa. Como técnica de diseño los pasos significativos son los dos primeros, mientras que el tercero corresponde más bien a la fase de codificaci#n. Diseño Estructurado
Esta técnica de diseño es el complemento del llamado análisis estructurado. $mbas técnicas coinciden en el empleo de los diagramas de flujo de datos 3&<&4, como medio fundamental de representaci#n del modelo funcional del sistema. "a tarea de diseño consiste en pasar de los &<&@s a los diagramas de estructura, la dificultad radica en que ha% que establecer una jerarqu/a o estructura de control entre los diferentes m#dulos. 6ara establecer dicha jerarqu/a de control entre las diversas operaciones descritas en los &<&@s, la técnica de diseño estructurada recomienda hacer el análisis de flujo de datos global, es decir, reali(ar análisis denominados de flujo de transformaci#n % de flujo de transacci#n. $nálisis de flujo de ransformaci#n Consiste en identificar identificar un flujo global de informaci#n desde los elementos de entrada al sistema hasta los de salida. "os procesos se dividen en tres entradas denominadas flujo de entrada, flujo de transformaci#n % flujo de salida. $nálisis del flujo de ransacci#n Este se aplicará cuando cuando el flujo de datos se pueda descomponer descomponer en varias l/neas separadas, cada una de las cuales corresponde a una funci#n o transacci#n distinta, de manera que solo una de estas l/neas se activa para cada entrada de datos de tipo diferente, dicho análisis consiste en identificar el denominado centro de transacci#n a partir del cual se ramifican las lineas de flujo. TEC$"C'S DE D"SE2 6'S'D E$ '6ST('CC"$ES
Estas técnicas de diseño surgen cuando se identifican con precisi#n los conceptos de abstracci#n de datos % de ocultaci#n. "a idea general es que los m#dulos se correspondan o bien con funciones o bien con tipos abstractos de datos. "as estructuras modulares resultantes pueden implementarse bien con lenguajes de programaci#n que tengan facilidades para implementar abstracciones de datos tales como ;odulaA*, $da o C. 6or supuesto, pueden también implementarse con lenguajes de programaci#n orientado a objetos, que poseen a1n más facilidades 3:ava, 6B6, C4.
Descomposición Modular ,asada en ',stracciones
Como técnica de programaci#n, consiste en ampliar el lenguaje existente con nuevas operaciones % tipos de datos, definidos por el usuario, de forma que se simplifique la escritura de los niveles superiores del programa. Como técnica de diseño, consiste en dedicar m#dulos separados a la reali(aci#n de cada tipo abstracto de datos % cada funci#n importante. Esta técnica de diseño puede aplicarse tanto en forma ascendente como descendente. En forma descendente puede considerarse como una ampliaci#n de la técnica de refinamiento progresivo. i se aplica de forma ascendente se trata de ir ampliando las primitivas existentes en el lenguaje de programaci#n % las librer/as asociadas con nuevas operaciones % tipos de ma%or nivel, más adecuados para el campo de la aplicaci#n que se está diseñando. Método de ',,ott
En este método se sugiere una forma met#dica de conseguir descripciones más formales que empleando notaciones precisas % no solo lenguaje natural. "a idea es identificar en el texto de la descripci#n aquellas palabras o términos que puedan corresponder a elementos significativos del diseño como son los tipos de datos, los atributos % las operaciones. "os tipos de datos aparecen como sustantivos genéricos, los atributos como sustantivos % las operaciones como verbos. $lgunos adjetivos pueden aparecer como valores de atributos. TEC$"C'S DE D"SE2 ("E$T'D'S ' 64ETS
El diseño orientado a objetos es esencialmente igual al diseño basado en abstracciones, que de hecho se describe en muchos casos como 8basado en objetos9. "os objetos s#lo añaden algunas caracter/sticas adicionales, tales como la herencia % el polimorfismo. "a idea global de las técnicas de diseño orientadas a objetos es que en la descomposici#n modular del sistema cada m#dulo contenga la descripci#n de una clase de objetos o de varias clases relacionadas entre s/. Diseño rientado a ,7etos
"a técnica general de diseño orientado a objetos se basa en los siguientes pasos ). Estudiar Estudiar % comprend comprender er el problema problema a resolv resolver. er. Este Este paso debe debe haberse haberse reali(ad reali(adoo %a en la fase de análisis de requisitos. *. &esarrollar en l/neas generales una posible soluci#n. soluci#n. &escribirla suficientemente, suficientemente, al menos de una manera informal. Es posible que esto se ha%a hecho también durante la fase de análisis, aunque es más probable que se tenga que hacer o completar en la fase de diseño. Convendrá considerar varias alternativas % elegir la que se considere más apropiada. +.
Tema 3.1 Descomposición Modular 'ctiidad por euipo: Dué entendiste por m#duloF DEn qué consiste la descomposici#n modularF DCuáles son los tres aspectos importantes i mportantes que deben tomarse en cuenta para reali(ar una descomposici#n modular a un sistemaF ;enciona los tipos de ;#dulos más comunes en un sistema ;enciona las cualidades m/nimas que debe contener una descomposici#n modular ;enciona las técnicas de &iseño que permiten descomposici#n modular &e acuerdo al sistema que desarrolla mencione los m#dulos en los que está divido el sistema $ su juicio estará completa la descomposici#n modular 3conteste s8 o no9 en caso de contestar no mencione el o los m#dulos que faltan4 DCuál es el objetivo de descomponer un sistema en m#dulosF "nte*rantes de euipo: 2ota enviar esta informaci#n a gmpGHIJtectama(unchale.edu.mx olo el est
