新软件建模技术2_设计.ppt

1、分析阶段的总结,系统开发的分析阶段强调对需求、概念和操作的理解。这个阶段的调查和分析的焦点是要找出问题是什么-概念是什么、过程是什么，等等。,6设计阶段的开始,在这个阶段中，将开发出一个基于面向对象的系统的逻辑解决方案。这个解决方案的核心是要建立交互图（interaction diagram），它能够展示为了满足系统需求各个对象相互之间如何进行通信。 在交互图建立之后，接着要建立设计类图（design class diagram），它对要实现的软件类（和接口）的定义进行总结。,6.1描述真实用例,真实用例能够展示出用例是如何具体设计实现的。 创建真实用例是一个开发周期的设计阶段中最初要进行的活

2、动之一。创建真实用例要以前面已经建立好的基本用例为基础。 真实用例描述了用例的真实的或实际的设计情况，要涉及到具体的输入输出技术和系统的整体实现等方面（如图形窗口的描述以及底层的交互等）,6.2交互图,交互图（interaction diagram），展示出多个对象之间如何通过消息传递来协作完成任务。这些消息交互的出发点是为了满足操作契约中的后置条件。 UML中定义了2中交互图，两者都能够表达相似或完全相同的消息交互： 1）协作图 2）顺序图,6.3建立协作图,1）在当前的开发周期中，为每个要开发的系统操作建立一个单独的图，其中每个系统操作消息都作为这个单独的图的其始消息。 2）如果这样绘制的

3、图太复杂，那么将这个大图分成若干个小图 3）使用操作契约和契约的后置条件以及用例描述文档作为起点来设计一个系统。这个系统是为完成任务而进行交互的各个对象的集合。,6.4协作图的基本表示法 -类和实例的表示法,在一个交互图中展示一个类的实例的时候，使用类的图框，但是类的名字要加下划线。除此之外，在一个协作图中，类名称之前总带一个分号。,6.5链的表示法,链是两个实例之间的连接路径，它表明在两个实例之间具有某种形式的可见性联系和导航关系。,6.6消息的表示法,在对象之间传递的消息用一个带有标记箭头的链线来表示。一个链线上可以承载任何数量的消息流动。每个消息上带有一个顺序号来表示在当前的控制线程下，

4、消息的传递顺序。,6.7参数的表示法,消息所带的参数用圆括号括起来，跟在消息名后。参数的类型可以写在参数后也可以不写。,6.8返回值的表示法,消息名后面可以写上返回值的变量名和一个赋值符号（“：=”）。返回值的类型是可选的。,6.9传送到“self”或“this”的消息表示法,一个对象可以向自身发送一个消息。用一个指向自身的链来表示，所发送的消息在这个链上流动。,6.9迭代的表示法,迭代可以通过在消息序号上附带一个*来表示。这样的表示法说明消息在一个循环中反复的被发送给接收者。 为了表示在同一个迭代子句中要发送多个不同名的消息，在每个消息上都要加上迭代子句。,6.10职责分配模式 -职责和方法

5、,职责（responsibility）：一个类或类型的契约或者义务。职责与对象在行为上的义务密切相关。 职责基本上可以分为两类（做型、知道型）,6.11“知道”(knowing)型职责,知道自己的私有的、封装了的数据 知道与自己密切相关联的对象信息 知道自己派生出来或计算出来的事物,6.12做型职责,自己完成某件任务 发起其他对象执行动作 控制和协调其他对象类的活动,在面向对象的设计中，职责是分配给对象的。 将职责转换为对应类的方法要受到职责粒度的影响。 职责的履行是通过方法来实现的。实现职责的方法要么是一个单独起作用的方法，要么是与其他方法和对象进行合作的方法。,6.13职责和交互图,在UM

6、L制品中，通常是在建立交互图这个背景之下来考虑对象职责分配（通过方法来实现）。,6.14专家模式,将一个职责分配给信息专家掌握了为履行职责所必须的信息的类 优点： 1）封装能够得以维持，因为对象只使用他们自己所包含的信息来完成任务。封装支持低耦合度（low couling），低耦合度会提高系统的健壮性和可维护性 2）系统行为只分布在具有所需信息的类中，这样能够使类具有聚合度高的“轻量级”类定义，这样定义的类容易被理解也容易被维护。支持高聚合度（high cohesion）,6.15创建者模式,将创建一个类A 的实例的职责指派给类B的实例，如果下列条件满足的话： B聚集了A对象 B包含了A对象

7、B记录了A对象的实例 B要经常使用A对象 当A的实例被创建时，B具有传递给A的初始化数据（也就是说B是创建 A的实例这项任务的信息专家。） 那么B是A对象的创建者。,6.16低耦合度原则,在分配一个职责时要保持低耦合度 耦合度（coupling）是一个类与其他类关联、知道其他类的信息或者依赖其他类的强弱程度。 一个具有低耦合度（弱）的类不依赖于太多的其他类。 一个具有高耦合度的类要倚赖于很多其他的类。这样的类不受欢迎，他们有如下问题:其他类定义的改变会迫使这个类改变其自身的局部定义;难以孤立的理解它;难以重用，因为要使用这个类，需要它所倚赖的其他类也同时存在,6.17高聚合度原则,在分配一个职

8、责时要保持类的高聚合度。 将复杂性保持在可控制范围之内。 聚合度或内聚度（cohesion）（更具体地说，是功能聚合度）是对一个类中的各个职责之间相关程度和集中程度的度量。一个具有高度相关职责的类并且这个类所能完成的工作量不是特别巨大，那么它就是高聚合度。,6.18控制者原则,将处理系统事件消息的职责分派给代表下列事物的类： 代表整个“系统”的类 代表整个企业或组织的类 代表真实世界中参与职责的主动对象类 代表一个用例中所有事件的人工处理者类 使用同一个控制者类处理同一个用例中的所有的事件,6.19协作图：enterItem,enterItem系统操作发生在一个出纳员录入了顾客所要购买的商品U

9、PC和数量的时候。,契约：,如果是一次新的销售交易，则一个Sale实例被创建 如果是一次新的销售交易，新生成的Sale实例与POST发生关联 一个SalesLineItem实例 被创建 这个生成的 SalesLineItem实例与Sale发生关联 该SalesLineItem实例的quantity属性被设置 SalesLineItem实例与一个ProductSpecificition实例发生关联，这个关联建立在两者UPC匹配的基础上,选择控制者类,第一个选择是要为系统操作消息enterItem选择控制者。根据控制者模式，有如下的选择： 代表整个“系统”的类POST 代表整个企业或者组织的类St

10、ore（商店） 代表真实世界中参与职责的主动对象Cashier（出纳员）,显示商品描述信息和价格,按照一个叫做模型-视图分离的设计原则，领域对象没有与用户界面层交互的职责。因此显示商品描述信息和价格在现在可以暂不考虑,创建一个新的Sale实例,为了使系统正确执行，在软件设计过程中必须要考虑契约所表达的需求如何被满足。这个契约的后置条件是： 如果是一次新的销售交易，则一个Sale实例被创建 如果是一次新的销售交易，新生成的Sale实例与POST发生关联,创建一个新的SalesLineItem实例,一个SalesLineItem实例 被创建 这个生成的 SalesLineItem实例与Sale发生

11、关联 该SalesLineItem实例的quantity属性被设置 SalesLineItem实例与一个ProductSpecificition实例发生关联，这个关联建立在两者UPC匹配的基础上,6.20协作图EndSale,当一个出纳员按下一个表示一次销售结束的按钮后，EndSale 系统操作就发生了。 后置条件：SalesComplete属性设置为TRUE。,选择控制者类,专家模式是第一个要考虑的模式，除非所要处理的问题是控制问题或是实例创建问题。 基于控制者模式：继续选择POST作为控制者类,显示信息,在契约endSale的职责陈述中要求销售总额（sale total）必须被显示出来。

12、谁该负责显示这个信息？（如在一个图形化窗口中显示） 根据模型-视图分离模式，领域对象（如sale,post）应该不知道窗口对象或者一个表示层对象的信息，或者不与这些对象联系 但是销售总额必须为某个对象所知晓,6.21计算销售总额,1）陈述职责：谁负责了解销售总额？ 2）总结出所需要的信息： 销售项总额是所有销售项记录金额的总和； 销售项记录金额：=销售项记录的数量*产品价格,6.22协作图： MakePayment,一个Payment实例被创建 Payment.amountTendered的值被修改 Payment 与Sale实例之间形成关联 Sale实例与对应的Store实例之间形成关联，将

13、已经完成的销售项添加到商店的历史记录中。,选择控制者类,首先考虑如何处理系统操作消息makePayment。 继续使用POST来作为一个控制者类（对一个用例的操作使用同一个控制者类是通常的做法）。,创建支付项Payment,POST(一个POST在逻辑上记录了一个Payment) SALE(Sale将使用一个 Payment),另一种寻找创建者类的方法是运用专家模式：找出谁掌握了创建实例所需的初始化数据（顾客所支付的金额）。POST是接收系统操作 makePayment(amoutTendered)消息的控制者，因此它具有初始化所需的数据。,按照低耦合和高聚合模式来考虑。若选择Sale作为Pa

14、yment的创建者，那么POST的工作量就会轻些；再者，POST不需要知道一个Paymentt实例的存在，因为它能通过Sale间接知道这个信息。,6.24记录销售项,根据系统需求，一旦交易完成，Sale的信息就应当被保存在一个历史日志中去。 职责陈述： 谁负责了解所有的已经被记录的Sale，并且承担记录任务？ 让一个商店来知道所有的已经被记录的Sale，并且承担记录任务是合理的，因为这些销售项对商店的财政状况有很大的影响。（经常要使用）。,6.24计算余额,根据职责段的陈述，要求必须已经计算出应找还给顾客的余额（balance），将其打印在一个收据上并显示在一个显示器上。 鉴于模型-视图分离原

15、则，目前不用仔细考虑余额如何被显示及打印出来，但是必须保证余额是可知的。,谁负责计算余额呢？,为了计算余额，需要知道销售总额和付款额，根据专家模式：Sale和Payment是解决这个问题的部分专家。,6.25协作图：StartUp,大部分系统，都有一个StartUp(启动系统)的用例和与启动应用系统有关的初始化操作。,6.26应用程序如何启动,StartUp这个系统操作抽象地代表一个应用程序开始执行的初始化阶段。 一个常规的设计惯用法是创建一个初始化领域对象（initial domain object），它是整个系统中第一个被创建的领域对象。在这个对象的初始化方法中，它负责初始化其他领域对象。

16、 StartUp操作的协作图代表了当初始化领域对象被创建时所发生的事情，以及当它取得控制权时所发生的事情。,6.27POST系统的StartUp操作,当一个管理员打开了POST系统的电源并且程序加载后，StartUp系统操作就开始执行。假设系统中有一个图形用户界面，并且一个表示层中的对象将负责创建初始化领域对象。,选择初始化领域对象,代表整个逻辑信息系统的类（POST) 代表整个企业或组织的类(Store),Store-Create()协作图,一个Store、一个POST、一个ProductCatalog、和一个ProductSpecfication实例被创建 ProductCatalog与ProductSpecfication之间形成关联 Store与ProductCatalog之间形成关联 Store与POST之间形成关联 POST与Produ