Object-Oriented Technology

Object-oriented technology is revolutionizing GIS. At every turn, from researchers to

salespersons, the buzz words “object-oriented” crop up. But what does object-oriented really
mean? Are there different types? Are there shades of object-oriented-ness? Can a system be
“just a little” object-oriented?
Like most over-used and under-grasped terms, object-oriented has a variety of near religious
interpretations. In reality,

however, there are just three basic forms:

1) Object-Oriented User Interfaces (OOUI)
2)Object-Oriented Programming Systems (OOPS)
3) Object-Oriented Data Base Management (OODBM)
.
OOUI uses “icons” in place of command lines and/or menu selections to launch repetitive
procedures. It’s what used to make a Mac a Mac, and all the other PC’s just techno
frustration.With the advent of Windows ’95, however, OOUI’s have moved from “state of-
the-art” to commonplace. Its objects include all those things on the screen you that drag,
drop, slide, toggle, push and click. On the “desktop” you have cute little sketches including
file folders, program shortcuts, a recycle bin and task bar. In a “dialog box” the basic objects
include the check box, command button, radio (or option) button, slider bar and spinner
button, in addition to the drop-down, edit and list boxes. When activated, these objects allow
you to communicate with computers by point ‘n click, instead of type ‘n retype. Keep in mind
that OOUI defines “a friendly user interface (FUI) as a graphical user interface (GUI)”… yep
you got it again, a phooey-gooey.
In addition to icons, OOUI’s use “glyphs.” These are graphical objects are controlled by
programs to perform specific functions. The best examples of glyphs are in screen savers.
The little dog, man or monster roaming across your screen which “destroys” it (sends it to
black) piece by piece is actually a “screen object” expression of a computer program.

object-oriented. Technically it does, so you had better ask a few more questions to
differentiate the nature and degree of OO-ness. OOPS technology uses “widgets” in the
development of computer code. Visual Basic and Visual C are examples of object oriented
programming systems. These packages allow a programmer to generate code by simply
flowcharting a program’s logic. At each “drafting” step, a widget (flowcharting object) is
moved into place and a dialog box is popped-up. Completion of the dialog box writes the
appropriately coded gibberish defining the step to a file.

Whereas an OOUI dialog box is independent, an OOPS dialog box is one in a linked set of
commands depicted in the flowchart. Most modern GIS display at least a minimal level of
OOPS-ness. By turning on the “command log” or “macro builder,” a series of dialog box
entries can be stored to a file, which in turn, can be rerun to repeat the processing. A robust
OOPS, however, uses rigorous flowcharting structure, rules and mechanics to “graphically”
assemble a computer application. From this perspective, OOPS is an effective programmer’s
tool, as it provides an easier way (thank heavens) to develop fully structured computer
programs.
Last section suggested that there are three basic types of “object-oriented-ness.” the
distinctions between an OOUI (object-oriented user interface) and an OOPS (object oriented
programming system) were tackled. That leaves the third type of “OO-ness,”
object-oriented database management (OODBM, pronounced ooD’BUM) for scrutiny
this time. The OODBM concept provides database procedures for establishing and
relating spatial objects, more generally referred to as “data objects.” Early DBM systems
used “flat files,” which were nothing more than long lists of data. The records, or data items,
were fairly independent (usually just alpha-numerically sorted) and items in separate files
were totally independent. With the advent of “relational databases,” procedures were
developed for robust internal referencing of data items, and more importantly, indexing
among separate data sets. OODBM, the next evolutionary (or quite possibly, revolutionary)
step, extends direct data indexing by establishing procedural rules that relate data. The rules
are used to develop a new database structure that interconnects data entries and greatly
facilitates data queries.
The OODBM rules fall into four, somewhat semantically-challenging categories:
encapsulation, polymorphism, structure, and inheritance. Before we tackle the details, keep
in mind that “object-oriented” is actually a set of ideas about data organization, not software.
It involves coupling of data and the processing procedures that act on it into a single package,
or data object. In an OODBM system, this data/procedure bundle is handled as a single unit;
whereas the data/procedure link in a traditional database system is handled by separate
programs.

Agent-Oriented Technology
Agent-oriented programming (AOP) has been presented by Y. Shoham [Shoham, 1993] as a
specialization of object-oriented programming (OOP). In this context, objects are considered
the base for the design of intelligent agents.
The definition of objects as base for agent design is specially supported by two facts. The
first, agents possess a bounded set of action abilities that can be mapped to a set of objects
classes methods. The second, agents maintain an internal private state known as mental state,
which is equivalent to the internal and private state of the objects.
Far from Shoham's definition, many languages designed for agent programming (i.e.
AgentSpeak [Weerasooriya, 1995], Daisy [Poggi, 1995], Metatem [Fisher, 1994],
CooL [Kolb, 1995]) have been built using concepts from object-oriented paradigm and many
specific agents (such as [Vere, 1990] [Ciancarini, 1997]) have been implemented in object
oriented languages such as C++, Smalltalk or Java.
These experiences of agent language definitions based on concepts of object-orientation and
the development of multi-agent systems using object-oriented languages put in evidence one
limitation in the possibilities for managing mental attitudes. In those experiences, mental
attitudes are manipulated as simple data whose relationships are freely interpreted in decision
algorithms used by agents.
That limitation is imposed by the complexity of relationships among mental attitudes such as
beliefs, goals, preferences, intentions, commitments and possibilities. These relationships
among mental attitudes are exposed in several logic formalisms [Cohen, 1990] [Linder, 1996]
[Huang, 1996]. In spite of these theoretical developments, complex relationships among
mental attitudes are not found in multi-agent developments.
Object-oriented programming resolves the problem that means the hiding of behavior of each
type of agents and administration of private knowledge. On the other hand, logic
programming allows logic clauses being used for representing mental attitudes.
This paper presents two experiences to integrate object-oriented programming and logic
programming as a base for agent development. The next section describes the two basic lines
of integration between object-oriented programming and logic programming. Section 3 shows
the integration between Java and a Prolog interpreter. Section 4 exposes the integration of
Smalltalk and Prolog and an example of agent programming. Finally, at the end of this paper,
the conclusions are presented.

Agent Background
Agents are entities that are designed to run routine(user driven) tasks and to achieve a
proposed setting (or goal) within the context of a specific environment. The difference
between an Agent and a traditional software entity is that the latter just follows its designed
functions, procedures or macros to run deterministic codes. The former incorporates the
ability to practice intelligence by making (autonomous/ semi-autonomous) decisions based on
dynamic runtime situations. There is no universally accepted definition of an Agent.
According to N. R. Jennings [2], autonomy is the central capability of an Agent. More
generally, an Agent is an encapsulated system, which is situated in some environment and is
capable of flexible, autonomous action taken within the environment to meet designed
objectives. There are several application domains of software system functions that are
appropriate for Agent techniques. Jennings and Wooldridge [1] proposed a catalogue to
classify Agent application domains (Table 1). Building industrial-strength applications in a
robust, fault-tolerant and flexible way seems a demanding requirement. Current Object-
Oriented software engineering (SE) processes provide methods and tools for developing
traditional software systems. Standards exist for modeling, analyzing, designing and testing
Object- Oriented software. However, there is no consensus agreement on how to build a
comprehensive Agentoriented system. Because of the intrinsic properties of Agents,
development of Agent systems is a nontrivial task without the necessary infrastructure.
Agent-Oriented SE requires methodologies and tools to encompass steps from problem
realization, requirements analysis, architecture design and implementation. These steps must
be implemented within a life-cycle process including testing, verification, and re-engineering
to ensure the built system is sound.
Concepts & Properties of Agents
Criteria Description
Autonomy An Agent can make decisions on its
own based on inner states without external supervision.
Mental Mechanism An Agent has mechanisms to realize its intentions by achieving
goals.
Adaptation An Agent is flexible enough to adjust its activities according to
dynamically changing environments.
Concurrency An Agent may need to perform multiple tasks concurrently.
Communication There are protocols or mechanisms defined for Agent
interactions.
Collaboration An Agent has methods to cooperate with other Agents to achieve
goals.
Agent Abstraction Methodology has theory to describe Agents using high-level
abstractions.
Agent-oriented The design of methodologies originates from the consideration of
Agent-oriented approaches primarily focused on whether the
methodology addresses Agent-based features during the analysis
and design

Conclusion
Software Agent technology has drawn much attention as the preferred architectural
framework for the design of many distributed software systems. Agent-based systems are
often featured with intelligence, autonomy, and reasoning. Such attributes are quickly
becoming alluring to both legacy and new systems. Agents are building blocks in these
software systems, while combinations of attributes are composed to form the software
entities. The more complex an Agent-based system is, the more sophisticated the
methodology to design such systems must be. At present there are no consensus standards on
how to create Agents or model them in the development process. A study of proposals for
creating Agent-based systems is under way to gain insights on what attributes are useful in
leading to better design methodologies.

In this work, we described agent-based systems as they are used in a variety of application
domains. Since there is no single definition of agents, we described the more commonly
accepted properties of agents. We then described some of the available methodologies and SE
processes for designing agent-oriented software systems. We created a framework for
comparing the available AOSE methodologies. Our framework is based on both SE process
principles and agent characteristics. The evaluation framework is composed of two levels. At
the overview level we evaluate AOSE methodologies to determine whether a criteria have
been met by the methodology. We then proposed questions at the detailed level concerning
logical relationships among criteria, and provide answers as statements for comparison.

References
[1] Jennings, NR and Wooldridge, MJ, "Applications of Intelligent Agents," in Agent
Technology: Foundations,
Applications, and Markets: Springer, 1998, pp. 3-28.
[2] Jennings, NR. "On Agent-based Software Engineering, "Artificial Intelligence, Elsevier,
2000(177): 277-296.