Ingeniería de Software Orientado a Objetos

INGENIERIA DE SOFTWARE ORIENTADA A OBJETOSTeora y Prctica con UML y Java

Dr. Alfredo Weitzenfeld

Departamento Acadmico de Computacin Divisin Acadmica de Ingeniera

Mxico, Octubre 2002

Weitzenfeld: Captulo 1

1

Parte I Introduccin En esta era tecnolgica en la cual vivimos, nuestras vidas estn regidas de gran manera por las computadoras y por el software que las controlan. Las consecuencias del uso del software son muy importantes, a favor y en contra. Cuando todo funciona bien las computadoras son de gran ayuda pero cuando no, el resultado puede ser nefasto, algo que se ha visto a lo largo de los aos en mltiples ocasiones. En esta primera parte del libro se da la motivacin al rea de ingeniera de software orientada a objetos donde se discuten los siguientes temas: (1) el costo del software para la sociedad, (2) la razn para utilizar tecnologa orientada a objetos y (3) el proceso de software necesario para desarrollar y mantener tales desarrollos. 1 El Costo del Software para la Sociedad Se comienza haciendo una pregunta muy sencilla: Cunto le cuesta a la sociedad utilizar sistemas de software? De manera bsica el costo del software puede calcularse en base al gasto mundial en comprar productos y servicios relacionado al software. Por ejemplo, en 1995 se calcul que el mercado mundial de software fue de alrededor de $400 billones de dlares y para el 2000 se estim que sera mayor a $1 trilln de dlares. Segn estadsticas del departamento de comercio americano, el mercado mundial de software empacado en 1994 fue de $77 billones de dlares (se calcula que en 1993 se perdieron $13 billones por piratera). Se calcula que para el ao 2000 sera de $153 billones de dlares. Este software empacado incluye herramientas de aplicacin, soluciones de aplicacin, software de sistemas, y utileras. El mercado de servicios de informacin mundial en 1995 en $324.7 billones de dlares con un incremento de 13% anualmente, lo que significara un mercado de $600 billones de dlares para el ao 2000. Sin embargo, estos costos no representan la realidad completa dada la dependencia que tenemos en el software. En este captulo profundizar un poco ms en este tema para entender cuales son los gastos "ocultos" del software y que consecuencias pueden tener para la sociedad, desde costos econmicos adicionales hasta, incluso, vidas humanas. 1.1 Costos Ocultos y Consecuencias del Software Quizs el costo oculto (externalidades) ms importante del software (el costo no oculto es el que se paga para adquirir o desarrollar ms servicios adicionales) tiene que ver con su funcionamiento incorrecto. La pregunta que nos hacemos es, dada la dependencia sobre el software en el mundo, cules son las consecuencias de su funcionamiento incorrecto? Estas consecuencias se pueden agrupar de la siguiente forma: ? ? Consecuencias inmediatas y efectos directos. Pueden significar horas de cada de los sistemas involucrados y horas de transacciones perdidas. A su vez, esto puede significar que la organizacin tenga que arreglrselas mientras tanto sin sus sistemas; y si los sistemas son centrales a los propsitos de la organizacin, una falla puede representar un costo inmenso. Estos costos corresponden a aplicaciones "criticas de negocios" o "crticas a la misin". Sin embargo, el costo total de una falla de computadora es ms que las consecuencias inmediatas y/o efectos directos. ? ? Consecuencias a mediano y largo plazo y efectos indirectos. Pueden significar productividad perdida, ventas perdidas, costos de servicios de emergencia, costos de restaurar datos, costos por propaganda negativa, costos por accidentes causados, incluyendo posibles juicios en su contra. Estos costos adicionales pueden volver insignificantes el costo bsico del software inicial. Estos puntos anteriores son indicativos de que es difcil predecir el costo real del software para la sociedad a mediano y largo plazo si consideramos los problemas que pudieran ocasionar por su utilizacin. Por otro lado el no utilizar software no sera una alternativa aceptable hoy en da ya que los efectos seran mucho mayores. A lo largo de estos ltimos aos se han podido presenciar casos de fallas de software con consecuencias nefastas. Existen muchos casos donde errores en el software o su mala utilizacin han costado vidas humanas o perdidas econmicas multimillonarias. Peter G. Neumann, moderador del foro de la ACM sobre riesgos al pblico en el uso de computadoras y sistemas relacionados, ha mantenido una lista comprensiva de desastres ocasionados por fallas del software o su mala utilizacin. Otros grupos, como los Profesionales de la Computacin para la Responsabilidad Social (CPSR por sus siglas en ingles) reportan sobre las implicaciones sociales de todo tipo de fallas en las computadoras. Lamentablemente se aprende ms de los errores que de la correcta ejecucin de los sistemas. Las siguientes secciones ilustran algunos de estos casos que sirven para motivar y concientizar al lector en que el software no es algo que pueda o deba tomarse a la ligera en especial si se conoce poco del tema. Ms adelante analizaremos qu se puede hacer para manejar su complejidad y evitar desastres.


2

1.1.1 Fallas en Sistemas de Software El orden en la presentacin de los siguientes ejemplos de desastres ocasionados directa o indirectamente por software y por las computadoras que lo operan, es exclusivamente cronolgico sin relacin al rea de aplicacin o las consecuencias que ocasionaron. Por supuesto que slo algunos ejemplos son mencionados, de lo contrario todo el libro pudiera haber sido dedicado al tema! ? ? Fracaso del Mariner 1 (1962). Podemos remontarnos bastante tiempo atrs para descubrir errores ya causados por computadoras. La primera misin del programa Mariner (con costo total de la misin Mariner 1 hasta Mariner 10 de 554 millones de dlares) fracas por culpa de un caracter incorrecto ('? ') en la especificacin del programa de control para el cohete de propulsin Atlas lo cual caus finalmente que el vehculo se saliera de curso. Ambos, el cohete y el vehculo espacial tuvieron que ser destruidos poco despus del lanzamiento. Adicionalmente, se cree que un error de computadora tambin fue la causa del fracaso del Mariner 8 en 1971. ? ? Sobregiro del Banco de New York (1985). En Noviembre de 1985, el Banco de New York (BoNY) tuvo accidentalmente un sobregiro de $32 billones de dlares (una buena suma si consideramos que esto fue hace 15 aos!) por culpa de un contador de 16 bits (la mayora de los dems contadores eran de 32 bits) que se activ ocasionando un "overflow" del contador que nunca fue verificado. BoNY no pudo procesar nuevos crditos de transferencias de "securities", mientras que la Reserva Federal de New York automticamente hizo un traspaso de $24 billones de dlares al BoNY para cubrir sus gastos por un da, por lo cual el banco tuvo que pagar $5 millones de dlares por los intereses diarios, hasta que el software fue arreglado. ? ? Accidente de un F-18 (1986). En Abril 1986 un avin de combate F-18 se estrell por culpa de un giro descontrolado ("unrecoverable spin") atribuido a una expresin "IF-THEN" para la cual no haba una instruccin "ELSE" porque se pens que era innecesaria, resultando en una transferencia fuera de control del programa. ? ? Muertes por el Therac-25 (1985-1987). El acelerador lineal mdico, Therac-25, producido por AECL (Atomic Energy of Canada Limited), fue diseado para tratamiento a pacientes por medio de radiacin de Rayos X de dos tipos: (i) tratamiento de rayo directo de bajo poder, y (ii) tratamiento de rayo indirecto reflejado de alto poder. Entre 1985 y 1987 este sistema ocasion la muerte de varios pacientes en diferentes hospitales de USA y Canad por culpa de radiaciones de alto poder aplicadas de manera incontrolada. La probable causa de los accidentes consista en que para ciertas secuencias de comandos del operador de la mquina, los controles de la computadora llevaban la mquina a un estado interno errneo y muy peligroso, generando una sobredosis masiva de radiacin al paciente. Despus de amplia publicidad de estos accidentes se descubri que la FDA (Federal Drug Agency) no especificaba requisitos, y no haca revisiones sobre prcticas de desarrollo de software o control de calidad de software en dispositivos mdicos. El FDA inform en Septiembre de 1987 que comenzara a requerir controles de software integrados a ciertas clases de dispositivos mdicos. ? ? Avin derribado por el USS Vincennes (1988). En julio de 1988 la fragata USS Vincennes estaba asignada al golfo prsico. Despus de repetidos intentos de comunicacin por radio, el USS Vincennes dispar un misil (por error) derribando un avin Airbus comercial Iran matando a todos los 290 pasajeros y tripulantes. Esto ocurri mientras el Airbus ganaba altura, bajo la suposicin incorrecta de que era un avin de combate F-14 que descendera sobre el barco de manera hostil. Aunque la orden de disparo fue dada por el comandante del navo, se culpa como causa contribuyente del incidente al sistema de radar AEGIS, el cual con su sistema de interface de usuario mostraba nicamente un punto junto a un dato textual representando al avin, en lugar del eco real del radar sobre el avin. Posteriormente se supuso que en algn momento la aerolnea Iran estuvo en la proximidad de un F-14, probablemente durante el despegue del aeropuerto, confundiendo al sistema AEGIS y asociando de manera incorrecta la informacin transmitida por los "transponders" aire-tierra del F-14 a la aerolnea. Cuando el avin despeg, ste qued asociado con los datos del F-14 sobre la pantalla. Un despliegue inconveniente y posiblemente confuso de la informacin de altitud del avin posiblemente confundi an ms a los oficiales del barco, los cuales supusieron que el F-14 estaba descendiendo, aunque en realidad estaba ganando altura. La inclusin de un eco real del radar sobre la pantalla hubiera hecho posible determinar que el eco del radar del avin era del tamao incorrecto para un avin de combate. ? ? Falla del software de AT&T (1990). El 15 de enero de 1990, AT&T (American Telegraph and Telephone) la compaa que controla las redes del mayor sistema de comunicacin en el mundo, experiment una falla masiva que dej fuera de servicio su sistema de comunicaciones de larga distancia. La falla dur alrededor de nueve horas e interrumpi millones de llamadas de larga distancia. Un error en el software de manejo de excepciones de un tipo particular de sistema de switching telefnico result en una falla de switching, que a su vez caus otras fallas de switching en un efecto cascada. Segn Neuman, se report que la ltima causa del problema tuvo


3

??

??

??

??

??

origen en un programa en el lenguaje C que contena una instruccin "BREAK" dentro de una clusula "IF" dentro de una clusula "SWITCH". Aberracin esfrica en el telescopio espacial Hubble (1990). El 25 de Abril de 1990 se puso en rbita el famoso telescopio espacial Hubble desde el vehculo espacial Discovery. Al poco tiempo, NASA descubri que el componente ms crtico del telescopio de $4 billones de dlares, su espejo principal, tena una gran falla, imposibilitando producir imgenes altamente enfocadas. El problema en su lente es tcnicamente conocido como una "aberracin esfrica". Una investigacin de la NASA revel que el espejo se haba construido con la forma incorrecta siendo 2 micrones (1 micrn = 10-6 metros) ms plano a los lados de lo estipulado en el diseo original, un error bastante grande segn los estndares de precisin de la ptica moderna. Este fue el error principal encontrado en el telescopio, considerando que hubo otros problemas adicionales, como en sus paneles solares, sus giroscopios, y contactos elctricos. El problema del lente radic en que nunca fue realmente probado antes de ser enviado al espacio. En su lugar, una simulacin de computadora se us como mtodo de menor costo para validar el rendimiento del espejo. Por desgracia, malos datos de entrada se utilizaron en la simulacin, significando resultados despreciables. Para corregir el error final en el espacio, se agreg al telescopio ptica correctiva a un costo muchas veces mayor que una prueba en tierra del espejo, significando adems que el espejo nunca funcionara tan bien como se plane. Por lo pronto, la NASA no planea otro telescopio de la magnitud del Hubble, por lo cual los astrnomos tendrn que limitarse a las restricciones actuales del Hubble, con el cual slo se pueden ver objetos aproximadamente 20 veces ms grandes de lo original. Duplicacin de solicitudes de transferencias bancarias (1990). En 1990 un error de software ocasion que un banco en el Reino Unido duplicara cada solicitud de transferencia de pago por un periodo de media hora, acumulando 2 billones de libras esterlinas adicionales. Aunque el banco expres haber recuperado todos los fondos, se especul que los posibles intereses perdidos pudieran haber llegado a medio milln de libras por da. Falla del software de los misiles Patriot (1991). En las primeras etapas de la guerra del golfo prsico de 1991, el sistema Patriot fue descrito como altamente exitoso. En anlisis posteriores, los estimados de su efectividad fueron disminuidos seriamente de 95% a 13% o incluso menos. El sistema fue diseado para trabajar en un ambiente mucho ms limitado y menos hostil que el que haba en Arabia Saudita. Segn report posteriormente el New York Times, una falla en la computadora de tierra del misil Patriot fue responsable de evitar la peor baja americana durante la guerra. Esto result en su inoperabilidad, permitiendo que un misil "scud" destruyera unas barracas militares americanas en Dhahran, Arabia Saudita, causando 29 muertos y 97 heridos. Aparentemente el sistema de radar del Patriot nunca vio al misil Scud. Segn oficiales del ejrcito "una combinacin imprevista de docenas de variables - incluyendo la velocidad, altura y trayectoria del Scud - causaron la falla del sistema del radar [este caso fue] una anomala que nunca apareci durante las horas de pruebas." El error se atribuye a una acumulacin de inexactitudes en el manejo interno del tiempo de la computadora del sistema. Aunque el sistema ejecutaba segn las especificaciones, ste deba ser apagado y prendido con la suficiente frecuencia para que el error acumulado nunca fuera peligroso. Como el sistema se us de manera no planeada, una pequea inexactitud signific un serio error. Despus de 8 horas de uso se detect el problema del reloj acumulado. La correccin slo se logr al da siguiente de la catstrofe (Mellor, 1994; Schach 1997). Error en el procesador Pentium de Intel (1994). En 1994 un error de punto flotante en el procesador Pentium le cost US $475 millones a Intel. El error no fue reconocido pblicamente por varios meses por Intel diciendo que el procesador era "suficientemente bueno" adems de que sera muy difcil que el error ocurriera. Actualmente, Intel est sufriendo otros problemas similares con sus procesadores, como la unidad MTH (Memory Translator Hub) usado para transferir seales de la memoria a otra unidad de la computadora (Intel 820) que podra significarle un costo similar. Recientemente ha tenido problemas con la ltima generacin del Pentium III de 1 Ghz, donde se ha visto obligada a retirarlo del mercado. Al menos la compaa ya ha aprendido a reconocer sus errores! Error en sistema de autentificacin de tarjeta de crdito (1995). Segn un artculo del 4 de Noviembre 4 de 1995 del peridico Guardian en UK se relata que los dos sistemas ms grandes en UK para la autorizacin de crdito (Barclay's PDQ y NatWest's Streamline) fallaron el sbado 28 de octubre de 1995 dejando a los negocios sin poder verificar las tarjetas de crdito de sus clientes. En el caso de Barclay, ms del 40% de las transacciones fallaron por un "error en el sistema de software". Para NatWest, el problema fue una gran cola de llamadas, por razones desconocidas, las cuales retrasaron la autentificacin de tarjetas. Aunque ambos tenan sistemas de contingencia permitiendo a los negocios telefonear para autenticar solicitudes, por el volumen de ventas las lneas se saturaron rpidamente.


4

??

??

??

??

??

??

Explosin del cohete Ariane 5 (1996). El 6 de Junio de 1996 una computadora fue culpada por la explosin del primer vuelo, el 501, del cohete Ariane 5 con un costo de US$500 millones de dlares. El cohete, que parece que no estaba asegurado, llevaba cuatro satlites, ocasionando prdidas totales de $1.8 billones de dlares. El Ariane-5 estaba funcionando perfectamente hasta los 40 segundos iniciales cuando de repente empez a salirse de su curso y fue destruido remotamente por una explosin solo fracciones de segundo despus, ocasionadas por una seal enviada por un controlador de tierra del Ariane. Segn ESA (Agencia Espacial Eurpea), la desviacin fuera de curso fue ocasionada por instrucciones de la computadora controlando los escapes de los dos poderosos impulsadores del cohete. Incluso se especul que la instruccin fue generada por la computadora porque crey que el cohete se estaba saliendo de su curso y de esta manera estara corrigiendo el curso de vuelo. Segn el reporte final, la causa de la falla fue una excepcin de software ocurrida durante la conversin de un nmero flotante de 64-bits a un nmero entero de 16 bits. El nmero flotante siendo convertido tena un valor mayor del que poda ser representado por un nmero entero de 16 bits (con signo). Esto result en un "error de operando". Las instrucciones de conversin de datos (cdigo en Ada) no estaban protegidos de causar tal error de operando, aunque otras conversiones de variables similares en el mismo lugar, s estaban protegidas. El origen del problema parece haber sido en que el Ariane 5 poda llevar un mayor nmero de satlites que el Arianne-4, incrementando as su peso. Sin embargo el Ariane-5 utilizaba una gran cantidad de software diseado para el Ariane-4. Las conclusiones finales no oficiales fueron que ningn mtodo formal hubiera detectado el problema, ya que la raz de tal era a nivel de comunicacin entre humanos, en relacin a informacin fsica aparentemente no relacionada y no un problema de programacin. Error del sistema de cobranza lleva a una compaa a la quiebra (1996). Un artculo en la edicin de Abril de 1996 de "TVRO Dealer" (una publicacin del rea de televisin por satlite) describe cmo el intento de un servicio de programacin de una gran compaa de televisin por satlite de cambiar a un nuevo sistema de software de cobranza el 28 de Marzo anterior finalmente caus la quiebra de la compaa. Error del sistema de cobranza en MCI (1996). En la edicin del 29 de marzo de 1996 del Washington Post, MCI report que devolveran aproximadamente 40 millones de dlares a sus clientes por causa de un error de cmputo. El error de cobranza fue descubierto por un reportero investigador de una estacin local de televisin en Richmond, VA. Los reporteros encontraron que fueron facturados por 4 minutos despus de hacer una llamada de tan solo 2.5 minutos, dando lugar a una profunda investigacin. Mayor falla de una computadora en la historia de bancos en USA (1996). El 18 de mayo de 1996 la revista US & World Report, y al siguiente da el diario The Boston Globe, reportaron que aproximadamente 800 clientes del First National Bank of Chicago fueron sorprendidos al ver que sus saldos eran $924 millones de dlares ms de lo que tenan la semana pasada. La causa fue el tradicional "cambio en el programa de la computadora". De acuerdo a la Asociacin de Banqueros Americanos, el total de $763.9 billones fue la cantidad ms grande para tal error en la historia bancaria de los Estados Unidos, ms de seis veces el total de fondos ("assets") del First Chicago NBD Corp. El problema fue atribuido a un "error de la computadora". Falla de la computadora del centro de control de trfico areo de NY (1996). El 20 de Mayo 1996 fall la computadora del Centro de Control Areo de Nueva York (ARTCC - NY Air Route Traffic Control Center) que controla el trfico areo sobre los estados de New York, Connecticut, New Jersey, Pennsylvania y parte del ocano Atlntico. La computadora de 7 aos de vigencia perdi capacidad de servicio efectivo ("fall") dos veces la tarde del lunes 20 de mayo; la primera vez por 23 minutos y la segunda por alrededor de una hora, una hora ms tarde. Parece que 4 das antes se haba instalado un nuevo software en el sistema. Se volvi al sistema anterior, con procedimientos de control de trfico areo ms ineficientes, ocasionando un lmite ms bajo de saturacin de trfico y retrasos en los despegues de alrededor de una hora en los aeropuertos principales en el rea; junto con un incremento en la carga de trabajo de los controladores y menor seguridad, incluyendo la desactivacin de la "alerta automtica de conflictos". Mala planificacin del nuevo sistema de una administradora de servicios de salud (1997). Segn report el Wall Street Journal el 11 de diciembre de 1997, Oxford Health Plans Inc., administradora de servicios de salud en USA, de gran crecimiento en los ltimos tiempos, anunci que registrara una prdida de US$120 millones o ms durante ese trimestre, adems de una prdida adicional de US$78,2 millones, su primera prdida desde que sali a la bolsa en 1991. La razn principal fue la larga lista de problemas ocurridos con un sistema informtico que se puso en lnea en 1996; desde el diseo del sistema y su instalacin hasta cmo fue administrado por los ejecutivos del grupo Oxford. Los problemas ocasionaron que Oxford no pudiera enviar facturas mensuales a miles de cuentas de clientes adems de incapacitarla para rastrear los pagos a cientos de mdicos y hospitales. En menos de un ao, los pagos no cobrados de sus clientes se triplicaron a ms de US$400 millones, mientras que el monto que Oxford deba a los proveedores de servicios mdicos aument en ms del 50%, a una suma


5

??

??

??

superior a los US$650 millones. La administradora de servicios mdicos comenz a planear su nuevo sistema informtico en 1993, cuando slo tena 217,000 miembros. El sistema, desarrollado por Oracle, no comenz a utilizarse hasta Octubre de 1996, cuando el nmero de abonados a su seguro mdico haba llegado a 1,5 millones. En ese momento el sistema ya era obsoleto. En lugar de tomar 6 segundo inscribir a un nuevo miembro, tomaba 15 minutos. A pesar de esto y que la infraestructura administrativa de Oxford no daba abasto, los ejecutivos seguan inscribiendo nuevos clientes, en el ltimo ao se incorpor medio milln adicional. A finales de 1993, Oxford trat de ajustar el sistema, adems de convertir de una sola vez la mayora de su base de datos para facturacin: unas 43,000 cuentas cubriendo a 1,9 millones de miembros. Esto signific la catstrofe final, ya que la transformacin entre base de datos no funcion, y mientras tanto se suspendi por unos meses la facturacin ya que no se contaba con un sistema de seguridad, ni siquiera manual. A pesar de todo esto, Oxford sigui sus prcticas habituales de contabilidad, registrando aquellas facturas que no se haban cobrado como facturacin trimestral. Los problemas finales surgieron cuando Oxford comenz a poner al da las cuentas vencidas contactando a los clientes por primera vez en varios meses. Muchos se negaron a pagar y otros dijeron que haca mucho que haban cancelado su cuenta. Por consiguiente, Oxford tuvo que registrar US$111 millones como deudas incobrables y reconoci que tena 30,000 afiliados menos de lo que haba calculado. El presidente reconoci que deba haber contratado un ejrcito de trabajadores temporales para que escribieran a mquina las facturas. Por otro lado, lo primero que perdieron fueron los clientes pequeos, pero como luego no resolvieron ningn problema comenzaron a perder a los clientes grandes. Error de un controlador de discos de Toshiba (1999). En noviembre de 1999 Toshiba lleg a un arreglo fuera de corte que le costara a la compaa ms de $2 billones de dlares para cubrir errores que pudiesen haber significado la prdida de informacin por culpa de fallas en los controladores de discos "floppy" producidos en sus computadoras porttiles a partir de 1980. Aunque los controladores fueron diseados originalmente por NEC, Toshiba produca sus propios componentes y nunca incluy la modificacin hecha por NEC en 1987 lo cual hubiese evitado el problema. Lo mas interesante del caso es que realmente nunca se report falla alguna. Queda por ver que consecuencias traer este caso al resto de los fabricantes de computadoras para los cuales este precedente los tiene extremadamente preocupados. Actualizacin de software mal planificada paraliza Nasdaq (1999). El 17 de noviembre de 1999 los corredores de la bolsa de valores Nasdaq no pudieron comprar ni vender acciones durante 17 minutos cruciales, despus de que oficiales de Nasdaq intentaran actualizar sobre la marcha un sistema de software durante la ltima media hora de la sesin. Algo funcion mal y los inversionistas tuvieron que pagar el precio. Error del milenio (2000). Concluyo estos ejemplos con un pequeo pero nocivo error que se le conoce como el problema Y2K, error del milenio, o inclusive el problema de software del siglo 20. El problema se remonta a la dcada de los 60, y radica en que hace mucho tiempo los programadores adoptaron la convencin de representar el ao con dos dgitos en lugar de cuatro. Esta convencin ocasionara fallas en los sistemas al llegar al ao 2000, ya que se alambraba el "19" (no se permita utilizar un nmero que no fuera el 19), para generar la fecha lo cual al llegar al ao 2000 fallara por saturar el registro de almacenamiento ("overflow"). Para empeorar las cosas a menudo los dgitos "99" o "00" eran valores reservados (nmeros mgicos) significando "nunca borrar esto" o "esta es una cuenta de demostracin". Adems, esto resultaba en el uso de un algoritmo incorrecto para reconocer aos bisiestos. No est claro si hay una razn nica para haber hecho esto; porque la memoria de las computadoras en esa poca era extremadamente cara, o porque no se esperaba que estos sistemas duraran tanto tiempo, o incluso quizs porque no reconocieron el problema. Aunque el problema se activ en este nuevo milenio, se tiene precedentes. Muy pocos se dieron cuenta que la IBM 360 no poda manejar fechas mayores al 31 de Diciembre de 1969, hasta que estas mquinas empezaron a fallar a la medianoche hora local. IBM recomend a sus clientes en Amrica y Asia mentirles a las computadoras cambiando a una fecha anterior, mientras IBM empez a crear una solucin al problema. El problema es muy extenso, afecta hardware (BIOS, relojes de tiempo real, "embedded firmware", etc.), lenguajes y compiladores, sistemas operativos, generadores de nmeros aleatorios, servicios de seguridad, sistemas de manejo de bases de datos, sistemas de procesamiento de transacciones, sistemas financieros, hojas de clculo, conmutadores telefnicos, sistemas telefnicos y ms. No es solamente un problema de sistemas de informacin, todo aquel sistema que use fechas est expuesto: automviles, elevadores, etc. (Por ejemplo, en cierto momento Visa y MasterCard pidieron a sus bancos asociados que dejen de dar tarjetas que expiren en el 2000 o despus.) No solamente es un problema de aplicaciones antiguas: el ao pasado el paquete Quicken para manejo de finanzas personales fue corregido para ir ms all de 1999. En enero se report que el Instituto Nacional de Salud (NIH) en USA recibi nuevas PCs con tres versiones diferentes de BIOS, dos de las cuales fallaron a la transicin Y2K. Las soluciones fueron muchas, consistiendo de diferentes etapas para analizar el problema particular y decidiendo las medidas a tomar, incluyendo no hacer nada y dejar que el problema ocurriera para luego


6

arreglarlo. Existe an toda una industria alrededor de este problema, con 1,800 compaas asociadas a la organizacin "year200" (year2000.com, year2000.org) y proporcionando certificaciones. Se dice que lleg a ser tanta la demanda por programadores del lenguaje Cobol (donde el problema fue ms significativo) y tan desesperada la situacin, que segn se report, se fue a buscar programadores de Cobol ya retirados en asilos para ancianos Actualmente se desconoce el costo final al problema de Y2K. Es difcil estimar cual fue el costo total del problema Y2K. Segn la compaa TMR (Technology Management Reports) de San Diego, los costos podran haber sido superior a $1 trilln de dlares. Esto incluye reescribir programas existentes, adquisicin e instalacin de sistemas que los reemplacen, y productividad perdida por culpa de la interrupcin de los sistemas para pruebas y las propias fallas por no ser funcionales en el ao 2000. Y esto no incluye demandas por daos ocasionados. Otras compaas predijeron rangos de costos similares, como el grupo Gartner, que predijo un costo de $600 billones de dlares a nivel mundial. Varias compaas asignaron presupuestos para este problema: Chase Manhattan dijo que gastara $250 millones de dlares, American Airlines y Hughes Electronics dijeron que gastaran $100 millones de dlares cada una. La oficina de administracin de presupuesto de la Casa Blanca (OMB - Office of Management and Budget) calcul sus costos de reparacin en 2.8 billones. Esto inclua 4,500 computadoras para defensa nacional, trfico areo, pagos de impuestos y seguridad social. El Grupo Gartner estim que los costos para el Departamento de Defensa de USA podran ser superior a los US$30 billones. 1.1.2 Sobrecostos, Retrasos y Cancelaciones en los Sistemas de Software Lamentablemente los costos de los sistemas de software no se restringen a fallas en el software o los sistemas de computadora. Segn una encuesta hecha por el Standish Consulting Group en 1995 compaas y agencias gubernamentales americanas perdieron $81 billones de dlares por proyectos de software cancelados. Segn Rob Thomsett, las causas de esto pueden ser de dos niveles principales: (i) factores que casi garantizan la cancelacin del proyecto, como la falta de un dueo del proyecto; y (ii) factores que no resultan en una cancelacin inminente del proyecto, pero seguramente ocasionarn reducciones substanciales en su calidad. En esta seccin se muestran algunos ejemplos clsicos en orden cronolgico. ? ? Sobrecosto y retraso en sistema de Allstate Insurance (1982). En 1982, Allstate Insurance comenz a construir un sistema para automatizar su negocio por $8 millones. El supuesto esfuerzo de 5 aos continu hasta al menos 1993 cuando termin costando cerca de $100 millones. ? ? Sobrecosto, retraso y cancelacin en sistema de London Stock Exchange (1983-1988). El proyecto Taurus de la Bolsa de Valores de Londres estaba originalmente cotizado en 6 millones de libras. Varios aos ms tarde y ms de 100 veces (13,200%) sobre presupuesto el proyecto fue cancelado, costando a la ciudad de Londres al momento de ser abandonado, 800 millones de libras. ? ? Sobrecosto y retraso en sistema del bombardero B-1 (1985). El bombardero B-1 en servicio desde 1985 requiri US $1 billn adicional para mejorar su software de defensa area que era inefectivo, aunque problemas de software imposibilitaron alcanzar los objetivos originales. ? ? Sobrecosto, retraso y cancelacin en sistema de Bank of America (1988). En 1988, Bank of America gast US $23 millones en una plan inicial de 5 aos para desarrollar MasterNet, un sistema computarizado para contabilidad y reportes de "trust". Luego de abandonar el sistema viejo, gastaron $60 millones adicionales para lograr que el nuevo sistema funcionara y finalmente terminaron desistiendo. Las cuentas de los clientes perdidos pudieron haber excedido los billones de dlares. ? ? Sobrecosto y retraso en sistema de control de rastreo por satlite (1989). El software para la modernizacin de la Facilidad de Control de Rastreo por Satlite tom 7 aos ms de lo previsto y cost $300 millones adicionales ofreciendo menor capacidad de la requerida. ? ? Sobrecosto y retraso en sistema Airborne Self-Protection Jammer (1989). El sistema ASJP (Airborne SelfProtection Jammer), un sistema electrnico de defensa area instalado en alrededor de 2,000 aviones de combate y ataque de la Marina Americana, cost US $1 billn adicional, tom 4 aos adicionales, y slo fue "efectivo operacionalmente marginalmente y apropiado operacionalmente marginalmente". ? ? Sobrecosto en sistema del avin de carga C-17 (1989). El avin de carga C-17 construido por Douglas Aircraft cost $500 millones adicionales por problemas del software aeronutico. Un reporte de GAO not que existieron 19 computadoras a bordo, 80 microprocesadores, y 6 lenguajes diferentes de programacin. 1.1.3 Razn de los Problemas del Software Cmo podemos justificar tantos problemas en el software y las computadoras? Una pequea ancdota refleja la situacin.


7

Se dice que hace unos aos se juntaron un mdico, un ingeniero civil y un ingeniero en computacin para discutir cual era la profesin ms antigua del universo. El mdico explic: Dios cre a Eva de la costilla de Adn; obviamente se requiri ciruga, por lo cual la medicina tiene que haber sido la profesin ms antigua. A esto dijo el ingeniero civil: antes de Adn y Eva, Dios cre todo el universo, del caos puso orden en el cielo y en la tierra, siendo sta la aplicacin ms espectacular de la ingeniera civil y tambin la ms antigua. Finalmente, exclam el ingeniero en computacin, quin creen que cre el caos en primer lugar. Una frase ms actual dice que para hacer las cosas mal es suficiente una persona, pero para hacerlas verdaderamente desastrosas se requiere una computadora. 1.2 Complejidad del Software El problema principal que hemos visto en la seccin anterior radica en que cuanto ms grandes son los sistemas de software mayor es su complejidad. Uno se pregunta, de dnde proviene toda esta complejidad? Se puede hablar de dos aspectos que causan esta complejidad, uno esttico y otro dinmico. El aspecto esttico del software tiene que ver con la funcionalidad que el software ofrece. Cuanto mayor es su funcionalidad mayor es el nmero de requisitos que debe satisfacer un sistema. Esto significa que los sistemas se vuelven ms grandes y ms difciles de comprender por la cantidad de informacin y funciones que manejan. El nivel de complejidad radica en estos aspectos intrnsicos a la aplicacin. Para reducir tal complejidad habra que simplificar la funcionalidad que el sistema ofrece. Obviamente, la complejidad puede fcilmente aumentar si la aplicacin no est desarrollada de manera adecuada. El aspecto dinmico del software tiene que ver con los cambios que pudieran hacerse en un sistema en el futuro. Segn una ley de desarrollo de software (Lehman, 1985), todo programa que se use se modificar; y cuando un programa se modifica, su complejidad aumenta, siempre y cuando uno no trabaje activamente contra esto. Esto es similar al problema de la entropa, una medida de termodinmica sobre desorden. Segn la segunda ley de termodinmica, la entropa de un sistema cerrado no puede ser reducida, solo puede aumentar o posiblemente mantenerse sin cambios. Una alternativa es aplicar reingeniera para reducir esta entropa, y as poder continuar con el mantenimiento del sistema. Por otro lado, cuando se llega a tal desorden, no es econmicamente justificable continuar con el sistema, ya que es demasiado caro modificarlo. Lamentablemente, como se vi antes, la historia nos muestra que los sistemas raramente se desarrollan a tiempo, dentro del presupuesto y segn las especificaciones originales. Ms an, los sistemas tienden a fallar. Sin embargo, segn veremos en el Captulo 3, no todo es negativo. Un aspecto importante para poder manejar la complejidad de los sistemas, es seguir un buen proceso de software. 1.2.1 Robustez del Software Tomemos el caso de los sistemas de control de trfico areo de Estados Unidos. El gobierno requiere que sus nuevos sistemas no dejen de funcionar por ms de 3 segundos al ao. Adems requiere que en los sistemas de las aerolneas civiles la probabilidad de ciertas fallas catastrficas no sean mayor a 10-9 por hora. La problemtica de esto es cmo comprobar que dichas fallas nunca ocurran dado que de por s ocurren muy raras veces. Por ejemplo, el requisito anterior significa que se tendra que ejecutar un programa varios mltiplos de 109 (100,000 aos) para asegurarse que el sistema funcione bien y que tales fallas no ocurran. Segn Edward Adams de IBM Thomas Watson Research Center, un tercio de todas los errores (bugs) son defectos de "5,000 aos" (MTBF - mean time between failures): cada una de ellas produce un error una vez cada 5,000 aos. Adems de la dificultad para encontrar la falla, remover una de ellas significara una mejora insignificante en la robustez del sistema. Segn Caper Jones (1995), se puede estimar el nmero de defectos "latentes" en un sistema tpico de acuerdo al tamao del sistema, medido en puntos de funciones, subido a la 1.2 potencia. Se calcul que cuando Microsoft Windows 3.1 se envi al mercado en 1992 contaba con 5,000 errores (bugs) conocidos. Considerando que Windows 95 consista aproximadamente de 80,000 puntos de funcin, esto sugiere que Windows 95 tena aproximadamente 765,000 errores latentes (o sea, errores que en el proceso de desarrollo deban componerse durante las etapas de pruebas). Si todas estas pruebas removieran el 99% de los errores, aun quedaran 7,650 para ser encontrados despus de haberse enviado el software al mercado. La primera versin de Word tuvo 27,000 lneas mientras que Word 6.0 tena 2 millones. Word 6.0 tena 10 veces ms funcionalidad que Word 5.1, y 3 veces la cantidad de cdigo, significando obviamente una gran lentitud en el sistema. Los nmeros para Office 2000 y Windows 2000 aterraran a cualquiera! Por supuesto que existen mtodos formales que son pruebas matemticas para garantizar si un programa funciona de acuerdo a sus especificaciones. Sin embargo, esto tampoco ofrece una solucin completa, aunque siempre ayuda. Entonces, que alternativa tenemos para mejorar la robustez del software? Analizaremos esto y otros temas ms adelante.


8

1.2.2 Software Suficientemente Bueno En general no existe una sola medida que nos diga que tan bueno es un sistema de software. Por un lado, un sistema de software se puede considerar exitoso cuando satisface y posiblemente excede las expectativas de los clientes y/o usuarios en el momento de utilizarse. A nivel de negocios, esto tambin implica que se desarrolle a tiempo, de manera econmica, y que se ajuste a modificaciones y extensiones posteriores. De manera general se pueden caracterizar aspectos externos e internos al sistema. Como factores externos, los usuarios esperan resultados rpidos, que el software sea fcil de aprender, sea confiable, etc. Como factores internos los administradores del software esperan que el sistema sea fcil de modificar y extender, al igual que sea fcil de comprender, verificar, migrar (a diferentes ambientes de cmputo), etc. Quizs de todos estos aspectos, lo que ms se puede medir cuantitativamente es la cantidad de errores o defectos que resultan. Aunque en la prctica no se puede garantizar el software perfecto, o sea cero defectos, la pregunta es cundo el software es suficientemente bueno, y cuanto esfuerzo amerita invertir para eliminar defectos adicionales. Segn Yourdon los tres elementos ms importantes del software "suficientemente bueno" son funcionalidad ("feature richness"), calidad y tiempo (schedule) como se muestra en la Figura 1.1. Cualquier cambio en uno de estos aspectos afecta a los otros.Funcionalidad

Calidad

Tiempo

Figura 1.1 Diagrama de calidad versus funcionalidad versus horario del software. Actualmente la situacin es tan extrema que en el apogeo de la guerra de "browsers" entre Netscape y Microsoft se competa por quien liberaba ms rpido su siguiente browser, agregando cada vez mayor funcionalidad, con ciclos de desarrollos de slo unos pocos meses. Esto obviamente afect la calidad del producto significando muchos errores en los nuevos "browsers" que no fueron depurados de manera adecuada, volvindose el usuario el encargado de probar realmente el software y encontrar sus errores. En 1997 errores de seguridad en Netscape y Explorer 4.0 hicieron que las compaas revisaran sus programas y los quitaran temporalmente del mercado. Situaciones similares son comunes en la actualidad. Lo peor del caso es que ante la opcin de escoger entre un software perfecto, con cero defectos o una versin ms nueva con todo lo novedoso, pero que pudiera tener algunos errores, la gente siempre quiere la nueva. En cierta manera nosotros mismos impulsamos el deterioro en la calidad del software comercial. La famosa frase "ms rpido, ms barato, mejor" realmente significa en la actualidad "suficientemente rpido, suficientemente barato, suficientemente bueno". 1.2.3 La Bala de Plata ("Silver Bullet") En 1975 Fred Brooks, "el padre del Sistema 360 de IBM", escribi su famoso libro "The Mythical Man-Month" en el cual resaltaba la complejidad en el desarrollo de sistemas de software; un clsico an hoy en da vuelto a publicar en 1995 para su vigsimo aniversario. El sistema operativo OS/360 de IBM escrito en la dcada de los 60 tuvo en su apogeo 1000 personas trabajando al mismo tiempo en el proyecto, incluyendo programadores, documentadores, operadores, secretarias, administradores y dems. Entre 1963 y 1966 se calcul que se utilizaron para el diseo, construccin y documentacin del sistema 5000 aos-persona. Calculado a 100 lneas/persona/mes esto sera equivalente a 5,000x100x12 = 6 millones de lneas. Este sistema es el precursor de MVS/370 y MVS/390 an utilizado por los mainframes de IBM. Uno de sus ms conocidos legados es la famosa "Ley de Brooks" que resalta que cuanto ms gente se agregue a un proyecto de software ya retrasado ms se retrasa el proyecto, como se muestra en la grfica de la Figura 1.2.


9

Tiempo

Nmero de Programadores

Figura 1.2 Ley de Brooks: cuanto ms se aumente el nmero de trabajadores mayor el tiempo de desarrollo. La razn para esto se basa en que las necesidades de personal se calculan inicialmente segn una simple medida de lneas de cdigo producidas por una persona al mes (el estndar actual es aproximadamente de 100 a 1,000 lneas por personas al mes), lo cual significara que si un proyecto requiere 10 millones de lneas, simplemente se puede dividir por los meses y personas que se requieren para lograr esa cantidad y si llegase a haber un retraso, simplemente se pueden agregar ms personas en base a un clculo similar. Sin embargo, esto no funciona as en la realidad. La razn principal de esto es que a las nuevas personas hay que entrenarlas y explicarles el proyecto. Significa que se quita temporalmente personal ya involucrado en el proyecto para dedicarle a las nuevas contrataciones, causando que el proyecto se retrase an ms. Pero esta ley no es el legado ms importante de Fred Brooks para la computacin. Brooks ha contribuido con muchas ideas, incluso algunas controversiales. En 1987 (IEEE Computer, Abril 1987) public su ya clebre artculo "No Silver Bullet" en el cual menciona: "..segn miramos al horizonte de una dcada, no vemos ninguna bala de plata. No existe un solo desarrollo, en la tecnologa o tcnica de administracin, que por si slo prometa incluso una mejora de un orden de magnitud en productividad, seguridad (reliability), simplicidad, dentro de una dcada". En otras palabras, no hay nada que permita mejorar la calidad del software de manera radical. 1.2.4 Ciclo de Vida del Software Para apreciar esto es necesario comprender un poco ms en qu consiste desarrollar software. Un sistema de software tiene un ciclo de vida que comienza con la formulacin de un problema, seguido por la especificacin de requisitos, anlisis, diseo, implementacin, verificacin, validacin, integracin y pruebas del software, continuado de una fase operacional durante la cual se mantiene y extiende el sistema. Todo desarrollo de software incluye aspectos esenciales, como la creacin de las estructuras que resuelvan el problema, junto con aspectos secundarios ("accidentales"), como la codificacin y las pruebas. Segn Brooks, existe una regla emprica ("thumb rule") que dice que para el desarrollo de un proyecto de software se debe asignar, 1/3 del tiempo a la planeacin, 1/6 a codificacin, 1/4 a pruebas de componentes, y 1/4 a pruebas del sistema, como se muestra en la Figure 1.3. O sea, la mitad del esfuerzo (2/4) son dedicados a pruebas lo cual tambin incluye la depuracin y aspectos secundarios del software.

1/6 Codificacin

1/4 Pruebas Componentes

1/3 Planeacin

1/4 Pruebas Sistema

Figura 1.3 Estimado general del tiempo dedicado al desarrollo de un proyecto de software. La mayora de las mejoras en la productividad del sofware se han dado histricamente simplificando las tareas secundarias como las herramientas, ambientes y lenguajes de programacin. Segn la premisa de Brooks, a menos


10

que lo secundario fuese ms de 9/10 del esfuerzo total, reduciendo estas actividades a cero no resultara en un orden de magnitud de mejora. Ya que ste no es el caso, sera necesario tambin reducir el tiempo dedicado a lo esencial. Entonces, como hacer para mejorar tan radicalmente la productividad del software? El autor muestra cierto pesimismo, y lamentablemente bastante realismo. Todo esto es un reflejo de que los sistemas de software son muy complejos, pudiendo contar con muchos millones de lneas de cdigo. Esta complejidad requiere de un proceso de desarrollo de software eficiente y sistemtico, con base a buenas metodologas y herramientas de apoyo. Como no se puede eliminar la complejidad, por lo menos se podr reducirla a un nivel manejable. Otro famoso autor y tecnlogo, Ed Yourdon discute en su libro "Rise and Resurrection of the American Programmer" en 1996 (una revisin a su libro anterior titulado "Decline and Fall of the American Programmer, 1993), que aunque no hay un slo desarrollo que sea la "bala de plata", s se pueden ver varios aspectos que juntos pueden dar ese incremento en orden de magnitud. En particular, l da nfasis en la cuestin humana ("peopleware"), proceso de software, tecnologa de objetos, reuso y mtricas de software. Estos temas han sido tratados por mltiples autores, algunos ms optimistas que otros. Considerando que es inevitable seguir desarrollando software, veamos qu se puede hacer. Analicemos en el resto de la introduccin de este libro los aspectos ms relevantes en la actualidad, del software orientado a objetos (Captulo 2) y del proceso de software (Captulo 3).


1

2 Tecnologa Orientada a ObjetosDado que un aspecto primordial de este libro es el software orientado a objetos es entonces necesario comprender que significa esta tecnologa. Comenzamos discutiendo brevemente cuales son los mitos y cuales las realidades con esta tecnologa. Continuamos describiendo los aspectos bsicos que distinguen a la programacin orientada a objetos con respecto a la manera tradicional de programacin. El resto del captulo describir la motivacin, y conceptos detrs de esta tecnologa junto con una breve resea de los ms importantes lenguajes orientados a objetos. 2.1 Mitos y Realidades La orientacin a objetos es un buen ejemplo de cmo un pequeo detalle puede significar tan crtico, algo similar a la famosa frase de Neil Armstrong cuando pis la luna: Un pequeo paso para un hombre, un gran paso para la humanidad. Sin exagerar con la similitud analicemos qu significa este pequeo paso tecnolgico que tanto ha significado para el desarrollo de software. 2.1.1 Programacin Tradicional En la programacin tradicional, conocida como estructurada, es separar los datos del programa de las funciones que los manipulan. El programa o aplicacin completa, consiste de mltiples datos y mltiples funciones, como se muestra en la Figura 2.1.

Datos

FuncionesFigura 2.1 Programacin estructural: datos y funciones globales. Esta forma de programar tiene sus orgenes en la arquitectura von Neumann de las primeras computadoras modernas. La arquitectura bsica es la misma utilizada en la actualidad a nivel comercial en las PCs y se basa de manera simplificada en una unidad central de procesamiento (CPU) y una memoria donde se carga el programa o aplicacin que debe ejecutarse. (El disco duro guarda a largo plazo la aplicacin para que sta no se pierda pero no juega un papel primordial cuando la aplicacin se ejecuta.) La memoria en s se divide en una seccin donde se guardan las funciones del programa, correspondiente al cdigo que controla la lgica de la aplicacin, y otra seccin de datos donde se guarda la informacin que quiere manipularse. Dada esta separacin entre funciones y datos en la memoria lo ms lgico siempre ha sido utilizar una programacin que se ajustara a ello dando origen a un gran nmero de lenguajes basados en esta estructuracin. Esta manera de programar tiene dos problemas principales. El primer problema es obligar a un programador a pensar como la mquina, en lugar de lo opuesto. El segundo problema es que toda la informacin presente es conocida y potencialmente utilizada por todas las funciones del programa y si se hiciera algn cambio en la estructura de alguno de los datos (se consideran todos como globales), potencialmente habra que modificar todas las funciones del programa para que stas pudieran utilizar la nueva estructura. Que tan problemtico pudiese ser esto? Pues que mejor ejemplo que el problema del ao 2000 donde un dato tan insignificante como la fecha, que al cambiarse de dos a cuatro dgitos result en costos mundiales de cerca de $1 trilln de dlares. Lo que empeor las cosas fue que todos estos programas tenan miles de funciones donde cada una de ellas requera de la fecha para funcionar correctamente, cmo en el caso de aplicaciones bancarias y nminas de compaas. 2.1.2 Programacin Orientada a Objetos Cmo puede ayudarnos la orientacin a objetos a solucionar los dos problemas principales de la programacin tradicional? La respuesta es que la orientacin nos ayuda a mejorar radicalmente ambas situaciones gracias a que la unidad bsica de programacin es el objeto. A nivel organizacional el concepto del objeto nos acerca ms a la manera de pensar de la gente al agregar un nivel de abstraccin adicional donde internamente la estructura del programa se ajusta a la arquitectura de la mquina. En relacin al segundo problema, los datos globales desaparecen, asignando a cada objeto sus propios datos y funciones locales, resultando en un programa o aplicacin definido exclusivamente en trmino de objetos y sus relaciones entre s, como se muestra en la Figura 2.2.


2

Objeto Objeto

ObjetoFigura 2.2 Programacin orientada a objetos: objetos globales. Obviamente debemos tener datos y funciones para que un programa tenga sentido, pero estos son guardados en cada objeto de manera independiente, como se muestra en la Figura 2.3.ObjetoFunciones

Datos

Figura 2.3 Programacin orientada a objetos: objetos globales que contienen datos y funciones locales. Ntese en el diagrama, que los datos estn ubicados en el centro del objeto (un concepto puramente ilustrativo) resaltando el efecto de que un cambio en la estructura de uno de estos datos slo afecta a las funciones del mismo objeto pero no al resto de la aplicacin. Todo lo relacionado al detalle de los objetos junto con sus datos y funciones ser descrito en el Captulo 4. 2.1.3 El Problema del Ao 2000 Revisado Cules hubieran sido las consecuencias del problema del ao 2000 si todas esas aplicaciones hubiesen sido programadas mediante la programacin orientada a objetos. La fecha como tal no hubiese sido un dato sino un objeto y aunque el objeto Fecha hubiese contenido originalmente dos en lugar de cuatro dgitos, el resto de la aplicacin se relacionara nicamente con el objeto Fecha como se muestra en la Figura 2.4.

Objeto Objeto

FechaFigura 2.4 El objeto "Fecha" como ejemplo de un objeto.


3

Llegando el ao 2000 donde se reconoce la deficiencia de los dos dgitos se habra cambiado la estructura interna de los datos del objeto Fecha a cuatro dgitos solamente afectando las funciones internas encargadas de manipular los datos internos del objeto Fecha, como se muestra en la Figura 2.5.Funciones Datos de 2 dgitos Funciones Datos de 4 dgitos

Fecha (2) Fecha (4) Figura 2.5 Extensin de la estructura de dato de "Fecha" de 2 a 4 dgitos. El resto de la aplicacin nunca se hubiera enterado y el diagrama mostrado en la Figure 2.4 hubiese sido idntico. Como consecuencia el mundo se hubiera ahorrado $1 trilln de dlares! Un cambio insignificante para un programa pero repercusiones brutales para la humanidad. Por supuesto que an con tecnologa orientado a objetos, un mal diseo no hubiese solucionado el problema, aunque el desafo para lograr malos diseos es mayor!

2.2 Programacin Orientada a Objetos El software orientado a objetos apoya ciertos aspectos que mejoran la robustez de los sistemas, este software requiere de ciertas caractersticas mnimas para considerarse orientado a objetos y finalmente debe integrarse como parte de un lenguaje de programacin. Estos temas son descritos a continuacin. 2.2.1 Aspectos que Mejoran la Robustez de los Sistemas Existen razones un poco ms tcnicas que motivan a la orientacin a objetos, como son la abstraccin, modularidad, extensiblidad y reutilizacin. ? ? Abstraccin. Una de las consideraciones ms importantes para tratar el problema de la complejidad del software es el concepto de abstraccin. La idea bsica de la abstraccin es reducir el nivel de primitivas o representaciones bsicas necesarias para producir un sistema de software. De manera sencilla esto se logra mediante el uso de lenguajes de programacin que contengan estructuras de datos de alto nivel. En otras palabras, la pregunta opuesta sera: por qu no programar en cdigo binario, o sea 0s y 1s ? La respuesta es que ninguna persona sera capaz de comprender una aplicacin al verse el cdigo y por otro lado requerira de programas extremadamente extensos para representar la aplicacin completa dada la simplicidad de la primitiva bsica. Los sistemas de software construidos con lenguajes de programacin de ms alto nivel reducen el nmero total de lneas de cdigo por lo tanto reducen su complejidad. Con la programacin orientada a objetos se definen dos niveles de abstraccin. El nivel ms alto, el de los objetos, es utilizado para describir la aplicacin mientras que el nivel ms bajo, el de los datos y las funciones, es utilizado para describir sus detalles. Este nivel inferior corresponde al nico nivel de la programacin tradicional. Esto refleja que la complejidad se maneja de mejor manera con la tecnologa orientada a objetos. En general cuanto ms podamos simplificar las tareas de desarrollo mejor ser el manejo de la complejidad. Por otro lado el objeto como estructura bsica sirve para separar el que de una aplicacin del como, o sea sus detalles, al contrario de la programacin tradicional donde el que y el como se resuelven a la vez. ? ? Modularidad. Otro aspecto importante de una aplicacin es su modularidad. La modularidad de un sistema depende de sus abstracciones bsicas, lo cual permite dividir el sistema en componentes separados. Al tener abstracciones de mayor nivel la modularidad de los componentes tambin es de mayor nivel reduciendo el nmero final de componentes lo cual a su vez simplifica su manipulacin y mantenimiento. Con la orientacin a objetos, la modularidad del sistema se da en base a objetos, un nivel ms alto que los datos y funciones tradicionales. El nmero final de mdulos, o sea objetos, es menor que el nmero original de datos y funciones. Esto reduce la complejidad de la aplicacin ya que el programador piensa en menos componentes a la vez descartando detalles innecesarios. ? ? Extensibilidad. En general, los sistemas de software tienden a ser modificados y ampliados durante el transcurso de su vida. Como se mencion en el Captulo 1, la Ley de Lehman dice que todo programa que se use se modificar. O sea, si un programa no se modifica es porque nadie lo quiere usar, por lo cual uno se pregunta: que tan larga es la vida de un sistema? En otras palabras, cundo se vuelve ms costoso mantener un sistema de software que desarrollar uno nuevo? La extensibilidad tiene como objetivo permitir cambios en el


4

sistema de manera modular afectando lo mnimo posible el resto del sistema. Con la orientacin a objetos, los cambios se dan a dos niveles: modificacin externa e interna de los objetos. Los cambios internos a los objetos afectan principalmente al propio objeto, mientras que los cambios externos a los objetos afectarn de mayor forma al resto del sistema. Dada la reduccin en el nmero de entidades bsicas en un sistema mediante abstracciones de nivel ms alto, se logra un desarrollo de sistemas ms estables con menor complejidad, y por lo tanto ms fcilmente extensibles. ? ? Reutilizacin. Una de las maneras de reducir la complejidad del software es mediante la reutilizacin o reuso de partes existentes. La pregunta que uno se hace es: cunto puedo reutilizar del cdigo y sistemas ya existentes? El reuso de cdigo reduce el tiempo del diseo, la codificacin, y el costo del sistema al amortizar el esfuerzo sobre varios diseos. El reducir el tamao del cdigo tambin simplifica su entendimiento, aumentando la probabilidad de que el cdigo sea correcto. Mediante el reuso de cdigo se puede aprovechar componentes genricos para estructurar bibliotecas reutilizables, y as lograr una estandarizacin y simplificacin de aplicaciones por medio de componentes genricos prefabricados. Tradicionalmente, los componentes o libreras de software han existido por muchos aos como procedimientos y funciones, particularmente para aplicaciones numricas y estadsticas. Y aunque el reuso es posible en lenguajes convencionales, los lenguajes orientados a objetos aumentan substancialmente las posibilidades de tal reuso, gracias a la modularidad de los sistemas. En particular, lenguajes como Java ofrecen componentes de estructuras de datos bsicas como colas, pilas, listas, rboles, junto con aquellas de ms alto nivel, utilizadas por ejemplo para la construccin de interfaces de usuario facilitando el desarrollo de nuevas aplicaciones. La problemtica mayor de la reutilizacin radica en que para construir componentes genricos, sencillos, con interfaces bien definidas y que puedan utilizarse en varias reas de aplicacin el esfuerzo es mucho mayor que para construir componentes que sern utilizados en una aplicacin. Con la orientacin a objetos, el objeto es la unidad de reuso ms pequea, pudindose aprovechar definiciones similares de objetos dentro de la misma aplicacin o incluso en distintas aplicaciones. Al agrupar objetos similares se puede lograr reutilizacin de componentes de ms alto nivel. Por otro lado, se puede aprovechar objetos con estructuras de datos y funciones similares, definiendo una sola vez los aspectos comunes y especializndolos en objetos adicionales. A un nivel ms amplio existen los marco de aplicacin (frameworks) donde una aplicacin genrica en un dominio particular se especializa para diferentes ambientes, algo promovido con diferente xito por compaas como SAP y PeopleSoft. Al definir una aplicacin en trminos suficientemente abstractos o generales, se puede en teora especializar su comportamiento sin tener que hacer ningn cambio en la estructura bsica de los componentes y de la propia aplicacin. Esto extendera de manera radical la utilidad de la aplicacin. Esto sera el elixir de la ingeniera de software, lograr crear nuevas aplicaciones sin escribir una sola lnea de cdigo, solamente integrando componentes ya existentes, como en la construccin de casas o puentes prefrabricados. Dado que es difcil lograr grandes niveles de reutilizacin sin contar con niveles intermedios, se ha realizado un esfuerzo muy importante conocido como Patrones de Diseo (Design Patterns), algo que discutiremos con mayor detalle en el captulo de diseo. 2.2.2 Caractersticas Mnimas de los Lenguajes Orientados a Objetos En la seccin anterior mencionamos la motivacin detrs de la orientacin a objetos: lograr mayor productividad en el desarrollo de software y mejorar la calidad de ste mediante niveles ms altos de abstraccin, apoyo a la modularidad, extensiblidad y reutilizacin de cdigo. En esta seccin describimos los conceptos bsicos que hacen que un lenguaje sea considerado efectivamente orientado a objetos. En general, cuatro aspectos deben existir en tal lenguaje: encapsulamiento, clasificacin, generalizacin y polimorfismo. En esta seccin nicamente introducimos los conceptos, los cuales sern descritos en mucho mayor detalle y ejemplos en el Captulo 4. ? ? Encapsulacin. Encapsulacin o encapsulamiento es la separacin de las propiedades externas de un objeto, o sea su interface, correspondiente a la interface de sus funciones, de los detalles de implementacin internos del objeto, o sea sus datos y la implementacin de sus funciones, como se muestra en la Figura 2.5. Esta separacin es muy importante. Si nos referimos al diagrama de la Figura 2.2, realmente el conocimiento de un objeto por otros objetos en la misma aplicacin es exclusivamente en base a la interface de dichos objetos. Todo el detalle, al estar encapsulado, es desconocido por el resto de la aplicacin, limitando el impacto de cualquier cambio en la implementacin del objeto, ya que los cambios a las propiedades internas del objeto no afectan su interaccin externa. Obviamente cualquier cambio en la propia interface del objeto afectara potencialmente a todo el resto de la aplicacin. Sin embargo el porcentaje de cdigo dedicado a las interfaces es por lo general muchsimo menor que el porcentaje total de lneas de cdigo utilizados para datos e implementacin de funciones. De tal manera se reduce la complejidad del sistema protegiendo los objetos contra posibles errores, y permitiendo lograr de mejor manera extensiones futuras en la implementacin de los objetos.


5

Interface Funciones Implementacin Funciones

Datos

Figura 2.5 Un objeto da a conocer a los dems objetos slo las interfaces de sus funciones. Clasificacin. En todo programacin orientada a objetos la clasificacin es un aspecto fundamental, donde objetos que contienen estructuras similares, correspondiente a tipos de datos y funciones similares, se clasifican como pertenecientes a la misma clase de objeto. Ntese de que hablamos de tipos de datos similares, dado que los valores de los datos an pueden cambiar en objetos de clase similar. Si todos los valores de los datos tuvieran que ser tambin iguales entonces todos los objetos de una misma clase seran idnticos, algo que limitara el alcance de la clasificacin adems de ser muy aburrido! ? ? Generalizacin. Si tomamos como base la clasificacin, y consideramos que no slo los objetos similares pueden clasificarse, sino tambin las propias clases de los objetos, entonces se define la generalizacin o especializacin de clases. Mediante la generalizacin, clases de objetos con estructura y comportamiento similar se reutilizan en la definicin de las nuevas clases. Estas nuevas clases se consideran clases ms especializadas o subclases mientras que las originales se consideran clases ms generales o superclases. El mecanismo para describir jerarquas de generalizacin de clases se conoce como herencia, un trmino muy utilizado en la orientacin a objetos, se dice que una subclase hereda de una superclase. La herencia puede ser sencilla, donde una subclase hereda de una sola superclase directa, o mltiple, donde una subclase hereda de mltiples superclases directas. La herencia es tambin una forma de reutilizacin de cdigo, ya que se aprovechan descripciones de clases de objetos para luego definir clases de objetos parecidos. ? ? Polimorfismo. Quizs el concepto ms complicado de explicar y en cierta manera el ms poderoso es el polimorfismo. De manera simplificada, mediante el polimorfismo se definen funciones con el mismo nombre e interfaz en distintas clases de objetos, pero bajo implementaciones distintas. Para qu sirve entonces el polimorfismo? Sin adelantarme a las explicaciones ms detalladas que vendrn en el Captulo 4, el polimorfismo es til para extender la funcionalidad existente en los objetos del sistema, a nuevos objetos an desconocidos en ese momento. Es como definir un estndar de interfaces para los objetos la cual debe ser seguida por todos los existentes y nuevos. Haciendo una analoga, todo el tiempo aparecen nuevas aplicaciones de software que pueden ejecutarse en sistemas ya existentes. Para que todo funcione correctamente el diseador del nuevo software debe mantener un estndar en las interfaces de sus funciones que sea ya conocida y aceptada aunque la implementacin de las funciones sea obviamente distinta. Nuevamente, esto es un ejemplo de cmo necesidades actuales en los sistemas pueden ser apoyado de mejor manera mediante nueva tecnologa que ayude a mejorar los diseos aunque no garantiza el resultado final. 2.2.3 Lenguajes de Programacin Los lenguajes orientados a objetos varan en su apoyo a los conceptos de orientacin a objetos y en los ambientes de desarrollo que incorporan. Por lo general, cada lenguaje, aunque orientado a objetos, tiene un diseo particular teniendo aspectos comunes entre si. El usuario debe considerar los distintos aspectos y tomar una decisin de cual es el lenguaje ms apropiado para su aplicacin. En general, el lenguaje que utilizaremos en este libro es Java por tres motivos principales: su integracin con el Web, sus buenas caractersticas como lenguaje de programacin y su gran aceptacin en el mercado que lo hacen uno de los ms utilizados en la actualidad. No sera completa una descripcin de la programacin orientada a objetos sin mencionar algunos de los lenguajes de programacin ms importantes. Considerando que existen lenguajes de programacin orientados a objetos ya desde hace varias dcadas sera bueno revisar brevemente la historia de estos lenguajes, como se muestra en la Tabla 2.1, en orden cronolgico. (Ntese que a partir de la dcada de los 80 la gran mayora son orientados a objetos.) ?? Ao 1957 Lenguaje FORTRAN Descripcin FORmula TRANslator fue el primer lenguaje de alto nivel y an sigue OO? No


6

1959

LISP

1959

COBOL

1960

ALGOL

1962

SIMULA

1962

PL/I

1962

APL

1964

BASIC

1968

Pascal

1972

Smalltalk

siendo el ms utilizado para clculos numricos. Fue diseado originalmente por John Backus entre 1954 y 1957. La versin actual es FORTRAN-90. Lisp fue diseado por McCarthy entre 1956 y 1961. Existen diferentes extensiones, conocidas hoy en da como CommonLisp. El lenguaje se utiliza principalmente para aplicaciones en Inteligencia Artificial. En un esfuerzo por hacer de LISP un lenguaje ms moderno, ste se extendi en 1988 con orientacin a objetos dando lugar a CLOS ("Common LISP Object System"). COmputer Business Oriented Language fue un lenguaje diseado a partir de 1959 por un grupo de profesionales conocidos como CODASYL (COnference on DAta SYstems Languages) y fue creado para aplicaciones principalmente financieras. Este lenguaje es el principal culpable del problema del milenio. La versin ms reciente es COBOL-97 conteniendo incluso extensiones de orientacin a objetos. ALGOrithmic Language fue desarrollado por J. Backus y P. Naur entre 1958 y 1960. Se le considera el primer lenguaje de propsito general para aplicaciones tanto industriales como cientficas. La ltima versin fue Algol68. El primer sistema con objetos fue B1000 en 1961, seguido por Sketchpad en 1962, conteniendo clones e instancias. Sin embargo, se le atribuye como el primer lenguaje orientado a objetos conteniendo objetos y clases, a Simula I, diseado por Ole Dahl y Kristen Nygaard del Centro de Computacin de Noruega (NCC Oslo) en 1962. El lenguaje, implementado por primera vez en 1964, fue diseado como una extensin a Algol 60 para la simulacin de eventos discretos. En 1967, se introdujo el lenguaje de propsito ms general Simula67 con un nmero mayor de tipos de datos adems de apoyo a objetos. Simula se estandariz en 1977. Programming Language 1 fue un lenguaje bastante complejo inventado en IBM a partir de 1962 para su famosos System/360. PL/I quera ser el lenguaje para los sistemas grandes y aplicaciones. Fue utilizado principalmente en la dcada de los 80s. "A Programming Language" fue diseado por Ken Iverson a partir de 1962 y utilizado por IBM. El objetivo principal era programar matemticamente. Inclua letras griegas, siendo un lenguaje extremadamente compacto. La versin actual es APL2. Este famoso lenguaje fue inventado por los profesores John G. Kemeny y Thomas E. Kurtz de la Universidad de Dartmouth, Estados Unidos. El primer programa de BASIC fue ejecutado el 1 de Mayo de 1964. Los dialectos ms modernos incluyen, a partir de 1991, VisualBasic diseado por Microsoft (reminicencias de su primer negocio en 1975 vendiendo interpretadores de Basic!) Este famosos lenguaje fue diseado por Niklaus Wirth del Instituto Tecnolgico Federal de Zurich entre 1968 y 1971. Pascal evolucion el diseo de Algol siendo por muchos aos el lenguaje para la enseanza de la introduccin a la programacin en las diversas universidades. Las versiones ms reconocidas posteriormente fueron promovidas por la compaa Borland con TurboPascal, y luego ObjectPascal en su ambiente de desarrollo Delphi, actualmente muy utilizado. Smalltalk diseado por Alan Kay (quien haba diseado y construido entre 1967 y 1968 la primera computadora personal basada en programacin orientada a objetos, llamada FLEX) y otros en XEROX PARC. La primera versin fue conocida como Smalltalk 72, cuyas races fueron Simula 67. Sigui Smalltalk 76, una versin totalmente orientada a objetos. En 1980, Smalltalk 80, fue la primera versin comercial del lenguaje, incluyendo un

No

No

No

S

No

No

No

No

S


7

1972

Prolog

1972

C

1977

CLU

1980

Modula

1983

Ada

1983

Objective-C

1983

Beta

1984

ML

1985

C++

ambiente de programacin orientado a objetos uniforme. El lenguaje Smalltalk ha influido sobre otros lenguajes como C++ y Java, y aunque no ha tenido el grado de xito de estos dos ltimos, quizs por lo tardo en volverse gratis junto a razones de eficiencia, este lenguaje tiene un gran nmero de seguidores en la actualidad, los cuales consideran a Smalltalk como el mejor lenguaje que existe. PROgramming in LOGic fue el progenitor de la programacin lgica. Fue diseado por Robert A Kowalski de la Universidad de Edinburgo, Reino Unido, y Alain Colmerauer de la Universidad de Aix-Marseille, Francia. C fue diseado por Ritchie y Thompson entre 1969 y 1973, en paralelo con los primeros desarrollos del sistema operativo Unix. Otra etapa del desarrollo fue hecha por Kernighan y Ritchie entre 1977 y 1979, cuando la portabilidad de Unix era demostrada. En esa poca se escribi el famoso libro The C Programming Language [Kernighan y Ritchie, 1978]. Es uno de los lenguajes de mayor utilizacin en la actualidad. "CLUster" es un lenguaje diseado por Barbara Liskov del MIT entre 1974 y 1977. El lenguaje utiliza conceptos bsicos de la orientacin a objetos aunque no es propiamente considerado como tal. La versin original se conoci como Modula-2 desarrollada por Niklaus Wirth diseada a mediado de los 70s como descendiente director de Pascal. El lenguaje inclua concurrencia y ciertos aspectos de la orientacin a objetos. La ltima versin conocida como Modula-3 fue diseada por Luca Cardelli. Dada su simpleza se desconoce por qu la falta de xito en la utilizacin de este lenguaje. El lenguaje fue diseado a partir de 1977 por el Departamento de Defensa de Estados Unidos, teniendo como autor principal a Jean Ichibah, para apoyar programacin de gran escala y promover la robustez del software. Su nombre fue en honor de Lady Ada Lovelace (1815-1852), una amiga y confidente de Charles Babbage, considerado el padre de la computacin por su trabajo terico hace un siglo y medio. Aunque la versin original no era orientada a objetos, la versin actual Ada 1995 s lo es. Existe otra versin no orientada a objetos conocida como Ada 83 o Ada Clsica. El lenguaje fue diseado por Brad Cox como una extensin a C pero con orientacin a objetos. El lenguaje ofreca muchos aspectos de diseo de Smalltalk-80 como su misma naturaleza sin tipos, aunque incorporaba datos sencillos de C, como enteros y reales. Su popularidad inicial vino a raz de su utilizacin en la computadora NeXT, incluyendo una interfaz de construccion como parte del ambiente NeXTSTEP, conocido luego como OpenStep, y actualmente adquirido por Apple como base para su nuevo sistema operativo MacOS X. Beta, desarrollado por Madsen en la Universidad de Aarhus en Dinamarca es otro lenguaje orientado a objetos inspirado por Simula con sintaxis similar a Pascal y algo parecido a C. Standard ML (Meta Language) representa una familia de lenguajes funcionales propuestas originalmente en 1983 y diseadas entre 1984 y 1988 por Milner y Tofte. La versin actual, Standard ML '97 es una revisin modesta y simplificada del languaje. C++ diseado por Bjarne Stoustrup, AT&T Bell Labs, entre 1982 y 1985 es uno de los lenguajes de programacin ms populares actualmente. El lenguaje se agrega aspectos de orientacin a objetos al lenguaje de C, siendo realmente un lenguaje hbrido donde un programador puede efectivamente programar en C aunque utilizando C++. En la actualidad muchos de los seguidores de este lenguaje se han pasado a Java. La razn primordial de esto es la complejidad de C++ junto con muchos aspectos

No

No

No

S

S

S

S

No

S


8

problemticos y falta de estandarizacin bajo distintas plataformas. S Eiffel, honrando a la famosa torre en Pars, fue diseado por Bertrand Meyer como un lenguaje orientado a objetos con una sintaxis superficialmente similar a C. Eiffel ofrece un ambiente interpretado de bytecode similar a Java, aunque por eficiencia este cdigo normalmente se traduce a C para luego ser compilado en el ambiente particular. El diseo del lenguaje apoya un enfoque de ingeniera de software conocido como Diseo por Contrato. Aunque es un lenguaje muy sencillo y poderoso nunca logr la aceptacin lograda por C++ y Java, posiblemente por la falta de compiladores gratis. S 1986 Self Self diseado por David Ungar y Randall Smith es un lenguaje cuya sintaxis es similar a Smalltalk. Un aspecto muy novedoso es la omisin de la nocion de clase en el lenguaje, donde un objeto se deriva de otro (su prototipo) por medio de copiado y refinado. Dado esto, Self es un lenguaje muy poderoso, sin embargo, es an un proyecto de investigacin requiriendo una gran cantidad de memoria y una gran mquina para ejecutar. 1988 CLOS CLOS ("Common LISP Object System") es una extensin de CommonLisp S mediante la orientacin a objetos desarrollada originalmente en 1988 por David Moon (Sumbolics), Daniel Bobrow (Xerox), Gregor Kiczales (Xerox) y Richard Gabriel (Lucid), entre otros. S 1990 Haskell Haskell desarrollado por un comit (Hughes, Wadler, Peterson y otros) tiene su nombre en honor a Haskell Brooks Curry, cuyo trabajo en lgica matemtica sirve como fundamento para los lenguajes funcionales. El lenguaje est altamente influenciado por Lisp aunque fue extendido con ciertos aspectos de la orientacin a objetos para ser ms moderno. S 1992 Dylan Dylan ( DYnamic LANguage es un lenguaje orientado a objetos ) originalmente desarrollado por Apple, se parece mucho a CLOS y Scheme, aunque ha sido influenciado por Smalltalk y Self. S 1995 Java Java, diseado por Gosling en Sun Microsystems entre 1994 y 1995 es el lenguaje orientado a objetos ms utilizado en la actualidad. El lenguaje es sencillo y porttil, bastante similar a C++, aunque tomando ideas de Modula-3, Smalltalk y Objective-C, hacindolo ms robusto y seguro. Java es tpicamente compilado en bytecodes que son luego interpretados por una mquina virtual de Java (JVM). Un aspecto primordial en el xito del lenguaje es su integracin con el Web mediante aplicaciones conocidas como applets que pueden ser ejecutadas desde un navegador del Web (browser). Otro aspecto importante es la inclusin de un gran nmero de paquetes y libreras que estandarizan y facilitan el desarrollo de nuevos programas. 2000 C# Este lenguaje conocido como C Sharp es el ltimo intento por parte de S Microsoft de competir contra el xito y el seguimiento que tiene Java. El lenguaje revisa muchos aspectos problemticos de C++. Tabla 2.1 La tabla describe los lenguajes ms importantes de la historia de la computacin haciendo nfasis en aquellos orientados a objetos.. 1986 Eiffel

Introduccin

10/11/2002

9


1

3 El Proceso para el Desarrollo de SoftwareUn proceso est definido como una serie de acciones u operaciones que conducen a un fin. En general, una empresa u organizacin requiere de uno o ms procesos para lograr sus objetivos, los cuales por lo general involucran la utilizacin de sistemas de software. En el caso de una empresa que se dedica al desarrollo de software, se requieren procesos que abarquen desde la creacin de un sistema de software hasta su mantenimiento. Todo esto es conocido como el ciclo de vida del software. Como hemos visto en el Captulo 1, el desarrollo de sistemas de software es algo muy complejo. De lo contrario todos haramos siempre software perfecto! Un aspecto bsico para manejar la complejidad inherente en los sistemas de software es contar con un modelo de proceso a seguir, como se discutir en el resto del captulo. 3.1 Modelo del Proceso El modelo de proceso define un orden para llevar a cabo los distintos aspectos del proceso. El modelo se puede definir como un grupo de estrategias, actividades, mtodos y tareas, que se organizan para lograr un conjunto de metas y objetivos. El modelo de proceso abarca aspectos como la planeacin, autoridad, prediccin, evaluacin y rastreabilidad (traceability). ? ? La planeacin involucra definir cmo se llevarn a cabo las diversas etapas del proceso sin limitarse a aspectos de desarrollo si no tambin por ejemplo, los organizacionales. ? ? La autoridad define cmo se puede influir para llegar a donde se quiere. ? ? La prediccin describe a donde se va a llegar. ? ? La evaluacin describe donde se encuentra el proceso actualmente. ? ? La rastreabilidad describe cmo se logr un resultado particular. En particular, el proceso de desarrollo es considerado como un conjunto de personas, estructuras organizacionales, reglas, polticas, actividades, componentes de software, metodologas y herramientas usadas o creadas especficamente para conceptualizar, desarrollar, ofrecer un servicio, innovar o extender un producto de software, es decir la forma en que la organizacin realiza sus distintos proyectos de generacin de software. Los modelos de proceso varan mucho entre s y dependen de las diversas opiniones o mximas generales en las cuales se basan [Goldberg & Rubin 1995], donde obviamente cada persona puede tener una opinin distinta al respecto. Por ejemplo algunas creencias en el desarrollo de software son: ? ? Es mejor comprender el problema antes de desarrollar una solucin. ? ? El proceso para resolver un problema debe dar un resultado predecible, sin importar del individuo que hace el trabajo. ? ? Debe ser posible planear y calcular el proceso con gran precisin. ? ? Evaluar y administrar el riesgo es importante para el xito del proceso. ? ? Etapas bien definidas con entregas intermedias aumentan la confianza que se tiene en el resultado final. En general, todas las creencias luego actan como base para definir las estrategias, actividades, mtodos, y tareas del modelo de proceso. Estos conceptos se describen a continuacin. ? ? Una estrategia es un plan para llevar a cabo un objetivo, en nuestro caso el desarrollo de software. Existen diversas estrategias para lograr mejor calidad en el software final. Una estrategia bsica se relaciona con el tipo de arquitectura que se desea crear, por ejemplo, utilizando elementos sencillos como bloques y componentes o como elementos prefabricados de ms alto nivel. Esta arquitectura puede incluso integrar diversos niveles de sofisticacin en los elementos. Las estrategias bsicas escogidas afectan directamente el tipo de programacin y los lenguajes que se utilizarn. En cierta manera, para este libro ya hemos definido nuestra estrategia bsica de desarrollo de software, la cual es el uso de tecnologa orientada a objetos, en particular usando el lenguaje Java. Sin embargo, an dentro esta estrategia de orientacin a objetos puede refinarse an mas. (Obviamente, se puede utilizar una estrategia distinta, incluso que no sea orientada a objetos.) La estrategia no slo afecta la arquitectura del sistema sino tambien cmo se llevarn a cabo las actividades del proceso. Mientras no se tengan conflictos, es posible combinar mltiples estrategias, donde las distintas actividades del proceso de software pueden hacerse bajo estrategias diferentes, definiendo implcitamente la estrategia global del modelo de proceso. Dos estrategias importantes son el uso de prototipos y reutilizacin. Hablaremos de esto ms adelante. ? ? Una actividad es una unidad o paso organizacional para llevar a cabo cierto aspecto de un proceso. En nuestro caso las actividades definen los distintos pasos necesarios para lograr las metas y objetivos definidos en el modelo de proceso, o sea en el desarrollo de software. Las actividades dependen de la arquitectura de software y deben ser simples de aprender y usar; deben simplificar la comprensin del sistema, deben ser suficientemente


2

poderosas para expresar la informacin requerida para modelar el sistema, deben ser lo suficientemente descriptivas para poder discutir el sistema sin ambigedades y deben proveer un modelo evolucionable del sistema. Las actividades bsicas necesarias para el proceso de desarrollo de software son las siguientes: (i) requisitos para capturar los aspectos funcionales correspondientes, cmo un usuario interactuara con el sistema; (ii) anlisis para dar al sistema una estructura robusta y extensible bajo un ambiente de implementacin ideal; (iii) diseo para adoptar y refinar las estructuras al ambiente de implementacin particular; (iv) implementacin para codificar el sistema; (v) pruebas para validar y verificar el sistema; (vi) integracin para pegar componentes del sistema; (vii) documentacin para describir los distintos aspectos el sistema y (viii) mantenimiento para extender la funcionalidad del sistema. ? ? Un mtodo es un procedimiento definiendo las tareas que deben llevarse a cabo para satisfacer la actividad. Existen mtodos, por ejemplo, para asegurar la calidad del software, seguir el progreso del proyecto y probar el software. Durante el anlisis, el mtodo debe ayudar en la identificacin de los objetos necesarios para la arquitectura del sistema. Anlisis estructurado y anlisis orientado a objetos son ejemplos de diferentes mtodos para hacer anlisis, cada uno con sus propias tareas. Una metodologa se refiere al estudio de los mtodos, existiendo un gran nmero de metodologas para el desarrollo de software. En general, distintas metodologas llevan a cabo las actividades del desarrollo de software de diferente manera. En este libro buscamos aplicar las metodologas ms evolucionadas utilizando tecnologa orientada a objetos. En el apndice del libro contrastaremos algunas de estas metodologas. ? ? Una tarea es un grupo relacionado de acciones contribuyendo a una accin mayor. Cada mtodo define un conjunto de tareas a llevarse a cabo para lograr los objetivos deseados. La tarea puede incluir condiciones de entrada y de salida que sern satisfechas antes y despus de su realizacin. Existen procesos de acuerdo al tipo de proyecto como se ver en la Seccin 3.1.1 y aunque no hay lmite a los diversos modelos de proceso que puedan existir, describiremos los ms clsicos: el Modelo de Cascada en la seccin 3.1.2 y el Modelo de Espiral en la seccin 3.1.3. Cada uno de estos modelos de proceso est definido con un propsito particular y posee distintas estrategias para especificar las diferentes actividades, mtodos y tareas. El tema de la madurez del modelo ser tratada en la seccin 3.1.4. 3.1.1 Procesos Adaptados a Tipos de Proyectos Una creencia comn pero equivocada en la industria del software es que hay un slo modelo de proceso que sirve para todo tipo de proyecto basados en tecnologa orientada a objetos. En general, el modelo de proceso depende del tipo particular de proyecto que se est llevando a cabo. Algunos de estos tipos de proyectos son: ? ? Primer proyecto de su tipo, donde se va a crear la mayora del software desde cero, aunque obviamente se pueden aprovechar componentes genricos para su desarrollo. Por ser la primera vez que se crea este tipo de software, se requiere ms tiempo para analizar el dominio del problema que para otros proyectos. Incluso aunque el dominio del problema sea familiar pudiera ser sta la primera versin de un sistema de software de este tipo. En un primer proyecto en su tipo, la incertidumbre crea riesgos adicionales. ? ? Segundo proyecto en su tipo, donde se busca agregar nueva funcionalidad a un proyecto conocido. El desarrollador tpicamente tiende a excederse agregando demasiada funcionalidad en comparacin al proyecto anterior (featuritis). El sistema se vuelve muchos ms grande que el original significando retrasos en el sistema, como ocurre con muchos de los paquetes comerciales de la actualidad. ? ? Variacin de un proyecto, donde se extiende un sistema ya existente. Esto puede involucrar introducir componentes de software reutilizables como un marco (framework), crear nuevos componentes o simplemente extender la aplicacin existente mediante nueva funcionalidad. Dependiendo de la estrategia particular, el modelo de proceso debe variar. Por lo general, el riesgo en este tipo de proyectos es mucho menor que en los primeros proyectos de su tipo. Lo que se debe hacer ya est definido por la naturaleza del software existente, sin embargo se debe comprender las nuevas extensiones en el software en especial si stos involucran componentes reutilizables. ? ? Proyecto de reescritura de legado (legacy), donde se busca transformar o hacer una reingeniera de un sistema ya existente desarrollado bajo tecnologas anteriores, a un sistema desarrollado bajo nuevas tecnologas, tales como las orientadas a objetos. Este ha sido el enfoque ms importante para tratar el problema del ao 2000. En lugar de remendar sistemas se aprovech para rescribirlos. Como la organizacin ya ha escrito el sistema por lo menos una vez antes, el proyecto de reescritura de legado tiene varias caractersticas en comn con otros modelos, como variacin de un proyecto donde por ejemplo, se incluir actividades para examinar el sistema existente, para extraer requisitos y para comprender la arquitectura anterior. Tambin tiene aspectos comunes con un primer proyecto en su tipo, ya que, se debe crear una nueva arquitectura sin poder contar con


3

??

??

software reutilizable del proyecto anterior. Adems, existen todos los riesgos involucrados con un primer proyecto usando una nueva tecnologa. Proyecto de creacin de software reutilizable, donde se busca crear uno o ms componentes de software reutilizables. Este tipo de proyecto es muy similar a otros proyectos de desarrollo de software, siendo necesario comprender requisitos y desarrollar el diseo completo del componente. Sin embargo, es diferente de otro tipo de sistemas, en que los requisitos tienen que considerar las necesidades de mltiples proyectos, asegurando que el diseo es suficientemente general para ser til en otras situaciones desconocidas. Por lo general, esto requiere de esfuerzos mucho mayores que para software no reutilizable, razn por la cual la mayora del software existente no es reutilizable. Proyecto de mejora de sistema o mantenimiento, donde se busca modificar los componentes bsicos de un sistema para apoyar nueva funcionalidad. Tales proyectos a menudo son relativamente pequeos en alcance y no incluyen rescribir componentes o la aplicacin completa. Se debe tener una buena comprensin de los componentes a ser mejorados y cmo estos cambios afectan el resto del sistema.

3.1.2 Modelo Cascada El modelo de cascada clsico data de la dcada de los 60s y 70s (Royce 1970, Boehm 1981). El modelo de cascada se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisin bien definidos (milestones o checkpoints). En su poca de esplendor, este modelo tuvo gran aceptacin en la comunidad de contratistas gubernamentales estadounidenses, ya que stos reciban sus pagos del gobierno en base a entregas basadas en horarios (schedule) predefinidos. El desarrollo de software implicaba una secuencia de actividades a realizarse y cuyo seguimiento era verificar que cada actividad haya sido completada. La ejecucin del modelo era muy lineal, por lo cual el modelo fue sencillo y atractivo; donde se especificaba las actividades para luego hacerlas de principio a fin. Se consideraba que una vez terminada una actividad se continuaba con la siguiente. La Figura 3.1 muestra un diagrama conceptual del modelo describiendo el orden a seguir de las ac

Ingeniería de Software Orientado a Objetos

Documents

Transcript of Ingeniería de Software Orientado a Objetos