Smart Internet Architecture Project
According to the Collins English Dictionary architecture
can mean structure or design of anything. It is a term used loosely
when describing anything that requires some thought or effort
concerning an ultimate system structure. If the various experiments
and technologies being researched within Smart Internet are ever
going to be able to contribute to some overall system offering
then some serious architectural work has to ensue.
Determining the architecture of a system involves understanding
the functional requirements and various “quality attributes”
that the system must meet. The quality attributes are also requirements,
but they are often stated in somewhat imprecise form such as “the
system will be built to the highest possible quality” or
“the system must be very adaptable”. Within the various
Smart Internet project descriptions there are lots of requirements
of this nature. Some are - mobility, adaptability, usability,
flexibility, integrability, trainability, robustness, stability,
safety, configurability. Most of these words conjure up certain
ideas/assumptions, but unless described properly can easily be
interpreted differently to what might have been intended.
Before determining an architecture, an architect needs to do things
like: construct scenarios of system use (not always done with
a user); construct models that accurately exemplify the functional
requirements; build dictionaries of terms to help ensure greater
probability of correct interpretation; discuss user interfaces
with clients and users; understand which bits of the system already
exist and ensure their purpose; and (of course) ensure that quality
attributes are properly described and understood.
Once all this stuff is brought together, the architect can start
thinking about potential architectural styles (such as model-view-controller
for user interaction or blackboard for when no deterministic solution
strategies are known as in AI-type systems) that could be used
and how to fit them together to provide the optimum result in
terms of trade-offs of (probably) several conflicting requirements.
For example, flexibility might easily conflict with stability
or robustness, and usability might easily conflict with safety
if all these particular “ilities” were required. Having
the client and users suggest priorities for such requirements
will help the architect in trade-off arguments.
Fitting different architectural styles together may require some
experimentation, but it also requires distinguishing different
systems aspects (such as trust, safety, intelligence) so that
components/subsystems that are ultimately built to support such
different aspects are not tightly coupled. Actually it is best
to start the system development with an approach of separating
the various concerns that must be dealt with in the implemented
system. The architecture is ultimately both a structure and a
compromise that enables the support of all the requirements.
Currently, Annette Vincent (a contracted SRA at ANU), Chris Johnson
(an academic at ANU) and myself (also an academic at ANU) are
developing the specification for a reusable architecture that
incorporates most of the Smart Internet technological and user
requirements. To do so we are applying an approach which begins
with the identification of the separate areas of concern that
typical Smart Internet applications must incorporate.
To aid in this process, it has been decided that the SWARM requirements
should represent (perhaps) a typical Smart Internet application
and in doing so develop the specification for the SWARM and the
architecture at the same time. Christine Satchell has helped initiate
the construction of a specification model by providing known SWARM
system requirements. At this stage there are still several requirements
that need clarification, but Annette and I have managed to progress
quite well nonetheless.
A different prototypical approach is being undertaken simultaneously
to help provide further input into both the SWARM and the architectural
requirements and also to provide a proof of concept concerning
the SWARM. Chris Johnson (who is currently on sabbatical at Sydney
University) is working with Bob Kummerfeld, Sam Holden, Waleed
Kadous, Claude Sammut, John Zic, Justin Lipman and (potentially)
Paul Boustead, to put together a prototype that can be shown to
users for their feedback. Hopefully, members of the UCD project
will be approached in the near future for input regarding user
interface and ultimately, system usability. Whatever requirements
and architectural concepts are derived from this prototypical
work, will be included in the specification for the Smart Internet
architecture.
Clive Boughton
Architecture Project Leader
Clive.Boughton@anu.edu.au
|
