建立序列图之前是不是一定要建立类图？

lodge

原帖由 kissmoon 于 2010-9-26 12:52 发表
在rose里，
在用例视图里 建立 三个包 一个包名为“业务用例”，一个包名为“涉众”，一个包名为“系统用例”
并把 业务用例、actor 、系统用例 存放在相应的包下，
在用例下定义出活动图。
在活动图的基础上绘制系统用例图。

对象是在什么视图下？ logic view ？ 序列图是在什么视图下绘制？
并且 这些 东东，应该怎么组织？

对ＲＯＳＥ不熟，不大理解你说的那几个术语。

系统设计的基本思想有以下几点（个人总结，可能不够权威）
１）程序和系统是对现实世界的事物及其活动的模拟
２）由于用程序构建起来的模拟世界和现实世界很不相同没有可比性，所以要建立一个模型，这个模型既可以抽象出现实世界也可以抽象出模拟世界
３）设计的过程就是先以现实世界为基础，抽象出一个模型（系统设计），再将这个模型还原到模拟世界（程序设计）的过程

ＵＭＬ提供了一个抽象现实世界的方法，这个方法把抽象过程分成了以下几个步骤
１）抽ＵＳＥ　ＣＡＳＥ，就是对已有的做法进行归纳和总结，新手最容易犯的错误
　　就是对将要开发的系统进行归纳和总结反而无视现实世界。要开发的系统并不存在，
　　以它为基础去抽象ＵＳＥ　ＣＡＳＥ会变得很难而且也没有意义，这种情况下最容易
　　产生直接写程序把这个东西做出来看看的冲动。如果只是开造现有业务（如，把已有的
　　人事管理流程改称电子处理流程）则没有必要把业务ＵＣ和系统ＵＣ分开来分析。但是，
　　当使用信息系统去实现一个前所未有的功能时（如把一家超市改成网店）这就需要先针对
　　现有业务作业务ＵＣ并作改进，然后再作有了网络和系统时的系统模型（也就是系统ＵＣ）。

　　另外，ＵＳＥ　ＣＡＳＥ的名称是进行下一步分析重要依据。
　　通常要按照动词＋宾语的方式来命名。如　登记人事信息。
　　其中，动词部分将成为事件流（或者叫活动图）分析的依据而宾语部分就是处理对象的概括。
　　

２）抽出ＵＳＥ　ＣＡＳＥ之后，就为每个ＵＣ作活动图，将上面提到的动词部分拆分到几个更为
　　详细的步骤中去。同时，每个步骤地处理对象也要按照上面的宾语进行拆分。
３）然后，把活动图中定义的名词作为序列图中的对象，为每个ＵＣ做序列图。在分析序列的过程中追加对象是很普通的事情，不需要回过头去修改活动图。
４）把序列图中的对象抽出来做类图，根据序列为类添加方法和属性
５）对类的方法和属性进行详细定义。（如，人事信息的属性，有效值等等）
６）把序列图中定义边界抽出来，做画面设计
７）把序列的先后次序抽出来，做控制类设计
系统设计完成

运行环境＋分析类，为每个ＵＣ作序列然后拆物理类－－这个就不细说了。

lodge

原帖由 kissmoon 于 2010-9-26 12:00 发表
我看 thinking in uml 中的 示例，序列图 里
操作人员----边界----控制类---实体
发起操作-->显示--->处理-->实体

这些边界类和控制类及实体，得在序列图之前做出来吧？

因为画了序列图才知道有边界类和控制类及实体。
分析类的设计恰恰是根据序列图画出来的。

kissmoon

你这么一说，清楚了很多：-）

６）把序列图中定义边界抽出来，做画面设计

   这里的这个边界，需要先定义一个边界类吗？

我现在看的 thinking in uml 里，
感觉这里是先对每个UC定义 边界类 控制类 实体 三个类，然后用这三个类及相关的对象绘制序列图。（对书理解可能也不对）
由边界类向控制类发消息，控制类向对象及实体类发消息。

kissmoon

呵呵，明白了：-）

谢谢 lodge

张恂

原帖由 lodge 于 2010-9-26 12:57 发表

它们是ＥＲ图的主要分析对象。

用了 UML，就不再需要用 ER 图了。

张恂

原帖由 lodge 于 2010-9-26 13:44 发表

因为画了序列图才知道有边界类和控制类及实体。
分析类的设计恰恰是根据序列图画出来的。

不对。

软件实体类很多来自业务领域模型中的业务实体类，它们及其关系的存在并不依赖于画不画序列图，而是事先就可以知道。可以重用业务领域分析的结果，这正是 OO 方法的一大优点。

不过，画了序列图，除了实现用例功能的基本目的外，还可以反过来调整和优化分析类的设计。

不能说，分析类的设计只是根据序列图画出来的，影响分析类设计结果的有多个因素和来源。

张恂

lodge 说的 Block 图是这个吧：

http://en.wikipedia.org/wiki/Block_diagram

kissmoon

原帖由 张恂 于 2010-9-27 11:20 发表
lodge 说的 Block 图是这个吧：

http://en.wikipedia.org/wiki/Block_diagram

这个图的话，怎么做 block 间的序列图？

我感觉只有数据流吧。

kissmoon

我现在的做法是
在系统用例之后 做一步“业务用例”涉及“对象”的分析，并且每个业务用例都增加两个类，一个界面类，一个控制类

这样，序列图就可以做成如下：
操作人员--->界面---->控制类--->对象1---->对象2.......

如此，操作人员只与界面交互，界面与控制类交互，控制类与各个对象交互，
之后，细化界面类、控制类以及对象对应的类。

lodge

原帖由 张恂 于 2010-9-27 11:12 发表


不对。

软件实体类很多来自业务领域模型中的业务实体类，它们及其关系的存在并不依赖于画不画序列图，而是事先就可以知道。可以重用业务领域分析的结果，这正是 OO 方法的一大优点。

不过，画了序列图，除了实现用例功能的基本目的外，还可以反过来调整和优化分析类的设计。

不能说，分析类的设计只是根据序列图画出来的，影响分析类设计结果的有多个因素和来源。

不考虑流程直接定义实体的方法比较类似于传统的DO(DATA ORIENTED), 这个方法在做系统分析时, 首先收集现有业务的单据和报表并绘制DFD, 然后做逻辑ER图在做物理ER图.

偶提到的做法综合了DA和PA(PROCESS ORIENTED), 在这样的设计中业务实体,业务流程都被看成是对象, 可以被抽象成类, 因此它并不违背OO的原则.
另外, 这个手法是花了大把的银子从MS的技术咨询那里学来的,应该说这个流程还是相当的权威滴.