Complejidad Un médico, un ingeniero civil y una informatica estaban discutiendo acerca de cual era la profesiOn mis antigua del mundo. E] médico senslé: «Bueno, en le Biblia dice que Dios creé a Eva de una costlla que le quite a Adan. Evidente. mente, esto requiio ciruga, y por eso bien puedo afirmar que la mia es la pro- ‘esidn mds antigua del mundo.» El ingeniero interrumpis y dijo: «Pero incluso antes, en el Genesis, se dice que Dios cre6 el orden de los cielos y la tera s Partr del caos. Est fue la primera y desde luego la mas espectacular aplicacion Ge la ingeniers civil. Por tanto, querido doctor, esté usted equivocade: la mia ¢s la ms antigua profesion del mundo.» La informética se recing en su sill, sont, y dijo ranquilamente: «Pero bueno, zquitn pensdis que cred el caos?» 1.1. La complejidad inherente al software Las propiedades de los sistemas de software simples y complejos Una estrella moribunda al borde del colapso, un nit aprendiendo a leer, glé- bulos blancos que se apresuran a atacar a un virus: no son mas que unos pocos ¢ los abjetos del mundo fsico que conllevan unacomplejidad verdaderamente aterradora, El software puede tambien involucrar elementos de gran comple dad; sin embargo, la complejidad que se encuenira aqui es de un tipo funda. ‘mentalmente diferente. Como apunta Brooks, «Einstein arguyé que debe haber explicaciones simplificadas de ia naturaleza, porque Dios no es caprichoso ni arbitrario. No hay fe semejante que conforte al ingeniero dl software. Mucha e la complejidad que debe dominar es complejidad arbitrarian[ 1}. ‘Ya se sabe que algunos sistemas de software no son complejos. Son las apli- caciones altamente intrascendentes que son especificadas, construidas, mant ‘idas y utilizadas por la misma persona, habitualmente el programador afiio- ‘ado 0 el desarrollador profesional que trabaja en solitario. Esto no signifies que 3ANiUSS Y DISEAIO OAENTADO A OBIETOS CON APUCACIONES todos estos sistemas sean toscos 0 poco clegantes, ni se pretende quitar mérito asus creadores, Tales sistemas tienden a tener un propésito muy limitado y un 3S Ge vida muy cono. Unu puede permite Srarlos a la bacura y reempla- carlos con software completamente nuevo en lugar de intentar reutilizarios, = pararloso extender su funcionalidad. El desarolio de estas aplicaciones es ge- ‘heralmente mas tedioso que difil; por consiguient, el aprender a disetarlas es algo que no nos interes En lugar de eso, interesan mucho més los desflos que plantea el desarrollo de lo que llamaremos sofiware de dimensidn industrial. Aqui se encuentra, “aplicaciones que exhiben un conjuato muy rico de comportamientos, como ‘Geurre, por ejemplo, en sistemas reactivos que drigen o son diriidos por even tos del mundo fsico,y para los cuales el tiempo y el espacio son recursos esca- Sos; aplicaciones que mantienen la integridad de cientos de miles de rezistros de informacion mientras permiten actualizaciones y consultas concurrentes; ysis temas para la gestion y control de entidades del mundo rea, tales como los con oladores de trfio aéreo o ferroviario. Los sistemas de software de esta clase tiendeva tener un ciclo de vida largo, y @ lo largo del tiempo muchos usuarios Tegan a depender de su fancionamiento correcto. En el mundo del software de rension indvsinal se encuentran también marcos estructurales que simplifi- an lacreacién de aplicaciones orientadas a un dominio espectfico, y programas (Que mimetizan algunos aspectos de la inteligencia humana, Aunque tales apli- Aicioves son generalmente productos para investigaciOn y desarrollo, no son. Snenos complejas, porque sirven como medio y artefacto para un desarrollo in- cremental y exploratoro. ‘Ls caracteristica dstintva del software de dimensiGn industrial es que re- sulta sumamente diffi, sino imposible, para el desarrollador individual com- render todas ls suilidades de su diseo. Para hablar claro, la complejidad de {ales sistemas excede [a capacidad intelectual humana. Lamentablemente, 1a compcidad de la que se habla parece ser una propiedad esencial de todos los ‘Sstemas de software de gran tamaflo. Con esencial quiere decrse que puede do ‘minarse esa complejidad, pero nunca eliminaria ‘Gertamente, sempre habré genio, personas de habilidad extraordinaria que pueden hacer el trabajo de varios simples deserrolladores mortales, los equiva enter en ingenieria del software & Frank Lloyd Wright o Leonardo da Vinci Estas som las personas a quienes se desearia como arquitectos de un sistema: as ‘que idean lenguajes, mecanismos y marcos estructurales que otros pueden uti- Tzar como fundamentos arquitectonicos de otras aplicaciones o sistemas. Sin cembergo, como Peters observa, «El mundo esté poblado de genios solamente de forma dspersa, No hay razon para creer que Ia comunidad de Ia ingenierfa del software posee una proporcién extraordinariamente grande de ellos [2], Aun- {que bay un toque de genialidad en todos nosotros, en el dominio del software Ge dimension industrial no se puede confiar siempre en la inspiracién divina. Por tanto, hay que considerar vias de mayor disciplina para dominer la com- plejied, Para une mejor comprension de lo que se pretende contxlat, s© vas COMPLEJOAD —— cexaminar por qué la complejidad es una propiedad esencial de todos los siste- mas de software. Por qué el software es complejo de forma innata ‘Como susiere Brooks, «a complejidad del software es una propiedad esencial, rno accidental» [3]. Se observa que esta complejidad inherente se deriva de cua- {ro elementos: la complejidad del dominio de problema, la dificultad de gestio- rar el proceso de desarrollo, la fexibilidad que se puede alcanzar a través del ‘software y Ios problemas que plantea la caracterizacién del comportamiento de sistemas dsrretos. ‘La complejidad del dominio del problema. Los problemas que se intentan resolver con el software conllevan a menudo elementos de complejidad inelu- bible en los que se encuentra una miriada™ de requisitos que compiten entre st, {que quieés incluso se contradicen. Considé-ense los requisitos para el sistema lectrOnico de un evion multimotor, un sistema de conmutacién para teléfonos Celulares 0 un robot autonomo. La funcioralidad pura de tales sistemas es di fil incluso de com prender, pero anédanse ademas todos los requerimientos no funcionales, tales como facilidad de uso, rendimiento, coste, capacidad de sv- pervivencia y fiabilidad, que a menudo estin implictos. Esta ilimitada comple- Fidad exteraa es lo que causa la complefidad arbitraria ala que Brooks se refiere. Esta complejidad externa surge habitualmente de «desacoplamientos de im- pedancian que existen entre los usuarios de an sistema y sus desarrolladores; 1s {suaris suelen encontrar grandes difcultades al intentar expresar con precision sus necesidades en una forma que los desarolladores puedan comprender. En ‘casos extremos, los usuarios pueden no tener més que ideas vagas de lo que de- fean de un sistema de software. Esto no es on realidad achacable a los usuarios nia los desarrolladores del sistema; mds bien ocurre porque cada uno de los grupos no suele conocer suficientemente el dominio del otro. Los usuarios y los ‘Sesurolladores tienen perspectivas diferentes sobre la naturaleza del problems ¥ realizandistintas suposiciones sobre la naturaleza de la solucion, En la actus fidad, aun evando los usuarios taviesen un conocimiento perfecto de sus nece- sidades, e dispone de pocos instrumentos para plasmar estos requisitos con tcxactitud. La forma habitual de expresar requisites hoy en dia es mediante fgrandes cantidades de texto, ocasionalmente acompaftadas de unos pocos éi- ‘bujos, Estos documentos son dificiles de comprender, estén abiertos a diversas interpretaciones, y demasiado frecuentemente contienen elementos que inva~ den el diseto en lugar de limitarse a ser requisitos esenciles. ‘Una complicacion adicional es que los tequisitos de un sistema de software cambian fecuentemente durante su desarollo, especialmente porque la mera ‘xistencia de un proyecto de desarrollo de software altera las reglas del pro- tet ye, panda 7)ANALISS YOSENVO ORFENTADO A OBJETOS CON APLICACIONES —La tree delequipo.ce desarzata de sofware 2 ofecr usién de simp, blema, La observacion de productos de las primeras fases, como documentos de diseto y prototipos, y Ia posterior wilizacion de un sistema cuando ya estéins- talado y opeativo, son Factores que llevan a los usuarios a comprender y art- cular mejor sus necesidades reales. Al mismo tiempo, este proceso ayuda a los desarrollacores a comprender el dominio del problema, capacitandoles para responder mejor a preguntas que iluminan los fincones oscuros det comporta- rmiento deseado de un sistema. : "Ya que un sistema grande de sofware es una inversin considerable, no es admisible el desechar un sistema existente cada vez que los requerimientos cambian, Est o no previsto, los sistemas grandes tienden a evolucionar en el tiempo, sitaacidn que con frecuencia se etiqueta de forma incorrect com el tér- ‘ino mantenimiento del software, Siendo precisos, es mantenimiento cuando se comigen erores, es evaluctdn cuando se responde a requerimientos que cam- bian; es couervacién cuando se siguen empleando medios extraordinarios para ‘mantener en operacion un elemento de software anticuado y decadente. Desa- fortunadamente, le realidad sugiere que un porcentajeexagerado de los recursos de desarrollo del software se emplean en conservacion del mismo. La difglted de gestlonar el proceso de desarrollo. La tarea fundamental del equipo de desarrollo de software es dar vida a una ilusion de simplicidad ‘para defender a Tos usuarios de esta vasta y a menudo arbitraria compleiidad COMPLEIOAD SS ee externa, Ciertamente, el tamabo no es una gran virtud para un sistema de soft- ware. Se hace lo posible por escribir menos e6digo mediante la invencion de ‘mecanismos ingeniosos y potentes que dan esta isin de simplicidad, si como mediante la reuilizacién de marcos estructurales de disetos y cédigo ya exis tentes. Sin embargo, a veces es imposible eludir el mero volunten de los reque- Fimientos de un sistema y se plantea la obligacion deo bien escribir una enorme cantidad de nuevo software o bien reusar software existente de nuevas formas. [No hace mas de dos décadas que los programas en lenguaje ensamblador de tan sélo unos pocos miles de Iinas de c6digo pontan a prueba los limites de la ca- Decidad de la ingenieria del software. Hoy en dia no es extra encontrar sste- ‘mas ya terminados cuyo tarmaio se mide en cientos de miles, oineluso millones de lineas de cédigo (y todo esto en un lenguaje de programacién de alto nivel, ademas). Nadie puede comprender completamente tal sistema a titulo indivi ‘dual Incluso si se descompone la implantacion de formas significativas, ain hay ue enfrentarse a cientos y a veces miles de médulos separados. Esta cantided de trabajo exige ls uilizacion de un equipo de destrrolladores, y deform ideal se utiliza un equipo tan pequetio como sea posible. Sin embargo, da igual el ta- maf, siempre hay retos considerables asociados con el desarrollo en equipo, [Un mayor nimer> de miembros implica una comtnicacién més compleja y por tanto una coordinacién més diftcil, particularmente si el equipo esta disperso geogréficamente, y esta situacion no es nada excepcional en proyectos muy srandes. Con un equipo de desarrolladores, el reto clave dela diveceiGn es iem- ‘bre mnantener una unidad e integridad en el dseac. La flexibilidad que se puede alcancar através dl software. Una compaiiia de construccién de edificios normalmente no gestona su propia explotacion fo- restal para cosechar arboles de los que obtener macera; es extremadamente int sual construir una aceria en la obra con el fin de hacer vigas a medida paca cl nuevo edificio, Sin embargo, en la industria del seftware este comportamiento 5 frecuente, El software ofrece la fexibilidad maxima por lo que un desatrolia- ddor puede expresar casi cualquier clase de abstracion. Esta flenibiidad resulta Ser una propiedad que seduce increiblemente, sis embargo, porque también empuja al desarrollador a construir por si mismo >racicamente todos os blo- ‘ques fundamentaes sobre los que se apoyan estas abstracciones de mas alto ni- vel. Mientras la industria de la construccién tiene nocmativas wniformes de construccién y estindares para la calidad de los materiales, existen muy pocos cstindares similares en la industria del software. Como consecuencia, ef desa- rollo del software sigue siendo un negocio enormementelaborioso, Los problemas de caracterizar el comportamien'o de sistemas dscretos. Si se lanza una pelota al aie, se puede predecic de manera fiable su trayectoria porque se sabe que, en condiciones normales, ay certas leyes fsicas apicables, Serfa muy sorprendente si, simplemente por haber arrojado la pelota un poco mds fuerte, se detuviera de repente a mitnd del vielay saliese disparada hacia