所以我的问题是,是否有人已经完成了这项工作并找到(甚至一半找到)一种结构化的方法来推断一组给定的编程问题的适当隐喻或启发式方法?
我可能已经开始回答您的问题了。这包括多个抽象层次;多个域的描述;以及以特定方式应用“建模”技术 - 与通常在建模中所做的完全不同。我相信,总体方法是您所寻求的 - 它提供了隐喻,然后将其转化为实际结果。它基于许多已发布的方法,并且严重依赖其中一些方法和方法。
以下内容受这些警告的约束:
- 这是非常“进行中的工作”。
- 我一直在接受贬损评论,说我是“架构宇航员”,结果暗示我与实际系统开发的本质脱节。这是正在进行的工作的原因之一——我目前的项目旨在验证这个概念,并证明它具有真正的实用性。为了做到这一点,我需要使用我的方法开发一个具有足够规模和复杂性的系统,这通常是单个开发人员无法实现的。我只是通过这种概念开发证明的一部分。
- 虽然我描述的概念源自对复杂问题域(声纳接触跟踪系统和芯片设计系统)的考虑,但我的示例涉及一个更简单的域 - 基本上是一个受规则系统约束的信息系统。规则库不仅包括有关领域的规则,还包括有关其他规则适用性的规则。
- 我怀疑,从你的问题来看,我是从与你相反的方向来的。您要求一种方法来为一组给定的编程问题推断出适当的隐喻或启发式方法——这对我来说意味着从编程问题开始。我的动力来自分析方面 - 试图找到并制定描述提议系统的方法,以便可以将其作为真实系统实施。
- 当我使用“模型”和“建模”这两个词时,我的意思是如下所述的建模。此描述与这些术语的常见用法有些不同。
这种方法所需的三个主要成分是:
多个域
我对域的定义比通常采用的更广泛:
域是一个独立的真实的、假设的或抽象的世界,由一组不同的对象和现象所占据,这些对象和现象根据域的规则和策略特征运行。在问题分析中,在开发复杂系统时,域是一个有用的考虑单位。
在这个定义下,一个系统中有多个域需要考虑,通常当开发人员提到一个域时,它们是指问题(或应用程序)域(以下称为P)。然而,对于这种方法,系统的任何方面或系统开发都是建模的潜在主题。这包括系统架构(A);系统生产工件(代码、制作脚本、数据库模式等)(C);DBA 职能;等接近P通过隐喻需要开发几个这样的领域——与隐喻和从隐喻到现实世界模型的转换有关,或者与在已开发系统中对现实世界的代码实现有关。当开发多个这样的模型时,它们都被开发到相同程度的范围和精度。
多层次的抽象
为了描述一个问题和系统,一个模型不仅要建模P,还要建模适当的更高层次的抽象。因此,选择描述 P 的隐喻被建模(M)。以类似的方式,对A ( F ) 的形式进行建模,如果认为有必要,使用A ( R )在P和C之间的转换过程。所以抽象了问题域;抽象抽象等等。
多个模型的应用类似于分色——它们相互重叠,系统必须满足所有层的所有描述(“完整图片”)。这又不同于通常的建模方式,后者倾向于通过精心设计原始模型以接受不同的约束来满足此类多重要求。当所有架构域都有效地应用于所有问题域的所有元素时,这具有特别的意义。
造型
我所说的建模与更常用的建模方法在以下方面不同:
- 模型的主题很可能因域而异。这与初始模型是其他模型的详细说明的建模形成对比。事实上,对模型有效性的一项测试是它代表了 DRY 原则的极端版本——如果在多个地方定义了某些东西,则表明模型存在缺陷。这延伸到所有正在考虑的领域,因此系统的构建方式仅在一个地方定义。
- 一个域,一旦建模,很可能是相当静态的。抽象级别越高,更改的可能性就越小。
- 模型的范围可能比传统开发的范围更窄、更深。与传统建模相比,特定领域内的对象可能更少;但是这些模型必须是完整的,并且有一些测试可以表明模型的完整性(显然,永远无法证明系统描述是完整的)。
- P用M定义的术语来描述。该模型可以表示为图表、OO 表示、数学公式或适用于域M的任何内容。
以下示例源自我的概念验证项目,可能会为我上面的描述提供一些内容。我列出了我的一些领域,以及领域模型的候选内容。
- P [车辆、单位、运动、疲劳、速度……]
- P1 [规则、适用性、状态、优先级...](附属问题域)
- M [对象类型、属性、关系、域...]
- A [事件、表、列、数据库域、类...]
- F【持久化机制、处理……】
- C [数据库模式、源代码、SQL 脚本、构建脚本……]
- R [形式主义、变换、映射...]
这种方法至少有一个主要缺点 - 管理层认为开发模型所涉及的工作是非生产性的,没有产生真正的可交付成果。
该答案的来源多种多样,但确实严重依赖以下作品:
- Michael Jackson 谈结构化编程;系统分析; 和问题域描述。
- Shlaer-Mellor 的系统开发方法是通过转换而不是精心设计。
- Kennedy-Carter 方法咨询公司。