第9-10章-OOA课件

2020/5/3,1,面向对象方法学与面向对象分析,2020/5/3,2,一、面向对象方法学,面向对象方法学概述面向对象的相关概念面向对象建模三种模型及其图示化对象模型动态模型功能模型,2020/5/3,3,1、面向对象方法学概述,基本原则：尽可能模拟人类习惯的思维方式，使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致传统语言提供的解空间对象实质上却仅是描述实体属性的数据，必须在程序中从外部对它施加操作才能模拟它的行为面向对象方法是一种以数据或信息为主线，把数据和处理相结合的方法面向对象方法把对象作为由数据及可以施加在这些数据上的操作所构成的统一体,2020/5/3,4,面向对象方法学概述（续1）,面向对象方法把程序看作是相互协作而又彼此独立的对象的集合；在许多系统中解空间对象都可以直接模拟问题空间的对象，解空间与问题空间的结构十分一致；减少“语义断层”面向对象方法具有4个要点：客观世界是由各种对象组成，对象分解取代功能分解把所有对象都划分成各种对象类：数据和操作共享继承：按照子类与父类的关系，把若干个对象类组成一个层次结构的系统对象彼此之间仅能通过传递消息互相联系；封装,2020/5/3,5,面向对象方法学概述（续2）,OO=objects+classes+inheritance+communicationwithmessages面向对象就是：既使用对象又使用类和继承等机制，而且对象之间仅能通过传递消息实现彼此通信优点：与人类习惯的思维方法一致稳定性好可重用性好较易开发大型软件产品；可维护性好,2020/5/3,6,2、面向对象的相关概念,对象：描述该对象属性的数据以及可以对这些数据施加的所有操作封装在一起构成的统一体类：具有相同数据和相同操作的一组相似对象的定义实例：由某个特定的类所描述的一个具体的对象消息：要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明方法：对象所能执行的操作，也就是类中所定义的服务（C+中成员函数）,2020/5/3,7,面向对象的相关概念（续）,属性：类中所定义的数据，它是对客观世界实体所具有的性质的抽象（C+中数据成员）封装：使用一个对象的时候，只需知道它向外界提供的接口形式，无须知道它的具体实现继承：子类自动地共享基类中定义的数据和方法的机制；单继承、多重继承、同名屏蔽多态性：在类等级的不同层次中可以共享一个行为的名字，然而不同层次中的每个类却各自按自己的需要来实现这个行为重载：当参数特征不同或被操作数的类型不同时，实现函数的算法或运算符的语义是不相同的；函数重载、运算符重载,2020/5/3,8,3、面向对象建模,建立问题模型：为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述通常模型由一组图示符号和组织这些符号的规则组成，利用它们来定义和描述问题域中的术语和概念建模过程：系统分析员从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型,2020/5/3,9,面向对象建模（续1）,用OO方法开发软件的关键：是对问题域的理解通常需要建立3种形式的模型：对象模型：描述系统数据结构动态模型：描述系统控制结构功能模型：描述系统功能一个典型的软件系统组合了上述3方面内容：它使用数据结构(对象模型)，执行操作(动态模型)，并且完成数据值的变化(功能模型),2020/5/3,10,面向对象建模（续2）,用面向对象方法开发软件，在任何情况下，对象模型始终都是最重要、最基本、最核心的在整个开发过程中，3种模型一直都在发展完善：OOA阶段：构造出完全独立于实现的应用域模型OOD阶段：把求解域的结构逐渐加入到模型中OOP阶段：把应用域和求解域的结构都编成程序代码，并进行严格的测试验证,2020/5/3,11,4、对象模型,对象模型是对模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构在建立对象模型时，我们的目标是从客观世界中提炼出对具体应用有价值的概念需要用适当的建模语言来表达模型：图示符号UML：统一建模语言，1997年OMG规定通常使用UML提供的类图来建立对象模型,2020/5/3,12,（1）类图的基本符号,类图描述类及类与类之间的静态关系1）定义类UML中类的图形符号为长方形，用两条横线把长方形分成上、中、下3个区域（分别放类的名字、属性和服务类命名原则：使用标准术语；使用具有确切含义的名词；简洁的而且无二义性的,2020/5/3,13,类图的基本符号（续1）,2）定义属性UML语法：可见性属性名：类型名=初值性质串可见性有三种：公有的(public)、私有的(private)和保护的(protected)，分别用加号(+)、减号(-)和井号(#)表示；没有默认的可见性类型名表示该属性的数据类型：基本或自定义初值作为创建实例时该属性的默认值性质串列出该属性所有可能的取值，用逗号分隔例如：“发货单”类的属性“管理员”，可描述为：管理员：String=“未定”,2020/5/3,14,类图的基本符号（续2）,3）定义服务UML语法：可见性操作名(参数表)：返回值类型性质串参数表是用逗号分隔的形式参数的序列。描述一个参数的语法：参数名：类型名=默认值类作用域属性：静态数据成员，带下划线类作用域操作：静态成员函数，带下划线,2020/5/3,15,（2）表示关系的符号,类图由类及类与类之间的关系组成类与类之间通常有关联、泛化（继承）、依赖和细化等4种关系1.关联关联表示两个类的对象之间存在某种语义上的联系通常关联是双向的，可以双向取不同的名字黑三角表示关联的方向,2020/5/3,16,1）普通关联,最常见的关联关系，只要在类与类之间存在连接关系就可以用普通关联表示图示符号是连接两个类之间的直线（见前页）重数：表示该类有多少个对象与对方的一个对象连接，写在关联直线两端01表示0到1个对象0*或*表示0到多个对象1+或1*表示1到多个对象115表示1到15个对象3表示3个对象黑三角表示关联的方向若未明确标出，则默认重数为1,2020/5/3,17,2）关联的角色：Role,此关联的对象所扮演的角色（即起的作用）在某些情况下显式标明角色名有助于别人理解类图例如：递归关联,2020/5/3,18,3）限定关联,通常用在一对多或多对多的关联关系中，可以把模型中的重数从一对多变成一对一，或从多对多简化成多对一在类图中把限定词放在关联关系末端的一个小方框内例如：在一个目录内文件名确定了惟一一个文件,2020/5/3,19,4）关联类,引入一个关联类来记录关联的附加信息关联中的每个连接与关联类的一个对象相联系。关联类通过一条虚线与关联连接例如一个电梯系统的类模型，队列就是电梯控制器类与电梯类的关联关系上的关联类关联类与一般的类一样，也有属性、操作和关联,2020/5/3,20,2.聚集,聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系在陈述需求时使用的“包含”、“组成”、“分为部分”等字句，往往意味着存在聚集关系聚集分类一般聚合共享聚合组合聚合图示符号：在表示关联关系的直线末端紧挨着整体类的地方画一个菱形（空心和实心）,2020/5/3,21,1）共享聚合,在聚集关系中处于部分方的对象，可同时参与多个处于整体方对象的构成例如：一个课题组包含许多成员，每个成员又可以是另一个课题组的成员，则课题组和成员之间是共享聚集关系,2020/5/3,22,2）组合聚合,如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失,2020/5/3,23,3.泛化关系：继承,它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息：继承和派生泛化针对类型而不针对实例泛化关系指出在类与类之间存在“一般-特殊”关系图示符号：用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素泛化分类普通泛化受限泛化,2020/5/3,24,1）普通泛化,就是普通的继承关系抽象类与具体类抽象类通常都具有抽象操作。抽象操作仅用来指定该类的所有子类应具有哪些行为在操作标记后面跟随一个性质串abstract,2020/5/3,25,泛化示例,2020/5/3,26,2）受限泛化,可以给泛化关系附加约束条件，以进一步说明该泛化关系的使用方法或扩充方法；预定义的约束有4种：多重、不相交、完全和不完全多重继承、不相交继承如果图中没有指定多重约束，则是不相交继承，一般的继承都是不相交继承,2020/5/3,27,4.依赖和细化,依赖关系：描述两个模型元素（类、用例等）之间的语义连接关系：其中一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素，如果独立的模型元素改变了，将影响依赖于它的模型元素图示：用带箭头的虚线连接有依赖关系的两个类，箭头指向独立的类,2020/5/3,28,依赖和细化（续）,细化关系：当对同一个事物在不同抽象层次上描述时，这些描述之间具有细化关系细化用来协调不同阶段模型之间的关系，表示各个开发阶段不同抽象层次的模型之间的相关性，常常用于跟踪模型的演变图示：为由细化层指向原始层一端为空心三角形的虚线,2020/5/3,29,5、动态模型,动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列所有对象都具有自己的生命周期。其生命周期由许多阶段组成，在每个特定阶段中，都有适合该对象的一组运行规律和行为规则，用以规范该对象的行为。生命周期中的阶段也就是对象的状态状态：是对对象属性值的一种抽象事件：各对象之间相互触发就形成了一系列的状态变化。一个触发行为称作一个事件用UML提供的状态图来描绘对象的状态、触发状态转换的事件以及对象的行为（对事件的响应）,2020/5/3,30,6、功能模型,功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”功能模型由一组数据流图组成；建立功能模型有助于软件开发人员更深入地理解问题域用例图：进行需求分析和建立功能模型的工具用例模型：用用例图建立起来的系统模型；描述的是外部行为者(actor）所理解的系统功能；用例模型的建立是系统开发者和用户反复讨论的结果，它描述了开发者和用户对需求规格所达成的共识,2020/5/3,31,（1）用例图,用例图包含的模型元素有系统、行为者、用例及用例之间的关系系统提供用例的黑盒子方框的边线表示系统的边界描述系统功能的用例置于方框内代表外部实体的行为者置于方框外,2020/5/3,32,1）用例：UseCase,用例：是可以被行为者感受到的、系统的一个完整的功能在UML中把用例定义成系统完成的一系列动作用例通过关联与行为者连接用例具有的特征代表某些用户可见的功能，实现一个具体的用户目标总是被行为者启动的，并向行为者提供可识别的值用例必须是完整的脚本：用例的实例，是系统的一种实际使用方法脚本是系统的一次具体执行过程,2020/5/3,33,2）行为者：Actor,是指与系统交互的人或其他系统，它代表外部实体。使用用例并且与系统交互的任何人或物都是行为者行为者代表一种角色，而不是某个具体的人或物在用例图中用直线连接行为者和用例，表示两者之间交换信息，称为通信联系实践表明，行为者对确定用例是非常有用的面对一个大型、复杂的系统，可以先列出行为者清单，再针对每个行为者列出它的用例,2020/5/3,34,3）用例之间的关系,UML用例之间主要有扩展和使用两种关系，它们是泛化关系的两种不同形式扩展关系：向一个用例中添加一些动作后构成了另一个用例，后者继承前者的一些行为，通常把后者称为扩展用例例如：“售货”用例-“售散装饮料”用例使用关系：一个用例使用另一个用例。抽象用例：如果在若干个用例中有某些相同的动作，则可以把这些相同的动作提取出来单独构成一个用例,2020/5/3,35,含扩展和使用关系的用例图,2020/5/3,36,（2）用例建模,通过用例可以获取用户需求，规划和控制项目获取用例是需求分析阶段的主要工作之一大部分用例将在项目的需求分析阶段产生，并且随着开发工作的深入还会发现更多用例一个用例模型由若干幅用例图组成。创建用例模型的工作包括：定义系统，寻找行为者和用例，描述用例，定义用例之间的关系，确认模型。其中，寻找行为者和用例是关键,2020/5/3,37,1）寻找行为者,找出系统的行为者，可以通过请系统的用户回答一些问题的办法来发现行为者：谁将使用系统的主要功能（主行为者）？谁需要借助系统的支持来完成日常工作？谁来维护和管理系统（副行为者）？系统控制哪些硬件设备？系统需要与哪些其他系统交互？哪些人或系统对本系统产生的结果（值）感兴趣？,2020/5/3,38,2）寻找用例,可以通过请每个行为者回答问题来获取用例：行为者需要系统提供哪些功能？行为者自身需要做什么？行为者是否需要读取、创建、删除、修改或存储系统中的某类信息？系统中发生的事件需要通知行为者吗？系统需要哪些输入输出？输入来自何处？输出到哪里去？当前使用的系统存在的主要问题是什么？一个用例必须至少与一个行为者相关联,2020/5/3,39,7、三种模型之间的关系,这3种模型相互补充、相互配合，使得我们对系统的认识更加全面：功能模型指明了系统应该“做什么”动态模型明确规定了什么时候(即在何种状态下接受了什么事件的触发)做对象模型则定义了做事情的实体,2020/5/3,40,二、面向对象分析：OOA,OOA的基本过程需求陈述三种模型的建立对象模型动态模型功能模型定义服务,2020/5/3,41,OOA的主要工作,分析的过程就是提取系统需求的过程分析工作主要包括：理解、表达和验证分析过程得出的最重要的文档资料：软件需求规格说明（SRS）OOA的关键：识别出问题域内的类和对象，分析它们之间的关系，建立正确模型,2020/5/3,42,1、OOA的基本过程,OOA的定义：就是抽取和整理用户需求并建立问题域精确模型的过程OOA的过程：从分析陈述用户需求的文件开始系统分析员需要反复与用户协商、讨论、交流信息，必要时可快速建立一个原型系统，正确提炼需求系统分析员深入理解用户需求，抽象出目标系统的本质属性，并用模型准确地表示出来OOA得到的分析模型应该成为对问题的精确而又简洁的表示,2020/5/3,43,OOA过程中需要注意的问题,需求陈述通常是不完整、不准确的，而且往往是非正式的；需要分析、改正与补充不应该认为需求陈述是一成不变的，而应该把它作为细化和完善实际需求的基础在面向对象建模的过程中，系统分析员必须认真向领域专家学习注意研究以前针对相同或类似的问题域的分析结果，有些可以在当前项目中重用,2020/5/3,44,个模型与个层次,个模型针对解决问题的不同，各有侧重：几乎解决任何一个问题，都需要从客观世界实体及实体间相互关系抽象出极有价值的对象模型当问题涉及交互作用和时序时(例如，用户界面及过程控制等)，动态模型是重要的解决运算量很大的问题(例如，高级语言编译、科学与工程计算等)，则涉及重要的功能模型动态模型和功能模型中都包含了对象模型中的操作(即服务或方法),2020/5/3,45,个层次,复杂问题的对象模型通常由下述5个层次组成：主题层、类与对象层、结构层、属性层和服务层,2020/5/3,46,主题层,主题是指导读者(包括系统分析员、软件设计人员、领域专家、管理人员、用户等，总之，“读者”泛指所有需要读懂系统模型的人)理解大型、复杂模型的一种机制通过划分主题把一个大型、复杂的对象模型分解成几个不同的概念范畴OOA通过控制读者能见到的层次数目来控制可见性OOA引入主题层，可以从一个相当高的层次描述总体模型，并对读者的注意力加以指导,2020/5/3,47,个层次对应的活动,5个层次对应着在OOA中建立对象模型的5项主要活动：找出类与对象，识别结构，识别主题，定义属性，定义服务OOA大体上按照下列顺序进行：寻找类与对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务注意：分析不可能严格地按照预定顺序进行大型/复杂系统的模型通常，先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来,2020/5/3,48,2、需求陈述,通常，需求陈述的内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等需求陈述应该阐明“做什么”而不是“怎样做”。它应该描述用户的需求而不是提出解决问题的方法应该指出哪些是系统必要的性质，哪些是任选的性质应该避免对设计策略施加过多的约束，也不要描述系统的内部结构,书写要点,2020/5/3,49,需求陈述例子：自动取款机(ATM)系统,某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统,2020/5/3,50,需求陈述例子（续）,银行柜员使用柜员终端处理储户提交的储蓄事务(存款/取款)，一个储户允许多个账户柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户储户使用银行卡可以通过ATM访问自己的账户(取款/查询/转账等)每张银行卡仅属于一个储户所有，但是同一张卡可能有多个副本；系统应该能够处理并发的访问：在若干台ATM上使用同样的银行卡,2020/5/3,51,3、建立对象模型,确定类和对象确定关联划分主题确定属性识别继承关系反复修改,实施步骤,典型的工作步骤是：首先确定对象类和关联(因为它们影响系统整体结构和解决问题的方法)，对于大型复杂问题还要进一步划分出若干个主题；然后给类和关联增添属性，以进一步描述它们；接下来利用适当的继承关系进一步合并和组织类；而对类中操作的最后确定，则需等到建立了动态模型和功能模型之后,2020/5/3,52,（1）确定类和对象,系统分析员的主要任务就是通过分析找出这些问题域中存在的类与对象Step1：找出候选的类与对象可感知的物理实体；人或组织的角色；应该记忆的事件；两个或多个对象的相互作用；需要说明的概念例如ATM系统初步候选者：银行，ATM，中央计算机，分行计算机，网络，储蓄所，柜员，储户，现金，支票，账户，事务，银行卡，余额，分行代码，卡号，用户，副本，密码，类型，取款额，账单，访问分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来，例如：事务日志、通信连路,2020/5/3,53,确定类和对象（续）,Step2：筛选出正确的类与对象仅保留应该记录其信息或需要其提供服务的那些对象筛选原则：冗余、无关、笼统、属性、操作、实现例如：储户和用户、银行卡和卡号、事务日志上例：ATM系统经过初步筛选，剩下下列类与对象：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务、银行卡,2020/5/3,54,（2）确定关联,分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类与对象1、初步确定关联：注意需求陈述中使用的描述性动词或动词词组，如由.组成、包含、负责等例1：分行提供分行计算机和柜员终端例2：储户拥有账户(一对多)隐含：分行保管账户；系统维护事务日志问题域知识获取：银行卡访问账户,2020/5/3,55,确定关联（续）,2、筛选关联，去掉不正确的或不必要的关联原则：已删去的类之间的关联；与问题无关的或应在实现阶段考虑的关联；瞬时事件；三元关联；派生关联。例如：分行计算机维护账户=分行保管账户+事务修改账户3、进一步完善几个方面：选择含义正确的关联名；分解；补充；标明关联的重数例如：总行拥有中央计算机；分行拥有分行计算机；分行拥有柜员终端,2020/5/3,56,经过分析后的ATM系统原始类图,2020/5/3,57,（3）划分主题,在开发很小的系统时，可能根本无须引入主题层对于含有较多对象的系统，则往往先识别出类与对象和关联，然后划分主题，并用它作为指导开发者和用户观察整个模型的一种机制对于规模极大的系统，则首先由高级分析员粗略地识别对象和关联，然后初步划分主题，经进一步分析修改和精炼主题应该按问题领域而不是用功能分解方法来确定主题；应该按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题例如：ATM系统划分为总行、分行、ATM,2020/5/3,58,（4）确定属性,确定属性的过程包括分析和选择两个步骤：分析：确定属性注意需求陈述中的名词词组；领域知识和常识属性的确定与问题域有关，也和目标系统的任务有关应该先找出最重要的属性，暂不考虑用于实现的属性选择：删除不正确或不必要的属性错误的属性情况：误把对象当作属性；误把关联类的属性当作一般对象的属性；把限定误当成属性；误把内部状态当成了属性；过于细化；存在不一致的属性例如：分行名和分行号,2020/5/3,59,系统对象模型中的属性,2020/5/3,60,（5）识别继承关系,确定了类中应该定义的属性之后，就可以利用继承机制共享公共性质继承关系的建立实质上是知识抽取过程，它应该反映出一定深度的领域知识，因此必须有领域专家密切配合才能完成可以使用两种方式建立继承(即泛化)关系：自底向上：抽象出现有类的共同性质泛化出父类自顶向下：把现有类细化成更具体的子类例如：由“远程事务”和“柜员事务”可以泛化出父类“事务”,2020/5/3,61,带有继承关系的系统对象模型,2020/5/3,62,（6）反复修改,由于面向对象的概念和符号在整个开发过程中都是一致的，因此远比使用SA和SD技术更容易实现反复修改、逐步完善的过程有些细化工作(例如，定义服务)是在建立了动态模型和功能模型之后才进行的例如：ATM系统的几处修改分解“现金兑换卡”类“事务”由“更新”组成把“分行”与“分行计算机”合并,2020/5/3,63,修改后的系统对象模型,2020/5/3,64,4、建立动态模型,编写脚本设想用户界面绘制事件跟踪图绘制状态图审查动态模型,实施步骤,在开发交互式系统时，动态模型却起着很重要的作用。建模第一步，是编写典型交互行为的脚本。第二步，从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。最后，比较各个对象的状态图，检查它们之间的一致性。,2020/5/3,65,（1）编写脚本,脚本指系统在某一执行期间内出现的一系列事件脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程编写脚本是保证不遗漏重要的交互步骤脚本描写的范围并不是固定的编写脚本的过程，实质上就是分析用户对系统交互行为的要求的过程在编写脚本的过程中，需要与用户充分交换意见，编写后还应该经过他们审查与修改,2020/5/3,66,编写脚本（续）,编写脚本时，首先编写正常情况的脚本；然后，考虑特殊情况；最后考虑出错情况对交互系统而言，出错处理是重要却难于实现例如：输入非法；异常终止一个操作参见Page248：ATM系统的正常情况脚本和异常情况脚本,2020/5/3,67,（2）设想用户界面,大多数交互行为都可以分为应用逻辑和用户界面两部分应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。动态模型着重表示应用系统的控制逻辑：信息流与控制流在分析阶段也不能完全忽略用户界面：确保能够完成全部必要的信息交换，而不会丢失重要的信息软件开发人员往往快速地建立起用户界面的原型，供用户试用与评价,2020/5/3,68,初步设想的ATM界面格式,2020/5/3,69,（3）绘制事件跟踪图,用自然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图Step1：确定事件事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等正常事件、异常事件和出错条件传递信息的对象的动作也是事件把对控制流产生相同效果的那些事件组合在一起作为一类事件；区分对控制流有不同影响的那些事件应该区分出每类事件的发送对象和接受对象,2020/5/3,70,绘制事件跟踪图（续）,Step2：画出事件跟踪图事件跟踪图描述事件序列以及事件与对象的关系事件跟踪图实质上是扩充的脚本，可以认为事件跟踪图是简化的UML顺序图一条竖线代表