O. *_*per 5 plugins components uml class-diagram package
我试图用UML展示基于插件/组件的系统的整体架构.作为这个问题的一个简单示例,我将展示一个主应用程序,它加载一个插件接口库(定义插件的通用接口),以及两个示例插件(其中一个带有一些内部细节),如图所示以下UML类图1:
在我的UML图中,我想强调如何将这些类(和接口)分发到单独的二进制文件2中,以便阐明在不重新编译的情况下可以替换系统的哪些部分.
现在,虽然我知道UML提供了相当大的余地,并且UML的主要观点并不是坚持严格的符号,而是以一种使其易于理解的方式表达信息,我仍然期望这种情况有一个共同的实践.
表达我所想到的信息的一种直接方式是使用UML组件图.维基百科引用了这个定义
系统的模块化部分,封装其内容,其表现形式可在其环境中替换.
对于组件.这看起来很合适,因为我想要展示的只是一个可替换的组件.因此,通过将上述类型放入组件中,我得出:
虽然这是可以理解的,但我有点怀疑这是可接受的符号,因为我可以找到的组件图上的几乎所有资源(包括前面提到的维基百科文章)都非常强调定义所需和提供的接口.在形式上,看起来我应该在图中的任何地方添加小的矩形端口或棒棒糖形状的接口,其中关系连接组件之间的元素.我不太喜欢这种前景,因为它听起来有点麻烦,更重要的是,它会使图形混乱而不提供任何额外的信息.
或者,包可能是可接受的符号.我的目的似乎与维基百科在相应文章的第二个列表中描述的内容相符
组织组件模型时,使用包根据所有权和/或重用可能性对组件进行分组.
包图如下所示:
另一方面,我有点担心使用包符号可能会与实际的代码内包(名称空间)产生混淆,这些包实际上与程序集正交.实际上,有些资源将UML包解释为Java包的1:1映射,这不是我想要传达的(为了论证,所有描述的类型可能非常好地驻留在同一个命名空间中,某些东西喜欢MyGreatSystem.Plugins).
可能有点合适的唯一其他UML图类型可能是部署图,但是诸如维基百科中的定义使得相当清楚的是,这样的图中的节点是物理机器或执行环境,两者都是明显不同于简单地处于单独的二进制文件中.
我能想到的最后一个替代方法是通过将类型与UML注释连接来指示二进制文件:
然而,这似乎更像是一种变通方法给我,我觉得更多的节点和边缘(而不是类型内的组件,在那里它们实际上是)使图不太可读.
什么是适当的UML方式来传达哪些类型存在于成品中的二进制文件中?
1:这里没有显示类和接口的成员,因为它们暂时不相关.这在我的最终图表中可能相同或不同,因为重点主要不在于完整的内部类结构.
2:在我的案例中是.NET程序集,但这个问题对其他环境/技术同样有效.
您应该区分组件和它们“体现”的二进制文件。
组件是行为的逻辑分组。实际的物理二进制程序集在 UML 中表示为显现工件。
最密集的符号可以在 UML 规范 v 2.5(测试版)第 221 页图 11.40 中找到
确保在组件和其他元素之间使用正确的关系。
| 归档时间: |
|
| 查看次数: |
207 次 |
| 最近记录: |