Riassunto esame Ingegneria del software, Prof. De Lucia Andrea, libro consigliato Object Oriented Software Engineering, Bernd Bruegge

8. SYSTEM DESIGN (DECOMPOSIZIONE DEL SISTEMA)

8.1 Overview

Il System Design (progettazione del sistema) è la trasformazione del modello di analisi nel System Design Model (modello di progettazione del sistema). Perché il Design è così difficile? A differenza dell'Analisi, che si focalizza sul dominio applicativo, il Design si focalizza sul dominio delle soluzioni. Le conoscenze di design, quindi, sono in continua evoluzione e le motivazioni per cui si prendono decisioni di design stanno cambiando molto rapidamente. In generale, comunque, gli sviluppatori devono raggiungere dei compromessi fra i vari obiettivi di design che sono spesso in conflitto gli uni con gli altri e devono anticipare molte decisioni relative alla progettazione, pur non avendo una chiara idea del dominio della soluzione. Lo scopo del System Design è quello di costruire un "ponte" tra il sistema desiderato e quello esistente, in maniera maneggevole, usando la tecnica Divide

usando accoppiamenti ecoesioni) che possono essere realizzati da team individuali. 3. Gestire la concorrenza, identificando thread. 4. Scegliere le strategie di mapping hardware/software. 5. Scegliere le strategie relative alla gestione dei dati persistenti (oggetti persistenti, file, database, strutture dati). 6. Gestire le risorse globali: politiche di controllo degli accessi e politiche di sicurezza. 7. Scegliere il controllo software: monolitico, event-driven, thread, processi concorrenti. 8. Gestire le boundary condition (inizializzazione, terminazione, fallimenti). Il modello di analisi descrive il sistema dal punto di vista degli attori e serve come base fra il cliente e gli sviluppatori. Non contiene informazioni sulla struttura interna del sistema, sulla sua configurazione hardware e, in generale, su come il sistema dovrebbe essere realizzato. Ingegneria del Software (Metodi e Tecniche) Capitolo 8 - System Design (Decomposizione del Sistema) L'analisi dei requisiti fornisce informazioni dettagliate sulle funzionalità e i requisiti del sistema, mentre il design del sistema si concentra sulla decomposizione del sistema in componenti più piccoli e sulla definizione delle interazioni tra di essi.

Output il modello dei requisiti. Ecco come usare questo modello per il System Design:

1. Requisiti non funzionali => (1) Definizione degli obiettivi di design.
2. Modello funzionale => (2) Decomposizione del sistema (selezione di sottosistemi basandosi sui requisiti funzionali, su coesione e su accoppiamento).
3. Modello a oggetti => (4) Mapping hardware/software e (5) Gestione dei dati permanenti.
4. Modello dinamico => (3) Gestione della concorrenza, (6) Gestione globale delle risorse, (7) Controllo software.
5. Decomposizione in sottosistemi => (8) Gestione delle boundary condition.

I prodotti del system design, quindi, sono:

• Obiettivi di design, descrivono la qualità del sistema.
• Architettura software: descrive la decomposizione del sistema in termini delle responsabilità dei sottosistemi, in modo che ogni sottosistema possa essere assegnato ad un team e realizzato indipendentemente; le dipendenze fra sottosistemi; l'hardware associato ai vari.

sottosistemi; le politiche relative al flusso di controllo, al controllo degli accessi e alla memorizzazione dei dati.

Boundary use case, descrivono la configurazione del sistema, le scelte relative allo startup, allo shutdown ed alla gestione delle eccezioni.

Identificare gli Obiettivi di Design

Questo è il primo passo del system design, ed è effettuato per identificare le qualità su cui deve essere focalizzato il sistema. Molti design goals possono essere ricavati dai requisiti non funzionali o dal dominio applicativo, altri sono forniti dal cliente. È comunque importante formalizzarli esplicitamente, perché ogni decisione importante di design deve essere presa seguendo lo stesso insieme di criteri. È possibile selezionare questi obiettivi di design da una lunga lista di qualità desiderabili:

I criteri sono organizzati in cinque gruppi:

• Criteri di Performance: includono i requisiti imposti sul sistema in termini di spazio e velocità, come il tempo di risposta, il throughput e la memoria.
• Criteri di Affidabilità: riguardano i requisiti che il sistema deve avere per minimizzare i crash e le loro conseguenze, come la robustezza, l'affidabilità, la disponibilità, la tolleranza ai fault e la sicurezza.
• Criteri di Costo: includono i costi per lo sviluppo, l'implementazione e l'amministrazione del sistema, come il costo dello sviluppo iniziale, il costo dell'installazione e della formazione degli utenti, il costo di conversione dei dati dal sistema precedente (quando è richiesta la compatibilità con il sistema precedente) e il costo di manutenzione e amministrazione.
• Criteri di Mantenimento: determinano quanto sia difficile apportare modifiche al sistema dopo il suo rilascio, come l'estendibilità, la modificabilità, l'adattabilità e la portabilità.

leggibilità, tracciabilità dei requisiti.

Criteri di End User

Includono qualità che sono desiderabili dal punto di vista dell'utente, ma che non sono state coperte dai criteri di performance e affidabilità: utilità, usabilità.

Relazioni tra gli obiettivi di progettazione:

In realtà, quando si definiscono questi obiettivi, spesso solo un piccolo sottoinsieme di essi può essere tenuto in considerazione. Ad esempio, non è realistico sviluppare software che sia contemporaneamente sicuro e costi poco. Gli sviluppatori, perciò, devono dare delle priorità agli obiettivi di design, tenendo conto anche di aspetti manageriali, quali il rispetto dello schedule e del budget. In genere, quindi, si utilizzano dei trade-off (compromessi) tra i principali obiettivi di design, ad esempio:

• Funzionalità vs. Usabilità
• Costo vs. Robustezza
• Efficienza vs. Portabilità
• Sviluppo rapido vs. Funzionalità
• Costo vs.

RiusabilitàCompatibilità all'indietro vs. LeggibilitàIngegneria del Software (Metodi e Tecniche) Capitolo 8 - System Design (Decomposizione del Sistema)Dal punto di vista pratico, la definizione di questi obiettivi di design è da ricercare principalmente tra i requisiti non funzionali, che possono fornire indizi per l'uso dei Design Patterns (modelli di progetto): rileggere il problem statement e usare indizi testuali (come con la tecnica di Abbot durante l'Analisi) per identificare i design pattern. Riportiamo di seguito alcuni esempi, ma solo nei capitoli successivi sarà più chiaro il concetto di Design Pattern:"produttore indipendente", "dispositivo indipendente", "deve supportare una famiglia di prodotti" Abstract Factory Pattern; "deve interfacciarsi con un oggetto esistente" Adapter Pattern; "deve potersi interfacciare con vari sistemi, alcuni dei quali saranno

"sviluppati in futuro", "un primo prototipo deve essere dimostrato" - Bridge Pattern;

"struttura complessa", "deve avere profondità e ampiezza variabili" - Composite Pattern;

"deve interfacciarsi a un insieme di oggetti esistenti" - Facade Pattern;

"la sua locazione deve essere trasparente" - Proxy Pattern;

"deve essere estendibile", "deve essere scalabile" - Observer Pattern;

"deve fornire una politica indipendente dal meccanismo" - Strategy Pattern;

8.3 Decomposizione del Sistema

Un Sottosistema (Package in UML) è una collezione di classi, associazioni, operazioni, eventi e vincoli che sono correlati. Origini dei sottosistemi sono gli oggetti e le classi UML.

Il Servizio (di un Sottosistema) è un gruppo di operazioni fornite dal sottosistema. Trova origine dai casi d'uso del sottosistema ed è specificato dall' L'

Interfaccia del Sottosistema. specifica il flusso di informazioni e interazioni da/per i Subsystem Boundary (confini dei sottosistemi), ma non interni al sottosistema. Dovrebbe essere ben definita, piccola ed è spesso chiamata API: Application (ma questo termine dovrebbe essere usato durante l'implementazione, non durante il System Design). In particolare, definiamo:

• Servizio: un insieme di operazioni correlate che condividono un obiettivo comune. Servizi di notifica dei sottosistemi sono: LookupChannel(), SubscribeToChannel(), SendNotice(), UnsubscribeFromChannel(). I Servizi sono definiti in fase di System Design.
• Interfaccia di un Sottosistema: insieme di operazioni correlate, con signature completamente specializzate. Queste interfacce sono definite durante l'Object Design e sono anche dette API.

Per ridurre la complessità della soluzione, si decompone il sistema in parti più piccole, in Sottosistemi. Il problemaÈ come scegliere questi sottosistemi. I criteri per sceglierli si basano sull'osservazione che molte interazioni dovrebbero essere interne ai sottosistemi, piuttosto che attraverso i confini di sistema (Alta coesione). A tal proposito, il problema primario è del tipo "Che tipo di servizio è fornito dai sottosistemi (interfacce dei sottosistemi)?" e quello secondario è del tipo "Che tipo di modello è adatto per descrivere i layers (strati) e le partizioni?"

Ingegneria del Software (Metodi e Tecniche) Capitolo 8 - System Design (Decomposizione del Sistema)

Esempio di Decomposizione di un sistema:

Un Oggetto di Interfaccia del Sottosistema fornisce un servizio: si tratta di un insieme di metodi pubblici forniti dal sottosistema e l'interfaccia del sottosistema descrive tutti i metodi dell'oggetto.