对于简单的应用程序功能，我应该使用什么 UML 图......？
我对此感到非常困惑，尝试阅读很多有关图表的内容，但我只是不明白什么最适合这种情况。
我只需要展示我有 10 个模块，其中有 10 个功能。该功能之一可以调用其他模块功能......
类似这样。很简单。最好是某种具有依赖关系[作为功能]的块，以及每个模块块如何与另一个块交互，
目的是展示开源系统没有什么，以及该系统将修改后有。当然，使用颜色，可以轻松显示所有修改......比开始规划项目并计算需要花费多少时间在需要做的事情上更容易。
I'm really confused about this, tried to read a lot about diagrams but I just can't understand what is most suitable for this case.
I need just TO SHOW that I have 10 modules, which have 10 features. One of that feature can call other module feature..
something like this. very simple. it's better just to be some kind of blocks with depedencies[as features] and how each module block will interact with another block
purpose is to show what open source system doesn't have, and what this system WILL have after modification. And ofcourse with colors, it's easy to display all modifications.. than it's easier to start planning a project and count how much hours will be spent on things you need to make..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
事实上，正如其他人所说，UML 并不直接支持您所需要的。据我了解，您想要捕获结构（模块）、行为（功能）和交互（依赖项），尽管是基本形式，但您的目标仍然是同时捕获太多内容。
因此，让我们回顾一下您使用 UML 的可能性，我希望这将帮助您做出决定：
包图可以将结构和依赖关系显示为包和导入
组件图表可以将结构和依赖关系捕获为带有连接器的组件
复合结构图允许通过组合、端口、连接器和协作来描述复杂的结构和交互
用例图包含与系统交互以执行用例的参与者，它可以与包图结合以简单地将系统分解为不同的模块，它们提供了不同的功能 - 用例，并且为了描述交互，您可以将参与者与用例连接起来。
因此，正如您所猜测的，我的选择将是带有包图的用例图。这些非常简单，包含少量噪音，这对于您的简单情况可能是必不可少的。这种组合可以满足您所需的大部分功能，但是，为了显示模块以某种方式交互，您需要将模块既作为包又作为参与者，这不是一个好的做法。但从你所说的来看，我猜你想宣传现有系统的变化，这在这些图中看起来很漂亮，并且很容易向对 UML 一无所知的客户解释。您可以考虑删除模块之间的交互并仅显示提供给用户（描述为参与者）的功能。
Indeed as other stated, UML does not support directly what you need. As far as I understand, you want capture the structure (modules), behaviour (features) and interactions (dependencies), although in a basic form, still you aim to capture too much at the same time.
So let us review your possibilities with UML, I hope this will help you decide:
Package diagram can show structure and dependencies as packages and imports
Component diagram can capture structure and dependencies as components with connectors
Composite Structure diagram allow to depict complex structure and interactions through composites, ports, connectors and collaborations
Use case diagram contains actors interacting with the system to perform use cases, which can be combined with the package diagram to simply decompose system in different modules, which provide different features - use cases and for depicting interactions you can connect actors with use cases.
So, as you guess my choice will be the use case diagram with package diagram. Those are goth quite simple, containing small amount of noise, which might be essential for your simple case. This combination allows for most of what you need, however, to show that modules interact in certain way, you would need to have a module both as a package and as an actor, which is not a good practice. But from what you say I guess you want to advertise change of existing system, which will look nice in those diagrams and will be easy to explain to customers who know nothing about UML. You might consider removing interactions between modules and show only features provided to users (depicted as actors).
您感到困惑的真正原因是 UML 的创建者只是制作了他们的图表的目录（十几种类型），并且从未真正告诉您何时使用其中一种。
如果您谈论功能，则意味着用例图。您可以在这里查看一些示例：
http://askuml.com/blog/login-page-use-case -图/
或者
http://askuml.com/blog/e-commerce/
The very reason you are confused is that the creators of UML just made a catalog of their diagrams (a dozen types) and never really tells you when to use one or the other.
If you're talking about features, it means use case diagrams. You can see some examples here:
http://askuml.com/blog/login-page-use-case-diagram/
or
http://askuml.com/blog/e-commerce/
包图或组件图？
我认为对于您的具体情况，包图非常适合。
What about a Package diagram or a Component diagram?
I think for your particular case the Package diagram would be quite a good fit.
没有这方面的 UML 图。
There is no UML diagram for this.