Uml 建模软件组件及其交互的图解法；输入输出

我想对软件组件及其交互进行建模，传递什么信息，每个组件中发生什么过程（不太详细），以及组件输入/输出的明确规范

到目前为止，我在UML中看到的内容过于抽象，没有太多细节

---

有什么建议吗？

Someg-guys在论文中以图表的形式设计程序，

然后将其交给软件开发人员进行施工。

尝试这种方法：“聪明人”进行建模，并将模型传递给“普通”开发人员来完成繁重的任务这不起作用。

我们喜欢类比。很多时候，我们把它比作建筑行业，有些人做模型蓝图，而另一些人做建筑施工。我们首先认为UML或其他模型图表等同于建筑行业模型蓝图。但似乎我们错了

与建筑业打个比方，我们的蓝图不是 模型图、蓝图实际上就是我们编写的代码

详细的纸张模型，如烹饪容器

完全在一篇论文上预先设计详细的模型是不现实的。软件开发是迭代和增量的过程

想想一个地图制作者，他制作了一张和城市一样大的纸质城市地图，因为建模者包含了所有细节，没有任何抽象层次。这会有用吗

建模没用吗？

绝对不是。但是你应该把它应用到你的问题解决空间的困难部分，而不是每一个琐碎的部分

因此，与其在纸上向开发人员提供系统的每一个细节，不如使用可视化图表与开发人员面对面地探索问题解决空间中的困难部分

在软件行业，不管你喜不喜欢，源代码仍然是最重要的 国王。所有的模型在实现和测试之前都是骗子

---

这个问题似乎离题了，因为它是关于你已经知道将要结束的事情。作为一个答案似乎是合法的！但是，如果我想比UML允许的更详细地建模这些困难的部分，该怎么办？我应该使用“修改的/更详细的”组件图吗？有什么建议吗？你所说的通常也是我所想的，但有些部分只是要求我对它们进行建模，以消除在维护或扩展web应用程序时的任何误解或歧义。我不知道你的上下文。但对于非常详细的精确规范，UML不是一个好的选择。也许可以使用对象约束语言为模型提供更精确的定义。但是，如果UML不适合您的工作，就不要使用它…考虑实用和简单…也许可以使用简单的工具，如输入输出、先决条件和后条件的简单列表…要获得有关软件开发中使用的其他建模方法的简短信息，只需查看“建模软件行为：工匠方法”一书保罗乔根森