Lake Tana Two Tier Operations Research Transport ...

International Journal of Earth Sciences and Engineering ISSN 0974-5904, Volume 04, No 06 SPL, October 2011, pp 381-384

381

Lake Tana Two Tier Operations Research Transport Model-XY2T -a Framework of Design Patterns Yonas Mitiku Degu Director, School of Mechanical and Industrial Engineering, Institute of Technology, Bahir Dar University, Bahir Dar, Ethiopia, Email: [email protected]

S. P. Chary Professor, School of Mechanical and Industrial Engineering, Institute of Technology, Bahir Dar University, Bahir Dar, Ethiopia, Email: [email protected]

ABSTRACT: The present article depicts the Operations research (OR) model for the Lake Tana transport system consisting of multiple ports and multiple routes connecting the various islands within the lake. Lake Tana, the source of Blue Nile in Ethiopia, significantly contributes to the livelihood of people in the islands and peninsular towns around the lake. Building a well-developed OR transport model with multiple ports along the shore of the lake and on the islands within the lake is crucial for the water transport system across the lake. The main constraints in the problem are changing wind resistance, islands coming in the route and the additional drag due to the waves on the lake. OR is a scientific method of providing practical solutions with a qualitative and quantitative basis for decision making regarding the water transportation problem on hand. X,Y coordinates parallel to latitude and longitude at the global level and area coordinates at the local level are used to describe Lake Tana for building OR transport Model-XY2T,which implies a two dimensional model intended to cover both tourist and transport requirements since it is being built for a developing tourist destiny. Through GPS the global coordinates of the ports and vessels cruising in the lake are obtained and the local co-ordinates of each vessel moving in the lake are calculated with respect to the ports around in the locality. A framework of Design Patterns describing the OR Model-XY2T is envisaged to model, view and control vehicular traffic. KEY WORDS: OR Model, Transport Management, Framework of Design Patterns, Development Planning, Lake Tana

INTRODUCTION The operations research model for the Lake Tana water transport system is built based upon the qualitative and quantitative information obtained through the global positioning system (GPS) continuously updated both for the location of the ports and the cruising vessels in the lake. The qualitative information in terms of the longitude and latitude of the ports on the shore and on the islands as well as the quantitative information regarding the location of the vessels cruising in the lake are obtained by observation and the subsequent calculation of the area coordinates relative to the chosen ports around the cruising vessel. The OR model is named as XY2T to indicate that it is a two dimensional model expressed in terms of the co-ordinate system describing at the global and local levels. For the sake of clarity and generality, Design Patterns are chosen in describing OR Model-XY2T to identify the relevant Framework of Design Patterns [1]. The Model-View-Controller (MVC) triad of classes consists of three kinds of objects [2, 3]. The Model is the application object, the View is its screen presentation and the Controller defines the way the user interface reacts to user input. MVC decouples views and models by establishing a subscribe/notify protocol between them. A View must ensure that its appearance reflects the state of the model. Whenever the model’s data changes, the model notifies the views that depend on it. In response, each view gets an opportunity to update itself. This approach enables us attach multiple views to a model to provide different presentations. We can also create new views for a model without rewriting it. The model communicates with its views when its values change and the views communicate with model to access these values.

Decoupling of the objects is achieved such that changes to one can affect any number of others without requiring the changed object to know the details of the others. This more general design is described by the Observer Design Pattern. Another feature of MVC is that views can be nested. MVC supports nested views with composite view class, which is a sub-class of view. Composite view objects act just like view objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views. Whenever we want to group objects and treat the group like an individual object, a more general design described by the Composite can be used. MVC enable us to change the way a view responds user input without changing its visual presentation. MVC encapsulates the response mechanism in a controller object. There is class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one. A view uses an instance of a controller subclass to implement a particular response; to implement a different strategy, simply replace the instance with different kind of controller. It is even possible to change a view’s controller at run-time to let the view change the way it responds to user input. The View–Controller relationship is an example of Strategy Design Pattern. A Strategy is an object that represents an algorithm. It is useful when we want to replace the algorithm either statically or dynamically, or when we have a lot of variants of the algorithm. MVC uses other Design Patterns such as Factory Method to specify the default controller class for a view and Decorator to add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy Design Patterns.

#020410234 Copyright © 2011 CAFET-INNOVA TECHNICAL SOCIETY. All rights reserved

382

Yonas Mitiku Degu, S. P. Chary

DESIGN PATTERNS RELEVANT TO LAKE TANA TRANSPORT SYSTEM Object oriented programs are made up of objects. An object packages both data and procedures that operate on the data. Requests are the only ways to get an object to execute operations to change an object’s internal data. Because of these restrictions, the object’ internal state is said to be encapsulated. It cannot be accessed directly and its representation is invisible from outside the object. In the Lake Tana transport model, the ports on the islands and on the shore as well as the vessels moving in the lake or harboured in the ports are the only obvious objects. The tourists can be found either in the ports on the island or on the shore or in the vessels moving in the lake or harboured in the lake. In the OR Transport Model-XY2T, we focus on the collaborations and responsibilities between the ports and the vessels in facilitating the exchange of the tourists between them to promote the tourism activities. Design Patterns help us to identify the less obvious abstractions and the objects that can capture them. Objects that represent a process or algorithm can be a crucial part in promoting the tourist activity design and development. The Strategy Pattern describes how to implement interchangeable families of algorithms like the description of the tourist vessel route to be followed. The State Pattern represents each state of an entity as an object like the instantaneous position of a tourist vessel in the lake. These objects are seldom found during the analysis or even in the early stages of the design; they are rediscovered later in the course of making the design more flexible and reusable. When a request is send to an object, the particular operation that is performed depends up on both the request and the receiving object. Different objects that support identical request may have different implementations of the operations that fulfil the requests. The runt-time association of a request to an object and one of its operations like embarking and disembarking of the tourist from the tourist vessels is known as dynamic binding. Dynamic binding means that issuing a request does not commit as to a particular implementation until run-time. Moreover dynamic binding lets us substitute objects that have identical interfaces for each other at runtime. This substitutability is known as polymorphism and it is a key concept in object oriented system. Polymorphism specifies the definition of the clients decouples the objects from each other and even vary their relationship at run-time. Specifying Object Implementations Object implementations are defined by its class. The class specifies the object internal data representations and defines the operations the object can perform. Objects are created by instantiating. The object is said to be an instance of a class the process of instantiating a class allocates storages for the object internal data which is made of instance variables and associate the operations with these data. Many similar instances of an object can be created by instantiating a class such as hovercraft as a modern transport facility that can be a tourist attraction.

New classes can be defined in terms of the existing classes using class inheritance. Class inheritance enables us to define classes simply by extending other classes, making it easy to define families of object having related functionality. When a sub-class inherits from a parent class it includes the definitions all the data operations defined by the parent data. Object that instances of the sub-class will contain all data define by the sub class and its parent classes and they will be able to perform all operations defined by these sub class and its sub parent. An abstract class is one whose main purpose is to define a common interface for its sub classes. It will differ some or all of its implementations to operations defined in sub classes; hence an abstract class cannot be instantiated. The operations that an abstract class declares but does not implement are called abstract operations. Classes that are not abstract are called concrete classes. Sub-classes refine and redefine the behaviours of their parent classes. More specifically a class my override an operation defined by its parent class. Overriding gives sub classes a chance to handle request instead of their parent classes. The names of abstract classes appeared in slanted type to distinguish them from concrete classes. Class Verses Interface Inheritance An object’s class defines how the object is implemented. The class defines the objects internal states and the implementation of its operations. In contrast, an object type only refers to its interface the set of request to which it can respond. An object can have many types and objects of different classes can have the same type such as the classification of the type of accommodation on different tourist vessels. Because a class defines the operations an object can perform, it also defines the objects type. When we say that an object is instance of a class, we imply the object supports the interface defined by the class. Sending a message requires checking that the classes of receiver implement the message but it does not require checking that the receiver is an instance of a particular class. For example to facilitate embarking of tourists at a particular port requires to know weather there is accommodation on a particular type of vessel and weather the chosen vessel stops at a particular port or not. In the composite pattern, component defines a common interface but composite often describe a common implementations. Command, observer, state and strategy are often implemented with the abstract classes that are pure interfaces. Class inheritance is basically just a mechanism for extending application functionality by reusing functionality in parent classes. It enables to define a new kind of object rapidly in terms of an old one. It enables us to get new implementations almost free inheriting most of what we need from existing classes. These facilitate the private sector participation in tourism industry introducing more and more attractive facilities which can be inherited from the existing vessels in use in Lake Tana transport system promoting competition and efficient operation in the transport system in Lake Tana and its surroundings.


Lake Tana Two Tier Operations Research Transport Model-XY2T-a Framework of Design Patterns Application Programs and Frameworks While building an application program the internal reuse, maintainability and extension are high priorities. A Framework is a set of cooperating classes that make up a reusable design for specific class of software. The Framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse. It is imperative to design the Framework to be as flexible and extensible as possible. As a Framework evolves, applications have to follow it. Mature Frameworks usually incorporate several Design Patterns which help to make the Framework’s architecture more suitable for many applications without redesign. Design Patterns are more abstract and less specialised than Frameworks. Design Patterns are smaller architectural elements than Frameworks.

Creational Patterns These give us a lot of flexibility in what gets created, who creates it, how it gets created and when. A class creational pattern uses inheritance to vary the class that is instantiated whereas an object creational pattern will delegate instantiation to another object. They enable us to vary configuration with the product object that vary widely in structure and functionality. We can choose a ship, hovercraft are even an amphibian aircraft as the medium of transport which will determine the nature of the grid of triangles covering the lake to facilitate the transport of man and material across the lake. The other types of Design Patterns are Structural and Behavioural Patterns. Table-1 Design aspects allowed by Design Patterns [1] Design Pattern Creational Patterns

Abstract factory Builder Factory method Prototype

Struc

Singleton Adapter Bridge

Aspects that Can Vary Families of product objects How a composite object gets created Sub-class of object that is instantiated Class of object that is instantiated The sole instance of a class Interface to an object Implementation of an object

Decorator Facade Flyweight Proxy Chain of responsibility Command Behavioural Patterns

Encapsulating Variation This is a theme of many behavioural patterns. The patterns usually define an abstract class that describes the encapsulating object and the pattern derives its name from that object. A strategy object encapsulates an algorithm. A state object encapsulates a state-dependent behaviour. A mediator object encapsulates the protocol between objects. An iterator object encapsulates the way you access and traverse the components of an aggregate object. These patterns describe aspects of a program that are likely to change. Chain of responsibility pattern deals with arbitrary number of objects, which may be already exist in the system.

Composite

Interpreter Iterator Mediator Memento Observer State Strategy Template method Visitor

383

Structure and composition of an object Responsibilities of object without sub-classing Interface to a sub-system Storage costs of objects How an object is accessed and its location Object that fulfill a request When and how a request is fulfilled Grammar interpretation of a language How aggregate’s elements are accessed or traversed How and which objects interact with each other What information is stored outside an object and when How dependent objects stay up to date States of an object An algorithm Steps of an algorithm Operations that can be applied to objects without changing their classes

Designing for Change The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements and in designing such transport system like that of Lake Tana so that, it can evolve accordingly as the tourism picks up. A design that does not take change into consideration risks major redesign in future. Design Patterns help us avoid this by ensuring that a system can change in specific ways. Each Design Pattern lets some aspect of the system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change. These patterns describe features of the program that are likely to change. Most patterns have two kinds of objects namely the new objects that encapsulate the aspect, and the existing objects that use these new objects. Composite Pattern Compose objects into tree structures to represent partwhole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. The user can group components to form larger components, which in turn can be grouped to form still bigger components. The key to composite pattern is an abstract class that represents both primitives and their containers. The composite pattern defines class hierarchies consisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects which in turn can be composed and so on recursively.


384

Yonas Mitiku Degu, S. P. Chary

Y

CONCLUSIONS

B

The present paper aims at connecting the OR-Transport Model with the Design Patterns for the sake of clarity and generality. The XY coordinates together with the area coordinates calculated from the GPS location of the ports and the cruising vessels form the OR Model-XY2T. We depict the sailing vessel by a point moving on the map of Lake Tana following the principles of particle dynamics. The instantaneous position of a cruising vessel in the lake is given by a point. State pattern gives its GPS coordinates XY. The subsequent positions it occupies while cruising are described by path. The path is determined by the Strategy Pattern. The MVC pattern conveys this information to the different ports in the lake to coordinate the tourist traffic. Area coordinates calculated from the GPS locations of the cruising vessel and the surrounding ports determine the vessel movement in the lake relative to the surrounding ports. The origin of the coordinate system XY can be located somewhere nearer to the Deck Island in the Lake Tana. The coordinates XY are parallel to the latitudes and longitudes in the area. The advantage of using a ship is it can transport man and material simultaneously. The hovercraft has got the advantage because of its amphibian nature it need not depend upon a ready made port on the shore or on the island for a transporting either man or material. If we go for an amphibian aircraft as a mode of conveyance for transport the limitation imposed by the island in lake as obstruction on the shortest path chosen and the necessity to depend upon the runway of the aerodrome it can land or take off from the surface of the lake itself.

I

II

O

x

III

IV

Fig. 1 (a) Lake Tana

a

o c

C

A b Fig. 1 (b) Area Coordinates x, y, z

Where A’ = (A + B + C) which is the total area a, b, c are the ports and o is the cursing vessel x = A/A’; y = B/A’; z = C/A’ Design Space Identifies the key functional and structural dimensions used to create a system design in a specific application domain. Design space dimensions describe aspects of the problem space as functional and performance related design alternatives, while structural dimensions describe the solution space as a set of alternative implementation characteristics. Lake Tana can be covered through Google wave like infrastructure to form wide area network. Quantified Design Space Software artefact is only the last step in the process of creating a product [3]. Software can only be as good as the design model from which it is produced. To have flexible, reusable, robust and extensible software, OR ModelXY2T is being expressed as a frame work of design patterns which draw their basic input coordinates from global positioning system (GPS) coordinates and the derived area coordinates of the cursing vessel in the lake to develop a software product that can match growing needs of Lake Tana transport system.

REFERENCES

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlssides,1995 “Design Patterns: Elements of Reusable Object-Oriented Software”, an imprint of Addison Wesley Longman, Inc., First ISE reprint,1998 [2] Glenn E. Krasner and Stephen T. Pope. “A Cookbook for Using the Model View Controller User Interface Paradigm in Smalltalck-80” Journal of Object Oriented Programming, 1(3):26-49, August /September, 1988 [3] Mary Shaw and David Garlan, “Software Architecture Perspectives on an Emerging [4] Discipline”, Prentice –Hall of India (1996, 2005)
