Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001

Modelado de aplicaciones en Internet

lvaro Rendn Galln
Grupo de Ingeniera Telemtica, Universidad del Cauca, Popayn, Colombia
arendon@unicauca.edu.co

ResumenLa rpida penetracin del uso de Internet la est

convirtiendo en el escenario en el cual se desarrollan una buena
parte de las actividades acadmicas, econmicas, de
entretenimiento y hasta polticas del hombre moderno. Ello ha
impulsado a su vez el desarrollo constante de nuevas
tecnologas que buscan extender su uso mucho ms all de la
simple navegacin y convertirla en un medio para la prestacin
de mltiples servicios a travs de aplicaciones que pueden
llegar a ser tan complejas como las clsicas aplicaciones
multinivel, lo cual requiere contar con las herramientas de
desarrollo adecuadas, entre las que son imprescindibles las
tcnicas y herramientas de modelado. En este artculo se
presentan de manera integrada, y tomando como base el
modelo de Proceso Unificado para Desarrollo de Software, un
conjunto de procedimientos y tcnicas que facilitan a los
equipos de desarrollo de aplicaciones web manejar la
complejidad de las aplicaciones y obtener productos de alta
calidad. Se hace nfasis en dos actividades de singular
importancia en el tipo de aplicaciones tratado: el Modelado de
la Organizacin, que describe la actividad que ser soportada
por la aplicacin, y el Diseo, que describe la propia aplicacin.
Los modelos son construidos usando UML y la Extensin para
Aplicaciones Web de UML.
Palabras clave-- WWW, metodologas de desarrollo, ingeniera
de software, tcnicas orientadas a objetos, UML, estereotipos.

I. INTRODUCCIN
Cuando Mosaic [1] fue creado en los laboratorios del CERN
(Centro Europeo para la Investigacin Nuclear) en 1993, es
poco probable que alguien hubiera imaginado el impacto que
este nuevo servicio de Internet, la WWW (World Wide Web)
o simplemente "la Web", tendra sobre la sociedad moderna.
Lo que simplemente empez como un mecanismo basado en
hipertexto para acceso a informacin, con mejores
prestaciones que las ofrecidas por los servicios de entonces,
el FTP (File Transfer Protocol) y el Gopher, constituye hoy
en da la aplicacin estrella ("killer application") de Internet,
contribuyendo enormemente a su popularizacin. Los
clientes de navegacin eliminaron la barrera de acceso a
Internet que imponan las aplicaciones anteriores, que
exigan un conocimiento de la red y del uso de comandos, y
pusieron esta red al alcance de todo tipo de usuarios, a travs
de una interfaz de muy fcil manejo.

con HTML, llamados pginas web, que residen en un

servidor, tal como se muestra en la Figura 1. Los usuarios
disponen de una aplicacin cliente, llamada navegador, que
utiliza el protocolo HTTP para solicitar y obtener del
servidor las pginas, e interpreta su contenido para entregar
al usuario la informacin ofrecida. Esta informacin es en
general de tipo multimedia (texto, imgenes, sonido, vdeo,
etc.), y a travs de los enlaces del hipertexto puede conducir
a otros servidores en Internet que ofrecen ms informacin.
Servidor Web

Navegador

Internet

HTTP
HTML
HTML
HTML

Figura 1. Navegacin en Internet

La rpida penetracin del uso de Internet ha llevado a su vez

a la aparicin de nuevas tecnologas que, como se ilustra en
la Figura 2, buscan extender el uso de la Web mucho ms
all de la simple navegacin a travs de documentos
multimedia. Del lado del servidor, tecnologas como CGI
(Common Gateway Interface) [4], PHP (Hypertext
Preprocessor) [5], Servlets de Java [6] y ASP (Active Server
Pages) [7] permiten acceder y procesar informacin en bases
de datos o comunicarse con aplicaciones que a su vez
pueden interactuar con otras aplicaciones eventualmente en
red, y entregar sus resultados al usuario a travs de pginas
creadas en forma dinmica.
Navegador

Servidor Web
Internet

HTTP
HTML
HTML
HTML

CGI, ASP
Servlet

JavaScripts

WAN

Dispositivos
locales

Applets
ActiveX

I IOP
DCOM

Servidor de
Aplicaciones

Base de
Datos

Figura 2. Aplicaciones en Internet

Los pilares de este nuevo servicio son el Lenguaje de

Marcado para Hiper-Texto (HTML, HiperText Markup
Language) [2] y el Protocolo de Transferencia de HiperTexto (HTTP, HiperText Transfer Protocol) [3]. La
informacin se ofrece a travs de documentos elaborados

Del lado del cliente, se han desarrollado tecnologas como

los JavaScripts, que permiten mejorar la presentacin de la
informacin al usuario y realizar validaciones y clculos
limitados, y los Applets de Java y componentes tipo ActiveX

Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
y JavaBeans, que son adems capaces de acceder a
dispositivos locales del usuario y a otras aplicaciones en la
red a travs de los protocolos IIOP (Internet Inter-ORB
Protocol) [8] y DCOM (Distributed Component Object
Model) [9].

niveles de disponibilidad pero en cambio s un nmero de

usuarios creciente, as como las presiones del mercado,
imponen a las aplicaciones en Internet caractersticas
como flexibilidad, robustez, escalabilidad, oportunidad y
economa, entre otras.

Como resultado de la disponibilidad de estas tecnologas,

tanto del lado del servidor como del cliente, la Web ya no es
slo un depsito de documentos hipertexto, sino que es
adems el medio para construir, ofrecer y acceder a
aplicaciones distribuidas las aplicaciones web que
pueden llegar a ser tan complejas como las clsicas
aplicaciones multinivel (n-tier), donde el componente de
interfaz es provisto por el navegador y los componentes de
lgica de la aplicacin y de gestin de datos se acceden
desde el servidor web o desde el propio cliente.

En el presente artculo se describe de manera integral un

conjunto de procedimientos y notaciones orientados a
facilitar a los equipos de desarrollo de aplicaciones en
Internet el manejo de la complejidad de las mismas y la
obtencin de productos de alta calidad, que satisfagan las
necesidades de los clientes y usuarios, y dentro de los plazos
y presupuestos planeados. Si bien estas guas estn
enmarcadas dentro de un modelo de Proceso de Desarrollo
genrico, instanciable a distintos dominios de aplicacin, se
han incluido elementos especficos para las aplicaciones en
Internet, como la Extensin para Aplicaciones Web de UML
[10].

Por las mismas razones, ya no es suficiente, como hasta hace

no mucho tiempo, con armarse con un cursillo de HTML y
un editor de texto, o en el mejor de los casos con un
generador de pginas web, para sacarle un buen provecho a
Internet. Hoy en da se requiere contar con un arsenal
adecuado para el desarrollo de aplicaciones en Internet, en el
que son imprescindibles las tcnicas y herramientas de
modelado. Esta necesidad se hace ms evidente al considerar
los siguientes factores:
- Uso creciente de Internet como proveedor de mltiples
servicios. Como se ha mencionado, ya no slo se usa la
red para acceder a informacin esttica, sino tambin para
acceder a servicios que utilizan en forma dinmica
informacin contenida en una base de datos, como la
consulta a un diccionario en lnea, u obtienen los
resultados de una aplicacin, como el clculo de las cuotas
en un simulador de crdito. Estos servicios cubren ya una
amplia gama de aplicaciones que incluyen la telemedicina,
el comercio electrnico, y la teleeducacin, y que no slo
atienden usuarios de computadores sino tambin usuarios
de dispositivos inalmbricos con protocolos como WAP
(Wireless Application Protocol).
- Diversidad de participantes en el desarrollo de las
aplicaciones. Adems del equipo de desarrollo, la
construccin de aplicaciones web requiere de personas de
muy variadas disciplinas; para una aplicacin de comercio
electrnico, por ejemplo, se debe contar con la
participacin de la alta gerencia de la empresa usuaria, los
consumidores de sus productos, las empresas proveedoras,
diseadores grficos, comunicadores sociales, abogados,
etc.
- Continua evolucin de las aplicaciones. La permanente
adaptacin, tanto a nuevas condiciones del negocio como a
nuevas tecnologas que van surgiendo, es una condicin
necesaria para la supervivencia de las aplicaciones en
Internet, la cual ha llevado a afirmar a Grady Booch que
una aplicacin web estancada est muerta1.
- Las aplicaciones deben cumplir con caractersticas
exigentes. Su carcter distribuido, el hecho de que se
ejecuten sobre una red Internet que no garantiza altos
1

Prlogo de [10].

La siguiente seccin explica los principios generales del

proceso de desarrollo presentado en el artculo. La Seccin
III describe la Fase de Gestacin, haciendo nfasis en los
componentes de Modelado de la Organizacin y Captura de
Requisitos. La Seccin IV trata de la Fase de Preparacin,
con nfasis en los componentes de Anlisis y Diseo, y
describe la Extensin para Aplicaciones Web de UML. La
Seccin V ofrece las conclusiones del trabajo.
II. PROCESO DE DESARROLLO
Los modelos que se presentan en este artculo corresponden
a un proceso de desarrollo basado en el trabajo que desde
hace ms de un lustro vienen realizando los three amigos,
Grady Booch, James Rumbaugh e Ivar Jacobson, y que ha
tomado forma en el Proceso Unificado (Unified Process,
UP) ([11], [13]), como gua metodolgica, y el Lenguaje
Unificado de Modelado (Unified Modeling Language, UML)
[14], como notacin para los modelos.
El proceso de desarrollo de aplicaciones informticas
(software development process) es el conjunto de acciones y
elementos necesarios para transformar los requisitos de los
usuarios en un sistema informtico, y est definido en
trminos de quin hace qu, cundo ha de hacerlo, y cmo
obtener un cierto objetivo. El proceso de desarrollo descrito
en UP est caracterizado por tres principios fundamentales:
es iterativo e incremental, es conducido por casos de uso, y
est centrado en la arquitectura.
En cumplimiento del principio de desarrollo incremental e
iterativo, que a su vez est basado en el modelo en espiral de
Boehm [15], UP propende por una ruptura definitiva con el
modelo en cascada. Mientras que en ste las actividades de
captura de requisitos, anlisis, diseo, implementacin y
pruebas se agotan de manera secuencial hasta llegar a la
terminacin del sistema, en UP ellas son ejecutadas con
mayor o menor intensidad a lo largo de todo el ciclo de
desarrollo, a la manera de miniproyectos que permiten un
mayor control del avance de la construccin del sistema. El
ciclo de desarrollo se divide as en fases, que estn definidas

Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
en trminos de los productos (denominados artefactos) que
deben ser obtenidos en ciertos momentos clave
(denominados hitos), mediante el concurso de todas o al
menos varias de las actividades de desarrollo.
El esquema de UP de la Figura 3 muestra las actividades
organizadas en componentes, en el eje vertical, y con
variable intensidad de ejecucin en el eje del tiempo,
organizado en fases, iteraciones e hitos. Los componentes
agrupan las actividades segn su naturaleza, estableciendo la
estructura del proceso de desarrollo, y se expresan en
trminos de los flujos de trabajo que deben ejecutarse, los
artefactos que deben construirse y los trabajadores
responsables de su realizacin.

de la arquitectura fsica sobre la que va a funcionar y su

entorno de implementacin, esto es, sistemas operativos,
protocolos, lenguajes de programacin, etc. Con los
artefactos obtenidos se responde la pregunta Cmo se
construye el sistema?
- Implementacin. Tangibiliza el sistema al verter en
archivos de cdigo fuente, guiones de comandos, binarios,
libreras, ejecutables y dems, la conceptualizacin del
sistema que hasta el momento estaba expresada slo en
modelos, generalmente grficos.
- Pruebas. Evala los componentes construidos y el sistema
completo a fin de garantizar que satisfacen un cierto
conjunto de requisitos y contienen un nmero mnimo de
defectos.

Organizacin por
Componentes

Organizacin en el tiempo

COMPONENTES DEL PROCESO

Gestacin Preparac. Construccin

FASES
Transicin

Modelado de la Organizacin
Captura de Requisitos
Anlisis
Diseo
Implementacin
Pruebas
Puesta en Servicio

- Puesta en servicio. Comprende la instalacin

del sistema en la planta fsica y los equipos del
cliente, y su entrega en operacin a satisfaccin
del cliente y los usuarios.
Los Componentes de Soporte contienen los flujos
de trabajo de carcter administrativo, que son:
- Gestin de configuracin y cambios. Realiza
el seguimiento y mantiene la integridad de los
artefactos a medida que evolucionan. Es aqu
donde se hace el control de versiones, la
administracin y anlisis de impacto de los
cambios, y la extraccin de informacin sobre
el avance del proyecto.

COMPONENTES DE SOPORTE
Gestin de Configuracin y Cambios
Gestin del Proyecto
Entorno

Hitos

Inicial

Prep. Prep. Const. Const. Const. Trans. Trans.

#1 #2
#1
#2
#N
#1
#2

Iteraciones
Figura 3. Organizacin del Proceso Unificado

Los Componentes del Proceso contienen los flujos de trabajo

que contribuyen directamente con la construccin del
sistema, a saber:
- Modelado de la Organizacin. Tiene como fin la
comprensin cabal por parte del equipo de desarrollo (y
con frecuencia del propio cliente) de la estructura y
funcionamiento de la organizacin a la cual brindar
soporte la aplicacin a construir. Su aporte es la
identificacin del problema que debe ser resuelto por el
sistema en desarrollo; en otros trminos, responder a la
pregunta Cul es el problema?
- Captura de Requisitos. Su propsito es la descripcin de
las funcionalidades y caractersticas que debe (y no debe)
ofrecer el sistema a sus clientes y usuarios. Esta
descripcin responde a la pregunta Qu hace el sistema?
- Anlisis. Define una estructura y funcionalidad de los
componentes del sistema, de modo que satisfagan las
necesidades de sus clientes y usuarios. Los artefactos
elaborados en este componente permiten responder la
pregunta Cmo funciona el sistema?
- Diseo. En este componente se aterriza el desarrollo del
sistema, al incorporar en su concepcin la consideracin

- Gestin del proyecto. Es el componente donde

se elabora la planeacin del proyecto y sus
iteraciones, se establecen las estrategias para la
gestin de los riesgos y se realiza el monitoreo del avance
del proyecto.

- Entorno. Presta soporte al equipo de desarrollo mediante

la provisin, configuracin y mantenimiento de las
herramientas computacionales y metodolgicas requeridas
por el proyecto.
Mientras que la organizacin por componentes, como se dijo
arriba, representa el aspecto estructural de UP describiendo
las actividades, productos y trabajadores que integran el
proceso de desarrollo, la organizacin en el tiempo
representa su aspecto dinmico, describiendo cmo avanza
el ciclo de vida del sistema, y cmo se conjugan las
diferentes actividades para cumplir con los hitos del ciclo
desarrollo. Cada ciclo de desarrollo, que conduce a la
construccin y entrega de una nueva versin del sistema, se
divide en fases, cada una de las cuales culmina con un hito y
puede ser desarrollada en una o varias iteraciones.
Las fases de UP, a diferencia de las fases del modelo en
cascada, no estn delimitadas por la finalizacin secuencial
de las actividades, sino por hitos en los que se evalan los
resultados obtenidos gracias a la conjugacin de diversas
actividades. Las fases definidas son:

Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
- Gestacin. Su propsito es allegar la suficiente
informacin sobre el problema planteado, de manera que
el equipo de desarrollo y el cliente puedan establecer los
objetivos, el alcance y la factibilidad del proyecto.
Termina con un hito donde se decide si el proyecto se
lanza o no.
- Preparacin. Est orientada fundamentalmente a la
definicin de la arquitectura del sistema, lo cual implica
continuar el refinamiento del modelo de la organizacin y
los requisitos, iniciados en la fase de gestacin, avanzar en
el anlisis y el diseo hasta obtener la arquitectura del
sistema, e implementar y probar uno o ms prototipos a fin
de validar la arquitectura. Finaliza con un hito en el que,
por razones de viabilidad tcnica o econmica, todava se
puede abortar el desarrollo del proyecto sin que se
incurran en grandes prdidas, puesto que an no se ha
iniciado la costosa construccin del sistema.
- Construccin. Aunque se recorren todos los componentes
del proceso de desarrollo, a travs de varias iteraciones, el
mayor esfuerzo est centrado en la culminacin del diseo
y la implementacin, a partir de la arquitectura definida en
la fase anterior. Su hito terminal consiste en la obtencin
de la aplicacin informtica requerida, en condiciones de
ser operada por sus usuarios finales.
- Transicin. Consiste en la transferencia de la aplicacin al
cliente, incluyendo su puesta en operacin en las
instalaciones de ste, el entrenamiento de los usuarios, y la
depuracin de los errores que surgen al final. El hito con el
que termina es la entrega final de la aplicacin a
satisfaccin del cliente.
Si bien a lo largo del desarrollo del sistema se producen
planes de trabajo, glosarios, y otros documentos de tipo
textual, el proceso de desarrollo hace muchsimo hincapi en
la elaboracin de modelos grficos del sistema, para lo cual
se utiliza UML y sus extensiones. Estos modelos, al igual
que los otros artefactos, estn asignados a determinados
componentes, y se van refinando a medida que avanzan las
iteraciones y las fases. La relacin entre componentes y
modelos es la siguiente:
- Modelado de la Organizacin: Modelo de la Organizacin.
- Captura de Requisitos: Modelo de Casos de Uso.
- Anlisis: Modelo de Anlisis.
- Diseo: Modelo de Diseo.
- Implementacin: Modelo de Implementacin.
- Pruebas: Modelo de Pruebas.
Como podr apreciarse ms adelante, el Modelo de Casos de
Uso es el eje de la dinmica de desarrollo del sistema, pues
es en funcin de l que se construyen los dems modelos.
Los casos de uso, propuestos por Ivar Jacobson [12], sirven
para describir el comportamiento de un sistema en trminos
de secuencias de interacciones entre l y las entidades que
hacen parte de su entorno, denominadas actores. En el
Modelo de la Organizacin, los casos de uso (apellidados
de la organizacin) identifican los procedimientos de la
organizacin, que son su unidad de funcionamiento. Los
Casos de Uso de la Organizacin son la base para obtener

los casos de uso de la aplicacin a desarrollar, que integran

el Modelo de Casos de Uso. A su vez, son los casos de uso
de la aplicacin los que guan la construccin de los dems
modelos:
- Las clases de los modelos de Anlisis y Diseo se
identifican en funcin de los casos de uso, y sus
interacciones describen cmo realiza la aplicacin cada
caso de uso.
- Los casos de uso son implementados finalmente por el
cdigo del Modelo de Implementacin.
- Los casos de prueba que hacen parte del Modelo de
Pruebas son diseados para establecer si el
comportamiento de la aplicacin corresponde al
establecido en los casos de uso.
III. FASE DE GESTACIN
Si bien en esta fase se ejecutan tambin otros componentes
del proceso de desarrollo, en este artculo se har nfasis en
los componentes de Modelado de la Organizacin y Captura
de Requisitos.
A. Modelado de la Organizacin.
Como se indic con anterioridad, su propsito es brindar un
entendimiento de la nueva organizacin donde se va a
implantar el sistema, en trminos de su estructura
(departamentos, empleados, recursos, etc.) y su dinmica
(procesos y procedimientos), y a partir de l identificar y
comprender los problemas que pueden ser resueltos con el
soporte de la aplicacin a desarrollar.
Esta actividad es particularmente importante en el desarrollo
de aplicaciones en Internet, pues stas suelen tener un gran
impacto sobre el funcionamiento de las organizaciones, que
es fcilmente subestimado. Por ejemplo, la introduccin de
servicios de comercio electrnico no implican slo la
automatizacin de ciertos procesos como venta y
proveedura, sino tambin, y ante todo, un anlisis sobre los
nuevos mercados que se abren a travs e Internet, una
caracterizacin de los nuevos clientes, y una reorganizacin
de la empresa a fin de sacar el mejor provecho de la nueva
situacin.
Para describir la estructura y funcionamiento de una
organizacin se utilizan diversos artefactos obtenidos en el
componente de Modelado de la Organizacin [13]. Los ms
importantes son el Modelo de Casos de Uso de la
Organizacin y el Modelo de Objetos de la Organizacin, los
cuales son construidos utilizando los estereotipos de UML
mostrados en la Figura 4.
Los Actores de la Organizacin representan los clientes,
proveedores, socios y dems entidades externas con las
cuales interacta la organizacin.
Los Casos de Uso de la Organizacin representan los
procesos y procedimientos que se llevan a cabo en la
organizacin, en respuesta a una demanda externa.

Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
plazo, tipo, etc.). A continuacin el Asistente informa al
Analista, quien estudia la solicitud del Crdito y el Perfil del
Caso de Uso de
la Organizacin

Unidad de la
Organizacin

cliente y decide la aceptacin o denegacin del prstamo.

Actor de la
Organizacin

Realizacin de
Caso de Uso de
la Organizacin

Entidad de la
Organizacin

Trabajador de la
Organizacin

Figura 4. Estereotipos para el Modelado de la Organizacin

Las Entidades de la Organizacin representan los elementos

que la organizacin gestiona o produce (unidades de
informacin y otros recursos).
El Modelo de Casos de Uso de la Organizacin permite
representar los servicios que presta y dems interacciones
que tiene la organizacin con su entorno, y las personas y
organizaciones con las cuales sostiene esas interacciones. En
el ejemplo de la Figura 5a se muestra uno de los Casos de
Uso de la Organizacin para una organizacin financiera,
llamado Gestionar Prstamo, que representa el servicio de
crdito que la entidad ofrece a sus clientes.

Cliente

Gestionar Prstamo

a) Caso de Uso de la Organizacin

:Asistente

Tambin se pueden emplear diagramas de secuencia para

representar las interacciones entre los elementos de la
organizacin en la realizacin de un Caso de Uso de la
Organizacin.
B. Captura de Requisitos.
Durante la fase de Gestacin se ejecuta tambin el
componente de Captura de Requisitos, con la finalidad de
delimitar el sistema, y obtener una descripcin inicial de sus
interacciones con el exterior y la funcionalidad que debe
ofrecer. Esta descripcin inicial es presentada mediante una
primera versin del Modelo de Casos de Uso, que consta de
un diagrama de Casos de Uso ms una descripcin de los
casos de uso a alto nivel.
La Figura 6 muestra los casos de uso Solicitar Prstamo y
Estudiar Prstamo, que son derivados del Caso de Uso de la
Organizacin Gestionar Prstamo, y Control Acceso, que
define el procedimiento de autorizacin inicial de acceso al
sistema para el Analista. En las entrevistas con el personal de
la organizacin financiera se ha determinado que una de las
funciones de la aplicacin a desarrollar es la atencin va
web de las solicitudes de crdito de los clientes, las cuales
deben ser verificadas por el sistema (la labor desempeada
por el Asistente en el Modelo de Objetos de la Organizacin)
antes de notificar al Analista; este requisito que la aplicacin
debe satisfacer queda expresado en el caso de uso Solicitar
Prstamo, cuya descripcin es la siguiente:

:Analista

Cliente

Solicitar Prstamo

:Cliente
:Perfil

:Cuenta

:Crdito

Estudiar Prstamo

Analista

b) Modelo de Objetos de la Organizacin

Figura 5. Artefactos del Modelado de la Organizacin

El Modelo de Objetos de la Organizacin, por su parte,

representa la estructura interna de la organizacin, y
constituye la base para describir sus procesos y
procedimientos. En el ejemplo de la Figura 5b se muestran
los trabajadores y entidades de la organizacin financiera
que intervienen en la atencin de una solicitud de prstamo
de un cliente; los trabajadores son un Asistente y un Analista,
y las entidades son la Cuenta que posee el Cliente, su Perfil
(historial del cliente en la organizacin), y Crdito (registro
de toda la informacin relativa al prstamo). El Cliente es
atendido directamente por un Asistente, quien verifica que
posea Cuenta en la institucin, consulta su Perfil para
establecer si no est inhabilitado para recibir un prstamo, y
le solicita la informacin inicial sobre el Crdito (cantidad,

Control Acceso
Figura 6. Diagrama de Casos de Uso

Caso de uso: Solicitar Prstamo

Actores: Cliente (iniciador) y Analista
Tipo: Primario
Descripcin:
- El caso de uso empieza cuando el Cliente ingresa a la
opcin de solicitar un prstamo.
- El Sistema solicita al Cliente su identificacin.
- El Cliente ingresa su identificacin.
- El Sistema verifica que el Cliente tenga una Cuenta activa.
- El Sistema consulta el Perfil del Cliente para establecer si
no est inhabilitado para gestionar un crdito.

Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
- El Sistema solicita al Cliente la informacin del Crdito
deseado.
- El Cliente ingresa la informacin solicitada.
- El Sistema registra la informacin y notifica al Analista
que hay un nuevo Crdito para su estudio.
Esta es una descripcin de alto nivel, en la que se narra muy
brevemente la interaccin del sistema con los actores
identificados. El Modelo de Casos de Uso se refina en la fase
de Preparacin identificando nuevos casos de uso y
utilizando una descripcin extendida para todos ellos, en la
que se incluyen los flujos alternativos de accin y las
maquetas de las entradas (e.g. formularios de captura de
datos) y salidas (e.g. resultados de una bsqueda, listado por
impresora) del sistema.

usuarios o con otros sistemas (clase IU_Acceso).

Dependen, por supuesto, del entorno del sistema. Se
obtienen examinando la relacin con cada actor en los
casos de uso.
- Clases de Control. Modelan la lgica de la aplicacin
(clase CtrlAcceso). Son las responsables de coordinar los
eventos necesarios para implementar el comportamiento
especificado en los casos de uso, por lo cual dependen de
la aplicacin. Inicialmente se puede crear una clase de
control por cada par actor-caso de uso.

Analista

IU_Acceso

CtrlAcceso

IU_Menu

Usuarios

IV. FASE DE PREPARACIN

En esta fase se avanza en la ejecucin de todos los
componentes del proceso de desarrollo hasta obtener la
arquitectura del sistema. Este resultado se logra con el
concurso de dos actividades de la mayor importancia:
anlisis y diseo, las cuales, si bien son incluidas por UP en
el mismo componente, en este artculo reciben un
tratamiento diferenciado.
Esta seccin se centra de manera exclusiva en los dos
componentes mencionados arriba, sin que ello deba
interpretarse en el sentido que los otros componentes no
jueguen un papel tambin importante en la fase de
Preparacin; al final de la seccin anterior se anunci la
continuidad del componente de Captura de Requisitos, y no
est permitida la aprobacin de la arquitectura sin haberla
validado mediante la construccin de al menos un prototipo,
lo que involucra los componentes de Implementacin y
Pruebas.
A. Anlisis
Una actividad clave en este componente es la identificacin
de las clases del sistema a partir de los requisitos expresados
en el Modelo de Casos de Uso. Despus se identifican las
relaciones entre las clases y se definen sus atributos y
comportamiento, todo lo cual se describe en la Vista Lgica
del sistema, utilizando entre otros los Diagramas de Clase
para presentar la estructura y los Diagramas de Secuencias
de Mensajes para presentar su dinmica.

Figura 7. Diagrama de Clases de Anlisis

Algunos autores proponen una cuarta categora de Clases de

Excepcin, las cuales son las responsables de otorgar
robustez al comportamiento del sistema cuando se presentan
situaciones fuera de lo normal.
La Figura 7 representa las clases que realizan el Caso de Uso
control de acceso del analista al sistema, cuya dinmica est
descrita en el Diagrama de Secuencias de la Figura 8. Una
vez el Analista ha activado la aplicacin, la clase de control
CtrlAcceso invoca a la clase de interfaz IU_Acceso para que le
presente el formulario mediante el cual se le solicita su
identificacin y su clave. Cuando el Analista las ingresa,
IU_Acceso las entrega a CtrlAcceso, que consulta a la clase de
entidad Usuarios para verificar la validez de la informacin.
Si sta es correcta, CtrlAcceso activa a IU_Menu para que
presente el men principal de la aplicacin.

: IU_Acceso

: Analista

: IU_Menu

: CtrlAcceso

: Usuarios

Activa
Activa
Solicita ID+Clave
ID+Clave
ID+Clave
Consulta ID+Clave

Para la identificacin de las clases resulta de gran utilidad

echar mano de los criterios que permiten identificar tres
categoras de clases, ilustradas en la Figura 7, a saber:
- Clases de Entidad. Modelan la informacin que maneja el
sistema (clase Usuarios). Generalmente son un reflejo del
mundo real, no dependen del entorno del sistema, y
pueden ser independientes de la aplicacin cuando se
utiliza la misma informacin con diferentes propsitos. Se
obtienen examinando las responsabilidades del sistema en
los casos de uso.
- Clases de Frontera. Modelan las comunicaciones con el
exterior del sistema, proveyendo interfaces con los

Activa
Muestra Men Ppal

Figura 8. Diagrama de Secuencias

B. Diseo
El diseo comienza por lo general con dos actividades que
introducen sendos elementos clave en el desarrollo del
sistema. La primera de ellas es la construccin del Modelo

Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
de Implantacin, que describe la arquitectura fsica del
sistema y cmo se ejecutan sobre ella los componentes de la
aplicacin. La segunda actividad es la elaboracin de un
diagrama de subsistemas que, adems de representar los
componentes que estn siendo construidos, incluye tambin
aquellos que integran el entorno de implementacin.
Otra de las actividades de diseo es la obtencin de las
Clases de Diseo, para lo cual obviamente se parte de las
Clases de Anlisis, aunque algunas de ellas pueden
desaparecer y otras nuevas se incorporan al modelo. Para
cada categora de clase se realiza un tratamiento diferente,
teniendo en cuenta los elementos clave introducidos en el
diseo: la arquitectura fsica y el entorno de desarrollo.
En el caso de las Clases de Control, se deben analizar
aspectos como el grado de distribucin del sistema, el
rendimiento y la gestin de las transacciones. Se pueden
tener clases normales o pasivas, que funcionan bajo
demanda, ofreciendo servicios que slo se activan cuando
otra clase los requiere. Por otra parte, las clases tambin
pueden ser activas, es decir, poseen su propio hilo de
ejecucin; en cada nodo fsico de la arquitectura del sistema
debe haber al menos una instancia (objeto) de una clase
activa, y tambin se las requiere para el manejo de las
comunicaciones, el arranque, la reconfiguracin, etc., as
como para garantizar ciertos niveles de rendimiento y
disponibilidad del sistema. En el caso de las aplicaciones en
Internet, estas clases de control, que son las que establecen la
lgica de la aplicacin, se pueden implementar en cualquiera
de los niveles clsicos de una aplicacin multinivel: en el
nivel de interfaz, esto es, en las pginas web; en el nivel de la
gestin de los datos, como procedimientos almacenados del
gestor de la base de datos; o en el nivel de la lgica del
negocio, como componentes independientes de la interfaz y
los datos. Cada aplicacin requiere elegir la estrategia ms
adecuada para ella.

UML propuesta para la construccin de modelos de diseo

de aplicaciones web.
C. WAE: Web Application Extension
WAE extiende UML con estereotipos y restricciones
(contraints) para permitir el modelado de elementos de la
arquitectura especficos de la web como parte del modelo del
sistema [10]. Conallen propone un amplio conjunto de
estereotipos para la representacin de elementos como
pginas web, formularios, marcos, enlaces, servlets, etc.,
unas reglas de correcta formacin de los modelos, y unas
guas para el uso de la extensin. Est ms all del propsito
de este artculo explicar en detalle WAE, pero se darn
algunos ejemplos de su aplicacin.
La Figura 9 muestra algunos de los estereotipos de WAE.
Una pgina Cliente es una unidad de cdigo HTML que es
distribuida por el servidor web a sus clientes, que son los
navegadores, usando el protocolo HTTP; los navegadores
interpretan el cdigo y presentan la informacin que
contiene al usuario. Para obtener una Pgina Cliente, el
navegador enva al servidor web, usando tambin HTTP, la
direccin (URL, Uniform Resource Locator) de la pgina.

http
Servidor
Web
procesa
Pgina
Servidor

distribuye

construye

interpreta

Navegador

Pgina
Cliente

accede
Base de Datos

a) Pginas Cliente y Servidor

Las Clases de Entidad, que son las que contienen la

informacin del sistema, deben ser analizadas para
determinar cules de ellas requieren persistencia, esto es, la
capacidad para preservar su estado (los valores de sus
atributos) de una ejecucin a otra de la aplicacin. La
manera ms comn de lograrlo es mediante el uso de
Sistemas de Gestin de Bases de Datos Relacionales, lo cual
implica la transformacin de un modelo de objetos,
integrado por las instancias de las clases de entidad, en un
modelo relacional, integrado por las tablas donde queda
finalmente almacenada la informacin. Las herramientas a
usar por parte del equipo de desarrollo son las reglas de
transformacin de estos modelos (e.g. [16], [17]) y los
mecanismos para el acceso a bases de datos relacionales
desde aplicaciones orientadas a objetos, los cuales son
provistos por los mismos entorno de desarrollo.
El tratamiento de las Clases de Interfaz es el de mayor
inters desde el punto de vista del modelado de aplicaciones
en Internet, pues estas clases se convierten por lo general en
pginas web. La siguiente seccin describe una extensin de

Pagina
Cliente

Textbox
Text area
Checkbox
Radio button group
Selection list

0..*
submits

Forma
1

Pagina
1 Servidor

Figura 9. Estereotipos WAE

Una Pgina Servidora, por su parte, es una se

cuencia
de comandos (que pueden ser CGI, ASP, JSP, etc.) que son
procesados por el mismo servidor. Al igual que las Pginas
Cliente tienen una URL que es enviada por el navegador al

Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.

Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
servidor web, pero ste, en lugar de distribuir la pgina,
ejecuta las instrucciones que contiene. Estas instrucciones
pueden ser, por ejemplo, para consultar una base de datos y
extraer de ella informacin que interesa al usuario del
navegador, y terminan generalmente con la construccin de
una Pgina Cliente que contiene la informacin obtenida, y
que es enviada entonces por el servidor web al navegador
para que se la presente al usuario. Desde el punto de vista de
ste, el servidor web le enva la Pgina Cliente construida en
forma dinmica, en respuesta a la URL de la Pgina
Servidora enviada previamente.
Las Pginas Cliente pueden contener formularios, que son
campos de entrada a travs de los cuales el usuario ingresa
informacin que luego es procesada en el servidor web;
dichos campos pueden ser cajitas de texto, reas de texto con
mayor capacidad, cajas de chequeo, grupos de botones de
seleccin, y listas de seleccin. Cada formulario de la Pgina
Cliente tiene asociada una Pgina Servidora que es la que
recibe y procesa la informacin contenida en el formulario.

complejidad creciente. El modelo de proceso de desarrollo

propuesto por UP, con el soporte de UML y sus extensiones
para el modelado de la organizacin y las aplicaciones web,
y basada en slidos principios que han sido madurados por
aos de experiencia, ofrece una gua metodolgica que les
permite a los equipos de desarrollo incrementar sus
posibilidades de xito al enfrentar el reto de construir tales
aplicaciones.
Como lo sealan reiteradamente sus autores, los criterios,
tcnicas, modelos y dems elementos de estas metodologas
constituyen un marco general que debe ser adaptado para
cada equipo de desarrollo y cada proyecto, teniendo en
cuenta los niveles de formacin de las personas, los estilos
de trabajo, los recursos tcnicos, fsicos y financieros
disponibles.
REFERENCIAS
[1]
[2]

El Diagrama de Clases de Diseo de la Figura 10 utiliza

WAE para representar el refinamiento del Diagrama de
Clases de Anlisis de la Figura 7; se muestran tanto las
representaciones grficas (conos) de los estereotipos de las
clases como los estereotipos de las relaciones entre stas. La
Pgina Cliente Acceso, que es la que se le presenta al Analista
cuando activa la aplicacin, posee el formulario ID_Clave
que contiene las cajitas de texto para ingresar la
identificacin y la clave. Cuando se presiona el botn
Aceptar, se transmite esta informacin al servidor web, que
la entrega a la Pgina Servidora CtrlAcceso. El cdigo
contenido en esta pgina consulta Usuarios para verificar si
es correcta la informacin ingresada por el Analista, y en tal
caso construye la Pgina Cliente Men, probablemente a
partir de una plantilla a la que se agrega alguna informacin
personalizada para el usuario. La pgina Men ofrece al
Analista opciones que lo llevan a otras pginas a travs de
enlaces de hipertexto.

[3]

[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]

Acceso

Menu

links

OpcinX

[12]
[13]
[14]

builds
ID_Clave
Identificador
Clave

submits

CtrlAcceso

query

[15]
Usuarios

[16]
[17]

Figura 10. Diagrama de Clases de Diseo

V. CONCLUSIONES
La Web se ha convertido en una plataforma de amplsimo
alcance para la prestacin de todo tipo de servicios, que
exigen el desarrollo y mantenimiento de aplicaciones de

R.J. Vetter, C. Spell, and C. Ward. "Mosaic and the World-Wide

Web". IEEE Computer Magazine, Vol. 27, pp. 49-57, October 1994.
D. Raggett, A. Le Hors, I. Jacobs (Eds.). "Hypertext Markup
Language -- HTML 4.01 Specification". W3C Recommendation.
<http://www.w3.org/TR/html4/>. 24 December 1999.
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and
T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1". RFC
2616. The Internet Society. <http://www.w3.org/Protocols/rfc2616/
rfc2616.html>. June 1999.
World Wide Web Consortium. CGI: Common Gateway Interface.
<http://www.w3.org/CGI/>. Octubre 1999.
Apache Software Foundation. PHP: Hypertext Preprocessor.
< http://www.php.net/>. Octubre 2001.
Sun
Microsystems.
Java
Servlet
Technology.
<http://java.sun.com/products/servlet/>. Octubre 2001.
Microsoft Corporation. An ASP You Can Grasp: The ABCs of
Active Server Pages. <http://msdn.microsoft.com/workshop/server/
asp/ASPover.asp>. Mayo 1997.
Object Management Group. CORBA/IIOP Specification.
<http://www.omg.org/technology/documents/formal/
corba_iiop.htm>. Septiembre 2001.
Microsoft Corporation. Distributed Component Object Model
(DCOM). <http://www.microsoft.com/com/tech/DCOM.asp>. Marzo
1998.
Jim Conallen. Building Web Applications with UML. AddisonWesley. 2000
Ivar Jacobson, Grady Booch and James Rumbaugh. The Unified
Software Development Process. Addison-Wesley. 1998.
I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. ObjectOriented Software Engineering. A Use Case Driven Approach.
Addison-Wesley. 1992.
Philippe Kruchten. The Rational Unified Process, An Introduction.
Addison-Wesley. March 2000.
UML Revision Task Force. OMG Unified Modeling Language
Specification, v. 1.3. Document ad/99-06-08, Object Management
Group. June 1999.
Barry Boehm. A Spiral Model of Software Development and
Enhancement. IEEE Computer, 21(5):61-72, 1988.
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen.
Object-Oriented Modeling and Design. Prentice Hall. 1991. Seccin
17.3 Relational Database Design, pg. 373.
Consejo Superior de Informtica. "METRICA versin 3. Metodologa
de Planificacin, Desarrollo y Mantenimiento de sistemas de
informacin", Ministerio de Administraciones Pblicas, Madrid
(Espaa).
Julio
2001.
Documento
3:
"Tcnicas".
<http://ns.map.es/csi/metrica3>.