软件建模实践：匠人之道

需积分: 9 163 浏览量更新于2024-07-22 收藏 8.05MB PDF 举报

"Modeling Software Behavior A Craftsman's Approach" 是一本由Paul C. Jorgensen著、Anauerbach Books出版的书籍，由CRC Press（Taylor & Francis Group的一个印记）于2010年发行。这本书聚焦于软件行为建模的工匠方法，旨在提供一种专业且深入的视角来理解和实践软件开发中的建模技术。在软件工程领域，"Modeling Software Behavior" 涉及的核心知识点包括： 1. **软件建模基础**：建模是软件开发过程中的关键步骤，它帮助我们理解、设计和沟通复杂的系统。书中可能涵盖了统一建模语言（UML）的基本概念，如用例图、类图、序列图和状态图等，这些都是描述软件行为的重要工具。 2. **系统架构**：软件行为建模通常与系统架构紧密相关，作者可能讨论了如何通过建模来定义和分析系统的组件、接口以及它们之间的交互，以确保系统的设计符合需求并具有良好的可扩展性。 3. **行为建模技术**：书中可能详细介绍了如何使用活动图、状态机和交互图来表示软件的时间和顺序行为。这些技术有助于捕捉系统在不同条件下的动态行为，从而更准确地预测和避免潜在问题。 4. **软件工艺**：作为“工匠的方法”，本书可能强调了建模过程中的技巧和最佳实践，包括如何选择合适的建模元素、如何保持模型的简洁性和一致性，以及如何通过持续迭代改进模型。 5. **决策与权衡**：在软件开发中，每个设计决策都可能带来不同的后果。书中的“工匠方法”可能会探讨在模型复杂性和准确性之间做出明智权衡的重要性，以及如何根据项目需求和团队能力来调整建模策略。 6. **质量属性**：软件行为建模不仅关注功能实现，还关注非功能需求，如性能、安全性、可靠性等。书中可能会讨论如何在模型中体现这些质量属性，以及如何通过建模来优化它们。 7. **验证与确认**：有效的建模还包括验证模型是否正确地反映了需求，并通过模拟和测试来确认模型的行为。这部分内容可能涵盖模型驱动的开发（MDD）和模型检查等技术。 8. **团队协作与沟通**：软件建模也是一种沟通工具，书中可能涉及如何通过模型与利益相关者、开发者和其他团队成员进行有效的沟通，以确保所有人都对系统的预期行为有共同的理解。 9. **知识产权与版权**：书末的版权声明表明，尽管作者和出版社已尽力追踪并获得所有复制材料的许可，但他们仍可能遗漏了一些版权信息，并邀请未被承认的版权所有者联系他们以修正未来的再版。 "Modeling Software Behavior A Craftsman's Approach" 是一本深入探讨软件建模实践的专著，对于希望提升软件开发技能和理解系统行为的专业人士来说，是一份宝贵的资源。

2 ◾ Modeling Software Behavior: A Craftsman’s Approach

are exaggerated. In the United States as this is being written, caricatures of George

W. Bush are generally unﬂattering, compressing his head, and emphasizing his

nose and giving him pointy, elﬂike ears. At the same time, caricatures show

Barack Obama with large ears and a wide smile. Both leaders are easily recogniz-

able. Model-as-caricature is a helpful view of modeling. We hope to use models to

emphasize important features of the item being modeled, thereby increasing our

understanding and, likely, communicating this to others.

Modeling, then, is something of an art form: we need to recognize both the

compromise and caricature aspects of a potential model. Both are important, and

both contribute to the overall utility of a model.

1.2 Models of Software

Imagine a three-dimensional diagram, with the axes labeled “data,” “function,”

and “behavior” (sometimes, “control” is used in place of “behavior”), as seen in

Figure 1.1. is three-dimensional space is the one in which most of the require-

ments speciﬁcation modeling is done, and these axes are conceptually orthogonal

to each other. ey certainly represent very distinct approaches to modeling a sys-

tem. e object-oriented community links data and function together (by encap-

sulation), and the behavior axis remains as a distinct modeling view. None of these

views is suﬃcient by itself, and good modeling practice often moves freely among

Data

Control

Process

Figure 1.1 Axes in the modeling space.

Issues in Behavior Modeling ◾ 3

these three views. To fully understand a system, it must be described in terms of

each axis. In this and the following chapters, we are concerned with the behavior

axis. is chapter begins to develop a context of the study by discussing some

of the issues of requirements analysis. ere are other discussions that divide the

requirements-speciﬁcation phase of a project into ﬁne steps: Elicitation, analysis,

and speciﬁcation are the main ones. We are focused on the requirements-analysis

portion, speciﬁcally, models that describe and explain (and maybe even predict)

system behavior.

In the grandfather life-cycle model, the waterfall model, the requirements phase

is the foundation of the whole project. is carries over to nearly all of the software

development life-cycle models. Indeed, the focus of many of them, for example

rapid prototyping and the agile methods, is to get a better understanding of the

requirements of a system. We next look at two sets of guidelines for the goals of

requirements speciﬁcation: the traditional one, and a more appropriate modern

one. Academics no longer have to sell practitioners on the importance of require-

ments speciﬁcation, especially for event-driven systems. Two inescapable forces

drive this point home: A large portion of system faults (some say at least half) is due

to an inadequate requirements speciﬁcation, and the cost to resolve a fault found

during system testing can be a hundred times the cost of resolving the same error

at speciﬁcation time.

1.2.1 Traditional Goals

roughout most of the 1970s and 1980s, authors of requirements speciﬁcation

papers exhorted us to produce requirements speciﬁcations that are “consistent,

complete, and clear,” the “3 Cs” that were drilled into software engineering stu-

dents. e traditional goals of consistency, completeness, and clarity are products of

a past time. In the context of traditional applications developed using the waterfall

model, they were appropriate. Understanding why they are inappropriate will help

show the value of their replacements.

1.2.1.1 Consistency

e demand for consistency is probably an outgrowth of the strong mathematics

background of the early software developers. Mathematics (and logic) abhors an

inconsistency in much the same way that physics abhors a vacuum. (Everything is

true in an inconsistent formal system, thus such systems are of no value.) But what

does consistency mean when applied to software? Here are some possibilities:

◾ e program conforms to its deﬁnition.

◾ e program behaves as expected.

◾ All representations of the system (requirements speciﬁcation, design, source

and object code) are mutually compatible.

4 ◾ Modeling Software Behavior: A Craftsman’s Approach

◾ e program is predictable (deterministic); given the same inputs, it will

repeatedly produce the same outputs.

◾ No two parts of the requirements speciﬁcation contradict each other.

All of these are desirable, but are they really properties of a requirements

speciﬁcation? e ﬁrst two are really the goals of developer and customer testing,

respectively. e third is the charter of conﬁguration management in the software

development process. e fourth view is close, but it really is a program property.

Of the possibilities listed here, the ﬁfth comes closest to what “the authors” prob-

ably meant when they demanded requirements speciﬁcation consistency.

Why is (was!) consistency so important? Is it the fear that an inconsistent pair of

statements hidden somewhere in the requirements speciﬁcation may manifest itself

someday as an inconsistent pair of system behaviors lurking in the background,

waiting for a chance to lend further credence to Murphy’s Law? is fear is plausible

if software development were suﬃciently disciplined so as to implement everything

exactly as speciﬁed. In most organizations, there is too much “gain” in the develop-

ment process to make an inconsistency a real problem. e best case to make for

this view is transformational implementation (Agresti 1986), in which a system is

generated from a very formal speciﬁcation by a sequence of correctness-preserving

transformations. With this paradigm, an inconsistent speciﬁcation is clearly prob-

lematic; however, transformational implementation has had only limited success on

very simple applications.

Even if we accept, for the moment, that it really is important to have a consis-

tent requirements speciﬁcation, how would we ever determine this consistency?

Mathematical proofs of consistency are problematic: Kurt Gödel showed that

internal-consistency proofs are impossible, and moving to a stronger system to prove

that the original is consistent begs the question of the consistency of the stronger

system. At the other extreme, human-based techniques such as software reviews

don’t oﬀer much hope. Practitioners will be forced into a notation-dependent view

of consistency. As we shall see, decision tables, for example, have (somewhat relaxed)

interpretations of consistency that are, at least, comforting.

1.2.1.2 Completeness

e desire for completeness is much easier to understand, especially in terms of the

waterfall model of the software development life cycle. In the waterfall model, if

something is missing from the requirements speciﬁcation, it clearly won’t inﬂuence

the high-level design decisions, and will therefore be absent from both the detailed

design and the eventual source code. How embarrassing to deliver a system to a

customer and then be told that something obvious (to the customer) is missing.

Completeness is certainly desirable, but is it attainable? Once again, the answer

Issues in Behavior Modeling ◾ 5

depends on what we mean by completeness. Here are some deﬁnitions I have col-

lected over the years (the sources are deliberately omitted):

1. No TBD (to be done) sections.

2. All portions required by a given requirements speciﬁcation standard are

present.

3. All referenced items are deﬁned somewhere.

4. All system interfaces are considered.

5. All Ada

packages have a speciﬁcation part.

6. Notation-dependent forms of completeness.

7. Nothing is missing.

Rather than dwell on all of these, we look at the last two. Typically, with a

notation-dependent form of completeness, you know when you’re done. But, even

if you “are done,” have you satisﬁed the seventh possibility? It refers to problem

domain completeness, or semantic completeness; notation-dependent forms of

completeness are essentially syntactic, not semantic. e extent to which the syntax

of the requirements-speciﬁcation notation matches the semantics of the application

domain is a limiting factor on completeness.

Semantic (maybe “user-deﬁned” is a better term) completeness is the real objec-

tive. How attainable is semantic completeness? For well-understood systems, com-

pleteness is within reach. ese are the ones in which the user and the producer, as

a team, have what Agresti (1986) calls “perfect foresight.” What happens when we

don’t have perfect foresight, when neither the user nor the producer fully under-

stands the system being developed? e newer life-cycle models evolved as the prac-

titioner’s response. e whole point of rapid prototyping, for example, is to elicit

early feedback from the user. For simple systems, experienced developers can derive

the behavior from a structural model. For complex systems, rapid prototyping (and

its event-driven equivalent, executable speciﬁcations) helps us deal with incom-

pleteness. Notice that four of the newer life-cycle paradigms—rapid prototyping,

incremental development, evolutionary development, and agile development—all

share the premise that the requirements speciﬁcation is incomplete.

1.2.1.3 Clarity

Of all documents produced during software development, the requirements speci-

ﬁcation has the widest audience. It is used by the developer, the customer, the

independent test team, the maintainer, and by project management. We can also

imagine secondary users, such as trainers, installers, repair persons, operators, qual-

ity analysts, marketing personnel, and so on. With such a broad audience, no won-

der clarity is an issue. Of the three Cs, we should keep clarity. e need for clarity is

6 ◾ Modeling Software Behavior: A Craftsman’s Approach

sometimes at cross purposes with consistency and completeness. Our main conclu-

sion on these is that they are heavily dependent upon the notation used to express

the requirements speciﬁcation. Sadly, notations that help with consistency and

completeness are typically too technical to be well understood by the full audience

of the requirements speciﬁcation. Formal speciﬁcations can be very unclear. To see

this, try to ﬁgure out what simple mathematical function, f, is being speciﬁed below

(Liskov and Berzins 1977).

∀(i, x, y) ∋ i, x, and y are integers, x > 0, y > 0,

g(f(x, y), x) ∧ g(f(x, y), y) ∧ ∀i (g(i, x) ∧ g(i, y) ⇒ g(i, f(x, y)),

where g(x, y) = ∃ i ( y = x * i )

More descriptive names are used next; notice that the meaning becomes clear,

not because the structure has changed, but because the names give us clues.

For All i, x, and y, where i, x, and y are integers, x > 0, y > 0,

divides(gcd(x, y), x) AND divides(gcd(x, y), y) AND

for all i (divides(i, x) AND divides(i, y) implies divides(i, gcd(x, y)),

where divides(x, y) = exists i ( y = x * i )

Be honest—did you recognize this as the speciﬁcation of the greatest common

divisor of two integers? Even worse, did you understand what makes the result

maximal? A better way to provide clarity is to consider the information needs of

each component in the audience, and then try to produce that information in the

requirements speciﬁcation document. Having all interested parties actively review

the document (to defend their own self-interests) is an eﬀective way to ensure that

this variety of information needs has been met.

1.2.2 Appropriate Goals

e traditional goals for requirements speciﬁcation are products of a past time.

Major changes since that time obviate the past goals and demand new ones.

Consider:

◾ Size (and its attendant complexity) has increased by orders of magnitude.

We now (not routinely) undertake systems on the order of 10 million source

lines.

◾ e waterfall model and its handmaiden, functional decomposition, are

challenged by rival life-cycle models and composition.

◾ Real-time, concurrent, and event-driven systems have inherent complexi-

ties that cannot even be represented in traditional notations.

剩余221页未读，继续阅读

jiangdmdr

粉丝: 58
资源: 765

软件建模实践：匠人之道

"UML交互建模：清华大学软件学院刘璘解析交互图及对象协作行为

IBM Rational Software Architect for Virtualized System Modeling

"基于Pro/E的六自由度机械手参数化建模与仿真研究

Multiphysics Modeling Using COMSOL A First Principles Approach

System function implementation and behavioral modeling: A systems theoretic approach

Who Let The Dogs Out Modeling Dog Behavior From Visual Data.pdf

modeling-software-with-finite-state-machines-a-practical-approach

软件工程教学课件：Chapter_06_Requirements Modeling-behavior.ppt

Texturing and Modeling - A Procedural Approach

Geodetic Modeling Software in Matlab.zip

最新资源