• Author / Uploaded
• lord_helix_hell666

Citation preview

UNIVERSIDAD DE EL SALVADOR FACULTAD DE INGENIERÍA Y ARQUITECTURA ESCUELA DE INGENIERÍA DE SISTEMAS INFORMÁTICOS PROGRAMACIÓN I

Unidad VI INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS

Objetivo: Conocer los conceptos básicos de la programación orientada a objetos; además se y aplicarlos en la solución de problemas. Contenido: • • • • •

Introducción Programación Orientada a Objetos Terminología Básica Técnicas de la Programación Orientada a Objetos Lenguaje de Modelado UML

1 2 3 9 10

Introducción: Los conceptos de la Programación Orientada a Objetos (POO) tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones con naves aéreas. La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre BASIC) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar en tiempo de ejecución en lugar de tener un sistema basado en programas estáticos. La Programación Orientada a Objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. El “Eiffel de Bertrand Meyer” (1985) fue un tempranero y moderadamente acertado lenguaje que cumplía con los objetivos de la POO; pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha modificado y, soporta una orientación a objetos de forma completa.

MCP – CAH

ciclo II - 2011

Página 1

1. Concepto La Programación Orientada a Objetos es un enfoque conceptual específico para diseñar programas, Es una forma de programar diferente concentrándose sobre todo en lo que se requiere obtener y no en cómo obtenerlo. Esta técnica, se basa en el representación del problema en modelos de objetos físicos o simulados; aunque la idea es abstracta y parece muy complicada, cuando se aplica a objetos físicos en términos de sus clases, componentes, propiedades y comportamiento se vuelve más clara. La idea fundamental de la orientación a objetos y de los lenguajes que implementan este paradigma de programación es combinar (encapsular) en una sola unidad tanto los datos como las funciones que operan (manipulan) sobre los datos. Esta característica permite representar los objetos del mundo real, mucho más eficientemente que con funciones y datos de forma separada o independiente (cómo lo hace Programación Estructurada).

2. Generalidades La POO (Programación Orientada a Objetos), es un paradigma que utiliza objetos como elementos fundamentales en la construcción de una solución. Un objeto es una abstracción de algún hecho ó ente del mundo real que tiene atributos que representan sus características y propiedades; y métodos que representan su comportamiento. Todas las propiedades y métodos comunes entre objetos se encapsulan o se agrupan en clases. Las propiedades más importantes de la POO son: • • • • •

Abstracción Encapsulamiento y ocultación de datos Polimorfismo Herencia Reusabilidad o reutilización de código

3. ¿Programación Estructurada ó Programación Orientada a Objetos? La POO difiere de la Programación Estructurada tradicional, en la forma en son manejados los datos y los procedimientos, en PE estos (datos y procedimientos) están separados y sin ninguna relación entre ellos; ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La Programación Estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. Con esta técnica de programación, se diseñan módulos (o funciones) , que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos. Para realizar una comparación listaremos las ventajas y desventajas de estas dos formas de programación:

MCP – CAH

ciclo II - 2011

Página 2

Técnica de programación

Orientada a Objetos (POO)

Estructurada (PE)

Ventajas

Desventajas

Fomenta la reutilización del código Facilita la creación de programas visuales Agiliza el desarrollo de software Permite crear sistemas más complejos Son más fáciles de entender

Mayor complejidad para adaptarse Depuración de código más compleja

Cuando crece el código se dificulta el manejo del código fuente La estructura de los programas La reutilización de código es clara no se explota tanto como en la POO El mantenimiento es fácil Los bloques de código son casi auto explicativos Programas más sencillos y rápidos de confeccionar Es más fácil realizar pruebas y depuración de los bloques

La Programación Estructurada es la primera técnica formal de programación (nació a inicios de los 60’), sigue estando en vigencia y es muy utilizada para iniciar el aprendizaje de programación. La programación orientada a objetos es una mejora de la programación estructurada; sin embargo, la mayor diferencia que existe entre ambas es la forma en que se organizan los programas. En la actualidad se ha notado que muchas personas desean aprender POO dejando de lado la PE, esto es un error, ya que PE es la base de POO ya que esta última utiliza técnicas como: modularidad, estructura de datos entre otras. Por lo tanto si se desea aprender POO primero hay que dominar la PE. La Programación Estructurada es ideal para realizar programas sencillos y para iniciar la programación. La Programación Orientada a Objetos es recomendada para resolver problemas más complejos y requiere un mayor nivel de abstracción del problema.

A continuación se definen algunos elementos básicos de la programación orientada a objetos con el objetivo de familiarizarse con esta forma de programación. 1. Objeto Es el centro de la programación orientada a objeto. Un objeto es algo que se visualiza, se utiliza y que juega un papel o un rol. En POO el objeto representa alguna entidad de la vida real. A través del estudio de ellos se adquiere el conocimiento necesario para (mediante la abstracción y la generalización) agruparlos según sus características en conjuntos. MCP – CAH

ciclo II - 2011

Página 3

Un objeto es cualquier elemento del medio ambiente real del problema que vamos a resolver; posee características fundamentales: •

Identidad: En programación la identidad de los objetos sirve para verificar mediante sus características si dos objetos son iguales o no.

•

Comportamiento: El comportamiento de un objeto está directamente relacionado con su funcionalidad y determina las operaciones que este puede realizar o a las que puede responder ante mensajes enviados por otros objetos.

•

Estado: El estado de un objeto se refiere al conjunto de los valores de sus atributos en un instante de tiempo dado. El comportamiento de un objeto puede modificar el estado de éste. Cuando una operación de un objeto modifica su estado se dice que esta tiene "efecto colateral".

2. Atributo Los atributos son las características individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades. Son propiedades del objeto, por ejemplo para el objeto automóvil, algunos de sus atributos son: propietario, marca, año de matrícula, potencia etc. Atributos son los datos o variables que caracterizan el objeto y cuyos valores indican en un momento dado su estado. Para el objeto estudiante algunos de sus atributos podrían ser: carnet, nombre, carrera, asignaturas aprobadas, etc. La identidad y estado de los objeto, tienen que ver con los atributos, y estos pueden ser modificados por el comportamiento de los objetos. 3. Clase Una clase es la representación de un conjunto de objetos del mismo tipo, es decir que los distinguen los mismos atributos y las mismas funciones (o comportamiento). Es la definición (o implantación) de un tipo abstracto de datos; es decir que una clase describe no solo los atributos de los objetos que la forman, sino que también incluye sus procesos (funciones o comportamiento). “Una clase es una caracterización abstracta de un conjunto de objetos ”

Luis Joyanes

Aguilar.

4. Métodos Son las operaciones (acciones o funciones) definidas para los objetos, y permiten crearlos, cambiar su estado o consultar el valor de los atributos. Cuando se llama a una operación de un objeto se interpreta como el envío de mensaje a dicho objeto. En otras palabras, un método es una subrutina asociada a una clase. Algunos de los diferentes tipos de método que existen son los siguientes: • Método Get (para ver o consultar valores de atributos) • Método Set (para asignar valores de atributos) • Métodos de actualización (para cambiar valores por medio de cálculos) MCP – CAH

ciclo II - 2011

Página 4

5. Relaciones entre clases: Los objetos del medio ambiente que nos rodea, no permanecen aislados y separados unos de los otros, todo lo contrario se comunican entre sí para poder apoyarse y ayudarse entre sí. De la misma forma las clases que forman parte del ambiente de un problema se relacionan entre sí y con ello se permite que los objetos colaboren entre sí e intercambien información. Las relaciones entre clases pueden ser las siguientes: • Asociación: Es la relación más importante y común entre clases. Refleja una relación entre dos clases independientes que se mantiene durante la vida de los objetos de dichas clases o al menos durante un tiempo prolongado. •

Agregación: Es un tipo especial de asociación donde se parte de la idea que la clase de donde parte la relación representa el “todo” y las clases relacionadas a ésta “las partes”. Es decir que las partes pueden seguir funcionando aun sin el todo.

•

Composición: Este tipo de relación entre clases indica dependencia entre ellas (las clases), indica que una clase es parte esencial de otra; es una relación mucho más fuerte que la agregación ya que de eliminarse una clase, deja de existir la otra. Dicho de otra forma, si la clase origen “el todo” se elimina o destruye, las otras clases (o “las partes”) también se destruyen.

•

Dependencia: Esta relación indica la necesidad de una clase hacia otra, es decir que la implantación de una clase depende de otra; los métodos u operaciones de una clase requiere de los atributos de los objetos de la otra clase.

•

Herencia: Indica que una subclase hereda los métodos y atributos especificados por una Superclase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Superclase.

6. Modelado Un modelo es la representación gráfica de una situación real; por lo tanto, modelado implica realizar un esquema (gráfico o dibujo). A continuación se definen algunos elementos necesarios para el modelado de sistemas utilizando la POO. 6.1 Diagrama de clases Es una representación gráfica de las clases de un sistema. Sirve para modelar el sistema en términos de sus clases, atributos y las relaciones entre estos elementos. En el diagrama se representan los requerimientos, y la arquitectura general del sistema en estudio. Este diagrama se utiliza en la etapa de análisis del problema y diseño de la solución. Los símbolos más utilizados en este diagrama son: RECTANGULO: Que representa una clase, dividido en tres partes, una para el nombre de la clase, otra para los atributos y la última para los métodos o funciones.

MCP – CAH

ciclo II - 2011

Página 5

NombreClase •

Atributos

•

Métodos

FLECHAS: Que indican la relación que existe entre dos clases. Las flechas pueden ser continuas o punteadas, pueden tener punta o no y está se puede sustituir por rombos. Según sea la relación que esta indique, como se verá más adelante:

6.2 Multiplicidad en las relaciones de clases Un concepto que va ligado al de las relaciones es el de la Cardinalidad (o multiplicidad), que indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: • uno a muchos: 1..* (1..n) • 0 a muchos: 0..* (0..n) • número fijo: m (m denota el número). 6.3 Reglas para nombrar clase, atributos y métodos. Para poder distinguir una clase de otra, siempre es importante y necesario identificarlos con un nombre que las diferencie entre sí, para los atributos y métodos debe hacerse también esta distinción. Existen unas pocas reglas o convenciones que siempre es bueno guardar para nombrarlos: 1. Se usan letras preferiblemente, no se deben utilizar símbolos. 2. La primera siempre va en mayúsculas, las demás en minúsculas. 3. Si se utilizan dos o más palabras, se escriben unidas, sin espacio y las iniciales con mayúsculas. 4. Los nombres siempre van en singular. 5. Los nombres de atributos y métodos, se escriben con letras minúsculas.

Para poder ejemplificar un diagrama de clases, que como ya dijimos incluyen las clases y sus relaciones, vamos a ampliar un poco más sobre las relaciones de asociación y agregación, que son las que se utilizan con frecuencia: Asociación Esta relación se establece cuando dos clases tienen una dependencia de utilización, es decir que una clase utiliza atributos y/o métodos de otra clase para funcionar, ambas clase tienen la misma jerarquía, es decir que ninguna es parte de la otra.

MCP – CAH

ciclo II - 2011

Página 6

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Ejemplo:

Note que las 2 clases están unidas por una línea y no por una flecha, porque: Cuando las flechas van de izquierda a derecha y de arriba hacia abajo, se puede omitir la punta de la flecha.

Un cliente puede tener asociadas muchas Órdenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

Agregación: Con este tipo de relación se indica que un objeto forma parte de otro objeto; por ejemplo si tenemos un objeto: computadora, esta tiene un monitor, que es otro objeto; el monitor forma parte de la computadora; por lo tanto tienen una relación de agregación. Esta relación también es conocida como “forma parte de …”

Ejemplo:

Aquí las flechas tienen punta ya que están inclinadas. El rombo vacio indica una relación de agregación (siendo la clase Almacen “el todo” y la clase cliente representa “la parte”). El rombo relleno indica una relación de composición, otro tipo de relación.

• •

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias, es decir el objeto que está formado por los otros: el todo y las partes). Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

6.4 Pasos para crear el Diagrama de Clases (sin métodos) 1. Listar clases candidatas 2. Representar las clases en un diagrama de clases 3. Agregar asociaciones 4. Agregar atributos necesarios 6.5 Ejemplo de creación de un Diagrama de Clases: Enunciado: Jugar Dados En un juego de dados, un jugador toma dos dados y los lanza. Luego, se suman los valores de las caras superiores de los dados. Si el valor es 7 gana el juego, de lo contrario pierde. 1. Listar clases • Juego de Dados - clase MCP – CAH

ciclo II - 2011

Página 7

• • • •

Jugador Dado Valor de la cara Resultado

- clase - clase - atributo de cada dado - Es la suma de las caras

2. Representar clases en un diagrama de clases • Clases identificadas • Juego de Dados • Jugador • Dado

3. Agregar asociaciones • Asociaciones identificadas • Jugador lanza Dados • Jugador juega Juego de Dados • Dados son parte del Juego de Dados • Jugador utiliza Dado

4. Agregar atributos • Jugador: nombre del jugador • Dado: valor de la cara

De esta manera el Diagrama de clases, únicamente con atributos y relaciones, queda así:

MCP – CAH

ciclo II - 2011

Página 8

1. Abstracción Una forma de reducir la complejidad de un problema o situación es la abstracción. Las características y procesos de cualquier sistema se resumen en los aspectos más esenciales y relevantes. En computación, la abstracción es el proceso crucial de representar la información en términos de su interfaz con el usuario. Un ejemplo de abstracción expresada de diferentes formas según la aplicación a desarrollar, puede ser un auto. • •

Un auto es la composición de diferentes partes( motor, ruedas, puertas, asientos etc.) Un auto es un término común que define a tipos diferentes de automóviles, es decir es una categoría que puede servir para agrupar, por ejemplo las diferentes marcas (BMW, Seat, Toyota entre otras) o por su categoría (deportivos, clásicos, pick-up etc).

Si los miembros de autos o las diferencias entre autos individuales no son relevantes, entonces se utilizan expresiones y operaciones tales como: se fabrican autos, se usan autos para trasladarse de un lado a otro, se descompone el auto en sus partes etc. 2. Encapsulamiento y ocultación de datos La encapsulación es la reunión en una cierta estructura, de todos los elementos que a un cierto nivel de abstracción se pueden considerar pertenecientes a una misma entidad y también es el proceso de agrupamiento de datos y operaciones relacionadas bajo una misma unidad de programación, lo que permite aumenta la cohesión de los componentes del sistema. Todas estos objetos que presentan características y comportamientos similares, se agrupan en clases las cuales son utilizadas para encapsular los datos 3. Herencia El concepto de herencia ha sido definido en la sección de modelado, sin embargo es una de las técnicas utilizadas en la POO debido a que la facilidad de heredarle características de una Superclase a una Subclase es comúnmente utilizado en la POO. MCP – CAH

ciclo II - 2011

Página 9

La idea principal es crear una clase que encapsule todos los elementos o características generales que pueda y a partir de ésta, heredarle parcial o totalmente las características a objetos de una subclase.

El lenguaje utilizado para el modelamiento de los sistemas utilizando la Programación Orientada a Objetos es el UML. A continuación se encuentran los conceptos básicos del lenguaje UML. 1. Historia de UML En la primera mitad de la década de los 90, los lenguajes de modelado que imperaban eran OMT-2 (Object Modeling Technique) creado por James Rumbaugh, OOSE (Object Oriented Software Engineering) creado por Ivan Jacobson y Booch93 creadi oir Grady Booch. Grady Booch llamó a James Rumbaugh y formaron equipo en una nueva Rational Corporation (cuyo propietario era Grady) con el objetivo de fusionar sus dos métodos. En octubre de 1994, Grady y James comenzaron a trabajar en la unificación de ambos métodos produciendo una versión en borrador llamada 0.8 y nombre “Unified Method”. A partir de 1995 Jacobson se une. El primer fruto de su trabajo colectivo se lanzó en enero de 1997 y fue presentado como versión 1.0 de UML. La gran ventaja de UML es que fue recogiendo aportaciones de los grandes gurús de objetos: David Hasel con sus diagramas de estado; partes de la notación de Fusion, el criterio de responsabilidadcolaboración y los diagramas de Rebeca Wirfs-Brock, y el trabajo de patrones y documentación de Gamma-Helm-Johnson-Ulissides. En 1997 OMG aceptó UML como estándar (versión 1.1) y nació el primer lenguaje de modelado visual orientado a objetos como estándar abierto de la industria. En 1998, OMG lanzó dos revisiones más, 1.2 y 1.3. En el año 2000 se presentó UML 1.4 con la importante aportación de la semántica de acción, que describe el comportamiento de un conjunto de acciones permitidas que se pueden implementar mediante lenguajes de acción. La versión 1.5 siguió a las ya citadas. En 2004 finalizó la versión 2.0 con su especificación completa. UML 2 es ya un lenguaje de modelado muy maduro. UML 2 ha incorporado numerosas mejoras a UML 1.x. Los cambios más importantes se han realizado en el metamodelo (generador de modelos), conservando los principios fundamentales y evolutivos de las últimas versiones. Los diseñadores de UML 2.0 han tenido mucho cuidado en asegurar que fuera totalmente compatible con las versiones anteriores para que los usuarios de éstas no tuvieran problemas de adaptación. La versión UML 2.0 ha evolucionado para superar los nuevos retos a los cuales se enfrentan el software y los nuevos desarrolladores de modelos.

2. Diagramas del lenguaje UML ¿Qué significa UML? UML significa Lenguaje Unificado de Modelado (Unified Model Language) y es el lenguaje estándar para el desarrollo de sistemas y de software utilizando POO. ¿Qué es lenguaje UML? El lenguaje UML tiene una gran aplicación en la representación y modelado de la información que se utiliza en las fases de análisis y diseño del ciclo de vida de los sistemas. MCP – CAH

ciclo II - 2011

Página 10

Un modelo es una abstracción de cosas reales, es decir es una simplificación del sistema real; en pocas palabras es la representación gráfica de una situación real, mediante una simbología que esquematiza clases, objetos, relaciones, etc. Con un lenguaje formal de modelado, el lenguaje es abstracto aunque tan preciso como un lenguaje de programación. Esta precisión permite que un lenguaje sea legible por la máquina de moto que pueda ser interpretado, ejecutado y transformado entre sistemas.

3. Tipos de diagramas en UML A continuación se presenta una figura que presenta una forma de clasificación de los diferentes diagramas que existen en UML.

Los diagramas estructurados se utilizan para capturar la organización física de las cosas del sistema, por ejemplo como se relacionan unos objetos con otros. Los diagramas de comportamiento se centran en el comportamiento de los elementos de un sistema. El diagrama de clases es uno de los tipos de diagrama más fundamentales en UML. Se utilizan para capturar las relaciones estáticas de su software. Este tipo de diagramas proporcionan un medio de capturar la estructura física de un sistema. 2.4 Simbología En el siguiente cuadro se encuentra la simbología de los elementos básicos para el diseño UML. MCP – CAH

ciclo II - 2011

Página 11

MCP – CAH

ciclo II - 2011

Página 13