INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

ANLISIS Y DISEO ORIENTADO A OBJETOS. Anlisis y diseo orientado a objetos (ADOO) 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. El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estndar usado en anlisis y diseo orientado a objetos. Diseo orientado a objetos es una fase de la metodologa orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando planifican su cdigo. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, tambin es definida en esta etapa. Un programa orientado a objetos es descrito por la interaccin de esos objetos. El diseo orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el anlisis orientado a objetos. Analisis orientado a objetos (AOO), como su propio nombre indica, lo que nos importa en este anlisis es distinguir cules sern los objetos que van a ser parte de la aplicacin. Tal vez sta es la tarea ms complicada del analista. En un primer momento, no debemos intentar enfocar con rigurosidad los objetos que nos puedan hacer falta en nuestra aplicacin. Lo que haremos, un Brain Storming (tormenta de ideas que depuremos con posterioridad).

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

REFERENCIAS HISTORICAS. Las ideas bsicas de la orientacin a objetos nacen a principios de los aos 60 en la Universidad de Noruega. Un equipo dirigido por el Dr. Nygaard se dedicaba a desarrollar sistemas informticos para realizar simulaciones de sistemas fsicos. La dificultad en la que se encontraba era doble. Por un lado los programas eran muy complejos y, por otro, forzosamente tenan que ser modificados. Este segundo punto era especialmente problemtico, ya que la razn de ser de los programas era el cambio y no solo se requeran varias iteraciones para obtener un producto con el rendimiento deseado, sino que muchas veces se quera obtener diversas alternativas viables cada una con sus ventajas e inconvenientes. La solucin que idearon fue disear el programa paralelamente al objeto fsico, es decir, si el objeto fsico tena cien componentes, el programa tendra cien mdulos, uno por componente. De esta forma, habra una correspondencia entre el sistema fsico y el informtico. Este enfoque resolvi los dos problemas planteados. Primeramente, ofreca una forma natural de partir un programa muy complejo y, en segundo lugar, el mantenimiento pasaba a ser controlable. El primer punto es obvio ya que, a partir el programa en unidades informticas paralelas a las fsicas, la descomposicin era automtica. El segundo punto tambin se resuelve ya que, a cada iteracin de simulacin, el analista querr cambiar o bien piezas enteras o bien el comportamiento de alguna pieza. En ambos casos la localizacin de los cambios est perfectamente clara y su alcance se reduce a un componente. Pero, poco a poco, fue obtenindose otro beneficio muy importante, que es la razn principal por la que la industria informtica se ha abocado a la orientacin a objetos. Se trata de la reusabilidad. En el proceso de construccin de un programa se obtienen piezas para futuros programas. Para dar soporte a estas ideas lo que se hizo fue crear un lenguaje para darle soporte, Simula-67, que continua utilizndose actualmente. El siguiente paso se da en los aos 70 en los Estados Unidos. Xerox tiene un centro de investigacin en Palo Alto, donde trabajan en conceptos que puedan convertirse en productos industriales al cabo de 12 a 20 aos. As pues, en aquellos aos contrataron a un joven llamado Alan Kay para que llevase a trmino las ideas que propona en su tesis doctoral, la propuesta de construccin de un ordenador llamado Dynabook, adecuado para ser utilizado por nios. El ordenador no tena teclado, la pantalla era sensible al tacto y la mayor parte de la comunicacin era grfica. Al desarrollar este proyecto se invento el Mouse y los entornos grficos. Al volver a encontrarse con una programacin compleja y experimental, como en el caso de Nygaard, decidieron crear un entorno y lenguaje llamado Smalltalk. Smalltalk tuvo una gran difusin y cuando en los aos 80 en ATT-Bell quisieron crear un sucesor al lenguaje C, incorporaron las principales ideas de Smalltalk y Simula, creando el lenguaje C++. Este desarrollo que se ha descrito se refiere slo a la evolucin que ha tenido la orientacin a objetos en el mundo de la ingeniera del software. Ha existido un desarrollo paralelo de los mismos conceptos en el mundo de la inteligencia artificial, donde el lenguaje CLOS, una variante de Lisp orientada a objetos, est muy extendido.

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

OMT (TECNICA DE MODELADO DE OBJETOS). METODOLOGA OMT. Object Modeling Tecnique (Tcnica de Modelizacin de Objetos) es una metodologa de Ingeniera del Software, tambin conocida como el Mtodo OMT de Rumbaugh, que cubre todas las fases del ciclo de vida de un producto software: anlisis, diseo, implementacin, verificacin y mantenimiento. OMT modeliza un sistema desde tres puntos de vista diferentes, relacionados entre s. OMT se apoya en tres modelos: Modelo de Objetos, Modelo Dinmico y Modelo Funcional. El Modelo de Objetos representa al aspecto estructural, esttico de un sistema: es decir, describe la estructura de los objetos del sistema en trminos de su identidad, atributos, operaciones y relaciones (asociativas, de agregacin y de herencia); el modelo se representa mediante un diagrama de objetos. El Modelo Dinmico describe los aspectos del sistema relacionados con el tiempo y el secuenciamiento de operaciones, en trminos de eventos y estados de los objetos; el modelo se representa grficamente mediante diagramas de estado que muestran la secuencia de eventos, cambios de estado y operaciones permitidas para una clase. El Modelo Funcional describe las transformaciones que sufren las informaciones del sistema; se representan mediante Diagramas de Flujo de Datos (DFDs) que describen qu hace el sistema, sin tener en cuenta quin o cundo se realizan esas acciones. Estos tres modelos van evolucionando a medida que avanza el proceso de desarrollo a travs de las siguientes cuatro fases : anlisis, diseo del sistema, diseo de los objetos, implementacin. Veremos a continuacin, brevemente, la fase de anlisis. FASE DE ANLISIS EN OMT. Los modelos obtenidos tras esta fase representaran una vista externa del sistema, indicando qu es lo que dicho sistema hace. El Modelo de Objetos es el primero que se crea y constituye el marco esencial para la construccin de los otros dos modelos. Para la obtencin de este modelo se identificarn las clases principales que forman parte del sistema, sus asociaciones con otras clases y sus atributos que correspondern respectivamente a nombres, verbos ( o frases verbales) y adjetivos ( o frases posesivas) de las especificaciones iniciales o del dominio de la aplicacin. A continuacin se organizan las clases, capturando la informacin y el comportamiento comn en superclases. Se crean as jerarquas de herencia. Para construir el Modelo Dinmico, el analista desarrolla diagramas de traza de eventos describiendo escenarios, diagramas de flujo de eventos y diagramas de estado para las clases con comportamiento dinmico relevante.

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

Corresponden a funciones o procesos en el Modelo Funcional las operaciones de los diagramas de estado que los objetos realizan como consecuencia de ciertos eventos. Los DFDs de este modelo detallarn las operaciones del Modelo Dinmico. Las entidades externas y los almacenes corresponden a objetos del Modelo de Objetos. Sin embargo, a diferencia de un objeto entidad externa (actor), un almacn no genera ninguna operacin por s solo, sino que se limita a responder a peticiones de acceso o almacenamiento. Los procesos del Modelo Funcional corresponden a operaciones en el Modelo de Objetos (etapa de adicin de operaciones); cada proceso se implementa como un mtodo en algn objeto. El proceso de anlisis de un sistema es un proceso iterativo, por lo que los modelos finales de esta etapa se obtengan, posiblemente, tras varias iteraciones de los pasos anteriores. METODOLOGIA BOOCH.

El mtodo de Booch se basa en la necesidad de disponer de varias vistas para capturar todos los detalles de un sistema software ms o menos complejo. Es interesante que para comprender completamente un sistema conozcamos: La estructura y la funcin de los objetos que lo componen. La estructura de las clases que lo integran. Los mecanismos de herencia empleados en l. El comportamiento individual de los objetos. El comportamiento del sistema visto como un todo. En la metodologa de Booch tenemos diversos tipos de diagramas, cada uno dedicado a representar un aspecto concreto del sistema que pretendamos construir. A su vez estos diagramas se dividen en dos grandes categoras: los que representan aspectos estticos del sistema y los que representan aspectos dinmicos del mismo. Entre los primeros estn los siguientes: Diagramas de clase. En ellos se representan las clases que existen y las relaciones que existen entre ellas. Las relaciones que existen entre las clases son: Asociacin, Tiene, Herencia, Utiliza y Meta clase. Diagramas de objetos. En ellos se representan los mecanismos empleados para regular la colaboracin entre los distintos objetos. Diagramas de mdulos. En ellos se indica donde se debera de declarar cada clase y cada objeto utilizado. Diagramas de procesos. Estos diagramas se emplean para indicar a qu procesador se debera asociar un proceso y dado un procesador, cul debera ser la estrategia de planificacin de los procesos asociados a l.

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

Entre los segundos, estn los Diagramas de Transicin entre Estados, de los cuales se puede tener uno para cada clase y en ellos se representa el comportamiento de un objeto mediante una sucesin ordenada, en el tiempo, de eventos. Una representacin grfica de estos diagramas se encuentra en el libro Object Oriented Analysis and Design with Applications 2. Edicin. Booch propone los siguientes pasos para el DOO: Definir el problema. Identificar clases y sus relaciones. Identificar objetos y sus atributos. Identificar operaciones o mtodos que pueden aplicarse a los objetos. Establecer interfaces para mostrar las relaciones entre los objetos y los mtodos. Decidir los aspectos del diseo de los objetos en detalle para su posterior implementacin.

METODOLOGIA RUP (RATIONAL UNIFIED PROCESS). El Proceso Unificado Racional (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. FASES Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Se define el alcance del proyecto Elaboracin: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos. Construccin: se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario. Transicin: se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

FASE DE INICIO. Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en actividades modelado del negocio y de requisitos. Modelado del negocio En esta fase el equipo se familiarizar ms al funcionamiento de la empresa, sobre conocer sus procesos. Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Requisitos En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos. Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podra hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Definir el mbito del sistema. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario. FASE DE ELABORACIN. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. Anlisis y Diseo. En esta actividad se especifican los requerimientos y se describen sobre como se van a implementar en el sistemas Transformar los requisitos al diseo del sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseo para que sea consistente con el entorno de implementacin

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

FASE DE CONSTRUCCIN. Implementacin. Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El resultado final es un sistema ejecutable. Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados, formando el Plan de Integracin. Cada implementador decide en qu orden implementa los elementos del subsistema. Si encuentra errores de diseo, los notifica. Se integra el sistema siguiendo el plan. Pruebas Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida. Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas. Verificar las funciones del producto de software segn lo diseado. Verificar que los requisitos tengan su apropiada implementacin. FASE DE TRANSICION. Despliegue. Esta actividad tiene como objetivo producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen: Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos. DURANTE TODO EL PROYECTO. Gestin del proyecto. Se vigila el cumplimiento de los objetivos, gestin de riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios. Proveer un marco de trabajo para la gestin de proyectos de software intensivos. Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos. Configuracin y control de cambios. El control de cambios permite mantener la integridad de todos los artefactos que se crean en el proceso, as como de mantener informacin del proceso evolutivo que han seguido. Entorno La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas, procesos y mtodos. Brinda una especificacin de las herramientas que se van a necesitar en cada momento, as como definir la instancia concreta del proceso que se va a seguir. En concreto las responsabilidades de este flujo de trabajo incluyen:

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

Seleccin y adquisicin de herramientas Establecer y configurar las herramientas para que se ajusten a la organizacin. Configuracin del proceso. Mejora del proceso. Servicios tcnicos. VENTAJAS DE RUP. La ventaja principal de RUP es que se basa todo en las mejores prcticas que se han intentado y se han probado en el campo. (En comparacin con XP que se basa en las prcticas inestables que utilizaron juntas se evita que se derribe). Mitigacin temprana de posibles riesgos altos, progreso visible en las primeras etapas Temprana retroalimentacin que se ajuste a las necesidades reales. Gestin de la complejidad Conocimiento adquirido en una iteracin puede aplicarse de iteracin a iteracin DESVENTAJASDE RUP. Por el grado de complejidad puede no resultar muy adecuado. El RUP es generalmente mal aplicado en el estilo cascada. Requiere conocimientos del proceso y de UML. La metodologa RUP es ms adaptable para proyectos de largo plazo. Podemos incluir adems lo ms importante antes de elegir la metodologa que vamos a usar una implementacin del Software. DISEO DE ALTO NIVEL (HLD) Y BAJO NIVEL (LLD). Diseo de Alto Nivel: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema. Diseo de Bajo Nivel: Por diseo de bajo nivel entendemos aquella parte del diseo que se centra en los aspectos ms tcnicos y explcitos del proyecto. El sistema se especifica en detalle, describiendo cmo va a funcionar internamente para satisfacer lo especificado en el Diseo de Alto Nivel. CONCLUSION.
Durante los ltimos aos ha ido creciendo en forma considerable el anlisis y diseo orientado a objetos. De un tiempo para ac ha venido presentndose un inters creciente en el campo del anlisis orientado a objetos (AOO) y el diseo orientado a objetos (DOO), lo que ha hecho ms fcil la programacin y los mtodos se han estabilizado y ahora las organizaciones pueden manejarse con tranquilidad a esta nueva tecnologa.

ING. EN SISTEMAS COMPUTACIONALES

INSTITUTO TECNOLGICO SUPERIOR DE CIUDAD ACUA

BIBLIOGRAFIA.

http://www.mitecnologico.com/Main/AnalisisOrientadoAObjetos http://es.wikipedia.org/wiki/Dise%C3%B1o_orientado_a_objetos http://programacionytecnologia.blog.com/sample-page/ http://glbrtlmb.blogdiario.com/i2006-09/ http://www.slideshare.net/chinota90/metodologia-rup http://programacionytecnologia.blog.com/sample-page/

ING. EN SISTEMAS COMPUTACIONALES