Case Study Uml

CASE STUDY
ON

“UML(Unified modeling Language)”

LORD KRISHNA COLLEGE OF TECHNOLOGY
Indore (M.P.)

GUIDED BY: SUBMITTED BY:
Mr. Mohsin Sheikh Ganesh Prakash
Roll no.-0835CS071023
CS branch, 3rd Year.

Table of Contents
• Introduction
• UML Diagrams
• UML Diagram Classification
• 4+1 View of UML Diagrams
• Features in UML Tools
• Popular UML Tools
• Representations
• Use Case Diagram
• Class Diagram
• Object Diagram
• Sequence Diagram
• State-chart Diagram
• Activity diagram
• Component Diagram
• Deployment Diagram
• Conclusion

Introduction

UML is a result of the evolution of object-oriented modeling languages. It was developed
by Rational Software Company by unifying some of the leading object-oriented modeling
methods,
• Booch by Grady Booch,
• OMT (Object Modeling Technique), by Jim Raumbaugh and
• OOSE (Object-Oriented Software Engineering), by Ivar Jacobson.

UML is used for modeling software systems; such modeling 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 support for identifying and 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.

Modeling 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. Modeling 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." Hence, the reasons behind modeling can
be summed up in two words:

• Readability
• Reusability

Readability 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. Modeling 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 behavior of the system.

Reusability is the byproduct of making a system readable. After a system has been
modeled to make it easy to understand, we tend to identify similarities or redundancy, be
they in terms of functionality, features, or structure.

Even though there are many techniques and tools for modeling, in this article series, we
will be concerning ourselves with modeling object-oriented systems and applications

using the Unified Modeling Language. The Unified Modeling Language, or UML, as it is
popularly known by its TLA (three-letter acronym!), is the language that can be used to
model systems and make them readable. This essentially means that UML provides the
ability to capture the characteristics of a system by using notations. UML provides a wide
array of simple, easy to understand notations for documenting systems based on the
object-oriented design principles. These notations are called the nine diagrams of UML.

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 modeling language without being tied down to any
technologies.

UML Diagrams

The underlying premise of UML is that no one diagram can capture the different
elements of a system in its entirety. Hence, UML is made up of nine diagrams that can be
used to model a system at different points of time in the software life cycle of a system.
The nine UML diagrams are:

• 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.
Each class in the class diagram may be capable of providing certain
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".
• Collaboration diagram: A collaboration diagram groups together the
interactions between different objects. The interactions are listed as numbered
interactions that help to trace the sequence of the interactions. The collaboration
diagram helps to identify all the possible interactions that each object has with
other objects.
• 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.

UML Diagram Classification—Static, Dynamic, and Implementation

A software system can be said to have two distinct characteristics: a structural, "static"
part and a behavioral, "dynamic" part. In addition to these two characteristics, an
additional characteristic that a software system possesses is related to implementation.
Before we categorize UML diagrams into each of these three characteristics, let us take a
quick look at exactly what these characteristics are.

• Static: The static characteristic of a system is essentially the structural aspect of
the system. The static characteristics define what parts the system is made up of.
• Dynamic: The behavioral features of a system; for example, the ways a system
behaves in response to certain events or actions are the dynamic characteristics of
a system.
• Implementation: The implementation characteristic of a system is an entirely
new feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

• Static
oUse case diagram
oClass diagram
• Dynamic
o Object diagram
o State diagram
o Activity diagram
o Sequence diagram
o Collaboration diagram

• Implementation
o Component diagram
o Deployment diagram

4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a
system, let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers a
different perspective to classify and apply UML diagrams. The 4+1 view is essentially
how a system can be viewed from a software life cycle perspective. Each of these views
represents how a system can be modeled. This will enable us to understand where exactly
the UML diagrams fit in and their applicability.

These different 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 behavior 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: Next, you have the component view that shows the grouped
modules of a given system modeled 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 of the
• Use case View: Finally, we have the use case view. Use case diagrams of UML
are 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
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, 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 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 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 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.

• Version control: A very important feature that we want to have in the UML tool
is 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
the increasing use of iterative methodologies for building software systems, it
becomes very difficult to keep the design of the system in sync with the
developed code. Hence, it would be useful if the UML tool provides integration
with popular IDEs. This feature would enable the UML tool to be updated with
the changes in the source code made in the IDE.
• 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
have increasingly begun to 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.

Popular UML Tools

We will list here a few of the "movers and shakers" of vendors of UML tools. Please note
that this list is by no means exhaustive and is not meant to provide any ranking for any
UML tool.

• Rational Rose: No discussion of UML tools is complete without the mention of
the Rational Rose modeling tool from Rational Software Corporation. Rational
Rose (the Rose stands for "Rational Object-oriented Software Engineering") is a

visual modeling tool for UML. It comes in different versions suited to different
requirements. Rational Rose provides support for all the standard features that we
discussed in the previous section such as UML diagram support, forward and
reverse engineering support, and documentation and round-trip engineering
support. Apart from this, Rational Rose also provides support for version control,
IDE integration, design pattern modeling, test script generation, and collaborative
modeling environment. In addition, Rational Rose also supports the designing of
data models within the same environment. An interesting feature of Rational Rose
is the ability to publish the UML diagrams as a set of Web pages and images. This
enables you to share and distribute your application design where the Rational
Rose tool is not installed.
• Together Control Center: Together Control Center (formerly from
Togethersoft) from Borland is an entire suite of visual modeling tools for UML.
Together Control Center supports UML diagrams, MVC modeling, forward and
reverse engineering, and round-trip engineering, as well as integration with IDEs
such as IBM WebSphere Studio.

It supports comprehensive documentation and a powerful collaborative modeling
environment.

An added feature of Together Control Center is the pattern repository. The pattern
repository (similar to the template-driven modeling concept discussed above)
makes frequently used diagrams and design patterns readily available for reuse in
modeling. Together Control Center supports the Rational Unified Process as well
as the Extreme Programming methodologies.

• Poseidon: Poseidon from Gentle ware has its roots in the Agrium open source
project. The Agrium modeling tool evolved as an open source effort and is a
useful, full-featured UML tool freely available under the Open Publication
License. Gentle ware has taken Agrium a step further and turned it into a good
modeling tool. Poseidon comes in different flavors suited to different
requirements. Poseidon supports forward and reverse engineering and
documentation generation by using special-purpose plug-ins.

Gentle ware has not forgotten its open source moorings and offers the Poseidon
for UML Community Edition 1.5 free for individual software developers.

Representations

Types of Things
Name Symbol Description Variations/
other
related
elements
Description of a set of objects that
share the same: attributes, operations, - actors
Class relationships and semantics. - signals
- utilities

Interface A collection of operations that specify
a service of a class or component.

Collaboration An interaction and a society or roles
and other elements that work together
to provide some cooperative behavior
that is bigger than the sum of all the
elements. Represent implementation of
patterns that make up the system.

Actor The outside entity that communicates
with a system, typically a person
playing a role or an external device

Use Case A description of set of sequence of
actions that a system perform that
produces an observable result of value
to a particular actor. Used to structure
behavioral things in the model.

Active class A class whose objects own a process or
execution thread and therefore can
initiate a control activity on their own

Component A component is a physical and
replicable part that conforms to and
provides the realization of a set of
interfaces.

Node A physical resource that exists in run
time and represents a computational
resource.

Interaction Set of messages exchanged among a
set of objects within a particular
context to accomplish a specific
purpose.

State machine A behavior that specifies the sequences
of states an object or an interaction
goes through during its lifetime in
response to events, together with its
responses to those events.

Packages General purpose mechanism of
organizing elements into groups.

Note A symbol for rendering notes and
constraints attached to an element or a
collection of elements.

Relations

The types of UML relationships are shown in the table 2, relationships are used to
connect things into well defined models (UML diagrams).

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 the
use 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. The implementation class diagram won't be drawn with the same
attributes, however, because it will most likely have references to things like Vectors and
Hash Maps.

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. In
my 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.util).]

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

primary motivation for using UML to describe and build software. Finally, code
generation increases UML's value to the developer by reducing errors and improving
productivity.

Case Study Uml

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Case Study Uml (20)

Recently uploaded (20)

Case Study Uml