面向对象的分析与设计课件-分析篇.ppt

第二部分：分析篇,北京大学信息科学技术学院研究生课程面向对象的分析与设计,主讲教师：邵维忠,2,课件说明 这组课件是本人多年来在北京大学讲授“面向对象的分析与设计”课程时制作的，随着该领域理论与技术的发展而逐年改进。目前的最新版本所适应的教材是邵维忠、杨芙清合写的著作面向对象的分析与设计（清华大学出版社2013年1月）。为了促进学术交流和资源共享，现将这套课件无偿提供给国内讲授同类课程的教师和同行，欢迎他们在教学工作中使用或作为参考。课件共包括“基础篇”、“分析篇”和“设计篇”三部分，是按照54学时研究生课程制作的，各位教师可根据自己的授课对象及教学计划，对原课件进行剪裁或重新组织。北京大学信息学院 邵维忠电子信箱：2013年7月2日,3,第5章建立需求模型用况图,5.1 需求分析和系统分析需求分析的确切含义是对用户需求进行分析，旨在产生一份明确、规范的需求定义。OOA的主要内容是研究问题域中与需求有关的事物，把它们抽象为系统中的对象，建立类图。确切地讲，这些工作应该叫做系统分析，而不是严格意义上的需求分析。早期的OOA缺乏一个良好的基础对需求的规范描述。,4,问题域（抽象的来源）,OOA模型（类图）,抽象,OOA是将问题域中的事物抽象为系统中的对象,5,5.2 基本思路问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的系统？如何规范地定义用户需求？考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述其外部可见的行为。,把内外交互情况描述清楚，就确切地定义了系统的需求,6,系统边界,系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。系统：被开发的计算机软硬件系统，不是指现实系统。系统成分：在OOA和OOD中定义并且在编程时加以实现的系统元素对象,对象,对象,对象,对象,对象,对象,5.3 系统边界与参与者,7,现实世界中的事物与系统之间的关系分四种情况,8,人员系统的直接使用者直接为系统服务的人员设备与系统直接相联的设备为系统提供信息在系统控制下运行不与系统相连的设备 计算机设备 外系统上级系统子系统其它系统,如何发现参与者考虑人员、设备、外系统,9,什么是用况I.Jacobson：用况是通过使用系统功能的某些部分而使用系统的一种具体方式。每个用况包括一个由参与者发动的完整的事件过程。它详细说明了参与者和系统之间发生的交互。因此，一个用况是一个由参与者和系统在一次对话中执行的特定的相关事务序列。全部用况的集合则说明了所有可能存在的系统使用方式。对象技术词典：1对一个系统或者一个应用的一种单一的使用方式所进行的描述。2关于单个参与者在与系统的对话中所执行的处理的行为陈述序列。UML：对系统在与它的参与者交互时所能执行的一组动作序列（包括其变体）的描述。,本书的定义：用况是对参与者使用系统的一项功能时所进行的交互过程的描述，其中包含由双方交替执行的一系列动作。,5.4 用况（use case）,10,术语“use case”的准确含义使用情况是对一项系统功能使用情况的一般描述，它对于每一次使用都普遍适应，既不是应用实例，也不是举例说明。因此译为“用况”，而不是“用例”。几点说明：（1）一个用况只描述参与者对单独一项系统功能的使用情况；（2）通常是平铺直叙的文字描述，UML也允许其他描述方式；（3）陈述参与者和系统在交互过程中双方所做的事；（4）所描述的交互既可能由参与者发起也可能由系统发起；（5）描述彼此为对方直接地做什么事，不描述怎么做；（6）描述应力求准确，允许概括，但不要把双方的行为混在一起；（7）一个用况可以由多种参与者分别参与或共同参与。,11,内容与书写格式：名称行为陈述（分左右栏）调用语句控制语句括号或标号,12,如何定义用况,针对单个用况的描述策略：把自己当作参与者，与设想中的系统进行交互。考虑：交互的目的是什么？需要向系统输入什么信息？希望由系统进行什么处理并从它得到何种结果？把上述交互过程描述出来。定义系统中所有的用况：（1）全面地了解和收集用户所要求的各项系统功能，找出所有的参与者，了解与各项功能相关的业务流程；（2）把用户提出的功能组织成适当的单位，每一项功能完成一项完整而相对独立的工作；（3）穷举每一类参与者所使用的每一项系统功能，定义相应的用况；（4）检查用户对系统的各项功能需求是否都通过相应的用况做了描述。,13,参与者,基用况,include,extend,include,用况,基用况,基用况,被包含用况,延伸用况,用况,5.5 用况图,参与者,参与者,模型元素：参与者用况延伸包含泛化,5.5 用况图,14,用况之间的关系包含、延伸、泛化,延伸,包含,问题：延伸与包含的相似性延伸的方向问题“条件”和“延伸点”问题“泛化”问题系统边界问题,15,用况的两种复杂情况1、两个（或多个）参与者共享一个用况不同种类的参与者可能都要使用某一项系统功能，因此它们可能共享同一个用况,16,2、一个用况的执行，可能需要两个（甚至多个）参与者同时与系统交互。,17,用况图的开发过程确定系统边界发现参与者 定义用况 建立用况之间的关系 确定参与者和用况之间的关系 绘制用况图,使用用况图的几条建议最重要的工作是对用况的描述不要过分深入地描述系统内部的行为细节 运用最主要概念，加强用况内容的描述不要陷入延伸与包含、延伸点、泛化等问题的争论和辨别了解用况的局限性主要作用是描述功能需求,5.6 开发过程与建议,18,概念：对象（object）是系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，由一组属性和施加于这组属性的一组操作构成。类（class）是具有相同属性和操作的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，它由一个类名、一组属性和一组操作构成。类和对象的关系集合与成员，对象是类的实例,第6章 发现对象，定义对象类,6.1 对象和类的概念及其运用,19,主动对象（active object）至少有一个操作不需要接收消息就能主动执行的对象用于描述具有主动行为的事物主动对象的类叫做主动类（active class）被动对象（passive object）每个操作都必须在消息的驱动下才能执行的对象,20,类的语义,OO方法中的类在不同的语境下有两种不同的语义：1.一个类代表由它的全部对象实例所构成的群体日常语言表达中的例子：“公司里有管理人员、技术人员和市场人员”“马路上汽车很多”在OO模型中：每个类都是由它的全部对象实例所构成的集合类代表了它的全部对象实例。,2.一个类代表属于该类的任意一个对象实例从大量的个体中抽象出一个概念，再运用这个概念时就可以代表其中的任何一个个体，例如：“学生有一个学号，属于一个班级，要上课”在OO系统模型中定义了一个类，它就可以代表它的任何一个对象实例，例如：汽车与发动机之间的聚合关系，表示任何一辆汽车都有一台发动机，任何一台发动机都可以装在01辆汽车上,21,在类的抽象层次建模,理由：（1）充分性：模型中一个类描述了它的全部对象实例（2）必要性：个别对象实例不能代表其他对象实例（3）符合人类的思维方式：在概念层次上表达描述事物规律（4）与OOPL保持良好的对应（5）避免建模概念复杂化（6）消除抽象层次的混乱,22,如何运用类和对象的概念,从对象出发认识问题域将问题域中的事物抽象为对象；将具有共同特征的对象抽象为类用类以及它们之间的关系构成整个系统模型；,归纳,23,类 名,压缩方式,类 名,属性名:类型名,操作名(),展开方式,6.2 表示法在模型中用类符号来表示一个类它代表了属于该类的全部对象实例,24,对象名:类名,压缩方式,属性名=值,UML的对象表示法：,细节方式,对象名:类名,25,6.3 发现对象,研究问题域亲临现场深入调查研究直接观察并向用户及相关的业务人员进行调查和交流，考察问题域中各种各样的事物、它们的特征及相互关系 听取问题域专家的见解领域专家包括技术人员、管理者、老职员和富有经验的工人等阅读相关材料阅读各种与问题域有关的材料，学习相关行业和领域的基本知识借鉴以往的系统查阅以往在该问题域中开发过的同类系统的分析文档，吸取经验，发现可以复用的类,26,正确地运用抽象原则对什么进行抽象问题域当前目标系统责任,忽略与系统责任无关的事物只注意与之有关的事物，抽象为系统中的对象 例如：学校的教师、学生、教务员 和 警卫忽略与系统责任无关的事物特征只注意与之有关的特征，抽象为对象的属性或操作 例如：教师的专业、职称 和 身高、体重,正确地提炼对象 例如：对书的不同抽象在图书馆管理系统中以一本书作为一个对象实例在书店管理系统中以一种书作为一个对象实例,27,由系统管理或使用其信息，或者在系统中呈现某些行为的各类人员,由系统管理或使用其信息，或者在系统中呈现某些行为的各类组织,由系统进行管理的各种物品,其他,策略与启发,（1）考虑问题域：,抽象事物,事件,文件,结构,人员,组织,物品,设备,由系统进行管理或控制，或者在系统中呈现某些行为的各种设备,例如：课程、计划、交易、账户,需要长期记忆的事件例如：银行的取款、存款，保险公司的索赔，车辆管理中的驾驶违章,泛指各种表格、档案、证件、票据等文件例如：业务报表，人事档案，身份证，合同，商品订单等 注意三个问题：非基础数据，同一事物的重复描述，多种事物信息组合,从结构得到启发，联想到新的对象,其他一切有助于发现对象的事物,28,（2）考虑系统边界：考察在系统边界以外与系统交互的各类参与者考虑通过那些对象处理这些参与者的交互,人员,设备,外系统,（3）考虑系统责任：检查每一项功能需求是否已有相应的对象提供，发现遗漏的对象,29,审查与筛选,（1）舍弃无用的对象通过属性判断：是否通过属性记录了某些有用的信息？通过操作判断：是否通过操作提供了某些有用的功能？二者都不是无用,30,（2）对象的精简只有一个属性的对象,班级,班主任姓名,1,1,班级班主任姓名,31,（3）与实现条件有关的对象例如：与图形用户界面（GUI）数据管理系统硬件 及操作系统 有关的对象推迟到OOD考虑,32,6.4 对象分类,（1）将对象抽象为类，用类表示它的全部对象（2）审查和调整类的属性或操作不适合该类的全部对象实例例：“汽车”类的“乘客限量”属性进一步划分特殊类属性及操作相同的类经过抽象，差别很大的事物可能只保留相同的特征考虑能否合并为一个类属性及操作相似的类考虑能否提升出一个一般类同一事物的重复描述例：“职员”和“工作证”取消其中一个,33,（3）类的命名类的名字应适合该类（及其特殊类）的全部对象实例反映个体而不是群体使用名词 或 带定语的名词避免市井俚语和无意义的符号使用问题域通用的词汇使用便于交流的语言文字可以用本地文字和英文双重命名,34,属性（attribute）是用来描述对象静态特征的一个数据项。实例属性（instance attribute）和类属性（class attribute）的区别例如：仪表类输入电压、功率及各种规定的质量指标类属性编号、出厂日期、精度等实际性能参数实例属性,第7章 定义对象的属性和操作,7.1 属性和操作,35,操作（operation）是用来描述对象动态特征（行为）的一个动作序列。近义词：方法（method），服务（service）被动操作（passive operation）：只有接收到消息才能执行的操作 编程语言中的函数、过程等被动成分主动操作（active operation）：不需要接收消息就能主动执行的操作编程语言中的进程、线程等主动成分,36,实现级细节方式,分析级细节方式,7.2 属性和操作的表示法,类 名,属性名:类型名=值,操作名(参数表)：返回类型,类 名,属性名:类型名,操作名(),37,7.3 定义属性,（1）策略与启发按常识这个对象应该有哪些属性？人姓名、地址、出生年月在当前的问题域中，对象应该有哪些属性？商品条形码根据系统责任，这个对象应具有哪些属性？乘客手机号码建立这个对象是为了保存和管理哪些信息？物资型号、规格、库存量为实现操作的功能，需要增设哪些属性？传感器（信号采集功能）时间间隔是否需要增加描述对象状态的属性？设备状态 用什么属性表示关联和聚合？课程任课教师，汽车发动机,38,（2）审查与筛选是否体现了以系统责任为目标的抽象例：书重量？是否描述对象本身的特征例：课程电话号码？是否可通过继承得到？是否可从其他属性直接导出？,（3）推迟到OOD考虑的问题规范化问题对象标识性能问题,（4）属性的命名与定位命名：原则与类的命名相同定位：针对所描述的对象适合类（及其子类）的全部对象实例,39,（1）对象行为分类系统行为例：创建、删除、复制、转存对象自身的行为算法简单的操作例：读、写属性值对象自身的行为算法复杂的操作计算或监控,7.4 定义操作,40,考虑系统责任有哪些功能要求在本对象提供？考虑问题域对象在问题域对应的事物有哪些行为？分析对象状态对象状态的转换是由哪些操作引起的？追踪操作的执行路线模拟操作的执行，并在整个系统中跟踪,（3）策略与启发,41,审查对象的每个操作是否真正有用是否直接提供系统责任所要求的某项功能？或者 响应其它操作的请求间接地完成这种功能的某些局部操作？调整取消无用的操作审查操作是不是高内聚的一个操作应该只完成一项单一的、完整的功能调整拆分 或 合并,（3）审查与调整,42,考虑问题域对象行为是被引发的，还是主动呈现的？,（4）认识对象的主动行为,操作执行路线逆向追踪,与参与者直接交互的对象操作,43,问题：分析阶段为什么要给出操作流程？关于OOA/OOD分工的两种不同观点,（5）操作过程描述可采用流程图或活动图,yes,no,动作陈述框，在框内填写要执行的动作。,条件判断框，给出一个判断条件。,转接，用于连接各个框，表示它们之间的转接关系。,入口/出口标记，指出操作的开始或结束。,流程图：,活动图：在流程图基础上进行了一些扩展，有更强的描述能力（第9章介绍）,44,命名：动词或动宾结构定位：与实际事物一致例：售货员售货，商品售出在一般-特殊结构中的位置适合类的全部对象实例,（6）操作的命名和定位,从主语-谓语-宾语结构看对象操作的设置“售货员销售商品”操作应该放在哪里？,45,7.5 接口的概念及用途,早期的面向对象方法并没有把接口作为正式的OO概念 和系统成分，只是用来解释OO概念“操作是对象（类）对外提供的访问接口”20世纪90年代中后期，接口才作为一种系统成分出现在OOPL中，并且被UML作为一种模型元素UML对接口的定义及解释：“接口（interface）是一种类目（classifier），它表示对一组紧凑的公共特征和职责的声明。一个接口说明了一个合约；实现接口的任何类目的实例必须履行这个合约。”“一个给定的类目可以实现多个接口，而一个接口可以由多个不同的类目来实现。”,46,为什么引入接口的概念,47,接口（interface）是由一组操作所形成的一个集合，它由一个名字和代表其中每个操作的特征标记构成。特征标记（signature）代表了一个操作，但并不具体地定义操作的实现特征标记:=（:,:）:,interface接口名称操作1（）操作n（）,表示法（详细方式）：,48,接口与类的关系接口由某些类实现（提供），被另外某些类使用（需要）前者与接口的关系称为实现（realization）后者与接口的关系称为使用（use）,interface销售查询（）售出（）,售货员,商品,使用,实现,同一个接口 对实现者而言是供接口（provided interface）对使用者而言是需接口（required interface）,49,表示法（简略方式）：托球-托座,使用者,提供者,提供者的供接口（托球）使用者的需接口（托座）,50,在一个类上可以画出它所有的供接口和需接口,类,供接口,需接口,一个接口可以由多个类使用，它也可以由多个类实现,类B,类D,类A,类E,类C,多个类可以共同使用同一个接口正如对象的一个操作可以被多个对象调用,多个类都可以分别实现同一个接口这里表示它们可以相互替换,51,接口与类的区别类既有属性又有操作；接口只是声明了一组操作，没有属性。在一个类中定义了一个操作，就要在这个类中真正地实现它；接口中的操作只是一个声明，不需要在接口中加以实现。类可以创建对象实例；接口则没有任何实例。,引入接口概念的好处在接口的使用者和提供者之间建立了一种灵活的衔接机制，有利于对类、构件等软件成分进行灵活的组装和复用。将操作的声明与实现相分离，隔离了接口的使用者和提供者的相互影响。使用者只需关注接口的声明，不必关心它的实现；提供者不必关心哪些类将使用这个接口，只是根据接口的声明中所承诺的功能来实现它，并且可以有多种不同的实现。,接口概念对描述构件之间的关系具有更重要的意义教材第9章将做进一步介绍,52,接口与多继承的比较接口果真能部分地解决多继承问题吗？,interface接口 A操作A-1（）操作A-n（）,interface接口 B操作B-1（）操作B-m（）,类 C,操作A-1（）操作A-n（）操作B-1（）操作B-m（）,53,对象之间的四种关系1一般-特殊关系 又称继承关系，反映事物的分类。由这种关系可以形成一般-特殊结构。2整体-部分关系即聚合关系。反映事物的构成。由这种关系可以形成整体-部分结构。3关联关系对象实例集合（类）上的一个关系，其中的元素提供了被开发系统的应用领域中一组有意义的信息。4消息关系 对象之间的动态联系，即一个对象在执行其操作时，请求其他对象为它执行某个操作，或者向其他对象传送某些信息。反映了事物之间的行为依赖关系。,这些关系形成了类图的关系层,第8章定义对象间的关系,54,概念同义词 和 近义词继承（inheritance）是描述一般类和特殊类之间关系的最传统、最经典的术语。有时作为动词或形容词出现。一般-特殊（generalization-specialization）含义最准确，而且不容易产生误解，恰切地反映了一般类（概念）和特殊类（概念）之间的相对（二元）关系；也用于描述结构，即一般-特殊结构。缺点是书写和阅读比较累赘。泛化（generalization）取“一般-特殊”的一半，是UML的做法。比较简练，但是只反映了问题的一方面。作为关系的名称尚可，说结构是一个“泛化”则很勉强。分类（classification）接近人类日常的语言习惯，体现了类的层次划分，也作为结构的名称。在许多的场合被作为一种原则。本书主要采用“一般-特殊”这个术语,8.1一般-特殊结构,相关概念：一般类、特殊类、继承、多继承、多态语义：“is a kind of”,55,一般-特殊关系（继承关系）是类之间的一种二元关系是一种基本的模型元素；由这种关系所形成的结构是一般-特殊结构是一种复合的模型成分。,人员,股东,职员,顾客,股东职员,例：,这是1个一般-特殊结构 包含5个一般特殊关系,56,定义1：如果类A具有类B的全部属性和全部操作，而且具有自己特有的某些属性或操作，则A叫做B的特殊类，B叫做A的一般类。一般类与特殊类又称父类与子类。,定义2：如果类A的全部对象都是类B的对象，而且类B中存在不属于类A的对象，则A是B的特殊类，B是A的一般类。书中证明，以上两种定义是等价的,一般类和特殊类的两个定义,57,表示法,一般类,特殊类,特殊类,集中式,一般类,特殊类,特殊类,分散式,58,如何发现一般-特殊结构,（1）学习当前领域的分类学知识（2）按常识考虑事物的分类（3）根据一般类和特殊类的两种定义（4）考察属性与操作的适应范围,59,（5）考虑领域范围内的复用,现钞收款机 A B C D E F X Y Z,60,（1）问题域是否需要这样的分类？（例：书线装书）（2）系统责任是否需要这样的分类？（例：职员本市职员）（3）是否符合分类学的常识？（用“is a kind of”来衡量）,审查与调整,（4）是否真正的继承了一些属性或操作？,61,一般-特殊结构的简化（1）取消没有特殊性的特殊类,运输工具发动机载重量速度,飞机飞行高度 自动导航,汽车,运输,62,（2）增加属性简化一般特殊结构,人员,男 人,女 人,中国人,美国人,日本人,63,（3）取消用途单一的一般类，减少继承层次一般类存在的理由：*有两个或两个上以上的特殊类*需要用它创建对象实例*有助于软件复用,64,多继承：允许一个特殊类具有一个以上一般类的继承模式,65,多态：,多态是指同一个命名可具有不同的语义。OO方法中，常指在一般类中定义的属性或操作被特殊类继承之后，可以具有不同的数据类型或表现出不同的行为。,66,概念：聚合（aggregation），组合（composition）整体-部分（whole-part）整体对象，部分对象语义：“a part of”或“has a”聚合关系描述了对象实例之间的构成情况，然而它的定义却是在类的抽象层次给出的。从集合论的观点看聚合关系整体-部分关系（聚合关系）是两个类之间的二元关系，其中一个类的某些对象是另一个类的某些对象的组成部分。整体-部分结构是把若干具有聚合关系的类组织在一起所形成的结构。它是一个以类为结点，以聚合关系为边的连通有向图。,8.2 整体-部分结构,一种基本的模型元素,由若干聚合关系形成的复合模型成分,67,可以正确有问题,若类 A 的对象 a 是类 B 对象 b 的一个组成部分判断以下几种说法正确与否：“对象 b 和对象 a 之间具有聚合关系”“类 B 和类 A 之间具有聚合关系”“类 A 是类 B 的一个组成部分”,组合（composition）是聚合关系的一种特殊情况，它表明整体对于部分的强拥有关系，即整体与部分之间具有紧密、固定的组成关系。UML把聚合定义为关联的一种特殊情况而组合关系是聚合关系的特殊情况,68,数量,数量,数量,数量,整体对象类,部分对象类,整体对象类,部分对象类,表示法,在连接符两端通过数字或者符号给出关系双方对象实例的数量约束，称为多重性（multiplicity）确定的整数 给出确定的数量 例如：1，2 下界上界 给出一个范围 例如：01，14*表示多个，数量不确定下界*表示多个，下界确定 例如 0*，1*多重性有以下3种情况：一对一，一对多，多对多,69,如何发现整体-部分结构基本策略考察问题域中各种具有构成关系的事物,（1）物理上的整体事物和它的组成部分例：机器、设备和它的零部件（2）组织机构和它的下级组织及部门例：公司与子公司、部门（3）团体（组织）与成员例：公司与职员（4）一种事物在空间上包容其它事物例：生产车间与机器（5）抽象事物的整体与部分例：学科与分支学科、法律与法律条款（6）具体事物和它的某个抽象方面例：人员与身份、履历,70,审查与筛选,（1）是否属于问题域？例：公司职员与家庭（2）是不是系统责任的需要？例：员工与工会（3）部分对象是否有一个以上的属性？例：汽车与车轮（规格）（4）是否有明显的整体-部分关系？例：学生与课程,71,整体-部分结构的高级应用技巧,（1）简化对象的定义,飞 机,有关发动机的属性与操作,有关驾驶室的属性与操作,72,（2）支持软件复用,起重机,送料车,机床,钻床,刨床,车床,73,（3）表示数量不定的组成部分,订 单编号卖方买方总金额成交日期,一个订单可以包含一项到多达几十项商品,提问：能否不要订单行，直接用商品作为订单的部分对象？,74,（4）表示动态变化的对象特征,人员,营业员,会计师,经理,问题：对象的属性与操作定义在系统运行中动态变化，例如：,不理想的解决办法：删除、重建Shlaer/Mellor的子类型迁移“动态对象”,75,“三友”对问题的描述及解决方法“大多数面向对象的编程语言是静态类型化的，这意味着在创建对象时就限定了对象的类型。但是随着时间的推移对象还可能扮演不同的角色。”例子：候选者，雇员，退休者,总之都是围绕着继承想主意，没有运用聚合。,76,从上述例子得到的启示：整体-部分结构有很强的表达能力运用OO方法的基本概念可以自然而有效地解决许多在其他方法中用扩充概念解决的问题加强对基本概念的运用，不要轻易创造新的扩充概念,person,01,01,01,1,1,1,用聚合概念解决：,CandidateRole,EmployeeRole,RetireeRole,77,用一般特殊结构,两种结构的变通,汽 车,制冷设备,冷藏车,解释：继承和聚合都是使一类对象获得另一类对象的特征，只是观察问题的角度不同。,78,概念：关联（association）是两个或者多个类上的一个关系（即这些类的对象实例集合的笛卡儿积的一个子集合），其中的元素提供了被开发系统的应用领域中一组有意义的信息。二元关联（binary association）n元关联（n-ary association）关联的实例有序对 或 n元组，又称链（link）关联是这些有序对 或 n元组的集合关联位于类的抽象层次，链位于对象的抽象层次,8.3 关联,提问：一个n元关联中所涉及的类的数量是否可以小于n？,79,二元关联的表示法,类 A,名称,类 B,数量,数量,角色,角色,80,二元关联的实现（一对一和一对多）,编程语言：在程序中用两个类分别实现关联两端的类；以数量约束为“1”的类的对象实例为目标，在关联另一端的类中设置一个指向该目标的指针或者对象标识（源类的属性）。,教 师,1,授课,课 程,*,81,二元关联的实现（多对多）,问题：任何一端的一个对象实例的要和另一端多个对象实例发生关联，而且数量不确定。实现时不知道该设立多少个指针（或者对象标识、外键）才能够用。,课 程,学 生,*,*,82,运用简单的概念及表示法解决各种复杂的关联问题,教师,学生,1,*,指导论文,（1）带有属性和操作的关联,有某些信息需要描述,OMT（及UML）的概念扩充关联类（association class）,问题：增加了概念的复杂性，缺乏编程语言支持,83,换一种思路考虑问题：两类对象之间的关联带有某些复杂的信息，说明它们之间存在着某种事物（尽管可能是抽象事物）。用普通的对象概念来表示这种事物，简化关联，减少概念，并加强与OOPL的对应。,教师,学生,1,*,指导论文,论文题目答辩时间成绩,例1,84,城市之间有航线,城 市,有航线距离每周班次,*,*,其他例子,85,复杂关联表示法的转换,m,n,类 A,类 B,关联类属性操作,86,（2）n元关联,OMT的三元关联及其表示法,问题：编程语言不能直接支持可推广到n元关联，是否要创造更多的符号？多重性表示的困难（详后）,*,*,*,87,在理论上，n元关联是由若干n元组形成的集合，本质上也是一个类是由每个n元组作为对象实例的类,从实现的角度看，用类实现n元关联是最自然的选择例如：用一个数据库表存放n元关联的全部n元组,88,在模型中，把n元关联定义为一个类并定义它与原有的各个类之间的关系都是二元关联,类2,类n,类1,类3,n元关联,89,项 目,语 言,人 员,*,?,*,是 1 还是*？,n元关联多重性表示的困难和解决办法,90,例：课程实习中每两名学生在一台设备上合作完成一个题目1）若系统要求记录和查阅哪两名学生是合作者建立学生类到它自身的关联（如同城市之间有航线）是一个二元关联，其中学生类在关联中出现了两次 2）如果还要记录每组学生的实习题目和使用的设备建立学生、题目、设备三个类之间的4元关联学生类在这个关联中出现了两次,（3）一个类在一个关联中多次出现,91,假如该系统的多重性要求是：每两名学生在一台设备上合作完成一个题目；一个题目可以供多组学生实习，可以在不同的设备上完成；一台设备可以供多组学生使用，可以做不同的题目。,92,关联端点的复杂情况 关联端点：关联的连接线与类符号相衔接的点修饰：在端点附近标注符号或者文字，或者画成不同的形状,多重性（multiplicity）有序（ordered）ordered 限定符（qualifier）详后导航性（navigability）聚合标志（aggregation indicator）角色名（rolename）接口说明（interface specifier）角色名:接口说明 可变性（changeability）frozen,addOnly 可见性（visibility）。“+”、“#”或者“-”,93,“限定符是关联的一种属性，它的值划定了跨过一个关联与一个对象相关的对象集合。”用限定符修饰的关联称为受限关联（qualified association）,UML对限定符的解释,类 A,限定符,类 B,*,01,表示法,94,限定符的例子及其简单解决方案,95,关联端点的修饰在UML2的变化,（1）取消了接口说明和可变性两种修饰（2）新增两种图形方式的修饰：表示不可导航：表示拥有权（3）增加了花括号内的特性串（property string）subsets 子集合redefines 重定义union 合并ordered 有序nonunique 不唯一sequence，seq 序列,96,如何建立关联1根据问题域和系统责任发现所需要的关联 哪些类的对象实例之间存在着对用户业务有意义的关系？问题域中实际事物之间有哪些值得注意的关系？这种信息是否需要通过有序对（或者n元组）来体现？这些信息是否需要在系统中进行保存、管理或维护？系统是否需要查阅和使用由这种关系所体现的信息？,97,2关联的复杂情况处理对关联属性和操作的处理 对n元关联的处理避免一个类在关联中多次出现 多对多关联的处理,供货商,客户,*,*,多对多关联的处理,98,3为关联端点添加修饰 分析关联的多重性 给出关联名或角色名识别聚合种类其他修饰导航性、特性串等根据实际情况决定是否采用限定符用简单的类和关联的概念解决4在类中设立实现关联的属性,99,5关联定位,系统管理员,1,计算机,服务器,客户机,用 户,*,操作,使用,1,*,100,6.4消息,1、什么是消息（message）现实生活中人或其他事物之间传递的信息，例如：人与人之间的对话、通信、发通知、留言交通信号灯对车辆和行人发出的信号人发给设备的遥控信号等软件系统中进程或软件成分之间传送的信息控制信息 例如一次函数调用，或唤醒一个进程数据信息 例如传送一个数据文件面向对象的系统中（按严格封装的要求）消息是对象之间在行为上的唯一联系方式 消息是向对象发出的服务请求（狭义）消息是对象之间在一次交互中所传送的信息（广义）消息有发送者和接收者，遵守共同约定的语法和语义,101,每个消息都是向对象发出的服务请求最常见的是函数调用消息都是同步的。接收者执行消息所请求的服务。发送者等待消息处理完毕再继续执行。每个消息只有唯一的接收者。,顺序系统中的消息,102,并发系统中的消息,控制流内部的消息与顺序系统相同控制流之间的消息情况复杂得多消息有多种用途服务请求，传送数据，发送通知，传递控制信号消息有同步与异步之分同步消息（synchronous message）异步消息（asynchronous message）接收者对消息有不同响应方式创建控制流，立即响应，延迟响应，不响应发送者对消息处理结果有不同期待方式等待回应，事后查看结果，不等待不查看消息的接收者可能不唯一定向消息（directed message）广播消息（broadcast message）,103,消息对面向对象建模的意义消息体现了对象之间的行为依赖关系，是实现对象之间的动态联系，使系统成为一个能运行的整体，并使各个部分能够协调工作的关键因素。在顺序系统中 消息体现了过程抽象的原则一个对象的操作通过消息调用其他对象的操作在OO模型中通过消息把对象操作贯穿在一起系统实现后这些操作将在一个控制流中顺序地执行在并发系统中 控制流内部的消息使系统中的每个控制流呈现出清晰的脉络控制流之间的消息体现了控制流之间的通信关系,104,OO模型需要表示消息的哪些信息？（按重要性排序）（1）对象之间是否存在着某种消息？（2）这种消息是控制流内部的还是控制流之间的？（3）每一种消息是从发送者的哪个操作发出的？是由接收者的哪个操作响应和处理的？（4）消息是同步的还是异步的？（5）发送者是否等待消息的处理结果？,105,以往不同的OOA&D方法有不同的处理方式 例如：Coad/Yourdon方法 在类图中表示消息 Booch方法只在实例级的模型图（对象图和交互图）中表示消息,UML的处理方式：不在类图中表示消息，只在协作图和顺序图中表示理由：把类图定义为静态结构图，不表示动态信息问题：抽象级别问题局部与全局问题实际上类图中仍然包含动态信息操作，调用（call）依赖,要不要在类图中表示消息,106,UML对各种箭头的用法,同步消息（顺序图、协作图）,实线封闭箭头,依赖（类图、包图、用况图、构件图）从消息接收者的操作返回（顺序图）,虚线开放箭头,关联的导航性（类图）异步消息（顺序图）,实线开放箭头,用 途,图形符号,箭头种类,用什么符号表示消息,借用依赖关系表示类图中的消息,call,send,控制流内部的消息,控制流之间的消息,107,A,C,D,E,F,call,call,call,send,B,call,call,例子：,108,如何建立的消息（控制流内部）策略“操作模拟”和“执行路线追踪”（1）人为地模拟当前对象操作的执行考虑：需要其它对象（或本对象）提供什么服务（2）判断该消息是否属于同一个控制流：二者应该顺序地执行还是并发地执行？是否引起控制流的切换？接收者是否只有通过当前消息的触发才能执行？（3）向接收者画出消息连接线，填写模型规约上述工作进行到当前的操作模拟执行完毕（4）沿着控制流内部的每一种消息追踪到接收该消息的对象操作，重复进行以上的工作，直到已发现的全部消息都经历一遍。针对每个主动类的每个主动操作进行上述模拟与追踪检查系统中每个操作是否都被经历过发现遗漏的消息或多余的操作,109,建立控制流之间消息对每个控制流考虑以下问题：（1）它在执行时，是否需要请求其他控制流中的对象为它提供某种服务？（2）它在执行时是否要向其他控制流中的对象提供或索取某些数据？（3）它在执行时是否将产生某些可影响其他控制流执行的事件？（4）各个控制流的并发执行，是否需要相互传递一些同步控制信号？（5）一个控制流将在何种条件下中止执行？在它中止之后将在何种条件下被唤醒？由哪个控制流唤醒？从上述各个角度发现控制流之间的消息在相应的类之间画出消息连接线,110,8.5 关于依赖关系,什么是依赖（dependency）在以往的OO方法中，只有Firesmith方法用到这个概念，其大意是：“客户/服务者（client/server）关系，表示客户对服务者的依赖。”列举的情况包括：消息传送其中客户发送消息给服务者；聚合其中聚合体（客户）的定义依赖它的构成部分（服务者）；继承其中派生类（客户）依赖它的基类（服务者）以继承其特征。结论：在Firesmith方法中，依赖并不是对象之间的一种基本关系，而是为了指出在消息、聚合、继承等基本关系中哪个模型成分是客户（依赖者），哪个模型成分是服务者（被依赖者）所采用的一个概括性的术语。,111,UML1.4对依赖的定义和解释“依赖：两个建模元素之间的一种关系，其中一个建模元素（独立元素）的一个改变将影响到另一个建模元素（依赖元素）。”“依赖是除了关联、泛化、流以及元关系之外的关系的方便术语。”“依赖表明一个或者一组元素的实现或者功能需要另外一个或者一组元素出现。”“依赖指出了两个模型元素（或者两组模型元素）之间的语义关系。它指的是这些模型元素本身，而不需要一组实例来说明其含义。它指出这样一种情况：目标元素的一个变化可能需要依赖中的源元素发生变化。”Booch等UML用户指南的解释“两个事物之间的语义关系，其中一个事物（独立事物）的改变将影响到另一个事物（依赖事物）。”,112,UML2对依赖关系的新阐述“依赖表明模型元素之间的供方/客方（supplier/client）关系，其中供方的修改可能影响到客方元素。依赖意味着，如果没有供方，客方的语义就是不完整的。依赖在一个模型中出现并不含有任何运行时的语义