[互联网]系统分析与设计基础.ppt_第1页
[互联网]系统分析与设计基础.ppt_第2页
[互联网]系统分析与设计基础.ppt_第3页
[互联网]系统分析与设计基础.ppt_第4页
[互联网]系统分析与设计基础.ppt_第5页
已阅读5页,还剩87页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1,第四部分 面向对象的系统分析,2,面向对象的分析与设计,面向对象分析的主要任务: 分析问题空间的主要目标和功能,寻找存在的对象,找出这些对象的特征和责任(即属性和服务),以及对象间的关系,并由此产生一个完整表达系统需求的规格说明(做什么?) 面向对象设计的主要任务: 强调对分析结果的完善和改良,产生一个指导面向对象编程的详细规格说明(怎么做?) 与传统方法相比,面向对象的分析与设计之间不存在严格的时间界限和内容分工,设计是对分析的细化过程,从而为活动的反复迭代创造了条件,3,4.1 面向对象方法概述,4.1.1 引例餐馆管理系统 业务流程描述: 顾客点菜,服务员产生点菜单 厨房根据传入的点菜单准备饭菜 服务员上菜 顾客结账付款并获取收据,4,4.1.1 引例餐馆管理系统,使用结构化方法来对餐馆的上述业务进行建模 分析阶段:(DFD略) 外部实体:顾客、服务员、厨师、帮厨 处理:点菜、做菜(备菜、炒菜)、上菜、结账 数据存储:餐馆菜单、顾客点菜单 数据流:略 设计阶段:(结构图如下),5,使用面向对象方法来对餐馆的上述业务进行建模 确定系统对象及其职责,构建系统的静态模型和动态模型:,4.1.1 引例餐馆管理系统,静态模型(类图),动态模型(顺序图),可见:面向对象方法把分析设计的焦点放在执行操作的对象以及对象间的协作上,6,4.1.2 面向对象方法的基本概念,1. 对象 定义:是一些属性及操作的封装体 对象的属性值刻画了一个对象的状态;而通过对象提供的操作可改变对象的属性 例: 一个简单的对象,属性,操作,7,2. 类 体现了人类常用的思维方式抽象 定义:是具有相同属性和服务的一组对象的集合(是创建对象的模板),为属于该类的全部对象提供了统一的抽象描述。一个对象是该对象所在类的一个实例。 例如:对象“客车”、“货车”、“拖车”等属于同一个类-“车辆”,8,3. 消息 消息是对象之间通信和合作的手段,是封装的一种体现 定义:是向对象发出的服务请求,应包含:提供服务的对象标识、服务类型、输入信息、应答信息 泛指一个对象调用了其他对象的服务,当对象A请求对象B的某个服务X,就可以直接调用对象B提供的函数接口X( ),9,4. 封装 把数据与服务封装于一个内在的整体。对外仅提供有限的服务,而隐藏对象内部实现细节,限制外界对对象私有数据和方法的访问 保证软件部件具有较好的模块性,提高了可维护性: 只要对象接口不变,对象内部逻辑的修改不会影响其他部件 严密的接口保护使对象的属性和服务不会被随意地使用,对象的状态易于控制,可靠性增强,10,5. 继承 定义:指特殊类拥有其一般类的全部属性和服务。特殊类在继承一般类的语义性质外,还有自己特有的属性和操作 在软件开发中使用继承可带来的好处: 可以简化系统的描述和实现(在分析、设计和编程的整个过程中都用到了继承特性) 较好地实现软件重用,提高软件开发效率,子类 (同时还具有“姓名”属性和“注册”方法),父类,11,6.多态性 定义:指同一消息发送到不同对象可引起不同操作、产生不同结果 相同接口,多种实现 通过子类覆盖(overriding)父类的方法实现多态: 例如:“学生”是“本科生”和“研究生”的一般类,“学生”有注册操作,“本科生”注册需要在规定时间内交学费,“研究生”注册则不需要,“学生”通过“本科生”和“研究生”对注册操作的重新定义表现出多态性,抽象类,12,对问题空间的理解更直接、更快,更符合人们认识客观事物的思维规律(将问题空间直接映射到分析模型) 系统分析与设计使用统一的表示模型,减少了转换工作和语义差异,也使模型与代码之间的同步成为可能 把最稳定的对象作为构成系统的基本单位,把最易变的属性和方法隐藏起来,从而控制了系统的复杂性,增强了系统的应变能力 面向对象的优异特性为提高软件可重用性、可扩充性和可维护性提供了有效的手段和途径,4.1.3 面向对象方法的优势,13,4.2 UML,UML(Unified Modeling Language)是一种构建软件系统和文档的通用可视化建模语言,体现了实践面向对象方法的最好经验 UML统一了面向对象建模的基本概念和图形符号 UML可用于软件开发从分析到实现的各个阶段 UML能表达系统的静态结构和动态信息,并能管理复杂的系统模型,便于软件团队之间的合作开发 UML不是编程语言,但支持UML语言的工具可以提供从UML到编程语言的代码生成,也可以实现从现有程序逆向构建UML模型,14,从20世纪80年代末开始,一些方法论学者、研究人员和专家就开始提出面向对象的表示符号和方法: Peter Coad 和 Ed Yourdon在面向对象的程序设计语言基础上建立了他们的OOA和OOD,主要工具是类与对象图、对象状态图和服务图 Grady Booch在Rational软件公司开发Ada系统时建立了许多构件(Component),并以此由底向上构筑大型软件系统,即OOD方法 Jim Rumbaugh在GE领导一个研究小组,提出了对象建模技术(OMT)方法,通过面向对象的三种模型:对象模型、动态模型和功能模型,从不同角度对系统进行描述 Ivar Jacobson提出了OOSE面向对象的软件工程,利用Use Case来表达系统要求 Wirfs-Brock提出职责驱动设计(Responsibility-Driven Design),用类所承担的责任来描述系统,利用责任把封装的概念带到分析与设计活动中去,UML发展历程,15,UML发展历程,以上各种面向对象的建模语言独立发展,用户无法区别不同语言之间的差别,难以选择适合各自系统特点的语言,而且使用不同语言建立的模型之间无法通信和合作 UML结合了Booch,OMT和OOSE方法的优点,于1997年11月正式被OMG采用 1997 UML1.0/UML1.1 (OMG) 1998 UML1.2 1999 UML1.3 2001 UML1.4/UML2.0 (提交ISO),统一 标准化 工业化,16,UML架构与基本组成,视图(views) UML的组成 图(diagrams) 模型元素(model elements) 通用机制(general mechanism) 通用机制:为图做进一步的补充说明,如注释、元素的语义说明,17,UML视图(views),完整的系统通常有一组视图,每个视图显示系统的一个特定方面,分别从不同的视角做出描述 视图由图组成,一个视图对应一个或多个图,18,逻辑视图,组件视图,配置视图,行为视图,描述系统的外部功能特性 采用用例图描述,表达软件组织结构。采用组件图描述系统的软件组件或模块及它们的依赖关系,表达系统的基本逻辑结构,也称为静态视图。采用类图描述对象的静态结构,采用对象图来显示类的实例以帮助理解该类,表达系统的动态行为 采用顺序图、协作图、活动图及状态图描述,表达物理结构。采用配置图来描述系统中的节点和节点的连接关系,以及软件对象在节点的分布情况,UML视图,用例视图,19,UML图与视图的对应关系,用例视图(用例图),逻辑视图(类、对象图),组件视图(组件图),行为视图(状态图、活动图、顺序图和协作图),视图,配置视图(配置图 ),静态建模,物理架构,20,UML模型元素 (model elements),可以在UML图中使用的概念统称为模型元素 模型元素在图中用相应的符号表示:,21,保险销售用例图,签定保险单,销售统计,记录客户数据,保险销售系统,22,UML图类图(class),表示系统中类与类之间的关系 特点:反映系统的静态结构 类的表示方法: 长方形表示类,分上、中、下三个区域分别表示类的名字、属性和操作,属性,操作,类名,23,例:一个简化的租赁系统的类图,*,1*,一项租赁业务可能租出一个或多个产品项目,一个项目可能被租出0次或多次,24,UML图对象图 (object),表示系统在某个特定时刻各个对象的具体内容,帮助对类图的理解 对象图实质上是类图的实例 表示方法 与类图的表示方法基本相同,只是对象名与类名的表示存在差异 对象名有三种表示格式 对象名:类名 :类名 对象名,25,例:一个简化的租赁系统的对象图,该对象图表示在处理第0012号租赁业务的特定时刻,各个对象的具体内容,*,1*,26,UML图状态图(state),用于描述一个对象所能到达的所有状态以及引起状态转变的事件(例如,消息,超时,出错,条件满足等) 表示方法 转移:状态之间带箭头的连线 事件:状态的变迁通常由事件触发,在转移上方标注 (若未标注,则表示源状态的内部活动执行完毕后自动触发转移) 初态:状态图的起始点,表示一个对象的初始状态 (初态只有一个) 终态:状态图的终点,表示一个对象完成必要操作后的最终状态(终态可能有多个也可能没有) 中间状态:处于初态和终态之间的状态 组合状态:含有子状态的状态,27,例:电梯运行的状态图,28,UML图活动图(activity),描述对象操作中所要完成的工作以及用例的工作过程。适合描述比较复杂的操作 和流程图很类似,但支持并发控制 表示方法 起点:仅有一个起点 终点:可有多个终点 活动:表示流程中任务的执行 分支:使用一个菱形的判断标志来表达条件转移 并发:使用一个称为同步条的水平粗线将一条转移分叉为多个并发执行的分支,或将多个转移汇合为一条转移 协作:用矩形框表示泳道,活动中的每个对象有自己的泳道,该对象负责的活动画在对应泳道上,29,例:库存管理活动图,计算库存,进货,报警, 下限 , 上限 ,30,例:带泳道的活动图,Customer,Sales,Stockroom,Request Service,Pay,Take Order,Fill Order,Deliver Order,Collect Order,泳道,31,UML图顺序图(sequence),描述为实现一个用例多个对象之间动态的交互关系,着重体现对象间消息传递的时间顺序 表示方法 横坐标:对象 纵坐标:生命线(生命线上的矩形表示对象的生存期) 消息:一般对应接收方对象响应该消息的方法名,32,例:打印文件的顺序图,注:上图中的打印机空闲、 打印机忙表示执行条件,33,UML图协作图(collaboration),用来描述为实现一个用例多个对象之间的协作关系,着重体现的是对象间消息的连接关系 表示方法 对象 链接 消息:消息旁的数字表示执行顺序,34,例:打印文件的协作图,:计算机,: 打印服务器,: 打印机,: 队列,1:打印(文件),2:打印机空闲打印(文件),3:打印机忙 存储(文件),注:上图中的打印机空闲、 打印机忙表示执行条件,35,UML图组件图 (component),描述软件组件间的组织和依赖关系(包括编译、链接或执行时组件间的依赖关系) 组件可以是源代码文件、可执行文件、动态链接库等 表示方法 组件 相关性联接,36,例:窗口系统组件图,图中的虚线表示依赖关系,37,UML图配置图 (deployment),描述系统运行时软件和硬件的物理配置: 硬件配置包含硬件节点及其连接关系 软件配置包含各组件在硬件节点上的分布情况 配置图常用于帮助理解分布式系统 表示方法 节点:硬件单元,例如计算机、打印机,POS终端,通信设备等 连接:即通信路径,38,配置图举例,Windows/PC,Unix/Server,TCP/IP,客户 程序,39,常用UML 建模工具,Rational ROSE Microsoft Visio,40,面向对象的分析与设计过程,1)识别系统的目标和系统边界:确定系统的责任范围,认识系统与外部环境的接口以及哪些人或事物通过该接口与系统有交互活动 2)识别用例,建立用例图:用例用来捕捉系统的功能需求,有助于寻找对象并确定其责任、了解对象间的协作关系 3)识别对象、类及其关系,建立类图 4)设计用例的详细逻辑,建立时序图等动态视图:将用例图中的每个用例展开后描述操作的细节,必要时对类的属性与服务进行调整 5)必要时重复上述活动,精化并调整各图,41,UML在系统开发各阶段的应用,分析:用用例图描述用户的需求,用类图描述系统的静态结构,用协作图、顺序图、活动图和状态图描述系统的动态行为 设计:把分析阶段的结果扩展为技术解决方案,加入新的类来定义软件系统的技术方案细节 (同时要进行数据库设计、编码设计、输入/输出设计、人机界面设计等) 编码:把来自设计阶段的类转换成某种面向对象程序设计语言的代码,42,4.3 用例模型,面向对象分析的主要任务: 分析问题空间的主要目标和功能,寻找存在的对象,找出这些对象的特征和责任(即属性和服务),以及对象间的关系,并由此产生一个完整表达系统需求的规格说明 具体步骤: 建立用例模型 建立分析模型,43,4.3.1 用例(Use Case),在面向对象方法中,通过用例描述系统需求 用例的定义: 用例是对于一组动作序列的描述,系统执行这些动作会对特定的参与者产生可观测的、有价值的结果 用例是从用户角度定义的具有交互过程的系统功能 引入用例的目的: 1)确定系统应具备哪些功能,这些功能是否完整表达了系统的需求 2)为系统功能提供清晰规范的描述,这是开发人员之间以及开发人员与用户之间交流的基础,也为系统测试和验收提供依据 3)以用例为驱动,为具体实现的类及其方法提供跟踪检测和设计启发,44,用例图,用例图由系统、执行者和用例三种模型元素以及它们之间的关系组成 执行者:处于系统之外,需要使用用例的人或事物 用例:代表系统的一项外部功能需求 用例的场景描述:清楚描述该用例的有关事件流,对于较复杂的用例建议使用活动图或系统时序图描述,45,用例图的表示方法: 小人形的图形表示执行者,下方书写执行者名字 椭圆形表示用例,其名字写在椭圆下方或者内部 用例位于系统边界的内部 用例与执行者之间的关系用一条直线表示,签定保险单,销售统计,记录客户数据,保险销售系统,46,4.3.2 用例建模,用例建模有3个步骤: 确定参与者 确定用例(及之间的关系),建立用例图 用例的场景描述,47,1)确定参与者,参与者是系统之外与系统进行交互的任何实体 寻找参与者的方法: 如果某个人或事物对于完成系统目标没有责任关系,则将他们定义在系统之外 如果某个人或事物与该系统的某些功能存在联系,则他们是系统边界之外的与系统有交互的参与者 参与者可以是人,也可以是其他系统;只有那些直接与系统通信的人员才需要被当做参与者 如果在定义需求时建立了事件表,则用例图中的参与者可以来源于事件表中的“来源”列,48,例:确定网上订购系统的参与者,系统供订货员直接使用,则订货员是参与者 (客户因为提供数据给系统,因而可以作为数据流程图的外部实体),网上预订系统,1.客户(打电话)通过订货员查询并订购商品,2.客户利用因特网查询并订购商品,网上预订系统,系统供客户通过因特网直接使用,则客户是参与者,49,另例:简化的门诊挂号系统的用例图,挂号的需求说明: 窗口挂号:指在挂号窗口挂号,获取挂号单 网上挂号:指通过网络访问医院的服务器,操作成功后拿到一个密码,在指定的时间内到医院的挂号处凭密码领取挂号单,挂窗口号,发号,网上挂号,打印挂号单,病人仅在网上挂号时充当参与者,挂窗口号时只是系统内部处理的对象,不能识别为参与者,50,2)确定用例,建立用例图,确定用例需要注意: 用例是参与者与系统之间为达到某个目的而进行的一次典型的交互过程,因此必须与参与者直接相关 用例定义了与外界有交互过程的系统功能,该功能可能是一系列动作的集合,因此不要混淆用例和用例所包含的步骤,51,以下问题的思考有助于建模时发现用例 参与者需要从系统中获得哪些功能? 参与者需要读取、删除、修改或存储系统中的某些信息吗? 系统中发生的事件是否需要通知参与者?这些事件的作用是什么?(如系统的报警功能) 系统需要的输入/输出信息是什么?都怎样产生? 如果在定义需求时建立了事件表,则用例图中的用例可以直接来自于事件表中的外部事件,52,根据事件表绘制用例图,查询打折商品,创建新订单,更改订单,验证客户帐号,其中,“创建新订单”和“更改订单”用例均需要检查客户的帐号是否正确,因而要使用“验证客户帐号”用例,例:图书馆系统用例图,53,54,用例之间的关系 a) 包含关系 包含用例:指经过封装后可以在各种不同的基本用例中复用的用例,例如ATM系统中的“取款”和“修改口令”都包含识别客户身份的行为,可将该行为抽取到一个名为“身份识别”的包含用例 基本用例:指未经过分解、包含常规会发生的最基本的功能的用例,具有普遍性,例如:ATM系统中的基本用例有“取款”和“修改口令”,执行基本用例时,一定会执行包含用例部分,包含用例,基本用例,55,b) 扩展关系 扩展用例:指表达某些可选或只在特定条件下才执行的系统行为的用例,其是否执行取决于在执行基本用例时所发生的事件 例如:在电话系统中,为用户提供的主要服务通过用例“打电话”来表示,可选服务包括三方通话和通话保持,执行基本用例时,可以执行,也可以不执行扩展用例部分,56,c)泛化关系 如果两个或更多用例在行为、结构和目的方面存在共性,可以用一个新的抽象用例来描述这些共有部分,该用例随后被子用例特殊化,子用例继承父用例的所有结构、行为,执行时,子用例与父用例不存在相互依赖,用例间的扩展关系、包含关系和泛化关系指出了系统潜在的复用机会,父用例,例:图书馆系统用例之间的关系,57,58,3)用例的场景描述,仅凭用例图不足以清楚地描述系统需求,因而还必须用文本对用例进行详述,即use case specification 每个用例都有一系列的场景:一个主要场景,以及多个次要场景(描述执行路径中的异常或可选情况) 用例的场景描述一般包括以下内容: 简单描述:用例名称、参与者、目标、假设条件等 前置条件:这些条件必须在执行用例前得到满足 后置条件:这些条件将在用例完成后得到满足 主事件流:描述用例中各项工作都正常进行时用例的工作路径,不包括任何条件和分支 备选事件流: 描述主事件流的执行分支(可选),包括: 正常可选事件流 错误异常事件流(描述出现异常或发生错误情况下的执行路径),59,例:一个用例的场景描述,用例“登录”的描述 简单描述:本用例描述了用户如何登录到系统中 前置条件:无 后置条件:如果用例成功,则用户登录到系统中;否则系统状态不变 主事件流: 1)系统提示用户输入用户名和密码 2)用户输入自己的用户名和密码,提交 3)系统验证输入的名字和密码(E-1),用户登录系统成功 正常可选事件流:无 错误异常事件流: E-1: 如果输入用户名和/或密码无效,系统提示错误信息,用户可以重新输入或终止该用例,客户,登录,60,用例的场景描述,简单描述:本用例描述了用户完成新订单生成的过程 前置条件:客户登录到系统 后置条件:如果用例成功,则客户订单被创建 主事件流: 1)用户进入商品目录界面查看商品条目,添加想要的商品条目到购物车 2)添加完毕后系统显示所有已选商品条目 3)用户输入付款信息 4)系统验证付款信息( E-1 ),显示订单成功创建的信息 正常可选事件流:无 错误异常事件流: E-1: 如果用户的付款信息不能通过验证,系统提示错误信息,用户可以重新输入付款信息或终止该用例,客户,创建新订单,用例的场景描述,前置条件:图书管理员已被识别和授权 后置条件:如果用例成功,存储借书记录,更新库存数量,所借图书状态为借出 主事件流: 1)图书管理员将读者借书卡提供给系统; 2)系统验证读者身份和借书条件; 3)图书管理员将读者所借图书输入系统; 4)系统记录借书信息,并且修改图书的状态和此种书的可借数量; 5)系统累加读者的借书数量; 6)重复3)- 5),直到图书管理员确认全部图书登记完毕; 7)系统打印借书清单,交易成功完成 正常可选事件流:如读者此前进行了预定,则撤销预定 错误异常事件流: E-1: 如果读者借书数目已达到限额,系统提示错误,61,62,用系统顺序图描述用例 “借出图书”,图示方法比用例的文本描述能更直观地反映出系统的行为 系统顺序图将系统看作黑盒来展示参与者与系统的交互过程,63,用活动图描述用例 “生成新订单”,64,用例模型,若干张的用例图及用例描述构成了系统的用例模型 当系统逻辑较为复杂时,可使用包图来分类组织用例图(即分成若干包,每个包图中包括若干用例) 通常一个子系统对应一个包图,65,4.4 分析模型,用例模型给出了问题空间的描述(要实现哪些用例?),而分析模型则是解空间的逻辑描述(实现每个用例需要哪些对象?对象之间如何通信?) 分析模型包括: 静态模型:展示对象和类如何组成系统(分析类图) 动态模型:对象之间如何交互来实现系统行为(交互图,状态图、活动图),66,1)识别对象、类及其关系,建立类图,面向对象分析与设计的核心工作就是分析和设计对象及类,从而建立类图 步骤: 发现对象,识别其属性和操作 对对象进行合并和调整,为它们建立对应的类,确定类的属性和服务 结合用例的实现确定类的关系,建立类图,67,对象的识别,对象是系统中用来描述客观事物的一个实体,可从问题域的以下几个方面着手寻找: 实物:如图书,汽车,飞机 角色:如雇员,客户,管理员 组织部门:如系,分店,分行 交互行为信息(事件):订单,合同,交易记录 可以通过事件中的出现的名词(如客户,订单,销售报表)以及已有系统的信息中出现的名词来寻找、确定对象 对象的审查: 对象是否参与至少一个用例的实现?若没有,则删除,68,例:图书管理系统的类,69,对象属性的识别,属性是描述对象静态特征的一个数据项,以下问题的回答可帮助确定属性: 如何为对象做一般性的描述?(如客户对象的描述信息有姓名,性别,电话等) 在当前问题域, 对象还具备哪些特定描述项?(如网上订购系统的客户对象可增加“已购买商品的总价格”属性作为优惠依据) 为实现对象的功能还需要了解或提供哪些信息?(如为提供会员优惠,图书对象需要增加“会员价格”属性) 对象可能处于什么状态?(如图书就有有货、缺货两个状态) 对确定的每个属性在设计过程还需要说明:属性的数据类型?取值范围、缺省值?可见性?(公有?私有?) 属性的审查: 属性是否参与到某个操作中?若没有,则删除 该属性是否可从其他属性导出?若是,则删除(如年龄可从出生日期导出),70,例:图书管理系统的类(添加了属性),借书记录中还需要 包含读者、所借图书等 属性,可在设计阶段补充,71,对象操作的识别,操作是描述对象动态特征的一个执行序列。可从以下几个方面着手确定: 考虑对象在系统中的可见行为(如客户对象更改个人信息,订单对象添加商品条目到订单) 分析用例应由哪些对象来实现,各对象各自完成哪些任务,对象是如何发送消息和接收消息并响应的?(可在绘制交互图时识别并添加这类操作) 分析对象的主要状态。状态的转换是由什么操作引发的?在特定状态下对象允许什么样的行为?(如图书对象在“有货”和“缺货”状态之间的转换是由“更新库存”操作引发的) 系统有哪些事件?哪些对象对事件有响应?(如发生库存缺货事件,则缺货商品对象需要创建订货单),72,例:图书管理系统的类图(添加了操作),73,类(对象)之间关系(关联)的确立,关联体现对象实例之间的关系,对象关联的静态特性通过类图反映,动态特性通过顺序图反映,74,类之间的关系,1.一般关联 表示类与类之间的关系 在类图中用一条把类连接在一起的实线表示 1)关联名称 描述关联的作用,通常用动词表示 如果关联的含义已经很明确,则关联名可省略,Employ,如果不使用关联名,则类的关系可以有多种解释,如Person类可以表示公司的客户、股东、雇员等,75,2)关联的角色 关联路径的两端为角色(role),角色规定了类在关联中所起的作用 如果在关联上没有标出角色名,则隐含地用类名表示 角色还具有多重性,表示可以有多少个对象参与该关联,由角色上的表达式指出,如: 01,0*,1,1*,*(即0*),Employer,Employee,1,*,76,3)关联的导向性 单向关联:用单向箭头表示;只需要在源类中增加一个能访问目标类的属性,而目标类不需要了解源类 例:,类A的代码: public class A public B b; public A( ) 类A中有类型为B的属性b,类B的代码: public class B public B( ) 类B中没有类型为A的属性,双向关联:直接用实线表示(没有箭头);源类和目标类都需要增加属性来支持对对方的访问,77,4)关联类 两个对象实例之间的连接若有自己的属性,则可以识别为对象并建立对应的类,其最常见的用途就是协调多对多关系 关联类反映关联的特性,具有类的特征(属性,操作),通过一条虚线与关联连接,Employer,Employee,1,*,78,关联类举例,分解多对多关系,关联类,关联类还可以添加自己的属性,79,类之间的关系(续),2. 聚合 聚合是一种特殊形式的关联,表示类之间整体与部分的关系 使用连接线和空心菱形表示,菱形一端的类代表整体,Circle类有颜色、是否填充等属性,而这些样式属性可以用一个style对象来表示;但style对象也可以表示其他类(如Triangle类)的样式方面的属性 Circle类对象与Style类对象的生存期无关,80,类之间的关系(续),3. 组合 组合是一种特殊形式的聚合,也表示类之间整体与部分的关系 使用连接线和实心菱形表示,菱形一端的类代表整体,圆由半径和圆心确定,如果圆不存在,圆心也不存在 Circle类对象与Center类对象具有相同的生存期 一个部分对象只能属于一个整体对象且不可改变 注意:确定类之间的聚合或组合关系是为了使模型更加明确,如果不能确定属于何种关系,可直接用普通关联表示,81,类之间的关系(续),4.泛化 表示类之间一般与特殊的关系(即继承关系) 使用连接线和空心三角形表示,三角形一端的类代表一般类,特殊类中不用再重复定义一般类中出现的属性或服务,从而可以简化模型描述,有效反映分类层次,82,类的检查,类是否只有一个属性?例如客户经理类只有“姓名”一个属性(不含操作),该属性仅被客户类访问,则可考虑精简客户经理类,将“客户经理姓名”归并为客户类的一个属性 类是否只有一个操作?如果该服务仅被一个类使用,则可考虑将该操作归并到该类中,若有计划扩展“PostcodeValidator类”的操作,如增加电话号码有效性检查、身份证号有效性检查等,则可保留该类独立存在,并重新命名为“Validator类

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论