Este documento describe los conceptos básicos de la metodología orientada a objetos y el lenguaje unificado de modelado (UML). Explica que la orientación a objetos une datos y procesos en objetos, y describe conceptos como clases, atributos, métodos, herencia y polimorfismo. También introduce UML como un lenguaje estándar para modelar sistemas de software que puede usarse en todas las fases del desarrollo.

1. METODOLOGÍA ORIENTADA A OBJETOS

2. El desarrollo de proyectos software ha sufrido una evolución desde los primeros sistemas de calculo, implementados en grandes computadores simplemente ayudados mediante unas tarjetas perforadas donde los programadores escribían sus algoritmos de control, hasta la revolución de los sistemas de información e Internet. Han existido dos grandes cambios desde aquellos sistemas meramente algorítmicos donde todo el esfuerzo de desarrollo se centraba en la escritura de programas que realizaran algún tipo de calculo. El primero de ellos es la aparición del modelo relacional, un modelo con fuerte base matemática que supuso el desarrollo las bases de datos y propició la aparición de los grandes sistemas de información. HISTORIA DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE

3. El segundo cambio es sobre los lenguajes de programación, la aparición de los Lenguajes Orientados a Objetos (aunque los primero lenguajes con características de orientación a objetos aparecieron en la década de los setenta, por ejemplo Simula 67 ) supuso una revolución en la industria software. El problema entonces radicaba en poder sacarle partido a los lenguajes orientados a objetos por lo que aparecieron numerosas metodologías para el diseño orientado objetos, hubo un momento en el que se podía decir que el concepto de orientación a objetos estaba “de moda” y todo era orientado a objetos, cuando realmente lo que ocurría es que las grandes empresas que proporcionaban los compiladores y lenguajes de programación “lavaban la cara" a sus compiladores, sacaban nuevas versiones que adoptaran alguno de los conceptos de orientación a objetos y los vendían como orientados a objetos.

4. Para poner un poco de orden, sobre todo en lo que respecta a la modelización de sistemas software, aparece UML (Unified Modeling Languaje, Lenguaje Unificado de Modelado ) que pretende unificar las tres metodologías más difundidas (OMT, Bootch y OOSE) e intentar que la industria software termine su maduración como Ingeniería . Y lo consigue en tal manera que lo que UML proporciona son las herramientas necesarias para poder obtener los planos del software equivalentes a los que se utilizan en la construcción, la mecánica o la industria aeroespacial. UML abarca todas las fases del ciclo de vida de un proyecto, soporta diferentes maneras de visualización dependiendo de quién tenga que interpretar los planos y en que fase del proyecto se encuentre. Lo que describiéremos en este curso es una introducción al diseño orientado a objetos y que solución aporta UML, explicando sus características principales.

5. Para producir software que cumpla su propósito hay que obtener los requisitos del sistema, esto se consigue conociendo de una forma disciplinada a los usuarios y haciéndolos participar de manera activa para que no queden “cabos sueltos”. Para conseguir un software de calidad, que sea duradero y fácil de mantener hay que idear una sólida base arquitectónica que sea flexible al cambio. Para desarrollar software rápida y eficientemente, minimizando el trabajo de recodificación y evitando crear miles de líneas de código inútil hay que disponer, además de la gente y las herramientas necesarias, de un enfoque apropiado. MODELADO

6. Para conseguir, que a la hora de desarrollar software de manera industrial se obtenga un producto de calidad, es completamente necesario seguir ciertas pautas y no abordar los problemas de manera somera, con el fin de obtener un modelo que represente lo suficientemente bien el problema que hemos de abordar. El modelado es la espina dorsal del desarrollo software de calidad. Se construyen modelos para poder comunicarnos con otros, para explicar el comportamiento del sistema a desarrollar, para comprender, nosotros mismos, mejor ese sistema, para controlar el riesgo y en definitiva para poder atacar problemas que sin el modelado su resolución seria imposible, tanto desde el punto de vista de los desarrolladores (no se pueden cumplir los plazos estimados, no se consigue ajustar los presupuestos...) como desde el punto de vista del cliente, el cual, si finalmente se le entrega el producto del desarrollo, se encontrará con infinidades de problemas, desde que no se cumplen las especificaciones hasta fallos que dejan inutilizado el sistema.

7. Cuando nos referimos al desarrollo software en el ámbito industrial, no se pretende que la capacidad de modelar se reduzca a empresas que disponen de gran numero de empleados o empresas que han de abordar proyectos eminentemente grandiosos, si no que nos referimos a la capacidad de obtener un producto comercial (sea cual sea su coste o tamaño) que cumpla lo que en la industria se suele denominar como calidad total1 y que además pueda reportar beneficios a corto o medio plazo, evitando, por ejemplo, implantaciones casi eternas debido a la falta de previsión o al haber abordado los problemas muy a la ligera.

10. PRINCIPIOS BÁSICOS DEL MODELADO c) Los mejores modelos están ligados a la realidad. Lo principal es tener modelos que nos permitan representar la realidad lo más claramente posible, pero no sólo esto, tenemos que saber, exactamente cuando se apartan de la realidad para no caer en la ocultación de ningún detalle importante. d) Un único modelo no es suficiente . Cualquier sistema que no sea trivial se afronta mejor desde pequeños modelos casi independientes, que los podamos construir y estudiar independientemente y que nos representen las partes más diferenciadas del sistema y sus interrelaciones.

11. ORIENTACIÓN A OBJETOS La programación estructurada tradicional se basa fundamentalmente en la ecuación de Wirth: Algoritmos + Estructuras de Datos = Programas Esta ecuación significa que en la programación estructurada u orientada a procedimientos los datos y el código se trata por separado y lo único que se realiza son funciones o procedimientos que tratan esos datos y los van pasando de unos a otros hasta que se obtiene el resultado que se desea.

12. ORIENTACIÓN A OBJETOS Podemos definir objeto como el "encapsulamiento de un conjunto de operaciones (métodos) que pueden ser invocados externamente, y de un estado que recuerda el efecto de los servicios". [Piattini et al., 1996] . Un objeto además de un estado interno, presenta una interfaz para poder interactuar con el exterior. Es por esto por lo que se dice que en la programación orientada a objetos "se unen datos y procesos", y no como en su predecesora, la programación estructurada, en la que estaban separados en forma de variables y funciones. Un objeto consta de: Tiempo de vida: La duración de un objeto en un programa siempre está limitada en el tiempo. La mayoría de los objetos sólo existen durante una parte de la ejecución del programa. Los objetos son creados mediante un mecanismo denominado instanciación , y cuando dejan de existir se dice que son destruidos. Estado: Todo objeto posee un estado, definido por sus atributos . Con él se definen las propiedades del objeto, y el estado en que se encuentra en un momento determinado de su existencia. Comportamiento: Todo objeto ha de presentar una interfaz, definida por sus métodos , para que el resto de objetos que componen los programas puedan interactuar con él.

13. VENTAJAS DE LA ORIENTACIÓN A OBJETOS Las ventajas más importantes de la programación orientada a objetos son las siguientes: • Mantenibilidad (facilidad de mantenimiento). Los programas que se diseñan utilizando el concepto de orientación a objetos son más fáciles de leer y comprender y el control de la complejidad del programa se consigue gracias a la ocultación de la información que permite dejar visibles sólo los detalles más relevantes. • Modificabilidad (facilidad para modificar los programas). Se pueden realizar añadidos o supresiones a programas simplemente añadiendo, suprimiendo o modificando objetos. • Resusabilidad . Los objetos, si han sido correctamente diseñados, se pueden usar numerosas veces y en distintos proyectos. • Fiabilidad . Los programas orientados a objetos suelen ser más fiables ya que se basan en el uso de objetos ya definidos que están ampliamente testeados.

16. CONCEPTOS BÁSICOS DE LA ORIENTACIÓN A OBJETOS Clase: Es una descripción de un conjunto de objetos similares. Por ejemplo la clase Coches. Una clase contiene los atributos y las operaciones sobre esos atributos que hacen que una clase tenga la entidad que se desea.

17. Nombre Cada clase tiene un nombre que la distingue de las demás. Un nombre es una cadena de texto. Se tienen: Nombres simples: es el simple nombre. Por ejemplo: Cliente, pared. Nombres compuestos: consta del nombre de la clase precedido por el nombre del paquete en el que se encuentra. Por ejemplo: java::awt::Rectangle Los nombres de las clases son sustantivos o frases cortas y empiezan con una letra mayúscula.

18. Atributos Es una propiedad de una clase identificada con un nombre, que describe un rango de valores. Una clase puede tener: cualquier número de atributos o ningún atributo. Un atributo representa alguna propiedad del elemento que se está modelando. Un atributo se puede especificar más indicando su clase y su valor inicial por defecto.

19. Operaciones Una operación es una acción que se puede solicitar a cualquier objeto de la clase. Las operaciones son los procesos que una clase sabe cómo realizar. Una operación es una abstracción de algo que se puede hacer a un objeto y que son compartidos por todos los objetos de la clase. Una clase puede tener cualquier número de operaciones o ninguna. Las operaciones se pueden representar mostrando sólo sus nombres.

20. EJEMPLOS DE CLASES

21. • Objeto: Un objeto es una cosa, generalmente extraída del vocabulario del espacio del problema o del espacio de la solución. Todo objeto tiene un nombre (se le puede identificar), un estado (generalmente hay algunos datos asociados a él) y un comportamiento (se le pueden hacer cosas a objeto y él puede hacer cosas a otros objetos). Un objeto de la clase Coches puede ser un Ford Mustang .

22. • Atributo: Es una característica concreta de una clase. Por ejemplo atributos de la clase Coches pueden ser el Color , el Numero de Puertas... • Método: Es una operación concreta de una determinada clase. Por ejemplo de la clase Coches podríamos tener un método arrancar() que lo que hace es poner en marcha el coche. • Instancia: Es una manifestación concreta de una clase (un objeto con valores concretos). También se le suele llamar ocurrencia. Por ejemplo una instancia de la clase Coches puede ser: Un Ford Mustang, de color Gris con 3 puertas

23. CONCEPTOS BÁSICOS DE LA ORIENTACIÓN A OBJETOS Herencia: Es un mecanismo mediante el cual se puede crear una nueva clase partiendo de una existente, se dice entonces que la nueva clase hereda las características de la clase existentes aunque se le puede añadir más capacidades (añadiendo datos o capacidades) o modificar las que tiene. Por ejemplo supongamos que tenemos la VehiculosDeMotor. En esta clase tenemos los siguientes atributos: Cilindrada y Numero de Ruedas , y el método acelerar() . Mediante el mecanismo de herencia podemos definir la clase Coches y la clase Motos. Estas dos clases heredan los atributos Cilindrada y Numero de Ruedas de la clase VehículosDeMotor pero a su vez tendrán atributos propios (como hemos dicho antes el Numero de Puertas es un atributo propio de la clase Coches que no tienen sentido en la clase Motos ). Se puede decir que Coches extiende la clase VehículosDeMotor, o que VehículosDeMotor es una generalización de las clases Coches y Motos.

25. La idea de las clases es tener un punto de referencia y describir las similitudes o diferencias que un objeto específico posee con respecto a los miembros de su propia clase.

26. CONCEPTOS BÁSICOS DE LA ORIENTACIÓN A OBJETOS Polimorfismo: Hace referencia a la posibilidad de que dos métodos implementen distintas acciones, aun teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o de los parámetros que recibe. En el ejemplo anterior teníamos dos objetos que heredaban el método acelerar() de la clase VehiculosDeMotor . De hecho en clase VehiculosDeMotor al ser general no tiene sentido que tenga una implementación concreta de este método. Sin embargo, en las clases Coches y Motos si que hay una implementación clara y distinta del método acelerar(), lo podemos ver en el código fuente 1 y 2. De este modo podríamos tener un objeto VehículosDeMotor , llamado vdm , en el que residiera un objeto Coche. Si realizáramos la llamada vdm.acelerar() sabría exactamente que ha de ejecutar el método Coches::acelerar().

28. INTRODUCCIÓN A UML UML es un lenguaje estándar que sirve para escribir los planos del software , puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real. UML es solamente un lenguaje por lo que es sólo una parte de un método de desarrollo software, es independiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, además es un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la representación conceptual y física del sistema.

29. INTRODUCCIÓN A UML UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante gráficos o mediante texto obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo ya que al ser estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño (e incluso por herramientas) sin ninguna ambigüedad. En este contexto, UML sirve para especificar , modelos concretos, no ambiguos y completos. Debido a su estandarización y su definición completa no ambigua, y aunque no sea un lenguaje de programación, UML se puede conectar de manera directa a lenguajes de programación como Java, C++ o Visual Basic, esta correspondencia permite lo que se denomina como ingeniería directa (obtener el código fuente partiendo de los modelos) pero además es posible reconstruir un modelo en UML partiendo de la implementación, o sea, la ingeniería inversa.

31. VISTAS GENERALES DE UML El lenguaje UML se compone de tres elementos básicos, los bloques de construcción, las reglas y algunos mecanismos comunes. Estos elementos interaccionan entre sí para dar a UML el carácter de completitud y no-ambigüedad que antes comentábamos. Los bloques de construcción se dividen en tres partes: Elementos , que son las abstracciones de primer nivel, Relaciones , que unen a los elementos entre sí, y los Diagramas , que son agrupaciones interesantes de elementos. Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos: elementos estructurales , elementos de comportamiento, elementos de agrupación y elementos de anotación.

32. VISTAS GENERALES DE UML Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia, relaciones de asociación, relaciones de generalización y relaciones de realización. Se utilizan diferentes diagramas dependiendo de qué, nos interese representar en cada momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle..., por esta razón UML soporta un gran numero de diagramas diferentes aunque, en la practica, sólo se utilicen un pequeño número de combinaciones.

33. ELEMENTOS ESTRUCTURALES Los elementos estructurales en UML, en su mayoría, son las partes estáticas del modelo y representan cosas que son conceptuales o materiales. Clases Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones.

34. DIAGRAMA DE CLASES Ejemplo Piense en las cosas que le rodean. Es probable que muchas de esas cosas tengan atributos (propiedades) y que realicen determinadas acciones. Podríamos imaginar cada una de esas acciones como un conjunto de tareas. También se encontrará con que las cosas naturalmente se albergan en categorías (automóviles, mobiliario, lavadoras…). A tales categorías las llamaremos clases. Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares. Por ejemplo: cualquier cosa dentro de la clase lavadora tiene atributos como son la marca, el modelo, el número de serie y la capacidad. Entre las acciones de las cosas de esta clase se encuentran: “agregar ropa”,” agregar detergente”, “activarse” y “sacar ropa”.

35. ¿Qué objetivo tiene pensar en las clases, así como sus atributos y acciones? Para interactuar con nuestro complejo mundo. La mayoría del software moderno simula algún aspecto. Décadas de experiencia sugieren que es más sencillo desarrollar aplicaciones que simulen algún aspecto del mundo cuando el software representa clases de cosas reales. Los diagramas de clases facilitan las representaciones a partir de las cuales los desarrolladores trabajan. A su vez, los diagramas de clases colaboran en lo referente al análisis. Permiten al analista hablarles a los clientes en su propia terminología. Lo cual hace posible que los clientes indiquen importantes detalles de los problemas que requieren.

36. DIAGRAMA DE OBJETOS Un objeto es una instancia de clase (una entidad que tiene valores específicos de los atributos y acciones). Su lavadora, por ejemplo podría tener la marca CENTRALES, el modelo M1, el número de serie GL57774 y una capacidad de 7Kg. El símbolo con el que UML representa a un objeto es muy similar al de una clase, pero en este caso el nombre está subrayado. El nombre de la instancia específica se encuentra a la izquierda de los dos puntos( : ), y el nombre de la clase a la derecha.

37. DIAGRAMA DE CASOS DE USO Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema , a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema . Un Uso-Caso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interactúa con el sistema: " Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo ".

38. DIAGRAMA DE CASOS DE USO Un Uso-Caso es empleado con más frecuencia en alguna de las siguientes etapas : Determinación de Requerimientos: Por lo general nuevos requerimientos de sistema generan nuevos usos-casos, conforme es analizado y diseñado el sistema. Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto. Generación de pruebas de Sistemas: A través de los diagramas uso-caso se pueden generar una serie de pruebas de sistema.

39. DIAGRAMA DE CASOS DE USO Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, ésta es una herramienta valiosa, ya que es una técnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que pueda ser utilizado por la gente en general (no sólo por expertos en computación). A la figura correspondiente al usuario de la lavadora se le conoce como actor. La elipse representa al caso de uso. El actor que inicia el caso de uso puede ser una persona u otro sistema.

40. DIAGRAMA DE ESTADOS En cualquier momento, un objeto se encuentra en un estado en particular. Una persona puede ser recién nacida, infante, adolecente, joven o adulta. Un elevador se moverá hacia arriba, estará en estado de reposo o se moverá hacia abajo. Una lavadora podrá estar en la fase de remojo. Lavado enjuague, centrifugado o apagada. El diagrama de estados intenta capturar esa realidad que sucede dentro de un sistema mostrándonos los diferentes estados que se presentan con las diferentes partes que lo conforma e interactuar con él. La notación para un diagrama de estados es la siguiente.

42. DIAGRAMA SECUENCIAS Los diagramas de clases y objetos representan la información estática. No obstante, en un sistema funcional los objetos interactúan entre sí y tales interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la mecánica de la interacción con base en tiempos. Continuando con el ejemplo de la lavadora, entre los componentes de la lavadora se encuentran: una manguera de agua (para obtener agua fresca), un tambor (donde se coloca la ropa) y un sistema de drenaje. ¿Qué sucederá cuando el usuario invoqeu el caso de uso lavar ropa? En este caso por lo menos sucederían 3 operaciones “AGREGAR ROPA”, “AGREGAR DETERGENTE” Y “ACTIVAR” la secuencia sería más o menos la siguiente

45. DIAGRAMA DE ACTIVIDADES Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un uso-caso, así como las distintas rutas que pueden irse desencadenando en el uso-caso. Es importante recalcar que aunque un diagrama de actividad es muy similar en definición a un diagrama de flujo (típicamente asociado en el diseño de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjunción de un diagrama uso-caso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como reacciona en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema , mientras un diagrama de flujo describe la solución .

46. DIAGRAMA DE ACTIVIDADES Composición Inicio : El inicio de un diagrama de actividad es representado por un círculo de color negro sólido. Actividad : Una actividad representa la acción que será realizada por el sistema la cual es representada dentro de un ovalo. Transición : Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección.

47. Actividades del diagrama de secuencias del 4 al 6

48. OTROS DIAGRAMAS Diagrama de Colaboraciones Diagrama de Componentes Diagrama de Distribución

49. OTROS DIAGRAMAS Diagrama de Distribución

50. ¿POR QUÉ TANTOS DIAGRAMAS? Los diagramas UML le permiten examinar un sistema desde distintos puntos de vista, es importante recalcar que en un modelo UML, no es necesario que aparezcan todos los diagramas. ¿Por qué es necesario contar con diferentes perspectivas del un sistema? Por lo general, un sistema cuenta con diversas personas implicadas las cuales tienen enfoques particulares en diversos aspectos del sistema. Si tenemos en cuenta el ejemplo tratado anteriormente (LAVADORA), para diseñar el motor de la lavadora se tendría una perspectiva del sistema; si se diseñan las formas que tendrá se vería de otra forma, desde el punto de vista de quien escribe los comandos de ejecución tendría una perspectiva distinta y el usuario también tendría una visión diferente a las anteriores. El diseño de un sistema completo involucra todas las posibles perspectivas, y el diagrama UML le da una forma de incorporar una perspectiva en particular. El objetivo es satisfacer a cada persona implicada.

52. DIAGRAMAS DE CLASES El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estáticas que existen entre ellos. Hay dos tipos principales de relaciones estáticas: ASOCIACIONES (por ejemplo, un diente puede rentar diversas videocintas). GENERALIZACIÓN (una enfermera es un tipo de persona). Los diagramas de clase también muestran los atributos y operaciones de una clase y las restricciones a que se ven sujetos, según la forma en que se conecten o interrelacionen los objetos que se contienen en el proyecto.

53. ABSTRACCIÓN: La abstracción consiste en captar las características esenciales de un objeto, así como su comportamiento. Por ejemplo analicemos a un automóvil, ¿Qué características podemos abstraer de los automóviles? O lo que es lo mismo ¿Qué características semejantes tienen todos los automóviles? Todos tendrán una marca, un modelo, número de chasis, peso, llantas, puertas, ventanas, etc. Y en cuanto a su comportamiento todos los automóviles podrán acelerar, frenar, retroceder, etc (clases). HERENCIA: La herencia es uno de los conceptos más cruciales en la POO. La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y métodos propios, tiene incorporados los atributos y métodos heredados de la superclase. De esta manera se crea una jerarquía de herencia. Por ejemplo, imaginemos que estamos haciendo el análisis de un Sistema para una tienda que vende y repara equipos celulares. http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/ CONCEPTOS CLAVE DE APRENDIZAJE

54. En el gráfico vemos 2 Clases más que posiblemente necesitemos para crear nuestro Sistema. Esas 2 Clases nuevas se construirán a partir de la Clase Celular existente. De esa forma utilizamos el comportamiento de la SuperClase.

55. POLIMORFISMO En ocasiones una operación tiene el mismo nombre en diferentes clases. Por ejemplo, podrá abrir una puerta, una ventana, un periódico, un regalo o una cuenta de banco, en cada uno de estos casos, realizará una operación diferente. En el polimorfismo una operación puede tener el mismo nombre en diversas clases y puede realizar operaciones propias o funcionar de modo distinto en cada una,

56. ENCAPSULAMIENTO El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.

57. ENVÍO DE MENSAJES Un objeto es inútil si está aislado. El medio empleado para que un objeto interactúe con otro son los mensajes. Hablando en términos un poco más técnicos, los mensajes son invocaciones a los métodos de los objetos. Todos los objetos trabajan en conjunto. Esto se logra mediante el envío de mensajes entre ellos. Un objeto envía a otro un mensaje para realizar una operación y el objeto receptor ejecutará la operación.

58. ASOCIACIONES La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

59. ASOCIACIONES Con Frecuencia los objetos se relacionan entre si de alguna forma. Cuando usted enciende su televisión tendrá una asociación en una sola dirección con ella En ocasiones, un objeto podría asociarse en más de una forma , por ejemplo 2 personas (Jefe y empleado) al mismo tiempo pueden ser amigos

60. ASOCIACIONES Una clase se puede asociar con más de una clase distinta una persona puede viajar en automóvil, pero también puede hacerlo en autobús. La multiplicidad o diversificación es un importante aspecto de las asociaciones entre objetos indica la cantidad de objetos de una clase que se relacionan con otro objeto en particular de la clase asociada. Por ejemplo en un curso escolar, el curso se imparte por un solo instructor, en consecuencia, el curso y el instructor están en asociación 1 a 1. sin embargo en un seminario hay diversos instructores que impartirán el curso a lo largo del semestre, por lo tanto el curso y el instructor tienen una asociación de 1 a N Otros ejemplos una bicicleta rueda en 2 neumáticos (1:2), un triciclo rueda en 3 (1:3), entre otros.

61. Una asociación es una relación estructural que describe una conexión fuerte entre los objetos de las clases. Gráficamente, se muestra como una línea continua que une las clases relacionadas entre sí, NAVEGACIÓN EN LAS ASOCIACIONES: Aunque las asociaciones suelen ser bidireccionales (se pueden recorrer en ambos sentidos), en ocasiones es deseable hacerlas unidireccionales (restringir su navegación en un único sentido). Gráficamente, cuando la asociación es unidireccional, la línea termina en una punta de flecha que indica el sentido de la asociación,

62. Class Cuenta { private Dinero balance; public void ingresar (Dinero cantidad) { balance = balance + cantidad; } public void retirar (Dinero cantidad) { balance = balance – cantidad; } public Dinero getSaldo () { return balance; } } En este ejemplo se supone que Dinero es un tipo de dato con el que se pueden hacer operaciones aritméticas y se ha añadido una operación adicional que nos permite comprobar el saldo de una cuenta,

63. AGREGACIÓN Para entender este término vamos a analizar una computadora, cuenta con un teclado, un ratón, un DVD, uno o varios discos duros, una tarjeta de video, una impresora, entre otros elementos. Al analizar este ejemplo llegamos a la conclusión que la computadora es una agregación o adición, ya que el equipo está constituido de diversos tipos de componentes . Una computadora es un ejemplo de agregación: un objeto que se conforma de una combinación de diversos tipos de objetos.

64. COMPOSICIÓN El punto central de la composición es que el componente hace parte de un objeto compuesto. Por ejemplo una camisa está compuesta de cuerpo, cuello, mangas, botones, ojales y puños. Si se suprime la camisa el cuello será inútil. En ocasiones, un objeto compuesto no tiene el mismo tiempo de vida que sus propios componentes. Las hojas de un árbol puede morir antes de que el árbol. Si se destruye al árbol, también las hojas morirán, LA agregación y la composición son importantes dado que reflejan casos extremadamente comunes, y ello ayuda a que cree modelos que se asemejen considerablemente a la realidad. En una composición, un componente Puede morir antes que el objeto Compuesto. Si destruye el objeto Compuesto, destruirá también a los Componentes,