3. Rumbaugh’s Object Modeling Technique (OMT)
-A method for analysis, design and implementation by
an object oriented technique.
-fast and intuitive approach for identifying and
modeling all objects making up a system.
-Class attributes, methods, inheritance and association can
be expressed easily.
-Dynamic behavior of objects can be described using
the OMT dynamic model.
-Detailed specification of state transitions and their
-descriptions within a system
4. Rumbaugh ET AL’s Object
Modeling Technique:
Four phases of OMT (can be performed iteratively)
Analysis: objects,dynamic and functional models
System Design: Basic architecture of the system.
Object Design: static, dynamic and functional models
of objects.
Implementation: reusable, extendible and robust
code.
5. Three different parts of OMT modeling
An object model - object model & data
dictionary
A dynamic model - state diagrams & event
flow diagrams
A functional model - data flow &
constraints
6. Object Model
structure of objects in a system.
Identity, relationships to other objects,
attributes and operations.
Object diagram
7. The OMT object model of a bank system. The boxes represent
classes and the filled triangle represents specialization.
Association between Account and Transaction is one to many;
since one account can have many transactions, the filled circle
represents many (zero or more). The relationship between Client
and Account classes is one to one: A client can have only one
account and account can belong to only one person (in this model
joint accounts are not allowed).
8. Object Diagram
Classes interconnected by association
lines
Classes- a set of individual objects
Association lines- relationship among
classes (i.e., objects of one class to
objects of another class)
9. OMT Dynamic Model
States, transitions, events and actions
OMT state transition diagram-network
of states and events
10. State transition diagram for the bank application user
interface. The round boxes represent states and the
arrows represent transitions.
13. OMT Functional Model
DFD- (Data Flow Diagram)
Shows flow of data between different
processes in a business.
Simple and intuitive method for describing
business processes without focusing on the
details of computer systems.
14. Data Flow Diagram
Four primary symbols
Process- any function being performed
Data Flow- Direction of data element movement
Data Store – Location where data is stored
External Entity-Source or Destination
of a data element
15.
16. The Booch Methodology
Widely used OO method
Uses the object paradigm
Covers the design and analysis phase of
an OO system
Criticized for his large set of symbols
17. Diagrams of Booch method
Class diagrams-
describe roles and responsibilities of objects
Object diagrams
describe the desired behavior of the system in terms
of scenarios
State transition diagrams
state of a class based on a stimulus
Module diagrams
to map out where each class & object should be
declared
Process diagrams
to determine to which processor to allocate a process
Interaction diagrams
describes behavior of the system in terms of scenarios
18. Diagrams of Booch method
Class diagrams
describe roles and
responsibilities of
objects
Object diagrams
describe the desired
behavior of the system in
terms of scenarios
24. Macro Development Process
Controlling framework for the micro
process.
Primary concern-technical management
of the system.
25. Steps for macro development
process
1. Conceptualization
2. Analysis & Development of the model
3. Design or create the system architecture
4. Evolution or implementation
5. Maintenance
26. Object modeling using Booch notation. The arrows
represent specialization; for example, class Taurus is
subclass of the class Ford.
27. An alarm class state transition diagram with Booch
notation. This diagram can capture the state of a class
based on a stimulus. For example, a stimulus causes the
class to perform some processing, followed by a
transition to another state. In this case, the alarm
silenced state can be changed to alarm sounding state
and vice versa.
28. Micro Development Process
Each macro process has its own micro
development process
Steps:
- Identify classes & objects
- Identify class & objects semantics
- Identify class & object relationship
- Identify class & objects interface and
implementation
29. JACOBSON METHODOLOGIES
Use Cases.
Object Oriented Software Engineering.
Object Oriented Business Engineering.
30. Use Cases
Understanding system requirements
Interaction between Users and Systems
The use case description must contain
How and when the use case begins and ends.
The Interaction between the use case and its actors,
including when the interaction occurs and what is
exchanged.
How and when the use case will need data stored in the
system.
Exception to the flow of events
How and when concepts of the problem domain are
handled.
31. Some uses of a library. As you can see, these are external
views of the library system from the actor such as a
member. The simpler the use case, the more effective it
will be. It is unwise to capture all of the details right at
the start; you can do that later.
32. OOSE
Object Oriented Software Engineering.
Objectory is built around several
different models:
Use case model. The use-case model defines the outside
(actors) and inside (use case) of the systems behavior.
Domain object model. The objects of the “real” world are
mapped into the domain object model.
Analysis object model. The analysis object model presents
how the source code (implementation) should be carried out
and written.
Implementation model. The implementation model
represents the implementation of the system.
Test model. The test model constitutes the test plans,
specifications, and reports.
34. OOBE
Object Oriented Business Engineering
OOBE is object modeling at the
enterprise level.
Analysis phase
Design and Implementation phase
Testing phase
E.g. Unit testing, integration and system
testing.
35. PATTERNS
It is an instructive information that
captures the essential structure and
insight of a successful family of proven
solutions to a recurring problem that
arises within a certain context and
system of forces.
36. Good Pattern will do the
following
It solves a problem.
It is a proven concept.
The Solution is not obvious.
It describes a relationship.
The pattern has a significant human
component.
37. Patterns
Patterns
Generative Patterns Non Generative Patterns
(describe recurring phenomena (describe recurring phenomena
with saying how to without saying how to
reproduce them) reproduce them)
38. Patterns Template
Essential Components should be clearly recognizable
on reading a pattern:
Name
Problem
Context
Forces
Solution
Examples
Resulting context
Rationale
Related Patterns
Known uses
39. Frameworks
Way of delivering application
development patterns to support best
practice sharing during application
development.
Can be viewed as the implementation
of a system of design patterns.
41. Difference between Patterns and
Frameworks
Design patterns are more abstract than
frameworks.
Design patterns are smaller
architectural elements than
frameworks.
Design patterns are less specialized
than frameworks.
42. Model
An abstract representation of a
system.
Types of model
1. Use case model
2. Domain model
3. Analysis object model
4. Implementation model
5. Test model
43. Model
Types of model
1. Use case model defines the outside (actors)
& inside (use case) of the system’s behavior.
2. Domain model maps real world object into
the domain object model.
3. Analysis object model how source code
should be carried out & written.
4. Implementation model represents the
implementation of the system.
5. Test model test plans, specifications &
reports.
44. Model
Model is an iterative process.
It can represent static or dynamic
situations.
Model
Static Dynamic
Provides a system’s Represents a system’s behaviors
parameters at rest or at a that, taken together, reflect its
specific point in time. behavior over time.
(e.g.) class diagram (e.g.) interaction & activity diagrams
46. Advantages of modeling
Easy to express complex ideas
Reduce complexity
Enhance & reinforce learning and
training
Low cost
Easy to change the model
47. What is Unified Modeling
Language (UML)?
The UML is a graphical / standard
language for visualizing,
specifying, constructing &
documenting the artifacts of a
software system.
48. History of UML
1980 – 1990 Many different
methodologies
1. Booch method by Grady Booch
2. Object Modeling Technique (OMT) by Jim Rumbaugh
3. Object Oriented Software Engineering (OOSE) by Ivar
Jacobson
Each method had its strengths &
weaknesses.
1. Booch was great in design
2. OMT & OOSE were great in analysis
49. History of UML 1997)
UML 1.0 (January
UML 1.1 (November 1997)
UML 1.3 (Current Minor revision 1999)
UML 1.4 (Planned Minor revision 2000)
UML 2.0 (Planned Major revision 2004)
50. UML Concepts
UML can be used to support your
entire life cycle.
1. The interaction of your application with the outside
world (use case diagram)
2. Visualize object interaction (sequence &
collaboration diagrams)
3. The structure of your system (class diagram)
4. View the system architecture by looking at the
defined package.
5. The components in your system (component
diagram)
51. What are Diagrams ?
Graphical presentation of model
elements.
A diagram is a graphical means to view
a system’s parts
52. UML Diagrams
8 diagrams
You will model the following 5 diagrams only:
1. Use case diagram
2. Activity diagram
3. Sequence diagram Interaction
4. Collaboration diagram diagram
5. Class diagram
The other UML diagrams that can be modeled in
Rose are:
1. State chart diagram
2. Component diagram
3. Deployment diagram
54. UML Diagrams
1. Class diagram
2. Use case diagram
3. Activity diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Component diagram
8. Deployment diagram
55. 1. Class diagram
Class a set of objects that share the
same attributes, operations & relationships.
It represented by a compartmentalized
rectangle.
It shows the structure of your software.
3 compartments
1. Top
2. Middle
3. Bottom
56. 1. Class diagram
1. Top shows class name
2. Middle shows class attributes
3. Bottom shows class operation
57. 1. Class diagram
1. Attributes defines the characteristics or
structure of a class.
displayed in the middle of the
compartmentalized rectangle.
Attributes
58. 1. Class diagram
2. Operation the service provided by the class.
displayed in the bottom of the
compartmentalized rectangle.
Operations
59. 2.Use case diagram
It shows a set of use cases and actors and
their relationships.
Address the static view of a system.
Actor user (or) someone / something
outside the system that interacts with the
system (it must be a noun) & it is
represented by a stickman.
……contd
60. 2.Use case diagram
Use case a sequences of actions (it must be
a verb) & it is represented by an oval.
Relationship illustrates a connection among
model elements.
Unidirectional Bi-directional
It is created to visualize the interaction of your
system with the outside world.
(e.g.) ATM
……contd
61. 2. Use case diagram (ATM)
WITHDRAW
CASH
CUSTOMER DISPENSER
CHECK BALANCE
PRINTER
CHANGE PIN
LOGIN
62. 2. Use case diagram (Pay roll)
Actors employee & account
Use case count leave, disburse
salary, check loans, calculate PF,
prepare IT returns, calculate HRA &
check salary
63. Count leave
Customer
Disburse salary
Check loans
Calculate HRA
Calculate PF
Check salary
Prepare IT returns
64. 3.Activity Diagram
It shows the flow of events with our
system & what is going on inside a use
case.
We draw the activity diagram for each
& every use case.
Login (use case) – (e.g.) ATM
It is showing flow of control from
activity to activity.
65. 3.Activity Diagram
Activity it represents the performance of a
task within the workflow.
Activity is represented by a lozenge
(horizontal top and bottom with convex sides)
Start state shows the beginning of a workflow
on an activity diagram.
There is only one start state.
66. 3.Activity Diagram
A start state is represented by a solid
circle.
An end state represents a final or
terminal state on an activity diagram.
A end state is represented by a bull’s
eye.
67. 3.Activity Diagram
A state transition shows what activity
follows after another.
It is represented by a solid line with an
arrow.
68. 3.Activity Diagram
A decision is a point in an activity diagram
where guard conditions are used to indicate
different possible transitions.
It is represented by a diamond.
Guard conditions control the transition of a
set of alternate transitions that follows after
the activity has been completed.
70. 3.Activity Diagram
A synchronization bar allows you to
show concurrent threads in a work flow
of a use case.
It represented by a thick horizontal or
vertical line.
71. 3.Activity Diagram
A swimlane is used to partition an
activity diagram to help us better
understand who or what is initiating an
activity.
72. 3.Activity Diagram – Login Use case
Cus tom er Enters
the login details
Sys tem retrives
the details
Sys tem validates
the cus tom er
[ Fals e ]
Sys tem prompts to
reenter
[ True ]
Sys tem welcomes
the cus tom er
73. 4.Sequence Diagram
It shows step by step what must happen
to accomplish a piece of functionality
provided by the system.
It has 2Ds.
1. Vertical dimensions represents time
2. Horizontal dimensions represents
different objects.
Vertical line is called the object’s life line.
74. 4.Sequence Diagram
Life line the existence object at a
particular time.
Objects are shown at the top.
The object role is shown as a vertical
dashed line, the life line.
75. 4.Sequence Diagram
A message is the communication between 2
objects that triggers an event.
It is represented by a labeled arrow.
Each message is represented by an arrow
between the life lines of 2 objects.
76. 4.Sequence Diagram
A focus of control shows the period of
time during which an object is
performing an action, either directly or
through a subordinate procedure.
It represented by a tall, thin rectangle.
78. 5.Collaboration Diagram
It displays objects and their links to one
other.
It is also known as an interaction diagram.
79. 5.Collaboration Diagram
It is made up of the following basic
elements :
1. Actors
2. Objects
3. Links
4. Messages
80. 5.Collaboration Diagram
1. Actors user
2. Objects
data + logic / the representation
of some real world entity.
3. Links a pathway for communication
between objects.
represented by a solid line
between 2 objects
4. Messages the communication between
objects that triggers an event.
represented by a labeled arrow
above
the link.
81. 5.Collaboration Diagram –
Login use case
1: Enter Login Details ( )
2: Subm it( )
: LoginForm
: Cus tom er
3: Validate( )
4: getLoginDetails ( )
: LoginController
: Cus tom erInfo
82. 6. State Chart Diagram
It shows the sequence of states.
A state is represented as a rounded box,
which may contain one or more
compartments.
Name compartment holds the name of
the state.
Internal transition compartment list of
actions / activities
Start & end states
83. 7.Component Diagram
It shows relationship between the
components in the system.
A component may be a software
component [for (e.g.) a.h file in C++
(or) a .java file in Java], a run time
component [for (e.g.) a.DLL file]
84. 8. Deployment Diagram
It shows the configuration of run time
processing elements & the software
components, processes & objects that
live in them.
It shows the nodes in the system & the
connections between them.
85. Review
Name the 2 benefits of visual modeling.
What is UML?
Name three UML diagrams.
What are the elements of a use-case
diagram?
Define a use case.
Define an actor.
What is meant by a relationship?
86. Module Summary
Visual modeling
1. The interaction of your application with the outside
world (use case diagram)
2. Visualize object interaction (sequence &
collaboration diagrams)
3. The structure of your system (class diagram)
4. View the system architecture by looking at the
defined package.
5. The components in your system (component
diagram)
87. Module Summary
UML
The UML is a graphical / standard
language for visualizing, specifying,
constructing & documenting the
artifacts of a software system.
88. Module Summary
You can model the following 8 UML
diagrams in Rational Rose.
1. Use case diagram
2. Activity diagram
3. Sequence diagram
4. Collaboration diagram
5. Class diagram
6. State chart diagram
7. Component diagram
8. Deployment diagram
89. Views and Diagrams in Rational Rose
What is model?
A model is a simplification of reality or the blueprint of
the system.
What is view?
A view is a perspective of the model (ie)
meaningful to specific stakeholders.
90. Views
Logical View Implementation View
(Analyst / Designer) (Programmers)
Structure Software Management
Use case view (end
user functionality
Process View Deployment View
(System integrators) (System Engineering)
Performance, scalability System topology, Delivery,
& throughput installation & Communication
91. Views
In Rose, you can create the following views
1. Use-case view
2. Logical view
3. Process view
4. Component view (Implementation view)
5. Deployment view
These views together create what we call the
4+1 Architectural View
92. Use Case View
It specifies WHAT the system should do?
Servers as a contract between customer and
developer.
Essential to analysis, design and test
activities.
93. Logical View
It supports the functional requirements
of the system.
It includes use-case realizations, class
and interaction diagrams.
It can also include state chart and
activity diagrams.
94. Process View
Addresses the performance, scalability and
throughput of the system.
Is not necessary for a single Processing
environment.
96. Deployment View
Addresses issues like deployment,
installation and performance.
.Used for distributed system only.
97. Rational Rose Interface
It includes the following :
Browser
Diagram window
Diagram toolbar
Documentation window
Log window
Options window
The options window is not technically part of the
rose interface. However, it is important in your
initial setup.
98. The Browser
The browser allow you to textually
view and navigate the views and
diagrams in rational rose.
Display the elements that you have
modeled. if an element doesn’t
appear in the browser, it not a part of
your modeled system.
99. Diagram window
The diagram window allows you to
create and update graphical views of
the current model.
100. Diagram Toolbar
The diagram toolbar includes
the elements to build a
diagram.
Each diagrams toolbar unique
to that diagram.
It is active only when the
diagram is displayed.
101. Documentation window
Used to create, view or modify text that
explains a selected item within a
diagram.
102. Log window
Reports progress, result and errors.
For (e.g.) code generation commands post
progress and error messages to this window.
To display log window, go to View menu,
click LOG to show or hide the window.
To clear the contents of log window, click
CLEAR LOG.
103. Options window
Used to set all of your default for
modeling.
Note that if you change default, existing
model elements are not changed.
104. Basic tool techniques
There are two basic tool techniques
we will discuss before you begin the
labs. They are
1. Deleting diagram elements
2. Adding diagram elements
105. Deleting diagram elements
What happens when you delete an
element from the browser? Rose does the
following.
Removes the selected elements from the
model
Removes all icons representing the
elements from all diagrams on which they
appear.
Delete the specification for the element .
106. Deleting Diagram Elements
There are three ways to delete an element.
1. Click the element in the diagram and then
press ctrl-D
2. Right click the element in browser, and then
click delete
3. Click the element in the browser or
diagram. From the edit menu, click delete
from model.
107. Adding diagram elements
How do you add diagram elements?
You add elements to a diagram from either
the diagram tool bar or browser.
108. Review
What are views?
Name a view in rose and discuss its
purpose.
Name two feature of the rose interface
Discuss deleting from the browser
versus the diagram.
109. Module Summary
Rational Rose uses views & diagrams to
depict varying perspectives and a system’s
parts.
There are 5 views in Rational Rose :
1. Use case view
2. Logical view
3. Process view
4. Component / implementation view
5. Deployment view
110. Module Summary
Diagrams are a graphical means to view a
system’s parts.
The browser shows all of your model
elements
Diagram window is to create a view
Diagram toolbar includes the elements to
build a diagram.
Documentation window is used to create,
view or modify text that explains a selected
item within a diagram.
111. Module Summary
Log window reports progress, results &
errors.
Option window allows you to set your
defaults.
Deleting diagram elements ctrl D, DEL key
(or) go to edit menu, click DELETE FROM
MODEL.
Adding diagram elements click the element
& then click in the diagram window.