TRABAJO ENCARGADO: DESARROLLO DE

METODOLOGIAS
I.

DISEO ORIENTADO A OBJETOS METODOLOGIA 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 sino 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 representar la 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.

II.

METODOLOGIAS ORIENTADO A OBJETO E INGENIERIA DE

SOFTWARE HENDERSON
La metodologa MOSES es una metodologa que cubre todo el ciclo de vida del
desarrollo de software orientado a objetos, no solo anlisis, sino la gestin de
proyectos, planificacin de negocio, mantenimiento de la aplicacin y futuras
mejoras. Incluye una notacin completa que adems es soportada por algunas
de las herramientas CASE que existen en el mercado, as como unas tcnicas
de gestin avanzadas que no estn disponibles en ninguna otra metodologa.
Muchas industrias estn adaptando MOSES como metodologa de desarrollo de
software de calidad. Uno de los sitios donde se est realizando (buque insignia
de esta metodologa) es el Dow Jones, Nueva York).
MOSES es un compendio de:
1. Un ciclo de vida de desarrollo de software en el modelo de ciclo de vida
fuente orientado a objeto.
2. Un ciclo de vida del producto con 3 etapas orientadas a la parte tcnica.
3. Un ciclo de vida de procesos con 5 fases solapadas orientadas a la parte
tcnica.
4. Un conjunto de 20 actividades que compones una detallada gua de
pasos a seguir.
Ventajas que ofrece MOSES:

Incorpora diagramas de modelizacin de negocio.

Consigue unos procesos mejores.
Da soporte a la reutilizacin
Las extensiones y modificaciones son ms fciles de gestionar.
Est enfocada a la calidad.
Crea una arquitectura adecuada de proyectos complejos.
Da soporte a herramientas CASE.

Modelo fuente
El modelo fuente nos da un ciclo de vida de desarrollo software (SDLC) muy
iterativo y recursivo, que es especialmente adecuado para la construccin de
software orientado a objeto. Las ventajas de la reutilizacin y el anlisis y
diseo de dominios estn incorporadas, y as se consigue un modelo
semnticamente muy rico, aunque flexible.
En este modelo (que viene a reemplazar al modelo cascada usado en anlisis
estructurado) aunque las fases son consecutivas, encontramos un considerable
solapamiento.
La creacin de sistemas orientados a objeto es ms propicia a enfocarla en
secciones denominadas clusters o subsistemas (conjuntos de clases que van a
trabajar conjunta y estrechamente). Bien, pues esta metodologa da soporte a
esta forma de trabajo, proponiendo un nuevo modelo fuente interno para cada
uno de estos subsistemas.

Ciclo de vida del producto

Existen 3 etapas orientadas al negocio que son: planificacin, construccin y

entrega (que se repiten recursivamente en cada versin generada del producto
software). Tanto la primera como la ltima han de involucrar al usuario, y
comprende las decisiones generales, mientras que la parte de construccin
seria ms tcnica.
La parte de construccin es en la que se generan ms assets, y suele tener las
siguientes fases internas: planificacin, implementacin y revisin.
Assets generados
1. En la etapa de planificacin de negocio:
El estudio de planificion de negocio. Es un asset textual, es decir es
una descripcin realizada en algn procesador de textos en lenguaje
natural.
2. En la etapa de construccin:
8 textuales: el plan de iteracin, la especificacin de requisitos del
usuario, el glosario de escenarios y actores, la especificacin de
clases, la especificacin de responsabilidades de los subsistemas, el
cdigo fuente, resultados de las pruebas y resultado de la revisin.
De estos 8 destacan 2:
La especificacin de clases (descripcin de cada clase que
aparecer en el modelo de objetos y clases) que puede hacerse
en una sintaxis formal basada en la usada de Eiffel o usando una
sintaxis ms informal.
La especificacin de responsabilidades de los subsistemas, que
es usada para documentar los nombres de los distintos
subsistemas, sus servicios, sus responsabilidades y
colaboraciones. Tambin se le conoce como SRS. Se usa un
mecanismo similar a las tarjetas de clase (CRC).
5 grficos: el modelo de clases y objetos, el modelo de eventos, los
diagramas de objetos, el modelo de herencia y el modelo de
estructura de servicios:
El modelo de clases y objetos (O/C model) es el principal asset
de MOSES. Representa la estructura esttica del sistema (las
clases, sus servicios y relaciones con otras clases)
El modelo de herencia se usa para mostrar la herencia que se
produzca entre las diferentes clases, y aunque se puede
integrar en el modelo anterior, se suele hacer en este otro.
El diagrama de objetos muestra las clases que presentan
comportamiento dinmico. Muestra los diagramas de transicin
de estados aplicados a clases.
El modelo de eventos muestra las clases que presentan
comportamiento dinmico. Muestra los las secuencias de paso
de mensajes entre un conjunto de objetos que colaboren. Se
suelen usar para formalizar escenarios o casos de uso.

El modelo de estructuras de servicio (SMM model) se suele usar

significativamente bastante menos. Se aplica al diseo de la
estructura interna de los mtodos.

3. En la etapa de entrega:
Estudio de la etapa de entrega (incluye el manual del usuario). Es un
aseet textual.
Adems de todas estas tcnicas, para poder enfrentarse a proyectos
complejos se incluyen cuatro tcnicas (hojas, repositorio, visibilidad
selectiva y subsistemas).
Proceso de ciclo de vida (las 20 actividades)
El proceso de ciclo de vida se ocupa de la etapa de construccin ya
mencionada. Es dividida en cinco fases (planificacin, investigacin,
especificacin, implementacin y revisin). Las fases cubren la parte de
gestin, diseo y construccin de los diferentes assets. Es un proceso
altamente iterativo, reconstruyendo los assets en cada una de las iteraciones.
Los assets (de la etapa de construccin) son generados desde cada actividad
que compone el proceso de ciclo de vida. Dependiendo de la profundidad a la
que se llegue en una interaccin se conseguir realizar menos iteraciones,
pero, por el contrario, con poca profundidad podra obtenerse rpidamente un
prototipo de la aplicacin.
Se compone de 20 actividades, que se recomienda sean ampliadas (por
ejemplo en el diseo de base de datos, concurrencia, procesos distribuidos y
computacin en tiempo real).

III.

TECNICA DE MODELADO DE OBJETOS RAMBAUGH

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 orientadas a objetos, ms
maduras 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 del sistema. El diseador del sistema toma decisiones de alto

nivel sobre la arquitectura del mismo. Durante esta fase el sistema se
organiza en subsistemas basndose tanto en la estructura del anlisis
como en la arquitectura propuesta. Se selecciona una estrategia para
afrontar el problema.

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 que son necesarios para implementar cada clase.
OMT describe la forma en que el diseo puede ser implementado en
distintos lenguajes (orientados y no orientados a objetos, bases de
datos, etc.).

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. Describe la estructura esttica de los objetos del

sistema
(identidad,
relaciones
con
otros
objetos,
atributos
y operaciones). El modelo de objetos proporciona el entorno esencial en
el cual se pueden situar el modelo dinmico y el modelo funcional.
El objetivo es capturar aquellos conceptos del mundo real que sean
importantes para la aplicacin. Se representa mediante diagramas 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

Modelo de Objetos
Esta es la parte principal de la Tcnica para modelado ya que se fundamenta
en la teora de OO. La definicin clara de las entidades que intervienen en el
sistema es un paso inicial necesario para poder definir qu transformaciones
ocurren en ellas y cundo se producen estas transformaciones. Esta forma de
pensar es inherente al paradigma de OO donde las clases y su jerarqua
determinan el sistema.
Los diagramas de objetos permiten representar grficamente los objetos, las
clases y sus relaciones mediante dos tipos de diagramas: los diagramas de
clases y los diagramas de casos concretos (instancias). Los diagramas de
clases describen las clases que componen el sistema y que permitirn la
creacin de casos concretos, los diagramas de casos concretos describen la
manera en que los objetos del sistema se relacionan y los casos concretos que
existen en el sistema de cada clase. En los diagramas que componen este
modelo se pueden representar los siguientes elementos del sistema: objetos y
clases, atributos, operaciones, y relaciones o asociaciones.
Clases y Objetos

Los objetos y sus componentes se representan grficamente en OMT de forma

que es posible obtener una idea de los elementos que intervienen en el
sistema estudiando el modelo. Los elementos y sus caractersticas con
representacin grfica son los siguientes:

Objetos. Un objeto es, sencillamente, algo que tiene sentido en el

contexto de la aplicacin. Se definir un objeto como un concepto,
abstraccin o cosa con lmites bien definidos y con significado a efectos
del problema que se tenga entre manos.

Clases. Describe un grupo de objetos con propiedades (atributos)

similares,
con
relaciones
comunes
con
otros
y
con
una semntica comn.

Diagramas de objetos. Proporcionan un anotacin grfica formal para el

modelado de objetos, clases y sus relaciones entre s, son tiles, tanto
para el modelado abstracto como, para disear programas reales. Hay
dos tipos de diagramas de objetos

-Diagrama de clases. Esquema, patrn o plantilla para describir muchas

instancias de datos posibles.
-Diagrama de instancias. Describe la forma en que un cierto conjunto de
objetos se relacionan entre s.

Atributos. Los objetos pertenecientes a una clase presentan

caractersticas que en OMT se denominan atributos. Sin embargo, no se
deben de confundir los atributos, que son caractersticas que todos los
objetos de una clase comparten, con otros objetos que pueden formar
parte del objeto que estamos tratando.

Operaciones y mtodos. Del mismo modo que los objetos en OMT se

pueden representar las operaciones que se realizan sobre ellos o que
stos realizan sobre otros objetos del sistema. Los objetos
realizan acciones sobre otros objetos y definen acciones que se realizan
sobre ellos mismos. Los objetos de una misma clase comparten estas
operaciones, aunque tambin pueden aadir otras nuevas que no se
definan en su clase a medida que se especializa el objeto en otras
subclases. Tambin pueden redefinir las operaciones en estas
especializaciones ignorando las definiciones realizadas en las
superclases. Las operaciones pueden llevar implcito el objeto sobre el
que se realizan o que realiza la accin, de forma que es posible tener
una misma operacin que se efecte de manera distinta segn el objeto
sobre el que se aplique. La implementacin de las operaciones para cada
uno de los objetos diferentes (o subclases) se denomina mtodo. Los
mtodos implementan en cada una de las clases de forma especfica
para los objetos que representa.

Enlaces y Asociaciones

Las relaciones entre clases determinan el comportamiento del sistema y

constituyen una parte muy importante del mismo ya que mediante las
relaciones definimos la forma en que los objetos se comunican, lo que tambin
se conoce como comportamiento.
Adems las relaciones tienen una serie
de inters para el modelado del sistema.

de

caractersticas

que

son

Relaciones. En OMT se identifican a travs de enlaces: conexiones fsicas

o conceptuales entre casos concretos de objetos. Una asociacin en OMT
abstrae un conjunto de enlaces con una estructura y un significado
comunes. Desde el punto de vista de la implementacin, una asociacin
es un puntero que apunta desde un objeto a otro.

Multiplicidad. Este trmino se encuentra relacionado con las

asociaciones e indica el nmero de casos concretos de una clase que
puede relacionarse con otro caso concreto. Las relaciones ms
frecuentes son las binarias, aunque pueden darse de cualquier orden.

Conceptos Avanzados de Enlaces y Asociaciones

Atributos de los enlaces. Los enlaces as como los objetos pueden tener
atributos, que son propiedades de los enlaces de una asociacin.

Modelado de una asociacin en forma de clase. A veces resulta

conveniente modelar las asociaciones como clases en lugar de como
relaciones, cuando los enlaces pueden participar en asociaciones con
otros objetos o estn sometidos a operaciones.

Clasificacin. Tambin podemos encontrar en una asociacin de objetos

que pertenecen a una clase con multiplicidad "muchos" que deben estar
ordenados. Esta caracterstica de los objetos es una restriccin, ya que
implica una condicin que deben cumplir los elementos de la clase.

Nombre de rol. Las asociaciones conectan clases u objetos que

pertenecen a dichas clases, pero en ocasiones necesitamos restringir el
conjunto de los objetos que se relacionan dentro de la clase. Mediante
estas restricciones podemos especificar qu objetos se relacionan.
Podemos conseguir este objetivo mediante los llamados nombres de rol.
Un nombre de rol es un atributo derivado de una clase cuyo valor es un
conjunto de objetos relacionados. Los nombres de rol se utilizan cuando
las asociaciones se producen entre objetos de la misma clase ya que
suelen producirse entre subconjuntos de esas clases. Una asociacin
binaria puede tener dos roles, uno por cada extremo de la asociacin
que son identificados por sus nombres.

Cualificacin. Las asociaciones muchos a muchos y uno a muchos

pueden ser calificadas mediante un elemento calificador que reduce el
conjunto de objetos relacionados, indicando un subconjunto de la clase

que se califica en la asociacin. Las asociaciones que se pueden calificar

son las de multiplicidad uno a muchos y muchos a muchos.

Agregacin. Las relaciones de agregacin son para OMT formas de

asociacin del tipo "es parte de", como tales se definen entre una clase
agregado y una clase componente y se indican con un rombo en la parte
de la clase que acta como continente. Las relaciones de agregacin se
establecen en los llamados objetos compuestos que contienen otros
objetos y stos pueden ser de dos tipos: aquellos que tienen
existencia fsica ms all del objeto agregado, y los que no pueden
existir sin el objeto agregado.

Generalizacin y Herencia
En el paradigma de la orientacin a objetos uno de los elementos ms
importantes es la herencia. La cualidad que permite que los objetos hereden
las caractersticas (atributos) y las operaciones (mtodos) dentro de una
estructura jerrquica conlleva una serie de consecuencias de mxima
relevancia a la hora de disear un sistema informtico. Los objetos heredan un
comportamiento que puede ser modificado y unas estructuras de datos de
forma que se permite y se facilita la reutilizacin de las clases y del cdigo que
implementa sus funcionalidades.
Ambos conceptos van unidos: herencia y estructura jerrquica, de forma que la
herencia se produce por la existencia de una estructura entre los componentes
del sistema y la estructura se consigue en la implementacin del cdigo a
travs de la herencia en los lenguajes OO.
La herencia est ntimamente relacionada con la forma concreta en que
un lenguaje implementa la generalizacin, que es un trmino ms abstracto.

La generalizacin es la relacin que existe entre una clase y las

subclases que se derivan de la misma. A partir de una versin "en bruto"
se generan versiones ms especializadas de la misma que aaden
caractersticas y operaciones. La superclase es la versin general y las
subclases son especializaciones de la superclase. Las generalizaciones
pueden tener discriminadores que indican qu aspecto de la superclase
est siendo utilizado para obtener subclases ms concretas.

Anulacin. Al implementar la herencia nos encontramos en numerosas

ocasiones que las subclases redefinen operaciones que ya han sido
definidas en las superclases. Las razones para esta nueva
implementacin de operaciones que existen en las superclases son
variadas, a veces simplemente se le aaden nuevas acciones que van en
consonancia con las nuevas caractersticas que aade la subclase; otras,
se consigue optimizar las operaciones debido a que las subclases tienen
caractersticas nuevas que lo permiten, y a veces se produce por una
mala prctica de anlisis donde no se prevn las operaciones de manera
ptima.

Se han propuesto una serie de reglas a la hora de implementar la herencia

para minimizar los errores y maximizar la reutilizacin de cdigo:
a.
b. Las operaciones de consulta, aquellas que no modifican valores de
atributos, se heredan por todas las subclases.
c. Las operaciones de actualizacin, que modifican valores de atributos, se
heredan por todas las subclases y se aaden las nuevas operaciones
para aquellas que aadan atributos.
d. Las operaciones de actualizacin que se realizan sobre atributos que
tengan algn tipo de restriccin o asociacin, se bloquean para nuevas
subclases.
e. Las operaciones no pueden volver a definirse para hacer que se
comporten de distinta manera de cara al exterior, es decir; todos los
mtodos concretos de una operacin deben tener el mismo protocolo.
f.

Las operaciones se pueden refinar aadiendo comportamientos en las

subclases.

Agrupacin de entidades
Los elementos que hemos estudiado en el Modelo de Objetos se pueden
agrupar para construir el modelo completo, as, las clases, las asociaciones y
las generalizaciones forman lo que se denomina mdulo y varios mdulos
forman el modelo de objetos. En un mdulo no se deben repetir los nombres de
las clases y de las asociaciones, aunque se puede hacer referencia a la misma
clase dentro de distintos mdulos. Tambin se definen las denominadas hojas
que se utilizan para descompones un Modelo de Objetos en unidades que
podemos manejar. Una hoja es una parte de un mdulo que podemos manejar
con facilidad, sea en el formato que sea.
Notacin
Todas las relaciones y diagramas han de respetar la siguiente notacin:

IV.

TECNICA MODELADO VISUAL - IBM

Modelado para la ejecucin y BPM
Un artculo anterior del ao 2008 discuta la metodologa de modelado para la
ejecucin en el contexto de las herramientas de gestin de procesos de
negocios de IBM WebSphere. Un artculo posterior del ao 2009 describa
las mejoras realizadas en la versin V6.2 de la pila de productos BPM de IBM,
que logran que el proceso de modelado para la ejecucin sea mucho ms fcil.
Ahora, en el ao 2010, gracias a la experiencia que tenemos en casos reales de
implementacin en el campo y a algunos nuevos estndares industriales
emergentes en la gestin de procesos de negocios, es el momento indicado
para volver a revisar este tema.
Qu es el modelado para la ejecucin?
El modelado para la ejecucin no es un concepto nuevo, ya que este enfoque
se viene usando para el desarrollo de sistemas y software tradicional desde
hace ya bastante tiempo. Esta tcnica siempre comienza con un modelo

independiente de la plataforma (PIM) de alto nivel que se suele expresar en

algn tipo de lenguaje visual. Luego, a este modelo se lo puede traducir o
transformar en un modelo especfico a la plataforma (PSM) en un lenguaje de
programacin en particular para una plataforma especfica. Luego, esto se
puede compilar o interpretar para la ejecucin. De hecho, esta metodologa usa
los principios de la Arquitectura Impulsada por Modelos (MDA) de Object
Management Group (OMG). La Figura 1 le muestra la relacin existente entre
los modelos.
Transformacin del modelo

La arquitectura impulsada por modelos comienza con la idea muy conocida y

ampliamente establecida de separar la especificacin de la operacin del
sistema de los detalles de cmo dicho sistema usa las capacidades de su
plataforma. Los tres objetivos principales de MDA son la portabilidad,
la interoperabilidad y la capacidad de reutilizacin por medio de la
separacin arquitectnica de las cuestiones.
La entrega de la solucin BPM es una nueva forma impulsada por los negocios
y centrada en el proceso de entregar aplicaciones. Adems, puede y debera
usar las mejores prcticas que hemos aprendido en las ltimas dcadas de
desarrollo de software e ingeniera de sistemas. Los principios MDA son
ciertamente aplicables en este caso pero, como la entrega de la solucin BPM
es exclusiva porque pone ms nfasis sobre el diseo de negocios interactivos
y requiere una mayor participacin de los analistas y los usuarios de negocios,
deberamos tener en cuenta algunas consideraciones especiales al momento
de adoptar las tcnicas de modelado para la ejecucin.
Aplicacin del modelado para la ejecucin con WebSphere BPM
Muchas compaas usan la metodologa de modelado para la ejecucin y las
tcnicas para la entrega de soluciones basadas en la suite de productos
WebSphere BPM desde hace ya varios aos. La Figura 2 ilustra la transicin
tpica del modelo de negocios al modelo tcnico de negocios y al modelo de
implementacin.

Figura 2. Del modelo de negocios al modelo de implementacin

La Figura 2 le muestra tres fases:

Un analista de negocios o un arquitecto de procesos de negocios crea un

modelo de negocios en IBM WebSphere Business Modeler (ya sea en
modo Bsico o Avanzado). Grficamente, el modelo de negocios
representa el proceso de negocios y usa una semntica relevante para
los analistas de negocios y los expertos en la materia. El modelo de
negocios tambin se puede usar para simulacin.

Un analista tcnico de negocios o un arquitecto tcnico de procesos

refina el modelo en el modo IBM WebSphere Process Server, lo que
produce un modelo tcnico de negocios que representa grficamente el
proceso de negocios para la implementacin y comienza a transformar la
semntica de negocios en la semntica tcnica. El analista tcnico de
negocios exporta el modelo tcnico de negocios desde WebSphere
Business Modeler como un archivo de intercambio de proyecto, que es
un archivo .zip que incluye todos los artefactos de tiempo de ejecucin
que constituyen el modelo de implementacin.

Un arquitecto de procesos o un desarrollador de integracin importa el

modelo de implementacin a IBM WebSphere Integration Developer. El
modelo de implementacin representa grficamente el proceso de
negocios a implementar. El desarrollador de integracin refina todava
ms el modelo y completa la transformacin de la semntica de
negocios en la semntica tcnica.

Lo importante a tener en cuenta en este caso es que, mientras se trabaja

dentro de WebSphere Business Modeler, los modelos subyacentes se
representan como un modelo de proceso de modelo del objeto de negocios
(BOM) especfico al modelador. Cuando usted exporta el modelo como un
archivo de intercambio de proyecto, estos modelos de proceso BOM se
transforman en modelos de proceso BPEL, que son la semntica con la que
usted trabaja en WebSphere Integration Developer.

V.

ANALISIS Y DISEO ORIENTADO A OBJETOS COAD

YOURDAN
El enfoque de Coad y Yourdon, plantea que el anlisis es razonablemente
independiente de la tecnologa, en cambio el diseo viene a ser entonces cada
vez ms orientado hacia un lenguaje OO particular y a un ambiente de
desarrollo.
Las actividades de diseo OO estn agrupadas en los cuatro componentes
principales del sistema final: el componente del problema, el componente de
interfaz humana, el componente de manejo de datos y el componente de
manejo de tareas, todos ellos estn expandido a lo largo de las cinco capas con
que cuenta el diseo OO, mismas que se presentaron anteriormente en el
anlisis OO
ANLISIS ORIENTADO A OBJETOS
El enfoque de Coad y Yourdon para el anlisis orientado a objetos est basado
en cinco capas.
Capa Clase Objeto: Esta capa del anlisis y diseo indica las clases y
objetos.
Capa de Estructura: Esta capa captura diversas estructuras de clases y
objetos, como las relaciones uno a muchos.
Capa de Atributos: Esta capa detalla los atributos de las clases.
Capa de Servicios: Esta capa indica los mensajes y comportamientos de
los objetos.
Capa de Tema: Esta capa divide el
implementacin o asignaciones de equipos.

diseo

en

unidades

de

METODOLOGA OOA - OBJECT ORIENTED ANALYSIS

METODOLOGIA
Es un mtodo de anlisis que examina los requisitos desde la perspectiva de
las clases y objetos que se encuentran en el vocabulario del dominio del
problema
CMO SE ORGANIZA
Se realiza una documentacin con los requerimientos especificados por los
clientes.
DOCUMENTACIN
Documentacin del anlisis
Especificacin de requerimientos

 Diagramas casos de uso

Escenarios y subescenarios
Prototipos y evaluacin
Tcnicas usadas
El enfoque Coad y Yourdon est basado en 5 capas
Capa de estructura: Captura diversas estructuras de clases
Capa de atributos: Esta capa detalla los atributos de clase
Capa de servicios: Mensajes y comportamientos de los objetos
Capa de tema: Diseo de unidades de implementacin o asignaciones de
equipo
Capa clases de objetos: Indica clases y objetos
Realizadas por:
Generalmente es realizado por el personal que es encargado del levantamiento
de informacin como el analista
Herramientas utilizadas
Para poder realizar el anlisis se usan diagramas UML, y sistemas de
levantamiento de informacin como encuestas o entrevistas.
ODD - OBJECT-ORIENTED DESIGN - DISEO ORIENTADO A OBJETOS
Modular
Escaso acoplamiento externo y fuerte cohesin interna
Efectos laterales mnimos (encapsulamiento)
Programacin por extensin
Orientado a datos
Explota la herencia (jerrquico)
Reutilizacin de clases
Fcil de modificar
HERENCIA
Hay diferentes puntos de vista respecto a la importancia de la herencia en OOD

Identificar la jerarqua de herencia es una parte fundamental de OOD.

Obviamente esto puede ser solamente implementado usando un LPOO

La herencia es un concepto de implementacin til el cual permite

reutilizar definiciones de atributos y operaciones.

Identificar un jerarqua de de herencia en la etapa de diseo pone restricciones

innecesarias en la implementacin. La herencia introduce complejidad y esto
es indeseable, especialmente en sistemas crticos
MODELOS DE DISEO

VI.

Los modelos de diseo muestran los objetos, clases y relaciones entre

estas entidades.

Los modelos estticos describen la estructura esttica del sistema en

trminos de clases y relaciones.

Los modelos dinmicos describen las interacciones dinmicas entre

objetos.

INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS

JACOBSON
Este mtodo proporciona un soporte para el diseo creativo de productos de
software, inclusive a escala industrial. El autor plantea el problema del diseo y
construccin de software haciendo una comparacin con la industria de la
construccin, contemplando las siguientes fases:
Herramientas. Soportan todos los aspectos de la
empresa, explcitamente las actividades de
arquitectura, mtodos y procesos.
Procesos. Permite el escalamiento de los
mtodos, de tal forma que puedan ser aplicados a
proyectos de forma interactiva y en partes.
Mtodos. Establece de manera explcita los
procedimientos etapa por etapa que deben
seguirse para aplicar la arquitectura al proyecto.
Arquitectura. Una buena estructura del sistema es fcil de entender, de
cambiar y realizar pruebas y mantenimiento. Las propiedades del sistema
determinan como la arquitectura debe ser tratada durante el tiempo de vida.
Las propiedades de la arquitectura son extremadamente importantes y forman
la base del mtodo.
Diseo creativo

Las actividades creativas de un desarrollo, consisten en la transformacin de

un conjunto de requerimientos y nociones vagas, en un plan estructurado de
construccin y un plan de accin para su implementacin.
El diseo creativo tomando como referencia una base arquitectnica es seguir
paso a paso los mtodos y procesos con la asistencia de herramientas, para
convertir los requerimientos dentro de una arquitectura viable para la
construccin de un proyecto incluyendo la creacin de prototipos.

El ciclo de vida del sistema

Un aspecto importante durante el desarrollo del sistema, es considerar
explcitamente el proceso de cambio.

DESARROLLO DEL SISTEMA

Todos los sistemas cambian durante su ciclo de vida. Hoy en da el desarrollo
de los nuevos mtodos es conocer que cambios son los principales en la parte
global del ciclo de vida, as como el costo del sistema. Una industrial del
proceso debe por lo tanto saber sobre los cambios del sistema. Un sistema
normalmente desarrolla cambios incorporndose en nuevas versiones.

La primera versin de un sistema representa una pequea parte de una

composicin durante el ciclo de vida del sistema.

Las actividades de un ciclo de vida son las mismas tanto para desarrollar una
nueva versin de un sistema, as como para un sistema totalmente nuevo. La
diferencia radica en que las entradas para cada etapa cambian en cada ciclo
de vida.
Modelo de anlisis

Especifica el comportamiento funcional del sistema bajo prcticamente

circunstancias ideales y sin hacer alusin a un ambiente particular de
implementacin.
Construccin
L a primera actividad en la construccin consiste en la implementacin de los
detalles que conciernen a la arquitectura y construccin del plan, que es ir de
una mayor abstraccin a concretizar ms el plan.
Diseo
Formaliza el modelo de anlisis en trminos del ambiente de implementacin y
especifica la identidad de los bloques de construccin
Prueba del sistema
Consiste en la verificacin del trabajo de cada uno de los paquetes de servicio
definidos en el modelo de anlisis Esta fase tiene lugar en varios niveles, desde
funciones especficas, hasta el sistema completo.
Desarrollo incremental
El desarrollo del sistema es usualmente un proceso el cual toma varios aos
para su terminacin. La especificacin es seguida por el anlisis, la
construccin y prueba del sistema completo. Este mtodo puede trabajar si
todos los requerimientos del sistema son conocidos del conjunto de salida.