Design - UML

 UML Concepts

Structure Diagrams
Behavior Diagram

1.    Class Diagram

2.    Object Diagram

3.    Component Diagram

4.    Deployment Diagram

1.     Use Case Diagram

2.    Sequence Diagram

3.    Collaboration Diagram

4.    State Chart/State Diagram

5.    Activity Diagram

 




       UML Notations 
                        

                  
Association - is a generic relation between the two classes, and is modeled by aline connecting the two classes. The line can be qualified with the types if relationships and multiplicity (1-1, 1-*, *-1, *-*).

Aggregation – (“Has A” relationship) Whole part relationship.


Composition – If a class cannot exist by itself, and instead must be member of another class.

Dependency – When a class uses another class, perhaps as a member variable or a parameter.

Generalization/Inheritence - (“Is A” relationship)

Implementation -

Aggregation is a special kind of an association and Composition is a special kind of an aggregation. (Association->Aggregation->Composition)

 Note: Composition not possible in Java but in C it is possible.


association_aggre_com.gif



We prepare UML diagrams to understand a system in better and simple way. A single diagram is not enough to cover all aspects of the system. So UML defines various kinds of diagrams to cover most of the aspects of a system.
You can also create your own set of diagrams to meet your requirements. Diagrams are generally made in an incremental and iterative way.

There are two broad caetgories of diagrams and then are again divided into sub-categories:
  • Structural Diagrams
  • Behavioral Diagrams
Structural Diagrams:
The structural diagrams represent the static aspect of the system. These static aspects represent those parts of a diagram which forms the main structure and therefore stable.These static parts are represents by classes, interfaces, objects, components and nodes. The four structural diagrams are:
    • Class diagram
    • Object diagram
    • Component diagram
    • Deployment diagram
Class Diagram:
Class diagrams are the most common diagrams used in UML. Class diagram consists of classes, interfaces, associations and collaboration.
Class diagrams basically represent the object oriented view of a system which is static in nature.
Active class is used in a class diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. So it is generally used for development purpose. This is the most widely used diagram at the time of system construction.

Object Diagram:
Object diagrams can be described as an instance of class diagram. So these diagrams are more close to real life scenarios where we implement a system.
Object diagrams are a set of objects and their relationships just like class diagrams and also represent the static view of the system.
The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from practical perspective.

Component Diagram:
Component diagrams represent a set of components and their relationships. These components consist of classes, interfaces or collaborations.
So Component diagrams represent the implementation view of a system.
During design phase software artifacts (classes, interfaces etc) of a system are arranged in different groups depending upon their relationship. Now these groups are known as components.
Finally, component diagrams are used to visualize the implementation.

Deployment Diagram:
Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where the components are deployed.
Deployment diagrams are used for visualizing deployment view of a system. This is generally used by the deployment team.
Note: If the above descriptions and usages are observed carefully then it is very clear that all the diagrams are having some relationship with one another. Component diagrams are dependent upon the classes, interfaces etc which are part of class/object diagram. Again the deployment diagram is dependent upon the components which are used to make a component diagrams.

Behavioral Diagrams:
Any system can have two aspects, static and dynamic. So a model is considered as complete when both the aspects are covered fully.
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams:
    • Use case diagram
    • Sequence diagram
    • Collaboration diagram
    • Statechart diagram
    • Activity diagram

Use case Diagram:
Use case diagrams are a set of use cases, actors and their relationships. They represent the use case view of a system.
A use case represents a particular functionality of a system.
So use case diagram is used to describe the relationships among the functionalities and their internal/external controllers. These controllers are known as actors.

Sequence Diagram:
A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with some sequences, which are the sequence of messages flowing from one object to another.
Interaction among the components of a system is very important from implementation and execution perspective.
So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific functionality.


Collaboration diagram is another form of interaction diagram. It represents the structural organization of a system and the messages sent/received. Structural organization consists of objects and links.
The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of collaboration diagram is to visualize the organization of objects and their interaction.
State Diagram:
State diagrams are used to describe the behavior of a system.  State diagrams describe all of the possible states of an object as events occur.  Each diagram usually represents objects of a single class and track the different states of its objects through the system. 

When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases of the system.  Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system.  Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case
State diagrams have very few elements.  The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state.  The activity section of the state symbol depicts what activities the object will be doing while it is in that state.

Activity Diagram:
Activity diagram describes the work flow of system. So it consists of activities and links. The flow can be sequential, concurrent or branched.
Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared to capture the entire flow in a system.
Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have an idea of how the system will work when executed.
It uses -

When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams and state diagrams.  The main reason to use activity diagrams is to model the workflow behind the system being designed.  Activity Diagrams are also useful for: analyzing a use case by describing what actions need to take place and when they should occur;  describing a complicated sequential algorithm;  and modeling applications with parallel processes.

How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the system.  Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities.  A fork is used when multiple activities are occurring at the same time.

Fork/Join -> User to execute the two activities simultaniously then join each other.
Branch/merge -> The branch describes what activities will take place based on a set of conditions.  All branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. 
Note: Dynamic nature of a system is very difficult to capture. So UML has provided features to capture the dynamics of a system from different angles. Sequence diagrams and collaboration diagrams are isomorphic so they can be converted from one another without losing any information. This is also true for statechart and activity diagram.

        To view sample diagrams of Activity/State -  Click Here
  ------------------------------------------------------------------------------------------------
   High Level Design Models
     
       Domain Model -

       ERD Model  -  Entity relationship diagram(Some time also callled as Server Model)  -    

Creating a good domain model is one of the most difficult challenges developers have to face. What follows are some advices to create a good domain model

1.- Understand the business model completely.

In order to create a good domain model, developers need to look into the detail of the the business model, not only in the surface. It requires to understand and distill the main entities and then find their closest equivalent software abstractions.

2.- Use good names for all your domain model classes.

Naming is critical in software domain modeling. There are two qualities that you should be looking for in a good name for an entity in your model:
  • Consistent. Business and developers should always use the same term to define a single concept.
  • Exact. A name should exactly define the responsibilities of an entity in the domain model.

3.- Use metaphors.

Many times is necessary to model abstract operations/entities in software development, (processing orders, simulations…), for these cases, metaphors will help you to simplify the design of the domain model.

4.- Make the domain model self-contained.

The domain model should contain the raw logic of the application. Any additional logic should be contained in some other layers, as for instance the work-flow, dependency injection, persistence…

5.- Make the domain model independent.

The domain model shouldn’t change because the underlying persistence implementation or the UI or any other layer changes.

6.- Make the domain model technically simple.

It should only contain POJOs. The responsibilities assigned to an entity in the domain model should be limited to only those necessary for the software domain

7.- Keep the domain model updated.

Synchronize it always with the business domain model, having two unsynchronized models is one of the biggest sources of productivity killers. Synchronization requires refactoring and enough test coverage to make sure that things don’t break as they are refactored.

8.- Make the software domain model match the business domain model.

A software domain model should be easy to understand for a business domain model expert and it shouldn’t have any discrepancy.

9.- Care for the code quality of your domain model.

There are two reasons why you want to make sure that the code quality of the domain model is top-notch.
  • The domain model is the foundation of your application, if it is bad, the whole thing can fall apart
  • It changes a lot. There are very few areas in your code that are going to change so many times as the domain model

10.- Test the domain model independently, and involve the customer in the test.

As already mentioned, the domain model is an independent and very important part of the architecture of the application. That’s why is so important to pay attention to test it in isolation. Involving the customers in this test phase can be very productive as they can identify test cases that are likely in production and which probably are the most interesting ones to test.