搜寻

< 返回

物件导向法程序手册

1. 目的

本文件的目的是说明物件导向法的程序结构，及详述在进行物件导向法规划时所涉及的程序。

2. 范围

本手册的读者对象是从事物件导向法计划的工作人员。它是以物件导向法程序的各个阶段作为文件的结构而编写。就物件导向法每个阶段的各个工作项目而编写的文件，均会载列以下的资讯：

目的
描述
必要条件
成品
指引
技巧
细分工作项目

为方便参考，部分内容摘录自手册全文，并在下文加以概述。

3. 物件导向法概览

物件导向法是一个系统发展方法，鼓励和协助用户把电脑系统的软件组件再次使用。采用这个方法后，电脑系统能够以组件作为基础进行发展，有助用户有效地把现有的组件再次使用，及协助把系统的组件与其他系统共用。采用物件导向法可提高生产力、减少维修费用和获得更佳品质。

物件导向法生命周期由六个阶段组成。这些阶段计有：

业务规划阶段；
业务体系结构定义阶段；
技术体系结构定义阶段；
递增交付规划阶段；
递增设计和建设阶段；及
设置阶段。

3.1 业务规划

在业务规划阶段，业务的管方和用户通常会举行一系列的会议和研讨会。这些会议会制定彼此达成共识的目标、范围和用户需求，以及开始发展程序及评估发展计划的可行性。

业务规划的工作项目是：

（a）审查现有环境及制定目标

透过制定系统的目标，计划推行小组成员和业务用户可以清楚了解计划的界限、范围、相关费用和好处。透过审查以往的研究结果、现有系统和业务的使命，可制定业务方案的主要目标。

（b）确定整体需求

功能需求指系统将提供的功能。这些需求会编写为需求目录，编写方式与在稍后的工作项目内用例载列需求详情的高层次方式相同。

（c）业务程序模型

业务程序模型是与用户共同发展的。这模型界定了业务范围，而建议的业务方案会在这范围内予以推行，最后投入运作。为与执行业务程序的有关人员举办用户研讨会，以讨论、了解及编写所涉及的事件及程序。业务程序模型会展示「将予采用」的程序模型。任何重新设计程序的工作，应该在执行目前这工作项目之前完成。

（d）分析用例

在组件和物件发展方面，用例是电脑系统发展的主要驱动工具。在业务程序模型所说明的程序界定了业务系统，但这些程序并没有说明电脑系统需求。业务系统与电脑系统需求之间其实互有关连，因此，可能会有一个程序（通常是企业业务程序）是与用例有连结的。这种连结关系提供了电脑发展系统的记录和结构方面的资料。

业务方案的功能需求会载列在用例内。每个用例说明了系统的一个能够为用户提供价值的使用方式。每项功能需求最少会作为一个用例或在最少一个用例内列出。此外，用例图也会包含与用例业务方案有关的系统执行因素及系统活动者。

（e）开展业务类别模型

这工作项目最好在完成制定用例模型后才开始，因为系统分析人员在制定用例模型时会对计划领域的知识大幅增加。

这方面的重点需放在于基本的业务类别，即与计划领域有关的跟物件对应的类别，因为假设这些类别一般会成为资料模型的一个相关实体，并且因而能够充当一个资料模型规模的基础。这个资料模型可能包含更多的实体，例如：体现多方面之间的相互关系。

（f）确定可再次使用的组件

这工作项目会与上一个项目同时进行，可避免会对已经存在的现有组件制定类别模型。在这个阶段拟定再次使用系统组件的计划，是以组件为本进行发展的一个重要基础。

（g）完成可行性研究

如采用结合可行性研究／系统分析和设计阶段的方法，便无需进行这项工作。

这工作项目会按照预算的成本和推行的期间完成可行性研究。为资料库规模的目的，在完成业务体系结构定义阶段的「把业务类别与实体配对」的工作项目后，会制定一个所需系统逻辑资料模型。

3.2 业务体系结构定义

业务体系结构定义的重点在于加深了解用户的需要，及界定一个会符合需要的方案。

在用例中指明的系统需求会予以分析。需用以达成系统功能的组件服务会加以确定。组件服务会透过业务类别的仔细设计和组件之间的合作得以提供。

为从以组件为本的发展中获得好处，在可重用组件所获得的服务和这些服务之间互相依赖的关系会加以确定。在进行上述活动时，可同时制定屏幕及报告的原型。

业务体系结构定义的工作项目是：

（a）检讨业务规划成品

如在业务规划阶段后业务需求有所改变，便需进行这工作项目。可能出现的改变通常视乎业务规划阶段完结后和业务体系结构定义阶段开始前的期间而定。这工作项目对于已进行可行性研究（或业务规划阶段）作为一个独立阶段的计划尤其重要。

（b）原型用户界面

屏幕原型是一种核实用例的简报及相关资料输入／输出的出色技术，而用户也会获得鼓励参与这项工作，令所完成的方案是一个彼此接受的方案。用户研讨会是一个发展原型的有效机制。

（c）确定待用组件

这工作项目是界定系统所包含的业务体系结构的元素。经确定的组件是逻辑业务组件，并会为此界定组件服务。

组件的确定将主要取决于与业务类别的（静态）联系。待用组件需在较后的工作项目进行时由（动态）交互模型加以核实，因此不会在这个阶段作出定论。

（d）组件交互模型

业务组件交互模型与制定原型的工作同时进行，并在确定待用组件之后完成。有关的组件服务会根据用例的功能界定。

这项工作需与「业务类别交互模型」的工作同时进行，因为可加深对组件功能的了解。

（e）业务类别交互模型

物件之间进行交互产生系统的职能。编制业务类别物件顺序图可界定业务类别的各项运作活动。有关的交互可协助分析人员分析业务类别的动态职能。在这个阶段，制定模型的工作主要是制定组件内部的模型。

（f）把业务类别与实体配对

如果使用物件资料库管理系统，类别模型结构和物件资料库管理系统结构之间应该可直接进行配对，但对于关系资料库而言则并不是这样。例如，该类资料库并不支援继承结构。关系表格也需要基本和外在的关键码，而类别模型则没有提供这些关键码。如使用物件资料库管理系统，必须执行物件的关系转换，以编制逻辑资料模型。

（g）完成交互模型

前两个工作项目会产生大量的物件顺序图供计划推行小组使用。该等物件顺序图的完整性、一贯性和详细程度必须先予以查核，然后该模型才可进入递增设计和建设阶段。通常可在这阶段加入更多的细节。

3.3 技术体系结构定义

技术体系结构定义的活动会与业务体系结构定义阶段同时进行。业务体系结构定义的重点在于业务需求，而技术体系结构定义阶段郄侧重技术和体系结构两方面。

技术体系结构定义的工作项目是：

（a）确认技术需求

新业务及技术需求既然已经确定，它们对现有系统的基础建设的影响必须加以确定。如没有该等基础建设，则那些应由基础建设提供的服务便须加以确定，分析和推行。

（b）选择业界标准方案

就业务功能而言，由个别机构发展的应用系统可能是独特的，但从技术体系结构的观点来说，它们并非独特的系统。要成功发展一个应用系统，关键之一是采用业界标准方案、架构和最佳作业实务（如可能）。要选择正确，必须把对服务的技术需求作出比较；该等服务是由经考虑的体系结构的架构／方案所提供。在选择过程中，应考虑机构采用的标准。

（c）说明技术系统体系结构

技术系统体系结构对工具、环境和支援应用系统的软件方案加以界定。为使发展系统的人员有效地共同工作，所选择的工具须能以整合及一致的方式支援所有不同的技术，而这些技术均是发展该类应用系统所需要的。这项活动集中于把适当的工具和操作平台进行配对；该等工具和操作平台均适合系统的技术需求和机构的标准。

（d）界定技术应用系统体系结构

在进行任何设计和发展活动前，最基本的需求是设立参考模型，供分析人员和开发人员作为方案／组件设计的基础。技术应用系统体系结构界定如何按职责发展软件，及对系统内各层职责提供清楚的区分。该等在体系结构层之内的职责称为「版型」，代表该物件或技术的名称和目的；「版型」的作用是推行具体的体系结构职责。此外，在推行前先了解将会使用那些技术以处理不同的版型（例如：EJB、Servlets及JSP等），这点亦非常重要。

（e）设计技术服务及模式

在技术系统体系结构的期间内，由于并非所有的技术需求均得到标准方案提供的服务处理，因此有需要设计自订的技术服务，以应付尚未完成的需求及支援业务组件。

（f）技术体系结构原型

这工作项目包括一个有限的发展计划，在结构上它是业务体系结构定义及设计和发展周期的总和，但主要差别在于其所支援的「业务」包括应用系统软件。

（g）完成技术体系结构

在收到业务体系结构小组有关规模的资讯和概念验证的检讨后，便需完成技术体系结构。

3.4 递增交付规划

每个递增交付成品均包括多个完整的用例。由于每个用例都说明一个可用于系统的方法，因此在获得调配时便能够产生价值。基于在业务规划阶段内所发展的用例的优先排序，最重要的用例会首先交付给用户。

递增交付规划的工作项目是：

（a）界定递增交付成品及推行策略

递增交付工作可透过编配用例及所需组件至建议的递增交付成品而加以规划。有关把具体的用例编配给递增交付成品的决定，是根据编配给每个递增交付成品的交付优先次序而作出。优先次序主要是由代表用例的业务价值来衡量。其他因素如用例的复杂性和组件之间的关系，亦应加以考虑。

（b）完成系统分析及设计

这工作项目会完成系统分析和设计的有关活动，并编制系统分析和设计的报告。

3.5 递增设计和建设

本阶段会以业务体系结构定义的最后成品作为出发点。有关组件及其类别会从技术体系结构定义向技术体系结构作出配对，及在其后按表现和可维修性等原因进行优化。
透过使用作为程式编制语言的一部分的类别概念，会令那些经优化的类别得以实现。程式将会接受测试，获得用户接受和随时可供调配。

递增设计和建设业务的工作项目是：

（a）巩固体系结构

业务体系结构定义针对问题领域，并提供经界定的业务组件和组件服务，以支援系统的需求。技术体系结构定义则处理基本职责和适用的技术，及提供一套组件和软件方案的使用模式和原则，以切合具体的技术需求。

（b）设计和发展方案程序

以组件为本的发展程序和模型会有两方面，即左面（方案程序）和右面（业务组件）。
左面是关于发展在业务组件以外的用例。方案的物件顺序图显示在程序管制人员左面的交互情况。它涉及确定和增加类别用户（与用户界面原型一致），然后发展用户界面物件和管制物件（例如：程序及界面管制人员物件），及业务组件界面的使用。此外，它也界定进行交易的环境。

（c）设计和发展业务组件

以组件为本的发展程序和模型会有两方面，即左面（方案程序）和右面（业务组件）。右面是关于发展在业务组件以内的业务组件；该组件是在物件顺序图的业务组件界面的右面。

（d）设计和发展资料服务

把资料库接达服务「组件化」所具有的好处，与把业务服务「组件化」的好处相同。它有助工作人员在静态界面工作，因此可在界面后面进行结构变化而不会对界面产生影响。

（e）测试递增交付成品

为推行用例的职能而编制的代码会进行测试，以确保它根据在用例中所指明的规格正确地执行。测试方法与测试一般概念的方法一致。

3.6 设置

递增交付成品的设置可按业务性质、计划的限制及所带来的好处而加以采用。

设置的工作项目是：

（a）为培训用户作好准备

是否需要就整个系统或每个递增交付成品对用户进行培训，实在非常取决于如何调配该等递增交付成品。

如会设置每一个递增交付成品，便须在第一个递增交付成品的用户测试前首先进行培训。在用户测试期间，终端用户将须在设置递增交付成品前操作该系统和收取培训材料。