object oriented methodologies

object oriented modelling and design MCA notes

1. OOMD Object Oriented Methodologies

2. Introduction A system of methods used in a particular area of study or activity Numbers of methodology are based on modeling the business problem and implementing the application in an object oriented fashion. The major differences between different methodologies lie primarily in the documentation of information, and modeling notations and language.

3. The three major methodologies and their modeling notations developed by Rumbaugh et al ., Booch and Jacobson which are the origins of the Unified Modeling Language. Each method has its strengths. Rambaugh method is well-suited for describing the object model or the static structure of the system. The Jacobson et al. method is good for producing user – driven analysis models. The Booch method produces detailed object–oriented design models.

4. Rambaugh et al. ’s Object Modeling Technique(OMT) OMT presented by Jim Rambaugh and his co workers describes a method for the analysis , design and implementation of a system using an object-oriented technique. OMT is a fast, intuitive approach for identifying and modeling all the objects making up a system. Details such as class, attributes, method, inheritance and association also can be expressed easily.

5. OMT consists of four phases , which can be performed iteratively. Analysis : The results are objects and dynamic and functional models System Design : The results are a structure of basic architecture of system along with high–level strategy decisions. Object Design : This phase produces a design document, consisting of detailed objects static, dynamic and functional models. Implementation : This activity produces reusable, extensible and robust code.

6. OMT separates modeling into three different parts . An object model , presented by the object model and the data dictionary. A dynamic model presented by the state diagrams and even flow diagrams. A functional model presented by data flow and constraints.

7. Object Model It describes the structure of objects in a system: Their identity , relationships to other objects, attributes and operations . It is represented graphically with an object diagram which contained classes interconnected by association lines. Each class contains a set of individual objects and association lines establish relationships among the class.

8. OMT Dynamic Model It provides a detailed and comprehensive dynamic model , in addition to letting us depict states , transitions , events and actions . The OMT state transition diagram is a network of states and events. Each state receives one or more events, at which time it makes the transition to the next state whereas the next state depends on current state as well as events.

9. OMT Functional Model OMT data flow diagram (DFD) shows the flow of data between difference processes in a business. It also provides a simple and intuitive method for describing business process without focusing on the details of the computer system. DFD uses 4 primary symbols 1. The process is any function being performed. 2. The data flow shows the direction of data element movement. 3. The data store is a location where data are stored 4. An external entity is a source or destination of a data element

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

12. State transition diagram for the bank application user interface. The round boxes represent states and the arrows represent transitions.

13. Booch Methodology It is a widely used object oriented method that helps us design our system using the object paradigm. It covers the analysis and design phases of an object oriented system. We start with class & object diagrams in analysis phase and refine these diagrams in various steps. The Booch method consists of the following diagrams : Class diagrams , Object diagrams, State Transition diagrams, Module diagrams Process diagrams, Interaction programs.

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

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

16. State transition diagrams state of a class based on a stimulus

17. Process diagrams to determine to which processor to allocate a process

18. Module diagrams to map out where each class & object should be declared

19. Interaction diagrams describes behavior of the system in terms of scenarios

20. Booch method prescribes: Macro Development Process Micro Development Process

21. The Macro Development process The macro process serves as a controlling framework for micro process & its main concern is technical management of system. It consists of following steps: Conceptualization : Core requirements, goal of system & Prototype to prove the concept. Analysis & development of model : Class, object & interaction diagrams for roles & responses Design/create sys., architecture : Schedules for multiple processes on each relevant processor Evolution or implementation : Refine through iterations and a stream of s/w implementations Maintenance : Make localized changes to system to add new requirements & eliminate bugs

22. Object modeling using Booch notation. The arrows represent specialization; for example, class Taurus is subclass of the class Ford.

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

24. The Micro Development process It is a description of the day–to–day activities by a single or small group of s/w developers which could look blurry to an outside viewer as analysis & design phases are not clearly defined. 1. Identify classes and objects 2. Identify class and object semantics. 3. Identify class & object relationships, 4. Identify class & object interfaces & implementation.

25. Jacobson et al. Methodology Use Cases. Object Oriented Software Engineering. Object Oriented Business Engineering.

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

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

28. OOSE Object Oriented Software Engineering. Objectory (Object Factory for S/w Development) 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.

29. The use-case model is considered in every model and phase.

30. OOBE Object Oriented Business Engineering OOBE is object modeling at the enterprise level. Analysis phase Object Model Requirement Analysis Design and Implementation phase DBMS Distribution of Process Testing phase Unit testing, integration and system testing.

31. The primary difference between OOBE and traditional business modeling and redesign approaches is that OOBE facilitates thinking about the business as though it were a series of modular components that can be reconfigured at-will as the business changes. OOBE encourages convergence of diverse thinking (through business patterns); while still very clearly capturing and respecting those differences that create profitable differentiation in the marketplace. OOBE harmonies information systems thinking with business thinking , driving systems from the business point of view, but not treating business and systems as incompatible. By providing a clean transition between business and systems thinking, OOBE makes possible the realization of a new breed of business operations where key processes, and even entire businesses, are implemented electronically

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

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

34. Patterns

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

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

37. Benefits of Frameworks Reusability Modularity Extensibility Inversion of Control

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

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

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

41. Model Model is an iterative process. It can represent static or dynamic situations. Model Static Dynamic Represents a system’s behaviors that, taken together, reflect its behavior over time. (e.g.) interaction & activity diagrams Provides a system’s parameters at rest or at a specific point in time. (e.g.) class diagram

42. Why modeling Blue print Clarity Familiarity Maintenance Simplification

43. Advantages of modeling Easy to express complex ideas Reduce complexity Enhance & reinforce learning and training Low cost Easy to change the model