Environmental Engineering Reference
In-Depth Information
The Role of Software Engineering in the Design
of Integrated Assessment Tools
Integrated assessment systems tend to be studied and built as part of (large) research
projects where the approach is mostly bottom-up: starting from simple models
building a larger and more complex model, accounting for the interactions among the
simpler processes (Knapen et al.
2007)
. This emphasizes the linking of the models
and perhaps the development or re-using of a framework to support it. Possibilities
of the models and the created links between them, and the framework's flexibility
are then put behind a most of the time rather technical looking user interface.
The same system could also be thought of from a top-down perspective: start
from the larger problem, and try to detail its subcomponents. This is more of a User
Centred Design (UCD) (Raskin
2000)
approach where usability and business
requirements drive the features and technical development. Tell tailing would be that
the user interface would be conceptualised first, and its usefulness studied with the
intended customers or target customer groups. The bottom-up view serves mostly
the modellers and framework builders, and the top-down all the other customers
that most likely pay (in some way or another) for the development of the system
and only care to a limited level about the intricate internal machinery of connected
interdisciplinary models. To them, in essence it is a data intensive software system that
has to provide usable information at the right moment, timely for the decision taking
process. Data intensive software systems are well known to software engineering,
for example consider the large banking and insurance systems. These are commonly
called (Business) Information Systems, or Enterprise Applications. If we regard
integrated modelling systems from this perspective, would it make sense to apply
to them some of the same software design rules - or software architecture, as used
for other enterprise applications? The answer is logically positive, and we have thus
adopted advanced software development methodologies, especially relying on
design patterns
to assist our design process, as they provide a mechanism for
providing software design advice in a reference format (Gamma et al.
1994)
.
We have been inspired by design patterns in some of our key design choices:
-
layered software architecture
, an architectural design pattern (Fowler 2007),
with its multi-tier levels, helped us to organise the complexity of software, by
clearly delegating different roles to components in the different layers.
-
Data Transfer Objects
(DTOs) helped us to optimise remote method calls.
A data transfer object is an object that holds all the data required for a call to a
remote interface. This pattern has proven itself very useful as the amount of data
to be transferred between the client and the server can become rather sizeable in
integrated assessment studies, and optimisation in this area brought sensible
improvements in the tool usability.
The
The
-
Service Layer
and the
Data Access Object design pattern
were useful in the
definition of SeamServer boundary and its set of available operations from the per-
spective of interfacing client layers. It encapsulates the business logic, controlling
transactions and coordinating responses in the implementation of its operations.
