是否有任何结构化方法来定义隐喻以简化程序的复杂性

Question

很抱歉，如果这看起来是一个模糊的问题，但它已经困扰我一段时间了。

在我的日常工作中，我编写的一些代码变得非常复杂。并不是说它通常非常技术性，而是问题域本身是一个处理空间数据以及许多其他事物的复杂问题。我很确定我的保密协议会禁止我透露我正在做的事情的任何细节，所以不幸的是，我必须保持这个非常笼统的内容。

现在，我完全赞成降低复杂性，因此我会尽可能找到正确的抽象，但是有什么方法可以通过明确不处理手头的实际问题而是使用一些隐喻来进一步减少复杂性可以对其进行操作，然后转化为我想要的实际结果吗？

当然，由于该领域本身是如此复杂，..我尝试过但失败了（很多次！）找到正确的比喻:-(

所以我的问题是，是否有人已经完成了这项工作并发现（甚至一半 ）找到）一种结构化的方法来推断一组给定的编程问题的适当的隐喻或启发式？

再次，如果这看起来有点奇怪，我很抱歉我只是想找到成为更好的程序员的新方法。

提前致谢。

Answer 1

所以我的问题是，是否有人已经完成了这项工作并发现（或
甚至一半找到）一种结构化的方法来推断适当的
对于一组给定的编程问题的隐喻或启发式？

我可能已经开始回答你的问题了。这由多个抽象级别组成；多个域的描述；以及以特定方式应用“建模”技术——与通常的建模方式截然不同。我相信，总体方法就是您所寻求的 - 它给出了可操作的隐喻，然后转化为实际结果。它基于许多已发布的方法，并严重依赖其中一些途径和方法。

以下内容受到这些警告的约束：

1. 这在很大程度上是“正在进行的工作”。
2. 我一直受到贬低性的评论，称我是“架构宇航员”，这意味着我与真实系统开发的本质脱节。这是这项工作正在进行的原因之一 - 我当前的项目旨在验证这个概念，并证明它具有真正的实用性。为了做到这一点，我需要使用我的方法开发一个具有足够规模和复杂性的系统，这通常是单个开发人员无法实现的。我只是完成了这种概念验证开发的一部分。
3. 虽然我描述的概念源自对复杂问题领域（声纳接触跟踪系统和芯片设计系统）的考虑，但我的示例涉及一个更简单的领域 - 基本上是一个受规则系统约束的信息系统。规则库不仅包括有关域的规则，还包括有关其他规则的适用性的规则。
4. 从你的问题来看，我怀疑我是从与你相反的方向来讨论这个问题的。您要求一种方法来为一组给定的编程问题推断出适当的隐喻或启发式 - 对我来说这意味着从编程问题开始。我的动力来自于分析方面——试图找到并制定描述所提议的系统的方法，以便它可以作为一个真实的系统来实现。
5. 当我使用“模型”和“建模”这两个词时，我指的是如下所述的建模。此描述与这些术语的常见用法有些不同。

这种方法所需的三个主要组成部分是：

多个域

我对域的定义比通常采用的更广泛：

域是一个独立的真实的、假设的或抽象的世界
由一组不同的物体和现象组成，这些物体和现象的行为遵循
域的规则和策略特征。有问题
分析。域是开发时一个有用的考虑单位
复杂的系统。

根据这个定义，系统内有多个域需要考虑，通常当开发人员提到域时，他们指的是问题（或应用程序）域（以下称为P）。然而，对于这种方法，系统的任何方面或系统开发都是建模的潜在主题。这包括系统架构（A）；系统生产工件（代码、制作脚本、数据库模式等）（C）； DBA职能；等等。通过隐喻接近P需要开发几个这样的领域 - 与隐喻以及从隐喻到现实世界模型或代码实现的转换相关开发系统中的现实世界。当开发多个这样的模型时，它们都被开发到相同程度的范围和精度。

多层次抽象

为了描述问题和系统，不仅要建模P，还要建模适当的更高抽象层次。因此，选择用来描述 P 的隐喻被建模（M）。以类似的方式，对 A (F) 的形式进行建模，如果认为有必要，则进行转换过程在 P 和 C 之间使用 A (<强>R）。因此，我们可以抽象出问题领域；抽象抽象等等。

多个模型的应用类似于分色——它们相互叠加，系统必须满足所有层的所有描述（“完整图片”）。这又与常见的建模方式不同，常见的建模方式往往通过精心设计原始模型以纳入不同的约束来满足多种要求。当所有架构域都有效地应用于所有问题域的所有元素时，这具有特殊的含义。

建模

我所说的建模与更常用的建模方法在以下方面有所不同：

1. 模型的主题很可能因领域而异。这与初始模型是其他模型的详细阐述的建模形成鲜明对比。事实上，模型有效性的一个测试是它代表了 DRY 原则的极端版本​​ - 如果某事物在多个地方定义，则表明模型存在缺陷。这扩展到所考虑的所有领域，因此系统的构建方式仅在一处定义。
2. 域一旦建模，就可能是相当静态的。抽象级别越高，改变的可能性就越小。
3. 模型的范围可能比传统开发的模型要窄得多，而且要深入得多。与传统建模相比，特定领域内的对象可能更少；但这些模型必须是完整的，并且有一些测试可以表明模型的完整性（显然，人们永远无法证明系统描述是完整的）。
4. P 采用 M 定义的术语进行描述。该模型可以表示为图表、OO 表示、数学公式或任何适合领域M 的形式。

以下示例源自我的概念验证项目，可能会为我上面的描述提供一些内容。我列出了我的一些领域，以及领域模型的候选内容。

• P [车辆、单位、动作、疲劳、速度...]
• P1 [规则、适用性、状态、优先级...]（附属问题域）
• M [对象类型、属性、关系、域...]
• A [事件、表、列、数据库域、类...]
• F [持久化机制、处理......]
• C [数据库模式、源代码、SQL 脚本、构建脚本，...]
• R [形式主义、转换、映射...]

这种方法至少有一个主要缺点 - 管理层可能会认为开发模型所涉及的工作是非生产性的，没有产生真正的可交付成果。

这个答案的来源多种多样，但很大程度上依赖于以下人的著作：

1. 迈克尔·杰克逊的结构化编程；系统分析；和问题域描述。
2. Shlaer-Mellor 通过转换而非细化进行系统开发的方法。
3. 肯尼迪卡特方法咨询公司。