Java Reference
In-Depth Information
11.7
■
Assessment
The case study exemplified the development of a typical access control
system for car parking.
Generic components
. The problem specification clearly addresses features
that have already been discussed in the previous two case studies. In fact, the
car parking system is described in terms of the physical components it is
made up of. As in the work cell system presented in Chapter 9, these devices
behave as finite state machines. The access control system is in charge of
coordinating the behaviour of the devices and of animating their graphical
representation. In Chapter 10 we have seen how to animate a mobile robot
for indoor exploration. Thus, the car parking system has been designed by
generalizing the solutions identified in the previous two case studies.
Architectural styles
. The problem analysis focused on the selection of the
simulation model and thus on the software architecture that better supports
both event-driven simulation and graphical animation. The architecture
has been designed as a hierarchy of control layers: at the lower layer, the
physical devices play the role of servers that receive stimuli from the
environment (the car) and the system controller; at the higher layer, the
controller supervises the correct behaviour of the physical devices by
sending commands and receiving notification events.
Communication
. The analysis of existing domain models identified two
communication mechanisms (i.e. the caller
-
provider and the broadcaster
-
listener) that cope with inter-component visibility issues typically
encountered in the development of software control systems.
Concurrency
. The implementation builds on the Java mechanism for
concurrency presented in Chapter 10 and for event-based communication
presented in Chapter 8.
Architecture
Hierarchy of control layers
Context
Large control systems perform multiple concurrent
activities.
Problem
How can the system be organized and divided into parts in
order to cope with its complexity?
Forces or tradeoffs
Typically the evolution of a software control system is
bottom-up. Control applications are built by integrating
existing components, which have been developed without
any prior knowledge of the environment in which they
have to be embedded.
Solution
The different functionalities of the systems should be
encapsulated into control modules with precise
responsibilities. The representation of control modules
has to be standardized in order to facilitate reuse and
architectural unity. Generally, a control module has the
following characteristics:
