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).

1 INTRODUCTION
We can check whether that workshop is free or not
Bus depots are considered to be the nuclei of a and then assign a proper type of workshop to it.
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 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 Figure 1 : OPEN Class Framework representing.
computerized display management system. Bus Repair Management System.

Ubiquitous Computing and Communication Journal 1

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.
3. The Bus has to be assigned proper
workshop for repair depending on the
requirement checked at the gate.
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.
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
Ubiquitous Computing and Communication Journal
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.
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. 3 : White Box Sequence Diagram with
necessary interfaces.
2
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.

Ubiquitous Computing and Communication Journal 3