ITIS

ISTITUTO TECNICO INDUSTRIALE STATALE E. Fermi Mantova

anno scolastico 2007/2008

Instant Messaging

Tesi di Cappelli Gino

Sezione 5^A informatica

INDICE INTRODUZIONE...... 2 SPECIFICA DEI REQUISITI ... 4 La realt di riferimento...................... 4 Il modello Client/Server................................................ 4 Suddivisione del carico elaborativo.............................. 5 Controllo degli accessi................................................... 6 Il Database..................................................................... 6 Lapplicativo software................................................... 8 Laccesso al sistema...................................................... 9 Una visione astratta....................................................... 10 Ambiente di sviluppo e testing...................................... 11 Riassunto....................................................................... 11 PROGETTAZIONE DEL DATABASE .................................... 12 Progettazione concettuale.............................................. 12 Progettazione logica...................................................... 13 Progettazione fisica....................................................... 14 Web Server.................................................................... 15 PROGETTAZIONE DELLAPPLICATIVO ........................... La soluzione software................................................... I socket.......................................................................... API C MySql................................................................ Interfacciamento al database........................................ Linterfaccia grafica, la presentazione del risultato..... Le classi C++................................................................ PROJECT MANAGEMENT .................................................... Il progetto iniziale......................................................... Obbiettivi di progetto.................................................... Attivit.......................................................................... Le risorse (il calendario, i costi)................................... 16 16 16 18 19 19 22 23 23 23 23 23

CONCLUSIONE ....................................................................... 24
2

1 - INTRODUZIONE
Nella seguente trattazione si vuole riassumere sinteticamente il lavoro svolto per progettare un Instant Messaging (software di messaggistica istantanea) in C++, molto simile a Messenger di Microsoft (figura 1). Nella prima parte verr trattata tutta la fase della specifica dei requisiti, che consiste nella raccolta di tutte quelle informazioni necessarie alle fasi successive di progettazione. Si proporr quindi unanalisi di tutte le caratteristiche e specifiche riguardanti il software e della la realt in cui dovr operare. Nella seconda parte si progetter il Database dellapplicazione, necessario a contenere importanti informazioni come ad esempio i dati degli utenti. Nella terza parte verr progettato lapplicativo software, quindi si prenderanno in ingresso tutti i dati delle fasi precedenti e si cercher di implementarlo in modo da soddisfare tutte le specifiche imposte precedentemente. Infine nella quarta parte si far una breve raccolta di informazioni riguardanti il progetto (Project Management), quali ad esempio: gli obiettivi di partenza, i costi, le attivit svolte, le risorse disponibili etc.

Figura 1 La finestra di login (accesso)

2 - SPECIFICA DEI REQUISITI

2.1 LA REALTA DI RIFERIMENTO Il software deve poter operare attraverso internet, perci su rete TCP/IP. Ovviamente anche in rete locale LAN (Local Area Network), in modo da soddisfare sia le richieste degli utenti che vogliono poter comunicare da casa propria con amici (per semplice svago) sia le richieste di coloro che intendono comunicare solo in una propria rete locale per questioni di lavoro (magari enti privati). Nel primo caso il carico di utenza (numero di utenti che effettuano laccesso per poter comunicare con altri utenti) e molto elevato, in quanto chiunque pu procurarsi una copia dellapplicazione ed iscriversi al servizio (i termini del servizio verranno analizzati successivamente). Nel secondo caso invece il carico dutenza e abbastanza basso, in quanto gli unici utenti che possono usufruire del servizio sono quegli utenti che frequentano la sede in cui collocata la rete privata. Si vuole quindi fare in modo che ogni utente possieda una propria lista di contatti con cui pu, nel caso siano in linea (connessi), comunicare attraverso rete TCP/IP. Per comunicare si intende ovviamente scrivere messaggi di testo. 2.2 IL MODELLO CLIENT/SERVER Per poter soddisfare alle richieste del paragrafo 2.1 necessario adottare un modello molto diffuso chiamato Client-Server (letteralmente cliente-servitore). Il modello client/server prevede per lappunto un Server (servitore) che attende ad accetta le connessioni di vari Client (clienti) offrendogli un servizio. Ad esempio un utente (Client) attraverso uninterfaccia utente si pu connettere ad un Server, che pu ad esempio essere rappresentato da uninsieme di database, e facendo opportune richieste a questultimo pu ottenere informazioni contenute allinterno dei database. Nel nostro caso ogni macchina assume sia il ruolo di Client che di Server: pu ricevere richieste di connessione da qualsiasi utente (che intende comunicare con lui) e pu alla stesso modo fare connessioni verso qualsiasi altro utente. Perci ogni macchina avr un Server attivo che attende richieste di connessione (sulla porta 3000) ed un vettore di Client con cui fare connessioni verso gli altri utenti (ovviamente sulla porta 3000): in questo modo la comunicazione garantita in entrambe le direzioni (Figura 2). Il modello verr approfondito successivamente.

Figura 2 Semplificazione del modello Client/Server di Comunicate

2.3 SUDDIVISIONE DEL CARICO ELABORATIVO A questo punto bisogna decidere come suddividere il carico elaborativo tra Client e Server, o meglio che operazioni deve compiere ogni Client ed ogni Server. Ogni Client potr: Fare una connessione verso un Server: in questo caso far semplicemente la connessione verso questultimo. Inviare messaggi verso un Server: attraverso uninterfaccia lutente scrive il messaggio e lo invia al Server. Ricevere messaggi dal Server: ogni Client in grado di inviare messaggi ma anche di ricevere messaggi. I messaggi inviati e ricevuti verranno visualizzati in unopportuna interfaccia (o meglio finestra di conversazione) visibile allutente. Per ogni connessione dovr essere creata una diversa finestra di conversazione, quindi si potr comunicare con pi contatti contemporaneamente. Ogni Server dovr: Ricevere connessioni da diversi Client: una volta accettata la connessione dovr aprire uninterfaccia utente (finestra di conversazione) dove visualizzare i messaggi in arrivo dal Client. Creare diversi oggetti Server (questa espressione verr chiarita successivamente): con cui lutente pu rispondere (inviare messaggi) ai Client di cui ha accettato la connessione (ogni server in grado di ricevere ma anche di inviare messaggi). Tutti i messaggi inviati e ricevuti verranno visualizzati nella finestra di conversazione prima creata. Per ogni connessione dovr essere creata una diversa finestra di conversazione. Nella figura 3 mostrata la finestra di conversazione che utilizza Comunicate.
6

Figura 3 La finestra di conversazione di Comunicate: uninterfaccia in cui possibile visualizzare i messaggi inviati e ricevuti

2.4 IL CONTROLLO DEGLI ACCESSI Ogni utente possiede un proprio profilo opportunamente memorizzato sul database centrale, per cui ad ogni accesso lutente dovr inserire i propri dati. Il software provveder a connettersi al database e a controllare la veridicit dei dati inseriti: se i dati inseriti sono presenti (Username e password, come mostrato in figura 1), si aprir la finestra contenente tutta la lista dei contatti che appartengono allutente. 2.5 IL DATABASE Come gi accennato presente un database centralizzato con tutti i dati degli utenti quali username (identificativo), password, elenco dei contatti dellutente, stato dellutente (in linea, non al computer, sconnesso ecc) pi altre informazioni di servizio. Il database viene interpellato/utilizzato: Quando ci si connette: in quanto si devono modificare alcune informazioni di servizio quali ad esempio lo stato dellutente (in linea, non in linea). Per la stessa motivazione del primo punto, quando ci si sconnette. Quando si deve scaricare la lista dei propri contatti (figura 4).
7

Quando si deve aggiungere/eliminare un contatto (figura 4) o un profilo (registrazione di un nuovo utente, figura 5). Quando ci si sconnette per aggiornare alcune informazioni di servizio.

Figura 4: La finestra contenente la lista dei contatti di Comunicate.

Figura 5 La finestra di registrazione di un nuovo utente

2.6 LAPPLICATIVO SOFTWARE Lapplicazione gi stata in buona parte descritta, riassumendo quello gi detto: Allavvio dellapplicazione si avvia la finestra di login (figura 1). Dalla finestra di login possibile compiere 2 operazioni: 1) Inserire i propri dati ed accedere. 2) Registrare un nuovo profilo con cui poter accedere (figura 5). Una volta effettuato laccesso la finestra di login scompare e viene visualizzato la finestra contenente la lista di tutti i contatti dellutente (figura 4). Da questa finestra possibile compiere varie operazioni: o Selezionare un contatto in modo da aprire una finestra di comunicazione (figura 3) con quel contatto e potergli inviare messaggi. o Aggiungere/eliminare contatti. o Eliminare il proprio profilo se lo si desidera.
9

Bisogna precisare che presente anche una finestra chiamata Registro (figura 6) contenete tutti gli eventi accaduti dallavvio del programma, quali ad esempio accesso, aggiunto nuovo utente, inizializzazione lista ecc Questa finestra accessibile in qualsiasi momento.

Figura 6: Il registro di Comunicate

2.7 LACCESSO AL SISTEMA Come gi accennato nel paragrafo 4 laccesso al sistema avviene effettuando un controllo sui dati inseriti dallutente interpellando un database centralizzato. Ci sar perci un server anchesso centralizzato (accessibile a qualsiasi utente indifferentemente dal nodo della rete in cui si trova) che attende connessioni sulla porta 1990 (non necessariamente la 1990, si pu cambiare) e che pu rispondere a varie interrogazioni (quali: la lista dei contatti, i dati di unutente ecc) andando a fare un controllo sul database centralizzato come mostrato in figura 7. Sono permesse (o meglio il server permette) anche operazioni di inserimento e cancellazione.

Figura 7 Il server centralizzato

10

2.8 UNA VISIONE ASTRATTA Ci che stato detto fino ad adesso pu essere schematizzato dalla seguente illustrazione:

Figura 8 : Unillustrazione di come avviene lo scambio di dati fra le varie entit

In seguito chiariremo meglio il significato delloggetto server.

11

2.9 AMBIENTE DI SVILUPPO E TESTING Per lo sviluppo ed il testing dellapplicativo si scelto di utilizzare Code Bloks. Code Bloks un IDE (Integrated development environment) che supporta i linguaggi di programmazione C e C++. Per quanto riguarda il database si scelto di utilizzare mySql Server 5.0 che mette a disposizione vari tool che permettono di ridurre notevolmente i tempi di lavoro. Nel capitolo 5 si chiarir meglio il motivo di tali scelte. 2.10 RIASSUNTO Riassumendo: Allavvio dellapplicazione viene mostrata la finestra di Login (figura 1). Lutente inserendo i propri dati (Username e password) nella finestra di Login potr effettuare laccesso. Per effettuare laccesso il programma dove connettersi al Server centralizzato e controllare se i dati dellutente sono veritieri (figura 7). Il Server centralizzato ovviamente si connette a sua volta al Database centralizzato (presente sulla stessa macchina del Server) contenente tutte le informazioni degli utenti. Se laccesso va a buon fine viene visualizzata la propria lista dei contatti (figura 4). Selezionando un contatto (per esempio il contatto prova2 di figura 4) possibile aprire una finestra di conversazione (figura 3) con cui possibile comunicare con quel contatto. Quando si seleziona un contatto si apre un Client sulla propria macchina che effettua una connessione verso il Server presente nella macchina del contatto. Il Server crea perci un proprio oggetto Server con cui accetta la connessione del Client e la comunicazione pu avere inizio. Lo scambio di dati fra le varie entit schematizzato in figura 8.

12

3 PROGETTAZIONE DEL DATABASE

Come gi detto nel capitolo precedente presente un Database centralizzato ed un Web Server che attende connessioni sulla porta 1990. Scopo di questo capitolo quello di approfondire la struttura del Database in ogni suo aspetto. 3.1 PROGETTAZIONE CONCETTUALE Il Database formato da due tabelle: Tabella profiles: questa tabella contiene tutti i profili degli utenti. Tabella contacts: questa tabella contiene tutti i contatti degli utenti. Ogni profilo caratterizzato dallUsername dellutente, dalla sua password, dal suo stato (in linea, occupato, al telefono, ecc), da una variabile che indica se connesso o meno, dallindirizzo IP della macchina corrente in cui si trova (si vedr nel prossimo capitolo che necessario per lapplicativo) e dallindirizzo IP pubblico della rete in cui si trova. Ogni contatto associato ad un profilo (o meglio appartiene ad un profilo: ogni profilo (utente) ha i propri contatti) perci caratterizzato dallUsername del profilo e dallUsername del contatto (cio lUsername del profilo che si intende aggiungere come contatto, in modo da potergli inviare messaggi). Tutto ci si pu riassumere nel seguente diagramma ER:

Figura 9 Lo Schema ER del Database 13

ServerUp: una variabile che indica se si connessi o meno (assume il valore 1 oppure 0) Status: indica lo stato dellutente, assume i seguenti valori: 0: in linea (default) 1: occupato 2: torno subito 3: non al computer 4: al telefono 5: a pranzo 6: invisibile (in linea ma non visibile dagli altri utenti) La scelta dello stato si effettua nella finestra di Login prima dellaccesso:

Figura 10 Nella finestra di Login lutente seleziona il proprio stato

3.2 PROGETTAZIONE LOGICA Lo schema ER del paragrafo precedente si pu tradurre nelle seguenti 2 tabelle SQL:

PROFILES(Username, Passwrd, ServerUp, CurrentIp, Status, CurrentPublicIp) CONTACTS(Index , Username, Contact)

Il campo Passwrd unabbreviazione di Password. Nella figura 11 mostrata una rappresentazione grafica delle tabelle.
14

Figura 11 Le tabelle del Database

3.3 PROGETTAZIONE FISICA Per implementare le tabelle si utilizzato MySql Server 5.0 per i seguenti motivi: Oltre ad avere elevate prestazioni open source Mette a disposizione un web Server (paragrafo 4) Dispone di un tool chiamato MySql Query Browser che premette di implementare le tabelle e fare interrogazioni in breve tempo grazie allinterfaccia grafica Dispone di un tool chiamato MySql Administrator che permette la gestione degli utenti e dei diritti del database sempre grazie ad uninterfaccia grafica Qui di seguito vengono riportate alcune interrogazioni SQL con opportuna spiegazione (si tenga presente che comunicate il database, profiles e contacts le tabelle):

SELECT * FROM comunicate. profiles; ( lelenco di tutte le tuple della tabella profiles)

SELECT Username, Passwrd FROM comunicate.profiles WHERE Username='utente1 AND Passwrd=utente;

( i dati dellutente che ha come Username uetnte1 e come password utente)

SELECT A.Username, A.ServerUp, A.CurrentIP, A.Status, A.CurrentPublicIP FROM comunicate.profiles AS A, comunicate.contacts AS B WHERE utente1=B.Username AND B.Contact=A.Username; (I dati di tutti i contatti di utente1)
15

3.4 WEB SERVER Il web server (figura 7,capitolo 2 paragrafo 7) attende connessioni sulla porta 1990 (si scelta questa porta per non andare in conflitto con altri servizi attivi sulla stessa macchina) e si interpone tra lutente (la macchina dellutente) ed il Database. Questo Server pu accettare connessioni anche da postazioni remote per cui ogni utente pu accedere al proprio profilo da qualsiasi postazione connessa a internet (nel caso della rete locale da qualsiasi postazione connessa alla rete LAN).

Figura 12 Uno scenario client-server

Il web Server ed il DBMS si trovano sulla stessa macchina.

16

4 PROGETTAZIONE DELL APPLICATIVO

4.1 LA SOLUZIONE SOFTWARE Come gi accennato nel capitolo 2 per lo sviluppo dellapplicativo si scelto di utilizzare il linguaggio di programmazione C++ (alcune parti sono state scritte in C). Questo linguaggio dispone di una vasta gamma di librerie per limplementazione della GUI (graphical user interface), per la gestione delle connessioni TCP e per la gestione degli accessi al Database. Per lo sviluppo della GUI si scelto di utilizzare le librerie grafiche wxWidgets che mettono anche a disposizione decine di classi per il trattamento dei file e delle stringhe. Per quanto riguarda le connessioni TCP le wxWidgets mettono a disposizione molte classi per lo sviluppo dei Socket (paragrafo 2). Infine per le connessioni al Database si sono utilizzate le librerie C MySql in quanto oltre ad essere semplici da utilizzare sono gi incluse nel pacchetto di MySql Server 5.0. 4.2 I SOCKET Un socket un particolare oggetto sul quale leggere e scrivere i dati da trasmettere o ricevere attraverso una rete, per cui lo scambio di messaggi tra gli utenti che utilizzano lapplicazione avviene attraverso i socket. Nel dettaglio sono state utilizzate le classi wxSocketBase, wxSocketClient e wxSocketServer messe a disposizione dalle librerie wxWidgets. wxSocketBase la classe base per tutti gli oggetti socket, definisce tutte le funzionalit di I/O base. wxSocketClient una classe derivata da wxSocketBase rappresenta un Socket Client, per cui permette connessioni verso Server. wxSocketServer anchessa derivata da wxSocketBase rappresenta un Socket Server, il suo compito quello di attendere connessioni dai Client.

In ogni macchina gira il proprio applicativo con un vettore di wxSocketServer per poter accettare pi connessioni dai vari Client (i contatti dellutente) e tanti wxSocketClient quante connessioni sono state effettuate con i contatti che dispone lutente. Se si osserva figura 4 (capitolo 2, paragrafo 5), selezionando un contatto (ad esempio il contatto prova2) viene aperto un Client (wxSocketClient) che effettua una connessione verso un Server (wxSocketServer) della postazione del contatto. In questo modo i due utenti possono inviarsi messaggi attraverso i Socket aperti, lutente del Client (quello che ha effettuato la connessione) invier messaggi allutente del Server (quello che ha accettato la connessione) con unapposita funzione membro di
17

wxSocketClient viceversa lutente del Server scriver messaggi allutente del Client con una funzione membro di wxSocketServer. Il tutto schematizzato in figura 13:

Figura 13 I socket in comunicate

La classe wxSocketClient contiene la funzione membro:

wxSocketClient::Connect

che ha i seguenti prototipi:

bool Connect(wxSockAddress& address, bool wait = true) bool Connect(wxSockAddress& address, wxSockAddress& local, bool wait = true)

18

Questa funzione permette di effettuare una connessione verso un Server. wxSockAddress una classe che rappresenta un indirizzo, pi precisamente nel caso della funzione Connect() lindirizzo della macchina in cui si trova il Server associato ad una porta. Per quanto riguarda la porta lapplicativo utilizza di default la 3000, invece per quanto riguarda lindirizzo (lip) lo va prendere dal Database centralizzato (nella tabella profiles, campo CurrentIp se si tratta di una rete locale o CurrentPublicIp di una rete pubblica vedesi capitolo 3). La classe wxSocketServer al contrario utilizza la funzione membro:
wxSocketServer::AcceptWith

per accettare le connessioni. Ha il seguente prototipo:

bool AcceptWith(wxSocketBase& socket, bool wait = true)

Nel primo parametro della funzione viene passato lindirizzo di un oggetto wxSocketServer. Sia la classe wxSocketClient che la classe wxSocketServer possono usufruire delle seguenti due funzioni:
wxSocketBase::WriteMsg wxSocketBase::ReadMsg

in quanto sono due classi derivate da wxSocketBase. La prima funzione permette di scrivere messaggi verso il Client (se siamo il Server) o il Server (se siamo il Client), viceversa la seconda di leggere i messaggi in arrivo dal Client (se siamo il Server) o dal Server (se siamo il Client). 4.3 API C MYSQL Per connettersi al Database centralizzato si scelto di utilizzare le librerie che mette a disposizione MySql Server 5.0. Le funzioni utilizzate sono essenzialmente le seguenti:
MYSQL *mysql_init(MYSQL *mysql) inizializza un oggetto MYSQL MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned long client_flag) connette un oggetto MYSQL ad un database

19

int mysql_real_query(MYSQL *mysql, const char *stmt_str, unsigned long length) esegue una query al database a cui loggetto

MYSQL connesso
void mysql_close(MYSQL *mysql) sconnette un oggetto MYSQL dal

database 4.4 INTERFACCIAMENTO AL DATABASE Ad ogni accesso il programma effettuer tre connessioni verso il database: Nella prima andr a controllare se nella tabella profiles presente una tupla con i campi username e passwrd uguali a quelli che lutente ha inserito nella finestra di Login. Se sono presenti i due campi allora si passer alla seconda connessione in cui: Setter il campo ServerUp della tabella profiles ad 1, in questo modo gli altri utenti sapranno che lutente che sta effettuando laccesso in linea. Aggiorner il campo Status della tabella profiles con il valore appropriato scelto dellutente (in linea, occupato, al telefono, ecc - figura 10, paragrafo 3.1) Aggiorner i campi CurrentIp ed CurrentPublicIp della tabella profiles rispettivamente con una stringa contenente lip privato della macchina da cui lutente sta effettuando laccesso ed una stringa contenente lip pubblico della rete da cui lutente sta effettuando laccesso. Nella terza scaricher tutti i contatti dellutente dalla tabella contacts (tutte le tuple che hanno il campo username uguale a quello dellutente) e li visualizzer nella finestra contenente la lista dei contatti mostrata in figura 4 (capitolo 2, paragrafo 5). Una volta effettuato laccesso il programma effettuer una connessione al database ogni volta che lutente vuole aggiungere un contatto alla propria lista dei contatti, in questo caso verr aggiunta una tupla alla tabella contacts. Infine quando lutente effettua il Logout si far unultima connessione al database in cui il campo ServerUp della tabella profiles viene portato a 0. 4.5 LINTERFACCIA GRAFICA, LA PRESENTAZIONE DEL RISULTATO Le librerie wxWidgets mettono a disposizione un classe chiamata wxFrame ed una classe chiamata wxDialog, creando delle proprie classi derivate da queste due classi possibile creare qualsiasi tipo di finestra. Derivando la classe wxFrame si sono create: La finestra di login (classe LoginFrame), figura 1
20

La finestra contenete la lista dei contatti (classe ListFrame), figura 4 La finestra di conversazione (classe Conversation), figura 3 La finestra del registro (classe Register), figura 6

Derivando la classe wxDialog si sono invece create: La finestra che permette linserimento di un nuovo contatto (classe NewContact), figura 4 La finestra che permette linserimento di un nuovo profilo (classe NewProfile), figura 5 La finestra delle impostazioni (classe Options) come mostrato qui di seguito in figura 14, che permette la variazione di alcune variabili importanti come: lip del server centralizzato (di default 85.46.25.26), la porta su cui ascolta il server centralizzato (di default la 1990), la porta standard utilizzata da Comunicate per linvio dei messaggi (di default la 3000) ed il numero massimo di connessioni consentite (di default 25)

Figura 14 La finestra delle opzioni

In figura 15 mostrata una schematizzazione di quello detto sinora.

21

Figura 15 Le classi delle entit pi utilizzate in Comunicate 22

4.6 LE CLASSI C++ Il progetto c++ (creato con Code Blocks) contiene in totale 11 file (figura 16). Negli header files presente la definizione di tutte le classi (e di tutte le strutture dati utilizzate) mentre nei source files presente la loro implementazione. Nel resource file controlsStyle.rc vengono incluse alcune librerie per migliorare laspetto grafico dei controlli utilizzati nellapplicazione (pulsanti, campi di testo, ecc). Nel file listFrame.h sono presenti: La classe ListFrame La classe Conversation La classe NewContact La classe Options La classe SmilesTransientPopup che serve per la finestra (popup) degli smiles utilizzata nella classe Conversation (figura 17). Nel file loginFrame.h sono presenti: La classe LoginFrame La classe NewProfile Nel file register.h presente la classe Register.

Figura 16 : Il progetto C++

Figura 17: la finestra degli smiles

Infine nel file main.h presente la classe Comunicate (derivata dalla classe wxApp delle wxWidgets), che la prima classe che viene eseguita allavviamento del programma. Questa classe contiene unistanza della classe LoginFrame, unistanza della classe ListFrame ed unistanza della classe Register (figura 18).

Figura 18 : La classe Comunicate 23

5 - PROJECT MANAGEMENT
5.1 IL PROGETTO INIZIALE Il progetto iniziale prevedeva lo sviluppo di unapplicazione multipiattaforma (che possa funzionare allo stesso modo su sistemi operativi differenti) di messaggistica istantanea (instant messaging). Lidea era quella di poter far comunicare qualunque utente con chi volesse, indipendentemente dal sistema operativo utilizzato o dal nodo della rete in cui si situati. I problemi riscontrati sono stati i seguenti: Seppur tutte le librerie e gli strumenti utilizzati siano multipiattaforma, molte parti di codice producevano risultati differenti se compilate su sistemi operativi diversi Una scarsa analisi dei requisiti iniziale ha rallentato i lavori, molte parti di codice sono state riscritte molte volte Il tempo a disposizione limitato 5.2 OBBIETTIVI DI PROGETTO Gli obbiettivi posti in partenza sono stati in larga parte raggiunti, anche se a causa del tempo a disposizione limitato si dovuto rinunciare alla realizzazione di un applicazione multipiattaforma (il programma funziona solo sotto i sistemi operativi si Microsoft Windows) ed alla galleria delle foto (in teoria ogni utente avrebbe potuto in qualsiasi momento visualizzare le foto dei propri contatti). 5.3 ATTIVITA Le attivit svolte per la realizzazione del progetto sono state essenzialmente: Scrittura del codice sorgente Disegno di elementi grafici (immagini, icone, ecc) utilizzando software open source Documentazione sulle librerie C++ utilizzate (normalmente si tratta di testi tecnici in lingua inglese accessibili dal sito del produttore) Frequenti test dellapplicazione 5.4 LE RISORSE Per quanto riguarda il tempo a disposizione il progetto ha avuto inizio a Settembre del 2007 e si concluso definitivamente in Maggio 2008. I costi di progetto sono nulli in quanto tutti gli strumenti utilizzati sono open source, cio liberi: tutti possono usufruirne e modificarne il codice sorgente.
24

6 CONCLUSIONE
Questo progetto mi ha dato modo di capire quanto siano importanti le fasi di analisi e di documentazione di un qualsiasi progetto software, infatti una buona analisi iniziale consente di evitare di incorrere in problemi nelle successive fasi di implementazione e test. Con una buona analisi iniziale si pu raggiungere una comprensione chiara di ci che si vuole realizzare, si possono perci pianificare le metodologie e le tecnologie che si dovranno utilizzare per raggiungere gli obbiettivi posti in partenza.

25