科学与工程通用框架 - 第12部分：宏伟项目

Petr Ivankov

3.69/5 (18投票s)

2008年11月21日

CPOL

48分钟阅读

62946

4854

科学与工程通用框架在宏伟项目中的应用

其他有用资源

引言

在我之前的文章中，我曾说过，任何工程师都可以使用科学与工程通用框架来解决任何任务。显然，框架应该通过某种方式进行扩展，但它没有扩展的障碍。框架与其说是一个软件，不如说是一种哲学。这种哲学基于范畴论。框架的理念与范畴论的理念一样，都是为了实现统一。我曾写过一篇关于范畴论和框架的文章。现在我意识到，任何工程任务都不是框架的真正目的。框架的目的是为了发展宏伟项目。本文将解释框架的哲学如何应用于宏伟项目。历史上有很多宏伟的项目。但许多项目实际上是未知的。例如，胡夫金字塔项目实际上是未知的。根据科学家的观点，任何现象只有当我们能够重现它时，它才是已知的。所有关于这个项目技术的猜测都只是假设。也许其技术比所有这些猜测都要高明得多。我从未接近过任何宏伟项目。然而，我曾对制造宇宙飞船有很多想法。这个问题超出了我的理解范围。如果火箭上的任何一个小部件都会导致它毁灭，那么你如何制造它？如果你无法掌握其元素的物理特性，你又如何制造火箭？我在《永恒的建造之道》一书中找到了这个问题的答案。克里斯托弗·亚历山大证明了《永恒的建造之道》的原则不依赖于领域。我敢肯定，胡夫金字塔和宇宙飞船的创造者都明白这一点。即使是我自己也能独立理解这一点。但是，理解与证明之间存在很长的距离。理解与描述之间的距离可能更长。《永恒的建造之道》已经存在了几千年，但对其清晰的描述直到20世纪才出现。事实上，我解释的是相同的想法。但我的文章包含源代码和示例。根据我的经验，带有代码和示例的文章比没有它们的文章更容易理解。我认为CodeProject会员是宏伟项目创建者的绝佳人选，原因如下：

CodeProject会员可以理解其他开发者编写的代码。代码量可能非常大；
CodeProject会员充满主动性。

出于这些原因，本文适合CodeProject。还有另一个原因。框架并非易于理解。因此，本文包含相对简单的框架扩展示例。

背景

众所周知，宏伟项目并非一系列工程任务。这些任务需要相互协作。项目经理应该理解所有这些任务。显然，经理无法详细了解所有任务。但他/她需要有足够的理解，以便整个项目能够实施。现在，有许多针对项目经理、软件开发人员、软件项目测试人员的工具，以支持他们的工作。我认为，框架是任何类型工程项目的此类工具的原型。本文并未涵盖此事的全部功能。但我和我未来的继任者将撰写更多相关文章。

1. 宏伟项目的生命周期

宏伟项目的一个基本特征是它原则上无法实现。如果一个项目可以实现，那么它就不宏伟。CodeProject致力于实现的代码示例。然而，我认为尽管有这种情况，本文并不违反CodeProject的宗旨。本文包含代码（完成后）。也许一些读者会尝试宏伟项目。我不建议我的读者对他的主管说：“我有一个原则上无法实现的宏伟想法。”主管的反应将是完全正常的。最好是为这个想法寻找赞助人。我个人有无法实现的想法的经验。原则上，当今的数学研究需要全职投入和数学教育。我两者都没有。尽管如此，我仍是一名数学研究员http://arxiv.org/abs/math/0604508。因此，我想解释一个原则上无法实现的想法的生命周期。

1.1 第一阶段

一个年轻人有一个宏伟的想法，并向他的主管解释。在主管做出正常反应后，他/她认为他的主管不太对。在这种情况下，想法的生命周期就结束了。
也许我从拒绝宏伟想法的主管那里收到了第一个低评价。我认为这些主管完全正确。我表示“感谢”。这些评价激励我写下这段文字。
但是，如果年轻人有足够的自我批评精神，他/她可以继续发展他的宏伟想法。
暂停：我去吃午饭。
此阶段可以省略。如果您阅读本文，您将永远不会将宏伟的想法介绍给您的主管，而是直接进入第二阶段。

1.2 第二阶段

此阶段不可省略。您应该尝试说服别人，这个想法不是纯粹的虚构。这是一项非常艰巨的任务，因为即使您自己也不知道这个想法是否会实现。
很多人会认为您疯了。如果您不能容忍别人说您疯了，那么这个想法就无法实现。
宏伟的想法有很多悖论。如果您不自我批评，它就无法实现。否则，它就是“原则上不可能”。您应该非常谨慎。但您不应该害怕有错误的草稿。如果潜在赞助人注意到您不够谨慎，他们就不会相信您。否则，过度的准确性会阻碍这个想法。
然而，勇气并不与谨慎相矛盾。
在这个阶段，很多人会说您疯了。您应该对此泰然处之。

1.3 第三阶段

此阶段是想法的实现。由于这个想法是宏伟的，所以没有保证。然而，即使想法失败了，您也能获得很多好处。例如，我对数学的投入刺激了我的大脑。所以我能写这篇文章。尽管框架尚不是宏伟项目的基础，但它包含了很多有用的代码。这使我的文章很有趣。它激励人们。我使用我自己的经历来获得灵感。我发现这帮助了很多年轻人。
暂停：我将打印文本并进行修正。

2. 死锁

宏伟项目存在许多看不见的障碍。它应该足够灵活，能够避免它们。每个软件开发者都知道，项目死锁是由不熟悉技术的经理引起的。这位经理无法理解究竟什么是看不见的障碍。每个领域都有看不见的障碍。我知道许多Simulink工程开发项目都遭遇过死锁。然而，这些项目的开始是非常成功的。军事艺术也充满了死锁。非常精确的作战计划是失败的根源。拿破仑·波拿巴在一场战役中使用了几个计划。然后他采用了最适合当时情况的计划。
一般来说，任何领域都使用类似的方法来避免死锁。这种方法是一系列不同的变体。软件开发使用抽象。然而，抽象使我们能够提供非常多的变体。拿破仑·波拿巴不像软件开发抽象那样拥有如此多的变体。
现在我将解释我如何在框架中避免死锁。框架基于范畴论。该理论在数学中具有更高的层次和通用性。因此，框架对看不见的障碍非常稳定。这一点已通过其许多应用得到证明。但我正在寻找新的应用来测试框架的稳定性。
框架的公式编辑器中存在潜在死锁。这个编辑器有一个非常慢的解释器。从一开始，我就知道公式编辑器性能低下会导致死锁。但我知道我将来会避免这个死锁。

在第11部分中，您可以通过CodeDom优化编译器找到解决此死锁的方法。

在将量子化学并行计算项目应用到框架时，发现了另一个死锁。该项目包含通过一组处理器进行的并行计算。根据我的观点，并行计算应该有一个抽象层次。现在它可以在多核上实现。但下一代计算机可能具有其他类型的并行化。
但最近我发现框架中存在一个潜在死锁。框架本身并未被领域专家接受。无论如何，我找到了以下死锁解决方案：将框架开发转换为领域专家熟悉的语言。
在撰写本文的过程中，我决定写一个如何避免死锁的例子。我曾做过很多高风险的开发。但这段文字可能会把我描绘成一个冒险家。然而，避免这个死锁非常容易。首先，我在技术文档方面非常严谨。我是多个企业标准的发起人。但我自由撰写的文章包含很多玩笑。我需要聪明的学生。而玩笑是检验我学生的绝佳方式。我之前的CodeProject文章也包含很多玩笑。我希望我的读者能注意到它们。而且我并不害怕被人称为纯粹的冒险家。这篇文章也可以被解释为玩笑。我认为宏伟项目的未来创造者应该区分严肃的想法和玩笑。本文也包含一个玩笑。我教我的学生避免签署未完成的文件。前苏联有一个非常有趣的未完成文件签署的例子。一位主管签署了一份未完成的文件。然后他的员工写道，他的主管是个傻瓜。这位主管陷入了死锁，并辞职了。现在，本文的结尾是“未完待续…”。这意味着这份文件未完成。但我已经收到了两份文章评价。所以，我无权将标记我的文章的人与苏联领导人相提并论。当文章不再包含“未完待续”的文字时，我就失去了进行此类玩笑的权利。
这个例子表明，如果宏伟项目的创造者过于轻信，死锁就不可避免。CodeProject致力于软件开发。为什么我在其中讨论挑衅？我注意到，许多优秀的软件开发者之所以不成功，是因为他们过于轻信。这个事实使他们的技艺归零。所以我不仅仅教我的学生技术。

3. 项目经理

项目经理是项目中的关键人物。尤利乌斯·凯撒写道，他有一次忽略了一个小细节。结果导致他的许多士兵丧生。这意味着经理的角色比他所有的士兵都重要。如果尤利乌斯·凯撒生病或疲劳，一个微小但非常重要的细节可能会被忽略。存在矛盾。经理无法掌握宏伟项目的全部细节。否则，一个小细节就会导致项目失败。有很多文章说：“项目经理不应该懂技术。”我知道很多项目因为经理不懂技术而失败。这种矛盾可以通过以下方式解决：经理应该能够快速找到小的、重要的细节。例如，高中毕业后，鲍里斯·叶利钦尝试过各种建筑行业。其中一种职业是起重机操作员。在成为起重机操作员期间，他避免了一起事故。当他成为注册工程师时，他就能自己评估起重机操作员的工作。一些操作员希望高估自己的工作以获取更多报酬或减少工作量。然而，一些操作员可能会低估自己的工作。这些操作员可能会导致事故。我认为，叶利钦的这段经历帮助他在担任俄罗斯联邦总统期间避免了重大事故。叶利钦犯了很多错误。其中一些是由于他的疾病造成的。但我认为，在他提名期间更换总统并不能避免这些错误。频繁更换国家领导人并非包治百病的灵丹妙药。

现在我解释一下框架哲学如何帮助项目经理。首先，框架提供了一种经理熟悉的语言。此外，经理可以轻松地向其团队成员解释任务。

例如，Team Foundation Server和Rational Software在软件开发领域有相同的目的。

然而，宏伟项目可能包括量子力学、传热学、材料科学、光学、空气动力学等领域的专家。所有团队成员都应向经理解释他们的问题。经理也应向团队成员解释任务。

众所周知，纯粹的垂直管理效率不高。团队的一名成员应该向另一名成员解释他们的问题。框架使这个过程变得非常容易。核心思想是众所周知的。它借鉴了形式语言理论。存在一组语言。我们也有一个通用语言。翻译如下：

语言1 -> 通用语言 -> 语言2。

例如，语言1是力学语言，语言2是控制理论语言。

以下文本包含项目经理与其团队成员之间通信的示例。

项目经理的一项任务是实时工作。我现在正在实时写这篇文章。我注意到，今天这篇文章的浏览量创下了447次的记录。这并非Code Project的记录，而是我自己的记录。我已经收到了两票。这也是我自己的记录。我还收到了两个评分1。这也是我自己的记录。因此，我得出以下结论：

本文比我以前的文章更具影响力。

我应该弄清楚为什么我得到了两个1分评分。

也许我得到了叶利钦的评价。许多俄罗斯人讨厌他。也许这个评分是由实时语法引起的。确实，宏伟项目不允许有糟糕的语法。但草稿允许。然而，项目经理应实时纠正语法。也许我得到了那些不懂技术的经理的评价。我很容易接受这些人的意见。

但是，那些在我的文章中发现实际错误的人的意见对我非常重要。根据我的经验，过快的评价是不客观的。今天我写了文章的五分之一。所以我也很容易接受这些评价。此外，我现在认为如此快的评价非常好，因为它意味着我的文章很有影响力。但进一步的分析可能会改变这种看法。

该睡觉了。我明天早上会修正语法。事实上，我今天写了3.3.2控制理论。但这与实时项目经理工作有关。项目经理应该同时写一组章节。尤利乌斯·凯撒能够同时写作、阅读和说话。再见。等待明早的续集+3 GMT。

大家好。我醒了，修正了语法。现在我正在写关于宏伟项目生命周期的章节。

4. 心理学

CodeProject致力于软件。但我发现它包含很多心理学信息。许多关于用户界面的文章都具有有趣的心理学方面。此外，许多文章包含关于软件开发人员心理学的信息。我更像是一名工程师，我想讨论工程师的心理学。我曾告诉一位航空工程师，我将为飞机提供20g的加速度。他大喊：“停下！！！”但飞机是虚拟的。事实上，我认为抽象层次比专业更重要。我将这种更高级别的抽象称为“无处不在的勺子”。这个层次使您能够进行任何智力工作。我经常在纯粹的数学家、软件开发者和极端专家中发现这种层次。根据我的观察，“无处不在的勺子”在工程师和应用数学家中非常罕见。在框架开发初期，我想提高工程师的抽象水平。这项任务超出了我的能力范围。我回想起普希金的悲剧《莫扎特与萨列里》。莫扎特说：“萨列里，我的朋友，不可能所有人都成为音乐天才。”我希望亚历山大·普希金能原谅我从俄语翻译。由于我无法全球化“无处不在的勺子”层次，我决定开发从“无处不在的勺子”到工程师熟悉的语言以及反向的转换器。我认为这个想法对宏伟项目非常有益。

有一种观点认为，长时间工作可能导致大脑疲劳。但我认为这并不完全正确。我进行了多年的大脑锻炼。结果，我获得了“大脑后燃”的能力。两个小时的“大脑压力”会让我非常疲劳。我明白，如果我具备“大脑压力”的能力，我就应该将框架应用于不具备这种能力的人。一种非常自然的方法是从框架语言转换为领域专家的语言，反之亦然。一个聪明的开发者只为自己开发清晰的软件是众所周知的。我认为我们不应该要求他立即制作适配的软件。如果我们这样做，我们可能会破坏一种非常有益的语言。然而，开发者应该能够从他的语言与熟悉的语言之间进行转换，反之亦然。

当我写完以上文字时，我发现“大脑压力”能激发有趣的创意。我正在实时模式下写这篇文章。我明白很多人现在都在读它。这个事实激励了我。当然，我稍后会修正文本。但实时模式有很多好处。

值得一提的一个心理学方面是，如果一本书或一篇文章是关于作者本人的，那么它会非常有影响力。尤利乌斯·凯撒和鲍里斯·叶利钦都写过关于他们自己的事情。此外，他们是在危急情况下写的。不幸的是，宇宙飞船的创造者没有这样做。我认为我们永远不会知道宇宙飞船实际上是如何建造的。我向未来的宏伟项目创造者提出建议：“写写你自己。立即写作。如果你不立即写作，那么你的项目的宏伟性将永远不为人知。”

本文的读者可能会发现其中存在混乱。这是宏伟项目的一个悖论。混乱和强大的秩序同时存在。我在尤利乌斯·凯撒和鲍里斯·叶利钦的书籍中发现了这一点。

5. 集成

宏伟项目的关键问题是集成。我们可以在数据库领域观察到类似的情况。宏伟的数据库应该集成许多数据源，这些数据源以不同类型的数据库表示。集成服务可以解决这个任务。

现在我想描述另一个集成示例。所有C#语言对象都有自己的C#函数GetType()。但C++对象没有这个函数。每个好的C++项目都有一个类似的函数。量子化学并行计算项目有一个类DescribedClass，它有一个函数ClassDesc* sc::DescribedClass::class_desc ( ). 事实上，这个函数是C#函数GetType()的C++等价物。其结果是我们有很多非常好的C++项目，但很难将它们合并。我们没有一个GetType()，而是有许多。我写这个是因为我真的很想将量子化学并行计算集成到框架中。此外，我想使用多核技术来实现并行计算。但我希望框架可以轻松地集成到其他项目中。因此，我选择了C#而不是C++。

但是C#也有缺点。C#现在没有好的矩阵向量代数标准库。每家公司都开发自己的库。例如，XNA Game Studio Express是3D游戏开发的绝佳工具。此外，我发现它也是航空航天模拟器的绝佳工具。然而，它包含自己的3D向量。因此，工程软件开发者应该将自己的n维向量适配到XNA的3D向量。否则，框架有自己的n维向量，而其他工程软件开发者应该将框架的向量适配到他们自己的向量。如果C#拥有内在的向量矩阵代数，那么我会使用它以更好地与其他第三方软件集成。然而，框架本身也可以是第三方软件。好的软件可以使用第三方软件，也可以是第三方软件本身。

6. 宏伟项目构建示例

以下是一个受控航天器的构建示例。航天器是一种带有控制系统的机械装置。

6.1. 步骤1. 力学+控制系统

航天器的开发包括力学和控制理论专家的工作。他们懂自己的语言。

6.1.1 力学语言

以下是力学语言的典型示例

这些图片展示了力、速度和质量。现在有许多机械软件产品。也许现在已经有可以直接处理上述图表的软件。

6.1.2 控制理论语言

以下图片展示了控制理论语言的典型示例

Simulink能够理解这种语言。您可以在这里找到Simulink在控制理论中的应用示例。

6.1.3 通用框架语言

通用框架应理解力学和控制系统。

6.1.3.1 力学

框架在力学中的应用在第9部分中有描述。我将重复第9部分的一些引用。

让我们考虑以下使用框架模拟集合动力学的例子。这个例子包含一个具有5个连接**C 1**...**C 5**的航天器。飞轮**F 1**、**F 2**、**F 3**和光伏板**P 1**、**P 2**、**P 3**连接到航天器（见下图）

框架如下所示展示了这个集合

比较这两张图片很容易。

6.1.3.2 控制理论

您可以在第3部分中找到框架在控制理论中的应用。下面展示了一个框架语言在控制理论中应用的示例。

现在框架还不太为人所知。许多控制理论专家可能无法接受它。因此，应该开发框架语言到控制理论语言的转换器（见2.2节）。根据怀疑论者的观点，开发额外的软件会增加时间和资金的投入。然而，我自己的经验表明，开发软件比用手和图片解释更容易。

此外，框架语言具有一些对控制理论专家非常方便的特性。例如，它包含传递函数的解析指示。

此外，控制系统包包含狄拉克δ函数。

这个函数不仅对控制理论有用。

6.1.4 力学和控制理论的联合

现在我们应该控制航天器，它实际上是一个机械装置。

框架的通用性使得这项任务更加容易。

6.2 添加磁场

许多航天器都有磁力控制系统。因此，我们应该使用地球磁场模型。这种情况在下图所示：

图片中的参与者是航天器、地球磁场、弹性振动体、飞轮稳定器和控制磁铁。所有这些参与者都相互作用。这个场景在第9部分中有描述。框架展示的场景如下：

6.3 传感器。再次提及力学

经典的控制方案如下图所示：

它的一个组成部分是传感器。许多航天器使用陀螺仪作为传感器。但陀螺仪是机械装置。

6.4 更多传感器。再次提及磁场

众所周知，陀螺仪有漂移。为了补偿它，我们应该有其他传感器。一种参考传感器是磁力计。

6.5 再次提及更多传感器。星图

航天器可能拥有冗余传感器。它们的模拟需要星图。第2部分和第7部分展示了与星图的工作。

6.6 虚拟振动台。再次提及控制理论和力学

非线性力学模型不利于控制理论。为了获得控制理论，我们可以构建一个虚拟振动台（第9部分）。它使我们能够获得线性模型。

6.7 真实振动台

虚拟现实与现实不同。除了虚拟振动台，还有真实的。通过处理真实振动台的数据，我们可以获得更准确的模型。第3部分专门讨论数据处理。

6.8 观测。再次提及星图

许多航天器任务是星体观测，所以我们再次需要星图。

6.9 虚拟现实

如果航天器是一个有人居住的空间站，那么宏伟项目就包括飞行员的训练。所以我们需要虚拟现实。但这种虚拟现实并非孤立存在。它应该与上面描述的其他方面相联系。第7部分专门讨论虚拟现实。

6.10 带有星星的虚拟现实。再次提及星图

航天器虚拟现实包含星图的图像。所以我们再次需要星图。

6.11 螺旋模型

现在我们已经建造了航天器。但我们应该对其进行修正。这个操作类似于软件开发的螺旋模型。如果我们有一个完整的单一模型在通用框架中，那么下一次迭代将变得更加容易。

7. 宏伟项目整体。再次提及集成。再次提及项目经理。

大家好。请原谅我的暂停。我去了我的工作，再次经历了“大脑压力”。这激励我继续写作。

我想解释为什么我们需要将宏伟项目作为一个整体进行模拟。以下情况很常见。宏伟项目通常被分成不同的组件。

两个组件都有以圆形表示的对象。在这个图中，我们有一个高层次的抽象。每个圆都可以是设备、船只、社会群体等的一部分。我们不要求所有圆都具有相同的类型。对象之间的线条表示影响。影响可以是电的、热转换的、信息的等等。

现在我们连接两个组件。

我们有额外的链接。在连接之前，两个组件都很好，但整个结构却不是。现在，许多宏伟项目的计算机模型仅是其组件的模型。我认为，我们应该有一个整个项目的模型或接近完整的模型。

现在让我们考虑以下情况：

在这个图中，红色对象不正确。但它本身并不错误。它不正确是因为蓝色对象的影响。软件开发知道这种情况称为诱发错误。在软件中很难找到它。但在工程设备中找到它要困难得多。

我从未接近过宏伟项目。但我构建了非常复杂的模型。其中一个如下所示：

我无法在这样的模型中找到错误。框架向我显示红圈，但我找不到蓝圈。然后我开发了许多寻找蓝圈的方法。我将在以后描述它们。这个例子表明，我们应该开发整个宏伟项目的计算机模型或为之努力。框架是宏伟项目模型的一项工作。

其目标是潜在的无限集成。我已经在本文中说过，小细节会毁掉整个项目。整个项目的计算机模型可以帮助项目经理找到这个小细节。

8. 无处不在的勺子

“无处不在的勺子”意味着高层次的抽象。作者是非交换几何的研究员，也被称为非几何。这种几何没有点。没有点的几何是一个悖论。但我们如何证明真实宇宙有点呢？点的存在问题在古代就已为人所知。根据亚里士多德的观点，点的存在意味着我们可以将空间无限细分。但这种实验原则上是不可能的。

高抽象级别提供了许多好处。我将在下面讨论它们。

我曾与许多人就框架进行过讨论。有些人告诉我它的组件类型很少。但使用少数组件类型，我可以解决很多任务。每个软件开发者都知道，最佳实践是减少组件类型。向软件开发者解释抽象数据库很容易。他/她会理解“无处不在的勺子”。但向无线电员解释“抽象物理场”非常困难。根据我的经验，“抽象物理场”非常有用。我面临一个困境。第一种方法是向无线电员解释“抽象物理场”。第二种方法是放弃“无处不在的勺子”。这两种方法都不好。然后我找到了这个困境的标准解决方案。这个解决方案在设计模式中是众所周知的，我们开发新版本的软件，但我们不想放弃旧版本。然而，现在我们没有旧软件。我们有一个不理解“无处不在的勺子”的高专业无线电员。

我认为读者会原谅我文章中的错误。我稍后会修正它们。本文是在与其他工作之间的短暂休息时间里写成的。但这些其他工作会给我带来新的想法，我应该立即写下来。我没有CodeProject编辑器的离线版本。尽管未编辑的有错误的版本被许多人阅读过，但使用在线CodeProject编辑器将更快地完成完整版本。

暂停工作。

在我的工作中，我发现实时模式的新好处。我的同事告诉我，有一个与SCADA相关的新问题。我回答说，这不是新问题，框架早就解决了。现在他们缺乏“无处不在的勺子”的理解。但几年前我也缺乏。我应该再次解释“无处不在的勺子”。本文也进行了这样的解释。下面的文本专门讨论“无处不在的勺子”的例子。

这些例子非常不同。“无处不在的勺子”的艺术包括在不同的事物之间找到联系，例如普鲁塔克的《平行生活》。框架的哲学也包括“在不同事物之间找到平行”，正如任何优秀软件的哲学一样。

大家好。我醒了。我发现我得到了5分。这意味着我应该在这篇文章上尽力而为。我承诺稍后改进我的英语。今天我将解释“无处不在的勺子”的第一个例子。

8.1 示例1。再次提及无线电员

有一种观点认为哲学与现实无关。例如，“老式专家就像C代码”仅仅是一个比喻。但我有一个实际的实现。可以使用适配器模式来适应C代码。我使用这种模式来适应不理解“无处不在的勺子”的无线电员。也许无线电员以后会理解“无处不在的勺子”。他/她是我的朋友，我会和他/她有很多讨论。但我想今天就用他/她。所以框架需要一个他/她现在能理解的附加接口。典型的提供附加接口的软件示例是RSView和LabVIEW。他/她不是唯一的无线电员。有许多无线电员不理解抽象物理场是什么。一种“无处不在的勺子”的意思是“C代码和无线电员之间没有区别”。普鲁塔克曾因其类比而受到批评。作者也因将C代码与无线电员进行类比而受到批评。也许后代会写下关于普鲁塔克和作者之间现场类比的文章。

8.2 示例2。回归分析

在撰写这篇文章时，我明白了为什么“无处不在的勺子”对许多软件开发者来说很清晰。C#有一个函数Equals。Java也有类似的函数。这个函数可以重载。结果是，即使对象类型不同（非继承），非常不同的对象也可以相等。许多开发者使用它。下面的公式

SQL查询 = 位图 + 数字滤波器 = 3D形状 + 虚拟相机 + 位图 + 数字滤波器

是另一个“无处不在的勺子”版本。我将证明这个公式。所有相等元素为回归分析提供实验数据。回归分析在第2部分中有讨论。

8.2.1 实验数据

回归运算处理实验数据。这些数据是一组实数。框架结构使我们能够设置上述等式，因为它们都提供一组实数。我在此重复它们：

SQL查询 = 位图 + 数字滤波器 = 3D形状 + 虚拟相机 + 位图 + 数字滤波器。

让我们考虑这个方程的每一项。

8.2.1.1 SQL查询

很容易理解SQL查询如何提供一组实数。框架提供SQL查询。

然后我们有以下实验数据：

实数是这个图表的横坐标和纵坐标。

最后，使用回归分析，我们近似这些数据。

蓝线是近似结果。

8.2.1.2 位图 + 数字滤波器

现在我们有以下位图。

我们想从中获得一组实数。为此，我们对位图进行了过滤：

黑色点的坐标可以转换为实数。当然，我们可以为我们的图像类实现选择接口。但这并非一个好主意，因为随着时间的推移，图像将拥有许多接口。在这种情况下，适配器模式要有效得多。框架遵循适配器模式的道路。

左边的元素是图像，右边的元素是从图像获得的选区。然而，它具有桥模式的特性。它是从图像到选区的桥梁。它为回归提供选区。因此，框架在用户界面级别包含设计模式。无线电员很难理解它，但它非常有效。通过将箭头从一个块设置到另一个块，人们就可以选择图像。无线电员将使用我下面将要描述的另一个用户界面。因此，我们有一个选区，我们可以对其进行近似。近似结果如下所示：

8.2.1.3 3D形状 + 虚拟相机 + 位图 + 数字滤波器

这个例子也是“无处不在的勺子”。我们有一个位图。

我们还有一个3D形状和一个虚拟相机。

过滤下面显示的图像后，我们得到以下红蓝曲线：

红线来自位图，第二条来自相机和3D形状。我们想用第二条曲线近似第一条曲线。换句话说，我们想找到平面的位置和方向。近似结果如下所示：

在这种情况下，我们有一个非常有趣的桥模式案例。我们有一个来自两个对象的选区：相机和图像。

我称之为双向桥。选区由蓝色和红色轮廓的差异构成。红色由**图像**提供，蓝色由**相机**提供。选区结果用于**回归**。箭头表示对象消耗图像。箭头表示**相机**正在观察**平面**。这种语言看起来很陌生。然而，它非常自然，并且与现代IT的语言非常相似。这种语言的优点在于它的简洁性。众所周知，数学公式比文字解释更清晰。同样，使用图标也非常清晰。在21世纪，文字解释看起来就像巴比伦数学。

8.2.2 回归方程

回归分析不仅包括实验数据。另一个基本要素是回归方程。这也是“无处不在的勺子”。以下文本描述了一系列回归方程版本。

8.2.2.1 有限公式

有限公式是回归方程的一个非常简单的例子。在8.2.1.1和8.2.1.2中，我使用了以下公式：

其中a、b、c、d、f、g是未知参数，x是自变量。

8.2.2.2 复杂常微分方程

在第6部分（关于确定人造卫星轨道）中，我考虑了一个复杂的常微分方程。其未知参数是卫星的初始坐标和3D速度。在这种情况下，我们没有明确的公式。

确定人造卫星轨道的方法是众所周知的。有许多软件致力于这些方法。但人们不知道它可以包含在一个更通用的框架中。

8.2.2.3 3D形状 + 虚拟相机 + 位图 + 数字滤波器（再次）

这个版本的回归方程在8.1.2.3中讨论过。未知参数是平面的坐标和3D方向参数。很明显，我们再次没有明确的公式。回归方程包括3D平面模型、虚拟相机、数字滤波器。这不是一个方程。它更像是“又是无处不在的勺子”。

8.3 示例3. 变更请求。战斗障碍。再次提及拿破仑·波拿巴

有人问我：“你为什么要学习历史？你为什么要学习军事艺术？”我回答：“这与我的工作有关。”“拿破仑·波拿巴在一场战役中使用了几个计划”这句话看起来很简单。它没有“无处不在的勺子”。但实际上它暗含了“无处不在的勺子”。战斗障碍是看不见的，就像变更请求一样。“拿破仑·波拿巴在一场战役中使用了几个计划”意味着他可以预测看不见的战斗障碍。这并不容易。这也是“无处不在的勺子”。

8.4 示例4. 道德因素。再次提及拿破仑·波拿巴

道德因素也是看不见的。拿破仑·波拿巴了解它。但历史知道其他受教育程度低的军事天才。例如，瓦西里·恰帕耶夫和盖乌斯·马略就是这样的军事人才。像普鲁塔克一样，我找到了他们之间的现实类比。他们也理解道德因素。瓦西里·恰帕耶夫引用拿破仑·波拿巴来提高士兵的士气。拿破仑·波拿巴的引用提高了瓦西里·恰帕耶夫的权威。宏伟项目也有道德因素。读者应该明白为什么本文作者要引用瓦西里·恰帕耶夫。

8.5 示例5. 宇宙飞船设计

这篇文章看起来像混乱。但如果你想在一份文件中描述一个宏伟的项目，你也会发现混乱。文章实际上是一个扁平文件。任何严肃的项目都不是扁平的。它包含类接口等的复杂组合。但它不是面条代码。它是结构良好的。这篇文章更像是一种启发，而不是宏伟项目的指南。因此，它包含历史名称。本文包含代码重用。例如，示例1是“无处不在的勺子”的示例。但它可以被希望使用无线电员的项目经理使用。因此，示例1与关于项目经理的章节有关。本文还包含递归。像普鲁塔克一样，本文也包含类比，然后我们就有了一个关于本文作者和普鲁塔克之间的类比。

有一种观点认为，这种方法与宇宙飞船设计无关，因为它不接受混乱。但宇宙飞船设计包含大量的代码重用和递归。此外，它还包含“无处不在的勺子”。宇宙飞船有许多相互协作的子系统。其中一些子系统是同时设计的。因此，一个系统并不完全了解另一个系统。另一个子系统对第一个系统来说就是“无处不在的勺子”。

8.5 示例6. 复杂的数学

复杂的数学包含一些无法解决或非常难以解决的问题。但“无处不在的勺子”可以轻松解决这些问题。以下是这类解决方案的示例。

8.5.1 量子色动力学

量子色动力学处理我们无法计算的值。但我们可以计算这些值之间的关系。这一事实可用于实验检验。“无处不在的勺子”意味着我们不应该计算值。

8.5.2 已知变体

我曾经需要解决一个与材料强度有关的任务。我应该从以下公式中选择一个变体：

公式1、2和3对我来说是已知的，但我现在记不起来了。我明白了公式是

我没有尝试计算整个积分，甚至“…”也没有。我立刻找到了正确的结果。我认为读者也会这样做。

8.5.3 数学知识贫乏。再次提及瓦西里·恰帕耶夫

瓦西里·恰帕耶夫的数学知识非常少。有人问他：“0.5 + 1/2 等于多少？”恰帕耶夫回答：“我知道它是1升（私酿酒），但我无法证明。”事实上，恰帕耶夫用他的想象力弥补了他有限的知识。有很多笑话是因为恰帕耶夫具有非凡的才华但数学知识却很少。

8.5.4 数值实验

许多软件开发者有以下问题。他们应该选择“+”或“-”。简单的解决方案是先设置“+”。如果不行，我们就设置“-”。

8.6 示例6. 视频适配器作为工程计算器

有一种观点认为，当今的IT与工程无关。此外，许多人认为视频适配器可以用作有效的多媒体设备。当今的视频适配器使用现代技术并具有高性能。它们有自己的内存，并且可以在其上绘制虚拟图像。这些特性可用于显著提高工程计算的性能。我将在下面提供关于物理光学和空间空气动力学的示例。

8.6.1 物理光学

物理光学也是一种高频近似（短波长近似）的名称，常用于光学、电气工程和应用物理学。在此上下文中，它是一种介于几何光学（忽略波效应）和全波电磁学（精确理论）之间的中间方法。单词“物理”意味着它比几何或光线光学更物理，而不是说它是一个精确的物理理论。物理光学对凸三维形状有效，但也可用于非凸形状。如果我们想使用物理光学，我们就必须定义3D形状的可见部分。通常，这个任务需要大量的计算。然而，我们可以用不同的颜色标记形状的一部分，然后定义下图所示的颜色集合。

使用这种方法，我们可以更快地定义可见部分。如果部分的数量超过颜色的数量，我们可以使用多个图像。

8.6.2. 空间空气动力学

空间空气动力学的关键特征是航天器与不碰撞的分子相互作用。因此，空气动力取决于可见面积，而与其他航天器形状参数无关。可见面积可以通过计算下图白色像素的数量来计算。

还可以轻松定义空气动力轴，然后我们可以计算空气动力矩。

9. 入门

通常，“入门”放在开头。但本文的开头包含展望。我经常被问到“如何使用框架？”我的回答是：“每个人都可以开发自己的组件并将其添加到框架中。”本章包含新组件开发的示例。

9.1 示例1. IronPython组件。再次提及集成

IronPython是一种众所周知的编程语言。许多科学和工程开发都使用IronPython。由于框架是通用的，它应该包含这些开发。这里有一个包含的示例：

下载Iron Python互操作性示例源代码 - 1.65 MB

这个示例需要Visual C# Express Edition和IronPython。您应该将IronPython.dll添加为IronPython.Library.csproj的引用。这个IronPython组件实际上是一个适配器。在这个例子中，IronPython被用作第三方。

9.1.1 功能示例

9.1.1.1 纯框架版本

已知的可视化功能使代码解释更容易。让我们考虑一个典型的数据转换任务。

框架的解决方案如下所示：

**Source**（源）是数据转换的来源。**Source**的属性如下所示：

Source包含两个公式：

公式1 = t;

公式2 = t²。

这里t是时间或任何其他自变量。这个事实通过右到左的组合框反映出来。

**Transformer**（转换器）执行**Source**提供的计算。**Transformer**的属性如下所示：

这张图表示Transformer执行以下计算：

公式1 = sin(a);

公式2 = cos(b)；

公式3 = cos(a) +1.

这里a和b由**Source**提供。这个事实在图的左侧有所体现。完整的转换方案如下所示：

**Target**（目标）指示转换结果。

红、绿、蓝曲线分别是sin(t)、cos(t²)和cos(t) + 1。

单击此处下载此示例 - 2.47 KB。

9.1.1.2 IronPython + Framework 版本

此版本使用了为本文开发的IronPython组件。转换图如下所示：

在这里，**Transformer**已被其IronPython版本替换。IronPython版本如下所示：

左上角的表格表示以下赋值：

a = Formula_1;

b = Formula_2。

由于我们使用“*Source.Formula_1*”和“*Source.Formula_2*”的表示法，因此这两个公式都从**Source**导出。Python代码框包含IronPython代码。右上角的表格包含**Target**使用的导出变量列表。

单击此处下载此示例 - 24.1 KB。

9.1.2 IronPython组件的开发

每个人都可以将自己的组件添加到框架中。可以在单独的动态链接库中开发新组件。IronPython组件包含在两个库中。第一个包含业务逻辑。第二个包含用户界面。

9.1.2.1 业务逻辑

业务逻辑包含在IronPython.Library.csproj项目中。该项目包含一个公共类IronPythonTransformer。

与范畴论架构的任何类一样，它实现了ICategoryObject接口。这里它是一个CategoryObject的子类。同样，每个箭头对象都应该实现IICategoryArrow接口。ISerializable的实现使我们能够序列化该类型的对象。IPostSetArrow.PostSetArrow()方法在设置箭头后执行额外的操作。该类还实现了IDataConsumer和IMeasurements接口。第一个接口意味着组件可以消耗数据。在上面的例子中，它从**Source**消耗数据。IMeasurements可以命名为IDataProvider。但我将其命名为IMeasurements，因为它提供了虚拟测量。在上面的例子中，它为**Target**提供虚拟测量。

IronPython的关键特性包含在以下函数中：

        /// <summary>
        /// Updates measurements
        /// </summary>
        void IMeasurements.UpdateMeasurements()
        {
            // Updates children data
            consumer.UpdateChildrenData();
            // Sets IronPython local parameters
            foreach (string name in inputMeasurements.Keys)
            {
                parameters[name] = inputMeasurements[name].Parameter();
            }
            // Executes IronPyhon compiled ode 
            compiledCode.Execute(module, parameters);
        }

此函数执行编译代码。因此，我们使用IronPython进行数据转换。这样我们就有了业务对象。

9.1.2.2 用户界面

框架的所有版本都具有单一风格的用户界面。这种风格是IUIFactory接口的实现。IUIFactory对应于抽象工厂模式。多年来，我开发了许多IUIFactory实现。但我花了很长时间才将它们合并。最后，我开发了工厂组件AssemblyFactory，它实现了IUIFactory。现在，我们可以通过向工厂添加一个新工厂来扩展功能。我还为本文开发了PythonFactory并将其添加到现有的工厂组件中。让我们考虑PythonLibrary的一个基本特征。

        /// <summary>
        /// Creates desktop label from button
        /// </summary>
        /// <param name="button">Button on palette</param>
        /// <returns></returns>
        IObjectLabelUI IUIFactory.CreateObjectLabel(IPaletteButton button)
        {
            // Match button type to IronPythonTransformer
            if (button.ReflectionType.Equals(typeof(IronPythonTransformer)))
            {
                if (button.Kind.Equals(""))
                {
                    // Returns label
                    return UserControlLabel.CreateLabel(new Labels.PythonTransformerLabel(), button.ButtonImage);
                }
            }
            // If does not match then return zero
            // True label will be returned by following factories
            return null;
        }

此函数从选定的调色板按钮创建桌面标签。下图说明了其含义：

因此，我们有了必要的业务逻辑和用户界面。它们是框架扩展的必要组成部分。

9.2 航空训练模拟器

有许多游戏生成器。我想展示它们如何用作航空航天模拟器。飞行驾驶可能非常困难。在首次飞行之前，米格-31的飞行员需要大量训练。即使是非常有经验的飞行员格奥尔基·别列戈沃伊也无法完成地月轨道对接。苏联首次地月轨道对接是在开发了训练模拟器之后才完成的。此示例需要Visual C# Express Edition和Microsoft XNA Game Studio 3.0。

9.2.1 控制系统设计工作站

航空训练模拟器的开发是许多不同类型专家的联合工作。它包括空气动力学和力学研究。现代飞机使用自动驾驶仪。因此，控制系统专家也应该被包括在内。飞机控制任务如下所示：

图中所示的飞机看起来不现实。它来自Microsoft XNA Game的示例。下面展示的飞机模型并不完全逼真。但它包含许多定性成分。上面的图片意味着Microsoft XNA Game Studio 3.0和现实物理学的结合具有很多优势。

我将在此简要解释真实物理学家的工作。框架的一个版本名为“航空+控制系统”。它为力学和控制系统专家提供了一个单一的设计工作站。该工作站的桌面如下所示：

让我们简要描述图中所示的组件。

9.2.1.1 刚体动力学

飞机运动由刚体动力学方程描述。因此，框架的“航空+控制系统”版本包含刚体动力学组件。其属性如下所示：

刚体动力学的输入属性包括位置、方向、线速度分量和角速度分量。输出参数是力和力矩。属性还包含质量和惯性张量。这些参数的值是从下面描述的桌面其他组件导出的。

9.2.1.2 空气动力学

很明显，这项任务应该包括空气动力学。在这个例子中，我考虑了跨音速情况。在这种情况下，空气动力学强烈依赖于马赫数。因此，一维空气动力学依赖性变成二维。二维依赖性如下所示：

这是阻力系数对马赫数和迎角的依赖关系。

9.2.1.3 PID控制

许多现代飞机都有不稳定的空气动力学。这些飞机需要自动驾驶仪。有许多不同种类的控制回路用于自动驾驶仪。其中之一是PID控制。它的一个必要成分是积分器。该元件用作具有以下属性的组件：

9.2.1.4 工程指示

我们已经构建了飞机及其控制系统模型。现在我们想指示它的行为。我们为此使用图形化指示器。

为简单起见，我使用了双通道自动驾驶仪。第一个通道控制俯仰，第二个通道控制速度。上面的图表显示了这些通道的瞬态过程。

9.2.2 模拟器

因此，我们有了数学模型，我们想将其用作模拟器中的第三方。首先，模型将被导出。我明白我的解释不够清楚，但我希望读者能通过提问来帮助我。

9.2.2.1 数学模型导出

9.2.2中描述的模型已保存到以下文件中：

单击此处下载航空+控制系统示例 - 16.89 KB

现在我们通过以下方式将此文件导出到模拟器项目中：

首先，我们开发导出用户控件。它包含组件UserControlSimulation。我放了DesktopHolder组件。然后我们编辑DesktopHolder的**Content**属性。我们下载Aviation_ControlSystems_sample.cfa。

现在我们应该使用DesktopHolder。下图显示了我们想要使用的对象：

有价值的组件是**Velocity diff**（速度差）、**Tangage diff**（俯仰差）和**Mea**（测量）。其他对象可视为内部（私有）。**Velocity diff**和**Tangage diff**使我们能够设置控制信号。**Mea**提供用于可视化的运动参数。

/// <summary>
/// Tangage control
/// </summary>
private IAliasName tangage;
/// <summary>
/// Velocity control
/// </summary>
private IAliasName velocity;
/// <summary>
/// Output Mesurements
/// </summary>
private IMeasurements output;

对象之间存在以下对应关系：

桌面对象	标识符
速度差	速度
俯仰差	俯仰
Mea	输出

标识符的初始化如下进行：

9.2.2.2 数学模型与用户界面的互操作性

现在我们 Now we would like to provide interopreability. 用户界面包括键盘和屏幕。为交互开发了以下委托：

/// <summary>
/// Interaction between input (keyboard) and output screen
/// </summary>
/// <param name="gameTime">Game time</param>
/// <param name="gamePadState">GamePad State</param>
/// <param name="keyboardState">Keyboard state</param>
/// <param name="position">3D position of vehicle</param>
/// <param name="direction">Direction</param>
/// <param name="velocity">Velocity vector</param>
/// <param name="up">The "up" vehicle ort</param>
/// <param name="right">The "right" vehicle ort</param>
public delegate void MotionDelegate(GameTime gameTime, GamePadState gamePadState, KeyboardState keyboardState,
ref Vector3 position, ref Vector3 direction, ref Vector3 velocity, ref Vector3 up, ref Vector3 right);

键盘和游戏时间通过以下方式提供输入：

float elapsed = (float)gameTime.ElapsedGameTime.TotalSeconds;
if (elapsed < last)
{
    if (elapsed > 0)
    {
           last = elapsed;
     }
 }
time = oldTime + kt * (double)elapsed;

// Setting time
StaticDataPerformer.Strategy.Time = time;
double timeStep = time - oldTime;
if (oldTime > 0)
{

    processor.Step(oldTime, time);
}

// Updating
StaticDataPerformer.Strategy.UpdateAll(desktop);
step.Step = current;
++current;
oldTime = time;

// Count of tangage control value
if (keyboardState.IsKeyDown(Keys.Up))
{
    if (angleCurr > -angleDiscr)
    {

        --angleCurr;

     }
}

if (keyboardState.IsKeyDown(Keys.Down))
{
    if (angleCurr < angleDiscr)
    {
        ++angleCurr;

    }
}

double angle = (double)angleCurr * angleStep;

// Setting tangage conrol value
tangage.Value = angle;
if (keyboardState.IsKeyDown(Keys.Space))
{
    if (velCurr < velDiscr)
    {

        ++velCurr;
    }
}

if (keyboardState.IsKeyDown(Keys.Back))
{
     if (velCurr > 0)
     {
        --velCurr;
     }
}

double vel = (double)velCurr * velStep;

// Setting velocity control value
velocity.Value = vel;

输出的运动参数用于屏幕指示，如下所示：

// Reading parameters for 3D indication

position.X = -scale * (float)(double)coord[2].Parameter() + x0;
position.Y = scale * (float)(double)coord[1].Parameter() + y0;
position.Z = -scale * (float)(double)coord[0].Parameter() + z0;
double tan = 2 * Math.Atan2((double)quater[1].Parameter(), (double)quater[0].Parameter());
direction.X = 0;
direction.Y = (float)Math.Sin(tan);
direction.Z = -(float)Math.Cos(tan);
right.X = 1;
right.Y = 0;
right.Z = 0;
up.X = 0;
up.Y = -direction.Z;
up.Z = direction.Y;

结果是我们得到了以下模拟器：

下载航空训练模拟器项目源代码 - 1.37 MB

9.3 数字图像处理Web项目

每个现代宏伟项目都应该有Web界面。在这里，我想展示框架如何用作Web应用程序。宏伟项目的成员拥有不同的专业和熟练程度。其中一些人只能理解简单的用户界面。另一方面，框架本身非常科学密集。然而，框架的复杂性与简单的用户界面并不矛盾。我将在本章中展示这一点。

9.3.1 问题描述

许多非常有用的信息包含在旧报告或其他纸质文档中。例如，我们有以下图片：

我们希望从这个图像中获得数学依赖关系。

9.3.2 准备工作

我们使用数字图像处理项目进行准备。

下载数字图像处理项目源代码 - 1.85 MB

使用此项目，我们开发了以下内容：

让我们简要描述这张图。**Source**对象是源图像。**Transform**是**Source**过滤的结果。布尔值是过滤的关键元素。它包含以下公式：

此公式的参数r、g、b分别是颜色红、绿、蓝的强度。过滤结果如下所示：

现在我们 Now we would like approximate black points of the result by the following formula

y⁵ + bx⁴ + cx³ + dx² + fx + g;

它包含在**Regression**（回归）组件中。

**Processor**（处理器）执行**Transform**点的近似。**Graph**（图表）显示了近似结果。开发结果保存在文件*DirtyChart.cfa*中。

下载*DirtyChart.cfa* - 13.32 KB

此文件用于Web应用程序。

9.3.3 Web应用程序开发

Web应用程序使用数字图像处理项目的某些动态链接库以及文件*DirtyChart.cfa*。开发需要Visual Web Developer 2008 Express Edition。

下载数字Web应用程序源代码 - 415.06 KB

这个应用程序非常简单，我不会在这里评论它的代码。除了一个特性。开发者应该将*Resource.resx*中的参数PortalDir替换为Web项目的本地目录。这里我只解释它的用户界面。与Web应用程序的工作包含以下三个步骤。

9.3.3.1 上传图片

这一步非常简单。您只需上传图片。

9.3.3.2 过滤

这一步如下所示：

它需要选择过滤图表的红色、绿色和蓝色范围。

9.3.3.3 近似

这一步如下所示：

这一步需要选择X和Y范围。结果是我们得到了多项式的系数和结果多项式的图表。

10. 独立开发

30年前，30年前，我认为我将创建一个宏伟的项目。然而，苏联拒绝了许多有 iniciativa 的人。但我从未放弃宏伟项目的想法。我一直在独自创建它。我的灵感来自于亚历山大·伊萨耶维奇·索尔仁尼琴。他在狱中写书。而且，他写作的内容对他来说是致命的危险。他出版书籍的机会很渺茫。他很有可能在狱中死去。但他一直在独自前行。就像亚历山大·伊萨耶维奇·索尔仁尼琴一样，我也没有机会创造宏伟的项目。在苏联，这需要苏维埃共产主义党的成员资格，这与我的天性相悖。此外，苏联体制对出版我的想法有很多阻碍。也许正是这些机会的缺失，使我从抽象的层面思考宏伟的项目。而这种抽象的理解比我尝试创建宏伟项目的努力更有用。我将继续推广我的想法，时间会证明它们的有效性。我想对所有未来的宏伟项目创作者说：“单干不是坏办法。将来，你的继承者会加入你”多项式系数和结果多项式图。

11. 尾声

本文的主题将在我接下来的文章中继续。请期待。