Diagrames estàtics

El llenguatge unificat de modelització (UML) es basa en diagrames que estableixen les especificacions i documentació de qualsevol sistema. Aquests diagrames es fan servir en el desenvolupament de projectes informàtics per analitzar i dissenyar les necessitats dels usuaris finals de les aplicacions, amb la qual cosa es documenten els seus requeriments. Però també es podran utilitzar en molts més àmbits, com ara la modelització del funcionament d’una empresa, d’un departament o d’un sistema de qualsevol altre entorn.

Els diagrames que es poden fer servir per modelitzar sistemes es poden agrupar o classificar de moltes formes. Una d’aquestes classificacions diferencia entre els diagrames que corresponen a l’UML estàtic i els que corresponen a l’UML dinàmic. Els diagrames inclosos en els considerats de UML estàtic, també anomenats diagrames d’estructura, fan referència als elements que s’hauran de trobar en el sistema de modelització. Aquests diagrames fan una descripció del sistema sense tenir en compte les interaccions amb altres elements o el comportament que tenen els elements del sistema, només identifiquen aquests models i estableixen les seves característiques.

Dins aquest tipus de diagrames, el més important és el diagrama de classes, que especificarà totes les classes estimades al disseny orientat a objectes i que seran instanciades al codi de programació que es desenvoluparà a continuació.

En les pàgines corresponents a aquest apartat es treballaran els diagrames corresponents a l’UML estàtic, fent especial referència al diagrama de classes. També es mostra un exemple de com poder treballar amb un IDE (Eclipse) amb els diagrames UML.

Anàlisi i disseny orientat a objectes

La creació d’una aplicació informàtica es pot considerar una obra d’enginyeria. De fet, fa molts anys que es coneix amb el nom enginyeria del programari (o enginyeria del software), considerat com una de les àrees més importants de la informàtica. L’enginyeria del programari engloba tota una sèrie de metodologies, tècniques i eines que faciliten la feina que comporten totes i cada una de les fases d’un projecte informàtic.

L’enginyeria del programari ha evolucionat de forma contínua (i ho continua fent a data d’avui), adaptant-se a les noves tecnologies i a les noves formes de desenvolupar programari. A la dècada dels 70, amb l’inici de la programació d’aplicacions com a feina generalitzada en les organitzacions, i l’aparició de la figura del programador, només hi havia un objectiu: que les aplicacions fessin el que havien de fer optimitzant la velocitat i l’ús de memòria. En aquells primers programes ningú no es preocupava pel futur manteniment de les aplicacions per part d’altres programadors, ni tampoc que el codi fos fàcil d’entendre.

Amb els anys, les aplicacions demanen més funcionalitats i el desenvolupament d’aplicacions es fa més complex a mesura que millora el maquinari i el programari que utilitzen els programadors. La programació passa a ser programació estructurada, implementada en mòduls i més senzilla d’entendre i de mantenir.

A mitjan-finals dels anys 70 comencen a aparèixer les primeres metodologies. El fet s’elaborar el codi de programació a partir de les improvisacions o de les intuïcions del programador, sotmet el projecte a uns riscos, com ara la poca eficàcia o els errors en les funcionalitats que han de solucionar els requeriments de les especificacions.

Aquestes metodologies recullen l’experiència de molts projectes, oferint una sèrie de passos a efectuar per al correcte i exitós desenvolupament de les aplicacions informàtiques. Entre aquests passos es troben les fases en què es divideix un projecte, entre les quals hi ha la fase de disseny.

El disseny estructurat, o també anomenat disseny orientat al flux de dades, permet establir la transició del Diagrama de Flux de Dades (DFD) a una descripció de l’estructura del programa, que es representa mitjançant un diagrama d’estructures. Les eines que faciliten i automatitzen aquest tipus de disseny es coneixen com a eines CASE. A la figura es pot observar un exemple de Diagrama de Flux de Dades.

Figura Exemple DFD

L’evolució en l’enginyeria del programari sorgeix a partir dels anys 80, quan comença a aparèixer la programació orientada a objectes. La forma de programar ja no es basarà en les estructures i en la programació modular, sinó que la base seran les classes i els objectes. Igual que hi ha una evolució en la programació, aquesta evolució també es veu reflectida en les metodologies de gestió de projectes. Al cap d’uns anys d’agafar força la programació orientada a objectes i de fer-se un lloc entre els desenvolupadors d’aplicacions, van aparèixer:

  • Modelització de sistemes orientats a objectes.
  • Disseny orientat a objectes.
  • Generació automàtica de Codi.
  • Metodologies àgils.

En l’actualitat existeixen diferents tipus de tecnologies que s’utilitzen en el desenvolupament de programari, i les més utilitzades són:

  • Metodologies estructurades.
  • Metodologies orientades a objectes.
  • Metodologies àgils.

Deixant la tercera de banda, en les altres dues (estructurades i orientades a objectes) es pot considerar que el procés de desenvolupament de programari té les mateixes fases. Segons diversos autors, pot haver-hi grans divergències entre les propostes de fases d’un projecte, però, en general, les proposades són aquestes:

  • Estudi previ, on es delimita l’àmbit del projecte de desenvolupament d’un programari i se’n determina la viabilitat, els riscos, els costos i el calendari.
  • Anàlisi de requeriments, on es descriuen de manera adient els requisits del programari, que són les necessitats d’informació que el programari ha de satisfer. L’anàlisi ha de deixar molt clar el que es vol fer a partir de l’estudi d’un problema determinat. Els requeriments que cal recollir hauran ser funcionals i no funcionals. Caldrà que sigui independent de la tecnologia i del tipus de programació escollits per al desenvolupament del projecte.
  • Disseny, on es projecta el programari amb vista a implementar-lo en un entorn tecnològic concret, definit per aspectes com ara el llenguatge de programació, l’entorn de desenvolupament i el gestor de bases de dades, de tots els quals en pot intervenir més d’un dins un sol projecte. A partir del que caldrà fer, definit a la fase anterior al disseny, es determina el com es farà. Caldrà tenir en compte les possibles conseqüències de les decisions presses en aquesta fase. El detall haurà de ser suficientment baix com perquè a partir d’aquestes indicacions es pugui desenvolupar el projecte.
  • Desenvolupament i proves, on es porta a terme el desenvolupament del codi font que satisfaci les funcionalitats establertes a les fases anteriors. Aquesta fase no només es limita a la codificació manual, sinó que pot incloure la programació gràfica, la generació automàtica de codi i altres tècniques. En aquesta fase també s’inclouran les proves del programari. Algunes parts de la programació poden començar abans que el disseny estigui enllestit del tot, i també es poden provar parts del programari mentre encara se n’estan implementant d’altres.
  • Finalització i transferència, on es prepara el programari per tal que estigui en explotació. Durant aquesta fase, és objecte de manteniment per eliminar errors no corregits durant la prova, introduir-hi millores i adaptar-lo a canvis tecnològics i organitzatius que es produeixin en l’entorn de treball dels usuaris.

Un model adequat evita trobar-se amb situacions com la que es mostra en la figura, on es poden observar, a mode d’exemple, les diferències d’enteniment entre les diferents parts i fases implicades en la gestió d’un projecte informàtic.

Figura Errors a evitar en el desenvolupament d’un programari

Llenguatge unificat de modelització

UML és l’acrònim, en anglès, de Unified Modeling Language, és a dir, Llenguatge unificat de modelització. UML són un conjunt de notacions gràfiques que serveixen per especificar, dissenyar, elaborar i documentar models de sistemes i, en particular, d’aplicacions informàtiques. A partir d’aquestes notacions gràfiques o diagrames, l’analista i el dissenyador podran recrear les característiques que caldrà que tingui l’aplicació informàtica que els desenvolupadors hauran de crear posteriorment.

OMG

Prové de l’anglès, Object Management Group, que és un consorci fundat l’any 1989 amb l’objectiu de fomentar l’ús de la tecnologia orientada a l’objecte mitjançant l’establiment d’estàndards.

En l’actualitat és el llenguatge de modelització de sistemes més conegut i utilitzat. Gaudeix d’una acceptació gairebé universal i, entre altres beneficis, ha tingut l’efecte d’impulsar el desenvolupament d’eines de modelització gràfica del programari orientat a l’objecte. A més està reconegut i és recomanat per l’OMG.

Els avantatges de la notació UML són els següents:

  • Està recolzada per la OMG (Object Management Group) com la notació estàndard per al desenvolupament de projectes informàtics.
  • Es basa en una notació gràfica concreta i fàcil d’interpretar, essent completada amb explicacions escrites.
  • A l’analista i/o al dissenyador els permet fer ús dels diagrames que considerin oportuns i amb el grau de detall que considerin en funció de les característiques del sistema.
  • Permet tenir una visió global del sistema a implementar.
  • Promou la reutilització.

En la secció Annexos del web del mòdul hi podeu trobar més informació referent a la història i característiques de l’UML.

Entre els desavantatges destaquen:

  • UML no és una metodologia, és una notació.
  • UML no és un llenguatge de programació.
  • Pot resultar complex obtenir un coneixement complet de les possibilitats del llenguatge.

Diagrames

En el llenguatge de modelització UML, en la seva versió 2.4.1, existeixen un total de 14 tipus diferents de diagrames.

Com es pot observar a la figura, una possible classificació dels diagrames es fa en funció de la visió del model del sistema que ofereixen. Les dues visions diferents de model de sistema que poden representar els diagrames UML són:

  • Visió estàtica (o estructural): per oferir aquest tipus de visió s’utilitzen objectes, atributs, operacions i relacions. La visió estàtica d’un sistema dóna més valor als elements que es trobaran en el model del sistema des d’un punt de vista de l’estructura del sistema. Descriuen aspectes del sistema que són estructurals i, per tant, permanents (allò que el sistema té).
  • Visió dinàmica (o de comportament): per oferir aquest tipus de visió es dóna més valor al comportament dinàmic del sistema, és a dir, a allò que ha de passar en el sistema. Amb els diagrames de comportament es mostra com es modela la col·laboració entre els elements del sistema i els seus canvis d’estat. Representen allò que pot fer el sistema modelitzat.

Figura Diagrames UML

Dins els diagrames estàtics o diagrames d’estructura es poden trobar 7 tipus de diagrames, que són:

  • Diagrama de paquets, que representa essencialment les relacions de diferents menes entre els continguts de diferents paquets d’un model.
  • Diagrama de classes, que probablement molts consideren el diagrama principal, atès que descriu classificadors de tota mena i diferents tipus de relacions entre ells abans de fer-los servir en altres diagrames.
  • Diagrama d’objectes, que representa instàncies de classificadors definits en un diagrama de classes previ i relacions entre elles.
  • Diagrama d’estructures compostes, que descriu casos en què, o bé les instàncies d’un classificador tenen com a parts instàncies d’altres, o bé en el comportament executant d’un classificador participen instàncies d’altres.
  • Diagrama de components, que és un diagrama de classes i alhora d’estructures compostes simplificat i més adient per a determinades tecnologies de programació.
  • Diagrama de desplegament, que descriu la configuració en temps d’execució d’un programari especificat, normalment, per un diagrama de components.
  • Diagrama de perfil, permet adaptar o personalitzar el model amb construccions que són específiques d’un domini en particular, d’una determinada plataforma, o d’un mètode de desenvolupament de programari…

A la figura es pot observar un resum dels diagrames d’estructura.

Figura Diagrames d’estructura o estàtics

Dins els diagrames dinàmics o diagrames de comportament es poden trobar 7 tipus de diagrames, que són:

  • Diagrama de casos d’ús, que considera els comportaments d’un sistema principalment des del punt de vista de les interaccions que té amb el món exterior.
  • Diagrama d’estats, en el qual es descriuen les diferents situacions -estats- des del punt de vista dels seus comportaments, de les instàncies d’un classificador, alhora que les causes, condicions i conseqüències dels canvis d’una situació a una altra.
  • Diagrama d’activitats, en què es descriu un comportament complex en forma de seqüències condicionals d’activitats components.

Diagrama d’interacció, que descriu comportaments emergents i té les variants següents:

  • Diagrama de seqüències, que fa èmfasi en la seqüència temporal de les participacions de les diferents instàncies.
  • Diagrama de comunicacions, que es basa directament en una estructura composta.
  • Diagrama de visió general de la interacció, que dóna una visió resumida del comportament emergent.
  • Diagrama temporal, que es basa en un diagrama d’estats previ o més d’un i alhora posa èmfasi en els canvis d’estat al llarg del temps.

A la figura es pot observar un resum dels diagrames dinàmics, també anomenats diagrames d’estructura.

Figura UML: Diagrama de comportament o dinàmic

Diagrama de classes

Un dels diagrames referents de UML, classificat dins els diagrames de tipus estàtic, és el diagrama de classes. És un dels diagrames més utilitzats a les metodologies d’anàlisi i de disseny que es basen en UML.

Un diagrama de classes representa les classes que seran utilitzades dins el sistema i les relacions que existeixen entre elles.

Aquest tipus de diagrames són utilitzats durant les fases d’anàlisi i de disseny dels projectes de desenvolupament de programari. És en aquest moment en què es comença a crear el model conceptual de les dades que farà servir el sistema. Per això s’identifiquen els components (amb els seus atributs i funcionalitats) que prendran part en els processos i es defineixen les relacions que hi haurà entre ells.

Un diagrama de classes porta vinculats alguns conceptes que ajudaran a entendre’n la creació i el funcionament en la seva totalitat. Aquests conceptes són:

  • Classe, atribut i mètode (operacions).
  • Visibilitat.
  • Objecte. Instanciació.
  • Relacions. Herència, composició i agregació.
  • Classe associativa.
  • Interfícies.

A la figura es mostren els elements que poden pertànyer a un diagrama de classes.

Figura Elements del diagrama de classes

Classes. Atributs i operacions

Una classe descriu un conjunt d’objectes que comparteixen els mateixos atributs, que representen característiques estables de les classes, i les operacions, que representen les accions de les classes.

Els atributs (també anomenats propietats o característiques) són les dades detallades que contenen els objectes. Aquests valors corresponen a l’objecte que instancia la classe i fa que tots els objectes siguin diferents entre si.

Tot atribut té assignat un tipus i pot tenir una llista formada per un valor o més d’aquest tipus, d’acord amb la multiplicitat corresponent, que han de pertànyer a aquest tipus i poden variar al llarg del temps.

Per exemple, un possible atribut de la classe persona podria ser el seu nom, atribut de tipus string.

Les operacions (també anomenades mètodes o funcionalitats) implementen les accions que es podran dur a terme sobre els atributs. Ofereixen la possibilitat d’aplicar canvis sobre els atributs, però també moltes altres accions relacionades amb l’objecte, com obrir-lo o tancar-lo, carregar-lo…

Cada operació té una signatura que en descriu els eventuals paràmetres i el seu valor de retorn. Els paràmetres tenen nom, tipus, multiplicitat i direcció (que indica si el paràmetre és d’entrada, de sortida, o d’entrada i sortida alhora). El valor de retorn, si n’hi ha, només té tipus i multiplicitat.

Les operacions poden tornar excepcions durant la seva execució. Una excepció és una instància d’un classificador que és el seu tipus. El fet que una operació torni una excepció normalment denota que s’ha produït una anomalia en l’execució.

Per exemple, un possible mètode de la classe Persona podria ser CalcularEdat, que retorna un enter.

A la figura, es mostra un breu exemple d’una classe i com es representaria.

Figura Exemple de representació d’una classe

Aquesta representació mostra un rectangle que està dividit en tres files:

  • A la primera s’indica el nom de la classe.
  • A la segona s’indiquen els atributs que donen les característiques a la classe. Caldrà també indicar la seva visibilitat.
  • A la tercera s’indiquen els mètodes o les operacions amb la seva declaració i visibilitat.

El codi que es generaria a partir de la classe Persona de la figura seria:

Class Persona{
{
     // atributs
     private String nom;
     private String dni;
     private String adreca;
     private String telefon;
     private date dataNaixement;
     // constructor
     public Persona(String nom, String dni, string adreca, string telefon, date dataNaixement{
  	   this.nom = nom;
  	   this.dni = dni;
  	   this.adreca= adreca;
  	   this.telefon = telefon;
  	   this.dataNaixement = dataNaixement;
     }
     // mètodes o operacions
     public integer CalcularEdat() {
          Date dataActual = new Date();
          SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
          String _dataActual = formato.format(dataActual);
          String _dataNaixement = formato.format(dataNaixement);

          String[] dataInici = _dataNaixement.split("/");
          String[] dataFi = _dataActual.split("/");

          int anys = Integer.parseInt(dataFi[2]) - Integer.parseInt(dataInici[2]);
          int mes = Integer.parseInt(dataFi[1]) - Integer.parseInt(dataInici[1]);
          if (mes < 0) {
               anys = anys - 1;
          } else if (mes == 0) {
               int dia = Integer.parseInt(dataFi[0]) - Integer.parseInt(dataInici[0]);
               if (dia > 0) anys = anys - 1;
          }
          return anys;
     }
}

La visibilitat

La visibilitat d’un atribut o d’una operació definirà l’àmbit des del qual podran ser utilitzats aquests elements. Aquesta característica està directament relacionada amb el concepte d’orientació a objectes anomenat encapsulació, mitjançant el qual es permet als objectes decidir quina de la seva informació serà més o menys pública per a la resta d’objectes.

Exemple de visibilitat

Una classe és un espai de noms per a les seves variables i mètodes; per exemple, un mètode de visibilitat # només pot ser invocat des de mètodes que formin part de la mateixa classe o d’alguna de les seves especialitzacions eventuals.

Les possibilitats per a la visibilitat, tant d’atributs com de mètodes, són:

  • + en UML, o public, que vol dir que l’element és accessible per tots els altres elements del sistema.
  • - en UML, o private, que significa que l’element només és accessible pels elements continguts dins el mateix objecte.
  • # en UML, o protected, que vol dir que l’element només és visible per als elements del seu mateix objecte i per als elements que pertanyen a objectes que són especialitzacions.
  • ~ en UML, o package, que només es pot aplicar quan l’objecte no és un paquet, i aleshores vol dir que l’element només és visible per als elements continguts directament o indirectament dins el paquet que conté directament l’objecte.

Per mostrar un exemple de la visibilitat, es mostra a continuació el codi de la classe Habitació, la classe Persona i la classe Test. Cadascuna de les classes té els seus atributs i els seus mètodes. Alguns d’aquests elements seran públics o privats, oferint les característiques que s’indiquen en finalitzar el codi.

public class Habitacio {
  	private String dataEntrada;
  	private String dataSortida;
  	private Persona client;
  	
  	public Habitacio (String dataEntrada, String dataSortida, String nom) {
  		 this.dataEntrada = dataEntrada;
  		 this.dataSortida = dataSortida;
  		 client = new Persona(nom);
  	}
  	public String getDataEntrada() {
  		 return dataEntrada;
  	}
  	public String getDataSortida() {
  		 return dataSortida;
  	}
  	public Persona getClient() {
  		 return client;
  	}
 }
class Persona{
  	private String nom;
  	
  	public Persona(String nom) {
  		 this.nom = nom;
  	}
  	public String getNom() {
  		 return nom;
  	}
  	public void setNom(String nom) {
  		 this.nom = nom;
  	}
}
public class Test {
  	public static void main(String[] args) {
  		 Habitacio reserva = new Habitacio ("24/011/2012", "28/11/2012", "Joan Garcia");
  		 Persona client = reserva.getClient();
  		 String nom = reserva.getClient().getNom();
  	}
}

Caldria fixar-se en el mètode reserva.getClient(), que únicament té visibilitat als atributs i als mètodes públics de la classe Persona, és a dir, pot consultar el nom de la persona a través del mètode públic getNom però no pot accedir a l’atribut privat nom.

D’altra banda, els mètodes getNom i setNom de la classe Persona tenen visibilitat als atributs i als mètodes privats de la classe, amb la qual cosa, poden accedir a l’atribut privat nom.

Objectes. Instanciació

Un objecte és una instanciació d’una classe. El concepte instanciació indica l’acció de crear una instància d’una classe.

La creació d’una instància d’una classe es refereix a fer una crida al mètode constructor d’una classe en temps d’execució d’un programari.

Un objecte es pot definir, llavors, com una unitat de memòria relacionada que, en temps d’execució, du a terme accions dintre un programari. És quelcom que es pot distingir i que té una existència pròpia, ja sigui de forma conceptual o de forma física.

Un objecte pot pertànyer a més d’una classe, però només d’una d’elles es poden crear objectes directament: la resta de classes representen només papers que pot exercir l’objecte.

Un possible objecte de la classe Persona podria ser el que es mostra a la figura.

Figura Exemple d’un objecte de la classe Persona

El codi per crear un objecte o instància es mostra tot seguit:

public static void main(String[] args) {
      Persona Joan = new Persona("Joan Garcia","40782949","C/Casanoves 130", "93 2983924", 25/03/1977);
}

Un aspecte característic dels objectes és que tenen identitat, cosa que significa que dos objectes creats per separat sempre es consideren diferents, encara que tinguin els mateixos valors a les característiques estructurals.

En canvi, les instàncies de segons quins classificadors no tenen identitat i, aleshores, dues instàncies amb els mateixos valors a les característiques estructurals es consideren com una mateixa instància. Aquest fet es representa a la figura.

Figura Instanciació d’objectes de la classe Persona

Relacions. Herència, composició, agregació

Les relacions són elements imprescindibles en un diagrama de classes. Per relació s’entén que un objecte obj1 demani a un altre obj2, mitjançant un missatge, que executi una operació de les definides en la classe de l'obj2.

En l’exemple d’un client que reserva una habitació d’hotel es pot observar que intervenen dues classes, Persona i Habitació, que estan relacionades, on la classe Habitació consulta el nom del client corresponent a la classe Persona. Es veu representat a la figura.

Figura Relació entre classes

Les relacions que existeixen entre les diferents classes s’anomenen de forma genèrica associacions.

Una associació és un classificador que defineix una relació entre diversos classificadors, que estableix connexions amb un cert significat entre les instàncies respectives.

Classificador

Un classificador és un tipus els valors del qual tenen en comú característiques estructurals i de comportament, que són elements que es defineixen a nivell del classificador. Cadascun d’aquests valors és una instància del classificador.

Una associació té diversos extrems d’associació, a cadascun dels quals hi ha un classificador que té un cert paper en l’associació; un classificador pot ser en més d’un extrem de la mateixa associació amb papers diferents.

Una associació amb dos extrems es diu que és binària; seria el cas de l’exemple d’un client que reserva una habitació d’hotel. Una associació amb tres extrems es diu que és ternària. Es pot veure un exemple d’una associació ternària a la figura.

Figura Associació ternària

La multiplicitat, representada per uns valors <min….max>, indica el nombre màxim d’enllaços possibles que es podran donar en una relació. Aquesta multiplicitat no podrà ser mai negativa, essent, a més a més, el valor màxim sempre més gran o igual al valor mínim. A la figura es pot veure un exemple de la representació d’una associació entre dues classes amb la indicació de la seva multiplicitat.

Figura Associació amb multiplicitat

Concretament, indica que, en l’associació Préstec, per a cada objecte de la classe Lector podrà haver-hi, com a mínim 0 objectes de la classe Llibre i, com a màxim, 3 objectes. En canvi per a cada objecte de la classe Llibre podrà haver-hi, com a mínim 0 i com a màxim 1 objecte de la classe Lector.

Es poden trobar diferents tipus de relacions entre classes. Aquestes es poden classificar de moltes formes. A continuació, es mostra una classificació de les relacions:

  • Relació d’associació
  • Relació d’associació d’agregació
  • Relació d’associació de composició
  • Relacions de dependència
  • Relació de generalització

1) La relació d’associació es representa mitjançant una línia contínua sense fletxes ni cap altre símbol als extrems. És el tipus de relació (anomenada de forma genèrica associació) que s’ha estat explicant fins al moment. És un tipus de relació estructural que defineix les connexions entre dos o més objectes, la qual cosa permet associar objectes que instancien classes que col·laboren entre si.

2) Una relació d’associació d’agregació és un cas especial d’associació entre dos o més objectes. Es tracta d’una relació del tipus tot-part. Aquest tipus de relació implica dos tipus d’objectes, l’objecte anomenat base i l’objecte que estarà inclòs a l’objecte base. La relació indica que l’objecte base necessita de l’objecte inclòs per poder existir i fer les seves funcionalitats. Si desapareix l’objecte base, el o els objectes que es troben inclosos en l’objecte base no desapareixeran i podran continuar existint amb les seves funcionalitats pròpies. La relació d’associació d’agregació es representa mitjançant una línia contínua que finalitza en un dels extrems per un rombe buit, sense omplir. El rombe buit s’ubicarà a la part de l’objecte base. A la figura es pot observar un exemple de relació d’associació d’agregació. L’objecte base és l’objecte anomenat Fruiteria. Els objectes inclosos a la fruiteria són: Pomes, Taronges, Peres i Maduixes. S’estableix una relació entre aquestes classes del tipus tot-part, on les fruites són part de la fruiteria. Això sí, si la fruiteria deixa d’existir, les fruites continuen existint.

Figura Relació d’associació d’agregació

3) Una relació d’associació de composició és també un cas especial d’associació entre dos o més objectes. És una relació del tipus tot-part. És una relació molt semblant a la relació d’associació d’agregació, amb la diferència que hi ha una dependència d’existència entre l’objecte base i l’objecte (o els objectes) que hi està inclòs. És a dir, si deixa d’existir l’objecte base, deixarà d’existir també el o els objectes inclosos. El temps de vida de l’objecte inclòs depèn del temps de vida de l’objecte base. La relació d’associació de composició es representa mitjançant una línia contínua finalitzada en un dels extrems per un rombe pintat, omplert. El rombe pintat s’ubicarà a la part de l’objecte base. A la figura es mostra un exemple d’una relació d’agregació. L’objecte base es compon dels objectes inclosos Menovell, Anular, Cor, Índex i Polze. Sense l’objecte la resta d’objectes deixaran d’existir.

Figura Relació d’agregació de composició

4) Un altre tipus de relació entre classes és la relació de dependència. Aquest tipus de relació es representa mitjançant una fletxa discontínua entre dos elements. L’objecte del qual surt la fletxa es considera un objecte dependent. L’objecte al qual arriba la fletxa es considera un objecte independent. Es tracta d’una relació semàntica. Si hi ha un canvi en l’objecte independent, l’objecte dependent es veurà afectat.

5) La relació de generalització es dóna entre dues classes on hi ha un vincle que es pot considerar d’herència. Una classe és anomenada classe mare (o superclasse). L’altra (o les altres) són les anomenades classes filles o subclasses, que hereten els atributs i els mètodes i comportament de la classe mare. Aquest tipus de relació queda especificat mitjançant una fletxa que surt de la classe filla i que acaba a la classe mare. A la figura es pot veure un exemple on l’element actor és independent. Hi ha una dependència normal de l’element pel·lícula en relació amb l’element actor, ja que actor es fa servir com a paràmetre als mètodes afegir i eliminar de pel·lícula. Si hi ha canvis a actor, l’objecte pel·lícula es veurà afectat.

Figura Relació de dependència

L’herència es dóna a partir d’aquestes relacions de dependència. Ofereixen com a punt fort la possibilitat de reutilitzar part del contingut d’un objecte (el considerat superclasse), estenent els seus atributs i els seus mètodes a l’objecte fill. A la figura es pot veure un exemple d’herència.

Figura Relació d’herència

Classe associativa

Quan una associació té propietats o mètodes propis es representa com una classe unida a la línia de l’associació per mitjà d’una línia discontínua. Tant la línia com el rectangle de classe representen el mateix element conceptual: l’associació.

En el cas de l’exemple de la figura ens trobem que la nota està directament relacionada amb les classes Estudiant i Assignatura. Cada un dels alumnes de l’assignatura tindrà una determinada nota. La manera de modelitzar l’UML aquesta situació és amb les classes associades.

Figura Exemple de classe associativa

Interfície

Una interfície conté la declaració de les operacions sense la seva implementació, que hauran de ser implementades per una classe o component.

Arribats a aquest punt, ens podríem preguntar: Quina diferència hi ha entre una interfície i una classe abstracta?

Una interfície és simplement una llista de mètodes no implementats, així com la declaració de possibles constants. Una classe abstracta, a diferència de les interfícies, pot incloure mètodes implementats i no implementats.

A la figura es mostra un exemple d’una interfície representada en UML. Aquesta interfície s’anomena ICalculadora, i conté els mètodes suma, resta, multiplicacio i divisio.

Figura Representació d’una interfície en UML

En el codi següent es mostra la definició d’aquesta interfície a partir de la figura.

interface ICalculadora {
    public abstract int suma (int x, int y);
    public abstract int resta (int x, int y);
    public abstract int multiplicacio (int x, int y);
    public abstract int divisio (int x, int y);
}

Una vegada definida es mosta com serà la utilització de la interfície definida en el codi següent.

public class Calculadora implements ICalculadora {
        public int suma (int x, int y){
            return x + y;
        }
        public int resta (int x, int y){
            return x - y;
        }
        public int multiplicacio (int x, int y){
            return x * y;
        }
        public int divisio (int x, int y){
            return x / y;
        }
}

Diagrama d'objectes

Un objecte és una instància d’una classe, per la qual cosa es pot considerar el diagrama d’objectes com una instància del diagrama de classes.

El diagrama d’objectes només pot contenir instàncies i relacions entre objectes: enllaços i dependències que tinguin lloc entre instàncies. Els classificadors i les associacions respectives han d’haver estat definits prèviament en un diagrama de classes.

Sovint té la funció de simple exemple d’un diagrama de classes o d’una part d’ell.

A la figura es mostra un diagrama de classes consistent en dues classes, la classe Habitació i la classe Persona. A partir d’aquest diagrama es crea i es mostra el diagrama d’objectes a la mateixa figura.

Figura Diagrama d’objectes

Diagrama de paquets

Els paquets permeten organitzar els elements del model en grups relacionats semànticament; un paquet no té un significat per si mateix.

El diagrama de paquets serveix per descriure l’estructura d’un model en termes de paquets interrelacionats.

A la figura es mostra un exemple de diagrama de paquets. S’hi ha representat un paquet, Diagrames, que conté dos paquets: estàtic o d’estructura i dinàmic o de comportament.

Figura Diagrama de paquets

Diagrama d'estructures compostes

Una estructura composta és un conjunt d’elements interconnectats que col·laboren en temps d’execució per aconseguir algun propòsit.

La finalitat del diagrama d’estructures compostes és descriure objectes compostos amb la màxima precisió possible. Es tracta d’un diagrama que complementa el diagrama de classes.

A continuació es descriurà, fent ús d’un exemple, el concepte del diagrama d’estructures compostes.

Si es vol modelitzar un sistema que té una videoconsola i una minicadena, ambdues estan compostes per una CPU (Unitat Central de Procés), però en la videoconsola la CPU processa el joc que serà visualitzat en algun dispositiu de sortida (com, per exemple, un televisor) i, en el segon cas, la CPU processa la música perquè pugui ser escoltada.

Una possible forma de modelitzar el sistema podria ser la que mostra la figura.

Figura Diagrama de classes-composició

Però si es revisa amb detall el diagrama de la figura es pot observar que té deficiències, ja que fàcilment es pot interpretar que la CPU de la minicadena pot processar música i jocs.

UML 2.0 ha introduït un nou diagrama, anomenat diagrama d’estructura composta, que permet concretar les parts que componen una classe. Aquest permetrà representar el sistema amb el diagrama que es mostra en la figura, que delimita l’abast de la videoconsola i de la minicadena.

Figura Diagrama d’estructura composta

Diagrama de components

Un component és una peça del programari que conforma el sistema, peça que pot ser reutilitzable i fàcilment substituïble.

Interfície

Una interfície conté la declaració de les operacions sense la seva implementació, les quals hauran de ser implementades per una classe o component.

Un component sol fer ús d’una interfície que defineix les operacions que el component implementarà.

El diagrama de components mostra els components que conformen el sistema i com es relacionen entre si. A la figura es pot veure un exemple d’un diagrama de components.

Figura Diagrama de components

Diagrama de desplegament

El diagrama de desplegament descriu la distribució de les parts d’una aplicació i les seves interrelacions, tot en temps d’execució.

El diagrama de desplegament descriu la configuració d’un sistema de programari en temps d’execució, en termes de recursos de maquinari i dels components de programari, processos i objectes (en memòria o emmagatzemats en bases de dades, per exemple) que s’hi hostatgen.

Tot seguit es mostren diversos exemples de diagrames de desplegament.

En la figura hi ha els nodes Servidor i Client, considerats a nivell de classificador, i una línia de comunicacions. En aquesta, cada instància de Client pot bescanviar informació només amb una instància de Servidor, mentre que una instància de Servidor en pot bescanviar informació almenys amb una instància de Client, però podrà fer-ho amb més.

Figura Nodes i línia de comunicacions

Que un artefacte es desplegui dins d’un node es pot representar, o bé incloent el símbol de l’artefacte dins el del node, o bé amb el desplegament de l’artefacte cap al node. La figura mostra un exemple de cada opció, la primera amb instàncies i la segona amb classificadors.

Figura Un desplaçament i els seus elements

Eclipse i UML: notació dels diagrames de classes

Per poder entendre millor els diagrames de classes i la seva notació, es mostra a continuació un exemple complet. A més a més, s’ha fet servir l’IDE Eclipse per a la creació d’aquests diagrames UML. Aquest IDE, en la seva distribució normal, no porta incorporada cap eina que permeti la creació de diagrames UML. Per això és necessari instal·lar el connector anomenat Papyrus a l’Eclipse. Existeixen molts connectors a Eclipse que permeten treballar amb Eclipse, alguns de propietaris i altres de codi obert. Qualsevol hauria d’oferir un funcionament semblant al que es proposa des d’aquests materials. Es fa servir el format d’exercici per oferir aquestes indicacions, pas a pas, de com crear un diagrama de classes a partir dels requeriments d’un enunciat.

Aquest enunciat és el que es mostra a continuació:

Les factures dels proveïdors d’una empresa poden ser de proveïdors de serveis o de proveïdors de productes o materials. Cadascuna de les factures, de qualsevol dels dos tipus, tenen en comú:

  • El número de la factura.
  • La data de la factura.
  • L’import total –que es calcula de manera diferent en les unes que en les altres.
  • Les dades del client, que són el NIF i el nom, i que s’hauran de trobar en una classe a part.
  • El detall de la factura (tant si és de materials com si és de serveis).

Tant per a les factures de serveis com per a les factures de productes o materials cal tenir guardada la darrera factura emesa, per tenir present el número de factura. Hi ha una llista de serveis amb la descripció i el preu per hora de cadascun.

En el detall de les factures haurà d’haver-hi:

  • A les factures de serveis, a cada factura hi ha una llista de serveis amb la data de prestació, el nombre d’hores dedicades i el preu/hora per servei. En una factura hi pot haver més d’una prestació del mateix servei.
  • A les factures de productes, per a cada producte (a cada factura n’hi ha almenys un) haurà d’haver-hi la descripció, el preu unitari i la quantitat.

Creació del projecte

El primer que s’ha de fer és crear un projecte de tipus Papyrus. Es pot observar a la figura.

Figura

Una vegada seleccionada l’opció, es podrà seguir l’assistent que s’ofereix per a la creació del projecte. Es pot observar a la figura.

Figura

Tal com es mostra en la figura, l’assistent ens permetrà especificar el nom del projecte.

Figura

L’assistent permetrà seleccionar el llenguatge del diagrama, que en aquest cas serà UML, Unified Modeling Language (figura).

Figura

Finalment, permetrà seleccionar els diagrames que s’utilitzaran en el projecte, UML Class Diagram (figura).

Figura

Una vegada finalitzada la creació del projecte, podrem observar una vista Package Explorer, que conté el projecte que s’acaba de crear Factura. L’editor permetrà representar gràficament el diagrama de classes i una vista Palette, que anirà mostrant els diferents components que es podran utilitzar en el diagrama seleccionat (vegeu la figura).

Figura

Configuració de l'IDE: Eclipse

En la figura, figura i figura es mostra com visualitzar una nova vista, en concret Model Explorer, que contindrà un llistat jeràrquic dels components que integrin el diagrama.

Figura

Figura

Figura

En la figura i figura es mostra com visualitzar una nova vista, en concret les propietats dels components. Vista imprescindible per dissenyar el diagrama. Per exemple, en una relació es podrà especificar el nom de l’associació, la seva visibilitat, la cardinalitat de la relació, entre d’altres.

Figura

Figura

Herència

L’enunciat especifica: “cadascuna de les factures d’una empresa és, o bé una factura de serveis o bé una factura de productes”. Podem observar que es tracta d’una generalització o herència, on la classe pare correspon a Factura i les classes filles a Factura de serveis i Factura de productes.

En la figura es mostra com es crea una classe Factura en el diagrama de classes, seleccionant el Node class en la barra d’eines i arrossegant-lo a l’àrea de treball.

Figura Creació d’una classe

Les propietats de la classe es poden concretar en la finestra de propietats, tal com es mostra en la figura.

Figura

De la mateixa manera que s’ha explicat anteriorment, es creen les classes corresponents a Factura de serveis i Factura de productes. En la figura es mostren aquestes classes.

Figura Classes Factura, FacturaServeis i FacturaProducte

Queda pendent crear la relació d’herència entre les classes. Seleccionant l’enllaç generalització i arrossegant-lo a la zona de treball, se seleccionen els dos objectes que s’han de relacionar, FacturaProductes i Factura. A la figura es pot observar com crear la relació d’herència.

Figura Creació de la relació d’herència

Es repeteix el procés en la relació FacturaServeis i Factura.

El diagrama resultant és el que es mostra en la figura.

Figura Relació d’herència entre classes

Creació dels atributs d'una classe

Si continuem interpretant l’enunciat, ens indica: “les unes i les altres tenen en comú el número, la data i l’import”. D’aquesta manera, les propietats de la classe Factura són: número, data i import.

Papyrus permet crear les relacions fent ús del component Property, arrossegant-lo a la segona fila de la classe Factura, tal com es mostra en la figura.

Figura Atributs de la classe

Es modifica el nom de cada un dels atributs en la finestra de les propietats. En la figura es pot observar com ha de quedar el diagrama de classes.

Figura Atributs de la classe Factura

Arribats a aquest punt, queda pendent especificar el tipus de cada un dels atributs. Inicialment, s’haurà de crear una referència als tipus de UML tal com es mostra en la figura, figura, figura i figura.

Figura Relació UML tipus

Figura Relació UML tipus

Figura Relació UML tipus

Figura Relació UML tipus

Seleccionat un atribut, en la finestra de propietats, en concret en l’opció Type s’especifica el tipus, com es pot observar a la figura.

Figura Tipus de l’atribut

En la figura es pot observar com queda el diagrama de classes.

Figura Diagrama de classes

Creació dels mètodes d'una classe

L’enunciat ens indica que l’import es calcula de manera diferent en les unes que en les altres, és a dir el càlcul de l’import serà diferent per a la classe FacturaServeis i per a la classe FacturaProductes.

D’aquesta manera, el mètode CalculImport() de la classe Factura es definirà com un mètode abstracte que serà definit en cada una de les classes filles.

Com es pot observar a la figura, per definir un mètode en Papyrus es fa ús del component operation, que serà arrossegat a l’àrea de mètodes de la classe (tercera fila).

Figura Creació d’un mètode

Per definir el tipus de retorn del mètode CalculImport s’ha d’afegir un nou atribut, tal com es mostra en la figura.

Figura Creació d’un paràmetre

Per especificar que es tracta d’un paràmetre de retorn s’efectua a través de les propietats, com es pot observar a la figura.

Figura Paràmetre de retorn

D’aquesta manera, el diagrama resultant analitzat fins al moment és el que es mostra en la figura.

Figura Diagrama de classes

Agregació

Seguint amb l’enunciat, es diu: “les dades del client, que són el NIF i el nom, i són en una classe a part”.

És necessari crear una nova classe anomenada DadesClient, que contindrà els atributs NIF i nom. Es pot observar el diagrama d’aquesta classe en la figura.

Figura Classe DadesClient

El tipus d’associació entre la classe Factura i DadesClient és d’agregació, ja que la classe DadesClient és un objecte que únicament podrà ser creat si existeix l’objecte agregat Factura del qual ha de formar part. En la figura es mostra com crear aquest tipus d’associació.

Figura Agregació

El diagrama resultant analitzat fins al moment és el que es mostra en la figura.

Figura Diagrama de classes

D’altra banda, l’enunciat especifica: “es guarda, d’una banda, l’últim número de factura de serveis i, de l’altra, l’últim número de factura de productes”.

És necessari crear un nou atribut ultimNumero en la classe FacturaServeis i en la classe FacturaProductes.

El diagrama resultant analitzat fins al moment és el que es mostra en la figura.

Figura Diagrama de classes

Classe associada

L’enunciat continua explicant: “Hi ha una llista de serveis amb la descripció i el preu per hora de cadascun”.

Per tant, és necessari crear una nova classe anomenada Servei que contindrà dos atributs: descripcio i preuHora (preu per hora), com es pot observar en la figura.

Figura Classe Servei

L’enunciat continua: “cada factura de serveis té una llista de serveis amb la data de prestació i el nombre d’hores, i en una factura hi pot haver més d’una prestació del mateix servei”.

Per tant, és necessari crear una classe associada anomenada Hores que contindrà dos atributs: dataPrestació (data de prestació) i nombre (nombre d’hores), com es pot observar a la figura.

Figura Classe Hores

El diagrama resultant és el que es mostra en la figura.

Figura Diagrama de classes

Composició

Continuant amb l’enunciat, aquest ens especifica: “Les factures de productes, per a cada producte (a cada factura n’hi ha almenys un) tenen la descripció, el preu unitari i la quantitat”.

Per tant, és necessari crear una nova classe anomenada ProducteFactura, que contindrà els atributs descripcio, preuUnitat (preu unitari) i quantitat, com es pot observar en la figura.

Figura Classe ProducteFactura

En aquest cas es tracta d’una composició, ja que és una relació més forta que l’agregació. FacturaProductes té sentit per ell mateix, però està compost de ProducteFactura (amb la descripció, preu i quantitat de la factura), aquesta relació és més forta que l’associació d’una agregació.

El diagrama resultant de l’enunciat és el que es mostra en la figura.

Figura Diagrama de classes

Anar a la pàgina anterior:
Referències
Anar a la pàgina següent:
Activitats