Introducción Programación Orientada a Objetos

Introducción a la Programación
Orientada a Objetos (POO).
Diseño Orientado a Objetos.
Metodología enfocada a la solución de problemas complejos.
Complejidad del software.
Problemas difíciles de precisar.
Definición de requerimientos vago y cambio a la par que se desarrolla el sistema.
Proceso de desarrollo difícil.
Verificación del software poco viable.
Para manejar la complejidad se utiliza alguna forma de organización jerárquica.
Dependencias.
Jerárquica estructural (parte de)
Jerárquica especialización (tipo de)
Ejemplos.
Dependencia estructurar: Existen dependencias muy fuertes.
Jerarquía de especialización: Heredan las características.
Descomposición algorítmica.
Algorítmico: Método utilizado en el diseño estructurado "Top-down". Se basa en
la identificación de las operaciones en la descripción del problema y su expresión
en términos de operaciones más sencillas.
Ejemplo.
Orientado a objetos.
Método que permite resolver un problema alrededor de abstracciones
representadas por objetos. Los objetos se comportan como agentes.
Topología de programas estructurados.
Topología de programas orientados a objetos (hay encapsulamiento).
Modelo orientado a objetos.
Conceptos básicos.
Abstracción.
Caracterización de un objeto de acuerdo a las propiedades que nos interesen en un
instante de tiempo.
Las características escogidas son relativas a la perspectiva del observador.
Encapsulación.
Manera de ocultar los detalles de la representación interna de un objeto
presentando solo la interfase para el usuario.
Modularidad.
Un módulo es una agrupación de abstracciones lógicamente relacionadas.
Introducción a la Programación Orientada a Objetos
(OOP).
La idea central es:
Organizar los programas de modo que reflejen la forma de organización de los
objetos en el mundo real.
La programación orientada a objetos es, desde su raíz, una forma de concebir un programa de
computadora.
Un objeto es un elemento independiente de un programa de computadora, que representa
un grupo asociado de características y está diseñado para realizar tareas específicas. A
los objetos también se les conoce como instancias.
Cada objeto tiene un papel específico en un programa, y todos los objetos puedes funcionar
con otros objetos en maneras definidas.
Una clase es una plantilla que se utiliza para crear múltiples objetos con características
similares.
Las clases engloban todas las características de un conjunto particular de objetos. Cuando se
escribe un programa en un lenguaje orientado a objetos, no se definen objetos individuales,
sino que se definen clases de objetos.
Los conceptos de herencia, interfaces y paquetes, conforman los mecanismos para organizar
clases y su comportamiento. La biblioteca de clases de Java se apoya en estos conceptos.
La herencia.
Es un mecanismo que hace posible que una clase herede todo el comportamiento y
los atributos de otra clase.
A través de la herencia, una clase tiene inmediatamente toda la funcionalidad de una clase
existente. Debido a esto, las nuevas clases de pueden crear indicando únicamente en que se
diferencian de la clase existente.
Con la herencia, todas la clases se acomodan en una jerarquía estricta, las que uno mismo creó
y aquellas que provienen de la biblioteca de clases de Java y otras bibliotecas.
A una clase que hereda de otra clase se le llama subclase, y a la clase que
proporciona la herencia se le llama superclase.
Una clase puede tener únicamente una superclase, pero cada clase tiene una cantidad ilimitada
de subclases. Las subclases reciben por herencia todos los atributos y comportamiento de sus
superclases.
Modularidad:
Un modulo es una agrupación de abstracciones lógicamente relacionadas.
La interfaz de un módulo es la descripción de los servicio que ofrece a otros
módulos.
Es una idea básica en la POO.
Jerarquía:
Permite organizar y ordenar las abstracciones.
Hay dos tipos: por estructura y por especialización.
Idea: Pensar en una forma de organizar nuestros objetos.
Tipo:
Caracterización precisa de propiedades sobre la estructura y el comportamiento de
una colección de unidades.
Esta asociado íntimamente con la clases. Va a indicarnos cual es el ambiente que
va a englobar al modulo.
Persistencia:
Propiedad de un objeto de poder quedar vigente en el tiempo y el espacio
(independiente de 00).
indicara que tiempo el objeto permanecerá vigente.
(ligado a lo anterior)
Concurrencia:
Que simultáneamente se pueden llevar múltiples procesos.
Clases y objetos.
Objeto = Instancia.
Un objeto tiene un estado, un comportamiento y una identidad.
Estado
El estado de un objeto se compone de las propiedades estáticas de un objeto con
valores dinámicos asociados a ellas en un momento dado.
Estado à variables de instancia.
(se traduce al manejo de las variables de instancia)
Comportamiento
Forma en que actúa y reacciona el objeto, expresado en términos de cambios de
estado y envío de mensajes a otros objetos.
Comportamiento à Método (es lo que nos indica como se comporta la clase o
qué puede hacer la clase)
Identidad.
Propiedad que distingue a un objeto de los demás.
Cuando hablamos de OOP hablamos de crear un objeto que tenga las tres
características (Estado, Comportamiento, identidad).
Hablando de la parte de programación, las variables de instancia + los métodos
definen al objeto.
Relaciones entre objetos.
Relación de uso.
Expresan la manera en que unos objetos usan a otros.
Formas de uso:
Actor.- (nunca es operado por los demás)
Objeto que puede operar sobre otros.
Servidor.- (nunca opera sobre los demás)
Objeto que puede ser operado por otros.
Agente.
Objeto que puede operar sobre los demás y también puede ser operado por otros.
Relación de Contención.
Se crea la relación si un objeto esta compuesto por otros objetos.
Cuidado !!! --> Crean dependencias.
Recordemos: Hay que crear objetos independientes buscando en un futuro re-utilizar.
Clases.
Conjunto de objetos que tienen una estructura común y un comportamiento común. Por
tanto es una abstracción del concepto objeto.
Un objeto es una instancia de una clase.
Interfaz de una clase.
proporciona la vista externa o interfaz con el usuario.
Se divide en:
Pública: visible para todas las clases.
Protegida: visible sólo para subclases.
Privada: NO visible para ninguna otra clase.
Relaciones entre clases.
La interfaz esta compuesta por las variables de instancia.
Para garantizar el encapsulamiento y la privacidad se usaran variables privadas.
à Las relaciones entre las clases forman la estructura del diseño de un sistema.
Formas básicas:
Relación de Herencia.
Una clase comparte la estructura y/o comportamiento definidos en una o más
clases.
Herencia Sencilla.
Nota: aquí el "elefante" es una subclase, y "animal" es una superclase.
Herencia Multiple.
Superclase: Clase de la cual otra clase hereda.
Subclase: Clase que hereda de una o más clases.
subclase à especialización de la superclase.
à NO todos los lenguajes de programación orientada a objetos usan la herencia múltiple.
Clase abstracta.
Su comportamiento no esta totalmente definido. Sirven para captar las propiedades generales
que posteriormente son particularizadas en las subclases.
Clase Base.
Clase que no tiene superclases.
Relación de uso.
Hay 2 formas principales de relación de uso entre clases:
- La interfaz de una clase usa otra clase.
- La implantación de una clase usa otra clase.
Las relaciones que se tendrán dentro de las clases, se tendrá en un agente, en su
comportamiento.
Relación de instanciación.
Relación entre clases donde el comportamiento de una clase puede ser
parametrizada por otra clase.
Ejemplo.
Colecciones de objetos homogéneas (listas, colas, pilas, árboles, etc. [operaciones
genéricas para todos]).
La parametrización de una clase con otra es un mecanismo muy flexible que
permita crear clases reutilizables.
Relación de metaclases.
A una clase se le puede ver como a un objeto por lo tanto a la clase de los objetos
de clases se les llama Metaclase.
Metaclase.
Es una clase cuyos objetos son clases.
Idea central de la instanciación y la parametrización: poder llegar a tener clases
reutilizables.
Relación entre clases y objetos.
Las clases son estáticas, i.e. forman parte del texto del programa y no cambian
durante su ejecución.
Los objetos por el contrario son totalmente dinámicos, se crean, cambian su estado
y se destruyen.
Clasificación.
Forma de ordenar el conocimiento. No existen reglas simples que permitan la
mejor selección de clases y objetos para generar una clasificación.
Identificar clases y objetos requiere de la aplicación de nuestras capacidades de
descubrir e inventar.
Clasificar es agrupar cosas que tienen estructura común o comportamiento similar.
La clasificación es un proceso difícil, por lo que conviene hacerlo de manera
incremental iterativa.
Al iniciar el diseño, se define una estructura inicial para las clases. En base a la
experiencia adquirida se crean nuevas subclases a partir de las existentes o bien es
muy común que se requiera dividir una clase en otras más pequeñas (pero más
generales), inclusive es posible requerir de la unión de varias clases.
Proceso de diseño orientado a objetos
Análisis orientado a objetos.
Durante el análisis OO las clases y objetos se derivan usualmente de los siguientes conceptos:
Cosas tangibles (autos, sensores, ?)
Papeles que representan (madre, profesor, ?)
Eventos que ocurren (aterrizaje, petición,? )
Interacción (préstamos, encuentro, ?)
Organizaciones (UAM, ONU, ?)
Conceptos (negociación, comunicación, ?)
Convención para signar nombres a los objetos y clases:
Objeto. Sustantivo (el sensor, un sólido, ?)
Clase. Nombre común (sensores, sólidos, ?)
Operaciones que modifican. Verbos activos (dibujar, mover, ?)
Operaciones de selección. Preguntas (¿esta abierto? ?)
Mecanismos de interacción.
Determinan de qué manera interactúan las instancias de las clases. La definición de los
mecanismos es una decisión estratégica en el diseño de un sistema.
Nota: Es importante no perder de vista el diagrama de jerarquías.
Método de diseño.
Para especificar el diseño de un sistema complejo es necesario especificar la estructura estática
(clases, objetos, módulos, procesos), y la dinámica del sistema (transición de estados, tiempo).
Especificación Estática.
Lógica à Diagrama de clases.
à Diagrama de objetos.
Física à Diagrama de módulos.
Diagrama de procesos.
Especificación Dinámica.
Diagrama de transición de estados. (íntimamente relacionado con instancias)
Diagrama de tiempo.
Diagrama de Clases.
Se usa para mostrar la existencia de clases y las relaciones entre ellas.
Simbología.
Por ejemplo.
Esta clase (la de la izquierda), lo que hace es usar en su interfaz elementos de la otra clase (la
de la derecha), y la misma clase "x" usará métodos de la clase de abajo.
A continuación tenemos más elementos.
Esta relación entre clases conviene usarla en las primeras fases del
diseño, cuando todavía no estamos seguros del tipo de relación.
Categorías de Clases.
Cuando un sistema incluye muchísimas clases, es importante agrupar las clases en categorías y
hacer diagramas de las mismas.
Cuando una categoría de clase es visible para las demás, se recomienda anotar la palabra
"global" en la esquina izquierda del recuadro.
Ejemplo.
Aquí implica que todo lo que esta dentro de la clase "policía" es público, i.e. podríamos crear
un nuevo objeto de nombre "Policía Federal de Caminos", que heredaría las propiedades
básicas de "policía", pero se le agregarían nuevas características a la nueva categoría.
Esquemas de Clases.
Para complementar la información de los diagramas de clases, es importante incluir la
documentación o esquema de clases.
De manera general podemos incluir:
Nombre: identificador de la clase.
Descripción: texto.
Jerarquía:
Superclases: lista de nombres de clases.
Metaclase: nombre de clase.
Parámetros: lista de parámetros.
Interfaz: (público, protegido, privado).
*Usa: Lista de nombres de clases.
*Campos: lista de declaraciones.
*Operaciones: lista de declaraciones.
(*) implantación.
Máquina de Estados finitos. Diagrama de transición.
Concurrencia. Secuencial / paralelo
Esquema de Operaciones.
En fases avanzadas del diseño se requiere de una definición más precisa de las operaciones que
forman parte de la clase.
Nombre: Identificador
Descripción: Texto
Categoría: Nombre
Parámetros formales: Lista
Resultado: lista
Acciones: lista
Excepciones: lista de declaraciones
Concurrencia: secuencial / paralelo.
Hint: Es muy importante ir trabajando y documentando nuestro programa. No dejar a ultima
hora.
Diagramas de transición de estados.
Se usan para mostrar el estado de una instancia de una clase dada, los eventos que causan una
transición de un estado a otro y las acciones que resultan del cambio de estado.
Ejemplo.
Proceso de inscripción a la maestría.
Diagrama de objetos.
Las clases son estáticas, mientras que los objetos son dinámicos. Los diagramas de objetos
reflejan las interacciones dinámicas entre objetos relacionados con el envío de mensajes.
Esquemas de objetos y mensajes.
Documentación para el diseño de objetos.
Diagrama de tiempos.
Un diagrama de tiempo es una gráfica de tiempo contra los objetos involucrados en la
interacción.
Ejemplo.
Proceso de diseño orientado a objetos ( OOP)
Es interactivo e incremental.
Se compone por las siguientes actividades.
1. Identificar clases y objetos.
2. Identificar la semántica de clases y objetos.
3. Identificar interrelaciones de clases y objetos.
4. Implementar clases y objetos.
Identificar clases y objetos.
Se descubren las abstracciones de clases y objetos.
Se les asignan nombres significativos.
Se dibujan los diagramas de clases y objetos.
Identificar la semántica de las clases y objetos.
Se establece el significado de las clases y objetos.
Se trabaja sobre el refinamiento de las interfaces de las clases y sobre las acciones que
pueden hacer sus objetos.
Identificar interrelaciones de clases y objetos.
Establecer exactamente como interactúan las cosas dentro del sistema.
Se establecen las relaciones de uso, herencia y otras.
Se refinan los diagramas de los pasos anteriores.
Implementar clases y objetos.
Buscar una representación de clases y objetos.
Alojar las clases y objetos en módulos, y los programas y procesos.
Implementar las clases y objetos en un lenguaje OO.
Diseño tradicional vs. Diseño OO.
El método tradicional consiste en las siguientes etapas:
También conocido como Métodos de cascada.
Puntos débiles del diseño tradicional.
No enfoca apropiadamente el diseño de familias de programas.
Asume una progresión relativa uniforme de pasos de elaboración.
No acomoda el tipo de desarrollo evolutivo.
No enfoca los posibles modos futuros de desarrollo de software.
Conclusión:
Al terminar un sistema es casi imposible reutilizar el código en otra aplicación.
Método orientado a objetos.
Análisis.
Une a los usuarios y a los diseñadores.
Permite proporcionar una descripción completa del problema, legible y revisable por las
partes interesadas y verificable contra la realidad.
Nota: Si tenemos correctamente definidas nuestras jerarquías de clase, hacer
modificaciones no es tan costoso como en el caso de programación tradicional. Sólo
tenemos que entrar en la parte de Evolución para hacer modificaciones.
Diseño.
Inicia aún antes de concluir con la etapa de análisis.
Se recomienda analizar un poco y diseñar.
Esta etapa debe concluir una vez que se establecieron claves y mecanismos importantes.
Evolución.
Incorpora los aspectos tradicionales de programación, verificación e integración.
El proceso de desarrollo consiste en una producción incremental de series de
prototipos que evolucionan a la implantación final.
Posibles cambios que pueden presentarse en esta etapa:
Agregar una clase.
Modificar la implantación de una clase.
Modificar la representación de una clase.
Reorganizar la estructura de clases.
Cambiar la interfaz de una clase.
Modificación.
Un programa que se usa en un ambiente real necesariamente debe cambiar. Los
cambios difieren un poco de los requeridos en evolución, pues contemplan la
introducción de nuevas funcionalidades no previstas en el problema original.
Administración de un proyecto.
En lo referente a la asignación de recursos, comparada con el diseño tradicional tenemos:
Gastos similares en la etapa de análisis.
Gastos mayores en la etapa de diseño.
Gastos mucho menores en programación y verificación.
Gastos considerablemente menores en integración.
Recursos humanos equivalentes o menores.
Un producto de mayor calidad.
Beneficios.
Utiliza el poder expresivo de los lenguajes OO.
Favorece la reutilización del software.
Los sistemas resultan flexibles al cambio.
Reduce los riesgos de desarrollo.
Es atractivo para la cognición humana.
Riesgos.
Desempeño relativamente menor respecto a un sistema tradicional.
Costos iniciales de adopción de DOO.
Casos de uso.
Permiten especificar gráficamente las relaciones entre los actores y los procesos del sistema.
Ejemplo.
(ver diagrama en hoja de papel)
Actores. Son las entidades que realizan o están involucrados en el proceso.
Procesos. Acciones que se deben realizar para provocar un cambio de estado.
Ejemplo.
Determinar cuales de los actores en el sistema de inscripción.
Alumno
Sistemas escolares
Coordinación
Caja
Computo
Determinar que procesos se realizan en el sistema.
Solicitar formatos
Llenar formatos
Inscripción
Validación
Efectuar pago
Autorización Sistemas Escolares
Autorización Coordinación.
Nota: en un principio definimos 7 procesos, pero en base al diagrama podemos
identificar qué procesos y actores tengo. Nos ha quedado finalmente, en la
descripción de los procesos, algo que originalmente no estaba contemplado.
Para el siguiente ejemplo, la notación que se sigue es:
Ejemplo de un diagrama de clases.
(**) Restricción: Si pedido. cliente. calificación. crédito es "pobre", entonces pedido:
prepagado debe ser verdadero.
Se vale que algunas clases no incluyan métodos o variables de instancia.
UML
Clase
Asociación
Generalización
Agregación
Booch
Clase
Uso
Hereda
Contiene
Otro ejemplo:
Ahora vamos a aplicarlo al ejemplo que hemos venido desarrollando.
Autoevaluación
1. Da 3 ejemplos de jerarquía de especialización y 3 de dependencias estructuras.
2. Buscar toda la metodología de diagramación para la programación orientada a
objetos.
3. Realizar una pequeña investigación comparativa de los diferentes lenguajes de
programación (orientada a objetos) que existen, y su evolución:
Historia
Evolución
Ventajas y desventajas.
Conclusiones.
4. ¿Cómo clasificaríamos el entorno de tu casa para que funcione correctamente?
Pista: Clase base: la casa. Luego la recamara, la sala, el baño, la cocina, etc? Luego, tomando la
recamara: ¿qué hay en ella?.- cama, cómoda/closet, mesa, silla, etc.
5. Realizar el estudio para el caso de solicitud y regreso de un libro a la biblioteca.
Considerar todo lo que puede pasar (multas, robo, etc.) Elaborar diagrama,
estados, diagrama de tiempos. Etc.
6. Realizar el estudio para el proceso de inscripción a la maestría. Considerar todo lo
que puede pasar (multas, robo, etc.) Elaborar diagrama, estados, diagrama de
tiempos. Etc.
7. Investiga el modelado con tarjetas CRC
8. Repite 5 y 6 con tarjetas CRC
9. ¿ Cuál de los métodos es mejor ?
Indice
1. Capítulo 1 *
1 Introducción a la Programación Orientada a Objetos (OOP). *
1.2 Diseño Orientado a Objetos. *
1.3 Descomposición algorítmica. *
1.4 Orientado a objetos. *
1.5 Modelo orientado a objetos. *
1.6 Introducción a la Programación Orientada a Objetos (OOP). *
1.7 Clases y objetos. *
1.8 Relaciones entre objetos. *
1.9 Clases. *
1.10 Relación de uso. *
1.11 Relación entre clases y objetos. *
1.10 Proceso de diseño orientado a objetos *
1.11 Análisis orientado a objetos. *
1.12 Proceso de diseño orientado a objetos ( OOP) *
1.13 Diseño tradicional vs. Diseño OO. *
1.14 Puntos débiles del diseño tradicional. *
1.15 Método orientado a objetos. *
1.16 Administración de un proyecto. *
1.17 Autoevaluación *
1.18 Indice *