Metodologa OMT

OMT el significado de las siglas de esta metodologa es Object Modeling Technique y en

espaol es Tcnica de Modelado en Objetos. Es una tcnica de modelado de objetos,
desarrollada por James Rumbaugh, que es uno de los precursores del Lenguaje Unificado de
Modelado (UML).

Qu es?
OMT es una de las metodologas de anlisis y diseo orientados a objetos, ms eficientes que
existen en la actualidad. La gran virtud que aporta esta metodologa es su carcter de abierta
(no propietaria), es decir, 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.

Fases de la metodologa OMT

ANLISIS DISEO IMPLEMENTACIN

1. 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. En esta parte se maneja de forma exacta la construccin
de los modelos objetos.
La metodologa OMT emplea 3 pasos que son los modelos para describir la fase
anlisis:
 Modelo Objeto
PASOS ACTIVIDADES

IDENTIFICACIN DEL MODELO o Identificar los Objetos y Clases.

OBJETO o Identificar la asociacin entre Objetos.
o Identificar las clases y mdulos.
o Agrupar las clases y mdulos.
o Preparar el diccionario de datos
IDENTIFICACIN DEL MODELO o Definir para cada objeto que eventos
DINMICO tendr.
o Construir los diagramas de estado para el
comportamiento de los objetos.
IDENTIFICACIN DEL MODELO o Manejar la elaboracin de diagramas de
FUNCIONAL flujo de datos para identificar la
independencia que existe entre
operaciones.
o Distinguir los valores de entrada y salida.

2. Diseo

Diseo del Sistema

El diseo del sistema es la estrategia de alto nivel para resolver el problema y

construir una solucin, incluye decisiones acerca de la organizacin del
sistema (arquitectura del sistema) en subsistemas, la asignacin de
subsistemas a componentes de hardware y software y decisiones
fundamentales conceptuales y de poltica que son las que constituyen el marco
de trabajo para el diseo detallado. Durante el diseo del sistema se aaden
estructuras en el dominio de la solucin. El modelo de diseo debe ser
razonablemente eficiente y prctico a la hora de codificar, tratando detalles de
bajo nivel que se omiten en el modelo de anlisis.

La metodologa de Rumbaugh, no abarca este aspecto, sin embargo sugiere

algunas ideas generales
Organizar el sistema en subsistemas.
Identificar la concurrencia inherente en el problema.
Asignar los subsistemas a procesadores y a tareas.
Seleccionar la estrategia bsica de implementacin de los almacenes
de datos, en trminos de estructuras de datos, archivos y bases de
datos.
Identificar los recursos globales y determinar los mecanismos para
controlar el acceso a tales recursos.
 Seleccionar una aproximacin para implementar el control del
software. Consideraciones de condiciones de contorno.
Establecimiento de prioridades de compensacin.

Diseo de Objetos

En el Diseo de Objetos se toman las decisiones necesarias para construir un

sistema sin descender a los detalles particulares de un lenguaje o sistema de
base de datos. El diseo de objetos es el comienzo de un desplazamiento con
respecto al mundo real, en el modelo de anlisis, aproximndose a la
orientacin a la computadora, necesaria para una implementacin prctica.
Rumbaugh sugiere las siguientes etapas:

Obtencin de las operaciones para el modelo de objetos a partir de los

dems modelos.
Diseo de algoritmos para la implementacin de las operaciones.
Optimizacin de las vas de acceso a los datos.
Implementar el control del software completando la aproximacin
seleccionada durante el diseo del sistema.
Ajuste de la estructura de clases para incrementar la herencia.
Diseo de la implementacin de las asociaciones.
Se determina la representacin exacta de los atributos que son objetos.
Empaquetamiento de las clases y asociaciones en mdulos.

3. Implementacin

Durante la implementacin se codifican, tanto las estructuras en el dominio de la

aplicacin como las estructuras en el dominio de la solucin. La base que la sustenta
es el diseo de objetos. El cdigo puede ser una simple transicin de las decisiones
de diseo a las caractersticas propias de un lenguaje.
 Metodologa XP
La programacin extrema o eXtreme Programming (XP) es la metodologa posiblemente ms
destacada de las metodologas giles, esto se debe a su gran capacidad de adaptacin ante
cualquier tipo de imprevisto que surja.

Por esta razn, no se mantienen ciertos requisitos desde el comienzo de la elaboracin del
proyecto y en su lugar va evolucionando gradualmente sin complicaciones durante el
proceso.

Los creadores de esta metodologa consideran que es mejor adaptarse en el proceso a los
requisitos que vayan apareciendo, que iniciar con requisitos y desarrollar un proyecto en base
a eso.

Valores de la Metodologa XP

Para garantizar el xito de un proyecto, los autores de XP se consider los siguientes valores:

Simplicidad

La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar

el desarrollo y facilitar el mantenimiento. Un diseo complejo del cdigo junto a sucesivas
modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente
exponencialmente.

Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de

mantener el cdigo simple a medida que crece.

Comunicacin

Para los programadores el cdigo comunica mejor cuanto ms simple sea. Si el cdigo es
complejo hay que esforzarse para hacerlo inteligible. (Que puede ser comprendido o
entendido.) El cdigo autodocumentado es ms fiable que los comentarios ya que stos
ltimos pronto quedan desfasados(inadecuado) con el cdigo a medida que es modificado.

Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases
y los mtodos al mostrar ejemplos concretos de cmo utilizar su funcionalidad. Los
programadores se comunican constantemente gracias a la programacin por parejas. La
comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo.
El cliente decide qu caractersticas tienen prioridad y siempre debe estar disponible para
solucionar dudas.

Retroalimentacin (feedback)

Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce
en tiempo real.

Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener
que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse
en lo que es ms importante.

Coraje o valenta

Muchas de las prcticas implican valenta. Una de ellas es siempre disear y programar para
hoy y no para maana. Esto es un esfuerzo para evitar saturarse en el diseo y requerir
demasiado tiempo y trabajo para implementar el resto del proyecto. La valenta le permite a
los desarrolladores que se sientan cmodos con reconstruir su cdigo cuando sea necesario.
Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se
implementaran ms fcilmente.

Respeto

El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a
otros, porque los programadores no pueden realizar cambios que hacen que las pruebas
existentes fallen o que demore el trabajo de sus compaeros. Los miembros respetan su
trabajo porque siempre estn luchando por la alta calidad en el producto y buscando el diseo
ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo.

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo

pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin.
Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a
Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres ltimas inspiradas en
JUnit, la cual, a su vez, se insipir en SUnit, el primer framework orientado a realizar tests,
realizado para el lenguaje de programacin Smalltalk.

Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por
dos personas en un mismo puesto. La mayor calidad del cdigo escrito de esta manera -el
cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida
de productividad inmediata.

Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda

que un representante del cliente trabaje junto al equipo de desarrollo.

Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas
frecuentes.

Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su
legibilidad y mantenibilidad, pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorizacin no se ha introducido ningn fallo.

Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de

cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin
garantizan que los posibles errores sern detectados.

Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que
es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se
requiere, que realizar algo complicado y quizs nunca utilizarlo.