我试图用UML展示基于插件/组件的系统的整体架构。作为这个问题的一个简单示例,我将展示一个主应用程序,它加载一个插件接口库(定义插件的通用接口),以及两个示例插件(其中一个带有一些内部细节),如图所示以下UML类图 1 :
在我的UML图中,我想强调如何将这些类(和接口)分发到单独的二进制文件 2 ,以便阐明在不重新编译的情况下可以替换系统的哪些部分。
现在,虽然我知道UML提供了相当大的余地,UML的主要观点并不是坚持一个严格的符号,而是以一种让它易于理解的方式表达信息,我仍然期望有一个共同的做法场景。
表达我所想到的信息的一种直接方式是使用UML component diagram。 Wikipedia cites定义
系统的模块化部分,封装其内容,其表现形式可在其环境中替换。
表示组件。这看起来很合适,因为我想要展示的只是一个可替换的组件。因此,通过将上述类型放入组件中,我得出了这个:
虽然这是可以理解的,但我有点怀疑这是可接受的符号,因为我能找到的组件图上的几乎所有资源(包括aforementioned Wikipedia article)都非常强调定义所需和提供的接口。在形式上,看起来我应该在图中的任何地方添加小的矩形端口或棒棒糖形状的接口,其中关系连接组件之间的元素。我不太喜欢这种前景,因为它听起来有点麻烦,更重要的是,它会使图形混乱而不提供任何额外的信息。
或者,package可能是可接受的符号。我的目的似乎与Wikipedia在相应文章的第二个列表中描述的内容相匹配
组织组件模型时,使用包根据所有权和/或重用可能性对组件进行分组。
包图如下所示:
另一方面,我有点担心使用包符号可能会与实际的代码内包(名称空间)产生混淆,这些包实际上是正交到程序集。实际上,there are resources将UML包解释为Java包的1:1映射,这不是我想要传达的(为了参数,所有描述的类型可能很好地存在于同一个命名空间内) ,像MyGreatSystem.Plugins
)。
可能有点合适的唯一其他UML图表类型可能是deployment diagram,但是来自Wikipedia的定义使得在此类图表中明确表示node是一个物理机器,或者是一个执行环境,两者明显不同于单独的二进制文件。
我能想到的最后一个选择是通过将类型与UML注释连接来指示二进制文件:
但是,这似乎更像是一种解决方法,我觉得额外的节点和边缘(而不是在里面的类型的组件,它们实际上是这些)使图少可读。
什么是适当的UML方式来传达哪些类型存在于成品中的二进制文件中?
1 :这里没有显示类和接口的成员,因为它们暂时不相关。这在我的最终图表中可能相同或不同,因为重点主要不在于完整的内部类结构。
2 :在我的案例中是.NET程序集,但这个问题同样适用于其他环境/技术。
答案 0 :(得分:1)
我的第一张图与使用套餐的图表相当不错。组件可以包含元素(根据UML规范,它由PackageableElements
组成)。为了便于阅读,我会放大Core Application
,以便钻石完全位于内部。第三种选择就是:另一种选择。我更喜欢第一个。
答案 1 :(得分:1)