AP4-AA3-Ev2-Interfaz Gráfica de Usuario para El Proyecto de Formación-YELKIN SIERRA

Framework unificado para desarrollo de interfaces software el yes
Metodología para el diseño y desarrollo de Interfaces de Usuario

Versión 0.1 YELKIN ANTONIO SIERRA ATENCIA
YELKIN SIERRA
METODOLOGÍA
PARA EL DISEÑO
Y DESARROLLO
DE
INTERFACES DE
USUARIO
Version <0.1>
Historia de Revisión
Fecha Versión Descripción Responsable
09/05/2019 <0.1> Creación.
Yelkin Antonio sierra
atencia
INVESTIGADORES:
YELKIN ANTONIO SIERRA ATENCIA

DIRECTOR:
YELKIN SIERRA
Framework unificado para desarrollo de interfaces J2EE
YELKIN SIERRA
TABLA DE CONTENIDO
1. Introducción ........................................................................................................... 3
2. Análisis, diseño, implementación y pruebas de una aplicación en software el yes
.............. 4
2.1 Modelo de negocio ......................................................................................................... 4
2.2 Análisis de requerimientos ............................................................................................. 6
2.2.1 Documento de requerimientos .................................................................. 6
2.2.2 Documento de casos de uso ..................................................................... 8
2.3 Diseño del sistema ......................................................................................................... 9
2.4 Diseño de la lógica del negocio ................................................................................... 10
2.4.1 Modelo entidad relación .......................................................................... 11
2.4.2 Modelo de clases persistentes ................................................................ 11
2.4.3 Modelo de acceso a los datos (Patrón DAO) .......................................... 11
2.4.4 Definición de servicios ............................................................................ 12
2.5 Diseño de las interfaces de usuario .............................................................................. 12
3. Interfaz gráfica Sofware el yes ............................................................................ 12
3.1 Elementos funcionales de una interfaz grafica ............................................................ 13
3.1.1 Validaciones ............................................................................................ 14
3.1.2 Información a presentar y recolectar ....................................................... 14
3.1.3 Relación entre datos ............................................................................... 15
3.1.4 Flujo de Páginas ..................................................................................... 15
3.2 Elementos de diseño de una interfaz grafica ................................................................ 15
3.2.1 Diseño estructural ................................................................................... 16
3.2.2 Componentes .......................................................................................... 17
3.2.3 Zona de Mensajes ................................................................................... 17
3.2.4 Diagrama de navegabilidad ..................................................................... 17
4. Otros problemas .................................................................................................. 18
4.1 Acciones Extra( Mail, Alertas, tiempos) ...................................................... 18
4.2 Seguridad ................................................................................................... 18
4.3 Reportes .................................................................................................... 18
4.4 Performance .............................................................................................. 18
4.5 Integración con otro Software .................................................................... 18
YELKIN SIERRA
1. Introducción
Uno de los principales problemas en el desarrollo de aplicaciones software el yes es
el poco conocimiento que se tiene de cómo unir la lógica 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 definición de una metodología
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 metodología para el análisis,

diseño, implementación y pruebas en desarrollos de software el yes, además de
esto definir como diseñar 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.
2. Análisis, diseño, implementación y pruebas de una

aplicación software el yes
1
Desarrollando el caso de prueba de nuestro proyecto , se han podido identificar una
serie de etapas que se deben realizar para la construcción de aplicaciones software
el yes. 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 características específicas de la aplicación.
A continuación se muestran las etapas que consideramos se deben realizar en la

construcción de una aplicación software el yes:
• 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 cuáles son los procesos y procedimientos que se
tienen en el escenario para el cual se va a desarrollar la aplicación. Esto permite
identificar los casos concretos que debe automatizar el sistema, la relación que
debe existir entre la ingeniería 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 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 el
escenario 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. (véase numeral tal )
• Impacto: Indica los efectos producidos por la ejecución del procedimiento.
• Tiempo de realización: Indica el tiempo promedio de duración

del procedimiento.
• Descripción: Indica de manera detallada todos los pasos que se
deben cumplir para la realización del procedimiento.
• Resultados esperados: Indica los resultados que se deben obtener
luego de 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 hemos

definido el siguiente formato:
Numero del proceso:

Nombre del Proceso:
Objetivo:
Alcance:
Importancia:
Tiempo:
Procesos relacionados:
Resultados esperados:
Procedimientos
Nombre Objetivo Personas Impacto Tiempo Descripción Resultados
Implicadas
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 deberán realizar las etapas posteriores de la metodología.
2.2 Análisis de requerimientos
El análisis de requerimientos es la etapa más importante del desarrollo de software,

para poder hablar de ella primero tenemos que definirla; Para esto utilizaremos la
siguiente definición que hace Microsoft: “El análisis 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
2
problema o conseguir un objetivo.”
Como se indica en esta definición, el objetivo de el análisis de requerimientos es

determinar las condiciones o capacidades que debe cumplir el sistema que se
quiere diseñar para satisfacer las necesidades de un grupo de usuarios. Para lograr
esto utilizaremos la definición de requerimientos. Un requerimiento se puede
entender como una descripción 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.
2.2.1 Documento de requerimientos

En el documento de requerimientos se especifican las características y
funcionalidades que debería cumplir el sistema, para satisfacer los procesos y
procedimientos que se han determinado para ser automatizados. Este documento
3
debe contener al menos la siguiente información :
• 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 las

características de los usuarios que interactuaran con el sistema. Para esto se
utilizara 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:

SIERRA ATENCIA
• Nombre: identificador único de un grupo de usuarios que interactúan con

el sistema.
• Funciones: Conjunto de tareas que cumplir 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álisis del
negocio que se halla hecho.
Para la definición de los requerimientos funcionales se deben especificar los

siguientes 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 requerimientos
Funcionales y a las características de funcionamiento que requiera el usuario.
Para la definición de los requerimientos no funcionales se deben identificar lo

siguientes 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 el
sistema para permitir la interacción entre el usuario y las funcionalidades que este
tiene, con el fin de que en el proceso de diseño se tenga claridad de las interfaces
que se deben crear y la relación que debe existir entre ellas.
Para la definición de los requerimientos de interfaz se deben identificar lo siguientes

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 pretende

tener una primera aproximación 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 básicamente en la definición
de un conjunto de casos de uso. Un caso de uso es:” narración que describe la
secuencia de eventos de un actor (agente externo) que utiliza un sistema para
4
completar un proceso” .
La definición 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 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 de

personas que de alguna manera interactúan en alguno de los procesos del sistema,
estos actores estimulan al sistema con eventos de entrada o la recepción de 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 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 (véase 2.2.1)
4
Para la definición 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.
• 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 y
alterno, dependiendo si se presenta o no algún 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.
2.2.2.3 Diagrama de casos de uso
En esta sección del documento de casos de uso, se presenta el diagrama de casos

de uso. Un diagrama de casos de uso “Explica gráficamente un conjunto de casos
5
de uso de un sistema, los actores y la relación entre estos y los casos de uso”.
Para mayor información para la realización de estos diagramas a la especificación

6
de UML .
2.3 Diseño del sistema
En el diseño del sistema se pretende definir la arquitectura que utilizara la

aplicación, con el desarrollo del caso de prueba, hemos creído que es conveniente
utilizar una arquitectura multicapas, donde se tendrán al menos las siguientes
capas:
• 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.
Este tipo de arquitectura se puede considerar genérico para el desarrollo de

aplicaciones software el yes; 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
Gráficamente la arquitectura es:
Tomca
t
Intern JBOS ORACLE
et
HIBERNAT
La herramienta que se desarrollara, servirá para la creación de aplicaciones con la

arquitectura anteriormente descrita.
2.4 Diseño de la lógica del negocio
En esta etapa se deberá diseñar 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
7
que al menos se deben realizar :
• Modelo entidad relación

• Modelo de clases persistentes
8
• Modelo de acceso a los datos (Patrón DAO )
• 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, para
mayor 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.
0.1 YELKIN ANTONIO SIERRA ATENCIA
2.4.1 Modelo entidad relación
El modelo entidad relación es uno de los modelos conceptuales mas utilizados para
el diseño de bases de datos, el propósito de este modelo es simplificar el diseño de
9
bases de datos a partir de descripciones textuales de los requerimientos .
Para la construcción de este modelo se utilizan fundamentalmente los siguientes

elementos:
• 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 de

entidades, con sus atributos, que permitan representar todos los objetos que están
involucrados en el problema a solucionar. Con este conjunto de entidades y con el
documento de casos de uso, se deberán establecer las relaciones entre estas.
El objetivo del modelo de entidad relación es representar gráficamente estas

entidades y las relaciones que existen entre ellas, así como definir la estructura que
10
debe existir en la base de datos .
2.4.2 Modelo de clases persistentes:

Este modelo sirve para hacer un mapeo entre la información que se encuentra
almacenada en la base de datos y los objetos que se tendrán dentro de la
aplicación. Es importante aclarar que en este modelo no representara directamente
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 estas clases es un
11
POJO .
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 y
consistencia de los datos.
Consiste en definir un conjunto de clases que tendrán un grupo de métodos que se

encargan de todas las operaciones sobre los POJO´s que se definieron en el
modelo de clases persistentes. Típicamente se tendrán que ofrecer operaciones
12
CRUD y búsquedas.
0.1 YELKIN ANTONIO SIERRA ATENCIA
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 definidos anteriormente
para la aplicación, es decir, se encargaran de implementar la lógica del 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 del

comienzo de la ejecución de un servicio.
• Poscondición: Indica cual debe ser el estado de los datos después
de haber 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 las
interfaces graficas
3. Interfaz gráfica software el yes
Como ultimo paso de la metodología encontramos la definición detallada de las

interfaces gráficas, aquí se encuentran los pasos a seguir en la construcción de la
mismas.
Las pantallas deben permitir una forma de interacción entre el usuario y todas las
funcionalidades que ofrece el sistema, cada una de ellas debe al menos presentar
una funcionalidad para que su creación este justificada.
Los elementos comunes entre pantallas que se podrian definir son:
• Encabezado (Opcional)
• Menú (Opcional)
• Zona de mensajes (error, éxito)
• Zona de Contenido
13
• Hojas de estilo (CSS)
Los elementos que se deben definir para cada pantalla son:
• Información a presentar o recolectar

• Validaciones
• Relación entre datos
• Flujo de paginas
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
continuación:
Pagina 1 Pagina 2 .... Pagina m

Funcionalidad 1 X
Funcionalidad 2 X
.... X
Funcionalidad n X
El marcar la intersección entre una pagina y una funcionalidad, indica que la

pagina implementa esa funcionalidad.
En esta sección se describe en detalle componentes y características de las

interfaces gráficas en desarrollos SOFTWARE EL YES. Para llevar esto acabo
dividimos los elementos de una interfaz gráfica en dos: los que corresponden al
diseño de la interfaz, y los que hacen referencia a su funcionalidad.
3.1 Elementos funcionales de una interfaz grafica
Los elementos funcionales de una interfaz gráfica 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 desempeño por parte de los mismos es necesario que

trabajen conjuntamente, debido a que todos formarán el sistema y todos hacen
que sea mas claro el funcionamiento del mismo.
Entre los elementos a tener en cuenta encontramos:

3.1.1 Validaciones
Validación: Una validación 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 evalúa el dato respecto al tipo que se especificó que debía

ser. Los tipo que se tendrán en cuenta son:
o Números (Enteros y decimales).

o Cadena de Caracteres
o Fechas.
• Longitud: Dependiendo de la longitud mínima o máxima que se

requiera se 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ún

tipo de dato tenga o no caracteres especiales se debe verificar si
cumple con el requisito.
• Valores máximos(mínimos): En algunas aplicaciones los datos

deben estar entre unos limites establecido según los requerimientos
del sistema. Esto también debe ser evaluado
Las validaciones que se generen pueden ser agrupadas en código

reutilizable(clase), que funcione para todas las pantallas que requieran
las mismas.
3.1.2 Información a presentar y recolectar

La información 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 petición 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 descripción de pantallas: Caso de prueba
videotienda.
3.1.3 Relación entre datos

Hemos definido un lenguaje para modelar la relación existente entre los datos, con
el fin de especificar la descripción de cada una de las interfaces dependiendo de
los datos que se necesitan y se quieren mostrar.
Para mayor información dirigirse a el documento de patrones.....
3.1.4 Flujo de Páginas

Para el flujo que se lleva a cabo en cada acción vamos a utilizar los diagramas de
secuencia propuestos por UML, con la siguiente modificación: 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 representarán
pantallas, por donde transitará el sistema para responder a un evento.
Diagrama de Secuencia Modificado:
El diagrama de secuencia describirá el curso particular de eventos para cada uno

de 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:
Pantalla X Pantallas: Dice a que pantalla se hace referencia.
Actor: Persona que interactúa con la pantalla.
Operador
Acción: Describe un evento.
Si desea ver un ejemplo diríjase al documento de descripción de pantallas.
3.2 Elementos de diseño de una interfaz grafica

Los elementos de diseño de una interfaz grafica, son aquellos que hacen
referencia a la presentación estética(distribución, colores, fuentes, etc) de cada
una de las pantallas.
Este diseño es necesario para enfocar a la persona encargada de la construcción

de las paginas en el resultado que se desea alcanzar dejándole poca libertad,
esto evitará contratiempos y mal entendidos.
3.2.1 Diseño estructural

Una buena practica para el desarrollo de interfaces de gráficas en software el
yes, es hacer un diseño estructural que consiste en realizar un esquema previo
de cómo 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 diseño es la identificación de elementos

comunes que pueden ser utilizados en todas las pantallas, lo cual que mejora
el tiempo de desarrollo.
Otra ventajas es que se le da uniformidad al sistema haciendo que este sea

mas agradable estéticamente.
Entre los elementos que se deben tener en cuenta en el diseño encontramos:
3.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 aplicación, es recomendable
utilizar frames para que esta imagen se cargue solo una vez.
3.2.1.2 Menú
El menú es necesario para una navegabilidad rápida, se puede ubicar en
varios lugares y debe ser accesible desde cualquier página. Es una buena
practica de programación web el utilizar menús, para no tener que regresar a
paginas y causar mayor demora.
3.2.1.3 Zona de Contenido

La zona de contenido cambia constantemente, dependiendo de la operación
requerida por el usuario, en esta zona se podrán visualizar el resto de paginas
de la aplicación y a las que se pueda dirigir según el tipo de rol de usuario que
este en interacción.
Versión YELKIN ANTONIO SIERRA ATENCIA
3.2.2 Componentes
Un componente es un elemento que posee unas características definidas,
las cuales sirven para el cumplimiento de un objetivo para el que fue creado.
Los componentes a usarse deben ser definidos en el diseño estructural, algunos

son 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,
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 incluirán
componentes que no aporten, porque todos estarán cumpliendo con un objetivo.
En el documento de Descripción de Pantallas y Navegabilidad se encuentra un

ejemplo de cómo se definen las validaciones y los componentes necesarios
para el caso de prueba.
3.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
varios maneras descritas a continuación:
• Panel de Mensajes: Consisten en un panel que aparece en

consecuencia a un evento, mostrando el mensaje asociado que explica
la razón de este; Este panel es independiente de la pagina involucrada
y tiene un botón para continuar en la aplicación 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
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
lo genero, ya sea la razón de un error o la confirmación exitoso de una
operación.
Vale aclarar que cualquiera de los diseños anteriores es valido y

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

Este diagrama es una herramienta útil para identificar la navegabilidad que existe
entre las pantallas especificadas para la aplicación. Se construye a partir del
direccionamiento que se describe para cada una de las pantallas que se definieron
en la etapa anterior.
Versión YELKIN ANTONIO SIERRA ATENCIA
Para nuestro caso particular, este diagrama consta de 3 componentes

fundamentales que son:
P1 Representación de una pantalla
Indica direccionamiento de una pantalla a otra

Etiqueta Indica el evento que genero el direccionamiento
Para mayor detalle sobre elementos y características de las interfaces

graficas remítase al numeral 3 de este documento.
Luego de la construcción de este diagrama se habrá terminado el uso de la

metodología y se deberá comenzar el proceso de implementación de la aplicación.
4. Otros problemas
4.1 Acciones Extra( Mail, Alertas, tiempos)
4.2 Seguridad
4.3 Reportes
4.4 Performance
4.5 Integración con otro Software
Este proyecto esta encaminado hacia la gestión documental ect además la

posilidad de hacer ordenes de servicio como el programa que manejo acá
sipost pero mas exacto gracias…

AP4-AA3-Ev2-Interfaz Gráfica de Usuario para El Proyecto de Formación-YELKIN SIERRA

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AP4-AA3-Ev2-Interfaz Gráfica de Usuario para El Proyecto de Formación-YELKIN SIERRA

Загружено:

Авторское право:

Доступные форматы

Framework unificado para desarrollo de interfaces software el yes

Metodología para el diseño y desarrollo de Interfaces de Usuario

YELKIN ANTONIO SIERRA ATENCIA

El objetivo de este documento es presentar una metodología para el análisis,

2. Análisis, diseño, implementación y pruebas de una

A continuación se muestran las etapas que consideramos se deben realizar en la

2.1 Modelo de negocio

Un procedimiento se puede entender como un método estructurado para ejecutar

Típicamente de un procedimiento se debe conocer:

• Nombre: identificador único del procedimiento.

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

Para un proceso se deben conocer:

• Nombre: identificador único del proceso

Para la recolección de la información de procesos y procedimientos hemos

Numero del proceso:

2.2 Análisis de requerimientos

El análisis de requerimientos es la etapa más importante del desarrollo de software,

Como se indica en esta definición, el objetivo de el análisis de requerimientos es

Para lograr el levantamiento de estos requerimientos consideramos que se deben

2.2.1 Documento de requerimientos

• Definición de los usuarios del sistema

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 las

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

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

2.2.1.2 Requerimientos Funcionales

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

• Id: Identifica de manera única un requerimiento.

2.2.1.3 Requerimientos No Funcionales

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

Para la definición de los requerimientos no funcionales se deben identificar lo

• Id: Identifica de manera única un requerimiento.

2.2.1.4 Requerimientos de interfaz

Para la definición de los requerimientos de interfaz se deben identificar lo siguientes

• Id: Identifica de manera única una interfaz gráfica

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

2.2.2 Documento de casos de uso

Luego de desarrollar el documento de requerimientos, se debe construir el

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

2.2.2.1 Definición de actores

En esta sección del documento de casos de uso, se especificaran el tipo de

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

• Nombre: Identifica de manera única un tipo de actor.

2.2.2.2 Definición de casos de uso

En esta sección del documento de casos de uso, se definen de manera formal

• Nombre: Identifica de manera única un caso de uso.

2.2.2.3 Diagrama de casos de uso

En esta sección del documento de casos de uso, se presenta el diagrama de casos

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

2.3 Diseño del sistema

En el diseño del sistema se pretende definir la arquitectura que utilizara la

• Interfaz (Web): Se encarga de la presentación de la aplicación al usuario.

Este tipo de arquitectura se puede considerar genérico para el desarrollo de

• Interfaz: Java Server Faces (JSF), Tapestry

Gráficamente la arquitectura es:

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

2.4 Diseño de la lógica del negocio

En esta etapa se deberá diseñar un modelo apropiado para satisfacer los

• Modelo entidad relación

2.4.1 Modelo entidad relación

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

• Entidad: Abstracción que representa un objeto de la vida real.