wu (04) Pressman, R.S. (1999). “Conceptos del disefio orientado a los objetos” en Ingenieria del software. Un enfoque practico. México: McGraw-Hill, pp.417-423. CAPITULO 12: DISENO ORIENTADO A LOS OBJETOS 417 Durante los aftos ochenta, la répida evolucién de los lenguajes de progra- macion Smalltalk y Ada, seguida de un crecimiento explosivo del uso de los dialectos orientados a los objetos de C como C++ y Objective-C, produjeron un interés inusitado en el DOO, En un temprano tratamiento de los métodos para conseguir el diseto orientado a los objetos, Abbott [ABB83] mostré “como el andlisis de la descripcion del problema y su solucién en lenguaje natural se po- dia usar como guia para el desarrollo de fa parte visible de un paquete util (un paquete contiene tantos datos como los procedimientos que operan sobre ellos] y del algoritmo concreto para un problema dado”. Booch [BOO86a] amplié el trabajo de Abbott y popularizé el concepto de diseto orientado a los objetos. A finales de los ochenta, ¢! DOO se usaba en el diseiio de aplicaciones de software que iban desde las animaciones graficas en computadora hasta las telecomuni- caciones. Actualmente, muchos creen que con Ia llegada del nuevo milenio, los métodos y los lenguajes de programacién orientados a los objetos seran los que predominen. 12. . CONCEPTOS DEL DISENO ORIENTADO A LOS OBJETOS Al igual que otros métodos de disefio, el DOO introduce un nuevo conjunto de términos, notaciones y procedimientos para la derivacién del disefio del soft- ware. En esta seccién repasamos la terminologia orientada a los objetos (ya in- troducida en el Capitulo 8) ¢ introducimos algunos conceptos adicionales que son relevantes para el disefto. 12.2.1. Objetos, operaciones y mensajes EI funcionamiento del software se consigue al actuar sobre una estructura de datos (de un nivel de complejidad variable) uno o mas procesos de acuerdo con un procedimiento de invocacién definido por un algoritmo estatico o por or- denes dinamicas. Para conseguir un diseto orientado a los objetos, debemos es- tablecer un mecanismo para (1) representar la estructura de datos, (2) especifi- car el proceso y (3) llevar a cabo el procedimiento de invocacién. Un objeto es una componente del mundo real que se ha hecho corresponder con el campo del software. En el contexto de un sistema basado en computa- dora, un objeto tipicamente es un productor o un consumidor de informacién, o un elemento de informacién. Por ejemplo, objetos tipicos pueden ser maqui- nas, 6tdenes, archivos, monitores, interruptores, sefiales, cadenas alfanuméricas ‘© cualquier otro lugar, persona, cosa, ocurrencia, papel (de comportamiento) 0 suceso, Cuando se hace corresponder un objeto con su realizacién software, consiste en una estructura de datos privada y en procesos, denominados opera- ciones', que pueden legitimamente transformar la estructura de datos. Las ope- * También se usan los términos “meétodos” y “servicios”. Material compllado confines académicos, se prohie su reproduccin total parca sn la autorzacion de cada autor.418 TERCERA PARTE; DISENO E IMPLEMENTACION DEL SOFTWARE Interfaz Estructura 1D del sistema de datos N2 de teléfono de verificacion Estado del sister Tabla de sensores tipo de sensor Tiempo de retardo de la alarma NGmerois) de teléfono. Tipo de alarma Contrasefia maestra Contrasefia temporal Punteros a Programar ‘operaciones "| Mostrar Reiniciar Figura 12.1. Representacién de un objeto. raciones contienen unas construcciones procedimentales y de control que pue- den ser invocadas mediante un mensaje —una peticion al objeto para que realice alguna de sus operaciones. Recordando la notacidn introducida en el Capitulo 8, la Figura 12.1 mues- tra como representamos un objeto. El objeto sistema (parte del producto de se- guridad HogarSeguro) muestra su estructura de datos privada y las operaciones asociadas. El objeto también tiene una parte compartida, que es su interfaz. Los men- Sajes se mueven por la interfaz y especifican la operacién que se desea realizar sobre ¢] objeto, aunque no cdémo se ha de realizar la operacion. Es el objeto que recibe el mensaje el que determina cémo se implementa !a operacién requerida. Al definir un objeto con parte privada y proporcionar mensajes para invocar el procesamiento adecuado, conseguimos el ocultamiento de informacién —es decir, dejar ocultos para el resto de los elementos del programa los detalles de implementacién del objeto. Los objetos con sus operaciones proporcionan una modularidad inherente —es decir, los elementos del software (datos y procesos) estén agrupados con un mecanismo de interfaz bien definido (en este caso, los mensajes), 12.2.2. Aspectos de disefio Bertrand Meyer [MEY90] sugierc cinco criterios para juzgar la capacidad de un método de diseiio de conseguir la modularidad y los relaciona con el disefio orientado a los objetos: Material compllado confines académicos, se prohibe su reproduccin total o parca sin la autorzacién de cada autor.CAPITULO 12: DISENO ORIENTADO A LOS OBIETOS 419. © Descomponibilidad: \a facilidad con la que un método de diseiio ayuda al disefiador a descomponer un gran problema en subproblemas mas faciles de resolver. ‘© Componibilidad: ¢] grado en que un método de disehio asegura que las ‘componente del programa (médulos), una vez disefiadas y construidas, pueden ser reusadas para crear otros programas. ‘© Comprensibilidad: la facilidad con la que se puede comprender una com- ponente de un programa sin tener que referenciar otra informacion ni otros médulos. © Continuidad: la capacidad de realizar pequeftos cambios en un programa Y que esos cambios se manifiesten por si mismos con sélo unos cambios ‘correspondientes en uno o unos pocos médulos. © Proteccion: una caracteristica arquitectonica que reduce la propagacién de efectos laterales cuando se produce un error en un médulo dado. A partir de estos criterios, Meyer [MEY90] sugiere la derivacién de cinco prin- ios basicos de disefto para arquitecturas modulares: (1) unidades lingiistica- mente modulares; (2) pocas interfaces; (3) interfaces pequefias (acoplamiento débil); (4) interfaces explicitas; (5) ocultamiento de informacién. Los médulos se definen como wnidades lingiisticamente modulares cuando “corresponden a unidades sintacticas del Jenguaje utilizado” [MEY90]. Es de- cir, el lenguaje de programacién que se vaya a utilizar debe soportar directa- mente la modularidad. Por ejemplo, si el diseftador crea una subrutina, cual- quiera de los lenguajes de programacién mas populares (p. ¢j.: FORTRAN, C, Pascal) puede implementarla como una unidad sintactica. Pero, si lo que se de- fine es un paquete que contiene estructuras de datos y procedimientos, identi- ficandolos como una tnica unidad, seria necesario un Ienguaje como Ada (u otro lenguaje orientado a los objetos) para representar directamente ese tipo de médulo con la sintaxis del lenguaje. Para conseguir un bajo acoplamiento (un concepto de disefo introducido en el Capitulo 10), se debe minimizar el mimero de interfaces entre médulos (*pocas interfaces”) y minimizar la cantidad de informacién que se mueve a través de una interfaz (“interfaces pequefias”). Siempre que los médulos deban comunicarse, lo deben hacer de una forma obvia y directa (“interfaces explici- tas"). Por ejemplo, si los médulos Xe ¥ se comunican a través de una zona global de datos (lo que denominamos “acoplamiento comun”™ en el Capitu- Jo 10), violardn el principio de interfaces explicitas, ya que la comunicacién en- tre los médulos no resulta evidente para un observador externo. Finalmente, conseguimas el principio de ocultamiento de informacion cuando toda la informacion de un médulo esta oculta para un acceso desde el exterior, a menos que la informacién sea definida especificamente como «informacion Publica». ‘Los ctitetios y los principios de diseito presentados en esta seccién se pueden aplicar a cualqvier método de diseito (p. ej.: los podemos aplicar al disefto es- tructurado). Sin embargo, como veremos, el método de diseno orientado a los objetos consigue cada uno de esos criterios de forma més eficiente que los otros Material compllado confines académicos, se prohibe su reproduccin total o parca sin la autorzacién de cada autor.420 TERCERA PARTE; DISENO E IMPLEMENTACION DEL SOFTWARE enfoques, dando como resultado arquitecturas modulares que permiten conse- guir los criterios de modularidad de forma mis efectiva. 12.2.3. Clases, instancias y herencia Muchos objetos del mundo fisico tienen caracteristicas razonablemente simila- res y realizan operaciones razonablemente similares, Si observamos la planta de fabricacién de una fabrica de equipos pesados, veremos méquinas fresadoras, taladradoras y perforadoras. Aunque cada uno de esos objetos es diferente, to- dos pertenecen a una clase superior denominada “maquinas herramienta”. To- dos los objetos de la clase maquinas herramienta tienen atributos comunes (p. ej todos usan motores eléctricos) y realizan operaciones comunes (p. ¢j.: corte, arranque, parada). Por tanto, clasificando un “torno” como miembro de la clase de maquinas herramienta, ya sabemos algo acerca de sus atributos y sus apera- ciones, incluso sin saber exactamente cual es su funcién. Las realizaciones en software de objetos del mundo real se clasifican de forma muy parecida. Tados los objetos son miembros de una clase mayor y heredan la estructura de datos privada y las operaciones que han sido definidas para esa clase. Dicho de otra forma, una clase es un conjunto de objetos que tienen las mismas caracteristicas. Asi, un objeto es una instancia de una clase mayor, Recordando el sistema de seguridad HogarSeguro presentado en anteriores capitulos, llevamos a cabo el andlisis orientado a los objetos (Capitulo 8) ¢ iden- tificamos clases candidatas. Una de esas clases es sensor. Para esa definicion de clase, podemos instanciar objets sensores especificos, sensor de entrada, sensor de humo y sensor de movimiento. Utilizando el lenguaje de disefio de programas (LDP) introducido en el Capitulo 10, ‘TYPE sensor de movimiento IS INSTANCE OF sensor; implica la herencia de los atributos de sensor. Pero, {qué pasa si la herencia no es perfecta? Esta situacion se produce cuando una instancia candidata de una clase comparte la mayoria, pero no to- dos, de los atributos de la clase y requiere todas las operaciones de la clase, asi como otras adicionales, que s6lo son relevantes para el candidato a miembro. Por ejemplo. supongamos que se va a afiadir un nuevo tipo de sensor al sistema HogarSeguro. A diferencia de los sensores de humo, de entrada y de movi- miento, el nuevo sensor es “agresivo”, es decir, realiza alguna accién cuando detecta un suceso. Un sensor:de fuego alertard al panel de control de Hogar- Seguro (véase el Capitulo 8), pero también esparcird en el aire un producto qui- mico para frenar el avance del fuego, durante un periodo de tiempo progra- mado. Para dar cabida al sensor de fuego, creamos una subclase —esto es, heredamos Jos atributos y las operaciones de la clase sensor, pero los modifica- mos para ajustarlos a las caracteristicas especiales de sensor de fuego. En la Figura {2.2 se muestran la clase sensor original y la nueva subclase, denomi- nada sensor agresivo. Material compllado confines académicos, se prohibe su reproduccin total o parca sin la autorzacién de cada autor.CAPITULO 12: DISENO ORIENTADO A LOS OBJETOS 421. 1D del sensor Estado del sensor Estado del sensor Caracteristieas de la alarma| | Caracteristicas dela alarma. ‘umbral ‘umbyal tipo de sefal tipo de senal nivel deta sonal nivel de a serial Inertaz hardware Interfax hardware tipo tipo ceracteristicas AD caracteristicas AD datos de temporizacién Leer Establecer Probar Figura 12.2. llustracién de la clase sensor y su subclase sensor agresivo. El uso de clases, subclases y herencia es de crucial importancia en la inge- nieria del software moderna. La reutilizacién de componentes de software (lo que nos permite conseguir la composicién) se eva a cabo creando objetos (ins- tancias) que se forman sobre los atributos y las operaciones existentes heredadas de una clase o de una subclase. Sélo es necesario especificar cémo son las dife- rencias entre el nuevo objeto y la clase, en lugar de definir todas las caracteris- ticas del nuevo objeto. A diferencia de otros conceptos de disetto que son independientes del len- guaje de programacién que se utilice, Ia implementacién de las clases, de las subclases y de los objetos varia de acuerdo con el lenguaje de programacién que se utilice. Por esta raz6n, el anterior tratamiento genérico requerira ciertas mo- dificaciones para el contexto de cada lenguaje de programacién especifico, Por ejemplo, en Ada, los objetos se implementan como paguetes y las instancias se obtienen mediante el uso de abstracciones de datos y tipos. Por otro lado, el len- guaje de programacién Snualltalk implementa directamente cada uno de los conceptos anteriormente descritos, convirtiéndolo en un lenguaje de progra- macién verdaderamente orientado a los objetos. 4. Descripciones de los objetos La descripcion de disefto de un objeto (una instancia de una clase o de una sub- clase) puede tener dos formas distintas [GOL83]: Material compllado confines académicos, se proibe su reproduccin total o parca sin la autorzacién de cada autor.422 TERCERA PARTE: DISENO E IMPLEMENTACION DEL SOFTWARE 1, Una descripcién del protocolo que establece 1a interfaz del objeto, defi- niendo cada mensaje que puede recibir el objeto y las operaciones que rea- liza el objeto cuando recibe el mensaje. 2. Una descripcién de la implementacién, que muestra los detalles de cada operacién implicada en la recepcién de un mensaje por el objeto. Los de- talles de implementacién incluyen la informacion sobre la parte privada del objeto, esto es, los detalles internos de la estructura de datos, y los detalles procedimentales que describen las operaciones. La descripcién det protocolo no es otra cosa que un conjunto de mensajes con sus correspondientes comentarios asociados. Por ejemplo, una parte de la descripcién del protocolo del objeto sensor de movimiento (descrito anterior- mente) podria ser: MENSAJE (sensor de movimiento) > leer: DEVUELVE ID del sensor, estado del sensor; que describe el mensaje requerido para leer el sensor. De forma similar, MENSAJE (sensor de movimiento) -» establecer: RECIBE ID del sensor, es- tado del sensor establece 0 inicializa el estado del sensor. Para grandes sistemas con muchos mensajes, a menudo se pueden crear ca- tegorias de mensajes. Por ejemplo, para el sistema HogarSeguro las categorias de mensajes podrian ser: mensajes de configuracién del sistema, mensajes de monitorizacion, mensajes de sucesos, etc. Una descripcion de la implementacion de un objeto proporciona los detalles internos (“ocultos”) requeridos para su implementaci6n, aunque no necesaria- mente para su invocacién. Es decir, el disefiador del objeto proporciona una descripcion de su implementacion y, consecuentemente, crea los detalles inter- nos del objeto. Sin embargo, otro disefiador o programador que utilice el objeto u otras instancias del objeto, solo requiere la descripcién del protocolo, no la descripcion de la implementacién. Una descripcin de la implementacién esta compuesta por la siguiente in- formacién: (1) una especificacién del nombre del objeto y de la referencia a una clase; (2) una especificacion de Ja estructura de datos privada, con indicacion de los elementos de datos y sus tipos; (3) una descripcién procedimental de cada operacion 0, alternativamente, referencias a esas descripciones procedimenta- les, La descripcion de la implementacién debe contener suficiente informacion para que se puedan manejar de forma adecuada todos los mensajes descritos en la descripcion del protocolo. ‘Cox [COX85] carateriza las diferencias entre la informacion contenida en la descripcién del protocolo y la contenida en la descripcién de la implementa- cién, en términos de los “usuarios” y de los “suministradores” de los servicios. Un usuario de un “servicio” proporcionado por un objeto debe familiarizarse Material compllado confines académicos, se prohibe su reproduccin total o parca sin la autorzacion de cada autor.CAPITULO 12: DISENO ORIENTADO A LOS OBJETOS 423 con el protocolo de invocacién de ese servicio, es decir, con la forma de espe- cificar qué es lo que desea. Al suministrador del servicio (el propio objeto), !o ne le concierne es cdmo proporcionar el servicio al usuario, es decir, los deta- lles de implementacién. Este concepto, denominado encapsulacién, se resume de la forma siguiente [COX85]: [Un objeto] proporciona encapsulacidn, en cuanto que pone en servicio una es- tructura de datos y un grupo de procedimientos para accederla, de tal forma que los usuarios de esa facilidad puedan accederla a través de unas interfaces cuidadosa- mente documentadas, controladas y estandarizadas. Esas estructuras de datos encap- suladas, denominadas objetos, cuentas como datos activos a los que se les puede pe- dir que hagan cosas, taandéndoles mensajes. 12.3. METODOS DE DISENO ORIENTADOS A LOS OBJETOS A veces es dificil distinguir claramente el andlisis orientado a los objetos (Capitulo 8) y el diseiio orientado a los objetos *. Esencialmente, el andlisis orientado a los objetos (AO) es una actividad de clasificacién. Es decir, se ana- liza un problema con el fin de determinar clases de objetos que sean aplicables en el desarrollo de fa soluci6n. El disefo orientado a los objetos (DOO) permite al ingeniero de software indicar los objetos que se derivan de cada clase y las interrelaciones entre ellos. Ademas, el DOO debe proporcionar una notacién que refleje las relaciones entre Jos objetos. En este capitulo también se pueden apli- car de igual forma la terminologia, la notacién y el enfoque usados cn el AOO. Los primeros intentos de describir un método de disefto orientado a los ob- jetos no surgieron hasta principios de la década de los ochenta. Tanto Abbott [ABB83] como Booch [BOO86a] establecen que el DOO debe comenzar con una descripcion en lenguaje natural (p. ej.: espafiol) de la estrategia de solucion, mediante una realizacion en software, de un problema del mundo real. A partir de esa descripcion, el disefador puede identificar los objetos y las operaciones. Posteriores contribuciones de Schlaer y Mellor [SCL88] y de Coad y Yourdon [COA90] introdujeron una notacién mas amplia para asistir a esa actividad y argumentaron que se trataba realmente de una actividad de andlisis. En su estado actual de evolucién, los métodos de DOO combinan elementos de las tres categorias de diseno presentadas anteriormente en este libro: diseno de datos, disefio arquitectonico y disefio procedimental. Al identificar clases y objetos, se crean abstracciones de datos. Asociando operaciones a los datos, se especifican médulos y se establece una estructura para el software. Al desarro- lar mecanismos para la utilizacion de los objetos, (p. ¢j-: generacion de men- sajes) se describen las interfaces. Los métodos de DOO iniciales [BOO86a] estén caracterizados por los si- guientes pasos: A los lectores que no hayan leido completamente el Capitulo 8, se es insta a hacerlo ahora, Material compllado confines académicos, se prohibe su reproduccién total o parca sin la autorzacién de cada autor.