e PDF

UML.
Una Metodología Orientada a Objetos

aplicada a la Reingeniería de la Empresa
MIGUEL REBOLLO PEDRUELO

Departamento de Sistemas Informáticos y Computación
Universidad de Valencia
El proceso de reingeniería busca construir el modelo de una situación real, con el

fin de determinar su funcionamiento para mejorarlo posteriormente. Cuando el sistema
que se considera es el mundo empresarial, se habla de reingeniería de la empresa. Para
realizar este proceso se pueden utilizar herramientas que nacen del campo de la Infor -
mática, en concreto el análisis y diseño orientado a objetos.
En el presente artículo se muestra cómo aplicar la metodología y el lenguaje UML

al proceso de reingeniería de la empresa. Esta técnica 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 técnicas de control, etc… usando unos mecanismos formales que garantizan su co -
rrección y facilitan la construcción de sistemas de información que soporten los nuevos
procesos rediseñados.
1. INTRODUCCIÓN
Ha llegado el momento de cambiar estructura, administración y desempeño de los ne-

gocios: entramos en el siglo XXI con empresas creadas en el siglo XX con las ideas del
siglo XIX. Estos cambios están motivados, entre otras razones, por la fuerte variación que
se ha producido en los clientes, en la competencia y en el propio proceso de cambio.
Los clientes exigen productos y servicios diseñados a medida. Ya no se trata con un

mercado masivo que está dispuesto a absorber cualquier producto, si no que saben lo que
quieren, cuándo lo quieren, bajo qué condiciones y cuánto están 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 produc-
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

106 MIGUEL REBOLLO PEDRUELO 498/00
tos, así como el tiempo disponible para diseñar e introducir otros nuevos [KOTLER, 95]
[SERRANO, 94].
El problema actual es que muchas empresas parecen estar en decadencia. Los moti-
vos 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. También
están los que lo atribuyen a deficiencias en la administración y piensan que la solución es
hacer cambios en la gestión de la empresa, variando su estructura departamental o el es-
tilo de dirección. Muchos ven en la automatización el remedio a sus problemas.
Para determinar qué ocurre realmente y cómo solucionar estos problemas hay que fi-
jarse 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. REINGENIERÍA DE LA EMPRESA
2.1. Concepto de reingeniería
La reingeniería propone obtener una visión de la empresa a partir de sus procesos.

“Es la revisión fundamental y el rediseño radical de procesos para alcanzar mejoras es -
pectaculares en medidas críticas y contemporáneas de rendimiento, tales como costes,
calidad, servicio o rapidez” [HAMMER, 94], [P ÉREZ, 96]. Esta definición se basa en el
concepto de proceso. Un proceso es un conjunto de actividades que recibe una o más en-
tradas y crea un producto de valor para el cliente [FERNANDEZ, 96], [KUBECK, 95] [OULD,
94]. Esta definición es muy útil sobre todo a la hora de rediseñar los procesos: todo aque-
llo que no aporte algo de valor al producto, o al menos no sea considerado como algo
imprescindible, no debería formar parte del proceso rediseñado. Esto conlleva implícita-
mente una reducción en las tareas de control. Otra implicación de la visión de la empresa
a través de sus procesos es la abolición de la división de éstos en tareas más sencillas
(ALAN SMITH, 1776), que tiende a perder de vista el objetivo global. Las empresas redi-
señadas suelen necesitar GENERALISTAS, no ESPECIALISTAS.
La reingeniería consiste en empezar de cero, abandonando reglas anticuadas y su-

puestos fundamentales heredados. Este sistema para reformar la empresa tiene una serie
de características comunes añadidas: ambición (no busca mejoras pequeñas), quebranta-
miento de reglas y uso creativo de la informática.
Dentro de esta revolución de las empresas, la Informática tiene un papel fundamental

[WILEY, 94], [HAMMER, 94]. En primer lugar, no se debe confundir los cambios tecnoló-

499/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 107
gicos con la automatización. Usar nuevas tecnologías debe suponer un cambio en la for-
ma de trabajar y en los métodos empleados. La introducción de las tecnologías de la in-
formación ha favorecido la ruptura de una serie de reglas que hasta hace algunos años se
consideraban inamovibles:
• “La información sólo puede estar en un sitio”. Ahora, Las bases de datos dis-
tribuidas permiten disponer de la información allá donde es necesaria, sin du-
plicidad en los datos, manteniendo la información dispersa en diversas localiza-
ciones.
• “Sólo los expertos hacen el trabajo complejo”. Los sistemas expertos, como
aplicación de las técnicas más novedosas de la Inteligencia Artificial, permiten a
los usuarios consultar a los ordenadores como si de expertos en materias concre-
tas se tratara.
• “Escoger entre centralizar y descentralizar”. La proliferación de las redes de te-

lecomunicaciones y el gran desarrollo de Internet permite mantener centralizado
sólo lo imprescindible y repartir localmente la información necesaria, sin perder
las ventajas de cada uno de estos métodos.
• “Sólo 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 di-
rectamente a su trabajo.
Todo esto conlleva una serie de implicaciones que se deben traducir en un cambio en
el comportamiento y la filosofía de una empresa. Estas implicaciones pueden resumirse
en una: las compañías deben ser flexibles y rápidas en sus reacciones, tal y como exigen
los clientes, la competencia y el mismo proceso de cambio.
2.2. Ingredientes para un proceso de reingeniería formal
Un proceso formal de reingeniería incluye [JACOBSON, 94]:
• una descripción que especifique todas las actividades involucradas y se adapte al

proyecto de reingeniería;
• modelos del negocio, centrados en la arquitectura y dinámica de la empresa. Han

de ser diferentes a los modelos tradicionales, que fallan porque modelan la em-
presa 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 información que esté realmente in-

tegrado en la empresa rediseñada. Un sistema así debe construirse en paralelo con
los nuevos procesos de los negocios.

Los procesos son rediseñados por un equipo de reingeniería, habitualmente compues-

to por gente que procede de distintos ámbitos de la empresa. Para que este equipo pueda
realizar su trabajo adecuadamente necesita:
• un proceso formal para rediseñar la empresa;
• herramientas para visualizar, explicar, comprobar y evaluar sus ideas, soluciones,

decisiones y acciones;
• modelos expresivos para la compañía rediseñada, que también son utilizados por
el personal que construye los sistemas de información.
Este último punto es especialmente importante, pues la Informática 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 situación del
mundo real, pero también deben ser formales y sin ambigüedades, de forma que no nece-
siten transformaciones ni interpretaciones para desarrollar el sistema de información que
les dé soporte.
La técnica que se propone en el presente artículo 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 través de procesos. Cada
vía para “utilizar” la empresa es un caso de uso.
• La metodología orientada a objetos (OO), que se expondrá en el siguiente aparta-

do, es excelente para clasificar el trabajo interno de una empresa —sus procesos,
productos, servicios, recursos, …— y cómo estos elementos dependen los unos
de los otros.
• El modelo de una empresa rediseñada se construye mediante la unión de la rein-

geniería de la empresa y una metodología de análisis y diseño orientado a objetos.
3. ANÁLISIS ORIENTADO A OBJETOS
El paradigma orientado a objetos surge en los años 80 como un nuevo enfoque para
el desarrollo de software. Sustituye a modelos anteriores, ya desfasados, que consideran
la resolución de problemas mediante el modelo clásico de entrada → proceso → sali -
da o modelos basados en estructuras jerárquicas de información [PRESSMAN, 93].
Los objetos se emplean para representar una gran variedad de elementos del sistema:
(1) Use cases” en el inglés original.

• entidades externas, ajenas al sistema pero que interactúan con él;
• elementos físicos que forman parte del dominio del problema;
• sucesos: operaciones que tienen lugar;
• papeles o roles que desempeñan las personas que interactúan con el sistema;
• unidades organizativas: estructuras que aglutinan los objetos en entidades de ni-

vel superior;
• lugares: establecen el contexto del problema y el funcionamiento general del sis-

tema.
El término “orientado a objetos” se aplica a multitud de campos: sistemas gestores

de bases de datos, lenguajes de programación, metodologías de análisis y diseño… Un
objeto es una entidad dinámica cuyo estado interno evoluciona a lo largo de su historia
como consecuencia de la ocurrencia de eventos. Es el elemento que más se aproxima a
cualquier entidad del mundo real, por lo que resulta un mecanismo muy intuitivo. Se
basa en dos conceptos: la ocultación de información y los tipos abstractos de datos
(TAD’s). El primero consiste en hacer inaccesibles algunas partes, ocultándolas a los
usuarios, que sólo pueden acceder al estado interno del objeto a través 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 actúan sobre los datos
para modificarlos [PASTOR, 93].
Un sistema construido con un método orientado a objetos se caracteriza porque sus

componentes [PASTOR, 96]:
• son “paquetes” que encapsulan estática (datos) y dinámica (funciones);
• pueden heredar atributos y comportamiento de otras componentes;
• se comunican a través de mensajes.
3.1. Conceptos fundamentales
La entidad de más alto nivel es la clase. Una clase agrupa los objetos con un compor-
tamiento similar, definiendo la estructura y el comportamiento común de todos los obje-
tos que forman parte de ella. Puede verse como un esquema o un patrón de todos los ob-
jetos 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 identificación
de los objetos a través de una serie de variables, denominadas atributos, que describen su
estado. Debe haber al menos una variable especial a través de la cual se pueda identificar
de forma inequívoca a cada objeto. A esta variable se le denomina identificador. Los

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 través de las acciones que requiere

a otros objetos y de las que él mismo ofrece a los demás. Las operaciones propias de
un objeto se denominan métodos. Los objetos se comunican entre sí mediante mensa -
jes (operaciones indicadas en la especificación), que provocan la ejecución de dichos
métodos.
3.2. Qué es UML
UML (Unified Modeling Language —Lenguaje de Modelado Unificado—) es un

lenguaje para la especificación, creación y documentación de sistemas informáticos, aun-
que puede utilizarse también 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 ingeniería útiles para el modelado de sistemas grandes y com-
plejos. Además del lenguaje, junto con UML se propone una metodología de análisis y
diseño orientado a objetos.
La primera propuesta data de Septiembre de 1997. Fusiona los conceptos propuestos

en las metodologías de BOOCH [BOOCH, 91], OMT [RUMBAUGH, 91] y OOSE [JACOBSON,
92]. Es un lenguaje (y una metodología) que debe aplicarse en un contexto de procesos y
ese es, precisamente, el entorno necesario para aplicar la reingeniería de la empresa. El
resultado es un proceso de desarrollo dirigido por casos de uso, con una arquitectura cen-
tralizada (aunque no excluye la posibilidad de modelar sistemas distribuidos), iterativo e
incremental.
UML es una arquitectura jerarquizada por niveles y organizada en paquetes. Den-

tro de cada paquete, los elementos del modelo se definen en términos de una sintaxis
abstracta (diagrama de clases), reglas bien formadas (restricciones sobre el modelo) y
una semántica. Incorpora todos los conceptos asumidos por la comunidad orientada a
objetos.
3.3. Elementos básicos de UML
UML utiliza una representación gráfica para modelar los sistemas. Cada diagrama
tiene asociado un nombre, una notación y una semántica que proporciona un formalismo
adecuado. Los diagramas que forman el modelo de un sistema genérico son los que se
describen a continuación.
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.

Un caso de uso es una entidad funcional que representa un proceso en el modelo, vis-
to como la secuencia de mensajes que intercambian el sistema y las entidades que inte-
ractúan con él (actores), junto con las acciones que realiza el sistema como respuesta a
los estímulos externos. Un actor representa el papel que desempeña un elemento externo
al sistema.
Venta por teléfono
Comprobar estado
vendedor
Realizar pedido
cliente
Despachar pedido
dependiente
Proporcionar
crédito
supervisor
3.3.2. Diagrama de clases
Muestra la estructura estática 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 ti-
pos: asociación y generalización. Dentro de cada clase, se indica su estructura (atributos)
y su comportamiento (métodos).
CLIENTE
Nif: String
Nombre: String
Cuenta corriente: Integer
Realizar Compra ()
Solicitar Crédito (importe: Integer)
Pedir Información (tema:String)
Una clase se representa como un rectángulo 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 métodos (su nombre y los argumentos que necesita).
Las clases pueden relacionarse entre sí mediante generalización o mediante asocia-

ción. La generalización permite realizar una clasificación taxonómica entre clases más

generales y otras más específicas, consistentes con las primeras y que añaden más infor-
mación. A la clase general se le denomina superclase y a la específica subclase. Se re-
presenta mediante una flecha que parte de la subclase y termina en la superclase. La aso -
ciación es la relación más frecuente. Se utiliza para representar cualquier otro tipo de re-
lación existente entre las clases (es-parte-de, es-un,… ). Se representa con una línea que
une las dos clases relacionadas. A estas líneas se le pueden añadir distintos símbolos que
indican sus propiedades y características.
3.3.3. Diagrama de secuencia
Muestra cómo interactúan 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 cómo 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

dirección 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 colaboración
Muestra cómo colaboran los objetos del sistema entre sí, pero sin considerar el tiem-
po de forma explícita. Los elementos que lo componen son clases y los mensajes que se
envían entre ellas. Con él se determina el comportamiento global de un proceso, así
como los elementos que cooperan para realizar una determinada acción. Suele haber uno
para cada caso de uso.

Nótese que tanto el diagrama de secuencia como el de colaboración expresan infor-

mación similar. Por eso, normalmente, es suficiente construir sólo uno de ellos para mo-
delar el sistema. Los diagramas de secuencia muestran de forma explícita el flujo de
mensajes en el sistema, siendo más adecuados para modelos de tiempo real o escenarios
complejos. Los diagramas de colaboración muestran relaciones entre los objetos y son
mejores para comprender todos lo efectos que produce un objeto.
3.3.5. Diagrama de transición 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. Además, en función de su estado actual, el objeto
responderá a un tipo de mensaje o a otro. Se representa mediante una máquina de esta -
dos [HOPCROF, 79], donde los símbolos de estado representan los posibles estados del ob-
jeto y las flechas corresponden a las transiciones entre estados.
activo inválido
15 seg.
15 seg. marcar
dígito
levantar
auricular tono de marcar dígito
marcando
preparado
terminar
marcar
ocioso conectando
tono de
ocupado ocupado conectado
receptor
contesta
hablan- sonando
colgar auricular
3.3.6. Diagrama de actividad
Es una variación de la máquina de estados, en la que cada estado es una actividad

que representa la ejecución de una operación y las transiciones se disparan por su termi-
nación. Representa un proceso completo o una parte de él, asociándose a un caso de uso,
a una clase o a un método de una clase. Su propósito es centrar la atención en el flujo de
control de un proceso interno del modelo.
Los elementos de un diagrama de actividad son:

• acciones: representan el estado asociado a una operación interna;
• decisiones: expresan una bifurcación como consecuencia de la evaluación de una

condición;
• mensajes: indican el envío o la recepción de un mensaje.
Marcar n.º
[coste < 50$]

Calcular coste
[coste ≥ 50$]
enviar recibir
4. REINGENIERÍA DE LA EMPRESA CON UML
El equipo de reingeniería necesita modelos de los procesos de la empresa, centrando

la atención en aquellos elementos y relaciones que resulten significativos. UML es un
lenguaje y una metodología adecuada para modelar el funcionamiento actual de la em-
presa, pues permite detectar posibles errores de concepto y mejoras eventuales de los
procesos, y también para diseñar los procesos nuevos.
La metodología a seguir con UML favorece un ciclo de vida en espiral para el mode-
lado, en contraposición con los ciclos de vida secuenciales clásicos (en los que las tareas
de especificación, análisis, diseño, implementación y mantenimiento se realizan en es-
tricto 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 generan-
do prototipos cada vez más refinados y completos, que valida el usuario.
El primer paso consiste en obtener los requerimientos de los procesos rediseñados,

que normalmente se le suministran al equipo de reingeniería (o genera él mismo) en for-
ma de enunciado. A continuación se realiza el análisis y diseño de estos procesos par-
tiendo 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. Después se construye el diagrama de clases, que contiene todos los objetos rele-
vantes que intervienen en los procesos rediseñados.
3. Dependiendo de las características de los procesos, se debe escoger entre utilizar
un diagrama de secuencia o uno de colaboración 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. Asi-

mismo, todos los mensajes tienen que estar definidos como métodos de las clases
que les dan soporte.
4. Un diagrama de transición de estados por cada clase, aunque en ocasiones pue-

de utilizarse para una jerarquía de generalización completa. Muestra también 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 método de una clase y
los puntos de sincronismo con las demás tareas (envío/recepción de mensajes).
Todos estos diagramas constituyen un modelo de la empresa rediseñada. Si es nece-

sario, se puede incluso construir un prototipo de sistema de información que proporcione
un soporte informático básico al modelo inicial. Este modelo es el primer resultado del
equipo de reingeniería, pero no necesariamente el definitivo. Los diagramas se deben re-
visar, refinándolos más o corrigiendo y modificando algún componente. El modelo revi-
sado constituye un segundo prototipo de la empresa. Este proceso continua hasta que se
considere que el modelo refleja exactamente la empresa rediseñada.
5. EJEMPLO DE APLICACIÓN
ARIMEZ S.A. es una empresa constructora cuya actividad se centra principalmente

en realizar grandes obras para el sector público. Una entidad saca a concurso público la
adjudicación de una obra, publicándolo en el B.O.E. y en el de la provincia, así como en
dos periódicos de tirada nacional. ARIMEZ acude a la administración correspondiente
para obtener una copia del proyecto para su evaluación. La oficina técnica, con el apoyo
del departamento de administración, lo estudia y confecciona una propuesta, especifican-
do (si procede) una baja en el importe del presupuesto o en tiempo de ejecución sobre el
proyecto inicial. Esta propuesta se envía en la entidad.
Cuando finaliza el plazo de presentación de ofertas, la entidad resuelve el concurso

público y adjudica la obra a una empresa determinada. En el plazo de 7 días se firma el
contrato, asumiendo la cuantía y duración especificadas en la propuesta y fijando un ca-
lendario para la ejecución de la obra.
Periódicamente, la entidad supervisa el estado de la obra, realizando una serie de me-

diciones sobre el volumen de trabajo realizado. Con los resultados de estas mediciones,
se elabora una valoración y la entidad emite una certificación y abona a ARIMEZ la can-
tidad correspondiente. Cuando ARIMEZ concluye la obra, la entidad emite una última
certificación y, en el caso de que se haya ejecutado un volumen distinto al presupuesta-
do, realiza una liquidación por la diferencia, tras la cual el proyecto se da por concluido.
En ese momento, comienza un periodo de garantía, pasado el cual se archiva el proyecto.

5.1. Diagrama de casos de uso
Las tareas principales en las que se ve involucrada ARIMEZ pueden resumirse en tres
procesos fundamentales: la confección de propuestas para proyectos, la adjudicación o
rechazo de las propuestas en concurso público y la certificación de los trabajos realizados
a medida que avanza la obra. Cada uno de estos procesos se modela como un caso de uso.
Confeccionar
propuesta Oficina técnica
Entidad Adjudicar
Certificar Dpto.
Administración
Los actores, elementos activos de estos procesos, son: la entidad pública (externo) y
la oficina técnica y el departamento de administración (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 jerarquía de generalizaciones que tiene el proyecto como superclase. La propues-
ta es una subclase del proyecto, al que se le añade la baja que oferta la empresa (frecuen-
temente, expresada en porcentaje). Las propuestas, tras la resolución del concurso, se
clasifican en acaptadas o rechazadas. Esta clasificación de las propuestas aparece en el
diagrama como una nueva generalización. Tras la firma del contrato, la propuesta adjudi-
cada recibe más información (como la fecha de inicio y la de finalización), pasando a ser
una obra en ejecución. Cuando termina, se le añaden los datos reales de ejecución y se
archiva. Una obra archivada es a su vez una subclase de la obra en ejecución.
Los documentos que se generan en el proceso también se modelan como clases.
En el caso de ARIMEZ, los únicos documentos que se especifican son las certifica-
ciones y la liquidación final. Deben asociarse a la clase que los genera (la entidad) y a la
(2) Por motivos de espacio y de complejidad del diagrama, sólo 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 métodos.

proyecto
1..n. 1..n.
estudia
propone
1
1..n. elabora 1 oficina técnica
1..n. propuesta
evalúa 1..n. elabora
1
1 1
entidad rechazada adjudicada dpto. administración
1 1
1 emite cobra
1..n. abona 1..n.

1..n. 1
certificación ejecución
realiza 1
liquida
1..n.
liquidación 1 archivada
clase que los recibe (una obra en ejecución). Se unen a través de asociaciones, que se eti-
quetan con un nombre y una cardinalidad (el número de instancias con las que se rela-
ciona).Así, una entidad emite una o varias certificaciones (marcado como 1..n), y cada
certificación sólo 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 interactúan directamente.
5.3. Diagrama de secuencia
Cada proceso de ARIMEZ debe tener un diagrama de secuencia o de colaboración

asociado. La figura muestra el diagrama de secuencia asociado al proceso de certifica-
ción de la obra (ver enunciado). Los menajes muestran el flujo de información a lo largo
de este proceso.
En el modelo inicial, la certificación está unida a la finalización de la obra. En un fu-

turo refinamiento, se puede considerar la posibilidad de separar este proceso en dos, uno
dedicado exclusivamente a la certificación y otro que modela las acciones que se realizan
al finalizar la obra (última certificación, liquidación y periodo de garantía).
(3) Algunos actores pueden corresponder a entidades externas sobre las que no se desea al-
macenar ningún tipo de información. En ese caso, no aparecen en el diagrama de clases.

dpto. admón. ejecución certificación entidad archivada

supervisar
resultado
emitir
abonar
cobrar
liquidar finalizar
5.4. Diagrama de transición de estados
Cada clase del modelo tiene asociado un diagrama de transición de estados, que
muestra cómo 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 en ejecución en garantía

adjudicar firmar liquidar finalizar
rechazar 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 están
representadas por un único estado (como la clase adjudicada), pues un evento de cam-
bio de estado hace que también cambie de clase (al firmarla, pasa a ser una obra en
ejecución).

5.5. Diagrama de actividad
El último paso antes de dar por concluido el modelo consiste en especificar con más
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 métodos de
las clases.
Inicio
emitir propuesta rechazada
estudiar aceptada
firmar contrato fin
El diagrama de la figura muestra la secuencia de acciones que debe realizarse en el

proceso de adjudicación de una obra a una empresa.
Nótese 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 artículo se ha descrito cómo aplicar la metodología orientada a objetos

en el entorno empresarial. El empleo de este tipo de técnicas permite modelar sistemas
de forma sencilla, sin tener que utilizar artificios y abstracciones complejas. Así, no es
necesario disponer de conocimientos informáticos profundos para elaborar los diagramas
y construir un sistema de información acorde con la realidad de la empresa que se está
modelando. Incluso existen herramientas CASE (4) que traducen los esquemas a código
directamente implementable en un ordenador, generando el software que da soporte al
sistema de información.
Las ventajas de emplear los objetos son claras. La más importante es que se trata de
un modelo formal, es decir, la especificación del sistema se describe mediante una sinta-
xis y una semántica formales, basadas en conceptos matemáticos, que permite eliminar
ambigüedades e inconsistencias en el modelo y que dan rigor y robustez a los sistemas.
Los conceptos que utiliza están próximos al mecanismo cognitivo humano. Desde el
(4) Computer Aided Sowftare Engineering (Ingeniería del Software Asistida por Computa-
dor). Son herramientas que proporcionan un soporte automático o semiautomático para las fases
de análisis y diseño de sistemas informáticos, apoyado por controles de coherencia internos, aná-
lisis de los modelos, facilidades de documentación, etc…

punto de vista del diseñador, ofrecen una visión conjunta de la estática y la dinámica del
sistema, aportando grandes ventajas sobre los métodos centrados sólo en los datos (mo-
delo entidad-relación [CHEN, 76]) o en los procesos (análisis y diseño 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 metodología que reúne los conceptos asumidos por la comu-
nidad orientada a objetos. El resultado es un lenguaje de propósito general, útil para redi-
señar los procesos de la empresa y que favorece la comunicación entre distintos equipos
al facilitar diagramas claros, sencillos, expresivos, flexibles y formales.
7. BIBLIOGRAFÍA
[BOOCH, 91] BOOCH, G. “Object Oriented Design with Applications”, Benjamin Cum-
mings Publishing Company (1991).
[BOOCH, 97] BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. “Unified Modeling Language
User’s 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 Gestión por Proce -
sos”, ESIC Editorial (1996).
[GANE, 81] GANE C.; S ARSON T. “Análisis Estructurado de Sistemas”, Ed. Librería “El
Ateneo”, (1981).
[HAMMER, 94] HAMMER, M.; CHAMPY, J. “Reingeniería de la empresa”, Paramón
(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. “Dirección 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 Semánticos y Modelos
Orientados a Objetos”, Universidad Politécnica de Valencia (1993).
[PASTOR, 96] PASTOR, O. “Análisis Orientado a Objetos. Conceptos y Metodologías”,
Internal Report, Dpto. de Sistemas Informáticos y Computación, Universidad Poli-
técnica de Valencia (1996).

[PEREZ, 96] PÉREZ-FERNANDEZ, J. A. “Gestión por procesos. Reingeniería y mejora de

los procesos de la empresa”, ESIC Editorial (1996).
[PRESSMAN, 93] PRESSMAN, R. S. “Ingeniería del Software. Un enfoque práctico”, M C-
GRAW-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 Introducción al marketing”, ESIC Editorial
(1995).
[TAYLOR, 95] TAYLOR, D. A. “Business Engineering with Object Technology”, John Wi-
ley & Sons (1995).
[WILEY, 94] Varios autores. “Software Assistance for Bussines Re-Engineering”, J OHN
WILEY & SONS (1994).

e PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

e PDF

Cargado por

Copyright:

Formatos disponibles

UML.

Una Metodología Orientada a Objetos

MIGUEL REBOLLO PEDRUELO

El proceso de reingeniería busca construir el modelo de una situación real, con el

En el presente artículo se muestra cómo aplicar la metodología y el lenguaje UML

Ha llegado el momento de cambiar estructura, administración y desempeño de los ne-

Los clientes exigen productos y servicios diseñados a medida. Ya no se trata con un

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

2.1. Concepto de reingeniería

La reingeniería propone obtener una visión de la empresa a partir de sus procesos.

La reingeniería consiste en empezar de cero, abandonando reglas anticuadas y su-

Dentro de esta revolución de las empresas, la Informática tiene un papel fundamental

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

• “Escoger entre centralizar y descentralizar”. La proliferación de las redes de te-

• “Sólo los gerentes toman decisiones”. El desarrollo de los sistemas de ayuda a la

2.2. Ingredientes para un proceso de reingeniería formal

Un proceso formal de reingeniería incluye [JACOBSON, 94]:

• una descripción que especifique todas las actividades involucradas y se adapte al

• modelos del negocio, centrados en la arquitectura y dinámica de la empresa. Han

• un proceso para el desarrollo de un sistema de información que esté realmente in-

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

Los procesos son rediseñados por un equipo de reingeniería, habitualmente compues-

• un proceso formal para rediseñar la empresa;

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

Este último punto es especialmente importante, pues la Informática tiene un gran

• La metodología orientada a objetos (OO), que se expondrá en el siguiente aparta-

• El modelo de una empresa rediseñada se construye mediante la unión de la rein-

3. ANÁLISIS ORIENTADO A OBJETOS

(1) Use cases” en el inglés original.

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

• entidades externas, ajenas al sistema pero que interactúan con él;

• elementos físicos que forman parte del dominio del problema;

• sucesos: operaciones que tienen lugar;

• unidades organizativas: estructuras que aglutinan los objetos en entidades de ni-

• lugares: establecen el contexto del problema y el funcionamiento general del sis-

El término “orientado a objetos” se aplica a multitud de campos: sistemas gestores

Un sistema construido con un método orientado a objetos se caracteriza porque sus

• son “paquetes” que encapsulan estática (datos) y dinámica (funciones);

• pueden heredar atributos y comportamiento de otras componentes;

• se comunican a través de mensajes.

3.1. Conceptos fundamentales

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

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

El comportamiento de un objeto se representa a través de las acciones que requiere

3.2. Qué es UML

UML (Unified Modeling Language —Lenguaje de Modelado Unificado—) es un

La primera propuesta data de Septiembre de 1997. Fusiona los conceptos propuestos

UML es una arquitectura jerarquizada por niveles y organizada en paquetes. Den-

3.3. Elementos básicos de UML

3.3.1. Diagrama de casos de uso

Delimita el sistema a construir y define su funcionalidad. Utiliza dos elementos: los

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

Venta por teléfono

3.3.2. Diagrama de clases

Las clases pueden relacionarse entre sí mediante generalización o mediante asocia-

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000

3.3.3. Diagrama de secuencia

emisor centralita receptor

dar tono sonar

parar tonos parar timbre

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

3.3.4. Diagrama de colaboración

ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000