Análisis y Diseño Orientado A Objetos - Grady Booch

Anlisis y Diseo Orientado a Objetos Grady Booch
Anlisis y Diseo Orientado a Objetos

Grady Booch
CAPITULO 1 COMPLEJIDAD CAPITULO 2 EL MODELO DE OBJETOS CAPITULO 3 CLASES Y OBJETOS CAPITULO 4 - CLASIFICACIN
Pg. 1/38
INDICE
.................................................................................................................... ......................1 CAPITULO 1 COMPLEJIDAD....................................................................................... ..1 CAPITULO 2 EL MODELO DE OBJETOS................................................................. .....1 CAPITULO 3 CLASES Y OBJETOS ............................................................... ...............1 CAPITULO 4 - CLASIFICACIN......................................................... ..............................1 INDICE........................................................................................................ .......................2
1.1 La complejidad inherente al software..................................................................................................... .....................5 Software de dimensin industrial.....................................................................................................................................5 El software es complejo de forma innata. Es una caracterstica esencial de l................................................................5 La complejidad del dominio del problema...................................................................................................................5 La dificultad de gestionar el proceso de desarrollo......................................................................................................5 La flexibilidad que se puede alcanzar a travs del software........................................................................................6 Los problemas que plantea la caracterizacin del comportamiento de sistemas discretos..........................................6 Las consecuencias de la complejidad ilimitada................................................................................................................6 1.2 La estructura de los sistemas complejos.......................................................................................................................... 6 Ejemplos de sistemas complejos......................................................................................................................................6 Los cinco atributos de un sistema complejo.....................................................................................................................6 Complejidad organizada y desorganizada........................................................................................................................7 La forma cannica de un sistema complejo.................................................................................................................7 1.3 - Imponiendo orden al caos.......................................................................................................................... .....................7 El rol de la descomposicin..............................................................................................................................................7 Categoras de mtodos de diseo.....................................................................................................................................8 El rol de la abstraccin.....................................................................................................................................................8 El rol de la jerarqua.........................................................................................................................................................8 1.4 - Del diseo de sistemas complejos....................................................................................................................... ............9 El significado del diseo..................................................................................................................................................9 La importancia de construir un modelo............................................................................................................................9 RESUMEN CAPITULO 1.......................................................................................................................................... ........10
CAPTULO 2 EL MODELO DE OBJETOS....................................................... .............11

2.1 - La evolucin del modelo de objetos......................................................................................................... ....................11 Tendencias en ingeniera de software.............................................................................................................................11 Las generaciones de lenguajes de programacin........................................................................................................11 Topologa de los lenguajes de primera y principios de la segunda generacin..............................................................11 Topologa de los lenguajes de fines de la segunda y principios de la tercera generacin..............................................11 Topologa de los lenguajes de finales de la tercera generacin......................................................................................12 Topologa de los lenguajes basados en objetos y orientados a objetos..........................................................................12 Fundamentos del modelo de objetos..............................................................................................................................12 Programacin orientada a objetos..................................................................................................................................12
Pg. 2/38

Diseo orientado a objetos.............................................................................................................................................13 Anlisis orientado a objetos............................................................................................................................................13 2.2 - Elementos del modelo de objetos............................................................................................................ .....................13 Tipos de paradigmas de programacin...........................................................................................................................13 Abstraccin.....................................................................................................................................................................14 Encapsulamiento.............................................................................................................................................................15 El significado del encapsulamiento............................................................................................................................15 Modularidad...................................................................................................................................................................15 El significado de la modularidad................................................................................................................................15 Jerarqua.........................................................................................................................................................................16 El significado de la jerarqua......................................................................................................................................16 Tipos. Tipificacin..........................................................................................................................................................17 El significado de los tipos...........................................................................................................................................17 Beneficios del uso de tipos estrictos:..........................................................................................................................17 Ligadura esttica y dinmica......................................................................................................................................18 El significado de la concurrencia...............................................................................................................................18 El significado de la persistencia.................................................................................................................................18 2.3 - Aplicacin del modelo de objetos................................................................................................................. ................19 Beneficios del modelo de objetos...................................................................................................................................19 RESUMEN CAPITULO 2.......................................................................................................................................... ........20
CAPTULO 3 CLASES Y OBJETOS............................................................. ................21

3.1 - La naturaleza de los objetos................................................................................................................. ........................21 Qu es y qu no es un objeto..........................................................................................................................................21 Semntica...................................................................................................................................................................21 El significado del comportamiento.............................................................................................................................22 Roles y responsabilidades...............................................................................................................................................22 Los objetos como mquinas...........................................................................................................................................22 Identidad.........................................................................................................................................................................23 Copia, asignacin e igualdad..........................................................................................................................................23 Espacio de vida de un objeto..........................................................................................................................................23 3.2 - Relaciones entre objetos............................................................................................................................. ...................23 Tipos de relaciones.........................................................................................................................................................23 3.3 - La naturaleza de una clase..................................................................................................................................... .......25 Qu es y qu no es una clase..........................................................................................................................................25 Interfaz e implementacin..............................................................................................................................................25 Ciclo de vida de las clases..............................................................................................................................................25 3.4 - Relaciones entre clases........................................................................................................................................... ........25 Tipos de relaciones.........................................................................................................................................................25 Polimorfismo simple......................................................................................................................................................27 Herencia mltiple...........................................................................................................................................................27 Agregacin.....................................................................................................................................................................27 Contencin fsica............................................................................................................................................................27 Instanciacin...................................................................................................................................................................28 Metaclases......................................................................................................................................................................28 3.5 - La interaccin entre clases y objetos............................................................................................................. ..............28 Relaciones entre clases y objetos...................................................................................................................................28 El papel de clases y objetos en anlisis y diseo............................................................................................................28 3.6 - De la construccin de clases y objetos de calidad.............................................................................................. ........29
Pg. 3/38

Medida de la calidad de una abstraccin........................................................................................................................29 Seleccin de operaciones................................................................................................................................................30 Semntica funcional...................................................................................................................................................30 Semntica espacial y temporal...................................................................................................................................30 Eleccin de relaciones....................................................................................................................................................31 Colaboraciones...........................................................................................................................................................31 Mecanismos y visibilidad...........................................................................................................................................31 Eleccin de implementaciones.......................................................................................................................................31 Representacin...........................................................................................................................................................31 RESUMEN CAPITULO 3.......................................................................................................................................... ........32
CAPTULO 4 CLASIFICACIN................................................................................ .....33

4.1 La importancia de una clasificacin correcta....................................................................................... .......................33 Clasificacin y diseo orientado a objetos.....................................................................................................................33 La dificultad de la clasificacin......................................................................................................................................33 Ejemplos de clasificacin...........................................................................................................................................33 La naturaleza incremental e iterativa de la clasificacin............................................................................................33 4.2 Identificando clases y objetos..................................................................................................................................... .....34 Enfoques clsicos y modernos........................................................................................................................................34 Categorizacin clsica................................................................................................................................................34 Agrupamiento conceptual...........................................................................................................................................34 Teora de los prototipos..............................................................................................................................................34 Aplicacin de las teoras clsicas y modernas............................................................................................................34 Anlisis Orientado a Objetos..........................................................................................................................................34 Enfoques clsicos.......................................................................................................................................................35 Anlisis del comportamiento......................................................................................................................................35 Anlisis de dominios..................................................................................................................................................35 Anlisis de Casos de Uso...........................................................................................................................................36 Fichas CRC.................................................................................................................................................................36 Descripcin informal en espaol................................................................................................................................36 Anlisis Estructurado..................................................................................................................................................36 4.3 Abstracciones y mecanismos clave.................................................................................................................. ...............36 Identificacin de las abstracciones clave........................................................................................................................36 Bsqueda de las abstracciones clave..........................................................................................................................36 Refinamiento de abstracciones clave..........................................................................................................................37 Identificacin de mecanismos........................................................................................................................................37 Bsqueda de mecanismos...........................................................................................................................................37 Ejemplos de mecanismos...........................................................................................................................................37
Pg. 4/38
Captulo 1 - Complejidad 1.1 La complejidad inherente al software

Software de dimensin industrial.
Aplicaciones con un ciclo de vida muy largo y de los cuales muchos usuarios a lo largo del tiempo llegan a depender de su funcionamiento correcto. Su complejidad excede la capacidad intelectual del ser humano, por lo que resulta imposible ser comprendido en su totalidad por un nico desarrollador. Y esto es caracterstica esencial de casi todos los sistemas de software de gran tamao.
El software es complejo de forma innata. Es una caracterstica esencial de l.

Es complejo porque hereda la complejidad del dominio del problema, la dificultad de gestionar el proceso de desarrollo, la flexibilidad que se puede alcanzar a travs del software y los problemas que plantea la caracterizacin del comportamiento de sistemas discretos.
La complejidad del dominio del problema 1. El problema a resolver presenta muchos requisitos que compiten entre s o se contradicen (cuando se compite entre facilidad de uso o costo con la facilidad de desarrollo o su funcionalidad)
2. Esas contradicciones o desacoplamientos existen debido a que los usuarios suelen encontrar grandes dificultades para expresar sus necesidades en una forma en que los desarrolladores puedan entender. Los usuarios tal vez solo tiene vagas ideas de lo que quieren del sistema. 3. Los requisitos adems cambian con frecuencia durante el desarrollo incluso porque la mera existencia de un proyecto de solucin lo altera al sistema real. 4. Un sistema grande, debido a la inversin financiera que implica, no puede desecharse y reemplazarse por uno nuevo cada vez que los requisitos cambian. Debe evolucionar. Evolucionar del software: responder al cambio de requerimientos Mantenimiento del software: corregir errores Conservacin del software: emplear recursos para mantener en operacin un elemento de software anticuado y decadente.
La dificultad de gestionar el proceso de desarrollo 5. La principal tarea del grupo de desarrollo es dar una ilusin de simplicidad para defender a los usuarios de esta complejidad arbitraria del problema. 6. Se hace lo posible por escribir menos cdigo pero a veces es imposible eludir el tamao de un sistema grande. Debe recurrirse a la aplicacin de varias tcnicas de re-utilizacin de cdigo existente o de la escritura de nuevo software. 7. Debe tambin enfrentarse la existencia de miles de mdulos separados y esto implica un grupo de desarrolladores, nunca una nica persona. Esto implica ms personas y por consiguiente una comunicacin ms rigurosa y coordinacin ms difcil, ms an si el grupo y el proyecto se extienden geogrficamente.
Pg. 5/38
La flexibilidad que se puede alcanzar a travs del software 8. Un proyecto de software es muy frecuentemente apoyado en pilares construidos por los mismos desarrolladores (a diferencia de una obra edilicia, por ejemplo, que no contiene un acera para fabricar sus propias vigas metlicas). Esto significa que el desarrollo del proyecto de software sigue siendo una tarea muy laboriosa. No hay estndares para el desarrollo de software.
Los problemas que plantea la caracterizacin del comportamiento de sistemas discretos. 9. El estado actual de una aplicacin est dado por el conjunto de variables (que pueden ser miles), de sus valores actuales y de la direccin de ejecucin y de la pila de cada proceso del sistema.
10. En sistemas continuos una pequea modificacin en la entrada provoca una pequea modificacin en la salida. Pero en sistemas discretos y de gran tamao se percibe una explosin combinatoria que hace que la salida se modifique enormemente. 11. Se intenta disear los sistemas con una separacin de intereses: de forma que el comportamiento de una parte del sistema tenga el mnimo impacto en el comportamiento de otra parte del sistema. 12. En un sistema de gran volumen debe uno contentarse con un grado de confianza determinado a lo que refiere su correccin ya que no puede llevarse a cabo una prueba a fondo exhaustiva por no tener las herramientas matemticas ni intelectuales para un sistema no continuo.
Las consecuencias de la complejidad ilimitada.

Ms complejo es el sistema, ms abierto est al derrumbamiento total. Crisis del software: ha existido tanto tiempo que debe considerarse normal. Es cuando se pretende dominar la complejidad del sistema a un extremo que lleva al presupuesto a niveles excedentes y que transforman en deficiente al sistema respecto a los requerimientos fijados.
1.2 La estructura de los sistemas complejos.

Ejemplos de sistemas complejos.
Computador personal: complejidad moderada. Casi todos los computadores estn formados por los mismos elementos bsicos. Los sistemas complejos no slo son jerrquicos, sino que los niveles de esta jerarqua representan diferentes niveles de abstraccin. A cada nivel de abstraccin se encuentra una serie de dispositivos que colaboran para proporcionar servicios a capas ms altas. Se elige determinado nivel de abstraccin para satisfacer necesidades particulares. Slo a travs de la cooperacin mutua de colecciones significativas de estos agentes se ve la funcionalidad de nivel superior de una planta. la ciencia de la complejidad llama a esto comportamiento emergente. El comportamiento del todo es mayor que la suma de sus partes.
Los cinco atributos de un sistema complejo.

1. La complejidad toma la forma de una jerarqua, por lo cual un sistema complejo est compuesto de subsistemas relacionados que tiene a su vez sus propios subsistemas, y as sucesivamente, hasta que se alcanza algn nfimo nivel de componentes elementales.
Pg. 6/38

El hecho de tener una estructura jerrquica y casi descomponible es lo que facilita la comprensin del sistema complejo. En realidad slo se puede comprender a los sistemas que tiene una estructura de jerarqua. 2. La eleccin de qu componentes de un sistema son primitivos es relativamente arbitraria y queda en gran medida a decisin del observador. 3. Los enlaces internos de los componentes suelen ser ms fuertes que los enlaces entre los componentes. Este hecho tiene el efecto de separar la dinmica de alta frecuencia de los componentes que involucra a la estructura interna de los mismos de la dinmica de baja frecuencia que involucra la interaccin entre los componentes. Esto posibilita un estudio de cada parte de forma relativamente aislada. 4. Los sistemas jerrquicos estn compuestos usualmente de slo unas pocas clases diferentes de subsistemas dispuestos en varias combinaciones y disposiciones. Esto lleva a la reutilizacin de componentes pequeos. Se encontrar siempre que 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. Hay que volver a empezar, partiendo de un sistema simple que funcione.
5.
Complejidad organizada y desorganizada.

La forma cannica de un sistema complejo. El descubrimiento de abstracciones y mecanismos comunes facilita la comprensin del sistema complejo. A un sistema se lo puede descomponer en una jerarqua estructural o parte-de o en una jerarqua de tipos o es-un. Es esencial ver a un sistema desde ambas perspectivas. A estas jerarquas se las llaman respectivamente estructura de clases y estructura de objetos. Por lo general, existen muchos ms objetos que clases en un sistema. Al tener en cuenta la estructura de clases, se capturan las propiedades de determinados objetos en un slo lugar, posibilitando as una mejor comprensin. Una nueva mirada a cada nivel de estructura de objetos expone un nuevo nivel de complejidad. Ambas estructuras no son del todo independientes y juntas conforman la arquitectura del sistema.
1.3 - Imponiendo orden al caos.

El rol de la descomposicin.
Para estudiar y trabajar con sistemas complejos es muy til e imperioso dividirlo en partes ms y ms pequeas para as poder refinarlas en forma independiente. Divide y vencers. As se satisface la restriccin fundamental de la capacidad humana: para entender un nivel dado basta con comprender unas pocas partes (no necesariamente todas) a la vez.
Descomposicin algortmica: cada mdulo del sistema representa un paso importante de un

proceso global. Se siguen las reglas del diseo estructurado y descendente. Esta visin enfatiza el orden de los eventos.
Descomposicin orientada a objetos:
se identifican los objetos que se derivan directamente del vocabulario del dominio del problema. Son agentes autnomos que colaboran para llevar acabo algn comportamiento de nivel superior. Un objeto aqu es una entidad tangible que muestra un comportamiento bien definido. Esta visin resalta a los objetos que provocan acciones o son sujetos de estas acciones.
Pg. 7/38

Ambas visiones son importantes, pero no se puede disear un sistema complejo con las dos visiones al mismo tiempo, ya que son vistas perpendiculares. Hay que comenzar a descomponer un sistema por algoritmos o por objetos y luego utilizar la estructura resultante como marco de referencia para expresar la otra perspectiva.
Categoras de mtodos de diseo.

Mtodo es un proceso disciplinado para generar un conjunto de modelos que describen varios aspectos de un sistema de software en desarrollo, utilizando alguna notacin bien definida. Metodologa es una coleccin de mtodos aplicados a lo largo del ciclo de vida del desarrollo del software y unificados por alguna aproximacin general o filosfica. Los mtodos son importantes porque introducen una disciplina en el desarrollo de sistemas de software complejos. Definen los productos que sirven como vehculo comn para la comunicacin entre miembros de un equipo de desarrollo.
Diseo estructurado descendente o diseo compuesto:
(representado en lenguajes como FORTRAN y COBOL) se aplica descomposicin algortmica para fragmentar un problema grande en pasos pequeos. La unidad fundamental es el subprograma.
Diseo dirigido por los datos: con este diseo, la estructura de un sistema de software se
deduce de la correspondencia entre las entradas y las salidas del sistema.
Diseo orientado a objetos: se modelo los sistemas de software como colecciones de objetos
que cooperan, tratando los objetos individuales como instancias de una clase que est adentro de una jerarqua de clases. Lenguajes que reflejan esta topologa son Smalltalk, Object Pascal, C++, Common Lisp Object System (CLOS) y Ada. La descomposicin orientada a objetos produce sistemas ms pequeos a travs de la reutilizacin de mecanismos comunes, proporcionando una til economa de expresin. Los sistemas orientados a objetos son ms resistentes al cambio por lo que estn mejor preparados para evolucionar a travs del tiempo, porque est basado en formas intermedias estables (abstracciones y mecanismos ya probados). Est diseado para evolucionar de forma incremental, partiendo de sistemas ms pequeos en los que ya se tiene confianza.
El rol de la abstraccin.
Es una tcnica muy potente para enfrentarse a la complejidad. Al ser incapaces de dominar en su totalidad a un objeto complejo, ignoramos entonces sus detalles no esenciales, tratando en su lugar con el modelo generalizado e idealizado del objeto.
El rol de la jerarqua.
Reconocer jerarquas de clases y objetos es otra forma de incrementar el contenido semntico de bloques de informacin. la estructura de objetos es importante porque nos muestra como los objetos colaboran entre s a travs de diferentes mecanismos, mientras que la estructura de clases resalta la estructura y comportamiento comunes en el interior del sistema. La identificacin de jerarquas en un sistema complejo no es fcil ya que requiere que se descubran patrones entre muchos objetos, cada uno de los cuales puede incluir comportamientos muy complicados.
Pg. 8/38

Puede hacerse frente a las restricciones de la cognicin humana mediante el uso de la descomposicin, la abstraccin y la jerarqua.
1.4 - Del diseo de sistemas complejos.

El significado del diseo.
Es la aproximacin disciplinada que se utiliza para inventar una solucin para algn problema, suministrando as un camino desde los requerimientos hasta la implantacin. Construir un sistema que: satisfaga determinada condicin funcional se ajuste a las limitaciones impuestas por el medio de destino respete requisitos implcitos o explcitos sobre el rendimiento y reutilizacin de recursos satisfaga criterios de diseo implcitos o explcitos sobre la forma del artefacto satisfaga restricciones sobre el propio proceso de diseo, tales como su longitud o coste, o las herramientas disponibles para realizar el diseo "Crear una estructura interna (o arquitectura) clara y relativamente simple" "Es un balance entre un conjunto de requisitos que compiten" "Los productos del diseo son modelos que permiten razonar sobre las estructuras, hacer concesiones cuando los requisitos entran en conflicto y, en general, proporcionar un anteproyecto para la implementacin.
La importancia de construir un modelo.

Cada modelo dentro de un diseo describe un aspecto especfico del sistema que se est considerando. Generalmente, se busca construir nuevos modelos basados en modelos viejos en los que ya se confa. Los modelos dan la oportunidad de fallar en condiciones controladas, bajo situaciones tanto previstas como improbables para modificarlo para que se comporte del modo esperado o deseado. Los elementos de los mtodos de diseo del software. 1. 2. 3. Notacin Proceso sistema. El lenguaje para expresar cada modelo Las actividades que encaminan a la construccin ordenada de los modelos del
Herramientas Los artefactos que eliminan el tedio de construir el modelo y reafirman las reglas sobre los propios modelos, de forma que sea posible revelar errores e inconsistencias.
Los modelos del desarrollo orientado a objetos. El diseo orientado a objetos es el mtodo que lleva a una descomposicin orientada a objetos. Aplicando diseo orientado a objetos se crea software resistente al cambio (mejor evolucin) y escrito con economa de expresin.

Modelo lgico Modelo fsico Modelo esttico Modelo dinmico

Pg. 9/38
RESUMEN CAPITULO 1
El software es complejo de forma innata; la complejidad de los sistemas de software excede frecuentemente la capacidad intelectual humana. La tarea del equipo de desarrollo de software es la de crear una ilusin de sencillez. La complejidad toma a menudo la forma de una jerarqua; esto es til para modelar tanto las jerarquas es-un como parte de de un sistema complejo. Los sistemas complejos evolucionan generalmente de formas intermedias estables. Existen factores de limitacin fundamentales en la cognicin humana; puede hacerse frente a estas restricciones mediante el uso de la descomposicin, abstraccin y jerarqua. Los sistemas complejos pueden verse centrando la atencin bien en las cosas o bien en los procesos; hay razones de peso para aplicar la descomposicin orientada a objetos, en la cual se ve el mundo como una coleccin significativa de objetos que colaboran para conseguir algn comportamiento de nivel superior. El diseo orientado a objetos es el mtodo que conduce a una descomposicin orientada a objetos; el diseo orientado a objetos define una notacin y un proceso para construir sistemas de software complejos, y ofrece un rico conjunto de modelos lgicos y fsicos con los cuales se puede razonar sobre diferentes aspectos del sistema que se esta considerando.
Pg. 10/38
Captulo 2 El modelo de objetos

El modelo de objetos es el conjunto de slidos fundamentos de ingeniera para la tecnologa orientada a objetos. Este modelo abarca los principios de abstraccin, encapsulacin, modularidad, jerarqua, tipos, concurrencia y persistencia. Los conceptos no son nuevos pero el modelo los integra de forma sinrgica. Por desgracia la programacin orientada a objetos significa cosas distintas para personas distintas.
2.1 - La evolucin del modelo de objetos.

Tendencias en ingeniera de software.
Las generaciones de lenguajes de programacin. Desplazamiento de programacin al por menor a la programacin al por mayor. La evolucin de los lenguajes de alto nivel.
La tendencia ha demostrado un desplazamiento de los lenguajes imperativos hacia los lenguajes declarativos. Lenguajes imperativos: le dicen a la computadora qu hacer. Lenguajes declarativos: describen las abstracciones claves del dominio del problema.
Primera generacin: represent un paso de acercamiento al problema y un paso de alejamiento

de la mquina que haba debajo al poder escribir el vocabulario casi totalmente matemtico y cientfico directamente con frmulas (sin complicaciones de lenguaje de mquina).
Segunda generacin: se enfatiz las abstracciones algortmicas. Lo principal ahora era decirle a
la mquina lo que deba hacer.
Tercera generacin: se requirieron ms tipos de datos. Se empez a soportar la abstraccin de

datos. A partir de los aos setenta se crearon ms de dos millares de lenguajes de programacin de los cuales pocos sobrevivieron.
Topologa de los lenguajes de primera y principios de la segunda generacin.

1. 2. El bloque principal de construccin de programas de esta poca era el subprograma o prrafo. Estructura fsica relativamente plana, consistente solo en datos globales y subprogramas. Dependencia de cada uno de los subprogramas a los datos globales. Un error en una parte de estos programas puede tener un devastador efecto de propagacin (debido a que las estructuras de datos globales estn expuestas a todos los subprogramas). Difcil mantener la integridad del diseo original en un sistema grande. La entropa es fcil de encontrar. Enorme cantidad de acoplamientos entre subprogramas y flujo de control retorcidos, amenazando la fiabilidad y claridad de la solucin del sistema.
3. 4.
Topologa de los lenguajes de fines de la segunda y principios de la tercera generacin.

Incorporacin del concepto de abstraccin procedimental con tres consecuencias:
Pg. 11/38

1. 2. 3. mecanismos de pasaje de parmetros, se asentaron los fundamentos de la programacin estructurada y surgieron los mtodos de diseo estructurado (con subprogramas como bloques fsicos bsicos para la construccin).
Topologa de los lenguajes de finales de la tercera generacin.

Se incorpor la idea del mdulo compilado separadamente para trabajar en equipos de desarrollo grande y dividir las tareas, pero que carecan de reglas que exigiesen una consistencia semntica entre los diferentes mdulos escritos.
Topologa de los lenguajes basados en objetos y orientados a objetos.

1. Surgieron primero los mtodos de diseo dirigido por los datos, que proporcionaron una aproximacin disciplinada al hecho de realizar abstracciones de datos en lenguajes orientados algortmicamente. Aparecieron teoras acerca del concepto de tipo.
2.
Estos dos conceptos fueron mejorando poco a poco a travs de los millares de lenguajes que perecieron y culminaron representndose en lenguajes como Smalltalk, Object Pascal, C++, CLOS, Ada y Eiffel. Estos lenguajes son basados en objetos y orientados a objetos. El bloque bsico de construccin de este tipo de lenguajes es el mdulo (que representa una coleccin lgica de clases y objetos en lugar de subprogramas).
Fundamentos del modelo de objetos.

Las clases y objetos son los bloques bsicos de construccin en este modelo. El modelo de objetos result ser un concepto unificador de la informtica, al aplicrsele a las interfaces de usuario, bases de datos y arquitecturas de computadores. Todo esto debido a los primeros puntos citados del primer captulo: la orientacin a objetos ayuda a combatir la complejidad inherente a muchos tipos de sistemas Un objeto slo puede cambiar de estado, actuar, ser manipulado o permanecer en relacin con otros objetos de maneras apropiadas. Existen propiedades invariantes que caracterizan a un objeto y su comportamiento.
Programacin orientada a objetos.

Es un mtodo de implementacin 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. Si falta cualquiera de estos elementos, el programa no es orientado a objetos. La programacin sin herencia es explcitamente no orientada a objetos, se denomina programacin con tipos abstractos de datos. Un lenguaje es orientado a objetos si y slo si:
Pg. 12/38

1. soporta objetos que son abstracciones de datos con un interfaz de operaciones con nombre y un estado local oculto 2. los objetos tiene un tipo asociado (clase) 3. los tipos (clase) pueden heredar atributos de los supertipos (superclases). Para un lenguaje soportar la herencia significa que es posible expresar relaciones es un entre tipos. Basado en objeto es un lenguaje que no ofrece soporte directo para la herencia.
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. El soporte para la descomposicin orientada a objetos diferencia a este tipo de diseo del estructurado ya que permite diagramar lgicamente el sistema haciendo uso de abstracciones de clases y objetos.
Anlisis orientado a objetos.

Enfatiza la construccin de modelos del mundo real, utilizando una visin orientada a objetos. Es un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. Los productos del AOO sirven como modelos de los que se puede partir para un DOO. Los productos del DOO puede utilizarse como anteproyectos para la implementacin completa de un sistema utilizando mtodos de POO.
2.2 - Elementos del modelo de objetos.

Tipos de paradigmas de programacin.
Estilo de programacin: una forma de organizar programas sobre las bases de algn modelo conceptual de programacin y un lenguaje apropiado para que resulten claros los programas escritos en ese estilo.
Estilo de programacin Orientado a procedimientos Orientado a objetos Orientado a lgica Orientado a reglas Orientados a restricciones
Abstraccin que se usa Algoritmos Clases y objetos Objetivos, expresados como clculo de predicados Reglas si-entonces Relaciones invariantes
Hay cuatro elementos fundamentales del modelo de objetos (si alguno de ellos falta el modelo no es orientado a objetos): Abstraccin Encapsulamiento Modularidad Jerarqua
Pg. 13/38
Hay tres elementos secundarios: Tipos (tipificacin) Concurrencia Persistencia
Abstraccin.
Surge del reconocimiento de las similitudes entre ciertos objetos, situaciones o procesos del mundo real, y la decisin de concentrarse en esas similitudes e ignorar por el momento las diferencias. Una abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objeto y proporciona as fronteras conceptuales ntidamente definidas respecto a la perspectiva del observador. Una abstraccin se centra en la visin externa del objeto y por tanto sirve para separar el comportamiento esencial de un objeto de su implantacin (= barrera de abstraccin). Abstraccin de entidades Abstraccin de acciones Un objeto representa un modelo til de una entidad del dominio del problema o del dominio de la solucin. Un objeto que proporciona un conjunto generalizado de operaciones y todas ellas desempean funciones del mismo tipo. Un objeto que agrupa operaciones, todas ellas virtuales utilizadas por algn nivel superior o control, u operaciones que utilizan todas algn conjunto de operaciones de nivel inferior.
Abstraccin de mquinas virtuales
Abstraccin de coincidencia
Un objeto que almacena un conjunto de operaciones que no tiene relacin entre s.
Un cliente es cualquier objeto que utiliza los recursos de otro objeto (denominado servidor). Se puede caracterizar el comportamiento de un objeto considerando los servicios que presta a otros objetos. Al conjunto completo de operaciones que puede realizar un cliente sobre un objeto, junto con las formas de invocacin u rdenes que admite, se le denomina protocolo. Un invariante es una condicin booleana cuyo valor de verdad debe mantenerse. Precondiciones: invariantes asumidos por la operacin Postcondiciones: invariantes satisfechos por la operacin. Si se viola una precondicin significa que un cliente no ha satisfecho su parte del convenio, y por tanto el servidor no puede proceder con fiabilidad. Si se viola una postcondicin significa que un servidor no ha llevado a cabo su parte del contrato, y por tanto sus clientes ya no pueden seguir confiando en el comportamiento del servidor.
Pg. 14/38

Una excepcin es una indicacin de que no se ha satisfecho algn invariante. Todas las abstracciones tiene propiedades tanto estticas como dinmicas. Objeto: archivo en un disco. Propiedades: ESTTICAS nombre, tamao, contenido. Valores de las propiedades: DINMICOS su nombre, su tamao y su contenido pueden cambiar.
Encapsulamiento.
El significado del encapsulamiento. Ninguna parte de un sistema complejo debe depender de los detalles internos de otras partes. Mientras la abstraccin ayuda a las personas a pensar sobre lo que estn haciendo, el encapsulamiento permite que los cambios hechos en los programas sean fiables con el menor esfuerzo. El encapsulamiento se consigue a menudo mediante la ocultacin de informacin, la estructura de un objeto est oculta as como la implantacin de sus mtodos. Para que la abstraccin funcione, la implementacin debe estar encapsulada En la prctica cada clase debe tener dos partes: un interfaz y una implementacin. Interfaz: captura slo su vista externa, abarcando la abstraccin que se ha hecho del comportamiento comn de todas las instancias de esa clase. Implementacin: (o implantacin) comprende la representacin de la abstraccin as como los mecanismos que consiguen el comportamiento deseado. El encapsulamiento es el proceso de almacenar en un mismo compartimento los elementos de una abstraccin que constituyen su estructura y su comportamiento; sirve para separar el interfaz contractual de una abstraccin y su implementacin. Esos elementos encapsulados se llaman secretos de una abstraccin. La ocultacin es un concepto relativo: lo que est oculto a un nivel de abstraccin puede representar la visin externa a otro nivel de abstraccin.
Modularidad.
El significado de la modularidad. El acto de fragmentar un programa en componentes individuales puede reducir su complejidad en algn grado. Esto es una razn til, pero ms poderosa es la justificacin de que la fragmentacin crea una serie de fronteras bien definidas y documentadas dentro del programa. El uso de mdulos es esencial para ayudar a manejar la complejidad. La modularizacin consiste en dividir un programa en mdulos que pueden compilarse separadamente, pero que tienen conexiones con otros mdulos. Las conexiones entre mdulos son las suposiciones que cada mdulo hace acerca de todos los dems. La decisin sobre el conjunto adecuado de mdulos para determinado problema es casi tan difcil como decidir sobre el conjunto adecuado de abstracciones. 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
Pg. 15/38

problema presenta diferencias sutiles, la tarea es decidir dnde empaquetar fsicamente las clases y objetos a partir de la estructura lgica del diseo, y stos son claramente diferentes de los subprogramas. El objetivo de fondo de la descomposicin en mdulos es la reduccin del coste del software al permitir que los mdulos se diseen y revisen independientemente. La estructura de cada mdulo debera ser lo bastante simple como para ser comprendida en su totalidad. 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. Hay que hacer lo posible por construir mdulos cohesivos (agrupando abstracciones que guarden cierta relacin lgica) y dbilmente acoplados (minimizando las dependencias entre mdulos). La modularidad es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados.
Jerarqua.
El significado de la jerarqua. La abstraccin es algo bueno, pero excepto en las aplicaciones ms triviales, puede haber muchas ms abstracciones diferentes de las que se pueden comprender simultneamente. El encapsulamiento ayuda a manejar esta complejidad ocultando la visin interna de las abstracciones. La modularidad tambin ayuda, ofreciendo una va para agrupar abstracciones relacionadas lgicamente. La jerarqua es una ordenacin o clasificacin de abstracciones. Las dos jerarquas ms importantes en un sistema complejo son su estructura de clases (la jerarqua de clases) y su estructura de objetos (la jerarqua de partes). La herencia es la jerarqua de clases ms importante (elemento esencial en los sistemas orientados a objetos). Bsicamente la herencia define una relacin entre clases, en la que una clase comparte la estructura de comportamiento definida en una o ms clases (lo denominado herencia simple o mltiple). Una subclase hereda de una o ms superclases. Tpicamente una subclase aumenta o redefine la estructura y el comportamiento de sus superclases. Semnticamente la herencia denota una relacin de tipo es un. A medida que se desarrolla una jerarqua de herencias, la estructura y comportamiento comunes a diferentes clases tender a migrar hacia superclases comunes. Herencia = jerarqua de generalizacin / especializacin. Las superclases representan abstracciones generalizadas Las subclases representan especializaciones en la que los campos y mtodos de las superclases sufren adiciones, modificaciones o incluso ocultaciones. De este modo la herencia permite declarar las abstracciones con economa de expresin. Sin herencia cada clase sera una unidad independiente, desarrollada partiendo de cero.
Pg. 16/38

La herencia posibilita la definicin de nuevo software de la misma forma que se presenta un nuevo concepto a un recin llegado, comparndolo con lago que ya le resulte familiar. La abstraccin de datos intenta proporcionar una barrera opaca tras de la cual se ocultan los mtodos y el estado; la herencia requiere abrir ese interfaz en cierto grado y puede permitir el acceso a mtodos y al estado sin abstraccin Para la herencia mltiple primero se idean clases que capturen independientemente las propiedades buscadas (se las llama clases aditivas) y luego se las une en una subclase. Hay problemas de colisin de nombres y herencia repetida. Jerarqua de agregacin: son relaciones parte de. Esto permite hablar de niveles de abstraccin. Niveles ms altos o ms bajos para indicar la dependencia de una clase a otra. Una clase est a nivel ms alto de abstraccin que cualquiera de las clases que constituyen su implantacin. La combinacin de herencia con agregacin es muy potente. La agregacin permite el agrupamiento fsico de estructuras relacionadas lgicamente, y la herencia permite que estos grupos de aparicin frecuente se reutilicen con facilidad en diferentes abstracciones.
Tipos. Tipificacin.
El significado de los tipos. Un tipo es una caracterizacin precisa de las propiedades estructurales o de comportamiento que comparten una serie de entidades. (Las clases implementan a los tipos) No son exactamente lo mismo. Los tipos son la puesta en vigor de la clase de los objetos, de modo que los objetos de tipos distintos no pueden intercambiarse o, como mucho, pueden intercambiarse slo de formas muy restringidas. Un lenguaje de programacin determinado puede tener comprobacin estricta de tipos, comprobacin dbil de tipos, o incluso no tener tipos, y an as ser considerado como orientado a objetos. Comprobacin estricta de tipos: no puede llamarse a una operacin sobre un objeto a menos que en la clase o superclases del objeto est definido el prototipo de esa operacin. Todas las expresiones son consistentes respecto al tipo. En lenguajes con comprobacin estricta de tipos puede detectarse en tiempo de compilacin cualquier violacin a la concordancia de tipos. Comprobacin dbil de tipos: hacer cumplir la clase de un objeto, lo que previene el intercambio de objetos de diferentes tipos o, como mucho, permite este intercambio de maneras muy limitadas.
Beneficios del uso de tipos estrictos: sin la comprobacin de tipos un programa puede estallar de forma misteriosa en ejecucin en la mayora de los lenguajes. en la mayora de los sistemas, el ciclo editar-compilar-depurar es tan tedioso que la comprobacin temprana de errores es indispensable. la declaracin de tipos ayuda a documentar los programas. la mayora de los compiladores pueden generar un cdigo ms eficiente si se han declarado tipos.
Pg. 17/38
Ligadura esttica y dinmica. a. b. Ligadura esttica o temprana: significa que se fijan los tipos de todas las variables y expresiones en tiempo de compilacin; Ligadura dinmica o tarda: los tipos de las variables y expresiones no se conocen hasta el tiempo de ejecucin.
Polimorfismo: representa un concepto de teora de tipos, en el que un solo nombre (tal como una
declaracin de variable) puede denotar objetos de muchas clases diferentes que se relacionan por alguna superclase comn de operaciones. El opuesto del polimorfismo es el monomorfismo.
Concurrencia.
El significado de la concurrencia. Hilo de control: un solo proceso. Es comn tener que manejar muchos eventos diferentes simultneamente. Un solo proceso es la raz a partir de la cual se producen acciones dinmicas independientes dentro del sistema. Los sistemas que se ejecutan en mltiples CPUs permiten hilos de control verdaderamente concurrentes, mientras que los sistemas que se ejecutan en una sola CPU slo pueden conseguir la ilusin de hilos concurrentes de control, normalmente mediante algn algoritmo de tiempo compartido. Proceso pesado: aquel tpicamente manejado de forma independiente por el sistema operativo de destino, y abarca su propio espacio de direcciones. 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. Disear un sistema que abarque mltiples hilos de control es muy difcil ya que hay que preocuparse de problemas tales como interbloqueo, bloqueo activo, inanicin, exclusin mutua y condiciones de competencia. Mientras que la POO se centra en la abstraccin de datos, encapsulamiento y herencia, la concurrencia se centra en la abstraccin de procesos y la sincronizacin. El objeto es un concepto que unifica estos dos puntos de vista distintos: cada objeto (extrado de una abstraccin del mundo real) puede representar un hilo separado de control (una abstraccin de un proceso). Tales objetos se llaman activos. En un sistema OO se puede conceptualizar el mundo como un conjunto de objetos cooperativos, algunos de los cuales son activos y sirven as como centros de la actividad independiente. La concurrencia es la propiedad que distingue un objeto activo de uno que no est activo. Una vez que se introduce la concurrencia a un sistema, hay que tener en cuenta como los objetos activos sincronizan sus actividades con otros, as como con objetos puramente secuenciales.
Persistencia.
El significado de la persistencia. Un objeto de software ocupa una cierta cantidad de espacio, y existe durante una cierta cantidad de tiempo. Hay un espacio de existencia que va desde los objetos transitorios que surgen en la evaluacin de una expresin hasta los objetos de una base de datos. Este espectro de persistencia abarca lo siguiente:
Pg. 18/38

1. 2. 3. 4. 5. 6. Resultados transitorios en la evaluacin de expresiones. Variables locales en la activacin de procedimientos. Variables propias, globales y elementos del montculo cuya duracin difiere de su mbito. Datos que existen entre ejecuciones de un programa. Datos que existen entre varias versiones de un programa. Datos que sobreviven al programa.
La persistencia abarca algo ms que la mera duracin de los datos. En las bases de datos orientadas a objetos, no slo persiste el estado del objeto, sino que su clase debe trascender tambin a cualquier programa individual, de forma que todos los programas interpreten de la misma manera el estado almacenado. Esto hace que sea un reto evidente el mantener la integridad de una base de datos a medida que crece, particularmente si hay que cambiar la clase de un objeto. La persistencia es la propiedad de un objeto por la que su existencia trasciende el tiempo 8es decir, el objeto contina existiendo despus de que su creador deja de existir) y / o el espacio (es decir, la posicin del objeto vara con respecto al espacio de direcciones en el que fue creado).
2.3 - Aplicacin del modelo de objetos.

Beneficios del modelo de objetos.
El uso del modelo de objetos conduce a la construccin de sistemas que incluyen los cinco atributos de los sistemas complejos bien estructurados. 1) Ayuda adems a explotar la potencia expresiva de los lenguajes de programacin basados en objetos y orientados a objetos. Se han logrado mejoras significativas con por ejemplo, una pizca de abstraccin de datos aadida donde era claramente til, o apreciando las jerarquas de clases en el proceso de diseo. 2) Promueve la reutilizacin no slo de software, sino de diseos enteros, conduciendo a la creacin de marcos de desarrollo de aplicaciones reutilizables. Los sistemas orientados a objetos son frecuentemente ms pequeos que sus implantaciones equivalente no orientadas a objetos. Significa escribir y mantener menos cdigo aparte de una reutilizacin de software que refleja beneficios de coste y planificacin. 3) Produce sistemas que se construyen sobre formas intermedias estables, son ms flexibles al cambio. Tienen una mejor evolucin en el tiempo y mayor ciclo de vida. 4) Reduce los riesgos inherentes al desarrollo de sistemas complejos. La integracin se distribuye a lo largo del ciclo vital en vez de suceder como un evento principal. 5) Resulta atractivo para el funcionamiento de la cognicin humana, porque muchas personas que no tiene ni idea de cmo funciona un computador encuentran bastante natural la idea de los sistemas orientados a objetos. El modelo de objetos ha demostrado ser aplicable a una amplia variedad de dominios de problema. Hoy en da, el DOO puede que sea el nico mtodo que puede emplearse para atacar la complejidad innata a muchos sistemas grandes. Sin embargo, puede no ser aconsejable en dominios, no por razones tcnicas sino por cuestiones como falta de personal con entrenamiento adecuado o buenos entornos de desarrollo.
Pg. 19/38
Anlisis y Diseo Orientado a Objetos Grady Booch RESUMEN CAPITULO 2

La madurez de la ingeniera del software ha conducido al desarrollo de mtodos de anlisis, diseo y programacin orientados 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, orientados 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 objeto, y proporciona as fronteras conceptuales definidas con nitidez, desde la perspectiva del observador. El encapsulamiento es el proceso de compartimentar los elementos de una abstraccin que constituyen su estructura y comportamiento. Sirve para separa 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 ordenacin 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 restrictivas. La concurrencia es la propiedad que distingue un objeto activo de uno que no est activo. La persistencia es la propiedad de un objeto mediante la cual su existencia perdura en el tiempo y/o el espacio.
Pg. 20/38
Captulo 3 Clases y Objetos

Las clases y los objetos son los bloques bsicos de construccin de un sistema de software complejo.
3.1 - La naturaleza de los objetos.

Qu es y qu no es un objeto.
A travs del concepto de objeto un nio llega a darse cuenta de que los objetos tienen una permanencia e identidad adems de cualesquiera operaciones sobre ellos. Desde la perspectiva de la cognicin humana un objeto es cualesquiera de las siguientes cosas: Una cosa tangible y / o visible. Algo que puede comprenderse intelectualmente. Algo hacia lo que se dirige un pensamiento o accin.
Un objeto modelo alguna parte de la realidad, y es por tanto algo que existe en el tiempo y el espacio. Los objetos del mundo real no son el nico tipo de objeto de inters para el desarrollo del software. Otros tipos importantes de objetos son invenciones del proceso de diseo cuyas colaboraciones con otros objetos semejantes sirven como mecanismos para desempear algn comportamiento de nivel superior. 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. Un objeto es cualquier cosa que tenga una frontera definida con nitidez. Algunos objetos pueden tener lmites conceptuales precisos, pero an as pueden representar eventos o procesos intangibles. Algunos objetos pueden ser tangibles y an as tener fronteras fsicas difusas (objetos como los ros, la niebla, etc.). Un objeto tiene estado, comportamiento e identidad; la estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables.
Estado.
Semntica.
El comportamiento de un objeto est influenciado por su historia: el orden en el que se opera sobre un objeto es importante. La razn para este comportamiento dependiente del tiempo y los eventos es la existencia de un estado interior del objeto. O sea que: El estado de un objeto abarca todas las propiedades (normalmente estticas) del mismo ms los valores actuales (normalmente dinmicos) de cada una de esas propiedades. Una propiedad es una caracterstica distintiva o inherente, un rasgo o cualidad que contribuye a hacer que un objeto sea ese objeto y no otro. Todas las propiedades tiene algn valor. Este valor puede ser una mera cantidad, o puede denotar a otro objeto. Esas cantidades son intemporales, inmutables y no instanciadas; mientras que los objetos existen en el tiempo, son modificables, tienen estado, son instanciados y pueden crearse, destruirse y compartirse. El hecho de que todo objeto tiene un estado implica que todo objeto toma cierta cantidad de espacio, ya sea en el mundo fsico o en la memoria del computador.
Pg. 21/38

Puede decirse que todos los objetos de un sistema encapsulan algn estado, y que todo el estado de un sistema est encapsulado en objetos. Sin embargo, encapsular el estado de un objeto es un punto de partido pero no es suficiente para permitir que se capturen todos los designios de las abstracciones que se descubren e inventan durante el desarrollo. Por esta razn, hay que considerar tambin cmo se comportan los objetos.
Comportamiento.
El significado del comportamiento. Ningn objeto existe de forma aislada. Los objetos reciben acciones y actan sobre otros objetos. El comportamiento es cmo acta y reacciona un objeto, en trminos de sus cambios de estado y paso de mensajes. Representa su actividad visible y comprobable exteriormente. Una operacin es una accin que un objeto efecta sobre otro con el fin de provocar una reaccin. Los trminos operacin y mensaje son intercambiables. En la mayora de los lenguajes de programacin orientados a objetos, las operaciones que los clientes pueden realizar sobre un objeto suelen declararse como mtodos (o funcin miembro en C++ por ejemplo). La definicin de comportamiento tambin recoge que el estado de un objeto afecta asimismo a su comportamiento. El comportamiento de un objeto es funcin de su estado as como tambin de la operacin que se realiza sobre l, teniendo algunas operaciones el efecto lateral de modificar el estado del objeto. El estado de un objeto representa los resultados acumulados de su comportamiento. Una operacin denota un servicio que una clase ofrece a sus clientes. Los tres tipos ms comunes de operaciones sobre un objeto son: a. b. c. d. e. Modificador Selector Una operacin que altera el estado de un objeto. Una operacin que accede al estado de un objeto, pero no altera ese estado.
Iterador Una operacin que permite acceder a todas las partes de un objeto en algn orden perfectamente establecido. Constructor Destructor Una operacin que crea un objeto y / o inicializa su estado. Una operacin que libera el estado de un objeto y / o destruye el propio objeto.
Roles y responsabilidades.
Todos los mtodos y subprogramas libres asociados a un objeto concreto forman su protocolo. El protocolo define as la envoltura del comportamiento admisible en un objeto, englobando la visin esttica y dinmica completa del mismo. Para la mayora de las abstracciones es til dividir este protocolo en grupos lgicos de comportamiento. Estas colecciones, que constituyen una particin del espacio de comportamiento de un objeto, denotan papeles que un objeto puede desempear. Un papel es una mscara que se pone un objeto y por tanto define un contrato entre una abstraccin y sus clientes. Las responsabilidades de un objeto incluyen dos elementos clave: el conocimiento que un objeto mantiene y las acciones que puede llevar a cabo. Las responsabilidades estn encaminadas a transmitir un sentido del propsito de un objeto y de su lugar en el sistema . Las responsabilidades de un objeto son todos los servicios que proporciona para todos los contratos que soporta.
Los objetos como mquinas.

La existencia de un estado significa que el orden en el que se invocan las operaciones es importante. Esto da lugar a la idea de que cada objeto es como una pequea mquina independiente. Se pueden entonces
Pg. 22/38

clasificar los objetos como activos o 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, pueden exhibir algn comportamiento sin que ningn otro objeto opere sobre ellos. Los pasivos, slo pueden padecer un cambio de estado cuando se acta explcitamente sobre ellos.
Identidad.
Semntica.
La identidad es aquella propiedad de un objeto que lo distingue de todos los dems objetos. La mayora de los lenguajes de programacin y bases de datos utilizan nombres de variable para distinguir objetos temporales, mezclando la posibilidad de acceder a ellos con su identidad. El fracaso en reconocer la diferencia entre el nombre del objeto y el objeto en s mismo es fuente de muchos errores en la programacin orientada a objetos.
Copia, asignacin e igualdad.

La comparticin estructural se da cuando la identidad de un objeto recibe un alias a travs de un segundo nombre. Es una operacin de copia. La asignacin es del mismo modo en general una operacin de copia. El problema de la igualdad est en relacin muy estrecha con el de la asignacin. Aunque se presenta como un concepto simple la igualdad puede presentar una de dos cosas. Primero, puede significar que dos nombres designan el mismo objeto y segundo, puede significar que dos nombres designan objetos distintos cuyos estados son iguales.
Espacio de vida de un objeto.

El tiempo de vida de un objeto se extiende desde el momento en que se crea por primera vez (y consume as espacio por primera vez) hasta que ese espacio se recupera. Para crear explcitamente un objeto hay que declararlo o bien asignarle memoria dinmicamente.
3.2 - Relaciones entre objetos.

Tipos de relaciones.
Los objetos contribuyen al comportamiento de un sistema colaborando con otros. En lugar de un procesador triturador de bits que golpea y saquea estructuras de datos, tenemos un universo de objetos bien educados que cortsmente solicitan a los dems que lleven a cabo sus diversos deseos. La relacin entre dos objetos cualesquiera abarca las suposiciones que cada uno realiza acerca del otro, incluyendo qu operaciones pueden realizarse y qu comportamiento se obtiene. Hay dos tipos de jerarquas de objetos: Enlaces Agregacin
Enlaces.
Una conexin fsica o conceptual entre objetos. Un objeto colabora con otros objetos a travs de sus enlaces con stos. Un enlace denota la asociacin especfica por la cual un objeto (el cliente) utiliza los servicios de otro objeto (el suministrador o servidor), o a travs de la cual un objeto puede comunicarse con otro.
Pg. 23/38

El paso de mensajes entre dos objetos es unidireccional, aunque ocasionalmente puede ser bidireccional. Como participante de un enlace, un objeto puede desempear uno de tres papeles: 1. 2. 3. Actor Un objeto que puede operar sobre otros objetos pero nunca se opera sobre l por parte de otros objetos; en algunos contextos, los trminos objeto activo y actor son equivalentes. Servidor Un objeto que nunca opera sobre otros objetos; slo 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 en nombre de un actor u otro agente.
Visibilidad.
Considrense dos objetos A y B con un enlace entre ambos. Para que A pueda enviarle un mensaje a B, B debe ser visible para A de algn modo. Durante el anlisis del problema se puede ignorar la visibilidad, pero una vez que se comienza a idear implantaciones concretas hay que considerarla a travs de los enlaces, porque las decisiones en este punto dictan el mbito y acceso de los objetos a cada lado del enlace. Hay cuatro formas en que un objeto puede tener visibilidad para otro: El objeto servidor es global para el cliente. El objeto servidor es un parmetro de alguna operacin del cliente. El objeto servidor es parte del objeto cliente. El objeto servidor es un objeto declarado localmente en alguna operacin del cliente.
Sincronizacin.
Siempre que un objeto pasa un mensaje a otro a travs de un enlace se dice que los dos objetos estn sincronizados. Para objetos de una aplicacin completamente secuencial, esta sincronizacin suele realizarse mediante una simple invocacin de mtodos. Sin embargo en presencia de mltiples hilos de control, los objetos requieren un paso de mensajes ms sofisticado. Hay que elegir uno de tres enfoques: 1. 2. 3. Secuencial La semntica del objeto pasivo est garantizada slo 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 de igual-a-igual o cliente / servidor, la agregacin denota una jerarqua todo / parte, con la capacidad de ir desde el todo (tambin llamado el agregado) hasta sus partes (conocido tambin como atributos). La agregacin puede o no denotar contencin fsica. 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 ms dbiles entre los objetos. Por implicacin, un objeto que es atributo de otro tiene un enlace a su agregado. A travs de este enlace, el agregado puede enviar mensajes a sus partes.
Pg. 24/38
3.3 - La naturaleza de una clase.

Qu es y qu no es una clase.
Los conceptos de clase y objeto estn estrechamente ligados pero hay que saber que mientras un objeto es una entidad concreta que existe en el tiempo y el espacio, una clase representa slo una abstraccin, la esencia de un objeto (lo que representa las caractersticas comunes de todos los objetos que pertenecen a una clase). Una clase es un conjunto de objetos que comparten una estructura comn y un comportamiento comn. Un solo objeto no es ms que una instancia de una clase. Un objeto no es una clase, aunque una clase s puede ser un objeto. La clase es un vehculo necesario, pero no suficiente, para la descomposicin.
Interfaz e implementacin.
Un objeto es una entidad concreta que desempea algn papel en el sistema global y una clase captura la estructura y comportamiento comunes a todos los objetos relacionados. As, una clase sirve como una especie de contrato que vincula a una abstraccin y todos sus clientes. Esta visin de la programacin como un contrato lleva a distinguir entre la visin externa y la visin interna de una clase. El interfaz de una clase proporciona su visin externa y por tanto enfatiza la abstraccin a la vez que oculta su estructura y los secretos de comportamiento. Se compone principalmente de todas las operaciones aplicables a instancias de esta clase, pero tambin puede incluir la declaracin de otras clases, constantes, variables, expresiones, segn se necesiten para completar la abstraccin. Por contraste, la implementacin es su visin interna que engloba los secretos de su comportamiento. La implementacin de una clase se compone principalmente de la implementacin de todas las operaciones definidas en el interfaz de la misma. El interfaz puede dividirse en: 1. 2. 3. Pblico (Public) Una declaracin accesible a todos los clientes. Protegida (Protected) Una declaracin accesible slo a la propia clase, sus subclases, y sus clases amigas. Privada (Private) Una declaracin accesible slo a la propia clase y sus clases amigas.
Ciclo de vida de las clases.

Se puede llegar a la comprensin del comportamiento de una clase simple con slo comprender la semntica de sus distintas operaciones pblicas de forma aislada. Sin embargo, el comportamiento de clases ms interesantes implica la interaccin de sus diversas operaciones a lo largo del tiempo de vida de cada una de sus instancias.
3.4 - Relaciones entre clases.

Tipos de relaciones.
Las clases, al igual que los objetos no existen aisladamente. Para un domino de problema especfico las abstracciones clave suelen estar relacionadas por vas muy diversas e interesantes formando la estructura de clases del diseo. Se establecen relaciones entre clases porque a. la relacin podra indicar algn tipo de comparticin. b. la relacin podra indicar algn tipo de conexin semntica. Existen tres tipos bsicos de relaciones entre clases:
Pg. 25/38

1. 2. 3. generalizacin / especializacin; denota una relacin es un. todo / parte; denota una relacin parte de. asociacin; denota alguna dependencia semntica entre clases de otro modo independientes.
Relaciones:
1) Asociacin 2) Herencia 3) Agregacin 4) Uso 5) Instanciacin (creacin de instancias o ejemplares) 6) Metaclase
Asociacin.
Una asociacin slo denota una dependencia semntica y no establece la direccin de esta dependencia (a menos que se diga lo contrario, una asociacin implica relacin bidireccional) ni establece la forma exacta en que una clase se relaciona con otra (slo puede denotarse esta semntica nombrando el papel que desempea cada clase en relacin con la otra).
Cardinalidad.
Existen tres tipos de Cardinalidad en una asociacin: 1. Uno a uno 2. Uno a muchos 3. Muchos a muchos.
Herencia.
La herencia es una relacin entre clases en la que una clase comparte la estructura y / o comportamiento definidos en una (herencia simple) o ms clases (herencia mltiple). La clase de las que otras heredan se llama superclase. La clase que hereda de otra o ms clases se denomina subclase. La herencia define por tanto una jerarqua de tipos entre clases, en las que una subclase hereda de una o ms superclases. Dadas las clases A y B, si A no es un tipo de B, entonces A no debera ser una subclase de B. La capacidad de un lenguaje para soportar o no este tipo de herencia distingue a los lenguajes de programacin orientados a objetos de los lenguajes basados en objetos. Una subclase generalmente aumenta o restringe la estructura y comportamiento existentes en sus superclases. Una subclase que aumenta sus superclases se dice que utiliza herencia por extensin, mientras que la subclase que restringe a sus superclases se dice que utiliza herencia por restriccin. Se espera que algunas de las clases generadas tengan instancias y que otras no las tengan (frecuentemente las intermedias). Las clases sin instancias se llaman clases abstractas. Las clases ms especializadas se llaman clases hoja o clases concretas. La clase ms generalizada en una estructura de clases se llama clase base. Una clase cualquiera tiene tpicamente dos tipos de clientes: A. Instancias.
Pg. 26/38

B. Subclases. Para comprender el significado de una clase particular muchas veces hay que estudiar todas sus superclases, a veces incluyendo sus vistas internas.
Polimorfismo simple.
Es un concepto de teora de tipos en el que un nombre puede denotar instancias de muchas clases diferentes en tanto y en cuanto estn relacionadas por alguna superclase comn. Cualquier objeto denotado por este nombre es, por tanto, capaz de responder a algn conjunto de operaciones de diversas formas. Sobrecarga es una forma de llamar a un polimorfismo por el cual smbolos como el + podran definirse para significar cosas distintas. El polimorfismo es ms til cuando existen muchas clases con los mismos protocolos.
Herencia mltiple.
Con herencia simple, cada subclase tiene exactamente una superclase. Esto limita la aplicabilidad de las clases predefinidas, haciendo muchas veces necesario duplicar cdigo. Las colisiones de nombres pueden aparecer cuando dos o ms superclases diferentes utilizan el mismo nombre para algn elemento de sus interfaces, como las variables de instancias o los mtodos. Otro problema es la herencia repetida, que es lo que sucede cuando una clase es un antecesor de otra por ms de una va. La existencia de herencia mltiple plantea un estilo de clases, llamadas aditivas porque se mezclan, se combinan pequeas clases para construir clases con un comportamiento ms sofisticado. Una clase aditiva es sintcticamente idntica una normal, pero su intencin es distinta. El propsito de tal clase es nicamente aadir funciones a otras clases. No pueden existir por s mismas, se usan para aumentar el significado de otra clase. Una clase que se construye principalmente heredando de clases aditivas y no aade su propia estructura o comportamiento se llama clase agregada.
Agregacin.
Las relaciones de agregacin entre clases tienen un paralelismo directo con las relaciones de agregacin entre los objetos correspondientes a esas clases.
Contencin fsica.
Contencin por valor: un tipo de contencin fsica que significa que el objeto no existe independientemente de la instancia que lo encierra. El tiempo de vida de ambos objetos est en ntima conexin. Contencin por referencia: tipo de agregacin menos directo. En este caso, la clase sigue denotando al todo, y una de sus partes sigue siendo una instancia de la clase, aunque ahora hay que acceder a esa parte indirectamente. Sus tiempos de vida no estn tan estrechamente emparejados. La agregacin establece una direccin en la relacin todo / parte. La contencin por valor no puede ser cclica (ambos objetos no pueden ser fsicamente partes del otro), aunque la contencin por referencia s puede serlo. La herencia mltiple se confunde a menudo con la agregacin. Cuando se considera la herencia versus agregacin, recurdese aplicar la prueba correspondiente para ambas. Si no se puede afirmar sinceramente que existe una relacin es un entre dos clases, habra que utilizar agregacin o alguna otra relacin en vez de herencia.
Pg. 27/38
Uso.
Una clase usa los servicios de otra. Mientras que una asociacin denota una conexin semntica bidireccional, 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 que proporciona ciertos servicios.
Instanciacin.
Creacin de instancias.
Metaclases.
Es una clase cuyas instancias son, ellas mismas, clases. Se justifica su necesidad al hacer notar que en un sistema bajo desarrollo, una clase proporciona al programador un interfaz para comunicarse con la definicin de objetos. Para este uso de las clases, es extremadamente til para ellas ser objetos, de forma que puedan ser manipulados de la misma forma que todas las dems descripciones.
3.5 - La interaccin entre clases y objetos.

Relaciones entre clases y objetos.
Las clases y objetos son conceptos diferentes pero en ntima relacin. Concretamente todo objeto es instancia de alguna clase y toda clase tiene cero o ms instancias.
El papel de clases y objetos en 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. Idear las estructuras por las que conjuntos de objetos trabajan juntos para lograr los comportamientos que satisfacen los requerimientos del problema.
En conjunto se llama a esas clases y objetos las abstracciones claves del problema. Se denomina a esas estructuras cooperativas los mecanismos de la implantacin. Durante estas fases del desarrollo, el inters principal del desarrollo de estar en la vista externa de estas abstracciones clave y mecanismos. Esta vista representa el marco de referencia lgico del sistema y, por tanto, abarca la estructura de clases y la estructura de objetos del mismo. En las etapas finales del diseo y entrando ya en la implantacin, la tarea del desarrollador cambia: el centro de atencin est en la vista interna de estas abstracciones clave y mecanismos, involucrando a su representacin fsica. Pueden expresarse estas decisiones de diseo como parte de la arquitectura de mdulos y la arquitectura de procesos del sistema.
Pg. 28/38
Anlisis y Diseo Orientado a Objetos Grady Booch 3.6 - De la construccin de clases y objetos de calidad.
Medida de la calidad de una abstraccin.
Cmo puede saberse si una clase u objeto est bien diseado? Se sugieren cinco mtricas significativas: Acoplamiento Cohesin Suficiencia Complecin (estado completo / plenitud) Ser primitivo
Acoplamiento:
es una nocin copiada del diseo estructurado, es la medida de la fuerza de la asociacin establecida por una conexin entre un mdulo y otro. El acoplamiento fuerte complica un sistema porque los mdulos son ms difciles de comprender, cambiar o corregir por s mismos si estn muy interrelacionados con otros mdulos. La complejidad puede reducirse diseando sistemas con los acoplamientos ms dbiles posibles entre los mdulos. Es igualmente importante el acoplamiento entre clases y objetos. Existe tensin entre los conceptos de acoplamiento y herencia ya que la herencia implica un acoplamiento considerable. Es deseable clases dbilmente acopladas pero es la herencia ayuda tambin a explotar las caractersticas comunes de las abstracciones.
Cohesin: tambin proviene del diseo estructurado. Mide el grado de conectividad entre los elementos
de un solo mdulo, clase u objeto. 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 ms deseable es la cohesin funcional en la cual los elementos de una clase o mdulo trabajan todos juntos para proporcionar algn comportamiento bien delimitado. Hay mayor cohesion cuando ay mas actividad entre ambos.
Suficiente: la clase o mdulo captura suficientes caractersticas de la abstraccin como para permitir
una interaccin significativa y eficiente.
Ser primitivo: Son aquellas q solo se pueden resolver cuando se tiene acceso a la implentacion Estado completo: 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 puede exagerarse. Ofrecer todas las operaciones significativas para una abstraccin particular desborda al usuario y suele ser innecesario, ya que muchas operaciones de alto nivel pueden componerse partiendo de las de bajo nivel. Por ello se sugiere que las clases y mdulos sean primitivos.
Operaciones primitivas: aquellas que pueden implantarse eficientemente slo si tienen acceso a
la representacin subyacente. Una operacin es primitiva si se puede implantar slo accediendo a la representacin interna. Una operacin que podra implantarse sobre operaciones primitivas existentes pero a un coste de recursos computacionales significativamente mayor, es tambin candidata para su inclusin como operacin primitiva.
Pg. 29/38
Seleccin de operaciones.
Semntica funcional. Es habitual en el desarrollo orientado a objetos disear los mtodos de una clase como un todo, porque todos esos mtodos cooperan para formar el protocolo completo de la abstraccin. As, dado un comportamiento que se desea hay que decidir en qu clase se sita. Para tomar una decisin de ese tipo se sugieren los siguientes criterios:

Reutilizacin Complejidad Aplicabilidad Conocimiento de la implementacin
Sera este el comportamiento ms til en ms de un contexto? Qu grado de dificultad plantea el implementar este comportamiento? Qu relevancia tiene este comportamiento para el tipo en el que podra ubicarse? Depende la implementacin del comportamiento de los detalles internos de un cierto tipo?
Semntica espacial y temporal. Una vez definida una operacin y su semntica funcional hay que especificar la cantidad de tiempo que lleva completar la operacin (semntica temporal) y la cantidad de espacio de almacenamiento que necesita (semntica espacial). Siempre que un objeto pasa un mensaje a travs de un enlace, ambos objetos deben estar sincronizados de alguna forma. En presencia de mltiples hilos de control esto significa que el paso de mensajes es mucho ms que una mera seleccin de subprogramas. El paso de mensajes debe as adoptar una de las formas siguientes: Una operacin comienza slo cuando el emisor ha iniciado la accin y el receptor est preparado para aceptar el mensaje; el emisor y el receptor esperarn indefinidamente hasta que ambas partes estn preparadas para continuar. Igual que el sncrono, excepto en que el emisor abandonar la operacin si el receptor no est preparado inmediatamente.
Sncrono
Abandono inmediato
De intervalo
Igual que el sncrono, excepto en que el emisor esperar a que el receptor est listo durante un intervalo de tiempo especificado.
Asncrono
Un emisor puede hincar una accin independientemente de si el receptor est esperando o no el mensaje.
Pg. 30/38

Eleccin de relaciones.
Colaboraciones. Define la accesibilidad. Por accesible se entiende la capacidad de una abstraccin para ver a otra y hacer referencia a recursos en su vista externa. Una abstraccin es accesible a otra slo donde sus mbitos se superpongan y slo donde estn garantizados los derechos de acceso. Los mtodos de una clase no deberan depender de ninguna manera de la estructura de ninguna clase, salvo de la estructura inmediata (de nivel superior) de su propia clase.
Mecanismos y visibilidad. La decisin sobre las relaciones entre objetos es principalmente una cuestin de disear los mecanismos por los que esos objetos interactan. Durante el proceso de diseo es til establecer explcitamente cmo un objeto es visible para otro. Existen cuatro formas fundamentales por las que un objeto X se puede hacer visible aun 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.
Hay una variacin sobre cada una de estas ideas y es la idea de visibilidad compartida.
Eleccin de implementaciones.
Representacin. La representacin de una clase u objeto debera casi siempre ser uno de los secretos encapsulados de la abstraccin. Esto posibilita cambiar la representacin sin violar ninguna de las suposiciones funcionales que los clientes puedan haber hecho. A veces no es fcil elegir con que representacin se queda el objeto (cuando dos o ms se contradicen o compiten). De eso modo muchas veces se acaba con familias de clases cuyas interfaces son prcticamente idnticos, pero cuyas implantaciones son radicalmente distintas, con el fin de proporcionar diferentes comportamientos respecto al espacio y al tiempo. Una de las compensaciones ms difciles cuando se selecciona la implantacin de una clase se da entre el clculo del valor del estado de un objeto y su almacenamiento como un campo.
Empaquetamiento.
Aparecen problemas similares en la declaracin de clases y objetos dentro de los mdulos. Los requerimientos competidores de visibilidad y ocultacin de informacin suelen guiar las decisiones de diseo sobre donde declarar clases y objetos. Generalmente, se busca construir mdulos con cohesin funcional y dbilmente acoplados. Hay muchos factores no tcnicos que influyen estas decisiones como cuestiones de reutilizacin, seguridad y documentacin. Al igual que el diseo de clases y objetos no hay que tomar a la ligera el diseo de mdulos.
Pg. 31/38
RESUMEN CAPITULO 3
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 (normalmente estticas) del mismo ms los valores actuales (normalmente dinmicos) de cada una de esas propiedades. El comportamiento de 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, completad (estado completo), y por el grado hasta el cual es primitiva.
Pg. 32/38
Captulo 4 Clasificacin
La clasificacin es el medio por el que ordenamos el conocimiento. En el diseo orientado a objetos, el renacimiento de la similitud entre las cosas nos permite exponer lo que tienen en comn en abstracciones clave y mecanismos. No hay recetas fciles para identificar clases y objetos. Existen tcnicas de anlisis orientado a objetos que ofrecen varias recomendaciones prcticas y reglas tiles para identificar las clases y objetos relevantes para un problema concreto.
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 OO. La experiencia muestra que la identificacin 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. 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 mdulos diferentes, dependiendo de la similitud que se encuentra entre esas declaraciones, el acoplamiento y la cohesin son simplemente medidas de esta similitud.
La dificultad de la clasificacin
Ejemplos de clasificacin. En el captulo anterior se defini un objeto como algo que tiene una frontera definida con nitidez. Sin embargo, las fronteras que distinguen un objeto de otro son a menudo bastante difusas. Por ejemplo: Dnde comienza la rodilla y donde termina? Darwin propuso la teora de que la seleccin natural fue el mecanismo de la evolucin, en virtud de la cual las especies actuales evolucionaron de otras ms antiguas. La teora de Darwin dependa de una clasificacin inteligente de especies. Descartes afirmaba que 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. La naturaleza incremental e iterativa de la clasificacin. La clasificacin inteligente es un trabajo intelectualmente difcil, y la mejor forma de realizarlo es a travs de un proceso incremental e iterativo. La naturaleza incremental e iterativa 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 puede dividir una clase grande en varias ms pequeas (composicin). Se puede incluso descubrir aspectos comunes que haban pasado desapercibidos, e idear una nueva subclase (abstraccin). La dificultad radica en 2 razones importantes: 1. No existe algo que pueda llamarse una clasificacin perfecta, algunas clasificaciones son mejores que otras. Potencialmente, hay al menos tantas formas de dividir el mundo en sistemas de objetos como cientficos para emprender la tarea. 2. La clasificacin inteligente requiere una gran perspicacia creativa: a veces la respuesta es evidente, a veces es una cuestin de gustos, y otras veces, la seleccin de componentes adecuados es un punto curial del anlisis.
Pg. 33/38
Anlisis y Diseo Orientado a Objetos Grady Booch 4.2 Identificando clases y objetos.
Enfoques clsicos y modernos.
Histricamente slo han existido tres aproximaciones generales a la clasificacin: Categorizacin clsica. Agrupamiento conceptual. Teora de los prototipos.
Categorizacin clsica. Es la aproximacin clsica a la categorizacin: 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. Un mayor conocimiento significativo sobre un dominio facilita, hasta cierto punto, conseguir una clasificacin inteligente. 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 pueda volar pero un pez no pueda, es una propiedad que distingue un guila de un salmn.
Agrupamiento conceptual Es una variacin ms moderna del enfoque clsico. Representa ms bien un agrupamiento probabilstico de los objetos. El agrupamiento conceptual est en estrecha relacin con la teora de conjuntos difusos (multivalor), en la que los objetos pueden pertenecer a uno o ms grupos , en diversos grados de adecuacin. Realiza juicios absolutos de la clasificacin centrndose en la mayor adecuacin.
Teora de los prototipos Existen abstracciones que no tienen ni propiedades ni conceptos delimitados con claridad. Por ejemplo, una categora como juego no encaja en el molde clsico, porque no hay propiedades comunes compartidas por todos los juegos tampoco hay una frontera fija para la categora juego. Podra extenderse, se pueden introducir nuevos tipos de juegos, siempre que se parezcan a juegos anteriores de forma apropiada. Esta es la razn por la que el enfoque se denomina teora de prototipos: 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. Aplicacin de las teoras clsicas y modernas. Las tres aproximaciones a la clasificacin tienen aplicacin directa en el diseo OO. Se identifican las clases y objetos -en primer lugar- de acuerdo con las propiedades relevantes para nuestro dominio particular.
Anlisis Orientado a Objetos

Las fronteras entre anlisis y diseo son difusas. 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.
Pg. 34/38

Enfoques clsicos Derivan sobre todo de los principios de la categorizacin clsica. Ejemplos: Shlaer y Mellor sugieren que las clases y objetos candidatos provienen habitualmente de una de las fuentes siguientes: COSAS TANGIBLES PAPELES (ROLES) EVENTOS INTERACCIONES Coches, datos de telemetra, sensores de presin Madre, profesor, poltico Aterrizaje, interrupcin, peticin Prstamo, reunin, interseccin.
Desde la perspectiva del modelado de bases de datos: PERSONAS Humanos que llevan a cabo alguna funcin. LUGARES Areas reservadas para personas o cosas COSAS Objetos fsicos, o grupos de objetos, que son tangibles. ORGANIZACIONES Colecciones formalmente organizadas de personas, recursos, instalaciones y posibilidades que tienen una misin definida. EVENTOS Cosas que suceden, habitualmente a alguna otra cosa, en una fecha y hora concretas, o como pasos dentro de una secuencia ordenada. Coad y Yourdon sugieren otro conjunto ms fuerte de objetos potenciales: 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 usuarios.
Anlisis del comportamiento Se centra en el comportamiento dinmico como fuente primaria de clases y objetos. Se forman clases basadas en grupos de objetos que exhiben comportamiento similar. Las responsabilidades denotan el conocimiento que un objeto tiene y las acciones que un objeto puede realizar. Las responsabilidades de un objeto son todos los servicios que suministra para todos los contratos que soporta. De esta forma se agrupan cosas que tienen responsabilidades comunes, y se forman jerarquas de clases que involucran a superclases que incorporan responsabilidades generales y subclases que especializan su comportamiento. Al poner el nfasis en la comprensin de lo que sucede en el sistema, nos encontramos con los comportamientos del sistema, asignndolos a partes del sistema, donde surge la necesidad de entender quien inicia esos 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. 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, etc. Se trata de un intento por identificar los objetos, operaciones y relaciones con los expertos del dominio consideran importantes acerca del mismo.
Pg. 35/38

Anlisis de Casos de Uso. 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 usuarios finales, expertos del dominio y el equipo de desarrollo enumeran los escenarios fundamentales para el funcionamiento del sistema. Estos escenarios en conjunto describen las funcionales del sistema en esa aplicacin. El anlisis procede entonces como un estudio de cada escenario, utilizando tcnicas de presentacin. A medida que el equipo pasa por cada escenario, debe identificar los objetos que participan en el, las responsabilidades de cada objeto, y cmo esos objetos colaboran con otros, en trminos de las operaciones que invoca cada uno sobre el otro. Fichas CRC Las fichas CRC surgieron como una forma simple, pero maravillosamente efectivas de analizar escenarios. Es una tarjeta con una tabla de 3 X 55, sobre la cual el analista escribe el nombre de una clase (en la parte superior de la tarjeta), sus responsabilidades (en la mitad de la tarjeta) y sus colaboradores (en la otra mitad). Se crea una ficha para cada clase que se identifique como relevante para el escenario. Pueden disponerse espacialmente para representar patrones de colaboracin. Descripcin informal en espaol Una alternativa al anlisis OO clsico fue la propuesta de Abbott, quien sugiri redactar una descripcin del problema (o 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 al desarrollador a trabajar en el vocabulario del espacio del problema. Anlisis Estructurado Una segunda alternativa al Anlisis OO clsico utiliza los productos del anlisis estructurado como va de entrada al diseo orientado a objetos. Esta tcnica es atractiva slo porque hay gran nmero de analistas con experiencia en anlisis estructurado, y existen muchas herramientas CASE que soportan la automatizacin de estos mtodos. Es desaconsejable el uso del anlisis estructurado como punto de partida para el diseo OO.
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; enfatizan las cosas que estn en el sistema y, por lo tanto, son relevantes para el diseo y suprimen las cosas que estn fura del sistema. Por ejemplo: Un cliente que utiliza un cajero automtico habla en trminos de cuentas, depsitos y reintegros; estas palabras son parte del vocabulario del dominio del problema. Un desarrollador de un sistema semejante utiliza estas mismas abstracciones, pero introduce tambin algunas nuevas, como bases de datos, manejadores de pantallas, listas, cosas, etc. Estas abstracciones clave son artefactos del diseo particular, no del dominio del problema. .
Pg. 36/38

Refinamiento de abstracciones clave. Una vez que se identifica determinada clave como candidata, hay que evaluarla de acuerdo a las m6tricas descriptas 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. En la prctica: No siempre se disean tipos en una jerarqua de tipos comenzando por un supertipo y creando a continuacin los subtipos, sino que se crean varios tipos aparentemente dispares, se da cuenta de que estn relacionados, y entonces factoriza sus caractersticas comunes en uno o ms supertipos. 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 de clases, incrementando as el grado de comparticin. Esto se llama promocin de clases. Analgicamente 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. Sugerencias: Los objetos deberan nombrarse empleando frases construidas con nombres propios, como elSensor o simplemente forma. Las clases deberan nombrarse empleando frases construidas 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.
Identificacin de mecanismos
Bsqueda de mecanismos. Utilizamos la palabra mecanismo para describir cualquier estructura mediante la cual los objetos colaboran para proporcionar algn comportamiento que satisface un requerimiento del problema. Los mecanismos representan patrones de comportamiento. El mecanismo que elige un desarrollador entre un conjunto de alternativas es frecuentemente el resultado de otros factores, como costo, fiabilidad, facilidad de fabricacin y seguridad. Una vez que el desarrollador decide sobre un patrn concreto de colaboracin, se distribuye el trabajo entre muchos objetos definiendo mtodos convenientes en las clases apropiadas. Los mecanismos representan as decisiones de diseo estratgicas, como el diseo de una estructura de clases. La interfaz de una clase individual es ms bien una decisin de diseo tctica. Ejemplos de mecanismos Consideremos el mecanismo de dibujo utilizado habitualmente en intercales grficas de usuario. 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 cundo (pero no cmo) hay que visualizar ese modelo.
Pg. 37/38

RESUMEN-CAPITULO 4 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 o iterativo, que se complica por el hecho de que un conjunto dado de objetos puede clasificarse de 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 de un prototipo) Los escenarios son una potente herramienta para el anlisis orientado a objetos, y pueden utilizarse para guiar los procesos de anlisis clsico, anlisis del comportamiento y anlisis de dominios. 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.
Pg. 38/38

Análisis y Diseño Orientado A Objetos - Grady Booch

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Análisis y Diseño Orientado A Objetos - Grady Booch

Загружено:

Авторское право:

Доступные форматы

Anlisis y Diseo Orientado a Objetos Grady Booch

Anlisis y Diseo Orientado a Objetos

Anlisis y Diseo Orientado a Objetos Grady Booch

CAPTULO 2 EL MODELO DE OBJETOS....................................................... .............11

Anlisis y Diseo Orientado a Objetos Grady Booch

CAPTULO 3 CLASES Y OBJETOS............................................................. ................21

Anlisis y Diseo Orientado a Objetos Grady Booch

CAPTULO 4 CLASIFICACIN................................................................................ .....33

Anlisis y Diseo Orientado a Objetos Grady Booch

Captulo 1 - Complejidad 1.1 La complejidad inherente al software

El software es complejo de forma innata. Es una caracterstica esencial de l.

Anlisis y Diseo Orientado a Objetos Grady Booch

Las consecuencias de la complejidad ilimitada.

1.2 La estructura de los sistemas complejos.

Los cinco atributos de un sistema complejo.

Anlisis y Diseo Orientado a Objetos Grady Booch

Complejidad organizada y desorganizada.

1.3 - Imponiendo orden al caos.

Descomposicin algortmica: cada mdulo del sistema representa un paso importante de un

Descomposicin orientada a objetos:

Anlisis y Diseo Orientado a Objetos Grady Booch

Categoras de mtodos de diseo.

Diseo estructurado descendente o diseo compuesto:

Anlisis y Diseo Orientado a Objetos Grady Booch

1.4 - Del diseo de sistemas complejos.

La importancia de construir un modelo.

Modelo lgico Modelo fsico Modelo esttico Modelo dinmico

Anlisis y Diseo Orientado a Objetos Grady Booch

Anlisis y Diseo Orientado a Objetos Grady Booch

Captulo 2 El modelo de objetos

2.1 - La evolucin del modelo de objetos.

Primera generacin: represent un paso de acercamiento al problema y un paso de alejamiento

Tercera generacin: se requirieron ms tipos de datos. Se empez a soportar la abstraccin de

Topologa de los lenguajes de primera y principios de la segunda generacin.

Topologa de los lenguajes de fines de la segunda y principios de la tercera generacin.

Anlisis y Diseo Orientado a Objetos Grady Booch

Topologa de los lenguajes de finales de la tercera generacin.

Topologa de los lenguajes basados en objetos y orientados a objetos.

Fundamentos del modelo de objetos.

Programacin orientada a objetos.

Anlisis y Diseo Orientado a Objetos Grady Booch

Diseo orientado a objetos.

Anlisis orientado a objetos.

2.2 - Elementos del modelo de objetos.

Anlisis y Diseo Orientado a Objetos Grady Booch

Hay tres elementos secundarios: Tipos (tipificacin) Concurrencia Persistencia

Abstraccin de mquinas virtuales

Un objeto que almacena un conjunto de operaciones que no tiene relacin entre s.

Anlisis y Diseo Orientado a Objetos Grady Booch

Anlisis y Diseo Orientado a Objetos Grady Booch

Anlisis y Diseo Orientado a Objetos Grady Booch

Anlisis y Diseo Orientado a Objetos Grady Booch

Anlisis y Diseo Orientado a Objetos Grady Booch

2.3 - Aplicacin del modelo de objetos.

Anlisis y Diseo Orientado a Objetos Grady Booch RESUMEN CAPITULO 2

Anlisis y Diseo Orientado a Objetos Grady Booch

Captulo 3 Clases y Objetos

3.1 - La naturaleza de los objetos.

Anlisis y Diseo Orientado a Objetos Grady Booch

Los objetos como mquinas.

Anlisis y Diseo Orientado a Objetos Grady Booch

Copia, asignacin e igualdad.

Espacio de vida de un objeto.