Ingegneria del Software

(1)

Ingegneria del Software

Esempi di Progettazione a oggetti con i pattern GRASP

Prof. Orazio Tomarchio

O. Tomarchio Ingegneria del Software 2

Cosa vedremo in questa lezione

Obiettivi



Progettare realizzazione di casi d'uso



Applicare i pattern GRASP per assegnare le responsabilità alle classi



Applicare UML per illustrare e pensare durante la progettazione degli ogget

Il tutto facendo riferimento ai casi di studio

(2)

Progettazione OO con pattern GRASP



Realizzazione di un caso d’uso

Definizione:



Descrive come viene realizzato un caso d’uso all’interno del Modello di Progetto in termini di ogget che collaborano



In realtà una realizzazione di caso d’uso è relativa ad uno solo dei possibili scenari di caso d’uso



Sarebbe più corretto parlare di realizzazione di scenario di caso d’uso (ma non è una espressione usata nella pratica)

Progettazione OO: relazioni tra gli elaborati

Operation:

enterItem(…) Postconditions:

. . . Operation Contracts

Sale date. . .

Sales LineItem quantity 1..*

1 . . .

. . . Domain Model

UseCase Model

Design Model : Register

enterItem (itemID, quantity)

: ProductCatalog

d = getProductDescription(itemID) addLineItem( d, quantity )

: Sale Require

ments Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem (id, quantity) Use Case Text

System Sequence Diagrams make NewSale()

system events

Cashier Process

Sale

: Cashier use case names

system operations Use Case Diagram

Supplementary Specification

Glossary

starting events to design for, and detailed post

condition to satisfy

Process Sale 1. Customer arrives ...

2. ...

3. Cashier enters item identifier.

inspiration for names of some software domain objects

functional requirements that must be realized by the objects ideas for

the post

conditions

Register ...

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

ProductCatalog ...

getProductDescription(...) ...

* 1

nonfunctional requirements domain rules

item details, formats, validation

(3)

Progettazione OO: relazioni tra gli elaborati



I casi d’uso suggeriscono le operazioni di sistema (SSD)



Le operazioni di sistema diventano i messaggi iniziali entranti nel Controller per i diagrammi di interazione



I diagrammi di interazione illustrano come gli ogget collaborano per realizzare i casi d’uso



Punti di attenzione:



Il Modello di dominio e gli elaborati del modello dei casi d’uso sono un input impreciso e incompleto per la progettazione



Si può progettare a partire da casi d’uso e SSD e opzionalmente dai contrat delle operazioni

Studio di caso: POS

Realizzazione del caso d'uso Process Sale

(4)

POS (modello di dominio)

Register id

Store Item nameaddress

Sale dateTime / total

CashPayment amountTendered

Sales LineItem quantity

Cashier id Customer

Product Catalog

Product Description itemID description price

Stocks

*

Houses 1..*

Usedby

*

Contains 1..*

Describes

*

Capturedon Containedin

1..*

Recordssaleof

0..1

Paidby Isfor

Logs

completed

*

 Workson 1 1

1

1 1..*

1 1

1

1 1

0..1 1

1 Ledger

Records

accounts

for 1

1

Linee guida:

inizializzazione e caso d'uso di avviamento



Mentre si codifica



Si programmi prima almeno una parte delle inizializzazioni per l'avviamento



Ma, durante la modellazione della progettazione OO



Si consideri la progettazione delle inizializzazioni per l'avviamento alla fine



Dopo aver scoperto cosa va realmente creato e inizializzato



Progetamo quindi l'inizializzazione a supporto delle

necessità di altre realizzazione di caso d'uso

(5)

POS (1)

Progettazione di makeNewSale



Scelta del controller.

Per il Pattern Controller si hanno le scelte:

 Facade Controller

 Store (oggetto radice)

 Register (un dispositivo fisico su cui gira il sw)

 POSSystem (rappresenta il sistema complessivo)

 Controller di caso d’uso

 ProcessSaleHandler o ProcessSaleSession



Dato che le operazioni sono poche la scelta ricade su uno dei Facade Controller quindi

 Si introduce la classe software Register



Scelta di chi crea una Sale (vendita)

 Dall’analisi del Modello di dominio si vede che Register registra istanze di Sale quindi:

 Per LRG si introduce la classe software Sale

 Per il Pattern Creator è Register che può creare Sale

 Deve essere creata una collezione vuota che conterrà i SalesLineItem

 La collezione sarà mantenuta da Sale quindi per Creator Sale è un buon candidato per creare la collezione

POS (2)



Progettazione di makeNewSale (diagramma di sequenza)

(6)

POS (3)

Progettazione di enterItem



Scelta del controller (Pattern Controller)

 Si usa Register (Facade Controller)



Scelta di chi crea una SalesLineItem

 Dall’analisi del Modello di Dominio si vede che Sale contiene SalesLineItem quindi

Per LRG si introduce la classe sw SalesLineItem (Sale già esiste)

Per Creator Sale crea SalesLineItem



Scelta di chi ricerca una ProductDescription a partire da un itemID (Pattern Expert)

 Dall’analisi del Modello di Dominio si vede che ProductCatalog contiene tutte le ProductDescription quindi

Per LRG si introducono le classi software ProductCatalog e ProductDescription

L’Expert è ProductCatalog. A questo si aggiunge il metodo getProductDescription(id)



Register deve poter chiamare il metodo getProductDescription

 Deve avere Visibilità di ProductCatalog quindi:

Si aggiunge a Register una associazione con ProductCatalog

POS (4.1)

2: makeLineItem(desc, qty) enterItem(id, qty)

1: desc = getProductDesc(id) 2.1: create(desc, qty)

1.1: desc = get(id)

:Register :Sale

:Product Catalog

sl: SalesLineItem

lineItems : List<SalesLineItem>

: Map<ProductDescription>

2.2: add(sl) by Expert

by Controller by Creator

Aggiunge SalesLineItem alla lista

Diagramma di comunicazione

(7)

POS (4.2)

SalesLineItem quantity : Integer ...

ProductCatalog ...

getProductDesc(...)

ProductDescription description : Text price : Money itemID: ItemID ...

1..*

1..* Register

...

enterItem(...) ...

Sale isComplete : Boolean time : DateTime makeLineItem(...) 1 ...

1

1 catalog

currentSale

descriptions {Map}

lineItems {ordered}

description

Diagramma delle classi di progetto (DCD) - (parziale)

POS (5)

Progettazione di endSale



Scelta del controller (Pattern Controller)



Scelta di chi assegna true a Sale.isComplete (Pattern Expert)

 Dall’analisi del Modello di Dominio si vede che isComplete è mantenuto da Sale

 Per Expert è Sale che deve modificare isComplete quindi si aggiunge a Sale il metodo becomeComplete



Scelta di chi calcola il totale della vendita

 Dall’analisi del Modello di Dominio si vede che Sale contiene SalesLineItem quindi:

 Per Expert è Sale che deve restituire il totale quindi si aggiunge getTotal a Sale



Scelta di chi calcola il subtotale (totale di una SalesLineItem)

 Per il calcolo del subtotale è necessario conoscere SalesLineItem.quantity e ProductDescription.price

 Dall’analisi del Modello di Dominio si vede che SalesLineItem ha come attributo quantity ed è associato a ProductDescription

 Per Expert è SalesLineItem che deve restituire il subtotale quindi si aggiunge il metodo getSubtotal

(8)

POS (6)

:Register

endSale( 1: becomeComplete s :Sale

by Expert by Controller

:Sale

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

:ProductDescription 1.1: pr = getPrice lineItems[ i ]:

SalesLineItem

by Expert by Expert UML: note the selector

notation to select elements from the lineItems collection

POS (7)

Progettazione di makePayment



Scelta del controller (Pattern Controller)



Scelta di chi crea una Payment

 Dall’analisi del Modello di Dominio si vede che Register registra e Sale utilizza strettamente Payment

 2 candidati: Register e Sale. Si valutano le alternative con Low Coupling e High Coesion

 Per Low Coupling la scelta è Sale



Scelta di chi registra le vendite completate

 Dall’analisi del Modello di Dominio si vede che può essere la classe Ledger



Scelta di chi è il responsabile di conoscere il resto

 Per calcolare il resto è necessario conoscere il totale della vendita e l’importo in contanti

 Gli Expert parziali sono Sale e Payment

 2 alternative: Payment responsabile principale e Sale secondario o viceversa. Si valutano le alternative con Low Coupling e High Coesion

 Per Low Coupling la scelta è: Sale responsabile principale e Payment secondario (Sale è già accoppiato a Payment perchè lo crea)

(9)

POS (8)

POS (9)

DCD finale per l'iterazione 1

SalesLineItem quantity : Integer getSubtotal() ProductCatalog

...

getProductDesc(...)

ProductDescription description : Text price : Money itemID: ItemID ...

Store address : Address name : Text addCompleteSale(...)

Payment amount : Money ...

1..*

Register ...

endSale() enterItem(...) makeNewSale() makePayment(...)

Sale isComplete : Boolean time : DateTime becomeComplete() makeLineItem(...) makePayment(...) getTotal() 1

1

*

catalog

register

currentSale

descriptions {Map}

lineItems {ordered}

payment completedSales

{ordered}

description

(10)

POS (10)



Connessione dello strato UI allo strato di dominio

:Register Cashier

:ProcessSale JFrame

actionPerformed( actionEvent )

1: enterItem(id, qty) system event UI

Layer

Domain Layer

presses button

Nel Main si effettuano i seguenti step

● si crea l’oggetto UI

● si crea il Facade Controller Register

● si rende visibile Register all’oggetto UI

● Successivamente ogni azione sull’UI viene trasformata in una chiamata a Register

POS (11)



Caso d’uso di avviamento



StartUp del sistema e creazione dell’oggetto di dominio iniziale



Un oggetto radice rispetto alla gerarchia di contenimento

(11)

Esercizio

