Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Summary
COMET Software Life Cycle Model The problem Case study development
25/may/2001
Incremental Sw Construction
Throwaway Prototyping
Incremental Sw Integration
Incremental Prototyping
25/may/2001 Banking System Case Study
System Testing
3
C u s t o m e r
COMET Activities in
Requirements Modeling
The system is considered as a black box. Emphasis is on understanding the problem. Activities: use case modeling
25/may/2001
Static and dynamic models are developed; Static model: structural relationship among model: problem domain classes; classes; Dynamic model: use cases refinement; model: refinement; Collaboration diagram and/or sequence diagram. diagram.
25/may/2001
COMET Activities in
Analysis Modeling
The analysis of the problem domain is considered. Activities: static modeling; object structuring; finite state machines modeling; dynamic modeling.
25/may/2001
The software architecture of the system is designed; Analysis model Design model; System Subsystems; Concurrent/Sequential;
25/may/2001
COMET Activities in
Design Modeling
The solution domain is considered. The analysis model is mapped to a concurrent design model. Activities: develop consolidate object collaboration diagram; decide subsystem structuring; decide about: objs, msgs; develop a detailed sw design.
25/may/2001 Banking System Case Study 9
25/may/2001
10
Integration testing of each sw increment is performed; performed; Integration test cases are developed for each use case; case; The interface between objects are tested. tested.
25/may/2001
11
Functional testing of the system; system; Functional test case are built for each black box use case; case; Any sw increment released to the customer needs to go through this phase. phase.
25/may/2001
12
ATM
25/may/2001
ATM
ATM
13
The Problem
A customer can:
Withdraw funds Query an account Transfer funds
Customer records, account records debit card records are all mantained on the server.
25/may/2001 Banking System Case Study 14
The Problem
(withdraw funds)
Before approving:
Do sufficient funds exist? Is the max limit excedeed? Is there sufficient cash in the dispenser?
If approved:
Cash is dispensed; A receipt is printed; The card is ejected
25/may/2001
15
The Problem
(transfer funds)
Before approving:
Has the customer at least two accounts? Are there sufficient funds in the account to be debited?
If approved:
A receipt is printed;
25/may/2001
16
The Problem
A transaction starts when:
Card is inserted Card is recognized (assumed true) Card validated PIN is inserted & validated The customer is allowed three attempts to enter the correct PIN; if the 3rd attempt fails the card is confiscated.
25/may/2001 Banking System Case Study 17
The Problem
A card is composed by:
25/may/2001
18
The Problem
An ATM operator can:
Start up and close down the ATM to replenish the cash dispenser for routine maintenance
25/may/2001
19
The Problem
(what is not in)
It is assumed that functionality such as open/close accounts create/update/delete customer and cards is provided by an existing system and is not part of the problem.
During modeling the Bank Server should be considered as part of the problem
25/may/2001
20
Two users/actors:
ATM customer ATM operator
25/may/2001
22
Withdraw funds
23
Static Modeling
Problem domain System Context Static Model
Attention is focused on Problem Domain and System Context The result is a Conceptual Static Model
Banking System Case Study 26
25/may/2001
Physical entity:
Dispenser (cash) Printer (receipt) Card Reader (card)
External users:
Operator (keyboard/display) Customer (keyboard/display)
25/may/2001
27
ATM
Customer Interface
25/may/2001
28
Customer Interface
25/may/2001
30
ATM Card: info read from the magnetic strip Card: ATM Cash: amount of cash maintained in Cash: ATM Receipt: Receipt: info about a transaction (unnecessary because holds info similar to Transaction class
25/may/2001 Banking System Case Study 31
25/may/2001
32
(continues)
25/may/2001 Banking System Case Study 33
Object Structuring
Structuring the system into objects for the dynamic model definitions. definitions.
Objects and classes are determined For each use case a collaboration (or sequence) diagram is developed
25/may/2001
34
Object Structuring
Client/Server Subsystem Structuring (1)
Bank Server
ATM
ATM Customer executes both client/server ATM Operator executes entirely on client
Banking System Case Study 35
25/may/2001
Object Structuring
Major Subsystems
25/may/2001
36
Object Structuring
Client/Server Subsystem Structuring (2)
Client/Server use case
25/may/2001
37
Object Structuring
Subsystem packaging of use cases
25/may/2001
38
Banking system is seen as a package Foreach external class one interface class One instance of each interface classes for each ATM
25/may/2001
39
Customer Interface
25/may/2001
40
Each use case is considered All the objs participating in use case are determined What is used? (to do what?) Where info should be stored? Is something missing?
25/may/2001
42
What is in:
Objs accessible from each ATM (customer, account, (customer, debit card)
Entity classes
Customer, Account (Superclass), (Superclass), Checking/Saving Account (Subclasses), (Subclasses), Debit Card ATM Transaction obj migrates from client to server
Business Logic
PIN Validation, TransactionManager, WithdrawalTransactionManager, QueryTransactionManager, TransferTransactionManager
25/may/2001 Banking System Case Study 43
Dynamic Modeling
Depicts interaction among objs participating in each use case Starting point: point:
Sequence of inter-objs comunications are intershown (with both sequence or collaboration diagram)
25/may/2001
44
The system is structured in client & server side The use cases were divided into abstract client and server use case The collaboration diagram are structured for client and server subsystems Statecharts shown form state-dependent use statecases
25/may/2001 Banking System Case Study 45
Server Side
25/may/2001 Banking System Case Study 46
25/may/2001
47
25/may/2001
48
Statechart for ATM Control: ATM Client Validate PIN use case
25/may/2001
49
25/may/2001
50
25/may/2001
51