Sommerville I. Software Engineering (9th edition)
Подождите немного. Документ загружается.
534 Chapter 19 ■ Service-oriented architecture
5. I have discussed the notion of compensation actions that are invoked when an
exception occurs and previous commitments that have been made (such as a
flight reservation) have to be revoked. There is a problem in testing such actions
as they may depend on the failure of other services. Ensuring that these services
actually fail during the testing process may be very difficult.
These problems are particularly acute when external services are used. They are less
serious when services are used within the same company or where cooperating com-
panies trust services offered by their partners. In such cases, source code may be
available to guide the testing process and payment for services is unlikely to be a
problem. Resolving these testing problems and producing guidelines, tools, and tech-
niques for testing service-oriented applications remains an important research issue.
K E Y P O I N T S
■ Service-oriented architecture is an approach to software engineering where reusable,
standardized services are the basic building blocks for application systems.
■ Service interfaces may be defined in an XML-based language called WSDL. A WSDL specification
includes a definition of the interface types and operations, the binding protocol used by the
service and the service location.
■ Services may be classified as utility services that provide a general-purpose functionality,
business services that implement part of a business process, or coordination services that
coordinate the execution of other services.
■ The service engineering process involves identifying candidate services for implementation,
defining the service interface and implementing, and testing and deploying the service.
■ Service interfaces may be defined for legacy software systems that continue to be useful for an
organization. The functionality of the legacy system may then be reused in other applications.
■ The development of software using services is based around the idea that programs are created
by composing and configuring services to create new composite services.
■ Business process models define the activities and information exchange that takes place in
a business process. Activities in the business process may be implemented by services so that
the business process model represents a service composition.
F U RT H E R R E A D I N G
There is an immense amount of tutorial material on the Web covering all aspects of web services.
However, I found the following two books by Thomas Erl to be the best overview and description
of services and service standards. Unlike most books, Erl includes some discussion of software
Chapter 19 ■ Exercises 535
E X E R C I S E S
19.1. What are the most important distinctions between services and software components?
19.2. Explain why SOAs should be based on standards.
19.3. Using the same notation, extend Figure 19.5 to include definitions for MaxMinType and
InDataFault. The temperatures should be represented as integers with an additional field
indicating whether the temperature is in degrees Fahrenheit or degrees Celsius. InDataFault
should be a simple type consisting of an error code.
19.4. Define an interface specification for the Currency Converter and Check credit rating services
shown in Figure 19.7.
19.5. Design possible input and output messages for the services shown in Figure 19.11. You may
specify these in the UML or in XML.
19.6. Giving reasons for your answer, suggest two important types of applications where you
would not recommend the use of service-oriented architecture.
19.7. In Section 19.2.1, I introduced an example of a company that has developed a catalog service
that is used by customers’ web-based procurement systems. Using BPMN, design a workflow
that uses this catalog service to look up and place orders for computer equipment.
19.8. Explain what is meant by a ‘compensation action’ and, using an example, show why these
actions may have to be included in workflows.
19.9. For the example of the vacation package reservation service, design a workflow that will
book ground transportation for a group of passengers arriving at an airport. They should be
given the option of booking either a taxi or renting a car. You may assume that the taxi and
car rental companies offer web services to make a reservation.
19.10. Using an example, explain in detail why the thorough testing of services that include
compensation actions is difficult.
engineering issues in service-oriented computing. He has also written more specialized books on the
design of services and SOA design patterns, although these are generally aimed at readers with
experience of implementing SOA.
Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. The primary focus
of this book is the underlying XML-based technologies (SOAP, WSDL, BPEL, etc.) that are a framework
for SOA. (T. Erl, Prentice Hall, 2004.)
Service-Oriented Architecture: Concepts, Technology and Design. This is a more general book on
the engineering of service-oriented systems. There is a little bit of overlap with the text above but
Erl mostly concentrates on discussing how a service-oriented approach may be used at all stages of
the software process. (T. Erl, Prentice Hall, 2005.)
‘SOA realization: Service design principles’. This short web article is an excellent overview of the
issues to be considered in designing services. (D. J. N. Artus, IBM, 2006.)
http://www.ibm.com/developerworks/webservices/library/ws-soa-design/.
536 Chapter 19 ■ Service-oriented architecture
R E F E R E N C E S
Andrews, T., Curbera, F., Goland, Y., Klein, J. and Al., E. (2003). ‘Business Process Execution Language
for Web Services’. http://www-128.ibm.com/developerworks/library/ws-bpel/.
Cabrera, L. F., Copeland, G. and Al., E. 2005. ‘Web Services Coordination (WS-Coordination)’.
ftp://www6.software.ibm.com/software/developer/library/WS-Coordination.pdf.
Carr, N. (2009). The Big Switch: Rewiring the World from Edison to Google, Reprint edition. New York:
W.W. Norton & Co.
Erl, T. (2004). Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services.
Upper Saddle River, NJ: Prentice Hall.
Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology and Design. Upper Saddle River,
NJ: Prentice Hall.
Kavantzas, N., Burdett, D. and Ritzinger, G. 2004. ‘Web Services Choreography Description Language
Version 1.0’. http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/.
Lovelock, C., Vandermerwe, S. and Lewis, B. (1996). Services Marketing. Englewood Cliffs, NJ: Prentice
Hall.
Newcomer, E. and Lomow, G. (2005). Understanding SOA with Web Services. Boston: Addison-Wesley.
Owl_Services_Coalition. 2003. ‘OWL-S: Semantic Markup for Web Services’.
http://www.daml.org/services/owl-s/1.0/owl-s.pdf.
Pautasso, C., Zimmermann, O. and Leymann, F. (2008). ‘RESTful Web Services vs “Big” Web Services:
Making the Right Architectural Decision’. Proc. WWW 2008, Beijing, China: 805–14.
Richardson, L. and Ruby, S. (2007). RESTful Web Services. Sebastopol, Calif.: O’Reilly Media Inc.
Turner, M., Budgen, D. and Brereton, P. (2003). ‘Turning Software into a Service’. IEEE Computer, 36
(10), 38–45.
White, S. A. (2004a). ‘An Introduction to BPMN’.
http://www.bpmn.org/Documents/Introduction%20to%20BPMN.
White, S. A. (2004b). ‘Process Modelling Notations and Workflow Patterns’. In Workflow Handbook
2004. Fischer, L. (ed.). Lighthouse Point, Fla.: Future Strategies Inc. 265–294.
White, S. A. and Miers, D. (2008). BPMN Modeling and Reference Guide: Understanding and Using
BPMN. Lighthouse Point, Fla.: Future Strategies Inc.
Embedded software
20
Objectives
The objective of this chapter is to introduce some of the characteristic
features of embedded real-time systems and real-time software
engineering. When you have read this chapter, you will:
■ understand the concept of embedded software, which is used to
control systems that must react to external events in their
environment;
■ have been introduced to a design process for real-time systems, where
the software systems are organized as a set of cooperating processes;
■ understand three architectural patterns that are commonly used in
embedded real-time systems design;
■ understand the organization of real-time operating systems and the
role that they play in an embedded, real-time system.
Contents
20.1 Embedded systems design
20.2 Architectural patterns
20.3 Timing analysis
20.4 Real-time operating systems
538 Chapter 20 ■ Embedded software
Computers are used to control a wide range of systems from simple domestic
machines, through games controllers, to entire manufacturing plants. These comput-
ers interact directly with hardware devices. Their software must react to events gen-
erated by the hardware and, often, issue control signals in response to these events.
These signals result in an action, such as the initiation of a phone call, the movement
of a character on the screen, the opening of a valve, or the display of the system
status. The software in these systems is embedded in system hardware, often in read-
only memory, and usually responds, in real time, to events from the system’s envi-
ronment. By real time, I mean that the software system has a deadline for responding
to external events. If this deadline is missed, then the overall hardware–software
system will not operate correctly.
Embedded software is very important economically because almost every electri-
cal device now includes software. There are therefore many more embedded soft-
ware systems than other types of software system. If you look around your house
you may have three or four personal computers. But you probably have 20 or 30
embedded systems, such as systems in phones, cookers, microwaves, etc.
Responsiveness in real time is the critical difference between embedded systems
and other software systems, such as information systems, web-based systems, or per-
sonal software systems, whose main purpose is data processing. For non-real-time
systems, the correctness of a system can be defined by specifying how system inputs
map to corresponding outputs that should be produced by the system. In response to
an input, a corresponding output should be generated by the system and, often, some
data should be stored. For example, if you choose a create command in a patient
information system, then the correct system response is to create a new patient record
in a database, and to confirm that this has been done. Within reasonable limits, it does
not matter how long this takes.
However, in a real-time system, the correctness depends both on the response to
an input and the time taken to generate that response. If the system takes too long to
respond, then the required response may be ineffective. For example, if embedded
software controlling a car braking system is too slow, then an accident may occur
because it is impossible to stop the car in time.
Therefore, time is inherent in the definition of a real-time software system:
A real-time software system is a system whose correct operation depends on
both the results produced by the system and the time at which these results are
produced. A ‘soft real-time system’ is a system whose operation is degraded if
results are not produced according to the specified timing requirements. If
results are not produced according to the timing specification in a ‘hard real-
time system’, this is considered to be a system failure.
Timely response is an important factor in all embedded systems but not all
embedded systems require a very fast response. For example, the insulin pump soft-
ware that I have used as an example in several chapters of this book is an embedded
system. However, although it needs to check the glucose level at periodic intervals, it
does not need to respond very quickly to external events. The wilderness weather
Chapter 20 ■ Embedded software 539
station software is also an embedded system but, again, it does not require a fast
response to external events.
As well as the need for real-time response, there are other important differences
between embedded systems and other types of software system:
1. Embedded systems generally run continuously and do not terminate. They start
when the hardware is switched on and must execute until the hardware is
switched off. This means that techniques for reliable software engineering, as
discussed in Chapter 13, may have to be used to ensure continuous operation.
The real-time system may include update mechanisms that support dynamic
reconfiguration so that the system can be updated while it is in service.
2. Interactions with the system’s environment are uncontrollable and unpre-
dictable. In interactive systems, the pace of the interaction is controlled by the
system and, by limiting user options, the events to be processed are known in
advance. By contrast, real-time embedded systems must be able to respond to
unexpected events at any time. This leads to a design for real-time systems
based on concurrency, with several processes executing in parallel.
3. There may be physical limitations that affect the design of a system. Examples
of these include limitations on the power available to the system and on the
physical space taken up by the hardware. These limitations may generate
requirements for the embedded software, such as the need to conserve power
and so prolong battery life. Size and weight limitations may mean that the soft-
ware has to take over some hardware functions because of the need to limit the
number of chips used in the system.
4. Direct hardware interaction may be necessary. In interactive systems and infor-
mation systems, there is a layer of software (the device drivers) that hides the
hardware from the operating system. This is possible because you can only con-
nect a few types of device to these systems, such as keyboards, mice, displays,
etc. By contrast, embedded systems may have to interact with a wide range of
hardware devices that do not have separate device drivers.
5. Issues of safety and reliability may dominate the system design. Many embed-
ded systems control devices whose failure may have high human or economic
costs. Therefore, dependability is critical and the system design has to ensure
safety-critical behavior at all times. This often leads to a conservative approach
to design where tried and tested techniques are used instead of newer techniques
that may introduce new failure modes.
Embedded systems can be thought of as reactive systems; that is, they must react
to events in their environment at the speed of that environment (Berry, 1989; Lee,
2002). Response times are often governed by the laws of physics rather than chosen
for human convenience. This is in contrast to other types of software where the sys-
tem controls the speed of the interaction. For example, the word processor that I am
540 Chapter 20 ■ Embedded software
using to write this book can check spelling and grammar and there are no practical
limits on the time taken to do this.
20.1 Embedded systems design
The design process for embedded systems is a systems engineering process in
which the software designers have to consider in detail the design and perform-
ance of the system hardware. Part of the system design process may involve
deciding which system capabilities are to be implemented in software and which
in hardware. For many real-time systems embedded in consumer products, such
as the systems in cell phones, the costs, and power consumption of the hardware
are critical. Specific processors designed to support embedded systems may be
used and, for some systems, special-purpose hardware may have to be designed
and built.
This means that a top-down software design process, in which the design starts
with an abstract model that is decomposed and developed in a series of stages, is
impractical for most real-time systems. Low-level decisions on hardware, support
software, and system timing must be considered early in the process. These limit the
flexibility of system designers and may mean that additional software functionality,
such as battery and power management, has to be included in the system.
Given that embedded systems are reactive systems that react to events in their
environment, the most general approach to embedded, real-time software design is
based on a stimulus-response model. A stimulus is an event occurring in the software
system’s environment that causes the system to react in some way; a response is a
signal or message that is sent by the software to its environment.
You can define the behavior of a real-time system by listing the stimuli received
by the system, the associated responses, and the time at which the response must be
produced. For example, Figure 20.1 shows possible stimuli and system responses for
a burglar alarm system. I give more information about this system in Section 20.2.1.
Stimuli fall into two classes:
1. Periodic stimuli These occur at predictable time intervals. For example, the sys-
tem may examine a sensor every 50 milliseconds and take action (respond)
depending on that sensor value (the stimulus).
2. Aperiodic stimuli These occur irregularly and unpredictably and are usually sig-
naled using the computer’s interrupt mechanism. An example of such a stimulus
would be an interrupt indicating that an I/O transfer was complete and that data
was available in a buffer.
Stimuli come from sensors in the system’s environment and responses are sent to
actuators, as shown in Figure 20.2. A general design guideline for real-time systems
20.1 ■ Embedded systems design 541
Figure 20.1 Stimuli
and responses for
a burglar alarm
system
is to have separate processes for each type of sensor and actuator (Figure 20.3).
These actuators control equipment, such as a pump, which then makes changes to
the system’s environment. The actuators themselves may also generate stimuli. The
stimuli from actuators often indicate that some problem has occurred, which must be
handled by the system.
For each type of sensor, there may be a sensor management process that handles data
collection from the sensors. Data processing processes compute the required responses
for the stimuli received by the system. Actuator control processes are associated with
Stimulus Response
Single sensor positive Initiate alarm; turn on lights around site of
positive sensor.
Two or more sensors positive Initiate alarm; turn on lights around sites of
positive sensors; call police with location of
suspected break-in.
Voltage drop of between 10%
and 20%
Switch to battery backup; run power
supply test.
Voltage drop of more than 20% Switch to battery backup; initiate alarm;
call police; run power supply test.
Power supply failure Call service technician.
Sensor failure Call service technician.
Console panic button positive Initiate alarm; turn on lights around console;
call police.
Clear alarms Switch off all active alarms; switch off all lights
that have been switched on.
Real-Time
Control System
ActuatorActuatorActuator Actuator
SensorSensorSensor SensorSensorSensor
Stimuli
Responses
Figure 20.2 A general
model of an embedded
real-time system
542 Chapter 20 ■ Embedded software
each actuator and manage the operation of that actuator. This model allows data to be
collected quickly from the sensor (before it is overwritten by the next input) and allows
processing and the associated actuator response to be carried out later.
A real-time system has to respond to stimuli that occur at different times. You
therefore have to organize the system architecture so that, as soon as a stimulus is
received, control is transferred to the correct handler. This is impractical in sequen-
tial programs. Consequently, real-time software systems are normally designed as a
set of concurrent, cooperating processes. To support the management of these
processes, the execution platform on which the real-time system executes may
include a real-time operating system (discussed in Section 20.4). The functions pro-
vided by this operating system are accessed through the run-time support system for
the real-time programming language that is used.
There is no standard embedded system design process. Rather, different processes
are used that depend on the type of system, available hardware, and the organization
that is developing the system. The following activities may be included in a real-time
software design process:
1. Platform selection In this activity, you choose an execution platform for the
system (i.e., the hardware and the real-time operating system to be used).
Factors that influence these choices include the timing constraints on the
system, limitations on power available, the experience of the development team,
and the price target for the delivered system.
2. Stimuli/response identification This involves identifying the stimuli that the sys-
tem must process and the associated response or responses for each stimulus.
3. Timing analysis For each stimulus and associated response, you identify the tim-
ing constraints that apply to both stimulus and response processing. These are
used to establish the deadlines for the processes in the system.
4. Process design At this stage, you aggregate the stimulus and response process-
ing into a number of concurrent processes. A good starting point for designing
the process architecture is the architectural patterns that I describe in Section
20.2. You then optimize the process architecture to reflect the specific require-
ments that you have to implement.
5. Algorithm design For each stimulus and response, you design algorithms to
carry out the required computations. Algorithm designs may have to be
Data
Processor
Actuator
Control
Actuator
Sensor
Control
Sensor
Stimulus Response
Figure 20.3 Sensor and
actuator processes
20.1 ■ Embedded systems design 543
developed relatively early in the design process to give an indication of the
amount of processing required and the time needed to complete that process-
ing. This is especially important for computationally intensive tasks, such as
signal processing.
6. Data design You specify the information that is exchanged by processes and the
events that coordinate information exchange, and design data structures to man-
age this information exchange. Several concurrent processes may share these
data structures.
7. Process scheduling You design a scheduling system that will ensure that
processes are started in time to meet their deadlines.
The order of these activities in the real-time software design process depends on
the type of system being developed, as well as its process and platform requirements.
In some cases, you may be able to follow a fairly abstract approach where you start
with the stimuli and associated processing, and decide on the hardware and execution
platforms late in the process. In other cases, the choice of hardware and operating sys-
tem is made before the software design starts. In such a situation, you have to design
the software to take account of the constraints imposed by the hardware capabilities.
Processes in a real-time system have to be coordinated and share information.
Process coordination mechanisms ensure mutual exclusion to shared resources.
When one process is modifying a shared resource, other processes should not be able
to change that resource. Mechanisms for ensuring mutual exclusion include sema-
phores (Dijkstra, 1968), monitors (Hoare, 1974), and critical regions (Brinch-
Hansen, 1973). These process synchronization mechanisms are described in most
operating system texts (Silberschatz et al., 2008; Tanenbaum, 2007).
When designing the information exchange between processes, you have to take
into account the fact that these processes may be running at different speeds. One
process is producing information; the other process is consuming that information. If
the producer is running faster than the consumer, new information could overwrite a
previously read information item before the consumer process has read the original
information. If the consumer process is running faster than the producer process, the
same item could be read twice.
To get around this problem, you should implement information exchange using a
shared buffer and use mutual exclusion mechanisms to control access to that buffer. This
means that information can’t be overwritten before it has been read and that information
cannot be read twice. Figure 20.4 illustrates the notion of a shared buffer. This is usually
implemented as a circular queue, so that mismatches in speed between the producer and
consumer processes can be accommodated without having to delay process execution.
The producer process always enters data in the buffer location at the tail of the
queue (represented as v10 in Figure 20.4). The consumer process always retrieves
information from the head of the queue (represented as v1 in Figure 20.4). After the
consumer process has retrieved the information, the head of the list is adjusted to
point at the next item (v2). After the producer process has added information, the tail
of the list is adjusted to point at the next free slot in the list.