approcci al design
DESCRIPTION
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).TRANSCRIPT
Come affrontare la progettazione di un software
Andrea Colleoni - 2011
Approcci al design
SummaryMotivazione: i driver di progettazione OOPDimensionamento del problemaArchitettura SWObject Oriented Design
Dove nel processo?
Problem solvingIdentificazione e definizione del problemaUso di astrazione, analogia, brainstorming,
divide et impera, riduzione, test di ipotesiLa soluzione può essere ottenuta
impiegando un mix di atteggiamenti e la sua bontà e la rapidità con la quale è ottenuta è influenzata dall’esperienza
Analogia e riduzioneAnalogia: 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
Astrazione e raffinamentoAstrazione: 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)
Decomposizione e partizionamentoLa 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)
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
OOPLe attività sono correlate tra loro
OOP è ancora il paradigma di riferimento: attuale e valido
• Analogia e riduzione
• Astrazione e raffinamento
• Decomposizione e partizionamento
• Software Construction
RiusoDesign
OO
Creazione
Moduli
Software
Quality
OO è un approccio concettuale alla rappresentazione e alla soluzione di un problema
Il linguaggio e lo stile di programmazione (imperativa, dichiarativa) sono strumenti con cui realizzare la soluzione OO
Driver di progettazione OOPModularità Manutenibilità, Riusabilità,
EstensibilitàRobustezza Sicurezza, Fault-tolerance,
CompatibilitàUsabilità
Uso delle metaforeUna 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.
Dimensione del problemaNon esiste un modo unico di affrontare un problema; in
primo luogo è necessario identificare la dimensione del problemaUn 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.
Approccio incrementaleL’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
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
Piccoli problemiEffort complessivo < 30 gguNell’ordine di qualche K LOCCostruzione SW circa 65% dell’effort complessivoSi cerca nell’ordine di soddisfare il problema nei
seguenti modi:1. Ricerca di soluzioni già funzionanti2. Personalizzazione (configurazione) di soluzioni
esistenti3. Accrescimento di soluzioni esistenti tramite
l’aggiunta di funzioniIn generale, sono preferibili approcci del tipo:
Buy over makeDesign bottom-up
Problemi di medie dimensioni30 ggu < effort complessivo < 200 gguNell’ordine di qualche decina di K LOCCostruzione SW circa 50% dell’effort complessivoTramite 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
iterativoUso di metodologie più agili
Problemi di grandi dimensionieffort complessivo > 200 gguNell’ordine di qualche centinaio di K LOCMaggiore attenzione al design, che ha l’impatto
più oneroso in termini di incidenza degli erroriIl problema nel suo complesso può essere
gestito con i seguenti approcci:Metodologie di design più rigorose ed affidabiliMake over buy nelle parti alte della gerarchia
della decomposizione funzionale; Buy over make nella parte bassa
Design top down
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
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
Make vs. BuyMake
Può avere un costo elevato, ma non sviluppa dipendenze da soggetti terzi
Non beneficia di esperienza e maturità acquisiteAccresce il toolset dei partecipanti sulla tecnologia di
riferimento selezionata per la realizzazioneBuy
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
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
Quanto costa lo sviluppo?
Estimation approach CategoryExamples of support of
implementation of estimation approach
Analogy-based estimation
Formal estimation model
ANGEL, Weighted Micro Function Points
WBS-based (bottom up) estimation
Expert estimationProject management software, company specific activity templates
Parametric modelsFormal estimation model
COCOMO, SLIM, SEER-SEM
Size-based estimation models[11]
Formal estimation model
Function Point Analysis[12], Use Case Analysis, Story points-based estimation in Agile software development
Group estimation Expert estimation Planning poker, Wideband Delphi
Mechanical combinationCombination-based estimation
Average of an analogy-based and a Work breakdown structure-based effort estimate
Judgmental combinationCombination-based estimation
Expert judgment based on estimates from a parametric model and group estimation
Linguaggi e piattaformeI 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
IDE e ALM ToolsIDE devono essere
ProduttiviProdurre SW di qualità più elevata possibile
ALM Tools devonoFormalizzare e automatizzare l’intera vita del
SWDisponibilità di librerie
Librerie con scopi diversi sono disponibili in tecnologie diverse
Scelte Chiave per la ConstructionScelta del linguaggio
Kind of Program Best Languages Worst Languages
Command-line processing
Cobol, Fortran, SQL
Cross-platform development
Java, Perl, Python Assembler, C#, Visual Basic
Database manipulation SQL, Visual Basic Assembler, C
Direct memory manipulation
Assembler, C, C++ C#, Java, Visual Basic
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, VisualBasic
Secure program C#, Java C, C++
Web development C#, Java, JavaScript, PHP, Visual Basic
Assembler, C
Coding & Teamwork
QA & Tools
Object Oriented DesignI risultati dell’attività di OOD sono:
Modello concettuale: indipendente dalla tecnologia
Casi d’uso: descrizione semi formale di sequenze di eventi
Modello dei datiStoryboard o modello UXCRC CardsUML
Altri approcci al designDomain 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.
Caratteristiche chiave del buon designMinimal complexityEase of maintenanceMinimal connectednessExtensibilityReusabilityHigh fan-inLow-to-medium fan-outPortabilityLeannessStratificationStandard techniques
Granularità del design
Pattern e anti-patternIn 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
Architectural PatternsThe 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.
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)
Design patternsA 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
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
BellwareWikipedia