序列图/协作图来表示在系统运行时，完成该用例功能系统的内部协作关系。
序列图和协作图是等价的，在Rose中，可以将序列图自动转换成等价的协作图，协作图也可以自动转换成相应的协作图。到底采用哪种建模元素，完全取决于项目的实际需要，而且，这两种图只需要构造其中的一种就可以了。在一般的实时系统中，一般采用序列图，在序列图中，能够清楚地看到各个对象之间交互时的时间与顺序关系。而在其他的不强调时间与顺序的情况下，使用协作图来表示对象间的关系。
在对管理系统的动态建模中，根据不同用例的不同情况，我选择了这两种建模机制，当比较强调时间或顺序时，可以选者选择序列图或顺序图来表示，下面是以“入住宿舍”的顺序图。见下图6 （入住宿舍顺序图）。
在创建用例的序列图的过程中，应该注意各个类的初级设计，即发现各个类的方法和属性，而且，一般在此阶段发现的类的属性和设计都是非常重要和关键的，当然对于这个阶段发现的方法和属性不需要进行严格的定义，对方法和属性的严格定义可以放在设计阶段去完成；但是，对于每一个发现的方法和属性应该记录下来，可以使用文字进行详细的描述。对于方法，如果能够确定其参数，返回值，也必须进行描述，或者将其定义确定下来。在创建和验证UML的过程中，要做如下工作：
² 对于某个类，如果已经存在方法和属性，要详细描述，能够准确定义的，则需要进行准确定义。
² 对于某各类，如果发现新的方法或属性，也要进行详细描述，描述应该包括参数，返回值，功能等等。
² 如果在建模过程中，需要增加一些类或删除一些类，或对一些类进行合并，验证后，要立即修改相应的类图。
图6 "入住宿舍” 顺序图
在对所有用例的序列图创建过程中，也是经过这样的步骤，逐渐来增加该类的方法和属性的。物品进出管理类在此阶段发现的方法和属性简要归纳如下，对于这些属性和方法的描述性的：
物品进出类：
属性：
pInformation：保存物品进出信息。
方法：
GetInformationt：得到物品信息。
ConflictCheck：冲突检测。
NotifyUser：通知用户。
AddInformation：增加新的结果
在上面的物品进出宿舍类的方法和属性会随着分析和设计的不断深入和迭代开发的不断进行而增加和优化；上面给出的属性和方法是一些不可缺少的，在以后的迭代中被修改的可能性也比较少，当然，也可能会被修改，这些方法和属性的确定，对一个类来说是非常重要的。
应该确定一些类的对象的状态图，当然这些类必须具有一些非常明显的状态。在宿舍管理系统中，没有发现那些类的对象具有或可能具有的一系列的状态，对于一些对象只具有一到两个状态，就没有必要为其建立相应的状态图。
在对宿舍管理系统创建分析模型之后，应该进行设计模型的创建阶段，这是RRUP第7步和第8步中所规定的工作。
设计阶段的工作，在整个项目的开发过程中是一项非常重要的工作，该阶段完成的模型在最后直接向代码进行转化。所以，设计阶段的工作必需在分析阶段所确定的模型的基础上进行，它所设计每一个类在分析阶段都是存在的，如果发现确实需要增加的类，则需要在分析模型中增加该类，并验证是否确实需要增加；在设计阶段，不赞成过多地回头去增加或删除分析模型中的类。
在设计阶段的工作，简单来说，是根据分析模型，建立相应的设计模型。
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>