CASE STUDY 

ON 
UML (UNIFIED MODELING 
LANGUAGE) 
JAGANNATH GUPTA INSTITUTE OF 
TECHNOLOGY, JAIPUR 
GUIDED BY: - SUBMITTED BY: - 
Vijay Mohan Shrimal Anubhav Dubey 
Roll no.16EJGCS004 CS Branch, 3rd Year 
 
Contents 
INTRODUCTION 
UML DIAGRAMS 
UML CLASSIFICATIONS 
UML DIAGRAMS MODELING VIEWS 
UML FEATURES 
UML TOOLS 
• REPRESENTATIONS 
• USE CASE DIAGRAMS 
• CLASS DIAGRAMS 
• OBJECT DIAGRAMS 
• SEQUENCE DIAGRAMS 
• STATE CHART DIAGRAMS 
• ACTIVITY DIAGRAMS 
• COMPONENET DIAGRAMS 
• DEPLOYMENT DIAGRAMS 
• TIMING DIAGRAMS 
• PACKAGE DIAGRAMS 
• INTERACTIVE OVERVIEW DIAGRAMS 
CONCLUSION 
 
INTRODUCTION 
UML  is  a  result  of  the  evolution  of  object-oriented  modelling  languages.  UML  (Unified 
Modelling  Language) is a standard language for specifying, visualizing, constructing, and 
documenting  the  artefacts  of  software  systems.  UML  was  created  by  the  Object 
Management  Group  (OMG)  and  UML  1.0  specification  draft  was  proposed  to  the  OMG 
in  January  1997.  It  was  initially started to capture the behaviour of complex software and 
non-software  system  and  now  it  has  become  an  OMG  standard.  This  tutorial  gives  a 
complete understanding on UML. 
Modelling  is  an  activity that has been carried out over the years in software development. 
When  writing  applications  by  using  the  simplest  languages  to  the  most  powerful  and 
complex languages, you still need to model. 
Modelling  can  be  as  straightforward  as  drawing  a  flowchart  listing  the  steps  carried  out 
by  an  application.  Defining  a  model  makes  it  easier to break up a complex application or 
a  huge  system  into  simple,  discrete  pieces  that  can be individually studied. We can focus 
more easily on the smaller parts of a system and then understand the "big picture." 
Modelling is depending on two factors are as follows: - 
Reusability: - 
Reusability is the by-product of making a system readable. After system has 
been  modelled  to  make  it  easy  to  understand,  we  tend  to  identify  similarities  or 
redundancy, be they in terms of functionality, features, or structure. 
Readability: - 
It  brings  clarity—ease  of  understanding.  Understanding  a  system  is  the 
first  step  in  either  building  or  enhancing  a  system.  This  involves  knowing what a system 
is  made  up  of,  how  it  behaves,  and  so  forth.  Modelling  a  system  ensures  that  it becomes 
readable and, most importantly, easy to document. Depicting a system to make it readable 
involves capturing the structure of a system and the behaviour of the system. 
UML  does  not  have  any  dependencies  with  respect  to  any  technologies  or  languages. 
This  implies  that  we  can  use  UML  to  model  applications  and  systems  based  on  either of 
the  current  hot  technologies;  for example, J2EE and .NET. Every effort has been made to 
keep  UML  as  a  clear  and  concise  modelling  language  without  being  tied  down  to  any 
technologies. 
UML is used for modelling software systems; such modelling includes analysis and 
design. By an analysis the system is first described by a set 
 
of  requirements,  and  then  by  identification  of  system  parts  on  a  high  level.  The  design 
phase  is  tightly  connected  to  the  analysis  phase.  It  starts  from  the  identified system parts 
and  continues  with  detailed specification of these parts and their interaction. For the early 
phases  of  software  projects  UML  provide  s  u  p  p  o  r  t  f  o  r  i  d  e  n  t  i  f  y  i  n  g  a  n  d 
specifying  requirements  as use cases. Class diagrams or component diagrams can be used 
for  identification  of  system  parts on a high level. During the design phase class diagrams, 
interaction  diagrams,  component  diagrams  and  state  chart  diagrams  can  be  used  for 
comprehensive descriptions of the different parts in the system. 
UML DIAGRAMS 
UML  is  a  modelling technique so it can be explained through diagrams. There are mainly 
nine diagrams are used out of twelve in UML. These diagrams can be given as following: 
Use case diagram: The use case diagram is used to identify the primary elements and 
processes that form the system. The primary elements are termed as “actors” and the 
processes are called "use cases." The use case diagram shows which actors interact with 
each use case. 
Class diagram: The class diagram is used to refine the use case diagram and define a 
detailed design of the system. The class diagram classifies the actors defined in the use 
case diagram into a set of interrelated classes. The relationship or association between the 
classes can be either an "is-a" or "has-a" relationship. E a c h c l a s s in the class diagram 
may be capable of providing c e r t a i n functionalities. These functionalities provided by 
the class are termed methods of the class. Apart from this, each class may have certain 
"attributes" that uniquely identify the class. 
Object diagram: The object diagram is a special kind of class diagram. An object is an 
instance of a class. This essentially means that an object represents the state of a class at a 
given point of time while the system is running. The object diagram captures the state of 
different classes in the system and their relationships or associations at a given point of 
time. 
 
State diagram: A state diagram, as the name suggests, represents the different states that 
objects in the system undergo during their life cycle. Objects in the system change states 
in response to events. In addition to this, a state diagram also captures the transition of the 
object's state from an initial state to a final state in response to events affecting the 
system. 
Activity diagram: The process flows in the system are captured in the activity diagram. 
Similar to a state diagram, an activity diagram also consists of activities, actions, 
transitions, initial and final states, and guard conditions. 
Sequence diagram: A sequence diagram represents the interaction between different 
objects in the system. The important aspect of a sequence diagram is that it is 
time-ordered. This means that the exact sequence of the interactions between the objects 
is represented step by step. Different objects in the sequence diagram interact with each 
other by passing "messages". 
Component diagram: The component diagram represents the high-level parts that make 
up the system. This diagram depicts, at a high level, what components form part of the 
system and how they are interrelated. A component diagram depicts the components 
culled after the system has undergone the development or construction phase. 
Deployment diagram: The deployment diagram captures the configuration of the runtime 
elements of the application. This diagram is by far most useful when a system is built and 
ready to be deployed. 
Timing Diagram A timing diagram is a type of behavioural or interaction UML diagram 
that focuses on processes that take place during a specific period of time. They're a 
special instance of a sequence diagram, except time is shown to increase from left to right 
instead of top down. 
 
Package Diagram Package diagrams are a subset of class diagrams, but developers 
sometimes treat them as a separate technique. Package diagrams organize elements of a 
system into related groups to minimize dependencies between packages. 
Interaction Overview Diagram Interaction overview diagrams are a combination of 
activity and sequence diagrams. They model a sequence of actions and let you 
deconstruct more complex interactions into manageable occurrences. You should use the 
same notation on interaction overview diagrams that you would see on an activity 
diagram. 
UML CLASSIFICATIONS Uml classified into two distinct characteristics Static 
Classification Dynamic classification Let us discuss all the above classification- 
Static: -It is the structural part of a software system. It can only define the components of 
a software. Dynamic: -It defines the behaviour of a system. An additional characteristic 
that a software system possesses is related to implementation. UML diagrams is 
classified as following: - 
STATIC: 
• USE CASE DIAGRAMS 
• CLASS DIAGRAMS 
DYNAMIC: 
• OBJECT DIAGRAMS 
• SEQUENCE DIAGRAMS 
• STATE CHART DIAGRAMS 
• ACTIVITY DIAGRAMS 
IMPLEMENT DIAGRAMS: 
• COMPONENET DIAGRAMS 
• DEPLOYMENT DIAGRAMS 
 
5 Important view of UML 
There are 5 important views of UML which can explain the applicability of the 
diagrams. These views can define that how this can be modelled. 
These views are: - 
Design View: The design view of a system is the structural view of the system. This 
gives an idea of what a given system is made up of. Class diagrams and object diagrams 
form the design view of the system. 
Process View: The dynamic behaviour of a system can be seen using the Process view. 
The different diagrams such as the state diagram, activity diagram, sequence diagram, 
and collaboration diagram are used in this view. 
Component View: Component view that shows the grouped modules of a given system 
modelled using the component diagram. 
Deployment View: The deployment diagram of UML is used to identify the deployment 
modules for a given system. This is the deployment view. 
Use case View: Use case diagrams of UML is used to view a system from this 
perspective as a set of discrete activities or transactions. 
Features in UML Tools This takes us to an important question—what exactly should we 
look for in a UML tool? Because the primary use of a UML tool is to enable you to draw 
diagrams, first and foremost, we need to see what types of UML diagrams the tool 
supports. But, is drawing diagrams all that you would expect from a UML tool? For 
example, wouldn't it be great if the class diagrams that you draw in the tool can somehow 
be used to generate the source code for actual Java classes or C++ classes? Let us take a 
look at another scenario. Suppose you were given a large set of source code files with lots 
and lots of classes. Wouldn't it be a nightmare wading through the code trying to figure 
out how all the classes are interconnected? This is where UML tools step-in to make 
things a lot easier by providing support for such features. Now, let's define these features 
in technical terms: 
 
UML diagram support: The UML tool should support all the nine diagrams that make up 
UML. You should look for a tool that supports drawing use cases, designing the static 
view diagrams such as class diagrams and object diagrams, defining the dynamic view 
diagrams such as sequence, activity, state, and collaboration diagrams and the component 
and deployment diagrams that form the implementation view of the system. 
Forward engineering: A UML tool should not have its use limited to just a pictorial 
depiction of diagrams. Because the structure of the system defined by the diagram is 
translated by a developer into actual source code (classes), the Maltol should bridge this 
step by generating the source code of the classes with the methods stubbed out. 
Developers can take up this stub code and fill in with the actual code. This characteristic 
of automating the generation of source code is called forward engineering. Forward 
engineering support by a UML tool is normally for a specific language or a set of 
languages. If you are a Java developer, verify that the UML tool that you want to use has 
forward engineering support for Java. Similarly, if you are a C++ developer, the UML 
tool should provide you forward engineering support for C++. 
Reverse engineering: Reverse engineering is exactly the opposite of forward engineering. 
In reverse engineering, the UML tool loads all the files of the application/system, 
identifies dependencies between the various classes, and essentially reconstructs the 
entire application structure along with all the relationships between the classes. Reverse 
engineering is a feature normally provided by sophisticated and high-end UML tools. 
Round-trip engineering: Another useful feature apart from forward and reverse 
engineering is round-trip engineering. Forward and reverse engineering are essentially 
one-off activities that take input and generate the required output, An important rule in 
software design is that no design remains unchanged. This is as true for small systems as 
it is for large systems. During development, the design structure defined in the UML 
model does undergo changes to incorporate physical differences in implementation that 
may not have been envisaged during design. It becomes very difficult to keep the design 
of the system updated with the changes in the source code. The round-trip engineering 
feature enables the Maltol to synchronize the model with the changes in the application 
code. 
Documentation: Documentation is an integral aspect of a UML tool. Software designing, 
by nature, is an abstract process. Apart from a few syntax and semantic ground rules, 
there 
 
are  no  other  rules.  The  thought  process  of  a  software  architect  who  designs  applications 
using  UML can be lost if the reasons behind certain design decisions are not captured and 
well  documented.  This  becomes  painfully  clear  when  large  systems  are  maintained  and 
no  one  has  a  clue  to  why  a  subsystem was designed in a certain way. Hence, a UML tool 
must  necessarily  provide  some  way  for  the  designer  to  document  design  decisions  in the 
diagrams  by  using  simple  things  such as annotations or comments. In addition to this, the 
tool  should  support  the  generation  of  reports/listings  of  the  different  design  elements  of 
the  diagram.  Apart  from  the  above  features,  you  should  also  identify  a  few  features  that 
would definitely be useful to have in the UML tool. 
Version control: A very important feature that we want to have in the UML tools either 
an integrated version control mechanism or connectivity to a standard version control 
system. Configuration management is an integral part in the building of software systems. 
Considering that the design of a system is a very important artifact of the software 
lifecycle, maintaining versions and baselines of the system design is a desirable feature to 
have in UML tools. In the absence of direct support for version control, it is the 
responsibility of the designer to maintain versions of the design. 
Collaborative modeling environment: Enterprise systems are huge and their designs are 
quite complex. While designing complex systems, there may be different teams involved 
and may carry out design work on different subsystems in parallel. This collaborative 
design effort needs to be properly synchronized by the UML tool. The UML tool should 
provide support for a collaborative modeling environment with capability to compare 
different versions designs for differences or even merge different versions of a design. 
Collaborative modeling is always a nice feature to have in UML tools. 
Integration with popular Integrated Development Environments (IDE): With Features in 
UML Tools this takes us to an important question—what exactly should we look for in a 
UML tool? Because the primary use of a UML tool is to enable you to draw diagrams, 
first and foremost, we need to see what types of UML diagrams the tool supports. But, is 
drawing UML diagrams all that you would expect from a UML tool? For example, 
wouldn't it be great if the class diagrams that you draw in the tool can somehow be used 
to generate the source code for actual Java classes or C++ classes? Let us take a look at 
another scenario. Suppose you were given a large set of source code files with lots and 
lots of classes. Wouldn't it be a nightmare wading through the code trying to figure out 
how all the classes are interconnected? This is where UML tools step in to make things a 
lot easier by providing support for such features. Now, these features in technical terms: 
 
UML diagram support: The UML tool should support all the nine diagrams that make up 
UML. You should look for a tool that supports drawing use cases, designing the static 
view diagrams such as class diagrams and object diagrams, defining the dynamic view 
diagrams such as sequence, activity, state, and collaboration diagrams and the component 
and deployment diagrams that form the implementation view of the system. 
Forward engineering: A UML tool should not have its use limited to just a pictorial 
depiction of diagrams. Because the structure of the system defined by the diagram is 
translated by a developer into actual source code (classes), the UML tool should bridge 
this step by generating the source code of the classes with the methods stubbed out. 
Developers can take up this stub code and fill in with the actual code. This characteristic 
of automating the generation of source code is called forward engineering. Forward 
engineering support by a UML tool is normally for a specific language or a set of 
languages. If you are a Java developer, verify that the UML tool that you want to use has 
forward engineering support for Java. Similarly, if you are a C++ developer, the UML 
tool should provide you forward engineering support for C++. 
Reverse engineering: Reverse engineering is exactly the opposite of forward engineering. 
In reverse engineering, the UML tool loads all the files of the application/system, 
identifies dependencies between the various classes, and essentially reconstructs the 
entire application structure along with all the relationships between the classes. Reverse 
engineering is a feature normally provided by sophisticated and high-end UML tools. 
Round-trip engineering: Another useful feature apart from forward and reverse 
engineering is round-trip engineering. Forward and reverse engineering are essentially 
one-off activities that take input and generate the required output. Round-trip engineering 
extends these features. An important role in software design is that no design remains 
unchanged. This is as true for small systems as it is for large systems. During 
development, the design structure defined in the UML model does undergo changes to 
incorporate physical differences in implementation that may not have been envisaged 
during design. It becomes very difficult to keep the design of the system updated with the 
changes in the source code. The round- trip engineering feature enables the UML tool to 
synchronize the model with the changes in the application code. 
 
Documentation: Documentation is an integral aspect of a UML tool. Software designing, 
by nature, is an abstract process. Apart from a few syntax and semantic ground rules, 
there are no other rules. The thought process of a software architect who designs 
applications using UML can be lost if the reasons behind certain design decisions are not 
captured and well documented. This becomes painfully clear when large systems are 
maintained and no one has a clue to why a subsystem was designed in a certain way. 
Hence, a UML tool must necessarily provide some way for the designer to document 
design decisions in the diagrams by using simple things such as annotations or comments. 
In addition to this, the UML tool should support the generation of reports/listings of the 
different design elements of the diagram. Apart from the above features, you should also 
identify a few features that would definitely be useful to have in the UML tool. 
Test script generation: The system or subsystem designed in a UML tool may represent a 
set of functional aspects as well. Hence, it would be really useful if, in addition to 
generating stub code, the tool also generates test scripts that can be used for testing how 
the generated class functions. 
Model View Controller (MVC) modeling: Enterprise application architectures h a v e i n 
c r e a s i n g l y b e g u n t o standardize and are based on the Model View Controller 
architecture. Hence, if you design n-tier, Web-enabled enterprise applications, you should 
look for a UML tool that supports designing applications based on the MVC architecture. 
Support for MVC modeling makes it easier to organize and clearly distinguish the design 
elements along the lines of the MVC layers. This will help in the long run in improving 
the readability of the model. 
 
Representations 
Use-case diagram A use case illustrates a unit of functionality provided 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 beings 
who will interact with the system) to essential processes, as well as the relationships 
among different use cases. Use-case diagrams generally show groups of use cases — 
either all use cases for the complete system, or a breakout of a particular group of use 
cases with related functionality (e.g., all security administration-related use cases). To 
show a use case on a use-case diagram, you draw an oval in the middle of the diagram 
and put the name of these case in the center of, or below, the oval. To draw an actor 
(indicating a system user) on a use-case diagram, you draw a stick person to the left or 
right of your diagram (and just in case you're wondering, some people draw prettier stick 
people than others). 
Class diagram: The class diagram shows how the different entities (people, things, and 
data) relate to each other; in other words, it shows the static structures of the system. A 
class diagram can be used to display logical classes, which are typically the kinds of 
things the business people in an organization talk about.Class diagrams can also be used 
to show implementation classes, which are the things that programmers typically deal 
with. An 
 
implementation class diagram will probably show some of the same classes as the logical 
classes diagram. 
Object Diagram An Object diagram focuses on some particular set of object instances 
and attributes, and the links between the instances. A correlated set of object diagrams 
provides insight into how an arbitrary view of a system is expected to evolve over time. 
Object diagrams are more concrete than class diagrams, and are often used to provide 
examples, or act as test cases for the class diagrams. Only those aspects of a model that 
are of current interest need be shown on an object diagram. 
 
Sequence diagram Sequence diagrams show a detailed flow for a specific use case or 
even just part of a specific use case. They are almost self-explanatory; they show the calls 
between the different objects in their sequence and can show, at a detailed level, different 
calls to different objects. A sequence diagram has two dimensions: The vertical 
dimension shows the sequence 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. 
State-chart diagram The state-chart diagram models the different states that a class can be 
in and how that class transitions from state to state. It can be argued that every class has a 
state, but that every class shouldn't have a state-chart diagram. Only classes with 
"interesting" states — that is, classes with three or more potential states during system 
activity — should be modeled. The notation set of the state-chart diagram has five basic 
elements: the initial starting point, which is drawn using a solid circle; a transition 
between states, which is drawn using a line with an open arrowhead; a state, which is 
drawn using a rectangle with rounded corners; a decision point, which is drawn as an 
open circle; and one or more termination points, which are drawn using a circle with a 
solid circle inside it. To draw a state-chart diagram, begin with a starting point and a 
transition line pointing to the initial state of the class. Draw the states themselves 
anywhere on the diagram, and then simply connect them using the state transition lines. 
 
Activity diagram Activity diagrams show the procedural flow of control between two or 
more class objects while processing an activity. Activity diagrams can be used to model 
higher-level business process at the business unit level, or to model low-level internal 
class actions. Inky experience, activity diagrams are best used to model higher-level 
processes, such as how the company is currently doing business, or how it would like to 
do business. This is because activity diagrams are "less technical" in appearance, 
compared to sequence diagrams, and business- minded people tend to understand them 
more quickly. 
 
Component diagram A component diagram provides a physical view of the system. Its 
purpose is to show the dependencies that the software has on the other software 
components (e.g., software libraries) in the system. The diagram can be shown at a very 
high level, with just the large-grain components, or it can be shown at the component 
package level. [Note: The phrase component package level is a programming 
language-neutral way of referring to class container levels such as .NET’s namespaces 
(e.g., System.Web.UI) or Java's packages (e.g., java).] 
Deployment diagram The deployment diagram shows how a system will be physically 
deployed in the hardware environment. 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, a system's production staff will 
make considerable use of this diagram. The notation in a deployment diagram includes 
the notation elements used in a component diagram, with a couple of additions, including 
the concept of a node. A node represents either a physical machine or a virtual machine 
node (e.g., a mainframe node). To model a node, 
 
simply draw a three-dimensional cube with the name of the node at the top of the cube. 
Conclusion: 
UML  does  not  provide  the  magic  solution  to  all  embedded  development  problems. 
However,  it  is  possible  to  make  significant  steps  to  improve  the  productivity  of  a 
developer  by  using  UML  model-driven  development  and  robust  and  powerful  OO 
language. Alleviating the chaos of complex software development is the