Todo Ha cerca de la metodología

1. INSTITUTO TECNOLOGICO SUPERIOR SAN GABRIEL
MATERIA: ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
TEMA: METODOLOGIAS ORIENTADO A OBJETOS
PROFESOR: ING. ÁNGEL HUILCA
REALIZADO POR: MARCIA CAMPOVERDE
RIOBAMBA _ECUAROR

2. METODOLOGIA OMT
La metodología OMT (Object Modeling Technique) fue creada por James
Rumbaugh y Michael Blaha en 1991, mientras James dirigía un equipo de
investigación de los laboratorios General Electric.
OMT es una de las metodologías de análisis y diseño orientados a objetos, más
maduros y eficientes que existen en la actualidad. La gran virtud que aporta esta
metodología es su carácter de abierta (no propietaria), que le permite ser de
dominio público y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita
su
evolución para acoplarse a todas las necesidades actuales y futuras de la
ingeniería de software.
Las fases que conforman a la metodología OMT son:
Análisis. El analista construye un modelo del dominio del problema, mostrando
sus propiedades más importantes. El modelo de análisis es una abstracción
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
aplicación y no conceptos informáticos 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 informáticos.
Diseño de objetos. El diseñador de objetos construye un modelo de diseño
basándose en el modelo de análisis, pero incorporando detalles de
implementación. El diseño de objetos se centra en las estructuras de datos y
algoritmos.
Implementación. Las clases de objetos y relaciones desarrolladas durante el
análisis de objetos se traducen finalmente a una implementación concreta.
Durante la fase de implementación es importante tener en cuenta los principios de
la ingeniería del software de forma que la correspondencia con el diseño sea
directa y el sistema implementado sea flexible y extensible. No tiene sentido que
utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la
correspondencia entre el dominio del problema y el sistema informático, si luego
perdemos todas estas ventajas con una implementación de mala calidad.
La metodología OMT emplea tres clases de modelos para describir el sistema:
Modelo de objetos:

3. Modelo dinámico. Describe los aspectos de un sistema que tratan de la
temporización y secuencia de operaciones (sucesos que marcan los cambios,
secuencias de sucesos, estados que definen el contexto para los sucesos) y la
organización 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
están implementadas. Se representa gráficamente 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.
METODOLOGÍA BOOCH.
Booch es la estrella en esto de los objetos. No es el mejor, ni el que tiene más
prestigio, ni el pero, como otros famosos en esto de la informática se ha hecho un
hueco, ha consiguiófama y lo ha transformado en ¿un negocio? él sabrá. El
método de Booch contiene una notación gráfica características (las famosas
"nubecitas" que representan la frontera de una abstracción, un concepto que no
tiene necesariamente bordes sencillos o simples.), un modelo estático, uno
dinámico, 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 método. En su misma línea se encuentra OMT
(aunque OMT, o la exposición que Rumbaugh hace del mismo, resulta más
structured). En la segunda edición.Del método se aproxima más al de Rumbaugh
(el OMT) anunciando lo que se conoce como el método unificado. Yo,
personalmente, sigo prefiriendo por encima de todos ellos el OORAM de
Reenskaug.
La metodología de Booch o también llamado “diseño orientado a objetos de Grady
Booch (OOD)”. Provee una forma de desarrollar análisis y diseño de un sistema
orientado a objetos.
La metodología de Booch es secuencial en el sentido que la fase de análisis es
completada y posteriormente la fase de diseño también. Es cíclica en el sentido
que cada fase está compuesta de pasos cíclicos más pequeños.
La metodología de Booch se enfoca en el análisis y el diseño y no en la
implementación o la prueba del resultado de estos.
Define seis tipos de diagramas: clase, objeto, estado de transición, interacción,
modulo y proceso.
Para Booch el Diseño Orientado a Objetos (DOO) "es el método que lleva a una
descomposición Orientado a Objetos. Aplicando DOO, se crea software resistente

4. al cambio y escrito con economía de expresión. Se logra un mayor nivel de
confianza en la corrección del software a través de la división inteligente de su
espacio de estados. En última instancia, se reducen los riesgos inherentes al
desarrollo de sistemas".
En su libro Análisis y Diseño Orientado a Objetos con Aplicaciones, Grady Booch
señala que: "Los métodos 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 vehículo común para la comunicación
entre los miembros de un equipo de desarrollo. Además, los métodos definen los
hitos que necesita la dirección para medir el progreso y gestionar el riesgo".
El papel del ingeniero como artista es particularmente dificultoso cuando la tarea
es diseñar un sistema completamente nuevo. Francamente, es la circunstancia
más habitual en la ingeniería del software.
"Es imposible capturar todos los detalles sutiles de un sistema de software
complejo en una sola vista. ... Uno debe comprender la estructura taxonómica de
las clases, los mecanismos de herencia utilizados, los comportamientos
individuales de los objetos y el comportamiento dinámico del sistema en su
conjunto".
METODOLOGÍA DE FUSIÓN
La entrada para la fase de análisis es un documento de definición de requisitos en
lenguaje natural.
Modelo de Objetos
La finalidad del modelo de objeto en Fusión 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 estática de la información en el sistema.
o Las clases y las relaciones entre ellas.
o Atributos de las clases.
o Agregación
o Especialización/generalización

5. 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 asociación o correspondencia
entre objetos que pertenecen a clases.
Para describir una relación, se consideran los puntos siguientes:
Restricciones de Cardinalidad. Cardinalidad es el número de clases que
pueden asociarse entre sí en una relación.
Invariantes. Restricciones de que alguna propiedad se debe cumplir.
Roles. Las clases que participan en una relación tienen roles. Los nombres
para los roles o papeles en una relación deben ser únicos.
Atributos de la relación. Las relaciones, como los objetos, pueden tener
atributos.
Relaciones ternarias y más altas. Las relaciones ternarias relacionan tres
objetos separados. Las que involucran más de tres objetos se llaman
relaciones n-arias.
o La agregación es un mecanismo para estructurar el modelo de
objetos. Permite la construcción de una clase agregada a partir de
las otras clases componentes. La agregación modela las relaciones
todo/parte.
o La generalización permite a una clase, llamada súpertipo, ser
formada sacando las propiedades comunes de varias clases,
llamadas subtipos. La especialización es el caso inverso en el que un
nuevo subtipo se define como una versión más especializada de un
súpertipo.
o La especialización múltiple permite definir un nuevo subtipo como
una especialización de más de un súpertipo inmediato. La subclase
hereda los atributos y relaciones de todas las superclases.

6. METODDOLOGIA OORAM
Desde el punto de vista cualquiera que esté buscando un buen método orientado
a objetos para el diseño de software debería buscar en éste la solución a sus
problemas. No es tan famoso como los demás, no verá sus iconos gráficos
proliferar por revistas de programación 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 método de
conozco que se puede trasladar a la práctica y obtener beneficios con ello.
MÉTODO UNIFICADO
Este método es una evolución/unificación de los métodos 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 señores Booch y Rumbaugh (y el no menos
famoso Ivar Jacobson) se reúnen en la misma empresa y amenazan con dinamitar
el mundo de los objetos.
Se prevé que en unos años todas las herramientas CASE soportarán el método
unificado, todos los cursos sobre programación orientada a objetos versarán sobre
el método unificado, en todas las universidades se enseñará el método unificado,
etc. La historia de MS-DOS y WINDOWS llevada al mundo de los objetos.
El método unificado aporta nuevos diagramas y la evolución lógica que el paso del
tiempo aporta a todo en esta vida. En Rational se puede conseguir una versión
previa (la última es la 0.8) de la documentación correspondiente a este método:
¡ojo! hay que conocer OMT y Booch antes de meterse con él.
METODOLOGIA RUP
El Proceso Unificado de Racional (Rational Unified Process en inglés,
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 metodología
estándar más utilizada para el análisis, diseño, implementación y documentación
de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software, también desarrollado por
Rational, que incluye información entrelazada de diversos artefactos y
descripciones de las diversas actividades. Está incluido en el Rational

7. MethodComposer (RMC), que permite la personalización de acuerdo con las
necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso
Unificado, y una especificación más 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 características propias del proyecto u
organización, el tamaño del mismo, así como su tipo o las regulaciones que lo
condicionen, influirán en su diseño específico. También se deberá tener en cuenta
el alcance del proyecto en un área subformal para hacer un proceso de
satisfacción 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 podrán 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 iteración se analiza la opinión de los inversores, la estabilidad y calidad
del producto, y se refina la dirección del proyecto así como también los riesgos
involucrados.
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos.
Debe haber una comunicación fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como
patrón 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 codificación 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 reutilización del código. Un alto nivel
de abstracción también permite discusiones sobre diversos niveles y soluciones
arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de
la arquitectura, por ejemplo con el lenguaje UML.

8. Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los
aspectos de la producción. 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 implementación 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 número variable según el proyecto y en las que se hace un mayor o
menor hincapié en las distintas actividades. En la Figura muestra cómo varía el
esfuerzo asociado a las disciplinas según la fase en la que se encuentre el
proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto,
la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea
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 elaboración, las iteraciones se orientan al desarrollo de la baseline
de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de
negocios (refinamiento), análisis, diseño y una parte de implementación orientado
a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio
de una serie de iteraciones.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y
diseño y se procede a su implementación y pruebas. Se realiza una pequeña
cascada para cada ciclo. Se realizan iteraciones hasta que se termine la
implementación de la nueva versión del producto.
En la fase de transición 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 varía.
Principales Características
 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo interactivo
 Administración de requisitos

9.  Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación 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 código fuente, etc.) y roles (papel que desempeña
una persona en un determinado momento, una persona puede desempeñar
distintos roles a lo largo del proceso).