Temari M-1

Java Back End Web
Developer
21/FPOAN/570/0171492/001
DOCENT: CARLOS HEREDIA

MÒDUL 1: SISTEMES I ARQUITECTURA WEB AMB TECNOLOGIA JAVA
1. Interpretació de les parts principals que componen un projecte web: arquitectura web i
bases de dades
Arquitectures web: el concepte d’arquitectura client-servidor
El model de desenvolupament web es recolza, en una primera aproximació des d'un punt de
vista centrat en el maquinari, en el que es coneix com a arquitectura client-servidor, que defineix
un patró d'arquitectura on hi ha dos actors, client i servidor, de manera que el primer és qui es
connecta amb el segon per sol·licitar algun servei. En el cas que ens ocupa, el desenvolupament
web, els clients sol·liciten que se'ls serveixi un web per visualitzar-lo, encara que també és
possible sol·licitar informació si parlem del cas dels serveis web que també veurem més
endavant. En qualsevol cas, en ambdós casos apareix el mateix escenari, on un servidor es troba
executant-se ininterrompudament en espera que els diferents clients facin una sol·licitud.
Normalment a la sol·licitud que fan els clients al servidor s'anomena petició (request) i al que el
servidor torna a aquest client en diem resposta (request).
També cal tenir en compte que aquesta arquitectura client-servidor planteja la possibilitat de
nombrosos clients atesos per un mateix servidor. És a dir, el servidor serà un programari
multitasca que serà capaç d'atendre peticions simultànies de nombrosos clients.
Tel. 977222231-601989689
formació@multimediatarragona.com 1
www.multimediatarragona.com
Figura 1: Arquitectura client-servidor
Des d'un punt de vista de desenvolupament, una aproximació més detallada per a aquest model
d'execució és el que es coneix com a model en 3 capes. És un model on es mostra més
detalladament com es distribueix el programari que participa en qualsevol desenvolupament
web. Segueix estant present l'arquitectura client-servidor (tot s'hi basa) però apareixen més
detalls com el programari utilitzat en cadascun dels dos actors i com interactuen les diferents
tecnologies o aplicacions.
Protocols
La pila de protocols en què es basa Internet és molt àmplia, ja sigui seguint el model OSI o el
model TCP. En qualsevol cas, en el tema que ens ocupa a nosaltres només ens fixarem a la
darrera capa, la capa de transport. És en aquesta capa on hi ha els protocols de la web, els que
usen navegadors i servidors (web i aplicacions) per comunicar-se. Al cap i a la fi, la web no és
més que una de les tantes aplicacions que hi ha a Internet. Altres aplicacions, que també veurem,
entre d'altres.
Tel. 977222231-601989689
Figura 2: Model OSI
A continuació es detallen els protocols més habituals pel que fa a desenvolupament web:
▪ HTTP : HyperText Transfer Protocol. Protocol de comunicació per a la web

▪ HTTPS : HTTP Secure. Protocol assegurança de comunicació per a la web. Sorgeix
aplicar una capa de seguretat, utilitzant SSL/TLS, al protocol HTTP
▪ Telnet : És un protocol que estableix una línia de comunicació basada en text entre
un client i un servidor. Des de la seva aparició es va utilitzar àmpliament com a via
de comunicació remota amb el sistema operatiu ja que permetia lexecució remota
de comandaments. Amb el temps, ha anat caient en desús a favor d'un protocol
segur que el substitueix, SSH.
Tel. 977222231-601989689
▪ SSH : Secure Shell. Protocol assegurança de comunicació àmpliament utilitzat per a
la gestió remota de sistemes, ja que permet l'execució remota d'ordres. Sorgeix com
a reemplaçament per al protocol no segur Telnet.
▪ SCP : Secure Copy. És un protocol segur (basat en RCP, Remote Copy) que permet
transferir fitxers entre un equip local i un altre de remot o entre dos equips remots.
Utilitza SSH pel que garanteix la seguretat de la transferència així com de
l'autenticació dels usuaris.
▪ FTP : File Transfer Protocol. És un protocol que s'utilitza per transferir fitxers entre
un ordinador local i un altre de remot. El seu principal problema és que tant
l'autenticació com la transferència es fa com a text pla, per la qual cosa es considera
un protocol no segur.
▪ SFTP . SSH FTP. És una versió del protocol FTP que utilitza SSH per xifrar tant
l'autenticació de l'usuari com la transferència dels fitxers. És l'opció segura a l'ús
d'un protocol com a FTP
Figura 3: Protocols a Internet
Tel. 977222231-601989689
Protocol HTTP
El protocol HTTP és un protocol per a la transferència de pàgines web (hipertext) entre els clients
(navegadors web) i un servidor web. Quan un usuari, a través del navegador, vol un document
(pàgina web), aquest ho sol·licita mitjançant una petició HTTP al servidor. Aquest us contestarà
amb una resposta HTTP i el document, si en disposa.
Cal tenir en compte que, al contrari que la resta de protocols que estem veient en aquesta part,
HTTP no té estat. Això significa que un servidor web no emmagatzema cap informació sobre els
clients que s'hi connecten. Així, cada petició/resposta suposa una connexió única i aïllada. En
qualsevol cas, utilitzant tecnologies al costat servidor és possible escriure aplicacions web que
puguin establir sessions o galetes per emmagatzemar aquest estat i “recordar” d'alguna manera
als clients en successives connexions
Figura a: Protocol HTTP
A continuació, com a exemple, podem veure una petició HTTP que un navegador ( Firefox ) ha
realitzat a un lloc web ( misitio.com ), sol·licitant el document index.html .
GET / index.html HTTP / 1.1
Host: www.misitio.com
User-Agent: client
Referer: www.google.com
User-Agent: Mozilla / 5.0 ( X11; Linux x86_64; rv: 45.0 ) Gecko / 20100101 Firefox / 45.0
Tel. 977222231-601989689
Connection: keep-alive
[ Línia en blanc ]
I el servidor web li contesta amb el contingut del document perquè el navegador que ho ha
sol·licitat el pugui renderitzar perquè l'usuari el visualitzi a la pantalla:
HTTP / 1.1 200 OK
Dóna't: Fri, 31 Dec 2003 23 : 59 : 59 GMT
Content-Type: text / html
Content-Length: 1221
< html lang = "es" >
< head >
< meta charset = "utf-8" >
< title > El meu títol </ title >
</ head >
< body >
< h1 > Benvingut al meu lloc.com </ h1 >
...
...
</ body >
Tel. 977222231-601989689
</ html >
Protocol SSL/TLS
SSL (Secure Sockets Layer) i TSL (Transport Layer Security) són protocols de xifratge que
s'utilitzen per xifrar les comunicacions a Internet. De vegades es fa referència en tots dos casos
a l'ús de SSL, però la realitat és que TLS és el successor de SSL a causa de les diferents
vulnerabilitats que han anat sorgint d'aquest darrer.
En aquest cas, l'aplicació d'aquesta capa de seguretat, xifrant les comunicacions del protocol
HTTP, dóna lloc a allò que es coneix com a HTTPS, que veurem a continuació.
Figura 5: Protocol SSL/TLS
Figuae 6: SSL/TLS al model TCP

Tel. 977222231-601989689
Protocol HTTPS
El protocol HTTPS (HTTP Secure) és un protocol de comunicació segura mitjançant Internet.

Aquest protocol es basa en la comunicació del protocol HTTP però amb una capa de seguretat
addicional xifrant el contingut amb TSL o SSL.
La seva utilitat principal és el xifratge dels mecanismes d'autenticació a la web, justament quan
l'usuari envia les seves credencials al servidor per validar la sessió. És el moment més crític en
una comunicació, encara que actualment s'està utilitzant obertament durant tota la
comunicació entre client i servidor a la web per privadesa i integritat.
Pel que fa a la integritat, HTTPS proporciona un mecanisme d'autenticació pel que fa al lloc web
i servidor web que estem visitant, evitant així atacs com el del Man in the Middle . És la manera
com podem estar segurs que el lloc amb què estem comunicant-nos és el que creiem que és.
Figura 7: Protocol HTTPS
Tel. 977222231-601989689
Protocol Telnet
El protocol Telnet ( Tel etype net work) va sorgir com una manera de proporcionar una
comunicació interactiva basada en text entre dues màquines. Telnet proporciona accés remot a
una altra màquina i permet executar ordres i visualitzar els resultats en pantalla. Per això, a la
màquina remota s'havia d'executar el costat servidor i, al costat client, l'usuari havia d'utilitzar
una aplicació client per establir la connexió i més endavant les ordres com si es tractés de la línia
d'ordres del sistema operatiu.
Amb el temps, i a causa de la manca de seguretat a les comunicacions i l'autenticació dels

usuaris, es va abandonar l'ús d'aquest protocol en benefici d'altres com SSH.
Protocol SSH
El protocol SSH ( Secure SH ell ), igual que Telnet, proporciona una forma de comunicació entre
dues màquines remotes, basada en text però en aquest cas tant l'autenticació com la
comunicació es troben xifrades. El seu ús més habitual és la gestió remota de màquines
Unix/Linux, tal com passés al seu moment amb Telnet.
A més, altres protocols com FTP (per això anomenat SFTP) o SCP es recolzen en aquest protocol
de xifratge per xifrar les seves comunicacions.
Protocol SCP
El protocol SCP ( Secure C o P i ), basat en el protocol SSH, permet copiar fitxers entre dos equips,
tant de l'equip local al remot com en sentit contrari.
Protocol FTP
El protocol FTP ( F ile T ransfer P rotocol) és un protocol per a la transferència de fitxers entre
dues màquines: una màquina client i una altra màquina remota o servidor on s'allotgen aquests
fitxers. La idea és que la màquina remota serveixi com a repositori d'informació i siguin els
múltiples clients els que s'hi connecten per agafar o pujar fitxers.
Tel. 977222231-601989689
Figura 8: Protocol FTP (actiu i passiu)
Protocol SFTP
El protocol SFTP (SSH FTP) és la versió segura del protocol FTP. Aquesta vegada, a diferència del
que passa amb el protocol FTP, les comunicacions es xifren de la mateixa manera que en el
protocol SSH.
Tel. 977222231-601989689
Figura 9: Protocol SFTP
Servidors web i aplicacions
La realitat és que hi ha una infinitat de servidors web i d'aplicacions. Encara que a l'hora de la
veritat, uns quants (4 o 5) es reparteixen més del 90% dels llocs web a Internet. Els altres,
solucions potser molt específiques, no és que no siguin bones aplicacions sinó que es fan servir
en àmbits molt concrets. Els més utilitzats tenen un perfil més generalista i la gran majoria de
desenvolupadors i administradors s'hi decanten perquè compleixen els requisits que es
necessiten.
Bases de dades
Fonaments de Bases de Dades
Sistema d'informació
Un Sistema d'Informació és un conjunt d'elements destinats al tractament i administració de

dades i informació, organitzats i preparats per al seu ús posterior, generats per cobrir una
necessitat (objectiu).
Aquesta definició de Sistema d'Informació inclou qualsevol tipus de sistema, tinguin o no

components informàtics. Nosaltres ens fixarem en els de caràcter informàtic, més concretament
els que coneixem com a Sistemes Gestors de Bases de Dades (a partir d'ara SGBD ), que definirem
més endavant.
Cal tenir en compte que, dins del camp de la informàtica, hi ha molts tipus de sistemes
d'informació que no són SGBD . Per exemple, qualsevol aplicació informàtica que permet el
tractament de quantitats considerables d’informació per a qualsevol comesa pot ser considerat
un Sistema dI’nformació. De totes maneres, és molt probable que qualsevol d'aquestes
Tel. 977222231-601989689
aplicacions (o Sistemes d'Informació ) utilitzin un SGBD com a suport lògic d'emmagatzematge
de tota aquesta informació.
Cal sempre fer servir un SGBD?
Al nostre camp, un fitxer es podria considerar com la unitat mínima d’emmagatzematge de

qualsevol tipus dinformació. No és més que un conjunt de registres emmagatzemats amb una
estructura homogènia, que permet ser accedit per al tractament des d'alguna aplicació
informàtica. Hi ha molts tipus de fitxers atenent al format en què s'escriuen: text pla, imatge,
PDF, . . . i per treballar amb cadascun d'aquests formats hi ha una o diverses aplicacions. I en
general, un tipus d'aplicació només obrirà un tipus de fitxer, el tipus de fitxer per al qual ha estat
dissenyada: El Bloc de Notes obre fitxers de text pla, Adobe Reader obre fitxers PDF, Picasa obre
fitxers d'imatge, . . . Encara que també ens podem trobar amb aplicacions que són capaces de
treballar amb diferents formats, similars entre si (Microsoft Word, per exemple).
Una base de dades és un conjunt de fitxers interrelacionats entre si, creats per un SGBD, que
han de ser gestionats i accedits a través d'aquesta eina. En general, es tractarà d'una gran
quantitat d'informació repartida entre diversos fitxers, que és accedida des d'una eina específica
de manera que l'usuari s'abstrau de com està organitzada aquesta informació. No ens interessa
conèixer quins fitxers formen la Base de Dades, on són ni quant ocupen; l'eina que fem servir
s'ocupa de tota aquesta feina. Nosaltres, com a usuaris d'una Base de Dades, tindrem a la nostra
disposició totes les dades i nombroses eines que ens permetin treballar-hi d'una manera
còmoda (utilitats per buscar, per ordenar, per eliminar, . . .)
Tel. 977222231-601989689
Cal tenir en compte que, encara que les Bases de Dades siguin la solució als problemes
d’emmagatzematge i consulta de grans quantitats dinformació, no sempre seran la solució que
necessitem. Si imaginem una petita aplicació que només necessita emmagatzemar unes poques
files de dades, no serà molt recomanable dependre d'una segona aplicació (normalment costosa
en mida i rendiment i, probablement, també en diners) per gestionar aquestes poques dades.
Encara que hi ha solucions petites per a aquest tipus d'aplicacions, normalment afegiran una
càrrega extra de treball més gran que el benefici que produeix utilitzar quan l'ocasió ho
requereix. Si bé és cert que hi ha petits SGBD que poden ser una opció molt interessant en aquest
tipus de casos, com passa amb SQLite, que té suport en dispositius mòbils a través d' Android .
Un altre avantatge que presenta l'ús de Bases de Dades davant de l'ús de fitxers és l'estalvi que
això suposa. Cal pensar que en cas que no comptem amb un SGBD per al desenvolupament
d'una aplicació determinada, haurem de desenvolupar a mida tota la part que es refereixi a
l'emmagatzematge i la gestió de totes les dades d'aquesta aplicació. En un SGBD tota aquesta
part ja està implementada, té una interfície d'accés comú i adaptable a pràcticament qualsevol
entorn. A més, hi ha llenguatges àmpliament coneguts per a l'accés i la gestió de les dades
emmagatzemades ( SQL en el cas dels SGBD relacionals, per exemple).
D'altra banda cal tenir en compte, segons veurem més endavant, que actualment hi ha molts
tipus de SGBD, des del que es coneix com el clàssic SGBD relacional fins a petits SGBD que amb
prou feines ocupen 1MB d'espai i no requereixen instal·lació, altres emmagatzemen la
informació com a fitxers XML, . . . per tant, la distància que separa l'accés directe a fitxers i els
SGBD cada vegada és menor i pràcticament tot es pot considerar una Base de Dades, que
juntament amb la seva aplicació corresponent formen nombrosos i diferents Sistemes
d'Informació.
Sistema gestor de bases de dades
Un SGBD és una eina programari, més o menys complexa, que permet la creació i la gestió d'una
base de dades. Al punt anterior hem vist que una Base de Dades estava composta de diversos
fitxers relacionats entre si. L'SGBD és l'eina que s'encarrega d'organitzar aquests fitxers
mantenint la informació sempre accessible per a l'usuari de la manera més eficient possible, tant
a l'espai com a la velocitat d'accés.
Quan gestionem una base de dades a través d'un SGBD, estem afegint un nivell d'abstracció ja
que “no ens assabentem” exactament del que passa amb les dades, com s'emmagatzemen, on
Tel. 977222231-601989689
s'emmagatzemen, quant ocupen... En realitat, és aquesta eina la que s'encarrega que la Base de
Dades sigui consistent, estigui sempre accessible, disposi d'espai en disc, i de moltes altres
tasques que, depenent de l'SGBD concret, poden ser més o menys complexes.
Cal tenir en compte que actualment hi ha diferents tipus de SGBD quant al nivell de
coneixements tècnics que es requereixen per treballar-hi. Per citar un exemple, un SGBD com
MySQL mai no podrà ser utilitzat per usuaris amb escassos coneixements tècnics ja que no està
pensat com a aplicació per a l'usuari final, sinó com a SGBD de suport per a altres aplicacions,
aplicacions web o llocs web que requereixin manejar grans quantitats de dades (Sistemes
dInformació). D'altra banda, Microsoft Access o LibreOffice Base són SGBD pensats per a un
usuari menys tècnic. No calen tants coneixements tècnics per al seu maneig, i per tant s'acosten
més a l'usuari. De fet s'inclouen a les suites ofimàtiques més conegudes. Per tant, és lògic pensar
que aleshores no estaran pensats per servir de suport a altres aplicacions, sinó per funcionar de
manera independent com a aplicació final d'usuari.
Característiques desitjables
En general, de qualsevol sistema d'informació, s'esperen una sèrie de característiques, que

s'exposen a continuació:
▪ CRUD : L'acrònim CRUD fa referència a les 4 operacions bàsiques que qualsevol

SGBD hauria de proporcionar: Create (crear), Update (modificar), Read (llegir),
Tel. 977222231-601989689
Delete (eliminar). A més, cal tenir-les molt en compte a l'hora de dissenyar
correctament la nostra Base de Dades, ja que l'aplicació que la gestioni haurà de
facilitar aquestes operacions correctament.
▪ Recuperació de la informació : En certa manera fa referència a la R de CRUD però
també és important la manera com aquesta informació es pot llegir, de manera que
s'espera que qualsevol fragment d'informació pugui ser recuperat, ia més de
diferents formes. Per exemple, hauríem de ser capaços de buscar un client
determinat a les nostres bases de dades fent referència a més d'un criteri (DNI,
cognoms, ciutat on viu, . . . )
▪ Consistència : De tot SGBD s'espera que els resultats d'una lectura o cerca siguin
consistents de manera que si realitzem la mateixa cerca dues vegades obtinguem el
mateix resultat (sempre que les dades no hagin estat modificades). Si un altre usuari
realitza la mateixa cerca també haurà de rebre la mateixa informació. És a dir, una
mateixa dada no pot tenir més d'un resultat possible. En aquest sentit cal tenir en
compte que un mal disseny en una base de dades pot no tornar el mateix resultat
per a una mateixa cerca. Suposem que la informació de contacte d'un client difereix
de la informació de contacte d'aquest client en alguna de les comandes que heu fet.
Quina informació he d'utilitzar per contactar-hi?
▪ Validesa : El SGBD ha de proporcionar mecanismes que permetin validar la
informació que es registra a la Base de Dades. Per exemple, si hem d'indicar la data
d'una comanda al camp d'un formulari, cal esperar que l'SGBD sigui capaç de
verificar si el format de la dada introduïda és del tipus correcte.
▪ Velocitat Potser és una de les característiques més importants. La informació a un
SGBD s'ha de poder crear, modificar, llegir i eliminar ràpidament. En aquest aspecte
influeix en gran manera el disseny que s'ha realitzat de la Base de Dades. Un disseny
pobre pot incidir molt negativament en la velocitat daccés a les dades per part del
SGBD.
▪ Transaccions atòmiques Una transacció atòmica consisteix a realitzar una sèrie
d'accions com si es tractés d'una sola operació, i sense interferir de cap manera en
la correcta execució d'aquestes accions. És molt important tenir en compte que
aquestes transaccions s'han d'executar completament, o bé no executar cap de les
seves accions, mai no s'han d'executar a mitges. Més endavant, en aquest tema, es
detallaran com han de funcionar aquestes transaccions atòmiques.
▪ Persistència i suport per a Backups : Tota la informació emmagatzemada pel SGBD
ha de ser persistent. És a dir, no ha de desaparèixer. Un cop s'hagi fet una operació,
Tel. 977222231-601989689
la informació no es pot canviar. D'altra manera no podríem “confiar” a la nostra
Base de Dades. Si bé en condicions normals és relativament fàcil assegurar la
persistència de la informació, cal tenir en compte que hi ha diferents situacions que
poden posar en perill les dades. Suposem que estem donant d'alta una sèrie de
clients i en el mateix moment que acabem se'n va la llum. El SGBD haurà de ser
capaç d'emmagatzemar correctament les dades de totes aquelles operacions que
han estat confirmades (i no fer-ho en aquelles que no ho hagin estat). D'altra banda,
davant de situacions imprevistes com esborrats accidentals, fallades en els discos
durs, . . . es necessitaran eines per a la creació i restauració de Backups . En
definitiva, mecanismes per recuperar la informació en cas de fallades d'aquells
elements aliens al nostre SGBD però dels quals es depèn (disc dur, accions
accidentals dels usuaris, . . . )
▪ Capacitat d'estendre les característiques : Pot resultar molt interessant la capacitat
d'estendre les característiques de l'SGBD de manera que a mesura que passa el
temps puguem incorporar noves característiques a la Base de Dades que hi tinguem
emmagatzemada. En aquest cas també caldrà tenir en compte el disseny de la Base
de Dades ja que només un bon disseny permetrà estendre'n les capacitats sense
comprometre'n el rendiment.
▪ Seguretat : Tot Sistema d'Informació ha de proporcionar certs mecanismes de
seguretat que protegeixin la informació que s'hi emmagatzema. Aquests
mecanismes poden variar i sempre seran més grans com més sensible sigui la
informació emmagatzemada, però almenys s'haurà de comptar amb una correcta
gestió de comptes d'usuari i privilegis quant als accessos que els diferents usuaris
realitzen a l'SGBD per treballar amb la Base de Dades. Per descomptat, el bon ús
d'aquesta gestió de privilegis serà el que proporcioni la seguretat desitjada a les
nostres dades.
Funcions
Per això, podríem dir que les funcions de tot SGBD són les següents:
▪ Crear i organitzar la Base de Dades Aquesta eina s'encarrega de la creació i gestió

de la Base de Dades, abstraient els usuaris d'on i com s'organitza internament.
L'administrador de la base de dades disposa de les eines necessàries per crear i
Tel. 977222231-601989689
organitzar les bases de dades sense la necessitat de conèixer la implementació de
tota la resta.
▪ Control d'accés No tots els SGBD ho incorporen, però la majoria donen suport a un
control en l'accés a la informació mitjançant un sistema de comptes d'usuari i
privilegis pel qual l'administrador de la Base de Dades podrà decidir quins usuaris
pot fer determinades tasques sobre objectes determinats de la Base de Dades.
D'aquesta manera, es limita l'accés a la informació més crítica i es limiten les accions
que determinats usuaris poden fer sobre determinats objectes.
▪ Evitar la redundància i inconsistència de les dades Potser és una de les funcions
més importants que ha de dur a terme qualsevol SGBD. La redundància de dades fa
referència a la necessitat d'assegurar que una dada no es troba duplicada en algun
altre lloc de la Base de Dades. És un error molt comú i alhora molt perillós ja que pot
produir el que es coneix com a inconsistència de dades que té lloc quan, havent-hi
redundància, alguna de les còpies duplicades no s'actualitza correctament i la
mateixa dada pren més d'un valor diferent.
▪ Evitar anomalies a l'accés concurrent Atès que normalment diversos usuaris
intentaran accedir simultàniament a la mateixa Base de Dades, caldrà solucionar els
problemes que pugui ocasionar la modificació simultània d'una mateixa dada per
més d'un usuari. Qualsevol SGBD amb suport multiusuari haurà de donar suport a
aquesta característica.
▪ Garantir la correcta execució de les transaccions
Si parlem d'un SGBD amb suport per a transaccions (SGBD transaccional), aquest haurà de
proporcionar suport per a una execució correcta de les mateixes. En aquest sentit, hi ha un
conjunt de normes conegudes com ACID , que marquen aquelles característiques que tot SGBD
ha de suportar per a un funcionament correcte de les transaccions.
Tel. 977222231-601989689
▪ Atomicitat ( A tomicity): Cal assegurar si l'operació s'ha dut a terme o no. No hi pot
haver un terme mitjà
▪ Consistència ( C onsistency): Totes les operacions que comencen a executar-se han
d'assegurar-se que poden acabar sense trencar cap de les regles d'integritat de la
Base de Dades
▪ Aïllament ( I solation): Si s'executen dues transaccions sobre les mateixes dades
alhora (operacions concurrents), han de ser independents i no han de generar cap
error
▪ Durabilitat ( D urability): Un cop es faci l'operació, aquesta ha de persistir en el
temps. Fins i tot davant d'una fallada del sistema, si l'operació es va fer
correctament no es podrà desfer
Com a exemple per entendre el concepte de transacció cal imaginar el moviment de diners entre
dos comptes bancaris. Es tracta d'una sola operació que comporta l'execució de més d'una tasca
(retirar els diners del compte origen i incrementar-los al compte destí) de manera que mai
s'hauria d'executar a mitges (no podem només retirar els diners del compte origen o només
incrementar el saldo a la de destinació). Es tracta d'una transacció i, per tant, haurà de complir
les regles ACID per funcionar correctament.
▪ Respatller i recuperació La gran majoria de SGBD proporcionen eines addicionals

per al respatller i la recuperació. Ha de ser possible fer una còpia de seguretat de
tota la Base de Dades en qualsevol moment per a la seva posterior recuperació en
cas de fallada.
No tots els SGBD implementen totes les funcionalitats que s'han descrit anteriorment ja que en
determinades ocasions no ens caldrà. Per exemple, Microsoft Access no dóna suport a accés
concurrent ni tampoc dóna solució a certs problemes de seguretat i control d'accés, però no és
un dels objectius. Es tracta d'una base de dades inclosa en un paquet ofimàtic i no s'hauria de
fer servir en entorns més complexos. D'altra banda, sistemes com Oracle, SQL Server o MySQL
implementen molt bons suports per a accés concurrent, seguretat, control d'accés i moltes
altres funcionalitats, ja que són solucions destinades a entorns més complexos. Altres SGBD amb
prou feines implementen algunes de les característiques desitjables d'aquestes eines, ja que
estan destinats per a entorns amb poca capacitat de càlcul, com ara qualsevol dispositiu mòbil.
Per citar un exemple, el sistema operatiu Android utilitza un SGBD anomenat SQLite per les seves
reduïdes dimensions i necessitats quant a la capacitat de càlcul
Tel. 977222231-601989689
Components
Normalment hi ha una separació clara entre els components principals de la gran majoria de
SGBD. El més comú és la separació entre costat Client i costat Servidor ( Arquitectura Client-
Servidor ), encara que no tots els SGBD segueixen aquesta arquitectura. La gran part de la
funcionalitat la trobarem al costat del servidor, ja que és on s'emmagatzemaran sempre les
dades. El costat client és una eina força simple que serveix de comunicació entre usuari i el que
es coneix com el Motor (Engine) de l'SGBD, que forma la part servidor.
Si mirem dins del motor d'un SGBD, podem trobar-nos els components següents:
▪ Administrador d'Emmagatzematge : Controla l'accés a la informació de la Base de

Dades al disc. S'encarrega tant dels buffers com dels fitxers on s'emmagatzemen
totes les dades.
▪ Processador de consultes : S'encarrega de rebre les peticions de consultes i ha de
trobar la manera més òptima de realitzar-les a través del que es coneix com a Pla
d'Execució . Emet ordres a l'Administrador d'Emmagatzematge ja que és qui
accedeix finalment a les dades per proporcionar-les.
▪ Gestor de transaccions : Assegura que es mantingui la integritat de la Base de Dades
després de l'execució de transaccions, siguin fallides o no.
Tel. 977222231-601989689
Tipus
Atenent el model de dades utilitzat, destaquen els tipus següents, sempre tenint en compte que
algunes Bases de Dades poden estar en diverses d'aquestes categories. Per citar un exemple,
db4o és un conegut SGBD orientat a objectes i alhora és NoSQL ja que no utilitza el llenguatge
SQL per accedir a les dades que emmagatzema.
Tel. 977222231-601989689
Relacional
S'ajusten al model relacional, que actualment és el model de base de dades més estès. És el
model de dades més utilitzat actualment, basat en el concepte de taules i les relacions entre
elles com a forma de relacionar la informació entre si. Destaquen Ms Access , Oracle , Microsoft
SQL Server i MySQL com els SGBD relacionals més estesos actualment.
Els SGBD relacionals proporcionen una sèrie de funcionalitats, entre les quals destaquen les
següents:
▪ Tipus de dades : Cada columna té un tipus de dada definida de manera que l'SGBD
no permet emmagatzemar valors d'un altre tipus a aquesta columna
▪ Restriccions : És possible definir restriccions que obliguin a complir una sèrie de
requisits als valors que s'emmagatzemen en una columna determinada
▪ Integritat referencial : En el moment de registrar alguna nova dada que hagi d'estar
relacionada amb una altra, l'SGBD comprovarà que la segona existeix abans de
permetre el registre. En cas contrari no ho permetrà
▪ Consultes complexes : És possible realitzar consultes molt complexes, fins i tot
aquelles que inicialment no havien estat tingudes en compte durant el disseny de la
Base de Dades
Tel. 977222231-601989689
Les bases de dades relacionals són apropiades si:
▪ Cal fer consultes molt complexes entre diferents taules

▪ Cal validar la informació entre taules
▪ Es permet que una dada pugui tenir qualsevol nombre de valors
▪ És necessari construir noves consultes que no havien estat planificades quan es va
dissenyar la Base de Dades
D'altra banda, no són apropiades si:
▪ És necessari definir una topologia determinada per treballar amb l'aplicació

corresponent, tal com podria ser una jerarquia o una xarxa. Per a aquests casos hi
ha tipus de SGBD específics que proporcionen més rendiment
▪ En molt comptades situacions on les necessitats de rendiment són molt elevades i
les regles a què se sotmeten les Bases de Dades relacionals alenteixen el
funcionament global
XML
XML és un llenguatge per emmagatzemar informació de forma jeràrquica. És un llenguatge que

no proporciona cap manera de crear, cercar, modificar o validar informació. Tanmateix, es fa
servir àmpliament per emmagatzemar, transferir i recuperar dades jeràrquiques i hi ha moltes
eines per treballar amb aquests fitxers d'una manera senzilla.
A més, és un llenguatge molt utilitzat per a lintercanvi dinformació entre aplicacions remotes a
través dInternet.
En definitiva, el llenguatge XML només especifica la manera d'escriure el fitxer i organitzar la

informació mitjançant les etiquetes que dóna sentit a cadascun dels valors emmagatzemats i la
jerarquia entre aquestes etiquetes en marca la dependència. Així, en funció de l'ús que volem
donar-li, ens haurem de fer amb l'eina determinada que ens permeti gestionar el fitxer XML de
la manera que més ens convingui. Per al cas que ens ocupa, hi ha eines com xbird que permeten
accedir a fitxers XML per treballar com si fos una Base de Dades, proporcionant el que es coneix
com a processador XQuery per donar suport a un llenguatge de consultes i proporcionant un
rendiment òptim en l'accés a les dades, podent treballar amb fitxers de fins a diversos GBs.
Tel. 977222231-601989689
Les bases de dades XML són apropiades si:
▪ Les dades són jeràrquiques

▪ Les eines XML proporcionen les funcionalitats que necessites
▪ Utilitzaràs aplicacions programari que entenen el format XML
Tel. 977222231-601989689
D'altra banda, no convenen si:
▪ Les dades no són jeràrquiques

▪ Cal fer validacions complicades
▪ Cal relacionar d'alguna manera la informació
▪ La Base de Dades és molt gran com per reescriure el fitxer complet cada cop que es
realitza algun canvi
Orientat a objectes
En aquest model tots els elements de la Base de Dades es representen com a objectes i
segueixen el paradigma de la Programació Orientada a Objectes . L'objectiu d'aquest tipus de
bases de dades és el treball en unió amb algun llenguatge de programació del mateix paradigma.
D'aquesta manera els objectes de l'aplicació tenen una correspondència directa amb els
objectes a la Base de Dades, ja que poden fer servir el mateix model de dades.
Com que el paradigma d'orientació a objectes és relativament nou, i encara que a la programació
està força estès, a les Bases de Dades no està gaire acceptat. Hi ha ja alguns SGBD comercials
però el seu ús és minoritari. Entre ells destaca db4o i |InterSystems Caché
Tel. 977222231-601989689
Les bases de dades orientades a objectes són apropiades si:
▪ L'aplicació està programant-se amb algun llenguatge de programació orientat a

objectes
▪ No cal fer consultes molt complexes
▪ Cal comunicar-se amb eines externes per emmagatzemar certa informació en altres
models més habituals com el relacional
▪ Cal fer consultes complexes
▪ L'aplicació no es programarà amb un llenguatge orientat a objectes
▪ Cal fer certes validacions que aquest tipus de bases de dades no proporciona
Objecte-Relacional
Apareixen com una extensió al model relacional, de manera que les dades s'emmagatzemen en
forma de taules. I a més, permeten la utilització de certes característiques pròpies de la
Programació Orientada a Objectes (POO) com poden ser l'Herència o l'ús de tipus més
complexos com són les col·leccions o els camps estructurats. Cal destacar PostgreSQL com a
SGBD objecte-relacional, que actualment està força estès.
Les Bases de Dades objecte-relacionals són apropiades si:
▪ L'arquitectura de l'aplicació està orientada a objectes

▪ Cal fer consultes complexes de dades relacionades entre si
▪ Cal fer validacions de dades
▪ A l'equip de treball es manté una separació entre programadors de l'aplicació i la
base de dades
▪ Per al desenvolupament de l'aplicació no es farà servir un llenguatge orientat a

objectes
NoSQL
Tel. 977222231-601989689
Apareixen com un canvi de tendència davant dels clàssics SGBD relacionals. La seva principal
característica és que no utilitzen el llenguatge SQL com a principal llenguatge de consultes
(d'aquí el seu nom, No only SQL). Tampoc suporten operacions JOIN com en els sistemes
relacionals i no solen garantir ACID .
La seva característica principal és l'escalabilitat horitzontal. És a dir, el rendiment de la Base de

Dades es manté a mesura que es van afegint nodes (equips) al sistema. Això va començar a ser
una necessitat quan les principals companyies d'Internet (Google, Amazon, Twitter, . . .) van
començar a necessitar grans sistemes que donessin resposta en temps real. Els clàssics SGBD
relacionals no donaven resposta a les seves necessitats, ja que empren gran part del temps en
fer les validacions i verificar la coherència entre les dades. Els sistemes NoSQL resten
importància a aquest aspecte i permeten oferir un major rendiment al conjunt per a determinats
tipus i estructures de dades.
En general, les Bases de Dades NoSQL són apropiades si:
▪ Cal manejar grans quantitats de dades

▪ Cal escalar (afegint nodes al sistema)
D'altra banda, no són apropiades per a qualsevol tipus de projecte ja que el rendiment no
sempre serà el més important, o almenys no a costa de perdre regles de validació o coherència
o no garantir ACID .
Alguns exemples coneguts de SGBD NoSQL són MongoDB i Cassandra , encara que també podem
considerar com SGBD NoSQL a db4o , que en tractar-se d'un SGBD orientat a objectes no empra
SQL com a llenguatge principal de consulta, encara que difereix força en funcionament dels dos
anteriors i de algunes de les característiques principals dels SGBD NoSQL.
Tel. 977222231-601989689
Classificació segons accessos simultanis suportats
Monousuari
Són aquells SGBD que no permeten que més d'un usuari pugui estar connectat amb la base de
dades alhora. Normalment no suporten cap tipus de control d'usuari, per la qual cosa la Base de
Dades es reduirà a un simple fitxer al qual es podrà accedir des de l'aplicació com si es tractés
de qualsevol altre tipus de document. Així, no suporten el control de concurrència ni qualsevol
altra característica pròpia dels sistemes multiusuaris. Alguns SGBD monousuari són Ms Access i
LibreOffice Base .
Multiusuari
Permeten connexions simultànies amb una mateixa base de dades. Té suport per a control de
comptes dusuari, i per tant inclouen tot el suport per al control de concurrència, propi de
qualsevol sistema multiusuari. Alguns SGBD multiusuari són MySQL , PostgreSQL , Microsoft SQL
Server , Oracle , MongoDB i Cassandra .
Classificació segons mida
SGBD lleuger
Tel. 977222231-601989689
Es tracta de petits SGBD (fins i tot < 1MByte de mida) que donen suport a algunes de les
principals funcions d'aquestes eines, ideals per a entorns on no cal un gran rendiment o bé no
es disposa de gran potència de càlcul (dispositius mòbils). El més conegut actualment és SQLite
SGBD Ofimàtica
Una mica més potents que els SGBD considerats com a lleugers, amb algunes funcions més, molt
utilitzats en Ofimàtica per a petites Bases de Dades (normalment alguns MBytes). Ms Access i
LibreOffice Base són dos exemples d'aquesta categoria
SGBD d'alt rendiment
Ideals per a entorns dedicats a la gestió de dades o bé per a aplicacions que manegen ja una
gran quantitat de dades i necessiten algunes funcions que altres SGBD no proporcionen, com a
control d'usuaris, concurrència, suport per a transaccions o altres operacions. MySQL , Microsoft
SQL Server , Oracle i PostgreSQL són alguns exemples Altres SGBD d'alt rendiment, encara que
són algunes característiques diferents als anteriors, són MongoDB i Cassandra .
Tipus de Bases de Dades
Bases de dades centralitzades
Són el tipus de bases de dades més comú. Normalment, en grans corporacions, es dedica un
únic equip per a l'emmagatzematge i la gestió de les dades utilitzant algun tipus de SGBD. Tota
la Base de Dades es troba ubicada lògicament i físicament en aquest equip. És la solució més
habitual ja que normalment n'hi ha prou ia més és molt més senzilla d'implementar.
Tel. 977222231-601989689
Avantatges
▪ Fàcil implementació. En tractar-se d'una solució àmpliament adoptada és més

senzill d'implementar i més fàcil actuar davant de possibles errors
▪ Disseny senzill. Com que es tracta d'una solució coneguda, el disseny lògic és també
més senzill de fer
Desavantatges
▪ En cas de fallada, en existir una sola ubicació física de la Base de Dades, aquesta
afectarà totes les dades emmagatzemades en ella.
Bases de dades distribuïdes
Una Base de Dades distribuïda és un conjunt de bases de dades relacionades lògicament entre
si que es troben localitzades a diferents ubicacions físiques. Es pot tractar de dues màquines
connectades entre si mitjançant una LAN o bé mitjançant Internet. Com a conseqüència,
aquestes Bases de Dades poden fer tasques de forma autònoma o bé de forma distribuïda. En
el cas de les operacions realitzades de forma distribuïda, l'usuari de qualsevol de les dues (o
més) màquines tindrà accés a tota la informació com si estiguessin sent accedits de forma local.
Tel. 977222231-601989689
Avantatges
▪ És més barat crear una xarxa de màquines de baix rendiment que tenir una sola
màquina molt potent
▪ Quant a la disponibilitat, una fallada en qualsevol dels nodes no afecta la resta, per
la qual cosa la resta de la Base de Dades seguirà accessible
▪ Com que les dades es troben distribuïdes, aquestes poden ubicar-se on més
interessa. Per exemple al departament amb què tenen relació. A més, aquest
departament disposarà de l'autonomia necessària per controlar aquesta informació
Desavantatges
▪ Un sistema de Bases de Dades distribuïda és complex de posar en marxa i mantenir

▪ Quant a la seguretat, en disposar de diversos nodes, es disposa de diversos sistemes
diferents que caldrà protegir
▪ És un sistema força nou, per la qual cosa hi ha poca experiència davant fallades poc
comunes
▪ En disposar de diversos nodes és possible que necessiteu més mà d'obra
especialitzada en cadascun d'ells
Arquitectura d'una aplicació
Un cop hem vist què és un SGBD, una Base de Dades i els diferents tipus amb què ens podem
trobar just amb els seus avantatges i inconvenients, convé fer una ullada d'una manera més
global per veure quina és la posició d'un SGBD i la Base de Dades al conjunt d'una aplicació ja
desenvolupada.
Tel. 977222231-601989689
Com ja s'ha vist més amunt, molts dels SGBD treballen seguint allò que es coneix com a
arquitectura client-servidor. Seguint aquesta mateixa filosofia, hi ha la programació per capes ,
que consisteix en una arquitectura en què el principal objectiu és la separació de les diferents
capes lògiques d'una aplicació (presentació, negoci i dades). Per això, l'arquitectura més
coneguda és l'arquitectura de 3 capes, on l'estructura de l'aplicació se separa en tres nivells. Tot
i que no sempre les 3 capes estan separades físicament, és convenient que ho estiguin
lògicament. La separació física vindrà donada per la pròpia naturalesa de l'aplicació (aplicació
web) o bé per les necessitats pròpies quant a rendiment de la mateixa (un o més equips per
donar suport a la capa de negoci o dades).
▪ Capa de presentació És la capa que veu lusuari. Presenta l'aplicació a l'usuari, us

permet interactuar-hi i us mostra la informació que aquest sol·licita. En definitiva,
és el que es coneix com a interfície d'usuari.
▪ Capa de negoci En aquesta capa es troba tota la lògica de l'aplicació i serà on es
realitzin tots els processos de tractament de la informació obtinguda a la capa de
dades i els resultats de la qual es mostren a l'usuari mitjançant la capa de
presentació.
▪ Capa de dades En aquesta capa resideixen les dades. S'hi troben els SGBD i reben
peticions per accedir o escriure dades des de la capa de negoci.
En aplicacions de mida mitjana és força habitual trobar un model lògic basat en 3 capes però
físicament distribuït només en 2. En aquests casos el més habitual serà que l'usuari carregui la
capa de presentació al seu propi equip (ja sigui executant l'aplicació o carregant la web al vostre
navegador) i que les capes de negoci i dades es trobin en un altre equip remot (el servidor). A
mesura que l'aplicació es faci més exigent les capes de negoci i dades es poden separar en
diferents equips (normalment físicament més a prop) i segons s'exigeix un rendiment més gran
es poden afegir equips a qualsevol d'aquestes dues capes.
Tel. 977222231-601989689
Tel. 977222231-601989689
Disseny de Bases de Dades
Els passos del disseny d'una Base de Dades, representats a la figura següent, es poden resumir
en
▪ Recol·lecció i anàlisi de requeriments : En aquest pas recollim informació del

sistema per al qual hem de dissenyar la Base de Dades.
▪ Disseny conceptual : Un cop recollits tots els requisits i conegut el problema,
realitzem un primer esquema conceptual en algun llenguatge d'alt nivell com és el
Model Entitat-Relació
▪ Disseny lògic : El disseny conceptual ha de ser transformat ara en un disseny lògic,
que és la transformació d'un model conceptual a un model de dades concret per tal
de poder representar el problema, més endavant, en algun programari concret. En
el nostre cas farem servir el Model Relacional .
▪ Disseny físic : En aquest punt hem d'aplicar el model lògic de dades del punt anterior
sobre un SGBD concret. Depenent del disseny físic escollit, tindrem un ventall de
possibilitats pel que fa al programari disponible. En el nostre cas hem optat per un
model relacional per la qual cosa haurem d'escollir entre els SGBD relacionals
disponibles. En aquest curs serà MySQL .
Tel. 977222231-601989689
Model Entitat/Relació
És un model de dades que representa la realitat a través d' entitats , que són objectes que
existeixen i es distingeixen d'altres per les seves característiques, que anomenem atributs . A
més, aquestes entitats podran o no estar relacionades les unes amb les altres a través del que
es coneix com a relació . Cal tenir en compte que només es tracta d'un model de representació,
per la qual cosa no té correspondència real amb cap sistema d'emmagatzematge. S'utilitza a
l'etapa d'Anàlisi i Disseny d'una Base de Dades, per la qual cosa caldrà convertir-la a un altre
model abans de començar a treballar-hi.
Tel. 977222231-601989689
Una entitat és un objecte que existeix en una realitat que volem representar, per exemple, un
alumne, que es distingeix d'un altre per les seves característiques com poden ser: nom,
cognoms, número d'expedient, . . .
Les entitats es representen pel símbol següent: Aquestes característiques

que fan que unes entitats es distingeixin d'altres, són els atributs . El nom, els cognoms i el
número dexpedient serien atributs de lentitat alumne. Els atributs es representen pel símbol
següent: Alhora, podem relacionar unes entitats amb les altres a

través del que es coneix com a relació . Per exemple, dues entitats alumne i assignatura podrien
estar relacionades entre si ja que un alumne cursa una assignatura (o diverses). Cal ressaltar que
una relació entre dues entitats no expressa obligatorietat de relació sinó possibilitat de
relacionar-se.
En aquest cas, no cal que tots els alumnes cursin una assignatura o que una assignatura sigui
cursada per tots els alumnes perquè la relació s'estableixi. Per tant, en aquest cas s'estableix
que entre aquestes dues entitats hi ha una relació que podríem anomenar cursa . Les relacions
es representen pel següent símbol:
Si considerem que dues entitats A i B estan relacionades a través d'una relació R, haurem de
determinar el que es coneix com a cardinalitat de la relació , que determina totes les entitats de
tipus A que es relacionen, com a màxim, amb totes les entitats de tipus B. A més , resulta
convenient, en cada cas, calcular quantes entitats de tipus A es relacionen, com a mínim, amb
totes les entitats de tipus B (que normalment serà 0 o 1). D'aquesta manera podrem indicar
l'obligatorietat o no de la relació entre elements de les entitats A i B.
Tel. 977222231-601989689
Relació un a un
En aquesta relació una entitat de tipus A només es pot relacionar amb una entitat de tipus B i
viceversa. Per exemple, si suposem dues entitats Curs i Aula , relacionades a través d'una relació
S'Imparteix , podrem suposar que un Curs s'imparteix en una Aula i en una Aula només es pot
impartir un Curs . Es representaria com segueix:
Relació un a molts
Indica que una entitat de tipus A es pot relacionar amb un nombre indeterminat d'entitats de
tipus B, però alhora una entitat de tipus B només es pot relacionar amb una entitat de tipus A.
Si suposem una entitat Propietari i una altra entitat Vehicle relacionades a mitjançant una relació
Posseeix , podrem suposar que un Propietari pot posseir diversos Vehicles , mentre que cada
Vehicle només pot pertànyer a un Propietari .
Quedaria representat de la següent manera:
Tel. 977222231-601989689
Relació molts a un
Significa que una entitat de tipus A només es pot relacionar amb una entitat de tipus B, però
una entitat de tipus B es pot relacionar amb un nombre indeterminat d'entitats de tipus A. En
realitat es tracta com una relació un a molts però el sentit de la relació és l'invers.
Relació molts a molts
En aquest cas, tant les entitats de tipus A i B poden relacionar-se amb un nombre indeterminat
d'entitats de l'altre tipus. Per exemple, si suposem les entitats Alumne i Assignatura i una relació
Cursa , podrem suposar que un Alumne cursa diverses assignatures mentre que una Assignatura
la cursen diversos Alumnes . Quedaria representat de la següent manera:
Diagrama Entitat/Relació
Es coneix com a Diagrama Entitat/Relació (E/R) al diagrama resultant de modelar un món real
seguint el model Entitat/Relació. Com a resultat, es modelen totes les entitats amb els seus
atributs, així com totes les relacions existents entre elles, juntament amb la cardinalitat.
Tel. 977222231-601989689
Herència
Tel. 977222231-601989689
També és possible representar un altre tipus de relacions entre objectes del nostre sistema. La
relació dherència, representada com un triangle (veure figura), expressa que un objecte és un
subtipus dun altre objecte. També se sol considerar el subtipus com una especialització del
primer o el primer com una generalització del segon.
En el cas de l'exemple, hi ha dos tipus d'empleats que es relacionen de manera diferent amb
altres objectes del sistema, però que poden tenir gran part en comú. Per exemple, treballen de
manera diferent però moltes de les dades personals que emmagatzemarem de tots dos són
comunes. És per això que l'objecte emprat es pot considerar una generalització dels dos tipus
de treballadors que hi ha al sistema. Tots aquells atributs i relacions que tinguin en comú es
podrà representar com a atributs i funcionalitat de l'objecte Empleat i els atributs i relacions que
tinguin com a treballadors especialitzats seran representats en el corresponent objecte.
Reflexivitat
Tel. 977222231-601989689
És possible que la mateixa entitat ocupi ambdós costats duna relació. En aquest cas estem
davant del que es coneix com a relacions reflexives. La cardinalitat de la relació indicarà si tots
els elements de la relació estan relacionats reflexivament o bé només alguns estan relacionats
entre ells. En el cas de la figura podríem suposar una empresa on alguns empleats fan de
supervisor d'altres empleats.
Atributs multivaluats
Els atributs multivaluats són aquells atributs que poden contenir una quantitat indeterminada
de valors.
Atributs estructurats (o compostos)
Tel. 977222231-601989689
Els atributs estructurats o compostos són els atributs que poden estar composts per altres
atributs. Normalment són atributs que es poden descompondre encara que depenent del
context de l'aplicació pot no interessar fer aquesta descomposició i tractar-ho com un atribut
simple.
Atributs derivats
Els atributs derivats (o calculats) són aquells atributs el valor dels quals pot ser deduït fent
algunes operacions amb altres atributs de la mateixa entitat o d'altres entitats. En algunes
situacions es podria considerar redundant (ja que el seu valor es pot deduir) però en altres pot
resultar còmode emmagatzemar-ho ja calculat ja que es pot estalviar molt de temps de còmput
si es tracta d'un valor de càlcul difícil i/o recurrent.
Comprovacions sobre el Diagrama Entitat-Relació
1. Resulta còmode que les entitats estiguin escrites en minúscula per fer totes
aquestes comprovacions
Tel. 977222231-601989689
2. Comprovar que el nostre diagrama no ha esdevingut un diagrama de flux i no descriu
processos, sinó magatzems de dades
3. Comprovar que les Entitats són noms de coses i les relacions són verbs
4. Comprovar que cap Entitat té com a atribut alguna cosa que existeix com a Entitat
(si s'escau, s'haurien de relacionar ambdues Entitats)
5. Comprovar que diverses entitats no comparteixen un mateix atribut estructurat que
pugui ser considerat realment com una entitat
6. Evitar els cicles (si n'apareix algun, que pot passar, comprovar que cal)
7. Si una relació té diversos atributs, valorar si és possible que realment hagi de ser
una nova Entitat (Comprar → Comanda, Llogar → Lloguer, Reservar → Reserva,
Enviar → Enviament, . . .)
8. Comprovar que no hi ha col·locada cap cardinalitat al revés: S'ha de poder llegir: un
Usuari Realitza de 0 a N Comandes . Usuari i Comanda són entitats i Realitzar la
relació entre totes dues. En aquest cas, (0, N) hauria d'estar escrit al costat Comanda
perquè pogués llegir-se correctament
9. Continuarà. . .
Exemples de disseny
▪ Dissenyar un model Entitat/Relació (entitats, atributs i relacions)
▪ Dissenyar un model Entitat/Relació (cicles i redundància)
▪ Dissenyar un model Entitat/Relació (atributs multivaluats, compostos i derivats)
Model relacional
El model relacional és un altre model de representació on les dades i les seves relacions es
representen a través de taules, i on els atributs es tradueixen en camps d'aquestes taules. És el
model de representació que segueix la gran majoria dels SGBD relacionals (MySQL, SQL Server,
Oracle, Ms Access, entre d'altres) actualment, ja que és el model de dades més estès.
Tel. 977222231-601989689
Així, cal transformar el nostre model Entitat/Relació a un model relacional si volem crear la
nostra Base de Dades en algun SGBD relacional.
Pas del model E/R al model relacional
El pas d'un model E/R a un model relacional es pot dur a terme, en gran part, seguint una sèrie
de regles o pautes que s'enumeren a continuació:
▪ Tota entitat es transforma en una taula

▪ Tot atribut simple o derivat es transforma en una columna d'una taula
▪ Els atributs estructurats transformen els camps en què es componen en noves
columnes de la taula
▪ L' identificador únic de l'entitat esdevé clau primària
▪ Els atributs multivaluats generen una taula nova amb tres columnes: un id , l' id de
la taula de la qual sorgeixen propagat com a clau aliena i el valor del camp
multivaluat
Tel. 977222231-601989689
▪ Tota relació N:M es transforma en una taula que tindrà com a clau primària la
concatenació dels atributs clau de les entitats que hi relaciona.
▪ En la transformació de relacions 1:N hi ha dues possibilitats:
▪ Transformar-ho en una taula. Es fa com si fos una relació N:M. És
convenient fer-ho així en cas que es prevegi que en un futur la relació
pot transformar-se en N:M i quan la relació té atributs propis
▪ Propagar la clau. Es propaga l'atribut principal de l'entitat que té de
cardinalitat màxima 1 a la que té cardinalitat màxima N fent
desaparèixer a la relació
▪ En la transformació de relacions 1:1 es tenen en compte les cardinalitats de les
entitats que hi participen. Hi ha també dues solucions:
▪ Transformar-ho en una taula. Si les entitats tenen cardinalitats (0,1), la
relació es converteix en una taula
▪ Propagar la clau. Si una de les entitats té cardinalitat (0,1) i l'altra (1,1),
es propaga la clau de l'entitat amb cardinalitat (1,1) a la taula resultant
de l'entitat de cardinalitat (0,1). Si totes dues tenen cardinalitats (1,1),
es pot propagar la clau de qualsevol a la taula resultant de l'altra
▪ Per als atributs de les relacions hi ha dos casos:
▪ Si la relació és 1:N, els seus atributs es propaguen a la taula de costat N,
juntament amb la clau del costat 1
▪ Si la relació és N:M, els seus atributs es transformen en columnes de la
taula generada per aquesta relació
▪ Les relacions d' herència es poden transformar de diverses maneres. La més senzilla
serà crear una taula per entitat (de la qual s'hereta i les que hereten), cada entitat
transforma els seus atributs seguint les regles anteriors, i al final, la taula que resulta
de l'entitat base (de la qual s'hereta) propaga la seva clau com a clau aliena a
cadascuna de les taules que resulten de les entitats que heretaven.
Les situacions més particulars caldrà estudiar-les i aplicar algun patró de disseny conegut, si n'hi
ha, per generar el corresponent model relacional. Aquests casos no sempre es podran reflectir
al corresponent model Entitat-Relació ja que alguns tenen a veure amb exigències tècniques o
de temps, més que amb el propi model de dades. Alguns casos particulars poden ser:
▪ Dades temporals : Com representar en un model relacional dades que tenen data
de caducitat (els preus d'un producte del qual volem tenir un històric de preus, . . .)
Tel. 977222231-601989689
▪ Dades eliminades : Com representar en un model relacional dades que es volen
eliminar, però que per alguna raó necessitem que segueixin estant
emmagatzemades a la base de dades (productes descatalogats, alumnes que
acaben els seus estudis, . . .)
▪ Registre o auditoria : Com podem registrar les accions dels usuaris o de l'aplicació
durant el cicle de vida de la Base de Dades.
▪ Bloqueig de registres : Com podem bloquejar l'accés a un registre per evitar la
modificació simultània de la mateixa dada per més d'un usuari des de l'aplicació que
connecta amb la base de dades.
En qualsevol cas, aplicar correctament al model relacional resultant les regles de normalització
eliminaran totes les anomalies que el nostre model pugui contenir. Així, cal tenir en compte que
el model relacional que hem obtingut en aquest moment encara pot no ser el definitiu i pot patir
transformacions (i fins i tot es poden afegir noves taules) com a resultat d'aplicar les regles de
normalització que es passen a explicar a el punt següent.
Exemples de transformacions a model relacional
▪ Transformar relacions 1 a 1 al model relacional
▪ Transformar relacions N a M al model relacional
▪ Transformar relacions 1 a N al model relacional
▪ Tranformar una herència al model relacional
▪ Transformar relacions reflexives al model relacional
▪ Transformar atributs al model relacional
Tel. 977222231-601989689
▪ Exemple complet de disseny i transformació de model Entitat/Relació a model
relacional
▪ Transformar un model Entitat/Relació a model relacional
Normalització de models relacionals
Un dels reptes en el disseny de tota Base de Dades és obtenir una estructura estable tal que:
▪ El sistema no patiu anomalies d'emmagatzematge

▪ El model lògic es pot modificar si apareixen nous requisits
Una Base de Dades ben dissenyada té més esperança de vida, fins i tot en un ambient dinàmic
on puguin aparèixer nous requisits, que una Base de Dades amb un disseny pobre. Com a
mitjana, una Base de Dades pot patir una reorganització cada sis anys, depenent de la dinàmica
que siguin els seus requisits. Si la Base de Dades es dissenya bé seguiran tenint un bon rendiment
encara que augmenti la mida, i serà prou flexible per suportar els nous requisits i/o
característiques addicionals.
Actualment hi ha diversos regs en el disseny de Bases de Dades relacionals. Els més habituals
són la redundància dinformació i la inconsistència de dades.
La normalització és el procés de simplificar la relació entre els camps d'un registre de manera
que aquest es reemplaça per diversos registres més simples i predictibles i, per tant, més
manejables. En definitiva, la normalització busca simplificar el disseny perquè aquest sigui més
fàcil incorporar noves funcionalitats amb el pas del temps i no baixi el seu rendiment quan la
quantitat de dades emmagatzemades hi augmentin considerablement.
La teoria de la normalització es basa en el que es coneix com a Formes Normals. Cadascuna

d'aquestes Formes Normals estableix una sèrie de restriccions que el disseny haurà de complir
per satisfer aquesta Forma. En aquest curs veurem les tres primeres FN (Formes Normals).
Primera forma normal
Es diu que una taula està en primera forma normal si una taula té les propietats següents:
Tel. 977222231-601989689
▪ Cada columna té un valor únic
▪ L'ordre de les files i les columnes no importa
▪ Cada columna ha de tenir un únic tipus de dades
▪ Dues files no contenen valors idèntics
▪ Cada columna conté un sol valor
▪ Les columnes no poden contenir valors repetits
Suposem el cas més comú que un camp pugui tenir més d'un valor. Per normalitzar una taula
que no està en primera forma normal per aquesta raó, cal seguir aquests passos:
▪ Es localitzen els atributs corresponents a la clau principal

▪ Es fa una projecció sobre la taula i es descompon en diverses, de manera que es fa
la projecció de la clau sobre cadascun dels valors de l'atribut que no és atòmic
Per al cas de taules que incompleixen l'última de les propietats i posseeix columnes amb valors
repetits (una taula de clients amb els camps telèfon 1, telèfon 2, telèfon 3, . . .) s'opera de forma
molt similar, ja que es diu valors s'han d'emmagatzemar en una taula nova i utilitzar la clau
principal de la primera per referenciar aquests nous valors.
Segona forma normal
Aquesta formal normal només ha de ser considerada per a aquelles taules en què la clau
principal sigui composta. Si no fos així, la taula estaria, de manera directa, en segona forma
normal.
Diem que una taula està en segona forma normal si es compleixen les condicions següents:
▪ Està a 1FN
▪ Tot atribut secundari (que no pertanyi a la clau principal) té una dependència
funcional total de la clau principal, i no d'una part
Tel. 977222231-601989689
Es diu un atribut B depèn funcionalment de A ( A→B ) si cada valor d'A es correspon amb un únic
valor de B. Vist d'una altra manera, si donat A puc obtenir B. Un cas típic podria ser DNI → Nom
, posat que donat un DNI puc obtenir, de manera unívoca, el nom de la persona
Per convertir una taula que no és a 2FN es crearà una taula amb la clau i totes les seves
dependències funcionals totals i una altra taula amb la part de la clau que té dependències amb
els atributs secundaris.
A l'exemple podem veure com el camp TelefonoProveedor no depèn totalment de la clau

(NomProducte, NomProveïdor) , sinó únicament del camp NomProveïdor .
Tercera forma normal
Es diu que una taula està en tercera forma normal si:
▪ Està a 2FN
▪ No hi ha atributs no primaris (que no pertanyin a la clau) que són transitivament
dependents de cada possible clau de la taula. És a dir, un atribut secundari només
pot ser conegut a través de la clau principal i no mitjançant un atribut no primari
Per convertir una taula que no està a 3FN es realitzarà una projecció de la clau als elements que
no tinguin dependència funcional transitiva i una altra taula amb una nova clau als elements que
anteriorment tenien aquesta dependència.
Tel. 977222231-601989689
A l'exemple, és possible conèixer l'edat de l'inscrit a través del número de llicència, i atesa l'edat
podem conèixer la seva categoria, tenim una dependència funcional transitiva. El que és
important és tenir en compte que la categoria depèn d'un atribut que no forma part de la clau.
Per normalitzar, hem de descompondre aquesta taula a les taules Atletes i Categories
2. Identificació dels conceptes bàsics del llenguatge Java així com de les eines per
desenvolupar i executar un programa escrit en aquest llenguatge.
2.1 Conceptes bàsics
Programar significar crear una sèrie d’ordres per a que la màquina entengui el que ha de fer i,
per tant, fer possible la concepció del programa. Aquesta llista d’ordres o instruccions
s’anomena algoritme. Per realitzar qualsevol programa, es necessari idea prèviament un
algoritme, que seria bàsicament una seqüencia ordenada de passes que condueixen a solucionar
un problema. Bàsicament, tenen tres característiques principals:
- Són precisos, indicant l’ordre de realització de les passes.

- Estan ben definits i sempre donen la mateixa solució.
- Són finits, per tant tenen unes passes concretes i delimitades.
Un llenguatge de programació és un conjunt de símbols que es combinen d’acord amb una

sintaxi ben definida per fer possible la transmissió d’instruccions a la CPU. És a dir, és el codi
amb el que volem transmetre al ordinador les ordres d’un programa. Els llenguatges poden tenir
un estilo o paradigma de programació concret; poden tenir un nivell d’abstracció diferenciat
Tel. 977222231-601989689
(baix nivell i alt) i, segons el procés de traducció del codi, tenim llenguatges interpretats,
compilats i ensamblats.
Els llenguatges han evolucionat des de els anys 50-70, des d’una programació-estructura, a una
estructura clàssica (1970-1990) o modular (1970-1999), a una orientada a objectes, que és el
tipus de llenguatge més habitual avui dia. Tot i que hi ha més paradigmes, aquests són els
majoritaris:
- La programació-estructura utilitza indistintament salts i bucles per aconseguir el seu

objectiu. Avui dia és molt mala praxis.
- Programació estructura clàssica, que és una tècnica que utilitza una sèrie d’estructures
específiques per optimitzar els recursos lògics i físic de l’ordinador. Java n’ha heretat
certs elements.
- Programació modular, que consisteix en dividir un programa complex en diversos
programes petits que interaccionen. Cada programa és un mòdul i cooperen entre sí,
però són independents. Pot conviure perfectament amb programació estructurada i de
fet així va ser. Avui dia encara tenim elements heretats d’aquesta lògica.
- Programació orientada a objectes, que bàsicament és un tipus de programació
estructura i modular en el que les instruccions i les dades queden encapsulades en
entitats anomenades classes, de las que després creen objectes.
A l’actualitat, bàsicament tots els llenguatges moderns permeten l’orientació a objectes, i fins i
tot llenguatges clàssics com C han evolucionat a C++ per permetre-ho.
Així mateix, diferenciem llenguatges d’alt i de baix nivell. Les màquines només entenen el
llenguatge binari (zeros i uns) i els humans tenim un llenguatge molt més complex, que
anomenem llenguatge natural. Entre el binari i el natural tenim els llenguatges de programació
(llenguatge reduït i estricte a nivell de regles). Si aquests són molt semblants a la lògica binaria,
diem que són de baix nivell. Si s’apropen al llenguatge natural, serien d’alt nivell. Per fer la
traducció per a que les màquines entenguin el que es diu, tenim uns altres programes que
s’encarreguen de traduir el codi d’alt nivell, especialment, a un codi màquina. Es diuen
compiladors i intèrprets. Per tant, el codi d’alt nivell, tot i ser portable d’un hardware a un altre,
ha de ser traduït a codi màquina per un compilador diferenciat depenent de la plataforma a on
va dirigit.
En relació amb aquests programes que tradueixen llenguatge a codi màquina, en podem
diferenciar de tres tipus: un ensamblador, un compilador i un intèrpret.
Tel. 977222231-601989689
- Ensambladors: programes encarregats de traduir programes escrits en ensamblador
(baix nivell) a codi binari. Són programes poc complexos.
- Compiladors, un programa que tradueix el codi d’alt nivell (que no de baix nivell, com
l’anterior) a codi binari, però de manera molt més complexa que l’ensamblador. Hem
de diferenciar el programa escrit d’alt nivell (codi font); el programa traduït (codi
objecte). De manera que el compilador converteix un programa font a un programa
objecte.
- Intèrpret és un programa que tradueix codi d’alt nivell a codi binari però, a diferencia
del compilador, ho fa en temps d’execució. No és necessari una traducció amb un
programa diferenciat.
És important veure aquí les diferencies fonamentals. L’intèrpret és més lent per la simple raó de
que va traduint mentre el flux del codi va avançant. El compilador, en canvi, al ser traduït
prèviament en la seva totalitat, funciona molt més ràpid. L’avantatge del intèrpret és que
funciona en qualsevol plataforma, mentre que el compilat ha de ser traduït a cada un dels
Tel. 977222231-601989689
sistemes. JavaScript és interpretat, no així C++., que és molt més ràpid però cal adaptar-se al
hardware o al sistema operatiu de destí.
En el cas particular de Java, tenim el concepte del Bytecode. Al crear-se Java es va voler que fos
un llenguatge altament portable i altament eficient (les avantatges del interpretat i el compilat).
Per fer-ho possible, van idear una espècie de semi-compilació. El codi font es compilar en codi
binari, però no en el codi binari d’una màquina real, sinó en el d’una màquina fictícia. Aquest
codi binari s’anomena bytecode.
Aquesta màquina s’emula amb l’ús d’un software especial anomenat maquina virtual de Java
(JVM = Java Virtual Machine). JVM agafa el codi binari del bytecode i l’interpreta, traduint en
temps d’execució al codi binari real del sistema sobre el que està treballant. Clar, és una
traducció en execució però amb l’ús d’un llenguatge ara de baix nivell, ja que el bytecode ja és
codi binari. EL JVM bàsicament formateja les instruccions del bytecode per fer-les compatibles
amb una màquina real, però no fa una traducció completa. Per tant, és molt portable, amb
l’única cosa de que l’ordinador de destí ha de tenir instal·lar una JVM.
Exemple: tenim un codi de funcionament java que “semicompilem” en un codi binari d’una
maquina virtual. Aquest resultat seria el mateix treballant amb Linux, Mac, Android o qualsevol
altre plataforma. Ara, aquest codi “semicompilat”, anomenat bytecode, el portem a una
plataforma com un smartphone amb Android que té una JVM instal·lada. Si llancem l’aplicació
el JVM agafarà el control i realitzarà la traducció final. Aquest resultat sí que serà diferent
depenent de la plataforma.
Tot això en el marc del concepte de maquina virtual. Bàsicament és un programa informàtic que
emula un ordinador o que permet executar programes com si fos un ordinador real. La màquina
virtual pot emular un ordinador real o fictici. Un tret essencial és que si la maquina virtual té uns
recursos concrets, com per exemple 1gb de ram, els programes executats només podran utilitzar
Tel. 977222231-601989689
aquest gb: res més, tot i que la màquina real tingui més memòria física. Un bon exemple de
màquina virtual és poder inicialitzar un sistema operatiu diferenciat per fer la prova. De
màquines virtuals en tenim de dos tipus: de sistema (SVM) i de procés (PVM).
- SVM: també coneguda com a màquina virtual de hardware, permeten a la màquina física
dividir-se en diverses maquines virtuals, cadascuna amb el seu propi sistema operatiu.
Entre els programes de virtualització tenim VMWare, VirtualBox d’Oracle i VirtualPC.
- PVM: també coneguda com a maquina virutal d’aplicació, s’executa com un procés
normal dins un sistema operatiu i suporta un sol procés. Es llança per dur a terme el
procés i al acabar finalitza. Bàsicament vol emular un procés sense que la plataforma
sigui un problema. La màquina virtual de Java és d’aquest tipus, emulant el hardware
necessari per executar l’aplicació independentment del hardware real, igual que
l’entorn .Net de Microsoft.
2.2 Eines per desenvolupar Java: el JDK.
El JDK (Java Development Kit) és un paquet de software que conté tot el necessari per
desenvolupar aplicacions escrites a Java, excepte un editor de text, que més tard analitzem. El
JDK inclou:
- La biblioteca de clases estándar de Java.

- La JVM o máquina virtual Java (java).
- El compilador de java (javac).
- Un desensamblador de clases (javap).
- Un depurador de consola (jdb).
- El generador automàtic de documentació (javadoc).
- Un visor de applets (appletviewer).
Tots els elements menys la biblioteca de classes és el que s’anomena JRE (Java Runtime
Enviroment). Bàsicament són els components necessaris per compilar i executar aplicacions
java. No obstant, per desenvolupar nous programes, necessitem a més a més la biblioteca de
classes. El JRE més la biblioteca de classes forma el que s’anomena JDK.
Un cop instal·lades (després de descarregar-ho des de la web oficial d’Oracle) a vegades cal
revisar el valor de dos variables d’entorn:
- Variable path, que ha d’apuntar al directori bin de JDK. Si no és així, no s’executarà.
Tel. 977222231-601989689
- Variable classpath: ha d’apuntar al directori arrel on estan les classes JDK (especialment
versions més antigues).
Per treballar amb java, podem utilitzar o bé editors de texts sense formatejar; o bé entorns
integrats de desenvolupament (IDE). Permet fer tota la tasca de manera molt més còmode i no
cal anar compilant i invocant comandaments JDK des de al consola. Per començar pot ser útil
evitar els IDE, que en qualsevol cas hi ha de molts tipus, pesats i lleugers, com Eclipse i NetBeans;
o Geany i BlueJ, respectivament.
2.3 Introducció a Java

2.3.1 Breu història
Cal tenir en compte que Java és un llenguatge de programació d’ordinadors. Va ser creat l’any
1991 per James Grosling, de Sun Microsystems, tot i que la primera versió no va aparèixer pel
públic fins al 1996.
Les primeres versions s’anomenen JDK 1.0, JDK 1.1, però després van passar a denominar-se
Java2 o j2, diferenciant tipologies de versions depenent dels components que incorporen i del
preu. Tindríem l’estàndard (SE = Standard Edition), l’empresarial (EE = Enterprise Edition, de
pagament) i la domèstica o portable (ME = Micro Edition). A partir de la versió JDK1.5,
denominada ja com a J2SE 5, es va deixar d’utilitzar la nomenclatura J2 i es parla simplement de
Java SE 6, Java SE 7, etcètera.
Al 2010, Oracle es va fusionar amb Microsystem i, per tant, avui dia Java és propietat d’Oracle,
tot i que la major part del codi té una llicència en obert GNU/GPL. La versió GNU Classpath, per
exemple, és una versió alternativa del JDK i és completament lliure. Java ha evolucionat i avui
dia és crucial perquè s’utilitza especialment per la creació d’aplicacions a Android, sistemes
tancats (smart tv, etcètera) o com a element vital en el marc del backend. Això sí, l’ús d’applets
(miniaplicacions web executable al navegador del client) ha quedat molt minvat. L´última versió
de Java és la número 17. Més endavant veurem quina és la ideal depenent de l’ús.
2.3.2 Trets principals de Java
Els trets més distintius de Java són:
- És un llenguatge de programació de propòsit general, concurrent i orientada a objectes

i basada en classes.
Tel. 977222231-601989689
- Va ser dissenyat per tenir poques dependències, és a dir, que fos el més portable
possible (concepte de WORA “write once, run anywhere”). Això és possible per la
compilació a bytecode i la seva traducció a binari des d’aquest.
- Allibera objectes no utilitzats de manera automàtica, gestionant la memòria de manera
eficient.
- És un dels llenguatges més populars a l’actualitat, especialment pel que hem comentat
del seu us en Android.
2.3.3 Estructura bàsica
L’estructura bàsica de Java és la següent:
public class Holamundo {

/* Programa holamundo */
public static void main(String[] args) {
// Este programa solo muestra un saludo por la pantalla
System.out.println(“Hola, mundo!”);
}
}
Què veiem aquí? Doncs bàsicament hem de destacar que Java és un llenguatge molt sensitiu i
exigent, perquè té molt en compte la sintaxis. En cas d’una errada (majúscula per minúscula, per
exemple), el programa directament no funciona. En el codi que tenim aquí, veiem que està
incrustat dins d’unes estructures anomenades classes. Aquestes classes han de tenir un nom, en
aquest cas Holamundo. Es poden també afegir comentaris com a qualsevol altre llenguatge y
dintre de les classes hi pot haver molts elements. Dins ha d’haver sempre un mètode (un bloc
de codi) amb el nom de main(). Aquest mètode és públic (es pot executar des de qualsevol lloc),
és estàtic (no cal instanciar la classe – ja veurem aquests conceptes) i no torna cap valor a qui
executa (void). És normal que al principi sigui molt confús. De fet, molts programadors sèniors
de Java encara tremolen quan veuen el codi java d’un altre desenvolupador.
Per poder executar aquest codi, cal tenir instal·lat el JDK i configurada les variables d’entorn.
Utilitzarem un IDE que pot ser ECLIPSE, per exemple. Primerament compilem l’arxiu
Holamundo.java i ens donarà un Holamundo.class, que és la traducció que arriba en bytecode.
Un cop compilat, toca executar-ho, i ens donarà el missatge Hola Mundo!.
2.4 Tipus de dades
Tel. 977222231-601989689
Les dades són representacions dels objectes del món real. Aquests objectes poden ser simples
(edat persona, número de treballadors d’una empresa...) o complexes (flota d’autobusos). És
important distingir entre simples i complexos perquè Java és molt sensitiu. Necessita saber
quina dada enmagatzemarà per reservar els recursos necessaris (principalment memòria RAM).
Per tipus de dada, per tant, entenem el domini en el que una determinada dada pot tenir un
valor. Per exemple, nombres enters significa que només pot contenir números sense decimals,
etcètera.
En aquet sentit, Java és un llenguatge tipat de tipus estàtic i fort. El tipat de tipus estàtic implica
que un cop que una variable és assignada (entenem variable com l’espai de memòria reservat
per guardar dades), no es pot canviar, al contrari que els llenguatges de tipat dinàmic, com
Javascript o Python. Així mateix, el tipat fort suposa que el llenguatge comprova exhaustivament
que les variables de cada tipus només s’utilitzen conforme al tipus que permet, al contrari que
els de tipat dèbil. Això fa que siguin més ineficients, perquè durant l’execució s’ha d’anar
comprovant variable per variable. A favor seu hi ha el fet de que són més robustos i tolerants a
errors.
2.4.1 Dades de tipus primitiu
A Java anomenem els tipus de dades simples com a tipus de dades primitives. Les classes són
primitives, tal i com veurem, però bàsicament serien els següents: números sencers, números
reals, caràcters i lògics.
- Números enters: -4, -3, -2, -1, 0, 1, 2, 3, 4... Bàsicament són els números sense decimals.
Sí que es cert que, com veurem, cada variable ocupa un espai físic en bits, de manera
que no podríem posar números molt molt grans. Hi ha una limitació concreta si
codifiquem en 8, 16, 32, 64, 128 o més. Aquestes limitacions són fàcils de trobar a
Internet.
o Els tipus enters primitius de Java són:
▪ byte, enter de 8 bits.
▪ short, enter de 16 bits.
▪ int, enter de 32 bits.
▪ long, enter de 64 bits.
- Números reals, que permet representar números amb decimals. Es representa amb el
concepte de flotant. Al igual que passa amb els enters, hi ha uns límits reservats pel
número situat en la posició decimal (mantissa) i el número del exponent.
o Els tipus primitius per manejar números reals a Java són:
Tel. 977222231-601989689
▪ float, coma flotant de 32 bits (1 bit reservat al signe, 8 al exponent, 24
mantissa.
▪ double, coma flotant de 64 bits (1 signe, 11 exponent, 52 mantissa).
Si quan fem càlculs el numero resultant és més gran que el que permet guardar la memòria,
estaríem davant un cas anomenat overflow o desbordament. A Java, la JVM proporciona un
error en temps d’execució.
- Caràcters i cadenes, que serveixen per representar dades alfanumèriques. Java ens
proporciona el tipus char, de 16 bits, per manejar caràcters. Els caràcters vàlids son les lletres
minúscules, les majúscules, els dígits i caràcters especials o d’altres idiomes tipus el símbol
del dolar, l’euro, la ç trencada... Per distingir un numero d’un caràcter numero utilitzem les
cometes. Es tracta de guardar només 1 caràcter. Les cadenes o string els veurem després
amb les dades complexes.
- Dades lògiques o booleans, és una dada que només pot tenir un valor entre dos possibles
(true o false). Java utilitza el tipus boolean per fer ús d’aquestes dades.
2.4.2 Conversions de tipus
Com que Java és un llenguatge fortament tipat, de manera uqe normalment hi ha problemes si
fem una conversió o mesclem dos tipus de dades. Tenim de dos tipus.
- Conversió implícita, que es fan de manera automàtica al barrejar dos tipus. Només és
possible si la variable receptora és més concreta i específica. Per exemple, podríem passar
un int a un long, però no al revés.
- Conversió explícita, també anomenat casting, suposa que el programador diu explícitament
que vol fer una conversió. Per exemple. Tenim un valor int anomenat x que val 5; i una dada
tipus byte que anomenem y. Si fem y = (byte)x; la variable entera es convertirà en byte.
2.4.3 Operacions amb dades
Les dades que poden participar d’una operació s’anomenen operands i el símbol de l’operació
operador. Bàsicament podem distingir entre operacions aritmètiques i operacions lògiques.
També tenim d’altres, com l’operador lògic XOR (^), l’operador complement a 1 o els operadors
de desplaçament de bits, no tan habituals.
2.4.4 Operacions aritmètiques
Tel. 977222231-601989689
Suma, resta, multiplicació, divisió i mòdul (resto) representats com + . - . *. / i % respectivament.
El mòdul serveix per calcular la quantitat restant de la divisió sencera. El tipus del resultat
dependrà del tipus d’operands. Si sumem dos enters, donarà enter; si sumem dos reals, donarà
real. La suma de diferents tipus no està permesa. Cal subratllar aquí que existeixen dos tipus
d’operadors aritmètics molt habituals:
- Operador d’increment (++). x++ equivaldria a x= x+1.

- Operador de decrement (--). x -- equivaldria a x = x-1.
2.4.5 Operadors lògics, que normalment donen true o false. Tenim dos tipus:
- Operador de relació: menor que, major que, igual que, menor o igual que, major o igual
que, i diferent que. El resultat serà vertader o fals. És fàcil trobar els símbols per internet.
- Operadors lògics, que serien and (y), escrit &&; i or (o), escrit | |.
2.4.6 Prioritat dels operadors
En el casos que hi ha diverses operacions juntes en una línia, hi ha operacions que tenen
prioritat. Aquesta prioritat respecta les regles generals d’àlgebra, podent-se alterar utilitzant
parèntesis. Normalment la divisió i multiplicació tenen prioritat sobre suma i resta; però hi ha
d’altres que depenen del llenguatge utilitzat. Aquí la llista de prioritat:
2.4.7 Operacions complexes
Les operacions que van més enllà de les ja vistes, requereixen de l’ús d’una classe de biblioteca
estàndard anomenada Math. Aquesta forma un mètode i cal passar els paràmetres que fan els
càlculs per a que doni un resultat concret. Això ja ho veurem més endavant. Aquí un quadre a
tall d’exemple:
Tel. 977222231-601989689
2.5 Constants i variables
Una dada constant és una dada d’un programa que té un valor que no canvia durant l’execució.
Pel contrari, una dada variable és una dada que sí que pot canviar al llarg del programa.
2.5.1 Identificadors de variables
A les constants i a les variables se’ls assigna un nom. Una variable anomenada edat pot contenir
el valor 25. L’identificador es edat i el valor de la variable és 25. Java és sensitiu i, per tant, té
normes estrictes. Les variables només poden començar per lletra i pel símbol (“_”) i a més no
poden coincidir amb paraules reservades com class o function. Per conveni, a més, les constants
s’escriuen en majúscula i les variables en minúscula, tot i que és una recomanació d’estil.
2.5.2 Declaració i assignació
Les variables, si són simples, han de ser dun tipus determinat. Declarar la variable a Java seria
una cosa així:
int x; double y; char z.
Entenem això com a declarar la variable. Després, li assignem un valor:
x = 5;
y = 7.5;
z = “M”.
Aquestes variables poden canviar, seguint sempre l’esquema de lectura de dalt a baix. Per
contra, les constants mai canvien. Per a poder dir que una variable és constant, cal posar el
modificador final abans de la declaració (que com hem vist normalment és en majúscula): final
ANYO = 2021.
2.5.3 El modificador static
Tel. 977222231-601989689
Moltes vegades veiem que a la declaració d’una variable s’utilitza la paraula static. Exemple:
static int x.
El modificador static significa que aquesta variable o constant només es crearan uan vegada en
tota l’execució del programa, tot i que es declara diversos cops. També s’aplica a mètodes. Més
endavant en treballarem el tema.
2.5.4 Vida i àmbit de les variables
Totes les variables son per definició locals al bloc que pertanyen (on han estat declarats). Un
bloc és tot allò que hi ha dins de les claus { }. Això vol dir que només viu en aquest bloc i es
destruirà quan finalitzi. Aquestes variables no poden ser modificades amb l’static. Les variables
que estan dins d’una classe sí que són accessibles i per tant poden ser declares com a static.
En aquest codi (no cal que s’entengui ara per ara!) veiem que dins la classe hi ha dos blocs de
codi anomenats mètodes: el main() i el otro_metodo(). Bàsicament veiem que la variable n, al
ser de classe, es pot usar dins els blocs sense problemes. No passa això amb les variables locals
m o r, que no poden utilitzar-se fora d’aquesta àmbit. Per això l’assignació fallarà.
2.5.5 Expressions
Una expressió és una combinació de constants, variables, operadors, mètodes i expressions

literals. Per exemple: (5+x) / 2. Aquí veiem dos constants literals ( 5 i 2), una variable (x) i dos
operadors. El càlcul d’això s’anomena avaluació de la expressió.
2.6 Programació estructurada a Java i el seu vincle amb la POO
Bàsicament, sense entrar a referir-nos gaire als orígens de la programació estructura, diem que
un programa és estructurat quan compleix tres característiques:
Tel. 977222231-601989689
- Té un ÚNIC punt d’inici i un ÚNIC punt de finalització.
- Existeixen almenys un camí que va de l’inici al final passant per tot el programa.
- No existeixen bucles infinits.
Aquesta teoria de la programació s’emmarca en una dinàmica de simplificació. Per tant, el

software estructurat ha de limitar-se al ús de tres estructures: la seqüencial, la selectiva o
condicional i la repetitiva.
La POO evoluciona d’aquest pensament de caràcter estructurat. Els algoritmes i les dades
queden dins les classes (encapsulats) i més tard es recorre (s’instancien) en objectes que
interactuen entre sí. Però el codi que tenim dins dels algoritmes funcionen com a programes
estructurats. És a dir, la POO és un superconjunt de la programació estructurada clàssica i per
això és vital controlar els elements habituals.
2.6.1 Estructura seqüencial
És la més simple de les tres. Bàsicament les instruccions s’executen una rere l’altre, al mateix
ordre que van ser escrites. A continuació un diagrama i un exemple amb Java:
2.6.2 Estructura selectiva o condicional
Tel. 977222231-601989689
Quan podem trencar la seqüencia perquè tenim condicions que ho fan possibles, parlem
realment d’una utilitat real quan dissenyem els programes. D’estructures selectives en tenim de
tres tipus: simples, dobles i múltiples.
2.6.2.1 Condicional simple
Bàsicament té aquest esquema:
if (condicion) {
acciones
}
La condició que apareix rere l’if és sempre una expressió lògica que té com a resultat un true o
un false. Si el resultat és true, llavors s’executen les accions situades entre els parèntesis. Si no,
es segueix el ritme descendent ignorant saltant-se les accions. Aquí un exemple de codi que
calcula l’àrea i el perímetre d’un rectangle:
Tel. 977222231-601989689
2.6.2.2 Condicional doble
La forma de la instrucció és la següent:
if (condicion) {
acciones-1
}
else {
acciones-2
}
Si él resulta és true, llavors s’executa el primer bloc, en cas contrari el segon (else). Aquí el mateix
exemple d’abans amb condicional doble:
Tel. 977222231-601989689
2.6.2.3 Condicional múltiple
Quan el resultat de les condicions no es queda emmarcat només en un true/false, sinó que tenim
més opcions, hem d’utilitzar aquest tipus de condicional, tot i que també podríem fer un if else
niuat constantment. L’exemple mostra un condicional de tipus switch:
switch (expresión) {
valor1: acciones-1;
break;
valor2: acciones-2;
break;
valor3: acciones-3;
break;
...
default: acciones-N;
}
Bàsicament, funciona primerament avaluant l’expressió, que no necessàriament ha de ser

lògica. El resultat de l’expressió es compara amb cadascun dels valors. Si coincideix, llença el
resultat d’aquesta i finalitza amb el break. Si no coincideix, arriba al default, una part que no és
obligatòria. Aquí un exemple d’algoritme que escriu el nom dels dies de la setmana en funció
del valor d’una variable entera anomenada “dia”:
Tel. 977222231-601989689
2.7 Estructura iterativa (bucles)
Inicialment, els ordinadors es van dissenyar per realitzar tasques senzilles i repetitives. La
repetició és una tasca que els ordinadors poden fer de manera constant i sense cap tipus
d’esforç. Aquestes repeticions reben el nom de bucles, loops o iteracions.
Per bucle entenem una estructura que repeteix un conjunt d’instruccions un número finit de
vegades. Cal evitar sempre el bucle infinit, perquè realment no té utilitat. Per evitar aquesta
infinitat, s’utilitzen condicions de sortida, elements que permeten sortir-ne del bucle. Per tant,
un bucle té dos parts: un cos o conjunt d’instruccions que s’executen repetidament; i una
condició de sortida per deixar de repetir instruccions i continuar amb el programa. En tenim de
tres tipus:
a. Bucle while: sortida al principi del bucle.

b. Bucle do... while: sortida al final del bucle.
c. Bucle for: sortida al principi amb un comptador automàtic.
2.7.1 El bucle de tipus while
És una estructura que es repeteix mentre la condició sigui true. La condició està al principi i
després apareixen les accions que es repeteixen (cos del bucle). Aquí un esquema:
Tel. 977222231-601989689
while (condición) {
acciones (cuerpo del bucle)
}
Bàsicament al arribar al bucle s’avalua si la condició és certa. Si és true, es realitzen les accions i
al acabar el bloc d’accions, es retorna a la instrucció while. Aquí es torna a avaluar la condició
fins que sigui false. A continuació afegim un exemple d’un algoritme que mostra per pantalla
tots els números enters del 1 al 100.
{
int cont = 0;
while (cont < 100) {
cont = cont + 1;
System.out.println(cont);
}
}
Aquí observem l’ús d’un comptador a la condició de sortida, un element molt habitual. Cada cop
va sumant 1, fins que arriba a 100 i acaba el bucle.
2.7.2 El bucle de tipus do... while
És molt similar a l’anterior, amb la diferencia que la condició de sortida s’avalua al final del bucle
i no al principi.
Tel. 977222231-601989689
do {
acciones (cuerpo del bucle)
}
while (condicion);
Quan s’arriba a aquest bucle, s’executen les accions entre parèntesis i després s’avalua la
condició, que ha de ser de tipus lògic. Si el resultat és false s’acaba el bucle, i si és true es continua
en el mateix. La gran diferència és que la condició s’avalua al final, de manera que les acciones
s’avaluen ALMENYS una vegada. Aquí un exemple d’un programa que escriu els números enters
(1 al 100) amb el bucle do... while.
{
int cont = 0;
do {
cont = cont + 1;
}
while (cont < 100);
}
2.7.3 El bucle de tipus for
Quan coneixem de primera mà el número de vegades que volem executar accions, s’utilitza el
bucle for. L’estructura del bucle repeteix les accions del bucle un número prefixat de vegades i
s’incrementa automàticament, utilitzant una variable comptador.
Tel. 977222231-601989689
for (inicialización; condición; incremento) {
acciones
}
El bucle 'for' el fem servir per repetir una o diverses instruccions un nombre determinat de
vegades. La seva estructura, és molt semblant a l'estructura del “while”, però més
simplificada. Entre parèntesis definim una expressió inicial que resulta la declaració d'una
variable “i” a la qual assignem un valor inicial “let i = 1”. A continuació, indiquem la condició que
s'ha de complir perquè el bucle segueixi executant-se, en aquest cas ' i <=3 , és a dir, el bucle es
repetirà sempre que ”i” sigui menor o igual que 3. Finalment, definim una expressió final que
anirà incrementant el valor de “i” en un ' i++ '.
Vegem com es comporta (recordeu que i++ equival a i = i + 1).Quan el nostre programa arribi a
la línia on és el bucle, ens trobem amb l' expressió inicial es declara la variable, “i” és igual a 0,
es comprova la condició ( i és menor que 3) → TRUE , aleshores s'executen les instruccions (en
aquest cas la instrucció) que es troben dins de les claus, en aquest exemple es mostrarà per
consola el valor de “i” que ara és igual a 0.
Un cop s'ha executat aquesta instrucció, el programa s'adreça a l' expressió final i se'n suma un
al valor de “i” ( ara i = 1 ). A continuació, s'avalua la condició , (i (1) és menor que 3) → TRUE i es
Tel. 977222231-601989689
torna a executar la instrucció que tenim entre les claus, en aquest cas es mostra per consola el
valor de la variable “i”, que ara és igual a 1.
Aquest procés es torna a repetir:
expressió final → sumem un a “i” → i = 2
condició → i (2) és menor que 3 → TRUE
en ser 'true' la condició s'executa el codi que tenim entre les claus
I de nou es torna a repetir el procés:
expressió final → sumem un a “i” → i = 3
condició → i (3) no és menor que 3 → FALSE
Ara la condició és 'false' i per tant, ja no es compleix la condició, ni s'executarà allò que tenim
entre les claus. El programa surt del bucle i segueix la resta d'instruccions.
A continuació afegim el mateix algoritme dels números enters, modificant “i” per cont, en el
marc del codi de Java:
{
int cont;
for (cont = 1; cont <= 100; cont = cont + 1) {
}
}
2.8 Entrada i sortida a Java
Deixant ja els bucles, és important destacar aquí com podem manejar l’entrada de dades per
teclat i la sortida de dades per consola. Tot això mitjançant la classe System. Aquesta classe està
al paquet java.lang.System, que sap carregar automàticament les aplicacions. La classe System
conté a més a més tres objectes static que es creen automàticament al executar qualsevol
programa de Java i que es destrueixen sols al acabar. Aquets són:
3 System.out, per manejar sortides estàndard (consola).

4 System.in, per manejar l’entrada estàndard (teclat).
5 System.err, per manejar sortida d’errors.
Pel que fa al System.out ja hem vist com funciona. Quant al System.in, aquí un exemple:
Tel. 977222231-601989689
Aquest exemple sembla molt complicat però bàsicament estem davant d’un maneig
d’excepcions: si passa alguna cosa inesperada al llegir un caràcter (com posar-ne 20), el
programa és capaç de detectar-lo i reaccionar adequadament. Això és el bloc try-catch.
Per fer entrada per teclat tenim tres formes diferents:
La tercera forma és la més fiable, a la que hauríem de posar un try-catch per si dona errors:
En aquest punt, no cal amoïnar-se gaire pel codi i per la seva complexitat. És un procés
acumulatiu!
3. Identificació dels fonaments de la programació orientada a objectes
Cal iniciar-se a la programació orientada a objectes des del principi a la vida del programador,
perquè molts manuals ensenyen aquest paradigma molt posteriorment, ensenyant com si fos
programació estructurada i després fer el salt. Això suposa tornar a repensar la feina què cal fer,
de manera que nosaltres introduirem aquí mateix tot aquest paradigma.
Tel. 977222231-601989689
3.1 Definició. Pensament orientat a objectes.
Per definir què fa que Java sigui un llenguatge de programació orientat a objectes (POO), cal
reflexionar primerament sobre què és POO, i després fixar-nos en que no és. Pel que fa a la
primera qüestió, normalment quan pensem en POO el conceptualitzem com un paradigma, una
tècnica pel desenvolupament de software, un model o patró per a la programació, i que és
utilitzat per molts llenguatges de programació. En qualsevol cas, cal fixar-se en que no és. La
programació tradicional resolia qualsevol problema informàtic codificant un conjunt
d’algoritmes que treballaven sobre unes dades. Les dades actuen com a elements passius, sent
el codi el veritable protagonista. El principal problema radica que en estructures molt grans de
codi és molt difícil localitzar errors. La POO canvia dràsticament aquesta forma de treballar. No
és una revolució, sinó un canvi en la forma en que es fan les mateixes coses de sempre. Tota la
feina recau bàsicament en les dades, de manera que es converteixen en elements dinàmics i no
estàtics.
La idea es fer de la variable no només una caixa amb una tapa a la que podem llençar coses dins;
sinó que la veurem com autèntiques màquines funcionals tancades amb pocs interruptors. No
volem tornar a pensar en com funciona cadascuna d’aquestes maquines.
Un exemple: el forn. El forn consta d’un temporitzador. Si volem traslladar aquesta idea a Java,
diríem que el temporitzador podria ser una variable numèrica de tipus float o double. El
programa manipularia aquesta variable disminuint el valor una vegada per segon i permetria a
l’usuari establir el temps inicial del temporitzador. Amb aquest paradigma, qualsevol error
podria donar un valor fals i, per tant, les possibilitats de fallar són moltes.
En el cas de la POO, el programador haurà de deciar temps pensant en què és exactament un

temporitzador i com s’espera que el món exterior interactuï amb ell. Al final, crearà una petita
maquina (una peça de software) amb controls que permeten establir, consultar i disminuir el
seu valor. No es tracta d’assignar valors arbitraris, sinó fixar-se que, per exemple, només permet
múltiples de 10. De manera que mai ningú podria donar-li un valor negatiu, per exemple. Aquest
objecte estaria “protegit” d’aquesta manera d’errors. A més, la POO permetrà crear un patró o
model del temporitzador. A partir d’aquest motlle, es poden construir objectes diferents (però
similars) de manera indefinida.
Per tant, el motlle o patró es coneix com a classe; i cada temporitzador concret que fabriquem
a partir del mateix es coneix com a objecte.
Tel. 977222231-601989689
Així mateix, convé apropar-se i entendre molt bé quatre conceptes de programació, que ens
ajudaran a comprendre millor els motius i les característiques del POO.
1 Abstracció, que és un procés mental pel qual ignores (o t’abstreus) de les complexitats dels
elements que t’envolten. Exemple: encendre la TV, no pensem com funciona realment ni
quins sistemes estan implicats, només l’encenem (un tècnic de TV ho veuria diferent).
2 Encapsulació, que és un procés pel qual s’amaguen els detalls del suport de les
característiques d’una abstracció. Exemple: et demanen el CIF per a una factura, però no li
ensenyes el paperet oficial on surt. Es subministra la informació, però s’amaga on es troba.
No és un procés automàtic: és una elecció.
3 Modularització, que és el procés de descomposició d’un sistema en mòduls poc acoblats i
cohesius. Exemple: un sistema com a organització amb una fita comuna, com el govern de
la nació. El ministre no està acoblat als funcionaris: treballen de manera conjunta, però la
falta d’un no suposa gaire (poc acopats).
4 Jerarquització, que és el procés pel qual es produeix una organització en nivells: composició,
classificació...
L’augment de l’ús d’aquests conceptes en programació produeix un codi menys complexa,

llegible, comprensible, més flexible, escalable, amb menor manteniment i, per tant, molt més
barat.
Certament, el POO intenta emular les característiques del món real, implementant un sistema
d’elements que modelitzen aquelles coses que veiem en el dia a dia. Aquests elements treballen
i col·laboren entre sí per portar a terme l’objectiu dels nostres programes: classe, objecte,
atribut, mètode, estat, missatge...
3.2 Mètodes i atributs
Els interruptors que dèiem són els coneguts com a mètodes. Al POO són els propis objectes els
que decideixen com s’ha d’operar amb ells: no es poden manipular les dades directament des
de l’exterior. Es passa un missatge al objecte i aquest missatge provoca algun tipus d’acció o
resposta significativa per part de l’objecte, però tampoc ens importa com realitza la seva feina
interior.
Les tasques que podem demanar que un objecte faci (els missatges que compren) són els
mètodes.
Així, les arrays i els strings, per exemple, són objectes que saben exactament el que han de fer
si els demanem que calculin la seva pròpia longitud (lenght):
Tel. 977222231-601989689
Aquest autoconeixement de les peces de dades a Java allibera al programa de la carrega de
memoritzar una gran quantitat de noms de funcions. Com que tenim poques funcions, aquestes
es poden aplicar a diferents tipus de dades tenint un resultat esperable. Aquesta característica
del POO és el que anomenem polimorfisme.
Si un objecte rep un missatge que no coneix, es produeix un error. Els mètodes són com els dials
del forn: com a usuari, has de saber quins dials existeixen i com utilitzar-los; però no com estan
construïts per dins.
Els atributs defineixen les característiques d’un objectes. El programador s’encarrega d’utilitzar
els objectes a través del seus mètodes i aquests operen amb els atributs. Per tant, no cal que el
programador sàpiga quins atributs te l’objecte.
3.3 Definicions de caràcter formal
Objectes
És una unitat que engloba dins de sí un conjunt de dades i les funcions necessàries per el
tractament d’aquestes dades. Podríem dir que és un exemplar, una unitat d’un element amb les
característiques definides a una classe (procés que es coneix com a instanciar). Es caracteritza
per:
5 La seva identitat. Cada objecte és únic i diferent a la resta. Internament té un ID per

diferenciar-lo dels altres objectes, tot i pertànyer a la mateixa classe.
6 El seu estat: l’estat de l’objecte depèn del valor dels seus atributs o variables internes.
7 El seu comportament, que es defineix mitjançant els mètodes o fragments de codi que
operen amb els atributs interns del objecte i interactuen, si es necessari, amb d’altres
objectes.
En el cas d’objectes cotxe doncs tindríem Mini del 1978, benzina, vermell, 3 portes... Seria igual
que el BMW sèrie 3 en que responen a les mateixes operacions: arrencar, frenar, accelerar...
Atributs
Tel. 977222231-601989689
Són les dades incloses al objecte. Són com les variables dels llenguatges de programació
habituals, però estan encapsulades dins d’un objecte i en principi són invisibles al exterior. Per
tant, entenem atributs com una dada dins una classe. Són les dades descrites a la classe. En
aquest sentit, tots els objectes d’una mateixa classe tenen tots els atributs definits. Aquests
pdoen ser constants o variables: un cotxe té 4 rodes, però diferents colors.
Estat
Són els valors que tenen els atributs en un moment concret. Els valors poden canviar al llarg del
temps. Poden tenir diferents estats al llarg de la vida del objecte.
Mètodes
Són les funcions que pertanyen a un objecte: els fragments de codi amb un nom que permet
invocar-los i executar-os, però estan encapsulats dins l’objecte. Tenen accés als atributs i són la
forma d’operar amb els atributs des de l’exterior de l’objecte. Són els dials, al final. Per tant, és
la definició d’una operació d’una classe. Es declaren dins el codi de la pròpia classe. Així, el
mètode té el codi que ha d’executar-se quan li passen un missatge. És una funció que diu quines
operacions han de produir-se quan em demanen que faci alguna cosa.
Classes
És un patró per construir objectes: una definició de les dades i funcionalitats d’elements d’un
tipus. Un objecte és una variable que pertany a una classe determinada. La classe simplement
és una declaració, no té associat cap objecte, mentre que l’objecte ha de pertànyer a una classe.
Un exemple podria ser la classe cotxe: les dades serien el model, l’any de fabricació, la
cilindrada... Mentre que les funcionalitats serien arrencar, accelerar, frenar...
Missatges
La manera en que es comuniquen els objectes entre sí. Un missatge no és més que una trucada
a un mètode d’un determinat objecte. Quan truquem a un mètode d’un objecte, direm que
estem enviant un missatge a aquest objecte, i l’objecte reaccionarà executant el codi associat a
aquest missatge. Per tant, podríem dir que és una invocació a la funcionalitat d’un objecte.
“Llancem missatges” per demanar als objectes que facin coses per nosaltres. A un objecte cotxe
li llanço el missatge: “accelera”.
Interfície
Tel. 977222231-601989689
Les classes (i per tant també els objectes) tenen parts publiques i parts privades. La part pública
és visible per a la resta ‘d’objectes, no així la part privada que només pot visualitzar-se pel propi
objecte. A la part pública d’un objecte se’n diu interfície.
3.4 Trets de la POO
Entre els trets principals, tenim:
1 Abstracció: s’intenten abstraure les característiques dels objectes del problema que hem
d’informatitzar, per crear a partir d’aquest les classes i mètodes.
2 Encapsulament, que fa referencia al fet de que cada objecte es comporta de manera
autònoma, de manera que el que passa al seu interior és invisible pel resta d’objectes.
3 Herència, que fa referencia al fet de dissenyar noves classes basant-se en classes ja existents.
Quan una classe hereta d’un altre, agafa tots els atributs i tots els mètodes de la classe
“mare” i pot afegir els seus propis.
4 Polimorfisme, es refereix a la possibilitat de crear diverses versions del mateix mètode, de
manera que es comportin diferent en base al estat del objecte o dels paràmetres d’entrada.
Els principals avantatges són:
1 Modularitat: el codi d’un objecte es pot modificar, mantenir-se o millorar-se sense que afecti
a la totalitat del sistema. La resta d’objectes seguiran comunicant-se amb l’objecte modificat
sense que sàpiguen que aquest ha canviat.
2 Reutilització de codi: és molt senzill utilitzar classes i objectes de terceres parts. Igual que
un tècnic d’una rentadora canvia una peça electrònica per un altre sense saber exactament
com estan fetes.
3 Facilitat de prova i manteniment, si alguna cosa falla és fàcil aïllar l’element problemàtic
sense que afecti a tot el sistema.
4 Ocultació d’informació, ja que com cada objecte amaga els detalls d’implantació ala resta,
és difícil que un mal funcionament d’una determinada part afecti al sistema.
3.5 Declaració de classes i objectes a Java
Per a crear un objecte i començar a utilitzar-lo, és necessari que abans existeix una classe (el
motlle). A Java, la forma més simple de declarar una classe és aquesta:
class MiClase {
private static int miAtributo1;
private float miAtributo2;
Tel. 977222231-601989689
public void miMetodo1() {
<codi del mètode>
}
public int miMetodo2(int a, b) {
int r;
<codi del mètode>
return r;
}
}
A l’exemple, hem declarar una classe que es diu “MiClase” i que hem desat en un arxiu anomenat
MiClase.java. La classe té dos atributs: miAtributo1 (int) i miAtributo2 (float). Els dos són private
i per tant no es pot accedir des de fora (és l’ideal en el cas dels atributs). I un d’ells és statics:
només es crearà una vegada tot i que es defineixen diversos objectes d’aquesta classe. Després
tenim dos mètodes, un que no torna res i que és públic; i un que també és públic i torna el valor
d’una int anomenada r.
Això és un patró, un motlle, una plantilla. Si volem crear objectes des d’aquesta classe hem de
fer servir la següent forma:
MiClase miObjecto = newMiClase;
Des de llavors, existirà una variable en el programa anomenat miObjeto i en el seu interior
contindrà tots els elements de miClase: els atributs i els mètodes. Podem crear tots els objectes
que vulguem a partir d’aquest patró o motlle.
A continuació, un cas més realista. Volem desenvolupar una aplicació per administrar dades
personals i acadèmiques del alumnat d’un institut. L’objecte persona té certes característiques
com nom, edat, sexe, i es pot operar amb ell: assignació de nom, preguntar-li quina edat té...
Aquests trets són els atributs i les operacions els mètodes.
Aquí com seria la classe persona:
Tel. 977222231-601989689
Els atributs són privats i hem definit un mètode públic per consultar i modificar cadascun d’ells.
Un exemple de com podríem utilitzar aquesta classe per crear una persona seria aquest:
Tel. 977222231-601989689
És interessant veure que tot i que l’emmagatzematge del sexe és amb el caràcter H, al recuperar-
lo utilitzant getsexo(), ens torna l’string masculino. Aquest és el comportament del objecte i com
a usuaris no ens importa el procediment intern.
Important: per utilitzar la classe Persona des de la classe probarPersona no cal fer imports ni res:
només han de conviure en el mateix directori.
3.6 Més sobre mètodes: els paràmetres
Els mètodes poden rebre una sèrie de valors anomenats paràmetres. A la declaració del mètode,
cal indicar el tipus de cada paràmetre
Així mateix, convé assenyalar l’existència de sentències com el retorn en alguns mètodes.
Bàsicament vol dir que el mètode retorna al usuari un resultat. El mètode getEdad() no va
precedit de void (que no torni res), sinó del tipus: públic int getEdad...
També poden estar precedits per la paraula static: de la classe amb static davant només es
crearà una sola instància d’aquest mètode o atribut. Això vol dir, bàsicament, que cada objecte
Persona, al ser invocat, l’atribut numPersonas s’anirà incrementant. Si no fos un atribut static,
cada objecte Persona tindria el seu propi atribut a 0 en el moment de la creació.
Valors tornats
Alguns mètodes terminen amb la seqüencia return. Bàsicament això vol dir que retornen un
resultat. És per això que molts mètodes utilitzen la paraula void (buit), perquè no retornen. Si
en canvi retornen, tindríem un model com aquest exemple:
Mètodes i atributs estàtics
Tel. 977222231-601989689
Alguns mètodes, com també alguns atributs, poden estar precedits per la paraula static. Això vol
dir que només es crearà una vegada, i que seria compartir per 800 objectes del tipus Vehicle,
per posar un exemple.
3.7 Una primera visió dels constructors
A Java existeixen dos mètodes especials anomenats constructors i destructors d’objectes, que
després analitzem amb més profunditat però que requereixen ja d’una petita introducció. De
fet, no és obligatori programar constructors a cada classe, però sí que apareixen amb molta
freqüència.
El constructor és un mètode que és invocat automàticament al crear un objecte de la classe. La

seva funció sol ser la de inicialitzar l’estat del objecte. Entre els trets principals tenim:
- El nom del constructor ha de coincidir amb el de la classe.

- S’han d’utilitzar per inicialitzar amb valors buits tots els atributs de la classe.
- No tornen res ni s’indica la seva visibilitat.
- Podem parametritzar-se, creant dos vies d’accés: un amb paràmetres i un altre sense ells
Aquí un exemple:
3.8 Nivells d’accés als membres d’una classe
A Java trobem diversos nivells d’accés als membres d’una classe (els membres són tan els
atributs com els mètodes d’una classe):
Tel. 977222231-601989689
- Públic (public). Es pot accedir des de qualsevol altre classe de l’aplicació.
- Privat (private). No es pot accedir des d’un altre classe.
- Protegit (protected). No es pot accedir excepte si pertanyen al mateix paquet i subclasse.
- No especificat. Si no s’especifica només podran accedir al membre de la classe les classes
del mateix paquet, però no les subclasses.
Cada cop que es declara un membre d’una classe (atribut o mètode), cal indicar el nivell d’accés.
No especificar el nivell d’accés també és una forma vàlida. Aquí un exemple amb atributs privats
i mètode públic:
El conjunt de membres d’una classe declarats com a públics i protegits constitueixen una
interfície, és a dir, la part que es mostra a la resta de l’aplicació. Qualsevol modificació interna
de la classe no hauria d’afectar mai a una interfície, de manera que el funcionament de la resta
de l’aplicació no es veurà alterat degut al fet d’haver d’alterar una línia de codi d’una de les
classes.
Nivells d’accés a una classe
També podem controlar el nivell d’accés a una classe, declarant-la com a pública o com a privada
en la seva totalitat. La privada només la podran utilitzar altres classes del seu propi paquet. En
el cas de públic, posem “public” al davant de tot; en el cas d’una privada amb apertura al paquet,
no posem res; i en el cas d’una classe totalment privada fins i tot respecte a d’altres classes,
posem “private”.
3.9 Els objectes this i super
La paraula this és una paraula reservada de Java. Això vol dir que no pots fer-la servir com a
identificador de variable, constant, mètode o classe. I és una paraula reservada perquè l'objecte
this fa referència al propi objecte que executa el codi. És a dir, si tenim una classe nauEspacial i
instanciem cinc objectes d'aquesta classe, tindrem al nostre programa cinc naus espacials,
cadascuna amb els seus atributs i mètodes. Doncs bé, referir-nos a this dins del codi de la classe
és referir-nos al objecte concret, a una de les cinc naus espacials. L'objecte this es pot fer servir
per accedir als atributs i als mètodes del mateix objecte, però gairebé sempre s'omet per
Tel. 977222231-601989689
estalviar codi. En canvi, algunes vegades és necessari fer-lo servir per evitar ambigüitats. Aquí
un exemple:
L'objecte super és semblant a this, però no es refereix a l'objecte actual, sinó a la superclasse o
classe mare del objecte. Veurem més sobre superclasses, classes mare i herència més endavant.
3.10 La classe Object
La classe Object és l’arrel de les jerarquies de classes a Java. Això vol dir que totes les classes
creades a Java són, en realitat, una subclasse d’Object, heretant els seus atributs i els seus
mètodes. Per herència, un concepte que després analitzem, entenem bàsicament el fet de que
una classe filla hereta els atributs i mètodes de la mare, disposant d’ells sense necessitat de
tornar-los a escriure. La classe Objet disposa de mètodes que comparteix amb totes les classes:
- Mètode clone(), per clonar o fer una copia d’un objecte. La seva particularitat és que
l’original i el clonat fan referència a la mateixa zona de memòria, el que s’anomena còpia
superficial, de manera que canvis en aquesta afecten als dos.
nau1 = new NauEspacial();

nau2 = (NauEspacial)n1.clone();
- El mètode equals(), per comparar dos objectes. Fa una comparació superficial, mirant si els
dos objectes comparteixen la mateixa zona de memòria.
nau1 = new NauEspacial();

nau2 = (NauEspacial)n1.clone();
if (nau1.equals(nau2))
System.out.printLn(“nau1 i nau2 són iguals segons equals()”);
Tel. 977222231-601989689
- toString(), que torna el nom de la classe. Bàsicament torna el nom de la classe i la direcció
de memòria, expressada en hexadecimal.
- El mètode finalize(), per esborrar un objecte, alliberant aquest espai de memòria.
Normalment és invocat automàticament pel recol·lector de brossa de la JVM. Més endavant,
quan parlem dels destructors, tornem sobre el tema.
3.11 Atributs de classe i variables globals
A Java no existeixen les variables globals, aquelles que estan disponible en tot el codi de
l’aplicació. En d’altres llenguatges de programació, pot resultar útil, però és una forma de fer
molt tendent als errors. L’element més proper en el cas de Java són els atributs de classe o
atributs static. Es declara abans de crear (instanciar) un objecte d’aquesta classe. L’atribut static
es crea i es guarda dins la variable. Després, al crear un altre objecte de la mateixa classe,
l’atribut es comparteix, en canvi la resta d’atributs no es comparteixen, es creen de nous.
Aquests atributs “normals”, els no static, es denominen atributs d’instància.
L’atribut naves és static. Es tracta d’un comptador de quants objectes naveEspacial hem creat.
En aquest cas, s’incrementa en un cada vegada que es crea una nau i com que es compartir per
totes les naus, anirà acumulant el numero d’objectes creats.
L’atribut vidas, en canvi, és normal. És un atribut d’instància, i per tant quan es crea un objecte,
aquest atribut es crea de nou i, per tant, el comptador es reinicia.
3.12 Mètodes de classe
En el cas dels mètodes passa exactament igual. El mètode de classe o mètodes static són
compartits per tota la classe, existint tot i que no s’hagi creat cap objecte de classe. Aquests
mètodes tenen dos limitacions bastant lògiques: no poden accedir a this i no poden accedir als
Tel. 977222231-601989689
membres de l’instància (només poden accedir a d’altres membres static). Ara entenem millor el
“public static void main()”: l’static fa referència precisament a que es pot executar sense
necessitat d’instanciar un objecte de la classe que el conté. El programa comença precisament
aquí, d’aquí que no sigui necessari instanciar l’objecte. Normalment els mètodes static s’utilitzen
en una classe que no té variables, ja que no té sentit instanciar objectes perquè tots seran
idèntics els uns dels altres.
3.13 El pas de paràmetres: valors o referències
Per passar paràmetres tenim dos formes:
- Per valor, que es la forma més senzilla però no permet tornar resultats en els paràmetres.
- Per referència, molt més complex però que permet tornar resultats en els paràmetres dels
mètodes.
Pas de paràmetres per valor.
Els mètodes poden tenir una sèrie de paràmetres a la seva declaració. Aquests paràmetres reben
el nom de paràmetres formals, que es el que veiem en el primer exemple:
El segon, per la seva banda, mostra una invocació de mètode, passant-li entre parèntesis els
valors dels paràmetres. Se’ls denomina paràmetres actuals. Al invocar el mètode, els paràmetres
actuals són assignats als paràmetres formals en el mateix ordre en el que foren escrits. Dins el
mètode, els paràmetres s’utilitzen com a variables convencionals. Això sí: un cop s’acaba
l’execució, només romandrà “viu” la variable que torna el resultat, en el cas de l’exemple la
variable c.
Pas de paràmetres per referència
Tel. 977222231-601989689
A Java el pas per referència no existeix. Això sí, quan l’argument és un objecte en comptes d’un
tipus primitiu, el que es passa per valor és la seva referència, és a dir, la posició que ocupa a la
memòria i, per tant, podem accedir al interior del objecte i modificar el seu contingut des del
mètode. Aquí un exemple en el que veiem que cambiarNombre() ha creat un nou objecte
persona i se li ha assignat a p. La cosa és que el valor p de main() no es veu afectat, d’aquí que
realment no estiguem passant paràmetres per referència sinó per valor.
3.14 Constructors i destructors
Ja vam veure una visió molt introductòria dels constructors, aquells mètodes que es diuen igual
que la classe i que s’executen automàticament al crear un objecte d’aquesta classe i que
normalment s’utilitzen per assignar un valor inicial al estat de la mateixa (és a dir, a les seves
variables membre). A continuació introduïm algunes particularitats:
1 No poden ser static. Els mètodes static s’executen sense crear un objecte, i en aquest cas
precisament s’utilitza per crear-ne. Bàsicament no pot portar cap modificador.
2 Normalment són public, perquè si fossin private no es podrien crear objectes des de fora de
la classe.
3 Si no es defineix cap, Java executarà el constructor per defecte, que està heretant de la
classe Object i assigna valors per defecte a les variables membre. Els valors numèrics per
Tel. 977222231-601989689
defecte són 0, NUL per caràcters, cadenes buides per Strings i valor Null per la resta
d’objectes.
4 Poden sobrecarregar-se, ja que un constructor pot acceptar paràmetres i d’altres no.
A nivell d’assignació, els de tipus simple (primitius) bàsicament funciona com a còpia del valor
d’una variable a un altre; mentre que en el cas els objectes el que es fa és una copia de la
referència d’un objecte al altre. Si la dada en qüestió ocupa 32 bits, la nova dada ocuparà uns
altres 32 bits. No passa això en el cas dels objectes, ja que quan assignem un objecte a un altre
no es copien els seus valors, sinó que se li assigna la direcció de memòria d’un objecte a un altre.
Si fem p2=p, la direcció de memòria de p2 es perden per sempre i es converteix en p. De manera
que si modifiquem p2, modificarem també la p.
En el cas de que vulguem fer còpies, és a dir, que vulguem que es comportin igual que les
variables simples, utilitzem un constructor especial que anomenem constructors còpia. Aquí un
exemple on veiem que, tot i compartir els atributs, al final es poden modificar, de manera que
estaríem davant de còpies i p1 i p2 no serien el mateix objecte.
Pel que fa als destructors, cal dir que a Java no existeixen. Bàsicament fan referència a un
concepte de POO que consisteix en alliberar memòria d’aquells processos o objectes que
deixaran d’existir. La part positiva és que a Java aquet procés és automàtic, no com altres
llenguatges de programació tipus C++. Aquest mecanisme automàtic se’l coneix com a
recol·lector de brossa (garbage collector, o gc), que s’encarrega d’anar alliberant els recursos
Tel. 977222231-601989689
que ocupaven els objectes que ja no existeixen. A Java existeix, de totes maneres, un
“pseudodestructor”, que és el mètode finalize(), però que no cal endinsar-nos perquè no és bona
pràctica.
3.15 Interfícies
Una interfície és una classe sense codi. És a dir, una classe amb atributs i les definicions dels seus
mètodes, però sense codi dins d’ells. En sí mateixa, no serveix per a res. La seva utilitat és servir
de patró o motlle per formar altres classes que sí implementaran codi. Per exemple:
Si observem l’exemple veurem que les classes rectangle i cercle implementen els dos mètodes
de la interfície: area() i perimetro(). Aquestes interfícies el que fan és forçar a que totes les
classes similars obeeixin a una interfície comuna: obliga a totes les classes rectangle, cercle i
qualsevol altre similar, a seguir el mateix patró i a no canviar-lo. De fet, el principi d’encapsulació
Tel. 977222231-601989689
funciona així: ningú pot accedir a veure el funcionament intern d’una classe, però sí que es pot
accedir mitjançant la seva interfície.
3.16 Classes i mètodes abstractes
Les classes abstractes són classes genèriques. És a dir, no es poden crear objectes d’aquesta
classe (no es pot instanciar). S’utilitzen per crear classes derivades a partir d’elles. Un bon
exemple seria la classe Vehicle, que seria una classe abstracta en el marc d’una jerarquització.
D’aquesta deriven classes més concretes com Moto, Furgoneta o Camió, i aquestes últimes sí
que poden instanciar objectes. Per tant, s’utilitzen per representar correctament jerarquies
entre objectes del món real i permeten reutilitzar gran quantitat de codi de forma comprensible.
Les seves característiques són:
1 No poden instanciar-se (crear objectes).

2 Poden tenir mètodes abstractes i no abstractes. Els primers han de ser implementats
forçosament pels fills, excepte que també siguin classes abstractes i els segueixen declarant
com abstracte. Els segons son heretats pels fills com qualsevol altra herència, de manera
que poden o no ser redefinits.
3 Si una classe té un mètode abstracta, serà classe abstracta.
4 Els mètodes abstractes no poden ser static.
Aquí un exemple de com es declaren:
3.17 Objectes, classes i mètodes finals
Un objecte final fa que sigui impossible que un altre objecte tingui la mateixa referencia. Aquests
s’utilitzen amb propòsits de seguretat (per prevenir modificacions accidentals al estat d’un
objecte) i per eficiència (al existir només una instància, la JVM el col·locarà a la memòria RAM
directament i tractar-ho serà un procés ràpid.
Tel. 977222231-601989689
Així mateix, els mètodes finals són aquells que no es poden modificar mai. És a dir, si altre classe
els hereta, no els podrà modificar, perquè la idea és que mai sigui alterat. També es fa per motius
de seguretat i eficiència, fent previsió d’una possible mala praxis posterior per part del
programador. Per últim, les classes finals són aquelles que no poden tenir descendència.
Diferència entre interfícies i classes abstractes
Ambdós elements serveixen per forçar una interfície comuna a totes les classes que hereten
d’ella (en el cas de les classes abstractes) o que les implementen (cas de les interfícies). Quan
hem d’utilitzar un o un altre?
- Les classes abstractes són classes, tot i no poder instanciar-se. Per tant, poden tenir codi en
alguns dels seus mètodes; no així les interfícies.
- Qualsevol que hereti ha d’implementar mètodes forçament en el cas de les classes
abstractes. És a dir, si Vehicle és una classe abstracta, totes les classes derivades han de ser
vehicles. Això no passa a les interfícies. La interfície només defineix un conjunt de mètodes
comuns que després poden ser implementats en una gran varietat de classes. Un exemple
és la interfície Drawable que té el mètode draw(), que serveix per representar gràficament
per pantalla. Vehicles o figures geomètriques podrien participar d’aqueta interfície tot i no
tenir res a veure.
- També una classe pot implementar diverses interfícies a la vegada, camuflant una herència
múltiple, temes que veure més endavant.
3.18 Els paquets de Java
Un paquet o Package és un conjunt de classes relacionades entre sí empaquetades en un arxiu.

Al JDK en tenim molts paquets estàndard que s’utilitzen contínuament. Un paquet de Java és el
que es denomina en d’altres llenguatges una llibreria o biblioteca. L’ús de paquets permet
agrupar les classes relacionades en un sol lloc, evitant possibles conflictes amb el nombre de
classes i mètodes que es repeteixen.
Per a utilitzar un paquet, cal utilitzar la sentència import: import java.lang.system; import
java.lang, per exemple. És vital fer que el compilador de Java necessiti saber on estan els arxius
de la biblioteca de classes, d’aquí que s’hagi de configurar molt bé tot el tema del CLASSPATH.
Tel. 977222231-601989689
3.19 Maneig d’excepcions
El control d’excepcions permet al programar evitar que el programa falli durant l’execució de
forma inesperada. La qüestió no és que falli, al final és que no s’aturi de cop. El concepte de
maneig d’excepcions consisteix en preveure i capturar els possibles errors d’execució per a
redirigir-los a una rutina de codi, de manera que el programa pugui recuperar-se del error.
S’utilitza especialment en llocs sensibles d’execució, com entrada de dades d’usuari o
operacions aritmètiques amb valors que no es poden preveure. Bàsicament s’utilitza novament
el bloc try-catch:
try {
<sentencias que pueden fallar>
}
catch (excepcion-1) {
<control de la excepción 1>
}
catch (excepcion-1) {
<control de la excepción 2>
}.
..
finally {
<control final>
A continuació un exemple amb maneig d’excepcions i sense, incloent l’error que apareix.
Bàsicament tot es deu al fet de que es divideix 10 entre 0.
Tel. 977222231-601989689
Amb l’ús del try catch, l’error es redirigit, de manera que el nostre codi agafa el control de la
situació i tracta de tractar-ho de manera que el programa pugui seguir executant. Aquest tipus
de maneig d’excepcions els utilitzarem molt més endavant, però convé saber que existeix
aquesta possibilitat.
Així mateix, convé assenyalar que el maneig d’excepcions el trobaràs habitual en el moment en
el que l’usuari hagi d’entrar dades pel teclat. L’usuari pot escriure qualsevol cosa, d’aquí aquesta
necessitat que ja hem comentat anterior. Aquí veiem un exemple d’una classe que demana dos
números per teclat i els suma:
Tel. 977222231-601989689
En aquest cas s’ha volgut redireccionar les entrades de dades que han de convertir-se de String
a números enters. Com és probable que l’error d’aquest codi sigui en aquest moment, podem
capturar aquest aquest error d’execució i tractar-ho amb el nostre propi codi, en comptes de
que la JVM s’encarregui i imprimeixi errors tan preocupants a l’usuari final. Quant al mètode
printStackTrace() és utilitzat pels desenvolupadors per veure l’error a l’hora de depurar el
programa, però a la versió final ha de desaparèixer per evitar que arribin aquests missatges al
usuari final.
4. Distinció dels entorns, fases i eines necessàries per realitzar projectes Java i web.
Un equip de desenvolupadors de Java, com a norma general, ha de seguir una seqüència

d’activitats per tal d’assolir uns objectius i aconseguir un producte final el més adient possible.
Es defineix, així, un marc de treball que el líder de projecte s’encarregarà de fer seguir, formant
un equip de professionals, establint les persones adequades per a cada activitat, marcant una
data final d’entrega o deadline, etcètera. Aquest marc de treball està clarament diferenciat per
diverses etapes:
- Anàlisis de requisits. Consistiria en la primera etapa del projecte, i l’objectiu d’aquesta

seria obtenir el document d’especificació funcional. Un cop el client ens ha sol·licitat el
producte i hem arribat a un acord respecte al que desitja obtenir, el programador
realitzarà aquest document on especificarà de la manera més detallada possible el què
farà, com ho farà i quins programes desenvoluparà.
- Disseny i arquitectura. Si bé en l’apartat anterior hem hagut d’aprofundir en tot tipus de
detalls sobre la feina que es realitzarà, en aquesta etapa del projecte no serà tan
Tel. 977222231-601989689
necessari. En aquest punt, es parlarà sobre la manera en què es farà servir el programa
que s’està desenvolupant, així com les eines que es requeriran.
- Programació. En aquesta etapa posarem en marxa tot l’engranatge que havíem estat
preparant fins ara.
- Proves. Un cop desenvolupat el programa, ha arribat el moment de posar-lo a prova per
a comprovar la seva funcionalitat i descartar errates. Tot el que s’havia planificat a les
primeres etapes s’ha de veure reflectit en el programa que hem creat. Una bona praxis
és que aquesta prova la realitzi personal extern a l’equip de programadors que ha
desenvolupat el programa.
- Desplegament i Manteniment. El programa, desprès de totes les etapes de feina, per fi
ha arribat a l’usuari final. No obstant, la nostra feina encara no ha finalitzat, doncs un
cop entregat, hem de controlar que no sorgeixen deficiències en el programari,
realitzant un correcte manteniment del mateix mitjançant la millora i la optimització. Hi
ha quatre tipus diferents de manteniment:
- Perfectiu. Millora elements visuals o la optimització del programa.
- Evolutiu. S’afegeixen millores al programa que no s’havien previst en un principi,
per tal d’adaptar-nos a les noves necessitat de l’usuari.
- Adaptatiu. Modificacions en el sistema operatiu i les bases de dades.
- Correctiu. Aquells que s’apliquen derivats d’errades que no es van detectar en
la fase de proves i que han arribat inesperadament a l’usuari final. També
trobem en aquest grup tots aquells errors que sorgeixen amb la implementació
de nou contingut com a conseqüència del manteniment.
Així mateix, en el cas de Java, ens trobem amb diferents versions depenent de què volem
aconseguir. Tot això juntament amb l’ús d’un IDE professional, normalment Oracle. Certament,
des del seu primer llançament l'any 1996, Java ha mantingut la reputació de ser un dels
llenguatges més segurs, fiables i independents de la plataforma per a la programació
d'ordinadors. Malgrat la seva popularitat, començar amb Java pot ser aclaparador, com
probablement ja has notat. Amb totes les diferents versions i edicions per triar, pot ser difícil
saber quina versió de Java és adequada. A continuació, ens endinsem en les versions més
rellevants de Java disponibles, incloses les diferències clau i la versió més adequada per a les
vostres necessitats.
Primerament, cal diferenciar entre versió i edició. Quan us vau descarregar Java, normalment es
veuen opcions com Java SE 7 o JAVA EE 8. Tot i que el número indica clarament la versió, les
Tel. 977222231-601989689
lletres generen confusions, però bàsicament el que fan aquestes lletres és especificar l’edició de
Java. Aquestes són les edicions més habituals:
- Edició estàndard (SE). L'edició estàndard és la plataforma bàsica de programació Java.

Inclou totes les biblioteques bàsiques i les API amb les quals cada programador de Java
ha d'estar familiaritzat. Per a la majoria de desenvolupadors (especialment els que
acaben de començar) l'edició estàndard és la més adequada.
- Edició Enterprise (EE). L'edició empresarial inclou tot el que es troba a l'edició estàndard
amb algunes biblioteques addicionals que ofereixen funcionalitats per a entorns
empresarials a gran escala. L'edició empresarial posa èmfasi en aplicacions distribuïdes
grans, tolerants a errors, que caracteritzen un entorn empresarial. Tot i que l'EE és
adequat per a grans empreses i projectes a gran escala, la seva funcionalitat afegida no
és necessària per als nouvinguts o els desenvolupadors individuals que busquen
introduir-se.
- Edició Micro (ME). La micro-edició proporciona un subconjunt de la funcionalitat que
inclou SE, però inclou algunes biblioteques addicionals específiques per al
desenvolupament mòbil. Aquesta edició és la més adequada per als desenvolupadors
de Java de dispositius mòbils.
En segon lloc, cal veure quina versió de Java hem d’utilitzar, tan a nivell individual com
professional. En el món actual, ens trobem amb aquestes versions.
▪ Java 7. Java 7 es va llançar originalment el 2011. Va continuar sent l'opció de descàrrega

predeterminada des d'abril de 2012 fins a octubre de 2014 i encara s'utilitza àmpliament
avui dia. Java 7 va ser més popular per a la verificació de tipus millorada, la inferència
de tipus millorada per a genèrics i el suport de JVM per a llenguatges dinàmics. Malgrat
la seva popularitat, Java 7 ja no té suport públic per Oracle.
▪ Java 8. Java 8 es va llançar el 2014 i va substituir Java 7 com a descàrrega recomanada
per defecte. Les seves millores respecte a Java 7 inclouen suport a nivell de llenguatge
per a expressions lambda, una nova API DATE/TIME i el projecte Nashorn (un entorn
d'execució de JavaScript que permet als desenvolupadors incrustar JavaScript a les
aplicacions Java). Oracle va deixar oficialment de publicar actualitzacions per a Java 8
després de setembre de 2016.
▪ Java 9. Java 9 es va llançar l'any 2017 i és la versió principal de Java que s'utilitza
actualment. Java 9 adopta un enfocament més modular de la programació, ja que el
codi està més clarament separat en funció de la funcionalitat. A més, Java 9 introdueix
Tel. 977222231-601989689
JShell: una eina de línia d'ordres que us permet executar codi Java autònom en un shell
interactiu per fer proves ràpides. També inclou microbenchmarking que permet als
desenvolupadors mesurar el rendiment de petites peces de codi. Inclou suport complet
per al client HTTP 2.0 i fins i tot inclou una nova API de procés.
▪ Java 10. Java 10 es va llançar el març de 2018. Les seves millores inclouen una interfície
de recollida d'escombraries i una inferència de tipus variable local, però no ofereix
suport a llarg termini (LTS).
▪ Java 11. Java 11 es va llançar el setembre de 2018. És la següent versió principal de Java
que ofereix LTS
En conclusió, per iniciar-se Java SE 8 o Java SE 11. A nivell professional, Java EE, perquè les
biblioteques incorporades sí que poden ser necessàries en ambients laborals. Tot i que veureu
versions anteriors de Java (5,6,7) al món real, recordeu que la versió 8 és la versió activament
compatible actual.
5. Aplicació d’aspectes avançats de programació orientada a objectes.
5.1 Herència
Per herència entenem el pas de dades i codi d’un element pare a un fill. Quan una classe deriva
d’un altre és hereva de tots els seus atributs i mètodes. Una classe derivada (o classe filla) pot
sobreescriure (override) alguns atributs i mètodes, però també pot sobrecarregar-se, és a dir,
fer noves versions d’un mètode heredat però conservant l’original.
A Java, cada classe només pot ser hereva d’un altre. És el que denominem herència simple, a
diferència d’altres llenguatges de programació, com C++, que permet a cada classe heretar de
diverses, el que es coneix com a herència múltiple. Aquí un exemple amb la classe
FiguraGeometrica:
Tel. 977222231-601989689
Com es pot apreciar, com que no són interfícies, en comptes d’implements utilitzem el concepte
d’extends. Això significa que hereten totes les dades i mètodes de FiguraGeometrica. Això fa
que no calgui definir en les classes círculo i rectángulo els mètodes setColor() i getColor(), perquè
poden utilitzar-se com a propis sense cap problema. D’aquesta manera es reutilitza el codi de
manera simple sense necessitat de fer copy-paste.
És interessat també el concepte de wrapper, literalment “envoltoris”. Bàsicament són uns

elements que s’utilitzen per poder fer que les dades de diversos tipus puguin utilitzar-se com a
objectes quan sigui convenient. Un exemple d’això és la classe Integer, que té dos constructors:
Integer(int) i Integer(String). Aquesta mateixa té una col·lecció de mètodes, com per exemple
Integer parseInt(String), que converteix un String en un Integer.
5.2 Polimorfisme, sobreescriptura i sobrecàrrega
Aquests tres termes fan referència a tres característiques fonamentals de la POO.
En relació amb el polimorfisme, bàsicament entenem que consisteix en que un mateix element
pugui adquirir formes diverses. La manera més habitual de trobar-nos amb polimorfismes és en
Tel. 977222231-601989689
els mètodes, de manera que puguin existir diverses versions del mateix mètode amb distinta
forma: el mateix nom però diferents paràmetres; o diferent tipus tornat.
Aquest polimorfisme és resolt per l’intèrpret comparant els paràmetres formals amb els
paràmetres actuals que utilitzen en la trucada al mètode, executant la versió del mètode que
correspongui amb la trucada.
Així mateix, existeix un polimorfisme més complex, que es refereix als polimorfisme relatiu als
objectes pertanyents a una classe baixa. Per explicar-ho, utilitzarem aquesta jerarquia de classes
representada gràficament en format diagrama de classes (una de les eines més utilitzades per
arquitectes o analistes de software per dissenyar aplicacions POO), juntament amb un exemple
de codi en Java que implementa dit diagrama.
La idea és que els vehicles tipus Todoterreno tindran un consum mitjà cada 100km. Quan es
comportin com a automòbils convencionals (circulant per carrers i carreteres), aquest serà el
seu consum; mentre que quan circulen per camins i pistes forestals, el seu consum mitjà habitual
es veurà incrementat per 20%. Per tant, els vehicles Todoterreno a vegades es comportaran com
a Automovil i a vegades com a Todoterreno.
En aquest sentit, per tractar de clarificar la forma en el que l’intèrpret de Java decideix quina
versió de cada mètode executa en cada cas, hem de tenir en compte els mecanismes de
Tel. 977222231-601989689
vinculació que utilitza i quan els utilitza. Vinculació aquí es refereix a la forma en la que Java
enllaça la trucada a un mètode amb el codi concret de dit mètode.
A Java tenim dos mecanismes de vinculació:
- Vinculació prèvia, que es la que es realitza en temps de compilació. És la utilitzada amb els
mètodes “normals” i amb els sobrecarregats.
- Vinculació tardana, que és la que es realitza en temps d’execució, utilitzada en els mètodes
sobreescrits, excepte els finals.
Pel que fa a la sobreescriptura (overriding) de mètodes, diríem que ens permet modificar el
comportament de la classe mare reescrivint el codi d’un o diversos mètodes. Els trets que han
de compartir els mètodes sobreescrits són els següents: mantenir el mateix nom; tornar dades
del mateix tipus; i mantenir els mateixos paràmetres formals.
Per últim, cal destacar que la sobrecàrrega (overloading) és un dels elements bàsics del
polimorfisme. Quan definim diverses versions del mateix mètode, amb diferents paràmetres y/o
valors retornats, es diu que estem davant d’una sobrecàrrega d’aquest mètode.
5.3 Accés a la superclasse i classes niuades.
Per accedir-ne, s’utilitza la paraula reservada super. Aquesta paraula està disponible en tots els
mètodes menys als estàtics. Super, com this, és una referencia al objecte actual. La principal
diferencia és que executarà les versions dels mètodes de la superclasse en lloc dels de la classe
actual. Amb super podem accedir als membres protected de la superclasse, però no als private.
Aquí un exemple:
Tel. 977222231-601989689
Així mateix, convé assenyalar les classes niuades, és a dir, les que es poden definir una dins les
altres. En el següent exemple podem veure aquesta idea. La classe interna és membre de la
classe externa i, com a tal, tindrà accés a tots els seus atributs i mètodes, inclosos els privats. A
més, la classe niuada pot ser també estàtica o no, en cas negatiu no podria instanciar-se. Per
crear o instanciar objecte d’una classe niuada, es necessària la prèvia instanciació de la classe
externa. En general, les classes niuades cal evitar-les per risc a confusions.
6 Interpretació de la informació d’arxius locals en sistemes remots a través de connexions

web i en base de dades
6.1 Les estructures de dades bàsiques: arrays i matrius

Tel. 977222231-601989689
Les estructures d’emmagatzematge, tant si es manegen de manera clàssica com orientades a
objectes, poden ser de dos tipus: estàtiques, que ocupen un espai determinat a la memòria de
l’ordinador, un espai que és invariable i que queda especificat pel programador; i dinàmiques,
que són aquelles que tenen un espai ocupat que pot modificar-se durant l’execució del
programa.
Les estructures més genèriques són els arrays o llistats arrenglats. Certament, ja hem vist com
emmagatzemar dades individuals en variables. Què passa quan necessitem emmagatzemar un
grup de dades? Què passa si tenim una llista d'alumnes a una aula? O un rànquing dels 10 millors
cavalls que acaben una cursa de cavalls? Si emmagatzemem 5 números de bitllets de loteria, per
exemple, podríem crear una variable diferent per a cada valor:
int primerNumero = 4;
int segonNumero = 8;
int tercerNumero = 15;
int quartNumero = 16;
int cinqueNumero = 23;
Això és molt de codi repetit desagradablement. I si tinguéssim cent números de loteria? És més
net i còmode utilitzar un array per emmagatzemar les dades com a llista. Un array conté un
nombre fix de valors d'un tipus. Poden contenir dobles, int, booleans o qualsevol altre dada
primitiva. A més, també poden contenir cadenes i referències d'objectes. Cada índex d'un array
es correspon amb un valor diferent. Aquí teniu un diagrama d'una array ple de valors enters:
Cal tenir en compte que els índexs comencen a 0! L'element de l'índex 0 és 4, mentre que
l'element de l'índex 1 és 8. Aquest array té una longitud de 5, ja que conté cinc elements, però
l'índex més alt és 4.
Tel. 977222231-601989689
Per crear un array, primer declarament el tipus de data que volem emmagatzemar. Utilitzarem
com exemple un programa que guardi els preus de diferents objectes.
double[] prices;
Després, inicialitzem l’array amb les dades:
prices = {13.15, 15.87, 14.22, 16.66};
També podem declarar i inicialitzar en la mateixa línia de codi:
double[] prices = {13.15, 15.87, 14.22, 16.66};

També podem utilitzar arrays per guardar Strings o d’altres elements primitius:
String[] clothingItems = {"Tank Top", "Beanie", "Funny Socks", "Corduroys"};
Per obtenir el elements guardats al array, utilitzem els claudàtors amb el número d’índex
concret:
double[] prices = {13.1, 15.87, 14.22, 16.66};
System.out.println(prices[1]);
15.87
Això passa perquè 15.87 és l’ítem desat a la posició 1, ja que recordem que un array comença
sempre amb 0. Si intentem entrar a un element fora de rang, rebrem un error.
Així mateix, podem crear arrays buits per després introduir els elements. No obstant, Java
exigeix que es declari exactament el tipus i la mesura màxima i no es pot canviar posteriorment.
String[] menuItems = new String[5];
Un cop declarat i inicialitzat, hauríem de fer això per anar omplint:
menuItems[0] = "Veggie hot dog";

menuItems[1] = "Potato salad";
menuItems[2] = "Cornbread";
Tel. 977222231-601989689
menuItems[3] = "Roasted broccoli";
menuItems[4] = "Coffee ice cream";
String[] menuItems = {"Veggie hot dog", "Potato salad", "Cornbread", "Roasted broccoli",
"Coffee ice cream"};
El que sí que podríem canviar son els valors declarant un de nou:
menuItems[3] = "Baked cauliflower";

["Veggie hot dog", "Potato salad", "Cornbread", "Baked cauliflower", "Coffee ice cream"]
Els arrays s’anomenen normalment com array unidimensionals. És a dir, en tenim també
d’arrays bidimensionals o matrius. La gran diferència és que a l’hora de declarar i accedir a cada
element individual, hem d’utilitzar dos índex en lloc d’un:
A classe ja farem pràctiques sobre les matrius, però bàsicament funcionen igual que els arrays
unidimensionals però amb dos paràmetres (que poden ser molts més, de fet, tot i que ja
parlaríem d’arrays de múltiples dimensions.
6.2 Introducció als Arraylist
El principal problema dels arrays o matrius és que no es poden modificar. Per crear un array més
dinàmic, utilitzem el concepte d’Arraylist. Primerament, s’ha d’importar el paquet:
// import the ArrayList package

import java.util.ArrayList;
// create an ArrayList called students
Tel. 977222231-601989689
ArrayList<String> students = new ArrayList<String>();
Per modificar, s’ha d’utilitzar el mètode add(), mentre que per borrar utilitzariem el mètode
remove()
import java.util.ArrayList;
public class Students {

public static void main(String[] args) {
// create an ArrayList called studentList, which initially holds []

ArrayList<String> studentList = new ArrayList<String>();
// add students to the ArrayList

studentList.add("John");
studentList.add("Lily");
studentList.add("Samantha");
studentList.add("Tony");
// remove John from the ArrayList, then Lily

studentList.remove(0);
studentList.remove("Lily");
// studentList now holds [Samantha, Tony]
System.out.println(studentList);
}
}
6.3 Estructuració de fitxers: el format XML
Una de les problemàtiques més habituals és la necessitat de desar o recuperar dades i com
estructurar-les. Per intentar pal·liar els problemes resultants d’una heterogeneïtat de formes,
Tel. 977222231-601989689
utilitzem el llenguatge XML. Es tracta d’un familiar molt proper al codi HTML, és a dir, és un
llenguatge de marques, un conjunt de paraules i símbols per descriure la identitat o la funció
dels components d’un document. Aquestes marques permeten facilitar el processament de
dades a tractar dins el fitxer.
XML és un llenguatge que té vocació de ser molt clar. Sense tenir coneixements és possible
esbrinar a què es refereix gràcies a la informació extra que anomenem marques. Així, el
document és autoexplicatiu en relació amb els seus propòsits. Les diferències respecte al HTML
són les següents, un fet que explica els motius de la utilització de XML front a HTML a Java i en
el desenvolupament per Android:
- HTML serveix per indicar com representar visualment unes dades; mentre que XML serveix
per qualsevol tipus de processament de dades.
- A HTML la llista de marques està prefixada, mentre que a XML es poden crear de noves. És
la nostra tasca la de definir correctament les marques en funció de les dades
emmagatzemades.
- HTML té una sintaxi més laxa i XML és molt més estricte.
7 Adquisició de bones pràctiques de programació i de revisió de codi, ús de sistemes de

control de versions i metodologies de treball àgils.
7.1 Bones pràctiques de desenvolupament a Java
Una de les idees principals en relació amb els bones pràctiques de Java és elaborar un codi net.
El codi net fa referència a aquell codi que qualsevol desenvolupador pot llegir i canviar fàcilment.
Escriure codi net és una qüestió d'hàbit personal, però també d’habilitat. Els principis de
codificació neta ens ajuden a assolir molts objectius desitjables relacionats amb el programari
que volem produir. Anem a repassar-los per entendre-ho millor:
- Base de codi que es pugui mantenir: qualsevol programari que desenvolupem té una
vida productiva i durant aquest període requerirà canvis i manteniment general. El codi
net pot ajudar a desenvolupar programari que sigui fàcil de canviar i mantenir al llarg
del temps.
- Resolució de problemes més fàcil: el programari pot mostrar un comportament no
desitjat a causa de diversos factors interns o externs. Sovint pot requerir un canvi ràpid
Tel. 977222231-601989689
en termes de solucions i disponibilitat. El programari desenvolupat amb principis de
codificació neta és més fàcil de solucionar els problemes.
- Incorporació més ràpida: el programari, durant la seva vida, veurà que molts
desenvolupadors el creen, actualitzen i el mantenen, i els desenvolupadors s'uniran en
diferents moments. Això requereix no perdre molt de temps, requerint per tant
flexibilitat que el codi net ens ajuda a obtenir.
Les bases de codi escrites amb principis de codificació nets presenten diverses característiques
que les diferencien. Repassem algunes d'aquestes característiques:
- Enfocat: s'ha d'escriure un fragment de codi per resoldre un problema específic. No

hauria de fer res estrictament no relacionat amb la resolució del problema donat. Això
s'aplica a tots els nivells d'abstracció de la base de codi, com ara mètode, classe, paquet
o mòdul.
- Simple: aquesta és, amb diferència, la característica més important i sovint ignorada del
codi net. El disseny i la implementació del programari ha de ser el més senzill possible,
la qual cosa ens pot ajudar a aconseguir els resultats desitjats. L'augment de la
complexitat fa que els errors siguin més habituals i tot sigui més difícil de mantenir.
- Comprovable: el codi net, tot i que és senzill, ha de resoldre el problema. Ha de ser
intuïtiu i fàcil provar la base de codi, preferiblement de manera automatitzada. Això
ajuda a establir el comportament de base de la base de codi i fa que sigui més fàcil
canviar-lo sense trencar res.
Pel que fa a Java strictu sensu, destaquem alguns elements de bona praxis, mostrant aquí només
una petita visió:
- Mantenir petites les classes. En el món laboral, és habitual el concepte de refactoritzar,

que vol dir canviar el disseny del codi existent sense canviar-ne els resultats. Classes
molt llargues fan difícil el manteniment i l’ús per part dels desenvolupadors. En general,
una classe representa una entitat conceptual a l'aplicació, i la mida de la classe hauria
de reflectir només la funcionalitat que ha de fer, sigui el que sigui el que l'entitat ha de
fer. Cal que les classes s'enfoquin intensament a fer un petit nombre de coses, i que les
facin bé.
- Mantenir només els mètodes necessaris, amb una nomenclatura clara. No és el mateix
a() que calcularPes(), el segon és evidentment molt més clar.
Tel. 977222231-601989689
- Mantenir petits els mètodes, fent només una cosa, normalment amb una mida
equiparable a una pàgina visible des de la pantalla. Interessa veure la totalitat del
mètode.
- Utilitzar comentaris, perquè fins i tot el codi més comprensible necessita d’anotacions.
És interessant destacar aquí el llibre de Martin Flower, Refactoring (1999), que una mica va
marcar el camí cap a la idea de la refactorització. De fet, Eclipse té un conjunt d’eines que
optimitzen aquest procediment.
7.2 Sistemes de control de versions
Per control de versions (VCS) ens referim a un sistema que registra els canvis realitzats en un
fitxer o conjunt de fitxers al llarg del temps, de manera que sigui possible recuperar versions
específiques en qualsevol moment. Al programar, es fa del tot necessari mantenir versions
prèvies d’una imatge o disseny, de manera que un control de versions és bàsic. Aquest sistema
permet tornar a versions anteriors dels teus fitxers, tornar a una versió anterior del projecte
complet, comparar canvis al llarg del temps, veure qui va modificar per última vegada alguna
cosa que pugui estar causant problemes, veure qui (i quan) va introduir un problema i, fins i tot,
ens permet recuperar arxius perduts.
El mètode més habitual de control de versions és el de copiar els fitxers a un altre directori o
format. Aquest manera de procedir és propensa a errors i pot provocar el fet de desar
accidentalment un arxiu equivocat o sobreescriure’n d’altres. Per evitar aquesta problemàtica,
els programadors van començar a utilitzar control de versions locals que contenien una simple
base de dades on es portava el registre de tots els canvis produïts. No obstant, ven aviat va ser
necessari col·laborar amb d’altres desenvolupadors i superar l’esquema local. Els sistemes de
control de versions centralitzats (CVCS) tenen un únic servidor que conté tots els fitxers
versionats, permetent que els clients puguin descarregar els fitxers des d'aquest lloc centralitzat.
Aquesta configuració ofereix molts avantatges, com el fet de que totes les persones saben fins
a cert punt en què estan treballant els altres col·laboradors del projecte. Els administradors
tenen un control detallat sobre què pot fer cada usuari, i és molt més fàcil administrar un CVCS
que haver de tractar amb bases de dades locals. No obstant això, aquesta configuració també té
seriosos desavantatges. La més evident és que el servidor centralitzat por fallar, caient en
conseqüència tot el control de versions. Si cau durant hores, ningú pot col·laborar o desar canvis
als fitxers, però també pot passar que el disc dur del servidor central es corrompi, de manera
que es perdia tota la informació, a excepció de còpies de seguretat o fitxers situats a les
Tel. 977222231-601989689
màquines locals dels col·laboradors. Estem davant de desavantatges força importants, que
també tenen, de fet, els VCS locals.
L’evolució lògica a aquest esquema es va produir amb els sistemes de control de versions
distribuïts (DVCS), els quals ofereixen solucions per als problemes comentats. En un DVCS (com
Git, Mercurial, Bazaar o Darcs), els clients no només descarreguen l'última còpia instantània dels
fitxers, sinó que es replica completament el dipòsit. D'aquesta manera, si un servidor deixa de
funcionar i aquests sistemes estaven col·laborant, qualsevol repositori pot ser copiat al servidor
per tal de restaurar-lo. Així, cada clon és una còpia completa de totes les dades.
En aquest punt, convé presentar el control de versions que utilitzarem i que és, de fet, el més
popular: Git. La principal diferència entre Git i qualsevol altre VCS (incloent Subversion) és la
forma en què es manegen les dades. Conceptualment, la majoria dels altres sistemes
emmagatzemen la informació com a llistats de canvis. Aquests sistemes (CVS, Subversion,
Perforce, Bazaar, etc.) manegen la informació que emmagatzemen com un conjunt de fitxers,
amb les dades de totes les modificacions que han patit al llarg del temps.
Git no tracta ni emmagatzema les dades d'aquesta manera, sinó que ho fa com un conjunt de
còpies instantànies. El seu símil seria el d’un sistema de fitxers en miniatura. Cada vegada que
confirmem un canvi, o guardem l'estat del nostre projecte, Git bàsicament pren una foto de
l'aspecte de tots els fitxers en aquell moment i guarda una referència. A més, si els arxius no
s’han modificat, Git directament no emmagatzema un nou fitxer, sinó que crea un enllaç al fitxer
anterior que ja té desat. Per tant, Git maneja les dades com una seqüència de còpies
instantànies.
Tel. 977222231-601989689
Així mateix, la majoria de les operacions a Git només necessiten fitxers i recursos locals per
funcionar. En general no es necessita informació de cap altre ordinador de la xarxa. Per exemple,
per navegar per la història del projecte, Git no necessita connectar-se al servidor per obtenir la
història i mostrar-la. Simplement la llegeix directament de la base de dades local. Això vol dir
que es pot veure la història del projecte gairebé instantàniament. Si volem veure els canvis
introduïts en un fitxer entre la versió actual i la de fa un mes, Git pot buscar el fitxer de fa un
mes i fer un càlcul de diferències localment, en lloc d'haver de demanar-li a un servidor remot
que ho faci.
Una vegada presentat Git, convé senyalar un dels seus aspectes clau. Així, aquest control de
versions té tres estats principals on es poden trobar els teus arxius: confirmat (committed),
modificat (modified), i preparat (staged).
▪ Confirmat (commited) significa que les dades estan emmagatzemades de manera segura
a la base de dades local.
▪ Modificat (modified) suposa que s’ha modificat el fitxer, però encara no hi ha hagut una
confirmació a la base de dades.
▪ Preparat (staged) significa que un fitxer ha quedat marcat com a modificat i que ja es pot
confirmar.
Aquests tres estats ens porta de ple a les (també) tres seccions principals d'un projecte de Git:
el directori de Git (Git directory), el directori de treball (working directory) i l'àrea de preparació
(staging area).
▪ El directori de Git és on s'emmagatzemen les metadades i la base de dades d'objectes

del projecte. És la part més important de Git, i és el que es recrea quan es clona un
repositori des d'un altre ordinador.
▪ El directori de treball és una còpia d’una versió del projecte. Aquests fitxers es treuen
de la base de dades comprimida al directori de Git, i es col·loquen en disc perquè es
puguin utilitzar o modificar.
▪ L'àrea de preparació és un fitxer, generalment contingut al directori de Git, que
emmagatzema informació sobre el que anirà a la propera confirmació. De vegades se
l'anomena índex (“index”), però és més habitual trobar el concepte de staging area.
Bàsicament, podem ressaltar que el flux de Git funciona d’aquesta manera. Primer, es
modifiquen els fitxers al directori de treball; segon, es preparen els fitxers, afegint-los a l’àrea
de preparació; i tercer, es confirmen els canvis, s’agafen els fitxers tal com estan a l'àrea de
preparació i s’emmagatzema una còpia instantània de manera permanent al directori de Git.
Tel. 977222231-601989689
En resum, si una versió concreta d'un fitxer és al directori de Git, es considera confirmada
(committed). Si hi ha hagut canvis des que es va obtenir del repositori, però ha estat afegida a
l'àrea de preparació, està preparada (staged). I si s’han produït canvis des que es va obtenir del
repositori, però no s'ha preparat, està modificada (modified).
7.2.1 Sintaxi bàsica
Git funciona des de la terminal. A continuació es detallen els comandaments bàsics a tall de guia:
Tel. 977222231-601989689
Comandaments bàsics:
Comandaments Descripció
Inicialitza un repositori local de

git init
Git
git clone ssh://git@github.com/[nomUsuari]/[nom- Crea una copia local d’un

del-repo].git repositori remot
git status Comprovació status actual
git add [nombre-del-archivo.txt] Afegeix arxiu al staging area
Afegeix tots els arxius del

git add -A
repositori al staging area
Crea un missatge explicatiu dels

git commit -m "[Missatge del commit]"
canvis fets
git rm -r [nom-del-arxiu.txt] Elimina un arxiu (o carpeta)
Branques i fusions:
Comandament Descripció
Mostra llistat de branques del projecte

git branch
(asterisc senyala branca activa)
Mostra llistat de totes les branques (locals i

git branch -a
en remot)
git branch [nom de la branca] Crea un nova branca
Tel. 977222231-601989689
Comandament Descripció
git branch -d [nom de la branca] Elimina branca local
git push origin --delete [nombre de la

Elimina una branca en remot
rama]
git checkout -b [nombre de la rama] Crea una nova rama i ens mou cap a ella
git checkout -b [nombre de la rama] Clona una branca en remot i ens mou cap a
origin/[nombre de la rama] ella
git branch -m [nombre de la rama

Li dona nou nom a una branca local
antigua] [nombre de la rama nueva]
git checkout [nombre de la rama] Canvia una branca concreta
git checkout - Canvia a l’última branca activa
git checkout -- [nombre-del-archivo.txt] Descarta canvis d’un arxiu
Combina una branca concreta amb una

git merge [nombre de la rama]
branca activa
Combina una branca concreta (branca

git merge [nombre de la rama de origen]
d’origen) amb una bfranca nova (branca de
[nombre de la rama de destino]
destí)
Reverteix últims canvis i errors en el directori

git stash
actual
git stash clear Reverteix tots els canvis en el directori actual
Tel. 977222231-601989689
Compartir i actualitzar projectes:
Envia una branca local

git push origin [nom de la branca]
al repositori en remot
Envia canvis al
repositori en remot (i
git push -u origin [nombre de la branca]
et posiciona en una
branca concreta)
Envia canvis al
git push repositori en remot (a
la branca actual)
Elimina una branca en

git push origin --delete [nom de la branca]
remot
Actualitza el repositori
git pull local a l’últim commit
enviat
Agafa tots els canvis

git pull origin [nom de la branca] d’un repositori en
remot
git remote add origin ssh://git@github.com/[nomUsuari]/[nom- Afegeix canvis a un

del-repo].git repositori en remot
Inspeccionar i comparar:
git log Inicialitza un repositori local de Git
Tel. 977222231-601989689
git log --summary Crea una copia local d’un repositori remot
git log --oneline Comprovació status actual
git diff [source branch] [target branch] Afegeix arxiu al staging area
7.2.2 GitFlow
Per GitFlow entenem una lògica de treball que busca brindar més control i organització en el
marc dels controls de versions, específicament a Git. També fa referència a una extensió
instal·lable, anomenada actualment GitFlow AVH Edition.
Bàsicament, el flux de treball amb Git Flow ens ajuda a organitzar el repositori i la nostra feina.
S'estableix un conveni de noms per a les nostres branques que permet a tots els membres de
l'equip saber què és cada cosa. A més, estableix unes regles comunes alhora de moure la
informació d’una branca a una altra. Pel que fa a la política de branques, Git Flow proposa una
sèrie de convencions a nivell de nomenclatura:
- Una branca màster com a branca principal del projecte. Conté el codi de producció i no
s’hi treballa. D'aquesta branca no en neix cap excepte els hotfix.
- Develop, com a branca de desenvolupament, on tampoc hi treballarem. D'aquesta
branca neixen totes les branques de feature. La branca develop es mergearà amb master
quan anem a desplegar el projecte a través de les releases. Entenem merge com la fusió
a tres bandes entre les dos últimes de cada branca i l’ancestre comú d’aquestes dues.
- Feature, que seran les branques sobre les quals treballarem normalment. Porten per
defecte el prefix feature/ seguit del nom de la branca. Neixen sempre des de la branca
develop i moren quan són mergeadas.
- Hotfix, són les branques que farem servir per corregir errors crítics trobats en producció.
Porten el prefix hotfix/ seguit del nom de la branca. Neixen sempre des de la branca
màster.
- Release són les branques que utilitzarem per crear noves versions per desplegar la
producció. Porten el prefix release/ seguit del número de versió.
Tel. 977222231-601989689
- Bugfix, que són branques que es fan servir per corregir errors que encara no han arribat
a producció. Porten el prefix bugfix/ seguit del nom de la branca.
7.2.3 GitHub
Com ja hem vist, Git és un sistema de control de versions. La seva “centralització” efectiva és el
portal web GitHub.com, on els desenvolupadors emmagatzemen els seus projectes i ens permet
connectar amb persones amb idees afins.
En aquest sentit, cal subratllar diversos conceptes o idees molt utilitzats que ens ajuden a
entendre GitHub:
- Repositori. Es tracta d’un dipòsit, una ubicació on s’emmagatzemen tots els fitxers d’un
projecte concret. Cada projecte té el seu propi repositori i podeu accedir-hi amb un URL
únic.
- Bifurcació o “forking” d’un repositori, que fa referencia a la creació d’un nou projecte
basat en un altre que ja existeix. Aquesta característica fomenta enormement el
desenvolupament posterior de programes i altres projectes. Per exemple, és possible
trobar un projecte interessant i bifurcar el repositori, fer els canvis que es vulguin fer i
llançat un nou projecte revisat com a nou repositori.
Tel. 977222231-601989689
- Sol·licituds d'extracció. Després de fer els canvis pertinents, és possible que els autors
del repositori original puguin veure el vostre treball mitjançant aquesta sol·licitud.
GitHub ofereix un mitjà per comunicar-se amb els responsables del projecte.
- Connexió com a xarxa social, perquè permet que els projectes creixin més que gairebé
qualsevol de les altres funcions que s'ofereixen. Cada usuari de GitHub té el seu propi
perfil que actua com una mena de currículum, que mostra el vostre treball anterior i les
contribucions a altres projectes mitjançant sol·licituds d'extracció.
- Registres de canvi. Quan diverses persones col·laboren en un projecte, és difícil fer un
seguiment de les revisions. GitHub s'encarrega d'aquest problema fent un seguiment de
tots els canvis que s'han enviat al repositori.
Els passos necessaris per activar GitHub són els següents:
- Creació d’un compte d’usuari.

- Creació d’un repositori on emmagatzemar el codi.
- Creació dels fitxers
- Fer “commit” (manualment, mitjançant terminal de Git o mitjançant VSC).
- Connectar el vostre repositori (en remot) al vostre ordinador.
7.3 Fonaments de metodologies de programació àgils
Hi ha nombroses propostes de metodologia per desenvolupar programari. Tradicionalment

aquestes metodologies se centren en el control del procés, establint rigorosament les activitats,
eines i notacions al respecte. No obstant, aquest tipus de metodologia es caracteritza per ser
rígida i molt dirigida, un fet que no connecta bé amb un món cada cop més dinàmic. Certament,
aquest enfocament no és el més adequat per a molts dels projectes actuals on l'entorn del
sistema és molt canviant, i on s'exigeix reduir dràsticament els temps de desenvolupament però
mantenint una alta qualitat.
En aquest escenari, les metodologies àgils emergeixen com una possible resposta per omplir
aquest buit metodològic. Al febrer de 2001, després d'una reunió celebrada a Utah-EUA, neix el
terme àgil aplicat al desenvolupament de programari. El seu objectiu va ser esbossar els valors i
principis que haurien de permetre als equips desenvolupar programari ràpidament i responent
als canvis que puguin sorgir al llarg del projecte.
Tel. 977222231-601989689
Després d'aquesta reunió es va crear The Agile Alliance, una organització sense ànim de lucre,
dedicada a promoure els conceptes relacionats amb el desenvolupament àgil de programari i
ajudar les organitzacions perquè adoptin aquests conceptes. El punt de partida és el Manifest
Àgil, un document que resumeix la filosofia àgil.
Segons el Manifest:
- Es valora més a l'individu i a les interaccions de l'equip de desenvolupament, que no pas

el procés i les eines. La gent és el principal factor d’èxit d’un projecte de
desenvolupament. És més important construir un bon equip que no pas construir
l'entorn.
- Interessa desenvolupar programari que funcioni, relegant la confecció d’una bona
documentació. La regla a seguir és no produir documents tret que siguin necessaris de
forma immediata per prendre una decisió important. Aquests documents han de ser
curts i centrar-se en allò fonamental.
- La col·laboració amb el client ha de potenciar-se sobre la negociació contractual. Es
proposa que hi hagi una interacció constant entre el client i l'equip de
desenvolupament. Aquesta col·laboració entre tots dos serà la que marqui la marxa del
projecte i n'asseguri l'èxit.
- Cal assegurar-se que es pot respondre als canvis, no seguint un pla molt estricte.
L'habilitat de respondre als canvis que puguin sorgir al llarg del projecte (canvis en els
requisits, en la tecnologia, en l'equip, etc.) determina també l'èxit o el fracàs. Per tant,
la planificació no ha de ser estricta, sinó flexible i oberta.
Els valors anteriors inspiren els dotze principis del manifest. Són característiques que diferencien
un procés àgil d'un de tradicional. Els dos primers principis són generals i resumeixen gran part
de l'esperit àgil. La resta tenen a veure amb el procés a seguir i amb l'equip de desenvolupament,
pel que fa a fites a seguir i organització del mateix.
Els principis són:
- La prioritat és satisfer el client mitjançant primeres i contínues entregues de programari

que li aporti un valor.
- Donar la benvinguda als canvis. Es focalitzen els canvis perquè el client tingui un
avantatge competitiu.
Tel. 977222231-601989689
- Lliurar sovint programari que funcioni des d'un parell de setmanes a un parell de mesos,
amb el menor interval de temps possible entre lliuraments.
- La gent del negoci i els desenvolupadors han de treballar junts al llarg del projecte.
- Construir el projecte al voltant d'individus motivats. Donar-los l'entorn i el suport que
necessiten i confiar-hi per aconseguir finalitzar la feina.
- El diàleg cara a cara és el mètode més eficient i efectiu per comunicar informació dins
un equip de desenvolupament.
- El programari que funciona és la mesura principal de progrés.
- Els processos àgils promouen un desenvolupament sostenible. Els promotors,
desenvolupadors i usuaris haurien de ser capaços de mantenir una pau constant.
- L'atenció continua a la qualitat tècnica i al bon disseny millora l'agilitat.
- La simplicitat és essencial.
- Les millors arquitectures, requisits i dissenys sorgeixen dels equips organitzats per ells
mateixos.
- En intervals regulars, l'equip reflexiona sobre com arribar a ser més efectiu, i segons això
n'ajusta el comportament.
Bibliografia i Webgrafia bàsica utilitzada per la realització d’aquests materials
Belmonte, O. Introdución al lenguaje de programación Java: una guía básica. 2005 [inèdit].
Gómez, J-D. Java 2020: Curso de programación, 2020, Editorial Lobo Gris.
Lassof, M. Java Programming for Beginners, 2017, Packt.
Nadal, M. Curso de programación Java, 2021, Anaya.
Vozmediano, A.M. Java para Novatos, 2013, ensegundapersona.
Codecademy, 2021: https://www.codecademy.com/learn/learn-java

JavaDocs, 2022: https://docs.oracle.com/en/java/
Git, 2022: Git - Documentation (git-scm.com)
Tel. 977222231-601989689

Temari M-1

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

Temari M-1

Uploaded by

Copyright:

Available Formats

Java Back End Web

DOCENT: CARLOS HEREDIA

Arquitectures web: el concepte d’arquitectura client-servidor

▪ HTTP : HyperText Transfer Protocol. Protocol de comunicació per a la web

Figura 3: Protocols a Internet

Figura a: Protocol HTTP

GET / index.html HTTP / 1.1

HTTP / 1.1 200 OK

Dóna't: Fri, 31 Dec 2003 23 : 59 : 59 GMT

Content-Type: text / html

< html lang = "es" >

< head >

< meta charset = "utf-8" >

< title > El meu títol </ title >

</ head >

< body >

< h1 > Benvingut al meu lloc.com </ h1 >

</ body >

Figura 5: Protocol SSL/TLS

Figuae 6: SSL/TLS al model TCP

El protocol HTTPS (HTTP Secure) és un protocol de comunicació segura mitjançant Internet.

Figura 7: Protocol HTTPS

Amb el temps, i a causa de la manca de seguretat a les comunicacions i l'autenticació dels

Servidors web i aplicacions

Fonaments de Bases de Dades

Un Sistema d'Informació és un conjunt d'elements destinats al tractament i administració de

Aquesta definició de Sistema d'Informació inclou qualsevol tipus de sistema, tinguin o no

Cal sempre fer servir un SGBD?

Al nostre camp, un fitxer es podria considerar com la unitat mínima d’emmagatzematge de

Sistema gestor de bases de dades

En general, de qualsevol sistema d'informació, s'esperen una sèrie de característiques, que

▪ CRUD : L'acrònim CRUD fa referència a les 4 operacions bàsiques que qualsevol

▪ Crear i organitzar la Base de Dades Aquesta eina s'encarrega de la creació i gestió

▪ Respatller i recuperació La gran majoria de SGBD proporcionen eines addicionals

▪ Administrador d'Emmagatzematge : Controla l'accés a la informació de la Base de

▪ Cal fer consultes molt complexes entre diferents taules

D'altra banda, no són apropiades si:

▪ És necessari definir una topologia determinada per treballar amb l'aplicació

XML és un llenguatge per emmagatzemar informació de forma jeràrquica. És un llenguatge que

En definitiva, el llenguatge XML només especifica la manera d'escriure el fitxer i organitzar la

▪ Les dades són jeràrquiques

▪ Les dades no són jeràrquiques

▪ L'aplicació està programant-se amb algun llenguatge de programació orientat a

Les Bases de Dades objecte-relacionals són apropiades si:

▪ L'arquitectura de l'aplicació està orientada a objectes

▪ Per al desenvolupament de l'aplicació no es farà servir un llenguatge orientat a

La seva característica principal és l'escalabilitat horitzontal. És a dir, el rendiment de la Base de

En general, les Bases de Dades NoSQL són apropiades si:

▪ Cal manejar grans quantitats de dades

Classificació segons mida

SGBD d'alt rendiment

Tipus de Bases de Dades

Bases de dades centralitzades

▪ Fàcil implementació. En tractar-se d'una solució àmpliament adoptada és més

▪ Un sistema de Bases de Dades distribuïda és complex de posar en marxa i mantenir

▪ Capa de presentació És la capa que veu lusuari. Presenta l'aplicació a l'usuari, us

▪ Recol·lecció i anàlisi de requeriments : En aquest pas recollim informació del

Les entitats es representen pel símbol següent: Aquestes característiques

següent: Alhora, podem relacionar unes entitats amb les altres a

Quedaria representat de la següent manera:

Relació molts a molts

Atributs estructurats (o compostos)

Comprovacions sobre el Diagrama Entitat-Relació