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.
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 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.
Is there any UML tools available for Scala. the reason for my question is that its a blend of functional and OO concepts hence I would like to know how such tools denote functions in UML diagrams.
This thread summarizes the obstacles faced by any UML tool wanting to represent Scala classes:
there is no official representation of mixins in UML
it is difficult to represent:
closures
Scala type members
class constructor parameter bounds (a.k.a. "template
type" bounds/constraints)
covariant and contravariant class constructor inheritance
the relationship between a class or trait and the
companion object
This thesis ("Evaluierung des Einsatzes von Scala bei der Entwicklung für die Android-Plattform", pdf, German) does add stereotypes for trait mixins and other scala specific elements (pp. 146).
What was added by Meiko Rachimow in 2009:
attributes, getter and setter
For all published attributes exist implicit getter (attribute1 and attribute2), except the visibility was declared as private (attribute3). If published attributes are tagged with a stereotype Var, they are variables, for which there exist implicit setter (attribute2). The stereotype lazy marks instance variables as lazy (attribute4).
classes and generics
Like in UML, generic classes are marked with an abstract type. By using the Scala language syntax, upper and lower bounds can be declared for this type (EineKlasse). It is possible to use structured types as bounds, which attributes and methods are embraced by curly braces (EineKlasse2). Generic type parameters of methods are embraced by square brackets (operation).
traits
Traits are displayed like abstract classes and tagged with the stereotype trait. Abstract attributes and methods are displayed in italics (attribute2, operation2). For abstract attributes the dependency arrow can be tagged with the stereotype requires (Trait3, attribute3). On the other hand, the stereotype self is used for self referencing types (Trait4). If a trait inherits another trait, the inheritance is displayed with an inheritance arrow (Trait2). This arrow type is used too, if a class extends a trait (Klasse). To emphasis the “mix in” of traits, the inheritance arrow can be tagged with the stereotype mixin (Klasse).
singleton objects
Singleton objects are displayed like classes and tagged with the stereotype singleton. It is possible, that there exist two class elements with the same name. In fact it is a singleton object with the belonging companion class. In this case the dependency arrow is tagged with the stereotype hasA.
You could try (experimental) Dia2Scala tool. Notation used by this code generator is based on a notation from Meiko Rachimow's thesis (described in answer from VonC).
Just tested the Green UML Eclipse plugin. Some months ago it didn't work but with the Scala IDE nightly version Apr 2012) you can get some sort of class diagram. Looks promissing.
The tool I use is the same for Java, the UML diagram (classes or dependencies) in Intellij however its only available for "Ultimate" users
https://www.jetbrains.com/help/idea/class-diagram.html
Whenever I create an abstract class I tend to create an interface to go along with it and have other code refer to the interface and not the abstract class. Usually when I don't create an interface to start with I regret it (such as having to override all implimented methods to stub the class for unit testing or later down the line new classes don't need any of the implimentation and override everything also finding themselves unable to extend any other class).
At first I tried to distinguish when to use an interface and when to use an abstract class by considering is-a vs able-to but I still would end up suffering later down the line for not making an interface to start with.
So the question is when is it a good idea to only have an abstract class and no interface at all?
When you wish to "give" some base class functionality to derived classes but when this functionality is not sufficient to instantiate a usable class, then go for abstract classes.
When you wish that some classes completely implement a set of methods (a public contract), then it is a convenient to define such contract with interfaces and enforce them onto classes by making them inherit this interface.
In short:
With abstract classes you give some common base functionality to derived classes. No further actions are necessary unless abstract class has some stubs (which have to be implemented down there).
With interfaces you require derived classes to implement a set of functions and you do not pass along any implementation.
So the question is when is it a good idea to only have an abstract class and no interface at all?
When you do not wish to enforce any public contract (a set of methods/properties defined by an interface).
Also when you do not plan to use certain coding techniques like casting object to an interface type (run-time polymorphism) or limit allowed input (some method argument will only accept object of types which implement certain interfaces).
Well, the main case it is useful to have only an abstract class without any interface is to mark a certain type. It is useful to be able to check if an object "is-a" something. These interface "mark" an objet to be of a certain type. Depending on the language you use, different design patterns apply ...
These sort of abstract classes exist in java. You can also use them in C++ with RTTI.
my2c