Module 4

System Models: Context models; Behavioural models; Data models; Object models; structured
methods. CH-8

Architectural Design: Architectural design decisions; System organization; Modular decomposition

styles; Control styles, Reference architectures. CH-11

Application architectures: Data-processing systems, Transaction-processing systems, Event

processing systems Language-processing system. Ch-13

System Models (Chapter 8)

System models are abstract representations of a software system (graphical representation).
They are used during requirements analysis and system design to help developers and
stakeholders understand how a system works, how its components interact, and how data
flows through the system. Since real systems are complex, models help reduce complexity by
focusing on important aspects of the system. System models are often expressed using
diagrams and notations such as UML.

8.1 Context Models

These show the boundary of a system and how it interacts with external elements like users,
devices, other system or organization. You should make these decisions early in the process
to limit the system costs and the time needed for analysis.

A context model shows:

 The system
 Its boundary
 Everything outside the system (environment) that interacts with it

Once some decisions on the boundaries of the system have been made, part of the analysis
activity is the definition of that context and the dependencies that a system has on its
environment. Normally, producing a simple architectural model is the first step in this
activity. For example:
Above is a high-level architectural model and are usually expressed as simple block diagrams
where each sub-system is represented by a named rectangle, and lines indicate associations
between sub-systems. They show only environment of a system, not any relationship (no
details about external system). Therefore, simple architectural models are normally
supplemented by other models, such as process models, that show the process activities
supported by the system.

Figure 8.2 Process model of equipment procurement.

In the case of procuring equipment in an organisation, the overall process includes the
following activities:

1. Specify equipment requirements

– Identify what equipment is needed, quantity, specifications, and budget.
2. Find suppliers
– Search for potential suppliers who can provide the required equipment.
3. Choose suppliers
– Evaluate suppliers based on cost, quality, reliability, and delivery time.
4. Order equipment
– Place purchase orders with the selected supplier.
5. Take delivery of equipment
– Receive the equipment when it is delivered.
6. Test equipment after delivery
– Check whether the equipment works correctly and meets requirements.
8.2 Behavioural Models
Behavioural models are used to describe the overall behaviour of the system. There are two
types:

 Data-flow models which model the data processing in the system

 State machine models which model how the system reacts to events.

Most business systems are primarily driven by data. A data flow model may be all that is
needed to represent the behaviour of these systems. By contrast, real-time systems are often
event-driven with minimal data processing. A state machine model is the most effective way
to represent their behaviour.

8.2.1 Data-flow Models (Figure 8.3, 8.4)

Data-flow models are an intuitive way to represent how data is processed as it moves
through a system. They focus on what happens to data, rather than on control or timing.

Data-flow diagram (DFD) notation

A data-flow diagram uses simple symbols:

 Processes (rounded rectangles)

- Represent functional processing or transformations on data
 Data stores (rectangles)
- Hold data for later use (e.g., files or databases)
 Data flows (labelled arrows)
- Show the movement of data between processes and data stores

DFMs show how data flows through a sequence of processing steps. At each step, data is
transformed before moving to the next process. Example: A process that filters duplicate
customer records modifies the input data and passes the cleaned data onward.

Figure 8.3 Data-flow diagram of order processing.

The above data-flow diagram shows how an equipment order is processed in an organisation:
order details are first used to complete the order form, the order is then validated and
recorded, after which the signed order is sent to the supplier and the available budget is
adjusted, with the order information stored in the Orders file and the cost details updated in
the Budget file, illustrating how data moves and is transformed step by step through the
system.

Data-flow models present a functional view (perspective) of a system, where each

transformation represents a single process or function that operates on data. They are
especially useful during requirements analysis because they clearly show end-to-end
processing. This can be explained using the following diagram.

Figure 8.4 Data-flow diagram of an insulin pump

Here, blood sugar data is sensed and analysed to compute the required insulin level.
The controller then sends commands to the pump to deliver the correct amount of insulin.

8.2.2 State Machine Models (Figure 8.5, 8.6, 8.7)

A state machine model describes how a system responds to internal or external events. The
state machine model shows system states and events that cause transitions from one state to
another. It does not show the flow of data within the system. This type of model is often used
for modelling real-time systems.

Harel‟s method uses a notation called Statecharts and these were the basis for the state
machine-modelling notation in the UML. A state machine model of a system assumes that, at
any time, the system is in one of a number of possible states. When a stimulus is received,
this may trigger a transition to a different state.

Figure 8.5 State machine model of a simple microwave oven

The above diagram shows a state machine model of a simple microwave oven equipped with
buttons to set the power and the timer and to start the system. Sequence of actions in using
the microwave is: 1. Select the power level (either half-power or full-power). 2. Input the
cooking time. 3. Press Start, and the food are cooked for the given time. For safety reasons,
the oven should not operate when the door is open and, on completion of cooking, a
buzzer is sounded. The oven has a very simple alphanumeric display that is used to display
various alerts and warning messages.

The rounded rectangles in a model represent system states. The labelled arrows represent
stimuli that force a transition from one state to another. The UML notation lets you indicate
the activity that takes place in a state. In a detailed system specification, you have to provide
more detail about both the stimuli and the system states. This information may be maintained
in a data dictionary or encyclopaedia as shown in the following diagram.

The problem with the state machine approach is that the number of possible states increases
rapidly. For large system models, therefore, some structuring of these state models is
necessary. One way to do this is by using the notion of a superstate that encapsulates a
number of separate states. This superstate looks like a single state on a high-level model but
is then expanded in more detail on a separate diagram like shown below.
8.3 Data Models (Figure 8.8, 8.9)

Data models are the blueprints that define how data is organized, stored and accessed i.e. they
describe how data is structured and related within a software system. They help developers
understand what data is needed and how different pieces of data connect with each other.

An important part of systems modelling is defining the logical form of the data processed by
the system. These are sometimes called semantic data models. The most widely used data
modelling technique is Entity-Relation-Attribute modelling (ERA modelling), which
shows the data entities, their associated attributes and the relations between these entities.
This approach to modelling was first proposed in the mid-1970s by Chen (Chen, 1976).
Entity-relationship models have been widely used in database design. The relational
database schemas are derived from these models.

Figure 8.8 is an example of a data model that is part of the library system LIBSYS where it
is designed to deliver copies of copy righted articles that have been published in magazines
and journals and to collect payments for these articles. Therefore, the data model must
include information about the article, the copyright holder and the buyer of the article.

The above diagram shows that an Article has attributes representing the title, the authors, the
name of the PDF file of the article and the fee payable. This is linked to the Source, where the
article was published, and to the Copyright Agency for the country of publication. Both
Copyright Agency and Source are linked to Country. The country of publication is
important because copyright laws vary by country. The diagram also shows that Buyers place
Orders for Articles.

Like all graphical models, data models lack detail, and you should maintain more detailed
descriptions of the entities, relationships and attributes that are included in the model. You
may collect these more detailed descriptions in a repository or data dictionary. A data
dictionary is, simplistically, an alphabetic list of the names included in the system models. As
well as the name, the dictionary should include an associated description of the named entity
and, if the name represents a composite object, a description of the composition as shown
below. It defines the names in the semantic data model for LIBSYS.

The advantages of using a data dictionary are:

1. It is a mechanism for name management.

2. It serves as a store of organisational information.

8.4 Object Models

Object models describe a system by showing the objects in the system, their attributes,
relationships, and interactions. They focus on what the system is made of, rather than how
data flows or processes occur. Object models are commonly represented using UML class
diagrams and are useful for understanding system structure during analysis and for guiding
object-oriented design. This means expressing the systems requirements using an object
model, designing using objects and developing the system in an object-oriented programming
language such as Java or C++.

There are 3 types:

1. Inheritance Models
2. Object Aggregation
3. Object Behaviour Modelling

Developing object models during requirements analysis usually simplifies the transition to
object-oriented design and programming. However, end users often find object models
difficult to understand. An object class in UML, is represented as a vertically oriented
rectangle with three sections:

1. The name of the object class is in the top section.

2. The class attributes are in the middle section.

3. The operations associated with the object class are in the lower section of the rectangle.
8.4.1 Inheritance Models (Fig 8.10, 8.11, 8.12)

Object-oriented modelling involves identifying the classes of object that are important in the
domain being studied. These are then organised into taxonomy.

Taxonomy is a classification scheme that shows how an object class is related to other classes
through common attributes and services. To display this taxonomy, the classes are organised
into an inheritance hierarchy with the most general object classes at the top of the
hierarchy. More specialised objects inherit their attributes and services. These specialised
objects may have their own attributes and services. For Example,

The above diagram illustrates part of a simplified class hierarchy for a model of a library.
This hierarchy gives information about the items held in the library. The library holds various
items, such as books, music, recordings of films, magazines and newspapers. Here, the most
general item is at the top of the tree and has a set of attributes and services that are common
to all library items. These are inherited by the classes Published item and Recorded item,
which add their own attributes that are then inherited by lower-level items.

The above diagram is another inheritance hierarchy that might be part of the library model. In
this case, the users of a library are shown. There are two classes of user: those who are
allowed to borrow books, and those who may only read books in the library without taking
them away. In the UML notation, inheritance is shown „upwards‟ rather than „downwards‟.
That is, the arrowhead (shown as a triangle) points from the classes that inherit attributes and
operations to the super-class.

Multiple Inheritance

Multiple inheritance models may also be constructed where a class has several parents. Its
inherited attributes and services are a conjunction of those inherited from each super-class.

8.4.2 Object Aggregation

As well as acquiring attributes and services through an inheritance relationship with other
objects, some objects are groupings of other objects. That is, an object is an aggregate of a set
of other objects. The classes representing these objects may be modelled using an object
aggregation model, as shown in the diagram below.

In the above diagram, they have modelled a library item, which is a study pack for a
university course. This study pack includes lecture notes, exercises, sample solutions, copies
of transparencies used in lectures, and videotapes. The UML notation for aggregation is to
represent the composition by including a diamond shape on the source of the link. Therefore,
„A study pack is composed of one of more assignments, OHP slide packages, lecture notes
and videotapes.‟
8.4.3 Object Behaviour Modelling

To model object behaviour, it is necessary to show how an object‟s operations are used. In
UML, behaviour is modelled using scenarios, which are represented as use cases. One
common way to describe behaviour is through sequence diagrams, which show the order of
actions and messages involved in a use case. UML also provides collaboration diagrams,
which similarly illustrate message exchanges between objects, but sequence diagrams are
more commonly used.

In a sequence diagram, objects and actors are aligned along the top of the diagram. Labelled
arrows indicate operations; the sequence of operations is from top to bot tom. In this scenario,
the library user accesses the catalogue to see whether the item required is available
electronically; if it is, the user requests the electronic issue of that item. For copyright
reasons, this must be licensed so there is a transaction between the item and the user where
the license is agreed. The item to be issued is then sent to a network server object for
compression before being sent to the library user.

8.5 Structured Methods

Structured methods are systematic techniques used in software engineering to analyse,
design, and document a system in a clear and organized way. They were first developed in
the 1970s to support software analysis and design. It is a function-based approach to software
development. It breaks the system into small functions and shows how data flows between
them.

It focuses on function not object and easy to understand. Common structured methods/tools
include:
 Data Flow Diagrams (DFDs) – show how data moves through the system.

 Entity–Relationship (ER) diagrams – model data and relationships.

 Structure charts – show module hierarchy and control.

 Decision tables and decision trees – represent complex logic

Advantages:

 Easy to understand and document

 Good for large, well-defined systems
 Improves communication among stakeholders

Limitation:

1. Structured methods do not effectively model non-functional requirements.

2. They provide no guidance on choosing or adapting a method for a specific problem.
3. They generate excessive documentation that can hide key requirements.
4. Their detailed models are difficult for users to understand and validate.

Analysis and design CASE tools support the creation, editing and analysis of the graphical
notations used in structured methods. Diagram shown below shows the components that may
be included method support environment.

1. Diagram editors used to create object models, data models, behavioural

models, and so on. These editors are not just drawing tools but are aware of
the types of entities in the diagram. They capture information about these
entities and save this information in the central repository.
2. Design analysis and checking tools that process the design and report on errors
and anomalies. These may be integrated with the editing system so that user
errors are trapped at an early stage in the process.
3. Repository query languages that allow the designer to find designs and
associated design information in the repository.
4. A data dictionary that maintains information about the entities used in a
system design.
5. Report definition and generation tools that take information from the central
store and automatically generate system documentation.
6. Forms definition tools that allow screen and document formats to be specified.
7. Import/export facilities that allow the interchange of information from the
central repository with other development tools.
8. Code generators that generate code or code skeletons automatically from the
design captured in the central store.
 Architectural Design (Chapter 11)
Large systems are always decomposed into sub-systems that provide some related set of
services. The initial design process of identifying these sub-systems and establishing a
framework for sub-system control and communication is called architectural design.

Therefore, architectural design is the process of defining a high level structure of

software system, its major components, their relationships and communication methods
to meet functional and non-functional requirements.

Three advantages of explicitly designing and documenting software architecture:

1. Stakeholder communication: The architecture is a high-level presentation of the

system that may be used as a focus for discussion by a range of different stake
holders.
2. System analysis: Making the system architecture clear early requires analysis. Early
design decisions greatly affect system performance, reliability, and maintainability,
and are hard to change later.
3. Large-scale reuse: Similar systems often use the same architecture, which supports
software reuse. This can lead to product-line architectures where one architecture is
used for many related systems.

The system architecture affects the performance, robustness, distributability and

maintainability of a system (Bosch, 2000). The particular style and structure chosen for an
application may therefore depend on the non-functional system requirements:

1. Performance
2. Security
3. Safety
4. Availability
5. Maintainability

A sub-system design is an abstract decomposition of a system into large-grain components,

each of which may be a substantial system in its own right. Block diagrams are often used to
describe sub-system designs where each box in the diagram represents a sub-system. Boxes
within boxes indicate that the sub-system has itself been decomposed to sub-systems. Arrows
mean that data and or control signals are passed from sub-system to sub-system in the
direction of the arrows.
The above diagram is an abstract model of the architecture for a packing robot system that
shows the sub-systems that have to be developed. This robotic system can pack different
kinds of object. It uses a vision sub-system to pick out objects on a conveyor, identify the
type of object and select the right kind of pack aging. The system then moves objects from
the delivery conveyor to be packaged. It places packaged objects on another conveyor.

11.1 Architectural Design Decisions

Architectural design is a creative process where you try to establish a system organisation
that will satisfy the functional and non-functional system requirements. During the
architectural design process, system architects have to make a number of fundamental
decisions that profoundly affect the system and its development process. Based on their
knowledge and experience, they have to answer the following fundamental questions:

1. Is there a generic application architecture that can act as a template for the system that is
being designed?

2. How will the system be distributed across a number of processors?

3. What architectural style or styles are appropriate for the system?

4. What will be the fundamental approach used to structure the system?

5. How will the structural units in the system be decomposed into modules?

The product of the architectural design process is an architectural design document. This may
include a number of graphical representations of the system along with associated descriptive
text. It should describe how the system is structured into sub-systems, the approach adopted
and how each sub-system is structured into modules. The graphical models of the system
present different perspectives on the architecture. Architectural models that may be
developed may include:

1. A static structural model that shows the sub-systems or components that are to be
developed as separate units.

2. A dynamic process model that shows how the system is organised into pro cesses at run-
time. This may be different from the static model.

3. An interface model that defines the services offered by each sub-system through its public
interface.

4. Relationship models that show relationships, such as data flow, between the sub-systems.

5. A distribution model that shows how sub-systems may be distributed across computers.
System Architect should be aware of different Architecture Styles to select which structure
best suits your requirements. An architectural style is a pattern of system organization such as
a client–server organization or a layered architecture. Then you develop a general model of
the control relationships between the parts of the system established.

11.2 System Organisation

The organisation of a system reflects the basic strategy that is used to structure a system. You
have to make decisions on the overall organisational model of a system early in the
architectural design process. The system organisation may be directly reflected in the sub-
system structure.

It involves structuring both the software itself (modules, layers, components) and
development efforts (teams, processes like SDLC) for efficiency, maintainability and meeting
business goals. It involves designing modular or layered systems and organizing teams to
build them efficiently.

There are 3 Models:

1. The Repository Model

2. The Client-Server Model
3. The Layered Model

11.2.1 The Repository Model

Sub-systems making up a system must exchange information so that they can work together
effectively. There are two fundamental ways in which this can be done.

1. All shared data is held in a central database that can be accessed by all sub systems. A
system model based on a shared database is sometimes called a repository model.
2. Each sub-system maintains its own database. Data is interchanged with other sub-
systems by passing messages to them.

The majority of systems that use large amounts of data are organised around a shared
database or repository. This model is therefore suited to applications where data is generated
by one sub-system and used by another.

Example: E-commerce systems, IDE (eclipse, VS code), Banking apps etc.

The diagram shown below is an example of a CASE toolset architecture based on a shared
repository. The first shared repository for CASE tools was probably developed in the early
1970s by a UK company called ICL. to support their operating system development
(McGuffin, et al., 1979).
 Advantages Disadvantages
Components can easily share data through the
The repository is a single point of failure
central repository
Data is consistent because it is stored in one Changes to the repository affect all
place components
Easier data management and backup Difficult to scale for very large systems
New components can be added without Components become tightly coupled to the
changing existing ones repository
Suitable for systems with large amounts of Performance bottleneck if many components
shared data access it at once

11.2.2 The Client–Server Model

The client–server model is a distributed system architecture in which the system is divided
into clients and servers. A client is a program that requests services, while a server is a
program that provides those services. Clients and servers communicate with each other over
a network using well-defined communication protocols.

In this model, clients do not share resources directly with each other. Instead, all shared
resources such as data, files, or services are managed centrally by servers. A server may serve
many clients at the same time.

Major Components are:

 A set of servers that offer services to other sub-systems.

 A set of clients that call on the services offered by servers.

 A network that allows the clients to access these services.

Clients may have to know the names of the available servers and the services that they
provide. However, servers need not know either the identity of clients or how many clients
there are.

Examples: Web Applications, Email Systems, Online Video Platforms, Online Banking
The diagram below shows an example of a system that is based on the client–server model.
This is a multi-user, web-based system to provide a film and photograph library.

In this system, several servers manage and display the different types of media. Video frames
need to be transmitted quickly and in synchrony but at relatively low resolution. They may be
compressed in a store, so the video server may handle video compression and decompression
into different formats. Still pictures, however, must be maintained at a high resolution, so it is
appropriate to maintain them on a separate server.

Advantages Disadvantages
Centralised management of data and
Server is a single point of failure
resources
Easier maintenance and updates on the
Server overload can reduce performance
server
Better security as data is controlled at the
Higher cost for server hardware and maintenance
server
Network dependency – system fails if network is
Clients can be added or removed easily
down
Supports scalability by upgrading the Limited scalability compared to distributed
server systems
Consistent data access for all clients Server requires skilled administration

11.2.3 The Layered Model

The layered model of an architecture (sometimes called an abstract machine model) organises
a system into layers, each of which provide a set of services. Each layer provides a specific
set of services to the layer above it and uses the services of the layer below it. Every layer can
be viewed as an abstract machine, whose “machine language” is the set of services it offers.
The next higher layer is implemented using this language.

Example: 1. OSI Reference Model for network protocols, where communication is divided
into layers such as physical, data link, network, etc.
2. Ada Programming Support Environment (APSE) proposed by Buxton, which uses a
layered approach to integrate tools such as configuration management systems

The diagram shown below reflects the APSE structure and shows how a configuration
management system might be integrated using this abstract machine approach.

The diagram shows a layered architecture where the system is divided into levels. The
operating system layer provides basic services like file and memory management. The
database layer stores data safely and handles transactions. The object management layer
manages configuration objects and their versions. The configuration management layer is the
top layer that users interact with to control and track changes. This structure makes the
system easier to manage and modify.

Disadvantages
Advantages
Easy to understand and design Difficult to decide proper layer boundaries
Supports incremental development Lower layers may be needed by higher layers
Easy to modify or replace layers Layer bypassing breaks the model
Improves portability across platforms Performance overhead due to multiple layers
Changes affect only adjacent layers Not suitable for all types of systems

11.3 Modular Decomposition Styles

After an overall system organisation has been chosen, you need to make a decision on the approach
to be used in decomposing sub-systems into modules. Module decomposition is a critical aspect
of system design, enabling the breakdown of complex systems into smaller, more manageable
modules or components.

Difference between modules and sub-systems.

 A module is a smaller, specific functional unit (like a function or class). A module is

normally a system component that provides one or more services to other modules. It
 makes use of services provided by other modules. It is not normally considered to be
an independent system. Modules are usually com posed from a number of other
simpler system components.

 A sub-system is a collection of related modules forming a larger, more independent

system-within-a-system, often reusable across projects. A sub-system is a system in
its own right whose operation does not depend on the services provided by other sub-
systems. Sub-systems are composed of modules and have defined interfaces, which
are used for communication with other sub-systems.

There are two main strategies that you can use when decomposing a sub-system into
modules:

1. Object-oriented decomposition where you decompose a system into a set of

communicating objects.
2. Function-oriented pipelining where you decompose a system into functional modules
that accept input data and transform it into output data.

11.3.1 Object-Oriented Decomposition

Object-oriented decomposition organizes a system as a collection of independent objects that

interact with each other through well-defined interfaces. Each object provides certain services
and can use services from other objects.

Eg: Invoice processing system.

An object-oriented decomposition is concerned with object classes, their attributes and their
operations. When implemented, objects are created from these classes and some control
model is used to coordinate object operations. In an invoice processing system, objects such
as Invoice, Customer, Payment, and Receipt work together. The Invoice object handles main
tasks like issuing invoices, receiving payments, and sending reminders, while using
information from the other objects.

Advantages:

 Objects are loosely coupled, so changes in one object usually do not affect others.

 Objects often represent real-world entities, making the system easy to understand.

 Objects can be reused in other systems.

 Object-oriented languages directly support this design.

Disadvantages:

 Objects must know the names and interfaces of other objects they use.

 Complex real-world entities are sometimes hard to model as objects.

11.3.2 Function-Oriented Pipelining

Function-oriented pipelining (also called the data-flow or pipe-and-filter model) organizes a

system as a series of processing steps. Each step (called a transform or filter) takes input data,
processes it, and passes the output to the next step. Data flows step by step through the
pipeline until final output is produced.

When the transformations are represented as separate processes, this model is sometimes
called the pipe and filter style after the terminology used in the Unix system. The term filter
is used because a transformation „filters out‟ the data it can process from its input data
stream.

Example for this model is a pipeline model of an invoice processing system

An organization has issued invoices to customers. Once a week, payments that have been
made are reconciled with the invoices. For those invoices that have been paid, a receipt is
issued. For those invoices that have not been paid within the allowed payment time, a
reminder is issued. This is a model of only part of the invoice processing system; alternative
transformations would be used for the issue of invoices.

Advantages

 Easy to reuse processing steps

 Very intuitive (input → process → output)

 Easy to extend by adding new steps

 Simple to implement as sequential or parallel

Disadvantages

 All steps must use a common data format

 Data parsing and formatting increase overhead

 Hard to combine components with incompatible formats

 Not suitable for interactive systems (like GUI-based applications)

Therefore, pipelining is ideal for batch data-processing systems (e.g., billing), but not for
interactive systems.

11.4 Control Styles

To work as a system, sub-systems must be controlled so that their services are delivered to
the right place at the right time. Structural models do not include control information.
Rather, the architect should organize the sub-systems according to some control model.

Control models at the architectural level are concerned with the control flow between
sub-systems.

There are two generic control styles:

1. Centralized Control: One sub-system has overall responsibility for control

and starts and stops other sub-systems. It may also devolve control to another
sub system but will expect to have this control responsibility returned to it.

2. Event-Based Control: Rather than control information being embedded in

a sub system, each sub-system can respond to externally generated events.
These events might come from other sub-systems or from the environment of
the system.

11.4.1 Centralised Control

In a centralised control model, one sub-system is designated as the system controller and has
responsibility for managing the execution of other sub-systems. Centralised control models
fall into two classes, depending on whether the controlled sub-systems execute sequentially
or in parallel.

1. The call–return model: This is the familiar top-down subroutine model where control
starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels
in the tree. The subroutine model is only applicable to sequential systems.

2. The manager model: This is applicable to concurrent systems. One system component is
designated as a system manager and controls the starting, stopping and coordination of other
system processes.

The Call–Return Model

This is the familiar top-down subroutine model where control starts at the top of a subroutine
hierarchy and, through subroutine calls, passes to lower levels in the tree.

Here, the main program can call Routines 1, 2 and 3; Routine 1 can call Routines 1.2 or 1.2;
Routine 3 can call Routines 3.1 or 3.2; and so on. This familiar model is embedded in
programming languages such as C, Ada and Pascal. Control passes from a higher-level
routine in the hierarchy to a lower-level routine. It then returns to the point where the routine
was called.

In many object-oriented systems, operations on objects (methods) are implemented as

procedures or functions. For example, when a Java object requests a service from another
object, it does so by calling an associated method.

This call–return model may be used at the module level to control functions or objects.

The rigid and restricted nature of this model is both strength and a weakness. It is strength
because it is relatively simple to analyse control flows and work out how the system will
respond to particular inputs. It is a weakness because exceptions to normal operation are
awkward to handle.
The Manager Model

The central controller manages the execution of a set of processes associated with sensors and
actuators.

The above diagram is an illustration of a centralised management model of control for a

concurrent system. This model is often used in „soft‟ real-time systems which do not have
very tight time constraints. The central controller manages the execution of a set of processes
associated with sensors and actuators.

The system controller process decides when processes should be started or stopped depending
on system state variables. It checks whether other processes have produced information to
be processed or to pass information to them for processing. The controller usually loops
continuously, polling sensors and other processes for events or state changes. For this reason,
this model is sometimes called an event loop model.

11.4.2 Event-Driven Systems

In centralised control models, control decisions are usually determined by the values of some
system state variables. By contrast, event-driven control models are driven by externally
generated events. The term event in this context does not just mean a binary signal. It may
be a signal that can take a range of values or a command input from a menu.

Here we discuss two event-driven control models:

1. Broadcast models: In these models, an event is broadcast to all sub-systems. Any sub-
system that has been programmed to handle that event can respond to it.

2. Interrupt-driven models: These are exclusively used in real-time systems where external
interrupts are detected by an interrupt handler. They are then passed to some other component
for processing.
Broadcast models are effective in integrating sub-systems distributed across different
computers on a network. Interrupt-driven models are used in real-time systems with stringent
timing requirements.

Broadcast Models:

In these models, an event is broadcast to all sub-systems. Any sub-system that has been
programmed to handle that event can respond to it. In broadcast models, sub-systems register
an interest in specific events. When these events occur, control is transferred to the sub-
system that can handle the event. The distinction between this model and the centralized
model is as shown below.

All events could be broadcast to all sub-systems, but this imposes a great deal of processing
overhead. More often, the event and message handler maintains a register of sub-systems and
the events of interest to them. The event handler detects the events, consults the event register
and passes the event to those sub systems who have declared an interest.

Disadvantages of the Broadcast Model

 A sub-system does not know if or when its event will be handled.

 It does not know which sub-systems are listening to its events.

Advantages of the Broadcast Model

 It is easy to extend the system by adding new sub-systems.

 New sub-systems can be added by registering for events without changing existing
ones.

 Sub-systems can communicate without knowing each other‟s identity or location.

 Sub-systems can run on different machines, and this distribution is transparent to

others.
Interrupt-Driven Models

These are exclusively used in Real-Time Systems where external interrupts are detected by
an interrupt handler. They are then passed to some other component for processing. If a real-
time system is used to control the safety systems in a car, it must detect a possible crash and,
perhaps, inflate an airbag before the driver‟s head hits the steering wheel. To provide this
rapid response to events, you have to use interrupt-driven control.

An interrupt-driven control model is illustrated in the above diagram. There are a known
number of interrupt types with a handler defined for each type. Each type of interrupt is
associated with the memory location where its handler‟s address is stored. When an interrupt
of a particular type is received, a hardware switch causes control to be transferred
immediately to its handler. This interrupt handler may then start or stop other processes in
response to the event signaled by the interrupt.

The advantage of this approach is that it allows very fast responses to events to be
implemented. Its disadvantages are that it is complex to program and difficult to validate.

11.5 Reference Architectures

Architectural models can be general (used for many types of systems) or domain-specific
(used for a particular application area). As well as these general models, architectural models
that are specific to a particular application domain may also be used. Although instances of
these systems differ in detail, the common architectural structure can be reused when
developing new systems. These architectural models are called domain specific architectures.

Domain-specific architectures reuse a common structure found in similar systems, even

though details may differ.
There are two types of domain-specific architectural model:

 Generic Models: These are created by studying many real systems and
extracting their common features. Generic models can often be directly reused
when designing new systems.

Example: generic architectures for real-time systems like data collection or

monitoring systems.

 Reference models: These are more abstract and describe a broad class of
systems. They represent an ideal architecture, including all possible features
systems in that domain might have.

A generic model can also act as a reference model. However, reference models are usually
not used for direct implementation, but as a basis for discussion and comparison. They
provide a common vocabulary for evaluating systems.

Example 1: The OSI Reference Model Architecture (Open System Interconnection)

The OSI (Open Systems Interconnection) model is a reference model for how computers
communicate over a network. It divides communication into seven layers, each with a
specific function. Each layer uses services from the layer below and provides services to the
layer above. The layers are,

 The lower layers deal with physical data transmission.

 The middle layers handle data transfer and reliability.

 The upper layers manage meaningful application data.

The designers of the OSI model had the very practical objective of defining an
implementation standard so that conformant systems could communicate with each other.
Each layer should only depend on the layer beneath it. As technology developed, a layer
could be transparently re-implemented without affecting the systems using other layers. The
model was created to standardize communication between different systems. It allows
changes in one layer without affecting other layers.
Example 2: The ECMA reference architecture for CASE environments

The CASE (Computer-Aided Software Engineering) reference model defines what

services a CASE environment should provide and supports plug-in tools.

It includes five service layers:

1. Data repository services: These provide facilities for the storage and manage ment
of data items and their relationships.
2. Data integration services: These provide facilities for managing groups or the
establishment of relationships between them. These services and data repository
services are the basis of data integration in the environment.
3. Task management services: These provide facilities for the definition and enactment
of process models. They support process integration.
4. Message services: These provide facilities for tool-tool, environment-tool and
environment-environment communications. They support control integration.
5. User interface services: These provide facilities for user interface development. They
support presentation integration.

This model shows what may be included in a CASE environment. Not all systems include
every feature.