第12章节UML例子-2.ppt

12.5小结 本章从一个开发者角度来理解问题。 在风险、重要性、合适性的基础上考虑系统的一些用例。对于每一个用例，用事件流来寻找实体对象、控制对象和边界对象。然后，用顺序图来描述对象之间的交互。最后，用类图来显示对象之间的关系。 分析时利用协作对象以及定义这些对象的类来描述解决方案。它集中关注这些对象的职责和行为，并忽略实现技术。 这样，就从相关人员和开发人员这两个角度来对系统有一个很好的认识。这个认识为在下一个阶段找到一个系统的解决方案（技术选择、架构以及设计）打下坚实的基础。 第12章 案例-续 * 再前一个方法是LoginWorkflow请求UserLocator对象来寻找用户名代表的User对象。虽然现在还不清楚LoginWorkflow对象是怎么知道UserLocator对象的，但是可以放心地假设任何对象都可以使用专用的UserLocator对象。其中的细节将在设计的时候考虑。当然，UserLocator对象必须能够定位任何User对象，这是它的本职工作。 第12章 案例-续 * 再前一个方法是EmployeeLoginUI对象请求LoginWorkflow对象来验证登录信息。虽然我们不清楚EmployeeLoginUI对象是怎么知道这个LoginWorkflow对象的，但我们可以很合理地认为这两个对象是相互协作的一对，或者是EmployeeLoginUI创建了LoginWorkflow，或者是它们都是由同一个应用级的对象创建的。其中的细节将在设计的时候考虑。虽然LoginWorkflow对象本身不执行这个任务，但它知道从什么地方得到这个信息。这是控制对象的本性。 当然，EmployeeLoginUI对象懂得如何显示一个登录窗口并接受用户的输入。我们还不清楚参与者和EmployeeLoginUI是如何连在一起的。这取决于实现的策略，因而可以等到设计阶段再来决定。 第12章 案例-续 * 4．其他用例的顺序图和类图 下图显示了“Extract Time Entries”和“Record Time”用例的顺序图和类图，其中仅有少量的说明。这些图完善了分析模型，它们本身并没有引入任何新技术或者问题。 第12章 案例-续 * 第12章 案例-续 * 第12章 案例-续 * 第12章 案例-续 * 第12章 案例-续 * 12.4描述类 类之间的关系是支持事件流中对象之间的交互所必需的。 通过为每一个用例创建类图来完成。 意味着，同一个用例的几个顺序图将共享一个类图。 记住，每当一个对象调用另一个对象的方法的时候，在这两个对象之间就存在关系。 在分析阶段，将完全确定实体类之间的关系，而对边界类与控制类以及控制类与实体类之间的关系，只是进行简单的判断。 第12章 案例-续 * 从一个对象发往另一个对象的每条消息都需要一个从发送对象的类到接收对象的类之间的关系。确定这个关系的类型却有点复杂。 在分析阶段，这个关系可能比较难确定，因为这里没有方法参数。 幸好，这种关系的确定在分析阶段并不重要。 第12章 案例-续 * 12.4.1描述类的准则 在描述一个支持某个用例的类的时候，应该遵循如下三条准则： 1)完整。 在顺序图中的每一个消息在相关联的类中都有一个对应的方法。 在一个对象向另一个对象发送消息的时候，它实际上是调用接收对象中实现的方法。所以，每一个消息都必须对应着类中的一个方法。 为了发送一个消息，发送对象必须有一个可以导航到接收对象的关系。接收对象可以回复一个返回值，但它并不需要导航到发送者。 建立类之间的关系的方向是很重要的。 2)保持简单。 第12章 案例-续 * 3)维持类的一致性。 每一个用例的新事件流都会在已有的类中引入新的方法。这种现象将随着大量的用例中出现的大量的事件流而加剧，这样要保持类中方法的一致性就很难。 所以，在顺序图完成以及类随着顺序图中发现的行为而更新之后，这些类就需要复查(reexamined)。类中积聚的某些方法可能并不合适，或者和类所声明的职责有较大的差别。在这种情况下，这些方法必须要重新分配，以使每一个类都是一个一致的整体。 第12章 案例-续 * 12.4.2描述类的步骤 描述类有三个步骤： 1)将对象的行为合并到类中。 2)重构类，使其符合准则。 3)发现类之间的关系。 将利用“Withdraw Funds” 来分别介绍这些步骤。 1．合并行为 在“Withdraw Funds” 中只有一个顺序图，即如下图所示。 第12章 案例-续 * 第12章 案例-续 * 在实际的系统中，每一个用例都有一个类图以及很多的顺序图。支持多个用例的类可以出现在其所支持的每一个用例图中。 消息是在接受对象中实现的。每一个对象的行为完全是由实例化这个对象的类决定的。所以，对每一个消息，我们识别出接收对象的类，