Skip to main content

UML 2.0 - Class diagram and different relations

Lately I had a hard time to understand different notations used in UML 2.0 to represent relationship between classes in a class model. Though I have experiences in programming and designing, it did not help much. Therefore to enhance this knowledge I did some research on internet and also read a beautiful book on UML 2.0 by Martin Fowler. Indeed it helped me a lot and here goes some of my interpretation on Class modeling based on UML notations.

UML 2.0 defines standard notations to indicate relationship between the classes. The class diagram is necessary while designing behavior of a component. Also helps a lot in TDD to scribble some design before start coding. The relationship between classes can be defined as below,
  • Relationship that is defined at instance level, are of three type. Relation that is defined at instance level can be considered as a run-time relation. These relations are realized and contributed at run-time.
    • Association: It defines the abstract form of a relationship among two classes. The association can be on visibility and usability of the classes. It depicts the link with in classes in-terms of multiplicity, direction, aggregation, composition etc. For example, Class A is associated with Class B in order to use some of its properties. So it can be a dependency, aggregation, composition which is not clear. Hence it is abstract level representation of a relationship. Association can be used at the early stages of class design where the designer not much clear with the exact relation.
        
    • Aggregation: It represents a has-a relationship among objects. This is a kind of weak relationship among objects. If you remove the relationship from a class, it should not affect the life-cycle much. For example, Pond has a fish. which is a weaker relationship. A pond can sustain its life-cycle without a fish. 
    • Composition: It represents another variant of has-a relationship among objects. This is a kind of strong relationship among objects. If you remove a composition relationship from a class, it will affect the life-cycle. For example, Mobile has a Battery. which represents a strong relationship between the mobile and the battery classes. A mobile cannot sustain its life-cycle without a battery.
  • Relationship that is defined at class level
    • Generalization: The generalization relationship among classes represents the is-a relationship of object oriented design paradigm. In this relationship there will be a super class considered as generalization of sub classes. The sub classes will by default inherit the behavior of the super class once this relationship has been established. For example, Cow is a type of Animal. Hence a Cow by default inherits all the properties of an Animal. However Cow can also have some specialized behavior which is applicable in its life-cycle. In java this relation is established using extends keyword. Is a relationship can be achieved using a Concrete or Abstract class as a super class.         
    • Realization: A realization relationship is relationship between two classes where one will define the behavior and other implements it. The class which defines the behavior is called as interface. The implemented class have to execute all the behavior that is defined in the super class. However in case of generalization the sub class do not need to execute all the behaviors. The realization relationship is typically used in a situation where the concrete class need to expose some behavior to other clients, those behaviors can be represent by a component. Also in some cases realization is used to define common behavior between more than one classes, For example, A person can be a professor or a student and both has common attribute first and last name but with different values.  
       
  • General relationships
    • Dependency: Dependency among the classes is a weaker form of relationship. It mostly does not affect the life-cycle of a class, however can be a cause of exception if it is missing. The dependency can occur based on operation or attribute used by class from another class at some point of time during the life-cycle. For example, Incoming call to mobile always displays the caller identification number. Imagine situation where the incoming call class need to detect an anonymous call, then it need to depend on a separate class say Anonymous Call detector class. So incoming call has a Anonymous Call detector. It is also depicted an aggregation. 
    • Multiplicity: It depicts the number association among the classes with respect to instances. Using multiplicity a class represents the number of instances of a class to which it is associated. For example, One Pond can associates with one or many Fishes. Similarly a company can have more than one employees. This relation can be indicated as (0..1) - no or more instances, (1) - one instance, (0..*) zero or more instances, (1..*) one or more instances, (*) - many instances.
Hope this discussion will help the designers. For more : http://en.wikipedia.org/wiki/Class_diagram

Popular posts from this blog

Spring: Method Injection

This is useful when a Singleton bean need to use a non-singleton bean. Sometime your application may need to collaborate a prototype bean with a singleton bean to satisfy your business logic. That is your singleton bean is dependent on a prototype bean. Let’s consider three beans Customer Sales Person Product A customer may ask a sales Person to show different type of products from the repository. Let’s assume you have gone to a garment shop to buy a new shirt for the lucky date with your new girlfriend. So, it’s a tough choice and you may like to try different colors and styles and finally you will choose one. So, if we describe the above situation in the form of business logic inside one of your module, it will look like this, The sales Person should show a new product every time he requests. Let’s assume Customer and Sales Person to be singleton bean in your Spring container and Product as prototype. But based on bean life-cycle a prototype bean can not be injec...

Copying objects – Java Clonable interface

We can assign reference of an object to another, provided each of them satisfies an “ is-a” relationship or of same type. For example, a Dog object can hold the reference of another Dog object regardless both have different states. Similarly an Animal object can hold the reference of a Dog or Cat object, if they satisfies an “is-a” relationship. But hold on, these assignments do not help you to create a duplicate copy of the object. It’s nothing but different pointers pointing to the same memory location. Java provides API to clone an object. Using this API one can get a copy of an object to another. To achieve this, proposed class should implement Clonable interface (else JVM will throw CloneNotSupportedException during runtime). The rationale behind cloning is to get an independent copy of an object. The Object class has a clone() method which takes care of this operation. This method is protected by nature and returns an Object , when called.   You can call this ...

JUnit Rule : Creating Temporary Folder

I was surprised to see this beautiful feature in JUnit and it helped to ease to lots of constrains I face while writing JUnit tests. I basically follow TDD and as you guys know we focus more on writing tests, hence it is necessary to use some shortcuts availed by the tools like JUnit to make the process fast. Recently I had an issue where I had to create and delete a file before and after every test executes. I did that using @Before and @After annotation of Junit and it worked, however I was looking for more of a generic way to do this at one place. As I started googling I came across this post, which is amazing,  After reading the block I know how I can generalize my creating and deleting of a temporary file or folder (I decided to go with a temporary folder and a file inside it, which looks more readable and oganized). The JUnit class: public class TemporaryFolderTestCase { @Rule public TemporaryFolder temporaryFolder = new TemporaryF...