Una panoramica sugli approcci metodologici al design di Software destinato all'impresa (Enterprise).
La presentazione fa parte di una serie di presentazione sulla progettazione, la programmazione e l'adozione di metodologie nel campo dello sviluppo di Software Object Oriented (OOP).
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
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
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
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