Object-Oriented Methodologies: Rumbaugh, Booch, and Jacobson

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 - Jacobson’s methodologies Patterns Frameworks

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. 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 system’s 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 Provides a system’s parameters at rest or at a specific point in time. (e.g.) class diagram Represents a system’s behaviors that, taken together, reflect its behavior over time. (e.g.) interaction & activity diagrams

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 system’s 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 • Class diagram • Use case diagram • Activity diagram • Sequence diagram • Collaboration diagram • State chart diagram • Component diagram • 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. UnidirectionalBi-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. Count leave Customer Disburse salary Check loans Calculate HRA Calculate PF Check salary Prepare IT returns

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.