Elementos de Desarrollo OO

LENGUAJES ORIENTADOS A OBJETOS
Lenguajes Orientados a Objetos
Elementos de Anlisis y Desarrollo Orientados a Objetos

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS 1
Contenido
1. El Problema de la Complejidad del Software Los Cinco Atributos de un Sistema Complejo El Rol de la Descomposicin 2. El Modelo Orientado a Objetos La Evolucin del Modelo de Objetos Elementos del Modelo de Objetos Abstraccin Encapsulamiento Modularidad Jerarqua Tipos (Tipificacin) Concurrencia Persistencia Aplicacin del Modelo de Objetos 3. Objetos y Clases: Naturaleza y Relaciones Estado Comportamiento Identidad Relaciones entre Objetos La Naturaleza de una Clase Relaciones entre Clases Relaciones de herencia Relaciones de uso Relaciones de instanciacin Relaciones de metaclases Relaciones entre Clases y Objetos El Rol de Clases y Objetos en Anlisis y Diseo Relaciones de herencia entre clases Relaciones de uso entre clases Relaciones de instanciacin entre clases Metaclases 4. Metodologa de Booch Anlisis Diseo Evolucin Modificacin
ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS
Diagramas de Clases Estados y Transiciones de Estado Diagramas de Objetos Diagramas de Mdulos Diagramas de Procesos 6. El Proceso de Desarrollo en la Metodologa de Booch Identificacin de Clases y Objetos Identificacin de la Semntica de las Clases y Objetos Identificacin de las Relaciones entre Clases y Objetos Implementacin de Clases y Objetos 7. Metodologa OMT Anlisis Diseo de Sistemas Diseo de Objetos 8. Modelos OMT Modelado de Objetos Objetos y Clases Diagramas de Objetos Enlaces y Asociaciones Generalizacin y Herencia Modelado Dinmico Sucesos y Estados Operaciones Modelado Funcional Empaquetamiento Fsico Implementacin Diseo de Objetos Diseo de Asociaciones Asignacin de Subsistemas a Procesadores y a Tareas Administracin de Almacenes de Datos Manejo de las Condiciones de Contorno Diseo del Sistema Descomposicin de un Sistema en Subsistemas Modelado Dinmico Modelado Funcional Adicin de Operaciones Iteracin del Anlisis
5. Notacin de Booch
1. El Problema de la Complejidad del Software

La caracterstica distintiva del software de dimensin industrial es que resulta sumamente difcil, si no imposible, para el desarrollador individual comprender todas las sutilidades de su diseo. Para hablar claro, la complejidad de tales sistemas excede la capacidad intelectual humana. Lamentablemente, la complejidad de la que se habla parece ser una propiedad esencial de todos los sistemas de software de gran tamao. Con esencial quiere decirse que puede dominarse esa complejidad, pero nunca eliminarla. Ya se sabe que algunos sistemas de software no son complejos. Son las aplicaciones altamente intranscendentes que son especificadas, construidas, mantenidas y utilizadas por la misma persona, habitualmente el programador aficionado o el desarrollador profesional que trabaja en solitario. Tales sistemas tienden a tener un propsito muy limitado y un ciclo de vida muy corto. Uno puede permitirse tirarlos a la basura y reemplazarlos con software completamente nuevo en lugar de intentar reutilizarlos, repararlos o extender su funcionalidad. En lugar de eso, interesan mucho ms los desafos que plantea el desarrollo de lo que llamaremos software de dimensin industrial.
Por qu el software es complejo de forma innata

La complejidad del software es una propiedad esencial, no accidental. Se observa que esta complejidad inherente se deriva de cuatro elementos: 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. Los problemas que se intentan resolver con el software conllevan a menudo elementos de complejidad ineludible, en los que se encuentra una mirada de requisitos que compiten entre s, que quizs incluso se contradicen, y los requisitos de un sistema de software cambian frecuentemente durante su desarrollo. La dificultad de gestionar el proceso de desarrollo. Hoy en da no es extrao encontrar sistemas ya terminados cuyo tamao se mide en cientos de miles, o incluso millones de lneas de cdigo (y todo esto adems en un lenguaje de programacin de alto nivel). Nadie puede comprender completamente tal sistema. Incluso si se descompone la implementacin de formas significativas, an hay que enfrentarse a cientos y a veces miles de mdulos separados. Esta cantidad de trabajo exige la utilizacin de un equipo de desarrolladores, y de forma ideal se utiliza un equipo tan pequeo como sea posible. Sin embargo, da igual el tamao, siempre hay retos considerables asociados con el desarrollo en equipo. Un mayor nmero de desarrolladores implica una comunicacin ms compleja y por tanto una
comunicacin ms difcil, particularmente si el equipo est disperso geogrficamente, y esta situacin no es nada excepcional en proyectos muy grandes. Con un equipo de desarrolladores, el reto clave de la direccin es siempre mantener una unidad e integridad en el diseo. La flexibilidad que se puede alcanzar a travs del software. El software ofrece la flexibilidad mxima por lo que un desarrollador puede expresar casi cualquier clase de abstraccin. Esta flexibilidad resulta ser una propiedad que seduce increblemente, sin embargo, porque tambin empuja al desarrollador a construir por s mismo prcticamente todos los bloques fundamentales sobre los que se apoyan estas abstracciones de ms alto nivel. Los problemas de caracterizar el comportamiento de sistemas discretos. En una aplicacin de gran tamao puede haber cientos o hasta miles de variables, as como ms de un posible flujo de control. El conjunto de todas estas variables, sus valores actuales, y la direccin de ejecucin y pila actual de cada uno de los procesos del sistema constituyen el estado actual de la aplicacin. Al ejecutarse el software en computadoras digitales, se tiene un sistema con estados discretos. Todos los eventos externos a un sistema de software tienen la posibilidad de llevar a ese sistema a un nuevo estado, y ms an, la transicin de estado a estado no siempre es determinista.
Los Cinco Atributos de un Sistema Complejo

Los enlaces internos de los componentes suelen ser ms fuertes que los enlaces entre 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 alta frecuencia - que involucra la interaccin entre los componentes. Los sistemas jerrquicos estn compuestos usualmente de slo unas pocas clases diferentes de subsistemas en varias combinaciones y disposiciones. Frecuentemente, la complejidad toma la forma de una jerarqua, por lo cual un sistema complejo se compone de subsistemas relacionados que tienen a su vez sus propios subsistemas, y as sucesivamente, hasta que se alcanza algn nivel nfimo de componentes elementales. Se encontrar invariablemente 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. La eleccin de qu componentes de un sistema son primitivos es relativamente arbitraria y queda en gran medida a decisin del observador del sistema.
El Rol de la Descomposicin
Cuando se disea un sistema de software complejo, es esencial descomponerlo en partes ms y ms pequeas, cada una de las cuales se puede refinar entonces de forma independiente. De este modo se satisface la restriccin fundamental que existe sobre la capacidad de canal de la comprensin humana: para entender un nivel dado de un sistema, basta con comprender unas pocas partes (no necesariamente todas) a la vez. Descomposicin Algortmica. La mayora de los informticos han sido adiestrados en el dogma del diseo estructurado descendente (top-down), y por eso suelen afrontar la descomposicin como una simple cuestin de descomposicin algortmica, en la que cada mdulo del sistema representa un paso importante de algn proceso global. Descomposicin Orientada a Objetos. En esta descomposicin, se ve el mundo como un conjunto de agentes autnomos que colaboran para llevar a cabo algn comportamiento de nivel superior. Cada objeto en esta solucin contiene su propio comportamiento nico, y cada uno modela a algn objeto del mundo real. Desde esta perspectiva, un objeto no es ms que una entidad tangible que muestra un comportamiento bien definido. Los objetos hacen cosas, y se les pide a ellos que realicen lo que hacen envindoles mensajes. Puesto que esta descomposicin est basada en objetos y no en algoritmos, se le llama descomposicin orientada a objetos.
2. El Modelo Orientado a Objetos

La tecnologa orientada a objetos se apoya en los slidos fundamentos de la ingeniera, cuyos elementos reciben el nombre global de modelo de objetos. El modelo de objetos abarca los principios de abstraccin, encapsulacin, modularidad, jerarqua, tipos, concurrencia, y persistencia. Ninguno de estos principios es nuevo por s mismo. Lo importante del modelo de objetos es el hecho de conjugar todos estos elementos de forma sinrgica. Queda claro que el diseo orientado a objetos es fundamentalmente diferente a los enfoques de diseo estructurado tradicionales: requiere un modo distinto de pensar acerca de la descomposicin, y produce arquitecturas de software muy alejadas del dominio de la cultura del diseo estructurado. Estas diferencias surgen del hecho de que los mtodos de diseo estructurado se basan en la programacin estructurada, mientras que el diseo orientado a objetos se basa en la programacin orientada a objetos.
La Evolucin del Modelo de Objetos

La mayora de los nuevos sistemas de software de dimensin industrial son ms grandes y ms complejos que sus predecesores de pocos aos antes. Este crecimiento de la complejidad ha promovido una cantidad significativa de investigacin aplicada til en ingeniera del software, particularmente en lo referente a descomposicin, abstraccin y jerarqua. El desarrollo de lenguajes de programacin ms expresivos ha completado estos avances. La tendencia ha sido un desplazamiento desde los lenguajes que dicen al computador qu hacer (lenguajes imperativos), hacia los lenguajes que describen las abstracciones clave en el domino del problema (lenguajes declarativos). Wegner ha clasificado algunos de los lenguajes de programacin de alto nivel ms populares en generaciones, dispuestas de acuerdo con las caractersticas que tales lenguajes fueron pioneros en presentar:
Lenguajes de Primera Generacin (1954-1958) FORTRAN I ALGOL 58 Flowmatic IPL V Expresiones matemticas. Expresiones matemticas. Expresiones matemticas. Expresiones matemticas.
Lenguajes de Segunda Generacin (1959-1961) FORTRAN II ALGOL 60 COBOL Lisp Subrutinas, compilacin separada. Estructura en bloques, tipos de datos. Descripcin de datos, manejo de archivos. Procesamiento de listas, punteros, recoleccin de basura.
Lenguajes de Tercera Generacin (1962-1970) PL/1 ALGOL 68 Pascal Simula FORTRAN + ALGOL + COBOL. Sucesor riguroso del ALGOL 60. Sucesor sencillo del ALGOL 60. Clases, abstraccin de datos.
El Hueco Generacional (1970-1980) Se inventaron muchos lenguajes diferentes pero pocos perduraron.
En generaciones sucesivas, el tipo de mecanismo de abstraccin que admita cada lenguaje fue cambiando. Los lenguajes de la primera generacin se utilizaron principalmente para aplicaciones cientficas y de ingeniera, y el vocabulario de estos dominios de problema fue matemtico casi por completo. As, los lenguajes como FORTRAN I se desarrollaron para que el programador pudiera escribir frmulas matemticas, liberndole de esta forma de algunas de las complicaciones del lenguaje ensamblador o del lenguaje mquina. Esta primera generacin de lenguajes de alto nivel represent por lo tanto un paso de acercamiento al espacio del problema, y un paso de alejamiento de la mquina que haba debajo. Entre los lenguajes de segunda generacin, el nfasis se puso en las abstracciones algortmicas. Por esta poca, las mquinas eran cada vez ms y ms potentes, y el abaratamiento en la industria de las computadoras signific que poda automatizarse una mayor variedad de problemas, especialmente para aplicaciones comerciales. En este momento, lo principal era decirle a la mquina lo que deba de hacer: lee primero esta fichas personales, ordnales despus, y a continuacin imprime este informe. Una vez ms, esta nueva generacin de lenguajes de alto nivel acercaba a los desarrolladores un paso hacia el espacio del problema y los alejaba de la mquina subyacente. A finales de los sesenta, especialmente con la llegada de los transistores y la tecnologa de circuitos integrados, el coste del hardware de las computadoras haba cado de forma dramtica, pero su capacidad de procesamiento haba crecido casi exponencialmente. Ahora podan resolverse problemas mayores, pero eso exiga la manipulacin de ms tipos de datos. As, los lenguajes como ALGOL 60 y posteriormente Pascal evolucionaron soportando abstraccin de datos. El programador poda describir el significado de clases de datos relacionadas entre s (su tipo) y permitir que el lenguaje de programacin apoyase estas decisiones de diseo. Esta generacin de lenguajes acerc de nuevo el software un paso hacia el dominio del problema, y lo alej otro paso de la mquina. Los setenta ofrecieron un frenes de actividad investigadora en materia de lenguajes de programacin, con el resultado de la creacin de literalmente dos millares de diferentes lenguajes con sus dialectos. En gran medida, la tendencia a escribir programas ms y ms grandes puso de manifiesto las deficiencias de los lenguajes ms antiguos; as, se desarrollaron muchos nuevos mecanismos lingsticos para superar estas limitaciones. Slo algunos de estos lenguajes han sobrevivido (acaso ha visto libros recientes sobre los lenguajes Fred, Chaos o Tranquil?); sin embargo, muchos de los conceptos que introdujeron encontraron su camino en sucesores de los lenguajes anteriores. As, hoy en da existen Smalltalk (un sucesor revolucionario de Simula), Ada (un sucesor del ALGOL 68 y Pascal, con contribuciones de Simula, Alphard y CLU), CLOS (que surgi del Lisp, LOOPS y Flavors), C++ (derivado de un matrimonio entre C y Simula), y Eiffel (derivado de Simula y Ada).
Lo que resulta de mayor inters para nosotros es la clase de lenguajes que suelen llamarse basados en objetos y orientados a objetos. Los lenguajes de programacin basados en y orientados a objetos son los que mejor soportan la descomposicin orientada a objetos del software.
Elementos del Modelo de Objetos

Abstraccin 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 de un objeto, y, por tanto, sirve para separar el comportamiento esencial de un objeto de su implantacin. Abelson y Sussman llaman a sta divisin comportamiento/implementacin una barrera de abstraccin que se consigue aplicando el principio de mnimo compromiso, mediante el cual la interfaz de un objeto muestra su comportamiento esencial, y nada ms. Se puede citar un principio adicional que se ha denominado el principio de mnima sorpresa, por el cual una abstraccin captura el comportamiento completo de algn objeto, ni ms ni menos, y no ofrece sorpresas o efectos laterales que lleguen ms all del mbito de la abstraccin. Encapsulamiento La abstraccin de un objeto debera preceder a las decisiones sobre su implementacin. Una vez que se ha seleccionado una implementacin, debe tratarse como un secreto de la abstraccin, oculto para la mayora de los clientes. Como sugiere sabiamente Ingalls, 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. La abstraccin y el encapsulamiento son conceptos complementarios: la abstraccin se centra en el comportamiento observable de un objeto, mientras el encapsulamiento se centra en la implementacin que da lugar a este comportamiento. El encapsulamiento se consigue a menudo mediante la ocultamiento de informacin, que es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus caractersticas esenciales; tpicamente, la estructura de un objeto est oculta, as como la implementacin de sus mtodos.
10
Modularidad El acto de fragmentar un programa en componentes individuales puede reducir su complejidad en algn grado... Aunque la fragmentacin de programas es til por sta razn, una justificacin ms poderosa para esta fragmentacin es que crea una serie de fronteras bien definidas y documentadas dentro del programa. Estas fronteras o interfaces, tienen un incalculable valor cara a la comprensin del programa. En algunos lenguajes, como Smalltalk, no existe el concepto de mdulo, y as la clase es la nica unidad fsica de descomposicin. En muchos otros, incluyendo Object Pascal, C++, CLOS y Ada, el mdulo es una construccin adicional del lenguaje y, por lo tanto, justifica un conjunto separado de decisiones de diseo. en estos lenguajes, las clases y los objetos forman la estructura lgica de un sistema; si se sitan estas abstracciones en mdulos para producir la arquitectura fsica del sistema. Especialmente para aplicaciones ms grandes, en las que puede haber varios cientos de clases, el uso de mdulos es esencial para ayudar a manejar la complejidad. Jerarqua Frecuentemente un conjunto de abstracciones forma una jerarqua, y la identificacin de esas jerarquas en el diseo simplifica en gran medida la comprensin del problema. Se define la jerarqua como sigue: La jerarqua es una clasificacin u ordenacin de abstracciones. Las dos jerarquas ms importantes en un sistema complejo son su estructura de clases (la jerarqua tipo de) y su estructura de objetos (la jerarqua parte de). Herencia. La herencia es el jerarqua tipo de ms importante y, como se ha visto anteriormente, es un elemento esencial de 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 que se denomina herencia simple o herencia mltiple, respectivamente). La herencia representa as una jerarqua de abstracciones, en la que una subclase hereda de una o ms superclases. Tpicamente, una subclase aumenta o redefine la estructura y el comportamiento de sus superclases. Agregacin. Mientras estas jerarquas tipo de denotan relaciones de generalizacin/especializacin, las jerarquas parte de describen relaciones de agregacin. En trminos de su jerarqua tipo de, una abstraccin de alto nivel est generalizada, y una abstraccin de bajo nivel est especializada. Por lo tanto se dice que una clase Planta est a nivel ms alto de abstraccin que una clase Flor. En trminos de su jerarqua parte de, una clase est a nivel ms alto de abstraccin que cualquiera de las clases que constituyen su implementacin. Tipos (Tipificacin)
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, a lo ms, pueden intercambiarse slo de formas muy restringidas. Los tipos permiten expresar las abstracciones de manera que el lenguaje de programacin en el que se implementan puede utilizarse para apoyar las decisiones de diseo. Wegner observa que este tipo de apoyo o refuerzo es esencial para la programacin a gran escala. Se considera esto un elemento menor, debido a que un lenguaje puede ser fuertemente tipificado, dbilmente tipificado, o incluso sin tipos, y an as ser llamado basado en objetos u orientado a objetos Concurrencia La programacin orientada a objetos 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 basado en diseo orientado a objetos, se puede conceptualizar el mundo como un conjunto de objetos cooperativos, algunos de los cuales son activos y sirven as como centros de actividad independiente. Partiendo de esta concepcin, se define la concurrencia como sigue: La concurrencia es la propiedad que distingue un objeto activo de uno que no est activo. Persistencia La persistencia es la propiedad de un objeto por la que su existencia trasciende el tiempo (es 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).
Aplicacin del Modelo de Objetos

Puede que el diseo orientado a objetos sea el nico mtodo entre los disponibles hoy en da, que puede emplearse para atacar la complejidad innata en muchos sistemas grandes. Siendo justos, sin embargo, el uso del diseo orientado a objetos puede no ser aconsejable en algunos dominios, no por razones tcnicas, sino por razones no tcnicas, como la falta de personal con entrenamiento adecuado o buenos entornos de desarrollo.
3. Objetos y Clases: Naturaleza y Relaciones

Se ha definido informalmente un objeto como una entidad tangible que exhibe algn comportamiento bien definido. Desde la perspectiva de la cognicin humana, un objeto es cualquiera de las siguientes cosas:
12
Una cosa tangible y/o visible. Algo que puede comprenderse intelectualmente. Algo hacia lo que se dirige un pensamiento o accin. Se aade a la definicin informal la idea de que un objeto modela 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 en 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 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
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 inherente o distintiva, un rasgo o cualidad que contribuye a hacer que un objeto sea nicamente ese objeto y no otro. Todas las propiedades tienen algn valor. Este valor puede ser una mera cantidad, o puede denotar a otro objeto.
Comportamiento
Ningn objeto existe de forma aislada. En vez de eso, los objetos reciben acciones, y ellos mismos actan sobre otros objetos. As puede decirse que El comportamiento es cmo acta y reacciona un objeto, en trminos de sus cambios de estado y paso de mensajes. En otras palabras, el comportamiento de un objeto 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. El estado de un objeto representa los resultados acumulados de su comportamiento.
Identidad
13
La identidad es aquella propiedad de un objeto que lo distingue de todos los dems objetos. La mayora de los lenguajes de programacin y de bases de datos utilizan nombres de variables para distinguir objetos temporales, mezclando la posibilidad de acceder a ellos con su identidad. La mayora de los sistemas de bases de datos utilizan claves de identificacin para distinguir objetos persistentes, mezclando el valor de un dato con la identidad. El fracaso en reconocer la diferencia entre el nombre de un objeto y el objeto en s mismo es fuente de muchos tipos de errores en la programacin orientada a objetos.
Relaciones entre Objetos

Un objeto por s mismo es muy poco interesante. Los objetos contribuyen al comportamiento de un sistema colaborando con otros. 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. se ha encontrado que hay dos tipos de jerarquas de objetos de inters especial en el anlisis y diseo orientados a objetos, a saber: Enlaces (Using relationships) Agregacin (Containing relationships)
La Naturaleza de una Clase

Los conceptos de clase y objeto estn estrechamente entretejidos, porque no puede hablarse de un objeto sin atencin a su clase. Sin embargo, existen diferencias importantes entre ambos trminos. Mientras que un objeto es una entidad concreta que existe en el tiempo y el espacio, una clase representa slo una abstraccin, como si dijsemos, la esencia de un objeto. En trminos corrientes, se puede definir una clase como un grupo, conjunto o tipo marcado por atributos comunes o un atributo comn; una divisin, distincin o clasificacin de grupos basada en la calidad, grado de competencia o condicin. En el contexto del anlisis y diseo orientado a objetos, se define una clase como sigue: 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. Qu no es una clase? Un objeto no es una clase, aunque, curiosamente, como se describir despus, una clase puede ser un objeto. Los objetos que no comparten estructura y comportamiento similares no pueden agruparse en una clase porque, por definicin, no estn relacionados entre s a no ser por su naturaleza general como objetos.
14
Relaciones entre Clases

Se establecen relaciones entre dos clases por una de dos razones. primero, una relacin entre clases podra indicar algn tipo de comparticin. Segundo, una relacin entre clases podra indicar algn tipo de conexin semntica. Existen tres tipos bsicos de relaciones entre clases. La primera es la generalizacin/especializacin, que denota una relacin tipo de. Por ejemplo una rosa es un tipo de flor, lo que quiere decir que una rosa es una subclase especializada de una clase ms general, la de las flores. La segunda es la relacin todo/parte (agregacin), que denota una relacin parte de. As, un ptalo no es un tipo de flor; es una parte de una flor. La tercera es la asociacin, que denota alguna dependencia semntica entre clases de otro modo independientes. Como ejemplo, las rosas y la velas son clases claramente independientes, pero ambas representan cosas que podran utilizarse para decorar la mesa de una cena. En los lenguajes de programacin han evolucionado varios enfoques comunes para plasmar relaciones de generalizacin/especializacin, todo/parte (agregacin) y asociacin. Especficamente, la mayora de los lenguajes orientados a objetos ofrecen soporte directo para alguna combinacin de las siguientes relaciones: Relaciones de herencia Relaciones de uso Relaciones de instanciacin Relaciones de metaclases
Relaciones entre Clases y Objetos

Las relaciones y los objetos son conceptos separados pero en ntima relacin. Concretamente, todo objeto es instancia de alguna clase, y toda clase tiene cero o ms instancias. Para prcticamente todas los aplicaciones, las clases son estticas; sin embargo, su existencia, semntica y significado estn determinados antes de la ejecucin de un programa. Anlogamente, la clase de la mayora de los objetos es esttica, lo que significa que una vez que se crea un objeto, su clase est determinada. En un contraste agudo, sin embargo, los objetos se crean y destruyen tpicamente a un ritmo trepidante durante el tiempo de vida de una aplicacin.
El Rol de Clases y Objetos en Anlisis y Diseo

Durante el anlisis y las primeras etapas del 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 clave del problema, y se denomina a esas estructuras cooperativas los mecanismos de la implementacin. Durante estas fases del desarrollo, el inters principal del desarrollador debe 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 implementacin, 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.
Relaciones de herencia entre clases

Dicho simplemente, herencia es una relacin entre clases en donde una clase comparte la estructura o comportamiento definidos en una (herencia simple) o ms clases (herencia mltiple). La clase de la cual se heredan otras clases se denomina superclase. Y la clase que se hereda de una o ms clases se denomina subclase.
Relaciones de uso entre clases

Existen dos diferentes enfoques de relaciones de uso: una interfaz de clase puede usar otra clase (como en el ejemplo anterior), o una implementacin de clase puede usar otra clase. En el primer caso, la clase usada tiene que ser visible para cualquier cliente. En el segundo caso, la clase utilizada est oculta como parte del secreto de la clase en uso.
Relaciones de instanciacin entre clases

Mediante un lenguaje fuertemente tipificado, es deseable aprovechar cada oportunidad para aplicar tipos a fin de capturar y as reforzar nuestras decisiones de diseo. Por ejemplo, supngase que se desea elaborar la abstraccin de una tienda departamental, en la cuales tienen diez cajas registradoras. En Object Pascal y ADA tendramos que definir un tipo entero de dominio especfico, cuyos valores estuviesen comprendidos en el rango de 1 a 10, representando una fila especfica para pagar. A un simple nivel de abstraccin de alto nivel podramos crear una clase conjunto, para representar colecciones de empleados que pueden ser asignados a una caja. Sin embargo, nuestra comprensin del problema nos indica que tales colecciones slo contendrn nicamente empleados, y no otros objetos, tales como clientes o, peor an, legumbres. Idealmente quisiramos definir nuestra clase conjunto, de tal forma que podamos determinar el tipo de objetos permitidos en dicho conjunto y entonces dejar que las reglas para tipos en nuestro lenguaje nos prohiban hacerlo de otra forma.
16
Un conjunto es un ejemplo de una clase contenedora, la cual es una clase cuyas instancias son colecciones de otros objetos. Las clases contenedoras pueden denotar colecciones homogneas, indicando que todos los objetos en la coleccin son de la misma clase, o bien pueden representar colecciones heterogneas, en las cuales los objetos pueden ser de diferentes clases a pesar de que deben todas compartir alguna superclase comn.
Metaclases
Las tres formas de relaciones de clases discutidas anteriormente (herencia, uso, e instanciacin) cubren en su conjunto todas las formas importantes de relaciones de clases que la mayora de los desarrolladores necesitan. Sin embargo, considerando slo un paso ms all la idea del modelo de objetos, descubriremos otra posible forma de relacin. Se ha dicho que cada objeto es una instancia de alguna clase. Qu pasara si se trata a una clase como un objeto que pudiera ser manipulado? Para hacer esto, debemos preguntar, cul es la clase de una clase? La respuesta es simple, una metaclase. Dicho de otra manera, una metaclase es una clase cuyas instancias son clases.
17
4. Metodologa de Booch
Anlisis Anlisis
Diseo Diseo
Evolucin Evolucin
Mantenimiento Mantenimiento
Figura: Diseo Orientado a Objetos en el Ciclo de Vida del Desarrollo de Software. La Figura Diseo Orientado a Objetos en el Ciclo de Vida del Desarrollo de Software muestra el ciclo de vida para el desarrollo de un diseo orientado a objetos. Aqu se observa que el diseo no es una fase monoltica aislada; sino slo un paso dentro del proceso incremental del desarrollo iterativo de un sistema, cuyas etapas se retroalimentan.
Anlisis
Las Actividades del Anlisis. El Anlisis es la fase que rene por primera a los usuarios y a los desarrolladores de un sistema, a travs de un vocabulario comn surgido del dominio del problema. El propsito del anlisis es proporcionar una descripcin de un problema. La descripcin debe ser completa, consistente, legible y disponible a las diversas partes interesadas y, comprobable en la realidad. Los productos del anlisis se utilizan a menudo para articular las funciones de un sistema. As pues, funcin, no se refiere a una abstraccin algortmica. Ms bien, en el contexto de anlisis de requerimientos, una funcin denota un nico comportamiento claro y demostrable.
18
Diseo
Iniciando el Proceso de Diseo. Cundo se comienza a disear? Realmente, el diseo puede comenzar tan pronto como se tenga algn modelo formal o informal (posiblemente incompleto) del problema a ser resuelto. Si se comienza a el diseo muy pronto, probablemente no se sepa lo suficiente del problema para realizar cambios de diseo inteligentes. Pero s el diseo se comienza muy tarde, se corre el riesgo de desperdiciar recursos en el anlisis al hacerlo muy detalladamente, lo cual puede abrumar al diseador con un torrente de detalles innecesarios extras. Por estas razones, se sugiere la estrategia de analizar un poco, disear un poco. De esta manera, cada intento en el diseo puede ayudar a enfocar el proceso de anlisis hacia aspectos del sistema que son importantes para la elaboracin de una solucin. Disense nicamente las abstracciones clave y lo mecanismos importantes, a fin de obtener un bosquejo que sea suficiente para la implementacin, y djense para fases posteriores los aspectos de la solucin que tengan poco o nada que ver con en el comportamiento observable del sistema. Divdase un gran problema en subproblemas, de tal forma que los especialistas en un dominio particular puedan llevar a cabo el proceso de diseo. Dentro de un gran sistema, se deben identificar los aspectos que sean claramente problemas de red, o problemas de bases de datos o problemas de interfaz de usuarios. Por regla general se detiene el proceso de diseo cuando las abstracciones clave son lo suficientemente simples para no requerir mayor descomposicin (pero que pueden ser compuestas a partir de componentes de software reusables ya existentes).
Evolucin
Las actividades de Evolucin. La evolucin de un sistema en el ciclo de vida del desarrollo de software orientado a objetos combina los aspectos tradicionales de codificacin, prueba e integracin. El resultado de un diseo orientado a objetos, es que nunca se dar un evento big-bang de la integracin del sistema. En vez de ello, el proceso de desarrollo resulta en la produccin incremental de una serie de prototipos que eventualmente evolucionan en la implementacin final. Tipos de cambios evolutivos. En la prctica, pueden esperarse las siguientes formas de cambios para un diseo, durante la evolucin de un sistema: Adicin de una nueva clase Cambio de la implementacin de una clase Cambio de la representacin de una clase Reorganizacin de la estructura de una clase Cambio de la interfaz de una clase
Modificacin
Un programa que se usa en un entorno del mundo real necesariamente ha de cambiar o se volver cada vez menos til (ley del cambio continuo). A medida que cambia un programa en evolucin, su estructura se vuelve ms compleja a pesar de los esfuerzos activos que se realicen para evitar este fenmeno (ley de la complejidad creciente).
20
5. Notacin de Booch
Disear no es el acto de dibujar un diagrama; un diagrama simplemente captura un diseo. Sin embargo, es importante disponer de una notacin expresiva y bien definida. En primer lugar, una notacin estndar hace posible que una persona pueda formular un diseo y que despus lo comunique. Es imposible capturar todos los sutiles detalles de un sistema complejo de software en un solo tipo de diagrama. Se debe entender tanto la estructura, como la funcin de los objetos involucrados. Y comprender la estructura taxonmica de las clases, los mecanismos de herencia usados, el comportamiento individual de los objetos y el comportamiento dinmico del sistema como un todo.
Diagramas de Clases
Un diagrama de clase se utiliza para mostrar la existencia de clases y sus relaciones en el diseo lgico de un sistema. Un solo diagrama de clase representa toda o parte de la estructura de clases de un sistema. Usualmente, para un pequeo sistema, un solo diagrama de clases es suficiente, pero en el diseo de la mayora de los sistemas se requiere una serie de dichos diagramas, para documentar su estructura de clases. Los tres elementos ms importantes de la estructura de clases son las clases, las relaciones de clases y las utileras de clases (para lenguajes que soportan la declaracin de subprogramas libres). Clases. La Figura Icono para una Clase muestra el icono que utilizamos para representar una clase en un diagrama de clases. Por razones histricas, su forma es la de una mancha amorfa; que algunos llaman nube. Este icono representa una abstraccin con algunos lmites frgiles. Las lneas punteadas que forman el contorno del icono indican que los clientes generalmente operan slo sobre instancias de una clase, y no en la clase misma. El nombre de la clase es requerido y se coloca dentro de la nube.
name
Figura: Icono para una Clase
21
x x
label label label
x uso (para interfaz) x uso (para implementacin) instancia (tipo compatible) instancia (nuevo tipo) herencia (tipo compatible) herencia (nuevo tipo) metaclase indefinada 0 cero 1 uno * cero o ms + uno o ms ? cero o ms n n
label + label label + label
label
Figura: Iconos para Relaciones de Clases y Cardinalidad Relaciones de Clases. Se puede obtener una primera conceptualizacin de una jerarqua de clases mediante la inclusin de una relacin indefinida. Los iconos para cada forma de relacin de clase se enlistan en la figura Iconos para Relaciones de Clases y Cardinalidad. Cada relacin puede incluir una etiqueta (que puede omitirse) para documentar el nombre o rol de la relacin. Si se utiliza una etiqueta el smbolo debe aplicarse para indicar la direccin en que debe ser leda la etiqueta. Una relacin de uso es indicada por una lnea doble con un crculo que se coloca en un extremo para designar la clase que utiliza los recursos de otra. Por ejemplo, si utilizamos una lnea doble para indicar una relacin entre clases A y B y despus colocar un crculo cerca de la clase A, indicamos que la interfaz de A utiliza los recursos de la clase B. Si utilizamos un crculo relleno estamos indicando entonces que la implementacin de A utiliza los recursos de la clase B. Durante las primeras etapas del diseo, usualmente es suficiente mostrar slo las relaciones de interfaz. Un desarrollador puede considerar adems mostrar las relaciones de implementacin , slo al momento de tomar las decisiones de implementacin. En alguna circunstancias, especialmente en el modelado de las clases que forman parte de una base de datos, resulta de gran utilidad mostrar la cardinalidad entre las clases que se utilizan una con otra. La figura Iconos para Relaciones de Clases y Cardinalidad tambin
22
ilustra los iconos que se utilizan para expresar cardinalidad, que estn derivados de los smbolos utilizados para escribir expresiones regulares para la herramienta greep de Unix. Por ejemplo, si entre las clases A y B, colocamos el smbolo 1 cerca de A y el smbolo + cerca de B, significa que para cada instancia de A, pudiramos tener una o ms instancias de B, y que para cada instancia de B, existe exactamente una instancia de A. Si es necesario, podemos tambin formar aserciones de cardinalidad ms complicadas usando operaciones de relacin =, <>, <, >, <=, y >=. Una relacin de clase en donde una clase A instanca a una clase B se indica mediante una lnea punteada, con una flecha apuntando a la clase que se est instanciando (en este caso, B). Esta forma de relacin es significativa nicamente para lenguajes que soportan alguna forma de clases parametrizadas o mecanismos genricos. Una relacin de herencia se parece a una relacin de instanciacin, pero en ella se utiliza una lnea continua. En la prctica, las relaciones de herencia son las ms comunes, seguidas por las relaciones de uso. Por convencin, generalmente no se muestra la herencia de una clase desde la clase base ms alta, tal como Tobject de Object Pascal, a menos que exista una razn justificable para hacerlo. Las clases que aparecen solas son usualmente consideradas como ancestros directos de esta clase base. Si las instancias de la subclase no son de tipo compatible con las instancias de la superclase (o, en trminos de Ada, si se tiene un tipo derivado), entonces se coloca una lnea perpendicular a travs de la lnea de relacin, opuesta a la flecha. El icono para una relacin de metaclase utiliza una lnea gris. En algunos lenguajes, tal como Smalltalk, cada clase tiene una metaclase, pero generalmente se elige documentar slo aquellas metaclases que adicionan su propio comportamiento de dominio especfico. Una relacin indefinida, representada por una lnea gris punteada sin punta de flecha, es utilizada por el diseador para indicar que existe alguna forma de relacin de clase, pero que la decisin acerca de la forma precisa de dicha relacin ser tomada posteriormente. Utileras de Clases. El icono para una utilera de clase se ilustra en la figura Icono para una Utilera de Clase. Es similar al icono de una clase, pero se distingue por que tiene una sombra. El icono de utilera de clase representa tambin, un subprograma libre o una coleccin de stos. Si el lenguaje de implementacin no permite estas construcciones, el icono puede ser omitido. El nombre de la utiliera de clase es requerido, y se coloca dentro de la nube, si el nombre es particularmente largo, tambin puede ser elidido, o el icono puede amplificarse. Cada nombre de utilera de clase debe ser nico dentro de la categora de clase. Pueden expresarse relaciones de clase que involucren utileras de clase, pero por lo general, solamente se aplican las relaciones de uso e instanciacin.
name
23
Figura: Icono para una Utilera de Clase Categoras de Clases. Un tpico diagrama de clases puede contener de una a varias docenas de clases en cualquier parte. El intentar poner todas estas clases en un slo diagrama puede resultar abrumador. Para resolver este problema, se requieren medios para organizar las clases en porciones significativas, lo que conduce a la idea de categora de clase. Cada categora de clase denota otro diagrama de clases, de ese modo, si se selecciona alguna de las categoras de clase desde este diagrama de mas alto nivel, y se observa a detalle su implementacin, posiblemente se encontrar otro diagrama de clases consistente de clases, relaciones y utileras de clases, o para problemas mucho muy grandes, otro diagrama de clases conteniendo otras categoras de clase, que en su momento representan otros diagramas de objetos. Visibilidad de la Categora de Clase. Dado que una categora de clase representa el nombre de un espacio encapsulado, algunas de las entidades que incluye pueden ser visibles fuera de la categora de clase, y otras pueden ser importadas desde otras categoras de clase visibles. Para designar la visibilidad de una entidad nombrada, contenida en una categora de clase, pueden utilizarse iconos especiales. Un nombre sin adorno representa una entidad que es privada a la categora clase; que no debe de ser referenciada por nada fuera de dicha categora.
Nombre: Documentacin: Visibilidad: Cardinalidad: Jerarqua: Superclase: Metaclase: Parmetros Genricos: Interfaz | Implementacin (Pblica/Protegida/Privada): Usos: Campos: Operaciones: Mquina de estado finito: Concurrencia: Complejidad del espacio: Persistencia: identificador texto exportada / privada / importada 0/1/n nombre de clase lista de parmetros lista de nombres de clases lista de declaraciones de campos lista de declaraciones de operaciones diagrama de transicin de estados secuencial / bloqueada / activa texto esttica / dinmica
Figura: Plantilla para una Clase. Una plantilla de clase representa todos los aspectos importantes de una clase. En la prctica, no puede esperarse que un desarrollador complete todo su contenido, a menos que, por supuesto, sea importante mostrar este nivel de detalle.
24
Tanto las plantillas de clase como las de utileras de clase, pueden incluir listas de operaciones. Para un diseo menos riguroso, basta simplemente establecer el nombre de la operacin, sus parmetros y su significado (utilizando un texto de forma libre).
Estados y Transiciones de Estado

Un diagrama de clase no indica por si mismo cmo se comportan las instancias de clases individuales. El comportamiento dinmico asociado con ciertas clases, se documenta mejor a travs del uso de diagramas de transicin de estados. Estos diagramas muestran el espacio de estado de una clase, los eventos que causan la transicin de un estado a otro, y las acciones que resultan de un cambio de estado. Los diagramas de transicin de estados estn as ntimamente relacionados a otras partes de la notacin: una plantilla de clase puede contener un diagrama de transicin de estados, y las acciones descritas en un diagrama de transicin de estado particular puede apuntar a otros diagramas de objetos. Tpicamente, los diagramas de transicin de estados asociados con una clase no tienen ni estados de inicio ni de fin: cuando un objeto es creado, entra a un estado dependiendo del contexto que lo rodea, y cuando el objeto es destruido, los estados asociados se transforman. Ejemplo de un diagrama de transicin de estado. La Figura Diagrama de transicin de estado del sistema de jardines hidropnicos muestra un ejemplo de un diagrama de transicin de estado para la clase EnviromenttalController para un sistema de jardines hidropnicos.
25
TemperatureChange
TemperatureChange
Plant
StartGrowingCycle
Day
Sunset Sunrise
Night
StopGrowingCycle
StopGrowingCycle
Harvest
Figura: Diagrama de transicin de estado del sistema de jardines hidropnicos.
Diagramas de Objetos
Un diagrama de objetos es utilizado para mostrar la existencia de objetos y sus relaciones en el diseo lgico de un sistema. Un diagrama de objetos representa toda o parte de la estructura de objetos de un sistema; tpicamente el diseo de un sistema requiere un conjunto de diagramas de objetos. El propsito de cada diagrama de objetos es ilustrar la semntica de los mecanismos clave en el diseo lgico. Por ello, se utilizan los diagramas de objetos para capturar la semntica dinmica de operaciones y mquinas de estado finito. Un diagrama de objetos puede tambin representar la captura de un momento en un lapso de tiempo de un evento de otro modo transitorio. Existen relaciones importante entre los diagramas de clases y los diagramas de objetos, paralelas a la interaccin entre clases y objetos. Especficamente, cada objeto en un diagrama de objetos denota alguna instancia (especfica o arbitraria) de una clase. Adicionalmente las operaciones utilizadas en un diagrama de objetos deben ser consistentes con las operaciones definidas en las clases asociadas.
26
Diagramas de Mdulos
Un diagrama de mdulos se utiliza para mostrar la asignacin de objetos y clases a mdulos en el diseo fsico de un sistema; un diagrama de mdulos representa toda o parte de la arquitectura de mdulos de un sistema
27
Gardening Control
PlanningControls
Environmnet Controls NutrientControls
GreenhouseSensors GreenhouseActuators
Figura: Diagrama de mdulo de un sistema de jardines hidropnicos
28
Diagramas de Procesos
Muchos de los grandes sistemas requieren del diseo de ms de un nico programa monoltico; algunas veces se deben disear sistemas compuestos de mltiples programas, ejecutndose sobre una coleccin distribuida de computadoras, los que requieren decisiones de diseo muy diferentes a aquellas asociadas con la identificacin de clases y objetos. Por esta razn , se utilizan diagramas de proceso para visualizar y entonces razonar sobre el problema de la asignacin de procesos a los procesadores en el diseo fsico de un sistema. Un diagrama de proceso representa toda o parte de la arquitectura de procesos de un sistema, un diseo incluye tpicamente un slo diagrama, aunque algunos sistemas particularmente complejos, pueden requerir de varios. Conexiones. Los procesadores y los dispositivos deben comunicarse. Es posible establecer conexiones de dispositivo a procesador, de un procesador a procesador, o de un dispositivo a dispositivo. Una conexin usualmente representa algn enlace de hardware directo (tal como un cable RS232, una conexin Ethernet, o un cable de fibra ptica) aunque tambin puede representar enlaces menos directos, tales como los enlaces satelitales. Usualmente se considera a las comunicaciones como bidireccionales, aunque si una conexin particular es unidireccional, se puede adicionar una flecha para indicar la direccin. Cada conexin puede incluir una etiqueta (que se puede omitir), para documentar el nombre de la conexin.
29
6. El Proceso de Desarrollo en la Metodologa de Booch

El proceso de diseo orientado a objetos es la anttesis del enfoque de un libro de cocina. Como se ver el diseo orientado a objetos es ms que un proceso iterativo incremental, en el cual los productos del diseo se desarrollan poco a poco con el transcurso del tiempo. La experiencia indica que el diseo orientado a objetos no es estrictamente top-down ni totalmente bottom-up. En vez de ello, los sistemas complejos bien estructurados se crean bajo el enfoque de round-trip gestalt design. Este estilo enfatiza el diseo iterativo e incremental de un sistema a travs del refinamiento de diferentes, aunque consistentes, vistas lgicas y fsicas del sistema como un todo. Se sugiere entonces, que el enfoque de round-trip gestalt design es la base del proceso de diseo orientado a objetos. El diseo orientado a objetos no es un proceso que comienza con una especificacin de requerimientos, y que termina con un bosquejo para la implementacin, requiriendo de un milagro en alguna parte de entre ambas fases. El proceso de diseo orientado a objetos generalmente sigue el siguiente orden de eventos: Identificar las clases y objetos en un nivel de abstraccin dado. Identificar la semntica de dichas clases y objetos. Identificar las relaciones entre estas clases y objetos. Implementar estas clases y objetos.
Identificacin de Clases y Objetos

Actividades El primer paso involucra dos actividades: el descubrimiento de las abstracciones clave en el espacio del problema (las clases y objetos significativos) y la invencin de los mecanismos importantes que proveern el comportamiento requerido para los objetos que interactuarn para llevar a acabo una cierta funcin. A travs del estudio de los requerimientos del problema y/o a travs de discusiones con los expertos en el dominio, el desarrollador debe aprender el vocabulario del dominio de un problema. Los elementos tangibles en el dominio del problema, los roles que desempean, y los eventos que pueden ocurrir forman las clases y los objetos candidatos de un diseo, al ms alto nivel de abstraccin.
30
Productos En un extremo del espectro, puede ser suficiente el simplemente enlistar los nombres de las clases y objetos significativos, usando nombres adecuados que impliquen su semntica. Llamaremos a esto simplemente enlistar cosas. Algunas de las cosas en esta lista pueden resultar ser clases, algunas objetos y otras simplemente atributos de objetos. En el otro extremo del espectro, se puede especificar formalmente el significado de estas abstracciones y mecanismos, escribiendo las apropiadas plantillas de clases y objetos.
Identificacin de la Semntica de las Clases y Objetos

Actividades El segundo paso involucra una actividad bsica: establecer el significado de las clases y objetos identificados en el paso anterior. Aqu, el desarrollador, acta como un ente desligado y ajeno, observando cada clase desde la perspectiva de su interfaz, a fin de identificar las cosas que se pueden hacer a cada instancia de una clase y lo que un objeto puede hacer a otro. Encontrar clases y objetos es la parte fcil, pero decidir acerca del protocolo de cada objeto resulta difcil. Por esta razn, el proceso de diseo orientado a objetos se vuelve iterativo en este punto. Confeccionar el protocolo para un objeto dado, puede requerir de decisiones que cambien el significado de otro objeto. De forma general, la existencia de las abstracciones clave no cambia; nicamente cambian sus lmites. Un tcnica til para guiar estas actividades, involucra la elaboracin de un guin para cada objeto, el cual define su ciclo de vida desde su creacin hasta su destruccin, incluyendo sus comportamientos caractersticos. Productos Los productos de este paso reflejan la naturaleza incremental del diseo orientado a objetos. Para documentar nuestras decisiones de diseo, considerando el significado de cada clase y objeto, generalmente se refinan las plantillas de cada clase y objetos diseados en el paso previo. Esto implica que se deben documentar todas las semnticas estticas y dinmicas de cada una de las abstracciones clave y de los mecanismos, lo mejor posible en este punto. Tambin se podran disear nuevos diagramas de objetos para documentar cualquier mecanismo que se haya inventado en esta etapa del proceso.
Identificacin de las Relaciones entre Clases y Objetos

Actividades El tercer paso constituye en gran parte una extensin de las actividades del anterior. Aqu, se establece exactamente cmo interctan las cosas dentro del sistema. De acuerdo con las abstracciones clave, esto significa que se deben establecer las relaciones de uso, de herencia y otras formas de relaciones entre las clases. Para los objetos implementacin, esto significa que se deben establecer la semnticas esttica y dinmica de cada mecanismo. Hay dos actividades relacionadas que obligan a refinar los primeros productos en un diseo. Primero, se deben descubrir patrones: patrones entre clases, que llevan a reorganizar y simplificar la estructura de clases del sistema, y patrones entre colecciones cooperativas de objetos, que llevan a generalizar los mecanismos ya considerados en el diseo. Esta parte del proceso de diseo, requiere de todas las habilidades creativas del diseador, los aciertos en esta parte, diferencian los buenos diseos de los malos. Segundo, se deben hacer decisiones de visibilidad: esto es, cmo una clase ve a otra, cmo se ven los objetos unos con otros, e igualmente importante, que clases y objetos no se ven entre s. Esto ayuda a efectuar inteligentes decisiones de empaquetamiento en el diseo de la arquitectura de mdulos del sistema. El descubrimiento de patrones y la toma de decisiones de visibilidad llevan tambin al refinamiento de los protocolos de varias clases de los pasos anteriores, de modo que finalizaremos con abstracciones y mecanismos comunes definidos en un solo sitio. Productos Los productos de esta etapa incluyen la conclusin de la mayora de los modelos lgicos del diseo. Aqu se refinan los diagramas de clase de los pasos anteriores, tomando en cuenta los patrones descubiertos y las decisiones de visibilidad efectuadas. Tambin se completarn de los diagramas de objetos que documentan los mecanismos esenciales en nuestra solucin. En la prctica este enfoque para crear tales diagramas es muy claro. Utilizando la notacin de las secciones anteriores, se dibujan primero los objetos que se sabe cooperan de cierta forma. Despus, se seleccionan pares de objetos y se pregunta si hay relaciones entre ellos. Si la respuesta es afirmativa, entonces se formulan las dos siguientes preguntas: cmo se relacionan estos objetos? y qu mensajes intercambian? Esto generalmente lleva a refinar el protocolo de las correspondientes clases, y este refinamiento a su vez puede conduce a la identificacin de nuevos patrones. Es por esto que el proceso de diseo orientado a objetos es iterativo.
Implementacin de Clases y Objetos

Actividades
32
El cuarto paso no es necesariamente el ltimo. Este paso involucra dos actividades: tomar decisiones de diseo concernientes a la representacin de las clases y objetos inventados y, la asignacin de clases y objetos a mdulos, y de programas a procesos. Este es el punto en el proceso de diseo en donde primero se efecta una observacin hacia dentro de cada clase y modulo, para decidir cmo ha de ser implementado su comportamiento. Aunque las abstracciones clave y mecanismos son triviales, es en este punto cuando se debe volver al primer paso y aplicar este proceso nuevamente, hasta la observacin interna de las clases y mdulos existentes. De esta forma, se repite el proceso de diseo, pero esta vez enfocndose en un nivel de abstraccin ms bajo. Significa esto que el diseo orientado a objetos es un proceso top-down? Todava la respuesta sigue siendo no exactamente. En la prctica, se disean primero las abstracciones clave y los mecanismos de ms alto nivel, involucrando aquellas clases y objetos que son parte directa del vocabulario del dominio del problema. Sin embargo, a cualquier nivel de diseo, frecuentemente se debe saltar hacia abstracciones clave y mecanismos de un nivel ms bajo, pues sirven como clases y objetos primitivos sobre los cuales se pueden componer clases y objetos de nivel ms alto. Esto nuevamente ilustra que el diseo orientado a objetos involucra un proceso de round-trip gestalt design. Productos En este paso del proceso de diseo, se establece la interfaz concreta de cada clase y objeto importante en un nivel dado de abstraccin. Los productos entonces, incluyen el refinamiento de la estructura de clases del sistema, y de forma particular la parte completa de implementacin de cada plantilla de clase importante. La misma forma de completitud se aplica a los diagramas de mdulos y si la arquitectura del sistema lo demanda, a los diagramas de procesos.
33
7. Metodologa OMT
El Modelado y Diseo Orientado a Objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que se han organizado tomando como base conceptos del mundo real. La construccin fundamental es el objeto que combina las estructuras de datos con los comportamientos en una entidad nica. Los modelos orientados a objetos son tiles para comprender problemas, comunicarse con expertos en esa aplicacin, modelar empresas, preparar documentacin y disear programas y bases de datos. OMT, la Tcnica de Modelado de Objetos se extiende desde el anlisis hasta la implementacin pasando por el diseo. OMT presenta un enfoque orientado a objetos hacia desarrollo del software basado en modelar objetos del mundo real y utilizar as el modelo para construir un diseo independiente del lenguaje que estar organizado en torno a esos objetos. Se describe una notacin grfica para expresar modelos orientados a objetos. Los objetos del dominio de la aplicacin y del dominio de la computadora se pueden modelar, disear e implementar utilizando los mismos conceptos y la misma notacin orientada a objetos. Esta misma notacin sin solucin de continuidad se utiliza desde el anlisis hasta la implementacin, pasando por el diseo, de una forma tal que la informacin aadida en una fase de desarrollo no necesita perderse, ni ser traducida, para la prxima fase.
Anlisis
El objetivo del anlisis es desarrollar un modelo de lo que va a hacer el sistema. El modelo se expresa en trminos de objetos y de relaciones, flujo dinmico de control y transformaciones funcionales. El proceso de captura de requisitos y de consultas con el solicitante debera extenderse a lo largo de todo el anlisis. Los pasos son los siguientes: 1. Se escribe o se obtiene una descripcin inicial del problema (definicin del problema) 2. Se construye un Modelo de Objetos. 3. Se desarrolla un Modelo Dinmico. 4. Se construye un Modelo Funcional. 5. Se verifican, iteran y refinan los tres modelos.
Diseo de Sistemas
Durante el diseo de sistemas se escoge la estructura de alto nivel del sistema.
Documento de Diseo de Sistema = estructura de la arquitectura bsica del sistema y decisiones estratgicas de alto nivel.
Diseo de Objetos
34
Durante el diseo de objetos, se elabora el modelo de anlisis y se proporciona una base detallada para la implementacin. Se toman las decisiones que sean necesarias para construir un sistema sin descender a los detalles particulares de un lenguaje o sistema de base de datos individual. El diseo de objetos seala el comienzo de un desplazamiento con respecto a la orientacin a la computadora que es necesaria para una implementacin prctica.
Documento de Diseo = Modelo de Objetos Detallado + Modelo Dinmico Detallado + Modelo Funcional Detallado
35
Notacin del Modelo de Objetos:

Clase: Nombre de clase Nombre de clase atributo atributo: tipo_de_dato atributo: tipo_de_dato=valor inicial ... operacin operacin(lista_arg):tipo_proporcionado
Generalizacin (herencia) Superclase
Subclase - 1
Subclase - 2
Agregacin: Clase Compuesta
Parte 1-Clase
Parte 2-Clase
Agregacin: (forma alternativa): Clase Compuesta
Parte 1-Clase
Parte 2-Clase 36
Instancias de Objetos:
(Nombre de clase)
(Nombre de clase) nombre_atributo=valor ...
Asociacin: nombre de asociacin Clase-1 Clase-1
Clase Clase Clase 1+ 1-2,4 Clase Clase
Exactamente una Muchas (cero o ms) Opcional (cero o ms) Una o ms Especificadas numricamente
37
8. Modelos OMT
Modelado de Objetos
El modelado de objetos captura la estructura esttica del sistema, mostrando los objetos del sistema, las relaciones entre ellos, y los atributos que caracterizan a cada clase. Se har hincapi en construir un sistema en torno a los objetos y no en torno a la funcionalidad, porque el modelo de objetos se corresponde con el mundo real de manera ms fiel y, por tanto, es ms flexible frente al cambio. Los modelos de objetos proporcionan una representacin grfica intuitiva del sistema y son valiosos para comunicarse con el cliente y para documentar la estructura del sistema.
Objetos y Clases
El propsito del modelado de objetos es describir objetos. Se definir un objeto como un concepto, abstraccin o cosa con lmites bien definidos y con significado a efectos del problema que se tenga entre manos. Los objetos tienen dos propsitos: promover la comprensin del mundo real y proporcionar una base prctica para la implementacin por computadora. La descomposicin de un problema en objetos depende del juicio y de la naturaleza del problema. No existe una nica representacin correcta. Una clase de objetos describe un grupo de objetos con propiedades (atributos) similares, con relaciones comunes con otros y con una semntica comn. Es frecuente utilizar la abreviatura clase en lugar de decir clase de objetos. Cada objeto conoce su clase. La mayora de los lenguajes de programacin orientados a objetos puede determinar la clase del objeto en el momento de la ejecucin. La clase del objeto es una propiedad implcita de s mismo.
Diagramas de Objetos
Los diagramas de objetos proporcionan una notacin grfica formal para el modelado de objetos, clases y sus relaciones entre s, son tiles, tanto para el modelado abstracto como, para disear programas reales. Los diagramas de objetos son concisos, fciles de entender y funcionan bien en la prctica. Un diagrama de clases es un esquema, patrn o plantilla para describir muchas instancias de datos posibles. Los diagramas de clases describen clases de objetos.
38
Un diagrama de instancias describe la forma en que un cierto conjunto de objetos se relacionan entre s. Un diagrama de instancias describe instancias de objetos. Los diagramas de instancias son tiles para documentar casos prcticos (sobre todo los escenarios) y para describir ejemplos. Un diagrama de clases dado se corresponde con un conjunto infinito de diagramas de instancia.
Persona
(Persona) Juan Garca
(Persona) Mara Prez
(Persona)
Clase
Objetos
Un atributo es un valor de un dato que est almacenado en los objetos de una clase. Cada atributo tiene un valor para cada instancia del objeto. Los atributos debera ser valores puros de datos y no objetos. Los atributos se enumeran en la segunda parte del cuadro de clase. El nombre de cada atributo puede ir seguido por detalles opcionales, tales como el tipo y el valor por omisin. El tipo ir precedido por dos puntos. El valor por omisin ir precedido por un signo igual. En algunas ocasiones puede uno decidir omitir los atributos en los cuadros de clase. Depende del nivel de detalle deseado en el modelo de objetos. Los cuadros de clase tienen una lnea entre el nombre de la clase y los atributos. Los cuadros de objetos no tienen esta lnea para distinguirlos todava ms de los cuadros de clase.
Persona nombre:cadena edad:entero (Persona) Juan Garca 24 (Persona) Mara Prez 52
Clase con sus atributos
Objetos con sus valores
Una operacin es una funcin o transformacin que se puede aplicar o que puede ser aplicada por los objetos de una clase. Todos los objetos de una clase comparten las mismas operaciones. Todo objeto conoce su clase, y por tanto, la implementacin correcta de la operacin.
Una misma operacin puede aplicarse a muchas clases distintas. Tal operacin ser polimrfica: esto es, una misma operacin adopta distintas formas en distintas clases.
Persona nombre edad cambiar de trabajo cambiar de direccin Archivo nombre de archivo tamao en bytes ltima actualizacin imprimir Objeto geomtrico color posicin mover (delta: Vector) seleccionar (p: Punto): Boolean rotar (ngulo)
Enlaces y Asociaciones
Un enlace es una conexin fsica o conceptual entre instancias de objetos. Un enlace es una instancia de una asociacin. Una asociacin describe un grupo de enlaces con estructura y semntica comunes. Las asociaciones son inherentemente bidireccionales. El nombre de una asociacin binaria suele leerse en un cierto sentido, pero la asociacin binaria se pude recorrer en ambas direcciones. La direccin implicada por el nombre es la direccin hacia adelante; la direccin opuesta es la direccin hacia atrs.
Pas nombre
Tiene-como-capital
Ciudad nombre Diagrama de clases
(Pas) Canad (Pas) Francia (Pas) Senegal
Tiene-como-capital
(Ciudad) Ottawa (Ciudad) Pars (Ciudad) Dakar
Tiene-como-capital
Diagrama de instancias
Tiene-como-capital
La multiplicidad especifica el nmero de instancias de una clase que pueden estar relacionadas con una nica instancia de una clase asociada. La multiplicidad limita el nmero de objetos relacionados.
40
En el caso ms general se puede especificar la multiplicidad mediante un nmero o mediante un conjunto de intervalos, tal como puede ser 1 (uno exactamente), 1+ (uno o ms), 3-5 ( entre tres y cinco, ambos inclusive), y 2,4,18 (dos, cuatro o bien dieciocho). Existen terminadores de lnea especiales que indican ciertos valores frecuentes de multiplicidad. Un crculo negro es el smbolo OMT que denota muchos, lo cual quiere decir cero o ms. Un circulo blanco indica opcional, lo cual quiere decir cero o uno. Una lnea sin smbolos de multiplicidad denota una asociacin uno-a-uno. En el caso general, la multiplicidad se escribe junto al final de la lnea, por ejemplo, 1+ para indicar uno o ms. La distincin de multiplicidad ms importante es la existente entre uno y muchos. Una agregacin es la relacin parte-todo o una-parte-de en la cual los objetos que representan los componentes de algo se asocian a un objeto que representa el ensamblaje completo. Definimos la relacin de agregacin como aquella que relaciona una clase ya ensamblada con una clase componente. Un ensamblaje con muchas clases de componentes se corresponde con muchas relaciones de agregacin. Definimos cada emparejamiento individual como una agregacin para que sea posible especificar la multiplicidad de cada componente dentro del ensamblaje. Esta definicin hace hincapi en que la agregacin es una forma especial de asociacin.
Documento
Prrafo
Frase
41
El modelo de objetos debera hacer fcil identificar visualmente los niveles de una jerarqua de partes.
Microcomputadora
Monitor
Caja del sistema
Ratn
Teclado
Generalizacin y Herencia
La Generalizacin es la relacin entre una clase y una o ms versiones refinadas de esa Chasis CPU RAM Ventilador misma clase. La que se est refinando se denomina la superclase y cada versin refinada se denomina subclase. La generalizacin y la herencia son transitivas a travs de un nmero arbitrario de niveles. Los trminos ascendente y descendente hacen alusin a la generalizacin de clases a travs de niveles mltiples. Una instancia de una subclase es simultneamente una instancia de todas sus clases antecesoras. El estado de una instancia incluye un valor para todos y cada uno de los atributos de todas sus clases antecesoras. Toda operacin aplicable a una clase antecesora podr ser aplicada a una instancia suya. Toda subclase hereda, no solamente todas las caractersticas de sus antecesoras sino que adems aade sus propios atributos y operaciones especficos.
42
La notacin para la generalizacin es un tringulo que conecta una superclase con sus subclases. La superclase se conecta mediante una lnea a la parte superior del tringulo. Las subclases se conectan mediante lneas a una barra horizontal asociada a la base del tringulo. Por comodidad, se puede invertir el tringulo y se pueden conectar las subclases tanto a la parte superior de la barra como a la parte inferior pero, si es posible, la superclase debera dibujarse en la parte superior y las subclases en la parte inferior.
Equipo nombre fabricante peso coste tipo de equipo
Bomba presin de succin presin de descarga medida de flujo
Intercambiador de calor rea superficial dimetro del tubo longitud del tubo presin del tubo presin superficial
...
Tanque volumen presin
tipo de bomba
Bomba centrfuga dimetro del impulsor nmero de hojas eje de rotacin
Bomba de diafragma
Bomba de pistn longitud del pistn dimetro del pistn nmero de cilindros tipo de tanque
...
material del diafragma
...
Tanque esfrico dimetro
Tanque a presin dimetro altura
Tanque de techo flotante dimetro altura
43
Las palabras que se escriben al lado de los tringulos en un diagrama, tales como, tipo de equipo, tipo de bomba y tipo de tanque son discriminadores. Un discriminador es un atributo de enumeracin de tipo que indica qu propiedad del objeto est siendo abstrada por una relacin de generalizacin en particular. Solamente se debe discriminar una propiedad de cada vez. El discriminador es, simplemente, un nombre para la base de la generalizacin.
Modelado Dinmico
Los aspectos del sistema que estn relacionados con el tiempo y con los cambios constituyen el modelo dinmico, por contraste con el modelo esttico o de objetos. El control es aquella parte del sistema que describe las secuencias de operaciones que se producen en respuesta a estmulos externos, sin tener en cuenta los que hagan las operaciones, aquello a lo que afectan, ni la forma en que sean implementadas.
Sucesos y Estados
Los valores de los atributos y de los enlaces mantenidos por un objeto son lo que se denomina su estado. A lo largo del tiempo, los objetos se estimulan unos a otros, dando lugar a una serie de cambios en sus estados. Un estmulo individual proveniente de un objeto y que llega a otro es un suceso. La respuesta a un suceso depende del estado del objeto que lo recibe, y puede incluir un cambio de estado o el envo de otro suceso al remitente o a un tercer objeto. La trama de sucesos, estado y transiciones de estados para una clase dad se puede abstraer y representar en forma de un diagrama de estados. Un diagrama de estados es una red de estados y sucesos, del mismo modo que un diagrama de objetos es una red de clases y de relaciones. El modelo dinmico consta de mltiples diagramas de estados, con un diagrama de estados para cada clase que posea un comportamiento dinmico importante, y muestra la trama de actividad para todo el sistema. Un suceso es una transmisin de informacin de direccin nica entre un objeto y otro. Un escenario es una secuencia de sucesos que se produce durante una ejecucin concreta de un sistema. El mbito de un escenario es variable, puede incluir a todos los sucesos del sistema, o puede incluir solamente aquellos sucesos que afecten a ciertos objetos del sistema, o que sean generados por ellos. Un escenario puede ser el registro histrico de la ejecucin de un sistema, o de un experimento imaginario de la ejecucin de un sistema propuesto. Un diagrama de estados relaciona sucesos y estados. Cuando se recibe un suceso, el estado siguiente depende del actual, as como del suceso: un cambio de estado causado por un suceso es lo que se llama una transicin. Un diagrama de estados es un grafo cuyos nodos son estados, y cuyos arcos dirigidos son transiciones rotuladas con nombres de sucesos. Los estados se representan como cuadros redondeados que contienen un nombre opcional. Las transacciones se representan en forma de flechas desde el estado receptor hasta el estado de
destino: el rtulo de la flecha es el nombre del suceso que de lugar a la transaccin. Todas las transiciones que salgan de un estado deben de corresponder a sucesos distintos. Un diagrama de estados describe el comportamiento de una sola clase de objetos. Dado que todas las instancias de una clase tienen el mismo comportamiento (por definicin), todas ellas comparten el mismo diagrama de estados, por cuanto todas ellas comparten las mismas caractersticas de clase.
Operaciones
Una descripcin conductista de un objeto debe especificar lo que hace el objeto como respuesta a los sucesos. Las operaciones asociadas a estados o a transiciones se efectan en respuesta a los correspondientes estados o sucesos. Una actividad es una operacin cuya realizacin requiere un cierto tiempo. Toda actividad est asociada a un estado. La notacin hacer: A dentro del cuadro de un estado indica que la actividad A comienza al entrar en ese estado y finaliza al salir de l. Una accin es una operacin instantnea que va asociada a un suceso. Una accin representa a una operacin cuya duracin es insignificante en comparacin con la resolucin del diagrama de estados. La notacin para una accin que afecta a una transicin es una barra (/) y el nombre (o descripcin), despus del nombre del suceso que la produce.
botn derecho pulsado / mostrar men abatible
en reposo
botn derecho soltado / borrar men abatible
Men visible
se mueve el cursor / seleccionar tem de men
45
Modelado Funcional
El modelado funcional muestra la forma en que se derivan los valores producidos en un clculo a partir de los valores introducidos, sin tener en cuenta el orden en el cual se calculan los valores. Consta de mltiples diagramas de flujo de datos, que muestran el flujo de valores desde las entradas externas, a travs de las operaciones y almacenes internos de datos hasta las salidas externas, tambin incluye restricciones entre valores dentro del modelo de objetos. Un diagrama de flujo de datos (DFD) muestra las relaciones funcionales entre los valores calculados por un sistema, incluyendo los valores introducidos, los obtenidos, y los almacenes internos de datos. Un diagrama de flujo de datos contiene procesos que transforman datos, flujos de datos que los trasladan, objetos actores que producen y consumen datos, y de almacenes de datos que los almacenan de forma pasiva. Un proceso transforma valores de datos. Los procesos del ms bajo nivel son funciones puras, sin efectos laterales. Los procesos se dibujan en forma de elipses que contienen una descripcin de la transformacin, normalmente su nombre. Cada proceso tiene un nmero fijo de flechas de entrada y salida de datos, cada una de las cuales lleva un valor de un tipo dado. Las entradas y salidas se pueden rotular, para mostrar su papel en el clculo, pero es frecuente que baste el tipo de valor asociado al flujo de datos.
dividiendo
cociente
divisin entera
divisor resto
Un flujo de datos conecta la salida de un objeto o proceso con la entrada de otro objeto o proceso. Representa un valor de datos intermedio dentro de un clculo que no es modificado por el flujo de datos. Los flujos de datos se dibujan como flechas entre el productor y el consumidor de ese valor de datos. La fecha est rotulada con una descripcin de los datos, normalmente su nombre o su tipo. El mismo valor se puede enviar a varios lugares; esto se denota mediante una bifurcacin con varias flechas que emerjan de ella.
Un actor es un objeto activo que controla el grafo de flujo de datos produciendo o consumiendo valores. Los actores estn asociados a las entradas y salidas del grafo del flujo de datos. En cierto sentido, los actores yacen en la frontera del grafo, pero hacen que concluya el flujo de datos como fuentes y sumideros de datos, as que en algunos casos se denominan terminadores. Los actores se representan como rectngulos para mostrar que son objetos. Las flechas entre el actor y el diagrama son las entradas y salidas del diagrama. Un almacn de datos es un objeto pasivo dentro de un diagrama de flujo de datos que almacena datos para su posterior utilizacin. A diferencia de los actores, no generan ninguna operacin por s mismos, sino que se limitan a responder a solicitudes de almacenamiento y acceso a datos. Los almacenes de datos se dibujan en forma de un par de lneas paralelas que contienen el nombre del almacn. Las flechas de entrada indican informacin u operaciones que modifican los datos almacenados: esto incluye la adicin de elementos, modificacin de valores, o el borrado de elementos. Las flechas de salida indican informacin que se ha extrado del almacn. Esto incluye recuperar todo el valor o bien alguno de sus componentes.
47
Cuenta
saldo Retirada de fondos
Cliente
Tabla peridica
pesos atmicos
elemento
hallar peso
peso atmico
48
Empaquetamiento Fsico
Los programas constan de unidades fsicas discretas que se pueden editar, compilar, importar o en general manipular. En algunos lenguajes, como C y Fortran, las unidades son archivos fuente. En Ada, el package * es una estructura explcita del lenguaje para crear mdulos. Los lenguajes orientados a objetos tienen distintos grados de empaquetamiento. En todo proyecto de envergadura, una cuidadosa descomposicin de la implementacin en paquetes (sea cual fuere su forma) resulta importante para permitir que distintas personas puedan trabajar cooperativamente en el programa. El empaquetamiento implica los asuntos siguientes: Ocultar la informacin interna a los ojos del exterior Coherencia de entidades Construccin de mdulos fsicos
Implementacin
La escritura de cdigo es una extensin del proceso de diseo. La escritura de cdigo debera de ser sencilla, casi mecnica, porque ya deberamos de haber tomado todas las decisiones difciles durante el diseo. Ciertamente, hay que tomar decisiones mientras se escribe el cdigo, pero cada una de ellas debera de afectar solamente a una pequea parte del programa, de tal manera que fuera fcil cambiarlas. Con todo, el cdigo de programa es la personificacin ltima de al solucin del problema, as que la forma en que se escriba ser importante para la mantenibilidad y la extensibilidad. La manera ms fcil de implementar un diseo orientado a objetos conlleva el uso de un lenguaje orientado a objetos, pero incluso los lenguajes orientados a objetos ofrecen distintos grados de apoyo para los conceptos orientados a objetos. Cada lenguaje supone un compromiso entre potencia conceptual, eficiencia y compatibilidad con los trabajos anteriores. An cuando tengamos que utilizar un lenguaje que no sea orientado a objetos, el diseo orientado a objetos resulta beneficioso. Los conceptos orientados a objetos se pueden hacer corresponder con las estructuras de un lenguaje no orientado a objetos. No es tanto un problema real de potencia - en todo caso, los lenguajes de programacin acaban por convertirse en cdigo mquina - como una cuestin de expresividad. El uso de un lenguaje que no sea orientado a objetos exige mayor cuidado y disciplina a la hora de mantener la estructura orientada a objetos del programa, y el programador no puede obtener ayuda del lenguaje para hallar las fallas.
Diseo de Objetos
49
Durante el diseo de objetos, se ejecuta la estrategia seleccionada durante el diseo del sistema y se rellenan los detalles. Despus del anlisis, se tienen los modelos de objetos, dinmico y funcional, no obstante el primero es el entorno principal alrededor del que se construye el diseo. El modelo de objetos procedente de un anlisis puede no mostrar operaciones. El diseador debe transformar las acciones y actividades del modelo dinmico y los procesos del modelos funcional en operaciones asociadas a las clases del modelo de objetos. Al efectuar esta transformacin, comienza el proceso consistente en hacer corresponder la estructura lgica del modelo de anlisis en una organizacin fsica de un programa. Cada operacin especificada en el modelo funcional debe ser formulada como un algoritmo. El anlisis de especificaciones dice lo que hace la operacin desde el punto de vista de sus clientes y los algoritmos muestran cmo se hace. Un algoritmos se pude subdividir en llamadas a operaciones ms sencillas, y as sucesivamente, hasta que las operaciones del nivel ms bajo sean suficientemente sencillas para implementarlas directamente sin ms refinamiento.
Diseo de Asociaciones
Las asociaciones son el pegamento de nuestro modelo de objetos, y proporcionan vas de acceso entre objetos siendo entidades conceptuales tiles para el modelado y el anlisis. Durante la fase del diseo de objetos hay que formularse una estrategia para implementar las asociaciones habidas en el modelo de objetos. Se puede seleccionar una estrategia global para implementar todas las asociaciones uniformemente, o bien seleccionar una tcnica particular para cada asociacin, teniendo en cuenta la forma en que ser utilizada en la aplicacin. Para tomar decisiones inteligentes acerca de las asociaciones, se necesita analizar primero la forma en que sern utilizadas. Hasta el momento se ha supuesto que las asociaciones son inherentemente bidireccionales, lo cual es sin duda cierto, en el sentido abstracto. Pero si algunas asociaciones de la aplicacin slo se van a recorrer en una direccin, se puede simplificar su implementacin. Hay que ser consciente, sin embargo, de que los requisitos de la aplicacin podran cambiar, con lo que sera necesario despus de una nueva operacin que necesite recorra la asociacin en sentido inverso. Hay que ocultar la implementacin, empleando operaciones de acceso para recorrer la asociacin y para actualizarla. Esto permitir cambiar de decisin con un esfuerzo mnimo.
50
Asignacin de Subsistemas a Procesadores y a Tareas

Cada subsistema concurrente debe ser asociado a una unidad de hardware, bien a un procesador de propsito general o a una unidad funcional especializada. El diseador del sistema deber: Estimar las necesidades de rendimiento y los recursos necesarios para satisfacerlas. Seleccionar las implementaciones de hardware o de software para los subsistemas. Asignar los subsistemas de software a los procesadores para satisfacer las necesidades de rendimiento, y para minimizar la comunicacin interprocesadores. Determinar las conexiones de las unidades fsicas que implementan los subsistemas.
Administracin de Almacenes de Datos

Los almacenes de datos internos y externos dentro de un sistema, proporcionan puntos limpios de separacin entre subsistemas, con interfaces bien definidas. En general, todo almacn de datos puede combinar estructuras de datos, archivos y bases de datos implementados en memoria o bien en dispositivos de almacenamiento secundario.
Manejo de las Condiciones de Contorno

An cuando la mayor parte del esfuerzo de diseo en muchos sistemas se dedica al comportamiento en estado estacionario, el diseador de sistemas debe considerar tambin las condiciones de contorno: La iniciacin, terminacin y fallos. Iniciacin. El sistema debe traerse desde un estado inicial de reposo hasta una situacin estacionaria mantenible. Terminacin. La terminacin suele ser ms sencilla que la iniciacin, porque hay muchos objetos internos que se pueden, simplemente, abandonar. Fallos. Un fallo es la terminacin no planeada de un sistema. Los fallos pueden surgir de errores del usuario, del agotamiento de recursos del sistema, o de algn fallo catastrfico externo. Los buenos diseadores planean fallos ordenados.
51
Diseo del Sistema

El diseo del sistema es la estrategia de alto nivel para resolver el problema y construir una solucin. ste incluye decisiones acerca de la organizacin del sistema en subsistemas, la asignacin de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de poltica que son las que constituyen un marco de trabajo para el diseo detallado. Durante el anlisis, lo fundamental es lo que necesita hacerse, independientemente de la forma de hacerlo. Durante el diseo, se toman decisiones acerca de la forma en que se resolver el problema, primero desde un nivel elevado y despus empleando niveles cada vez ms detallados.
Descomposicin de un Sistema en Subsistemas

En todas las aplicaciones, salvo las ms pequeas, el primer paso para disear un sistema consiste en dividir el sistema en un pequeo nmero de componentes. Cada uno de los componentes principales de un sistema se llama subsistema. Cada subsistema abarca aspectos del sistema que compartan alguna propiedad comn. Un subsistema no es ni una funcin ni un objeto, sino un paquete de clases, asociaciones, operaciones, sucesos y restricciones interrelacionados. Normalmente, un subsistema se identifica por los servicios que proporciona. Un servicio es un grupo de funciones relacionadas que comparten algn propsito comn. Cada subsistema posee una interfaz bien definida con el resto del sistema. sta especifica la forma de todas las interacciones y el flujo de informacin entre los lmites de subsistemas, pero no especifica cmo est implementado internamente el subsistema. Cada subsistema se puede disear, entonces, independientemente sin afectar a los dems.
Modelado Dinmico
El modelo dinmico muestra la forma en que el comportamiento del sistema y de los objetos de que consta va variando con el tiempo. Comience el anlisis dinmico buscando los sucesos que son estmulos y respuestas visibles externamente. Despus hay que resumir las secuencias de sucesos admisibles para todos los objetos que tengan un diagrama de estados. La ejecucin de algoritmos no es relevante durante el anlisis si no hay manifestaciones visibles externamente; los algoritmos son una parte de la implementacin.
52
Modelado Funcional
El modelo funcional muestra la forma en que se calculan los valores, sin tener en cuenta las secuencias, decisiones o estructura de los objetos. El modelo funcional muestra qu valores dependen de qu otros valores, y las funciones que los relacionan. Los diagramas de flujo de datos resultan tiles para mostrar dependencias funcionales. Las funciones se expresan de diferentes formas, incluyendo el lenguaje natural, las ecuaciones matemticas y el pseudocdigo. Los procesos de un diagrama de flujo de datos se corresponden con actividades o acciones de los diagramas de estados de las clases. Los flujos de un diagrama de flujo de datos se corresponden con objetos o con valores de atributos de un diagrama de objetos. Lo mejor es construir el modelo funcional despus de haberlo hecho con los modelos de objetos dinmico.
Adicin de Operaciones
Nuestro estilo de anlisis orientado a objetos hace mucho menos hincapi en la definicin de operaciones que las metodologas de programacin ms tradicionales, orientadas a objetos pero basadas en la programacin. La lista de operaciones que pueden resultar tiles es inacabable, y resulta difcil saber cundo tienen qu dejar de aadir.
Iteracin del Anlisis

Casi todos los modelos de anlisis requiere ms de una pasada para finalizar. En su mayor parte las definiciones del problema contienen referencias circulares, y no es posible aproximarse a la mayora de las operaciones en forma completamente lineal, porque las distintas partes del problema interactan. Para comprender un problema con todas sus implicaciones es preciso atacar iterativamente el anlisis, preparando una primera aproximacin al modelo e iterando despus el anlisis a medida que mejore nuestra comprensin.
53

Elementos de Desarrollo OO

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Elementos de Desarrollo OO

Caricato da

Copyright:

Formati disponibili

LENGUAJES ORIENTADOS A OBJETOS

Lenguajes Orientados a Objetos

Elementos de Anlisis y Desarrollo Orientados a Objetos

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

1. El Problema de la Complejidad del Software

Por qu el software es complejo de forma innata

LENGUAJES ORIENTADOS A OBJETOS

Los Cinco Atributos de un Sistema Complejo

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

2. El Modelo Orientado a Objetos

La Evolucin del Modelo de Objetos

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

Elementos del Modelo de Objetos

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

Aplicacin del Modelo de Objetos

3. Objetos y Clases: Naturaleza y Relaciones

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

Relaciones entre Objetos

La Naturaleza de una Clase

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

Relaciones entre Clases

Relaciones entre Clases y Objetos

El Rol de Clases y Objetos en Anlisis y Diseo

LENGUAJES ORIENTADOS A OBJETOS

Relaciones de herencia entre clases

Relaciones de uso entre clases

Relaciones de instanciacin entre clases

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

Figura: Icono para una Clase

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

label label label

label + label label + label

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS

ELEMENTOS DE ANALISIS Y DESARROLLO ORIENTADOS A OBJETOS

LENGUAJES ORIENTADOS A OBJETOS