In Java it's perfectly legal for an interface to extend an interface. Does this relationship in UML look like an "extends" relationship (solid line, closed, unfilled arrowhead) or an "implements" relationship (dotted line, close, unfilled arrowhead)? I can't seem to find an example of this relationship either online or in Fowler's book.
Use "extends" (solid line, closed, unfilled arrowhead), which is consistent with how Java uses the extends and implements keywords.
"extends" == UML generalization / specialization relationship
"implements" == UML realization relationship
The sub-interface is a specialization of the super-interface, not a realization of it.
See http://www.informit.com/articles/article.aspx?p=29224&seqNum=2
.
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.
public abstract class Shape {
abstract int area();
}
How do we draw the UML class diagram for the abstract method? Use +, - or #?
public class Room {
int nWindows;
}
And what if the class instance variable doesn't have public, private or protected?
Abstract
According to UML specification:
The name of an abstract Classifier is shown in italics, where permitted by the font in use. Alternatively or in addition, an abstract Classifier may be shown using the textual annotation {abstract} after or below its name.
Note however that Operation is not a Classifier. It still has an isAbstract attribute as a BehavioralFeature but 2.5 specification does not define how to model the fact of being abstract. Older specifications (1.4.x) were using the same method as for Classifiers and it is a widely recognized method to show operation abstraction. Note only that the elements in curly brackets for features are presented at the end of line rather than just after the name (Classifier simply has no other specification directly after name).
Possibly authors made an omission in 2.5 specification for Feature abstraction notation by a mistake.
An abstract operation can of course have any visibility kind.
Of course the operation might be abstract only if its containing Classifier (Class in your case) is also abstract.
No visibility kind
In general visibility kind in UML is optional i.e. you can simply omit it. Just take into consideration that UML is a model so it actually can ignore some irrelevant elements or can specify them at a later stage of modelling. Not using any visibility kind in UML does not allow you to make any assumption about it's final visibility kind.
On the other hand if in actual code you use no visibility kind specification (if allowed at all) there is some default behaviour. For example
in Java it's package (#) - in UML understanding, Java calls it "package-private",
in C++ you'll end up with private feature (-),
in PHP such features are treated as public (+)
and so on.
Class diagram is a static representation of a system that we are going to develop.Classes can be categorized as
Boundary classes
Control classes
Entity classes
So when we are drawing class diagram Is it not necessary to draw boundary classes in the class diagram?
It depends on what you are trying to show.
Entity-Control-Boundary (ECB) is a variation of the Model View Controller Pattern.
If your application does not follow the EBC pattern there is no need to mark classes as Entity, Boundary or Control.
You may also use Class Diagramms to show the relationship between some of the classes, like how the Mediator Pattern may be implemented.
From Wikipeda: Mediator Pattern UML Diagram
There is no Entity, Control or Boundary.
So in the answer is - in general there is no need to draw Entities, Boundaries or Control elements in UML Class Diagrams, only if your classes implement something like the ECB Pattern.
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.