<<Interface>> TP Primitive (from Topology <Interface>> TP Edge TP Node (from Topo OD) /Orientation Node rose <<ValueType>> +side TP_-DirectedEdge 0. TP- Object: dimension= 1 TP_Object: position type = GM_Curve 图16-3:用UML表达的线几何体类以及和其它类的关系( OpenGIS Consortium) 1.4开发过程模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。软件开发模型能够清晰、 直观的表达软件开发过程,明确规定要完成的主要活动和任务,可以作为软件项目工作的基 础 随着软件工程了实践,相继提出了一系列开发模型,如下: 1.4.1瀑布模型 在瀑布模型中,将各项活动规定为依照固定顺序连接的若干阶段工作,形如瀑布流水(图 16-4),瀑布模型的特征是:每一阶段接受上一阶段的工作结果作为输入:其工作输出传入 下一阶段:每一阶段工作都要进行评审,得到确认后,才能继续下阶段工作。瀑布模型较好 地支持结构化软件开发,但是缺乏灵活性,无法通过软件开发活动澄清本来不够确切的需求
图 16-3：用 UML 表达的线几何体类以及和其它类的关系（OpenGIS Consortium）。 1．4 开发过程模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。软件开发模型能够清晰、 直观的表达软件开发过程，明确规定要完成的主要活动和任务，可以作为软件项目工作的基 础。 随着软件工程了实践，相继提出了一系列开发模型，如下： 1．4．1 瀑布模型 在瀑布模型中，将各项活动规定为依照固定顺序连接的若干阶段工作，形如瀑布流水（图 16-4），瀑布模型的特征是：每一阶段接受上一阶段的工作结果作为输入；其工作输出传入 下一阶段；每一阶段工作都要进行评审，得到确认后，才能继续下阶段工作。瀑布模型较好 地支持结构化软件开发，但是缺乏灵活性，无法通过软件开发活动澄清本来不够确切的需求
系统需求 软件需求 需求分析 设计 编码 测试 运仃 图16-4:瀑布模型 1.4.2演化模型 演化模型主要针对事先不能完整定义需求的软件开发。用户可以先给出核心需求,当开 发人员将核心需求实现后,用户提出反馈意见,以支持系统的最终设计和实现。 1.4.3螺旋模型 螺旋模型是在瀑布模型以及演化模型的基础上,加入风险分析所建立的模型。在螺旋模 型每一次演化的过程中,都经历以下四个方面的活动: 1)制定计划—一确定软件目标,选定实施方案,弄清项目开发的限制条件。 2)风险分析—一分析所选方案,考虑如何识别和消除风险。 3)实施工程一一实施软件开发。 4)客户评估一一评价开发工作,提出修正建议。 每一次演化都开发出更为完善的一个新的软件版本,形成了螺旋模型的一圈。螺旋模型 借助于原型,获取用户需求,进行软件开发的风险分析,对于大型软件的开发,是颇为实际 的方法。 1.4.4喷泉模型 喷泉模型体现了软件开发过程中所固有的迭代和无间隙的特征(图16-5)。喷泉模型表 明了软件刻画活动需要多次重复。例如,在编码之前,再次进行分析和设计,并添加有关功 能,使系统得以演化。同时,该模型还表明活动之间没有明显的间隙,例如在分析和设计之 间没有明确的界限 在面向对象技术中,由于对象概念的引入,使分析、设计、实现之间的表达连贯而一致
系统需求 软件需求 需求分析 设计 编码 测试 运行 图 16-4：瀑布模型 1．4．2 演化模型 演化模型主要针对事先不能完整定义需求的软件开发。用户可以先给出核心需求，当开 发人员将核心需求实现后，用户提出反馈意见，以支持系统的最终设计和实现。 1．4．3 螺旋模型 螺旋模型是在瀑布模型以及演化模型的基础上，加入风险分析所建立的模型。在螺旋模 型每一次演化的过程中，都经历以下四个方面的活动： 1）制定计划——确定软件目标，选定实施方案，弄清项目开发的限制条件。 2）风险分析——分析所选方案，考虑如何识别和消除风险。 3）实施工程——实施软件开发。 4）客户评估——评价开发工作，提出修正建议。 每一次演化都开发出更为完善的一个新的软件版本，形成了螺旋模型的一圈。螺旋模型 借助于原型，获取用户需求，进行软件开发的风险分析，对于大型软件的开发，是颇为实际 的方法。 1．4．4 喷泉模型 喷泉模型体现了软件开发过程中所固有的迭代和无间隙的特征（图 16-5）。喷泉模型表 明了软件刻画活动需要多次重复。例如，在编码之前，再次进行分析和设计，并添加有关功 能，使系统得以演化。同时，该模型还表明活动之间没有明显的间隙，例如在分析和设计之 间没有明确的界限。 在面向对象技术中，由于对象概念的引入，使分析、设计、实现之间的表达连贯而一致
所以,喷泉模型主要用于支持面向对象开发过程。 演化 维护 确认 实现 设计 分析 图16-5:喷泉模型 目前,随着面向对象技术的发展和UML建模语言的成熟,统一软件开发过程(USDP, Unified Software Development Process被提出以指导软件开发,它是一个用例( use case)驱 动的、体系结构为中心的、增量迭代的开发过程模型,适用于利用面向对象技术进行软件开 发 2.G|S领域的体系结构和构件 按照应用目的,地理信息系统可以分为区域地理信息系统、专题地理信息系统以及地理 信息系统工具,它们共同组成了GS领域( Domain)。所谓领域,是指共享某种功能性 ( Functionality))的系统或应用程序的集合,换言之,领域表现了一组应用系统共性的方面。对 于地理信息系统而言,其共享的功能就是对空间数据输入、管理、分析和表现,而这恰好是 地理信息系统工具所提供的功能(图16-6) 具体,专用 应用系统区域GS|专题GS 领域 地理信息系统工具 操作系统 抽象,通用 图16-6:GIS领域 与具体应用领域相对应,对于领域,可以实施领域工程,得到领域模型,并建立领域特 定的软件体系结构(DSSA, Domain- Specific Software Architecture)。DSSA是能够适应领域 中多个系统的需求的一个高层次的设计,在开发具体应用系统时,可以利用DSSA将领域 构件( Component)连接和组织起来,以支持软件复用,提高软件开发的效率和质量。 对于地理信息系统,实施领域工程,得到DSSA,不仅可以指导具体应用系统的开发 而且DSSA可以直接作为地理信息系统工具的软件体系结构。 地理信息系统的核心功能包括空间数据的输入、管理、分析以及表现,并且这些功能形
所以，喷泉模型主要用于支持面向对象开发过程。 演化 维护 确认 实现 设计 分析 图 16-5：喷泉模型 目前，随着面向对象技术的发展和 UML 建模语言的成熟，统一软件开发过程(USDP， Unified Software Development Process)被提出以指导软件开发，它是一个用例（use case）驱 动的、体系结构为中心的、增量迭代的开发过程模型，适用于利用面向对象技术进行软件开 发。 2．GIS 领域的体系结构和构件 按照应用目的，地理信息系统可以分为区域地理信息系统、专题地理信息系统以及地理 信息系统工具，它们共同组成了 GIS 领域（Domain）。所谓领域，是指共享某种功能性 (Functionality)的系统或应用程序的集合，换言之，领域表现了一组应用系统共性的方面。对 于地理信息系统而言，其共享的功能就是对空间数据输入、管理、分析和表现，而这恰好是 地理信息系统工具所提供的功能（图 16-6）。 操作系统 地理信息系统工具 区域 GIS 专题 GIS 领域 应用系统 具体，专用 抽象，通用 图 16-6：GIS 领域 与具体应用领域相对应，对于领域，可以实施领域工程，得到领域模型，并建立领域特 定的软件体系结构（DSSA, Domain-Specific Software Architecture）。DSSA 是能够适应领域 中多个系统的需求的一个高层次的设计，在开发具体应用系统时，可以利用 DSSA 将领域 构件（Component）连接和组织起来，以支持软件复用，提高软件开发的效率和质量。 对于地理信息系统，实施领域工程，得到 DSSA，不仅可以指导具体应用系统的开发， 而且 DSSA 可以直接作为地理信息系统工具的软件体系结构。 地理信息系统的核心功能包括空间数据的输入、管理、分析以及表现，并且这些功能形
成了一个比较完全的数据处理流程,此外考虑到与遥感以及全球定位系统的结合,形成如下 的系统结构(图16-7)。该视图更多地体现了地理信息系统的业务逻辑,为了适用于具体的 应用系统,该结构可以被特化一一类似于面向对象中,从父类派生一个子类一一形成更加具 体的体系结构。 依赖于DSSA,可以将构件组装起来,形成具体的应用系统,基于构件的技术已经成为 软件开发技术的主流,它从面向对象技术发展而来,是开发高效、低成本程序的重要实现途 径 为了能够通过组装以构造系统,构件必须能够互相合作,即具有互操作性,这是通过定 义构件的接口规范来实现的。对于构件而言,除了互操作性之外,还要支持分布式的网络计 算,即构件的互操作可以是基于异种平台的,其实现需要分布计算平台(DCP- Distributed Computing Paltform)的支持。 数据录入 数据官理 查询分析 遥感数据转入 数据规范化处理空间炸据库 空间模型 GPS数据转入 数据表现 图16-7:GIS领域体系结构:一个工作流视图 目前存在着多种构件技术标准,其中OMG(对象管理组织)的 CORBA(公共请求对 象代理体系结构- Common object request broker architecture)和 Microsoft的 OLE/COM/DCOM 技术是其中两个主要的、被广泛采用的标准 COBRA定义了一个带有开放软总线的分布式结构,在这一结构中,来自不同厂商、运 行于不同操作系统上的对象,能够进行互操作。 CORBA对象的互相通信通过对象请求代理 (ORB, Object Request Broker)为中介,可以在多种流行网络通信协议上实现。接口描述 语言(IDL, Interface Description Language)用于描述对象接口,它与语言无关,使得所有 CORBA对象以一致的方式被描述。 Microsoft的DCOM(分布式对象构件模型, Distributed Component Object Model)技术 是对原有的COM技术的扩展,以支持在网络上不同计算机的对象之间的通信。COM定义 了接口的二进制标准,包括接口交互、管理对象及其资源等等。而DCOM通过增加网络协 议的支持,使得对象可以通过网络互操作。DCOM技术很好的支持复用,位置独立,可扩 展等,并且其执行性能较好,目前被基于 Windows平台的软件开发商所广泛支持
成了一个比较完全的数据处理流程，此外考虑到与遥感以及全球定位系统的结合，形成如下 的系统结构（图 16-7）。该视图更多地体现了地理信息系统的业务逻辑，为了适用于具体的 应用系统，该结构可以被特化——类似于面向对象中，从父类派生一个子类——形成更加具 体的体系结构。 依赖于 DSSA，可以将构件组装起来，形成具体的应用系统，基于构件的技术已经成为 软件开发技术的主流，它从面向对象技术发展而来，是开发高效、低成本程序的重要实现途 径。 为了能够通过组装以构造系统，构件必须能够互相合作，即具有互操作性，这是通过定 义构件的接口规范来实现的。对于构件而言，除了互操作性之外，还要支持分布式的网络计 算，即构件的互操作可以是基于异种平台的，其实现需要分布计算平台（DCP-Distributed Computing Paltform）的支持。 图 16-7：GIS 领域体系结构：一个工作流视图 目前存在着多种构件技术标准，其中 OMG（对象管理组织）的 CORBA（公共请求对 象代理体系结构-Common object request broker architecture）和 Microsoft 的 OLE/COM/DCOM 技术是其中两个主要的、被广泛采用的标准。 COBRA 定义了一个带有开放软总线的分布式结构，在这一结构中，来自不同厂商、运 行于不同操作系统上的对象，能够进行互操作。CORBA 对象的互相通信通过对象请求代理 （ORB，Object Request Broker）为中介，可以在多种流行网络通信协议上实现。接口描述 语言（IDL，Interface Description Language）用于描述对象接口，它与语言无关，使得所有 CORBA 对象以一致的方式被描述。 Microsoft 的 DCOM（分布式对象构件模型，Distributed Component Object Model）技术 是对原有的 COM 技术的扩展，以支持在网络上不同计算机的对象之间的通信。COM 定义 了接口的二进制标准，包括接口交互、管理对象及其资源等等。而 DCOM 通过增加网络协 议的支持，使得对象可以通过网络互操作。DCOM 技术很好的支持复用，位置独立，可扩 展等，并且其执行性能较好，目前被基于 Windows 平台的软件开发商所广泛支持