Unified Modeling Language in 5000 words

1. Overview Designing is the most significant part of the software development process that requires the ability to view the real world problem in it's abstract form. The designers analyze the problem domain and sketch a possible solution to the problem by breaking the domain up in to different objects and their relationships. The designers design the system but the challenge is how they would communicate their thoughts to the programmers who eventually will write code to build the system. We need some sort of norms or protocols to represent the design of a software which is unambiguous in nature and has uniform meaning to everyone. Here the significance of standard notations comes into the picture. The most renowned and widely accepted solution to overcome this communication challenge is the Unified Modeling Language (UML), a non-proprietary, object-modeling and specification language used in software engineering. UML includes a standardized graphical notation that may be used to create an abstract model of a system: the UML model. The UML has quickly become the de-facto standard for building object-oriented software.

The OMG specification states:

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."

The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process. Nevertheless, the following factors have led to UML’s rapid and widespread acceptance in the object-oriented design community:

• The language is based on experience
• The language is expressive
• The language has been adopted by the Object Management Group (OMG), a consortium of companies in the object business. As a result, numerous Computer Aided Software Engineering (CASE) tools support it.

As stated earlier, there are a bunch of CASE tools that support the UML specifications; some of those are:

• Rational Rose from Rational
• TogetherJ from Together Soft
• ArgoUML, from open source community etc.

When you are finished reading you will not have enough knowledge to put UML on your resume, but you will have a solid starting point for digging more deeply into the language. UML 2.0 is the basis that I followed through out the article. You'd learn the followings:

• UML concepts
• Highlighted distinctions of UML 2.0
• Various diagrams of the language those includes Use Case diagram, Class diagram, Sequence diagram, State chart diagram, activity diagram, component diagram, deployment diagram etc.
• Some criticism of UML
• Basic installation and setup of ArgoUML and drawing of basic UML diagrams using it
• Some best practices of UML uses

Resource Reference
Find the following links and reference to learn more details on this subject:

Links:
http://www.omg.org
http://www.argouml.tigris.org
http://www.javaworld.com
http://www.sparsxsystems.com.au
http://www.agilemodeling.com

Reference:

1. Designing Flexible Object-Oriented Systems with UML by Charles Richter
2. ArgoUML Quick Guide: Get started with ArgoUML 0.18.1
3. ArgoUML User Manual: A tutorial and reference description

2 UML
As mentioned earlier, one of the purposes of UML was to provide the object-oriented developers community with a stable and common design language that could be used to develop and build computer applications. UML brought forth a unified standard modeling notation that IT professionals had been wanting for years. Using UML, IT professionals could now read and disseminate system structure and design plans – just as construction workers have been doing for years with blueprints of buildings.

UML defines the notations and semantics for the following domains:

• The Use Case Model, describes the systems boundaries and its functionalities under analysis
• The interaction model, describes how the objects interact with each other to form the system
• The dynamic model, describes the states that classes assumes over time. Activity graphs describe the workflows the system will implement
• The Logical or class model, describes the classes and objects and their relationships that will make up the system
• The physical component model, describes the software components that make up the system
• The physical deployment model, describes the physical architecture and the deployment of components on that physical architecture

Although this is out of scope of this article to explain the design process but a simple design process might help the reader to map the modeling language with their usual software development life. Let’s look into the following example to explore the exact places where different models/diagrams fit:

Define the high-level business activities and processes that occur in an organization. These provides the foundation of the Use Case model
Complete the use cases by including requirements, constraints, complexity and scenarios. Also define the relationships among Use Case, if any.
From the scenario texts, develop the sequence diagram, collaboration diagram etc.
From the scenario diagrams develop the static view of the system: the class model. This is a precise specification of the objects in the system, their data or attributes and their behaviors or operations. Scenario diagrams messages shall typically map to class operations.
As the class model develops it may be broken into discrete packages and components. A Component represents a deployable chunk of software that collects the behavior and data of one or more classes. So from the class model a component model is built to define the logical packaging of the classes.
As the analysis and design progresses, the deployment model is developed to define the physical architecture of the system.

2.1 UML 2.0
As experience with UML grew and the issues and needs of software modeling became better understood, new requirements for UML emerged. This led to the issuing of format request for the first major revision of standard. Although the UML 2.0 has been introduced a few years back, in October 2004, but it won’t be redundant or excessive to describe some of the features of the newer version of the language.

The following aspects most clearly distinguish UML 2.0 from earlier versions:

• An increased level of precision in describing the basic modeling concepts in the language and, in particular, their semantics.
• An improved capability to model large-scale software systems. This includes the ability to model entire system architectures – in effect, to use UML as an architectural description language.
• Enhancements to allow modeling of complex network-based business processes and other functionally oriented applications
• Nested Classifiers, an extremely powerful concept.

In UML, almost every model building block you work with (classes, objects, components, behaviors such as activities and state machines, and more) is a classifier. In UML 2.0, you can nest a set of classes inside the component that manages them, or embed a behavior (such as a state machine) inside the class or component that implements it. This capability also lets you build up complex behaviors from simpler ones, the capability that defines the Interaction Overview Diagram.

2.2 Diagrams
According to the latest version of UML, there are 13 types of diagrams. To understand them, it is sometimes useful to categorize them in the following three groups based on their characteristics:

Structure Diagrams emphasize what things must be in the system being modeled:

• Class diagram
• Component diagram
• Object diagram
• Composite structure diagram
• Deployment diagram
• Package diagram

Behavior Diagrams emphasize what must happen in the system being modeled:

• Activity diagram
• Use Case diagram
• State Machine diagram

Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

• Sequence diagram
• Collaboration (UML 1.x)/Communication diagram (UML 2.0)
• Interaction overview diagram (UML 2.0)
• Timing diagram (UML 2.0)

2.2.1 Structural
2.2.1.1 Class Diagram
In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes and the relationships between them. Class is the blueprint of the objects that, with its attributes and behaviors, constructs the system in the Object-Oriented design through the use of associations and relations.

The Class Model is at the core of object-oriented development and design - it expresses both the persistent state of the system and the behavior of the system. A class encapsulates state (attributes) and offers services to manipulate that state (behavior). Good object-oriented design limits direct access to class attributes and offers services which manipulate attributes on behalf of the caller. This hiding of data and exposing of services ensures data updates are only done in one place and according to specific rules - for large systems the maintenance burden of code which has direct access to data elements in many places is extremely high.

Figure 1: Class model

The class has three distinct areas:

1. The class name
2. The class attributes i.e. the internal data structure
3. The class operations to manipulate its data

Attributes and operations may be marked as one of the followings:

• Private (using “—“), indicating they are not visible to callers outside the class
• Protected (using “#”), they are only visible to children of the class
• Public (using “+”), they are visible to all

Relationships:
UML has basically two types of relationships for the class diagram and these are:

Specialization
Specialization and Generalization is the relationship between classes showing is-a-kind-of relationship, in which specialization is the subclass, or subtype and the generalization is the superclass, or supertype; the notation for class specialization and generalization is depicted in the below figure:

Figure 2: Specialization or Generalization

Association
An association describes the logical relationship or dependencies between classes. The association includes cardinality constraints on its end and might have the following values:

• If the end of an association is plain, the cardinality is unspecified
• A non-negative integer indicates that specific value
• An asterisk (*) means many
• A range is denoted using two ellipsis pings (..). hence, 1..* indicates one or more.
• An asterisk (*) alone is shorthand for 0..* i.e.,. zero or more
• Commas separate discrete values. For example, 3, 5 means 3 or 5

The following figure depicts the associations and its cardinality:

Figure 3: Associate with cardinality

Aggregation:
The aggregation relationship is a special form of association used to model the whole-part or part-of relationship. It is drawn with all of the diagrammatic conventions of associations except that a diamond symbol appears next to the whole element. The following figure indicates that an OBJECT1 is a whole with any number of OBJECT2 items as parts.

Figure 4: Aggregation association

Composition:
UML provides a second form of aggregation with very specific and strong semantics, which is the composition relationship. Filling in the diamond specifies it. The composition relationship indicates “strong ownership and coincident lifetime of part with the whole”. The whole must therefore create the part when the whole is created, and it must delete the part as it is deleted. This also implies that a part can belong only to a single whole.


Figure 5: Composition association

Best practice for designing class diagram:

1. Increase Cohesiveness: It is a measure of the diversity of an entity’s features. The less diverse its features are, the more cohesive the entity is. In other words, a highly cohesive entity represents a single concept or engages in just one general type of activity.
2. Reduce Coupling: Coupling in an object-oriented design is a measure of how much a class or an object knows about the world around it. If an object knows about another object more than the first object’s implementation might be affected by the change of the second object’s behavior.
3. Avoid Concrete Super class: The Super class object should not have the instantiation capability. It should be characterized as abstract to keep the place for flexibility.
4. Make the properties of superclasses meaningful in all subclasses. You generally do not want subclasses to inherit things they don’t need.
5. Use specialization only when you have an “is-a-kind-of” relationship.
6. Use aggregation more than specialization: Though specialization seems much more object oriented than aggregation, but aggregation shall keep your design more flexible and less prone to change. Also avoid deeper level of specialization (e.g. more than 3 level)

2.2.1.2 Package Diagram
A package diagram is used to show the logical groupings and the relationships among the groups of a system. The package diagram has the following implications:

• It draws the logical dependencies among the packages. It is a best tool for the software manager to distribute the work packages to the developers effectively.
• The dependency can be measured from the relations among the packages. This is best use by the Change Control Board (CCB) to find out the impact of a proposed change.
• Helps to see the overall logical view of the system

Figure 6: Package diagram

2.2.1.3 Deployment Diagram
The deployment diagram defines the hardware architecture of a system or application. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, the implementation team will make considerable use of this diagram.

The diagram includes a set of nodes, shown as three-dimensional cubes. Each node represents a class of hardware processor and is labeled with the type of the node. The relationships between nodes represent physical connections between the corresponding processors. Both the nodes and relationships can include cardinality constraints. The cardinality constraint of a node usually appears in the upper right corner of the node.

Figure 7: Deployment diagram
2.2.1.4 Composite Structure
The composite structure diagram is used to show the objects involved in collaboration. This is a good tool for describing design pattern, broadly believed by the strong supporter of the latest release of the language. But the developers are greatly familiar with the combination of Class diagram and Sequence diagram while developing a design pattern.

2.2.1.5 Component Diagram
Philippe Kruchten provides two complementary characterizations of a component:

A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realizations of a set of interfaces.

Components offer one or more interfaces and are dependent only on the interfaces of other components

A component diagram provides a physical view of how a system is split up into physical components (e.g. files, headers, link libraries, modules, executables, and packages) and shows the dependencies among these components. Its purpose is to show the dependencies that the software has on the other software components (e.g. software libraries) in the system.

<<Diagram: Sample Component diagram>>


2.2.1.6 Object Diagram
An object diagram is a diagram that shows a set of objects and their relationships at a point in time. Graphically, an object diagram is a collection of vertices and arcs.

An object diagram commonly contains Objects and Links and may contains notes and constraints. Object diagram may also contain packages or subsystems, both of which are used to group elements of your model into larger chunks.

You use object diagrams to model the static design view or static process view of a system just as you do with class diagrams, but from the perspective of real or prototypical instances. This view primarily supports the functional requirements of a system – that is, the services the system should provide to its end uses. Object diagrams let you model static data structures.

2.2.2 Behavioral
2.2.2.1 Use Case Diagram
A Use Case illustrates a unit of functionality provide by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of “actors” (human or any other system that interacts with the system) to essential processes, as well as the relationships among different use cases.

The use case diagram contains three basic components:

System: The system is depicted as a rectangle, labeled with the name of the system

Actor: Each actor is shown as a stick figure

Use Case: Each use case is shown as a solid-bordered oval labeled with the name of the use case


Figure 8: Use Case diagram showing the three notations>>

Use Case Relationships
Use Case diagrams can include relationships between actors and use cases as well as between the use cases themselves. There are two types of relationships: Uses and extends


The UML Notation Guide states uses relation as:

A uses relation from use case A to use case B indicates that an instance of the use case A will also include the behavior as specified by [use case] B.

The notation is a closed-headed arrow annotated with the stereotype name uses. See Figure 8 for the uses relationship

The UML Notation Guide states extends relation as:

An extends relationship from use case A to use case B indicates that an instance of use case B may include (subject to specific conditions specified in the extension) the behavior specified by [use case] A

The notation is the enclosed-headed arrow directed away from the extension (that is, toward the use case that is being extended) with the “extends” stereotype annotation. See Figure 8 for the extends releationship

2.2.2.2 Activity Diagram
An activity diagram is a workflow view. It depicts a set of activities that must be carried out, together with the temporal sequencing of those activities and the conditions under which they occur. It says nothing about what objects are involved. It, therefore, can be used for everything from showing the sequencing of use cases to flow charting an individual method.

Figure 9: Activity diagram

You can refine a use case into an activity diagram that “flowcharts” the steps in the use case. Following is the brief description of the notations of an activity:

1. An activity is modeled as a capsule (that is, as a rectangle with rounded corners) with the activity name enclosed. The activity diagrams starts with a solid circle connected to the initial activity. The end activity is drawn by a small circle, containing another little smaller filled circle

2. The simplest relationship between two activities occurs when one must follow the other. It also contains the cardinality like class diagram.

3. You can indicate that one activity conditionally follows another. The diamond shape (same one is used in the flow chart notation) is used includes condition in the activity diagram

4. Parallelism is an unique notation that helps the designer to draw the multi threaded software.

5. The activities are sometimes organized into different swimlanes which are used to indicate the object actually performs the activity.

2.2.2.3 State Machine Diagram
A state transition diagram is used to show the state-based behavior of a class of instances across all scenarios. Whereas the scope of an interaction diagram is a single scenario, a state machine is tied to one class. It specifies the states through which an instance of that class may pass, the messages to which that instance will respond in each of those states, and the conditions that cause the instance to pass from one state to another

Figure 10: State chart diagram

A state is an abstraction of an object’s state. It is depicted in UML as a capsule with a name and/or a set of actions.
A transition is the movement of an object from one state to another. It is assumed to take almost no time. In a state machine, a transition is depicted as a directed edge between the source and destination states. There are various transitions:

a. Transitions may be triggered by events. There may be a condition (known as a guarding condition) towards a state.

b. A state machine can execute actions while taking a transition.

c. An important grouping feature of State charts is the composite state. A composite state is composed of a collection of lower-level sub-states that share semantics. For example, all of the sub-states may have the same outgoing transition. The states outside the composite states in some cases may ignore the internal details of the composite state and interact with it is as a single state.


2.2.3 Interaction2.2.3.1 Sequence Diagram
An interaction/sequence diagram indicates the sequencing of object interactions in one scenario. It shows exactly which objects respond to which requests, as well as the results of those requests, in that scenario. On the other hand, the internal state of an object, as well as how that state may change during the scenario, is not shown.

A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls and optionally returns of messages/calls in the time order that they occur; the horizontal dimension shows the object instances to which the messages are sent.

A sequence diagram is very simple to draw:

• Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box.
• In the box, put the class instance name and class name separated by a space/colon/space (e.g. myTask:Task).
• If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance; place the name of the message/method above the line.
• Optionally, for important messages, you can draw a doted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line. It is a good practice to include the return value lines because it makes it easier to read.

Figure 11: Sequence Diagram

2.2.3.2 Communication Diagram
Communication diagrams are equivalent to UML sequence diagram and are typically used when you need a bird’s-eye-view of collaborating objects.

2.2.3.3 Timing Diagram
Timing diagrams, for exploring the changes in state an object or component, have been added in the UML 2.0 release. This has a little use with business application developers but might found very useful for the real-time community.

2.3 Criticism
UML has some criticisms those are not baseless though the notations has the wide range of acceptance in the field of software engineering:

• The semantics are imprecise to subjective interpretation and difficulties in the format test phases of development.
• It has weaknesses to design distributed system
• The User Interface design is not specifically covered by any of the UML diagrams.

3 Best Practices

During the design phase of the Software Development Life Cycle (SDLC) the following practices might help you avoid the pitfall usually faces in a development team:

• Use the UML notations from the very beginning of your designing phase otherwise it will cost extra boring hours to convert your own invented notations to the UML diagrams.
• Don’t try to fit UML diagrams to your design rather fit your design thoughts to UML diagrams.
• In the brainstorming session of designing it is best to use paper-pencil rather UML tools. It would give you a room to trace back your design if anything goes wrong
• Don’t be perfectionist while designing but complete your tasks in the stipulated time with what you came out with your present knowledge level. Remember that it is the iterative process and you can easily refine your design at the time of development. If you have to redesign your software more that 20% in the coding phase, you need to be careful in the next design.
• Always keep your design up-to-date with the coding though it costs some extra hours of the designer; it will make your life easy in the bug fixing phase and reduce the dependency on the original coder.
• Use separate engineer to code rather than the original designer of that module; it is helpful to keep the sanity of the design document

5 SummaryI’ve tried to describe all of the diagrams those are used in UML 2.0 release. Some of those are used heavily by the designer community and some are not that much popular. You might notice that the descriptions are lengthened for the diagrams those are widely used; those are:

• Use Case diagram
• Class diagram
• Sequence diagram
• State chart diagram and
• Activity diagram

The fewer used diagrams are sometimes just defined and then left to the reader if he is interested on that topic.

Although this article provides only a brief introduction to Unified Modeling Language, I encourage you to start applying the information you have learned here to your own projects and to dig more deeply into UML. There are several software tools that help you to integrate UML diagrams into your software development process, but even without automated tools, you can use markers on a whiteboard or paper and pencils to draw your UML diagrams and still achieve benefits.