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