Redazione e Presentazione di Progetti Informatici - CNRstaff.icar.cnr.it/ruffolo/files/06 - RPPI -...
23
•1 Massimo Ruffolo – RPPI 2006/2007 1 Redazione e Presentazione di Progetti Informatici Corso di Laurea in Informatica Facoltà di Scienze Matematiche, Fisiche e Naturali Massimo Ruffolo E-mail: [email protected] Web: http://www.icar.cnr.it/ruffolo Istituto di CAlcolo e Reti ad alte prestazioni del Consiglio Nazionale delle Ricerche (ICAR-CNR) Exeura s.r.l. – Spin-off dell’Università della Calabria Massimo Ruffolo – RPPI 2006/2007 2 Ingegneria del Software Cenni sulle metodologie: Zachman Framework Feature Driven Development Extreme Programming COSM La metodologia Exeura
Transcript of Redazione e Presentazione di Progetti Informatici - CNRstaff.icar.cnr.it/ruffolo/files/06 - RPPI -...
•1
Massimo Ruffolo – RPPI 2006/2007 1
Redazione e Presentazione di Progetti Informatici
Corso di Laurea in InformaticaFacoltà di Scienze Matematiche, Fisiche e Naturali
Massimo Ruffolo
E-mail: [email protected]: http://www.icar.cnr.it/ruffolo
Istituto di CAlcolo e Reti ad alte prestazioni del Consiglio Nazionale delle Ricerche (ICAR-CNR)
Exeura s.r.l. – Spin-off dell’Università della Calabria
Massimo Ruffolo – RPPI 2006/2007 2
Ingegneria del Software
Cenni sulle metodologie:
Zachman Framework
Feature Driven Development
Extreme Programming
COSM
La metodologia Exeura
•2
Massimo Ruffolo – RPPI 2006/2007 3
Ingegneria del Software: Zachman Framework
Massimo Ruffolo – RPPI 2006/2007 4
Ingegneria del Software
Il valore di una metodologia sta nell’Approccio strutturato alla realizzazione di un servizio/prodotto, ciò consente di:
identificare al meglio gli obiettivi intermedi e finaliottimizzare l’impiego di risorse (risparmiare tempo e danaro)controllore i risultati intermedi e finali (non perdere di vista li obiettivi)…
•3
Massimo Ruffolo – RPPI 2006/2007 5
Based on work b y Jo hn A. Z achman
VA Enterprise Arch itectu re
DATAWhat
F UN C TI ONHow
NETW ORKWhere
PEOPLEWho
TI M EWhen
MOTI VA TI ONWhy
DATAWhat
F UN C TI ONHow
NETW ORKWhere
PEOPLEWho
TI M EWhen
MOTI VA TI ONWhy
S COPE(CON TEX TU AL)
Planner
EN TER PR I S EMOD EL(CON C EPTU AL)
Owner
S YS TEM M OD EL(LOGI C AL )
Designer
TEC H N OLO GYMOD EL(PHYSI CAL)
Builder
DETAI LEDR EPRES EN TATION S(OU T-OF -C ON TE XT)
Sub-Contractor
FUNC TIONI N GEN TER PR I S E
S C OPE(C ON TEX TU AL)
Planner
ENTER PRI S EMOD EL
(C ONC EPTU AL)
Owner
S YS TEM M OD EL(L OGIC AL)
Designer
TECHNOLO GYMOD EL
(PHYSI CAL)
Builder
DETAI LEDR EPRES EN TATION S(OU T-OF -C ONTE XT)
Sub-Contracto r
FUNC TI ONI N GEN TERPR I S E
T hings Im portant to the Bus iness
Entity = C lass of Bus iness T hing
Proc ess es Perform ed
F unc tion = C lass of Bus iness Process
Sem antic M odel
Ent = Bus ines s Entity R el = Bus ines s R elationship
Business Process M odel
Proc = Bus iness Process I/O = Bus iness R es ourc es
Business Logis tic sSy s tem
N ode = Bus iness Loc ation Link = Bus iness Link age
Work F low M odel
People = Organization Unit Work = Work Product
M as ter Schedule
T ime = Bus iness Event Cyc le = Bus iness Cyc le
Bus iness Plan
End = Bus iness Objec tiv e M eans = Bus iness Strategy
Im portantOrganizations
People = Major Organizations
Business locations
N ode = M ajor Bus iness Locations
Ev ents Signific antto the Bus iness
T ime = M ajorBus iness Event
Bus iness Goalsand Strategy
Ends/Means =M ajor Bus iness Goals
Logic al DataM odel
Ent = Data Entity R el = Data Relationship
Application Arc hitec ture
Proc = Application Func tion I/O = U ser View s
Dis tributed Sy s temArc hitec ture
N ode = IS F unc tion Link = Line C haracteris tics
Hum an InterfaceArc hitec ture
People = Role Work = Deliv erable
Process ingStruc ture
T ime = Sys tem Ev ent Cyc le = Proc ess ing Cycle
Bus iness R uleM odel
End = Struc tural Assertion M eans = Ac tion Assertion
Phy s ical DataM odel
Ent = Segm ent/T able R el = Pointer/Key
Sy s temDesign
Proc = C om puter F unc tion I/O = Data Elem ents /Sets
T ec hnologyArc hitec ture
N ode = Hardw are/Softw are Link = Line Spec ific ations
Pres entationArc hitec ture
People = User Work = Screen F orm at
C ontrolStruc ture
T ime = Ex ec ute Cyc le = C om ponent Cy c le
R uleDes ign
End = C ondition M eans = Ac tion
DataDefinition
Ent = F ield R el = Address
Program
Proc = Language S tatem ent I/O = C ontrol Block
N etw orkArc hitec ture
N ode = Addres ses Link = Protoc ols
SecurityArc hitec ture
People = IdentityWork = Job
T im ing Definition
T ime = InterruptCyc le = M achine Cy cle
R uleDes ign
End = Sub-C ondition M eans = Step
Data
Ent = R el =
F unc tion
Proc =I/O =
N etw ork
N ode = Link =
Organization
People = Work =
Schedule
T ime = Cyc le =
Strategy
End = M eans =
Based on work b y Jo hn A. Z achman
VA Enterprise Arch itectu re
DATAWhat
F UN C TI ONHow
NETW ORKWhere
PEOPLEWho
TI M EWhen
MOTI VA TI ONWhy
DATAWhat
F UN C TI ONHow
NETW ORKWhere
PEOPLEWho
TI M EWhen
MOTI VA TI ONWhy
S COPE(CON TEX TU AL)
Planner
EN TER PR I S EMOD EL(CON C EPTU AL)
Owner
S YS TEM M OD EL(LOGI C AL )
Designer
TEC H N OLO GYMOD EL(PHYSI CAL)
Builder
DETAI LEDR EPRES EN TATION S(OU T-OF -C ON TE XT)
Sub-Contractor
FUNC TIONI N GEN TER PR I S E
S C OPE(C ON TEX TU AL)
Planner
ENTER PRI S EMOD EL
(C ONC EPTU AL)
Owner
S YS TEM M OD EL(L OGIC AL)
Designer
TECHNOLO GYMOD EL
(PHYSI CAL)
Builder
DETAI LEDR EPRES EN TATION S(OU T-OF -C ONTE XT)
Sub-Contracto r
FUNC TI ONI N GEN TERPR I S E
T hings Im portant to the Bus iness
Entity = C lass of Bus iness T hing
Proc ess es Perform ed
F unc tion = C lass of Bus iness Process
Sem antic M odel
Ent = Bus ines s Entity R el = Bus ines s R elationship
Business Process M odel
Proc = Bus iness Process I/O = Bus iness R es ourc es
Business Logis tic sSy s tem
N ode = Bus iness Loc ation Link = Bus iness Link age
Work F low M odel
People = Organization Unit Work = Work Product
M as ter Schedule
T ime = Bus iness Event Cyc le = Bus iness Cyc le
Bus iness Plan
End = Bus iness Objec tiv e M eans = Bus iness Strategy
Im portantOrganizations
People = Major Organizations
Business locations
N ode = M ajor Bus iness Locations
Ev ents Signific antto the Bus iness
T ime = M ajorBus iness Event
Bus iness Goalsand Strategy
Ends/Means =M ajor Bus iness Goals
Logic al DataM odel
Ent = Data Entity R el = Data Relationship
Application Arc hitec ture
Proc = Application Func tion I/O = U ser View s
Dis tributed Sy s temArc hitec ture
N ode = IS F unc tion Link = Line C haracteris tics
Hum an InterfaceArc hitec ture
People = Role Work = Deliv erable
Process ingStruc ture
T ime = Sys tem Ev ent Cyc le = Proc ess ing Cycle
Bus iness R uleM odel
End = Struc tural Assertion M eans = Ac tion Assertion
Phy s ical DataM odel
Ent = Segm ent/T able R el = Pointer/Key
Sy s temDesign
Proc = C om puter F unc tion I/O = Data Elem ents /Sets
T ec hnologyArc hitec ture
N ode = Hardw are/Softw are Link = Line Spec ific ations
Pres entationArc hitec ture
People = User Work = Screen F orm at
C ontrolStruc ture
T ime = Ex ec ute Cyc le = C om ponent Cy c le
R uleDes ign
End = C ondition M eans = Ac tion
DataDefinition
Ent = F ield R el = Address
Program
Proc = Language S tatem ent I/O = C ontrol Block
N etw orkArc hitec ture
N ode = Addres ses Link = Protoc ols
SecurityArc hitec ture
People = IdentityWork = Job
T im ing Definition
T ime = InterruptCyc le = M achine Cy cle
R uleDes ign
End = Sub-C ondition M eans = Step
Data
Ent = R el =
F unc tion
Proc =I/O =
N etw ork
N ode = Link =
Organization
People = Work =
Schedule
T ime = Cyc le =
Strategy
End = M eans =
Zachman Framework
Massimo Ruffolo – RPPI 2006/2007 6
Zachman Framework
Row 1 – ScopeExternal Requirements and DriversBusiness Function Modeling
Row 2 – Enterprise ModelBusiness Process Models
Row 3 – System ModelLogical ModelsRequirements Definition
Row 4 – Technology ModelPhysical ModelsSolution Definition and Development
Row 5 – As BuiltAs BuiltDeployment
Row 6 – Functioning EnterpriseFunctioning EnterpriseEvaluation
123456
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
•4
Massimo Ruffolo – RPPI 2006/2007 7
Framework Rules
Rule 1:Columns have no order
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
Rule 2:Each column has a simple, basic model
Rule 3:Basic model of each column is unique
Rule 4:Each row represents a distinct view
Rule 5:Each cell is unique
Rule 6:Combining the cells in one row forms a complete description from that view
Basic Model = Entities and Relationships
EntityRelationshipEntity
Massimo Ruffolo – RPPI 2006/2007 8
Zachman Framework – Row 1Scope/Planner’s View
• External Requirements and Drivers• Business Function Modeling
• Motivation/WhyBusiness goals, objectives and performancemeasures related to each function
Function/HowHigh-level business functions
Data/WhatHigh-level data classes related to
each function
People/WhoStakeholders related to each function
Network/WhereVA locations related to each function
Time/WhenCycles and events related to eachfunction
1 Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
•5
Massimo Ruffolo – RPPI 2006/2007 9
Zachman Framework – Row 2Enterprise Model/Designer’s View
• Business Process Models• Business Function Allocation• Elimination of Function Overlap and
Ambiguity
• Motivation/WhyPolicies, procedures and standards for eachprocess
Function/HowBusiness processes
Data/WhatBusiness data
People/WhoVA roles and responsibilities in eachprocess
Network/WhereVA locations related to each process
Time/WhenEvents for each process and sequencingof integration and process improvements
2
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
Massimo Ruffolo – RPPI 2006/2007 10
Zachman Framework – Row 3System Model/Designer’s View
• Logical Models• Project Management• Requirements Definition
• Motivation/WhyVA policies, standards and proceduresassociated with a business rule model
Function/HowLogical representation of informationsystems and their relationships
Data/WhatLogical data models of data and datarelationships underlying VA information
People/WhoLogical representation of access privilegesconstrained by roles and responsibilities
Network/WhereLogical representation of the distributedsystem architecture for VA locations
Time/WhenLogical events and their triggered responses constrained by business events and their responses
3
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
•6
Massimo Ruffolo – RPPI 2006/2007 11
Zachman Framework – Row 4Technology Model/Builder’s View
• Physical Models• Technology Management• Solution Definition and Development
• Motivation/WhyVA business rules constrained by informationsystems standards
Function/HowSpecifications of applications that operateon particular technology platforms
Data/WhatDatabase management system (DBMS) typerequirements constrained by logical data models
People/WhoSpecification of access privileges tospecific platforms and technologies
Network/WhereSpecification of network devices and theirrelationships within physical boundaries
Time/WhenSpecification of triggers to respond to systemevents on specific platforms and technologies
4
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
Massimo Ruffolo – RPPI 2006/2007 12
Zachman Framework – Row 5As Built/Integrator’s View
• As Built• Configuration Management• Deployment
• Motivation/WhyVA business rules constrained by specific technology standards
Function/HowPrograms coded to operate on specific technology platforms
Data/WhatData definitions constrained by physical data models
People/WhoAccess privileges coded to control access to specific platforms and technologies
Network/WhereNetwork devices configured to conform to node specifications
Time/WhenTiming definitions coded to sequence activities on specific platforms and technologies
5
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
•7
Massimo Ruffolo – RPPI 2006/2007 13
Zachman Framework – Row 6Functioning Enterprise/User’s View
• Functioning Enterprise• Operations Management• Evaluation
• Motivation/WhyOperating characteristics of specific technologies constrained by standards
Function/HowFunctioning computer instructions
Data/WhatData values stored in actual databases
People/WhoVA personnel and key stakeholders working within their roles and responsibilities
Network/WhereSending and receiving messages
Time/WhenTiming definitions operating to sequence activities
6
Contextual
Conceptual
Logical
Physical
Integrated
Functioning
Contextual
Conceptual
Logical
Physical
Integrated
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
Massimo Ruffolo – RPPI 2006/2007 14
VA Zachman Framework Portal
•8
Massimo Ruffolo – RPPI 2006/2007 15
Ingegneria del Software: Feature Driven Development (FDD)
Massimo Ruffolo – RPPI 2006/2007 16
E’ una via di mezzo fra metodologia leggera e approccio tradizionale
Propone una robusta fase di analisi e progettazione, integrata con un modello di sviluppo agile
Si focalizza sullo sviluppo di funzionalità "tangibili" per il cliente; di fatto la Feature è una funzionalità che deve avere un valore per il committente e che "guida" il ciclo di sviluppo
FDD
•9
Massimo Ruffolo – RPPI 2006/2007 17
FDD
Massimo Ruffolo – RPPI 2006/2007 18
FDD
Ideata da Jeff De Luca e Peter Coad. E’ una via di mezzo fra metodologia leggera e approccio tradizionale. Propone una robusta fase di analisi e progettazione, integrata con un modello di sviluppo agile E’ una forma di sviluppo “guidata” dalle funzionalità da realizzare E’ strettamente basata sull’utilizzo di UML e in particolare sulla versione “colorata” di UML ideata dagli autoriSono disponibili diversi strumenti di supporto free, alcuni anche open sourceEsiste una community molto attiva che si occupa di questa metodologia e dei sui strumenti
•10
Massimo Ruffolo – RPPI 2006/2007 19
FDD
Pur essendo molto meno conosciuta di ExtremeProgramming è forse il miglior approccio metodologico allo sviluppo del software
Dal confronto diretto emerge sorprendentemente che Feature Driven Development è addirittura più flessibile di Extreme Programming anche se la prima ha una fase di progettazione “classica” che la seconda elimina proprio per guadagnarne in flessibilità
Massimo Ruffolo – RPPI 2006/2007 20
FDD
I dettagli delle fasi di sviluppo sono pochi e semplici. Un progetto è diviso in cinque fasi, dette processi: sviluppare un modello generale
criteri d’ingresso: avere scelto gli esperti del problema, i capi-programmatori ed il capo-architettoattività: il project manager deve formare il team di modellazione; il team di modellazione deve offrire una panoramica del dominio delproblema, preparare i documenti funzionali e, diviso in piccoli gruppi, sviluppare il modello; il capo-architetto deve rifinire il modello generale ad oggetti insieme al team di modellazione e scrivere le note al modello insieme ai capi-programmatori; verifica: il team di modellazione deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenti criteri d’uscita: avere definito il modello ad oggetti avendo quindi a disposizione i diagrammi delle classi, i metodi e gli attributi delle classi, la sequenza delle classi (se esiste), le note al modello
•11
Massimo Ruffolo – RPPI 2006/2007 21
FDD
costruire una lista di funzionalitàcriteri d’ingresso: avere scelto gli esperti del problema, il capo-programmatore ed i capi-architettiattività: il project manager deve formare il team della lista delle funzionalità che deve comprendere i capi-programmatori del team di modellazione; il team della lista delle funzionalità deve definire la lista delle funzionalità in termini di azione-risultato-oggettoverifica: il team della lista delle funzionalità deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenticriteri d’uscita: avere definito la lista delle funzionalità avendo quindi a disposizione la lista delle aree oggetto, la lista delle attivitàdi business per ogni area oggetto, la lista delle funzionalità che soddisfino tutti i punti di ogni lista delle attività;
Massimo Ruffolo – RPPI 2006/2007 22
FDD
Pianificare per funzionalitàcriteri d’ingresso: è stato portato a termine il processo “costruire una lista di funzionalità”attività: il project manager deve formare il team di progettazione che comprende capi-programmatori e manager dello sviluppo; il team di progettazione deve definire la sequenza di sviluppo, assegnare le attività di business ai capi-programmatori ed assegnare le classi agli sviluppatoriverifica: il team di progettazione deve effettuare un’autoverifica sul lavoro svoltocriteri d’uscita: avere definito un piano di sviluppo comprendente le attività di business con le date di completamento ed i capi-programmatori responsabili assegnati, la date di completamento delle aree oggetto (derivate da quelle delle attività di business), la lista delle classi con relativi sviluppatori
•12
Massimo Ruffolo – RPPI 2006/2007 23
FDD
Progettare per funzionalitàcriteri d’ingresso: è stato portato a termine il processo “pianificare per funzionalità”attività: ogni capo-programmatore forma il team delle funzionalità; ogni esperto del problema definisce la strada per affrontare il problema e risolverlo; il team delle funzionalità studia i documenti dei requisiti delle proprie funzionalità; il team di progettazione sviluppa i diagrammi di sequenza; il capo-programmatore raffina il modello ad oggetti per definire se scrivere o modificare classi, metodi, attributi; il team delle funzionalitàscrive le classi e gli header dei metodi verifica: il team delle funzionalità ispeziona il progetto in tutti i suoi aspetti funzionali e temporali criteri d’uscita: avere definito un pacchetto di progettazione completo che comprenda un documento esplicativo dell’intero progetto con le specifiche referenziate (se esistono riferimenti), i diagrammi di sequenza, le alternative di progetto (se esistono), il modello ad oggetti completo di classi, metodi e attributi, gli header di classi e metodi, una todo list con un calendario delle scadenze per ogni attività ed ogni membro del team
Massimo Ruffolo – RPPI 2006/2007 24
FDD
Sviluppare per funzionalitàcriteri d’ingresso: è stato portato a termine il processo “pianificare per funzionalità” ed è stato ispezionato con successo il progetto in tutti i suoi aspetti funzionali e temporali attività: il team delle funzionalità implementa classi e metodi, ispeziona il codice ed effettua i test unitari; il capo-programmatore decide (dopo i test unitari) insieme al team delle funzionalità quali classi siano “promuovibili” come utili alla costruzione del progetto in riguardo alle funzionalità richieste verifica: il capo-programmatore sovrintende affinché siano completate effettivamente in tutti i punti dal team delle funzionalitàl’ispezione dei codici ed la soddisfazione dei test unitari criteri d’uscita: avere ottenuto classi e metodi che siano stati ispezionati e testati con successo, infine promossi all’integrazione nel progetto (ovviamente a copertura di tutte le funzionalità previste
•13
Massimo Ruffolo – RPPI 2006/2007 25
FDDFeature Driven Development non richiede esplicitamente la stesura di documentazione, ma obbliga all’utilizzo dei diagrammi UML. Questo per avere una base decisionale che sia stabile durante tutto il processo di sviluppo, solo in seconda battuta sarà utile per scrivere una documentazione formale, se richiesta Nel corso del progetto ci sono molti documenti che devono essere disponibili per i diversi attori, quindi la miglior soluzione è organizzare un sito web interno che contenga tutte le informazioni sul progetto: la lista di sviluppatori ed esperti del problema, il modello UML con i commenti, i forum di discussione, le convenzioni di scrittura del codice, la lista degli strumenti e delle librerie usate, i report dei test unitari, lo status del progetto, la timelinecomprensiva della pianificazione futura, ecc...
Massimo Ruffolo – RPPI 2006/2007 26
FDD
Durante lo sviluppo, organizzato in iterazioni brevi, si forma una struttura gerarchica con figure a metà strada fra il project manager e gli sviluppatori: i capi-programmatori. Questi sono a capo di ogni singola iterazione, che quindi possono essere numerose e procedere parallelamente, scegliendo anche il team (composto da 3-5 persone) che se ne occuperàL’esperienza dei capi-programmatori e la frammentazione del lavoro in iterazioni, sono i meccanismi di controllo e regolazione di Feature Driven Development. All’inizio di ogni iterazione si organizzano delle riunioni di progettazione che servono a far confrontare i membri del team e ad ottenere la documentazione del codice
•14
Massimo Ruffolo – RPPI 2006/2007 27
FDDLa stesura del codice prevede l’utilizzo rigoroso di uno standard comune di scrittura e il ricorso ad i test unitari, che possono essere organizzati a discrezione dei capi-programmatori Date le numerose riunioni effettuate prima di cominciare a scrivere il codice, questa attività diventa qualcosa di meccanico, infatti Feature Driven Development scoraggia l’uso di pratiche tipo il Refactoring mentre incoraggia la condivisione del codice prodotto (in maniera particolare della documentazione relativa) fra i diversi programmatori Per la revisione del codice si va oltre il Pair Programming visto che la condivisione all’interno del team dell’iterazione permette una verifica molto più ampia. In ogni caso è proprio per permettere la miglior revisione possibile del codice che i team di sviluppo devono essere poco numerosi e che le iterazioni devono essere brevi, fra 1 e 3 settimane
Massimo Ruffolo – RPPI 2006/2007 28
FDD
Il rilascio delle versioni è previsto per la fine di ogni iterazione, raramente di più iterazioni, ma ciò permette di coinvolgere molto di meno il cliente rispetto a quanto facciano le altre metodologie leggere. E permette anche di non consegnare alcune versioni intermedie quando le condizioni al contorno non lo rendano possibile, ad esempio in caso di software medici embeddedTenere una traccia dello status del progetto è un compito reso semplice da Feature Driven Development in quanto si ha a disposizione sin dall’inizio la lista delle funzionalità da implementare ed ogni iterazione ha dei pesi ben definiti per ogni passo
•15
Massimo Ruffolo – RPPI 2006/2007 29
FDD
FDD usa Colored UML. Per UML colorato si intende un UML standard con le classi divise in quattro categorie individuate da quattro colori diversi:
giallo (indica un Ruolo, ricoperto da persona o da organizzazione, come ad esempio i differenti tipi di utente di un servizio) blu (indica una Descrizione modello-catalogo, ad esempio il tipo di oggetto in un database ma non il singolo oggetto) verde (indica un Luogo o un Oggetto, ad esempio il singolo oggetto del database di prima) rosa (indica i Tempi, un momento o un intervallo associati ad un processo, ad esempio ad un azione su di un oggetto del database) Le classi ausiliari e le interfacce restano standard e non sono colorate
Massimo Ruffolo – RPPI 2006/2007 30
FDD
•16
Massimo Ruffolo – RPPI 2006/2007 31
Ingegneria del Software: Extreme Programming (XP)
Massimo Ruffolo – RPPI 2006/2007 32
XP
È un insieme di regole di sviluppo software sviluppate originariamente dal lavoro congiunto di Kent Beck, fondatore del Three Rivers Institute, e Ward Cunningham
La chiave della metodologia è lavorare fianco a fianco con il cliente per anticipare i frequenti cambiamenti alle specifiche e di sviluppare in contemporanea con la scrittura del codice i test unitari atti a verificare la correttezza dei risultati restituiti dal codice stesso
•17
Massimo Ruffolo – RPPI 2006/2007 33
XPSi possono individuare dodici regole base di ExtremeProgramming:
Progettare con il cliente Test funzionali e unitari Refactoring (riscrivere il codice senza alterarne le funzionalitàesterne) Progettare al minimoDescrivere il sistema con una metafora, anche per la descrizioneformale Proprietà del codice collettiva (contribuisce alla stesura chiunque sia coinvolto nel progetto) Scegliere ed utilizzare un preciso standard di scrittura del codice Integrare continuamente i cambiamenti al codice Il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali) Open Workspace40 ore di lavoro settimanali Pair Programming (due programmatori lavorano insieme su un solo computer)
Massimo Ruffolo – RPPI 2006/2007 34
XP
James Donovan Wells mantiene una delle risorse più ricche sull’argomento. Indica in particolare quattro linee guida:
Comunicazione (tutti possono parlare con tutti, persino l’ultimo dei programmatori con il cliente)Semplicità (gli analisti mantengano la descrizione formale il più semplice e chiara possibile)Feedback (sin dal primo giorno si testa il codice)Coraggio (si dà in uso il sistema il prima possibile e si implementano i cambiamenti richiesti man mano).
•18
Massimo Ruffolo – RPPI 2006/2007 35
XP
Quattro sono le fasi del progetto, ognuna delle quali con le sue regole interne:
Pianificazione (User Stories, Release Planning, Small Releases, Project Velocity, Load Factor, Iterative Development, Iteration Planning, Move People Around, Daily Stand Up Meeting, Fix XP) Progettazione (Simplicity, System Metaphor, CRC Cards, Spike Solution, Never Add Early, Refactoring) Sviluppo (Customer Always Available, Standards, Unit Test First, Pair Programming, Sequential Integration, Integrate Often, Collective Code Ownership, Optimize Last, No Overtime)Testing (Unit Test Framework, Bug’s found, Functional Test o Acceptance Tests).
Massimo Ruffolo – RPPI 2006/2007 36
XP
•19
Massimo Ruffolo – RPPI 2006/2007 37
Ingegneria del Software: COSM
Massimo Ruffolo – RPPI 2006/2007 38
COSM
E’ soggetta a copyrightIntegra il framework di Zachman e la FDD con considerazioni provenienti dal mondo del PM e del BPMPrevede la stesura di una corposa documentazioneE’ centrata sulla realizzazione di architetture SOA (component based architecture)
•20
Massimo Ruffolo – RPPI 2006/2007 39
Ingegneria del Software: La Metodologia Exeura
L’output UML è costituito da un package chiamato Modello Progettuale contenente:
• un’analisi fisica rappresentata mediante un package denominato Schema Architettura.
• un’analisi dinamica rappresentata mediante un package denominato Schema Funzioni e un package denominato Schema Attori.
• un’analisi statica rappresentata mediante un package denominato Schema Dati e un package denominato Schema Viste.
La modellazione UML
•21
Massimo Ruffolo – RPPI 2006/2007 41
Le funzioni vengono rappresentate mediante package innestati di UsecaseUsecase diagramdiagram nei quali vengono espressi i legami con attori e dati
Gli aspetti dinamici delle funzioni vengono modellati mediante una serie di ActivityActivity diagramdiagram nei quali si rappresenta la sequenza di esecuzione degli usecase
Lo schema funzioni/1
Lo schema funzioni/2
Massimo Ruffolo – RPPI 2006/2007 42
La struttura architetturale del sistema da implementare viene modellata mediante DeploymentDeployment diagramdiagram nei quali si modellano nodi, componenti e relative interazioni
Le figure che interagiscono con il sistema vengono definite in uno UsecaseUsecase diagramdiagram che modella anche le tassonomie dei ruoli
Lo schema architettura
Lo schema attori
•22
Massimo Ruffolo – RPPI 2006/2007 43
La struttura del database sul quale viene sviluppato il sistema èmodellata in un Class Class diagramdiagram che rappresenta gli attributi, le tabelle e le relative relazioni
Utilizzando lo stereotipo di viste, specifiche porzioni di dati vengono messe a disposizione delle funzioni che ne faranno uso
Lo schema dati
Lo schema viste
Massimo Ruffolo – RPPI 2006/2007 44
La costruzione del modello progettuale avviene in maniera incrementale.
Si può iniziare
• considerando le aree funzionali richieste per il sistema
• analizzando le tipologie di utenti che dovranno essere supportate con l’implementazione delle nuove funzionalità.
La modalità di applicazione
Anche la progettazione dell’area dei dati e viste è incrementale e parte da una descrizione a livello abbozzato, per poi passare a uno scheletro di schema globale in cui si dettagliano le viste che costituiscono il contatto con l’area funzionale
•23
Massimo Ruffolo – RPPI 2006/2007 45
La modellazione UML può essere supportata utilizzando la piattaforma ENTERPRISEARCHITECTfornita dallaSparxsystems
www.sparxsystems.com
L’ambientedi lavoro
