·delete()删除类实例的信息。
.update()更新类实例的信息。
类操作的识别主要在第11章中设计序列图时进行。在设计序列图时，为了满足用例路径，可能需要为类重新定义操作。
与类的识别一样，类操作的识别也需要往复多次才能完成。本章建立的类模型，还只是一个初步的模型。随着对系统静态和动态特性的深入了解，类模型还需不断调整或细化。
项目
Invoice
票据
User
用户
2
要画出类图，不仅要识别出系统中的类，还要识别出类与类之间的关系。
显式的关系可以从用例中找到，而隐式的关系在用例中没有明确的说明，这需要系统分析员去细心发现。
表2列出了系统实例中类的关系。
表2系统中类的关系
类
关系
类
Project
拥有
Invoice
Project
涉及
User
因此去掉。
市场竞争力对于系统来说，不需要持久保存，不能识别为系统中的实体，因此去掉。
家用电器、产品意义相近或相同，并且对于系统来说，不需要持久保存，不能识别为系统中的实体，
因此去掉。
创新基金对于系统来说，只有一个，没有身份，不能识别为系统中的实体，因此去掉。
创新基金管理信息系统、新系统意义相近或相同，并且对于系统来说，只有一个，没有身份，不能
供应商
报销内容
报销金额
报销时间
报销人
付款方式
是否附合同
是否附通知
票据张数
4.3 User类
User类标识用户。在本系统中，对User类我们所关心的是用户的账户、姓名、权限、部门和密码。
这样，对User类可以初步找出以下一些属性：
● 账户
● 姓名
● 权限
● 部门
● 密码
5找出类的操作
类的操作定义了类的行为。相对来说，识别类的操作比识别类的属性要容易一些。可以从如下几个方面去识别类的操作：
要注意分辨类与属性。在类的识别中，曾经提到过，从系统描述中找出的名词，并不都对应着一个对象(类)，有的名词可能只是其他对象的一个属性。
类的属性最后要映射到数据库中的数据表的列。
与类的识别一样，类属性的识别也需要往复多次才能完成。
4.1 Project类
Project类标识项目。在我们这个系统中，我们关心的项目信息有：项目名称、项目经费、报销单位和报销人等。因此，对Project类可以初步找出以下一些属性：
· 类本身应该有哪些操作来维持其信息的更新、一致性和完整性?
· 系统要求类具有什么作用?
· 这个类要为别的类提供什么?
现在来识别类的操作还为时过早，因为现在并不清楚系统需要这些类提供哪些服务。不过，一个类通常需要以下一些必须的、基本的服务：
· getlnfo()选择类实例的信息。
· insert()插入类实例的信息。
正如人的身份证唯一地代表一个人。在传统的数据库设计中，E.R图中的实体表
示系统中的持久的元素，要映射为数据库中的数据表。UML中的实体也表示系统中的持久的元素。两
者的区别在于，UML中的实体除表示系统中的持久的元素外，还具有行为特性——操作。因此，如果
3 画出类图
类图主要描述系统中类、类与类之间的关系。前两节已经识别出了系统的类以及类与类之间的关系。从表l0.2可以看出，与Project类有关系的类是Invoice和User。一个项目有0或多张票据，一张票据属于一个项目，因此Project类与Invoice类之fnq存在着一到0或多的双向关联；一个项目有一或多个报销人，一个用户可能是0或多个项目的报销人，因此Project类与User类之间存在着0或多到一或多的双向关联。
● 项目大类
● 项目小类
● 项目经费
● 已报销金额
● 报销单位
· 报销人
4.2 Invoice类
Invoice类标识票据。对于本系统，我们所关心的是一张票据的报销内容、供应商、报销金额、报销时间、报销人、付款方式、票据张数、是否附合同、是否附通知。另外，考虑到对报销后的票据归档，还要有凭证号。这样，对Invoice类可以初步找出以下一些属性：
UML
类模型是面向对象分析的核心，用类图来描述。类图主要描述系统中类、类与类之间的关系。
1
要找出系统中的类，也要首先掌握识别类的方法，然后再从系统中
把类一个一个找出来。
1.1 怎样找
识别类比识别用例要困难得多。虽然从理论上说，我们生活在一个实体世界中，周围的一切都是对
象，但是识别起来并非易事。因为长期以来，人们，特别是程序开发人员，在认识世界时总是从功能出
报销人、审核人、用户、公司领导是系统中的实体，可以识别为一个类，保留名称“用户”。
财务室是管理部门中的一个，而管理部门又是部门中的一个类别。因此，将“部门”识别为“用户”
类的一个属性。
公司财务报销规定虽然需要持久保存，但不是一个实体。
飞机票是票据的一种，因此它只是类“票据”的一个对象。
项目经费总额可以识别为类“项目”的属性“项目经费”。
以识别为类。但是要注意，并不是每个名词都对应着一个对象(类)，可能有的名词只是其他对象的一
个属性，也可能几个名词对应着一个对象(类)。
找出的名词是否都应该成为系统的对象(类)，有一个简单的判断方法：考察其是否有与该对象(类)
相关的身份和行为，如果有，那么它就是系统中的一个对象(类)。身份指的是一个对象的唯一标识，
UML初学者识别类时开始有困难，不妨首先找出系统中E—R图中的实体，即系统中的持久的元素，然
后参照E.R图中的实体去定义UML中的实体。
1.2找出类
现在，采用名词识别方法来识别系统实例中的类。
第一步，从系统描述中找出用来描述问题域实体的名词。根据9.1节对系统的描述，可以得到以下
一些名词：
企业、家用电器、市场竞争力、公司、创新基金、产品、管理部门、决策信息、创新基金管理信息
识别为系统中的实体，因此去掉。
票据是系统中的实体，可以识别为一个类“票据”。
决策信息、人工处理方式、开发计划对于系统来说，不需要持久保存，不能识别为系统中的实体，
因此去掉。
研究项目是系统中的实体，可以识别为一个类“项目”。
汽油票金额、发票的金额是项目开支的经费的一种，它们可以识别为类“项目”的属性“报销金额”。
发，因而反映在头脑里的往往是功能而不是实体对象。
识别类的方法不止一种，但通常使用的识别方法是名词识别方法。下面，简单介绍一下名词识别方法。
一般来说，描述问题域实体都用名词或名词短语。应用名词识别方法时，要从系统描述中找出名词、
名词短语或名词性代词，它们往往对应着对象(类)。其中单数名词可以识别为对象，而复数名词则可
招待费是票据报销内容的一种，因此可以为类“票据”识别一个属性“报销内容”。
财务档案对于系统来说，只有一个，没有身份，不能识别为系统中的实体，因此去掉。
报表、系统资源对于系统来说，不需要持久保存，不能识别为系统中的实体，因此去掉。
经过上面的筛选，初步得到如下表所示的一些类。
表1系统中的类
类
含义
Project
现在可以画出类图，如图1所示。
图1系统类图
类的属性一般描述类的某个特征。在识别属性时，要从类的语义完整性角度来斟酌取舍。所谓类的语义完整性，是指类的属性能够在一起完整地描述一个类所具有的特性和特征。
类属性的识别依赖于系统的问题域。一般来说，类所对应的实体具有很多种不同的特征。但是，在某个特定系统的问题域中，系统分析员只对其中某些特征感兴趣，只有这些特征才可能成为该类的属性。
系统、新系统、票据、人工处理方式、开发计划、研究项目、财务室、项目开支的经费、报销人、公司
财务报销规定、汽油票金额、发票的金额、飞机票、项目经费总额、招待费、财务档案、用户、报表、
系统资源、公司领导。
第二步，从候选对象(类)中筛选去掉一部分名词。
企业、公司意义相近或相同，并且对于系统来说，只有一个，没有身份，不能识别为系统中的实体，