Rumbaugh Methodology

1
Unit-2

• Rumbaugh Methodology
• Booch Methodology
• Jacobson Methodology
• Patterns
• Frameworks
• Unified Approach
• Unified Modeling Language
• Use case
• class diagram
• Interactive Diagram
• Collaboration Diagram
• State Diagram
• Activity Diagram.

2
Chapter Objectives
You should be able to define and
understand Object Oriented methodologies. -
The Rumbaugh OMT - The Booch methodology -
Jacobsons methodologies Patterns Frameworks
3
Rumbaughs 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
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
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)

8
OMT Dynamic Model

• States, transitions, events and actions
• OMT state transition diagram-network of states
  and events

9
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.

10
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
11
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

12
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

13
Booch method prescribes

• Macro Development Process
• Micro Development Process

14
Macro Development Process

• Controlling framework for the micro process.
• Primary concern-technical management of the
  system.

15
Steps for macro development process

• Conceptualization
• Analysis Development of the model
• Design or create the system architecture
• Evolution or implementation
• Maintenance

16
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

17
JACOBSON METHODOLOGIES

• Use Cases.
• Object Oriented Software Engineering.
• Object Oriented Business Engineering.

18
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.

19
OOSE

• Object Oriented Software Engineering.
• Objectory is built models
• Use case model
• Domain object model
• Analysis object model
• Implementation model
• Test model

20
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.

21
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.

22
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.

23
Patterns
24
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

25
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.

26
Benefits of Frameworks

• Reusability
• Modularity
• Extensibility
• Inversion of Control

27
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.

28
Model

• An abstract representation of a system.
• Types of model
• Use case model
• Domain model
• Analysis object model
• Implementation model
• Test model

29
Model

• Types of model
• Use case model ? defines the outside (actors)
  inside (use case) of the systems behavior.
• Domain model ? maps real world object into the
  domain object model.
• Analysis object model ? how source code should be
  carried out written.
• Implementation model ?represents the
  implementation of the system.
• Test model ? test plans, specifications reports.

30
Model

• Model is an iterative process.
• It can represent static or dynamic situations.
• Model

Dynamic
Static
Represents a systems behaviors that, taken
together, reflect its behavior over time. (e.g.)
interaction activity diagrams
Provides a systems parameters at rest or at a
specific point in time. (e.g.) class diagram
31
Why modeling

• Blue print
• Clarity
• Familiarity
• Maintenance
• Simplification

32
Advantages of modeling

• Easy to express complex ideas
• Reduce complexity
• Enhance reinforce learning and training
• Low cost
• Easy to change the model

33
What is Unified Modeling Language (UML)?

• The UML is a graphical / standard language for
  visualizing, specifying, constructing
  documenting the artifacts of a software system.

34
History of UML

• 1980 1990 ? Many different methodologies
• Booch method by Grady Booch
• Object Modeling Technique (OMT) by Jim Rumbaugh
• Object Oriented Software Engineering (OOSE) by
  Ivar Jacobson
• Each method had its strengths weaknesses.
• Booch was great in design
• OMT OOSE were great in analysis

35
History of UML
UML 1.0 (January 1997)
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)
36
UML Concepts

• UML can be used to support your entire life
  cycle.
• The interaction of your application with the
  outside world (use case diagram)
• Visualize object interaction (sequence
  collaboration diagrams)
• The structure of your system (class diagram)
• View the system architecture by looking at the
  defined package.
• The components in your system (component diagram)

37
What are Diagrams ?

• Graphical presentation of model elements.
• A diagram is a graphical means to view a systems
  parts

38
UML Diagrams

• 8 diagrams
• You will model the following 5 diagrams only
• Use case diagram
• Activity diagram
• Sequence diagram
• Collaboration diagram
• Class diagram
• The other UML diagrams that can be modeled in
  Rose are
• State chart diagram
• Component diagram
• Deployment diagram

Interaction diagram
39
Behavior Diagram
Interaction diagram

• Sequence diagram
• Collaboration diagram
• State chart diagram
• Activity diagram

behavior diagram
40
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

41
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
• Top
• Middle
• Bottom

42
1. Class diagram

• Top ? shows class name
• Middle ? shows class attributes
• Bottom ? shows class operation

43
1. Class diagram

• Attributes ? defines the characteristics or
• structure of a class.
• ? displayed in the middle of the
• compartmentalized
  rectangle.

Attributes
44
1. Class diagram

• 2. Operation ? the service provided by the class.
• ? displayed in the bottom of the
• compartmentalized
  rectangle.

Operations
45
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

46
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

47
2. Use case diagram (ATM)
48
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

49
(No Transcript)
50
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.

51
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.

52
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 bulls eye.

53
3.Activity Diagram

• A state transition shows what activity follows
  after another.
• It is represented by a solid line with an arrow.

54
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.

55
3.Activity Diagram
AND
Synchronization bar
Joint
56
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.

57
3.Activity Diagram

• A swimlane is used to partition an activity
  diagram to help us better understand who or what
  is initiating an activity.

58
3.Activity Diagram Login Use case
59
4.Sequence Diagram

• It shows step by step what must happen to
  accomplish a piece of functionality provided by
  the system.
• It has 2Ds.
• Vertical dimensions ? represents time
• Horizontal dimensions ? represents different
  objects.
• Vertical line is called the objects life line.

60
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.

61
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.

62
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.

63
4.Sequence Diagram login success
64
5.Collaboration Diagram

• It displays objects and their links to one other.
• It is also known as an interaction diagram.

65
5.Collaboration Diagram

• It is made up of the following basic elements
• Actors
• Objects
• Links
• Messages

66
5.Collaboration Diagram

• Actors ? user
• 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.

67
5.Collaboration Diagram Login use case
68
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

69
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

70
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.

71
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?

72
Module Summary

• Visual modeling
• The interaction of your application with the
  outside world (use case diagram)
• Visualize object interaction (sequence
  collaboration diagrams)
• The structure of your system (class diagram)
• View the system architecture by looking at the
  defined package.
• The components in your system (component diagram)

73
Module Summary

• UML
• The UML is a graphical / standard language for
  visualizing, specifying, constructing
  documenting the artifacts of a software system.

74
Module Summary

• You can model the following 8 UML diagrams in
  Rational Rose.
• Use case diagram
• Activity diagram
• Sequence diagram
• Collaboration diagram
• Class diagram
• State chart diagram
• Component diagram
• Deployment diagram

75
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.

76
Views

• Logical View Implementation View
• (Analyst / Designer) (Programmers)
• Structure Software Management
• Process View Deployment View
• (System integrators) (System
  Engineering)
• Performance, scalability System
  topology, Delivery,
• throughput installation
  Communication

Use case view (end user functionality
77
Views

• In Rose, you can create the following views
• Use-case view
• Logical view
• Process view
• Component view (Implementation view)
• Deployment view
• These views together create what we call the
  41 Architectural View

78
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.

79
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.

80
Process View

• Addresses the performance, scalability and
  throughput of the system.
• Is not necessary for a single Processing
  environment.

81
Component / Implementation View

• Addresses issues of ease of development,
  management of software assets, reuse etc.

82
Deployment View

• Addresses issues like deployment, installation
  and performance.
• .Used for distributed system only.

83
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.

84
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 doesnt appear in the browser, it not a
  part of your modeled system.

85
Diagram window

• The diagram window allows you to create and
  update graphical views of the current model.

86
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.

87
Documentation window

• Used to create, view or modify text that explains
  a selected item within a diagram.

88
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.

89
Options window

• Used to set all of your default for modeling.
• Note that if you change default, existing model
  elements are not changed.

90
Basic tool techniques

• There are two basic tool techniques we will
  discuss before you begin the labs. They are
• Deleting diagram elements
• Adding diagram elements

91
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 .

92
Deleting Diagram Elements

• There are three ways to delete an element.
• Click the element in the diagram and then press
  ctrl-D
• Right click the element in browser, and then
  click delete
• Click the element in the browser or diagram. From
  the edit menu, click delete from model.

93
Adding diagram elements

• How do you add diagram elements?
• You add elements to a diagram from either the
  diagram tool bar or browser.

94
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.

95
Module Summary

• Rational Rose uses views diagrams to depict
  varying perspectives and a systems parts.
• There are 5 views in Rational Rose
• Use case view
• Logical view
• Process view
• Component / implementation view
• Deployment view

96
Module Summary

• Diagrams are a graphical means to view a systems
  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.

97
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.

98
Thank You!