Mòdul 2 - Orientació a objectes

Orientaci aobjectes

Jordi Pradel MiquelJose Raya Martos

PID_00171145

FUOC PID_00171145 Orientaci a objectes

Cap part d'aquesta publicaci, incloent-hi el disseny general i la coberta, no pot ser copiada,reproduda, emmagatzemada o transmesa de cap manera ni per cap mitj, tant si s elctric comqumic, mecnic, ptic, de gravaci, de fotocpia o per altres mtodes, sense l'autoritzaciprvia per escrit dels titulars del copyright.


ndex

Introducci.................................................................................................. 5

Objectius....................................................................................................... 6

1. Qu s l'orientaci a objectes?........................................................ 71.1. Evoluci histrica dels llenguatges de programaci ................... 81.2. Els llenguatges de programaci orientats a objectes ................... 81.3. Anlisi orientada a objectes ........................................................ 9

2. Classificaci i abstracci.................................................................. 102.1. Classificaci ................................................................................. 102.2. Abstracci .................................................................................... 122.3. Descripci de les classes d'objectes ............................................. 12

2.3.1. Atributs ........................................................................... 122.3.2. Associacions ................................................................... 132.3.3. Operacions ..................................................................... 16

3. Ocultaci d'informaci i encapsulament.................................... 183.1. Ocultaci d'informaci ............................................................... 183.2. Encapsulament ............................................................................ 20

4. Herncia i polimorfisme.................................................................. 224.1. Herncia ....................................................................................... 22

4.1.1. Generalitzaci i especialitzaci ...................................... 234.2. Polimorfisme ............................................................................... 24

4.2.1. Classes abstractes i redefinici del comportament ........ 254.2.2. Associacions polimrfiques ........................................... 26

5. Cas prctic: un frum virtual........................................................ 275.1. Classificaci dels objectes ........................................................... 27

5.1.1. Classes ............................................................................ 275.1.2. Atributs ........................................................................... 28

5.2. Herncia ....................................................................................... 285.3. Associacions ................................................................................. 29

Resum............................................................................................................ 31

Activitats...................................................................................................... 33

Exercicis d'autoavaluaci........................................................................ 33


Solucionari.................................................................................................. 35

Glossari......................................................................................................... 37

Bibliografia................................................................................................. 40

FUOC PID_00171145 5 Orientaci a objectes

Introducci

Tal com hem vist al mdul "Introducci a l'enginyeria del programari", els pro-gramadors necessiten un llenguatge de programaci que els permeti escriureprogrames en termes de ms alt nivell d'abstracci del que la mquina potexecutar per si mateixa. Un dels tipus de llenguatges de programaci ms im-portants sn els orientats a objectes.

L'orientaci a objectes proposa fer una abstracci del problema que s'est in-tentant resoldre en lloc de fer-la de la mquina que finalment executar elprograma. Grcies a aquest enfocament, resulta un paradigma molt til nosolament per a la programaci sin tamb per a l'anlisi.

Al llarg d'aquest mdul estudiarem com podem crear una descripci del mnreal seguint el paradigma de l'orientaci a objectes i com aquesta descripciens pot ajudar a fer anlisi de requisits per tamb en altres activitats del pro-gramari.

Comenarem introduint l'orientaci a objectes i el context histric en el qualva nixer.

A continuaci anirem veient, de manera progressiva, com podem fer servirel paradigma de l'orientaci a objectes per a descriure el mn real. Comena-rem parlant de la classificaci i l'abstracci, mitjanant les quals estructuremla informaci en el que anomenarem classes, associacions, atributs i operacionsi continuarem estudiant l'encapsulament, que ens permet ocultar informacidins els objectes, i l'herncia i el polimorfisme, que ens permeten fer abstrac-cions ms potents.

Finalment veurem com podem aplicar l'orientaci a objectes per a fer unadescripci del mn real per mitj d'un cas prctic.


Objectius

L'objectiu principal d'aquest mdul s presentar el paradigma de l'orientacia objectes i com es pot aplicar a activitats de l'enginyeria del programari di-ferents de la programaci. En concret, l'estudiant ha d'assolir els objectius se-gents:

1. Entendre els conceptes fonamentals de l'orientaci a objectes: classificaci,abstracci, ocultaci d'informaci, encapsulament, herncia i polimorfis-me.

2. Saber com es poden descriure els objectes d'un sistema mitjanant l's declasses, atributs, operacions i associacions.


1. Qu s l'orientaci a objectes?

Un dels problemes comuns a tots els projectes de desenvolupament de pro-gramari s descriure la tasca que s'ha de dur a terme en un llenguatge que tantel programador com la computadora puguin entendre. Els llenguatges de pro-gramaci es van crear justament per aquest motiu.

El problema de la comunicaci

Al mn de la programaci informtica s'ha intentat solucionar el problemacreant nous llenguatges de programaci ms propers al llenguatge natural (elque fem servir les persones per a comunicar-nos entre nosaltres) i a la maneraque tenim d'entendre la realitat que ens envolta.

Exemple de llenguatge assemblador

A continuaci teniu un exemple de programa en llenguatge assemblador. No us preocu-peu, que no cal entendre'l per a entendre la resta del mdul.

.MODEL Small .STACK 100h .DATAmsg db 'Hello, world!$' .CODEstart:mov ah, 09hlea dx, msgint 21hmov ax,4C00hint 21hend start

A continuaci teniu un exemple del mateix programa, aquest cop escrit en C.

#includeint main(int arg_count,char ** arg_values) { printf("Hello World\n"); return 0;}

I a continuaci en BASIC.

10 PRINT "Hello World"

Vegeu tamb

Al mdul "Introducci al'enginyeria del programari" estracten els diversos problemescomuns a tots els projectes dedesenvolupament de progra-mari.


1.1. Evoluci histrica dels llenguatges de programaci

Ja sabem que els processadors poden entendre un conjunt limitatd'instruccions (l'anomenat codi mquina). Els primers llenguatges es limitavena instruccions molts senzilles que es corresponien prcticament una a una ambles operacions que podia entendre el processador. Els llenguatges que imple-menten aquest paradigma es coneixen com a llenguatge assemblador.

Els llenguatges fets en assemblador sn molt fcils d'interpretar per a la m-quina, per sn molt complicats d'escriure i d'entendre per a les persones.Per aquest motiu, programar fent servir aquests llenguatges es fa molt feixuc iaquest enfocament noms s viable per a tasques molt concretes.

De seguida es van anar elaborant llenguatges ms rics que permetien als pro-gramadors fer servir un llenguatge ms proper al llenguatge natural a l'horade descriure les instruccions que ha de seguir el computador. s el cas de llen-guatges com el BASIC, el COBOL o el C.

Aquests llenguatges es coneixen com a llenguatges d'alt nivell perqu permetenexpressar-se a un nivell d'abstracci ms alt que els llenguatges assembladors.Tamb es coneixen com a llenguatges procedimentals perqu es basen en la de-finici de procediments per a descompondre el problema que es vol tractar enunitats ms petites.

Els llenguatges procedimentals eleven el nivell d'abstracci respecte als llen-guatges assembladors creant una abstracci de la mquina sobre la quals'executen, que entn instruccions ms abstractes que les que realment potexecutar.

1.2. Els llenguatges de programaci orientats a objectes

Al final dels anys seixanta els investigadors noruecs Ole-Johan Dahl i KristenNygaard, mentre treballaven en un programari de simulaci de vaixells, vandecidir provar un enfocament diferent. En comptes de fer una abstracci de lamquina sobre la qual s'executaria el programa farien una abstracci del pro-blema sobre el qual estaven treballant. Els seus programes, en comptes de te-nir procediments i estructures de dades tindrien objectes, cadascun dels qualsrepresentaria un objecte del mn real; aix naixia el llenguatge Simula 67 i laprogramaci orientada a objectes.

No va ser, per, fins al final dels setanta i comenaments dels vuitanta que elparadigma de l'orientaci a objectes es va popularitzar massivament, primeramb el llenguatge Smalltalk (creat per un grup d'investigadors dirigit per AlanKay al mtic laboratori de Xerox a Palo Alto), desprs amb el C++ (creat per


Bjarne Stroustrup als no menys mtics laboratoris Bell d'AT&T el 1983) i final-ment amb el Java, com un dels llenguatges ms populars actualment (creat perJames Gosling a Sun Microsystems el 1995).

La diferncia fonamental dels llenguatgesorientatsaobjectes respecteals llenguatges procedimentals est en el fet que, en comptes de basar-seen all que la mquina pot entendre, es basen en all que les personesvolem comunicar.

Aviat es va veure, per, que el fet que aquest paradigma se centrs en l'mbitdel problema per resoldre i no pas en el de la soluci, el convertia en unabona eina no solament per a les tasques d'implementaci, sin tamb durantl'anlisi, ja que l'orientaci a objectes ens ofereix una manera de fer la des-cripci de qualsevol sistema fcilment traslladable a programari mitjanantels llenguatges de programaci orientats a objectes.

1.3. Anlisi orientada a objectes

L'anlisi orientada a objectes consisteix a aplicar els conceptes i idees dels llen-guatges orientats a objectes a l'anlisi de sistemes. Aix ens permetr fer servirun llenguatge similar durant les diferents etapes del desenvolupament.

Aquest s de l'orientaci a objectes durant les tasques d'anlisi es va popula-ritzar, especialment, a partir de l'aparici el 1997 del llenguatge unificat demodelitzaci (UML) creat per James Rumbaugh, Grady Booch i Ivar Jacobson.

Comunicaci amb UML


2. Classificaci i abstracci

Un sistemaorientataobjectes est format per una srie d'elementsautnoms (els objectes) que es comuniquen els uns amb els altres pertal de dur a terme les seves tasques.

Per tant, el primer que hem de saber en un sistema com aquest s qu pot fercadascun d'aquests objectes: quines coses sap, amb quins altres objectes es potcomunicar o quines tasques se li poden demanar.

Anomenarem responsabilitats de l'objecte aquestes caracterstiques.

2.1. Classificaci

Quan descrivim un determinat sistema fent servir orientaci a objectes des-criurem els objectes que formen aquest sistema. Si intentem descriure un perun aquests objectes, per, aviat trobem que hi ha objectes que sn d'un mateixtipus i tenen una mateixa estructura i responsabilitats.

Exemple de classificaci

Si estem descrivint una empresa, per exemple, segurament tindrem algun objecte que re-presenta un treballador concret. Aquest treballador pot tenir responsabilitats com "saberquin s el seu nom", "saber quin s el seu departament" o "calcular quants companys t(s a dir, quants treballadors pertanyen al mateix departament que ell)". Per de seguidaveiem que hi ha molts altres objectes a la mateixa empresa que tamb representen tre-balladors i que, per tant, tamb tenen les responsabilitats de "saber quin s el seu nom","saber quin s el seu departament" i "calcular quants companys t".

A l'hora de fer la descripci del nostre sistema, per tant, no ens interessar tantl'objecte en si (en aquest cas, una persona, l'individu) com la classe d'objectesque tenen les mateixes responsabilitats (en aquest cas, els treballadors).

La classificaci s el mecanisme mitjanant el qual simplifiquem ladescripci dels objectes del sistema i identifiquem aquelles classesd'objectes tals que tots els objectes de la mateixa classe tenen les matei-xes responsabilitats.

En el cas anterior, tots els treballadors saben quin s el seu nom (encara que cada treba-llador tingui un nom diferent, cadasc sap quin s el seu), saben quin s el seu departa-ment i poden calcular quants companys tenen.


Classificaci dels objectes

Anomenem classe el grup i instncia l'objecte.

Classes d'objectes

A l'exemple anterior tenim tres classes d'objectes:

Crrecs, Empleats i Departaments.

De la classe Crrec en tenim tres instncies (Director, Ajudant i Responsable), d'Empleat,vuit, i de Departament, tres (Vendes, Finances i Informtica).

A l'hora de definir les responsabilitats dels objectes d'una classe, les podemdividir en tres tipus:

1) La informaci que coneixen (les dades)

2) Els objectes que coneixen (les associacions)

3) Les tasques que poden dur a terme (les operacions)

A l'exemple anterior, cada instncia d'Empleat sap quina s la informaci de l'empleat(el nom, el telfon, etc.), est associada amb altres instncies (el seu crrec i el seu de-partament) i hi ha una srie de tasques que pot dur a terme (redactar una sollicitud,aprovar-la, etc.).

Instncies


2.2. Abstracci

En orientaci a objectes, l'abstracci s el mecanisme mitjanant el qualdecidim quines de les possibles responsabilitats associades a una classeformaran part de la seva definici.

A l'hora de descriure un sistema mitjanant l'orientaci a objectes, hauremd'aplicar el mecanisme d'abstracci als tres tipus de responsabilitat que hemvist anteriorment per a decidir quines dades, relacions i comportament snrellevants per al nostre problema.

En el cas de l'exemple anterior, s ben probable que trets com el color dels ulls, l'aladao qui s amic de qui entre els treballadors o el fet que a alguns treballadors els poguemdemanar que facin la declaraci de renda no siguin rellevants i, per tant, no es tinguinen compte.

2.3. Descripci de les classes d'objectes

Aplicant la classificaci i l'abstracci arribarem a una primera descripci delsobjectes que formen part del nostre sistema, en qu tindrem un conjunt declasses i, per a cada classe, un conjunt de responsabilitats. Aquestes responsa-bilitats prendran la forma d'atributs, operacions i associacions.

2.3.1. Atributs

Quan tots els objectes d'una classe tenen un mateix element d'informaci(com ara la data de contractaci a l'empresa), encara que cada objecte hi tinguiun valor diferent, diem que la classe t un atribut.

Els atributs ens diuen quina informaci (quines dades) coneixem sobreels objectes d'una classe determinada.

L'atribut tindr un nom que ens permet distingir-lo de la resta d'atributs (perexemple, podem anomenar Alta l'atribut que desa la data en qu un empleatva ser donat d'alta a l'empresa) i sol tenir un tipus que ens ajuda a entendremillor el tipus d'informaci que s'hi emmagatzema i a saber quins valors snvlids per a l'atribut (per exemple, si diem que Alta s de tipus Data, sabemque els valors que pot prendre han de ser dates i no pas nombres enters).

String

Anomenem String el tipusd'atributs en que els valors snseqncies de carcters; s adir, textos sense cap format.Formalment, un String s unaseqncia de smbols ques'escullen d'un conjunt o d'unalfabet.


Exemple de classe amb atributs i de dues de les seves instncies

mbit de l'atribut

Els atributs poden emmagatzemar, o b un valor diferent per a cada instn-cia, o b un mateix valor per a totes les instncies de la classe. Per exemple,l'atribut Alta que emmagatzema la data en qu es va incorporar el treballadora l'empresa ha de tenir un valor diferent per a cada treballador. En aquest cas,diem que l'atribut t mbitd'instncia.

En canvi, un atribut anomenat mitjanaEdats que emmagatzems la mitjana deles edats de tots els treballadors no tindria sentit que dons valors diferents pera diferents instncies ja que, sigui quin sigui el treballador a qui preguntem,la mitjana de les edats ha de ser la mateixa; en aquest cas, diem que l'atributt mbitdeclasse. Aquests atributs (amb mbit de classe), per, sn poc ha-bituals.

Nombre de valors d'un atribut

Fins ara hem vist atributs tals que cada instncia noms pot tenir un valor,i l'ha de tenir per fora. Diem que sn atributs univaluats i obligatoris. Peralguns atributs poden no tenir valor en algunes instncies (atributs opcionals)o en poden tenir ms d'un (atributs multivaluats).

Exemples d'atributs opcionals i multivaluats

El nmero de fax d'un treballador podria ser un atribut opcional (ja que un treballadorpodria no tenir nmero de fax); d'altra banda, el nmero de telfon podria ser multiva-luat, ja que podria ser que un treballador tingus ms d'un nmero de telfon en el quales pogus localitzar.

2.3.2. Associacions

Les associacions ens diuen quins altres objectes coneixen els objectes d'unaclasse (quines sn les seves relacions amb altres objectes). Per tant, formen partdel conjunt d'informaci (les dades) que gestiona un objecte i, com a tals, lespodrem considerar atributs. A diferncia dels atributs que hem considerat finsara, per, una associaci no fa referncia a un nic objecte sin que semprefar referncia, com a mnim, a dos objectes. Per aix distingim entre atributsi associacions.


Per exemple, hem dit que ens interessa saber, per a una instncia concreta de departa-ment, quins empleats hi pertanyen. En aquest cas direm que hi ha una associaci entreles classes Empleat i Departament. L'associaci pot tenir un nom (per exemple, podemanomenar treballaA la relaci entre un empleat i el seu departament). A diferncia d'unatribut, l'associaci treballaA sempre fa referncia a dos objectes: un empleat i un depar-tament.

Una associaci entre dues classes indica que les instncies de cada clas-se saben, com a part de les seves responsabilitats, amb quina o quinesinstncies de l'altra classe estan relacionades.

La relaci d'associaci entre dues instncies s recproca, de tal manera que siuna instncia a d'una classe A est associada amb una instncia b de la classeB, la instncia b estar tamb associada a la instncia a.

Quan una classe est associada amb una altra, podem consultar el vincle entreles instncies relacionades. Aix, si diem que la classe Empleat est associadaa la classe Departament, estem dient que, donada una instncia concreta dela classe Empleat, li podrem demanar amb quines instncies de la classe De-partament est associada o, si ho volem fer a la inversa, donada una instnciaconcreta de Departament, li podrem demanar amb quines instncies d'Empleatest associada.

Exemple d'associacions

A l'exemple de la figura segent, podem saber que l'empleada Laura Mart t associat elDepartament de Vendes, l'empleada Rosa Sils, tamb, i que el Departament de Vendes tassociats els empleats Laura Mart i Rosa Sils.

Associaci Empleat-Departament(treballaA)

Tot i que l'associaci s una caracterstica de la classe, els valors que pren seranespecfics de les instncies (igual que passa amb els atributs). Per, a difernciadels atributs, les associacions mai no tindran mbit de classe.


Rols de les instncies

Quan una instncia participa en una associaci amb altres instncies, sempreho ha de fer tenint un rol concret. De vegades, aquest rol tindr un nom ex-plcit i, fins i tot, podr tenir una visibilitat (pblic, privat, etc.).

El rol s especialment important en el cas de les associacionsrecursives, quesn aquelles associacions que connecten una classe amb ella mateixa.

Exemple d'associaci recursiva

Si tenim la classe Persona i volem definir la relaci entre pares i fills, tindrem una asso-ciaci recursiva a la classe Persona, ja que estem connectant la classe Persona amb ellamateixa. En aquest cas, una instncia de persona pot tenir el rol de pare o de fill en rela-ci a una altra instncia. s important veure, per, que una mateixa instncia de Personapot tenir el rol de pare en relaci a una instncia i, al mateix temps, tenir el rol de fillen relaci a una altra.

Associaci recursiva

El rol tamb s important quan tenim ms d'una associaci entre dues classes.

Per exemple, la classe Persona i la classe Ciutat podrien tenir dues associacions: la queens diu on va nixer una persona (ciutat natal) i la que ens diu on viu la persona (ciutatde residncia). En aquest cas no n'hi ha prou de dir que una ciutat est associada a unapersona sin que cal distingir quin dels dos rols t la ciutat en la seva associaci amb lapersona (s a dir, si s la seva ciutat natal o si s la seva ciutat de residncia). A priori,res no impedeix que una mateixa ciutat tingui els dos rols per, tot i aix, consideraremque la ciutat est associada dues vegades a la persona, una com a ciutat natal i una altracom a ciutat de residncia.

Classes associatives

Nota d'un estudiant

Suposem el cas segent. Un estudiant est matriculat d'una assignatura i, en finalitzarel curs, li queda una nota de B. De quina classe s atribut la nota que l'estudiant treud'una assignatura? Si fem que la nota sigui un atribut d'estudiant llavors no dependria del'assignatura; direm, per exemple, que en Joan (un estudiant) t una nota de B... per,de quina assignatura? Si, en canvi, definim la nota com un atribut d'assignatura, llavorsno dependria de l'estudiant. En realitat, la nota pertany a l'associaci entre l'estudianti l'assignatura.

Una classeassociativa s aquella classe les instncies de la qual sn instnciesd'una associaci. A l'exemple anterior, tindrem una classe associativa anome-nada Matrcula les instncies de la qual serien les parelles (Estudiant, Assigna-tura) que estan relacionades.


Una instnciad'unaassociaci s una parella d'instncies de les classesque l'associaci relaciona. Podem parlar d'instncies d'associaci tant sil'associaci s una classe associativa com si no ho s. En el primer cas,per, aquestes instncies sn, alhora, objectes d'una classe i, per tant,poden tenir, al seu torn, atributs, operacions, mtodes i associacions.

Classe associativa

Associacions n-ries

Fins ara, totes les associacions que hem vist eren entre dues classes per, devegades, es pot donar el cas de tenir associacions entre tres o ms classes.

Exemple d'associaci n-ria

La matrcula d'un estudiant la podem veure com una associaci binaria (Estudiant, Assig-natura) o b com una associaci ternria (Estudiant, Semestre, Assignatura).

En el segon cas, no hi ha una nica associaci entre l'estudiant i l'assignatura sin diver-ses, cadascuna corresponent a un semestre diferent.

En el cas de tenir una classe associativa, les instncies de la classe sempre estaran relaci-onades amb una instncia de cadascuna de les classes de l'associaci. Aix doncs, no tsentit parlar de la nota de l'estudiant en aquella assignatura sin de la nota de l'estudianten aquella assignatura i en aquell semestre.

2.3.3. Operacions

Les operacions ens diuen quines tasques poden dur a terme les instn-cies d'una classe (quin s el seu comportament observable).

A l'hora de definir el comportament d'un objecte distingim entre l'operaci(la definici de qu pot fer) i el mtode (el conjunt d'instruccions que indicacom ho ha de fer). Les operacions formen part de la interfcie, mentre que elsmtodes formen part de la implementaci.

Vegeu tamb

Podeu trobar ms informacisobre la diferncia entre inter-fcie i implementaci al mdul"Introducci a l'enginyeria delprogramari".


Quan un objecte vol que un altre executi el comportament definit en una deles seves operacions, diem que invoca (o crida) aquella operaci o b que lienvia aquell missatge.

Per exemple, si la classe Treballador t una operaci anomenada quantsCompanys, diemque s'invoca o es crida l'operaci quantsCompanys o b que se li envia el missatge quants-Companys.

Exemple de classe amb atributs i operacions i de dues de lesseves instncies

Operacions, mbit declasse o d'instncia

Les operacions tamb po-den tenir mbit de classe (elmissatge el rep la classe) od'instncia (el missatge el repuna instncia en concret) toti que, de moment, no cal queho tinguem en compte.


3. Ocultaci d'informaci i encapsulament

Hem vist que, grcies a la classificaci i l'abstracci, podem simplificar la des-cripci dels objectes agrupant-los en classes i centrant-nos noms en aquellesresponsabilitats que siguin rellevants per al nostre cas.

Tamb hem vist que ens interessa "ocultar informaci" per tal de separar la in-terfcie d'un objecte de la seva implementaci i poder oferir a la resta d'objectesdel sistema una versi encara ms simplificada d'aquest.

L'encapsulament s el mecanisme de l'orientaci a objectes que enspermet ocultarinformaci.

3.1. Ocultaci d'informaci

El concepte d'ocultaci d'informaci s molt anterior als llenguatges orientatsa objectes. De fet, va ser mencionat per primer cop per David Parnas (1972).

Ocultaci d'informaci segons David Parnas

Cada element (mdul o subsistema) del sistema cont una certa infor-maci que "oculta" a la resta de mduls presentant-los una visi simpli-ficada.

Una descripci en qu no expliquem el funcionament intern de l'objecte des-crit es coneix com a descripci de "caixa negra".

Exemple de descripci de "caixa negra"

Suposem que volem descriure a una altra persona com funciona una aixeta de palanca.Segurament la nostra descripci seria de l'estil de: "L'aixeta t una palanca que, quanla puges, fa que surti aigua (com ms la puges ms aigua surt) i quan la baixes tancal'aixeta. Per a regular la temperatura has de moure la palanca a l'esquerra (si vols l'aiguams calenta) o a la dreta (si la vols ms freda)".

Vegeu tamb

Hem vist al mdul "Introduccia l'enginyeria del programari"que ens interessa separar la in-terfcie d'un objecte de la sevaimplementaci.


Aixeta vista com a caixa negra

Amb aquesta descripci, per, noms hem descrit com es fa servir l'aixeta, no pas comfunciona per dintre. Si fos un lampista qui li demana a un altre lampista com funcionauna aixeta de palanca segurament ens diria alguna cosa similar al segent:

"L'aixeta t dues entrades d'aigua, una de freda i una de calenta. La palanca va connectadaa una rtula que regula el pas d'aigua de les dues entrades: a la posici central deixa passaraigua de tots dos circuits, mentre que si movem la palanca, anirem ampliant el pas d'uncircuit al mateix temps que tanquem el pas de l'altre."

Aixeta vista com a caixa blanca

Les descripcions que inclouen els detalls de funcionament les coneixem coma descripcions de "caixa blanca".

Totes dues sn descripcions vlides de l'aixeta de palanca, per mentre que laprimera s molt fcil d'entendre, la segona requereix una mica ms d'esfor i deconeixements sobre lampisteria. Aplicant el principi d'ocultaci d'informaci,la primera descripci omet el detall sobre com es regulen els dos circuits d'aiguai es limita a explicar-nos que, movent la palanca, alterem la temperatura del'aigua.

De la mateixa manera, en descriure les responsabilitats d'una classe, ho podemfer des d'un punt de vista extern (com una "caixa negra"), indicant nomscom es poden fer servir els objectes d'aquella classe, o b des d'un punt devista intern (o de "caixa blanca"), indicant com est estructurat l'objecte i comfunciona per dintre.


3.2. Encapsulament

L'encapsulament ens permet ocultar informaci a altres objectes i de-finir quins atributs, operacions i associacions d'un objecte els seran vi-sibles i quins estaran ocults.

D'aquesta manera els atributs i operacions que no hem fet visibles quedenocults a la resta d'objectes que, per tant, no necessiten (de fet no poden) saberde la seva existncia. El fet que les dades i les operacions formin part de lamateixa entitat (l'objecte) facilita encara ms l'ocultaci d'informaci.

S'anomena visibilitat d'un atribut, associaci o operaci, la propietatque defineix quins objectes el poden veure.

La visibilitat, doncs, determina quins objectes poden consultar el valor del'atribut o de l'associaci o b invocar l'operaci. En general, diem que la vi-sibilitat determina quins objectes tenen accs a una responsabilitat determi-nada. Els diferents llenguatges de programaci defineixen diferents tipus devisibilitat, per els casos ms tpics sn:

Visibilitat pblica: qualsevol objecte hi t accs.

Visibilitat privada: noms els objectes de la mateixa classe hi tenen accs.

Visibilitat protegida: noms els objectes de la mateixa classe o d'algunasubclasse hi tenen accs.

Visibilitat de paquet: noms els objectes del mateix grup o "paquet" hitenen accs.

Paquet

Un paquet s una agrupaci d'elements en un sistema orientat a objectes per a facilitar-nel'organitzaci. Un paquet pot contenir classes i altres paquets i pot resultar til per adefinir la visibilitat de paquet dels atributs, associacions i operacions de les classes quecont.

Com a efecte collateral, l'ocultaci d'informaci t l'avantatge que alg podriacrear una implementaci alternativa (per exemple, fabricar una aixeta de pa-lanca que substitus la rtula per algun altre mecanisme) sense que aix afec-ts els usuaris de la classe, ja que el comportament observable (la interfcie)seria el mateix.

Exemple d'encapsulament

A la figura segent tenim dues possibles implementacions per a una mateixa interfcie.En tots dos casos, els atributs pblics sn els mateixos (Nom, Telfon, Antiguitat) per escalcularien de manera diferent a partir de conjunts d'atributs privats diferents.

Vegeu tamb

Veurem el concepte de sub-classe en l'apartat 4 d'aquestmdul.


Encapsulament


4. Herncia i polimorfisme

4.1. Herncia

Fins ara noms hem tingut en compte un nivell de classificaci (un objectepertany a una classe) per, de la mateixa manera que la classificaci ens per-met simplificar la descripci que fem d'un objecte agrupant els objectes enclasses, de vegades podem simplificar la descripci d'una classe identificantresponsabilitats comunes entre les instncies de diferents classes.

Classificaci dels ssers vius

Podem considerar el cas de la classificaci dels ssers vius. Una abella qualsevol podria serun exemplar d'abella europea (Apis mellifera). Per a l'hora de descriure com s l'abella,sabem que t caracterstiques comunes amb altres ssers vius que no sn abelles (elsaltres insectes) que, al seu temps, comparteixen caracterstiques amb altres ssers viusque no sn necessriament insectes (com els artrpodes), que al seu temps comparteixencaracterstiques amb la resta d'animals.

Classificaci de l'abella europea

Aquest tipus de classificaci jerrquica el podem reproduir en un siste-ma orientat a objectes mitjanant el mecanisme d'herncia entre clas-ses.

Diem que una classe (subclasse) hereta la definici d'una altra classe (super-classe) quan volem reutilitzar la definici de la superclasse de manera queaquesta s'apliqui tamb a les instncies de la subclasse. Aquest mecanisme enspermet, a l'hora de definir una subclasse, indicar noms aquelles caracters-tiques que en sn especfiques, mentre que les que sn comunes amb altressubclasses de la mateixa superclasse, diem que les hereta.

Tornant a l'exemple de les abelles, quan estem definint la classe abella, no cal que indi-quem que t tres parells de potes sin que en tenim prou de dir que s una subclassed'insecte (i, per tant, la classe abella hereta aquesta caracterstica). Si modifiquem la defi-nici de la classe insecte i afegim que t dues antenes, automticament totes les subclassesd'insecte (entre elles, abella) passen a heretar aquesta nova caracterstica.


Relacions is-a i is-like-a

La relaci d'herncia es coneix tamb com a relaci is-a (s-un), ja que les instncies dela subclasse sn tamb de la superclasse (una abella is-a un insecte). De vegades, per,ens pot interessar que la subclasse afegeixi caracterstiques que no sn aplicables a lasuperclasse (per exemple, una bomba de calor s com un aparell d'aire condicionat perque en comptes de noms refredar tamb pot donar calor). En aquests casos, la relaciseria is-like-a (s-com-un) i hi ha certa controvrsia sobre si aquest s o no un s correctede l'herncia.

La relaci d'herncia no s'ha de limitar necessriament a un sol nivell ni a duessubclasses noms, sin que podem arribar a tenir classificacions arbitrriamentcomplexes.

4.1.1. Generalitzaci i especialitzaci

Hi ha dos processos que ens permeten identificar fcilment les relacionsd'herncia al nostre domini: la generalitzaci i l'especialitzaci. El procs degeneralitzaci consisteix a trobar classes ms generals a partir de les que ja te-nim, mentre que l'especialitzaci consisteix a trobar classes ms especfiquesa partir de les que ja tenim.

La generalitzaci s un procs que es du a terme en dues etapes: el primer pass identificar responsabilitats comunes a dues o ms classes.

Exemple de primera etapa de la generalitzaci

A la universitat tenim instncies d'Estudiant, de les quals sabem que tenen un nom, unscognoms, una edat i que estan matriculats d'un nombre concret de crdits. Tamb teniminstncies de Professor, de les quals sabem que tenen un nom, uns cognoms, una edat iuna antiguitat a la universitat. Podem veure, doncs, que els estudiants i els professors, sib no sn la mateixa classe (per exemple, cap professor no est matriculat de crdits nisabem l'antiguitat de cap estudiant), s que comparteixen algunes caracterstiques (nom,cognoms i edat).

El segon pas de la generalitzaci consisteix a crear una nova classe i crear unarelaci d'herncia entre les classes que tenem i la classe que hem afegit.

Al nostre exemple, afegirem una classe Persona i farem que, tant Estudiant com Profes-sor, fossin subclasses de Persona.

L'especialitzaci s el procs simtric a l'anterior: primer identifiquem un sub-conjunt de les instncies d'una classe que comparteixen alguna caractersticacomuna (per exemple, hi ha un subconjunt de persones que es poden matri-cular d'assignatures, mentre que la resta no ho poden fer) i desprs creem unasubclasse nova que inclou aquest conjunt d'instncies i afegeix a la seva defi-nici la caracterstica que els s especfica.

Si estudissim el ADN de les abelles europees, veurem que no sn totes iguals, sin quehi ha diversos grups, com ara el grup afric, el mediterrani o el de l'Orient Mitj. Enaquest cas, a partir de la classe abella europea, anirem creant subclasses per especialitzacia mesura que anssim descobrint els diferents grups.


4.2. Polimorfisme

En el cas de les abelles, un mateix espcimen el podem veure com una abella(per exemple, si no hi entenem gaire) o com una abella europea del grup afri-c (si, per exemple, estigussim interessats a estudiar la distribuci geogrficadels diferents grups). Aix s molt til perqu ens permet treballar a diferentsnivells d'abstracci segons quin sigui el nostre inters en els detalls.

El polimorfisme s la capacitat d'un objecte de presentar-se amb formesdiferents (interfcies diferents) segons el context.

A l'exemple anterior, l'espcimen es presenta amb forma (o interfcie) d'abella per al'observador no expert mentre que, per a l'observador expert, es presenta en formad'abella europea del grup afric.

Polimorfisme

s important veure, per, que l'espcimen (l'individu, la instncia) s el mateixen tots dos casos i que, per tant, el polimorfisme est relacionat amb la visique els altres objectes tenen de l'objecte ms que no pas amb l'objecte en si,que sempre pertany a la classe ms concreta de la jerarquia, encara que algunsobservadors no ho vegin.

A l'exemple anterior, encara que l'observador no expert noms vegi una abella, l'abellaque est veient sempre s una abella europea del grup afric.

Exemple de polimorfisme

Si volem saber el nom d'una persona que participa al campus virtual de la UOC, ens sigual saber si s un consultor o un estudiant i, per tant, farem servir la interfcie de personaindependentment del tipus concret de persona que sigui. En canvi, si volem saber si lapersona est matriculada d'una assignatura, hem de tenir en compte el tipus de personaque s, ja que els consultors no es matriculen i, per tant, la pregunta noms t sentit perals estudiants (i hem de fer servir la interfcie d'estudiant).

El polimorfisme afecta tant les dades com el comportament, i permet que lessubclasses redefineixin algunes operacions per tal de comportar-se de maneradiferent de la resta d'instncies (s el que anomenem operacions polimrfiques).


Una operacipolimrfica s una operaci que t un comportamentdiferent en funci de la classe concreta a la qual pertanyi un objecte.

Per exemple, hi ha grups d'abelles que sn ms agressius que altres i que, per tant, res-pondran de manera diferent al mateix estmul. En aquest cas, podem dir que la classeabella defineix l'operaci molestar amb el comportament fugir per que hi ha una sub-classe que la redefineix amb el comportament atacar; diem que l'operaci molestar spolimrfica perqu si molestem una abella el seu comportament ser diferent segons eltipus concret d'abella que sigui (podria fugir si s una de les normals o atacar-nos si suna de les agressives).

4.2.1. Classes abstractes i redefinici del comportament

En una classificaci jerrquica com les que estem proposant, podria passar queuna superclasse no tingus cap instncia que no pertanys a una subclasse (perexemple, la classe abella no t cap instncia que no sigui d'alguna subclassecom ara l'abella europea).

Anomenem classesabstractes les classes que no es poden instanciardirectament; aquestes classes s'han d'instanciar per mitj de les sevessubclasses.

A l'exemple anterior, si volem una instncia d'abella, hem de decidir de quinsubtipus d'abella ha de ser.

Les classes abstractes poden definir tant dades com comportament que here-taran les seves subclasses. Una caracterstica, per, especfica de les classes abs-tractes, s que poden definir operacionsabstractes.

Una operaciabstracta s una operaci que no t associat un mtode(s a dir, no s'ha definit un comportament) en la classe en qu es defi-neix.

Aix obliga les subclasses a definir un mtode (comportament) per a aquellaoperaci o a ser igualment abstractes i deixar que siguin les seves subclassesles que defineixin el comportament.

Exemple d'operaci abstracta

Si tornem a l'exemple de les aixetes, podem considerar que tenim una classe abstractaAixeta i dues subclasses, Aixeta de palanca i Aixeta termosttica. En aquest cas, la classeAixeta pot oferir una operaci anomenada tancar, que tancar l'aixeta i far que en deixide brollar aigua.

El comportament d'aquesta operaci, per, ser diferent en funci del tipus concretd'aixeta. En aquest exemple, l'operaci tancar de la classe Aixeta s abstracta perqu nodefineix cap implementaci definida i les subclasses Aixeta de palanca i Aixeta termostticala implementen de manera diferent (cadascuna definint el seu comportament propi).


4.2.2. Associacions polimrfiques

Les associacions ens permeten donar una nova utilitat al polimorfisme: po-dem tenir associacions amb una superclasse de manera que no ens hem depreocupar de la subclasse concreta dels objectes que tenim associats.

Exemple d'associaci polimrfica

Un aula del campus virtual pot tenir una llista de persones participants, per a les qualsno necessita saber si sn estudiants o professors, sin noms saber si sn persones, siparticipen a l'aula i quin s el seu nom.

Associaci polimrfica

Aquest s del polimorfisme, a ms, ens ajudar a evolucionar el sistema si,en un futur, descobrim altres tipus de persones (sempre que aquestes tambtinguin nom i puguin rebre missatges).


5. Cas prctic: un frum virtual

A continuaci aplicarem els principis i les tcniques vistos anteriorment a undomini molt petit per prou representatiu: un sistema de frums virtuals enqu els usuaris envien missatges a un frum i poden llegir els missatges quehan enviat els altres usuaris.

s molt important, per, abans d'aplicar el qu hem vist, que considerem qui-na s la finalitat de la tasca que estem duent a terme. Com hem dit amb an-terioritat, el paradigma de l'orientaci a objectes es pot aplicar en mbits di-ferents, com ara la descripci del domini durant l'anlisi o b la implementa-ci del programari del sistema. En aquest exemple ens centrarem en l's del'orientaci a objectes com a tcnica per a la descripci del domini del proble-ma i, per tant, el nostre objectiu s identificar les classes del domini i no pas lesclasses de programari que formaran part de la soluci. Per tant, veurem classescom Missatge o Frum per no pas BaseDeDadesDeMissatges.

5.1. Classificaci dels objectes

Comenarem identificant les classes i els atributs dels objectes. En aquest pri-mer pas crearem les abstraccions bsiques del nostre sistema i descartarem totsels detalls que no considerem rellevants.

5.1.1. Classes

En aquest cas, fent un exercici d'abstracci, podem identificar fcilment tresclasses ben diferenciades: Usuari, Missatge i Frum. Usuaris sn aquelles perso-nes que fan servir el sistema, missatges sn el que s'envien els usuaris, i elsfrums serveixen per a agrupar els missatges.

Tots els objectes que tinguem al domini pertanyeran a alguna d'aquestes tresclasses i, per tant, no considerarem cap classe ms si no s que incorporemms informaci que la que tenim actualment.

Classes

Observaci

El model del domini que femdurant l'anlisi fa servir els ob-jectes per a representar con-ceptes del mn real i, per tant,no ens interessa identificar-hioperacions ni assignar-los m-todes, ja que aquestes tasqueses faran durant el disseny i im-plementaci del sistema.


5.1.2. Atributs

Per a determinar els atributs de les diferents classes, hem de determinar quinsdetalls sn rellevants per al nostre sistema de les instncies de cada classe.

Dels usuaris podrem conixer molta informaci (el nom, l'edat, les seves afi-cions, el color dels ulls, on treballen, si els agrada l'pera, etc.), per moltad'aquesta informaci no s rellevant per al sistema que estem desenvolupanti, per tant, no l'hem de considerar com a atributs de la classe.

En canvi, segur que necessitarem una manera d'identificar els usuaris (perexemple, fent servir un nom que podria ser el seu nom real o un lies) per talde poder saber qui ha creat un missatge i, de la mateixa manera, necessitarempoder determinar que un usuari s qui diu ser (per exemple, mitjanant unmot de pas); en aquest cas, doncs, direm que la classe Usuari t dos atributs:nomUsuari (el que fa servir per a autenticar-se al sistema) i motDePas (la con-trasenya).

Altres detalls de l'usuari, com ara el nom, els cognoms i l'edat, podrien seratributs o no segons els considerem rellevants per al sistema que estem descri-vint. Per simplificar l'exemple, els considerarem no rellevants i, per tant, noels convertirem en atributs.

Dels missatges tamb en podrem saber tot de coses com ara la longitud delcontingut, si s interessant o s avorrit, etc., per ens quedarem amb dos atri-buts que considerem rellevants: ttol i contingut.

Finalment, dels frums ens interessar saber-ne el nom (per poder-los distingirdels altres).

Per tant, tenim les classes i atributs segents:

Classes i atributs

5.2. Herncia

En aquest cas no s possible generalitzar cap de les classes identificades, jaque representen conceptes molt diferents entre si. En canvi, podria passar queuna anlisi ms a fons de la funcionalitat ens ports a pensar que alguns delsusuaris tenen permisos especials i poden esborrar els missatges d'altres usuaris.


Com que no tots els usuaris tenen aquest perms especial, podrem identificarun subconjunt d'Usuaris que anomenarem Moderadors, que sn aquells quepoden esborrar missatges d'altres usuaris.

En aquest cas, doncs, haurem afegit una classe nova per especialitzaci:

Especialitzaci de Moderador

5.3. Associacions

Pel qu fa a les associacions, podrem identificar una associaci entre Usuarii Missatge, en qu Usuari t el rol d'autor i Missatge el de missatge, i on des-arem quin usuari s l'autor d'un missatge. Tamb necessitarem saber a quinfrum pertany un missatge (anomenarem pertany aquesta associaci i missatgei frum, els rols del missatge i del frum, respectivament).

Alguns missatges poden ser respostes a missatges anteriors. Aquesta associacis una associaci recursiva, ja que associa dues instncies de la mateixa classe(Missatge): una t el rol de missatge original i l'altra t el rol de resposta.

Finalment, tamb ens interessar saber qui s el moderador d'un frum enconcret. En aquest cas, en comptes d'associar Frum i Usuari associarem F-rum i Moderador, ja que sabem que noms el subconjunt d'usuaris que snmoderadors estan capacitats per a moderar un frum.


Associacions


Resum

Hem vist com una eina que es va crear com a mecanisme d'abstracci per alsllenguatges de programaci ens permet simplificar la descripci de qualsevolsistema del mn real. Per tant, hem de veure l'orientaci a objectes no sola-ment com un paradigma de programaci, sin com un paradigma d'anlisique podem aplicar al mn real.

L'orientaci a objectes ens proporciona una manera d'abstraure les caracters-tiques importants de les entitats que formen el nostre domini, classificar-lesde manera que en puguem maximitzar la reutilitzaci i que puguem variar elnivell d'abstracci al qual treballem i, al mateix temps, establir relacions entreaquestes mitjanant associacions.

Hem vist com podem classificar els objectes en classes i fer abstracci dels as-pectes rellevants a l'hora de descriure les classes mitjanant les diferents res-ponsabilitats que es traduiran en atributs, associacions i operacions.

Tamb hem vist com l'encapsulament ens permet establir la visibilitat de ca-dascuna de les responsabilitats i ocultar, aix, els detalls d'implementaci a laresta de classes.

Finalment, l'herncia ens permet establir jerarquies de classe de tal maneraque puguem descriure els trets comuns a diverses classes en una classe msgeneral, mentre que el polimorfisme ens permet veure un mateix objecte comd'una o altra classe de la jerarquia en funci del context.

Un model orientat a objectes del nostre domini ens facilitar, ms endavant,la creaci de classes de programari que reflecteixin aquest domini, al mateixtemps que ens pot ajudar a la creaci d'altres models (com ara l'estructura dela base de dades) mantenint, al mateix temps, la possibilitat de fer-lo servir pera comunicar-nos amb les persones expertes en el domini sense necessitat quesiguin expertes en programaci orientada a objectes.


Activitats

1. A l'exemple del subapartat 2.3.1 hem dit que el telfon s un atribut de tipus String. Perqu no l'hem indicat com de tipus numric?

2. Estem fent l'anlisi orientada a objectes per a un sistema de comer electrnic. L'empresavendr una srie de productes dels quals tindrem un nom, la marca comercial, una descripci,una fotografia i el preu. Alguns productes sn electrnics, en el sentit que sn documentsbinaris que es poden descarregar i no objectes fsics que cal enviar; per a aquests, tamb volemtenir-ne el fitxer i el format, que pot ser msica, llibre o pellcula. Cada producte podrpertnyer a una o ms categories, cadascuna de les quals tindr un nom i una descripci.

Els usuaris tindran un nom d'usuari, una contrasenya i una adrea i faran compres de lesquals desarem la data i el conjunt de productes comprats. D'un mateix producte, en unacompra, se'n podran comprar una o ms unitats. No tindrem en compte el pagament.

Feu una llista de les classes que podem trobar en aquest domini. Per a cada classe, indiqueu els atributs que t, el tipus de cada atribut i quin s el seu

nombre possible de valors. Identifiqueu les associacions entre classes. Per a cada una indiqueu els noms dels rols i,

si n'hi ha, els atributs que tingui la classe associativa. Identifiqueu les relacions d'herncia entre classes i quines classes creieu que sn abstrac-

tes.

3. Tenim un sistema orientat a objectes amb les classes Vehicle, Cotxe, Moto i Conductor. Laclasse Vehicle, que s abstracta, t l'atribut pblic matrcula, l'atribut protegit marca i l'atributprivat model. Cotxe i Moto sn subclasses de la classe Vehicle.

a) Quins atributs de Vehicle sn visibles des de la classe Vehicle?

b) I des de la classe Cotxe?

c) I des de Persona?

4. Tenim un sistema orientat a objectes amb les classes Be, BeImmoble (que s subclasse de Be)i Contribuent. Entre Contribuent i Be hi ha una associaci, de tal manera que un contribuentt qualsevol nombre de bns, cadascun dels quals pertany a un o ms contribuents. Be tl'atribut valor, mentre que BeImmoble t un atribut referenciaCatastral. Be t una operacicalcularImpostos que calcula d'impost per aplicar als contribuents que tenen el b associat.BeImmoble redefineix l'operaci calcularImpostos i, a ms, t una operaci prpia anomenadahipotecar, amb diversos parmetres.

a) Pot passar que un contribuent tingui associat un b immoble?

b) Un contribuent podria demanar l'operaci hipotecar sobre tots els seus bns associats?

c) Segons aquest esquema, els bns immobles tenen valor?

d) Els bns tenen referncia catastral?

5. Suposeu que tenim el mateix sistema orientat a objectes de l'exercici anterior. Ara, per,sabem que l'atribut valor de la classe Be s privat. I ara, els bns immobles tenen valor? Desde la classe BeImmoble es pot accedir a l'atribut valor?

Exercicis d'autoavaluaci

1. Quina s la diferncia fonamental entre els llenguatges de programaci procedimentals iels orientats a objectes pel que fa a l'abstracci?

2. Quina relaci hi ha entre l'anlisi orientada a objectes i la programaci orientada a objec-tes?

3. En orientaci a objectes, amb quin criteri agrupa objectes el mecanisme de classificaci?

4. Quins tipus de responsabilitats poden tenir els objectes?

5. Quin mecanisme de l'orientaci a objectes ens permet descartar trets caracterstics delsobjectes que no siguin rellevants al problema que volem resoldre?


6. Quin element de la classe ens indica la informaci que coneixem de les seves instncies?

7. Quina informaci coneixem dels atributs d'una classe, a ms del nom?

8. Qu vol dir que la relaci d'associaci sigui recproca?

9. Pot existir una associaci d'una classe amb si mateixa? En tal cas, com distingim unainstncia d'una altra entre dues que estan relacionades?

10. En orientaci a objectes, com modelitzem les tasques que poden portar a terme els ob-jectes?

11. Quina relaci hi ha entre operacions, mtodes, interfcie i implementaci?

12. Quina altra metfora es fa servir en orientaci a objectes per a fer referncia a la invocacio crida d'una operaci?

13. Quina relaci hi ha entre l'encapsulament i l'ocultaci de la informaci?

14. Quines visibilitats podem definir per a atributs i operacions en un sistema orientat aobjectes?

15. Quin mecanisme de classificaci ens permet simplificar la descripci de les classes?

16. Com podem identificar relacions d'herncia en domini?

17. Quin mecanisme ens permet treballar amb un objecte en diversos nivells d'abstraccisegons les nostres necessitats?

18. Qu s una classe abstracta?

19. Una classe que no s abstracta pot tenir operacions abstractes? Per qu?

20. Una classe abstracta pot tenir operacions que no ho siguin? Per qu?

21. Quina relaci hi pot haver entre el concepte d'associaci i el de polimorfisme?

22. Com podem solucionar, en orientaci a objectes, el cas en qu una associaci t infor-maci addicional que no depn d'una de les instncies relacionades, sin de totes?


Solucionari

Activitats

1. Els telfons sn cadenes de carcters que, aparentment, noms poden contenir nombres,per no sn nombres en el sentit que no els percebem com a tals i no els fem servir com atals en cap moment. Aix, per exemple, alguns trets que els distingeixen dels nombres sn:

No s el mateix el telfon 003 que el 3, tot i que s que sn el mateix nombre. Els telfons no admeten cap de les operacions habituals dels nombres. Mai no sumem,

restem, multipliquem, dividim, etc. telfons, tot i que s que ho fem amb els nombres. Alguns carcters no numrics poden formar part d'un nmero de telfon. Com a mnim

el carcter + que podem fer servir per a senyalitzar el prefix internacional d'un nmerode telfon, i que realment es marca en marcar el nmero.

2. Classes que podem trobar i atributs:

Producte: nom:String, marcaComercial:String, descripcio:String, fotografia:Imatge,preu:Import

Producte electrnic: fitxer:Fitxer, format:Format Categoria: nom:String, descripcio:String Usuari: nomUsuari:String, contrassenya:String, adrea:Adrea Compra: data:Data

Associacions:

PertanyA: cada producte (amb nom de rol productes) pertany a una o ms categories (ambnom de rol categories).

Fa: cada usuari (nom de rol usuari) fa un seguit de compres (nom de rol compres). Inclou: una compra (nom de rol compra) inclou un seguit de productes (nom de rol pro-

ductes). Aquesta s una classe associativa amb l'atribut numUnitats:nat.

Hi ha una relaci d'herncia entre Producte i Producte electrnic, de tal manera que Producteelectrnic s una subclasse de Producte. Producte, per, no s una classe abstracta, ja que hiha productes que no sn electrnics.

3.

a) Totsb) Matrcula i marca, ja que marca s protegit i s visible des de les subclasses per model s

privat i no s visible des de cap altra classe que no sigui Vehicle.c) Matrcula, ja que marca i model no sn pblics.

4.

a) S. Un contribuent pot tenir associat qualsevol nombre de bns i els bns immobles tambsn bns.

b) No, ja que els bns que no sn immobles no es poden hipotecar; s a dir, l'operaci nomsest definida per a la classe BeImmoble i, per tant, noms es pot invocar sobre instnciesd'aquesta classe.

c) S. Tot b immoble s un b i, per tant, com tots els bns, t un valor. Vist des del puntde vista de l'herncia, la classe BeImmoble hereta l'atribut valor de la classe Be.

d) En general, no. Noms aquells bns que siguin immobles tindran referncia cadastral.Per tots els altres no en tindran.

5. La visibilitat d'un atribut no en canvia el comportament pel que fa a l'herncia. Per tant,si valor s un atribut privat, tots els bns continuaran tenint valor, incloent-hi els bns im-mobles. Ara b, com que l'atribut valor s ara privat, encara que els bns immobles tamb entinguin, no hi podem accedir des de la classe BeImmoble.

Exercicisd'autoavaluaci

1. Els llenguatges de programaci procedimentals fan una abstracci del que la mquina potentendre, mentre que els llenguatges de programaci orientats a objectes fan una abstraccid'all que les persones volen comunicar. (Vegeu el subapartat 1.2.)

2. L'anlisi orientada a objectes consisteix a aplicar els conceptes i idees dels llenguatges deprogramaci orientats a objectes a l'anlisi de sistemes. Per tant, l'anlisi orientada a objectesfa servir el mateix paradigma, l'orientaci a objectes, que la programaci orientada a objectes.(Vegeu el subapartat 1.3.)


3. El criteri pel qual la classificaci agrupa objectes en classes s el conjunt de responsabilitatsen com que tenen aquests objectes. Aix, tots els objectes d'una mateixa classe tenen unesmateixes responsabilitats. (Vegeu el subapartat 2.1.)

4. Un objecte pot tenir responsabilitats de dades (coses que ha de saber), associacions (altresobjectes que coneix) i comportament (tasques que se li poden demanar). (Vegeu el subapartat2.1.)

5. L'abstracci. s el mecanisme mitjanant el qual decidim quines de les possibles respon-sabilitats associades a una classe formaran part de la seva definici. (Vegeu el subapartat 2.2.)

6. Els atributs. (Vegeu el subapartat 2.3.1.)

7. Els atributs solen tenir un tipus, que ens ajuda a entendre el tipus d'informaci que s'hiemmagatzema, un mbit (que pot ser d'instncia o de classe) i un nombre de valors (pot sero no opcional i pot ser o no multivaluat). (Vegeu el subapartat 2.3.1.)

8. Vol dir que si una instncia a1 d'una classe A est associada amb una instncia b1 de laclasse B, la instncia b1 estar tamb associada a la instncia a1. (Vegeu el subapartat 2.3.2.)

9. Si, i s'anomena associaci recursiva. Per a distingir el rol que t cada instncia de l'associacifem servir els rols d'associaci. (Vegeu l'apartat 2.3.2.)

10. Mitjanant operacions. (Vegeu el subapartat 2.3.3.)

11. Les operacions indiquen quines tasques pot dur a terme un objecte i formen la interfciede l'objecte. Cada mtode s el conjunt d'instruccions que indica com un objecte du a termeuna tasca (una operaci) i forma la implementaci de l'objecte. (Vegeu el subapartat 2.3.3.)

12. Tamb es fa servir la metfora de l'enviament d'un missatge. Quan un objecte invoca ocrida una operaci d'un altre objecte tamb podem dir que li envia un missatge. (Vegeu elsubapartat 2.3.3.)

13. L'encapsulament s el mecanisme de l'orientaci a objectes que ens permet ocultar in-formaci.

14. Visibilitat pblica (qualsevol objecte hi t accs), privada (noms els objectes de la ma-teixa classe), protegida (noms els objectes de la mateixa classe o d'alguna subclasse) i depaquet (noms els objectes del mateix grup o "paquet"). (Vegeu el subapartat 3.2.)

15. L'herncia. Ens permet simplificar la descripci d'una classe identificant responsabilitatscomunes entre les instncies de diferents classes i evitant haver-les de descriure en ms d'unaclasse. (Vegeu l'apartat 4.1.)

16. Mitjanant la generalitzaci (trobem classes ms generals a partir de les que ja tenim)o l'especialitzaci (trobem classes ms especfiques a partir de les que ja tenim). (Vegeu elsubapartat 4.1.1.)

17. El polimorfisme. s la capacitat de treballar amb un objecte amb formes diferents (inter-fcies diferents) segons les nostres necessitats. (Vegeu el subapartat 4.2.)

18. Una classe abstracta s una classe que no podem instanciar directament; s a dir, nomspodem crear instncies d'alguna de les seves subclasses. (Vegeu el subapartat 4.2.1.)

19. Una classe no abstacta no pot tenir operacions abstractes, perqu, per a aquestes, el com-portament (el mtode) s'ha de definir en les subclasses. Per tant, els objectes de la classe notindran cap comportament associat, tret que pertanyin a una subclasse. Per aix, per fora,haurien de pertnyer a una subclasse; s a dir, la classe hauria de ser abstracta. (Vegeu elsubapartat 4.2.1.)

20. Una classe abstracta pot tenir operacions que no ho siguin. Senzillament, les seves sub-classes heretaran les operacions amb el seu comportament i el podran redefinir o deixar-lotal qual. (Vegeu el subapartat 4.2.1.)

21. Podem tenir associacions polimrfiques: Una associaci polimrfica s una associaciamb una classe que t subclasses. En aquest cas, un objecte pot tenir associats, per una matei-xa associaci, objectes de la classe associada i de les seves subclasses. Per tant, tindr associatsobjectes de diverses classes (amb una superclasse en com). (Vegeu el subapartat 4.2.2.)

22. Fem servir una classe associativa, s a dir, una classe les instncies de la qual sn instnciesde l'associaci. (Vegeu l'apartat 2.3.2.)


Glossari

abstracci f L'acte de reunir les qualitats essencials o generals de coses similars. Tamb,les caracterstiques essencials provinents d'una cosa.

abstracta (classe) f Classe que no es pot instanciar directament, sin que noms es podeninstanciar les subclasses no abstractes que tingui.

abstracta (operaci) f Operaci que no t associat un mtode; s a dir, per a la qual nos'ha definit un comportament.

mbit (d'un atribut) m Caracterstica que distingeix si un atribut emmagatzema un valordiferent per a cada instncia (mbit d'instncia) o b un mateix valor per a totes les instnciesd'una classe (mbit de classe).

anlisi orientada a objectes f Aplicaci dels conceptes i idees dels llenguatges orientatsa objectes a l'anlisi de sistemes.

associaci f Relaci estructural entre dues (o ms) classes que ens indica quins objectes dela segona classe coneixen els objectes de la primera. Una associaci, per tant, constitueix unaresponsabilitat de cada una de les classes implicades.

associaci polimrfica f Vegeu polimrfica (associaci)

associaci recursiva f Associaci que connecta una classe amb ella mateixa.

atribut m Element estructural d'una classe que indica quina informaci tenen les instn-cies d'aquella classe; s una de les responsabilitats, per tant, de la classe.

caixa blanca f Tipus de descripci d'un objecte en qu es descriu, a ms de qualsevolaspecte extern de l'objecte, la seva estructura i funcionament interns.

caixa negra f Tipus de descripci d'un objecte en qu es descriu el seu funcionament desd'un punt de vista extern, sense explicar-ne l'estructura ni el funcionament interns.

classe abstracta f Vegeu abstracta (classe)

classe associativa f Classe de la qual les instncies sn instncies d'una associaci; s adir, cada instncia d'una classe associativa representa una instncia d'una associaci en elsentit que est formada pel parell (en el cas d'associacions binaries) d'instncies associades,a ms de tenir els atributs, associacions i operacions propis.

classe (d'objectes) f Descriptor d'un conjunt d'objectes que comparteixen els mateixosatributs, associacions, operacions i mtodes.

classificaci f Mecanisme d'identificar classes d'objectes com a descriptores de conjuntsd'objectes amb les mateixes responsabilitats.

codi mquina m Codi format pel conjunt d'instruccions que els processadors (en general,el maquinari) poden entendre i executar.

cridar f Vegeu invocar.

de paquet (visibilitat) Visibilitat d'un atribut, associaci o operaci tal que noms svisible pels objectes del mateix grup o paquet.

encapsulament m Mecanisme de l'orientaci a objectes que ens permet ocultar informa-ci definint quins atributs, operacions i associacions d'un objecte sn visibles i quins restenocults.

especialitzaci f Procs d'identificaci d'una subclasse d'una classe existent que serveixper a descriure les responsabilitats comunes a un subconjunt de les instncies de la classeoriginal, per no a totes.

generalitzaci f Procs d'identificaci d'una superclasse de dues o ms classes ja existentsque serveix per a descriure les responsabilitats comunes a les classes ja identificades inicial-ment.

herncia f Caracterstica de l'orientaci a objectes mitjanant la qual podem identificaruna relaci entre una superclasse i una subclasse tal que totes les instncies de la subclasseho sn tamb de la superclasse. Diem que la subclasse hereta la definici de la superclasse,


de tal manera que per a definir la subclasse noms ens cal indicar aquelles caracterstiquesque li sn especfiques que no sn presents a la superclasse.

implementaci (d'una classe) f Comportament intern de les instncies d'una classe quequeda definit pel conjunt de mtodes de la classe. La implementaci queda oculta darrerela interfcie.

instncia f Vegeu objecte.

interfcie f Conjunt d'operacions ofertes per les instncies d'una classe i que, per tant,sn invocables per altres objectes. La interfcie no inclou, per, la implementaci, que estformada pels mtodes que implementen aquestes operacions.

invocar v Demanar a un objecte l'execuci del seu comportament per a una determinadaoperaci.

llenguatge assemblador m Llenguatge de programaci en qu les instruccions es cor-responen prcticament una a una amb les operacions que pot entendre el processador. Estradueix a codi mquina per a ser executat.

llenguatge de programaci m Llenguatge artificial que est dissenyat per a expressarels cmputs que volem que dugui a terme un ordinador.

llenguatge de programaci d'alt nivell m Llenguatge de programaci ms ric que elllenguatge assemblador, ja que permet expressar les instruccions amb un nivell d'abstraccims alt.

llenguatge de programaci orientat a objectes m Llenguatge de programaci d'altnivell que eleva el nivell d'abstracci creant una abstracci del problema que es vol resoldrefent servir el paradigma de l'orientaci a objectes. Vegeu orientaci a objectes.

llenguatge natural m Llenguatge que fem servir les persones per a comunicar-nos entrenosaltres (com ara el catal o l'angls), per oposici als llenguatges que fem servir per a co-municar-nos amb els ordinadors (com ara els llenguatges de programaci).

llenguatge procedimental m Llenguatge de programaci d'alt nivell que eleva el nivelld'abstracci creant una abstracci de la mquina sobre la qual s'executen. Permet fer servir unjoc d'instruccions ms abstractes que les que el processador s directament capa d'executar.

llenguatge unificat de modelitzaci m Vegeu universal modeling language

mtode m Conjunt d'instruccions que, per a una operaci, en una classe, indica com escomportaran els objectes d'aquella classe. El conjunt dels mtodes de la classe en forma laimplementaci.

missatge (orientaci a objectes) m Metfora que representa una crida o invocaci d'unaoperaci d'un objecte. Sota aquesta metfora diem que l'objecte que fa la crida (el que demanal'execuci de l'operaci) envia un missatge a l'objecte que rep la crida (el que ha d'executarel seu comportament per a aquella operaci).

multivaluat (atribut) m Atribut que, per a una determinada instncia, pot tenir msd'un valor en lloc d'haver-ne de tenir noms un. Antnim d'univaluat.

objecte m Cada un dels elements autnoms que forma un sistema orientat a objectes

obligatori (atribut) m Atribut tal que totes les instncies de la classe hi han de tenirvalor. Antnim d'opcional.

ocultaci d'informaci f Capacitat de fer que cada element d'un sistema contingui certainformaci que s'amaga a la resta d'elements, mostrant-los una visi simplificada. En el cas deles classes d'un sistema orientat a objectes, l'encapsulament permet indicar quins elementssn visibles i ocultar la resta.

opcional (atribut) m Atribut que, per a una determinada instncia, pot no tenir valor. Siun atribut no s opcional, aleshores ha de tenir valor per a totes les instncies de la classe.Antnim d'obligatori.

operaci f Especificaci d'una tasca que poden dur a terme totes les instncies d'una classe.L'operaci es pot demanar mitjanant la crida o invocaci i el comportament de la instnciaque rebi la crida es defineix en un mtode. s, per tant, una de les responsabilitats de la classe.


operaci abstracta f Vegeu abstracta (operaci)

operaci polimrfica f Vegeu polimrfica (operaci)

orientaci a objectes f Paradigma consistent a descompondre un sistema complex en unconjunt d'elements autnoms (els objectes) que es comuniquen els uns amb els altres per talde dur a terme les seves tasques.

paquet m Agrupaci d'elements en un sistema orientat a objectes per a facilitar-nel'organitzaci. Un paquet pot contenir classes i altres paquets i pot resultar til per a definirla visibilitat de paquet dels atributs, associacions i operacions de les classes que cont.

polimrfica (associaci) f Associaci en qu una (o ms) de les classes que hi participent subclasses, de tal manera que un objecte pot tenir associats, per la mateixa associaci,objectes pertanyents a diferents classes (sempre que pertanyin a la jerarquia d'herncia dela classe associada).

polimrfica (operaci) f Operaci que t un mtode associat en una classe per que tun mtode diferent per a alguna de les subclasses de la classe. D'aquesta manera, les diferentsinstncies de la classe, en executar l'operaci, es comportaran de manera diferent en funcide si sn instncies noms de la classe o de quina subclasse siguin instncies.

polimorfisme m Capacitat d'un objecte de presentar-se amb formes diferents (interfciesdiferents) segons el context. Aix, un objecte que pertanyi a una classe qualsevol es pot veurecom a pertanyent a aquella classe, a la superclasse d'aquella, a la superclasse de la superclassed'aquella, etc.

protegida (visibilitat) f Visibilitat d'un atribut, associaci o operaci tal que noms svisible per la classe en qu est definida i les seves subclasses.

privada (visibilitat) f Visibilitat d'un atribut, associaci o operaci tal que noms svisible per la mateixa classe en qu est definida.

pblica (visibilitat) f Visibilitat d'un atribut, associaci o operaci tal que s visible pertots els objectes del sistema.

redefinir (una operaci) v Definir, per a una operaci d'una subclasse, un mtode (uncomportament) diferent del mtode que tenia associada aquella operaci a la superclasse. Enredefinir una operaci en una subclasse la convertim en una operaci polimrfica.

responsabilitat (d'un objecte) f Caracterstiques o obligacions d'una classe, que podenser informaci que les instncies han de conixer (atributs), altres instncies que han deconixer (associacions) o tasques que han de poder dur a terme (operacions).

rol m Extrem d'una associaci al qual s'assigna un nom per a indicar el seu propsit; s adir, per a indicar quin s el paper que hi tenen les instncies quan s'associen.

subclasse f En una relaci d'herncia entre dues classes, la classe que hereta les responsa-bilitats de l'altra classe; s, per tant, la classe ms especfica.

superclasse f En una relaci d'herncia entre dues classes, la classe de la qual s'hereten lesresponsabilitats; s, per tant, la classe ms genrica.

tipus (d'un atribut) m Descripci del conjunt de valors que pot prendre un atribut. Al-guns exemples de tipus d'atributs poden ser el tipus data (que defineix un conjunt de valorsque inclou 1/3/2011 o 31/3/1414), enter (com ara 14 o 356) o carcter (com ara "a" o "@").

unified modeling language mLlenguatge de modelitzaci de propsit general estandar-ditzat per l'OMG i utilitzat en el camp de l'enginyeria del programari.Sigla UML

univaluat (atribut) m Atribut tal que cap instncia de la classe no pot tenir ms d'unvalor en aquell atribut. Antnim de multivaluat.

visibilitat f Propietat d'un atribut, associaci o operaci que defineix quins objectes elpoden veure o veure-la. La visibilitat pot ser pblica, privada, protegida o de paquet.


Bibliografia

La bibliografia sobre orientaci a objectes est molt relacionada amb el mn de la progra-maci.

Meyer, Bertrand (2002). Construccin de software orientado a objetos. Madrid: Prentice Hall.

Aquest llibre s la referncia acadmica en orientaci a objectes i, per tant, s molt adequatper a l'estudi en profunditat dels diferents conceptes.

Bibliografia complementria

Moltes guies i llibres sobre programaci en un llenguatge orientat a objectes inclouen unasecci introductria sobre la programaci a objectes. A continuaci us en recomanem dos:

Eckel, Bruce (2006). Thining in Java. Prentice Hall.

Object Oriented Programming with Objective C (Apple Corp.) http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/OOP_ObjC/OOP_ObjC.pdf

Referncies bibliogrfiques

Parnas, David L. (1972). "On the Criteria to Be Used in Decomposing Systems Into Modu-les". Communications of the ACM.

Orientaci a objectesIntroducciObjectiusndex1. Qu s l'orientaci a objectes?1.1. Evoluci histrica dels llenguatges de programaci1.2. Els llenguatges de programaci orientats a objectes1.3. Anlisi orientada a objectes

2. Classificaci i abstracci2.1. Classificaci2.2. Abstracci2.3. Descripci de les classes d'objectes2.3.1. Atributs2.3.2. Associacions2.3.3. Operacions

3. Ocultaci d'informaci i encapsulament3.1. Ocultaci d'informaci3.2. Encapsulament

4. Herncia i polimorfisme4.1. Herncia4.1.1. Generalitzaci i especialitzaci

4.2. Polimorfisme4.2.1. Classes abstractes i redefinici del comportament4.2.2. Associacions polimrfiques

5. Cas prctic: un frum virtual5.1. Classificaci dels objectes5.1.1. Classes5.1.2. Atributs

5.2. Herncia5.3. Associacions

ResumActivitatsExercicis d'autoavaluaciSolucionariGlossariBibliografia

Documents

Mòdul 2 - Orientació a objectes