Aplicació per als Bombers de Mallorca en PDA.


Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Aplicació per als Bombers de Mallorca en PDA."

Transcripción

1 Aplicació per als Bombers de Mallorca en PDA. TFC Alumne: Miquel Piulats Mateu Consultor: David Gañan Jimenez UOC TFC.NET. 1

2 1.1.- OBJECTIU DESCRIPCIÓ DEL TREBALL TASQUES TAULA DE PLANIFICACIÓ MATERIALS REQUISITS DE L APLICACIÓ REQUISITS FUNCIONALS REQUISITS DE LA INTERFÍCIE REQUISITS D USABILITAT REQUISITS DE MAQUINARI ANÀLISIS CASOS D US IDENTIFICACIÓ DE CLASSES DISSENY UML DISSENY USABILITAT I PROTOTIP IMPLEMENTACIÓ EMMAGATZAMENT D INFORMACIÓ LLISTAT DINÀMICS CONTROL D OPCIONS DISPONIBLES

3 5.4.- EXPORTACIÓ DE LES DADES OPCIÓ D IMATGES SINCRONITZACIÓ UN PASSEIG PER L APLICACIÓ CONCLUSIONS BIBLIOGRAFIA USADA

4 1.1.- Objectiu. L objectiu d aquest TFC és desenvolupar una aplicació client per PDA fent ús de la tecnologia.net de Microsoft per al cos de bombers del Consell de Mallorca per a enregistrar in situ les dades relatives als sinistres on són demanats els seus serveis. Es tracta doncs d un cas real, de manera que podrem comptar amb un feedback per part dels usuaris de l aplicació. 4

5 1.2.- Descripció del treball. Actualment, els Bombers de Mallorca, disposen d un aplicació sota un entorn d intranet per a la gestió, introducció i modificació dels sinistres que ocorren en l illa de Mallorca. Aquesta aplicació només està accessible des de les dependències del Consell de Mallorca. Aquesta situació els obliga a tenir que prendre nota de totes les seves actuacions en paper, fins que arriben a la central i realitzen les entrades dels sinistres que han efectuat. A més, es dona el cas de que sovint, qui introdueix les dades no es la mateixa persona que s ha presentat al sinistre, i això fa que la informació original pugui veure s tergiversada. El Consell de Mallorca, ens encarrega el desenvolupament d una aplicació per a PDA, per tal que els bombers puguin gestionar correctament tota la informació relacionada amb sinistres des de el mateix lloc d actuació. Aquesta aplicació, presenta dos grans reptes. Per un costat explorar les possibilitats de la tecnologia. NET per al desenvolupament d una aplicació per a PDA, amb programació orientada al objecte i el seu accés a dades, i per una altra banda introduir-se en els conceptes d usabilitat apresos també durant l enginyeria ( Interacció Humana amb les ordinadors). Aquesta aplicació haurà de facilitar l enregistrament de dades de cada sinistre. Cal dir, que en un sinistre intervenen molts factors, que defineixen les seves característiques. Entre d altres, la informació que defineix cada sinistre, inclou la gestió de persones, lloc, tipus de sinistre, vehicles propis que hi ha intervingut, col laboració amb d altres cossos, bens mobles i immobles sinistrats, etc... La aplicació objecte d aquest TFC haurà de poder enregistrar, consultar o modificar tota aquesta informació i facilitar les tasca al bomber. 5

6 L aplicació s haurà comunicar amb un agent extern. En aquest cas l aplicació de la intranet del Consell de Mallorca, i realitzar intercanvis de dades. D aquesta manera, considerarem dos àmbits on l aplicació haurà de funcionar: - No es disposa de connexió, i la informació de sinistres s ha d anar enregistrant per a una posterior sincronització amb l aplicació de la intranet. - Quan es disposa de connexió, i l aplicació actualitzarà les dades a l aplicació del servidor, i sincronitzarà la informació que hi pugui tenir enregistrada, per tal que aquesta quedi inserida. També es descarregarà possibles actualitzacions a les opcions relatives als sinistres. La comunicació de l aplicatiu amb l ordinador central es realitzarà mitjançant l enviament de post i get de tipus http, que permetrà tenir intercanvi de dades entre dues aplicacions, independentment de les seves característiques i/o llenguatges. També s avaluarà si les cameres integrades amb PDA proporcionaran prou qualitat o no a les fotografies del sinistre. 6

7 1.3- Tasques. Podem definir tot un seguit de tasques per a dur a terme durant el temps de desenvolupament d'aquest aplicatiu: Reunions amb el client. Ens permetrà conèixer de primera mà la metodologia de treball dels bombers de Mallorca per tal que la nostra aplicació s ajusti al màxim a les característiques de funcionament intern del cos. Determinar funcionalitats Aquesta presa de contacte, ens permetrà definir quines són les característiques que s esperen de l aplicació d una manera més acurada. Determinar maquinari Seleccionarem un maquinari que s ajusti a les necessitats del cos. En aquest sentit ens caldrà un PDA prou capaç, amb camera integrada. Anàlisi i creació de les estructures de dades. Amb tota la informació necessària recopilada, confeccionarem totes les estructures de dades. Se n generaran els diagrames oportuns. Anàlisi de funcions. Es determinaran totes les funcions que seran necessàries per a la relació entre tots els elements que intervenen en un sinistre. Prototipatge.Usabilitat. S aplicaran al disseny les tècniques d usabilitat. Escriure el codi font. S escriuran totes les funcions i lògica necessària per al correcte funcionament de la aplicació. Procés de proves. Es realitzaran proves tant a nivell de laboratori com en ús general, per tal de comprovar si s ajusta correctament a les funcionalitats demanades. Documentació. La documentació relativa al projecte, s anirà realitzant a la vegada que el desenvolupament. Lliurament. Finalment es farà entrega de tot el projecte. 7

8 1.4.- Taula de planificació. Reunions amb el client. Dates d inici i final De 6 de Març a 12 de Març. Determinar funcionalitats de 12 de Març a 17 de Març. Determinar maquinari de 12 de Març a 17 de Març. Anàlisi i creació de les estructures de dades. de 17 de Març a 1 d abril. Anàlisi de funcions. d 1 d abril a 10 d abril. Prototipatge. Usabilitat. de 10 d abril a 18 d abril. Entrega PAC 2 Disseny. Escriure el codi font. De 18 d abril a 22 de Maig. Entrega PAC3 Implementació. Procès de proves. De 22 de Maig a 7 juny. Documentació Durant tot el procés de desenvolupament. Lliurament 19 de Juny Lliurament 8

9 1.5.- Materials. Per al desenvolupament d aquest TFC serà necessari el següent programari:.net Compact Framework 2.0 de Microsoft. Visual Studio 2005 de Microsoft. Tot el programari es desenvoluparà en CompactFramework ( c# ) de visual studio. S ha fet us de les possibilitats d aquest llenguatge i la seva orientació al objecte. En aquest sentit, hem aprofitat la serialització d objectes a xml, i la seva deserialització. 9

10 2.- Requisits de l aplicació. En aquesta etapa, s han portat a terme diverses reunions amb integrants del cos de bombers del Consell de Mallorca, per tal d obtenir prou informació per a la elaboració de requisits de l aplicatiu. En línies generals en requisits funcionals, l aplicatiu ha de poder enregistrar l informe de cada actuació que realitza el servei de bombers. Un cop te totes les dades enregistrades, s ha de sincronitzar amb l aplicatiu que es troba al servidor del Consell de Mallorca. El fet més determinant a nivell de funcionalitats, resideix en el fet que els formularis de dades son diferents per a cada tipus d actuació, i en caldrà diferenciar cadascun dels casos. En quant a usabilitat, s ha de tenir en compte que l aplicatiu serà usat per persones que no estan acostumades a fer anar ordinador i menys dispositius mòbils. Per tant cal aplicar uns criteris d usabilitat de manera que no tinguin que realitzar un esforç per saber fer anar aquest aplicatiu. D altra banda, algunes de les opcions han de ser de ràpid accés doncs a vegades el temps d utilització és un factor important Requisits funcionals. S han de poder emmagatzemar els informes d actuació diària. Ha de poder funcionar tant en mode online com en mode offline. Totes les opcions han de poder ser modificades en cas de correcció abans de la sincronització amb el servidor. Ha de distingir els diversos casos d actuació, demanant la informació exacte relativa a cada tipus. Cal desar algunes dades preconfigurades relacionades amb cada parc per tal de facilitar la visualització de formularis ja filtrats. Aquestes han d estar desades en un fitxer de configuració. 10

11 Tota la informació que es visualitzar en els formularis ha de ser sincronitzada amb el servidor, de manera que canvis en la estructura del programa principal de gestió d informes també quedin reflexades en l aplicactiu mòbil. A continuació exposem quines són les dades que poden integrar un informe d actuació Dades generals del Sinistre L usuari haurà de poder enregistrar unes dades bàsiques relatives al sinistre. Aquestes són: Una descripció. Tipus d actuació que s ha realitzat. Situació del sinistre. Data del sinistre. Data de finalització del sinistre. Data de tancament del informe. Distancia del parc. Posició del sinistre. Parcs que hi assisteixen. Aquestes opcions seran comunes a totes les actuacions per part dels bombers. El tipus d actuació vindrà donat per la sincronització per part del servidor on ja s han tipificat les possibles actuacions. Actualment es contemplen els següents casos: - Falsa Alarma. Per aquelles actuacions on finalment no ha calgut realitzat una intervenció. Això no vol dir que els bombers no s hi hagin desplaçat físicament. - Incendi amb intervenció. Per aquelles actuacions on si ha calgut realitzar una intervenció, i s han utilitzat mitjans propis. - Incendi sense intervenció. Per aquelles actuacions on si ha calgut realitzar una intervenció, però hi ha intervingut altres mitjans. - Altres intervencions. Quan es tracta d actuacions especials, com rescats, salvaments, etc... 11

12 Addicionalment, el Consell ha definit dues tipologies més, que són combinació de les anteriors: - Incendi amb intervenció + altres. - Incendi sense intervenció + altres. Com més endavant és podrà comprovar, el tipus d intervenció condicionarà d una manera important el funcionament de l aplicatiu doncs s haurà d ajustar a la naturalesa del informe que s està realitzant Bombers que han assistit. Cada informe de sinistre, te uns bombers associats que són el que hi han assistit. Malgrat el informe només és omplert pel Bombers de màxima graduació, s haurà de fer constar quin són el total de bombers que hi ha assistit. Es mostrarà a l usuari una llista dels possibles bombers que assisteixen a la actuació. S ha demanat per part del Consell de Mallorca, que aquesta llista es trobi filtrada per parc d actuació, de manera que només apareguin als usuaris ( almenys en primera instància) els bombers que pertanyen al parc al que pertany qui realitza el informe. Addicionalment, l usuari podrà seleccionar la possibilitat de veure tots els bombers de tots els parcs. També és podrà filtrar per la graduació dels bombers. Aquesta opció és comuna a qualsevol tipus d actuació Imatges. Cada informe de sinistre pot tenir associat imatges. Si el PDA disposa de camera integrada, l aplicació haurà de vincular les imatges al informe, de manera que aquestes també siguin actualitzades amb el servidor central. Aquesta opció és comuna a qualsevol tipus d actuació menys la de falsa alarma. 12

13 Altres col laboradors. Cal associar a cada informe, els possibles col laboradors externs que han participat a l actuació. Aquests poden ser diversos, i caldrà que siguin actualitzats amb el servidor. Actualment hi ha definit diversos cossos com la Guàrdia Civil, Creu Roja, etc... Ha de ser possible una selecció múltiple d altres col laboradors Bens sinistrats. Cal també desar la informació relacionada amb els bens que han estat sinistrats. Per això distingim tres tipus de bens sinistrats, els mobles, immobles i semovents. Els bens mobles són de tipus material, com vehicles, maquinaria, etc... D aquests en desarem el camp matrícula. Els bens immobles són aquells que es refereixen a una construcció. D aquests desarem la adreça física. Dels bens semovents, com animals, desarem una descripció ( que serà desada per imposició de l aplicació existent al camp de matrícula). De tots ells, desarem també qui és el propietari, amb el nom i el NIF. S ha de tenir la possibilitat de afegir diversos bens sinistrats de diversos propietaris. Aquesta opció és comuna a qualsevol tipus d actuació menys la de falsa alarma Vehicles que hi ha assistit. A cada sinistre, s hi destinen un vehicles. N hi ha de diversos tipus. Cada vehicle té unes característiques i es troba en algun parc. Aquesta informació caldrà que sigui sincronitzada amb el servidor de l aplicació doncs és la que te les dades de en quin parc es troba cada vehicle. Cada vehicle te associat una matricula, un model, una descripció, i la seva situació. El bomber haurà de poder seleccionar els vehicles que han acudit al 13

14 sinistre. A més a més, se li ha de presentar la informació filtrada depenent del parc d actuació. De cada vehicle, s ha de poder desar el moment en que s ha efectuat la sortida, la seva arribada al sinistre, i el de tornada al parc. Per altra banda, la distància en Km que ha recorregut el vehicle. A més a més també desarem els minuts de bomba d aigua que s han utilitzat en el sinistre ( si s hi han destinat) Mitjans que s han utilitzat. Mitjans es refereix a quins medis s han utilitzat per la actuació en el sinistre. Aquests mitjans és poden diferenciar entre tres tipus: Mitjans propis. Aquells mitjans que han estat aportats pel propi cos de bombers del Consell de Mallorca. La relació de mitjans propis haurà d estar sincronitzada amb el servidor central per tal de oferir una llista actualitzada dels mitjans. Cada mitjà te una descripció, un codi, i en caldrà quina ha estat la quantitat que s'ha fet servir Mitjans al lloc. Aquells mitjans que no han estat aportats pel propi cos de bombers del Consell de Mallorca i es troben en el mateix lloc del sinistre. La relació de mitjans al lloc haurà d estar sincronitzada amb el servidor central per tal de oferir una llista actualitzada dels possibles mitjans. Cada mitjà te una descripció, un codi, i en caldrà quina ha estat la quantitat que s'ha fet servir. 14

15 Mitjans externs. Aquells mitjans que han estat aportats per altres col laboradors al lloc del sinistre. La relació de mitjans externs haurà d estar sincronitzada amb el servidor central per tal de oferir una llista actualitzada dels possibles mitjans. Cada mitjà te una descripció, un codi, i en caldrà indicar quina ha estat la quantitat que s'ha fet servir Víctimes. En tots els tipus d actuació, menys en el cas de falsa alarma, cal enregistrar quines han estat les víctimes personals del sinistre. A tal efecte, l aplicació ha de poder enregistrar el nombre de víctimes, algunes personals de cadascuna d elles com nom, cognoms, DNI, edat, gravetat, sexe i tipus ( bomber, civil, col laborador) de cadascuna d elles Ús del local. Quan es realitza una actuació en un local, cal també indicar de quin tipus de local es tracta. Aquesta opció necessitarà de la sincronització amb el servidor per a donar les possibles opcions Salvament i assistència. Quan el tipus d actuació inclou la especificació d altres, cal mostrar un formulari on poder seleccionar de quin tipus d actuació s ha realitzat ( salvament, evacuació,...) Aquesta informació també ens vindrà sincronitzada amb el servidor. 15

16 Apartats del incendi. Quan en la actuació hi ha intervingut un incendi, cal registrar quines han estat les característiques del mateix. Podem distingir entre 5 apartats principals, que a la vegada ens proposaran d altres opcions. Tipus de foc. Que permet seleccionar quin ha estat el tipus de foc. Superfície. Que permet indicar el tipus de superfície on s ha produït el foc. Caract. superfície. Que permet indicar d una manera més detallada la tipologia de la superfície. Causa inicial. Que permet indicar quina ha estat la causa inicial del foc. Causes de propagació. Que permet indicar quina ha/han estat les causes de propagació. Avís d incendi. Que permet indicar qui ha donat la primera alarma del incendi Sincronitzar dades. L aplicatiu anirà desant tots els informes que s hagin elaborat durant el dia. El bomber, en tornar al seu lloc de treball i dipositar el pda a la seva base, sincronitzarà les dades amb el servidor. Haurà de seleccionar entre els informes que hi ha desats el que vol sincronitzar. Es podria sincronitzar mitjançant la connexió GRPS, però les mesures de seguretat del Consell de Mallorca impedeixen que es pugui realitzar la sincronització fora de la xarxa interna de les instal lacions. 16

17 2.2.- Requisits de la interfície. Un dels problemes dels dispositius mòbils, es la reduïda pantalla de la que disposen. En aquest sentit caldrà dissenyar la interfície de manera que tota la informació sigui mostrada correctament, i evitar al màxim la introducció de dades de text. S ha de fer servir al màxim icones que facilitin l enteniment de les opcions. S ha d evitar al màxim la introducció de dades de text ( doncs amb un PDA pot tractar-se d una tasca complicada). La interfície s ha d adaptar depenent del tipus d esdeveniment que s està enregistrant. S ha de preveure que per a un bomber el temps pot jugar un paper important Tasques Un cop tenim una visió general de tot el que ha de fer l aplicatiu, podem definir tot un seguit de tasques que ens ajudarà tant a definir les classes d anàlisis com la interfície d usuari. anterior següent. Entrada Sortida Origen dades Nou informe Cap. Menú Informe Cap. Estat inicial. No n hi ha. anterior següent. Entrada Sortida Origen dades Gestió informes Cap. Menú gestió informes. Cap. Estat inicial. No n hi ha. 17

18 anterior següent. Entrada Sortida Origen dades Gestió Informes Cap. Sincronitzar. Seleccionar un dels informes que es troben desat al PDA per la seva edició o sincronització. Estat inicial. Local del PDA. anterior següent. Entrada Sortida Origen dades Menú informe Nou informe Opció seleccionada. Seleccionar una de les opcions inicials per a començar a omplir l informe. Al seleccionar l icona amb el tipus de dades a editar. Els icones vendran determinats pel tipus d actuació. anterior següent. Entrada Sortida Origen dades Dades Generals Menú informe. Menú dades del informe Selecció d un formulari amb els tipus d actuació. Dades principals del informe. Desant les dades. 18

19 anterior següent. Entrada Sortida Origen dades Seleccionar bombers que hi ha assistit. Menú d informe. Tornar al menú d informe. Formulari amb multi selecció múltiple dels bombers que hi ha disponibles en el parc. Un cop seleccionats els bombers es podrà tornar al menú principal del informe. Els bombers disponibles caldrà sincronitzarlos amb el servidor.. anterior següent. Entrada Sortida Origen dades Adjuntar imatges. Menú d informe. Tornar al menú d informe. Formulari per adjuntar imatges realitzades. Un cop seleccionades les imatges es podrà tornar al menú principal del informe. Local, mitjançant el PDA. anterior següent. Entrada Sortida Origen dades Seleccionar col laboradors. Menú d informe. Tornar al menú d informe. Formulari amb multi selecció múltiple dels possibles col laboradors. Un cop seleccionats els col laboradors es podrà tornar al menú principal del informe. Els col laboradors possibles caldrà sincronitzarlos amb el servidor. 19

20 anterior següent. Entrada Sortida Origen dades Omplir bens sinistrats. Menú d informe. Tornar al menú d informe. Visualització de bens ja introduït amb la possibilitat d editar o bé d introduir-ne de nous. Un cop visualitzats tots els bens es podrà retornar al menú del informe. Entrats tots pel bomber. anterior següent. Entrada Sortida Origen dades Omplir/editar un be sinistrat. Menú de bens sinistrats. Tornar al menú de bens sinistrats. Visualització d un formulari amb les dades de: tipus, direcció, matricula, propietari del be sinistrat. Boto d afegir o be de desar la edició. Un cop introduïts els bens sinistrats es podrà retornar al menú bens sinistrats. Dades entrades per part del bomber. 20

21 anterior següent. Entrada Sortida Origen dades Seleccionar vehicles que hi ha assistit. Menú d informe. Tornar al menú d informe. Formulari amb multi selecció múltiple dels vehicles que hi ha disponibles en el parc. Un cop seleccionats els vehicles es podrà accedir omplir les seves dades relatives a entrada, arribada i sortida del parc com de km recorreguts. Els vehicles disponibles caldrà sincronitzarlos amb el servidor. anterior següent. Entrada Sortida Origen dades Mitjans Menú d informe. Tornar al menú d informe. Formulari indicant si es tracta de mitjans al lloc, propis o de col laboradors. La selecció d aquests variarà les possibilitats de selecció del següent formulari on es podrà realitzar una selecció múltiple i indicar la quantitat usada de cada mitjà. Un cop seleccionats els mitjans que s han fet servir en l actuació es podrà retornar al menú principal del informe. Els mitjans a seleccionar, tant propis, col laboradors i externs vindran sincronitzats amb l aplicació servidor. 21

22 anterior següent. Entrada Sortida Origen dades Omplir víctimes. Menú d informe. Tornar al menú d informe. Visualització de víctimes ja introduïdes amb la possibilitat d editar o bé d introduir-ne de noves. Un cop visualitzats totes les víctimes bens es podrà retornar al menú del informe. Entrats tots pel bomber. anterior següent. Entrada Sortida Origen dades Omplir/editar una víctima. Menú de víctimes. Tornar al menú de llistat de víctimes. Visualització d un formulari amb les dades de: nom, DNI, edat, gravetat, evacuat, sexe i tipus. Boto d afegir o be de desar la edició. Un cop introduïts les dades de la víctima es podrà retornar al menú de víctimes. Dades entrades per part del bomber. anterior següent. Entrada Sortida Origen dades Ús del local. Menú d informe. Tornar al menú d informe. Formulari amb multi selecció múltiple dels possibles usos del local. Un cop seleccionats els usos dels locals es podrà tornar al menú principal del informe. Els possibles usos del local caldrà sincronitzarlos amb el servidor. 22

23 anterior següent. Entrada Sortida Origen dades Salvament i assistència. Menú d informe. Tornar al menú d informe. Formulari amb multi selecció múltiple dels possibles casos de salvament i assistència. Un cop seleccionats els casos de salvament i assistència podrà tornar al menú principal del informe. Els possibles casos de salvament i assistència caldrà sincronitzarlos amb el servidor. anterior següent. Entrada Sortida Origen dades Apartats del incendi. Menú d informe. Tornar al menú d informe. Formulari on es demanar quin dels apartats del incendi es vol omplir. La selecció d aquest dependrà de les opcions possibles de un segon formulari. Un cop indicades totes les característiques del foc es podrà retornar al menú del informe. Les opcions a seleccionar d apartats del incendi caldrà sincronitzar amb el servidor. 23

24 2.3.- Requisits d usabilitat. S ha de fer servir al màxim icones que facilitin l enteniment de les opcions. S ha d evitar al màxim la introducció de dades de text ( doncs amb un PDA pot tractar-se d una tasca complicada). S ha de simplificar al màxim els formularis, de manera que no es demani més que el que és necessari en cada tipus d actuació. 24

25 2.4.- Requisits de maquinari. S ha seleccionat un PDA amb característiques suficients per a cobrir les necessitats. El model d HP 6500 aporta les funcionalitats demanades, com camera integrada, gps i possibilitats de connexió remota. S en poden veure les característiques fonamentals a: Els avantatges principals, i que ens han fet decantar per aquest maquinari han estat: - Teclat físic, que ajudarà a realitzar les entrades de dades, especialment aquelles en que es requereix una descripció o nom de persona. - Inclou GPS que serà de gran ajuda en els desplaçaments dels bombers. - Inclou una camera prou potent, amb el que no caldrà que el bomber dugui dos dispositius. - També és telèfon movil, i d aquesta manera suprimim un altre aparell que el bomber ha de portar. - La seva capacitat és fàcilment ampliable amb la incorporació d un mòdul de memòria de tipus SD. Per altra banda, el principal inconvenient d aquest model és la seva reduïda pantalla de tipus quadrada. Encara així, pensem que serà possible encabir tots els formularis de l aplicatiu en les seves dimensions de 240x188 pixels. 25

26 3.- Anàlisis Casos d us Donat la complexitat de unificar tots els casos d ús en un sol gràfic, s ha optat per realitzar un gràfic simplificat de casos d us, i desprès un gràfic en detall agrupant casos d us segons la seva naturalesa, amb la intenció de facilitar-ne la comprensió. Cal també explicar, que només tenim un únic autor que és el bomber. La aplicació modifica el seu comportament en funció del tipus d actuació que s està realitzant. En aquest cas, els casos d ús han de reflexar com serà aquest comportament. El cas d ús de sortida, i que s amplia en els següents apartats és aquest: «e xte n ds» F a lsa A la rm a E d ita r In fo rm e «e xte n d s» «e xte n d s» In ce n d i a m b in te rvenció «e xte n d s» «e xte n d s» «e xte n d s» Incendi sense in te rvenció A cto r1 G e stio In fo rm e s «e xte n d s» A ltre s In cendi a m b intervenció + altres Incendi sense intervenció + altres 26

27 3.1.1 Cas Falsa Alarma «uses» Dades generals Falsa Alarma «uses» Bomber «uses» Bombers Vehicles En el cas que l actuació sigui una falsa alarma, només cal introduir les dades generals dels sinistres, els bombers que hi ha participat, i els vehicles que s hi ha desplaçat. És el tipus d actuació del que s han d enregistrar menys dades. 27

28 3.1.2 Cas d ús Incendi amb intervenció. Dades generals «uses» Incendi amb intervenció «uses» «uses» «extends» Bombers Vehicles Bomber «extends» Bens sinistrats «extends» «uses» «uses» «extends» Altres col laboradors «extends» Imatges Tipus Foc Mitjans Víctimes «extends» «extends» «extends» Ús del local Mitjans propis Mitjans al lloc Mitjans externs Aquest cas és un del més complets, doncs s ha d enregistrar totes les dades relatives al foc i a la intervenció realitzada. 28

29 3.1.3 Cas d ús Incendi sense intervenció. Dades generals «uses» Incendi sense intervenció «uses» «uses» «extends» Bombers Vehicles Bomber «extends» Bens sinistrats «uses» «uses» «extends» «extends» Altres col laboradors «extends» Imatges Tipus Foc Mitjans Víctimes «extends» «extends» Ús del local Mitjans al lloc Mitjans externs En aquest cas, intervenen també la majoria d agents, doncs encara que el cos de bombers no hagi realitzat intervenció, es desen totes les dades relatives al foc, i les de mitjans fets servir per altres agents participants. 29

30 3.1.4 Altres. D a d e s g e n e ra ls «u s e s» «u s e s» «u s e s» B o m b e rs V e h ic le s A ltre s «e x te n d s» B o m b e r «u s e s» «e x te n d s» «e x te n d s» B e n s s in is tra ts A ltre s c o l la b o ra d o rs S a lv a m e n t i a s s itè n c ia Im a tg e s El casos d Altres, fan aparèixer la opció de Salvament i assistència, on es permetrà seleccionar altres tipus d actuacions que també s hagin pogut realitzar, com un rescat de muntanya. 30

31 3.1.5 Incendi amb Intervenció + altres. Dades generals «uses» Incendi amb intervenció «uses» «uses» «extends» Bombers Vehicles Bomber «uses» «uses» «uses» «extends» «extends» «extends» Bens sinistrats Altres col laboradors «extends» Altres Imatges «uses» Tipus Foc Mitjans «extends» «extends» «extends» Víctimes Ús del local Salvament i assitència Mitjans propis Mitjans al lloc Mitjans externs Com es pot comprovar en el diagrama, els cas de Intervenció amb actuació + altres són composicions dels diagrames Altres i Intervenció amb actuació. 31

32 3.1.5 Incendi sense Intervenció + altres. Dades generals «uses» Incendi sense intervenció «uses» «uses» «extends» Bombers Vehicles «uses» Bomber «extends» Bens sinistrats Altres «uses» «uses» «extends» «extends» «extends» Altres col laboradors Imatges «uses» Tipus Foc Mitjans Víctimes «extends» «extends» Ús del local Salvament i assitència Mitjans al lloc Mitjans externs Com es pot comprovar en el diagrama, els cas de Intervenció sense actuació + altres són composicions dels diagrames Altres i Intervenció sense actuació. 32

33 3.2 - Identificació de classes. Amb tota la definició de les dades que cal enregistrar per a cada cas, i els casos d us i tasques exposats anteriorment, podem ja perfilar quines seran les principals classes necessàries que configuraran l esquelet de l aplicatiu i que desenvoluparem del tot en el següent apartat de disseny Classe Principal. La classe principal serà el eix vertebrador de l aplicatiu. D aquest classe és des de on es nodreix de dades a la resta de classes. D aquesta manera, aquesta classe és la encarregada de deserialitzar tots els objectes que són desats en format xml, i oferir els mateixos a la resta de classes que hi interacturan Classe Informe. Aquesta classe representarà l informe que ha estat emplenat. Informe -desc : string -datainici : int -datafinal -datainforme -distancia -temps -tipusactuacio : actuacio -situacio -uslocal -salvament -colaboradors : colaborador -sortides : sortida -bombers : Bomber -imatges : imatge Amb els següents atributs: Desc: Descripció de l actuació. DataInici: Data d inici de l informe. DataFinal: Data de finalització de l informe. Tipus d actuació: Contindrà un objecte actuació, on hi s inclourà informació relativa al comportament de l aplicatiu. Parc: Parc al que pertany l informe. I també conte totes les estructures de dades, per desar les característiques del informe, en format de llistes. 33

34 3.2.3 Classe Actuació. actuacio -distancia -tempsactuacio -situacio falsaalarma altres -uslocal -salvament incedi -incendi : incedi -intervencio : intervencio -altres : Altres Donat que el comportament del programa ha de ser diferent, depenent del tipus d actuació seleccionada, he decidit en crear una classe diferent per a cada tipus d actuació. Falsa alarma: per actuacions que no requereixen més informació que la bàsica. Altres: per actuacions que requereixen el formulari que es refereix a d altres actuacions. Incendi: per actuacions amb incendi, que a la vegada pot contenir un objecte altres, i un objecte intervenció. D aquesta manera podrem, amb només 3 classes derivades, mantenir tots els tipus d actuació descrits en l apartat de funcionalitats. D aquesta manera, la lògica de quines opcions s ha de mostrar en cada tipus d actuacio estarà en cadascun del tipus d objecte, i si en el futur s en han d afegir noves, la seva implementació només dependrà de l objecte actuació. 34

35 3.2.4 Classe Persona. Persona -Nom : string +getnom() : string +setnom() Bomber -IdBomber -Graduacio -Parc Victima -Sexe -Edat : int -Gravetat -Tipus -Evacuat : bool Propietari -Nif -Cognom -Tipus La classe persona que representarà individus dins l aplicatiu. Aquests poden ser de tres tipus ( bombers, víctimes i propietaris), i cadascun d ells serà una classe derivada de persones. De la classe bomber ens interessarà el seu identificador com a bomber, la seva graduació i al parc al que està destinat. Des de la classe de víctimes, ens interessa conèixer el seu sexe, la seva edat, el nivell de gravetat i si ha estat evacuat o no. Per últim, de la classe propietari ens interessa desar les seves dades principals. 35

36 3.2.5 Classe BeSinistrat. LA classe BeSinistrat, representa un be que s ha malmès degut al sinistre. La classe informe mantindrà un vector de bens sinitrats. BeSinistrat Moble -Matricula Inmoble -Direccio Semovent -Desc Finalment, en la implementació s ha optat per mantenir una sola classe BeSinistrat, i s ha convertit la herència en un atribut de la classe Classe Sortides i Vehicles. Es clar que hi ha una relació molt clara entre les sortides i els vehicles, doncs cada cop que es produeix una sortida aquest esta relacionada directament amb un vehicle. Una actuació pot contemplar diferents sortides, i cadascuna d elles tindrà associat un vehicle. Per tant, creem una relació d agregació entre vehicle i cada sortida. Vehicle -IdVehicle -Model -Parc -Desc -Matricula Sortida -Inici -ArribadaLloc -ArribadaParc -KmRecorreguts -MinutsBomba 36

37 3.3 Disseny UML Principal -Informes : Informe 1 * 1 UsLocal colaborador -idcolaborador : int -nomcolaborador : string * im atge * 1 actuacio * 1 1 Inform e -desc : string -datainici : int -datafinal -datainform e -distancia -temps -tipusactuacio : actuacio -situacio -uslocal -salvam ent -colaboradors : colaborador -sortides : sortida -bombers : Bomber -imatges : imatge * * 1..* sortida -inici -arribadalloc -arribadaparc -kmrecorreguts -m inutsbomba 1 M unicipi 0..* 1..* 1 vehicle -idvehicle -model -parc -desc -matricula parc * 1 -idparc : int -nomparc : string +veurevechiles() : vehicle +veurebombers() : Bom ber * -id -nom -tipus -desc persona -Nom : string 1 falsaalarm a altres incedi 1..* -incendi : incedi -intervencio : intervencio -altres : Altres 1..* Despesa -Q uantitat -IdMitja 1 * * * bom ber -IdBomber -graduacio -Parc : parc victim a -Sexe -Edat : int -Gravetat -Tipus -Evacuat : bool propietari -Nif -Cognom -Tipus ApartatsIncendi -TipusFoc -Superficie -CausaInicial -CausaPropaga -Avis -CaractSup * M itja -IdMitja -IdNom -idtipus BeSinistrat -tipus -desc * * 1 37

38 4.- Disseny 4.1- Usabilitat i prototip Tal com hem vist en l anàlisi de tasques, cal un menú principal per a gestionar totes les dades. A tal efecte, la navegació per tot l aplicatiu a partir que s està introduint l informe és realitzarà sempre de la mateixa manera. S entrarà dins un determinat tipus d informació, s omplirà i es retornarà al menú de l informe. També s ha uniformat tots els llistats, del tipus que sigui, i la manera d interactuar amb l usuari. En entrar en cadascun dels apartats de l informe, és pot desar, cancel lar, i quan és necessari veure quines són les dades enregistrades per l informe. Aquesta darrera opció és especialment útil en seleccions com la de bombers, on al modificar el filtrat del llistat es deixa de tenir contacte visual amb el que s ha seleccionat fins el moment. 38

39 4.1.1 Pantalla d inici Des de la pantalla inicial es presentaran 2 opcions bàsiques: Iniciar un nou informe. Gestionar els informes que hi ha desats al PDA ( pendents de sincronitzar). Addicionalment mitjançant el menú de context de la finestra ( no es tracta d una opció que generalment es faci servir) és podrà configurar detalls com el parc en que el PDA esta donant servei. Aquesta informació ens servirà per donar posteriorment formularis filtrats per parc. 39

40 4.1.2 Pantalla d ompliment d informe Aquesta serà la pantalla principal de l informe que inclourà les mínimes d un informe, i que un cop determinat el tipus d actuació afegirà les opcions pertinents de cada cas. D aquesta manera que el risc a equivocació en omplir dades que no són pas necessàries ( actualment passa ) desapareix. Per al prototipatge hem escollit el tipus d informe en que apareixen totes les opcions. 40

41 4.1.3 Pantalla de Bombers que han assistit. Finalment, mostrem l acció de entrar dins el part de bombers com mostra de la navegació endavant- endarrera per al ompliment de l informe. La selecció de bombers, podrà ser filtrada per parc o graduació del bomber que volem cercar. Com que s ha de possibilitat seleccionar més d un bomber es faran servir controls de tipus checkbox. Els llistat de vehicles, i la resta d opcions seleccionables d una llista tindran aquest format. 41

42 5.- Implementació. La implementació de Bombers s ha realitzat amb Visual Studio El llenguatge utilitzat ha estat c#, donada la seva orientació al objecte. A continuació destaquem quines han estat les decisions en temps d implementació més importants Emmagatzament d informació. Tota la informació necessària per a que aquest aplicatiu funcioni correctament, es troba emmagatzemada en un directori anomenat dades ( en aquest moment DadesProva), on es troben localitzats els fitxers xml necessaris. D aquests fitxers xml s extreuen les dades necessàries que desprès apareixen en els formularis de l usuari. Informació com els vehicles disponibles, bombers, etc... Així, a mode d exemple podem trobar el fitxer parcs.xml, amb un sintaxi tal que: <ArrayOfParc> <parc> <id>1</id> <nom>palma</nom> </parc> <parc> <id>2</id> <nom>manacor</nom> </parc> <parc> <id>3</id> <nom>inca</nom> </parc> </ArrayOfParc> A continuació podeu veure l exemple per desserialitzar aquests parcs inclosos en un fitxer xml a objectes dins l aplicatiu: serializer = new XmlSerializer(typeof(List<Parc>)); reader = new StreamReader(dirBase parcs = (List<Parc>) serializer.deserialize(reader); reader.close(); 42

43 L objecte principal, que conté metodes estatics, serà l encarregat de suministrar totes les dades a la resta de classes de l aplicació. És per això, que és aquest classe la encarregada de llegir en un primer moment tots els fitxers xml amb les dades. 43

44 5.2.- Llistat dinàmics. Per a la construcció dels diferents llistats que composen l aplicació ( llistat de bombers, vehicles,...) s ha optat per la generació dinàmica de menús. Donat que els controls per a dipositius PDA que són proporcionats per el compact framework són molt limitats, ha calgut dibuixar els controls de manera dinàmica a partir de les llistes de dades que composen l informe. D aquesta manera, podem veure com el llistat de bombers és generat per el mètode mostra_bombers(), que ten en compte quines seleccions de filtratge ha seleccionat l usuari, i genera els controls de tipus chekbox dins el formulari. A mida d exemple, poso el codi font d aquest mètode que és troba definit dins l objecte FormBomers, i que genera la llista de bombers disponibles. public void mostra_bombers() { // Si hi ha llistat anterior l esborrem del formulari. foreach (Control ctrl in Controls) if (ctrl is CheckBox) Controls.Remove(ctrl); // parc que es troba seleccionat al formulari Parc pselec; pselec = (Parc) cbparc.selecteditem; // graduació que es troba seleccionat al formulari String gselec; gselec = (String)cbGraduacio.SelectedItem; System.Windows.Forms.CheckBox checkbox100; int y = 40; // per cada entrada a la llista de bombers foreach (Bomber p in Principal.Bombers) { // Primera condició:si el bomber es del parc seleccionat, o //s ha seleccionat tots els parcs. // Segona condició: si el bomber te la graduació //seleccionada o s hah seleccionat Totes les graduacions. if ((pselec.id == p.parc) (pselec.id == 0)) if((gselec == "Totes") (gselec == p.graduacio)) { checkbox100 = new System.Windows.Forms.CheckBox(); // per donar color de llistat if(y % 2 == 0) checkbox100.backcolor System.Drawing.SystemColors.Control; 44

45 checkbox100.location = new System.Drawing.Point(11, y); checkbox100.size = new System.Drawing.Size(210, 20); checkbox100.tabindex = 0; checkbox100.text = p.nom + " - " + p.graduacio; checkbox100.tag = p; checkbox100.visible = true; if(llistatemp.contains(p)){ checkbox100.checked = true; }else{ checkbox100.checked = false; } checkbox100.checkstatechanged += new System.EventHandler(this.checkBox_CheckStateChanged); this.controls.add(checkbox100); y += 23; } } } El resultat final és aquest: Podem canviar la selecció, i el llistat és va generant dinàmicament. 45

46 5.3.- Control d opcions disponibles. Tal com ja havíem vist en el disseny, cada tipus d actuació defineix quines seran les característiques de l informe. Totes aquestes opcions es troben agrupades des de l objecte FormInforme ( el formulari base de cada informe)., i cal anar mostrant les mateixes a mesura que es va omplint l informe. En un primer moment, quan un informe es crea, només cal deixar entrar les dades generals ( icona de dades generals). Aquesta decisió és pren dins l objecte informe, que al no tenir el tipus d actuació definit no permet endinsarse en la resta de l informe. Això ho aconseguim mitjançant el mètode mostrabotons que pertany a FormInforme, i que s executa cada vegada que aquest formulari passa a primer pla. Aquest mètode, fa una crida amb l objecte imatge ( la icona del menú) com a paràmetre a un altre mètode definit al objecte informe, i es aquest el qui decideix quines icones han de estar en estat visible i quins no. L objecte informe, la vegada, un cop definit el tipus d actuació, delega la decisió sobre cada icona al objecte actuació que te com a atribut. A continuació mostro la part de codi de FormInforme on es fa la crida al mètode de l objecte informe: private void MostraBotons() { foreach (Control ctrl in Controls) if (ctrl is PictureBox) informe.esvisibleboto((picturebox)ctrl); } Tal com podem veure, l objecte informe s encarregarà de fer visible o no, cadascuna de es icones que hi ha contingudes al FormInforme. 46

47 5.4.- Exportació de les dades. Per a desar i enviar les dades dels nous informes generats, és generarà un fitxer xml per a cada informe. L objecte informe tindrà un mètode anomenat escriu, que serà l encarregat de serialitzar l objecte informe a un fitxer xml. Per a identificar cada informe, es genera un cadena de text, composta de la data i hora en que s ha realitzat la creació de l informe. Aquest cadena la farem servir com a identificador de cadascun dels informes, i coincidirà amb el nom del fitxer xml generat. Podem veure un exemple de serialització d un objecte en el següent fragment de codi: XmlSerializer serializer = new XmlSerializer(typeof(DadesGlobals)); TextWriter writer = new StreamWriter(dirBase serializer.serialize(writer, dadesglobals); En aquest cas, serialitzem l objecte dadesglobals de tipus DadesGLobals, que és un contenedor de les opcions personalitzades per l aplicació en cada dispositiu. Aquest objecte, entre d altres configuracions conté el Parc per defecte ( per agilitzar el filtratge en llistat de vehicles i bombers). El resultat d aquesta execució és un fitxer xml amb les següents dades: <globals> <idparc>1</idparc> </globals> Una de les condicions imposades per a poder realitzar aquestes serialitzacions, és el fet de que els atributs que volem que siguin exportats a xml han de ser forçosament públics. Això ha implicat alguns canvis de disseny sobre l original. Concretament, tant en el moment de desar o be carregar les dades d un informe, s ha de fer un preprocés per fer publics els atributs que ens calen per fer la exportació a XML. El prepocès, consisteix a moure els atribut/s que ens interesa desar de cada objecte ( normalment l identificador) a una llista de tipus pública ( per a que pugui ser exportada). D aquesta manera només desem les dades que són estrictament necessàries. El cas contrari, és en el moment de fer la càrrega, on a partir dels identificadors que hem desat anteriorment, cerquem l objecte que ens ha instanciat Principal a partir dels xml que ens arriben de la intranet. 47

48 5.5- Opció d Imatges. El dispositiu realitza fotografies amb el seu propi aplicatiu de camera fotogràfica. Aquestes són desades en un directori concret. La nostre aplicació, permet seleccionar les imatges que han d adjuntar-se al informe, a partir de les fotografies que s han realitzat. Per a fer això, la opció imatges, llegeix aquest directori, i mostra en versió reduïda, aquelles que no fa més de 48 hores que s han fotografiat, o be aquelles que ja pertanyen al informe. DirectoryInfo dir = new DirectoryInfo(dirImatges); FileInfo[] files = dir.getfiles("hpim*.jpg"); int ni = 0; foreach (FileInfo f in files) { Condició: nomes aquelles que ja pertanyen a l informe, o be les que fa menys de 48 h que s han realitzat. if (!imatgesinforme.containskey(f.name)) imatgesinforme.add(f.name, false); bool dinsinforme = imatgesinforme[f.name]; if (mostrainforme &&! dinsinforme) continue; if (!dinsinforme && ((DateTime.Now - f.creationtime) > new TimeSpan(48, 0, 0))) continue; int y = (ni / 2) * (MRG + ALT + MRG + SEP); int x = (MRG + AMP + MRG + SEP) * (ni % 2); Panel panel = new Panel(); panel.location = new System.Drawing.Point(x, y); panel.size = new System.Drawing.Size(MRG + AMP + MRG, MRG + ALT + MRG); panel.backcolor = (dinsinforme? colorsel : colornosel); PictureBox pb = new PictureBox(); pb.location = new System.Drawing.Point(MRG, MRG); pb.size = new System.Drawing.Size(AMP, ALT); Bitmap bm = new Bitmap(f.FullName); pb.image = new Bitmap(AMP, ALT); Graphics gr = Graphics.FromImage(pb.Image); Reducció de la imatge. gr.drawimage(bm, new System.Drawing.Rectangle(0, 0, AMP, ALT), new System.Drawing.Rectangle(0, 0, bm.width, bm.height), GraphicsUnit.Pixel); Afegim el nom de la imatge. gr.drawstring(f.name, new Font(System.Drawing.FontFamily.GenericMonospace, 8, 48

49 FontStyle.Regular), new SolidBrush(Color.White), MRG, ALT - 15); pb.click += new System.EventHandler(imatge_Click); pb.tag = panel; panel.tag = f.name; panel.controls.add(pb); Controls.Add(panel); bm.dispose(); ni += 1; } La reducció de cadascuna de les imatges es realitza en temps real, i a més, hi afegim, a cadascuna el nom de la mateixa per a major control per part de l usuari. El dispositiu triga en mostrar les imatges disponibles, doncs li requereix un procés important. El resultat final és aquest: * aquesta opció només funciona correctament quan s executa amb la PDA, i no funciona per falta de recursos amb l emulador que incorpora Visual Studio. 49

50 5.6- Sincronització La sincronització amb el servidor, on resideix tota la aplicació central que enregistra els informes elaborats, és realitzarà mitjançant protocol http, com si d un post web es tractés. Aquesta manera de realitzar la sincronització, ha vingut donada pel propi client, donat les mides de seguretat que hi ha a la xarxa interna del Consell, que no permetien cap altre tipus de protocol o port que no fos el port web. A més, donat que la interfície de la aplicació general de bombers, funciona dins l àmbit d una intranet privada, el fet que enviem les dades com si es tractes d un formulari web fa que les modificacions en aquesta aplicatiu servidor siguin poques. En el moment de enviar informes, la aplicació client també aprofita per actualitzar les dades relatives al funcionament de la mateixa aplicació. Dades com els bombers que hi ha disponibles en cada parc, disponibilitat de vehicles, o la incorporació de nous mitjans per a les intervencions. Per a la implementació d aquesta sincronització per post, he fet servir una classe anomenada httpupload, amb la que gestionar l enviament de l informe per post. Tal com podeu veure en l exemple ens ha posat les coses molt més fàcils: Informe informeactualitzar; List<HttpFileUpload.UploadSpec> llistaimatges; informeactualitzar = Informe.carrega(Principal.DirInformes + lbinformes.text); llistaimatges = new List<HttpFileUpload.UploadSpec>(informeActualitzar.Imatges.Count); foreach (String s in informeactualitzar.imatges){ llistaimatges.add(new HttpFileUpload.UploadSpec((String) Principal.DirImatges + s,s)); } + Principal.UriBase null, null, llistaimatges.toarray() ); I així s envia el fitxer xml amb tota la informació del informe juntament amb les imatges que hi pertanyen. Un cop sincronitzat l informe, és eliminat junt amb les imatges del dispositiu local. 50

51 6.- Un passeig per l aplicació. Pantalla d inici de l aplicació. A continuació se li mostren les dades que ja pot omplir del informe, les més bàsiques d una actuació. 51

52 El procés normal serà escullir les dades generals, i un cop seleccionada el tipus d actuació el menú de l informe mostrarà totes les opcions relacionades amb el tipus d actuació. El menú informe, ara mostrarà totes les opcions possibles per a aquest tipus d actuació. 52

53 A continuació, algunes de les pantalles més importants de l aplicatiu: Afegir víctima. Gestió de les víctimes introduïdes. 53

54 Selecció d imatges. Apartats per a definir com ha sigut l incendi. 54

55 Afegir un be sinistrat. Indicar mitjans que s han fet servir en la intervenció. 55

56 Gestió d informes emmagatzemats. Un cop sincronitzat s informa la usuari i l informe s elimina del dispositiu. Existeixen més opcions, però aquestes són prou representatives per a veure el tipus d aplicació que s ha desenvolupat. 56

57 7- Conclusions. Aquest ha estat un treball molt enriquidor que ha permès treballar amb la plataforma de desenvolupament de.net. En concret, amb l ús del seu Compact Framework, una versió reduïda del producte, per a poder desenvolupar aplicacions per PDA. Aquest mateix producte, permet també desenvolupar aplicacions per a mòbils, la qual cosa obre moltissimes possibilitats alhora de pensar en noves aplicacions. La eina, està pensada per facilitat la feina al programador. S avança en la escriptura, i des de la mateixa línia de comandes et va mostrant els atributs/mètodes de l objecte amb el que estàs treballant. En quant al ús de dipositius mòbils, és una realitat el fet que cada dia van guanyant terreny tant en l àmbit professional com en d altres, i que cada cop serà necessari noves aplicacions per aquest tipus de dispositiu. Com a conclusions directament relacionades amb aquest projecte, voldria remarcar l aprenentatge que s ha realitzat de la tecnologia.net. Concretament, sobre els dispositius mòbils, he pogut també abordar la problemàtica directament relacionada amb els pocs controls que aporta el Compact FrameWork ( massa senzills de vegades ), i la poca pantalla de la que disposem. Això fa, que a més a més del disseny de la lògica correcte, s hagi de posar especial cura en els aspectes d usabilitat, i fer les aplicacions el més fàcil i usable possible. En concret, en aquest projecte, s ha intentat que el procés d introducció d informació sigues el més semblant possible a omplir un informe en paper amb els camps preparats amb anterioritat, on només s hagi d anar seleccionat aquells apartats que són necessaris. També, ens hem pogut adonar, que amb la capacitat actual de processament posar limitacions a determinades opcions com el tractament d imatges en temps real. Finalment, voldria comentar, que el feedback amb el client ha estat molt positiu. S ha mostrat molt entusiasmat amb aquest aplicatiu, i ja s està parlant de la possibilitat de desenvolupar un altre per a la gestió de les incidències en carreteres. Això demostra, que el camp dels dispositius mòbils, és un camp obert a nous desenvolupament, i que amb molta probabilitat no serà la darrera aplicació mòbil, i amb tecnologia.net que desenvolupi. 57

Sitemap