I need some help.
I'm writing class diagrams for my engineering software course and I have some doubt.
With few words, this app will send a trouble ticket about a gas loss e.g.
I have a class called "ManageTroublTicket" and I need some methods to delete or modify the ticket for example.
I already have a ticket class, so ManageTroubleTicket will have a ticket object as attribute, but for the rest?
Should I create a class for "DeleteTicket" and extends with ManageTroubleTIcket?
Like
Class DeleteTicket extends ManageTroubleTicket?
Or something like
Class ManageTroubleTicket implements DeleteTicket?
What kind of strategy should I use?
Thanks for answering and sorry for my bad english
Related
In university, we are taught that a composition is quite important to keep your code clean and efficient. For example, a playtile class object could only exist in a playfield class object. If there is no playfield, there could not be a playtile. However, we were never taught how to implement such a thing. When I asked, I got an answer similar to "Add a check in the constructor." or something along those lines but I have no clue on how I would implement that (I don't know what to look for or what the official terms are). One of my attempts was inheritance. The teachers did not like that, let's keep it at that...
So, how does a composition work in practice? How could I make it so the playfield class is the only class that could instantiate a playtile without inheritance?
In practice a class that references another doesn't impose constraints on the class it references. Its not desirable for a class to care about what is referencing it. For example: you would not want to enforce this constraint when you write unit tests. I would never make it so the playfield class is the only class that could instantiate a playtile.
For a concrete example of how composition is implemented in the wild, check out the Unity3d game engine: https://www.youtube.com/watch?v=8TIkManpEu4
Say I have an interface Interface and a concrete class ConcreteClass that implements Interface. Now consider a third class MyClass. If instances of MyClass hold a reference to ConcreteClass:
Interface ref = new ConcreteClass();
then should I associate MyClass with Interface or ConcreteClass in UML class diagram?
Thanks
That depends on what the public interface of MyClass defines.
If the public interface makes an Interface available, then you should link to that on the diagram. This would be the usual approach as the Interface is the general type and specifies the contract. Unless you have a reason to limit to ConcreteClass, don't.
If the public interface makes a ConcreteClass available, then you should link to that on the diagram.
The fact that at runtime a variable of type Interface actually holds an instance of ConcreteClass is beside the point. The diagram represents the relationships.
Solely with the Interface. The point is that you want the behavior of the interface. Whatever the implementation is of that interface is for the picture of no importance. MyClass has a relation with the interface, not with the implementation of the interface.
This principle is called Design By Interface. In the answer given by nakosspy is it his first picture. But it would even be better to leave the implementation of ConcreteClass out of the picture. The implementation is of no importance at that conceptual level. If there is a variable pointing to an interface, then is it obvious to the educated reader that there should be a concrete implementation as well.
If you would make a reference to the ConcreteClass then would you have to change the diagram everytime you change the implementation of the interface. That is not what you want. It is bad coding practice and bad uml practice.
It is good coding practice to separate the declaration of the relationship between MyClass and the Interface and the practical implementation of the Interface. By example:
Interface ref = new ConcreteClass();
should never happen in the class MyClass.
You should have something like this instead:
class MyClass
Interface ref;
setRef(){
ref = InterfaceImplementation();
}
}
This way can you change the implementation of Interface without changing one line of code in MyClass. Altough this might look much ado when you write one class, think of it when you are managing hundreds of classes.
So: it depends.
It's equally legal to associate MyClass with ConcreteClass or Interface. You won't find the answer to your question in the UML spec. Why? Because the answer lies in your problem domain, not the modelling language.
Consider two contrived examples to illustrate the point.
Example 1: Association between Classes
Substitute:
ICanBark for Interface
Dog for ConcreteClass
Trainer for MyClass
Let's assume the association we want to capture is Trains, i.e.
Each Trainer trains many Dogs
Each Dog is trained by at most one Trainer
In this case the association exists because of the 'Dogginess', not the 'Barkiness'. So it properly exists between the two classes.
Example 2: Association between Class and Interface
Substitute:
ILogger for Interface
FileLogger for ConcreteClass
Application for MyClass
In this case the relationship is about the 'Logginess', not the 'Fileness'. Application shouldn't care how the interface is implemented; it just wants a way to log messages. So the Association exists between the Class and the Interface
Summary
As is nearly always the case with Associations, the key to solving the problem lies in the problem domain itself - not the modelling language.
hth.
There are 2 ways to present the ref variable of MyClass: You can present it as attribute or as association. Then there are two alternative notations for the Interface interface: Square with the interface stereotype or circle. This makes 2*2=4 alternatives.
Show ref as association and use square interface notation.
Here you can't show the initial value that ref takes. That's because you can't show default values in associations.
Show ref as association but use the circle notation for the Interface.
As it was with the previous alternative, again here you can't show the initial value.
Show ref as attribute and use square interface notation.
Here you can show the default value, because you can do that for attributes. The relationship between MyClass and Interface is presented as a dependency. The same happens for the dependency between MyClass and ConcreteClass.
Note that this dependency (MyClass depends on ConcreteClass) can be presented also in the alternatives 1 and 2, you can add a dependency arrow (dashed) pointing from MyClass to ConcreteClass.
Show ref as attribute and use circle interface notation.
Again here you can show the default value.
If we count also the alternatives derived from presenting or not the dependencies, then there are at least 6 ways to present the same thing. Now the question is which to chose.
It depends on what do you want to visualize with the diagram and for whom the diagram is intended. In this case if the initialization of ref is the message, then you should use an alternative that presents it. If it's less important, then you might prefer a diagram that shows ref as association.
In a real problem you have more elements, so it makes much more alternatives. It's always up to you to decide what to present and how.
EDIT: Some references to help you understand the notation of interface implementation.
According to wikipedia:
A realization is a relationship between classes, interfaces,
components, and packages that connects a client element with a
supplier element. A realization relationship between classes and
interfaces and between components and interfaces shows that the class
realizes the operations offered by the interface.
You can find some quick reference examples and a lot of information at uml-diagrams.org.
This excellent answer Explanation of the UML arrows will help you with more examples.
Here you can also find some more info on realization.
You can define reference to concrete class as:
Attribute typed as Interface (or ConcreteClass) defined in MyClass, or
Association between MyClass and Interface (or ConcreteClass).
no more options are avialable
Hi there I hope I am able to explain myself clear enough with this problem I have been really confused about.
I have a concrete class called UTModule, it is not subclassed at all, but it is composed of several different abstract objects (for example UTListener, UTRenderer, UTDeliverer) the instantiation of these abstract classes to concrete objects defines the behaviour of my completed UTModule object.
The question I am asking is that, every example I see for the factory design pattern is in regards to an abstract object that is subclassed, whereas my object is a concrete class who's behaviour is decided by its composition.
Am I supposed to create a factory for each of my composite abstract objects? Or just create one factory that creates my UTModule, with the correct composite objects depending on the clients request?
Thanks in advance!
I feel like using the Abstract factory pattern is a clear solution for you.
Lets take UTModule as a abstract factory class which has methods to create a Factory of the Other Objects like "UTListener, UTRenderer, UTDeliverer"
Some additional interface is required for each UTListener, UTRenderer, UTDeliverer and respective factory class for each family.
UTModule add all require method to return the factory of the family you are looking.
For More details and example please follow OODesgin
I am trying to represent the following situation in a UML Class Diagram.
We have a class named Selection where the user select how will the
next screen be.
The selection class has a property screen: Screen, where screen is an interface.
There are multiple implementations of the interface screen. ex. SimpleScreen, SuperScreen, etc.
The screen property in selection class should be able to contain an instance of any implementation of screen depending on user choice.
My questions are:
Is it possible to do this in OO?
How would the Class Diagram representation look like for this case?
Right now I have a diagram like this: http://yuml.me/1dcb2f2f
If you want to modify the diagram I used yuml.me this is the link http://yuml.me/edit/1dcb2f2f
Thank you for your help
Yes it is possible to do it in OO. The correct UML notation is:
http://app.genmymodel.com/engine/xaelis/nextScreen.jpg
In order to act upon an abstract 'screen' polymorphically the implementations would have to adhere to a common interface or inherit from a common base class.
I'm not sure of the proper way to UML this, I think you've got the diagram about right.
Get acquainted with design patterns.
Use factory method (produce instance based on the user choice) +
singleton (makes factory easily accessible and ensures that only one factory exists) for producing instance of needed class +
object composition with bridge pattern(allows to decouple interface from implementation and allows to switch implementation in a run-time/)
Is there a difference in the meaning of "class diagram" and "object graph"?
see this tutorial
http://www.cs.toronto.edu/~jm/340S/Slides6/ClassD.pdf
Object graph contains value of one instance of class see example View its a view of an object system at a particular point in time
while
class diagram as wiki
The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling.[1] The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts: [2]
A class with three sections.
The upper part holds the name of the class
The middle part contains the attributes of the class
The bottom part gives the methods or operations the class can take or undertake
see further
I agree with the previous post but would like to add that a class diagram is based on UML which is an accredited language sponsored by the OMG and known by over 5 millions users. UML is therefore a standard based on a model from which you get views.
IN UML 2 the class diagram is fantastic if used with Java because it seems to me that the new specification has exactly the same structure as a java project. It include a project name, with packages including classifiers (e.g. Class, interface, enum) which includes attributes, methodes which includes properties.
If you have to use just one diagram I would say to use Class diagram. It is easy to create because you don't need to know UML and can reverse engineer your project into a model a get class diagram views. My class diagram is Just magic:-)
Class diagram represent class name,its attributes and behaviours whereas object diagram represent instance of class diagram,object diagram comes under class diagram