Ingegneria del software appunti PDF

Preview

Summary

Appunti su teoria, diagrammi, agile, pattern, modalità di svolgimento dei diagrammi, gwt...

Description

SwEng 2016/2017 Per inquadrare il contesto: primo capitolo del libro OOD/A: Object-Oriented Analisys Design. UML non è OOD/A o un metodo, ma solo un linguaggio di notazione per diagrammi. Nel libro è spiegato come applicare UML allo scopo di effettuare OOD/A. Il nocciolo è risolvere problemi pragmatici affrontati dalla progettazione di un'applicazione OO. • Quali sono gli oggetti? • Quali sono le classi? • Cosa deve conoscere ciascun oggetto? (proprie variabili di istanza) • Cosa deve saper fare un oggetto? (metodi) • Come devono collaborare gli oggetti? (ovvero quali messaggi si scambiano) Queste sono le domande critiche nella progettazione di un sistema software, a cui il libro risponde insegnando una metafora della progettazione OO classica, che è la progettazione guidata alla responsabilità, che affronta il problema da questo punto di vista: come devono essere assegnate le responsabilità (di conoscere, di fare, di collaborare) alle classi di oggetti? In tal senso esistono soluzioni sperimentate e valide a problemi di programmazione ricorrenti: pattern. L'analisi dei requisiti costituisce un presupposto fondamentale per la costruzione dell'intero progetto software e la sua implementazione. Date le numerose attività possibili, svolte tra i requisiti e l'implementazione, è quindi necessario definire un opportuno processo di sviluppo, ad esempio di tipo iterativo ed evolutivo come Unified Process UP, Agile Scrum, Agile Extreme Programming (XP), ecc.. Una capacità critica nello sviluppo OO è quella di assegnare in modo abile responsabilità agli oggetti software. Importanti requisiti del progetto software: robustezza, manutenibilità, riusabilità. A corredo di queste basilari caratteristiche, è importante prestare attenzione all'assegnazione delle responsabilità (responsability-driven design). GRASP (General Responsibility Assignment Software Patterns) è una collezione di pattern, usata nella progettazione object-oriented, che fornisce delle linee guida per l'assegnazione di responsabilità alle classi e agli oggetti. GRASP comprende i seguenti 9 pattern: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations. In generale. Analisi: enfatizza un'investigazione del problema e dei requisiti, anziché di una soluzione. Progettazione: enfatizza una soluzione concettuale che soddisfi i requisiti, anziché la relativa implementazione. L'analisi e la progettazione possono essere riassunte nell'espressione: fare la cosa giusta (analisi), fare la cosa bene (progettazione). A conclusione abbiamo poi la terza fase di implementazione.

1

In particolare nel contesto OOP Possiamo identificare tre fasi consequenziali. 1. Analisi orientata agli oggetti: identificazione e descrizione degli oggetti, concetti, delle classi concettuali (dominio del problema). 2. Progettazione orientata agli oggetti: definizione degli oggetti software e dei modi con cui essi collaborano per soddisfare i requisiti (dominio della soluzione). 3. Implementazione (traduzione) del modello in uno specifico linguaggio di programmazione OO. Le tre fasi sono osservabili dalla seguente prospettiva. 1. OOA – Object Oriented Analisys → modello di dominio. 2. OOD – Object Oriented Design → diagramma delle classi. 3. OOP – Object Oiented Programming → scrittura del codice. In sintesi, passi e diagrammi fondamentali. 0. Fase 0. Analisi dei requisiti e definizione dei casi d'uso. Non sono un elaborato orientato agli oggetti, ma semplicemente delle storie scritte. Sono tuttavia uno strumento diffuso nell'analisi dei requisiti. 1. L'analisi orientata agli oggetti è interessata alla creazione di una descrizione del dominio da un punto di vista ad oggetti. Grazie al modello di dominio vengono quindi identificati i concetti, gli attributi, le associazioni considerate significative. E' altresì denominato modello concettuale a oggetti. 2. Il diagramma di sequenza, un particolare diagramma di interazione di UML, illustra in forma esplicita il flusso di messaggi tra oggetti software, dunque l'invocazione di metodi e quindi le collaborazioni e le responsabilità. Il diagramma di sequenza offre una vista dinamica delle collaborazioni tra oggetti. 3. Il diagramma delle classi di progetto offre una vista statica delle definizioni delle classi software (con i loro attributi e metodi). Lo scambio di messaggi definiti nel diagramma di sequenza diverranno metodi all'interno di questo modello. Diversamente dal modello di dominio che illustra classi concettuali del “mondo reale” (ovvero definite a partire dall'analisi della realtà di riferimento), il diagramma delle classi mostra classi software (ovviamente nel paradigma OOP). E' presumibile che il modello di dominio e il diagramma delle classi siano molto simili. Nel passaggio dalla rappresentazione della realtà (modelli mentali) all'implementazione software, i linguaggi OO sono quindi in grado di favorire un salto rappresentazionale basso. Paragrafo 1.6, pagina 12 Cos'è UML? Unified Modeling Language é un linguaggio visuale per la specifica, la costruzione e la documentazione degli elaborati di un sistema software. UML è uno standard de facto per la notazione di diagrammi, per disegnare o rappresentare figure relative al software, e in particolare al software OO. UML può essere usato indistintamente in entrambe le seguenti macro categorie di progettazione: • Punto di vista concettuale → fase di analisi → dominio del problema → UML: modello di dominio → permette di visualizzare concetti del mondo reale, ovvero concetti di / del dominio, classi concettuali. • Punto di vista software → fase di progettazione → dominio della soluzione → UML: diagramma delle classi (è un modello di progetto) → permette di visualizzare elementi software, ovvero classi di progetto. 2

Ricapitolando. Punto di vista concettuale: modello di dominio. Punto di vista software / implementativo: modello di progetto (di cui il diagramma delle classi ne è istanza). Modellazione visuale (dal libro) I diagrammi UML ci aiutano a vedere o esaminare meglio il quadro generale e le relazioni tra elementi dell'analisi o software, e allo stesso tempo ci permettono di ignorare o nascondere dettagli poco interessanti.

3

Capitolo 2: metodo iterativo e evolutivo – UP Nella slide Software-process-model.pdf sono presenti (i) il modello a cascata (waterfall model) ed il (ii) modello a spirale (spiral model). Il processo a cascata (pagina 22) E' basato su uno svolgimento sequenziale delle diverse attività dello sviluppo software. Fasi: 1. analisi e definizione dettagliata dei requisiti, contemporaneo alla definizione di un piano temporale dettagliato e “affidabile” delle attività da svolgere; 2. modellazione (analisi e progettazione), con cui è creato un modello completo del software; 3. implementazione, ovvero la stesura del codice, la programmazione effettiva dell'applicazione; 4. verifica e rilascio. Le fasi vengono svolte perfettamente in sequenza, sebbene il modello offra una parziale possibilità di feedback e cicli iterativi tra le varie attività (modalità, questa, in genere scarsamente impiegata). E' stato dimostrato che il modello rappresenti una pratica mediocre, se non fallimentare, poiché caratterizzato da un'elevata percentuale di fallimenti, minor produttività, maggiori percentuali di difetti. Una delle più importanti motivazioni che stanno alla base della scarsa efficacia del modello, riguarda la credenza in genere smentita: “le specifiche sono prevedibili e stabili, e possano essere definite correttamente sin dall'inizio, a fronte di un basso tasso di cambiamenti”. Il mancato coinvolgimento dell'utente nei progetti software è quasi al primo posto tra i motivi di fallimento dei progetti [Larman03]. Lo sviluppo iterativo ed evolutivo è una metodologia di sviluppo software in cui sono applicabili OOA/D, UML, RDD e GRASP, design patterns, ecc. E' tuttavia importante ricordare che questi concetti / modelli sono indipendenti da qualsiasi processo specifico. The Unified Software Development Process or Unified Process (UP) is a popular iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). Other examples are OpenUP and Agile Unified Process. Pagina 24 || Sviluppo iterativo (ovvero adattivo), incrementale, evolutivo. Sviluppo iterativo. In questo approccio al ciclo di vita, lo sviluppo è organizzato in una serie di mini- progetti brevi, di lunghezza fissa (per esempio di tre settimane) chiamati iterazioni; il risultato di ciascuna iterazione è un sistema eseguibile, testato e integrato, anche se parziale. Ciascuna iterazione comprende le proprie attività di analisi dei requisiti, progettazione, implementazione – test – integrazione – ulteriore progettazione, integrazione finale – test. Come vedremo in seguito, tali attività afferiscono ad ambiti tematici omogenei definiti discipline. Il ciclo di vita iterativo si basa sull'ampliamento e il raffinamento successivi di un sistema attraverso molteplici iterazioni. Il sistema cresce in modo incrementale nel tempo, iterazione dopo iterazione e pertanto questo approccio è noto anche come sviluppo iterativo e incrementale. Poiché il feedback e l'adattamento fanno evolvere le specifiche e il progetto, è noto anche come sviluppo iterativo ed evolutivo. Ad esempio in un team di 4 persone un'iterazione può durare 15 giorni di cui al più una giornata sarà dedicata ad una breve riflessione preliminare riguardo alla progettazione, usando UML come abbozzo alla lavagna. Ciascuna iterazione produce un sistema software funzionante ma incompleto.

4

La slide 21 in Software-process-model.pdf descrive le fasi di UP. Sinteticamente riporto quelle indicate a pagina 34 del libro. Un progetto UP (un intero ciclo di sviluppo) organizza il lavoro e le iterazioni in 4 fasi principali: 1. ideazione: non rappresenta la fase dei requisiti, piuttosto è una fase di fattibilità in cui viene eseguita un'indagine sufficiente a sostenere la decisione di proseguire o meno con il progetto SW. Essa comprende l'analisi del 10% dei casi d'uso, la creazione di uno studio economico, la preparazione dell'ambiente di sviluppo, ecc.. 2. elaborazione: fase in cui viene implementata in modo iterativo l'architettura del sistema (soprattutto il nucleo e le componenti di maggior rischio); 3. costruzione: implementazione iterativa degli elementi rimanenti (di minor rischio); 4. transizione: beta test e rilascio. Un ciclo di sviluppo termina con il rilascio di un sistema in produzione ed è composto da numerose iterazioni. Le iterazioni si “spalmano” sulle 2 macro-fasi centrali in cui sono prodotti elaborati funzionanti ma incompleti → (anche sull'ultima?). Sembra tuttavia che la fase di ideazione non sia suddivisa in iterazioni. Keywords di UP (slide 20) • Iterative and incremental. • Use case-driven. • Risk focused (paragrafo 2.6, pagina 32). La pianificazione guidata dal rischio (e guidata dal cliente) comporta che gli obiettivi delle iterazioni iniziali vengono scelti (i) per identificare e attenuare i rischi maggiori, (ii) per costruire e rendere visibili le caratteristiche a cui il cliente tiene di più. • Architecture-centric (paragrafo 2.6, pagina 32). Lo sviluppo iterativo centrato sull'architettura è direttamente correlato al precedente; le prime iterazioni della fase di elaborazione debbono infatti concentrarsi sulla costruzione, il test e la stabilizzazione del nucleo dell'architettura. E' un rischio molto alto non avere una base architetturale solida. Aggiungerei (pagina 27 del libro). • Timeboxed. E' un'iterazione di lunghezza fissata. Molti metodi iterativi raccomandano una lunghezza delle iterazioni da due a sei settimane. Iterazioni più lunghe aumentano il rischio del progetto. • Passi piccoli, feedback rapido e adattamento sono le idee centrali dello sviluppo iterativo. Alcune caratteristiche a corredo (estratte da pagina 39) Nello sviluppo iterativo o UP. • Non è richiesta la definizione della maggior parte dei requisiti prima dell'inizio della progettazione (questo tipologia di approccio sarebbe invece incoraggiato nel modello waterfall). • Non è necessario impiegare giorni o settimane nella modellazione UML. • Ciascuna fase deve essere correttamente suddivisa in iterazioni, di lunghezza non superiore alle 3/4 settimane. • In ciascuna iterazione devono essere presenti attività di modellazione e progettazione, implementazione e realizzazione, testing, pianificazione della successiva iterazione (da pagine 29 e 30 del libro). • Non è richiesta da subito la completa pianificazione di ciascuna iterazione.

5

Ricapitolando, schematicamente 1. Un processo di sviluppo software iterativo e incrementale basato su UP è suddiviso in 4 macro-fasi che consequenzialmente si attivano una in successione all'altra: ideazione, elaborazione, costruzione, transizione. 2. Ciascuna macro-fase (fatta eccezione, se ho ben capito, dell'ideazione) è suddivisa in iterazioni. 3. L'intero processo, e quindi ciascuna macro-fase, è attraversato da varie discipline, le cui attività, in misura maggiore o minore, vengono svolte all'interno delle iterazioni. 4. Definizione di disciplina (pagina 35 del libro): insieme di attività lavorative e dei relativi elaborati, afferenti ad una determinata area tematica. 5. Ciascuna disciplina ha maggior vigore e necessita quindi di maggiori energie e tempo, a seconda della macro-fase che il processo di sviluppo sta attraversando. 6. Ciò comporta che all'interno di ciascuna iterazione, tali discipline occupino fette maggiori o minori della totalità del lavoro svolto. 7. Nel libro (ed anche a lezione) abbiamo affrontato le seguenti discipline (e quindi le seguenti aree tematiche): modellazione del business, requisiti, progettazione (altre, ma non affrontate: implementazione, test, rilascio, .. ). 8. Ciascuna, rispettivamente, si concretizza nella produzione dei seguenti elaborati: modello di dominio, modello dei casi d'uso, modello di progetto (nb. così come indicato a pagina 311, il modello di progetto comprende il diagramma di sequenza e il diagramma delle classi). 9. Per definizione il processo è iterativo e incrementale, ciò significa che gli elaborati afferenti a ciascuna disciplina vengono man mano raffinati durante l'evolversi delle iterazioni e quindi delle macro-fasi. 10. E' molto probabile che la disciplina “requisiti” (produce l'elaborato “modello dei casi d'uso”) richiederà maggiore energia nelle prime iterazioni (svolte nella fase di elaborazione), piuttosto che nelle ultime iterazioni svolte in prossimità del termine della fase di costruzione, poiché i requisiti ed il progetto si stabilizzano attraverso un processo di feedback e adattamento. 11. Aspetto interessante: riportato anche nella sintesi del capitolo 7. I casi d'uso rivestono un ruolo importante nella pianificazione iterativa. Il lavoro di un'iterazione è definito, in parte, scegliendo alcuni scenari di casi d'uso o interi casi d'uso.

6

Capitolo 7: casi d'uso Elaborato della disciplina “requisiti” in UP; maggior energia è richiesta nella fase di elaborazione. Il modello dei casi d'uso in UML è di tipo “Behavior Diagram” (l'altra grande famiglia è “Structure Diagram”). Dalla slide Use-case1.pdf Use case diagrams are behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system. In generale i casi d'uso sono storie scritte, testuali, di qualche attore che usa il sistema per raggiungere degli obiettivi. L'essenza è individuare e registrare i requisiti funzionali scrivendo storie di come un sistema possa essere utilizzato per consentire agli utenti di raggiungere i loro obiettivi. Entità coinvolte. 1. Attore: qualcosa o qualcuno dotato di comportamento, come una persona (caratterizzata da un ruolo), un sistema informatico o un'organizzazione. Attenzione: gli attori interni al sistema non debbono essere esplicitamente rappresentati (ad esempio l'attore “pharmacist” durante la rappresentazione del subject “business – pharmacy”). Pharmacist working in the pharmacy is not an actor, he or she is part of the business and is usually called business worker. 2. Scenario (istanza di caso d'uso): è una sequenza di interazioni tra il sistema e alcuni attori. Descrive una particolare storia dell'uso del sistema, ovvero un percorso attraverso il caso d'uso. Esempi di scenario: effettuare un acquisto che va a buon fine, pagando in contanti; fallito acquisto a causa del rifiuto della cc. 3. Caso d'uso: è una collezione di scenari correlati, sia di successo che di fallimento, che descrivono un attore che usa un sistema per raggiungere un obiettivo specifico. → In altri termini (probabilmente più esplicativo): un caso d'uso descrive un'insieme di sequenze di azioni (raggruppa dunque una serie di possibili scenari) svolta dal sistema che produce un risultato osservabile nei confronti di un attore del sistema. Importante: deve durare il tempo di un caffè! Occhio a non equivocarsi tra un caso d'uso e un processo. Forse è utile intenderlo come specifica funzionalità del sistema attivata da un attore. Dalle slide; conciso ma efficace. 1. Actor: In UML an actor is behaviored classifier which specifies a role played by an external entity that interacts with the subject (e.g., by exchanging signals and data), a human user of the designed system, some other system or hardware using services of the subject. Standard UML notation for actor is “stick man” icon with the name of the actor above or below of the icon. Custom icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon(s) for non-human actors. 2. Subject: The subject is the system under analysis or design to which a set of use cases apply. The subject could be a business, software system, physical system, or a smaller subsystem having some behavior. In UML terms, subject is a use case classifier playing the "subject" role. Use case classifier is classifier extended with the capability to own use cases. Subject is presented by a rectangle with subject name in upper corner with applicable use cases inside the rectangle and actors - outside of the system boundaries.

7

3. Use case: in UML a use case is behaviored classifier which specifies behavior of a subject by describing a set of sequences of actions (scenari) performed by the system to yield an observable result of some value to one or more actors or other stakeholders of the system. In other words, each use case describes a unit of complete and useful functionality that the subject provides to its users. Use case is usually shown as an ellipse containing the name of the use case. Operazione / azione (non un processo) eseguita da un attore (che riveste un ruolo) che interagisce con il sistema, ovvero che attiva una sua particolare funzionalità e produce un risultato osservabile. Ricorda che un use case è anche una collezione di scenari. I casi d'uso sono documenti di testo, non diagrammi, e la modellazione dei casi d'uso è innanzitutto un atto di scrittura di testi, non di disegno di diagrammi. In classe abbiamo contraddetto questa asserzione. Dal nostro punto di vista sono principalmente diagrammi UML. Dobbiamo concentraci sui System Use Case. Come ulteriore elaborato della disciplina “requisiti” di UP, in classe abbiamo visto e utilizzato le Regole di Business (business rules); altri sono: le specifiche supplementari, il glossario, la visione. In classe, principalmente, ci siamo concentrati sull'elaborazione dei casi d'uso mediante UML. E' importante porre maggiore attenzione alla scrittura di storie testuali piuttosto che ad aspetti considerabili secondari come: diagrammi dei casi d'uso, relazioni tra casi d'uso, il package dei casi d'uso, ..). Un ulteriore punto di forza dei casi d'uso è dato dalla possibilità di aumentare e diminuire il loro livello di dettaglio e di formalità. ← aspetto interessante, utile consiglio. Meglio ridurre che alimentare la complessità. Paragrafo 7.5 I casi d'uso sono requisiti, soprattutto requisiti ...