To design “non intrusive” systems, both for
users (with different roles: system developers,
system configurators and end-users), we
propose a framework of “wise objects” from
which a system inherits its “wisdom”;
Each system entity inheriting from Wise Object
(WO) class will have the ability to learn on
itself and on its usage by others.
In the system a particular object called
Assembly Object is in charge of putting together
individual WOs behaviours. A WO instance
does not know the other WO instances in the
decentralized system.
As already said, a Wise Object (WO) is an object
that knows itself by its own, i.e. its knowledge is not
obtained from an external database. This acquisition
is performed by introspection and monitoring.
As depicted by Figure 1, a WO life-cycle
involves two main steps: Configuration and
Operation. When an instance of WO Class is created
the object has no knowledge about the services it is
expected to provide.
At Configuration step, a WO acquires
knowledge about its capabilities (i.e. services
implemented as methods) thanks to introspection
mechanisms we defined in WO class. Thus, a WO
object discovers services it is intended to offer and
constructs a behaviour graph of all its possible states
and all its possible transitions when it invokes those
services. Transitions in the behaviour graph
correspond to the object method invocations. A WO
object can easily obtain the set of its methods by
introspection. A state in the graph behaviour is
defined by the attribute values of the object. When a
WO instance is created, the object is in its initial
state. The other states are computed by method
invocation. Each invocation can move the object
into a new state or let the object into its current state.
When all methods are invoked on all known states,
the behaviour graph is considered as complete. What
is worth noting here is that in “Learning on itself”
sub state, a WO is able to act in an autonomous way,
i.e. with no external interaction. This results a
behaviour graph that could be either incomplete (e.g.
because it requires external information) or not valid
(e.g. because some transitions are not realistic). A
“validation” sub state involving users is required for
those reasons. This sub state is in particular
necessary for assembling behaviour graphs of
system WO instances. Indeed up to now, a WO
instance has learnt only about its behaviour.
In addition to WO objects, we designed an
Assembly Object that puts together graph
behaviours of participating WO instances. An
Assembly Object assembles behaviour graphs in a
way similar to process composition in FSP (Finite
State Processes) algebra (Magee and Kramer, 2006).
In a system at work, each service invocation is
followed by the requested service delivery (i.e.
executing the corresponding object method). We
then can view object method execution as an atomic
action, and, coordination among concurrent WO
instances as a composition of their behaviour graphs
from a process perspective (i.e. ordering constraints
on object method execution). It is in the charge of
the system configurator to define the valid
“assembly” or coordination rules. In our illustrating
example, System configurator defines the following
rule: a switch on must be followed by shutter roll
down. According to this rule, the Assembly Object
deactivates all transitions that do not conform to the
expected rules.
When the Operation step starts, a WO instance is
ready to learn about its usage. It collects data
(Collecting usage data) each time a service is
invoked. Those data correspond to the statistics on
state changes or the discrete-time Markov chain of
the usage. As the behaviour graph is known
(Configuration step), the Markov chain is computed
by monitoring method invocations on the object.
This computation is done by the WO instance when
it is in idle, i.e. it is not executing a service
(Learning on its usage). In this step, when an
uncommon case occurs (e.g. a service that has never
been invoked by a user before), the WO instance
handles this situation in the Managing emotion sub
state. The word “emotion” is another metaphor to
qualify unusual situations.
Up to now, we considered atomic objects (i.e.
not composed of other objects). One more important
issue is then: in a hierarchical system of WOs (i.e. a
WO composed of WOs), how can knowledge from
low-level WOs be managed by high-level WOs? The
amount of knowledge can be important but not
always relevant to high-level WOs, in particular if
this does not bring new information. Thus, it is more
relevant for the system to translate knowledge from
low to high-level WO only if knowledge evolves or
if the usage of WO changes. If we consider that the
capabilities of a WO cannot change, two questions
are raised:
• how can a WO detect a change on its usage?
• is this change relevant to the high-level WO?
We see the former as a fuzzy problem where the
change can be expressed as a distance to a common
usage reference. Regarding the second question, we
consider that a low-level WO cannot “say” if a
change on its usage has an impact on its high-level
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
470