面向对象分析模式：可重用对象模型解析

5星 · 超过95%的资源需积分: 4 42 浏览量更新于2024-08-02 1 收藏 1.84MB PDF 举报

"分析模式-可重用对象模型" 是一本由Martin Flow撰写的经典书籍，主要探讨了面向对象设计中的模式和设计原则，强调了对象模型的可重用性。书中的内容涵盖了分析模式、设计模式以及重用等关键概念。在面向对象的设计中，分析模式是指在系统分析阶段发现的通用解决方案，它们描述了如何抽象和建模现实世界中的问题领域。这些模式可以作为模板，帮助开发者创建更稳定、可维护和易于理解的系统。马丁·弗洛伊德的这本书深入探讨了这些模式，并提供了实用的指导，帮助读者理解和应用这些模式。书中提到的概念模型是系统设计的基础，它是一种对现实世界的抽象，用于理解和表达问题域的关键元素。例如，"Party" 模式是一种常见的分析模式，用于表示具有责任或义务的实体，如个人、组织或公司。这个模式强调了如何构建具有责任关系的对象模型。 "Accountability" 是分析中的一个重要主题，书中详细介绍了如何通过组织层级、组织结构、职责分配和操作范围来建模责任。 PartyType 的一般化关系展示了不同类型的实体如何共享基本属性和行为，而Hierarchic Accountability则描述了责任如何在组织结构中逐级传递。 "Observations and Measurements"章节讨论了如何在系统中处理量度和观察数据。Quantity模式代表了数量，ConversionRatio用于转换不同单位之间的比率，Compound Units则处理复合单位的建模。Measurement模式关注的是实际的测量过程，而Observation模式则描述了如何记录和存储观察到的数据。Subtyping Observation Concepts扩展了观察的类型，Protocol模式定义了一组交互规则，而Dual Time Record模式则用于处理同时涉及两个时间点的记录。本书还提到了模式和框架之间的关系，指出模式可以作为构建大型软件系统框架的基础。使用这些模式可以提高代码的复用性，降低开发复杂性，同时促进团队间的沟通和协作。 "分析模式-可重用对象模型"是一本深入探讨面向对象设计中可重用性的权威著作，适合软件设计师、架构师和系统分析师阅读，帮助他们提升分析和设计能力，实现更高水平的代码复用和系统质量。

DLKING ,  : www.dlking.com

Introduction

1.1 Conceptual Models

Most books on object modeling talk about analysis and design. There is little

agreement on where the boundary between these two activities lies. An important

principle in object development is designing software so that its structure reflects

that of the problem. One result of this principle is that the models produced from

both analysis and design end up deliberately similar, leading many people to

think that there is no difference.

I believe a difference between analysis and design still exists, but it is

increasingly becoming one of emphasis. When doing analysis you are trying to

understand the problem. To my mind this is not just listing requirements in

use-cases [8]. Use-cases are a valuable, if not essential, part of system

development, but capturing them is not the end of analysis. Analysis also

involves looking behind the surface requirements to come up with a mental

model of what is going on in the problem.

Consider someone who wants to write software to simulate a game of

snooker. This problem could be evaluated in terms of use-cases that describe the

surface features: "The player hits the white ball so it travels at a certain speed; it

hits the red ball at a certain angle, and the red ball travels a certain distance and

direction." You could film several hundred such incidents and measure ball

speeds, angles, distances traveled. But these examples alone would probably not

be enough to write a good simulation. To do the job well, you would need to look

behind the surface to understand the laws of motion that relate mass, velocity,

momentum, and the like. Understanding those laws would make it much easier to

see how the software could be built.

DLKING ,  : www.dlking.com

2 Conceptual Models

The snooker ball problem is unusual because the laws are well known and

have been well known for a long time. In many enterprises the equivalent

foundations are not so well understood, and we have to make the effort to uncover

them. To do this we create a conceptual model—a mental model that allows us to

understand and simplify the problem. Some kind of conceptual model is a

necessary part of software development, and even the most uncontrolled hacker

does it. The difference is whether we think about conceptual modeling as a

process in itself or as one aspect of the entire software design process.

It is important to remember that a conceptual model is a

human artifact.

The

laws of motion that a developer uses to create something like the snooker

simulation are not part of the real world; they represent a model of the real world,

a model created by human beings. They are effective, in engineering terms,

because they allow us to better understand what happens in the real world. Also, a

developer can use more than one model; for the snooker simulation a Newtonian

or Einsteinian model could be used. You could argue that the Einsteinian model

would be more correct because it takes into account changes of mass due to the

speed the balls are traveling and is thus more precise. The developer would almost

certainly prefer the Newtonian model, however, because the speeds would be so

low that they would make a negligible difference to the simulation but would

involve a lot of extra complexity. This illustrates an important principle: There is

no right or wrong model, merely one that is more useful for the job at hand.

Modeling Principle

Models are not right or wrong; they are more or less useful.

The choice of model affects the flexibility and reusability of the resulting

system. You might argue that the developer should use an Einsteinian model

because the resulting software would be flexible enough to handle problems

involving atomic collisions. But this is a dangerous path to go down. Building too

much flexibility into a system can make it too complex, and this is bad

engineering. Engineering demands a trade-off between the cost of building and

maintaining an artifact and the features it will provide. To build software that is fit

for a purpose, you have to develop a conceptual model that is appropriate to your

needs. You need the simplest model you can get away with. Don't add flexibility

you are unlikely to use.

The simplest model is not necessarily the first one you think of. Finding a

simple solution takes a lot of time and effort, which can be frustrating. People

often react to a simple model by saying "Oh yes, that's obvious" and thinking "So

why did it take so long to come up with it?" But simple models are always worth

the effort. Not only do they make things easier to build, but more importantly they

make them easier to maintain and extend in the

DLKING ,  : www.dlking.com

Introduction 3

future. That's why it is worth replacing software that works with simpler software

that also works.

How do you express a conceptual model? For many people the conceptual

model is built into their software language. The advantage of a language is that

you can execute a model to verify its correctness and to further explore it. This is

no small advantage; I often use Smalltalk in my conceptual modeling. Another

advantage is that you have to turn the model into a programming language

eventually, so modeling in your target language saves the step of translation.

(There are tools that can interpret or compile analysis and design models, thus

reducing the problems associated with translation.)

The danger of using a language is that it is easy to get lost in the issues of

using that language and lose sight of the problem you are trying to understand.

(This is less of a problem with higher-level languages, such as Smalltalk. I know

several gifted conceptual modelers who do their modeling in that language.)

Modeling in a programming language also presents the danger of tying the models

to that language. The model may use features of that language that are not

available in other languages. This does not mean that the conceptual model cannot

be moved to another language, but it can make the process more difficult.

To avoid these problems, many people use analysis and design techniques for

conceptual modeling. These techniques can help people concen trate on

conceptual rather than software design issues, and they can be easier to teach to

domain experts. Analysis and design techniques use graphics to be more

expressive. They may be rigorous, but they don't have to be. Techniques designed

to be executable must be rigorous, but when analysis methods are used in

conjunction with a programming language, they need not be as rigorous.

One of the main reasons I use analysis and design techniques is to involve

domain experts. It is

essential

to have domain experts involved in conceptual

modeling. I believe that effective models can only be built by those that really

understand the domain—

full-time

workers in the domain, not software developers,

no matter how long they have worked in the domain. If domain experts are to do

conceptual modeling, they must be taught. I have taught OO analysis and design

techniques to customer service supervisors, doctors, nurses, financial traders, and

corporate financial analysts. I have found that an IT background is neither a help

nor a hindrance to skill in modeling. The best modeler I know is a physician at a

London hospital. As the professional analyst and modeler, I bring valuable skills

to the process: I can provide rigor, I know how to use the techniques, and my

outsider's view can challenge accepted wisdom. All this is not enough. However

much work I do in health care computing, I will never know? as much about

health care as a doctor or nurse. Expert knowledge is central to a good analysis

model.

DLKING ,  : www.dlking.com

4 The World of Patterns

Analysis techniques are intended to be independent of software technology.

Ideally a conceptual modeling technique is totally independent of software

technology, as are the laws of motion. This independence would prevent

technology from hindering an understanding of the problem, and the resulting

model would be equally useful for all kinds of software technology. In practice

this purity does not occur. I try to develop very conceptual models that focus

entirely on the problem, yet my techniques are object-oriented and hence reflect a

software design approach. You can get a good sense of how software technology

affects conceptual modeling by comparing the models in this book with those of

David Hay [7]. We are both trying to build conceptual models, yet our results are

different because he uses a relational technique and I use an object-oriented one.

This is an inevitable result of the nature of software. Building software is building

virtual machines. The languages in which we build software can both control the

physical machine and express the needs of the problem. One of the reasons our

languages change is because we find better ways to express the needs of a

problem. These language changes thus influence the way we build conceptual

models. Despite a few tricky areas (see Chapter 14), the resulting models are not

difficult to turn into object-oriented software.

One caution I do need to raise now, however, is that conceptual models relate

closely to software interfaces rather than software implementations. One of the

important things about object-oriented software is that it separates interface from

implementation. Unfortunately this distinction is too easily lost in practice

because common languages do not make an explicit distinction between the two.

The difference between a software component's interface (its type) and its

implementation (its class) is extremely important. Many important

delegation-based patterns in the "Gang of Four" book [6] rely on this distinction.

When implementing these models, don't forget the difference.

Modeling Principle

Conceptual models are linked to interfaces (types) not imple-

mentations (classes).

1.2 The World of Patterns

In the last couple of years, patterns have become one of the hottest topics in the

object community. They are rapidly becoming the leading-edge fad, generating a

huge amount of interest and the usual hype. We are also seeing internal battles

over what fits into the community, including many arguments about exactly what

a pattern is. Certainly it is difficult to find any common definition

of pattern.

DLKING ,  : www.dlking.com

Introduction 5

The roots of the patterns movement come from various sources. In recent

years an increasing number of people felt that the software world was not very

good at describing and proliferating good design practice. Methodologies

abounded, but they defined a language for describing designs rather than

describing actual designs. There was (and still is) a dearth of technical papers

describing useful designs based on practice, which could be used to educate and

inspire. As Ralph Johnson and Ward Cunningham put it:

"Projects fail despite the

latest technology for lack of ordinary solutions"

[4],

Patterns evolved from several initiatives. Kent Beck and Ward

Cunning-ham, two of the pioneers of Smalltalk, came across the ideas of

Christopher Alexander, who had developed a theory and collection of patterns

in architecture. Bruce Anderson led workshops at OOPSLA in the early 1990s

that investigated building a handbook for software architects. Jim Coplien's C++

book [3] described idioms useful in C++. A number of these people formed the

Hillside Group to explore these ideas further.

A greater public knowledge of the movement was triggered by the publication

of the seminal "Gang of Four" book [6] and the PLoP (Pattern Language of

Programming) conference started by the Hillside group in 1994 [4].

I had had very little contact with this growing community. I had long

wanted to read books that described conceptual models, because I felt such

books would give me good ideas. I didn't feel I could write about such things

until I had enough models to form a worthwhile book. I was interested in the

patterns movement and I found many of their principles appealing, but I was put

off by the impression of a cliquey group that was obsessed with the architect

Christopher Alexander and had a very stylized form of pattern writing. In the

last year I have had more contact and attended the second PLoP. The most

noticeable aspect of the patterns community is that it is quite a diverse group.

Yes, there are those who seem to regard Alexander's works as sacred text, with

alternative interpretations to be argued over. There are also plenty of those who

dismiss Alexander as irrelevant. There are those who seem to see a mystical

virtue in patterns, and those who can't stand the "touchy-feely" aspect of

patterns. There are those who see patterns as overturning analysis and design

methods, those who see conceptual modeling as a waste of time, and those who

have encouraged me to produce this book to show what analysis, or conceptual,

patterns can be like.

The idea of software patterns is not confined to the object-oriented com-

munity; David Hay has written a valuable book on data model patterns [7]. The

models follow relational data modeling style, but they are very conceptual

models. This makes the models valuable even if you are using object technology.

剩余358页未读，继续阅读

pict_jxl

粉丝: 0
资源: 2

面向对象分析模式：可重用对象模型解析

分析模式：可复用的对象模型(Analysis.Patterns:Reusable.Object.Models)(中英版)

《分析模式：可重用对象模型》--责任模式

《分析模式：可重用对象模型》--观察和测量

马丁·福勒的《分析模式：可重用对象模型》

05-03-分析模型-01-分析模型报告1

COM 技术内幕-微软组件对象模型

面向对象分析与设计：分析模式与重用对象模型

马丁·福勒的《分析模式》：可重用对象模型解析

面向对象分析模式探索：重用与模型设计

分析模式 可复用的对象模型 pdf

最新资源

分析模式可复用的对象模型 pdf