informe de practicas-sistema de banca móvil para cooperativas

UNIVERSIDAD NACIONAL DE SAN CRISTOBAL DE HUAMANGA

FACULTAD DE INGENIERIA DE MINAS GEOLOGIA Y CIVIL

ESCUELA DE FORMACIÓN PROFESIONAL DE INGENIERIA DE

SISTEMAS

INFORME DE PRACTICA PRE PROFESIONAL

Sistema de Banca Móvil para Cooperativas; para los casos de uso

Registro de Parámetros, login, selección de socio, selección de

cuenta, depósito, retiro

ENTIDAD AUSPICIADORA : Red Peruana de Servicios

Compartidos

Kuskanet S.R.L.

NOMBRE DEL EJECUTOR : CUBA ALARCON, Juan Mariano

LUGAR Y FECHA : Ayacucho, junio del 2011

AYACUCHO – PERU

1

2011

2

DEDICATORIA:

A todas las personas que día a día se aferran a la Ciencia con el fin de ayudar a los demás

i

Agradecimientos:

Agradezco el presente trabajo a mis padres, hermano

por brindarme el apoyo incondicional en esta travesía

de la vida y a los profesores de

esta prestigiosa casa de estudios.

ii

CONTENIDO

DEDICATORIA:.......................................................................................................................... i

Agradecimientos:...................................................................................................................ii

CONTENIDO................................................................................................... iii

RESUMEN.......................................................................................................vi

INTRODUCCION.............................................................................................vii

CAPITULO I

OBJETIVOS

1.1 OBJETIVO GENERAL...............................................................................................8

1.2 OBJETIVOS ESPECIFICOS......................................................................................8

CAPITULO II

MARCO TEORICO

2.1 METODOLOGIA ICONIX.........................................................................................9

2.1.1 MODELO DE DOMINIO.........................................................................................10

2.1.2 MODELO DE CASOS DE USO.............................................................................11

2.1.3 REVISION DE REQUISITOS.................................................................................13

2.1.4 ANALISIS DE ROBUSTEZ.....................................................................................15

2.1.5 REVISION PRELIMINAR DE DISEÑO.................................................................17

2.1.6 ARQUITECTURA TECNICA...................................................................................17

2.1.7 DIAGRAMA DE SECUENCIA................................................................................18

2.1.8 REVISION CRITICA DEL DISEÑO.......................................................................20

2.1.9 IMPLEMENTACION.................................................................................................21

2.1.10 REVISION DEL CODIGO Y ACTUALIZACION DEL MODELO......................21

2.1.11 PRUEBAS BASADAS EN DISEÑO.......................................................................21

iii

2.2 TEORIA DE OBJETOS............................................................................................21

2.2.1 CLASE Y OBJETO....................................................................................................21

2.2.2 ENCAPSULAMIENTO, HERENCIA Y POLIMORFISMO...................................22

2.3 UML............................................................................................................................22

2.4 MODELO VISTA CONTROLADOR......................................................................23

2.5 JAVA 2 MICRO EDITION.......................................................................................24

2.5.1 CONFIGURACIONES..............................................................................................25

2.5.2 PERFILES..................................................................................................................26

2.5.3 KVM...........................................................................................................................26

2.6 SERVICIOS WEB.....................................................................................................27

2.6.1 XML............................................................................................................................27

2.6.2 SOAP.........................................................................................................................28

2.6.3 WSDL........................................................................................................................28

2.6.4 UDDI..........................................................................................................................29

2.7 BLUETOOTH............................................................................................................29

2.7.1 API JSR 82...............................................................................................................30

2.8 TECNOLOGIA..........................................................................................................30

2.8.1 ENTERPRISE ARCHITECT....................................................................................30

2.8.2 JAVA 2 MICRO DB..................................................................................................30

2.8.2.1 J2MLIB.......................................................................................................................31

2.8.2.2 KXML.........................................................................................................................31

2.9 SISTEMA OPERATIVO SYMBIAN........................................................................31

2.10 COOPERATIVA DE AHORRO Y CREDITO........................................................32

2.11 BANCA MOVIL........................................................................................................32

2.12 RED PERUANA DE SERVICIOS COMPARTIDOS KUSKANET......................33

2.13 RECOMENDACIONES PARA DISEÑAR Y PROGRAMAR CON J2ME..........33

CAPITULO III

RESSULTADOS

iv

3.1 MODELO DE DOMINIO.........................................................................................35

3.2 MODELO DE CASOS DE USO.............................................................................40

3.3 DESCRIPCIÓN DE CASOS DE USO...................................................................44

3.4 REVISION DE REQUISITOS.................................................................................46

3.5 ANALISIS DE ROBUSTEZ.....................................................................................48

3.6 REVISION PRELIMINAR DE DISEÑO.................................................................50

3.7 ARQUITECTURA TECNICA...................................................................................53

3.8 DIAGRAMAS DE SECUENCIA.............................................................................56

3.9 REVISION CRITICA DEL DISEÑO.......................................................................60

RECOMENDACIONES....................................................................................66

BIBLIOGRAFIA...............................................................................................67

ANEXO 1.......................................................................................................69

v

RESUMEN

Las actividades de prácticas pre profesionales de la Escuela de Formación

Profesional de Ingeniería de Sistemas de la Universidad Nacional de San

Cristóbal de Huamanga, se realizó en la Empresa Red Peruana de Servicios

Compartidos Kuskanet S.R.L., cuyo fin principal fue realizar, el desarrollo

para la construcción del sistema de banca móvil, llamado KNETMOVIL, que

permite realizar las operaciones de una banca móvil, como son retiros y

depósitos por parte de los socios de una Cooperativa y el Core de esta.

El sistema a desarrollar en las prácticas se abocó al análisis y desarrollo del

paquete de operaciones financieras en cuenta de ahorros de un socio, estos

casos de uso comprenden las respectivas búsquedas de socio como de sus

respectivas cuentas, depósito y retiro en cuenta de ahorro.

El Sistema de Banca Móvil permite que algunas de las actividades

financieras de la Cooperativa se realicen a través del dispositivo móvil, que

generarán mayores movimientos financieros y la facilidad de que el agente

de banca móvil se encuentre en distintas partes del mundo.

vi

INTRODUCCION

El Sistema de Banca Móvil para las Cooperativas es un servicio que emplea

como único canal de atención el celular, permitiendo al cliente realizar las

transacciones financieras en lugares donde se encuentro nuestro agente

móvil.

El Sistema de Banca Móvil permite realizar operaciones financieras como,

depósito, retiro, abono a cuentas de crédito, transferencia entre cuentas y

otros más por ende facilitará al socio en realizar sus operaciones sin

necesidad de acudir a la agencia de la Cooperativa.

La metodología de software empleada fue ICONIX; con el apoyo del

paradigma orientado a objetos, el lenguaje de modelado (UML) y diversos

consejos para diseñar sistemas en móviles.

Las tecnologías que se emplearon para el desarrollo del sistema son: para la

programación el lenguaje java 2 micro edition, la administración de base de

datos local se realizará con java 2 Data Base Micro Edition, para el

modelado el case Enterprise Architect 7.1.

vii

CAPITULO I OBJETIVOS

I.1 OBJETIVO GENERAL

Desarrollar una aplicación de Banca Móvil para cooperativas, con

el empleo de la metodología ICONIX, CASE Enterprise Architect, lenguaje de

programación java 2 micro edition, base de datos Java micro DB, con la

finalidad de brindar a las cooperativas del Perú el servicio de Banca Móvil

para facilitar sus operaciones financieras, 2010.

I.2 OBJETIVOS ESPECIFICOS

a) Diseñar un sistema para móviles empleando la metodología ICONIX

b) Diseñar e implementar un sistema para móviles

8

CAPITULO IIMARCO TEORICO

II.1 METODOLOGIA ICONIX

(ROSENBERG y STEPHENS, 2007) definen a ICONIX como un

“proceso de software práctico”. Un proceso pequeño y ligero, como XP, que

no descarta el análisis ni el diseño como lo hace este, y es orientado a los

casos de uso como lo hace RUP.

Este proceso también hace uso aerodinámico del UML mientras guarda un

enfoque afilado en la trazabilidad de requisitos. El proceso se guía igual a la

visión original de Jacobson del manejo de casos de uso, esto produce un

resultado concreto, específico y casos de uso fácilmente entendible, que un

equipo de un proyecto puede usar para conducir el esfuerzo hacia un

desarrollo real. El enfoque es flexible y abierto; siempre se puede

seleccionar de los otros aspectos del UML para complementar los materiales

básicos.

Este proceso de desarrollo de software presenta 3 características:

Primero, es reiterativo e incremental. Las iteraciones múltiples ocurren

entre el desarrollo del modelo del dominio e identificar y analizar los casos

de uso. Otras iteraciones existen también, como los procesos del equipo a

través del ciclo de vida. El modelo estático se refina incrementalmente

durante las iteraciones sucesivas a través del modelo dinámico (compuesto

de los casos de uso, análisis de robustez y el diagrama de secuencia.

Segundo, el enfoque ofrece un alto grado de seguimiento. Por el camino, a

cada paso usted consultara de alguna manera los requisitos anteriores.

Nunca hay un punto en que el proceso le permita desviarse lejos de las

necesidades del usuario. Seguimiento se refiere también al hecho que usted

puede seguir los objetos paso a paso como el análisis dentro del diseño.

Tercero, el enfoque ofrece uso aerodinámico del UML.

9

Figura 2. 1 Metodología ICONIX

Fuente: (ROSENBERG y STEPHENS, 2007)

II.1.1 MODELO DE DOMINIO

El modelo de dominio es una parte esencial del Proceso de ICONIX,

construye la porción estática inicial de un modelo que es esencial al

manejar su plan de la aplicación, antes de los casos del uso. El Modelo de

Dominio trata de Identificar en el “mundo real” los objetos y todas las

relaciones de agregación y generalización entre ellos

Figura 2. 2 Modelo de dominio en el proceso ICONIX Fuente:


10

Para poder realizar un modelo de dominio adecuado, (ROSENBERG y

STEPHENS, 2007) mencionan en su libro una serie de pasos, que en el

cuadro siguiente se detalla con más exactitud.

Actividad Tarea Artefactos Técnicas Actores

A.1. Identificar objetos del mundo real.

T.1. Identificar requisitos del alto nivel.

T.2. De cada requisito de alto nivel identificar los objetos del mundo real.

T.3. Depurar la lista de objetos.

A.1. Lista de requisitos de alto nivel.

A.2. Listado de objetos identificados del mundo real.

A.3. Lista depurada

T.1. Entrevistas.

T.2. Realzar nombres y frases convirtiendo todos los plurales en singulares.

T.3. Identificar la duplicación de términos.

Analista Cliente Usuario

A.2. Dibuje el modelo de dominio.

T.1. Relacionar los objetos identificados.

T.2. Refinar el modelo de dominio

A.1. Objetos relacionados.

A.2. Modelo de dominio refinado.

T.1. Agrupamiento con las preguntas ¿es un? , ¿es parte de ?.

T.2. Lluvia de ideas

Analista

Cuadro 2. 1 Actividades de análisis de requisitos

II.1.2 MODELO DE CASOS DE USO

Dentro del proceso de ICONIX, uno de los primeros pasos involucra

la construcción del modelo de casos de uso. Este modelo se usa para

capturar los requisitos del usuario de un nuevo sistema (si está

desarrollándose desde el principio o basado en un sistema existente)

detallando todos los guiones que los usuarios realizarán. Los casos del uso

manejan al modelo dinámico y, por la extensión, el esfuerzo del desarrollo

entero.

11

(ROSENBERG y STEPHENS, 2007) escriben que “Los casos de uso le dan

algo a partir del cual se puede diseñar, y desde el cual se puede estimar el

tiempo y el esfuerzo.”

Figura 2. 3Modelo de dominio en el proceso ICONIX


Actividad Tarea Artefactos Técnicas Actores

1. Identifique los Casos de Uso y ubíquelos en el diagrama de los casos de uso.

T.1. Entrevista con los expertos del negocio. T.2. Obtener los casos de uso a partir de la información recopilada.

A.1. Información recopilada.

A.2. Casos de uso identificado.

T.1. Entrevistas.

T.2. Análisis de requisitos.

Analista. Cliente. Usuario

2. Organice los casos de uso lógicamente en grupos capture esta información en diagrama de paquetes

T.3. Agrupar los casos de uso en paquetes afines.

A.3. Diagrama de Paquete de casos de uso.

T.1. Cuadro sinóptico.

Analista

3. Asigne los requisitos

T.4. Asignar los requisitos

A.4. Casos de uso con sus

T.1. Lluvia de ideas.

Analista

12

funcionales a los casos de uso y objetos de dominio.

funcionales. respectivos requisitos funcionales.

4. Escriba el primer borrador de casos de uso.

T.5. Escribir el borrador del caso de uso.

A.5. Primer borrador del caso de uso.

T.1. Resumen Analista

Cuadro 2. 2 actividades del modelo de casos de uso

II.1.3 REVISION DE REQUISITOS

La etapa de revisión de requisitos nos garantiza que el sistema tal

y como se describe coincide con los requisitos. Se trata de un período de

sesiones de colaboración que impliquen al representante(s) del cliente, los

usuarios finales (es decir, las personas que realmente van a utilizar el

sistema, o quien está usando el sistema actual que se sustituirá). El cliente

estuvo involucrado en los requisitos iníciales y es de esperar que también

participe en su taller de modelado de casos de uso. Pero, ahora que el

primer-borrador de casos de uso está totalmente escrito, necesita tener al

cliente de nuevo y asegurarse de que el sistema tal y como se describe

realmente coincide con sus requisitos. En algún momento, tendrás que

enlazar las necesidades funcionales a los Casos de Uso, de modo que

puedas demostrar que todos los requisitos del cliente se han implementado

exitosamente. Es una buena práctica hacer esto justo después de que se ha

escrito la descripción de los Casos de Uso, como la asignación de requisitos

para el Casos de Uso a menudo se manifiesta en algunas zonas en que los

requisitos podrían haber sido dejados de lado. Pero si no realizas esta

actividad en esa etapa, entonces deberás tratar de hacer esto durante la

revisión de requisitos. Si ha utilizado los requisitos funcionales como la

principal fuente de Casos de Uso, entonces ya debería haber una correlación

directa entre los requisitos y los Casos de Uso.

13

Figura 2. 4Revisión de requisitos Fuente:


Actividad Tarea Artefacto Técnica Actores

1. Revisar el modelo de dominio.

T.1. Cerciorar de que el modelo de dominio muestra relaciones de generalización y agregación dentro de las abstracciones más importantes del dominio del problema.

A.1. Modelo de dominio revisado.

T.1. Lectura y corrección.

Analista

2. Revisar los casos de uso y prototipos GUI.

T.1. Verificar que los requisitos funcionales están en voz pasiva y no en activa.

A.1. Casos de usos revisados.

A.2. Paquetes de caso de uso revisado.

T.1. Lectura y corrección.

Analista

14

T.2. Asegurar que los casos de uso están organizados en paquetes.

T.3. Cerciorarse que la descripción de los casos de uso esté complementada con los prototipos GUI.

A.3. Prototipos GUI Revisados

Cuadro 2. 3 Actividades para revisión de requisitos

II.1.4 ANALISIS DE ROBUSTEZ

Es la etapa del proceso ICONIX, la cual describe (ROSENBERG,

2007) como una técnica que es simple y útil, se une el análisis al diseño

asegurando que su texto de caso de uso esté correcto. Se dirige caminos

necesarios de acción y le permite continuar descubriendo los objetos. Este

tema enfoca el análisis de robustez que involucra análisis del texto de

descripción de los casos del uso e identificando un conjunto de primeras

suposiciones de los objetos que participarán en cada caso de uso,

clasificando estos objetos en tres tipos:

o El objeto Límite, son aquellos objetos que los actores usan para

comunicarse con el sistema, mayormente son las interfaces o

pantallas.

o El objeto Entidad que se obtienen del modelo del dominio.

o El objeto Control, qué sirve como la " unión " entre el objeto Limite

y el objeto entidad.

Esta técnica es simple pero muy útil porque sirve como un eslabón crucial

entre el Análisis y modelo. El diagrama retrata la esencia del enfoque

aerodinámico al desarrollo del software, que incluye un juego mínimo de

diagramas de UML y algunas valiosas técnicas que se toman de los casos

del uso para codificar rápida y eficazmente.

En esta fase se refinará el texto del caso de uso y el modelo será solido

como resultado del análisis de robustez. Dentro del proceso de ICONIX, esta

15

técnica simple pero muy útil sirve como un eslabón crucial entre el modelo

y el análisis.

Se realiza el análisis de robustez para cada caso de uso, utilizando en el

texto del caso de uso, una frase a la vez, y dibujando a los actores, el límite

apropiado, el objeto entidad y el controlador, y las conexiones entre los

varios elementos del diagrama. Se debe encajar el camino básico y todos

los caminos alternados en un diagrama. Cuatro reglas básicas:

o Los Actores sólo pueden interactuar con los objetos límite.

o Los objetos límite sólo pueden interactuar con controladores y

actores.

o Los objetos entidad sólo pueden interactuar con controladores.

o Los controladores pueden interactuar con objetos limite y objetos

entidad, y con otros controladores, pero no con actores

o Los Objetos Límite y objetos Entidad son los sustantivos, y los

controladores son los verbos. Los sustantivos no pueden

interactuar con otros sustantivos, pero los verbos pueden

interactuar con sustantivos o verbos.


A1. Desambiguar el primer borrador de la descripción de los casos de uso.

T.1. Reescribir los casos de uso mientras se dibuja el diagraman de robustez.

A.1. Descripción de casos de uso desambiguado.

Análisis Analista

A2. Identificar un primer corte de los objetos que cumpla con cada escenario.

T.1. Hacer un objeto interfaz para cada pantalla.

T.2. Identificar los controles y entidades dentro del diagrama de robustez de los casos de uso y relacionarla.

A.1. Objeto de interfaz de casos de uso.

A.2. Diagrama de robustez.

Análisis Analista

A3. Actualizar el modelo de dominio a medida que se

T.1. Identificar nuevos objetos de dominio

A.1. Modelo de dominio actualizado.

Diagramación Analista

16

descubra nuevos objetos y atributos.

dentro del diagrama de robustez.

Cuadro 2. 4 Actividades de análisis de robustez

II.1.5 REVISION PRELIMINAR DE DISEÑO

(ROSENGER Y STEPHENS, 2007), mencionan que las sesiones de

Revisión de diseño preliminar ayudan a asegurarse que los diagramas de

robustez, el modelo de dominio y la descripción de los casos de uso

coincidan entre sí. Esta revisión es el puente entre el diseño preliminar e las

etapas de diseño detallado, para cada paquete de casos de uso.

Figura 2. 5 Revisión preliminar de diseño


II.1.6 ARQUITECTURA TECNICA

Según (ROSENBERG y STEPHENS, 2007) “la arquitectura técnica

(también conocida como arquitectura del sistema y arquitectura del

software) generalmente describe el sistema que se intenta construir en

términos de estructura.”

17

Para realizar una buena arquitectura técnica hay que basarse en los niveles

de servicios que se van a ofrecer, la topología a usar, todo basado en un

análisis exhaustivo en el número de personas que van a utilizar el sistema,

las horas pico en que se usarán y entre otros.

En resumen la arquitectura técnica tiene que estar acorde a los requisitos

del sistema, tiene que tener factores tales como escalabilidad, seguridad y

disponibilidad; internacionalización y localización.

II.1.7 DIAGRAMA DE SECUENCIA

La interacción diseñada le permite detallar la conducta de sus

objetos y encuentre las clases apropiadas para los atributos y

funcionamientos. Cuando se termina con planeamiento de dominio y

análisis de robustez, se habrá encontrado la mayoría de los objetos en el

problema y se asignara algunos atributos a ellos. Se habrá definido las

relaciones estáticas entre los objetos en su diagrama de la clase de alto

nivel y unas relaciones dinámicas en sus diagramas de robustez. Ahora es

tiempo para diseñar como su software realmente trabajará (en otros

términos, para definir la solución a su problema).

El diseño de Interacción es la fase dónde usted construye a los hilos que

unen sus objetos. Aquí, se empezará a ver cómo el nuevo sistema realiza

una conducta útil.

Dentro del enfoque de ICONIX, los diagramas de secuencia representan el

producto de trabajo de un mayor modelo. Se dibuja un diagrama de

secuencia que abarque el camino básico y todos los caminos alternativos

dentro de cada uno de casos de uso. Los resultados forman el centro de su

modelo dinámico (que es la conducta del tiempo de ejecución del sistema,

incluyendo cómo se logrará esa conducta) que se define en gran detalle.

Hay cuatro tipos de elementos en un diagrama de secuencia: el texto para

el camino de acción de los casos de uso, objetos, mensajes y métodos

(funcionamientos).

o El texto para el camino de acción de los casos de uso aparece abajo

en el lado izquierdo. Es una buena idea separar el texto con el

18

espacio en blanco para que sea fácil ver qué frase(s) corresponde

con cada uno de los elementos a la derecha.

o Los Objetos que usted trae directamente de sus diagramas de

robustez, se representa con dos componentes: el nombre del objeto

y la clase a que ese objeto pertenece. Éstos aparecen en una caja

arriba de la página, de la forma object: class. Una línea punteada

corre de esa caja hacia abajo en toda la longitud de la página. Usted

puede mostrar los iconos de diagrama de robustez sobre las cajas

del objeto.

o Los mensajes son las flechas entre los objetos. Una flecha del

mensaje puede ir directamente entre dos líneas punteadas, entre

una línea y un rectángulo del método, o entre dos rectángulos del

método.

o Los métodos (funcionamientos) se muestran como rectángulos que

quedan encima de las líneas punteadas que pertenecen a los

objetos a que ellos se asignan. Usted puede usar las longitudes de

estos rectángulos para reflejar el enfoque de mando dentro de la

secuencia. Un método en particular parte del extremo del

rectángulo.

Figura 2. 6 Diagrama de secuencia en el proceso ICONIX



A1. Generar un Diagrama Esqueleto de

T.1. Seleccionar todos los

A.1. Objetos seleccionados.

Análisis Analista

19

los Objetos Entidad e Interfaz.

objetos entidad e Interfaces en el mismo caso de uso.

A2. Dibujar flechas de mensajes entre objetos.

T.2. Hacer que los objetos de control estén bien detallados.

A.2. Mensajes entre objetos bien definidos.

Análisis Analista

A3. Actualizar el Diagrama de clases con los nuevos atributos y operaciones.

T.3. Quitar y/o agregar en el diagrama de clases algunos atributos y operaciones.

A.3. Diagrama

de secuencia

Modelo de

clases

actualizado

Análisis Analista

Cuadro 2. 5 Actividades para realizar diagrama de secuencia

II.1.8 REVISION CRITICA DEL DISEÑO

La revisión crítica de diseño ayuda a alcanzar tres objetivos

importantes, antes de comenzar la codificación:

o Asegurarse de que el "cómo" del diseño detallado coincida con el

"qué" especificado en los requisitos. En otras palabras, para cada

caso de uso, es necesario que coincida el caso de uso con el

diagrama de secuencia.

o Revisar la calidad del diseño.

o Comprobar la continuidad de los mensajes. Necesita comprobar la

dirección de las flechas de mensaje en los diagramas de secuencia,

y asegurarse de que se pueda reconocer cual objeto esta en

control.

El cliente no debe participar en el CDR-sólo los diseñadores y

desarrolladores. Es una sesión de Revisión Técnica, por lo que debe estar

conformado por gente técnica. El cliente (además de los usuarios

principales, etc.) tiene mucho que contribuir a los requisitos funcionales,

casos de uso y así sucesivamente, pero a menos que el cliente sea un

diseñador técnico experto que pudiese contribuir a la revisión del diseño, es

preferible que no esté en una CDR.

20

II.1.9 IMPLEMENTACION

Es la codificación del sistema, es decir llevarlo al lenguaje elegido en

la arquitectura técnica, en la implementación debe estar guiado por el

diseño del modelo en este caso el diagrama de secuencia, adicional el

diagrama de clases final obtenido del diseño, esto ayudará al programador o

programadores a enfocarse en la secuencia del sistema y obtener un

sistema final que esté acorde a los requisitos.

II.1.10 REVISION DEL CODIGO Y ACTUALIZACION DEL MODELO

La revisión de código es la exanimación sistemática del código

fuente del software, se propone encontrar y fijar errores pasados por alto en

fase inicial del desarrollo, mejorando el software.

Las revisiones de código pueden encontrar y quitar a menudo un campo

común vulnerabilidades por ejemplo problemas de seguridad, optimización

de hardware y desbordamientos del almacenador intermediario, de tal

modo mejorando seguridad del software.

II.1.11 PRUEBAS BASADAS EN DISEÑO

Las pruebas de software, en inglés testing son los procesos que

permiten verificar y revelar el software. Son utilizadas para identificar

posibles fallos de implementación de un programa de ordenador. La Prueba

basada en el diseño provee un método para producir casos de prueba y

verificar que todos los escenarios específicos están completos. Puedes

además usar este proceso para escribir pruebas unitarias ejecutables de

estos casos de prueba.

II.2 TEORIA DE OBJETOS

II.2.1 CLASE Y OBJETO

(PRESSMAN, 2002) menciona que una clase es un concepto del

paradigma orientado a objetos, la clase es la capacidad con que se

encapsula abstracciones de los diversos datos que son requeridos para

describir el contenido y el comportamiento de alguna entidad del mundo

real, en otras palabras la clase es una descripción generalizada de una

colección de objetos, mientras que un objeto es una instanciación de la

clase.

21

Las clases están formadas por diversos elementos, entre los cuales se

encuentras los atributos, que son las propiedades que tienen los objetos, y

las operaciones, métodos y servicios, que son los diferentes

comportamientos que son encapsulados de la colección de objetos, y los

mensajes, que son los medios por los cuales interactúan los diferentes

objetos.

II.2.2 ENCAPSULAMIENTO, HERENCIA Y POLIMORFISMO

Estas son las características del paradigma OO, (PRESSMAN, 2002)

hace referencia que el encapsulamiento es el empaquetado de métodos y

atributos de un o colección de objetos; la herencia es la obtención de

atributos y métodos de una superclase X a una sub clase Y; y el

Polimorfismo es la característica que reduce en gran medida el esfuerzo

necesario para extender el paradigma orientado a objetos.

II.3 UML

(WIKIPEDIA, 2011) define “Lenguaje Unificado de Modelado (LUM o

UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de

modelado de sistemas de software más conocido y utilizado en la

actualidad; está respaldado por el OMG (Object Management Group). Es un

lenguaje gráfico para visualizar, especificar, construir y documentar un

sistema. UML ofrece un estándar para describir un "plano" del sistema

(modelo), incluyendo aspectos conceptuales tales como procesos de

negocio y funciones del sistema, y aspectos concretos como expresiones de

lenguajes de programación, esquemas de bases de datos y componentes

reutilizables.”

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de

manera concreta, a veces es útil categorizarlos jerárquicamente, como se

muestra en la figura de la derecha.

Los Diagramas de Estructura enfatizan en los elementos que deben existir

en el sistema modelado:

Diagrama de clases

Diagrama de componentes

22

Diagrama de objetos

Diagrama de estructura compuesta (UML 2.0)

Diagrama de despliegue

Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el

sistema modelado:

Diagrama de actividades

Diagrama de casos de uso

Diagrama de estados

Los Diagramas de Interacción son un subtipo de diagramas de

comportamiento, que enfatiza sobre el flujo de control y de datos entre los

elementos del sistema modelado:

Diagrama de secuencia

Diagrama de comunicación, que es una versión simplificada del

Diagrama de colaboración (UML 1.x)

Diagrama de tiempos (UML 2.0)

Diagrama global de interacciones o Diagrama de vista de interacción

(UML 2.0)

En específico para la metodología ICONIX, no se usarán los 13 diagramas,

solo se emplearán el diagrama de clases, el diagrama de casos de uso, el

diagrama de colaboración y el diagrama de secuencia; en algunos casos el

diagrama de componentes para ver la interacción de los componentes del

sistema. Adicionalmente estos diagramas se utilizan de una forma un poco

más libre, siguiendo a la metodología ICONIX.

II.4 MODELO VISTA CONTROLADOR

El patrón MVC puede fácilmente articularse en la arquitectura

J2ME; (FROUFE y CARDENES, 2004) mencionan que en la arquitectura MVC

para J2ME:

Modelo; son las preferencias, constantes y modelo de datos.

Vista; lógica de presentación en pantalla

Controlador; comunicaciones, lógica de la aplicación

23

En especial para J2ME el controlador debe estar preparado para conexiones

a un servidor de datos, para soportar petición de datos mientras esté

moviéndose en un entorno pull o push.

La vista debe estar preparada para la presentación e diversos tipos de

configuraciones y resoluciones.

El modelo incluye preferencias del usuario guardadas en el sistema de

almacenamiento permanente del dispositivo, las constantes que utilice de

partida la aplicación y todos los datos que se presenten al usuario.

Este tipo de arquitectura es ampliamente usada en aplicativos móviles,

pues casi siempre estos se conectan a un servidor de base de datos o con

aplicativos que se encuentran alojados en otros sitios, como son los web

services.

Figura 2. 7 Modelo Vista Controlador

Fuente: (SUN, 2011)

II.5 JAVA 2 MICRO EDITION

Java 2 Micro Edition es un conjunto de especificaciones, cada uno

aplicable a cierto número de requisitos, J2ME no define un nuevo lenguaje,

sino que mantiene la compatibilidad con J2SE, adaptando esta tecnología al

os dispositivos móviles, J2ME elimina partes de la edición J2SE que no son

compatibles con este tipo de dispositivos con capacidades limitadas .

24

Figura 2. 8 Arquitectura J2ME

Fuente: Caraballo, 2009

II.5.1 CONFIGURACIONES

Se entiende por configuraciones al entorno de ejecución java

completo que define al entorno de ejecución básico de J2ME, cuyo objetivo

es adecuarse a las necesidades de una familia de dispositivos con

capacidades similares. (FROUFE, 2004) menciona que las configuraciones

están constituidas por 3 elementos, los cuales son:

1. Una máquina virtual para ejecutar el bytecode de la aplicación.

2. Código nativo para realizar la interface entre java y el sistema

operativo del dispositivo.

3. Un conjunto de clases Java que constituyen un entorno de

ejecución

Para poder elegir una configuración adecuada, es importante definir a qué

tipo de familia corresponde el dispositivo en el cual se va ejecutar nuestra

aplicación.

En la actualidad están definidas dos tipos de configuraciones: Connected

Device Configuration(CDC) y Connected Limited Configuration(CLDC).

25

CDC

La configuración para dispositivos conectados JSR-36 está orientado a

dispositivos dotados con microprocesadores de 32 bits y que disponen de

2mb o mas de memoria virtual, incluyendo memoria RAM y flash ROM. Los

dispositivos tienen que tener capacidad de conexión a red.

CLDC

Configuración para dispositivos con configuración limitada está definida

para las características de dispositivos cuyos procesadores estén entre 16 y

32 bits, de entre 8 a 32 MHz y con una cantidad de memoria total

disponible para java de 160 a 192 Kb.

II.5.2 PERFILES

Un perfil define el tipo de dispositivo soportado, por ejemplo el

Perfil para Dispositivos de Información Móvil (Móvil Information Device

Profile, MIDP) define el perfil para las aplicaciones s que se ejecutarán en

teléfonos celulares y buscapersonas.

El MIDP es el perfil basado para celulares, el cual no permite a los midlets

acceder al sistema operativo, porque si accediera, la aplicación no sería

portable.

II.5.3 KVM

Más conocido por el nombre de Kilobyte Virtual Machine, la KVM es

la implementación completa de una máquina virtual java optimizada para

ejecutarse en dispositivos con recursos restringidos, Esta máquina virtual es

una parte de la JVM que es la java virtual machine comúnmente conocida,

con la diferencia que solo implementa algunas clases que suelen ser útiles

para el desarrollo de aplicaciones móviles.

Cabe señalar que para la ejecución de un aplicativo con la configuración

CLD o CLDC con un perfil MIDP u otro, no siempre es preciso que estuviera

la KVM, si no otra máquina virtual que contenga las clases requeridas y los

mecanismos que cumple la máquina virtual, es por ello que en la actualidad

existen diversas máquinas virtuales pre compiladas, entre ellas la CVM o

26

como la máquina virtual Total Cross para programadores de superwaba que

no es otra cosa que la máquina virtual java con otro tipo de compilación.

II.6 SERVICIOS WEB

(SINAY, 2007) menciona que los web services es un estándar de

comunicación entre procesos y/componentes, diseñado para ser

multiplataforma y multilenguaje. Mientras que (WIKIPEDIA, 2011) define web

service como “un conjunto de protocolos y estándares que sirven para

intercambiar datos entre aplicaciones. Distintas aplicaciones de software

desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre

cualquier plataforma, pueden utilizar los servicios web para intercambiar

datos en redes de ordenadores como Internet.”

Lo que proporciona los web service es la interoperabilidad, que se consigue

empleando estándares abiertos, entre los estándares empleados tenemos:

XML, SOAP, WSDL, UDDI entre otros.

II.6.1 XML

(W3C, 2011) define “Lenguaje de marcado extensible (XML) es un

formato simple, texto muy flexible derivado de SGML (ISO 8879).

Originalmente diseñado para afrontar los retos de la publicación electrónica

a gran escala, XML también está desempeñando un papel cada vez más

importante en el intercambio de una amplia variedad de datos en la Web y

en otros lugares.”

II.6.2 SOAP

SOAP es un protocolo para el intercambio de mensajes sobre redes

de computadoras, generalmente usando HTTP. Está basado en XML, a

diferencia de DCOM y CORBA que son binarios; esto facilita la lectura por

parte de los humanos, pero también los mensajes resultan más largos y, por

lo tanto, considerablemente más lentos de transferir.

Existen múltiples tipos de modelos de mensajes en SOAP pero, por lejos, el

más común es el RPC, en donde un nodo de red (el cliente) envía un

27

mensaje de solicitud a otro nodo (el servidor) y el servidor inmediatamente

responde el mensaje al cliente.

Los mensajes SOAP, son independientes del sistema operativo, y pueden

transportarse en varios protocolos de internet como SMTP, MIME y HTTP.

II.6.3 WSDL

WSDL son las siglas de Web Services Description Language, un

formato XML que se utiliza para describir servicios Web (algunas personas lo

leen como wisdel). La versión 1.0 fue la primera recomendación por parte

del W3C y la versión 1.1 no alcanzó nunca tal estatus. La versión 2.0 se

convirtió en la recomendación actual por parte de dicha entidad.

WSDL describe la interfaz pública a los servicios Web. Está basado en XML y

describe la forma de comunicación, es decir, los requisitos del protocolo y

los formatos de los mensajes necesarios para interactuar con los servicios

listados en su catálogo. Las operaciones y mensajes que soporta se

describen en abstracto y se ligan después al protocolo concreto de red y al

formato del mensaje.

Así, WSDL se usa a menudo en combinación con SOAP y XML Schema. Un

programa cliente que se conecta a un servicio web puede leer el WSDL para

determinar qué funciones están disponibles en el servidor. Los tipos de

datos especiales se incluyen en el archivo WSDL en forma de XML Schema.

El cliente puede usar SOAP para hacer la llamada a una de las funciones

listadas en el WSDL.

El WSDL nos permite tener una descripción de un servicio web. Especifica la

interfaz abstracta a través de la cual un cliente puede acceder al servicio y

los detalles de cómo se debe utilizar.

II.6.4 UDDI

UDDI son las siglas del catálogo de negocios de Internet

denominado Universal Description, Discovery and Integration. El registro en

el catálogo se hace en XML. UDDI es una iniciativa industrial abierta

28

(sufragada por la OASIS) entroncada en el contexto de los servicios Web. El

registro de un negocio en UDDI tiene tres partes:

Páginas blancas - dirección, contacto y otros identificadores conocidos.

Páginas amarillas - categorización industrial basada en taxonomías.

Páginas verdes - información técnica sobre los servicios que aportan las

propias empresas.

UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es

ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los

que se describen los requisitos del protocolo y los formatos del mensaje

solicitado para interactuar con los servicios Web del catálogo de registros.

II.7 BLUETOOTH

(GIMENO, 2004) define Bluetooth como “una tecnología de

comunicación inalámbrica omnidireccional”. Se ideó pensando en

dispositivos de bajo consumo y comunicaciones a corta distancia (10

metros).

Se trata de una tecnología barata con un ancho de banda reducido: hasta

11 Mbit/s. Es ideal para periféricos de ordenador (ratón, teclado, manos

libres,...) y dispositivos móviles (teléfonos móviles, PDAs, Pocket PCs, etc).

Mediante Bluetooth es posible formar pequeñas redes de dispositivos

conectados denominadas piconets. Se pueden conectar varias piconets

formando lo que se denomina una scatternet.

Las principales aplicaciones de Bluetooth son: transferencia de archivos,

sincronización de dispositivos y conectividad de periféricos.

II.7.1 API JSR 82

Este API está dividida en dos partes: el paquete javax.bluetooth y

el paquete javax.obex. Los dos paquetes son totalmente independientes. El

primero de ellos define clases e interfaces básicas para el descubrimiento

de dispositivos, descubrimiento de servicios, conexión y comunicación. La

comunicación a través de javax.bluetooth es a bajo nivel: mediante flujos de

datos o mediante la transmisión de arrays de bytes.

Por el contrario el paquete javax.obex permite manejar el protocolo de alto

nivel OBEX (OBject EXchange). Este protocolo es muy similar a HTTP y es

utilizado sobre todo para el intercambio de archivos. El protocolo OBEX es

un estándar desarrollado por IrDA y es utilizado también sobre otras

tecnologías inalámbricas distintas de Bluetooth.

29

La plataforma principal de desarrollo del API JSR-82 es J2ME. El API ha sido

diseñado para depender de la configuración CLDC. Sin embargo existen

implementaciones para poder hacer uso de este API en J2SE. Al final del

tutorial se listan la mayoría de las implementaciones del JSR 82 existentes.

II.8 TECNOLOGIA

II.8.1 ENTERPRISE ARCHITECT

Es una herramienta para flexible, completa y potente de modelado

en UML. Provee lo más nuevo en desarrollo de sistemas, administración de

proyectos y análisis de negocio.

EA es una herramienta que abarca integralmente el ciclo de vida, cubriendo

el desarrollo de software en caso particular para la metodología ICONIX.

Enterprise Architect fue construido en base al excepcional éxito de las

versiones previas con un completo soporte para el estándar UML 2.0 y a

partir de la versión 7.8 para UML 2.2.

II.8.2 JAVA 2 MICRO DB

Es un proyecto open source desarrollado en la Universidad

Politécnica de Catalunya, que tiene como principal objetivo proporcionar a

los programadores de J2ME APIs para gestionar una base de datos relacional

(limitada) en un dispositivo móvil.

(FROUFE, 2004) menciona que es una familia de especificaciones que

definen varias versiones minimizadas de la plataforma Java 2; estas

versiones minimizadas pueden ser usadas para programar en dispositivos

electrónicos; desde teléfonos celulares, en PDAs, hasta en tarjetas

inteligentes, etc. Basada en familias y categorías, donde una categoría

define un tipo de dispositivo particular: celulares, buscapersonas,

organizadores personales y entre otras; y la familia de dispositivos a

aquellos que están agrupados de acuerdo a las capacidades de memoria,

capacidad de procesamiento.

II.8.2.1 J2MLIB

Es una librería del proyecto J2MEMicroDB desarrollada en la

Universitat Politècnica de Catalunya por los profesores Maria José Casany,

Marc Alier (Ludo) y Pablo Casado, junto con los estudiantes de proyecto de

30

fin de carrera de la Facultad de informática de Barcelona.

J2MESDLIB permite trabajar con tablas relacionales en dispositivos móviles.

Esta API proporciona los métodos necesarios para poder crear, modificar y

borrar, en definitiva, gestionar tablas en una base de datos relacional.

II.8.2.2 KXML

KXML es un analizador sintáctico de XML ligero basado en Java

diseñado para ser ejecutado en sistemas integrados limitados como

dispositivos móviles personales.

Es un analizador de tipo pull, lo que significa que lee una pequeña porción

del documento cada vez. Así la aplicación conduce al analizador a través del

documento XML pidiendo repetidamente la siguiente porción del mismo.

II.9 SISTEMA OPERATIVO SYMBIAN

(Wikipedia, 2011) hace mención que Symbian es un sistema

operativo que fue producto de la alianza de varias empresas de telefonía

móvil, entre las que se encuentran Nokia, Sony Ericsson, Psion, Samsung,

Siemens, Arima, Benq, Fujitsu, Lenovo, LG, Motorola, Mitsubishi Electric,

Panasonic, Sharp, etc. Sus orígenes provienen de su antepasado EPOC32,

utilizado en PDA's y Handhelds de PSION.

La mayoría de los móviles con Symbian son de la compañía NOKIA; todos los

modelos de la serie 60 (5700.) y superiores, incluyéndose toda la Serie N y

los nuevos táctiles N97, 5530, 5230, 5800, X6 y los más recientes N8 y C7

(con la versión 3 de Symbian, son los móviles más importantes actualmente

para NOKIA), los cuatro con la nueva versión v5, a excepción de los de tipo

handheld (los cuales funcionan con Maemo corriendo sobre Linux) y los

denominados "Internet Tablet" (N800,N810 y N900).

II.10 COOPERATIVA DE AHORRO Y CREDITO

Las cooperativas de ahorro y crédito son empresas de propiedad

conjunta, autónomas frente al Estado democráticamente administradas. Se

constituyen en forma libre y voluntaria, por medio de la asociación de

personas, con la finalidad de atender las necesidades financieras, sociales y

culturales de sus miembros.

31

http://es.wikipedia.org/wiki/Maemo

http://es.wikipedia.org/wiki/Handheld

http://es.wikipedia.org/wiki/Serie_N_de_Nokia

http://es.wikipedia.org/wiki/Handheld

http://es.wikipedia.org/wiki/PDA

http://en.wikipedia.org/wiki/EPOC_(computing)

http://es.wikipedia.org/wiki/Sharp_Corporation

http://es.wikipedia.org/wiki/Panasonic

http://es.wikipedia.org/wiki/Mitsubishi

http://es.wikipedia.org/wiki/Motorola

http://es.wikipedia.org/wiki/LG

http://es.wikipedia.org/wiki/Lenovo

http://es.wikipedia.org/wiki/Fujitsu

http://es.wikipedia.org/wiki/Benq

http://es.wikipedia.org/w/index.php?title=Arima_Computer_Corporation&action=edit&redlink=1

http://es.wikipedia.org/wiki/Siemens_AG

http://es.wikipedia.org/wiki/Samsung

http://en.wikipedia.org/wiki/Psion

http://es.wikipedia.org/wiki/Sony_Ericsson

http://es.wikipedia.org/wiki/Nokia

http://es.wikipedia.org/wiki/Sistema_operativo

http://es.wikipedia.org/wiki/Sistema_operativo

Las cooperativas fomentan el ahorro en sus diversas modalidades, además

de brindar otros servicios financieros a sus socios. Son una verdadera

opción de apoyo mutuo y solidario frente a la crisis, porque agrupan a

personas comunes que están al margen del sistema financiero tradicional.

Los socios forman un fondo común destinado a otorgar créditos que alivien

sus necesidades urgentes o de inversión.

El carácter solidario de las cooperativas de ahorro y crédito, contrapuesto al

fin lucrativo de las entidades bancarias, determina que gran cantidad de

personas opten por sus servicios.

II.11 BANCA MOVIL

La banca móvil es un servicio que usa como único canal de

comunicación y atención la red celular, permitiendo a las personas realizar

las transacciones financieras desde un celular.

Con el creciente desarrollo de dispositivitos móviles y tecnologías de redes

inalámbricas como Wireless LAN, GSM, GPRS, Bluetooth, ha sido

perfeccionada la movilidad de los usuarios, de manera que ya no están

obligados a realizar su trabajo en un lugar fijo es por ello que surgen las

bancas móviles, para que los socios a través de de un dispositivo móvil

autorizado puedan realizar sus transacciones sin la necesidad de acudir a la

agencia de la entidad financiera.

II.12 RED PERUANA DE SERVICIOS COMPARTIDOS KUSKANET

La red peruana de servicios Compartidos Kuskanet, es una

empresa que brinda servicios Financieros a las cooperativas del país, esta

empresa ha sido subvencionada por la FENACREP (Federación Nacional de

Cooperativas de Ahorro y Crédito), WOCCU(Consejo Mundial de

Cooperativas de Ahorro y Crédito) y cooperativas que se integraron como

nuestros socios estratégicos.

Entre los principales servicios que presta Kuskanet son:

- Agencias compartidas.

- Cajeros automáticos

- POS

32

La misión de Kuskanet es "Proveer a cada uno de nuestros socios una mejor

calidad de servicio y una mayor diversidad de productos, que contribuyan a

su desarrollo económico y al logro de un mayor nivel de vida."

Y su visión: "Contribuir al desarrollo y crecimiento de las Cooperativas de

Ahorro y Crédito en el Perú."

II.13 RECOMENDACIONES PARA DISEÑAR Y PROGRAMAR CON

J2ME

Para realizar un buen diseño siempre hay que tener

consideraciones de que cosa se está haciendo y sobre que, en este caso la

arquitectura del sistema, y es por ello que para desarrollar un sistema para

dispositivos móviles hay que tener diversas consideraciones, es por ello que

(FROUFE y JORGE, 2004) mencionan una serie de recomendaciones:

- Mantener la aplicación simple, es decir no mantener características

que no sean necesarias para el sistema, las características de

adorno y complementos deben ser añadidas en un programa

aparte.

- Cuánto más pequeño sea el sistema o la descripción de los casos

de uso es mejor, es por ello que es recomendable realizar diversos

casos de uso para una secuencia de procedimientos del sistema

- Minimizar el uso de memoria en tiempo de ejecución, para ello

utilizar solo clases necesarias, y de preferencia usar tipos básicos

de datos y si se emplean clases complejas usar un recolector o

simplemente al finalizar su trabajo colocarlos a null.

- En aplicaciones con conexiones a un servidor, hacer que el servidor

realice la mayor parte de la lógica.

- No abusar del uso de clases interface, o en su mejor empleo evitar

emplearlas, pues esta hará incrementar el tamaño del jar y así

empleará más recurso de memoria.

- Si el sistema utiliza una base de datos local, es necesario realizar

un análisis para especificar que datos son necesarios para que

persistan, ya que el espacio de almacenamiento de un dispositivo

móvil es limitado.

- Evitar concatenación de cadenas

- Reducir el número de métodos de una clase. Una consecuencia del

uso de orientación a objetos es tener diversas clases con diversos

métodos que pueden ser reutilizables, y esta aplicación sea más

33

fácil de entender. Sin embargo tener muchos métodos pequeños

incrementa el tamaño de las clases y reduce su rendimiento, esto

se muestra al incrementar líneas para llamar a métodos de una

clase a otra, y en consecuencia se incrementa el uso de memoria

en tiempo de ejecución. Por ello hay que tener en cuenta la

relación Coste/ beneficio del uso de métodos pequeños y

numerosos, o tener pocos métodos y de regular tamaño.

- Reducir los métodos de conveniencia o los sobrecargados.

- Utilizar tareas e hilos y evitar la sincronización.

- Evitar el uso de procesos recursivos.

- De preferencia utilizar el patrón de diseño MVC, ya que podremos

distinguir las diferentes capas de de diseño, pero en algunos casos

va ser casi imposible separar la vista del controlador, ya que los

dos se necesitan y están ligados, es por ello que analizar el uso del

método MVC reducido, que en este caso sería el modelo de

delegado, es ampliamente utilizado ya que la interface presenta un

poco de lógica de la que contiene el controlador.

- Reducir al mínimo el uso de clases.

CAPITULO III

RESULTADOS

III.1 MODELO DE DOMINIO

a. Requisitos funcionales

N° Requisito funcional

1 El usuario podrá registrar un nuevo socio

2El sistema debe efectuar la transacción de retiro de cuenta de

ahorros de una cooperativa

El usuario podrá efectuar depósitos a cuenta de ahorros del socio

a través de los web service

34

3El usuario podrá efectuar abono de sus cuentas crédito que tenga

el socio

4 El usuario debe ser capaz de aperturar una cuenta de ahorro

5El sistema debe permitir realizar búsqueda de cuentas del socio a

través de web services

6El usuario podrá realizar transferencia de ahorros de una cuenta

del socio a otra.

7 El usuario podrá efectuar la actualización de datos de socio

8 El usuario podrá permitir realizar una pre aprobación de crédito

9 El usuario podrá permitir búsqueda de socios

10 El usuario podrá emitir reportes de su colecta del día

11El usuario podrá realizar búsqueda de cuentas del socio a través de

web services

12 El usuario podrá registrar los datos financieros de los socios

13El usuario administrador podrá registrar los parámetros de

conexión del sistema móvil

14El sistema debe ser capaz de almacenar las operaciones

financieras que se realizan

15

El usuario debe ser capaz de actualizar el catálogo de datos como

país, departamento, provincia, distrito, para el registro de

nuevos usuarios,

16El usuario debe actualizar el catálogo de empresas, tipos de

documento

17El usuario debe ser capaz de actualizar el catálogo de

profesiones

18El sistema debe sincronizar el tipo de los tipos de cuenta crédito

y ahorro

b. Requisitos no funcionales

N° Requisitos no funcionales

1El sistema móvil se conectará a un web services para realizar las

operaciones

2 El sistema utilizará un lenguaje libre

3 El sistema utilizará una base de datos libre y que sea multi plataforma

4 El sistema para seguridad tendrá que manejar datos encriptados

5 El sistema debe ejecutarse en equipos con sistema operativo Symbian

35

LISTA DE OBJETOS CANDIDATOS

- Socio

- Operaciones financieras

- Administrador

- Usuario

- Parámetros

- Cuenta de ahorro

- Cuenta crédito

- Base de datos

- Web service

- Reportes

- Colecta

- Datos financieros de socio

- Datos personales de socio

- País

- Departamento

- Provincia

- Distrito

- Catálogo

- Tipo de cuenta crédito

- Tipo de documento de identidad

- Catálogo de empresas

- Catálogo de profesiones

Desambiguación con aspecto gramatical

- El administrador y el usuario son actores del sistema, por tanto

deberán ir en el modelo de dominio.

- Socio no es un actor del sistema, en este caso particular seria un

objeto donde se almacene sus datos financieros y datos personales.

Lista de objetos de modelo de dominio

- Empresas

- Profesiones

- País

36

- Departamento

- Provincia

- Distrito

- Socio

- Operaciones

- Dispositivo

- Web service

- Cooperativa

- Cuentas socio

- Cuenta crédito

- Cuenta ahorro

- Socio

- Información financiera

- Datos personales

- Operaciones

- Empresa

- Midlet

- Base de datos

37

Primer modelo de dominio

class ModeloOminio

Operaciones

Cooperativ a

Dispositiv o

CuentaSocioSocio

DatosPersonales

WebServ ice

Pais Departamento

Distrito

Prov incia

InformacionFinanciera

Empresa

CuentaCredito

CuentaAhorro

usuario

Administrador

Transaferencia

Baso de datos

Midlet

haceuso

efectua

realiza

labora

pertenece

Figura 3. 1: Primer modelo de dominio

38

III.2 MODELO DE CASOS DE USO

Extracción de casos de uso de los requisitos

Requisitos Casos de uso

El usuario podrá registrar un nuevo

socio

Registrar socio

El sistema debe efectuar la transacción

de retiro de cuenta de ahorros de una

cooperativa

Retiro en cuanta de ahorros

El usuario podrá efectuar depósitos a

cuenta de ahorros del socio a través

de los web service

Depósito en cuenta de ahorros

El usuario podrá efectuar abono de sus

cuentas crédito que tenga el socio

Abono de crédito

El usuario debe ser capaz de apertura

una cuenta de ahorro

Apertura de cuenta de ahorro

El sistema debe permitir realizar

búsqueda de cuentas del socio a través

de web services

Búsqueda de cuentas de socio

El usuario podrá realizar transferencia

de ahorros de una cuenta del socio a

otra.

Transferencia de ahorros

El usuario podrá efectuar la actualización

de datos de socio

Actualización de datos de socio

El usuario podrá permitir realizar una pre

aprobación de crédito

Pre aprobación de crédito

El usuario podrá realizar búsqueda de

socios por DNI o nombres y apellidos

- Búsqueda de socio por DNI

- Búsqueda de socio por

Nombre y apellidos

El usuario podrá emitir reportes de su

colecta del día

- Reporte de colecta local total

- Reporte de colecta local

detallada

El usuario podrá registrar los datos

financieros de los socios

- Registrar datos financieros

de socio

El usuario administrador podrá registrar

los parámetros de conexión del sistema

Registrar parámetros de

conexión

39

móvil

El usuario debe ser capaz de actualizar

el catálogo de datos como país,

departamento, provincia, distrito,

para el registro de nuevos usuarios,

Actualizar catálogos

El usuario debe actualizar el catálogo

de empresas, tipos de documento


El usuario debe ser capaz de actualizar

el catálogo de profesiones


El usuario podrá buscar las cuentas de

ahorro que posee el socio, y las cuentas

de crédito

- Búsqueda de cuentas de

ahorros

- Búsqueda de cuentas de

socio

El usuario para poder realizar cualquiera

de las funciones debe registrarse en el

sistema

- Login

Listado de casos de uso

- Registrar socio

- Registrar datos financieros de socio

- Retiro en cuenta de ahorros

- Depósito en cuenta de ahorros

- Abono de crédito

- Apertura de cuenta de ahorro

- Búsqueda de cuenta de ahorro

- Transferencia de ahorros

- Actualización de datos de socio

- Pre aprobación de crédito

- Búsqueda de socio por DNI

- Búsqueda de socio por nombre y apellido

- Búsqueda de cuentas de ahorros

- Búsqueda de cuentas de socio

- Reporte de colecta total

- Reporte de colecta detallada

- Actualizar catálogos

- Registro de parámetros de conexión

40

- Login

Paquetes de casos de uso

a. Empaquetado de casos de uso

uc Use Case Model

Administraciòn

+ Registrar parámetros

+ login

+ Reimprimir recibo

+ Traer catálogo ciiu, división, segmento

+ Traer catálogo ciudades

+ traer catálogo de Departamentos, provincias distritos

+ Traer catálogo de profesiones y empresas de trabajo

+ Verificar conexión

Operaciones

+ Cuenta ahorros

+ Cuenta crédito

+ Selección de cuenta ahorro

+ Selección de cuenta crédito

+ Seleccion de socio

+ Transferencia de Ahorros

Reportes

+ Reporte detallado de transacciones

+ Reporte total de transacciones

Cuenta ahorros

+ Apertura de cuenta de ahorros

+ Busqueda Cuenta de ahorros

+ Depósito cuenta de ahorros

+ Impresión de vouchers

+ Retiro cuenta de ahorros

Cuenta crédito

+ Abono a préstamo

+ Consulta de crédito

+ Pre aprobación de crédito

Figura 3. 2: Diagrama de paquees de caso de uso

41

b. Paquete operaciones

uc Operaciones

Selección de cuenta crédito

Selección de cuenta ahorro

Transferencia de Ahorros

Usuario

(from Actors)

Cuenta ahorros






Cuenta crédito

+ Abono a préstamo



Seleccion de socio

«precedes»

«precedes»

«precedes»

«precedes»

«precedes»

Figura 3. 3: Diagrama de casos de uso del paquete operaciones

c. Paquete cuentas de ahorro

uc Cuenta ahorros

Apertura de cuenta de ahorros

Depósito cuenta de ahorros

Retiro cuenta de ahorros

Impresión de vouchers

Busqueda Cuenta de ahorros

Usuario

(from Actors) «precedes»

«precedes»«invokes»

«invokes»

Figura 3. 4: Diagrama de casos de uso del paquete de cuenta de ahorro

42

III.3 DESCRIPCIÓN DE CASOS DE USO

CU6: depósito en cuenta de ahorros

Descripción:

El socio realiza un depósito en su cuenta de ahorros

Curso básico:

En la lista de menú ahorro, el usuario pulsa sobre la opción de depósito, el

sistema recupera los datos de Socio que está en sesión y la Cuenta Socio

que está activa, a continuación el sistema muestra el formulario de

depósito en el midlet con los datos de nombre de usuario, cuenta de socio,

respectivamente llenados, el usuario ingresa la cantidad a depositar y hace

clic sobre procesar, el sistema muestra un alerta de verificación si está

conforme con la transacción o no, el usuario pulsa sobre procesar, el

sistema muestra al usuario la pantalla de espera, el sistema verifica la

cantidad de depósito, recupera los parámetros de conexión desde

parámetros, el sistema cifra los datos de número de cuenta y numero de

documento del socio, luego se conecta con el web service y envía los

datos del depósito, el valor de la operación, como son el valor del depósito,

la cuenta del socio, el número de identificación del socio, el nombre de

usuario que está en sesión, el numero de bluetooth para la seguridad, y

envía al web services estos datos; el sistema recibe la respuesta del web

service, parsea el mensaje recibido y obtiene el error y los datos del

depósito, verifica el error devuelto por el web service y si el error es

considerado como correcto, el sistema guarda los datos cuanta socio,

numero documento del socio, el valor de la transacción, el usuario en

sesión, el numero de referencia, el numero de secuencia de impresión , la

fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra

una alerta de transacción realizada correctamente, y si desea imprimir la

transacción.

Curso alterno:

No hay respuesta del web service: después de un tiempo de15 segundos

el web service no responde, el sistema cierra la conexión y crea un Error

el cual es devuelto a la interface, la interface valida el error y muestra

una alerta con el código y descripción del error.

43

El web service devuelve los datos incompletos, el sistema crea un Error y

lo devuelve a interface, en aquí muestra un alerta con el código y

descripción del error.

La transacción se realizó de forma correcta pero no se almacenó en la

base de datos local: el sistema al almacenar los datos en la base de

datos local, surge un error, el sistema muestra un alerta con el código

de error respectivo y el mensaje de error, transacción realizada

correctamente, error al almacenar en dispositivo local, consulte con su

proveedor de servicios.

El web service devuelve un error diferente de estado correcto, el sistema

muestra la alerta con el código de error devuelto y el mensaje devuelto.

Error al recuperar parámetros, el sistema no puede recuperar los

parámetros de conexión, el sistema muestra un alerta con el código de

error 120000 y el mensaje error al recuperar parámetros de conexión.

Figura 3. 2: prototipo de pantalla de depósito

44

III.4 REVISION DE REQUISITOS

class ModeloOminio

Operaciones

Cooperativ a

Dispositiv o

CuentaSocio

SocioDatosPersonales

WebServ ice

Pais Departamento

Distrito

Prov incia


Empresa

CuentaCredito

CuentaSocio

usuario

Administrador

labora

haceuso

pertenece

realiza

efectua

Figura 3. 5 modelo de dominio actualizado


Descripción:


Curso básico:

En la lista de menú ahorro, el usuario pulsa sobre la opción de depósito, el

sistema recupera los datos de Socio que está en sesión y la Cuenta Socio

que está activa, a continuación el sistema muestra el formulario de

depósito en el midlet con los datos de nombre de usuario, cuenta de socio,

respectivamente llenados, el usuario ingresa la cantidad a depositar y hace

clic sobre procesar, el sistema muestra un alerta de verificación si está

conforme con la transacción o no, el usuario pulsa sobre procesar, el

sistema muestra al usuario la pantalla de espera, el sistema verifica la

cantidad de depósito, recupera los parámetros de conexión desde

parámetros, el sistema cifra los datos de número de cuenta y numero de

documento del socio, luego se conecta con el web service y envía los

45

datos del depósito, el valor de la operación, como son el valor del depósito,

la cuenta del socio, el número de identificación del socio, el nombre de

usuario que está en sesión, el numero de bluetooth para la seguridad, y

envía al web services estos datos; el sistema recibe la respuesta del web

service, parsea el mensaje recibido y obtiene el error y los datos del

depósito, verifica el error devuelto por el web service y si el error es

considerado como correcto, el sistema guarda los datos cuanta socio,

numero documento del socio, el valor de la transacción, el usuario en

sesión, el numero de referencia, el numero de secuencia de impresión , la

fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra

una alerta de transacción realizada correctamente, y si desea imprimir la

transacción.

Curso alterno:




una alerta con el código y descripción del error.











muestra la alerta con el código de error devuelto y el mensaje devuelto.


parámetros de conexión, el sistema muestra un alerta con el código de

error 120000 y el mensaje error al recuperar parámetros de conexión.

46

III.5 ANALISIS DE ROBUSTEZ

CU6: Deposito

sd Depósito cuenta de ahorros

CU6: depósito en cuenta de ahorrosDescripción:El socio realiza un depósito en su cuenta de ahorrosCurso básico:En la lista de menú ahorro, el usuario pulsasobre la opción de depósito, el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio que está activa, a continuación el sistema muestra el formulario de depósito en el midlet con los datos de nombre de usuario, cuenta de socio, respectivamente llenados, el usuario ingresa la cantidad a depositar y hace clic sobre procesar, el sistema muestra un alertade verificación si está conforme con la transacción o no, el usuario pulsa sobre procesar, el sistema muestra al usuario la pantalla de espera, el sistema verifica la cantidad de depósito, recupera los parámetros de conexión desde parámetros, el sistema cifra los datos de número de cuenta y numero de documento del socio, luego se conecta con el web serv ice y envía los datos del depósito, el valor de la operación, como son el valor del depósito, la cuenta del socio, el número de identificación del socio, el nombre de usuario que está en sesión, el numero de bluetooth para la seguridad, y envía al web services estos datos; el sistema recibe la respuesta del web serv ice, parsea el mensaje recibido y obtiene el error y los datos del depósito, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuanta socio, numero documento del socio, el valor de latransacción, el usuario en sesión, el numero de referencia, el numero de secuencia de impresión , la fecha y hora dedepósito en Operaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno: No hay respuesta del web service:

después de un tiempo de15 segundos el web service no responde, el sistema cierra la conexión y crea un Error el cual es devuelto a la interface, la interface valida el error y muestra una alerta con el código y descripción del error.

El web service devuelve los datos incompletos, el sistema crea un Error ylo devuelve a interface, en aquí muestra un alerta con el código y descripción del error.

La transacción se realizó de forma correcta pero no se almacenó en la base de datos local: el sistema al almacenar los datos en la base de datos local, surge un error, el sistema muestra un alerta con el código de error respectivo y el mensaje de error, transacción realizada correctamente, error al almacenar en dispositivo local, consulte con su proveedor de servicios.

El web service devuelve un error diferente de estado correcto, el sistema muestra la alerta con el código de error devuelto y el mensaje devuelto.

Error al recuperar parámetros, el sistema no puede recuperar los parámetros de conexión, el sistema muestra un alerta con el código de error 120000 y el mensaje error al recuperar parámetros de conexión.

Usuario

(from Actors)midlet Knet

muestra lista deopciones de menu de

ahorros

muestra formulario dedepósito en midlet

recupera los datos deusuario como el

nombre de usuario

usuario

recupera los datos desocio, nombre y

apellidosocio

recupera datos decuenta de ahorro como

el numero de cuentatipo moneda

cuentaAhorro

muestra alerta deverificacion de

transacción en midlet,con mensaje desea

realizar la trnasacción?recupera parámetros

de conexión

conecta con webservice

envia los datos deldepósito como

identificación delsocio, identificaciondel usuario, numero

cuenta, valor dedepósito, numero

bluetooth

muestra la pantalla deespera de transacción

de depósito

espera respuesta delweb service

la respuesta fueexitosa?

parsea respuesta yobtiene el error

Errores

surgió algun error en latransacción?

guarda datos dedepósito

Operacion AH

guardado correcto'

muestra mensaje deeror en la transacci{on

muestra alerta de errorcon mensaje de error

al guardado

muestra alerta detransacción realizada

correctamente

muestra alerta de errorcon mensaje error en

comunicación

muestra alerta de errorcon mensaje tiempode espera agotado

recuperado losparámetros

correctamente?

muestra alaerta deerror conmensaje de

error al recuperarparámetros

Parametros

WebServiceespera agotada

opcion seleccionada es si

ingresa el valor dedepósito y pulsa enprocesar

clic en depósito

sino

no

no

sino

si

si

Figura 3. 6: Diagrama de robustez de caso de uso depósito

47

class bean

CuentaAhorro

+ moneda: String+ numDoc: String+ numeroCuenta: String+ producto: String+ saldo: String

CuentaCredito

+ cuotasAtraso: String+ diasAtraso: String+ moneda: String+ montoCUota: String+ nombreProducto: String+ numCuotasCred: String+ numDoc: String+ numeroCuenta: String+ numeroCuota: String+ saldoDeuda: String+ totalCred: String

DatosFinancierosSocio

- alimentacion: String- comisiones: String- deudas: int

Departamento

+ idDepartamento: String+ nombreDepartamento: String

Distrito

+ codDepartamento: String+ codDistrito: String+ codProvincia: String+ nombreDistrito: String

Empresa

+ codEmpresa: String+ nombreEmpresa: String

Errores

+ descError: String+ idError: String

OperacionAh

+ cuentaSocio: String+ error: String+ fechaMov: String+ moneda: String+ monto: String+ nombreSocio: String+ noSocio: String+ numMov: String+ operador: String+ saldo: String+ secImpresion: String+ tipoProceso: String

Parametro

+ direc: String+ ipCoope: String+ nomCoop: String+ telef: String

Prov incia

+ codDepartamento: String+ codProvincia: String+ nombreProvincia: String

Socio

+ apelidoMat: String+ apell idoPat: String+ ciuced: String+ codCiiu: String+ codDiv: String+ codSegmento: String+ correoElec: String+ departamento: String+ depNace: String+ direccionResidencia: String+ distNace: String+ distrito: String+ dniFecha: String+ empresaLabora: String+ envioCorrespondencia: String+ estadoCivil: String+ estrato: String+ fechaIngreso: String+ fechaModif: String+ fecNacimiento: String+ isRegistro: String+ nacionalidad: String+ nivelEducacion: String+ noCelular: String+ nombre: String+ noTelefono: String+ numDoc: String+ pais: String+ paisNace: String+ perCargoAdu: String+ perCargoMen: String+ perDeduccion: String+ profesion: String+ propiedadVivienda: String+ provincia: String+ provNace: String+ salario: String+ sexo: String+ tipoContrato: String+ tipoDoc: String+ tipoVivienda: String

Transferencias

Usuario

+ nombreUsuario: String+ numBlue: String+ pasUsuario: String

cuenta

- numeroCuenta: String

OperacionesCredito

- Fecha: String- moneda: String- montoPagado: string- numCuota: String- numRef: String

realiza

1

se_realiza_con

0..*

1

posee

1

1

realiza

0..*

0..*

tiene

1

0

tiene

0..1

0..1

pertenece

0..*

1

ubica

0..*

1

ubica

0..*

1

ubica

0

realiza

1

realiza0..*

1 recibe0..*

realiza

realiza

Figura 3. 7: Modelo de dominio actualizado

48

III.6 REVISION PRELIMINAR DE DISEÑO

Caso de uso rectificado:


Descripción:


Curso básico:

En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de

depósito; el sistema recupera los datos de Socio que está en sesión y la

Cuenta Socio que está activa, y muestra la pantalla de depósito con los

datos: nombre de usuario, cuenta de socio, número de identificación de

socio, respectivamente llenados.

El usuario ingresa la cantidad a retirar y hace clic sobre procesar; el sistema

muestra un alerta de verificación si está conforme con la transacción o no,

el usuario pulsa sobre si, el sistema muestra al usuario la pantalla de

espera; el sistema verifica la cantidad de retiro, recupera los parámetros de

conexión de parámetros, el sistema cifra los datos de número de cuenta y

número de documento del socio, luego se conecta con el web service y

envía los datos de depósito: cuenta de socio, número de identificación de

socio, nombre de usuario, valor de retiro, el numero de bluetooth, y los

envía al web services.

El sistema espera la respuesta del web service por un tiempo prudencial.

El sistema recibe la respuesta del web service, parsea el mensaje recibido y

obtiene el error y los datos del retiro, verifica el error devuelto por el web

service y si el error es considerado como correcto, el sistema guarda los

datos cuenta socio, numero documento del socio, el valor de la transacción,

el usuario en sesión, el numero de referencia, el numero de secuencia de

impresión , la fecha y hora de depósito en Operaciones Ahorro, y el sistema

muestra una alerta de transacción realizada correctamente, y si desea

imprimir la transacción.

Curso alterno:


parámetros de conexión, el sistema muestra un alerta de error con el

mensaje error al recuperar parámetros.



49


una alerta con el mensaje tiempo de espera agotado.

El web service devuelve los datos incompletos, el sistema muestra un

alerta de error con mensaje de datos incompletos.







50

Diagrama de robustez revisado


Descripción:El socio realiza un depósito en su cuenta de ahorrosCurso básico:En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de depósito; el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio que está activa, y muestra la pantalla de depósito con los datos: nombre de usuario, cuenta de socio, número de identificación de socio, respectivamente llenados.El usuario ingresa la cantidad a retirar y hace clic sobre procesar; el sistema muestra un alerta de verificación si está conforme con la transacción o no, el usuario pulsa sobre si, el sistema muestra al usuario la pantalla de espera; el sistema verifica la cantidad de retiro, recupera los parámetros de conexión de parámetros, el sistema cifra los datos de número de cuenta y número de documento del socio, luego se conecta con el web service y envía los datos de depósito: cuenta de socio, número de identificación de socio, nombre de usuario, valor de retiro, el numero de bluetooth, y los envía al web services.El sistema espera la respuesta del web service por un tiempo prudencial.El sistema recibe la respuesta del web service, parsea el mensaje recibido y obtiene el error y los datos del retiro, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuenta socio, numero documento del socio, el valor de la transacción, el usuario en sesión, el numerode referencia, el numero de secuencia de impresión , la fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno:

Error al recuperar parámetros, el sistema no puede recuperar los parámetros de conexión, el sistemamuestra un alerta de error con el mensaje error al recuperar parámetros.

No hay respuesta del web service: después de un tiempo de15 segundos el web service no responde, el sistema cierra la conexión y crea un Error el cual es devuelto a la interface, la interface valida el error y muestra una alerta con el mensaje tiempo de espera agotado.

El web service devuelve los datos incompletos, el sistema muestra un alerta de error con mensaje de datos incompletos.

La transacción se realizó de forma correcta pero no se almacenó en labase de datos local: el sistema al almacenar los datos en la base de datos local, surge un error, el sistema muestra un alerta con el código de error respectivo y el mensaje de error, transacción realizada correctamente, error al almacenar en dispositivo local, consulte con su proveedor de servicios.

Usuario

(from Actors)

pantalla de depósito


ahorros

muestra pantalla dedepósito


nombre de usuario

usuario


apellido

socio



cuentaAhorro



realizar la trnasacción? recupera parámetrosde conexión




bluetooth


de depósito




Errores



Operacion AH

guardado correcto'



al guardado


correctamente


comunicación



correctamente?muestra alaerta de

error conmensaje deerror al recuperar

parámetros

Parametros

WebService

Pantalla de menúahorro

Pantalla de espera dedepósito

cifra datos

si

no

sino

no

esperaagotada

clic en no

opcion seleccionada essi

si


clic en depósito

sino

Figura 3. 8: Diagrama de robustez revisado de caso de uso depósito

51

III.7 ARQUITECTURA TECNICA

Topología de sistema

Figura 3. 9: Topología de sistema móvil

52

Diagrama de componentes

cmp Diagrma de componentes

Vistas

Midlet

Controladores

Controladores de operaciones

Modelo

DAO Beans

WebServ ice

Figura 3. 10; Diagrama de componentes de sistema movil

53

Diagrama de despliegue

deployment Diagrama de despliegue

Capa de presentación

Midlet

Logica

Controladores

Componentes de acceso a datos

Base de datos

Base de datos

Figura 3. 11:Diagrama de despliegue de sistema móvil

54

III.8 DIAGRAMAS DE SECUENCIA

CU6: depósito


Usuario

(from Actors)

pantalla dedepósito

Operacion AH Parametros cuentaAhorro socio usuarioPantalla de menúahorro

Pantalla deespera dedepósito

WebServ ice

Descripción:El socio realiza un depósito en su cuenta de ahorrosCurso básico:En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de depósito; el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio que está activa, y muestra la pantalla de depósito con los datos: nombre de usuario, cuenta de socio, número de identificación de socio, respectivamente llenados.El usuario ingresa la cantidad a retirar y hace clic sobre procesar; el sistema muestra un alerta de verificación si está conforme con la transacción o no, el usuario pulsa sobre si, el sistema muestra al usuario la pantalla de espera; el sistema verifica la cantidad de retiro, recupera los parámetros de conexión de parámetros, el sistema cifra los datos de número de cuenta y número de documento del socio, luego se conecta con el web service y envía los datos de depósito: cuenta de socio, número de identificación de socio, nombre de usuario, valor de retiro, el numero de bluetooth, y los envía al web services.El sistema espera la respuesta del web service por un tiempoprudencial.El sistema recibe la respuesta del web service, parsea el mensaje recibido y obtiene el error y los datos del retiro, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuenta socio, numero documento del socio, el valor de la transacción, el usuario en sesión, el numero de referencia, el numero de secuencia de impresión , la fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno:

Error al recuperar parámetros, el sistema no puede recuperar los parámetros de conexión, el sistema muestra un alerta de error con el mensaje error al recuperar parámetros.




clic endepósito()

getPantallaDeposito()

get NombreUsuario():String

getNumDOc()

getNombre()

getNumCuenta():String

display()

ingresa monto deposito clic enprocesar()

getWaitScreenProcesandoDeposit()

display()movimiento(String usua, String bluetooth, String noIdentificacion, String cuenta, Stringmoneda, String producto, String montoEfectivo, String nombreSocio, String tipoProceso) :Errores

recuperaParametro()

operaciones( String bluetooth, String tipoProceso, String noIdentificacion, cuenta,String montoEfectivo, String usua, String moneda):String

parseaRetorno(String retorno):Void

traverseOperacion(Stringretorno)

newOperacion(String numMov, String tipoProceso, String noSocio,):boolean

comprobarTransaccion()

getAlertOk()

getAlertErrores()

display()

Figura 3. 12: diagrama de secuencia de caso de uso depósito

55


Usuario

(from Actors)


Errores Operacion AH Parametros cuentaAhorro socio usuarioPantalla de menúahorro


COperacionesParametrosDAOWebServ ice

OperacionesDAO Encripta

Descripción:El socio realiza un depósito en su cuenta de ahorrosCurso básico:En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de depósito;el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio que está activa, y muestra la pantalla de depósito con los datos: nombre de usuario, cuenta de socio, número de identificación de socio, respectivamente llenados.El usuario ingresa la cantidad a retirar y hace clic sobre procesar; el sistema muestra un alerta de verificación si está conforme con la transacción o no, el usuario pulsa sobre si, el sistema muestra al usuario la pantalla de espera; el sistema verifica la cantidad de retiro, recupera los parámetros de conexión de parámetros, el sistema cifra los datos de número de cuenta y número de documento del socio, luego se conecta con el web service y envía los datos de depósito: cuenta de socio, número de identificación de socio, nombre de usuario, valor de retiro, el numero de bluetooth, y los envía al web services.El sistema espera la respuesta del web service por un tiempo prudencial.El sistema recibe la respuesta del web service, parsea el mensaje recibido y obtiene el error y los datos del retiro, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuenta socio, numero documento del socio, el valor de la transacción, el usuario en sesión, el numero de referencia, el numero de secuencia de impresión , la fecha y hora de depósito enOperaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno:


No hay respuesta del web service:después de un tiempo de15 segundos el web service no responde, el sistema cierra la conexión y crea un Error el cual es devuelto a la interface, la interface valida el error y muestra una alerta con el mensaje tiempo de espera agotado.



clic endepósito()



getNumDOc()

getNombre()


display()



display()

movimiento(String usua, String bluetooth, StringnoIdentificacion, String cuenta, String moneda,String producto, String montoEfectivo, StringnombreSocio, String tipoProceso) :Errores new

ParametrosDao()

getParametro(String codParametro):Parametro

encriptaDatos():String



traverseOperacion(Stringretorno)new OperacionesDAO()



getAlertOk()

Error al recuperar parametros de conexion():Errores

Error no hay respuesta del wweb Service():Errores

error al obtener parametrosde conexion():Errores

No se guardó la transaccion():Errores

Error devuelto por el web service():Errores

getAlertErrores()

display()

56

class bean

Socio

+ apelidoMat: String+ apellidoPat: String+ correoElec: String+ depNace: String+ direccionResidencia: String+ distNace: String+ dniFecha: String+ envioCorrespondencia: String+ estadoCivil: String+ estrato: String+ fechaIngreso: String+ fechaModif: String+ fecNacimiento: String+ nacionalidad: String+ nivelEducacion: String+ noCelular: String+ nombre: String+ noTelefono: String+ numDoc: String+ perCargoAdu: String+ perCargoMen: String+ perDeduccion: String+ profesion: String+ propiedadVivienda: String+ provNace: String+ salario: String+ sexo: String+ tipoContrato: String+ tipoDoc: String+ tipoVivienda: String

+ buscarSocio() : Socio+ newSocio(String, String, String, String, String, String) : void

CuentaAhorro


+ newCuentaAhorro(String, String, String, String, String) : void

Cuenta

- nombreCuenta: String- numerpoCuenta: String

Controladores::COperacion

~ erro: Error = new Errores()~ opera: OperacionesDAO = new OperacionesDAO()~ operaAH: OperacionAh = new OperacionAh()

+ movimiento(String, String, String, String, String, String, String, String, String) : Error+ parseaOperacion(String) : void+ traverseOperacion(XmlParser, String) : void

serv iceknetserv ice::serv iceknetServ ice_Stub

+ buscaCuentDest(String, String, String, String, int) : String+ buscarClientes(String, String, String) : String+ busquedaCuentas(String, String, String, int) : String+ login(String, String, String) : String+ operaciones(String, String, String, String, String, String, String) : String+ preAprobacionCred(String, String, String, String, String, String, String, String, String, String, String, String) : String+ transferencia(String, String, String, String, String, String, String, String) : String+ verificarComunicacion(String) : String

DAO::OperacionesDAO

+ CreateTblMovimientos() : J2METable+ getOperacion(String) : OperacionAh+ getOpers() : Vector+ newOperacion(String, String, String, String, String, String, String, String, String, String) : boolean+ OperacionesDAO()

DAO::ParametrosDAO

+ createTblParametro() : J2METable+ dropParametro() : void+ getContact(String) : String+ getParametros() : Vector+ newParametro(String, String, String) : boolean

DAO::SocioDAO

+ CreateTableSocio() : J2METable+ deleteSocio(String) : boolean+ getSocios() : Vector+ NewSocio(String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String) : boolean+ SocioDAO()+ uptadeSocio(String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String) : boolean

v ista::Midlet

+ getFormDeposito() : void

0..*

tiene

1~opera

Figura 3. 13: Modelo de clases de bajo nivel para caso de uso retiro

57

class modelo

CuentaAhorro



CuentaCredito


+ newCuentaCredito(String, String, String, String, String) : void

DatoFinancieroSocio

+ alimentacion: String+ comisiones: String+ deudas: String+ gastoArriendo: String+ honorarios: String+ ingArriendo: String+ otrosGastos: String+ otrosIngresos: String+ pensiones: String+ salud: String+ servicios: String+ util idadNegocio: String

+ newDatoFinanciero(String, Stirng, String, String, String) : void

Departamento


+ getCodigoDepartamendo() : String

Distrito


+ getCodDistrito() : String

Empresa

+ codEmpresa: String- codigoDivision: String- codigoSegmento: String+ nombreEmpresa: String

+ getCodEmpresa() : String

OperacionAh


+ movimiento(String, String, String, String, String, String, String, String, String) : Error+ newOperacion(String, String, String) : boolean+ parseaRetorno(String) : void+ traverseOperacion(String) : void

Error


+ getidError() : String

Prov incia


+ getCodDepartamento() : String

Transferencia

+ cueDest: String+ cueOrig: String+ descErroe: String+ erroe: String+ fecha: String+ idDest: String+ idOrg: String+ moneda: String+ monto: String+ nomDes: String+ nomOri: String+ numRef: String+ operador: String+ secImpre: String

+ newTransferencia(String, String, String, String, String, String, String, String) : void

Socio



Usuario


+ get NombreUsuario() : String+ getNombre() : String+ getNumCuenta() : String+ getNumDOc() : void

Cuenta


Ubigeo

- CodigoDepartamento: String- CodigoDistrito: String- CodigoProvincia: String- codigoUbigeo: String

+ getCodigoUbigeo() : String

0

tiene

0..1

2

se realiza encuenta

0..*

1

posee

11

ubica

0..*

1

ubica

0..*

1

se_realiza_con

0..*

0..1

pertenece

0..*naceen

1

ubica

0

1

realiza0..*

2

transfiere

0..*

1realiza

0..*

1realiza

0..*

0..*

tiene

1

Figura 3. 14: Diagrama de clases actualizado

58

III.9 REVISION CRITICA DEL DISEÑO

Caso de uso rectificado:


Descripción:


Curso básico:


depósito, el sistema recupera los datos de Socio que está en sesión y la

Cuenta Socio que está activa, a continuación el sistema muestra la pantalla

de depósito con los datos: nombre de usuario, cuenta de socio, número de

identificación de socio, respectivamente llenados, el usuario ingresa la

cantidad a retirar y hace clic sobre procesar, el sistema muestra un alerta

de verificación si está conforme con la transacción o no, el usuario pulsa

sobre si, el sistema muestra al usuario la pantalla de espera, el sistema

verifica la cantidad de retiro, recupera los parámetros de conexión de

parámetros, el sistema cifra los datos de número de cuenta y número de

documento del socio, luego se conecta con el web service y envía los datos

de depósito: cuenta de socio, número de identificación de socio, nombre de

usuario, valor de retiro, el numero de bluetooth, y los envía al web services;

el sistema espera la respuesta; el sistema recibe la respuesta del web

service, parsea el mensaje recibido y obtiene el error y los datos del retiro,

verifica el error devuelto por el web service y si el error es considerado

como correcto, el sistema guarda los datos cuenta socio, numero

documento del socio, el valor de la transacción, el usuario en sesión, el

numero de referencia, el numero de secuencia de impresión , la fecha y

hora de depósito en Operaciones Ahorro, y el sistema muestra una alerta de

transacción realizada correctamente, y si desea imprimir la transacción.

Curso alterno:








59









60


CU6: depósito en cuenta de ahorrosDescripción:El socio realiza un depósito en su cuenta de ahorrosCurso básico:En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de depósito, el sistema recupera los datos de Socio que esta en sesión y la Cuenta Socio que está activa, a continuación el sistema muestra lapantalla de depósito con los datos: nombre de usuario, cuenta de socio, número de identificación de socio, respectivamente l lenados, el usuario ingresa la cantidad a retirar y hace clic sobre procesar, el sistema muestra un alerta de verificación si está conforme con la transacción o no, el usuario pulsa sobre si, el sistema muestra al usuario la pantalla de espera, el sistema verifica la cantidad de retiro, recupera los parámetros de conexión de parámetros, el sistema cifra los datos de número de cuentay número de documento del socio, luego seconecta con el web service y envía los datos de depósito: cuenta de socio, numero de identificación de socio, nombre de usuario, valor de retiro, el numero de bluetooth, y los envía al web services; el sistema espera la respuesta; el sistema recibe la respuesta del web service, parsea el mensaje recibido y obtiene el error y los datos del retiro, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuenta socio, numero documento del socio, el valor de la transacción, el usuario en sesión, el numerode referencia, el numero de secuencia de impresión , la fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno: Error al recuperar parámetros, el

sistema no puede recuperar los parámetros de conexión, el sistema muestra un alerta de error con el mensaje error al recuperar parámetros.



La transacción se realizó de forma correcta pero no se almacenó en la base de datos local: el sistema al almacenar los datos en la base de datos local, surge un error, el sistema muestra un alerta con el código de error respectivo y el mensaje de error, transacción realizada correctamente, error al almacenar en dispositivo local,consulte con su proveedor de servicios.

Usuario

(from Actors)



ahorros



nombre de usuario

usuario


apell ido

socio



cuentaAhorro







bluetooth


de depósito




Errores



Operacion AH

guardado correcto'



al guardado


correctamente


comunicación





parámetros

Parametros

WebService



cifra datos

espera agotada

opcion seleccionada es si


clic en depósito

clic en no

si

sino

no

no

sino

si

Figura 3. 15; Diagrama de robustez de caso de uso depósito revisado

61


Usuario

(from Actors)











clic endepósito()



getNumDOc()

getNombre()


display()



display()


ParametrosDao()








getAlertOk()






getAlertErrores()

display()

Figura 3. 16: Diagrama de secuencia de caso de uso depósito revisado

62

class bean

Socio



CuentaAhorro



Cuenta







DAO::OperacionesDAO


DAO::ParametrosDAO


DAO::SocioDAO


v ista::Midlet


0..*

tiene

1~opera

Figura 3. 17: Diagrama de clases de bajo nivel para caso de uso depósito

63

class modelo

CuentaAhorro



CuentaCredito



DatoFinancieroSocio

+ alimentacion: String+ comisiones: String+ deudas: String+ gastoArriendo: String+ honorarios: String+ ingArriendo: String+ otrosGastos: String+ otrosIngresos: String+ pensiones: String+ salud: String+ servicios: String+ uti l idadNegocio: String


Departamento



Distrito



Empresa



OperacionAh



Error



Prov incia



Transferencia



Socio

+ apelidoMat: String+ apell idoPat: String+ correoElec: String+ depNace: String+ direccionResidencia: String+ distNace: String+ dniFecha: String+ envioCorrespondencia: String+ estadoCivil: String+ estrato: String+ fechaIngreso: String+ fechaModif: String+ fecNacimiento: String+ nacionalidad: String+ nivelEducacion: String+ noCelular: String+ nombre: String+ noTelefono: String+ numDoc: String+ perCargoAdu: String+ perCargoMen: String+ perDeduccion: String+ profesion: String+ propiedadVivienda: String+ provNace: String+ salario: String+ sexo: String+ tipoContrato: String+ tipoDoc: String+ tipoVivienda: String


Usuario



Cuenta


Ubigeo



0

tiene

0..1

2

se realiza encuenta

0..*

1

posee

11

ubica

0..*

1

ubica

0..*

1

se_realiza_con

0..*

0..1

pertenece

0..*naceen

1

ubica

0

1

realiza0..*

2

transfiere

0..*

1realiza

0..*

1realiza

0..*

0..*

tiene

1

Figura 3. 18; Diagrama de clases

64

RECOMENDACIONES

a. Se recomienda emplear la metodología ICONIX para el desarrollo de

sistemas móviles.

b. Se recomienda hacer uso de lenguaje orientado a objetos en la

programación para la fácil reutilización de los componentes del

mismo.

c. Se recomienda a las cooperativas que adquieran el sistema de banca

móvil realizar un análisis de costo para la adquisición de equipos y

planes de datos para estos; de acuerdo a la cantidad de

transacciones proyectadas.

65

BIBLIOGRAFIA

1. ALVARADO RIVAS, Mauricio; ALVARADO RIVERA, René y VARELA

PERLA, Haydé (2005). Sistema de inventario a través de internet y

dispositivo móvil. Proyecto de graduación para optar el grado de

ingeniero en ciencias de la computación. Universidad don Bosco. El

Salvador.

2. CARABALLO MAESTRA, Rodrigo. “Ingeniería de software, Introducción

a J2ME”. Disponible en

http://caraballomaestre.blogspot.com/2009/05/introduccion-

j2me.html, visitado el 24 de setiembre del 2011.

3. DAMIAN MARROQUIN, Félix (2006). Programación de dispositivos

móviles. Trabajo de graduación de Ingeniero de ciencias y sistemas.

Universidad De San Carlos de Guatemala. Guatemala

4. FROUTE QUINTAS, Agustín y JOREG CARDENES, Patricia. (2004) J2ME

Manual de usuario y tutorial. Alfa omega grupo editor. México.

5. GIMENO BRIEVA, Alberto (2004). JSR-82 Bluetooth desde java.

California - Estados Unidos de América.

6. MENDEZ CARVAJAL, Alejandro (2008). Prototipo de aplicación móvil

para consulta de información de novedades de un portafolio

financiero a través de un teléfono celular. Trabajo de grado para

optar el título de ingeniero de sistemas. Universidad del Bosque.

Bogotá – Colombia.

7. PRESSMAN, Roger (2002). Ingeniería de software, un enfoque

práctico.Editorial Mc Graw Hill. Quinta edición, Traducido de la

quinta edición en inglés de SOFTWARE ENGINEERING. A Practitioner’s

Approach. European Adaptation. Madrid – España.

8. ROSENBERG, Doud., STEPHENS, Matt. (2007). Use Case Driven Object

Modeling with UML: Theory and Practice. Editorial Springer. Estados

Unidos de América.

9. Wikipedia, 2011. Lenguaje de Modelado Unificado. Disponible en

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado.

Revisado el 24 de setiembre del 2011.

66

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

http://caraballomaestre.blogspot.com/2009/05/introduccion-j2me.html

http://caraballomaestre.blogspot.com/2009/05/introduccion-j2me.html

ANEXO 1PROCESO ICONIX

MODELO DE DOMINIO INICIAL

class ModeloOminio

Operaciones

Cooperativa

Dispositiv o

CuentaSocio

SocioDatosPersonales

WebServ ice

Pais Departamento

Distrito

Prov incia


Empresa

CuentaCredito

CuentaSocio

usuario

Administrador

labora

haceuso

pertenece

realiza

efectua

Figura 1: Modelo de dominio inicial

67

DIAGRAMAS DE CASOS DE USO POR PAQUETES

Paquetes de casos de uso

d. Empaquetado de casos de uso

uc Use Case Model

Administraciòn

+ Registrar parámetros

+ login

+ Reimprimir recibo

+ Traer catálogo ciiu, división, segmento

+ Traer catálogo ciudades

+ traer catálogo de Departamentos, provincias distritos

+ Traer catálogo de profesiones y empresas de trabajo

+ Verificar conexión

Operaciones

+ Cuenta ahorros

+ Cuenta crédito





Reportes

+ Reporte detallado de transacciones

+ Reporte total de transacciones

Cuenta ahorros






Cuenta crédito

+ Abono a préstamo



Figura 2: Diagrama de paquees de caso de uso

e. Paquete administración

uc Administracion

Reimprimir recibo Traer catálogo ciiu, div isión, segmento

Verificar conexión

login

traer catálogo de Departamentos,

prov incias distritos

Traer catálogo de profesiones y

empresas de trabajo

Usuario

(from Actors)

Operaciones

+ Cuenta ahorros

+ Cuenta crédito





(from Use Case Model)

Registrar parámetros

«precedes»

«precedes»

«invokes»

Figura 3: Diagrama de caso de uso del paquete administración

f. Paquete operaciones

68

uc Operaciones

Selección de cuenta crédito

Selección de cuenta ahorro

Transferencia de Ahorros

Usuario

(from Actors)

Cuenta ahorros






Cuenta crédito

+ Abono a préstamo



Seleccion de socio

«precedes»

«precedes»

«precedes»

«precedes»

«precedes»

Figura 4: Diagrama de casos de uso del paquete operaciones

g. Paquete cuentas de ahorro

uc Cuenta ahorros

Apertura de cuenta de ahorros

Depósito cuenta de ahorros

Retiro cuenta de ahorros

Impresión de v ouchers

Busqueda Cuenta de ahorros

Usuario

(from Actors) «precedes»

«precedes»«invokes»

«invokes»

Figura 5: Diagrama de casos de uso del paquete de cuenta de ahorro

h. Paquete cuentas crédito

69

uc Cuenta crédito

Consulta de crédito

Abono a préstamo

Pre aprobación de crédito

(from Cuenta ahorros)

Impresión de vouchers

Usuario

(from Actors)

«invokes»

«invokes»

Figura 6: Diagrama de casos de uso del paquete de cuentas de crédito

70

DESCRIPCION DE CASOS DE USO

Figura 7: Prototipo de interface, pantalla login

CU1: Login

Descripción:

El usuario inicia sesión para el uso del sistema

Curso básico:

El sistema muestra al usuario la pantalla de login.

El usuario ingresa su nombre de usuario y contraseña y pulsa en la opción

iniciar sesión, el sistema muestra la pantalla de espera de login.

El sistema valida si es correcto el ingreso de datos, luego valida si los datos

ingresados pertenecen al administrador, el sistema recupera los parámetros

de conexión como son la ip de conexión del web service, recupera la

dirección bluetooth, y se conecta con web services y envía el nombre de

usuario y la contraseña al web service.

El web service responde con un mensaje, el sistema parsea el mensaje y

obtiene el error; el sistema compara si el error es de operación correcta el

sistema parsea los datos del usuario como son el nombre de usuario,

apellidos, nombre de usuario, y los almacena en usuario; y el sistema

muestra la pantalla de búsqueda socio.

71

Curso Alterno:

No existen parámetros, el sistema recuperar los parámetros de conexión,

no encuentra ningún parámetro almacenado, el sistema muestra un

alerta con el mensaje de no existen parámetros.

El tiempo de espera agotado: el sistema al enviar los datos respectivos al

web service, demora en la obtener respuesta, el sistema muestra un

alerta con el mensaje tiempo de espera agotado.

El error obtenido del web service es operación incorrecta, el sistema

muestra el mensaje con el mensaje obtenido del error.

El nombre de usuario y contraseña pertenecen al administrador de

equipo, el sistema muestra la pantalla de registro de parámetros.

CU2: Registrar parámetros

Descripción:

El Usuario registra los parámetros para el funcionamiento del sistema móvil

Curso básico:

El sistema muestra la pantalla de registro de parámetros, y el usuario

ingresa la ip del web service, el nombre de la cooperativa, el código de la

cooperativa, dirección de la cooperativa, teléfono de la cooperativa, y

presiona en registrar parámetros.

El sistema verifica los datos ingresados, el sistema limpia la tabla de

parámetros de la base de datos y los almacena en la base de datos del

equipo.

El sistema devuelve un código de error el sistema verifica el código de error

y muestra la alerta con el mensaje de parámetros ingresados

correctamente, el usuario presiona sobre ok y el sistema muestra la pantalla

de login del sistema.

Curso alterno:

72

Parámetros incorrectos: el usuario no ingresó los 5 parámetros o ingresó

incorrectamente los parámetros, el sistema muestra una alerta de error

con el mensaje “datos ingresados incorrectos”.

Error al guardar los parámetros en la base de datos: el sistema el

intentar guardar los parámetros no obtiene respuesta o surge un error al

guardar en base de datos, el sistema muestra un alerta con el mensaje

"error al registrar parámetros"

CU3: Selección de socio

Descripción:

El Usuario realiza una búsqueda del socio, y selecciona de la lista

encontrada a uno para realizar operaciones con el socio.

Curso Básico:

En la pantalla búsqueda de socio, el usuario ingresa el DNI del socio y

selecciona la opción búsqueda por DNI, y pulsa en la opción buscar, el

sistema muestra la pantalla de espera de búsqueda socio.

El sistema verifica los datos, recupera los parámetros de conexión como son

ip del web service de parámetros, inicializa el web service con los

parámetros y envía los datos de numero bluetooth, el DNI del cliente, el id

del usuario y los envía al web service.

El sistema espera la respuesta del web service.

El web service responde la petición con un mensaje, el sistema parsea la

cadena devuelta y almacena los datos llegados en Socio y Errores, el

sistema verifica el error devuelto por el web service, si está correcto la

devolución el sistema guarda los datos en socio en la base de datos local

del sistema, verifica el error al guardar en base de datos y muestra en la

pantalla la lista de socios, con el DNI del socio, nombres y apellidos del

socio.

El usuario hace clic sobre uno de los socios encontrados, el sistema guarda

en sesión los datos del socio como el número documento, nombre y

apellidos y muestra la pantalla de menú operaciones.

Curso alterno:

73

Tiempo de espera agotado: después de un tiempo de 10 segundos el

web service no responde, el muestra un alerta de error con el mensaje,

tiempo de espera agotado.

El web service devuelve error: el sistema muestra un alerta con el

mensaje de error devuelto por el web service.

Error al guardar datos de socio en base de datos: el sistema muestra un

alerta de error con el mensaje error al guardar datos de socio en

dispositivo local.

Figura 8: Pantalla de búsqueda socio

Figura 9: Pantalla de selección socio

Figura 10: Pantalla de menú operaciones

74

CU4: Selección de cuenta de ahorros

Descripción:

El usuario realiza una búsqueda de cuentas de ahorro del socio antes

seleccionado, y elige una cuenta para realizar las operaciones financieras en

la cuenta

Curso básico:

El usuario en la pantalla de menú operaciones, hace clic sobre la opción de

ahorro, el sistema muestra la pantalla de espera de búsqueda cuenta.

El sistema recupera la ip de conexión de parámetros, recupera los datos del

socio como el número de identificación, recupera los datos del usuario en

sesión, recupera la dirección bluetooth del dispositivo, y a continuación se

conecta con el web service y envía el código de usuario, la dirección

bluetooth, el número y tipo de identificación del socio al web service.

El sistema espera la respuesta del web service.

El web service responde con un mensaje, el sistema parsea el mensaje y

obtiene el código error de operación y el mensaje de error, si el error de

operación es de operación correcta, el sistema parsea el mensaje y obtiene

los datos de las cuentas ahorro del socio, como son el número de cuenta, la

moneda de la cuenta, nombre producto de la cuenta y retorna el error y la

lista de cuentas; el sistema comprueba que la lista de cuentas sea como

mínimo uno, el sistema muestra en la pantalla de cuentas de socio.

El usuario hace clic sobre una de las cuentas visualizadas, el sistema guarda

los datos de la cuenta seleccionada en sesión y muestra la lista de menú de

opciones de cuenta de ahorro.

Curso alterno:

Error al obtener los parámetros de conexión: el sistema no puede

obtener los parámetros de conexión, muestra un alerta con el mensaje

de “error al recuperar parámetros de conexión”.

No hay respuesta del web service: después de un tiempo de 10

segundos el web service no responde, el sistema cierra la conexión y

muestra un alerta con el mensaje de error de tiempo de espera agotado.

75




El socio no posee cuentas: el sistema muestra un alerta de error con el

mensaje de socio no posee cuentas de ahorro.

Figura 11: Pantalla de selección de cuenta ahorro

Figura 12; Pantalla de menú operaciones cuenta ahorro

CU5: Retiro

Descripción:

El socio realiza un retiro de su cuenta de ahorros

Curso básico:

En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de retiro,

el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio

que está activa, y muestra la pantalla de retiro con los datos: nombre de

usuario, cuenta de socio, número de identificación de socio,

respectivamente llenados.



76

el usuario pulsa en la opción si, el sistema muestra al usuario la pantalla de

espera, el sistema verifica la cantidad de retiro, recupera los parámetros de


número de documento del socio.

El sistema se conecta con el web service y envía los datos de retiro: cuenta

de socio, número de identificación de socio, nombre de usuario, valor de

retiro, el número de bluetooth; el sistema espera la respuesta.









Curso alterno:

















muestra la alerta de error con el código de error devuelto y el mensaje

devuelto.

77

Figura 13: Pantalla de retiro


Descripción:


Curso básico:


depósito; el sistema recupera los datos de Socio que está en sesión y la

Cuenta Socio que está activa, y muestra la pantalla de depósito con los

datos: nombre de usuario, cuenta de socio, número de identificación de

socio, respectivamente llenados.



el usuario pulsa sobre si, el sistema muestra al usuario la pantalla de

espera; el sistema verifica la cantidad de retiro, recupera los parámetros de


número de documento del socio, luego se conecta con el web service y

envía los datos de depósito: cuenta de socio, número de identificación de

socio, nombre de usuario, valor de retiro, el numero de bluetooth, y los

envía al web services.

El sistema espera la respuesta del web service por un tiempo prudencial.





78





Curso alterno:
















79

Figura 14: Pantalla de depósito

80

DIAGRAMAS DE ROBUSTEZ

CU1: Caso de uso login sd login

Descripción:El usuario inicia sesión para el uso del sistema

Curso básico:El sistema muestra al usuario la pantalla de login.El usuario ingresa su nombre de usuario y contraseña y pulsa en la opción iniciar sesión, el sistema muestra la pantalla de espera de login.El sistema valida si es correcto el ingreso de datos, luego valida si los datos ingresados pertenecen al administrador, el sistema recupera los parámetros de conexión como son la ip de conexión del web service, recupera la dirección bluetooth, y se conecta con web services y envía el nombre de usuario y la contraseña al web service.El web service responde con un mensaje, el sistema parsea el mensaje y obtiene el error; el sistema compara si el error es de operación correcta el sistema parsea los datos del usuario como son el nombre de usuario, apellidos, nombre de usuario, y los almacena en usuario; y el sistema muestra la pantalla de búsqueda socio.

Curso Alterno:

No existen parámetros, el sistema recuperar los parámetros de conexión, no encuentra ningún parámetro almacenado, el sistema muestra un alerta con el mensaje de no existen parámetros.

El tiempo de espera agotado: el sistema al enviar los datos respectivos al web service, demora en la obtener respuesta, el sistema muestra un alerta con el mensaje tiempo de espera agotado.

El error obtenido del web service es operación incorrecta, el sistema muestra el mensaje con el mensaje obtenido del error.

El nombre de usuario y contraseña pertenecen al administrador de equipo, el sistema muestra la pantalla de registro de parámetros.

visualiza pantalla deinicio sesion

datos ingresadoscorrectamente?

almacena datos enusuario

Usuario

Datos ingresadospertenecen aadministrador?

Registrar parámetros

Usuario

muestra alerta conmensaje de Ingrese

nuevamente sus datos

recupera parametrosde conexion

muestra pantalla deespera

Parametros

pantalla de espera deinicio sesion

encripta id ycontraseña

obtiene direccionbluetooth

Web service

conecta y envianombre de usuario,

contraseña encriptadosy direccion bluetooth

Parsea el mensaje yobtiene el error

Error

Error de operacioncorrecta?

muestra alerta conmensajede error

obtenido del webservice

parsea datos deusuario como el

nombre, apellido,nombre de usuario yalmacena en usuario

Usuario

visializa pantalla debusqueda socio

tiempo de esperaagotado?

muestra alerta conmensaje de tiempo de

espera agotado

pantalla busquedasocio

Pantalla de iniciosesion

no

ingresa usuario y contraseña

si

no

si

no

si

si

no

Figura 15: Diagrama de robustez de caso de uso login

81

CU2: Registro de parámetros

sd Registrar parámetros

Descripción:El Usuario registra los parámetros para el funcionamiento del sistemamóvil

Curso básico:El sistema muestra la pantalla de registro de parámetros, y el usuario ingresa la ip del web service, el nombre de la cooperativa, el código de la cooperativa, direcciónde la cooperativa, teléfono de la cooperativa, y presiona en registrar parámetros.El sistema verifica los datos ingresados, el sistema limpia la tabla de parámetros de la base de datos y los almacena en la base dedatos del equipo.El sistema devuelve un código de error el sistema verifica el código de error y muestra la alerta con el mensaje de parámetros ingresados correctamente, el usuario presiona sobre ok y el sistema muestra la pantalla de login del sistema.

Curso alterno: Parámetros incorrectos: el

usuario no ingresó los 5 parámetros o ingresó incorrectamente los parámetros, el sistema muestra una alerta de error con el mensaje "datos ingresados incorrectos".

Error al guardar los parámetros en la base de datos: el sistema el intentar guardar los parámetros no obtiene respuesta o surge un error al guardar en base de datos, el sistema muestra un alerta con el mensaje "error al registrar parámetros"

pantalla registro deparámetros

Usuario

(from Actors)

visualiza pantalla deregistro de parámetros

Parametros

Guarda paràmetros

los datos fueroningresados

correctamente?

Muestra alerta de datosincorrectos limpia la tabla en base

de datos

Guardado correcto?muestra alerta de

guardado incorecto

Muestra alerta de datosregistrados

correctamente

el sistema muestra lapantalla de inicio delsistema en el midlet

pantalla de inicio desistema

pantalla de espera deregistro de parámetros

visualiza pantalla deesera de registro de

parámetros

no

el usuairo presiona en ok

Ingresa losparámetros ip,cadena deconexion,nombre decooeprativa,dirección ypresiona enregistrar

si

no

si

Figura 16: Diagrama de robustez de caso de uso registro parámetros

82

CU3: Selección de socio sd Seleccion de socio

CU3: Selección de socioDescripción:El Usuario realiza una búsqueda del socio, y selecciona de la l ista encontrada a uno para realizar operaciones con el socio.

Curso Básico:En la pantalla búsqueda de socio, el usuario ingresa el DNI del socio y selecciona la opción búsqueda por DNI, y pulsa en la opción buscar, el sistema muestra la pantalla de espera de búsqueda socio.El sistema verifica los datos, recupera los parámetros de conexión como son ip del web service de parámetros, inicializa el web service con los parámetros y envía los datos de numero bluetooth, el DNI delcliente, el id del usuario y los envía al web service.El sistema espera la respuesta del web service.El web service responde la petición con un mensaje, el sistema parsea la cadena devuelta y almacena los datos l legados en Socio y Errores, el sistema verifica el error devuelto por el web service, si está correcto la devolución el sistema guarda los datos en socio en la base de datos local del sistema, verifica el error al guardar en base de datos y muestra en la pantalla la l ista de socios, con el DNI del socio, nombres y apellidos del socio.El usuario hace clic sobre uno de los socios encontrados, el sistema guarda en sesión los datos del socio como el numero documento, nombre y apell idos ymuestra la pantalla de menú operaciones.Curso alterno:

Tiempo de espera agotado: después de un tiempo de 10 segundos el web service no responde, el muestra un alerta de error con el mensaje, tiempo de espera agotado.

El web service devuelve error: el sistema muestra un alerta con el mensaje de error devuelto por el web service.

Error al guardar datos de socio en base de datos: el sistema muestra un alerta de error con el mensaje error al guardar datos de socio en dispositivo local.

pantalla de busquedasocio

Usuario

(from Actors)

Mostrar pantalla debusqueda socio

verifica si se ingresódatos correctos

Devuelve un error conel mensaje de datos

ingresados incorrectos

Recupera losparámetros de

conexión de webservice

Datos recuperadoscorrectamente?

muestra error ocnmensaje de erro al

recuperar parámetros

Almacena datos desocio como nombre,

tipo documento ynumero documento de

identidad

Socio

Envia datos al webservice busqueda socio

Tiempo de esperaagotado?

Parsea los datosobtenidos del web

service

Datos correctosdevueltos por web

service?

Devuelve error conmensaje de tiempo de

espera agotado

muestra pantalla deespera de selección

socio


devuelto por webservice

guarda datos del socio

muestra l ista de socio,con el dni del socio,nombre y apell ido

Web service

Coloca en sesión elusuario seleccionado

muestra la l ista demenú operaciones

pantalla de espera debusqueda socio

Pantalla de l ista desocios

pantalla de menu deoperaciones

Parametro

incorrectos

si

no

si

no

si

correctos

no

clic en uno de los usuarios

ingresa el DNI de socio yselecicona Busqueda porDNI, y pulsa en buscar

Figura 17: Diagrama de robustez de caso de uso Selección socio

83

CU4: Selección de cuenta de ahorro sd Selección de cuenta ahorro

Descripción:El usuario realiza una búsqueda de cuentas de ahorro del socio antes seleccionado, y elige una cuenta para realizar las operaciones financieras en la cuentaCurso básico:El usuario en la pantalla de menú operaciones, hace clic sobre la opción de ahorro, el sistema muestra la pantalla de espera de búsqueda cuenta.El sistema recupera la ip de conexión de parámetros, recupera los datos del socio como el número de identificación, recupera los datos del usuario en sesión, recupera la dirección bluetooth del dispositivo, y acontinuación se conecta con el web service y envía el código de usuario, la dirección bluetooth, el número y tipo de identificación del socio al web service.El sistema espera la respuesta del webservice.El web service responde con un mensaje, el sistema parsea el mensaje y obtiene el código error de operación y el mensaje de error, si el error de operación es de operación correcta, el sistema parsea el mensaje y obtiene los datos de las cuentas ahorro del socio, como son el número de cuenta, la moneda de la cuenta, nombre producto de la cuenta y retorna el error y la l ista de cuentas; el sistema comprueba que la l ista de cuentas sea como mínimo uno, el sistema muestra en la pantalla de cuentas de socio.El usuario hace clic sobre una de las cuentas visualizadas, el sistema guarda los datos de la cuenta seleccionada en sesión y muestra la l ista de menú de opciones de cuenta de ahorro.

Curso alterno:

Error al obtener los parámetros de conexión: el sistema no puede obtener los parámetros de conexión, muestra un alerta con el mensaje de "error al recuperar parámetros de conexión".

No hay respuesta del web service: después de un tiempo de 10 segundos el web service no responde, el sistema cierra la conexión y muestra un alerta con el mensaje de error de tiempo de espera agotado.

El web service devuelve los datos incompletos, el sistema crea un Error y lo devuelve a interface, en aquí muestra un alerta con el código y descripción del error.

El socio no posee cuentas: el sistema muestra un alerta de error con el mensaje de socio no posee cuentas de ahorro.

usuario

Pantalla de menúopciones

muestra la pantalla deespera

recupera parámetrosde conexión como la

ip

Parámetros

Dstos recuperadoscorrectamente?

Muestra alerta conmensaje de error de no

error al recuperarparámetros de

conexión

recupera datos delusuario como el codigo

de usuario

Usuario

recupera datos delsocio como numero de

identificación

Socioconecta y envía losdatos de codigo deusuario, numero de

identificacion del socioy la direccionbluetooth del

dispositivo

Tiempod e esperaagotado?

Muestra alerta conmensaje de tiempo de

espera agotado

parsea el error yalmacena en error

Error

error de operacióncorrecta?

muestra alerta conmensaje obtenido delerror del web service

parsea los datos decuenta de socio y

guarda en cuenta socioy pone ensesion la

cuenta

pantalla de espera

Cuenta ahorro

muestra pantalla conlista de cuentas de

ahorro del socio

pantalla de lista decuentas de ahorro

el socio tiene cuentasde ahorro?

mostrar mensaje de noposee cuentas de

ahorro

webService

visualizaPantalla deoperaciones

Pantalla deoperaciones de cuenta

ahorro

si

clic en opcion deahorros

si

clic en una cuenta

no

no

si

no

si

no

Figura 18: Diagrama de robustez de caso de uso selección cuenta ahorro

84

CU5: Retiro

sd Retiro cuenta de ahorros

Descripción:El socio realiza un retiro de su cuenta de ahorros

Curso básico:En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de retiro, el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio que está activa, y muestra la pantalla de retiro con los datos: nombre de usuario, cuenta de socio, número de identificaciónde socio, respectivamente l lenados.El usuario ingresa la cantidad a retirar y hace clic sobre procesar; el sistema muestra un alerta de verificación si está conforme con la transacción o no, el usuario pulsa en la opción si, el sistema muestra al usuario la pantalla de espera, el sistema verifica la cantidad de retiro, recupera los parámetros de conexión de parámetros, el sistema cifra los datos de número de cuenta y número de documento del socio.El sistema se conecta con el web service y envía los datos de retiro: cuenta de socio, número de identificación de socio, nombre de usuario, valor de retiro, el número de bluetooth; el sistema espera la respuesta.El sistema recibe la respuesta del web service, parsea el mensaje recibido y obtiene el error y los datos del retiro, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuenta socio, numero documento del socio, el valor de la transacción, el usuario en sesión, el numero de referencia, el numero de secuencia de impresión , la fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno:





El web service devuelve un error diferente de estado correcto, el sistema muestra la alerta de error con el código de error devuelto y el mensaje devuelto.

Usuario

(from Actors)

pantalla de menúahorro

pantalla de retiro

Visualiza pantalla demenú de ahorros

Recupera los datos deusuario

Usuario

Socio

Recupera datos desocio

Recupera los datos decuenta de ahorro

Cuenta ahorro

Visualiza pantalla deretiro

Muestra alerta deverificación

Pantalla de espera detransacción de retiro

muestra pantalla deespera transacción de

depósitoRecupera parametros

de conexión

Parámetros

Parámetrosrecuperados

correctamente?

muestra alerta de errorcon mensaje error alrecuperar parámetros

conecta con webservice

envia los datos delretiro como



bluetooth


muestra alerta de rrorcon mensaje de

tiempo de esperaagotado

respeusta fué exitosa?


comunicación

Parsea respuesta yobtiene el error

surgió algún error en latransacción?


devuelto

obtiene datos de latransacción

guarda datos detransacción

operacion AH

guardado correcto?alerta de error con

mensaje detransacción realiada

correctamente, error alguardar en base dedatos local, consulte

con proveedor

muestra mensaje detransacción correcta, y

opción si deseaimprimir

Error

Web Service

clic en retiro

clic ensi

clic enno

ingresa monto y pulsaen procesar

no

sino

no

no

tiempo de espera agotado

sino

Figura 19: Diagrama de robustez de caso de uso retiro

85

CU6: Deposito


Descripción:El socio realiza un depósito en su cuenta de ahorrosCurso básico:En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de depósito; el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio que está activa, y muestra la pantalla de depósito con los datos: nombre de usuario, cuenta de socio, número de identificación de socio, respectivamente llenados.El usuario ingresa la cantidad a retirar y hace clic sobre procesar; el sistema muestra un alerta de verificación si está conforme con la transacción o no, el usuario pulsa sobre si, el sistema muestra al usuario la pantalla de espera; el sistema verifica la cantidad de retiro, recupera los parámetros de conexión de parámetros, el sistema cifra los datos de número de cuenta y número de documento del socio, luego se conecta con el web service y envía los datos de depósito: cuenta de socio, número de identificación de socio, nombre de usuario, valor de retiro, el numero de bluetooth, y los envía al web services.El sistema espera la respuesta del web service por un tiempo prudencial.El sistema recibe la respuesta del web service, parsea el mensaje recibido y obtiene el error y los datos del retiro, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuenta socio, numero documento del socio, el valor de la transacción, el usuario en sesión, el numerode referencia, el numero de secuencia de impresión , la fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno:

Error al recuperar parámetros, el sistema no puede recuperar los parámetros de conexión, el sistemamuestra un alerta de error con el mensaje error al recuperar parámetros.



La transacción se realizó de forma correcta pero no se almacenó en labase de datos local: el sistema al almacenar los datos en la base de datos local, surge un error, el sistema muestra un alerta con el código de error respectivo y el mensaje de error, transacción realizada correctamente, error al almacenar en dispositivo local, consulte con su proveedor de servicios.

Usuario

(from Actors)



ahorros



nombre de usuario

usuario


apellido

socio



cuentaAhorro





identificación del socio,identificacion delusuario, numerocuenta, valor de

depósito, numerobluetooth


de depósito




Errores



Operacion AH

guardado correcto'


muestra alerta de errorcon mensaje de error al

guardado


correctamente


comunicación

muestra alerta de errorcon mensaje tiempo de

espera agotado




parámetros

Parametros

WebService



cifra datos

si

no

sino

no

esperaagotada

clic en no

opcion seleccionada essi

si


clic en depósito

sino

Figura 20: Diagrama de robustez de caso de uso depósito

86

ARQUITECTURA TECNICA

a. Topología de sistema

Figura 21: Topología de sistema

87

b. Diagrama de componentes

cmp Diagrma de componentes

EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version



































Vistas

Midlet

Controladores

Controladores de operaciones

Modelo

DAO Beans

WebServ ice

Figura 22: Diagrama de componentes de sistema móvil

88

c. Diagrama de despliegue

deployment Diagrama de despliegue




































Capa de presentación

Midlet

Logica

Controladores

Componentes de acceso a datos

Base de datos

Base de datos

Figura 23: Diagrama de despliegue de sistema móvil

89

DIAGRAMAS DE SECUENCIA sd login

Usuario

(from Actors)

Usuario ErrorPantalla de iniciosesion

Parametros Web serv icepantalla deespera de inicio

sesion

pantalla busquedasocio

CLogin

Registrarparámetros

EncriptaDescripción:El usuario inicia sesión para el uso del sistema

Curso básico:El sistema muestra al usuario la pantalla de login.El usuario ingresa su nombre de usuario ycontraseña y pulsa en la opción iniciar sesión, el sistema muestra la pantalla de espera de login.El sistema valida si es correcto el ingreso de datos, luego valida si los datos ingresados pertenecen al administrador, el sistema recupera los parámetros de conexión como son la ip de conexión del web service, recupera la dirección bluetooth, y se conecta con web services y envía el nombre de usuario y la contraseña al web service.El web service responde con un mensaje, el sistema parsea el mensaje y obtiene el error; el sistema compara si el error es de operación correcta el sistema parsea los datos del usuario como son el nombre de usuario, apell idos, nombre de usuario, y los almacena en usuario; y el sistema muestra la pantalla de búsqueda socio.

Curso Alterno:

No existen parámetros, el sistema recuperar los parámetros de conexión, no encuentra ningún parámetro almacenado, el sistema muestra un alerta con el mensaje de no existen parámetros.

El tiempo de espera agotado: el sistema al enviar los datos respectivos al web service, demora en la obtener respuesta, el sistema muestra un alerta con el mensaje tiempo de espera agotado.

El error obtenido del web service es operación incorrecta, el sistema muestra el mensaje con el mensaje obtenido del error.

El nombre de usuario y contraseña pertenecen al administrador de equipo, el sistema muestra la pantalla de registro de parámetros.

ingresanombre deusuario ycontraseña()

displayWaitScreenInicioSesion()

new()

verificaDatos():Errores

validaDatosAdministrador():Usuario

inicioSesion(String contraseña, String usuario):Errores

new Usuario(contraseña, nombreUsuario)

recuperaParametros():Parametro

getDireccionBluetooth():String direccion

EncriptaDatos(claveUsuario)inicioSesion(nombreUsuario, claveUsuario,direccionBluetooth):String cadena

parseaXML(String cadena):Errores

display()

Tiempo de espera agotado()muestra alerta

No existen parámetros de conexiongetAlert()

Error obtenido del web service es operacion incorrecta(): Errores

getAlertaError()

El nombre y contrasena pertenecen a administrador , goTo()

Figura 24: Diagrama de secuencia de caso de uso login

90

sd Registrar parámetros

Usuario

(from Actors)

pantalla registrode parámetros

ParametrosCParametro ParametroDAO

pantalla de iniciode sistema

pantalla deespera de registro

de parámetros

Descripción:El Usuario registra los parámetros para el funcionamiento del sistema móvil

Curso básico:El sistema muestra la pantalla de registro de parámetros, y el usuario ingresa la ip del web service, el nombre de la cooperativa, el código de la cooperativa, dirección de la cooperativa, teléfono de la cooperativa, y presiona en registrar parámetros.El sistema verifica los datos ingresados, el sistema limpia la tabla de parámetros de la base de datos y los almacena en la base de datos del equipo.El sistema devuelve un código de error el sistema verifica el código de error y muestra la alerta con el mensaje de parámetros ingresados correctamente, el usuario presiona sobre ok y el sistema muestra la pantalla de login del sistema.

Curso alterno: Parámetros incorrectos:

el usuario no ingresó los 5 parámetros o ingresó incorrectamente los parámetros, el sistema muestra una alerta de error con el mensaje "datos ingresados incorrectos".

Error al guardar los parámetros en la base de datos: el sistema el intentar guardar los parámetros no obtiene respuesta o surge un erroral guardar en base de datos, el sistema muestra un alerta con el mensaje "error al registrar parámetros"

getFrmRegistroParametro()

displayFrmParametro()

ingresa parametros clic en registrar()

display waitScreenRegistroParam()

registrarParametros(Parametro a):Errores

new()

dropParametro()

newParametro(Parametro):Errores

getAlerta(Errores)

clic en ok()

display()

Error al registrar parametro();Errores muestraalerta

Error datos ingresadosIncorrectos();Errores muestraalerta

getAlertaError()

Figura 25: Diagrama de secuencia de caso de uso registro de parámetros

91

sd Selección de cuenta ahorro

usuarioCuenta ahorro Error ParámetrosSocio Usuariopantalla de

esperapantalla de listade cuentas de

ahorro

Pantalla de menúopciones

CCuentas ParametrosDAOWeb serv icepantalla de menu

de operaciones

Descripción:El usuario realiza una búsqueda de cuentas de ahorro del socio antes seleccionado, y elige una cuenta para realizar las operaciones financieras en la cuentaCurso básico:El usuario en la pantalla de menú operaciones, hace clic sobre la opción de ahorro, el sistema muestra la pantalla de espera de búsqueda cuenta.El sistema recupera la ip de conexión de parámetros, recupera los datos del socio como el número de identificación, recupera los datos del usuario en sesión, recupera la dirección bluetooth del dispositivo, y a continuación se conecta con el web service y envía el código de usuario, la dirección bluetooth, el número y tipo de identificación del socio al web service.El sistema espera la respuesta del web service.El web service responde con un mensaje, el sistema parsea el mensaje y obtiene el código error de operación y el mensaje de error, si el error de operación es de operación correcta, el sistema parsea el mensaje y obtiene los datos de las cuentas ahorro del socio, como son el número de cuenta, la moneda de la cuenta, nombre producto de la cuenta y retorna el error y la lista de cuentas; el sistema comprueba que la lista de cuentas sea como mínimo uno, el sistema muestra en la pantalla de cuentas de socio.El usuario hace clic sobre una de las cuentas visualizadas, el sistema guarda los datos de la cuenta seleccionada en sesión y muestra la lista de menú de opciones de cuenta de ahorro.

Curso alterno:

Error al obtener los parámetros de conexión: el sistema no puede obtener los parámetros de conexión, muestra un alerta con el mensaje de "error al recuperar parámetros de conexión".

No hay respuesta del web service:después de un tiempo de 10 segundos el web service no responde, el sistema cierra la conexión y muestra un alerta con el mensaje de error de tiempo de espera agotado.

El web service devuelve los datos incompletos, el sistema crea un Error y lo devuelve a interface, en aquí muestra un alerta con el código y descripción del error.

El socio no posee cuentas: el sistema muestra un alerta de error con el mensaje de socio no posee cuentas de ahorro.

clic en ahorro()

display()

newCCuentas()

buscarCuenta(String, Usuario , int ):Vector getParametro():

Parametro

getDocSocio()

busquedaCuentas(String nombreusuario, String direcBlue,String numDoc, int tipo):String

parseaBusquedaCuentas(String respWs):Vector

taskComproCantCuenta()

display()

clic en una cuenta()

new CCuentas(String numCuen, String nombre Cuenta)

display()

error al obtener parametros de conexion():Errores

timpo de espera agotado por web service():Errores

datos incompletos recibidos():Errores

getAlertErroes()

no posee cuentas el socio():Errores

verifica cuenta():Vector

displayList() no posee cuentas elsocio

Figura 26: Diagrama de secuencia de caso de uso Selección cuenta ahorro

92


Usuario

(from Actors)











clic endepósito()



getNumDOc()

getNombre()


display()



display()


ParametrosDao()








getAlertOk()






getAlertErrores()

display()

Figura 27: Diagrama de secuencia de caso de uso deposito

93

sd Retiro cuenta de ahorros

Usuario

(from Actors)

Cuenta ahorroPantalla deespera de

transacción deretiro

Parámetros Socio Usuario operacion AHpantalla de menúahorro

pantalla de retiro ErroresCOPeracion ParametrosDAO ServiceOperacionesDAO()

Descripción:El socio realiza un retiro de su cuenta de ahorros

Curso básico:En la pantalla de menú de Ahorro, el usuario pulsa sobre la opción de retiro, el sistema recupera los datos de Socio que está en sesión y la Cuenta Socio que está activa, y muestra la pantalla de retiro con los datos: nombre de usuario, cuenta de socio, número de identificación de socio, respectivamente l lenados.El usuario ingresa la cantidad a retirar y hace clic sobre procesar; el sistema muestra un alerta de verificación si está conforme con la transacción o no, el usuario pulsa en la opción si, el sistema muestra al usuario la pantalla de espera, el sistema verifica la cantidad de retiro, recupera los parámetros deconexión de parámetros, el sistema cifra los datos de número de cuenta y número de documento del socio.El sistema se conecta con el web service y envía los datos de retiro: cuenta de socio, número de identificación de socio, nombre de usuario, valor de retiro, el número de bluetooth; el sistema espera la respuesta.El sistema recibe la respuesta del web service, parsea el mensaje recibido y obtiene el error y los datos del retiro, verifica el error devuelto por el web service y si el error es considerado como correcto, el sistema guarda los datos cuenta socio, numero documento del socio, el valor de la transacción, el usuario en sesión, el numero de referencia, el numero de secuencia de impresión , la fecha y hora de depósito en Operaciones Ahorro, y el sistema muestra una alerta de transacción realizada correctamente, y si desea imprimir la transacción.Curso alterno:




La transacción se realizó de forma correcta pero no se almacenó en la base de datos local: el sistema al almacenar los datos en la base de datos local, surge un error, el sistema muestra un alerta con el código de error respectivo y el mensaje de error,transacción realizada correctamente, error al almacenar en dispositivo local, consulte con su proveedor de servicios.

El web service devuelve un error diferente de estado correcto, el sistema muestra la alerta de error conel código de error devuelto y el mensaje devuelto.

clic ejn depósito()

getPantallaRetiro()

getNombreUsuairo()

getNumCuenta()

getNUmDoc()

getNombre()

display()

ingresa monto de retiro clicen procesar()

getWaitScreenProcesandoRetiro()

display()

movimiento(String usua, String bluetooth, StringnoIdentificacion, String cuenta, String moneda,String producto, String montoEfectivo, StringnombreSocio, String tipoProceso) :Errores

new ParametrosDAO()

getParametro(String codigoParam):parametro


parseaOperacion(StringxmlStri)

traverseOperacion(String retorno)

new OperacionesDAO()



getAlertOK()



error al obtener parametros de conexion():Errores



getAlertErrores()

display()

Figura 28: Diagrama de secuencia de caso de uso retiro

94

DIAGRAMA DE CLASES class modelo

CuentaAhorro



CuentaCredito



DatoFinancieroSocio



Departamento



Distrito



Empresa



OperacionAh



Error



Prov incia



Transferencia



Socio



Usuario



Cuenta


Ubigeo



0

tiene

0..1

2

se realiza encuenta

0..*

1

posee

11

ubica

0..*

1

ubica

0..*

1

se_realiza_con

0..*

0..1

pertenece

0..*naceen

1

ubica

0

1

realiza0..*

2

transfiere

0..*

1realiza

0..*

1realiza

0..*

0..*

tiene

1

Figura 3. 19: Diagrama de clases de sistema de banca móvil

95

class bean

Cuenta

CuentaAhorro



Cuenta

CuentaCredito



DatoFinancieroSocio



Departamento



Distrito



Empresa



Error



OperacionAh



Parametro

+ direc: String+ ipCoope: String+ nomCoop: String+ telef: String

Prov incia



Socio



Transferencia



Usuario



DAO::OperacionesDAO


DAO::CuentaCreditoDAO

+ CreateTblCuentaCR() : J2METable+ CuentaCreditoDAO()+ NewCuentaCred(String, String, String, String, String, String, String, String, String, String) : void

DAO::CuentaAhorroDAO

+ createTblCuentaAH() : J2METable+ CuentaAhorroDAO()+ getCuenta(String) : J2MERow+ newCuentaAH(String, String, String, String, String) : void

DAO::SocioDAO


Controladores::CLogin

+ dispositivoLocal: LocalDevice~ errorc: Error = new Errores()~ URL: String~ usuario: Usuario

+ iniciarSesion(Usuario) : Error+ inicioSesion(String, String) : Error+ obtenerDatosUsuario(String, String) : Usuario+ obtenerDirecBluetooth() : String+ parseaXML(String) : Error+ traverse(XmlParser) : Error+ verificarComunicacion(Error, String) : Error

Controladores::CCuentas

+ buscarCuenta(String, Usuario, int) : Vector+ buscarCuentaDest(String, Usuario, String, int) : Vector+ parseaBusquedaCuentas(String) : Vector+ traverseCuenta(XmlParser, String) : Vector+ traverseCuentaCred(XmlParser, String) : Vector



Encripta

+ encriptaDatos(String) : String

v ista::Midlet





Controladores::CParametro

+ registrarParametros(String, String, String, String, String) : Error

Controladores::CClientes

+ buscarSocio1(String, Usuario) : Vector+ guardarSocio(String, int, Usuario) : Vector+ parseaBusquedaSocios(String) : Vector+ traverseSocio(XmlParser, String) : Vector

DAO::ParametrosDAO


Ubigeo



~errorc

1

se_realiza_con

0..*

~usuario

1

realiza

0..*

1realiza

0..*

2

transfiere

0..*

1

realiza0..*

1

ubica

0

0

tiene

0..1

0..1

pertenece

0..*

1ubica

0..*

1

ubica

0..*

1

posee

1

2

se realiza encuenta

0..*

~operaAH

~opera

~erro

nace en

Figura 3. 20: Diagrama de clases de bajo nivel de sistema de banca móvil

96

informe de practicas-sistema de banca móvil para cooperativas

Documents