solució global per la gestió de dades d’empleat mitjançant

Memòria. TFC-J2ME/J2EE. UOC. 2005/02. Natalie Moraes

Pàgina 1

Solució global per la gestió de dades d’empleat mitjançant J2ME/J2EE. Anàlisi, disseny i implementació. Natalie Moraes Münter ETIG / ETIS Consultor: Abel Almazán 16/06/2006


Pàgina 2

Agraïments:

Gràcies a totes aquelles persones que m’han acompanyat durant la carrera, si avui estic aquí en part és gràcies a tots vosaltres, als vostres consells, als vostres ànims, a la vostra amistat.

Molt especialment, gràcies a Abel Almazán, per la seva paciència i els seus consells en la realització d’aquest TFC.


Pàgina 3

Resum.

Aquest treball final de carrera es basa en l’anàlisi, disseny i implementació d’una solució per comunicar un empleat i la seva empresa per tal de gestionar informació i dades de l’empleat com poden ser: la nòmina, el full d’hores, el full de despeses i la consulta i sol·licitud de vacances.

Es tracta d’un projecte d’aplicació real. Tot i que inicialment s’hagués pensat en enfocar-ho a comercials d’una empresa farmacèutica, gràcies a la seva generalització seria fàcilment aplicable a altre tipus d’empresa. Proposem el desenvolupament d’una solució molt útil per empreses que disposin de treballadors amb molta mobilitat i que els hi vulguin oferir una eina còmode per tal de facilitar la gestió d’aquest tipus de dades i no interferir en el rendiment del seu treball.

Actualment la tecnologia mòbil avança a passos agegantats, per la qual cosa és absurd desenvolupar una aplicació exclusivament per un model o sistema operatiu. Aquesta és, la principal raó per la qual la implementació s’ha basat en el llenguatge Java. Java disposa d’una plataforma exclusiva per dispositius mòbils: J2ME (Java 2 Micro Edition) que tot i tenir certes carències és multiplataforma i no lliga l’aplicació a cap model de dispositiu mòbil concret. Per de fer possibles els requeriments funcionals i mantenir la portabilitat de tota la solució serà necessari l’ús de l’arquitectura J2EE per la part del servidor i la intranet.

L’anàlisi i disseny del projecte s’ha basat sota el paradigma de la programació orientada a objectes procurant seguir el cicle de vida del Rational Unified Proces(RUP).


Pàgina 4

1. Índex.

1. Índex. ..........................................................................................................4 2. INTRODUCCIÓ. ..........................................................................................5

2.1 Justificació del TFC: punt de partida i aportació. 5 2.2 Objectius del TFC. 6 2.3 Enfocament i mètode seguit. 6 2.4 Planificació del projecte. 7 2.5 Productes obtinguts 9 2.6 Descripció dels capítols següents 9

3. ESPECIFICACIÓ I ANÀLISI DELS REQUERIMENTS ..............................10 3.1 Descripció 10 3.2 Requeriments funcionals. 12 3.2.1 Subsistema principal 13 3.2.2 Subsistema de gestió de nòmines 16 3.2.3 Subsistema de gestió de vacances 17 3.2.4 Subsistema de gestió d’hores 20 3.2.5 Subsistema de gestió de despeses 24 3.2.6 Subsistema de sincronització 28 3.3 Seguretat. 30 3.4 Funcionalitats de les properes versions. 30 3.5 Interfície gràfica 31 3.5.1 Subsistema principal 32 3.5.2 Subsistema de sol·licitud de nòmines 35 3.5.3 Subsistema de gestió de vacances 36 3.5.4 Subsistema de gestió d’hores 39 3.5.5 Subsistema de gestió de despeses 41 3.5.6 Subsistema d’alertes 43 3.5.7 Subsistema de sincronització 45

4. DISSENY.....................................................................................................46 4.1 Introducció 46 4.2 Java 2 Enterprise Edition(J2EE) 46 4.3 Java 2 Mobile Edition(J2ME) 49 4.4 XML 50 4.5 Disseny de l’arquitectura 51 4.6 Disseny de la base de dades 52 4.7 Model ER 53 4.8 Model lògic 54 4.9 Descripció de les taules 55 4.9.1 Taula Agent 55 4.9.2 Taula SolVacances 56 4.9.3 Taula Nòmina 56 4.9.4 Taula CabDespeses 57 4.9.5 Taula linDespesa 57 4.9.6 Taula tipusDespesa 58 4.9.7 Taula cabHores 58 4.9.8 Taula linHores 59 4.9.9 Taula tipusDia 59 4.9.10 Taula Responsables 59 4.9.11 Taula Alertes 60 4.10 Diagrama estàtic de disseny: classes i jerarquies 61 Diagrama de classes de l’aplicació IntraChronos 61 Diagrama de classes de l’aplicació ChronosMobile 62 4.11 Descripció de les comunicacions 63

5. IMPLEMENTACIÓ. .....................................................................................65 5.1 Requisits del maquinari i programari 65

6. Valoració econòmica. ...............................................................................65 7. Conclusions. ..............................................................................................66 8. Glossari. .....................................................................................................67 9. Bibliografia consultada.............................................................................68


Pàgina 5

2. INTRODUCCIÓ.

2.1 Justificació del TFC: punt de partida i aportació.

Aquest TFC parteix de la necessitat de desenvolupar una aplicació per dispositius mòbils en J2ME que interactuï amb la tecnologia J2EE.

Com a qualsevol TFC, l’objectiu principal d’aquest és mostrar l’assoliment de l’aprenentatge que s’ha dut a terme al llarg dels estudis d' Enginyeria Tècnica en Informàtica, analitzant un problema complex de tipus pràctic transformant-lo en un projecte informàtic, elaborant un pla de treball i treballant els aspectes formals en l’anàlisi, disseny y desenvolupament.

El punt de partida són doncs els coneixements adquirits durant la carrera, han estat especialment útils els coneixements adquirits en assignatures com programació orientada a objectes, estructura de la informació, enginyeria del programari, base de dades I base de dades II. Tot i que aquestes assignatures proporcionen una bona base conceptual i casos pràctics molt bàsics, era necessari aprendre el funcionament de tecnologies Java com són els servlets, els JSP’s, JDBC, els midlets, la implementació del patró MVC, XML, J2ME...

L’aportació característica d’aquest TFC és la interacció entre J2ME i J2EE per tal d’oferir una solució global de caire empresarial..


Pàgina 6

2.2 Objectius del TFC.

Els principals objectius del TFC han estat l’anàlisi, disseny i implementació d’una solució empresarial basada en dues aplicacions:

• ChronosMobile: aplicació per dispositius mòbils, mitjançant la tecnologia J2ME/J2EE.

• IntraChronos: aplicació web, mitjançant la tecnologia J2EE.

Durant la planificació inicial es van marcar uns objectius massa ambiciosos pel temps que es proporciona per la realització del TFC. De les fites establertes inicialment s’han assolit amb èxit, l’anàlisi i disseny de les dues aplicacions i la implementació de la primera. Tot i així, l’anàlisi i disseny especificat en aquest document facilita futures implementacions.

2.3 Enfocament i mètode seguit.

L’enfocament utilitzat en el desenvolupament del TFC ha estat treballar en paral·lel diversos aspectes. Per una banda realitzar l’anàlisi i disseny de l’aplicació mitjançant el paradigma de l’orientació a objectes. Però per una altra augmentar el coneixement de gran part de les tecnologies relacionades amb J2EE i J2ME.

Les principals dificultats han estat la instal·lació i configuració de tot el programari necessari i la gran quantitat de coneixement a adquirir en tan poc temps per aplicar-ho en un projecte real.


Pàgina 7

2.4 Planificació del projecte.

A continuació presentem la planificació inicial. Tot i que s’han respectat totes les dates d’entrega no ha estat possible fer sempre una preentrega de les PAC’s.

El temps dedicat finalment a cada una de les fases del desenvolupament d’aquest treball de carrera han estat aproximadament:

Recollida de requisits 5 dies

Anàlisi 17 dies

Disseny 12 dies

Implementació + prova 40 dies

Memòria i presentació 15 dies


Pàgina 8


Pàgina 9

2.5 Productes obtinguts

El producte obtingut en la implementació d’aquest projecte podem descompondre-ho en els següent elements:

fitxer instal·lable pels dispositius mòbils ChronosMobile.prc ( o .jar)

fitxer .war amb el servlets de l’aplicació ChronosMobile, CMServlet.war.

el codi font de totes les classes utilitzades

Documentació detallada i normalitzada en format javadoc de totes les classes

Els fitxers de desplegament i de configuració utilitzats, conjuntament amb les llibreries necessàries pel seu funcionament.

El fitxers de creació de les taules i la inserció de dades necessàries a la BD de prova.

Una demostració en format .mpg del funcionament de l’aplicació ChronosMobile.

2.6 Descripció dels capítols següents

En la resta de capítols de la memòria es comentaran les fases d’anàlisi, disseny i implementació per les quals ha passat el desenvolupament d’aquest TFC.


Pàgina 10

3. ESPECIFICACIÓ I ANÀLISI DELS REQUERIMENTS

3.1 Descripció

L’empresa farmacèutica UOC-Pharma ens ha demanat una eina per gestionar la informació de RRHH dels seus treballadors. Aquesta eina ha de facilitar la gestió de dades com són els fulls de despeses, els fulls d’hores, les nòmines i les vacances. L’empresa considera important que aquestes gestions no afectin al rendiment dels seus treballadors, per la qual cosa vol posar a les mans dels seus treballadors una eina fàcil i còmode d’utilitzar.

La solució proposada consta de dues aplicacions:

o ChronosMobile: Aplicació pels terminals mòbils que permetrà als comercials la connexió amb un servidor per enviar i obtenir la informació necessària.

o IntraChronos: Aplicació web (intranet) que permetrà als responsables gestionar les dades proporcionades pel ChronosMobile.

Podem distingir per tant dos actors, un per cada una de les aplicacions i aquest són els respectius guions:

Comercial: Quan un comercial encén l’aplicació ChronosMobile s’haurà d’autenticar per tal de que les seves dades quedin protegides. A continuació se li ofereix la possibilitat de escollir entre les següents opcions:

• Consulta de la nòmina • Consulta i/o sol·licitud de vacances • Introduir hores • Introduir despeses • Llegir alertes • Sincronitzar dades

Responsables: Quan un responsable accedeix a la IntraChronos s’haurà d’autenticar per tal de carregar les seves dades i que aquestes quedin protegides. . A continuació se li ofereix la possibilitat de escollir entre les següents opcions:

• Validar Vacances • Validar despeses • Validar hores • Introduir alertes • Sincronitzar dades


Pàgina 11

El següent esquema ens mostra el funcionament de la solució proposada:


Pàgina 12

3.2 Requeriments funcionals.

Segons els requeriments de les aplicacions podem diferenciar els següents subsistemes, tant per el ChronosMobile, com per la IntraChronos:

• Subsistema principal: A les dos aplicacions, és l’encarregat de la autenticació dels usuaris i de la gestió de la pantalla principal. S’encarrega d’entrar i sortir del programa.

• Subsistema de gestió de nòmines: Aquest subsistema només el considerarem al ChronosMobile. Permet a l’usuari consultar les dades més rellevants de la seva nòmina. Suposarem que un altre aplicació s’encarrega de la introducció de dades de la nòmina a la base de dades

• Subsistema de gestió de vacances: En la aplicació mòbil proporciona als comercials una forma còmode i ràpida de consultar i sol·licitar les seves vacances. A la Intranet els responsables seran els encarregats de validar les sol·licituds.

• Subsistema de gestió d’hores: Al ChronosMobile permet a l’usuari introduir les hores i enviar-les a qualsevol hora i en qualsevol lloc( on tinguin cobertura). En el cas de la IntraChronos proporcionarà als responsables una eina amb la qual poder validar o denegar les dades introduïdes en el subsistema de gestió d’hores de l’aplicació mòbil.

• Subsistema de gestió de despeses: Al ChronosMobile permet a l’usuari introduir les despeses i enviar-les a qualsevol hora i en qualsevol lloc( on tinguin cobertura). En el cas de la IntraChronos proporcionarà als responsables una eina amb la qual poder validar o denegar les dades introduïdes en el subsistema de gestió de despeses de l’aplicació mòbil.

• Subsistema d’alertes: Proporciona una via de comunicació des de el departament de RRHH i els responsables cap als seus comercials. La IntraChronos envia i el ChronosMobile només rep.

• Subsistema de sincronització: És l’encarregat d’enviar les dades introduïdes pels comercials i de rebre les dades que estan disponibles a la base de dades.


Pàgina 13

3.2.1 Subsistema principal

Com ja hem comentat, el subsistema principal és l’encarregat de entrar i sortir del programa i del procés d’autenticació. D’aquesta manera observem que tan per l’aplicació ChronosMobile com per la IntraChronos tenim casos d’ús molt similars.


Pàgina 14

A continuació presentarem detalladament cada un dels casos d’ús.

Cas d’ús: Iniciar Chronos Mobile

Resum Correspon a l’inici de la aplicació des de el sistema operatiu

Paper Principal

Actors Comercial

Casos d’ús relacionats

Autenticació

Precondició -

Postcondició L’usuari es troba amb el menú principal des de el qual pot accedir a totes les opcions de l’aplicació.

Descripció A l’iniciar l’aplicació es mostra una pantalla d’autentificació on l’usuari haurà d’introduir la seva contrasenya. Si la contrasenya introduïda és correcta apareix una pantalla de presentació, mentre es van carregant les dades des de el RMS. A continuació apareix el menú principal amb totes les seves opcions.

Cas d’ús: Autenticació

Resum Permet a l’usuari l'autenticació per tal d’accedir a l’aplicació.

Paper Apareix cada cop que s’arranca l’aplicació

Actors Comercial


-

Precondició L’usuari coneix el seu password.

Postcondició L’usuari ha introduït el seu password.

Descripció Apareix una pantalla amb el codi de l’agent i permet introduir la contrasenya. En cas de que s’introdueixi la contrasenya incorrecta apareix un missatge informant a l’usuari i suggerint-li que si no se’n recorda de la seva contrasenya que es posi en contacte amb el departament de sistemes.


Pàgina 15

Cas d’ús: Iniciar IntraChronos

Resum Correspon a l’inici de la aplicació des de el sistema operatiu.

Paper Principal

Actors Responsable


Autenticació

Precondició -


Descripció A l’iniciar l’aplicació es mostra una pantalla d’autentificació on l’usuari haurà d’introduir el seu usuari i la seva contrasenya. Si la contrasenya introduïda és correcta apareix una pantalla de presentació i es carreguen les dades segons l’usuari. A continuació apareix el menú principal amb totes les seves opcions.

Cas d’ús: Autenticació

Resum Permet a l’usuari autenticar-se per tal d’accedir a l’aplicació.

Paper Es produeix cada cop que s’arranca l’aplicació

Actors Responsable


-

Precondició L’usuari coneix el seu username i el seu password.

Postcondició L’usuari ha introduït correctament el nom d’usuari i el seu corresponent password.

Descripció Apareix una pantalla on ens demanen l’usuari i contrasenya. Si la autentificació és incorrecta s’informarà a l’usuari donant-li la oportunitat de tornar a intentar-ho o sortir.


Pàgina 16

3.2.2 Subsistema de gestió de nòmines

Aquest es el subsistema que permet al comercial consultar les dades de les seves nòmines. L’aplicació IntraChronos no treballa sobre aquest subsistema.

Cas d’ús: Sol·licitar Nòmina

Resum Permet a l’usuari consultar les dades de la nòmina.

Paper Ho faran servir aproximadament un cop al mes.

Actors Responsable


-

Precondició -


Descripció Un cop introduït el mes i l’any del qual es vol la nòmina es comprova que no hi sigui en local. Si hi és s’agafen les dades i es mostren per pantalla. Sinó mitjançant una connexió http es fa la petició al servidor i aquest envia les dades en un xml. Un cop al dispositiu es mostren les dades per pantalla. Abans de sortir d’aquest cas d’us existeix la possibilitat de guardar les dades de la nòmina en local, per tal de poder consultar-la sense la necessitat de connectar-se. Com a molt es guardaran les últimes 12 nòmines.


Pàgina 17

3.2.3 Subsistema de gestió de vacances

En aquest subsistema podem observar un actor per cada una de les aplicacions i permet als comercials sol·licitar vacances i consultar quants dies s’han gastat i quants dies queden disponibles. Els responsables s’encarregaran de validar o no les sol·licituds.


Pàgina 18

Cas d’ús: Sol·licitar Vacances

Resum Permet als comercials fer sol·licituds de vacances.

Paper Ho faran servir ocasionalment per tal de planificar les seves vacances.

Actors Comercial


Consulta Vacances

Precondició Al comercial li queden dies disponibles per les vacances.

Postcondició L’usuari ha fet una sol·licitud de vacances que serà enviada amb el subsistema de sincronització.

Descripció En cas de que la última consulta s’hagués fet en dies anteriors a l’actual es demana a l’usuari si desitja actualitzar les dades dels dies disponibles. En cas afirmatiu es realitza la consulta i un cop s’ha rebut la resposta es poden introduir les dates d’inici i fi per la sol·licitud de vacances. En cas negatiu s’accedeix directament a la pantalla per introduir la data d’inici i la data de fi. La sol·licitud serà enviada amb el subsistema de sincronització.

Cas d’ús: Consulta de Vacances

Resum S’encarrega de fer les consultes per saber els dies de vacances disponibles i els gastats.


Actors Comercial


-

Precondició Tenir connexió GPRS.

Postcondició L’usuari veu per pantalla els dies disposats i disponibles.

Descripció Es genera una petició cap al servidor i aquest torna la informació en format XML. Un cop arriba al dispositiu es mostra per pantalla i es guarda al RMS.


Pàgina 19

Cas d’ús: Consulta estat de les sol·licituds.

Resum Permet veure el estat de les sol·licituds.


Actors Comercial


-

Precondició Tenir sol·licituds

Postcondició L’usuari veu per pantalla un llistat de sol·licituds i el seu estat representat de forma gràfica.

Descripció Quan l’usuari entra en aquest apartat pot veure l’estat des de la última consulta i si ho desitja actualitzar les dades. Per això es genera una petició cap al servidor i aquest respon mitjançant un XML. Quan arriba al dispositiu s’actualitza la llista.

Cas d’ús: Aprovar/denegar de vacances

Resum Permet al responsable validar o no les sol·licituds de vacances dels seus comercials.

Paper Ho faran servir cada cop que quan entrin a l’aplicació hi hagi peticions de vacances pendents.

Actors Responsable


-

Precondició Hi ha sol·licituds de vacances pendents de confirmació.

Postcondició El responsable ha aprovat o denegat una sol·licitud de vacances.

Descripció Quan l’usuari entra en aquest apartat pot veure un llistat de les sol·licituds pendent d’aprovació. En accedir a una d’elles tindrà dos possibilitats, aprovar o denegar. Un cop presa la decisió, la sol·licitud desapareixerà del llistat.


Pàgina 20

3.2.4 Subsistema de gestió d’hores

Aquest subsistema permet als comercials crear una fulla d’hores, consultar les dades introduïdes( les que encara no han estat enviades), modificar-les o esborrar-les.

Als responsables els hi permet en la seva aplicació aprovar o denegar les hores enviades pels seus comercials.


Pàgina 21

Cas d’ús: Consultar hores

Resum Permet a l’usuari veure les hores introduïdes que encara no han estat enviades.

Paper Ho faran servir com a mínim un cop per setmana ja que cada divendres han d’enviar les hores.

Actors Comercial


Introduir hores, modificar hores, esborrar hores.

Precondició -

Postcondició L’usuari veu per pantalla una taula amb les hores introduïdes i a partir d’aquí te la possibilitat d’introduir, modificar o esborrar dades.

Descripció Quan l’usuari entra en aquest apartat si no té una taula creada es crea una buida. Si en té es mostren les dades per pantalla i és l’usuari el que decideix si vol introduir hores, modificar o esborrar alguna fila.

Cas d’ús: Introduir hores

Resum Permet a l’usuari introduir les hores treballades.

Paper Ho faran servir com a mínim un cop per setmana ja que cada divendres han d’enviar les hores.

Actors Comercial


-

Precondició -

Postcondició L’usuari ha introduït les hores i es veuran reflectides a la taula.

Descripció En entrar en aquesta opció apareix un formulari buit on l’usuari hi ha d’introduir una sèrie de dades. Un cop introduïdes accepta i les dades s’afegeixen a la fulla creada. No pot haver més d’una fulla en local. Un cop introduïdes totes les dades de la setmana, s’envien mitjançant el subsistema de sincronització i un cop enviat s’esborra del dispositiu mòbil.


Pàgina 22

Cas d’ús: Modificar Hores

Resum Permet modificar el detall de les hores introduïdes.

Paper Ho faran servir cada cop que necessitin modificar les dades introduïdes.

Actors Comercial


-

Precondició Tenir hores introduïdes

Postcondició L’usuari ha modificat el detall i això es veu reflectit a la taula.

Descripció L’usuari selecciona una fila de la taula, apareix un formulari amb les dades del detall i en modifica les dades. S’actualitza la taula per tal de que es vegin els canvis fets.

Cas d’ús: Borrar hores

Resum Permet esborrar files de la taula d’hores introduïdes.

Paper Ho faran servir cada cop que necessitin esborrar les dades introduïdes.

Actors Comercial


-

Precondició Tenir hores introduïdes

Postcondició L’usuari borra les files sel·leccionades i això es veu reflectit a la taula.

Descripció L’usuari selecciona una fila de la taula i selecciona la opció de esborrar hores. Després de preguntar-li si realment vol esborrar les hores sel·leccionades els canvis es veuran reflectits immediatament a la taula.


Pàgina 23

Cas d’ús: Validar hores

Resum Permet al responsable validar o no les hores dels seus comercials.

Paper Ho faran servir cada cop que quan entrin a l’aplicació hi hagi fulles d’hores pendents.

Actors Responsable


-

Precondició Hi ha fulles d’hores sense validar.

Postcondició El responsable aprova o denega la fulla d’hores.

Descripció Quan l’usuari entra en aquest apartat pot veure un llistat de les fulles pendents d’aprovació. En accedir a una d’elles tindrà dos possibilitats, aprovar o denegar. Si aprova se li notifica al comercial mitjançant el subsistema d’alertes. En aquest cas el responsable es posarà en contacte amb el comercial i després de parlar amb ell farà les modificacions pertinents.


Pàgina 24

3.2.5 Subsistema de gestió de despeses

Aquest subsistema permet als comercials crear una fulla de despeses, consultar les dades introduïdes( les que encara no han estat enviades), modificar-les o esborrar-les.

Als responsables els hi permet en la seva aplicació aprovar o denegar les despeses enviades pels seus comercials.


Pàgina 25

Cas d’ús: Consultar despeses

Resum Permet a l’usuari veure les despeses introduïdes que encara no han estat enviades.

Paper Cada cop que enviïn el full de despeses.

Actors Comercial


Introduir despeses, modificar despeses, esborrar despeses.

Precondició -

Postcondició L’usuari veu per pantalla una taula amb les despeses introduïdes i a partir d’aquí te la possibilitat d’introduir, modificar o esborrar dades.

Descripció Quan l’usuari entra en aquest apartat si no té una taula creada es crea una buida. Si en té es mostren les dades per pantalla i és l’usuari el que decideix si vol introduir hores, modificar o esborrar alguna fila.

Cas d’ús: Introduir despeses

Resum Permet a l’usuari introduir les seves despeses.

Paper Cada cop que enviïn el full de despeses.

Actors Comercial


-

Precondició -

Postcondició L’usuari ha introduït les despeses i es veuran reflectides a la taula.

Descripció En entrar en aquesta opció apareix un formulari buit on l’usuari hi ha d’introduir una sèrie de dades. Un cop introduïdes accepta i les dades s’afegeixen a la fulla creada. No pot haver més d’una fulla en local. Un cop introduïdes totes les dades, s’envien mitjançant el subsistema de sincronització i un cop enviat s’esborra del dispositiu mòbil.


Pàgina 26

Cas d’ús: Modificar despeses

Resum Permet modificar el detall de les despeses introduïdes.

Paper Ho faran servir cada cop que necessitin modificar les dades introduïdes.

Actors Comercial


-

Precondició Tenir despeses introduïdes

Postcondició L’usuari ha modificat el detall i això es veu reflectit a la taula.

Descripció L’usuari selecciona una fila de la taula, apareix un formulari amb les dades del detall de la despesa i en modifica les dades. S’actualitza la taula per tal de que es vegin els canvis fets.

Cas d’ús: Borrar despeses

Resum Permet esborrar files de la taula d’hores introduïdes.

Paper Ho faran servir cada cop que necessitin esborrar les dades introduïdes.

Actors Comercial


-

Precondició Tenir despeses introduïdes

Postcondició L’usuari borra les files sel·leccionades i això es veu reflectit a la taula.

Descripció L’usuari selecciona una fila de la taula i selecciona la opció de esborrar hores. Després de preguntar-li si realment vol esborrar les despeses sel·leccionades els canvis es veuran reflectits immediatament a la taula.


Pàgina 27

Cas d’ús: Validar despeses

Resum Permet al responsable validar o no les despeses dels seus comercials.

Paper Ho faran servir cada cop que quan entrin a l’aplicació hi hagi fulles d’hores pendents.

Actors Responsable


-

Precondició Hi ha fulles d’hores sense validar.

Postcondició El responsable aprova o denega la fulla de despeses.

Descripció Quan l’usuari entra en aquest apartat pot veure un llistat de les fulles de despeses pendents d’aprovació. En accedir a una d’elles tindrà dos possibilitats, aprovar o denegar. Si aprova se li notifica al comercial mitjançant el subsistema d’alertes. En cas contrari el responsable es posarà en contacte amb el comercial i després de parlar amb ell farà les modificacions pertinents.


Pàgina 28

3.2.6 Subsistema de sincronització

Aquest subsistema permet que comercial i responsable puguin sincronitzar les seves dades en les seves respectives aplicacions.


Pàgina 29

Cas d’ús: Sincronitzar

Resum Permet als comercials sincronitzar les dades de l’aplicació Chronos Mobile.

Paper Ho faran cada cop que vulguin actualitzar les seves dades.

Actors Comercial


-

Precondició -

Postcondició El comercial ha enviat les dades introduïdes i al dispositiu s’han rebut totes les dades que el servidor tenia preparat per ell.

Descripció Quan l’usuari entra en aquest apartat pot veure un llistat de les dades disponibles per sincronitzar de dispositiu cap a servidor i pot sel·leccionar quines dades vol enviar en aquell moment, lo q no pot determinar són les dades a rebre.

Cas d’ús: Sincronitzar

Resum Permet als responsables sincronitzar les dades de l’aplicació IntraChronos.

Paper Es farà automàticament cada cop que s’accedeixi a l’aplicació.

Actors Responsable


-

Precondició -

Postcondició El responsable pot visualitzar les noves tasques pendents, si es que n’hi ha.

Descripció Quan l’usuari entra a l’aplicació les dades es sincronitzen automàticament.


Pàgina 30

3.3 Seguretat.

La seguretat d’accés fa referència a les mesures necessàries per garantir el correcte accés al sistema. Com que es tracta d’una aplicació J2EE i una J2ME tenim la seguretat que es deriva de les característiques de les classes fonamentals de Java. Per exemple, tenim les mesures de seguretat que imposa la JVM, la qual verifica totes les classes abans de carregar-les.

Tot i que s’ha plantejat la implementació de la Intranet amb un sistema d’autenticació bàsic mitjançant el servidor verifica l’usuari i la seva clau, seria més segur enviar les dades mitjançant SSL.

Caldrà definir un time-out ( un temps màxim de treball amb una sessió), per evitar que un usuari deixés accidentalment oberta una connexió amb la possibilitat que es produís un accés no autoritzat.

Per protegir les dades de l’aplicació mòbil l’usuari ha d’introduir el seu usuari i contrasenya a l’inici de la sessió. Queda com a millora de l’aplicació implementar un sistema més segur.

3.4 Funcionalitats de les properes versions.

Aquesta solució pot oferir un munt de noves funcionalitats tot depenent de les necessitats de la empresa. Oferim a continuació una series de aspectes que poden ser inclosos en properes versions:

ChronosMobile:

Consultes de les hores introduïdes ja sincronitzades. Guardant-les a la base de dades o mitjançant consultes al servidor.

Consultes de les despeses introduïdes ja sincronitzades. Guardant-les a la base de dades o mitjançant consultes al servidor.

Automatitzar les actualitzacions de les noves versions de l’aplicació.

Incorporar un sistema més segur d’autenticació.

Interfície gràfica configurable per l’usuari.

Afegir més funcionalitats com poden ser, gestió de la formació, comunicació de comercial a responsable...


Pàgina 31

IntraChronos:

Automatitzar el sistema de pagament de les despeses aprovades.

Incorporar un nivell de seguretat SSL (Secure Sockets Layer) al sistema.

Interfície gràfica configurable per l’usuari.

Introducció de les dades de la nòmina.

3.5 Interfície gràfica

A continuació podrem observar la seqüència de pantalles que es veuran al dispositiu mòbil i a la intranet. Com es podrà veure es procurarà que des de totes les pantalles tinguin accés a l’ajuda. Pel disseny de les pantalles del ChronosMobile s’ha tingut en compte el reduït espai del que acostumen a disposar els dispositius mòbils.

Totes les pantalles que es mostren a continuació només desitgen ser una aproximació del que seran en realitat, definint tots els elements necessaris en elles, encara que, tal com es veurà en el desenvolupament la seva semblança es limiti únicament als elements que la conformen.

A la presentació virtual es pot apreciar mitjançant el vídeo de la demostració l’aspecte final de les pantalles.


Pàgina 32

3.5.1 Subsistema principal

Inicialment tenim la pantalla per introduir la contrasenya.

Si la contrasenya no s’introdueix correctament, apareixerà un missatge informant a l’usuari i aconsellant-lo que en cas de que no recordi la seva contrasenya es posi en contacte amb el departament de sistemes d’informació.

Si la contrasenya introduïda es validada observarem una pantalla de presentació, amb el nom de l’aplicació i les dades dels creadors de l’aplicació.


Pàgina 33

Després d’uns 5 segons ens apareix la pantalla del menú principal on podem observar les diferents opcions de l’aplicació. El nombre d’icones és ampliable per tal d’afegir noves funcionalitats a l’aplicació.

Per la part de la intranet tenim que el subsistema principal estarà format per una pantalla d’autentificació i a continuació el menú on a simple vista l’usuari podrà veure les tasques pendents.


Pàgina 34


Pàgina 35

3.5.2 Subsistema de sol·licitud de nòmines

En seleccionar en el menú principal la opció de Nòmines ens apareix primer aquesta pantalla, on hi hem d’introduir el mes i l’any.

Un cop introduït mes i any ens apareix una nova pantalla amb les principals dades de la nòmina seleccionada. En cas de no estar disponible s’informarà a l’usuari mitjançant un missatge.


Pàgina 36

3.5.3 Subsistema de gestió de vacances

En seleccionar en el menú principal la opció de Vacances ens apareix primer aquesta pantalla, on hi podem veure les dades de la última consulta de vacances.

Si seleccionem la opció “Sol·licitar” ens apareixerà una pantalla com aquesta.


Pàgina 37

I si anem a l’apartat d’estat de les sol·licituds podrem observar una pantalla amb els següents elements.


Pàgina 38

Per part de la IntraChronos el responsable veurà la següent pantalla en entrar en l’apartat de Vacances, sota la taula de la llista de Vacances per validar apareixerà el detall de la fila seleccionada.


Pàgina 39

3.5.4 Subsistema de gestió d’hores

En accedir a l’apartat d’hores des de el menú principal observem una pantalla amb els següents elements.

Per tal de modificar un dels element simplement haurem de seleccionar un de la llista amb la qual cosa apareixerà la següent pantalla.

Per introduir un nou registre d’hores ens apareixerà una pantalla com la de edició però buida.

El total el calcula l’aplicació amb les dades introduïdes.


Pàgina 40

Per part de la IntraChronos el responsable veurà la següent pantalla en entrar en l’apartat d’hores, sota la taula de la llista d’hores per validar apareixerà el detall de la fila seleccionada.


Pàgina 41

3.5.5 Subsistema de gestió de despeses

A l’hora d’entrar a l’apartat de despeses des de el menú principal observem una pantalla amb els següents elements.

Per tal de modificar un dels element simplement haurem de seleccionar un de la llista amb la qual cosa apareixerà la següent pantalla.

Per introduir un nou registre d’hores ens apareixerà una pantalla com la de edició però buida.

En el cas en que la despesa tingui un preu per unitat el total s’autocalcularà.


Pàgina 42

Per part de la IntraChronos el responsable veurà la següent pantalla en entrar en l’apartat de Despeses, sota la taula de la llista de Despeses per validar apareixerà el detall de la fila seleccionada. I els corresponents botons per acceptar o denegar.


Pàgina 43

3.5.6 Subsistema d’alertes

Si accedim a la opció d’alertes ens apareixerà un llistat com el que presentem a continuació.

Si seleccionem un dels elements de la llista veurem el detall de la noticia.

Per tal d’introduir les alertes a la IntraChronos el responsables treballaran amb una pàgina similar a la que presentem a continuació.


Pàgina 44


Pàgina 45

3.5.7 Subsistema de sincronització

Quan entrem a l’apartat de sincronització ens apareix una pantalla on podem seleccionar què volem sincronitzar.


Pàgina 46

4. DISSENY.

4.1 Introducció

Aquest apartat proposa una solució als requeriments i funcionalitats presentades en el document “Especificació i anàlisi dels requeriments”. Si en el document d’anàlisi descrivíem que havia de fer el programari, en aquets document explicarem com ho ha de fer. Es discutirà sobre l’arquitectura J2EE i la J2ME a utilitzar, els patrons a emprar, es farà un disseny de la base de dades, les estructures de dades i l’especificació de cada programa.

4.2 Java 2 Enterprise Edition(J2EE)

J2EE és una especificació oberta que proporciona un model complert per suportar arquitectures distribuïdes i representa un conjunt de tecnologies que es poden utilitzar conjuntament per implementar un model arquitectònic d’aplicacions distribuïdes de gran dimensions (orientat al món de les empreses).

Per desenvolupar la part de la intranet tenim la possibilitats de fer servir una de les dues tecnologies que descrivim a continuació:

• Java Server Pages(JSP’s) :Una pàgina JSP no és més que un altre forma de veure un servlet. Es tracta de permetre que es pugui incloure codi Java dins d’una pàgina HTML. Una pàgina JSP és preprocessada a un arxiu .java que després és compilat per generar un arxiu .class. Aquesta és la innovació que proporciona aquesta tecnologia envers a la tecnologia ASP de Microsoft que es compila en memòria i no en un arxiu separat. Aquesta característica fa més lenta la execució de les pàgines, tot i així quan una pàgina JSP ha estat convertida a servlet i compilada, la seva execució es tan ràpida com si el seu origen hagués estat un servlet normal.


Pàgina 47

A continuació mostrem un diagrama on es descriu el tractament que es fa en el servidor web quan es rep una petició http.

• Motor de plantilles: Per tal de separar al màxim possible el disseny i a maquetació de

la programació s’hauria d’utilitzar un motor de plantilles. Un motor de plantilles és una llibreria que permet separar les dades de la presentació, en el nostre cas la programació Java del codi HTML. Tant FreeMarker com Velocity són motors de plantilles que s’adapten molt bé a les necessitats que tenim.

En un motor de plantilles ens trobarem amb 2 elements, les plantilles i els models de dades. La tasca del motor es unir aquests dos elements per enviar codi html al navegador.


Pàgina 48

Per tal d’ oferir una interacció entre el dispositiu mòbil i el servidor farem servir els servlets. Els servlets són objectes que s’executen, en el nostre cas, sota el context d’un servidor web. L’ús més habitual és per generar pàgines web de forma dinàmica a partir dels paràmetres de la petició que enviï el navegador web. En el nostre cas farem servir els servlets per donar suport a l’aplicació ChronosMobile, oferint una comunicació amb el servidor mitjançant peticions http. S’encarregarà de interactuar entre la aplicació mòbil i la base de dades gestionant les consultes, insercions y modificacions.


Pàgina 49

4.3 Java 2 Mobile Edition(J2ME)

Hi ha dos formes d’implementar aplicacions d’aquest tipus en un entorn comercial.

• Les aplicacions lleugeres estan basades en el món web utilitzen llenguatges com WML o HTML pel desenvolupament de continguts i per comunicar-se amb el servidor el protocol HTTP. Són aplicacions fàcils de crear però tenen l’inconvenient de necessitar que l’usuari hagi d’estar connectat contínuament.

• Les aplicacions natives son aquelles desenvolupades per un sistema operatiu determinat com PalmOS, Windows CE i estan escrites en C o C++ i en alguns casos en BASIC. Aquestes aplicacions es poden executar sense connexió però són totalment dependents del sistema operatiu pel qual han estat creades. Tot i això aquest tipus d’aplicacions presenten l’avantatge de que poden aprofitar al màxim el control del hardware i la interacció amb l’usuari.

Les aplicacions J2ME pretenen agafar el millor dels dos tipus, creant un nou tipus de clients. La edició de J2ME, ofereix un rendiment òptim per dispositius mòbils, donat que ha estat una adaptació del llenguatge Java, on s’han eliminat les operacions prescindibles que necessiten més processament i s’han introduït noves classes per ajudar a desenvolupar aplicacions sobre aquest tipus de dispositius. Tot això ajuda a que la memòria utilitzada per la execució de l’aplicació sobre el dispositiu sigui inferior deixant més espai lliure al dispositiu, la persistència de dades i la execució d’aplicacions.

Un midlet és una aplicació Java que suporta les especificacions CLCD i MIDP. Un midlet des de que es crea fins que es destrueix pot passar per diferents estats tal com mostra la següent figura. S’indiquen també els mètode necessaris per passar d’un estat a l’altre.


Pàgina 50

4.4 XML

XML(Extensible Markup Language) és un llenguatge de marcat amb el que es pot crear etiquetes pròpies. Fou creat pel Consorci per la World Wide Web (W3C) per superar les limitacions d’HTML.

Aquest llenguatge permet fer documents clars i portables per la qual cosa és una gran solució d’intercanvi de dades entre aplicacions.

Fins ara hem vist que fa que les aplicacions siguin portables entre plataformes diferents i XML assegura que les seves dades també ho siguin.

Els trets característics de XML són:

• Claredat: permet la extracció automàtica d’informació.

• Validació: permet comprovar la consistència de les dades al ser enviades.

• Estàndard obert i lliure: ha provocat un creixement accelerat del seu ús.

Per tal de convertir les dades a un format xml necessitem un generador de xml i un parser.


Pàgina 51

XML serà el format que farem servir per enviar les dades. Per tal de la implementació d’aquesta tecnologia emprarem les següents llibreries:

• XMLPULL Els analitzadors de tipus pull són els que presenten millor comportament en dispositius mòbils. La implementació kxml2 es basa en aquesta API, per tant serà la que farem servir a l’hora d’implementar la part de l’aplicació ChronosMobile.

• JDOM El principal avantatge de JDOM es que redueix la quantitat de codi a

escriure. El mida de les aplicacions JDOM acostumen a ser un terç de les aplicacions DOM i la meitat de les aplicacions SAX. Per la implementació dels servlets amb els que es comunica el ChronosMobile farem servir JDOM que tot i que no ho fa tot, cobreix totes les nostres necessitats.

4.5 Disseny de l’arquitectura

El disseny de l’aplicació es basa en el paradigma client/servidor, on el servidor és el servlet i els clients són, per una banda el midlet de ChronosMobile i per un altre la IntraChronos. L’arquitectura de les aplicacions J2ME en el dispositiu mòbil pot articular-se fàcilment per adaptar-la al patró Model-Vista-Controlador (MVC):

• Model:Consta de les preferències, les constants i les dades. Inclou les preferències del usuari guardades en el sistema d’emmagatzematge permanent del dispositiu, les constants que utilitzi la aplicació des de un principi i totes les dades que es presenten a l’usuari. El model hauria de ser l’encarregat d’indicar les característiques del dispositiu, per tal que l’aplicació pugui adaptar-se a aquestes característiques.

• Vista: Es basa en la lògica de presentació en pantalla. La vista ha d’estar preparada per la presentació de dades en un interval desconegut de resolucions ja que l’aplicació no pot conèixer sobre quin dispositiu s’està executant. A més informa al controlador del tipus de dades que ha d’enviar-li en funció de característiques com: mida de la pantalla, color, pantalla tàctil…

• Controlador: S’ocupa de les comunicacions, i la lògica de la aplicació. En aquest cas, que necessita una connexió amb el servidor, ha d’estar preparat tant per suportar una petició de dades en un entorn pull com la recepció de dades en un entorn push. Per tal de facilitar aquesta funcionalitat seria convenient crear una classe base amb la funcionalitat comuna y després derivar subclasses amb la funcionalitat específica.


Pàgina 52

4.6 Disseny de la base de dades

En aquest apartat es defineix tant la base de dades a la qual s’accedeix a través del servidor com la petita base de dades que s’ocupa d’emmagatzemar les dades al dispositiu mòbil. S’ha tingut en compte que per la persistència de dades a l’aplicació ChronosMobile no disposem de cap base de dades relacional. El perfil MIDP de J2ME defineix un conjunt de classes per a controlar la persistència de dades en el dispositiu mòbil: el Record Management System(RMS). Les zones on es guarden de dades son en realitat arxius binaris que depenen de la plataforma. La informació que conté cada registre del RMS es semblant a la que podríem trobar en una base de dades plana. Per tant no podem fer servir les eines que ens ofereix una bona base de dades relacional. El nombre de dades que s’emmagatzemaran al dispositiu no serà gaire gran, la intenció és que al dispositiu es mantinguin les mínimes dades necessàries i que la resta de dades s’obtinguin per mitjà de consultes on-line, d’aquesta manera delegarem part de la feina al servidor. Com que el nombre de dades no serà gaire gran i els registres del RMS són poc manejables s’ha optat per bolcar les dades del RMS a objectes en memòria en el moment d’engegar l’aplicació. D’aquesta manera s’aconseguirà un accés més còmode a les dades. Per aquest motiu s’hauran de definir una sèrie de mètodes pels objectes que contindran aquestes dades per tal de carregar i descarregar les dades de un registre. Podem dir per tant, que l’aplicació ChronosMobile disposarà d’uns RecordStores que contindran gairebé les mateixes dades que a les taules de la base de dades però serà l’aplicació la que s’encarregarà de gestionar les relacions entre les dades dels registres.


Pàgina 53

4.7 Model ER

Després de la recollida de requisits i del seu posterior anàlisi, s’han definit el següent disseny per la base de dades.


Pàgina 54

4.8 Model lògic

A partir del model conceptual s’obté el següent model lògic.


Pàgina 55

4.9 Descripció de les taules

A continuació es descriuen detalladament cada una de les taules de la base de dades. La descripció de les taules de la base de dades conté de la següent informació: • Columna: el nom de la columna de la taula • Tipus: el tipus de dada. • Clau: PK (primary key) indica que aquesta columna forma part de la clau

primària. FK (foreign key) indica que aquesta columna forma part d’una clau

forana a una columna o columnes d’una altra taula. • Null?.: indica si la columna accepta valors nuls. • Descripció: conté una breu descripció de la columna.

4.9.1 Taula Agent

En aquesta taula tindrem les dades de cada agent

Taula Agent Columna Tipus Clau Null? Descripció

id_agent number PK no Identificador de l’agent Id_responsable number FK no Identificador del responsable de

l’agent nom varchar(20) no Nom de l’agent cognoms varchar(40) no Cognoms de l’agent dni varchar(9) no Dni de l’agent nss varchar(20) no Número de seguretat social

De l’agent username varchar(15) Nom d’usuari de l’agent psw varchar(6) contrasenya vacances_totals number Número total de vacances que té

l’agent. vacances_disponibles number Número de dies de vacances

disponibles


Pàgina 56

4.9.2 Taula SolVacances

En aquesta taula quedaran registrades les peticions de vacances que fan els agents.

Taula solVacances Columna Tipus Clau Null? Descripció

id_solicitud number PK no Identificador de la sol·licitud. id_agent number FK no Identificador de l’agent que ha

fet la sol·licitud. data_inici date no Data d’inici de les vacances

sol·licitades. data_fi date no Data fi de les vacances

sol·licitades. estat varchar(10) Estat en el que es troba la

sol·licitud: PENDENT, APROVAT, DENEGAT

4.9.3 Taula Nòmina

En aquesta taula és on es troben guardades les dades de les nòmines dels agents. En aquest cas només treballarem amb dades bàsiques com el total reportat, el total deduït i el total, però podria ser una possible ampliació del projecte el poder mostrar als comercial més dades de la nòmina.

Taula Nomina Columna Tipus Clau Null? Descripció

id_nomina number PK no Identificador de la nòmina id_agent number FK no Identificador del agent data date no Data reportat number no Import reportat deduït number no Import deduït total number no Total a percebre


Pàgina 57

4.9.4 Taula CabDespeses

En aquesta taula guardarem les dades de la capçalera de una fulla de despeses. Podem observar que el valor de total es pot calcular a partir dels totals de les línies del full de despeses.

cabDespeses Columna Tipus Clau Null? Descripció

id_despeses number PK no Identificador de la capçalera de despeses.

id_agent number FK no Identificador de l’agent data_inici no Data inici data_fi no Data fi estat Varchar(10) Estat en el que es troba la


total number no Total: suma de totes les despeses de la fulla.

4.9.5 Taula linDespesa

En aquesta taula es registren cada una de les línies del full de despeses.

linDespesa Columna Tipus Clau Null? Descripció

id_despeses number PK/FK no Identificador de la fulla a la qual correspon aquesta línia.

línia number PK no Número de línia dins de la fulla.

id_tipus number FK no Identificador del tipus de despesa.

unitats number no Unitats de la despesa. data date no Data anotació Varchar(100) Anotació sobre la despesa. total number no Total per aquesta despesa.


Pàgina 58

4.9.6 Taula tipusDespesa

En aquesta taula tindrem tots els tipus de despeses amb els seus atributs.

tipusDespesa Columna Tipus Clau Null? Descripció

id_despesa number PK no Identificador del tipus de despesa.

nom varchar(20) no Nom descriptiu de la despesa ppu number Preu per unitat de la despesa.

4.9.7 Taula cabHores

En aquesta taula tenim la capçalera d’un full d’hores, en aquest cas també podrem calcular el total d’hores a partir de les línies de la fulla d’hores.

Taula cabHores Columna Tipus Clau Null? Descripció

id_hores number PK no Identificador de la fulla d’hores. id_agent number FK no Identificador de l’agent. data_inici date no Data d’inici del full. data_fi date no Data de fi de la fulla estat varchar(10) no Estat en el que es troba la


total number no Número total d’hores de la fulla.


Pàgina 59

4.9.8 Taula linHores

En aquesta taula es troben les línies del full d’hores.

Taula linHores Columna Tipus Clau Null? Descripció

id_hores number PK/FK no Identificador de la fulla a la qual correspon la línia.

línia number PK no Número de la línia dins d’aquesta fulla

id_tipus number no Identificador del tipus de dia al qual correspon aquesta línia.

Data Date no Data. Hora_inici timeStamp no Hora a la que es comença a

treballar. Hora_fi timeStamp no Hora a la que termina. descans number Número d’hores de descans. total number no Número total d’hores.

4.9.9 Taula tipusDia

En aquesta taula trobarem tots els tipus de dies:vacances, malaltia, feina…

Taula tipusDia Columna Tipus Clau Null? Descripció

id number PK no Identificador del tipus de dia nom varchar(20) no Nom descriptiu del tipus de dia.

4.9.10 Taula Responsables

En aquesta taula tindrem les dades de cada responsable


id_responsable number PK no Identificador del responsable nom varchar(20) no Nom del responsable cognoms varchar(40) no Cognoms del responsable dni varchar(9) no Dni del responsable username varchar(15) Nom d’usuari del responsable psw varchar(6) contrasenya


Pàgina 60

4.9.11 Taula Alertes

En aquesta taula tindrem les dades de cada alerta


id_alerta number PK no Identificador de l’alerta data Date no Data de creació nova varchar(2) no 0/1 vella/nova assumpte varchar(50) no Assumpte de l’alerta id_agent number FK no Identificador de l’agent. autor varchar(20) no Nom del autor de l’alerta text varchar(100) contrasenya


Pàgina 61

4.10 Diagrama estàtic de disseny: classes i jerarquies

Diagrama de classes de l’aplicació IntraChronos


Pàgina 62

Diagrama de classes de l’aplicació ChronosMobile


Pàgina 63

4.11 Descripció de les comunicacions

A continuació presentem una sèrie de diagrames que il·lustren tot el procés de comunicació, tant de dispositiu mòbil a servidor com al revés. El càlcul del checksum es fa, per tal de poder ser reutilitzat en posteriors funcionalitats de l’aplicació, sumant el codi ASCII de cada un dels caràcters del XML.

• Enviament de dades PDA a Servidor


Pàgina 64

En el cas en que la comprovació del checksum surti negativa, s’haurà de repetir l’enviament de les dades

• Enviament de dades de Servidor a PDA


Pàgina 65

5. IMPLEMENTACIÓ.

5.1 Requisits del maquinari i programari

En aquest punt es defineixen les necessitats pel desenvolupament del projecte.

• Dispositiu Mòbil o CLDC 1.0 ( Connected Limited Devices Configuration) o MIDP 2.0 (Mobile Information Device Configuration) o Connexió GPRS o Capacitat de processament suficient (CPU + Memòria) i suport de màquina virtual

J2ME.

• Servidor d’aplicacions:Apache Tomcat 5.5

• IDE: Eclipse 3.1 o Plug in EclipseMe per J2ME o Java wireless toolkit 2.2. o Plug in Lomboz o Plug in Quantum o Plug in ant

• Base de dades: MySql 5.0.19

o Driver JDBC.

• Aplicació pel disseny d’icones: Axialis IconWorkshop.

6. Valoració econòmica.

La valoració econòmica no forma part dels objectius d’aquest, tot i així es pot valorar el projecte en funció del nombre d’hores. Han estat 14 setmanes de feina amb un promig de 20 hores setmanals, tenim un total de 280 hores. Multiplicant aquest valor pel preu en mercat de la hora d’un analista/programador obtindríem una valoració econòmica aproximada d’aquest projecte. Tot i que s’ha de tenir en compte que el preu real seria inferior pel temps que ha suposat adquirir el coneixement suficient per la realització del TFC.

El cost econòmic de la implantació d’aquest projecte depèn molt de la infraestructura que tingui la empresa. Tot i que gràcies a la gran portabilitat de la solució és fàcilment adaptable a gairebé qualsevol entorn.


Pàgina 66

7. Conclusions.

Des de un punt de vista professional crec que el tret més característic del producte obtingut és a part de la seva utilitat, la seva portabilitat, facilitant la seva implantació en diversos entorns i especificacions. A més a més considero que la implantació Chronos en una empresa suposaria una sèrie de beneficis que enumerarem a continuació:

• Augmenta la comoditat pels usuaris.

• Proporciona un servei de consultes i sol·licituds constant als comercials. • Augmenta la velocitat de resposta per part dels responsables. • S’eviten errors humans augmentant la consistència de les dades. • Estalvi de temps i per tant un major rendiment en les tasques dels seus empleats. • L’ús de noves tecnologies dóna una bona imatge de empresa. • La independència del dispositiu suposa a la llarga un estalvi econòmic.

Des d’un punt de vista personal, l’elecció de realitzar el TFC a l’àrea de J2EE va ser motivada per la necessitat d’ampliar i consolidar el meu coneixement en el món de Java. Tecnologia cada cop més emprada en el món professional. M’ha servit també per posar en pràctica coneixements adquirits durant la carrera especialment els relatius a enginyeria del programari, programació orientada a objectes, estructura de la informació i les assignatures de base de dades.

Donat que quan vaig començar el meu coneixement sobre J2EE era mínim, penso que he assolit els objectius que apareixen en el pla docent relatius al TFC. La memòria, i sobretot el producte obtingut, són l’exemple més il·lustratiu. Tot i que inicialment sí tenia nocions de J2ME, aquest TFC m’ha servit tant per ampliar i consolidar el coneixement en aquesta area com per corregir males costums i errors en la programació en J2ME.

Tot i la limitació temporal, la realització d’aquest TFC ha estat molt positiva. Considero que la temàtica escollida ha estat molt interessant ja que la tecnologia mòbil està a l’ordre del dia i tot allò relacionat amb ella, fent d’aquest treball un projecte innovador. Ha estat molt motivant el fet de treballar sobre una idea pròpia amb possibilitats de convertir-se en un futur en una aplicació real. Per primera vegada en la carrera m’he posat com a desenvolupadora a la pell dels usuaris per tal de dissenyar una aplicació còmode i útil, cuidant cada detall tant en la programació com en la interfície gràfica. El poder realitzar un projecte des de zero, imaginar uns suposats requisits, escollir l’arquitectura, fer l’anàlisi, el disseny i per últim la implementació ha suposat per mi un pont entre la universitat i el món professional.


Pàgina 67

8. Glossari.

• API: Application Programming Interface - Interfície de Programació d’aplicacions. És un conjunto d’especificacions que permeten una abstracció en la programació.

• Autenticació: procés de seguretat pel qual l’usuari ha d’introduir el seu nom

d’usuari, la seva contrasenya i en cas de que siguin correctes de li permet l’accés, en cas contrari no.

• Chronos: Nom que li hem donat al producte obtingut amb el desenvolupament d’aquest TFC. Consta de dos aplicacions ChronosMobile i IntraChronos.

• CLCD: Configuració per dispositius amb connexió limitada.

• GPRS: General Packet Radio Service és una tecnologia digital de telefonia mòbil que proporcina altes velocitats de transferència de dades.

• J2ME: La plataforma Java 2, Micro Edition, és una col·lecció d’API’s en Java orientades a dispositius mòbils.

• J2EE: La plataforma Java 2 Enterprise Edition orientada al desenvolupament d’aplicacions empresarials.

• JSP: JavaServer Pages és la tecnologia per generar pàgines web de forma dinàmica en el servidor, basat en scripts que utilitzen una variant del llenguatge java.

• Midlet: aplicació que s’executa sobre un dispositiu mòbil fent ús de la plataforma J2ME.

• MIDP: Perfil per dispositius de informació mòbil.

• RMS: Record Management System. Conjunt de classes definides pel perfil MIDP destinades al control del emmagatzemament de dades.

• Servlet: aplicació que s’executa sobre un servidor fent ús de la plataforma J2EE.

• Scripts: és el programa escrit per un llenguatge interpretat.

• Solució global: Conjunt d’aplicacions que sobre una infraestructura (empresarial) ofereixen la solució a una sèrie de tasques determinades.

• XML: eXtensible Markup Language – llenguatge de marcat extensible.


Pàgina 68

9. Bibliografia consultada.

CAMPDERRICH, BENET. Enginyeria del programari; Anàlisi orientada a objectes . UOC. (material de l’assignatura Enginyeria del Programari).

IBM.[online] Architectural manifesto: The MVC design pattern in MIDP development http://www-128.ibm.com/developerworks/library/wi-arch6/index.html?ca=drs-wi3704

AGUSTÍN FROUFE QUINTAS, PATRICIA JORGE CÁRDENAS- Java 2 Micro Edition:Manual de usuario y tutorial. RA-MA Editorial.

CRAIG LARMAN- UML y Patrones. Learson Educación.

JAMES W. COOPER, ADDISON WESLEY- Java Design Patterns: A tutorial.

SERGIO GÁLVEZ, LUCAS ORTEGA .[online] Java a tope http://www.lcc.uma.es/~galvez/J2ME.html

AGUSTÍN FROUFE- JavaServer Pages: Manual de usuario y tutorial. RA-MA Editorial JESÚS BOBADILLA, ADELA SANCHO- Comunicaciones y base de datos con JAVA a través de ejemplos. RA-MA Editorial MARTY HALL – Servlets and JavaServer Pages. Sun Microsystems. CHOPRA, BAKORE, EAVES, GALBRAITH, LI, WIGGERS- Professional Apache Tomcat 5. Anaya Multimedia.


Pàgina 69

solució global per la gestió de dades d’empleat mitjançant

Documents