Memòria TFC PDF

Dedicatria
A tots els que em van preguntar,

Qu? Com portes el projecte?
Agraments
A lEscola Universitria Politcnica de Matar, per ser una excellent casa destudis.
Als meus pares i avis per donar-me loportunitat destudiar una carrera i donar-me
suport contnuament.
A Jordi Diu per animar-me i ajudar-me en tot moment.
A tota la gent que no ha deixat de recolzar-me.
Al professor Josep Roure Alcob, pels seus consells, orientaci i pacincia com a
ponent daquest projecte.
Resum
Tallers Sacreu S.C.C.L s una petita empresa de reparaci de vehicles que amb el pas del
temps ha vist com el sistema de gesti del seu negoci ha quedat obsolet. Actualment
funciona amb fulls de clcul i processadors de text, i existeix una manca important dordre.
Per tant, necessita modernitzar i estructurar la gesti el taller. El segent projecte pretn
assolir lobjectiu de millorar la gesti, oferir a aquesta empresa l'agilitzaci de tots els seus
processos i evitar la prdua de dades mitjanant l'elaboraci d'una aplicaci que permetr
controlar de forma centralitzada tots les funcions i processos del taller, referents a la
facturaci.
Resumen
Talleres Sacreu S.C.C.L es una pequea empresa de reparacin de vehculos que con el
paso del tiempo ha visto como el sistema de gestin de su negocio ha quedado obsoleto.
Actualmente funciona con hojas de clculo y procesadores de texto, y existe una carencia
importante de orden. Por lo tanto, necesita modernizar y estructurar la gestin el taller. El
siguiente proyecto pretende lograr el objetivo de mejorar la gestin, ofrecer a esta empresa
la agilizacin de todos los sus procesos y evitar la prdida de datos mediante la elaboracin
de una aplicacin que permitir controlar de forma centralizada todos las funciones y
procesos del taller, referentes a la facturacin.
Abstract
Talleres Sacreu S.C.C.L is a small company of repair of vehicles that with the passage of
time one has seen as the system of management of its business has remained obsolete.
Nowadays it works with leaves of calculation and processors of text, and an important lack
of order exists. Therefore, the management needs to modernize and to construct the
workshop. The following project tries to achieve the lens to improve the management, to
improve to this company the streamlining of all them its processes and to improve the loss
of information by means of the production of an application that will allow to control of
centralized form all the functions and processes of the workshop, modal to the invoicing.
ndex general
Dedicatria............................................................................................................................ II
Agraments .......................................................................................................................... IV
Resum .................................................................................................................................. VI
ndex general .................................................................................................................... VIII
ndex figures .......................................................................................................................... 1
ndex taules ............................................................................................................................ 1
1. Introducci ................................................................................................................... 1
1.1. Descripci del client ............................................................................................. 1
1.2. Funcionament del taller ......................................................................................... 2
2. Objectius ....................................................................................................................... 3
2.1. Objectiu general .................................................................................................... 3
2.2. Objectius especfics .............................................................................................. 3
3. Pressupost ..................................................................................................................... 5
3.1. Planificaci ........................................................................................................... 5
3.2. Cost ....................................................................................................................... 6
3.2.1. Personal ..................................................................................................... 6
3.2.2. Software .................................................................................................... 6
3.2.3. Hardware ................................................................................................... 7
3.2.4. Total .......................................................................................................... 7
4. Anlisi ........................................................................................................................... 9
4.1. Restriccions funcionals ......................................................................................... 9
4.1.1. Clients ....................................................................................................... 9
4.1.2. Contactes ................................................................................................... 9

4.1.3. Bancs ......................................................................................................... 9
4.1.4. Vehicles..................................................................................................... 9
4.1.5. Provedors ................................................................................................. 9
4.1.6. Factures Clients ....................................................................................... 10
4.1.7. Factures Provedors ................................................................................. 10
4.1.8. Altres ....................................................................................................... 10
4.2. Requeriments no funcionals ............................................................................... 10
4.3. Diagrama de casos ds ...................................................................................... 12
4.4. Especificaci de casos ds ................................................................................ 14
4.4.1. Gesti Clients .......................................................................................... 14
4.4.2. Gesti Provedors .................................................................................... 19
4.4.3. Gesti Contactes ..................................................................................... 24
4.4.4. Gesti Vehicles ....................................................................................... 28
4.4.5. Gesti Factures Provedors ..................................................................... 32
4.4.6. Gesti Factures Clients ........................................................................... 34
4.4.7. Gesti de bancs ....................................................................................... 37
4.4.8. Gesti Ordres de Taller ........................................................................... 40
4.4.9. Gesti Tarifes .......................................................................................... 42
4.4.10. Gesti Pasos ........................................................................................... 45
4.4.11. Gesti Provncies .................................................................................... 47
4.4.12. Gesti Poblacions.................................................................................... 49
4.4.13. Gesti Codis Postals ............................................................................... 51
4.4.14. Gesti Operacions ................................................................................... 53
4.4.15. Gesti Material........................................................................................ 55
4.5. Diagrama de Classes del Domini ........................................................................ 59
4.6. Digrames de seqncia del sistema .................................................................... 62
4.6.1. Cas ds Alta Ordre Taller .................................................................. 62

4.6.2. Cas ds Alta Factura Client ................................................................ 63
5. Disseny ........................................................................................................................ 65
5.1. Patr arquitectnic .............................................................................................. 65
5.1.1. Capa Presentaci ..................................................................................... 66
5.1.2. Capa Aplicaci ........................................................................................ 67
5.1.3. Capa Domini ........................................................................................... 68
5.2. Patrons de Disseny .............................................................................................. 69
5.2.1. Singleton ................................................................................................. 69
5.2.2. Factoria .................................................................................................... 70
5.2.3. Indirecci................................................................................................. 70
5.2.4. Controlador ............................................................................................. 71
5.3. Base de dades ...................................................................................................... 71
5.3.1. Model conceptual .................................................................................... 73
5.3.2. Model relacional...................................................................................... 75
5.3.3. Regles de negoci ..................................................................................... 77
5.3.4. Seqncies ............................................................................................... 78
5.4. Diagrama de seqncia del cas ds AltaOrdreTaller ..................................... 79
6. Implementaci ............................................................................................................ 81
6.1. Interfcie grfica .................................................................................................. 81
6.2. Controladors ........................................................................................................ 84
6.3. Interfcies i Factoria de Registres........................................................................ 85
6.4. Persistncia ......................................................................................................... 85
7. Conclusions ................................................................................................................ 89
Annex II- PSP (Procs Software Personal) ..................................................................... 95
Annex III Contingut del CD ........................................................................................ 105
Bibliografia ....................................................................................................................... 107

ndex figures
Figura 1: Grfic Costos ........................................................................................................ 8

Figura 2: Diagrama de casos d's ....................................................................................... 12
Figura 3: Diagrama de Classes del Domini ........................................................................ 59
Figura 4: Interfcies i Factoria Registres ............................................................................ 61
Figura 5: Diagrama de seqncia dels sistema (altaOrdreTaller) ...................................... 62
Figura 6: Diagrama de seqncia del sistema (altaFacturaClient) ..................................... 63
Figura 7: Esquema MVC 4 capes ....................................................................................... 65
Figura 8: Patr Singleton a la classe ConnexioBD ............................................................ 69
Figura 9: Patr Factoria a FactoriaRegistres ...................................................................... 70
Figura 10: Model Conceptual de la Base de Dades .......................................................... 73
Figura 11: Model Relacional de la Base de Dades............................................................. 75
Figura 12: Diagrama de seqncia AltaVehicle 1 .............................................................. 79
Figura 13: Diagrama altaOrdreTaller 2 .............................................................................. 80
Figura 14: Finestra selecciAlta ......................................................................................... 81
Figura 15: JClalendar de Toedter ....................................................................................... 83
Figura 16: Finestra IDClient .............................................................................................. 83
Figura 17: Finestra altaVehicle .......................................................................................... 84
ndex taules
Taula 1: Planificaci de tasques ........................................................................................... 5

Taula 2: Cost del personal .................................................................................................... 6
Taula 3: Cost del software .................................................................................................... 6
Taula 4: Cost del hardware ................................................................................................... 7
Taula 5: Cost Total ............................................................................................................... 7
Taula 6: Cuadre-Resum dequivalncies entre Mtrica v3 i el PSP ................................. 104
Taula 7: Cuadre-Resum dequivalncies entre UP i el PSP ............................................. 104
Gesti Tallers Sacreu, s.c.c.l. - 1
1. Introducci
1.1. Descripci del client
Aquesta aplicaci est dissenyada i desenvolupada seguint les necessitats dun

client real, Tallers Sacreu S.C.C.L.
Tallers Sacreu, S.C.C.L s una empresa dedicada des de fa ms de 25 anys a la

reparaci general dautombils, especialment de vehicles industrials, (camions, grues,
bobcats, etc ...). Empresa dmbit local i situada al cap de munt de la riera de lEixample
dArenys de Munt, sha consolidat amb una cartera de clients fixes darreu de la comarca,
tant empreses com particulars. Estem parlant de ms de 250 clients que al llarg de lany
passen a fer les revisions i reparacions al seus vehicles. El volum de factures entre lany
passat i aquest ha disminut a causa de la crisis econmica. Sha calculat que aquest any es
pot arribar, entre 320 i 350 factures, uns 80.000 euros bruts a lany.
Pel que fa als provedors, actualment treballen amb ms duna cinquantena de

provedors habituals i altres despordics, depenent de les promocions que els fan (ofertes,
rpels,...). Entre els provedors amb els que treballa shi troben provedors de serveis
(identificats pel pla comptable de 1991, amb lidentificador 410), provedors ordinaris, s a
dir provedors de mercaderies, matries primeres etc, (identificats amb el 400) i finalment
amb Administracions Pbliques (identificades amb el 47).
La necessitat daquest software es deu a que el sistema dinformaci del tallers sha
quedat obsolet, s a dir, treballen a fulls de clcul i editors de text. El problema daquest
sistema de treball s la prdua dinformaci i el poc control de gesti sobre clients,
provedors i la facturaci. Lobjectiu daquesta aplicaci s resoldre aquest problema de la
gesti i sobretot solucionar el problema de la prdua dinformaci. A ms, permetr
agilitzar els processos relacionats amb la gesti de clients, provedors i factures.
Introducci - 2
1.2. Funcionament del taller
Fins a dia davui el funcionament del taller s com el de fa molts anys, un taller
petit de poble i el tracte amb els clients es cordial per alhora molt personalitzat i de
confiana . Els clients sapropen al taller o en cas de no poder portar el vehicle sels hi va a
buscar al seu domicili. No es fa cap mena de pressupost previ formal, sin que
senzillament es fa de paraula i aproximatiu.
Cada cop que entra un vehicle al taller se li crea una fitxa de reparaci amb la data,
el numero de reparaci, marca i matricula del vehicle. Sovint si el mateix client porta a
reparar un vehicle, mentre encara nhi ha algun altre seu al taller, saprofita la mateixa fitxa
de reparaci. Quan es parla de fitxa de reparaci, fa referncia al que posteriorment es la
factura de reparaci del vehicle o vehicles.
Pel que fa a les factures de clients, el venciment s de 30 o 60 dies. El clients

decideixen si volen que el pagament de les factures li siguin domiciliades al seu compte
bancari o pel contrari poden pagar de la forma que els hi sigui ms cmode.
El tracte amb els provedors s excellent, treballen amb provedors propers al taller
o que els hi poden servir els materials en qesti dhores. Aquest tracte amb els provedors
s molt convenient que sempre resti excellent, ja que al ser un taller multi marca, s a dir,
reparen vehicles de tot tipus i marques, i cada tipus i model de marca utilitza un material o
peces diferents. No disposen destoc de material al taller.
Gesti Tallers Sacreu, s.c.c.l. - 3
2. Objectius
2.1. Objectiu general
Desenvolupar una aplicaci:

Escalable.
Usable (Facilitat ds).
Econmica .
A mida, pensada exclusivament per al sector dels petits tallers mecnics i ms
concretament en client,Tallers Sacreu, S.c.c.l, que no tenen un gran volum de
treball ni guarden un estoc concret de cada material.
Mantenible.
Robusta.
2.2. Objectius especfics
Resoldre el problema de la gesti de clients, provedors i facturaci.

Resoldre el problema de la prdua de dades.
Desenvolupar una interfcie grfica elaborada, per tal, de reduir al mxim els errors
dintroducci de dades per part de lusuari.
Conixer internament la gesti dun taller mecnic dautombils.
Desenvolupar una aplicaci robusta, eficient i escalable.
Experimentar en primera persona el desenvolupament integral duna aplicaci per a
un client real.
Conservar els principis bsics de la programaci orientada a lobjecte.
Ampliar coneixements en la plataforma J2SE.
Aplicar els coneixements adquirits al llarg de la carrera, en el desenvolupament
dun software de gesti, com la utilitzaci de patrons arquitectnics, patrons de
disseny, etc..
Gesti Tallers Sacreu, s.c.c.l. -5
3. Pressupost
3.1. Planificaci
Tasques Duraci (en hores)
Entrevistes amb el client 10 h
Especificaci de requeriments 5h
Diagrama de casos ds 1h
Especificaci de casos ds 10 h
Anlisi deines i tecnologies 3h
Anlisi de lestructura de laplicaci 5h
Elaboraci pressupost 2h
Diagrama de classes 15 h
Model conceptual 35 h
Programaci de la interfcie grfica 50 h
Programaci dels casos ds 240 h
Documentaci 20 h
Testing 15 h
TOTAL 411 h
Taula 1. Planificaci de tasques

6 - Pressupost
3.2. Cost
3.2.1. Personal
Hores Preu/hora
411 h 12 /h
TOTAL 4.939
Taula 2. Cost del personal
3.2.2. Software
Producte Preu
Incls en
Microsoft Windows Vista Premium OEM
hardware
Microsoft Office Student 2007 88
NetBeansIDE 6.5.1 Gratut
Sybase PowerDesigner 15 Versi Prova
MySQL Gratut
SQLyog Gratut
TOTAL 88
Taula 3. Cost del software

3.2.3. Hardware
Equip Preu Amortitzaci (4 mesos)
Asus M51VA 850 283
TOTAL 283
Taula 4. Cost del hardware
3.2.4. Total
Concepte SubTotal
Cost del personal 4.939
Cost del software 88
Cost del hardware 283
TOTAL 5.310
Taula 5. Cost Total

8 - Pressupost
Grfic de Costos
5% 2%
Personal
Hardware
Software
93%
Figura 1. Grfic Costos

4. Anlisi
4.1. Restriccions funcionals
4.1.1. Clients
Lidentificador ha de comenar per 43 i ha de tenir 6 dgits.

No es poden donar de baixa clients amb factures relacionades, amb la
diferncia de la data actual a la data demissi de la factura menor a 5 anys.
Si un client canvia de nif no es pot modificar, sha de crear un de nou.
4.1.2. Contactes
No pot existir un contacte sense dades de telfons, mbils, faxs o correus
electrnics.
No pot existir un contacte sense client o contacte.
No es pot crear un contacte dun client o provedor donat de baixa.
4.1.3. Bancs
Un client o provedor no poden tenir 2 bancs predefinits alhora.
No es pot associar o crear un banc a un client o provedor donat de baixa.
4.1.4. Vehicles
No pot existir un vehicle sense client.

No es pot crear o modificar un vehicle a un client donat de baixa.
4.1.5. Provedors
Lidentificador ha de comenar per 40, 41 o 47.

No es poden donar de baixa provedors amb factures relacionades, amb la
diferncia de la data actual a la data demissi de la factura menor a 5 anys.
Si un provedor canvia de nif no es pot modificar, sha de crear un de nou.
10 - Anlisi
4.1.6. Factures Clients
No es poden fer factures a cotxes donats de baixa.

El venciment no pot ser anterior a la data demissi.
Les factures sempre han de ser amb iva incls.
El total duna factura pot ser negatius, per si alguna retroacci.
Si hi ha ja hi ha factures introdudes, el mes demissi de la segent factura ha
de ser igual o posterior a les introdudes al sistema.
No es poden modificar si el llistat dives on esta incls sha tancat.
4.1.7. Factures Provedors
No es poden crear factures de provedors donats de baixa.

Els nmeros de factura (identificador) han de correlatius al llarg de lany i cada
1 de gener es torna a comenar des de 1.
El total de la factura pot ser negatiu si es un abonament.
En el cas que la factura emesa per un provedor tingui diferents tants per cent,
es crear una nova factura provedor per a cada tant per cent.
Una factura pot tenir iva i irpf alhora.
4.1.8. Altres
Un codi postal noms pot estar associat a una poblaci.

Una poblaci noms pot ser duna provncia.
Una provncia noms s dun pas.
No poden existir 2 tipus doperacions iguals.
No poden existir 2 tipus de material iguals.
4.2. Requeriments no funcionals
Laplicaci ha destar desenvolupada en Java.

El motor de la base de dades ha de ser MySQL.
Sistema escalable, robust i rpid.

El sistema operatiu que ha de suportar ha de ser Windows.
Sha de treballar de manera gil i aplicant el Patr Model Vista Controlador 4
capes.
La interfcie ha de ser senzilla, cmode i intutiva.
La interacci amb lusuari ha de ser fluida.
12 - Anlisi
4.3. Diagrama de casos ds
Figura 2. Diagrama de casos d's

Gesti Client: Consta de tres casos ds: Alta Client, Baixa Client i Modificaci
Client.
Gesti Provedor: Consta de tres casos ds: Alta Provedor, Baixa Provedor i
Modificaci Provedor.
Facturaci: Engloba dos casos:
o Gesti Facturaci Provedors: Consta de tres casos ds: Alta Factura de
Provedor, Baixa Factura de Provedor, Modificaci Factura Provedor.
o Gesti Factura Clients: Consta de dos casos ds: Alta Factura Clients i
Modificaci Factura Provedors.
Gesti Contactes: Consta de tres casos ds: Alta Contacte, Baixa Contacte,
Modificaci Contacte.
Gesti Bancs: Consta de tres casos ds: Alta Compte Bancari, Baixa Compte
Bancari, Modificaci Compte Bancari.
Gesti Vehicles: Hi ha 3 casos ds, Alta Vehicle, Baixa Vehicle, Modificaci
Vehicle.
Llistar: En aquest cas ds es creen diferents llistes:
o Llistar iva: Creaci de llistes dives mensuals, tant de provedors com de
clients.
o Llistar Clients: Es crea la llista del clients de lempresa Talleres Sacreu
s.c.c.l.
o Llistar Provedors: Crea la llista de provedors relacionat amb Tallers
Sacreu s.c.c.l.
Gesti Administraci: shi engloba tot el que fa referncia a la configuraci del
dades del sistema, es dir, les dades de configuraci de lusuari del sistema, sense
aquestes dades introdudes el sistema no pot executar la majoria de casos ds. Sha
fet aquests casos dus per evitar errors dintroducci de dades per part d lusuari.
Aquest cas ds s que ms nengloba, fins a un total de set.
o Gesti Tarifes: Configura els diferents preus preus/hora dels que disposa el
taller. Com les altres gestions consta de dAlta Tarifa, Modificar Tarifa i
Baixa Tarifa.
o Gesti Pas: Consta dAlta Pas i Baixa Pas.
o Gesti Provncies: Consta de 2 casos ds Alta Pas i Baixa Pas.
o Gesti Poblaci: Com les anteriors, Alta poblaci i Modificar Poblaci.
14 - Anlisi
o Gesti Codis Postals: consta de Alta Codi Postal i Baixa Codi Postal.
o Gesti Operacions: Alta i Modificaci Operacions.
o Gesti Material: Alta Material i baixa Material.
Aquest ltims 6 casos sn nicament per evitar duplicacions errnies a la base de

dades. Per exemple, si ja hi les poblacions a dins de la bases de dades, sevita que lusuari
un cop insereixi Matar i un altre cop Mataro (una vegada amb accent i una altre
sense).
4.4. Especificaci de casos ds
4.4.1. Gesti Clients
Cas ds Alta Client
Actor/s: Usuari.
El cas ds pot finalitzar sempre que lusuari ho desitgi.
Pre-Condicions
1. Parmetres dadministraci del sistema introduts al sistema (Tipus de tarifes,

pasos, provncies i poblacions).
Post-Condicions
1. El client que enregistrat.

2. Si hi ha dades del contacte, contacte enregistrat.
3. Si hi ha dades del banc, banc enregistrat.
Flux Normal
1. Lusuari inicia el cas ds Alta Client.

2. El sistema demana el Nif del nou client.
3. Lusuari introdueix el Nif.
4. Lusuari confirma la introducci del Nif.

5. El sistema comprova el Nif.
6. El sistema mostra el formulari per introduir les dades fiscal, els contactes i el
nmero de compte del client. Les dades demanades sn: identificador de client,
data dalta, nom i cognoms (en cas de persones), nom comercial i nom fiscal ( en
cas dempreses), nif, direcci postal , direcci fiscal, pas, provncia, poblaci, codi
postal, web (en cas dempreses) , tarifa aplicada,nom del contacte,telfons, telfons
mbils,faxs, correus electrnics, nom banc, entitat, oficina, dgit de control, numero
de compte .
7. Lusuari introdueix les dades del client (identificador de client, data dalta, nom i
cognoms (en cas de persones), nom comercial i nom fiscal ( en cas dempreses),
direcci postal , direcci fiscal, pas, provncia, poblaci, codi postal, web (en cas
dempreses) , tarifa aplicada), en cas de que tingui algun tipus dinformaci del
contacte( telfons, telfons mbils, faxs o correus electrnics) tamb la introdueix, i
finalment si t en numero de compte del contacte tamb el pot introduir (nom del
banc, entitat, oficina, dgit de control i numero de compte).
8. Lusuari confirma les dades introdudes prement el boto acceptar
9. El sistema valida les dades.
10. El sistema necessita confirmaci de que les dades son correctes.
11. Lusuari prem S.
12. El sistema demana si es volen introduir vehicles del nou client.
13. Lusuari prem S.
14. El sistema inicia el cas ds Alta vehicle des del punt 2.
15. Finalitza el cas ds Alta Client.
Flux Alternatiu
4.1. El sistema detecta que el Nif es incorrecte.

4.1.1. Retorna al punt 2.
4.2. El sistema detecta que el Nif esta repetit.
4.2.1 Retorna al punt 2.
4.3. El sistema detecta que el Nif pertany a un provedor.
16 - Anlisi
4.3.1. El sistema demana si es volen copiar les dades fiscals del provedor al nou
client.
4.3.2. Es va directament al punt 6, on les dades ja estan en el formulari per si sen
desitja modificar alguna.
4.4. El sistema detecta que el Nif s dun client donat de baixa.
4.4.1. El sistema demana si es vol caviar lestat del client, destar donat de baixa a
estar donat dalta.
4.4.2. Sinicia el cas ds Modificar Client en el punt 4, on les dades ja estan en el
formulari per si sen desitja modificar alguna.
4.4.3. Finalitza el cas ds Alta Client.
7.1. El sistema detecta que hi ha alguna dada incorrecte.
7.1.1. Retorna al pas 7.
11.1. Lusuari prem No.
11.1.1. El sistema retorna fins al punt 8.
13.1. LUsuari prem No.
13.1.1 Finalitza el cas ds.
Cas ds Modificar Client
Actor: Usuari.
El cas ds pot finalitzar lusuari desitgi.
Sense sortir del cas ds es pot saltar cap al cas ds Modificar Contactes , Modificar
Bancs i Modificar Vehicles per noms del client seleccionat.
Pre-Condicions
1. Tenir almenys un client donat a la base de dades.

Post-Condicions
1. Emmagatzemar les noves dades del client.

Flux Normal
1. Lusuari inicia el cas ds Modificar Client.

2. El sistema mostra el llistat de tots els clients emmagatzemats a base de dades tant
actius com donats de baixa.
3. Lusuari selecciona el client desitjat de llista i accepta.
4. El sistema mostra el formulari amb les segents dades del client que es vol
modificar. Dades que mostra: identificador de client, data dalta, nom i cognoms
(en cas de persones), nom comercial i nom fiscal ( en cas dempreses), direcci
postal , direcci fiscal, pas, provncia, poblaci, codi postal, web (en cas
dempreses) , tarifa aplicada i si esta actiu o donat de baixa.
5. Lusuari modifica les dades que necessiti canviar, nom i cognoms (en cas de
persones), nom comercial i nom fiscal ( en cas dempreses), direcci postal ,
direcci fiscal, pas, provncia, poblaci, codi postal, web (en cas dempreses) ,
tarifa aplicada i si esta actiu o donat de baixa.
9. Lusuari prem S.
10. El sistema realitza lacci.
11. El sistema pregunta si es desitja sortir del cas ds o si es volen modificar dades
dels contactes o dels bancs.
12. Lusuari prem No.
13. El sistema surt del cas ds.
Flux alternatiu
7.1. El sistema detecta errors en les noves dades introdudes.

7.1.1. Retorn al pas 5.
12.1. Lusuari prem S.
18 - Anlisi
12.1.1. El sistema pregunta quines dades es volen modificar, mostrant 4 opcions,

Dades Contacte , Dades Banc, Dades Vehicle, Cancellar, si el client no t
alguna de les dades el bot est desactivat .
12.1.2. Lusuari fa la selecci dalguna de les opcions a les quals tingui accs.
12.1.3. El sistema inicia el cas ds referent a lopci escollida per lusuari.
Cas ds Baixa Client
Actor: Usuari.
El cas ds pot finalitzar quan lusuari ho desitgi.
Pre-Condicions
1. Tenir clients actius a la base de dades.

2. El clients que es desitgin donar de baixa no poden tenir factures en els ltims 5
anys, per raons fiscals.
Post-Condicions
1. Client donat de baixa a la base de dades.

2. Si es dna el cas, i t contactes o bancs que no comparteixi amb cap provedor
tamb es donen de baixa.
3. Si t algun vehicle, aquest tamb es dna de baixa.
4. Si t alguna factura posterior a 5 anys tamb selimina, permanentment de la base
de dades.
Flux normal
1. Lusuari inicia el cas ds Donar de Baixa Client.

2. El sistema mostra un llistat del clients actius.
3. Lusuari selecciona el client que desitja eliminar i confirma la selecci.
4. El sistema comprova que no t cap factura en els ltims cinc anys.
5. El sistema mostra les totes les dades del client, tots el contactes relacionats, tots els
vehicles relacionats i les dades bancries .
6. Lusuari prem el bot Acceptar.
7. El sistema pregunta si esta segur de voler donar de baixa el client seleccionat.
8. Lusuari prem S.
9. El sistema dna de baixa el client i si es dona el cas tamb dna de baixa els seus
contactes , les seves dades bancries i els seus vehicles, sempre i quan no estiguin
relacionats amb un provedor.
10. Finalitza el cas ds.
Flux alternatiu
4.1. El sistema detecta que existeixen factures en els ltims cinc anys del client.
4.1.1. El sistema informa al usuari de la incidncia.
4.1.2. Surt del cas ds.
4.4.2. Gesti Provedors
Cas ds Alta Proveidor
Actor: Usuari
Pre-Condicions
1. Parmetres dadministraci del sistema introduts al sistema ( pasos, provncies i

poblacions).
Post-Condicions
1. El provedor queda enregistrat.

20 - Anlisi
2. Si hi ha dades del contacte, contacte enregistrat.

3. Si hi ha dades del banc, banc enregistrat.
Flux Normal
1. Lusuari inicia el cas ds Alta Provedor.

2. El sistema demana el Nif del nou client.
3. Lusuari introdueix el Nif.
4. Lusuari confirma la introduccio del Nif.
5. El sistema comprova el Nif.
6. El sistema mostra el formulari per introduir les dades del Provedor. Les dades
fiscals del provedor sn: identificador de provedor, data dalta, nom i cognoms
(en cas de persones), nom comercial i nom fiscal ( en cas dempreses), direcci
postal , direcci fiscal, pas, provncia, poblaci, codi postal, web (en cas
dempreses),nom del contacte,telfons, telfons mbils,faxs, correus electrnics,
nom banc, entitat, oficina, dgit de control, numero de compte .
7. Lusuari introdueix les dades del provedor,( identificador de provedor, data dalta,
nom i cognoms (en cas de persones), nom comercial i nom fiscal ( en cas
dempreses), direcci postal , direcci fiscal, pas, provncia, poblaci, codi postal,
web (en cas dempreses)) i si existeixen tamb introdueix les dades referents a
contacte (nom del contacte,telfons, telfons mbils,faxs, correus electrnics) i al
banc (nom banc, entitat, oficina, dgit de control, numero de compte).
10. El sistema requereix confirmaci de que les dades introdudes son correctes.
11. Lusuari prem S.
12. Si hi ha alguna dada del contacte del provedor ,el sistema demana si es volen
introduir ms contactes del nou provedor.
14. Finalitza el cas ds Alta Provedor
Flux Alternatiu
4.1. El sistema detecta que el Nif es incorrecte.

4.1.2. Retorna al punt 2.
4.2. El sistema detecta que el Nif esta repetit.
4.2.1 Retorna al punt 2.
4.3. El sistema detecta que el Nif pertany a un client.
4.3.1. El sistema demana si es volen copiar les dades personals del client al nou
provedor.
4.3.2. Es va directament al punt 6, on les dades ja estan en el formulari.
11.1.1. El sistema retorna al pas 8.
13.1. Lusuari prem S
13.1.1. El sistema inicia el cas ds Alta Contacte des del punt 4.
Cas ds Modificar Provedor
Actor: Usuari
Lusuari pot sortir del cas ds quan ho desitgi.
Pre-Condicions
1. Tenir almenys un provedor donat a la base de dades.

2. Parmetres dadministraci del sistema introduts al sistema (pasos, provncies i
poblacions).
Post-Condicions
1. Emmagatzemar les noves dades del provedor.
Flux Normal
1. Lusuari inicia el cas ds Modificar Provedor.

22 - Anlisi
2. El sistema mostra el llistat de tots els provedors emmagatzemats a base de dades

tant actius com donats de baixa.
3. Lusuari selecciona el provedor desitjat de llista i accepta.
4. El sistema mostra el formulari amb les dades del provedor que es vol modificar.
Dades que mostra: identificador de provedor, data dalta, nom i cognoms (en cas
de persones), nom comercial i nom fiscal ( en cas dempreses), direcci postal ,
direcci fiscal, pas, provncia, poblaci, codi postal, web (en cas dempreses) i si
esta actiu o donat de baixa.
5. Lusuari modifica les dades que necessiti canviar, nom i cognoms (en cas de
persones), nom comercial i nom fiscal ( en cas dempreses), direcci postal ,
direcci fiscal, pas, provncia, poblaci, codi postal, web (en cas dempreses) , i si
9. Lusuari prem S.
11. El sistema pregunta si es desitja sortir del cas ds o si es volen modificar dades
dels contactes o dels bancs.
Flux Alternatiu

12.2.1. El sistema pregunta quines dades es volen modificar, mostrant 3 opcions,
Dades Contacte , Dades Banc, Cancellar, si el client no t alguna de les
dades el bot est desactivat .
12.2.2. Lusuari fa la selecci dalguna de les opcions a les quals tingui accs.
12.2.3. El sistema inicia el cas ds referent a lopci escollida per lusuari.
Cas ds Baixa Provedor
Actor: Usuari.
El cas ds pot finalitzar quan lusuari ho desitgi.
Pre-Condicions
1. Tenir provedors actius a la base de dades.

2. El provedors que es desitgin donar de baixa no poden tenir factures relacionades
en els ltims 5 anys, per raons fiscals.
Post-Condicions
1. Provedor donat de baixa a la base de dades.

2. Si es dna el cas, i t contactes que no comparteix amb cap client, tamb es donen
de baixa.
3. Si es dna el cas, i t bancs que no comparteixi amb cap client tamb es donen de
baixa.
4. Si t alguna factura posterior a 5 anys tamb selimina, permanentment de la base
de dades.
Flux normal
1. Lusuari inicia el cas ds Donar de Baixa Provedor.

2. El sistema mostra un llistat dels provedors actius.
3. Lusuari selecciona el provedor que desitja eliminar i confirma la selecci.
4. El sistema comprova que no t cap factura en els ltims cinc anys.
5. El sistema mostra les totes les dades del provedor, totes les dades dels contactes i
dels bancs relacionats amb dit client.
6. Lusuari prem el bot Acceptar.
24 - Anlisi
7. El sistema pregunta si esta segur de voler donar de baixa el provedor seleccionat.

8. Lusuari prem S.
9. El sistema dna de baixa el provedor i si es dona el cas tamb dona de baixa,
contactes i bancs, sempre i quan no estiguin relacionades amb un client.
Flux alternatiu
4.2. El sistema detecta que existeixen factures en els ltims cinc anys del provedor
4.2.1. El sistema informa al usuari de la incidncia.
4.4.3. Gesti Contactes
Cas ds Alta Contacte
Actor: Usuari.
Lusuari pot passar en qualsevol moment al cas ds Modificar Contacte.
Pre-Condicions
1. Tenir algun client o provedor actiu (que no estigui donat de baixa) enregistrat.
Post-Condicions
1. Contacte enregistrat, amb telfons, mbils,faxs i/o correus electrnics.

Flux Normal
1. Lusuari inicia el cas ds Alta Contacte.

2. El sistema mostra tots el clients i provedors actius emmagatzemats.
3. Lusuari selecciona el client o provedor.
4. El sistema mostra una llista amb els contactes existents per al client o provedor
seleccionat i el formulari per introduir les dades del nou Contacte, el formulari
demana nom del contacte, telfons, mbils,faxs, e-mails .
5. Lusuari introdueix les dades del contacte, el nom, i almenys una dada de
pertanyent al client, telfon o mbil o fax o e-mail.
8. El sistema confirma lalta i demana si es volen introduir ms contactes.
9. Lusuari prem el boto No.
10. Finalitza el cas ds Alta Contacte.
Flux Alternatiu
1.1. El sistema detecta que no hi cap client ni cap provedor actiu guardat.
6.1. El sistema detecta dades incorrectes
6.1.1 Retorna al punt 4 .
9.1.1. El sistema retorna al pas 2.
Cas ds Modificar Contacte
Actor: Usuari
Pre-Condicions
1. Tenir almenys un provedor o contacte amb contactes relacionats, a la base de
dades.
26 - Anlisi

Post-Condicions
1. Emmagatzemar les noves dades del client (telfons, telfons mbils, faxs, correus
electrnics).
Flux Normal
1. Lusuari inicia el cas ds Modificar Contacte.

2. El sistema mostra el llistat de tots els provedors i clients emmagatzemats a base de
dades tant actius com donats de baixa i que disposen de dades de contactes.
3. Lusuari selecciona el provedor o client desitjat de llista i accepta.
4. El sistema mostra el formulari amb les dades del contacte que es vol modificar.
Dades que mostra: Nom del contacte, telfons, telfons mbils, faxs i e-mails i si
5. Lusuari modifica les dades que necessiti canviar, telfons, telfons mbil,faxs,
correus electrnics i si esta actiu o donat de baixa.
8. El sistema necessita confirmaci de que les dades sn correctes.
9. Lusuari prem S.
Flux Alternatiu

Cas ds Baixa Contacte
Actor:Usuari.
Pre-Condicions
1. Tenir clients o provedors amb dades de contactes, a la base de dades.

Post-Condicions
1. Eliminaci permanent dun contacte de la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Eliminar Contacte.

2. El sistema mostra el llistat de tots els provedors i clients actius emmagatzemats a
base de dades i que disposen de dades de contactes.
3. Lusuari selecciona el provedor o client desitjat de llista i accepta.
4. El sistema mostra un llistat amb contactes del client o provedor seleccionat.
5. Lusuari selecciona i accepta el contacte que vol eliminar.
6. El sistema comprova que el contacte seleccionat noms t relaci amb el client o
provedor seleccionat anteriorment.
7. El sistema necessita confirmaci de que es vol eliminar de forma permanent les
dades del contacte, nom, telfons, telfons mbils, faxs i correus electrnics.
8. Lusuari prem S.
Flux Alternatiu
7.1. El sistema comprova que te relaci amb altres provedors o clients, i pregunta si
es vol eliminar de totes maneres.
28 - Anlisi
7.1.1. Lusuari prem S .

7.1.1.1. Avana al pas 9.
7.1.2. Lusuari prem No.
7.1.2.1. Surt del cas ds.
4.4.4. Gesti Vehicles
Cas ds Alta Vehicle
Actor: Usuari.
Pre-Condicions
1. Tenir algun client actiu (que no estigui donat de baixa) enregistrat.

Post-Condicions
1. El vehicle queda enregistrat.
Flux Normal
1. Lusuari inicia el cas ds Alta Vehicle.

2. El sistema mostra tots el clients actius emmagatzemats.
3. Lusuari selecciona el client.
4. El sistema mostra les dades del client seleccionat, dels seus contactes i dels seus
vehicles existents i el formulari per introduir les dades del nou Vehicle.
5. Lusuari introdueix les dades del contacte.
8. El sistema confirma lalta i demana si es volen introduir ms vehicles del mateix

client.
9. Lusuari prem el boto No.
10. Finalitza el cas ds Alta Vehicle.
Flux Alternatiu
4.1. El sistema detecta que no hi cap client actiu guardat.

6.1. El sistema detecta dades incorrectes
6.1.1. Retorna al punt 4 .
9.1.1. El sistema retorna al pas 4, actualitzat.
Cas ds Modificar Vehicle
Actor: Usuari.
Sempre que es desitgi es pot abandonar el cas ds.
Pre-Condicions
1. Tenir clients actius amb vehicles emmagatzemats a la base de dades.

Post-Condicions
1. Tenir emmagatzemades les noves dades del vehicle seleccionat.
Flux Normal
1. Lusuari inicia el cas ds Modificar Vehicle.

30 - Anlisi
2. El sistema mostra tots el clients actius amb dades de vehicles, que estan
emmagatzemats a la base de dades.
3. Lusuari selecciona un client i accepta.
4. El sistema mostra la informaci del client, i la llista dels vehicles que t.
5. Lusuari selecciona un vehicle.
6. El sistema mostra les dades del vehicle seleccionat en un formulari. Les dades sn:
matrcula, tipus, marca, model, data dalta i quilmetres.
7. Lusuari canvia les dades antigues per les noves, tipus, marca,model i quilmetres i
la data de baixa en cas de tenir-ne i accepta.
9. El sistema pregunta si les dades sn correctes.
10. Lusuari ho confirma.
Flux Alternatiu
7.1. El sistema detecta algun error en les noves dades.

Cas ds Baixa Vehicle
Actor:Usuari.
Sempre que es desitgi es pot abandonar el cas ds.
Pre-Condicions
1. Tenir clients actius amb vehicles actius emmagatzemats a la base de dades.

2. Que els vehicles actius no tinguin cap factura en els ltims 5 anys
Post-Condicions
1. Tenir el vehicle seleccionat donat de baixa a la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Donar de Baixa Vehicle.

2. El sistema mostra tots el clients actius amb dades de vehicles actius, que estan
emmagatzemats a la base de dades.
3. Lusuari selecciona un client i accepta.
4. El sistema mostra la informaci del client, i la llista dels vehicles actius que t.
5. Lusuari selecciona un vehicle de la llista.
6. El sistema comprova que no t cap factura relacionada.
7. El sistema mostra les dades del vehicle en un formulari. Les dades sn: matrcula,
tipus, marca, model, data dalta i quilmetres.
8. Lusuari prem Acceptar.
10. El sistema pregunta si esta segur de voler donar de baixa el vehicle.
11. Lusuari ho confirma.
Flux Alternatiu
6.1. El sistema comprova que t factures amb una antiguitat menor a 5 anys.
6.1.1. El sistema surt del cas ds.
10.1. Lusuari no confirma la baixa
10.1.1. El sistema surt del cas ds.
32 - Anlisi
4.4.5. Gesti Factures Provedors
Cas ds Alta Factures Provedors
Actor:Usuari.
Lusuari decideix quan aturar el cas ds.
Pre-Condicions
1. Tenir provedors actius donats dalta a la base de dades
Post-Condicions
2. Tenir emmagatzemada una factura de provedor a la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Alta Factures Provedors.

2. El sistema mostra el formulari per introduir les factures noves. El formulari consta
dels segents camps: mes, any, nmero factura taller, identificador del provedor,
nom fiscal del provedor, data demissi de la factura, numero factura provedor,
base imposable, iva, irpf, total factura, tant per cent iva i tant per cent irpf.
3. Lusuari selecciona el mes i introdueix lany.
4. El sistema comprova que el mes i lany son iguals o anteriors a la data actual i
tamb comprova si hi ha factures del mes de any seleccionat i mostra les dades de
les factures existents en una taula.
5. Lusuari introdueix les dades necessries en els camps corresponents, selecciona el
provedor, la data demissi i comprova que els tants per cent diva i irpf
corresponen amb la seva factura i finalment introdueix la base imposable.
6. El sistema valida de les dades i fa els clculs de liva, irpf i total factura
corresponents i ho mostra en el formulari dintroducci de dades.
7. Lusuari prem el boto Afegir a la llista.
8. El sistema insereix les dades de la factura a la base de dades i afegeix les dades a la
taula del formulari.
9. El cas ds finalitza quan lusuari decideix acabar dinserir factures.
Flux Alternatiu
4.1. El sistema detecta que el mes i lany introduts sn posteriors a la data actual.
6.1. El sistema detecta que el valor base imposable s incorrecte.
Cas ds Modificar Factura Provedor
Actor:Usuari.
Pre-Condicions
1. Tenir provedors actius donats dalta a la base de dades.

2. Tenir factures de provedors del mes i any seleccionats.
Post-Condicions
1. Tenir les noves dades duna factura de provedor a la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Modificar Factures Provedors.

2. El sistema mostra el formulari per introduir les factures noves. El formulari consta
dels segents camps: mes, any, nmero factura taller, identificador del provedor,
nom fiscal del provedor, data demissi de la factura, numero factura provedor,
base imposable, iva, irpf, total factura, tant per cent iva i tant per cent irpf.
34 - Anlisi
3. Lusuari selecciona el mes i introdueix lany.

4. El sistema comprova que el mes i lany son iguals o anteriors a la data actual i
tamb comprova si hi ha factures del mes de any seleccionat i mostra les dades de
les factures existents en una taula.
5. Lusuari selecciona la factura que es vol modificar
6. El sistema omple els camps del formulari amb les dades de la factura seleccionada.
7. Lusuari modifica les dades antigues per les dades noves.
8. El sistema valida de les dades i fa els clculs de liva, irpf i total factura
corresponents i ho mostra en el formulari dintroducci de dades.
9. Lusuari prem el boto Modificar.
10. El sistema modifica les dades de la factura a la base de dades i tamb modifica les
dades a la taula del formulari.
11. El cas dus finalitza quan lusuari decideix acabar dinserir factures.
Flux Alternatiu
4.1. El sistema comprova que no t cap factura el mes i lany introduts.

6.1. El sistema detecta que el valor base imposable s incorrecte.
4.4.6. Gesti Factures Clients
Cas ds Alta Factures Clients
Actor:Usuari.
Pre-Condicions
1. Tenir clients actius donats dalta a la base de dades, amb altes dordre sense
relacionar amb cap factura.
Post-Condicions
1. Tenir emmagatzemada una factura de clients a la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Alta Factures Provedors.

2. El sistema mostra els clients actius que tenen ordres de taller pendents de facturar.
3. Lusuari selecciona un client.
4. El sistema mostra les dades del client, les ordres de taller pendents de facturar i el
formulari per introduir les factures noves. El formulari consta dels segents camps:
nmero factura, data demissi, data de venciment.
5. Lusuari introdueix les dades i accepta.
6. El sistema valida les dades, mostra la informaci la factura que es crear i necessita
confirmar les dades.
7. Lusuari confirma les dades.
8. El sistema pregunta si es volen fer ms factures.
9. Lusuari prem No
Flux Alternatiu
6.1. El sistema detecta alguna dada incorrecta.

6.2. El sistema detecta que la data de venciment s posterior a la data demissi de la
factura .
6.3. El sistema detecta que el client t un banc actiu, i detecta que la dia de venciment
no s 5 ,ni 20, 25 del mes segent a la emissi.
36 - Anlisi
Cas ds Modificar Factura Client
Actor:Usuari.
Pre-Condicions
1. Tenir clients actius donats dalta a la base de dades, amb vehicles.

2. Tenir ordres de taller del vehicle del client.
3. Tenir una factura del client a la base de dades.
4. No haver tancat el llistat dives de clients del mes demissi de la factura.
Post-Condicions
1. Tenir les noves dades duna factura de client a la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Modificar Factures Client.

2. El sistema mostra les factures existents.
3. Lusuari selecciona la factura que vol modificar.
4. El sistema mostra el formulari amb les dades de la factura seleccionada.
5. Lusuari modifica les dades i les ordres de taller seleccionades.
6. El sistema comprova les noves dades introdudes.
7. El sistema valida les dades, mostra la informaci la factura que es modificar i
necessita confirmar les dades.
8. Lusuari confirma.
9. El sistema realitza lacci i finalitza el cas ds.
Flux Alternatiu
6.1. El sistema detecta alguna dada incorrecta.

6.2. El sistema detecta que la data de venciment s posterior a la data demissi de la

factura .
6.3. El sistema detecta que el client t un banc actiu, i detecta que la dia de venciment
no s 5 ,ni 20, 25 del mes segent a la emissi.
4.4.7. Gesti de bancs
Cas ds Alta Banc
Actor: Usuari
Lusuari pot abandonar el cas ds quan ho desitgi.
Pre-condicions
1. Tenir provedors o clients actius emmagatzemats a la base de dades.
Post-Condicions
1. Tenir registrat un banc relacionat amb un client i/o un provedor actius.
Flux Normal
1. Lusuari inicia el cas ds Alta Banc

2. El sistema mostra el llistat de clients i provedors actius.
3. Lusuari selecciona un client o provedor i accepta.
4. El sistema mostra les dades del client o provedor, i si t algun banc relacionat
tamb nensenya les dades del banc en una taula. Tamb mostra el formulari
dentrada on es demana el nom, lentitat,loficina, el dgit de control i el numero de
compte.
5. Lusuari introdueix el nom del banc, lentitat, loficina, el dgit de control i el
numero de compte i accepta.
6. El sistema valida les dades i demana si les dades del banc que sacaben dintroduir
sn les noves dades per defecte del bancs del client
38 - Anlisi
7. Lusuari confirma.
8. El sistema realitza lacci i surt del cas ds.
Flux Alternatiu
6.1. El sistema detecta que les dades sn incorrectes

6.2. El sistema detecta que el banc es repeteix en un altre client.
6.2.1. Retorn al pas 4
7.1.1. El sistema continua lacci per sense posar per defecte les dades del banc.
Cas ds Modificar Banc
Actor: Usuari
Pre-Condicions
1. Tenir a la base de dades clients o provedors actius que tinguin bancs relacionats.
Post-Condicions
1. Enregistrar les noves dades del banc a la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Modificar Banc

2. El sistema mostra el llistat de clients i provedors actius amb bancs relacionats.
3. Lusuari selecciona un client o provedor de la llista.
4. El sistema mostra el bancs del clients en una taula.
5. Lusuari selecciona un banc.
6. El sistema introdueix les dades del banc seleccionat al formulari de la finestra, nom
banc, entitat, oficina, dgit de control, numero de compte i si s lactual.
7. Lusuari modifica les dades necessries i accepta.
8. El sistema valida les dades i demana si vol que el banc sigui lactual.
9. Lusuari prem S.
10. El sistema fa lacci i finalitza el cas ds.
Flux Alternatiu
8.1. El sistema detecta que les dades sn incorrectes

8.2. El sistema detecta que el banc es repeteix en un altre client.
9.1.1. El sistema continua lacci per sense posar per defecte les dades del banc.
Cas ds Eliminar Banc
Actor: Usuari.
Pre-Condicions
1. Tenir contactes clients o provedors actius amb alguna dada de banc.
Post-Condicions
1. Eliminaci permanent del banc seleccionat a la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Eliminar Banc

2. El sistema mostra el llistat de clients i provedors actius amb bancs relacionats.
40 - Anlisi
3. Lusuari selecciona un client o provedor de la llista.

4. El sistema mostra el bancs del clients en una taula.
5. Lusuari selecciona un banc.
6. El sistema demana si es vol eliminar permanentment de la base de dades
7. Lusuari prem S.
8. El sistema fa lacci i finalitza el cas ds.
Flux Alternatiu

4.4.8. Gesti Ordres de Taller
Cas ds Alta Ordre Taller
Autor: Usuari
Pre-Condicions
1. Tenir clients actius que posseeixin vehicles que no estiguin donats de baixa.
pasos, provncies, poblacions operacions).
Post-Condicions
1. Tenir a la base de dades una ordre de taller del vehicle seleccionat.
Flux Normal
1. Lusuari inicia el cas ds alta ordre taller.

2. El sistema mostra un llistat del clients actius que tenen vehicles.

4. El sistema mostra les dades del client, les dades de totes els contactes i les dades de
tots els vehicles.
5. Lusuari selecciona el vehicle desitjat.
6. El sistema mostra les dades del vehicle i el formulari per inserir les segents dades:
nom operaci, nom material, quantitat i preu unitari.
7. Lusuari introdueix les dades data inici, nom operaci, nom material, quantitat,
preu unitari, quilmetres del vehicle el dia dentrada al taller.
8. El sistema valida les dades, calcula el camp preu total i afegeix les operacions i les
ordres a les llistes corresponents.
9. Lusuari prem Finalitzar
10. El sistema demana el total dhores de durada de lordre de taller.
11. Lusuari entra les hores totals.
12. Els sistema valida les dades.
13. El sistema finalitza el cas ds.
Flux Alternatiu
8.1. El sistema detecta dades incorrectes o repetides

9.1. Lusuari no prem Finalitzar.
12.1. El sistema detecta que el valor de les hores totals es incorrecte.
Cas ds Modificar Ordre Taller
Autor: Usuari
Pre-Condicions
1. Tenir clients actius que posseeixin vehicles que no estiguin donats de baixa.
42 - Anlisi

pasos, provncies, poblacions, operacions, material).
Post-Condicions
1. Tenir a la base de dades una ordre de taller del vehicle seleccionat.
Flux Normal
1. Lusuari inicia el cas ds modificar ordre taller.

2. El sistema mostra un llistat del clients actius que tenen vehicles.
4. El sistema mostra les dades del client, les dades de totes els contactes i les dades de
tots els vehicles.
5. Lusuari selecciona el vehicle desitjat.
6. El sistema mostra les dades del vehicle i les ordres de taller pendents de facturar.
7. Lusuari escull la ordre de taller desitjada.
8. El sistema mostra la informaci de la ordre selecciona al formulari.
9. Lusuari modifica les operacions que si li ha realitzat en vehicle, i/o els materials i
accepta.
10. El sistema valida les dades i demana confirmaci.
11. Lusuari confirma que les dades sn correctes.
Flux alternatiu
10.1. El sistema detecta dades incorrectes.

10.2. Lusuari no confirma.
4.4.9. Gesti Tarifes

Cas ds Alta Tarifa Preu
Actor:Usuari.
Pre-Condicions
Post-Condicions
1. Tenir enregistrat un nova tarifa (Preu/Hora).
Flux Normal
1. Lusuari inicia el cas ds Alta Tipus Preu.

2. El sistema comprova els tipus preu que hi ha a la base de dades que hi ha i els
mostra en una taula i tamb mostra el formulari de introducci de dades noves, on
demana el nom/descripci de la nova tarifa i el preu/hora en euros.
3. Lusuari introdueix les noves dades de nom/descripci i el nou preu/hora.
Flux Alternatiu
4.1. El sistema detecta que les dades son errnies.

4.2. El sistema detecta que la tarifa ja existeix.
Cas ds Modificar Tarifa Preus
Actor:Usuari.
Pre-Condicions
44 - Anlisi
1. Ha dexistir una tarifa de preus a la base de dades.
Post-Condicions
1. La tarifa de preus seleccionada amb les noves dades.
Flux Normal
1. Lusuari inicia el cas ds Modificar Tarifa Preus

2. El sistema comprova les tarifes que hi ha a la base de dades que hi ha i els mostra
en una taula.
3. Lusuari selecciona la tarifa que desitja modificar.
4. El sistema introdueix les dades de nom/descripci i preu/hora de la tarifa
seleccionada al formulari.
5. Lusuari modifica el preu/hora al formulari i accepta.
Flux Alternatiu
6.1. El sistema detecta dades incorrecte.

Cas ds Eliminar Tarifa Preus
Actor:Usuari.
Pre-Condicions
1. Ha dexistir una tarifa de preus a la base de dades.
Post-Condicions
1. La tarifa de preus eliminada permanentment de la base de dades.
Flux Normal
1. Lusuari inicia el cas ds Eliminar Tarifa Preus

2. El sistema comprova les tarifes que hi ha a la base de dades que hi ha i els mostra
en una taula.
3. Lusuari selecciona la tarifa que desitja eliminar.
4. El sistema comprova que cap client lestigui utilitzant i procedeix a lacci.
Flux Alternatiu
6.2. El sistema detecta que hi client que utilitzen la tarifa seleccionada .

4.4.10. Gesti Pasos
Cas ds Alta Pas
Actor: Usuari.
Pre-Condicions
Post-Condicions
Tenir a la base de dades la informaci dun pas.
Flux Normal
1. LUsuari inicia el cas ds Alta pas.

2. El sistema mostra els pasos existents en una taula i el formulari dinserci de
dades, identificador Pas i nom Pas.
46 - Anlisi
3. Lusuari introdueix les dades al formulari i accepta.

Flux Alternatiu
4.1. El sistema detecta que hi ha dades incorrectes.

4.1. El sistema detecta dades repetides
Cas ds Modificar Pas
Actor: Usuari.
Pre-Condicions
1. Tenir un pas inserit a la base de dades.
Post-Condicions
1. Tenir a la base de dades la informaci dun pas.
Flux Normal
1. LUsuari inicia el cas ds Modificaci Pas.

2. El sistema mostra els pasos existents en una taula i el formulari dinserci de
dades, identificador Pas i nom Pas.
3. Lusuari selecciona el pas que vol modificar.
4. El sistema colloca les dades del pas seleccionat al formulari.
5. Lusuari modifica les dades del formulari i accepta.
Flux Alternatiu

4.4.11. Gesti Provncies
Cas ds Alta Provncia
Actor: Usuari.
Pre-Condicions
1. Tenir un pas registrat a la base de dades.
Post-Condicions
1. Tenir a la base de dades la informaci duna provncia que pertanyi al pas

seleccionat.
Flux Normal
1. LUsuari inicia el cas ds Alta Provncia.

2. El sistema mostra els pasos existents en una taula.
3. Lusuari selecciona el pas en que vols afegir una provncia.
4. El sistema mostra un llistat de les provncies existents en el pas seleccionat i un
formulari on demana el identificador de provncia i el nom de la provncia.
48 - Anlisi
Flux Alternatiu

Cas ds Modificaci Provncia
Actor: Usuari.
Pre-Condicions
1. Tenir una provncia guardada a la base de dades.
Post-Condicions
1. Tenir a la base de dades la nova informaci de la provncia seleccionada.
Flux Normal
1. LUsuari inicia el cas ds Modificar Provncia.

3. Lusuari selecciona el pas en que desitja modificar una provncia.
4. El sistema mostra un llistat de les provncies existents en el pas seleccionat i un
formulari on demana el identificador de provncia i el nom de la provncia.
5. Lusuari selecciona una provncia de la llista.
6. El sistema transfereix les dades de la provncia seleccionada al formulari.
7. Lusuari modifica les dades al formulari i accepta.
Flux Alternatiu

4.4.12. Gesti Poblacions
Cas ds Alta Poblaci
Actor: Usuari.
Pre-Condicions
1. Tenir una provncia registrada a la base de dades.
Post-Condicions
1. Tenir a la base de dades la informaci duna poblaci que pertanyi a la provncia

seleccionada.
Flux Normal
1. LUsuari inicia el cas ds Alta Poblaci.

3. Lusuari selecciona el pas en hi ha la provncia on es vol afegir la poblaci.
4. El sistema mostra un llistat de les provncies existents en el pas seleccionat.
5. Lusuari selecciona la provncia on vol afegir la nova poblaci.
50 - Anlisi
6. El sistema mostra un llista amb les poblacions existents de la provncia

seleccionada, tamb un formulari on demana el identificador de provncia,
lidentificador de poblaci i el nom de la poblaci.
Flux Alternatiu

Cas ds Modificar Poblaci
Actor: Usuari.
Pre-Condicions
1. Tenir alguna poblaci registrada a la base de dades.
Post-Condicions
1. Tenir a la base de dades la informaci modificada de la poblaci seleccionada.
Flux Normal
1. LUsuari inicia el cas ds Modificaci Poblaci.

3. Lusuari selecciona el pas en hi ha la provncia del poble que es vol modificar.
5. Lusuari selecciona la provncia del poble que vol modificar.

seleccionada.
7. Lusuari selecciona la poblaci que desitja modificar
8. El sistema colloca les dades de la poblaci seleccionada al formulari.
9. Lusuari modifica la dada nom poble.
Flux Alternatiu
4.4.13. Gesti Codis Postals
Cas ds Alta Codi Postal
Actor: Usuari.
Pre-Condicions
1. Tenir una poblaci registrada a la base de dades.
Post-Condicions
1. Tenir a la base el codi postal duna poblaci de la poblaci seleccionada.
Flux Normal
1. LUsuari inicia el cas ds Modificar Codi Postal.

52 - Anlisi
3. Lusuari selecciona el pas on hi ha la provncia, de on s el poble que se li vol

modificar el codi Postal.
5. Lusuari selecciona la provncia de on s el poble que se li vol afegir un codi Postal.
seleccionada.
7. Lusuari selecciona la poblaci on hi vol afegir un codi postal.
8. El sistema mostra els codis postals existents del poble seleccionat i un formulari on
demana el codi postal a inserir.
Flux Alternatiu

Cas ds Modificaci Codi Postal
Actor: Usuari.
Pre-Condicions
1. Tenir un codi postal registrat a la base de dades.
Post-Condicions
1. Tenir a la base el codi postal seleccionat amb les noves dades introdudes.
Flux Normal
1. LUsuari inicia el cas ds Modificaci Codi Postal.

3. Lusuari selecciona el pas on hi ha la provncia, de on s el poble que se li vol
modificar un codi Postal.
5. Lusuari selecciona la provncia de on s el poble que se li vol modificar el codi
Postal.
seleccionada.
7. Lusuari selecciona la poblaci on hi vol modificar codi postal.
8. El sistema mostra els codis postals existents del poble seleccionat
9. Lusuari selecciona el codi postal que desitja modificar.
10. El sistema transfereix les dades del codi postal seleccionat al formulari per
modificar el codi postal.
11. Lusuari modifica les dades al formulari i accepta.
Flux Alternatiu

4.4.14. Gesti Operacions
Cas ds Alta Operaci
Actor: Usuari.
54 - Anlisi
Pre-Condicions
Post-Condicions
1. Tenir emmagatzemada a la base dades una operaci.
Flux Normal
1. Lusuari inicia el cas ds Alta Operaci.

2. El sistema mostra tots els tipus operacions existents i el formulari per introduir nous
tipus operacions, on demana el nom de loperaci.
3. Lusuari introdueix el nom de la nova operaci.
Flux Alternatiu
4.1. El sistema detecta dades incorrectes o que loperaci esta repetida.

Cas ds Modificar Operaci
Actor: Usuari.
Pre-Condicions
1. Que existeixi una operaci a la base de dades.
Post-Condicions
1. Tenir emmagatzemada a la base dades loperaci.

Flux Normal
1. Lusuari inicia el cas ds Modificar Operaci.

2. El sistema mostra tots els tipus operacions existents i el formulari per introduir nous
tipus operacions, on demana el nom de loperaci.
3. Lusuari selecciona loperaci que vol modificar.
4. El sistema carrega al formulari les dades de loperaci seleccionada.
Flux Alternatiu
5.1. El sistema detecta dades incorrectes o que loperaci esta repetida.

4.4.15. Gesti Material
Cas ds Alta Material
Actor: Usuari.
Pre-Condicions
Post-Condicions
1. Tenir emmagatzemada a la base dades un material.
Flux Normal
1. Lusuari inicia el cas ds Alta Material.

2. El sistema mostra tots els tipus de materials existents i el formulari per introduir nous
tipus materials, on demana el nom del material.
3. Lusuari introdueix el nom de nou material.
56 - Anlisi

Flux Alternatiu
4.2. El sistema detecta dades incorrectes o que el material ja est a la base de dades.
Cas ds Modificar Material
Actor: Usuari.
Pre-Condicions
1. Que existeixi un material a la base de dades.
Post-Condicions
1. Tenir emmagatzemada a la base dades el material seleccionat amb les noves dades.
Flux Normal
1. Lusuari inicia el cas ds Modificar Material.

2. El sistema mostra tots els tipus de materials existents i el formulari per introduir nous
materials, on demana el nom del material.
3. Lusuari selecciona el material que vol modificar.
4. El sistema carrega al formulari les dades del material seleccionat.
Flux Alternatiu
5.2. El sistema detecta dades incorrectes o que el material est repetit.


4.5. Diagrama de Classes del Domini
Figura 3. Diagrama de Classes del Domini

A la pgina anterior es mostra el diagrama de classe del domini, s a dir tots els
objectes que engloben la lgica de laplicaci. De cada objecte, en aquest diagrama, sha
representat les relacions que mantenen els objectes entre s i els atributs o variables de
classe que fa servir. Shan obviat les operacions ja que en totes les classes son els
constructors amb tots els parmetres, i tots els mtodes get i set de cada atribut.
Figura 4. Interfcies i Factoria Registres
Les interfcies mostrades al damunt, sn les interfcies que fan de pont entre les
classes del domini i la classes de la persistncia. Hi ha prcticament una interfcie per a
cada classe del domini, aix aconseguim aplicar el patr indirecci.
Durant la realitzaci daquest diagrama es van tenir problemes de disseny ja que

era complicat el tema de la generalitzaci. El aquest cas sha optat per fer la generalitzaci
de client i provedor, perqu per a fer algunes operacions importants ens era dutilitat poder
diferenciar de forma rpida entre clients i provedors, tot i que, en daltres casos seria ms
dutilitat tenir el la generalitzaci persona i empresa.
Un altre punt fort i complicat del disseny s tot el tema dordres de taller, factures,
operacions, materials, ja que no acaben de funcionar com a la majoria de tallers, per
62 - Disseny
solucionar aquesta diferncia am daltres tallers, sha incls dues taules, TipusOperacio i
TipusMaterial.
4.6. Digrames de seqncia del sistema
4.6.1. Cas ds Alta Ordre Taller
Figura 5. Diagrama de seqncia dels sistema (altaOrdreTaller)

4.6.2. Cas ds Alta Factura Client
Figura 6. Diagrama de seqncia del sistema (altaFacturaClient)

5. Disseny
5.1. Patr arquitectnic
Per desenvolupar aquesta aplicaci sutilitza una arquitectura MVC, dividit en 4

capes, seguint la metodologia del patr capes. La lgica daquest software s
complexa s interessant salvaguardar-la i allar-la de la resta de laplicaci,
principalment de la presentaci ja que tendeix a canviar. En el grfic segent s mostra
el funcionament de lesmentada arquitectura.
Capa Presentaci Vista
Capa Aplicaci Controlador
Capa Domini
Model
Capa Persistncia
Base de dades
Figura 7. Esquema MVC 4 capes

66 - Disseny
Larquitectura en capes permet separar la implementaci en diferents

funcionalitats, cada capa sencarrega dunes funcionalitats diferents. A grans trets
sexplica que fa cada capa:
Capa Presentaci : s la que sencarrega de la interacci amb lusuari, s a dir,

s des de on lusuari es comunica amb el sistema i viceversa.
Capa Aplicaci: Sencarrega de transformar les dades de la presentaci en

objectes del domini, i les transfereix cap a la capa Domini. Tamb fa la funci
inversa, rep els objectes del domini i els prepara per a que la capa Presentaci,
en pugui utilitzar la informaci dels objectes.
Capa Domini: s la capa que cont els objectes del domini i la que es
responsabilitza de comunicar les peticions de la capa Aplicaci cap a la capa
Persistncia. Al inrevs, retorna els resultats del capa Persistncia cap a la capa
Aplicaci.
Capa Persistncia: Aquesta capa sencarrega de realitzar les ordres de consulta,

modificaci i inserci de la capa superior, en el llenguatge que usa la Base de
Dades, el cas daquest projecte, fa la conversi de java a Sql.
5.1.1. Capa Presentaci
Com sha explicat anteriorment, s la que sencarrega de la interacci amb

lusuari, rep i les ordres de lusuari i les hi retorna.
En la presentaci shi troben totes les classes que sn pantalles, s a dir, classes
del tipus JFrame, JInternaFrame, JPanel.
Tamb hi ha unes classes que utilitzen els formularis de les finestres, per tal de
reduir el nombre de comprovacions en el moment de confirmar lacci. Alguns
exemples, daquestes classes son:
La classe LimitadorCaractersMax: el que fa es limitar el nombre de carcters

que es poden introduir en un camp dun formulari.
La classe LimitadorNomesLLetres: t la mateixa funcionalitat que lanterior,

s a dir, limita el nombre mxim de carcters que hi podem escriure en camp, per a
ms a ms, restringeix que aquets carcters no poden ser nmeros.
La classe LimitadorNomesNum: Com indica el nom, noms ens hi deixa

escriure un nombre limitat de carcters compresos entre el 0 i el 9.
5.1.2. Capa Aplicaci
Aquesta capa equival al controlador del Patr MVC. Aquest patr assigna la
responsabilitat de rebre o tractar un esdeveniment del sistema cap a una subsistema
determinat. Un error molt com s sobrecarregar el controlador amb tasques que no li
corresponen.
En aquesta capa hi trobem el segents controladors:
Controlador Gesti Clients: dins daquesta classe sengloben tots els mtodes
que necessiten per fer qualsevol operaci amb els clients del taller, des de donar
dalta, modificar, llistar clients, etc...
Controlador Gesti Provedors: De la mateixa manera que el controlador

anterior cont tots els mtodes que fan referncia als provedors.
Controlador Gesti Contactes: Aquest controlador posseeix totes les funcions

que necessiten els contactes dels clients i provedors.
Controlador Gesti Bancs: Com ens els casos anteriors aquest controlador t
tots els mtodes referents a la gesti de bancs.
68 - Disseny
Controlador Gesti Administraci: Cont mtodes que no son especfics de

cap objecte, sin que son genrics de tot el software, com exemple, les altes de
poblacions, provncies i pasos, llistar les poblacions, provncies, establir el
preu/hora, etc..
Controlador Factures Provedors: s el controlador que posseeix les funcions

que engloben tot el que fa esment a les factures dels provedors, altes, baixes,
modificacions, etc...
5.1.3. Capa Domini
s la capa on hi a tots el objectes, i s lencarregada de comunicar els

esdeveniments que ha sollicitat la capa Aplicaci. En el domini he resideix tota la
lgica de laplicaci. Un objecte del domini mai accedir a la base de dades directament
sin que ho far mitjanant una interfcie. Per evitar acoblament sha fet servir el patr
Factoria.
Algunes de les classes del domini que hi ha sn:
ClientEmpresa IClient
ClientPersona IProveidor
ProveidorEmpresa IVehicle
ProveidorPersona IBanc
Vehicle IContacte
Banc TipusPreu
Contacte FactoriaRegistres
5.1.4. Capa Persistncia
La capa Persistncia equival tamb equival al Model del MVC. A la persistncia

shi troben tots els mtodes que interaccionen amb la base de dades, aquests mtodes
contenen sentencies SQL.
En aquesta capa es fan servir classes mirall, s a dir, hi ha totes les classes que hi
ha el domini per ara la seva feina s la comunicar-se amb la base de dades. Aquestes
classes mirall es defineixen amb una implementaci de la interfcies que els hi
pertoquen.
Una de les classes ms importants de la persistncia s ConnexioBD, que

sencarrega de crear la connexi amb la base de dades corresponent mitjanant el JDBC.
Cada classe de la persistncia al ser creada crida una instncia de ConnexioBD . Per
tal de que el software sigui ms eficient la connexi amb la base de dades es crea al
principi i no es tanca fins que es surt de laplicaci, ja que aquesta aplicaci no te el
problema de la concurrncia.
5.2. Patrons de Disseny
5.2.1. Singleton
s un patr molt simple que ajuda a laplicaci a no sobre carregar-se

innecessariament amb objectes instanciats varies vegades. Es fa servir quan en temps
dexecuci nomes s necessita una sola instancia dun objecte determinat. Aquest patr
sha fet servir per exemple en la creaci de les finestres de la capa presentaci, a la
classe ConnexioBD i a la classe FactoriaRegistres.
Figura 8: Patr Singleton a la classe ConnexioBD

70 - Disseny
5.2.2. Factoria
Lobjectiu daquest patr s separar la part del codi de creaci dobjectes de la

resta daplicaci. Agafa sentit quan es creen objectes a partir dinterfcies, on la lgica
s ms complexa. El patr factoria sha fet servir en la classe FactoriaRegistres.
Figura 9: Patr Factoria a FactoriaRegistres
5.2.3. Indirecci
Amb aquest patr es millora el baix acoblament entre dues classes assignant
responsabilitats de la mediaci entre ells a un tercer. Per exemple, entre la classe
Vehicle del domini i la classe VehicleBD de la persistncia existeix una interfcie
IVehicle que assigna les responsabilitats de la intervenci entre elles i igual que amb
aquestes dues classes, el patr indirecci saplica a totes els capes de domini que estan
relacionades amb la persistncia.
5.2.4. Controlador
El patr controlador s un patr que serveix com a intermediari entre una

determinada interfcie i l'algorisme que la implementa, de tal manera que s la rep les
dades de l'usuari i les envia a les diferents classes segons el mtode cridat. Aquest patr
suggereix que la lgica de negocis ha d'estar separada de la capa de presentaci, aix
serveix per a augmentar la reutilitzaci de codi i alhora tenir un control superior. Es
recomana dividir els esdeveniments del sistema en el mxim nombre de controladors
per a poder augmentar la cohesi i disminuir l'acoblament.
5.3. Base de dades

En les dues segents pgines es mostra el model conceptual i el model relacional de
la Base de Dades.
5.3.1. Model conceptual
Figura 10. Model Conceptual de la Base de Dades

5.3.2. Model relacional
Figura 11. Model Relacional de la Base de Dades

5.3.3. Regles de negoci
Taula Provedor
El valor de la columna dataAlta ha de ser igual o anterior a la data actual.
Taula Client
El valor de la columna dataAlta ha de ser igual o anterior a la data actual
Taula TipusPreu
El valor de la columna preuHora ha de major o igual a 0.
Taula Vehicle
El valor de la columna dataAlta ha de ser anterior o igual al valor de la

columna dataBaixa.
Taula OrdreTaller
El valor de la columna dataInici ha de ser anterior o igual al valor de la

columna dataFinal.
El valor de la columna Hores ha de ser igual o superior a 0.
Taula FacturaClient
El valor de la columna dataEmissi ha de ser anterior o igual al valor de la

columna dataVenciment.
78 - Disseny
Taula FacturesProveidor
El valor de la columna mes ha de ser Gener, Febrer, Mar, Abril,

Maig, Juny, Juliol, Agost, Setembre, Octubre, Novembre o
Desembre.
El valor de la columna any1 ha de ser anterior o igual al any actual.
El valor del mes de la columna dataFra ha de ser anterior o igual al valor de la
columna mes.
Taula Material
El valor de la columna preuMaterial ha de ser igual o superior a 0.
5.3.4. Seqncies
La majoria de taules utilitzen un identificador numric, per no tots els ha

dinserir lusuari sin que ho fa automticament la base de dades. El cas daquest
projecte s interessant que les seqncies comencin a 1, i incrementin de un en un.
Aquest problema el resol el mySQL amb una funci predefinida anomenada
AUTO_INCREMENT. La funci en si per defecte comena per 1 i incrementa de
forma unitria.
Relaci de taules on es fa servir la funci Auto_Increment :

Contacte
Banc
Material
TipusMaterial
Operaci
TipusOperaci
La forma de indicar que un atribut utilitza aquesta funci, s la creaci de la taula, en

lexemple que hi ha a continuaci es veu ms clar.
CREATE TABLE BANC

(
IDBANC INT NOT NULL AUTO_INCREMENT,
NOM VARCHAR(50),
ENTITAT INT NOT NULL,
OFICINA INT NOT NULL,
DC INT NOT NULL,
NCOMPTE BIGINT NOT NULL,
IDCLIENT INT NOT NULL,
ACTUAL TINYINT(1) NOT NULL,
PRIMARY KEY (IDBANC)
);
5.4. Diagrama de seqncia del cas ds AltaOrdreTaller
Primer de tot es recuperen les dades del client amb els vehicles, i contactes si en t.
Per tant el diagrama daquest pas s:
Figura 12. Diagrama de seqncia AltaVehicle 1
El segent pas s la introducci de dades dordre taller, i aix ho representa el diagrama

segent:
80
- Disseny
Figura 13. Diagrama altaOrdreTaller 2

6. Implementaci
6.1. Interfcie grfica
s important recalcar que per optimitzar el software, es treballa en memria i en

base de dades, s a dir, quan es vol recuperar informaci primer es va al magatzem de
dades, i si no es troba la informaci demanada llavors es fa la consulta a la base de
dades.
En lapartat dobjectius sha vist que una fita important s que la interfcies sigui
fcil de fer servir i per tant la interfcie s molt guiada. El que sha fet per evitar errors
prematurs per equivocaci alhora de prmer tecles i aconseguir que la interfcie sigui
usable, rpida, fluda, i alhora robusta, s el segent:
Figura 14. Finestra selecciAlta
Si es mira la imatge del JFrame, on sintrodueix el dni o nif, el bot Acceptar

est desactivat fins que no hi ha inserits 9 carcters, i apart sutilitza la classe
LimitadorCaractersMax, aquesta classe noms controla la longitud mxima del camp.
En aquest cas com que dni, t vuit nombres i una lletra es fa servir la classe
LimitadorCaractersMax, que deixar inserir qualsevol tipus de carcter.
82 - Implementaci
public class LimitadorCaractersMax extends PlainDocument {

private JTextField miJTextField;
private int nroMaxCaracteres;
public LimitadorCaractersMax(JTextField mijtext, int nroMaxCaract){
miJTextField=mijtext;
nroMaxCaracteres=nroMaxCaract;
}
public void insertString(int arg0, String arg1, AttributeSet arg2)
throws BadLocationException
{
for (int i=0;i<arg1.length();i++)
if
((miJTextField.getText().length()+arg1.length())>nroMaxCaracteres)
return;
super.insertString(arg0, arg1, arg2);
}
}
Com sha comentat en el captol de disseny i ms concretament en lapartat de la

capa Presentaci, es fan servir unes classes per controlar lentrada de dades. Amb aix
saconsegueix ms velocitat i fludesa alhora de dur a terme la introducci de dades.
Hi ha altres classes que limiten que noms es puguin introduir una certa quantitat
nombres i una altre que noms una certa quantitat de lletres. El paquet Swing de java, t
un component dentrada anomenat JFormatedText, que no deixa de ser un JTextField on
limites que hi vols que shi escrigui i en quin format.
En quan a la introducci de dates sha de fer servir un calendari aix es limita el

format de la data i la presentaci t menys feina de comprovar que all s una data. El
calendari que sutilitza s un JCalendar, extret de www.toedter.com i modificat
especficament per a aquesta aplicaci.
Figura 15. JClalendar de Toedter
Una altre detall important de la implementaci, es que cada cop lusuari desitja
fer una modificaci o una alta dalgun client, banc, vehicle, primer se li mostren totes
les dades del client per pantalla i aix pot veure abans dintroduir les dades si ja disposa
delles. Anem a veure un exemple de lalta Vehicle.
Primer es seleccionaria quin a quin client se li vos afegir un vehicle.
Figura 16. Finestra IDClient

84 - Implementaci
Un cop acceptem ens mostra la finestra de la segent pantalla.

On shi pot veure les dades del client, les dades dels contactes dels que disposa,
una taula amb els seus vehicles i finalment un formulari a on inserir les dades del nou
vehicle.
Figura 17. Finestra altaVehicle
6.2. Controladors
Per seguir el patr controlador, sha implementat un controlador, per a cada subsistema,
s a dir, hi ha el Controlador de Clients, que inclou totes les operacions relacionades
amb els clients, Controlador Gesti Factures de Provedors que t implementades totes
els mtodes necessaris per que funcioni aquest subsistema de laplicaci. Els cada cop
que s crida a un controlador es crida a una instancia ja que utilitza el patr Singleton.
6.3. Interfcies i Factoria de Registres
En lapartat de disseny sha comentat que un objecte del domini no pot accedir a
la base de dades directament sin que ho fa mitjanant una interfcie. Com que les
interfcies no tenen constructor, no es pot fer un new de la interfcie i la persistncia
queda fora de l'abast de l'aplicaci per fer un nou objecte d'una classe de la persistncia.
A continuaci es mostra com sha solucionat el problema esmentat.
public IVehicle getRegistreVehicles() {

try {
if (vehicle == null) {
Com es veu
vehicle = a(IVehicle)
la figura anterio
Class.forName("Persistencia.VehicleBD").newInstance();
}
} catch (ClassNotFoundException e) {
System.out.println("Classe no trobada: " + e.getMessage());
} catch (InstantiationException e) {
System.out.println("Instanciaci fallida: " + e.getMessage());
} catch (IllegalAccessException e) {
System.out.println("Acces ilegal: " + e.getMessage());
} catch (Exception e) {
System.out.println("Exception: " + e.getMessage());
}
return vehicle;
}
Utilitzant el Class.forName("Persistencia.VehicleBD").newInstance();, el
que saconsegueix fer un recuperar una instancia de la classe VehicleBD. El codi
mostrat s un mtode de la classe FactoriaRegistres.
6.4. Persistncia
En la implementaci de la persistncia shan creat classes mirall, s a dir, hi ha

una classe per cada taula de la base de dades. Aqu simplementen totes mtodes de per
accedir a la base de dades. Per seguretat en les insercions es comprova que tot el procs
ha funcionat correctament ja que sin no fa el commit i la execuci fa un rollback.
Per exemple, en el codi de sota es veu com es dna dalta un contacte.
En el constructor de la classe ja fa la connexi.
86 - Implementaci
public ContacteBD() throws ExcepcioDAOFallaConnexio {

try {
con = ConnexioBD.getConnexio();
} catch (Exception exec) {
throw new ExcepcioDAOFallaConnexio("Falla la connexi", exec);}}
Desprs ja es fa el mtode alta contacte:
public void altaContacteBD(int ids, Contacte contacte) throws Exception {

PreparedStatement stm = null;
boolean commited = false;
String sql;
int idContacte;
int idProv=-1;;
int idCli=-1;
String id=String.valueOf(ids);
if(id.startsWith("43")){
idCli=ids;
}
else if(id.startsWith("40")||id.startsWith("41")){
idProv=ids;
}
try {
sql = "INSERT INTO CONTACTE (NOM,IDPROVEIDOR,IDCLIENT) VALUES
(?,?,?) ";
stm = con.prepareStatement(sql);
stm.clearParameters();
Contacte c = contacte;
String nom = c.getNom();
stm.setString(1, nom);
stm.setInt(2, idProv);
stm.setInt(3, idCli);
stm.executeUpdate();
idContacte = this.getLastId();
System.out.println(idContacte);
TelefonBD tBD = new TelefonBD();
if (!c.getTels().isEmpty()) {
tBD.AltaTelefon(idContacte, c.getTels());
}
FaxBD fBD = new FaxBD();
if (!c.getMobs().isEmpty()) {
fBD.altaFaxBD(idContacte, c.getFaxs());
}
MobilBD mBD = new MobilBD();
if (!c.getMobs().isEmpty()) {
mBD.altaMobilBD(idContacte, c.getMobs());
}
EmailBD eBD = new EmailBD();
if (!c.getEmail().isEmpty()) {
eBD.altaEmailBD(idContacte, c.getEmail());
}
con.commit();
commited = true;
} catch (SQLException e) {
if (e.getMessage().startsWith("ORA-00001")) {
throw new ExcepcioDAOPKDuplicada("error", e);
} else {
throw new ExcepcioDAOFallaConnexio("Falla la connexi", e);
}
} catch (Exception ex) {
throw new ExcepcioDAO(ex.getMessage(), ex);
} finally {
try {
if (stm != null) {
stm.close();
}
if (!commited) {
con.rollback();
}
} catch (SQLException e) {
throw new ExcepcioDAOFallaConnexio("Falla la connexi", e);
}
}
}
7. Conclusions
Laplicaci que es presenta en aquest projecte final de carrera est pensada,

dissenyada i elaborada per a un client en concret. Amb aix es vol dir que altres
empreses del sector segurament no la puguin utilitzar ja que sha desenvolupat en base a
els processos concrets de Tallers Sacreu s.c.c.l.
Daltra banda es proposa una metodologia software pel desenvolupament de

petits i mitjans sistemes dinformaci. El temps ha estat el principal factor pel quan no
sha pogut seguir fil per randa metodologies tan conegudes con Unified Proces o
Mtrica v3. Ja que estan pensades per a projectes molt ms grans que laplicaci que
sha desenvolupat en aquest projecte. A causa del factor temporal tamb hi ha algun
aspectes com algunes proves que shan quedat en segon terme.
A diferencia de la majoria de projectes finals de carrera aquest t al darrera un

client real. Aix ha perms aconseguir una experincia molt ms fructfera i gratificant,
a causa de saber que el software que es dissenya realment tindr un s en la vida
quotidiana del client. Aix s lautentica satisfacci, saber que el que fas serveix
dalguna cosa o ajuda a les necessitats dalguna persona.
Eduard Campos Maymi Gesti Tallers Sacreu

Escola Universitria Politcnica de Matar s.c.c.l
Enginyeria Tcnica en Informtica de Gesti
Primavera 2009
cammayed@eupmt.upc.edu
Resum:. Tallers Sacreu S.C.C.L s una petita empresa de reparaci de vehicles que amb el
pas del temps ha vist com el sistema de gesti del seu negoci ha quedat obsolet. Actualment
funciona amb fulls de clcul i processadors de text, i existeix una manca important dordre.
Lobjectiu del projecte s millorar la gesti, oferir a aquesta empresa l'agilitzaci de tots els seus
processos i evitar la prdua de dades mitjanant l'elaboraci d'una aplicaci que permetr
controlar de forma centralitzada tots les funcions i processos del taller, referents a la facturaci.
1. Introducci La necessitat daquest software es deu a que

el sistema dinformaci del tallers sha quedat
Aquesta aplicaci est dissenyada i obsolet. El problema del seu sistema de
desenvolupada seguint les necessitats dun treball actual s la prdua dinformaci i el
client real, Tallers Sacreu S.C.C.L. poc control de gesti sobre clients, provedors
i la facturaci. Lobjectiu de laplicaci s
Tallers Sacreu, S.C.C.L s una empresa resoldre aquest problema de la gesti i
dedicada des de fa ms de 25 anys a la sobretot solucionar el problema de la prdua
reparaci general dautombils, especialment dinformaci i agilitzar els processos de
de vehicles industrials, Empresa dmbit local gesti de clients, provedors i factures.
que sha consolidat amb una cartera de clients
fixes darreu de la comarca del maresme, tant 2. Objectius
empreses com particulars. Estem parlant de
ms de 250 clients que al llarg de lany L objectiu principal daquest projecte s
passen a fer les revisions i reparacions al seus desenvolupar una aplicaci escalable, usable,
vehicles. s a dir, que sigui molt fcil de dutilitzar
amb interfcies grfiques intutives que no
Pel que fa als provedors, actualment provoquin redundncia sobre les dades que
treballen amb ms duna cinquantena de sha dintroduir, ha de ser mantenible i
provedors habituals i altres despordics, robusta am un bon control derrors.
Entre els provedors amb els que treballa shi
troben provedors de serveis, provedors Final ha de resoldre la gesti dels clients,
ordinaris, s a dir provedors de mercaderies, provedors i facturaci, i sobre tot la
matries primeres etc, i finalment amb problemtica de la prdua de dades.
Administracions Pbliques.
92 Annex I
3. Pressupost Capa Presentaci

Vista
Sha estimat que el desenvolupament del
projecte tindr una durada aproximada de 411 Capa Aplicaci Controlador
hores. El cost total de laplicaci comptant
amb el costos derivats de personal, de
hardware i de llicencies software ascendeix a
Capa Domini
la quantitat de 5.310 distributs de la
segent manera: Model
Capa Persistncia
4.939 de personal.
88 de software.
283 de hardware.
2% 5%
Base
de dades
Personal
Software
Hadrware
Larquitectura en capes permet separar la
implementaci en diferents funcionalitats,
93% cada capa sencarrega dunes funcionalitats
diferents. A grans trets sexplica que fa cada
Amb el grfic sobserva que la majoria de capa:
costos deriven de personal ja que les
aplicacions utilitzades sn lliures o versions d Capa Presentaci : s la que
prova, i el hardware utilitzat s un porttil de sencarrega de la interacci amb lusuari, s a
gamma mitja.
dir, s des de on lusuari es comunica amb el
4. Disseny sistema i viceversa.
Patr arquitectnic Capa Aplicaci: Sencarrega de

transformar les dades de la presentaci en
Per desenvolupar aquesta aplicaci objectes del domini, i les transfereix cap a la
sutilitza una arquitectura MVC, dividit en capa Domini. Tamb fa la funci inversa, rep
4 capes, seguint la metodologia del patr els objectes del domini i els prepara per a que
capes. La lgica daquest software s la capa Presentaci, en pugui utilitzar la
complexa s interessant salvaguardar-la i informaci dels objectes.
allar-la de la resta de laplicaci,
principalment de la presentaci ja que Capa Domini: s la capa que cont
tendeix a canviar. En el grfic segent s
els objectes del domini i la que es
mostra el funcionament de lesmentada
responsabilitza de comunicar les peticions de
arquitectura.
la capa Aplicaci cap a la capa Persistncia.
Al inrevs, retorna els resultats del capa
Persistncia cap a la capa Aplicaci.
saplica a totes els capes de domini que estan

Capa Persistncia: Aquesta capa relacionades amb la persistncia.
sencarrega de realitzar les ordres de consulta,
modificaci i inserci de la capa superior, en Controlador
el llenguatge que usa la Base de Dades, el cas
daquest projecte, fa la conversi de java a El patr controlador s un patr que serveix
Sql. com a intermediari entre una determinada
interfcie i l'algorisme que la implementa, de
Patrons de disseny
tal manera que s la rep les dades de l'usuari i
les envia a les diferents classes segons el
Singleton
mtode cridat. Aquest patr suggereix que la
s un patr molt simple que ajuda a lgica de negocis ha d'estar separada de la
laplicaci a no sobre carregar-se capa de presentaci, aix serveix per a
innecessariament amb objectes instanciats augmentar la reutilitzaci de codi i alhora
varies vegades. Es fa servir quan en temps tenir un control superior. Es recomana dividir
dexecuci nomes s necessita una sola els esdeveniments del sistema en el mxim
instancia dun objecte determinat. Aquest nombre de controladors per a poder
patr sha fet servir per exemple en la creaci augmentar la cohesi i disminuir
de les finestres de la capa presentaci, en la l'acoblament. Concretament en el programa
connexi a la base de dades, el patr factoria i els controladors es situen a la capa aplicaci.
en la creaci dels controladors.
Seqncies
Factoria
La majoria de taules utilitzen un
identificador numric, per no tots els ha
Lobjectiu daquest patr s separar la part
dinserir lusuari sin que ho fa
del codi de creaci dobjectes de la resta
automticament la base de dades. El cas
daplicaci. Agafa sentit quan es creen
daquest projecte s interessant que les
objectes a partir dinterfcies, on la lgica s
seqncies comencin a 1, i incrementin de un
ms complexa. El patr factoria sha fet
en un. Aquest problema el resol el mySQL
servir en la classe FactoriaRegistres.
amb una funci predefinida anomenada
AUTO_INCREMENT. La funci en si per
indirecci defecte comena per 1 i incrementa de forma
unitria. Els casos on es fa servir ls
Amb aquest patr es millora el baix daquestes seqncies s a la taula banc,
acoblament entre dues classes assignant contacte, material, operaci, tipusMaterial i
responsabilitats de la mediaci entre ells a un tipusOperacio.
tercer. Per exemple, entre la classe Vehicle
del domini i la classe VehicleBD de la
5. Implementaci
persistncia existeix una interfcie IVehicle
que assigna les responsabilitats de la
s important recalcar que per optimitzar
intervenci entre elles i igual que amb
aquestes dues classes, el patr indirecci
el software, es treballa en memria i en
base de dades, s a dir, quan es vol
94 Annex I
recuperar informaci primer es va al el que saconsegueix fer un recuperar una

magatzem de dades, i si no es troba la instancia de la classe xxx.
informaci demanada llavors es fa la En la implementaci de la persistncia shan
consulta a la base de dades. creat classes mirall, s a dir, hi ha una classe
per cada taula de la base de dades. Aqu
En lapartat dobjectius sha vist que una simplementen totes mtodes de per accedir a
la base de dades. Per seguretat en les
fita important s que la interfcies sigui
insercions es comprova que tot el procs ha
fcil de fer servir i per tant la interfcie s
funcionat correctament ja que sin no fa el
molt guiada. El que sha fet per evitar commit i la execuci fa un rollback.
errors prematurs per equivocaci alhora
de prmer tecles i aconseguir que la 6. Conclusions
interfcie sigui usable, rpida, fluda, i
alhora robusta. Laplicaci que es presenta en aquest projecte
final de carrera est pensada, dissenyada i
Per evitar errors a lusuari se li restringeix elaborada per a un client en concret. Amb
molt lentrada de dades, s a dir, el aix es vol dir que altres empreses del sector
software intenta proporcionar la mxima segurament no la puguin utilitzar ja que sha
informaci possible perqu lusuari ompli desenvolupat en base a els processos concrets
menys camps. de Tallers Sacreu s.c.c.l.
Per seguir el patr controlador, sha Daltra banda es proposa una metodologia
implementat un controlador, per a cada software pel desenvolupament de petits i
subsistema, s a dir, hi ha el Controlador de mitjans sistemes dinformaci. El temps ha
Clients, que inclou totes les operacions estat el principal factor pel quan no sha
relacionades amb els clients, Controlador pogut seguir fil per randa metodologies tan
Gesti Factures de Provedors que t conegudes con Unified Proces o Mtrica v3.
implementades totes els mtodes necessaris
per que funcioni aquest subsistema de
7. Bibliografia
laplicaci. Els cada cop que s crida a un
controlador es crida a una instancia ja que
I. Craig Larman, UML y Patrones,2a
utilitza el patr Singleton.
Edicin. Pearson, Prentice Hall.
En lapartat de disseny sha comentat que un II. Holzner, Steven, la Biblia del JAVA
objecte del domini no pot accedir a la base de 2, Anaya Multimedia
dades directament sin que ho fa mitjanant
III. http://www.netbeans.org/kb/,
una interfcie. Com que les interfcies no NetBeans Docs&Support, 2009
tenen constructor, no es pot fer un new de
la interfcie, i la persistncia queda fora de IV. http://www.javahispano.org/,
l'abast de l'aplicaci per fer un nou objecte Asociacin JavaHispano, 2009
d'una classe de la persistncia. Utilitzant el V. http://www.lawebdelprogramador.co
Class.forName("xxx").newInstance();, m/, La Web del Programador, 2009
Annex II- PSP (Procs Software Personal)
Paradigma escollit
Desprs de fer lestudi de metodologies (revisar Annex) sha arribat a la

conclusi que es far servir el Procs Software Personal, que es un treball desenvolupat
a lassignatura de Desenvolupament de Sistemes dInformaci (DSI) i que fusiona idees
de diversos models com Mtrica v3, UP de ideologia tradicional i de eXtreme
Programing, una metodologia gil.
Descripci PSP
s un model incremental i iteratiu, principalment basat en Unified Process. Me

basat en UP (Unified Process) per diverses raons. La primera i la ms important s que
permet introduir nous requeriments al llarg del cicle de vida del projecte no cal que
sigui al principi com en daltres, per exemple els paradigmes de tipus seqencial. Altres
raons sn que minimitza els riscos i obt arquitectures software ms robustes perqu sn
provades com a mnim un cop per iteraci, i que prcticament des del primer moment
tots el membres del projecte ja poden comenar a treballar.
De Mtrica versi 3 tamb hi ha un parell didees interessants, el procs de
planificaci i el procs estudi de la viabilitat del sistema, per en el procs personal
software shan unit en un de sol. Per exemple en comptes de tenir planificaci del SI i
estudi de la viabilitat del sistema com a dos processos diferents, posar-los com
Avantprojecte que noms es fa al inici del projecte, abans de la primera iteraci. Amb
el que sintenta aconseguir amb aquest avantprojecte es poder recollir o capturar els
requeriments que fan servir en la primera iteraci per poder comenar a treballar, i
poder fer els pressupostos i a calcular el temps que es dedica a cada iteraci, o a cada
cas ds.
Del model de procs software eXtreme Programming s interessant el feedback

continu amb el client, estar fent testing sempre i la integraci continua de codi.
La darrera modificaci del Unified Process s la ultima fase, la Transition, tal i com
es coneix noms sintrodueix al final, ja que de cara a cada iteraci es creu
96 Annex II
innecessria. Per exemple, en les primeres iteracions no s necessari preparar els

sistemes on shan de fer les installacions, migrar les dades dels sistemes antics, perqu
aix es pot fer al final de tot quan el projecte ja sha alliberat al client. Per per altra
banda s veig til a cada iteraci, pel fet de realitzar les ultimes proves i detecci
derrors, per examinar que els requeriments es compleixen satisfactriament i per la
preparaci de documentaci i manuals dusuari.
ETAPES O PHASES
- Inception
En la primera etapa del procs personal software, el que es fa s reunir-se amb el

client per tornar a buscar nous requeriments. En la primera iteraci aquesta fase no fa
falta que es faci perqu els requeriments inicials sn els que shan obtingut de
lavantprojecte. Per si que es pot anar fent el disseny i la implementaci dels
requeriments que ja es tenen.
- Elaboration
s una fase molt important perqu defineix larquitectura del sistema. En la fase
delaboraci es realitzen els diagrames de classes, els diagrames dactivitat, els
diagrames de seqncia, els diagrama de casos d's, el model conceptual de la base de
dades, en definitiva tots els models necessaris per saber que ha de fer i com es
comportar el sistema. En aquesta etapa torna a aparixer el feedback amb el client, per
tal densenyar-li una mena de prototip dels requeriments captats fins al moment, amb
aix sintenta obtenir-ne de nous o modificar algun requeriment mal captat. Tamb s
defineixen i es planifiquen les proves i la fase segent, la Construction.
- Construction
Lobjectiu daquesta fase s obtenir una versi beta del sistema amb totes les
seves prestacions, llesta per poder-la provar. Per tant, es centra en la implementaci de
tots el requeriments que hi ha a la fase delaboraci. Integra el sistema i el prova tot

alhora de forma exhaustiva, vigilant els detalls.
- Transition
Aquesta transici no s com la del model de procs software Unified Process,

per aix, s una Transition especial del procs software personal. En aquesta fase
prepara la documentaci del fet fins aleshores, corregir errors detectats en les proves
realitzades en les fases anteriors, realitzar les darreres proves, examinar que els
requeriments sacompleixin satisfactriament i planificar la segent iteraci.
WORKFLOWS
Aquests sn els workflows que sinclouen en el procs personal software, la

majoria es fan servir a cada iteraci, per daltres noms es fan un sol cop, o al principi
o al final.
Aix doncs comencem pel principi, lAvantprojecte.
Avantprojecte
Aquest Workflow s el que es fa al inici del projecte i no es repeteix a cap iteraci

ms.
- Estudi de la viabilitat.
s el primer que es fa quan sinicia un projecte, estudiar si es possible o no

portar a terme un projecte amb aquelles caracterstiques. Un cop ja es sap que el
projecte es pot dur a terme, s viable, es descriu la situaci actual, es determina
labast del sistema, ves valora el impacte a lorganitzaci , la inversi necessria
i aix podem afinar ms el preu alhora de fer el pressupost.
98 Annex II
- Captura dels primers requeriments.
Arribat aquest punt hi ha un primer contacte amb els requeriments, funcionals i

no funcionals. El client a de dir el que vol que faci el software. Un cop sha
parlat amb el client es pot escriure un informe diferenciant els requeriments
funcionals dels no funcionals.
- Clcul de temps de durada del projecte i el pressupost.
Per calcular el temps i el pressupost orientatius, es far servir una mtrica de

software estudiada a la assignatura de Gesti de Projectes Informtics. Aquesta
mtrica saplica calculant els Punts de Funci a partir del requeriments inicials,
tamb es pot utilitzar CoCoMo un cop calculats els Punts de Funci, que donen
la durada i lesfor en les diferents fases del projecte, a partir daqu ja es pot
calcular un pressupost orientatiu del projecte.
Principals artefactes
- Documentaci de lestudi de viabilitat amb la soluci ms adequada i

linforme de la situaci actual i del qu es vol millorar.
- Pressupostos
Requeriments
Aquest Workflow es repeteix tants cops com iteracions hi hagi en el projecte,

excepte en la primera iteraci perqu els requeriments ja els shan recollit en
lAvantprojecte.
- Reuni amb el client o feedback.
Hi ha una reuni amb el client i se li mostra una versi beta amb els
requeriments que es tenen fins aleshores, i que ho provi. Daquesta manera pot dir si s
el que realment espera o no, del programari que sest desenvolupant.
- Captura de ms requeriments.
A partir de la reuni amb client es poden treure conclusions, com si es va

ben encaminat amb els requeriments o shan de canviar o afegir daltres. Per aquest
motiu el feedback amb el client cobra especial importncia.
- Informe de nous requeriments i/o de requeriments modificats.
Anlisi & Disseny
Aquest Workflow tamb es repeteix tants cops com iteracions tingui el projecte. En
lapartat de anlisi i disseny hi afegit el model de casos ds i el model de domini, que
en Unified Process es troba en el Workflow anterior, Requeriments.
Per dur a terme els diferents diagrames i models susaran deines RAD, com el
Borland Together o el NetBeans que lutilitzarem per fer el model de domini o diagrama
de classes, el model de casos ds i els diagrames de seqncia tot aix escrit en UML.
Per fer els models de bases de dades es fa servir el PowerDesigner, de Sybase.
- Anlisi i Disseny del casos ds
En aquest sub-apartat danlisi i disseny sescriuen els casos ds corresponents

als requeriments funcionals que es tenen fins aleshores.
- Anlisi i Disseny de les classes
En aquest altre sub-apartat sha de fer el diagrama de classes o el model de

domini, cada classe ha de tenir els seus atributs i les seves corresponents relacions amb
les altres classes.
- Base de dades
Aqu es fa el model conceptual de la base de dades, amb el PowerDesigner, que

automticament genera el model fsic de la base de dades i lScript de creaci de la base
100 Annex II
de dades, que posteriorment es fa servir. Tamb shan de deixar escrites les regles de
negoci per a la fase de implementaci poder-les codificar.
- Interfcie grfica dusuari
Sha de dissenyar la interfcie grfica dusuari (GUI), s a dir, les pantalles amb
que lusuari interactuar amb el sistema.
- Test Case
Shan de dissenyar els tests case de cada cas ds, indicant que sest provant,
les diferents entrades de dades i la resposta esperada del sistema per a cada dada
introduda.
Principals Artefactes
- Informe del casos dus.
- Model de casos ds.
- Diagrama de classes o model de domini.
- Diagrama de seqncia.
- Model conceptual de la base de dades.
- Model fsic de la base de dades.
- Script de creaci de la base de dades.
- Les diferents interfcies grfiques dusuari.
- Els Tests Case.
Implementation
Aquest Workflow es fa tants cops com iteracions tingui projecte. Principalment

es porta a terme la implementaci o codificaci dels requeriments, utilitzant altre cop el
Borland Together o altres eines, tota aquesta codificaci sescriur amb el llenguatge
Java, de Sun. Tamb sha de crear la Base de Dades, amb leditor Toad o mySQL o
altres eines i sempre utilitzant SQL, dOracle.
- Implementar
En aquest apartat es codifica tant els requeriments com tot el que fa referncia a
la base de dades. En la codificaci de requeriments sutilitza una programaci orientada
a objectes, simplementen les classes de cada package i els mtodes de cada classe.
Referent a les Bases de Dades sutilitza lScript de creaci obtingut del PowerDesigner,
i sin sha utilitzat el PowerDesiger, doncs sha descriure lScript de creaci.
Indiferentment de si sha utilitzat leina de Sybase o no, tamb sha de codificar lScript
de les regles de negoci en leditor de Bases de Dades.
- Revisar el codi implementat
Aquesta idea de Extrem Programing, revisa el codi, sense usar el compilador,

per tal de buscar errors. En el cas de que existeixi algun error de codificaci es tornaa
lapartat anterior i es resol lerror.
- Compilar el codi
Compilaci del codi per buscar error en temps dexecuci, si es troba algun error
es retorna a la implementaci.
- Codi font.
- Script de regles de negoci.
- Script de creaci de la base de dades (En cas de que no shagi obtingut
abans.)
Test
Aquest Workflow es porta a terme tants cops con iteracions t el projecte. Es

torna a utilitzar el Borland Together o alguna altre eina per crear un programa
executable de prova.
102 Annex II
- Testing
Un cop est creat el programa de prova, recuperem els documents Test case, i
es fan totes les proves pertinents. Si alguna prova falla es torna al Workflow anterior, i
ms concretament, a la implementaci per corregir els errors detectats en el testeig del
software.
Principals Artefactes
- Codi font i/o Scripts de les bases de dades corregits.

- Informe derrors.
Transici
Possiblement no es el millor nom per aquest Workflow, ja que en el procs

software personal tamb he considerat com una fase.
Aquest Workflow noms es porta a terme en lultima iteraci.
- Versi definitiva
Aqu sha dobtenir una versi executable del software i preparar-la per poder
installar-la al maquinari del client.
- Installar el programa al maquinari del client.
Sha de preparar el maquinari perqu pugui suportar el software que

posteriorment li ser installat.
- Migraci de dades
Es fa si i noms s, el client ja tenia un sistema dinformaci anterior
- Versi executable
Manteniment del software
Aquest Workflow noms es fa un cop shagi lliurat el software al client.

Se li deixen un dies de prova, per si es detecta algun error. En aquest cas, en que
el client detecti alguna errada t un perode de dies preestablert per informar i el
manteniment ser de franc, s un perode de garantia.
Un cop passat aquest perode de garantia el manteniment ja es cobra.
Cal matisar que sentn per manteniment totes aquelles modificacions que no
afectin a larquitectura del software.
- Actualitzacions de la versi definitiva, per tal de solucionar els canvis

necessaris.
104 Annex II
Mtrica Versi 3 Procs Software Personal
Planificaci del SI AvantProjecte
Estudi de la viabilitat del sistema Requeriments
Anlisi del SI Anlisi & Disseny
Disseny del SI
Implementaci
Construcci del SI
Implantaci i acceptaci del Sistema Test
Transici
Manteniment del SI
Manteniment del SI
Taula 6. Cuadre-Resum dequivalncies entre Mtrica v3 i el PSP
Unified Process Procs Personal Software
Bussines Modeling AvantProjecte
Requirements Requeriments
Analysis Anlisis & Disseny
Design
Implementaci
Implementation
Test Test
Transici
Deployment
Manteniment del SI
Taula 7. Cuadre-Resum dequivalncies entre UP i el PSP

Annex III Contingut del CD
Aplicaci
o Codi font de laplicaci ( Netbeans IDE 6.5.1).
Documentaci
o Memria del Projecte (Microsoft Office i Adobe Reader).

o Portada de la memria.
o Diagrames UML i models de bases de dades.
o Article del projecte (Adobe Reader).
Fitxers dinstallaci
o Fitxer dinstallaci del Netbeans IDE 6.5.1.

o Fitxer dinstallaci de Sybase PowerDesigner 15.
o Fitxer installacio mySQL.
o Fitxer installaci SQLyog.
106 Annex II
Bibliografia
I. Craig Larman, UML y Patrones,2a Edicin. Pearson, Prentice Hall.

II. Holzner, Steven, la Biblia del JAVA 2, Anaya Multimedia
III. http://www.netbeans.org/kb/, NetBeans Docs&Support, 2009
IV. http://www.javahispano.org/, Asociacin JavaHispano, 2009
V. http://www.lawebdelprogramador.com/, La Web del Programador, 2009
VI. http://www.toedter.com/en/jcalendar/index.html, Kai toedter, 2008

Memòria TFC PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Memòria TFC PDF

Uploaded by

Copyright:

Available Formats

Dedicatria

A tots els que em van preguntar,

ndex general .................................................................................................................... VIII

ndex figures .......................................................................................................................... 1

ndex taules ............................................................................................................................ 1

1.1. Descripci del client ............................................................................................. 1

1.2. Funcionament del taller ......................................................................................... 2

2.1. Objectiu general .................................................................................................... 3

2.2. Objectius especfics .............................................................................................. 3

3.1. Planificaci ........................................................................................................... 5

3.2. Cost ....................................................................................................................... 6

3.2.1. Personal ..................................................................................................... 6

3.2.2. Software .................................................................................................... 6

3.2.3. Hardware ................................................................................................... 7

3.2.4. Total .......................................................................................................... 7

4.1. Restriccions funcionals ......................................................................................... 9

4.1.1. Clients ....................................................................................................... 9

4.1.2. Contactes ................................................................................................... 9

4.1.5. Provedors ................................................................................................. 9

4.1.6. Factures Clients ....................................................................................... 10

4.1.7. Factures Provedors ................................................................................. 10

4.1.8. Altres ....................................................................................................... 10

4.2. Requeriments no funcionals ............................................................................... 10

4.3. Diagrama de casos ds ...................................................................................... 12

4.4. Especificaci de casos ds ................................................................................ 14

4.4.1. Gesti Clients .......................................................................................... 14

4.4.2. Gesti Provedors .................................................................................... 19

4.4.3. Gesti Contactes ..................................................................................... 24

4.4.4. Gesti Vehicles ....................................................................................... 28

4.4.5. Gesti Factures Provedors ..................................................................... 32

4.4.6. Gesti Factures Clients ........................................................................... 34

4.4.7. Gesti de bancs ....................................................................................... 37

4.4.8. Gesti Ordres de Taller ........................................................................... 40

4.4.9. Gesti Tarifes .......................................................................................... 42

4.4.10. Gesti Pasos ........................................................................................... 45

4.4.11. Gesti Provncies .................................................................................... 47

4.4.12. Gesti Poblacions.................................................................................... 49

4.4.13. Gesti Codis Postals ............................................................................... 51

4.4.14. Gesti Operacions ................................................................................... 53

4.4.15. Gesti Material........................................................................................ 55

4.5. Diagrama de Classes del Domini ........................................................................ 59

4.6. Digrames de seqncia del sistema .................................................................... 62

4.6.1. Cas ds Alta Ordre Taller .................................................................. 62

5.1. Patr arquitectnic .............................................................................................. 65

5.1.1. Capa Presentaci ..................................................................................... 66

5.1.2. Capa Aplicaci ........................................................................................ 67

5.1.3. Capa Domini ........................................................................................... 68

5.2. Patrons de Disseny .............................................................................................. 69

5.2.1. Singleton ................................................................................................. 69

5.2.2. Factoria .................................................................................................... 70

5.2.4. Controlador ............................................................................................. 71

5.3. Base de dades ...................................................................................................... 71

5.3.1. Model conceptual .................................................................................... 73

5.3.2. Model relacional...................................................................................... 75

5.3.3. Regles de negoci ..................................................................................... 77

5.3.4. Seqncies ............................................................................................... 78

5.4. Diagrama de seqncia del cas ds AltaOrdreTaller ..................................... 79

6.1. Interfcie grfica .................................................................................................. 81

6.2. Controladors ........................................................................................................ 84

6.3. Interfcies i Factoria de Registres........................................................................ 85

6.4. Persistncia ......................................................................................................... 85

Annex II- PSP (Procs Software Personal) ..................................................................... 95

Annex III Contingut del CD ........................................................................................ 105