Instituto Universitario de Tecnologa

Antonio Jos de Sucre

TEMA: METODOLOGIA ORIENTADA

A OBJETOS

Prof. Ing Mara Teresa Langone

Barquisimeto

METODOLOGA ORIENTADA A OBJETOS

Una metodologa de ingeniera del software es un proceso
para producir software de una manera organizada, usando
convenciones y tcnicas de notacin predefinidas. Desde que
la comunidad de programacin orientada a objetos tuvo la
nocin de incorporar el pensamiento de que los objetos son
entidades coherentes con identidad estado y conducta, estos
objetos pueden ser organizados por sus similitudes y sus
diferencias, puestas en uso en herencia y polimorfismo, las
metodologas orientadas a objetos incorporan estos conceptos
para definir sus reglas, normas, procedimientos, guas y
notaciones para alcanzar un producto de calidad que satisfaga
las necesidades del cliente
Que consta de los siguientes elementos:
Un ciclo de vida que permita adaptarse a las reglas de
negocio y factibilidades tecnolgicas
Conjunto completo de modelos y conceptos internamente
consistentes
Coleccin de reglas y guas de desarrollo
Notacin
Tcnicas para pruebas
Mtricas apropiadas
Estndares y estrategias de pruebas
Identificacin de reglas
negocios y programacin

organizacionales,

de

Gua de manejo de proyectos y control de calidad.

reglas

de

Metodologa OMT
Object Modeling Technique (OMT):
Es importante el modelo y uso del mismo para lograr una
abstraccin, en el cual el anlisis est enfocado en el mundo
real para un nivel de diseo, tambin pone detalles
particulares para modelado de recursos de la computadora.
Esta metodologa puede ser aplicada en varios aspectos de
implementacin incluyendo archivos, base de datos
relacionales, base de datos orientados a objetos. OMT est
construido alrededor de descripciones de estructura de datos,
constantes, sistemas para procesos de transacciones.OMT
pone nfasis en especificaciones declarativas de la
informacin,
para
capturar
los
requerimientos,
especificaciones
imperativas
para
poder
descender
prematuramente en el diseo, declaraciones que permiten
optimizar los estados, adems provee un soporte declarativo
para una directa implementacin de DBMS
Data Base Manager System
Los puntos ms importantes para esta metodologa son los
siguientes:
Poner nfasis en el anlisis y no en el desarrollo.
Poner nfasis en los datos ms que en las funciones, lo que
proporciona estabilidad al proceso de desarrollo.
Utilizar una notacin comn en todas las fases a travs de
tres modelos que capturan los aspectos estticos, dinmicos y
funcionales que combinados proveen una descripcin
completa del software. La Metodologa OMT divide el proceso
de desarrollo en tres partes aisladas: anlisis, diseo e
implantacin.
Anlisis:
Su objetivo es desarrollar un modelo de lo que va a hacer el
sistema. El modelo se expresa en trminos de objetos y de
relaciones entre ellos, flujo dinmico de control y las
transformaciones funcionales.
Diseo:

Es la estrategia de alto nivel para resolver el problema y cmo

construir una solucin. Se define la arquitectura del sistema y
se toman las decisiones estratgicas.
Implementacin:
En esta fase se convierte finalmente el diseo de objetos en
cdigo. A su vez, cada una de estas fases se divide en su
tareas, como son: modelos de objetos, dinmico y funcional;
anlisis y del sistema, y objetos del sistema.
Modelo de Objetos:
En esta primera parte del anlisis se forma una primera
imagen del modelo de clases del sistema con sus atributos y
las relaciones entre ellas, usando para ello un diagrama
entidad relacin modificada en el que adems de las clases y
sus relaciones se pueden representar tambin los mtodos.
Modelo Dinmico:
El modelo dinmico usa un grafo para representar el
comportamiento dinmico de cada clase, es decir, el
comportamiento de estas ante cada evento que se produce en
el sistema. Un evento desencadenar en un cambio de estado
en la clase que se traducir en una modificacin de los
atributos o relaciones de sta.
Modelo Funcional:
Muestra que es lo que el sistema ha de hacer mediante un
diagrama de flujo de datos, sin entrar en la secuencia
temporal en la que los procesos se ejecutan. El modelo
funcional puede revelar nuevos objetos y mtodos que se
pueden incorporar en los dos modelos anteriores. Por eso se
dice que el mtodo OMT es iterativo.
Diseo del Sistema:
Se centra en la parte fsica del sistema como la
descomposicin de ste en subsistemas, el tipo de entorno en
el que se va a ejecutar, el manejo de recursos y el
almacenamiento de datos.

Diseo de los objetos:

Determina que operaciones van a realizar los mtodos y
profundiza incluso los algoritmos que va a usar. Se escogen
los distintos tipos de representacin de datos y se subdivide
en mdulos que pasarn a formar parte de la implementacin.

Metodologa BOOCH
Object Oriented Design - Grady Booch

La metodologa Booch (OOD), es una metodologa de

propsito general en la que se parte de que cada etapa no es
un proceso aislado si no que ha de
Interactuar con sus siguientes y precedentes en una especie
de bucle del que se sale cuando se est satisfecho con el
modelo conseguido. En un principio se tienen una serie de
objetos y clases que forman el sistema, a continuacin se
construye el modelo de interfaz y se examinan las relaciones
entre las clases lo que, a su vez, genera la adicin de nuevos
interfaces que generarn nuevas relaciones iterndose hasta
llegar al estado de refinamiento deseado. El mtodo Booch
proporciona un conjunto de herramientas grficas y
notaciones que ayudan representar visualmente los modelos
definidos en las fases de anlisis y diseo.
Algunas de ellas son:
Diagramas de clase:

Es una variacin de los diagramas de entidad relacin en los

que se aaden nuevos tipos de relaciones como la herencia,
instanciacin y uso. Adems permite agrupar las clases y
relaciones en categoras para diagramas demasiado
complejos.
Diagramas de objetos:
En este tipo de grfico de muestran los objetos y sus
relaciones de forma dinmica mostrando la forma en la que
los objetos se pasan mensajes entre ellos. As mismo, en esto
diagramas es posible representarla visibilidad de los objetos
siendo sta la que determina que objetos se pueden
comunicar con otros.
Diagramas temporales:
Muestran la secuencia temporal de creacin y destruccin de
objetos. Suelen ir acompaados de pseudocdigo en el que se
explica el flujo de mensajes de control entre los objetos del
sistema.
Diagramas de transicin de estados:
Permiten definir como las instancias de las clases pasan de un
estado a otro a causa de ciertos eventos y que acciones se
desencadenan de esos cambios de estado.
Diagramas de mdulo y proceso:
En Booch, en la fase de implementacin, es posible
representar mediante estos grficos la parte fsica del
sistema, es decir, podemos mostrar cmo se van a almacenar
internamente las clases y objetos, relaciones entre mdulos
en tiempo de compilacin, procesos, dispositivos y las
comunicaciones entre ellos.
Metodologa RUP
Rational Unified Process (RUP)

Proceso Unificado de Desarrollo es el resultado de tres

dcadas de desarrollo y uso prctico. Es un conjunto de
actividades necesarias para transformar los requisitos de un
usuario en un sistema de software. Ms que un simple proceso
de trabajo, es un marco de trabajo genrico que puede
especializarse para una gran variedad de dominios. Rational
Unified Process (RUP), es la metodologa estndar de la
industria para la construccin completa del ciclo de ingeniera
de software, tanto para sistemas tradicionales como para
sistemas web. Esta metodologa permite mayor productividad
en equipo y la realizacin de mejores prcticas de software a
travs de plantillas y herramientas que guan en todas las
actividades de desarrollo crtico del software. RUP unifica las
disciplinas en lo que a desarrollo de software se refiere,
incluyendo modelado de negocio,
El manejo de requerimientos, componentes de desarrollo,
ingeniera de datos, manejo y configuracin de cambios, y
pruebas, cubriendo todo el ciclo de vida de los proyectos
basado en la construccin de componentes y maximizando el
uso del UML (Unified Modeling Language). El software en
construccin est formado por componentes interconectados
a travs de interfaces. Los puntos principales en los que se
basa RUP son los siguientes:
Casos de Uso:
Los casos de uso representan los requisitos funcionales de la
aplicacin a ser desarrollada; en otras palabras, qu es lo que
debe hacer el sistema.
Arquitectura del producto:

El concepto de arquitectura de software incluye los aspectos

estticos y dinmicos ms significativos del sistema. Hay que
tomar en cuenta que tanto la arquitectura como los casos de
uso deben ser generados en paralelo, pues los casos de uso
deben encajar en la arquitectura, as como la arquitectura
debe permitir que los casos de uso se lleven a cabo.
Ciclo de vida Iterativo Incremental:
El ciclo de vida Iterativo Incremental, consiste en dividir el
trabajo en partes ms pequeas o mini proyectos. Cada mini
proyecto es una iteracin que resulta en un incremento. Las
iteraciones hacen referencias a pasos en el flujo de trabajo, y
los incrementos, al crecimiento del producto. Para una
efectividad mxima,
Las iteraciones deben estar controladas; esto es, deben
seleccionarse y ejecutarse desuna forma planificada. El RUP
se sostiene en los tres puntos bsicos anteriores. Para hacer
que funcionen, se necesitan un proceso polifactico, que
tenga en cuenta ciclos, fases, flujos de trabajo, gestin del
riesgo, control de calidad, gestin del proyecto y control de la
configuracin. El RUP ha establecido un Framework que
integra todas esas diferentes facetas.
PROCESO UNIFICADO

Proceso Unificado de Desarrollo Software o simplemente

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.
OOram

OOram (Object-Oriented Role Analysis and Modeling) Es un

mtodo de
Anlisis y diseo basado en la metfora de la orientacin a
objetos pero que introduce
El concepto de modelo de roles como principal mecanismo de
abstraccin que
Utilizar el modelador. El modelado con roles fue ideado para
modelar grandes
Sistemas y con el propsito de favorecer una implementacin
en lenguajes de
Programacin orientada a objetos. Para ello el sistema se
descompone en un conjunto
De subsistemas o reas de inters que representan
actividades desempeadas por una
Estructura de objetos que colaboran entre s. Cada una de
estas estructuras es descrita

Mediante un modelo de roles.

Un modelo de roles describe los objetos que participan en una
actividad y las
Interacciones entre ellos; contiene un conjunto de roles, de
modo que todos los
Objetos que ocupan una misma posicin en la estructura son
representados por un rol.
Un rol describe el comportamiento de un objeto en el contexto
de una actividad.
La figura 1 muestra el modelo de roles Compras Proyecto que
describe la actividad
Asociada a una solicitud de compra por un miembro de un
proyecto desarrollado en
Una organizacin. El modelo se representa mediante una vista
colaboracin y una
Vista escenario, que son las ms utilizadas del conjunto de
vistas que ofrece OOram.
Modelo de roles
De la vista escenario se deduce fcilmente la secuencia de
acciones que incluye la
Actividad. Si dos roles estn conectados mediante una lnea,
significa que existe una
Interaccin entre ellos. Si en el extremo de una lnea aparece
un puerto, significa que
Un objeto que juegue el rol asociado enviar mensajes a un
objeto que juegue el rol
Del otro extremo de la lnea. El envo de un mensaje provoca
la ejecucin de una
Operacin o mtodo sobre el objeto del rol que lo recibe. Un
puerto representado con
Un doble crculo denota que la interaccin puede ser con un
conjunto de objetos.
OOram tambin incluye la vista diagrama de estados, que
describe los estados de
Un rol y las transiciones entre ellos; la vista proceso (basada
en el estndar IDEF0
Muestra explcitamente las acciones que realizan los roles y
los flujos de

Informacin que intercambian, y la vista semntica, isomorfa

a la vista colaboracin
Del mismo modelo, pero que en vez de puertos y caminos de
interaccin entre roles,
Muestra relaciones de asociacin.
El concepto de rol unifica los conceptos clase y objeto: los
roles tienen tanto una
Naturaleza esttica como dinmica, pues permiten describir
las propiedades de los
Objetos que representan, y tambin pueden usarse para
mostrar cmo los objetos
Colaboran entre s.
Al igual que un objeto, un rol tiene identidad: puede enviar y
recibir mensajes.
La extensin de un rol es el conjunto de objetos que pueden
representar ese papel;
De forma paralela, la extensin de un modelo de roles es el
conjunto de estructuras
De objetos obtenido una vez que hacemos jugar sus roles a
los objetos del sistema;
Durante una instanciacin, un rol puede ser jugado por un
objeto como mximo.
Una clase describe un objeto independientemente del
contexto en que dicho objeto
Interacciona con otros; un rol describe un objeto en el
contexto de una actividad.
Los roles son independientes de las clases, permiten un
modelado que pospone la
Eleccin de las clases que implementan los objetos y de las
relaciones entre ellas.
Un rol puede ser implementado por una o ms clases y una
clase puede
Implementar uno o ms roles.
Mtodo de Fusin
Fusion proporciona un mtodo de desarrollo de software
orientado al objeto, que abarca desde la definicin de

requisitos a la
programacin.

Es considerada
generacin,

implementacin

como una
porque

en

un

lenguaje

metodologa de
proviene

de

segunda
de:

OMT:
modelo
de
objetos,
CRC:
interaccin
de
objetos,
BOOCH:
visibilidad,
Los
mtodos
Formales:
prey
postcondiciones.
Proporciona un proceso de desarrollo, que se divide en:
Anlisis,
Diseo
e
Implementacin.1
Ofrece notaciones para los modelos, que describen varios
aspectos
del
software.
Actualmente
ha
abandonado
su
notacin.
Proporciona
herramientas
de
gestin.
Anlisis
El anlisis se basa ms en describir lo que hace un sistema en
lugar de cmo lo hace. Para esto, hay que ver el sistema
desde la perspectiva del usuario en lugar de desde la de la
mquina. El anlisis casa con el dominio del problema y se
preocupa por el comportamiento visible externamente.
La meta de la fase de anlisis es capturar tantos requisitos del
sistema como sea posible. Se producen los siguientes
modelos
del
sistema:
Modelo
de
objetos

Modelo
Modelo
Modelo

de

la
del

del

ciclo

interfaz
funcionamiento,
de
vida.

Estos
modelos
describen:
Clases de objetos que existen en el sistema.
Relaciones
entre
esas
clases.
Operaciones que pueden realizarse en el sistema.
Secuencias
permitidas
de
estas
operaciones.
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 objetos en Fusion 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 objetos representa: la estructura esttica de la
informacin en el sistema, las clases y relaciones entre ellas
Especifica el orden en el que deben hacerse las cosas dentro
de cada fase. Tambin proporciona criterios de cundo pasar a
la
siguiente
fase.
En la fase del anlisis de Fusion, slo los atributos de una
clase son considerados. Los mtodos son considerados en la
fase de diseo. Por consiguiente, en la fase del anlisis, los
objetos son similares a las entidades en el tradicional modelo
entidad
relacin.
Atributos
de
clases,
Agregacin,
Especializacin/generalizacin.