Taller De Grado I

UNIVERSIDAD AUTNOMA GABRIEL REN

MOREMO FACULTAD DE CIENCIAS DE LA
COMPUTACION Y TELECOMUNICACIONES
Carrera de Ingeniera Informtica

Taller de Grado I
SOFTWARE PARA ADMINISTRAR UNA AGENDA DISTRIBUIDA EN J2ME
PARA LA F.S.T.P.S.C.

Realizado por:
Diego Antequera Virhuez.
Fernando Mendoza Chvez.
Revisado por:
Msc. Ing. Rolando Martnez

Friday, 29 de May de 2015

INDICE
PARTE 1.................................................................................................................................1
ASPECTOS GENERALES DEL PROYECTO.................................................................1
CAPITULO 1.........................................................................................................................2
PERFIL DEL PROYECTO..................................................................................................2
PROYECTO
1.1.

INTRODUCCIN........................................................................................ 3

1.2.

ANTECEDENTES....................................................................................... 4

1.3.

DESCRIPCIN DEL PROBLEMA..................................................................5

1.4.

SITUACIN PROBLEMTICA......................................................................6

1.5.

SITUACIN DESEADA............................................................................... 6

Taller De Grado I
1.6.

OBJETIVOS............................................................................................... 6

1.6.1.

OBJETIVO GENERAL...........................................................................6

1.6.2.

OBJETIVOS ESPECFICOS....................................................................6

1.7.

ALCANCE................................................................................................. 7

1.8.

METODOLOGA......................................................................................... 8

PUDS - PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE.....................8

1.9.

HERRAMIENTAS....................................................................................... 9

CAPITULO 2.......................................................................................................................10
LA EMPRESA (F.S.T.P.S.C.).............................................................................................10
(F.S.T.P.S.C.)
2.1. FEDERACION SINDICAL DE TRABAJADORES DE LA PRENSA DE SANTA CRUZ
(F.S.T.P.S.C.)..................................................................................................... 11

CAPITULO 3.......................................................................................................................13
EL SOFTWARE: AGENDA ELECTRONICA DISTRIBUIDA.....................................13
DISTRIBUIDA
3.1.

AGENDA REUNION............................................................................... 14

3.2.

AGENDA ELECTRONICA..........................................................................15

3.3.

AGENDAS ELECTRONICAS DISTRIBUIDAS...............................................15

PARTE 2...............................................................................................................................19
DESARROLLO DEL SOFTWARE..................................................................................19
CAPITULO 4.......................................................................................................................20
FLUJO DE TRABAJO:......................................................................................................20
TRABAJO:
CAPTURA DE REQUISITO.............................................................................................20
REQUISITO
4.1.

DEFINIENDO EL CONTEXTO DEL PROYECTO............................................21

4.1.1.
4.2.

MODELO DE DOMINIO......................................................................21

IDENTIFICAR CASOS DE USO...................................................................22

4.2.1.

IDENTIFICACION DE ACTORES..........................................................22

4.2.2.

IDENTIFICACION DE CASOS DE USO..................................................22

4.3.

CASOS DE USO POR MDULOS................................................................23

4.4.

PRIORIZAR CASOS DE USO......................................................................24

4.5.

DETALLE DE CASOS DE USO....................................................................25

4.6.

MODELO DE CASOS DE USO....................................................................43

CAPITULO 5.......................................................................................................................44
FLUJO DE TRABAJO:......................................................................................................44
TRABAJO:

Taller De Grado I

ANALISIS............................................................................................................................44
ANALISIS
5.1.

ANALISIS DE ARQUITECTURA.................................................................45

5.1.1.

IDENTIFICAR PAQUETES DE ANALISIS...............................................45

5.1.2.

DESCRIBIR PAQUETES......................................................................45

5.1.3.

VISTA EXTERNA DE PAQUETE...........................................................46

5.2.

ANALIZAR CASOS DE USO......................................................................49

CAPITULO 6.......................................................................................................................58
FLUJO DE TRABAJO:......................................................................................................58
TRABAJO:
DISENO...............................................................................................................................58
DISENO
6.1.

ANALISIS CLASES................................................................................... 59

6.1.1.

ARQUITECTURA LOGICA..................................................................59

6.1.2.

DISENO DE LA ARQUITECTURA FISICA..............................................60

6.1.3.

DISENO DE CASOS DE USO...............................................................61

6.1.4.

DISENO DE CLASE..........................................................................78

6.2.

DIAGRAMA DE CLASES GENERAL...........................................................92

6.3.

ANALIZAR PAQUETES............................................................................. 94

6.3.1.

DEPENDENCIA DE PAQUETE.............................................................94

CONCLUCIONES..............................................................................................................95
RECOMENDACIONES.....................................................................................................95
BIBLIOGRAFIA.................................................................................................................96
ANEXOS..............................................................................................................................97
Esquema grafico de la situacin problemtica.............................................................97
Esquema grafico de la situacin deseada....................................................................98

Tabla de Ilustraciones
Ilustracin 1: Organigrama de la Institucin...................................................................11
Ilustracin 2: Organigrama de la Corte.........................................................................12
Ilustracin 3: Arquitectura SOA................................................................................. 17
Ilustracin 4: Modelo de Dominio............................................................................... 21

Taller De Grado I

PARTE 1
ASPECTOS GENERALES DEL
PROYECTO

Taller De Grado I

CAPITULO 1
PERFIL DEL PROYECTO

Resumen
En este captulo se introduce la temtica de
investigacin propuesta, se describe el problema, los
objetivos que conducen la solucin a la problemtica,
los alcances y limitaciones para desarrollar el
sistema.

Taller De Grado I

1.1.

INTRODUCCIN.
El mundo actual se encuentra inmerso en cambios constantes y ms an

tecnolgicos, donde todos y cada uno de los miembros que lo conforman se encuentran
interrelacionados y a su vez, se encuentran en una constante competencia para ser
mejor. El cual hace que busquen el desarrollo integral de todos sus elementos, dando le
mayor importancia al control de calidad. Este efecto, conlleva a que este proceso de
cambios y mejoras tenga nuevas exigencias, donde el software tendr que cumplir con
nuevos requisitos, seguir procesos para satisfacer necesidades ms exigentes, teniendo
que demostrar la calidad que tienen.
Santa Cruz de la Sierra ciudad dinmica y productiva donde la principal actividad
econmica reside en el sector industrial, comercial y de servicios, no ha sido la
excepcin. Hoy en da se puede evidenciar el crecimiento que ha sufrido la ciudad y su
poblacin junto a las diferentes organizaciones lucrativas, y no lucrativas; las mismas
cada vez ms requieren de profesionales y tcnicos idneos en las diferentes reas.
Las organizaciones que estn en crecimiento o estn en el ms alto proceso de
crecimiento donde interactan muchas personas para alcanzar un objetivo en comn,
recurren al uso de agendas electrnicas, para las reuniones constantes que se sostienen
dentro de la organizacin o institucin. Una agenda electrnica es lo ms utilizado por
toda persona que est dentro de un mundo de negocios, citas, acontecimientos, entre
otros, donde el principal objetivo del uso de una agenda es anotar dichas citas para un
posterior recuerdo de nuestras actividades diarias.
La Federacin Sindical de Trabajadores de la Prensa de Santa Cruz de la Sierra,
actualmente es dirigida por un directorio de 18 personas a la cabeza de todas las
organizaciones del departamento, en la cual se realizan muchas reuniones durante el
transcurso del mes, donde es anotada en un calendario Cuaderno de Citas y
Reuniones, el cual despus es avisado a las distintas personas va telefnica para su
confirmacin de asistencia.
En el lapso de este documento abordaremos los problemas con respecto al uso de
agendas comunes, agendas electrnicas, y una posible solucin una Agenda Comn
3

Taller De Grado I

distribuida, donde el principal objetivo es que todas las personas puedan acceder a la
informacin almacenada en dicha agenda.

1.2.

ANTECEDENTES.
La Federacin Sindical de Trabajadores de la Prensa de Santa Cruz F.S.T.P.S.C.

actualmente est conformada por los 31 sindicatos en todo el departamento con 1125
afiliados hasta el momento, y dirigido por un directorio de 18 personas las cuales son
elegidas democrticamente entre todos cada 2 aos.
En la federacin se realizan 1 reunin de directorio cada semana, donde las 18
personas que representan se juntan para discutir diversos temas, cada 3 meses se
realizan reuniones generales, donde se cita a los representantes de los 31 sindicatos de
Santa Cruz, y cada cierto tiempo se llaman a ampliados generales donde se hace saber a
todas las actividades programadas por la Federacin, como ser Cursos de capacitacin,
o formar grupos de personas que son enviadas como corresponsales, entre otros. Donde
se ve la necesidad de que todas las personas estn informadas de las distintas
actividades que se realizaran, puesto que actualmente para las reuniones de directorio se
informa va telefnica, donde no muchas veces no se logra comunicar a todas las
personas, para poder confirmar su posterior asistencia, en las reuniones generales con
los distintos sindicatos afiliados, se les comunica mediante fax sobre las reuniones,
donde muchas veces los dirigentes no asisten poniendo como excusa que no saban o no
llegan los fax y en los ampliados departamentales, se enva mediante fax el comunicado
a cada dirigente de sindicato, para que el posteriormente pase el informativo a cada uno
de sus integrantes, siendo un problema que no todos pueden llegar a conocer las
actividades, por diferentes causas, siendo la ms comn que no muchas veces el que
dirige el sindicato avisa al grupo opositor de dichas reuniones.
Actualmente todo se anota en una agenda en secretaria de la Federacin, donde
cualquier persona afiliada puede llamar a consultar sobre las actividades programadas,
pero no todas las personas logran enterarse de las actividades, y muchas veces se ven
vacios los ampliados. Ahora lo que se desea hacer es un software Una Agenda
Distribuida, donde se coloquen todas las reuniones, citas, actividades, entre otros, y
cualquier persona desde su celular pueda acceder a la informacin sin necesidad de
4

Taller De Grado I

llamar, simplemente podr confirmar directamente su asistencia o excusarla, donde el

software avisara ni bien se coloque una cita, y avise hora antes de realizar dicha cita a
todos los afiliados.
Actualmente existe diversos tipos de software que podran ser una solucin pero no
son muy especficos a la hora de armar una reunin grupal, se podra usar Twitter para
avisar a todos, pero no se podra saber si confirma o no la asistencia, las mismas
agendas que traen los celulares, pero a la vez otras personas no podran acceder a pasar
la cita de agenda a otra agenda, puesto que son de uso personal y no colectivo,
aplicaciones como MSN permiten que un grupo de personas en grupo puedan entablar
una conversacin pero no todas las personas se conectan al mismo tiempo, entre otros,
todos estos software se han hecho generalmente con el mbito de mostrar informacin
personal o de chat donde es necesario tener a las dos personas conectadas, la cual no es
una solucin directa al problema.

1.3.

DESCRIPCIN DEL PROBLEMA.

En la actualidad muchas personas no estn acostumbradas a usar una agenda

personal, y si las usan escriben sus notas o citas, y se olvidan de revisarlas, olvidando
asistir a las mismas.
Otro problema es que al programar una reunin para un determinado grupo de
personas no todas pueden asistir, o en el peor de los casos no se pueda comunicar a
todas las personas.
En el caso del Sindicato de la Prensa de Santa Cruz de la Sierra, la cual est
conformada por 18 personas en el directorio principal de Santa Cruz, y ms de mil
afiliados en todo el departamento distribuidos y organizados en diferentes sindicatos
segn su canal o radioemisora.
El problema es reflejado al momento de establecer las reuniones del directorio, la
cual se hace semanalmente donde el medio de comunicacin es va sms, en el cual
muchas veces los sms no logran llegar a tiempo a los afiliados para que puedan
confirmar la asistencia, y cuando es va telefnica no todos pueden contestar el telfono
ya que muchos trabajan y dejan el celular en silencio.
5

Taller De Grado I

Este problema es acarreado tambin en las reuniones de mbito general que se

realizan cada 3 meses donde estn los 18 directivos, mas los 31 representantes de los
diferentes sindicatos a nivel Departamental, porque las vas principal de comunican es
mediante Fax, a cada dirigente sindical.
El caso extremo se ve cuando se llaman a ampliados, donde se ve la necesidad que
todas las personas afiliadas estn al tanto de la reunin. En este caso se ve mucha
dificultad de llegar a todos los afiliados, ya que muchas veces existen sindicatos que no
simpatizan con algunos grupos de afiliados de ellos, y no pasan el comunicado, este es
el mayor problema donde la Federacin Sindical de Trabajadores de la Prensa de Santa
Cruz F.S.T.P.S.C., no puede llegar a todos sus afiliados.

1.4.

SITUACIN PROBLEMTICA.
La Federacin Sindical de Trabajadores de la Prensa de Santa Cruz al momento de

planificar las actividades a desarrollarse entre varias personas, muchas veces no se

puede tener una lista de las personas que confirman su asistencia a la reunin, ya que el
principal medio por el que se comunican es va sms, donde no siempre responden
confirmando o simplemente no les llega el sms a su celulares.

1.5.

SITUACIN DESEADA.
Poner al tanto de las nuevas actividades que surjan en el transcurso del tiempo,

haciendo recuerdo de las actividades establecidas, y notificando las actividades que

sean modificadas.

1.6.

OBJETIVOS.

1.6.1.

OBJETIVO GENERAL.

Desarrollar un software que permita administrar una agenda electrnica distribuida

para el manejo de reuniones en la F.S.T.P.S.C.
1.6.2.

OBJETIVOS ESPECFICOS.

Realizar un estudio sobre Tecnologas Distribuidas va socket, RMI, SOA, para el

manejo de la comunicacin entre aplicaciones cliente-servidor.
Elaborar un estudio sobre los problemas de comunicacin de la F.S.T.P.S.C.
6

Taller De Grado I

Realizar la captura de requisitos; analizando los requerimientos del software, para

definirlos a travs de casos de uso.
Analizar la arquitectura del software, de acuerdo a los requisitos especificados;
definiendo paquetes; y analizando cada caso de uso, cada clase, y cada paquete
definido.
Disear la arquitectura de acuerdo al anlisis realizado; diseando los casos de uso,
las clases, los subsistemas y las interfaces.
Implementar el proyecto segn las especificaciones del diseo.
Realizar las pruebas pertinentes para asegurar el correcto funcionamiento del
software.

1.7.

ALCANCE.
Gestionar las actividades programadas, se debe permitir guardar la fecha, da, hora

y lugar donde se desarrollar una actividad como tambin el tema a tratar, as mismo
posibilitar la modificacin o eliminacin de una actividad.
Administrar el tiempo de un usuario o de grupos de usuario, el software de
administrar un calendario para saber la disponibilidad de los usuarios para las nuevas
actividades que surjan en el transcurso del tiempo.
Gestionar actividades de grupos de usuarios, se ver permitir enviar actividades a
una sola persona, a un grupo de persona.
Envi y recepcin de nuevas actividades, las actividades nuevas tienen que ser
enviada automticamente a las personas involucradas, como tambin la recepcin y
almacenamiento de las actividades enviadas por otro usuario.
Confirmacin de asistencia, posibilidad de administrar listas de los usuarios a han
confirmado asistencia a la actividad.
Notificacin de las actividades, reproduccin mediante voz de las actividades
almacenadas en la agenda, estas notificaciones puede ser de dos formas: el usuario
puede seleccionar las actividades a ser reproducidas mediante ciertos criterios de

Taller De Grado I

bsquedas en la agenda, o el usuario puede programar la reproduccin de las

actividades de acuerdo a una configuracin.
Manejo de usuarios, este punto contempla la administracin de los usuarios como
los permisos de acceso a los diferentes grupos
Autentificacin de los usuarios, para el acceso a la administracin de la agenda.
Configuracin de la agenda, se debe permitir de habilitar o deshabilitar la
reproduccin de las notificaciones, configuracin para el acceso remoto.
Posibilidad de trabajar sin una conexin remota, en caso de que Smartphone se
desconecte de la red, la aplicacin debe trabajar con las actividades ya almacenadas.

1.8.

METODOLOGA.
Como estrategia de desarrollo del presente proyecto se aplic la metodologa de

Proceso Unificado de Desarrollo de Software (PUDS, 1999), utilizando los conceptos,

elementos de construccin y diagramas del Lenguaje Unificado de Modelado.
PUDS - PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
Fase del Proceso Unificado
Este proceso de desarrollo considera que cualquier desarrollo de un sistema
software debe pasar por cuatro fases que se describirn a continuacin, las fases de
desarrollo y los diversos flujos de trabajo involucrados dentro de cada fase, cabe
destacar el flujo de trabajo concerniente al negocio.

Fase de inicio.- se realizara la captura de los requisitos, identificar los

actores y casos de uso, priorizar casos de uso, detallar casos de uso, y un

diagrama de casos de uso.

Fase de Elaboracin.- se realizara el encapsulamiento de los casos de uso
mediante diagramas de paquetes, anlisis de los casos de uso mediante
diagrama de comunicacin.

Fase de Construccin.- en esta fase se realizar los flujos de trabajo de diseo

e implementacin:
o Diseo.8

Taller De Grado I

Diseo de la arquitectura mediante diagramas de despliegue,

diagramas de paquetes organizado en capas.
Diseo de casos de uso mediante diagramas de secuencia.
Diseo de clases mediante diagrama de clases.
o Implementacin.Modelo de implementacin mediante un diagrama de componentes
Los Flujos de Trabajo Fundamentales

Requerimientos
Anlisis
Diseo
Implementacin
Prueba

(Ivar, Grady, & James, 2000)

1.9.

HERRAMIENTAS.
SOFTWARE.
Lenguaje de Programacin

: Java

IDE (Entorno de Desarrollo Integrado)

: Eclipse, Netbeans

SDK Android, J2ME, Sony Ericsson y Nokia S60 SDK

Emulador

: wireles toolkit sun.

SGBD (Sistema Gestor de Base de Datos) : MySQL, Sqlite

Herramienta CASE

: Enterprise Architect v7.5.x

HARDWARE
Celular Android V2.2 en adelante, Sony Ericsson k510, Nokia 6530.
Una PC para Servidor de Datos

Taller De Grado I

CAPITULO 2
LA EMPRESA (F.S.T.P.S.C.)
Resumen
En este captulo se dar a conocer para quien estamos
desarrollando el software, su organizacin y su
funcin social que cumple.

10

Taller De Grado I

2.1.

FEDERACION SINDICAL DE TRABAJADORES DE LA PRENSA DE

SANTA CRUZ (F.S.T.P.S.C.)

La federacin sindical de trabajadores de la prensa de santa cruz (F.S.T.P.S.C.) es
producto de un gran trabaja de hombres y mujeres, voluntades que se han dispuesto en
beneficio de todos sus afiliados; para ello, en una parte, han trabado durante mucho en
las normas que rigen en el accionar de la organizacin, de sus dirigentes y de quienes
hacen los sindicatos y comit sindicales: hombres y mujeres de base.
La F.S.T.P.S.C. cuenta a disposicin de todos los afiliados su estatuto, el que ha sido
reformulado en la ciudad de camur con el esfuerzo de cada uno de los delegados
asistentes a este congreso extraordinario, teniendo como reto de cada uno de los
miembros de esta federacin es cumplir con este estatuto orgnico que el mismo est
dividido en 20 captulos y 139 artculos, tambin cuenta con un reglamento del tribunal
de honor y el reglamento del comit electoral. As mismo se puede mencionar que la
F.S.T.P.S.C. incluye el cdigo de tica de la confederacin sindical de trabajadores de la
prensa boliviana aprobada en 1991 y la ley de imprenta que goza de plena vigencia en
el pas.
A continuacin presentamos el organigrama de la institucin:

Sd
eci
cer
ea
aic
rEt
oe
Gur
ei
na
e
r
a

r
r
a
i

e
t
tr
c

j
t

l
Ilustracin 1: Organigrama de la Institucin

11

Taller De Grado I

SSP
eeR
ccE
eeS
aaI
riD
ohE
GaN
ecT
neE
en
rd
aa

rr
tt
r
o

i
i

l
Ilustracin 2: Organigrama de la Corte

12

Taller De Grado I

CAPITULO 3
EL SOFTWARE: AGENDA ELECTRONICA
DISTRIBUIDA
Resumen
En este captulo explicaremos acerca del software.

13

Taller De Grado I

3.1.

AGENDA REUNION
La palabra agenda es originalmente una palabra en plural, un trmino latino para

denotar las acciones a ser acometidas. Lo que hoy se conoce con ese nombre es una
lista de renglones individuales, cada uno de estos referidos originalmente
como agendum. Hoy da, sin embargo, es comn referirse a la lista en su totalidad como
la agenda para la reunin. Esta palabra es tratada como singular y tiene su
plural agendas.
Significa hacer cosas o tener cosas planeadas para hacerlas.
Contenido y Formato de una Agenda
En reuniones de negocio y de muchas instituciones pblicas y privadas, la agenda
de la reunin se conoce tambin como orden del da. La agenda se distribuye
generalmente a los participantes de una reunin antes de la misma, de modo que los
asistentes estn enterados de los temas que se discutirn y puedan prepararse
consecuentemente para la reunin.
En el procedimiento parlamentario, el orden del da no es vinculante para la
asamblea a menos que sus propias reglas as lo exijan, o haya sido adoptado como el
programa de la reunin por mayora de votos al inicio de la sesin. De lo contrario, es
simplemente una orientacin para el presidente de la asamblea.
Si un orden del da es obligatorio para una asamblea, y aparece una hora especfica
en la convocatoria de la reunin, ese elemento no puede ser iniciado antes de esa hora, y
se debe empezar cuando llegue ese momento, incluso si otro asunto se encuentra
pendiente de finalizar. Si se desea hacer otra cosa, las reglas pueden ser suspendidas con
ese propsito.
En reuniones de tipo cientfico o acadmico, se prefiere el uso de la palabra
programa.

14

Taller De Grado I

Generalmente la agenda u orden del da tiene como encabezado la fecha, la hora y el

lugar de la reunin, y le siguen una serie de puntos que conforman el contenido de la
reunin. (Airunp, et al., 2012)

3.2.

AGENDA ELECTRONICA
Un

organizador

(del ingls 'personal

personal o
digital

una

agenda

assistant

electrnica

asistente

digital

de

bolsillo,
personal),

PDA
es

una computadora de mano originalmente diseada como agenda electrnica (calendario,

lista de telefnica, bloc de notas y recordatorios) con un sistema de reconocimiento de
escritura.
Actualmente un PDA tiene por lo menos una pantalla tctil para ingresar
informacin, una tarjeta de memoria y al menos un sistema de conexin inalmbrica, ya
sea Bluetooth o WiFi. Por lo general estos dispositivos de bolsillo incluyen un
calendario, un directorio de contactos y algn programa de notas. Algunos
organizadores digitales tambin tienen soporte para navegar por la red y revisar el
correo electrnico.
La llegada de los telfonos inteligentes o Comunicadores (hbridos entre
ordenadores de bolsillo y telfono mvil) supuso para el mercado, por un lado, la
entrada de nuevos competidores y, por otro, la incorporacin a ste de usuarios
avanzados de mviles. De paso supuso la vuelta de un sistema operativo que haba
abandonado el mercado de las PDAs y ordenadores de mano en favor de los mviles:
el Symbian OS. Las PDAs de hoy en da traen multitud de comunicaciones
inalmbricas (Bluetooth, Wi-Fi, IrDA (infrarrojos), GPS...) que los hace tremendamente
atractivos hasta para cosas tan inverosmiles como su uso para domtica o
como navegadores GPS. Hoy en da la mayora de los PDAs son Smartphone.
(AlbertoDV, et al., 2012)

3.3.

AGENDAS ELECTRONICAS DISTRIBUIDAS

Para describir y comprender el comportamiento de una Agenda Electrnica Distribuida,

veremos el siguiente concepto:
15

Taller De Grado I

3.3.1.

Sistemas Distribuidos
Un sistema distribuido se define como: una coleccin de computadoras

separadas

fsicamente

conectadas

entre

por

una red

de

comunicaciones distribuida; cada mquina posee sus componentes de hardware y

software que el usuario percibe como un solo sistema (no necesita saber qu cosas
estn en qu mquinas). El usuario accede a los recursos remotos (RPC) de la
misma manera en que accede a recursos locales, o un grupo de computadores que
usan un software para conseguir un objetivo en comn.
Los sistemas distribuidos deben ser muy confiables, ya que si un
componente del sistema se descompone otro componente debe ser capaz de
reemplazarlo, esto se denomina tolerancia a fallos.
El tamao de un sistema distribuido puede ser muy variado, ya sean decenas
de hosts (red de rea local), centenas de hosts (red de rea metropolitana), y miles o
millones de hosts (Internet); esto se denomina escalabilidad. (4lex, et al., 2012)
3.3.2.

E-SOA
Enterprise Oriented Services Architecture, en espaol Arquitectura de

Servicios Orientados a Empresas. Este es un concepto de arquitectura de software

que define la utilizacin de servicios para dar soporte a los requisitos del negocio.
SOA es un plan de arquitectura abierta de Tecnologas de la Informacin
flexible y adaptable, para el desarrollo de soluciones de negocios basadas en
servicios a escala empresarial. (Trujillo, 2010)

16

Taller De Grado I

Arquitectura SOA

Ilustracin 3: Arquitectura SOA

Segn los conceptos anteriormente vistos, esta aplicacin se basara en poder conectar
una agenda, de una empresa con las agendas de todos los trabajadores, para que al
momento de poner una cita, o reunin automticamente se coloque en la agenda de los
dems, y poder ser procesadas como las citas fuesen colocadas por los mismos usuarios.
3.3.3.

J2ME Java Plataform Micro Edition

Es entorno flexible y slido para aplicaciones que se ejecutan en dispositivos

mviles e integrados: telfonos mviles, TDT, reproductores Blue-ray, dispositivos

multimedia digitales, mdulos M2M, impresoras y mucho ms.
La tecnologa Java ME se cre originalmente para paliar las limitaciones
asociadas a la creacin de aplicaciones para pequeos dispositivos. Con este fin
Oracle ha definido los fundamentos de la tecnologa Java ME para adaptarse a
entornos limitados y hacer posible la creacin de aplicaciones Java que se ejecuten
en pequeos dispositivos con memoria, visualizacin y potencia limitadas. (Oracle)
Los motivos para realizar una agenda distribuida para la Federacin Sindical de
Trabajadores de la Prensa de Santa Cruz, son:
17

Taller De Grado I

Facilitar el aviso de citas o reuniones a los usuarios, de toda la F.S.T.P.S.C., y as

tener una propia herramienta de comunicacin, ya que el uso de Google Calendar que
ofrece Google App, est fuera de las posibilidades que se tienen para el pago, de
acuerdo a lo visto por su propia pgina donde la empresa tiene que cancelar un monto
de 5 USD por usuario mes, el cual no est al alcance de las posibilidades de la
Federacin, otro inconveniente es que para sacar mayor provecho al servicio tendra
que estar en la misma plataforma de Google en este caso Android, si bien el uso de
Smartphone Android en Bolivia est incrementando, la mayora de los afiliados no
cuentan con estos dispositivos, y obligara a que se comprase uno, ya que Google
calendar no tiene una aplicacin que se ejecute desde telfonos normales, y algunas
aplicaciones que logran mantener comunicacin con Google calendar necesitan si o si
tener acceso a internet para el acceso a la informacin, ya que Google calendar solo
ofrece una pgina mvil para el acceso a los datos desde un dispositivo comn, el cual
no cuenta con una interface cmoda para la administracin de citas y eventos.
Es por eso que el desarrollo de esta aplicacin usaremos todas estas tecnologas
antes mencionadas, SOAP para el manejo y comunicacin de datos con el servidor, y la
actualizacin de los eventos suscitados en el transcurso del tiempo, en especial J2ME
que ser la plataforma de desarrollo escogida por ser multiplataforma en casi todos los
dispositivos mviles, Celulares, PDA.

18

Taller De Grado I

PARTE 2
DESARROLLO DEL SOFTWARE

19

Taller De Grado I

CAPITULO 4
FLUJO DE TRABAJO:
CAPTURA DE REQUISITO
Resumen
En este captulo explicaremos acerca de la
especificacin de los requisitos funcionales y no
funcionales del sistema, generando un modelo de
casos de uso.

20

Taller De Grado I

4.1.

DEFINIENDO EL CONTEXTO DEL PROYECTO

4.1.1. MODELO DE DOMINIO

Ilustracin 4: Modelo de Dominio

21

Taller De Grado I

4.2.

IDENTIFICAR CASOS DE USO

4.2.1. IDENTIFICACION DE ACTORES

Empresa: La encargada de poder acceder al servicio de publicacin la

planificacin de eventos, reuniones, etc. A todos sus usuarios o personas que
estn relacionadas a la empresa.
Cliente: Es el usuario normal que tiene acceso al servicio de agenda, en el
cual solo tendr permiso de guardar sus datos en el servidor y ver otras
agendas, pero l no podr compartir informacin con los dems usuarios.
Agenda: Es el software para el dispositivo mvil, que se encargara de
comunicarse con el servidor de datos, para que se actualicen los datos y
mostrarlo al cliente.

4.2.2. IDENTIFICACION DE CASOS DE USO

UC 1)

Crear Cuenta

UC 2)

Login

UC 3)

Gestionar Perfil

UC 4)

Gestionar Evento

UC 5)

Publicar Evento

UC 6)

Compartir Evento

UC 7)

Crear Evento

UC 8)

Eventos Pendientes

UC 9)

Ver Eventos
22

Taller De Grado I

4.3.

UC 10)

Notificar Eventos

UC 11)

Ver Confirmados

UC 12)

Verificar Conexin

CASOS DE USO POR MDULOS.

4.3.1.

4.3.2.

4.3.3.

Manejo de Usuarios
UC 1)

Crear Cuenta

UC 2)

Login

UC 3)

Gestionar Perfil

Manejo de Eventos
UC 4)

Gestionar Evento

UC 5)

Publicar Evento

UC 6)

Compartir Evento

UC 7)

Crear Evento

UC 8)

Eventos Pendientes

UC 9)

Ver Eventos

Manejo de Agenda
UC 10)

Notificar Eventos

UC 11)

Ver Confirmados

UC 12)

Verificar Conexin

23

Taller De Grado I

4.4.

PRIORIZAR CASOS DE USO.

CASO DE USO

ESTADO

PRIORI
DAD

RIESGO

CU1.

Crear Cuenta

Aprobad
o

Critico

Alta

CU2.

Login

Aprobad
o

Critico

Alta

CU3.

Gestionar Perfil

Aprobad
o

Importan
te

Bajo

CU4.

Gestionar Eventos

Aprobad
o

Importan
te

Media

CU5.

Publicar Eventos

Aprobad
o

Critico

Alta

CU6.

Compartir Eventos

Aprobad
o

Critico

Alta

CU7.

Crear Eventos

Aprobad
o

Critico

Alta

CU8.

Eventos Pendientes

Aprobad
o

Importan
te

Media

CU9.

Ver Eventos

Aprobad
o

Importan
te

Media

CU10. Notificar Eventos

Aprobad
o

Importan
te

Media

CU11. Ver Confirmados

Aprobad
o

Importan
te

Media

CU12. Verificar Conexin

Aprobad
o

Critico

Alta

24

Taller De Grado I

4.5.

DETALLE DE CASOS DE USO.

UC 1)

Crear Cuenta

Caso de Uso
Crear Cuenta
1
Breve
Descripcin
Se encargara de poder registrar y crear una cuenta de acceso al
sistema para los usuarios.
Actores
Principales
Cliente, Empresa
Actores
Secundarios
Ninguno
Precondiciones
Ninguno
Flujo Principal
1. Inicia cuando el Cliente normal o empresa desean utilizar el
servicio.
2. Se establece una conexin con servidor.
3. Se realiza la solicitud de un nuevo usuario.
4. Se recibe el formulario de nueva Cuenta.
5. Se registra.
6. Se muestra primeras configuraciones.
Pos
condiciones
Flujos
Alternativos

25

Taller De Grado I

26

Taller De Grado I

UC 2)

Login

Caso de Uso
Login
Breve
Descripcin
Define un punto de login para poder sincronizar datos con el
servidor.
Actores
Principales
Usuario, Empresa
Actores
Secundarios
Ninguno
Precondiciones
Ninguno
Flujo Principal
1. Inicia cuando el usuario requiere su User, y Password.
2. Se establece una conexin con servidor.
3. Se realiza la sincronizacin y visualizacin de datos.
Pos
condiciones

Flujos
Alternativos
Puede Acceder en modo No Conectado desde la aplicacin Movil.

27

Taller De Grado I

28

Taller De Grado I

UC 3)

Gestionar Perfil

Caso de Uso
Gestionar Perfil
3
Breve
Descripcin
Define un perfil de usuario para que sea visto por las empresas, o lo
que mostrara el usuario cuando se asocie a otra agenda.
Actores
Principales
Usuario
Actores
Secundarios
Ninguno
Precondiciones
Ninguno
Flujo Principal
1. Inicia cuando el usuario requiere modificar los datos
personales.
2. Se establece una conexin con servidor.
3. Se realiza el cambio de perfil.
Pos
condiciones
Flujos
Alternativos

29

Taller De Grado I

30

Taller De Grado I

UC 4)

Gestionar Evento

Caso de Uso
Gestionar Evento
4
Breve
Descripcin
Define los eventos locales de la misma aplicacin, eventos que no
son compartidos con ninguna otra persona.
Actores
Principales
Usuario
Actores
Secundarios
Ninguno
Precondiciones
Ninguno
Flujo Principal
1. Inicia cuando el usuario requiere poner un evento, cita, en su
agenda.
2. Se escribe en el servidor el evento, o de manera local si esta
en modo no conectado.
3. Se recibe confirmacin de almacenado correctamente.
Pos
condiciones
Se podr modificar, postergar, los eventos creados.
Flujos
Alternativos

31

Taller De Grado I

32

Taller De Grado I

UC 5)

Publicar Evento

Caso de Uso
Publicar Evento
5
Breve
Descripcin
Define la creacin y publicacin de un evento a las personas
asociadas, a la agenda.
Actores
Principales
Empresa
Actores
Secundarios
Ninguno
Precondiciones
1. Crear Evento
2. Establecer conexin con el servidor.
Flujo Principal
1. Se selecciona el evento creado.
2. Selecciona a quienes se va a compartir el evento.
3. Se realiza el envi del evento, a ser publicado.
4. Se recibe confirmacin de evento publicado.
5. Se establece una lista de usuarios que confirman el evento.
Pos
condiciones
Flujos
Alternativos

33

Taller De Grado I

UC 6)

Compartir Evento

Caso de Uso
Compartir Evento
6
Breve
Descripcin
Se Encarga de compartir un evento, a un determinado grupo de
usuario
Actores
Principales
Empresa
Actores
Secundarios
Ninguno
Precondiciones
1. Establecer conexin con el servidor
2. Evento este Seleccionado
Flujo Principal
1. Lista de usuarios a quienes puedo compartir.
2. Seleccin de usuarios para compartir.
3. Se enva el evento.
4. Se recibe confirmacin de datos enviados.
Pos
condiciones
Flujos
Alternativos

34

Taller De Grado I

UC 7)

Crear Evento

Caso de Uso

Definir Punto de Referencia para la

Bsqueda

Breve
Descripcin
Define la creacin de un evento pblico.
Actores
Principales
Empresa
Actores
Secundarios
Ninguno
Precondiciones
1. Establecer conexin con el servidor
Flujo Principal
1. Despliega un formulario de evento.
2. La empresa da la informacin del evento (Fecha, hora, lugar).
3. Se guarda el evento y enva los datos al servidor
Pos
condiciones
El servidor de dato comunicara el evento, si tuviera conexin.
Flujos
Alternativos
En el caso de no tener conexin quedara en una cola de espera
para ser publicado.

35

Taller De Grado I

36

Taller De Grado I

UC 8)

Eventos Pendientes

Caso de Uso
Eventos Pendientes
8
Breve
Descripcin
Se encargara todos los eventos nuevos, y pendientes de
confirmacin.
Actores
Principales
Usuario
Actores
Secundarios
Ninguno
Precondiciones
Ninguno
Flujo Principal
1. El sistema despliega una lista con todos los eventos nuevos, y
pendientes de confirmacin.
2. El usuario tiene la opcin de elegir un evento y dar la opcin
de confirmar o rechazar.
Pos
condiciones
Si se confirma un evento, cambia de estado.
Flujos
Alternativos

37

Taller De Grado I

38

Taller De Grado I

UC 9)

Ver Eventos

Caso de Uso
Breve
Descripcin

Ver Eventos

Desplegara todos los eventos confirmados, en forma de lista.

Actores
Principales
Usuario
Actores
Secundarios
Ninguno
Precondiciones
Ninguno
Flujo Principal
1. Visualiza en forma de lista todos los eventos, propios del
usuario.
2. El usuario puede seleccionar un evento y ver el detalle del
evento.
Pos
condiciones
Flujos
Alternativos

39

Taller De Grado I

40

Taller De Grado I

UC 10)

Notificar Eventos

Caso de Uso
Notificar Eventos
10
Breve
Descripcin
Emite alertas de que un evento est por ser realizado, o que ha
llegado un nuevo evento.
Actores
Principales
Agenda
Actores
Secundarios
Precondiciones
Ninguno
Flujo Principal
1. Desplegara una pantalla para mostrar un detalle del evento
que se est por realizar.
2. Tendr la opcin de reproduccin automtica del evento.
Pos
condiciones
Flujos
Alternativos

41

Taller De Grado I

42

Taller De Grado I

UC 11)

Ver Confirmados

Caso de Uso
Ver Confirmados
15
Breve
Descripcin
Muestra una lista de todos los perfiles de los usuarios que han
confirmado a una reunin organizada anterior mente, o que se est
organizando.
Actores
Principales
Empresa
Actores
Secundarios
Ninguno
Precondiciones
1. Establecer conexin con el servidor
Flujo Principal
1. Muestra una lista de usuarios que han confirmado la
asistencia a la reunin.
2. Muestra una lista de usuarios q faltan confirmar asistencia.
Pos
condiciones
Flujos
Alternativos

43

Taller De Grado I

UC 12)

Verificar Conexin

Caso de Uso
Verificar Conexin
16
Breve
Descripcin
Indica si existe conexin o esta trabajndose en modo no conectado
desde el celular.
Actores
Principales
Usuario
Actores
Secundarios
Ninguno
Precondiciones
Ninguno
Flujo Principal
1. Si el sistema no tiene conexin, entrara en modo no
conectado, almacenando en forma local las nuevas
citas, creadas por el usuario.
Pos
condiciones
Flujos
Alternativos

44

Taller De Grado I

4.6.

MODELO DE CASOS DE USO.

45

Taller De Grado I

CAPITULO 5
FLUJO DE TRABAJO:
ANALISIS
Resumen
En este captulo explicaremos acerca de la
especificacin de los requisitos funcionales y no
funcionales del sistema, generando un modelo de
casos de uso.

46

Taller De Grado I

5.1.

ANALISIS DE ARQUITECTURA

5.1.1.

IDENTIFICAR PAQUETES DE ANALISIS

5.1.2.

DESCRIBIR PAQUETES

Package 1.

Manage Events.- El propsito de este paquete es el de manejar los

eventos, y para ser notificados, segn la configuracin hecha.

Package 2. Manage Calendar.- El propsito de este paquete es de mostrar
grficamente en un calendario las notas, citas y reuniones, para el da, o distintos
das.
Package 3.

Manage Data.- El propsito de este paquete es de guardar todos los

datos que se registren en el mvil.

Package 4. Manage Users.- El propsito de este paquete es de controlar el
acceso a las agendas mediante accediendo por un login, para ver los datos desde
el mvil.
47

Taller De Grado I

Package 5.

Web Service.- Contiene todos los servicios Web, y la comunicacin

con los datos del servidor de datos.

5.1.3.

VISTA EXTERNA DE PAQUETE

Package 1.

Manage Events.-

48

Taller De Grado I

Package 2.

Manage Calendar.-

Package 3.

Manage Data.-

49

Taller De Grado I

Package 4.

Manage Users.-

Package 5.

Web Service

50

Taller De Grado I

5.2.

ANALIZAR CASOS DE USO

UC 1)

Crear Cuenta

51

Taller De Grado I

UC 2)

Login`

Web Service

52

Taller De Grado I

UC 3)

Gestionar Perfil

Web Service

53

Taller De Grado I

UC 4)

Gestionar Evento

Web Service

54

Taller De Grado I

UC 5)

Publicar Evento

Web Service

UC 6)

Compartir Evento

Web Service

55

Taller De Grado I

UC 7)

Crear Evento

Web Service

56

Taller De Grado I

UC 8)

Eventos Pendientes

Web Service

UC 9)

Ver Eventos

Web Service

57

Taller De Grado I

UC 10)

Notificar Eventos

58

Taller De Grado I

UC 11)

Ver Confirmados

Web Service

UC 12)

Verificar Conexin

59

Taller De Grado I

CAPITULO 6
FLUJO DE TRABAJO:
DISENO
Resumen
En este captulo explicaremos acerca de la
especificacin del diseo de la arquitectura del
software.

60

Taller De Grado I

6.1.

ANALISIS CLASES

6.1.1.

ARQUITECTURA LOGICA

61

Taller De Grado I

6.1.2.

DISENO DE LA ARQUITECTURA FISICA

62

Taller De Grado I

6.1.3.

DISENO DE CASOS DE USO

UC 1)

Crear Cuenta

63

Taller De Grado I

64

Taller De Grado I

UC 2)

Login

65

Taller De Grado I

UC 3)

Gestionar Perfil
66

Taller De Grado I

UC 4)

Gestionar Evento
67

Taller De Grado I

68

Taller De Grado I

69

Taller De Grado I

70

Taller De Grado I

71

Taller De Grado I

72

:WSAgenda

73

(from Actors)

:T rue

[l i stAgenda.si ze]

loop share Ev ents

:T bEstado

:T bAgenda

save()

:Hi bernateUtil

getSessionFactory() :Sessi onFactory

getSessionFactory() :Sessi onFactory

getSessi onFactory() :SessionFactory

agendaeventos= T bAgendaeventos(T bAgenda, T bEstado, T bEvento, T bConfi guraci ones)

l i stAgenda= getAgendasForSi ndi cato(i nt) :Li st<T bAgenda>

agenda= T bAgenda()

estado= i sEstado(i nt)

estado= T bEstado()

getSessi onFactory() :Sessi onFactory

getSessi onFactory() :Sessi onFactory

:T bAgendaeventos

UC 5)

confi guraci on= i sConfi guraci on(i nt)

:T bConfi guraci ones

confi guraci on= T bConfi guraci ones()

evento= i sEvento(i nt)

:T bEvento
evento= T bEvento()

shareEventForSindi cato(i nt, i nt, Stri ng) :bool ean

usuario

sd Interaction

Taller De Grado I

Publicar Evento

74

(from Actors)

:resp

resp= encode()

save()

:T bPersona

:T bEvento

agendaeventos= T bAgendaeventos()

i sAgenda(i nt)

agenda= T bAgenda()

persona= i sPersona(int)

persona= T bPersona()

evento= i sEvento(i nt) :T bEvento

evento= T bEvento()

:T bEstado

:T bAgendaeventos

:T bAgenda

UC 6)

estado= i sEstado(i nt) :T bEstado

estado= T bEstado()

confi guraci on= i sConfi guraci on(i nt) :T bConfi guraciones

:T bConfi guraciones
confi guraci on= T bConfiguraci ones()

:WSAgenda

shareEventForUser(int, i nt, String) :Stri ng

usuario

sd Interaction

Taller De Grado I

Compartir Evento

Taller De Grado I

UC 7)

Crear Evento

75

Taller De Grado I

UC 8)

Eventos Pendientes

76

Taller De Grado I

UC 9)

Ver Eventos

77

:WSAgenda

78

T bAgenda()

:T bAgenda

send()

M ai l (Stri ng, Stri ng, Stri ng)

T bPersona()

personLi st= getAgendasForSi ndi cato(i nt) :Li st<T bAgenda>

loop GetAllPersonForSindicato
[l i st.si ze]

:T bConfi guraci ones

i sConfi guraci on(i nt) :T bConfi guraci ones

T bConfi guraci ones()

:T bPersona

:M ai l

UC 10)

(from Actors)

:T bEvento

i sEvento(i nt) :T bEvento

T bEvento()

shareEventForSi ndi cato(i nt, i nt, Stri ng) :bool ean

usuari o

sd Secuencia

Taller De Grado I

Notificar Eventos

Taller De Grado I

UC 11)

Ver Confirmados

UC 12)

Verificar Conexin

79

Taller De Grado I

6.1.4. DISENO DE CLASE

UC 1)

Crear Cuenta

80

Taller De Grado I

UC 2)

Login`

81

Taller De Grado I

Web Service Login

82

Taller De Grado I

UC 3)

Gestionar Perfil

83

negocio::WSPersona

password: string
tbPersonas: Set<T bPersona>

+ getPassword() : string

+ getLogin() : string

+ getId() : integer

+ session: Session

login: string

datos::TbUsuario
i d: integer

+ isUsuarioLogi n(string) : T bUsuario

+ updPerson(int, string, string, int, int, string, int) : string

84

ci: int
email: string
id: Integer
nombre: string
tbAgendas: Set<T bAgenda>
tbSi ndicato: T bSi ndicato
tbUsuario: T bUsuario
telefonocelular: integer
telefonofijo: integer

datos::TbPersona

+ update() : void

+ T bPersona(Set<T bAgenda>, i nteger, integer, string, string, string, i nt, T bSindicato, T bUsuario) : void

+ T bPersona(string, string, int, T bSindicato) : voi d

+ T bPersona() : void

+ setT el efonofijo(integer) : voi d

+ setT elefonocelular(integer) : void

+ setT bUsuario(T bUsuario) : void

+ setT bSindicato(T bSi ndicato) : void

+ setT bAgendas(Set<T bAgenda>) : voi d

+ setNombre(string) : void

+ setId(integer) : void

+ setEm ail(string) : void

+ setCi(int) : void

+ setApellidos(string) : void

+ save() : T bPersona

+ isPersona(int) : T bPersona

+ getT elefonofijo() : integer

+ getT elefonocelular() : integer

+ getT bUsuario() : T bUsuario

+ getT bSi ndicato() : T bSindicato

+ getT bAgendas() : Set<T bAgenda>

+ getPersona(int) : T bPersona

+ getNom bre() : string

+ getId() : integer

+ getEmail() : string

+ getCi() : int

+ getApellidos() : string

+ sessi on: Session

apellidos: string

+ update() : void

+ T bUsuario(string, string, Set<T bPersona> ) : void

+ T bUsuario(string, string) : voi d

+ T bUsuari o() : void

+ setT bPersonas(Set<T bPersona>) : void

+ setPassword(string) : void

+ setLogin(string) : void

+ setId(Integer) : void

+ save() : T bUsuario

+ i sUsuario(integer) : T bUsuario

+ isPerson(int) : boolean

+ addPerson(string, string, int, int, int, string, int, int) : string + getT bPersonas() : Set<T bPersona>
+ isUsuario(string, strng) : T bUsuari o
+ exi stCnx() : boolean

class Perfil

cnx::HibernateUtil

getSigla() : string
getT bPersonas() : Set<T bPersona>
getT bSindicato() : T bSindicato
getT bSindicatos() : Set<T bSindicato>
isSindicato(string, string, int) : T bSindi cato
save() : T bSindicato
setId(i nteger) : void
setNombre(string) : void
setSigla(string) : void
setT bPersonas(Set<T bPersona>) : void
setT bSindicato(T bSindicato) : void
setT bSindi catos(Set<T bSindicato>) : void
T bSindicato() : void
T bSindicato(string) : void
T bSindicato(T bSindicato, string, string, Set<T bSindicato>, Set<T bPersona>) : void
update() : void

+
+
+
+
+
+
+
+
+
+
+
+
+
+

session: Session

getNombre() : string

tbSindicatos: Set<T bSindi cato>

tbSindi cato: T bSindi cato

getId() : integer

tbPersonas: Set<T bPersona>

sigl a: string

nombre: string

i d: integer

datos::TbSindicato

getSessionFactory() : SessionFactory

sessionFactory: SessionFactory

Taller De Grado I

Web Service Perfil

Taller De Grado I

UC 4)

Gestionar Evento

85

Taller De Grado I

UC 5)

Publicar Evento

86

Taller De Grado I

UC 6)

Compartir Evento

87

Taller De Grado I

UC 7)

Crear Evento

88

Taller De Grado I

UC 8)

Eventos Pendientes

89

Taller De Grado I

UC 9)

Ver Eventos

90

Taller De Grado I

UC 10)

Notificar Eventos

91

Taller De Grado I

UC 11)

Ver Confirmados

92

Taller De Grado I

UC 12)

Verificar Conexin

93

Taller De Grado I

6.2.

DIAGRAMA DE CLASES GENERAL

Diagrama para el Almacenamiento de Dato

94

Taller De Grado I

Diagrama Framework Patrn de Comportamiento MVC

95

Taller De Grado I

6.3.

ANALIZAR PAQUETES

6.3.1.

DEPENDENCIA DE PAQUETE

96

Taller De Grado I

CONCLUCIONES
Durante el desarrollo de este software se ha encontrado problemas como por ejemplo la
persistencia de datos, en la cual J2ME no tiene soporte para Sqlite, donde hemos tenido que
aprender otras formas diferentes de persistencia de datos, usando estndares en la estructura de
datos como JSON, para mantener la estructura de los datos, donde la comunicacin de datos con un
servidor es algo critico, se tiene que tener estructuras fciles de manipular y que no ocupen muchos
datos, solamente las suficientes.
Hemos concluido con el software siguiendo conceptos de SOAP Arquitectura Orientada a
Servicios para la comunicacin del telfono con el servidor, y conceptos de Desarrollo de Software
Basado en Componentes, para futuras actualizaciones que as necesitasen.

RECOMENDACIONES
Antes de empezar a realizar una aplicacin en J2ME se defina una capa de persistencia de
datos, ya que no hay forma de manejar relaciones entre datos, porque solo maneja almacenamiento
en registros de memoria.
Aprender sobre el uso de la Api de bajo nivel, como Canvas, para el desarrollo de
interfaces, puesto que J2ME no ofrece muchas opciones al momento de disear interfaces.
Aplicar patrones de diseo para definir la arquitectura que soporte al software, y tener una
facilidad al momento de aplicar correcciones o actualizaciones al software.

97

Taller De Grado I

BIBLIOGRAFIA
4lex, garcia, A. I., Arcoe, Bernard, BetoCG, Caos, y otros. (2 de mayo de 2012). Wikipedia
Enciclopedia Libre. Recuperado el 3 de mayo de 2012, de Wikipedia Enciclopedia Libre:
http://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida
Airunp, Armando-Martin, BlackBeast, Cobalttempest, Correogsk, Javierito92, y otros. (abril de
2012). Wikipedia Enciclopedia Libre. Recuperado el 1 de mayo de 2012, de wikipedia:
http://es.wikipedia.org/wiki/Agenda_(reuni%C3%B3n)
AlbertoDV, Alhen, Pramo, A., Arciei, maguina, A., Baiji, y otros. (29 de mayo de 2012). Wikipedia
Enciclopedia Libre. Recuperado el 1 de 5 de 2012, de Wikipedia Enciclopedia Libre:
http://es.wikipedia.org/wiki/Agenda_electr%C3%B3nica
Ivar, J., Grady, B., & James, R. (2000). El Proceso Unificado de Desarrollo de Software.
Oracle. (s.f.). Acerca de Java Micro Edition. Recuperado el 14 de 6 de 2012, de Sitio Web de Oracle
: http://www.java.com/es/download/faq/whatis_j2me.xml
Trujillo, M. (21 de Mayo de 2010). Blogspot E-SOA. Recuperado el 1 de Mayo de 2012, de
Blogspot E-SOA: http://mauriciotrujillointranets.blogspot.com/2010/03/e-soa.html.

98

Taller De Grado I

ANEXOS.
Esquema grafico de la situacin problemtica

99

Taller De Grado I

Esquema grafico de la situacin deseada

100