系统规划---方案的制订和改进

 方案的制订和改进

    通过在问题定义和归结模型阶段的工作，已经分析并定义了与系统开发目标相关的各种模型、分析出了系统的功能清单、性能要求等，解释了“系统目标是什么”的问题。在系统方案阶段，主要完成的工作则是解释“系统如何实现”的问题。

    系统方案制订的最主要内容，包括以下几个方面。

    1．确定软件架构

    在问题定义阶段得到的软件概念模型使用各种工具定义了项目的开发目标。在系统方案制订阶段才开始真正考虑如何去实现软件。其中最重要的工作，就是制定系统的实现架构。

    系统的实现架构与一些很具体的方面相关：

    （1）分析模型的结构。例如，采用结构化分析方法得到的功能分解体系，或面向对象的类和“对象－关系图”、“对象－行为图”。

    （2）一些对应于系统目标的最基本、最重要的实现要素。例如，关键的用例、最主要的控制类、对象组织的模式、常用和最关键的实现算法模型等。这些实现要素对应于系统目标实现最重要的场景，表示了整个系统最主要的控制流程和实现机制。

    （3）特性和要点的解释。这些附加的内容解释系统的一些特性、服务等是如何实现的。

    2．确定实现的各种关键性要素和实现手段关键性的实现要素通常包括：

• 关键的用例、最主要的控制类、功能和服务的首要组织方式（例如网站首页）；

• 对象的组织模式；

• 常用和最关键的实现算法模型。关键性的实现手段通常包括：

• 选定基础计算平台，如操作系统、数据库、Web服务器、中间件平台等；

• 选定开发工具和开发环境，如计算机语言、构件库、工具软件等。

    3.归结目标到最适合的计算体系

    通常，提供开发工具和开发环境的组织总是有一些标准的计算体系可以选择（例如，.NET 和J2EE 等），因此对于大多数系统开发项目来说，比较各种标准计算体系与预期目标之间的匹配程度即可选定计算体系。选择标准的计算体系去实现系统可以忽略大多数基础平台和底层支撑技术的实现问题，从而大大提高系统的质量、降低开发风险和成本。开发人员常根据基础平台的系统实现能力支持，公司或项目组在特定实现平台上的技术积累，甚至技术的“先进性”或流行程度这样的因素去选择系统的实现技术体系。

    在另一些情况下，出于各种诸如用户投资力度，与用户现有的 IT 设施保持一致性、兼容性、扩展性及未来维护的能力等因素，系统的基础平台很可能在项目的论证阶段就已经被确定，如操作系统、数据库系统、Web 服务器、开发工具或开发环境等。在这种情况下，系统的实现体系实际上已经确定。

    通过同时参考系统概念模型，将前面得到的系统功能清单和系统实现的各种关键要素整理并分类，然后与现有的技术、标准的实现体系进行比较和匹配，就可以将系统概念模型定义的系统目标，进一步映射到真正可计算、可实现的系统架构上。这个过程可以理解为一种不断归结、比较并匹配的过程。

    进行匹配的过程常常是一种双向的选择和探究过程，一方面拿出一个系统目标中的功能或实现要素，询问：这部分功能属于表示层、业务逻辑、还是数据服务？另一方面，也研究标准计算体系提供的功能，例如：放在业务逻辑层合适吗？技术人员具有这方面的开发经验积累吗？甚至是标准构件或服务可用吗？

    各种标准的计算体系可能很复杂，但通常总是包括一些逻辑上的划分，例如，.NET 体系将应用系统理解为三个层次，表示层、事务逻辑层和数据服务层构成。

    （1）表示层：用户的界面部分。例如，单一应用程序的用户界面、C/S 计算模式的客户端、B/S 模式在浏览器中运行的HTML、DHTML、Scripting、JavaApplet、ActiveX 等。

    （2）事务逻辑层：负责处理表示层的应用请求，完成商务逻辑的计算任务，并将处理结果返回给用户。事务逻辑处理层是将原先置于客户端的事务逻辑分离出来，集中置于服务器部分，为所有用户共享。事务逻辑层是整个应用的核心部分，而组件对象模型 COM 则相当于其心脏。事务逻辑层通过 COM 进行事务处理，并由 IIS（Internet Information Server， Internet 信息服务器）和 MTS（Microsoft Transaction Server，微软事务处理服务器）为各种应用组件提供完善的管理。

    （3）数据服务层：为应用提供数据来源。和以往的两层架构不同，数据库不再和每个活动客户保持一个连接，而是若干个客户通过应用逻辑组件共享数据库的连接，从而减少连接次数，提高数据服务器的性能和安全性。

    相同的三层计算模式，也会表现为不同的实现方式。例如，表示层可能是单一应用系统的用户界面、C/S 计算的客户端、或 B/S 计算的 Web 页面和元素；事务逻辑层可能是单一应用系统的程序模块、C/S 的服务器端服务、B/S 应用服务器中的业务脚本或业务对象；当利用类似存储过程来实现数据操作逻辑的时候，存储过程也被看作事务逻辑层的一部分，但如果利用 ADO（ActiveX Data Object，ActiveX 数据对象）这样的数据访问组件访问数据时，ADO 和后台的数据库系统及数据库的逻辑则被看作数据服务层的一部分。

    在必要的情况下，某个层次还可能进一步细分，例如，使用面向对象设计方法的系统常常会将事务逻辑层划分为基本的计算对象、业务对象及黏合业务对象实现功能的脚本 “胶水”或一些控制类。

    不同标准的计算体系的逻辑划分，甚至同一个计算体系的不同版本，通常也不会套用这样的三层分类方式，但却有类似之处。图 7-2 表示了利用 JSP 开发 Web 程序的计算模式。 JSP 页面构成了前端的表示层，EJB 构成了业务逻辑层，JDBC（Java DataBase Connectivity， Java 数据库连接）和后台的数据库构成了数据服务层。

    对于小规模的网站系统，开发者可能直接在 JSP 页面中书写所有的应用逻辑脚本，这样业务逻辑层就和表示层合并了，而对于使用 J2EE 体系的开发人员来说，利用 EJB 的容器、对象操作语言等机制直接实现了对象级的接口，开发人员直接在业务逻辑层去构思应用，JDBC 和后台数据库系统的数据服务层被隐含在 J2EE 的平台机制内，在更高的抽象级别上被屏蔽。

    因此，归结系统实现要素到计算体系的时候，要点在于理解各种计算体系的大致分层和构成，比较实现要素的目标和实现手段之间的“适合程度”，而不是生搬硬套某种实现机制，或盲目追求某种“流行的”或“先进的”算体系。

    系统方案制订后，需要根据有关标准进行评价，找出不符合实际的地方，然后进行改进。