图(state-chart diagram)和活动图(activity diagram)三种模型图来描述。 2)逻辑视图 逻辑视图(logical view)包含设计视图和进程视图，其定义系统的实现逻辑，描述了为实现 用例图描述的功能以及在对软件系统进行设计时所产生的设计概念（又称软件系统的设计词 汇，vocabulary)。逻辑视图定义了设计词汇的逻辑结构、存在于它们之间的语义联系以及设 计词汇包括系统的类/协同/接口及其关系。 对逻辑视图的描述在原则上与软件系统的实现平台无关。它相当于电子产品生产中的电 原理图。逻辑视图包含的模型图有：类图(class diagrams)、对象图(object diagrams)、交互 图、状态图和活动图。 3)实现视图 当系统的逻辑结构在逻辑视图里定义之后，需要定义逻辑结构的物理实现，比如设计元素 对应的源代码文件、各物理文件之间的关系、存放路径等。实现视图(implementation view)就 是定义这些内容的地方，它相当于电子产品的印刷电路板的布线图。实现视图描述组成一个 软件系统的各个物理部件，这些部件以各种方式组合起来（如不同的源代码经过编译，构成一 个可执行系统；或者不同的软件组件配置成为一个可执行系统；以及不同的网页文件以特定的 目录结构组成一个网站等)，构成了一个可实际运行的系统。 实现视图包含的模型图有：部件图(component diagram)、交互图、状态图和活动图。 4)部署视图 软件产品将运行在计算机硬件系统上，如果软件产品是面向网络的应用系统，则有可能同 时运行在多个计算机上。部署视图(deployment view)用来描述软件产品在计算机硬件系统 和网络上的安装、分发(delivery)、分布(distribution)。在部署视图中，系统的静态特性可以通 过部署图来描述，动态特性的描述用交互图、状态图和活动图来描述。 3.3UML的构成 作为UML完整的概念模型，UML的构成包括其成员和建模规则，即 UML=UML成员+UML建模规则 UML的成员包含了模型元素(model element)、模型图(diagram)和公共机制(common mechanism),即 UML成员=模型元素十模型图十公共机制 3.3.1UML模型元素 UML模型元素，类似于电子产品原理图里的集成电路符号，是模型图上包含的基本符 号。基本模型元素可分为四类：结构模型元素(structural element)、行为模型元素(behavioral element)、成组模型元素(grouping element)和注解元素(annotational element),即 UML模型元素=结构模型元素十行为模型元素十成组模型元素十注解元素 |021
０２１ 图（ｓｔａｔｅｃｈａｒｔｄｉａｇｒａｍ）和活动图（ａｃｔｉｖｉｔｙｄｉａｇｒａｍ）三种模型图来描述。 ２）逻辑视图 逻辑视图（ｌｏｇｉｃａｌｖｉｅｗ）包含设计视图和进程视图，其定义系统的实现逻辑，描述了为实现 用例图描述的功能以及在对软件系统进行设计时所产生的设计概念（又称软件系统的设计词 汇，ｖｏｃａｂｕｌａｒｙ）。逻辑视图定义了设计词汇的逻辑结构、存在于它们之间的语义联系以及设 计词汇包括系统的类／协同／接口及其关系。 对逻辑视图的描述在原则上与软件系统的实现平台无关。它相当于电子产品生产中的电 原理图。逻辑视图包含的模型图有：类图（ｃｌａｓｓｄｉａｇｒａｍｓ）、对象图（ｏｂｊｅｃｔｄｉａｇｒａｍｓ）、交互 图、状态图和活动图。 ３）实现视图 当系统的逻辑结构在逻辑视图里定义之后，需要定义逻辑结构的物理实现，比如设计元素 对应的源代码文件、各物理文件之间的关系、存放路径等。实现视图（ｉｍｐｌｅｍｅｎｔａｔｉｏｎｖｉｅｗ）就 是定义这些内容的地方，它相当于电子产品的印刷电路板的布线图。实现视图描述组成一个 软件系统的各个物理部件，这些部件以各种方式组合起来（如不同的源代码经过编译，构成一 个可执行系统；或者不同的软件组件配置成为一个可执行系统；以及不同的网页文件以特定的 目录结构组成一个网站等），构成了一个可实际运行的系统。 实现视图包含的模型图有：部件图（ｃｏｍｐｏｎｅｎｔｄｉａｇｒａｍ）、交互图、状态图和活动图。 ４）部署视图 软件产品将运行在计算机硬件系统上，如果软件产品是面向网络的应用系统，则有可能同 时运行在多个计算机上。部署视图（ｄｅｐｌｏｙｍｅｎｔｖｉｅｗ）用来描述软件产品在计算机硬件系统 和网络上的安装、分发（ｄｅｌｉｖｅｒｙ）、分布（ｄｉｓｔｒｉｂｕｔｉｏｎ）。在部署视图中，系统的静态特性可以通 过部署图来描述，动态特性的描述用交互图、状态图和活动图来描述。 ３．３ 犝犕犔的构成 作为ＵＭＬ完整的概念模型，ＵＭＬ的构成包括其成员和建模规则，即 ＵＭＬ＝ＵＭＬ成员＋ＵＭＬ建模规则 ＵＭＬ的成员包含了模型元素（ｍｏｄｅｌｅｌｅｍｅｎｔ）、模型图（ｄｉａｇｒａｍ）和公共机制（ｃｏｍｍｏｎ ｍｅｃｈａｎｉｓｍ），即 ＵＭＬ成员＝模型元素＋模型图＋公共机制 ３．３．１ 犝犕犔模型元素 ＵＭＬ模型元素，类似于电子产品原理图里的集成电路符号，是模型图上包含的基本符 号。基本模型元素可分为四类：结构模型元素（ｓｔｒｕｃｔｕｒａｌｅｌｅｍｅｎｔ）、行为模型元素（ｂｅｈａｖｉｏｒａｌ ｅｌｅｍｅｎｔ）、成组模型元素（ｇｒｏｕｐｉｎｇｅｌｅｍｅｎｔ）和注解元素（ａｎｎｏｔａｔｉｏｎａｌｅｌｅｍｅｎｔ），即 ＵＭＬ模型元素＝结构模型元素＋行为模型元素＋成组模型元素＋注解元素
1)结构模型元素 结构模型元素(structural element)(基础包)是UML模型里的名词，是模型的静态组成 部分，代表软件系统概念的或物理的存在。例如：类是最常用的一个结构模型元素，代表一系 列共享同样的属性(attributes)、操作(operation)、关系和语义的对象(objects)。 UML模型的静态组成部分不是孤立存在的，它们组合在一起互相协作以完成某项任务。 因此，结构模型元素之间存在着某种语义上的联系。在UML中，这种联系是关系 (relationship)。UML中共有4种关系：关联关系(association)、依赖关系(dependency)、泛化 关系(generalization).和实现关系(realization)。 2)行为模型元素 行为模型元素(behavioral element)(行为元素包)是UML模型的动态组成部分，它是模 型的动词，代表软件系统在空间和时间上的行为。行为模型元素包括两类：交互(interaction) 和状态机(state machine)。 3)成组模型元素 在为复杂的软件系统建模的时候，将大的问题分解为多个子问题分别描述和解决，这就是 分治原则。UML提供了支持分治原则的语言成分，即成组模型元素(grouping element).(模型 管理包)。成组模型元素只有一类，即模型包(package),模型包是一个通用的手段，用来组织 多种语言成分，其中可包含：结构模型元素、行为模型元素和成组模型元素自身。模型包是纯 概念性的，只存在于软件系统的开发阶段。 4)注解元素 注解大量存在于机械图和电子线路图中，用来标示产品的工艺要求等。UML中也存在 着相似的语言成分，这就是注解元素(annotational element),它只有一种，即标注(note)。标 注用来描述施加于一个或多个模型元素的限制，或对模型元素的语义加以说明。标注的图形 表示为一个折了角的长方形，在长方形中写标注的内容。标注的内容可以是形式的文本，或非 形式的文本，甚至可以是图形。 3.3.2UML模型图 UML基本模型元素及其关系必须通过某种载体表示，这种载体就是模型图(diagram)。 在UML中，模型图是一组UML基本模型元素的图形表示，它通常由一组节点(UML基本 模型元素)，及节点之间的连线（关系）组成。一般地说，一个UML基本模型元素既可以出 现在所有的模型图中，又可以出现在某些模型图中，甚至可以不在任何一个模型图上出现。 模型图可以表达软件系统体系结构的五个视图的内容，详细的模型图介绍见3.4和3.5 章节。 3.3.3公共机制 在模型图上对UML成员进行描绘时，存在着共同的描绘方式，它们称为UML公共机制 (UML common mechanism)。使用公共机制，可以使得建模的过程易于掌握，模型易于理解。 公共机制可分解为四个方面的内容：规格说明(specification)、通用划分(common division)、 修饰(adornment)和扩展机制(extensibility)。即 022
０２２ １）结构模型元素 结构模型元素（ｓｔｒｕｃｔｕｒａｌｅｌｅｍｅｎｔ）（基础包）是ＵＭＬ模型里的名词，是模型的静态组成 部分，代表软件系统概念的或物理的存在。例如：类是最常用的一个结构模型元素，代表一系 列共享同样的属性（ａｔｔｒｉｂｕｔｅｓ）、操作（ｏｐｅｒａｔｉｏｎ）、关系和语义的对象（ｏｂｊｅｃｔｓ）。 ＵＭＬ模型的静态组成部分不是孤立存在的，它们组合在一起互相协作以完成某项任务。 因此，结构模型元素之间存在着某种语义上的联系。在 ＵＭＬ 中，这种联系是关系 （ｒｅｌａｔｉｏｎｓｈｉｐ）。ＵＭＬ中共有４种关系：关联关系（ａｓｓｏｃｉａｔｉｏｎ）、依赖关系（ｄｅｐｅｎｄｅｎｃｙ）、泛化 关系（ｇｅｎｅｒａｌｉｚａｔｉｏｎ）和实现关系（ｒｅａｌｉｚａｔｉｏｎ）。 ２）行为模型元素 行为模型元素（ｂｅｈａｖｉｏｒａｌｅｌｅｍｅｎｔ）（行为元素包）是ＵＭＬ模型的动态组成部分，它是模 型的动词，代表软件系统在空间和时间上的行为。行为模型元素包括两类：交互（ｉｎｔｅｒａｃｔｉｏｎ） 和状态机（ｓｔａｔｅｍａｃｈｉｎｅ）。 ３）成组模型元素 在为复杂的软件系统建模的时候，将大的问题分解为多个子问题分别描述和解决，这就是 分治原则。ＵＭＬ提供了支持分治原则的语言成分，即成组模型元素（ｇｒｏｕｐｉｎｇｅｌｅｍｅｎｔ）（模型 管理包）。成组模型元素只有一类，即模型包（ｐａｃｋａｇｅ），模型包是一个通用的手段，用来组织 多种语言成分，其中可包含：结构模型元素、行为模型元素和成组模型元素自身。模型包是纯 概念性的，只存在于软件系统的开发阶段。 ４）注解元素 注解大量存在于机械图和电子线路图中，用来标示产品的工艺要求等。ＵＭＬ中也存在 着相似的语言成分，这就是注解元素（ａｎｎｏｔａｔｉｏｎａｌｅｌｅｍｅｎｔ），它只有一种，即标注（ｎｏｔｅ）。标 注用来描述施加于一个或多个模型元素的限制，或对模型元素的语义加以说明。标注的图形 表示为一个折了角的长方形，在长方形中写标注的内容。标注的内容可以是形式的文本，或非 形式的文本，甚至可以是图形。 ３．３．２ 犝犕犔模型图 ＵＭＬ基本模型元素及其关系必须通过某种载体表示，这种载体就是模型图（ｄｉａｇｒａｍ）。 在ＵＭＬ中，模型图是一组ＵＭＬ基本模型元素的图形表示，它通常由一组节点（ＵＭＬ基本 模型元素），及节点之间的连线（关系）组成。一般地说，一个 ＵＭＬ基本模型元素既可以出 现在所有的模型图中，又可以出现在某些模型图中，甚至可以不在任何一个模型图上出现。 模型图可以表达软件系统体系结构的五个视图的内容，详细的模型图介绍见３．４和３．５ 章节。 ３．３．３ 公共机制 在模型图上对ＵＭＬ成员进行描绘时，存在着共同的描绘方式，它们称为ＵＭＬ公共机制 （ＵＭＬｃｏｍｍｏｎｍｅｃｈａｎｉｓｍ）。使用公共机制，可以使得建模的过程易于掌握，模型易于理解。 公共机制可分解为四个方面的内容：规格说明（ｓｐｅｃｉｆｉｃａｔｉｏｎ）、通用划分（ｃｏｍｍｏｎｄｉｖｉｓｉｏｎ）、 修饰（ａｄｏｒｎｍｅｎｔ）和扩展机制（ｅｘｔｅｎｓｉｂｉｌｉｔｙ）。即
UML公共机制=规格说明+通用划分十修饰十扩展机制 1)规格说明 规格说明体现了UML规则的省略性原则。模型图可以省略某些不重要的内容，但是另 一方面，软件模型必须是完备的，以便于软件系统的建造，这就意味着此模型必须具备足够的 详细信息以供软件建造之用，这些构成一个完备模型的详细信息就是模型的规格说明 (specification)。所有UML模型元素都包含规格说明。在模型图上省略的内容并不代表它 不存在于模型之中，模型完整的或完备的信息可以保存在模型的规格说明中。 2)通用划分 在面向对象的设计中，有许多事物可以划分为抽象的描绘(class)和具体的实例 (instance)。UML提供了事物的两分法(dichotomy)表达。几乎每种UML成员都有这种类 /对象的两分法划分，通常对象和类使用同样的图符，在对象的名字下面加下划线以示区 别。还有一种两分法是接口和实现的两分法划分：接口定义了一种协议，实现是此协议的 具体实施方法。UML里这样的接口/实现两分法划分包括：接口/类或组件、用例和协同、 操作和方法。 3)修饰和扩展机制 UML提供了一系列图形化的标准建模元素，可用于描述软件系统的大多数侧面的特性。 但也有可能在某些情形下，由于应用领域特殊性，标准的UML建模元素，无法完整而准确地 描述软件系统的分析和设计，这时，需要对UML的标准建模元素进行扩充，以提高模型的表 达能力。UML的修饰和扩展机制就是为这个目的而设置的。 标注是UML修饰机制的一个重要组成部分。当用UML的各种建模元素为软件系统建 模时，将遇到关于这些建模元素的复杂的语法、语义、原理、约束、注释等，这些内容对表达问题 的某一方面很重要，但又无法通过标准建模元素完整地表达。这时，可以使用标注对这些建模 元素进行附加说明，例如在使用序列图描述一组对象间的交互时，其中的消息的语义、语法无 法在消息的名字字串内完整地表达时，可以用标注的方法进行直观的说明。 在UML中，标注定义为UML的一个图形表示，它用来描述对一个或一组UML建模元 素的约束或注释。标注可以作用于任何UML建模元素（如类目、对象、关系、消息等），用于对 此建模元素的各方面的特性作补充说明、表示设计分析过程中产生的假设和决定等。标注的 内容对被标注的建模元素没有任何语义上的影响，它只起到增强模型可读性的作用。 3.4UML建模规则 UML的模型图不是UML成员的简单堆砌，而是按特定的规则有机地组合而成，从而构 成一个完备的UML模型图。一个完备的UML模型图(well-formed UML diagram)在语义 上是一致的。 UML建模规则包括： (1)名字：任何一个UML成员都必须包含一个名字。 (2)作用域：UML成员所定义的内容起作用的上下文环境。 |023
０２３ ＵＭＬ公共机制＝规格说明＋通用划分＋修饰＋扩展机制 １）规格说明 规格说明体现了ＵＭＬ规则的省略性原则。模型图可以省略某些不重要的内容，但是另 一方面，软件模型必须是完备的，以便于软件系统的建造，这就意味着此模型必须具备足够的 详细信息以供软件建造之用，这些构成一个完备模型的详细信息就是模型的规格说明 （ｓｐｅｃｉｆｉｃａｔｉｏｎ）。所有ＵＭＬ模型元素都包含规格说明。在模型图上省略的内容并不代表它 不存在于模型之中，模型完整的或完备的信息可以保存在模型的规格说明中。 ２）通用划分 在面向对象的设计中，有许多事物可以划分为抽象的描绘（ｃｌａｓｓ）和具体的实例 （ｉｎｓｔａｎｃｅ）。ＵＭＬ提供了事物的两分法（ｄｉｃｈｏｔｏｍｙ）表达。几乎每种 ＵＭＬ成员都有这种类 ／对象的两分法划分，通常对象和类使用同样的图符，在对象的名字下面加下划线以示区 别。还有一种两分法是接口和实现的两分法划分：接口定义了一种协议，实现是此协议的 具体实施方法。ＵＭＬ里这样的接口／实现两分法划分包括：接口／类或组件、用例和协同、 操作和方法。 ３）修饰和扩展机制 ＵＭＬ提供了一系列图形化的标准建模元素，可用于描述软件系统的大多数侧面的特性。 但也有可能在某些情形下，由于应用领域特殊性，标准的ＵＭＬ建模元素，无法完整而准确地 描述软件系统的分析和设计，这时，需要对ＵＭＬ的标准建模元素进行扩充，以提高模型的表 达能力。ＵＭＬ的修饰和扩展机制就是为这个目的而设置的。 标注是ＵＭＬ修饰机制的一个重要组成部分。当用ＵＭＬ的各种建模元素为软件系统建 模时，将遇到关于这些建模元素的复杂的语法、语义、原理、约束、注释等，这些内容对表达问题 的某一方面很重要，但又无法通过标准建模元素完整地表达。这时，可以使用标注对这些建模 元素进行附加说明，例如在使用序列图描述一组对象间的交互时，其中的消息的语义、语法无 法在消息的名字字串内完整地表达时，可以用标注的方法进行直观的说明。 在ＵＭＬ中，标注定义为ＵＭＬ的一个图形表示，它用来描述对一个或一组ＵＭＬ建模元 素的约束或注释。标注可以作用于任何ＵＭＬ建模元素（如类目、对象、关系、消息等），用于对 此建模元素的各方面的特性作补充说明、表示设计分析过程中产生的假设和决定等。标注的 内容对被标注的建模元素没有任何语义上的影响，它只起到增强模型可读性的作用。 ３．４ 犝犕犔建模规则 ＵＭＬ的模型图不是ＵＭＬ成员的简单堆砌，而是按特定的规则有机地组合而成，从而构 成一个完备的ＵＭＬ模型图。一个完备的ＵＭＬ模型图（ｗｅｌｌｆｏｒｍｅｄＵＭＬｄｉａｇｒａｍ）在语义 上是一致的。 ＵＭＬ建模规则包括： （１）名字：任何一个ＵＭＬ成员都必须包含一个名字。 （２）作用域：ＵＭＬ成员所定义的内容起作用的上下文环境。
(3)可见性：UML成员能被其他成员引用的方式。 (4)完整性：UML成员之间互相连接的合法性和一致性。 (5)运行属性：UML成员在运行时的特性。 完备的UML模型必须对以上的内容给出完整的解释，当用于软件系统的建造时，UML 模型必须是完备的，但是当模型在不同的视图中出现时，出于不同的交流侧重点，其表达可以 是不完备的。 UML有两套建模机制：静态建模机制和动态建模机制。静态建模机制包括用例图、类 图、包图、对象图、组件图和部署图等；动态建模机制包含状态图、活动图、序列图、通信图、交互 概览图和时间图等。 3.5 静态建模机制模型图 3.5.1用例图(use case diagram) 使用用例捕获系统功能需求，代表了从用户角度出发的应用系统的功能。用例图是用例 的可视化表示。用例图主要包含参与者、用例及他们之间的关系。 参与者中的角色(actor),可以是人也可以是事物。若用例执行的动作由参与者引起，则 这个参与者称为主参与者，放在用例的左侧；若参与者帮助用例完成动作，则这个参与者称为 次参与者，通常放在用例的右侧。用例是用户与计算机的一次交互。参与者通过关联与用例 发生作用，关联用一条线段表示。 用例之间的关系用带有箭头的虚线表示，有扩展、包含两种依赖关系以及泛化关系。以教 室预订系统为例，系统的用例图如图3-2所示。中间的椭圆形代表了系统的用例，它们之间 图3-2教室预订系统用例图 024|
０２４ （３）可见性：ＵＭＬ成员能被其他成员引用的方式。 （４）完整性：ＵＭＬ成员之间互相连接的合法性和一致性。 （５）运行属性：ＵＭＬ成员在运行时的特性。 完备的ＵＭＬ模型必须对以上的内容给出完整的解释，当用于软件系统的建造时，ＵＭＬ 模型必须是完备的，但是当模型在不同的视图中出现时，出于不同的交流侧重点，其表达可以 是不完备的。 ＵＭＬ有两套建模机制：静态建模机制和动态建模机制。静态建模机制包括用例图、类 图、包图、对象图、组件图和部署图等；动态建模机制包含状态图、活动图、序列图、通信图、交互 概览图和时间图等。 ３．５ 静态建模机制模型图 ３．５．１ 用例图（狌狊犲犮犪狊犲犱犻犪犵狉犪犿） 使用用例捕获系统功能需求，代表了从用户角度出发的应用系统的功能。用例图是用例 的可视化表示。用例图主要包含参与者、用例及他们之间的关系。 参与者中的角色（ａｃｔｏｒ），可以是人也可以是事物。若用例执行的动作由参与者引起，则 这个参与者称为主参与者，放在用例的左侧；若参与者帮助用例完成动作，则这个参与者称为 次参与者，通常放在用例的右侧。用例是用户与计算机的一次交互。参与者通过关联与用例 发生作用，关联用一条线段表示。 用例之间的关系用带有箭头的虚线表示，有扩展、包含两种依赖关系以及泛化关系。以教 室预订系统为例，系统的用例图如图３ ２所示。中间的椭圆形代表了系统的用例，它们之间 图３ ２ 教室预订系统用例图
存在包含关系。Applicant和Admin是引发用例执行的主参与者，NotificationSystem和 Academic InformationSystem是辅助用例完成的次参与者。 3.5.2类图(class diagram) 类图用于描述系统中的对象类型以及存在于它们之间的各种静态关系。类图也展示类的 性质和操作，以及应用于对象连接方式的约束。性质(property)代表类的结构特性，有两种表 示：属性和关联。属性(attribute)把性质描述成为类方框中的一行文本。关联(association) 是一根两个类之间的实线，方向从源类到目标类，关联的名称以及多重性放在关联的目标端。 图3-3给出了教室预订系统中类图的部分片段。 ClassRoom 0.* 0.1 Applicant userlD:int Student Teacher Staff 图3-3教室预订系统的类图片段 3.5.3包图(package diagram) 包是一种分组结构，最常见的用法是组织类。包图的主要元素是包、它们的可见性和它们 的依赖关系。在UM2.0中，包的表示方法为左上角带有标签的文件夹，使用双冒号来表示 所属包的名称。图3-4为包图的示例。 Notification System CassRoomBookngSystem 图3-4包图 3.5.4对象图(object diagram) 对象图用来说明系统中某一时刻存在的对象以及对象之间的关系。对象图是某时间点上 |025
０２５ 存在包含关系。Ａｐｐｌｉｃａｎｔ和 Ａｄｍｉｎ是引发用例执行的主参与者，ＮｏｔｉｆｉｃａｔｉｏｎＳｙｓｔｅｍ 和 ＡｃａｄｅｍｉｃＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍ是辅助用例完成的次参与者。 ３．５．２ 类图（犮犾犪狊狊犱犻犪犵狉犪犿） 类图用于描述系统中的对象类型以及存在于它们之间的各种静态关系。类图也展示类的 性质和操作，以及应用于对象连接方式的约束。性质（ｐｒｏｐｅｒｔｙ）代表类的结构特性，有两种表 示：属性和关联。属性（ａｔｔｒｉｂｕｔｅ）把性质描述成为类方框中的一行文本。关联（ａｓｓｏｃｉａｔｉｏｎ） 是一根两个类之间的实线，方向从源类到目标类，关联的名称以及多重性放在关联的目标端。 图３ ３给出了教室预订系统中类图的部分片段。 图３ ３ 教室预订系统的类图片段 ３．５．３ 包图（狆犪犮犽犪犵犲犱犻犪犵狉犪犿） 包是一种分组结构，最常见的用法是组织类。包图的主要元素是包、它们的可见性和它们 的依赖关系。在ＵＭＬ２．０中，包的表示方法为左上角带有标签的文件夹，使用双冒号来表示 所属包的名称。图３ ４为包图的示例。 图３ ４ 包图 ３．５．４ 对象图（狅犫犼犲犮狋犱犻犪犵狉犪犿） 对象图用来说明系统中某一时刻存在的对象以及对象之间的关系。对象图是某时间点上