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

lodge

原帖由 kissmoon 于 2010-9-27 16:12 发表
我现在的做法是
在系统用例之后 做一步“业务用例”涉及“对象”的分析，并且每个业务用例都增加两个类，一个界面类，一个控制类

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

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

序列图是要说明为了完成某一用例而必须完成的操作
如, 用户登录可以用这样的序列图来说明(管理员相关处理省略)

  用户            界面           登录控制         用户信息预登录表        用户信息库           管理员
   +--登录请求----------------------->+
                            +<--登录许可----+
     +<--申请表------+
     +----登录信息--------------------->+
                                                     +---审核登记---------->+
                                                     +---审核通知----------------------------------------------------------->+
                                                     +<-审核结果------------------------------------------------------------+
                                                     +<-登录信息------------+
                                                     +--用户登录------------------------------------>+
                             +<----登录完成--+
     +<--结果通知------+


根据上面的序列可以拆出以下实体类
登录请求
登录许可
登录信息

拆出画面
登录申请表
登录结果

拆出控制类
登录控制

程序设计时画出系统结构(BLOCK图)把上面的类分配到BLOCK里去
然后,再画处理时的序列, 然后拆出物理类和方法属性

有一个概念必须深刻理解, 系统设计并不是对系统内部处理的设计, 而是对系统将要实现的业务进行描述.
这一点至关重要.

[ 本帖最后由 lodge 于 2010-9-27 21:17 编辑 ]

lodge

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

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

就是这个东东

kissmoon

1、这两个信息是从哪里得来的？
     用户信息预登录表、用户信息库

2、如果这是前面某个步骤抽出来的对象，这个名称是不是有问题，一个叫表，一个叫库？

3、实体里，是不是也要把 用户信息预登录表、用户信息库 这两个加上？

这个序列图象itpub的登录一样：-）

kissmoon

用户            界面           登录控制         用户信息预登录表        用户信息库           管理员
   +--登录请求----------------------->+
                            +<--登录许可----+
     +<--申请表------+
     +----登录信息--------------------->+

对于“登录请求”及“登录信息”这两个不通过界面，直接和控制交互，这样可以吗？
我记得在网上看资料的时候有看到过大概的描述：用户与界面交互、界面与控制交互、控制与实体交互；用户与控制或是用户与实体直接交互，都是不充许的。

kissmoon

原帖由 lodge 于 2010-9-27 21:14 发表


就是这个东东

我这个是不是也可以算是这个东东：-）

lodge

原帖由 kissmoon 于 2010-9-28 08:32 发表
1、这两个信息是从哪里得来的？
     用户信息预登录表、用户信息库

2、如果这是前面某个步骤抽出来的对象，这个名称是不是有问题，一个叫表，一个叫库？

3、实体里，是不是也要把 用户信息预登录表、用户信息库 这两个加上？

这个序列图象itpub的登录一样：-）

这里只是举例说明序列图的画法和用法，至于实体和对象抽的是否准确这
个要结合实际情况才能知道。实际的设计中，用户信息预登录表和用户信
息库是要从用例的事件流描述中抽出来的。特别是用户信息库它是一个真
正的业务实体而且还有可能是一个独立系统（比如ＡＤ）。

lodge

原帖由 kissmoon 于 2010-9-28 08:40 发表
用户            界面           登录控制         用户信息预登录表        用户信息库           管理员
   +--登录请求----------------------->+
                            +

为了简单说明画法和用法，这里省略了很多细节。
为了说明业务功能可以先不去管用户是否可以不使用界面同控制实体交互的问题。
因为在这个系统投入使用之前，控制实体不一定是电脑系统，它可能就是公司的
前台可以直接同用户交互。但是，要注意的是登录表，信息库这些东东是数据存储单元，
它们不能和人直接交互必须通过某个处理才行。上面的图里，把这些细节也省去了。

另外，作为分析序列，它的重点在于分析用户的业务流程和业务实体。
根据系统的复杂性和规模，可以单纯做业务序列（不要界面，控制这些
只有在系统中才会出现的实体），也可以把业务和系统结合起来做（上面
的例子）后者省略了纯粹的业务分析，在一般的信息系统开发中用得多一些，
因为要针对开发人员进行说明。
而前者多用于，财务，税务，银行等行业，因为这些行业的业务流程要符合法律
法规的要求，设计书要提交法律部门审查不适合写太多的技术内容。
不管怎么做，这个序列图都是要说明业务的情况，如果在设计时预先有了系统的
定式，并且试图说明系统的构成则犯了系统分析的大忌。

lodge

原帖由 kissmoon 于 2010-9-28 08:57 发表



我这个是不是也可以算是这个东东：-）

恩，如果加上环境配置，就完整了

kissmoon

现在我做的还是有点僵硬。

灵活是随着经验出来的，继续学习：-）