UML.

Una Metodologa Orientada a Objetos

aplicada a la Reingeniera de la Empresa
MIGUEL REBOLLO PEDRUELO
Departamento de Sistemas Informticos y Computacin
Universidad de Valencia

El proceso de reingeniera busca construir el modelo de una situacin real, con el

fin de determinar su funcionamiento para mejorarlo posteriormente. Cuando el sistema
que se considera es el mundo empresarial, se habla de reingeniera de la empresa. Para
realizar este proceso se pueden utilizar herramientas que nacen del campo de la Infor mtica, en concreto el anlisis y diseo orientado a objetos.
En el presente artculo se muestra cmo aplicar la metodologa y el lenguaje UML
al proceso de reingeniera de la empresa. Esta tcnica permite determinar la estructura
de la empresa y sus procesos internos y externos, de forma que es posible detectar y co rregir un posible malfuncionamiento, modificar su estructura para modernizarla, apli car tcnicas de control, etc usando unos mecanismos formales que garantizan su co rreccin y facilitan la construccin de sistemas de informacin que soporten los nuevos
procesos rediseados.

1. INTRODUCCIN
Ha llegado el momento de cambiar estructura, administracin y desempeo de los negocios: entramos en el siglo XXI con empresas creadas en el siglo XX con las ideas del
siglo XIX. Estos cambios estn motivados, entre otras razones, por la fuerte variacin que
se ha producido en los clientes, en la competencia y en el propio proceso de cambio.
Los clientes exigen productos y servicios diseados a medida. Ya no se trata con un
mercado masivo que est dispuesto a absorber cualquier producto, si no que saben lo que
quieren, cundo lo quieren, bajo qu condiciones y cunto estn dispuestos a pagar por
ello. Otro aspecto importante es la naturaleza del cambio, que se ha convertido en algo
general y permanente. Este cambio continuo ha reducido el ciclo de vida de los producESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

106

MIGUEL REBOLLO PEDRUELO

498/00

tos, as como el tiempo disponible para disear e introducir otros nuevos [KOTLER, 95]
[SERRANO, 94].
El problema actual es que muchas empresas parecen estar en decadencia. Los motivos a los que se achaca son muy diversos. Unos piensan que se debe a factores externos,
sobre los que no se tiene control. Otros, a que no se da con el producto adecuado. Hay
quienes deciden plantear nuevas estrategias corporativas para salir de la crisis, como
cambios de mercado, pasarse a otro negocio o incluso manipular los activos. Tambin
estn los que lo atribuyen a deficiencias en la administracin y piensan que la solucin es
hacer cambios en la gestin de la empresa, variando su estructura departamental o el estilo de direccin. Muchos ven en la automatizacin el remedio a sus problemas.
Para determinar qu ocurre realmente y cmo solucionar estos problemas hay que fijarse en las empresas que tienen xito: son las que hacen mejor su trabajo. Lo que se
debe mejorar es, entonces, la forma en la que se realizan las distintas tareas que se llevan
a cabo en la empresa.

2. REINGENIERA DE LA EMPRESA
2.1. Concepto de reingeniera
La reingeniera propone obtener una visin de la empresa a partir de sus procesos.
Es la revisin fundamental y el rediseo radical de procesos para alcanzar mejoras es pectaculares en medidas crticas y contemporneas de rendimiento, tales como costes,
calidad, servicio o rapidez [HAMMER, 94], [P REZ, 96]. Esta definicin se basa en el
concepto de proceso. Un proceso es un conjunto de actividades que recibe una o ms entradas y crea un producto de valor para el cliente [FERNANDEZ, 96], [KUBECK, 95] [OULD,
94]. Esta definicin es muy til sobre todo a la hora de redisear los procesos: todo aquello que no aporte algo de valor al producto, o al menos no sea considerado como algo
imprescindible, no debera formar parte del proceso rediseado. Esto conlleva implcitamente una reduccin en las tareas de control. Otra implicacin de la visin de la empresa
a travs de sus procesos es la abolicin de la divisin de stos en tareas ms sencillas
(ALAN SMITH, 1776), que tiende a perder de vista el objetivo global. Las empresas rediseadas suelen necesitar GENERALISTAS, no ESPECIALISTAS.
La reingeniera consiste en empezar de cero, abandonando reglas anticuadas y supuestos fundamentales heredados. Este sistema para reformar la empresa tiene una serie
de caractersticas comunes aadidas: ambicin (no busca mejoras pequeas), quebrantamiento de reglas y uso creativo de la informtica.
Dentro de esta revolucin de las empresas, la Informtica tiene un papel fundamental
[WILEY, 94], [HAMMER, 94]. En primer lugar, no se debe confundir los cambios tecnolESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

499/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

107

gicos con la automatizacin. Usar nuevas tecnologas debe suponer un cambio en la forma de trabajar y en los mtodos empleados. La introduccin de las tecnologas de la informacin ha favorecido la ruptura de una serie de reglas que hasta hace algunos aos se
consideraban inamovibles:

La informacin slo puede estar en un sitio. Ahora, Las bases de datos distribuidas permiten disponer de la informacin all donde es necesaria, sin duplicidad en los datos, manteniendo la informacin dispersa en diversas localizaciones.

Slo los expertos hacen el trabajo complejo. Los sistemas expertos, como
aplicacin de las tcnicas ms novedosas de la Inteligencia Artificial, permiten a
los usuarios consultar a los ordenadores como si de expertos en materias concretas se tratara.

Escoger entre centralizar y descentralizar. La proliferacin de las redes de telecomunicaciones y el gran desarrollo de Internet permite mantener centralizado
slo lo imprescindible y repartir localmente la informacin necesaria, sin perder
las ventajas de cada uno de estos mtodos.

Slo los gerentes toman decisiones. El desarrollo de los sistemas de ayuda a la

toma de decisiones (DSS Decision Support System) permite a los usuarios
consultar grandes bancos de datos con los que basar las decisiones que afectan directamente a su trabajo.

Todo esto conlleva una serie de implicaciones que se deben traducir en un cambio en
el comportamiento y la filosofa de una empresa. Estas implicaciones pueden resumirse
en una: las compaas deben ser flexibles y rpidas en sus reacciones, tal y como exigen
los clientes, la competencia y el mismo proceso de cambio.
2.2. Ingredientes para un proceso de reingeniera formal
Un proceso formal de reingeniera incluye [JACOBSON, 94]:

una descripcin que especifique todas las actividades involucradas y se adapte al

proyecto de reingeniera;

modelos del negocio, centrados en la arquitectura y dinmica de la empresa. Han

de ser diferentes a los modelos tradicionales, que fallan porque modelan la empresa como si fuera un ordenador con una base de datos y un programa que la
manipula;

un proceso para el desarrollo de un sistema de informacin que est realmente integrado en la empresa rediseada. Un sistema as debe construirse en paralelo con
los nuevos procesos de los negocios.

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

108

MIGUEL REBOLLO PEDRUELO

500/00

Los procesos son rediseados por un equipo de reingeniera, habitualmente compuesto por gente que procede de distintos mbitos de la empresa. Para que este equipo pueda
realizar su trabajo adecuadamente necesita:

un proceso formal para redisear la empresa;

herramientas para visualizar, explicar, comprobar y evaluar sus ideas, soluciones,

decisiones y acciones;

modelos expresivos para la compaa rediseada, que tambin son utilizados por
el personal que construye los sistemas de informacin.

Este ltimo punto es especialmente importante, pues la Informtica tiene un gran

peso en el xito de los nuevos procesos. Por eso, es importante que los modelos sean lo
suficientemente expresivos y flexibles como para representar cualquier situacin del
mundo real, pero tambin deben ser formales y sin ambigedades, de forma que no necesiten transformaciones ni interpretaciones para desarrollar el sistema de informacin que
les d soporte.
La tcnica que se propone en el presente artculo est basada en las siguientes ideas
fundamentales:

Casos de uso (1). Constituyen una forma natural de identificar los procesos de la
empresa. Los usuarios de la empresa hacen uso de sta a travs de procesos. Cada
va para utilizar la empresa es un caso de uso.

La metodologa orientada a objetos (OO), que se expondr en el siguiente apartado, es excelente para clasificar el trabajo interno de una empresa sus procesos,
productos, servicios, recursos, y cmo estos elementos dependen los unos
de los otros.

El modelo de una empresa rediseada se construye mediante la unin de la reingeniera de la empresa y una metodologa de anlisis y diseo orientado a objetos.

3. ANLISIS ORIENTADO A OBJETOS

El paradigma orientado a objetos surge en los aos 80 como un nuevo enfoque para
el desarrollo de software. Sustituye a modelos anteriores, ya desfasados, que consideran
la resolucin de problemas mediante el modelo clsico de entrada proceso sali da o modelos basados en estructuras jerrquicas de informacin [PRESSMAN, 93].
Los objetos se emplean para representar una gran variedad de elementos del sistema:
(1) Use cases en el ingls original.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

501/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

109

entidades externas, ajenas al sistema pero que interactan con l;

elementos fsicos que forman parte del dominio del problema;

sucesos: operaciones que tienen lugar;

papeles o roles que desempean las personas que interactan con el sistema;

unidades organizativas: estructuras que aglutinan los objetos en entidades de nivel superior;

lugares: establecen el contexto del problema y el funcionamiento general del sistema.

El trmino orientado a objetos se aplica a multitud de campos: sistemas gestores

de bases de datos, lenguajes de programacin, metodologas de anlisis y diseo Un
objeto es una entidad dinmica cuyo estado interno evoluciona a lo largo de su historia
como consecuencia de la ocurrencia de eventos. Es el elemento que ms se aproxima a
cualquier entidad del mundo real, por lo que resulta un mecanismo muy intuitivo. Se
basa en dos conceptos: la ocultacin de informacin y los tipos abstractos de datos
(TADs). El primero consiste en hacer inaccesibles algunas partes, ocultndolas a los
usuarios, que slo pueden acceder al estado interno del objeto a travs de una interfaz
concreta. Como un TAD, un objeto encapsula datos y operaciones. Los datos representan
el estado de los objetos en un momento dado y las operaciones actan sobre los datos
para modificarlos [PASTOR, 93].
Un sistema construido con un mtodo orientado a objetos se caracteriza porque sus
componentes [PASTOR, 96]:

son paquetes que encapsulan esttica (datos) y dinmica (funciones);

pueden heredar atributos y comportamiento de otras componentes;

se comunican a travs de mensajes.

3.1. Conceptos fundamentales

La entidad de ms alto nivel es la clase. Una clase agrupa los objetos con un comportamiento similar, definiendo la estructura y el comportamiento comn de todos los objetos que forman parte de ella. Puede verse como un esquema o un patrn de todos los objetos de la clase.
Cada uno de los objetos se considera una instancia de esa clase. Surge la necesidad
de distinguir las instancias de una misma clase, por lo que se recurre a la identificacin
de los objetos a travs de una serie de variables, denominadas atributos, que describen su
estado. Debe haber al menos una variable especial a travs de la cual se pueda identificar
de forma inequvoca a cada objeto. A esta variable se le denomina identificador. Los
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

110

MIGUEL REBOLLO PEDRUELO

502/00

atributos pueden permanecer constantes o ir modificando su valor a lo largo de la vida

del objeto.
El comportamiento de un objeto se representa a travs de las acciones que requiere
a otros objetos y de las que l mismo ofrece a los dems. Las operaciones propias de
un objeto se denominan mtodos. Los objetos se comunican entre s mediante mensa jes (operaciones indicadas en la especificacin), que provocan la ejecucin de dichos
mtodos.
3.2. Qu es UML
UML (Unified Modeling Language Lenguaje de Modelado Unificado) es un
lenguaje para la especificacin, creacin y documentacin de sistemas informticos, aunque puede utilizarse tambin para modelar cualquier tipo de sistemas, entre los que se
encuentran las empresas [BOOCH, 97], [JACOBSON, 97], [RUMBAUGH, 97]. Proporciona
una serie de conceptos de ingeniera tiles para el modelado de sistemas grandes y complejos. Adems del lenguaje, junto con UML se propone una metodologa de anlisis y
diseo orientado a objetos.
La primera propuesta data de Septiembre de 1997. Fusiona los conceptos propuestos
en las metodologas de BOOCH [BOOCH, 91], OMT [RUMBAUGH, 91] y OOSE [JACOBSON,
92]. Es un lenguaje (y una metodologa) que debe aplicarse en un contexto de procesos y
ese es, precisamente, el entorno necesario para aplicar la reingeniera de la empresa. El
resultado es un proceso de desarrollo dirigido por casos de uso, con una arquitectura centralizada (aunque no excluye la posibilidad de modelar sistemas distribuidos), iterativo e
incremental.
UML es una arquitectura jerarquizada por niveles y organizada en paquetes. Dentro de cada paquete, los elementos del modelo se definen en trminos de una sintaxis
abstracta (diagrama de clases), reglas bien formadas (restricciones sobre el modelo) y
una semntica. Incorpora todos los conceptos asumidos por la comunidad orientada a
objetos.
3.3. Elementos bsicos de UML
UML utiliza una representacin grfica para modelar los sistemas. Cada diagrama
tiene asociado un nombre, una notacin y una semntica que proporciona un formalismo
adecuado. Los diagramas que forman el modelo de un sistema genrico son los que se
describen a continuacin.
3.3.1. Diagrama de casos de uso
Delimita el sistema a construir y define su funcionalidad. Utiliza dos elementos: los
actores y los casos de uso.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

503/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

111

Un caso de uso es una entidad funcional que representa un proceso en el modelo, visto como la secuencia de mensajes que intercambian el sistema y las entidades que interactan con l (actores), junto con las acciones que realiza el sistema como respuesta a
los estmulos externos. Un actor representa el papel que desempea un elemento externo
al sistema.
Venta por telfono

Comprobar estado
vendedor
Realizar pedido
cliente
Despachar pedido
dependiente
Proporcionar
crdito
supervisor

3.3.2. Diagrama de clases

Muestra la estructura esttica del modelo, compuesto por todo aquello que puede
existir en el mundo real (y es de relevancia para el sistema), su estructura interna y sus
relaciones. Especifica las clases que forman el sistema, unidas por relaciones de dos tipos: asociacin y generalizacin. Dentro de cada clase, se indica su estructura (atributos)
y su comportamiento (mtodos).

CLIENTE
Nif: String
Nombre: String
Cuenta corriente: Integer
Realizar Compra ()
Solicitar Crdito (importe: Integer)
Pedir Informacin (tema:String)

Una clase se representa como un rectngulo dividido entres partes. En la primera de ellas
se indica el nombre de la clase, en la segunda sus atributos (indicando su nombre y el tipo de
datos que almacena) y en la tercera los mtodos (su nombre y los argumentos que necesita).
Las clases pueden relacionarse entre s mediante generalizacin o mediante asociacin. La generalizacin permite realizar una clasificacin taxonmica entre clases ms
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

112

MIGUEL REBOLLO PEDRUELO

504/00

generales y otras ms especficas, consistentes con las primeras y que aaden ms informacin. A la clase general se le denomina superclase y a la especfica subclase. Se representa mediante una flecha que parte de la subclase y termina en la superclase. La aso ciacin es la relacin ms frecuente. Se utiliza para representar cualquier otro tipo de relacin existente entre las clases (es-parte-de, es-un, ). Se representa con una lnea que
une las dos clases relacionadas. A estas lneas se le pueden aadir distintos smbolos que
indican sus propiedades y caractersticas.
3.3.3. Diagrama de secuencia
Muestra cmo interactan entre s los objetos definidos en el modelo, as como los
mensajes que intercambian. Normalmente, cada caso de uso tiene asociado un diagrama
de secuencia que especifica cmo se desarrolla el proceso a lo largo del tiempo.
emisor

centralita

receptor

descolgar
dar tono
marcar n.

encaminar
dar tono

sonar
descolgar

parar tonos

parar timbre

Un diagrama de secuencia tiene dos dimensiones: la vertical representa el tiempo (en

direccin descendente) y la horizontal los distintos objetos que intervienen. Cada objeto
tiene asociado un eje vertical y los mensajes se representan como flechas que van de un
eje a otro.
3.3.4. Diagrama de colaboracin
Muestra cmo colaboran los objetos del sistema entre s, pero sin considerar el tiempo de forma explcita. Los elementos que lo componen son clases y los mensajes que se
envan entre ellas. Con l se determina el comportamiento global de un proceso, as
como los elementos que cooperan para realizar una determinada accin. Suele haber uno
para cada caso de uso.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

505/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

113

Ntese que tanto el diagrama de secuencia como el de colaboracin expresan informacin similar. Por eso, normalmente, es suficiente construir slo uno de ellos para modelar el sistema. Los diagramas de secuencia muestran de forma explcita el flujo de
mensajes en el sistema, siendo ms adecuados para modelos de tiempo real o escenarios
complejos. Los diagramas de colaboracin muestran relaciones entre los objetos y son
mejores para comprender todos lo efectos que produce un objeto.
3.3.5. Diagrama de transicin de estados
Expresa la secuencia de estados en los que se puede encontrar un objeto durante su
vida en el sistema, desde que se crea hasta que se destruye. Un objeto cambia de estado
como respuesta a un cierto mensaje. Adems, en funcin de su estado actual, el objeto
responder a un tipo de mensaje o a otro. Se representa mediante una mquina de esta dos [HOPCROF, 79], donde los smbolos de estado representan los posibles estados del objeto y las flechas corresponden a las transiciones entre estados.
activo

invlido
15 seg.
marcar
dgito

15 seg.
levantar
auricular

tono de
preparado

marcar dgito

marcando
terminar
marcar
conectando

ocioso
tono de
ocupado

colgar auricular

hablan-

ocupado

receptor
contesta

conectado

sonando

3.3.6. Diagrama de actividad

Es una variacin de la mquina de estados, en la que cada estado es una actividad
que representa la ejecucin de una operacin y las transiciones se disparan por su terminacin. Representa un proceso completo o una parte de l, asocindose a un caso de uso,
a una clase o a un mtodo de una clase. Su propsito es centrar la atencin en el flujo de
control de un proceso interno del modelo.
Los elementos de un diagrama de actividad son:
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

114

MIGUEL REBOLLO PEDRUELO

506/00

acciones: representan el estado asociado a una operacin interna;

decisiones: expresan una bifurcacin como consecuencia de la evaluacin de una

condicin;

mensajes: indican el envo o la recepcin de un mensaje.

Marcar n.
[coste < 50$]

Calcular coste
enviar

[coste 50$]
recibir

4. REINGENIERA DE LA EMPRESA CON UML

El equipo de reingeniera necesita modelos de los procesos de la empresa, centrando
la atencin en aquellos elementos y relaciones que resulten significativos. UML es un
lenguaje y una metodologa adecuada para modelar el funcionamiento actual de la empresa, pues permite detectar posibles errores de concepto y mejoras eventuales de los
procesos, y tambin para disear los procesos nuevos.
La metodologa a seguir con UML favorece un ciclo de vida en espiral para el modelado, en contraposicin con los ciclos de vida secuenciales clsicos (en los que las tareas
de especificacin, anlisis, diseo, implementacin y mantenimiento se realizan en estricto orden) [PRESSMAN, 93]. El ciclo de vida en espiral es un proceso que construye el
sistema final de forma incremental, partiendo de las especificaciones iniciales y generando prototipos cada vez ms refinados y completos, que valida el usuario.
El primer paso consiste en obtener los requerimientos de los procesos rediseados,
que normalmente se le suministran al equipo de reingeniera (o genera l mismo) en forma de enunciado. A continuacin se realiza el anlisis y diseo de estos procesos partiendo de cero. En esta fase, el equipo construye todos los diagramas propuestos en
UML, con los que el proceso queda completamente especificado.
1. Se comienza con el diagrama de casos de uso, que limita el modelo a construir
identificando elementos internos y externos a la empresa, as como los procesos
fundamentales que realiza.
2. Despus se construye el diagrama de clases, que contiene todos los objetos relevantes que intervienen en los procesos rediseados.
3. Dependiendo de las caractersticas de los procesos, se debe escoger entre utilizar
un diagrama de secuencia o uno de colaboracin para cada caso de uso. En
cualquier caso, deben figurar al menos una vez cada una de las clases definidas en
el diagrama anterior. Si alguna no interviene, debe eliminarse del modelo. AsiESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

507/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

115

mismo, todos los mensajes tienen que estar definidos como mtodos de las clases
que les dan soporte.
4. Un diagrama de transicin de estados por cada clase, aunque en ocasiones puede utilizarse para una jerarqua de generalizacin completa. Muestra tambin los
mensajes que provocan los cambios de estado, definidos en el diagrama de clases.
5. El ltimo es el diagrama de actividad, que muestra con detalle la secuencia de
acciones que se debe seguir para ejecutar un proceso o un mtodo de una clase y
los puntos de sincronismo con las dems tareas (envo/recepcin de mensajes).
Todos estos diagramas constituyen un modelo de la empresa rediseada. Si es necesario, se puede incluso construir un prototipo de sistema de informacin que proporcione
un soporte informtico bsico al modelo inicial. Este modelo es el primer resultado del
equipo de reingeniera, pero no necesariamente el definitivo. Los diagramas se deben revisar, refinndolos ms o corrigiendo y modificando algn componente. El modelo revisado constituye un segundo prototipo de la empresa. Este proceso continua hasta que se
considere que el modelo refleja exactamente la empresa rediseada.

5. EJEMPLO DE APLICACIN
ARIMEZ S.A. es una empresa constructora cuya actividad se centra principalmente
en realizar grandes obras para el sector pblico. Una entidad saca a concurso pblico la
adjudicacin de una obra, publicndolo en el B.O.E. y en el de la provincia, as como en
dos peridicos de tirada nacional. ARIMEZ acude a la administracin correspondiente
para obtener una copia del proyecto para su evaluacin. La oficina tcnica, con el apoyo
del departamento de administracin, lo estudia y confecciona una propuesta, especificando (si procede) una baja en el importe del presupuesto o en tiempo de ejecucin sobre el
proyecto inicial. Esta propuesta se enva en la entidad.
Cuando finaliza el plazo de presentacin de ofertas, la entidad resuelve el concurso
pblico y adjudica la obra a una empresa determinada. En el plazo de 7 das se firma el
contrato, asumiendo la cuanta y duracin especificadas en la propuesta y fijando un calendario para la ejecucin de la obra.
Peridicamente, la entidad supervisa el estado de la obra, realizando una serie de mediciones sobre el volumen de trabajo realizado. Con los resultados de estas mediciones,
se elabora una valoracin y la entidad emite una certificacin y abona a ARIMEZ la cantidad correspondiente. Cuando ARIMEZ concluye la obra, la entidad emite una ltima
certificacin y, en el caso de que se haya ejecutado un volumen distinto al presupuestado, realiza una liquidacin por la diferencia, tras la cual el proyecto se da por concluido.
En ese momento, comienza un periodo de garanta, pasado el cual se archiva el proyecto.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

116

MIGUEL REBOLLO PEDRUELO

508/00

5.1. Diagrama de casos de uso

Las tareas principales en las que se ve involucrada ARIMEZ pueden resumirse en tres
procesos fundamentales: la confeccin de propuestas para proyectos, la adjudicacin o
rechazo de las propuestas en concurso pblico y la certificacin de los trabajos realizados
a medida que avanza la obra. Cada uno de estos procesos se modela como un caso de uso.

Confeccionar
propuesta

Entidad

Oficina tcnica

Adjudicar

Certificar

Dpto.
Administracin

Los actores, elementos activos de estos procesos, son: la entidad pblica (externo) y
la oficina tcnica y el departamento de administracin (internos).
5.2. Diagrama de clases
El diagrama de clases muestra todos los objetos, activos o pasivos, que intervienen
en los procesos de ARIMEZ (2). Las clases principales del modelo aparecen agrupadas
en una jerarqua de generalizaciones que tiene el proyecto como superclase. La propuesta es una subclase del proyecto, al que se le aade la baja que oferta la empresa (frecuentemente, expresada en porcentaje). Las propuestas, tras la resolucin del concurso, se
clasifican en acaptadas o rechazadas. Esta clasificacin de las propuestas aparece en el
diagrama como una nueva generalizacin. Tras la firma del contrato, la propuesta adjudicada recibe ms informacin (como la fecha de inicio y la de finalizacin), pasando a ser
una obra en ejecucin. Cuando termina, se le aaden los datos reales de ejecucin y se
archiva. Una obra archivada es a su vez una subclase de la obra en ejecucin.
Los documentos que se generan en el proceso tambin se modelan como clases.
En el caso de ARIMEZ, los nicos documentos que se especifican son las certificaciones y la liquidacin final. Deben asociarse a la clase que los genera (la entidad) y a la
(2) Por motivos de espacio y de complejidad del diagrama, slo aparece el nombre de las
clases y las relaciones que existen entre ellas. Para que el diagrama sea completo, se debe indicar,
para cada clase, todos sus atributos y todos sus mtodos.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

509/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

117

proyecto
1..n.

1..n.
estudia

1..n.

1..n.

elabora

1..n.

elabora

propone
propuesta

evala

1
1 oficina tcnica

1
1

1
rechazada

entidad
1
1

adjudicada

emite

dpto. administracin
cobra

1..n.
certificacin

abona
1..n. 1

1..n.
ejecucin
1

realiza
liquida
1..n.
liquidacin

archivada

clase que los recibe (una obra en ejecucin). Se unen a travs de asociaciones, que se etiquetan con un nombre y una cardinalidad (el nmero de instancias con las que se relaciona).As, una entidad emite una o varias certificaciones (marcado como 1..n), y cada
certificacin slo es emitida por una entidad (marcada como 1).
Por ltimo, deben aparecer los actores del diagrama de casos de uso (3), relacionados
mediante asociaciones con las clases sobre las que interactan directamente.
5.3. Diagrama de secuencia
Cada proceso de ARIMEZ debe tener un diagrama de secuencia o de colaboracin
asociado. La figura muestra el diagrama de secuencia asociado al proceso de certificacin de la obra (ver enunciado). Los menajes muestran el flujo de informacin a lo largo
de este proceso.
En el modelo inicial, la certificacin est unida a la finalizacin de la obra. En un futuro refinamiento, se puede considerar la posibilidad de separar este proceso en dos, uno
dedicado exclusivamente a la certificacin y otro que modela las acciones que se realizan
al finalizar la obra (ltima certificacin, liquidacin y periodo de garanta).
(3) Algunos actores pueden corresponder a entidades externas sobre las que no se desea almacenar ningn tipo de informacin. En ese caso, no aparecen en el diagrama de clases.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

118

MIGUEL REBOLLO PEDRUELO

dpto. admn.

ejecucin

certificacin

510/00

entidad

archivada

supervisar

resultado
emitir
abonar
cobrar

liquidar

finalizar

5.4. Diagrama de transicin de estados

Cada clase del modelo tiene asociado un diagrama de transicin de estados, que
muestra cmo evoluciona en el sistema a lo largo de su vida. Se puede emplear un solo
diagrama para representar toda una red de generalizaciones, tal y como muestra este
caso.
proyectada

certificar

realizar propuesta
ofertada

adjudicada
adjudicar

en ejecucin
firmar

en garanta
liquidar

rechazar

finalizar
plazo

rechazada

archivada

Una obra arranca en estado proyectada y a medida que le llegan distintos eventos
(realizar propuesta, aceptar/rechazar,) va cambiando de estado. Algunas clases estn
representadas por un nico estado (como la clase adjudicada), pues un evento de cambio de estado hace que tambin cambie de clase (al firmarla, pasa a ser una obra en
ejecucin).
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

511/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

119

5.5. Diagrama de actividad

El ltimo paso antes de dar por concluido el modelo consiste en especificar con ms
detalle cada una de las tareas que se realizan en el sistema, bien desde el punto de vista
de los procesos o bien ofreciendo un mayor nivel de detalle, modelando los mtodos de
las clases.
Inicio
emitir propuesta
estudiar

rechazada
aceptada
firmar contrato

fin

El diagrama de la figura muestra la secuencia de acciones que debe realizarse en el

proceso de adjudicacin de una obra a una empresa.
Ntese que, en el caso de que se modelen procesos, los diagramas que resultan son
muy parecidos a los diagramas de secuencia, pero especificando con detalle las acciones
que se realizan entre los lanzamientos de los mensajes.

6. CONCLUSIONES
En el presente artculo se ha descrito cmo aplicar la metodologa orientada a objetos
en el entorno empresarial. El empleo de este tipo de tcnicas permite modelar sistemas
de forma sencilla, sin tener que utilizar artificios y abstracciones complejas. As, no es
necesario disponer de conocimientos informticos profundos para elaborar los diagramas
y construir un sistema de informacin acorde con la realidad de la empresa que se est
modelando. Incluso existen herramientas CASE (4) que traducen los esquemas a cdigo
directamente implementable en un ordenador, generando el software que da soporte al
sistema de informacin.
Las ventajas de emplear los objetos son claras. La ms importante es que se trata de
un modelo formal, es decir, la especificacin del sistema se describe mediante una sintaxis y una semntica formales, basadas en conceptos matemticos, que permite eliminar
ambigedades e inconsistencias en el modelo y que dan rigor y robustez a los sistemas.
Los conceptos que utiliza estn prximos al mecanismo cognitivo humano. Desde el
(4) Computer Aided Sowftare Engineering (Ingeniera del Software Asistida por Computador). Son herramientas que proporcionan un soporte automtico o semiautomtico para las fases
de anlisis y diseo de sistemas informticos, apoyado por controles de coherencia internos, anlisis de los modelos, facilidades de documentacin, etc
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

120

MIGUEL REBOLLO PEDRUELO

512/00

punto de vista del diseador, ofrecen una visin conjunta de la esttica y la dinmica del
sistema, aportando grandes ventajas sobre los mtodos centrados slo en los datos (modelo entidad-relacin [CHEN, 76]) o en los procesos (anlisis y diseo estructurado
[GANE, 81]). Los modelos que resultan son escalables, simplificando las ampliaciones
sobre el modelo, lo que favorece el ciclo de vida en espiral.
UML proporciona una metodologa que rene los conceptos asumidos por la comunidad orientada a objetos. El resultado es un lenguaje de propsito general, til para redisear los procesos de la empresa y que favorece la comunicacin entre distintos equipos
al facilitar diagramas claros, sencillos, expresivos, flexibles y formales.

7. BIBLIOGRAFA
[BOOCH, 91] BOOCH, G. Object Oriented Design with Applications, Benjamin Cummings Publishing Company (1991).
[BOOCH, 97] BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. Unified Modeling Language
Users Guide, Addison-Wesley (1997).
[CHEN, 76] CHEN, P. The Entity-Relationship Model. Towward a Unified View of
Data, ACM Transactions on Database Systems 1, 1 (Mar. 1976).
[FERNANDEZ, 96] FERNANDEZ, M. A. El Control, Fundamento de la Gestin por Proce sos, ESIC Editorial (1996).
[GANE, 81] GANE C.; S ARSON T. Anlisis Estructurado de Sistemas, Ed. Librera El
Ateneo, (1981).
[HAMMER, 94] HAMMER, M.; CHAMPY, J. Reingeniera de la empresa, Paramn
(1994).
[HOPCROF, 79] H OPCROF, J. Z.; ULLMAN, J. D. Introduction to Automata Theory. Lan guages and Computation, Addison-Wesley (1979).
[JACOBSON, 92] JACOBSON, I. Object-Oriented Software Engineering: An Use Case Dri ven Approach, Addison-Wesley (1992)
[JACOBSON, 94] JACOBSON, I. The Object Advantage, Addison-Wesley (1994)
[JACOBSON, 97] J ACOBSON I.; BOOCH, G.; R UMBAUGH, J. The Objectory Software Deve lopment Process, Addison-Wesley (1997).
[KOTLER, 94] KOTLER, P. Direccin de Marketing, Prentice-Hall (1994).
[KUBECK, 95] KUBECK, L. C. Techniques for Business Process Redesign, JOHN WILEY
& S ONS (1995).
[OULD, 94] OULD, M. A. Business Processes, John Wiley & Sons (1994).
[PASTOR, 93] P ASTOR, O.; SICOL, J. J.; HERRERO, M. Modelos Semnticos y Modelos
Orientados a Objetos, Universidad Politcnica de Valencia (1993).
[PASTOR, 96] PASTOR, O. Anlisis Orientado a Objetos. Conceptos y Metodologas,
Internal Report, Dpto. de Sistemas Informticos y Computacin, Universidad Politcnica de Valencia (1996).
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

513/00

UML. UNA METODOLOGA ORIENTADA A OBJETOS APLICADA A LA

121

[PEREZ, 96] PREZ-FERNANDEZ, J. A. Gestin por procesos. Reingeniera y mejora de

los procesos de la empresa, ESIC Editorial (1996).
[PRESSMAN, 93] PRESSMAN, R. S. Ingeniera del Software. Un enfoque prctico, M CGRAW-HILL (1993).
[RUMBAUGH, 91] R UMBAUGH, J. Object Oriented Modeling and Design, Prentice-Hall
(1991).
[RUMBAUGH, 97] R UMBAUGH, J.; BOOCH, G.; J ACOBSON, I. Unified Modeling Language
Reference Manual, Addison-Wesley (1997).
[SERRANO, 95] SERRANO, F. Temas de Introduccin al marketing, ESIC Editorial
(1995).
[TAYLOR, 95] TAYLOR, D. A. Business Engineering with Object Technology, John Wiley & Sons (1995).
[WILEY, 94] Varios autores. Software Assistance for Bussines Re-Engineering, J OHN
WILEY & SONS (1994).

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000