Object-Oriented Development

1. Object-Oriented Development By Grady Booch

2. Abstract • Object-oriented development is a partial-lifecycle software development method which the decomposition of a system is based on the concept of an object • This method is fundamentally different than Traditional functional approaches to design

3. Abstract continues… • Serves to help manage the complexity of massive software-intensive systems

4. Introduction • Object-oriented programming is what structured programming was in 1970’s • Object-oriented approach to software design in which the decomposition of a system is based upon the concept on an object

5. An object is an entity whose behavior is characterized by the action that it suffers and that requires of other objects Object oriented development is different than traditional functional methods Continued…

6. Functional method • Fortran, Cobol, Pascal • Each module represents a major step in the overall process • Tend to consist of collections of programs, because they are the only building blocks available

7. Continued… • Subroutines are not well suited to the description of abstract objects. This is a serious drawback

8. Object-oriented method • Ada and Smalltalk • subprogram as an elementary building block • In Ada, Package and task are major elements • Package is used to create new objects and classes of objects

9. Continued… • Task express concurrent objects and activities in a natural way • Package and subprograms help to better build abstraction of the problem space by permitting a more balanced treatment between nouns and verbs

10. Nouns and Verbs • Nouns are objects • Verbs are operations

11. functional method Limitations • Do not effectively address data abstraction and information hiding • Generally inadequate for problem domains with natural concurrency • Often not responsive to changes in the problem space • OO approach mitigate these problems

12. A cruise control design • Inputs to the system • System on/off • If on, cruise control maintains the speed • Engine on/off • Cruise control only active if engine is on • Pulse from wheel • One pulse for every revolution • Accelerator • How far it has been pressed

13. Continued… • Brake • when pressed, cruise control is turned off • Increase/Decrease Speed • If only the cruise control system is on • Resume • Resume the last maintained speed • Clock • Timing pulse every millisecond

14. Continued… • Output from the system • Throttle • Digital value for the engine throttle setting

15. Cruise Control Hardware Block Diagram System on/off Engine on/off Pulse from Wheel Cruise- Control System Accelerator Throttle Brake Increase/decrease speed Resume speed Clock

16. Pulse Wheel Calculate Current Speed Current speed Current speed Clock tick Clock On/Off Calculate Desired Speed Driver Desired speed Desired speed Incr/Decr Resume Set Brake State Brake State Brake Brake State On/Off Brake State On/Off Engine Calculate Throttle Setting Desired speed Value Current Speed Throttle Setting Accel Throttle Throttle Setting

17. Cruise Control System Get Desired Speed Get Current Speed Get Brake State Calculate Throttle Setting Put Throttle Value Functional Decomposition

18. Wheel Clock Driver Current Speed Brake Desired Speed Engine Throttle Object Oriented Decomposition Accelerator

19. Object-Oriented Development • Major steps in Object-oriented development • Identify the objects and their attributes • Identify the operations suffered by and required of each object • Establish the visibility of each object in relation to other objects • Establish the interface of each object • Implement each object

20. Identify the objects and their attributes • Recognition of major actors, agents, and servers in the problem space plus their role in our model of reality • The objects identify is this step derive from the nouns used in describing the problem space • Establish classes of objects for similar objects

21. Identify the operations suffered by and required of each object • Serves to characterize the behavior of each object or class of objects • Establish the static semantics of the object by determining the operations that may be meaningfully performed on the object of objects • Establish the dynamic behavior of object by identifying the constraints upon time or space that must be observed

22. Establish the visibility of each object in relation to other objects • We identify the static dependencies among objects and classes of objects • In other words, what objects see and are seen by a given objects • The purpose of this step is to capture the topology of objects from our model of reality

23. Establish the interface of each object • Produce a module specification, using some suitable notation (Ada, Smalltalk, etc, …) • This captures the static semantics of each object or class of objects that we established in previous step • This specification serves as a contract between the clients of an object and the object itself • In other words, the interface forms the boundary between the outside view and the inside view of an object

24. Implement each object • Involves choosing a suitable representation for each object or class of objects • Implementing the interface from previous step • Involves decomposition or composition if an object is found to consist of several objects • In this case we repeat our method to further decompose the object

25. Useful points • Object-oriented development is a partial-lifecycle method • It focuses upon the design and implementation stages of software development • It is necessary to couple object-oriented development with appropriate requirements and analysis methods in order to help create or model of reality

26. Major Goals in developing object Based software • To reduce the total life-cycle software cost by increasing programmer productivity and reducing maintenance cost • Implement software system that resist both accidental and malicious corruption attempts

27. Properties of an Object • Object is an entity that • Has state • Is characterized by the actions that it suffers and that it requires of other objects • Is an instance of some class • Is denoted by a name • Has restricted visibility of and by other objects • May be viewed either by its specification or by its implementation

28. Object Classification • Actor • Suffers no operation but only operates upon other objects • Agent • Serves to perform some operation on behalf of another object and in turn may operate upon another object • Server • Suffers operation and may not operate upon other objects

29. Class • An object is a unique instance of some class • A class denotes a set of similar but unique objects • Class serves to factor the common properties of a set of objects and specify the behavior of all instances

30. Inheritance • Permits a hierarchy of classes • All objects are an instance of a class, which is a subclass of another class (and so on) • Subclass has the same operations defined by the superclass • May also add operation, modify existing operation, and hide operation from the superclass

31. Two views to each Objects • Outside View • Serves to capture the abstract behavior of the object • An object can interact with other objects by just knowing its outside view • Implementation does not need to be present for interaction with the object • Inside View • Indicates how the behavior is implemented and it is hidden form other objects

32. Ada and Object-Oriented Development • Classes of objects are denoted by packages that export private or limited private types • Objects are denoted by instances of private or limited private types or as packages that serve as abstract state machined • Objects state resides either with a declared object or in the body of a package

33. Continued … • Operations are implemented as subprograms exported from a package specification; generic formal subprogram parameters serve to specify the operations required by an object • Visibility is statistically defined through unit context clauses • Separate compilation of package specification and body support the tow views of an object • Tasks and task types may be used to denote actor objects and classes of objects

34. Name_X Name_Y Name_B Object Object Name_A Package Type Object Operation Names, Objects and Classes Interaction of the points in the previous slide Operation

35. Symbols of OOD Generic Subprogram Task Subsystem Subprogram Generic Package Package Object

36. These symbols can be connected by a direct line • A line connects object A to B, this denotes object A depends on object B

37. Design Case Study • A collection of free-floating Buoys • Buoys collect air and water temperature • Collect wind speed • Collect location data through variety of sensors • Each equipped with a radio transmitter to broadcast weather and location in formation as well as an SOS message • Each equipped with a radio receiver to receive requests from passing vessels

38. Some equipped with a red light, which may be activated by vessel during a sea-search operations • If a sailor is able to reach the buoy, he or she may flip a switch on the side to initiate an SOS broadcast

39. Buoys

40. Software Requirements • Maintain current current wind temperature, and location in formation; wind speed readings are taken every 30 seconds; temperature readings every 10 seconds and location every 10 seconds; wind and temperature; wind and temperature values kept as a running average • Broadcast current wind, temperature and location information every 60 seconds

41. Broadcast wind, temperature, and location information from the past 24 hours in response to requests from passing vessels • Activate or deactivate the red light based on a request from a passing vessel • Continuously broadcast an SOS signal after a sailor engages the emergency switch; this takes priority over all other broadcast and continues until reset by a passing vessel

42. Pulse Clock Wind Speed Sensor Air Temp Sensor Water Temp Sensor Location Sensor Value Value Value Value Calculate Average Calculate Average Calculate Average Calculate Location Pulse Avg. value Avg. value value Avg. value Sensor Data Bases Radio Receiver Request Broadcast Message Wind/Location Data Radio Transmitter SOS Message State Set Light State SOS Request Emergency Switch State Red Light Host at see Buoy data flow diagram

43. Objects • Clock • Provides the stimulus for periodic actions • Wind Speed sensor • Maintains a running average of wind speed • Air Temperature Sensor • Maintains a running average of air temperature • Water Temperature Sensor • Maintains a running avg. of water temperature • Location Sensor • Maintains the current buoy location • Sensor Database • Serves to store weather and location history

44. Radio Receiver • Provides a channel for requests from passing vessels • Radio Transmitter • Provides a channel for broad cast of weather and location reports as well as SOS messages • Emergency Switch • Provides the stimulus for the SOS signal • Red Light • Controls the activity of the emergency light • Message Switch • Serves to generate and arbitrate various broadcast messages

45. Clock Air Temp Sensor Wind Speed Sensor Water Temp Sensor Location Sensor Sensor Data Base Radio Receiver Radio Transmitter Message Switch Red Light Host at see buoy objects Emergency Switch

46. Operations Suffered by an Object • Clock • None • Wind Speed Sensors • Take Sample • Air Temperature Sensors • Take Sample • Water Temperature Sensors • Take Sample • Location Sensor • Take Sample

47. Sensor Database • Put value • Get value • Radio Receiver • None • Radio Transmitter • Broadcast SOS • Broadcast Weather/Location report

48. Emergency Switch • None • Red Light • Set State • Message Switch • Request History Report • Request SOS

49. Operations Required from an Object • Clock • Force Sample • Force Periodic Report • Wind Speed Sensors • Put Value • Air Temperature Sensors • Put Value • Water Temperature Sensors • Put Value • Location Sensor • Put Value

50. Sensor Database • None • Radio Receiver • Force History Report • Set Light State • Radio Transmitter • None