阶段的求解决域的不一致。 面向对象的设计范式采用建模的观点。在传统的软件生命周期中,分析和设计同开发问题域的模型紧 密相关。而在面向对象的生命周期中,保留了明显的独立结构。人们通过把问题域作为一系列相互作用的 实体可以构造出模型。实体的基于软件模型以及模型间的关系汇集成应用程序的基本结构。这样,在分析 阶段开发的信息就成为设计阶段的一个主要部分。这种极其自然的过渡是利用了“构件”的一致性。这种 致性与结构化分析和结构化设计有着完全不同的观点。 由过程设计范式产生的构件是执行任务的过程,且与所提出的解决方法有关。 由面向对象范式产生的构件是实体描述,即类。许多这样的描述可直接地反映原始问题,尽管许多类 并不表示物理对象,但它们是概念上的实体,可以用问题域的术语来描述 在传统语言中,程序是由传递参数的过程或函数的集合组成,每个过程处理它的参数,并有可能返回 个值,因此执行单元(即过程)为中心。 在面向对象的语言中,世界被看作独立的对象的集合,相互之间通过过程(通常称作消息)进行通信 对象是主动的,而过程(消息)是被动的,过程(消息)和它们的参数一起被从一个对象传递到另一个对 象。一个对象根据提交给它的请求(即过程过又称做方法)并基于这些过程(方法)进行行动,因此以数 据(即对象)为中心。由于抽象数据类型普遍地被应用于模拟应用领域内的实体,它们为程序的模块化提 供了一个自然的基础,其面向对象程序的机构可以非常相似于应用领域中的结构。 为了说明过程范式和面向对象范式的不同,下面以一个十字路口控制交通灯的软件系统为例子,其简 要的需求说明如下 硬件包括一组传感器、交通灯和控制箱。软件读出传感器的状态,决定十字路口的新状态并且发出改 变交通灯的信号。另外,系统还有其他能力,如通过配置集测试循环灯的任选项。系统也可以被设置成缺 省状态。传感器指明在特殊车道上有无车辆。有几种类型的传感器,每种传感器的内部工作方式都不同。 然而所有的传感器都是中断驱动的,且一旦触发,就置传感器状态位。当决定要改变十字路口的状态时, 需要重新设置每个传感器。这个特殊的十字路口用两种类型的交通灯:一种是常见的三色灯,它用于直接 向前车道:另一种是四方位灯:红、黄、绿和转动箭头标志。每个灯都有当前状态、下一个状态和缺省状 态。控制器的硬件包括灯的开关、传感器的数据存储以及进行定时查询状态的时钟。控制器的软件读时钟 定时查询传感器,确定下一个状态并且发信号改变交通灯。 过程范式通过考虑必须执行的一组任务来开发交通控制系统。如下图所示。层次结构中的每一层表示 了更详细的功能。图中任务的顺序是从左到右的 [控制十字路口交通灯 设置初始序列[检查时钟][读传感器]确定下一状态[修改状态 [定时查询每个传感器设置每个传感器字位] 控制十字路口交通灯问题的层次图 面向对象范式通过识别问题的实体来开发系统。本例涉及到的物理实体包括传感器、交通灯的控制器 注意,范式并不仅限于物理实体。如本例可识别的非物理实体是“lane”(车道)实体,它把传感器与特定 的交通灯联系起来。“lane”实体沟通了问题域和求解域之间的关系。 这些实体的抽象将成为系统的基本成分类,类的规格说明用来补充传统的需求说明的信息。面向对象 的需求说明用对象和分类把传统的系统功能需求与面向对象的操纵的对象描述融合在一起,它描述了问题 域的一部分。 上面识别的实体以及其他一些实体,如下图所示。这种图用实体关系图来表示实体和实体间的关系, 称这种图是问题的语义数据模型。它允许表示更宽范围的信息阶段的求解决域的不一致。 面向对象的设计范式采用建模的观点。在传统的软件生命周期中，分析和设计同开发问题域的模型紧 密相关。而在面向对象的生命周期中，保留了明显的独立结构。人们通过把问题域作为一系列相互作用的 实体可以构造出模型。实体的基于软件模型以及模型间的关系汇集成应用程序的基本结构。这样，在分析 阶段开发的信息就成为设计阶段的一个主要部分。这种极其自然的过渡是利用了“构件”的一致性。这种 一致性与结构化分析和结构化设计有着完全不同的观点。 由过程设计范式产生的构件是执行任务的过程，且与所提出的解决方法有关。 由面向对象范式产生的构件是实体描述，即类。许多这样的描述可直接地反映原始问题，尽管许多类 并不表示物理对象，但它们是概念上的实体，可以用问题域的术语来描述。 在传统语言中，程序是由传递参数的过程或函数的集合组成，每个过程处理它的参数，并有可能返回 一个值，因此执行单元（即过程）为中心。 在面向对象的语言中，世界被看作独立的对象的集合，相互之间通过过程（通常称作消息）进行通信。 对象是主动的，而过程（消息）是被动的，过程（消息）和它们的参数一起被从一个对象传递到另一个对 象。一个对象根据提交给它的请求（即过程过又称做方法）并基于这些过程（方法）进行行动，因此以数 据（即对象）为中心。由于抽象数据类型普遍地被应用于模拟应用领域内的实体，它们为程序的模块化提 供了一个自然的基础，其面向对象程序的机构可以非常相似于应用领域中的结构。 为了说明过程范式和面向对象范式的不同，下面以一个十字路口控制交通灯的软件系统为例子，其简 要的需求说明如下： 硬件包括一组传感器、交通灯和控制箱。软件读出传感器的状态，决定十字路口的新状态并且发出改 变交通灯的信号。另外，系统还有其他能力，如通过配置集测试循环灯的任选项。系统也可以被设置成缺 省状态。传感器指明在特殊车道上有无车辆。有几种类型的传感器，每种传感器的内部工作方式都不同。 然而所有的传感器都是中断驱动的，且一旦触发，就置传感器状态位。当决定要改变十字路口的状态时， 需要重新设置每个传感器。这个特殊的十字路口用两种类型的交通灯：一种是常见的三色灯，它用于直接 向前车道；另一种是四方位灯：红、黄、绿和转动箭头标志。每个灯都有当前状态、下一个状态和缺省状 态。控制器的硬件包括灯的开关、传感器的数据存储以及进行定时查询状态的时钟。控制器的软件读时钟， 定时查询传感器，确定下一个状态并且发信号改变交通灯。 过程范式通过考虑必须执行的一组任务来开发交通控制系统。如下图所示。层次结构中的每一层表示 了更详细的功能。图中任务的顺序是从左到右的。 面向对象范式通过识别问题的实体来开发系统。本例涉及到的物理实体包括传感器、交通灯的控制器。 注意，范式并不仅限于物理实体。如本例可识别的非物理实体是“lane”（车道）实体，它把传感器与特定 的交通灯联系起来。“lane”实体沟通了问题域和求解域之间的关系。 这些实体的抽象将成为系统的基本成分类，类的规格说明用来补充传统的需求说明的信息。面向对象 的需求说明用对象和分类把传统的系统功能需求与面向对象的操纵的对象描述融合在一起，它描述了问题 域的一部分。 上面识别的实体以及其他一些实体，如下图所示。这种图用实体关系图来表示实体和实体间的关系， 称这种图是问题的语义数据模型。它允许表示更宽范围的信息