for a software design project I have to do, I chose the Eclipse Platform as a framework. Meaning I have lots of extension points to implement.
However, I have trouble specifying these extension points in my UML class diagram. So how do I model the fact that a class belongs to an extension point in my class diagram?
Or is the class diagram the wrong place to do this anyway? If so, where is the best place to specify the extension points I implement?
For reference, I am doing the UML modeling with Papyrus. I already have a working prototype of the application, so it is just about creating the diagram.
Cheers
Speaking of Eclipse plugins I would rather choose a component diagram than a class diagram. You can then model extension points as ports and their contract as interfaces (those lollipops).
If you rather have class diagrams specifying extension points as interfaces with a special stereotype (or keyword) would be fine as well.
Regarding the class implementing an extension point you can either use a dependency on the component or (in the second solution) an interface realization.
An eclipse extension point is like an interface: it declares a set of properties that must be implemented.
For example, the org.eclipse.ui.editors extension point declares that to implement this extension point you have to provide:
id
name
icon
class
file extensions
contributors
There is no EXACT way to say this in UML since an extension point is neither an interface nor an object, but you could model it by adding a stereotype to your model, say <<extension_point>> (you can read more about stereotypes here), and create a class in your diagram (for example org.eclipse.ui.editors) that has all of these attributes, with their required types (in this example all attributes are strings, except class which is of type org.eclipse.ui.IEditorPart).
After this you can create another stereotype, say <<extension_point_implementation>> and a new class that has this stereotype. This class you connect with a realization link from the <<extension_point>> class, and then you set the values of all of the attributes to what you are implementing.
Note that this is not "pure" UML since you are defining a new domain with added semantics, but I think that this would be a good and easy to understand way to model what you want.
In a sense extensions are to extension points what instances are to classes; extension points define the possible attributes of the extensions, and each extension contains the concrete attributes conforming to the extension point.
Just reverse the java code and add a note. It would do the job.
Related
I have to do an UML class diagram for a project in which I implement an interface with abstract methods for RL algorithms. I implement several algorithms that implement an interface but implement additional methods depending on the algorithm. How can I capture that in an UML diagram? I have thought in including a box with the generic name "Algorithm" and the attributes and methods
"Algorithm specific attributes/methods", would that be correct in the UML framework?
A class should not inherit an interface but realize (aka implements) it. Graphically, you'll use the same notation than inheritance but with a dashed line:
Your case is a classic case of interface realization, as you'll find for example in a strategy pattern. The fact that you add other operations (aka methods) is completely normal and does not require anything special.
If you're using abstract classes instead of interfaces, then you may use inheritance:
I'm creating a student information system which will have two access levels namely admin and manager. The Admin class can perform all functions of Manager class along with some additional functions. But literally speaking an Admin is not a manager. So how should I implement this relationship? Is it okay to do Admin extends Manager or is there any other way to implement this? (I'll be using java to implement the system)
Well, UML provides 3 mechanisms to depict (some) similarity between classes.
Generalization
Interfaces
Substitution
Let's look at them closer:
Generalization
When two classes are in generalization relationship, one of them (subclass, specialized or child class) is a kind of the other (superclass, general or parent class). Child class has all attributes and methods of its parents (inherits them) and can have some additional attributes or methods and can handle some methods in a different matter.
Generalization is depicted with a solid line and an arrow whose head is an empty triangle. Head is pointing the more general class
Interfaces
Actually interfaces are not a direct relationship between two classes that are in some way similar. But they help to show it to some degree.
Interface is a specific kind of a class that has a collection of methods. Interface is not directly instantiated, but other classes can either realize the interface or require an interface.
If a class realizes an interface (or provides it in other words) then it has to have all the methods of an interface, however interface in no way enforces a method of implementation.
So we may have two (or more) classes that realize the same interface and then both those classes will be able to perform the same functions, however it might be a totally different way.
We show interface realization by a dashed line and an arrow in a form of empty triangle, pointing the interface.
The class that requires the interface is the class interacting with those classes providing the interface.
To show interface usage you use a dashed line with an open arrow and stereotype <<use>> (well, technically it is not a stereotype).
Substitution
Class substitution is used to shown that one class can step into the role of the other class but it is not a kind of that class. A substituting class has to have all methods of the class it substitutes but it might have different internal representation.
This relationship is used when two or more classes can perform similar roles but they are not of the same kind.
Substitution relationship is shown as a dashed line with an open arrowhead pointing the class that can be substituted and a stereotype <<substitute>>
Your case is substitution, where Admin can substitute Manager, however you can combine substitution with interfaces to make it clearer.
Also always make sure that the recipient of your documentation will understand the element models you're going to use.
Just make a parent class with the methods shared by both Admin and Manager.
I try to make a model on eclipse modelling tool and I have in the model a class that use an other class as a type for an attribute.
I have made the class definition but I can't find the way to connect them together.
I have also made the definition for a method with a parameter with the same class type, but there I've no trouble. The class I use as a Type is in the combo box.
How should I do?
If I understand your question correctly, you are trying to create an EMF metamodel, and are using a graphical editor, and try to connect EClasses.
Basically, EMF EClasses can have two kinds of features: EAttributes and EReferences. EAttributes can refer to Java types, like integer or string; while EReferences are used to connect EClasses. In other words, you cannot have an EAttribute refer to another type you added to the diagram; instead you have to create a reference between them.
I am currently building a model from existing C++ code. There is a (dynamically loadable) library that must therefore implement/provide a defined interface (class). The class which is used has some pure virtual functions, but it is - admittedly - not a pure interface (in the Java sense) as it is also a base class containing state (members) and a few method implementations.
So it is kind of a hybrid - base class in C++ reality, but an interface in its main purpose.
Note: I do not intent to generate some code, but the model should be correct for documentation purposes.
When drawing an example in EA (12), some questions arise:
a) are there any important reasons to prefer a class and make it 'abstract' (gray box "Base"), or should I directly use an Interface from the toolbox (purple box "Base2")? So far I could not notice any behavioral difference in EA except the color.
b) How can I suppress the stereotype {abstract} written behind the methods? When I do not set them to "abstract", they are not drawn in italic letters. But I want them italic, without the "{abstract}".
c) Similar question concerning the class/interface boxes: aren't interfaces abstract by definition? So why does EA add the {abstract} text here? It was sufficient to draw the class name italic.
d) I guess that the most left arrow (generalization of a base class) and the most right arrow (realization of an interface) are correct, and the middle one is not. Right?
a) Take either, but be consistent. The difference is a bit esoteric and except for rare cases not worth while (YMMV).
b) It looks like you filled Context/Advanced/Multiplicity with the value abstract
c) Yes. Interfaces are abstract and if you look at the Details tab you'll see that the Abstract box is ticked and can't be changed. I have no idea where that curly bracketed text comes from. It's not a stereotype. The only way I could show it like that was to change the type from int to int {abstract}.
d) You can well implement more than one interface in a class so theoretically all connectors are fine. So Derived implements two interfaces.
Edit As #minastros found out himself (and PMed me) the culprit was one of the zillion flags in the EA options:
As Thomas mentions, an interface is an abstract class technically, although an abstract class isn't always an interface. If you have even one operation (method) that isn't implemented, the class is abstract, so it follows that if none of the operations are implemented, the class is also abstract. An "abstract class" is often only thought of as a class with partial implementation since such an abstract class is different from an interface. However, a class with no implementation--an interface--technically is also an abstract class.
That's probably why EA puts the {abstract} attribute on an interface (it isn't a stereotype in the diagram, it's an attribute--stereotypes use <>). I wouldn't do it myself, since it goes without saying.
With reference to UML diagrams, what is an interface? and can someone explain in more simpler words. I cant understand anything from googling it.
An interface is like a template design for a class that contains no data or implemetnation; only definitions for methods, properties etc. These are abstract and cannot be instantiated but can be inherited from at which point all specified methods etc must be implemented by the concrete class inheriting the interface.
An interface is a design item describing a behaviour.
Classes implementing the interface will/must behave according to its definition.
Interfaces are used to promote loose coupling and the base of many IoC patterns (Inversion of Control)
A Interface is just a description of a class nothing concrete.
You use it to create a new class "with the same description" without knowing the concrete implementation.
In one word: it's a contract. Every class that implements this contract (interface) will have to implement the methods defined on it.