SOFTWARE

ENGINEERING
TOPICS: 1)UML AND USE-CASE DIAGRAM
2)REVERSE ENGINEERING
3)RATIONAL ROSE

NAME: NIMRA SAGHEER

ROLL NO: 814/909153
CLASS: BS (Computer Science)
SEMESTER: 5th (Morning)
SUBMITTED TO: PROF. NASRULLAH
 Unified Modeling Language (UML)
Introduction
Unified Modeling Language (UML) is a standardized general-purpose
modeling language in the field of object-oriented software engineering.
UML includes a set of graphic notation techniques to create visual
models of object-oriented software systems. UML combines techniques
from data modeling, business modeling, object modeling, and component
modeling and can be used throughout the software development life-
cycle and across different implementation technologies.
Modeling
There is a difference between a UML model and the set of diagrams of a
system. A diagram is a partial graphic representation of a system’s model.
The model also contains documentation that drives the model elements
and diagrams (such as written use cases).
UML diagrams represent two different views of a system model:
Static (or structural) view
This view emphasizes the static structure of the system using objects,
attributes, operations, and relationships. Ex: Class diagram, Composite
Structure diagram.
Dynamic (or behavioral) view
This view emphasizes the dynamic behavior of the system by showing
collaborations among objects and changes to the internal states of
objects. Ex: Sequence diagram, Activity diagram, State Machine diagram.
Types of diagrams
UML has different types of diagrams divided into multiple categories.

1
 Diagrams

Structure
Behavior Diagram
Diagram

Component Interaction Use Case

Class Diagram Object Diagram
Diagram Diagram Diagram

Composite Interaction
Deployment Sequence State Machine
Profile Diagram Structure Overview Activity Diagram
Diagram Diagram Diagram
Diagram Diagram

Communication
Pakage Diagram Timing Diagram
Diagram

1. Structure Diagrams
These diagrams emphasize the things that must be present in the
system being modeled. Since they represent the structure, they are
used extensively in documenting the software architecture of
software systems.
 Class Diagram
Class Diagram Describes the structure of a system by showing the
system’s classes, their attributes, and the relationships among the
classes.
2
 Component Diagram
Component diagram describes how a software system is split-up
into components and shows the dependencies among these
components.
 Composite Structure
Composite structure diagram describes the internal structure of a
class and the collaborations that this structure makes possible
 Deployment Diagram
Deployment Diagram Describes the hardware used in system
implementations and the execution environments and artifacts
deployed on the hardware.
 Object Diagram
Object diagram shows a complete or partial view of the structure of
an example modeled system at a specific time.
 Package Diagram Describes how a system is split-up into logical
groupings by showing the dependencies among these groupings.
 Profile Diagram
Profile diagram operates at the metamodel level to show stereotypes
as classes with the <<stereotype>>, and profiles as packages with the
<<profile>> stereotype. The extension relation (solid line with closed,
filled arrowhead) indicates what metamodel element a given
stereotype is extending
2. Behavior Diagrams
These diagrams emphasize what must happen in the system being
modeled. Since they illustrate the behavior of a system, they are
used extensively to describe the functionality of software systems.
 Activity Diagram
Activity diagrams describes the business and operational step-by-
step workflows of components in a system. An activity diagram
shows the overall flow of control.
 State Machine Diagram

3
 This diagram describes the states and state transitions of the
system.
 Use Case Diagram
It describes the functionality provided by a system in terms of
actors, their goals represented as use cases, and any dependencies
among those use cases.
 Interaction Diagrams
These diagrams are a subset of behavior diagrams, emphasizing the
flow of control and data among the things in the system being
modeled.
 Communication Diagram
This diagram shows the interactions between objects or parts
in terms of sequenced messages. They represent a
combination of information taken from Class, Sequence, and
Use Case Diagrams describing both the static structure and
dynamic behavior of a system.
 Interaction Overview Diagram
Interaction Overview Diagram Provides an overview in which
the nodes represent communication diagrams. They are
activity diagrams in which every node, instead of being an
activity, is a rectangular frame containing an interaction
diagram (i.e., a communication, interaction overview,
sequence, or UML timing diagram).
 Sequence Diagram
Sequence Diagram Shows how objects communicate with
each other in terms of a sequence of messages. Also indicates
the lifespans of objects relative to those messages.
 Timing Diagram
A specific type of interaction diagram where the focus is on
timing constraints. Timing diagrams model sequence of
events and their effects on states and property values. Time
flows along a horizontal axis from left to right. They can be
4
 used to show method execution profiling or concurrency
scenarios.
Use-Case Diagram
What is Use-Case Diagram?
A use case diagram is usually simple. It does not show the detail of the
use cases:
 It only summarizes some of the relationships between use cases,
actors, and systems.
 It does not show the order in which steps are performed to achieve
the goals of each use case.
As said, a use case diagram should be simple and contains only a few
shapes. If yours contain more than 20 use cases, you are probably
misusing use case diagram.
Purpose of Use Case Diagram
Use case diagrams are typically developed in the early stage of
development and people often apply use case modeling for the following
purposes:
 Specify the context of a system
 Capture the requirements of a system
 Validate a systems architecture
 Drive implementation and generate test cases
 Developed by analysts together with domain experts
Use Case Diagram at a Glance
A standard form of use case diagram is defined in the Unified Modeling
Language as shown in the Use Case Diagram example below:

5
Actor
Someone interacts with use case (system function).
For example:
A prof. can be instructor and also researcher
Use Case
System function (process - automated or manual)
Communication Link
The participation of an actor in a use case is shown by connecting an
actor to a use case by a solid link.
Boundary of system
The system boundary is potentially the entire system as defined in the
requirements document.
Use Case Diagram Tips
Now, check the tips below to see how to apply use case effectively in
your software project.

6
  Always structure and organize the use case diagram from the
perspective of actors.
 Use cases should start off simple and at the highest view possible.
Only then can they be refined and detailed further.
 Use case diagrams are based upon functionality and thus should
focus on the "what" and not the "how".

RATIONAL ROSE
What Does Rational Rose Mean?
Rational Rose is an object-oriented programming (OOP) and unified
modeling language (UML) tool to design enterprise-level software
applications and components. It creates visual software application
models under object-oriented principles. Example application models
include the creation of actors, use cases, relationships, objects, entities,
etc. Rational Rose uses classical UML concepts to graphically model
software applications. This facilitates documenting the environment,
requirements and overall design.

Applications of Rational Rose Software

Rational rose software is basically used to draw UML diagram. It is a
professional and widely used in industry. In academics rational rose
software helps in making the diagram during the design phase of
software development life cycle.
 Modeling can be useful at any point in the application
 In Software Development process during design phase.
 Initial Design Work (Requirement Analysis and Definition)
Features of Rational Rose Graphical User Interface
The main features of the Rational Rose Real Time user interface are as
follow:
1. The Standard Toolbar remains the same for all views and diagrams. It
contains standard Windows functions as well as those specific to
Rational Rose Real Time.
2. The Diagram Toolbox is used for adding elements to the model by
drawing them on a diagram. The toolbox elements change depending
7
 on the active diagram. For example, the Use-Case Diagram has a tool
for adding actors, but the Component Diagram does not have this
tool.
3. Browsers are hierarchical. When you start Rational Rose Real Time,
the Model View, the Containment View, and
the Inheritance View browsers are on the left side of the interface in a
stacked format. They can be set to visible/invisible, docked, or floating.
To activate a specific browser,
4. Select the appropriate tab located at the bottom of the interface. There
are two additional browsers, also referred to as editors that performs
specific tasks: the Structure/State Diagram Browser/Editor, and
the Run Time System (RTS) Browser/Editor.
5. Rational Rose Real Time offers four main views located on the Model
View browser. Each view is corresponds to a software life cycle phase,
and the diagrams are artifacts of those phases.

Software Reverse Engineering

Software Reverse Engineering is a process of recovering the design,

requirement specifications and functions of a product from an analysis of
its code. It builds a program database and generates information from
this.
The purpose of reverse engineering is to facilitate the maintenance work
by improving the understandability of a system and to produce the
necessary documents for a legacy system.

 Cope with Complexity.

 Recover lost information.
 Detect side effects.
 Synthesize higher abstraction.
 Facilitate Reuse.

8
Steps of Software Reverse Engineering:
1. Collection Information:
This step focuses on collecting all possible information (i.e., source
design documents etc.) about the software.
2. Examining the information:

9
 The information collected in step-1 as studied so as to get familiar
with the system.
3. Extracting the structure:
This step concerns with identification of program structure in the
form of structure chart where each node corresponds to some
routine.
4. Recording the functionality:
During this step processing details of each module of the structure,
charts are recorded using structured language like decision table, etc.
5. Recording data flow:
From the information extracted in step-3 and step-4, set of data
flow diagrams are derived to show the flow of data among the
processes.
6. Recording control flow:
High level control structure of the software is recorded.
7. Review extracted design:
Design document extracted is reviewed several times to ensure
consistency and correctness. It also ensures that the design
represents the program.
8. Generate documentation:
Finally, in this step, the complete documentation including SRS,
design document, history, overview, etc. are recorded for future use.
Reverse Engineering Tools:
Reverse engineering if done manually would consume lot of time and
human labour and hence must be supported by automated tools. Some
of tools are given below:
 CIAO and CIA: A graphical navigator for software and web
repositories along with a collection of Reverse Engineering tools.
 Rigi: A visual software understanding tool.
 Bunch: A software clustering/modularization tool.
 GEN++: An application generator to support development of analysis
tools for the C++ language.
 PBS: Software Bookshelf tools for extracting and visualizing the
architecture of programs.

10
11