Static Modeling
In COMET
Corso di Ingegneria del Software II
Sonia Pini
Static modeling: Cos’è
Considera gli aspetti strutturali statici del
problema.
Definisce le classi di oggetti nel sistema,
con attributi, operazioni e relazioni tra classi
Static Modeling in COMET
E’ la prima attività dell’Analysis Modeling
Lo scopo dell’Analysis Modeling è quello di capire il
problema, e quindi identificare gli oggetti del dominio del
problema e le informazioni passate tra tali oggetti.
Definisce il modello statico per le
specifiche del problema.
Utilizza la notazione UML per i Class
Diagrams.
Indice argomenti.
Preliminari tecnici (UML) per lo Static
Modeling.
Metodo COMET per lo Static Modeling.
indice
Preliminari tecnici.
Nel dettaglio analizzeremo:
Relazioni tra classi:
 Associazioni
 Composizioni e Aggregazioni
 Generalizzazioni/Specializzazioni
Vincoli
indice
Preliminari tecnici: Associazioni
Per le associazioni daremo:
Definizione di Associazione con alcuni
esempi.
Definizione di Link Attributes.
Definizione di Association Classes.
indice
Associazioni.
Una associazione è una relazione tra 2 o più
classi, che denota una qualche relazione
strutturale tra le classi.
Esempio.
Employee works in Department
Esistono convenzioni per la descrizione
delle associazioni nei class diagram.
indice
Associazioni: esempio
<<entity>>
Company
<<entity>>
Company
name:String
address:String
businessSector:String
name:String
address:String
businessSector:String
1
..*1
Has
1
<<entity>>
President
name:String
SSN:String
address:String
phoneNumber:Integer
Molteplicita` dell’associazione.
Manages
1..*
<<entity>>
President
name:String
SSN:String
address:String
phoneNumber:Integer
indice
Associazioni: esempio.
<<entity>>
Car
modelName:String
manufacture:String
modelYear:Date
1
<<entity>>
Course
courseId: String
courseName: String
Section#: Integer
Semester: String
*
Has
2,4
<<entity>>
Door
heigh: Real
width: Real
depth: Real
windowArea: Real
Material: String
Has
Attends
*
<<entity>>
Student
studentName: String
studentSSN: String
studentAddress: String
studentType: String
indice
Associazioni Ternarie.
Ternaria: e` un’associazione a 3 vie tra classi.
<<entity>>
Buyer
Name:String
Address:String
phoneNumber:String
movingDateTarger:Date
homePriceTaget:Integer
Negotiates
Price
<<entity>>
Agent
name:String
address:String
Company:String
workPhoneNumber:String
homePhoneNumber:String
<<entity>>
Seller
Name:String
Address:String
phoneNumber:String
SelleringPrice:Integer
Indice
Associazioni Unarie.
Unaria: è un’associazione tra un oggetto di
una classe e un altro oggetto della stessa
classe.
Esempio.
Person is-married-to Person
Employee is-boss-of Employee
indice
Associazioni: Link
Un Link è una connessione tra istanze
oggetto.
Rappresenta una istanza di una associazione
tra classi.
Esempio.
Jane works in Manufactuting
indice
Associazioni: Link Attributes
E` possibile per un Link avere degli
attributi.
Tali attributi appartengono alla
associazione.
indice
Associazioni: Link Attributes
<<entity>>
Employee
employeeName: String
employeeSSN: String
employeeAddress: String
Level: String
<<entity>>
Project
*
*
projectId: String
projectName: String
startDate: Date
endDate: Date
Customer: String
hoursWorked: Real
indice
Associazioni: Association Class.
Sono un’alternativa all’uso dei Link
Attributes.
Rappresentano una classe che modella
un’associazione tra 2 o più classi.
I suoi attributi sono attributi
dell’associazione.
indice
Associazioni: Association Class
<<entity>>
Employee
employeeName: String
employeeSSN: String
employeeAddress: String
Level: String
<<entity>>
Project
*
*
projectId: String
projectName: String
startDate: Date
endDate: Date
Customer: String
<<entity>>
Hours
hoursWorked: Real
indice
Composizioni e Aggregazioni.
Entrambe si riferiscono a una classe
costruita su altre classi.
Sono forme speciali di relazioni in cui le
classi sono saldamente legate dalla
relazione Parte/Intero.
La relazione parte/intero, in entrambi I casi,
è una relazione IS PART OF.
indice
Composizioni.
Le parti (oggetti) sono creati, vivono e
muoiono con l’intero.
Le parti di una composizione possono
includere classi e associazioni.
Una classe composta spesso implica una
relazione fisica tra l’intero e le parti.
indice
Composizioni: esempio.
Elevator
Elevator#: Integer
currentFloor#: Integer
Direction: DirectionType
1..*
ElevatorButton
1
1..*
1
ElevatoLamp
Motor
destinationFloor#: Integer destinationFloor#: Integer
Door
indice
Aggregazioni.
L’aggregazione gerarchica è una forma più
debole di relazione parte/intero.
Sono usate per modellare classi concettuali
piuttosto che classi fisiche.
Le istanze delle parti possono venire aggiunte e rimosse
dall’intero.
Una parte può appartenere a più di una aggregazione.
indice
Aggregazioni: esempio
<<aggregate>>
College
Gli attributi
sono
Propagati
dall’intereo alle
parti.
collegeName: String
Dean: String
1
<<entity>>
AdminOffice
Location: String
Phone#: String
Administrator: String
1..*
<<entity>>
|Departement
deptName: String
deptLocation: String
deptPhone#: String
chairPerson: String
Secretary: String
1..*
<<entity>>
ResearchCenter
name: String
location: String
phone#: String
Head: String
foundingDate: Date
renewalDate: Date
indice
Generalizzazioni/Specializzazioni
Sono relazioni tassonomiche tra un elemento più
generale (superclass) e uno più specifico
(subclass).
L’elemento più specifico è completamente compatibile con l’altro
elemento e aggiunge informazioni addizionali.
C’è una relazione IS A tra la subclass e la
superclass.
La subclass eredita proprietà dalla superclass.
indice
Generalizzazioni/Specializzazioni
<<entity>>
Account
accountNumber: Integer
Balance: Real
<<entity>>
CheckingAccount
<<entity>>
SavingAccount
tastDepositAmount: Real
Interest: Real
Generalizzazioni/Specializzazioni
indice
Discriminator.
Un Discriminator è un attributo che indica
quale proprietà dell’oggetto è stata astratta
dalla relazione di generalizzazione.
indice
Generalizzazioni/Specializzazioni
<<entity>>
Account
accountNumber: Integer
Balance: Real
AccountType
<<entity>>
CheckingAccount
<<entity>>
SavingAccount
tastDepositAmount: Real
Interest: Real
indice
Vincoli.
Specificano condizioni che devono essere
vere.
Possono essere espressi attraverso il linguaggio naturale
oppure attraverso il linguaggio fornito da UML, cioè
OCL(Object Constraint Language)
Alcuni tipi di constraint:
Sugli attributi
 Sulle associazioni

indice
Vincoli e Commenti in UML.
indice
Vincoli: esempio.
<<entity>>
Account
accountNumber: Integer
Balance: Real
{ balance>= 0 }
indice
Vincoli: esempio.
<<entity>>
Account
accountNumber: Integer
Balance: Real
1
Modified by
{ordered by time}
*
<<entity>>
ATMTransaction
transactionId; Integer
cardId: Integer
PIN: String
Date: Date
Time: Time
Status: Integer
indice
Indice argomenti.
Preliminari tecnici (UML) per lo Static
Modeling.
Metodo COMET per lo Static Modeling.
indice
Metodo COMET.
Tratteremo con particolare considerazione:
Descrizione dell’approccio COMET.
Static Modeling del Dominio del Problema.
Static Modeling del System Context.

2 esempi di sviluppo.
Static Modeling delle Entity Classes.
indice
Static Modeling e UML
C’è poco accordo su come applicare lo
Static Modeling, cioè su quale metodo usare
per sviluppare Class Diagrams.
Alcune proposte di sviluppo sono di usare:
Static modeling per modellare le classi.
 Sstatic modeling solo per modellare entity
classes.
 Diversi livelli di static modeling.

Approccio COMET all’uso dello
Static Modeling.
indice
COMET usa un approccio con diversi livelli
di Static Modeling:
Un conceptual Static Model semplice nella
fase di analisi.
Uno Static Modeling piu` dettagliato nella
fase di design.
Static Modeling del dominio del
problema.
indice
Occorre modellare dapprima:
Physical Classes.
Rappresentano classi con caratteristiche fisiche, che
avranno bisogno di una rappresentazione concettuale nel
sistema software.
Entity Classes.
Rappresentano classi con dati persistenti, ad esempio
classi con dati memorizzati in un data-base.
Static Modeling del dominio del
indice
problema: esempio.
1
Bank
1..*
ATM
Mantains
ATM
1
1
1
Cardreader
1 Reads
1
ATMCard
1
Operator
1
CashDispenser
1
Dispenses
1
ATMCash
1
ReceiptPrinterBank
1
1
Receipt
Prints
Terminal
Static Modeling del System
Context.
System Context
E` utilizzato per comprendere l’interfaccia tra il
sistema e l’ambiente esterno.
Nella structured Analysis il System Context
è mostrato da un System Context Diagram.
Può essere rappresentato con:
Static Model.
 Collaboration Model.

indice
indice
System Context Diagram.
Il system context class diagram può essere
determinato attraverso:
Lo static modeling delle classi esterne
connesse al sistema.
L’uso di use cases.
Sviluppo di Context Class
Diagram dalle calssi esterne.
1
<<external
I/O
1..*
device>>
CardReader
Inputs
to
1
Outputs
1 <<external output
to
device>>
ReceiptPrinter
ATM
Customer
indice
1
1..*
Outputs
to
1
1
1
<<system>>
Banking
System
1
Operator
Interacts
with
1
1..* <<external user>>
Operator
<<external
user>> 1..*
Interacts 1
ATMCustomer
with
1
<<external
output
1..*
device>>
CashDispenser
Outputs
to
Static modeling del dominio del problema
per il sistama bancario
Sviluppo di Context Class
Diagram dagli Attori.
Occorre ricavare le classi esterne dagli
attori.
Abbiamo due attori nel caso del Banking
System Context Class Diagram, entrambi
utenti umani.
indice
Static Modeling delle Entity
Classes.
I dati contenuti nelle entity classes sono
memorizzati in modo permanente e acceduti
da use cases.
Sono definite durante lo static modeling del
dominio del probelma.
indice
Static modeling delle Entity
Classes.
1 <<entity>>
Bank
1 <<entity>>
Manteins
1
ATMInfo
Has
1
1..*
0..1
<<entity>>
DebitCard
1..*
Provides
acces to
*
*
<<entity>>
Customer 1,2
Owns
Identifies
1
1..*
Manages
indice
*
Modifies
<<entity>>
ATMTransaction
Owns
1.*
<<entity>>
Account
1..*
<<entity>>
CardAccount
<<entity>>
Checking
Account
<<entitty>>
Saving
Account
<<entity>>
Withdrawal
Transaction
<<entity>>
Query
Transaction
<<entity>>
Transfer
Transaction
<<entity>>
PINValidation
Transaction