embedded - 您对 Rhapsody 开发的审核流程是什么？

Question

我的团队正在使用 IBM 的 Rhapsody 工具进行实时嵌入式开发。不幸的是，我们对当前的审核流程不满意。

更具体地说，我们遇到了困难，因为:

缺少用于图表更改的良好差异工具

Rhapsody diff 工具不会生成您可以在评论中使用的报告

源文件历史是参差不齐的，因为源文件是 MDD 中的产品，因此未在 VCS 中以高粒度进行配置

在源代码上运行差异有时会引入其他开发人员所做的无关更改

有时更改模型元素的属性会更改数十个源文件

很容易通过属性更改更改源文件而不知道它

有没有人有任何关于 Rhapsody 开发的同行评审的技巧，它既健壮又轻松？您想分享哪些最佳实践和经验教训？我不是在寻找成熟的流程文章；我不知道的花絮会很棒。

Answer 1

我们在我的工作场所出于同样的目的使用 Rhapsody。模型更改的审查是通过一个脚本完成的，该脚本在我们存储库的两个副本上打开 diffmerge(一个在更改开始时，一个最晚)。这显示了所有相关的变化，没有 Rhapsody 添加的任何内部杂物。

我们的 repo 不跟踪生成的源，但我们经常看到 Rhapsody 的 sbs 文件中有很多不相关的变化。我们已经开始在文件系统上将 sbs 文件设置为只读，然后在 Rhapsody 的属性面板中将它们更改为读/写。这不会阻止您标记为读/写的文件插入 cruft，但它可以防止不相关的文件被修改。

我仍然没有找到一种方法让 Rhapsody 停止插入不相关的更改(例如:它有时会在保存之间添加和删除文件名字段，尽管对模型的更改很小)。它产生了很多合并冲突，我个人开始每次提交花费 5 分钟左右的时间来只添加重要的更改。