Case stydy cs701

RUSTAMJI INSTITUTE OF TECHNOLOGY
BSF ACADEMY, TEKANPUR
CASE STUDY
UML (Unified modeling Language)
Submitted by
RAKSHA RAJPUT(0902CS181037)
SOMYA SINGH GOUR (0902CS18104)
DINKAR MISHRA (0902CS181018)
B.Tech. Computer Science & Engineering 7th
Semester
(2018-2022 batch)
Subject Teacher
MS. Soumya MA’AM
File Checked by
Mr. Yashwant Pathak

Table of Contents
• Introduction
• UML Diagrams
• UML Diagram Classification
• 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".
• 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
o Use case diagram
o Class diagram
• Dynamic
o Object diagram
o State diagram
o Activity diagram
o Sequence diagram
o Collaboration diagram
• Implementation
o Component diagram
o Deployment diagram
Features in UML Tools :-
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.
• 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.
• 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.
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.
• 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.
• 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.
Representations :-
Name Symbol Description Variations/ other
related elements
Class Description of a set of
objects that share the
same: attributes,
operations, relationships
and semantics.
- actors
- 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.
Use-case diagrams :-
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 .

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 diagra :-
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 stydy cs701

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Case stydy cs701

Similar to Case stydy cs701 (20)

Recently uploaded

Recently uploaded (20)

Case stydy cs701