Chap面向对象的软件设计方法.pptx

《Chap面向对象的软件设计方法.pptx》由会员分享，可在线阅读，更多相关《Chap面向对象的软件设计方法.pptx（50页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设计用例分析与设计4.34.3概念模型和顶层架构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第1页/共50页2基于UML的分析与设计UML是独立于软件开发过程的，它几乎可以用于任何类型的软件开发过程，包括瀑布式、迭代式、螺旋式等不同模型。在软件分析和设计中，可以根据项目的特征、开发组织在已有实践中定义的相关规范、设计人员本身的偏好等因素，对基于UML的软件设计过程

2、进行定制。第2页/共50页3基于UML的分析与设计过程第3页/共50页4内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设计用例分析与设计4.34.3概念模型和顶层架构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第4页/共50页5案例：银行ATM自动柜员机的需求简述 本案例将要开发的ATM系统能够为顾客提供以下基本服务（它们统一称为交易）：取款服务。顾客可以用银行卡从对应的账户中支取现金，现金必须是100元的整数

3、倍，且每次取款不能超过2000元。存款服务。顾客可以把现金存入与银行卡对应的账户中。转帐服务。顾客可以把一个银行卡对应的账户中的款项转帐到另一个银行账户中。查询服务。顾客能够查询一个银行卡对应的账户中的余额。第5页/共50页6（1）确定用例采用用例模型描述系统需求时，首先需要开发人员从业务需求描述出发获取参与者（Actor）和场景，对场景进行汇总、分类、抽象，形成用例。场景是从单个参与者的角度观察目标软件系统的功能和外部行为，这种功能通过系统与用户之间的交互来表示。场景是用例的实例，而用例是某类场景的共同抽象。第6页/共50页7获取场景目标软件系统有哪些参与者？参与者希望系统执行的任务有哪些？

4、参与者希望获得哪些信息？这些信息由谁生成？由谁修改？参与者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？系统将通告参与者哪些事件？第7页/共50页8定义用例在场景确定之后，通过对场景的汇总、分类归并、抽象即可形成用例。需要特别注意的是，参与者并只限于人员，其它与目标软件发生交互的外部实体或系统也是参与者；用例应该是对参与者可见的系统需求或功能，否则不能作为用例。第8页/共50页9ATM案例的参与者“顾客”（Customer）“操作管理人员”（Operator）“银行服务器”（Bank System）“读卡器”（Card Reader）“存款器”（Cash Acceptor）“取

5、款器”（Cash Dispenser）“打印机”（Printer）第9页/共50页10ATM案例的用例“取款”（Withdrawal）“存款”（Deposit）“转帐”（Transfer）“查询余额”（Inquiry）“开机”（System Startup）“关机”（System Shutdown）第10页/共50页11（2）生成用例图生成用例图是一个逐步精化的过程，首先可以建立初步的用例图，包括前面发现的参与者和用例；然后对用例图进行细化，定义用例之间“包含”、“扩展”、“继承”等关系，并可能需要定义新的用例，以能够更准确地使用用例图描述系统需求。第11页/共50页12生成初步用例图第12页

6、/共50页13用例图的细化包含（include）关系扩展（extend）关系 继承关系 第13页/共50页14细化后ATM用例图第14页/共50页15（3）用例描述对用例的完整描述包括用例名称、参与者、前置条件、一个主事件流、0到多个辅事件流、后置条件。主事件流表示正常情况下参与者与系统之间的信息交互及动作序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。第15页/共50页16“取款用例”描述用例名称：Withdrawal参与者：Customer，Bank System，Card Reader，Cash Dispenser，Printer前置条件：顾客已插入银行卡，密码验证正确，顾

7、客按下“取款”按钮主事件流：1.顾客输入取款金额，并确认。2.系统认可取款金额，并发送指令给取款器。3.取款器把相应金额的现金送出。4.打印机打印回执。辅事件流：1.如果取款金额不是100的整数倍，则显示信息“输入金额必须是100的整数倍，请重新输入”，并返回主事件流中步骤（1）。2.如果取款金额超过2000元，则显示信息“输入金额不能超过2000元，请重新输入”，并返回主事件流中步骤（1）。3.如果账户余额小于取款金额，则显示信息“账户余额不足，请重新输入”，并返回主事件流中步骤（1）。4.顾客在确认取款金额前可以选择取消交易。后置条件：如果取款成功，系统从账户余额中减去相应数额，并返回等待

8、状态；如果顾客取消交易，则返回等待状态。第16页/共50页17用顺序图描述用例第17页/共50页18内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设计用例分析与设计4.34.3概念模型和顶层架构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第18页/共50页19（1）概念模型设计在用户需求和相关的业务领域中，往往有一些全局性的概念对于理解需求至关重要，因此，有必要抽取这些概念，研究这些概念之间的关系。UML类图非

9、常适合用来建立领域概念模型，描述在问题域中存在哪些主要概念和对象，并表示出它们之间的关系，例如关联、聚集、继承等。为建立以UML类图表示的领域概念模型，首先必须标识关键概念。第19页/共50页20关键概念的来源（1）业务需求描述、用例说明；（2）业务领域中的相关规范、标准、术语定义。（3）反映业务领域知识的既往经验。第20页/共50页21分析类描述概念模型的UML类图主要由分析类组成。分析类是指直接服务于用户功能性需求的概念层面的类，它们与待开发软件系统的具体实现技术无关。概念层UML类图也可以称为分析类图。第21页/共50页22三种分析类边界类。负责目标软件系统与参与者之间的交互。控制类。作

10、为完成用例任务的责任承担者，负责协调、控制其它类共同完成用例规定的功能或行为。实体类。负责保存目标软件系统中具有持久意义的信息项并向其它类提供读、写信息项内容的必要操作接口，一般不涉及业务逻辑处理。第22页/共50页23（2）顶层架构设计顶层架构的主要目的是为后续的分析和设计活动建立一种结构和划分，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推进，框架中的内容不断丰富、翔实，最终演进为完整的面向对象软件结构。第23页/共50页24顶层架构设计顶层架构的设计可以把体系结构设计方法与概念模型得到的结果

11、结合起来考虑，利用一定的体系结构模式（例如分层模式、模型视图控制器MVC模式等）对概念模型中的相关元素进行组织，同时需要考虑目标软件系统与其它作为参与者的外部系统之间的联系和交互方式。UML包图非常适合于表示软件顶层架构，可以从某种视角将具有比较密切的关联的一些类划分为一个包，分属不同包的两个类之间的关联则比较松散。第24页/共50页25内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设计用例分析与设计4.34.3概念模型和顶层架构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计

12、精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第25页/共50页26用户界面设计的内容用户界面包含两方面内容：首先要完整地包括用户在使用软件过程中所需的各种元素，例如窗口、菜单、按钮、输入文本框、选择列表、提示信息等，缺乏这些元素中的某些将会导致软件功能无法被用户正常完成；其次要求具有良好的外观和布局，例如背景颜色、按钮等元素的位置、选择列表中条目的顺序等，这些因素的不足可能不会影响软件功能的正确使用，但会给用户带来不便、迷惑甚至反感。第26页/共50页27用户界面的层次和结构层次：屏幕窗口用户界面的结构可以由UML类图描述，屏幕和窗口用类进行表示，并给出它们之间的关系。用构

13、造型和分别表示屏幕和窗口。而屏幕之间的切换过程可以用UML状态图表示。第27页/共50页28屏幕结构类图第28页/共50页29屏幕变化状态图第29页/共50页30屏幕结构包图第30页/共50页31内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设计用例分析与设计4.34.3概念模型和顶层架构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第31页/共50页32持久数据模型设计步骤确定设计模型中需要持久保存的类的对象及

14、其属性，其中实体类是主要关注对象。确定持久存储的数据之间的组织方式。确定数据模型中的操作行为，例如数据完整性验证、数据读取、存储与更新、数据求和、求数据平均值等。进一步优化持久数据操作的性能，例如使用数据索引、存储过程、触发器等方式。第32页/共50页33关系数据库建模可以把类对应于关系数据模型中的表格（table），对象对应于记录（record），属性对应于表格中的字段（field）或者列（column）。第33页/共50页34数据模型第34页/共50页35内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设计用例分析与设计4.34.3概念模型和顶层架

15、构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第35页/共50页36设计精化的任务（1）精化软件架构（2）调整软件组成类（3）精化交互模型（4）精化类之间关系第36页/共50页37（1）精化软件架构精化软件架构的主要目的是寻找一种理想的包划分方案，使得每个包中直接包含的类的数量规模适中，包的边界清晰、自然，并且包间的耦合度较低。随着分析和设计不断深入，原有包图中的包可能包含了过多的类，此时需要对其进行分拆。按照软件工程强内聚、松耦合的原则，这种分拆应该具

16、有某种自然划分的性质，并且尽可能降低划分以后的子包之间的耦合度。第37页/共50页38有关原则避免包间的循环依赖关系，即，排除包P1依赖于包P2、P2又依赖于P1的情形。在层次结构中，位于较低层次的通用包不应当依赖于较高层次中的专用包。在层次结构中，较高层次的包可以依赖于较低层次的包，但应尽量在相邻的层次间发生。如果针对某些子系统专门划分了接口包和实现包，那么，其它与该子系统相关的包只能依赖于接口包，不能依赖于实现包。第38页/共50页39（2）调整软件构成类增加辅助类合并相互通信频繁的类 分拆规模过大的类 第39页/共50页40（3）精化交互模型对交互图进行精化时，需要考虑以下内容：要考虑软

17、件架构和组成类被调整之后对交互模型会产生哪些影响，新出现的对象或拆分后的对象如何参与交互过程，在其中起到什么样的作用。对象在交互过程中的消息传递需要哪些参数和返回值。交互过程是否需要细化，例如增加必要的消息，或对局部引用一个更加具体的交互图。第40页/共50页41（4）精化类之间的关系根据这些连接的语义强度将它们精确地判定为UML的依赖、关联、聚合或构成关系之一；确定连接的方向及参与连接的类对象之间的数量对应关系；根据软件复用的要求及软件结构简洁化、清晰化的要求，优化类之间的关系。第41页/共50页42内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设

18、计用例分析与设计4.34.3概念模型和顶层架构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第42页/共50页43类设计的任务（1）对类的属性与操作进行精化。（2）对类的对象实例在其生命周期中对外部消息的响应和状态变化过程进行建模。（3）对类中重要操作的实现过程或算法进行描述。第43页/共50页44（1）精化类的属性与操作对于类的每项属性，在设计模型中，可以定义属性的名称、类型、初始值、取值范围及属性说明，后三项内容是可选的。操作的基本内容包括名称、参数表

19、（含参数的名称和类型）、返回类型、功能描述。如果操作比较复杂，还需要用文字或UML活动图说明操作的实现算法。第44页/共50页45（2）类的行为模型设计针对整个类使用UML状态图描述其行为。针对类中某些重要的方法，用UML活动图描述其执行过程或步骤。第45页/共50页46内容4.14.1基于基于UMLUML的分析与设计过程的分析与设计过程4.24.2用例分析与设计用例分析与设计4.34.3概念模型和顶层架构设计概念模型和顶层架构设计4.44.4用户界面设计用户界面设计4.54.5数据模型设计数据模型设计4.64.6设计精化设计精化4.74.7类设计类设计4.84.8部署模型设计部署模型设计第46页/共50页47部署模型设计的内容最终开发完成的软件包括哪些制品形式；软件运行环境存在哪些类型的物理节点；不同节点之间的连接和通信形式是什么；软件制品应该如何在物理节点上进行部署，即它们的部署映射关系。第47页/共50页48ATM系统部署模型第48页/共50页49第49页/共50页50谢谢您的观看！第50页/共50页