Corso di Ingegneria del Software - Dipartimento Informatica · Lezione 10 Da Analisi a Progetto 47...

Corso di Ingegneria del Software

Paolo Bottoni

Lezione 10: Dall'analisi al progetto

Flusso di lavoro di analisi: ruoli e

artefatti

Lezione 10 Da Analisi a Progetto Ingegneria del Software 2 Lezione 10 Da Analisi a Progetto 2 Ingegneria del Software

Lezione 11 Da Analisi a Progetto Ingegneria del Software 3 3

Da casi d'uso ad analisi

• Linguaggio cliente

• Vista esterna

• Struttura a use-case

• Contratto tra cliente e

sviluppatori

• Non formalmente corretto

• Funzionalità

• Casi d'uso da analizzare

ulteriormente

• Linguaggio sviluppatore

• Vista interna

• Struttura stereotipi e package

• Usato da sviluppatori

• Formalmente corretto

• Realizzazioni

• Deriva da casi d'uso

Casi d'uso Analisi


Stereotipi per classi d'analisi

<<entity>> <<boundary>> <<control>>


Stereotipo <<entity>>

• Informazione lunga durata, spesso persistente

• Dati e comportamenti per fenomeni o concetti

• Derivabili da classi di modelli di business o di

dominio, ma più orientate a sistema


Stereotipo <<boundary>>

• Interazione tra sistema e attori (umani/dispositivi)

• Isola cambiamenti interfacce utenti, comunicazione

• Spesso astrazione elemento software di interfaccia

• Non richiede di descrivere realizzazione fisica

• Corrispondenza con attori


Stereotipo <<control>>

• Coordinamento, sequenza, transazioni e controllo

per altri oggetti

• Logica di business non legata a specifiche entità

• Dinamica sistema

• Associabili a casi d'uso (controllo flusso eventi)


Identificazione delle classi (analisi)

• Classi entità definite da descrizione casi

d'uso e modello dominio

• Classi boundary per ogni attore

• Classi entity per ogni entità

• Classi di controllo definite da caso d'uso

Lezione 11 Da Analisi a Progetto Ingegneria del Software I 9 9

Stereotipi in diagrammi di classe


Consigli empirici

• Usare sempre linguaggio di business

• Modelli devono “raccontare una storia”

• Mantenersi a livello generale

• Distinguere domini di problema e soluzione

• Minimizzare accoppiamento

• Introdurre ereditarietà solo se gerarchie in dominio

• Valutare utilità per stakeholder

Lezione 10 Da Analisi a Progetto Ingegneria del Software 11

Analisi nomi-verbi

11


Schede CRC

12


Package

• Contenitore e possessore per elementi di modello

• Utilizzi – Raggruppa elementi in relazione semantica

– Definisce confine semantico in modello

– Fornisce elementi a gestione configurazione

– Fornisce unità per sviluppo parallelo (design)

– Fornisce namespace incapsulato con unicità di nomi

• Ogni elemento appartiene a uno e un solo package


Package di analisi

• Contengono

– Casi d'uso

– Classi di analisi

– Realizzazioni di casi d'uso


Notazione (1)


Notazione (2)

Editor

+ Controller + DiagramElements + DomainElements + GraphicsCore - MotifCore - WindowsCore

Editor:Controller


Analisi architetturale

Organizzazione in package coesi e stratificazione

Sales Products

AccountManagement InventoryManagement


Identificazione package d'analisi

• Raggruppare cluster di classi coesi

• Trovare gerarchie di ereditarietà

• Casi d'uso per processo o attore possono

indicare package

• Alta coesione dentro package

• Basso accoppiamento fra package

• Evitare package annidati


Dipendenze cicliche

• Fondere in unico package

• Fattorizzare elementi comuni in nuovo package

• Attenzione a orientamento associazioni!


Elementi della realizzazione

• Diagrammi di classi di analisi – Classi di analisi che interagiscono per realizzare caso d’uso

• Diagrammi di interazione – Collaborazioni e interazioni tra istanze che lo realizzano

• istantanee esecuzione

• Requisiti speciali – Identificazione nuovi requisiti specifici a caso d’uso

• Raffinamento casi d’uso – Si può dovere aggiornare caso d’uso


Stereotipi in diagrammi di interazione

21

Lezione 10 Da Analisi a Progetto 22 22

Obiettivi flusso di lavoro di progetto

• Comprensione di vincoli non-funzionali e tecnologici

• Requisiti di sottosistemi, interfacce, classi

• Decomposizione lavoro implementativo

• Interfacce fra sottosistemi

• Astrazione implementazione

Ingegneria del Software


Caratteristiche del design

• Specifica completa implementazione di funzionalità.

• Dominio del problema e Dominio della soluzione

– Requsiti: da dominio problema

– Analisi: esplora dominio da punto di vista stakeholder.

– Progetto: considera soluzioni tecniche in dominio

soluzione per fornire modello implementabile di sistema.


Flusso di lavoro di Design

• Principalmente fine Elaboration e inizio Construction

• Aspetti comuni ad Analysis, svolgimento parallelo.

• UP prevede unico team che svolge fasi da

Requirements ad Analysis a Design

• Fuoco su obiettivo piuttosto che su compito.


Flusso di lavoro di progetto: ruoli e artefatti

da Arlow, Neustadt, UML and the Unified Process, Addison Wesley, 2002


Modelli di Analisi e Design

• Concettuale

• Generico (per vari design)

• Stereotipi concettuali

• Meno formale e costoso

• Pochi strati

• Dinamico (comunicazione)

• Non legato a tool

• Non richiesto mantenerlo

• Definisce struttura, anche architetturale

• Fisico

• Specifico applicazione

• Stereotipi linguaggio

• Più formale e costoso

• Molti strati

• Dinamico (sequence)

• Round-trip con implementation

• Mantenuto

• Dà forma a sistema, mantenendo struttura


Tracciabilità

<<analysisModel>>

Model <<analysisSystem>

System

<<designModel>>

Model <<designSystem>>

System

<<trace>> <<trace>>


Conseguenze

• Più enfasi su interfacce

– forte ruolo architetturale in progetto

• Package di analisi decomponibili in più

sottosistemi di progetto

– e.g. sottosistemi corrispondenti a diversi

componenti

• Quanti modelli?


Scelte

• Raffinare modello di analisi in progetto – Unico modello di progetto, si perde modello di analisi

• Raffinare modello di analisi in progetto, strumento ricostruisce vista di analisi – Modello di analisi ricostruito non garantito accettabile

• Congelare modello di analisi, copiarlo e raffinarlo – Due modelli, non coerenti

• Due modelli separati – Mantenimento coerenza costoso


Vantaggi di mantenere modello di analisi

• Poche classi, più comprensibile

• Utile per

– spiegare progetto a nuove persone

– comprendere sistema successivamente

– soddisfazione requisiti e tracciabilità

– pianificare mantenimento e miglioramenti

– comprendere architettura logica

– affidare costruzione esternamente


Casi in cui non serve

• Sistemi piccoli (meno di 200 classi di

Design), ancora comprensibili

• Sistemi non strategici

• Sistemi con vita breve

– Ma molti sistemi vivono più di quanto atteso!


Componenti del modello di progetto

• Analoghe a modello di analisi, ma più

formate e con dettagli di implementazione

– sottosistemi di progetto

– classi di progetto

– interfacce

– realizzazioni di casi di uso - progetto

– diagramma di deployment

Lezione 10 Da Analisi a Progetto 33

Sottosistemi

• Alta coesione, basso accoppiamento

• Separazione di responsabilità

• Strati di applicazione tracciabili a package o classi

di analisi

• Wrapper per riuso di prodotti (middleware o

sistema) o sistemi legacy (a livello di applicazione)



Sottosistemi di servizio

• Localizzano servizi, facilitano cambiamento.

• Identificati da package di analisi.

• Possono fornire servizi in termini di interfacce

• Soddisfano requisiti non-funzionali

• Decomponibili per dispiegamento



Identificazione di classi attive

• Analisi requisiti di concorrenza

– Performance, throughput, disponibilità

– Distribuzione su nodi diversi (anche per gestione

comunicazione fra nodi)

– Analisi problemi specifici (e.g. deadlock, liveness,

riconfigurazione)

• Definizione ciclo di vita



Meccanismi generici

• Persistenza

• Distribuzione trasparente di oggetti

• Aspetti di sicurezza

• Individuazione e recupero di errori

• Gestione transazioni

– Modellabili come collaborazioni/protocolli



Origini delle classi di progetto

• Dominio del problema

– raffinamento classi di analisi

• aggiunta di dettagli di implementazione

• separazione di classe di analisi in classi diverse

• Dominio della soluzione

– biblioteche di classi di utilità e componenti riusabili

– middleware, GUI framework



Classi di progetto

• Completare insieme attributi

• Trasformare operazioni in insieme completo di metodi

BankAccount

name number balance

deposit() withdraw() calculateInterest()

BankAccount

-name: String -number: String -balance: double = 0

+BankAccount(name: String, number: String) +deposit(m:double):void +withdraw(m:double):boolean +calculateInterest():double +getName():String +setName(n:String):void +getBalance():double +BankAccount(name: String, number: String, m:double)

<<trace>>



Classi di design corrette

• Considerare punto di vista clienti classi

• Classi devono essere

– Complete e sufficienti

– Primitive

– Alta coesione

– Basso accoppiamento



Completezza e sufficienza

• Metodi pubblici definiscono contratto

• Nomi significativi: creano attese da soddisfare

• Metodi focalizzati su scopo classe.

• Non aggiungere caratteristiche



Primitive

• Offrire servizi primitivi e atomici

• Non avere metodi diversi per stessa cosa

• Primitività rilassabile solo quando vantaggio

prestazioni significativo



Alta coesione

• Realizzazione di singolo concetto

• Metodi focalizzati su scopo della classe

• Se classe ha diverse responsabilità, creare

classi “helper” a cui delegare



Basso accoppiamento

• Associazioni fra classi derivate da responsabilità

• Associare classi solo se vero collegamento semantico

• Fonti per associazioni:

– modello di analisi

– vincoli di implementazione.

• Accoppiamento entro package ammissibile



Ereditarietà in progetto

• In analisi ammessa solo per IS_A

• In progetto per riusare codice, ma:

– forte accoppiamento

– bassa incapsulazione, cambiamenti si propagano

– non flessibile, gerarchia rimane fissa

• aggregazione e composizione, alternative flessibili



Esempio

Employee

Manager Programmer

john:Programmer

<<instance>>

Employee

Manager Programmer

john:Employee

<<instance>>

Job

:Manager :Programmer


Generalizzando: il pattern State



Realizzazione di interfacce

• Ereditarietà comprende due aspetti

– interfaccia: metodi pubblici classe di base

– implementazione: attributi, associazioni, metodi privati e

protetti classe di base

• Realizzazione di interfaccia

– interfaccia: insieme di metodi pubblici, no implementazione



Interfaccia

• Specifica e dà nome a insieme di operazioni

• Separa specifica di funzionalità da sua

implementazione da parte di classificatore

• Definisce contratto implementato (pubblicamente)

da classificatore (classe, sottosistema, componente)



Struttura di interfaccia

• Deve avere

– segnatura completa operazioni

– semantica operazioni (testo,pseudocode)

– (opzionali) stereotipi, vincoli, tag

• Non può avere

– istanze

– implementazioni di operazioni

• Può dichiarare proprietà, ma realizzazione

non richiede implementazione strutturale



Sintassi grafica

<<interface>> Activate

activate() deactivate()

Sensor


Zone


Sensor


Zone


Activate



Disaccoppiamento da classi

specifiche

Printer

Customer

<<interface>> Print

print(g:Graphics):void

Order <<uses>>



Interfacce fra sottosistemi

<<subsystem>>

GUI

<<subsystem>>

BusinessLogic

CustomerManager AccountManager



Aggregazioni di interfacce

Activate

IdCard


Zone


Alarm


Sensor


1

*



Individuare le interfacce

• Discutere associazioni

– vanno a singola classe o devono essere più flessibili?

• Discutere invio messaggi

– vanno a oggetti di singola classe?

• Fattorizzare gruppi di operazioni riusabili

• Fattorizzare insiemi di operazioni comuni a più classi

• Identificare classi che giocano stesso ruolo

• Identificare possibili estensioni



Relazioni fra modelli di analisi e di progetto

Analysis class

Design class

<<interface>> Interface

<<trace>>

1

0..*

0..*

Use case realization - analysis

Use case realization - design

<<trace>>

1 1


• Descrivono struttura di ruoli.

– Collettivamente ottengono funzionalità desiderata

• Scopo primario spiegare funzionamento sistema

• Sopprime dettagli identità o classe partecipanti

• Rappresentata da tipo classificatore

– Entità cooperanti come ruoli ricoperti da istanze.

– Connettori definiscono cammini di comunicazione

• Entità cooperanti giocano ruoli e comunicano

– Entità proprietarie di collaborazioni

– Vista di insieme di classificatori.

– Caratteristiche richieste per svolgere ruolo

Collaborazioni


• Relazioni fra ruoli rilevanti mostrate come connettori

• Ruoli ricoperti da istanze durante interazione.

• Ruoli di collaborazione definiscono uso istanze

– Specifica proprietà istanze per partecipare collaborazione

• Tipo ruolo definisce insieme caratteristiche istanze

• Connettori tra ruoli specificano cammini fra istanze

Collaborazioni


• Collaborazione specializzata da altre collaborazioni

• Se ruolo esteso, tipo ruolo in collaborazione

specializzata conforme a tipo ruolo in generale

• Specializzazione tipi di ruolo non implica

specializzazione classificatori che realizzano ruolo

– Sufficiente conformità a vincoli per ruoli

• Collaborazione non direttamente istanziabile

– Realizzata da cooperazione istanze che ricoprono ruoli

Specializzazione di collaborazioni

Lezione 11 Da Analisi a Progetto Ingegneria del Software I 59

Esempio

Lezione 11 Da Analisi a Progetto


Diagramma di sequenza per observer


• Uso: spiegare relazioni tra proprietà classificatore

• Pattern descritto da collaborazione in contesto

– Entità specifiche contesto legate a ruoli collaborazione

• Caratteristiche strutturali

• Specifiche di istanze

• Ruoli in collaborazioni contenenti quella usata

• Più occorrenze collaborazione in classificatore

– Ognuna con diversi insiemi di ruoli e connettori

– Stesso ruolo può essere coinvolto in occorrenze multiple

– Dipendenze fra caratteristiche tipo collaborazione

(fornitore) e caratteristiche classificatore (cliente)

Uso di collaborazione


Collaborazioni come pattern riusabili


Raffinamento modello di analisi

• Associazioni aggregazioni o composizioni

• Implementazione classi di associazione

• Gestione molteplicità e direzionalità: – associazioni uno a molti

– associazioni molti a molti

– associazioni bidirezionali


Implementazione di parte_di

• Realizzate attraverso attributi

• Modellazione come attributi per tipi primitivi,

di utilità, o comunque non interessanti da

modellare in sé

• Altrimenti realizzazioni complesse


Raffinamento

• Aggiungere molteplicità e nomi di ruolo se

assenti in analisi

• Stabilire ruoli intero e parte

• Se molteplicità intero == 1

– possibile uso composizione

– altrimenti usare aggregazione

• Navigabilità unidirezionale

– da intero a parte


Gestione molteplicità

• Associazioni 1-a-1 – composizione, fusione in singolo classe, attributo se

parte non importante

• Associazioni n-a-1 – parte condivisa, non composizione

– se non ci sono cicli, usare aggregazione

• Associazioni 1-a-n – collezione di parti, supporto nativo, o classi collezione


Collezioni

• Hanno metodi:

– add(o: Object):Boolean

– remove(o: Object):Boolean

– Object find(d:Descriptor)

– Object next()

– Boolean hasNext()


Tre strategie

• Modellazione esplicita classe collezione

• Specificare implementazione a CASE

• Specificare semantica collezione, ma non

implementazione

A Vector B 1 * 1 1

A {Vector}* 1

B

A {ordered}* 1

B


Proprietà semantiche collezioni

• In UML

– {ordered}, {unordered}

• Definite da utente (esempi)

– {sorted} secondo qualche chiave

– {indexed} chiave numerica

– {set} duplicati non ammessi

– {lifo} organizzazione a stack

– {queue} organizzazione a coda


Relazioni reificate

• Non supportate direttamente da nessun

linguaggio (per ora)

– associazioni m-a-n

– associazioni bidirezionali

– association classes


Associazioni m-a-n

• Realizzate con aggregazione, decisione su quale

capo rappresenta intero

Task Resource * *

Resource-centric Task Resource * *

Allocation 1 1

Task-centric Resource Task * *

Allocation 1 1

Allocation-centric Resource Task

* * Allocation

1 1


Associazioni bidirezionali

Usate per modellare callback

A B 1 *

A B 1 *

1 *

<<trace>> <<trace>>

Intero passa se stesso come parametro a metodo parte, o parte crea istanza intero in suo metodo

A B 1 *

1 *


Classi di associazione

Company Person

Job

salary:double

* *

Company Person

Job

salary:double 1

* 1

*

{una persona può avere solo un lavoro con una compagnia}


Casi d’uso dall’analisi

• Raffinamento

– Diagrammi di interazione di progetto

– Diagrammi di classi

• Fuoco sul come

– Scopo esplicativo

– Modellazione esaustiva solo per generazione

automatica di codice, rara


Interazioni con sottosistemi

• Sottosistemi come black box

• Forma di descrittore per diagrammi di interazione

Sales Agent

<<subsystem>> :Customer

CustomerManager::getCustomerDetails(cid)


Nuovi diagrammi

• Illustrazione di questioni tecniche da Progetto

• Diagrammi che illustrano meccanismi specifici,

possono riguardare diversi casi d’uso

– e.g. persistenza, distribuzione, transazioni


Modello di implementazione

• Implementazione di elementi modello di progetto

in termini di componenti

• Organizzazione componenti secondo meccanismi

di strutturazione e modularizzazione


Dipendenza dal design

• Modello di implementazione in corrispondenza

<<trace>> 1 a 1 con modello di progetto

• Vista di implementazione su modello di progetto

• Fa parte modello di progetto


Artefatti prodotti

• Piano di integrazione – Sequenza di build (versione eseguibile di sistema) per iterazione

• Funzionalità da costruire per ogni build

• Parti modello di implementazione influenzate da build

• Diagramma di componenti – Dipendenze fra componenti software che implementano sistema

• Diagramma di dispiegamento – Nodi fisici su cui porre software e dipendenze fra i nodi


Build

• Build dovrebbe aggiungere funzionalità a precedente

implementando casi d’uso e/o scenari completi

• Non includere troppe componenti nuove o raffinate

• Deve essere basato sul build precedente

• Partire da strati bassi ed espandersi verso strati generali

e specifici di applicazione


Componenti

• Parte modulare di sistema.

– Incapsula contenuto

– Manifestazione rimpiazzabile entro ambiente

• Definisce comportamento in termini di interfacce

– Usabile come tipo

– Sostituibilità solo se tipi conformi

• Unità di riuso

• Manifestato in artefatti

– Disposti in ambiente esecuzione

81

Esempi: • File sorgente • Sottosistemi di implementazione • Controlli ActiveX • JavaBeans • Enterprise JavaBeans • Java servlets • Java Server Pages


Stereotipi di artefatti

• <<executable>>: programma eseguibile su nodo

• <<file>>: contiene codice sorgente o dati

• <<library>>: statica o dinamica

• <<table>>: tabella di base di dati

• <<document>>: documento

• <<subsystem>>: unità in decomposizione gerarchica


Sottosistemi

• Componenti con stereotipo <<subsystem>>

• Si usano in Design e Implementation

• Contengono:

– classi di progetto e interfacce

– realizzazioni di casi d’uso

– altri sottosistemi

– elementi di specifica (e.g. casi d’uso)

• Usati per: – separare questioni relative a progetto

– rappresentare componenti a grana grossa

– racchiudere sistemi legacy


Costruzione di sottosistemi

• Suddivisione di package di analisi

• Altri sottosistemi relativi a dominio soluzione

– classi di accesso a basi di dati

– classi di comunicazione

• Dipendenze fra sottosistemi


Stratificazione

<<subsystem>>

GUI

<<subsystem>>

Customer

<<subsystem>>

Order

<<subsystem>>

Product

<<subsystem>>

Accounts

<<subsystem>>

javax.swing

<<subsystem>>

java.sql <<subsystem>>

java.util

{global}

Order Manager

Customer Manager

Product Manager

Account Manager

pre

senta

tion

busin

ess logic

utility

dom

ain

serv

ices


Connettori

• Estensione da classi strutturate

– Aggiungono contratti e notazione specifica

• delegation lega contratto a realizzazione

• assembly lega parti in cui alcune forniscono

e altre usano servizi

86


Notazione

87


Diagrammi di deployment

• Hardware fisico su cui eseguire e distribuire software.

• Forma di descrittore contiene – Nodi: tipi di hardware

– Componenti: tipi di software

– Relazioni fra nodi

• Forma di istanza: – Istanze di nodi: specifici elementi hardware

– Istanze di software: copie specifiche

– Relazioni fra istanze di nodi


Creazione dei diagrammi

• Prima versione creata durante progettazione.

• In genere prima forma di descrittore.

• Raffinata man mano che si conoscono

dettagli su sito di installazione


Deployment: nodi e artefatti

Corso di Ingegneria del Software - Dipartimento Informatica · Lezione 10 Da Analisi a Progetto 47...

Documents

Transcript of Corso di Ingegneria del Software - Dipartimento Informatica · Lezione 10 Da Analisi a Progetto 47...