Il documento esplora gli approcci al design del software, enfatizzando l'importanza dell'architettura e della progettazione in relazione alla soluzione di problemi complessi. Vengono discussi concetti come astrazione, decomposizione, modularità e l'uso di metodologie di sviluppo incrementale e agile, evidenziando i fattori che influenzano la qualità del software. Infine, viene trattata la scelta tra sviluppare internamente (make) e l'acquisto di soluzioni (buy), con considerazioni sull'open source e sull'importanza della conoscenza esperienziale del programmatore.

1. Approcci al design
Come affrontare la progettazione di un
software
Andrea Colleoni - 2011

2. Summary
 Motivazione: i driver di progettazione OOP
 Dimensionamento del problema
 Architettura SW
 Object Oriented Design

3. Dove nel processo?

4. Problem solving
 Identificazione e definizione del problema
 Uso di astrazione, analogia, brainstorming, divide
et impera, riduzione, test di ipotesi
 La soluzione può essere ottenuta impiegando un
mix di atteggiamenti e la sua bontà e la rapidità
con la quale è ottenuta è influenzata
dall’esperienza

5. Analogia e riduzione
 Analogia: viene riconosciuta nel problema in
analisi un’analogia con un problema già affrontato
e risolto positivamente o negativamente;
un’analisi critica dell’analogia permette di fare
leva sull’esperienza
 Riduzione: un problema viene approssimato ad
un altro problema già risolto; la soluzione è già
disponibile

6. Astrazione e raffinamento
 Astrazione: un processo viene progressivamente
svuotato delle informazioni che non sono ritenute
cruciali e critiche con lo scopo di arrivarne
all’essenza eliminando il rumore
 Raffinamento: è la trasformazione di un problema
astratto nella sua rappresentazione formale
eseguibile (algoritmo e quindi, infine, codice)

7. Decomposizione e
partizionamento
 La decomposizione funzionale è il processo per
cui da un problema complesso di grandi
dimensioni si giunge ad un problema di
dimensioni più contenute la cui complessità è
minore; le funzioni possono essere rappresentate
come un albero gerarchico
 Il partizionamento strutturale divide l’albero della
decomposizione in senso orizzontale (insieme
delle funzioni principali) e in senso verticale
(flusso del controllo, modularizzazione)

8. Software construction
 È l’insieme delle attività relative alla realizzazione
della soluzione di un problema
 Comprende la progettazione architetturale e di
dettaglio, la pianificazione, la scrittura e il debug,
il test e l’integrazione. Non prescinde dalla
tecnologia, dal linguaggio, dallo stile scelto per la
realizzazione
 Influenza il risultato nel modo più diretto perché il
risultato di quest’attività è IL SOFTWARE stesso

9. OOP è ancora il
OOP paradigma di
Le attività sono riferimento: attuale e
correlate tra loro valido
 OO è un approccio
• Analogia e
riduzione
• Astrazione e
raffinamento concettuale alla
rappresentazione e
Riuso
Design
OO alla soluzione di un
problema
Software
Quality
Creazione
Moduli
 Il linguaggio e lo stile
• Software
Construction
• Decomposizione
e partizionamento
di programmazione
(imperativa,
dichiarativa) sono
strumenti con cui
realizzare la soluzione

10. Driver di progettazione OOP
 Modularità  Manutenibilità, Riusabilità,
Estensibilità
 Robustezza  Sicurezza, Fault-tolerance,
Compatibilità
 Usabilità

11. Uso delle metafore
 Una metafora non ci
può dire dove trovare
la soluzione, ci può
dire dove questa può
essere
ricercata[McConnell]
 La metafora edilizia ci
potrà aiutare a
chiarire alcuni concetti
quindi parleremo di
«costruzione del
software» e non di
semplice scrittura di
codice.

12. Dimensione del problema
 Non esiste un modo unico di affrontare un problema;
in primo luogo è necessario identificare la dimensione
del problema
 Un problema di piccole dimensioni, metaforicamente la
cuccia di Fido, può essere affrontato con poca o nulla
progettazione; in caso di errore può essere demolita e
ricostruita, i componenti utilizzati sono semplici, poco
costosi e di solito si può affrontare il progetto da soli in
un breve lasso di tempo
 Un problema di grandi dimensioni, metaforicamente la
costruzione di un edificio, non può essere affrontato
senza progettazione. Non è possibile incominciare a
costruire una palazzina e vedere come procede il
progetto. È necessario progettare, pianificare,
selezionare strumenti, materiali, persone.

13. Approccio incrementale
 L’accrescimento del SW consiste nel modificare
un SW esistente aumentandone le dimensioni
(numero di funzioni, complessità, ecc.) tramite
aggiunte esterne graduali o inclusione.
 Costruire lo scheletro; la versione più semplice
possibile che possa essere messa in esecuzione,
anche senza Input o Output realisitici
 Poco a poco aggiungere porzioni allo scheletro;
non modificare lo scheletro per far ricevere input,
piuttosto aggiungere una funzione che riceve input
 Aggiungere codice fino a produrre il sistema finale

14. Cassetta degli attrezzi
 Per costruire SW, oltre al materiale ad ogni
programmatore serve l’esperienza
 La cassetta degli attrezzi del programmatore è il
bagaglio delle conoscenze acquisite durante la
sua esperienza
 Più è ampia la gamma di problemi risolti, di
tecnologie utilizzate, di metodologie applicate,
migliore sarà l’approccio al problema; strumenti
più raffinati aiutano a perseguire gli obiettivi con
maggiore qualità e minor tempo

15. Piccoli problemi
 Effort complessivo < 30 ggu
 Nell’ordine di qualche K LOC
 Costruzione SW circa 65% dell’effort complessivo
 Si cerca nell’ordine di soddisfare il problema nei
seguenti modi:
1. Ricerca di soluzioni già funzionanti
2. Personalizzazione (configurazione) di soluzioni
esistenti
3. Accrescimento di soluzioni esistenti tramite l’aggiunta
di funzioni
 In generale, sono preferibili approcci del tipo:
 Buy over make
 Design bottom-up

16. Problemi di medie dimensioni
 30 ggu < effort complessivo < 200 ggu
 Nell’ordine di qualche decina di K LOC
 Costruzione SW circa 50% dell’effort complessivo
 Tramite la decomposizione funzionale si cerca di
stabilire se i piccoli problemi risultanti possono
ricadere nell’approccio tipico dei piccoli problemi
 Il problema nel suo complesso può essere gestito
con i seguenti approcci:
 Mix tecnologico di componenti acquistati e costruiti;
 Uso avanzato degli IDE, sviluppo incrementatale
iterativo
 Uso di metodologie più agili

17. Problemi di grandi dimensioni
 effort complessivo > 200 ggu
 Nell’ordine di qualche centinaio di K LOC
 Maggiore attenzione al design, che ha l’impatto
più oneroso in termini di incidenza degli errori
 Il problema nel suo complesso può essere gestito
con i seguenti approcci:
 Metodologie di design più rigorose ed affidabili
 Make over buy nelle parti alte della gerarchia della
decomposizione funzionale; Buy over make nella
parte bassa
 Design top down

18. Considerazioni sulle dimensioni
 Più è grande il progetto,
più è impegnativo il design
• Più è grande il
progetto minore è
l’incidenza degli errori
di costruzione,
maggiore quella degli
errori di design e di
requirements

19. Costo degli errori: misura due volte,
taglia una volta
 [McConnell]: è evidente come il costo degli errori
incida in misura maggiore sulle fasi finali se i
difetti sono introdotti nelle fasi iniziali

20. Make vs. Buy
 Make
 Può avere un costo elevato, ma non sviluppa
dipendenze da soggetti terzi
 Non beneficia di esperienza e maturità acquisite
 Accresce il toolset dei partecipanti sulla tecnologia di
riferimento selezionata per la realizzazione
 Buy
 Ha generalmente costi più contenuti in rapporto al valore
del prodotto
 Beneficia di esperienza e maturità che possono essere
rilevanti e difficilmente ottenibili con approccio make
 Non sempre tutto il contenuto del prodotto è rilevante
per il progetto
 Sviluppa dipendenze da soggetti terzi

21. Open source
• L’open source può essere assimilato a un
atteggiamento make, generalmente a costo zero, nel
caso di possesso della conoscenza necessaria a
padroneggiare il codice sorgente ed il processo per
generarne i binari
• L’open source può essere assimilato ad un
atteggiamento buy, generalmente a costo zero nel
caso non si possegga la conoscenza necessaria alla
gestione del progetto (sviluppa la dipendenza)
• L’open source può essere valutato con attenzione
rispetto a:
• Maturità
• Vitalità
• Ampiezza della base utilizzatori e sviluppatori
• Piani di sviluppo
• Il closed source non è valutabile; bisogna solo fidarsi

22. Quanto costa lo sviluppo?
Examples of support of implementation
Estimation approach Category
of estimation approach
Analogy-based estimation Formal estimation model ANGEL, Weighted Micro Function Points
WBS-based (bottom up) Project management software, company
Expert estimation
estimation specific activity templates
Parametric models Formal estimation model COCOMO, SLIM, SEER-SEM
Function Point Analysis[12], Use
Size-based estimation
Formal estimation model Case Analysis, Story points-based
models[11]
estimation in Agile software development
Group estimation Expert estimation Planning poker, Wideband Delphi
Combination-based Average of an analogy-based and a Work
Mechanical combination
estimation breakdown structure-based effort estimate
Combination-based Expert judgment based on estimates from
Judgmental combination
estimation a parametric model and group estimation

23. Linguaggi e piattaforme
 I linguaggi OO sono moltissimi e sono sempre più
presenti le caratteristiche funzionali; attualmente
più diffusi sono C# e Java, ma sono presenti
anche Scala, Haskell, F#, Ruby e JavaScript
 Le piattaforme sono in minor numero:
principalmente abbiamo CLR e JVM

24. IDE e ALM Tools
 IDE devono essere
 Produttivi
 Produrre SW di qualità più elevata possibile
 ALM Tools devono
 Formalizzare e automatizzare l’intera vita del SW
 Disponibilità di librerie
 Librerie con scopi diversi sono disponibili in
tecnologie diverse

25. Scelte Chiave per la Construction
 Scelta del linguaggio
Kind of Program Best Languages Worst Languages
Command-line processing Cobol, Fortran, SQL
Cross-platform Java, Perl, Python Assembler, C#, Visual Basic
development
Database manipulation SQL, Visual Basic Assembler, C
Direct memory Assembler, C, C++ C#, Java, Visual Basic
manipulation
Distributed system C#, Java
Dynamic memory use C, C++, Java, C#
Easy-to-maintain program C++, Java, C#, Visual Basic
Real-time program C, C++, Assembler C#, Java, Python, Perl, Visual
Basic
Secure program C#, Java C, C++
Web development C#, Java, JavaScript, PHP, Assembler, C
Visual Basic

26. Coding & Teamwork

27. QA & Tools

28. Object Oriented Design
 I risultati dell’attività di OOD sono:
 Modello concettuale: indipendente dalla tecnologia
 Casi d’uso: descrizione semi formale di sequenze di
eventi
 Modello dei dati
 Storyboard o modello UX
 CRC Cards
 UML

29. Altri approcci al design
 Domain Drive Design
 È una metodologia di progettazione che si adatta a progetti di
grandi dimensioni
 Consente di agganciare l’implementazione ad un modello
evolvibile dei concetti chiave del problema
 Scenario Driven Design: per la progettazione di framework
o componenti di base, il design deve partire da un insieme
di scenari di utilizzo concreti e dal relativo codice che
farebbe uso del framework
 Test Driven Design: usato in alcune metodologie agili,
adatte per progetti mid-size; anticipa quanto più possibile
l’identificazione e la codifica dei test (sia Unit Test che
Acceptance Test). Favorisce l’approccio incrementale.
 Model Driven Architecture: approccio poco utilizzato nella
pratica che mira ad ottenere un modello eseguibile. La
modellazione che si avvicina di più all’approccio MDA è
quella ottenuta con UML.

30. Caratteristiche chiave del buon
design
 Minimal complexity
 Ease of maintenance
 Minimal connectedness
 Extensibility
 Reusability
 High fan-in
 Low-to-medium fan-out
 Portability
 Leanness
 Stratification
 Standard techniques

31. Granularità del design

32. Pattern e anti-pattern
 In software engineering, an anti-
pattern (or antipattern) is a pattern that may be
commonly used but is ineffective and/or
counterproductive in practice.
 A pattern is a general reusable solution to a
commonly occurring problem

33. Architectural Patterns
 The software architecture of a system is the set
of structures needed to reason about the system,
which comprise software elements, relations among
them, and properties of both.
 The term also refers to documentation of a system's
software architecture. Documenting software
architecture facilitates communication
between stakeholders, documents early decisions
about high-level design, and allows reuse of design
components and patterns between projects
 The software architecture discipline is centered on the
idea of reducing complexity
through abstraction and separation of concerns
 An architectural pattern in software is a
standard design in the field of software architecture.

34. Architectural Patterns: esempi
 Client–server model (2-tier, n-tier, peer-to-peer, cloud computing all use
this model)
 Database-centric architecture (broad division can be made for programs
which have database at its center and applications which don't have to
rely on databases, E.g. desktop application programs, utility programs
etc.)
 Distributed computing
 Event-driven architecture
 Front end and back end
 Implicit invocation (Hollywood Principle and IoC)
 Peer-to-peer
 Pipes and filters
 Plugin
 Representational State Transfer
 Service-oriented architecture
 Software componentry
 Three-tier model (An architecture with Presentation, Business Logic and
Database tiers)

35. Design patterns
 A design pattern is a general reusable solution to a
commonly occurring problem in software design.
 Design patterns can speed up the development
process by providing tested, proven development
paradigms.
 Effective software design requires considering issues
that may not become visible until later in the
implementation.
 Reusing design patterns helps to prevent subtle
issues that can cause major problems, and it also
improves code readability for coders and architects
who are familiar with the patterns.
 Reuse is achieved through the coding of components;
a design pattern is not a component, but a “to be
implemented” reusable solution

36. References
 [McConnell]: Steven McCollen - Code Complete
2° edition - http://www.cc2e.com/
 [BCK]: Bass, Clements, Kazman – Software
Architecture in practice – Addison Wesley 2003
 [C2]: http://c2.com/cgi/wiki
 [C#Style]: C# Code Style Guide - Scott Bellware
 Wikipedia