advertisement

SIENA

50 %
50 %
advertisement
Information about SIENA
Entertainment

Published on January 16, 2008

Author: Reinardo

Source: authorstream.com

advertisement

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

Add a comment

Related presentations

Related pages

Siena – Wikipedia

Siena (italienische Aussprache [ˈsjɛːna]) ist der Name einer Stadt und eines früheren Stadtstaates im Zentrum der italienischen Toskana. Die Stadt hat ...
Read more

Siena - touristische Informationen. Das historische ...

Siena. Was man über diese Stadt wissen sollte und was man sehen sollte. Touristische Informationen. Über den Palio, das historische Pferderennen
Read more

Siena Reiseführer – Wikitravel - Wikitravel - The Free ...

Der Open Source Reiseführer für Siena mit aktuellen Informationen und Tipps über Hotels, Sehenswürdigkeiten, Gastronomie, das Nachtleben und mehr.
Read more

Über Siena, ihr Touristenführer für Siena

Informationen über die Stadt Siena: Geschichte, Kultur, Hotels, Pläne und vieles mehr über Siena
Read more

siena

Siena.de: Reise und Kultur . Kultur- und Reiseinformationen über Seina. Siena.de. Reise und Kultur ...
Read more

Siena - Toskana - Urlaub, wo Italien am schönsten ist

Kultur und Entspannung pur bei einem Urlaub im malerischen Siena - eine der schönsten Städte der Toskana
Read more

Siena - Wikipedia, the free encyclopedia

Siena (Italian pronunciation: ; in English sometimes spelled Sienna) is a city in Tuscany, Italy. It is the capital of the province of Siena.
Read more

Siena in 3 Tagen - Toskana - Ihr Portal zum Thema Toskana

Siena in 3 Tagen. Siena gehört neben Florenz zu den beliebtesten Reisezielen in der Toskana und ist im Gegensatz zur Letztgenannten weniger durch die ...
Read more

Siena, Italien: Tourismus in Siena - TripAdvisor

Auf TripAdvisor finden Sie alles für Siena, Province of Siena: 122.170 unabhängige Bewertungen von Hotels, Restaurants und Sehenswürdigkeiten sowie ...
Read more

Fiat Siena – Wikipedia

Fiat Siena (2001–2004) Produktionszeitraum: seit 1996: Motoren: Ottomotoren: 1,0–1,8 Liter (51–84 kW) Dieselmotoren: 1,3–1,7 Liter (≈52 kW) Länge:
Read more