D-FOM，面向对象系统分析与设计的另一种模型

引言

面向对象分析与设计（OOAD）在软件设计领域并非新概念。Booch、Rum Baugh和Jackabson在该领域提出了许多杰出的概念，以帮助系统设计。他们提出了关于类识别及其在包和关系建模方面的好方法。

尽管面向对象方法的初学者可以通过互联网和其他信息来源获得足够多的现有系统案例研究和示例，但他们在识别具有关联和聚合关系的类和属性时似乎仍然面临许多困惑。

在过去的几个月里，不同的软件和硬件开发公司联系我，因为他们没有高效的工具可以直接将VHDL系统设计转换为OOPS（面向对象程序设计），反之亦然。我对此问题进行了一些思考。

在这些论文中，我试图找到并解决大多数这些困惑和常见问题，并提出另一种分析系统的方法，为系统的面向对象分析提供一个清晰、易于接受的视角。

传统面向对象方法的回顾

在传统的面向对象方法中，我们试图用具有自身身份、状态和行为的离散对象来描述系统。这些方法建议不要从函数集来分析系统，而是从对象、类和关联来分析。（这些术语已经在各种信息源上讨论过，对IT专业人士来说并不陌生，因此无需重新讨论）。

这些方法建议，软件架构和设计并非是单维度的，而是由并发的多个视图组成的。[参考“4+1架构”：Visual Modeling with Rational Rose2000 - 作者：Terry Quatrani]。

传统面向对象方法中的常见复杂性

这些传统方法存在一些薄弱环节，经常导致设计的错误，从而使系统设计成为一项复杂的任务。其中一些复杂性可以总结如下：

1. 类识别：最大的复杂性在于准确识别类，否则设计将无法按规范工作，并且在设计实现时还会产生更多复杂性。传统方法建议从问题陈述中收集名词，然后将其分类为相关类、不相关类、属性和关系。

2. 对于新加入的分析师来说，不可能获得一套完美（或接近完美）的类、用例、参与者和关联。它们各自的集合都存在不完美之处，当4+1视图结构独立地并行设计这些视图时，所有这些不完美之处都会累加，导致设计中出现越来越多的错误。

3. 由于所有视图都是并行开发的，因此必须交叉检查它们的一致性，确保不会以不同的态度做出不同的假设和决策。在后期阶段（在分别分析所有视图之后）进行的这种交叉检查会导致分析和设计阶段出现大量迭代。

4. 面向对象程序设计（OOPS）与硬件描述语言（HDL）之间没有关联。

5. 由于多个视图是并行开发的，最后才合并在一起，这会导致多种不一致和不兼容。为了消除这些不一致和不兼容，我们需要在SDLC（软件开发生命周期）中执行多次迭代。这些迭代耗费时间和资源。

DFOM - 新方法

在过去的几个月里，不同的软件和硬件开发公司联系我，因为他们没有高效的工具可以直接将VHDL系统设计转换为OOPS，反之亦然。我对此问题进行了一些思考。

现在我将尝试找出一种新的方法，它不应脱离对象和面向对象系统的基础，但应在整个过程中减少迭代次数，从而减少为获得良好设计所需投入的精力和资源。同时，我也会尝试在此方法中解决上述问题，以便我们可以将系统从VHDL模型转换为OOPS，反之亦然。

人们普遍发现，当有人审视系统时，他们会试图直接关注系统的功能。同样，当客户提出系统需求时，他们总是试图解释系统所需的功能或服务。这甚至可能是系统的黑盒功能，它只说明对于给定的输入会产生什么输出。在识别了系统给定输入集下的行为后，我们可以从抽象层面识别系统的不同状态。

根据系统的行为和环境，我们可以定义系统的用户是谁以及他们如何使用它。基于这些研究，我们可以准备一个系统的用例分析，其中包含多个用户（参与者）以及他们与系统的交互（用例），展示他们如何使用系统。

通过用例分析结果，称为用例图，我们可以很好地理解系统在环境中将如何被使用。

现在，这个用例分析可以用来开发系统的类图，为任何面向对象语言的系统编程代码提供一个骨架。

此外，对于每个需要的用例，可以使用顺序图来支持用例分析，它在执行该用例时为您提供系统的动态行为视图。

如果用例得到妥善管理和分析，这些系统动态就可以转换为编程语言的代码。如果需要，一个用例还可以进一步分解为多个用例。

分析的第一步

使用这种方法进行系统面向对象分析的第一步是找出系统中的参与者及其用例。为此，我们需要清楚地理解参与者和用例的概念。

参与者（Actor）：使用系统或触发系统任何活动的用户、任何外部系统或实体，甚至系统本身的一部分（待分析部分）都可以被视为系统的参与者。换句话说，参与者是系统中必须与之交互的外部事物。

例如，银行系统的客户是参与者；“点播音乐”系统的请求发送者是参与者；图书馆的订阅者是参与者；出租车的司机和租车人是参与者。

用例（Use Case）：我们可以说用例是系统业务流程的表示。它是参与者与系统之间对话的模型。用例可能是系统为参与者提供的一个功能或服务。换句话说，可能是参与者使用系统或获取其服务的方式。例如，对于银行客户，填表、存款、取款、查询余额等都是用例。同样，对于“点播音乐”系统的请求发送者，"呼叫系统"、"选择感兴趣的歌曲"、"提交请求"等是该系统的用例。

有什么新功能？

这种以参与者和用例来分析系统的方式，与Booch和Ram Baugh提出的普通面向对象方法类似。在这些传统方法中，我们过去会为系统的分析和设计准备用例图、类图、顺序图、协作图、包图等。我们过去会使它们彼此独立。

在DFOM中，我们增加了几个新的概念和成员。在DFOM方法中，引入了两个新术语如下：

统一参与者（Unified Actors）：它们也可以称为系统的内部参与者。它们可以被定义为系统内部的参与者。它们被认为是系统本身的一部分。需要注意的是，之前定义的参与者是系统外部环境的成员。而内部参与者是同一系统的一部分。可以观察到，这些参与者通常是系统的子模块或功能部分，它们为了某些服务而使用系统的其他子模块。这样，它们就使用了系统，但同时它们本身也是系统的一部分。

例如：个人电脑系统中的“显示器”为其功能使用了显卡。因此，在这种情况下，“显示器”是一个统一参与者。

称它们为统一参与者是因为它们以统一的方式包含对系统的使用和系统的功能。这意味着它们以一种方式使用系统，也以另一种方式提供其部分功能。

统一用例（Unified Use Cases）：我们也可以称它们为内部用例。它们可以很容易地被发现是系统中功能参与者的用例，也就是说，是内部参与者与系统或其部分进行的交互，或者是它使用系统或其一部分的方式。通过任何系统的示例，可以很容易地观察到，内部用例可能是系统或其部分提供的功能或服务。

以最后一个例子为例：“显示器”是PC系统的统一参与者，而“将信号转换为显示器可兼容的形式”是显卡的功能。对于“显示器”来说，这同时也是一个统一用例。

我们还可以得出结论：“显示器”是显卡的参与者，但对于PC来说是统一参与者；“获取转换后的兼容信号”是其对显卡的用例，也是PC系统的统一用例；而“显示”是其功能。

现在，通过这四个组成部分——“参与者、统一参与者、用例和统一用例”——我们准备一个功能用例模型来表示它们之间的交互。

这里得出的结论是，如果我们定义一个功能参与者（FA），它是一个参与者或统一参与者，那么功能参与者就是使用或向系统提供功能/服务的单元。同样，另一个术语可以称为功能用例（FUA），它可以被定义为一个用例或内部用例。因此，功能用例要么是系统提供给用户的功能/服务，要么是系统内部工作所使用的其子模块的服务，这些服务的集成结果构成了系统的功能。通过功能参与者和功能用例来分析系统被称为该系统的功能用例分析（FUCA），其结果是功能用例模型（FUCM）。

迈向设计

在DFOM技术中，主要的迭代发生在功能用例分析（FUCA）阶段。之后，该方法遵循自顶向下分析策略。每个功能参与者（FA）都被视为一个独立的模块，每个FA-FUC集合都会被单独深入分析，以便将模块设计到最大细节。

为了清楚地解释FUCA，让我们用同样的方法来分析一个微处理器芯片。

对于微处理器，外部用户或参与者可能是“命令生成器”和“复位”信号生成器。这是因为这两种是微处理器被激活执行某些功能的唯一方式。当我们开始审视微处理器时，首先，根据我们最初的了解，我们可以看到在这里可能是功能参与者的单元是：

• 控制单元

• 内存

• 算术逻辑单元

这些单元在内部为微处理器提供功能服务。

功能用例模型包含功能参与者和功能用例。这意味着它包含参与者、内部参与者、用例和内部用例。需要注意的是，对于给定的系统问题陈述，此模型可能因人而异，这取决于他们对领域的理解和经验。但这种差异通常非常微小，最终的分析模型会围绕一个通用的观点线。这些迭代分析结果带来了被开发系统的FUCA模型。

现在，这是我们转向系统设计阶段的起点。这种设计与传统方法不同。这是DFOM开始发生急剧转折并形成形状的地方。我们以一种依赖和有偏见的方式前进。在这里，DFOM技术在组件视图（包括类分析、对象和关联）上引入了一些对预先开发的功能用例模型的依赖。DFOM认为，为了获得系统的类设计，我们可以直接将统一参与者视为类，而相应的函数用例（统一用例和普通用例）可以直接作为与相应类对象相关联的函数（或方法）。在类设计实现或正式化之前，我们可以根据经验和系统知识，根据需要从模型中删除不相关的类。

这大大减少了后期阶段为了获得一致的4+1视图而进行大量迭代的需求。主要迭代仅在FUCA阶段完成。此外，在引入依赖关系的情况下，系统的后续设计和实现过程变得非常直接和简单。它能提供快速准确的结果。

现在，为了继续前进，以实现为重点，为类模型中包含的每个函数用例开发顺序图。它为类中包含的所有方法的实现提供了框架。这里的想法是，“顺序图代表设计与实现阶段的共同边界”。因此，它们必须能够清楚地显示该方法如何工作，并解释如何在选定的编程语言中实现此过程。顺序图也可以被视为过程工作的某种算法。

在此之后，我们可以根据类的特性将它们分组到包中。最后，可以根据需求迭代地实现系统。

需要指出的是，该方法并没有消除迭代的概念，而是旨在减少获得良好设计所需的迭代次数。此外，由于该方法主要侧重于FUCA和FUCM，一旦获得良好的FUCM，该过程的结果本身就是一个良好的设计。

为什么命名为D-FOM？

可能会有人问，为什么我将这种提议的方法命名为“D-FOM”。这背后没有太大的故事。这里的“D”只是代表我的首字母。“FOM”代表**功能对象建模**（Functional Object Modeling）。事实上，这种方法是围绕功能对象工作的。功能对象的概念是，我们在这里试图分析系统的功能，然后在此基础上开发对象模型。最后，将这些函数和这些对象结合起来，得到我们称之为功能对象的东西。这些概念及其应用的结合框架在这里被称为FO-Model，结果就是该方法，“D-FOM”。

分析 D-FOM 方法

上述讨论的D-FOM方法可以作为其他现有软件系统设计方法的替代方案，在某些情况下可能具有一些优势。但另一方面，除了这些优势，该方法在某些情况下也存在一些限制和缺点。在使用该方法解决特定问题之前，需要了解这些优势和限制。问题的性质及其环境对建模技术的结果有很大影响。

优点

1. 资源消耗与一致性：如果在传统方法中的后期阶段进行一致性检查，并且在该阶段发现系统设计不一致，那么我们必须一遍又一遍地重复整个设计过程，直到做出一致的设计。这些迭代使设计过程非常耗时且消耗资源。或者，在D-FOM中，我们在“FUCA”的早期阶段就进行了进行一致性检查。通过这种方式，我们无需迭代整个过程，只需要修改FUCA。这可以节省时间和资源和精力。

2. 自动化：D-FOM中不同阶段的依赖关系使其成为一种更自动化的方法。我们只需要分析“FUCA”和函数动态，而其他大部分部分则根据规定的依赖关系进行设计，因此根据输入，结果大多是固定的。我们可以开发一个工具，以“FUCA”为输入，以自动化方式输出完整的骨架设计。

3. 集中的、确定的错误易发区：由于“FUCA”涉及主要的决策和分析，它成为任何系统设计错误的潜在主要错误区域。D-FOM中的其他阶段几乎是自动化的，并且依赖于FUCA。因此，对于系统中的任何错误，主要概率都发生在FUCA中。这使得模型在设计错误检测方面速度更快。

4. 系统与模拟器的并行设计：对于任何硬件系统，如今公司都试图构建其模拟器，以便进行未来的分析和实验，并与类似硬件进行交互。使用D-FOM，我们可以获得一个同样适合OOPS和HDL实现的设计。在这方面，您可以参考我的另一篇论文“VHDL与OOPS的映射”。

方法中的缺陷

我们不能直接称之为缺陷，但就像任何其他方法一样，这种方法也可能面临一些约束和限制。

• 为了正常运行，该模型需要一个恰当且明确定义的问题陈述，以及清晰的一致性标准陈述。这里的恰当的问题陈述不一定意味着一个僵化的陈述，而是指一个至少能提供可查看的需求列表并能让请求者期望得到理解的问题陈述。

• 如果我们不能很好地理解系统，那么这种方法可能无法提供有效的解决方案。相反，我们应该进行一些原型制作，功能最少，以便为理解系统打下基础。在原型制作的后期阶段，当我们有了明确的系统概念和良好的问题陈述时，我们就可以轻松地切换到相同的模型。但对于这一点，您应该按照方法中所述的分析和设计步骤及图表的步骤和依赖关系来构建原型。

• 该模型的一个主要限制是它高度依赖于其用例模型。这意味着只有完美的“功能用例模型”（FUCM）才能带来良好的设计。任何留在那一阶段的错误都可能导致最终设计中的相同错误。因此，为了使用该方法获得良好的设计，我们需要将主要精力放在其FUCM分析上，以便几乎不遗漏任何错误。主要迭代将仅在那里发生，使其越来越完善和无错误。

D-FOM的未来工作

在未来的工作中，我将添加一些支持该模型的案例研究。这些案例研究将阐明D-FOM的用法。我将尝试用系统设计的实际例子来描述D-FOM中的不同步骤和阶段。这些案例研究将展示我们如何在D-FOM中使用不同模型（分析图）的依赖关系及其相应的依赖关系。

1. D-FOM 对微控制器系统的分析

2. D-FOM 对微控制器内部RAM的分析

3. D-FOM 对微控制器ALU的分析

4. D-Fom 对intel 8031-MCU内部解码器的分析

5. 使用D-FOM的微控制器设计生命周期

参考文献

下载引用的研究论文 - 655.6 Kb

1. 谁需要方法论？ 作者：David A Banks
2. 为什么建模？ 作者：Martin Fowler (编辑-IEEE)
3. “4+1架构”：Visual Modeling with Rational Rose2000 - 作者：Terry Quatrani
4. 面向对象软件系统的正向和反向工程中的动态建模 - 作者：Tarja Systa - 坦佩雷大学。
5. 4+1架构：http://www.architecture.external.hp.com/Download/ arch_template_vers13_withexamples.pdf
6. 面向对象分析与设计 - 作者：James Rumbaugh, Michael Blaha, William Premerlani。
7. 面向对象分析与设计 - 作者：Grady Booch
8. 软件工程 - 实践方法：作者：Reger S. Pressmen
9. VHDL：分析与设计 - 作者：Navabi。

---

---