Ubiquitous Computing and Communication Journal

EXPLORING UBIQUITIUOS COMPUTING USING OPEN

FRAMEWORK FOR CONTROLLING BUS DEPOT
MANGEMENT
Manuj Darbari, Assistant Professor, Department of Information Technology,
BBDNITM, A-649, Indira Nagar, Lucknow, India. manujuma@rediffmail.com
Dr. Bhaskar Karn, Coordinator, Department of Information Science,
Birla Institute of Technology, Mesra. Ranchi,India.
Dr.Sayed Sayeed Ahmad, Assistant Professor, College of Information Technology,
The Kingdom University, The Kingdom of Bahrain.
Vivek Kr. Singh, Assistant Professor, Department of Computer Science & Engg.,
BBDNITM, 628 / 40C, Shakti Nagar, Lucknow,India.

ABSTRACT
In this paper we have suggested a scientific procedure of exploring ubiquitious
computing for management of urban bus depot using OPEN collaboration
diagrams. The paper also discusses the extension of interaction components in a
distributed framework for both the specifications and implementations level
modeling of Bus Depot, by taking the case study of Lucknow Bus Depot.

Keywords: Object Process Environment Notation (OPEN).

INTRODUCTION

Bus depots are considered to be the nuclei of a

transport organization as they are the most preferred
means of traveling. All the activities relating to bus
operation and maintenance in transport undertakings
are carried out through the functional hinges called
"BUS DEPOTS" . The basis function of Bus depot is
to provide maintenance and repair of buses. In this
paper we propose to reify open collaboration into
interaction components, in such a way that
collaboration can be thought of as both a design level
components and an implementation level component.
These components are designed to handle high level
interaction obstructions throughout the software
process.
2

We can check whether that workshop is free or not

and then assign a proper type of workshop to it.

BUS DEPOT MANAGEMENT

The main focus in this section is on the

OML[1,3] collaboration used in the application. Bus
depot consist of various types of workshops for
repair and maintenance of the bus. There has to be a
proper workshop assigned to bus depending upon the
need of repair it wants. Considering a fully
computerized display management system.

Volume 3 Number 3

Page 65

Figure 1 : OPEN Class Framework representing.

Bus Repair Management System.

www.ubicc.org

Ubiquitous Computing and Communication Journal

The figure shows the bus repair workshop having

various components which interacts in the following
manner:
1.

When a Bus approaches, the access

door sends a query to the workshop if
the workshop if the workshop is
already having pre-requisite number of
buses then it is rejected.

2.

When the bus leaves the workshop after

the job is complete the information is
given to the access door person and the
if a new bus enters for repair it is being
allocated the particular workshop. The
information console displays the latest
information.
The Bus has to be assigned proper
workshop for repair depending on the
requirement checked at the gate.

3.

role and gets a place in the workshop it calls " Reject

New Bus ( ) method as shown in Figure 2.
The modified collaboration diagram represents new
feature Data and Storage center. It is linked with the
storage Id, maintaining the record the Buses Number
plate which has undergone repair. We can also assign
a priority list of the buses which are to be taken in by
removing the older buses which are being repaired or
are not at higher priority.
This new diagram is more complex because it has a
state and manages a collection of records by way of
Data and Storage centre. By this diagram we are able
to observe the use of high level and complex
communication or intersection obstruction can be
easily done in OPEN with collaboration diagrams.
At the implementation level the complex interaction
do not exists as single entity, they are refined split
and lost in a set of objects that can be distributed
over a network and communicate through low level
primitives such as remote procedure calls. In this
paper we propose to manipulate an interaction
between components as component i.e. to implement
an OPEN collaboration into software components.

These three components interact with the Bus

Depot Management System. In this collaboration
diagram [3,4] we have a producer which producer
which produces a space in the workshop if it is free
otherwise reject it. The display plays the role of a
listener as it listen the workshop status.

The collaboration diagram contains all the roles that

can be played by the components, a class
representing the medium and all the elements
necessary to describe the behavior of the medium
and its services.
For each role, the class representing the medium in
the collaboration implements an interface containing
the services offered to the components playing this
role. A "Role Name" role implements an interface
providing the services the medium would call back.
The final messages representing interaction resulting
from a service call be added onto the collaboration
diagram. The structural White Box Sequence
Diagram with necessary interfaces is shown in Fig. 3.

Fig. 2 : Modified Collaboration Diagram

3. DYNAMICCOLLABORATION SEQUENCES
OF A BUS DEPOT
From the above roles assigned we can create a
dynamic collaboration diagram [2].
The first window has a simple specification of the
collaboration diagram. The collaboration sequence is
very simple. If a producer wants to fix a workshop
then calls the new Bus for repair ( ) on the consumer

Volume 3 Number 3

Page

Fig. 3 : White Box Sequence Diagram with

necessary interfaces.

66

www.ubicc.org

Ubiquitous Computing and Communication Journal

The Data and Storage class represents the medium as

a whole. It implements the two interfaces of offered
services. The component playing the consumer and
producer roles are dependent on one of these
interfaces i.e. they are using their services. The
listener role must supplement the IListener[5]
component services in order to be informed of the
change of the number available identifies.
The Data and Storage class manages the of available
producer identifiers (free workshops) and keeps
reference on the original set.

5. REFERENCES
[1] O.M.G. Unified modeling specification version 1.3 http
://www.omg.org..
[2] T. Reenskang (2006), Working with objects, Prentice Hall,
USA.
[3] E. Carion, and A. Benguard (2002)", An architecture and a
process for implementing distributed collaboration in 6th
IEEE Internation Enterprise distributed object computing
conference (EDOC 2002).
[4] E.P. Anderson and T. Reenskang, "System design by
composing structures of interacting objects", in ECOOP.,
2006.
[5] Kurter, I. : 2003, Model Driven Architecture based XML
processing, proceedings of ACM symposium on document
engineering, frame.

The multiplicity of the links between a Role and

Data and Storage medium class on the role side
allows the number of role instantiated.
A type specification is the definition of a set of
services and their semantics. All features and
attribute that are necessary for specifying the
services must be added in a static diagram associated
with this type. A component implements one or
several types. These types are defined at an abstract
level without any assumptions about implementation.
In the cease of our bus deport management the
collaborations are used to produce identifiers. A
producer component calls a producer services the
service and it belongs to the type specification. This
process allows us to place the identifier set inside the
medium, but we have shown it as an external agent.
4. CONCLUSION
At the conclusion we would like to sum up that our
paper has presented an approach to reify high-level
interactions abstraction into fully developed software
components. We have briefly described about the
medium specification methodology, but this
methodology is involved in a more global process
allowing the manipulation and the reutilization of
high level interaction obstruction throughout the
software process, from analysis to implementation
and deployment. This work can be further extended
for Real Time Software Development where the
medium and components can be shown by the help
of enhanced collaboration diagrams.

ACKNOWLEDGEMENT
We would like to thank U.P.S.R.T.C, Lucknow for
their cooperation in providing the necessary details
about Bus Depot.

Volume 3 Number 3

Page 67

www.ubicc.org