UML第2章 UML-2.pptVIP

2.3.1描述行为 描述行为的目的： 确定实体类、边界类和控制类的对象是如何通过交互来实现用例。 考虑两个部分： 第一，描述行为的一些准则。 第二，描述对象交互的实际过程。 UML用两种图来描述对象间的交互：顺序图和协作图。 顺序图显示了在时间上对象间的交互。顺序图能够让你很容易地跟踪复杂的消息序列，但它不显示对象是如何联系的。 协作图显示对象间的联系，但是，对于复杂的消息序列，它的可读性不强。 第2章 案例-续 * 对象通过调用方法来交互。对象采用这种机制来发送信息，请求服务，或者请求信息。 在面向对象的术语中，这种交互被称为“消息”(message)，它由一个对象发出，并由另一个对象接收。虽然消息是从调用对象的角度来命名的，但是，它的实现是在接收对象中的。 提示： 为了保持清醒，建议一次只考虑一个用例，并分别为每一个用例开发出顺序图和参与的类的视图。 第2章 案例-续 * 1．寻找行为的准则 对象通过协作来完成用例，在识别它们的行为时，你应该遵循如下四个规则： 确认在每种类型的对象内部，它的各个方法是内聚的。 清楚地命名每一个消息。 完全满足用例的所有功能需求。 保持简单。 第2章 案例-续 * 以下详细介绍寻找行为的准则： 1）确保方法之间的内聚性 类的方法必须是连贯的，它们必须满足那个类所描述的职责。 例如，makeToast、makeEggs和makeJuice可以构成完成“make breakfast”职责的密切相关的行为。在Cook类中，它们是很合理的方法。如果我们增加一个changeOil方法，那么这些方法就不再构成一个连贯的职责。 2）采用清楚明确的方法名 从调用对象的角度考虑，必须清楚明确地命名每一个方法。 例如，带有getQuantity和getValue的方法的类不会受到欢迎。 大多数的方法名表明了它的返回类型。例如，getName应该返回一个字符串，该字符串是这个对象的名字串。而叫setHeight的方法，我们不指望它会返回什么，但几乎可以确定它接收一个数字参数来改变对象的高度。 第2章 案例-续 * 3）完全满足用例要求 这需要毅力以及良好的文档工作。 在用例中，每一个事件流的每一个步骤，活动图的每一个活动和条件，都必须可追踪(traceable)到对象的某个或者多个方法。在分析中，对方法的认识可能还不透彻，但是它必须存在。 4）保持简单 在分析时不要太苛求。 任何不明显的参数和返回类型都可以留到设计时去考虑。而且，也没有必要去确定每一个对象的来源，这也就没必要去创建对象间详细的继承层次，或者去争论两个对象间的确切关系。 在设计过程中，整个场景会不断更改和演化，所以就没必要去追求细节的东西。到现在为止，我们只是使用类来放置一些相关的行为而已。 第2章 案例-续 * 描述行为的检查表： 是否每一个方法都有清楚的目标? 是否每一个方法的命名都是名词和动词的强组合? 是否避免采用模棱两可的名字? 是否从调用对象的角度来清楚地命名每一个方法? 对其他开发人员来说，这些名字是否是明确的? 方法的名字是否表明了它的返回类型? 例如，可以很合理的认为一个叫做getDate的请求会返回某种日期对象，而一个叫做repaint的请求则不会指望它能够返回什么东西。 在每一个类中的方法，它们之间是否存在密切关系? 是否每一个类中的方法都符合这个类所声明的职责? 是否每一个类仍然还保持一个具体的目标? 第2章 案例-续 * 2．描述行为的步骤 发现和描述对象之间协作完成某个用例的交互过程可以分为如下三个步骤： 1)将已识别的参与对象加到顺序图中。 2)从参与者开始，一步步寻找行为。 3)从后往前验证行为序列。 第2章 案例-续 * 具体如下： 1．在顺序图中加入参与对象 首先，在顺序图中加入触发这个用例的参与者（Actor）。 然后，加入边界对象（Boundary）。 接着，控制对象（Control）。 最后，实体对象（Entity）。 这个模式屡试不爽。每个用例都是由一个参与者触发的，所以应该最先放置参与者。同样，在参与者和用例间总该有一个边界对象，所以下一个就是放置它了。在边界对象和实体对象间总会有一个控制对象作为联系中介。最后，根据用例的复杂程度，可能会有一堆的实体对象。我们暂时忽略生命周期对象，直到需要它们的时候再说。 第2章 案例-续 * 第2章 案例-续 * 2．从参与者开始分析 显示放置好的对象是如何交互的。 在面向对象的术语中，一个对象向另一个对象发出消息，实际的方法实现是在接受方的对象中。每一个消息都是按照它调用的方法来命名。 由于总是由参与者来触发用例，所以应该由它来发出第一个消息。在UML中，消息用带箭头的实线来表示，这条实线从一个对象的虚线开始，指向另一个对象的虚线。沿着对象的虚线从上到下的顺序表