Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA.
Universidad del Quindo. Armenia, octubre 8 al 12 de 2001
ResumenLa rpida penetracin del uso de Internet la est convirtiendo en el escenario en el cual se desarrollan una buena parte de las actividades acadmicas, econmicas, de entretenimiento y hasta polticas del hombre moderno. Ello ha impulsado a su vez el desarrollo constante de nuevas tecnologas que buscan extender su uso mucho ms all de la simple navegacin y convertirla en un medio para la prestacin de mltiples servicios a travs de aplicaciones que pueden llegar a ser tan complejas como las clsicas aplicaciones multinivel, lo cual requiere contar con las herramientas de desarrollo adecuadas, entre las que son imprescindibles las tcnicas y herramientas de modelado. En este artculo se presentan de manera integrada, y tomando como base el modelo de Proceso Unificado para Desarrollo de Software, un conjunto de procedimientos y tcnicas que facilitan a los equipos de desarrollo de aplicaciones web manejar la complejidad de las aplicaciones y obtener productos de alta calidad. Se hace nfasis en dos actividades de singular importancia en el tipo de aplicaciones tratado: el Modelado de la Organizacin, que describe la actividad que ser soportada por la aplicacin, y el Diseo, que describe la propia aplicacin. Los modelos son construidos usando UML y la Extensin para Aplicaciones Web de UML.
Palabras clave-- WWW, metodologas de desarrollo, ingeniera de software, tcnicas orientadas a objetos, UML, estereotipos. I. INTRODUCCIN Cuando Mosaic [1] fue creado en los laboratorios del CERN (Centro Europeo para la Investigacin Nuclear) en 1993, es poco probable que alguien hubiera imaginado el impacto que este nuevo servicio de Internet, la WWW (World Wide Web) o simplemente "la Web", tendra sobre la sociedad moderna. Lo que simplemente empez como un mecanismo basado en hipertexto para acceso a informacin, con mejores prestaciones que las ofrecidas por los servicios de entonces, el FTP (File Transfer Protocol) y el Gopher, constituye hoy en da la aplicacin estrella ("killer application") de Internet, contribuyendo enormemente a su popularizacin. Los clientes de navegacin eliminaron la barrera de acceso a Internet que imponan las aplicaciones anteriores, que exigan un conocimiento de la red y del uso de comandos, y pusieron esta red al alcance de todo tipo de usuarios, a travs de una interfaz de muy fcil manejo.
Los pilares de este nuevo servicio son el Lenguaje de Marcado para Hiper-Texto (HTML, HiperText Markup Language) [2] y el Protocolo de Transferencia de Hiper- Texto (HTTP, HiperText Transfer Protocol) [3]. La informacin se ofrece a travs de documentos elaborados con HTML, llamados pginas web, que residen en un servidor, tal como se muestra en la Figura 1. Los usuarios disponen de una aplicacin cliente, llamada navegador, que utiliza el protocolo HTTP para solicitar y obtener del servidor las pginas, e interpreta su contenido para entregar al usuario la informacin ofrecida. Esta informacin es en general de tipo multimedia (texto, imgenes, sonido, vdeo, etc.), y a travs de los enlaces del hipertexto puede conducir a otros servidores en Internet que ofrecen ms informacin. Figura 1. Navegacin en Internet
La rpida penetracin del uso de Internet ha llevado a su vez a la aparicin de nuevas tecnologas que, como se ilustra en la Figura 2, buscan extender el uso de la Web mucho ms all de la simple navegacin a travs de documentos multimedia. Del lado del servidor, tecnologas como CGI (Common Gateway Interface) [4], PHP (Hypertext Preprocessor) [5], Servlets de Java [6] y ASP (Active Server Pages) [7] permiten acceder y procesar informacin en bases de datos o comunicarse con aplicaciones que a su vez pueden interactuar con otras aplicaciones eventualmente en red, y entregar sus resultados al usuario a travs de pginas creadas en forma dinmica. Figura 2. Aplicaciones en Internet
Del lado del cliente, se han desarrollado tecnologas como los JavaScripts, que permiten mejorar la presentacin de la informacin al usuario y realizar validaciones y clculos limitados, y los Applets de Java y componentes tipo ActiveX Modelado de aplicaciones en Internet lvaro Rendn Galln Grupo de Ingeniera Telemtica, Universidad del Cauca, Popayn, Colombia arendon@unicauca.edu.co HTML HTML HTML Base de Datos Servidor Web Navegador HTTP JavaScripts I IOP DCOM Applets ActiveX Servidor de Aplicaciones Internet WAN Dispositivos locales Servlet CGI, ASP HTML HTML HTML Servidor Web Navegador HTTP Internet Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA. Universidad del Quindo. Armenia, octubre 8 al 12 de 2001 y JavaBeans, que son adems capaces de acceder a dispositivos locales del usuario y a otras aplicaciones en la red a travs de los protocolos IIOP (Internet Inter-ORB Protocol) [8] y DCOM (Distributed Component Object Model) [9].
Como resultado de la disponibilidad de estas tecnologas, tanto del lado del servidor como del cliente, la Web ya no es slo un depsito de documentos hipertexto, sino que es adems el medio para construir, ofrecer y acceder a aplicaciones distribuidas las aplicaciones web que pueden llegar a ser tan complejas como las clsicas aplicaciones multinivel (n-tier), donde el componente de interfaz es provisto por el navegador y los componentes de lgica de la aplicacin y de gestin de datos se acceden desde el servidor web o desde el propio cliente.
Por las mismas razones, ya no es suficiente, como hasta hace no mucho tiempo, con armarse con un cursillo de HTML y un editor de texto, o en el mejor de los casos con un generador de pginas web, para sacarle un buen provecho a Internet. Hoy en da se requiere contar con un arsenal adecuado para el desarrollo de aplicaciones en Internet, en el que son imprescindibles las tcnicas y herramientas de modelado. Esta necesidad se hace ms evidente al considerar los siguientes factores:
- Uso creciente de Internet como proveedor de mltiples servicios. Como se ha mencionado, ya no slo se usa la red para acceder a informacin esttica, sino tambin para acceder a servicios que utilizan en forma dinmica informacin contenida en una base de datos, como la consulta a un diccionario en lnea, u obtienen los resultados de una aplicacin, como el clculo de las cuotas en un simulador de crdito. Estos servicios cubren ya una amplia gama de aplicaciones que incluyen la telemedicina, el comercio electrnico, y la teleeducacin, y que no slo atienden usuarios de computadores sino tambin usuarios de dispositivos inalmbricos con protocolos como WAP (Wireless Application Protocol). - Diversidad de participantes en el desarrollo de las aplicaciones. Adems del equipo de desarrollo, la construccin de aplicaciones web requiere de personas de muy variadas disciplinas; para una aplicacin de comercio electrnico, por ejemplo, se debe contar con la participacin de la alta gerencia de la empresa usuaria, los consumidores de sus productos, las empresas proveedoras, diseadores grficos, comunicadores sociales, abogados, etc. - Continua evolucin de las aplicaciones. La permanente adaptacin, tanto a nuevas condiciones del negocio como a nuevas tecnologas que van surgiendo, es una condicin necesaria para la supervivencia de las aplicaciones en Internet, la cual ha llevado a afirmar a Grady Booch que una aplicacin web estancada est muerta 1 . - Las aplicaciones deben cumplir con caractersticas exigentes. Su carcter distribuido, el hecho de que se ejecuten sobre una red Internet que no garantiza altos
1 Prlogo de [10]. niveles de disponibilidad pero en cambio s un nmero de usuarios creciente, as como las presiones del mercado, imponen a las aplicaciones en Internet caractersticas como flexibilidad, robustez, escalabilidad, oportunidad y economa, entre otras.
En el presente artculo se describe de manera integral un conjunto de procedimientos y notaciones orientados a facilitar a los equipos de desarrollo de aplicaciones en Internet el manejo de la complejidad de las mismas y la obtencin de productos de alta calidad, que satisfagan las necesidades de los clientes y usuarios, y dentro de los plazos y presupuestos planeados. Si bien estas guas estn enmarcadas dentro de un modelo de Proceso de Desarrollo genrico, instanciable a distintos dominios de aplicacin, se han incluido elementos especficos para las aplicaciones en Internet, como la Extensin para Aplicaciones Web de UML [10].
La siguiente seccin explica los principios generales del proceso de desarrollo presentado en el artculo. La Seccin III describe la Fase de Gestacin, haciendo nfasis en los componentes de Modelado de la Organizacin y Captura de Requisitos. La Seccin IV trata de la Fase de Preparacin, con nfasis en los componentes de Anlisis y Diseo, y describe la Extensin para Aplicaciones Web de UML. La Seccin V ofrece las conclusiones del trabajo. II. PROCESO DE DESARROLLO Los modelos que se presentan en este artculo corresponden a un proceso de desarrollo basado en el trabajo que desde hace ms de un lustro vienen realizando los three amigos, Grady Booch, James Rumbaugh e Ivar Jacobson, y que ha tomado forma en el Proceso Unificado (Unified Process, UP) ([11], [13]), como gua metodolgica, y el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) [14], como notacin para los modelos.
El proceso de desarrollo de aplicaciones informticas (software development process) es el conjunto de acciones y elementos necesarios para transformar los requisitos de los usuarios en un sistema informtico, y est definido en trminos de quin hace qu, cundo ha de hacerlo, y cmo obtener un cierto objetivo. El proceso de desarrollo descrito en UP est caracterizado por tres principios fundamentales: es iterativo e incremental, es conducido por casos de uso, y est centrado en la arquitectura.
En cumplimiento del principio de desarrollo incremental e iterativo, que a su vez est basado en el modelo en espiral de Boehm [15], UP propende por una ruptura definitiva con el modelo en cascada. Mientras que en ste las actividades de captura de requisitos, anlisis, diseo, implementacin y pruebas se agotan de manera secuencial hasta llegar a la terminacin del sistema, en UP ellas son ejecutadas con mayor o menor intensidad a lo largo de todo el ciclo de desarrollo, a la manera de miniproyectos que permiten un mayor control del avance de la construccin del sistema. El ciclo de desarrollo se divide as en fases, que estn definidas Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA. Universidad del Quindo. Armenia, octubre 8 al 12 de 2001 en trminos de los productos (denominados artefactos) que deben ser obtenidos en ciertos momentos clave (denominados hitos), mediante el concurso de todas o al menos varias de las actividades de desarrollo.
El esquema de UP de la Figura 3 muestra las actividades organizadas en componentes, en el eje vertical, y con variable intensidad de ejecucin en el eje del tiempo, organizado en fases, iteraciones e hitos. Los componentes agrupan las actividades segn su naturaleza, estableciendo la estructura del proceso de desarrollo, y se expresan en trminos de los flujos de trabajo que deben ejecutarse, los artefactos que deben construirse y los trabajadores responsables de su realizacin. Figura 3. Organizacin del Proceso Unificado
Los Componentes del Proceso contienen los flujos de trabajo que contribuyen directamente con la construccin del sistema, a saber: - Modelado de la Organizacin. Tiene como fin la comprensin cabal por parte del equipo de desarrollo (y con frecuencia del propio cliente) de la estructura y funcionamiento de la organizacin a la cual brindar soporte la aplicacin a construir. Su aporte es la identificacin del problema que debe ser resuelto por el sistema en desarrollo; en otros trminos, responder a la pregunta Cul es el problema? - Captura de Requisitos. Su propsito es la descripcin de las funcionalidades y caractersticas que debe (y no debe) ofrecer el sistema a sus clientes y usuarios. Esta descripcin responde a la pregunta Qu hace el sistema? - Anlisis. Define una estructura y funcionalidad de los componentes del sistema, de modo que satisfagan las necesidades de sus clientes y usuarios. Los artefactos elaborados en este componente permiten responder la pregunta Cmo funciona el sistema? - Diseo. En este componente se aterriza el desarrollo del sistema, al incorporar en su concepcin la consideracin de la arquitectura fsica sobre la que va a funcionar y su entorno de implementacin, esto es, sistemas operativos, protocolos, lenguajes de programacin, etc. Con los artefactos obtenidos se responde la pregunta Cmo se construye el sistema? - Implementacin. Tangibiliza el sistema al verter en archivos de cdigo fuente, guiones de comandos, binarios, libreras, ejecutables y dems, la conceptualizacin del sistema que hasta el momento estaba expresada slo en modelos, generalmente grficos. - Pruebas. Evala los componentes construidos y el sistema completo a fin de garantizar que satisfacen un cierto conjunto de requisitos y contienen un nmero mnimo de defectos. - Puesta en servicio. Comprende la instalacin del sistema en la planta fsica y los equipos del cliente, y su entrega en operacin a satisfaccin del cliente y los usuarios.
Los Componentes de Soporte contienen los flujos de trabajo de carcter administrativo, que son: - Gestin de configuracin y cambios. Realiza el seguimiento y mantiene la integridad de los artefactos a medida que evolucionan. Es aqu donde se hace el control de versiones, la administracin y anlisis de impacto de los cambios, y la extraccin de informacin sobre el avance del proyecto. - Gestin del proyecto. Es el componente donde se elabora la planeacin del proyecto y sus iteraciones, se establecen las estrategias para la gestin de los riesgos y se realiza el monitoreo del avance del proyecto. - Entorno. Presta soporte al equipo de desarrollo mediante la provisin, configuracin y mantenimiento de las herramientas computacionales y metodolgicas requeridas por el proyecto.
Mientras que la organizacin por componentes, como se dijo arriba, representa el aspecto estructural de UP describiendo las actividades, productos y trabajadores que integran el proceso de desarrollo, la organizacin en el tiempo representa su aspecto dinmico, describiendo cmo avanza el ciclo de vida del sistema, y cmo se conjugan las diferentes actividades para cumplir con los hitos del ciclo desarrollo. Cada ciclo de desarrollo, que conduce a la construccin y entrega de una nueva versin del sistema, se divide en fases, cada una de las cuales culmina con un hito y puede ser desarrollada en una o varias iteraciones.
Las fases de UP, a diferencia de las fases del modelo en cascada, no estn delimitadas por la finalizacin secuencial de las actividades, sino por hitos en los que se evalan los resultados obtenidos gracias a la conjugacin de diversas actividades. Las fases definidas son: Organizacin por Organizacin en el tiempo COMPONENTES DE SOPORTE COMPONENTES DEL PROCESO Iteraciones Inicial Gestacin Preparac. Construccin Transicin Prep. #1 Prep. #2 Const. #1 Const. #2 Const. #N Trans. #1 Trans. #2 FASES Componentes Captura de Requisitos Anlisis Diseo Implementacin Pruebas Puesta en Servicio Modelado de la Organizacin Gestin de Configuracin y Cambios Gestin del Proyecto Entorno Hitos Organizacin por Organizacin en el tiempo COMPONENTES DE SOPORTE COMPONENTES DEL PROCESO Iteraciones Inicial Gestacin Preparac. Construccin Transicin Gestacin Preparac. Construccin Transicin Prep. #1 Prep. #2 Const. #1 Const. #2 Const. #N Trans. #1 Trans. #2 FASES Componentes Captura de Requisitos Anlisis Diseo Implementacin Pruebas Puesta en Servicio Modelado de la Organizacin Captura de Requisitos Anlisis Diseo Implementacin Pruebas Puesta en Servicio Modelado de la Organizacin Gestin de Configuracin y Cambios Gestin del Proyecto Entorno Gestin de Configuracin y Cambios Gestin del Proyecto Entorno Hitos Hitos Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA. Universidad del Quindo. Armenia, octubre 8 al 12 de 2001 - Gestacin. Su propsito es allegar la suficiente informacin sobre el problema planteado, de manera que el equipo de desarrollo y el cliente puedan establecer los objetivos, el alcance y la factibilidad del proyecto. Termina con un hito donde se decide si el proyecto se lanza o no. - Preparacin. Est orientada fundamentalmente a la definicin de la arquitectura del sistema, lo cual implica continuar el refinamiento del modelo de la organizacin y los requisitos, iniciados en la fase de gestacin, avanzar en el anlisis y el diseo hasta obtener la arquitectura del sistema, e implementar y probar uno o ms prototipos a fin de validar la arquitectura. Finaliza con un hito en el que, por razones de viabilidad tcnica o econmica, todava se puede abortar el desarrollo del proyecto sin que se incurran en grandes prdidas, puesto que an no se ha iniciado la costosa construccin del sistema. - Construccin. Aunque se recorren todos los componentes del proceso de desarrollo, a travs de varias iteraciones, el mayor esfuerzo est centrado en la culminacin del diseo y la implementacin, a partir de la arquitectura definida en la fase anterior. Su hito terminal consiste en la obtencin de la aplicacin informtica requerida, en condiciones de ser operada por sus usuarios finales. - Transicin. Consiste en la transferencia de la aplicacin al cliente, incluyendo su puesta en operacin en las instalaciones de ste, el entrenamiento de los usuarios, y la depuracin de los errores que surgen al final. El hito con el que termina es la entrega final de la aplicacin a satisfaccin del cliente.
Si bien a lo largo del desarrollo del sistema se producen planes de trabajo, glosarios, y otros documentos de tipo textual, el proceso de desarrollo hace muchsimo hincapi en la elaboracin de modelos grficos del sistema, para lo cual se utiliza UML y sus extensiones. Estos modelos, al igual que los otros artefactos, estn asignados a determinados componentes, y se van refinando a medida que avanzan las iteraciones y las fases. La relacin entre componentes y modelos es la siguiente: - Modelado de la Organizacin: Modelo de la Organizacin. - Captura de Requisitos: Modelo de Casos de Uso. - Anlisis: Modelo de Anlisis. - Diseo: Modelo de Diseo. - Implementacin: Modelo de Implementacin. - Pruebas: Modelo de Pruebas.
Como podr apreciarse ms adelante, el Modelo de Casos de Uso es el eje de la dinmica de desarrollo del sistema, pues es en funcin de l que se construyen los dems modelos. Los casos de uso, propuestos por Ivar Jacobson [12], sirven para describir el comportamiento de un sistema en trminos de secuencias de interacciones entre l y las entidades que hacen parte de su entorno, denominadas actores. En el Modelo de la Organizacin, los casos de uso (apellidados de la organizacin) identifican los procedimientos de la organizacin, que son su unidad de funcionamiento. Los Casos de Uso de la Organizacin son la base para obtener los casos de uso de la aplicacin a desarrollar, que integran el Modelo de Casos de Uso. A su vez, son los casos de uso de la aplicacin los que guan la construccin de los dems modelos: - Las clases de los modelos de Anlisis y Diseo se identifican en funcin de los casos de uso, y sus interacciones describen cmo realiza la aplicacin cada caso de uso. - Los casos de uso son implementados finalmente por el cdigo del Modelo de Implementacin. - Los casos de prueba que hacen parte del Modelo de Pruebas son diseados para establecer si el comportamiento de la aplicacin corresponde al establecido en los casos de uso. III. FASE DE GESTACIN Si bien en esta fase se ejecutan tambin otros componentes del proceso de desarrollo, en este artculo se har nfasis en los componentes de Modelado de la Organizacin y Captura de Requisitos. A. Modelado de la Organizacin. Como se indic con anterioridad, su propsito es brindar un entendimiento de la nueva organizacin donde se va a implantar el sistema, en trminos de su estructura (departamentos, empleados, recursos, etc.) y su dinmica (procesos y procedimientos), y a partir de l identificar y comprender los problemas que pueden ser resueltos con el soporte de la aplicacin a desarrollar.
Esta actividad es particularmente importante en el desarrollo de aplicaciones en Internet, pues stas suelen tener un gran impacto sobre el funcionamiento de las organizaciones, que es fcilmente subestimado. Por ejemplo, la introduccin de servicios de comercio electrnico no implican slo la automatizacin de ciertos procesos como venta y proveedura, sino tambin, y ante todo, un anlisis sobre los nuevos mercados que se abren a travs e Internet, una caracterizacin de los nuevos clientes, y una reorganizacin de la empresa a fin de sacar el mejor provecho de la nueva situacin.
Para describir la estructura y funcionamiento de una organizacin se utilizan diversos artefactos obtenidos en el componente de Modelado de la Organizacin [13]. Los ms importantes son el Modelo de Casos de Uso de la Organizacin y el Modelo de Objetos de la Organizacin, los cuales son construidos utilizando los estereotipos de UML mostrados en la Figura 4.
Los Actores de la Organizacin representan los clientes, proveedores, socios y dems entidades externas con las cuales interacta la organizacin.
Los Casos de Uso de la Organizacin representan los procesos y procedimientos que se llevan a cabo en la organizacin, en respuesta a una demanda externa.
Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA. Universidad del Quindo. Armenia, octubre 8 al 12 de 2001 Figura 4. Estereotipos para el Modelado de la Organizacin
Las Entidades de la Organizacin representan los elementos que la organizacin gestiona o produce (unidades de informacin y otros recursos).
El Modelo de Casos de Uso de la Organizacin permite representar los servicios que presta y dems interacciones que tiene la organizacin con su entorno, y las personas y organizaciones con las cuales sostiene esas interacciones. En el ejemplo de la Figura 5a se muestra uno de los Casos de Uso de la Organizacin para una organizacin financiera, llamado Gestionar Prstamo, que representa el servicio de crdito que la entidad ofrece a sus clientes. Figura 5. Artefactos del Modelado de la Organizacin
El Modelo de Objetos de la Organizacin, por su parte, representa la estructura interna de la organizacin, y constituye la base para describir sus procesos y procedimientos. En el ejemplo de la Figura 5b se muestran los trabajadores y entidades de la organizacin financiera que intervienen en la atencin de una solicitud de prstamo de un cliente; los trabajadores son un Asistente y un Analista, y las entidades son la Cuenta que posee el Cliente, su Perfil (historial del cliente en la organizacin), y Crdito (registro de toda la informacin relativa al prstamo). El Cliente es atendido directamente por un Asistente, quien verifica que posea Cuenta en la institucin, consulta su Perfil para establecer si no est inhabilitado para recibir un prstamo, y le solicita la informacin inicial sobre el Crdito (cantidad, plazo, tipo, etc.). A continuacin el Asistente informa al Analista, quien estudia la solicitud del Crdito y el Perfil del cliente y decide la aceptacin o denegacin del prstamo.
Tambin se pueden emplear diagramas de secuencia para representar las interacciones entre los elementos de la organizacin en la realizacin de un Caso de Uso de la Organizacin. B. Captura de Requisitos. Durante la fase de Gestacin se ejecuta tambin el componente de Captura de Requisitos, con la finalidad de delimitar el sistema, y obtener una descripcin inicial de sus interacciones con el exterior y la funcionalidad que debe ofrecer. Esta descripcin inicial es presentada mediante una primera versin del Modelo de Casos de Uso, que consta de un diagrama de Casos de Uso ms una descripcin de los casos de uso a alto nivel.
La Figura 6 muestra los casos de uso Solicitar Prstamo y Estudiar Prstamo, que son derivados del Caso de Uso de la Organizacin Gestionar Prstamo, y Control Acceso, que define el procedimiento de autorizacin inicial de acceso al sistema para el Analista. En las entrevistas con el personal de la organizacin financiera se ha determinado que una de las funciones de la aplicacin a desarrollar es la atencin va web de las solicitudes de crdito de los clientes, las cuales deben ser verificadas por el sistema (la labor desempeada por el Asistente en el Modelo de Objetos de la Organizacin) antes de notificar al Analista; este requisito que la aplicacin debe satisfacer queda expresado en el caso de uso Solicitar Prstamo, cuya descripcin es la siguiente: Figura 6. Diagrama de Casos de Uso
Caso de uso: Solicitar Prstamo Actores: Cliente (iniciador) y Analista Tipo: Primario Descripcin: - El caso de uso empieza cuando el Cliente ingresa a la opcin de solicitar un prstamo. - El Sistema solicita al Cliente su identificacin. - El Cliente ingresa su identificacin. - El Sistema verifica que el Cliente tenga una Cuenta activa. - El Sistema consulta el Perfil del Cliente para establecer si no est inhabilitado para gestionar un crdito. Unidad de la Organizacin Trabajador de la Organizacin Realizacin de Caso de Uso de la Organizacin Entidad de la Organizacin Actor de la Organizacin Caso de Uso de la Organizacin Unidad de la Organizacin Trabajador de la Organizacin Trabajador de la Organizacin Realizacin de Caso de Uso de la Organizacin Realizacin de Caso de Uso de la Organizacin Entidad de la Organizacin Entidad de la Organizacin Actor de la Organizacin Caso de Uso de la Organizacin Caso de Uso de la Organizacin Cliente Gestionar Prstamo
b) Modelo de Objetos de la Organizacin Cliente Solicitar Prstamo Analista Estudiar Prstamo Control Acceso Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA. Universidad del Quindo. Armenia, octubre 8 al 12 de 2001 - El Sistema solicita al Cliente la informacin del Crdito deseado. - El Cliente ingresa la informacin solicitada. - El Sistema registra la informacin y notifica al Analista que hay un nuevo Crdito para su estudio.
Esta es una descripcin de alto nivel, en la que se narra muy brevemente la interaccin del sistema con los actores identificados. El Modelo de Casos de Uso se refina en la fase de Preparacin identificando nuevos casos de uso y utilizando una descripcin extendida para todos ellos, en la que se incluyen los flujos alternativos de accin y las maquetas de las entradas (e.g. formularios de captura de datos) y salidas (e.g. resultados de una bsqueda, listado por impresora) del sistema. IV. FASE DE PREPARACIN En esta fase se avanza en la ejecucin de todos los componentes del proceso de desarrollo hasta obtener la arquitectura del sistema. Este resultado se logra con el concurso de dos actividades de la mayor importancia: anlisis y diseo, las cuales, si bien son incluidas por UP en el mismo componente, en este artculo reciben un tratamiento diferenciado.
Esta seccin se centra de manera exclusiva en los dos componentes mencionados arriba, sin que ello deba interpretarse en el sentido que los otros componentes no jueguen un papel tambin importante en la fase de Preparacin; al final de la seccin anterior se anunci la continuidad del componente de Captura de Requisitos, y no est permitida la aprobacin de la arquitectura sin haberla validado mediante la construccin de al menos un prototipo, lo que involucra los componentes de Implementacin y Pruebas. A. Anlisis Una actividad clave en este componente es la identificacin de las clases del sistema a partir de los requisitos expresados en el Modelo de Casos de Uso. Despus se identifican las relaciones entre las clases y se definen sus atributos y comportamiento, todo lo cual se describe en la Vista Lgica del sistema, utilizando entre otros los Diagramas de Clase para presentar la estructura y los Diagramas de Secuencias de Mensajes para presentar su dinmica.
Para la identificacin de las clases resulta de gran utilidad echar mano de los criterios que permiten identificar tres categoras de clases, ilustradas en la Figura 7, a saber: - Clases de Entidad. Modelan la informacin que maneja el sistema (clase Usuarios). Generalmente son un reflejo del mundo real, no dependen del entorno del sistema, y pueden ser independientes de la aplicacin cuando se utiliza la misma informacin con diferentes propsitos. Se obtienen examinando las responsabilidades del sistema en los casos de uso. - Clases de Frontera. Modelan las comunicaciones con el exterior del sistema, proveyendo interfaces con los usuarios o con otros sistemas (clase IU_Acceso). Dependen, por supuesto, del entorno del sistema. Se obtienen examinando la relacin con cada actor en los casos de uso. - Clases de Control. Modelan la lgica de la aplicacin (clase CtrlAcceso). Son las responsables de coordinar los eventos necesarios para implementar el comportamiento especificado en los casos de uso, por lo cual dependen de la aplicacin. Inicialmente se puede crear una clase de control por cada par actor-caso de uso. Figura 7. Diagrama de Clases de Anlisis
Algunos autores proponen una cuarta categora de Clases de Excepcin, las cuales son las responsables de otorgar robustez al comportamiento del sistema cuando se presentan situaciones fuera de lo normal.
La Figura 7 representa las clases que realizan el Caso de Uso control de acceso del analista al sistema, cuya dinmica est descrita en el Diagrama de Secuencias de la Figura 8. Una vez el Analista ha activado la aplicacin, la clase de control CtrlAcceso invoca a la clase de interfaz IU_Acceso para que le presente el formulario mediante el cual se le solicita su identificacin y su clave. Cuando el Analista las ingresa, IU_Acceso las entrega a CtrlAcceso, que consulta a la clase de entidad Usuarios para verificar la validez de la informacin. Si sta es correcta, CtrlAcceso activa a IU_Menu para que presente el men principal de la aplicacin. Figura 8. Diagrama de Secuencias B. Diseo El diseo comienza por lo general con dos actividades que introducen sendos elementos clave en el desarrollo del sistema. La primera de ellas es la construccin del Modelo Usuarios Analista IU_Acceso CtrlAcceso IU_Menu : Analista : IU_Acceso : CtrlAcceso : Usuarios : IU_Menu Activa Solicita ID+Clave ID+Clave Consulta ID+Clave Activa Muestra Men Ppal Activa ID+Clave Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA. Universidad del Quindo. Armenia, octubre 8 al 12 de 2001 de Implantacin, que describe la arquitectura fsica del sistema y cmo se ejecutan sobre ella los componentes de la aplicacin. La segunda actividad es la elaboracin de un diagrama de subsistemas que, adems de representar los componentes que estn siendo construidos, incluye tambin aquellos que integran el entorno de implementacin.
Otra de las actividades de diseo es la obtencin de las Clases de Diseo, para lo cual obviamente se parte de las Clases de Anlisis, aunque algunas de ellas pueden desaparecer y otras nuevas se incorporan al modelo. Para cada categora de clase se realiza un tratamiento diferente, teniendo en cuenta los elementos clave introducidos en el diseo: la arquitectura fsica y el entorno de desarrollo.
En el caso de las Clases de Control, se deben analizar aspectos como el grado de distribucin del sistema, el rendimiento y la gestin de las transacciones. Se pueden tener clases normales o pasivas, que funcionan bajo demanda, ofreciendo servicios que slo se activan cuando otra clase los requiere. Por otra parte, las clases tambin pueden ser activas, es decir, poseen su propio hilo de ejecucin; en cada nodo fsico de la arquitectura del sistema debe haber al menos una instancia (objeto) de una clase activa, y tambin se las requiere para el manejo de las comunicaciones, el arranque, la reconfiguracin, etc., as como para garantizar ciertos niveles de rendimiento y disponibilidad del sistema. En el caso de las aplicaciones en Internet, estas clases de control, que son las que establecen la lgica de la aplicacin, se pueden implementar en cualquiera de los niveles clsicos de una aplicacin multinivel: en el nivel de interfaz, esto es, en las pginas web; en el nivel de la gestin de los datos, como procedimientos almacenados del gestor de la base de datos; o en el nivel de la lgica del negocio, como componentes independientes de la interfaz y los datos. Cada aplicacin requiere elegir la estrategia ms adecuada para ella.
Las Clases de Entidad, que son las que contienen la informacin del sistema, deben ser analizadas para determinar cules de ellas requieren persistencia, esto es, la capacidad para preservar su estado (los valores de sus atributos) de una ejecucin a otra de la aplicacin. La manera ms comn de lograrlo es mediante el uso de Sistemas de Gestin de Bases de Datos Relacionales, lo cual implica la transformacin de un modelo de objetos, integrado por las instancias de las clases de entidad, en un modelo relacional, integrado por las tablas donde queda finalmente almacenada la informacin. Las herramientas a usar por parte del equipo de desarrollo son las reglas de transformacin de estos modelos (e.g. [16], [17]) y los mecanismos para el acceso a bases de datos relacionales desde aplicaciones orientadas a objetos, los cuales son provistos por los mismos entorno de desarrollo.
El tratamiento de las Clases de Interfaz es el de mayor inters desde el punto de vista del modelado de aplicaciones en Internet, pues estas clases se convierten por lo general en pginas web. La siguiente seccin describe una extensin de UML propuesta para la construccin de modelos de diseo de aplicaciones web. C. WAE: Web Application Extension WAE extiende UML con estereotipos y restricciones (contraints) para permitir el modelado de elementos de la arquitectura especficos de la web como parte del modelo del sistema [10]. Conallen propone un amplio conjunto de estereotipos para la representacin de elementos como pginas web, formularios, marcos, enlaces, servlets, etc., unas reglas de correcta formacin de los modelos, y unas guas para el uso de la extensin. Est ms all del propsito de este artculo explicar en detalle WAE, pero se darn algunos ejemplos de su aplicacin.
La Figura 9 muestra algunos de los estereotipos de WAE. Una pgina Cliente es una unidad de cdigo HTML que es distribuida por el servidor web a sus clientes, que son los navegadores, usando el protocolo HTTP; los navegadores interpretan el cdigo y presentan la informacin que contiene al usuario. Para obtener una Pgina Cliente, el navegador enva al servidor web, usando tambin HTTP, la direccin (URL, Uniform Resource Locator) de la pgina. Figura 9. Estereotipos WAE
Una Pgina Servidora, por su parte, es una se cuencia de comandos (que pueden ser CGI, ASP, JSP, etc.) que son procesados por el mismo servidor. Al igual que las Pginas Cliente tienen una URL que es enviada por el navegador al Base de Datos construye accede distribuye interpreta procesa http Navegador Pgina Cliente Pgina Servidor Servidor Web Base de Datos construye accede distribuye interpreta procesa http Navegador Pgina Cliente Pgina Cliente Pgina Servidor Pgina Servidor Servidor Web a) Pginas Cliente y Servidor
Pagina Cliente Forma Textbox Text area Checkbox Radio button group Selection list Pagina Servidor submits 1 1 0..* Pagina Cliente Pagina Cliente Forma Forma Textbox Text area Checkbox Radio button group Selection list Pagina Servidor Pagina Servidor submits 1 1 0..* Primer Congreso de Electrnica y Telecomunicaciones Armenia, ICETA. Universidad del Quindo. Armenia, octubre 8 al 12 de 2001 servidor web, pero ste, en lugar de distribuir la pgina, ejecuta las instrucciones que contiene. Estas instrucciones pueden ser, por ejemplo, para consultar una base de datos y extraer de ella informacin que interesa al usuario del navegador, y terminan generalmente con la construccin de una Pgina Cliente que contiene la informacin obtenida, y que es enviada entonces por el servidor web al navegador para que se la presente al usuario. Desde el punto de vista de ste, el servidor web le enva la Pgina Cliente construida en forma dinmica, en respuesta a la URL de la Pgina Servidora enviada previamente.
Las Pginas Cliente pueden contener formularios, que son campos de entrada a travs de los cuales el usuario ingresa informacin que luego es procesada en el servidor web; dichos campos pueden ser cajitas de texto, reas de texto con mayor capacidad, cajas de chequeo, grupos de botones de seleccin, y listas de seleccin. Cada formulario de la Pgina Cliente tiene asociada una Pgina Servidora que es la que recibe y procesa la informacin contenida en el formulario.
El Diagrama de Clases de Diseo de la Figura 10 utiliza WAE para representar el refinamiento del Diagrama de Clases de Anlisis de la Figura 7; se muestran tanto las representaciones grficas (conos) de los estereotipos de las clases como los estereotipos de las relaciones entre stas. La Pgina Cliente Acceso, que es la que se le presenta al Analista cuando activa la aplicacin, posee el formulario ID_Clave que contiene las cajitas de texto para ingresar la identificacin y la clave. Cuando se presiona el botn Aceptar, se transmite esta informacin al servidor web, que la entrega a la Pgina Servidora CtrlAcceso. El cdigo contenido en esta pgina consulta Usuarios para verificar si es correcta la informacin ingresada por el Analista, y en tal caso construye la Pgina Cliente Men, probablemente a partir de una plantilla a la que se agrega alguna informacin personalizada para el usuario. La pgina Men ofrece al Analista opciones que lo llevan a otras pginas a travs de enlaces de hipertexto. Figura 10. Diagrama de Clases de Diseo V. CONCLUSIONES La Web se ha convertido en una plataforma de amplsimo alcance para la prestacin de todo tipo de servicios, que exigen el desarrollo y mantenimiento de aplicaciones de complejidad creciente. El modelo de proceso de desarrollo propuesto por UP, con el soporte de UML y sus extensiones para el modelado de la organizacin y las aplicaciones web, y basada en slidos principios que han sido madurados por aos de experiencia, ofrece una gua metodolgica que les permite a los equipos de desarrollo incrementar sus posibilidades de xito al enfrentar el reto de construir tales aplicaciones.
Como lo sealan reiteradamente sus autores, los criterios, tcnicas, modelos y dems elementos de estas metodologas constituyen un marco general que debe ser adaptado para cada equipo de desarrollo y cada proyecto, teniendo en cuenta los niveles de formacin de las personas, los estilos de trabajo, los recursos tcnicos, fsicos y financieros disponibles. REFERENCIAS [1] R.J. Vetter, C. Spell, and C. Ward. "Mosaic and the World-Wide Web". IEEE Computer Magazine, Vol. 27, pp. 49-57, October 1994. [2] D. Raggett, A. Le Hors, I. Jacobs (Eds.). "Hypertext Markup Language -- HTML 4.01 Specification". W3C Recommendation. <http://www.w3.org/TR/html4/>. 24 December 1999. [3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1". RFC 2616. The Internet Society. <http://www.w3.org/Protocols/rfc2616/ rfc2616.html>. June 1999. [4] World Wide Web Consortium. CGI: Common Gateway Interface. <http://www.w3.org/CGI/>. Octubre 1999. [5] Apache Software Foundation. PHP: Hypertext Preprocessor. < http://www.php.net/>. Octubre 2001. [6] Sun Microsystems. Java Servlet Technology. <http://java.sun.com/products/servlet/>. Octubre 2001. [7] Microsoft Corporation. An ASP You Can Grasp: The ABCs of Active Server Pages. <http://msdn.microsoft.com/workshop/server/ asp/ASPover.asp>. Mayo 1997. [8] Object Management Group. CORBA/IIOP Specification. <http://www.omg.org/technology/documents/formal/ corba_iiop.htm>. Septiembre 2001. [9] Microsoft Corporation. Distributed Component Object Model (DCOM). <http://www.microsoft.com/com/tech/DCOM.asp>. Marzo 1998. [10] Jim Conallen. Building Web Applications with UML. Addison- Wesley. 2000 [11] Ivar Jacobson, Grady Booch and James Rumbaugh. The Unified Software Development Process. Addison-Wesley. 1998. [12] I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object- Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley. 1992. [13] Philippe Kruchten. The Rational Unified Process, An Introduction. Addison-Wesley. March 2000. [14] UML Revision Task Force. OMG Unified Modeling Language Specification, v. 1.3. Document ad/99-06-08, Object Management Group. June 1999. [15] Barry Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5):61-72, 1988. [16] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall. 1991. Seccin 17.3 Relational Database Design, pg. 373. [17] Consejo Superior de Informtica. "METRICA versin 3. Metodologa de Planificacin, Desarrollo y Mantenimiento de sistemas de informacin", Ministerio de Administraciones Pblicas, Madrid (Espaa). Julio 2001. Documento 3: "Tcnicas". <http://ns.map.es/csi/metrica3>. Acceso ID_Clave submits CtrlAcceso OpcinX links Menu builds query Usuarios Identificador Clave Acceso Acceso ID_Clave submits CtrlAcceso CtrlAcceso OpcinX OpcinX OpcinX links Menu Menu Menu builds query Usuarios Usuarios Identificador Clave