第04章：UML系统分析与设计-类图和对象图
第4章 系统分析与设计概要
“图书管理系统”分析设计报告（实例）
类方法： 方法名 savaBook deleteBook updateBook getBook 方法功能 添加图书信息 删除图书信息 修改图书信息 根据id查找某本图书的详细信息 返回值类型 void void void
getBooks
查询图书信息
List
“图书管理系统”分析设计报告（实例）
面向对象分析模型由三个独立的模型组成：功能模型、对 象模型和动态模型。
4.1概述
系统设计是在分析模型的基础上形成实现环境下的设计模型 面向对象设计是根据已建立的系统分析模型，运用面向对象 技术，进行系统的软件设计。 面向对象设计是面向对象分析到实现的一个桥梁。面向对象 分析是将用户需求经过分析后，建立问题域精确模型的过程； 而面向对象设计则是根据面向对象分析得到的需求模型，建 立求解域模型的过程。 设计主要涉及体系结构设计、用户界面设计和数据库设计等 方面。
4.1概述
面向对象设计是面向对象分析的延伸、扩展。 面向对象方法学在概念和表示方法上的一致性，所以从面 向对象分析到面向对象设计没有转换，只是扩展、调整。 面向对象分析的结果可以直接移植到面向对象设计的结果 中来，分析到设计是平滑过渡。 开发大系统时可采用从面向对象分析到设计顺序进行，对 于小系统，这两个阶段可以是交替进行的。
4.2分析阶段的任务
（3）功能模型： 功能模型由一组数据流图组成。它表明了系统中数据之间 的依赖关系，以及有关的数据处理功能。 数据流图可描述功能的依赖关系，它的“处理”对应于状 态图的活动和动作，它的“数据流”对应于对象图中的对 象或属性。 建立功能模型一般在建立了对象模型和动态模型之后。在 面向对象方法学中，数据流图不像在结构化方法中那样重 要。
面向对象软件工程与UML第4章 详细设计1
次关系。
特点：没有流程线，不可能随意转移控制
S1 S2 (a)
T S1
IF条 件
CASE条 件 F S2 值1 值2 … … 值n CASE n 部分
CASE 1 CASE 2 部分 部分 (c)
(b) while循 环条 件 while -do部 分 do -until部 分
读、易记、易修改。
(2) 为多种常用高级语言提供了相应的图形符号，
每种控制语句都与一个专门的图形符号相对应，易于
PAD图向高级语言源程序转换。
(3) 支持自顶向下、逐步求精的设计过程。
(4) 既能够描述程序的逻辑结构，又能够描述系
统中的数据结构。
开始 在工资档案中读一条记录
是文件结束位置吗? N
Y
型”语言。
PDL语言与结构化语言的主要区别在于： PDL语法结构更加严格并且处理过程描述更加具体详细
PDL语言主要特点： (1) 各种定义语句及控制结构的表达都具有严格 的语法形式，使程序结构、数据说明等更加清晰。 (2) 提供了数据说明机制，可用于定义简单及复 杂的数据结构。
(3) 提供了模块的定义和调用机制，方便了程序
详细设计说明书包括的内容
(1) 引言：用于说明编写本说明书的目的、背景，定义所 用到的术语和缩略语，以及列出文档中所引用的参考资料等。
(2) 总体设计：用于给出软件系统的体系结构图。
(3) 模块描述：依次对各个模块进行详细的描述，主要包 括模块的功能和性能，实现模块功能的算法，模块的输入及输 出，模块接口的详细信息等。
5.2 面向数据流的详细设计方法
面向数据流的详细设计方法关键技术:
第四章 用例图-UML面向对象分析、建模与设计-吕云翔-清华大学出版社
依赖关系
特性 作用 执行过程 对基用例的要求
include
extend
增强基用例的行为
增强基用例的行为
包含用例一定会执行
扩展用例可能被执行
在没有包含用例的情况下，在没有扩展用例的情况下， 基用例可以是也可以不是 基用例一定是良构的 良构的
表示法
箭头指向包含用例
是用例的重要服务对象，而次参与者处于一
种协作地位。
系统管理员
用例与参与者
在确定用例时可以通过参与者入手来寻找用例：
参与者的主要任务是什么？ 参与者需要系统的什么信息？ 参与者可以为系统提供什么信息？ 系统需要通知参与者发生的变化和事件吗？ 参与者需要通知系统发生的变化和事件吗？
用例的特征
用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用 例是否准确的依据。
不改变基用例的同时，根据需要自由地向用
例中添加行为。
检查实名信息
依赖关系——扩展
扩展用例的使用包括四个部分：
基用例：需要被扩展的用例，如图5-10中的“注册”用例。 扩展用例：提供所添加的行为序列的用例，如图5-10中的“检查实名信
息”用例。 扩展关系：使用虚线箭头表示，箭头指向基用例。 扩展点：基用例中的一个或多个位置，表示在该位置会根据某条件来决
一个父参与者的直接实例，这就要求属于抽象父
直接客户
电话客户
参与者的外部对象一定能够属于其子参与者之一。
网上客户
用例的概念 用例与参与者 用例的特征 用例的粒度
用例
用例的概念
用例是类元提供的一个内聚的的功能单元，表明系统与 一个或多个参与者之间信息交换的顺序，也表明了系统 执行的动作。
面向对象分析与设计 第4章 UML图
20
• 阻止(balking)消息。消息发送者发出消息给 接收者，如果接收者无法立即接收消息，则发 送者放弃这个消息。 例：阻止消息的表示符号。
21
• 超时(time-out)消息。消息发送者发出消息给 接收者并等待指定时间，如果接收者无法在指 定时间内接收消息，则发送者放弃这个消息。 例：超时消息的表示符号。
例：调用消息的表示符号。
说明： 1. 调用消息的接收者必须是一个被动对象(passive object)， 即它是一个需要通过消息驱动才能执行动作的对象。 2. 一般调用消息必有一个配对的返回消息。
17
• 异步消息(asynchronous)。异步消息的发送者通 过消息把信号传递给消息的接收者，然后继续自 己的活动，不等待接收者返回消息或控制。 例：异步消息的表示符号。
12
Focus of control(控制焦点)
• focus of control：A symbol on a sequence diagram that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure. • 图例：
22
例：一些消息的例子
2: display (x, y)
1.3.1: p:= find(specs) 4 [x < 0] : invert (x, color) 3.1*: update ( ) 简单消息 嵌套消息，消息带返回值 条件消息 循环消息
A3,B4/ C2: copy(a,b)
线程间同步
显示对象名和类名
软件设计与体系结构-第四章-面向对象的软件设计方法课件
l 概念模型与顶层架构设计:
l 在用户需求和相关的业务领域中，概念及概念关系的抽取
l 用户界面设计:
l 设计每个界面中的所有界面元素，确定初步的界面布局，定义用户界面动作对软件系统中设计元
素的要求
l 数据模型的设计:
l 确定设计模型中需要持久保存的类的对象及其属性，定义持久持久存储数据之间的组织方式，并
.
26
概念模型和顶层架构设计
l 边界类: 其职责包括: l 边界控制: l 包括定义数据的格式及内容转换，输出结果的呈现，软件运行过程中界
面的变化与切换等。 l 外部接口: l 实现目标软件系统与外部系统或外部设备之间的信息交流和互操作，主
要关注跨越目标软件系统边界的通信协议 l 环境隔离: l 对目标软件系统与操作系统、数据库管理系统、中间件等环境软件进行
事件流中步骤（1）
l （3）如果账户余额小于取款金额，则显示信息“账户余额不足，请重新输入”，并返回主事件流
中步骤（1）
l （4）顾客在确认取款金额前右以选择取消交易。
l 后置条件: 如果取款成功，系统从账户余额中减去相应数额，并返回等待状态；如果顾客取消交易，
则返回等待状态
.
19
用例的分析与设计
体技术没有关系 l 顶层架构的设计 l 目的: 为后续的分析和设计活动建立一种结构和划分
.
24
概念模型和顶层架构设计
l 关键概念来源: l 为建立以UML类图表示的领域概念模型，首先必须标识关键概念。关键
概念的来源包括: l （1）业务需求描述、用例说明； l （2）业务领域中的相关规范、标准、术语定义。 l （3）反映业务领域知识的既往经验。 l 业务需求描述 l 业务领域中的相关规范、标准、述评呼定义 l 反映业务领域知识的既往经验
UML中数据流图，用例图，类图，对象图，角色图，活动图，序列图详细讲述保存供参考
UML中数据流图，⽤例图，类图，对象图，⾓⾊图，活动图，序列图详细讲述保存供参考这个⽂章，是我在急需的情况下在园⼦⾥搜索到的，原创作者是：DO-websoftware,为了⾃⼰看⽅便，所以复制到我的空间，希望原创者不要介意哦~~~~很详细的介绍，对我的帮助很⼤，谢谢哦。
类图，对象图，⾓⾊图：⼀、UML中基本的图范畴：在 UML 2 中有⼆种基本的图范畴：结构图和⾏为图。
每个 UML 图都属于这⼆个图范畴。
结构图的⽬的是显⽰建模系统的静态结构。
它们包括类，组件和（或）对象图。
另⼀⽅⾯，⾏为图显⽰系统中的对象的动态⾏为，包括如对象的⽅法，协作和活动之类的内容。
⾏为图的实例是活动图，⽤例图和序列图。
⼆、UML中的类图：1.类图的表⽰：类的 UML 表⽰是⼀个长⽅形，垂直地分为三个区，如图 1 所⽰。
顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。
描述：顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。
·类名：如果是抽象类，则采⽤斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0，这是带有默认值的表达形式·类⽅法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
UML各种图例—用例图、类图、状态图、包图、协作图、顺序图
UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
UML分析与设计
二、分析问题
分析问题的主要任务是：对问题领域进行抽象，
提出解决方案；对未来系统进行需求分析，确定 系统的职责范围、功能需求、性能需求、应用环 境及假设条件等；用Use Case图对未来系统的 行为建立模型，初步确定未来系统的体系结构。
23
2.1 确定系统范围和系统边界
首先要确定业务需求和系统目标。简易教学管理系统JXGL用于新学 期课程的选课注册管理和学生的成绩管理。凡是这两方面的教学管理 内容都是JXGL系统的职责范围，其他的教学管理内容，如：安排教
系统实现 对象设计：从系统框架 程序结构
可重用构件、可重用系统框架
系统测试
单元测试：测试类（基于类图和状态图） 集成测试：测试协作关系（基于构件图和协作图） 系统测试：测试系统功能（基于用例图）
18
一、系统需求--选课管理[1]
在选课管理方面应提供的服务功能如下：
1. 录入与生成新学期课程表。 教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供 师生参考选择。(若某课程的实际选课学生少于10人，则停开该课程，把该 课程从课程目录表中删除；若某课程的选课学生多于30人，则停止选课。) 2. 学生选课注册。 新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许 改变或取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注 册。在选课注册结束后，教学管理员打印学生选课注册名单和开课通知书， 送交有关部门和授课教师。
21
一、系统需求--其他
在数据库方面的考虑： 为了保存数据，需建立教学管理数据库。可以采用关系数据库：学生表、教 师表、课程表、选课表、任课表、成绩表。 简易教学管理系统JXGL的直接用户有学生、教师和教学管理员。教学管理 员有权操纵数据库的数据，进行增、删、改等操作。学生和教师一般只查询 信息，只允许对自己有关的数据进行添加、更新、删除等操作。 跟外部系统的连接： JXGL的相关系统有财务系统。JXGL系统需要把学生的选课注册信息传送 给财务系统，以供财务系统计算学生应交纳的费用，但不是要求财务系统返 馈学生交纳的费用信息。 硬件部署方面的考虑： JXGL将采用客户机/服务器结构建立，JXGL系统的应用服务器和数据库服 务器设置在学校计算中心工作站。学生、教师和教学管理员可以在各系、各 部门、图书馆、学生宿舍的台式PC机上使用JXGL系统。
UML课件5-类图和对象图详解
5.4.3 寻找类（三种常用方法）
1. 使用名词/动词法分析寻找类
收集相关信息 补充的需求规格说明 用例 项目词汇表 其他文档
选取类的属性时只考虑系统用到的特征，不必将所有属 性都表示出来，原则上，由类的属性应能区分每个特定 的对象。
5.1.1 属性
可见性
属性的可访问性，四类： 公共（public）
私有（private）
保护（protected）
实现（implementation） 子类无法继承和访问父类的私有属性和实现属性
先调用Order的dispatch ()方法，它将根据其包含的OrderItem中 产品信息，来按供应商户分拆成若干个DeliverOrder。商户登录 系统后就可以获取其DeliverOrder，并在执行完成后再调用close ()方法。此时，就将调用OrderItem的stateChange()方法来改变 其状态。同时再调用Order的close()方法，判断该Order的所有 的OrderItem是否都已经送到了，如果是就将其真正close()掉。
一个公司有多个部门，一个职员为其中某部门工作，则 可推导该职员为该公司工作。
5.2.2 泛化
Generalization，一般元素和特殊元素之间 的关系。即OO语言中，类之间的继承关系
斜体表示 抽象类
5.2.2 泛化
泛化的目的
自顶向下的属性继承。可以使得子类共享父类的属性 和操作，实现继承。
5.1.2 操作
标准格式：
[可见性] 操作名[ (参数列表) ] [: 返回值类型][{特性}]
例：
+display() #create() -attachXWindow(xwin:XWindowPtr) +getname():String
第4章 面向对象系统分析与对象类建模 2
⑶ 类的操作
其语法如下： [方向]名称：类型[ = 默认值] [direction] name：type [= default value] 方向可以取下述值之一： in输入参数，不能对它进行修改。 out输出参数，为了向调用者传送信息可以对它进 行修改。 inout输入参数，为了向调用者传送信息可以对它 进行修改。
第4章 面向对象系统分 析与对象类建模
教学目的
⑴ 掌握面向对象系统分析的过程 ⑵ 掌握系统用例模型的设计方法
⑶ 了解类和对象的概念、类与对象的关系等
⑷ 重点掌握系统用例模型的设计和对象与类图 的设计
4.1 面向对象系统分析
面向对象分析，就是抽取和整理用户需求并 建立问题域精确模型的过程。 面向对象分析过程从分析陈述用户需求的文 件开始 可能由用户（包括出资开发该软件的业主代 表及最终用户）单方面写出需求陈述，也可 能由系统分析员配合用户，共同写出需求陈 述 当软件项目采用招标方式确定开发单位时，
关联可以有方向，即导航。 一般不作说明的时候，导航是双向的，不需要在线上标出箭头。 大部分情况下导航是单向的，可以加一个箭头表示。 导航性描述的是一个对象通过链（关联的实例）进行导航访问另 一个对象，即对一个关联端点设置导航属性意味着本端的对象可 以被另一端的对象访问。 可以在关联关系上加箭头表示导航方向。 只在一个方向上可以导航的关联称为单向关联，用一条带箭头的 实线来表示。 在两个方向上都可以导航的关联称为双向关联，用一条没有箭头 的实线来表示。
关联的多重性是指有多少对象可以参与该关联，多重性可 以用来表达一个取值范围、特定值、无限定的范围或一组 离散值。 将多重性写成一个表示取值范围的表达式，其最大值和最 小值可以相同，用两个圆点把它们分开。 多重性说明对于关联另一端的类的每个对象，本端的类可 能有多少个对象出现，对象的数目必须是在给定的范围内。 可以精确地表示多重性为：一个（1）；多个（0..*）；一 个或多个（1..*）；整数范围，
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
类图的组成
实现关系将一种模型元素（如类）与另一种模型元素（如接口） 连接起来，是说明和其实现之间的关系。
类图的组成
属性是类的一个特性，也是类的一个组成部分，描 述了在软件系统中所代表的对象具备的静态部分的 公共特征抽象，这些特性是这些的对象所共有的。
在UML中，类的属性的表示语法为（[ ]内的内容是 可选的）：
[可见性] 属性名称 [：属性类型] [=初始值] [{属性 字符串}]
类图的组成
类图的组成
1. 类
类是面向对象系统组织结构的核心。类是对一组具有相 同属性、操作、关系和语义的事物的抽象。
在UML的图形表示中，类的表示法是一个矩形，这个矩 形由三个部分构成，分别是：类的名称（Name）、类的 属性（Attribute）和类的操作（Operation）。
类图的组成
类的名称是每个类的图形中所必须拥有的元素，用于同其 它类进行区分。类的名称通常来自于系统的问题域，并且 尽可能地明确表达要描述的事物，不会造成类的语义冲突。
类图的组成
类的约束指定了该类所要满足的一个或多个规则。在 UML中，约束是用一个大括号括起来的文本信息。
类图的组成
类的注释
类图的组成
2. 接口
类接口是在没有给出对象的实现和状态的情况下对对象行为的描述。 通常，在接口中包含一系列操作但是不包含属性，并且它没有对外界 可见的关联。
接口是一种特殊的类，所有接口都是有构造型<<interface>>的类。一 个类可以通过实现接口从而支持接口所指定的行为。
类图的组成
泛化关系是用来描述类的一般和具体之间的关系。具体描 述建立在对类的一般描述的基础之上，并对其进行了扩展。 因此，在具体描述中不仅包含一般描述中所拥有的所有特 性、成员和关系，而且还包含了具体描述补充的信息。
类图的组成
关联关系是一种结构关系，指出了一个事物对象与另一个 事物对象之间的语义上的连接。
[可见性] 操作名称 [（参数表）] [：返回类型] [{属性 字符串}]
类图的组成
在标准的UML定义中，有时还应当指明类的另一种信 息，那就是类的职责。类的职责指的是对该类的所有 对象所具备的那些相同的属性和操作共同组成的功能 或服务的抽象。
在声明类的职责的时候，可以非正式的在类图的下方 增加一栏，将该类的职责逐条描述出来。类的职责的 描述并不是必须的，因此也可以将其作为文档的形似 存在，也就是说类的职责其实只是一段或多段文本描 述。一个类可以有多种职责，设计得好的类一般至少 有一种职责。
在UML中，接口的表示方式是使用一个带有名称的小圆圈来进行表示 的，并且我们可以通过一条Realize（实现关系）线与实现它的类相连 接
类图的组成
3. 类之间的关系
依赖关系：表示的是两个或多个模型元素之间语义上的连接关 系。它只将模型元素本身连接起来而不需要用一组实例来表达 它的意思。
它表示了这样一种情形，提供者的某些变化会要求或指示依赖 关系中客户的变化。也就是说依赖关系将二个类联系起来，其 中一个类会影响另一个类的行为和实现。
创建类图
2. 创建类之间的关系
（1）创建和删除依赖关系。 （2）创建和删除泛化关系。 （3）创建和删除实现关系。 （4）创建和删除关联关系。
对象图的概念
类图的作用是对系统的静态视图进行建模。当对系统的静态视图 进行建模时，通常是以以下三种方式来使用类图。 1. 为系统的词汇建模。 2. 模型化简单的协作。 3. 模型化逻辑数据库模式。
在设计数据库时，通常将数据库模式看作为数据库概念设计的蓝 图，在很多领域中，都需要在关系数据库或面向数据库中存储永 久信息。系统分析者可以使用类图来对这些数据库进行模式建模。
类的操作指的是类的所能执行的操作，也是类的一个 重要组成部分，描述了在软件系统中所代表对象具备 的动态部分的公共特征抽象。
操作由一个返回类型、一个名称以及参数表来描述。 其中，返回类型、名称和参数一起被称为操作签名 （Signature of the Operation）。操作签名描述了使用 该操作所必需的所有信息。在UML中，类的操作的表 示语法为（[ ]内的内容是可选的）：
UML系统分析与设计
第四章：类图和对象图
学习内容
类图的概念 类图的组成 创建类图 对象图的概念 创建类图案例分析 创建对象图案例分析
类图的概念
1. 类图的概念
类图（Class diagram）显示了系统的静态结构，而系统的 静态结构构成了系统的概念基础。
类图，就是用于对系统中的各种概念进行建模，并描绘出 它们之间关系的图。
在实现关系中，接口只是行为的说明而不是结构或者实现，而 类中则要包含了其具体的实现内容，可以通过一个或多个类实 现一个接口，但是每个类必须分别实现接口中的操作。虽然实 现关系意味着要有像接口这样的说明元素，它也可以用一个具 体的实现元素来暗示它的说明（而不是它的实现）必须被支持。
创建类图
1. 创建类
1. 在图形编辑工具栏中，选择 按钮，此时光标变为“＋”号。
2. 在类图中单击选择任意一个位 置，系统在该位置创建一个新类。 系统产生的默认名称为 “NewClass”。
3. 在类的名称栏中，显示了当前 所有的类的名称，我们可以选择清 单中的现有类，这样便把在模型中 存在的该类添加到类图中。如果创 建新类，将“NewClass”重新命名 成新的名称即可。
在大多数的 UML 模型中，我们可以将这些概念的类型概 括为以下四种，分别是： 1类 2 接口 3 数据类型 4 构件
类图的概念
在类图中，具体来讲 它一共包含了以下几 种模型元素，分别是： 类、接口、依赖关系、 泛化关系、关联关系 以及实现关系。
类图可以创建约束、 注释和包等。
类图的概念
类图在项目开发中的作用