EXPLORING UBIQUITIUOS COMPUTING USING
OPEN FRAMEWORK FOR CONTROLLING BUS DEPOT
Manuj Darbari, Assistant Professor, Department of Information Technology,
BBDNITM, A-649, Indira Nagar, Lucknow, India. email@example.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.
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).
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
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 role and gets a place in the workshop it calls " Reject
various components which interacts in the following New Bus ( ) method as shown in Figure 2.
The modified collaboration diagram represents new
1. When a Bus approaches, the access feature Data and Storage center. It is linked with the
door sends a query to the workshop if storage Id, maintaining the record the Buses Number
the workshop if the workshop is plate which has undergone repair. We can also assign
already having pre-requisite number of a priority list of the buses which are to be taken in by
buses then it is rejected. removing the older buses which are being repaired or
are not at higher priority.
2. When the bus leaves the workshop after
the job is complete the information is This new diagram is more complex because it has a
given to the access door person and the state and manages a collection of records by way of
if a new bus enters for repair it is being Data and Storage centre. By this diagram we are able
allocated the particular workshop. The to observe the use of high level and complex
information console displays the latest communication or intersection obstruction can be
information. easily done in OPEN with collaboration diagrams.
3. The Bus has to be assigned proper At the implementation level the complex interaction
workshop for repair depending on the do not exists as single entity, they are refined split
requirement checked at the gate. and lost in a set of objects that can be distributed
over a network and communicate through low level
These three components interact with the Bus primitives such as remote procedure calls. In this
Depot Management System. In this collaboration paper we propose to manipulate an interaction
diagram [3,4] we have a producer which producer between components as component i.e. to implement
which produces a space in the workshop if it is free an OPEN collaboration into software components.
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 .
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 Fig. 3 : White Box Sequence Diagram with
then calls the new Bus for repair ( ) on the consumer necessary interfaces.
Ubiquitous Computing and Communication Journal 2
The Data and Storage class represents the medium as 5. REFERENCES
a whole. It implements the two interfaces of offered
services. The component playing the consumer and  O.M.G. Unified modeling specification version 1.3 http
producer roles are dependent on one of these  T. Reenskang (2006), Working with objects, Prentice Hall,
interfaces i.e. they are using their services. The USA.
 E. Carion, and A. Benguard (2002)", An architecture and a
listener role must supplement the IListener process for implementing distributed collaboration in 6th
component services in order to be informed of the IEEE Internation Enterprise distributed object computing
conference (EDOC 2002).
change of the number available identifies.  E.P. Anderson and T. Reenskang, "System design by
composing structures of interacting objects", in ECOOP.,
The Data and Storage class manages the of available 2006.
 Kurter, I. : 2003, Model Driven Architecture based XML
producer identifiers (free workshops) and keeps processing, proceedings of ACM symposium on document
reference on the original set. 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.
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.
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