INSTITUTO TECNOLOGICO SUPERIOR SAN GABRIEL

MATERIA: ANLISIS Y DISEO ORIENTADO A OBJETOS

TEMA: METODOLOGIAS ORIENTADO A OBJETOS

PROFESOR: ING. NGEL HUILCA

REALIZADO POR: MARCIA CAMPOVERDE

RIOBAMBA _ECUAROR
 METODOLOGIA OMT

La metodologa OMT (Object Modeling Technique) fue creada por James

Rumbaugh y Michael Blaha en 1991, mientras James diriga un equipo de
investigacin de los laboratorios General Electric.
OMT es una de las metodologas de anlisis y diseo orientados a objetos, ms
maduros y eficientes que existen en la actualidad. La gran virtud que aporta esta
metodologa es su carcter de abierta (no propietaria), que le permite ser de
dominio pblico y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita
su
evolucin para acoplarse a todas las necesidades actuales y futuras de la
ingeniera de software.
Las fases que conforman a la metodologa OMT son:

Anlisis. El analista construye un modelo del dominio del problema, mostrando

sus propiedades ms importantes. El modelo de anlisis es una abstraccin
resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma
en que se har. Los elementos del modelo deben ser conceptos del dominio de
aplicacin y no conceptos informticos tales como estructuras de datos. Un buen
modelo debe poder ser entendido y criticado por expertos en el dominio del
problema que no tengan conocimientos informticos.

Diseo de objetos. El diseador de objetos construye un modelo de diseo

basndose en el modelo de anlisis, pero incorporando detalles de
implementacin. El diseo de objetos se centra en las estructuras de datos y
algoritmos.

Implementacin. Las clases de objetos y relaciones desarrolladas durante el

anlisis de objetos se traducen finalmente a una implementacin concreta.
Durante la fase de implementacin es importante tener en cuenta los principios de
la ingeniera del software de forma que la correspondencia con el diseo sea
directa y el sistema implementado sea flexible y extensible. No tiene sentido que
utilicemos AOO y DOO de forma que potenciemos la reutilizacin de cdigo y la
correspondencia entre el dominio del problema y el sistema informtico, si luego
perdemos todas estas ventajas con una implementacin de mala calidad.

La metodologa OMT emplea tres clases de modelos para describir el sistema:

Modelo de objetos:
Modelo dinmico. Describe los aspectos de un sistema que tratan de la
temporizacin y secuencia de operaciones (sucesos que marcan los cambios,
secuencias de sucesos, estados que definen el contexto para los sucesos) y la
organizacin de sucesos y estados. Captura el control, aquel aspecto de un
sistema que describe las secuencias de operaciones que se producen sin tener en
cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que
estn implementadas. Se representa grficamente mediante diagramas de estado.

Modelo funcional. Describe las transformaciones de valores de datos (funciones,

correspondencias, restricciones y dependencias funcionales) que ocurren dentro
del sistema. Captura lo que hace el sistema, independientemente de cuando se
haga o de la forma en que se haga. Se representa mediante diagramas de flujo de
datos.
METODOLOGA BOOCH.
Booch es la estrella en esto de los objetos. No es el mejor, ni el que tiene ms
prestigio, ni el pero, como otros famosos en esto de la informtica se ha hecho un
hueco, ha consigui fama y lo ha transformado en un negocio? l sabr. El
mtodo de Booch contiene una notacin grfica caractersticas (las famosas
"nubecitas" que representan la frontera de una abstraccin, un concepto que no
tiene necesariamente bordes sencillos o simples.), un modelo esttico, uno
dinmico, diagramas de estados, etc.
Desde mi punto de vista es "algo que hay que conocer" si se est en esto de los
objetos, pero no es el mejor mtodo. En su misma lnea se encuentra OMT
(aunque OMT, o la exposicin que Rumbaugh hace del mismo, resulta ms
structured). En la segunda edicin. Del mtodo se aproxima ms al de Rumbaugh
(el OMT) anunciando lo que se conoce como el mtodo unificado. Yo,
personalmente, sigo prefiriendo por encima de todos ellos el OORAM de
Reenskaug.

La metodologa de Booch o tambin llamado diseo orientado a objetos de Grady

Booch (OOD). Provee una forma de desarrollar anlisis y diseo de un sistema
orientado a objetos.

La metodologa de Booch es secuencial en el sentido que la fase de anlisis es

completada y posteriormente la fase de diseo tambin. Es cclica en el sentido
que cada fase est compuesta de pasos cclicos ms pequeos.

La metodologa de Booch se enfoca en el anlisis y el diseo y no en la

implementacin o la prueba del resultado de estos.
Define seis tipos de diagramas: clase, objeto, estado de transicin, interaccin,
modulo y proceso.

Para Booch el Diseo Orientado a Objetos (DOO) "es el mtodo que lleva a una
descomposicin Orientado a Objetos. Aplicando DOO, se crea software resistente
al cambio y escrito con economa de expresin. Se logra un mayor nivel de
confianza en la correccin del software a travs de la divisin inteligente de su
espacio de estados. En ltima instancia, se reducen los riesgos inherentes al
desarrollo de sistemas".
En su libro Anlisis y Diseo Orientado a Objetos con Aplicaciones, Grady Booch
seala que: "Los mtodos son importantes por varias razones. En primer lugar,
inculcan una disciplina en el desarrollo de sistemas de software complejos.
Definen los productos que sirven como vehculo comn para la comunicacin
entre los miembros de un equipo de desarrollo. Adems, los mtodos definen los
hitos que necesita la direccin para medir el progreso y gestionar el riesgo".

El papel del ingeniero como artista es particularmente dificultoso cuando la tarea

es disear un sistema completamente nuevo. Francamente, es la circunstancia
ms habitual en la ingeniera del software.

"Es imposible capturar todos los detalles sutiles de un sistema de software

complejo en una sola vista. ... Uno debe comprender la estructura taxonmica de
las clases, los mecanismos de herencia utilizados, los comportamientos
individuales de los objetos y el comportamiento dinmico del sistema en su
conjunto".

METODOLOGA DE FUSIN

La entrada para la fase de anlisis es un documento de definicin de requisitos en

lenguaje natural.

Modelo de Objetos

La finalidad del modelo de objeto en Fusin es:

Capturar los conceptos que existen en el dominio del problema y las

relaciones entre ellos.

Mostrar clases y sus relaciones, (no mostrar objetos)

El modelo de objeto representa:

o La estructura esttica de la informacin en el sistema.

o Las clases y las relaciones entre ellas.

 o Atributos de las clases.

o Agregacin

o Especializacin/generalizacin

Definiciones

Un objeto es cualquier cosa que puede ser identificada. Puede tener una serie de
valores nombrados, llamados atributos.

Los objetos se agrupan en conjuntos, llamados clases.

Las relaciones se usan para modelar la idea de la asociacin o correspondencia

entre objetos que pertenecen a clases.

Para describir una relacin, se consideran los puntos siguientes:

Restricciones de Cardinalidad. Cardinalidad es el nmero de clases que

pueden asociarse entre s en una relacin.

Invariantes. Restricciones de que alguna propiedad se debe cumplir.

Roles. Las clases que participan en una relacin tienen roles. Los nombres
para los roles o papeles en una relacin deben ser nicos.

Atributos de la relacin. Las relaciones, como los objetos, pueden tener

atributos.

Relaciones ternarias y ms altas. Las relaciones ternarias relacionan tres

objetos separados. Las que involucran ms de tres objetos se llaman
relaciones n-arias.

o La agregacin es un mecanismo para estructurar el modelo de

objetos. Permite la construccin de una clase agregada a partir de
las otras clases componentes. La agregacin modela las relaciones
todo/parte.
 o La generalizacin permite a una clase, llamada sper tipo, ser
formada sacando las propiedades comunes de varias clases,
llamadas subtipos. La especializacin es el caso inverso en el que un
nuevo subtipo se define como una versin ms especializada de un
sper tipo.

o La especializacin mltiple permite definir un nuevo subtipo como

una especializacin de ms de un sper tipo inmediato. La subclase
hereda los atributos y relaciones de todas las superclases.

METODDOLOGIA OORAM

Desde el punto de vista cualquiera que est buscando un buen mtodo orientado
a objetos para el diseo de software debera buscar en ste la solucin a sus
problemas. No es tan famoso como los dems, no ver sus iconos grficos
proliferar por revistas de programacin y, seguramente, no podr convencer a
nadie que ser conocedor y practicante del OORAM sea algo til a la hora de
cambiar de trabajo. A pesar de todo ello, creo que ste es el nico mtodo de
conozco que se puede trasladar a la prctica y obtener beneficios con ello.

MTODO UNIFICADO

Este mtodo es una evolucin/unificacin de los mtodos de Booch y Rumbaugh.

Tiene su Origen al fichar Rational (la empresa de Grady Booch) a James

Rumbaugh (creador del OMT).

Como consecuencia de ello los seores Booch y Rumbaugh (y el no menos

famoso Ivar Jacobson) se renen en la misma empresa y amenazan con dinamitar
el mundo de los objetos.
Se prev que en unos aos todas las herramientas CASE soportarn el mtodo
unificado, todos los cursos sobre programacin orientada a objetos versarn sobre
el mtodo unificado, en todas las universidades se ensear el mtodo unificado,
etc. La historia de MS-DOS y WINDOWS llevada al mundo de los objetos.
El mtodo unificado aporta nuevos diagramas y la evolucin lgica que el paso del
tiempo aporta a todo en esta vida. En Rational se puede conseguir una versin
previa (la ltima es la 0.8) de la documentacin correspondiente a este mtodo:
ojo! hay que conocer OMT y Booch antes de meterse con l.

METODOLOGIA RUP
El Proceso Unificado de Racional (Rational Unified Process en ingls,
habitualmente resumido como RUP) es un proceso de desarrollo de software
desarrollado por la empresa Rational Software, actualmente propiedad de IBM.
Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa
estndar ms utilizada para el anlisis, diseo, 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.
Tambin se conoce por este nombre al software, tambin desarrollado por
Rational, que incluye informacin entrelazada de diversos artefactos y
descripciones de las diversas actividades. Est incluido en el Rational Method
Composer (RMC), que permite la personalizacin de acuerdo con las
necesidades.
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso
Unificado, y una especificacin ms detallada, el atioRnal Unified Process, que se
vendiera como producto independiente...
Principios de desarrollo
El RUP est basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deber adaptarse a las necesidades del cliente ya que es muy
importante interactuar con l. Las caractersticas propias del proyecto u
organizacin, el tamao del mismo, as como su tipo o las regulaciones que lo
condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta
el alcance del proyecto en un rea subformal para hacer un proceso de
satisfaccin del software.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios
o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los
deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que
surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad
del producto, y se refina la direccin del proyecto as como tambin los riesgos
involucrados.
Colaboracin entre equipos
El desarrollo de software no lo hace una nica persona sino mltiples equipos.
Debe haber una comunicacin fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
Elevar el nivel de abstraccin
Este principio dominante motiva el uso de conceptos reutilizables tales como
patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por
nombrar algunos. Esto evita que los ingenieros de software vayan directamente de
los requisitos a la codificacin de software a la medida del cliente, sin saber con
certeza qu codificar para satisfacer de la mejor manera los requisitos y sin
comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel
de abstraccin tambin permite discusiones sobre diversos niveles y soluciones
arquitectnicas. stas se pueden acompaar por las representaciones visuales de
la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los
aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso
de desarrollo y no de un grupo independiente.
Ciclo de Vida
El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida
organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o
menor hincapi en las distintas actividades. En la Figura muestra cmo vara el
esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el
proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la
comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto,
la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea
Base) de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de
modelado del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline
de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de
negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado
a la baseline de la arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto por medio
de una serie de iteraciones.
Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y
diseo y se procede a su implementacin y pruebas. Se realiza una pequea
cascada para cada ciclo. Se realizan iteraciones hasta que se termine la
implementacin de la nueva versin del producto.
En la fase de transicin se pretende garantizar que se tiene un producto preparado
para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero
dependiendo de la fase el esfuerzo dedicado a una disciplina vara.
Principales Caractersticas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu,

cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo interactivo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de uso.
Incluye artefactos (que son los productos tangibles del proceso como por ejemplo,
el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea
una persona en un determinado momento, una persona puede desempear
distintos roles a lo largo del proceso).