Desarrollo Orientado a Objetos

Desarrollo de Proyectos de Software. L.I. Marco Antonio Ruiz V. ITSTE

Enfoque de Orientacin a Objetos

El enfoque de orientacin a objetos es una forma de observar la realidad. El enfoque como su nombre lo indica se basa en el concepto de objeto:
Es todo aquello que tiene caractersticas que lo hacen nico e indivisible dentro del entorno al que pertenece. Siempre es posible establecer propiedades o atributos de un objeto, lo mismo que su grado de respuesta a estmulos externos (comportamientos del objeto). percibimos tal cual por sus caractersticas y su respuesta ante el entorno. Un elemento notable es que las caractersticas de un objeto pueden ser por s mismas otros objetos.

La orientacin a objetos promete mejoras de amplio alcance en la forma de diseo, desarrollo y mantenimiento del software ofreciendo una solucin a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del cdigo y reusabilidad, cdigo que es difcil de modificar, ciclos de desarrollo largos y tcnicas de codificacin no intuitivas.

Un lenguaje orientado a objetos ataca estos problemas. Tiene tres caractersticas bsicas:

basado en objetos,

basado en clases y
capaz de tener herencia de clases.

El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organizacin.
Esta definicin especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto nmero de componentes bien estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organizacin jerrquica o de otro tipo.

Estructura de un Objeto
Un objeto puede considerarse como una especie de cpsula dividida en tres partes: 1. RELACIONES. Las relaciones permiten que el objeto se inserte en la organizacin y estn formadas esencialmente por punteros a otros objetos. 2. PROPIEDADES Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organizacin y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organizacin. 3. MTODOS. Los mtodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarn incorporados en forma de programas (cdigo) que el objeto es capaz de ejecutar y que tambin pone a disposicin de sus descendientes a travs de la
herencia.

Clases e Instancias
Dentro de la definicin de objetos hay algunos que sern muy parecidos ya sea que comparten la misma definicin de caractersticas. Una clase es una ayuda notacional en el anlisis para establecer las propiedades y funciones que sern comunes a todos los objetos que se generen a partir de ella, tal y como lo muestra la siguiente imagen.

En la notacin de la metodologa UML se utiliza un rectngulo con tres divisiones para definir una clase. En la primera se indica el nombre de la clase, la segunda contendr todas las propiedades del objeto y la tercera contiene las funciones por media de las cuales el objeto responde a estmulos de su entorno.
En el enfoque orientado a objetos, todos los objetos se generan a partir de clases. Incluso cuando solo se genere uno, de forma que todo objeto est asociado a la clase a partir de la que se gener y se dice que dicho objeto es una instancia de clase que puede usar directamente las caractersticas y funciones asociadas a la clase.

La clase es un elemento conceptual que permite definir y modelar, el objeto o instancia de clase es una ejemplificacin de clase. Una instancia de clase tiene valores de atributos y puede invocar sus mtodos.

Encapsulamiento
Cuando interactuamos con un objeto nicamente nos interesa conocer las caractersticas y atributos que nos permiten establecer dicha interaccin, es decir el objeto publica ciertas caractersticas y mtodos, pero encapsula las dems ya que no es fundamental para el exterior conocerlas para poder interactuar con el objeto. nicamente se requiere conocer aquellas que se exhiban como pblicas.

Polimorfismo
El polimorfismo se define como la caracterstica de que un objeto que pide la ejecucin de una funcin a otro objeto no necesita saber la naturaleza del objeto dueo de la funcin. El polimorfismo ms comn lo tenemos en un operador como el de suma o multiplicacin, ya que la operacin se realiza aun cuando los operndoos sean distintos. La implementacin del operador tiene el cuidado de hacer correctamente la operacin para el tipo de datos que est participando como se muestra a continuacin:

Herencia
El concepto de herencia va asociado a la Generalizacin Especializacinen el que se establece que cierta clase de objetos puede tener clases de objetos ms especializados las cuales por ser especializaciones, tendrn todos los elementos de la clase genrica y modificarn la funcionalidad heredada o agregarn nueva funcionalidad para especializarse.
En la notacin UML la relacin de herencia entre dos clases se indica por medio de una flecha hueca que apunta a la clase ascendiente, esto es porque, en una relacin de herencia el padre no se construye teniendo en cuenta que se pueden derivar de l clases ms especializadas.

Por otro lado las clases que son descendientes es importante que sepan quin es su ascendiente pues de l estn tomando propiedades y funciones.

Las clases que no generan directamente instancias se denominan abstractas, y aquellas que generan directamente objetos se les denominan concretas.

Asociaciones estticas
Permiten la estructuracin de los objetos incorporando reglas del negocio. En su forma ms simple es un vnculo entre dos objetos. Al nivel de anlisis se documentan como vnculos entre clases, sin embargo, es importante recordar que las clases son definiciones generales de un tipo de objeto, lo que implica que no son colecciones de objetos y por lo tanto las asociaciones estticas no son asociaciones entre conjuntos de objetos como se pueden dar en el modelo Entidad Relacin tradicional.

La asociacin se indica con una lnea uniendo a las dos clases. La lnea puede tener una etiqueta que indique la forma en la que se est interpretando la asociacin. Muchas reglas del negocio se refieren a los niveles mximos y mnimos de vinculacin entre distintos objetos de la aplicacin. Por ejemplo, un objeto Cliente solo debe estar asociado a un solo agente de Ventas, aunque un Agente Vendedor puede estar vinculado a ms de un cliente. Este tipo de informacin es la multiplicidad o cardinalidad de la asociacin y se indica colocando un rango en los extremos de la asociacin.

Existen casos en los que una clase se asocia con ms de una clase, en donde es conveniente no slo mostrar la multiplicidad, sino tambin cmo el analista concibe el vnculo de la clase en cada asociacin. En estos casos se le define un rol a la clase en a cada asociacin que participa como se muestra en la siguiente imagen:

Asociaciones de agregacin o composicin.

Un caso particular de asociacin esttica, es cuando se encuentra que un objeto no slo est asociado con otro, sino que adems uno es parte del otro. Este tipo de situacin se le llama asociacin de agregacin. La agregacin podemos establecerla en dos tipos: por composicin y por agregacin simple como se muestra en la figura 1.6. En la primera, los objetos y la asociacin se dieron simultneamente y cuando desaparezca un objeto, el otro tambin desaparecer, as como la asociacin. Por lo regular se da cuando modelamos un objeto como propiedad de otro objeto.

La agregacin simple es la ms comn y se da cuando tenemos documentos, tales como facturas, rdenes de entrada de almacn, recibos de pago, etc. Ya que el documento es el objeto central y tiene una serie de caractersticas con cierto grado de opcionalidad, que hacen no necesiten estar los dos para que la agregacin se d.
En UML la agregacin se denota con un rombo en el extremo de la asociacin en donde se encuentra la clase a la que se le estn agregando objetos. La agregacin por composicin se denota con el rombo slido, mientas que la agregacin simple es con el rombo vaco.

En general es conveniente indicar las asociaciones de agregacin pues sugieren que las operaciones de mantenimiento a esos objetos tienen que hacerse dentro de una misma transaccin, lo cual ayuda a identificar la complejidad de los modelos de objetos que se estn obteniendo. Siempre ser ms fcil dar mantenimiento a una familia de objetos que a dos o ms familias de objetos como lo sugieren las asociaciones de agregacin.