第一节 信息模型与建模
信息模型（information model）是一种用来定义信息常规表示方式的方法，通过使用信息模型，计算机系统可以对所管理的数据进行重用、变更和分享。信息模型独立于具体技术，用于反映一个领域、机构或系统的信息基本状况。使用信息模型的意义不仅在于对象的建模，同时也在于对象间相关性的描述。在多数情况下，信息模型以层次化的形式来表示［1］。
模型最主要的优点在于它可以将一个复杂问题分解为几个可以控制的组成部分。建立卫生信息模型，可以使信息收集、记录、整理、传输、分析、利用的每个环节上的人都能在概念上对数据有统一的理解，在格式上有统一的标准，从而实现语法上的互操作以及语义上的互操作。标准的信息模型，相当于为所有系统建立了统一的信息基础框架，基于该框架的术语编码、数据交换等都将具备一致的语义基础。
一、建模原则
软件建模正在成为一种普遍的技术，以帮助软件工程师理解、设计软件，并就软件的各个方面与有关的涉众进行沟通。这里的涉众是指那些与该软件有着明确或隐含利害关系的人或机构，例如用户、买方、供应商、架构师、认证权威机构、评估人员、开发人员、软件工程师，也许还有其他人员。虽然在文献和实践中有许多建模语言、符号、技术和工具，但是有一些统一的一般概念以某种形式适用于所有这一切。下面将介绍这些一般概念的背景知识［2，3］。
（一）建模原则
建模为软件工程师提供了一种有组织的和系统化的方法，用于表示正在研究中的软件的一些重要方面，这有助于就软件或其构成元素作出决策，并将这些重要决策与涉众群体中的其他人进行沟通。指导此类建模活动的一般原则有3个。
1.为要点建模
即使是好的模型通常也并不能表达软件在各种可能的条件下的各个方面或功能特征。建模通常只涉及开发那些需要特定答案的软件功能特征，这就需要抽取掉所有不必要的信息。这种方法保持了模型的可管理性和实用性。
2.提供视图
建模是利用已经定义好的、在每个视图中用于表达该模型的一组规则来为正在研究中的软件提供一个全景视图。这种视图驱动的方法为模型确立了维度，例如结构视图、行为视图、时间视图、组织视图和其他相关视图。使用适当的符号、词汇、方法和工具，将信息组织到这些视图中，可将软件建模工作的重点放在与视图相关的特定关注点上。
3.实现有效的通信
建模使用软件的应用领域词汇、建模语言和语义表达（换句话说，就是上下文含义）。当这些能够严格且系统地使用时，这种建模会产生一种报告方法，从而促进软件信息与项目涉众的有效沟通。
模型是软件组件的抽象或简化。使用抽象方法的结果是，没有任何一个单一的抽象能完全描述软件组件。因此，不如说软件模型是诸多抽象的集合，当把它们放在一起时，它们也只是描述选定的方面、构面或视图，只描述那些需要作出明智决策并首先对创建该模型的原因作出响应的方面或视图。这种简化就会产生构成模型背景的一组假设，那么如果要重用这一模型，就要首先验证这些假设，以建立重用模型在其新用途和其背景间的相关性。
（二）模型的属性和表达
模型的属性是模型的特征，用于在所选的建模符号和使用的工具中描述其完整性、一致性和正确性。模型的属性包括如下几个方面。
1.完整性
在模型中所有需求都达到得以实现及验证的程度。
2.一致性
模型中的需求、断言、约束条件、函数或组件描述等不存在任何冲突的程度。
3.正确性
模型满足其需求和设计规范的程度，并且没有缺陷。
构建模型是为了表示真实世界的对象及其行为，以回答有关软件有望如何运行的特定问题。对模型进行质疑检查，无论是通过探究、模拟，还是评审，都能暴露出模型和模型所涉及的软件中的不确定性区域。这样，这些有关需求、设计和/或实现的不确定性或未回答的问题随后就可得到适当的处理和解决。模型的主要表达元素是实体。实体可以是具体事物（如处理器、传感器或机器人）或抽象事物（如软件模块或通信协议）。可将模型实体利用文字、连线或文本操作符与其他实体连接起来。模型实体的表达可以使用文本或图形化建模语言来完成，建模语言类型都通过特定的语言构造来连接模型实体。实体的含义可以通过其形状、文本属性或两者兼而有之来表示。一般来说，文本信息遵循特定于语言的句法结构。与使用这些实体和关系的上下文、结构或行为建模相关的精确含义取决于所使用的建模语言、应用于建模工作的设计严谨性、正在构建的特定视图，以及可能附加特定符号元素的实体。可能需要模型的多个视图来捕获软件所需的语义。当使用自动化支持的模型时，可能要检查模型的完整性和一致性。除有明确的工具支持之外，这些检查的有用性在很大程度上取决于应用于建模工作的语义和语法严格程度。正确性通常通过模拟和/或评审来检查。
（三）句法、语义和语用学
模型可能具有惊人的欺骗性。如果模型是一个缺失信息的抽象，那么可能会让人产生从单个模型去正确理解软件的错觉。一个完整的模型（与建模工作相关的“完整”）可以是多个子模型和任何特殊功能模型的结合。在这个子模型集合中，与单个模型相关的检查和决策可能是有问题的。理解建模构造的精确含义也很困难。建模语言是由句法和语义规则定义的。对于文本语言，语法是使用定义有效语言结构（如巴科斯-诺尔范式）的符号语法来定义的。对于图形语言，语法是使用被称为元模型的图形模型定义的。与巴科斯-诺尔范式一样，元模型定义图形建模语言的有效语法结构；元模型定义了如何组合这些构造来生成有效的模型。
建模语言的语义详细说明了模型中实体和关系的含义。例如，由一条线连接的两个框的这类简单关系图可以有多种解释。了解这些可能是对象关系图，也可能是活动关系图的框-线图，可以帮助解释这个模型。实际上，通常很好地理解选定的建模语言下的一个特定的软件模型的语义，要了解所用的建模语言是如何表达模型中实体和关系的，要了解建模师的经验基础和建模所依据的上下文背景，以及是如何表示的。即使在信息不完整的情况下，意义也是通过抽象的模型来传达的；语用学解释了意义如何在模型及其上下文中体现，以及如何有效地与其他软件工程师进行沟通。然而，仍然有一些实例需要在建模和语义方面保持谨慎。例如，必须检查从另一个模型或库导入的所有模型构成，以确定在新的建模环境下是否存在冲突的语义假设。应该检查模型是否有文档化的假设。虽然建模语法可能是相同的，但是模型在新环境（即不同的上下文）中可能意味着完全不同的东西。另外，考虑到随着软件的成熟和变化，可能会引入语义不一致，从而导致错误。随着时间的推移，与模型各部分打交道的软件工程师会越来越多，加上工具更新和可能的新需求，模型的某些部分有可能会表达与原始作者的意图和初始模型上下文完全不同的含义。
（四）前置条件、后置条件和不变条件
当对功能或方法建模时，软件工程师通常是从功能或方法执行前、中、后三种软件状态的一组假设开始的。这些假设对于功能或方法的正确运行是必不可少的，为便于讨论，将其分为前置条件、后置条件和不变条件三组。
1.前置条件
在执行功能或方法之前必须满足的一组条件。如果这些先决条件在功能或方法执行之前不成立，则功能或方法可能产生错误的结果。
2.后置条件
一组在功能或方法成功执行后保证为“真”的条件。通常，后置条件表示软件的状态是如何变化的、传递给功能或方法的参数是如何变化的、数据值是如何变化的，或者返回值是如何受到影响的。
3.不变条件
在功能或方法执行之前和之后，运行环境中始终存在的一组条件。换句话说，就是一组不变的条件，这些不变条件对软件和功能或方法的正确运行是相关和必要的。
二、模型类型
典型的模型是由若干子模型集合而成。每个子模型都是一个部分的描述，并且是为特定目的而创建的；它可以由一个或多个图组成。这些子模型可以使用多种建模语言，也可使用单一建模语言。统一建模语言（UML）识别许多种建模图。使用这些图以及建模语言构件，可产生三种常用的模型类型：信息模型、行为模型和结构模型。
（一）信息建模
信息模型主要关注数据和信息。信息模型是一种抽象表示，用于标识和定义数据实体的一组概念、属性、关系和约束。语义或概念信息模型通常用于从问题的角度为建模的软件提供某种形式体系和上下文，而不关心该模型如何实际映射到软件的实现。语义或概念信息模型是一种抽象，因此仅包括概念化信息的真实视图所需的概念、属性、关系和约束。语义或概念信息模型的后续转换，就是软件中实现的逻辑和物理数据模型的细化。
（二）行为建模
行为模型是确定和定义被建模软件的功能。行为模型通常有三种基本形式：状态机、控制流模型和数据流模型。状态机向软件模型提供的是已定义好的状态、事件和转换。软件通过模型环境中发生的受保护或未受保护的触发事件从一种状态转换到下一种状态。控制流模型描述一系列事件如何使流程被激活或停用。数据流行为被归类为一系列步骤，在这些步骤中，数据经过流程向数据存储或数据接收器移动。
（三）结构建模
结构模型从软件的各个组成部分说明软件的物理或逻辑组成。结构建模在被实现或建模的软件与将要在其中运行的环境之间建立已定义的边界。在结构建模中使用的一些常见结构构造是实体的组合、分解、泛化和专门化；实体之间的相关关系和基数的确定；以及流程或功能接口的定义。UML为结构建模提供的结构图包括类图、组件图、对象图、部署图和包图。
三、模型分析
模型的开发为软件工程师提供了一个研究、推理和理解与软件相关的结构、功能、运行使用和组装考虑事项的机会。需要对构建的模型进行分析，以确保这些模型足够完整、一致和正确，以满足涉众的预期目标。下面的部分简要描述了软件模型通常使用的分析技术，以确保软件工程师和其他相关的涉众从模型的开发和使用中获得适当的价值。
（一）完整性分析
为了使软件完全满足涉众的需求，完整性是至关重要的——从需求获取过程到代码实现。完整性是指所有指定的需求是否都已得到实现和验证的程度。可以使用结构分析和状态空间可达性分析等技术的建模工具检查模型的完整性（这些技术确保状态模型中的所有路径都由一组正确的输入到达）；可以使用检查或其他评审技术人工检查模型的完整性。这些分析工具产生的错误和警告信息，以及通过检查或评审发现的错误和警告信息，表明可能需要采取纠正措施，以确保模型的完整性。
（二）一致性分析
一致性是模型不包含任何冲突的需求、断言、约束、功能或组件描述的程度。通常，一致性检查是通过使用自动化分析功能的建模工具来完成的；还可以使用检查或其他评审技术人工检查模型的一致性。与完整性一样，这些分析工具产生的错误和警告信息以及通过检查或评审发现的错误和警告信息表明需要采取纠正措施。
（三）正确性分析
正确性是模型满足其软件需求和软件设计规范、不存在缺陷并最终满足涉众需求的程度。正确性分析包括验证模型的语法正确性（即正确使用建模语言语法和构造）和验证模型的语义正确性（即使用建模语言构造来正确表示建模对象的含义）。为了分析一个模型的语法和语义的正确性，可以自动化分析（如使用建模工具来检查模型的语法正确性）或人工分析（使用检查或其他评审技术）以便找到可能的缺陷，然后在软件的发布之前删除或修复已确认的缺陷。
（四）可追溯性
开发软件通常涉及许多工作产品的使用、创建和修改，如计划文档、过程规范、软件需求、图表、设计和伪代码、手写和工具生成的代码、手动和自动测试用例和报告，以及文件和数据。这些工作产品可以通过各种依赖关系（如应用、实现和测试）进行关联。随着软件的开发、管理、维护或扩展，需要映射和控制这些可追溯关系，以证明软件需求与软件模型和工作产品的一致性。通常，可追溯性可改进软件工作产品和软件过程质量的管理；它还能向涉众提供所有的需求均已得到满足的保证。可追溯性使得在软件开发和发布之后进行变更分析成为可能，因为可以很容易地遍历变更与软件工作产品的关系来评估变更的影响。通常，建模工具会提供一些自动化或人工的方法来规范和管理模型和其他软件工作产品中所表示的需求、设计、代码和/或测试实体之间的可追溯性连接关系。
（五）交互分析
交互分析着重于实体之间的通信或控制流关系，这些实体用于在软件模型中完成特定的任务或功能。此分析检查软件模型的不同部分，包括其他软件层（如操作系统、中间件和应用程序）之间交互的动态行为。对于某些软件应用程序来说，检查计算机软件应用程序和用户界面软件之间的交互也很重要。一些软件建模环境为研究建模软件的动态行为提供了模拟工具。逐步通过模拟，为软件工程师提供了一个分析选项，以审查交互设计并验证软件的预期功能。