Anlisis y diseo orientado a objetos - Grady Booch Captulo 1 Complejidad 1.

La complejidad inherente al software Las propiedades de los sistemas de software simples y complejos. Podemos encontrar objetos del mundo fsico complejos, como glbulos blancos, una estrella etc., tambin puede existir en el software una gran complejidad. Sabemos que existen software que no son muy complejos, como lo son las aplicaciones que son especificadas, construidas y mantenidas por la misma persona, son sistemas con un propsito limitado y un ciclo de vida muy corto, y se los puede dejar sin efecto rpidamente. Desarrollar estas aplicaciones es ms tedioso que difcil .se prestar especial atencin a el desarrollo del software de dimensin industrial. Son aplicaciones con un conjunto muy rico de comportamientos, ej.: aplicaciones que mantienen integridad de miles de registros, sistemas para la gestin y control de trfico areo o ferroviario. Son sistemas con un ciclo de vida largo. Este tipo de software tiene la caracterstica que resulta difcil para el desarrollador individual comprender todo el diseo. La complejidad es una propiedad esencial no accidental esta complejidad se deriva de cuatro elementos: La complejidad del dominio del problema :los problemas que se intentan resolver con el software conllevan a elementos complejos, existe una complejidad externa que esta dada entre los usuarios y los desarrolladores. Los usuarios y los desarrolladores tienen perspectivas diferentes sobre la naturaleza del problema y por lo tanto realizan distintas suposiciones sobre la naturaleza de la solucin. Para expresar los requisitos se utilizan textos, acompaados de grficos. Son difciles de comprender, son abiertos a diferentes interpretaciones. Los requisitos de un sistema de software pueden cambiar durante el desarrollo. La observacin del producto, desde sus comienzos (diseo y prototipo) y posterior utilizacin cuando ya est instalado permite al usuario comprender mejor sus necesidades. Los grandes sistemas evo lucionan en el tiempo, para esto no se utiliza correctamente el termino mantenimiento des software. El mantenimiento consiste en corregir errores; evolucin es cuando los requerimientos cambian con el tiempo, y es conservacin cuando se utilizan medios extraordinarios para mantener un software anticuado y decadente. La dificultad de gestionar el proceso de desarrollo:La tarea principal del equipo de desarrollo es dar vida a una idealizacin; se hace lo posible por escribir menos cdigo mediante la utilizacin de mecanismos que simplifiquen, la reutilizacin de estructuras y cdigos existentes. Podemos encontrar sistemas terminados con miles o millones de lneas de cdigo, esta cantidad de trabajo exige un equipo de desarrolladores, lo ideal es trabajar con un equipo tan pequeo como sea posible, una mayor cantidad de miembros implica una coordinacin compleja y una coordinacin ms difcil. La flexibilidad se puede alcanzar a travs del software: El software ofrece una flexibilidad mxima por lo que el desarrollador puede expresar cualquier clase de abstraccin, esta es una propiedad que sucede ya que es el programador el que construye todas las bases sobre las que se apoyar el diseo. Esto trae como consecuencia que la industria del software es un negocio enormemente laborioso. Los problemas de caracterizar el comportamiento de sistemas discretos: En una aplicacin de gran tamao puede haber cientos o miles de variables. Un sistema con estados discretos es cuando se ejecuta el software con computadoras digitales, los sistemas discretos tienen un nmero finito de estados posibles, en sistemas grandes, la combinacin de estos hace enorme este nmero. Se intenta disear sistemas con una separacin de intereses, de modo tal que el comportamiento de una part del sistema e tenga el mismo impacto en el comportamiento del mismo. Los eventos externos llevan a un sistema a diferentes estados, la transicin debe ser controlada por los diseadores. Las consecuencias de la complejidad ilimitada: Cuantoms complejo sea el sistema, mas abierto esta el derrumbamiento total. El dominar la complejidad del software lleva a proyectos retrasados, presupuestos que se exceden, que son deficientes respecto a los requerimientos fijados, esto es lo que se denomina la crisis del software, esta crisis se traduce en el desperdicio de recursos humanos y en perdidas de oportunidad, debe tratar de que esta situacin se mantenga ya que el software puede amplificar la potencia del individuo.

2. La estructura de los sistemas complejos Ejemplos de sistemas complejos: La estructura de un computador personal. Una computadora personal es un dispositivo de complejidad moderada. Se componen de elementos como unidad central del proceso, un monitor, un teclado, dispositivos de almacenamientos secundarios, discos flexibles, disco duro. Si descomponemos una CPU encontraremos una unidad principal, una ALU y un BUS al cual se conectan los dispositivos perifricos. De esta manera se ve la naturaleza jerrquica de un sistema. Una computadora funciona correctamente solo junto a cada una de sus partes. Los niveles de esta jerarqua presentan diferentes niveles de abstraccin, cada uno se construye sobre el otro, cada uno es comprensible por si mismo. La estructura de plantas y animales. En la estructura de un computador cada parte forma una jerarqua, y cada nivel de esta jerarqua conlleva su propia complejidad. Todas las partes al mismo nivel de abstraccin interactan en forma definida. Siempre hay fronteras claras en el exterior y en el interior de cada nivel. En una computadora encontramos que las puertas NAND se usan tanto en el diseo como en la unidad de disco duro. No se encuentran partes individuales que sean responsables cada una de un nico y pequeo paso en un solo proceso ms grande. No hay partes centralizadas que coordinen directamente las actividades de las partes de niveles inferiores. Encontramos partes separadas que actan como agentes independientes, cada una de las cuales exhibe un comportamiento bastante complejo y cada uno cont ribuye a muchas funciones del nivel superior, a travs de la cooperacin mutua de colecciones significativas, de estos agentes se ve la funcionalidad a nivel superior. La estructura de la materia estudiando campos como la astronoma y la fsica nuclear nos dan ejemplos de sistemas muy complejos. Tambin cuenta con una jerarqua. La estructura de las instituciones sociales es un ejemplo de sistemas complejos. Grupos de personas se juntan para realizar tareas que no pueden ser hechas por individuos. Pueden s transitorias o er pueden durar generaciones. El crecimiento de la organizacin produce una jerarqua distinta. Las multinacionales contienen compaas, estas contienen divisiones, contienen delegaciones, oficinas locales; las fronteras pueden cambiar a lo largo del tiempo, el grado de interaccin varia entre los empleados de diferentes reas. Los cinco atributos de un sistema complejo hay cinco atributos comunes a los sistemas complejos 1. La complejidad toma la forma de la jerarqua, por lo cual un sistema complejo se compone de subsistemas relacionados que tienen a su vez sus propios subsistemas, hasta que se alcanza algn nivel nfimo de componentes. 2. La eleccin de que componentes de un sistema son primitivos es arbitrario queda a decisin del observador. 3. Los enlaces internos de los componentes suelen ser ms fuertes entre componentes. 4. Los sistemas jerrquicos estn compuestos usualmente de solo unas pocas clases diferentes de subsistemas en varias combinaciones y disposiciones. 5. Un sistema complejo que funciona ha evolucionado de un sistema simple que funcionaba, un sistema complejo diseado desde cero nunca funciona y no puede parchearse para conseguir que lo haga, debe lograrse partiendo de un sistema simple que funcione. Complejidad organizada y desorganizada. La forma cannica de un sistema complejo. La mayora de los sistemas no contienen una sola jerarqua, en un solo sistema complejo suelen estar presentes muchas jerarquas diferentes. Puede haber descomposiciones que representen una jerarqua estructural o de parte de,llamada estructura de objetos; existe una segunda jerarqua de tipos es un , llamada estructura de clases. Las dos jerarquas del sistema: su estructura de clases y su estructura de objetos, cada una esta dividida en capas con las clases y objetos mas abstractos construidos a partir de otros mas primitivos. La eleccin de las clases y objetos primitivos depende del problema que se maneja. Las estructuras jerrquicas y de objetos no son del todo independientes, cada objeto presenta una instancia especfica de alguna clase. Existen mas objetos que clases en un sistema complejo. Los sistemas complejos de software con mas xito son aquellos que en su diseo incluyen una estructura de clases y objetos bien construida y queposee los cinco atributos de los sistemas complejos. Las limitaciones de la capacidad humana para enfrentarse a la complejidad adems de la complejidad que existe al disear sistemas complejos, se suman a esta las limitaciones de la capacidad humana para tratar la complejidad. Cuando se analiza por primera vez un sistema complejo de software, aparecen muchas partes que deben interactuar con muchas otras, no existiendo un factor comn entre estas partes (complejidad desorganizada). Para lograr tener una organizacin en el proceso de diseo hay que pensar en muchas cosas a la vez. Esto es imposible de realizar por una sola persona, segn estudios psicolgicos demuestran que un persona tiene limitada su capacidad de comprender en forma simultanea diferentes a cciones, por tal motivo se plantea un dilema fundamental, que es el de la capacidad de la habilidad humana para enfrentarse a esta complejidad.

3. Imponiendo orden al caos El ROL de la descomposicin. Cuando se disea un sistema un sistema complejo, es es encial descomponerlo en partes ms pequeas. Cada una de las cuales se puede tratar de forma independiente. De esta manera se puentea la restriccin humana que existe sobre la capacidad de canal de la comprensin humana, para entender un nivel dado de un sistema, basta por comprender unas pocas partes. Descomposicin algortmica casi todos los informticos fueron adiestrados con el dogma del diseo estructurado, en la que cada mdulo presenta un paso de algn proceso global.Descomposicin orientada a objetos. Puede existir una descomposicin alternativa para el mismo problema. El tema pasa por descomponer el sistema con abstracciones claves del dominio del problema, en vez de des omponer el c problema en pasos (abrir, obtener), se identifican objetos ( archivo maestro, suma de comprobacin ). Son un conjunto de agentes autnomos que colaboran para llevar a cabo algn comportamiento de nivel superior. Un objeto es una entidad tangible que muestra un comportamiento bien definido, los objetos hacen cosas, y se les pide que hagan lo que hacen envindoles mensajes. Descomposicin algortmica versus orientada a objetos. La visin algortmica enfatiza el orden de los eventos, la visin orientada a objetos resalta los agentes que causan acciones o son sujetos a est s. La descomposicin orientada objetos produce sistemas a pequeos a travs de la re - utilizacin de mecanismos comunes, tambin son mas resistentes al cambio y estn mejor preparados para evolucionar en el tiempo, su diseo est basado en formas intermed ias estables, reducen el riesgo que representan construir sistemas de software complejos, porque estn diseados para evolucionar en forma incremental. El ROL de la abstraccin el alcance de la memoria limita la cantidad de informacin que somos capaces de recibir procesar y recordar. Organizando el estmulo percibido simultneamente en varias dimensiones y sucesivamente en una secuencia de bloques se consigue superar el cuello de botella de la informacin. Este proceso se llama abstraccin. Se deciden ignorar los detalles no esenciales, tratando con el modelo generalizado e idealizado del objeto. El ROL de la jerarqua la estructura de objetos es importante porque muestra como diferentes objetos colaboran entre si a travs de patrones de interaccin l amados mecanismos. La estructura de clases no es menos importante, porque resalta el comportamiento comn en el interior de un sistema, se puede tratar como distinta cada instancia de un determinado tipo de objeto, y puede asumirse que comparte las mismas conductas que todas las dems instancias de ese mismo tipo de objeto. La identificacin de las jerarquas en un sistema complejo no es fcil, porque se requiere que se descubran patrones entre muchos objetos. 4. El diseo de sistemas complejos La ingeniera como ciencia y como arte. Segn Petroski el Ingeniero tiene que lograr un diseo como artista, y luego analizarlo como cientfico aplicando el mtodo cientfico con tanto rigor como cualquier cientfico lo har. El significado del diseo en todas las ingenieras se utilizan diseos para solucionar un problema, suministrando un camino desde los requerimientos hasta la implantacin. Mostow sugiere que el propsito del diseo es construir un diseo que: satisfaga las especificaciones, se ajuste a limitac iones impuestas por el medio, satisfaga criterios de diseo, satisfaga restricciones sobre el propio proceso. Un diseo es el producto final del proceso de diseo. La importancia de construir un modelo. Construir un modelo es algo atractivo, cada modelo dentro de un diseo describe un aspecto especifico de un sistema que se est considerando. De ser posible se busca construir nuevos modelos en los que se tiene confianza. Los modelos pueden fallar en condiciones controladas, por lo que se evala cada model en condiciones previstas como o improbables, para luego modificarse. Los elementos de los mtodos de diseo del software. Segn el quinto atributo de los sistemas complejos el diseo de estos conlleva a un proceso incremental e interactivo. Los buenos mtodos de diseo introducen en el proceso de desarrollo alguna disciplina. La ingeniera de software desarrollo diferentes mtodos que pueden clasificarse en tres categoras. Cada uno incluye: notacin, proceso, herramientas. Un buen mtodo de diseo se bas en fundamentos tericos. Los a modelos de desarrollo orientado a objetos. El diseo orientado a objetos es un mtodo que lleva a una descomposicin orientada a objetos ( son modelos que se centran en las cosas que se encuentran en el espacio del problema ). Aplicando diseo orientado a objetos se crea software resistente al cambio y escrito con economa de expresin, estos modelos reflejan una importancia de plasmar explcitamente las jerarquas de clases y objetos del sistema que se disea. Estos modelos animan a construir aplicaciones que posen los cinco atributos de los sistemas complejos. 3

Captulo 2 El modelo de objetos Este modelo abarca los principios de abstraccin, encapsulado, modularidad, jerarqua, tipos, concurrencia y persistencia. Los mtodos de diseo estructurado se basan en la programacin estructurada, mientras que el diseo orientado a objetos se basa en la programacin orientada a objetos. La evolucin del modelo de objetos Tendencias de ingeniera del software Las generaciones de los lenguajes de programacin:En la historia de la ingeniera del software se produjeron diferentes tendencias, desplazamiento de la programacin al por menor de la programacin al por mayor y la evolucin de los lenguajes de alto nivel. Los sistemas han evolucionado en cuanto a la complejidad. La tendencia se desplaz desde los lenguajes que dicen al computador que hacer, hacia los lenguajes que describen las abstracciones clave en el dominio del problema. Los mecanismos de abstraccin fueron cambiando por cada lenguaje; los lenguajes de primera generacin se utilizaban para aplicaciones cientficas con un vocabulario matemtico. Los lenguajes de segunda generacin utilizaron abstracciones algortmicas con mquinas cada vez ms potentes, lo principal er decirle a la maquina lo que tena que a hacer, acercaba a los desarrolladores a el espacio del problema y los alejaba de la mquina, los cambios de tecnologa (con la llegada de los circuitos) abarataron los costos, que influyeron en la resolucin de ms tpos i de problemas, el programador describa los tipos de datos (clases de datos relacionadas entre s), los sesenta se caracterizaron por la actividad en materia de lenguajes de programacin, la escritura de cdigo de envergadura puso en evidencia las deficiencias de los lenguajes utilizados en ese momento, por lo cual los mismos evolucionaron hasta los utilizados actualmente. Los lenguajes basados en y orientados a objetos son los que mejor soportan la descomposicin orientada a objetos del software. La topologa de los lenguajes de primera y principios de la segunda generacin :Se entiende por topologa a los bloques fsicos bsicos de construccin de ese lenguaje y cmo esas partes pueden ser conectadas. En lenguajes como el FORTRAN y COBOL el bloque bsico de construccin de aplicaciones es el subprograma, tienen una estructura fsica plana y consiste en solo datos globales y subprogramas , existen dependencias de subprogramas respecto de los datos. Un diseo puede separarse lgicamente en diferentes clases de datos, un error en una parte del programa puede afectar al resto del sistema, es muy difcil mantener la integridad del diseo original. Un programa escrito en estos lenguajes suele contener una enorme cantidad de acoplamientos entre subprogramas, con diferentes significados de datos y flujos de control, amenazando la fiabilidad de todo el sistema y reduciendo la claridad global de la solucin. La topologa de los lenguajes de fines de la segunda generacin y principios de la tercera :En los sesenta se reconoci a los programas como puntos intermedios entre el problema y a computadora, en l los 50 se inventaron los subprogramas vistos como dispositivos para ahorrar trabajo, los mismos podan servir como mecanismos de abstraccin con tres consecuencias importantes: primero se inventaron lenguajes con pases de parmetros, segundo: se asent el fundamento de la programacin estructurada, tercero : siguieron los subprogramas con bloques especficos de programacin, utilizando los mismos para construir grandes sistemas como bloques fsicos bsicos de construccin. Esta topologa contina con los problemas de programacin a gran escala. La topologa de los lenguajes de finales de la tercera generacin :Los lenguajes de esta generacin contaban con un importante mecanismo estructurador para resolver problemas crecientes de la programacin a gran escala; los proyectos mayores contaban con equipos mayores de desarrollo, y se desarrollaban independientemente cada parte de los programas. La mayor parte de los programas admitan una estructura modular, cada mdulo poda llamarse de tres maneras posibles: un nmero de coma flotante, una matriz de diez elementos y un indicador del tipo booleano. Estos lenguajes tenan un mal soporte de abstraccin de datos, y la comprobacin estricta de tipos, por lo que estos errores solo podan detectars e durante la ejecucin del programa. La topologa de los lenguajes de programacin basados en objetos y orientados a objetos: La abstraccin de datos es muy importante para dominar la complejidad. Primero surgieron mtodos de diseo dirigido por los datos, segundo aparecieron teoras del concepto de tipo. Aparecieron lenguajes que reciben el nombre de basados en objetos y orientados a objetos. El bloque fsico de construccin en estos lenguajes 4

es el mdulo, que representa una coleccin lgica de clases y objetos en lugar de subprogramas. Una estructura fsica de una aplicacin orientada a objetos tiene el aspecto de un grafo, no el de un rbol, tpico en lenguajes orientados algortmicamente. Los datos y operaciones estn unidos de tal modo que los bloque s lgicos de construccin fundamentales de estos sistemas ya no son algoritmos, sino clases y objetos. En aplicaciones a escala industrial encontramos agrupaciones de abstracciones que se construyen en capas, una sobre otra. Encontramos colecciones de objetos que colaboran para lograr algn comportamiento de nivel superior Los mtodos de diseo orientado a objetos han surgido para ayudar a los desarrolladores a explotar la potencia expresiva los lenguajes de programacin basados en objetos, utilizando la clases y los objetos s como bloques bsicos de construccin. La programacin orientada a objetos ayuda a combatir la complejidad. POO, DOO y AOO Objetos son entidades que combinan las propiedades de los procedimientos y los datos en el sentido de que realizan computaciones y conservan el estado local, los objetos sirven para unificar las ideas de las abstracciones algortmicas y de datos. Existen propiedades invariantes que caracterizan un objeto y su comportamiento Fundamentos del modelo de objetos:El termino objeto surgi a principio de los setenta, para referirse a nociones que eran diferentes en su apariencia, pero relacionadas entre si; los objetos representaban componentes de un sistema descompuesto modularmente. Existieron sucesos que ayuda ron a evolucionar a los objetos: avance de arquitectura de computadores, de lenguajes de programacin, de metodologa, avance de modelos de bases de datos, avance en inteligencia artificial. Existi un cambio en la arquitectura de computadores y sistemas operativos orientados en objetos Programacin orientada a objetos: La programacin orientada a objetos es un mtodo de implantacin en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarqua de clases unidas mediante relaciones de herencia. Lo importante de esta frase es destacar tres puntos: primero la programacin orientada a objetos utiliza objetos como sus bloques lgicos de construccin; segundo, cada objeto es una instancia de alguna clase; tercero, cada clase est relacionada con otra por medio de relaciones de herencia. Si falta cualquiera de estos elementos un programa no es orientado a objetos. Segn WEGNER un lenguaje es orientado a objetos solo si satisface los siguientes requisitos: si soporta objetos que son abstracciones de datos con un interfaz de operaciones con nombre y un estado local oculto, si los objetos tienen un tipo asociado (clase), si los tpos (clases) pueden heredar i atributos de los supertipos (superclases). Para un lenguaje soportar herencia es posible expresar relaciones. Diseo orientado a objetos: El diseo orientado a objetos es un mtodo de diseo que abarca el proceso de descomposicin orientada a objetos y una notacin para describir los modelos lgico y fsico, as como los modelos esttico y dinmico del sistema que se disea. Hay dos partes importantes en esta definicin: primero, el diseo orientado a objetos utiliza diversas notaciones para expresar diferentes modelos de diseo lgico y fsico de un sistema. Se utiliza el termino diseo orientado a objetos para referirse a cualquier mtodo que encamine a una descomposicin orientada a objetos. Anlisis orientado a objetos:Es un mtodo que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. Elementos del modelo de objetos Tipos de paradigmas de programacin La mayora de los programadores trabajan bajo un paradigma apoyado por el lenguaje que usan, y por tanto tienen dificultades para apreciar las ventajas de elegir un estilo ms apropiado para el problema que tienen en manos. Un estilo es una forma de organizar programas sobre las bases de algn m odelo conceptual de programacin y un lenguaje apropiado para que resulten claros los programas escritos en ese estilo. Existen cinco tipos principales de estilos de programacin, a saber: orientado a procedimientos, orientado a objetos, orientados a lgica, orientados a reglas, orientados a restricciones. No hay un estilo de programacin que sea el mejor para todo tipo de aplicaciones; el estilo orientado a objetos es el ms 5

adecuado para el ms amplio conjunto de aplicaciones. Cada estilo de programacin se basa en su propio marco conceptual de referencia; cada uno con una actitud mental diferente y una forma distinta de pensar el problema. Para todas las cosas orientadas a objetos, el marco de referencia conceptual es el modelo de objetos. Hay cuatro elementos fundamentales en este modelo, sin estos elementos no es orientado a objetos: abstraccin, encapsulado, modularidad, jerarqua. Existen tres elementos secundarios (no esenciales): tipos, concurrencia, persistencia. Abstraccin Denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objetos y proporciona as fronteras conceptuales ntidamente definidas respecto a la persistencia del observador. Una abstraccin se concentra en la visin externa de un objeto, y sirve para separar el comportamiento esencial de un objeto de su implantacin. Tipos de abstraccin: abstraccin de entidades, objeto que representa un modelo til de una entidad del dominio del problema o del dominio de la solucin; abstraccin de acciones: objeto que proporciona un conjunto generalizado de operaciones y todas desempean funciones del mismo tipo; abstracciones de mquinas virtuales: objeto que agrupa todas las operaciones virtuales utilizadas por algn nivel superior de control u operacion que utilizan todas algn es conjunto de operaciones de nivel inferior; abstraccin de coincidencia: almacena un conjunto de operaciones que no tienen relacin entre si. La idea es construir abstracciones de entidades. Un modelo contractual es la visin exterior del objeto, la vista exterior define un contrato del que pueden depender otros objetos y debe ser llevado a cabo por el propio objeto, este contrato abarca las responsabilidades de un objeto, el comportamiento del cual es responsable. Un protocolo es la forma en que un objeto puede reaccionar. El concepto central de la abstraccin es la invarianza( condicin booleana, con un valor que se mantiene). Para cualquier operacin relacionada con un objeto se definen precondiciones y pos condiciones, la violacin de cualquiera de estas significara una ruptura del contrato. Una excepcin indica que no se cumpli con un invariante. Encapsulado Abstraccin y encapsulado son conceptos complementarios; la abstraccin observa el comportamiento, el encapsulado se centra en la implementacin que da lugar a este comportamiento. El encapsulado no muestra barreras explcitas. El encapsulado es el proceso de almacenar en un mismo compartimiento los elementos de una abstraccin que constituyen su estructura y su com portamiento; sirve para separar el interfaz contractual de una abstraccin y su implantacin. Modularidad Segn LISKOV la modularizacin consiste en dividir un programa en mdulos que pueden compilarse separadamente, pero que tienen conexiones con otros mdulos. Segn PARNAS las conexiones entre mdulos son las suposiciones que cada mdulo hace acerca de todos los dems. La decisin sobre el conjunto adecuado de los mdulos para determinado problema casi tan difcil como decidir sobre el conjunto adecuado de abstracciones. Los mdulos sirven como los contenedores fsicos en los que se declaran las clases y objetos del diseo lgico realizado. En el diseo estructurado tradicional, la modularizacin persigue ante todo el agrupamiento significativo de subprogramas, utilizando los criterios de acoplamiento y cohesin. En el diseo orientado a objetos, el programa presenta diferencias sutiles: la tarea es decidir donde empaquetar fsicamente las clases y los objetos a partir de la estructura lgica del diseo, y estos son claramente diferentes de los subprogramas. PARNAS deca: los detalles de un sistema, que probablemente cambien de forma independiente, deberan ser secretos en mdulos separados; las nicas suposiciones que deberan darse entre mdulos son aquellas cuyo cambio se considera improbable. Toda estructura de datos es privada a algn mdulo; a ella pueden acceder directamente uno o ms programas del mdulo, pero no programas de fuera del mdulo. Cualquier otro programa que requiera informacin almacenada de datos de un mdulo debe obtenerla llamando a programas de este. La modularidad es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados. Un objeto proporciona una frontera bien definida alrededor de una abstraccin, y tanto el encapsulado como la modularidad proporcionan barreras que rodean a esta abstraccin.

Jerarqua Un conjunto de abstracciones forma una jerarqua, y la identificacin de esas jerarquas en el diseo simplifica en gran medida la comprensin del problema. Jerarqua es una clasificacin u ordenacin de abstracciones. Las dos jerarquas ms importantes en un sistema complejo son su estructura de clases ( jerarqua de clases) y su estructura de objetos (la jerarqua de partes). La herencia es la jerarqua de clases ms importante, y es un elemento esencial de los sistemas orientados a objetos. La herencia define una relacin entre clases, en la que una clase comparte la estructura de comportamiento definida en una o ms clases lo que se denomina herencia simple o herencia mltiple. De esta manera la herencia representa una jerarqua de abstracciones, en la que una subclase hereda de una superclase. Las superclases representan abstracciones generalizadas, y las subclases representan especializaciones en las que los campos y mtodos de la superclase sufren aadidos, modificaciones o incluso ocultaciones. La herencia permite declarar las abstracciones con economa de expresin. La agregacin es un tipo de jerarq parte de, donde ua una clase est a nivel ms alto de abstraccin que cualquiera de las clases que constituyen su implantacin. La agregacin es un concepto soportado por estructuras similares a las de objetos. La agregacin plante el problema de propiedad. Tipos (tipificacin) Un tipo es una caracterizacin precisa de propiedades estructurales o de comportamiento que comparten una serie de entidades. Los tipos son la puesta en vigor de la clase de los objetivos, de modo que los objetivos de tipos distintos no pueden intercambiarse o, como mucho, pueden intercambiarse solo de formas muy restringidas. Concurrencia Un sistemaautomatizado puede tener que manejar muchos eventos diferentes simultneamente, es natural considerar un conjunto distribuido de computadores capaces de realizar multitarea. Un hilo de control es un proceso, todo programa cuenta con al menos de un hilo de control, pero un sistema con concurrencia puede tener muchos hilos de control, los cuales pueden ser transitorios o permanecer dura la ejecucin. nte Un proceso pesado es aquel que es manejado de forma independiente por el sistema operativo de destino, y abarca su propio espacio de direcciones. Un proceso ligero suele existir dentro de un solo proceso del sistema operativo en compaa de otros procesos ligeros, que comparten el mismo espacio de direcciones. Muchos sistemas operativos proporcionan soporte directo para la concurrencia en sistemas orientados a objetos. La concurrencia se centra en la abstraccin de procesos y la sincroniz acin. Persistencia Un objeto de software ocupa una cierta cantidad de espacio, y existe durante una cierta cantidad de tiempo. La persistencia conserva el estado de un objeto en el tiempo y en el espacio. La persistencia es la propiedad de un objeto por la que su existencia trasciende el tiempo, es decir que el objeto continua existiendo despus de que su creador deja de existir, o el espacio, la posicin del objeto varia con respecto al espacio de direcciones en el que fue creado. Aplicacin del modelo de objetos - Beneficios del modelo de objetos El modelo de objetos es diferente a los modelos aportados por los mtodos ms tradicionales de anlisis estructurado y programacin estructurada, el modelo de objetos introduce nuevos elementos y beneficios significativos. En un modelo de objetos se promueve la reutilizacin no solo del software, sino de diseos enteros conduciendo a la creacin de marcos de desarrollo de aplicaciones reutilizables, que se traduce en beneficios de costo y planificacin. Utilizar modelos de objetos producen sistemas mas flexibles al cambio. Estos sistemas pueden evolucionar en el tiempo, en lugar de ser abandonados o completamente rediseados en cuanto se produce el primer cambio en el tiempo. Resumen  La madurez de la ingeniera del software ha conducido al desarrollo de mtodos de anlisis, diseo y programacin orientada a objetos, todos los cuales tienen la misin de resolver los problemas de la programacin a gran escala.

       

Existen varios paradigmas de programacin distintos: orientados a procedimientos, orientado a objetos, orientados a lgica, orientados a reglas y orientados a restricciones. Una abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objetos, y proporciona as fronteras conceptuales definidas con nitidez, desde la perspectiva del observador. El encapsulado es el proceso de compartimentar los elementos de una abstraccin que constituyen su estructura y comportamiento. Sirve para separar el interfaz contractual de una abstraccin y su implantacin. La modularidad es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados. La jerarqua es una graduacin u orientacin de abstracciones. Los tipos son el resultado de imponer la clase de los objetos, de forma que los objetos de tipos diferentes no pueden intercambiarse o, como mucho, pueden hacerlo de formas muy restringidas. La concurrencia es la propiedad que distingue un objeto activo de uno que no esta activo. La persistencia es la propiedad de un objeto mediante la cual su existencia perdura en el tiempo y/o el espacio.

Captulo 3 Clases y objetos Las clases y los objetos son los bloques bsicos de construccin que utilizan los mtodos o rientados a objetos. La naturaleza de los objetos Que es y que no es un objeto Un objeto es cualquier entidad tangible que exhibe algn comportamiento bien definido. Desde el punto de vista humano un objeto puede ser: una cosa tangible o visible, algo que puede comprenderse intelectualmente, algo hacia lo que se dirige un pensamiento o accin. Un objeto es algo que modela alguna parte de la realidad y es algo que existe en el tiempo y el espacio. SMITH y TOCKEY sugieren que un objeto representa un elemento, unidad o entidad individual e identificable, ya sea real o abstracta, con un papel bien definido en el dominio del problema. Algunos objetos pueden tener lmites conceptuales precisos, pero aun as pueden representar eventos o procesos intangibles. Algunos objetos pueden ser tangibles, y aun as tener fronteras fsicas dificultosas. Un objeto tiene estado, comportamiento e identidad; la estructura de objetos similares definidos en su clase comn; los trminos instancia y objeto son intercambiables. Estado (Semntica) El estado de un objeto abarca las propiedades normalmente estticas del mismo ms los valores actuales normalmente dinmicos de cada una de esas propiedades. Una propiedad es una caracterstica inherente o distintiva, un rasgo o cualidad que contribuye a hacer que un objeto sea ese objeto y no otro. Las propiedades suelen ser estticas, porque estos atributos son inmutables y fundamentales para la naturaleza del objeto. Todas las propiedades tienen algn valor. El hecho de que un objet tiene un estado implica que o todo objeto toma cierta cantidad de espacio, ya sea en el mundo fsico o en la memoria del computador. Se dice que todos los objetos de un sistema encapsulan algn estado, y que todo el estado de un sistema est encapsulado en objetos. Comportamiento Ningn objeto existe en forma aislada. Los objetos reciben acciones y ellos actan sobre otros objetos. El comportamiento es como acta y reacciona un objeto en trmino de sus cambios de estado y paso del mensaje. Una operacin es una accin que un objeto efecta sobre otro con el fin de provocar una reaccin. El los lenguajes orientados a objetos las operaciones que el objeto cliente puede realizar sobre un objeto suele declararse como mtodo. Se puede decir que el comportamiento de un objeto es funcin de su estado as como de la operacin que realiza sobre l, teniendo algunas operaciones el efecto lateral de modificar el estado del objeto. El concepto de efecto lateral reafirma la definicin de estado: el estado de un objeto representa los resultados acumulados de su comportamiento.

Operaciones Una operacin denota un servicio que una clase ofrece a sus clientes. Un cliente puede realizar cinco tipos de operaciones sobre un objeto.      Modificador: es una operacin que altera el estado de un objeto. Selector: una operacin que accede al estado de un objeto, pero n altera ese estado. o Iterador:una operacin que permite acceder a todas las partes de un objeto en algn orden perfectamente establecido. Constructor: una operacin que crea un objeto y/o inicializa su estado. Destructor: una operacin que libera el estado de un objeto y/o destruye el propio objeto. Los subprogramas libres son procedimientos o funciones que sirven como operaciones no primitivas sobre un objeto u objetos de la misma clase. Los subprogramas libres estn agrupados segn las clases segn sobre las que se los ha construido.

Papeles y responsabilidades Todos los mtodos y subprogramas libres asociados con un objeto concreto forman su protocolo. El protocolo define la envoltura del comportamiento admisible a un objeto, y engloba la visin esttica y dinmica completa del mismo. Para la mayora de las abstracciones se divide este protocolo mayor en grupos lgicos de comportamiento. Estos constituyen una particin del espacio del comportamiento de un objeto denotan los papeles que un objeto puede desempear. Las responsabil idades de un objeto son todos los servicios que proporciona para todos los contratos que soporta. Los objetos como mquinas Se los puede idealizar como mquinas ya que el objeto cuenta con estados que tienen en cuenta el orden en que se invocan las operaciones. Se pueden clasificar los objetos como activos y pasivos. Un objeto activo es aquel que comprende su propio hilo de control, mientras que un objeto pasivo no. Los objetos activos suelen ser autnomos (que demuestren algn comportamiento sin que nin gn otro objeto opere sobre ellos), los objetos pasivos tienen estado cuando de acta sobre ellos. Identidad semntica La identidad es aquella propiedad de un objeto que lo distingue de todos los dems objetos. Espacio de vida de un objeto El tiempo de vida de un objeto se extiende desde el objeto que se crea por primera vez hasta que ese espacio se recupera. Para crear explcitamente un objeto hay que declararlo o bien asignarle memoria dinmicamente. Relaciones entre objetos. Tipos de relaciones Las relaciones entre dos objetos cualesquiera abarcan las suposiciones que cada uno realiza acerca de otro, hay dos jerarquas de objetos: enlaces y agregacin. SEIDEWITZ las llama relaciones de antigedad Y STRARK las llama relaciones de padre hijo. Enlaces Es una conexin fsica o conceptual entre objetos. Un objeto colabora con otros objetos a travs de sus enlaces con estos. Un enlace es una asociacin especfica por lo cual un objeto utiliza los servicios de otro objeto, o a travs de la cual un objeto puede comunicarse con otro. Como participante de un enlace un objeto puede desempear uno de tres papeles: Actor: un objeto que puede operar sobre otros objetos pero 9

nunca se opera sobre l por parte de otros objetos. Servidor: Un objeto que nunca o pera sobre otros objetos; solo otros objetos operan sobre l. Agente: un objeto que puede operar sobre otros objetos y adems otros objetos pueden operar sobre l; un agente se crea normalmente para realizar algn trabajo bajo el nombre de un actor u otro agente. Visibilidad Si tenemos dos objetos A y B, con un enlace entre ambos. Con el fin de que A enve un mensaje a B, B debe ser visible para A de algn modo. Sincronizacin Siempre que un objeto pasa un mensaje a otro a travs de un enlace, se dice que los dos objetos estn sincronizados. Cuando un objeto activo tiene un enlace con uno pasivo, hay que elegir uno de tres enfoques para la sincronizacin:    Secuencial: la semntica del objeto pasivo est garantizada solo en presencia de un nico objeto activo simultneamente. Vigilado: la semntica del objeto pasivo est garantizada en presencia de mltiples hilos de control, pero los clientes activos deben colaborar para lograr la exclusin mutua. Sncrono:la semntica del objeto pasivo est garantizada en presencia de mltiples hilos de control, y el servidor garantiza la exclusin mutua.

Agregacin Mientras que los enlaces denotan relaciones igual a igual o cliente servidor, la agregacin denota una jerarqua todo parte, con la capacidad de ir desde el todo hasta sus partes. Existen claros pros y contras entre los enlaces y la agregacin. La agregacin es a veces mejor porque encapsula partes y secretos del todo. A veces son mejores los enlaces porque permiten acoplamientos mas dbiles entre los objetos. La naturaleza de una clase Que es y que no es una clase Los conceptos de objetos y clases estn muy ligados, no se puede hablar de un objeto sin atencin a su clase. Existen diferencias importantes entre ambos trminos. Un objeto es una entidad concreta que existe en el tiempo y el espacio, una clase representa solo una abstraccin, la esencia de un objeto. Se puede hablar de la clase mamferos que representa las caractersticas comunes a todos los mamferos. Se puede definir una clase como un grupo, conjunto o tipo marcado por atributos comunes o un atributo comn; una divisin, distincin de grupos basada en la calidad, grado de competencia o condicin. En el contexto del anlisis y diseo orientados a objetos, se define una clase como: una clase es un conjunto de objetos que comparten una estructura comn y un comportamiento comn. Un solo objet no es ms que una instancia o de una clase. Un objeto no es una clase. Los objetos que no comparten un comportamiento y estructuras similares no pueden agruparse en una clase, porque no estn relacionados entre s a no ser por su naturaleza general como objetos. A veces las abstracciones son tan complejas que no pueden expresarse convenientemente en trminos de una sola declaracin de clase. Una clase es un conjunto de objetos que comparten una estructura comn y un comportamiento comn. Interfaz e implementacin Un objeto individual es una entidad concreta que desempea algn papel en el sistema global, la clase captura la estructura y comportamiento comunes a todos los objetivos relacionados. Una clase sirve como una especie de contrato que vincula a una abstraccin y todos sus clientes. En una visin de programacin por contrato lleva a distinguir entre visin externa y la visin interna. El interfaz de una clase proporciona su visin externa y por tanto enfatiza la abstraccin. Este interfaz se compone principalmente de las declaraciones de todas las operaciones aplicables a instancias de esta clase. La implementacin de una clase de una clase se compone principalmente de la implementacin de todas las operaciones definidas en el interfaz de la misma. Se puede dividir el interfaz de una clase entres partes: 10

  

Public: una declaracin accesible a todos los clientes. Protected: una declaracin accesible solo a la propia clase, sus subclases, y sus clases amigas. Private: una declaracin accesible solo a la propia clase y a sus clases amigas.

La mayor parte de los lenguajes de programacin ofrecen diversas mezclas de partes public, protected y private, entre las que los desarrolladores pueden elegir para establecer derechos especficos de acceso para cada parte del interfaz de una clase y de este modo ejercer un control sobre que pueden ver los clientes y que no pueden ver. Ciclo de vida de las clases Est relacionado con el comportamiento de las clases, de las interacciones de sus diversas operaciones a los largo del tiempo de vida de cada una de sus instancias Relaciones entre clases Tipos de relaciones Las clases al igual que los objetos no existen aisladamente. Se establecen relaciones ente dos clases por una de dos razones. Una relacin entre clases podra indicar algn tipo de comparticin. Existen tres tipos bsicos e relaciones entre clases. La primera es la generalizacin especializacin, que nos muestra una relacin es un (subclase especializada de una clase ms general). La segunda es la relacin todo parte que denota una relacin parte de. La tercera es la asociacin que denota alguna de pendencia entre clases. La mayora de los lenguajes orientados a objetos ofrecen soporte directo para alguna combinacin de las siguientes relaciones: Asociacin, herencia, agregacin, Uso, instalacin, meta clase. Asociacin Una asociacin solo denota una dependencia semntica y no establece la direccin de esta dependencia ni establece la forma exacta en que una clase se relaciona con otra. Cardinalidad En una asociacin de uno a muchos existen cero o ms instancias de una clase por cada clase que existe en otra. Esta multiplicidad denota la cardinalidad de la asociacin. Existen tres tipos habituales de cardinalidad en una asociacin: uno a uno, uno a muchos, muchos a muchos. Una relacin de uno a uno denota una asociacin muy estrecha, las relaciones muchos a muchos tambin son habituales. Herencia Una subclase puede heredar la estructura y comportamiento de su superclase. Herencia simple La herencia es una relacin entre clases en la que una clase comparte la estructura y o el comportamiento definidos en una (herencia simple) o ms clases (herencia mltiple). La clase de la que otras heredan se denomina superclase. La clase que hereda de otra o ms clases se denomina subclase. La herencia define una jerarqua de tipos entre clases, en la que una subclase hereda de una o ms superclases. La capacidad o no de soportar este tipo de herencia distingue a los lenguajes de programacin orientados a objetos de los lenguajes basados en objetos. Una subclase aumenta o restringe la estructura y comportamiento existentes en sus superclases. Una subclase que aumenta sus superclases se dice que utiliza herencia por extensin. Se espera que algunas clases tengan instancias y que otras no las tengan. Las clases sin instancias se llaman clases abstractas. La clase ms generalizada en una estructura de clases se llama la clase base. Una clase cualquiera tiene tpicamente dos tipos de clientes: instancias y subclases. La herencia significa que las subclases heredan la estructura de su superclase. Las subclases tambin heredan el comportamiento de sus superclases.

11

Polimorfismo simple Es un concepto de teora de tipos en el que un nombre puede denotar instancias de muchas clases diferentes en tanto estn relacionadas por alguna superclase comn. Herencia y tipos El paralelismo entre herencia y tipos es deseable cuando se ven las je rarquas de generalizacin especializacin creadas a travs de la herencia como un medio para capturar la conexin semntica entre abstracciones. Herencia Mltiple Con la herencia simple, cada subclase tiene exactamente una superclase. La herencia mlti ple plantea un estilo de clases, llamadas aditivas. Se combinan pequeas clases para construir clases con un comportamiento ms sofisticado. Una clase que se construye principalmente heredando de clases aditivas y no aade su propia estructura o comportamiento se llama clase agregada. Agregacin (Contencin fsica) Existen agregacin como contencin por valor, que es un tipo de contencin fsica que significa que el objeto no existe independientemente de la instancia que lo encierra. Es posible un tipo menos directo de agregacin, llamado contencin por referencia. Clientes y proveedores Las relaciones de uso entre clases corren paralelas a los enlaces hermano a hermano entre las instancias correspondientes de estas clases. Una relacin de uso es un posible refinamiento de una asociacin, por el que se establece qu abstraccin es el cliente y qu abstraccin es el servidor. Metaclase Todo objeto es una instancia de alguna clase. Una metaclase es una clase cuyas instancias son ellas mismas, clases. El propsito principal de una metaclase es proporcionar variables de clase y operaciones para iniciar variables de clases y crear la instancia simple de la metaclase. La interaccin entre clases y objetos Relaciones entre clases y objetos Las clases y objetos son conceptos separados pero en ntima relacin. Todo objeto es una instancia de alguna clase, toda clase tienen cero o ms instancias. Las clases son estticas, lo que significa que una vez que se crea el objeto, su clase est fijada. El papel de clases y objetos en el anlisis y diseo Durante el anlisis y las primeras etapas de diseo el desarrollador tiene dos tareas principales: identificar las clases y objetos que forman el vocabulario del dominio del problema, e idear las estructuras por las que conjuntos de objetos trabajan juntos para lograr los comportamientos que satisfacen los requerimientos del problema. El conjunto de estas clases y objetos son las abstracciones claves. En las etapas finales del diseo y entrando en la implantacin, la tarea del desarrollador cambia: el centr de o atencin est en la vista interna de esas abstracciones claves y mecanismos. De la construccin de clases y objetos de calidad Medida de la calidad de una abstraccin Para saber si una clase u objeto datos est bien diseado, se sugieren cinco mtricas: Acoplamiento, cohesin, suficiencia, complecin, ser primitivo. El acoplamiento es una nocin del diseo estructurado, pero con una interpretacin liberal tambin se aplica al diseo orientado a objetos. La medida de la fuerza de la 12

asociacin establecida por una conexin entre un mdulo y el otro. El acoplamiento fuerte complica un sistema porque los mdulos son ms difciles de comprender, cambiar o corregir por si mismos si estn muy interrelacionados con otros mdulos. La complejidad puede reducirse diseando sistemas con los acoplamientos ms dbiles posibles entre los mdulos. La cohesin tambin proviene del diseo estructurado, la cohesin mide el grado de conectividad entre los elementos de un solo mdulo. La forma de cohesin menos deseable es la cohesin por coincidencia, en la que se incluyen en la misma clase o mdulo abstracciones sin ninguna relacin. La forma ms deseable de cohesin es la cohesin funcional, en la cual los elementos de una clase o mdulo trabajan todos juntos para p roporcionar algn comportamiento bien delimitado. Por suficiente quiere decirse que la clase o mdulo captura suficientes caractersticas de la abstraccin como para permitir una interaccin significativa y eficiente. Por completo puede decirse que el interfaz de la clase o mdulo captura todas las caractersticas significativas de la abstraccin. Una clase o mdulo completo es aquel cuyo interfaz es suficientemente general para ser utilizable de forma comn por cualquier cliente. La complecin (estado de completo o completitud ) sugiere que las clases o mdulos sean primitivos. Las operaciones primitivas son aquellas que pueden implantarse eficientemente slo si tienen acceso a la representacin subyacente de la abstraccin. Seleccin de operaciones Semntica funcional El desarrollo del interfaz de una clase o mdulo es un trabajo difcil. Dentro de una clase dada. Mtodos de grado fino: tenemos una clase dada, se intenta mantener las operaciones primitivas, de manera que cada una tenga un comportamiento reducido. Otra tendencia es separar mtodos que no se comunican con otros. Se definen subclases que redefinan el comportamiento de las superclases , esto nos permite agrupar un comportamiento dado en un mtodo que conduzca a una interfaz simple pero mtod s ms o grandes y complicados; distribuir un comportamiento entre varios mtodos lleva a una interfaz ms complicada, pero a mtodos ms simples. Semntica espacial y temporal En este punto lo que se hace es especificar las decisiones sobre la cantidad de tiempo que lleva completar una operacin y la cantidad de espacio de almacenamiento que necesita. Los objetos cuya semntica se preserva en presencia de mltiples hilos de control son objetos protegidos o sincronizados. Eleccin de colaboraciones La eleccin entre clases y objetos est ligada a la eleccin de operaciones. Un objeto puede ser accesible a otro. Accesible significa la capacidad de una abstraccin para ver a otra y hacer referencia a recursos en su vista externa. Una abstraccin es accesible a otra donde sus mbitos se superpongan y slo donde estn garantizados los derechos de acceso. El acoplamiento es una medida de accesibilidad. La ley de Demter determina que los mtodos de una clase no deberan depender de la estructura de ninguna clase, salvo de la estructura inmediata superior de su propia clase. Cada mtodo debera enviar mensajes slo a objetos pertenecientes a un conjunto muy limitado de clases. Pueden existir estructuras con jerarquas de herencias anchas y poco profundas, est echas y profundas y equilibradas. Existen ventajas para cada r enfoque, pero debe quedar claro que la estructura correcta de clases depende del tipo de problema. Mecanismos y visibilidad Durante el diseo, se suele establecer como un objeto es visible a otro, existen cuatro formas fundamentales por las que un objeto x puede hacerse visible a un objeto y: El objeto proveedor es global al cliente, el objeto proveedor es parmetro de alguna operacin del cliente, el objeto proveedor es parte del objeto cliente, el objeto proveedor es un objeto declarado localmente en el mbito del diagrama de objetos. Eleccin de implementaciones. Representacin Es uno de los secretos encapsulados de la abstraccin. Segn Wirth, la eleccin de la representacin es algo bastante difcil, y no est determinado de manera unvoca por las posibilidades disponibles. Debe tomarse siempre a la luz de las operaciones que van a realizarse sobre los datos. Que representacin es mejor depende completamente del problema concreto.

13

Empaquetamiento Aparecen aqu problemas similares en la declaracin de clases y objetos dentro de los mdulos. Se busca construir mdulos con cohesin funcional y dbilmente acoplados. Resumen            Un objeto tiene estado, comportamiento e identidad. La estructura y comportamiento de objetos similares estn definidos en su clase comn. El estado de un objeto abarca todas las propiedades del mismo ms los valores actuales. El comportamiento es la forma en que un objeto acta y reacciona en trminos de sus cambios de estado y paso de mensajes. La identidad es la propiedad de un objeto que lo distingue de todos los dems objetos. Los dos tipos de jerarquas de objetos son los lazos de inclusin y las relaciones de agregacin. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comunes. Los seis tipos de jerarquas de clase son las relaciones de asociacin, herencia, agregacin uso, instanciacin y relaciones de metaclase. Las abstracciones clave son las clases y objetos que forman el vocabulario del dominio del problema. Un mecanismo es una estructura por la que un conjunto de objetos trabajan juntos para ofrecer un comportamiento que satisfaga algn requerimiento del problema. La calidad de una abstraccin puede medirse por su acoplamiento, cohesin, suficiencia, completitud y por el grado hasta el cual es primitiva.

Captulo 4 Clasificacin La clasificacin es el medio por el que ordenamos el conocimiento. La similitud entre las cosa permite exponer lo que tienen en comn en abstracciones clave y mecanismos, y esto nos lleva a arquitecturas pequeas y simples. La importancia de una clasificacin correcta Clasificacin y diseo orientado a objetos Identificar es descubrir, con esto se llega a reconocer las abstracciones clave y los mecanismos que forman el vocabulario del dominio del problema. Cuando se clasifica se persigue agrupar cosas que tienen una estructura comn o exhiben un comportamiento comn. La clasificacin ayuda a identificar jerarquas de generalizacin, especializacin y agregacin entre clases. Se reconocen patrones comunes de interaccin entre objetos. La clasificacin proporciona una gua para tomar decisiones sobre modularizacin. La clasificacin tambin desempea un papel en la asignacin de proces a los procesadores. os La dificultad de la clasificacin Un objeto es algo que tiene una frontera definida con nitidez. La naturaleza incremental e interactiva 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. Se pueden crear nuevas subclases a partir de otras existentes (derivacin), se puede dividir una clase grande en varias pequeas (factorizacin), o crear una clase mayor uniendo otras ms pequeas (composicin), se pueden descubrir aspectos comunes que haban pasado desapercibidos, e idear una nueva clase (abstraccin). Identificando clases y objetos Enfoques clsicos y modernos Existen tres aproximaciones a la clasificacin: 1. 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 14

la categora. Aquino afirma que se puede nombrar una cosa segn el conocimien que tenemos sobre to su naturaleza a partir de sus propiedades y efectos. La aproximacin clsica emplea propiedades relacionadas como criterio de similitud entre objetos. Se puede dividir los objetos en conjuntos disjuntos dependiendo de la presencia o ausencia de una propiedad particular. 2. Agrupamiento conceptual: Es una variacin ms moderna del enfoque clsico, y deriva en gran medida de los intentos de explicar cmo se representa el conocimiento, las clases (agrupaciones de entidades), se generan formulando primero descripciones conceptuales de estas clases y clasificando entonces las entidades de acuerdo con las descripciones. 3. Teora de Prototipos: La categorizacin clsica y el agrupamiento conceptual son suficientemente expresivos para utilizarse en la mayora de las clasificaciones que se necesite realizar en el diseo de sistemas de software complejos. Existen algunas situaciones en que estas soluciones no son adecuadas, esto conduce a un enfoque ms reciente llamado teora de prototipos. Existen algunas abstracciones que no tienen ni propiedades ni conceptos delimitados con claridad. La teoria de prototipos dice que una clase de objetos se representa por un objeto prototpico, y se considera un objeto como un miembro de esta clase si y solo si se parece a este prototipo de forma significativa. Anlisis orientado a objetos Las fronteras entre anlisis y diseo son difusas, aunque el objetivo principal de ambos es bastante diferente. El anlisis persigue modelar el mundo descubriendo las clases y los 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 Hay una serie de diseadores y metodologas que han propuesto varias fuentes de clases y objetos, derivadas de los requerimientos del dominio del problema. Se llama a estos enfoques clsicos porque derivan sobre todo de los principios de la categorizacin clsica. Shlaer y Mellor sugieren que las clases y objetos candidatos provienen habitualmente de una de las fuentes siguientes:     Cosas tangibles: coches, sensores de presin. Papeles (roles): madre, profesor, poltico. Eventos: Aterrizaje, interrupcin, peticin. Interacciones: Prstamo, reunin, interseccin.

Ross tiene una perspectiva similar al de la perspectiva del modelado de las bases de datos:       Personas: Humanos que llevan a cabo alguna funcin. Lugares: reas reservadas para personas o cosas Cosas: Objetos fsicos, o grupos de objetos, que son tangibles. Organizaciones: colecciones formalmente organizadas de personas, recursos, instalaciones etc. Conceptos: Principios o ideas no tangibles. Eventos: cosas que suceden, habitualmente a alguna otra cosa, en una fecha y hora concretas.

Coad y Yourdon sugieren:        Estructuras. Relaciones de clases y de partes. Otros sistemas: Sistemas externos con los que la aplicacin interacta. Dispositivos: Dispositivos con los que la aplicacin interacta. Eventos recordados. Sucesos histricos que hay que registrar. Papeles desempeados. Los diferentes papeles que juegan los usuarios en su interaccin con la aplicacin. Posiciones: Ubicaciones fsicas, oficinas y lugares importantes para la aplicacin. Unidades de Organizacin: Grupos a los que pertenecen los usuarios.

15

Anlisis del Comportamiento Los enfoques clsicos se centran en cosas tangibles del dominio del problema, hay otra escuela de pensamiento en el anlisis orientado a objetos que se centra en el comportamiento dinmico como fuente primaria de clases y objetos. Estos enfoques tienen ms que ver con el agrupamiento conceptual: se forman clases basadas en grupos de objetos que exhiben comportamiento similar. Otros enfoques hacen hincapi en las responsabilidades, 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 y su lugar en el sistema Las responsabilidades de un objeto son todo los servicios que suministran para todos los contratos que soporta. Rubin y Goldberg hacen una aproximacin a la identificacin de clases y objetos derivados de funciones de sistema. Proponen que el enfoque que utilizamos pone en primer lugar el nfasis en la comprensin de lo que sucede en el sistema. Segn Rubin el comportamiento de un sistema est relacionado estrechamente con la idea de punto funcional. Un punto funcional se define como una funcin de las actividades del usuario final. Una funcin de actividades representa algn tipo de salida, pregunta, entrada o interfaz. Un punto funcional es cualquier comportamiento apreciable exteriormente y comprobable del sistema. Anlisis de dominios El anlisis de dominios, busca identificar las clases y objetos comunes a todas las aplicaciones dentro de un dominio dado, tales como mantenimiento de registros de pacientes, operaciones burstiles. El anlisis de dominios funciona bien porque existen muy pocos tipos de sistemas de software que sean verdaderamente nicos, esta idea fue introducida por Neighbors. Se define el anlisis de dominios como un intento de identificar los objetos, operaciones y relaciones que los expertos del dominio consideran importantes acerca del mismo. Moore y Bailin sugieren los siguientes pasos el anlisis del dominio:     Construir un modelo genrico fantasma - del dominio consultado por expertos de ese dominio. Examinar sistemas existentes en el dominio y representar esta comprensin en un formato comn. Identificar analogas y diferencias entre los sistemas consultando con expertos del dominio. Refinar el modelo genrico para acomodar sistemas ya existentes.

Anlisis de casos de uso Es 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. Puede aplicarse el anlisis de casos de uso en el momento en el que los usuarios finales, otros expertos del dominio y el equipo de desarrollo enumeran los escenarios fundamentales para el funcionamiento del sistema. Estos escenarios en conjunto describen las funciones del sistema en esa aplicacin. El anlisis procede entonces como un estudio de cada escenario, utilizando tcnicas de presentacin. A medid que el equipo pasa por a cada escenario, debe identificar los objetivos que participan en l, las responsabilidades de cada objeto, y cmo esos objetos colaboran con otros. El equipo se ve forzado a idear una clara separacin de intereses entre todas las abstracciones. Segn contina el proceso de desarrollo, estos escenarios iniciales se expanden para considerar condiciones excepcionales as como componente secundarios del sistema. Fichas CRC Las fichas CRC han surgido como una forma simple, pero efectiva de analizar escenarios. Las fichas CRC han demostrado ser una herramienta de desarrollo muy til que facilita las tormentas de ideas y mejora la comunicacin entre desarrolladores. Una ficha es una tarjeta con una tabla de 3x5, sobre la cual el analista escribe el nombre de una clase, sus responsabilidades y sus colaboradores. A medida que le equipo avanza por ese escenario, puede asignar nuevas responsabilidades a una clase ya existente, agrupar ciertas responsabilidades para formar una nueva clase o dividir las responsabilidades de una clase en otras de grano ms fino, y quizs distribuir estas responsabilidades a una clase diferente.

16

Descripcin Informal en espaol Una alternativa para el anlisis orientado a objeto clsico fue propuesta por A bbott, quien sugiri redactar una descripcin del problema en lenguaje natural. Este enfoque es til porque es simple y porque obliga al desarrollador a trabajar en el vocabulario del espacio del problema. Pero cuenta con una desventaja y la misma es que el lenguaje humano es impreciso. Anlisis Estructurado Esta alternativa utiliza los productos del anlisis estructurado como va de entrada al diseo orientado a objetos, hay una gran cantidad de analistas con experiencia en anlisis estructurado. Se comi nza con un e modelo esencial del sistema, como los diagramas de flujo de datos y otros productos del anlisis estructurado. Estos diagramas suministran un modelo formal razonable del problema. Partiendo de este modelo, puede pasarse a identificar las clases y objetos significativos en el dominio del problema de tres formas distintas. MacMenamin y Palmer proponen comenzar con un anlisis del diccionario de datos y proceder a analizar el diagrama de contexto del modelo. Hay dos tcnicas que llevan al anlisis de diagramas de flujos de datos individuales. Dado un diagrama de flujo de datos concreto, los objetos candidatos pueden derivarse de las siguientes entidades externas, almacenes de datos, almacenes de control, transformaciones de control. Las clases candidatas derivan de dos fuentes: Flujos de datos y flujos de control. Sidewitz y Stark sugieren otra tcnica, que llaman anlisis de abstraccin. El anlisis de abstracciones se fundamenta en la identificacin de las entidades centrales. En el anlisis es tructurado los datos de entrada y salida se examinan y se siguen hacia adentro hasta que alcanzan el nivel ms alto de abstraccin. Los procesos entre las entradas y las salidas forman la transformacin central. En el anlisis de abstracciones el diseador hace lo mismo, pero tambin examina la transformacin central para determinar que procesos y estados representan el mejor modelo abstracto de lo que hace el sistema. Tras identificar la entidad central en un diagrama de flujo de datos especfico, el anlisis de abstracciones procede a identificar todas las entidades de apoyo siguiendo los flujos de datos aferentes y eferentes a la entidad central, agrupando los procesos y estados hallados en el camino. Abstracciones y mecanismos clave Identificacin de las abstracciones clave Una abstraccin clave es una clase u objeto que forma parte del vocabulario del dominio del problema. La identificacin de abstracciones clave es altamente especfica de cada dominio. La identificacin de las abstracciones clave conlleva dos procesos: descubrimiento e invencin. Mediante el descubrimiento, se llega a reconocer las abstracciones utilizadas por expertos del dominio. Mediante la invencin, se crean nuevas clases y objetos que no son forzosamente parte del dominio del problema, pero son artefactos tiles en el diseo o la implantacin. Refinamiento de abstracciones clave Una vez que se identifica determinada abstraccin clave como candidata, hay que ubicarla en el contexto de las jerarquas de clases, y objetos que se han diseado. La colocacin de clases y objetos en lo niveles correctos de abstraccin es difcil. A veces se puede encontrar una subclase general, y elegir moverla hacia arriba en la estructura de clases, incrementando as el grado de comparticin. Esto se llama promocin de clases. Se puede apreciar que una clase es demasiado general, dificultando as la herencia por las subclases a causa de un vaco semntico grande. Esto recibe el nombre de conflicto de granularidad. Las clases y los objetos deberan estar a nivel de abstraccin adecuado: ni demasiado alto ni demasiado bajo. Sugerencias: Los objetos deberan nombrarse empleando frases construidas con nombres propios, como elSensor o simplemente forma. Las clases deberan nombrarse empleando frases co nstruidas con nombres comunes, como sensores o formas. 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 del tipo ser estar, como extensionDe o estaAbierto. El uso de caracteres de subrayado y estilos de uso de maysculas son en gran medida cuestiones de gusto personal.

17

Identificacin de mecanismos El trmino mecanismo describe cualquier estructura mediante la cual los objetos colaborasen para proporcionar algn comportamiento que satisficiese un requerimiento del problema. Mientras el diseo de una clase incorpora el conocimiento de cmo se comportan los objetivos individuales, u mecanismo es una n decisin de diseo sobre como cooperan colecciones de objetos. Los mecanismos representan patrones de comportamiento. La pulsacin del acelerador debera provocar que un motor fuera ms rpido, lo contrario cuando soltamos el acelerador. Puede emplearse cualquier mecanismo siempre y cuando produzca el efecto deseado, y que mecanismo se selecciona es una opcin de diseo. Podramos contar con los siguientes diseos: Una conexin mecnica desde el acelerador hasta el carburador, una conexi n electrnica desde el sensor de presin bajo el acelerador hasta una computadora que controla el carburador. El mecanismo que elige un desarrollador entre un conjunto de alternativas es frecuentemente el resultado de factores como costo, fiabilidad, facilidad, seguridad. Las abstracciones clave reflejan el vocabulario del comino del problema, los mecanismos son el alma del diseo. Durante el proceso de diseo el desarrollador debe considerar no solo el diseo de clases individuales, sino tambin cmo trabajan juntas las instancias de esas clases. Una vez que un desarrollador decide sobre un patrn concreto de colaboracin, se distribuye el trabajo entre muchos objetos definiendo mtodos convenientes en las clases apropiadas. EL protocolo de una clase individual abarca todas las operaciones que se requieren para implantar todo el comportamiento y todos los mecanismos asociados con una de sus instancias. Los mecanismos representan as decisiones de diseo estratgicas, como el diseo de una estructura de cla ses. Los mecanismos son realmente uno de entre la variedad de patrones que se encuentran en los sistemas de software bien estructurados. En el limite inferior de la cadena de alimentacin, estn los modismos. Un modismo es una expresin peculiar de algn lenguaje de programacin o cultura de aplicaciones, que representa una convencin generalmente aceptada para el uso del lenguaje. Un marco de referencia es una coleccin de clases que ofrecen un conjunto de servicios para un dominio particular; un marco de referencia exporta as una serie de clases y mecanismos individuales que los clientes pueden utilizar o adoptar. 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 comporta por el hecho de que un conjunto dado de objetos puede clasificarse de muchas formas igualmente c orrectas. 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 anlisis orientado a objetos, y puede utilizarse para guiar los procesos de anlisis clsico, anlisis del comportamiento y anlisis de dominios. Las abstracciones clave reflejan el vocabulario del domino del problema y p ueden 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.

18