Contenuti - Amministrazione di progetto - Documentazione di progetto - Ambiente e strumenti - Norme di progetto e di codifica - Seminario: leggibilità del codice Amministrare un progetto - Amministrare non è dirigere - L’amministrazione non compie scelte tecnologiche - L’amministrazione non compie scelte gestionali - Attività - Redazione e manutenzione delle regole - Non la loro approvazione, che spetta al responsabile di progetto - Accertamento di applicazione delle regole - Responsabilità su reperimento e disponibilità delle risorse - Per tutte le risorse di un progetto tranne che per il personale - Ambiente, infrastruttura, strumenti, prodotti, documenti Documentazione di progetto - Tutto ciò che documenta le attività - Prodotto e processo - Documenti di sviluppo - Documentazione fornita dal cliente - Diagrammi di progettazione - Codice - Piani di qualifica e risultati delle prove - Documentazione di accompagnamento del prodotto - Documenti di gestione del progetto - Documenti contrattuali - Piani e consuntivi delle attività - Piani di qualità Disponibilità e diffusione - I documenti devono essere disponibili - Chiaramente identificati - Corretti nei contenuti - Verificati e approvati - Aggiornati, datati e dotati di versione - La loro diffusione deve essere controllata - Tutti e soli gli interessati devono averne presa visione - Ogni documento ha una specifica lista di distribuzione - L’amministratore gestisce le liste di distribuzione e ne assicura il rispetto Ambiente di lavoro - Necessario al processo di produzione - Qualità dell’ambiente (produttività) - Influisce sulla qualità del processo - Influisce sulla qualità del prodotto - Caratteristiche di qualità di ambiente - Completo: deve offrire tutto il necessario - Ordinato: deve essere facile trovarvi ciò che si cerca - Aggiornato: il materiale obsoleto non deve intralciare Infrastruttura - Risorse hardware - Server, mainframe - Rete locale, connettività - Stazioni di lavoro, dispositivi di utilità - Archivi logici (dischi) - Archivi fisici (schedari, scaffali, armadi) - Risorse software - Ambienti di sviluppo, di prova e di lavoro - Strumenti di sviluppo - Prodotti del processo di sviluppo (documentazione inclusa) - Server interni per la diffusione di informazione (intranet) Strumenti di sviluppo - 1 - Non occorrono solo compilatori - Editori di testo: vi, (x)emacs, [IDE] - Verificatori: lint, prof, gprof, . - (g)prof: program execution profiler; lint (verificatore per C/C++); - Debugger: gdb, ddd, … - Versionamento: rcs, sccs, cvs, … - sccs: source code control system (1972) - rcs: revision control system (UNIX / FSF) - cvs: concurrent versions system , basato sul modello client-server (http://www.gnu.org/software/cvs) - Configurazione: make, imake, autoconf, … - imake: makefile generator (http://www.x.org) - autoconf: generatore di macro per la configurazione automatica (http://www.gnu.org/software/autoconf) Strumenti di sviluppo - 2 - Ambienti di supporto integrati - CASE: Computer Aided Software Engineering - Di concezione originata nei primi anni ‘80 - RAD: Rapid Application Development - Uso di “wizard”, meno controllo da parte del programmatore e più vincoli di ambiente e di piattaforma (p.es. Delphi, Visual BASIC) - CAST: Computer Aided Software Test - Strumenti ed ambienti per la generazione e l’applicazione (semi-)automatica di harness, script, stub, driver per prove - IDE: Integrated Development Environment - Visual Studio, Visual ONE, GPS, … Strumenti di processo - Gestione di progetto - Pianificazione e stima dei costi - Allocazione e gestione delle risorse - Analisi e progettazione - Ambienti di supporto alle metodologie - Tracciamento dei requisiti - Supporto alla realizzazione - Misurazione ed analisi del codice - Generazione ed esecuzione automatica delle prove Norme di progetto - Linee guida per le attività di sviluppo - Storicamente, hanno preceduto le procedure aziendali - Oggi sono lo strumento operativo che le completa - Contenuti - Norme di codifica - Organizzazione ed uso delle risorse di sviluppo - Convenzioni sull’uso degli strumenti di sviluppo - Organizzazione della comunicazione e della cooperazione Organizzazione di una norma - Regole - Convenzioni di cui si riconosce necessità e convenienza - Ne è richiesto ed accertato il rispetto - Raccomandazioni - Prassi desiderabile di buona programmazione - Inviti e suggerimenti, ma senza verifica di rispetto - Il contesto definisce la portata della norma - Non tutto può essere regolato - Troppe regole sono di difficile attuazione e verifica Obiettivi delle norme di codifica - Leggibilità come forma di prevenzione - Verificabilità - Manutenibilità - Portabilità - Come è “scritto” il codice? - È comprensibile a distanza di tempo? - È comprensibile a chi non lo ha prodotto? Convenzioni sui nomi - Nel codice e nel progetto - Tipi, costanti, variabili, funzioni, ... - Esempio: le norme Javadoc (vedi: http://java.sun.com/j2se/javadoc/ ) - Strutturazione in moduli, directory, file, ... - Aspetti pratici - Conflitti, all’interno o all’esterno del codice - Abbreviazioni, per comodità o per necessità - Limiti del linguaggio - P.es.: identificazione forte o debole dei tipi (Java vs. C) - Limiti degli strumenti - P.es.: lunghezza massima degli identificatori (p.es.: Windows 95-98) Indentazione - Obiettivi - Programmazione strutturata - Evidenziare visivamente la struttura di un programma - Aspetti da non sottovalutare - Lunghezza delle linee - Indentazione - Posizione degli fine linea nei blocchi - Posizione degli fine linea nelle espressioni - Come evitare guerre ideologiche sugli stili? Intestazione - Obiettivi - Identificazione e collocamento di una unità (modulo, file) - Storia e responsabilità delle modifiche - Contenuti - Dati dell’unità: tipo, contenuto, posizione - Responsabilità: autore, reparto, organizzazione - Copyright o copyleft: licenze, visibilità - Avvertenze: limiti di uso e di garanzia - Registro modifiche: storia, spiegazione, versioni Uso del linguaggio - Una strategia per costringere i programmatori a lavorare come si conviene - Prescrizioni tipiche - Compilazione senza errori fatali o potenziali (warning) - Uso chiaro e coerente dei costrutti del linguaggio - Uso di un sottoinsieme appropriato del linguaggio - I costrutti di maggiore robustezza, verificabilità, leggibilità - Non necessariamente quelli di maggiore potenza espressa e velocità Leggibilità del codice - Il codice illeggibile è disarmante ed irritante - Modificarlo costa tempo ed è rischioso - La leggibilità facilita le attività di ispezione - Il codice è una risorsa - Il primo (l’ultimo) posto dove guardare Norme di codifica char _3141592654[3141 ],__3141[3141];_314159[31415],_3141[31415];main(){register char* _3_141,*_3_1415, *_3__1415; register int _314,_31415,__31415,*_31, _3_14159,__3_1415;*_3141592654=__31415=2,_3141592654[0][_3141592654 -1]=1[__3141]=5;__3_1415=1;do{_3_14159=_314=0,__31415++;for( _31415 =0;_31415<(3,14-4)*__31415;_31415++)_31415[_3141]=_314159[_31415]= - 1;_3141[*_314159=_3_14159]=_314;_3_141=_3141592654+__3_1415;_3_1415= __3_1415 +__3141;for (_31415 = 3141- __3_1415 ; _31415;_31415-- ,_3_141 ++, _3_1415++){_314 +=_314<<2 ; _314<<=1;_314+= *_3_1415;_31 =_314159+_314; if(!(*_31+1) )* _31 =_314 / __31415,_314 [_3141]=_314 % __31415 ;* ( _3__1415=_3_141 )+= *_3_1415 = *_31;while(* _3__1415 >= 31415/3141 ) * _3__1415+= - 10,(*--_3__1415 )++;_314=_314 [_3141]; if ( ! _3_14159 && * _3_1415)_3_14159 =1,__3_1415 = 3141-_31415;}if( _314+(__31415 >>1)>=__31415 ) while ( ++ * _3_141==3141/314 )*_3_141--=0 ;}while(_3_14159 ) ; { char * __3_14= "3.1415"; write((3,1), (--*__3_14,__3_14 ),(_3_14159 ++,++_3_14159))+ 3.1415926; } for ( _31415 = 1; _31415<3141- 1;_31415++)write( 31415% 314-( 3,14),_3141592654[ _31415 ] + "0123456789","314" [ 3]+1)-_314; puts((*_3141592654=0 ,_3141592654)) ;_314= *"3.141592";} Notazione ungherese - lpfnWndProc (un campo di struttura) - l : long (32-bit integer) - p : pointer [to a] - fn : function [handling messages directed to] - Wnd: [a] window - Proc : procedure - Un vettore di puntatori a descrittori di finestre, indicizzato sul numero di finestre - Charles Simonyi @ Microsoft Intestazione dei file - esempio Riferimenti - V. Ambriola, G.A. Cignoni, “Laboratorio di progettazione”, Jackson Libri, 1996 - “Programming in C++ - Rules and Recommendations”, Ellemtel TSL (Svezia), 1992 - C. Simonyi, M. Heller, “The Hungarian Revolution”, Byte, agosto 1991