Modularidad PDF

TEMA 6:
MODULARIDAD
MSc. Andrea Teresa Cubillos Johnen
FACULTAD DE CIENCIAS Y TECNOLOGIA
CARRERA: INGENIERIA DE SISTEMAS
MATERIA: INGENIERIA DEL SOFTWARE
INTRODUCCION
La modularidad es uno de los temas principales en el diseo de
software. La modularidad tiene que ver con la estructura del
software. Esta estructura es el producto final de todos los mtodos
de diseo actuales tales como la descomposici!n funcional diseo
orientado a o"#etos $ los datos $ diseo de estructura.
%i se nos pidiera disear un autom!vil pro"a"lemente lo
disear&amos en trminos de varios su"sistemas ' motor
transmisi!n frenos c(asis etc. Llamemos estos su"sistemas
componentes. )l identificar estos componentes de autom!vil se
(an seleccionado los art&culos que son lo m*s independientes
posi"le unos de otros. Esta es la esencia la "uena modularidad.
+%c. )ndrea Teresa Cu"illos -o(nen
.UE E% UN CO+/ONENTE0
-ava es un t&pico len1ua#e moderno. En su m*s alto nivel de
1ranularidad un n2mero de sentencias $ declaraci!n de varia"les
pueden ser colocadas dentro de un mtodo. Un con#unto de mtodos
se pueden a1rupar #unto con al1unas varia"les compartidas dentro
de una clase. Un n2mero de clases puede a1ruparse dentro de un
paquete. )unque un component es una pie3a de pro1rama
independiente que tiene un nom"re al1unas instrucciones $ al1unos
datos por s& mismo. Un component es utili3ado o llamado por al12n
otro component $ similarmente utili3a 4llamadas5 a otros
components.
E6iste una variedad de mecanismos para divider el software en
componentes independientes o e6presado de otra manera a1rupar
elementos que tienen al1una afinidad en com2n.
En varios len1ua#es de pro1ramaci!n un component es7
Un mtodo
Una clase
Un paquete
/OR.UE L) +ODUL)RID)D0
El escenario es un software que consiste de miles o cientos de
miles de lineas de c!di1o. La comple#idad de tales sistemas puede
ser a"rumadora. El deseo de modularidad es acerca de intentar
constuir software a traves de las pie3as que son lo m*s
independiente posi"le unas con otras. Idealmente cada
componente de"er&a ser auto contenido $ tener las menos
referencias posi"les a otros components.
DISEO ARUITECTO!ICO
Este es el paso en el cual la estructura de 1ran escala de software
es determinada. /or lo cual es cr&tica para crear "uena
modularidad. Un enfoque de diseo que conlleva a una po"re
modularidad conllevar* a consecuencias futuras nefastas.
DISEO DE COM"O!E!TES
%i el diseo de la arquitectura es modular el diseo de los
componentes individuales ser* f*cil. Cada componente tendr* un
solo prop!sito "ien definido con pocas cone6iones con otros
componentes.
DE"URACIO!
Es durante la depuraci!n que la modularidad "rilla con lu3
propia. %i la estructura es modular de"er&a ser m*s f*cil
identificar qu componente en particular es responsa"le de la
falla o"servada. Del mismo modo la correcci!n de un solo
componente no de"e producir efectos de 8Reacci!n en cadena8 $a
que las interfaces desde $ (acia el componente no son afectados.
"RUE#AS
La prue"a de un 1ran sistema compuesto por un 1ran n2mero de
componentes es una tarea dif&cil $ consume muc(o tiempo. Es
pr*cticamente imposi"le pro"ar un componente individual en detalle
una ve3 se (a inte1rado en el sistema. /or lo tanto la prue"a se lleva
a ca"o de manera fra1mentada un componente a la ve3. 9a que la
estructura del sistema es crucial.
MA!TE!IMIE!TO
Esto si1nifica corre1ir errores $ me#orar el sistema para satisfacer las
necesidades del usuario. Esta actividad consume enormes cantidades
de tiempo a los desarrolladores de software. Una ve3 m*s la
modularidad es crucial. Lo ideal ser&a (acer un cam"io a un solo
componente con la total confian3a de que otros componentes no se
ver*n afectados. %in em"ar1o con demasiada frecuencia sucede que
intercone6iones sutiles u o"vias entre los componentes (acen que el
proceso de mantenimiento una pesadilla.
DESARROLLO I!DE"E!DIE!TE
La ma$or&a del software se lleva a ca"o por un equipo de
personas a menudo durante meses o aos. Normalmente cada
componente se desarrolla por una sola persona. /or tanto es vital
que las interfaces entre componentes sean pocas $ claras.
CO!TROL DE DAOS
Cuando se produce un error en un componente la propa1aci!n de
daos a otros componentes ser* minimi3ada si se (a limitado las
cone6iones con otros componentes .
REUTILI$ACIO! DEL SO%T&ARE
Una tcnica importante de in1enier&a de software es reutili3ar los
componentes de software de una "i"lioteca a partir de un pro$ecto
anterior. Esto evita reinventar la rueda $ puede a(orrar un
enorme esfuer3o. )dem*s los componentes reutili3a"les
1eneralmente se prue"an a fondo. Es un sueo de los in1enieros
de software seleccionar $ utili3ar componentes 2tiles.
%in em"ar1o un componente no puede ser f*cilmente reutili3ado
si se conecta de un modo comple#o con otros componentes.
:a$ por lo tanto tres requisitos para un componente reutili3a"le7
;. proporciona un servicio 2til
<. reali3a una sola funci!n
=. tiene el m&nimo de cone6iones 4idealmente no (a$ cone6iones5 a
otros componentes.
TI/O% DE CO+/ONENTE%
Los componentes pueden ser clasificados de acuerdo a sus funciones 7
s!lo c!mputo
memoria
1esti!n
controlador
enlace
Un componente de c!mputo no conserva nin12n dato entre posteriores
usos. )l1unos e#emplos son un mtodo matem*tico.
Un componente de memoria mantiene una colecci!n de datos
persistentes tales como una "ase de datos o un sistema de arc(ivos.
4Los datos persistentes son datos que e6isten m*s all* de la vida de
un pro1rama en particular o componente $ se almacena normalmente
en un medio de almacenamiento de respaldo tal como un disco.5
Un componente de 1esti!n es un tipo a"stracto de datos manteniendo
los datos $ las operaciones que pueden ser utili3ados en l. E#emplos
cl*sicos son una pila o una cola.
TI/O% DE CO+/ONENTE%
Un componente controlador controla cuando otros componentes se
activan o c!mo interact2an.
Un componente de enlace transfiere informaci!n entre otros
componentes. E#emplos son una interfa3 de usuario 4que
transfiere la informaci!n entre el usuario de un sistema $ uno o
m*s componentes5 $ el software de red.
T)+)>O 9 CO+/LE-ID)D DE LO%
CO+/ONENTE%
?.u tan 1rande de"e ser un componente de software0 Considere
la posi"ilidad de cualquier pie3a de software. %iempre se puede
construir de dos formas radicalmente diferentes ' una ve3 con
pequeos componentes $ de nuevo con componentes 1randes.
Como ilustraci!n la si1uiente fi1ura muestra dos estructuras
alternativas para el mismo software. Una consiste en muc(as
pie3as pequeas@ la otra de unos pocos 1randes componentes.
CO+/ONENTE%
%i los componentes son 1randes s!lo (a"r* unos pocos de ellos $
por lo tanto tender* a (a"er s!lo unas pocas cone6iones entre
ellos. Tenemos una estructura de red con pocas ramas $ al1unas
(o#as mu$ 1randes. La comple#idad de las intercone6iones es
m&nima pero la comple#idad de cada componente es alta.
%i los componentes son pequeos (a"r* muc(os componentes $
por tanto muc(as cone6iones entre ellos. La estructura es una
red con muc(as ramas $ muc(as (o#as pequeas. +ientras m*s
pequeo los componentes m*s f*cil se de"er&a comprender un
componente individual. /ero si los componentes son pequeos se
corre el ries1o de ser a"rumados por la proliferaci!n de las
intercone6iones entre ellos.
CO+/ONENTE%
La pre1unta es7 ?Cu*l de las dos estructuras es la me#or0 Las
alternativas son 1randes componentes con pocas cone6iones o
pequeos componentes con muc(as cone6iones .
%in em"ar1o como veremos el dilema no es 1eneralmente tan simple
como esto. Un punto de vista com2n es que un componente de"e
ocupar no m*s de una p*1ina de codificaci!n 4AB'CB l&neas5. Esta
su1erencia tiene en cuenta la dificultad de comprensi!n l!1ica que se
derrama de una p*1ina de la lista 4o de una pantalla a otra5.
Un punto de vista m*s e6tremo es el de que un componente de"e
durar normalmente alrededor de siete o menos l&neas de c!di1o $ en
nin12n caso m*s de nueve. )r1umentos a favor del Dn2mero m*1icoE F
se "asan en los resultados e6perimentales de la psicolo1&a. La
investi1aci!n indica que el cere"ro (umano es capa3 de comprender
s!lo siete cosas 4o conceptos5 a la ve3. Esto no quiere decir que
podamos recordar s!lo siete cosas. /ero s!lo podemos retener un par
de cosas en la memoria a corto pla3o $ estudiar como un con#unto
completo relacionado de o"#etos.
CO+/ONENTE%
Es evidente que un recuento del n2mero de l&neas es una medida
demasiado crudo para el tamao de un componente. Un
componente de siete l&neas que contiene varias sentencias if es
m*s comple#a que una de siete declaraciones comunes.
?Necesitamos un par de pie3as de 1ran tamao o muc(os
componentes pequeos0 La respuesta es que necesitamos am"os.
/lantemos la cuesti!n de c!mo se e6amina una pie3a de software.
Estudiar un pro1rama es necesario durante el diseo
arquitect!nico la verificaci!n depuraci!n $ mantenimiento $ por
lo tanto es una actividad importante. )l estudiar el software no
podemos mirarlo todo a la ve3 porque es demasiado comple#o para
comprenderlo en su con#unto.
CO+/ONENTE%
Cuando tenemos que entender la estructura 1eneral del software
4por e#emplo durante el diseo o durante el mantenimiento 5
necesitamos pie3as de 1ran tamao. En otras ocasiones 4por
e#emplo depuraci!n5 tenemos que centrar la atenci!n en un
componente individual /ara este prop!sito es preferi"le un
pequeo componente. %i el software (a sido "ien diseado
podemos estudiar la l!1ica de un componente individual en forma
aislada. %in em"ar1o como parte de la tarea del estudio de un
componente necesitamos sa"er al1o acerca de los componentes
que utili3a. Con este fin el poder de a"stracci!n es 2til $a que si
"ien entendemos lo que (acen otros componentes no necesitamos
entender c!mo lo (acen. /or lo tanto lo ideal es que nunca
ten1amos la necesidad de comprender m*s de un componente a la
ve3. Cuando (a$amos completado el e6amen de uno de los
componentes diri1imos nuestra atenci!n a otro. /or lo tanto
lle1amos a la conclusi!n de que es importante el tamao $ la
comple#idad de los componentes individuales $ sus cone6iones con
otros componentes.
CO+/ONENTE%
Los componentes pequeos pueden dar lu1ar a pro1ramas m*s
lentos de"ido a la ma$or so"recar1a de llamadas a mtodos. /ero
(o$ en d&a el tiempo de un pro1ramador puede costar muc(o m*s
que el tiempo de una computadora. La pre1unta aqu& es si es m*s
importante que un pro1rama sea f*cil de entender o si es m*s
importante que se e#ecute de forma r*pida.
Estudios (an demostrado que los pro1ramas pasan la ma$or parte
de su tiempo 4apro6imadamente CBG5 e#ecutando una pequea
fracci!n 4apro6imadamente ;BG5 de c!di1o. Es la optimi3aci!n de
estas pequeas pie3as que dar*n lu1ar a me#ores resultados.
CO+/ONENTE%
En los primeros d&as de la pro1ramaci!n la memoria principal era
pequea $ procesadores eran lentos. %e considera"a normal
esfor3arse (acer pro1ramas eficaces. :o$ en d&a la situaci!n es
"astante diferente ' la presi!n es en reducir el tiempo de
desarrollo de los pro1ramas $ aliviar la car1a de mantenimiento.
)s& que el nfasis est* en que la escritura de pro1ramas sean
claros $ simples $ por lo tanto f*cil de revisar entender $
modificar.
?Cu*les son los ar1umentos a favor de la simplicidad 0
es m*s r*pido para depurar un pro1rama simple
es m*s r*pido para poner a prue"a un pro1rama simple
es m*s pro"a"le que un pro1rama simple sea m*s confia"le
es m*s r*pido modificar un pro1rama sencillo
LO% D)TO% HLOI)LE% E% D)>IN)
/or datos 1lo"ales nos referimos a datos que pueden ser
ampliamente utili3ados a lo lar1o de una pie3a de software $ es
accesi"le a un n2mero de componentes en el sistema. El trmino
dato local se refiere a los datos que s!lo pueden ser utili3ados
dentro de un componente espec&fico@ el acceso est* estrec(amente
controlado.
/ara cualquier pie3a de software el diseador tiene la opci!n de
(acer que los datos sean 1lo"ales o locales. %i se toma la decisi!n
de utili3ar los datos locales los datos pueden ser compartidos
pas*ndolos como par*metros.
)qu& est* el ar1umento en contra de los datos 1lo"ales. %upon1amos
que los tres componentes nom"rados ) I $ C acceden a datos
1lo"ales como se muestra en la fi1ura. %upon1amos que tenemos que
estudiar el componente ). %upon1amos que los componentes ) $ I
acceden a una parte de los datos 1lo"ales llamado J. Entonces a fin
de comprender ) tenemos que entender el papel de J. /ero a(ora con
el fin de entender J tenemos que e6aminar I. )s& terminamos por
tener que estudiar un se1undo componente 4I5 cuando lo 2nico que
quer&amos entender era uno. /ero la (istoria se pone peor.
%upon1amos que los componentes I $ C comparten datos. Entonces
para entender I tenemos que entender C. /or lo tanto con el fin de
entender el componente ) tenemos que entender no s!lo el
componente I sino tam"in el componente C.
Kemos que para comprender cualquier componente que utili3a datos
1lo"ales tenemos que entender todos los componentes que lo utili3an.
En 1eneral los datos locales son preferi"les de"ido a que7
es m*s f*cil de estudiar un componente individual porque est*
claro que datos utili3a el componente
es m*s f*cil remover un componente $ utili3arlo en un nuevo
pro1rama porque es un paquete autocontenido.
los datos locales son m*s f*cil de leer $ entender porque se (a
reducido en tamao.
)s& en 1eneral la cantidad de datos 1lo"ales de"er&a ser minimi3ados
$ los datos locales ma6imi3ados. :o$ en d&a la ma$or&a de los
len1ua#es de pro1ramaci!n proporcionan un "uen apo$o para los
datos locales $ al1unos no permiten de datos 1lo"ales.
La ma$or&a de los len1ua#es de pro1ramaci!n modernos proporcionan
una facilidad para mtodos 1rupales $ datos dentro de un componente
4denominado diversamente un componente clase o paquete5. Dentro
de tal componente los mtodos acceden a datos compartidos lo cual
es 1lo"al. /ero estos datos son 1lo"ales dentro del componente.
OCULT)+IENTO DE INLOR+)CION
El ocultamiento de informaci!n ocultaci!n de datos o
encapsulaci!n es un enfoque para el software estructurado de
forma mu$ modular. La idea es que para cada estructura de
datos la estructura en s& las sentencias que acceden a la
estructura $ las sentencias que modifican la estructura son parte
de un solo componente.
Un peda3o de datos encapsulados como este no puede ser accedido
directamente. %!lo puede ser accedido a travs de uno de los
mtodos asociados con los datos. Esta recopilaci!n de datos $
mtodos es llamado un tipo a"stracto de datos o 4en
pro1ramaci!n orientada a o"#etos5 una clase o un o"#eto.
Un e#emplo cl*sico del uso de la ocultaci!n de informaci!n es la
pila. Los mtodos son proporcionado para iniciali3ar la pila para
empu#ar un elemento (asta la cima de la pila $ para sacar un
elemento desde la parte superior. Opcionalmente se proporciona
un mtodo con el fin de compro"ar si la pila est* vac&a. El acceso a
la pila es s!lo a travs de estos mtodos. Dada esta especificaci!n
el implementador de la pila tiene li"ertad para almacenarlo como
una matri3 una lista enla3ada o lo que sea.
El usuario de la pila tampoco necesita sa"er ni le importa c!mo
se implementa la pila. Cualquier cam"io en la representaci!n de
la pila no tiene efecto so"re los usuarios.
El ocultamiento de informaci!n cumple con tres o"#etivos 7
CAM#IA#ILIDAD
%i se cam"ia una decisi!n de diseo tal como la estructura de
arc(ivos los cam"ios se limitan a los menos componentes posi"les
$ preferi"lemente a un 2nico componente.
DESARROLLO I!DE"E!DIE!TE
Cuando un sistema est* siendo implementado por un equipo de
pro1ramadores las interfaces entre los componentes de"en ser
tan simples como sea posi"le. El ocultamiento de informaci!n
si1nifica que las interfaces son llamadas en mtodos.
COM"RE!SI#ILIDAD
) efectos de diseo verificaci!n prue"as $ mantenimiento es
vital para entender los componentes individuales de forma
independiente. Como (emos visto los datos 1lo"ales $
compartidos de"ilitan nuestra capacidad de entender el software.
El ocultamiento de informaci!n simplemente elimina este
pro"lema.
)l1unos len1ua#es de pro1ramaci!n 4)da C M M +odula < -ava
C N Kisual Iasic Net5 soportan la ocultaci!n de informaci!n
mediante la prevenci!n de cualquier referencia a un componente a
menos que sean llamadas a mtodos declarados p2"lico. Es
evidente que las facilidades de los len1ua#es de pro1ramaci!n
pueden a$udar en 1ran medida a estructurar el software de
acuerdo a la informaci!n oculta.
En resumen el principio de ocultaci!n de informaci!n si1nifica
que al final del proceso de diseo cualquier estructura de datos o
arc(ivo s!lo puede ser accedido a travs de mtodos espec&ficos.
)l1unos len1ua#es de pro1ramaci!n soportan la ocultaci!n de
informaci!n mientras que otros no lo (acen. El principio de
ocultaci!n de informaci!n se (a convertido en un concepto
importante en el diseo de pro1ramas $ la in1enier&a de software.
En la pro1ramaci!n orientada a o"#etos los datos $ acciones que
est*n fuertemente relacionadas son a1rupadas en entidades
llamadas o"#etos. Normalmente se permite el acceso a los datos
s!lo a travs de mtodos particulares. /or lo tanto la ocultaci!n de
informaci!n es implementada $ soportada por el len1ua#e de
pro1ramaci!n. Los datos 1lo"ales son completamente eliminados.
)CO/L)+IENTO 9 CO:E%ION
Las ideas de acoplamiento $ la co(esi!n son una terminolo1&a $
un esquema de clasificaci!n para descri"ir las interacciones entre
los componentes $ dentro de los componentes. Idealmente una
pie3a de software de"e ser construida a partir de componentes de
tal manera que e6ista un m&nimo de interacciones entre
componentes 4"a#o acoplamiento5 $ por el contrario un alto 1rado
de interacci!n dentro de un componente 4alta co(esi!n5.
Los si1uientes dia1ramas ilustran las ideas de acoplamiento $
co(esi!n. Los dia1ramas muestran la misma pie3a de software
pero diseado de dos formas diferentes. )m"as estructuras
constan de cuatro componentes. )m"as estructuras implican <B
interacciones 4llamadas a mtodos o acceso a elementos de datos5.
En el dia1rama de la i3quierda (a$ muc(as interacciones entre
los componentes pero comparativamente pocos dentro de los
componentes . En contraste en el dia1rama de la derec(a (a$
pocas interacciones entre componentes $ muc(as interacciones
dentro de los componentes . El pro1rama de la i3quierda tiene
acoplamiento fuerte $ co(esi!n d"il. El pro1rama de la derec(a
tiene acoplamiento d"il $ una fuerte co(esi!n .
)coplamiento $ co(esi!n son las dos caras de la misma moneda
en la que una fuerte co(esi!n tender* a crear un acoplamiento
d"il $ viceversa.
Las ideas de acoplamiento $ co(esi!n su1irieron en la dcada de
;OFB por 9ourdon $ Constantino. Datan de la poca en que la
ma$or&a de los len1ua#es de pro1ramaci!n permit&an al
pro1ramador muc(a m*s li"ertad que los len1ua#es modernos.
)s& el pro1ramador ten&a un enorme poder pero i1ualmente ten&a
la li"ertad de escri"ir c!di1o que (o$ en d&a podr&a ser
considerado peli1roso. ) pesar de su edad la terminolo1&a de
acoplamiento $ co(esi!n esta todav&a vi1ente $ es ampliamente
utili3ada para descri"ir las interacciones entre los componentes
de software.
)CO/L)+IENTO
Estamos familiari3ados con la idea de que uno de los componentes
(a1a una llamada a un mtodo en otro componente pero que
otros tipos de interacci!n 4acoplamiento5 (a$ entre los
componentes0 ?.u tipos son "uenos $ cu*les malos0
En primer lu1ar un aspecto importante de la interacci!n entre los
componentes es su 8tamao8. Cuanto menor sea el n2mero de
elementos que conectan componentes me#or. %i los componentes
comparten datos comunes de"e se minimi3ado. /ocos par*metros
se de"en pasar entre componentes mediante llamadas a mtodos.
%e (a su1erido que no m*s de < a A par*metros de"en ser
utili3ados. El en1ao no de"e ser practicado al a1rupar varios
par*metros en un re1istro $ lue1o utili3ar el re1istro como un
2nico par*metro.
)CO/L)+IENTO
?.u (a$ acerca de la naturale3a de la interacci!n entre los
componentes0 /odemos distin1uir las si1uientes maneras en que
los componentes interact2an. %e enumeran en un orden que va de
acoplamiento fuerte 4menos desea"le5 a un acoplamiento d"il
4m*s desea"le57
;. )lterar el c!di1o de otro componente
<. Llamar a un lu1ar que no sea el punto de entrada normal
=. El acceso a datos dentro de otro componente
A. Datos 1lo"ales o compartidos
C. Llamada al mtodo con un switc( como par*metro
P. Llamada a un mtodo con par*metros de datos puros
F. /asar una corriente de datos en serie a partir de un
componente a otro.
)CO/L)+IENTO
ALTERACIO! DE CODI'O DE OTRO COM"O!E!TE
Este es un tipo "astante raro de la interacci!n $ el 2nico len1ua#e de
pro1ramaci!n que normalmente permite es el ensam"lador. %in
em"ar1o en Co"ol la instrucci!n )LTER permite que un pro1rama
esencialmente modifique su propio c!di1o. El pro"lema con esta forma
de interacci!n es que un error en un componente es decir el
componente modificado aparece como un s&ntoma en otro el cual est*
siendo modificado.
I!'RESAR "OR LA "UERTA LATERAL
En este tipo de interacci!n un componente llama a otro desde un
lu1ar distinto que el punto de entrada normal. Una ve3 m*s esto es
imposi"le en la ma$or&a de los len1ua#es e6cepto ensam"lador Co"ol
$ las primeras versiones de Iasic.
La o"#eci!n a este tipo de interacci!n es parte del ar1umento a favor
de la pro1ramaci!n estructurada. Es s!lo mediante el uso de
componentes que tienen una sola entrada 4al inicio5 $ una salida 4al
final5 que podemos usar el poder de la a"stracci!n para disear $
entender 1randes pro1ramas.
)CO/L)+IENTO
MODI%ICACIO! DE DATOS DE!TRO DE OTROS
COM"O!E!TES
/ermitir que un componente altere los datos de otro componente
parece "astante menos daino que cam"iar de c!di1o de otro
componente. %in em"ar1o la e6cepci!n es la misma $ el
acoplamiento es fuerte de"ido a que si un fallo aparece en uno de
los componentes puede ser causado por otro.
DATOS 'LO#ALES O COM"ARTIDOS
Los datos compartidos son los datos en los que dos o m*s
componentes tienen acceso. Los datos est*n en un componente
distinto. Los datos 1lo"ales si1nifica una colecci!n de datos que
son accesi"les a un 1ran n2mero de componentes. La facilidad
para acceder a los datos de esta manera est* presente en casi
todos los len1ua#es de pro1ramaci!n ampliamente utili3ados.
)CO/L)+IENTO
U!A LLAMADA A METODO CO! U! "ARAMETRO UE ES
U! S&ITC(
:emos visto que tanto los datos compartidos $ transferencias
inusuales de control producen un fuerte acoplamiento entre
componentes. La soluci!n es utili3ar las llamadas de mtodo con
sus par*metros concomitantes. )un as& es posi"le empeorar el
acoplamiento al pasar como un par*metro datos no puros sino un
elemento de control. Un e#emplo es donde un componente es
pasado un indicador dicindole al mtodo que acci!n tomar entre
un n2mero de acciones disponi"les. 4Este indicador es a veces
llamado un switc(5. Un e#emplo de una llamada a un mtodo en
un mtodo de entrada $ salida de prop!sito 1eneral7
In)u*Ou*)u* +co,,and- de.ice- bu//er- len0*h12
)CO/L)+IENTO
El par*metro co,,and tiene valores de B ; < etc que
especifican si la operaci!n es lectura escritura a"rir etc. Esto no
es desea"le simplemente porque es innecesariamente complicado.
Este mtodo puede ser dividido en varios mtodos para llevar a
ca"o una sola acci!n. Como alternativa a llamar a un solo mtodo
$ pasarlo a un interruptor se puede llamar al mtodo individual
as&7
read+de.ice- bu//er- len0*h12
%e (a eliminado un par*metro de la interacci!n $ al mismo
tiempo se (an creado mtodos "ien definidos cada uno con una
funci!n espec&fica. Esto contrasta con un mtodo multiprop!sito.
Esta modulari3aci!n es m*s f*cil de entender $ mantener.
)CO/L)+IENTO
LLAMADAS A METODOS CO! "ARAMETROS UE SO! DATOS
"UROS
)qu& tenemos una forma de acoplamiento que es casi ideal. Los
componentes interact2an de una manera "ien definida no sufre
nin1una de las de"ilidades descritas en los esquemas anteriormente
descritos. Es mu$ claro sa"er qu informaci!n se es la que se
comunica entre componentes.
E!3IA!DO U!A CORRIE!TE DE DATOS E! SERIE
El acoplamiento m*s d"il se lo1ra sin nin1una transferencia de
control entre los componentes. )qu& es donde un componente pasa
una corriente en serie de datos a otro.
Este tipo de interacci!n est* disponi"le en al1unos len1ua#es de
pro1ramaci!n $ la ma$or&a de los sistemas operativos. Dentro de la
li"rer&a de -ava las clases #ava.io./ipedInput%tream $
#ava.io./ipedOutput%tream permiten que un o"#eto productor 4ori1en
de datos 5 env&e un flu#o de datos serial a un o"#eto de consumo 4
receptor de datos 5.
CO:E%ION
La co(esi!n es so"re la unidad. ?C!mo a1rupar acciones de la
me#or manera0 La co(esi!n descri"e la naturale3a de las
interacciones dentro de un mtodo. Un plan (a sido ela"orado
para la clasificaci!n de los diferentes tipos de co(esi!n. Estos van
desde la "a#a co(esi!n 4indesea"le5 en la parte superior de la lista
a una alta co(esi!n 4desea"le5 en la parte inferior. La lista de
cate1or&as es la si1uiente7
;. Coincidental
<. L!1ica
=. Temporal
A. Comunicacional
C. Luncional
CO:E%ION
CO(ESIO! COI!CIDE!CIAL
Los elementos est*n en el mtodo por pura coincidencia. No (a$
una relaci!n entre los elementos@ su coe6istencia es puramente
ar"itraria.
CO(ESIO! LO'ICA
El mtodo lleva a ca"o un con#unto de funciones l!1icamente
similares. El pro"lema con un mtodo l!1icamente co(esivo es que
es multifuncional@ lleva a ca"o un men2 de acciones en lu1ar de
una sola acci!n "ien definida. Es innecesariamente comple#o. %i
necesitamos modificar cualquier in1rediente dentro del mtodo
encontraremos que es dif&cil de i1norar los otros elementos.
CO:E%ION
CO(ESIO! TEM"ORAL
El mtodo reali3a una serie de acciones cu$a 2nica relaci!n es que
tienen que llevarse a ca"o al mismo tiempo. El e#emplo cl*sico es un
con#unto de iniciali3aci!n de operaciones. )s& un mtodo que lleva a
ca"o el si1uiente con#unto de acciones7 limpiar pantalla a"rir arc(ivo
e iniciali3ar total e6(i"ir&a una co(esi!n temporal .
CO(ESIO! COMU!ICACIO!AL
Las funciones que act2an so"re los mismos datos se a1rupan. /or
e#emplo un mtodo que muestra $ re1istra la temperatura est*
llevando a ca"o dos acciones diferentes so"re los datos de
temperatura. Un e#emplo similar es un mtodo que da formato e
imprime un n2mero.
CO(ESIO! %U!CIO!AL
Este es el me#or tipo de co(esi!n. Un mtodo con una co(esi!n
funcional reali3a una sola acci!n "ien definida so"re un solo tema.
)s& una frase que descri"e con precisi!n el prop!sito del mtodo s!lo
tiene un ver"o $ un 2nico o"#eto que act2a so"re ese ver"o.
/ROHR)+)CION ORIENT)D) )
OI-ETO%
En esta forma de pro1ramaci!n mtodos $ datos que est*n
fuertemente relacionados se a1rupan en un o"#eto. Esto coincide
e6actamente con las ideas de ocultar informaci!n $ encapsulaci!n.
Los elementos pertenecientes a un o"#eto est*n fuertemente
acoplados $ el o"#eto en su con#unto posee una alta co(esi!n . Un
o"#eto "ien diseado presenta un par de interfaces simples a sus
clientes. Las interfaces son aquellos mtodos p2"licos que se
declaran para ser accesi"le fuera del o"#eto. )s& un o"#eto "ien
diseado muestra "a#o acoplamiento con otros o"#etos ' llamadas
a mtodos con par*metros de datos puros a mtodos con co(esi!n
funcional.
Los len1ua#es orientados a o"#etos animan al pro1ramador
descri"ir las clases en lu1ar de o"#etos individuales. /or e#emplo
aqu& est* la descripci!n en -ava de un o"#eto 1r*fico una "ola
que tiene coordenadas 6 $ en pantalla7
OI-ETO%
class Iall Q
protected int 6 $@
private int radius@
pu"lic void setRadius4int newRadius5 Q
radius R newRadius@
S
pu"lic void setJ4int newJ5 Q
6 R newJ@
S
pu"lic void set94int new95 Q
$ R new9@
S
S
OI-ETO%
)qu& los elementos privados $ p2"licos se distin1uen claramente . Una
tercera descripci!n prote1ido si1nifica que el elemento no es accesi"le a
los clientes pero se puede acceder a las su"clases. Lo que no se muestra
en este e#emplo son los mtodos privados que son utili3ados por una clase
que son necesarios para llevar a ca"o el tra"a#o.
La pro1ramaci!n orientada a o"#etos 4/OO5 elimina completamente los
datos 1lo"ales@ todos los datos son encapsulado dentro de los o"#etos.

Modularidad PDF

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

Modularidad PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

TEMA 6:

Anda mungkin juga menyukai