Java Reference
In-Depth Information
According to these requirements, the access control system resembles a
typical event-driven client
-
server control architecture.
11.2.1
Domain models
Typically the evolution of a software control system is bottom-up. Very
often, control applications are built by integrating existing components,
which have been developed without any prior knowledge of the environment
in which they will be embedded.
The architecture of software control systems usually consists in a hier-
archy of component layers (Aarsten
et al
. 1996). A higher-level component
(e.g. the controller of the access control system), acting as a client, inte-
grates lower-level components, which act as servers (e.g. the photocells,
the ticket dispenser and the stopping bar.) In such systems, lower-level
components are more stable than higher-level components, which undergo
frequent reconfigurations according to rapidly evolving functional
requirements.
In complex control systems, some components might play both the role of
clients of lower-level components and the role of servers of higher-level
components. A major issue is the design of the software glue that integrates
the components and allows them to communicate. Communication requires
that some sort of visibility must exist among the components. Visibility
implies dependency with respect to changes, and hence it has consequences
for the entire system's design. In hierarchical software architectures it is
better to avoid visibility loops between components at different layers. This
is achieved by offering the components two communication mechanisms
where visibility and flow of information move in the same direction and in
the opposite direction with respect to the communicating components.
The first mechanism, known as caller
provider and deeply rooted in
object-oriented programming, is involved when an object invokes another
object's method. In hierarchical software architectures, it is convenient that
higher-level components (more volatile) have visibility of lower-level com-
ponents (more stable) but not vice versa. A client requests services from a
server by invoking the methods of its interface. For example, the controller
requests the ticket dispenser to deliver a ticket. Thus, both visibility and
flow of information move from the client to the server.
The second mechanism, the broadcaster
-
listener mechanism, consists in
giving the components the ability to both broadcast and listen to events.
The broadcaster does not know the identity of its listeners, which might
change over time. Conversely, the components that want to be notified
when an event is raised must know the identity of the component that
broadcasts that event. In hierarchical software architectures it is convenient
that lower-level components communicate with the higher-level ones by
broadcasting events. Thus, visibility and flow of information move in the
opposite direction: the client knows the server that broadcasts events of
interest.
-
