Professional Documents
Culture Documents
-:
-~,
"":;~=?==?:::.::::::==~======-
~--
--~--
-=-
------...:..:..:.
--. :-:~Jjfl~::~J:~!tJ~:~~~!1~~fr~~I!i~\~~~~~Jfth~~J~~;:1J~~~~it~~j,;~;~~i~~j~iij~;~i~:-~
Ehl~'b
ciJt
SO~ -k A-'2k
c<..e..
'
.,:,
<::--i
Cap_fulol
. lng~nicrb del soft-ware: Jn:rotluccin.
'
\'
'":' -<~,...,..4
. . . l
. . :- 1
:. :
1 '
.. :: 1
' . ; i\
!f
..
La_ ingeniera del'software es el campo de la c1enc1a de la computaGin que se ocupa de la '. '. :
- consl.r]Jccin de sist~mas de software que son tan largo? o corilplejos, que deben ser abordados por
uno va.-rios equipos'.-de ingenieros. Generalmet1te existen, mltiples versiones de estos si~temas y.
- se usa11 durante varios allos. Dll!ante su tiempo de Vi~a:, sufren muchos cambios; ya sea )ara ...c:-L - ,.-:-"~ . f
c~rregir defectos, 'eliminsr 'viejas caractersticas e; a_qaptarsc para coner'en un nuevo ambiente: -)~ --~~~;:~::~(:\_
:. ' Parnas (1987), defirii la inge11;iera deL software cdr:i.o la "construccin de un software .:.. << : :-~~;~
.f,
mull versin realizada por rn~ltiple~ personas". Esta defi?.icia captura la. escencia. de la ingenieria :t._. ;~ _,"~);~i::
del software y remarca sus :hferencms con la prof,TTanmci'I5n. Un programador escnbe un programa - . : '>!
completo, mientras que un ingeniero del software escribe componentes de software que se'
.: r
combinarn con otros componentes escritos por otros ingenieros para construir un sistema. El
componente que cada uno escribe puede ser mo.dificado por los otros. y puede ser usado para . ..,
construir otras version~s. del sistema ~? cuand~ y ha p~sado un tiemp? des~le .hdtalizacin del ,,.,__ '.<;~tt::-~)!-;;;fProyec~o. La programa.ct~r~ ~s. un a?lVtdad personal, m1entms qt!e la mgeruena del software efl _:} ; -;;:;:: l
escenCiaJmente una aCtlVldad. Ot: equtpO. .
.
: . , ~J-- ,.".:_.:(:~;< i
' El trmino "ingeniera del software" fu crear,lo 1!1 fines de la dcada del 60 cuando~!:::'::;_..
' . f
comprendi que todas las reglas aprendidas hcerca de ins maneras correctas Je programar, ~fi-:
ayudaban a construir mejores sistemas. Si bien en el campe> de la programacin se haban hecho
. tremendos avances - a Lrri~s dd estudio sistcr;lico de algoritmos y eslrU~'~uras de datos, y de !a
invencin de. -la "programasin es~ructi.1raua"- e;<istbn an grandes difcuitades para construir
grandes sistemas. Las tc!iiits usachts por un fsico pt;:i (e~o'lver.una ecuacin 'c::lifcretlciaLp,.<J.-a:-h!H _.,
expcrimc~lto, no se udec..:aban a las de. un progratnador que estaba desarrollando ~sisl~m~
operativo\) incluso un sim;;le sistema de contro: de.in,;elltario. Lo qu se necditaba en estos c.asos
era la propuesta clsica de la ingenier-a : ddi;1ir claramente el prob!emrr que se est tralandode
resolver, y desarrollar las hcrramiemas standard y las tcnicas para hacerlo .
. Sin duda, ]3 ingen!~:~ra del srA(w<tre ha hecho progresos desd:; los '60: Se hatt cstanariz.ado
tcnicas para usar en ese c.:mpo. Pero todava est muy lejos de alcanzar el slRlus.. de un discipliim
de ingeniera clsica. "tocbva qued3n muchas reas que se enseiian y practican sobre. las bases de
tcnicas informaks. Ni siquiera hay rntoc!os generales aceptados para especificar Jo que n
sistema debera hacer. Cuando se diseii utl sistema en ingcaieru elctrica-; lal como. un
ampli!cador, se lo puede: cspcci[c.:ar con exactitd. El usuatio y el ingeniero definen y entienden
con cln.ridad todos loB nrm.;tf')3 y niv;;les d::: tolerancia. En ingeniera del soflware, recin
estamos comenzando a cid:nir por un lado, cules deberan ser los parmetros de un sistema de
software, y por el otro- i.uta tare;:; mL~ciJo m<\s compleja- cmo espccfcarJs.
Adl:ms, en h:.s discipLnas <.le la ii1genieria Ci~sica, el ingenir~ro est equipado con las
herramientas -y la nw.Jurez matemtica para especificar las propiedades del producto
independienten1.ente de rtqu!ls del d.isefi.o. Por ejcn1pl6) tUl ingeniero electricista- se basa en ! -
ccuciones m::>.ternticas )<lia verifir~ar' que el discfo no vioic .los requerimientos de energa. E;1
ingc:nier!a del softwal"L:nJ :>e lmn dcsarr~lado tale:> herramientas matemticas. I~llpico ingeniero
del software se basa muc~Jo m{ls en la e;o;pctiencia y el criterio que en !cnias ~nutcmlicas. Si beli
la cxpcri ticin. y el crh.::.r;.. _, son !1:-!.e<:so.nos en !a prctica de ia ingt~nkra, (lfnbin son cscenc.ialcs
las herramientas ele ;mL;is formr.!.
El enfoque de e~ le Ebro, es que la_ 11geniera del software debe ser praclicada t;:omo una
uisci pliua ele ingeniera. Nuestra pro~uesLa ,es prc.sentar ciertos principios, que creemos, son
csccnciale5 para la consl,,_ccin de "un :;onvv<ir~ muLi\:ersin realiz:1do por mltip1es personas".
.-
,_
"
.\
) 1
;
. ',
,.,
'
,,~1'
~ )/
.
1
--. - . .
.. -- ---. - . - . ---- ..
- ._ .... :
.' -~---
~--.--:--
..
': : ,,,
,~~~~~~.li:ibq~"fh:f~~~'l,:E;tci;~~~~;t;;::c~\A~i:~d::.'i.iG:t~;;,<,",,;~,;,:'-'"~~2i:kf;~~-~i',;;;i: ..:2_~~:..;,;i''. .
(:.\.-): >: . .
. .: . . , .
: . ; . '. . : . . .
:~ . ::;,Pensamos que tales principios son mucho ms importantes que cualquier notacin o _metodologa. . .
construir .. software. Estos principios capacitarn ar ingeniero del software para evaluar '':/' ' : !--.
diferentes metodologas. y z.plicarias en el momento apropiado. El captulo 3 presenta los ,..
prifncipios; el resto del libro ejemplifica su aplicacin a distintos
de la
del . . ; :_.;
so tware.
En este. captulo, r~visamos la evolucin de la ingeniera de!' software y su relacin con
. ''
otras disciplinas .. La meta es poder ver la ingeniera del software desde distintas. perspectivas.
_:-:_ :para
problt~mas
<,::~,:. :.
ingenie~ia
,' 1
Un sistema generalmente forma parte de un sistema ms grande. La actividad de la ingeniera del .,.
software es, en co~ecuencia, parte de una act.lvidad de diseo mucho ms grande, ~n l cual los
n!qu~rimiento~ del software estn balanceados junto con los requerimientos de las otras parles del
sisiema que ;se est diseflando. Por ejemplo: un siste1i1a de comunicaciones telfonicas est
fonnado por computadora,s, . lneas telefnicas, cabl~s, aparatos telefnicos y. muchos otros
apar~tbs tale~ . como satli:es, tc.;
y finalmente el software que controla parte ele esos ...
componentes. Se espera pus, que ia combinacin de todos esos elementos, curnpl~ con. los
requerimientos de la totalidad del sistema.
_
_ Requerimientos tales como "el sistema no debe permenecer inactivo ms de un-segundo en
t.
20 aos" o "cuando el ustnrio levanta el tubo, deber escuchar un tono cada medio segundo" .
f.
pueden satisfacerse mediante la combinacin de hardware, software y artefactos especiales .. La, -:; t ~ :, . ,: : _,~\:; ~:
decisin sobre cmo se llega a cumplir con los requer:rnientos de la mejor munera se puede tomar.
lL,Iego de haber- considerado muc:hs posibles combinaciones. Otros ejemplos que muestrrin la
. ; :. :
\ecesidad- cfe'ver al~oft~var:~,:.como . r;;:l componente.de otros sistemas mayores son por ejemplo los
. c.
. sistemas de m o ni toreo ele l.lllU plantR de energa elctrica, sistemas bancarios, "sistemas pata In .
..
t.
administracin de hospitale~;, etc.
.
La prctica de la ingeniera del software de manera correcta, exige dar una mirada ms
L amplia sobre problema general de la i11geniera de sistemas. Requiere que el ingeniero del sofL~:vare
....
intervenga en el momento :~n que se stn desari.-ollamlo )os requerimientos inicial_es del sistema:
completo. El ingeniero de'Je intentar comprender. ei rea de aplicacin ms que. entender las
, .....
interfases que debe reunir el softvvare. Por ejemplo, si el sistema apunta a usuurios que se
manejarn por medio de u11 sistema de menes, no ser nada inteligente desrrollar un procesador
de textos sofisticado como parte del mismo.
.
1
'.''
'
Sobre todo, cualqu:er disciplina de ingeniera requiere un compromis<;>. Un compromiso.
clsico tiene que ver con la definicin de qu deb.e conseguirse mediante .el sofh~are y. q~
t
mediante el hardware. La implementacin del software ofrece fleyjbilidad. rhientras que la del ' J
.
hardware ofrece performaHce. Por ejemplo, en el captulo' 2, veremos el ejemplo de tma mquina .. ,
1
operada con monedas, d~beremos decidir si tendr varias rant:ras, para Jos distintos tipos de ;
monedas o una sola ranura, dejando que _-el soft\vare reco'1ozr::a las moedr!.s. Un com_jJromiso an , 1
ms simple puede ser el t_ener qu~ decid( qu procesos deben ser aulomuzadOs y cules se harn .. : !
. 1
7
'
:.
en forma manuaL
1.2 ll is to ria de la ln gcul
'.
-:--~---
iii;!~}])Wf~i~~ 1
.. ;
.. ;.; .:->:;:;,~~~J
...... =---
'
'
"'7. --- -----..--:--~:-- , ... -:: , : - - : ........ .---. ,.,. ___ ... , . :- ._-: , ~-. -. . . . . . . . . -- -~ ~- ,
,,
'. e
~.' ~ ~
o
- ,''
. ..
'.','1' ''".,''
"' "'"
'
: .
.!
\j 6; : .
: .
~-_:-:/
~. ':.~L:.-:'~:,.:,;':'
.i.J__:,.,_:;,,,
.
~-
,l,,ii
.;~ _-:~: ..
.. ~ ._. -- ..
'
'' 1!
- ~9
'--:-
..
; -:
' 1
problemas que se progrmaban se entencan: -con claridad -_ por ejemplo, cmo resolver una
ecuacin diferencial. El programa lo escriba por ejemplo un fsico, para resolver la ecuacin que le interesaba. Et' problema estaba entre el usuari~ la computadora; no estaba involucrada ningm1a--
~~~~
_,
';::: :.{J!
~
.
1
la
1."'
'
'\
.~
~)-'
J
)
-
.,
_)
.';
........
-~.
(__;}
(\)
;
-\
o
i(''
1 --
OlO
Jb
<
Q
o
:Q
@
G
; ()
o.
:o
(_
e
,le~
,1
._/
._:j,
1
'!
' .
. "l.,':--],
..
- - . -
. . . . -
"".
- : : : -.-:
.-~:"_': t.-:-
.. :~: .. ::_{:.:::,_:~::;_~~- _:
::-.t -:- ..-- :~--: :.... . ":: :~ ,~ ..~-... :..:. : _:~:-~:~~~~~~~!.~~:;:~' ;~;~
('') ' .
:r-: r ~
;"
<:
<'"~
::..
Ahg ....Ctrhzwe;{;m.e6.e
. .. , ..
-;_.,...
;;;.._~-
'>
.~
l~\ ~
'.~
,;
.
~requera direccin, organizacin, herr~micnt:s,~s, n~todologas y ~s. Y a~ naci la. ,!~~ -'.
ngeniera-del software:_
. ]
-
La historia anterior enfatiza el crecumento de la ingeniera del soltware desde la : ! ~ ~:
programacin. Hubo tambin otras tendencias tecnolg.icas que jugaron roles in1po.rtantes e11 la .. :.
:
evolucin en este campo. La inuencia ms.importantt:. fue el cambo que hubo en
relacin de, . j .. : :":,;~.
costos entre e~.:so.ftware y el hardware. Miet~lras que el costo de un sisterna compt!te~rizado estaba ~;._-. ;.,'j'.'_,~KiiN
def!-jdo mayonente pcir: el costo del hardware, y d costo c!el software constitua Ull factor.: :; ~;;~-~~.::i;,],i"_},~.~;?(_
in~i.grriicame, hoy (;D da, ~1 costo 0<;! s0n'l.'9p~ :fltwde significar ms de la mitad del costo total del .;
f:-:~~ 1:<i:
sistema. La disminucin del costo clel harc!\-va: ~ . : d .:;,~.::;nt;; Jel Cf'l<:10 rl-:1 ~0ftware !1~. ircEnaC:-; la ;:_'i.'~':"":: ~.:: _; '. 1
}
?ala~a en direccin al sof"Iware, poniendo un nuevo nfasis ~con~1ico en el de~arrollo de la.
; t .,:;:~ :~-)~~mgeruera del software.
.
.
_ ."
r.;,:.\ '(j'f.',:
Otra tendencia evolutiva ha venido des-de dentro d~l propio campo de la ingeniera dei
: . :; l
software. Se com~-tlZ a poner nfasis .e1i considerar que se trataba de algo ms que "codificar". En
, !
la
'JVr::i:\
..1
:' .
~.==
:_,~. ,-''~
cambio, se comenz a ver el softw.are como poseedor de un ciclo de vida, comenzando desde la
;
:~.:. ?:'.~;'. !1
concepcin y continuando con el disei'.0, desarrollo, implementacin, m~mleriimiento cvo'Iucin. . ; : ;:: ;
La disninucin del inters en la codificacin, alent ei des~rroilo de rri~todologas y herr~rnientas : ) .. _.:;;;.,;!
sofisticadas para apoyar a lC.s equipos involucrados en el ciclo completo de vida del softwa;e.
. ..... ::::-_. ,"_; .: ,i
Podemos esperar que la importancia ele la ingeniera del software contine crecierK!o por :..:, ;
varias razones. Prit:~ero las econmicas : en 1985 se gastare:< :1lred~dor de U$S 1L10 billones et1
software r-n todo el mundo. Se anticipa que los costos de software superarn en 1995 los U$S 450.
billones. Est~ hecho solamente asegura que la ingeniera del softwar-:.: ::::~L~;:;- como disciplina.
Segundo, el software est penetrando en la sociedad. Cada vez se utiliza ms software para
. controlar funciones crticr.s de diferentes meanismos tales como aviones y apmatos pllra- la
nicdicnil:: Este J.J.~ho asegUia el inters creciente de la sociedad en software confiable, ep la
creacin de estndares especficos, requerimientos y certificacin de procecli.rnientos. Sin eluda,
seguir siendo importante prender la mejor manera ele construir mejor software.
l:_;'_:_:.:..:'._:__
_)
.,
,,
La evolucin del campo ha definido el papd del ingeniero del software, la experiencia y la
educacin re'queridas.1fu..ingeniero del softw~be s~or supu~_?to, un buen prograr~ador, debe
~~9-EL~SilllClU!~-~e datos__ y al_s.~itr::~os,_x__~nanejar con fluid~~~<:.__O ms l:_:~S.:~~-~.s_de .
programacin. Estos son rt:querimientos para "programar en chico" es decir,
coistruccin de
~-------- . -- ---------- ----- ----. -~----------------programas que pueden se: escri los e:!1 su totalidad pot u!1 nico individuo. PerS?._~p_jl)g~nier.q_~~J.
software tambin ~a-_~v~li.Jc@.~l~t.jw._~rC?.f:~itnac{qA.--~~-=~gtand~"'
sta tiene otros
recueri mi en los.
..-- El ingeniero del so ftv,_a!:~!l~~~- e~~~~.[~~!!.Jil0Ii?~t-~9.-c;;s>B...c!~feren~~P.~~: d_iseo~~l?~ . :
. e~ tar c<p~~t~..9.?.Y~r:_a ___ !!..~::~~.!:_req~_:::runiento_:;y,..sk?.tQ.:LY..a.g~E,_~_s_peci.fl.~?.S!.J.J.es.pi:~.~~s_-S,_Y-~~-b~ ,.
-sabr-conversar con el us1.1a~jo en trmmos de la aplicacin ms que en trminos computacionales. ... .
,;-z. ex.ige ne-:.:15111daCf y-a.Jerflirara.'raeEten.Ciery ..co'CerTaescCI-adeTs-diferwtes.. :...
reas de aplicacin. El ingeniero del software debe poseer habilidad para mqverse entre distii1tos ":-
ra
---
:y
~;
.Ji
.'/ ,
:
src;:-a:--su
1mali1ei1te-e.I1ilvcl--~Jef
---
,. '
___
_____________
:;.----
- . . . 1,
1
'-.,;'
.
C.:
O
_ , .
o0MO 00 - -
-OOOOo- . .
00
jO' 0 ' . - , _
' ,
--~:
.
00 . - -
.
-
O O
-,-::-.,.:-~:-:---~'!"0'0 ,--~: :
- : - - - : 0 - : 0
~--.
- 0 - 000
000
O O O
000
- : - - . . , . - - - 0 0 0 oO
!'
00 . . - : - - - - : - . .
",
.. ..
'
lo 1v ...
/.
.
O o
...
,.
,, .... -;
..
.. :
:-
: .,_..
~.
....
''Codificacin y testeo de mdulos .. Esta es la fase que produce el cdigo real que ser
entregado al usuario como el sistema para ejecutar. Las otras fases del ciclo de vida
tambin pueden desarrollar cdigo, tal como prototipos y rutinas de prueba, pero
stos son para uso del desarrollador. Tainbin se prueban los mdulos individuales
desarrollados en esta fase antes de entregarlos a la fase siguiente.~
.
.
* Integracin y pnieba del sistema. En esta fase se integran todos los mdulos que se
probaron individualmente en la fase an'terior y se testea el sistema completo.
'
* liber~ci'l y r:Jar:.t~:::nimient0,. Un::1 vP.z que el sistema pasa toda? l~s pruebas, se lo . .
entrega al usuario y-::::~:::. .::nlc: ,. i."'~'<'' (k. rn~.;:..:r:irr:eni.:. Cualquk: rnoJicacin que 5e
'
.......
1. . :~
: :::::
' ":) 1 .
.~':;~~ti:
: :
. La figura 1.1 da una idea grfica del ciclo de vida de desarrollo del software, y provee una
exi)licacin visual del trmino "cascada" utilizado para defio.irlo. Cada fase produce resultados que
"~uyen" hacia la siguiente y el proceso contina de una. nianera lineal y ordenada.
.. 1
"} ..
~.
,.
.:
....
~-.
.'
;_::::
,.
.:
.~
;".
; .
Una terminologa c::Jmiln. distingue entre las fases altas y bajas del ciclo ele vieJa del
software : el estudio de factibilid01d, el anlisis de requerimientos y el diseo de alto nivel
pertenecen al primero; mientras que las actividades orientadas a la implementacin pertenecen al
ltimo.
Tal como' se I:J present aqu, las fases clan una vista parcial y simplificada de la
convencin que define el modelo de cascada. del ciclo de yida del software .. El procesq pl)ecle:
descomponerse en diferent~s conjuntos de fases, con nombres diferentes, propsitos diferetites y
diferente granularidad. Es :;msible definir esquemas .del ciclo de vida completamente diferentes, no
basados estrictamente en el desarrollo en cascada. Por ejemplo, est claro que si algunos tests
descubren defectos dd sistema, tendremos que retroceder-por lo menos a la fase de codificacin y
!al vez a la fase de diseo para corregir algunos errores. En general, cualquier fase puede. descubrir
problemas en fases previa:;, esto nos obligar a volver atrs hacia fases previas y rehacer algn.
trabajo anterior. Por ejemplo, si la fase de discfo desc.ubre hc.onsistencias o ambiguedades en los
,.
requerimientos del sistema., deber revisarse el anlisis d~ los requerimientos '-'jJara comprobar
.!
_,
Otra simplificacin en la presentacin anterior, asume que. cada fase se,eompleta antes qu
comience la siguiente. Er. le prctica, es a rnenudo conveniente comenzar una fase antes de que
finalice la anterior. Esto p:.1ede ocurrir por ejemplo~:_si-igunos de los datos pala: completar la fase
de requerimientos no cst<:.rn disponibles hasta ~el1tro de LUl tiempo. O puede suceder que las
personas que realiz::un b etapa siguiente se :,encuentran disponibles. sin nada para hacer.
Pospondremos estos y otros temas .relacionados cqn'!=] ~iclo de vida del software hasla el captulo
1
7.
-'Y
. (','
...Ji
. :'' '.-
:;r1
.. -.
1 '
'
~ ,. ~ , . , - ---; - .... . ~. -
r "''."::." '.:-
O .... .... -
------~~---- -~-
-- ,.,. - -:- ; : :
.. .! ... ~ ......... .
;:-:
. . . . . .. . .. '.
~
.;::>: .. :- ..=: .
-~
........ 1
: i
~ :~ 1.
.'... ...
!.
Como se discuti antes, el ingeniero del software tiene muchas responsabilidades. En la,
. i . . .
prctica, muchas organizaciones dividen las responsabilidades entre dif~rentes specialistas, con : .., . . _
diferentes ttulos. Por ejemplo, un analista es responsable de relevar Jos requerimientos, y un. : ..
1
;,'~/
l ..
...
.,.
\ ,:( :
Desde qu~ nace la idea de hacer un sistema, basta que se lo implementa y se. entrega al usuario, y
an despus, el sistema sufre un desarrollo y evolucin graduales. Se dice que el software tiene un
i.
i
!~ :
.. .;Jif&~.;:,;:i::J~;:~l)~:Y(~~:)iii!!;-> t
::
generalmente
la pi:iri1ra:'fase de:.ri;pr;o):~:(cr'de'desarrollo
de
software en gran escala.
.
. . . . 1 : .
'. . o:J,. ., ": ."' ..
!;~.:-
;, . )
' '
; ":.
.!
-~.
...
:)
:x
J
.)
~J
\...J
1.:..)
,.,
1 .
que
ia dicotoma "q~1e/como"
. - ~-~--~~-- ----~
. ..
~
..... ,
(;.~.
'
:.,t~ '~
' -..
.:--::---
'-
. '
'
.t
. rnuy bien desarrolladas - p<:,ra el desarroilo del sollvvare en ger1eral.- Por ejemplo podemos usar la ."--;. --~
gramlica para definir la sinlaxis de la interfase y :malizadores-generadores para verificar la
_;
. c~n~istencia y la falla de ambiguedad de la interfase 1 y automticm~1ente generar .el front-enel para '. .
;- ...
el s1stema.
Las interfases de usuario son un caso especialrnete interesante. porque nos hacen ver ia
. . ~:;;;;{
influencia en la direccin opuesta. Las disc~1siqnes ele ~a i11ge11iera del soft'0'are girando_ alr~dedor ,'
de las interfases de usuario fueron posibles por la difusin del uso de imgenes de mapas de bils y . . -~:~,~,J
1::ouses e:"' h'Hl ):r:y;_;ca ~ l:Js lenguajes r:ie .programacin a trabajar en el rea !e los lenguajes> _ ,-.
",vtsuales" o ".;i:.:~ricos''. Estos lenguajes intentan capturar la :;emntica 1:e'. mailejo :-:<".ventanas.,._ , . : .>:.
(windowing) y los paradigmas ele interaccin ofrecidos por los nuevos y sofisticados -clispositivu::, :: . :. ,\:./ ..
ytVff:
grfi.co~dems, otra inOuencia. de los lenguajes de pro~~amacin sobre la _i;1geniera ~lel soft,~a;i:e, . , :. . ..,'.H:,
'
'
'
...
'
.1
..:.'
,-.
.:~ 1
'.
~'-;,
Otra influencia proviene de los dos elementos. ms importantes del procesa1niento de
lenguajes - compilacin e interpretacin - que han sido ampliamente estudiados por los
diseadores de compiladores. En general, los intrpretes dan mayor Oexibilidael en tienipo de
ejecucwn, y los compiiadores ofrecen mayor eficiencia. Cualquiera de los dos criterios es
aplicable generalmente a cualquier sistema y puede pasar a ser una herramienta ms eh la caja de
het'ramienlas del ingeniero. Un ejemplo de su aplicacin fuera del rea de los lenguajes ele
prograrnac.in puede vers::: en el campo d;; las bases de datos. Las consultas que se realizan sbre
una base Je dato's, pued=:1 ser. compilac.ls o it~terprctadas. Los- tipt:rs c.le consulta. ~i.s comunes se
compilan para asegurarse la rapidez en la ejecucin: 'tntes de hacer cualqui;.::r cunsulta al sistema,
ste detenoina el c:u_nino exacto ele bsqueda usado por la base de datos. Por otra parte, como el
diseiiador de la base no puede pre-determinar iodos los tipos .de consulta, es posible realizar
cons:.:ilas ad-hoc, que requieren que la base de datos seleccione el camino de bsqueda en tiempo
de ejccuc[n, tas consultas ad-hoc lardan ms en ejecutarse pero le dan al usuario. mayor
flexibilidad.
("',
\.
..
(~
-~
\Y
.o
ca
lc
La influencia de los sistemas operativos en la ingeniera del software es muy fuerte, principalmente !
porque los sistemas operativos ueron los primeros grandes sistemas que se coristruyeOn, y adems '
fueron los primeros ejen:.plos de softw?-re que deba s~r "ingenierizado". Muchas ele la$ primeras . , ..
ideas de diseo de softwe smgiercin de lo~ pLi.meros intentos de construir sistemas operativos. .
Mquinas virtual:::s; niveles de abstra~cin y la sparacn de ia poltica, del mecanismo son ;.:'
conceptos desarroiados :::11 el campo de los sistemas operativos con aplicacin a cualquier sistema !
de envergadura. Por ejemplo, la idea de separar una ")oltica que. quiere imponer un sisiema. ,
operativo, como la de as:~.s'Lirarse la
interferencia entre procesos, del mecanismo("time-slicing'')_:::
usado para manejar con xito la concurrencia. es un: ejemplo de la separacin entr_e el "qu" y el
"cmo" - o bien de la. :~spccificac.in
la in1ple:i1entacin - y de la separadon de las parles
intercambiables de lo qt:e queda fijo en un .sis~~:11~.La idea de niveles de abstraccin es slo otra l
aproximacin. a la mod:.darizacin del diseo :m{ sistema.
'
. : . 1.
En la :direccin opuesta, la in.h~e~lc(a;J~;:i,la:~_inge.nie.rla del software sobre .Jos sistemas
operativos puede verse tanto en Ja man~ .. 9n):qt!. :se estructuran estos sistemas como en los . : .. 1
no
de
de
<t >
~d.i\i_;:
_.:: .: -
:..::_::'[:o_;J:,:.f:
_,_../\
..
. - ....
-~
--:t:r' ;.
~--
:. .... r:
~:-.,.,,::
r-::-
.. ......... ..
-~----=
--:: ':'-
-~
~-::-
_ ..:_.: .
.-..c.. .
.. : :, ; ' . . ..
'; .
act~erdo
{'~,;
. 1'_i.s La
computaciOn.
l;
:,.-.~.:. 1/~\.:;.>,.:::
:.~:~,J?iirt~~:;~q"- ~ : .
un
:.:
.._::..
..
...:!i[.:::'..
. ..
~.
.. .
, ) .5.1
.. La nfl uencia de la ingenra del softwari'.e'ir os.,. 'bgujes .de programacin es bastante evidente.
. . \: -.
Los lenguajes de programaCi'n sori las.~~b:~m:\WE~~~:t,:t.f~c!~~les
:er'desarrollo del software. Por
.._, . ,
lo tanto tieJlen. una profw;.da influencia' sobr<f)t~}p_osib'iljd(\d' ele alcanzar con xito nuestras melas.
Por otra parte esas metas i.nf1uyen sob.re~8~sa'd!Jo:'(to~ ienguajes. de programacin._
'para
;..,
-'
r- ..
1\
1.
~: ~.:
. ,.. ... _
;~=:1
;t.J..
~
'
~~-'
l.-.
!.
.......
'
~ l.::;
lll(".
;1.;:
" ..
' ( :.'
! ..,
iC
~.("
}~. ~}
.;-e~
de
l. .. ' ....
. . /:.'! :. ;' :.
',
.-.
. .. . .
-r"':,-o"'''"':'"'w--
""'-'"-w--
.. -
. . . .:'f~;>G:i
'
~~;_ : :~: .:
. ... .:
~~~~~~ey,~~~~~~~:~~~r:it:f!I~;,r,i;~i~;Y;:s?'F':1~;1G-.s;:;,::.:;;::.;;,:.;t~:;::~~~~;:"',~';='~:..,~,.,"'>;;;,,,;,k~"~-"-"~.::.lf.LL.,.:,:.-::iL
' ._
41':,/1./~l
1QJ!.Y
\ '
'
..... ', .
., 1 .
' ...... ,
::
~;.::..
. . ;,, .
'.. ~bj~tivos que tratan de sat:sfacer. Por-~je:n;~~~- . .~1 ~istehi~ operativo UNIX intenta proveer un ,:'. j ; ~-:..::;.:2
ambiente productivo para el desarrollo del software>
clase de herramientas provista por es le .,: . '.. ::. ::.
ambiente, soporta un mam.jo de la configtiracin d~l software - una manera. de mantener y
Una
~~~-~t. l..~-
) .. -... -.......uevamente)'y los sist~nas. operatl.vo~.. qe~:~s'tlti:. disellados para contener un pequeo
':
. : .. .. ',:;,protegido'_'
' .
. ;
kernel . : .-...
!;.. _';..
qu~ provee' u~ mnimo. ~e ~~~ci.~J?.~~~~~. ~;~t~ }~1ter~ctuar con ~ hardware y ~na parte,~ .<+,:f:\.~f:i~-
'~no proteg.da'~. que provee la ftmc~ona~1qad a.l!-tep?[~~nte .,asqcwd_a a los s1stem~s operat1 vos. )?'or. ,i) :. .: :;
;;r
~sti~d_o c~mtro 1ar el' esquema de pagiiiado, q~,e, .-, :- .;~:~::.:/;. ;;;:': ,-F
. tradicionalmente se consideraba parte integral ~el.sistenja operativo. . ,
.
. .
. . .: ..:; .. ._, ., -\ ;'
-!
.. En forma parecida, en los primeros sistemas operativos, el intrprete del lenguaje de ; /'~.;
~01n~ndos, fonnaba parte. integral del ::sistei1).~. ,.Hoy, est cotl.siderado simplemente como un ..
u'tilii~rio m~s. Esto pei-mit~ por ejernpl_?}ct~t.s~4a usua:~o tenga Ul~a v~rsin p~rSO!)a!i~ada del' ' : ..... ,
:. i~~trp1:ete. ~ri muchos sistein~s UNIX ]?.ay 'pcj_r)fiJ?.e~g~ .~res intrpretes: distintos.
.
'
-~~:
y:
}:~:
!:.i . Y~;~;~:~~sc~;~Ma
tos. ,::,; ; ;:l~*~i;~\!~J:~:;f~!:ti;
.:. lf. ~~~ .;. ~ , :- .l:!'~.'.:' : ;, ~.:''1\~f.;~~ ~t.rl~tt; ~~r~/:h:~~:
- -
1:
f:,; :r;tlh'
\;
1 '! .i .,:: .
;1L: '
' .
..
.;
de "independencia ele .. ;, - .:
'~:-
'',~,.,t~;:t'f":-l,l)1,1f1'~',/'\'t\r:ot',,:'"lll,
~,,,o.
. .
. datos", que es .9tro ejemplo de la separ).ci~-~~.:d~:la;'esljetpcadn cleta. {mplemelitridtt La base de :.. : -~: .. ~.
. . ;: 'datos permit~ 'escribir i)licaciones ;'Cjue.:::t~~:ii\J9f.tat9s 'sin preocp~rse por la represenlaciti
. . . . . ..
.
Otro impacto inte:esante de la tecnologa de bas de datos sobre la ingeniera del softw~u-e
es el que pennite usar los sistemas de bases de. datos como componentes de sistemas de rnayor
.tamaf.o. Desde que las bases de datos resolvieron los lllUChos problemas asocin,4os al manejo de . . . . .
. . ~ccesos concurren les a grandes cantidades de informacin por mltiples usuarios, no hay necesidad !
' .: de re-inv~ntar, estas soluciones cuando construimos. un sistema; sir:pplernente. podernos usar tm
sistema de base de datos :!xstente como un componen le.
.
.
.!
1
.
Otra illiluencia interesante de la ingeniera det' software sobre la tecr1ologa de bases de
datos tiene. su origen er1Ios priue~os intent<;JS de usar bas~s de datos coino sopdrte de los ambientes
de desarrollo d.e software:. Esta experiencia demostr que la tecnologa de base de datos tradicional_.
'. era incapaz.de manejas bs problemas generados por los procesos de la ingeniera del software. Por , ! .
-.. ejemplo, las' bases de datos tradicionales _no pueden manejar bien 'los siguientes requerimientos : '
. . . almacenargra..ndes objets estructurados, tales como programas o manuales de usuario; almacenar
grandes objetos no esl:ucturados tales .como cdigo objeto y cdigo ejecu.lable; mantener
diferentes versiones de .m mismo objeto;. almacenar objetos tales como un pro,clucto que posea
. campos gra.p.des, estructJrac..!os y no estr~tcturados, que pueden ser cdigo fuente,' cdigo objeto y '
rnanualdel tisuario.
'
'
. .
1
Otra dificultad t.iene que ver con la ,longitud de las transacciones. Las bases de datos
tradicionales soportan trrrnsaccicecs co~ias como por ejemp[o. un depsito en una cuenta bancaria o
\17
.
A'/
un retiro. Los ingenieros del soft.vare, por su parte, necesitan realizar transcciones muy largas : un.
/
i /
ingeniero puede querer. :~jecutar tma larga coinpilacin en un sistema mull-mdulo o puede querer ! .
'\' .' ' . ...;:.:j nD ~~ncia':~~s:: importi~~f6' d~. las_. ~;if~g{1 a~dA"t~;,est <d'~da'' p6r j'~ ~o'dn
: \ : . ; " .
"~(.\
,_... ,
1..-
.(-)
C.!
:e;
..:.-
o'(ll1
lo
,'.,,
J..)
.;
jU
C:
1()
(j
(:~;
r.
:o
C
...
'("'
1 ';~
C".
: C.J
'; ("
r .l-J
o ...
!.
: .: .~ :
iC
,.
.l ..
~
(''
;~ ( :~,
!:
-,(j
-,~-
00
..
lC_
, '
...
;r~
~~
,'.,,
'
. ;./
'
1
- .
-- -' ': -~-: '
"t ,'
~.::~
:, .. ,~.:
~~'=',
'
1
l'';'
0
''":':''\
'"
~:
. : -- < :":: .
.."'
g~nieri ;:!j~~
encuentran
entre
Jos ms complejos que se. han desarrollado. Pero difieren
de otros sistemas de. ~,=::L{ff:~:
jj
'
.
.
. ' J , .,
manera muy significativa. Tpicamente, un sistema de inteligencia artificial se construye slo con .
:,-:~. ':,',?r\E
ttna vaga nocin sobre cmo debera ttabajar. : El proceso', seguido para el desarrollo ele estos
fic:
sistemas se ha denominado '\.l.esarrol!o exploratorio".
.
: ,_:
Este proceso se opone a la-ingeniera del softw<i.re tradicional , en la cual, avanzamos Jando
pasos bien definidos y tratamos de producir un diseo comple.lo antes de pasar a la codificacin.
Estos desarrollos han dado origen a nuevas tcnicas para el trato de las especificacioJles,
verificacin, y razomunier!to en prescencia de la incertidumbre. Otras tcnicas aportadas por la
inteligencia artificial incluyen el uso de la lgica tanto en las especificaciones de soft,ivare co1~10
en los lenguajes de programacin.
. .. ..r
La orientacin lgica parece llenar el espa~io entre la especificacin y la implementacin
Clevando el nivel de los lenguajes de implementacin. La propuesta. lgica para la espe~ificacin y
'. ,
la progr'ainac'.. tarnbi1i hn sido Hamada declarativa. La idea es declarar las especificaciones o
requerimientos en lugar de especificarlas de una maneia procedural : la escripcn tleclarativn
ser entonces ejecutable. Los lenguajes ele programacin lgicos tnles como el PROLOG nos
ayudan a seguir esta metodologa.
Las tcnic~s ele la ingeniera del soflware han sido empicadas en !os nuevos sisLe1nas de
inteligencia artificial, por ejemplo en los. s.istemas expertos. Estos sistemas esln modularhados, .
con una clara separacin enlre los hechos "conocidos".. por el sistema experto y las reglas usadas .
por el sistema para proc,~sar los hechos - por ejemplo,'
regla para decidir, ,el curso de una' .
accin. Esta separacin ha permitido ostruir y coin~rcializar "mdulos ele sisterr1as expertos" que. .. ;
_...
incluyen slo as reglas. El usuario puede integrar el mcl\llo a la aplicacin e su inters inclicumlo ~ .
los hechQs especficos a considerar. La idea e:; que d usuario provea la experiet~cia general sobre la 1
aplicacin, y el mdulo aporte los principios generales sobre cmo aplicar la experiencia a , ':<!
.~
........ cualquier problema. . . .
-_:;.,'; ..' . :: ....:.:.. ~::.... ., .. ... Ei1..:-a. ,jnterscc:-~i~n d~ la ... !~gen!cr.t~r:.Ael . sp(t_y,i_a,re c<;>n la "inteligencia artificial .~~ esl . ,
(;J.:< .:.:_::.::~:.:-:.~~(o.<Juciep~{::~ii~ cl~e:}_i.~r.?nte\:c~~i:;.~iibisr~;::.:s.:. ~_sta1~:.. aplic_a_nd~::,:t6cni~as :de la inteligencia -; !.. . '
() :'' . :. . : rtificial ,pa1. J~1ejor'ai-'.tares propias de la. in.geniera :del 'sofl'\.;~~~e~. Por jern.plci, se estn -~/: : (
tf~:.
~. :d~sar.rollando i ,asistent~s. d .progr~i11at'i9h.'; l~: que. actan.
:~iesor~s: dd .:)rogr~~nador,::_:/_::::--_.:;:/t
~ . .. :.: ..:.: ;.. .coi1t;:~ !a11d~::~~~ruct un~.~:_de: progra111~i.~.~i / . . {eq~ff.1ij}l"~t?s. dh sis te~ a .. tal~s .:" sistei1 tes" han. sido ?/:;:::~'':t':i~:;
1
0
r.
~-
una
corno'
. . ..
.!
.~ ;0...:~: /~,:,'. : . \./ ,: ~:::h~~:,#.~t,~:t:~~t;;::~~~:~S~~!At~f~F~;),:\1?! prueba del software desniJOIIado, es. de.ci~ f:'J::r~[ij/if
: .! , ';.
'-~'.
C
1
e, .. . ;
,.1
/
: ':: ; . . . .. .
.'.
..
...
~.
. . .
.1! ; .. / .
~~
. .. .,. :. i~~~;: {
1.
1'
'
. '..
La teora de la cieqcia de la computacin ha desarrollado una cantidad de modelos que son'' . . . :...~ r.}: ~'
henamientas de gran utilidad para la ingeniera del software. Por ejemplo, las mquinas de estado
finito han servido tanto como base pala tcnicas de es:;ecificaciones de software C<?mo para
modelos de di.sei1o y estru.crura.. Los protocolo? de comunicaciones y los analizadores de kriguajes'
han us~do mquinas de estado finito ~omo modelos de procsamiento.
.. .
Tambin se han usac~o autrr,tas "pushduvvn" por ejemplo, para especificaciones
oper~ttivas de los sistemas y para. la constntc~in de procesauores para tales especificacio~1es. Cabe '!'
{~sealar que los autmatas 'pushdovm". surgieron de los . intentos pr:icticos para construir.
~--~
analizad::Hes y compiladores pam los lenguajes de programacin..
'J.
'
. 1
de.
es
ing~:.uicr::
En las secciones anterimcs examinamos la relacin entre. la ingeniera del software y otros campos
de b ci~ncia ele la con;put::.c.in. En esla secc.i6.1, exploramos la m<n:era en que la ingeniera del
1
sow:m:: se relaciona con 0'.!2.S re<~s fuera deJa cc;1cia de la comDutacin.
La ingeniera del. sc~f!warc no se pn:ctica en et vacio. Ha;, muchos probiemas que no son
pwpios de la ingeniera de:. son ware y que h2..n sido rest.:cltos en otros can< pos. tur:;go se adaptar_on
....1
l:1~
psicolog:t y el diseo indu:;t!iat pueden guio1rnos para desarrollar mejores iulerf;ses Je usuario.
soluciones. As, no ky m.:ccsidr,cl d'3- reinvcnlar cada solucin. Por ejemplo, las re::ts de la
.1 !'
-j
....
j
. _.
.;
_ .1
U::ty una gran parte de la i:gcniera del software reiacionada con lemas de aclm.inistrncin. Dicha
::uJministraci1i presenta t.bs a:;pcctos : admini.:,~racin tcnica y administracin de person11l. Las
l:trca:; cll: cualquier proyecto ndministralivo incluyen en general : la estimacin del proyecto, el
):!\nL~amicnto, organizr,cin ck .iOS r~:cursos ht~!llanos,' descomposicin y asignacin de t8reDs, y
_/
1 .
':;;~;7:);,:=-~<:
-~::.',::::<< :::-.::~_.:;.;::;:.,:
iir?W.gjsieni.e;.;41.;.;,";.j,:;;.; .;e
.:~-,-:,-.;.
-. .-.,
, ~~~.:.. .
':' 1
:._
.'
.
' ''
:
_._.
.":..
La hiptesis es
que existen cier:t.as leyes que gobiernan el comportq.miento de cualquier sistema complejo formado
por muchas compone11les con relaciones complejas. La ingeniera de sis~emas es til cuando
deseamos coi1ccntrarnos en el sistema y no en sus componentes individuales. La ii1gcnicra '.e.
sistemas trata de descubrir Jos tcfnas comunes que se pueden aplicar a los distintos s.islemas- por.
ejemplo, plantas qumicas, edificios y puentes.
.
El sofl\.vare genera\;ncete forma parle r:!e un sistema ms grande. Por ejemplo, el sortware .
de un sistema de control de [abicacin o el software de vuelo tk un avin son slo partes de
sistemas ms complicados. Se pucd10:n aplicar l<<S tcni1:as de la ingeniera de sistemas al estudio ele
(iichos sistemas. T!-Hnbin podemos considerar' a un sistema con miles de mdulos _como un sujeto
Tiue ser candidato a la apEcacin de las leyes de la ingeniera de sistemas..
.
Por otra parle; la :.ngenicra de sistemas se ha enriquecido expandiendo su coi"\iunto de
moddos de anlisis- tradicionalmente basado~ cr1 las :>l<emticas clsieas- xtra incluir modelos
discretos que se han usado en ln. ingeniera dd softwar:~.
'/
. .:
..
'',;
.'
1.7 Conclusiones
_j
.,
1
La. ing-,:licra del softwar~~ es una disciplina emergente. Consiste en la construccin de grandes
sistemas ef~.:ctuada po; equipos de programadores. }.-lemos visto la historia de su evolucin:-,
presentado su relacin con otras reas .Y descri plo l'os requisitos ele un ingeniero del software. En
este libro, estudiaremos l::>s principios que son escenciales para la co1itrucciu del softvvarl! por
medio de.Ia ingenicri<l.
...''
:_:1
,...
. 1
C;
1.
.. i
.
-:
:."'
..................
-'":"
.. ...: ..... ,. - .... : ----- -- ... . ... . . .. .. . :. -:"!--- ,.. _.: .. -~ ..-
.-. --.-
:-:-=;~--~,---
\1 ..
. :<-
!"' '
...........................
...... :-~- .. .. .
o';
:~
1 ..........
.-.
:
..
. ..::.
.. .. : ;_
..... .. _;:
;-
..
~.;:.. .
..r~~~~f~~.0:X~tt~ii~::i~~;-:;f~:Jli1~~~~-~;::;~~~;i,,j:;:~:;{:;~c~~L~<f;'t~zj,:;~-:.,:~:!r~,:..~'"'.Ok,, ..~:,,",.....~LSiJi'2:2;~:
''-'''
:.:
.1
.:
,~
......
(~).
o.
j(:-.
.~~
c?nst~11yeErnln p~ente, del tn~en.ier? ~erodes pacftwiat construy~' ~t avi~, y .eflt;inge~ieNro electricistda, utn
c 1rcuJlo.
proaucto e 1a mgemena e so are es un S.! S ema a e so :ware . o es un. pro uc o, .
tan tangible como los dem.s, perl? oCleJa de ser-llil pro~~ct?. Y c~Tet:ilafncin:..
. ' ;
En algunos aspecto~. lk.Jllildiili.tos O.wo.ffwa.~:e s~~~ similares a ot~?-~--1~!.<?.~~.::.~?~. -~~
ingeniera, pero en otros son muy diferentes. L::':.5:~E.~~~~~J~.f.i.~;;,_que lJ!~~-~epara alsoftw-r.t_d_e ot[_Q.S
pr.QQ.~_t:os ~_ing~err-esque-es'/'Zi'Ofe. Podemos modificar el producto con cierta fac.ilitlad -,,.
an oporndonosasu-Clis-eiY:J-:::..ES1oli5.ce que el soft\vare sea completame1~te diferente de otras
.. :.'''.>:
.; ,
. , ..
'
t'i'.
" '
. ' :
.
.. :-
'''
. !
.,
-cmpiTr ..
::-Est-;-
el
1.
.......
t;l .
... . .!
...
1 .
-:
-------.. --
~-~~:-
... -
..
--
--~:-
~-~ ::.':~--
.. ::
.,
....
. !
..'
.'
.:
;J.
:> '.
. .
Exi~~.... n
de'
1.
1 ..
. i
'
Podemos dividir las propiedades del softwareen l}temas y externas. Las cualidades .externas estn
a la vista de los usuarios del sistema; las internas conciernen a los desarroadres del sistema. En .;
general, a los usuarios del sistema les import<m slo las propiedades externas, pero son Jas
propiedades internas - relacionadas con la estructura dd software - las que ayudan a Jos
desarrolladores a alcanzar las propiedades externas. Por ejemplo, la propiedad . interna de
"verificabilidad" es necesaria para alcanzar la propiedad externa de confiabilidad. En muchos
casos, sin embargo, las propiedaues estn. relacionaJas tan estrechamente, que casi no hay
distincin
entre .interna y externa. .
'
: ~- ~ ~.'.;....:._
..
.1
' .
,. ...
'-:.
~
(~.
(
~:,
(j
(3
r:-::,
'-..J
r:~
<.5)
c:c~
:_:
.)
::
e_;
! ';.:.
C:
~7.;'1.
-'ll -
:~u,
:, u
-~.
1
~
...... _ .. ~--.
.-~-:;.; ~
..
:~-.
:.----:-:.-. , . .........
-~ ~ :-.-:-- - -r.! r
--\~-----:
1;
~ ~ :
'
::_,
: ;.,;._.. :~\:::..:
'
'
''
'!
1
)
.
..
.1 .
i .
. i
=-
,.,
..
1
1
.,
1
. ~-
. 't\
.: ;.
2.2.1 Correccin,
.
. Coiifiabilda.d y Robuste7..
.
-..1
:J
:-~~:~f:~-~:
2.2.1.1 Correcci.n
.,
C.'i
()
. C?-',
()
()
( ::\
' ~"
e:
.~~ .e::.
./
ji . '\
!'\:.;)
:e.
. c0
! C}
! l.}
. ~-
11
_,
1 :-.
i l.::>
.:!
(~:
: : t.;
:
2.2.1.2
Confiabilidad.
....,
:. ;.'
1 ...
-... .
~- ~ :
\
qucls.iSJ:ema.se.a-J.ncorrecto,....c.o...inter.es__cun leveoserf~"Se-~."ct~~!~s:ign;_ --.. -~ .... ...... -----. El concepto de confiabilidad es, por otra parte) re!Utivo : si la corisecuencia de Un error Cle
.
...
, . ,
..
:,
...
.
/
...
:
!
Figura 2.1
'
. 2.2.1.3 Robustez
; =
',.
''
datos incorrecta o alg\m dispositiv-de hardware fur.ciona mal (ej. un disco)-. Un programa que ...
supone Wl3. entrada ~ CatOS p~rfecta, generar Ull error irrecuperable en tiempo de ejecucin
cuando el usuario inadvertidamente escriba un comanC!o incorrecto. Este programa no puede ser
considerado robusto. Poc:.ra ser correcto, sin embargo; si la cspecificacitl de requerimi'entos rio.
establece qu acciones e_iecular ati.te la entrada inconecta de un comando. Obviamente, la ro_bustez
es una propiedad diflciLie clefin : despus de todo, s_ pu~irarnos establecer con precisin que
. 1 ,,
\,.
..
.. - ......... - ": ..
- - - - . - -
1,! ....
o>
:.,:;~ .
f , .:~(i~?:
son
1.
En general n.o esperamos que nos entreguen un automvil cbn una lisia de
,'.-,r..
l !).,, errores: de diseo son
extremadamente raros y ocupan l~s titulares de los diario_s,_ Un puente que se 4errumba puede
- -'
incluso llevar a la corte a sus diseadores.
.
dec~aracin donde se nos dice que el fa:bricaryte no se l~ace responsable por los daos que puedan
. :
ocasionar los errores uel producto. La ingeniera .del software podr ser llamada una disciplina tlt:
! '
ingenieria slo cup.ndo el soihvare alcance un.a confiabilidad similar a la de otros pro,ductos .
. . . . : .:.
La figura 2.1 ilustra la relacin entre la confiabiliclad y la correccin, bajo el, sup!_.lesto ele
. 'qu~ la especifi~acin de reqtefimientos funciona es contiene todas las propiedades deseables para
la;ap,licacin y ,'que no se h~n especificado:_ errnearneille propiedades no deseables. La figura
. mt~estra que e!': conjunto. de:)os progran1as confiables li-icl_uve al conjunto de los programas
:co'rre:ctos. Desatortunadartie!lt~.:en la pr~cUc.a., la..e.Specifj.c~ci es un modelo de lo que el usuario
'
q~i~re; pero d ':modelo P1J;~de o no,~ ~ser .'~t?a,. . c,t~0n19)~~: _a~ertada de. sus necesidades 'y de los
1'
\1-erdaderos requerimie.ntos. Todo lo que eLsoftv;;aie pl.iede hacer es cumplir con los reqUerimientos
dd moqdo - no 'puede as,~g~rar la precisin ~el modelo'~ ~ . ' .
. .
.
.
.
'
.. As, la. figura 2.1 . representa una=. situ~cin' 'idealizada- donde se supone que Jos
requerimientos son conectes, es decir que son la representacin fiel de lo que la implementacin
debe garanlizar para satisfa_:::er las neccsida?.~s..sJel usu~rio. Como se discutir en el capitulo 7, a
menudo hay obtculos invericibles jjfa alcanzar este. objeti'vo. El resultado es que a veces tenemos .
aplicaciones "correctas" que f~eron d{seadas para requerimientos "incorrectos", por lo que la
correccin dd software puede no ser suficiente para garantizar al usuario que dicho software se
comporta de la manera esperada. Esta situacin se discute en la siguiente subseccin.
conoc:-!rhs" rtugs).
:1 ,
~:
. ) .' . \
~o
:~ ~J
--.
-=~::.'~
.-. ..-:: ...... -:: .- .. _.,-: ;' ..... ...:. :': .. . ';' . .... "1'',
-:-~-
- -:
~--
::
--~:
- :-.:;-- :.-
~ .-;1 ~;
:
.'~--- ..
'"
:: : 1 :
:~
~:!- --~.
: .,
:i
.'>_.eberamos hacer p~ra que ur~a a.plicacin sea robusta:_tambin podramos definir con exatitud e\ ..
trmino "razonablemente". De este modo la robustez sera equivalente a la correccin (o
confiabilidad en el sentido de la figura 2.1)
.. ,, ...
Nuevame~1te la ru1aloga con Los puen~es es instructiva. Dos puentes que conectan ambas
mrgenes de un misrno ro son los dos. "correctos" si ambos satisfacen los requerimientos. '
establecidos .. Sin erpbargo, si durante tma inesperada y torrencial lluvia, tmo se. demunba y el otro
1
no, poJremos Jecir que el segundo es ms robusto'que el primero. Ntese que la lecc in aprendida
con el derrumbe del puente, llevar probablemente a mejorar los requerimientos' para futuros
puentes definiendo la resistencia alas lluvias como un requerimiento para la correccin. En otras
palabras, a medida que el fenmeno bajo estudio se vuelye ms y m ~ conocido nos acercaremos a
\ .
\
la propuesta de la:figwa 2.1 .don~e las especificaciones capturan exactamente los requ~ririlienlos "' :i 'Tl. ;>
. \ ....
esperados.
. ;. .
. . ,.
.
. .
.
i
La cantidad de cdigo dedicada a la robustez, depende del rea de aplicacin. Por ejemplo,
un sistema dedicado a usuarios poco experimentados cle\:,cr estar ms preparado para manejar
entradas de datos incorrectas, que un sistema integrado qe recibe su entrada de un sinsor.; sin
embargo, si el ~istema integrado est contro[anJo el transbordador espacial o algn Jispositivo
crticp para la vida, es aconsejn.ble disear una robustez extra.
: :. En conclusin, podemos ver que la robustez, y la correccin estn fuertemente relacionadas,
s\n q~e ha~.a una c.lara ~,nea de separacin. e~:re e!las. Si po~emos un requerimiento- en la
~ficacwn, su ejecucwn aporta a la correccwn; Sl no lo mcluunos, puede pasar a ser un tema
de robuste:JLa fronteraentre las dos proptedades es la especificacin del sistema. Finalm.ente, la
.
....confiabilidad aparece, porque no todos los comportamientos incorrectos generan serios problemas~
alguno.s comportamientos incorrectos pueden tolerarse tranquilamente.
.
..
.
Correccin, robustez y confiabilidad tambin se aplican al proceso de produccion .,.del
. ~
1' .
.1
...
soflware.~n prOceso es robu~;to, por eje_~plo, si _Puede acomo~ars.e a~bios .no anticipaJos
'
i
del entorno, tales. como un~ nueva verston del ststema operatiVO o la transferencta brusca ele la
~
mitad de los empleados a ofrr:yficina. ~ceso es coliable st cooduce en forma consistente ~
1
~eracin de p;oduc~os._t:_ alta ~~dad ..ll;,n.m.':lc~ms di~ciplinas de la ingeniera, se dedica un_a
buepa parte de las mvesttgact::mes para d descubmmento de procesos confiables.
'
2.2.2 Perfonnance
i_.'
1 ':
L.:..
"
'
. ''
..
J
'
i~
L.
~~
r'
i~
~ .. )
~ -
r:
: _1
Se espera que cualquier producto de ingeniera cumpla. con LU1 cierto nivel de performance. A
diferencia de otras discipli:oas, en la ingeniera deL software ~para petfarmance c.on _
eficiencia. Aqw tambin seg-.1iremos esa pri~ctica. Un sis~ema de software es ebctente si utiliza los
recursosae la computacin, econmicamente.
.
. .
La perfonnance e~. i.mportante porque afecta la "usabilidad " del sistema. Si un sistema es
muy lento, se reduce la productividad de los ustmrios posiblemente hasta el ptmto de no satisfacer
sus necesidades. Si un sistema usa mucho espacio en disco, puede resultar muy cara su ejecucin.
Si un sistema 'usa mucha memoria, puede afectar otras aplicaciones que corren. en el mismo
equipo, o pued~ ejecutarse con mucha lentitud mientras el sistemq; operativo trata de balahcyar la
asignacin de la memoria c[,tre las distintas aplicaciones.
Subyacente en. todos estos ejt:iplos- y es lo que dificulta el terna de la eficiencia- estn los
cambiantes lmites de la eficiencia a. medida que la tecnologa cambia. Nuestro enfoque ele lo que
es. "Jemasiado caro" sufr:~ w1 constante cambio a medida que los avances de la tecnologia
extienden sus lmites. Las computadoras ele hoy son muchsimo menos costosas que las de hace
algunos aos, y significativamente ms poderosas.
1
l-'
,.
''\'
.,
L/.,,
.. >-
' _, .
..
'
. ... ..... ~ . ... . . .~:.-.::.::.. .-.~;:~:~: ~:. . :. :~:. ,;~:..'.'::.~~::_~_~::.. : :.--~~-~:::~:~--~=:.. . .~-- --... --.. - ..
1'
'
...__
_;~-~\
:
:
- ,:.;;_.... , ' 1
.',,.,,,:;;":::;
..
. ,
.1.
i
l
i'
. '
.
. 1
1!
' 1'
'
i.
~.
.'
'.l
.1
::.
'_,
(~
C)
()
()
(:;
Se dice que un sistema de soft.vare es nniigable con el usuario si los usuarios. humanos lo
encuentra~ fcil de usar:. Esta definicin refleja la. nnl11r2.ieza subjetiva de la amigabilidad con el , ....
.. ,r'' .
-~,
;.'-.-
.
.1-
:.-::.
~ ~s_ua~io.
Una apli~acin usada por un prograzi:ador.novato, deber poseer cienas ~uadades que
' .
sern distintas de las que tendr una aplicacin que usar un programador experto. Por ejemplo, el > ..
. '
rin<;ipiante
aprecia
Jos
mensa.ies
de
ayuda
mientras
que
el
usuario
experimentado.
los
detesta
y
:
P
1
ti~nde a ignorarlos.
mism modo un.no-programador valorar el uso de menes,_mientras qu
.. 1 .
. un programador
sent~r ms :::modo e'scribiendo Jos comanqos.
.
. ; ~a inte~~~se con el usuarioes una parte ~portan-te de Ja amigabilidad con e~ usuario. ~n ::- .. , .:--,~,s 1st~ma Je software que s~ prese~t~ como_ un.. s. tstema d~ ventanas y_un mouse, sera mucho m~~-.-.,,:- .. , !:<J
amrgable que uno que ex.Jge c:scnbtr comanq9~ fonnados_por U[1a letra. Por otra parte un usuano . . :. , :'.i l .'
experimentado preferir uri conjW1to de comandos que minimicen la escritura en el teClado a 'una "'- : :,;_:~
bonita interfase de ventanas que lo obligue a navegar hasta encontrar ui1 comando del cual ya
. ... ~- ;.
conoc~ la sintaxis. Discutiremos los temas sobre ia.inrerfase con e.l usuario en el captulo 9.
i" .-:;: :,, )_ 1,/:' _
Hay algo ms que la in:erfase con el usuario para de fin ir la amigabilidad con el usuario.
.. . . ,, H
Por ejemplo, en un sistema irr:.egrado con el hardv.are no hay una interfase c.on los hwnanos. En su
.. i
Jugar, d sistema interacta con el hardware y probablemen_te con otros sistemas de software; la
i
se
pet
'.
'
amigabilidad con el usuao se refleja en estos casos en la facilidad con que. estos sistemas pueden
-.....
_}'
'").
j,;i
:--,
t\;
Ejercido.
i .
-----------------------------------------------------------------------------------------------------------------.
'
2.1
Discuta la relacin entre los aspectos de 1a interfase hur.i1ana del s.oftware con la.
confiabilidad.
... ...
_;' :-: .,, .
:~~~~~~~~~t~!~tt!t
2.2.4 Verificabilidad
:,:.o.
e,
\:_./
r, 1. ( -- .
:)c; '-...
1.
......
sistema
:r \._;'
'
'
,' '1-~~;.
':.
.\')( :~
::
,.
;,.::.:-..-.
.
1
..
",:..
.,
~ ;<;;:_-.~,.---~:~-:~ :>::~::-~::
.. ..
t@ ~-~rifi~r.: Como
.
-~'.'
:.
.
..
El diseo modular, las prcticas disciplinadas de codificacin y el us~ de un lenguaje d~
l
programacin adecua<;io, contribuyen a. la verificabilidad.
, .1.
'
.
i
La verifcabi!dau es generalmente una propiedaJ interna, aunque a veces se convierte en .
.
;J1.1a Dm?iednd e-;-rterna tarnbin. Por ejemplo, en muchas nplicaiones criticas. de seguridad, el
:... J-~.
;{ J
cliente requiere 1~ vericabilidad dr cil:'rtns !)rop;,_r~ades~ E!' ms <d[o nive.: de 1 S~f:'.'Jidad st~nd~rd
Y::\
para un "sistema de. cpmputacin ~ofiable" requiere ~~~ verificabiiiciad <..i.~.l kernel e.{ ststema
: .
.::!
oper~tivo.
,,
"
. :':
2.2.5 Mantenibilidad
. !
El trmino "mantenimiento del software" se usa generalmente para referirse a las modificaciones
que se hacen luego de que ei s~stema ha sido liberado. Salia verse al mantenimiento simplemente
corno una "correccin de errores" y fu penoso descubrir que se invirti tanto esfuerzo pa.ra
corregir defectos.i Los estudios demostraron, sin embargo, que la mayoria del tiempo dedicado al
mantenimiento, 's~ -~~up en realidad, para mejorar ~1 prodcto con propiedades que no estaban en
las especificac.ioll.es: orig.nales o que fueron mal definidas.
"Mantenii:niento" no es, por cierto, 'el t{tino adecuado para utilizar con el sr~rtware.
Pril11ero, como, se lo utiii~a' hoy, el t~1i~~o inblye uri amplio rango de actividades, todas
relacionadas con la modifc~9in de. alguna p;:ut~~ de~ .~oftware existente, para mejorar) o. Un
L~nnino que, qtizs, capfura mejor la. escencia ,de: este proceso es "evolucin del software".
Segundo, en otros productos de la ingeniera tales coino computadoras, automviles, y lavarropas,
el "mantenimiento" se refiere a \a conservacin del producto en respuesta al deterioro gradual
las partes debido al uso prclongado. Por ejemplo, pr~ridica.mente se cambian las correas d~
transmisin y. se limpian l9s filtros. Usar !?.-... p.~l~bm "m3:ntenimientci" para el sciflware, da una
cormotacin errnea dado e Le er soft~vare no
gasta. Desafortumidamente,. sin embargo, el
trmino est tan arraigado qut~ continuaremos usandolo.
.
Hay pruebas de
los costos de mantenim~into del software exceden el 60 % del G:osto '
totaL Para a...'1alizar los factor::;s que afectan tales costos, es habitual dividir el mantenimiento del.
software en tres categoras: mantenimiento correctivo, c::laprivo, y perfectivo.
.
El mantenimiento correctivo tiene que ver con la remocin de los errores residuales
presentes en el producto cuando fu liberado, as como tambin los errores introducidos en ~~
software durante su mantwi:nie:nto. El mantenimiento corree ti vo representa W1 20.,.% del total de
los <;estos de mantenimiento.
Lm?:pte!~!.!!.i.e.nt?.~..<:\~p_!._i_~~-L-P.&r~~i,~o son ias vercl_.a.de~~- fuentes del ~mb.io._e_!l el
software : ellos motivarmi la introduccin de
"evolutiv-idad" (defl..D.da ms. abajo) como una
propiedad fundam't;~ta.i'~fci-;:ftware y de 1~ "anticipacin del cam5o" (definid<!. en el cap~~do 3)
como un principio general qu~ d~bera guiar al ingeniero del software. El mantenm iento adaptivo
representa aproximadamente: otro 20 % del costo tolal de mantenimiento mientras que ms del . 50
% es absorbido por el malltCilill.e!ltO perfectivo. .
.. .
.
. .
El mantenimiento adaptivo consiste en el ajuste ~e la aplicacin a los cambios Jel entomo,
por ej. una nueva \rersin del hardvare, o del sistem operativo, o una nueva base de datos. En
otras palabras, en el mantenimiento adaptivo la riecesidadde efectuar cambios en el soft_ware no
puede ~tribuirse al software en s,
tales como la prescencia. de errores residuales o la
..
':
'
de
se
. ; . ::J .,
'
que
la
;'
.,
;)
\
'
..
..
.:~
--~;: ;
.
.. 1'
'.
':.
. .
.,
':},
.;:
i
, 7\.:
>"' .
el_../
!
~,
::.
..
---!
:": .
;~~~;~;;1~-~~;~,,~:~~,:~~~::.~:.~~~t,:i~:,.fw:.-;;:~:. . -~..
/
'
:.::~ac-;,C:~'d'j.:'.c.
-,..,_..,
----~~~.-~,.,~2...__.________ ____:;;_-.
-~l-: ;mp~s;bilidad deel~roveer alg;~,dfuncionalid~d ~~q,::iid:r.of el usu~rio Mas bien, el softwar d~be >- .. , ;
''
\
:,. . cambiar porque ambiente en cual est iiurierso; cambt, -:: . .
.
.
..
! .. ..
..
. :
Finalmente!' el manteni::11i~nto perfectivo consiste en_ la modificain del software para
! ._: _,_ _:. 1
mejorar algtma d sus propiedades. Aq~i los cambios se deben a la necesidad de modificar las
. . 1 . 1,
funciones que ofrece !a aplicacin, agregar nuevas funcione~, mejorar. la performance ele la
'~ \ .. : l
aplicacin, hacerla fcil de usar, 'etc. Los pedidos para rerJizar uri mantenimiento perfectivo
' :,_J::; . .
pueden provenir directamente del ingeniero del software con la intencin de mejorar la posicin. ..
del producto en el mercado,. o pueden venir del cliente, par~ satisfacer un nueyo requerimiento.
Veremos la mantenibilidad como dps propied~des .por sepanido : reparabilidad y .,
. evolutividad.
.
La diferencia entre reparabilidad y evolutividad no siempre es cl<!-'ra. Por ejemplo, si ias ;t'
especificaciones de requerimientos son vagas, puede no quedar cl~ro si estamos corrigiendo un
defecto o satisfaciendo un nuevo requerimiento. Discutiremos este punto, ms adelante eri. el
captulo 7. E~ general, sin ernbargo, es de ~tilida:d diferenciar las dos propiedades.
1 :
1'
.:
2.2.5.1 Reparabilidad
.. ;1
_)
,)
J
)
..
)
...
(j
()
o
o
()
o
()
u
o
( :-.
_
........ '
...
'lJ~i
t
-.
C..
.. ' \ .
..
. .. ,t ':'(..':~ . :
/.;- . .
.;,. ,:
. ;:.:;-.:?
,1
... -. . .. - -
~-
. i
-~
.
La reparabilidad puede r:1ejorarse con el_ uso de las. herramien.tas adecuadas.. Por ejemp).o, '_
. _ - usar Wl lenguaje de alto nivel en lugar de un asserp.bler,. conduce a una mejor reparab\lidad.
. Tambi~n herramientas tales como "ciebuggers" pueden ayudar a aislar y reparar errores.
_bt~12.~@id.ag__~_un producto af~cta su confiabilidad._ A m~dida gue la necesidad de
reparabilidad decrece, la c..Qll[iabilidad aum~nta.
_
_
. - -
----
''
i!.
. 1
.,
;_ :.: i
i.
\"
'1
1"
.:...:.:.
-.....
l)
( :'
'--.
u
~e-
Al igual que otros productos de ingeniera, e! software se. m{;diiica a rn-:d\da au~- o::1sa el tiempo,
'
,
. pc.ra: agregarle nuevas funciones o carnbiar .funciones existentes. Dadv que e: ;._,~,_,.~-:;_,~ e::. l~n
1
maleable, se hace muy fcil ap!icru- las modificaciones a una implemntacin. Sin embrgo, existe
. !
..
Wla grall diferencia entre modificar SOftware O modificar cualquier otro producto de la ingeniera ..,,
'
'.
En el caso de los. otros producto.s, la modificain comien.,.:a en el nivel de diseo, y luego ;:ontina
1
. '
con la implemeptacin. Por ejemplo, . si se deGide c.onstmir lln nuevo piso en una casa. habr que
;
_ hacer primero un estudio de factibilidad para ver si es segura la construccin. Luego habr qi.11~
1
: i ;
hacer un diseo basado en el diseo original de lh casa. Luego deber aprobarse el diseio
. i: i
verificando que no viole las normas existentes. Y, finalmen-te se encararla construccin de esta
. '
nueva parte.
..
En el caso del soft'rvare,' desafortunadamente; raramente se procede en una forma tan
' . i
ordc.1ada. A!J. cuando el caqiio en la ~plicacin puede ser radical, muy a mei1udu se conienza
con)~ impleme_n~acin sin)incer, un e~tHdio de _fapt~~ilid~d, sin solamente el cambio en el diseo
origimil. Peor an, cuando ~e cc;)mpleta la modifi~a~in, ni siquiera se la documenta a posteriori; es
decir que no S~- actualizan la's. e!'pecficaciones_ 1 p~n( qi.te. ref1ej~n el carnbio. Esto hace que los
futuros cambi_os sean cada ve-z ms dificiles de aplicar.
.
Por ot~~ parte, los pi-~du~tos ele software exitosos tienen larga vida. Su primera versin es .el
inicio de esa larga vida y c\cia sucesiva versi,n, representa el paso siguiente en la evo1ticiri del
sistema. Si el software fu diseado con cuiuauo. y cada motlilicacin se hace cuiJaJosamenle,
evotucionu.ri airosamente.:.... . . . __ .: -~---:.~ ...
_... , .
.
. A medida que crecen el 'costo de la p'roduccin de software y la complejidad de las '"-l.l
aplicaciones, la evolutividad adquie;c cada vez ms_ importancia. Una de las razones es la
necesidad de impulsar l2. ilwersin hecha eri el soflware a medida que la tecnologa del hardvvare
avanza. Algw1os de los primeros sistemas desanollados en Jos aos '60 aprovechan hoy las ventajas
dd nuevo hardware, dispositivos y tecnologas de red. Tal es. el caso del sistema de reservas de
American Airlines SABRE,. desarrollado iniialmente_ a mediados de los '60, y que sigue
evolucionando con nueva funcionalidad. Esta es una hazaa sorprendente, considerando las
.
2.2.5.2 Evolutividad
~. 1
'
1,
"'/' \ ; .
.. . :
._:__._, :
_:-~//,:
...
' . .' !
..
.;;;:~~\-:,.'.- :.-:- ._ -.
'
~-.:W~~i+~W;:i;,~~~;;;rr~i:::~',~-~;;~~;~A.:;.,:;;:;:~:.::;;:-.~:~~,~:.:$,:;,s:}];~~~iE~~2;,~~~3:2::~'-~~:t;.:~:~:~~-,~r!::::~-tiEEJt'J. :=;;.~J:
,.
_--.~ p~esentamos
c;:~pttulo
; .'
-~ '. ~
t-
1
: i
:- i
-l ;
. 1 ic
,.,_
<,_ ,. i:,
.i
. ' . ':i -:
,....
i
._,.
C:~;l
,()
it!J
ln,
'-:3.
10
JU
! -~ .
k}
e~,
e:
C:
1
'
. 1 .,
:. -:: ;: 01- ::;
.''
2.2.6. Reusabilidad
su
e!
..
1
~
'
~ :~ .: : . Tal como .lo discutimos antes, puede haber ms niveles de reutilizacin cuand() se diseii~
<: :: l
una aplicacin o an en el nivel de codificacin. Muchos expertos en software afinnan hoy que en :
e..:: 1
aplicaciones, no desaparecer a medida que la gente. se vaya, sin que se ac~ular '
:...... progresivamenle ~n sus catlogos. Otras compaas invertirn en la prouuccin generalizada de.
. coniponentes reusables, que pomlril en el n::ercado para que las usen otros productores de , ,
., .
'? ~
.,
_; f
: 1 i': !!
:.o.! .
_;~:'
~~J~~~~;
::;;r .
software existentes puede verse como el intento' de reutilizar el mismo proceso para la . , . .'_ r;;:,(
construccin de diferentes productos. La variedad de triodelos del ciclo d.e vida, intenta tambin/ . .. :
reutilizar procesos de tvel superior. Otro ejemplo de reusabilidad de un proceso es la propuesta
' ;
de "replay" para el ~ntenimi~o del software. E,n esta propuesta, se repite el proceso completo
cada vez que se hace tma modificacin. Es decir, primero se modifican los requerimientos, y tl:lego
se s_iguen los pasos que se J.efnierori Jurante d desarrollo inicial tlel prouucto. En el-captulo 7 se
dan' ms detalles sobre este tema.
:.. .
.
. '
' ; La reus~bilidad es un factor clave que caiacteriza la madurez del rea industriaL. Vei11os
(:):-;
altos grados de. reusabilidad en reas tfm rnadur~s 'corno la .i.ndustria automotriz y la electrnica de
. .,
consumo.' Por~jemplo, en:];~' iridust.ria automotriz;.
inotor se reutiliza de modelo en modelo.
Adems un a:uto,mvl se S;~mstruye,n1edia!lte ,el- ~p.~~~~l;>la?p de muchos coniponentes altamente
estandarizados y usados a a'ls de ni~chofmodelos producidos por la misma industria.. . .
:..
. 1
,.
: ' . . :; ' .
:
El bajo grado de reusabilidad del soflwar es i.111a iridicacn clara de que debe evolucionar
hasta alcanzar
el estado de. L!r:,a biGn definida d.iscipliria
de .la ingeniera.
. '
.. i
.
.
.
i!i. :;{:J
~.
el
)
)
Ejercicio
2.2 Discuta cmo la reusa'qilidad puede afec;rar.. .la confiabi_lid.ad de ios productos
~
. ... .. ... .
------------------------------------~--------------------------------------------------------------------~
----------------
2.2.7 Portabilidad
~).
..
;.-~
'"
o
o
o
o
:0
1 , ...
ll?.
\.....;
h.J
1
1().
1C
'l
,_.
.,:,
!t .
;'
: )'"
...
'~~
)'.~
\
... i.
,,
Wind~ws extiend~ esta capaddad para permiti~ q~e las ~p~icaciones se ejecuten sobre cualquie~
l .
.:
mapa de bits.
.
.
.Ms generalmente, la portabilidad se refiere a la posibilidad de ejecutar un sistema en
distirtas platafonna.S,de har~wnrc. A medida que <1Umenta la proporcin de dinero que se gasta en
software comparada con el gasto:J en hard\vare, la portabilidad adquiere mayor importancia.
Algunos sistemas de: software son inherentemente especficos para una mquina. Por
ejemplo, un sistema operativ~ i::st escrito p;Lra controlar una mquina especfica., y un cot~lpilador
tambin produce cdigo para una mquina determinaJa. An en estos casos, sin embargo, es
. posible alcanzar alg!). nivel de portabilidad. Nuevamente U1'fL'X es un. ejemplo de un sistema
operativo que ha sido transportado a muchos sistemas de hardware diferentes. Por supuesto, el
esfuezo para transportarlo requiere meses de trabajo. Todava podemos llamarlo portable ya que si .,,
tuviramos que escribirlo desde cero, seria mucho ms complicado. .
.
Para muchas aplicacincs, es muy in1pottante que sean transportables a travs de los
sistemas operativos. o, mirndolo de otra fonna, el sistema operativo proporciona la portabilidad
a travs de las pla.~aformas de :1ardware.
. i
.l
...
1-
'
1
'~' ';~t
.',
. 1.
. i,
. ~.
.
.,
?~.
.;
': i .
.' ;
-
-------------------------~-------------------------------------------------------------------------------------------------.
----------------~---~------------------------=------------~---~~------------------------------------------------------------
: ..._
'
,1
.:.i.
,.
_,_;
"'
_j}
-.
.. )
\)
\)
7
1
.. j ....... -
.1
. ...
'J-
. .
~~
..
.,
. ~
!-------~
.:.-<:: .
n}:t'f'!
:. ;erl~an u~a interf~e simple stondard, pe;m;;.\u~Ja salida de una aPlicacin pued. Ser usada
que
interoperatibilid~d en los
ambientes actuales : ,la interfa:=;e standard de UNDC es primitiva y orientada al caracter. No resulta
~~~j~E/!f~~;:~:~~J:::.::;~S:~r~;:::::~ce~:~~~~~ ~~o:n"~tn;i~~~~n:~:;~~:~e;a;~~
,: ~ ,.
. 1
..:. .L:
r:-
.;>~
:. , . , 1 '
....
.
_,.
_ ,.: .
' >
un
de
.i
': i
Un requisito interesante de los sisteinas abiertos es que se puede agregar una nueva
fw1cionalidad sin clesconec.t~'.r el sistema. Un sistema. abierto es similar a una organizacin
creciente que evoluciona ~!1 l tiempo, adaP.!~P_s)._ose a los cambios dd ambiente. La importancia de
la interoperatibilidad ha provocdo" un inters creciente en los sistemas abiertos, produciendo
algunos esfuerzos de eslm)dariz'acin en este rea. .
.
..
. ;;
Ejercicio
.:
-: .
2.4
.\
-----------------------------------------------------------------------------------------------------------------------------
.'.
.,
.....:
)
;.
-'
.
.'
--'
2.2.1 O
Productividad
La produclivi~ad es un::1. prGpiedad del poccso .de. produccin del software; mide la eficiencia del
pr~ceso y, como dijimo; cates, r:s la propiedad de per.~ormance aplicada los procesos. Un proceso
eficiente hace que el produ:::to se libere rpidamente.
.
'.,
. 1
.....
;. .
.'
.=::_'' -.,:,
. -~-
~~~,~~~~~~:~~{;~fSS::~~~~:~
. un proceso que reqmere especmllzacton d~ algunos m1embros del eqlilpo, puede al:ill.1entar la:_-o,-,c;~,i".:""
<-;.;::: :: prod~ctividad ep. la fabricae;in_ de w1 detenninadci producto, pero nci en! a produccin 'de una)J;f,g
: -:;:~l'.<;_._varie~ad de pro.ductos~ La tcnica de re~tilizaGtn del_ softtvre_ es w1a tcni~a que amenti, ID. {f!,f,,,
. :_:;:r/:-';:: P:9~~~tivida~. general -~~. U~la crganiz.aci~ :q~e:: se dedica. a_-. pioducir. muc??S. pr:o?.l!S~~~~;/ p~~Y. ~\z:~i~!
.)/'.. desarrollar modulas reutllJzables es mas compbcado que des~rrollar modulas parael propw:uso;.-'-'"'' 1
'
~.
: ' .
'
1 .
. .
:;{f,/
'i~ ~l
:; ,;
1''' ~ .
......
,::1~/'..: :-- ~n.i9.he$ :ia prQd~c.~iyidad de(grupo qu~ lo$ e~sJ~;:~~~arr.o~pdo ,S,e've~ tlisiT1i[lui~~- . -~j;~~@.~~~{tr;;~~{.
la
' .
........
.;
' ~
1 .,.
;. -~..
1 ,.
~-
. ,__.;,:
'
:-:... ~
,':o~. _,
- ;. ..:-/;_!::.;!'
Ct)
-'.
~
organiz~cio~1es ~e equipo para 1\1ejorar!a .. Como ~rt otra~ discipli~as de la !ng~~iera,y~:f~p;~s _q~e '-:::.:.f:J~~;.-,~1; . ,-~(
la eficencm del proceso, esta fuertemente afectada por . la, automat~:zac10n .. Las r modemas ,. ;.' :;~;;_:.r,J:~!Nt;'}
h~mamientas 4e la inger:ti_~rb~ dei software conducen a- tm aumnto de l~_ .rroduc~iy~d,,~~:_.Es.ia_s .:<:\~:!:1:,~;:~~_{:~~-~:i,'
.
. . en ,.. l caprtu
. 1o 9
,, '!;l!~. ?''"""~~';'
. herram1entas
se d'lSCUtJran
. ,_ . . _.,- .
.-. '' .
.. ---:'+ ''<
"' ,,,_.,:.lh1';' ... ,,.r;,:;l~.l~''"~jji~r.~''';\''
_,
,....
o.
~~~~--~~-~~--------~-~-,~4~-----=-----::;r:
_
::"tll,~l~~~
copo.
2.~ Evale criticamente la cs.ntidad de lneas de cdigo
medida de la productiyidad <,.-;.-, \:;2 {?' r.:
.
(Este tema ser analiz~do en profw1d_idad en el ca1)~t~~p:,8) . : . . . :.\~:.!::.i_;:.:<.::_i;~(.;,c,~
-----------------------------------------------------~~-~---------------;_:-+~-----------~-------.-------~-:;~~~~~-~:--e-~~_:_:_ e';:,':.
!&[~
habil!d;rit;;'1~r~~~>
el
entregar ese producto en el tiempo estipulado. Histricamente, la oportunidad ha fallado siempre ;..:'HL~irJ~'i--~'Sh/
en los proceSOS de prod'.!C~i:?~ del SOf~ware,..desembocando en ta "crisis del software", que a S~ vez::::;-.~~#.~;~;~~{;';ii,1~;;:'.
gener la necesidad de crear la ingeni~da del software. An ahora, muchos procesos. fallan: a,; la;f~~~'~:F:}~:%.~N.b.i:
hora de entregar el producto a tiempo.
._ . ..
.: ;:
_ -'> i-h>j~~:H;;T:;;:it!1i[~;.r
El siguiente ejemplo (real) caracteriza la Pfctica industrial en la actualidad. (circa 1988): ::';::-?'Jrl':ni}'1;i)t;'t
Un fabricante de computadoras prometi la primera versin del compilador .A.QA para una' )_!:,;)::::f::;(~.';
d~terminada fecha. Cuand:J lleg el da, el. cliente qu~ lo haba solicitado reCibi. en lugar ,~el;~'/;;:~{~!(:-;~,;;}}
producto, Uila carta diciendo que, dado que el producto todava contena muchos defectos> d ')29t;:~~'~i{Hs!+:
fabricante .haba decidido :Jue sera mejorpostergr la entreiza antes que entregar. el producto en -~-~~-;~t;:M;\~;ji;):
esas condiciones. La fechE -se po$terg tres meses.
. _
' " . ; ,_;:;;~:hW:\~~f#:1,t
,
A los cuatro meses! el pr-~ducto lleg, jnto con tma_ carta que deca que se haban corregido -:::::t:::_-_~i.~}if::,
muchos, pero no todos los defectos. En ese momento el fabricante decidi que era n1ejor qe los;~i:.':.'_;,/~:~:::(~:n::
clientes recibieran el compilador ADA, an ctando tuv1ese serios defe~tos, para qu'e as p-udie5~n-~:t;~j;;~;L;t.:}{tt
comenzar a desarrollar su::: propios productos usando .tillA. El valor de una entrega' tiempo pes i:/J:':;(j\\~:)1:')
ms. para este fabricante,. que el costo de_ haber entre.gado un proucto defectuo~?:: Por lo que,.;;;~i.~:;,0[',:}:i~i?,::.
finalmente el producto qu:~ se entreg lleg tarde y con defectos.
.
. ' .. .,
. . _, -:,_.::>::}ii:::::::i;:
La oportunidad en s no es u~1a propiedad tiL Aunque llegar tMde puede_ hac~rnos pel:cle;~~MWWJr;.
posibilidades en el merca:io. Entregar a tiempo un producto que adolece de otras propiedades, taleS!:~';:[!i;[~iM~r~t
como
confiabilidad o per::ormance, es intiL
_.
. ; :.}~;p:~::;(~ (
.
.
.
.
.. ;
La oportunidad requiere un planeamiento cuidadoso! una estimacin del trabajo acertnd~,fi::/;:-':.':~- :'-.-,
. punces de controi clara~:r1entc especificad?s y .vel'i.fic.abks. Todas ID.s otras disciplinas de' la:.~,;~::;;~,>.>:
'H~- -~~-~.:~;
~ .:r
~::t_\)_;~;:;;)}i~~~:r~~~-;
;:
:f;::.::.;;::~.
~~~-
.. -:_. _,...._.. -._\>-.::,~:s:-::
conttold~
:1~~:;~:~~t~).,~:;
u;
:i;;;:;:i .:::,, ' ... : .;:~;::...,, .:. . . :. .. !~:}::~ .,. :;.,.:;.;\ '. :; .-;
:.~:.:
(Las
unidades
de.
~~cala no se muestran, pero se supone que soii. umformes).:En el moirierito t-0 se
<:. . ..
:-i.};:::;~ . : -~-. :: .. : --;_~--~-- ~-\{t .i:: ::<~ .' :-, . :. - -~.::.:,::~-~;\;, .. '::.J.~~~i f:fty .::;;!-:.\ ~ ;::~
:reconoce la necesidad de un sistema Qe softWare: y cqmlenza' ~l)iesarrollo'-'cori un,cogoclf[uept
bastante incompleto de los requ~rimientos~ Como ~esi.tlt~do, d ''prodct' irliciai knt~e'gri'ci(?;~rn::~i~
. mogl.ento t-1, .no satisface ni J ::ls requc:.rimierttos iniciales del in omento t-0, ni los requinlientos
. '. . . ~el usuario en d r1;1omento t-l. Entr~ los m<nnento~ t., 1> y ; t), el producto se .:'mant{e,ne:::pa ' ,.
'i''.'i ' ajustarlo a las Mc;;esidades d,el usuario. Evenn1.~Iment~,i ooinigEt. c~n los-.r~_querini.ient_~s,;,~~hm! :
del.usuario en el momento t-2. Por Jas razon_e~ que. hemos -visto en 1a>seccin:2.2-,5.
momento
t-3,
;'.s:l
costo
de
.
mantenimiento
es:)an_,
alto
que:~\
desar~ollador
..
decide.:;
h.a
...
'
.
. . . .
.' '
. l'l'. ....
'
. . .. .
. ..
. . ,.... ,.._,
importante re~~-~~fo. La ~u~Y :versiri e~.t disponibl~.'-~h el:)Iiiento t-4 pr6 b sepafac(n de las .
. necesidades del':ustiario 'en}ste punto, es' mayor que ari.tes: .. : . .
. ' ;.,~;(~; ;;,:-_
.
.1.: .
: if::; .
..-v;~.: ~
.~ ::. .. . .. ,. . :',ir . . .
., .. . . ;. = .
Figura2.2- Las falencias en la "oporturiidad~' .. ctel software. (De Davis (1988)) :,:;:
'. .'
''
. , ''
,'/,
. :.
'
...
,.
1 . ;:
'
. .
'
'
'~~..
'
. 1
',
;:
,;
'':-:-~
' ;
!,,;:l'
'
~ ...,l.1
' -
,. ~-. :.
1.
.;.\:.~
-~-
Fw1cin; . .
. ;.
; .---
.
Una tcnica para '~i.:a~cir'."la: opb~t~~Id~d, es:a.,.travs de t:ntregas incremenla!es:_ .
producto. Esta tcnica se i~.ustra en el siguiente ejemplo: de la entrega del compllaoor ADA
efectuada por.otra compafia (real), diferente de.l<i. que s-~ describi con anterioridad.
.
.
Esta c~mpaflla entreg - !nuy tentprano :. wi cotl1pllad.or qi..le soportaba un subconjunto ttl. .
pequeo del lenguaje AD/\. Bsicamente era. equivalent~ a un Pa~al: con ."paq1.1.etes" .. E
cqmpilador no soportaba n:.glma de las nuev.as caractersticas del lenguaje' tales como el man' .
ti~ lare~s y ~xcepciones. El resultado de es la entrega adebintada fu un prod~cto confiable.: Como : .
consecuencia los usuario~; comenzaron a experimentar con. et nuevo lenguaje.yla cornpai.a c.ont . ,._~.,, ... ,. .,..,,,",
c~n: ms tiempf? para comprender las sutilezas de las nuevas caractersticas de ADA.. Despu~~ de_-.:- '
varias entregas que se prolongaron a lo largo. de dos aos, se termin un cornpila1or ADN/
completo
. >
::
.
:
~~- .. , ..
1
: ;o;",,;'.'\: ;0-'
L~s .entregas incr;.b1entales pex~iten que ~1 pt~du~t~: es~ disp~ibl~ .antes; y el 'is~rde/;'..,..,.;. . .,.,,.,_,_
producto aYl;tda a refinarlos requerimientos.tambi~1 de rria~a-incrementa( :
'
. .
Fuera' del campo 'd~.. la ng~nieria del software, ..UD:, .. ejemplo clsico de la dificltad .
tratar :::on los requerimientos de sistemas 'c~mp!ejo's;.
los sisterrias de rumas ri-iodeinas.::
. varios casos muy publicila.cios, l~ armas ya. eraa obsoleta::; cuando fueron enlregdas; . ,,, .....
. satisfacan los requerimientos, o en ~n'Jchos casos arriba.scosas. Pero despus de diez ai.os: de.::
desarrollo,.
inuy dificil decic!.ir qu6 hacer con, Wl producto que no satisface Ltn requerimie.rrto.; ..
establecido diez aos ::;trs. El problema est exac~rbcdd por el hecho de que e~ estos. casos)cis\
dd
!'
...
.--!
,...,
:J
.,..,
1
>. ,
. ' : .;
son
,..
L''
es
' . i;
..
. . .. ' . . . . . . . .. ..
;.: .
(-:
... ;
... - .
- '
'"""'"''"'"l<'i?
.. :~-~-P - ~-:_: ~. :
~--. -~~;-
...
f.: ; . .. .~ .... . . .. . .
-;.; .
\. -~
o:~~~ .;-.~
requ~rimientos
' ;, ,: .. .."
Obviamente, la entrega increrri~ntal d~pel1de de la habilidad para dividir el COl~ unto de .
funciones del si$terna erl subconjuntos que puedan ser entregados por incrementos. Si no es'posible ..
def~ir ciichos sl;><;:onjuntos, no existir ~n pr9.ceso que pueda poner. el prducto disponib,le po:
~ntre:g~s. Atm c~ando se pqedan identificarl.e~ :s~tbconjUil;ts, s el proceso. que, los ,tF~~aL~o: ~~.
in~rein~~~l:tampoco. se podr~ hac~r una e~~~~,~f:;,i~c/.~~71-~Pt:~~ri~f.oportuni?~~}e al~~~.~-~~?..;~(~.~
pue9~ dtvldtr yl prod~cto en SUIJCOnjuntos Y. ~~!W~fp~.yp,~PFR,2~-~9:,~pcrel11e,I1!,a\:A;,, . i~;t1.\fN!.~~:~~};J: .
La entrega 'mcrementa[. de SUbC()HJ~~~ps,;':.,}_llt1t~!es;:.;:P9r' surue~tO;;~o tl~n~_-:_ \.~l~r;;:l
oport~Jl,id;;td deb~ ~ombinar~e ~on otras protn.<?,?:id~.~,: 9~1 so ft;x~_fe: El capi~lo 4 verep1os: mue h.
tc~ca~ pr?: ol?!ener subconj:.mtos d~l pr99,~~to;?_y'e1_ ~apitill, 7,, discutir :las t~cnfc~sTp~ra._.
pro~esos experimentales.
.
.: }.~~:/~3
~- '::::~:~NYt' .:~ , :.
~;,., i..:;:~f~f:nrr.~;::~. ~_:
..
"::-":tt::
. . .:: :._
-~ '<\ ..' .
'!.
. .....
...::.:.
, ..._
\,.:.)
Otros.
tn;nos
son
transparen~ia:
Y
.~-pe.rtui:a.
L'a.~~ide~('es
q~~:Jo~~:;;r~~;
y
e
es
.
.
.t.
.- .
,..
. . '
'.
. ::l" :. ;
-. =
, .
proyy~to esttJ;W9-iponibles y son fcilmente accesibles desde"afuenl'Nrap9der.$~r exarpimi'dos ..
:
En mi.~chos proyectos, la_ mayora ;'de los ingenieros e i'ncluso:1os administradore .
de~cohocen el estado exacto en que se encuentra el proyecto. Algunos pueden est~r'd[s~fi~1'do .
otr~s codificando, y algunos haciendo pruebas, todos al mismo Liempo. Esto, en s mist~o, no es , .
malo. Sin embargo, si un ingeniero comienza a' redisear la mayor parte del cdigo jlisto en el,'.;_:
!Tiomento en que se supone que se integrar ese cdigo para tma prueba, correr es riesgo el~
padecerseriosproblemasydcmoras.
.
... . . ._.;. .. . .. ,,-,;~:).L,J
':_:.. .. . f' ,,,t>,r>' '' _..
.
..... ,. ,,._.......... ' <',;
.. .....~:..
La visibilidad penni te: a los ingenieros sopesar el impacto de sus acciones y as las gul. en.
la toma de decisiones. Penni~e que los miembros de un equipotrabajen n l: misn1a~ire.cciri,' en:
lugar de hacerlo, como e~_bastame rrecuet~~~<_:::.n direcciones cruzadas. El ejemplo mtts'comw1 de .
e~ta ltima situacin,es, corn'o se' Inncon antes, cuando un grupo ha estado hacierid_o.,un test de, , ..
integracin de una versin del sof1ware suponiendo que en la prxima versin habr, pocos:.'.
defectos que corregir y lendr muy pocas diferencias con la. presente; mientras que :al mismo '.
tiempo un ingeniero decide hacer un gran rediseo para co1Te'gir un defecto menor. Es ~oni.n que . .
h.ya tensin dentro de un grupo que est tratando de estabilizar el software mientras que.: otra . . .
p~rsona o grupo io esta desestabilizando de una. manera no intencional, por sJ.pesto. El p .
'
d~be alentar una visin cons~slente de las reales metas entre los participantes.
. ..
La. visibilidad no es::lo una propiedad interna, tambin es extefJ!a. Durante el curso 'de, un.;':' ... ,
largo proyecto hay muchas preguntas acerca dd estado dd mismo. ~ veces se requiere una . . . , . :
exposicin for:rnal d~ dicho estado, otras veces el pedido es informal. A veces el pedido vien~ de':_tU;.~>;~-t::.,
los administradores de la organizacin; y otras del propio cliente. Si el proceso de desarrollo d~\t(,li(~~;!:~W::~~:{f
software tiene una baja viscbilidad, cada uno de esos. infom1es de e~tado puede no :ser exacto,' '!i'',0~!;'.::,~iM1?1t:~;
requerir much9 esfuerzo p~ra prepararlo cada vez..
.
. ... , .-~- .. .... ;,:: .; . '.:.,;_; ,_~i;,;.;..::-~r1;:;;0-~G}~JA;. Una de las dificulta ::les para ni~nejar. grandes pro)"ectos tiene que, ver con_ la i-~;tacin dei[U(i(;::.L};i~\i(
personal. En ~muchos proyectos, li ..Tnforil}acin_; .crticft e efe a de los requernie.ntos :y-:el :disoU.' 1!,;;;:.;r[~f)l1p;
- ..-~~.~l-I'I.L:t"':t~~, q;:.!o~n
. --
. ~ ..... ._.,..;~X
~ .. \j,,~--~toma la forma de un "folk:.ore" slo c.o~Ji?_~}P?:r.P.9WJ~i.:g~j1te que ha es.tado en el proyect,o ;ya 'se~~)~:.
}E~isf~;
desde el principio, o bien durante uiCt1~m~q:g:P,roi6H~d6> Err muchas situacicnes se :hace'. muy';;,,:?'::~i!:\:t?~
dificil recuperarse de la prdida de Wl:-g~N~r,()J~r~~gii~ar
la incorporacit1 de otros .nuevos. . De. .>:u;h::}>f!i:f{
. ........ \ lj,.; ..
1 r. ! ,,
.
_... : ' ....
.
hecho, el agregado de nue.ros ingenieros _r-e,q_Hq!r~~~;P~.~~udo la productividad de td e1 proyecto::r:;;~:~{~t.~~;..f(:r
~,.,
~\
..
~~
.,l
'
..
. .
y:
&"
).~...
.,t._.r~
. 1.
~ . ..~ :_. 1
..
'
.
( ",
..
:----.-.~.--~-----.'=',.
-----:-.-.--- .. :.
'
. , .
.,
.~ ~ . ::
. .. -~: :} . .
:.-:
:: -...
:.~9
rrii~~liras
... . .
.
.
que
..... :
'
::.:'""'- '
- _
. . _. <
._ - ~- _.
.... -... ; .,... .. .
_ . . : ~ ::_-.. .... Lo dicho a.nterionnente, puntua.li.za que la visibilidad .de 0n proeso requiere n:o solaJnerite' '"
. que t9dos los pq,~os del proyecw estri d9cumentados, sin que t.~mbicn estn documentii.dos .las
;< est~99~ d~ los pr9qus;tos interm.edios, y que se :mantengan c~il..:acti~d 'Ias~specificajbnes de.
' ~ecpyurniento$ y. ~Y diseiio. Es d.ecir que tambi~i1 :;e exige visil:ilf4ad para ~l'prociucto'." :
,;+-5.
' .,.. :i'. ;:;. Intuitivamn'k un producto es visible"si estclaramenfef~struct~ra'doc'om
,
''
:_,.,.:, ....... ,, ..... '\'';.,
.,
)nge~eros..
. . ., ,
h"
'
. .
.;:: .......
. .
'.
,:
~- ,4~
... !.
, ...
. ':-
\'~::_.
!...
~,
-~
\:~...
--~~:.::-('
. ' .
~ f_:<:: .
~- calqir'::~:'~.-::l~w:(..;>;:w~~i~~
sisterna de software. Pero los sistemas de .sofu'{are se cntruyen para automatizar una ~plicacin en.
partic~lar y por lo,. tanto podernos caracterizar.. \m: sistei:na; .. <;J.e softw~re. basndono.s'/ en.; los:.
... !1':
,1\,'
2.3.'i~
Sistemas
:
.. ;. i.i .
: .
de informacin
' '
~.
~.
. . .
. :
: .',
; ~
~. '<:~ .. .. . . .. '
'
:..
.
1 .
.
i.p.formacin" q .implemente "sistemas de informacin". porque el propsito principal del sistema.,'')!) : . / ..
es el manejo de; ta infom1acin. Sonej.ell1p!os. de sistemas de infomlacin los sistemas bancarios, :'V)~~;': ::, . .:
sistemas de catalogacin de bibliote'(;as, y si~temas de personal. En el corazn de ~sos sistemas ,,<:~J::. : ,.'. ;:
infom1acin corno recurso. :i...os datos que manejan estos sistemas son, a menudo, ~el :recurso de \j;t:~:~i;{~'''-i0l;!:
mayor valor de una empresa, Tales da,tos Lienen relacin- tanto con los procesos ~b~O en los: 1)\c;e:r:):'}(:' l~
:recursos
internos de la e1j1presa- plantas,
mcaderias,
personal,
etc.- y tambicnin.formaciri
sobrd;y:=
i~i
-
: -
_
.
- !-r<:
1 :. \
recursos externos - competidores, proveedores, clientes; e~c~-- Cada vez ms; las' corpora.cionesJ~}
'~~
estn compLltarizando ss proceso manuales y confiando s informacin a las computadoras ..
mela es hacer que SUS proceciOS Sean ms eficientes y que Sus' datOS estn disponibles enJnea~ . ..::,ii:~:~,,,
i>t~~
Los sistemas de informacin estn orientados a los datos, y pueden caracterizarse sobre la ")}:tr.~,,~~;;,:,:~~t'i
,',. .. ', "
. . base' de la man.era en que tratan esos dJQs. Algunas. d~ ls propiedades. que caractenzan a ,los_:\cU'(:~U;:~;,;~~\i
:.
,.
,Laf'
>
' sistemas de
..;)
t..:.'l
. .
...
'
.:
~- ~:-:;..,~:_,,:.:::d:J\~ftfi:?f.{;.:~:r~J-~
:?:~;,i.
*Integridad de los datos. Bajo que circunstancias se corrompern los ciatossi.'el sistema:
..;J
fun~:ona mal?.
Cl
(')
, ,
;;:;
'
.,.~
... l . .-:.
. '
>'<.: :'~j~~f~~~~j~)
Seguridad. Hasta que punto el sistema protege los.. datos de accesos no autorizados? ..!.~:.:; :~:it~:~..._i((;~:~W~i
. .
.
.
.
.
.
.
.
. .... > . . ,:. ~-r::.1~;;n;~;ff(t1J
1
x Disponibilidad d<:: los datos. Bajo que condiciones podrn no estar disponibles los datos i:;::(~ i::;.t!.~t{
()
r':) .
'--1,-.
..
: ~i~~~~rj
~u
Jc
,j
J(.:l
lr>
;1~
. -.i:
..
...
-------.--.-.
. .
.;- .. .-,-..
.-.--.- ..
G~~:~;~
~a~
iffll :. :; ' Per f onna~ ~e de las ;ra,;sa c~io nes Dado que .le ~et8. ~e 1~s sisteril as dO inforinai n ~s
>< r '
1
. Otra caracterstica importante de los sistemas de informacin es la necesid?-d de provee~ ,.. ,, ... c~{J!.t.{ ~.1:
inter?ccin con ~os l;J!?Usarios ~ue. tiene11 'poca o ninguna t::spe~encia tcni~a .- ppr ej. ,yendedores 1 '~"!1f
~ ;~~~
. ~dmini~trativOSJ'j directores/ As; lbs r~quer~rrleiltos 'de.' int.erac7iri hmano-comp~f~~.2r~}~l.~~J,;;~{~1
~!:t
. como la amigab'ilidad con el).1suario son de P.rimera releva11c!a ~n este caso. En part.~9:\-na,<~;:esi ;:.;;jt~
~t
requiere que la interaccin cci,p. la aplicacin ~e. ?aga va men.. Los menes de9eria'!J: di~e~#se de:: ,i~}:i~?j
:rr
manera unifonne', y la navegaCiil entre las distintas ftmcion~s ofrecidas por la. aplica~in, deberi~.:,1:(~f~~;~~~:.
ser fcil. Los usuarios nunca.. deberan, sentir~e perditlos; , deberan poder', cbntrolar :.sienipre: la,;):~:it}IIJ.{
intericcin de la:plicacin, y la apl!cacin deberla proteger al sistema de un mal uso poi parte
}::;,;~;;Jt~1!;~.
los operadores. . :
,
.
,
.
.
; \. . '. >,';::>M~:)j.j~.~~J
. . Los mod~mos sisterri~s de in[o~acinapvntan e~1 esa direccin. No slo provi?P,:}:l!},f(lci!::;~;Jgz:t1?,..
<:
acceso para el U$uario, sin_ q~e tambin lo alient;1n para la creacin de .apti:~cione,s, 1.~~plf~: En :~~t):l,~~?lli~t:~?~~f 'Wf
lugar de depender de espectaltstas para hacer programas ad-hoc para, por.eJemplo, tener nuevos ::;,',,~:~;.;.!i:;J~.-.,.,:S
lis.t~do: de la b~se qe da'o~ o ~:o~~ui'tar a _la base d~~ wui m~nera d.istinta, el.u'sio
p~._de. usar :::{j\};~!,;i}f.J~1i~fiK
utlhtanos provtstos por el.sJstema de mformac10n para resolver este tlpo de problemas. Esta:::;~ 1:;: .;,~:~;;:'j}. ,;;h
c~racterstica se llama a me~udo."c~mptacin del usuario final":
..
. O;:jt,.<i~J~:( th~~:
?e
final
).
eventos dentr.o de un perodo de tiempo estricto y predefinido. Por ejemplo, en mi sistema de :::. :. . ;-,-i:':';.'
mo1J.itoreo de fabricacin, d software debe responder a un rpido aw1iento de li temp~ratura' ; ..,:-:; :, :,,. .,; . .,':
accionando 4eterminados c;o1~ando~ -~. oien..baciendo sonar una alanna.
un sistema para guiar u;:~~!~i~(;b<H.(/
misiles necesita monitorear petrnarien~emente las condiciones ambientales y la posicin del misil.; :;Jjff(.' .:::;o;
para corregir su tray~ctoria adecuadmente. .
. .
,
. . ;~
:;;!.~i;:,i,'f
'
Si bien la clasificacin de tiempo real se apl~a generalmente para referirse a !us' :;~.4(/:Uv.':.<~?:::;
automatizaciones de fabricacin, sistemas de vigilancia, .etc., se pueden encontrar requerimient~s ,: ;1::f:.~!;');f![,t/:
de tiempo i:eal en sistemas ms tradicionales. Un ejemplo poco usua( pero interesante, ~s el d.et. ;:;:~j~{-:1 :;~!0~\t\.
softwa,re que maneja el mouse de Wll computadora; elcual debe responder a l~s interrupci~nesT;;:::{!j)ij~:;:,v
generadas por el click del :;nouse dentro de tm detenninado perodo de tiempo. Por ejemplo, en. . ::;.:;~:<
algunos sistemas, Wl r~r.o click es lUl comando para seleccionar un objeto mientras qi.te un doble
,, ;, ..;~
clic)<:, si los dos clicks ~:stn lo sufi~ientemerlte cercar~os en el tiempo, es un comando diferente ,: 1 ::,:, :~:.
para "abrir" un objeto. Esta clase de interfase establece tm requerimiento .ele tiempo real en e[:.,'Y~d;-~~J.I!:.,,~::.;:.
software porque deber procesar el primer click lo suficientemente rpido de manera que 'pueda. :::f?;)~:;J~?;!'iii!:'
aceptar una 'segunda iaterrupcin y deterniinar si el usuario ejecut un dol;lle click o bien dos. +t!,:(::~;~i';.{'.
nicos clicks sucesivos.
.
.
.
. ,. .. '; ;.,~'{{~).]~fL~;i;;~~~
Existe una mala interprctaci~Q_respecto del tiempo real, que lo defne comQ un sistema que''7:f'?(~~'?:~:
.requiere "tiempos de re~.puesta rpidos". Esto no es verdadero ni suficientemente preciso. La ' . ,:
"rapidez" es una propiedad cualitativa de una aplicacin : ro que se requiere para un sistema en
;,
tiempo real es WJa nccin dd tiempo de respuesw. que sea cuantitativamente esp.eCificable y.
. verificable. Tambin, en algunos sistemas en tiempo real, una respuesta que llega deiT\asiaclo ,
..
temprano puede ser tan ir.correcta coh1o wm que llega demasiado tarde. En el ejemplo del mouse,
,. . . , .''
,;,;;;;.,;';:;;
()
C)
.c:~
,;~
().
Q
!5'
(j
...
,,
_;.1
G.
(j
e>,,
1,:&~
;;;11?(
.\.o ~f~i''l ~:,"';~ ~
[> '.
...
:::~::~~~~~;~'-"':c~:~;~;:;;;;~:~;;!;;c~~~:~~~:~t~~l~~~~
.. . . . . . : :
..,
,@ ~~:~c~~~~~;edi~k
se
pro~:esa
dernOsiado.
no m
d~~eciOd :''li~f
Los sistemas en tiernpo real han sido estudiados por deteho propio. Podemos d_ecir que los ., ., i~'::~z~h{{::\;
sis_tem.as de infonnayin estn orientad~~ a lo~ da~os y que .l?s sistemas en tiempo r~al estn ,: :::\:.r.fma:~f:~_,- '
on~nt~dos a los _controles. En el corazon de un SIStema de tiempo real. hay un "plamficadorn ,.;~:14;,! ''. :
(scnedu.ler) . que ordena o planiflcp. las acciones del sisteiJ1a. Hay dos algoritmos bsicos. deif-:[i::-7"':;<
.
pla.r:fca~in: pr ~nt~rvalos (~ea~lne) por ?~oridade~. _E~l~ plani~cacin por prioriJ,~q;s;~ a.da)~::U{):
~c;::c~on tiene aso.ctada una pncnda~ .. La accwn con la. pnqnda~ mas alta. es la que: s_e eJecuta ,>;;J:,\:;: .
.(j!,ij 1
. F.r_irero. E:~ ~a .?_anificaci~Sl). _por i~:tvalos cada ~ccin tene .'":~pecificada un tiet~lpo''dentro. :?e";-:,!fJ~t~;, ~tJ.;j
..c~?-l.debera m1ctarse o_ b1en finalrz~r su tare~.. Es re~ponsa:btlJda~ :l pb!1!~c::~~~or:_(s~beduler) .i,!\(r(~:~:::::;t;;.l2 ~!_
ase~ITars~ .que ~~as acciOnes se pla:mfquen ~e. tal mane m :qu~ sattsfagan los requenm1entos de~,~;;:::"
lf:ti:~\
1
plnmficac10n.
.
. .
~. .
.
.
. , .. ,
-'>.:_ :i(f:.
;
. . : Adems de las propiedades 'genricas del softwar~, los sistemas en tiempo re a~ se defiri.eil ;:;~~:1! ~~:ii'-~:
por la exactitud con que satisface) los requerimientos_ de tiempo de respuesta. Mi~ntras que en : g.:::;:{;:;~((1.
otros sistema~ ~1 tiempo de re:spue~ta tiene qu~ ver con la performance, en los sistema~
tiempo _.:;;::}f;~h:JJ:~~~~d
i~al, el tiempo de respuesta es un ciiterio de "~orreccin". Adems, los sistemas. en lieinpo real,son iA;~~(;;:l: i~\~1'
usados genenmente para. operacion.es .crticas (tales como If!.Oi"Iitoreo de i:mcie~tes, sistemas
.!.'<[?<fL,;;. ~Y~1
~ef~nsa, y control de procesos) y tienen requediierits de"i:~nfiabilidad niy_ estdctos: (S_e ttli.!i,za::i~~':.Y:'t~~~K "' ';;
. 1 . . 11
11
d" f . !
.
1
)
':l.:.- ~
e termmo mtstoncnt1ca para emtrtaessistemas .... ,._:1~':.
. . :;::~.:
:, . ..; :.;~i_<.~:,
.:, .: ... En e~ caso de sist~rn?-5. altamente. crticos;.se, usa:~: menudo el tn~ino seg~1/idad
_:-r:::"/m. ..
re~arcar: la ~nisencja de cRmport'mientos inde~~~bt~~ q~e _puedan provoc~r riesgos en el sistema. ::: ;qHf,~~;:?:.~~~~~
La seguridad _implica ms r,equerimientos_que los,de una misin primaria y exige que el sistema se :_::.~ :;~!("~\'::
. ejecute. sin causar riesgos' inaceptables .. A. diferencia
:los requerimientos funcionales," que ; o~ ~~:':fT3:''.
':,describen el comportanemo adecuado en trminos de relaciones de entradas y salidas, los :<:.:-::,,:.~):
requerin1ientos d~ segurithl describen lo que nunca deqera pasar mientras se ejecuta el sistema. :;:!:!/<~;_:.
En cierto sentido son requeriment::>S negativos: ::!specifi.ca.rr los estados en lsqucel" sistema jams ;.,.
debera ingresar.
:i
.
.
;
.
.
.
.
~ -.' :_ ':_.
; finalmente, hay otr.a_s propiedades q~Ls.of!ware .qu_e tambin podran ser importantes en el
' ~ ':
:.
caso de los sistemas en. ti.mp<rreaL Hemos 'visto cue los aspectos de la relacin hwnanocomputadora son importantes en 'los si'stemas de infonnacin. Y pueden ser an ms irnportailtes
:
en d caso de los sistemas en tiempo real. Por ejempo, la i11terfase extema de un sistema
control que monitorea una plan;ta industrial crtica, debe e_star diseado de tal forina que el .. J:.
operador comprenda c!aramente:el estado del sistema bajo control. para que as pueda oper_la
...
planta con seguridad.
.
1;Mj
en
de:
'par?- ,_.
Jt
de
de ' l .' :;
..'l
.~\
_._;
~~
?~
.......
<J
..
en
Los avances
la tecnologa de redes han hecho posible la construccwn de los as liamados
. ..
sistemas distribuidos, q~e consiste'n en computadoras indep~ndientes o semi-independientes, . ; :: . : .. :
cone~tadas pr una red d_e comunicaciones, El alto ancho de banda y ei bnjo prQmedio de erro~es; -':-~ ,_'..,
hace' posible escribir sisr~mas de software discribulqo"s, es decir, sistemas con componentes que se :};-;.;.:~:ii:i.JH;,::
ejecutan en distintas CO!nputadoras."
. .
. . . .
.
.
. . . ; >1{;:?".;;'
Si bien aplicamos las propiedades genricas del software a los sistemas dislribuidos, s~ ~A;<:'ff~;
agregan tambin algunas .: :;evas propiedades. Por ejemplo, que el ambiente de desarrollo del. ~:. _. .. Ii'
software soporte et desarrollo de. software sobre mltiples computadoras, donde los usuarios ... :.. :~.
puedan estar compilando y tal vez haciendo lihks en diferentes e~1uipos.
.
..
Entre las caracterist~ca~ de los sistemas distribuidos estn ( l) la cantidad de distribucin.::::.:.<):.
soportada- por ej. estb distribuidos los datos, los procesos o ambos ? (2) puede el sistema :. ; ...:,,.':
A\o.-.. ~ .:_ :.
..
-: ,,_.,
-. ,_ ',"''' ''.r"'',:-:HdHo;-
... - : ..
~:'";:--:-:-
:.::o ;-o.:~.'"''""''''"'~'"'"r'
..
l . ..:
~',;'~o:-0': OOo:to~
rolerar el pamcwnamiento de la red ? - por ej. cuando una mala conex.in hace imposible la
comunicacin entre dos subconjuntos de computadoras; y (3) el sistema tolera la falla individual
de una computadora ?
Un aspecto interesante de los sistemas distribuidos es que ofrec~n nuevas oportunidades'
para conseguir algunas de las propiedades discutidas. Por ejemplo, replicando los mismos datos en
ms de tma computadora, incrementarnos la confiabilidad del sistema. O distribuyendo los datos' '
entre ms de una computadora, pouemos aumentar la performance y la confabiliuad. Por supuesto,
replicar o distribuir datos no es tan simple y requiere un trabajo de diseo significativo. Existem
muchas tcnicas establecidas para tratar estos temas. Veremos algunas en el captulo 4.
'1
:..
~~~:
}\ ,.
.. .
. , . _; . ..
. .
: . :~ . .-:.-~A{)~:
Una.vq. que hemos definido las ;propiedades que son la meta de la ingeniera .del software;~::
necesitamos principios y. tcnicas 'que. _no~ ayuden a. concretarlas: Tambin necesita[nos. po~.e(i(i~~;i?J;;:~~r~,
)
me di~ una determinada propiedad.
, ,:
; . _. .
. . .
-. :>T: .,': .: ;.;~( ]\:\'.':t~t~Ht~l. ~J:. ;;..
_...
.
.
Si
identificamos
w1a
propiedad
como
importante;::_querremos
r_nedirl_a
_-s~b~r's(rios ~;;]';:~i~~JJ'' \;;~f!n
1
: . . _ac;;rcaplq$ a: los. _valores esperados .. Esto .n ..:;~,-y~~- F,~qu~~~e" que definamos. cada proptedad ,_de::':~~:-;];.;~;.
"~ h;;
) ' : ~i~~ra preci?a
que quede claro qu esu1-ios mld1end?:.s.q_h1ediciones!cualquier_ pe_d~"do,p~ra_:),? ..
l';':
)
-~: meiorar el sist~ma no tendr !;>ase de susten~a,cin.-.Pero sin~U[l<{pefinici~'pr_ecisa e.la.'pr{)pit!,da"d~\
no hay esperanza de que podamos medirla con exactitud.. ~-~:.;~\_:' . :.,. ... : ;. .~?!(;~. :.. ' ,?L~<:. :~ /~~:wr~>
:''' : Las dis~iplinas de ._ti. ingeniera:_ ~~isie.re~ .~tie'n~~:)cni~asst~~d~rci:'. p'~i:~,}i\~cf:;J~,_:;.,
propiedades. Por ejemplo, la confiabilidad de un amplificador se puede me-dir detern1i~'ando l_{~;~~ .... , ..
-";.
rango dentro del cual opera. La conpabilidad de un puen.tc -puede medirse por la presinque puede).f';'~(,'}]f/~~~fj;_
. -.\
....
soportar. Incluso, esos nivel-es de tolerancia se entregan junto con el producto como parte de las . :: .:~:: .:':: ~;;}\(:J,
...
especificaciones tcnic-as en el mauaL .
; .. ' .
, .
.
.
: '. -'~- ;_ .;. , . i i ,: _;,::.:, . ;:; >~~;.!';";~.
, ,
. Apesar de que al~unas propiedades. del sftware se pueden medir fcilmente,:~t~l ~orril~j;~1i:(J';;~~(,gg~~~;f
.....
,. ;.
perfom1ance, p~ra la may_oriade las propiedag~s no exist~n mtricas universalmente aceptadas;{Poi!~
t~J+~:i.i.K,\,
; ejemplo, se q~t~rri:J.ina e ITElera subj~ti~~~ si. Ut~ s~~~~rr:a e~o\ucionar ms fcilmente tlue.olro.No'Hi
r];J:~';ti:~F
' . .J
obstante necesitamos mlricas, y en al actualidad s~ est dedicando un gran esfuerzo para clertnir :'>'i:8%_f:f.i?}!f~#if~
.
.
.
' :
, .
.'
' .
' --~:
.
. .
..
. .
. -l!:'.-~!.:::;:'!,.~~--::::; ..;.~-'~::.
mtricas objetivas. En el ~apttulo 6 e:~al~lma_r~t1:1?S1 :~~~~- tema en profundtdad.
.. : :.,,~;,i;3),j.\)\'p~:J;;!)'
'
-, '
)
para: _
pa.ra
~-
.?\
'';. :;:~~~~})
. .
2.5 Conclusiones
:.~
...
,.;._;).
''
.. .
:: ;
0:
La ingeniera .del soft\vare consiste. ea la aplicacin de Jos principios de la ingenira para la.
{;j';;.':i
fabricacin det sofLware-:Par2. poder dertnir ui1. co1~unto de principios que sean unioni1emente :. :::~:
(>:
aplicados a una variedad de productos, el primer paso es elaborar un conjunto de propiedades que.: ..~;i\L S}>
caracterice dichos productos. Eso es lo que hemos hecho en este c.aptulo. Presentamos un ~~:t::; '',;.1i1-/
conjunto de propiedades q~!e determina el Jn_~rjJo de cualquier producto de soft,vare. La prximat>if}._': ..
tarea ser apren?er qu pr.inci:ii'o's'aplicar para .poder .constmir software que cw11pl~ con esas.:: !_::....._._::- .
propieJaJes. Ese ~s ellpic:J Jel prximo capitulo.
/:<
~Hs
2.6
!./
(:jfi'!i'~f(~
ejerdcios
En este capitulo hemos discutido bs propiedades del software que consideramos que son
las ;ns importantes. Otras propiedades son: Faci1idad de testeo (testeability); Integridad;
-
Facilidad de uso, Facilidad de operaci:1; Facilidad .de aprendizaje, Defina cada una de
estas propiedad..;s - :r otras, si las hay- da11do ejemplos y relacionndolos con las
propiedades que di~.cutimos en este cap_tulo.
,,
:_; ~:-:
,.
, _1
',.- ,:..
:1
2.7
.. 2.8
en
,:':.:y,~~'t,':;~)!)<~
.
1 .
--~~-
:J'i\~ii:[
' . :-
-~-~"-~ ............. :---:- . . . -".,. ............... ---~--:- .. , ...,::.,.:', ..... :..._~ .:~
-~--- ------' - -- : ~ ; __ ----- ... :- r_ ;~--::-:-.~:-...--;: :~ ~--:.- ~-1 ;.:~- -~-~-~::~.:;.::.~~~~ :.
- ., - ---. ,.-:..-
..
: ..
. --- ..
. .. :.
' 1
/~ "-
:: :. ;. .: :'~.:: ;,.::_::.=:::_:_;:;:::~:~:,;_:_:::~~..:;: . .. ..
Algunas yec~s, un nueve admin.istra,dor usa mchas de las tcnicas qu'tiliz en "su'~~.':t'~,,~>~.:,l:::'.' ': ..
proyecto ms reciente. Usando. esto corrio ejemplo, discuta el concepto
reus~nilid~d :o: : ;'., .';
. aplicado al proceso del ~oftware.: :.
.'
; (\) 2.9
de
2.19
,
.
..
.
'.
.. .
, ... ..
-' .
.
Si est. familiarizado con los protcolos ARPA para ftp y t~lnet, discutasupapel'enh(ri~):.: ,::r:
:
inreropratibitidad.
t.
2.1 i
:~-
. . .
. . ..
.; .
-o.:.- : . :.,..} :
,' ; ,.. ; .
podemo::; hablar de intt-:roperatib:~idacl c.le proesos. Por ejempl.o, ei proceso seil!id
'
..
-:.. "-< .
asegurar i.ma organizacin de,be ;:,ef COl~~p:::~i':J!~ (.;Qn -::\ p!oces~. ::;egut~O
~J;:-, ~.
:,
para:
p&ra desa:'rrc;lJar\<~0':
Otro ejemplo puede ser el de una compar1la que c~ntrata una organizacin indepeildiente .: . : .
,:
~!. _:; ,;.r. : .J
Pis'tas y yudns pai-a las solucione~
. .
2. J
-:::-
,,
.= ._:{Z:;;~-~. ~ :(
.. J~~!.r~j:l?: . _,:-.~.:
:_:.:.
~ ;_~: ~- ~:
: ... ' .
.... ;
. ;'
.. .,:-.o:,;:
. ..
-~
1.''
'
r.
. .
En alguno~ casos, las decsi~mes sobre la interfase con el usuario puecleii afectar _t
,
confiabilidad del sistema. Por ejemplo, debemos a.seguranos que dos' teclas que'producen :.. :
dos .comandos diametralmente f:mestos, no estn ubicadas una al lado de la otra pa;a; ' ' '.:
evitar que el usuario desprevenido accione una en lugar de la otra.
i
\,;;:?:lhi1i.:.:<;r., .
A medida que los con~.ponentes se reutilicen ms y ms, se volvernms c.onilabtes, dado . :~}:;';,,k;.f~;:~J~~;}
que se eliminarn pro;sresivamente los emores residuales.
'' .
'
. ~~
...
...
),
..
-\
i\J~i~
'
:;i
::'
~: ~.:~~~~
.....
_;J~t/\
..
! ..
.~ 1
.....
..~
.:::.:;_;:~~
':)
'
'
,:/)
.:
,.
r.
,,;)
'f)
0.
1,''
---'
--~
::.)
.,
,:"\
~- . ?
()
'e.-:;
..,.
.
;
. .'
-~
i.
. '
:.:;:.:::: :.:.~~;~:~:;~:;~~~..:.;:::~.- ~;;.~;;;,~~,,ir.-, :7;~=.:;;:;;~;;:::.;.-;;.:~~:..!.~~;'f:;,:,:~:~~;6;~+;,~::: ~,: :~ ;~~ .~ ;:~~ . i .;~,~\ ;;;\~.:,!;f~i.~rJ.~~Ev~:.;:~~i;;.:p ;;;z.Ni?~;~;H~!=.~ ~: i
''
~:"~;::~?t,;:-.
....
... . 4-! :
r:~i~*~~~=;;&~~-~~<z"";:,a~~"'~y~~
i\/ _:,Ti]1:f' \,
: .
Princi p
___
. -_- __-___ -_ __
:):,{":,:;:En' ~;>t~c~pt~lo, slis9utiremos algunos de los imponantes prin~ipios generales 'que. so~,;,: ... .. :.
.::/~:':':. p~r~ )ll}, exito~o, ~~sarf9llo. del software. Estos r,rincipios se refier~n t~.~to a ~O.s~p~?ces~,j:~~i-!~~~~g. ...
"::\:~i ; d.el ~of1ware com? al producw final. Un pr~ceso c.orrecto ~()ntn):>Uua a prod~cu el pro9,~ftO
;~: ;' "pyr9 ~1 producto .desea~p influir t~mbi en la.e.lecci?tl.del pr.c;>ce~o.a util~z~~(:[J1tl p~o~r''"
1~;.., .:.;.~.9:tla ingeniera del softvyar~ );,a sido el poner enfas.ts ya ~~a en el proc~so;, o en eL .. ,
;.~.).;.''exClusin del otro. Pero ambos son importantes..
: ' ,:,
Los principios que desarrollamos son lo suficientemente g.enerales como para po.der ser aplic . ...
]'J) . : .a todo lo largo del proceso de cp.nstruccin y gestin det software. Estos principios, sin embargo, n9. soh
:("'
suficientes para conducir el de:::arrollo del software. En realidad, son principios abstractos que describen: :,:e,
(:;;
las propiedades deseables para los procesos y el producto. Pero, para aplicar esos princip~os, el ing~niero. :'.: (~ . ,.
del software deber estar equipado con mtodos apropiados y tcnicas especficas que ayuderi a ; ::,'
.
~ncorporar las propiedades deseadas a los.procesos y productos.
.
. .
.>. :. :::; . ,:, .. J.;
;(;)
En principio, deberamos distinguir entre mtodos y tc.nicas. Los mtodos son pautas generales:::/' '<t)!
: (.)
que gobiernan fa ejecucir; de: alguna actividad; son propuestas rigurosas, sistemticas y di.sciplinadas. ;... :'.~; :::i'(. .'':
(Las tcnicas son ms tcnias y mecnicas que lo~. mtodos; a menudo, su campo de aplicacin est rn~d"\~
restri~gido. En general, siri. embargo, la diferencia entre los dos trminos no es tan pr~nunciada. En ,;;(k
~ . ~/ .\.- ConSe!cuericia 'usa~~ntos arribos trriinos indistintciill:erite}:.
.....
:_:~ ,. ,.
~.-:~.- '<(, :.:: . A veces, l~s mtodos y tcnicas se-~grupan. para formar una metoUologa. El propsito ele
1
.,:.metodologa es adelantar una (:ierta propuesta' para res'olver un problema, preseleccionando los mtodos y!
, r,F.1 , . 'las tcnicas a utilizar. Las henan;ientas. su vez, se desariollan para sustentar la aplicacin de tcnicas/
1l ~~.
mtodos y metod. ologas.
:
'
. :.
.
.
:..
.
. . . La figura 3.1 1nuestra: b relaCin entre prindpios: 'mtodos, metodologas y hermfnientaos. Cada;
~~>;
capa en la fig\lra, se basa ~ri,:.a capa anterior y es ms suceptib!e al cambio, debido al paso ele\ iiernpo.i
.1 '--.
Esta fi,S'1lra mi.testra claramente que los. principies soi1 las bases de todos los mtodos, tci1icas,!
jC
metodologas y herramieeta~:. La figura taniP.j~!J .. puede..explicar la estructura de. este libro .. En este:
O
captulo, presentamos los princi'pios sepciales de i ingeniera del software. En los capitulas ~1 .. 5 y 6;
!ir)
presentamos mtodos y tcnic~s basados en los principios de este captulo. El captulo 7 presenla alglmas
[ (\
metodologas y el captulo 9 r.liscute herramientasy ambientes.
'
!:) :. : , ,
r:.. .
:1;: . .
: . ,: :. .
1
las
m1a.l.
~~~~:
~~( :.
Figui-a 3.1
Reiacin entre principios, t~rJcas, metodologas y herramientas
l.- Herramientas
m.el
; ~i:;
2.~ Metodologas
~~
~~C~
;6
~ ~
!~\
~
..
me
~C
'
:.?, .
'
~ e,.
:f~ ~3 ...
~
..
'~-.:/\.>;:.\:'
:~~.\.
.. :. ' ,<;~ .
.
'.f :.'.!,
. . . ::
<!
.t.:spera que -los usuarios tengan muy poco o_ ningn conoclmtento sobre computadoras y softwnr. O.
.
podda ser necesario soportar una aplicacin crtica, en la cual el efecto de los errores puede ser serio y .. _"'
hasta desastroso. Por esta y otras razones, la. aplicacin debe ser confiable.
'
Tambin suponemos que ~-~-Qlicacit_u~sJo ~IJD.C2~~1:\1~J.P.~I)._t_e~_g!:_-D.4.~.Y-~9!~2~l~P~~!:~q~:~_srJiJd.@.. _: - . ;> '
descomposicin en partes maneja'Jles. Esto. es especialmente cierto para el caso_en que el proyecto ser.:".-<:.:.::_~!-;,~';
'cies'irollaac)"f:ior.l'm eqi:iip0.'1'ro-1a-lbin es cierto en el caso en que un {mico ingeniero del software est ~ ; -_,:;; ;.,; :~_;,
-:<.!
..
-~~~~~~~ol:~~:~~~Jid~; ambos casos hay necesidad tl~ uua pr~puesta de d~-~~sl_Vq__q~l__-~of!_\~ar~ qhl~. _.._.:..- -._: ~-._ -:~ .- ~'-, .:_;':!t_.' l_:;~-:_; !._~:
_='_:.:;__
__
-------'En todas las--r1reu.:.~stanf:ia;; aP!eriorf"s, !Gs cuales representan situciQ11~?.J!Ricas del d~sarr.ollo del __
softvvl.;c, ia Cui>ctbili.ad y ia e~::ol~tividad juegan un papel especial. Es1 claro que, s_i_eL.o;r:_f.:w.are_!22
::..;>!:',-;_,
~Le~.:__IOS-rQ~~ri~ei1~?.~-9~ ...c.o_W}abilida~__ ~y9liilv'C1iCia-neceS!dad de principios y tcnicas para la
.' :
ingenie_r~ del software, disminuye. En general, la eleccin de los J2rt:g.s;_i_J2i.q.? Y-J.e.~n,\~a~ _est_ delqmin.~
,1 . ' '
_or las metas de calidag_ge softW_!:lr ~-~~gic!_~~:.
;_
. En este captulo, discutiremos siete principios generales importantes que se aplican a lo largo del
_.:;.<:.
proceso de desarrollo del softvvare : rigor y formalidad, sepa'racin de los objetivos, modularidad,
. :
abstraccin, anticipacin de c2.mbio, generalidad e incremenlalidatl. La lista, por su propia naturaleza, ni.) ,{1\~_;~_._:.~_
puede ser exhaustiva, pero cubre las reas importantes de !a ingeniera del software. Si bien, a menudo,
los principios parecen estar fuertemente relacionados, preferinios describir cada uno por se~arado a :. :.-.
continuacin, en trminos gen,~rales. Los abordaremos en tn11inos rn.S concretos, detallados y
especficos, en los captulos siguientes. En particular, el principio de modlaridad, se presentar en :ei '
. captulo 4 como piedra angular del dis-eo del software,
,_,.
__
i,
' '::::.::=.-
, . l.J'o es necesario ser _siempre formal durante el diseo 1 pero el ingeo.iero debe saber cmo y cundo
ser .formaL Por ejemplo, puede cotar e u la experiencia pel pasado y en reglas emplricas, para diseilar un
pequeo puente. que ser \.1sad-:) temporatiaq-ente para conectar las. dos mrgenes de un riachuelo. En
cambio, debera usar un model-:) matemtico para verificar si el diseii.o es seguro para un gran puente que
se usar de manera pernJ<li~enl!:_ Tendra que, usar un modelo matemtico ts sofisticatlo si el puenle
inver;sa' es
.. ?
...
;1
~;. :
, . ..
~- ..
:;~-~--_-
-: .:.- . :: ;-: -
.. ..
~:.-:---:.~: .-~ ~ .':" "-:::=:-~:-;:- .'" !'"';"'~, . : : 7 ... ~- :"" -~: , ........... : : - , ..... :--- --::""':-~-- .~,_ :~
.. ........, ..._,., ........ , ...............,_ ............... ..........., .. . -- .. ,.... - -------- . ~
,. ~
-:_
.~.
.'
l@t...~~ra e~~epcion~lmente
:_-::.-:::-
.<-->:--: ~
~-
1 :
ira
!
!
i
; -'" . . . . . ... - .
: : :.:Lo mismo s~cede con l.a ingeniera:_ del. ~oftwar~,!j~l;~~Pt!tllo 5 profundiza este. tema en el contexto
de .las ~specificaciones del softi:are.! De"n1ostrarernos::qu~Pa::descripcin de lo que hace un programa
,. p~~l~?-~.~.r~~. ~e ;;una ~aner~, rigl?os_~:~~~,r1~o..;;l.~~~~?-jf}::.~atural; tam\?.[~~:~~~-~~---p~~~e describir
fom1al~ente. dancto.~.\.~1a desc~ipcin fonn~l'.:e~, :\\P;')~h~~}.tje: de. sentenc_i_a~ J.gic~.~.. La ~~!~ja__ ,?~. !__!
formahda~Lsobre el ngor es.. que la fom1ahpad. _pue~e.;;s~r la base de la mecamzacton del proc.eso. Por
. ; ej~urio puede esperar usar la' descr{pcin form<a:~e prb,aina pa~a crearlo (sl'es "que el pro'grama
no existe an) o para denioslrar que el programa. se:. corresponde con la descripcin formal (si el
!
'
. .
...., .
programa ya existe).
Tradicionalmente, hay ~lo 1.ma_etapa .9~~~E:oiL~del.2_Qft~are ~!!Ja..~~u.al ~-~-~~.':l:_.la .P.~.f?.P.~~_sta
formal": l~. J~I.Q.m:,~macin. De he:cho_._L~.~- P.J..Qg@_ma~- S9~..?.~J~!os for~~~~ : estn escritqs en un lenguaje ! .
! ..
cuya sintaxis y cuya semntica estn completamente defini-das. Los pro~son_Q.~-~FiP~_0_~~~ formales
que pueden ser manipuladas automticamente por los compiladores : se verifica su exactitud,
1
trans"fo~i1 t1 prograiila e ci i.vlen te""ei1 o"-o 1ngije (ass"il1 Gl[ o 1enga:jecre_rl}q\:iJn.)..l.-~!C... EStas-; .
. operacwnes medriCas,-~so:l.-posibles-gJ.cas-ar-so. de.Ta ...forrnadad. en. a .programac:}.n, pueden /
n1ejorar electivame~~J~~nfial2_.llid0.SJ:' 1!LY~I.ill~-Pllf.diliC4.~jQ_sJ?.r.9!.h1~~g~~l-~q~ty.,rare.: ..-... .
-~
El rigor y la formalidad no estn rcstrir:.g~~~~ a_! a J?!gg.:..Il!~.cjn : <l.~~Iig~lic_g_!l;_~. _lo .Jargo_<.\_e
todo el proceso dci-5-oti\v~tre~Ercapitulo 4 muestra estos conceptos en LJ.ccin para el caso del diseo del:
"S"oftwre:El Captlo 5 describe propuestas rigurosasy formal~s para las especificaciones del software.
.1
el captulo 6 hace lo mismo pq.r:1 la vc:rificacin del software.
.
.. \
' Hasta ac, nuestra discusin ha enfatizado la influencia del rig.or y l<L.fu..[Dl3.lid.ad._e.Ll~
::.
cQnfiabilidad y verificabU_Lciact de los productos de softviare. El rig_or )1 la forJllali.9.?.c;\..ta~~1bln_ ~ienen
efectos beJ!ficos en mantenib-ilidad: r~usab\iiciacCportaFi'lidad, comprensibilidaq e interoperatibiliciad~
Po( ejemplo, una documeii."tci!l.--del soft~vre --rigiirosa- a!1--forral"-puCl --ine}orar todas esas '.
propiedades en oposicin a nna docu~nentacin infom1al 1 que a -~;:wao-es-a1bigua,Tnc.6!1sis""tei1te-e -irirtpl"eta. ---- - - --~~-----------.:e----.--~--
-
. --- ----:---------..
sefOS
,y;
la
.il...!ig~y la J9!malidad tambin se. aplicari a_ ~.os procesos del software. Una docurnentacn
reutlil"zaci"I1 en
proyc.tos--simllars.-Basadosa
rigurosa de un proces(~fav"oreee.
d"cwentaci;~ .. ios..T~genicro:; pu~den ztnti:::~P~_r_ ..~os p~sos
.los . q~ -~~olucl;;~reL. nuevo proy~c:;to,
los ..recrs.os apropial.cis ..
se riee.s1iri, etc~ Asimisn1o:una-dc;~~~;ntacin !igurosa
d~l ..
d! soft\vare p~te:le. yudar
i-i. proii:icto existei1te_--S-i se. i~at; docwnet~t;d~-lo;
disli"tos pasos .a. travs ... d~ 1:)S cuaJes ha. evo!uCio-a."do erp-roye:Cto, --;-~- puede-nocii"fic'r~;;~ ...produ~t~-:
su-
s!gnar
p.rces
ameCiaa-(uri
a:rrliieriei. .
otrosen
.
en
-.
. -
- ---.
. .
. ....
'~
-~
.. .:
. :
.J
......
:'
_.;,'
.;.!
,_....
::~, --~-..
. : . .
/1:
.. ----::
---~
... ~-- .. ,_. -~- - ... -~ . . --._- -:... - -~ ::-: .. :- ........ -. - - .. .. . ... . .. .. . ... - ...-: ~ ..... - ... :- -. ......... : .... i. :: .. : ..!. :
.. . ' . '
.-.
-.
---~-.:._.;._
'
: ele ,,ista yanaiiZailOS-pOr separado. Por eje1nplo, al analizar los requeri1niento_s de un aplicacin, puede
;_
. ser 1:1rconcentrarsesepa,1dai11ei1te en el flujo .de datos_ de una. actividad a otra del.sistema y en el Dujo
:
!de control que gobi~ma manera en que se sincronizatllas distintas ac.tividades. Ambos pW1tOS de Vista :- _:
~
-~ :~o~. ayud~n a .comprender mejor el sistema en el que estamos trabajando, pero ninguno nos da una visi,n _ H,,. ,, j :=:~
completa de el.
.
: ;"'. , .. i
..:: .. , _, Hay incluso-otro tipo de separacin de objetivos que trata l~s lliferentesparteS e un sistema; ~c . >:::!_!. :~; f
...:,la s~paracin es e~ funcin c!el_tam~o. Este es. un concepto .fundamental que necesitamos manejar para
:l
la
r .,
:' .: Podramos _sospechar que hay una desventaja en la separacin de objetivos : al sep:;trarlos en dos o
.
ms partes podramos perder la optimizaci-n globa 1 que se obtendra abordnd?[os jtmtos. A menudo
'' .
!
. esta objecin pone demasiado ~nf::l.sis en nuestra ~labilidad para tomar decisiones "ptimas". Cornbir1arid6
_.d. _:. !
.. los objetivos, es ms probable que to!Jlernos las decisiones equivocadas porque no. podemos vencer la '
i
complejidad. Ep cambio, podremos superar la complejidad globl de un sistema, concentrndonos -en sus 1 '' .: ;
dift1r~ntes aspecto~. separadamente, an a expen$as tle pen.ler alguna optimizacin potencial.
, /
.;.
. . _: .. _- Ntese qu~: si dos aspectos de un problema estn est~echarnente relacionados (por ej. no podernos 1 ! :::,.:
separar el probleffi.a en dos partes), a menudo es posible tomar algunas decisiones genei-ales y luego ! >}it-~\\.11:
ef~~tjyamente sepa_rar el obj~ti~ en sus distint~s partes. Por ejemplo, consideremos n sistema en el ;, . ._<~~;.!}
cual' se ~ccede a umi base de datos en forma concurrente mediante transacciones on-line. En una primera : .. >;,_: ;;imple~'i~ntacin det sistema, ada trar1sacc1n bl?quea la base de datos c_ompleta al iniciarse, y la libera al ' "-'-l'"'"'
fin~iza[. Supongamos ahora qne tm anlsi~ jrcl.iminar de la perfonnance, nos demuestra que una ! ,
lrans~scin t (que podra ser ~ gn listado complejc q~e extrae datos de la base), demora ms de lo que. l.; ', .:
podems tolerar para dejar la base de datos disponible para otras transacciones. Entonces el problema es :
corregir la implementacin de manera tal que rilejore la performance manteniendo la correccin_ gel"!eral i
del sistema. Se puede ver clara:nente que los dos aspectos - correcin funcional y performance - estn '
fuettemente relacionados. De e~.te modo, una primera decisin de diseo debe considerar ambos : t no i
. puede ser implementada como una transaccin atmica, sin que debe di~idirse en varias subtranscciones i
tii ; t.2 ' ........ , .. tin cada una de e'<las.almica. EsUi."1'1ueva implementacin-puede afectar la CQtTeccin del
sistema debido a' una posible intercal~cin entre dos transacciones. Ahora, sin embargo, hen:~os .separado:
los dos objetivos; la vel'ificaciride la correcci fw1Cionai y ~1 anlisis de la performance. Por lo tanto se ;
podrn hacer anlisis distintos, incluso: hechos por personas diferentes con diferentes experiencias.
Como observacin final, ntese que la separacin de objetivos puede derivar en una separacin de
responsabilidades para tratar diferentes aspectos. As, este prin~!P.i~--e~Ja_J?ase par~.. Ji yidi_r _el lra~aj
sobre un problen~a complejo en asignaciones de trabajo especficas, p~qp~blemente a diferentes personas:
con{Jstnt"s--habilidds ... Por ejemplo: separando -los aspec~os tcni~os de lo~ d-~- ~-~dccio....
iaco'Operacinde dos ,tipos de individuos diferentes en el prC:Ces'Ciel software. o'tro ejelplo es que al
separar el anlisis de requerimientos especificaciones de las otras actividades en el ciclo
vida del_
software, podemos contratar analistas especializados en el rea que nos interesa en lugar de depender de
Jos recursos internos. El analta, por su- parte, podr concentrarse separadamente en los requerimientos
ftm~ionales y no-funcionales del sistema.
)J' :;
i,;
}L:
f :{;,:
periittnos
de
Ejercicio
3.1 Escriba un programa simple en el que pueda demostrr que trata separadamente la correccin y_l,a '
eficiencia.
\
...
5.
./
_,;,
'
..
: J
-"
,...
.
,~,,
"' '-"''
'
- -
....,_~.
,.,,.. , . , ~"f
'~..-:ro;.
'':::- ''
o,
~~J::'.:;.>:~I~dularid:~:d
..
< .
,:
,.. . .
. ,.,,,_.
~n~;~.J~:~ compl~j~puede diVidirse en pietas n'.as p~q~<fi;,. denominadas mdulos. Se dice ~ue un
..
:sistema compuesto por mdulos e.s modular: La ventaj~_psjp.c~.P..-L2:~J~__mqcJ~(a~:!ad __es __que... pennite .' / ;'
aplicar el principio 9e sp~raci<)n de objetivos en dos fas~~ : cuando se tratan los detalles de cada mdulo
~for1aaiSThaa"{e' ignotando:)os detalles de 'iosotros rndulos) y cuando se tratan las caractersti<(aS
generales de todos los mdulo y sus rel~ciones para integrarlos en un sistema coherente. Si estas dos
fases se ejecutan ter11poralmente en ei orden mencionado, decimos que el sistema est diseiado boa~_;,ir . ,,
up (de ~bajo hada ;'..rtiba); la inversa e~ el diseo tup-duwn (de arriba hacia abajo).
..?
de
:,
. 1
~jercicio
---~----~-~-------~---~---------------------------------------------------~---------------------------------------------------------3.2 Describa los paquetes de trabajo involucrados en la construccin de una casa, y dern uestr~ como se
La '
1
'Enfatizaremos la modularidad en el contexto del diseo del software en el prximo capitulo.
..
modularidad no slo es un principio deseabk para eLdiseii.o sin tambin para la produccin completa :
del software. En particular, hay :netas qLJ.~ la modularidad trata de alcanzar en la prctica; 'la capacidad .!
de deseo m pon~r U1 sistema conJ g~o, ~-omp.on~L~P _a-:~~!".~.~r_ g~_.n~_9.9\dlQ.~--~sJ:,;nJf-_s_,~_y la comprelisTci :;
-~el sst~~-~Q.OJ...Ra!Jes.
_La de5J?J.!ll.f22!.!ib iJ!~.~(~~~.~.~. ur~ ..?..\~_teina es}~. -~~.s~da en)0_ d.iyj~9n d~ __llD,_pr.o.Q~~.tn.,a origi'n~_.~c.?.I?-d~wn
(de arriba hacia abajo) en subj?.it!_j.)le~sy en, la aplicacin de la descomposicin a caJa subproblema-en
forma....recursi.va. Este .P'rocd1miento reE-Uaeroieti.coocdodtcho-Cki"la-dlvide"efliilj.Jera (divide y
re:inars), ~ describ~_!~L?~~:!}~ practicada p_or los antiguos romanos para ,dominar otras naciones:
diy~~~~"J~?.. Y..~.i~l~!!~~-pnm~:.o, y c:onquisiarl~S.l~~-~C? in?.L'fiduali:J;l~n.~.
.. ;
La componibilidad de u.r~-~!2-~m'!-_2.e__ p_~~~---~P.3.2!!.1.~.n:?ar desde ab<ljo ha.~.i.~. a~~~a. (bott_om up).
parti~~)~Io ..ife..los. compone.t}t~.s. e!_~~~-~ntales y prosiguiendo co.n el sistema te~in~do. Como ejemplo, un
sistema para a~romatizacin d':~ oficirias .. poCI.da ..disehai:se "e1sli1blando los componelltes de hardware
existentes tales como estaciones personales, .una red y P.erifricos; sistemas tales como sistemas
operativos y herramientas de productividad tales como procesadores de documentos, bases de datos, y
planillas J.e clculo. Un coch:~ es otro ejemplo obvio J.e un sistema ensamblaJ.o por com.ponentes.
Considere primero los subsistemas en los que se puede descomponer un coche : el cuerpo, el sistema
elctrico, el sistema de encendido, el sistema ele transmisin, etc. Cada uno de ellos, a la vez, est.
fonnad por partes standard: por ejemplo Ja batera, los fusibles, cables, etc., que forman el sistema
elctrico. Cuando algo no func\ona, las p?;rtes. d~fectuosas pueden reemplcu:arse por otras nue!'as.
.
__r&armej}t;'~l~p.C;iu~.ci.ll...uci:..software, ~~~.aramos.poder. ensamblar las nuevas aplicaciones
tmando mdulos de un.a .b!.bJi.ot.e.~a y combinndolos para formar el producto deseado. Tales .m.dtifos->.
deberan hab.er-sict'-di~eados e o~- ~1" ~bjetivo expreso de ser re-utilizados. Utilizando componentes':,:: .
rtisbies,-pod~~-os ag1iiZarla construccin inicial del sistema y su afinacin posterior. Por ejemplo, .sera .
posibi"e" reemplazar un comp:)!le.Hte t)or otro que 'realice la misma fw1cin pero que difiera en la.
utlzacin. de }O-~ recurSOS C(Jrnputaciona[es.
'\
,
,.~
. 1
.) .. ;;
6 .
'. l ......
.,
.' . .. .
... '.t.'
....: ..
.'1
,:
'
... - ~ ...... - ... ,. : -~-" -- ~ . . ~ ......:,.~. :.:. . ":- --,.. - ::::.-~ :.; ..... :-::-. -::" _.................... -~ -~ ...... -.... :: . . ~:-- ,....... :..... -4 ~- . ._...: :: .:~.: :
-~~,.-:;:-!tr:";'"'";--":":""'":''-
,. ..
.'
.
,.,.,.,_._, ..
~
~.
..
..- . .....,,..
... . .. .....
~------------- .
. , ..
~!GURA 3.2
La capacidad de ~omprensin de cada parte del sistema por sparado, facilita su modificacin. La
.
naturaleza evolutiva del s'oftware es tal que a :1enudo se le pide al ingeniero que vuelva atrs y modifique
su trabajo anterior. Si e[ sistc:ma slo , puede .ser comprendido en su totalidad, ser dificil hace{
. modificaciones y el resultado ser poco confiable. Si sw-ge Wla necesidad de reparacin, una modularidad
. apropiad~ nos ayud~i-i a buscar el origen del problerm1 en 'cada componente individual.
.
:., ,
>: ~ ,../P.ara'poder alcarii:ar conipf..ibilidad,'descothpO'nibil~dad y_-:c~ompren?in, los md~l,l.os de~eo ten~r..
'
: :
'
:>
..
i'
. ~".
-: --=----un:-.mdl'o tiene alta. c.ll.esin si todos sus compo11entes estn relacionados fuerterriente. Los ;.. , .. ,:
el~me~tos. de mdulo (por-ej."1ii:rtrucCi"oies, procedimientos y. declara~nes), 'se agrupan jun~q_s en un...~ . :.: ;_wf.?ffi_Q~ID..dulo_p_qr ~na raz!l- Jg~ca, nq al azar~ ap~~tan ~ un objetivo comn qu~ es ei fu~i~~ami~~- . . :. ~
del mdulo.
, :
--c;~~s~~-~.P'J.ndo que la cohesin es tma pro:iied0d interna de un mdul9, el acoplamiento caracteriza
,!
~J.;ldel mdulo con otros nHSdufos. ~l~?~l~r-~i~r:to mi~~ la interdepende.n~Ia ent,r_~ __uo.~. m~-~!C?..f ... ,
(por ej. el mdulo A llama a una n:.tina provista por el mdulo B o accede a una variable declarada por el . ; ::.:: !
mdio-B)~'"'"fO's'r:ncJ.ulq~ dependen pesadamente lUlO del otro, tienen un alto acopla):i~nto. ldeaJn'ente-... ; ::> ,,:
deseara~os que los mdulqs .d~~u sistema.'ti.ivieran un bajo' acopla.miento, porque si Jos 'ni.llulos estn. i
.
altam~t~~co.piad(;;;::s~ -~o~plicar el anlisis,. la :compr~risin; la modificacin, prueba o reutiliiaci.n de .
~::::!
cad~ Wl?d:e elra-sp~f'.separado .. Lafigtlia 3.2 nos pa u,na vis~n grfica'dela cohesin Y; el acoplamiento. .. .-; ~_.,:!' f:\!;
. ::::.un:buen ejemplo de un sistema con alta co)Je~ir1 y)ajo acoplamiento, es el ~ubsistema elctrico-
' .. )Y
de Wla casa .. El sist~_na tiene bajo acoplamier~to :porq~~ ~st compuesto por un conjunto de artefactos con
' t ,1
funciot~es clarame~te definibles e intercone~tado~. pr' si~ples cables.: Tiene alta cohesin porque los
1 :
componentes inte1:nos de cada' a~rarato son e.x.acia1ente los necesarios para que ese aparato ctJmpla la , '
funcin para la cual fue creado:.'
;
':i.
~~s estru~t~~ili, m~dulares con alta cohesin y bajo acoplamiento nos penniten ver los nidulos
como caj~s negras cua~uo uescfi~iiii.os_la..estr~ctur~_~ge.eral-Jet-s1s.tei:1ui~-Y. tratar co cada JA9..!J~i.9-J?oC
cuando se .ds.cribe-:o .. analiza .. la funcionalidad
-iisrno. Est~ es justamente otro ~jemplo del-;.
! ';
pr{cip-io-C1sepiti-'a.i'6~?=~e-:b.j'CTi~::-s.
..
..
-- ..
l . :"..
del:
s'ep.arado
.-
---~
-- .
Ejercicios
.J
de
3.5
Explique las: causas y soluciones para un alto acoplamiento' entre dos mdulos de software.
..:
',1
'
::,
------------------------------------~:-----------~------------------------------------------------------------------------------------
~
.\
.J
)
)'
..1
_)
-1
)
..
''
,'
t;.
'
:
.... ..
_
-.'
;
<.' .
_,. __
'
...
'"
'
1
'
.. 1
i1
'
- -
. lli:
1
1
.i
Ejercicio
1
3.6
Diferentes personas intenictuando con ui1a misma apliccin pueden requerir diferentes
abstracciones. Comente brevemente qu tipo de abstracciones son tiles para el us~tario . .
final, el ~iseauor y la persona qt}.e hace d mantermento.
La abstraccin es una tcnica poderosa practicada por los ingenieros de todos los campos para
ppder manejar la complejidad. Por ejemplo, !a represe~tacin de un circuito elctrico en tm1inos de i ..'
resistencias, capacitares, etc,, cada w1o, cnract~rzado por un modelo en trminos de ecuaciones, es. una i
abstraccin idealizada de un di~;positivo. Por un lado, las ecuaciones son w1 model simplificado que . ~
aproxima el comportamiento al de los componentes reales; por el otro, el modelo que construimos, a '
menudo ignora detalles taJes .CytllO el hecho de,que !10 hay conectores "puros" entre componentes y que
''ij~9Jelauos en lrn-linos de resist.encias, capacito res, etc. Ambos
esos conectores tambin deber~n
factores pueden ser ignorados por el 'diseador porque los efectos que describea son despreciables en
trminos de los resultados que deseamos observar.
: Este ejemplo ilustra una irnport;:mte idea general : los modelos de fenmenos que construimos,
- tales como ecuaciones para de~;cribir dispositivos..: son una abstraccin de la realidad, ignorando ciertos :
hechos y ~oncentrndose en otros que se consideran relevantes. Lo mismo se puede aplicar a los modelos ..
construidos y a11alizados por los ingenieros dd software. Por ejemplo, cuando anali.zan y especifican los .
requerimientos para una nu~va aplicacin, los ingcnier?s del software construyen un modelo para dicha !..
aplicacin. Como veremos. en el captulo 5, este modelo puede expresarse de varias maneras,
dependiendo dd grado ue rigor y fonnalidad requeridos. No in1porta qu lenguaje usemos para expresar :
los requerimientos- sea ellen(,'1.laje natural, o bien el lenguaje formal de las frmulas matemticas- lo ;
que producimos es Wl modelo que se abstrae de corllemplar" una cantidad de detalles que hemos decidido
ignorar sin correr riesgos.
La abstraccin afecta :t la totalidad
de la programacin.
Los lenguajes de programacin que
. -'
usamos son abstracciones CO!:lSlnlidas en la parte ms alta del hard\vare (top) : ellos nos proveen
. construcciones tiks y poderosas de manera tal que po~nmos escribir la mayoria de los programas
ignorando detalles tales como \a cantidad de bits usados pa,ra representn.r Jos nmeros o el mecansrno de
direccionan~iento.' Esto nos ayuda a concentrarnos en el problema a resolver ms que en la fonna de
decirle a la mquina cmo regolverlo. Los programas que escribimos son, en s mismos abstraccior1es. Por
1
ser
r>_
'l. ~:.-.
.1
...
:) .
o "' o" ~
;,
, : . ' , , , , , _ ,
::-.o , :: '.' : ; '' :: .'"' -~-:,_J:' :;":":-'".', .-o::.,,,.,,, __ -: -;--;,.. -: rr-. -;: :'- :, ~- ,.
00
o
0
..
;o
--~r.~-:-r',O
rr:- r
0
:
'
''
~=
.....--~----,;-oH'-:':''
'':
~::
.. O0
:1
0 o
0
O:- 1' O
-. ..
). ' .
. .
>: ,~;.~pl;,
1
' .
. ~j. <L.:., :: Como ejemplo del uso de la abstraccin en !os procesos del software, consi~leremos el caso ele una
j. ::.:\:stri~cin de costos. para una eva aplicacin. Una posible forma de h:~cer 1?- estiniacin ele co~tos
::O' :consiste en identificar algunos factores clave del nuevo sistema y extrapo~arlos 'de las estimaciones de
:.:~; , -<c.osto de sistemas similares anteriores. Los factores da ve usados para bac~r el anlisis son abstracciones
1
.
.
, . del sistema.
1.: .
''
11
Ejercicios
-------------------------------------------------~----------------------------------------------------------------------------7-----
. .
/ '. '3.7 . . Las variables que aparecen el los lenguajes de programacin se pueden ver como abstracciones ele
'
las posiciones de memoria. Que d~talles no se consideran pam ia abstraccin de las variables de
los lenguajes de programacirr? Cuales son las ventajas de usar ai)slrat;cin 7 Cunles so11 las
.-...
'
. . desventajas i
~~,
)
1.
."\
..l.-
. 3.8
'.
,Un modelo del ciclo ele vida del software, la! como el modelo en cascada delinc::ldo en el Cllpitulo
.1, es una abstracCin de un proceso del. softvvare. Porqu?
.
.
.
--------------------------------------------------------------------------------------------- ------------- ----------------------
,,;
. ;::\
.J
El. software sufre cambios constantemente. Com<? vimos en el captulo 2. los cambios se deben tanto a la
necesidad de repararlo- eliminando errores que no detectamos antes de liberar la aplicacin- co111o a lrr
..,,... ' necesidad de dar soporte a la ev!citr de la apl{cacin a medida que. ;,p;1reccn nuevos requerimientos y
catnbian los VIeJos. Es por eso que idtltifcamos la manteujbilida.d eomo una de lns prncipnks
---- -:-:-:._..
propiedades del software.
La habilidad del software para evoiucionar no es gratuita - requiere \Ul esfuezo especial pcira
anticipar t./::'io y cundo ocurrirn Jos posibles cambios. Una vez idenlifdulos estos cambios, se debe
tener especial. cuidado en proceder de manera tal que en ei futuro scc:.n fciles de aplicar. Verer~os este
. importante puntoen accin
el captulo 4, en el caso de diseo. Den",ostraremos cmo se puede disdiar
. el software de muner tal que esos posibles cambios q\,le anticipamos en los requerimientos. o';
modi.Qcaciones que se planean como parte de la estrategia de discfi.o, pedan ser incorporad.os a la
aplicacin de manera suave y segura. Bsicnmente 1 deberamos aislar los posibles cambios en porciones
' especficas, de tai manera que las modificaciones se restr~an slo a pequeas porciou'es.
en
\ --
.' <_;_
.:()
----- '
-- . ' o'
~
:::a ( ~"'- ~ :-~-:.-.-_:~ ,----.- "'-~.-.,. ~-:,; :: . -----.--. .-::-- - ......... :.~ ~........ --;-.-..----.: .._......... .-. . . . . .- . ... -.-.-f ...-- .. .
- -. ..... - ....
--~--:
. . .
...------
..
/
..
--m,,.""'f~lifiili!'c'!"?iji~i;i~JW~@illiQSi'J.;~~~:~!i~~~~~~~(~, ,.;; r
~;.
O, de una mane;:a
.. .. . . .
mas realista, podra sufrir :~m b ios le ves an t:" de s~;reu:a~~:.c ~~!''"-:'.,/'~>~~c. i.~,.:l
0
tal, la reusabilidad puede vers_~ __C:_~~.~~ tu~-~~-~~l_~I_9a_9_~.~.P~CJ.::l~na ~,S,~]g, .R9.I..f!.:...~::._qlgtiv.Jgad ~!.!~~~ !-~~- _ ~ .~
c~~es. Si pbde~no~-atiCip .. los-cai1i.b.ias det contexto
e_l cual se encuentra_ 1:1n componente del -: ..'.
sOTtware, podriamos d1senarlo de manera tal que se ac.o!1loda.ra facdmente a Jos cambtos.
La anticipacin i:le cambo exige disponer de las herramientas apropiadas para manejar las
i
diversas' versiones y revisiones del software de \.lila manera controlada. Debe ser posible al1acena( y
reGuperar UOCUIUentacin, mJu!OS fuente, mdulos Objeto, etC. JesJe una base de datOS que acte COnlO
depsito de componentes reusables. Debe controlarse el acceso a la base de datos. Un sistema de
software debe mantenerse consistente an cuando se. efectuen cambios en algunos de sus componentes...
... :
Tal como dijimos en la secciu L:.l.2 -y ccrn;J ':-~remo5 nuevalm:ntt- en b:: .:;;:..~ituios 7 y 8- la di<>ciplina
1
que est~dia . esta clase de problen1as se llama administracin de la configuracin (conftguration
------------------ ---~-----management).
,.
EJul.ues.tra...J~cusiil sob:e la anticipacin de cambio, concentramos nuestra atencin ms en 'los
}Jrductos, que en los pi:;C-;~os-ci..~f_s?.ft~.~-~~-e_.--Sii~l-~mb;rgo, ]a intJc:}.'lc]Oi}aeca-ibto.tambJ'--afecfaah
adi1~rilistracn
~oftwan;_ Por ejemp!o, los r:::sponsables deberian anticipar los efectos de
la rotacin del personal. As mismo, cuando se Jiseiia el cicLo de vida tle una aplicacin, es importante
tener en cuenta el rnantenimie:1to. Dependiendo ele los cambios anticipados, los responsables deben
estimar los costos y diseii.ar la estructura ~rganiz.acional que soportar la evolucin del software. Tambin
deberan investigar si vale la pe;1a in.vertir tiempo y esfuerzo en ia produccin de component~s reusables,
. ya sea como parte del producto o como Llll esfuerzo de desarrollo paralelo.
er:
delp:oceso--dei
~
j.''
Ejucicio
'\
3.9 Tome un programa de ord!:namiento (sort) de cualquier libro de texto. Disciaio desde el punto de
de vista de la reusabilid.1d. Podra reusarlo si el tipo de componentes cambia? Que pasa si la
'
. :J
secuencia Je valores a ou.Jenar es tan larga que hay que usar un alm<H.:ena111ento secundario para :.:. .
almacenarla? Co111o moJi 1\c;:~ra el programa para mejorar su reu:;abilidad bajo esr~s circunstancias?
)
.,
Basado en esta experiencia escriba w1a lista de sugestiones generales que favoreceri,~n la anticipacin
de cambio en un programa. .......
.,
)
..
--------------------------~---------------------------------------------------------------------------------------------------------',.-'
.':"\
,,
~
e:
e:
("\
'-"'
c.~
~
e:J
o
(':~.
(J
C
..1
3.6
Gcn~ralidad
.:)
r,
--'
,,_j
Por otra parte, una solucin generalizada puede ser ms costosa, en tnninos de velocidad de jec_ucin, o:
tiempo de desarrollo, que la :;olucin especializada que se ajusta exactamente al problema original. A.s,:
1
j~
( __ .
l1'\~...
, , , , . , . o-:"r
oO
'
ooOPo
-:"''''''0'"
ooo
'O"'''''
-:~o.oo~:oOo.oo.o .. ooOR~:
:..\
... ...
":-" ..-. ::
....
_,,
.- .
.. ~,-.: -:.<
.,::...
bastante :
area especrfica de apl1cacwn, ex1sten cada vezmas-paquetes-:
.g~~les _qtie. p~ov_e_e.l-so~~~~ii~c~~- ~ii~.;~~i?T9. ~- iJ_roblei:~s<~-~~~~n~. ~ -~-1 _.e~_l?.l~-~~~- p_ued~_ r~_cjefi!D.~?.~~~n~o- ;
una instancia de un problema q:.1c es posible-re-sol\ici'- mediante un paquete general, podra ser rn$1
C.Oil VellJentc.adoi).taLdicho. i)ac(u"etfe- lugat de. i1hple)etar-na SOCJO~e-s.i).e.Cl~izada:.
..
.. ...
:
Esta tendencia general se observa tambin en otras ramas de la industri~~--- Por ejemplo, en Jos! i
inicios de la tecnologa del autcmvil, era posible construir coches de acuerdo a los requerimientos
especficos del diente. A medida que este campo se industrial iz, los clientes pasaron a degii de un
catlogo de modelos - que corresponden a soluciones pi"e-empaquetadas - provisto por cada fabricante.
En la actual~acL.P no es posi.bk pedir un coche con un disei1o_.P.~I~onal, a mer1o.s que
est dspueso__ a
r~an.sLm;aae-Jmer":- ----------- ------
.. -,
------ :.
.
- __ _:=------:-.. . . .. . ....
generalizada del -software. Para cada
..[::
i
se
r
f
3.7 'Incrcmcntalidad
La incrementalidad caracteriza a los :rocesos que se ef~ctan paso a paso, por incre11"\entos. La meta :
deseada se alcanza por aprximaciones sucesivas. Cada apro:Umacii1 se alcanza a\ 'travs de un !
incremento de la anterior. .
.
La incrementalidad se emplea en muchas aclivida<;les de la ingenic1a. Aplicada al software:
significa que la aplicacin desea::ia es producto de un proceso evolutivo.
;
Una manera de usar la iucrememalidad consiste en ident~.:t;~ar Sltbconjunros iniciales que pueden
desarrollarse) entregaise--lclierile,"
coil el ..objt:to de obte.ner w1a re!inH!ri{;;~;~; !mn;ancl
(early
.... . ..
r
feedbac:k):--Este_~0.!ijte __qu~ __}a_ap!ic_aci:l evolucione ele manera c6'nirolada
los. casos en que los ..
req_~1::-irilientos iniciales no son estabks o no fueren completrullente corilprendiclo~. L.a motivacin para ..
f.
t:
[
t
!i
en ..
11
\ '\
\\1/
"
,,.
'
,.
'
'
1 ' '
'
-'
1.
~-;
':-:- . - T -
," : - - --~
.. . ..
..
..
..
-~~L)_~J!~~r~_!]J~ntalidad.es que en la
.,.
r;o
(__)
Ejercido
l..
( ..:.
e:
3.10
\_ .
le.
e~.
Notas flnaks
.e;
(;
~ l.;
En este captulo hemos tli:;cutido siete importantes princtptos de la ingeniera del software: Estos
pri;Kipios se aplican a lo lar;:;o de todo,et proceso de desarrollo del softvvare y durante su evolucin. Dada
su aplicabilidad general los hcm()s presentado por separado como bs piedras angulares de la ingeniera
del software, ms qu~ en d contexto de WJa fase especfica dd ciclo de vida del software. Otra razn para
presentarlos por separado es que la tenninolog!a usada-no est estanclarzada, y a menudo un mismo
trmino es utilizado por clift:rcnlcs personas con distinto significado. Comprendiendo estos principios del
sollware destle un co;nietW\ podremos usar los tnninos ms importantes sin 1rnbigueuades en el resto
de! libro.
.12
''
- -...-_
~.~
ill!9~.
Estos principios de la ing::niera del soft\yare, como los presentamos aqu, podran parecer
demasiado abstractos. Los iremos haciendo ms concretos con ms detalles en el resto del libro, _dentro
del contexto de diseo; especificacin; verificacin y gestin del software. Esto se har en parte
explicitall~~nte, sealando los prin::ipios importantes (cuando sea apropiado), y en parte implcitamente, .
dejando su reconocimiento al lector.
,
Enfatizamos el papel de los principios generales antes de presentar m~todos especficos, tcnicas
y herramientas. La razn es que b ingeniera dd softwar~.- corno cualquier otra rama Ll.e la ingeniera-, .
debe basarse en un conjunto probado de principios:.._L,os prin~ipios a su vez, son las bases para~!- ~~.l~lJnto'
de m!Q~Q.S .!.\;;ados en la disciplina y" para las tcnica:; especific_a:; YJ1t:~r:.~r~:-~~-~~as.~~~~-~s en)~yida -di_a~ia.
--- A medid~
la tecnologl"a evo lucio na, tambin
.hacen las herramientas de la ingeniera del
softwar'e. Los mtodos y las tcnicas. evolucionarn tan~bin - aunque menos rpid~mente que In,~
herramientas - a medida que aum:::.nta nuestro conocimiento del softvvare. En est~ cuadro, los principis
permanecen 1s estables; ellos cc.r1stiluyen las bases sobre las c.uaks se construir d resto. Tambin son
la clave que deber usar el lector rara interpretar Jos conceptos discutidos en el resto del libro.
-que
lo__
''
l.\'Is cj ercicios
-------------------------~----------------------------------------------------------------------------------------------------------
3.11
Supongamos que est escribiendo un programa que manipula archivos. Entre las rutinas ud. ofrece
un comando para ordenar un archivo ya sea en foana ~scendente o descendente. Entre lbs archivos
que ma1~eja, algunos se mantienen automit(camente ordenados por el sistema. UJ.. podra sa~ar
ventaja de este hecho :si el arch[vo ya est ordenado, no se efecta ninguna accin; si el archivo
est ordenado al revs, aplica una fttncin inversa en d orden opuesto. Discuta lo~ pro y los contra
de usar soluciones espcciak:adas en Jugar de utilizar la rutina st:ndarcl de ordenamiento (sort) cada
. vez que se ej-ecuta ese ccun:wdo.
i
! '
r
'
i~:cre.mentalidad
y oprtunidad (timeliness).
3.15 DiscULa los principios que podran ser tiles para e.! desarollo del software, y deni.uestre cnio se
3.'1
estructura con alta cohesin. 1\grupar instrucciones que cumplen alguna funcin conceptual da una '
cohesin mayor. (Esto corespo1cle a la descomposicjn convencional de progr:nnas en subrutinas). Es!
mejor a11 si podernos agrupar .os dato:~ y las ruti!las que: acceden a esos datos, porque esto aumenta la
facilidad de lectura y modifcac:(m.
3.5
Los mdulos que no r.'.(::actan con otros md1.dos, tienen un acoplamiento mmtmo, pero esto
ta111bin significa que ellos uo "cooperan" en nillg:1 sentido. Si un mdulo tiene acceso a las vcriables
locales de otro - por ej. si puede llll)c\ificar directamente el .::stado del otro mdulo -el acoplamiento es
mayor que si un mdulo llama ;:1 un procedimiento ddlniciJ dentro de otro mdulo.
..,
\ .., J.. ,
\ '
'
..
1/l
..)
------"
:....~ ........- , ; . . . : .
__
~_
... ~--~-
' '.
----~--._,;.'--o-.--:.__"------.::...-__-:-:_,7.;.~---"'-~'~-:~
::-.
j: _.:.;;::
f-.6
p usu::nio final se interesa :;olarncl\le ~n la Jcscripcit; abstrnc 1:; de cmo operar la anlcacin ~ i - . todos los detalles concernientes a la forma en que fue diseiiada e impiementada deben omitirse. -El
disei.ador debera saber cuales ~;on. los requerimi.entos y; al diseunr una pan e, deber::~ tener una visin
absrracta del resto del sistema qu,= le permita imaginarse la manera en que: esa parte interacla con el
.l
resto, pero ignora-ndo los detalles ck ese resto. Cuando se hace e! nw.nteoimic:nto-de! sistema, deberiamos
tener tambin tma visin abstr[)cta de la exposicin dd diseo ( porqu se tci.Iriaron cietias d~cisiones Y,
porqu se descartaron otras). Esto pr::rmitira mouifi.car d sistema Je una maner;1 cori.Gable sin ueterior<:1r .
su estructura._ .. _ .
~:
en ei ~:..:.;::~,:~; 7 q;c: e! P.Jodeio le cicb de -vida .en ;;:.aseada e:::- uti pt.:.I1to de vista
idealizado del desarrollo del software._ Por-ejemplo: el modelo de la figum l. 1 ignora e'l hecho" de que se
deb~rn repetir algunos pasos si ur1a fase revela inco~1sisterr.cias o errores en la fas.e anterior>.'!' .
i'
3.3
Ve~<:~mos
3.10 Esta es la creacin evolutiva de prototipos. Sin .;:-.;nbargo, en otros campos es mejor usar los
prototipos por descarte (thrbwavvay). Estos trminos se disctitirln en el captulo 7.
3.14 Entregando una ap!icarin de manera incremental: jodramos entregar un subconjunto til de la
aplicacin a modo de adelanto. 1::s decir, que podernos entrar antes ~n el mercado con un producto,
aunque est incompleto.
...::,..;.
..
.i--.:.
1!
.
...
. ...
'
.. -
-.~-
-.