SIENA

Information about SIENA

Published on January 16, 2008

Author: Reinardo

Source: authorstream.com

Content

Banking System Case Study Using COMET:  Banking System Case Study Using COMET Alessandro Siena Università di Genova Dipartimento di Informatica e Scienze dell’Informazione Summary:  Summary COMET Software Life Cycle Model The problem Case study development COMET Software Life Cycle Model:  COMET Software Life Cycle Model Requirement Modeling Analysis Modeling Design Modeling Incremental Sw Construction Incremental Sw Integration System Testing Throwaway Prototyping Incremental Prototyping User C u s t o m e r COMET Software Life Cycle Model Requirements Modeling:  COMET Software Life Cycle Model Requirements Modeling A requirement model is developed; Functional requirements are expressed as: Actors Use case (with narrative description) Essential: User inputs Active participation A throwaway prototype can be developed to clarify requirements COMET Activities in Requirements Modeling:  COMET Activities in Requirements Modeling The system is considered as a black box. Emphasis is on understanding the problem. Activities: use case modeling COMET Software Life Cycle Model Analysis Modeling:  COMET Software Life Cycle Model Analysis Modeling Static and dynamic models are developed; Static model: structural relationship among problem domain classes; Dynamic model: use cases refinement; Collaboration diagram and/or sequence diagram. COMET Activities in Analysis Modeling:  COMET Activities in Analysis Modeling The analysis of the problem domain is considered. Activities: static modeling; object structuring; finite state machines modeling; dynamic modeling. COMET Software Life Cycle Model Design Modeling:  COMET Software Life Cycle Model Design Modeling The software architecture of the system is designed; Analysis model  Design model; System  Subsystems; Concurrent/Sequential; COMET Activities in Design Modeling:  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. COMET Software Life Cycle Model Incremental Sw Construction:  COMET Software Life Cycle Model Incremental Sw Construction For each subset of the system to be constructed: detailed design, coding, testing, of each class in the subset. The Sw is gradually constructed. COMET Software Life Cycle Model Incremental Sw Integration:  COMET Software Life Cycle Model Incremental Sw Integration Integration testing of each sw increment is performed; Integration test cases are developed for each use case; The interface between objects are tested. COMET Software Life Cycle Model System Testing:  COMET Software Life Cycle Model System Testing Functional testing of the system; Functional test case are built for each black box use case; Any sw increment released to the customer needs to go through this phase. The Problem (draw):  The Problem (draw) Bank Server wan ATM ATM ATM ATM The Problem:  The Problem A customer can: Withdraw funds Query an account Transfer funds Delete a transaction in any moment so: The transaction is aborted The card is ejected Customer records, account records debit card records are all mantained on the server. The Problem (withdraw funds):  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 The Problem (transfer funds):  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; The card is ejected The Problem:  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. The Problem:  The Problem A card is composed by: A magnetic strip in which encodes: Start date; Expiration date; Serial n. The Problem:  The Problem An ATM operator can: Start up and close down the ATM to replenish the cash dispenser for routine maintenance The Problem (what is not in):  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 Case study development:  Case study development Use case model Static modeling Object structuring Dinamic modeling Use Case Model:  Use Case Model Two users/actors: ATM customer ATM operator An actor represents a role  multiple actors&operators Use Case Model:  Use Case Model Validate PIN Withdraw funds ATM Customer Operator Use case diagram Use case Model (Validate PIN Abstract use case):  Use case Model (Validate PIN Abstract use case) Use case name: Validate PIN Summary: system validates customer PIN Actor: ATM customer Pre: ATM is idle, displaying a welcome msg Description: 1. Customer inserts … 2. …… Alternatives: …… Post: Customer PIN has been validated Use Case Model (Withdraw funds Concrete Use Case):  Use Case Model (Withdraw funds Concrete Use Case) Use case name: Withdraw funds Summary: Customer withdraws a specific amount of funds from a valid bank account Actor: ATM customer Pre: ATM is idle, displaying a welcome msg Description: 1. Include Validate PIN abstract use case 2. Customer selects withdrawal, enter amounts,… 3. … … Alternatives: …… Post: Customer funds have been withdrawn Static Modeling:  Static Modeling Attention is focused on Problem Domain and System Context The result is a Conceptual Static Model Problem domain System Context Static Model Static Modeling of the Problem Domain:  Static Modeling of the Problem Domain Physical entity: Dispenser (cash) Printer (receipt) Card Reader (card) External users: Operator (keyboard/display) Customer (keyboard/display) Conceptual Static Modeling for the Problem Domain: physical classes:  Conceptual Static Modeling for the Problem Domain: physical classes Bank ATM has 1..* 1 Customer Interface Static Modeling of the System Context:  Static Modeling of the System Context Developed to show the external classes to which the Banking System (aggregate class) has to interface. The context class diagram is developed considering physical classes determined during static modeling of the problem domain (one instance of these external classes for each ATM). External classes ~ users & I/O devices (fig.) Static Modeling Banking System context class diagram:  Static Modeling Banking System context class diagram Customer Interface Static Modeling of the Entity Classes:  Static Modeling of the Entity Classes Both transaction and account are the generalization of more specialized classes Entity classes are also required to model the Physical classes ATM Card: info read from the magnetic strip ATM Cash: amount of cash maintained in ATM Receipt: info about a transaction (unnecessary because holds info similar to Transaction class Conceptual Static Model for Problem Domain: entity classes:  Conceptual Static Model for Problem Domain: entity classes Conceptual Static Model for Banking System: Class Attributes (partial):  Conceptual Static Model for Banking System: Class Attributes (partial) (continues…) Object Structuring:  Object Structuring Structuring the system into objects for the dynamic model definitions. Objects and classes are determined For each use case a collaboration (or sequence) diagram is developed Object Structuring Client/Server Subsystem Structuring (1):  Object Structuring Client/Server Subsystem Structuring (1) Subsystems are easily identifiable ATM Client Subsystem Bank Server Subsystem ATM Customer executes both client/server ATM Operator executes entirely on client Bank Server ATM Object Structuring Major Subsystems:  Object Structuring Major Subsystems Object Structuring Client/Server Subsystem Structuring (2):  Object Structuring Client/Server Subsystem Structuring (2) Client/Server use case Client Side use case Server Side use case Object Structuring Subsystem packaging of use cases:  Object Structuring Subsystem packaging of use cases ATM Client Object Structuring: Interface Objects:  ATM Client Object Structuring: Interface Objects Banking system is seen as a package Foreach external class  one interface class One instance of each interface classes for each ATM From System Context Diagram to Interface Objects Banking System external classes and interface class:  Banking System external classes and interface class Customer Interface ATM Client Object Structuring: Objects in Use Cases:  ATM Client Object Structuring: Objects in Use Cases 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? Result: classes in ATM class subsystem shown as a package ATM Client Subsystem Classes:  ATM Client Subsystem Classes Object Structuring in Server Subsystem:  Object Structuring in Server Subsystem What is in: Objs accessible from each ATM (customer, account, debit card) Entity classes Customer, Account (Superclass), Checking/Saving Account (Subclasses), Debit Card ATM Transaction obj migrates from client to server Business Logic PIN Validation, TransactionManager, WithdrawalTransactionManager, QueryTransactionManager, TransferTransactionManager Dynamic Modeling :  Dynamic Modeling Depicts interaction among objs participating in each use case Starting point: Use cases & objs determined in Objs Structuring Sequence of inter-objs comunications are shown (with both sequence or collaboration diagram) Dynamic Modeling (2):  Dynamic Modeling (2) 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 cases Collaboration diagram: ATM Client Validate PIN use case:  Collaboration diagram: ATM Client Validate PIN use case Server Side Collaboration diagram: ATM Server Validate PIN use case:  Collaboration diagram: ATM Server Validate PIN use case Sequence Diagram: ATM Client Validate PIN use case:  Sequence Diagram: ATM Client Validate PIN use case Statechart for ATM Control: ATM Client Validate PIN use case:  Statechart for ATM Control: ATM Client Validate PIN use case Toplevel Statechart for ATM Control:  Toplevel Statechart for ATM Control Statechart for ATM Control: Processing Customer Input superstate:  Statechart for ATM Control: Processing Customer Input superstate

Related presentations


Other presentations created by Reinardo

SCCM 2007 Overview
14. 02. 2008
0 views

SCCM 2007 Overview

04What is Wi Fi
04. 02. 2008
0 views

04What is Wi Fi

Environmental Analysis
17. 01. 2008
0 views

Environmental Analysis

session1 ws4 dias powerpoint
07. 05. 2008
0 views

session1 ws4 dias powerpoint

K Rauscher WERT for ETSI EMTEL
02. 05. 2008
0 views

K Rauscher WERT for ETSI EMTEL

Panel1 1
23. 04. 2008
0 views

Panel1 1

Politics and the Olympic Games
22. 04. 2008
0 views

Politics and the Olympic Games

Animal Diversity and Function
17. 04. 2008
0 views

Animal Diversity and Function

ITI Olympics
15. 04. 2008
0 views

ITI Olympics

AYURVEDA
03. 03. 2008
0 views

AYURVEDA

4 15 04
09. 01. 2008
0 views

4 15 04

AFD 070521 051
09. 01. 2008
0 views

AFD 070521 051

01 Basangwa
11. 01. 2008
0 views

01 Basangwa

Tajikistan wildlife
15. 01. 2008
0 views

Tajikistan wildlife

Dec 4 comets and meteors
16. 01. 2008
0 views

Dec 4 comets and meteors

succeed in industry
22. 01. 2008
0 views

succeed in industry

APEC Korea
23. 01. 2008
0 views

APEC Korea

TAXEFF
24. 01. 2008
0 views

TAXEFF

Ichia
24. 01. 2008
0 views

Ichia

7 GB Microcredit
04. 02. 2008
0 views

7 GB Microcredit

Slides 6 22 3
12. 02. 2008
0 views

Slides 6 22 3

HKPC Sep06
24. 01. 2008
0 views

HKPC Sep06

media presentation
28. 01. 2008
0 views

media presentation

biotic
28. 01. 2008
0 views

biotic

Me445 robotics
28. 01. 2008
0 views

Me445 robotics

sexualityinchina
31. 01. 2008
0 views

sexualityinchina

foucault3
05. 02. 2008
0 views

foucault3

ESM 219 N Cycle 07
07. 02. 2008
0 views

ESM 219 N Cycle 07

Angel vc hedge PE
07. 02. 2008
0 views

Angel vc hedge PE

Ch2
14. 01. 2008
0 views

Ch2

tender mercy
26. 02. 2008
0 views

tender mercy

vic miller
05. 03. 2008
0 views

vic miller

TecEcoEco CementConcretes011105
12. 02. 2008
0 views

TecEcoEco CementConcretes011105

WERTH SITE
22. 01. 2008
0 views

WERTH SITE

Aarhus Lecture
07. 03. 2008
0 views

Aarhus Lecture

Mahesh05
30. 01. 2008
0 views

Mahesh05

ES110 S07 OzoneTalk
20. 02. 2008
0 views

ES110 S07 OzoneTalk

hvrp grant app info
24. 03. 2008
0 views

hvrp grant app info

Finding our way
08. 01. 2008
0 views

Finding our way

2002 10 xx alguns dias depois
23. 01. 2008
0 views

2002 10 xx alguns dias depois

cs4811 lastclass
21. 03. 2008
0 views

cs4811 lastclass

presentation Willison B G
03. 04. 2008
0 views

presentation Willison B G

Outside reading I Semester 2
11. 02. 2008
0 views

Outside reading I Semester 2

CF eng
25. 01. 2008
0 views

CF eng

BrookeHanson specialfx
09. 01. 2008
0 views

BrookeHanson specialfx

Folien def juni06
07. 02. 2008
0 views

Folien def juni06

orangutans
13. 01. 2008
0 views

orangutans