3

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

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

然而，这个项目不会让我继续编码。但我对软件设计几乎一无所知，我是自学成才（在 1990 年代中期打折的 2 年计算机研究课程）。我总是循序渐进地工作，让一些东西发挥作用，然后在它的基础上进行建设。

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

我需要建议才能越过这个障碍。我需要停止寻找分散我思路的干扰。这是干扰之一。我怎样才能越过这个街区？

4

3 回答 3

3

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

您需要准确计算出您的软件需要的响应速度、可能占用的内存量、启动速度以及可执行文件的大小。如果您使用的是普通 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
}

这有一些变化（定期回调而不是等待），但这是一般的想法。

于 2010-03-01T13:19:38.357 回答
3

在非常广泛的术语中，“软件设计”是您将手头的问题分解为一系列模块的过程，并指定每个模块的职责是什么，以及每个模块应该如何与其他模块通信（如果有的话）。

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

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

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

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

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

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

有关更多详细信息，另请参阅CRC 卡。

于 2010-02-26T15:21:50.693 回答
0

一种方法是与熟悉设计模式和设计软件的人讨论您的要求并非常粗暴地设计出一个设计。在此过程中，您可以讨论应用设计模式的概念。

于 2010-02-26T15:08:02.873 回答