My program has one public class followed by a constructor and 2 local classes (the inner classes have action events) called from a method. There is one additional static methods.
Public class
Constructor
local Classes
Methods
I am very confused to how the UML diagram would look for this. I have made one for a super class and subclasses before and it was straightforward enough, but i'm not sure how to include local classes and action events (like key listener).
Thank you for your help. I am new to java so go easy please.
Edit: I meant Class diagrams not all UML in general. Sorry.
A quick Google search yielded the following from http://www.sparxsystems.com/resources/uml2_tutorial/uml2_classdiagram.html:
Nestings
A nesting is connector that shows the source element is nested within the target element. The following diagram shows the definition of an inner class, although in EA it is more usual to show them by their position in the project view hierarchy.
(source: sparxsystems.com)
UML defines 14 different types of diagrams. In the following I will assume you refer to the most common one: the Class Diagram.
Local classes have no inheritance relationship to the class they are defined in. However, each of their instances contain a reference to an instance of the class where they were defined. When you write new LocalClass() (which is the most usual), the referenced "parent" object is this. When you write aDefiningClassInstance.new LocalClass(), the referenced "parent" object is aDefiningClassInstance.
That clarified, the relationship of what you call the "public class" with the local classes is one of composition. Cardinality depends on you particular case, but it's most probably one-to-one with each local class.
Modern versions of UML introduce syntax for inner classes (which are practically the same as local ones), but IMHO this is excesively related to specific programming languages and does not represent the high-level relationships that UML is usually used for.
Whatever method calls the event handlers, it should belong to a class directly or indirectly storing references to them. Here you have two additional UML aggregation relationships (also of probable cardinality of one-to-one) if the calling method belongs to a class different to the defining one.
Related
If you want to show, for example, that a class Match contains an instance of class Game and class Set, then do you just simply have them in the attributes or do you have a line to the classes representing that when the instance of Match is created then that also creates an instance of Game and Set?
Here's what I mean in code:
public class Match {
private Set set = new Set();
private Game game = new Game();
}
This kind of relationship between classes is called association. Association is marked in UML with simple arrow:
We also have to types of association:
1. Composition - when our class contains reference to the other class and other class cannot exist without our class.
For example Human contains Hand, Leg, Heart, Car conatins Engine, Wheels. This type of association is understood as strong reference in garbage collection programming languages.
2. Aggregation - when our class contains reference to the other class and other clas can exist without our class, for example School contains Student.This type of association is understood as weak reference in garbage collection programming languages.
Composition is definetly the stronger one.
Hope it helps.
Both listing as attributes and showing as association (line pointing to another class) are valid and have exactly similar semantic.
Showing graphically rather than textually gives you opportunity to optionally present additional information: aggregation/composition, availability, ownership. Yet if none of this is present or important, the meaning is precisely the same and one can be replaced with another depending on what is more useful for you.
I'm trying to implement this in Java and I'm facing some interface / inheritance problems. I'm quite new to OO concepts so this will likely be an architecture choice / concept misunderstanding. If some information is missing, tell me and I'll try to make myself clearer.
Switches can be OSIL 2 or 3 equipments so I assume I need interfaces for the inheritance because one can only have on superclass at once, right ?
Problem : I cannot make Node an interface because I need its attribute and if it's not an interface OSIL3Equipement (as an interface) can't inherit from it.
Question : how can I model this in Java (aka where's the mistake in my class hierarchy ?)
(Italic written class names means its abstract, might be a convention but I prefer to point it out)
So part of the issue is that switches are trying to do two different things at once. Would it be possible to model them separately? OSIL 2 Switch and OSIL3 Switch. (possibly with switch as the interface that both are implementing on top of their OSIL Equipment base class)
If it needs to be a single object, could can work around java's lack of multiple inheritance by turning one of the abtract classes into an interface, and letting each implementation of it define its own data structure. ie: OSIL2Equipment is an interface method with getARPTable() or doARPTableLookup(), and the Switch class would just define it as a private field.
my program runs through source code easily enough and I can detect easy relationships such as implementation or inheritance using extends just by searching for where the class is defined. However, I'm a bit stuck with ideas on how to detect other relationships such as if a class has association or aggregation with another class.
So far I have tried parsing the code and looking for where other methods are called but I'm not sure of an exact code definition of these relationships.
Sorry if I am being unclear I can try and explain better if you don't understand just let me know in the comments.
Aggregation and composition both look like member variables in Java
e.g.
class MyClass {
private HerClass h;
}
MyClass HAS-A HerClass member - so that's composition or possible aggregation. You could tell the difference based on whether MyClass creates the HerClass - that would PROBABLY be composition.
Association is based on dependency. Why don't you use the imports to find out which classes are depended on? Or you could scan any use of type names in the code - the moment a type name is mentioned, there's a "uses" association.
The problem is that there is not any strict definition how to translate Java classes relations in associations, dependencies and aggregations. You should set the rules yourself, only check them against the UML standard.
I would advice the following :
UML Java
Dependency A->B Class A mentions class B
Association A->B Class A has reference {that can have reference} (it is recursive!} to class B
Composition A->B Class A has array or collection of B or of references to B AND
(black diamond) no other classes have instances of B or references to them,
either single or collective (arrays, collections)
Shared aggregation A->B Class A has array or collection of B or of references to B AND
(empty diamond) at least one other class has an instance of B or references to such,
either single or collective (arrays, collections)
If according to the last rule, you get two-sided shared aggregation A-B, it is forbidden. So, change it to two mutual shared aggregations.
Remember, that Association and Shared aggregation have NO strict definitions, only limitations.
I am writing a dense hierarchy of classes all deriving from a single abstract parent class for a project that will need to make use of polymorphism, and also to trace objects through the class hierarchy. I have determined that a cluster of classes are the same, in that they could all have an abstract parent class which is a child of the overall parent. However, for the purposes of the project, there is no need to implement anything in this class that isn't already defined in its parent. I have decided to create the class and leave it empty, as I feel it would be useful in narrowing down precisely what kind of object the program is dealing with at run time. Is this bad practice?
In certain cases, this is fully acceptable. I've done this before; it mostly involved empty classes which would specify certain generic parameters, so they were not "really" empty, as the type parameters narrowed the base class down a bit.
To develop a fully functional application consisting of more than 4 classes, what is the right way of handling shared data? I have researched about Static Methods and variables and Utility classes. It's said that use of Static methods hinders the concept of Object Orientation concept. So, if anybody could help me on how to use shared data between classes without hindering Object Oriented concept, then I would be highly grateful.
There are two primary axes of "inheritance" in object-oriented languages like Java. "Implementation" inheritance is where the sub-class inherits the actual code implementation from the parent. "Interface" inheritance is where the "sub-class" adheres to the public interface of the "parent".
Alas, Java actually mixes the two notions together a bit... Java interfaces are nice and clean -- when you "implement" an interface, you are stipulating that your class adheres to the "contract" of the interface that you specified. Java class inheritance isn't so clean -- when you sub-class in Java you are getting both the code inheritance but you are also stipulating that your sub-class adheres to the "contract" of the interface of the parent class.
Abstract classes in Java are just like regular Java classes but with the added constraint that you cannot instantiate them directly. In terms of that added constraint, they are basically classes which don't actually implement all of the code specified by their "contract".
So, it's generally considered good OO practice to specify the "contract" which you want to adhere to via Java interfaces. Then use normal Java class inheritance primarily for code reuse purposes. Use abstract Java classes when you want to provide some standard base code but want/need to force the user's of your class to complete the implementation (i.e., you create a skeleton implementation and the sub-classes must flesh it out).