Analisis Orientado A Objetos 62a2w
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report r6l17
Overview 4q3b3c
& View Analisis Orientado A Objetos as PDF for free.
More details 26j3b
- Words: 3,347
- Pages: 16
INSTITUTO UNIVERSITARIO DE TECNOLOGÍA DE ISTRACIÓN INDUSTRIAL ESPECIALIDAD: ANÁLISIS DE SISTEMAS SECCION: 203-A3 PROF. NAYDRUBYS TREJO
Análisis orientado a objetos
Alzualde Yacson C.I. 18.403.495
Guarenas, Julio 2011
ANÁLISIS ORIENTADO A OBJETOS (AOO) 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.
También se puede decir que, se considera como un análisis de actividades y consiste en la solución de negocios para el y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los s y sus roles Obtener datos de los s Evaluar la información Documentar los escenarios de uso Validar con los s Validar contra la arquitectura de la empresa Según Grady Booch “Es un método de análisis que examina los requisitos desde perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema”
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 un bebé, una factura, una medida, una fecha, etc.
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.
TIPOS DE OBJETOS 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, Ana Smith, 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.
DIFERENCIAS ENTRE ENTIDAD Y OBJETOS 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 cada tipo de objeto se manejan juntos. No se puede tener 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 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 vehículo podría ser aquel que calcule la distancia a una señal determinado. Otro podría transmitir la señal de alto. Otro podría verificar de manera periódica la velocidad del vehículo.
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 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 a los datos de cualquier forma que quisieran los s, los datos se podrían corromper o utilizar de mala manera. El encapsulado protege los datos del uso arbitrario y no pretendido.
TÉCNICAS DE ANÁLISIS DE ORIENTADO A OBJETOS
LAS PERSPECTIVAS DEL ANÁLISIS ORIENTADO A OBJETOS AOO En el contexto del desarrollo de sistemas de software con orientación a objetos, se entiende por Análisis Orientado a Objetos al proceso de construcción de modelos del dominio del problema, identificando y especificando un conjunto de objetos semánticos que interactúan y se comportan de acuerdo a los requerimientos del sistema. Los objetos semánticos son aquellos que poseen un significado específico en el dominio del problema. De acuerdo a esta definición, el AOO es esencialmente basada en modelado. Es razonable esperar entonces, que la especificación resultante de la aplicación de técnicas de AOO resulte en múltiples modelos y múltiples notaciones. En esta perspectiva, el proceso de construcción de los modelos del dominio del problema debe considerar diferentes aspectos o puntos de vista. Estos aspectos constituyen las dimensiones del modelado orientado a objetos. El modelado orientado a objetos comprende, como mínimo, dos aspectos relativamente ortogonales o dimensiones para describir un sistema complejo: la dimensión estructural de los objetos y la dimensión dinámica del comportamiento. Puede ser considerada también una dimensión adicional: la dimensión funcional de los requerimientos. La dimensión estructural de los objetos se centra en el aspecto estático o pasivo. Está relacionada con la estructura estática de los objetos que forman parte del sistema. La estructura incluye la identidad de cada objeto, su clasificación, su encapsulamiento (sus atributos y sus operaciones) y sus relacionamientos estáticos (jerarquías de herencia, agregación, composición y asociaciones específicas). La dimensión dinámica del comportamiento tiene que ver con el aspecto dinámico o activo, por esto describe el comportamiento y la colaboración de los objetos que constituyen el sistema. El comportamiento es reflejado por medio de estados (pasos dentro del ciclo de vida del objeto que caracterizan comportamientos diferentes del mismo), transiciones entre estos estados, eventos (hechos que ocurren y que producen las transiciones) y acciones (representadas por los métodos de los objetos, pudiendo ocurrir durante las transiciones o durante la permanencia en los estados). La colaboración es representada por modelos que
muestran el flujo de eventos o mensajes entre los objetos. Así algunas acciones generadas en un objeto pueden gatillar transiciones, bajo la forma de eventos, en otros objetos.
UNA CLASIFICACIÓN PARA LAS TÉCNICAS DE AOO La clasificación propuesta utiliza como criterio básico el origen de la técnica, es decir, el conjunto de conceptos a partir del cual se originó la técnica. Además, es considerado el énfasis que las técnicas de AOO otorgan a los conceptos, aspectos, procedimientos o representaciones en cada una de las dimensiones del modelado. Las categorías usadas para clasificar las técnicas son: textuales, evolutivas, integracionistas, reversas y comportamentales. La figura 1 muestra la estructura de esta clasificación.
Las Técnicas Textuales: Las técnicas denominadas textuales son aquellas que se basan en descripciones informales, pero precisas, escritas en lenguaje natural para identificar objetos, atributos y operaciones tanto del dominio del problema como del dominio de la solución, a través de un análisis sintáctico de sustantivos, adjetivos, verbos y adverbios. Las técnicas de esta categoría tienen su origen fuera del paradigma de la orientación a objetos, específicamente en el trabajo de Abbott, que propone diseñar programa en Ada a partir de descripciones informales en inglés. Sin embargo, estas técnicas son insuficientes para abordar problemas más complejos y pueden ser consideradas como sobrepasadas. Se consideran aquí sólo por su relevancia histórica. Las Técnicas Evolutivas: Las técnicas evolutivas son aquellas producto de la extensión o evolución de técnicas dirigidas por alguna de las dimensiones del modelado (estructural, dinámica y/o funcional) y su complementación con otros aspectos del modelado. Esta categoría de técnicas puede ser subdividida según la dimensión “dominante” en dirigidas por datos, dirigidas por procesos y dirigidas por dinámica. Sin duda esta es la categoría más poblada por razones obvias, las técnicas originales son todas ampliamente conocidas y probadas en el desarrollo de sistema de software. Entonces parece natural intentar extenderlas para la orientación a objetos.
Las Técnicas Integracionistas: Esta categoría representa a aquellas técnicas que integran modelos separados de las diferentes dimensiones. Como técnica representativa de esta categoría se encuentra la de Rumbaugh91. Los autores proponen una técnica de desarrollo de software orientado a objetos denominada OMT (Object Modeling Technique), que incluye explícitamente el AOO como la construcción de tres modelos, uno para cada dimensión, que especifiquen el dominio del problema considerando los requerimientos. El procedimiento del AOO está íntimamente ligado a la construcción de modelos de estos tres aspectos: modelado estructural, modelado dinámico y modelado funcional. El orden en que debe ser realizado el modelado es: 1) objetos, 2) dinámica y 3) funcionalidad. Para el modelado de objetos se utiliza una extensión del modelo entidad-relacionamiento. En el modelado dinámico es utilizada una variante de los statecharts. En el modelado funcional son usados DFD extendidos con flujos de control. La integración final de estos modelos, por ejemplo la asociación de las funciones (del modelo funcional) y las acciones (del modelo dinámico) a los objetos, es hecha en una fase posterior denominada diseño de objetos. La técnica OMT se ha transformado en una de las técnicas más divulgadas, existiendo por ejemplo diferentes herramientas CASE (Computer-Aided Software Engineering) que incluyen su notación. Las Técnicas Reversas: son aquellas originadas a partir de necesidades de implementación, como por ejemplo el soporte a conceptos de lenguajes de programación orientados a objetos específicos (por ejemplo Smalltalk, C++, Eiffel o Ada2). Esta categoría puede ser fácilmente confundida con otras, pues al soportar conceptos de un lenguaje de programación orientado a objetos puede ser apropiado utilizar enfoques, notaciones y procedimientos de otra naturaleza. La técnica escogida como más representativa es la propuesta por Nerson, que define una técnica de análisis y diseño orientados a objetos para el lenguaje Eiffel, usando la notación de objetos mejorada (Better Object Notation o BON). Esta técnica consiste en tres pasos: 1) identificación, designación y clustering de clases; 2) identificación de eventos y protocolos de comunicación entre objetos; y
3) definición de clases y diseño preliminar de la arquitectura básica. La técnica se basa en conceptos de lenguaje Eiffel (cluster, relacionamiento cliente/proveedor, clases diferidas y modelos estático/dinámico), la técnica OBA (presentada en la próxima sección). Otra técnica que puede ser clasificada en esta categoría es la técnica más reciente de Booch que ha evolucionado desde un método específico de diseño para el lenguaje Ada hasta una propuesta más general. También en la línea del lenguaje Ada se encuentran las propuestas de análisis de requerimientos orientados a objetos.
PRINCIPAL FORTALEZA DE LAS TÉCNICAS DE AOO El aspecto más consolidado en la mayoría de las técnicas y que constituye su principal fortaleza es el modelado de la dimensión estructural de los objetos. Como fue indicado anteriormente la causa de esto es que la mayoría de las propuestas utilizan los conceptos del modelado semántico en base a modelos extendidos entidad-relacionamiento. Estas técnicas poseen un desarrollo de más de 20 años a partir del trabajo original de Chen. En este sentido la identificación y especificación de objetos, clases, métodos, atributos, asociaciones dependientes del dominio y jerarquías de herencia es la principal fortaleza de las técnicas de AOO.
PROCESO UNIFICADO Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.
CARACTERÍSTICAS Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema. Centrado en la arquitectura: El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.
Enfocado en los riesgos: El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.
LENGUAJE UNIFICADO DE MODELADO (UML)
El Lenguaje unificado de modelado no es el sucesor de la oleada de métodos de análisis y diseño orientados a objetos que surgió a finales de la década de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los métodos de Booch, Rumbaugh, Brühl (OMT) y Jacobson, pero su alcance llegara ser mucho mas amplio. En estos momentos el UML está en pleno proceso de estandarización con el OMG (Object Management Group o Grupo de istracion de objetos). Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
DIAGRAMAS UML Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas: - Diagrama de casos de uso. - Diagrama de clases. - Diagrama de objetos. - Diagrama de secuencia. - Diagrama de colaboración. - Diagrama de estados. - Diagrama de actividades. - Diagrama de componentes. - Diagrama de despliegue. Los diagramas más interesantes (y los más usados) son los siguientes: El diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. En la figura 2 se muestra un ejemplo de casos de uso, donde se muestran tres actores (los clientes, los taquilleros y los jefes de taquilla) y las operaciones que pueden realizar (sus roles). El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste es el diagrama más común a la hora de describir el diseño de los sistemas orientados a objetos. En la figura 3 se muestran las clases globales, sus atributos y las relaciones de una posible solución al problema de la venta de entradas.
En el diagrama de secuencia se muestra la interacción de los objetos que componen un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 4 muestra la interacción de crear una nueva sala para un espectáculo. El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el comportamiento dinámico del sistema están los de interacción, colaboración, estados y actividades. Los diagramas de componentes y despliegue están enfocados a la implementación del sistema.
ANEXOS
Figura: 1
Figura: 2
Figura: 3
Figura: 4
REFERENCIAS
Juan, C. Tema 5º Análisis Orientado a Objetos (archivo PDF publicado en línea) Disponible en http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf (2010) Análisis y diseño orientado a objetos (enciclopedia en línea wikipedia) Disponible en http://es.wikipedia.org/wiki/An%C3%A1lisis_y_dise%C3%B1o_orientado_a_objetos Edgardo G. Mario C. Victoria M. Análisis y diseño orientado a objetos (archivo publicado en línea) Disponible en http://.tripod.com/grupo_aoo/sld001.htm Lauro S. Análisis Orientado a Objetos (Pagina web) Disponible en http://www.mitecnologico.com/Main/AnalisisOrientadoAObjetos Guillermo B. Técnicas de Análisis Orientado a Objetos: Clasificación y Evaluación (archivo PDF publicado en línea) Disponible en http://eii.ucv.cl/pers/gbustos/PDF/Clasifica.PDF (2011) Proceso Unificado (enciclopedia en línea wikipedia) Disponible en http://es.wikipedia.org/wiki/Proceso_Unificado Enrique H. El Lenguaje Unificado de Modelado (UML) (archivo PDF publicado en línea) Disponible en http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
Análisis orientado a objetos
Alzualde Yacson C.I. 18.403.495
Guarenas, Julio 2011
ANÁLISIS ORIENTADO A OBJETOS (AOO) 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.
También se puede decir que, se considera como un análisis de actividades y consiste en la solución de negocios para el y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los s y sus roles Obtener datos de los s Evaluar la información Documentar los escenarios de uso Validar con los s Validar contra la arquitectura de la empresa Según Grady Booch “Es un método de análisis que examina los requisitos desde perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema”
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 un bebé, una factura, una medida, una fecha, etc.
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.
TIPOS DE OBJETOS 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, Ana Smith, 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.
DIFERENCIAS ENTRE ENTIDAD Y OBJETOS 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 cada tipo de objeto se manejan juntos. No se puede tener 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 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 vehículo podría ser aquel que calcule la distancia a una señal determinado. Otro podría transmitir la señal de alto. Otro podría verificar de manera periódica la velocidad del vehículo.
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 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 a los datos de cualquier forma que quisieran los s, los datos se podrían corromper o utilizar de mala manera. El encapsulado protege los datos del uso arbitrario y no pretendido.
TÉCNICAS DE ANÁLISIS DE ORIENTADO A OBJETOS
LAS PERSPECTIVAS DEL ANÁLISIS ORIENTADO A OBJETOS AOO En el contexto del desarrollo de sistemas de software con orientación a objetos, se entiende por Análisis Orientado a Objetos al proceso de construcción de modelos del dominio del problema, identificando y especificando un conjunto de objetos semánticos que interactúan y se comportan de acuerdo a los requerimientos del sistema. Los objetos semánticos son aquellos que poseen un significado específico en el dominio del problema. De acuerdo a esta definición, el AOO es esencialmente basada en modelado. Es razonable esperar entonces, que la especificación resultante de la aplicación de técnicas de AOO resulte en múltiples modelos y múltiples notaciones. En esta perspectiva, el proceso de construcción de los modelos del dominio del problema debe considerar diferentes aspectos o puntos de vista. Estos aspectos constituyen las dimensiones del modelado orientado a objetos. El modelado orientado a objetos comprende, como mínimo, dos aspectos relativamente ortogonales o dimensiones para describir un sistema complejo: la dimensión estructural de los objetos y la dimensión dinámica del comportamiento. Puede ser considerada también una dimensión adicional: la dimensión funcional de los requerimientos. La dimensión estructural de los objetos se centra en el aspecto estático o pasivo. Está relacionada con la estructura estática de los objetos que forman parte del sistema. La estructura incluye la identidad de cada objeto, su clasificación, su encapsulamiento (sus atributos y sus operaciones) y sus relacionamientos estáticos (jerarquías de herencia, agregación, composición y asociaciones específicas). La dimensión dinámica del comportamiento tiene que ver con el aspecto dinámico o activo, por esto describe el comportamiento y la colaboración de los objetos que constituyen el sistema. El comportamiento es reflejado por medio de estados (pasos dentro del ciclo de vida del objeto que caracterizan comportamientos diferentes del mismo), transiciones entre estos estados, eventos (hechos que ocurren y que producen las transiciones) y acciones (representadas por los métodos de los objetos, pudiendo ocurrir durante las transiciones o durante la permanencia en los estados). La colaboración es representada por modelos que
muestran el flujo de eventos o mensajes entre los objetos. Así algunas acciones generadas en un objeto pueden gatillar transiciones, bajo la forma de eventos, en otros objetos.
UNA CLASIFICACIÓN PARA LAS TÉCNICAS DE AOO La clasificación propuesta utiliza como criterio básico el origen de la técnica, es decir, el conjunto de conceptos a partir del cual se originó la técnica. Además, es considerado el énfasis que las técnicas de AOO otorgan a los conceptos, aspectos, procedimientos o representaciones en cada una de las dimensiones del modelado. Las categorías usadas para clasificar las técnicas son: textuales, evolutivas, integracionistas, reversas y comportamentales. La figura 1 muestra la estructura de esta clasificación.
Las Técnicas Textuales: Las técnicas denominadas textuales son aquellas que se basan en descripciones informales, pero precisas, escritas en lenguaje natural para identificar objetos, atributos y operaciones tanto del dominio del problema como del dominio de la solución, a través de un análisis sintáctico de sustantivos, adjetivos, verbos y adverbios. Las técnicas de esta categoría tienen su origen fuera del paradigma de la orientación a objetos, específicamente en el trabajo de Abbott, que propone diseñar programa en Ada a partir de descripciones informales en inglés. Sin embargo, estas técnicas son insuficientes para abordar problemas más complejos y pueden ser consideradas como sobrepasadas. Se consideran aquí sólo por su relevancia histórica. Las Técnicas Evolutivas: Las técnicas evolutivas son aquellas producto de la extensión o evolución de técnicas dirigidas por alguna de las dimensiones del modelado (estructural, dinámica y/o funcional) y su complementación con otros aspectos del modelado. Esta categoría de técnicas puede ser subdividida según la dimensión “dominante” en dirigidas por datos, dirigidas por procesos y dirigidas por dinámica. Sin duda esta es la categoría más poblada por razones obvias, las técnicas originales son todas ampliamente conocidas y probadas en el desarrollo de sistema de software. Entonces parece natural intentar extenderlas para la orientación a objetos.
Las Técnicas Integracionistas: Esta categoría representa a aquellas técnicas que integran modelos separados de las diferentes dimensiones. Como técnica representativa de esta categoría se encuentra la de Rumbaugh91. Los autores proponen una técnica de desarrollo de software orientado a objetos denominada OMT (Object Modeling Technique), que incluye explícitamente el AOO como la construcción de tres modelos, uno para cada dimensión, que especifiquen el dominio del problema considerando los requerimientos. El procedimiento del AOO está íntimamente ligado a la construcción de modelos de estos tres aspectos: modelado estructural, modelado dinámico y modelado funcional. El orden en que debe ser realizado el modelado es: 1) objetos, 2) dinámica y 3) funcionalidad. Para el modelado de objetos se utiliza una extensión del modelo entidad-relacionamiento. En el modelado dinámico es utilizada una variante de los statecharts. En el modelado funcional son usados DFD extendidos con flujos de control. La integración final de estos modelos, por ejemplo la asociación de las funciones (del modelo funcional) y las acciones (del modelo dinámico) a los objetos, es hecha en una fase posterior denominada diseño de objetos. La técnica OMT se ha transformado en una de las técnicas más divulgadas, existiendo por ejemplo diferentes herramientas CASE (Computer-Aided Software Engineering) que incluyen su notación. Las Técnicas Reversas: son aquellas originadas a partir de necesidades de implementación, como por ejemplo el soporte a conceptos de lenguajes de programación orientados a objetos específicos (por ejemplo Smalltalk, C++, Eiffel o Ada2). Esta categoría puede ser fácilmente confundida con otras, pues al soportar conceptos de un lenguaje de programación orientado a objetos puede ser apropiado utilizar enfoques, notaciones y procedimientos de otra naturaleza. La técnica escogida como más representativa es la propuesta por Nerson, que define una técnica de análisis y diseño orientados a objetos para el lenguaje Eiffel, usando la notación de objetos mejorada (Better Object Notation o BON). Esta técnica consiste en tres pasos: 1) identificación, designación y clustering de clases; 2) identificación de eventos y protocolos de comunicación entre objetos; y
3) definición de clases y diseño preliminar de la arquitectura básica. La técnica se basa en conceptos de lenguaje Eiffel (cluster, relacionamiento cliente/proveedor, clases diferidas y modelos estático/dinámico), la técnica OBA (presentada en la próxima sección). Otra técnica que puede ser clasificada en esta categoría es la técnica más reciente de Booch que ha evolucionado desde un método específico de diseño para el lenguaje Ada hasta una propuesta más general. También en la línea del lenguaje Ada se encuentran las propuestas de análisis de requerimientos orientados a objetos.
PRINCIPAL FORTALEZA DE LAS TÉCNICAS DE AOO El aspecto más consolidado en la mayoría de las técnicas y que constituye su principal fortaleza es el modelado de la dimensión estructural de los objetos. Como fue indicado anteriormente la causa de esto es que la mayoría de las propuestas utilizan los conceptos del modelado semántico en base a modelos extendidos entidad-relacionamiento. Estas técnicas poseen un desarrollo de más de 20 años a partir del trabajo original de Chen. En este sentido la identificación y especificación de objetos, clases, métodos, atributos, asociaciones dependientes del dominio y jerarquías de herencia es la principal fortaleza de las técnicas de AOO.
PROCESO UNIFICADO Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.
CARACTERÍSTICAS Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema. Centrado en la arquitectura: El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.
Enfocado en los riesgos: El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.
LENGUAJE UNIFICADO DE MODELADO (UML)
El Lenguaje unificado de modelado no es el sucesor de la oleada de métodos de análisis y diseño orientados a objetos que surgió a finales de la década de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los métodos de Booch, Rumbaugh, Brühl (OMT) y Jacobson, pero su alcance llegara ser mucho mas amplio. En estos momentos el UML está en pleno proceso de estandarización con el OMG (Object Management Group o Grupo de istracion de objetos). Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
DIAGRAMAS UML Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas: - Diagrama de casos de uso. - Diagrama de clases. - Diagrama de objetos. - Diagrama de secuencia. - Diagrama de colaboración. - Diagrama de estados. - Diagrama de actividades. - Diagrama de componentes. - Diagrama de despliegue. Los diagramas más interesantes (y los más usados) son los siguientes: El diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. En la figura 2 se muestra un ejemplo de casos de uso, donde se muestran tres actores (los clientes, los taquilleros y los jefes de taquilla) y las operaciones que pueden realizar (sus roles). El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste es el diagrama más común a la hora de describir el diseño de los sistemas orientados a objetos. En la figura 3 se muestran las clases globales, sus atributos y las relaciones de una posible solución al problema de la venta de entradas.
En el diagrama de secuencia se muestra la interacción de los objetos que componen un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 4 muestra la interacción de crear una nueva sala para un espectáculo. El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el comportamiento dinámico del sistema están los de interacción, colaboración, estados y actividades. Los diagramas de componentes y despliegue están enfocados a la implementación del sistema.
ANEXOS
Figura: 1
Figura: 2
Figura: 3
Figura: 4
REFERENCIAS
Juan, C. Tema 5º Análisis Orientado a Objetos (archivo PDF publicado en línea) Disponible en http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf (2010) Análisis y diseño orientado a objetos (enciclopedia en línea wikipedia) Disponible en http://es.wikipedia.org/wiki/An%C3%A1lisis_y_dise%C3%B1o_orientado_a_objetos Edgardo G. Mario C. Victoria M. Análisis y diseño orientado a objetos (archivo publicado en línea) Disponible en http://.tripod.com/grupo_aoo/sld001.htm Lauro S. Análisis Orientado a Objetos (Pagina web) Disponible en http://www.mitecnologico.com/Main/AnalisisOrientadoAObjetos Guillermo B. Técnicas de Análisis Orientado a Objetos: Clasificación y Evaluación (archivo PDF publicado en línea) Disponible en http://eii.ucv.cl/pers/gbustos/PDF/Clasifica.PDF (2011) Proceso Unificado (enciclopedia en línea wikipedia) Disponible en http://es.wikipedia.org/wiki/Proceso_Unificado Enrique H. El Lenguaje Unificado de Modelado (UML) (archivo PDF publicado en línea) Disponible en http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
Related Documents 171j1w
Analisis Orientado A Objetos 62a2w
December 2019 62
Modelado Orientado A Objetos 6h2r1e
April 2020 23
Lenguajes Orientado A Objetos 3p696p
April 2020 23
Caracteristicas De Analisis Orientado A Objetos 5e49s
December 2019 38
Oracle, Orientado A Objetos Presentacion 624hk
April 2021 0