Metodologia (v1 1)

Framework unificado para desarrollo de interfaces J2EE
Metodologa para el diseo y desarrollo de Interfaces de Usuario

Versin 1.1
Metodologa para el
diseo y desarrollo de
interfaces de usuario
Versin <1.1>
Historia de Revisin
Fecha
Versin
Descripcin
Responsable
20/06/2005
<0.1>
Creacin.
Alejandro Bez
Cristian Castaeda
Diego Castaeda
3/07/2005
<1.0>
Se especifican con mayor Alejandro Bez

detalle las etapas de la
Cristian Castaeda
metodologa y se analizan
nuevos
aspectos
de
las Diego Castaeda
interfaces grficas
25/07/2005
<1.1>
Se aadi el diagrama para Alejandro Bez

modelamiento de procesos.
Cristian Castaeda
Diego Castaeda
INVESTIGADORES:
ALEJANDRO BAEZ
CRISTIAN CASTAEDA
DIEGO CASTAEDA
DIRECTOR:
JAVIER SNCHEZ

Versin 1.1
TABLA DE CONTENIDO
TABLA DE CONTENIDO .......................................................................... 2
1. Introduccin......................................................................................................... 4
2. Anlisis, diseo, implementacin y pruebas de una aplicacin en J2EE ............ 5
2.1 Modelo de negocio ........................................................................................ 5
2.2 Anlisis de requerimientos............................................................................. 8
2.2.1 Documento de requerimientos ................................................................ 9
2.2.1.1 Definicin de los usuarios del Sistema ............................................. 9
2.2.1.2 Requerimientos Funcionales ............................................................ 9
2.2.1.3 Requerimientos No Funcionales..................................................... 10
2.2.1.3.1 Requerimientos de interfaz .......................................................... 10
2.2.2 Documento de casos de uso ................................................................. 10
2.2.2.1 Definicin de actores ...................................................................... 11
2.2.2.2 Definicin de casos de uso ............................................................. 11
2.2.2.3 Diagrama de casos de uso ............................................................. 12
2.3 Diseo del sistema ...................................................................................... 13
2.4 Diseo de la lgica del negocio ................................................................... 14
2.4.1 Modelo entidad relacin ........................................................................ 14
2.4.2 Modelo de clases persistentes: ............................................................. 15
2.4.3 Modelo de acceso a los datos (Patrn DAO) ........................................ 15
2.4.4 Definicin de servicios........................................................................... 15
2.5 Diseo de las interfaces de usuario ............................................................. 16
2.6 Implementacin ........................................................................................... 16
2.7 Pruebas ....................................................................................................... 16
3. Relacin con RUP ............................................................................................. 16
3.1 Qu es RUP? ............................................................................................ 17
3.1.1 Fase de Inicio........................................................................................ 17
3.1.2 Fase de Elaboracin ............................................................................. 18
3.1.3 Fase de Construccin ........................................................................... 18
3.1.4 Fase de Transicin................................................................................ 18
3.1.5 Artefactos .............................................................................................. 18
Artefacto .............................................................................................. 19
3.2 RUP en nuestra metodologa....................................................................... 19
4. Interfaz grfica J2EE ......................................................................................... 22
4.1 Elementos funcionales de una interfaz grafica ............................................ 23
4.1.1 Validaciones .......................................................................................... 23
4.1.2 Informacin a presentar y recolectar ..................................................... 24
4.1.3 Relacin entre datos ............................................................................. 24
4.1.4 Flujo de Pginas.................................................................................... 24
4.2 Elementos de diseo de una interfaz grafica ............................................... 25
4.2.1 Diseo estructural ................................................................................. 25
4.2.1.1 Encabezado.................................................................................... 26
4.2.1.2 Men............................................................................................... 26

Versin 1.1
4.2.1.3 Zona de Contenido ......................................................................... 26

4.2.1.3 Hojas de Estilo................................................................................ 26
4.2.2 Componentes ........................................................................................ 26
4.2.3 Zona de Mensajes................................................................................. 27
4.2.4 Diagrama de navegabilidad................................................................... 27
5. Otros problemas................................................................................................ 28
5.1 Seguridad................................................................................................. 28
5.2 Reportes................................................................................................... 28
5.3 Performance............................................................................................. 29
5.4 Integracin con otro Software .................................................................. 29

Versin 1.1
1. Introduccin
Uno de los principales problemas en el desarrollo de aplicaciones J2EE es el poco
conocimiento que se tiene de cmo unir la lgica del negocio con la forma en que
se presentara esta a los usuarios finales del software. Es por eso de vital
importancia para el desarrollo de este proyecto, la definicin de una metodologa
que nos ayude a decir como se debe realizar este proceso, para reducir la
complejidad inherente de este tipo de desarrollos.
El objetivo de este documento es presentar una metodologa para el anlisis,
diseo, implementacin y pruebas en desarrollos de software en J2EE, adems de
esto definir como disear las interfaces graficas de usuario en este tipo de
aplicaciones y describir algunos problemas que se deben tener en cuenta en el
desarrollo de interfaces pero que van mas all del alcance de este proyecto.

Versin 1.1
2. Anlisis, diseo, implementacin y pruebas de una

aplicacin en J2EE
Desarrollando el caso de prueba de nuestro proyecto1, se han podido identificar
una serie de etapas que se deben realizar para la construccin de aplicaciones
J2EE. Estas etapas son un modelo general que hemos desarrollado a partir de
nuestra experiencia, pero el orden y cumplimiento de las fases no es obligatorio,
depende de las caractersticas especificas de la aplicacin.
A continuacin se muestran las etapas que consideramos se deben realizar en la
construccin de una aplicacin J2EE:
Modelo de negocio
Anlisis de requerimientos
Diseo del sistema
Diseo de la lgica del negocio
Diseo de las interfaces de usuario
Implementacin
Pruebas
2.1 Modelo de negocio

En esta etapa, se deben definir cuales son los procesos y procedimientos que se
tienen en el escenario para el cual se va a desarrollar la aplicacin. Esto permite
identificar los casos concretos que debe automatizar el sistema, la relacin que
debe existir entre la ingeniera de software y el negocio, con el fin de aclarar el
enfoque que quiere tener el cliente con el software.
Un procedimiento se puede entender como un mtodo estructurado para ejecutar
una tarea. Un proceso es un conjunto de procedimientos que se deben realizar
para alcanzar un objetivo, el cual representa una funcin que debe cumplir para el
escenario que se estudiando.
Tpicamente de un procedimiento se debe conocer:
ID: identifica de manera nica un procedimiento.

Nombre: identificador nico del procedimiento.
Objetivo: Indica la finalidad que se busca alcanzar con el desarrollo del
procedimiento.
Predecesor: Indica un procedimiento que se debe realizar antes de
realizar el procedimiento.
Personas implicadas: Indica las personas encargadas en desarrollar el
procedimiento.
Remitirse a los documentos de requerimientos, casos de uso y arquitectura de la videotienda en la pagina

http://pegasus.javeriana.edu.co/~fwj2ee/

Versin 1.1
Impacto: Indica los efectos producidos por la ejecucin del

procedimiento.
Tiempo de realizacin: Indica el tiempo promedio de duracin del
procedimiento.
Descripcin: Indica de manera detallada todos los pasos que se deben
cumplir para la realizacin del procedimiento.
Resultados esperados: Indica los resultados que se deben obtener luego
de la realizacin del procedimiento.
Para un proceso se deben conocer:
Nombre: identificador nico del proceso

Objetivo: Indica la finalidad que se busca alcanzar con el desarrollo del
proceso.
Alcance: Define de manera especfica las reas, departamentos,
procesos, etc. que van a ser afectadas por el proceso y sus resultados.
Importancia: Indica el nivel de prioridad del proceso respecto a otros.
Tiempo de realizacin: Indica el tiempo promedio de duracin del
proceso.
Procesos con los que se relaciona: Indica los procesos que intervienen o
se ven afectados con el desarrollo del proceso.
Resultados esperados: Indica los resultados que se deben obtener luego
de la realizacin del proceso.
Procedimientos implicados: Indica el conjunto de procedimientos que
incluye el desarrollo de este proceso.
Para la recoleccin de la informacin de procesos y procedimientos hemos

definido el siguiente formato:
Numero del proceso:
Nombre del Proceso:
Objetivo:
Alcance:
Importancia:
Tiempo:
Procesos relacionados:
Resultados esperados:
Procedimientos
ID Nombre
Objetivo
Predecesor Personas Implicadas Impacto Tiempo Descripcin Resultados
Luego de llenar este formato para todos los procesos que se quieren analizar, se
podr determinar que procesos van a ser automatizados por el sistema. Para
estos procesos se debern realizar las etapas posteriores de la metodologa. Con
el fin de tener ms criterios para determinar estos procesos que va a ser

Versin 1.1
automatizados, es til realizar un grfico propuesto por JBOSS2 que represente el

flujo de un proceso.
Para construir este grfico es importante tener en cuenta los siguientes conceptos:
Nodo de Inicio: Representa el comienzo del flujo de un proceso y se

identifica de la siguiente forma:
Nodo de Fin: Es el nodo que indica el final de un proceso y se representa

de la siguiente manera:
End
Nodo de Decisin: Es el nodo que indica una o varias opciones para

continuar el flujo del proceso, basado en un criterio de decisin; se
representa de la siguiente manera.
Criterio 1
Nodo de Procedimiento: Este nodo representa una o varias actividades a

ser realizadas, en este punto del flujo del proceso.
Tarea 1
Nodo de Divisin de tareas concurrentes: Este nodo divide el proceso en

varios flujos, que se llevaran a cabo en paralelo; al final de los mismos se
deben unificar usando este mismo nodo. Grficamente se representa de la
siguiente manera:
Transiciones: Accin que implica al flujo un cambio de estado, se

representa con una flecha y la accin a tomar.
Facturacin
Un ejemplo que presenta JBOSS para la explicacin es el manejo de una subasta

en un sitio de Internet:
Process Modelling, JBOSS, http://www.jbpm.org/3/processmodelling.html

Versin 1.1
2.2 Anlisis de requerimientos

El anlisis de requerimientos es la etapa mas importante del desarrollo de
software, para poder hablar de ella primero tenemos que definirla; Para esto
utilizaremos la siguiente definicin que hace Microsoft: El anlisis de
requerimientos es la primera etapa de un proyecto software, en ella se tratan de
definir las condiciones o capacidades necesarias para uno o varios usuarios con el
fin de solucionar un problema o conseguir un objetivo.3
Como se indica en esta definicin, el objetivo de el anlisis de requerimientos es
determinar las condiciones o capacidades que debe cumplir el sistema que se
quiere disear para satisfacer las necesidades de un grupo de usuarios. Para
lograr esto utilizaremos la definicin de requerimientos. Un requerimiento se puede
entender como una descripcin informal de las necesidades y deseos que tiene el
usuario final respecto a un producto de software.
Para lograr el levantamiento de estos requerimientos consideramos que se deben
construir los siguientes artefactos: documento de requerimientos y el documento
de casos de uso.
3
Para Mayor Informacin dirjase a: Http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/ingenieria/analisis.asp

Versin 1.1
2.2.1 Documento de requerimientos

En el documento de requerimientos se especifican las caractersticas y
funcionalidades que debera cumplir el sistema, para satisfacer los procesos y
procedimientos que se han determinado para ser automatizados. Este documento
debe contener al menos la siguiente informacin4:
Definicin de los usuarios del sistema

Requerimientos Funcionales
Requerimientos no funcionales
Requerimientos de Interfaz
Glosario
Este anlisis servir como base para el diseo de la aplicacin.

2.2.1.1 Definicin de los usuarios del Sistema
En esta seccin del documento de requerimientos se busca identificar las
caractersticas de los usuarios que interactuaran con el sistema. Para esto se
utilizara la definicin de roles. Un rol es un conjunto de funciones que debe cumplir
el papel de una persona que interacta con el sistema.
Para la definicin de un rol, se deben especificar los siguientes elementos:
Nombre: identificador nico de un grupo de usuarios que interactan con el

sistema.
Funciones: Conjunto de tareas que cumplen este tipo de usuarios.
Privilegios: Conjunto de derechos que deben tener este tipo de usuarios
dentro del sistema.
2.2.1.2 Requerimientos Funcionales

Los requerimientos funcionales son todas las funcionalidades que debe satisfacer
el sistema para cumplir con las necesidades de los usuarios, a partir del anlisis
del negocio que se halla hecho.
Para la definicin de los requerimientos funcionales se deben especificar los
siguientes elementos.
Id: Identifica de manera nica un requerimiento.

Nombre: identificador de un requerimiento.
Descripcin: Indica una funcionalidad que debe cumplir el sistema.
Prioridad: indica la importancia de un requerimiento(Baja, Media, Alta).
Para mas informacin remitirse al estndar IEEE 830-1998 (SRS)

Versin 1.1
2.2.1.3 Requerimientos No Funcionales

Los requerimientos no funcionales son todos aquellas caractersticas que debe
cumplir el sistema para responder de manera adecuada a todos los requerimientos
Funcionales y a las caractersticas de funcionamiento que requiera el usuario.
Para la definicin de los requerimientos no funcionales se deben identificar lo
siguientes elementos:
Id: Identifica de manera nica un requerimiento.

Nombre: identificador de un requerimiento.
Descripcin: Indica una caracterstica del sistema que ayudara a satisfacer
los requerimientos funcionales
Prioridad: indica la importancia de un requerimiento(Baja, Media, Alta).
2.2.1.3.1 Requerimientos de interfaz

Los requerimientos de interfaz son todos aquellos elementos que debe proveer el
sistema para permitir la interaccin entre el usuario y las funcionalidades que este
tiene, con el fin de que en el proceso de diseo se tenga claridad de las interfaces
que se deben crear y la relacin que debe existir entre ellas.
Para la definicin de los requerimientos de interfaz se deben identificar lo
siguientes elementos:
Id: Identifica de manera nica una interfaz grfica

Descripcin: Indica los elementos que debe tener la interfaz.
Requerimientos asociados: Indican las funcionalidades asociadas a la
interfaz grfica.
En este nivel, no se va definir de manera detallada la interfaz, solo se pretende

tener una primera aproximacin a los elementos que deben ser tenidos en cuenta
en el desarrollo de estas.
2.2.2 Documento de casos de uso

Luego de desarrollar el documento de requerimientos, se debe construir el
documento de casos de uso. Este documento consiste bsicamente en la
definicin de un conjunto de casos de uso. Un caso de uso es: narracin que
describe la secuencia de eventos de un actor (agente externo) que utiliza un
sistema para completar un proceso5.
UML y Patrones, Larman, 1999.

Versin 1.1
La definicin de estos casos de uso es til para conocer los procesos del dominio
y el ambiente externo, dentro de los cuales se ejecutan los requerimientos
anteriormente descritos.
El documento de casos de uso deber contener al menos la siguiente informacin:
Definicin de actores
Definicin de casos de uso
Diagrama de casos de uso
2.2.2.1 Definicin de actores

En esta seccin del documento de casos de uso, se especificaran el tipo de
personas que de alguna manera interactan en alguno de los procesos del
sistema, estos actores estimulan al sistema con eventos de entrada o la recepcin
de algn resultado que este produzca.
Para la definicin de los actores se deben identificar los siguientes elementos:
Nombre: Identifica de manera nica un tipo de actor.

Papel: Indica el tipo de estimulacin que ejerce el actor sobre el sistema.
2.2.2.2 Definicin de casos de uso

En esta seccin del documento de casos de uso, se definen de manera formal
todos los casos de uso en los cuales se ejecutan cada uno de los requerimientos
funcionales que se especificaron en el documento de requerimientos (vase 2.2.1)
Para la definicin de cada caso de uso se deben tener en cuenta al menos los
siguiente elementos:
Nombre: Identifica de manera nica un caso de uso.

Actores involucrados: Indica los actores que de alguna manera participan
en el desarrollo del caso de uso.
Propsito: Indica la finalidad que se busca con el caso de uso.
Resumen: Breve descripcin de los eventos que se realizan en el caso de
uso.
Tipo: Indica si la implementacin del caso de uso es opcional u obligatoria.
Importancia: Indica el nivel de prioridad del caso de uso(Baja, Media, Alta).
Curso normal y alterno de los eventos: Indica la secuencia de eventos que
suceden en la realizacin del caso de uso, especificando un curso normal y
alterno, dependiendo si se presenta o no algn evento inesperado que
afecte el desarrollo del caso de uso.
Requerimientos que satisface: Hace una referencia a los identificadores de
los requerimientos que satisface el caso uso.

Versin 1.1
2.2.2.3 Diagrama de casos de uso

En esta seccin del documento de casos de uso, se presenta el diagrama de
casos de uso. Un diagrama de casos de uso Explica grficamente un conjunto de
casos de uso de un sistema, los actores y la relacin entre estos y los casos de
uso.6
Para mayor informacin para la realizacin de estos diagramas a la especificacin
de UML7.
6
7
UML y Patrones, Larman, 1999.

UML (Unified Model Language), http://www.uml.org/

Versin 1.1
2.3 Diseo del sistema

En el diseo del sistema se pretende definir la arquitectura que utilizara la
aplicacin, con el desarrollo del caso de prueba, hemos credo que es conveniente
utilizar una arquitectura multicapas, donde se tendrn al menos las siguientes
capas:
Interfaz (Web): Se encarga de la presentacin de la aplicacin al usuario.

Servicios (negocio y Web): Se encarga de definir un conjunto de
funcionalidades para que la capa de interfaz se las presente al usuario.
Manejador de persistencia: Se encarga de establecer un puente para que la
capa de servicios acceda a la informacin que reside en la base de datos.
Base de datos: Se encarga de mantener de manera persistente la
informacin del sistema.
Este tipo de arquitectura se puede considerar genrico para el desarrollo de

aplicaciones J2EE; en nuestro caso hemos decidido utilizar los siguientes
frameworks:
Interfaz: Java Server Faces (JSF), Tapestry

Servicios: JBoss y Tomcat
Manejador de persistencia: Hibernate
Base de datos: Oracle
Grficamente la arquitectura es:
Tomcat
Inter
net
JBOSS
ORACLE
HIBERNATE
La herramienta que se desarrollara, servir para la creacin de aplicaciones con la

arquitectura anteriormente descrita.

Versin 1.1
2.4 Diseo de la lgica del negocio

En esta etapa se deber disear un modelo apropiado para satisfacer los
requerimientos y casos de uso que se especificaron en etapas anteriores
utilizando la arquitectura que se ha definido.
Realizando nuestro caso de prueba, hemos podido identificar los siguientes items
que al menos se deben realizar8:
Modelo entidad relacin

Modelo de clases persistentes
Modelo de acceso a los datos (Patrn DAO9)
Definicin de servicios
2.4.1 Modelo entidad relacin

El modelo entidad relacin es uno de los modelos conceptuales mas utilizados
para el diseo de bases de datos, el propsito de este modelo es simplificar el
diseo de bases de datos a partir de descripciones textuales de los
requerimientos10.
Para la construccin de este modelo se utilizan fundamentalmente los siguientes
elementos:
Entidad: Abstraccin que representa un objeto de la vida real.

Atributo: Caracterstica que representa un aspecto comn de la entidad
Relacin: Representa una interaccin entre entidades.
Luego del proceso de anlisis del sistema, se deben establecer un conjunto de

entidades, con sus atributos, que permitan representar todos los objetos que estn
involucrados en el problema a solucionar. Con este conjunto de entidades y con el
documento de casos de uso, se debern establecer las relaciones entre estas.
El objetivo del modelo de entidad relacin es representar grficamente estas
entidades y las relaciones que existen entre ellas, as como definir la estructura
que debe existir en la base de datos11.
El orden de realizacin de estos productos no es estricto. Se puede utilizar otros diagramas tiles para el diseo, para
mayor informacin remtase a la especificacin de UML.
9
Data Access Object, patrn que sirve para encapsular y administrar el acceso a los datos.
10
Modelo entidad relacin, http://alvherre.atentus.cl/modBasico/node3.html
11
Para mayor informacin: SILBERSCHATZ, A., et al. Fundamentos de Bases de Datos. Cuarta Edicin. McGraw Hill. 2002

Versin 1.1
2.4.2 Modelo de clases persistentes:

Este modelo sirve para hacer un mapeo entre la informacin que se encuentra
almacenada en la base de datos y los objetos que se tendrn dentro de la
aplicacin. Es importante aclarar que en este modelo no representara
directamente todas las funcionalidades que debe tener el sistema, sino que servir
como soporte al patrn DAO. En trminos de nuestro contexto, cada una de estas
clases es un POJO12.
2.4.3 Modelo de acceso a los datos (Patrn DAO)

Este modelo sirve para separar el acceso a los datos con la lgica del negocio,
esto permite que se defina un nivel mas que permita la proteccin a la integridad y
consistencia de los datos.
Consiste en definir un conjunto de clases que tendrn un grupo de mtodos que
se encargan de todas las operaciones sobre los POJOs que se definieron en el
modelo de clases persistentes. Tpicamente se tendrn que ofrecer operaciones
CRUD13 y bsquedas.
2.4.4 Definicin de servicios

En esta fase se debern definir un conjunto de servicios que se deben proveer
para satisfacer a los requerimientos y funcionalidades que fueron definidos
anteriormente para la aplicacin, es decir, se encargaran de implementar la lgica
del negocio. Estos servicios sern utilizados por el servidor Web para establecer
un puente entre la lgica del negocio y la presentacin.
Para nuestro contexto, consideramos que para un servicio se deben definir:
Precondicin: Es una condicin que ha de satisfacerse justo antes del

comienzo de la ejecucin de un servicio.
Poscondicin: Indica cual debe ser el estado de los datos despus de
haber realizado el servicio.
Definicin: Da una descripcin de lo que debe hacer el servicio
Prototipo del mtodo: Muestra el prototipo de cmo se implementara el
servicio.
Con la definicin de los servicios, se puede tener claro como van a ser
implementados los requerimientos funcionales del sistema; esta informacin ser
vital para el proceso de integracin de la aplicacin.
12
13
Persistent Old Java Object, objeto al cual solo se le definen los atributos, los set y get para accesarlos.
Create, Read, Update, Delete. Operaciones que bsicamente se hacen sobre los datos

Versin 1.1
2.5 Diseo de las interfaces de usuario

Una de las etapas a las que menos tiempo se les invierte es al diseo de las
interfaces graficas, por tal razn en el momento de implementarlas no se tiene
claro que es lo que se debe hacer, generando errores e inconsistencias lo que
hace que su desarrollo sea lento y complejo.
Por eso es una buena prctica, establecer en los cronogramas un tiempo para el
diseo de estas, para evitar que estos problemas se presenten. El problema del
diseo de las interfaces grficas se analizara al detalle en la seccin 4 de este
documento.
2.6 Implementacin
En esta etapa se debe llevar a la realidad todo lo que se ha descrito en los
modelos de las fases anteriores. Para tener un buen proceso de implementacin
se recomienda tener en cuanta los siguientes aspectos:
Manejo de versiones
Definicin de iteraciones
Documentacin
Estos aspectos se van tratar con mas detalle en la seccin 3, donde se establece
la relacin entre nuestra metodologa y RUP.
2.7 Pruebas
La ultima etapa de nuestra metodologa, busca asegurar que las funcionalidades
implementadas en el sistema funcionen de acuerdo a las especificaciones, para
esto se deben definir un conjunto de pruebas que nos ayuden a verificar esto.
La definicin de las pruebas y la administracin podrn ser manejadas con RUP,
ver la seccin 3.
3. Relacin con RUP

En la actualidad una de las metodologas mas utilizadas para desarrollos de
software es RUP (Rational Unified Process), por eso es de vital importancia para
la especificacin de nuestra metodologa, establecer como podemos entender
nuestras etapas segn el ciclo de vida que se define en RUP. Para poder
establecer esta relacin, primero debemos definir que es RUP.

Versin 1.1
3.1 Qu es RUP?
RUP es un proceso de Ingeniera de Software en el cual se especifican una serie
de tareas que se deben realizar con el fin de asegurar un producto de Software de
alta calidad a sus usuarios finales.
Dentro de RUP se pueden identificar cuatro etapas que son:
Inicio
Elaboracin
Construccin
Transicin
En cada una de estas etapas se propone la ejecucin de una serie de disciplinas,

que se deben ejecutar de forma iterativa para cada una de las fases. Estas
disciplinas son:
Modelamiento del negocio: Busca identificar el negocio, para el cual se

realizara el proyecto.
Levantamiento de requerimientos: Identifica los procesos que deben ser
automatizados, la manera como se deben proveer estos y los objetivos del
proyecto.
Anlisis y Diseo: Se busca determinar una solucin para alcanzar los
objetivos del proyecto.
Implementacin: Disciplina donde se busca llevar a la realidad la solucin
que se defini en el anlisis y diseo.
Pruebas: Busca comprobar la correcta implementacin de la solucin
dada.
Cada una de estas disciplinas se debe realizar en mayor o menor medida

dependiendo de la fase del proyecto en que se encuentre; A continuacin
especificaremos cuales son los objetivos de estas fases.
3.1.1 Fase de Inicio

La fase de Inicio tiene los siguientes objetivos:
Establecer el objetivo y el alcance del proyecto de Software.

Determinar requerimientos y casos de uso.
Dar una primera aproximacin de la arquitectura en la cual se desarrollar el
proyecto de Software.
Estimar los costos y el cronograma del proyecto de Software
Estimar los riesgos potenciales del proyecto de Software.
Preparar un ambiente de soporte para el proyecto.

Versin 1.1
3.1.2 Fase de Elaboracin

La fase de Elaboracin tiene los siguientes objetivos:
Asegurar que la arquitectura escogida cumpla los requerimientos y planes

previamente establecidos.
Definir los riesgos que la arquitectura escogida pueda traer al proyecto.
Establecer una lnea de base de la arquitectura para mitigar los riesgos en los
distintos escenarios y que soporte los requerimientos especificadas a un costo
y tiempo razonable .
Construir un prototipo que permita visualizar al usuario final una posible
solucin del problema con el fin de mitigar riesgos en el futuro y adems
levantar nuevos requerimientos del sistema.
3.1.3 Fase de Construccin

La fase de construccin tiene los siguientes objetivos:
Minimizar los costos y optimizar los recursos del proyecto.

Alcanzar los niveles de calidad adecuados.
Utilizar un control de versiones que sean practicas y rpidas.
Completar el anlisis, diseo y desarrollo y probar todos los requerimientos
funcionales.
Iterativamente e incrementalmente desarrollar la totalidad del producto.
Permitir la modularidad del producto con el fin de tener equipos de software
que desarrolle en paralelo.
3.1.4 Fase de Transicin

La fase de transicin tiene los siguientes objetivos:
Prueba para validar el nuevo sistema ante las expectativas del usuario final.
Capacitacin a usuario y administradores del sistema
Valorar si la lnea base del desarrollo cumple con la visin del proyecto y los
criterios de aceptacin de este.
Establecer un plan de soporte para el proyecto.
3.1.5 Artefactos
Debido a que el proceso de RUP es iterativo, no se puede definir claramente en
que etapa se deben desarrollar los diferentes artefactos que propone RUP, en
trminos generales consideramos que los siguientes artefactos son los mas
importantes que define este proceso:

Versin 1.1
Artefacto
Modelo de Casos de
Uso del negocio
Descripcin
Disciplina
Relaciona los casos de uso del
Modelo del Negocio
negocio con sus actores y
relaciones.
Modelo de Objetos
Relaciona en un modelo la
Modelo del Negocio
del Negocio
organizacin las entidades y
trabajadores del negocio.
Especificacin de
Identifica las necesidades que debe
Levantamiento de
requerimientos
satisfacer el sistema.
requerimientos
Casos de Uso
Identifica un escenario, los eventos y
Levantamiento de
actores para la realizacin de un
requerimientos
proceso del negocio.
Modelo de Casos de Relaciona grficamente los casos de
Levantamiento de
Uso
uso.
requerimientos
Especificacin de Define la arquitectura sobre la que se
Anlisis y Diseo
arquitectura
desarrollara el software
Modelo de datos
Define el modelo sobre el cual se
Anlisis y Diseo
creara la base de datos.
Diseo de clases
Define la forma en que se
Anlisis y Diseo
implementara la solucin.
Diseo de paquetes
Identifica los paquetes con los que
Anlisis y Diseo
se implementaran la solucin.
Pantallas
Define las interfaces de usuario.
Anlisis y Diseo
Mapa de Navegacin
Indica la navegacin entre las
Anlisis y Diseo
pantallas de usuario.
Plan de Pruebas
Define las pruebas que se le
Implementacin
realizara al software
Cdigo Fuente
Implementacin de la solucin.
Implementacin
Resultado de
Documenta los resultados de las
Pruebas
pruebas
pruebas.
Esta seccin es una breve introduccin al proceso de RUP, fue extrada de el
documento About the RUP Configuration for Java Developers14.
3.2 RUP en nuestra metodologa

Como pudimos darnos cuenta en la anterior seccin RUP ofrece una metodologa
de desarrollo, donde se pueden identificar una serie de etapas, que aunque
independientes se relacionan de manera muy fuerte por su proceso iterativo, esta
relacin es muy importante para que se pueda asegurar la calidad en el desarrollo
del software. En nuestra metodologa hemos podido identificar una serie de
14
RUP Configuration for Java Developers, Version 2002.05.20, Rational Software Corporation

Versin 1.1
disciplinas, que aunque no son exactamente iguales a las que propone RUP,
buscan cumplir con ese criterio de calidad.
A continuacin, asociaremos nuestras disciplinas con las cuatro etapas que
propone RUP:
En el grafico nos podemos dar cuenta, que nuestras disciplinas estn pensadas
para realizarse mediante un proceso iterativo. Esto quiere decir que luego de
realizarse por completo cada una de estas disciplinas se va a realizar nuevamente
con base a la versin anterior, mejorndola hasta que cumpla con las necesidades
planteadas.
Por otra parte nuestros artefactos aunque no son iguales a los que RUP propone,
son capaces de alcanzar los objetivos que la metodologa da para cada caso. A
continuacin, vamos a relacionar nuestros artefactos con las diferentes disciplinas
que propone RUP:
Artefactos
Modelo del Negocio
Documento de Requerimientos
Documento de Casos de Uso
Modelo entidad relacin
Modelo de clases persistentes
Modelo de acceso a los Datos
Disciplinas RUP
Modelo del Negocio
Levantamiento de requerimientos
Levantamiento de requerimientos
Anlisis y Diseo
Anlisis y Diseo
Anlisis y Diseo

Versin 1.1
Documento de Interfaces de usuario

Implementacin(Cdigo Fuente)
Pruebas
Anlisis y Diseo
Implementacin
Pruebas
De esta manera podemos ver como asociar la metodologa propuesta con el

proceso que realiza RUP, logrando seguir este pero con los pasos que en la
metodologa se proponen.

Versin 1.1
4. Interfaz grfica J2EE

En nuestra metodologa encontramos la definicin detallada de las interfaces
grficas, una nueva etapa en los desarrollos comunes de software. En esta
seccin se encuentran los pasos a seguir en el diseo y construccin de las
mismas.
Las pantallas deben permitir una forma de interaccin entre el usuario y todas las
funcionalidades que ofrece el sistema, cada una de ellas debe al menos presentar
una funcionalidad para que su creacin este justificada.
Los elementos que se deben definir para cada pantalla son:
Informacin a presentar o recolectar

Validaciones
Relacin entre datos
Flujo de paginas
Los elementos comunes entre pantallas que se podran definir son:
Encabezado (Opcional)
Men (Opcional)
Zona de Contenido
Hojas de estilo (CSS)15
Zona de mensajes (error, xito)
Una practica recomendable para verificar la completitud entre las paginas

definidas y las funcionalidades del sistema es llenar una matriz como la que se
muestra a continuacin:
Pagina 1
Funcionalidad 1
Funcionalidad 2
....
Funcionalidad n
Pagina 2
X
....
Pagina m
X
X
X
El marcar la interseccin entre una pagina y una funcionalidad, indica que la

pagina implementa esa funcionalidad.
15
Las hojas de estilo en cascada permiten estandarizar la forma de presentacin de los componentes en una
pagina. Para mas informacin http://www.csszengarden.com/

Versin 1.1
En esta seccin se describe en detalle componentes y caractersticas de las

interfaces grficas en desarrollos J2EE. Para llevar esto acabo dividimos los
elementos de una interfaz grfica en dos: los que hacen referencia a su
funcionalidad y los que corresponden al diseo de la interfaz.
4.1 Elementos funcionales de una interfaz grafica

Los elementos funcionales de una interfaz grfica son los que definen el
comportamiento de la misma, es decir aquellos cuyo objetivo es asegurar el
funcionamiento adecuado y coherente de las pantallas del sistema, teniendo en
cuenta los requerimientos que fueron planteados y que se necesita sean
satisfechos.
Para un correcto desempeo por parte de los mismos es necesario que trabajen
conjuntamente, debido a que todos formarn el sistema y todos hacen que sea
mas claro el funcionamiento del mismo.
Entre los elementos a tener en cuenta encontramos:
4.1.1 Validaciones
Validacin: Una validacin se lleva a cabo cuando se compara un dato con un
valor esperado, buscando coherencia e integridad.
Las validaciones que se van tener en cuenta son:
Tipo: Se evala el dato respecto al tipo que se especifico que deba ser.
Los tipo que se tendrn en cuenta son:
o Nmeros (Enteros y decimales).
o Cadena de Caracteres
o Fechas.
Longitud: Dependiendo de la longitud mnima o mxima que se requiera

se evaluar si el dato cumple con esta caracterstica.
Obligatoriedad: Se valida si en algunos casos el usuario tiene que llenar

un campo para realizar una operacin.
Caracteres Especiales: Dependiendo si el usuario necesita que algn

tipo de dato tenga o no caracteres especiales se debe verificar si cumple
con el requisito.
Valores mximos(mnimos): En algunas aplicaciones los datos deben

estar entre unos limites establecido segn los requerimientos del
sistema. Esto tambin debe ser evaluado

Versin 1.1
Las validaciones que se generen pueden ser agrupadas en cdigo

reutilizable(clase), que funcione para todas las pantallas que requieran las
mismas.
4.1.2 Informacin a presentar y recolectar

La informacin a presentar depender del rol del usuario del sistema ya que cada
uno tiene un nivel de acceso limitado, lo anterior para proteger la confidencialidad
de los datos. As mismo los datos que se obtienen tienen que estar acordes con la
peticin y ser consistentes en ntegros respecto a los almacenados en la base de
datos.
Los datos a recolectar deben tener coherencia respecto a lo que se necesita,
usando las validaciones para asegurar que sean correctos.
Se debe definir previamente que se va a mostrar y recolectar, donde y de que
forma para cada una de las pantallas que se van desarrollar. Si desea ver un
ejemplo dirigirse a el documento de descripcin de pantallas: Caso de prueba
videotienda.
4.1.3 Relacin entre datos

Es importante que el contenido de las interfaces a generar este previamente
representado, ya que son las bases de la construccin y sin estas podran
presentarse informacin no valida, incompleta, desordenada o fuera de las
expectativas del cliente.
Hemos definido entonces un lenguaje para modelar la relacin existente entre los
datos, con el fin de especificar la descripcin de cada una de las interfaces
dependiendo de los datos que se necesitan y se quieren mostrara ante los usuario
finales.
Para mayor informacin dirigirse al documento Patrones para la descripcin
formal de interfaces de usuario
4.1.4 Flujo de Pginas

El flujo de paginas
Para el flujo que se lleva a cabo en cada accin vamos a utilizar los diagramas de
secuencia propuestos por UML, con la siguiente modificacin: Los diagramas de
secuencias comunes muestran el curso normal de un caso de uso, y su transito
por cada una de las clases. En nuestro caso, en vez de clases las cajas
representarn pantallas, por donde transitar el sistema para responder a un
evento.
Diagrama de Secuencia Modificado:

Versin 1.1
El diagrama de secuencia describir el curso particular de eventos para cada uno

de los casos de uso, mostrando la navegacin a travs de las pantallas definidas,
incluyendo los autores y los eventos generados en dichas operaciones
En el diagrama de secuencia se tiene los elementos:
Pantalla X
Pantallas: Dice a que pantalla se hace referencia.
Actor: Persona que interacta con la pantalla.

Operador
Accin: Describe un evento.
Si desea ver un ejemplo dirjase al documento de descripcin de pantallas.
4.2 Elementos de diseo de una interfaz grafica

Los elementos de diseo de una interfaz grafica, son aquellos que hacen
referencia a la presentacin esttica(distribucin, colores, fuentes, etc) de cada
una de las pantallas.
Este diseo es necesario para enfocar a la persona encargada de la construccin
de las paginas en el resultado que se desea alcanzar dejndole poca libertad, esto
evitar contratiempos y mal entendidos.
4.2.1 Diseo estructural

Una buena practica para el desarrollo de interfaces de grficas en J2EE, es hacer
un diseo estructural que consiste en realizar un esquema previo de cmo se van
a visualizar cada una de las pantallas determinando componentes comunes y
singulares en cada de ellas.
Una de las ventajas de realizar este diseo es la identificacin de elementos
comunes que pueden ser utilizados en todas las pantallas, lo cual que mejora el
tiempo de desarrollo.

Versin 1.1
Otra ventajas es que se le da uniformidad al sistema haciendo que este sea mas
agradable estticamente.
Entre los elementos que se deben tener en cuenta en el diseo encontramos:
4.2.1.1 Encabezado
El encabezado se ubica en la parte superior de la pagina, por lo general contiene
un logo o una imagen que identifique la aplicacin, es recomendable utilizar
frames para que esta imagen se cargue solo una vez.
4.2.1.2 Men
El men es necesario para una navegabilidad rpida, se puede ubicar en varios
lugares y debe ser accesible desde cualquier pgina. Es una buena practica de
programacin web el utilizar mens, para no tener que regresar a paginas y
causar mayor demora.
4.2.1.3 Zona de Contenido
La zona de contenido cambia constantemente, dependiendo de la operacin
requerida por el usuario, en esta zona se podrn visualizar el resto de paginas de
la aplicacin y a las que se pueda dirigir segn el tipo de rol de usuario que este
en interaccin.
4.2.1.3 Hojas de Estilo
Las hojas de estilo permiten que el diseo sea flexible, debido a que recogen un
conjunto de caractersticas comunes a una serie de pginas web; as cuando
convenga, cambiando una caracterstica de la hoja de estilo automticamente
cambiar en todas las pginas web.
4.2.2 Componentes
Un componente es un elemento que posee unas caractersticas definidas, las
cuales sirven para el cumplimiento de un objetivo para el que fue creado.
Los componentes a usarse deben ser definidos en el diseo estructural, algunos
son comunes pero la gran mayora son nicos para cada pagina. Al observar
cuales se necesitan, tambin se debe tener en cuenta como van a configurarse, es
decir como se van a manejar las validaciones y cuales se van a hacer.
Al definir los componentes desde el comienzo se tiene la ventaja de que se tendr
estipulado lo que se necesita para el desarrollo de las pantallas, as no se incluirn
componentes que no aporten, porque todos estarn cumpliendo con un objetivo.
En el documento de Descripcin de Pantallas y Navegabilidad se encuentra un
ejemplo de cmo se definen las validaciones y los componentes necesarios para
el caso de prueba.

Versin 1.1
4.2.3 Zona de Mensajes

Esta zona se encarga de mostrar diferentes mensajes los cuales pueden se tipo:
informativos, de error o xito. La implementacin de esta zona puede ser de varios
maneras descritas a continuacin:
Panel de Mensajes: Consisten en un panel que aparece en

consecuencia a un evento, mostrando el mensaje asociado que explica
la razn de este; Este panel es independiente de la pagina involucrada y
tiene un botn para continuar en la aplicacin en el siguiente paso del
flujo.
Estilo de campos: Consisten en resaltar el campo don de hubo errores
con el fin que usuario lo identifique para su posterior correccin ,
adicionalmente se usa un comentario en frente de este campo en
colores llamativos que especifica la razn del error.
Mensajes en la parte superior o inferior: Consiste en ubicar el mensaje
en la parte superior o inferior de la pagina, donde se especifique que lo
genero, ya sea la razn de un error o la confirmacin exitoso de una
operacin.
Vale aclarar que cualquiera de los diseos anteriores es valido y adicionalmente

que se pueden hacer mezclas entre estos utilizando dos o los tres al mismo
tiempo.
4.2.4 Diagrama de navegabilidad

Este diagrama es una herramienta til para identificar la navegabilidad que existe
entre las pantallas especificadas para la aplicacin. Se construye a partir del
direccionamiento que se describe para cada una de las pantallas que se definieron
en la etapa anterior.
Para nuestro caso particular, este diagrama consta de 3 componentes
fundamentales que son:
P1
Etiqueta
Representacin de una pantalla

Indica direccionamiento de una pantalla a otra
Indica el evento que genero el direccionamiento
Luego de la construccin de este diagrama se habr terminado el uso de la

metodologa y se deber comenzar el proceso de implementacin de la aplicacin.

Versin 1.1
5. Otros problemas
A continuacin se presentaran algunos problemas que van mas all del alcance
del proyecto pero que son importantes en el desarrollo de aplicaciones en J2EE.
5.1 Seguridad
En todos los desarrollos de software es de gran importancia la seguridad que
deben tener estos frente a intrusos. La seguridad des software se puede asociar
con la seguridad de informacin que bsicamente se refiere a la proteccin de
sistema de informacin contra accesos sin autorizacin o la modificacin de
informacin.
Por ser los sistemas un desarrollo humano es muy probable que este quede con
errores que no se identifiquen porque no afectan el funcionamiento normal para el
que fueron creados, sin embargo siguen siendo errores y son estos los que se
buscan por un atacante para generar problemas informticos en los sistemas;
Debido esto es necesario determinar una seguridad al sistema tratando de mitigar
estos ataques.
Existen muchas maneras de realizar seguridad en Software, entre ellos
encontramos otro software probado y que se puede adquirir en el mercado que
haga esta tarea o mdulos creados por el programador del sistema que solucionen
dicho problema.
Es importante, e independiente de la manera como se valla a realizar la seguridad,
que antes que todo se debe conocer los riesgos de seguridad que tiene el sistema
en su contexto, una tarea del programador; Determinados estos riesgos, se debe
proceder a identificar medidas de seguridad apropiadas que busquen solucionar
de alguna manera los riesgos planteados, todo esto con el fin de buscar la mejor
estrategia de seguridad para el sistema.
5.2 Reportes
Por la filosofa y arquitectura de las aplicaciones J2EE los reportes se han
convertido de gran utilidad en este tipo de desarrollos; crear reportes de manera
fcil, rpida, y til, es de gran aceptacin para los clientes y usuarios finales y con
la ventaja que desde un browser se puede acceder a tan importante informacin.
En el mercado existen diferentes software que ayudan a el diseo y construccin
de reportes, entre ellos Jasper Report16que lo caracteriza por ser open source y
ofrecer soporte, servicios y entrenamiento de manera gratuita.
16
Jasper Reports open source: http://jasperreports.sourceforge.net/

Versin 1.1
5.3 Performance
Software performance hace referencia a la capacidad de reducir el coste y
fiabilidad de los sistemas, evitar defectos en las aplicaciones, detectar cuellos de
botellas y mitigarlos, detectar y anticipar la cada de servicios entre otras acciones
que busca este deseable estado del software.
Hay muchas compaas que ofrecen servicios de aseguramiento de esta
necesaria caracterstica del software, claro a un costo, sin embargo si se realiza
un correcto proceso de Ingeniera de Software la probabilidad de que el sistema
tenga un buen rendimiento es mayor.
5.4 Integracin con otro Software

Las aplicaciones J2EE permiten integracin con Software externo y diferente al
generado con Java; el ejemplo mas comn de esto es la utilizacin de Flash17 en
las interfaces grficas, que cada da atrae a mas programadores, por su capacidad
nica en diseo esttico de la interfaz y la no muy compleja unin con Java.
Esta claro que hay otros Software que se construyeron con propsitos especficos
y que podemos utilizar estas ventajas en nuestros desarrollos de Software gracias
a la flexibilidad de este tipo de arquitecturas.
17
Flash: Software desarrollado por la compaia Macromedia: http://www.macromedia.com/

Metodologia (v1 1)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metodologia (v1 1)

Uploaded by

Copyright:

Available Formats

Framework unificado para desarrollo de interfaces J2EE

Metodologa para el diseo y desarrollo de Interfaces de Usuario

Se especifican con mayor Alejandro Bez

Se aadi el diagrama para Alejandro Bez

Framework unificado para desarrollo de interfaces J2EE

Framework unificado para desarrollo de interfaces J2EE

4.2.1.3 Zona de Contenido ......................................................................... 26

Framework unificado para desarrollo de interfaces J2EE

Framework unificado para desarrollo de interfaces J2EE

2. Anlisis, diseo, implementacin y pruebas de una

2.1 Modelo de negocio

ID: identifica de manera nica un procedimiento.

Remitirse a los documentos de requerimientos, casos de uso y arquitectura de la videotienda en la pagina

Framework unificado para desarrollo de interfaces J2EE

Impacto: Indica los efectos producidos por la ejecucin del

Para un proceso se deben conocer:

Nombre: identificador nico del proceso

Para la recoleccin de la informacin de procesos y procedimientos hemos

Predecesor Personas Implicadas Impacto Tiempo Descripcin Resultados

Framework unificado para desarrollo de interfaces J2EE

automatizados, es til realizar un grfico propuesto por JBOSS2 que represente el

Nodo de Inicio: Representa el comienzo del flujo de un proceso y se

Nodo de Fin: Es el nodo que indica el final de un proceso y se representa

Nodo de Decisin: Es el nodo que indica una o varias opciones para

Nodo de Procedimiento: Este nodo representa una o varias actividades a

Nodo de Divisin de tareas concurrentes: Este nodo divide el proceso en

Transiciones: Accin que implica al flujo un cambio de estado, se

Un ejemplo que presenta JBOSS para la explicacin es el manejo de una subasta

Process Modelling, JBOSS, http://www.jbpm.org/3/processmodelling.html

Framework unificado para desarrollo de interfaces J2EE

2.2 Anlisis de requerimientos

Para Mayor Informacin dirjase a: Http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/ingenieria/analisis.asp

Framework unificado para desarrollo de interfaces J2EE

2.2.1 Documento de requerimientos

Definicin de los usuarios del sistema

Este anlisis servir como base para el diseo de la aplicacin.

Nombre: identificador nico de un grupo de usuarios que interactan con el

2.2.1.2 Requerimientos Funcionales

Id: Identifica de manera nica un requerimiento.

Para mas informacin remitirse al estndar IEEE 830-1998 (SRS)

Framework unificado para desarrollo de interfaces J2EE

2.2.1.3 Requerimientos No Funcionales

Id: Identifica de manera nica un requerimiento.

2.2.1.3.1 Requerimientos de interfaz

Id: Identifica de manera nica una interfaz grfica

En este nivel, no se va definir de manera detallada la interfaz, solo se pretende

2.2.2 Documento de casos de uso

UML y Patrones, Larman, 1999.

Framework unificado para desarrollo de interfaces J2EE

2.2.2.1 Definicin de actores

Nombre: Identifica de manera nica un tipo de actor.

2.2.2.2 Definicin de casos de uso

Nombre: Identifica de manera nica un caso de uso.

Framework unificado para desarrollo de interfaces J2EE

2.2.2.3 Diagrama de casos de uso

UML y Patrones, Larman, 1999.

Framework unificado para desarrollo de interfaces J2EE

2.3 Diseo del sistema

Interfaz (Web): Se encarga de la presentacin de la aplicacin al usuario.

Este tipo de arquitectura se puede considerar genrico para el desarrollo de

Interfaz: Java Server Faces (JSF), Tapestry

Grficamente la arquitectura es:

La herramienta que se desarrollara, servir para la creacin de aplicaciones con la