Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008.
-
Upload
biagino-ferretti -
Category
Documents
-
view
217 -
download
2
Transcript of Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008.
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)
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