A question from java interview:
You have to design a system that will manage 3 ducks:
The first one knows how to swim and fly, the second knows to swim and to hunt, the third knows to swim, fly and hunt. Describe the UML class diagram and explain the terms abstract class and interface. End of question.
In my opinion, i would create a "Duck" class with a method swim() in it, and 2 more classes "flyingDuck" and "huntingDuck" will derive from "Duck", and will contain the methods fly() and hunt() respectivly. One more class will be "universalDuck" and it will derive from "huntingDuck" and will contain the method eat(). What do you think ? Is this a good design or it's better to do it with interfaces ?
Why do you want to model a "universalDuck" extending "huntingDuck" by the method eat()? Was this asked for in your Java interview question?
Since the question asked for explanations of the terms abstract class and interface, you are probably expected to use these concepts in your model. For having a duck3 as an instance of a class that inherits both fly() from "flyingDuck" and hunt() from "huntingDuck" you will need to use interfaces for "flyingDuck" and "huntingDuck" because in Java you can only have multiple inheritance from interfaces.
Related
My Question in Analysis and design system with UML Methodology
Dose the abstract class have attributes or just Methods?
Thanks.
Can have both.
If at least one method is abstract, a class is abstract.
I'm creating some UML diagrams, and I have a large number of classes implementing an interface.
Is it necessary for these classes to also list the methods of the interface? It sounds quite trivial but will make the diagram look much simpler if they do not.
Here is an image to show what I mean:
(source: yuml.me)
Any implementation of MyInterface requires method1, method2 and method3 - so can these be left out?
I often refer to Agile Modeling's class diagramming guidelines. You'll find your question answered in section 3, "Interfaces".
Quick answer: They can be left out.
I have created a design using class diagram. However I was asked to give some explanation on the class diagram.
IMO, class diagram is fairly. For example, if a class is labeled as "Cat", am I going to explain, this "Cat" class represents "Cat"?
What is the best way to explain UML class diagram?
saying class Cat represents cats is one thing you can do, which is maybe not very exciting, though. More interesting to explain might be: associations, abstract classes, interfaces, inheritances, etc. is there any design pattern you are using? maybe explain them.
I hope this will help!
Suppose you have to explain this class diagram to your client in lieu your manager will. Just think how you will define all the responsibilities of each class present in that diagram. Give one-liner definition of its properties, methods, parent and child classes etc (go in bit more details when needed as well).
Define what would be the flow and how one class will link to another one.
For example:
Is your class 'cat' has any association with class Animal or interface IAnimal. You can think more of it and go better.
whatever the type of uml diagram, you should always add some explanantions in natural language.
at least explain some key aspects of the solution : this has a reference to this
this inherits from this class and do not need to override this operation.
I do need your valuable help.
A few weeks ago I developed a small program in Java.
Probably a wrong approach, but I didn't tackle the problem with UML in mind, but on the basis of a given idea I
built a fully functional piece of software which lives up to expectations.
The program itself consist of two classes and several methods.
Now I need to draw the corresponding UML class diagram and it seems a very knotty problem for me.
Since the UML class diagram aims at showing the source code dependencies between classes, I'm wondering
how I can draw a class diagram based on the following code.
.................................................................
import javax.swing.JPanel;
class WavPanel extends JPanel {
List<Byte> audioBytes;
List<Line2D.Double> lines;
public WavPanel() {
super();
setBackground(Color.black);
resetWaveform();
}
public void resetWaveform() {
audioBytes = new ArrayList<Byte>();
lines = new ArrayList<Line2D.Double>();
repaint();
}
}
................................................................
In a nutshell, the WavPanel class is an example of inheritance.
The JPanel class (part of a package) acts as a superclass.
How can I solve the problem?
My concern is that JPanel is a class which is part of a package.
Furthermore, in order to draw a good class diagram am I wrong in
thinking that maybe I had to do the UML diagram first and then write the
associated code?
The fact that I wrote several methods (instead of classes) and just a few classes,
can that be a problem with UML?
If so it would mean reengineering the entire software again.
Thanks in advance . Any help will be highly appreciated.
Yes, you should always do the planning before the programming. However, all is not lost.
You can still use JPanel in your UML, just show the inheritance (using the white diamond) for subclasses that use JPanel. I like to draw all my UML diagrams using UMLet, especially because (in the future, when you do UML first ;)) you can export your diagrams into Eclipse!
Methods and their arguments are specified inside the classes in a UML diagram. You don't really care about what each method DOES for a class diagram, just its characteristics for the most part. Focus on show the relationships between classes, even if they are libraries. Don't worry about all the individual methods in a library though...some API somewhere has probably taken care of that.
Do you need more help on UML itself? Let me know and I can add to this answer to clarify any other questions you have on UML in general, or consult this Wikipedia article on class diagrams.
You're not thinking about UML properly.
If your application works, then the fact that the UML is causing you difficulty should not be a concern.
UML is a communication notation, nothing more.
It's not a requirement to do the UML before coding. UML is not a requirement at all. Thinking is required. If creating UML helps you to think, by all means do it. But it's not required.
Your solution is simple: either import JPanel into your UML model and add inheritance to the class diagram, or create a stand-in for the sake of the diagram.
The program itself consist of two
classes and several methods.
No, the program consists of two classes that were written by you plus several core Java classes (e.g., JPanel, List, etc.) Are you suggesting that it's important to include every class in your class diagrams, even the Java core classes? I would disagree with that. Perhaps noting that your WavPanel inherits from JPanel would be useful, but I don't add java.lang.String to any UML diagrams that I create.
I wouldn't consider UML to be worth the effort for a solution that consisted of five classes or fewer. Those I can keep in my head. UML tends to help more when I have a larger problem than five classes.
I'm drawing some UML in which a concrete class inherits from an abstract class which defines a pure virtual method. Is it required to show this method in the concrete class as well? It's implied by inheriting from the abstract class.
Nope, you don't need to. in fact, in general, don't put any more in the UML than you must have to clarify what you're saying, unless you're (god forbid) trying to generate code from it.
The best guide I know of for UML is UML Distilled by Martin Fowler.
The funny thing about UML is that it has a pretty loose and varied definition. Most things that are called UML are actually not much more that block diagrams. There is a lot of ambiguity in any UML implementation.
I would say that if you are doing this for a presentation or architectural diagram, you can take care of a lot of the possible ambiguity with 'words'. If you will be generating code from it using some application, you should check the docs of that particular application.
It's implied and in fact, many CASE tools would show you the inherited method as part of the list of the methods of the subclass when clicking on the class at looking at its properties (and some CASE tools even have the option of showing also the inherited methods in the diagram)