目录
(5) 为需求建立模型：最难的一项任务！！！SA and OOA
11.4.2 数据流图DFD => 功能图、算法处理图 =》 类似OOA活动图
需求获取=>业务需求=》用户需求：目的是获取客户的真实需求，而不是分析客户的需求，因此，需求获取不会对客户的需求进行主观或客观的评判，收集原始的需求是主要的目标！！！因此，以用户故事、业务场景、用例图等输出为主！！！需求获取是完全站在客户的角度，定义用户的需求！！！把目标系统完成看成一个黑盒子，站在黑盒外部，对信息系统提出需求。
需求分析=》功能需求、非功能需求：就是把客户的需求变成软件产品的需求！！！！得到软件或产品的需求规格说明书！！！是站在产品经理和系统工程师的角度，对软件系统提出的需求！！！
需求分析重要的作用是“分析”，需要发挥分析师的主观能动性，对用户的需求进行分析，挖掘用户需求背后的主观需求，然后转换成产品或软件的需求！！！
从工作任务上来说,分析要完成的任务是将用户需求转化为软件开发人员更为熟悉和理解的软件需求,而设计要完成的任务则是如何将软件需求给实现。
从抽象层次上来说,分析处于较高的抽象层次,它是将需求从现实世界映射到对象世界,不依赖于任何实现语言和实现方式; 设计则处于较低的抽象层次,它是在分析的基础之上,并且考虑现实的设计约束——使用规定的语言和实现方式如何实现。因此，有时候，分析也称为高层设计、概要设计，设计称为低层设计、详细设计，与具体的编程语言相关。
在需求获取阶段，系统分析师所获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地方，也有矛盾的地方，这样的要求是不能作为软件设计的基础的。
一个好的需求应该具有无二义性、完整性、一致性、吋测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要系统分析师把杂乱无章的用户要求和期望转化为产品需求，这就是需求分析的工作。
需求分析就是提炼、分析和仔细审查己经获取到的需求，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。
需求分析的关键在于对问题域的研究与理解。为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。
Karl E . Wiegers 在 《软件需求》一书中指出，需求分析的工作通常包括以下7 个方面：
这种关系图是用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围。
这是描述系统最高层结构的DFD图，它的特点是，将整个待开发的系统表示为一个过程，将所有的外部实体和进出系统的数据流都画在一张图中。
用户界面对于一个系统来说是十分重要的，因此在需求分析阶段通过快速开发工具开发一个抛弃式原型，或者通过 PowerPoint 、 H a s h 等演示工具制作•-个演示原型，甚至是用纸和笔画出一些关键的界面接口示意图，将帮助用户更好地理解所要解决的问题，更好地理解系统。
对所有获得的需求进行成本、性能和技术实现方面的可行性研究，以及这些需求项是否与其他的需求项有冲突，是否有对外的依赖关系等。
这是一项很重要的工作，迭代幵发已经成为了现代软件工程方法的一个基础，而需求的优先级是制订迭代计划的一个最重要的依据。对于需求优先级的描述，可以采用满意度和不满意度指标进行说明。其中满意度表示当需求被实现时用户的满意程度，不满意度表示当需求未被实现时用户的不满意程度。
也就是建立分析模型，这些模型的表现形式主要是图表加上少量的文字描述，所 谓 “一图抵千字”，图形化地描述需求将使得其更加清晰、易懂。根据采用的分析方法不同，采用的图也将不同。例如， O O A 中的用例模型和领域模型 ，S A中的 D F D 和 E - R 图等。
需求分析模型主要描述系统的数据、功能、用户界面和运行的外部行为，它是系统的一种逻辑表示技术，并不涉及软件的具体实现细节。需求分析模型可以帮助系统分析师理解系统，使需求分析任务更加容易实现。同时，它也是以后进行软件设汁的基础，为软件设计提供了系统的表示视图。
数据字典是对系统用到的所有数据项和结构进行定义，以确保开发人员使用了统一的数据定义。有关数据字典的详细知识，将 在 11.4.3节中介绍。
这是在需求优先级某础上的一个升华，其原理与满意度和不满意度指标十分接近，通过将产品特性、属性与对用户的重要性联系起来。
QFD法是一种系统性的决策技术，在设计阶段，它可保证将顾客的要求准确无误地转换成产品定义；在生产准备阶段，它可以保证将反映顾客要求的产品定义准确无误地转换为产品制造工艺过程；在生产加工阶段，它可以保证制造出的产品完全满足顾客的需求。
在软件丄程实践过程中，人们提出了许多种需求分析的方法，其中主要有：
（1）S A 方法：
关注于功能的分层和分解，这非常符合人们自上而下、逐步分解问题直到可解决的自然思考方式。
S A 方法本身隐含着几个基本假设：即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。
S A 方法应用的是科学方法中的因果律、归纳法和逻辑法，通过对现实世界中的问题域进行不断的“测量”和 “分解”，宜到得到问题域的逻辑模型。
（2）0 0 A 方法：
则遵循完全不同的思维方式，它基于抽象、信息隐藏、功能独立和模块化。这些基本理念对系统进行分析。
0 0 A 方法首先对问题域的事物的“外在表象”进行观测，然后在逻辑世界中模拟出一个对应的逻辑对象，“断定”该对象和现实事物是一致的。
随后，观测到的对象被记录入对象集合，观测到的行为和表象被记录入对象关系模型和对象行为模盥。0 0 A 方法建立的对象彼此之间通过接口来相互沟通，每传递一个消息即触发一个事件，并引起内部方法的执行。只有观测对象内部的时候，才能看到具体的私有属性和方法。否则，只能看到对象对外部幵放的接口。
（3）比较
S A 方法假定系统分析师理解问题域的全部，并且有能力正确地识别和分解问题，SA方法是一次性把系统的功能分解到位。
而 O O A 方法既不假定系统分析师理解问题域的全部，也不假定其能够建立正确的抽象对象，它只承诺一种可以持续“观测并理解”的方法，以及“观测后建立”的对象和现实世界的外在表象是一致的。
很难对 S A 方法和0 0 久方法作-•种优劣性的比较，使用两种方法成功和失败的软件
系统都很多。
0 0 A 方法已经成为当前的主流分析方法，拥有大量的语言和建模工具的支持。
然而， S A 方法也并未过时，很多成功的软件系统依然在通过 S A 方法进行分析和
实现。
S A 方 法采用功能分解的方式来描述系统功能 ， 在这种表达方式 中 ，系统功能被分解到各个功 能模块中 ,通过描述细分的系统模块的功能来达到描述整个系统功能的目的 。
SA方法有两个明显的缺点：
（1）采用S A 方法来 描述系统需求 ，很容易混淆需求和设计的界限 ，
这样的描述实际上已经包含了部分的设计在内。因此，系统分析师常常感到迷惑，不知道系统需求应该详细到何种程度。一个极端的做法就是将需求详细到概要设计(即需求+概要设计)，因为这样的需求描述既包含了 外部需求（需求）也包含了内部设计（设计）。
（2）S A 方法的另一个缺点是分割了各项系统功能的应用环境,
从各项功能项入手,很难了解到这些功能项如何相互关联来实现一个完整的系统服务的。
从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。
用例方法是一种需求合成技术，采用 10.2.3节 和 11.2节介绍的技术（方法）获取需求，记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。
在 O O A 方法中，构建用例模型一•般需要 经历4 个阶段，分别是：
其中前三个阶段是必需的。
结构化方法首先关心的是功能Function，强调以模块（即过程、函数Function）为中心，采用模块化、自顶向下、逐步求精设计过程，系统是实现模块功能的函数和过程的集合，结构清晰、可读性好，的确是提高软件开发质量的一种有效手段。每个模块有可能保持较强的独立性，但它往往与数据库结构相独立，功能模块与数据库逻辑模式间没有映射关系，程序与数据结构很难封装在一起。如果问题世界的功能比数据更复杂或者更重要，那么结构化方法仍应是首选的方法。
如果数据结构复杂，模块独立性很难保证。面向对象方法抽象的系统结构往往并不比结构化方法产生的系统结构简单，但它能映射到数据库结构中，很容易实现程序与数据结构的封装。结构化设计从系统的功能入手，按照工程标准和严格规范将系统分解为若干功能模块。然而，由于用户的需求和软、硬件技术的不断发展变化，作为系统基本成分的功能模块很容易受到影响，局部修改甚至会引起系统的根本性变化。开发过程前期入手快而后期频繁改动的现象比较常见。
面向对象方法则从所处理的数据入手，以数据为中心来描述系统，数据相对于功能而言，具有更强的稳定性，这样设计出的系统模型往往能较好地映射问题域模型。对象、类、继承性、多态性、动态定连概念和设施的引入使用，显然令面向对象的设计方法具有一定的优势，能为生产可重用的软件构件和解决软件的复杂性问题提供一条有效的途径。
面向对象的设计过程就是指通过建立一些类以及它们之间的关系来解决实际问题，这就需要对问题域中的对象作整体分析，类及类间关系的设计要求较高，否则设计出的并不是真正意义上的面向对象的软件系统，而只是一些类的堆砌而已，不能体现出面向对象设计方法的优势之处。
面向对象方法的优点并不是减少开发时间，初次使用这种技术软件，可能比结构化方法开发时间更长，开发人员必须花很大精力去分析对象是什么，每个对象应该承担什么责任，所有这些对象怎样很好地合作以完成预定的目标。这样做换来的好处是，提高了目标系统的可重用性，减少了生命周期后续阶段的工作量和可能犯的错误，提高了软件的可维护性。
S A 方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的，于是复杂的问题也就迎刃而解了。SA方法是一次性复杂系统分解到可控的程度。
在 S A 方法中导出的分析模型如阁11-5所示。
从 图 11-5可以看出， S A 方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。
在实际工作中，一般使用:
这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。
E - R 模型也称为 E - R 图，它是描述概念世界，建立概念模型的实用工具。
在 E - R 图中，主要包括以下三个要素：
(1) 实 体 （型)。实体用矩形框表示，框内标注实体名称。
(2) 属性。
单值属性用椭圆形表示，并用连线与实体连接起来。如果是多值属性，
在椭圆形虚线外面再套实线椭圆；如果是派生属性，则用虚线椭圆表示。其中，多值属
性可以有一个或者两个以上的值，例如，学员信息数据库中可能包含关于他们个人兴趣
的数据，一个学员可能有运动、电影、投资和烹调等多个兴趣；派生属性是从基本属性
计算出来的属性，例如，学员的总成绩和平均成绩等。
(3) 实体之间的联系。
实体之间的联系用菱形框表示，框内标注联系名称，并用连线将菱形框分别与有关实体相连，并在连线上注明联系类型。例如，图 5 4 就是某在线教育平台系统的一个 E - R 图 （为了简单起见，省略了部分实体的属性和联系的属性）。
D F D 是 S A 方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能（即功能需，而不是用户需求，也不是业务需求）的一种方法。 D F D 还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将 D F D 作为需求规格说明书的一个组成部分。
D F D 从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说， D F D 的主要作用如下：
( 1 ) D F D 是理解和表达用户需求的工具，是需求分析的手段。
由于 D F D 简明易懂，>(<需要任何计算机专业知识就可以理解它，因此，系统分析师 p J ■以通过 D F D 与用户进行交流。
(2) D F D 概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
(3) D F D 作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
备注：
虽然是系统内部的功能，但这里并非定义这些功能的实现方法，而是功能需求！！！可以通过任何编程语言实现这些功能，也可以通过硬件的手段实现这些功能。这就是功能需求，而不是功能设计的原因。
需求和设计的区别：功能需求是业务逻辑所决定的，是由客户所决定的，设计是有实现业务逻辑的软件人员所决定的。
在 D F D 中，.通常会出现4‘种基本符号，分别是数据流、加工、数据存储和外部实体 （数据源及数据终点）。数据流是具有名字和流向的数据，在 D F D 中用标有名字的箭头表示。加 T 是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表不。
S A 方法的思路是依赖于 D F D 进行自顶而下的分析。这也是因为系统通常比较复杂，很难在- 张图上就将所有的数据流和加工描述清楚。因此， D F D 提供一种表现系统高层和低层概念的机制。也就是先绘制一张较髙层次的 D F D , 然后在此基础上，对其中的加工进行分解，分解成为若干个独立的、低层次的、详细的 D F D , 而且可以这样逐一的分解下去，直至系统被淸晰地描述出来。
(1)顶层图。
顶层图是描述系统最高层结构的 D F D , 它的特点是将整个待开发的系统表示为一个加工，将所有的外部实体和进出系统的数据流都画在一张图屮。例如，图11-6就是一个顶层图的实例，只不过在绘制时做了一些处理，使得它看上去更加直观易懂。
顶层图用来描述系统有什么输入和输出数据流，与哪些外部实体直接相关，可以把
整个系统的范围勾画出来。
(2)逐层分解。
当完成了顶层图的建模之后，就可以在此基础上进行进一步的分解。对 图 11-6进行分解，在对原有流程了解的基础上，可以得到图11-7。
图 11-7是在顶层图11-6的基础上做的第一次分解，而在图】1-7中只有一个加工，
那就是系统本身，可以将其编号为0。因此，对顶层图进行的分解，其实就是对这个编
号为0 的加工进行更细化的描述，在这里引入了新的加工和数据存储，为了能够区分其
位于的级别，在这个层次上的加工将以1, 2, 3 为序列进行编号。
正是由于这是对加工0 的分解，因此也称为0 层图。可以根据谣要对0 层图上的加
工进行类似的再分解，称之为1层图，在 1层图中引入的新加工，其编号规则就是1.1、
1.2、…，以及2.1、2.2、…，依次类推，直到完成分析工作。
大多数业务系统是数据驱动的，所以适合使用 D F D 。但是，实时控制系统却主要是
事件驱动的，因此，行为模型是最有效的描述方式。 S T D 通过描述系统的状态和引起系
统状态转换的事件，来表示系统的行为。此外， S T D 还指出了作为特定事件的结果将执
行哪些动作（例如，处理数据等）。
状态是任何可以被观察到的系统行为模式，每个状态代表系统的-•种行为模式。在S T D 中，用圆形框或椭圆框表示状态，通常在框内标上状态名。状态规定了系统对事件的响应方式。系统对事件的响应可以是做一个（或一系列）动作，也可以是仅仅改变系统本身的状态。 S T D 描述了系统如何在各种状态之间移动。
事件是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。例如，内部时钟指明某个规定的时间段己经过去，鼠标移动或单击等都是事件。简而言之，事件就是引起系统状态转换的控制信息。
在 S T D 中，从一个状态到另一个状态的转换用箭头线表示，箭头表明转换方向，箭
头线上标上事件名。必要时可在事件名后面加一个方括号，括号内写上状态转换的条件。
也就是说，仅当方括号内所列出的条件为真时，该事件的发生才引起箭头所示的状态转
换。图 11-8给出了一个在线课程学习的 S T D 示例。
S T D 既可以表示循环运行过程，也可以表示单程生命期。当描述循环运行过程时，
通常不关心循环是怎样启动的。当描述单程生命期时，需要标明初始状态（简称为“初
态”，系统启动时进入初始状态）和最终状态（简称为“终态”，系统运行结束时到达最
终状态）。在 S T D 中，初始状态用实心圆表示，最终状态用一对同心圆（内岡为实心圆)
表 。
D F D 描述了系统的分解，即系统由哪几部分组成，各部分之间的联系等，但是，对
于数据的详细内容却无法在 D F D 中得到反映。例如，图 11-7中的数据存储“课程”包
括哪些内容，在 D F D 中就无法具体、准确地描述。数据字典是在 D F D 的基础上，对 D F D
中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。
D F D 和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完
整的描述。
数据字典中一般有6 类条目，分别是数据元素、数据结构、数据流、数据存储、力口
工逻辑和外部实休。不同类型的条目有不同的属性需要描述。
(1)数据元素。
数据元素也称为数据项，是数据的最小组成单位，例如，课程号、
课程名等。对数据元素的描述，应该包括数据元素的名称、编号、别名、类型、长度、
取值范围和取值的含义等。此外，数据元素的条 H 还包括对该元素的简要说明，以及与
它有关的数据结构等信息。 .
(2) 数据结构。
数据结构用于描述某些数据元素之间的关系，它是一个递归的概念，
一个数据结构可以包括若干个数据元素或（和）数据结构。数据结构的描述重点是数据
元素之间的组合关系，即说明数据结构包括哪些成分。这些成分中有三种特殊情况，分
别是任选项、必选项和重复项。任选项是可以出现也可以省略的项，用 “[]”表示；必
选项是在两个或多个数据元素中，必须出现其中的一个。例如，任何一门课程是必修课
或选修课，二者必居其一。必选项的表示是将候选的多个数据项用“（}”括起来；重复
项是可以多次出现的数据项。例如，一张学员注册表可选择多门课程，“课程细节”可重
复多次，表示成“课程细节*”。
( 3 ) 数据流。
数据流由一个或一组数据元素组成，对数据流的描述应包括数据流的
名称、编号、简要说明、来源、去处、组成和流通 M (含高峰时期的流通量）。 •
( 4 ) 数据存储。
数据存储的条目主要描写该数据存储的结构，以及有关的数据流和
査询要求。有些数据存储的结构吋能很复杂，例如，图 1 1 -7 中的“学员”包括学员的基
本情况、学员动态、在线模拟测试记录、论文练>】成绩等，其中每一项又是一个数据结
构，这些数据结构有各自的条目分别加以说明。因此，在 “学员”的条目中只需列出这
些数据结构，而不要列出数据结构的内部构成。 D F D 是分层的，下层图是上层图的具体
化。同一个数据存储可能在不同层次的图中出现。描述这样的数据存储，应列出最底层
图中的数据流。
( 5 ) 加工逻辑。
需要描述加工的编号、名称、功能的简要说明、有关的输入数据流
和输出数据流。对加工进行描述，目的在于使相关人员能有一个较明确的概念，了解加
工的主要功能。详细的加工逻辑则需要借助一些工具来描述，包括判定树、判定表和结
构化语言等，有关这些工具的洋细知识，将 在 13.2.3 节中介绍。
(6) 外部实体。
外部实体是数据的来源和去向，对外部实体的描述应包括外部实体
的名称、编号、简要说明、外部实体产生的数据流和系统传给该外部实体的数据流，以
及该外部实体的数量。外部实体的数量对于估计系统的业务量有参考作用，尤其是关系
密切的主要外部实体。
数据字典实际上是“关于系统数据的数据库”。在整个系统开发过程和系统运行与
维护阶段，数据字典是必不可少的工具。数据字典是所有人员工作的依据，统一的标准。
它可以确保数据在系统中的完整性和一致性。具体来讲，数据字典具有以下作用：
(1)按各种要求列表。
可以根据数据字典，把所有数据条目按一定的顺序全部列出，保证系统设计时不会遗漏。如果系统分析师要对某个数据存储的结构进行深入分析，需要了解有关的细节，了解数据结构的组成乃至每个数据元素的属性，数据字典也可提供相应的内容。
(2) 相互参照，便于系统修改。
根据初步的 D F D , 建立相应的数据字典。在需求分析过程中，系统分析师常会发现原来的 D F D 及各种数据定义中有错误或遗漏，需要修改或补充。有了数据字典，这种修改就变得容易多了。
( 3 ) 由描述内容检索名称。
在一个稍微复杂的系统中 ， 系统分析师可能没有把握断定某个数据元素在数据字典中是否已经定义，或者记不淸楚其确切名字时，可以由内容查找其名称。
(4) 一致性检验和完整性检验。
根据各类条目的规定格式，可以发现一些问题，例如，是否存在没有指明来源或去向的数据流，是否存在没有指明数据存储或所属数据流的数据元素，加工逻辑与输入的数据元素是否匹配，是否存在没有输入或输出的数据存储等。
为了保证数据的一致性，数据字典必须由专人（数据管理员）管理。数据管理员的职责就是维护和管理数据字典，保证数据字典内容的完整性和一致性。任何人，包括系统分析师、软件设计师、程序员，如果要修改数据字典的内容，都必须通过数据管理员。数据管理员还要负责把数据字典的最新版本及时通知有关人员。
0 0 A 的基本任务是运用 O O 方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的 O O A 模型及其详细说明。0 0 A 模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是0 0 A 和
0 0 D 的区别之所在。 O O A 的任务是“做什么”，0 0 D 的任务是“怎么做”。
U M L 是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持 O O A 和 O O D , 还支持从需求分析开始的软件开发的全过程。//不仅仅用于需求分析！！！
从总体上来看， U M L 的结构包括构造块、规则和公共机制三个部分。
(1) 构造块。
U M L 有三种基本的构造块，分别是事物（ thing )、关 系 （ relationship )和 图 （ diagram )。事物是 U M L 的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
(2) 公共机制。
公共机制是指达到特定 H 标的公共 U M L 方法，主要包括规格说明(详细说明）、修饰、公共分类（通用划分）和扩展机制4 种。规格说明是事物语义的细节描述，它是模型真正的核心： U M L 为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息； U M L 包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约 束 （扩展了 U M L 构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展 U M L 的词汇，用于定义新的构造块）和标记值（扩展了 U M L 构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。
(3) 规则。
规则是构造块如何放在一•起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。
U M L 对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们
的关联性、交互机制和指导原则等提供系统设计的信息。
具体来说，全过程视图就是指以下5 个系统视图：
备注：下述视图并非都用于需求，而是用于软件分析与设计。
(1) 逻辑视图。
逻辑视图也称为设汁视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
(2) 进程视图。
进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
( 3 ) 实现视图。
实现视图对组成基于系统的物理代码的文件和构件进行建模。
(4) 部署视阁。
部署视阁把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
(5) 用例视图 =》 需求分析
用例视阁是最基本的需求分析模型。
另外， U M L 还允许在一定的阶段隐藏模型的某些元素、遗漏某些元素，以及不保
证模型的完整性，但模型逐步地要达到完整和一致。
U M L 中的事物也称为建模元素，包括结构事物 （Structural Things )、行为事物
(Behavioral Things ，动作事物）、分组事物 （Grouping Things ) 和注释事物 （Annotational
Things , 注解事物）。这些事物是 U M L 模型中最基木的0 0 构造块。
(1)结构事物。
结构事物在模型中 M 于最静态的部分，代表概念上或物理上的元素。
U M L 有 7 种结构事物，分别是类、接口、协作、用例、活动类、构件和节点。类是描述
具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接 D ; 接口是
指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作;
协作定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些
动作比事物的总和要大；用例是描述一系列的动作，产生有价值的结果。在模型中用例
通常用来组织行为事物。用例是通过协作来实现的；活动类的对象有一个或多个进程或
线程。活动类和类很相似，只是它的对象代表的事物的行为和其他事物是 N 时存在的；
构件是物理上或可替换的系统部分，它实现了一个接口集合；节点是一个物理元素，它
在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。•一个构件
集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
(2) 行为事物：
行为事物是 U M L 模型中的动态部分，代表时间和空间上的动作。
U M L 有两种主要的行为事物。第一种是交互（内部活动），交互是由一组对象之间在特
定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作
的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作）、连 接 （对象
之间的连接）；第二种是状态机，状态机由一系列对象的状态组成。 '
(3) 分组事物。
分组事物是 U M L 模型中组织的部分，可以把它们看成是个盒子，
模型可以在其中进行分解。 U M L 只有一种分组事物，称为包。包是一种将有组织的元素
分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于幵发阶段，而构
件可以存在于系统运行阶段。
(4) 注释事物。
注释事物是 U M L 模型的解释部分。
U M L 用关系把事物结合在一起，主要有下列4 种关系：
(1) 依 赖 （ dependency )。
依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
( 2 ) 关 联 （ association )。
关联描述一组对象之间连接的结构关系。一个事物的变化并不影响另一个事物。指针关系！
(3) 泛 化 （ generalization )。
泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
( 4 ) 实 现 （ realization )。
实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
U M L 2.0包 括 14种图，分别列举如下：
(1) 类 图 （Class Diagram )。-- 高层设计
类图描述一•组类、接口、协作和它们之间的关系。在0 0 系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
(2) 对 象 图 （Object Diagram )。-- 高层设计
对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
( 3 ) 构 件 图 （ Component Diagram ) 。 -- 高层设计
构 件 图 描 述 一 个 封 装 的 类 和 它 的 接 口 、 端 口 ，以 及 由 内 嵌 的 构 件 和 连 接 件 构 成 的 内 部 结 构 。构 件 阁 用 于 表 示 系 统 的 静 态 设 计 实 现 视 图 。
对 于 由 小 的 部 件 构 建 大 的 系 统 来 说 ， 构 件 图 是 很 重 要 的 。 构 件 图 是 类 图 的 变 体 。
(4) 组合结构图 （Composite Structure Diagram )。
组合结构图描述结构化类（例如，构 件 或 类 ） 的 内 部 结 构 ， 包 括 结 构 化 类 与 系 统 其 余 部 分 的 交 互 点 。 组 合 结 构 图 用 于 画 出
结 构 化 类 的 内 部 内容。
(5) 用例图 （Use Case Diagram )。 -- -- 业务需求 + 产品需求
用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
( 6 ) 顺 序 图 （ Sequence Diagram ， 序 列 图 ）。 -- 产品需求 + 高层设计
顺 序 图 是 一 种 交 互 图 （ interaction diagram ) ，交 互 图 展 现 了 一 种 交 互 ， 它 由 一 组 对 象 或 参 与 者 以 及 它 们 之 间 可 能 发 送 的 消 息 构 成 。 交互 图 专 注 于 系 统 的 动 态 视 图 。 顺 序 图 是 强 调 消 息 的 时 间 次 序 的 交 互 图 。
(7) 通 信 图 （Communication Diagram )。
通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。在 U M L I. X 版本中，通信图称为协作图 （ Collaboration D iagram )。
( 8 ) 定 时 图 （ TimingDiagram , 计 时 图 ）。
定 时 图 也 是 一 种 交 互 图 ， 它 强 调 消 息 跨 越不 同 对 象 或 参 与 者 的 实 际 时 间 ， 而 不 仅 仅 只 是 关 心 消 息 的 相 对 顺 序 。
( 9 ) 状 态 图 （ State Diagram ) 。-- 产品需求 + 高层设计 + 详细设计
状 态 图 描 述 一 个 状 态 机 ， 它 由 状 态 、 转 移 、 事 件 和 活动 组 成 。 状 态 图 给 出 了 对 象 的 动 态 视 图 。 它 对 于 接 口 、 类 或 协 作 的 行 为 建 模 尤 为 重 要 ，
而 且 它 强 调 事 件 导 致 的 对 象 行 为 ， 这 非 常 有 助 于 对 反 应 式 系 统 建 模 。
( 1 0 ) 活 动 图 （ Activity Diagram ) 。
活 动 图 将 进 程 或 其 他 计 算 结 构 展 示 为 计 算 内 部 一步 步 的 控 制 流 和 数 据 流 。 活 动 图 专 注 于 系 统 的 动 态 视 图 。 它 对 系 统 的 功 能 建 模 和 业 务 流程 建 模 特 别 電 要 ， 并 强 调 对 象 间 的 控 制 流 程 。
( 1 1 ) 部 署 图 （ Deployment Diagram ) 。
部 署 图 描 述 对 运 行 时 的 处 理 节 点 及 在 其 中 生存 的 构 件 的 配 置 。 部 署 图 给 出 了 架 构 的 静 态 部 署 视 图 ， 通 常 — 个 节 点 包 含 一 个 或 多 个 部署 图 。
( 1 2 ) 制 品 图 （ Artifact Diagram ) 。 制 品 图 描 述 计 算 机 屮 一 个 系 统 的 物 理 结 构 。 制 品包 括 文 件 、 数 据 库 和 类 似 的 物 理 比 特 集 合 。 制 品 图 通 常 与 部 署 图 一 起 使 用 。 制 品 也 给 出了 它 们 实 现 的 类 和 构 件 。
(13) 包 图 （ PackageDiagram )。
包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
(14) 交互概览图 （ Interaction O verview D iagram )。
交互概览图是活动图和顺序图的混合物 。
从系统外部的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。
用例方法是一种需求合成技术（把各种零散的用户功能需求合成在一个用例中），采用10.2.3节 和 11.2节介绍的技术（方法）获取用户需求，记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。每个用例可能包含了多个零散的外部用户需求和跨越内部多个功能实体。
在 O O A 方法中，构建用例模型一•般需要经历4 个阶段，分别是：
识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。
用例图是描述系统需求的方法，所谓系统需求，即是站在系统外部，对系统提出的需求。
因此，用例图并非是描述系统内部需求的方法，如果需要描述系统内部的需求，需要把系统拆分成更小的模块和单元，然后对每个单元进行系统需求分析。
参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。
备注：系统参与这，就如同项目管理中的项目外部的干系人，项目的目标就是满足不同项目干系人的诉求，软件系统，也是同样的道理，满足不同外部系统交互、通信的诉求。
(1) 其他系统：
当系统需要与其他系统交互时，其他系统就是一个参与者。例如，
对某企业的在线教育平台系统而言，该企、丨 k 的 O A 系统就是一个参与者。
(2) 硬件设备：
如果系统需要与硬件设备交互，硬件设备就是一个参与者。例如，在幵发集成电路（ IntegratedCircuit ，1 C ) 卡门禁系统时，1 C 卡读写器就是一个参与者。
(3) 时钟：
当系统需要定时触发时，时钟就是一个参与者。例如，开发在线测试系统中的“定时交卷”功能时，就需要引入时钟作为参与者。
要注意的是，参与者一定在系统之外，不是系统的•-部分。可以通过下列问题来帮助系统分析师发现系统的参与者：谁使用这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁关闭这个系统？哪 些 （其他的）系统使用这个系统？谁从这个系统获取信息？谁为这个系统提供信息？是否有事情自动在预汁的时间发生？
执行系统某项功能的参与者可能有多个，但这多个参与者在使用系统时会有不同的职责划分，根据职责的重要程度不同，有主要参与者和次要参与者之分。
主要参与者是从系统中直接获得可度量价值的参与者，次要参与者的需求驱动了用例所表示的行为或功能，在用例中起支持作用，帮助主要参与者完成他们的工作，次要参与者不能脱离主要参与者而存在。开发用例的重点是要找到主要参与者。
在确定用例的过程中，需要注意以下问题：
(1) 用例命名。
用例的命名应该注意采用“动 词 （短语）+ 名 词 （短语）”的形式，例如，“开通课程”和 “课程测试”等。而且，最好能够对用例进行编号，这也是实现需求跟踪管理的重要技巧，通过编号可以将用户的需求落实到特定的用例中 。
(2) 不能混淆用例和用例所包含的步骤。*****
例如，“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是是用例的子功能。
(3) 注意区分业务用例和目标系统用例。
当针对整个业务领域建模时，需要使用业务用例，其中会涉及大景的人工活动，例如，在线教育平台系统中有一项重要丁.作是“编写教材”，这就是业务用例，是信息系统无法完成的。
信息系统作为整个业务系统的一部分，只负责实现系统的部分功能， 因此，只需要识别出系统用例，而不需考虑业务用例。
用例建模的主要工作是书写用例规约 （use case specification )，而不是画图。
用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括：
一个用例，就是一个业务包含一个或多个业务场景。
一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构，这时吋以对用例进行分组。U M L 使用用例主题划分用例图 ，一 组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。用例的描述可以迭代完成，先对一些重要的用例编制相对细致的用例描述，对于•一
些不重要的用例，可以留待以后再补充完成。用例描述通常包括以下几个部分：
(1) 用例名称。
用例名称应该与用例图相符，并写上其相应的编号。
(2) 简要说明。
对用例为参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言。
(3) 事件流。
事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动，也就是用例所完成的工作步骤。
在编写时应注意使用简单的语法，主语明确，语义易丁•理解；
明确写出“谁控制谁“，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；
从俯视的角度来编写，指出参与者的动作，以及系统的响应；
描述用户意图和系统职责，而不叙述具体的行为和技术细节，特别是有关用户界面的细节。
执行一个用例的事件流有多种可能的路线，其中主事件流（基本事件流）是指能够满足目标的典型的成功路径，主事件流通常不包括任何条件和分支，符合大多数人的期望，从而更容易理解和扩展；
备选事件流（扩展事件流）也称为备选路径，是完成用例可能出现失败的情况、分支路径或扩展路径，为了不影响用例活动淸晰的主线，将这些分支处理全部抽取出来作为备选事件流。例如，在 “开通课程”用例执行的过程中，如果学员所交的费用多于所选修课程规定的费用，则需要把多余的费用转换为学习币：如果学员选修课程数量超出最人限额，则用例未达到期望目标而终止。
在事件流的描述中，主事件流使用“确认”和 “验证”等确定性语句，而不是“检查是否……”和 “如果……，那么……，杏则……”等条件语句，这些分支情况利用备选事件流来说明。
另外，事件流的编写过程也是可以分阶段迭代进行的，对于优先级高的用例花更多的时间，更加的细化：对优先级低的用例可以先简略地将主事件流描述清楚，备选事件流留待以后处理。
对于一些事件流较为复杂的，可以在用例描述中引用顺序图、状态图和通信图等手段进行描述。
(4) 非功能需求。
因为用例所涉及的非功能需求通常很难在事件流中进行表达，因此单列为一小节进行描述。
在非功能需求的描述方面 ， 一定要注意使其可度量和可验证。否则，就容易流于形式，形同摆设。
(5) 前置条件和后置条件。
前置条件是执行用例之前必须存在的系统状态，如果前置条件不满足，则用例无法启动。例如，“开通课程”用例的前置条件是客服人员己正确登录到系统中；
后置条件是用例执行完毕系统可能处于的一组状态。一旦用例成功执行 ,可能会导致系统内部某些状态的变化，例如，成功地“开通课程”会使该课程的选修人数增加 ， 会使学员的权限发生变化等。而某些用例也可能没有前置条件或后置条件，例如 ， “学员联络”用例没有后置条件，因为该用例执行后不会改变系统状态。如果在当前阶段不容易确定前置条件或后置条件，则可以在以后再细化。
(6) 扩展点。
如果包括扩展（或包含）用例，则写出扩展（或包含）用例名，并说明在什么情况下使用。
(7) 优先级。
说明用户对该用例的期望值，为以后的幵发工作确定先后顺序。可以采用满意度/不满意度指标进行说明，例如 ， 设置为1〜 5 的数值。表 114是图11-10中 “开通课程”的用例描述，这些内容不一定要一次完成。如果需要调整用例模型，则在调整用例模型之后，还可以修改和细化用例描述。
在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。
用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便
于复用，使得用例模型更易于维护。
(1) 包含关系。
当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出來的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。例如，图 11-10中 的 “学习课程”和 “课程测试”两个用例都需要检査学员的权限，为此，可以定义一个抽象用例“检査权限”。用 例 “学习课程”和 “课程测试”与用例“检査权限”之间的关系就是包含关系，如图11-11所示。其中“<< indud e» ”是包含关系的构造型，箭头指向抽象用例。
当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中
重复地描述这段事件流，也可以防止这段事件流在不同用例中的描述出现不一致。当需
要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一
致性和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也
可以将某一段事件流抽象成为一个被包含的用例。
(2) 扩展关系。
如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。例如，图 1 M 0 中的学员进行“课程测试”时，其测试的次数可能己超出系统规定的限额，这时就需要学员“充入学习币”。用 例 “课程测试”和 “充入学习币”之间的关系就是扩展关系，如 图 1 M 2 所示。其 中 “《 extend » ”是扩展关系的构造型，箭头指向基本用例。
(3)泛化关系。
当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。例如，图 11-10中学员进行课程注册时，假设既可以通过电话注册，也可以通过网上注册，则“注册课程”用例就是“电话注册”用例和“网上注册”用例的泛化，如 图 11-13所示。其中三角箭头指向父用例。
从 U M L 事物关系的本质上来看，包含关系和扩展关系都属于依赖关系。对包含关系而言，抽象用例中的事件流是一定插入到基本用例中去的，并且插入点只有一个。扩展用例的事件流往往可以抽象为基本用例的备选事件流，在扩展关系中，可以根据一定的条件来决定是否将扩展用例的事件流插入到基本用例的亊件流中，并且插入点可以有多个。在实际应用中，很少使用泛化关系，子用例的特殊行为都可以作为父用例中的备选事件流而存在。
在实际工作中，系统分析师要谨慎选用这些关系。从上面的介绍可以看出，包含、扩展和泛化关系都会增加用例的个数，从而增加用例模型的复杂度。
另外，一般都是在用例模型完成之后才对它进行调整，在用例模型建立之初不必急于抽象用例之间的关系。
11.5.2节从用户的观点对系统进行了用例建模，但捕获了用例并不意味着分析的结束，还要对需求进行深入分析，获取关于问题域本质内容的分析模型。
分析模型描述：系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。
为了使模型独立于具体的幵发语言，系统分析师需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起点就是领域模型。领域模型又称为概念模型或简称为领域模型，也就是找到那些代表事物与概念的对象，即概念类。
概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。
每一个用例对应一个类图（由多个类组成），描述参与这个用例实现的所有概念类，而用例的功能行为实现主要通过交互图来表示。例如，用例的事件流会对应产生一个顺序图，描述相关对象如何通过合作来完成整个事件流，复杂的备选事件流也吋以产生-个或多个顺序图。
所有这些图的集合就构成了系统的分析模型。建立分析模型的过程大致包括：定义概念类、确定类之间的关系、为类添加职责（即类自身的行为）、建立交互图（不同类之间的行为关系）等，其中有学者将前三个步骤统称为 C R C C C l a s s - Responsibity -Collaborator , 类-责任-协作者）建模。静态的结构类图和动态的交互图共同组成了某一用例图的实现，即分析视图。
0 0 A 的中心任务就是要找到系统中的对象或类，这些类将反映到系统设计中的软件类和系统实现中某个 O O P 语言声明的类。例如，在领域模型中，学员学习某门课程是一个事件，该事件记录了某个学员和某门课程在一定时期内的责任关系，表达的是领域概念；
在系统设计模型中，学习记录就是一个软件类。虽然它们是不同的事物，但领域模型中的命名启发了后者的命名和定义，从而缩小了表示的差距。在整个系统幵发过程中，要尽量使这些类或对象在不同阶段保持相同的名称。
发现类的方法有很多种，其中应用最广泛的是名词短语法。
它的主要规则是先识别有关问题域文本描述中的名词或名词短语，然后将它们作为候选的概念类或属性，其具体步骤如下：
(1) 阅读和理解需求文档或用例描述。
(2) 筛选出名词或名词短语，建立初始类清单（候选类）。
(3) 将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
(4) 舍弃明显无意义的类。
(5) 小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。
当完成了类的寻找工作之后，就需要理清这些类之间的关系，类之间的主要关系有
关联、依赖、泛化、聚合、组合和实现等，它们在 U M L 中的表示方式如图11-14所示。
(1) 关联关系 =》 只是有某种关联
关联提供了不同类的对象之间的结构关系，它在-段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。其余的关系涉及类元 fi 身的描述，而不是它们的实例。对于关联关系的描述，可以使用关联名称、角色、多重性和导向性来说明，如 图 11-15所示。关联名称反映该关系的0 的，并且应该是一个动词，例如，图 11-15屮 的 “测试”。
如果某种各关联的含义对于幵发人员和用户都是非常明确的，则可以省略关联名称；关联路径的两端为角色，角色规定了类在关联中所起的作用，例如，图 11-15中的“学员”和 “普通网友”。一般情况下，只有在关联名称不能明确表述时，才使用角色名称；多重性指定所在类可以实例化的对象数量（重数），即该类的多少个对象在一段特定的时间内可以与另一个类的一个对象相关联。例如，图 11-15中 的 数 字 和 都 表 示 关 联 ，其中等 价 于 导 向 性 表 示 可 以 通 过 关 联 从 源 类 导 向 到 目 标 类 ，也就是说，给定关联一端的对象就能够容易并直接地得到另一端的对象。导向性用一个箭头表示，如果没有箭头，就认为是一个双向关联或是一个未定义的关联。关联关系的表示方式，同样也适合其他关系的表示，只是箭线符号不同而已。
(2) 依赖关系。
两个类 A 和 B , 如果 B 的变化可能会引起 A 的变化，则称类 A 依赖于类 B 。依赖可以由各种原因引起，例如，一个类向另一个类发送消息、一个类是另一个类的数据成员、一个类是另一个类的某个操作参数等。
(3) 泛化关系/继承关系
泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是了类的泛化。
(4) 共亨聚集/聚合关系 =>临时聚合
共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与 “整体”的生命周期可以不相同。例如，汽车和车轮就是聚合关系，车了•坏了，车轮还可以用；车轮坏了，可以再换一个。
(5) 组合聚集/组合关系 => 共生组合
组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与 “整体”的生命周期相同，“部分”随 着 “整体”的创建而创建，也随着“整体”的消亡而消亡。例如，一个公司包含多个部门，它们之间的关系就是组合关系。公司一旦倒闭，也就无所谓部门了。
(6) 实现关系。
实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接 U , 而每个类分别实现接 n中的操作。确定了类之间的关系之后，通过 U M L 的类图将这些关系记录下来，形成领域模型。例如，图 11-16就是与在线教育平台系统相关的一个简单的领域模型。
找到了反映问题域本质的主要概念类，而且还理清了它们之间的协作关系之后，系统分析师就可以为这些类添加其相应的职责。类的职责包括两个方面的内容，一个是类所维护的知识，即成员变量或属性•，另一个是类能够执行的行为，即成员方法或责任。属性是描述类静态特征的一个数据项。系统分析师可以与用户进行交谈，提出问题来帮助寻找类的属性。
从概念建模的角度来看，属性越简单越好。要保持属性的简单性，应该做到只定义与系统责任和系统 H 标有关的属性；使用简单数据类型来定义属性，不使用可由其他属性导出的属性（冗余属性）：不为类关联定义厲性。最后，要对 M 性加以说明，包括名称、解释和数据类型，以及其他的一些要求。对于类的责任的确定，可以根据用例描述中的动词来进行判断，然后再进行筛选。
这个过程与类的识别过程是类似的，此处不再赘述。系统分析师应该通用性地描述类的成员方法，例如，“交费”和 “组卷”等。另外，根据封装性原则，信息和与其相关的行为应该存在同一个类中。关于一个事物的信总应该包含在单个类中，而不是分布在多个类中。但是，在适当的时候，可以在相关的类之间分享责任。要注意的是，为类添加职责与找到类之间的关系一样，这个阶段也只能找到那些主要的、明显的、与业务规则相关的部分。切忌在这个阶段不断地细化，甚至引入•些与
具体实现相关的技术内容（例如，数据库和分布式对象之类的东西）。
多个对象的行为通常釆用对象交互来表示 ，U M L 2.0提供的交互图有顺序图、交互概览图、通信图和定时图。每种图出于不同view对行为有不同的表现能力，其中最常用的是顺序图，几乎可以用在任何系统的场合。
顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线，其中消息是顺序图的灵魂。当对象行为复杂并存在多种不同状态转换时，还要用到反映对象状态变化的状态图。
对于分析模型的详细程度，各种文献说法不一，在实践中的做法也不一样。
有些文献建议只列出类以及类之间的主要关系，不要对关系进行描述，更不要体现类的职责；
而有些文献则认为应该将这些东西都列出來。
其实，干巴巴地讨论这个问题是没有任何意义的。
在整个系统开发的过程中，分析模型是不断演变的，应随着幵发的深入加入新的内容，或修改己有内容，逐渐完善，演变完整。
最初的分析模型主要是围绕着领域知识进行的，对现实的事物进行建模。而后，则不断地加入设计的元素，最终演变成为运行于计算机上的系统。
总之，模型不是要开发的目标产物，而是开发过程中的一个辅助工作，只要能够利用其帮助团队更好地开发，详细也罢，简约也罢，都是好模型。
