Chapter 20
■
Exercises 563
20.7.
A train protection system automatically applies the brakes of a train if the speed limit for a segment of track is exceeded or if the train enters a track segment that is currently signaled
with a red light i.e., the segment should not be entered. Details are shown in Figure 20.19. Identify the stimuli that must be processed by the onboard train control system and the
associated responses to these stimuli.
20.8.
Suggest a possible process architecture for this system.
20.9.
If a periodic process in the onboard train protection system is used to collect data from the trackside transmitter, how often must it be scheduled to ensure that the system is
guaranteed to collect information from the transmitter? Explain how you arrived at your answer.
20.10.
Why are general-purpose operating systems, such as Linux or Windows, not suitable as real-time system platforms? Use your experience of using a general-purpose system to help
answer this question.
Train protection system • The system acquires information on the speed limit of a segment from a trackside transmitter, which
continually broadcasts the segment identifier and its speed limit. The same transmitter also broadcasts information on the status of the signal controlling that track segment. The time required to broadcast track
segment and signal information is 50 ms. • The train can receive information from the trackside transmitter when it is within 10 m of a transmitter.
• The maximum train speed is 180 kph. • Sensors on the train provide information about the current train speed updated every 250 ms and the train
brake status updated every 100 ms. • If the train speed exceeds the current segment speed limit by more than 5 kph, a warning is sounded in the
driver’s cabin. If the train speed exceeds the current segment speed limit by more than 10 kph, the train’s brakes are automatically applied until the speed falls to the segment speed limit. Train brakes should be
applied within 100 ms of the time when the excessive train speed has been detected. • If the train enters a track signaled that is signaled with a red light, the train protection system applies the train
brakes and reduces the speed to zero. Train brakes should be applied within 100 ms of the time when the red light signal is received.
• The system continually updates a status display in the driver’s cabin. Figure 20.19
Requirements for a train protection system
564 Chapter 20
■
Embedded software
R E F E R E N C E S
Berry, G. 1989. ‘Real-time programming: Special-purpose or general-purpose languages’. In Information Processing. Ritter, G. ed.. Amsterdam: Elsevier Science Publishers, 11–17.
Brinch-Hansen, P. 1973. Operating System Principles. Englewood Cliffs, NJ: Prentice-Hall. Burns, A. and Wellings, A. 2009. Real-Time Systems and Programming Languages: Ada,
Real-Time Java and CReal-Time POSIX. Boston: Addison-Wesley. Cooling, J. 2003. Software Engineering for Real-Time Systems. Harlow, UK: Addison-Wesley.
Dibble, P. C. 2008. Real-time Java Platform Programming, 2nd edition. Charleston, SC: Booksurge Publishing.
Dijkstra, E. W. 1968. ‘Cooperating Sequential Processes’. In Programming Languages. Genuys, F. ed.. London: Academic Press, 43–112.
Douglass, B. P. 1999. Real-Time UML: Developing Efficient Objects for Embedded Systems, 2nd edition. Boston: Addison-Wesley.
Douglass, B. P. 2002. Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems. Boston: Addison-Wesley.
Gomaa, H. 1993. Software Design Methods for Concurrent and Real-Time Systems. Reading, Mass.: Addison-Wesley.
Harel, D. 1987. ‘Statecharts: A Visual Formalism for Complex Systems’. Sci. Comput. Programming, 8 3, 231–74.
Harel, D. 1988. ‘On Visual Formalisms’. Comm. ACM, 31 5, 514–30.
Hoare, C. A. R. 1974. ‘Monitors: an operating system structuring concept’. Comm. ACM, 21 8, 666–77.
Lee, E. A. 2002. ‘Embedded Software’. In Advances in Computers. Zelkowitz, M. ed.. London: Academic Press.
Silberschatz, A., Galvin, P. B. and Gagne, G. 2008. Operating System Concepts, 8th edition. New York: John Wiley Sons.
Tanenbaum, A. S. 2007. Modern Operating Systems, 3rd edition. Englewood Cliffs, NJ: Prentice Hall.
Aspect-oriented software engineering
21
Objectives
The objective of this chapter is to introduce you to aspect-oriented software development, which is based on the separation of concerns.
When you have read this chapter, you will:
■
understand why the separation of concerns is a good guiding principle for software development;
■
have been introduced to the fundamental ideas underlying aspects and aspect-oriented software development;
■
understand how an aspect-oriented approach may be used for requirements engineering, software design, and programming;
■
be aware of the difficulties of testing aspect-oriented systems.
Contents
21.1 The separation of concerns 21.2 Aspects, join points, and pointcuts
21.3 Software engineering with aspects
566 Chapter 21
■
Aspect-oriented software engineering In most large systems, the relationships between the requirements and the program
components are complex. A single requirement may be implemented by a number of components and each component may include elements of several requirements.
In practice, this means that implementing a change to the requirements may involve understanding and changing several components. Alternatively, a component may
provide some core functionality but also include code that implements several system requirements. Even when there appears to be significant reuse potential, it may be
expensive to reuse such components. Reuse may involve modifying them to remove extra code that is not associated with the core functionality of the component.
Aspect-oriented software engineering AOSE is an approach to software devel- opment that is intended to address this problem and so make programs easier to
maintain and reuse. AOSE is based around abstractions called aspects, which implement system functionality that may be required at several different places in a
program. Aspects encapsulate functionality that cross-cuts and coexists with other functionality that is included in a system. They are used alongside other abstrac-
tions such as objects and methods. An executable aspect-oriented program is created by automatically combining weaving objects, methods, and aspects,
according to specifications that are included in the program source code.
An important characteristic of aspects is that they include a definition of where they should be included in a program, as well as the code implementing the cross-
cutting concern. You can specify that the cross-cutting code should be included before or after a specific method call or when an attribute is accessed. Essentially,
the aspect is woven into the core program to create a new augmented system.
The key benefit of an aspect-oriented approach is that it supports the separation of concerns. As I explain in Section 21.1, separating concerns into independent ele-
ments rather than including different concerns in the same logical abstraction is good software engineering practice. By representing cross-cutting concerns as aspects,
these concerns can be understood, reused, and modified independently, without regard for where the code is used. For example, user authentication may be repre-
sented as an aspect that requests a login name and password. This can be automati- cally woven into the program wherever authentication is required.
Say you have a requirement that user authentication is required before any change to personal details is made in a database. You can describe this in an aspect by stat-
ing that the authentication code should be included before each call to methods that update personal details. Subsequently, you may extend the requirement for authenti-
cation to all database updates. This can easily be implemented by modifying the aspect. You simply change the definition of where the authentication code is to be
woven into the system. You do not have to search through the system looking for all occurrences of these methods. You are therefore less likely to make mistakes and
introduce accidental security vulnerabilities into your program.
Research and development in aspect-orientation has primarily focused on aspect- oriented programming. Aspect-oriented programming languages such as AspectJ
Colyer and Clement, 2005; Colyer et al., 2005; Kiczales, et al., 2001; Laddad, 2003a; Laddad, 2003b have been developed that extend object-oriented program-
ming to include aspects. Major companies have used aspect-oriented programming
21.1
■
The separation of concerns 567
in their software production processes Colyer and Clement, 2005. However, cross- cutting concerns are equally problematic at other stages of the software development
process. Researchers are now investigating how to utilize aspect-orientation in sys- tem requirements engineering and system design, and how to test and verify aspect-
oriented programs.
I have included a discussion of AOSE here because its focus on separating con- cerns is an important way of thinking about and structuring a software system.
Although some large-scale systems have been implemented using an aspect-oriented approach, the use of aspects is still not part of mainstream software engineering. As
with all new technologies, advocates focus on the benefits rather than the problems and costs. Although it will be some time before AOSE is routinely used alongside
other approaches to software engineering, the idea of separating concerns that under- lies AOSE are important. Thinking about the separation of concerns is a good gen-
eral approach to software engineering.
In the remaining sections of the chapter, I therefore focus on the concepts that are part of AOSE and discuss the advantages and disadvantages of using an aspect-
oriented approach at different stages of the software development process. As my aim is to help you understand the concepts underlying AOSE, I do not go into detail
of any specific approach or aspect-oriented programming language.
21.1 The separation of concerns
The separation of concerns is a key principle of software design and implementation. It means that you should organize your software so that each element in the program
class, method, procedure, etc. does one thing and one thing only. You can then focus on that element without regard for the other elements in the program. You can
understand each part of the program by knowing its concern, without the need to understand other elements. When changes are required, they are localized to a small
number of elements.
The importance of separating concerns was recognized at an early stage in the history of computer science. Subroutines, which encapsulate a unit of functionality,
were invented in the early 1950s and subsequent program structuring mechanisms such as procedures and object classes have been designed to provide better mecha-
nisms for realizing the separation of concerns. However, all of these mechanisms have problems in dealing with certain types of concern that cut across other con-
cerns. These cross-cutting concerns cannot be localized using structuring mecha- nisms such as objects or functions. Aspects have been invented to help manage these
cross-cutting concerns.
Although it is generally agreed that separating concerns is good software engineer- ing practice, it is harder to pin down what is actually meant by a concern. Sometimes
it is defined as a functional notion i.e., a concern is some element of functionality in a system. Alternatively, it may be defined very broadly as ‘any piece of interest or
568 Chapter 21
■
Aspect-oriented software engineering focus in a program’. Neither of these definitions is particularly useful in practice.
Concerns certainly are more than simply functional elements but the more general definition is so vague that it is practically useless.
In my view, most attempts to define concerns are problematic because they attempt to relate concerns to programs. In fact, as discussed by Jacobson and Ng
2004, concerns are really reflections of the system requirements and priorities of stakeholders in the system. System performance may be a concern because users
want to have a rapid response from a system; some stakeholders may be concerned that the system should include particular functionality; companies who are support-
ing a system may be concerned that it is easy to maintain. A concern can therefore be defined as something that is of interest or significance to a stakeholder or a group of
stakeholders.
If you think of concerns as a way of organizing requirements, you can see why an approach to implementation that separates concerns into different program elements is
good practice. It is easier to trace concerns, expressed as a requirement or a related set of requirements, to the program components that implement these concerns. If the
requirements change, then the part of the program that has to be changed is obvious.
There are several different types of stakeholder concern: 1.
Functional concerns, which are related to the specific functionality to be included in a system. For example, in a train control system, a specific functional concern
is train braking.
2. Quality of service concerns, which are related to the non-functional behavior of
a system. These include characteristics such as performance, reliability, and availability.
3. Policy concerns, which are related to the overall policies that govern the use of
a system. Policy concerns include security and safety concerns and concerns related to business rules.
4. System concerns, which are related to attributes of the system as a whole, such
as its maintainability or its configurability. 5.
Organizational concerns, which are related to organizational goals and priori- ties. These include producing a system within budget, making use of existing
software assets, and maintaining the reputation of the organization.
The core concerns of a system are those functional concerns that relate to its pri- mary purpose. Therefore, for a hospital patient information system, the core func-
tional concerns are the creation, editing, retrieval, and management of patient records. In addition to core concerns, large systems also have secondary functional concerns.
These may involve functionality that shares information with the core concerns, or which is required so that the system can satisfy its non-functional requirements.
For example, consider a system that has a requirement to provide concurrent access to a shared buffer. One process adds data to the buffer and another process
