【讨论/杂谈】关于结构化方法、信息系统方法和面向对象方法～♪

[mis98ZB]

《系统分析与设计》里把软件开发方法分为三种：结构化方法、信息系统方法和面向对象方法。
结构化方法面向过程，基于算法。
信息系统方法面向数据，基于传递和存储。
面向对象方法面向对象，基于协作。

然而，使用DFD就是结构化方法么？使用ER图就是信息系统方法么？使用UseCase就是面向对象方法么？

《系统分析与设计》里说结构化方法与面向对象方法，只不过是使用不同的模型来描述相同的信息。
那么，需要描述的信息是什么？它们各自以什么样的观点来描述这些信息？【note：放眼市面上的书籍，都是需要这种制品、那种制品。然而最终目的、需要表达信息却没有提及。这种买椟还珠的做法，真是让人郁闷而又无奈:(】

面向对象的分析，真的有这种东西存在么？

以上这些问题困扰了我好久好久，现在乘大家质疑UseCase的面向对象性质的时候提出来，希望能听听前辈们的教诲。

[ozzzzzz]

uc图和dfd图的区别当然很大了，而我们关心的应该是uc和dfd的区别。其实搞明白uc你就自然知道他们的区别了，uc主要还是反映用户的角度，体现的是用户的价值，关注的是actor的动作。
而你说的所谓存储的问题，如果系统不是把信息存储在别的系统中，则uc根本就不会涉及这个方面的东西。uc放映的是业务流程，而不是系统的内部运作。而我们需求分析也主要解决的是需求问题，不是具体如何技术实现的问题。如何存储是设计的工作，不是需求分析的工作。而实际上为什么xp一再强调尽早的进入编码，就是看到有些问题比如你说的数据断流的问题，在分析和设计这些阶段根本就很难发现，只能在编码阶段去验证是不是合理。而更进一步TDD干脆就先设立一个检验的标准，让你不断的去试验你自己是不是已经做到你想要做的事情了。
分析类是对于领域概念的抽象，分析模式是对于这些分析类经常出现的场景的分析。当然你可以通过使用分析模式得出分析类，但是就如同设计模式一样，你也可以步通过使用这些分析模式得出分析类。
feature是FDD方法中的一种需求分析元素，它的基础就是领域分析类。一个feature的形式遵守职责、对象、结果这三者的组合方式，把需求划分为粒度统一的一种形式。

[mis98ZB]

开会浪费了一天
@_@
今天晚上好好整理一下思路……

[scalene]

UP.

[mis98ZB]

非常感谢ozzzzzz(希望敏捷)老大孜孜不倦的指导！！
m(__)m

〉〉就算一个对象模型可以分为“结构”和“行为”特性
怎样表达“结构”和“行为”特性呢？
是不是分析模型侧重于表达“行为”特性，而设计模型侧重于表达“结构”特性呢？

〉〉OO 建模人员正在开始进行本质上的流程建模
这是什么意思呢？
是说OO建模实际上是使用OO设计技术的流程建模么？

[ozzzzzz]

给你一篇cockburn的文章看看吧，记得有翻译的，但是我找不到。

An Open Letter to Object Technology Newcomers
Alistair Cockburn , Humans and Technology ([e-mail])
This report is an html draft of HaT.TR.96.02, which may be submitted for external publication . This early version is being made available for professional peer communication. Since this file was auto-converted and touched up, some html marks may be bad. Please let me know if your browser objects.


Intro
It used to be the habit of authors to write an apology for adding another piece of writing to the face of the earth, and a justification. The need for apology still holds, the justification for this article is this: Over the last 6 years, I have spent numerous and pleasant long evenings in restaurants, bars, and hotel lobbies, discussing the nature of object orientation with other interested seekers of truth, light and wisdom. Over the years, we have been able to answer many of the questions we asked at the beginning. The other night I spent such an evening in a restaurant discussing those same questions asked by a new colleague. The next day, his office-mate wanted the same questions answered, and suggested I capture the discussion for his other colleagues to read. Considering the number of like-minded colleagues he has around the world, asking the same questions, it seems sensible to write it for them all to read.
The key questions were:


"Why is it that some OO experts get really upset when I do or say anything that is not strictly and purely object-oriented, but use cases are so popular, while not being object-oriented, and object modeling looks so much like data modeling?"
"Would the model produced by a data modeler look the same or different as the structural part of an object model, and would the model produced by a process modeler look different or the same as the behavioral part of an object model?"
"Why do we use use cases and scenarios, instead of just modeling the structure of the business?"
The questions are asked repeatedly by new arrivals to object orientation, and cannot be answered without having certain experiences. They come right to the heart of working with object orientation on a daily basis. So they are worth receiving consideration and serious response.

[ozzzzzz]

"Why is it that some OO people get really upset when I do or say anything that is not strictly and purely object-oriented, and yet use cases are so popular, while not being object-oriented, and object modeling looks so much like data modeling?"
My answer comes in 3 steps.
"When Bob <invented name for generic OO expert> and I get together to talk about OO, there is a shared understanding we have of each other, that we are experienced and convinced users of object technology. We understand and expect to use object identity, polymorphism, combined data and behavior, instance responsibilities, inheritance. So when I say, 'Tomorrow we'll do data modeling on the application form,', Bob does not think that I have abandoned objects in favor of relational tables, but expects that we are discussing the structural aspects of the situation, which will show up in the object model. He forgives my use or misuse of the term because he has associated certain expectations with my speech.

When Bob visits your organization, just learning object technology, he sees a strict separation of data from behavior, and an absence or neglect of object identity and polymorphism. So when you say 'data modeling', he comes down on you like a ton of bricks. He wants to make sure that you get clear about the shifts you need to make. You will notice that over the last months, your model (and modeling) have slowly acquired object identity, polymorphism, and combined behavior with data. It is perhaps now less dangerous to use the word 'data modeling', but there is the chance that he will think you are sliding back into previous work styles. In other words, he does not have those safe expectations with respect to your speech, and so you are obliged to speak carefully.

In the end, even an object model has structural aspects and behavioral aspects. We use those words to signal that we are not making the mistake of doing 'just' data modeling or 'just' process modeling. In point of fact, modeling the structural aspects is just a particular form of data modeling, being a bit careful with the meaning of the term data modeling. It is not that we are modeling the tables on the disk, but modeling the structure of the information that will be captured. Data modelers refer to this as the 'conceptual data model', as opposed to the logical or physical data model. It is something they regularly produce.

On the other hand, if two OO people are talking, and one starts talking about, 'process modeling', the other does not have a safe interpretation to give. Does the person really mean process modeling with standard data-flow diagram? These have been shown over the years to give great difficulty when going to an OO implementation, and so the conversation is about to enter a difficult period. Does the person mean the behavioral aspects of the model? Does the person mean modeling a process as an object in itself? This is interesting because it is not done that often. So 'process model' is not safe to insert into the conversation because the intent is too ambiguous.

Getting finally to use cases and scenarios, they are primarily requirements-gathering techniques, and are neutral to the implementation technology. They contribute a value in guiding the conversation during design, giving it context and scope. The fact that they are not 'object-oriented' is neither good nor bad. The fact that they resemble functional decomposition scares some people, but is also neither good nor bad. The important consideration is that they contribute value to the design process. When they are used to describe internal designs, they present a picture of the behavior of the system. Procedural code, flow charts, interaction diagrams, Petri nets, data-flow diagrams, use cases, all show aspects of behavior, and have different uses, advantages and disadvantages. As long as you know that objects have behavior as well as data, you can work open the discussion about how best to capture or describe the behavior within and across objects."

[ozzzzzz]

"Would the model produced by a data modeler look the same or different as the structural part of an object model - would the model produced by a process modeler look the same or different as the behavioral part of an object model?"
"In my experience, there are two groups of data modelers - those who model the data on the disk, and those who model the information in the system or in the organization. There is a world of difference between the models they produce and the discussions one can have with them.
Those who model the data on the disk talk and think in concrete terms, often in terms of tables. Their models are often quite different from OO models, and they are unwilling to see the similarities that exist across the technologies. In the data modeling community, it is legitimate to say that these people produce logical or physical data models, without being insulting.

Those who model the information in the system produce the conceptual data model. My experience is that the models they produce are very similar to the models produced by experienced OO modelers. These people typically work a lot closer to the business people than do the logical data modelers, which perhaps explains the difference in their results.

Also, there seems to be a body of knowledge, lore, training, or examples that let these people come to their results faster than OO people do. I have time and time again seen OO people go through three or four design iterations, ending up with the same model that the (conceptual) data modelers produced on the first round. So I have a lot of respect for the data modeling community. In fact, when I get stuck in the object design, I sometimes run and snatch a copy of what the data modelers produced, to look at where we are likely to end up.

I had the experience of facilitating a session between warring data and object modelers. We decided to do 'CRC sessions for an audience'. The four experienced OO designers sat around one end of a long table and were the only active participants. The business experts sat next along the table. They were there to answer questions and correct misstatements about the business. After them were the data modelers. At the far end of the table were other interested people. All told, there were over a dozen people in the room, but only four active people, talking mainly among themselves.

After about an hour of work, a section of the object design had emerged. We asked the data modelers what they had produced in their previous work, whether it was essentially the same or quite different. They said, 'Essentially the same.' We repeated this for two more segments of the design and got response from the data modelers each time that we had produced essentially the same design as they had, apart from certain obvious differences in notational technology. They had note used inheritance, but had the same placeholders in the same places. After that we were able to split into groups containing one business expert, one data modeling expert and one OO expert, and they quickly reconciled the rest of the design, identifying where there was a simple difference in technology, and sorting out minor differences. Where there was a difference, it sometimes happened that the data modelers had a better rationale, and sometimes the OO models had a better rationale, and the groups were able to resynchronize their designs.

So there have been at least a few experiences showing the similarity between results of conceptual data modeling and OO modeling with CRC cards.

There were also experiences showing the difference between logical (information-on-disk) based relational modeling and OO modeling. For the most part, the differences were due simply to technology, free use of inheritance and many-to-many relations in the OO model. The difficulties came with the inability of the participants to communicate across those technological differences.

So much for the data modeling part of the question.

The same cannot be said at this time for process modeling. Numerous methodologies, plans, conversions and projects were tried in the early 1990's to adapt data-flow diagram models to objects. A few projects may have laid claim to success, but in the end there seems to have been quiet consensus that they are difficult to map to object models. Most data-flow-diagrammers-become-OO-designers have dropped them (the Martin-Odell and Ptech groups being notable exceptions). My answer at this time is that process modelers do not produce a model comparable to what OO modelers produce.

The answer is not closed, though. OO people are beginning to model process per se. It is not clear how this will evolve. Will the processes start looking like steps in a procedure (procedural programming reincarnated), will they look like data-flow diagrams, or will they look like encapsulated objects?

[ozzzzzz]

"Why do we use use cases and scenarios, instead of just modeling the structure of the business?"
"Use case and scenarios ...
... guide the conversation, giving it scope and context,

... indicate what to include, exclude, how wide, how deep to go, and when to stop,

... provide variations to stress-test the design.

I have watched a number of groups do a random exploration of the domain when they model without working from scenarios. How does the leader know what questions to ask next? From intuition guided from some previous experience. How does the group know if they are capturing the information they will eventually need? They often don't, and don't know it, or do know it and use intuition and guesswork.

Several really expert OO designers have confessed in the late of the night that they do not have a straightforward formula for getting to the beautiful objects. One said, "We have really wild discussions at times", another agreed to the notion that, "Sometimes we just beat our heads against the walls until eventually some decent objects show up."

Using scenarios does not prevent wild discussions and beating heads against walls until decent objects show up. Using scenarios provides a context and boundaries for those discussions so that they stay within the area of interest. Without the scenarios, I watch groups go mad as they wander through an arbitrarily large modeling space for days or longer. So the first reason to use scenarios and use cases is to channel the effort.

The second use of scenarios is to determine when you are done.

Consider that you have been given the job of modeling a trucking company. What do you model? Would you include the new purchase value of the trucks... the actual purchase value... the resale value... the make... the color of the interior... the number of speeding tickets issued against it... the number and destinations of its trips? If you try to include everything, you will never finish. Where do you start, when do you stop, what do you include, exclude, and how much detail do you want?

An answer is provided by the scenarios. You need to have sufficient information to deliver all the questions posed by the scenarios. On the structural or full object model, every box (line, phrase) addresses some need of a scenario. If you color the items on the model red as you walk through a scenario, the red items will all be connected in some way (there will be no islands). If you do this for all scenarios, all items will be colored at the end. There are no boxes (lines, phrases) extra, there are no boxes (lines, phrases) missing. Then you are done. During the modeling work, the conversation may go wild from time to time, but there is a way to tell if you have strayed out of the bounds of the current need, or wandered too deep.

Finally, scenarios provide variations to stress test the design and establish its quality.

How do you distinguish the better between two models? Saying, 'It matches the business' is necessary, but not sufficient. There are many possible models that 'match the business.' What is the measure of quality?

Software has a very high cost function associated with making changes. For a change request, the cost grows rapidly with the area of damage (the 'trajectory of change'). The goal for software, then, is to change exactly one module. This will not always be possible, but as Kent Beck says, 'There is a noticeable difference in the quality of the software when you can change just one class.' For a business model, it is less clear what the cost function attaches to, but minimizing area of damage is a reasonable place to start.

To test the trajectory of change, you need variations. The scenarios provide the variations. 'What happens when the user wants to <something-or-the-other>?' How many items on the model do you have to touch? Some techniques, such as the CRC ('class-responsibility-collaborator') technique encourage you to invent impromptu scenarios rapidly, to uncover likely, but unstated future changes. At the end, you review the likely changes, and see how many items you have to alter to make those changes. For two models that match the business, that one is better which has fewer (Kent says, 'One') touched points for each scenario.

You will also find variations in other places, such as the structure of related products. Can you change products touching just one place? Both sources of variations should be used.

There are other uses of scenarios, such as checking requirements with users, and providing functional test cases for the system. These are the three reasons to use scenarios during the modeling activity itself."

[ozzzzzz]

多数情况下结构特征是在说属性，行为特征是在说方法。
OO建模人员正在进行流程建模，是说OO人员也可能会对流程建模。但是OO建模不是就是流程建模，流程建模可能是OO建模的一个部分，但是绝对不是全部。而对于流程的建模，一样可以使用OO的技术，这一点为很多人不理解，主要是他们对流程还不能进行对象化的理解。

[ozzzzzz]

找到翻译的版本了，在umlchina的19期。

致面向对象技术初学者的一封公开信
Alistair Cockburn 著（1996 年2 月），袁峰 译

介绍
首先我要解释一下为什么会写这封公开信。这似乎已经成了一种习惯，但这个步骤还是需要的。过去6 年中， 我曾经无数次地在饭店、酒吧、旅店大厅等各种地方以同一种方式度过愉快而漫长的夜晚：和同样追求真理、光明和智慧的伙伴一起探讨面向对象的真谛。现在，我已经可以回答很多当年我遇到的问题。这些同样的问题也在困扰着我的一位新同事，在一家饭店里，我花了整整一个晚上和他讨论这些问题。结果第二天，他的同事又来问这些问题，并建议把我们的谈话内容记录下来，这样他可以拿去给他的同事看。考虑到还有很多和他的同事一样询问这些同样问题的人，我决定写下这篇文章。
主要的问题是：
z 为什么只要稍有一点不是严格或纯面向对象的做法、说法，OO 专家就大惊小怪的？use case 并不是面向对象的，为什么还这么流行？而且，OO 建模似乎和数据建模非常相似？
z 数据建模（data model）得到的模型和对象模型的结构部分会不会很像？流程建模（process model）和对象模型的行为部分呢？
z 业务结构建模中为什么要用use case 和场景（scenario）?
OO 的新手们反复问这些问题，但实际上，只有在日常工作中坚持应用面向对象的思维进行工作，积累一定的经验，才能得到满意的答案。为什么只要稍有一点不是严格或纯面向对象的做法、说法，OO 专家就大惊小怪的？use case 并不是面向对象的，为什么还这么流行？而且，OO 建模似乎和数据建模非常相似？
我想分三步来回答这个问题。

首先，我举我和Bob（著名的OO 专家）一起工作的例子， 当我们讨论OO 的时候，彼此都有一个共识，知道对方拥有面向对象工作的丰富经验并且是这项技术的坚定支持者。而且，对诸如对象识别（object identity）、多态、数据和行为的封装、实例职责、继承等对象技术都是手到擒来。因此，当我说：“明天对程序表单进行数据建模吧”，Bob 不会产生我要会因为关系表而放弃对象这样的误解，他知道我指的是在对象模型中体现出来的结构化特性进行建模。他知道我会说些什么，因此我使用或误用这些术语不会造成什么误解。但作为一个对象技术的初学者，如果Bob 发现你把数据和行为完全分离开了， 并且没有使用（ 或者说忽视了）对象识别或者多态等技术， 这时候， 如果你说“ 数据建模”，Bob 会像一堵墙一样逼近你，直到你明白该怎样改变。这样工作几个月，你会发现，你的模型（以及建模）中渐渐有了对象识别、多态、数据和行为的绑定，这时候再用“ 数据建模”这个词就不是那么危险了， 但Bob 还可能会担心你走回到老路上。换句话说， 他对你还不够信任， 因此，你不得不很小心地使用这些术语。
就算一个对象模型可以分为“结构”和“行为”特性，我们也不会使用“对象建模”和“流程建模” 这种术语，以免引起混淆。事实上，为对象模型的“结构”特性建模可以看成是数据建模的特殊形式，只不过建模的对象不再是表，而是需要捕获的信息的结构。我们将它称为“ 概念数据模型”，而不是逻辑数据模型或物理数据模型。第二步，让我们考虑两个OO 使用者一起讨论的情况。如果其中一个家伙说到“流程建模”这样的词，肯定会让他的拍档琢磨半天：这家伙是说用标准数据流图作流程建模吗？如果这样的话，以后OO 实现的时候不是相当麻烦了吗？他是不是指模型的行为特性？是不是说在一个对象内部对流程进行建模？（如果这样的话，那会很有意思，因为很少有人这么做的。） 通过这个例子我们可以看到，这种谈话中使用“ 流程建模” 这种意图不明的词实在是太危险了，很容易就将交流变得非常困难。
最后来说use case 和场景的问题，它们都是获取需求的主要手段，和实现技术无关。其好处是可以为设计时的讨论提供内容和范围。它们不是“面向对象”的，这是事实，它们类似于功能分解，这也是事实，而且这一点吓坏了很多人，但这些都无所谓。重要的是它们为设计提供了内容，在用来描述内部设计时，它们表现了系统的行为。Flow chart 、交互图、Petri 网、数据流图、use case 都可以用来描述系统的行为特性， 但各自用途不同，各有优劣。关键是要知道：对象不仅有数据，也有行为， 认识到这一点， 就可以大胆地去考虑怎样可以更好地捕捉、描述对象内部和对象之间的行为。
数据建模（data model ）得到的模型和对象模型的结构部分会不会很像？流程建模（process model） 和对象模型的行为部分呢？根据我的经验，数据建模人员可以分为两种－一种是为存储的数据建模，而另一种是为系统或组织中的信息建模。这两者截然不同。前者讨论和思考所用的概念通常都很具体，比如说数据表。他们的模型和OO 建模者的模型大相径庭，而且他们并不愿意看到这些技术之间的相似性。在数据建模社区中，只有讨论逻辑数据模型或物理数据模型才不会受到攻击后者得到的是概念数据模型。根据我的经验，他们得到的模型和那些有经验的OO 建模者得到的模型非常相似。他们的工作更加类似于业务人员，而不是逻辑数据建模人员，这种说法可能会有助于理解概念数据模型和逻辑数据模型的区别。
似乎有一套学问可以帮助人们比OO 建模人员更快地得到结果。我多次发现这样的事实：OO 建模人员花了三四次迭代才得到的模型，实际上和（概念）数据建模人员一个循环得到的模型是一样的。这个发现使我对数据建模人员充满了敬佩。事实上，在进行对象设计的时候，我有时就直接去把数据建模人员的产品拷贝过来看看， 从中来看我最后得到的模型大概会是什么样的。
我曾经召开过数据建模人员和对象建模人员之间的会议。采取的方法是“ 一个听众的CRC 会议（CRC sessions for an audience）。四个经验丰富的OO 设计师坐在长桌一端，业务专家沿着长桌坐下，他们负责回答问题并纠正对业务的误解。接着是数据建模人员，长桌的另一头是其它有关人员。总的来说，屋里大概是十几个人，但谈话主要是在四个OO 设计师之间进行。
讨论大概一个小时之后，OO 设计师可以得到对象设计的一部分。这时候，咨询数据建模人员，这个模型和他们已经得到的模型本质上是不是一样的。他们说，“是的”，重复这个过程两次以上，每次都询问数据建模人员同样的问题，除了使用的符号技术是不同的，例如：他们没有用继承，但在同样的地方有同样的占位符，在本质上，这个模型和他们的模型没有什么不同的。接着，我们分成几个小组，每个小组包括一个业务专家、一个数据建模专家和一个OO 专家，很快就剩下的设计达成一致，找出技术上一些小的不同之处，并且进行排序。一般情况都是这样的：要么数据建模人员考虑得更加合理，要么OO 建模人员考虑得更加合理，小组要做的是在他们的设计之间进行协调。
从上面的这些经验可以看到，使用CRC 进行OO 建模得到的模型和概念数据建模得到的结果非常相似。另外，根据经验，基于逻辑（存储的信息）的关系建模和OO 建模是不同的。大多数情况下，区别是由于技术的不同导致的，例如，在OO 模型中可以自由地使用继承和多对多的关系。由于技术上的差异，两种建模人员之间不能很好地交流，这是最大的困难。
数据建模部分的问题就说这么多吧。

[ozzzzzz]

对流程建模而言， 情况却不一样了。90 年代初， 涌现出各种方法、计划、会议和项目，试图将数据流图的模型转变为对象模型。曾经有几个项目声称获得了成功，但都是后续无音，业界一致的结论是： 这个转变太困难了。大多数使用数据流图的建模人员最终都抛弃了这项技术， 投入了对象设计的怀抱（Martin-Odell 和Ptech 小组是著名的例外）。对于流程建模，现阶段我的回答是：其模型无法与OO 模型相比较。但这并不是最终的回答，OO 建模人员正在开始进行本质上的流程建模，下一步的发展将会怎样，我也并不清楚，流程将变成过程那样（过程编程复活？）， 或者变成数据流图那样，还是类似于封装的对象？
业务结构建模中为什么要用use case 和场景（scenario）?
use case 和场景……
……为讨论提供范围和内容，
……预示内容，包括什么，不包括什么，讨论多广，多深入，什么时候停止，
……为设计的压力测试提供参数。
我见过一些不使用“场景”的小组，他们建模的时候实际上就是在问题域内作随机的探险。负责人根本不知道下一个该问什么问题？经常都是凭直觉。一般说来，他们也不知道现在捕获的信息最后是否真正需要，就算知道也是凭直觉或者瞎蒙。
在一个寂静的深夜，几个真正专家级的OO 设计师向我说了心里话：根本就没有一个有效的规则来指导漂亮的对象设计。其中一位说，“我们有时真的是在毫无目的地讨论”， 另一位也相当赞同，“有时候我们就象没头的苍蝇一样到处乱撞，直到突然把一些好的对象给撞出来。”
使用场景也不能防止盲目的讨论和到处撞墙，只是可以为讨论提供内容和边界。我曾经见过有的小组不用场景，长时间在很大的建模范围内四处乱撞，失去控制。因此，使用场景和use case 的第一个理由就是为建模的努力提供一个范围。
使用场景的第二个理由是决定需求获取到什么程度算足够。
假设现在让你为一家货运公司建模。你建模的内容是什么？卡车的购买价值……实际价值……转售价值……车内颜色……快送单据的数目……旅途的数目和目的地？如果你想要把所有的内容都包括进来，那你将永远无法结束。除此之外，还有其它的问题：从何处开始，何时结束，包括什么，不包括什么，需要多少细节？ 场景可以回答关于内容的问题，答案是：你需要足以回答场景中所有问题的信息。在结构化模型或完全的对象模型中，如果用一个方框来对应一个场景。然后在浏览场景的过程中将涉及到的元素（译者注：这里的元素， 是比如在OO 的类或对象） 涂成红色， 会发现最后所有的元素都按某种顺序连接起来了（不会有遗漏的元素）。如果对所有的场景都执行这个操作，最后所有的元素都会被涂成红色。在建模过程中，讨论会经常离题，用这种方法可以保证针对当前的需要制定一个边界，这样不会跑题太远。
最后，场景还提供了压力测试的参数以保证质量。
怎样比较两个模型的优劣？ “和业务相符”，这是必要的，但肯定不够，可能有很多模型都可以“和业务相符”，怎样来度量这些模型的质量呢？
软件变更的成本很高，另外，变更越靠后，变更的成本也就越高。（变更成本曲线）。软件设计的一个目的就是将变更隔离开来，每次变更只需改变一个模块。这并不是什么时候都能做到的，正如Kent Beck 所说，“如果你可以只改变一个类， 那软件的质量将得到显著的提高”。和软件相比， 业务模型的成本函数并不是很清楚，但将变更影响的范围降低到最低肯定是应该的。
为了测试变更曲线，需要参数，而场景可以提供这些参数。如果用户想要“something-or-the-other”，怎么办？模型中到底需要多少元素？像CRC（class-responsibility-collaborator ）这样的技术鼓励用户在现场快速得到场景， 揭示可能的未来变更。最后，检查这些可能的变更，检查需要为之改动多少元素。对于两个都“和业务相符”的模型，哪个模型受场景影响的点少一些，哪个模型就要好一些。其它很多地方也可以找到压力测试的参数。例如相关产品的结构，变更时是不是可以只改一点就可以了？在评价模型时，这些参数都应该用上。
场景还可以用在很多地方，例如：同用户一起检查需求，为系统提供功能测试的用例。以上所说，就是在建模活动中采用场景的三个理由。

[mis98ZB]

唉，白白郁闷了好几天:P
研究了手头的六、七本关于分析与设计的书才发现，答案是如此简单:(

UC作为众多捕获需求的方法中的一种，关注的是问题域，是一种需求引导的手段；
DFD则是分析需求的方法，关注的解空间，使一种需求分析的手段。

实际上对于需求工程来说，包含了需求引导和需求分析两种活动。也就是获得需求和分析需求两种活动。
而我关于“面向对象的分析”的概念，完全把上述两种活动混淆了。

真是可怕的误会啊～～～～～

[ozzzzzz]

uc其实不是完全的问题域手段，它也是一种分析需求的手段。我们可以认为，在uc结合了UI的细节之后，这个时候健壮分析把UC的作用还扩大到与实现领域的边界。而这种分析和设计模型之间的联系，是面向对象分析和设计中的一种有利的手段。也就是说在面向对象的方法中，分析和设计之间的区分是没有一个明确的界限的。

[mis98ZB]

不好意思，项目要结了，工作比较多，没有时间来请教。(^_^;)

您说的“健壮分析”是什么呢？
是不是快速验证是否达到业务要求的方法呢？
UC→UI，是不是和快速原型比较相似？

“把UC的作用还扩大到与实现领域的边界”，会不会造成模型的脆弱呢？
《需求工程引导》里面批评DFD就是说，它没有区分问题域与解空间，因此造成模型的脆弱。《UML用户指南》里也有类似的观点。
如果UC涉及实现，是不是也会造成问题域与解空间混淆，因此使模型变得脆弱呢？

[ozzzzzz]

健壮分析，就是rose中那个界面类、控制类、数据类的分析方法。
UC的实现不管怎么样都会和UI挂钩，这就为健壮分析提供了基础。DFD的问题我觉得书上的观点是有道理的，但是DFD造成的分析和设计的无缝连接又是一种优势。而UC的问题在于其只能在需求的领域内发展，所以它只能扩展到实现领域的边界，而不可能进入。为了做的分析模型和设计模型的连接，健壮分析就在这个边界上建了一座桥梁。

[mis98ZB]

嗯……不太明白(^_^;)
界面类、控制类、数据类的分析方法是什么呀？
说来惭愧，我对Rose的使用，只是停留在文档工具的水平上。
连Check Model功能都很少用……

[ozzzzzz]

就是将UC中的数据类－也就是分析模型中的领域类，和UI中的界面类，以及联系这两种类之间的控制类，作一个划分的方法。
有时间我可以给大家具体解释一下这个方法，它可以被认为是rational的官方分析方法。

[mis98ZB]

是不是“Three-Tier Diagram”啊？
就是把图分为“User Services”、“Business Services”和“Data Services”三个泳道的。
而且“Logical View”也分为“User Services”、“Business Services”和“Data Services”三个包。

这么说来，这种格式倒是见过。但是内含指导思想还没有接触过。
嗯，期待ing、具体解释……

[mis98ZB]

呵呵，刚结束了项目的一次跌代。可以抽空进行一些深入一点的思考了:)

最近对需求的定义有些迷惑。什么是需求？问题域究竟是什么？

对于一个开发MIS系统的项目，所得的需求可能是一大堆业务逻辑、执行准则，这些东西可以轻易地消耗掉数包A4打打印纸。

而对于一个开发CASE工具的项目，所得的需求可能只有一句话，例如：获得JSP文件测试的覆盖率。然后进一步的需求分析只能在得出一个句话，定义一行代码被覆盖的条件。直到需求分析结束，我们连一步都没有跨出。

为什么会有这么大的差别呢？

仔细考虑一下第一个例子。
如果我们把需求定义为“建立电子信息平台”，那么上述的需求就是这个需求的逻辑解。
这个逻辑解是如何得到的呢？
客户会提供它们的想法，以前的系统、类似的系统会提供参考。
这样，我们从别人那里取得了解，而我们把这个过程叫做分析。

在想想第二个例子。
得出少得可怜的需求之后，我们开始设计。
我们会想到在JSP文件中插入写log的语句，这样我们就可以通过分析log来获得JSP文件的测试覆盖率。
我们自己得出了问题的逻辑解，而我们把这个过程叫做设计。

难道分析和设计的区别就是转载和原创的区别么！？

[robbit2002]

"为了做的分析模型和设计模型的连接，健壮分析就在这个边界上建了一座桥梁。"
to ozzzzzz:
最近一直在困惑领域模型到设计模型的转化的问题,听到你在这里提到这句话,好像能够找到答案,希望你能对健壮分析多做一些解释.
除了健壮分析之外,还有什么方法来连接这两个模型吗?
我最近一直在想一个问题,是关于uml的系统顺序图的,通过用例描述我们可以捕获actor的系统操作(这时候可以画出系统顺序图),以系统操作为起点,通过领域模型中概念实体间的相互协作(这时候不可回避的要加入一些辅助类)来完成系统操作的功能,这样分析模型就逐渐的向设计模型演化了,不知道我这种想法可取不可取?