MetodologÃ_a para el diseÃ_o y desarrollo de interfaces de usuario

5/17/2018 MetodologÃ_a para el diseÃ_o y desarrollo de interfaces de usuario - slidepdf.com

http://slidepdf.com/reader/full/metodologaa-para-el-diseao-y-desarrollo-de-interfaces-de-usuario 1/25

Framework unificado para desarrollo de interfaces J2EE

Metodología para el diseño y desarrollo de Interfaces de UsuarioVersión 1.0

Metodología para eldiseño y desarrollo deinterfaces de usuario

Versión <1.0>

Historia de RevisiónFecha Versión Descripción Responsable

20/06/2005 <0.1> Creación. Alejandro Báez

Cristian Castañeda

Diego Castañeda3/07/2005 <1.0> Se especifican con mayor

detalle las etapas de lametodología y se analizannuevos aspectos de lasinterfaces gráficas

Alejandro Báez

Cristian Castañeda

Diego Castañeda

INVESTIGADORES:

ALEJANDRO BAEZCRISTIAN CASTAÑEDA

DIEGO CASTAÑEDA

DIRECTOR:

JAVIER SÁNCHEZ





TABLA DE CONTENIDO

1. Introducción......................................................................................................... 32. Análisis, diseño, implementación y pruebas de una aplicación en J2EE ............ 4

2.1 Modelo de negocio ........................................................................................ 42.2 Análisis de requerimientos............................................................................. 6

2.2.1 Documento de requerimientos ................................................................ 62.2.2 Documento de casos de uso................................................................... 8

2.3 Diseño del sistema ........................................................................................ 92.4 Diseño de la lógica del negocio ................................................................... 10

2.4.1 Modelo entidad relación ........................................................................ 112.4.2 Modelo de clases persistentes: ............................................................. 112.4.3 Modelo de acceso a los datos (Patrón DAO) ........................................ 112.4.4 Definición de servicios........................................................................... 12

2.5 Diseño de las interfaces de usuario............................................................. 122.6 Implementación ........................................................................................... 122.7 Pruebas ....................................................................................................... 13

3. Relación con RUP............................................................................................. 133.1 ¿Qué es RUP? ............................................................................................ 13

3.1.1 Fase de Inicio........................................................................................ 143.1.2 Fase de Elaboración ............................................................................. 143.1.3 Fase de Construcción ........................................................................... 143.1.4 Fase de Transición................................................................................ 153.1.5 Artefactos .............................................................................................. 15

3.2 RUP en nuestra metodología....................................................................... 164. Interfaz gráfica J2EE ......................................................................................... 18

4.1 Elementos funcionales de una interfaz grafica ............................................ 194.1.1 Validaciones .......................................................................................... 194.1.2 Información a presentar y recolectar ..................................................... 204.1.3 Relación entre datos ............................................................................. 204.1.4 Flujo de Páginas.................................................................................... 20

4.2 Elementos de diseño de una interfaz grafica ............................................... 214.2.1 Diseño estructural ................................................................................. 214.2.2 Componentes ........................................................................................ 22

4.2.3 Zona de Mensajes................................................................................. 234.2.4 Diagrama de navegabilidad................................................................... 23

5. Otros problemas................................................................................................ 245.1 Seguridad................................................................................................. 245.2 Reportes................................................................................................... 245.3 Performance............................................................................................. 255.4 Integración con otro Software .................................................................. 25





1. Introducción

Uno de los principales problemas en el desarrollo de aplicaciones J2EE es el pococonocimiento que se tiene de cómo unir la lógica del negocio con la forma en quese presentara esta a los usuarios finales del software. Es por eso de vitalimportancia para el desarrollo de este proyecto, la definición de una metodologíaque nos ayude a decir como se debe realizar este proceso, para reducir lacomplejidad inherente de este tipo de desarrollos.

El objetivo de este documento es presentar una metodología para el análisis,diseño, implementación y pruebas en desarrollos de software en J2EE, además deesto definir como diseñar las interfaces graficas de usuario en este tipo deaplicaciones 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.





2. Análisis, diseño, implementación y pruebas de unaaplicación en J2EE

Desarrollando el caso de prueba de nuestro proyecto1, se han podido identificar una serie de etapas que se deben realizar para la construcción de aplicacionesJ2EE. Estas etapas son un modelo general que hemos desarrollado a partir denuestra experiencia, pero el orden y cumplimiento de las fases no es obligatorio,depende de las características especificas de la aplicación.

A continuación se muestran las etapas que consideramos se deben realizar en laconstrucción de una aplicación J2EE:

• Modelo de negocio• Análisis de requerimientos• Diseño del sistema• Diseño de la lógica del negocio• Diseño de las interfaces de usuario• Implementación• 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 aplicación. Esto permiteidentificar los casos concretos que debe automatizar el sistema, la relación quedebe existir entre la ingeniería de software y el negocio, con el fin de aclarar elenfoque que quiere tener el cliente con el software.

Un procedimiento se puede entender como un método estructurado para ejecutar una tarea. Un proceso es un conjunto de procedimientos que se deben realizar para alcanzar un objetivo, el cual representa una función que debe cumplir para elescenario que se estudiando.

Típicamente de un procedimiento se debe conocer:

• Nombre: identificador único del procedimiento.• Objetivo: Indica la finalidad que se busca alcanzar con el desarrollo del

procedimiento.• Personas implicadas: Indica las personas encargadas en desarrollar el

procedimiento.• Impacto: Indica los efectos producidos por la ejecución del

procedimiento.

1 Remitirse a los documentos de requerimientos, casos de uso y arquitectura de la videotienda en la paginahttp://pegasus.javeriana.edu.co/~fwj2ee/





• Tiempo de realización: Indica el tiempo promedio de duración delprocedimiento.

• Descripción: Indica de manera detallada todos los pasos que se debencumplir para la realización del procedimiento.

• Resultados esperados: Indica los resultados que se deben obtener luegode la realización 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 específica 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 realización: Indica el tiempo promedio de duración 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 realización del proceso.• Procedimientos implicados: Indica el conjunto de procedimientos que

incluye el desarrollo de este proceso.

Para la recolección de la información de procesos y procedimientos hemosdefinido el siguiente formato:

Numero del proceso:

Nombre del Proceso:

Objetivo:

Alcance:

Importancia:

Tiempo:

Procesos relacionados:

Resultados esperados:

Procedimientos

Nombre Objetivo PersonasImplicadas

Impacto Tiempo Descripción Resultados

Luego de llenar este formato para todos los procesos que se quieren analizar, sepodrá determinar que procesos van a ser automatizados por el sistema. Paraestos procesos se deberán realizar las etapas posteriores de la metodología.





2.2 Análisis de requerimientos

El análisis de requerimientos es la etapa mas importante del desarrollo desoftware, para poder hablar de ella primero tenemos que definirla; Para estoutilizaremos la siguiente definición que hace Microsoft: “El análisis derequerimientos es la primera etapa de un proyecto software, en ella se tratan dedefinir las condiciones o capacidades necesarias para uno o varios usuarios con elfin de solucionar un problema o conseguir un objetivo.”2

Como se indica en esta definición, el objetivo de el análisis de requerimientos esdeterminar las condiciones o capacidades que debe cumplir el sistema que sequiere diseñar para satisfacer las necesidades de un grupo de usuarios. Para

lograr esto utilizaremos la definición de requerimientos. Un requerimiento se puedeentender como una descripción informal de las necesidades y deseos que tiene elusuario final respecto a un producto de software.

Para lograr el levantamiento de estos requerimientos consideramos que se debenconstruir los siguientes artefactos: documento de requerimientos y el documentode casos de uso.

2.2.1 Documento de requerimientos

En el documento de requerimientos se especifican las características yfuncionalidades que debería cumplir el sistema, para satisfacer los procesos y

procedimientos que se han determinado para ser automatizados. Este documentodebe contener al menos la siguiente información3:

• Definición de los usuarios del sistema• Requerimientos Funcionales• Requerimientos no funcionales• Requerimientos de Interfaz• Glosario

Este análisis servirá como base para el diseño de la aplicación.

2.2.1.1 Definición de los usuarios del Sistema

En esta sección del documento de requerimientos se busca identificar lascaracterísticas de los usuarios que interactuaran con el sistema. Para esto seutilizara la definición de roles. Un rol es un conjunto de funciones que debe cumplir el papel de una persona que interactúa con el sistema.

Para la definición de un rol, se deben especificar los siguientes elementos:

2 Para Mayor Información diríjase a: Http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/ingenieria/analisis.asp3 Para mas información remitirse al estándar IEEE 830-1998 (SRS)





• Nombre: identificador único de un grupo de usuarios que interactúan con elsistema.

• 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 análisisdel negocio que se halla hecho.

Para la definición de los requerimientos funcionales se deben especificar lossiguientes elementos.

• Id: Identifica de manera única un requerimiento.• Nombre: identificador de un requerimiento.• Descripción: Indica una funcionalidad que debe cumplir el sistema.• Prioridad: indica la importancia de un requerimiento(Baja, Media, Alta).

2.2.1.3 Requerimientos No Funcionales

Los requerimientos no funcionales son todos aquellas características que debe

cumplir el sistema para responder de manera adecuada a todos los requerimientosFuncionales y a las características de funcionamiento que requiera el usuario.

Para la definición de los requerimientos no funcionales se deben identificar losiguientes elementos:

• Id: Identifica de manera única un requerimiento.• Nombre: identificador de un requerimiento.• Descripción: Indica una característica del sistema que ayudara a satisfacer

los requerimientos funcionales• Prioridad: indica la importancia de un requerimiento(Baja, Media, Alta).

2.2.1.4 Requerimientos de interfaz

Los requerimientos de interfaz son todos aquellos elementos que debe proveer elsistema para permitir la interacción entre el usuario y las funcionalidades que estetiene, con el fin de que en el proceso de diseño se tenga claridad de las interfacesque se deben crear y la relación que debe existir entre ellas.

Para la definición de los requerimientos de interfaz se deben identificar losiguientes elementos:





• Id: Identifica de manera única una interfaz gráfica• Descripción: Indica los elementos que debe tener la interfaz.• Requerimientos asociados: Indican las funcionalidades asociadas a la

interfaz gráfica.

En este nivel, no se va definir de manera detallada la interfaz, solo se pretendetener una primera aproximación a los elementos que deben ser tenidos en cuentaen el desarrollo de estas.

2.2.2 Documento de casos de uso

Luego de desarrollar el documento de requerimientos, se debe construir eldocumento de casos de uso. Este documento consiste básicamente en la

definición de un conjunto de casos de uso. Un caso de uso es:” narración quedescribe la secuencia de eventos de un actor (agente externo) que utiliza unsistema para completar un proceso”4.

La definición de estos casos de uso es útil para conocer los procesos del dominioy el ambiente externo, dentro de los cuales se ejecutan los requerimientosanteriormente descritos.

El documento de casos de uso deberá contener al menos la siguiente información:

• Definición de actores•

Definición de casos de uso• Diagrama de casos de uso

2.2.2.1 Definición de actores

En esta sección del documento de casos de uso, se especificaran el tipo depersonas que de alguna manera interactúan en alguno de los procesos delsistema, estos actores estimulan al sistema con eventos de entrada o la recepciónde algún resultado que este produzca.

Para la definición de los actores se deben identificar los siguientes elementos:

• Nombre: Identifica de manera única un tipo de actor.• Papel: Indica el tipo de estimulación que ejerce el actor sobre el sistema.

2.2.2.2 Definición de casos de uso

En esta sección del documento de casos de uso, se definen de manera formaltodos los casos de uso en los cuales se ejecutan cada uno de los requerimientosfuncionales que se especificaron en el documento de requerimientos (véase 2.2.1)

4 UML y Patrones, Larman, 1999.





Para la definición de cada caso de uso se deben tener en cuenta al menos lossiguiente 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.• Propósito: Indica la finalidad que se busca con el caso de uso.• Resumen: Breve descripción de los eventos que se realizan en el caso de

uso.• Tipo: Indica si la implementación 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 realización del caso de uso, especificando un curso normal yalterno, dependiendo si se presenta o no algún evento inesperado queafecte el desarrollo del caso de uso.

• Requerimientos que satisface: Hace una referencia a los identificadores delos requerimientos que satisface el caso uso.

2.2.2.3 Diagrama de casos de uso

En esta sección del documento de casos de uso, se presenta el diagrama decasos de uso. Un diagrama de casos de uso “Explica gráficamente un conjunto decasos de uso de un sistema, los actores y la relación entre estos y los casos de

uso”.5

Para mayor información para la realización de estos diagramas a la especificaciónde UML6.

2.3 Diseño del sistema

En el diseño del sistema se pretende definir la arquitectura que utilizara laaplicación, con el desarrollo del caso de prueba, hemos creído que es convenienteutilizar una arquitectura multicapas, donde se tendrán al menos las siguientescapas:

• Interfaz (Web): Se encarga de la presentación de la aplicación 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 información que reside en la base de datos.• Base de datos: Se encarga de mantener de manera persistente la

información del sistema.

5 UML y Patrones, Larman, 1999.6 UML (Unified Model Language), http://www.uml.org/





Este tipo de arquitectura se puede considerar genérico para el desarrollo deaplicaciones J2EE; en nuestro caso hemos decidido utilizar los siguientesframeworks:

• Interfaz: Java Server Faces (JSF), Tapestry• Servicios: JBoss y Tomcat• Manejador de persistencia: Hibernate• Base de datos: Oracle

Gráficamente la arquitectura es:

La herramienta que se desarrollara, servirá para la creación de aplicaciones con laarquitectura anteriormente descrita.

2.4 Diseño de la lógica del negocio

En esta etapa se deberá diseñar un modelo apropiado para satisfacer losrequerimientos y casos de uso que se especificaron en etapas anterioresutilizando la arquitectura que se ha definido.

Realizando nuestro caso de prueba, hemos podido identificar los siguientes itemsque al menos se deben realizar 7:

• Modelo entidad relación• Modelo de clases persistentes• Modelo de acceso a los datos (Patrón DAO8)• Definición de servicios

7 El orden de realización de estos productos no es estricto. Se puede utilizar otros diagramas útiles para el diseño, paramayor información remítase a la especificación de UML.8 Data Access Object, patrón que sirve para encapsular y administrar el acceso a los datos.

Inter net

Tomcat

JBOSS

HIBERNATE

ORACLE





2.4.1 Modelo entidad relación

El modelo entidad relación es uno de los modelos conceptuales mas utilizadospara el diseño de bases de datos, el propósito de este modelo es simplificar eldiseño de bases de datos a partir de descripciones textuales de losrequerimientos9.

Para la construcción de este modelo se utilizan fundamentalmente los siguienteselementos:

• Entidad: Abstracción que representa un objeto de la vida real.• Atributo: Característica que representa un aspecto común de la entidad• Relación: Representa una interacción entre entidades.

Luego del proceso de análisis del sistema, se deben establecer un conjunto deentidades, con sus atributos, que permitan representar todos los objetos que estáninvolucrados en el problema a solucionar. Con este conjunto de entidades y con eldocumento de casos de uso, se deberán establecer las relaciones entre estas.

El objetivo del modelo de entidad relación es representar gráficamente estasentidades y las relaciones que existen entre ellas, así como definir la estructuraque debe existir en la base de datos10.

2.4.2 Modelo de clases persistentes:Este modelo sirve para hacer un mapeo entre la información que se encuentraalmacenada en la base de datos y los objetos que se tendrán dentro de laaplicación. Es importante aclarar que en este modelo no representaradirectamente todas las funcionalidades que debe tener el sistema, sino que servirácomo soporte al patrón DAO. En términos de nuestro contexto, cada una de estasclases es un POJO11.

2.4.3 Modelo de acceso a los datos (Patrón DAO)

Este modelo sirve para separar el acceso a los datos con la lógica del negocio,

esto permite que se defina un nivel mas que permita la protección a la integridad yconsistencia de los datos.

Consiste en definir un conjunto de clases que tendrán un grupo de métodos quese encargan de todas las operaciones sobre los POJO´s que se definieron en elmodelo de clases persistentes. Típicamente se tendrán que ofrecer operacionesCRUD12 y búsquedas.

9 Modelo entidad relación, http://alvherre.atentus.cl/modBasico/node3.html10 Para mayor información: SILBERSCHATZ, A., et al. Fundamentos de Bases de Datos. Cuarta Edición. McGraw Hill. 200211 Persistent Old Java Object, objeto al cual solo se le definen los atributos, los set y get para accesarlos.12 Create, Read, Update, Delete. Operaciones que básicamente se hacen sobre los datos





2.4.4 Definición de servicios

En esta fase se deberán definir un conjunto de servicios que se deben proveer para satisfacer a los requerimientos y funcionalidades que fueron definidosanteriormente para la aplicación, es decir, se encargaran de implementar la lógicadel negocio. Estos servicios serán utilizados por el servidor Web para establecer un puente entre la lógica del negocio y la presentación.

Para nuestro contexto, consideramos que para un servicio se deben definir:

• Precondición: Es una condición que ha de satisfacerse justo antes delcomienzo de la ejecución de un servicio.

•

Poscondición: Indica cual debe ser el estado de los datos después dehaber realizado el servicio.• Definición: Da una descripción de lo que debe hacer el servicio• Prototipo del método: Muestra el prototipo de cómo se implementara el

servicio.

Con la definición de los servicios, se puede tener claro como van a ser implementados los requerimientos funcionales del sistema; esta información serávital para el proceso de integración de la aplicación.

2.5 Diseño de las interfaces de usuario

Una de las etapas a las que menos tiempo se les invierte es al diseño de lasinterfaces graficas, por tal razón en el momento de implementarlas no se tieneclaro que es lo que se debe hacer, generando errores e inconsistencias lo quehace que su desarrollo sea lento y complejo.

Por eso es una buena práctica, establecer en los cronogramas un tiempo para eldiseño de estas, para evitar que estos problemas se presenten. El problema deldiseño de las interfaces gráficas se analizara al detalle en la sección 4 de estedocumento.

2.6 Implementación

En esta etapa se debe llevar a la realidad todo lo que se ha descrito en losmodelos de las fases anteriores. Para tener un buen proceso de implementaciónse recomienda tener en cuanta los siguientes aspectos:

• Manejo de versiones• Definición de iteraciones• Documentación





Estos aspectos se van tratar con mas detalle en la sección 3, donde se establecela relación entre nuestra metodología y RUP.

2.7 Pruebas

La ultima etapa de nuestra metodología, busca asegurar que las funcionalidadesimplementadas en el sistema funcionen de acuerdo a las especificaciones, paraesto se deben definir un conjunto de pruebas que nos ayuden a verificar esto.

La definición de las pruebas y la administración podrán ser manejadas con RUP,ver la sección 3.

3. Relación con RUPEn la actualidad una de las metodologías mas utilizadas para desarrollos desoftware es RUP (Rational Unified Process), por eso es de vital importancia parala especificación de nuestra metodología, establecer como podemos entender nuestras etapas según el ciclo de vida que se define en RUP. Para poder establecer esta relación, primero debemos definir que es RUP.

3.1 ¿Qué es RUP?

RUP es un proceso de Ingeniería de Software en el cual se especifican una serie

de tareas que se deben realizar con el fin de asegurar un producto de Software dealta calidad a sus usuarios finales.

Dentro de RUP se pueden identificar cuatro etapas que son:

• Inicio• Elaboración• Construcción• Transición

En cada una de estas etapas se propone la ejecución de una serie de disciplinas,

que se deben ejecutar de forma iterativa para cada una de las fases. Estasdisciplinas son:

• Modelamiento del negocio: Busca identificar el negocio, para el cual serealizara el proyecto.

• Levantamiento de requerimientos: Identifica los procesos que deben ser automatizados, la manera como se deben proveer estos y los objetivos delproyecto.

• Análisis y Diseño: Se busca determinar una solución para alcanzar losobjetivos del proyecto.





• Implementación: Disciplina donde se busca llevar a la realidad la soluciónque se definió en el análisis y diseño.

• Pruebas: Busca comprobar la correcta implementación de la solucióndada.

Cada una de estas disciplinas se debe realizar en mayor o menor medidadependiendo de la fase del proyecto en que se encuentre; A continuaciónespecificaremos 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 aproximación 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.

3.1.2 Fase de Elaboración

La fase de Elaboración tiene los siguientes objetivos:

• Asegurar que la arquitectura escogida cumpla los requerimientos y planespreviamente establecidos.

• Definir los riesgos que la arquitectura escogida pueda traer al proyecto.• Establecer una línea de base de la arquitectura para mitigar los riesgos en los

distintos escenarios y que soporte los requerimientos especificadas a un costoy tiempo razonable .

• Construir un prototipo que permita visualizar al usuario final una posiblesolución del problema con el fin de mitigar riesgos en el futuro y ademáslevantar nuevos requerimientos del sistema.

3.1.3 Fase de Construcción

La fase de construcción 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 rápidas.• Completar el análisis, diseño 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 softwareque desarrolle en paralelo.

3.1.4 Fase de Transición

La fase de transición tiene los siguientes objetivos:

• Prueba para validar el nuevo sistema ante las expectativas del usuario final.• Capacitación a usuario y administradores del sistema• Valorar si la línea base del desarrollo cumple con la visión del proyecto y los

criterios de aceptación 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 enque etapa se deben desarrollar los diferentes artefactos que propone RUP, entérminos generales consideramos que los siguientes artefactos son los masimportantes que define este proceso:

Artefacto Descripción Disciplina

Modelo de Casos deUso del negocio

Relaciona los casos de uso delnegocio con sus actores y

relaciones.

Modelo del Negocio

Modelo de Objetosdel Negocio Relaciona en un modelo laorganización las entidades ytrabajadores del negocio.

Modelo del Negocio

Especificación derequerimientos

Identifica las necesidades que debesatisfacer el sistema.

Levantamiento derequerimientos

Casos de Uso Identifica un escenario, los eventos yactores para la realización de un

proceso del negocio.


Modelo de Casos deUso

Relaciona gráficamente los casos deuso.


Especificación de

arquitectura

Define la arquitectura sobre la que se

desarrollara el software

Análisis y Diseño

Modelo de datos Define el modelo sobre el cual secreara la base de datos.

Análisis y Diseño

Diseño de clases Define la forma en que seimplementara la solución.

Análisis y Diseño

Diseño de paquetes Identifica los paquetes con los quese implementaran la solución.

Análisis y Diseño

Pantallas Define las interfaces de usuario. Análisis y DiseñoMapa de Navegación Indica la navegación entre las

pantallas de usuario. Análisis y Diseño

Plan de Pruebas Define las pruebas que se le Implementación





realizara al softwareCódigo Fuente Implementación de la solución. ImplementaciónResultado de

pruebasDocumenta los resultados de las

pruebas.Pruebas

Esta sección es una breve introducción al proceso de RUP, fue extraída de eldocumento About the RUP® Configuration for Java™ Developers

13.

3.2 RUP en nuestra metodología

Como pudimos darnos cuenta en la anterior sección RUP ofrece una metodologíade desarrollo, donde se pueden identificar una serie de etapas, que aunqueindependientes se relacionan de manera muy fuerte por su proceso iterativo, esta

relación es muy importante para que se pueda asegurar la calidad en el desarrollodel software. En nuestra metodología hemos podido identificar una serie dedisciplinas, que aunque no son exactamente iguales a las que propone RUP,buscan cumplir con ese criterio de calidad.

A continuación, asociaremos nuestras disciplinas con las cuatro etapas quepropone RUP:

13 RUP® Configuration for Java™ Developers, Version 2002.05.20, Rational Software Corporation





En el grafico nos podemos dar cuenta, que nuestras disciplinas están pensadaspara realizarse mediante un proceso iterativo. Esto quiere decir que luego derealizarse por completo cada una de estas disciplinas se va a realizar nuevamentecon base a la versión anterior, mejorándola hasta que cumpla con las necesidadesplanteadas.

Por otra parte nuestros artefactos aunque no son iguales a los que RUP propone,son capaces de alcanzar los objetivos que la metodología da para cada caso. Acontinuación, vamos a relacionar nuestros artefactos con las diferentes disciplinasque propone RUP:

Artefactos Disciplinas RUP

Modelo del Negocio Modelo del NegocioDocumento de Requerimientos Levantamiento de requerimientosDocumento de Casos de Uso Levantamiento de requerimientos

Modelo entidad relación Análisis y DiseñoModelo de clases persistentes Análisis y DiseñoModelo de acceso a los Datos Análisis y Diseño

Documento de Interfaces de usuario Análisis y DiseñoImplementación(Código Fuente) Implementación

Pruebas Pruebas

De esta manera podemos ver como asociar la metodología propuesta con elproceso que realiza RUP, logrando seguir este pero con los pasos que en lametodología se proponen.





4. Interfaz gráfica J2EE

En nuestra metodología encontramos la definición detallada de las interfacesgráficas, una nueva etapa en los desarrollos comunes de software. En estasección se encuentran los pasos a seguir en el diseño y construcción de lasmismas.

Las pantallas deben permitir una forma de interacción entre el usuario y todas lasfuncionalidades que ofrece el sistema, cada una de ellas debe al menos presentar una funcionalidad para que su creación este justificada.

Los elementos que se deben definir para cada pantalla son:

• Información a presentar o recolectar • Validaciones• Relación entre datos• Flujo de paginas

Los elementos comunes entre pantallas que se podrían definir son:

• Encabezado (Opcional)• Menú (Opcional)• Zona de Contenido• Hojas de estilo (CSS)14 • Zona de mensajes (error, éxito)

Una practica recomendable para verificar la completitud entre las paginasdefinidas y las funcionalidades del sistema es llenar una matriz como la que semuestra a continuación:

Pagina 1 Pagina 2 .... Pagina m

Funcionalidad 1 XFuncionalidad 2 X

.... X

Funcionalidad n X

El marcar la intersección entre una pagina y una funcionalidad, indica que lapagina implementa esa funcionalidad.

14 Las hojas de estilo en cascada permiten estandarizar la forma de presentación de los componentes en una

pagina. Para mas información http://www.csszengarden.com/





En esta sección se describe en detalle componentes y características de lasinterfaces gráficas en desarrollos J2EE. Para llevar esto acabo dividimos loselementos de una interfaz gráfica en dos: los que hacen referencia a sufuncionalidad y los que corresponden al diseño de la interfaz.

4.1 Elementos funcionales de una interfaz grafica

Los elementos funcionales de una interfaz gráfica son los que definen elcomportamiento de la misma, es decir aquellos cuyo objetivo es asegurar elfuncionamiento adecuado y coherente de las pantallas del sistema, teniendo encuenta los requerimientos que fueron planteados y que se necesita seansatisfechos.

Para un correcto desempeño por parte de los mismos es necesario que trabajenconjuntamente, debido a que todos formarán el sistema y todos hacen que seamas claro el funcionamiento del mismo.

Entre los elementos a tener en cuenta encontramos:

4.1.1 Validaciones

Validación: Una validación se lleva a cabo cuando se compara un dato con unvalor esperado, buscando coherencia e integridad.Las validaciones que se van tener en cuenta son:

• Tipo: Se evalúa el dato respecto al tipo que se especifico que debía ser.Los tipo que se tendrán en cuenta son:

o Números (Enteros y decimales).o Cadena de Caractereso Fechas.

• Longitud: Dependiendo de la longitud mínima o máxima que se requierase evaluará si el dato cumple con esta característica.

•

Obligatoriedad: Se valida si en algunos casos el usuario tiene que llenar un campo para realizar una operación.

• Caracteres Especiales: Dependiendo si el usuario necesita que algúntipo de dato tenga o no caracteres especiales se debe verificar si cumplecon el requisito.

• Valores máximos(mínimos): En algunas aplicaciones los datos debenestar entre unos limites establecido según los requerimientos delsistema. Esto también debe ser evaluado





Las validaciones que se generen pueden ser agrupadas en códigoreutilizable(clase), que funcione para todas las pantallas que requieran lasmismas.

4.1.2 Información a presentar y recolectar

La información a presentar dependerá del rol del usuario del sistema ya que cadauno tiene un nivel de acceso limitado, lo anterior para proteger la confidencialidadde los datos. Así mismo los datos que se obtienen tienen que estar acordes con lapetición y ser consistentes en íntegros respecto a los almacenados en la base dedatos.

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 queforma para cada una de las pantallas que se van desarrollar. Si desea ver unejemplo dirigirse a el documento de descripción de pantallas: Caso de pruebavideotienda.

4.1.3 Relación entre datos

Es importante que el contenido de las interfaces a generar este previamenterepresentado, ya que son las bases de la construcción y sin estas podrían

presentarse información no valida, incompleta, desordenada o fuera de lasexpectativas del cliente.

Hemos definido entonces un lenguaje para modelar la relación existente entre losdatos, con el fin de especificar la descripción de cada una de las interfacesdependiendo de los datos que se necesitan y se quieren mostrara ante los usuariofinales.

Para mayor información dirigirse al documento “Patrones para la descripciónformal de interfaces de usuario”

4.1.4 Flujo de Páginas

El flujo de paginasPara el flujo que se lleva a cabo en cada acción vamos a utilizar los diagramas desecuencia propuestos por UML, con la siguiente modificación: Los diagramas desecuencias comunes muestran el curso normal de un caso de uso, y su transitopor cada una de las clases. En nuestro caso, en vez de clases las cajasrepresentarán pantallas, por donde transitará el sistema para responder a unevento.

Diagrama de Secuencia Modificado:





El diagrama de secuencia describirá el curso particular de eventos para cada unode los casos de uso, mostrando la navegación a través de las pantallas definidas,incluyendo los autores y los eventos generados en dichas operaciones

En el diagrama de secuencia se tiene los elementos:

Pantallas: Dice a que pantalla se hace referencia.

Actor: Persona que interactúa con la pantalla.

Acción: Describe un evento.

Si desea ver un ejemplo diríjase al documento de descripción de pantallas.

4.2 Elementos de diseño de una interfaz grafica

Los elementos de diseño de una interfaz grafica, son aquellos que hacenreferencia a la presentación estética(distribución, colores, fuentes, etc) de cadauna de las pantallas.

Este diseño es necesario para enfocar a la persona encargada de la construcciónde las paginas en el resultado que se desea alcanzar dejándole poca libertad, estoevitará contratiempos y mal entendidos.

4.2.1 Diseño estructural

Una buena practica para el desarrollo de interfaces de gráficas en J2EE, es hacer un diseño estructural que consiste en realizar un esquema previo de cómo se vana visualizar cada una de las pantallas determinando componentes comunes ysingulares en cada de ellas.

Una de las ventajas de realizar este diseño es la identificación de elementoscomunes que pueden ser utilizados en todas las pantallas, lo cual que mejora eltiempo de desarrollo.

Pantalla X

Operador





Otra ventajas es que se le da uniformidad al sistema haciendo que este sea masagradable estéticamente.

Entre los elementos que se deben tener en cuenta en el diseño encontramos:

4.2.1.1 EncabezadoEl encabezado se ubica en la parte superior de la pagina, por lo general contieneun logo o una imagen que identifique la aplicación, 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 rápida, se puede ubicar en varioslugares y debe ser accesible desde cualquier página. Es una buena practica deprogramación web el utilizar menús, para no tener que regresar a paginas y

causar mayor demora.

4.2.1.3 Zona de ContenidoLa zona de contenido cambia constantemente, dependiendo de la operaciónrequerida por el usuario, en esta zona se podrán visualizar el resto de paginas dela aplicación y a las que se pueda dirigir según el tipo de rol de usuario que esteen interacción.

4.2.1.3 Hojas de EstiloLas hojas de estilo permiten que el diseño sea flexible, debido a que recogen unconjunto de características comunes a una serie de páginas web; así cuando

convenga, cambiando una característica de la hoja de estilo automáticamentecambiará en todas las páginas web.

4.2.2 Componentes

Un componente es un elemento que posee unas características definidas, lascuales sirven para el cumplimiento de un objetivo para el que fue creado.

Los componentes a usarse deben ser definidos en el diseño estructural, algunosson comunes pero la gran mayoría son únicos para cada pagina. Al observar cuales se necesitan, también se debe tener en cuenta como van a configurarse, esdecir 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 incluiráncomponentes que no aporten, porque todos estarán cumpliendo con un objetivo.

En el documento de Descripción de Pantallas y Navegabilidad se encuentra unejemplo de cómo se definen las validaciones y los componentes necesarios parael caso de prueba.





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 implementación de esta zona puede ser de variosmaneras descritas a continuación:

• Panel de Mensajes: Consisten en un panel que aparece enconsecuencia a un evento, mostrando el mensaje asociado que explicala razón de este; Este panel es independiente de la pagina involucrada ytiene un botón para continuar en la aplicación en el siguiente paso delflujo.

• Estilo de campos: Consisten en resaltar el campo don de hubo errorescon el fin que usuario lo identifique para su posterior corrección ,adicionalmente se usa un comentario en frente de este campo en

colores llamativos que especifica la razón 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 logenero, ya sea la razón de un error o la confirmación exitoso de unaoperación.

Vale aclarar que cualquiera de los diseños anteriores es valido y adicionalmenteque se pueden hacer mezclas entre estos utilizando dos o los tres al mismotiempo.

4.2.4 Diagrama de navegabilidadEste diagrama es una herramienta útil para identificar la navegabilidad que existeentre las pantallas especificadas para la aplicación. Se construye a partir deldireccionamiento que se describe para cada una de las pantallas que se definieronen la etapa anterior.

Para nuestro caso particular, este diagrama consta de 3 componentesfundamentales que son:

Representación de una pantalla

Indica direccionamiento de una pantalla a otraIndica el evento que genero el direccionamiento

Luego de la construcción de este diagrama se habrá terminado el uso de lametodología y se deberá comenzar el proceso de implementación de la aplicación.

P1

Etiqueta





5. Otros problemas

A continuación se presentaran algunos problemas que van mas allá del alcancedel 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 quedeben tener estos frente a intrusos. La seguridad des software se puede asociar con la seguridad de información que básicamente se refiere a la protección desistema de información contra accesos sin autorización o la modificación deinformación.

Por ser los sistemas un desarrollo humano es muy probable que este quede conerrores que no se identifiquen porque no afectan el funcionamiento normal para elque fueron creados, sin embargo siguen siendo errores y son estos los que sebuscan por un atacante para generar problemas informáticos 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 ellosencontramos otro software probado y que se puede adquirir en el mercado quehaga esta tarea o módulos 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 sistemaen su contexto, una tarea del programador; Determinados estos riesgos, se debeproceder 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 filosofía y arquitectura de las aplicaciones J2EE los reportes se hanconvertido de gran utilidad en este tipo de desarrollos; crear reportes de manerafácil, rápida, y útil, es de gran aceptación para los clientes y usuarios finales y conla ventaja que desde un browser se puede acceder a tan importante información.

En el mercado existen diferentes software que ayudan a el diseño y construcciónde reportes, entre ellos Jasper Report15que lo caracteriza por ser open source yofrecer soporte, servicios y entrenamiento de manera gratuita.

15 Jasper Reports open source: http://jasperreports.sourceforge.net/





5.3 Performance

Software performance hace referencia a la capacidad de reducir el coste yfiabilidad de los sistemas, evitar defectos en las aplicaciones, detectar cuellos debotellas y mitigarlos, detectar y anticipar la caída de servicios entre otras accionesque busca este deseable estado del software.

Hay muchas compañías que ofrecen servicios de aseguramiento de estanecesaria característica del software, claro a un costo, sin embargo si se realizaun correcto proceso de Ingeniería de Software la probabilidad de que el sistematenga un buen rendimiento es mayor.

5.4 Integración con otro Software

Las aplicaciones J2EE permiten integración con Software externo y diferente algenerado con Java; el ejemplo mas común de esto es la utilización de Flash 16 enlas interfaces gráficas, que cada día atrae a mas programadores, por su capacidadúnica en diseño estético de la interfaz y la no muy compleja unión con Java.

Esta claro que hay otros Software que se construyeron con propósitos específicosy que podemos utilizar estas ventajas en nuestros desarrollos de Software graciasa la flexibilidad de este tipo de arquitecturas.

16 Flash: Software desarrollado por la compañia Macromedia: http://www.macromedia.com/

MetodologÃ_a para el diseÃ_o y desarrollo de interfaces de usuario

Documents

Transcript of MetodologÃ_a para el diseÃ_o y desarrollo de interfaces de usuario