Chap4面向对象的软件设计方法.ppt

Chap4面向对象的软件设计方法.ppt

《Chap4面向对象的软件设计方法.ppt》由会员分享，可在线阅读，更多相关《Chap4面向对象的软件设计方法.ppt（50页珍藏版）》请在冰豆网上搜索。

第四讲：

面向对象的软件设计方法,董威，文艳军，陈振邦国防科技大学计算机学院,软件设计与体系结构,2,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,2,3,基于UML的分析与设计,UML是独立于软件开发过程的，它几乎可以用于任何类型的软件开发过程，包括瀑布式、迭代式、螺旋式等不同模型。

在软件分析和设计中，可以根据项目的特征、开发组织在已有实践中定义的相关规范、设计人员本身的偏好等因素，对基于UML的软件设计过程进行定制。

3,4,基于UML的分析与设计过程,4,5,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,5,6,案例：

银行ATM自动柜员机的需求简述,本案例将要开发的ATM系统能够为顾客提供以下基本服务（它们统一称为交易）：

取款服务。

顾客可以用银行卡从对应的账户中支取现金，现金必须是100元的整数倍，且每次取款不能超过2000元。

存款服务。

顾客可以把现金存入与银行卡对应的账户中。

转帐服务。

顾客可以把一个银行卡对应的账户中的款项转帐到另一个银行账户中。

查询服务。

顾客能够查询一个银行卡对应的账户中的余额。

6,7,

（1）确定用例,采用用例模型描述系统需求时，首先需要开发人员从业务需求描述出发获取参与者（Actor）和场景，对场景进行汇总、分类、抽象，形成用例。

场景是从单个参与者的角度观察目标软件系统的功能和外部行为，这种功能通过系统与用户之间的交互来表示。

场景是用例的实例，而用例是某类场景的共同抽象。

7,8,获取场景,目标软件系统有哪些参与者？

参与者希望系统执行的任务有哪些？

参与者希望获得哪些信息？

这些信息由谁生成？

由谁修改？

参与者需要通知系统哪些事件？

系统响应这些事件时会表现出哪些外部行为？

系统将通告参与者哪些事件？

8,9,定义用例,在场景确定之后，通过对场景的汇总、分类归并、抽象即可形成用例。

需要特别注意的是，参与者并只限于人员，其它与目标软件发生交互的外部实体或系统也是参与者；用例应该是对参与者可见的系统需求或功能，否则不能作为用例。

9,10,ATM案例的参与者,“顾客”（Customer）“操作管理人员”（Operator）“银行服务器”（BankSystem）“读卡器”（CardReader）“存款器”（CashAcceptor）“取款器”（CashDispenser）“打印机”（Printer）,10,11,ATM案例的用例,“取款”（Withdrawal）“存款”（Deposit）“转帐”（Transfer）“查询余额”（Inquiry）“开机”（SystemStartup）“关机”（SystemShutdown）,11,12,

（2）生成用例图,生成用例图是一个逐步精化的过程，首先可以建立初步的用例图，包括前面发现的参与者和用例；然后对用例图进行细化，定义用例之间“包含”、“扩展”、“继承”等关系，并可能需要定义新的用例，以能够更准确地使用用例图描述系统需求。

12,13,生成初步用例图,13,14,用例图的细化,包含（include）关系扩展（extend）关系继承关系,14,15,细化后ATM用例图,15,16,（3）用例描述,对用例的完整描述包括用例名称、参与者、前置条件、一个主事件流、0到多个辅事件流、后置条件。

主事件流表示正常情况下参与者与系统之间的信息交互及动作序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。

16,17,“取款用例”描述,用例名称：

Withdrawal参与者：

Customer，BankSystem，CardReader，CashDispenser，Printer前置条件：

顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮主事件流：

顾客输入取款金额，并确认。

系统认可取款金额，并发送指令给取款器。

取款器把相应金额的现金送出。

打印机打印回执。

辅事件流：

如果取款金额不是100的整数倍，则显示信息“输入金额必须是100的整数倍，请重新输入”，并返回主事件流中步骤

（1）。

如果取款金额超过2000元，则显示信息“输入金额不能超过2000元，请重新输入”，并返回主事件流中步骤

（1）。

如果账户余额小于取款金额，则显示信息“账户余额不足，请重新输入”，并返回主事件流中步骤

（1）。

顾客在确认取款金额前可以选择取消交易。

后置条件：

如果取款成功，系统从账户余额中减去相应数额，并返回等待状态；如果顾客取消交易，则返回等待状态。

17,18,用顺序图描述用例,18,19,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,19,20,

（1）概念模型设计,在用户需求和相关的业务领域中，往往有一些全局性的概念对于理解需求至关重要，因此，有必要抽取这些概念，研究这些概念之间的关系。

UML类图非常适合用来建立领域概念模型，描述在问题域中存在哪些主要概念和对象，并表示出它们之间的关系，例如关联、聚集、继承等。

为建立以UML类图表示的领域概念模型，首先必须标识关键概念。

20,21,关键概念的来源,

（1）业务需求描述、用例说明；

（2）业务领域中的相关规范、标准、术语定义。

（3）反映业务领域知识的既往经验。

21,22,分析类,描述概念模型的UML类图主要由分析类组成。

分析类是指直接服务于用户功能性需求的概念层面的类，它们与待开发软件系统的具体实现技术无关。

概念层UML类图也可以称为分析类图。

22,23,三种分析类,边界类。

负责目标软件系统与参与者之间的交互。

控制类。

作为完成用例任务的责任承担者，负责协调、控制其它类共同完成用例规定的功能或行为。

实体类。

负责保存目标软件系统中具有持久意义的信息项并向其它类提供读、写信息项内容的必要操作接口，一般不涉及业务逻辑处理。

23,24,

（2）顶层架构设计,顶层架构的主要目的是为后续的分析和设计活动建立一种结构和划分，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。

顶层架构是分析和设计的阶段成果的承载体。

随着开发过程的推进，框架中的内容不断丰富、翔实，最终演进为完整的面向对象软件结构。

24,25,顶层架构设计,顶层架构的设计可以把体系结构设计方法与概念模型得到的结果结合起来考虑，利用一定的体系结构模式（例如分层模式、模型视图控制器MVC模式等）对概念模型中的相关元素进行组织，同时需要考虑目标软件系统与其它作为参与者的外部系统之间的联系和交互方式。

UML包图非常适合于表示软件顶层架构，可以从某种视角将具有比较密切的关联的一些类划分为一个包，分属不同包的两个类之间的关联则比较松散。

25,26,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,26,27,用户界面设计的内容,用户界面包含两方面内容：

首先要完整地包括用户在使用软件过程中所需的各种元素，例如窗口、菜单、按钮、输入文本框、选择列表、提示信息等，缺乏这些元素中的某些将会导致软件功能无法被用户正常完成；其次要求具有良好的外观和布局，例如背景颜色、按钮等元素的位置、选择列表中条目的顺序等，这些因素的不足可能不会影响软件功能的正确使用，但会给用户带来不便、迷惑甚至反感。

27,28,用户界面的层次和结构,层次：

屏幕窗口用户界面的结构可以由UML类图描述，屏幕和窗口用类进行表示，并给出它们之间的关系。

用构造型和分别表示屏幕和窗口。

而屏幕之间的切换过程可以用UML状态图表示。

28,29,屏幕结构类图,29,30,屏幕变化状态图,30,31,屏幕结构包图,31,32,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,32,33,持久数据模型设计步骤,确定设计模型中需要持久保存的类的对象及其属性，其中实体类是主要关注对象。

确定持久存储的数据之间的组织方式。

确定数据模型中的操作行为，例如数据完整性验证、数据读取、存储与更新、数据求和、求数据平均值等。

进一步优化持久数据操作的性能，例如使用数据索引、存储过程、触发器等方式。

33,34,关系数据库建模,可以把类对应于关系数据模型中的表格（table），对象对应于记录（record），属性对应于表格中的字段（field）或者列（column）。

34,35,数据模型,35,36,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,36,37,设计精化的任务,

（1）精化软件架构

（2）调整软件组成类（3）精化交互模型（4）精化类之间关系,37,38,

（1）精化软件架构,精化软件架构的主要目的是寻找一种理想的包划分方案，使得每个包中直接包含的类的数量规模适中，包的边界清晰、自然，并且包间的耦合度较低。

随着分析和设计不断深入，原有包图中的包可能包含了过多的类，此时需要对其进行分拆。

按照软件工程强内聚、松耦合的原则，这种分拆应该具有某种自然划分的性质，并且尽可能降低划分以后的子包之间的耦合度。

38,39,有关原则,避免包间的循环依赖关系，即，排除包P1依赖于包P2、P2又依赖于P1的情形。

在层次结构中，位于较低层次的通用包不应当依赖于较高层次中的专用包。

在层次结构中，较高层次的包可以依赖于较低层次的包，但应尽量在相邻的层次间发生。

如果针对某些子系统专门划分了接口包和实现包，那么，其它与该子系统相关的包只能依赖于接口包，不能依赖于实现包。

39,40,

（2）调整软件构成类,增加辅助类合并相互通信频繁的类分拆规模过大的类,40,41,（3）精化交互模型,对交互图进行精化时，需要考虑以下内容：

要考虑软件架构和组成类被调整之后对交互模型会产生哪些影响，新出现的对象或拆分后的对象如何参与交互过程，在其中起到什么样的作用。

对象在交互过程中的消息传递需要哪些参数和返回值。

交互过程是否需要细化，例如增加必要的消息，或对局部引用一个更加具体的交互图。

41,42,（4）精化类之间的关系,根据这些连接的语义强度将它们精确地判定为UML的依赖、关联、聚合或构成关系之一；确定连接的方向及参与连接的类对象之间的数量对应关系；根据软件复用的要求及软件结构简洁化、清晰化的要求，优化类之间的关系。

42,43,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,43,44,类设计的任务,

（1）对类的属性与操作进行精化。

（2）对类的对象实例在其生命周期中对外部消息的响应和状态变化过程进行建模。

（3）对类中重要操作的实现过程或算法进行描述。

44,45,

（1）精化类的属性与操作,对于类的每项属性，在设计模型中，可以定义属性的名称、类型、初始值、取值范围及属性说明，后三项内容是可选的。

操作的基本内容包括名称、参数表（含参数的名称和类型）、返回类型、功能描述。

如果操作比较复杂，还需要用文字或UML活动图说明操作的实现算法。

45,46,

（2）类的行为模型设计,针对整个类使用UML状态图描述其行为。

针对类中某些重要的方法，用UML活动图描述其执行过程或步骤。

46,47,内容,4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计,47,48,部署模型设计的内容,最终开发完成的软件包括哪些制品形式；软件运行环境存在哪些类型的物理节点