Approcci al design

696 views

Published on

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).

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
696
On SlideShare
0
From Embeds
0
Number of Embeds
68
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Approcci al design

  1. 1. Approcci al designCome affrontare la progettazione di un software Andrea Colleoni - 2011
  2. 2. Summary Motivazione: i driver di progettazione OOP Dimensionamento del problema Architettura SW Object Oriented Design
  3. 3. Dove nel processo?
  4. 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. 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. 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. 7. Decomposizione epartizionamento 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. 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. 9. OOP è ancora ilOOP paradigma diLe attività sono riferimento: attuale ecorrelate 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. 10. Driver di progettazione OOP Modularità  Manutenibilità, Riusabilità, Estensibilità Robustezza  Sicurezza, Fault-tolerance, Compatibilità Usabilità
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. Quanto costa lo sviluppo? Examples of support of implementation Estimation approach Category of estimation approachAnalogy-based estimation Formal estimation model ANGEL, Weighted Micro Function PointsWBS-based (bottom up) Project management software, company Expert estimationestimation specific activity templatesParametric models Formal estimation model COCOMO, SLIM, SEER-SEM Function Point Analysis[12], UseSize-based estimation Formal estimation model Case Analysis, Story points-basedmodels[11] estimation in Agile software developmentGroup estimation Expert estimation Planning poker, Wideband Delphi Combination-based Average of an analogy-based and a WorkMechanical combination estimation breakdown structure-based effort estimate Combination-based Expert judgment based on estimates fromJudgmental combination estimation a parametric model and group estimation
  23. 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. 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. 25. Scelte Chiave per la Construction  Scelta del linguaggioKind of Program Best Languages Worst LanguagesCommand-line processing Cobol, Fortran, SQLCross-platform Java, Perl, Python Assembler, C#, Visual BasicdevelopmentDatabase manipulation SQL, Visual Basic Assembler, CDirect memory Assembler, C, C++ C#, Java, Visual BasicmanipulationDistributed system C#, JavaDynamic memory use C, C++, Java, C#Easy-to-maintain program C++, Java, C#, Visual BasicReal-time program C, C++, Assembler C#, Java, Python, Perl, Visual BasicSecure program C#, Java C, C++Web development C#, Java, JavaScript, PHP, Assembler, C Visual Basic
  26. 26. Coding & Teamwork
  27. 27. QA & Tools
  28. 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. 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. 30. Caratteristiche chiave del buondesign Minimal complexity Ease of maintenance Minimal connectedness Extensibility Reusability High fan-in Low-to-medium fan-out Portability Leanness Stratification Standard techniques
  31. 31. Granularità del design
  32. 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. 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 systems 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. 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 dont 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. 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. 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

×