C/C++中的实用量子编程：嵌入式系统的状态机

4星 · 超过85%的资源需积分: 34 125 浏览量更新于2024-07-26 收藏 2.34MB PDF 举报

"Practical Statecharts in C/C++: Quantum Programming for Embedded Systems" 本书《实用状态图在C/C++中的应用：面向嵌入式系统的量子编程》深入探讨了如何使用状态机来解决嵌入式系统的设计问题。作者通过比较传统的事件-动作范式与基于状态机的编程方式，阐述了面向对象状态机的优势。书中的内容涵盖了从基础的三段式状态机到复杂的面向对象状态机，旨在帮助读者理解如何在实际项目中应用这些理论。在前言部分，作者提到了本书的目标和动机，即引入量子编程（Quantum Programming）的概念，这是相对于极限编程（XP）和其他敏捷开发方法的一种不同的编程哲学。本书的主要受众是对嵌入式系统设计感兴趣的软件工程师和开发者，无论他们的经验水平如何。第一部分“状态图”包含一系列章节，首先对量子编程进行了概述。第1章“快速了解量子编程”中，作者通过一个GUI应用程序的示例揭示了传统编程方法的不足，并提出了一种更有效的方法——设计一个能工作的计算器。这个示例展示了状态机如何改进事件处理和系统行为的组织。书中详细讨论了： 1.1. 传统的事件-动作范式的局限性，以及如何通过状态图来改善计算器应用程序的结构。 1.2. 计算器的状态图模型，如何将状态机与Windows系统集成，以及使用状态处理方法。 1.3. 面向对象的类比，包括状态层次结构、类分类、进入/退出状态与类的实例化/销毁，编程差异原则，行为继承作为元模式，状态模式的应用，以及如何重构状态模型。 1.4. 量子编程的类比，解释了量子编程理念如何与传统面向对象编程不同。 1.5. 每章末尾的总结，帮助读者巩固所学概念。第2章“状态图速成课”可能进一步深入讨论状态图的构造，状态之间的转换，以及如何用C/C++实现状态机。此外，书中还有对读者的阅读建议、感谢声明等内容，为读者提供了一个全面的学习指南，帮助他们更好地理解和实践状态图在嵌入式系统中的应用。通过这本书，读者不仅能掌握如何使用状态机解决复杂的问题，还能了解到如何将这些技术应用于嵌入式系统，从而提高软件的可维护性和可靠性。对于想要提升在嵌入式系统设计领域专业技能的开发者来说，这是一本极有价值的参考资料。

usually skip over exercises, at least consider looking at the answers provided on the CD−ROM so that you

don't miss the guidelines or techniques I introduce there.

I describe the CD−ROM that accompanies this book in more detail in Appendix C and the HTML browser

included on the disc. Here, I want to mention that the examples (although written in portable C++ or C) are

designed to run under Microsoft Visual C++ v6.0 on a 32−bit Windows machine (9x/NT/2000). If you don't

have Visual C++, I recommend you get a copy so that you will be able to run the examples without redoing

the makefiles, libraries, and so on. It is also important to have a good, easy−to−use debugger.

The source code for this book is available on the CD−ROM and can be freely distributed to students by

accredited colleges and universities without a license. You can use the code as is or modify it to embed in

your products, but you must obtain a Source Code Distribution License to distribute QP source code. I may

choose to assess a license fee for such situations, and you need to contact me for pricing (see below).

I intend to continue advancing QP and am interested in any constructive feedback you may have. I have

opened a Web site devoted to promotion of this book and QP at the URL http://www.quantum−leaps.com. I

plan for this site to contain application notes, ports of QP to different platforms, state patterns, useful links,

bug fixes, frequently asked questions and much more. Please feel free to contact me via e−mail at

miro@quantum−leaps.com.

[2]

For example, the Embedded Systems Programming survey (published annually by ESP magazine) or the

Annual Salary Survey (published by SD magazine).

Acknowledgments

I would like to thank Robert Ward, my acquisitions editor at CMP Books, in whom I found excellent editor,

extremely knowledgeable software professional, and a resonating mind. I feel very lucky that Robert accepted

my book for publication and offered his guidance throughout this book's lengthy birthing. I couldn't have

dreamed of a better editor for this book.

The team of CMP Books has been wonderful. It was a great pleasure to have Michelle O'Neal as the

managing editor. I'd like to thank Julie McNamee, Catherine Janzen, and Rita Sooby, for putting up with my

writing. I'm amazed how many times they managed to turn my convoluted technical jargon into something

actually readable. Reviewing their corrections was for me the best possible lesson in lucid writing. I also

thank Justin Fulmer, for polishing my drawings and integrating them into the final version of the book.

I am indebted to Jeff Claar, for the technical review of the manuscript and for scrutinizing the accompanying

code. Jeff's contributions include the complete C++ state machine implementation compliant with multiple

inheritance, which is available on the companion CD−ROM.

I'd like to thank Michael Barr, for letting me publish my earlier article on the subject in the Embedded

Systems Programming magazine, and for reviewing an early copy of this book.

This book has had a long gestation, of which the actual writing was merely the final step. I owe a lot to my

former colleagues at GE Medical Systems, specifically to John Zhang, for infecting me with his enthusiasm

for design patterns and state machines. In addition, I'd like to acknowledge my current team at IntegriNautics

Corporation–one of the highest concentrations of Ph.D.s per square foot in Silicon Valley. I am particularly

grateful to Paul Montgomery, for brainstorming many of the ideas, unforgettable pair−programming sessions,

and for patiently enduring all my early iterations of the Quantum Framework.

Acknowledgments 8

Chapter 1: Whirlwind Tour of Quantum Programming

Overview

I have found out there ain't no surer way to find out whether you like people or hate them than

to travel with them.

—Tom Sawyer Abroad [Mark Twain]

The triumph of the graphical user interface has been one of the most impressive developments in software

during the past three decades.

[1]

Today the concept is so familiar as to need no description. Although from the

beginning, windows, icons, menus, and pointing have been intuitive and easy to grasp for users, they remain a

challenge for programmers. The internal GUI architecture baffles many newcomers, who often find it strange,

backwards, mind−boggling, or weird. GUI programming is different because unlike traditional data

processing, it is entirely event−driven. Events can occur at any time in any order. The application always must

be prepared to handle them. GUI is an example of a complex reactive system.

You don't need to look far to find other examples of reactive systems. In fact, CPUs of all PCs, Macs, and

other general−purpose computers consume only about 1 percent of the worldwide microprocessor production.

The other 99 percent of microprocessor chips sold every year end up in various embedded systems, which are

predominantly reactive in nature. Yet, in spite of this ubiquity, the code found in most of these systems is

notoriously difficult to understand, fix, and maintain. Theoretical foundations on how to construct such

software have been around for more than a decade; however, these ideas somehow could not make it into the

mainstream. Quantum Programming (QP) is an attempt to make the modern methods more approachable for

programmers. QP is a set of straightforward design patterns, idioms, concrete implementations, and

commonsense techniques that you can start using immediately without investing in sophisticated tools.

[1]

The concept of the windows, icons, menus, and pointing (WIMP) interface was first publicly displayed by

Doug Englebart and his team from the Stanford Research Institute at the Western Joint Computer Conference

in 1968 [Englebart+ 68].

1.1 The Ultimate Hook — Anatomy of a GUI Application

The early GUI designers faced a formidable task. On the one hand, a GUI application must be virtually

infinitely customizable to allow anything from nonrectangular windows to splash screens and dazzling screen

savers. On the other hand, the system ought to impose a consistent look and feel, and applications content

with this standard behavior should be simple. How would you reconcile such conflicting requirements?

Today the problem seems easy — the trick is to use the "Ultimate Hook" [Petzold 96]. The idea is brilliantly

simple. The GUI system (e.g., Windows) dispatches all events first to the application (Windows calls a

specific function inside the application). If not handled by the application, the events flow back to the system.

This establishes a hierarchical order of event processing. The application, which is conceptually at a lower

level of hierarchy, has a chance to react to every event; thus, the application can customize every aspect of its

behavior. At the same time, all unhandled events flow back to the higher level (i.e., to the system), where they

are processed according to the standard look and feel. This is an example of programming−by−difference

because the application programmer has to code only the differences from standard system behavior.

Independently, David Harel applied the same idea to the finite state machine formalism [Harel 87]. Around

1983 he invented statecharts as a powerful way of specifying complex reactive systems. The main innovation

of statecharts over classical finite state machines was the introduction of hierarchical states. To understand

Chapter 1: Whirlwind Tour of Quantum Programming 11

what it means, consider the relation between the nested state (substate) and the surrounding state (superstate)

depicted in Figure 1.1a. This statechart attempts to process any event, first, in the context of the substate. If

the substate cannot handle it, the statechart automatically passes the event to the next higher level (i.e., to the

superstate). Of course, states can nest deeper than one level. The simple rule of processing events applies then

recursively to an arbitrary level of nesting.

Figure 1.1: (a) Statechart notation for nesting states

(b) Statechart representing Ultimate Hook design pattern

Harel's semantics of state hierarchy is at the heart of the Ultimate Hook design underlying GUI systems; in

other words, the statechart supports the Ultimate Hook pattern directly. This becomes obvious when renaming

the superstate to GUI_system and the substate to GUI_application, as shown in Figure 1.1b. Now this

is an interesting result: The fundamental Ultimate Hook design pattern turns out to be a very simple

statechart! This powerful statechart is unusually simple because, at this level of abstraction, it does not contain

any state transitions.

Traditionally, the hierarchy of states introduced in statecharts has been justified as follows.

As it turns out, highly complex behavior cannot be easily described by simple, "flat"

state−transition diagrams. The reason is rooted in the unmanageable multitude of states,

which may result in an unstructured and chaotic state−transition diagram

— [Harel+ 98].

Certainly, hierarchical diagrams are often simpler and better structured than traditional flat diagrams.

However, this is not the fundamental reason for the significance of state hierarchy, merely one of the side

effects. State hierarchy is fundamentally important even without the multitude of states and transitions, as

demonstrated clearly by the GUI example. The powerful statechart shown in Figure 1.1b contains only two

states and not a single state transition; yet, it is powerful. The only essential feature is state hierarchy, in its

pure form.

Figure 1.1b is so unusually simple because it shows only the highest level of abstraction. All nontrivial GUI

applications have many modes of operation (states) with typically complex rules of switching between these

modes (state transitions), regardless of whether you use a statechart, a classical flat state transition diagram,

brute force, or any other method. However, designs based on the statechart formalism seem to be the most

succinct, robust, and elegant, if for no other reason than their direct support for programming−by−difference

(Ultimate Hook pattern).

Although statecharts in some form or another have gained almost universal acceptance as a superior

formalism for specifying complex reactive systems, their actual adoption into mainstream programming has

been slow. In particular, GUI designs traditionally have not used statecharts. You will not find them in

standard GUI architectures such as Microsoft Foundation Classes (MFC), Borland's Object Windows Library

(OWL), or the more recent Java Abstract Window Toolkit (AWT). You also will not find support for

statecharts in rapid application development (RAD) tools such as Microsoft Visual Basic or Borland Delphi.

Among the many reasons, the most important is that statecharts have been taught as a high−level, visual

language, mandating the use of sophisticated computer−aided software engineering (CASE) tools, rather than

as a type of design. This has created many misconceptions in the industry and has resulted in a lack of

practical advice on how to code statecharts in mainstream programming languages such as C or C++.

Chapter 1: Whirlwind Tour of Quantum Programming 12

剩余278页未读，继续阅读

sagetom

粉丝: 7
资源: 16

C/C++中的实用量子编程：嵌入式系统的状态机

Programming Embedded Systems in C and C++

Newnes.Practical.UML.Statecharts.In.C.C++.Event.Driven.Programming.For.Embedded.Systems.2nd.Edition.2009.5star.pdf

Practical.UML.Statecharts.In.C.C++.Event.Driven.Programming第二版

Practical.Statecharts.in.C.C++.2002

Practical.UML.Statecharts.In.C.C++.2nd.2009

Practical+UML+Statecharts+In+C+C+++Event+Driven+Programming+For+Embedded

Quantum Programming for Embedded Systems英文PDF和光盘资料_说明

Quantum Programming for Embedded Systems英文PDF和光盘资料_02

Quantum Programming for Embedded Systems英文PDF和光盘资料_05

Quantum Programming for Embedded Systems英文PDF和光盘资料_04

最新资源