PMS-DC用于开发专用DSS中的问题管理系统或基于问题管理的DSS，为使PMS-DC能够比较方便地应用于这些DSS及PMS的开发中，其本身开发环境的选择及其在专用DSS中的实施部署方案也是非常重要的。
5.6.1 PMS-DC的开发环境
实际上，任何一种面向对象的软件集成开发环境（IDE）都可以用来开发PMS-DC，但由于PMS-DC及i-GIDSSG本身并不是一种通用或独立的DSS，而只是开发DSS的工具或平台，它们必须嵌入到通用的IDE中，通过IDE调用这些组件中的对象、类或控件才能开发出专用DSS所需的各种功能模块，因此，组件应该尽可能对更多的IDE有良好的适应性，而不是只能嵌入到一种专门的IDE中使其应用环境受到极大的限制。这就要求PMS-DC及i-GIDSSG所用的开发环境本身要具有应用的广泛性。
目前，被广泛应用的IDE包括Microsoft Stídio。NET、Bor1and JBíi1der、Bor1and C Bíi1der、Bor1and De1phi、IBM WebSphere Stídio App1ication Deve1oper、BEA Visía1 Cafe、Orac1e JDeve1oper、Sín Forto for Java、PowerBíi1der等。虽然每种IDE都有自己的体系结构、特色和适用领域，但基本上分属于两大阵营：Microsoft公司的。NET和SUN公司的J2EE。其中。NET是由Microsoft公司于2000年6月推出的一种软件开发平台，它对Microsoft早期的开发平台（VB、VC等）作了重大的改进，可以让不同程序设计语言创建的应用程序相互通信，也可以让开发者创建基于Web的应用程序，这些应用程序能够发布到多种不同的设备上（如台式机、笔记本、嵌入式设备、手持设备等）。Microsoft的。NET为利用In-ternet和Web进行软件的开发、设计和使用开辟了广阔的新前景。NET策略的一个重要方面是它的跨开发平台性，它不要求程序员使用唯一的一种程序设计语言，程序员可以将多种与。NET兼容的语言结合起来开发。NET应用程序；多个程序员可以共同参与同一个软件项目，每个人可以使用自己最熟悉的。NET语言（如C 、C、Basic或其他语言）来编写代码。
而J2EE（Java 2 p1atform，enterprise edition）是SUN公司定义的一个开发分布式企业级应用的规范。它提供了一个多层次的分布式应用模型和一系列开发技术规范。多层次分布式应用模型是指根据功能把应用逻辑分成多个层次，每个层次支持相应的服务器和组件，组件在分布式服务器的组件容器中运行（如serv1et组件在serv1et容器上运行，EJB组件在EJB容器上运行），容器间通过相关的协议进行通信，实现组件间的相互调用。遵从这个规范的开发者将得到行业的广泛支持，使企业级应用的开发变得简单、快速。
有关。NET和J2EE的比较分析比较多，根据我们的总结归纳，两者的相似性主要在于：
（1）。NET和J2EE都属于企业级开发平台，并且都可广泛应用于WEB开发领域。
（2）Windows。NET Framework和J2EE都使用了一种托管的运行时环境，都将源代码转换为一种中间语言，然后将其编译为本地的可执行代码。两种平台的开发语言环境都支持碎片整理、动态类加载和异常处理等功能。
（3）。NET和J2EE都倡导和支持面向对象的组件开发方式，也提供基础类库来执行I/O、XML处理、文本操作、网页脚本编写和带有连接池的数据库接入等。
（4）两者都经过特定的销售商进行发布。
（5）Windows。NET Framework和基于J2EE的产品都可以同第三方的产品一起工作。例如，数据库访问方面，。NET和基于J2EE的应用程序能访问储存在Microsoft的SQL、IBM的DB2、Orac1e、Informix、Sybase等服务器里面的数据。
两者的主要差别在于：
（1）在原理方面，J2EE是一个单一语言的平台，跨操作系统平台移植比较方便，但开发者必须接受关于Java的培训。Mi-crosoft提供的。NET属于多语言平台，只能用于Windows系列操作系统，但可跨开发工具平台，前提是支持。NET框架。开发人员一般无须接受一种新语言的重新训练。
（2）在体系结构方面，NET包括代码、产品、工具和构架，利用网络上全部的计算资源（包括设备、个人电脑和服务器等）。NET能使所有这些设备经过标准通信协议全部连接在一起，即所谓“XML web服务”。NET模型是广泛的分布式计算，它和许多代码互相通信并交换信息。而J2EE是面向服务器的模型，基于J2EE的产品只支持服务器端的应用程序。
（3）在编程模型的一致性方面，Windows。NET Framework提供了一个跨服务器、PC和其他设备的一致的、面向组件的模型。而J2EE提供EJB作为服务器端的组件模型，为客户端或是本地组件建立开放的完全用Java编写的API，为用户界面提供serv1et，也为移动设备提供另一种不同的模型。Microsoft的NET编程模型与Java平台相比较，在各种服务器和客户端上有更好的一致性。J2SE是基于开放的完全用Java编写的API，而J2EE则是基于Ja-va serv1et和EJB。
（4）在功能方面：
①Windows。NET Framework提供一个能识别版本的类加载器，因此开发者能确保他们开发的应用程序在一部分代码已经更新的情况下仍能运行。而Java和J2EE没有版本识别的类加载器，开发者和管理员不能完全保证代码被执行时是正确的。
②Windows。NET Framework显示了语言层面上的类属性，这使得编程更加简单。例如，在源代码中只用一个简单的属性就能把。NET组件标识为处理模式。而Java不显示语言层上的类属性。③。NET支持分离数据访问，主要用于在移动设备或偶尔联网的场合里运行的应用程序。数据能被脱机操作，接着再与起始数据重新同步。而不论是J2EE还是J2SE，现阶段都不支持分离数据访问，需要这项功能的J2EE开发者必须自己写“衔接”代码。
④为建立基于网络的用户界面，Windows。NET Framework为ASP。NET提供基于事件的模型，这些模型类似于Visía1 Basic中的智能客户端模型，它们使得建立、发布和维护一个基于网络的用户界面变得更加容易。而J2EE在JSP中不支持这样的模型，虽然有一些第三方的扩展程序部分弥补了这些功能，但是它们的实用性和简便性都不如ASP。NET。
（5）在简便性方面：
①从外部元数据的配置来看：对于J2EE，配置是由部署描述信息获得的XML格式的文件，它们和实际执行的商用逻辑代码有明显区别。这种方法有两个主要问题：第一，对于特定类的元数据，有些代码中的改变和元数据中的改变是相互依赖的，两个独立文件的同步性要求有可能产生错误。第二，对于应用程序层的元数据，在J2EE中缺乏从一个程序继承元数据到另一个程序的途径。与J2EE不同，Windows的。NET Framework包括了这个功能，使得可以在源代码中直接向类添加属性，从而不会产生第一个问题。Windows。NET中的元数据模型允许客户自己添加扩展程序，开发者可以编写和使用自己的属性，为程序继承元数据到另一个程序提供了途径。
②从数据库连接池的管理来看：在Windows。NET Framework中，是根据需要自动建立和管理这些池的。而在J2EE模型中，连接池必须被明确配置和管理。
③从XML Web服务上看：在。NET中建立一个XML Web服务就像在类中添加一个属性那样简单。有些基于J2EE的产品也想在Java中模拟这个功能。NET提供更简单的方法来建立和使用可由双方共同操作的XML Web服务。
④从应用程序部署来看：在。NET中，要部署一个应用程序，管理员只需要拷贝文件。而在J2EE中，管理员必须将很多编译文件和JAR、WAR以及EAR绑定，然后在一个特定的服务器部署工具中解开并运行它们，接着拷贝结果档案，这使得应用程序的部署较为复杂。
通过对。NET和J2EE的比较分析，我们认为在DSS组件的功能开发方面，两者均能满足要求。但在使用的简便性、开发出的组件对常用开发平台（IDE）的适应性和应用的广泛性方面，。NET平台占有一定的优势。为此，我们选用Microsoft的VS。NET作为PMS-DC乃至整个i-GIDSSG的开发平台。
5.6.2 PMS-DC的实现与部署
5.6.2.1 PMS-DC的实现
具体而言，PMS-DC采用VS。NET中的VB。NET来实现，主要应用于Windows系列操作系统下DSS或含有问题处理功能的信息系统的开发，分析和识别问题所需的资源——即问题知识（包括问题类型知识）和词库、语料库等，以及求解问题所需的资源（包括模型、知识、数据）均以数据的形式存储在数据库中，并通过DATABASE组件进行调用，以使i-GIDSSG对各决策资源在物理存储结构上进行统一管理。
此外，由于i-GIDSSG的MMS-DC和KMS-DC已先行开发出来，且MMS-DC在没有PMS-DC的情况下自带了问题求解对象（它采用的是由专家用户人工识别问题的方法），而KMS-DC中也未包含智能识别问题所需的规则和数据类知识，为此，在开发PMS-DC时还需对原来的MMS-DC和KMS-DC进行适当改造，将MMS-DC中所包含的问题求解模块分离出来归入PMS-DC中，同时将问题知识库加入KMS-DC，以实现PMS-DC对问题求解的统一控制，以及PMS-DC与MMS-DC和KMS-DC的协调运行。
5.6.2.2 PMS-DC的部署
由于PMS-DC本身只是一个问题管理子系统的开发组件，所以不能构成一个可独立运行的DSS。一个问题驱动的DSS或者带有辅助决策功能的MIS如果用i-GIDSSG进行开发，它至少需要其中的PMS-DC、MMS-DC、KMS-DC和DMS-DC四个组件，同时需要模型库、知识库、数据库和算法库存储所需的决策资源以及调用这些资源的接口组件。为了保持i-GIDSSG的灵活性，我们允许i-GIDSSG中的组件、资源库及其资源接口针对DSS的需求采用不同的部署方案：
1.C/S模式系统
如果用i-GIDSSG开发的实际DSS采用C/S工作模式，对于PMS-DC的组件部署，可以根据实际DSS的需要采用两种不同的部署方案：
（1）两层结构部署：即将PMS-DC与MMS-DC、KMS-DC和DMS-DC及资源调用组件一起部署在客户端，而将包含问题知识库、词库、语料库在内的知识库与模型库、算法库、业务数据库一起部署在服务器端，即可构成客户——服务器两层结构的DSS。
（2）三层结构部署：将PMS-DC与MMS-DC、KMS-DC和DMS-DC部署在客户端，将模型库、知识库、算法库、业务数据库等部署在数据库服务器端，而Database、Metadata（MMS-DC中的元数据管理组件）等接口层组件部署在应用服务器上，即可构成客户——应用服务器——数据库服务器三层结构的DSS。这种部署结构可以比较方便地支持DSS的Internet应用，即将Database组件封装成一个WebService组件，并将它部署在Web服务器（Web server）上，就可实现一个基于Web的DSS。
2.B/S模式系统
如果用i-GIDSSG开发的实际DSS采用B/S工作模式，则需要将PMS-DC与MMS-DC、KMS-DC和DMS-DC及资源调用组件部署在Web服务器上，将模型库、知识库、算法库、业务数据库等部署在数据库服务器上，构成浏览器——Web服务器——数据库服务器三层结构的DSS。也可以采用类似C/S模式的三层结构部署，将接口层组件部署在Web server上，但此时需将PMS-DC与MMS-DC、KMS-DC和DMS-DC改造成浏览器组件，相比之下，没有基于C/S模式的三层结构部署方案反而更方便。
