Análisis Y Diseño Orientado A Objetos PDF

Preview

Summary

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS...

Description

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional. En este método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por ejemplo, el lenguaje unificado de modelado (UML). ADOO aplica técnicas de modelado de objetos para analizar los requerimientos para un contexto por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño más modernas son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue. CONCEPTOS BÁSICOS Objeto Las personas tienen una idea clara de lo que es un objeto: conceptos adquiridos que nos permiten sentir y razonar acerca de las cosas del mundo. Un objeto podría ser real o abstracto, por ejemplo una organización, una factura, una figura en un dibujador, una pantalla de usuario, un avión, un vuelo de avión, etc. 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. La 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. Tipo de Objeto Los conceptos que poseemos se aplican a tipos determinados de objetos. Por ejemplo, empleado se aplica a los objetos que son personas empleadas por alguna organización. Algunas instancias de empleado podrían ser Juan Pérez, José Martínez, etc. En el análisis orientado a objetos, estos conceptos se llaman tipos de objetos; las instancias se llaman objetos. Así, un tipo de objeto es una categoría de objeto, mientras que un objeto es una instancia de un tipo de objeto. En el mundo de las bases de datos existen los tipos de entidad, como cliente o empleado. Existen muchas instancias de cada tipo de entidad (como Juan Pérez o José Martínez para el tipo de entidad empleado). Del mismo modo, en OO se define tipos de objetos e instancias de tipo de objeto. Sin embargo, el término objeto tiene diferencias fundamentales con el término entidad, ya que la entidad sólo se refiere a los datos, mientras que objeto se refiere a los datos y a los métodos mediante los cuales se controlan a los propios datos. En OO, la estructura de datos y los métodos de

1

cada tipo de objeto se manejan juntos. No se puede tener acceso o control de la estructura de datos excepto mediante los métodos que forman parte del tipo de objeto. Métodos Los métodos especifican la forma en que se controlan los datos de un objeto. Los métodos en un tipo de objeto sólo hacen referencia a la estructura de datos de ese tipo de objeto. No deben tener acceso directo a las estructuras de datos de otros objetos. Para utilizar la estructura de datos de otro objeto, deben enviar un mensaje a éste. El tipo de objeto empaca juntos los tipos de datos y su comportamiento. Un objeto entonces es una cosa cuyas propiedades están representadas por tipos de datos y su comportamiento por métodos. Un método asociado con el tipo de objeto factura podría ser aquel que calcule el total de la factura. Otro podría transmitir la factura a un cliente. Otro podría verificar de manera periódica si la factura ha sido pagada y, en caso contrario, añadir cierta tasa de interés. Encapsulado El empaque conjunto de datos y métodos se llama encapsulado. El objeto esconde sus datos de los demás objetos y permite el acceso a los datos mediante sus propios métodos. Esto recibe el nombre de ocultamiento de información. El encapsulamiento evita la corrupción de los datos de un objeto. Si todos los programas pudieran tener acceso a los datos de cualquier forma que quisieran los usuarios, los datos se podrían corromper o utilizar de mala manera. El encapsulado protege los datos del uso arbitrario y no pretendido. El encapsulado oculta los detalles de su implantación interna a los usuarios de un objeto. Los usuarios se dan cuenta de las operaciones que puede solicitar del objeto, pero desconocen los detalles de cómo se lleva a cabo la operación. Todos los detalles específicos de los datos del objeto y la codificación de sus operaciones están fuera del alcance del usuario. Así, encapsulado es el resultado (o acto) de ocultar los detalles de implantación de un objeto respecto de su usuario. El encapsulado, al separar el comportamiento del objeto de su implantación, permite la modificación de ésta sin que se tengan que modificar las aplicaciones que lo utilizan. Mensajes Para que un objeto haga algo, le enviamos una solicitud. Esta hace que se produzca una operación. La operación ejecuta el método apropiado y, de manera opcional, produce una respuesta. El mensaje que constituye la solicitud contiene el nombre del objeto, el nombre de una operación y, a veces, un grupo de parámetros. La programación orientada a objetos es una forma de diseño modular en la que con frecuencia el mundo se piensa en términos de objetos, operaciones, métodos y mensajes que se transfieren entre tales objetos. Un mensaje es una solicitud para que se lleve a cabo la operación indicada y se produzca el resultado. Los objetos pueden ser muy complejos, puesto que pueden contener muchos subobjetos, éstos a su vez pueden contener otros, etc. La persona que utilice el objeto no tiene que conocer su complejidad interna, sino la forma de comunicarse con él y la forma en que responde.

2

Clase El término clase se refiere a la implantación en software de un tipo de objeto. El tipo de objeto es una noción de concepto. Especifica una familia de objetos sin estipular la forma en que se implanten. Los tipos de objetos se especifican durante el análisis OO. Así, una clase es una implantación de un tipo de objeto. Especifica una estructura de datos y los métodos operativos permisibles que se aplican a cada uno de sus objetos. Herencia Un tipo de objeto de alto nivel puede especializarse en tipos de objeto de bajo nivel. Un tipo de objeto puede tener subtipos. Por ejemplo, el tipo de objeto persona puede tener subtipos estudiante y empleado. A su vez, el tipo de objeto estudiante puede tener como subtipo estudiante de pregrado y estudiante de postgrado, mientras que empleado puede tener como subtipo a académico y administrativo. Existe de este modo una jerarquía de tipos, subtipos, subsubtipos, etc. Una clase implanta el tipo de objeto. Una subclase hereda propiedades de su clase padre; una subsubclase hereda propiedades de las subclases; etc. Una subclase puede heredar la estructura de datos y los métodos, o algunos de los métodos, de su superclase. También tiene sus métodos e incluso tipos de datos propios. ANÁLISIS ORIENTADO A OBJETOS El análisis orientado a objetos es el proceso que modela el dominio del problema identificando y especificando un conjunto de objetos semánticos que interaccionan y se comportan de acuerdo a los requisitos del sistema [Monarchi y Puhr, 1992] El análisis orientado al objeto (OOA) consiste en una serie de técnicas y actividades mediante las que los requisitos identificados en la fase de elicitación son analizados, refinados y estructurados. El objetivo es una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que ayude a estructurar el sistema. El resultado consistirá en un modelo del sistema, modelo objeto, que describa el dominio del problema y que deberá ser correcto, completo, consistente y verificable  Permite describir el sistema en los mismos términos que el mundo real  Se centra en la comprensión del espacio (dominio) del problema  Contiene elementos de síntesis  La abstracción de requisitos de usuario y la identificación de los objetos clave del dominio es seguida del ensamblaje de estos objetos en estructuras de forma que soporten el diseño en fases posteriores Descriptores Análisis orientado a objetos; Modelo de dominio; Clase conceptual; Proceso Unificado; Objeto de entidad; Objeto de interfaz; Objeto de control Tipos de proceso en análisis  Existen diferentes enfoques de proceso en el análisis  Centran en la información (datos) del sistema  Centran en la funcionalidad (comportamiento) del sistema  Síntesis de los dos procesos anteriores 3

 El Proceso Unificado [Jacobson et al., 1999] sigue el enfoque de síntesis  Inicio por la funcionalidad (Casos de uso)  Refinamiento por la información (Diagramas de Clases)  Consolidación por la funcionalidad (Diagramas de secuencia /colaboración) EL DISEÑO ORIENTADO A OBJETOS Se define como un diseño de sistemas que utiliza objetos auto-contenidos y clases de objetos. 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 Desarrollo Orientado a Objetos: - El análisis, diseño y programación orientada a objetos están relacionados pero son diferentes - El análisis orientado a objetos concierne al desarrollo del modelo de objetos del dominio de la aplicación - El Diseño Orientado a Objetos trata del desarrollo del modelo del sistema orientado a objetos para implementar los requerimientos - La programación orientada a objetos trata de la realización del Diseño Orientado a Objetos utilizando algún lenguaje de programación orientada a objetos como C++ Métodos de Diseño Orientado a Objetos - Algunos métodos que fueron originalmente basados en funciones (método de Yourdon) han sido adaptadas al diseño orientado a objetos. Otros métodos como el método de Booch han sido específicamente desarrolladas específicamente para el Diseño Orientado a Objetos - El Diseño Orientado a Objetos es un método de diseño desarrollado para soportar la programación en Ada. - JSD (Jackson system development) tiene una cierta orientación a objetos pero no contiene información sobre estados entidad - Componentes del Diseño Orientado a Objetos - La identificación de objetos, sus atributos y servicios 4

-

La organización de objetos dentro de una jerarquía La construcción de descripciones dinámicas de objetos que muestran como se usan los servicios La especificación de interfaces de objetos

CODIFICACIÓN En el ciclo de vida de un programa, una vez que los algoritmos de una aplicación han sido diseñados, ya se puede iniciar la fase de codificación. En esta etapa se tienen que traducir dichos algoritmos a un lenguaje de programación específico; es decir, las acciones definidas en los algoritmos hay que convertirlas a instrucciones. PRUEBA Esta fase, da inicio luego de que las diferentes unidades de diseño han sido desarrolladas y probadas por separado. Durante su desarrollo, el sistema se emplea de forma experimental para asegurar que el software no falle, es decir que funcione deacuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga, y de esta forma poder detectar cualquier anomalía, antes de que el sistema sea puesto en marcha y se dependa de el. Para evaluar el desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de prueba:  Funcional: Prueba desde el punto de vista de los requerimientos funcionales.  De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeño.  De Integración: Prueba de interfaces.  De Aceptación Técnica: Prueba de manejo de condiciones extremas. Las fases del diseño, codificación y prueba absorben el 75% o más del coste de la ingeniería del software (excluyendo el mantenimiento). Es aquí donde se toman decisiones que afectarán finalmente al éxito de la implementación del programa y, con igual importancia, a la facilidad de mantenimiento que tendrá el software. Estas decisiones se llevan a cabo durante el diseño del software, haciendo que sea un paso fundamental de la fase de desarrollo. DOCUMENTACIÓN La documentación de sistemas es el conjunto de información que nos dice qué hacen los sistemas, cómo lo hacen y para quién lo hacen. La documentación consiste en material que explica las características técnicas y la operación de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el sistema y a los operandos como hacerlo funcionar. Existen varios tipos de documentación. La de programas, que explica la lógica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la del usuarios en forma general la naturaleza y capacidades del sistema y cómo usarlo. Muchas organizaciones tienen lo que se conoce como un "programa de documentación", el cual consiste en una política formal cuya documentación se muestra como algo que debe prepararse en forma rutinaria para cada programa de cómputo, archivo y nuevos sistemas.

5

Otra definición sería la de registro físico, generalmente por escrito que contiene los siguientes elementos: Políticas y normas referentes al desarrollo del sistema, su implantación, operación y mantenimiento. El diseño del sistema de información administrativo. Procedimientos para instalar el sistema de información administrativo. Procedimientos para operar el sistema de información administrativo. Procedimientos para mantener el sistema de información administrativo. IMPLEMENTACIÓN Se lleva lo especificado en el diseño a un lenguaje de programación. Dentro del ciclo de vida se encuentra la fase de implementación de un sistema, es la fase más costosa y que consume más tiempo, se dice que es costosa porque muchas personas, herramientas y recursos, están involucrados en el proceso y consume mucho tiempo porque se completa todo el trabajo realizado previamente durante el ciclo de vida. Durante la implementación las especificaciones del diseño físico son: – Codificación. – Prueba. – Instalación. – Documentación. – Adiestramiento. – Soporte. MANTENIMIENTO Luego que el nuevo sistema ha estado operando, el auditor de sistemas independiente de las otras fases de la vida del sistema, revisará lo siguiente: Determinar si el programa ha logrado los requerimientos de los objetivos, se debe prestar especial atención a la utilización y la satisfacción de los usuarios finales, ellos constituirán un indicador excelente. Verificar que se miden, analizan e informan adecuadamente a la gerencia los beneficios identificados con el estudio de factibilidad. Revisar las solicitudes de cambios a los programas que se han realizado, para evaluar el tipo de cambios que se exigen al sistema, el tipo de cambios puede indicar problemas de diseño, programación o interpretación de los requerimientos de usuario. Evaluación Los progresos realizados en un sistema deben ser medidos o evaluados para conocer las deficiencias y problemas que éste presenta. Aunque una evaluación cualitativa puede resultar útil en las etapas iníciales del desarrollo del sistema, medidas cuantitativas bajo unas mismas condiciones resultan de vital importancia para ver el progreso real del sistema y compararlo consigo mismo o con otros. Los números no aportan información si se desconoce de dónde proceden, es decir, qué representan. La evaluación de cualquier tecnología debe ir acompañada de un conjunto de medidas estándar propuestas para tal fin. La disponibilidad de bases de datos y de protocolos o procedimientos para la evaluación de estos sistemas ha sido un componente muy importante, casi fundamental, en el progreso alcanzado en este campo y ha permitido compartir nuevas ideas, e incluso compararlas con otras ya consolidadas. 6...