从面向对象的角度来看，世界就是由对象组成的。 任何给定的商业功能都是由一整套共同工作的对象互相协作来完成的。 对象不仅可以执行功能，还拥有属性（数据）。 计算机世界更好地映射现实世界。

引例 传统结构化编程：面向过程、模块分解 就餐服务的模块结构图： 面向对象编程：对象、协作 餐馆业务静态模型（类图）： 餐馆业务动态模型（顺序图）： 面向对象方法有如下优势： 更符合人类思维方式 各阶段过渡平滑 生命力强 易于扩充和维护 与数据模型一致

用例建模解决了业务管理功能到信息系统功能的映射； 领域对象建模解决业务管理对象到信息系统逻辑结构（软件结构模型和数据库结构模型）的映射； 对象建模采用的是面向对象分析技术，有关模型包括： -类图（class diagram）：对象及其关系，用于描述系统静态结构； -状态图（statechart diagram）：对象的状态及转换，用于描述基于事件响应的对象动态行为和状态之间的关系；

什么是领域对象 领域对象就是问题域中有意义的概念类，它们是现实系统中的事物（things）或事件（events）。 软件系统中的类一部分来自于领域对象。

1、Wirfs-Brock名词短语策略 1 阅读理解需求文档（或用例说明）； 2 反复阅读，筛选出名词或名词短语，建立初始对象清单（候选对象）； 3 将候选对象分成三类，即显而易见的对象、明显无意义的对象和不确定类别的对象； 4 舍弃明显无意义的名词或短语； 5 小组讨论不确定类别的对象，直到将它们都合并或调整到其它两类。

以下是“借出图书”用例的主事件流，由此可以获得候选概念类清单。 1．图书管理员将读者借书卡提供给系统； 2．系统验证读者合法性和借书条件； 3．图书管理员将读者所借图书输入系统； 4．系统记录借书信息，并且修改图书的状态和此种书的可借数量； 5．系统修改读者的可用限额； 6．重复3-5，直到图书管理员确认全部图书登记完毕； 7．系统打印借书清单，交易成功完成。 图书状态总是和具体的图书联系在一起，不是一个独立的对象。同理，借书数量、可用限额是读者属性。 可借数量是某个图书品种的特性，每本图书归属于一个图书品种，图书品种是一个隐含概念。

2、不同类别的概念 人员：系统需要保存或管理其信息的人员（如录象商店的会员、图书馆的读者），或在系统中中扮演一定角色的人员（如录象商店的职员、论文评阅教师）。 组织：在系统中发挥一定作用的组织机构（如录象商店的连锁店，医疗保险系统中的医院，学校中的系）。 物品：需要由系统管理的各种物品（如录象商店的商品、图书），包括无形事物（如学校的一门课程、毕设题目）。 设备：在系统中被使用或由系统进行监控的设备、仪器等，系统运行中的硬件设备（如打印机）除外。 事件：需要由系统长期记忆的事件（如在自动柜员机上的每次取款事件、每次借书事件）。 规格说明：系统中关于对象的规格信息的描述。 -如图书品种，每种图书有一个唯一的馆藏号，同时该图书还包含一些描述信息，如书号、价格、作者、出版社等，多本图书对象共用这些规格说明。 -当某种事物有多种类别时（如教师有讲师、副教授、教授，影片分儿童片、新片等），使用规格说明而不是建立多个子类，因为子类对象建立后可能会修改类型（如讲师变为教授） 业务规则或政策：系统中经常使用的业务规则或政策的文字描述。 -业务规则通常会在用例文档之外以其它条款说明。如图书馆系统中，对不同违规行为指定不同的罚款金额，商店对不同顾客或产品有不同的折扣策略等。如果这些规则无法并入到其他对象中，则可以作为概念类建立。 -通常规则可能仅有属性，或者仅有操作，比如折扣策略可能是一个纯粹的计算类。

图书馆系统的概念类 图书馆系统的第1张类图 类的属性即类的数据职责，类的操作即类的行为职责。设计类是面向对象设计中最重要的组成部分，也是最复杂和最耗时的部分。 在软件系统运行时，类将被实例化成对象(Object)，对象对应于某个具体的事物，是类的实例(Instance)。 类图(Class Diagram)使用出现在系统中的不同类来描述系统的静态结构，它用来描述不同的类以及它们之间的关系。

UML类图： Java代码片段：

属性是描述对象静态特征的一个数据项。 发现属性的策略： -如何为对象做一般性的描述？比如人，一般的描述信息有姓名、性别、出生日期、身高、体重等。 -在当前问题域，对象还具备那些特定描述项？比如人作为门诊系统的患者，还需要考虑血型、药物过敏、家族病史等。 -对象的责任是什么？在系统中对象还需要了解或提供哪些信息？比如图书馆要实现催还功能，与该责任相关的就需要为书籍或借书事项定义借书日期和期限。 -对象可能处于什么状态？对象的状态不同，则可能执行的操作也不同。比如出租物品就有在库、出租、维修三个状态。

保持属性的简单性 1 仅定义与系统责任和系统目标有关的属性。 2 使用简单数据类型来定义属性。如数字、字符串、日期、布尔、文本等。还包含多种特征或规则的数据，可考虑作为独立的对象类。 3 一般不使用可导出的属性。 4 分析阶段不为对象关联而定义属性。在确立关联后，在设计阶段通过关联属性来实现。 -如借书记录不应有“借书卡号”或“馆藏流水号” -如毕业设计题目与教师和学生存在关联，但题目中不应定义“教师姓名”、“学号”之类的属性。

属性的表示 属性的有关说明： -属性的名称和解释：有些属性只适用于该问题域，是专业术语，晦涩难懂；有些常用词语在特定环境下字面的含义有所修改，为了提高清晰度，需要对这些属性进行定义。 -属性的数据类型：分析时使用简单类型，如整数、实数、字符串、日期、数组、布尔等，分析阶段因为不考虑技术实现，所以不需要考虑具体语言能支持的数据类型。 -其它要求：如取值范围、缺省值等。

图书馆系统的第2张类图

零散孤立的概念类构成不了系统的概貌。 组成系统的事物之间是相互制约相互依赖的，对象间有一定的关联结构。如同实体关系图（E-R图）就基本表达了这种关联。 UML对于对象关联关系有明确的定义和表示法。

关联表示不同类的对象之间的静态关系，它在一段时间内将多个类的实例连接在一起。可以使用关联表示对象了解其他对象的程度。 对象关联通常可以使用“has a”来进行验证。 描述关联的要素 1、关联名称 2、关联角色 3、多重性 4、导向性

1、关联名称 多数关联是二元的（即只存在于两个类的实例之间），在图中表示为连接两个类符号的实线路径。 使用关联名称，应该反映该关系的目的，并且应该是一个动词词组。 -读者和图书的关联是“借阅” -教师对象和课程对象的关联名称就是“讲授” -医生和处方单的关系是“开”。 关联名称应放置在关联路径上或其附近。

2、关联角色 关联所联系的每一端叫做一个角色 角色名称应该是一个名词，能够表达被关联对象在关联中所充当的角色，角色名称紧邻关联线的末端。

3、关联的多重性(Multiplicity) 定义了一个类A的实例在一段特定的时间内能够和多少个类B的实例发生关联。 类似于ER中的关联基数（一对一/一对多/多对多）

4、关联的导向性(Navigability) 角色的导向性特征表示可以通过关联从源类导向到目标类上。也就是说给定关联一端的对象就能够容易并直接地得到另一端的对象。 识别关联的导向可以推迟，与设计实现有关。通常是源对象存储了对目标对象的一些引用。 整体-部分关联 如果对象a是对象b的一个组成部分，则称b为a的整体对象，a为b的部分对象，二者对应的关联形式称为整体-部分关联（Whole-Part）。这种结构可以用a “is a part of” b进行验证。 整体-部分关联是关联中使用较频繁的一种模式，用于对模型元素之间的组装关系进行建模。整体-部分关系在现实生活中可以表现为以下几种形式： -客观上或逻辑上的整体事物和它的组成部分（机器和零件、人体和器官、书和章节、图和元素） -组织机构和它的下级组织及部分（公司和子公司、医院和科室） -团体（组织）和成员（科室和医生、班级和学生） -空间上的容器事物和其包容物（车间和机器/工人、教室和设备）

整体-部分关系建模的这种关联也称为聚集（aggregation），在UML类图中使用连接线和菱形表达，菱形一端的对象是整体对象。 整体-部分关联有两种类型： -组合聚集(composition aggregation ) -共享聚集 (shared aggregation)

1、组合聚集(composition aggregation ) 组合聚集具有很强的归属关系，在特定时刻部分只能是一个组合对象的成员。 整体端的重数不会超过 1（即它无法被多个整体对象共享）,关系建立后一般不可变更。 关联路径的末端有一个实心菱形，用来表示组合关系。

2、共享聚集(shared aggregation) 描述整体-部分的关系，部分可能同时属于多个整体对象。 关联路径的末端有一个空心菱形，用来表示聚集关系。 关联的类型 识别关联的原则 找出问题域中的对象远远比找出关联更为重要 注意力集中在那些需要将对象之间的关系信息记忆一段持续时间的关联 太多无效关联会使概念模型变得混乱 要避免关联之间的信息冗余以及减少派生关联 关联使用关联名称、角色、多重性和导向性来

图书馆系统的第3张类图

泛化（Generalization）是在多个概念之间识别共性，定义超类（一般概念）和子类（特定概念）关系的活动。 -如在图书馆系统中，发现图书馆目前还收藏了其它资源，比如影碟（VCD/DVD）、音乐CD、电子书等品种。它们和图书一样可以被任何读者借出，每个对象都有条码和状态。但它们也有自己的特性，比如属性项、借阅期限、逾期惩罚不同，必须区别对待。

1、一般-特殊结构(Generalization-Specialization) 如果类A具有类B的全部属性和行为，而且具有自己特有的某些属性或服务，则A叫做B的特殊类，B叫做A的一般类。这种关系也称为一般-特殊关系、泛化-特化关系、继承关系。 特点： -可以简化模型，有效地反映问题空间的分类层次。 -必须确认子类一定是父类的一个特殊类型，即可以用“is-a-kind-of”进行验证 -注意控制泛化的粒度，额外的泛化增加复杂性

图书馆系统的泛化关系 2、什么时候需要划分一般-特殊结构 1 类的属性或行为不适合该类的全部对象 -如果定义“学生”类有“导师”属性，有“教学实践”行为的话，则该类的对象对于本科生不适合，只适合于研究生对象，采用一般-特殊结构重新分类，建立“学生”和“研究生”之间的一般-特殊结构，研究生可以继承所有学生的特性。 2 属性和行为相似的类 -将这些类的共性抽象出来作为超类，各自特性仍旧保留而作为超类的子类。 3 不要将一个对象的状态变化设计为多个子类，除非对象的多数行为是由状态来决定

3、抽象类 如果一般类A的每个实例还必须是它的一个特殊类的成员，那么类A就被称为一个抽象类。 -比如“学生”、“研究生”中，“学生”不是一个抽象类 -比如“支付”、“现金支付”、“信用卡支付”中，“支付”就是一个抽象类 但面向对象的设计原则强调设计抽象类，比如学生，设计一个抽象学生类，然后派生出本科生和研究生 抽象类意味着不能创建该类的实例

4、多继承 继承有单继承和多继承。 多继承是指一个子类继承了两个父类的属性和行为。 例如MyTool继承铅笔和橡皮两种事物的特性： 5、接口 当多种不同类型的对象具有相似行为时，可以将他们的行为进行抽象，定义为接口。 接口只是某种行为的契约，接口不含有契约的具体实现机制，实现由类来完成。 例如： -业务系统中有些单据能撤销，有些不能，可以将撤销操作封装到一个接口中，所有支持撤销的单据类去实现该接口

图书馆系统的类图 空调维修系统的类图

酒店预定 某公司要开发一个酒店预定系统，该酒店可对外开放豪华双人间、双人间、三人间和单人间，房间价格视情况可以调整，但周一到周五半价、周末全价的折扣不变。 对于客户请求，该系统应能根据请求预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型、入住日期和天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。 预定入住日期前旅店允许旅客取消预定，距离入住12小时以上可退回所有定金，否则定金不退还。 每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定

绘制领域类图的注意事项 某个对象在整个系统中只有一个对象实例，暂不需要建模，例如空调维修系统无“新科中央空调服务公司”对象，毕业设计管理系统无“教务处”对象。 实体的属性应该是实体与生俱有的特性，而不是相关联的其他对象属性。比如“派工单”的属性不包括客户名称、客户地址等属性，“毕设课题”不包括教师姓名、职称等属性。 泛化关系在语义上能够使用“is a kind of”验证通过，例如“业务经理”是一种类型“员工”，绘制类图时尽量让一般类放在特殊类的上方。 类图中关联尽量不要出现回路，例如“服务合同”、“业务经理”、“派工单”的循环关联，这种冗余关联没有错误，但过多的话会造成模型难以阅读。 类图中的对象关联应使用存在量词验证通过，例如一个派工单使用“某些”材料或一种材料在“有些”派工单中使用、派工单“至少有一个”维修人员等。如果必须使用全称量词，则不推荐建立关联关系，例如业务经理负责“所有”服务合同、每个图书管理员可以管理“每一本”图书。

对象图的使用 类图结构太抽象而难以理解时，可以用对象图补充说明。 UML对象图（object diagram）是在某个时刻系统中各个对象的一个快照，对象图的成分是类的实例而不是类，有时也称实例图。 案例分析 在火车票订购管理系统中，按照软件的设计流程，第一个需要完成的功能是学生在网上完成票的预订操作，学生在操作此功能时需要满足如下的功能要求： 记录火车票预订信息：预订编号、列车车次、起始站、终点站、预订时间、预定人、联系电话等。 记录火车票的费用信息：预订编号、火车票价、预付金额 记录火车票的状态：预订编号、状态（默认为“1：预订状态”）。 根据以上要求，我们可以确定系统中包含的对象： 要记录火车票的预定信息，肯定需要火车票的对象：BookTicketInfo。 预定火车票的对象是学生，所以需要学生的对象：Student 学生订票时需要记录费用信息，所以需要订票费用支付情况对象：BookTicketPay。 火车票从预订到领取会经历多种状态，为方便以后功能的扩展，所以将火车票的状态单独立出来，即BookTicketState。 对象图：

系统模型包括静态模型和动态模型。 静态模型反映系统的结构，动态模型反映系统如何运作（信息的处理过程）。 动态模型： -状态图：对象状态及变化 -交互图：不同对象之间的交互协作，如顺序图、通信图

对象状态建模的意义 研究对象状态变化与动态行为之间的关系 -不仅能描述一个对象的所有可能状态 -还能显示该对象在某个状态下基于特定事件作出响应的动态行为。 状态模型还可以与流程模型、用例模型进行相互补充和参照。 -不同模型的特点和描述能力不同，多种模型在一起才能获得更详尽具体的系统全貌。 -不同模型还可以进行对照检查，查漏补缺，发现问题。比如检查对象状态变换过程是否与流程模型的控制逻辑一致，检查用例模型定义的功能需求是否能覆盖对象全周期内的各种状态变化。

状态图 在UML2.0命名为状态机图（state machine diagram），它是表述系统行为的一种技术，在面向对象方法中，对单一的类绘制一个状态机图以表示该对象的生命期行为和状态转换。 对象可能存在的状态： 初态：是状态图的起始点，表示对象的初始状态，初态只有一个，用实心圆表示。 终态：是状态图的终点，表示一个对象完成必要操作后的最终状态，终态不能是复合状态。实心圆外加一个圆圈来表示终态。 复合状态：一种状态中还嵌套有其它多个状态（子状态）。

状态图的元素 -状态 -转换（transition）：指出由一种状态到另一种状态的运动。每个转换上有可选标记，标记含有三部分内容事件： 事件[监护条件]/活动（event[guard]/activity） 只有发生指定的事件后才有可能引发状态的改变 需要监护条件为真时转换才会生效 活动是在转换执行中的行为 -内部活动：对象在某个状态内部执行的操作

当事件 turn on发生时，只有水壶内有水（have water）才能由off状态转换到on状态，并发生烧水的动作（Boiling Water），其实动作也可以放在on状态中。

状态图举例