-
Notifications
You must be signed in to change notification settings - Fork 5
/
07_progettazione.html
93 lines (81 loc) · 7.41 KB
/
07_progettazione.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it" lang="it">
<head>
<title>Progettazione - sweki</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="author" content="Giorgio Giuffrè" />
<meta name="keywords" content="sweki, ingegneria, software, progettazione" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="prev" href="06_ingreqq.html" />
<link rel="next" href="08_documentazione.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="06_ingreqq.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="08_documentazione.html">></a>
</h1>
<h2>la <span xml:lang="en">wiki</span> di Ingegneria del <span xml:lang="en">Software</span></h2>
</div>
<div id="content">
<h1>Progettazione</h1>
<h2>Definizione</h2>
<p>La risoluzione di un problema attraversa due fasi: la prima è <strong>analitica</strong>, la seconda <strong>sintetica</strong>. Nella fase analitica il problema viene decomposto, approfondito nel dettaglio per capire di quali parti è formato (approccio <em xml:lang="en">top-down</em>); in quella sintetica, invece, si ricompongono i pezzi trovati al passo precedente e si sintetizza una soluzione per il problema (approccio <em xml:lang="en">bottom-up</em>). Se la fase analitica ("qual è il problema?") corrisponde grosso modo all'attività di analisi dei requisiti, quella sintetica ("come risolvere il problema?") è proprio la progettazione. Formalmente, la progettazione è la definizione<sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup> dell'architettura, dei componenti, delle interfacce e delle altre caratteristiche di un sistema o componente.</p>
<p>L'architettura di un <span xml:lang="en">software</span> è, tipicamente, un insieme di <strong>moduli</strong> che si raggruppano in <strong>unità</strong>, che a loro volta si raggruppano in <strong>componenti</strong>, che vanno a formare un <strong>sistema</strong>. Acronimo tattico per ricordarsi: <abbr title="System, Component, Unit, Module">SCUM</abbr>.</p>
<h2>Progettazione architetturale e progettazione di dettaglio</h2>
<p>Il processo di progettazione passa attraverso due attività, che si situano tra l'analisi dei requisiti e l'implementazione:</p>
<ul>
<li><strong>progettazione architetturale</strong>, di alto livello, che descrive come il <span xml:lang="en">software</span> viene organizzato in componenti;</li>
<li><strong>progettazione di dettaglio</strong>, che descrive il comportamento di tali componenti.</li>
</ul>
<p>Nel piano di qualifica, se l'analisi è verificata dal test di sistema, la progettazione architetturale è verificata dai test d'integrazione e quella di dettaglio dai test di unità. (Questo è il cosiddetto "modello a V".)</p>
<h2>Architettura</h2>
<p>Obiettivo della progettazione è definire l'architettura del sistema. Per architettura s'intende la decomposizione di un sistema in componenti, l'organizzazione di tali componenti, le interfacce dei componenti e i loro paradigmi di composizione. In generale, una buona architettura deve rispettare i seguenti princìpi:</p>
<ul>
<li>sufficienza — deve soddisfare tutti i requisiti;</li>
<li>comprensibilità — può essere capita dagli <span xml:lang="en">stakeholders</span>;</li>
<li>modularità — le sue parti sono chiare e distinte, non si sovrappongono;</li>
<li>robustezza — è capace di gestire un'ampia classe di input diversi;</li>
<li>flessibilità — permette modifiche a costo contenuto;</li>
<li>riusabilità — alcune sue parti possono essere utilmente impiegate in altre applicazioni;</li>
<li>efficienza;</li>
<li>affidabilità — è altamente probabile che svolga bene il suo compito;</li>
<li>disponibilità — necessita di poco tempo di manutenzione fuori linea;</li>
<li>sicurezza rispetto ai malfunzionamenti;</li>
<li>sicurezza rispetto a intrusioni;</li>
<li>semplicità — ogni parte contiene solo il necessario e niente di superfluo;</li>
<li>incapsulamento — nasconde i dettagli implementativi;</li>
<li>coesione — parti associate concorrono agli stessi obiettivi (l'approccio a oggetti aiuta molto a ottenere coesione);</li>
<li>basso accoppiamento — parti distinte dipendono il meno possibile le une dalle altre.</li>
</ul>
<p>Tutte queste qualità devono essere misurabili. In particolare, l'accoppiamento è misurabile interpretando le componenti di un sistema come i nodi di un grafo orientato dove gli archi sono dipendenze di un componente nei confronti di un altro; il numero di archi entranti (<em xml:lang="en">fan-in</em>) è indice di utilità, mentre il numero di archi uscenti (<em xml:lang="en">fan-out</em>) è indice di dipendenza. Riguardo alla riusabilità, infine, è bene notare che costituisce un guadagno soltanto nel lungo termine, mentre nel breve termine è un puro costo.</p>
<h2><em xml:lang="en">Design pattern</em> e stili architetturali</h2>
<p>Un <em xml:lang="en">design pattern</em> è una soluzione progettuale a un problema ricorrente. Per la progettazione esistono soluzioni progettuali di alto livello (gli stili architetturali) e di basso livello (i <span xml:lang="en">design pattern</span>).</p>
<h2>Progettazione architetturale</h2>
<p>Esistono vari stili architetturali e aderire a uno di essi garantisce coerenza; alcuni stili sono:</p>
<ul>
<li>strutture generali (livelli, oggetti, <span xml:lang="en">pipes</span> e filtri, <span xml:lang="en">blackboard</span>);</li>
<li>sistemi distribuiti (<em xml:lang="en">client-server</em>, <em xml:lang="en">three-tiers</em>, <em xml:lang="en">peer-to-peer</em>, <em xml:lang="en">broker</em>);</li>
<li>sistemi interattivi (<em xml:lang="en">Model-View-Controller</em>, <em xml:lang="en">Presentation-Abstraction-Control</em>);</li>
<li>sistemi adattabili (<span xml:lang="en">microkernel</span>, riflessione);</li>
<li>altri (<span xml:lang="en">batch</span>, interpreti...).</li>
</ul>
<h2>Progettazione di dettaglio</h2>
<p>Uno stile architetturale è una soluzione progettuale di alto livello; per la progettazione di dettaglio, invece, si ricorre ai <span xml:lang="en">design pattern</span>, che si dividono in tre famiglie:</p>
<ul>
<li><span xml:lang="en">design pattern</span> creazionali, che cercano di rendere un sistema indipendente dall'implementazione concreta delle sue componenti;</li>
<li><span xml:lang="en">design pattern</span> strutturali, che affrontano problemi riguardanti la composizione di classi e oggetti;</li>
<li><span xml:lang="en">design pattern</span> comportamentali, che si occupano del comportamento degli oggetti e delle collaborazioni tra essi.</li>
</ul>
<p>La progettazione di dettaglio deve definire delle unità il cui carico di lavoro sia realizzabile da un singolo programmatore, in parallelo con le altre unità. Quanto più piccolo è il compito tanto più piccolo è il rischio.</p>
</div>
<div id="footnotes">
<ol>
<li id="ftn1">Il termine "definizione" va inteso sia come processo sia come il risultato di tale processo.</li>
</ol>
</div>
</body>
</html>