UML for E-banking

14
OBJECT ORIENTED ANALYSIS AND DESIGN ASSIGNMENT NAME : G.MUTHUMANIKANDAN ROLL NO : 70244 COURSE : B.SC.COMPUTER SCIENCE YEAR : III PROJECT TITLE : ONLINE BANKING SYSTEM SUBMITTED TO : Mrs. P.MUTHULAKSHMI M.Sc., M.Phil SUBMITTED ON : 10 - FEBRUARY - 2010

description

UML for E-banking

Transcript of UML for E-banking

Page 1: UML for E-banking

OBJECT ORIENTED ANALYSIS AND DESIGNASSIGNMENT

NAME : G.MUTHUMANIKANDAN

ROLL NO : 70244

COURSE : B.SC.COMPUTER SCIENCE

YEAR : III

PROJECT TITLE : ONLINE BANKING SYSTEM

SUBMITTED TO : Mrs. P.MUTHULAKSHMI M.Sc., M.Phil

SUBMITTED ON : 10 - FEBRUARY - 2010

Page 2: UML for E-banking

Object Oriented Method (OMT )

Object-Oriented Methods for information system analysis and design are semi-formal methods based on graphical models. These models have the advantage of offering a synthetic view of the system which allows communication with customers.But their notations are ambiguous and result in a lack of precision in the specifications. This lack of precise semantics leads to difficulties to interpret model. On the contrary, formal methods are based on mathematical notations.While their use allows to increase system quality, these methods are not most used in practice and their application field is generally limited to safety-critical systems. There are numerous reasons why formal methods do not enter the general practice. Semi formal and formal methods seem several proposals have been done in order to combine semi formal and formal methods. They include the translation of structured methods and Object Oriented Methods like OMT, Fusion or UML.

OMT has proposed three main types of models:

Object model : The object model represents the static and most stable phenomena in the modeled domain . Main concepts are classes and associations, with attributes and operations. Aggregation and generalization are predefined relationships.

Dynamic model : The dynamic model represents a state/transition view on the model. Main concepts are states, transitions between states, and events to trigger transitions. Actions can be modeled as occurring within states. Generalization and aggregation are predefined relationships.

Functional model : The functional model handles the process perspective of the model, corresponding roughly to data flow diagrams. Main concepts are process, data store, data flow, and actors

Class diagram

The UML representation of a class is a rectangle containing three compartments stacked vertically. The top compartment shows the class's name. The middle compartment lists the class's attributes. The bottom compartment lists the class's operations .  Associations between classes are depicted as lines between classes.  Associations should include multiplicity indicators at each end, for example 0..1 representing ‘zero or one’ and 1..* representing “one or more”.  Associations may have roles indicated, for example the mentors association, a recursive relation that professor objects have with other professor objects, indicates the roles of advisor and associate.

Class attribute list

The attribute section of a class (the middle compartment) lists each of the class's attributes on a separate line. The attribute section is optional, but when used it contains each attribute of the class displayed in a list format. The line uses the following format:

name : attribute type

accountNo : Integer

Sometimes it is useful to show on a class diagram that a particular attribute has a default value. (For example, in a banking

Page 3: UML for E-banking

account application a new bank account would start off with a zero balance.).

The UML specification allows for the identification of default values in the attribute list section by using the following notation:

name : attribute type = default value

For example:balance : Dollars = 0

Class operations list

The class's operations are documented in the third compartment of the class diagram's rectangle, which again is optional. Like the attributes, the operations of a class are displayed in a list format, with each operation on its own line. Operations are documented using the following notation:

name(parameter list : attribute type) : type of value returned

Example:

Associations

When you model a system, certain objects will be related to each other, and these relationships themselves need to be modeled for clarity. There are five types of associations. I will discuss two of them bi-directional and uni-directional associations in this section, and I will discuss the remaining three association types in the Beyond the basics section.

Bi-directional association: An association is a linkage between two classes. Associations are always assumed to be bi-directional; this means that both classes are aware of each other and their relationship, unless you qualify the association as some other type

Uni-directional association: In a uni-directional association, two classes are related, but only one class knows that the relationship exists.

Indicator Meaning0..1 Zero or one1 One only0..* Zero or more* Zero or more1..* One or more3 Three only0..5 Zero to Five5..15 Five to Fifteen

Packages

Inevitably, if you are modeling a large system or a large area of a business,

ClassName

name : attribute type

name() : return type

BankAccount

accountNo : Integer balance : Dollars = 0

deposit(amount:Dollar)withdrawl(amount:Dollar)

Page 4: UML for E-banking

there will be many different classifiers in your model. Managing all the classes can be a daunting task; therefore, UML provides an organizing element called a package. Packages enable modelers to organize the model's classifiers into namespaces, which is sort of like folders in a filing system. Dividing a system into multiple packages makes the system easier to understand, especially if each package represents a specific part of the system.

Association class

In modeling an association, there are times when you need to include another class because it includes valuable information about the relationship. For this you would use an association class that you tie to the primary association. An association class is represented like a normal class. The difference is that the association line between the primary classes intersects a dotted line connected to the association class.

Reflexive associations : We have now discussed all the association types. As you may have noticed, all our examples have shown a relationship between two different classes. However, a class can also be associated with itself, using a reflexive association. This may not make sense at first, but remember that classes are abstractions.

Aggregation

Aggregation is a special type of association used to model a "whole to its parts" relationship. In basic aggregation relationships, the lifecycle of a part class is independent from the whole class's lifecycle.

Basic aggregation : An association with an aggregation relationship indicates that one class is a part of another class. In an aggregation

relationship, the child class instance can outlive its parent class. To represent an aggregation relationship, you draw a solid line from the parent class to the part class, and draw an unfilled diamond shape on the parent class's association end.

Composition aggregation : The composition aggregation relationship is just another form of the aggregation relationship, but the child class's instance lifecycle is dependent on the parent class's instance lifecycle.

VisibilityIn Object Oriented design, there is a

notation of visibility for attributes and operations. UML identifies four types of visibility: public, protected, private, and package.The UML specification does not require attributes and operations visibility to be displayed on the class diagram, but it does require that it be defined for each attribute or operation. To display visibility on the class diagram, you place the visibility mark in front of the attribute's or operation's name. Table 4 displays the different marks for the UML supported visibility types.

Mark Visibility type+ Public# Protected- Private~ Package

StarUML tool

StarUML is a fully fledged, open source, UML modeling tool that supports the ability to create software designs, from basic concepts, through to the coded solution. Users should beware that this tool is more complex than a simple UML

Page 5: UML for E-banking

diagram editing tool, in that, through the use of the Model Drive Architecture (MDA) standard, the tool supports complex modeling which is realizable in code. The package is aimed at the serious developer and is not suitable for beginners. Once the tool is mastered, the user can produce professional results without the need to invest in more costly commercial tools such as Borland Together or Rational Rose, which perform the same function.The tool supports the ability to add plug-ins to the basic system. Although written in the Delphi language, these plug-ins can be written in any COM-compatible language, such as C++, Delphi, C# and VB. On completion of the software design, represented as a model set, the Diagram Overview mode allows the user to see an at-a-glance view of the overall solution before completion.For the creation of professional UML models with the follow through capability of creating the coded solution, this package is hard to beat unless you are willing to pay for a commercial tool. However, this is not a tool aimed at the beginner who is just getting to grips with UML, although it is probably the most user-friendly introduction for those who need to understand the full weight of UML based development techniques. It is unfortunate that this tool is currently inactive in terms of the development of new releases. Nevertheless, anyone who needs exposure to UML concepts, especially to assist in understanding the difference between a software diagram, the underlying model, and the different views of that model, then this tool fits that purpose.

Advantages

Professional, inter-connected models can be created.

Supports plug-ins for both importing and exporting.

Code and documentation plug-ins provided with package.

Disadvantages

Complex for the beginner. No longer on a release cycle. Not cross platform. Supports code generation for the

Windows COM model only.

PROJECT

Online Banking System

With cybercafes and kiosks springing up in different cities access to the Net is going to be easy. Internet banking (also referred as e banking) is the latest in this series of technological wonders in the recent past involving use of Internet for delivery of banking products & services. Even the Morgan Stanley Dean Witter Internet research emphasised that Web is more important for retail financial services than for many other industries. Internet banking is changing the banking industry and is having the major effects on banking relationships. Banking is now no longer confined to the branches were one has to approach the branch in person, to withdraw cash or deposit a cheque or request a statement of accounts. In true Internet banking, any inquiry or transaction is processed online without any reference to the branch (anywhere banking) at any time. Providing Internet banking is increasingly becoming a "need to have" than a "nice to have" service. The net banking, thus, now is more of a norm rather than an exception in many developed countries due to the fact that it is the cheapest way of providing banking services.

Page 6: UML for E-banking

Class Diagram for Online Banking System:

Use Case diagram for Banking System

System

user

atm transaction pin validation

invalid pininsert card

<<extend>>

Bank Databaseonline transaction

login logout<<include>>

<<include>>

invalid login

<<extend>>bank employee

client desktop transaction

<<include>> <<include>>

transaction

retail institution

<<include>>

<<include>>

<<include>>

invalid card<<extend>>

web merchant

:

Page 7: UML for E-banking

Online Transaction Sequence Diagram:

customer console network to bank

transaction1 : loginRequest()

2 : validity()

3 : profileRequest()

4 : display()

5 : transferRequest()

6 : transfer()

7 : succed()

8 : acknowledgement()

9 : transferRequest()

online transactionsequence diagram

Online Transaction Collaboration Diagram:

customer console network to bank

transaction

1 : login request()

2 : validity()3 : profile request()

4 : display()

5 : transfer request()

6 : transfer()

7 : succeed()

8 : acknowledgement()

9 : transfer request()

Page 8: UML for E-banking

Online Transaction Activity Diagram:

open web page

create account enter id and pwd

furnish details

submit

choice menu

amount transfer view details change pwd

finished

valid details

valid login

yes

yes

no

no

Page 9: UML for E-banking

Component Diagram for Banking System:

Deployment Diagram for Banking System: