D-FOM：又一个面向对象模型

• 下载包含D-FOM方法完整细节和案例研究的PDF文档，以建立对该方法的信心 - 175 Kb

引言

面向对象分析和设计的概念在软件设计中并不新鲜。Grady Booch、Rum Baugh、Jackabson以及许多其他研究人员在该领域提出了伟大的概念，以帮助系统设计人员。他们提出了很好的方法来识别类及其在包和关系方面的建模。虽然面向方法的新手有足够的案例研究和已开发系统的示例来学习和理解这些方法的概念，但他们似乎在识别类、属性以及它们之间的关系和关联方面面临很多困惑。

此外，这些传统的面向对象方法在硬件模块或系统的设计和实现方面效率不高。在当今的场景中，我们常常对硬件系统的模拟器软件感兴趣，即使我们没有真实的硬件系统，也能理解并感受实际系统的工作原理。这些模拟器在培训机构中具有高度的重要性，因为它们占用的空间少且维护成本低，可以通过模拟器培训大量的学员。因此，设计人员也可能希望以最少的努力获得系统的模拟器。

设计过程中自动化技术的引入也可能是该领域研究人员的另一个目标，对设计团队具有很大的吸引力。减少错误并快速扫描设计以发现其中可能存在的错误是设计人员的另一个高度关注点。

在这些论文中，我试图通过提出另一种可接受的面向对象分析和实现任何给定系统规范的方法，来找出并解决一些普遍关注的困惑和问题。但要理解这种新方法，需要熟悉Grady Booch、Rum Baugh和Jackabson提出的传统面向对象方法。

传统面向对象方法回顾

在传统的面向对象方法中，我们一直试图用具有自身标识、状态和行为的离散对象来描述系统。这些方法一直建议不要以一组函数来分析系统，而是以对象、类以及它们之间的关联来分析系统。这些方法一直建议软件架构和设计不是一维的，而是由并发的多视图组成的。4+1 架构[1] 从五个并发视图描述了系统。每个视图都是一个抽象，具有明确的关注领域。用例视图关注系统的“可用性分析”和“可理解性”。逻辑视图关注系统的“功能性”。实现视图讨论系统的“软件管理”。过程视图描述设计的“性能、可伸缩性和吞吐量”，部署视图讨论系统拓扑、交付、安装和系统中涉及的通信的抽象[1]。所有这些视图都是相互独立准备的。

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

这些方法中存在一些薄弱点，经常导致所准备的设计出现错误，从而使系统设计成为一项复杂的任务。并不是说这些复杂性是不可避免或不可弥补的。多年来一直在进行研究以寻找解决方案。但理解这些复杂性在提出一些新的设计方法时至关重要，并且所有这些复杂性都必须在新方法中加以避免。其中一些复杂性可以总结如下：

1. 类识别：主要的复杂性出现在准确的类识别中，如果没有它，设计将无法按规范工作，并且在实现设计时还会产生更多复杂性。传统方法一直建议从问题陈述中收集名词，然后将其分类为相关类、不相关类、属性和关系。这种传统也可能因为大量的名词而造成混淆。
2. 对于经验不足的分析师，不可能获得一套完美（或良好，接近完美）的类、用例、参与者和关联。它们各自的集合都有其自身的缺陷，当4+1视图结构独立地并行设计这些视图时，所有这些缺陷都会累加起来，导致设计中出现越来越多的错误。
3. 对于新团队成员，如果中途加入项目，要快速掌握流程并理解之前专家在迭代中分析的完整设计并不容易。这可能需要很长时间，因此，某些团队成员中途加入项目可能会导致项目延期。
4. 由于所有视图都在并行开发中（4+1 架构），因此必须对它们进行交叉检查，以确保系统的一致性，即不会以不同的态度做出不同的假设和决策。在后期阶段（分别分析所有视图之后）进行这种交叉检查会导致分析和设计阶段的大量迭代。[1]
5. 这些方法中没有直接的关系或概念用于设计硬件及其在HDL中的实现。

确定性功能对象建模（DFOM）-新方法

针对上述所有复杂性，我们需要找到另一种方法，它必须不脱离对象和面向对象设计的基础，但应减少整个过程中的迭代次数，从而减少为获得良好设计所需付出的精力和资源。

通常发现，当人们审视系统时，他们会直接关注系统的功能。此外，当客户要求提供某个系统时，他们总是试图解释系统所需的功能或服务。甚至可以是系统的黑盒功能，它除了说明系统输入所需要的输出之外，什么也没有说明。在识别了系统在给定输入集下的行为之后，我们可以在抽象级别上识别系统的不同状态。

根据系统的行为和环境，我们可以定义系统的用户是谁以及他们如何使用它。在此基础上，我们可以准备一份系统的用例分析，其中包含许多用户（参与者）以及他们与系统（用例）的交互，这显示了他们如何使用系统。通过用例分析结果，即用例图，我们可以很好地理解系统将在环境中如何使用。

建议是，在某些依赖关系下，此用例分析可以直接用于开发系统的类图，为系统在任何面向对象语言中的编程代码提供骨架。此外，如果需要，可以用每个“用例”的序列图来支持这一点，这在执行该用例时提供了系统的动态行为视图。如果用例得到适当的管理和分析，则系统的这种动态性可以转换为编程语言的代码。如果需要，用例还可以进一步单独分析为许多用例。

分析的第一步

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

参与者：使用系统或在系统中触发任何活动的任何用户或外部系统都可以被视为系统的参与者。换句话说，参与者是系统外部必须与系统交互的事物。例如，客户是银行系统的参与者；请求发送者是“点播音乐”系统的参与者；订阅者是图书馆的参与者；司机和出租人是出租车的参与者。

用例：我们可以说用例是系统业务流程的表示[2]。它是参与者与系统之间对话的模型。用例可以是系统提供给参与者的某些功能或服务。换句话说，它可以是参与者使用系统或获取其服务的方式。例如，对于银行的客户来说，填写表格、存款、取款、余额查询等都是用例。同样，对于MOD系统的某个请求发送者来说，“调用系统”、“选择感兴趣的歌曲”、“提交请求”等都是用例。

有什么新功能？

上面讨论的从参与者和用例角度进行的系统分析，与Booch和Ram Baugh提出的传统面向对象方法类似。在这些传统方法中，我们通常会准备用例图、类图、序列图、协作图和包图来分析和设计系统。我们习惯于像前面描述的那样（4+1架构）[1]，在模型的独立视图中准备它们。

在DFOM中，我想在设计中引入一些新的概念和成员，以使过程更简单。这里，引入了两个新术语，如下所示：

1. 统一参与者：这些也可以称为系统的内部参与者。它们可以定义为系统内部的参与者。这意味着统一参与者以某种形式使用系统，但它本身存在于系统内部。它从系统的其他部分获取服务，同时它本身也是系统的一部分。每当需要为其提供某些服务时，它就会在系统中触发活动。这些被认为是系统本身的一部分。值得注意的是，之前定义的参与者是系统外部环境的一些成员。但内部参与者只是同一系统的一部分。稍后可能会观察到，统一参与者通常是系统的子模块或功能部分，它们利用系统的其他子模块来获取某些服务。通过这种方式，它们使用系统，但同时它们本身也是系统的一部分。例如：“显示器”在个人计算机系统中利用显卡来实现其功能。因此，在这种情况下，“显示器/监视器”是一个统一参与者。

   将它们称为统一参与者的原因是它们以统一的方式包含了系统的一个用途以及系统的一个功能。这意味着它们以一种方式使用系统，并以其他方式提供其某些功能。通过这种方式，它们统一了参与者和功能的概念，因此被称为统一参与者。

2. 统一用例：与统一参与者类似，这些也可以称为内部用例。它们可以很容易地被发现为系统中统一参与者的用例，即内部参与者对系统所做的事情，或者它使用系统的方式，或者使用系统的一部分。某些统一参与者的统一用例可能是它在系统中触发的活动。通过任何系统的示例可以很容易地观察到，内部用例可能是提供给系统或其某些部分的功能或服务。以上一个示例为例：“显示器”是PC系统的统一参与者，“信号转换”为可显示形式（与显示器兼容）是显卡的功能。它也是“显示器”的统一用例。

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

现在，通过“参与者、统一参与者、用例和统一用例”这四个组件，我们准备一个代表它们之间交互的“功能用例模型”（FUCM）。

这里得出的结论是，如果我们定义一个功能参与者（FA）为某种既是参与者又是统一参与者的东西，那么功能参与者就是使用或向系统提供功能/服务的单元。类似地，另一个术语可以称为功能用例（FUC），它可以定义为某种既是用例又是内部用例的东西。因此，功能用例要么是系统提供给其用户的功能/服务，要么是系统用于其内部工作的子模块产生的服务，其集成结果是系统的功能。根据功能参与者和功能用例分析系统被称为系统的功能用例分析（FUCA），其结果是功能用例模型（FUCM）。

转向设计

在DFOM技术中，主要的迭代只发生在功能用例分析阶段。之后，该方法遵循自顶向下的分析策略。每个功能参与者（FA）都被视为一个独立的模块，并且每个FA-FUC集合都单独深入分析，以最大限度地详细设计模块。为了清楚地解释FUCA，让我们用同样的方法分析一个微处理器芯片。

对于微处理器，外部用户或参与者可能是“指令发生器”和“复位”信号发生器。这是因为这两种是微处理器可以被外部激励以执行某些功能的唯一方式。当我们开始审视微处理器时，乍一看，根据我们第一级的经验和知识，我们可以看到这里可能是统一参与者的单元是：

1. 控制单元
2. 内存
3. 解码器
4. 算术逻辑单元

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

功能用例模型包含功能参与者和功能用例。这意味着它包含参与者、内部参与者、用例和内部用例。这里需要注意的是，对于给定的系统问题陈述，该模型可能因人而异，取决于他们自己对领域的理解和经验。但这种差异通常非常微小，最终的分析模型围绕着共同的视图。这些迭代分析结果产生了开发中的系统的功能用例模型（FUCA）。

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

这大大减少了后期阶段为了获得一致的4+1视图而进行的冗长迭代。主要的迭代仅在功能用例分析（FUCA）阶段完成。此外，由于引入了依赖关系，系统的进一步设计和实现过程变得非常直接和简单，因此也可以通过开发一些自动化工具来实现自动化。它提供快速而准确的结果。

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

在此之后，我们可以根据其特性将类分组到包中。最后，系统可以根据需求进行迭代实现。这里值得一提的是，该方法并没有消除过程中迭代的概念，但它只是为了减少获得良好设计所需的迭代次数而做出的努力。此外，由于该方法主要关注FUCA和FUCM，一旦您获得了一个好的FUCM，该过程的结果本身就是一个好的设计。

为什么命名为 D-FOM？

这里可能会出现一个问题，我为什么将这个提议的方法命名为“D-FOM”。这背后没有什么大故事。“D-FOM”代表着确定性功能对象建模。事实上，这种方法是与功能对象一起工作的。功能对象的概念表明，我们在这里试图分析系统的功能，然后在此基础上开发一个对象模型。最后，这些函数和这些对象结合起来得到我们所说的功能对象。将这些概念及其应用结合起来的框架在这里被称为功能对象（FO）模型。该方法既不纯粹基于函数也不基于对象，而是在这两个概念之间寻找解决方案。正如我们所看到的，该方法在功能用例分析（FUCA）之后使过程变得相当严格和确定，对于过程的后续步骤，我们以一种相当严格的框架和确定的方式前进。在这里，该方法既不围绕对象也不围绕函数，而是围绕“功能对象”，而且是以一种确定的方式，结果就是确定性功能对象建模（D-FOM）方法。

评估方法

所有方法都有其优点和局限性（如果不是缺点的话）。这使得任何方法都不能在不讨论的情况下，适用于任何类型的给定项目。我们需要在第一层基础上对系统进行一些临时分析，然后根据项目的性质和该领域的经验，选择可用的方法。确定性功能对象建模（DFOM）也是如此。在这里，我们的局限性也与其积极特性相关。该技术只有在应用于适当的项目时才能发挥最佳效果。这很容易理解，就像如果你需要在很短的时间内完成一个项目，并且你有一个在该领域有足够经验的团队，但如果你选择了SDLC的“原型”模型，很自然地你可能无法获得预期的收益。只有RAD模型才能使事情变得更好并增加收益。设计技术也发生类似的事情。因此，在决定SDLC模型以及分析和设计方法之前，我们需要进行适当的分析。现在让我们尝试将确定性功能建模方法（DFOM）与基于面向对象的其他设计方法进行比较。

分析D-FOM方法

正如我们之前讨论的，已经提出了许多基于面向对象概念的系统分析和设计方法并被接受。然而，研究仍在各个方面进行，以使系统分析和设计（SAD）过程更容易、更流畅。这些技术可以避免您在分析系统和开发过程中经常犯的愚蠢错误。但它们根本无法完全排除过程中出错的可能性。这些方法都有其自身的优点和局限性。这使得没有一种方法是普适的，可以不经讨论就适用于任何类型的给定项目。我们需要在第一层面上基于一些临时性基础来分析系统，然后根据项目的性质和该领域的经验来选择可用的方法。确定性功能对象建模（D-FOM）也是如此。在这里，我们也有与其积极特性相关的局限性。该技术只有在应用于适当的项目时才能发挥最佳效果。这很容易理解，就像——如果你需要在很短的时间内完成一个项目，并且你有一个在该主题上经验丰富的团队，但如果你选择了SDLC的“原型”模型，很自然地你可能无法获得预期的预期利润。只有RAD模型才能使事情变得更好并增加利润。设计技术也发生类似的事情。因此，在决定系统开发生命周期（SDLC）模型和分析和设计方法之前，我们需要进行适当的分析。现在让我们尝试将D-FOM设计技术与基于面向对象的其他传统方法进行比较。

所讨论的“DFOM”方法可以作为其他可用系统设计方法的替代方案，在某些情况下具有一些优势。但与此同时，除了这些优势之外，该方法在某些情况下也存在一些局限性，甚至是一些缺点。在使用该方法解决特定问题之前，需要理解这些优势和局限性。问题的性质及其环境对建模技术的结果会产生很大的影响。

优点

1. 资源消耗和一致性：如果我们在后期阶段（如4+1架构中）进行一致性检查，并且在该阶段发现系统设计不一致，我们必须强制性地一次又一次地迭代整个设计过程，直到设计一致为止。相反，在DFOM中，我们在“FUCA”的早期阶段进行一致性检查。通过这种方式，我们不需要迭代整个过程，只需要修改FUCA即可。这节省了时间和资源。
2. 自动化：DFOM中不同阶段的依赖性使其成为一种更自动化的方法。我们只需要分析“FUCA”和函数的动态性，而其他大部分部分都通过预设的依赖关系进行设计。
3. 集中且确定的易错区域：由于“FUCA”涉及主要的S人工决策，它成为任何系统设计的主要易错区域。DFOM中的其他阶段几乎都是自动化的，并且依赖于FUCA。因此，系统中任何错误的主要可能性都发生在FUCA中。这使得模型在设计中的错误检测速度更快。
4. 系统与模拟器的并行设计：如今，对于任何硬件系统，公司都会尝试为其未来的分析和与类似硬件的实验构建一个模拟器。使用DFOM，我们可以获得一个同样适用于OOPL和HDL实现的通用设计。在这方面，我在我的另一篇论文中讨论了将HDL映射到OOPL。

缺点

1. 为了使其正常运行，该模型需要一个适当且定义明确的问题陈述，并附有清晰的系统一致性标准陈述。如果我们无法正确理解系统，这种方法可能无法提供高效的结果。在由于缺乏系统和相关领域的知识而无法给出良好问题陈述的情况下，我们宁愿采用一些原型开发，以最少的功能作为系统理解的基础。在原型增强的后期阶段，当我们有了一个适当的系统概念和良好的问题陈述时，我们可以轻松地切换到DFOM。但为此，您应该按照该方法中解释的步骤和依赖关系来构建原型，包括不同分析和设计步骤以及图表。
2. 该模型的另一个主要局限性是它高度依赖于其功能用例模型。这意味着只有完美的“功能用例模型”（FUCM）才能为您提供良好的设计。在此步骤中留下的任何错误都可能导致最终设计中出现相同的错误。这意味着FUCA的错误会未经解决地传播到系统设计中。因此，要使用这种方法获得良好的设计，我们需要将主要精力放在FUCM的准备上，以确保几乎没有错误。主要的迭代只会发生在那里，以使其越来越精炼和无错误。

该方法的工作原理（实践经验：人力资源部参考）

在传统的面向对象方法中，我们通常先识别对象，然后将功能分配给它们。另一方面，在新方法中，我们尝试反其道而行之。DFOM 的工作方式与某个组织的人力资源开发部门类似。

假设您是某个软件开发组织的项目经理，并被分配了一个手头的项目。现在，您审视项目，并凭经验尝试准备一份所需的人力资源技能清单，以解决手头的问题。然后您将这份“技能要求”交给公司的人力资源部。人力资源部随后在组织内部寻找合适的员工，如果找不到，则招聘具有所需技能的新员工。

在这里，我们所做的正是，我们首先分析了系统的功能，然后为这些功能创建了对象（人力）。现在，这些功能如何分配给不同的对象？为此，我们再次以人力资源部为例。

假设一个团队“T1”是根据他们的逻辑和分析技能招募的。另一个团队“T2”是根据他们在C++语言中的编程技能招募的，那么所有的分析、设计和算法编写功能都可以分配给团队T1，而这些算法在C++中实现的工作将分配给团队T2。

同样地，D-FOM方法也根据分组将相似的功能进行分组，然后创建对象。

回顾

D-FOM 的组件

1. 参与者：使用系统的事物。
2. 用例：说明系统如何使用。
3. 统一参与者：系统内部的参与者。
4. 统一用例：统一参与者的用例。
5. 功能参与者：一个参与者或一个统一参与者。
6. 功能用例：一个用例或一个统一用例。

D-FOM的步骤

1. 分析的第一步
   1. 查找参与者
   2. 查找用例
   3. 查找统一参与者
   4. 查找统一用例
   5. FUCA
   6. 准备FUCM
   7. 迭代FUCM
2. 何时结束分析：给初学者的粗略想法
   • 当您内部没有更多的模块时。
   • 经验也可能使其提前结束。
3. 转向设计：实现视图（涉及依赖关系）
   • 一次一个树级别，并集成到路径上高一个级别（自底向上）
   • 统一参与者->类
   • 功能用例->方法
4. 迭代并获得泛化
5. 获取类似类的包
6. 序列分析和序列图
   • 自下而上策略：叶子（语句）的序列分析 -> 高一层（函数）的序列分析 -> 系统（过程）的序列分析
7. 实现
   1. 编写叶子序列图代码并创建函数
   2. 集成函数，使之在树中提升一层
   3. 整合以获取系统代码
8. 根据手头问题按照传统方法进行部署分析（由于新系统、网络技术和数据库概念，这并不真正困难）。

优点总结

1. 依赖类识别减少混淆。
2. 新加入成员有望快速开始工作，因为它只需学习和理解FUCM。
3. 集中易错区域。
4. 该方法提供了一种同样适用于OOPL和HDL实现的设计。因此也适用于HDL。
5. 实现硬件及其模拟器的并行设计。
6. 实现自动化。
7. 预计可减少精力和资源消耗。

局限性总结

1. 需要一个适当的FUCA。FUCM需要根据对系统的深入了解来制作。
2. 过度依赖FUCM
3. 并非普遍适用，而是取决于问题的性质。可能不适用于高度复杂的架构。（复杂性意味着模块之间的相互依赖性，这可能会产生巨大的集成问题。但传统方法中也是如此，所以这里没有什么例外。）
4. 项目领域的经验可带来更好的结果。

未来工作

D-FOM通过在过程中引入新概念，开辟了系统设计的新领域。它有望减少SDLC中的工作量和资源消耗。时代的需求是探索根据所选编程语言优化该方法所创建代码的方法，因为所有语言都有其特定的代码结构，并且可以以不同的方式进行优化。对于HDL，我们通常使用自动化合成器。但对于面向对象编程语言（OOPL），我们需要其他方法。另一个需要更多关注的方面是，哪种类型的项目更适合使用D-FOM而不是其他方法。为此，我们需要准备更多的案例研究，通过这些案例研究，我们可以对D-FOM与其他不同方法进行一些比较研究。

前期工作

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

• 微控制器系统（MCU）的D-FOM分析。
• MCU中各组件的D-FOM分析，例如内部解码器、RAM、ROM、ALU、USART和控制单元。
• 使用D-FOM的微控制器设计生命周期。
• 开发基于D-FOM以及HDL和OOPL映射概念的工具，用于OOPL代码与HDL之间的相互转换。

参考

1. Terry Quatrani，《使用Rational Rose 2000和UML进行可视化建模》，Addison Wesley。
2. James Rumbaugh，《面向对象分析与设计》，Prentice Hall，2002年。
3. Martin Fowler，《模型是用来做什么的？》
4. Martin Fowler，《谁需要架构师？IEEE Software 2003年7月/8月》。
5. Michael A. Ogush、Derek Coleman、Dorothea Beringer，《软件和固件架构文档模板》（版本1.3，2000年3月15日）。
6. Rational Software，《统一建模语言，版本1.1》，1998年。