Uwe PDF

Universidad de San Carlos de Guatemala
Facultad de ngeniera
Escuela de ngeniera en Ciencias y Sistemas

PROPUESTA DE ANLISIS Y DISEO BASADA EN UML Y UWE
PARA LA MIGRACIN DE ARQUITECTURA DE SOFTWARE
CENTRALIZADA HACIA INTERNET

HaroIdo Fernando Prez Hernndez
Asesorado por el ng. Jos Francisco Lpez Rodriguez

Guatemala, noviembre de 2010

UNVERSDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE NGENERA

CENTRALIZADA HACIA INTERNET

TRABAJO DE GRADUACN

PRESENTADO A LA JUNTA DRECTVA DE LA
FACULTAD DE NGENERA
POR

HAROLDO FERNANDO PEREZ HERNANDEZ
ASESORADO POR EL NG. JOS FRANCSCO LOPEZ
RODRGUEZ

AL CONFERRSELE EL TTULO DE

INGENIERO EN CIENCIAS Y SISTEMAS

GUATEMALA, NOVEMBRE DE 2010

UNVERSDAD DE SAN CARLOS DE GUATEMALA
FACULTAD DE NGENERA

NMINA DE JUNTA DIRECTIVA

DECANO ng. Murphy Olympo Paiz Recinos
VOCAL nga. Glenda Patricia Garca Soria
VOCAL nga. Alba Maritza Guerrero de Lpez
VOCAL ng. Miguel ngel Dvila Caldern
VOCAL V Br. Luis Pedro Ortz de Len
VOCAL V P. A. Jos Alfredo Ortz Herincx
SECRETARO ng. Hugo Humberto Rivera Prez

TRIBUNAL QUE PRACTIC EL EXAMEN GENERAL PRIVADO

DECANO ng. Murphy Olympo Paiz Recinos
EXAMNADORA nga. Virginia Victoria Tala Ayerdi
EXAMNADOR ng. Marlon Antonio Prez Turk
EXAMNADOR ng. Cresencio Gertrudis Chan Canek
SECRETARA nga. Marcia vonne Vliz Vargas

HONORABLE TRIBUNAL EXAMINADOR

Cumpliendo con los preceptos que establece la ley de la Universidad de San
Carlos de Guatemala, presento a su consideracin mi trabajo de graduacin
titulado:

CENTRALIZADA HACIA INTERNET,

tema que me fuera asignado por la Direccin de la Escuela de ngeniera en
Ciencias y Sistemas, el 22 de julio de 2009.

Haroldo Fernando Prez Hernndez

ACTO QUE DEDICO A:

DIOS
Por darme la sabidura y fortaleza para lograr una meta
ms. Es la fuente de mi inspiracin y es su voluntad este
acto.

MIS PADRES

Por estar siempre a mi lado y apoyarme en todo momento.
No hubiera sido posible sin ustedes.

MI FAMILIA
Por su apoyo incondicional cuando fue necesario en las
buenas y en las malas.

AGRADECIMIENTOS A:

MI ASESOR Ingeniero Jos Francisco Lpez
Por dedicarme su tiempo y experiencia para que este
trabajo llene las expectativas profesionales necesarias.

MIS AMIGOS
Por su amistad, apoyo y compartir su tiempo a lo largo de
esta carrera y el transcurso de mi vida, para no sentirme
solo en este camino formativo lleno de retos y dificultades,
he aprendido mucho de ustedes.

NDCE GENERAL
I
NDICE GENERAL

NDICE DE ILUSTRACIONES .......................................................... V
GLOSARIO ..................................................................................... V
RESUMEN ....................................................................................... X
OBJETIVOS ................................................................................... X
INTRODUCCIN ........................................................................... XV

1. MARCO TERICO ....................................................................... 1
1.1. Fundamentos de UML y UWE .................................................................... 1
1.1.1. ntroduccin al UML ............................................................ 1
1.1.2. Reglas del UML ................................................................... 3
1.1.3. Diagramas ........................................................................... 3
1.1.3.1. Diagramas recomendados ................................................ 5
1.1.4. ntroduccin a UWE ........................................................................ 6
1.1.4.1. Caractersticas principales ................................................ 7
1.1.4.2. Fases de desarrollo .......................................................... 7
1.2. Reingeniera de software ............................................................................. 9
1.3. ngeniera inversa ...................................................................................... 12
1.4. Migracin de sistemas ............................................................................... 13
1.4.1. Objetivos de migracin ................................................................. 14
1. 5. Aplicacin web .......................................................................................... 15
1.5.1. Caractersticas ............................................................................. 16
1.5.2. Tipos ............................................................................................. 16
1.5.3. Condiciones para el desarrollo .................................................... 17
NDCE GENERAL
II
1.6. Sistemas de informacin centralizados ...................................................... 18

2. ANLISIS Y REDISEO DEL SISTEMA CENTRALIZADO
USANDO UML. ............................................................................... 21
2.1. Anlisis del sistema actual con ingeniera inversa ...................................... 21
2.1.1. Especificaciones funcionales del sistema actual ........................... 23
2.1.2. Esquema lgico de datos .............................................................. 24
2.2. Esquema conceptual y modelado visual con UML ..................................... 26
2.2.1. La vista esttica ............................................................................ 26
2.2.1.1. dentificacin de conceptos ............................................. 28
2.2.1.2. Definicin en UML del modelado conceptual ................... 29

3. REDISEO DEL SISTEMA DE INFORMACIN CON UWE ..... 33
3.1. Diseo conceptual con UWE ...................................................................... 33
3.1.1. Perfiles de usuario ........................................................................ 34
3.1.2. Escenarios de uso ......................................................................... 35
3.1.2.1. Modelo de proceso de flujo de trabajo ............................. 35
3.1.2.2. El modelo de secuencia de tareas ................................... 35
3.1.2.3. El modelo de ambiente fsico ........................................... 36
3.1.3. Diagrama de casos de uso ........................................................... 36
3.1.4. Diseo conceptual sobre tres capas ............................................. 38
3.1.4.1 .Capa de presentacin ..................................................... 39
3.1.4.2. Capa de negocios ............................................................ 40
3.1.4.3. Capa de datos ................................................................. 42
3.2. Diseo lgico .............................................................................................. 42
3.2.1. Organizacin de las estructuras lgicas ........................................ 43
3.2.2. Transicin del diseo conceptual al diseo lgico ........................ 43
3.2.3. Creacin del diseo lgico ............................................................ 44
NDCE GENERAL
III
3.2.3.1. dentificacin de objetos ................................................. 45
3.2.3.2. dentificacin de los comportamientos ............................ 46
3.2.3.3. dentificacin de atributos ............................................... 48
3.2.3.4. dentificacin de relaciones ............................................. 49
3.2.4. Diagramas de clases .................................................................... 50
3.2.4.1. Mtodos de las clases en cada una de las tres capas .... 50

4. REDEFINICIN CON UNA ARQUITECTURA WEB USANDO
UWE ................................................................................................ 53
4.1. Modelando el proceso de negocio web con UWE ...................................... 53
4.1.1. ntegracin de procesos en el modelo de navegacin.................. 54
4.1.1.1. Modelado del espacio navegacional ............................... 54
4.1.1.2. Estructura del modelado navegacional ........................... 56
4.1.2. Afinando el modelado de procesos .............................................. 57
4.1.2.1. Modelo estructural del proceso ....................................... 58
4.1.2.2. Modelo de comportamiento del proceso ......................... 58
4.1.3. Soporte de procesos en el modelo de presentacin .................... 59
4.1.3.1. Estructura visual ............................................................. 60
4.1.3.2. nterfaz de usuario .......................................................... 61

5. CASO DE ESTUDIO ................................................................... 63
5.1. Descripcin caso de estudio. Sistema de contratos de personal ............... 63
5.2. Solucin de la migracin utilizando el mtodo propuesto .......................... 64
5.2.1. Anlisis y diseo del sistema actual centralizado ......................... 66
5.2.2. Rediseo del sistema de informacin con UWE ........................... 68
5.2.2.1. Nuevos escenarios de uso .............................................. 69
5.2.2.2. Especificacin y diagramas de casos de uso.................. 69
5.2.2.3. Diagrama de clases ........................................................ 78
NDCE GENERAL
IV
5.2.2.4. Diagramas de secuencia ................................................. 79
5.2.2.5. Diagramas de colaboracin ............................................. 82
5.2.3. Modelando el sistema con una arquitectura web .......................... 84
5.2.3.1. ntegracin de procesos en el modelo de navegacin ..... 84
5.2.3.1.1. Modelado del espacio navegacional ............................. 84
5.2.3.1.2. Estructura del modelado navegacional ......................... 87
5.2.3.2. Afinando el modelado de procesos ................................. 91
5.2.3.2.1. Modelo estructural del proceso ..................................... 91
5.2.3.2.2. Modelo de comportamiento del proceso ....................... 94
5.2.3.3. Soporte de procesos en el modelo de presentacin ........ 98
5.2.3.3.1. Estructura visual ........................................................... 98
5.2.3.3.2. nterfaz de usuario ........................................................ 99
5.2.4. Diagramas de componentes y despliegue .................................. 102
5.3. Prcticas adecuadas ................................................................................ 105

CONCLUSIONES ......................................................................... 107
RECOMENDACIONES ................................................................. 109
REFERENCIAS BIBLIOGRFICAS ............................................. 111
BIBLIOGRAFA ............................................................................ 113
NDCE DE LUSTRACONES
V
NDICE DE ILUSTRACIONES

FIGURAS

1. mpacto de cambio en el Software con respecto al cambio en las
reglas de negocio ....................................................................................... XV
2. Visualizacin del concepto ............................................................................ 27
3. Asociacin y multiplicidad ............................................................................. 30
4. Concepto y atributos ..................................................................................... 31
5. Conceptualizando procedimientos ................................................................ 31
6. Arquitectura de tres capas. ........................................................................... 39
7. Objetos ......................................................................................................... 46
8. Comportamiento del objeto user ................................................................... 47
9. Atributo del objeto user ................................................................................. 48
10. Ejemplo de diagrama de secuencia y relaciones de objetos ...................... 51
11. Estereotipos y sus conos para el modelo de navegacin .......................... 57
12. Estereotipos y sus conos para el modelo de presentacin ........................ 62
13. Sistema centralizado, caso de estudio. ....................................................... 65
14. Sistema migrado hacia nternet, caso de estudio. ...................................... 66
15. Abstraccin de clases del sistema antiguo, caso de estudio. ..................... 67
16. Abstraccin de clases detallado del sistema antiguo, caso de estudio. ...... 68
17. Diagrama de caso de uso, ingreso al sistema. ........................................... 75
18. Diagrama de caso de uso, mantenimiento de empleados. ......................... 76
19. Diagrama de caso de uso, contexto de administracin de personal. .......... 77
20. Vista conceptual rediseada, diagrama de clases. ..................................... 78
21. Diagrama de secuencia para la altas, bajas y consultas de empleados. .... 79
NDCE DE LUSTRACONES
VI
22. Diagrama de secuencia, ingreso de solicitud. ............................................. 80
23. Diagrama de secuencia del proceso de autorizacin y generacin de
contratos. .................................................................................................... 81
24. Diagrama de colaboracin, ingreso de solicitudes de contratos. ................ 82
25. Diagrama de colaboracin, administracin de solicitudes de contratos. ..... 83
26. Diagrama de colaboracin, mantenimiento de empleados. ......................... 83
27. Diagrama de espacio de navegacin por departamento. ............................ 84
28. Diagrama de espacio de navegacin para presupuesto. ............................. 85
29. Diagrama de espacio de navegacin para gerencia. ................................... 86
30. Diagrama de estructura de navegacin por departamento. ......................... 88
31. Diagrama de estructura de navegacin para presupuesto. ......................... 89
32. Diagrama de estructura de navegacin para gerencia. ............................... 90
33. Diagrama de estructura de proceso para procesamiento de solicitud. ........ 92
34. Diagrama de estructura de proceso para procesamiento de contrato y
solicitud autorizada. .................................................................................... 93
35. Diagrama de flujo de proceso para creacin de solicitud. ........................... 95
36. Diagrama de flujo de proceso para eliminacin de solicitud. ....................... 96
37. Diagrama de flujo de proceso para generacin de contrato. ....................... 97
38. Diagrama de presentacin, estructura visual para pgina de solicitud. ....... 99
39. Diagrama de presentacin, interfaz de usuario, creacin de solicitud. ...... 100
40. Diagrama de presentacin, interfaz de usuario, eliminacin de solicitud. . 101
41. Diagrama de componentes, estructura de pginas. .................................. 102
42. Diagrama de despliegue para usuarios de los departamentos de la
empresa. .................................................................................................... 103
43. Diagrama de despliegue para usuarios de presupuesto de la empresa. ... 104
44. Diagrama de despliegue para usuarios de gerencia de la empresa. ......... 104

GLOSARO
VII
GLOSARIO

Actor Es una persona o entidad externa al sistema que
interacta con los casos de uso.

ApIicacin Programa que realiza una serie de funciones y con
el cual se trabaja en el computador.

Arquitectura de software La manera en la cual el software est estructurado y
construido. Diseo de alto nivel de la estructura de
un sistema.

Atributo Es la descripcin de un campo con nombre de un
tipo especificado en una clase.

Browser Programa que permite leer documentos en la Web y
seguir enlaces (links) de documento en documento
de hipertexto.

Bug Se refiere a un error o defecto de software, resultado
de una deficiencia o falla durante el proceso de
creacin de programas para un computador.

CASE (Computer Aided Software Engineering) ngeniera
de software asistida por un computador, su objetivo
GLOSARO
VIII
reducir tiempo y dinero en el desarrollo de
aplicaciones.

Caso de uso Especificacin de las secuencias de acciones,
efectuadas por un sistema o clase, que interactan
con actores externos.

CIase Descriptor de un conjunto de objetos que comparten
los mismos atributos, operaciones, mtodos,
relaciones y comportamiento.

Data warehouse Dentro de un contexto de informtica significa
almacn de datos, determinado a un mbito
integrado, que ayuda a la toma de decisiones en la
entidad que se utiliza.

Front-end En diseo de software, se refiere a la parte que
interacta con el usuario.

GranuIaridad Es el grado de detalle de una definicin. La forma en
que los recursos se unen o se agregan entre s
define la granularidad.

Identidad Propiedad inherente de un objeto que permite
distinguirlo de todos los dems objetos.

ImpIementacin La forma en que se construye o calcula algo. Fase
de un sistema que describe el funcionamiento del
sistema en un medio ejecutable.
GLOSARO
IX
Interfaz Un conjunto de operaciones que posee un nombre y
el comportamiento de un elemento.

Hardware Conjunto de componentes que integran la parte
fsica material de un equipo de cmputo sobre el
cual funcionan programas de computadora.

HTML (Hyper Text Markup Language) Lenguaje de marcas
de hipertexto, lenguaje etiquetado o marcado que
predomina para la creacin de pginas web.

Mainframe Computadora central, potente y costosa, para
grandes procesamientos, su arquitectura es
centralizada, su acceso es por medio de terminales
fsicas o virtuales.

Migracin de sistemas Consiste en trasladar un sistema informtico a otro,
puede cambiar, plataforma, arquitectura o datos.

ModeIo Es una abstraccin semnticamente completa de un
sistema.

OCL (Object Constraint Language) Lenguaje de
restricciones para objetos. Describe formalmente las
expresiones en los modelos UML.

Pgina Documento situado en una red informtica, al que se
accede mediante enlaces de hipertexto.
GLOSARO
X
Software Conjunto de programas, instrucciones y reglas
informticas para ejecutar ciertas tareas de una
computadora.

UML

(Unified Modeling Language) Lenguaje de modelado
visual. Un lenguaje que permite modelar problemas
usando modelos organizados en torno a las ideas
del mundo real.

VAX (Virtual Address eXtended) Fue la primera mquina
comercial de arquitectura de 32 bits, marc un hito
en la historia, lanzada en 1977.

UWE (UML based Web Engineering) ngeniera Web
basada en UML, es una propuesta de metodologa
que gua el proceso de desarrollo de una aplicacin
Web.

Web Del ingls red, telaraa conocida como "la Web, es
el sistema de documentos interconectados por
medio de enlaces de hipertexto, accesibles en
nternet.

Web Server Computadora que provee el servicio de publicacin
de un sistema en nternet.

RESUMEN
XI
RESUMEN

Se presenta una propuesta del modelo de anlisis y diseo, para la
migracin de aplicaciones con poca funcionalidad y necesidad de cambio,
construidas con arquitectura centralizada, y su traslado sea hacia una
arquitectura que funcione en nternet, conjugando distintas representaciones
visuales y conceptuales, que permite UML y sus respectivas extensiones para
aplicaciones en nternet.

La primera fase se refiere al anlisis del sistema centralizado antiguo, y
el modelado conceptual del mismo con la nomenclatura UML para la
especificacin formal del funcionamiento de ste. En el proceso de abstraccin
de informacin del sistema centralizado se utiliza como herramienta principal la
ingeniera inversa, la cual es necesaria por la poca documentacin que existe
para este tipo de sistemas y la investigacin de los usuarios principales.

La segunda fase consiste en tomar la conceptualizacin obtenida del
sistema centralizado y la investigacin de nuevos escenarios de uso, para
redisear el sistema, tomando en cuenta que la migracin ser hacia nternet.
Se modifica y se ampla el diseo conceptual obtenido por medio de UWE,
especificando casos de uso, secuencia de actividades y comportamiento de los
objetos. Adems el diseo lgico se inicia con la identificacin de objetos,
atributos, propiedades y las relaciones que estos tengan.

RESUMEN
XII
La tercera fase que se propone consiste en la redefinicin del sistema
con la nueva arquitectura en nternet, partiendo del nuevo diseo conceptual
redefinido, agregando los diseos de navegacin y presentacin que sugiere la
metodologa propuesta para la Web, UWE.

OBJETVOS
XIII
OBJETIVOS

GeneraI

Brindar una propuesta prctica de anlisis y diseo para llevar a cabo la
migracin de un sistema con arquitectura centralizada, para que funcione con
arquitectura para nternet, por medio de fundamentos de UML y UWE.

Especficos

1. Dar a conocer la aplicacin de estndares UML en el anlisis del
problema de migracin, para ofrecer un mejor control del proceso.

2. Ofrecer una serie de etapas bsicas necesarias para el modelado del
proceso de migracin de sistemas en estudio.

3. Relacionar la interface en nternet por medio de UWE y la lgica de
negocios preexistentes.

OBJETVOS
XIV

NTRODUCCN
XV
INTRODUCCIN

El software que representan los sistemas de informacin suelen ser la
realizacin de las reglas de negocios de todas las organizaciones. A medida
que cambian estas reglas, el software tiene que cambiar tambin. En la
actualidad, existen muchas compaas que poseen miles de lneas de cdigo
de computadora que codifican sus reglas de negocio.

Cuando los administradores intentan modificar esas reglas para lograr
una mayor efectividad y competitividad, el software tiene que adaptarse. En
algunos casos, esto implica la creacin de nuevos sistemas de software, pero
en otros significa la modificacin y/o reconstruccin de aplicaciones ya
existentes, para que sean competentes a la hora de satisfacer las necesidades
cambiantes de los negocios del siglo XX, entre ellas la necesidad y/o
conveniencia de algunos sistemas de colocarse en nternet.

Aunque la migracin y reingeniera de negocios sea una estrategia
resistida por parte de la compaa, es algo que debe hacerse. Existen miles de
sistemas, aplicaciones cruciales para el xito de los negocios grandes y
pequeos, que estn afectados por una enorme necesidad de ser trasladados y
reconstruidos hacia plataformas en nternet.

NTRODUCCN
XVI
Este escenario resulta sumamente conocido, se tiene una aplicacin que
ha servido para las necesidades del negocio de una compaa durante diez o
quince aos. A lo largo de este tiempo, ha sido corregida, adaptada y mejorada
muchas veces. Las personas se dedicaban a esta tarea con la mejor de las
intenciones, pero las buenas prcticas de ingeniera de software siempre se
omitan, por la urgencia de otros problemas.

Aun cuando este software se haya creado empleando las mejores
tcnicas de diseo y codificacin, conocidas en la poca que fueron creados (y
la mayora no lo fueron), se cre cuando los tamaos de los programas y el
espacio de almacenamiento eran las preocupaciones principales. Luego se
traslad a nuevas plataformas, se ajust para adecuarlo a cambios de equipo y
sistema operativo, se mejor para satisfacer nuevas necesidades de usuario; y
todo esto se hizo sin tener en cuenta la arquitectura global y estndares de
control de calidad y metodologas como UML.

El resultado es estructura mal diseada, mala codificacin, una lgica
inadecuada, una escasa documentacin de los sistemas de software, y ahora
se exige que contine funcionando.

En la actualidad, la aplicacin se ha vuelto inestable, sigue funcionando,
pero cada vez que se intenta efectuar un cambio, se producen efectos
colaterales graves e inesperados. Y sin embargo, debe seguir evolucionando.

NTRODUCCN
XVII
El mantenimiento del software existente puede dar cuenta del ms del
60% de las inversiones efectuadas por una organizacin de desarrollo, y ese
porcentaje sigue ascendiendo a medida que se produce ms software.
[Pressman 1998,510] De l, tan slo un 20% se invierte en corregir errores
(bugs); el 80% restante se dedica a adaptar los sistemas existentes a los
cambios de su entorno externo, a efectuar las mejoras solicitadas por los
usuarios y a rehacer la ingeniera de las aplicaciones para su posterior
utilizacin. Se puede prever en el horizonte la existencia de organizaciones de
desarrollo de software truncadas en mantenimiento que ya no puedan producir
software nuevo porque todos los recursos disponibles se estarn invirtiendo en
el mantenimiento del software viejo.

La migracin y reingeniera de sistemas de informacin es una actividad
que absorber recursos de las tecnologas de la informacin durante muchos
aos. Esta es la razn por la cual toda organizacin necesita una estrategia
pragmtica para la migracin de sus sistemas antiguos, basada en una
metodologa moderna que contenga toda clase de controles.

NTRODUCCN
XVIII

Figura 1. Impacto de cambio en eI Software con respecto aI cambio en
Ias regIas de negocio

k
e
g
|
a
s

d
e

N
e
g
o
c
|
o
keg|as Software
Impacto de camb|o
CAM8lCS: 1ecnloglcos, ManLenlmlenLo, lnfraesLrucLura, lnLerfaz
CAM8lCS: LsLraLeglcos, Comerclales, Legales
MARCO TERCO
1
1. MARCO TERICO

1.1. Fundamentos de UML y UWE
1.1.1. Introduccin aI UML

UML (Unified Modeling Language en espaol Lenguaje Unificado de
Construccin de Modelos) es la notacin esquemtica con la que se construyen
sistemas por medio de conceptos orientados a objetos. Es un lenguaje
grfico para visualizacin, especificacin, construccin y documentacin de
componentes de sistemas de software grandes y complejos, tambin para
modelar negocios y otros sistemas que no son de software.

Especifica con notacin "orientada a objetos, cada fase de un proyecto
es visualizada a travs de diferentes diagramas y en conjunto representan la
arquitectura del proyecto. Representa una coleccin de las mejores prcticas
de ingeniera que han sido probadas completamente en el modelado de
sistemas grandes y complejos. Provee un vocabulario y reglas de
combinacin con el propsito de comunicar. Su modelado produce el
entendimiento de un sistema. Las reglas del lenguaje informan cmo crear y
leer el flujo de los modelos formados. Su vocabulario y reglas se centran en la
representacin conceptual y fsica de un sistema de forma estndar para el
diseo de software. Produce modelos explcitos que facilitan la comunicacin.
Algunas cosas se modelan mejor grficamente.
MARCO TERCO
2
UML es ms que solamente smbolos grficos, pues existe una semntica
slidamente definida detrs de los smbolos. Como lenguaje de especificacin,
significa la construccin de modelos precisos, completos y no ambiguos. En
particular, maneja la especificacin de todo el anlisis, diseo y decisiones de
implementacin que puede hacerse en la etapa de desarrollo e implantacin
de un sistema grande y complejo de software. Su utilizacin es independiente
de algn lenguaje de programacin particular y de algn tipo o caracterstica
especial de proyectos. Como lenguaje de documentacin, maneja la
documentacin de la arquitectura de un sistema y todos los detalles. ntroduce
diagramas que representan la parte dinmica de los procesos, logrando de esta
manera identificar fallas de diseo en los procesos y por consiguiente
generadoras de errores. Permite estereotipar sus elementos para que tengan
un comportamiento particular.

Para entender esta metodologa, se necesita construir un modelo
conceptual del lenguaje y ste requiere entender tres elementos especiales:
construccin de bloques bsicos en el UML, las reglas que indican cmo esos
bloques construidos se pueden interrelacionar, y algunos mecanismos comunes
que se aplican en todo el lenguaje. La construccin de bloques en el UML
se divide en tres categoras que son: cosas, relaciones y los diagramas. Las
cosas son abstracciones que estn colocadas primeramente en un modelo. Las
relaciones enlazan conjuntamente las cosas categorizndolas por dependencia,
asociacin, generalizacin o realizacin. Existen categoras de cosas en la
estructura de los modelos estticos que representan elementos conceptuales o
fsicos.

MARCO TERCO
3
1.1.2. RegIas deI UML

Reglas de semntica:
Nombres, que pueden ser de cosas, relaciones y diagramas.
Alcance, el sentido contextual que especifica a un nombre.
Visibilidad, cmo son vistos y usados, los nombres.
ntegridad, relacin entre cosas de forma apropiada y consistente.
Ejecucin, significa ejecutar o simular un modelo dinmico.

Para modelos construidos:
Generalizados, ocultar elementos para simplificar la vista.
ncompletos, algunos elementos pueden estar ausentes.
nconsistencia, la integridad del modelo no es garantizada.

1.1.3. Diagramas

Son los elementos bsicos del UML, cada uno contiene una notacin
propia. Las diferentes formas visibles de UML son compuestas por
combinaciones de diagramas, las cuales son:

Concepcin visual de casos de uso: compuesta por diagramas de,
casos de uso, colaboracin, estados y actividades.
Vista de diseo: compuesta por los diagramas de clases, objetos,
colaboracin, estados y actividades.
MARCO TERCO
4
Concepcin visual de procesos: compuesta diagramas de: clases,
objetos, colaboracin, estados y actividades, pero repasando y
afinando las clases y objetos que contienen procesos.
Concepcin visual de implementacin: compuesta por diagramas
de componentes, actividades, estados y colaboracin.
Concepcin visual de despliegue: compuesta por diagramas de
despliegue, actividades, interaccin y estados.

Existen dos tipos de diagramas para representar un sistema, los de
visin esttica y los de visin dinmica. Los diagramas de vista esttica son:
Diagrama de clases: presenta las clases, atributos y sus
respectivas relaciones. Comnmente dan la vista esttica del
proyecto.
Diagrama de objetos: presenta las instancias especficas de las
clases presentadas en el diagrama de clases y su relacin, da una
visin particular del sistema.
Diagrama de componentes: presenta la organizacin y las
dependencias de los componentes del sistema.
Diagrama de despliegue: presenta conjuntos de componentes
llamados nodos, adems sus relaciones. Reduce el detalle
complejo de los diagramas de clases y de componentes de
grandes sistemas. Resume el contenido, da una visin general del
sistema.
Diagrama de casos de uso: representa comportamientos por
medio de actores y sus relaciones. Muestra qu acciones hacen
los actores y las relaciones entre acciones. Modelan y organizan la
lgica del negocio a nivel general, la manera que se comporta el
sistema.
MARCO TERCO
5
Los diagramas de vista dinmica son:

Diagrama de secuencia y diagrama de colaboracin: representan
interaccin y colaboracin a travs del tiempo de un conjunto de
objetos, se envan mensajes entre objetos para modelar cada
mtodo.
Diagrama de estados: representa los estados de objetos, muestra
actividades y transiciones.
Diagrama de actividades: representa el comportamiento entre
objetos. tiles para representar de que manera funciona un
sistema y la fluidez de control entre los objetos.

UML proporciona un gran nmero de diagramas para detallar cunto se
requiera, algunos diagramas son ms necesarios dependiendo el tipo de
proyecto.

1.1.3.1. Diagramas recomendados

Segn el tipo de sistema por crearse se recomienda una serie de
diagramas bsica. Dependiendo de las caractersticas del desarrollo y la
experiencia, se determina los diagramas necesarios.
Aplicaciones locales:
Casos de uso.
Clases.
nteraccin.
MARCO TERCO
6
Aplicaciones orientadas a eventos:
Agregar: Diagrama de estados.
Aplicaciones Cliente-Servidor (segn complejidad):
Agregar: Diagrama de componentes
Agregar: Diagrama de despliegue
Aplicaciones distribuidas:
Todos.

Por lo tanto, para modelar aplicaciones sencillas, se necesita de tres a
seis tipos de diagramas, y para modelar aplicaciones complejas,
aproximadamente nueve tipos de diagramas. La mayora de aplicaciones no
complejas necesitan a lo sumo cuatro tipos de diagramas. UML est capacitado
para modelar pequeos sistemas y tambin sistemas complejos. Los sistemas
complejos representarn cantidades millonarias de lneas de cdigo,
generadas por grandes equipos de programacin, que dependen del nivel de
detalle especificado en dichos diagramas.

1.1.4. Introduccin a UWE

UWE (UML Web Engineering, en espaol ngeniera Web basada en
UML) es una metodologa que permite especificar de mejor manera una
aplicacin Web, para el proceso de creacin de aplicaciones detalla sta, con
una gran cantidad de definiciones, en el proceso de diseo lista qu debe
utilizarse. Procede de manera iterativa e incremental, coincidiendo con UML,
incluyendo flujos de trabajo y puntos de control.
MARCO TERCO
7
UWE se especializa en la especificacin de aplicaciones que se adaptan,
y por eso hace nfasis especial en las caractersticas de personalizacin, y la
definicin de los modelos de usuario o en un patrn de caractersticas de
navegacin basado en preferencias, tareas o conocimiento. Otros aspectos de
inters de la metodologa UWE es la orientacin a objetos, usuarios y la
definicin de un modelo de referencia que da soporte a la metodologa y
formaliza los modelos por el grado de restricciones y definiciones que
proporciona.

1.1.4.1. Caractersticas principaIes

Se basa en las caractersticas principales siguientes:
Notacin estndar: el uso de la metodologa UML para todos los
modelos.
Mtodos definidos: pasos definidos para la construccin de cada modelo.
Especificacin de restricciones: recomendables de manera escrita, para
que la exactitud en cada modelo aumente.

1.1.4.2. Fases de desarroIIo

Con respecto al proceso de creacin de la aplicacin, UWE se vale
mediante el uso de metodologas estndares reconocidas como UML
principalmente y tambin del lenguaje de especificacin de restricciones
asociado OCL (Object Constraint Language, en espaol Lenguaje de
restricciones para objetos).
MARCO TERCO
8
Para recolectar los requerimientos necesarios de las aplicaciones web, esta
metodologa propone una ampliacin utilizada en el proceso de creacin, la cual
se divide en las siguientes cuatro actividades:
Anlisis de requisitos: plasma los requerimientos funcionales de la
aplicacin Web, mediante modelos de casos de uso.
Diseo conceptual: se define mediante un modelo de dominio,
considerando los requisitos plasmados en los casos de uso, el diagrama
de clases representar los conceptos con un gran porcentaje de detalle.
Diseo navegacional: Comprende la construccin del modelo de
navegacin en dos pasos:
Modelo de espacio de navegacin: su objetivo es especificar qu
objetos pueden ser visitados a travs de la aplicacin.
Modelo de estructura de navegacin: ampla el modelo con un
conjunto de estructuras de acceso necesarias para la navegacin
como los ndices, consultas y visitas guiadas.
Diseo de presentacin: permite la especificacin lgica de la aplicacin
Web. Basada sobre este modelo lgico, una representacin fsica puede
ser construida. Representa las interfaces del usuario por medio de vistas
estndares de interaccin UML. Dentro de este modelo se distinguen dos
diferentes vistas:
Estructura de vista: muestra la estructura del espacio de
presentacin.
nterfaz de usuario (U por sus siglas en ingls de User Interface):
Vista que presenta detalles acerca de los elementos de la interfaz
de usuario dentro de las pginas.

MARCO TERCO
9
1.2. Reingeniera de software

Reingeniera significa redisear algo de manera radical, empezar de
nuevo, arrancando sin nada. Proporcionar al cliente ms con menos, no
significa hacer ms con menos. El objetivo es hacer mejor lo que ya se est
haciendo, trabajar mejor de manera inteligente, e integrar y redisear procesos
aislados. De esta manera las compaas retoman la eficiencia que han perdido
en operaciones. Dicho de otra manera la reingeniera es la revisin a los
fundamentos, que establece reformas extremas, con el fin de alcanzar una
espectacular mejora en medidas difciles de rendimiento, relacionadas con
costos, calidad, servicio y rapidez.

La reingeniera de software es reorganizar y modificar sistemas de
software existentes, es aplicable a los subsistemas que frecuentemente
requieren mantenimiento. La reingeniera agrega esfuerzo para que sea ms
fcil el mantenimiento del sistema. Comprende la re-documentacin,
reorganizacin y reestructura del sistema, traduccin del sistema a un lenguaje
de programacin ms moderno, actualizacin de estructura y adaptacin de
valores de datos existentes. La funcionalidad del sistema permanece igual,
regularmente no se cambia y normalmente con la arquitectura se trata que
permanezca igual.

Desde un punto de vista tcnico, la reingeniera de software se considera
una solucin alternativa y poco recomendable para los problemas de evolucin
de sistemas.
MARCO TERCO
10
El software arquitectnicamente no cambia mucho, pues regularmente no
se actualiza y esto hace difcil descentralizar los sistemas centralizados y
hacerlos distribuidos. Generalmente, es difcil cambiar radicalmente el lenguaje
de programacin, ya que la funcionalidad de algunos lenguajes limita la
descomposicin de los problemas en objetos, eventos y funciones, como otros
lenguajes.

Desde un punto de vista de negocios, la reingeniera de software es una
solucin viable para continuar con el servicio de los sistemas, muchas veces es
costoso y difcil tomar un enfoque para la evolucin de los sistemas. Se debe
aplicar la reingeniera cuando el soporte empieza a ser obsoleto y mientras las
herramientas de reestructuracin estn disponibles, si en la reestructuracin el
mantenimiento tiende a corromper la estructura de un programa, entonces se
dificulta entender el sistema.

La reingeniera de datos puede ser necesaria debido a la inconsistencia
de puntos de vista en la administracin de datos. Si se convierten los datos, los
costos de reingeniera se incrementan de manera notable. La reingeniera
reduce el riesgo de inconsistencia, pero cuando se vuelve a desarrollar el
software de una empresa, es una actividad crtica que aumenta el riesgo
operativo del negocio.

La reingeniera reduce los costos a largo plazo, pues segn estudios
sugieren que el costo de sta es menor que el costo de hacer de nuevo un
sistema totalmente en una comparacin de cuatro a uno.

MARCO TERCO
11
El proceso de la reingeniera de software comprende varias actividades
principales, las cuales son:
Traduccin de cdigo fuente, conversin de un lenguaje de programacin
antiguo a una versin ms actual u otro lenguaje diferente.
ngeniera inversa, analiza los programas extrayndoles informacin de
su organizacin para documentarla.
Mejora de la estructura del programa, es la reestructuracin de los
programas para una mejor organizacin comprensible.
Modularizacin del programa, es la forma de agrupar las partes
relacionadas de los programas eliminando la redundancia.
Reingeniera de datos, cambio de los datos segn las nuevas estructuras
de datos.

En el proceso de traduccin de cdigo fuente no debe cambiar la
estructura y organizacin del programa. La traduccin es conveniente hacerla
por etapas debido a la actualizacin de arquitectura, la falta de personal
capacitado en el lenguaje original, por los cambios en las polticas
organizacionales, para minimizar costos con cierto lenguaje, la falta de soporte
para determinado software. La traduccin del cdigo fuente es conveniente
econmicamente solo si se dispone de un traductor automtico para una
cantidad grande de traducciones. En varios casos es imposible hacer
traducciones automticas, pues las estructuras antiguas no tienen equivalente
directo en el lenguaje nuevo, en estos casos hay que manipular los cambios
haciendo los ajustes necesarios. La modularizacin comprende la
reorganizacin del programa de forma que las partes sean agrupadas por las
relaciones que ms convenga. Este proceso se puede hacer por abstracciones
de datos, por la funcionalidad de procedimientos que llevan a cabo tareas
relacionadas, o por modelos auxiliares para apoyar los procesos del negocio.
MARCO TERCO
12
La reingeniera de datos analiza y reorganiza las estructuras, y cundo
es necesario los valores. Prcticamente los datos se deben modificar por, la
degradacin de calidad de datos con el tiempo, lmites no coherentes en los
programas con la actualidad, evolucin en la arquitectura adoptada, puesto que
las arquitecturas trabajan la distribucin de datos de manera diferente.

1.3. Ingeniera inversa

Es el proceso que tiene como entrada cdigo fuente y obtiene como
resultado una descripcin de ms alto nivel, con el fin de recuperar el diseo y
la especificacin. Regularmente el cdigo es la entrada para este proceso,
aunque en ocasiones no existe y se debe hacer desde el cdigo ejecutable. La
aplicacin de este concepto est asociada al desarrollo de grandes sistemas o
a la produccin industrial de software, lo cual significa una mejora notable para
mantener la competitividad del mercado.

Se debe tomar en cuenta que la ingeniera inversa no persigue el mismo
objetivo con la reingeniera, puesto que la ingeniera inversa se centra en
derivar el diseo o la especificacin de un sistema a partir de su cdigo fuente,
y la reingeniera busca producir un sistema nuevo de fcil mantenimiento.
Durante la reingeniera es necesaria la ingeniera inversa para recuperar el
diseo de los programas del sistema y comprender lo que se tiene para su
reorganizacin y reestructuracin, aunque no siempre necesita seguirse de la
reingeniera.

MARCO TERCO
13
Es un trabajo a largo plazo, estas actividades, estn orientadas para
mejorar el mantenimiento. La productividad depende de cuanta mejora se logre
en la reduccin de recursos en este tipo de tarea, siendo este el objetivo
principal de la reingeniera. Analizar el cdigo fuente, el diseo actual y
modificarlo, manualmente o mediante herramientas, para convertir a cdigos
mejor estructurados y ms eficientes.

El proceso comienza con la etapa de anlisis, donde el sistema se
analiza a travs de herramientas para descubrir su estructura, aunque esto no
es suficiente para reconstruir el diseo, ya que los ingenieros necesitan el
modelo estructural y el cdigo fuente para comprender el sistema. Se usa esta
informacin en un grafo dirigido que se vincula al cdigo fuente del programa.
Por medio del grafo se genera documentacin de varios tipos como diagramas
de los programas, de las estructuras de datos, tambin matrices de rastreo, que
sirven para definir entidades y los destinos de sus referencias. Despus de
generar los documentos de diseo, se almacena ms informacin al repositorio
del sistema, la cual ayudar a la reconstruccin del mismo, esto implica tomar
varias notas de las estructuras.

1.4. Migracin de sistemas

En cualquier proceso de diseo, es normal tomar decisiones importantes
y afinarlas. Las opciones que se elijan mientras se planea la migracin pueden
hacer que demore la distribucin de algunas de las caractersticas del sistema
hasta una fecha posterior.
MARCO TERCO
14
Los pasos para crear una gua bsica de migracin consiste en identificar
y dar prioridad a los objetivos de la migracin, y comprender qu implican las
opciones elegidas. Al optar por migrar a un sistema nuevo, sin duda se ha
identificado ciertas caractersticas y ventajas que se estar deseando aplicar

1.4.1. Objetivos de migracin

Deben verse reflejados los objetivos de la migracin en su diseo. Los
objetivos pueden ser en funcin del negocio o de la migracin misma.
Comnmente los objetivos relativos al negocio impulsan la decisin de
migracin inicial. Una muestra de objetivos de la migracin la constituye una
mayor escalabilidad y mejora en la seguridad. Los objetivos en funcin del
negocio estn contenidos en la toma de decisiones de implementacin y
pueden utilizarse para evaluar posibles compromisos. Generalmente, se
prepara una tabla de conformidad, que en etapas posteriores se emplea para
identificar las tecnologas y caractersticas del producto que se va a
implementar en la plataforma final. Estas tecnologas y caractersticas ayudarn
a lograr los objetivos relativos al negocio.

Los objetivos con respecto a la migracin incluyen aspectos como el
efecto de la interrupcin en sistemas de produccin, el rendimiento del sistema
y las maneras de aumentar la media de tiempo entre errores. Estos objetivos
determinan cmo se formularn los planes de pruebas y criterios de aceptacin.
No estn dirigidos por la necesidad de implementar caractersticas tcnicas
especficas de herramientas de desarrollo.

MARCO TERCO
15
1. 5. ApIicacin web

"Sistema de informacin que contiene grandes cantidades de datos, con
un grado alto de estructuracin, procesado y analizado por medio de
navegadores valindose del protocolo HTTP (Hyper Text Transfer Protocol).
Actualmente se maneja el mismo concepto en la comunicacin cliente-servidor
(navegador webserver) slo que no necesariamente el resultado de la
comunicacin debe provenir de la carga de una pgina esttica. Esta puede ser
el resultado de la ejecucin en el servidor de alguna lgica de programacin.
Esto ltimo no necesariamente se llama una aplicacin Web, pero se acerca al
concepto. Considrese una aplicacin Web a un sitio Web donde la navegacin
a travs de l y la entrada de datos por parte de un usuario, afectan el estado
de la lgica del negocio. Esencialmente, una aplicacin Web utiliza un sitio Web
como entrada (front-end) a una cierta aplicacin. [1]

Una aplicacin Web necesariamente debe contener lgica del negocio en
el servidor, de lo contrario no se cataloga como tal. Bajo este concepto una
aplicacin Web no solamente despliega informacin, tambin soporta la lgica
de algn proceso operativo del negocio. Un aspecto importante es la gran
interaccin con el usuario, por lo tanto el diseo de la interfaz con el usuario
debe ser sencillo, claro y estructurarse de manera que oriente a cualquier
usuario.

MARCO TERCO
16
1.5.1. Caractersticas

Entre los aspectos que caracterizan las aplicaciones Web de otras
aplicaciones de software, se categorizan por tres puntos de vista:
Usuario: debe ser fcil de usar y acceder, tanto para usuarios expertos o
usuarios sin experiencia, ya que no se sabe el tipo y el nmero de estos.
Plataforma: por el uso de red y las conexiones, se intensifica y es
accedida desde diferentes tipos de dispositivos.
nformacin: pues ayuda en la disponibilidad global de fuentes de diversa
naturaleza de informacin, de diferentes dominios y asiste en la finalidad
de la aplicacin.

1.5.2. Tipos

La clasificacin se puede realizar bajo ciertos criterios, como la
complejidad de la aplicacin, la complejidad de datos, estructura de datos,
volatilidad, o la finalidad de la aplicacin. La siguiente clasificacin se basa en la
finalidad de la aplicacin:
nteractivas: interaccin con el usuario netamente.
Transaccionales: banca electrnica, compra electrnica.
Servicio: orientadas al servicio, ej. Asistencia financiera, simuladores.
Portales: intermediarios en lnea, centros comerciales de compra
electrnica.
nformacionales: difusin de informacin, independiente de
personalizacin.
MARCO TERCO
17
Descarga datos: orientadas a la disponibilidad de material en servidores.
Comunidades: servicio de subastas, foros de debate.
Anlisis de datos: aplicaciones OLAP( por sus siglas en ingls de On-
Line Analytical Processing), Datawarehousing.

1.5.3. Condiciones para eI desarroIIo

Se debe tomar en cuenta estos requisitos para la correcta
implementacin.
Calidad: evitar errores puesto que la tolerancia del usuario en este
aspecto es muy limitada, informacin desactualizada o enlaces errneos
hacen perder la confianza del usuario en la aplicacin. Por lo tanto, es de
suma importancia el control que minimice dicho fracaso.
Velocidad: considerar las condiciones de rendimiento de tecnologa y
telecomunicaciones, para que soporten la concurrencia y frecuencia de
uso de la aplicacin.
Portabilidad: es necesario considerar el entorno cambiante y los avances
de la tecnologa, para que las implantaciones de una aplicacin
funcionen en distintas plataformas, tomando en cuenta la reutilizacin de
cdigo y la independencia de este por medio de marcos de trabajo.
Seguridad: tomar en cuenta que este tipo de aplicacin est expuesta
ante todo tipo de usuario a travs de la web, y para ello la transmisin de
informacin debe protegerse a travs de mtodos seguros.
nterfaz: para la presentacin de la informacin se debe tomar muy en
cuenta el diseo, para captar la atencin del usuario y que sea fcil de
entender y usar para que la intuicin sea la gua.
MARCO TERCO
18
Personalizacin: tomar en cuenta la individualizacin del usuario en el
diseo como valor aadido, actualizndose constantemente, pues el
usuario utiliza gran variedad de aplicaciones y es necesario mantenerle
un perfil.
ntegracin: el manejo de contenidos de distintos formatos, estructuras y
ubicaciones, es un requisito a tomarse en cuenta.
Desarrollo rpido: el modelo de implantacin regularmente para este tipo
de aplicaciones es inmediato, debido al tiempo reducido influyente en el
ciclo de desarrollo y necesidad de dependencia del usuario hacia ms
funcionalidades.

1.6. Sistemas de informacin centraIizados

"A principios de los aos 80, el procesamiento de la informacin de
manera computarizada estaba estrictamente centralizado. Las principales
caractersticas de la centralizacin eran las siguientes:
Uso de una computadora principal (mainframe). Normalmente un gran
ordenador (BM System 9000) o una minicomputadora (VAX). En
trminos de estructura de la compaa, una unidad era responsable del
mantenimiento de dicha computadora mientras sus recursos estaban
disponibles para el resto del personal. A esta unidad se la llamaba
unidad de informtica o centro de clculo.
Procesamiento centralizado de la informacin. Todos los procesos y
clculos son ejecutados por el ordenador principal. Los diferentes
departamentos tienen terminales conectados a este ordenador
mainframe.
MARCO TERCO
19
Centralizacin de la informacin. La informacin es almacenada en
dispositivos de almacenamiento bajo el control del mainframe.
Control centralizado. El administrador del sistema es el nico
responsable del procesamiento de la informacin del sistema. El
administrador autoriza el acceso de los usuarios, es responsable del
funcionamiento, soporte y seguridad diaria del sistema.
Servicio centralizado. El hardware y el software estn mantenidos por el
personal del centro de informtica. Los otros departamentos no tienen
tcnicos informticos. [2]

"Entre las principales ventajas de los sistemas centralizados se pueden citar
las siguientes:

Fciles de manejar.
mplican menos costes de personal.
Un ordenador es suficiente para soportar diferentes sistemas de
informacin en una nica compaa.
Asignacin de nombres uniforme (de usuarios, de ficheros, de servicios).
La localizacin de los objetos no es un problema.
El acceso y la seguridad se controlan uniformemente en todo el sistema.
La gestin y administracin puede hacerse de forma centralizada.

En resumen, los sistemas centralizados se caracterizan por su:

Accesibilidad. Cualquiera puede usar todos los recursos.
Coherencia. Todo funciona de igual forma en todas partes.
Gestin centralizada. nico dominio de gestin.
MARCO TERCO
20

Actualmente, rara vez se encuentra una situacin en la que sea
justificable una centralizacin del estilo de lo descrito anteriormente. Solo tiene
sentido hablar de centralizacin a nivel de datos o de servicios cuando por su
naturaleza es mejor tenerlos centralizados. De todas formas, ahora es bastante
habitual tener lo que se ha venido en llamar clientes ligeros o thin clients en
ingles, que son terminales de bajo coste, sin disco duro y otros recursos, pero
con capacidades multimedia y que estn conectados a un ordenador central
ms potente. En algunas situaciones en las que se desea, que un ordenador se
utilice para un conjunto acotado de aplicaciones, puede ser una opcin
econmica e interesante a tener en cuenta. [2]

ANLSS Y REDSEO DEL SSTEMA CENTRALZADO USANDO UML
21
2. ANLISIS Y REDISEO DEL SISTEMA CENTRALIZADO
USANDO UML

2.1. AnIisis deI sistema actuaI con ingeniera inversa

En esta seccin se presenta el proceso de la ingeniera inversa y algunos
de sus campos necesarios para obtener una representacin estructural y
generar la documentacin necesaria para realizar un diseo propio y realizar la
reestructuracin. Los campos del proceso de ingeniera inversa dependen del
trabajo que se est realizando y de los profesionales que estn a cargo, por ello
aqu se muestran slo las secciones necesarias bsicas para este tipo de
trabajo aunque se puede llegar a un nivel de detalle ms profundo si los
profesionales a cargo lo necesitan.

Este proceso busca recuperar las cualidades y secretos del sistema en
cuestin, en este caso del sistema centralizado a partir del cdigo fuente
disponible para recuperar el respectivo diseo. En la actualidad se cuenta con
herramientas de tipo CASE (Computer Aided Software Engineering, en espaol
ngeniera de software asistida por un computador), que extraen la informacin
a partir del cdigo con cierta dependencia de un experto, la informacin que
recupera se refiere a procedimientos, estructura de arquitectura y datos.
22
Aunque la aparicin de multitud de herramientas facilita las labores de la
ingeniera inversa, es labor humana la decisiva a la hora de completar el estudio
del sistema.

Muchas veces se cuenta slo con el cdigo fuente para estos sistemas
centralizados, aunque en algunos casos se tiene cierta informacin de la
estructura, tanto como algn diseo no actualizado de la base de datos, una
descripcin incompleta de los atributos y tablas, algn manual de usuario de las
primeras versiones, y algunos documentos sobre cul debi haber sido el
funcionamiento del actual sistema, todo esto puede ayudar en cierta manera a
tener una visin general del sistema que se analizar.

Tomando en cuenta los sistemas obsoletos y descuidados, la ingeniera
inversa se aplica para los sistemas que cuentan regularmente con las
siguientes caractersticas:
Programacin sin estructura y programas muy extensos.
Programas que no cuentan con una documentacin interna. Si tienen
documentacin interna no est actualizada y no se entiende.
Documentacin general no existe o es obsoleta.
La funcionalidad de la aplicacin no cubre todos los requerimientos
esperados.

Para iniciar el anlisis del sistema centralizado que se desea estudiar, en
primer lugar se debe organizar el cdigo fuente, el cual no posee alguna
estructura para que su lectura sea ms fcil, y la aplicacin de la ingeniera
inversa pueda iniciar bien.
23
La actividad basada en la extraccin de abstracciones es el corazn
mismo de la ingeniera inversa. El analista debe evaluar el programa antiguo y
partiendo del cdigo fuente que regularmente no est documentado, debe
extraer una especificacin vlida para el proceso de investigacin y anlisis que
se est realizando, adems debe extraerse las estructuras de datos que se
utilizan y la interfaz de interaccin con el usuario.

Adems juntamente con la extraccin de abstracciones se produce
documentacin retroactiva desde el sistema existente, como parte de la
investigacin que lleva a cabo la ingeniera inversa, desde la escasa
documentacin interna del cdigo fuente y comentarios dentro del mismo hasta
la misma que genera con cada abstraccin adquirida.

2.1.1. Especificaciones funcionaIes deI sistema actuaI

Para comprender el procesamiento del sistema antiguo, primero la
ingeniera inversa inicia por comprender abstracciones obtenidas de los
procedimientos representados por el cdigo fuente. El anlisis de cdigo se
hace mediante niveles de abstraccin, los cuales son: sistema, programa,
componente, configuracin y sentencia.

Antes que nada se debe establecer un contexto, mediante la perfecta
comprensin de la funcionalidad general de todo el sistema que se dispone
para iniciar con el trabajo a detalle de la ingeniera inversa.
24
Este contexto es necesario para proporcionar la solucin a los problemas de
aplicacin en el sistema.

Una abstraccin del funcionamiento con lujo de detalles se tiene inmersa
en cada programa; slo se debe buscar y comprender. Se debe conceptualizar
las iteraciones de las abstracciones obtenidas por bloques, visualizndose por
medio de diagramas de comportamiento. Las funciones dentro del cdigo
fuente representan definiciones de procedimientos funcionales. Por medio de
las abstracciones obtenidas tambin se obtienen modelos y con ellos
especificaciones del sistema. En la bsqueda de procedimientos funcionales
que representen procesos generales, existen secciones auxiliares de cdigo
que vuelven engorrosa la comprensin del flujo bsico. Para ello se deben
segmentar los programas para identificar secciones significativas del
procedimiento general y aislar lo que no sirve, para formar segmentos
funcionales significativos.

2.1.2. Esquema Igico de datos

Para comprender la parte esttica del sistema es preciso aplicar la
ingeniera inversa a las estructuras de datos internas en los programas para la
comprensin de las estructuras globales. A partir del anlisis de las estructuras
internas de los programas se inicia la definicin de clases, por medio de
agrupaciones de variables relacionadas, con esto tambin se identifican los
tipos abstractos de datos.

25
(Breuer 1991.145) enumera una serie de pasos para determinar las
clases dentro del programa que interactan con las estructuras globales.
1. Se identifican los indicadores y estructuras de datos locales dentro del
programa que registren informacin importante acerca de las estructuras
de datos globales.
2. Se define la relacin entre indicadores y estructuras de datos locales y
las estructuras de datos globales
3. Para toda variable (perteneciente al programa) que represente una
matriz o archivo, se enumeran todas las dems variables que tengan una
relacin con ella.

Las bases de datos generalmente permiten establecer las relaciones que
existen entre los objetos no importando su organizacin lgica y su
estructura fsica. Para la definicin de un modelo de datos base, se puede
seguir los pasos definidos por [Premerlani, 1994.42]
1. Se construye un modelo de objetos inicial. Las clases definidas como
parte del modelo, se pueden conseguir mediante la revisin de
registros de una base de datos de archivos planos o de tablas de un
esquema relacional. Los objetos contenidos en los registros o tablas
pasarn a ser atributos de clases
2. Se determinan los candidatos a claves. Se examinan los atributos
para determinar si se utilizarn o no para sealar a otro registro o
tabla. Aquellos que sirvan como punteros pasarn a ser candidatos a
claves.
3. Se refinan las clases tentativas. Se determina si ciertas clases
similares pueden o no combinarse en una nica clase.
4. Se descubren las asociaciones. Mediante el uso de tcnicas
anlogas al enfoque de clases, responsabilidades y colaboraciones
26
2.2. Esquema conceptuaI y modeIado visuaI con UML

Es la explicacin de los conceptos significativos abstrados para el
dominio del problema, que mediante el sistema con que se cuenta se presenta
una solucin. En esencia, lo que un esquema conceptual debe ofrecer es la
representacin de cosas reales, no necesariamente componentes de software.

Esto se puede representar en UML con un grupo de diagramas tanto
para la parte esttica como para las operaciones que definen el comportamiento
o sea la parte dinmica. Para ello muestra conceptos, asociaciones entre
conceptos y atributos de los conceptos. La creacin del esquema conceptual
ayuda a descubrir y conocer la terminologa del dominio del problema,
modelando la comunicacin y relacin entre los trminos importantes.

2.2.1. La vista esttica

La parte esttica del modelo que se abstrae por medio de la ingeniera
inversa, se refiere al conjunto de elementos que tienen conceptos que significan
algo en la aplicacin en proceso de anlisis. sta describe entidades de
comportamiento como elementos de modelado discreto, pero no contiene los
detalles de su comportamiento dinmico, los cuales solo se nombran, refieren o
muestra la dependencia de la clase. Por lo tanto, los objetos y sus relaciones
son los elementos esenciales de este anlisis. Esta vista es la base sobre la
cual se construye la vista dinmica.
27
Aqu se captura la estructura de los objetos abstrados en la ingeniera inversa,
aunque en esta vista se incluye lo que se refiere a las estructuras de datos
tradicionales, y se enumeran las operaciones sobre los datos, prcticamente la
fase de especificacin. De esta manera, partiendo de estas unidades discretas
de informacin de la arquitectura que se dispone, el diseador puede iniciar la
reestructuracin donde sea necesaria. Con UML se puede representar
diagramas de estructura esttica que explican grficamente el modelo
conceptual. Los conceptos se pueden considerar como ideas, cosas u objetos
de una manera informal, representados formalmente a partir de su smbolo,
intensin (definicin) y extensin (instancia).

Figura 2. VisuaIizacin deI concepto

Venta
Fecha
Hora
Smbolo del concepto
Una venta representa el
evento de una transaccin de
compra. Tiene fecha y hora
ntensin del concepto
Venta-1
Venta-2
Venta-3

Venta-4
Extensin del concepto
28
2.2.1.1. Identificacin de conceptos

Una estrategia vlida para enfrentar la complejidad de un problema es la
descomposicin en unidades comprensibles. A partir del anlisis estructurado
tradicional del sistema dado, mediante procesos y funciones, se identifican
varios conceptos del dominio del problema y se documentan los resultados en
el esquema conceptual. No se debe pensar que entre menos conceptos se
manejen mejor ser la representacin del modelo, por el contrario es mejor
detallar ms, para especificar un esquema conceptual.

Otra estrategia es identificar los conceptos por medio de categoras
propias del dominio del problema, y tambin mediante la identificacin de frases
nominales en la especificacin de los casos de uso. Pasos para construir un
esquema conceptual
Realizar una lista de conceptos adecuados a partir de una lista de
categoras y de identificaciones de frases nominales.
Graficar los conceptos.
Agregar asociaciones para representar relaciones.
Adicionar los atributos necesarios para satisfacer las necesidades
requeridas.

Debe considerarse prcticamente que un modelo conceptual no es del
todo correcto ni errneo, sino que es una herramienta de comunicacin.

29
2.2.1.2. Definicin en UML deI modeIado conceptuaI

Para asociar y definir el modelo conceptual desde el punto de vista de
anlisis y diseo, se debe considerar que el trmino concepto equivale al de
cIase y tipo para la notacin de modelado, y partiendo desde especificaciones
obtenidas de un sistema existente o sea desde un punto de vista de
implementacin lo ms correcto es modelar las estructuras abstradas por la
ingeniera inversa desde el punto de vista de diseo o sea clases, las cuales
representan los conceptos con un poco ms de detalle en cuanto a atributos,
operaciones, mtodos y relaciones.

2.2.1.2.1. Las asociaciones

Son las relaciones significativas entre dos clases, que pueden ser
comunes o eventuales pero que se preservan y son reconstruidas en el tiempo.
En el modelado visual se representa como una lnea entre conceptos con el
nombre de la asociacin, en sentido bidireccional. En los extremos puede
incluirse una expresin de multiplicidad que indica las instancias de la clase. Se
puede indicar el sentido de lectura con una flecha de direccin sin sentido
semntico.

Es ms importante identificar conceptos que asociaciones, ya que
algunas asociaciones tienden a confundir en vez de aclarar. No incluir
asociaciones redundantes ni derivables.
30
Asignacin de nombre a una asociacin basada en el formato NombreDeTipo-
Frase nominal-NombreDeTipo.

Las asociaciones que se necesitan conocer son las que facilitan la
comprensin, debe verse el modelo como una herramienta de comunicacin,
con la cual se busca entender los conceptos importantes y sus relaciones. Se
puede eliminar algunas asociaciones que no encajen y que produzcan un
modelo inadecuado.

Figura 3. Asociacin y muItipIicidad

2.2.1.2.2. Los atributos

Son valores lgicos de datos de objetos. Es necesario identificar los
atributos de los conceptos que se necesitan para satisfacer requerimientos de
informacin, de los casos de uso respectivos. Los tipos primitivos de datos en
la prctica suelen ser los atributos ms simples, los cuales son los preferibles
en un esquema conceptual.

Tienda Producto
Almacena

1 *
Asociacin
(relacin de izq a der,
de 1 a muchos)
31
Figura 4. Concepto y atributos

Para representar entonces el esquema conceptual, se hace uso de un
diagrama de clases que facilitan las representaciones a partir de las cuales se
puede iniciar la reestructuracin del sistema que se desea migrar. Estos
diagramas colaboran en la tarea de anlisis, permite al analista una
retroalimentacin ms directa con el cliente en su propia terminologa, lo cual
hace posible recabar requerimientos detallados para comprender y transformar
el sistema en estudio.

Figura 5. ConceptuaIizando procedimientos

Linea aerea
Persona Vuelo Avion
1

Emplea

1..*
Asignado-a
1 *
Asignado-a
1 *

1 *

Supervisa
Venta
Fecha
Horanicial:Hora
Atributos
32

REDSEO DEL SSTEMA DE NFORMACN CON UWE
33
3. REDISEO DEL SISTEMA DE INFORMACIN CON UWE

3.1. Diseo conceptuaI con UWE

Ya se tiene el esquema conceptual del actual sistema, ahora debe
hacerse una redefinicin de lo que realmente se necesita, lo cual debera tener
el funcionamiento y no se ha podido incluir. Por lo tanto se necesita disear un
modelo conceptual, incluyendo el modelo obtenido del sistema actual, tomando
en cuenta las propiedades de la nueva arquitectura de software. El diseo
conceptual pretende definir claramente el problema que se debe solucionar y
elaborar una solucin para el mismo, en trminos que tanto los administradores
como los usuarios puedan entender.

El modelado proporciona una visin ms amplia del problema, ms que
limitarse a enumerar los requisitos. Tambin se trata de mantener esos
requisitos en contexto y tomar decisiones racionales. El diseo conceptual
captura las tareas y la informacin esencial necesaria, de las actividades del
negocio, dando como resultado una visin de la solucin, con un enfoque sobre
el proceso y centrada en los usuarios. Especifica la ubicacin, las capacidades
y las expectativas, de los usuarios. Se considera como un anlisis de
actividades y consiste en la solucin de negocios para el usuario y se expresa
con casos de uso.

34
3.1.1. PerfiIes de usuario

Para identificar a los actores del sistema como son llamados en UML, se
hace un anlisis de las personas que utilizan en la actualidad el sistema y los
roles o papeles que juegan en su interaccin con el mismo, en el desarrollo del
diseo tambin se denominan responsables. Tomar en cuenta los actores
externos que son necesarios para las interrelaciones que se tienen con ellos.

El actor representa el rol genrico de usuario del sistema, puede ser una
persona, software o hardware. El nombre que se le d, reflejar el papel que
tendr para el sistema. dentificar los actores permite:
Definir los lmites del sistema (Lo que forma parte del sistema y lo que
no).
Desarrollar un sistema dirigido al usuario que tome en cuenta todas las
funcionalidades esperadas por los diferentes actores.

Por ello se debe conocer el funcionamiento de los procedimientos reales,
para apegarse ms al proceso y modelar el comportamiento. Es como volver a
hacer el sistema desde cero, con el levantado de requisitos, pero con la ventaja
que se tiene un modelo bsico operacional el cual servir de gua y
comprensin, sobre sta ventaja girar el nuevo sistema.

35
3.1.2. Escenarios de uso

"Los escenarios de uso describen los requerimientos del sistema en el
contexto del usuario, mostrando cmo se efectan los procesos de negocios, o
cmo se deberan efectuar. Los escenarios de uso toman los datos que han
sido recolectados, y los aplica en un documento donde paso a paso se
describe qu pasa primero, luego y despus en la ejecucin de una tarea
especfica. Esto transforma los requerimientos que se han recolectado en el
contexto de cmo se usan los procesos, funciones y procedimientos.[3] Entre
los distintos mtodos para la construccin estn los siguientes.

3.1.2.1. ModeIo de proceso de fIujo de trabajo

"Es usado para crear escenarios de uso, que muestran cmo trabajos
especficos son ruteados a travs de una organizacin. Estas son las
condiciones necesarias para que el trabajo sea encaminado de un rea a otra, y
que es necesario para que un paso particular pueda darse.[3] Es necesario
definir pre y pos condiciones cuando se usa este modelo.

3.1.2.2. EI modeIo de secuencia de tareas

"Este modelo observa las series de acciones o secuencias de tareas que
un usuario efecta para completar una actividad.
36
Es posible usar este modelo con texto estructurado o no estructurado.
Dependiendo que se use, se necesita identificar el rol del usuario, y escribir el
escenario de uso este. El rol de usuario debe estar identificado en el escenario
de uso, de manera que cualquiera que lo vea pueda saber quin efecta que
actividad. [3]

3.1.2.3. EI modeIo de ambiente fsico

"Los escenarios de uso tambin son tiles para entender el ambiente
fsico en el que se desenvuelve la aplicacin. Esto se debe a que el diseo
puede ser afectado por el lugar donde la aplicacin vaya a ser usada, adems
de cmo y por qu. Este modelo observa el ambiente en el que la aplicacin va
ser usada. En este modelo, se documenta cmo las actividades se relacionan
con el ambiente fsico de la empresa. Esto permite determinar cmo los datos
se mueven a determinadas localizaciones. [3]

3.1.3. Diagrama de casos de uso

Basndose en la secuencia de tareas de los escenarios de uso, se crean
los casos de uso, de manera que se pueda tener una idea clara, de lo que se
quiere funcionalmente del sistema y de la forma en la que se realizan los
procesos.

37
Para finalizar y poder hacer la validacin del modelo conceptual se crea el
diagrama de casos de uso, donde se conjuguen todos los casos de uso en un
nico diagrama que se analiza, para ver si cumple con las especificaciones
funcionales del sistema actual. Se aplica el diagrama de casos de uso para
modelar la vista de casos de uso del sistema. Esto involucra el modelado del
contexto del sistema, subsistema, o clase, o modelado de requerimientos del
comportamiento de estos elementos.

Su importancia radica en el hecho de visualizar, especificar y documentar
el comportamiento de un elemento y hacen que el sistema sea accesible y
entendible, lo que presenta una vista externa de cmo estos elementos pueden
ser usados en el contexto.

ModeIado deI contexto deI sistema: envuelve el sistema total dentro de un
cuadro que dibuja los lmites del modelo y los actores que interactan con ste.
Aqu, los diagramas de casos de uso especifican los actores y el significado de
sus roles.

ModeIado de requerimientos deI sistema: especifica qu hace el sistema
desde el punto de vista externo. De esta forma, el diagrama de casos de uso
permite ver el sistema total como una caja negra, en el cual se puede ver las
reacciones del sistema a las cosas externas, pero no se puede ver cmo ese
sistema trabaja en el interior.

38
3.1.4. Diseo conceptuaI sobre tres capas

"La arquitectura de una aplicacin es la vista conceptual de la estructura.
Toda aplicacin contiene cdigo de presentacin, cdigo de procesamiento de
datos y cdigo de almacenamiento de datos. La arquitectura de las aplicaciones
difiere segn como est distribuido este cdigo. [4]

Los servicios "en la red operan de manera cooperativa para dar soporte
a uno o ms procesos de negocios. Una aplicacin se convierte en un conjunto
de servicios de usuario, negocios y datos que satisface las necesidades de los
procesos de negocios.[4] El diseo permite que los servicios estn disponibles
para uso general, siguiendo lineamientos de interfaz para su publicacin, la idea
es que se reutilicen y se compartan entre varias aplicaciones.

La arquitectura tres capas contienen servicios ya especificados por
capa, los cuales tienen comunicacin entre s, por medio de objetos o sea
componentes, como se muestra en el grfico siguiente.

39
Figura 6. Arquitectura de tres capas

Fuente: Diagrama de Arquitectura Windows DNA. www.msdn.com (20-12-2004)

"La arquitectura para aplicaciones distribuidas sobre nternet es un
marco de trabajo para construir una nueva generacin de soluciones de
informtica.[4]

3.1.4.1 .Capa de presentacin

Los servicios de presentacin proporcionan la interfaz necesaria para
presentar informacin y reunir datos. En esta capa se integra al usuario con la
aplicacin para ejecutar un proceso de negocios, y para ofrecer las capacidades
de transacciones requeridas se aseguran los servicios de negocios necesarios.
Estos servicios de presentacin comnmente son identificados con la interfaz
de usuario, y regularmente se encuentran en un programa ejecutable localizado
en la estacin de trabajo del usuario final. El cliente proporciona el contexto de
presentacin, generalmente un navegador de internet (browser), que permite
ver los datos remotos a travs de una capa de presentacin HTML.
40
Por medio del uso de componentes, la programacin que da acceso a
los datos en la base de datos y aplicaciones se aparta, desde el diseo y otros
contenidos de la pgina Web. Esto asegura que los desarrolladores se
enfoquen en escribir su lgica de negocios en componentes, sin la
preocupacin acerca de cmo el resultado se mostrar. Para el diseador, esto
le da libertad de usar herramientas familiares para modificar la interfaz. Los
servicios en la capa de presentacin son responsables de:
Obtencin de la informacin del usuario.
Enviar informacin del usuario, para procesarse por medio de los
servicios de negocios.
Recibir el resultado de los servicios de negocios, despus de procesarse
la informacin.
Presentar al usuario el resultado.

3.1.4.2. Capa de negocios

Los servicios de negocios son el puente entre un usuario y los servicios
de datos. Dan respuesta a las distintas peticiones, ya sean del usuario o de otro
servicio. Para ello aplican reglas de negocio por medio de procedimientos
formalizados. Los datos debern residir en la capa de datos para garantizar la
correcta aplicacin de estas reglas. Esto evitar que el usuario tenga
interaccin directa con la base de datos.

41
Las tareas de negocios estn definidas por operaciones resultantes de
los requerimientos de la aplicacin, como ingresar una orden de compra o
imprimir una lista de clientes. Las reglas de negocio se refieren a polticas que
controlan el flujo de las tareas, estas cambian con frecuencia ms que las
tareas especficas de negocio que atienden, por lo tanto, es recomendable
encapsularlas en componentes, que se separan de la lgica de la aplicacin.

Para ayudar a los desarrolladores a construir la lgica de negocio basada
en componentes de aplicaciones Web, existe un conjunto muy poderoso de
servicios que se encargan de la comunicacin en una aplicacin de tres capas.
Estos servicios estn altamente integrados unos con otros bajo un sistema
operativo, y expuestos de forma nica a travs de objetos componentes.

Los servicios en la capa de negocios son responsables de:
Recibir informacin de la capa de presentacin.
Relacionar los servicios de datos, para la ejecucin de procesos del
negocio, para el cual fue diseada la aplicacin.
Enviar los resultados procesados al nivel de presentacin.

Algunos de los servicios Web para la capa de Negocios son los
siguientes:
Servicios de componentes y transacciones
Servicios asncronos
Programacin de acceso al servidor.

42
3.1.4.3. Capa de datos

Los servicios en la capa de datos son responsables de:
Almacenamiento
Recuperacin
Mantenimiento
ntegridad

Estos servicios se acomodan para administrar base de datos relacionales,
sistemas de archivos y servidores de correo electrnico.
Para determinar necesidades, funcionalidades del producto u otras
caractersticas percibidas, durante las etapas posteriores del modelado se hace
referencia al diseo conceptual, y flexibilizar el proceso de diseo final.

3.2. Diseo Igico

Es el modelo que se construye a travs de la informacin abstrada en el
diseo conceptual, las necesidades y requerimientos del usuario son captadas
con la perspectiva de la etapa previa. Las relaciones entre elementos y
estructuras son establecidas en este diseo, desde el punto de vista de esta
etapa se identifican objetos, servicios, interfaces de usuario y estructuras de
base de datos; no importando detalles fsicos de implementacin, para que este
diseo sea completamente independiente de modelos fsicos. Entre ms detalle
el nivel de especificacin ser ms independiente del diseo conceptual, y
acercara mucho el modelo a la realidad del requerimiento obtenido del usuario.
43
Por lo tanto, el diseo lgico es el mapeo entre requerimientos de usuario
conceptualizados y los objetos y servicios de negocios.

3.2.1. Organizacin de Ias estructuras Igicas

Despus de la etapa de identificacin de objetos, es necesario organizar
todo segn servicios que estos provean y relaciones entre s. Las
consideraciones esenciales a tomarse en cuenta para disear en varias capas
son: escalabilidad, disponibilidad y eficiencia. Partiendo de estos factores
importantes cualquier elemento y relacin en el diseo deber alinearse. Con
respecto a la escalabilidad debe definirse el grado de granularidad entre los
componentes.

3.2.2. Transicin deI diseo conceptuaI aI diseo Igico

Consiste en el mapeo de objetos identificados con las reglas del negocio
a travs de la conceptualizacin obtenida del Diseo Conceptual. Regularmente
la identificacin de objetos y reglas obedecen a procedimientos muy propios del
la teora orientada a objetos. Segn el grado de granularidad que se desee as
sern los servicios que el objeto brindar. No obstante, el diseo lgico
resultante no identifica tecnologas especficas. El objetivo de esta fase es
analizar y comprender la funcionalidad de la aplicacin antes de tomar
decisiones relativas a la tecnologa.

44
Si el diseo final de la aplicacin incluye componentes personalizados,
en la fase fsica se pueden traducir directamente los componentes
correspondientes identificados en la fase lgica. Por ejemplo, si en la fase
lgica se define un objeto Users y el equipo decide que este objeto debe ser
personalizado, se repetira el diseo lgico de dicho objeto en la fase fsica.

3.2.3. Creacin deI diseo Igico

El primer paso para la creacin del diseo lgico de una aplicacin es
identificar los objetos (los componentes) que proporcionarn la funcionalidad
necesaria. A continuacin, el equipo debe identificar los comportamientos,
atributos y relaciones de cada objeto, para lo cual el equipo se sirve de los
escenarios de uso creados en la fase conceptual.

A continuacin, el equipo analiza el escenario para identificar los
aspectos fundamentales de la solucin y realizar las siguientes tareas:
dentificar los objetos del escenario.
dentificar los comportamientos de estos objetos.
dentificar sus atributos o propiedades.
dentificar las relaciones lgicas entre ellos.

Una vez que se han completado y documentado estas tareas para cada
escenario de uso, el equipo habr finalizado la fase de diseo lgico.
45
En la fase lgica regularmente UML utiliza las siguientes secciones, en las que
se describen las tareas que intervienen en la creacin del diseo lgico, se
ofrecen ejemplos de diagramas simples de UML.

3.2.3.1. Identificacin de objetos

Al analizar un escenario de uso, lo primero que hay que hacer es
identificar los objetos presentes en dicho escenario. Un objeto es, por lo
general, una entidad o proceso empresarial que aparece en el escenario de
uso. Por ejemplo, los objetos del siguiente prrafo aparecen en negrita:

El usuario (User) selecciona un catIogo (Catalog) en el que realiza
bsquedas. Aparecern las categoras (Categories) y productos (Products)
de la raz del catlogo seleccionado. El usuario podr elegir entre ver los
detalles de un producto (Product) determinado o seleccionar una categora y
ver sus productos y subcategoras.

En este escenario se utilizan los siguientes objetos:
User
Catalog
Categories
Product
Products

La siguiente
especificados en este ejemplo:

Estos cinco objetos constituyen
en determinadas situaciones, es necesario disponer de objetos adicionales para
que el escenario funcione, aunque dichos objetos no aparecen de forma
especfica en el escenario. Estos objetos adicionales se pueden id
examinando los comportamientos sin objetos aparentemente asociados. Para
identificar estos objetos, es necesario, en primer lugar, identificar los
comportamientos.

Una vez que se ha identificado
paso es identificar sus comportamientos correspondientes, tambin
denominados
objetos, es necesario evaluar, en primer lugar, las acciones que tiene
el escenario. Por ejemplo, las acciones del siguiente prrafo aparecen en
negrita:
Aparecern
siguiente figura muestra
comportamientos.
3.2.3.2
denominados mtodos
El usuario
Aparecern las categoras y productos de la raz del catlogo seleccionado.
figura muestra

3.2.3.2. Identificacin de Ios comportamientos
mtodos o servicios
El usuario seIecciona
las categoras y productos de la raz del catlogo seleccionado.
REDSEO DEL SSTEMA DE NFORMACN CON
46
figura muestra un diagrama de UML que ilustra los objetos
Figura 7.
Estos cinco objetos constituyen la base de este escenario. No obstante,
Identificacin de Ios comportamientos
Una vez que se ha identificado el conjunto obvio de objetos, el siguiente
servicios. Para identificar los comportamientos de los
seIecciona un catlogo en el que realiza
46
diagrama de UML que ilustra los objetos
Objetos
la base de este escenario. No obstante,
el conjunto obvio de objetos, el siguiente
Para identificar los comportamientos de los
un catlogo en el que realiza
un catlogo en el que realiza
especfica en el escenario. Estos objetos adicionales se pueden identificar
objetos, es necesario evaluar, en primer lugar, las acciones que tienen lugar en
un catlogo en el que realiza bsquedas.

entificar
n lugar en
bsquedas.

El usuario podr
seleccionar una categora y
el usuario selecciona un catlogo. La figura es un diagrama de UML que ilustra
el objeto

asociados aparentes deben derivar del escenario. Por tanto, debido a que el
usuario selecciona un catlogo, deb
permita seleccionar un catlogo de una lista de catlogos. Lgicamente se
podra entonces asumir la existencia de un objeto
administra la coleccin de objetos
la lista de objetos definida.
puede definir la primera accin como
pertenece al objeto
una de las oracion
y sus comportamientos asociados.

El usuario podr
el objeto User

Como se mencion anteriormente, los comportamientos sin objetos
pertenece al objeto
una de las oracion

El usuario podr eIegi
ser con el comportamiento
Figura
pertenece al objeto Catalogs
una de las oraciones del escenario hasta identificar todos los objetos necesarios
eIegir entre ver
seleccionar una categora y ver sus productos y subcategoras.
con el comportamiento
Figura 8. Comportamiento deI objeto
la lista de objetos definida. Una vez que se ha definido el objeto
Catalogs. A continuacin, se debe seguir evaluando cada
es del escenario hasta identificar todos los objetos necesarios
47
ver los detalles de un producto determinado o
sus productos y subcategoras.
con el comportamiento Select
Comportamiento deI objeto
usuario selecciona un catlogo, deber existir un tipo de mecanismo que
administra la coleccin de objetos Catalog
Una vez que se ha definido el objeto
puede definir la primera accin como Select
A continuacin, se debe seguir evaluando cada
los detalles de un producto determinado o
sus productos y subcategoras.
Select Catalog (Seleccionar catlogo):
Comportamiento deI objeto

er existir un tipo de mecanismo que
podra entonces asumir la existencia de un objeto Catalogs
y que, por tanto, se debe a
Select Catalog
sus productos y subcategoras. En primer lugar,
(Seleccionar catlogo):
Comportamiento deI objeto user
Catalogs (Catlogos) que
y que, por tanto, se debe a
Catalog; este comportamiento
En primer lugar,
(Catlogos) que
y que, por tanto, se debe agregar a
Una vez que se ha definido el objeto Catalogs
; este comportamiento
En primer lugar,
(Catlogos) que
gregar a
Catalogs, se
; este comportamiento

Una vez que se han identificado los comportamientos, el siguiente paso
consiste en identificar los atributos (tambin
objetos definidos.
elementos.
almacenan

Los atributos se obtienen del anlisis de los comportami
escenario y de la extraccin de los elementos que se deben almacenar o
controlar. Por ejemplo, en la seccin anterior, el escenario de uso especifica
que el usuario podr ver un producto determinado. Una vez visualizado ste, los
elementos que se
ejemplo, si la
producto, dichos elementos se convierten en atributos que se identifican en los
objetos.
atributo

3.2.3.3
objetos definidos.
elementos. Se trata de marcadores de posicin
almacenan.
elementos que se
ejemplo, si la empresa requiere que se muestre
La figura es un diagrama de UML
Name (Nombre):
3.2.3.3. Identificacin de atributos
objetos definidos. La aplicacin necesita realizar un seguimiento sobre estos
Se trata de marcadores de posicin
elementos que se muestran al usuario son los atributos del producto. Por
empresa requiere que se muestre
(Nombre):
Figura
48
Identificacin de atributos
La aplicacin necesita realizar un seguimiento sobre estos
Se trata de marcadores de posicin
muestran al usuario son los atributos del producto. Por
empresa requiere que se muestre
Figura 9. Atributo deI objeto
48
Identificacin de atributos
consiste en identificar los atributos (tambin denominados
Se trata de marcadores de posicin donde
empresa requiere que se muestre la descripcin y el precio del
La figura es un diagrama de UML que ilustra el objeto
Atributo deI objeto

denominados propiedades
donde los datos se retienen o
la descripcin y el precio del
que ilustra el objeto
Atributo deI objeto user
propiedades) de los
los datos se retienen o
Los atributos se obtienen del anlisis de los comportamientos del
que ilustra el objeto User
) de los
los datos se retienen o
entos del
User con el
49
3.2.3.4. Identificacin de reIaciones

Una vez que se han definido los objetos, sus comportamientos y
atributos, el siguiente paso es identificar sus reIaciones, que son asociaciones
lgicas entre objetos. Para identificarlas, es necesario analizar la interaccin
entre los distintos objetos. Por ejemplo, el objeto Categories, que administra la
coleccin, tiene una relacin con el objeto Category (Categora), ya que
contiene varios de estos objetos.

Es importante resaltar que existe otro tipo de relacin denominada
herencia, que se da slo cuando un objeto es definido por otro. Por ejemplo, si
la solucin que se est diseando est destinada a la venta de comida y libros y
se pretende diferenciar de forma lgica entre ambos productos, se debera
definir una relacin en la que los objetos Book (Libro) y Food (Comida) fueran
tipos del objeto Product. Es decir, ambos heredan del objeto Product.

En las aplicaciones que referencian la arquitectura para comercio
electrnico (Reference Architecture for Commerce), no se definen relaciones de
herencia en la fase lgica. No obstante, en determinadas soluciones de
comercio electrnico, las relaciones pueden resultar importantes. El resultado
final del proceso es la creacin de un diseo lgico que se utiliza como base
para el diseo y las especificaciones tcnicas.

50
3.2.4. Diagramas de cIases

Para analizar la relacin entre clases (Conjunto de objetos) se utiliza el
diagrama de clases, dicho diagrama se basa en lo anteriormente mencionado.

3.2.4.1. Mtodos de Ias cIases en cada una de Ias tres capas

Para obtener un buen diseo de una aplicacin de tres capas es
necesario poder colocar los mtodos de las clases correctas en las capas
correctas, de esta manera es posible encontrar las caractersticas de
escalabilidad y buen desempeo. En las etapas anteriores se encontraron los
mtodos de las clases, pero para una aplicacin de tres capas es necesario que
los mtodos se ubiquen segn su funcionalidad en la capa correspondiente.

En la capa de servicios de presentacin o interfaz, deben ir los mtodos
que no tienen nada que ver ni con manejo de datos, ni con reglas de negocios,
simplemente llamadas a mtodos de otras capas y procesos de exposicin de
informacin a travs de la interfaz. Por ejemplo, r_Registro_Anterior, etc.

En la capa del medio o de servicios de negocios, deben ir todos los
mtodos que contienen las reglas de negocios propiamente dichas y las
llamadas a los mtodos de manipulacin de datos de la tercera capa. En la
capa de servicio de datos deben ir todos los mtodos de manipulacin de datos
que acceden al repositorio de datos directamente, la base de datos.

lugar dnde colocar cada mtodo.
resultante no identifica tecnologas especficas. Estas
en una

El diagrama de secuencias y el anl
en una fase fsica del diseo.

Figura 10. EjempIo de

fase fsica del diseo.
10. EjempIo de
fase fsica del diseo.
10. EjempIo de diagrama de secuencia y r
51
lugar dnde colocar cada mtodo. Es importante recordar
grama de secuencia y r

El diagrama de secuencias y el anlisis de funcionalidad determinarn el
Es importante recordar
grama de secuencia y r
isis de funcionalidad determinarn el
Es importante recordar que el diseo lgico
resultante no identifica tecnologas especficas. Estas tecnologas se identifican
grama de secuencia y reIaciones de objetos
que el diseo lgico
tecnologas se identifican
eIaciones de objetos

que el diseo lgico
tecnologas se identifican
eIaciones de objetos
52

REDEFNCN DEL SSTEMA CON UNA ARQUTECTURA WEB USANDO UWE
53
4. REDEFINICIN CON UNA ARQUITECTURA WEB USANDO
UWE

4.1. ModeIando eI proceso de negocio web con UWE

Hasta esta etapa se ha modelado los requerimientos de la aplicacin
preexistente, por medio de sus especificaciones funcionales, hasta encontrar
distintos aspectos de cmo trabaja la aplicacin, pero ahora es necesario
considerar cmo la arquitectura web impacta en el nuevo diseo.

El diseo de las aplicaciones de negocio web siguiendo esta metodologa
requiere de las siguientes actividades: la primera parte del diseo es una
transaccin de refinamiento del modelo conceptual, donde las restricciones del
diseo web se aplican al diseo obtenido, de la conceptualizacin del sistema
original, agrega atributos y mtodos a las clases identificadas. El segundo paso
consiste en integrar los procesos en el modelo de navegacin, para indicar las
posibilidades de navegacin. La tercera actividad afina el modelo de actividades
mediante una estructura de procesos y un flujo de vistas de proceso. La ltima,
pero no menos importante, es el modelo de presentacin, basado en la
navegacin y el modelo de procesos, mostrando cmo se combina el
paradigma de navegacin y las actividades del negocio.

54
El producto de esta fase es un diseo de implementacin completo o una
gua en forma de documento de especificacin tcnica, que el equipo de
desarrollo emplear para crear la aplicacin.

4.1.1. Integracin de procesos en eI modeIo de navegacin

Las actividades del modelado navegacional en UWE comprenden la
construccin del modelo de navegacin en dos fases.

4.1.1.1. ModeIado deI espacio navegacionaI

Primero, el objetivo es especificar cuIes objetos pueden ser visitados a
travs de la aplicacin. ncorporando a este diagrama construcciones
adicionales que muestran cmo el usuario puede alcanzar estos elementos
navegando.

El modelo de navegacin es representado por diagramas estereotipados
de clases. Este incluye las clases de esos objetos, los cuales pueden ser
visitados a travs de la aplicacin Web. UWE provee un conjunto de guas y
mecanismos semiautomticos para el modelado de navegacin de una
aplicacin, las cuales son detalladas en manuales de referencias. Esta
automatizacin es soportada por herramientas CASE.
55
UWE define un conjunto de elementos de modelado usadas en la
construccin del modelo de navegacin. Como primer paso la <<clase de
navegacin>> y el <<enlace de navegacin>> y luego los estereotipos
adicionales <<clase de proceso>> y <<enlace de proceso>>, los cuales se
definen con la siguiente semntica.

La clase de proceso modela una clase cuya instancia es visitada por el
usuario durante la navegacin. Se les asigna el mismo nombre que su clase
correspondiente conceptual. Este posibilita definir un mapa funcional entre la
clase de proceso y los casos de uso (estos casos de usos no estereotipados
como navegacionales) en una va similar para el mapeo funcional definido entre
la clase de navegacin y la clase conceptual.

El enlace de proceso modela la asociacin entre una clase de
navegacin y una clase de proceso. Este enlace de proceso necesita tener
asociada informacin acerca del estado de proceso. Por ejemplo, pueden ser
restricciones por una expresin OCL sobre el estado de proceso. Esta permite
resumir actividades que contiene el proceso sobre condiciones acertadas. Las
relaciones entre el espacio de navegacin representan una navegabilidad
directa, indicando el punto de inicio y el punto final de navegacin. Para fijar las
direcciones de navegacin se usan flechas, en las que se indican la
multiplicidad y el rol. Cuando falta el nombre en la relacin, por convenio se
determina de la siguiente manera, si la multiplicidad es menor o igual a uno, se
toma el nombre de la clase destino para el rol, y si es mayor que uno se toma el
plural del nombre. Este enlace puede ser bidireccional, en la notacin puede ser
una lnea sin flechas.

56
4.1.1.2. Estructura deI modeIado navegacionaI

El segundo paso en la construccin del modelo de navegacin, consiste
en la ampliacin del modelo, por un conjunto de estructuras de acceso
necesarias para la navegacin. Esta ampliacin es parcialmente automatizada,
esto consiste en introducir ndices, visitas guiadas y consultas. Por cada una de
estas construcciones, UWE define una clase estereotipada <<ndice>>,
<<consulta>> y <<visita guiada>> dentro de los mecanismos extendidos de
UML. Adicional a esto, el modelo es enriquecido automticamente con mens,
los cuales UWE incluye con una clase estereotipada <<men>>. Para todas las
construcciones, UWE especifica elementos de modelado usando el lenguaje de
restricciones de objetos (OCL) para definir invariantes de esas construcciones.

Los estereotipos e conos asociados para estos elementos de
navegacin son:
ndice: permite un acceso directo a las instancias de las clases de
navegacin. Se modela mediante un objeto compuesto de enlaces con los
nombres de las instancias de las clases de navegacin a donde apuntan.
Consultas: su diseo consiste en una clase cuyo atributo es una cadena
de consulta, puede ser una operacin de seleccin definida con OCL.
Visitas guiadas: representan cmo acceder secuencialmente las
instancias de una clase de navegacin y deben ser controladas por el usuario o
por el sistema.

reglas que a continuaci
cual tiene una vista estructural
flujo de proceso.
navegacional, la cual es descrita definiendo entrada de procesos y puntos
finales entre ejecucin de pro

Figura

Los elementos de acceso de men se agregan siguiendo una serie de
Tomar en cuenta que las asociaciones tienen una clase de navegacin
como fuente.
A cada clase de navegacin que tiene al menos una asociacin que sale
se asocia una clase men.
Se reorganiza los
Para cada rol en el extremo
introduce un elemento correspondiente de men.
Toda relacin que tiene como fuente una clase de navegacin.

4.1.2

En nivel de diseo UWE propone construir un modelo de proceso
flujo de proceso.
REDEFNCN DEL SSTEMA CON UNA ARQUTECTURA
Figura 11. Estereotipos y sus
como fuente.
Se reorganiza los
4.1.2. Afinando eI modeIado de procesos
flujo de proceso. Otras vistas son la integracin de vistas con el modelo
Estereotipos y sus
clase de
navegacin
ndice
visita guiada
reglas que a continuacin se detallan.
Se reorganiza los mens en submens.
Afinando eI modeIado de procesos
Otras vistas son la integracin de vistas con el modelo
finales entre ejecucin de procesos y de navegacin.
57
Estereotipos y sus conos para eI modeIo de
clase de
navegacin

visita guiada
proceso
n se detallan.
en submens.
Para cada rol en el extremo de una asociacin con direccin
cual tiene una vista estructural del proceso
cesos y de navegacin.
conos para eI modeIo de
men
consulta
clase de
proceso
en submens.
de una asociacin con direccin
del proceso y una vi
cesos y de navegacin.
REDEFNCN DEL SSTEMA CON UNA ARQUTECTURA WEB
conos para eI modeIo de n
y una vista de comportamiento

WEB USANDO UWE
navegacin
sta de comportamiento
USANDO UWE
avegacin
de una asociacin con direccin, se
En nivel de diseo UWE propone construir un modelo de procesos, el
sta de comportamiento o
58
Estos conceptos son similares para el "inicio de actividad y el "final de
actividad, este modelo puede ser independiente de la navegacin. La
estructura del modelo de proceso es igual al modelo de navegacin, derivado
desde el modelo conceptual. La diferencia con el modelo de navegacin es
que el objetivo de este modelo es capturar la informacin relacionada que
comprende una estructura de comportamiento. Se puede adherir nuevos
elementos en el proceso que no necesariamente son derivados del modelo
conceptual, siempre usando los estereotipos mencionados anteriormente.

4.1.2.1. ModeIo estructuraI deI proceso

El objetivo es describir las relaciones entre las diferentes clases de
proceso, se crea un diagrama de clase donde cada una se representa con un
estereotipo de clase de proceso. Se conjuntan estas clases y se asocian a una
superclase que represente el proceso general, se agrega algunas clases si es
necesario para denotar alguna interaccin u operacin en comn y se asocian
con otra superclase del mismo tipo para heredar caractersticas.

4.1.2.2. ModeIo de comportamiento deI proceso

La conducta de un proceso es representado mediante un diagrama de
actividades UML, describiendo el flujo de una clase de proceso, lo que sucede
cuando un usuario navega hacia una clase de proceso.
59
Se modela un diagrama de actividad para cada clase de proceso con un
nombre propio del diagrama de navegacin, etiquetndolo con el nombre de la
clase ms el flujo de trabajo, de modo que se puede ver de manera fcil que la
actividad pertenece a un estereotipo. Pueden surgir varios diagramas de
actividad en estas derivaciones. Para denotar interaccin con el usuario y la
pgina web y respondiendo a un requerimiento informativo con el sistema se
usa el estereotipo <<Accin de usuario>>.

4.1.3. Soporte de procesos en eI modeIo de presentacin

El modelo de presentacin en UWE permite la especificacin de la lgica
de presentacin de una aplicacin web. Basada sobre el modelo lgico una
presentacin fsica puede ser construida, la cual contiene afinaciones
adicionales de elementos, para el diseo fsico por ejemplo letras y colores.
Esta presentacin fsica, no es el objetivo de este trabajo, pues no puede ser
capturada por algn modelo UML. Dentro del modelo de presentacin se puede
distinguir dos vistas diferentes: la estructura de vista que muestra la
estructura del espacio de presentacin, y la interfaz de usuario, la cual
presenta detalles acerca de los elementos de la interface de usuario en las
pginas.

Este diseo se gua por algunas reglas que a continuacin se presentan.
Crear una clase de presentacin por cada clase de navegacin que se
presente en el modelo de estructura de navegacin.
60
Crear una clase de presentacin por cada clase men, ndice, visita
guiada o consulta.
Como soporte de la navegacin se debe crear una clase de
presentacin.
Adicionar enlaces a las clases de presentacin.
Sealar qu elementos debern presentarse juntamente al usuario en
alguna ventana o seccin.
Adicionar si son necesarias expresiones OCL.
Crear los escenarios mediante serie de bocetos, representando la
sucesin de vistas de interfaz de usuario.

Por medio de los diagramas de presentacin se puede indicar qu clases
de navegacin y de procesos pertenecen a una pgina web.

4.1.3.1. Estructura visuaI

El objetivo de la estructura de vista en la presentacin es modelar cmo
el espacio de navegacin es dividido, cules elementos de presentacin son
desplegados en el mismo espacio, pero no en el mismo tiempo y cmo los
elementos de presentacin pueden ser agrupados, o sea el flujo de
presentacin.

El concepto central alrededor de la estructura de espacio de presentacin
toma lugar en el concepto de colocacin.
61
Por tanto se puede definir en el meta modelo de UWE una clase abstracta
con el estereotipo <<colocacin>>, la cual es la generalizacin de las siguientes
clases estereotipadas <<grupo de colocacin>>, <<colocacin alternativa>>, y
<<clase de presentacin>>. La semntica de estas clases se define como
sigue
<<grupo de colocacin>> clases estereotipadas son usadas para
modelar la subestructura de presentacin, por ejemplo un conjunto de
pginas. Estas agregan una lista de sub-localidades.
<<alternativa de colocacin>> clases estereotipadas son usadas para
modelar alternativas de presentacin entre clases de colocacin,
opcionalmente una alternativa automtica puede ser especificada.
<<clase de presentacin>> este estereotipo representa fragmentos
lgicos de pgina y est compuesto de elementos de interface de
usuario, presentados para el usuario de la aplicacin. Cada elemento de
la clase de presentacin es relacionado exactamente con una clase de
navegacin o clase de proceso contenida dentro de los elementos de un
modelo de navegacin o de procesos definiendo por all la presentacin
para ese elemento particular.

4.1.3.2. Interfaz de usuario

Muestra el contenido de cada nodo en la estructura del flujo de
presentacin mediante bocetos establecidos por el diseador web. Se utiliza
una notacin alternativa de UML para mostrar la composicin de la relacin de
los elementos de interfaz de usuario dentro del contenido visual de una clase de
presentacin.

Esta propuesta permite visualizar un esquema
observa
vista de la interfaz de usuario. Cada tipo de elemento de interfaz de usuario
tiene un estereotipo asociado
subyacen de la navegacin o cl
interfaz de usuario dinmicas
interface de usuario pueden ser usados
estticas
como encabezados.

El tipo de elemento de interface de usuario utilizado para presentar los
elementos correspondientes de los modelos subyacentes depende de su tipo y
el uso previsto.
desplega
los atributos de una clase de proceso.

Figura

observa la relacin
tiene un estereotipo asociado
estticas, por ejemplo las imgenes estticas como logos o textos est
como encabezados.
el uso previsto. Un elemento de ingreso por ejemplo puede ser usado para
desplegar informacin, as como para la entrada de informacin en el caso de
Figura 12. Estereotipos y sus
la relacin de composicin tradicional
tiene un estereotipo asociado.
por ejemplo las imgenes estticas como logos o textos est
como encabezados.
Un elemento de ingreso por ejemplo puede ser usado para
r informacin, as como para la entrada de informacin en el caso de
Estereotipos y sus
clase de presentacin
texto
ancla
botn
formulario
62
de composicin tradicional
. Estos son conectados por las caractersticas que
subyacen de la navegacin o clases de p
interfaz de usuario dinmicas. Adicionalmente, este tipo de elementos de
Estereotipos y sus conos para eI modeIo de

clase de presentacin

62
de composicin tradicional, a la hora que se representa la
Estos son conectados por las caractersticas que
ases de procesos,
Adicionalmente, este tipo de elementos de
interface de usuario pueden ser usados por elementos de interface de usuario

pgina de presentacin
entrada de texto
coleccin de anclas
imagen
grupo de presentacin

Esta propuesta permite visualizar un esquema ms
a la hora que se representa la
en el caso de elementos de
por elementos de interface de usuario
pgina de presentacin
entrada de texto
coleccin de anclas
grupo de presentacin
intuitivo, como
conos para eI modeIo de presentacin

USANDO UWE
como se
por ejemplo las imgenes estticas como logos o textos estticos
resentacin
CASO DE ESTUDO
63
5. CASO DE ESTUDIO

5.1. Descripcin caso de estudio. Sistema de contratos de personaI

Tomando en cuenta los conceptos descritos en este trabajo se estudia un
caso prctico del mundo real. La aplicacin para este caso se refiere a un
mdulo de administracin de contratos de una institucin, que por su expansin
actualmente tiene sucursales distribuidas geogrficamente.

El sistema con que se trabaja actualmente es de arquitectura
centralizada, con un servidor que contiene la programacin de las aplicaciones,
la base de datos y el acceso es por medio de terminales tontas o sesiones de
emulacin. No puede atender procesos en lnea de las sucursales.

El procedimiento para administrar contratos del personal actualmente
cuenta con una parte burocrtica la cual consta de, redactar una solicitud de
contrato para una persona durante determinado perodo de tiempo, por parte de
cada departamento de esta institucin, luego esta solicitud es llevada por el
encargado del departamento a la unidad de presupuesto, aqu es donde se
reciben todas las solicitudes para revisarse, autorizarse o rechazarse,
posteriormente las solicitudes son regresadas a los departamentos
correspondientes, para corregirse o bien si son presupuestadas las solicitudes,
se llevan a la gerencia para su aprobacin final y para la generacin de los
respectivos contratos.
CASO DE ESTUDO
64
Luego se acumulan lotes de contratos para trasladarlos al departamento
de procesamiento de datos para su ingreso al sistema, en el cual se guarda
parte de la informacin por el diseo limitado. Cuando se requiere por parte de
cualquier departamento de la empresa informacin acerca de contratos y
empleados, nicamente la divisin de procesamiento de datos y algunas
estaciones de trabajo conectadas al servidor pueden acceder a sta.

5.2. SoIucin de Ia migracin utiIizando eI mtodo propuesto

Primeramente se analiza el problema, a simple vista se detecta
problema en automatizacin de procesos, y la necesidad imperiosa de migrar
hacia una arquitectura que permita al sistema atender la cobertura geogrfica
que la empresa requiere, adems no es slo migrar el sistema de arquitectura,
tambin aprovechar el rediseo y agregar funcionalidad a los procesos que
existen en el sistema actual y agregar nuevos procesos. Lo que busca esta
propuesta es guiar el proceso de migracin de la arquitectura del sistema
antiguo y su traslado hacia nternet, con un diseo basado en parte por la
metodologa de visualizacin de UML y la ingeniera para la Web UWE, en este
caso de estudio se simplificar la solucin y se resumirn las etapas, la
visualizacin de algunos diagramas representar la esencia de las fases
principales, un lujo de detalles esta fuera del alcance de los objetivos de este
trabajo. En la siguiente figura se muestra cmo funciona el sistema antiguo que
se dispone y el proceso completo.

CASO DE ESTUDO
65
Figura 13. Sistema centraIizado, caso de estudio

Segn la solucin del problema, el cambio de arquitectura del sistema de
manejo de contratos quedara como se muestra en la siguiente figura.

CASO DE ESTUDO
66
Figura 14. Sistema migrado hacia Internet, caso de estudio

5.2.1. AnIisis y diseo deI sistema actuaI centraIizado

Se debe aplicar el anlisis de ingeniera inversa e investigacin de cdigo
fuente, y de modelos de base de datos. De la abstraccin que se obtenga de la
investigacin del sistema antiguo se debe crear un esquema conceptual, el cual
se representa con un diagrama de clases. En la siguiente figura se muestra
cmo se conceptualiza el sistema antiguo por medio de un diagrama de clases.

CASO DE ESTUDO
67
Figura 15. Abstraccin de cIases deI sistema antiguo, caso de estudio

Despus de ver un esquema generalizado del diagrama de clases, se
agregan los atributos que se extraen de los campos equivalentes en entidades,
tablas y archivos, adems se agregan los mtodos respectivos de cada clase,
producidos de la lgica de los subprogramas relacionados con la clase
equivalente.

Diagrama de Clases
Sistema Antiguo
Abstraido de la ngenieria
nversa.
Empl eado
Departament o
Puesto
EstadoPl aza
T ipoPlaza
Contrato
1..*
1
1..*
1
1..*
1
1..*
1
1..*
1
1..*
1
1..*
1
1..*
1
1..*
1
1..*
1
Resol uci on 1..*
1
1..*
1
CASO DE ESTUDO
68
Figura 16. Abstraccin de cIases detaIIado deI sistema antiguo, caso de
estudio

5.2.2. Rediseo deI sistema de informacin con UWE

Con la definicin de la arquitectura destino, se debe crear el nuevo
diseo, partiendo del esquema conceptual que se obtuvo del sistema antiguo.
Se agrega funcionalidad a los procesos antiguos, especificndose por medio de
casos de uso, esto con el fin de producir la conceptualizacin para la
arquitectura Web.
Diagrama de Clases
Sistema Antiguo
Abstraido de la ngenieria
nversa.
Empl eado
RegEmpl eado : nteger
Apel l i do : Stri ng
Nombre : stri ng
Di recci on : stri ng
Cedul a : stri ng
Fnaci mi ento : date
sexo : i nteger
estadoci vi l : i nteger
Manteni mi ento()
Regi stroTemporal ()
Departamento
CodDepto : i nteger
NombreDepto : i nteger
Puesto
CodPuesto : i nteger
Descri pci on : stri ng
Suel do : Doubl e
EstadoPl aza
CodEstadoPl aza : i nteger
Ti poPl aza
CodTi poPl aza : i nteger
Contrato
CodDepto : i nteger
NumPl aza : i nteger
RegEmpl eado : i nteger
CodTi poPl aza : i nteger
CodEstadoPl aza : i nteger
CodPuesto : i nteger
CodResol uci on;i nteger
Horari o : stri ng
Fechani ci o : date
FechaFi n : date
Suel do
ngresoContrato()
Modi fi caContrato()
El i mi naContrato()
Consul taContrato()
Resol uci on
CodResol uci on : i nteger
Fecha : date
NumResol uci on : i nteger
1
1
1
1
1
1..* 1..*
1
1..* 1..*
1
1..* 1..*
1
1..* 1..*
1
1..* 1..*
1
1..*
1
1..*
1
CASO DE ESTUDO
69
5.2.2.1. Nuevos escenarios de uso

Despus del anlisis y la determinacin de los alcances del nuevo
sistema, se puede redefinir los distintos escenarios de uso.
Mantenimiento de empIeados, administracin de los datos de
empleados, se compone de, el ingreso de empleados nuevos, la actualizacin
de informacin de los empleados existentes y la consulta de informacin de los
mismos.
Ingreso o modificacin de soIicitudes de contratos, se ingresan los
datos necesarios para solicitar la autorizacin del contrato, los cuales se hacen
por medio de un formulario, esto se hace en cada departamento.
Autorizacin de soIicitudes de contratos, administra la revisin de las
solicitudes de contratos ingresadas en el sistema, con base al presupuesto se
autoriza o rechaza segn sea el caso, lo cual se lleva a cabo en la unidad de
presupuesto.
Aprobacin finaI y generacin de contrato, la gerencia administra la
aprobacin de las solicitudes autorizadas ingresadas en el sistema, y genera los
contratos seleccionados.

5.2.2.2. Especificacin y diagramas de casos de uso

Los casos de uso proveen funcionalidad al sistema, en este sistema de
administracin de contratos se encuentran los siguientes casos de uso:

CASO DE ESTUDO
70
Nombre: ingreso aI sistema.
Precondiciones: debe existir usuario en el sistema.
Flujo principal:
1. El usuario ingresa al sistema.
2. El sistema presenta formulario de ingreso.
3. El usuario ingresa claves y parmetros.
4. El sistema verifica y valida informacin ingresada.
5. El sistema presenta opciones segn parmetros.
Flujo alterno:
4.1 El sistema detect parmetros incorrectos.
4.2 El sistema muestra mensaje de error.
Propsito: ingreso al sistema por usuarios vlidos.

Nombre: ingreso de empIeado nuevo
Precondiciones: el usuario debe haber ingresado al sistema, y estar dentro.
Flujo principal:
1. El sistema presenta formulario
2. El usuario ingresa informacin
3. El sistema verifica informacin ingresada.
4. El sistema retorna mensaje de verificacin.
5. El usuario graba informacin
6. El sistema sigue su flujo bsico
Flujo alterno:
4.1 Se ingres informacin incorrecta.
4.1 El sistema retorna mensaje de advertencia de error.
5.1 El sistema no pudo grabar.
5.2 El sistema retorna mensaje de error.
CASO DE ESTUDO
71
Propsito: agregar a la base de datos informacin de empleados que no existen
en el sistema, para procesar contratos.
Nombre: consuIta de empIeados
Debe existir informacin de empleados.
Flujo principal:
1. El sistema presenta formulario
2. El usuario ingresa parmetros de bsqueda
4. El sistema retorna informacin de bsqueda.
Flujo alterno:
2.1 El usuario ingresa parmetros de bsqueda por registro
2.1.a El sistema sigue su flujo bsico.
2.2 El usuario ingresa parmetros de bsqueda por nombre
2.2.a El sistema sigue su flujo bsico.
4.1 No existe informacin de parmetros de bsqueda.
Propsito: consultar informacin acerca de empleados existentes en el sistema.

Nombre: ingreso de soIicitud
Precondiciones: el usuario debe haber ingresado al sistema y estar dentro.
Flujo principal:
1. El sistema presenta formulario de solicitud.
2. El usuario ingresa informacin
5. El usuario graba informacin
CASO DE ESTUDO
72
6. El sistema procesa la grabacin.
Flujo alterno:
Propsito: ingreso de solicitudes de contrato, para su trmite.

Nombre: consuIta de soIicitud
Precondiciones: el usuario debe ingresar al sistema, y estar dentro. Debe existir
informacin de solicitudes.
Flujo principal:
1. El sistema presenta listado de solicitudes ingresadas
2. El usuario selecciona solicitud deseada
3. El sistema busca informacin de solicitud.
4. El sistema muestra informacin de solicitud.
Propsito: consultar informacin acerca de empleados, existentes en el
sistema.

Nombre: modificacin de soIicitud
Precondiciones: el usuario debe ingresar al sistema, y estar dentro.
Flujo principal:
1. El sistema presenta formulario con informacin de solicitud.
2. El usuario ingresa informacin a cambiar.
CASO DE ESTUDO
73
5. El usuario graba informacin.
6. El sistema guarda informacin.
7. El sistema sigue su flujo bsico.
Flujo alterno:
Propsito: correccin de solicitudes de contrato, para su trmite.

Nombre: autorizacin de soIicitud
informacin de solicitudes.
Flujo principal:
1. El sistema presenta listado de solicitudes ingresadas.
2. El usuario selecciona solicitud deseada.
5. El usuario autoriza solicitud de contrato.
6. El sistema actualiza informacin.
Flujo alterno:
5.1 El usuario no autoriza solicitud de contrato.
5.2 El usuario ingresa observaciones de rechazo.
5.3 El sistema sigue su flujo bsico.
6.1 El sistema no pudo actualizar informacin.
CASO DE ESTUDO
74
Propsito: autorizacin presupuestaria de solicitud de contrato de personal.

Nombre: aprobacin de contrato
informacin de solicitudes autorizadas nicamente.
Flujo principal:
1. El sistema presenta listado de solicitudes autorizadas.
2. El usuario selecciona solicitud deseada.
5. El usuario aprueba contrato.
6. El sistema actualiza informacin.
Flujo alterno:
5.1 El usuario no aprueba contrato.
5.2 El usuario ingresa observaciones de rechazo.
5.3 El sistema sigue su flujo bsico.
6.1 El sistema no pudo actualizar informacin.
Propsito: aprobacin final de contrato de personal.

Nombre: generacin de contrato
Debe existir informacin de solicitudes autorizadas (contratos aprobados).
Flujo principal:
1. El sistema presenta lista de contratos aprobados.
2. El usuario selecciona contrato deseado.
CASO DE ESTUDO
75
3. El sistema busca informacin de contrato.
4. El sistema genera contrato.
Flujo alterno:
4.1 El sistema tuvo problemas para generar contrato.
Propsito: generacin de contratos aprobados por gerencia, con la informacin
de las solicitudes ingresadas.

De la especificacin anterior se pueden visualizar varios casos de uso, e
incluir varios en un slo diagrama, como un contexto de procesos unificados.

Figura 17. Diagrama de caso de uso, ingreso aI sistema

usuario
autenti caci on
baseDatos
Departamento Presupuesto
Gerencia
Computo
<<include>>
<<include>>
Logueo al
sistema
<<include>>
CASO DE ESTUDO
76
Figura 18. Diagrama de caso de uso, mantenimiento de empIeados

usuario
ngreso Empleados
Consulta Empleados
Buscanformacion
Desplieganformacion
<<include>>
<<include>>
baseDatos
Manteni miento
de Empleados
CASO DE ESTUDO
77
Figura 19. Diagrama de caso de uso, contexto de administracin de
personaI

baseDatos
usuario
ngreso Solici tud
Modifica Solicitud
Cancela Solicitud
Consulta Solicitud
Autoriza Soli ci tud
Presupuesto Usuario
Gerencia Usuario
Aprobacion Contrato Genera Contrato
<<include>>
Admini straci on
de Soli citudes
de Contratos
CASO DE ESTUDO
78
5.2.2.3. Diagrama de cIases

Figura 20. Vista conceptuaI rediseada, diagrama de cIases

CASO DE ESTUDO
79
5.2.2.4. Diagramas de secuencia

Figura 21. Diagrama de secuencia para Ia aItas, bajas y consuItas de
empIeados

Depto : Depto
nterfaz Grafica
: baseDatos
Prerrequisito: logueado al sistema
Descripcin: Secuencia del proceso
de Consulta/ ngreso / Modificacion
de empleados
Parmetro busqueda
Datos empleado
Opcion AB
Modo nterfaz
Cambios
Verifica
Grabar
nserta
Exito | Error
Regresa Menu
CASO DE ESTUDO
80
22. Diagrama de secuencia, ingreso de soIicitud

: Depto
nterfaz Grafica
: baseDatos
Registro Jefe
Datos Jefe
Registro Empleado
Datos Empleado
Puesto
Datos Puesto
Datos complemetarios
Calculos
Muestra Calculos
Grabar
nsertar Solic
Exito | Error
Regresa Menu
Prerrequisito: logueado al sistema
Post: Manipulacin solicitud
Descripcin: Secuencia del proceso
de ingreso de solicitud de contrato
CASO DE ESTUDO
81
Figura 23. Diagrama de secuencia deI proceso de autorizacin y
generacin de contratos

: Depto
Pagina ABC
Soli citud
: baseDatos
Pagina Autoriza
Soli ci tud
: Presupuesto
Elige solicitud ngresada/ Rechazada
Busca datos
Retorna datos
Muestra solicitud
Revisa sol icitud
Elige Link
Menu Principal
Eli ge Soli ci tud
Muestra Solicitud
Autoriza/ Rechaza Cambios
Acepta Cambios
Update
Exito o Error
Elige Solicitud Autorizada
Busca Datos
Retorna Datos
Muestra Contrato
mprime contrato
Secuencia del
tramite de una
solicitud de
contrato por el
sistema.
CASO DE ESTUDO
82
5.2.2.5. Diagramas de coIaboracin

Figura 24. Diagrama de coIaboracin, ingreso de soIicitudes de contratos

Depto : Depto
nterfaz Grafica :
<Process Name>
: baseDatos
8: Calculos 1: Registro Jefe
3: Registro Empleado
5: Puesto
7: Datos complemetarios
10: Grabar
2: Datos Jefe
4: Datos Empleado
6: Datos Puesto
9: Muestra Calculos
13: Regresa Menu
11: nsertar Solic
12: Exi to | Error
CASO DE ESTUDO
83
Figura 25. Diagrama de coIaboracin, administracin de soIicitudes de
contratos

Figura 26. Diagrama de coIaboracin, mantenimiento de empIeados

: Depto
Pagina ABC
Solicitud
: baseDatos
: Presupuesto
5: Revisa solicitud
18: mprime contrato
10: Autoriza/ Rechaza Cambios
Pagina Autoriza
Solicitud
1: Elige sol icitud ngresada/ Rechazada
6: Elige Li nk
14: Elige Solicitud Autorizada
4: Muestra solicitud
7: Menu Principal
17: Muestra Contrato
2: Busca datos
15: Busca Datos
3: Retorna datos
16: Retorna Datos
12: Update
13: Exito o Error
8: Elige Solicitud
11: Acepta Cambios
9: Muestra Solicitud
Depto : Depto
nterfaz Grafica :
<Process Name>
: bas eDatos
1: Parmetro busqueda
3: Opci on AB
5: Cambios
7: Grabar
2: Datos empleado
4: Modo nterfaz
6: Verifica
10: Regresa Menu
8: nserta
9: Exito | Error
CASO DE ESTUDO
84
5.2.3. ModeIando eI sistema con una arquitectura web

5.2.3.1. Integracin de procesos en eI modeIo de navegacin

5.2.3.1.1. ModeIado deI espacio navegacionaI

A continuacin, se modela cmo alcanzar las clases de
navegacin y qu procesos principales intervienen para esto. Se puede
observar el proceso de autenticacin de usuario en cada diagrama, el cual
determinar el perfil de usuario, y los diferentes objetos en el flujo de
navegacin.

Figura 27. Diagrama de espacio de navegacin por departamento

CASO DE ESTUDO
85
Siguiendo la descripcin de los escenarios de uso, los usuarios con perfil
Departamento son los encargados de las altas, bajas, modificaciones y
consultas de las solicitudes para contrataciones. En la siguiente figura se
observa que para los usuarios con el perfil de la unidad de Presupuesto, a
partir de la pgina principal se puede navegar hacia la solicitud, para ser
autorizada o bien rechazada, mediante dos procesos respectivos.

Figura 28. Diagrama de espacio de navegacin para presupuesto

Para los usuarios con el perfil de Gerencia, a travs de la pgina principal
llegarn a la clase solicitud, con estado autorizada, sta contiene dos procesos,
uno de rechazo y el otro de autorizacin (aprobacion de contrato), que precede
la secuencia hacia el proceso de generacin de contrato, el cual se dirige hacia
la clase Contrato; esta clase tambin contiene dos procesos uno que genera la
impresin del contrato y el otro que actualiza informacin editada.

CASO DE ESTUDO
86
Figura 29. Diagrama de espacio de navegacin para gerencia

CASO DE ESTUDO
87
5.2.3.1.2. Estructura deI modeIado navegacionaI

Estas presentaciones enriquecen los diagramas anteriores con un detalle
ms amplio, incluyendo estereotipos propios del ambiente web, como son los
indices, mens, consultas y vistas guiadas. Cada uno se refiere al mismo
escenario de los diagramas de la seccin anterior respectivamente.

CASO DE ESTUDO
88
Figura 30. Diagrama de estructura de navegacin por departamento

CASO DE ESTUDO
89
Figura 31. Diagrama de estructura de navegacin para presupuesto

CASO DE ESTUDO
90
Figura 32. Diagrama de estructura de navegacin para gerencia

CASO DE ESTUDO
91
5.2.3.2. Afinando eI modeIado de procesos

5.2.3.2.1. ModeIo estructuraI deI proceso

Por medio de ste se presentan las relaciones entre los distintos
procesos, que se asocian a las clases principales de la aplicacin en anlisis;
se puede observar los procesos relacionados con las clases identificadas,
Solicitud, Creacin y Actualizacin, se asocian con una superclase que se
llamada ProcesamientoSolicitud, la cual les hereda caractersticas principales.
gualmente se observa la relacin entre los distintos procesos de confirmacin
con una superclase que generaliza el proceso bsico. La clase
ProcesamientoSolicitud se compone de la clase ngresonfoSolicitud que asigna
valores a los atributos de la clase conceptual.

CASO DE ESTUDO
92
Figura 33. Diagrama de estructura de proceso para procesamiento de
soIicitud

CASO DE ESTUDO
93
Figura 34. Diagrama de estructura de proceso para procesamiento de
contrato y soIicitud autorizada

En este diagrama se puede observar la generalizacin del proceso
Autoriza Contrato, que hereda caracteristicas de las superclases de proceso
ProcesamientoSolicitud y ProcesamientoContrato, ya que una solicitud es
aprobada para convertirse en contrato,

CASO DE ESTUDO
94
5.2.3.2.2. ModeIo de comportamiento deI proceso

Por medio de diagramas de actividades se representa el flujo de un
proceso, derivado de la accin que produzca un objeto de navegacin.

CASO DE ESTUDO
95
Figura 35. Diagrama de fIujo de proceso para creacin de soIicitud

CASO DE ESTUDO
96
En el diagrama anterior se observa el comportamiento del procedimiento
que se produce cuando se selecciona la opcion creacin de solicitud, en el
men del mdulo para los usuarios con perfil por departamento. Se observa el
flujo principal entre mtodos y procedimientos estereotipados, que interactan
con el usuario en la creacin de una solicitud, adems la relacin con la
instancia del objeto solicitud. El siguiente diagrama muestra el flujo de proceso
que se produce al presionar el botn elimina solicitud en la clase de navegacion
solicitud.

Figura 36. Diagrama de fIujo de proceso para eIiminacin de soIicitud

CASO DE ESTUDO
97

Figura 37. Diagrama de fIujo de proceso para generacin de contrato

CASO DE ESTUDO
98
Esta secuencia de pasos se produce al presionar el botn autoriza
contrato, desde la clase de navegacin solicitud, con estado autorizada, la cual
genera y crea una instancia de la clase contrato.

5.2.3.3. Soporte de procesos en eI modeIo de presentacin

5.2.3.3.1. Estructura visuaI

Por medio de ste se muestran los elementos de presentacin que
ocupan el espacio de una clase de navegacin, pero no en el mismo tiempo. A
continuacin el diagrama describe la clase de navegacin Solicitud, y la
estructura como un grupo de ubicacin, con la clase estereotipada <<location
group>>, que contiene una seccin de encabezado y una parte de interaccin
por medio de secciones alternativas <<location alternative>>. Encabezado,
agrega una clase para logotipo y otra para la ruta de navegacin Path. La
seccin nteraccin, agrega tres distintas clases de presentacin, las cuales son
de creacin, actualizacin y eliminacin.

CASO DE ESTUDO
99
Figura 38. Diagrama de presentacin, estructura visuaI para pgina de
soIicitud

5.2.3.3.2. Interfaz de usuario

Muestra el contenido visual por medio de elementos fsicos de interfaz de
usuario. En el siguiente diagrama se observa el contenido para la pgina de
solicitud de propuesta, correspondiente a la clase de navegacin llamada
Solicitud. La estructura detallada en el diagrama anterior, se puede ver
aplicada, la seccin de encabezado y la seccin de interaccin.
CASO DE ESTUDO
100
Para este caso particular, se muestra el contenido presentado en el
tiempo de ejecucin correspondiente a la seccin creacin de solicitud, se
pueden ver sus respectivos elementos de interfaz de usuario, elementos de
entrada de texto, botn grabar, botn cancelar.

Figura 39. Diagrama de presentacin, interfaz de usuario, creacin de
soIicitud

En el siguiente diagrama se puede notar algunas diferencias con
respecto al anterior, entre ellas el objetivo, una de creacin y la otra de
eliminacin, el tipo de estereotipo para presentar los datos cambia, el anterior
como entrada de datos y el siguiente como texto de despliegue y no de edicin.
CASO DE ESTUDO
101

Figura 40. Diagrama de presentacin, interfaz de usuario, eIiminacin de
soIicitud

CASO DE ESTUDO
102
5.2.4. Diagramas de componentes y despIiegue

Para modelar la organizacin y dependencia entre objetos fsicos del
sistema como ejecutables, archivos, libreras, tablas y artefactos de este tipo,
UML sugiere los diagramas de componentes, y sugiere los diagramas de
despliegue para mostrar la configuracin de nodos en tiempo de ejecucin. A
continuacin se muestra la estructura de las pginas para el diseo de la
aplicacin Web en estudio, la cual constar de varios componentes sugeridos
como se puede observar, pginas de estilo, libreras de autenticacin, funciones
java script y componentes propios del sistema operativo.

Figura 41. Diagrama de componentes, estructura de pginas

Pagina
Cliente
Pagina Web
Hoja Estilo
Plantilla
Frame Forma
Libreria
Codigo
Servidor
Conexion DB
Autentica
Funciones
JavaScript
nteraccion y
Acceso DB
Componente
ejecutable SO

CASO DE ESTUDO
103
En los siguientes diagramas se puede observar la configuracin de
instancias de componentes y sus relaciones fsicas en tiempo de ejecucin,
para los distintos perfiles que manejar la interaccin con la aplicacin.

Figura 42. Diagrama de despIiegue para usuarios de Ios departamentos de
Ia empresa

indice.html
LibManteni
Empleado
Libngreso
Solicitud
LibABC
Solicitud
Logueo
html
Seleccion
Opcion
ngreso
Empleado
Manteni
Empleado
Consulta
Empleado
ngreso
Solicitud
Consulta
Solicitud
Muestra
Solicitud
Modifica
Solicitud
DEPARTAMENTO
Lib
Seguridad
Error
Componente
ejecutable del
browser para
imprimir

CASO DE ESTUDO
104
Figura 43. Diagrama de despIiegue para usuarios de presupuesto de Ia
empresa

indice.html
Lib
Autoriza
Logueo
html
Seleccion
Depto
Despliega
y
Seleccion
Solicitud
Autoriza
Solicitud
PRESUPUESTO
Lib
Seguridad
Error

Figura 44. Diagrama de despIiegue para usuarios de gerencia de Ia
empresa

indice.html
Lib
Autoriza
Contrato
Logueo
html
Seleccion
Depto
Despliega
y
Seleccion
Solicitud-
Autorizada
Autoriza
Contrato
GERENCA
Lib
Seguridad
Error
Componente
ejecutable del
browser para
imprimir

CASO DE ESTUDO
105
5.3. Prcticas adecuadas

Plasmar toda clase de detalles sugeridos en la conceptualizacin del
sistema incluyendo la abstraccin del anterior para que la migracin no sea un
fracaso.

Los esquemas conceptuales del sistema antiguo y del nuevo sistema son
de mayor ayuda si antes de aplicar nomenclatura propia de clases y casos de
uso son modelados como conceptos y relaciones en lenguaje natural.

Los procedimientos utilizados para el modelado de un proyecto de
cambio de arquitectura son importantes para alcanzar el objetivo final, los
cuales deben ser revisados constantemente, con el fin de asegurar que todos
los usuarios involucrados perciban sus procesos operativos aplicados.

La comunicacin debe ser abierta y directa ya que la expectativa del
usuario crece con respecto a la informacin en lnea, este requiere de
resultados operativos ms rpidos.

La experiencia en el diseo con UML y UWE es necesaria para no perder
tiempo valioso en el aprendizaje de la misma, puesto que la investigacin es
necesaria solamente para extraer conocimiento del funcionamiento del sistema.

CASO DE ESTUDO
106
Recabar toda la informacin necesaria acerca de las distintas
arquitecturas tanto origen como destino, puesto que detalles propios de stas
pueden influir en el comportamiento de los sistemas y eso es necesario para el
modelado.

Contar con la colaboracin de usuarios expertos que conocen el rol de
los actores claves en los procesos funcionales.

Para el rediseo del sistema es recomendable crear un entorno de
prueba lo ms apegado a la realidad, para descubrir los detalles y casos
particulares que muchas veces no se contemplan.

El procedimiento de migracin de arquitectura de software no variar
dependiendo de la dimensin del sistema, una vez se tenga clara la
conceptualizacin de ste.

CONCLUSONES
107
CONCLUSIONES

1. El anlisis y diseo de un proceso de migracin de arquitectura de
software ser ms efectivo y conciso si se apoya en una metodologa
rica en detalles de conceptualizacin visual.

2. La aplicacin de los estndares que sugieren las metodologas de
modelado visual UML y UWE, ofrecen un control ms detallado de
especificaciones.

3. Por medio de las etapas que sugiere esta propuesta, un proceso de
migracin de arquitectura de software facilitar el desarrollo de la
aplicacin final.

4. La conceptualizacin y el diseo que permite UWE para representar los
requerimientos del negocio para el funcionamiento en la Web, se acopla
perfectamente con la lgica preexistente conceptualizada con UML.

5. La representacin de las metodologas UML y UWE permiten validar
juntamente con el usuario la conceptualizacin obtenida.

CONCLUSONES
108
6. Esta propuesta garantiza el xito del proyecto en funcin de la
conceptualizacin, percepcin y especificacin que el analista plasme en
el lenguaje de modelado propuesto.

RECOMENDACONES
109
RECOMENDACIONES

1. Trazar objetivos a largo y corto plazo, definiendo hitos y puntos de
referencia, para hacer una migracin de arquitectura de software de un
sistema, para mejor control.

2. Para facilitar la conceptualizacin de una ingeniera inversa ser de gran
ayuda si se apoya en la metodologa UML.

3. No caer en el error de considerar que por estar diseando una aplicacin
orientada por un lenguaje de modelado visual, la interfaz grfica al
usuario de una aplicacin es lo ms importante, cada seccin sugerida
en esta propuesta tiene su importancia.

4. No confundir los detalles de las metodologas de modelado UML y UWE
con lenguajes de programacin lineal, pues estos tratan de modelar
sistemas de manera que sean bastante entendibles al usuario slo en
etapa de anlisis y diseo de un proyecto de aplicacin de software.

5. nvestigar los comportamientos particulares de las arquitecturas de
software en la etapa de anlisis, para tomarse en cuenta desde el
diseo de la aplicacin.

RECOMENDACONES
110
6. Seguir con los estndares que dictan las metodologas UML Y UWE para
la documentacin, en las fases posteriores de desarrollo.

REFERENCAS BBLOGRAFCAS
111
REFERENCIAS BIBLIOGRFICAS

1. ApIicacin Web.
http://ieee.udistrital.edu.co/computer/paginas.php (02-06-2003)

2. TecnoIogas de Ia informacin aI servicio de Ia historia cInica
eIectrnica.
http://www.seis.es/informes/2003/PDF/CAPTULO6.pdf . (06-10-2004)

3. TecnoIoga computacionaI
http://www.monografias.com/trabajos14/tecnolcomp/tecnolcomp2.shtml
(02-02-09)

4. Arquitectura en capas
http://www.docirs.cl/arquitectura_tres_capas.htm (18-06-2003)

REFERENCAS BBLOGRAFCAS
112

BBLOGRAFA
113
BIBLIOGRAFA

1. Aguirre Ordoez, Zulma Karina. Modelado visual con el lenguaje
unificado de modelado (UML). Tesis ng. Sis. Guatemala, Universidad
de San Carlos de Guatemala, Facultad de ngeniera, 2000. 181pp.

2. Alvarado Mansilla, Luis Giovanni. Consideraciones para la migracin
de la tecnologa de informacin actual hacia la nueva generacin
Downsizing/Rightsizing. Tesis ng. Sis. Guatemala, universidad de
San Carlos de Guatemala, Facultad de ngeniera, 1997. 112 pp.

3. ConaIIen, Inc. HomePage.
http://www.conallen.org/technologyCorner/webextension .
(28-07-2004)

4. Conallen, Jim. Building Web Applications with UML. Editorial
Adison Wesley Longman, 1999.

5. Construyendo apIicaciones web con una metodoIoga de diseo
orientada a objetos.
http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r22_art5_c.pdf.
(20-07-2004)

6. DesarroIIo de apIicaciones WEB con UML.
http://www.vico.org/TRAD_obert/TRAD_WAE_abierto.html .
(27-10-2003)

BBLOGRAFA
114
7. Ingeniera inversa.
http://www.pue.udlap.mx/~tesis/lis/lopez_a_aa/capitulo4.pdf.
(03-11-2004)

8. Larman, Craig. UML y patrones. Introduccin aI anIisis y diseo
orientado a objetos. Mxico: Prentice Hall, 1999. 536pp.

9. MetodoIogas para eI desarroIIo de apIicaciones Web: UWE
http://alarcos.inf-cr.uclm.es/doc/aplicabbdd/DASBD-
MetodologiasParaElDesarrolloDeaplicacionesWeb_UWE.pdf .
(28-10-2005)

10. Migration Guide. A guide to migrating the basic software
components on server and workstation computer. Berlin: KBSt
Publication Service, 2003. 414pp.

11. ModeIando aspectos de navegacin y presentacin en
apIicaciones hipermediaIes.
http://www.dlsi.ua.es/~ccachero/papers/jisbd00.pdf. (30-11-2004)

12. Ortiz bez, Maria Jos y Jess Garca Molina. Un proceso basado
en UML para apIicaciones Web. Cursos de Verano de la
Universidad de Burgos, Universidad de Murcia, Espaa: 2001. 129pp.

13. Pressman, Roger S. Tr. Rafael Ojeda Martn, Joaqun Snchez,
Virgilio Galaup, Julio Zurdo Chvez. Ingeniera deI software. 4. ed.
Espaa: McGraw Hill nteramericana. 581pp.

BBLOGRAFA
115
14. Schmuller Joseph. Aprendiendo UML en 24 horas. Mxico: Pearson
Educacin, 2000. 448pp.

15. Sommerville, an. Ingeniera de Software. 6 ed. Mxico: Pearson
Educacin, 2002. 712pp.

16. TecnoIogas de Ia informacin aI servicio de Ia historia cInica
eIectrnica.
http://www.seis.es/informes/2003/PDF/CAPTULO6.pdf .
(06-10-2004)

17. TerminoIoga generaI
es.wikipedia.org . (30/03/2010)

18. UML. http://usuarios.lycos.es/oopere/uml.htm .(19-04-2004)

19. Web Software Arquitectura.
http://www.dlsi.ua.es/~ccachero/papers/websatr.pdf . (28-07-2004)

Uwe PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Uwe PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad de San Carlos de Guatemala

Das könnte Ihnen auch gefallen