A

Project Report
On
GAS AGENCY MANAGEMENT

Submitted By:
Dipika Ostwal
Reena Ostwal

Submitted To:
Prof. Sumedh Pundkar
 CONTENTS

 Introduction.
 Problem statement for object modeling.
 Analysis of the problem statement.
Identifying the right classes
Identifying the right attributes
Identifying the right associations
 Object model.
 Scenario based on the problem statement.
 Event trace diagram.
 Dynamic state model.
 Data flow model.
INTRODUCTION
INTRODUCTION

As we know that cooking gas is the biggest resource that is supplied throughout
the country, to each and every family. The cooking gas is basically Iso-Butane or Natural
gas and the fact does exist that these resources are non-renewable and there are
possibilities that they may expire some day, if not used properly. Thus managing
consumption of such resources properly is essential.

The firms that supply cooking gas are maintaining all the transactions, related to
the consumption of gas, in registers. Maintaining essential data in registers is inefficient
as there are many disadvantages related to it, such as, data redundancy, data
inconsistency and even data loss. The existence of such system is not helping to manage
consumption of these resources. For example, due to data loss, the monthly report shows
that the consumption is reduced, whereas; actually it might be the opposite. Thus, due to
existence of such system, proper measures cannot be taken. Hence, to overcome the
disadvantages related to the file system, we must go for the database systems for the
management of such important resources. The Database systems are quite stable and due
to its stability correct measures can be taken to manage these resources.

The Gas Agency Management software will try to enhance the present working
conditions related to the consumption of cooking gas. This project will atomize all the
functions performed in an agency. The main objective of this project will be to use the
available stock efficiently and correctly. With the help of this software the circulation of
cooking gas will be uniform in all sectors (i.e. Domestic and commercial sector). Using
advance application software’s, this software will be quite user friendly and thus mistakes
by the operators will be reduced. The software will employ strong database system which
will avoid data related mishaps and provide data consistency. Hence, with the use of this
software, the non-renewable resources can be saved for our generations to come.
PROBLEM STATEMENT
Software designing should be done in such a way that it can manage all the
operations carried out in a Gas Agency and the operators find it user friendly to manage
all the tasks. As previously, all the records were maintained in registers, the software
should have the facility to load the previous records into its database. The software
should manage the database effectively and maintain data consistency.

The software should handle the following operations of the Gas Agency
effectively:

 Consumer Records:

o New consumer details, type of consumer (i.e. Domestic/ Commercial) and

the weight of cylinder opted by the consumer.
o Modifying consumer details.
o Transfer of Consumer account from one region to another.
o Closing of Consumer account.

 Employee Records:

o New employee details and their post in the agency.

o Employee Attendance and their Salary.
o Closing of employee account.

 Stock Records:

o Everyday stock details.

 o Amount of stock delivered and pending.

 Transaction Records:

o Cylinder ordered by a consumer and delivery notification.

o Storing cash memos for each transaction.
o Checking of closed and transferred consumer accounts before issuing a
cylinder.

 Complaint Records:

o New complaint records and allotment of a unique complaint number to

each consumer complaint.
o Notification for solved complaint and remainder for unsolved complaints.
o Type of complaint (Urgent or Not).

 Mechanics and Spare parts Records:

o Mechanics allotment to a particular complaint.

o Total replacements of spare parts done for a complaint and its payment.

The software should be able to generate reports on daily, weekly, monthly and
yearly basis on the above mentioned records, whenever required. Along with the reports
the software should generate payment slips for every order, and the software should also
interface printer for printing all the reports and slips.

Holidays should be considered by the software, not only national holidays but
incidental holidays too, so that no data inconsistency occurs.
 Because of shortage of LPG, the software should issue cylinder to consumer after
21 days of last delivery date of that particular consumer. But the “21 days system” should
not be applicable to urgent users such as Hospitals and Hotels.

The software should handle multi-user environment and the modification of any
sort of data entered, should be done by the administrator of the agency.

The areas under the agency should be divided into area codes, so that the
employees for cylinder delivery are allotted to a particular area code where they have to
deliver cylinders.

Advance search should be provided; this means that an operator must be able to
search a particular record through any of the parameters related to that record. The
software should provide “Help” option, so that a new operator can easily understand the
software

The software should provide IVRS (Integrated Voice Recording System), so that
the consumer can directly book their cylinders and complaints through this system
without the help of operators.

A website for the agency should be developed for online booking of cylinders and
complaints. This website should also provide guidelines and instructions to consumers
under critical situations and accidents related to cylinders.
ANALYSIS
OBJECT MODEL

The object model describes the real world object classes and their relationships with
each other. The main steps involved in designing an object model are as follows:

1. Identify objects, associations and classes.

2. Prepare data dictionary.
3. Identify associations between objects.
4. Identify attributes of objects and links.
5. Organize and simplify object classes using inheritance.
6. Verify that access path exists for likely questions.
7. Group classes into modules.

Identifying object classes

The nouns are extracted from the problem statement (which is application
domain) and are tentatively considered as classes. Therefore the tentative classes for our
system are as follows:-

Redundant classes:
If two classes express the same information, the most descriptive name should be kept.

Irrelevant classes:
If a class is not much related with the system or it doesn’t have a role to play in the
system, these classes are called irrelevant classes and should be eliminated from the
system.
Vague classes:
A class should be specific. Tentative classes that have ill-defined boundaries should be
eliminated.

Attributes:
Classes that are properties of an individual object should be restated as attributes.

Operations:
If a name describes an operation that is applied to the object, then it is not a class. Such
names become the part of the dynamic model.

Roles:
The name of a class should reflect its intrinsic nature and not the role that it plays in an
association.

Implementation constructs:
Constructs extraneous to the real world should be eliminated from the analysis model.
They are usually used in the implementation stage. Processes, the date structures and
algorithms are implementation constructs.

Relevant classes:
Classes that are descriptive by themselves are retained.
Customer Employee Transaction Complain

Mechanics Stock Stock Acquired Locality

Cylinder Charges Unsolved Complain Account Disabled

Transaction Voucher Authority Mechanics Receipt

Holidays Company Information Stock Temp

Reason For Two Transaction Pending Company Account

Employee Area Agency Account Pending Cylinder

Company Product Employees Resigned Delivery Gap

Stock Inventory Consumer

Organization Detail
 Fig. 1 Gas systems classes identified from knowledge of problem domain

Identify and add attributes for objects and links

Eliminate unnecessary and incorrect attributes with the following criteria:

1. Object – if the independent existence of an entity is important, rather than just

its value, then it is an object.

2. Qualifiers – if the value of an attribute depends on particular context, and then

the attributes is stated as Qualifier.

3. Names – A name is an object attribute, when it does not depend on context.

4. Identifiers – Object identifiers are implicit in object models and hence are not
stated.

5. Link attributes – they are stated as an attribute of the link only.

6. Internal values – if an attribute describes the internal state of an object that is

invisible outside the object then it is eliminated from analysis.

7. Final detail – Omit minor attributes that are unlikely to effect from analysis.

Discordant attributes – an attribute that seems completely different from and unrelated to
all other attributes, may indicate a class.
Identifying associations
Any dependency between two or more classes or a reference from one class to
another is an association. Implementation decisions for associations should be made
outside the analysis model. Associations are mainly derived from verb phrases in the
problem statement while some other depends on real world knowledge or assumptions.
These have to be verified with the requestor, as they are not problem statement.

We discard unnecessary and incorrect associations using the following criteria:

1. Associations between eliminated classes.

2. Irrelevant or implementation classes.
3. Actions.
4. Ternary associations.
5. Derived associations.
6. Misnamed associations.
7. Role names.
8. Qualified associations.
9. Multiplicity.
10. Add missing associations.
SCENARIO

1. Gas Agency is formed and it gets its Registration Number.

2. Agency is termed to deliver cylinder to a particular range of area.

3. Agency’s Staff information is added into the system.

4. All the workers are given there respective area code in order to deliver cylinder to
customer.

5. Dealer provides a block of 300 cylinders at the start of every day to Agency.

6. 300 cylinders include all different weights of cylinders.

7. Customer registers themselves to the agency by providing their information.

8. Agency then provide customer with a unique consumer no.

9. Agency also provides optional components to be used with cylinder to customer.

10. Consumer uses that consumer No. to Book Cylinder.

11. Receipt is generated as per the booking.

12. Stock is updated.

13. These receipts are given to workers in order to deliver cylinder.

14. Receipts that are returned by the workers are entered into pending list.

15. Stock is updated.

16. If stock is exhausted the Agency calls up for a special block of cylinder as per the
requirement.

17. At the end of every week, then month and then year Report is generated showing
no. of new connections, no. of cylinders issued, etc.

18. Agency maintains all complaint record.

19. Agency maintains Mechanics work done record.

20. Agency maintains records of those customer who have closed their account with
agency and the same is been then disabled.

21. Agency also provides the transfer voucher for those customers who move out
from their Area.
 EVENT TRACE DIAGRAM

Customer
 Agenc
Distributor Worker
y

Gives
Registration No.

Gives 300 Cylinder

Every Day

Appoints worker

Registers himself

Allocates an area

Fills Registration Form

Gives Consumer No.

Gives Consumer No.

for booking cylinder.

Gives Delivery Date

Gives receipt for delivering cylinder

Delivers cylinder

Pays Money

Gives Money and

Confirmation receipt back

SYMBOLS USED IN STATE DIAGRAMS

 SYMBOL MEANING

USED TO REPRESENT STATES

USED TO REPRESENT START OF

STATES

USED TO REPRESENT
TRANSITION OF STATES

USED TO REPRESENT
CONCURRENCY

USED TO REPRESENT
END OF STATES

Agency is formed
 Do: agency [If applicable] Do: dealer
applies for provides Do: dealer
permit registration no. provides a
span of area

Do: Agency Do: workers in

Do: Agency
starts registering agency is allocated
appoints
customer to a particular area
staff

Customer Registration

Do: Customer [If True]

Do: agency Do: Provides
provides
verifies the consumer
information along
document number
with proofs

Booking of cylinder
 Do: Consumer Do: Consumer
Consumer Do: Previous
gives the number is is
[If Valid]
number booking is
consumer no. to verified
verified verified
book cylinder

[If days > 21 days]

Do: Delivery
date is given Do: Books
to consumer Cylinder

Cylinder Delivery

Do: Area wise Do: Receipt is Do: Worker goes

receipt is generated provided for for delivery
for booked cylinder worker for deliver

[If Customer is not present]

Do: Make that Do: Give back

transaction receipt to
pending agency
Customer Complain

Do: Customer Do: Complain Do: Mechanic

complains is recorded in is sent to solve
agency problem

[If consumer found]

Do: Complaint
solved by mechanic
is recorded

Customer account closing

Do: Customer Do: Agency Do: Customer

request to Checks for handover cylinder
close account its account. to agency

Do: Customer Do: Agency pays Do: Agency

account is deposited amount checks for
closed to customer security deposit
Transfer voucher for customer

Do: Customer Customer is Consumer’s

applies for verified new address is
Transfer voucher verified

Do: Agency of that Do: Customer Do: As per new

area accepts voucher shows transfer address, transfer
& include customer vouchers to new voucher is generated
in their database agency

Customer is
transferred to
new agency
SYMBOLS USED IN FUNCTIONAL DATA FLOW MODELS

SYMBOL MEANING

Represents the events in

the data flow model

Represents the actor in

the data flow model

Shows the direction of

flow of data

Shows the conditional

flow of data

Represents the data

storage present in the
data flow model
SYSTEM DESIGN
SYSTEM DESIGN
System design is a high-level strategy for solving the problem and building a
solution. System design includes decisions about the organization of the system into
subsystems, the allocation of subsystems to hardware and software components, and
major conceptual and policy decisions that form the framework for detailed design. The
overall organization of a system is called the system architecture.

OVERVIEW OF SYSTEM DESIGN

System design is the first design stage in which the basic approach to solving the problem
is selected. During system design, the overall structure and style are decided. The system
architecture is the overall organization of the system into components called subsystems.

The architecture provides the context in which more detailed decisions are made
in later design stages. By making high-level decisions that apply to the entire system, the
system designer partitions the problem into subsystems so that further work can done by
several designers working independently on different subsystems. The system designer
makes the following decisions:-

 Organize the systems into subsystems.

 Identify concurrency inherent in the problem.
 Allocate subsystems to processors and tasks.
 Choose an approach for management of data stores.
 Handle access to global resources.
 Choose the implementation of control in software.
 Handle boundary conditions.
 Set trade-off priorities.

BREAKING THE SYSTEMS INTO SUBSYSTEMS

 The first step in system design is to divide the system into a small number of
components. Each major component of the system is called the subsystem. Each
subsystem encompasses aspects of the system that share some common property.
A subsystem is not an object or a function but a package of classes, associations,
operations, events, and constraints that are interrelated and that have a reasonably well-
defined and small interface with other subsystems. A subsystem is usually identified by
the services it provides. A service is a group of related functions that share common
purpose, such as I/O processing, drawing pictures, or performing arithmetic. A subsystem
defines a coherent way of looking at one aspect of the problem.
Each subsystem has a well-defined interface to the rest of the system. The interface
specifies the form of all interactions and the information flow across subsystem
boundaries but does not specify how the subsystem is implemented internally. Each
subsystem can then be designed independently without affecting others.
The relationship between two subsystems can be client-supplier or peer-to-peer. In a
client-supplier relationship, the client calls on the supplier, this performs some service
and replies with the result. The client must know the interface of the supplier, but the
supplier does not have to the interfaces of its clients because all the interactions are
initiated by clients using the supplier’s interface.
The gas agency system comprises of the following subsystems:
 Booking of cylinder: This subsystem comprises of the details of cylinders
booked by the customers with their consumer number. The cylinder is booked
for any customer only after the 21 days of delivery of previously booked
cylinder.
 Delivery of cylinder: This subsystem contains the list of the cylinders
delivered with the date and consumer no. of customer. This system is used to
see the data of delivery when consumer books another cylinder.
 Transfer: This subsystem evolves around the procedure followed during as
well as after the transfer of an employee or customer.
  Employee: This subsystem contains the details of employee, the post at which
the employee is working and the details of locality allocated to the employee.

LAYERS
A layered system is an ordered set of virtual words, each built in terms of the ones
below it and providing the basis of implementation for the ones above it. The objects in
each layer can be independent although there is often some correspondence between
objects in different layers. A subsystem knows about the layers below it, but has no
knowledge of the systems above it. Layer architectures come in two forms: closed and
open. In a closed architecture each layer is built in terms of the immediate lower layer. In
an open architecture, a layer can use features of any lower layer to any depth. We have
used the ‘Open Architecture’ to design our system.

PARTITIONS
Partitions vertically divide a system into several independent or weakly-coupled
subsystems, each providing one kind of service. The subsystems may have some
knowledge of each other.
A system can be successfully decomposed into subsystems using both layers and
partitions in various possible combinations. Layers can be partitioned and partitions can
be layered.

IDENTIFYING CONCURRENCY
In the analysis model as ion the real world and in hardware, all objects are concurrent.
In an implementation, however, not all software objects are concurrent because one
processor may support many objects. In practice, many objects can be implemented on a
single processor if the objects cannot be active together. One important goal of system
design is to identify which objects must be active concurrently and which objects have
activity that is mutually exclusive. The latter objects can be folded together in a single
thread of control, or tasks.
IDENTIFYING INHERENT CONCURRENCY
The dynamic model is guide to identifying concurrency. Two objects are inherently
concurrent if they can receive events at the same time without interacting. If the events
are unsynchronized the objects cannot be folded on to a single thread of control. For
example, the engine and the wing controls on an airplane must operate concurrently (if
not completely independently). Independent systems are desirable because they can be
assigned to different hardware units without any communication cost.
Two subsystems that are inherently concurrent need not necessarily are implemented
as separate hardware units. The purpose of hardware interrupts operating systems and
tasking mechanisms is to stimulate logical concurrency in a uniprocessor. Physically
concurrent input must of course be processed by separate sensors if there is no timing
constraints on response then a multitasking operating system can handle the computation.
Often the problem statements specify that objects must be implemented at distant
hardware units.

DEFINING CONCURRENT TASKS

Although all objects are conceptually concurrent, in practice many objects in a system
are independent. By examining the state diagrams of individual objects and the exchange
of events among them, many objects can often be folded together into a single thread of
control. A thread of control is a path through a set of state diagrams on which a single
object at a time is active. A thread of control is a path through a set of state diagrams on
which a single object at a time is active. A thread remains within a state diagram until an
object sends an event to another object and waits for another event. The thread passes o
the receiver of the event until it eventually returns to the original object. The thread splits
if the object sends an event and continues executing.
On each thread of control, only a single object at a time is active. Threads of control
are implemented as tasks in computer systems.
MANAGEMENT OF DATA STORE
The internal and external data stores in a system provide clean separation points
between subsystems with well-defined interfaces. In general each data store may combine
data structures, files, and databases implemented in memory or on secondary storage
devices.
The kind of data that belongs in a formal database:
1. Data that requires access at fine levels of details by multiple users.
2. Data that can be efficiently managed with DBMS commands.
3. Data that must port across many hardware and operating system platforms.
4. Data that must be accessible by more than one application program.
The databases that are used in the functional data flow diagram for gas agency
are:
 Company’s database.
 Customer details.
 Employee details.
 Deliveries of cylinder.

HANDLING GLOBAL RESOURCES

The system designer must identify global resources and determine mechanics for
controlling access to them. Global resources include: physical units, such as processors,
tape drives, and communication satellites: space, such as disk space, a workstation
screen, and the buttons on a mouse; logical names, such as object Ids, filenames, and
class names; and access to shared data, such as databases.
DFD for Transfer Voucher
DFD for Closing of Customer Account
DFD for Booking Cylinder
DFD for Stock Process
DFD For Complain Process
OBJECT DESIGN
OBJECT DESIGN
The object design phase determines the full definitions of the classes and associations
used in the implementations, as well as the interfaces and algorithms of the methods used
to implement operations. The object design phase optimizes data structures and
algorithms.

OVERVIEW OF OBJECT DESIGN

During object design we carry out the strategy chosen during system design and flesh
out details. There is a shift in emphasis from application domain concepts to computer
concepts. We must choose among different ways to implement the objects discovered
during analysis keeping in mind factors like minimizing execution time, memory and
other measures of cost. The operations identified during analysis must be expressed as
algorithms with complex operation decomposed into simpler internal operations. The
classes, attributes and associations from analysis must be implemented data structures.

STEPS FOR OBJECT DESIGN

During object design we perform the following steps:-
 Combine the three models to obtain operations on classes.
 Design algorithms to implement operations.
 Optimize access paths to the data.
 Implement control for external interaction.
 Adjust class structure to increase inheritance.
 Design associations.
 Determine object representation.
 Package classes and associations into modules.
COMBINING THE THREE MODELS
After analysis we have the object, dynamic and functional model. But the object
model is the main framework around which design is constructed. The object model from
analysis does not show operations. We convert the actions and activities of the dynamic
model and processes of the functional model into operations attached to the classes in the
object model. We begin mapping the logical structure of the analysis model into a
physical organization of a program.

DESIGNING ALGORITHMS
Each operation specified in the functional model can be formulated as a functional
model. The analysis specification tells what the operation does from the viewpoint of its
client, but the algorithm shows how it is done.
As algorithm designer we must:
 Choose algorithm that minimize the cost of implementing operations.
 Select data structures appropriate to the algorithms.
 Define new internal classes and operations as necessary.
 Assign responsibility for operations to appropriate classes.

CHOOSING ALGORITHM
Many operations are simple enough that the specification in the functional model
already constitutes a satisfactory algorithm, because the description of what is done also
shows how it is done. Most functions are simple mathematical or procedural definitions.
Often the simple definition is the best algorithm for computing the function. While in
some cases the simple definition of an operation is hopelessly inefficient and must be
implemented with a more efficient algorithm.
We choose the algorithm based on the following factors:-
 Computational complexity.
 Ease of implementation and understandability.
 Flexibility.

 Fine tuning the object model.

CHOOSING DATA STRUCTURES
Choosing algorithms involves choosing the data structures they work on. During
object design we must choose the form of the data structures that will permit efficient
algorithms. We may use generic data structures provided by C++ for implementing the
algorithms required in the library.
The dictionary of the computer is implemented using an array of objects (with array name
keys) of the class dictionary. Class dictionary has data members keyword and info. The
member keyword of each array object is initialized with the keywords available and the
member info is initialized with the corresponding information about the keyword.
Fig: Object model for Gas Agency Management