Instituto Tecnologico de Oaxaca

Materia: Programacin Orientada a Objetos Profesor: Miguel ngel Rodrguez Morales

Alumna: Susana Sofa Miguel Bernardino

Contenido UNIDAD 1. INTRODUCCIN AL PARADIGMA DE LA PROGRAMACIN ORIENTADA A OBJETOS ..................................2

1.1 ELEMENTOS DEL MODELO DE OBJETOS: ........................... 2 CLASES ........................................................................................ 2 OBJETOS ..................................................................................... 3 Modelo de objetos ...........................................................................4 a.) Principio de Abstraccin .......................................................... 4 b.) Principio de Encapsulamiento ................................................. 4 c.) Principio de Modularidad ......................................................... 5 d.) Principio de Jerarqua .............................................................. 5 e.) Principio del Paso de Mensajes .............................................. 6 f.) Principio de Polimorfismo ......................................................... 6 1.2 LENGUAJE DE MODELADO UNIFICADO ............................... 6 DIAGRAMA DE CLASES ............................................................. 6

UNIDAD 1. INTRODUCCIN AL PARADIGMA DE LA PROGRAMACIN ORIENTADA A OBJETOS

La orientacin a objetos es un paradigma de programacin que facilita la creacin de software de calidad por sus factores que potencian el mantenimiento, la extensin y la reutilizacin del software generado bajo este paradigma. La programacin orientada a objetos trata de amoldarse al modo de pensar del hombre y no al de la mquina. Esto es posible gracias a la forma racional con la que se manejan las abstracciones que representan las entidades del dominio del problema, y a propiedades como la jerarqua o el encapsulamiento. El elemento bsico de este paradigma no es la funcin (elemento bsico de la programacin estructurada), sino un ente denominado objeto. Un objeto es la representacin de un concepto para un programa, y contiene toda la informacin necesaria para abstraer dicho concepto: los datos que describen su estado y las operaciones que pueden modificar dicho estado, y determinan las capacidades del objeto. Java incorpora el uso de la orientacin a objetos como uno de los pilares bsicos de su lenguaje.
1.1 ELEMENTOS DEL MODELO DE OBJETOS: CLASES

Las clases son abstracciones que representan a un conjunto de objetos con un comportamiento e interfaz comn. Podemos definir una clase como "un conjunto de cosas (fsicas o abstractas) que tienen el mismo comportamiento y caractersticas... Es la implementacin de un tipo de objeto (considerando los objetos como instancias de las clases)". [Piattini et al., 1996]. Una clase no es ms que una plantilla para la creacin de objetos. Cuando se crea un objeto ( instanciacin ) se ha de especificar de qu clase es el objeto instanciado, para que el compilador comprenda las caractersticas del objeto.

Las clases presentan el estado de los objetos a los que representan mediante variables denominadas atributos. Cuando se instancia un objeto el compilador crea en la memoria dinmica un espacio para tantas variables como atributos tenga la clase a la que pertenece el objeto. Los mtodos son las funciones mediante las que las clases representan el comportamiento de los objetos. En dichos mtodos se modifican los valores de los atributos del objeto, y representan las capacidades del objeto (en muchos textos se les denomina servicios ). Desde el punto de vista de la programacin estructurada, una clase se asemejara a un mdulo, los atributos a las variables globales de dicho mdulo, y los mtodos a las funciones del mdulo.
OBJETOS

Podemos definir objeto como el "encapsulamiento de un conjunto de operaciones (mtodos) que pueden ser invocados externamente, y de un estado que recuerda el efecto de los servicios". [Piattini et al., 1996]. Un objeto adems de un estado interno, presenta una interfaz para poder interactuar con el exterior. Es por esto por lo que se dice que en la programacin orientada a objetos "se unen datos y procesos", y no como en su predecesora, la programacin estructurada, en la que estaban separados en forma de variables y funciones. Un objeto consta de:
y

Tiempo de vida: La duracin de un objeto en un programa siempre est limitada en el tiempo. La mayora de los objetos slo existen durante una parte de la ejecucin del programa. Los objetos son creados mediante un mecanismo denominado instanciacin , 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 mtodos, para que el resto de objetos que componen los programas puedan interactuar con l.

El equivalente de un objeto en el paradigma estructurado sera una variable. As mismo la instanciacin de objetos equivaldra a la declaracin de variables , y el tiempo de vida de un objeto al mbito de una variable.
Modelo de objetos

Existen una serie de principios fundamentales para comprender cmo se modeliza la realidad al crear un programa bajo el paradigma de la orientacin a objetos. Estos principios son: la abstraccin, el encapsulamiento, la modularidad, la jerarqua, el paso de mensajes y el poliforfismo.
a.) Principio de Abstraccin

Mediante la abstraccin la mente humana modeliza la realidad en forma de objetos. Para ello busca parecidos entre la realidad y la posible implementacin de objetos del programa que simulen el funcionamiento de los objetos reales. Los seres humanos no pensamos en las cosas como un conjunto de cosas menores; por ejemplo, no vemos un cuerpo humano como un conjunto de clulas. Los humanos entendemos la realidad como objetos con comportamientos bien definidos. No necesitamos conocer los detalles de porqu ni cmo funcionan las cosas; simplemente solicitamos determinadas acciones en espera de una respuesta; cuando una persona desea desplazarse, su cuerpo le responde comenzando a caminar. Pero la abstraccin humana se gestiona de una manera jerrquica, dividiendo sucesivamente sistemas complejos en conjuntos de subsistemas, para as entender ms fcilmente la realidad. Esta es la forma de pensar que la orientacin a objeto intenta cubrir.
b.) Principio de Encapsulamiento

El encapsulamiento permite a los objetos elegir qu informacin es publicada y qu informacin es ocultada al resto de los objetos. Para ello los objetos suelen presentar sus mtodos como interfaces pblicas y sus atributos como datos privados e inaccesibles desde otros objetos. Para permitir que otros objetos consulten o modifiquen los atributos de los objetos, las clases suelen presentar mtodos de acceso. De

esta manera el acceso a los datos de los objetos es controlado por el programador, evitando efectos laterales no deseados. Con el encapsulado de los datos se consigue que las personas que utilicen un objeto slo tengan que comprender su interfaz, olvidndose de cmo est implementada, y en definitiva, reduciendo la complejidad de utilizacin.
c.) Principio de Modularidad

Mediante la modularidad, se propone al programador dividir su aplicacin en varios mdulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos con un sentido propio. Esta fragmentacin disminuye el grado de dificultad del problema al que da respuesta el programa, pues se afronta el problema como un conjunto de problemas de menor dificultad, adems de facilitar la comprensin del programa.
d.) Principio de Jerarqua

La mayora de nosotros ve de manera natural nuestro mundo como objetos que se relacionan entre s de una manera jerrquica. Por ejemplo, un perro es un mamfero, y los mamferos son animales, y los animales seres vivos... Del mismo modo, las distintas clases de un programa se organizan mediante la jerarqua. La representacin de dicha organizacin da lugar a los denominados rboles de herencia:

Imagen 1: Ejemplo de rbol de herencia

Mediante la herencia una clase hija puede tomar determinadas propiedades de una clase padre . As se simplifican los diseos y se

evita la duplicacin de cdigo al no tener que volver a codificar mtodos ya implementados. Al acto de tomar propiedades de una clase padre se denomina heredar.
e.) Principio del Paso de Mensajes

Mediante el denominado paso de mensajes , un objeto puede solicitar de otro objeto que realice una accin determinada o que modifique su estado. El paso de mensajes se suele implementar como llamadas a los mtodos de otros objetos. Desde el punto de vista de la programacin estructurada, esto correspondera con la llamada a funciones.
f.) Principio de Polimorfismo

Polimorfismo quiere decir "un objeto y muchas formas". Esta propiedad permite que un objeto presente diferentes comportamientos en funcin del contexto en que se encuentre. Por ejemplo un mtodo puede presentar diferentes implementaciones en funcin de los argumentos que recibe, recibir diferentes nmeros de parmetros para realizar una misma operacin, y realizar diferentes acciones dependiendo del nivel de abstraccin en que sea llamado.

1.2 LENGUAJE DE MODELADO UNIFICADO DIAGRAMA DE CLASES

Antes de entrar a lo que es diagrama de clases tenemos que tener en cuenta que una clase son los componentes fundamentales de los diagramas de clases la notacion general para una clase es un rectangulo dividido en tres secciones, mostrando la primera con el nombre de la clase la siguiente los atributos y la ultima las operaciones.

Los atributos:son muy parecidos a las asociaciones. Desde un nivel conceptual, el atributo de nombre de un Cliente indica que los Clientes tienen nombres. Desde el nivel de especificacin, este atributo indica que un objeto Cliente puede decir su nombre y tiene algn modo de establecer un nombre. Dependiendo del detalle del diagrama, la notacin de un atributo puede mostrar el nombre, el tipo y el valor predeterminado de un atributo (la sintaxis del UML es visibilidad /nombre: tipo = valor por omisi6n, donde la visibilidad es igual que la de las operaciones. Las operaciones:son los procesos que una clase sabe llevar a cabo. Evidentemente corresponden a los mtodos sobre una clase. En el nivel de especificacin, las operaciones corresponden a los mtodos pblicos. En general, no se muestran aquellas operaciones que simplemente manipulan atributos, ya que por lo comn, se pueden inferir. sobre un tipo.

En la sintaxis del UML completa para las operaciones es visibilidad nombre (lista -de-parmetros): expresi611-tipo-de-dato-a-regresar {cadena-de-propiedades} Donde visibilidad es + (public), # (protected), 0- (private) nombre es una cadena de caracteres (string) lista-de-parmetros contiene argumentos (opcionales) cuya sintaxis es la misma que la de 105 atributos expresin,,-tipo-de-dato-a-regresar es una especificacin opcional dependiente del lenguaje cadena-de-propiedades indica valores de propiedad que se aplican a la operacin dada
Los diagramas de clases: se utilizan para mostrar la estructura esttica del sistema modelado pueden contener clases, interfaces, paquetes, relaciones e incluso instancias, como objetos o enlaces. Los diagramas de clases son una potente herramienta de diseo ayudando a los desarrolladores a planificar y establecer la arquitectura y estructura del sistema y subsistema antes de escribir el ningncdigo esto permite asegurar que el sistema este bien diseado desde el principio. adems estos diagramas de clases son usadas prcticamente en la totalidad de sistema en que se utilizan UML para su modelado.Estos diagramas muestran la vista de

diseo esttica de un sistema a travs de un conjunto de clases, interfaces y colaboraciones junto con sus relaciones. El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estticas que existen entre ellos. Hay dos tipos principales de relaciones estticas:Asociaciones (por ejemplo, un diente puede rentar diversas videocintas).Subtipos (una enfermera es un tipo de persona). Los diagramas de clase tambin muestran los atributos y operaciones de una clase y las restricciones a que se ven sujetos, segn la forma en que se conecten los objetos.
Existen algunos estereotipos muy comunes con elementos preestablecidos: <<Boundary>>: indica que la clase constituye la frontera o interfaz entre el sistema modelado y el exterior. Se aplica a formularios, informes, interfaces, y similares <<Control>>: indica que la clase es una clase de control que se dedica a labores de coordinacin <<Entity>>: contiene la informacin significativa del sistema y generalmente son guardadas en almacenamiento externo esto es son clases persistentes. Hay tres perspectivas que se pueden manejar al dibujar diagramas de clase. Conceptual: Si se adopta la perspectiva conceptual, se dibuja un diagrama que represente los conceptos del dominio que se est estudiando. Estos conceptos se relacionan de manera natural con las clases que los implementan, pero con frecuencia no hay una correlacin directa. Especificacin: cuando estn viendo el software, lo que se observa son las interfaces del software, no su implementacin. Por tanto, en realidad vemos los tipos, no las clases. El desarrollo orientado a objetos pone un gran nfasis en la diferencia entre

interfaz e implementacin, pero esto con frecuencia se pasa por alto en la prctica, ya que el concepto de clase en un lenguaje 00 combina tanto la interfaz como la implementacin.

Implementacin: Dentro de esta concepcin, realmente tenemos clases y exponemos por completo a implementacin. esta es, probablemente, la perspectiva ms empleada, pero en muchos sentidos es mejor adoptar la perspectiva de especificacin. La comprensin de la perspectiva es crucial tanto para dibujar como para leer los diagramas de clase.

cuando estemos dibujando un diagrama, se tiene que hacer desde el punto de vista de una sola perspectiva clara. Cuando se lee un diagrama, se debe saber desde qu perspectiva se dibuj. Dicho conocimiento es esencial si se quiere interpretar correctamente el diagrama. La perspectiva no es parte del UML formal, pero es Extremadamente valiosa al modelar y revisar los modelos que el UML se puede utilizar con las tres perspectivas. Mediante el etiquetado de las clases con un estereotipo. La navegabilidad es una parte importante de los diagramas de implementacin y especificacin. Frecuentemente ver diagramas conceptuales que primero no tendrn navegabilidades. Posteriormente, se agregarn las navegabilidades como parte del cambio a perspectivas de especificacin y de implementacin Si existe una navegabilidad en una sola direccin, a la asociacin se le llama asociacin unidireccional. Una asociacin bidireccional contiene navegabilidades en ambas direcciones. ElUML dice que las asociaciones sin flechas significan que la navegabilidad es desconocida o que la asociacin es bidireccional . Las asociaciones bidireccionales incluyen una restriccin adicional, que consiste en que ambos papeles son inversos entre ellos.