Introducción
En nuestro mundo se encuentran un sin número de objetos, estos objetos existen como entidades hechas por el hombre, negocios y productos que se usan en la vida diaria. Todos estos objetos pueden ser clasificados, descritos, organizados, combinados, manipulados y creados.
La idea básica de la programación orientada a objetos se basa en 8 principios, que se muestran para un mejor entendimiento de la metodología:
• Clases
• Herencia
• Objetos
• Encapsulación
• Atributo
• Mensajes
• Método
• Polimorfismo
Un enfoque orientado a objetos, dependiendo de la naturaleza del software a desarrollar, puede facilitar la elaboración de la aplicación, debido a que los objetos describen de forma abstracta a los elementos del mundo en que vivimos.
Los beneficios de la tecnología orientada a objetos se fortalecen si se usa antes y durante el proceso de desarrollo del software una metodología de análisis y diseño orientada a objetos. Para obtener los mejores resultados se deben considerar el análisis de requisitos orientados a objetos, diseño orientado a objetos, análisis del dominio orientado a objetos, entre otros.
En el análisis orientado a objetos se desarrollan una serie de modelos que describen el software de computadora a trabajar para satisfacer un conjunto requisitos definidos por el cliente. El modelo del análisis orientado a objetos ilustra información, funcionamiento y comportamiento.
El diseño orientado a objetos transforma el modelo del análisis en un modelo de
diseño que sirve como anteproyecto para la construcción del software.
Orientación a objetos
Principios de orientación a objetos
La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los años sesenta. Sin embargo, las tecnologías de objetos han necesitado casi veinte años para llegar a ser ampliamente usadas. Durante los años 90, la ingeniería del software orientada a objetos se convirtió en el paradigma de elección para muchos productores de software y para un creciente número de sistemas de información y profesionales de la ingeniería. A medida que pasa el tiempo, las tecnologías de objetos están sustituyendo a los enfoques clásicos de desarrollo de software. Una pregunta importante es: ¿Por qué?. La respuesta (como muchas otras respuestas a interrogantes sobre ingeniería del software) no es sencilla. Algunas personas argumentarían que los profesionales del software sencillamente añoraban un nuevo enfoque, pero esta visión es muy simplista. Las tecnologías de objeto llevan un número de beneficios inherentes que proporcionan ventajas a los niveles de dirección y técnico.
Objeto
En el análisis y diseño orientados a objetos (OO), interesa el comportamiento del objeto. Si se construye software, los módulos de software OO se basan en los tipos de objetos. El software que implanta el objeto contiene estructuras de datos y operaciones que expresan dicho comportamiento. Las operaciones se codifican como métodos. Las representación en software OO del objeto es entonces una colección de tipos de datos y objetos.
Entonces, dentro del software orientado a objeto, un objeto es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos datos.
Un objeto puede estar compuesto por otros objetos. Estos últimos a su vez también pueden estar compuestos por otros objetos. Esta intrincada estructura es la que permite construir objetos muy complejos.
Paradigma
En la POO las entidades centrales son los objetos, que son tipos de datos que encapsulan con el mismo nombre estructuras de datos, operaciones o algoritmos que manipulan esos datos. Objeto: Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
Ventajas de Objetos
- Mejoras significativas de la productividad y calidad del código
- Estabilidad de los modelos respecto a entidades del mundo real Construcción iterativa.
- Promueve la reutilización de software y de diseños (componentes, frameworks)
- Los sistemas OO son generalmente más pequeños que su equivalente no OO: menos código y más reutilización.
- Permite desarrollar sistemas más preparados para el cambio
- Vale para aplicaciones de pequeño y gran tamaño
Características principales de los sistemas orientados a objetos
ABSTRACCION: la separación de propiedades de la implementación.
Los objetos son agentes abstractos con ciertas aptitudes que comuniquen entre ellos. No hay por qué conocer todos los detalles.
No importa la manera de almacenaje de los datos ni la elección de los algoritmos dentro de los métodos.
POLIMORFISMO: uso de la misma definición con diferentes tipos de datos.
Se puede escribir funciones de tal manera que no se pone restricciones en el tipo de parámetros.
EJEMPLO DE POLIMORFISMO
Operación Resultado
3 + 7 = 12
0.1 + 11.001 = 11.101
2 + 0.0008 = 2.0008
“ho” + “la” = ”hola”
HERENCIA: una clase se deriva de otra.
El propósito de herencia es extender la funcionalidad de una clase por “reuso automático” de las definiciones y la funcionalidad de otra clase: los objetos contienen las propiedades y el comportamiento de todas sus clases “padres”, además de los de su propia clase.
La meta es la construcción de jerarquías, a partir de una clase general a unas más específicas. ´
⇒ facilita el polimorfismo y el encapsulamiento
ENCAPSULAMIENTO: La ocultación de la información.
No es necesario conocer los detalles de la implementación y/o diseño para poder utilizar algún código.
Al ocultar información “no necesaria” se protege las otras partes del programa de cambios en el dado caso que cambia la parte escondida.
Gestión de proyectos de software orientado a objeto
Las técnicas modernas a las que un director de proyecto se debe enfrentar, se pueden dividir en las siguientes actividades:
- Establecimiento de un marco de proceso común para el proyecto.
- Métricas y estimación del proyecto.
- Especificación de productos de trabajo y avances.
- Definición de puntos de comprobación.
- Gestión de los cambios que ocurren invariablemente.
- Seguimiento del proyecto.
Para aplicar estas actividades hay que tomar en cuenta que todas hay que enfocarlas usando un modelo propio.
Marco de proceso común para OO (orientado a objetos): Se define cómo se organizarán las actividades dentro del proceso de creación de software y el mantenimiento del mismo. Se definen las tareas, hitos y entregas que se harán.
Un modelo recomendado es el “recursivo/paralelo” que consiste en: realizar el análisis correspondiente del problema, extrayendo todas las clases y conexiones más importantes; extraer objetos reutilizables de una biblioteca para construir un prototipo; hacer pruebas del prototipo; obtener más información del cliente sobre el prototipo; e ir refinando el modelo y los objetos, haciendo la modificación del análisis si es necesario, para que la aplicación vaya evolucionando.
Métricas y estimación en proyectos orientados a objetos: Esta actividad se centra en estimar cuán grande será el proyecto y el esfuerzo que necesitará.
Se sugieren varios métodos como:
– Número de guiones de escenario: que es una secuencia detallada de las interacciones del usuario con la aplicación
– Identificar el número de clases clave: ya que las clases clave son centrales al dominio del problema, éstas indica, el esfuerzo necesario para desarrollar el software.
– Identificar el número de clases soporte: no están directamente relacionados al dominio del problema, pero es también parte importante para poder estimar el tamaño de la aplicación
Este tópico define un enfoque organizativo para el desarrollo y mantenimiento del software. Identifica el paradigma de ing. de software aplicado para construir y mantener software. Tiene la cualidad de ser adaptable, de forma que cumpla con las necesidades individuales del equipo de proyecto.
Para el desarrollo de proyectos de esta naturaleza no se pueden aplicar modelos lineales (ciclo de vida), sino que es necesario aplicar un modelo que contemple un desarrollo iterativo. Iterativo significa que el software evolucione a través de un número de ciclos. El software OO debe ser evolutivo por naturaleza. Existen autores que sugieren un modelo recursivo/paralelo para el desarrollo orientado a objetos.
UML (Unified Modeling Language)
Es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido concebido por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh.
Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.
Análisis Orientado a objetos (AOO)
Desde comienzos de la década de los 80, el paradigma «orientado a objetos» ha ido madurando como un enfoque de desarrollo de software alternativo a la programación estructurada o modular. Se empezó a crear diseños de aplicaciones de todo tipo usando una forma de pensar orientada a los objetos, y a implementar estos diseños utilizando lenguajes orientados a objetos. Sin embargo, el análisis de requisitos se quedó atrás. No se desarrollaron técnicas de análisis específicamente orientadas a objetos.
El objetivo del análisis orientado a objetos es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente.
El enfoque de Coad y Yourdon para el análisis orientado a objetos está basado en cinco capas. Esas cinco capas consisten de capa clase /objeto, capa de estructura, capa de atributos, capa de servicios, y capa de tema. Estas capas dan mayor poder a la representación de la complejidad del análisis y el diseño en sistemas flexibles.
1. Capa Clase Objeto: Esta capa del análisis y diseño indica las clases y objetos.
2. Capa de Estructura: Esta capa captura diversas estructuras de clases y objetos, como las relaciones uno a muchos.
3. Capa de Atributos: Esta capa detalla los atributos de las clases.
4. Capa de Servicios: Esta capa indica los mensajes y comportamientos de los objetos.
5. Capa de Tema: Esta capa divide el diseño en unidades de implementación o asignaciones de equipos.
Ventajas del AOO.
- Dominio del problema. El paradigma OO es más que una forma de programar. Es una forma de pensar acerca de un problema en términos del mundo real en vez de en términos de un ordenador. El AOO permite analizar mejor el dominio del problema, sin pensar en términos de implementar el sistema en un ordenador. El AOO permite pasar directamente el dominio del problema al modelo del sistema.
- Comunicación. El concepto OO es más simple y está menos relacionado con la informática que el concepto de flujo de datos. Esto permite una mejor comunicación entre el analista y el experto en el dominio del problema (es decir, el cliente).
- Consistencia. Los objetos encapsulan tanto atributos como operaciones. Debido a esto, el AOO reduce la distancia entre el punto de vista de los datos y el punto de vista del proceso, dejando menos lugar a inconsistencias o disparidades entre ambos modelos.
- Expresión de características comunes. El paradigma OO utiliza la herencia para expresar explícitamente las características comunes de una serie de objetos. Estas características comunes quedan escondidas en otros enfoques y llevan a duplicar entidades en el análisis y código en los programas. Sin embargo, el paradigma OO pone especial énfasis en la reutilización, y proporciona mecanismos efectivos que permiten reutilizar aquello que es común, sin impedir por ello describir las diferencias.
- Resistencia al cambio. Los cambios en los requisitos afectan notablemente a la funcionalidad de un sistema, por lo que afectan mucho al software desarrollado con métodos estructurados. Sin embargo, los cambios afectan en mucha menor medida a los objetos que componen o maneja el sistema, que son mucho más estables. Las modificaciones necesarias para adaptar una aplicación basada en objetos a un cambio de requisitos suelen estar mucho más localizadas.
- Reutilización. Aparte de la reutilización interna, basada en la expresión explícita de características comunes, el paradigma OO desarrolla modelos mucho más próximos al mundo real, con lo que aumentan las posibilidades de reutilización. Es probable que en futuras aplicaciones nos encontremos con objetos iguales o similares a los de la actual.
Análisis de Clases y Objetos
Objeto: Es una abstracción de algo en un dominio de un problema que refleja las capacidades de un sistema para llevar información acerca de ello, interactuar con ello o ambas cosas. Una encapsulación de valores de atributos y sus servicios exclusivos. Clase: Una descripción de uno o más objetos con un conjunto de atributos y servicios uniformes, incluyendo una descripción de cómo crear nuevos objetos en la clase.
Clase y Objeto: Un término que se refiere tanto a la clase como a los objetos que ocurren en la clase.
En el análisis de clases y Objetos se identifican las clases, los objetos y las clases y objetos candidatos para la aplicación a desarrollar. Las clases, los objetos y las clases y objetos se pueden obtener haciendo un análisis gramatical de la descripción del problema, subrayando términos que podrían ser representados con objetos dentro del sistema. Dentro del análisis gramatical de la descripción del problema, los objetos se pueden manifestar de la siguiente manera:
• Entidades externas: (otros sistemas, dispositivos, gente) que producen o consumen información a ser utilizada en el sistema.
• Cosas: (informes, visualizaciones, cartas, señales) forman parte del dominio de información del problema.
• Ocurrencias o Sucesos: (una transferencia de una propiedad o la terminación de una serie de movimientos de un robot) ocurren en el contexto de operación del sistema.
• Papeles: (gestor, ingeniero, vendedor) son jugados por personas que interactúan con el sistema.
• Unidades organizativas: (división, grupo, equipo) son relevantes para la aplicación.
• Lugares: (sala de facturación, muelle de descarga) establecen el contexto del problema y el funcionamiento general del sistema.
• Estructuras: (sensores, vehículos de cuatro ruedas, computadoras) definen clases de objetos.
CASOS DE USO
Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.
En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. En otras palabras, un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema.
Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas.
MODELADO DE CLASES, RESPONSABILIDADES Y COLABORACIONES
Una vez que se han desarrollado los escenarios de uso básicos para el sistema, es el momento de identificar las clases candidatas e indicar sus responsabilidades y colaboraciones. El modelado de clases-responsabilidades colaboraciones (CRC) aporta un medio sencillo de identificar y organizar las clases que resulten relevantes al sistema o requisitos del producto. Se describe el modelado CRC de la siguiente manera:
Un modelo CRC es realmente una colección de tarjetas índice estándar que representan clases. Las tarjetas están divididas en tres secciones. A lo largo de la cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo se listan las responsabilidades de la clase a la izquierda y a la derecha los colaboradores.
En realidad, el modelo CRC puede hacer uso de tarjetas índice virtual o real. El caso es desarrollar una representación organizada de las clases. Las responsabilidades son los atributos y operaciones relevantes para la clase. Puesto de forma simple, una responsabilidad es «cualquier cosa que conoce o hace la clase». Los colaboradores son aquellas clases necesarias para proveer a una clase con la información necesaria para completar una responsabilidad. En general, una colaboración implica una solicitud de información o una solicitud de alguna acción.
Definición de atributos.
Los atributos presentan las siguientes características:
· Valor de un dato dentro de un objeto.
· Cada atributo tiene un valor para cada objeto.
· El nombre de un atributo es único dentro de una clase.
· Debería ser un dato ‘puro’, no un objeto (no tiene identidad): si un objeto necesita otro objeto habrá que modelarlo como asociación.
· Además del nombre podemos especificar el Tipo y el Valor por defecto.
· Los identificadores de objetos explícitos no se necesitan en el Modelo de Objetos.
Diseño Orientado a Objetos
El enfoque de Coad y Yourdon, plantea que el análisis es razonablemente independiente de la tecnología, en cambio el diseño viene a ser entonces cada vez más orientado hacia un lenguaje OO particular y a un ambiente de desarrollo. Las
actividades de diseño OO están agrupadas en los cuatro componentes principales del sistema final: el componente del problema, el componente de interfaz humana, el componente de manejo de datos y el componente de manejo de tareas, todos ellos están expandido a lo largo de las cinco capas con que cuenta el diseño OO, mismas que se presentaron anteriormente en el análisis OO.
Características principales del Diseño Orientado a Objetos:
Los objetos son abstracciones del mundo real o entidades del sistema que se administran entre ellas mismas
* Los objetos son independientes y encapsulan el estado y la representación de
información
* La funcionalidad del sistema se expresa en términos de servicios de los objetos
* Las áreas de datos compartidas son eliminadas. Los objetos se comunican mediante paso de parámetros
* Los objetos pueden estar distribuidos y pueden ejecutarse en forma secuencial o en paralelo
Ventajas del Diseño Orientado a Objetos:
* Fácil de mantener, los objetos representan entidades auto-contenidas
* Los objetos son componentes reutilizables
* Para algunos sistemas, puede haber un mapeo obvio entre las entidades del mundo real y los objetos del sistema
Objetos, operaciones y mensajes
El funcionamiento del software se consigue al actuar uno o más procesos sobre
una estructura de datos de acuerdo con un procedimiento de invocación.
Para conseguir un DOO, tenemos que establecer un mecanismo para:
• Representar la estructura de datos
• Especificar el proceso
• Realizar el procedimiento de invocación
Objeto: Componente del mundo real que se hace corresponder con el software. En un Sistema de Información basado en Computador, un objeto es un producto o consumidor de información, o un elemento de información.
Cuando se hace corresponder un objeto con su realización software, implementamos una estructura de datos y usa serie de procesos que pueden transformar la estructura de datos.
Aspectos de diseño
Meyer sugiere cinco criterios para evaluar la calidad de un método de diseño a partir de la modularidad.
Descomponibilidad: Facilidad con la que un método de diseño ayuda al diseñador a descomponer un problema en subproblemas más sencillos.
Componibilidad: Grado en el que un método de diseño permite la reutilizabilidad de módulos.
Compresibilidad: Facilidad para comprender un componente del programa sin tener que hacer referencia a otros módulos.
Continuidad: Capacidad de realizar cambios en un programa y que esos cambios afecten a un número mínimo de módulos.
Protección: Característica arquitectónica que reduce la propagación de errores.
Programación Orientada a Objetos
¿ Qué es Programación Orientada a Objeto (POO)
La programación Orientada a Objetos es una metodología que basa la estructura de los programas en torno a los objetos.
Los lenguajes de POO ofrecen medios y herramientas para describir los objetos manipulados por un programa. Más que describir cada objeto individualmente, estos lenguajes proveen una construcción (Clase) que describe a un conjunto de objetos que poseen las mismas propiedades.
¿Cuáles son las ventajas de un lenguaje orientado a objetos?
- Fomenta la reutilización y extensión del código.
- Permite crear sistemas más complejos.
- Relacionar el sistema al mundo real.
- Facilita la creación de programas visuales.
- Construcción de prototipos
- Agiliza el desarrollo de software
- Facilita el trabajo en equipo
- Facilita el mantenimiento del software
Lo interesante de la POO es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible.
Características Generales
Un objeto se identifica por un nombre o un identificador único que lo diferencia de los demás. Ejemplo: el objeto Cuenta de Ahorros número 12345 es diferente al objeto Cuenta de Ahorros número 25789. En este caso el identificador que los hace únicos es el número de la cuenta.
Un objeto posee estados. El estado de un objeto está determinado por los valores que poseen sus atributos en un
momento dado.
Un objeto tiene un conjunto de métodos. El comportamiento general de los objetos dentro de un sistema se describe o representa mediante sus operaciones o métodos. Los métodos se utilizarán para obtener o cambiar el estado de los objetos, así como para proporcionar un medio de comunicación entre objetos.
Un objeto tiene un conjunto de atributos. Los atributos de un objeto contienen valores que determinan el estado del objeto durante su tiempo de vida. Se implementan con variables, constantes y estructuras de datos (similares a los campos de un registro).
Conclusiones
El análisis, diseño y programación orientada a objetos, ha sido desarrollado para responder a las necesidades de flexibilidad en los Sistema de información basados en computadora.
La encapsulación, herencia y polimorfismo, tienen como objeto proporcionar sistemas complejos con mecanismos para un rápido, fácil y confiable mantenimiento y cambio de los programas. Aunque el desarrollo Orientado a Objeto típico involucra una fase de análisis y diseño más amplia, esta inversión se traduce en menores costos de operación de los sistemas que es probable que requiera una gran actividad de mantenimiento.
Existen varias metodologías orientadas a objetos, a pesar que tienen variantes entre ellas, todas trabajan con el mismo paradigma por tanto se basan en los mismo fundamentos de modelación de objetos. Este trabajo se enfoca en la técnica de Análisis y Diseño de Coad y Yourdon, por considerarse sencilla al momento de aplicar para analistas con poca experiencia.
Las técnicas para el análisis y diseño Orientadas a Objetos todavía están en desarrollo, esto debido a que la programación misma todavía se encuentra en esta etapa.
Por consiguiente han surgido tantas metodologías que tratan este modelo de programación, llegando a destacarse un enfoque de Modelación de Lenguaje Unificado (UML) como uno de los más prácticos y eficientes. Sin embargo, no existe una técnica que se haya definido como estándar para este paradigma.
Bibliografía
– www.inf.udec.cl/~mvaras/estprog/cap4.html
– Ingenieria_de_Software_-_Ian_Sommerville_-_7ma_Edicion
– http://www.slideshare.net/HectorMamani/1-el-paradigma-de-orientacin-a-objetos
– Pressman Roger S – Ingeniería Del Software Un Enfoque Practico (5ed)
– docentes.uni.edu.ni/fec/Giovanni.Saenz/Ingenieria_de_Software/Analisis_y_DisenoOO.pdf
- BOOCH, Grady. «Object-oriented Analysis and Design with Applications». 2da. edición, Benjamín/Cummings Publishing, 1993.
