是否存在用于定义隐喻以简化程序复杂性的结构化方法

时间:2010-02-10 15:18:08

标签: methodology heuristics

很抱歉,如果这看起来像是一个朦胧的问题,但这一直是困扰我一段时间。

在我的日常工作中,我编写的一些代码变得相当复杂。并不是说它通常非常技术性,但问题域本身是一个复杂的问题,处理空间数据和许多其他事情。我很确定我的NDA会禁止我提供我正在处理的任何细节,不幸的是,我必须保持这种非常一般。

现在,我只是为了降低复杂性,所以我尽量找到合适的抽象,但有没有办法通过明确地不处理实际问题来进一步减少它,但是相当一些可以操作的比喻,然后转化为我想要的实际结果?

当然,由于这个区域本身就很复杂,但我已经尝试但很多次失败(很多次!)找到正确的比喻: - (

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

再次,如果这看起来像一个奇怪的问题,我道歉。我只是想找到成为更好的程序员的新方法。

提前致谢。

1 个答案:

答案 0 :(得分:1)

  

所以我的问题是,有人已经完成了这项工作并找到了(或者   甚至一半发现)一种结构化的方式来推断一个合适的   一组给定编程问题的隐喻或启发式算法?

我可能会开始回答您的查询。这包括多个抽象层次;多个域的描述;以及"建模"的应用特定方式的技术 - 与通常在建模中所做的完全不同。我相信,整体方法是你所寻找的 - 它给出了操作的隐喻,然后转化为实际结果。它基于许多已发布的方法,并且在很大程度上依赖于其中一些方法和方法。

以下内容受以下警告影响:

  1. 这非常"正在进行中"。
  2. 我一直在接受贬义的评论,即我是一名建筑宇航员",结果暗示我与实际系统开发的细节不相符。这是正在进行中的原因之一 - 我目前的项目旨在验证这一概念,并证明它具有实用性。为了做到这一点,我需要使用我的方法开发一个具有足够规模和复杂性的系统,这通常是个别开发人员无法企及的。我只是通过这种概念发展证明的一部分。
  3. 虽然我描述的概念源于对复杂问题域(声纳接触跟踪系统和芯片设计系统)的考虑,但我的例子涉及一个更简单的域 - 基本上是一个受规则系统约束的信息系统。规则库不仅包括有关域的规则,还包括有关其他规则适用性的规则。
  4. 我怀疑,从你的问题来看,我是从与你相反的方向来到它。你想要一种方法来为一组给定的编程问题推断一个适当的比喻或启发式 - 这对我来说意味着从编程问题开始。我的动力来自分析方面 - 试图找到并制定描述拟议系统的方法,以便它可以作为一个真实的系统来实现。
  5. 当我使用" model"和"建模"我是指如下所述的建模。该描述与这些术语的常见用法有些不同。
  6. 这种方法所需的三个主要成分是:

    多个域名

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

      

    域名是一个独立的真实,假设或抽象的世界   由一组独特的物体和现象表现出来的   域的规则和政策特征。在问题   在开发时,域是一个有用的考虑因素   复杂的系统。

    根据此定义,系统中有多个域供考虑,通常当开发人员引用域时,它们表示问题(或应用程序)域(以下称为 P )。然而,对于这种方法,系统的任何方面或系统开发都是建模的潜在主题。这包括系统架构( A );系统生产工件(代码,制作脚本,数据库模式等)( C ); DBA功能;通过隐喻来接近 P 需要开发几个这样的域 - 涉及隐喻和从隐喻到现实世界模型的转换,或者代码实现发达系统中的现实世界。当开发出多个这样的模型时,它们都被发展到相同的范围和精度。

    多级抽象

    为了描述问题和系统,一个模型不仅 P ,还模拟适当的更高抽象级别。因此,选择用于描述P的比喻被建模( M )。以类似的方式, A F )的形式主义被建模,如果认为有必要,转换过程 P C 之间使用 A (<强> - [R )。所以一个抽象问题领域;摘要抽象等等。

    多个模型的应用类似于分色 - 它们位于彼此之上,系统必须满足所有层的所有描述(&#34;完整图片&#34;)。同样,这与通常的建模方法不同,后者倾向于通过详细说明原始模型来采用不同的约束来满足这样的多个要求。当所有体系结构域都有效地应用于所有问题域的所有元素时,这会产生特别的影响。

    <强>建模

    建模的意思与以下方面的建模方法不同:

    1. 模型的主题很可能在域与域之间存在差异。这与初始模型是其他模型的详细说明的建模形成对比。实际上,对模型有效性的一个测试是它代表了DRY原则的极端版本​​ - 如果在多个地方定义某些东西,则表明模型存在缺陷。这扩展到所有正在考虑的域,因此系统的构建方式仅在一个地方定义。
    2. 域名一旦建模,可能会相当静态。抽象级别越高,改变的可能性就越小。
    3. 模型的范围可能比传统开发的范围更窄,更深。特定域中的对象可能比传统建模中的对象少;但是这些模型必须是完整的,并且有一些测试可以显示模型的完整性(显然,人们永远无法证明系统描述是完整的)。
    4. P M 定义的术语描述。该模型可能表示为图表,OO表示,数学公式或适用于域 M 的任何内容。
    5. 以下示例源自我的概念证明项目,可能会给我上面的描述带来一些肉体。我列出了一些我的域名,以及域名模型的候选内容。

      • P [车辆,单位,动作,疲惫,速度......]
      • P1 [规则,适用性,状态,优先级......](子公司问题域名)
      • M [对象类型,属性,关系,域名...]
      • A [事件,表格,列,数据库域名,类...]
      • F [持久机制,处理,.....]
      • C [数据库模式,源代码,SQL脚本,构建脚本,....]
      • R [形式,变换,映射...]

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

      这个答案的来源多种多样,但很大程度上依赖于以下作品:

      1. Michael Jackson关于结构化编程;系统分析;和问题域描述。
      2. Shlaer-Mellor通过转换而不是精心制作系统开发的方法。
      3. Kennedy-Carter方法咨询公司。