实时系统设计模式：构建健壮可扩展的实时架构

需积分: 17 74 浏览量更新于2023-07-10 1 收藏 13.97MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Real-Time Design Patterns - Robust Scalable Architecture for Real-Time Systems" 本书《实时设计模式——实时系统的强大可扩展架构》由Bruce Powel Douglass撰写，是Addison Wesley出版社于2002年9月27日出版的一本528页的技术著作，专注于实时和嵌入式（RTE）系统的软件设计。在构建这些系统时，容错性至关重要，因为最终产品需要强大、高效且高度可靠。处理器和内存资源的限制增加了这一挑战。开发者通常依赖设计模式，即经过验证的解决当前设计问题的方法，来构建安全可靠的RTE系统。书中的主要内容分为以下几个关键部分： 1. **统一建模语言（UML）**：首先，书中回顾了UML的符号和语义，这是理解和设计软件系统的基础，特别是在实时系统中，清晰的模型化对于理解复杂系统的行为至关重要。 2. **快速面向对象的嵌入式系统过程（ROPES）**：接着，作者介绍了ROPES过程及其关键技术。这是一个针对实时和嵌入式系统设计的流程框架，旨在提高开发效率和代码质量。 3. **大型战略决策**：书中探讨了影响大多数软件元素的大型战略决策。这些决策涉及系统架构的选择，以及如何根据系统需求和约束进行设计。 4. **组件协调与组织**：如何有效地协调和组织系统组件，以实现高效的实时响应，是实时设计模式中的一个重要主题。这可能包括任务调度、同步机制和通信策略等。 5. **设计模式目录**：书中的核心部分是一份详尽的设计模式目录，涵盖了各种模式及其在实时系统中的应用。这些模式可能包括生产者-消费者模式、发布-订阅模式、观察者模式、状态机模式等，它们在解决实时环境中的特定问题时非常有效。 6. **案例研究与应用**：为了深入理解这些模式，书中提供了具体的案例研究，展示如何在实际项目中实施这些设计模式，以达到预期的效果和性能。通过这本书，开发者能够学习到如何在资源受限的环境中构建强大、可扩展的实时系统，同时还能提升软件的稳定性和可靠性。它不仅适合有经验的实时系统开发者，也对想要进入这个领域的初学者有着极高的参考价值。

资源详情

资源推荐

Although somewhat less common, association labels may also be used, such as between the Power

Subsystem and Display Subsystem classes. The label is normally used to help explain why the association

exists between the two classes. In this case, the label "displays messages for" indicates that is how the

Power Subsystem intends to use the Display Subsystem. To get the directionality of the label (is the Power

Subsystem displaying messages for the Display Subsystem?), you can add an arrowhead next to the label to

show the speaking perspective.

The multiplicity is probably the most important property of an association end. The multiplicity of an

association end indicates the possible numbers of instances that can participate in the association role at

run-time. This may be any of the following.

• A fixed number, such as "1" or "3"

• A comma-separated list, such as "0,1" or "3,5,7"

• A range, such as "1..10"

• A combination of a list and a range, such as "1..10, 25", which means "one to ten, inclusive, or 25"

• An asterisk, which means "zero or more"

• An asterisk with an endpoint, such as "1..*," which means "one or more"

In Figure 1-2

, we see multiplicities on all the associations. Multiplicity is shown at the role end of the class

to which it applies. Thus, each Switch object associates with zero or one Charger object, but each Charger

object associates with exactly one Switch object.

Finally, the directionality of the association may be specified. A normal line with no arrowheads means

that the association is bidirectional; that is, an object at either end of the association may send a message to

an object at the other end. If only one of the objects can send a message to the other and not vice versa,

then we add an open arrowhead (we'll see later that the type of arrowhead matters) pointing in the

direction of the message flow. Thus, we see that a Switch object can send a message to a Battery object,

but not vice versa. This does not imply that the Switch object cannot retrieve a value from a Battery object

because it can call a method that returns a value. It means, however, that an object of type Battery cannot

spontaneously send a message to a Switch object.

All of these adornments, except for perhaps multiplicity, are optional and may be added as desired to

further clarify the relationships between the respective classes.

An association between classes means that at some point during the lifecycle of instances of the associated

classes, there may be a link that enables them to exchange messages. Nothing is stated or implied about

which of these objects comes into existence first, which other object creates them, or how the link is

formed.

1.3.2.2 Aggregation

An aggregation is a specialized kind of association that indicates a "whole-part" relation exists between the

two objects. The "whole" end is marked with a white diamond, as in Figure 1-2

. For example, consider, the

classes Message List and Message. The Message List class is clearly a "whole" that aggregates possibly

many Message elements. The diamond on the aggregation relation shows that the Message List is the

"whole." The "*" on the myMsg association end indicates that the list may contain zero or more Message

elements. If we desired to constrain this to be no more than 100 messages, we could have made the

multiplicity "0..100."

Since aggregation is a specialized form of association, all of the properties and adornments that apply to

associations also apply to aggregations, including navigation, multiplicity, role names, and association

labels.

Aggregation is a relatively weak form of "whole-part," as we'll see in a moment. No statement is made

about lifecycle dependency or creation/destruction responsibility. Indeed, aggregation is normally treated

in design and implementation identically to association. Nevertheless, it can be useful to aid in

understanding the model structure and the relations among the conceptual elements from the problem

domain.

1.3.2.3 Composition

Composition is a strong form of aggregation in which the "whole" (also known as the "composite") has the

explicit responsibility for the creation and destruction of the part objects. Because of this, the composite

exists before the parts come into existence, and it exists after they are destroyed. If the parts have a fixed

multiplicity with respect to the composite, then it is common to create those parts in its constructor (a

special operation that creates the object) and destroy them in its destructor. With nonfixed multiplicities,

the composite dynamically creates and destroys the part objects during its execution. Because the

composite has creation and destruction responsibility, each part object can only be owned by a single

composite object, although the part objects may participate in other association and aggregation relations.

Composition is also a kind of association, so it can likewise have all of the adornments available to

ordinary associations.

Composition has two common presentations: nested class boxes and a filled-in diamond. There is no

semantic difference between the two, and individual preferences vary. Personally, because composition is

so distinct from aggregation, I prefer to nest the class boxes on the diagrams, but your mileage may vary.

Figure 1-2

shows both forms. The Power Subsystem, for example, is a composite class that contains parts

of type Charger, Battery, and Switch. The Button class is also a composite that contains a single Light part.

With the containment presentation, there is an issue as to how to show the multiplicity of the part (by

definition, the multiplicity on the whole end of a composition is exactly "1"). Since there is no line on

which to place the multiplicity, it is common to put the multiplicity in one of the upper corners of the part

class. This is called instance multiplicity. We see that the Power Subsystem contains either one or two

objects of type Switch, zero or more objects of type Charger, and zero to two objects of type Battery.

There is also the issue of how to show the role names. The common way is to use a class role name. A

class role name precedes the class name and a slash (/) separator. In the figure, instances of class Switch

have a class role name of PowerSwitch. As an aside, we can also show object names if we like,

independently from the class role names. An object name is shown as preceding the class name, with a

colon (:) separator. Thus,

PowerSwitch/ thePowerSwitch: Switch

shows a role called PowerSwitch that is played by an object named thePowerSwitch, which happens to be

an instance of class Switch.

The most common implementation of an association, as seen in the previous code examples, is an object

pointer (in C++) or an object reference (in Java). This is true regardless of which kind of association it is,

whether it is an ordinary association, an aggregation, or a composition. There are many other ways of

implementing an association—including nested class declaration, object identifier reference (as in a MS

Windows handle or a CORBA object ID), an operating system task ID, and so on—but using a pointer is

the most common.

A Word About Stereotypes Figure 1-2

has a couple of places where a class has a special adornment called a

stereotype. A stereotype is a way of tailoring the UML to meet a specific need or purpose. It is part of the

lightweight extension mechanism defined within the UML. A stereotype is a user-defined kind of element

that is based on some already defined element in the UML, such as Class, Operation, Association, and so

on. Stereotypes are usually shown by attaching the stereotype name in guillemets with the stereotyped

element or shown using a user-defined icon. In the example figure, a class box is used for a large-scale

element called a Subsystem. To indicate that this is that special kind of element, we attach the stereotype

«subsystem» to the class box. Subsystems are discussed later in this chapter.

1.3.2.4 Generalization

The generalization relation in the UML means that one class defines a set of features that is either

specialized or extended in another. Generalization may be thought of as "is a type of" relation and

therefore only has a design-time impact rather than a run-time impact.

Generalization has many uses in class models. First, generalization is used as a means to ensure interface

compliance, much in the same way that interfaces are used. Indeed, it is the most common way to

implement interfaces in languages that do not have interfaces as a native concept, such as in C++. Also,

generalization can simplify your class models because a set of features common to a number of classes can

be abstracted together into a single superclass, rather than having to redefine the same structure

independently in many different classes. In addition, generalization allows for different realizations to be

used interchangeably. For example, one realization subclass might optimize worst-case performance, while

another optimizes memory size, while yet another optimizes reliability because of internal redundancy.

Generalization in the UML means two things. First, it means inheritance—that subclasses have (at least)

the same attributes, operations, methods, and relations as the superclasses they specialize. Of course, if the

subclasses were identical with their superclasses, that would be boring, so subclasses can differ from their

superclasses in either or both of two ways: specialization or extension.

Subclasses can specialize operations or state machines of their superclasses. Specializing means that the

same operation (or action list on the statechart) is implemented differently than in the superclass. This is

commonly called polymorphism. In order to make this work, when a class has an association with another

TEAMFLY

Team-Fly

that is a superclass, at run-time an instance of the first can invoke an operation declared in the second, and

if the link is actually to a subclass instance, the operation of the subclass is invoked rather than that of the

superclass.

This is much easier to see in the example presented in Figure 1-3

. The class MsgQueue is a superclass, and

it defines standard queue-like behavior, storing Message objects in a FIFO fashion with operations such as

insert() and remove(). CachedQueue specializes and extends MsgQueue (the closed arrowhead on the

generalization line points to the more general class). The Communicator class associates with the base

class MsgQueue. If it needs to store only a few messages, a standard in-memory queue—that is, an

instance of MsgQueue—works fine. But what if some particular instance of Communicator needs to store

millions of messages? In that case, the instance can link to an instance of the CachedQueue subclass.

Whether Communicator actually links to an instance of MsgQueue or one of its subclasses is unknown to

the instance of Communicator. It calls the insert() or remove() operations as necessary. If the connected

instance is of class MsgQueue, then the correct operations for that class are called. If the connected

instance is of class CachedQueue, then the operations for that class are invoked instead, but the client of

the queue doesn't know which is invoked.

Figure 1-3. Polymorphism

It is common not to show inherited methods in the subclass unless they override (redefine) methods

inherited from the superclass, but this is merely a stylistic convention. Remember that a CachedQueue is a

MsgQueue, so everything that is true about the latter is true of the former, including the attributes,

operations, and relations. For example, CachedQueue aggregates zero or more Message objects and has a

composition relation to the class Semaphore because its superclass does. However, in this case, the

operations for insert and remove are likely to work differently.

For example, MsgQueue::insert() might be written as shown in Code Listing 1-3

Code Listing 1-3: MsgQueue::insert() operation

void MsgQueue::insert(Message m) {

if (isFull())

throw OVERFLOW;

else {

head = (head + 1) % size;

list[head] = m;

};

However, the code for the insert operation in the subclass must be more complex. First, note that the

subclass contains (via composition) two MsgQueues: one for input buffering and one for output buffering.

The CachedQueue::insert() operation only uses the MsgQueue instance playing the inputQueue role. If

this is full, then it must write the buffer out to disk and zero out the buffer. The code to do this is shown in

Code Listing 1-4

Code Listing 1-4: CachedQueue::insert() operation

void CachedQueue::insert(Message m) {

if (inputQueue->isFull()) {

// flush the full queue to disk and then

// clear it flush();

inputQueue->clear();

};

inputQueue->insert(m);

};

Similarly, the operations for remove(), getSize(), clear(), isEmpty(), and isFull() need to be overridden as

well to take into account the use of two internal queues and a disk file.

Note that in the UML, attributes cannot be specialized. If the superclass defines an attribute of time

sensedValue and it has a type int, then all subclasses also have that attribute, and it is of the same type.

Subclasses can also extend the superclass—that is, they can have new attributes, operations, states,

transitions, relations, and so forth. If you need to change the type of an attribute, you should use the «bind»

stereotype of dependency, discussed in Section 1.3.2.5

The other thing that generalization means in the UML is substitutability. This means that anyplace an

instance of the superclass was used, an instance of the subclass can also be used without breaking the

system in any overt way. Substitutability is what makes generalization immensely useful in designs.

Figure 1-4

shows the previous queue example in a larger context. In this example, CachedQueue is still a

subclass of MsgQueue. We see that MsgQueue also has a composition relation to a semaphore to ensure its

integrity if it is called in the presence of multiple threads. We see the MsgQueue superclass has two

different kinds of clients: end user clients (who want to send and receive messages), which are types of

Communicating Object, and Communicators, which use the queue to do transmission and reception of the

queues. Both of these are abstract, which means that they define at least one operation for which they do

not supply a corresponding method. In C++ terms, they are pure virtual classes. The intended usage of

these classes is that a class that wants to be able to send and receive messages will subclass from

Communicating Object, and a class that wants to be able to use queues to perform transmission and

reception will subclass Communicator.

Figure 1-4. Generalization

剩余324页未读，继续阅读

taishantiaofu

粉丝: 1
资源: 6

会员权益专享

实时系统设计模式：构建健壮可扩展的实时架构

Real-Time Design Patterns

Real-time design patterns

Go: Design Patterns for Real-World Projects

嵌入式设计模式有推荐的书籍吗

hands-on design patterns with c++下载

java-design-patterns

AI-Assisted Low Information Latency Wireless Networking

patterns, principles, and practices of domain-driven design mobi pdf

phased-array-antenna-patterns

pointr dynamic query

github c语言项目

design patterns elements of reusable object-oriented software下载

23 design patterns in C++ code

Internet of Things for Smart Cities

tail -f grep

Frequent patterns can be partitioned into subsets according to F-list • F-list = f-c-a-b-m-p • Patterns containing p • Patterns having m but no p • … • Patterns having c but no a nor b, m, p • Pattern f • Completeness and non-redundancy翻译解释

rtl-sdr*ads-b*matlab

会员权益专享

最新资源

rtl-sdrads-bmatlab