Programacin Orientada a Objetos

Clave 43100011 Maestra en Sistemas Computacionales

Mdulo 04 Clasificacin
Catedrtico MSC. Jose Juan Avia Grimaldo e-mail josejuan.avina@gmail.com josejuan.avina@upaep.mx Telfono 4 344761

Abril/Junio, 2008

Contenido del mdulo 4 Clasificacin

4.1. La importancia de una clasificacin adecuada 4.2 Identificacin de clases y objetos 4.3 Mecanismos y abstracciones importantes

Clasificacin
La clasificacin es el medio por el cual ordenamos el conocimiento. En el diseo orientado a objetos, el reconocimiento de la similitud entre las cosas nos permite exponer lo que tienen en comn en abstracciones clave y mecanismos, y eventualmente nos lleva a arquitecturas ms pequeas y simples. Desgraciadamente no existe un camino trillado hacia la clasificacin. Para el lector acostumbrado a encontrar respuestas e forma de receta, afirmamos inequvocamente que no hay recetas fciles para identificar clases y objetos. No existe algo que podamos llamar estructura de clases perfecta, ni un conjunto de objetos correcto. Al igual que en cualquier otra ingeniera, nuestra eleccin en el diseo son un compromiso conformado por muchos factores que compiten. Afortunadamente, existe un vasto legado de experiencia sobre la clasificacin en otras disciplinas. Partiendo de enfoques ms clsicos, surgieron tcnicas de anlisis orientado a objetos que ofrecen varias recomendaciones prcticas y reglase tiles para identificar las clases y objetos relevantes para un problema concreto. Estos heursticos centran el inters de este captulo.

4.1 La importancia de una clasificacin correcta

Clasificacin y diseo orientado a objetos La identificacin de clases y objetos es la parte ms difcil del diseo orientado a objetos. La experiencia muestra que la clasificacin implica descubrimiento e invencin. Mediante el descubrimiento se llega a reconocer las abstracciones clave y los mecanismos que forman el vocabulario del dominio del problema. Mediante la invencin, se idean abstracciones generalizadas as como nuevos mecanismos que especifican como colaboran los objetos. En ltima instancia, el descubrimiento y la invencin son ambos problemas de clasificacin, y la clasificacin es fundamentalmente un problema de hallar analogas. Cuando se clasifica, se persigue agrupar cosas que tiene estructura comn o exhiben un comportamiento comn. La clasificacin es relevante para todos los aspectos del DOO, sta ayuda a identificar jerarquas de generalizacin, especializacin y agregacin entre clases. La clasificacin tambin proporciona una gua para tomar decisiones sobre modularizacin. Se puede decidir ubicar ciertas clases y objetos juntos en el mismo mdulo o en diferentes, dependiendo de la similitud que se encuentra en estas 3

declaraciones; el acoplamiento y la cohesin son simplemente medidas de esa similitud. La dificultad de la clasificacin Ejemplos de clasificacin. En la biologa contempornea, la clasificacin denota el establecimiento de un sistema jerrquico de categoras sobre las bases de presuntas relaciones naturales entre organismos. La categora ms general de una taxonoma biolgica es el reino, seguido en orden de especializacin creciente por el filum, subfilum, clase, orden, familia, gnero y, finalmente, especie. Para un informtico la biologa puede parecer una disciplina madura hasta la pesadez, con criterios bien definidos para clasificar organismos, esto simplemente no es verdad. Como indica el bilogo Mey, a nivel puramente de hechos, no sabemos ni siquiera dentro de un orden de magnitud con cuantas especies de plantas y animales compartimos el globo: actualmente se han clasificado menos de 2 millones, y las estimaciones del nmero total varan entre 5 millones a ms de 50 millones. Adems criterios diferentes para clasificar los mismos organismos arrojan resultados distintos. La moraleja de todo esto es que incluso en las disciplinas rigurosamente cientficas, la clasificacin es altamente dependiente de la razn por la que se clasifica. Las mismas enseanzas pueden aprenderse de la qumica, con la clasificacin de los elementos que ha cambiado mltiples ocasiones, siempre teniendo en cuenta la clasificacin anterior. La leccin aqu es simple: como afirma Descartes El descubrimiento de un orden no es tarea fcil; sin embargo, una vez que se ha descubierto el orden, no hay dificultad alguna en comprenderlo. Los mejores diseos de software parecen simples, pero, como muestra la experiencia, exige gran cantidad de esfuerzo el diseo de una arquitectura simple. La naturaleza incremental e iterativa de la clasificacin. No se ha dicho todo esto para defender planificaciones de desarrollo de software de mucha duracin; sino para poner de relieve que la clasificacin inteligente es un trabajo intelectualmente difcil, y que la mejor forma de realizarlo es a travs de un proceso incremental e iterativo. Esta naturaleza de la clasificacin tiene un impacto directo en la construccin de jerarquas de clases y objetos en el diseo de un sistema de software complejo. En la prctica, es comn establecer una determinada estructura de clases en fases tempranas del diseo y revisar entonces esa estructura a lo largo del tiempo. Slo en etapas mas avanzadas del diseo, una vez que se han construido los clientes que utilizan tal estructura, se puede evaluar de forma significativa la calidad de la clasificacin. Sobre la base de esta experiencia, se puede decidir crear nuevas subclases a partir de otras existentes (derivacin). Se puede dividir una clase grande en varias ms pequeas (factorizacin), o crear una clase mayor uniendo otra ms pequeas (composicin).

Ocasionalmente, se puede incluso descubrir aspectos comunes que haban pasado desapercibidos, e idear una nueva clase (abstraccin). Por qu, entonces, es tan difcil la clasificacin?, Primero, no existe algo que pueda llamarse una clasificacin perfecta, aunque por supuesto, algunas clasificaciones son mejores que otras. Segn dicen Coombs, Raffia y Thrall potencialmente, hay al menos tantas formas de dividir el mundo en sistemas de objetos como cientficos para emprender esta tarea. Cualquier clasificacin es relativa a la perspectiva del observador que la realiza. Segundo, la clasificacin inteligente requiere una tremenda cantidad de perspectiva creativa. Este hecho recuerda una adivinanza: En que se parece un rayo lser y un pez de la familia de las carpas doradas? en que ninguno de los dos puede silbar. Solo una mente creativa puede encontrar similitudes entre cosas tan poco relacionadas entre s.

4.2. Identificando clases y objetos

Enfoques clsicos y modernos Histricamente han existido tres aproximaciones generales de a la clasificacin: Categorizacin clsica Agrupamiento conceptual Teora de prototipos. Categorizacin clsica: Todas las entidades que tienen una determinada propiedad o coleccin de propiedades en comn forman una categora. Tales propiedades son necesarias y suficientes para definir la categora. Por ejemplo las personas casadas constituyen una categora: Se esta casado o no se est, y el valor de esta propiedad es suficiente para decidir a que grupo pertenece determinada persona. Por otra parte, las personas altas no forman una categora, a menos que pueda haber un acuerdo respecto a algn criterio absoluto para el que se designa la propiedad alto de la propiedad bajo. La aproximacin clsica emplea propiedades relacionadas como criterio de similitud entre objetos. Concretamente, se puede dividir los objetos en conjuntos disjuntos dependiendo de la presencia o ausencia de una propiedad en particular. En sentido general, las propiedades pueden denotar algo ms que meras caractersticas medibles; pueden tambin abarcar comportamientos observables; por ejemplo, el hecho de que un pjaro puede volar, pero un pez no pueda es una caracterstica que distingue a un guila de un salmn. No hay medidas absolutas para la clasificacin, aunque una estructura de clases determinada puede ser ms adecuada para una aplicacin que para otra. Algunas 5

clasificaciones pueden ser ms significativas que otras, pero solo respecto a nuestros intereses, no porque representen la realidad de forma ms exacta o adecuada. Agrupamiento conceptual. Es una variacin de enfoque clsico, y se deriva de los intentos de explicar como se representa el conocimiento. Como afirman Stepp y Michalski, en este enfoque, las clases (agrupaciones de entidades) se generan formulando primero descripciones conceptuales de estas clases y clasificando entonces las entidades de acuerdo a sus descripciones. El agrupamiento conceptual esta en estrecha relacin con al teora de conjuntos difusos (multivalor), en la que los objetos pueden pertenecer a uno o mas grupos, en diversos grados de adecuacin. El agrupamiento conceptual realiza juicios absolutos de la clasificacin centrndose en la mayor adecuacin. Teora de prototipos. La categorizacin clsica y el agrupamiento conceptual son lo suficientemente expresivos para utilizarse en la mayora de las clasificaciones que se necesite realizar en el diseo de sistemas de software complejos. Sin embargo, existen algunas situaciones, en las que estas aproximaciones no son adecuadas. Esto conduce a la teora de prototipos, derivado del trabajo de Rosca en el campo de la Psicologa Cognitiva. Existen algunas abstracciones que no tienen ni propiedades ni conceptos delimitados con claridad. En esta la teora de prototipos: una clase de objeto se representa por un objeto prototpico y se considera un objeto como un miembro de esta clase si y solo si se parece a ese prototipo de forma significativa. Aplicacin de teoras clsicas y modernas. Estas tres aproximaciones tienen aplicacin directa en el diseo orientado a objetos. Segn nuestra experiencia, identificamos las clases y objetos en primer lugar de acuerdo a las propiedades relevantes para nuestro dominio particular. Aqu se hace hincapi en la identificacin de las estructuras y comportamiento que son parte del vocabulario del dominio del problema. Muchas de tales abstracciones suelen estar a nuestra disposicin. Si este enfoque fracasa en la produccin de una estructura de clases satisfactoria, hay que pasar a considerar la agrupacin de objetos por conceptos. Aqu se centra la atencin en el comportamiento de objetos que colaboran. Si ambos intentos fallan al capturar nuestra comprensin del dominio del problema, entonces se considera la clasificacin por asociacin, a travs de las cuales las agrupaciones de objetos se definen segn el grado en el que cada uno se parece a algn objeto prototpico. Ms directamente, estos tres enfoques de la clasificacin proporcionan el fundamento terico del anlisis orientado a objetos, que ofrece una seria de practicas y reglas pragmticas que se pueden aplicar para identificar clases y objetos en el diseo de un sistema de software complejo. 6

Anlisis orientado a objetos Las fronteras entre anlisis y diseo son difusas, aunque el objetivo principal de ambos es bastante diferente. En el anlisis se persigue modelar el mundo descubriendo las clases y objetos que forman el vocabulario del dominio del problema, y en el diseo se inventan las abstracciones y mecanismos que proporcionan el comportamiento que este modelo requiere. Enfoques clsicos. Estos enfoques se derivan de la categorizacin clsica y han sido propuestos por varios diseadores de metodologas que han propuesto varias fuentes de clases y objetos, derivados de los requerimientos del dominio del problema. Shlaer & Mellor
Cosas tangibles Papeles (roles) Eventos Interaccion es Coches, datos de telemetra, sensores Madre, profesor, poltico Aterrizaje, peticin Prstamo, reunin

Ross
Personas Lugares Cosas Organiza ciones Concepto s Eventos Humanos que llevan a cabo alguna funcin reas reservadas para personas o cosas. Objetos fsicos, o grupos de objetos que son tangibles. Coleccin formalmente organizada de personas, recursos. Etc. Principios o ideas no tangibleres per se. Cosas que suceden.

Coad & Yourdon

Estructuras Otros sistemas Dispositivos Eventos recordados Papeles desempead os Posiciones Unidades de organizacin Relaciones de clases y de partes Sistemas externos con los que la aplicacin interactua. Dispositivos con los que la aplicacin interacta. Sucesos histricos que hay que registrar. Roles que juegan los usuarios. Ubicaciones fsicas, oficinas, lugares. Grupos a los que pertenecen los usuarios.

Anlisis del comportamiento. Mientras estos enfoques clsicos se centran en cosas tangibles del dominio del problema, hay otra escuela de pensamiento en el AOO que se centra en el comportamiento dinmico como fuente primaria de clases y objetos. Estos enfoque tiene ms que ver con el agrupamiento conceptual: se forman clases basadas en grupos de objetos que exhiben comportamiento similar. Wirfs-Brock, hacen hincapi en las responsabilidades, que denotan el conocimiento que un objeto tiene y las acciones que un objeto puede realizar. Las responsabilidades estn encaminadas a comunicar una expresin del propsito de un objeto y su lugar en el sistema. Las responsabilidades de un objeto son todos los servicios que suministra para todos los contratos que soporta. Rubin y Goldberg, ofrecen una aproximacin a la identificacin de clases y objetos derivados de funciones del sistema. El enfoque que utilizamos pone en primer lugar el nfasis en la comprensin de lo que sucede en el sistema. Estos son los comportamientos del sistema. Seguidamente asignamos estos comportamientos a partes del sistema, y tratamos de entender quien inicia estos comportamientos y quien participa en ellos Los iniciadores y los participantes que desempean papeles

significativos se reconocen como objetos, y se les asignan las responsabilidades de actuacin para esos papeles. Este comportamiento esta en estrecha relacin de punto funcional (Albrech, 1979): Se define como una funcin de las actividades del usuario final. La funcin de actividades representa algn tipo de salida, pregunta, entrada, archivo o interfaz. Un punto funcional es cualquier comportamiento aplicable exteriormente y comprobable del sistema. Anlisis de dominios. Fue introducida por Neighbors, busca identificar las clases y objetos comunes a todas las aplicaciones dentro de un dominio dado (no solo de una aplicacin concreta e independiente), tales como mantenimiento de registro de pacientes, operaciones burstiles, compiladores. Si uno esta a mitad de un diseo y le faltan ideas sobre abstracciones clave que existen, un pequeo anlisis del dominio puede ayudarnos identificndonos las abstracciones clave que han mostrado ser tiles en otros sistemas relacionados con el nuestro. El anlisis de dominios funciona bien porque, excepto en situaciones especiales, existen pocos tipos de sistemas de software que son verdaderamente nicos. Anlisis de casos de uso. Formalizado por Jacobson; se acopla con los tres enfoques anteriores, para dirigir el proceso de anlisis de modo significativo. Un caso de uso se define como una forma o patrn o ejemplo concreto de utilizacin, un escenario que comienza con algn usuario del sistema que inicia alguna transaccin o secuencia de eventos interrelacionados. Los escenarios en conjunto describen las funciones del sistema en esa aplicacin; se analiza cada escenario para identificar objetos que participan en l; segn continua el proceso de desarrollo estos escenarios se expanden para considerar condiciones excepcionales as como comportamientos secundarios del sistema. Los escenarios sirven tambin como base para las pruebas del sistema. Fichas CRC. Propuesta por Beck y Cunningham como una herramienta par la enseanza de la POO. Estas fichas son una tarjeta de 3X5 (o 5X7), sobre la cual el analista escribe a lpiz- el nombre de una clase, sus responsabilidades y sus colaboraciones. Se crea una ficha para cada clase que se identifique como relevante para el escenario. Las fichas CRC pueden disponerse espacialmente para representar patrones de colaboracin. Semntica dinmica del escenario: Las fichas se disponen para mostrar el flujo de mensajes entre instancias prototpicas de cada clase. Semntica esttica del escenario: Las fichas se colocan para representar jerarquas de generalizacin/especializacin o de agregacin de clases. Descripcin informal en espaol. Propuesto primeramente por Abbott, quien sugiri redactar una descripcin del problema (o de parte del problema) en lenguaje natural y subrayar entonces los nombres y los verbos. Los nombres representan objetos candidatos y los verbos representan operaciones candidatas sobre ellos.

Este enfoque es til, porque es simple y porque obliga el desarrollador a trabajar en el vocabulario del espacio del problema. Sin embargo, el lenguaje humano es impreciso y ambiguo; adems, todo nombre pueden transformarse en verbo, y al revs; por tanto, es fcil dejar un sesgo en la lista de candidatos de objetos y operaciones. Anlisis estructurado. En esta aproximacin, se comienza con un modelo esencial del sistema, tal como lo describen los diagramas de flujo de datos y otros productos del anlisis estructurado. Estos modelos proporcionan un modelo formal razonable del problema; a partir de los cuales se pueden desprender los objetos, clases y operaciones candidatas. Hay que hacer hincapi que el diseo estructurado, tal como se empareja con el anlisis estructurado, es completamente ortogonal a los principios del diseo orientado a objetos. Desaconsejamos el uso de esta aproximacin como punto de partida para el diseo orientado a objetos, pero para algunas organizaciones es la nica alternativa pragmtica. Es tremendamente difcil construir un sistema orientado a objetos partiendo de un modelo tan obviamente dispuesto hacia la descomposicin algortmica.

4.3. Abstracciones y mecanismos clave

Identificacin de las abstracciones clave Bsqueda de las abstracciones clave. Una abstraccin clave es una clase u objeto que forma parte del vocabulario del dominio del problema. El valor principal que tiene la identificacin de tales abstracciones es que dan unos lmites al problema. Goldberg establece que la eleccin apropiada de objetos depende, por supuesto, de los propsitos a los que servira la aplicacin y de la granularidad de la informacin que va a manipularse. sta bsqueda conlleva dos procesos: Descubrimiento e invencin. En el primero se llega a reconocer la abstracciones utilizadas por los expertos del dominio (por ejemplo en un cajero automtico un cliente habla de cuentas, retiros, reintegros y dems); En el segundo, se crean nuevas clases y objetos que no son forzosamente parte del dominio del problema, pero son artefactos tiles en el diseo o implementacin (en el mismo ejemplo anterior un desarrollador introduce nuevas abstracciones como base de datos, manejadores de pantallas, listas, colas, pilas y dems). Se recomienda el uso de escenarios para guiar el proceso de identificacin de clases y objetos. 9

Refinamiento de las abstracciones clave. Una vez encontradas las abstracciones clave, hay que refinarlas de acuerdo a las mtricas de calidad vistas en el captulo anterior. Dada una nueva abstraccin, hay que ubicarla en el contexto de las jerarquas de clases y objetos que se han diseado. La colocacin de clases y objetos en los niveles correctos de abstraccin es difcil. A veces se puede encontrar una subclase general, y elegir moverla hacia arriba en la estructura, incrementando as el grado de comparticin. Esto se llama promocin de clases. Anlogamente, se puede apreciar que una clase es demasiado general, dificultando as la herencia para las subclases a causa de un vaco semntico grande. Esto recibe el nombre de conflicto de granularidad. En ambos casos se intenta encontrar abstracciones cohesivas y dbilmente acopladas, para mitigar estas dos situaciones. Se debe dar nombre correcta a las cosas de forma que reflejen su semntica - , a pesar de que es importante en la captura de la esencia de las abstracciones que se describen. El software debera escribirse tan cuidadosamente como la prosa en espaol. Los objetos deben nombrarse empleando frases con nombres propios, como elSensor. Las clases deberan nombrarse empleando frases construidas con nombres como, Sensores. Las operaciones de modificacin deberan nombrarse empleando frases construidas con verbos activos, como dibujar o moverIzquierda. Las operaciones de seleccin deberan implicar una interrogacin, o bien, nombrarse con verbos de tipo ser-estar, como extensionDe o estaAbierto. El uso de caracteres de subrayado y estilos de uso de mayusculas son en gran medida cuestiones de gusto personal. Da igual el estilo cosmtico que se use, pero al menos los programas propios deberan ser autoconsistentes. Identificacin de mecanismos. Un mecanismo describe cualquier estructura mediante la cual los objetos colaboran para proporcionar algn comportamiento que satisface un requerimiento del problema. En otras palabras, un mecanismo es una decisin de diseo sobre como cooperan colecciones de objetos. Los mecanismos representan as patrones de comportamiento. El mecanismo que elige un desarrollador de un conjunto de alternativas para cumplir cierto comportamiento es frecuentemente el resultado de factores como costo, fiabilidad, facilidad de fabricacin y seguridad. Mientras que las abstracciones clave reflejan el vocabulario del dominio del problema, los mecanismos son el alma del diseo. Durante el proceso de diseo, el desarrollador

10

debe considerar no solo el diseo de clases individuales, sino tambin como trabajan juntas las instancias de esas clases. Los mecanismos representan decisiones de diseo estratgicas, como le diseo de una estructura de clases. En contraste, sin embargo, el interfaz de una clase individual es ms bien una decisin de diseo tctica. Ejemplos de mecanismos. Considrese el mecanismo de dibujo utilizado en las GUI; varios objetos deben colaborar para presentar una imagen a un usuario: Una ventana, una vista, el modelo que se va a visualizar y algn cliente que sabe cuando (pero no como) hay que visualizar ese modelo. Primero el cliente dice a la ventana que se dibuje a si misma, lo que al fin y al cabo resulta en una imagen que se muestra al usuario. En este mecanismo el modelo esta completamente separado de la ventana y la vista en la que se presenta: las vistas pueden enviar mensajes a los modelos, pero los modelos no pueden enviar mensajes a las vistas. Smalltalk usa una variante de este mecanismo y lo llama paradigma MVC (model-view-control) Se emplea un mecanismo similar en casi cualquier marco de referencia de GUI orientado a objetos. Los mecanismos representan as un nivel de reutilizacin que es mayor a la reutilizacin de las clases individuales. Pueden encontrarse mecanismos prcticamente en cualquier dominio. Coad ha identificado una serie de mecanismos comunes en sistemas orientados a objetos, entre los que se incluyen patrones de asociacin temporal, de registro de eventos y multidifusin. En todos los casos, estos mecanismos no se manifiestan como clases individuales, sino como la estructura de clases que colaboran.

Resumen
La identificacin de clases y objetos es el problema fundamental en el diseo orientado a objetos; la identificacin implica descubrimiento e invencin. La clasificacin es fundamentalmente un problema de agrupacin La clasificacin es un proceso incremental e iterativo, que se complica por el hecho de que un conjunto dado de objetos puede clasificarse en muchas formas igualmente correctas. Los tres enfoques de la clasificacin son la categorizacin clsica (clasificacin por propiedades), agrupamiento conceptual (clasificacin por conceptos) y teora de prototipos (clasificacin por asociacin con un prototipo). Los escenarios son una potente herramienta para el AOO, y puede utilizarse para guiar los procesos de anlisis clsico, anlisis de comportamiento y anlisis de dominios. 11

 Las abstracciones clave reflejan el vocabulario del dominio del problema y pueden ser descubiertas en el dominio del problema, o bien ser inventadas como parte del diseo. Los mecanismos denotan decisiones estratgicas de diseo respecto a la actividad de colaboracin entre muchos tipos diferentes de objetos.

12

Bibliografa
1. Booch, Grady, Anlisis y Diseo Orientado a Objetos. Addison Wesley Longman 2da. Ed. Massachusetts, E.U.A (1998), Capitulo 3. 2. Deitel y Deitel, Como Programar en Java. Pearson Educacin, 1998. Capitulo 7. 3. Timothy Budd, Introduccin a la Programacin Orientada a Objetos. AddisonWesley Iberoamericana. (1991)

13