Sperimentazioni di Ingegneria del Software

G.Berio

V. Bono

2008

Obiettivi del corso

• Approfondire la notazione UML (Unified Modeling Language)

• Approfondire le caratteristiche dei processi di sviluppo detti orientati agli oggetti

• Sperimentare con strumenti CASE (Computer Aided Software Engineering) l’uso della notazione UML e dei processi di sviluppo object-oriented

Pre-requisiti

• I medesimi di Ingegneria del Software (logica, basi dati etc.)

• Conoscere il contenuto del corso di Ingegneria del Software

Organizzazione• Parte I: Ingegneria del Software - orientato agli oggetti -

con processi e metodologie orientati agli oggetti– Breve riepilogo ed approfondimento su alcuni aspetti della

ingegneria del software– The Unified Process (Rational/IBM)– Diagrammi UML (2.0)

• Parte II: Ingegneria della progettazione con pattern; rappresentazione di pattern di progetto (design pattern) e di architettura (architectural pattern) con diagrammi UML (eventualmente introduzione ai framework)

• Parte III: Strumenti di sviluppo; esercitazioni guidate in laboratorio

• Parte IV: Progetto d’esame

Materiale di supporto

• Testo di riferimento: C. Larman, Applicare UML e i pattern, Terza edizione (prima edizione italiana), Pearson.

• Esercizi su UML: Bennet, Skelton, Lunn, Introduzione a UML, Collana Schaum’s, McGraw-Hill.

• Materiale aggiuntivo dato dai docenti (disponibile a http://www.di.unito.it/~berio)

Ulteriori richieste

• berio@di.unito.it

• bono@di.unito.it

Il problema della Ingegneria del Software (IEEE)

• Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio e manutenzione del software

• Studio di tali strategie

Definizioni

• Processo di sviluppo del software e sua rappresentazione

• Ingegneria dei requisiti e della progettazione; analisi e progettazione etc.

• Pratiche, metodi (usate in compiti)

• Metodologia di sviluppo del software

Ingegneria dei Requisiti• Identificazione, rappresentazione e gestione

dei requisiti del software

• Produce il modello analitico (Pressman) o specifica dei requisiti

• Usualmente distinti in funzionali e non funzionali

• Più o meno semplice identificarli: talvolta i requisiti devono essere trovati in modo esplicito (obiettivi del sistema…requisiti del software…ipotesi ambientali)

Ingegneria della Progettazione

• Produce il modello di progetto (Pressman) o specifica del software cioè dell’architettura del software e dei suoi componenti

• Ottenimento di una certa qualità del software descritta attraverso attributi di qualità (quality forecasting and assessment)

• Guidata da principi di progettazione (per costruire software di qualità)

Gestione della Ingegneria del Software

• Qualità del processo

• Stime sulla bontà del processo di sviluppo

• Project management, pianificazione dei compiti (o attività)

Vantaggi dell’orientamento agli oggetti nella Ingegneria del Software

• Correttezza, affidabilità, robustezza• Prestazioni• Usabilità• Verificabilità• Manutenibilità• Riparabilità• Evolvibilità• Riusabilità• Portabilità• Comprensibilità• Interoperabilità

Esempio di attributi di qualità

Ragioni principali: garantisce al meglio la tracciabilità, tende a nascondere le implementazioni

Vantaggi dell’orientamento agli oggetti con l’uso di pattern nella

Ingegneria del Software

• Manutenibilità

• Riparabilità

• Evolvibilità

• Riusabilità

• Portabilità

• Comprensibilità

• Interoperabilità

Ragione principale: sfrutta al meglio le migliori conoscenze pregresse su come raggiungere buone valutazione degli attributi elencati a lato

Processo iterativo

• Small steps (timeboxed), feedback and refinement

Iteration1

DesignCode, Test,

IntegrateAnalyze

...Iteration

2

DesignAnalyzeCode, Test,

Integrate

2 weeks 2 weeks

Processo incrementale (incremental delivery)

I l M o d e llo In c re m e n ta le ( In c re m e n ta l D e liv e ry )

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y f e e d b a c k

a n a ly s i s

d e s ig n c o d e

t e s t

in c r e m e n t # 1

in c r e m e n t # 2

d e liv e ry o f 1 s t in c re m e n t

d e liv e ry o f 2 n d in c re m e n t

d e liv e ry o f n t h in c re m e n t

in c r e m e n t # n

p r o je c t c a le n d a r t im e

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

a n a ly s i s

d e s ig n c o d e

t e s t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

a n a ly s is

d e s ig nc o d e t e s t

so ftw a re re q u ire m e n ts c a n b e w e ll d e fin e d o n c e o r in se v e ra l fu tu re ru n s! P r io r ity -d riv e n

Processo evolutivo

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

Communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

Unified Process• Iterativo, incrementale (evolutivo)

• Basato su fasi: ideazione (inception), elaborazione (elaboration), costruzione (construction), transizione (transition)

• Iterazioni iniziali scelte in base al rischio, alle aspettative del cliente e da un’architettura preliminare

• Iterazioni di elaborazione centrate sull’architettura

• Inizialmente sviluppato da Rational (acquisita da IBM), la società dei promotori storici di UML: Booch, Jacobson, Rumbaugh

Unified Process• Attenzione: le fasi non sono (necessariamente)

iterazioni.

Attività generiche (Larman ed UP le chiamano Discipline)

Fasi UP• Ideazione: visione, studio economico, stime

approssimate dei costi e dei tempi --- molto simile ad una fattibilità ma basata sulla rappresentazione di casi d’uso

• Elaborazione: visione raffinata, implementazione iterativa del nucleo dell’architettura, identificazione della maggior parte dei requisiti, risoluzione rischi maggiori, stime più realistiche

• Costruzione: implementazione di ciò che resta, cioè degli elementi più semplici ed a minor rischio, preparazione del rilascio (deployment)

• Transizione: beta test e rilascio

Glossario UP

• Rilascio (release): un sottoinsieme stabile ed eseguibile del prodotto finale

• Elaborato (artifact): un qualunque documento ovvero modello sviluppato

• Sistema: il sistema software• Pietra miliare (milestone): fine di un’iterazione ove

dovrebbero essere ottenuti risultati significativi, necessari per prendere ulteriori decisioni

• Iterazione: passo con obiettivi ben definiti (es. release, diagrammi UML, stime etc.)

• Incremento: differenza tra due release consecutivi

Uso di UML in UP• Solo UML è usato in UP (ad esempio, non si usano

DFD)• I vari diagrammi sono usati con una certa variabilità in

UP: se un diagramma non è utile non è necessario usarlo ma tale scelta deve essere indicata esplicitamente; UP dovrebbe essere specializzato prima di essere usato

• Tuttavia, UP stesso consiglia pratiche e metodi che indicano quando e come usare alcuni diagrammi UML

• I vari diagrammi sono trattati in UP seguendo principalmente iterazioni (quali diagrammi) e incrementi o evoluzioni (incrementi definiti su uno stesso diagramma)

Diagrammi UML usati (usabili) in UP

• Diagramma dei casi d’uso• Diagramma di attività• Diagramma delle classi• Diagramma di sequenza• Diagramma di comunicazione• Diagramma statechart• Diagramma dei package• Diagramma componenti e deployment

UML e UP (I)Ideazione Elaborazione Costruzione Transizione

Modello di business

Casi d’uso (di business), classi (di business), etc.

Modello analitico (non definito in UP)

Casi d’uso raffinati, classi del dominio di business, diagrammi di sequenza di sistema

Modello di progetto

Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati

Codice

a

b

c

aRaffinamento, analisi linguistiche, passaggi etc.

bPrincipi di progettazione per la qualità del software (pattern di progetto e di architettura)c

Generatori parametrizzati di codice, framework

Modelli usualmente prodotti

UML e UP (II)

Ideazione Elaborazione Costruzione Transizione

Modello di business

Classi del dominio di business

Modello analitico (non definito in UP)

Casi d’uso Casi d’uso raffinati, diagrammi di sequenza di sistema

Modello di progetto

Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati

Codice

Forza una visione “black box” del sistema (software) anche se ciò è discutibile nella filosofia object-oriented ove le classi (corrette) sono la principale giustificazione della maggiore qualità

r

Raffinamento r

UP ed altri elaborati (esempio)Ideazione Elaborazione Costruzione Transizione

Definizione del business

Visione, specifiche supplementari, glossario

Ingegneria dei Requisiti

Visione raffinata, specifiche supplementari (caratteristiche), regole di business (dominio), glossario

Visione raffinata, specifiche supplementari (caratteristiche), regole di business (dominio), glossario

Ingegneria della progettazione

Codice

Gestione… Rischi e loro gestione, specializzazione di UP, piano della prima iterazione, dell’elaborazione,

r

r

Fig. 6.1

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Rappresentazione delle IterazioniIt N° Ideazione Elaborazione Costruzione Transizione

Definizione del business

Cosa deve essere prodotto come elaborato

Cosa deve essere prodotto come elaborato

Etc.

Ing. Requisiti Cosa deve essere prodotto come elaborato

Cosa deve essere prodotto come elaborato

Ing. Progettazione

Cosa deve essere prodotto come elaborato

Cosa deve essere prodotto come elaborato

Codice NA Cosa deve essere prodotto come elaborato

Elaborato Ideazione Elaborazione Costruzione Transizione

Definizione del business

Modello del dominio di business

i r r...

Ing. dei requisiti Modello dei casi d’uso i r r r...

Specifica supplementare i r r r...

Glossario i r r r...

Visione i r r r...

Diagrammi di sequenza di sistema e contratti delle operazioni

i r r...

Ing. progettazione

Modello delle classi di progetto

i r... r r r...

Architettura i r r...

Modello dei dati i r... r r r...

Codice

Gestione….

i indica inizio ed r raffinamento (il raffinamento è spesso un incremento sull’elaborato)

Elaborato Ideazione Elaborazione

Costruzione

Transizione

Definizione del business

Modello del dominio di business

i r r...

Ing. dei requisiti Modello dei casi d’uso 8/1—15/1 r r r...

Specifica supplementare i r r r...

Glossario i r r r...

Visione i r r r...

Diagrammi di sequenza di sistema e contratti delle operazioni

i r r...

Ing. progettazione

Modello delle classi di progetto

i r... r r r...

Architettura i r r...

Modello dei dati i r... r r r...

Codice

Gestione….

Caso POS NextGen• Un POS (Point Of Sale) richiede lo sviluppo di software utilizzato tra

l’altro per registrare vendite ed i pagamenti, in negozi e supermercati. Comprende componenti hardware, e software. Alcune funzionalità di servizio, ad esempio il calcolo delle imposte, sviluppate da terzi, e l’inventario devono interagire con il POS. Il software POS deve essere relativamente tollerante ai guasti: ad esempio, se alcune funzionalità di servizio non sono funzionanti, il software deve comunque permettere di registrare i pagamenti in modo che l’attività non si fermi.

• Il software POS deve essere in grado di usare terminali diversi ed interfacce diverse, browser, PDA, touch screen, interfacce dedicate.

• Poiché il software verrà venduto a diversi clienti, è necessario pensare al grado di personalizzazione.

UP e Casi d’uso• In UP i casi d’uso costituiscono la guida principale: si dice

infatti UP che è “use case driven”• Ciò implica che:

– I requisiti funzionali dovrebbero essere descritti principalmente con casi d’uso

– I casi d’uso sono usati per la pianificazione delle iterazioni (incluse anche le stime)

– La progettazione è poi basata sui casi d’uso da realizzare– I manuali utente sono influenzati dai casi d’uso– I test di sistema e di accettazione sono influenzati dai casi d’uso – I casi d’uso possono influenzare la visione (cioè i casi d’uso possono

essere scritti per definire meglio la visione)

Casi d’Uso e Ideazione• I casi d’uso sono interessanti descrizioni di scenari d’uso del sistema

(software)• I casi d’uso possono nella fase d’ideazione essere sviluppati secondo tre

gradi:– Breve– Informale– Dettagliato

• UP consiglia di concentrarsi nella ideazione sullo sviluppo dettagliato di circa il 10% dei casi maggiormente significativi per la riuscita del progetto

• I casi d’uso possono essere quindi organizzati come diagramma (UML) ma il diagramma è solo una visualizzazione parziale e, da solo, non serve a niente!! I casi d’uso sono principalmente rappresentati con testo strutturato (template)

Rappresentazione dei casi d’uso (UML)

• Template (funzione anche dello strumento CASE)

• Diagramma dei casi d’uso (UML)

• Un esempio:– Elabora vendite

• Breve

• Dettagliato

Scrivere i Casi d’Uso nella Ideazione ed Elaborazione

• Stile essenziale e conciso (per non eliminare a priori eventuali alternative, che costituiscono soluzioni migliori): ignorare le interfacce, concentrarsi sullo scopo dell’attore; evitare stile troppo concreto nella ideazione e nelle iterazioni iniziali di elaborazione

• Scrivere il caso d’uso a “scatola nera”: indicare solo cosa fa il sistema (software) senza indicare come verrà fatto (il più possibile)

• Concentrarsi sul risultato d’interesse che il caso d’uso deve produrre per l’attore principale

• Scegliere se usare una o due colonne• Scegliere il formato: breve, informale, dettagliato

Identificare i Casi d’Uso (Ideazione ed Elaborazione)

• Identificare gli attori primari ed i loro obiettivi; gli attori primari sono sempre esterni al sistema, quindi aiutano a stabilire i confini di cosa è parte del software da sviluppare e cosa rimane esterno

• Definire e rappresentare con UML (diagramma del caso d’uso/diagramma d’attività) i casi d’uso che soddisfano gli obiettivi degli attori primari– Usare check-list per identificare altri attori primari (pag. 89)

• Verificare l’utilità dei casi d’uso identificati:– Chiedere ad altri– Valutare se si tratta di un “processo elementare di business”– Valutare le “dimensioni”

Fig. 6.2

Goal: Process sales

Cashier

Customer

POS System

Checkout Service

Goal: Buy items

Enterprise Selling Things

Sales TaxAgency

Goal: Collect taxes on sales Sales Activity

System

Goal: Analyze sales and performance data

Fig. 6.3NextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation for a computer system actor

«actor»HR System

Cash In

«actor»Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

Elabora Vendite

Fig. 6.4

NextGen

Process Sale

. . .Cashier

Show computer system actors with an alternate notation to human actors.

primary actors on the left

supporting actors on the right

For a use case context diagram, limit the use cases to user-goal level use cases.

«actor»Payment

AuthorizationService

Casi d’uso e Iterazione ed Incrementalità

• Iterazione: scegliere i casi da descrivere in forma dettagliata e realizzarli in codice; la realizzazione in codice indicherà il feedback

• Incrementalità (o raffinamento): incrementare la descrizione (breve ovvero informale) con una descrizione dettagliata; approfondire eventualmente sezioni del template.

• Incrementalità: aggiungere casi d’uso (tipicamente solo nella ideazione)

Casi d’Uso nella Ideazione di NextGen

Dettagliato Informale Breve

Elabora Vendite

Gestisci Restituzione

Analizzare dati sulle vendite

Gestire sicurezza

Gestisci utenti

Cash in

Cash out

Avviare il sistema

Arrestare il sistema

Riassunto (Iterazione nella Ideazione)

• Pag. 133

Obiettivi dell’Elaborazione

• Sulle iterazioni:– Iterazioni guidate dal rischio, brevi e con durata fissata– Iniziare la programmazione (non di un prototipo ma del

vero e proprio software), presto– Frequente test

• Nelle iterazioni:– Scoperta (dedotta, trovata) la maggior parte dei

requisiti (quelli più rischiosi), rappresentati da casi d’uso dettagliati

– Definire la corrispondente architettura del software– Definire le azioni correttive del rischio (di ogni tipo)– Stime approfondite

Elaborazione ed Elaborati

• Ancora casi d’uso (raffinati)• Modello del dominio• Diagrammi di sequenza di sistema e contratti delle

operazioni• Modello delle classi di progetto• Architettura del software• Modello dei dati• Descrizione dell’interfaccia utente: navigabilità,

usabilità etc.

Elaborazione: Iterazione 1

Obiettivi della Iterazione 1• Realizzare una prima versione del modello delle

classi del dominio di business• Implementare il seguente scenario del caso d’uso

Elabora Vendite: inserire gli articoli e ricevere un pagamento in contanti

• Implementare un caso d’uso Avviare il sistema necessario per le esigenze di inizializzazione

• Non si considerano “requisiti complessi” come articolare regole di business e connessioni ad altri sistemi (software) esterni

UML e UP (II)

Ideazione Elaborazione Costruzione Transizione

Modello di business

Classi del dominio di business

Modello analitico (non definito in UP)

Casi d’uso Casi d’uso raffinati, diagrammi di sequenza di sistema

Modello di progetto

Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati

Codice

Forza una visione “black box” del sistema (software) anche se ciò è discutibile nella filosofia object-oriented ove le classi (corrette) sono la principale giustificazione della maggiore qualità

r

Raffinamento r

Modello del Dominio in UP

• Usare il diagramma UML delle classi per esprimere il modello del dominio

• Diagramma delle classi del dominio del business:– Diagramma delle classi tipicamente privato

delle operazioni e di altre caratteristiche delle classi di progetto

– Ogni classe dovrebbe essere definita in modo che il diagramma costituisca un’organizzazione per il glossario dei termini

Posizione in UP del modello del dominio

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Posizione del modello di dominio

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

UP Design ModelThe object-oriented developer has taken inspiration from the real world domainin creating software classes.

Therefore, the representational gap between how stakeholders conceive thedomain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Modelis a concept, but a Payment inthe Design Model is a softwareclass. They are not the samething, but the former inspired thenaming and definition of thelatter.

This reduces the representationalgap.

This is one of the big ideas inobject technology.

inspiresobjects

andnames in

Costruire il modello del dominio I

1. Trovare le classi• Usare categorie di classi (Pag. 149)• Usare i nomi e le frasi nominali (pag.150)• Usare pattern di analisi (non trattati da Larman)

2. Trovare le associazioni • Usare categorie di associazioni comuni• Caratterizzare i ruoli attraverso la cardinalità e verso di

lettura o navigabilità)

3. Trovare gli attributi• Caratterizzare il tipo di attributo, derivato o non derivato• Caratterizzare tipo di dato

4. Introdurre classi per tipo di dato specializzato

Patterns di Analisi

Problem:

How do you keep track of resource quotations performed before its actual trade?

Classi descrittiveItem

descriptionpriceserial numberitemID

ProductDescription

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *

POS NextGen: classi del dominio

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Attributi derivati

Sale

dateTime/ total : Money

attributes

derived attribute

Attributi usati come riferimenti

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "data type" attribute

1 1

Attributi e Tipo di Dato

OK

OK

ProductDescription

ProductDescription

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCodecountryCode

Address

street1street2cityName...

ProductID

pID: ProductID

Attributi e Tipo di Dato

Payment

amount : Number

Payment Quantity

amount : Number

Unit

...

Payment

amount : Quantity

Has-amount1*

Is-in1*

not useful

quantities are pure data values, so are suitable to show in attribute section better

Payment

amount : Money

variation: Money is a specialized Quantity whose unit is a currency

Costruire il modello del dominio II

1. Verificare le classi introdotte

• Alternativa classi/attributi

• Classi descrittive

2. Verificare gli attributi

• Non introdurre attributi usati principalmente per riferirsi ad altre classi; piuttosto usare associazioni

3. Verificare le associazioni

• Verificare l’indipendenza di associazioni diverse coinvolgenti le stesse classi

Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

ProductDescription

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

Modello (parziale) del dominio, POS NextGen

Modello (parziale) del dominio, POS NextGen

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

productID

Diagramma di sequenza di sistema

• Sono parte della specializzazione di UP usata nel testo• Indica un uso specializzato di un diagramma UML (il

diagramma di sequenza)• Serve per trovare le operazioni (messaggi) cui il

sistema software dovrebbe rispondere (molto simile al DFD di contesto ma qui il diagramma di sequenza indica con precisione quando certe operazioni hanno luogo ed in quale scenario ovvero caso d’uso)

• Le operazioni possono essere usate per valutare ad esempio i function points

Posizione in UP e forma di un SSD

1: m ()

: SystemUser

Un caso d’uso

uno scenario

Dovrebbe chiarire cosa fa il sistema e cosa fa il resto

Operazione di sistema

Un SSD

POS NextGen, lo scenario di elabora vendite

: Cashier :System

Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated.6. Cashier tells Customer the total, and asks for payment.7. Customer pays and System handles payment....

enterItem(itemID, quantity)

endSale

makePayment(amount)

description, total

total with taxes

change due, receipt

makeNewSale

[ more items ]loop

Process Sale Scenario

Contratto di un’operazione di sistema

• Nome operazione• Riferimenti al (ai) caso d’uso• Pre-condizioni: espresse con i nomi indicati nel

glossario ovvero nel modello del dominio• Post-condizioni: espresse con i nomi indicati nel

glossario ovvero nel modello del dominio ed in particolare indicano quali oggetti sono stati creati o distrutti, quali valori di attributi sono cambiati, quali link sono stati creati

POS NextGen, uno scenario di elabora vendite

: Cashier

enterItem(itemID, quantity)

endSale()

makePayment(amount)

description, total

total with taxes

change due, receipt

makeNewSale()

these input system events invoke system operations

the system event enterItem invokes a system operation called enterItem and so forth

this is the same as in object-oriented programming when we say the message foo invokes the method (handling operation) foo

[ more items ]loop

:System

Process Sale Scenario

Un Contratto I

• Contratto CO1: makeNewSale• Operazione: makeNewSale()• Riferimenti: Elabora Vendite• Precondizioni: nessuna• Post condizioni:

– è stata creata un’istanza s di Sale– s è stata associata a Register– gli attributi di s sono stati inizializzati

Un Contratto (II)• Contratto CO2: enterItem• Operazione: enterItem(itemID:ItemID, quantity:integer)• Riferimenti: Elabora Vendite• Precondizioni: è in corso una vendita• Post condizioni:

– è stata creata un’istanza sli di SaleLineItem– sli è stata associata alla Sale corrente– sli.quantity è divenuta quantity– sli è associata alla corrispondente ProductDescription usando

itemID

Un Contratto (III)

• Contratto CO3: endSale()

• Operazione: endSale()

• Riferimenti: Elabora Vendite

• Precondizioni: è in corso una vendita

• Post condizioni: – sale.isComplete è diventato vero

Relazione Contratti – Modello del dominio

Modello del dominio

Pre – post condizioni

Usato per esprimere

Contratto

Parte diUsato per incrementare

Sale

dateTimeisComplete : :Boolean

Attributo aggiunto

Creare e scrivere i contratti

• Creare un contratto per singola operazione parte di un SSD

• Descrivere le post-condizioni usando, ad esempio tre tipi di “operazioni concettuali”:– Creare o distruggere un oggetto– Modificare il valore di un attributo di un

oggetto– Creare o distruggere un’associazione

Creare e scrivere i contratti• I contratti devono essere scritti per tutte le

operazioni trovate attraverso gli SSD?– Non necessario!

• Nuovi classi, attributi, associazioni possono essere aggiunti al modello del dominio (tipico dei metodi iterativi ed incrementali)– Ed è necessario!

• Le post-condizioni devono, in ogni momento, essere il più complete possibili?– Non necessario ma con attenzione!

Ispirati a Iterazione e Incrementalità di UP

Transizione al progetto nella Iterazione 1: Elaborati

• Definizione dell’architettura del software (prima versione), ed in particolare:– La struttura ovvero organizzazione completa del

software

• Definizione di diagrammi di sequenza e di diagrammi di comunicazione di progetto– Responsabilità degli oggetti: quali oggetti fanno che

cosa!

• Definizione del diagramma delle classi di progetto– Ereditarietà!

Transizione al progetto: legami tra elaborati

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

starting events to design for, and more detailed requirements that must be satisfied by the software

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier.

the domain objects, attributes, and associations that undergo changes

requirements that must be satisfied by the software

ideas for the post-conditions

Modello di progetto

Stili e pattern architetturali

Design patterns

: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec ( itemID )

Require -ments

Business Modeling

Design

UP Artifact Relationships from Requirements/Business to Design

Vision Glossary

The logical architecture is influenced by the constraints and non -functional requirements captured in the Supp . Spec .

Domain Model

**

SupplementarySpecification

Use-Case Model and SSDs

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductSpec(...)...

1 1class diagrams(a static view )

interaction diagrams(a dynamic view )

UIpackage diagramsof the logical architecture(a static view ) Domain

Tech Services

Design Model

Dipendenze tra package

Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

Package: alternative di rappresentazione

Domain::Sales

UI::WebUI::Swing

Sales

WebSwing

UI

Domain

DomainUI

Swing SalesWeb

Pattern LayerUI

(AKA Presentation, View)

Application(AKA Workflow, Process,Mediation, App Controller)

Domain(AKA Business,

Application Logic, Model)

Technical Services(AKA Technical Infrastructure, High-level Technical Services)

Foundation(AKA Core Services, Base Services,

Low-level Technical Services/Infrastructure)

width implies range of applicability

GUI windowsreportsspeech interfaceHTML, XML, XSLT, JSP, Javascript, ...

handles presentation layer requestsworkflowsession statewindow/page transitionsconsolidation/transformation of disparate data for presentation

handles application layer requestsimplementation of domain rulesdomain services (POS, Inventory)- services may be used by just one application, but there is also the possibility of multi-application services

(relatively) high-level technical services and frameworks Persistence, Security

low-level technical services, utilities, and frameworksdata structures, threads, math, file, DB, and network I/O

moreapp

specific

de

pe

nde

ncy

Business Infrastructure(AKA Low-level Business Services)

very general low-level business services used in many business domainsCurrencyConverter

Layers, Partitions

Persistence Security Logging

Technical Services

POS Inventory Tax

Domain

Vertical Layers

Horizontal Partitions

Operazioni di sistema ed architettura a layer

Domain

UI

Swing

ProcessSaleFrame

...

... Register

makeNewSale()enterItem()...

: Cashier

makeNewSale()enterItem()endSale()

makeNewSale()enterItem()endSale()

enterItem(id, quantity)

:System: Cashier

endSale()

description, total

makeNewSale()

the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer

Diagramma di Comunicazione

• Un altro modo di indicare i messaggi che, all’interno di una comunicazione (scenario), vengono scambiati dagli oggetti

• Mentre un diagramma di sequenza indica solo che un oggetto invia (ovvero dovrebbe poter inviare) un messaggio ad un altro, un diagramma di comunicazione indica, di fatto, se ciò può avvenire

Notazione base di un diagramma di comunicazione

: A

myB : B

1: doTwo

2: doThree

doOne

Diagrammi di sequenza e di comunicazione (I)

: Register : Sale

makePayment(cashTendered)

makePayment(cashTendered)

: Paymentcreate(cashTendered)

Diagrammi di sequenza e di comunicazione (II)

1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register :Sale

:Payment

makePayment(cashTendered)

direction of message

Messaggi e causalità

1: makePayment(cashTendered)2: foo

2.1: bar: Register :Sale

link line

Link e messaggi

1: msg22: msg33: msg4

3.1: msg5: Register :Sale

all messages flow on the same link

msg1

Messaggi intra-oggetto

: Register

msg1

1: clear

Creazione di oggetti dei diagrammi di comunicazione

1: create(cashier)

: Register :Sale

create message, with optional initializing parameters. This will normally be interpreted as a constructor call.

«create»1: make(cashier)

: Register :Sale

if an unobvious creation message name is used, the message may be stereotyped for clarity

1: create(cashier)

: Register :Sale {new}

Three ways to show creation in a communication diagram

Leggere un diagramma di comunicazione

: Amsg1 : B1: msg2

: C

1.1: msg3

2.1: msg5

2: msg4

: D

2.2: msg6

first second

fourth

sixth

fifth

third

Messaggi condizionali

1 [ color = red ] : calculate: Foo : Bar

message1

conditional message, with test

Messaggi condizionali e mutua esclusione

1a [test1] : msg2

: A : B

: C

1a.1: msg3

msg1

: D

1b [not test1] : msg4

1b.1: msg5

: E

2: msg6

unconditional after either msg2 or msg4 1a and 1b are mutually

exclusive conditional paths

Interazione di messaggi

1 * [ i = 1..n ]: num = nextInt: SimulatorrunSimulation : Random

iteration is indicated with a * and an optional iteration clause following the sequence number

Lo scenario principale di Elabora Vendite: esempio di iterazione di messaggi

1 * [i = 1..n]: st = getSubtotal: Salet = getTotal

This lifeline box represents one instance from a collection of many SalesLineItem objects.

lineItems[i] is the expression to select one element from the collection of many SalesLineItems; the ‘i” value comes from the message clause.

lineItems[i]:SalesLineItem

this iteration and recurrence clause indicates we are looping across each element of the lineItems collection.

1 *: st = getSubtotal: Salet = getTotal lineItems[i]:SalesLineItem

Less precise, but usually good enough to imply iteration across the collection members