background image
vice consumer's perspective to the service
provider's perspective) and ensured that
duplication of information was avoided
while being easily accessible.
t took some effort to keep the software
documentation in a state that made it
suitable for automated maintenance and
automated analysis tools, but the standar-
disation and minimum of ambiguity pro-
ved to be very worthwhile.
he design of a service-based system
offers significant benefits for the
development of complex applications in a
distributed way. However, it also poses
considerable challenges to the co-ordina-
tion of the project.The MOBIlearn pro-
ject has found ways to manage the design
of such a service-based architecture suc-
cessfully, using UML and a specially desi-
gned documentation method, and taking
care in planning the future needs of the
to provide a framework for software
to monitor the status of
n order to achieve these goals, the
documentation must be unambiguous,
complete, and easily accessible by all. It
was maintained in a single Word file, stan-
dardised using templates for specifying
services and operations, and reporting
bugs and requests. A special MOBIlearn
menu added to the Microsoft Word menu
bar offered easy access to these macros.To
ease communication among the project
partners and allow automated analysis,
each component, service and operation
was assigned a unique identifier. For
example, the identifier AB_CDE+02
denotes the second operation called by
the service CDE from component AB.
These identifiers allowed for easy regrou-
ping of information according to different
needs (which was especially useful during
the design process when the view of the
documentation was changed from the ser-
t was verified that the system is free of
loops and the overall response time was
satisfactory. Although up to this point the
design had been demand driven, the team
now began to prepare the formal specifi-
cation for the implementation.The central
documentation (maintained in MS Word
for ease of use) was restructured to reflect
the system of services from the point of
view of the services providing the expec-
ted operations.
The MOBIlearn Software
n order to fully utilise the development
of individual services concurrently at
independent sites, the consortium agreed
on a standard form of design documenta-
tion.The MOBIlearn Software
Documentation has three main parts:
The Software Requirements Specification
gives high-level documentation that
facilitates the communication between
users, developers of scenarios and soft-
ware developers.
The Component Design breaks down the
Software Requirement Specification
into a set of components that can be
implemented separately.This facilitates
the communication between software
developers located at different sites.
The System Status section provides
a survey of all involved services and
operations and their interrelations.
A table of problems is available to
coordinate testing of the system.
ain usages of this documentation
to agree on the functionalities to be
to facilitate communication between
services that are developed concurrently
at different sites;
to determine correct behaviour of the
operations to be implemented;
to set the quality standards to be
n 2004,
.mobilear (kindly offer
ed b
y Xyber