sperimentazioni di ingegneria del software g.berio v. bono 2008
TRANSCRIPT
![Page 1: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/1.jpg)
Sperimentazioni di Ingegneria del Software
G.Berio
V. Bono
2008
![Page 2: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/2.jpg)
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
![Page 3: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/3.jpg)
Pre-requisiti
• I medesimi di Ingegneria del Software (logica, basi dati etc.)
• Conoscere il contenuto del corso di Ingegneria del Software
![Page 4: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/4.jpg)
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
![Page 5: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/5.jpg)
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)
![Page 7: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/7.jpg)
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
![Page 8: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/8.jpg)
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
![Page 9: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/9.jpg)
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)
![Page 10: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/10.jpg)
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à)
![Page 11: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/11.jpg)
Gestione della Ingegneria del Software
• Qualità del processo
• Stime sulla bontà del processo di sviluppo
• Project management, pianificazione dei compiti (o attività)
![Page 12: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/12.jpg)
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
![Page 13: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/13.jpg)
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
![Page 14: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/14.jpg)
Processo iterativo
• Small steps (timeboxed), feedback and refinement
Iteration1
DesignCode, Test,
IntegrateAnalyze
...Iteration
2
DesignAnalyzeCode, Test,
Integrate
2 weeks 2 weeks
![Page 15: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/15.jpg)
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
![Page 16: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/16.jpg)
Processo evolutivo
Communication
Quick plan
Construction of prototype
Modeling Quick design
Delivery & Feedback
Deployment
Communication
Quickplan
ModelingQuick design
Constructionof prototype
Deploymentdelivery &feedback
![Page 17: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/17.jpg)
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
![Page 18: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/18.jpg)
Unified Process• Attenzione: le fasi non sono (necessariamente)
iterazioni.
Attività generiche (Larman ed UP le chiamano Discipline)
![Page 19: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/19.jpg)
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
![Page 20: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/20.jpg)
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
![Page 21: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/21.jpg)
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)
![Page 22: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/22.jpg)
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
![Page 23: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/23.jpg)
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
![Page 24: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/24.jpg)
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
![Page 25: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/25.jpg)
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
![Page 26: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/26.jpg)
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. ...
![Page 27: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/27.jpg)
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
![Page 28: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/28.jpg)
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)
![Page 29: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/29.jpg)
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….
![Page 30: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/30.jpg)
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.
![Page 31: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/31.jpg)
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)
![Page 32: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/32.jpg)
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)
![Page 33: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/33.jpg)
Rappresentazione dei casi d’uso (UML)
• Template (funzione anche dello strumento CASE)
• Diagramma dei casi d’uso (UML)
• Un esempio:– Elabora vendite
• Breve
• Dettagliato
![Page 34: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/34.jpg)
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
![Page 35: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/35.jpg)
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”
![Page 36: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/36.jpg)
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
![Page 37: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/37.jpg)
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
![Page 38: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/38.jpg)
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
![Page 39: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/39.jpg)
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)
![Page 40: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/40.jpg)
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
![Page 41: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/41.jpg)
Riassunto (Iterazione nella Ideazione)
• Pag. 133
![Page 42: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/42.jpg)
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
![Page 43: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/43.jpg)
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.
![Page 44: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/44.jpg)
Elaborazione: Iterazione 1
![Page 45: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/45.jpg)
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
![Page 46: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/46.jpg)
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
![Page 47: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/47.jpg)
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
![Page 48: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/48.jpg)
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. ...
![Page 49: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/49.jpg)
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
![Page 50: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/50.jpg)
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
![Page 51: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/51.jpg)
Patterns di Analisi
Problem:
How do you keep track of resource quotations performed before its actual trade?
![Page 52: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/52.jpg)
Classi descrittiveItem
descriptionpriceserial numberitemID
ProductDescription
descriptionpriceitemID
Item
serial number
Describes Better
Worse
1 *
![Page 53: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/53.jpg)
POS NextGen: classi del dominio
StoreRegister SaleItem
CashPayment
SalesLineItem
Cashier Customer
ProductCatalog
ProductDescription
Ledger
![Page 54: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/54.jpg)
Attributi derivati
Sale
dateTime/ total : Money
attributes
derived attribute
![Page 55: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/55.jpg)
Attributi usati come riferimenti
Cashier
namecurrentRegister
Cashier
name
Register
number
Uses
Worse
Better
not a "data type" attribute
1 1
![Page 56: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/56.jpg)
Attributi e Tipo di Dato
OK
OK
ProductDescription
ProductDescription
itemId : ItemID
1Store
Store
address : Address
11 1
ItemID
idmanufacturerCodecountryCode
Address
street1street2cityName...
ProductID
pID: ProductID
![Page 57: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/57.jpg)
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
![Page 58: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/58.jpg)
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
![Page 59: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/59.jpg)
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
![Page 60: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/60.jpg)
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
![Page 61: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/61.jpg)
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
![Page 62: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/62.jpg)
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
![Page 63: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/63.jpg)
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
![Page 64: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/64.jpg)
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
![Page 65: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/65.jpg)
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
![Page 66: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/66.jpg)
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
![Page 67: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/67.jpg)
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
![Page 68: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/68.jpg)
Un Contratto (III)
• Contratto CO3: endSale()
• Operazione: endSale()
• Riferimenti: Elabora Vendite
• Precondizioni: è in corso una vendita
• Post condizioni: – sale.isComplete è diventato vero
![Page 69: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/69.jpg)
Relazione Contratti – Modello del dominio
Modello del dominio
Pre – post condizioni
Usato per esprimere
Contratto
Parte diUsato per incrementare
Sale
dateTimeisComplete : :Boolean
Attributo aggiunto
![Page 70: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/70.jpg)
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
![Page 71: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/71.jpg)
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
![Page 72: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/72.jpg)
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à!
![Page 73: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/73.jpg)
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
![Page 74: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/74.jpg)
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
![Page 75: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/75.jpg)
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
![Page 76: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/76.jpg)
Package: alternative di rappresentazione
Domain::Sales
UI::WebUI::Swing
Sales
WebSwing
UI
Domain
DomainUI
Swing SalesWeb
![Page 77: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/77.jpg)
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
![Page 78: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/78.jpg)
Layers, Partitions
Persistence Security Logging
Technical Services
POS Inventory Tax
Domain
Vertical Layers
Horizontal Partitions
![Page 79: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/79.jpg)
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
![Page 80: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/80.jpg)
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
![Page 81: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/81.jpg)
Notazione base di un diagramma di comunicazione
: A
myB : B
1: doTwo
2: doThree
doOne
![Page 82: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/82.jpg)
Diagrammi di sequenza e di comunicazione (I)
: Register : Sale
makePayment(cashTendered)
makePayment(cashTendered)
: Paymentcreate(cashTendered)
![Page 83: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/83.jpg)
Diagrammi di sequenza e di comunicazione (II)
1: makePayment(cashTendered)
1.1: create(cashTendered)
:Register :Sale
:Payment
makePayment(cashTendered)
direction of message
![Page 84: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/84.jpg)
Messaggi e causalità
1: makePayment(cashTendered)2: foo
2.1: bar: Register :Sale
link line
![Page 85: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/85.jpg)
Link e messaggi
1: msg22: msg33: msg4
3.1: msg5: Register :Sale
all messages flow on the same link
msg1
![Page 86: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/86.jpg)
Messaggi intra-oggetto
: Register
msg1
1: clear
![Page 87: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/87.jpg)
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
![Page 88: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/88.jpg)
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
![Page 89: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/89.jpg)
Messaggi condizionali
1 [ color = red ] : calculate: Foo : Bar
message1
conditional message, with test
![Page 90: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/90.jpg)
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
![Page 91: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/91.jpg)
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
![Page 92: Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008](https://reader035.vdocuments.pub/reader035/viewer/2022070313/5542eb6a497959361e8d69a4/html5/thumbnails/92.jpg)
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