Cat's Empire

统一建模语言是用于系统规格化、系统构建和文档的可视化的语言。
第1章 概述
UML作为建模语言的几个主要理由:
1 统一的术语和标准的符号对于参与沟通的各方而言,都可以使事情更加容易.
2 UML是伴随着建模技术的需求而发展起来的.
3 UML是基于广泛应该并通过论证的方法构建的.
4 UML已被广泛支持.

第2章 基本原则和背景知识
2.1 范例分析简介
2.2 模型、视图和图
1、模型采用的手段总是强调本质的细节，忽略不相关的详情。
2、一个系统模型必须完成以下任务：
   实现所有相关参与者之间的沟通。
   将针对客户、专家和用户的所有因素进行可视化。
   从完整性、一致性和正确性方面对这些因素进行验证。
3、有两个因素对建模的结果将产生巨大影响：该模型为谁创造，期望用于什么目的。
   实战技巧：在模型的抽象级别、清晰度和详细程序上必须做一个折中。也可以开发几个规范程度与详细程度都不同的模型构件，以满足不同的目标读者群。
4、分析的全过程由获取（obtaining）、表达（represnting）和验证（verifying）三个方面组成。
5、每种特定的UML图就是系统模型的一个视图。UML大部分图表（diagram）都是属于graph类型的。也就是说它是由图形元素以及连接图形元素的线组成的.
  模型数据库是区分CASE工具与绘制程序的本质攻能. UML提供了其自己的数据库模型:UML元模型.
2.3信息系统与IT系统
2.4范例分析的模型
2.5UML的历史:方法和符号
2.6需求规格说明
谁编写规格;为谁编写规格;对什么编写规格.
所有可用的模型和视图——只能和用户代表共同创建;只能由用户代表来确认其内容的正确性.
2.7 UML2.0
UML2.0包
上层构造:定义用于系统结构和执行建模的用户构造
下部构造:定义用于UML定义和修正的基本构造
图形交换:定义UML模型交换的标准,包括图形表示
对象约束语言(OCL):定义用于约束定义的语言

第3章 业务系统建模
每个新IT系统需要适应的目标环境:在业务过程级的集成; 在IT系统级的集成.
3.1 业务过程和业务系统
1 过程:是一组同级(并行且/或串行)过程活动的集合,它们连接在一起以实现公共的目标.这些活动集可以由手工活动和/或工作流活动组成.
2 业务过程:是属于业务组织结构和策略领域中的一类过程,其目的是实现业务目标.
3 业务系统:业务过程是动态的,要从整个业务系统的角度来看,还需要考虑静态方面,如组织结构等内容.对于静态和动态两个方面组成的整体,我们称之为业务系统.在业务术语中,业务系统表示的是一个增值链,它描述了通过供应货务和服务而产生的增值过程.一项业务可以跨越一个或多个业务系统.
3.2 一个模型，两个视图
1 从外部来观察一个业务系统，这个外部视图中将只关心与“外部用户”相关的业务过程。外部视图描述了业务系统的环境，业务系统本来则被看作一个黑盒子。
2 从业务系统内部，可以找到雇员和工具，它们负责满足环境的要求，处理必须的业务过程。通常这个内部视图对“外部用户”而言是不可见的。
3.3 外部视图
3.3.1 业务系统提供了什么利益
1 用例：用来定义系统执行的一组操作（action），它将为一到多个参与者(actor)或系统的其他涉众(stakeholder)提供可观测的有价值的结果。
在业务模型的层次上，使用“业务用例”来代替用例。
2 业务系统的外部用户将使用业务系统的输出，这些外部胳膊户无需了解业务用例具体如果执行的详细信息。这些外部用户称为参与者。
3.3.2 视图元素
表述外部视图时需要使用以下几种UML图：
用例图：表示参与者、业务用例以及它们之间的关系。用例图并未描述工序的细节。同时还隐藏了备选场景。这些图很好地概括了业务系统的功能。
活动图：用来描述工序的细节，在这里描述的是业务系统的业务过程。这些描述的主题是参与者与业务系统之间的交互，也就是提供给客户和业务伙伴的货物及服务。
顺序图：按时间顺序展示整个交互链。
3.3.3 用例图
1 参与者 表示一个外部用户与业务系统交互时可以扮演的角色。
2 关联 是参与者和业务用例之间的关系，它表示参与者可以使用业务系统中某个特定的功能。
3 业务用例 描述的是参与者和业务系统之间的交互，也就是描述业务系统中参与者可以使用的功能。
4 包含关系 两个用例之间的关系，意味着业务系统中提供的某个功能对于另外一个功能而言也是可访问的。
5 主题 用来描述包含一个或多个业务用例的业务系统。
3.3.4构建用例图
构建外部视图中的用例图
1 收集信息源——我们期望从哪获知？
2 识别潜在参与者——哪些伙伴和客户将使用该业务系统的货物和服务？
3 识别潜在业务用例——参与者可以例用哪些货物或服务？
4 连接业务用例——谁可以使用业务系统中的哪些货物或服务？
5 描述参与者——该参与者表示什么或完成什么功能？
6 寻找更多的业务用例——还有其它的功能需要完成么？
7 修改业务用例——在业务用例中实际包含什么内容？
8 对业务用例文档化——在业务用例中发生了什么？
9 建模业务用例之间的关系——哪些活动将重复发生？
10 视图验证——所有的内容都正确么？
实践技巧：观察技术对于业务用例的识别是最为有效的。
            采用较低的抽象层次是更可取的。
            使用业务过程或组织中使用的术语。
            不应该包含信息技术领域的术语。
验证外部视图中的用例图：
1 完备性 如果系统中没有其他业务用例了，则说明该用例图就是完备的。
2 范围 在用例图中包含的所有业务用例都是真正的业务用例，也就是符合业务用例的定义。
3 详细程度 满足以下需求
·业务用例表示的是一个行为上连贯的交互序列；
·业务用例是由参与者启动的，并且只与少量参与者相关；
·业务用例表示一个将产生切实、相关结果的功能。
4 业务用例间的关系 包含关系的应用是正确的。
5 命名与描述 业务用例的名称体现的是业务系统提供的功能，其命名应该和业务系统中常用的术语相一致。
6 参与者 在用例图中的参与者所表示的是外部的人、组织或其它业务系统与该业务系统交互时可以扮演的角色。
3.3.5 活动图
1 活动 表示一个业务过程。
2 操作 活动中一个独立的步骤。
3 调用一个活动（操作）
4 接收一个事件（操作）
5 接收一个时间事件（操作）（沙漏符号表示）
6 发送信号（操作）
7 边（控制流）
8 决策点（菱形）
9 汇合点（菱形）
10 分岔（粗横线或粗竖线）
11 结合（粗横线或粗竖线）
12 起始点（活动起点）整个活动开始的地方，一个活动可以有多个起始点。（黑点）
13 活动终点 可以用多个活动终点 (黑点加圈)
14 控制流终点 终止一个控制流。不会影响其它并形流。（圈内加叉）
15 活动分隔 分隔/泳道
3.3.6 构建活动图
构建外部视图中的活动图
1 收集信息源—— 我们期望从哪里获知？
2 寻找活动和操作——参与者使用系统提供的货物与服务是，将完成什么？
3 从业务用例中获取参与者——每个操作由谁负责？
4 连接操作——各个操作将沿着什么顺序执行？
5 精华活动——是否需要添加其它活动图？
6 视图验证——所有的内容都正确吗？
验证外部视图的活动图:
1 当从外部视图来构建活动图时，请始终记住内部过程和内部业务过程是与其不相关的。你的思考应限制在业务系统为外部人员所提供的功能上。
2 不同输出的判断条件不应该相互交迭，否则，控制流就是不明确的，也就是无法清晰指出决策点之后将处理什么流程。
3 判断条件必须包含所有的情况，否则控制流就会出现受阻的现象。在不确定的情况下，可以插入一个“否则（else）”条件。
4 分岔和结合是成对出现的。离开分岔的控制流数与在结合处终止的控制流数应该是相等的。
3.3.7 顺序图
1 注释
2 对象 交互所涉及的对象，主在X轴上。对象是消息的发送者和接收者/
3 消息和业务对象 对象发送和接收的消息将在Y轴上列出，从上到下按顺序添加，箭头的方面表示消息发送的方向。
3.3.8 构建顺序图
构建外部视图中的顺序图
1 指定参与者和业务系统——谁参与了？
2 指定发起人——谁启动交互？
3 描述参与者与业务系统之间的交互信息——将交换什么信息？
4 标识交互的过程——是什么顺序？
5 添加额外信息——还有什么重要内容？
6 视图验证——所有的内容都正确吗？
验证外部视图中的顺序图：
1 所需的所有顺序图是否都已经完整并可用？对于每个业务用例都应该有一个顺序图。
2 顺序图正确吗？每个顺序图只包含一个表示业务系统的对象，而其他对象的数量最多只能和该业务用例相关的参与者数量一样。
3 在用例图中列出的每个参与者是否至少在一张顺序图中出现？
4 每个启动业务用例的参与者是否在某张顺序图中处于起点位置？
5 是否在图中添加了所有的重要注释信息？是否在图中添加了过多的注释，以至于降低了图的清晰性？
3.3.9 高层顺序图
可以使用跨越多个业务用例的高层顺序图，在一个较粗的层次上表述业务过程。
3.3.10 针对业务用例场景的顺序图
每个消息交互都仅限于业务用例内部。
3.4内部视图
3.4.1 视图的元素
包图 以包的形式来描述组织单元
类图 描述协作者和业务对象之间的连接与关系
活动图 描述业务系统中的业务过程
3.4.2 包图
1 包《Organization Unit》组织单元可以用包来表示，组织单元名称写在《Organization Unit》下面
2 类《Worker》构造型《Worker》描述的是负责执行业务过程的人，以及与业务过程执行相关的人所扮演的角色。工作者是由人扮演的；工作者是位于业务系统中的；工作者可以与其它工作者以及业务系统之外的参与者通信。
3 《Business Object》被动元素
3.4.3 构建包图
构建内部视图中的包图
1 开发业务系统的初始包图——该业务系统包括哪些工作者和业务对象？
2 寻找其他组织单元——还有谁？
3 将工作者和业务对象分配到组织单元中——谁属于哪里？
4 寻找其它的组织单元、工作者或业务对象——还有什么？
5 视图验证——所有的内容都正确吗？
验证内部视图中的包图：
1 是否所有的工作者和组织单元都与包图所描述的业务系统为提供货物和服务所进行的处理相关？
2 是否不存在包图中所描述的业务系统为提供货物和服务所进行的处理不相关的工作者和组织单元？
3 是否所有业务对象都是包图中所描述的业务系统在提供货物和服务时所需的？
4 是否不存在包图中所描述的业务系统在提供货物和服务时所不需要的业务对象？
3.4.4 类图
1 《Worker》类
2《Business Object》类
3 关联 可以标上关系名称，添中一个三角形指定方向。
4 泛化 用来特指一般元素与特殊元素之间的关系。
3.4.5 构建类图
构建内部视较中的类图
1 寻找类——类图中存在哪些类？
2 创建类之间的关联——哪些类相互之间有往来？
3 证实关联性——这些关系意味着什么？
4 添加泛化关系——业务对象能分组吗？
5 视图验证——所有的内容都正确吗？
验证内部视图中的类图：
1 类图完整吗？在包图中的类是否全都存在于这个类图中？
2 是否对所有的关联都做了有意义的标注？箭头的方向是否正确？
3 类图正确吗？在知识承载者协助下一起仔细阅读，并遍历每个服务过程，这样就可以发现大多数错误。
4 详细程序是否最合适？该图是否详细到足以表示所有的内容，或者过于详细，或由于缺乏特定方面的内容而使其不清晰？
3.4.6 活动图
3.4.7 构建活动图
构建内部视图中中活动图（与外部的不同）
2 寻找活动和操作——需要执行哪些活动，才能提供和交付参与者能利用的货物或服务？
验证内部视图的活动图（与外部的不同）：
1 要构建内部视图的活动图时，请始终记住只有内部过程和业务过程才是相关的。

第4章 IT系统建模
IT系统模型的四个视图:
·外部视图——用例图和用例顺序图，是以UML用例图及界面原型的形式展现IT系统的用例。它描述IT系统提供哪些功能。
·结构视图——类图，以UML类图的形式展现了与IT系统相关的类。它描述IT系统中将对哪些结构化信息进行归档。
·交互视图——顺序图和通信图，以状态图的形式展现了每个对象的形为。它描述了IT系统中某个对象可能发生的所有事情。
·行为视图（交互视图）——状态图，以顺序图和通信图的形式，展现了IT系统中发生“转化”或“查询”操作时所执行的控制流。它描述用户使用IT系统时将会发生的事情。
4.1外部视图
4.1.1用户视图
1 外部视图由用例图、用例顺序图和界面原型组成。
2 对于用户而言，系统本质上是由用户界面和用例构成的。
3 操作IT系统的工作者属于业务系统的一部分，不是业务系统的参与者。
4.1.2 视图元素
IT系统的外部视图包括以下3个元素：
·用例图展示了IT系统的所有使用者（参与者），以及在IT系统中这些使用者可以执行的功能（用例）。在实践中，将IT系统中所有的用例都绘制在一张用例图中的意义不大。
·用例顺序图用来描述每个用例中用户与IT系统的交互过程
·界面原型用来展现每个用例所提供的用户界面的外观。
4.1.3 用例图
1 参与者 IT系统的用户可以描述成一个参与者。
2 用例 描述的是在参与者和IT系统之间在业务过程执行时可能产生的交互。
3 关联 关联是参与者和用例之间的连接线。关联表示这个参与者将执行该用例。
4 包含关系 表示箭头发起端的用例包含箭头另一端的用例。
4.1.4 查询事件和转换事件
·查询事件的目标是显示信息，通常不会修改IT系统中的任何东西。查询事件的结果就是已显示的信息。
·转换事件的目标是对IT系统中的信息进行存储、修改或删除操作。转换事件的结果取决于转变是否成功，如果成功，信息将被存储、修改或删除；如果失败，对于用户而言就没有任何东西发生改变。
1 在UML中并没有区分查询事件和转换事件，因而我们将使用UML扩展构造型，它是UML中一种用来表示自定义元素的扩展机制。在事件名称之前添加《Q》表示该事件是查询事件；在事件名称之前添加构造型《M》表示该事件是转换事件。
4.1.5 用例顺序图
1 注释
2 对界面原型的引用 对用户界面中屏幕窗体、列表及其他元素的引用，都将添加在注释中：例Show Coupon Details [B27]，这将为用例顺序图和界面原型之间建立链接。
3 参与者 Somebody
4 查询事件
5 转换事件
6 交互引用 ref Use Case，用来在用例顺序图中引用其他用例顺序图中的交互。
7 IT系统 包含所有对象和完整功能的黑盒子。
4.1.6 构建外部视图
构建外部视图中的各种图：
·收集信息源——我们期望从哪获知？
·标识潜在参与者——谁将与该IT系统协作？
·标识潜在用例——使用该IT系统可以完成什么？
·连接业务用例——谁可以使用该IT系统做什么？
·描述参与者——参与者描述的是谁或什么？
·寻找更多的用例——该IT系统还将提供哪些其他功能？
·编辑用例——业务用例中实际包含什么？
   为了避免用例过大，应针对每个用例询问以下问题：
   1 用例是不是由一组属于整体交互序列的行为组成的？
   2 参与者是否能够独立执行该用例？
   为发避免用例过小，应针对每个用例询问以下问题：
   1 该用例是否交付了一个切实、相关的结果？
   2 该用例是否从来不会单独执行，而只是按顺序与其它用例结合使用？
·用例文档化——在业务用例中发生了什么？
·建模用例间的关系——什么可以重用？
·视图验证——所有的内容都正确吗？
   验证外部视图的用例图：
·用例图是否完整？如果没有其他用例了，则说明该用例图就是完整的。
·用例正确吗？如果是按照用例的定义来描述IT系统的用例，那就是正确的。
·详细程序适当吗？用例表示的是一个在行为上连贯的交互序列，用例是单个参与者执行的，用例描述的是一个将产生切实、相关结果的功能。通常，用例是作为一个整体执行的。
·用例的名称合适吗？每个用例的名字都应描述它在IT系统上执行的活动。
·参与者正确吗？在用例图中的参与者表示的是某人或某东西与该系统交互时所扮演的角色。
  验证外部视图中的用例顺序图：
·用例顺序图是否完整？每个用例都应有一个描述该用例可能事件流的顺序图。
·用例顺序图正确吗？每个用例顺序图中表示IT系统的只有一个对象，只能对它发出查询事件和转换事件。
4.2 结构视图
4.2.1 对象和类
1 一方面，类是创建对象时所遵循的模式；
2 另一方面，类是一组对象，它们是按照该类创建的。
4.2.2 泛化、特化和继承
·对于超类的所有描述都适用于所有子类。
·超类对象可以完成的所有事情，子类对象也可以完成。
·在被建模的系统术语环境中，子类是超类的一种特殊形式。
4.2.3 静态和动态业务规则
·静态业务规则 在任何时间点都能够验证的业务规则。这些业务规则是与类的静态结构相关的，可在结构视图的类图里被文档化。
·动态业务规则 只能够在特定时间点进行验证的业务规则，也就是某事件发生时才能进行验证。这些业务规则涉及的是类对象的动态行为。这些业务规则将在行为视图的状态图中被文档化。
4.2.4 视图元素——一个或几个类图组成
4.2.5 类图
1 类
2 属性
3 泛化
4 关联
5 多重性
6 聚合 “由……组成”
4.2.6 构建类图
两个步骤：
1自顶向下分析 在我们的IT系统中，将使用哪些信息或领域概念？
·标识并建模类——需要什么类？
·标识并建模关联——这些类之间是如何连接的？
·定义属性——对于该对象，需要了解什么？
2自底向上分析 IT系统的每个输入、输出需要哪些信息？
·列出所需的查询和输入——系统将提交和接受什么？
·描述查询和输入——它们将如何显示？
·进行信息分析——需要哪些类、关联和属性？
·合并类图——它们如何结合在一起？
·验证类图——所有的内容都正确吗？
  验证结构视图中的类图：
·类图完整吗？见“交互视图”
·类图正确吗？经验显示，和知识承载者高度协作、共同阅读类图，能够发现大部分错误。另外，可以使用怀疑结构模式来测试。
4.3 行为视图
4.3.1 对象的生命周期
4.3.2 视图元素 多个状态图
4.3.3 状态图
1 初始状态，它不是一个标准状态，在此状态中对象还不存在。
2 状态 对象的状态是由其属性和关联决定的。
3 转换
4 内部转换
5 转换事件 启动从一个状态到另一个状态转换的事件。《M》Mutation Event/
6 活动 活动是对象中可以通过事件启动的操作集。活动描述的是对象的一些操作，这些操作并非是对事件的响应。《M》Event/Action
7 监护条件 判断条件，需要确定启用那个转换时使用。[Guard Condition]
8 终态 表示生命周期的结束，也不是一个实际的状态。
4.3.4 构建状态图
构建行为视图中的状态图：
·标识和对象相关的转换事件——能对该对象产生什么影响？
·按时间顺序对相关事件分组——一个正常的生命周期是如何的？（诞生、生命周期和消亡）
·对状态和转换建模——在此有哪些状态？
·在状态图中添加活动——对象要做什么操作？
·验证状态图——所有的内容都正确吗？
验证行为视图的状态图：
·是否有一个正式的终态，还是该对象永远存在，没有一个消亡事件？
·从每个状态到终态之间是否有一个（间接的）转换？
·如果逻辑消亡（对象冻结）和物理消亡（对象删除）是相关的，那么它们之间是否有区别？
·对于第个状态，是否至少有一个事件，它的应答是特定于该状态的？如果不是，那么该状态就应进行修正。
·如果在相同的状态中，通过相同的事件将启动两个及两个以上转换时，那么监护条件必须是不交迭的。
4.4 交互视图
4.4.1 看看IT系统内部发生了什么
4.4.2 视图元素
·通信图 对IT系统中的查询流程进行文档化，每个查询都是某个用例的一部分。
·顺序图 对IT系统中的转换事件进行文档化，转换事件也是某个用例的一部分。
4.4.3 通信图
1 参与者 Somebody
2 查询事件
3 参数
4 迭代*
5 对象和入口对象 Object:Class
4.4.4 顺序图
1 注释
2 参与者 Somebody
3 转换事件
4 对象
5 迭代
6 生命线
4.4.5 构建通信图
构建交互视图中的通信图：
·草拟查询结果——需要什么？
·标识相关的类——需要哪些类？
·定义初始对象——将从哪里开始？
·设计事件传递路径——走到哪里？
·修正事件传递路径——哪些对象是确实需要的？
·标识必要的属性——需要知道哪些内容
·验证通信图——所有的内容都正确吗？
验证交互视图中的通信图：
·草拟的查询结构能否通过该通信较构建？
·在通信图中的事件路径是否遵从类图中的关联？
·当涉及迭代或者选择时，是否在类图中也始终存在需求？
如果涉及这些问题的答案都是YES，那么绝大部分的错误根源就被消除了。
4.4.6 构建顺序图
构建交互视图中的顺序图：
·标识相关类——转换事件将显示哪些类？
·确定初始对象——转换事件从哪开始？
·传播事件——转换事件如何被转发？
·指定事件参数——对象需要知道什么？
·验证顺序图——所有的内容都正确吗？
验证交互视图中的顺序图：
·所有受转换事件影响的类是否已经在顺序图中列出了？
·转换事件是否沿着类图中的关联进行转发的？

第5章 系统集成建模
我们所理解的系统集成就是将原有或新的IT系统嵌入已有的IT系统环境中。
5.1 系统集成的相关术语
1 接口 IT系统之前将通过接口进行通信，接口是系统集成的基本元素。
2 消息 通过接口连接的IT系统之间将进行消息交换。消息是由发送者IT系统发送的，当接收者IT系统接收到预期的消息时，将启动一个活动。
3 企业应用集成EAI 是对组织内的方法、概念、分类工具、连接以及相关程序进行整合。
4 电子数据交换EDI 指的是在各个组织与协会的IT系统之间的业务文档交换标准。业务文档也称为消息。
5 UN/EDIFACT（联合国/针对行正管理、商业和传输领域的电子数据交换标准）是针对行政管理、商业和传输领域间电子数据交换的国际标准，它对规则和消息类型进行了标准化。
6 XML
5.2 UML中的消息
在UML中，一个消息可以分为两部分：消息名称指定了事件；消息的参数包含的信息将附在消息中。
5.3 一个模型由两个视图组成
对于IT系统集成而言，需要定义将要交换哪些信息，以及如何交换等。基于该原因，系统集成模型将由两个不同的视图组成：进程视图和静态视图。
进程视图：顺序图和活动图
静态视图：类图
5.4 进程视图
进程视图描述的是IT系统与其他IT系统进行消息交换时所经过的活动。
5.4.1 业务系统模型是基础
5.4.2 视图元素——顺序图和活动图
活动图展示的是操作流，描述了每个操作之间的依赖关系，以及业务对象的流程。
顺序图描述的是IT系统之间消息交换的时间顺序。
5.4.3 活动图（与3.3.5不同）
1 活动 活动表示一个业务过程
2 对象流（边）
3 接收信号（操作）
4 业务对象
5.4.4 顺序图
1 对象
2 消息
3 消息流（与活动图的对象流是相对应的）
4 参数
5.4.5 构建进程视图的图
构建进程视图的图
·确定接口——哪些IT系统间将进行通信？
·标识相关的系统——哪些IT系统要交换信息？
·标识活动和控制流——将完成什么，谁负责？
·定义消息——将交换什么信息？
·定义规则——对操作有何影响因素？
·验证视图——所有的内容都正确吗？
验证进程视图的顺序图：
·所有需要确认的信息是否在顺序图中体现出来？
·是否涉及消息交换的各个IT系统、业务伙伴都至少在其中一张顺序图中列出？
·所有交换的业务对象是否都在顺序图中以消息参数的形式列出？
·是否所有重要的信息都已经添加到图中了？是否在科中添加了地多的注释，去掉哪些注释可以使图的清晰度更高？
·消息流是否和活动图中的对象流相一致？
验证进程视图中的活动图：
·当构建进程视图中的活动图时，应只关心与消息交换相关的流。业务过程属于业务模型的。
·对象流清晰可见吗？是否所有业务对象都已经在活动图中列出了？
·不同输出的判断条件不能交迭。否则控制流就是不明确的，也就是在决策节点上控制流无法确定。
·判断条件必须包含所有的可能，否则控制流会陷入死胡同。在不确定的时候，可以添加一个“else”作为判断条件。
·分岔和结合必须是平衡的。离开分岔点的控制流数量应该和到达结合点的控制流数量相一致。
5.5 静态视图
静态视图描述的是业务对象的结构。
5.5.1 视图元素——类图
5.5.2 类图
在系统集成模型中的类图里，类表示瓣是一组信息的集合，这些信息是业务对象所包含的。
5.5.3 构建类图
构建静态视图中的类图：
·收集与业务对象相关的信息——需要读取什么？
·构建类图——业务对象采用什么结构？
·从IT系统的类图中采纳类和属性——类图中将呈现什么？
·推出其它数据元素——其他的该从哪里获取？
·为业务对象定义类和关系——需要哪些类间关系？
·验证视图——所有的内容都正确吗？
验证静态视图中的类图：
·类图是否完整？业务对象是否包含发送者和接收者要完成其活动所需的所有信息？
·是否对业务对象进行检查，使其只包含可以由外部参与者解释的数据元素？
·是否检查使用标准消息的可能性？
·类之间的关系是否以及意义的形式标注出来了？箭头的方向是否正确？
·类图是否正确？和知识携带者一起认真阅读类图，并对每个场景进行遍历，这样就可以发现绝大部分的错误。
5.5.4 将IT系统的数据转换到消息中
5.5.5 UML消息到不同标准格式的转换