INSTITUTO UNIVERSITARIO DE TECNOLOGA DE ADMINISTRACIN INDUSTRIAL ESPECIALIDAD: ANLISIS DE SISTEMAS SECCION: 203-A3 PROF.

NAYDRUBYS TREJO

Anlisis orientado a objetos

Alzualde Yacson C.I. 18.403.495

Guarenas, Julio 2011

ANLISIS ORIENTADO A OBJETOS (AOO)

Es un enfoque de la ingeniera de software que modela un sistema como un grupo de objetos que interactan entre s. Este enfoque representa un dominio en trminos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional. En este mtodo de anlisis y diseo se crea un conjunto de modelos utilizando una notacin acordada como, por ejemplo, el lenguaje unificado de modelado (UML). ADOO aplica tcnicas de modelado de objetos para analizar los requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de mdulos de software - y para disear una solucin para mejorar los procesos involucrados. No est restringido al diseo de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologas de anlisis y diseo ms modernas son casos de uso guiados a travs de requerimientos, diseo, implementacin, pruebas, y despliegue.

Tambin se puede decir que, se considera como un anlisis de actividades y consiste en la solucin de negocios para el usuario y se expresa con los casos de uso. El diseo lgico es la solucin del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la informacin Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa Segn Grady Booch Es un mtodo de anlisis 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 podra 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 mtodos que controlan dichos datos.

Un objeto puede estar compuesto por otros objetos. Estos ltimos a su vez tambin 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 organizacin. Algunas instancias de empleado podran ser Juan Prez, Ana Smith, etc. En el anlisis orientado a objetos, estos conceptos se llaman tipos de objetos; las instancias se llaman objetos. As, un tipo de objeto es una categora de objeto, mientras que un objeto es una instancia de un tipo de objeto.

DIFERENCIAS ENTRE ENTIDAD Y OBJETOS El trmino objeto tiene diferencias fundamentales con el trmino entidad, ya que la entidad slo se refiere a los datos, mientras que objeto se refiere a los datos y a los mtodos mediante los cuales se controlan a los propios datos. En OO, la estructura de datos y los mtodos de cada tipo de objeto se manejan juntos. No se puede tener acceso o control de la estructura de datos excepto mediante los mtodos que forman parte del tipo de objeto.

MTODOS

Los mtodos especifican la forma en que se controlan los datos de un objeto. Los mtodos en un tipo de objeto slo 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 estn representadas por tipos de datos y su comportamiento por mtodos.

Un mtodo asociado con el tipo de objeto vehculo podra ser aquel que calcule la distancia a una seal determinado. Otro podra transmitir la seal de alto. Otro podra verificar de manera peridica la velocidad del vehculo.

ENCAPSULADO

El empaque conjunto de datos y mtodos se llama encapsulado. El objeto esconde sus datos de los dems objetos y permite el acceso a los datos mediante sus propios mtodos. Esto recibe el nombre de ocultamiento de informacin. El encapsulamiento evita la corrupcin 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 podran corromper o utilizar de mala manera. El encapsulado protege los datos del uso arbitrario y no pretendido.

TCNICAS DE ANLISIS DE ORIENTADO A OBJETOS

LAS PERSPECTIVAS DEL ANLISIS ORIENTADO A OBJETOS AOO En el contexto del desarrollo de sistemas de software con orientacin a objetos, se entiende por Anlisis Orientado a Objetos al proceso de construccin de modelos del dominio del problema, identificando y especificando un conjunto de objetos semnticos que interactan y se comportan de acuerdo a los requerimientos del sistema. Los objetos semnticos son aquellos que poseen un significado especfico en el dominio del problema. De acuerdo a esta definicin, el AOO es esencialmente basada en modelado. Es razonable esperar entonces, que la especificacin resultante de la aplicacin de tcnicas de AOO resulte en mltiples modelos y mltiples notaciones. En esta perspectiva, el proceso de construccin 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 mnimo, dos aspectos relativamente ortogonales o dimensiones para describir un sistema complejo: la dimensin estructural de los objetos y la dimensin dinmica del comportamiento. Puede ser considerada tambin una dimensin adicional: la dimensin funcional de los requerimientos. La dimensin estructural de los objetos se centra en el aspecto esttico o pasivo. Est relacionada con la estructura esttica de los objetos que forman parte del sistema. La estructura incluye la identidad de cada objeto, su clasificacin, su encapsulamiento (sus atributos y sus operaciones) y sus relacionamientos estticos (jerarquas de herencia, agregacin, composicin y asociaciones especficas). La dimensin dinmica del comportamiento tiene que ver con el aspecto dinmico o activo, por esto describe el comportamiento y la colaboracin 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 mtodos de los objetos, pudiendo ocurrir durante las transiciones o durante la permanencia en los estados). La colaboracin 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 CLASIFICACIN PARA LAS TCNICAS DE AOO La clasificacin propuesta utiliza como criterio bsico el origen de la tcnica, es decir, el conjunto de conceptos a partir del cual se origin la tcnica. Adems, es considerado el nfasis que las tcnicas de AOO otorgan a los conceptos, aspectos, procedimientos o representaciones en cada una de las dimensiones del modelado. Las categoras usadas para clasificar las tcnicas son: textuales, evolutivas, integracionistas, reversas y comportamentales. La figura 1 muestra la estructura de esta clasificacin.

Las Tcnicas Textuales: Las tcnicas 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 solucin, a travs de un anlisis sintctico de sustantivos, adjetivos, verbos y adverbios. Las tcnicas de esta categora tienen su origen fuera del paradigma de la orientacin a objetos, especficamente en el trabajo de Abbott, que propone disear programa en Ada a partir de descripciones informales en ingls. Sin embargo, estas tcnicas son insuficientes para abordar problemas ms complejos y pueden ser consideradas como sobrepasadas. Se consideran aqu slo por su relevancia histrica. Las Tcnicas Evolutivas: Las tcnicas evolutivas son aquellas producto de la extensin o evolucin de tcnicas dirigidas por alguna de las dimensiones del modelado (estructural, dinmica y/o funcional) y su complementacin con otros aspectos del modelado. Esta categora de tcnicas puede ser subdividida segn la dimensin dominante en dirigidas por datos, dirigidas por procesos y dirigidas por dinmica. Sin duda esta es la categora ms poblada por razones obvias, las tcnicas originales son todas ampliamente conocidas y probadas en el desarrollo de sistema de software. Entonces parece natural intentar extenderlas para la orientacin a objetos.

Las Tcnicas Integracionistas: Esta categora representa a aquellas tcnicas que integran modelos separados de las diferentes dimensiones. Como tcnica representativa de esta categora se encuentra la de Rumbaugh91. Los autores proponen una tcnica de desarrollo de software orientado a objetos denominada OMT (Object Modeling Technique), que incluye explcitamente el AOO como la construccin de tres modelos, uno para cada dimensin, que especifiquen el dominio del problema considerando los requerimientos. El procedimiento del AOO est ntimamente ligado a la construccin de modelos de estos tres aspectos: modelado estructural, modelado dinmico y modelado funcional. El orden en que debe ser realizado el modelado es: 1) objetos, 2) dinmica y 3) funcionalidad. Para el modelado de objetos se utiliza una extensin del modelo entidad-relacionamiento. En el modelado dinmico es utilizada una variante de los statecharts. En el modelado funcional son usados DFD extendidos con flujos de control. La integracin final de estos modelos, por ejemplo la asociacin de las funciones (del modelo funcional) y las acciones (del modelo dinmico) a los objetos, es hecha en una fase posterior denominada diseo de objetos. La tcnica OMT se ha transformado en una de las tcnicas ms divulgadas, existiendo por ejemplo diferentes herramientas CASE (Computer-Aided Software Engineering) que incluyen su notacin. Las Tcnicas Reversas: son aquellas originadas a partir de necesidades de implementacin, como por ejemplo el soporte a conceptos de lenguajes de programacin orientados a objetos especficos (por ejemplo Smalltalk, C++, Eiffel o Ada2). Esta categora puede ser fcilmente confundida con otras, pues al soportar conceptos de un lenguaje de programacin orientado a objetos puede ser apropiado utilizar enfoques, notaciones y procedimientos de otra naturaleza. La tcnica escogida como ms representativa es la propuesta por Nerson, que define una tcnica de anlisis y diseo orientados a objetos para el lenguaje Eiffel, usando la notacin de objetos mejorada (Better Object Notation o BON). Esta tcnica consiste en tres pasos: 1) identificacin, designacin y clustering de clases; 2) identificacin de eventos y protocolos de comunicacin entre objetos; y

3) definicin de clases y diseo preliminar de la arquitectura bsica. La tcnica se basa en conceptos de lenguaje Eiffel (cluster, relacionamiento cliente/proveedor, clases diferidas y modelos esttico/dinmico), la tcnica OBA (presentada en la prxima seccin). Otra tcnica que puede ser clasificada en esta categora es la tcnica ms reciente de Booch que ha evolucionado desde un mtodo especfico de diseo para el lenguaje Ada hasta una propuesta ms general. Tambin en la lnea del lenguaje Ada se encuentran las propuestas de anlisis de requerimientos orientados a objetos.

PRINCIPAL FORTALEZA DE LAS TCNICAS DE AOO El aspecto ms consolidado en la mayora de las tcnicas y que constituye su principal fortaleza es el modelado de la dimensin estructural de los objetos. Como fue indicado anteriormente la causa de esto es que la mayora de las propuestas utilizan los conceptos del modelado semntico en base a modelos extendidos entidad-relacionamiento. Estas tcnicas poseen un desarrollo de ms de 20 aos a partir del trabajo original de Chen. En este sentido la identificacin y especificacin de objetos, clases, mtodos, atributos, asociaciones dependientes del dominio y jerarquas de herencia es la principal fortaleza de las tcnicas 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 ms 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 especficos. De la misma forma, el Proceso Unificado de Rational, tambin 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 genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin 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 versin espaola, 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 tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

CARACTERSTICAS Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade 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 clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara 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 iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, 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 mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.

Enfocado en los riesgos: El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, 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 mtodos de anlisis y diseo orientados a objetos que surgi a finales de la dcada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los mtodos de Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su alcance llegara ser mucho mas amplio. En estos momentos el UML est en pleno proceso de estandarizacin con el OMG (Object Management Group o Grupo de administracion de objetos). Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar 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 programacin, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos 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 metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo 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 representacin grfica 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 colaboracin. - Diagrama de estados. - Diagrama de actividades. - Diagrama de componentes. - Diagrama de despliegue. Los diagramas ms interesantes (y los ms usados) son los siguientes: El diagrama de casos de usos representa grficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interaccin 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 cmo. 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 ms comn a la hora de describir el diseo de los sistemas orientados a objetos. En la figura 3 se muestran las clases globales, sus atributos y las relaciones de una posible solucin al problema de la venta de entradas.

En el diagrama de secuencia se muestra la interaccin de los objetos que componen un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 4 muestra la interaccin de crear una nueva sala para un espectculo. El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el comportamiento dinmico del sistema estn los de interaccin, colaboracin, estados y actividades. Los diagramas de componentes y despliegue estn enfocados a la implementacin del sistema.

ANEXOS

Figura: 1

Figura: 2

Figura: 3

Figura: 4

REFERENCIAS

Juan, C. Tema 5 Anlisis Orientado a Objetos (archivo PDF publicado en lnea) Disponible en http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf (2010) Anlisis y diseo orientado a objetos (enciclopedia en lnea wikipedia) Disponible en http://es.wikipedia.org/wiki/An%C3%A1lisis_y_dise%C3%B1o_orientado_a_objetos Edgardo G. Mario C. Victoria M. Anlisis y diseo orientado a objetos (archivo publicado en lnea) Disponible en http://members.tripod.com/grupo_aoo/sld001.htm Lauro S. Anlisis Orientado a Objetos (Pagina web) Disponible en http://www.mitecnologico.com/Main/AnalisisOrientadoAObjetos Guillermo B. Tcnicas de Anlisis Orientado a Objetos: Clasificacin y Evaluacin (archivo PDF publicado en lnea) Disponible en http://eii.ucv.cl/pers/gbustos/PDF/Clasifica.PDF (2011) Proceso Unificado (enciclopedia en lnea wikipedia) Disponible en http://es.wikipedia.org/wiki/Proceso_Unificado Enrique H. El Lenguaje Unificado de Modelado (UML) (archivo PDF publicado en lnea) Disponible en http://www.disca.upv.es/enheror/pdf/ActaUML.PDF