第九章-使用UML进行面向对象分析和建模.ppt

第九章-使用UML进行面向对象分析和建模.ppt

  1. 1、本文档共43页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第9章 使用UML进行面向对象分析和建模 9.1 面向对象分析概述 面向对象分析技术用于:1)研究现有对象,看能否复用它们或者调整它们用于新的用途;2)定义各种新对象和修改后的对象,它们将与现有对象一起组合成一个有用的企业计算应用系统。 面向对象的分析(OOA)是: 按照对象(事物、概念、实体)的观点考虑 问题域,识别出问题域的不同概念,并用概念模 型表示 面对对象方法的核心一种称为对象建模的技术 对象建模是一种用于辩识系统环境中的对象和这些对象之间关系的技术。 统一建模语言(UML):是一套建模规则,它使用对象说明或描述软件系统。 9.2对象建模的系统概念 10.2.1 对象、属性、方法和封装 对象封装了描述离散的个人、对象、地点、事件或事物的数据(称为属性)以及所有使用或修改数据和属性的过程(称为方法)。访问或修改对象的数据的唯一方法是使用对象预定义的过程。 属性:对象的数据部分 例如学生的属性,学号,姓名,班级,性别等。 行为:指对象可以做的事情,以及在对象数据上执行的功能。在面向对象环境中,对象的行为通常称为方法、操作或者服务。 对象实例由描述特定的人、地点、事物或者事件的属性值构成。 封装:对象单独的负责执行任何在其数据上操作的功能或者行为。对象的属性和行为都被封装到一起作为那个对象的一部分。 例如只有你(对象)可以修改(行为)你的名字和家庭住址(属性) 对象实例使用包含对象实例名称的矩形表示,对象实例名字由唯一标示对象的属性值,冒号以及对象所属的类的名称构成。整个名字居中显示,并用下划线标出。 9.2.2 类、泛化和特化 对象类是共享相同属性和行为的对象集合。类有时称为对象类。 类、泛化和特化 继承是指在一个对象类中定义的方法和/或属性可以被另一个对象类继承或复用。 泛化/特化是一种技术,其中几类对象类的公共属性和行为被组合成类,称为超类。超类的属性和方法然后被那些对象类(子类)继承。 超类 – 是包含一个或多个对象子类的公共属性和行为的实体,也称为抽象类或父类。 子类 –是一个对象类,它从一个超类继承属性和行为,并可能包含自身所特有的属性和行为。如果它位于继承层次的最底层,也称为实类. 超类和子类之间具有一个和多个一对一的关系 10.2.3 对象/类关系 对象/类关系是一种存在于一个或多个对象/类之间的自然业务联系。 多重性:定义一个对象/类对应相关对象类的一个实例关联可能的最小出现次数和最大出现次数. 聚合关系 聚合关系:是一个较大的“整体”类饱含一个或多个较小的“部分”类之间的关系。 合成关系 合成关系:是一种特殊的聚合关系,其中“整体”负责其“部分”的创建和销毁,如果整体不存在,部分也不存在. 部分只能与一个整理关联 9.2.4 消息和消息发送 消息:对象/类通过传递消息进行交互或者沟通 对象发送消息只要知道它响应正确定义的消息请求就可以了,无需知道内部是如何实现的 9.2.5 多态性 多态:不同对象可以以不同的形式响应同样的消息. 重载:是一种技术,其中子类使用它自己的属性或行为,而不是从父类继承属性或行为。 9.3 UML模型图 用例模型图 静态结构图 类图 对象图 交互图 顺序图 协作图 建模一个特定对象的动态行为,说明了一个对象的生命周期——对象可以经历的各种状态,以及引起对象从一个状态向另一个状态转换的事件。 9.4 对象建模过程 面向对象分析要求我们辩识从用户角度开发所需的系统功能、支持所需系统功能的对象、对象的数据属性、相关的行为以及对象之间的关联。 面向对象分析包含三个活动: 建模系统功能[用例参与者词汇表、用例图、用例描述、活动图] 发现并确定业务对象[对象列表]. 组织对象并确定其关系[类图]. 9.4.2 构造分析用例模型 在面对对象分析中,我们需要通过以下的步骤将业务需求用例模型转化为分析用例模型 第1步:确定、定义并记录新的参与者 第2步:确定、定义并记录新的用例 第3步:确定任何复用的可能性 第4步:细化用例模型图 第5步:记录系统分析用例描述 记录抽象用例描述和扩展用例描述 第1步:确定、定义并记录新的参与者 在创建了业务需求用例模型和其最终被系统所有者批准之间,系统分析员和开发团队的其他成员通过与关联人员交谈和研究项目发布物,继续了解系统成功还需要什么。通过这些努力,有可能会发现需要被定义和记录的额外参与者。 第2步:确定、定义并记录新的用例 用于处理业务事件的每种类型的用户接口都需要自己的用例 第3步:确定任何复用的可能性 当两个用例有同样的业务目标但接口技术和实际的系统用户不同时,两个用例可能共享公共的步骤。 为了消除冗余步骤,可以将这些公共步骤提取成独立的用例,称为抽象用例 当分析用例并发现某个用例包含多个步骤构

文档评论(0)

好文精选 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档