I'm drawing a class UML for a JAVA software design. I don't really understand what is a stereotype. The formal definition:
The stereotype is a profile class which defines how an existing metaclass may be extended as part of a profile. It enables the use of a platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass
Is that mean the stereotype should be the name of the parent class? But why there are some superclasses also has a stereotype?
So for example, I have a superclass Animal and a class dog which extends the Animal class, what could be the stereotype of both classes? Also, why there are some classes without stereotype.
What is a stereotype and what are its purpose?
A stereotype extends UML by allowing to categorize some elements in a more detailed way than foreseen natively by UML. It helps to make the model more expressive.
A typical example are the Entity, Control, and Boundary stereotypes. They are used in a use-case driven design: in a class diagram, you can immediately find-out which classes represents the use-case logic (marked as «control» stereotype), which classes represents user-interface with actors («boundary» stereotype), and which classes represents business/domain objects (marked as «entity»).
Another use of stereotypes is to indicate the way a class is supposed to be implemented, for example to mark as «table» classes that correspond to database tables that are related to in-memory objects, or to indicate among the objects which ones are «persistent». An even more common use is to show some concepts that are language specific and have no equivalent in UML. I think in particular to C# «struct» which have a value semantic wheres C# classes have a reference semantic, or C# «property» (which is a stereotype at attribute level).
How are stereotypes defined?
Sterotypes are defined in a profile. You can see a stereotype as a class in a profile diagram.
But it's not an ordinary class that you could relate to other classes in your model. So there is no inheritance at play here. You would never indicate a superclass as stereotype.
A stereotype is a class related to the "metamodel", which means the UML standard elements defined in the UML standard. So it's a class of classes (or a class of associations, or of any other UML element).
To elaborate on your example, with an abstract superclass Animal and concrete sub-classes Cat and Dog:
you could affect them all an «entity» profile, because they all belong to the domain model.
if you would want to store the objects in an RDBMS using the concrete table inheritance, you may use a stereotype «persistent» for Cat and Dog (since concrete table inheritance pattern does not implement persistence for the abstract classes)
Related
There is a class diagram that contains one class and this class has three operations (Oper1, Oper2, and Oper3) and three attributes (Attr1, Attr2, Atrr3). Now suppose:
1- Oper1 uses Attr1 and Attr2 to read from and write to them,
2- Oper2 uses Attr3 to read from and write to it,
3- Oper3 uses Attr1, Attr2, and Attr3 to read from and write to them.
Now how can I show this dependency/usage of attributes in class's operations in UML diagram?
Is it necessary to show this kind of relation in UML?
This kind of relationships are not documented in an UML class diagram. The class diagram defines the properties and the operations, but not how they relate in a particular implementation.
May be today oper1 uses Attr1 and Attr2; but maybe tomorrow it will also use other properties. You may however document this in a comment note, or --perhaps better-- in UML pre-condition and post-condition constraints.
If you want to just model the dependency, you certainly can do it. Either in a class diagram:
Or in a matrix
Or simply in the model:
You could also define an activity as a method for each operation, which accesses the attributes with ReadStructuralFeatureActions and WriteStructuralFeatureActions. However, this would only add meaningful information, if you really want to completely specify the operations with this. Is this effort warranted?
In almost all EF methods that use inheritance, I see that the parent class is marked as abstract. Is there any reason why this is done? Or is it just so the abstract class cannot be instantiated?
No, that is not mandatory, your base class could not be abstract, but as you already said it's the most common. It's like a inheritance by generalization, which is extracting shared characteristics from two or more classes, and combining them into a generalized superclass, that's why is common see the base class as abstract.
In EF there are three different approaches to representing an inheritance hierarchy:
Table per Hierarchy (TPH): Enable polymorphism by denormalizing the
SQL schema, and utilize a type discriminator column that holds type
information.
Table per Type (TPT): Represent "is a" (inheritance) relationships as
"has a" (foreign key) relationships.
Table per Concrete class (TPC): Discard polymorphism and inheritance
relationships completely from the SQL schema.
In the last approach if the base class was concrete, then an additional table would be needed to hold instances of that class.
In summary, if the base class is abstract or not depends more on your side if that make sense or not in the model you are trying to represent.
I'd assume because the methods you override are also abstract? Can't have an abstract method on a non-abstract class.
So, for example, it never makes sense to instantiate a plain old DbContext -- you always need collection properties and such. The base DbContext provides functionality which all DbContext derivatives would need (connecting to a database, etc), but isn't useful as a stand-alone object.
When designing software (think UML diagrams for example) and real world objects.
How does one identify a suitable case for an Abstract class?
For example if we had an [Employee] and [Fireman] and [paidFireman] and [unpaidFireman]...I am having trouble seeing whether a Fireman or Employee should be abstract and why?
Abstract classes are one of those more esoteric constructs in UML. Since classes are already an abstraction of real world things, an abstract class is even one level higher. Abstract classes can not be instantiated (since it is assumed they miss something for a real life). Whether you say that Fireman is abstract while the paid/unpaid are not, is a pure point of view and must be argued in the specific domain.
As a rule of thumb: leave abstract classes out of the door until you come to a point where you feel the urgent need for it. Introducing abstractness limits your model (and can help to avoid some malformed results of it). But without those limits the model is still valid as long as the architect sticks to common sense rules.
It mainly depends on your functional requirements.
If it makes sense in your application just to have simple employees (without designating them as firemen, policemen, or craftsmen), then the class may not be abstract, as the application will have to make instances just of the Employee class.
If that doesn't make sense, i.e. the occupation of each of your employees needs to be known at creation time, abstract classes come into consideration. But still they aren't necessary in every case. The easiest way to make sure the occupation is known is to model it as a mandatory attribute. Introducing a subclass only makes sense if there is specialized behavior for each of those subclasses. If, e.g., the salary of the firemen is calculated as 50$ * count of the fires he exstinguished, but the salary of the policemen is 1000$ + 50 * rank, then you model an abstract operation getSalary() in the Employee class, which will be concretely specified and implemented in each of the subclasses.
As the concept of interface also got mentioned in one of the answers, an interface describes the obligation to implement certain operations in all classes realizing that interface. That's much the same as an abstract operation in an abstract class. But the abstract class can contain much more than an interface: attributes and non-abstract operations.
So the rule of thumb is: For concepts of your domain for which interface and behavior can be fully described, use non-abstract classes. For concepts for which only interfaces and no behavior can be described, use interfaces. For concepts for which interfaces and part of the behavior can be described, use abstract classes.
There are many uses for an abstract class. An abstract class is one that cannot have any direct instances.
In software design, it is one way to describe an interface. Some of the declared operations can be implemented in the superclass. Any remaining implementations must be specified in sub-classes. Regardless of where the implementations exist, an abstract class means there can be no direct instances, only instances of some non-abstract subclass.
In a domain analysis, an abstract class is a way of modeling an abstraction. For example, think of the abstraction Role. It is useful to say that a Person plays a number of Roles. However, there is no instance of a Role that makes sense, without it also being a more specific kind of Role, such as Employee, Fireman, or Teacher. For this situation, you not only want Role to be abstract, you also want a covering axiom. For more on that, please read https://stackoverflow.com/a/35950236/2596664.
Why and how are dependency relationships used?
I've come across a PiggyBank example where the Analysis Model consists of a class diagram with dependency relationships.
They use two relationships "use" and "instantiate" to describe the relationships between the classes.
I don't agree with the relationship that the boundary class TransferMoneyForm has a "use" to the TranferMoneControl. I believe it should be the other way around.
Can someone exaplain to me how these two relationships should be used. Thank you in advance.
The diagram shown there is not a correct and full UML class diagram. In such all the associations and generalizations should be defined, and what is abstract, what is public or not. To show what descends from what, what is hidden, what will be never instantiated and what fields of one class has types of other classes. Here we see only information about the
functions.
And it is logical. If you'll look at the previous chapter, there is written: "A control class represents a self-contained process..." So, they are talking on processes, not classes, instances and fields.
It is NOT a class diagram. And nowhere is said that it is. It is named "Transfer Money Participants diagram". They do use the elements of the class diagram, but not to the fullest and so create something more common. It is some approximate undefined diagram on some classes, something between class, communication or component diagrams. Maybe, it is the old style of IBM? Experts (What's the best UML diagramming tool?, 1st answer) say, "IBM Rational Software Architect did not implement UML 2.0". )
As for the question, who uses whom... According to Sparx VP UML, a "usage dependency" is a "relationship in which one element requires another element ... for its full functionality". According to wiki, "The client element somehow "uses" the supplier". Here the form hasn't sense without the controlling class, and vice versa. So, I'd say, the use goes in both sides. But more honest would be to create a normal communication or component diagram. The class diagram has NOT an element to say about sending and accepting the messages. And the "use" is definitely not for it. And when they have decided not to use logic, they can put there virtually anything.
If you are making a class diagram and one your class uses function(s) of another one, that is the case to draw a use dependency connection.
Me and several other developers are currently cleaning up our legacy code base, mostly separating visual and data layers. To help developers not involved in this refactoring understand the model, I'd like to introduce a (rather informal) class diagram with comments about scope and desired usage for each class. Since I'm lazy, I'd like to use UMLGraph for that.
However there is a small problem: we've got a perl code base and the refactoring uses Moose roles extensively. Now I don't know UML good enough to find a proper abstaction for roles -- my first guess would be interfaces, but they also contain implementation; multiple inheritance doesn't quite cut it either.
How do I (or how would you) represent roles properly in a class diagram?
I'm no UML expert but in the original paper Traits were represented like this
Traits Diagram http://img.skitch.com/20100422-8iey4atkkama53ni81c3pca562.jpg
I would represent a role as a UML class with the «role» stereotype. The class composing the role would then have an association to the role with the stereotype «does».
Simple Composition http://img820.imageshack.us/img820/5665/simplecomposition.png
If I needed to further adapt the role, with aliases or exclusions, I'd create that as an association class with properly annotated members and with the «adaptation» stereotype. The name of the association class wouldn't matter, because it won't be a real type in the design; so I'd leave it unnamed.
Composition with Conflict Resolution http://img828.imageshack.us/img828/244/conflictcomposition.png
(Please note that I have shown the adaptation "class" connected to the composition and the role it adapts. What I really wanted to do was connect it to the association between MyComposition and MyRole1. It's just that the tool I used didn't support association classes).