大脑无法理解设计实时应用程序的设计模式

发布于 2024-08-22 22:22:36 字数 527 浏览 10 评论 0原文

我给自己设定了实现实时 MIDI 应用程序的任务。与我迄今为止编写的所有其他软件一样，我也是从编码开始的。我实现了一个微型 GUI (GTK2) 应用程序，可以控制 Jack Audio Connection Kit 及其客户端的传输状态。

我以前从未写过实时应用程序，只写过一个多线程程序。这两个细节结合在一起，对我来说是一个巨大的挑战，因为我迄今为止编写的所有软件都不需要我先设计它。我只是偶尔需要笔和纸来解决问题。

然而，这个项目不允许我继续编码。但我对软件设计几乎一无所知，我是自学的（不包括 20 世纪 90 年代中期的 2 年计算机研究课程）。我总是循序渐进地工作，让一些东西发挥作用，然后在此基础上继续发展。

在我的研究过程中，我遇到了模型视图控制器模式，但我发现很难不考虑细节，并且无法找到任何可以构建的基础，除非发现导致一切崩溃的问题。

我需要建议来克服这个障碍。我需要停止寻找让我失去思路的干扰。这是干扰之一。我怎样才能越过这个障碍？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

日暮斜阳 2024-08-29 22:22:36

从广义上讲，“软件设计”是将手头的问题分解为一系列模块的过程，并指定每个模块的职责是什么，以及每个模块应如何与其他模块通信（如果有的话）。

有多种方法可以进行此活动。考虑到这是您第一次尝试，请让事情尽可能简单：拿一些纸和一支笔。

第一步：写下新应用程序必须能够执行的任务列表。
之后，尝试将您认为逻辑上属于同一组的任务分组到不同的组中。

对于每个子集，找到一个名称，将其写在空白纸上（一张纸代表子集），并更详细地描述该模块的功能，包括它应该处理哪种类型的数据和/或与其他数据交换。其中每一个都是“模块设计纸”

在另一张空白纸上为每个子集画一个框，用正确的名称标记它，并尝试从一个框到另一个框绘制箭头，每个箭头应该有一个名称并代表您的一个模块调用另一个。我们将其称为您的模块“界面设计论文”。

仔细检查您的模块描述以及它们应向其他模块提供的接口，并查看这是否需要更改原始任务列表以及这如何影响它们管理的数据。

如果模块对您来说太复杂/太大，则可以迭代地细分。如果你把一个模块分成子模块，只需再画一张界面设计纸，记住子模块的总和应该能够完成你最初为模块设想的所有任务，并能够回答其余模块的请求。系统。

另请参阅 CRC 卡了解更多详细信息。

回复收藏 0 原文

稀香 2024-08-29 22:22:36

针对这个问题已经写的答案很好，但没有一个提到实时软件开发中最独特的部分：实时技术要求。

您需要准确地弄清楚您的软件需要如何响应，它可以容纳多大的内存占用，启动速度有多快，以及可执行文件有多大。如果您使用的是普通 PC，则内存要求对您来说可能不那么重要，但无论您的目标平台是什么，运行时速度要求都很重要。

如果您的高级技术要求“足够好，让用户满意”，那么您只需担心低级技术要求 - 基本上，您的目标计算机，您的目标操作系统和您的第三个 -当事人图书馆可以处理。

听起来您已经编写了一些低级代码。我建议编写其余的硬件/操作系统/库接口代码，并为每个部分计时，无论是错误情况还是顺利的路径。这将使您更好地了解代码应如何处理其每个接口。（例如：此实用程序调用的超时时间足够长，足以使我的应用程序备份！我最好在调用它之前看看是否可以缩短超时时间或进行更好的错误检查！）

最后，最实时软件被编写为一个循环，如下所示：

while( program_running )
{
  // This period needs to be long enough for you to do your work
  //  but short enough that your user doesn't think your program
  //  is choppy. Anything better than 50 Hz is usually good enough
  //  for an application with a human interface.
  wait_for_short_period() 
  check_interfaces_for_new_data()
  update_model() // or state machine
  update_outbound_interface() // the speaker, monitor, whatever
}

这有一些变化（定期回调而不是等待），但这是总体思路。

The answers already written for this question are great but none of them mention the most unique part of real-time software development: the real-time technical requirements.

You need to figure out exactly how responsive your software needs to be, how large of a memory footprint it may hold, how fast boot-up may be, and how large the executable may be. The if you're on a normal PC, the memory requirements may not be as important to you, but the run-time speed requirements will be important whatever your target platform is.

If your high-level technical requirements are "good enough that the user is happy", then you'll only have to worry about the low-level technical requirements -- basically, what your target computer, your target OS, and your third-party libraries can handle.

It sounds like you've written some low-level code already. I would recommend writing the rest of your hardware/OS/library interface code and time each piece of it, both for error conditions and the happy path. This will give you a much better idea how your code should treat each of its interfaces. (For example: The timeout on this utility call is long enough to make my application back up! I'd better see if I can shorten the timeout or have some better error-checking before I call it!)

Finally, most real-time software is written as a loop something like so:

while( program_running )
{
  // This period needs to be long enough for you to do your work
  //  but short enough that your user doesn't think your program
  //  is choppy. Anything better than 50 Hz is usually good enough
  //  for an application with a human interface.
  wait_for_short_period() 
  check_interfaces_for_new_data()
  update_model() // or state machine
  update_outbound_interface() // the speaker, monitor, whatever
}

There are variations on this (periodic callbacks instead of waits), but that's the general idea.

回复收藏 0 原文