问题描述
我有一些要在UML中表示的相关接口和类（对关系感到抱歉，我不知道如何使用StarUML正确地做到这一点）
ISMS实现IMessage和IStorable接口的想法，不是让SMS类直接实现两个接口，而是使项目更具模块化，可维护性和易于测试。
这是设计的好方法吗？如果是这样，这是在UML类图中表示它们的一种好方法，还是有一种更好的方法来表示接口及其与UML中其他接口/类的关系？
解决方法
这是设计的好方法吗？
我认为是的，也是因为如果添加了MMS，它也可以实现ISMS（可以重命名该接口）。
对于 IEmail ，除简化 Email 和其他使用接口的类以具有一个接口而不是两个接口之外，尚不清楚。
我很确定Christophe会说更多有关这一点：-）
这是在UML类图中表示它们的一种好方法，还是有一种更好的方法来表示接口及其与UML中其他接口/类的关系？
表示类实现接口的关系是实现（用虚线绘制），您使用了泛化，因此还添加了 MMS ：
...实现IMessage和IStorable的ISMS
警告这不是实现，因为 ISMS 是一个接口，与 IEmail 相同，这就是为什么在接口之间支持继承的原因概括而不是实现。
,我在Bruno's already very clear answer上有几句话。
您的设计
乍一看，接口分解为IStorable和IMessage似乎是interface segregation principle的合理应用。
在这方面，将两个接口组合成可重用的ISMS接口，而不是直接在具体的SMS类中实现它们，这将使您的代码更具可维护性，因为它将轻松地替换SMS实现。另一种方法（如果您认为SMS功能可以是特定于平台的，则很有意义）。
但是问题是SMS和email是否不能互换使用。但是只有您可以回答这个问题：如果您的设计要求保持这些通信渠道的截然不同（也许您的实际代码在两个接口之间添加了一些区别），那就很好了。但是，如果没有，则允许这种互换性并用一个更通用的ISMS代替IEmail和INotification是有意义的。
您的UML表示形式
首先，我想强调布鲁诺关于泛化（普通线）和realization（虚线）之间区别的说法。
也许我是老学校了，但是我建议不要使用更常规的interface，就像在类框的上方带有关键字«interface»的类框一样。接口。尤其是如果您具有属性和操作。
在我看来，圆圈更适合界面的棒棒糖符号。当您对接口本身无话可说，但想显示一个类实现（lollipop）或依赖于（socket）的接口时，这是非常实用的。然后在另一个更详细的图中定义接口的详细信息。从理论上讲，您可以将两个符号合并在同一张图中，但是就我个人而言，我发现它的可读性较低，因此不建议这样做。