一些软件建模中的问题，大家帮忙侃侃

[happyjun2000]

//=========================================
// 一个问题是关于开发类图、时序图：
//=========================================

用例确定之后，一般是开发类图、时序图。

但是在开发类图、时序图的时候，我应该怎么做？

1.
看了一些书，上面说，先分析场景，就是先依据用例的基本路径，先画个简单的对象交互图（时序图），在这个过程中发现和寻找对象，然后归纳出一些概念类。

2.
一位大哥，以及我在网上看的一些经验说，可以先通过CRC法/泳道法来提炼对象，然后画出对象交互图（时序图）。

这两种方法，好象类图、时序图产生的顺序是不一样的？到底是谁先？或者说是同时进行？

感觉1.是摸索对象和消息交互同时进行，2.是分开进行。


//=========================================
// 另一个问题是关于软件建模：
//=========================================

1.
书上推荐，可以选择性的进行领域建模，然后进行系统建模，在领域建模的时候只考虑领域内的东西，可以有用例、时序、类图等来描述不同方面，在系统建模的时候，也有用例、时序、类图等，但是会从系统的角度去考虑，比如会引进界面UI对象等元素，在用例实现的对象交互时序图中，就考虑界面UI了。


2.
但是一位大哥学习的是《领域驱动》认为在对象交互时序图的时候绝对不能考虑界面UI，或者说他根本就是在领域建模，或者说他（忽略/不建立）系统模型中的对象交互时序图。

另外，我画的对象交互时序图，有时候可能和用例中的步骤是相似的，所以别人看了以后觉得，这样的对象交互时序图没有价值。
但是，我觉得用例中的步骤是和用户交流的，如果文字的不直观，还可以辅助以活动图（当然活动图可能也和用例的文字描述是一样的，就是换了个图表示，图文并茂），而对象交互时序图是描述对象消息交互的，动态的，所以就算是看起来和用例中的步骤一样，重复，但是因为它的侧重面是消息交互，而且如果到了分析后期，当类中的方法基本确定，方法可以作为消息交互，直接加到时序图中（rose中是支持的），也有其价值。

以上我理解的不知道是不是正确，对于以上的一些情况，大家怎么看，请大家指点。谢谢！

[happyjun2000]

to saucer(思归)

您说的有道理，在这里引入了界面元素，可能还太早了。
但是在这里是否考虑权限等元素呢。

下面我讲述一下我原来的理解：

参照RUP的过程，我原来是这么理解软件的模型的。

1.
业务模型
业务模型包括许多东西，主要依据实际需要选择，不讨论。
比如说，业务用例寻找以及业务用例的描述。
举个例子：
小王说，我在单位主要做两件事情：
1.客人的东西拿过来了，我保管起来。
2.客人来拿东西，我确认后，将东西给客人。
那么这里对组织来说，也许就有两个业务用例：
1.客人——托管东西
//客人——业务参与者，小王——业务工作者，业务实体——托管记录名细、托管费用、客户凭证等
2.客人——拿东西
//同上

2.
系统模型
2.1
系统用例模型
//这里只考虑用例描述的功能需求，其他需求略
情况一：
如果这是一个给客户使用的全自动的托管货物系统：
那么系统用例应该有：
1.客人——托管东西
2.客人——拿东西
托管东西，拿东西的过程都是电脑完成了，那么小王也就等于失业了。
那小王说，我不能失业，因为机器不能自动的维护货物的分类。
那这里系统应该还有一个用例：
3.？——维护货物类别
托管公司研究，说，既然这样，那么小王，这个系统有了，你要么失业，要么做系统维护/管理员。
那么3.用例其实就是：
3.系统维护/管理员——维护货物类别
系统还有一些潜在要考虑的元素，可以形成一些用例：
比如安全，那么就需要用例：
4.用户——登陆
5.系统管理员——维护用户
//这些系统元素，有些书也推荐不要这么早考虑
//因为，这个系统是一个不需要用户登陆就可以使用的系统，那么4、5用例在这里也就不需要
所以这里的系统用例，就有：
1.客人——托管东西
2.客人——拿东西
3.系统维护/管理员——维护货物类别

情况二：
如果这只是一个半自动化的，提高小王工作效率的OA系统。
那么系统用例就应该有：
1.保管员——处理客户保管
2.保管员——处理客户取货
3.保管员——维护货物类别
这个时候要考虑安全等元素：
4.用户——登陆
5.系统管理员——维护用户

2.2
系统分析模型
//引入了系统的元素，例如：界面、权限等。
2.2.1
系统概要分析
概要分析主要产生概念类（类图），概念对象之间的交互（时序图）
概要分析步骤：
方法一：分析场景，在描绘时序图的同时寻找对象，对象和交互同时迭代产生。
方法二：CRC/泳道法先寻找对象（实际也是分析场景，通过用例描述等场景，用CRC划分/活动图），然后绘制对象交互。
2.2.2
系统详细分析
详细分析主要研究对象之间的交互，精化概念类到说明类（描述方法，接口）。
方法：对应时序图中的消息精化类。

2.3
系统设计模型
2.3.1
系统概要设计
2.3.1.1确定设计规则
2.3.1.2确定构架风格，参考构架模式
2.3.1.3划分包/子系统
2.3.2
系统详细设计
2.3.2.1依据设计目的分离/重组类，参考设计模式等
2.3.2.2伪代码设计（算法等）

//其他视点模型略

以上是我原来的理解。

本来觉得既然是系统的模型，那么系统是有界面、权限等元素的，就需要在系统模型中体现出来。

但是那样做的话，的确十分的烦琐。

参照saucer(思归)大哥说的，我觉得在系统模型里面，
首先考虑的可能还是业务模型中比较核心的对象，但是用例和业务用例不同，如上所述（系统情况一、二的用例），系统用例和业务用例是有很大不同和区别的，业务用例做系统用例的参考。

既然是这样，那么其实系统用例一开始也就不要考虑界面、权限等比较烦琐的东西了。
也就是说用例：
4.用户——登陆
5.系统管理员——维护用户
一开始不用考虑。
系统对象交互中，也不必要描述界面等对象的交互。

然后，
到了最后的层次，看要不要精化模型，如果需要的化，再加上界面、权限等元素，这个时候建立的系统模型，才可以说是比较完整的。
前面的只是系统的核心模型，要不要精化到这么完整的系统模型，看需要。

觉得如果到了很详细的模型，维护起来就很吃力了，很耗时间，很多时候需要的是系统的核心模型。

以上一些想法，受知识和经验的限制，请大哥们指点。
另，大哥们告诉我不要拘泥于方法、过程，不要为了文档而文档，我也知道，这里只是搞清楚一点。

[happyjun2000]

to saucer(思归)

>>>>另一个问题是关于软件建模：

领域建模是关键，系统建模只是针对当前系统的。界面UI设计是另一类设计，在系统设计时一般不会考虑的

是的，界面UI设计是另一类设计。
但是界面UI觉得是特殊的设计，我分为两类设计，
一个是考虑它的外观，就是考虑界面美观等，
另一个的设计，就是将它作为对象，不考虑外观，要知道系统用例也是用例，用例是因为用户才有价值的，所以他的交互是出于用户的要求，和用户交互的，那么用户最直接的交互对象就是界面，用户对界面提出的一些需求，可以潜在的挖掘为界面对象的方法，然后引导挖掘其他对象的潜在方法。

以上的想法不知道有没有道理？
saucer(思归) 大哥指正！

[saucer]

>>>另一个的设计，就是将它作为对象，不考虑外观.....

如果你指的是大的方面，对外面的用户来说，界面即系统(input/output)，一般不会把界面单独作为一个独立的对象的

而且一般而言，在这个阶段，这里涉及的对象是指满足责任的对象，讨论MVC里的V对象好象还为时过早

[happyjun2000]

2.1
系统用例模型
此中考虑了业务用例演化的两种具体系统的用例。

还有一点问题的是，
在
2.2
系统分析模型
如果不考虑，例如：界面、权限等，也暂时不考虑mvc等设计技巧，
那么基本上系统分析模型的对象交互就等同于业务模型对象中的交互，因为对象基本是一样的。
一般业务模型中可能不怎么需要具体到描绘对象的交互，如果已经描述了，
虽然业务用例和系统用例不一样了（一般来说，系统用例 <=业务用例范围），
感觉还是在描述业务模型中的对象。

也许我讲的不怎么明白，还是请大哥们侃侃！

[happyjun2000]

没有大哥过来看了吗？

:<

[sunstone0]

没有实践过,
但我说学的应该是用泳道法确定类,然后用时序图来确定类所拥有的方法.

业务模型可以用来描述现有的业务并且对现有的业务流程进行改进.

系统模型是根据改进后的业务模型进行建模,将要素用系统中的要素来表示,比如说系统中的操作者可以是时间.

大家一起来讨论

[seekg]

县记者，过会回来看

[saucer]

>>>>1.业务模型 业务模型包括许多东西，主要依据实际需要选择，不讨论。

customer <--> business worker <--> business process (托管记录名细、托管费用、客户凭证)

>>>>2.系统模型

Because you have changed your business process

customer <--> system (托管记录名细、托管费用、客户凭证)

administrator <--> system (维护货物类别,维护用户)

>>>>情况二：如果这只是一个半自动化的，提高小王工作效率的OA系统。

not that you cannot talk about security, just that you don't want to talk about how the login screen looks like

same, because the business worker (保管员) is doing the job for the customer, system still works on the customer's info, not the business worker's

customer <--> system (login)
customer <--> system (保管、取货)

administrator <--> system (维护货物类别)
administrator <--> system (维护用户)

>>>>2.2 系统分析模型//引入了系统的元素，例如：界面、权限等。

I still think it is too early to talk about 界面. You can say, you are going to have a login screen, the user has to enter name/password, that is it. But you can talk about 权限, which defines what the users can do

[saucer]

>>>>2.2
>>>>系统分析模型
>>>>如果不考虑，例如：界面、权限等，也暂时不考虑mvc等设计技巧，
>>>>那么基本上系统分析模型的对象交互就等同于业务模型对象中的交互，因为对象基本是一样的。

not true, in 业务模型中, you might say

customer <--> business worker to do something

but in 系统分析模型中, you actually have

customer <--> system to do something

even if the business worker is doing the work for customer

but if your system needs somthing like "process by which business worker" recorded, then you need something like

1. business worker <--> login
2. customer calls in to check out something
3. buiness worker finds the customer info (say, a CustomerObject)
4. CustomerObject.Checked(BusinessWorkerName)
...

[DragonLancer]

学习，听课……

[sky]

大佬们来了，我们就听课了。

[happyjun2000]

体会，

分析模型正如saucer(思归) ( ) 信誉：368 大哥说的，不要考虑太多其他东西，

要考虑的话，（如果觉得需要）也许在设计模型的用例实现中可以完整的描绘一下所有对象（界面、权限、实体等）之间的交互。

[yesry]

建议下载一个方便交流的软件
http://duceland.com/cn/download/designer.zip

[EdwinYeah]

试答第一个问题：
use-case确定后，要找出实体类、控制类和边界类。

找实体类的方法是画类图。

而找控制类和边界类的方法是通过通过sequence diagram和VOPC(view of participating classes，即参与了sequence diagram的类图，两者是1对1关系。
通过sequence diagram 可以找出对象和对象之间的消息通讯。随着迭代，对象可以整理为类，而消息对应的是类的责任，即操作。

这个过程称做use-case realization,即use-case实现。

[happyjun2000]

to EdwinYeah(Edwin)

谢谢大哥。

大哥说的，
找实体类的方法是画类图。
呵呵，不是很理解。
觉得实体类的来源应该是参考用例描述中的对象，甚至可以说是从领域类的一部分演化。

而找控制类和边界类的方法是通过通过sequence diagram和VOPC(view of participating classes，即参与了sequence diagram的类图，两者是1对1关系。
同意，但是应该是属于后期迭代中处理的事情了。因为 mvc就想死鬼大哥说的本身就已经涉及到了设计了。

[dgfhz]

经典，谢谢你们的例子，我想没你们的例子我是一点都看不懂的!占个座。。。

[binkingaker]

占个座，好好听

[dapanda]

学习，准备向这方面进攻。。。

[tiaoci]

关于 “一般不会把界面单独作为一个独立的对象的” 不同意

一般用例分析最先引出的就是 Boundary 和 Entity，

这也是用例模型的一个总要用途， 如果仅是出于 领域建模的话

那倒是可以不考虑Boundary的

[chatterley]

看来我以后真的得常来看看了!