How to simulate Eclipse extension points in a UML class diagram?

For the software development project that I have to complete, I chose the Eclipse platform as the framework. Meaning I have many extension points to implement.

However, I was having trouble specifying these extension points on my UML class diagram. So, how do I simulate the fact that a class belongs to an extension point in a class diagram?

Or is the class diagram the wrong place for this? If so, where is the best place to specify the extension points that I am implementing?

For reference, I am doing UML modeling with Papyrus. I already have a working prototype of the application, so it just creates a diagram.

Greetings

+4
source share
4 answers

The eclipse extension point is similar to an interface: it declares a set of properties to be implemented.

For example, the org.eclipse.ui.editors extension point states that to implement this extension point you must provide:

  • ID
  • name
  • icon
  • class
  • file extensions
  • contribution

There is no EXACT way to say this in UML, since the extension point is neither an interface nor an object, but you can model it by adding a stereotype to your model, say <<extension_point>> (you can learn more about stereotypes here ) and create a class on your diagram (e.g. org.eclipse.ui.editors ) that has all of these attributes, with their required types (in this example, all attributes are strings except class , which are of type org.eclipse.ui.IEditorPart ).

After that, you can create another stereotype, say <<extension_point_implementation>> and a new class that has this stereotype. This class, which you connect to the implementation reference from the <<extension_point>> class, and then set the values ​​of all attributes for what you are implementing.

Please note that this is not β€œpure” UML, as you are defining a new domain with added semantics, but I think that would be a good and easy-to-understand way to model what you want.

+1
source

Speaking of Eclipse plugins, I would choose a component diagram than a class diagram. Then you can model the expansion points as ports and their contract as interfaces (these candies).

If you have class diagrams indicating extension points, since interfaces with a special stereotype (or keyword) will also be good.

As for the class that implements the extension point, you can either use the dependency on the component, or (in the second solution) the implementation of the interface.

+2
source

In a sense, extensions are extension points, which instances belong to classes; extension points determine the possible attributes of the extensions, and each extension contains specific attributes corresponding to the extension point.

0
source

Just change the Java code and add a note. That would do the job.

0
source

Source: https://habr.com/ru/post/1384926/


All Articles