Uml Unit-6

RAGHU ENGINEERING COLLEGE(Autonomous)
Dakamarri, Visakhapatnam – 531162

Approved by AICTE
Accredited by NBA
Accredited by NAAC with 'A' Grade
Affiliated to JNTU-Kakinada
COMPUTER SCIENCE & ENGINEERING
IV B.Tech - I Semester
UNIFIED MODELLING LANGUAGE(UNIT-3)
V.TATARAO
Asst.Professor
CSE DEPT
UNIFIED MODELLING LANGUAGE UNIT-6
UNIT-VI
UNIT-VI: Architectural Modeling: Component, Deployment, Component diagrams and
Deployment diagrams. Case Study: The Unified Library application.
Components
Introduction:
A component is a physical replaceable part of a system that complies with and provides the
realization of a set of interfaces. We use components to model the physical things that may reside
on a node, such as executables, libraries, tables, files and documents. A component typically
represents the physical packaging of otherwise logical elements such as classes, interfaces and
collaborations.
We do logical modeling to visualize, specify, and document our decisions about the vocabulary of
our domain and the structural and behavioral way those things collaborate. We do physical
modeling to construct the executable system. Object libraries, executables, COM+ components and
Enterprise Java Beans are all examples of components.
Components and Classes:

In many ways, components are like classes. Both have names, both may realize a set of interfaces,
both may participate in dependency, generalization and association relationships, both may be
nested, and both may have instances. However, there are some significant differences between
components and classes:
 Classes represent logical abstractions, components represent physical things that live in the
world of bits. In short, components may live on nodes, classes may not.
 Components represent the physical packaging of otherwise logical components and are at a
different level of abstraction.
 Classes may have attributes and operations directly. In general, components only have
operations that are reachable only through their interfaces.
The relationship between a component and the classes it implements can be shown explicitly by
using a dependency relationship as shown below:
RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Components and Interfaces:
An interface is a collection of operations that are used to specify a service of a class or a
component. We can show the relationship between a component and its interfaces in one of the two
ways. The first style renders the interfaces in its elided, iconic form. The component that realizes
the interfaces is connected to the interface using an elided realization relationship. The second style
renders the interface in its expanded form, perhaps revealing its operations. The component that
realizes the interface is connected to the interface using a full realization relationship. In both cases,
the component that accesses the services of the other component through the interfaces is connected
to the interface using a dependency relationship.
Binary Replaceability:
The basic intent of every component-based operating system facility is to permit the assembly of
systems from binary replaceable parts. This means that we can create a system out of components
and then evolve the system by adding new components and replacing the old ones, without
rebuilding the system.
First, a component is physical. It lives in the world of bits, not concepts.
Second, a component is replaceable. A component is substitutable means it is possible to replace a
component with another that conforms to the sane interfaces.
Third, a component is part of a system. A component rarely stands alone. Rather, a given
component collaborates with other components and in so doing exists in the architectural or
technology context in which it is intended to be used.
Fourth, a component conforms to and provides the realization of a set of interfaces.
Kinds of Components:
Three kinds of components may be distinguished.
First, there are deployment components. These are the components necessary and sufficient to form
an executable system, such as dynamic libraries (DLLs) and executables (EXEs).
Second, there are work product components. These components are generally the residue of the
development process, consisting of things such as the source code files and data files from which
deployment components are created.
Third are execution components. These components are created as a consequence of an executing
system, such as COM+ object, which is instantiated from a DLL.
Standard Elements:
All the UML’s extensibility mechanisms apply to components. Most often, we’ll use tagged values
to extend the component properties and stereotypes to specify new kind of components.
The UML defines five standard stereotypes that apply to components:
executable Specifies a component that may be executed on a node

library Specifies a static or dynamic object library
table Specifies a component that represents a database table
file Specifies a component that represents a document containing code or data
document Specifies a component that represents a document
Common Modeling Techniques:

Modeling Executables and Libraries:
To model executables and libraries:
 Identify the partitioning of the physical system. Consider the impact of the technical,
configuration management and reuse issues.
 Model any executables and libraries as components, using the appropriate standard
elements.
 Model the significant interfaces that some components use and others realize.
 As necessary to communicate your intent, model the relationships among these executables,
libraries and interfaces.

Modeling Tables, Files and Documents:
To model tables, files and documents:
 Identify the components that are part of the physical implementation of your system.
 Model these things as components.
 As necessary to communicate your intent, model the relationships among these components
and other executables, libraries and interfaces in the system.
Modeling an API:
To model an API:
 Identify the programmatic seems in the system and model each seem as an interface.
 Expose only those properties of the interface that are important to visualize the given
context. Otherwise, hide these properties, keeping them in the interface’s specification for
reference, as necessary.
 Model the realization of each API only as it is important to show the configuration of a
specific implementation.
Modeling Source Code:

To model source code:
 Depending on the constraints imposed by your development tools, model the files used to
store the details of all your logical elements, along with their compilation dependencies.
 Use tagged values if you want to use configuration management and version control tools.
 As far as possible, let your development tools manage the relationships among these files,
and use the UML only to visualize and document these relationships.
Component Diagrams
Introduction:
Component diagrams are one of the two kinds of diagrams for modeling the physical aspects of
object-oriented software systems. A component diagram shows the organization and dependencies
among a set of components. We use component diagrams to model the static implementation view
of a software system.

Common Properties:
A component is just a special kind of a diagram and shares the same common properties as the
other diagrams like: a name and graphical contents. What distinguishes a component diagram from
the rest of the diagrams is its content.
Content:
Component diagram commonly contain:
 Components
 Interfaces
 Dependency, generalization, association and realization relationships.
Like all other diagrams, component diagrams may contain notes and constraints. Component
diagrams may also contain packages.
Common Uses:
When modeling the static implementation view of a system, we will typically use component
diagrams in one of four ways:
1. To model source code.
2. To model executable releases.
3. To model physical databases.
4. To model adaptable systems.

Modeling source code:
To model a system’s source code:
 Either by forward or reverse engineering, identify the set of source code files of interest and
model them as components stereotypes as files.
 For larger systems, use packages to show groups of source code files.
 Consider using tagged values indicating such information as the version number of the
source code file, its author, and the date it was last changed.
 Model the compilation dependencies among these files using dependencies.
Modeling an executable release:

To model an executable release:
 Identify the set of components you’d like to model.
 Consider the stereotype of each component in this set.
 For each component in this set, consider its relationship to its neighbors. Most, often this
will involve interfaces that are realized by certain components and then imported by others.
Modeling a physical database:

To model a physical database:
 Identify the classes in your model that represent your logical database schema.
 Select a strategy for mapping these classes to tables. You have to also consider the physical
distribution of your databases.
 To visualize, specify, construct and document your mapping, create a component diagram
that contains components stereotyped as tables.
 Where possible, use tools to help you transform your logical design into a physical design.

Modeling adaptable systems:
To model an adaptable system:
 Consider the physical distribution of the components that may migrate from node to node.
We can specify the location of a component instance by marking it with a location tagged
value.
 If you want to model the actions that cause a component to migrate, create a corresponding
interaction diagram that contains component instances. We can illustrate a change of
location by drawing the same instance more than once, but with different values for its
location tagged value.
Deployment
Introduction:
A node is a physical element that exists at runtime and represents a computational resource,
generally having at least some memory and, often, processing capability. We use nodes to model
the topology of the hardware on which our system executes. A typically represents a processor or a
device on which components may be deployed.
When we architect a software-intensive system, we have to consider both its logical and physical
dimensions. On the logical side, you’ll find things such as classes, interfaces, collaborations,
interactions and state machines. On the physical side you’ll find components and nodes.
In UML, a node is represented as a cube as shown below. Using stereotypes we can tailor this
notation to represent specific kinds of processors and devices.
Nodes and Components:

In many ways, nodes are like components: Both have names, both may participate in dependency,
generalization and association relationships. Both may be nested, both may have instances, both
may be participants in interactions. However, there are significant differences between nodes and
components:
 Components are things that participate in the execution of a system. Nodes are things that
execute components.
 Components represent the physical packaging of logical elements, nodes represent the
physical deployment of components.
This first difference is the most important. Simply put, nodes execute components; components are
things that are executed by nodes.
A set of objects or components that are allocated to a node as a group is called a distribution unit.
Connections:
The most common kind of relationship we’ll use among nodes is an association. In this context, an
association represents a physical connection among nodes, such as an Ethernet connection, a serial
line, or a shared bus as shown below. We can even use associations to model indirect connections,
such as a satellite link between distant processors.

Modeling processors and devices:
To model processors and devices:
 Identify the computational elements of your system’s deployment view and model each as a
node.
 If these elements represent generic processors and devices, then stereotype them as such. If
they are kinds of processors and devices that are part of the vocabulary of your domain, then
specify an appropriate stereotype with an icon for each.
 As with class modeling, consider the attributes and operations that might apply to each
node.
Modeling the distribution of components:

To model the distribution of components:
 For each significant component in your system, allocate it to a given code.
 Consider duplicate locations for components.
 Render this allocation in one of the three ways:
1. Don’t make the allocation visible, but leave it as part of the backplane of your model that is, in
each node’s specification.
2. Using dependency relationships, connect each node with the components it deploys.
3. List the components deployed on a node in an additional compartment.
Deployment Diagrams
Introduction:
Deployment diagrams are one of the two kinds of diagrams used in modeling the physical aspects
of an object-oriented system. A deployment diagram shows the configuration of run time
processing nodes and the components that live on them.
We use deployment diagrams to model the static deployment view of a system. A deployment
diagram is a diagram that shows the configuration of run time processing nodes and the components
that live on them.
Common Properties:
A deployment is just a special kind of diagram that shares the same properties as all other diagrams
like: a name and graphical contents. What distinguishes a deployment diagram from the rest of the
diagrams is its content.
Contents:
A deployment diagram commonly contains:
 Nodes

 Dependency and association relationships
Like all other diagrams, deployment diagrams may contain notes and constraints.
Deployment diagrams may also contain components, each of which must live on some node.
Deployment diagrams may also contain packages and subsystems.
Common Uses:
When modeling the static deployment view of a system, we’ll typically use deployment diagrams in
one of the three ways:
1. To model embedded systems.
2. To model client/server systems.
3. To model fully distributed systems.

Modeling an embedded system:
To model an embedded system:
 Identify the devices and nodes that are unique to your system.
 Provide visual cues, especially for unusual devices, by using stereotypes.
 Model the relationships among these processors and devices in a deployment diagram.
Similarly, specify the relationship between components and nodes.
 As necessary, expand on the intelligent devices by modeling their structure with a more
detailed deployment diagram.
Modeling a client/server system:

To model a client/server system:
 Identify the nodes that represent your system’s client and server processors.
 Highlight those devices that are relevant to the behavior of your system.
 Provide visual cues for these processors and devices via stereotyping.
 Model the topology of these nodes in a deployment diagram.
Modeling a fully distributed system:

To model a fully distributed system:
 Identify the system’s devices and processors as for simpler client/server systems.
 If you need to reason about the performance of the system’s network or the impact of
changes to the network, be sure to model these communication devices to the level of detail
sufficient to make assessments.
 Pay close attention to logical groupings of nodes, which you can specify by using packages.
 Model these devices and processors using deployment diagrams.
 If you need to focus on the dynamics of the system, introduce use case diagrams to specify
the kind of behavior you are interested in, and expand on these use cases with interaction
diagrams.
Symbol Name Description

An entity required to execute a stereotype function. A
component provides and consumes behavior through
interfaces, as well as through other components. Think of
Component
components as a type of class. In UML 1.0, a component is
Component symbol
modeled as a rectangular block with two smaller rectangles
protruding from the side. In UML 2.0, a component is
modeled as a rectangular block with a small image of the
old component diagram shape.
Node symbol Represents hardware or software objects, which are of a

Node
higher level than components.
Interface symbol Shows input or materials that a component either receives

or provides. Interfaces can be represented with textual notes
or symbols, such as the lollipop, socket, and ball-and-
socket shapes.
Port symbol Specifies a separate interaction point between the

component and the environment. Ports are symbolized with
a small square.
Package symbol Groups together multiple elements of the system and is

Package represented by file folders in Lucidchart. Just as file folders
group together multiple sheets, packages can be drawn
around several components.
Note symbol Allows developers to affix a meta-analysis to the

Note
component diagram.
Dependency symbol Shows that one part of your system depends on another.
Dependencies are represented by dashed lines linking one
--------->
component (or element) to another.
CASE STUDY
1.ATM( Automatic Teller Machine)

Abstract

The Object-Oriented Modeling assists the programmer to address the complexity of a problem
domain by considering the problem not as a set of functions that can be performed but primarily as
a set of related, interacting Objects. This article is based on the approach of Object Oriented
modeling through Unified Modeling Language (UML) for an ATM system in Banking sector. The
main aim of this article is to provide a flexible and faithful environment for a customer, who wants
to do online banking transactions. After successful authentication, the customer can withdraw the
desire amount (within the prescribed limit) from the ATM machine or can transfer amount to other
account. User can also change the pin code. The ATM has solved many problems and now customer
can have money transaction 24/7. In this article UML Class, Interaction diagram, Activity diagram
& Use Case diagram are also designed for the ATM System.
Requirements:
The ATM will service one customer at a time. A customer will be required to insert an ATM card
and enter a personal identification number (PIN) - both of which will be sent to the bank for
validation as part of each transaction. The customer will then be able to perform one or more
transactions. The card will be retained in the machine until the customer indicates that he/she
desires no further transactions, at which point it will be returned -except as noted below.
The ATM must be able to provide the following services to the customer:
1. A customer must be able to make a cash withdrawal from any suitable account linked to the card,
in multiples of Rupees 100. Approval must be obtainedfrom the bank before cash is dispensed.
2. A customer must be able to make a deposit to anyaccount linked to the card, consisting of cash
and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM,
subject to manual verification when the envelope is removed from the machine by an operator.
Approval must be obtained from the bank before physically accepting the envelope.
3. A customer must be able to make a transfer of money between any two accounts linked to the
card.
4. A customer must be able to make a balance inquiry ofany account linked to the card.
ATM USE CASE DIAGRAM
Aim : To work with the use case diagram for ATM system.
Software used: MICROSOFT VISIO 2003
Usecases: a) Insert card b) Enter pin c) Select transaction d) Balance enquiry
e) Withdraw amount f) Dispensed cash g) Printed receipt
Actors: a) Card holder 1) Saving account 2) Current account
Procedure: Draw and drop the actors and use case from browser window into the diagram
window. Associate the use cases and actors.
Description: A use case diagram is a description of set of sequence of actions including variants
that the system performs which yields an observable result of value to an actor. The use case diagram
of ATM system contains two actions majorly. The ATM machine and the client.. The client interacts with
a set of use cases where he can enter ATM machine, enter pin, withdraw money, and check balance.
The ATM machine checks the pin, checks the balance, gives money and gives the receipt
Result: We have successfully worked with the ATM system in use case view.
ATM CLASS DIAGRAM
Aim : To work with class diagram in logical view for unified ATM application.
Procedure: Create a new package from the database and name it as class diagram. From the
toolbar, select the required tools and make corresponding connections.
Description: Class diagrams are used for visualizing, specifying and documenting structural
modeling. It consists of set of classes and then relationships. It consists of classes’ customer, ATM,
account database. Customer class consists of attributes name, address, and account type and account
number. It consists of operations enter pin(), request transaction(), balance enquiry(), withdraw
amount(), takes cash() and takes receipt(). ATM class consists of attributes branch name and code. It
consists of operations accept card(), verifies pin no(), verify balance() and issue money(), accept
inputs(), provide cash(), provide receipts(), process transaction(). Account database consists of branch
name, branch code, ATM center code. Operation like balance checking(), pin details(), withdraw
amount(), verify funds(), deduct funds(), update details(). So we place aggregation relationship
between them.
Result: We have successfully worked with class diagram in logical view for ATM system.
ATM OBJECT DIAGRAM

ATM SEQUENCE DIAGRAM

Aim: To work with sequence diagram in use case view for ATM system.
Procedure: Create a new package from the database and name it as a sequence diagram from the
toolbar, select the required tools and make corresponding connections.
Description: Both sequence and collaboration diagrams are interaction diagrams. Sequence
diagram is an interaction diagrams which emphases time ordering of message. Sequence diagrams
consist of classes’ customer, ATM machine and account. Customer insert card, ATM machine promts for
pin. Customer enters pin, database checks pin verification and database says its ok. Then enters the
transaction he can withdraw amount, customer enter amount and machine sees that amount is
entered. ATM machine verifies amount in database and if balance is present. Tells customer that
withdraw success, customer takes cash and issues receipt and finally takes receipt from ATM machine.
Result: We have successfully worked with sequence diagram in use case view for ATM system.
ATM COLLABORATION DIAGRAM

Aim: To work with collaboration diagram in use case view for ATM system.
Procedure: Create a new package from the database and name it as a collaboration diagram From
the toolbar, select the required tools and make corresponding connections.
Description: Collaboration diagram is an interaction diagram that emphases the structural

organization of objects that send and receive messages. The figure shows collaboration diagrams of
ATM systems. The collaboration diagram consists of objects customer, ATM machine, and account. Here
the messages between these objects are as follows. First insert a card, prompts the pin, enters pin,
machine verifies the pin, if pin is ok & tells its valid. Then choose transaction and customer enter
transaction and want to withdraw amount, enter the amount, after amount is entered checks. If
amount is present in account. If balance present then withdraw issue then takes cash, issue reciept and
takes reciept.
Result: We have successfully worked with collaboration diagram in use case view for ATM system.
ATM ACTIVITY DIAGRAM

ATM STATE CHART DIAGRAM
Aim: To work with the state chart diagram for ATM machine.
Procedure: Create a new package from the database and name it as a state chart diagram From
Description: A state chart diagram shows a state machine emphasizing the flow of control from
state to state. In the state chart diagram for client the flow start from client entering the card and pin
number into the system. If the validation ok () result true then he can enters amount and collect
amount. The statechart diagram for ATM system constitutes the states where it checks the details of
the member for validation, issue amount, issue receipt and then eject card.
Result: We have successfully worked with statechart diagram for ATM machine.
ATM COMPONENT DIAGRAM

Aim: To work with the component diagram for ATM machine.
Procedure: Create a new package from the database and name it as a component diagram From
Description: A component diagram shows the organization of and dependencies among a set of
component. A component is a physical and replaceable part of a system that confirms to and provides
realization of a set of interfaces. The component diagram of the ATM system constitutes three
components. These are database ATM machine and client. The user has a dependency relationship
with the ATM machine which interns as a dependency relation with the database. Result: We have
successfully worked with component diagram for ATM machine.
ATM DEPLOYMENT DIAGRAM

Aim: To work with the deployment diagram for ATM machine.

PROCEDURE: Create a new package from the database and name it as a deployment diagram From
Description: The deployment diagram shows the configuration of runtime processing nodes and
the component that live on them. The deployment diagram of the ATM system contains three nodes.
These nodes are adorned with some of the components that reside on them. The first node is adorned
with the database, the second with the ATM machine and last one is client. The client has a
dependency relation with the ATM machine which intern has a dependency relation with data
component.
Result: We have successfully worked with deployment diagram for ATM machine.
2.LIBRARY SYSTEM

Abstract
Unified Library application project is expected at developing an online Library Management
System for the school, college, university library. This is an Intranet based application that can be
accessed all through the university grounds or campus. This structure can be used to search for
books/magazines, reserve books, find out who is having a particular book, put in requests to buy a
new book etc. This is one integrated system that contains both the user component and the librarian
component. There are features like email notifications/reminders, report generators etc in this
system.
Functional Requirements
Following is a list of functionalities of the system. More functionality that you find appropriate can
be added to this list. And, in places where the description of functionality is not adequate, you can
make appropriate assumptions and proceed.
There are registered people in the system (students, faculty, librarian et al). Each one of them may
have some exclusive privileges (faculty, for example, could borrow reference books for a short
period, while students cannot).
1. A person should be able to
a. login to the system through the first page of the application
b. change the password after logging into the system
c. see the status of the books/journals borrowed/reserved by him and the respective due dates and
other relevant details
d. search for a particular book/journal based on the name of the book/name of the author/subject/etc
and also list for books/journals based on the name of the autor/subject etc
e. reserve a particular book/journal borrowed by others currently cancel the reservation made earlier
for a particular book/journal
f. see who has borrowed a particular book/journal and when is the due date for the same
g. place requests for purchasing new books to the library, by giving details about the name of the
book, name of the author, publisher etc.
h. get help about the LiMS on how to use the different features of the system
2. As soon as a reservation is made for a particular book, an automatic mail should be sent to the
person who made the reservation about the details. Then, a mail should be sent to people who are
having the book currently, stating a reservation has been made on that book.
3. Automatic mails should be sent to the users about the expiry of due dates for the books/journals
borrowed by them. An advance notification (say, 4 days before the expiry of the due date) should be
sent as well.
4. The librarian should be able to
a. include new books/journals or remove some books from the inventory

b. add new users to the system
c. see the purchase requests for new books and be able to approve/reject the same

LIBRARY SYSTEM USE CASE DIAGRAM
LIBRARY SYSTEM CLASS DIAGRAM

LIBRARY SYSTEM OBJECT DIAGRAM
LIBRARY SYSTEM SEQUENCE DIAGRAM

LIBRARY SYSTEM COLLABORATION DIAGRAM
LIBRARY SYSTEM ACTVITY DIAGRAM

LIBRARY SYSTEM STATECHART DIAGRAM
LIBRARY SYSTEM COMPONENT DIAGRAM

LIBRARY SYSTEM DEPLOYMENT DIAGRAM
3. ONLINE BOOK SHOP

Abstract
The main objective of the project is to create an online book store that allows users to search and
purchase a book online based on title, author and subject. The selected books are displayed in a
tabular format and the user can order their books online through credit card payment. Using this
Website the user can purchase a book online instead of going out to a book store and wasting time.
There are many online book stores like Powell’s, Amazon which were designed using Html. I want
to develop a similar website using .NET, SQL Server. Online Book store is an online web
application where the customer can purchase books online. Through a web browser the customers
can search for a book by its title or author, later can add to the shopping cart and finally purchase
using credit card transaction. The user can login using his account details or new customers can set
up an account very quickly. They should give the details of their name, contact number and
shipping address. The user can also give feedback to a book by giving
ratings on a score of five. The books are divided into many categories based on subject like
Software, Database, English, Architecture etc.
The Online Book Store Website provides customers with online shopping through a web browser. A
customer can, create, sign in to his account, place items into a shopping cart and purchase using his
credit card details.
The Administrator will have additional functionalities when compared to the

common user. He can add, delete and update the book details, book categories,

ONLINE BOOK SHOP USE CASE DIAGRAM
ONLINE BOOK SHOP CLASS DIAGRAM

ONLINE BOOK SHOP OBJECT DIAGRAM
ONLINE BOOK SHOP SEQUENCE DIAGRAM

ONLINE BOOK SHOP COLLABORATION DIAGRAM
ONLINE BOOK SHOP ACTIVITY DIAGRAM

ONLINE BOOK SHOP STATE CHART DIAGRAM
ONLINE BOOK SHOP COMPONENT DIAGRAM

ONLINE BOOK SHOP DEPLOYMENT DIAGRAM
4. RAILWAY RESERVATION SYSTEM

OBJECTIVE:
The main objective of our railway reservation system is to serve as a very effective and
premium portal for the reservation of railways.You can know the train timings,train routes,ticket
availability,and much more in just a few clicks.
INFORMATION DESCRIPTION:
DETAILED DESCRIPTION OF PROJECT:
• Search for the required train.

• Check for the availability of the ticket.
• If available reserve the ticket.
• Else search for another train.
HARDWARE DESCRIPTION:
1.Pentium Processor
2. Intel Motherboard
3. RAM 256MB(minimum)
4. Hard disk 40GB(minimum)
SOFTWARE DESCRIPTION:
• Microsoft VisualBasic6.0
• Microsoft Access
• Rational Rose
HUMAN INTERFACE DESCRIPTION:
Interface going to be used is a user friendly interface,it is an online interface which will
satisfy the users needs.
FUNCTIONAL DESCRIPTION:
PERFORMANCE CHARACTERISTICS:
• Fast access
• Easy access for end users.
• Simple steps for reservation and cancellation.
DATABASE REQUIREMENTS:
• Details of Indian trains.

• Fare of trains according to classes.
• Percentage of concessions according to persons such as students,senior citizens
etc..,
• Above database are stored in MS-Access.

NON FUNCTIONAL REQUIREMENTS:
AVAILABILITY:
Available to all systems around the clock.
Available in any environment
Suites for everyone that is no credit card needed.
Just enter the bank name and account no for payment.
MAINTAINABILITY:
Regular updates of database
Backup of database is maintained to avoid the loss of data due
to power failure.
Less memory space required.
BEHAVIOUR DESCRIPTION:
This project has mainly two functions:-
1.Reservation
• Easy and fast steps to reserve a ticket.
• Before reserving we can check the availability,timings etc..,
2.Cancellation
• Easy and few steps to cancel the tickets.
• The money will be automatically refunded in the bank account.
• Specified at the time of reservation.
• The history of reservation is maintained.
RAILWAY RESERVATION SYSTEM USE CASE DIAGRAM

RAILWAY RESERVATION SYSTEM CLASS DIAGRAM
RAILWAY RESERVATION SYSTEM SEQUENCE DIAGRAM

RAILWAY RESERVATION SYSTEM COLLABORATION DIAGRAM
RAILWAY RESERVATION SYSTEM ACTIVITY DIAGRAM

RAILWAY RESERVATION SYSTEM COMPONENT DIAGRAM
RAILWAY RESERVATION SYSTEM DEPLOYMENT DIAGRAM

5. BANKING SYSTEM
Abstract
The Internet era is a period in the information age in which communication and
commerce via the Internet became a central focus for businesses, consumers, government, and the media.
The Internet era also marks the convergence of the computer and communications industries and their
associated services and products. Nowadays, the availability of the Internet make it widely used for
everyday life. In order to led business to success, the business and specially the services should provide
comfort use to its costumer. The bank system is one of the most important businesses who may use the
website. The using for the web-based systems should contain special requirements to achieve the business
goal. Since that the paper will present the functional and non-functional for the web-based banking system.
• A Customer must have a valid User Id and password to login to the system
• If a wrong password is given thrice in succession, that account will be locked and the
customer will not be able to use it.
• When an invalid password is entered a warning is given to the user that his account is
going to get locked.
• After the valid user logs in he is shown the list of accounts he has with the bank.
• iv. On selecting the desired account he is taken to a page which shows the present bal -
ance in that particular account number
• User can request details of the last ‘n’ number of transactions he has performed.
A report can also be taken of this.
• User can make a funds transfer to another account in the same bank. User is provided
with a transaction password which is different from the login password.
• User can transfer funds from his account to any other account with this bank. If the
transaction is successful a notification should appear to the customer, in case it is un-
successful, a proper message should be given to the customer as to why it failed.
• User can request for cheque book/change of address/stop payment of cheques
• User can view his monthly as well as annual statements. He can also take print out of
the same.
BANKING SYSTEM USECASE DIAGRAM

BANKING SYSTEM CLASS DIAGRAM
BANKING SYSTEM OBJECT DIAGRAM

BANKING SYSTEM SEQUENCE DIAGRAM
BANKING SYSTEM COLLABORATION DIAGRAM

BANKING SYSTEM ACTIVITY DIAGRAM
BANKING SYSTEM STATECHART DIAGRAM

BANKING SYSTEM COMPONENT DIAGRAM
BANKING SYSTEM DEPLOYMENT DIAGRAM

Uml Unit-6

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml Unit-6

Uploaded by

Copyright:

Available Formats

RAGHU ENGINEERING COLLEGE(Autonomous)

Dakamarri, Visakhapatnam – 531162

COMPUTER SCIENCE & ENGINEERING

Components and Classes:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

The UML defines five standard stereotypes that apply to components:

executable Specifies a component that may be executed on a node

Common Modeling Techniques:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Modeling Source Code:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Common Modeling Techniques:

Modeling an executable release:

Modeling a physical database:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Nodes and Components:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Modeling the distribution of components:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Common Modeling Techniques:

Modeling a client/server system:

Modeling a fully distributed system:

Symbol Name Description

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Node symbol Represents hardware or software objects, which are of a

Interface symbol Shows input or materials that a component either receives

Port symbol Specifies a separate interaction point between the

Package symbol Groups together multiple elements of the system and is

Note symbol Allows developers to affix a meta-analysis to the

1.ATM( Automatic Teller Machine)

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

ATM USE CASE DIAGRAM

Software used: MICROSOFT VISIO 2003

Usecases: a) Insert card b) Enter pin c) Select transaction d) Balance enquiry

e) Withdraw amount f) Dispensed cash g) Printed receipt

Actors: a) Card holder 1) Saving account 2) Current account

ATM CLASS DIAGRAM

ATM OBJECT DIAGRAM

ATM SEQUENCE DIAGRAM

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

ATM COLLABORATION DIAGRAM

Description: Collaboration diagram is an interaction diagram that emphases the structural

ATM ACTIVITY DIAGRAM

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

ATM COMPONENT DIAGRAM

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

ATM DEPLOYMENT DIAGRAM

Aim: To work with the deployment diagram for ATM machine.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

a. include new books/journals or remove some books from the inventory

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

LIBRARY SYSTEM ACTVITY DIAGRAM

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

3. ONLINE BOOK SHOP

The Administrator will have additional functionalities when compared to the

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

ONLINE BOOK SHOP CLASS DIAGRAM

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

ONLINE BOOK SHOP SEQUENCE DIAGRAM