Llenguatge de modelització unificat

L'UML o llenguatge de modelització unificat (Unified Modeling Language^[1]) és un llenguatge de modelat de sistemes de programari, és el més conegut i utilitzat en l'actualitat, està suportat per l'OMG^[2] (Object Management Grup). És un llenguatge gràfic per visualitzar, especificar, construir i documentar un sistema. L'UML ofereix un estàndard per descriure un sistema (model), incloent aspectes conceptuals tals com els processos de negoci i funcions del sistema, i aspectes concrets com expressions de llenguatges de programació, esquemes de bases de dades i components reutilitzables.

L'UML va ser desenvolupat per Grady Booch,^[3] Ivar Jacobson^[4] i James Rumbaugh mentre treballaven per l'empresa Rational Software^[5] durant els anys 1994-1996. Aquest llenguatge disposa de diversos tipus de diagrames, els quals mostren diferents aspectes de les entitats representades.

Història

L'UML ha anat evolucionant des de la segona meitat de la dècada del 1990 i té les seves arrels en els mètodes orientats a objectes desenvolupats des de la fi dels anys 1980.^[6] La línia de temps (vegeu la imatge) mostra els aspectes més destacats de la història del modelatge orientat a objectes.

En català, segons el Termcat, és manté la paraula i l'acrònim anglesos, tot i donar com traducció literal «llenguatge de modelització unificat» o «llenguatge universal de modelització».^[7][8] La Gran Enciclopèdia dona «llenguatge unificat de modelació».^[9]

Abans del UML 1.x

Després que Rational Software^[5] contractés a James Rumbaugh la companyia es va convertir amb la font dels dos esquemes de modelat orientat a objectes més populars de l'època: L'Object-modeling technique (OMT) creat per Rumbaugh, que era millor per l'anàlisi orientat a objectes i el Mètode Booch creat per Grady Booch, que era millor pel disseny orientat a objectes. Poc després es va unir a l'empresa Ivar Jacobson, el creador del mètode d'enginyeria del software orientat a objectes. Els tres creadors van ser coneguts amb el nom dels Tres Amics a causa de les seves constants discussions sobre les pràctiques metodològiques.

L'any 1996 l'empresa Rational Software va concloure que l'abundància de llenguatges de modelat alentia la seva evolució i alterava el seu ús. Degut a això, l'empresa va decidir orientar-se cap a un mètode unificat i va encarregar als Tres Amics que desenvolupessin un llenguatge unificat de modelat obert (aparició UML).^[10]

UML 1.x

Com evolució de l'UML 0.x es va treure l'anotació de "núvols" de Booch i es va adoptar la capacitat de Booch per especificar detalls de disseny en els nivells inferiors. La notació de Casos d'ús i la notació de components de Booch van ser integrats a la resta de la notació, però la integració semàntica era relativament dèbil amb l'UML 1.1 i no es va arreglar realment fins a l'aparició de l'UML 2.0.

Conceptes de molts altres mètodes OO van ser integrats superficialment en UML amb el propòsit de fer-lo compatible amb tots els mètodes OO. A més el grup va tenir en compte molts altre mètodes de l'època, amb l'objectiu d'assegurar una àmplia cobertura en el domini dels sistemes de temps real. Com a resultat, UML és útil en una gran varietat de problemes d'enginyeria, des de processos senzills i aplicacions d'un sol usuari a sistemes concurrents i distribuïts.

UML 2.x

L'UML ha madurat considerablement des d'UML 1.1. Diferents revisions menors (UML 1.3, 1.4 i 1.5) han corretgit els defectes i errors de la primera versió d'UML. A aquestes revisions han estat precedides per la revisió major de l'UML 2.0^[11][12] que va ser adoptada per l'Object Management GroupOMG el 2005.

Hi ha hagut diverses versions des de l'UML 2.0 fins a arribar a l'UML 2.5 llançat l'octubre de 2012.

Definició (UML)^[13]

L'UML^[14] ens ofereix una forma diferent de visualitzar els problemes mitjançant diagràmes. El seu ús més comú està enfocat a la resolució/representació de problemes destinats a la construcció de software.

Anem a analitzar les sigles UML: Llenguatge unificat de modelat

Llenguatge UML

Un llenguatge, en general, és el conjunt de mots (un mot és un conjunt de simbols inventats que formen part d'un alfabet) concatenats seguint una gràmatica (regles marcades per concatenar els mots).

El llenguatge del UML ens permet descriure un model d'analisi i disseny d'un sistema mitjançant diagrames construïts utilitzant simbols que tenen regles semàntiques, sintàctiques i pràctiques.

• Regles Semàntiques: Ens diuen què significa cada símbol i com interpretarlo.
• Regles Sintàctiques: Ens diuen com mostrar i combinar els símbols per obtenir els diagrames d'un model.
• Regles Pràctiques: Defineix com utilitzar els simbols per obtenir els diagrames de model.

El procés unificat

El procés unificat és un metode d'enginyeria del software que ha estat desenvolupat amb l'objectiu de guiar els enginyers del software en les activitats necessàries per construir usant l'UML un projecte de software de qualitat.

Modelat

Un model UML és una abstracció que captura el coneixement sobre un problema, és a dir, el model extreu els detalls essencials del problema.

És important distingir entre el model UML i el conjunt de diagrames d'un sistema. El conjunt de diagrames no necessàriament necessiten cobrir tot un model i el fet de borrar un diagrama no implica canviar el model. Per tant, entenem que un model el conformen un conjunt de diagrames i un diagrama és una representació gràfica parcial del model d'un sistema. El model també conté la documentació que controlen els elements del model i els diagrames (per exemple, casos d'ús escrits (fitxes de casos d'ús)).

Metodologia de desenvolupament del software

El conjunt de fases per les quals passa el sistema que s'està desenvolupant des que neix la idea inicial fins que el software és retirat o substituït és el següent:^[15][16]

Hi ha diverses maneres d'implementar el cicle de vida^[17] del software, però més que com fer el cicle de vida ens volem centrar en les tres primeres fases.

Per tal de dur a terme les tres primeres fases és quan utilitzem el llenguatge unificat de modelat (UML) definint a partir del conjunt de diagrames del model final del nostre sistema.

En la primera fase, la fase de requeriments utilitzarem (per a descriure els requeriments del sistema) els diagrames de casos d'ús i els diagrames d'activitats que ens permetran descriure el comportament del sistema (funcionalitats) al interectuar amb usuaris externs (actors) i el flux d'activitats involucrades en una funcionalitat determinada del sistema respectivament.

En la segona fase, la fase d'anàlisi ja ens centrem més en l'interior del software i preparem el diagrama de classes. En aquesta fase intervenen els informàtics per tal de saber quines classes seran necessàries per a l'aplicació, però en la fase d'anàlisi simplement fem un diagrama de classes sense especificar els mètodes que tindrà cada classe, això ho farem a la fase de disseny.

A la fase de disseny és quan utilitzarem els diagrames de seqüència i diagrames de comunicació per tal de poder d'escollir els mètodes que ficarem a cada classe del diagrama de classes. També se solen fer els diagrames d'estat que ens permetran modelar la dinàmica d'un sistema .

Diagrames

L'UML presenta tots aquests diagrames,^[18] és a dir, el nostre model de software estarà comopost per tots aquests diagrames (tot i que molts cops molts dels diagrames presentats no s'utilitzen):

Els diagrames UML representen dos visions diferents d'un model de sistema:

• Estàtica (o estructural): defineix l'estructura estàtica del sistema utilitzant objectes, atributs, operacions i relacions. El punt de vista estructural inclou diagrames de classes i diagrames d'estructura composta.
• Dinàmica (o de comportament): defineix el comportament dinàmic del sistema, mostrant la col·laboració entre els objectes i els canvis en els estats interns dels objectes. Aquesta visió inclou diagrames de seqüència, diagrames d'activitat i diagrames d'estat.

A l'UML 2.5 hi ha 14 tipus diferents de diagrames. Per comprendre'ls de manera concreta, de vegades és útil categoritzar-los jeràrquicament, com es mostra a la figura de dalt.

Diagrames d'Estructura

Els Diagrames d'Estructura emfatitzen en els elements que hi ha d'haver en el sistema modelat:

• Diagrames de classes:
  • Descriuen l'estructura d'un sistema mostrant les seves classes, atributs i les relacions entre ells. És on es crea el disseny conceptual de la informació que utilitzarà el sistema, i els components que s'encarregaran del seu funcionament i de la relació entre l'un i l'altre.
• Diagrama de components:
  • Els diagrames de components mostren com es connecten entre si els components per formar components més grans. S'utilitzen per il·lustrar l'estructura dels sistemes arbitràriament complexes.
• Diagrama d'objectes:
  • El diagrama d'objectes consisteix en la mostra de les instàncies creades i els vincles existents entre elles en un moment donat.
• Diagrama de perfil:
  • Els diagrames de perfil ens permeten representar els estereotips utilitzats per representar l'aplicació dissenyada.
• Diagrama d'estructura composta:
  • Un diagrama d'estructura composta és semblant a un diagrama de classes, però mostra parts individuals en lloc de classes senceres. En altres paraules, mostra l'estructura interna d'una classe, així com les col·laboracions que permet.
• Diagrama de desplegament:
  • Els diagrames de desplegament ens permeten representar com està connectat el software dissenyat amb el hardware del sistema.
• Diagrama de paquets:
  • Un diagrama de paquets agrupa un conjunt de paquets i mostra les dependències entre aquests.

Diagrames de comportament

Els diagrames de Comportament emfatitzen en el que ha de succeir en el sistema modelat:

• Diagrama d'activitats:
  • Aquests diagrames descriuen gràficament els algoritmes (accions que fa el sistema). Fem una representació gràfica del que es fa quan es demana una acció al sistema (si fa això passa allò, sinó lo altre...)
• Diagrama de casos d'ús:
  • Els diagrames de casos d'ús descriuen el comportament (funcionalitats) d'un sistema quan interactua amb usuaris externs (actors), és a dir, defineix el comportament d'un sistema des del punt de vista dels actors.
• Diagrama d'estats:
  • Mostra el conjunt d'estats i transicions pels quals passa un objecte al llarg de la seva vida en l'aplicació.

Diagrames d'interacció

Els Diagrames d'Interacció són un subtipus de diagrames de comportament que descriuen com s'executa l'aplicació i com es distribueixen les dades entre les diferents parts del sistema.

• Diagrama de seqüència
  • Un diagrama de seqüència és un diagrama d'interacció que detalla com s'executen les operacions en funció del temps:
    • Quins missatges són enviats
    • Per quin objecte són enviats
    • Per quin objecte seran rebuts
    • Quan
• Diagrama de comunicació:
  • Els diagrames de comunicació ens proporcionen la mateixa informació que els diagrames de seqüència, però se centren en els rols dels objectes en comptes de fer-ho en el temps en el qual s'envien els missatges.
• Diagrama de temps:
  • És un diagrama d'interacció on l'atenció se centra en les limitacions de temps. Més concretament s'utilitzen per explorar el comportament dels objectes al llarg d'un període determinat.
• Diagrama global d'interaccions o Diagrama de vista d'interacció:
  • El diagrama general d'interacció és similar al diagrama d'activitat, els dos serveixen per visualitzar una seqüència d'activitats. La diferència és que, en el diagrama global d'interaccions, cada activitat individual es representa com un marc que pot contenir uns diagrames d'interacció niats.

Crítiques a l'UML

Malgrat la seva estatus d'estàndard àmpliament reconegut i utilitzat, l'UML sempre ha estat molt criticat per la seva manca d'una semàntica precisa, i això comporta que la interpretació d'un model UML no pugui ser objectiva. Un altre problema de l'UML és que no es presta amb facilitat al disseny de sistemes distribuïts. En aquests sistemes cobren importància factors com la transmissió, serialització, persistència, etc. l'UML no compta amb maneres de descriure aquests factors. No es pot, per exemple, fer servir l'UML per assenyalar que un objecte és persistent o remot, o que existeix en un servidor que corre contínuament i que és compartit entre diverses instàncies d'execució del sistema analitzat. No obstant això, l'UML si accepta la creació dels nostres propis components per a aquest tipus de modelatge.

Referències

Vegeu també

• Llista d'eines UML