Arquitectures de desenvolupament i de destinació en projectes AMI

Per desenvolupar eficientment projectes d’aplicacions multimèdia interactives (AMI) cal conèixer un seguit de tècniques i eines que faciliten enormement el treball. Si sou capaços i capaces de representar la funcionalitat d’una manera simple i visual serà més fàcil treballar-hi en equip. A més a més, l’èxit d’un projecte AMI depèn en gran mesura tant de l’entorn de desenvolupament escollit com de l’equip encarregat de produir el producte. Finalment, com en qualsevol altre entorn, cal tenir en compte la seguretat de tot el desenvolupament.

Representacions de la capacitat i funcionament del sistema

Reflexioneu un moment sobre algun cop en què heu volgut explicar un concepte complex a un grup de persones. Segur que tenir material visual de suport us ha resultat fonamental per poder transmetre la idea. Tot i així és molt probable que us hagi calgut respondre a alguna pregunta o que algun concepte no hagi quedat clar a algú. Aquest, de fet, és el problema més comú a l’hora de treballar en equip, o d’interpretar el que un client vol exactament. Hi ha un llenguatge, però, que permet posar en comú totes les idees d’una manera metòdica i tècnica, per evitar problemes de malentesos. Aquest és el llenguatge unificat de modelatge (UML).

Modelatge de sistemes: eines, tècniques i procediments

El modelatge de sistemes és un conjunt d’eines, tècniques i procediments que s’utilitzen per descriure els processos d’un sistema, per exemple un programari informàtic, una aplicació interactiva, o fins i tot una màquina. Com que els processos poden ser complexes i amb moltes variables, el modelatge ens permet analitzar i tractar tota la complexitat del sistema. L’objectiu és crear un model on estiguin descrites els diferents aspectes, com són la interacció de l’usuari amb l’aplicació, quins són els esdeveniments i quines accions es produeixen, quina és la relació entre aquestes accions. Per construir el model s’utilitzen eines visuals (diagrames), que mostren de manera molt clara aquests conceptes que són abstractes.

El llenguatge unificat de modelatge (UML) és un llenguatge visual per especificar, construir i documentar els artefactes dels sistemes. A la taula trobareu el vocabulari vinculat a l’UML.

Taula: Glossari de termes comuns al vocabulari d’UML
Vocabulari d’UML Descripció
Compatibilitat amb sintaxi abstracta Els usuaris poden moure models a través de diferents eines, fins i tot si usen diferents notacions.
Metamodel de magatzem comú (CWM) Interfícies estàndards que s’usen per permetre l’intercanvi de metadades de magatzem i intel·ligència de negocis entre eines de magatzem, plataformes de magatzem i repositoris de metadades de magatzem en entorns heterogenis distribuïts.
Compatibilitat amb sintaxi concreta Els usuaris poden continuar usant una notació amb la qual estiguin familiaritzats a través de diferents eines.
Nucli En el context d’UML, el nucli comunament es refereix al “paquet central”, que és un metamodel complet particularment dissenyat per a una alta reutilització.
Unitat de llenguatge Consisteix en una col·lecció de conceptes de modelatge estretament vinculats que proporciona als usuaris la capacitat de representar aspectes del sistema en estudi segons un paradigma o formalisme en particular. Consisteix en una col·lecció de conceptes de modelatge estretament vinculats que proporciona als usuaris la capacitat de representar aspectes del sistema en estudi segons un paradigma o formalisme en particular.
Nivell 0 (L0) Nivell de compliment inferior per a la infraestructura UML. Una sola unitat de llenguatge que fa possible el modelatge de tipus d’estructures basades en classes que es troben en els llenguatges més populars de programació orientats a objectes.
Meta Object Facility (MOF) Una especificació de modelatge d’OMG que brinda la base per a les definicions de metamodels en la família de llenguatges MDA d’OMG.
Metamodel Defineix el llenguatge i els processos a partir dels quals formar un model.
Construccions de metamodels (LM) Segon nivell de compliment en la infraestructura UML. Una unitat addicional de llenguatge per a estructures més avançades basades en classes, usades per construir metamodels (per mitjà de CMOF), com ara el mateix UML mateix. L’UML solament té dos nivells de compliment.
Arquitectura dirigida per models (MDA) Un enfocament i un pla per aconseguir un conjunt coherent d’especificacions de tecnologia dirigida per models.
Llenguatge de restriccions per a objectes (OCL) Un llenguatge declaratiu per descriure regles que s’apliquen al llenguatge unificat de modelatge. L’OCL complementa l’UML proporcionant termes i símbols de diagrames de flux que són més precisos que el llenguatge natural, però menys difícils de dominar que les matemàtiques.
Object Management Group (OMG) És un consorci sense finalitats de lucre d’especificacions per a la indústria de la computació, els membres de la qual defineixen i mantenen l’especificació UML.
UML 1 Primera versió del llenguatge unificat de modelatge.
XMI Una especificació basada en XML de formats d’intercanvi de models corresponents.

Diagramació, nivells apropiats de detall

El llenguatge unificat de modelatge (UML) va ser creat per forjar un llenguatge de modelatge visual comú i semànticament i sintàcticament ric per a l’arquitectura, el disseny i la implementació de sistemes de programari complexos, tant en estructura com en comportament. Representa la notació estàndard i semàntica essencial per al modelatge de sistemes. L’UML té aplicacions més enllà del desenvolupament de programari, per exemple, en el flux de processos en la fabricació.

L’UML es pot usar per modelar diferents tipus de sistemes: sistemes de programari, sistemes de maquinari i organitzacions del món real. Usa elements i els associa de diferents maneres per formar diagrames que representen aspectes estàtics o estructurals d’un sistema, i diagrames de comportament que capten els aspectes dinàmics d’un sistema (vegeu la figura).

Figura Elements d’un diagrama de casos d’ús

Els diagrames UML estructurals són:

  • Diagrama de classes: és el diagrama UML més comunament usat, i la base principal de tota solució orientada a objectes. És un tipus de diagrama estàtic que descriu l’estructura d’un sistema mostrant les seves classes, atributs i les relacions entre ells. Les classes s’agrupen per crear diagrames de classes en crear diagrames de sistemes grans.
  • Diagrama de components: mostra la relació estructural dels elements del sistema de programari, molt freqüentment empleats en treballar amb sistemes complexos amb components múltiples. Els components es comuniquen per mitjà d’interfícies.
  • Diagrama d’estructura composta: els diagrames d’estructura composta s’usen per mostrar l’estructura interna d’una classe.
  • Diagrama d’implementació: il·lustra el maquinari del sistema i el seu programari. És útil quan s’implementa una solució de programari en múltiples màquines amb configuracions úniques.
  • Diagrama d’objectes: mostra la relació entre objectes per mitjà d’exemples del món real i il·lustra com es veurà un sistema en un moment donat. Atès que les dades estan disponibles dins dels objectes, aquests poden usar-se per aclarir relacions entre objectes.
  • Diagrama de paquets: hi ha dos tipus especials de dependències que es defineixen entre paquets: la importació de paquets i la fusió de paquets. Els paquets poden representar els diferents nivells d’un sistema per revelar l’arquitectura. Es poden marcar les dependències de paquets per mostrar el mecanisme de comunicació entre nivells.

I entre els diagrames UML de comportament, tenim:

  • Diagrames d’activitats: fluxos de treball de negocis o operatius representats gràficament per mostrar l’activitat d’alguna part o component del sistema. Els diagrames d’activitats s’usen com una alternativa als diagrames de màquina d’estats.
  • Diagrama de comunicació: similar als diagrames de seqüència, però s’enfoca en els missatges que es passen entre objectes. La mateixa informació es pot representar usant un diagrama de seqüència i objectes diferents.
  • Diagrama de panorama d’interaccions: hi ha set tipus de diagrames d’interaccions. Aquest diagrama mostra la seqüència en la qual actuen.
  • Diagrama de seqüència: mostra com els objectes interactuen entre si i l’ordre de l’ocurrència. Representen interaccions per a un escenari concret.
  • Diagrama de màquina d’estats: similar als diagrames d’activitats, descriuen el comportament d’objectes que es comporten de diverses maneres en el seu estat actual.
  • Diagrama de temporització: igual que en els diagrames de seqüència, es representa el comportament dels objectes en un període de temps donat. Si hi ha un sol objecte, el diagrama és simple. Si hi ha més d’un objecte, les interaccions dels objectes es mostren durant aquest període de temps particular.
  • Diagrama de cas d’ús: representa una funcionalitat particular d’un sistema. Es crea per il·lustrar com es relacionen les funcionalitats amb els seus controladors (actors) interns/externs.

Modelatge de requisits des de la perspectiva de l'usuari

En el llenguatge unificat de modelatge (UML), un esquema de cas d’ús pot resumir els detalls dels usuaris del vostre sistema (actors) i les seves interaccions amb el sistema. Per construir-ne un, s’utilitza un conjunt específic de símbols i connectors. Un esquema de cas d’ús eficaç pot ajudar l’equip a parlar i debatre sobre:

  • Escenaris on el sistema o l’aplicació interacciona amb persones, organitzacions o elements externs.
  • Punts forts del sistema o l’aplicació que ajuden els actors a aconseguir fites.
  • L’abast del vostre sistema.

Així, quan s’han d’aplicar els diagrames de casos d’ús? Un diagrama de casos d’ús no entra en gaire detall; per exemple, no esperem que modifiqui l’ordre en què es realitzen els passos. En canvi, un diagrama de casos d’ús adequat mostra una visió d’alt nivell de la relació entre els casos d’ús, els actors i els sistemes. Els experts recomanen que s’utilitzin diagrames de casos per completar un cas d’ús textual més descriptiu.

L’UML és el kit d’eines de modelatge que podem utilitzar per crear els diagrames.

Els casos d’ús es representen amb una forma ovalada etiquetada. Les figures de pal representen actors en el procés, i la participació de l’actor en el sistema es modela amb una línia entre l’actor i el cas d’ús. Per representar el límit del sistema, dibuixa un quadre al voltant de l’ús del cas en si.

Els diagrames de casos d’ús UML són ideals per a (vegeu la figura):

  • Representar els objectius de les interaccions entre el sistema i l’usuari.
  • Definir i organitzar requisits funcionals en un sistema.
  • Especificar el context i els requisits d’un sistema.
  • Modelatge del flux bàsic d’esdeveniments en un cas d’ús.
Figura Diagrama de casos d’ús per a una botiga ‘online’

Per respondre la pregunta “què és un diagrama de casos d’ús?”, primer hem d’entendre els blocs de construcció i com utilitzar els components del diagrama de casos. Els components comuns inclouen (vegeu la figura):

  • Actors: els usuaris que interactuen amb un sistema. Un actor pot ser una persona, una organització o un sistema extern que interactuï amb la vostra aplicació o sistema. Han de ser objectes externs que produeixen o consumeixen dades.
  • Sistema: seqüència específica d’accions i interaccions entre actors i el sistema. Un sistema també es pot denominar escenari.
  • Objectius: el resultat final de la majoria dels casos d’ús. Un diagrama amb èxit hauria de descriure les activitats i variants utilitzades per assolir l’objectiu.
Figura Diagrama de casos d’ús per a una web

Llavors, com cal utilitzar símbols i notació de diagrama de casos? La notació per a un diagrama de casos d’ús és bastant senzilla i no implica tants tipus de símbols com en el cas d’altres diagrames UML. A continuació en veurem alguns exemples:

  • Casos d’ús: ovals en forma horitzontal que representen els diferents usos que un usuari pot tenir.
  • Actors: figures de pal que representen les persones que realment utilitzen els casos d’ús.
  • Associacions: una línia entre actors i casos d’ús. En diagrames complexos, és important saber quins actors estan associats amb els casos d’ús.
  • Caixes de límits del sistema: una casella que estableix un abast del sistema per utilitzar casos. Tots els casos d’ús fora de la caixa es considerarien fora de l’àmbit d’aquest sistema. Per exemple, Psycho Killer està fora de l’abast de les ocupacions en l’exemple de motoserra que es troba a continuació.
  • Paquets: una forma UML que us permet col·locar diferents elements en grups. Igual que amb els diagrames de components, aquestes agrupacions es representen com a carpetes d’arxius.

Modelatge de les seqüències dinàmiques d'acció i relacions: diagrames de seqüència

Els diagrames de seqüència són una popular solució de modelatge dinàmic. El modelatge dinàmic s’enfoca en les interaccions que tenen lloc dins del sistema. Els diagrames de seqüència s’enfoquen específicament en les “línies de vida” d’un objecte i com es comuniquen amb altres objectes per realitzar una funció abans que la línia de vida acabi.

Per comprendre què és un diagrama de seqüència, és important saber quin és el rol de l’UML. L’UML o el llenguatge unificat de modelatge és un conjunt d’eines de modelatge que dirigeix la creació i notació de molts tipus de diagrames, inclosos els diagrames de comportament, diagrames d’interacció i diagrames d’estructura.

Tant els desenvolupadors de programari com els empresaris usen aquests diagrames per comprendre els requisits d’un sistema nou o documentar un procés existent. Els diagrames de seqüència de vegades es coneixen com a diagrames d’esdeveniments o escenaris d’esdeveniments (vegeu la figura).

Figura Diagrama de seqüència del sistema bancari

Els diagrames de seqüència poden ser diagrames de referència útils per a les empreses i altres organitzacions. Els usos dels diagrames de seqüència són:

  • Representar els detalls d’un cas d’ús en UML.
  • Modelar la lògica d’una operació, una funció o un procediment sofisticats.
  • Veure com les tasques es mouen entre els objectes o components d’un procés.
  • Planificar i comprendre la funcionalitat detallada d’un escenari actual o futur.

Els diagrames de seqüència estan formats pels següents elements (vegeu la taula). A banda, també podem trobar els símbols de missatges de seqüència UML, que són paquets d’informació que es transmeten entre els objectes i poden reflectir l’inici i l’execució d’una operació o l’enviament i la recepció d’un senyal (vegeu la taula).

Taula: Elements d’un diagrama de seqüències (I)
Element Descripció Imatge
Símbol d’objecte: Aquesta figura de caixa representa una classe o objecte en UML. Demostra com es comportarà un objecte en el context del sistema. Els atributs de les classes no han d’aparèixer en aquesta figura.
Casella d’activació: Simbolitzada amb una figura rectangular, una casella d’activació representa el temps necessari perquè un objecte finalitzi una tasca. Com més temps porti la tasca, més llarga serà la casella d’activació
Símbol d’actor: Es mostren amb una figura de vareta. Els actors són entitats que interactuen amb el sistema, però que són externs a aquest.
Símbol de paquet: També conegut com a marc, és una figura rectangular que s’usa en la notació UML 2.0 per contenir els elements interactius del diagrama. Aquesta figura conté un petit rectangle interior per etiquetar el diagrama.
Símbol de línia de vida: Una línia vertical discontínua que representa el pas del temps a mesura que s’estén cap avall. A més del temps, representa esdeveniments seqüencials que li ocorren a un objecte durant el procés de representació grafica. Les línies de vida poden començar amb una figura rectangular etiquetada o un símbol d’actor.
Símbol de bucle d’opció: Una figura rectangular que conté una etiqueta més petita. Aquest símbol s’empra per modelar escenaris del tipus “Si… llavors…”, és a dir, una circumstància que solament succeirà en determinades condicions.
Símbol d’alternatives: S’usen per simbolitzar una decisió (que, en general, és mútuament exclusiva) entre dues o més seqüències de missatges. Per representar alternatives, empra la figura rectangular etiquetada amb una línia discontínua a l’interior.
Taula: Elements d’un diagrama de seqüències (II)
Element Descripció Imatge
Símbol de missatge sincrònic: Representat per una línia contínua i una punta de fletxa sòlida. Aquest símbol s’utilitza quan un remitent ha d’esperar una resposta a un missatge abans de prosseguir. El diagrama ha de mostrar el missatge i la resposta.
Símbol de missatge asincrònic: Representat per una línia contínua i una punta de fletxa simple. Els missatges asincrònics són aquells que no necessiten una resposta perquè el remitent avanci. Solament la trucada s’ha d’incloure en el diagrama.
Símbol de missatge de resposta asincrònic: Representat per una línia discontínua i una punta de fletxa simple.
Símbol de crear missatge asincrònic: Representat per una línia discontínua i una punta de fletxa simple. Aquests missatges s’envien a les línies de vida per crear-se per si sols.
Símbol de missatge de resposta: Estan representats amb una línia discontínua i una punta de fletxa simple. Aquests missatges són les respostes a les trucades.
Símbol d’eliminar missatge: Estan representats per una línia contínua i una punta de fletxa sòlida, seguida d’un símbol X. Aquests missatges indiquen la destrucció d’un objecte i estan situats en la seva ruta de la línia de vida.

La figura mostra un exemple de diagrama de seqüència que desglossa el sistema de creació i anunci d’un nou esdeveniment en un calendari.

Figura Diagrama de seqüència del sistema de creació i anunci d’un nou esdeveniment en un calendari

Modelatge del comportament dinàmic d'objectes o classes: diagrames d'estats

Un diagrama d’estats, de vegades conegut com a diagrama de màquina d’estats, és un tipus de diagrama de comportament en el llenguatge unificat de modelatge (UML) que s’especialitza a mostrar transicions entre diversos objectes.

Així, què és un diagrama d’estats en UML? Una màquina d’estats és tot el que pugui tenir diferents estats. En molts casos, quan parlem d’estats, parlem dels diferents estats d’un objecte. Els diagrames complexos poden tenir molts estats diferents. Per entendre millor objectes difícils, de vegades té sentit entendre tots els diferents estats possibles d’un objecte i com arriba l’objecte a aquest estat. Els estats són les diferents combinacions d’informació que pot contenir un objecte i no com es comporten.

Els principals elements que representen els diagrames d’estat són els estats i les transicions.

Els estats es capten per mitjà de rectangles arrodonits que s’etiqueten amb el nom de l’estat. Les transicions es marquen amb fletxes que flueixen d’un estat a un altre, i mostren com canvien els estats. A la figura podeu veure aquests dos elements en acció en un diagrama bàsic.

Figura Exemple de diagrama d’estats

Les aplicacions dels diagrames d’estat són les següents:

  • Representar objectes basats en esdeveniments en un sistema reactiu.
  • Il·lustrar escenaris de casos d’ús en un context de negocis.
  • Descriure com es mou un objecte a través de diversos estats al llarg de la seva existència.
  • Mostrar el comportament general d’una màquina d’estats o el comportament d’un conjunt relacionat de màquines d’estats.

Pel que fa als components dels diagrames d’estats, es poden incloure moltes figures diferents en un diagrama d’estats, particularment si tries combinar-ho amb un altre diagrama. Aquesta llista és un resum de les figures més comunes que pots trobar (vegeu la figura):

  1. Estat compost: un estat que conté subestats anidats.
  2. Pseudoestat d’opció: un símbol de diamant que indica una condició dinàmica amb resultats potencials ramificats.
  3. Punt de sortida: el punt en el qual se surt d’un estat compost o d’una màquina d’estats. Es representa amb un cercle amb una X a l’interior.
  4. Esdeveniment: una instància que activa una transició. S’etiqueta amb nom a dalt de la fletxa de transició aplicable.
  5. Estat final: un marcador per al primer estat del procés. Es mostra mitjançant un cercle fosc amb una fletxa de transició.
  6. Protecció: una condició booleana que permet o deté una transició. S’escriu a dalt de la fletxa de transició.
  7. Estat: un rectangle arrodonit que indica la naturalesa actual d’un objecte.
  8. Subestat: un estat contingut dins de la regió d’un estat compost.
  9. Transició: una fletxa que corre d’un estat a un altre que indica un estat canviant.
  10. Comportament transicional: un tipus de comportament resultant que ocorre durant la transició d’un estat. S’escriu a dalt de la fletxa de transició.
  11. Disparador: un tipus de missatge que mou activament un objecte d’estat en estat. S’escriu a dalt de la fletxa de transició.
Figura Exemple dels components dels diagrames d’estats

El següent diagrama d’estats (figura) mostra els diferents estats d’un objecte del calendari, el qual s’ha diagramat previament per mostrar el flux d’algú que defineix un esdeveniment en un calendari.

Figura Exemple de diagrama d’estats

La taula mostra el significat dels diferents símbols i notacions que podem trobar a un diagrama d’estats.

Taula: Símbols i notació per a diagrames d’estats
Símbol Significat
El cercle amb un punt a l’interior significa que un procés està acabat.
El cercle amb una “X” a l’interior significa que un procés està sent evitat.
Els quadres d’estat representen els diferents estats en els quals pot estar una màquina durant un procés.
Un punt negre representa l’inici d’un procés.

Elements d'ajuda, sense valor semàntic, utilitzats en els diagrames

En els diagrames s’utilitzen tres elements d’ajuda que no tenen valor semàntic; ens referim als paquets, les notes i els estereotips (vegeu la taula).

Taula: Elements d’ajuda utilitzats als diagrames
Element d’ajuda Descripció Exemple
Paquets: En algunes ocasions hi ha la necessitat d’organitzar els elements d’un diagrama en un grup. Tal vegada es vol mostrar que certes classes o components són part d’un subsistema en particular. Per fer-ho, es poden agrupar en un paquet, que es representa per una carpeta tabular.
Notes: És freqüent que alguna part del diagrama no presenti una explicació clara de per què és allí o la manera en què treballa. Quan això passi, la nota UML serà útil. La nota té una cantonada doblegada i s’adjunta a l’element del diagrama connectant-lo mitjançant una línia puntejada.
Estereotips: Alguns sistemes requereixen elements fets a mida que no es troben a l’UML. Per això, els estereotips o clixés permeten prendre elements propis de l’UML i convertir-los en uns altres que s’ajustin a les necessitats. Es representen com un nom entre dos parells de parèntesis angulars. «nom»

Modelatge de l'estructura estàtica del sistema: el diagrama de classes

Un mètode ben acceptat en el món del desenvolupament de projectes AMI per relacionar les idees i les descripcions del projecte és fer servir un diagrama de classes. Aquesta eina és una de les més importants dins del disseny de software, ja que us servirà fonamentalment per a poder treballar en equip i poder planificar el desenvolupament d’un projecte. A més a més, estableix d’una manera clara i molt visual la dificultat de programació i quines són les parts crítiques de qualsevol projecte.

Un diagrama de classes és simplement un recull de les classes que interpretem com a necessàries, i les dependències entre elles, donada una definició d’un problema per resoldre o una aplicació per desenvolupar.

Com és d’esperar, no sempre sereu capaços de definir perfectament un diagrama de classes abans de començar. Això és perquè no es pot esperar tenir sempre tota la informació, i tota correcta, des del primer moment. De fet, sovint us trobareu amb imprevistos a mig projecte, amb nous requeriments un cop començat el desenvolupament o, simplement, millorareu la comprensió de la tasca a mesura que passi el temps i us endinseu en el projecte.

És per això que, tot i que la construcció del diagrama de classes és un pas fonamental en el disseny de les vostres aplicacions, i que hauria de ser una de les primeres tasques a fer, no us heu de quedar amb un diagrama immutable. En tot cas, un cop tingueu una primera versió d’aquesta eina, una bona pràctica és distribuir la programació dins el vostre equip, assignant una classe per programador i rebre comentaris, per analitzar si cal introduir millores.

El primer pas per començar a dissenyar el diagrama de classes és entendre el problema profundament. Heu d’assegurar-vos de fer totes les preguntes necessàries i tenir tots els conceptes clars fins al màxim de detall abans de començar a dissenyar el diagrama.

Entendre bé el problema

Diversos científics han dit en més d’una ocasió que, si haguessin d’afrontar un problema, dedicarien el 80% del temps a entendre’l, i el 20% a resoldre’l. Si bé aquests percentatges no han de ser indicatius en absolut, l’esperit d’aquest pensament es manté.

El segon pas és definir les classes; per fer-ho, heu de tenir clar el conceptes de classe i instància. Una classe és la definició d’una idea o concepte, mentre que una instància és un exemple concret del concepte. Per exemple, tots tenim al cap què és una cadira. Això seria una classe. És simplement una idea, una definició. D’altra banda, cada dia seiem en multitud de cadires reals diferents; a l’autobús, a l’oficina, a la cuina tenim cadires que existeixen i que són exemples concrets del concepte que tenim al cap; això són instàncies.

Quan dissenyeu un diagrama de classes, heu de pensar únicament en classes i no en instàncies. Un exemple clàssic són els usuaris. Us pot interessar guardar perfils d’usuari, dels quals voldreu saber-ne el nom, l’edat, l’adreça electrònica… Quan definiu la classe “usuari”, no heu de pensar en un usuari en concret, amb un nom concret o una adreça concreta. De fet, aquestes dades es coneixen com a atributs i són tot allò que defineix una classe des del punt de vista del que interessa a l’aplicació.

Per tant, hi ha multitud de possibles atributs per definir un usuari o una persona, però per a una aplicació concreta n’hi pot haver prou coneixent-ne només tres o quatre. Per exemple, per a una aplicació per conèixer a gent a qui agradi la cervesa, dels usuaris potser només en necessiteu saber l’edat, el nom, el gènere, la preferència de cervesa i algunes fotografies. A priori, no us cal informació com ara la religió, el pensament polític, l’estat civil… A mesura que aneu desgranant les classes, podeu anar-ne detallant els atributs. En tot cas, es pot anar detallant iterativament, millorant progressivament el diagrama.

L’Unified Modeling Language, o UML, és la convenció més acceptada per definir diagrames de classes. En UML les classes es representen amb capses, on el títol de cada capsa és el nom de la classe. A l’hora d’escollir un nom per a una classe, heu de procurar escollir-ne un que sigui clar i concís, que transmeti el concepte de la millor manera possible. Per convenció, no s’utilitzen verbs ni adjectius, sinó que cal fer servir substantius. Els atributs es representen també dins de la capsa, a sota del títol. Per als atributs també fem servir noms, i no adjectius o verbs.

'Unified Modeling Language' (UML)

L’UML, o ‘llenguatge de modelatge unificat’, es va crear als anys noranta combinant diverses tècniques i diversos autors. Consta de diverses versions; l’última és la 2.0, que es va publicar l’any 2005.

Exemple de diagrama de classes

Imagineu que voleu fer un projecte per a desenvolupar una botiga virtual per a mascotes. Això sí, voleu poder oferir un servei de qualitat, i no només vendre els productes, sinó enregistrar informació sobre els clients i sobre les seves mascotes, per poder fer suggeriments de productes complementaris.
Analitzem ara les entitats fonamentals que apareixen en aquest exemple. Hem parlat de mascotes, de clients i de productes. Aquestes seran les classes del vostre diagrama per a una botiga virtual, que, provisionalment, quedarà com a la imatge següent:



Com veieu, el títol de les capses correspon al nom de la classe, que és una paraula clara i concreta. Segueix la convenció que sigui un substantiu en singular.

Per poder estar segurs que esteu definint classes, podeu fer-vos algunes preguntes de comprovació; per exemple, esteu visualitzant un concepte, o més aviat és un exemple concret? Us podeu trobar amb ocurrències diferents del mateix concepte? És a dir, si, per exemple, definim la classe “client”, us podeu trobar amb dos o més clients diferents que compleixin la definició de client. Si no queda clar que és una classe, probablement heu de repensar i repassar la definició del problema per comprovar-ho.

Diferents tipus d'atributs

Davant d’un diagrama de classes, a l’hora de visualitzar les classes, a més del títol, observeu que cada capsa té dos apartats més, que són per als atributs i els mètodes.

Pel que fa als atributs, us podeu trobar amb multitud d’informació que pot descriure una classe. Per exemple, un cotxe es pot descriure per la seva potència en CV, pel seu pes en kg, el seu preu en € i el seu consum en l/km. Tot i ser unitats diferents, des del punt de vista d’un diagrama de classe, aquests atributs són del mateix tipus: números. La notació per als atributs també és simple; es posen dins de la segona capsa, primer el nom de l’atribut i després el tipus, en anglès. Els atributs poden ser:

  • “Integer” (números enters)
  • “String” (cadenes de caràcters)
  • “Boolean” (atributs lògics que poden ser només o cert o fals)
  • “Float” (números amb decimals)

Lògicament, es pot donar el cas que aquests tipus no siguin suficients. Un exemple ben habitual són les dates. Tan vàlid és dir 12/10/1984 com 12 d’octubre de 1984, o d’altres maneres de representar la mateixa data. D’altra banda, no totes les combinacions amb característiques similars formen dates correctes. Per exemple, 35 d’octubre de 1984 no és una data correcta.

L’UML ens permet definir els nostres propis tipus d’atributs; tants com vulguem. Això sí, han de ser possibles de formar a partir de combinacions dels atributs bàsics descrits.

Per poder saber que realment esteu identificant un atribut, us heu de fer algunes preguntes de comprovació, per exemple, saber si defineix d’alguna manera la classe, i si és necessari donat el context del nostre problema. No volem afegir mai complexitat innecessària a un projecte, per tant, ens hem de restringir només a explicitar els atributs que siguin rellevants per al projecte. D’altra banda, si veiem que allò que estem dissenyant no formaria part d’una definició de la classe, pot ser que no sigui un atribut, sinó que sigui un altre element, com ara una classe diferent o una relació.

Exemple de creació d'atributs

Imagineu-vos que teniu una petita empresa que distribueix productes de diferents fabricants. Per tant, les classes que tindreu seran “client”, “producte” i “fabricant”. En aquest cas, a priori no teniu prou informació sobre els atributs que necessiteu. Podeu fer una mica d’investigació de camp preguntant a altres empreses que tinguin programaris similars, i us trobareu que típicament es vol guardar el nom i el correu dels clients. A banda, també voleu guardar el nom dels proveïdors, el nom de cada producte, el seu preu i una descripció. El resultat ens donaria una imatge similar a la següent, amb els atributs necessaris per al projecte:


Ben sovint us trobareu amb classes que tenen un atribut que és una llista d’atributs; per exemple, un equip d’esports pot tenir un nombre indeterminat de jugadors. La notació en aquest cas és: indicar el tipus, seguit del símbol [, el mínim d’elements de la llista, dos punts seguits i el màxim, seguit del símbol ]. A la figura, podeu veure el cas d’un equip que pot estar buit i en principi no tenir un màxim de jugadors.

Figura Atribut del tipus llista

D’aquesta manera, si esteu definint un equip d’un esport concret, amb unes regles de mínims i màxims, també ho podreu fer. Per exemple, un partit de futbol onze ha de jugar amb una alineació inicial d’onze jugadors per equip; a més a més, cada equip pot fer tres canvis. Per tant, en un partit hi poden jugar des de 22 jugadors fins a 28. Com a resultat, afegiríem un atribut de mida variable amb un rang definit, tal com mostra la figura.

Figura Atribut llista de mida variable amb un rang definit

D’altra banda, us podeu trobar que voleu que una classe faci referència a una altra classe. Així, les relacions entre classes són un cas diferent dels atributs; perquè justament la informació ja està representada al diagrama de classes amb una classe i, per tant, afegir-ho com a atribut seria redundant. Per exemple, imagineu un projecte on teniu proveïdors que fabriquen diversos productes, i voleu saber el nom del proveïdor, quins productes fabrica, el nom dels productes, el preu i una petita descripció. Aquesta relació se simbolitza unint les dues classes amb una línia, com podeu veure a la figura.

Figura Relacions entre classes

Continuant amb aquest exemple de relació, assumiu que després de fer diverses comprovacions us trobeu amb les següents premisses: un proveïdor ha de subministrar com a mínim un producte, i un màxim indefinit de productes. Si un proveïdor no us ofereix cap producte, no té sentit guardar la seva informació, perquè no està aportant res al vostre negoci. D’altra banda, no té sentit en general que un mateix producte l’ofereixin diversos proveïdors. Per tant, podeu assumir que cada producte és subministrat per un i només un proveïdor.

Aquestes restriccions s’anomenen cardinalitat de les relacions. Per representar-les es fan servir unes indicacions al voltant dels extrems de la línia d’associació, a prop de les capses de les classes. Es llegeix de la següent manera:

  • Una instància de la classe que està lluny de l’indicador pot estar relacionada amb un mínim i un màxim d’instàncies, expressades a l’indicador.
  • El mínim i el màxim estan separats per dos punts i seguit i, si són el mateix valor, s’indica amb un únic número.
  • D’altra banda, si no és un número definit, s’indica amb un asterisc, i si no hi ha cap restricció (és a dir, pot ser 0 o més) s’indica amb un zero, dos punts seguits i un asterisc.

A l’exemple de la figura veieu com un proveïdor pot tenir un o més productes associats, mentre que un producte ha de tenir necessàriament un proveïdor.

Figura Cardinalitats de relacions entre classes

És important tenir clara la cardinalitat de les relacions per diverses raons. Una d’elles és per claredat i llegibilitat, especialment a mesura que el projecte creix en complexitat. Quan tingueu diagrames de classes amb més de vint classes, conèixer la cardinalitat us facilitarà entendre la imatge global. També és important perquè té un impacte clar a l’hora d’implementar el projecte. Si una relació té cardinalitat d’1, us heu d’assegurar que no es pot instanciar una classe sense validar aquesta relació. Per tant, després de definir que dues o més classes es relacionen, heu de definir la cardinalitat de la relació pensant quantes instàncies com a màxim i com a mínim es relacionen.

El terme instanciar és un terme tècnic que ve de l’anglès to instantiate, i vol dir ‘crear un exemple de’ o ‘crear una mostra concreta de’.

Exemple de diferents tipus de cardinalitats

Per veure un exemple amb diversos tipus de cardinalitats podeu imaginar-vos el disseny de classes que representa la cadena de muntatge d’un cotxe amb diverses versions. Els cotxes poden tenir tres o cinc portes, tindran sempre quatre rodes, i poden venir amb extres o no. Cada peça, portes, rodes o extres, arriba a la cadena de muntatge a través d’un distribuïdor, que a la vegada treballa amb un únic proveïdor. A més a més, sabeu que cada proveïdor treballa amb un únic distribuïdor. L’esquema resultant seria el de la imatge següent:

Definir els mètodes

A més dels atributs, les classes també poden tenir mètodes. Un mètode és tota aquella operació d’una classe que pot ser útil per a una altra classe. Serveix per descriure d’una manera simplificada la funcionalitat de la classe, amb les entrades i sortides que tindrà cada mètode.

Per exemple, si des de la classe “client” voleu accedir a informació de preu de la classe “producte”, heu d’escriure un mètode dins de la classe producte que retorni el preu. D’aquesta manera, no només podreu accedir a la informació des de la classe “client”, sinó des de qualsevol classe.

Com que són operacions, la convenció és que els noms dels mètodes siguin verbs. Els casos més típics són obtenir valors i guardar valors, i la convenció per a aquests casos és fer servir els verbs anglesos get (obtenir) i set (guardar), respectivament. A més a més, la gran majoria de llenguatges de programació no accepten espais entre paraules per definir el nom d’un mètode, per tant per assenyalar que són dues paraules diferents feu servir les majúscules.

Per exemple, per guardar un nom, afegireu un mètode “setNom”, i per obtenir aquest mateix nom, el mètode es dirà “getNom”. També hi poden haver mètodes amb altres finalitats molt diferents, que no tinguin a veure amb obtenir o guardar informació. Per exemple, imagineu una situació on un càlcul sigui molt complex, i voleu executar-lo només quan sigui necessari. En aquest cas, definireu un mètode “executarCalcul”, i el fareu servir quan convingui.

D’altra banda, heu d’explicitar quins són els tipus de dades que necessita el vostre mètode, o dades d’entrada, i quin tipus de dades retorna. Per fer-ho, la convenció és posar les dades d’entrada entre parèntesi, i el tipus de dades després de ':'. Per al retorn, també escriureu ':' i el tipus, després del parèntesi. Per exemple, un mètode per calcular una multiplicació serà: “multiplicar(a:Float, b:Float) : Float”. D’aquesta manera, sabreu quin tipus de dades heu de passar al mètode, i quin tipus de dades ens retornarà.

Els mètodes poden tenir un tipus de dades “Void”. Aquest tipus vol dir que és buit, que o bé no necessita cap paràmetre o bé no retorna res. Es fa servir per deixar clar que no és que faltin paràmetres o hi hagi algun error, sinó que el mètode no té o bé paràmetres o bé valor de retorn, o cap d’aquests.

És cert que això no sempre conforma una informació completa. Per exemple, un mètode per a calcular una arrel quadrada hauria de controlar que no tingués una entrada negativa, perquè el càlcul no seria possible. La manera de resoldre-ho formalment és prou complexa, i se surt de l’abast d’aquest curs, tot i que és possible. De totes maneres, no se sol fer servir a la pràctica, ja que comporta un esforç que en moltes ocasions iguala o supera el de fer la implementació directament.

Lògicament, això no ens interessa, ja que l’objectiu principal del diagrama de classes és esquematitzar amb un nivell d’abstracció prou alt el disseny d’un projecte de software, abans de començar a implementar. La solució en aquest cas, de manera pràctica, seria escriure noms de mètodes prou entenedors per fer explícita la funcionalitat, i escriure les possibles restriccions informalment en comentaris.

En resum, els diagrames de classes són esquemes visuals que es construeixen a partir dels requeriments del problema que cal resoldre. Aquests requeriments són identificar correctament les classes i les seves associacions, a més dels atributs i mètodes de cada classe.

Modelatge dels detalls concrets de la implementació del sistema: diagrames de classes i components

Els diagrames de classes són una eina fonamental a l’hora de dissenyar programari; us permet prendre decisions i començar a veure l’arquitectura del projecte de programari abans de començar la implementació. A més a més, com que és una eina visual, és fàcil de compartir en un equip i iterar sobre el disseny. Finalment, resol d’una manera senzilla una primera aproximació al repartiment de tasques, perquè les classes més complexes es veuen a simple vista, i es poden assignar a individus o petits equips.

El terme iterar és molt comú en el desenvolupament de projectes, i es refereix a acabar una versió (pot ser incompleta) que tingui sentit com a entitat, i tornar a començar per millorar-la o afegir-hi funcionalitat.

Tenir tota la casuística possible resolta en un diagrama de classes és complex. Hi ha una gran variabilitat de possibilitats, i preveure tots els casos amb un nombre reduït d’eines és molt complicat; per això heu de tenir-les clares quan treballeu en escenaris més complexos. És a dir, només tenint clar com es relacionen dues classes i com es simbolitza un diagrama de classes, podeu veure i entendre casuístiques més elaborades: les relacions ternàries o múltiples i les herències.

Relacions ternàries

En primer lloc, per distingir bé els casos, hem de definir què són les relacions binàries. Una relació binària és aquella que involucra únicament dues classes; es diferencia d’un atribut perquè és una entitat que necessita la seva pròpia classe. En el cas, però, que vulgueu relacionar tres classes, us trobeu amb una relació ternària. Si relaciona quatre o més classes, serà una relació múltiple. Aquests tipus de relacions són importants i tenen una casuística pròpia, i una convenció també per a representar-les dins del diagrama de classe.

Les relacions ternàries són ben comunes. Molts cops us les trobareu com una manera d’enregistrar ocurrències d’una relació. Per exemple, quan vulgueu enregistrar una compra, típicament s’enllaça un client, un producte i una factura. D’aquesta manera, en el vostre diagrama de classes heu de poder expressar la cardinalitat de la relació, és a dir, indicar que un client i múltiples productes s’assignen a una factura. Per fer-ho, teniu les mateixes eines que en una relació binària, concretament els números al voltant de les classes. Finalment, una relació ternària s’indica amb un rombe que uneix línies cap a cada classe. A més a més, s’hi pot posar també una petita descripció d’un mot.

Exemple de relació ternària

El següent exemple es tracta d’una relació ternària que indica que un client pot comprar diversos productes, i això resulta en una factura.
A més d’identificar les classes, que són “factura”, “producte” i “client”, heu d’observar que tenen una relació ternària. Al diagrama de classes hi heu d’afegir les unions, i encara quedarà per determinar la cardinalitat. Per determinar la d’una classe, us heu de preguntar quantes instàncies d’aquella classe poden existir per cada instància de les altres dues; és a dir:

  • donat un client i un producte, quantes factures hi pot haver;
  • donat un client i una factura, quants productes hi pot haver, i
  • donada una factura i un producte, quants clients hi pot haver.


Per lògica, us trobeu que donat un producte i un client, podeu tenir 0 o més factures, ja que un client pot comprar més d’una vegada un mateix producte, o no comprar-lo. Això ens indica que la cardinalitat a la banda de les factures és de “0..*”. De la mateixa manera, donat un client i una factura, hi poden haver múltiples productes, tot i que com a mínim en tindreu 1, ja que no té sentit que es faci factura per no comprar cap producte. Per tant, la cardinalitat de la banda del producte serà “1..*”. Finalment, donada una factura i un producte, només es pot tenir un client i, per tant, la cardinalitat de “client” serà d’1. Com veieu a la següent imatge, aquesta relació ternària conforma un petit diagrama de classes:


Les herències

Les herències són un altre tipus de relació en escenaris complexos. En moltes ocasions us podeu trobar amb classes que formen part d’un mateix concepte; per exemple, un gos i un gat poden ser dues classes diferents, però es poden abstreure en una classe mascota; més enllà, qualsevol mascota és un ésser viu. Tot sovint us trobareu que volem tenir atributs, mètodes i relacions que són comunes a dues o més classes, i per tant us convindrà agrupar-les per reduir esforç i possibles errors per redundància. Aquesta és justament la missió de les herències.

La manera de representar una herència és mitjançant una línia que connecti les classes, però on un dels extrems és un triangle. Aquest triangle se situa a la classe més global, i les classes més concretes simplement se situen en la línia, com qualsevol altra relació. En aquest cas, no cal indicar la cardinalitat perquè no és una relació entre dues classes diferents, sinó una indicació que és el mateix concepte, on hi ha algunes particularitats. Per tant, no té sentit parlar de cardinalitat.

Seguint amb l’exemple de les mascotes, podeu definir un diagrama per a un cas on tinguem un passejador de gossos, productes per a mascotes, i gossos i gats. Els productes per a mascotes afecten tant gats com gossos, i tant gats com gossos tenen un nom; per tant, es pot abstreure. D’altra banda, els passejadors de gossos no treballen amb gats, per tant, no es poden relacionar amb la classe “mascota”, sinó directament amb la classe “gos”. Com veieu, no hi ha cap problema per fer associacions, tant amb la classe genèrica com amb les més específiques (vegeu la figura).

Figura Exemple d’herència “gos” i “gat” de la classe “mascota”.

A l’hora de referir-se a cada classe en una herència, es poden expressar com classes pare i fills, per a les classes abstractes i concretes, respectivament. També es pot anomenar superclasse la classe pare, i subclasse la classe fill. Les classes del mateix nivell es defineixen com germanes, o siblings en anglès. No hi ha un límit de nivells ni un límit de fills per nivell; podeu tenir capes d’abstraccions il·limitadament. És a dir, no hi ha cap restricció per tenir una classe que tingui un nombre molt elevat de fills, on cada fill tingui al seu torn un nombre elevat de fills, i així successivament. Això sí, heu de procurar sempre que tot tingui coherència i no abusar del detall innecessàriament. Recordeu que si voleu que el diagrama sigui útil, heu d’incloure-hi només la informació rellevant per cada problema en tot moment.

Pràctica amb diagrames de classes

Tot i que la teoria d’UML és molt més extensa, i abasta molts més casos, n’hi ha prou amb conèixer la base perquè sigui útil i per poder-la fer servir com una eina professional. Sabent com es planteja un diagrama de classes, quins elements formen una classe, com relacionar les classes i descriure detalls com la cardinalitat, ja teniu un coneixement suficient per a molts projectes. El problema pot ser posar-ho en pràctica. Per passar aquesta dificultat, l’única manera és practicant a base d’exemples. Per això, practicarem fer diagrames de classes amb exemples en profunditat.

Imagineu que heu de desenvolupar un projecte per a una empresa de màrqueting anomenada Mar. Per a Mar és fonamental conèixer:

  • El nom de les empreses amb què treballen i també el CIF, per poder facturar.
  • Com que es dediquen al màrqueting, els treballadors de Mar necessiten tenir informació sobre els consumidors dels clients amb qui treballen, per poder ajustar les ofertes apropiadament. En concret, necessiten tenir el telèfon, l’edat i el nom dels consumidors, per fer entrevistes i enquestes.
  • Per tenir una idea del valor dels projectes, Mar també necessita conèixer el nom i sou brut dels treballadors dels seus clients. D’aquesta manera podrà posar un preu ajustat a la necessitat de cada client.
  • Finalment, Mar necessita saber qui són els directius dels seus clients, per poder adreçar-se a ells i poder enviar informació comercial rellevant.

De tota aquesta informació, primer heu de poder extreure les classes. Vistos tots els conceptes que es mencionen a l’enunciat, queda clar que “client” és un dels més rellevants. Per comprovar que és una classe, us podeu preguntar si és un concepte (que sí que ho és) i si és només un exemple concret o una descripció. Mar podria tenir com a clients el client A i el client B, per tant el concepte client no és un una ocurrència concreta, sinó que és una classe.

També necessiteu conèixer els consumidors dels clients de Mar. Aplicant la mateixa lògica anterior, us adonareu que “consumidor” és una classe. Aquí, però, ja es pot veure un problema, i és que “client” i “consumidor” són dues paraules molt properes, i a primera vista no queda massa clar què és què. Per això podeu canviar el nom d’alguna de les dues classes per un altre que sigui també correcte, i que us permeti tenir un diagrama de classe més llegible. En aquest cas, una bona opció pot ser canviar “client” per “empresa”. Si bé és cert que Mar té clients, també ho és que aquests són empreses. Conceptualment aquest canvi no introdueix cap problema i, com es pot comprovar, aporta claredat.

Altres conceptes que apareixen a l’enunciat són els “treballadors” i “directius”. Aquests conceptes es poden generalitzar, ja que tant els treballadors com els directius són persones. A més a més, els consumidors també són persones. Per tant, podem abstreure aquestes tres classes amb la classe “persona”. Això sí, els directius són una subclasse de “treballador”, no de “persona” directament. Això ens dona el diagrama següent (vegeu la figura):

Figura Classes identificades donat l’enunciat

Però, com ho fem ara per relacionar les classes? Doncs, com hem comentat, tant “directiu”, com “consumidor” i “treballador” són subclasses de “persona”, però “directiu” és, de fet, subclasse de “treballador”. Això ens dona el diagrama següent (vegeu la figura):

Figura Relacions entre classes; herència identificada

Ara heu de veure com es relaciona “empresa” amb les altres classes. L’enunciat comenta que cada empresa té treballadors i consumidors; per tant, ha d’estar relacionada amb aquestes dues classes. Una empresa legalment ha de tenir algú que l’administri i no hi ha un màxim legal per nombre d’empleats; per tant, la cardinalitat a la banda de “treballador” serà “1..*” (vegeu la figura).

Aquí, si sou observadors, podeu veure una diferència entre el món real i el nostre diagrama de classes. Tècnicament, un administrador d’una empresa no pot ser un treballador contractat com la resta, sinó que ha de ser autònom. En tot cas, des del punt de vista dels requeriments d’aquest projecte, una persona que faci feina per a una empresa serà tractada com una persona treballadora per aquesta empresa. Formalitzar els detalls no sempre ens convé perquè no aporta res al diagrama i per tant només afegeix una complexitat innecessària.

Figura Relacions entre classes identificades amb la seva cardinalitat

Un cop especificades les classes i establertes les relacions, queda definir els atributs i els mètodes. En aquest cas, molts dels atributs es demanen explícitament. En concret, l’enunciat diu que heu de guardar el nom i el CIF de les empreses. Per tant, aquests són els atributs, i com que són una combinació de caràcters alfanumèrics, tots dos són de tipus “String”.

També és un requeriment conèixer el nom de totes les persones, siguin clients o treballadors. A més, dels consumidors se’n necessita el telèfon i l’edat. Aquí us podeu trobar amb un problema: si simplement guardeu l’edat, cada any haureu d’actualitzar les dades. I, si fos necessari ser precís, no podríeu saber-ho fàcilment d’aquesta manera. Per tant, la millor opció és guardar la data de naixement i dissenyar un mètode per calcular l’edat. Finalment, dels treballadors se’n necessita el sou, que serà un atribut de treballador. Per tant, el diagrama quedarà així (vegeu la figura):

Figura Atributs identificats a les classes

I, respecte als mètodes, per acabar, com hem dit abans, en necessiteu un per calcular l’edat. Així doncs, el diagrama final resultarà de la següent manera (vegeu la figura):

Figura Resultat final del diagrama de classes de Mar

En resum, caldrà que tingueu en compte que:

  1. Els diagrames de classes en UML poden tenir diferents tipus d’associacions entre les classes. Les classes no només poden relacionar-se entre elles de forma binària, sinó ternària o múltiple.
  2. Cal entendre com funcionen aquestes associacions, com es representen i quins casos cobreixen; a més de poder determinar la cardinalitat d’aquestes relacions.
  3. A més a més, les herències permeten abstreure i formar factor comú entre múltiples classes i poder d’aquesta manera reduir la complexitat i redundància del diagrama. És fonamental saber determinar les herències, també, perquè això té un impacte directe sobre la programació del projecte.

Esquemes i models de bases de dades

Un dels reptes més habituals, als quals qualsevol desenvolupador s’enfronta a l’hora de dissenyar una aplicació, és tractar les dades. En moltes ocasions haureu d’emmagatzemar o accedir a dades generades per usuaris o per altres aplicacions; caldrà, doncs, considerar-ho en detall.

Les dades en una aplicació es poden perdre fàcilment. És a dir, si tanqueu una aplicació d’una manera inesperada, o bé el dispositiu on s’està executant es queda sense bateria, o hi ha qualsevol tipus de problema, les dades que no s’hagin guardat en un sistema permanent es perdran. Mantenir aquests valors enregistrats d’una manera estable i segura requereix un esforç a l’hora de programar, i té un cost també en el rendiment d’una aplicació tant en pèrdua de velocitat, com en augment de consum de bateria com en espai en disc dur. Per tant, heu de tenir molt clar:

  • quines dades són les necessàries per al nostre sistema,
  • eliminar redundàncies i
  • tenir clar quin sistema d’emmagatzemament de dades fer servir.

Hi ha múltiples maneres d’assegurar la persistència de dades: podeu fer servir fitxers i abocar-hi les dades directament; pot ser amb un format propi, o bé formats estàndard, podeu fer servir alguna base de dades o inclús connectar-vos remotament a algun servei al núvol i que es gestioni d’alguna de les maneres anteriors. Cadascuna de les opcions té, lògicament, una sèrie d’avantatges i inconvenients:

  • Els fitxers tenen l’avantatge de poder ser llegits per humans, si s’escull un format adequat. Amb un bolcat directe, per exemple serialitzant les dades, us trobareu que carregar i guardar dades pot ser realment senzill. Això sí, no és llegible per humans i, si canvieu el format de les classes, la serialització ja no és possible, i per tant no és gens flexible. Connectar-nos al núvol pot ser una gran opció per a aquells projectes que vulguin ser independents del dispositiu on s’executi el nostre projecte, i inclús admetre aplicacions multidispositiu.
  • D’altra banda, significa haver de programar també la connexió i resoldre múltiples problemes derivats de les casuístiques que es poden donar, com per exemple fallades de xarxa i edició simultània de dades. A més a més, no soluciona el fet que al núvol igualment hi heu de ser capaços de guardar les dades d’alguna manera, que acaba sent una de les altres opcions mencionades.
  • Finalment, les bases de dades suposen una solució molt estesa que es troba en un punt mitjà. Una base de dades és un sistema estructurat d’emmagatzemament de dades, on el gestor de la base de dades és qui s’encarrega d’executar les entrades i sortides de les dades. Aquest gestor és independent dels projectes que es desenvolupin i que requereixin dades, i hi interactua a través d’un llenguatge estàndard.

Al llarg dels anys han existit diversos tipus d’estàndards de llenguatges per interactuar amb bases de dades, i també diferents tipus de bases de dades. Des de fa un temps, l’àmplia majoria de les bases de dades són de tipus relacional.

Una base de dades relacional es pot entendre com un conjunt de taules on cada taula té un nombre de columnes, o camps, definit per nosaltres, i tantes files com dades contingui, on cada fila és una entrada única de dades.

Així, per exemple, podríeu tenir la taula “persona”, on guardar el nom, el cognom i l’edat d’una persona. Aquests atributs serien les columnes de la taula i una fila seria una entrada concreta, com ara “Joan, Coloma, 33”. Lògicament, hi podria haver un nombre elevadíssim de files.

Cada taula, a més a més, cal que tingui un identificador únic, de manera que només coneixent aquell valor es pugui conèixer tota la entrada d’una manera inequívoca. Aquest identificador rep el nom de clau primària.

Si voleu, per exemple, guardar les dades d’una persona, no n’hi ha prou amb guardar el nom i els cognoms, perquè no podeu assegurar que no hi hagi una altra persona que es digui de la mateixa manera. Per tant, es pot afegir un camp extra que pot no ser estrictament necessari per a una aplicació, com per exemple el DNI, o bé es pot afegir una columna generada automàticament que fa la funció de clau primària. Fins i tot es pot donar el cas que una combinació de dos o més camps sigui única, i dissenyar la clau primària com una combinació d’aquestes columnes.

Hi ha molts casos en els quals no hi ha cap camp extra que sigui necessari i que pugui fer de clau primària. En aquests casos es genera un camp automàtic, que es sol marcar com a “id(auto)”.

Sovint es necessita que les taules facin referència les unes a les altres. Per exemple, podeu necessitar una base de dades d’on puguem extreure quins cotxes pertanyen a algunes persones. Els cotxes tenen un identificador únic, que és la matrícula, i les persones es poden identificar amb el seu número de DNI. Ara bé, com relacionem aquestes dues taules? La resposta és amb la clau forana.

Una clau forana realment és una columna que fa referència a una clau primària d’una altra taula. Per exemple, a la taula de persones hi afegiu una nova columna, que és la clau forana de la taula dels cotxes, on hi poseu valors que ens permetin trobar les dades del cotxe propietat de cada persona.

Aquestes operacions es fan a partir del llenguatge anomenat Structured Query Language (SQL), o ‘llenguatge de consulta estructurat’. És un llenguatge molt ben estructurat i definit amb el qual es poden crear, manipular i consultar bases de dades relacionals. Conèixer SQL és, per tant, fonamental per dissenyar aplicacions amb persistència de dades.

Hi ha diverses maneres d’assegurar la permanència de les dades. Probablement, la més comuna és fer servir bases de dades relacionals amb SQL. Això, però, no treu que s’ha de fer una anàlisi de quines dades són necessàries i fer un esquema de l’estructura de la base de dades.

Arquitectures, plataformes i entorns tecnològics

Tot projecte AMI complex ha de tenir en compte no només el repte de programar el codi, sinó tot l’entorn necessari per aconseguir-ho, assegurant que es compleixen els objectius. Cal tenir en compte els usuaris finals, per produir un producte que satisfaci les seves necessitats i no d’altres. A més a més, no tots els suports físics tenen les mateixes característiques. Finalment, cal que els usuaris sàpiguen trobar i instal·lar l’aplicació.

Arquitectura de producció o desenvolupament

Qualsevol projecte ha de tenir una previsió de quins són els recursos necessaris per dur-lo a terme: quants programadors calen? Quina és la experiència mínima necessària per a poder-lo desenvolupar? Quines llicències i entorns de desenvolupament calen? Totes aquestes preguntes sorgeixen per a qualsevol projecte d’una envergadura raonable. Normalment, el sentit comú i l’experiència són les millors conselleres per resoldre els dubtes.

En tot cas, per començar a poder fer aquestes estimacions, es poden seguir algunes guies. Una de molt clara és tenir en compte el diagrama de classes. Cada classe, cada mètode, cada atribut i relació afegeix una complexitat que es transforma en temps de desenvolupament. Per tant, diagrames més extensos volen dir desenvolupaments més llargs.

A més del nombre de classes, cal distingir la dificultat de desenvolupament de cadascuna (per exemple, si una classe té a veure amb una interfície gràfica, molt probablement es trigarà substancialment més). No hi ha una regla clara i fixa, perquè cada projecte té les seves particularitats, sobretot a la part d’interfícies.

Una bona pràctica és agrupar les classes amb components visuals. I també ho és agrupar els elements interactius de cada interfície. Per cada element interactiu haureu de controlar el tipus de valors que s’introdueixen, controlar errors, capturar esdeveniments… Per tant, primer, a l’hora de dissenyar interfícies, heu d’intentar sempre minimitzar els elements interactius i, d’altra banda, per estimar el cost en temps de desenvolupament d’una classe, cal tenir en compte que les interfícies més complexes seran més lentes de programar.

Una bona manera i ràpida de fer una estimació bàsica d’un temps de desenvolupament d’una aplicació és programar una classe de complexitat mitjana, comparativament amb la resta. Mesurant quant es triga a acabar aquesta classe, es pot extrapolar amb la resta.

Un altre mètode, més costós, però més acurat, és elaborar primer totes o bona part de les pantalles d’interacció amb l’usuari i fer el cicle d’ús complet tot i no programar tota la funcionalitat. D’aquesta manera us podeu assegurar que no us deixeu elements importants per falta de previsió o per un disseny que no ha tingut en compte tots els casos possibles. Un cop fet aquest prototip, podeu estimar molt millor el temps necessari per a completar la resta de la funcionalitat.

En un equip sempre hi cal algú amb experiència en desenvolupament de programari per dur a terme projectes. Aquesta persona liderarà l’equip i serà l’encarregada d’escollir la resta de l’equip i distribuir les tasques.

Respecte a les llicències, heu de considerar no només tot allò que quedarà inclòs dins del projecte, sinó també les eines necessàries per coordinar un equip. Per exemple, serveis com Trello o Bitbucket, per poder sincronitzar tasques, són essencials en projectes d’una mida raonable, i també heu de comptar amb la compra de les llicències de sistemes operatius, ordinadors on desenvolupar-los, possiblement editors per programar, serveis per veure estadístiques d’usuari…

És molt complex produir programari; cal prestar atenció als requisits tècnics i preveure’n les capacitats. Com més experiència, més fàcil serà poder predir necessitats i fer estimacions de temps; així i tot, seguint una sèrie de pautes i amb ajuda d’algunes eines, com el diagrama de classes, se’n pot tenir una idea més clara.

Arquitectura de destinació o desplegament

Abans de començar a dissenyar visualment un projecte, heu de pensar en l’usuari final. No serveix de res tenir uns algoritmes excel·lents i una programació elegant i robusta, si qui ha d’utilitzar el programari no el fa servir. Per tant, en tot moment heu de tenir present les possibles limitacions dels futurs usuaris; preguntar-vos: són professionals acostumats a processos molt concrets i definits? Són menors d’edat? Són menors de deu anys? Són persones grans? Es tracta d’usuaris amb disfuncions cognitives, com alteracions de la personalitat? Cal tenir en compte aquestes respostes perquè no només afectaran visualment el vostre projecte, sinó també tot el context que l’envolta.

Per exemple, fer un projecte per a una escola de primària és molt més sensible, perquè heu de poder assegurar que no hi haurà contingut que pugui ferir la sensibilitat dels alumnes ni alliberar les seves dades personals. A banda, depenent de l’edat, és possible que facin falta dispositius més robustos per aguantar caigudes i un tracte físic més exigent. Tot i no ser sempre responsables d’aquests dispositius, sí que hem de ser conscients que tot sovint aquests aparells tenen unes limitacions tècniques importants, que el seu pes sol ser més elevat, i que es poden perdre; per tant, la informació cal que estigui xifrada i protegida per contrasenya.

La millor manera d’assegurar que la vostra aplicació tindrà èxit és posant-vos a la pell dels vostres usuaris. A més, heu d’intentar preveure les situacions més extremes. Per fer-ho, us heu d’imaginar dos o més perfils extrems d’ús de la vostra aplicació. Per exemple, imagineu-vos que feu un projecte d’una aplicació per a una llar de gent gran. Un usuari extrem seria aquell a qui li encanta l’aplicació i la vol fer servir a totes hores, però té problemes de visió i de memòria. Heu de dissenyar la interfície visual de manera que tots els elements interactius siguin prou visibles i prou intuïtius perquè aquest usuari pugui gaudir-ne. Un cop fet, comprovareu que ho heu aconseguit, mostrant la interfície a algú amb aquestes característiques, i deixant que sigui ell mateix qui sigui capaç de moure’s dins l’entorn. Per fer aquesta prova, no cal ni tan sols desenvolupar la interfície, sinó que es pot fer amb papers impresos; d’aquesta tècnica se’n diu disseny centrat en l’usuari.

Un disseny que afavoreixi l’usuari

Una coneguda cadena de menjar ràpid va dissenyar i optimitzar les seves cuines en una pista de tenis. Va dibuixar amb guix els elements d’una cuina i van veure com interactuaven els treballadors que simulaven fer les tasques de cada part. En poques hores, i sense pràcticament cap inversió, van aconseguir trobar la distribució ideal per poder servir el màxim de menjar en el mínim temps.

Tornant a l’exemple de la llar de gent gran, un altre usuari extrem podria ser aquell a qui no li agrada la tecnologia i no hi troba utilitat, a la seva vida. En aquest cas, potser es podria fer una guia impresa en paper, amb una bona explicació feta amb cura sobre què li aporta l’aplicació i com pot començar-la a fer servir de manera senzilla. Tots aquests elements poden ser determinants en l’èxit del projecte, i variaran en cada situació. Per tant, més que una guia concreta, l’important és sempre posar-se a la perspectiva dels nostres usuaris, buscar els casos més extrems i trobar quines serien solucions adients a cada cas.

Des del punt de vista tècnic, heu d’assegurar-vos que controleu els dispositius on s’executarà la nostra aplicació. No sempre serà possible controlar el detall de cada dispositiu, però sí que heu de tenir clar uns mínims. Per exemple, el sistema operatiu és determinant a l’hora de començar a concretar els equips de desenvolupament. Hi ha tecnologies que funcionen a tots els sistemes operatius, però n’hi ha moltes que simplement no. Per tant, heu de conèixer quin és l’entorn final on s’espera poder gaudir de l’aplicació; a dia d’avui hi ha bàsicament tres grans mons:

  • Les aplicacions d’escriptori, on el sistema operatiu Windows és el gran dominador, i, tot i que s’està esforçant per desenvolupar i omplir una botiga d’aplicacions, el cert és que els usuaris estan acostumats a descarregar-les d’internet o a instal·lar-les amb suport físic. Com a conseqüència, tindreu poc control sobre l’entorn final. No sabreu si el dispositiu tindrà panell tàctil, si tindrà una pantalla gran o petita, el país, l’idioma…
  • Els dispositius mòbils, que, en canvi, estan ocupats per dos grans sistemes operatius, iOS i Android, i els dos tenen associats una botiga d’aplicacions molt sofisticada on els desenvolupadors tenen tot tipus d’eines per decidir quina versió es pot distribuir, en quina geografia, tipus de dispositiu… Aquest és el cas més favorable, ja que teniu un control prou específic.
  • El web, que és el cas contrari: es pot executar sobre qualsevol sistema operatiu, diversos exploradors, i pràcticament tota la combinatòria de maquinari possible. Per tant, és el més complicat de controlar, però també l’entorn on és més fàcil arribar al màxim de públic i el que ofereix millor compatibilitat amb tot tipus de dispositius. Hi ha eines per fer compensar la manca de control sobre el maquinari. La més comuna és tenir diverses versions del mateix contingut, i decidir quina versió enviar segons el dispositiu. Ja que vosaltres teniu el control de la distribució al servidor que escolliu, ho podeu aprofitar per adaptar-vos a cada situació.

Finalment, tot sovint us trobareu que el projecte s’ha de poder fer servir en dispositius de plataformes i sistemes operatius diferents, i a més s’han de poder comunicar entre dispositius. Per solucionar aquest problema d’interoperabilitat, moltes empreses ofereixen serveis al núvol a través d’internet. Aquesta solució té diversos avantatges, com el fet que les dades es guarden de manera persistent i que la responsabilitat sobre la protecció de les dades recau sobre una altra entitat. Com que és una tasca fonamental, crítica i normalment molt complexa, molts cops és millor que se’n responsabilitzi algú altre. A canvi, és clar, té un cost econòmic que pot arribar a ser important segons el nombre d’usuaris.

És fonamental conèixer l’entorn final del nostre projecte, és a dir, els requisits d’accessibilitat segons el tipus d’usuari i els mètodes de distribució per tal de trobar la millor compatibilitat amb la plataforma de suport de la informació. Us trobareu amb multitud de problemes que podreu resoldre amb proves inicials, un disseny adient i restringint en la mesura que pugueu els dispositius on s’executarà l’aplicació.

Desplegament d'AMIs

Les plataformes actuals tenen característiques molt diferents l’una respecte de l’altra, tant pel que fa al rendiment com a eines de desenvolupament i desplegament. Així, és important conèixer, almenys, unes línies generals per no confondre les capacitats de cadascuna.

Les arquitectures mòbils com els telèfons intel·ligents o les tauletes opten en la seva majoria per arquitectures hardware basades en ARM. Aquests processadors són cada any més potents, però en rendiment no arriben encara a rivalitzar amb ordinadors d’escriptori. Això és perquè s’enfoquen més a ser eficients energèticament per allargar la vida de les bateries. A més a més, els sistemes operatius de dispositius mòbils (majoritàriament Android i iOS) contenen una sèrie de mesures cada cop més estrictes per evitar que les bateries s’exhaureixin massa d’hora. En aquest sentit, els usuaris són cada cop més sensibles a desinstal·lar aplicacions que saben que consumeixen en excés. Per tant, desenvolupant projectes per a aquestes plataformes cal tenir molta cura amb aquest aspecte.

ARM

ARM és una empresa de disseny de processadors. Els seus dissenys els compren gairebé tots els fabricants de xips de baix consum, com els destinats a dispositius mòbils.

A més, aquests dispositius normalment són molt interessants perquè contenen una gran quantitat de sensors. Gairebé tots disposen de múltiples càmeres, sensors de proximitat, de llum, GPS, acceleració, brúixola… sense oblidar-nos de la connectivitat telefònica i d’internet. Tot aquest conjunt de sensors desemboca en informació que, interpretada correctament, pot donar lloc a aplicacions molt sorprenents. Per exemple, les aplicacions de realitat augmentada fan servir pràcticament tots els sensors d’un telèfon mòbil intel·ligent.

A més a més, el ràpid creixement d’aquesta plataforma, i el fet que està pràcticament ocupada pel duopoli Android i iOS, ha despertat un enorme interès per eines de desenvolupament multiplataforma. Per a aplicacions en 3D hi ha entorns com Unity 3D o Unreal Engine, amb els quals es pot desenvolupar una mateixa aplicació que no requereixi canvis o que aquests siguin mínims entre plataformes. Per a aplicacions en 2D actualment tenim entorns com PhoneGap, Ionic, Native script o React Native.

D’altra banda, les plataformes d’escriptori (tant en ordinadors de sobretaula com en portàtils) tenen, en general, millors prestacions de computació: memòries més ràpides, un disc dur amb molta més capacitat, processadors més ràpids i pantalles més grans. També se’ls exigeix més, la qual cosa resulta en una fluïdesa menor de la que podrien tenir. Aquest fet és molt notable en moltes pàgines web, que tenen versions d’escriptori i mòbils. Les versions mòbils tenen unes capacitats molt menors i mostren molta menys informació d’un cop. Això sí, si obriu aquestes versions en un dispositiu d’escriptori veureu una pantalla tan poc atractiva que no us resultarà útil, i exigireu més al vostre dispositiu. D’altra banda, en el sector professional segueix sent pràcticament imprescindible desenvolupar per a una plataforma d’escriptori. La distribució, en aquest cas, serà o a través de suport físic, com els CD, memòries USB o bé a través de descàrregues per internet i codis d’activació.

En un futur no massa llunyà és més que probable que es convergeixi cap a una única plataforma. En aquests moments ja hi ha propostes de Windows amb arquitectures ARM, i versions d’Android que funcionen en arquitectures de sobretaula. Per tant, la discussió sobre cada plataforma i sobre la distribució està subjecta a molts canvis.

Llançament d'un producte. Aspectes que cal tenir en compte

Tots els sistemes intel·ligents i les plataformes estan convergint cap al mateix concepte: un sistema operatiu desenvolupat per la mateixa empresa que controla també quines aplicacions s’instal·len a través d’una botiga d’aplicacions. Hi ha diverses propostes, més o menys restrictives, per a aquest mateix concepte. Per exemple, tenim les plataformes de sobretaula, dominades per Windows, on el maquinari no està controlat per la mateixa empresa, i les aplicacions es poden instal·lar a través de diverses botigues i no només des de la seva. A l’altre extrem hi ha els dispositius iOS, que únicament poden instal·lar aplicacions de la botiga, que pertany a la mateixa empresa que controla tant el sistema operatiu com el hardware.

A banda dels ordinadors, els telèfons mòbils i els diversos equips d’electrònica de consum, altres sistemes d’exhibició i noves plataformes estan guanyant importància. Els últims anys, diverses empreses s’han esforçat molt per ser rellevants a la TV interactiva. Tenim les propostes de Smart TV de cada fabricant, a més de les d’Apple TV o Android TV. Les videoconsoles també han evolucionat per deixar de ser una simple plataforma de jocs i convertir-se en centres multimèdia amb multitud d’aplicacions i no totes dedicades al joc. Tot i això, també aquestes plataformes tenen en comú que fan servir el mateix concepte doble de sistema operatiu-botiga d’aplicacions (en el cas de les videoconsoles, les botigues físiques també son rellevants, però la tendència és que deixin de ser-ho).

Per tant, ens podem preguntar: què és allò que les fa tan útils? Com podem convèncer els usuaris que facin servir la nostra aplicació i no la dels competidors? Tot i que cada botiga té característiques específiques pròpies, en general fan una feina similar:

  • Des del punt de vista de l’usuari el valor és molt clar: facilita molt la feina de trobar aplicacions adients, ja que està tot agrupat en un mateix lloc, està categoritzat, i té una sèrie de puntuacions i comentaris dels usuaris que fan referència a la qualitat de l’aplicació. D’aquesta manera es pot comparar d’una manera més fiable que amb els comentaris i descripcions del fabricant.
  • D’altra banda, per als desenvolupadors també hi ha avantatges, ja que només posant l’aplicació a la botiga tenen accés a un mercat immens, de centenars de milions d’usuaris distribuïts per tot el món, on tota la feina de monetitzar, establir confiança i distribuir ja està feta. A més, ofereixen un seguit d’eines molt útils per poder fer proves i una distribució efectiva controlant errors i possibles problemes legals. Per això aquest model funciona i la tendència és que totes les plataformes convergeixin al mateix concepte.

Totes les plataformes estan convergint cap a oferir formes centralitzades de distribució d’aplicacions. El concepte és una botiga d’aplicacions on tant els usuaris com els desenvolupadors poden gaudir de diversos serveis que els milloren l’experiència.

A continuació veureu un exemple d’una botiga d’aplicacions dins l’apartat de desenvolupadors, també conegut com la consola per desenvolupadors. En concret, veureu el cas de Google Play, que és segurament la més accessible per a les persones. El cost per poder començar a publicar aplicacions és de 25 dòlars, que es paguen un sol cop i donen accés il·limitat. Un cop pagat, us trobeu que podeu gestionar i afegir múltiples aplicacions dins la mateixa consola. Si n’afegiu una, entrareu en una consola on veureu un panell amb la informació més rellevant.

El primer que veureu són quatre Key Performance Indicators (KPI), que són indicadors rellevants del rendiment de la nostra aplicació. En concret, trobeu informació sobre el nombre d’instal·lacions per usuari, desinstal·lacions, una mitjana sobre la valoració dels usuaris i el nombre de crashes o problemes han tingut els usuaris (vegeu la figura).

Figura Pàgina inicial de la consola de desenvolupadors de Google Play, que mostra alguns KPI

Tot seguit, teniu un apartat relacionat amb el creixement del nombre d’usuaris, amb mètriques sobre instal·lacions per país i un rànquing de països. Finalment, també hi ha informació sobre el llançament de l’aplicació i enllaços a articles que parlen de bones pràctiques (vegeu la figura).

Figura Més KPI de la pàgina inicial de la consola de desenvolupadors de Google Play

A més d’aquesta secció, podeu veure la de Release Management (vegeu la figura). Aquí és on es pot començar a veure el potencial de les eines proporcionades pels desenvolupadors. Normalment, els equips tenen alguna persona o inclús un departament dedicat (potser amb d’altres tasques) a encarregar-se dels llançaments. En aquest sentit, pot fer quatre tipus de llançaments diferents:

Figura ‘Release Management’: espai per definir diferents tipus de llançaments, dins la consola de desenvolupadors de Google Play
  • Un llançament Internal serveix per a fer proves internes, dins de l’equip de desenvolupadors. Cal pujar l’APK a la botiga d’aplicacions, i d’allà començar a omplir tots els camps requerits per tenir la pantalla de descàrrega de l’aplicació des de la banda de l’usuari tal com es vol presentar. Als desenvolupadors els és molt útil per a fer totes les proves necessàries abans d’arriscar-se a fer servir usuaris reals amb errors. Presentar tot el procés és massa llarg i depèn completament de cada botiga, per tant, aquí no l’afegirem. Però el concepte és el mateix a totes bandes, i l’objectiu també.
  • Els llançaments Alpha serveixen per a fer proves amb grups de persones controlats. Les consoles per a desenvolupadors ofereixen maneres per a construir llistes tancades de provadors. En el cas de Google Play, només calen les adreces de correu. A partir d’aquesta llista, els provadors poden descarregar l’aplicació com si ja estigués disponible per a tothom. La diferència respecte als Internal és que en aquest cas els provadors poden ser de fora dels equips de proves, o inclús de fora de l’empresa que desenvolupa el projecte.
  • Avançant en aquesta lògica, els llançaments Beta són molt semblants als Alpha, però el grup és una mica més ampli. Podem obrir aquest tipus de llançaments al públic general, a totes aquelles persones que es vulguin apuntar al programa de llançaments Beta. Si comuniqueu de manera entenedora que aquestes versions no són necessàriament estables i que contenen funcionalitat que no sempre serà definitiva, els usuaris seran tolerants a errades i a dissenys poc clars. L’avantatge d’aquesta manera de distribuir les aplicacions és que es pot monitorar de manera fidedigna l’ús real de cada part de l’aplicació. Es pot controlar si una nova funció agrada o no als usuaris, o si un nou disseny genera rebuig o atrau usuaris. A més a més, rebreu comentaris específics i inclús suggeriments de millora. Fins i tot, si l’aplicació és popular, es filtrarà a la premsa i podreu veure clarament la reacció del públic.

APK

Un APK, o Android Application Package, és el format de les aplicacions d’Android. Qualsevol aplicació en un dispositiu Android és realment un APK instal·lat.

Per apurar i donar el màxim de flexibilitat als desenvolupadors, les consoles els permeten ajustar alguns límits. Per exemple, podeu controlar quins països tenen accés a cada versió. També podeu limitar les versions de sistema operatiu que poden instal·lar l’aplicació, o inclús restringir la mida de pantalla. La raó per la qual podeu voler restringir aquests paràmetres és per a evitar, per exemple, problemes legals en alguns països. Recentment a la Unió Europea hi ha hagut un canvi important de legislació respecte a la privacitat de les dades. En aquest cas, moltes empreses han optat per tenir versions diferents segons la geografia fins a ajustar-se a la normativa i poder convergir a una única versió. D’altra banda, hi ha algunes aplicacions on el disseny és una peça tan fonamental que una diferència important sobre la mida i resolució d’una pantalla resulta una experiència d’usuari molt diferent. Per tant és millor tenir dues versions diferents segons aquests paràmetres. Si bé això és cert per a tots els tipus de llançaments, és normalment en les fases Beta on fareu les proves necessàries i establireu alguns límits. Lògicament, en els llançaments finals l’ideal és no posar límits i tenir tots els casos previstos i provats.

  • Finalment, un llançament Production és molt similar a un de Beta, però sense restricció d’usuaris. Es poden definir encara criteris de restricció sobre algunes característiques, però qualsevol usuari que compleixi els criteris podrà baixar i instal·lar l’aplicació. Una eina addicional que solen oferir les consoles de desenvolupadors és una distribució per onades o per etapes. És a dir, oferir la nova versió primer a un percentatge definit dels usuaris, escollits a l’atzar, obrir una finestra temporal per analitzar-ne l’impacte abans de seguir oferint la nova versió a més usuaris, i apujar aquest percentatge si tot és correcte. D’aquesta manera les empreses eviten descobrir massa tard que una versió nova té algun error que afecta una quantitat massa gran d’usuaris, i poden reaccionar a temps.

A més d’aquestes qüestions, per respondre a la pregunta “què podeu fer per convèncer els usuaris que facin servir la nostra aplicació i no la d’un competidor”, la resposta és que teniu un seguit d’eines per fer-ho. Algunes formen part de les consoles de desenvolupador, com tenir cura de la presentació de l’aplicació i fer servir descripcions amb paraules clau; d’altres són serveis externs, com ara les analítiques de Firebase o els anuncis en xarxes socials.

Els usuaris tenen diverses maneres d’escollir quines aplicacions instal·len als seus dispositius. Una d’elles és la posició dins d’una cerca. Les cerques poden ser per nom o per algun concepte que descrigui les propietats de l’aplicació. Com més amunt estigui, més probabilitats hi ha d’obtenir descàrregues. És una dinàmica molt semblant a la dels resultats d’un cercador web. Per pujar en el rànquing, cal treballar bé la descripció de la nostra aplicació, incloent les paraules clau que els usuaris fan servir a les cerques. Per trobar aquestes paraules, es pot fer una anàlisi dels competidors. Copiant el text i cercant les paraules més repetides, es pot extreure quines són les paraules amb les quals els usuaris troben les seves aplicacions. A partir d’aquí, cal fer una reflexió sobre si la vostra aplicació té alguna diferència que cal incloure, o si cal fer servir les mateixes paraules clau.

Un altre factor que cal tenir en compte és la valoració dels usuaris. Molts usuaris deixaran comentaris sobre l’aplicació, i una valoració numèrica. De manera molt senzilla, com més comentaris i valoracions tingui una aplicació, més confiança genera, i com més positius siguin, més probabilitat d’obtenir descàrregues. Una manera simple d’obtenir les primeres valoracions és animar a tots els coneguts a descarregar-se l’aplicació i provar-la. Més enllà d’això, es pot enviar a mitjans de premsa, blogs especialitzats, etc.

A més a més, per minimitzar els comentaris negatius les consoles ofereixen dues possibilitats: la primera és fer llançaments de tipus Beta, on els usuaris ja entenen que algunes característiques no funcionen correctament, i la segona és poder contestar els missatges. Demanar disculpes per errors i agrair comentaris positius generarà una dinàmica positiva amb els usuaris, tot i que cal preveure que constitueix un gran esforç, magnificat per la diversitat d’idiomes en què ens podem trobar les ressenyes.

Finalment, la presentació de l’aplicació dins la botiga, just abans de la descàrrega, és fonamental. Com més esforç es dediqui a presentar visualment l’aplicació, més atractiva serà. En aquests casos, comptar amb un bon treball de disseny marca la diferència.

A part d’aquests factors, la qüestió subjacent és millorar l’aplicació per fer-la o bé més útil, o bé més atractiva o bé més rendible, per aconseguir augmentar l’ús de cada usuari, el nombre d’usuaris o la monetització per usuari. En aquest sentit, cal poder monitorar bé l’ús de l’aplicació mitjançant eines d’anàlisi. Són normalment serveis externs que s’integren dins del desenvolupament de l’aplicació (donada la varietat i complexitat que tenen, no caben dins del temari d’aquest curs, però podeu trobar més informació a firebase.google.com o appscatter.com/).

Selecció dels equips i les eines de producció

Un cop tingueu tots els requeriments clars sobre el tipus d’usuaris finals, l’arquitectura dels dispositius i l’experiència d’usuari, a més de tota la documentació preparada, com ara el diagrama de classes, l’estructura de la base de dades o les interfícies d’usuari, ja podreu començar a desenvolupar el projecte AMI. En aquest moment inicial, cal preparar tot l’entorn necessari, no només per escriure codi, sinó per fer proves i avançar feina de manera eficient. Per programar i fer proves calen essencialment dues coses: programari i maquinari. Caldrà, doncs, prestar especial atenció a la seva elecció, i també la de les diverses eines que necessitareu.

Com que comprar equips té un cost, cal tenir molt present el tipus de projecte per ajustar d’una manera adient la màquina amb la qual treballar. Si cada cop que es vol provar alguna cosa es triguen minuts a veure el resultat, es perdrà agilitat, s’acabaran ajornant o fins i tot evitant les proves. A més a més, l’afegit de tots els minuts d’espera al llarg d’un projecte sumaran una quantitat molt més alta del que ens podem imaginar. Tot això té un cost que en molt poc temps supera amb escreix el cost de molts equips. Per tant, no cal tenir por de sobredimensionar les màquines amb les quals es vol treballar.

Dit això, cal sobredimensionar particularment aquells components que seran més crítics depenent del projecte. Per exemple, en general el rendiment els jocs depèn de la targeta gràfica. Per tant, un projecte amb una gran càrrega gràfica hauria de ser desenvolupat amb màquines que tinguin bones targetes gràfiques. Aquells equips que es dediquin a compilar projectes o a exportar-los a diferents plataformes, haurien de tenir processadors, memòries i discs durs més potents i ràpids.

Com escollir programari és menys evident. Cada projecte té unes necessitats concretes, i cal abordar-les individualment. No obstant això, com a mínim cal un editor de codi, un sistema operatiu, un gestor de repositoris, un sistema per poder anotar tasques per fer i errors per corregir, i tot el que calgui per a fer proves del projecte. Cada element de la llista anterior depèn en gran mesura dels requisits del projecte, per tant és difícil generalitzar. Això sí, cal també assegurar la compatibilitat de totes les eines; siguin de creació i retoc visual, o d’integració i desenvolupament.

Eines de producció i desenvolupament

És molt probable que un projecte també necessiti algunes fonts visuals, com icones, textures i imatges. En altres casos caldran fonts més específiques, com animacions, malles en 3D o so. Per internet hi ha multitud de recursos, molts cops gratuïts, per trobar aquestes fonts. Aquests en són uns exemples: www.flaticon.com/free-icons/library, www.turbosquid.com, freesound.org/browse/tags/sound-effects/. Cal sempre llegir bé els drets d’ús per a cada recurs i assegurar-se de complir tots els requisits que mencionin.

Per editar aquests arxius, hi ha disponibles una gran quantitat de programes, i molts són multiplataforma, de codi obert i gratuïts. Per exemple, el Blender (www.blender.org) és un estàndard per a treballar amb malles i animacions en 3D; l’Audacity (www.audacityteam.org) és un dels editors de so més utilitzats i coneguts; i, finalment, el GIMP (www.gimp.org/) conforma una alternativa molt potent i gratuïta a programes molt coneguts d’edició d’imatges. En resum, tot i que trobar, produir i editar fonts és costós en temps i esforç, és ben possible fer-ho fins i tot de manera gratuïta.

Respecte a la integració i el desenvolupament de programari, el component més essencial és escollir un editor adient, ja que és, molt probablement, l’eina amb la qual els programadors s’hi passen més temps, i és que els editors fan molta feina per facilitar la feina als desenvolupadors. Per exemple, completen automàticament bona part del codi, reduint els errors i augmentant la productivitat. A més a més, ressalten les paraules clau i algunes estructures del codi per facilitar-ne la visualització, i també afegeixen tabulacions automàticament per a les estructures niades, tot seguint les bones pràctiques de cada llenguatge. Hi ha tota una varietat d’editors disponibles, i en molts casos escollir el millor depèn del llenguatge i l’entorn de desenvolupament. El Visual Studio visualstudio.microsoft.com és un dels més complets i utilitzats, i una versió reduïda i gratuïta és el Visual Studio Code code.visualstudio.com/.

A més d’un editor adient, cal tenir un control de versions. Serveis com Github, amb el protocol Git, permeten guardar i restablir versions; a més de poder treballar en equip sobre el mateix codi sense molestar la resta dels companys o companyes.

Operació i seguretat de l'entorn de producció o desenvolupament

Tot i que el desenvolupament de programes no sembla a priori un entorn de risc, el cert és que hi ha perills que son fàcils d’evitar i cal fer-ho. Per exemple, hi ha diverses complicacions i malalties associades a una mala postura, i és evident que els desenvolupadors es passen moltes hores asseguts davant d’una pantalla. Però a més dels riscos físics, també hi ha precaucions que cal prendre respecte a les dades. Cal assegurar-se que les dades no es perden i que es fa tot el possible per protegir-se d’intrusos i de còpies il·legals.

Legislació sobre prevenció de riscos

Els convenis col·lectius i la legislació actual sobre prevenció de riscos tenen apartats concrets sobre la feina d’oficina. Els programadors són, probablement, les persones a qui més s’adreça aquesta legislació, per la quantitat d’hores en postures similars. No parar atenció a aspectes com l’altura de la pantalla respecte als ulls o una postura adequada pot provocar articulacions adolorides al cap d’un temps o dolor crònic. Actualment hi ha solucions, com les taules per treballar dret. Fins i tot es poden trobar al mercat solucions per poder treballar en una cinta mecànica mentre es camina.

Cada persona té les seves preferències i potser també d’altres limitacions paral·leles, per tant, davant del dubte cal preguntar als experts. Les empreses d’una certa mida estan obligades a impartir cursos de prevenció de riscos on es pot preguntar lliurement qualsevol dubte. Si no, sempre es pot preguntar al metge de capçalera.

Aspectes ambientals i eficiència energètica

Actualment pràcticament tota la comunitat científica està d’acord que el clima canvia degut a l’acció humana. Consumim en global molta energia i ho fem alliberant residus al medi ambient. Les conseqüències d’aquest canvi climàtic poden ser absolutament devastadores si no es fa res per evitar-ho.

Molts governs i institucions públiques han marcat alguns objectius a escala nacional i global, però és a les mans de tots contribuir a pal·liar el canvi climàtic. És per això que moltes de les grans multinacionals han anunciat plans per neutralitzar el seu impacte a la natura. Per exemple, Apple i Google ja s’han compromès a obtenir tota la seva energia de fonts renovables, i Samsung ha anunciat recentment que ho aconseguirà al 2020. Aquestes són notícies transcendentals, ja que són empreses amb desenes de milers de treballadors i una gran quantitat de servidors funcionant les 24 hores del dia, amb la qual cosa el consum que generen és realment elevat.

Tot i que seria desitjable, no totes les empreses han fet aquest pas. De totes maneres, com a individu és possible contribuir a reduir el consum. Per exemple, moltes de les màquines tenen diferents modes energètics, i no sempre cal escollir el més potent. En moltes ocasions es poden activar modes ecològics o de baix consum. A més a més, també es poden escollir equips i components en funció del consum. També, és clar, és un bon costum apagar les màquines quan no es preveu utilitzar-les. Aquesta mesura, a més d’estalviar energia i diners, evita atacs maliciosos dels pirates informàtics (hackers).

A més de bones pràctiques, també es poden avaluar les tecnologies en funció del consum. Un exemple molt clar és Blockchain. Aquesta és una tecnologia d’emmagatzemament distribuït que té unes característiques molt atractives per a segons quines aplicacions. Això sí, és realment ineficient en l’aspecte del consum energètic. De fet, es calcula que Bitcoin, una de les aplicacions de Blockchain més conegudes i utilitzades, consumeix més que l’energia consumida per molts països junts. Si tenim en compte que tots els projectes que es poden implementar amb Blockchain també es poden implementar amb altres tecnologies com el núvol, una manera molt eficaç de millorar l’eficiència energètica és no fer servir Blockchain, si no és imprescindible.

Permisos d'accés a la informació: controlats i discrecionals

L’accés a la informació és una part clau del desenvolupament en la gran majoria de projectes, més encara en aquells que tractin dades personals dels usuaris. De fet, recentment la Unió Europea ha dictat noves normatives respecte a les dades personals. Però no és l’únic cas en què cal tenir molta cura de les dades. Entorns com l’educació amb menors o l’àmbit sanitari són especialment sensibles, i aquells projectes relacionats amb la defensa o amb contractes restrictius respecte a les dades són especialment sensibles. El primer que cal que tingueu clar i definiu de seguida és:

  • quin tipus de dades és sensibles i
  • quin tipus d’usuaris hi pot accedir.

Per exemple, en un joc hi poden haver diversos perfils: els jugadors, els observadors, els organitzadors i els creadors del joc. Cadascun d’ells ha de poder tenir accés només a les dades que li corresponen. De fet, un dels recursos més utilitzats pels jugadors que volen fer trampes és veure el joc com un observador, per tenir accés a informació que d’altra manera no podrien veure. D’altra banda, típicament els creadors del joc poden voler conèixer l’ús del joc per part dels jugadors per poder-lo mantenir correctament, o per millorar-ne algun aspecte. Això sí, no han de poder veure dades personals o contrasenyes. És important tenir-ho clar, perquè el fet de crear i distribuir una aplicació no ha de donar peu a poder veure la informació privada dels usuaris. Fins i tot amb consentiment explícit d’un usuari només en casos excepcionals s’hi hauria de poder accedir.

El mètode més utilitzat per assegurar accessos correctes és crear grups d’usuaris, i marcar a les dades sensibles quins grups d’usuaris hi tenen accés. A més a més, sempre cal xifrar aquestes dades per prevenir que els atacants puguin copiar les bases de dades i saltar-se aquestes restriccions. Després de casos ben sonats d’atacs amb èxit, les empreses han entès que no poden treballar d’una altra manera. Avui en dia ja és excepcional trobar que els atacants han pogut entrar a bases de dades i les han pogut llegir sense problema.

També comença a ser la norma utilitzar sistemes d’autenticació amb més d’un pas. En aquest cas, cada pas significa part de la clau. Per exemple, una autenticació en dos passos pot ser: una cosa que l’usuari sap, i una cosa que l’usuari té. Per la ràpida expansió dels telèfons intel·ligents, la combinació sol ser una contrasenya i una interacció al telèfon. Ja es comença a parlar, però, d’autenticacions en tres passos: una contrasenya, una interacció al telèfon i un reconeixement biomètric. Si bé mai és possible garantir la privacitat dels usuaris, amb una autenticació tan sofisticada serà excepcional ser vulnerables als atacs.

Anar a la pàgina anterior:
Exercicis d'autoavaluació
Anar a la pàgina següent:
Activitats