OO接口如何在组件图中处理？
我的组件图主要是组件，端口和接口。接口具有操作和属性。他们目前尚未捕获任何基于类的OO。正确的方法是什么？
我看到它们的选项是：
- 将类构造函数添加到组件界面，然后让该类型携带剩余的细节，例如类操作。
- 重复的类接口到组件接口，例如将类对象作为第一个参数。
从两者那里，前者显然是最不工作的。但是也许我忽略了一种更好的方式。
My component diagram is mostly components, ports, and interfaces. The interfaces have operations and attributes. They do not capture any class based OO at the moment. What's the right way of doing that?
My options as I see them is either:
- Add the class constructors to the component interfaces, and let the type carry remaining details like class operations.
- Duplicate class interfaces into the component interfaces, e.g. having the class object as first parameter.
From the two the former is least work obviously. But perhaps there is a better way I've overlooked.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
符号
最简单的方法是在单独的类图中捕获接口，仅使用
«接口»分类器。优势在于，这些分类器给接口（希望简称）名称，并描述所需的属性和操作以及所有必需的详细信息，包括构造函数（请记住，在UML构造函数中应在>«之前先于« 然后，创建»）然后，您可以在组件图中的组件显示所提供的接口（Lollipop）和必需的（套接字）仅参考命名接口，而不会使用许多冗余接口规格弄乱图表。
设计
时，当您在组件级别上指复制类接口时，我知道您的意思是将属性（零件？）和操作添加到组件中。
当然，实现相同隐式接口的组件原则上可以互换。但是，这种方法不允许对依赖性，特别是使用依赖关系有清晰的了解，而这些依赖性是将组件解散的实用性。换句话说，您的组件将是固定的。
在这方面，在组件级别上添加类构造函数似乎更干净，因为您的类构造函数将重新使用在其他地方定义的类。但是，如果您要朝这个方向发展，则可以更进一步，考虑使用工厂类别：
*。如果您这样做，我会回到符号主题：Lolipo/套接字符号将允许更好地突出该设计所提供的解耦。
Notation
The easiest way to do this is to capture the interfaces in a separate class diagram, with only
«interface»classifiers. The advantage is that these classifiers give a (hopefully short) name to an interface, and describe the attributes and operations that are needed, with all required details, including constructors (keep in mind that in UML constructors should be preceded with«Create»)You can then show for the components in your component diagram the interfaces provided (lollipop) and required (socket) just referring to the named interfaces, without cluttering the diagram with lots of redundant interface specifications.
Design
When you refer to duplicating class interfaces at the component level, I understand that you mean to add attributes (parts?) and operations to the component.
Of course, components implementing the same implicit interface could in principle be interchangeable. However, this approach does not allow to have a clear understanding of the dependencies, and in particular use dependencies, that are practical to decouple components. In other words, your components would be hard-wired.
Adding class constructors at the component level seems cleaner in this regard, since your class constructor would reuse classes that are defined somewhere else. But if you're going into that direction, you could go one step further and consider using a factory class:
*. If you go that way, I come back to the notational topic: the lolipo/socket notation would then allow to highlight better the decoupling that this design would offer.
我不明白您描述的选项。也许图会有所帮助。这是我的方式：
规范组件有两个端口，并间接实例化。对于实现组件，我选择两个正在实现组件的类。
class1具有一个操作，该操作使用接口定义的服务i1。class2实现i2承诺的服务。由于端口p2具有16个多重性，因此由class2键入的部分至少具有此多重性。构造函数（带有«创建»刻板印象），没有参数，因此可以在没有任何其他逻辑的情况下构造组件。如果需要其他逻辑，则可以使用直接实例化的组件。他们的构造函数可以称为实现类的参数化构造函数并创建接线。
I didn't understand the options you describe. Maybe a diagram would help. Here is how I would do it:
The specification component has two ports and is indirectly instantiated. For the realization component I select two classes that are realizing the component.
Class1has an operation that uses the service defined by interfaceI1.Class2implements the service promised byI2. Since portp2has a multiplicity of 16, the part typed byClass2also has at least this multiplicity. The constructors (with the«create»stereotype), don't have parameters, so that the component can be constructed without any additional logic.If you need additional logic, you can use directly instantiated components. They have constructors that could call the parametrized constructors of realizing classes and also create the wiring.