1 - OOP
Download as PPT, PDF5 likes1,847 views
This document discusses object-oriented programming and modeling. It introduces key concepts like objects, classes, inheritance, and how they help address the inherent complexity in software as it evolves over time. Objects encapsulate both data and behavior, and classes define common properties and behaviors for groups of objects. Inheritance allows classes to share and specialize behaviors through subclass hierarchies. Together, these concepts provide abstraction and reuse capabilities that help manage complexity in software systems.
![S.Ducasse 4
Continuous Development
17.4% Corrective
(fixing reported errors)
18.2% Adaptive
(new platforms or OS)
60.3% Perfective
(new functionality)
The bulk of the maintenance cost is due to new functionality
⇒even with better requirements, it is hard to predict new functions
data from [Lien78a]
4.1% Other
Relative Maintenance Effort
Between 50% and 75% of
global effort is spent on
“maintenance” !](https://image.slidesharecdn.com/stoop-001-oopintro2-101025031304-phpapp01/85/1-OOP-4-320.jpg)
![S.Ducasse 5
Lehman's Laws
A classic study by Lehman and Belady [Lehm85a] identified several
“laws” of system change.
Continuing change
A program that is used in a real-world environment must change, or
become progressively less useful in that environment.
Increasing complexity
As a program evolves, it becomes more complex, and extra resources are
needed to preserve and simplify its structure.
Those laws are still applicable to brand new
object-oriented applications
5](https://image.slidesharecdn.com/stoop-001-oopintro2-101025031304-phpapp01/85/1-OOP-5-320.jpg)
1 - OOP
- 2. S.Ducasse 2 License: CC-Attribution-ShareAlike 2.0 http://creativecommons.org/licenses/by-sa/2.0/
- 3. S.Ducasse 3 Outline • Context: Software MUST evolve • OOP Modeling • Objects • Classes • Inheritance
- 4. S.Ducasse 4 Continuous Development 17.4% Corrective (fixing reported errors) 18.2% Adaptive (new platforms or OS) 60.3% Perfective (new functionality) The bulk of the maintenance cost is due to new functionality ⇒even with better requirements, it is hard to predict new functions data from [Lien78a] 4.1% Other Relative Maintenance Effort Between 50% and 75% of global effort is spent on “maintenance” !
- 5. S.Ducasse 5 Lehman's Laws A classic study by Lehman and Belady [Lehm85a] identified several “laws” of system change. Continuing change A program that is used in a real-world environment must change, or become progressively less useful in that environment. Increasing complexity As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure. Those laws are still applicable to brand new object-oriented applications 5
- 6. S.Ducasse 6 Software is living… • Early decisions may have been good at that time • But the context changes • Customers change • Technology changes • People change • Successful software MUST evolve
- 7. S.Ducasse 7 The Old Way • Computer system consists of data and programs. • Programs manipulate data. • Programs organized by • functional decomposition • dataflow • modules
- 8. S.Ducasse 8 OOP • Computer system consists of a set of objects. • Objects are responsible for knowing and doing certain things. • Objects collaborate to carry out their responsibilities. • Programs organized by classes, inheritance hierarchies and subsystems
- 9. S.Ducasse 9 Accidental vs. Essential Complexity • Assembly is perfect to write 8k programs! • But we need abstraction tools to model the complexity of the world • Object-oriented programming in only one way • Reactive languages, • Relational languages, • Logic Languages, … are others • OOP helps reducing the accidental complexity not the essential • Bad OO programs are also difficult to understand, extend, and maintain
- 10. S.Ducasse 10 Outline • Context: Software MUST evolve • OOP Modeling • Objects • Classes • Inheritance
- 11. S.Ducasse 11 What is an object, anyway? Programming language view An object-oriented system is characterized by data abstraction inheritance polymorphism by late-binding of procedure calls
- 12. S.Ducasse 12 Modeling All phases of software life-cycle are modeling analysis - modeling of problem design - modeling of solution implementation - making model run on a computer maintenance - fixing/extending your model
- 13. S.Ducasse 13 Modeling Claim: people model the world with "objects" objects and classes relationships between objects relationships between classes Advantages of object-oriented software development more natural - matches the way people think single notation - makes it easy to move between software phases
- 14. S.Ducasse 14 Objects and Relationships John is Mary's father. Mary is John's daughter. Bob is Mary's dog. Mary is Bob's owner. Ann is John's employer. John is Ann's employee.
- 15. S.Ducasse 15 Objects and Attributes John's name is "John Patrick O'Brian". John's age is 27. John's address is 987 N. Oak St, Champaign IL 61820 What about John's employer? John's wife? What is an attribute, and what is a relationship?
- 16. S.Ducasse 16 Objects and Behavior John goes on a trip. John makes reservations. John buys tickets. John travels by airplane. John checks into hotel.
- 17. S.Ducasse 17 What is really an object? • Anything we can talk about can be an object, including relationships ("the husband of the first party", "first- born son"). • What are we trying to model? • “Models should be as simple as possible, but no simpler”. • Models are dictated by domains
- 18. S.Ducasse 18 Some Examples • Things that we can manipulate or see: Book, BD • Things that we can conceptually see: Process, Mortgage, InsuranceContract, Socket, • Rôles: Mother,Teacher, • Drivers,Algorithms • Events and transactions • Library elements: Color,Window,Text, Dictionary, Date, Boolean.... • Organizations, processes
- 19. S.Ducasse 19 RoadMap • Context: Software MUST evolve • OOP Modeling • Objects • Classes • Inheritance
- 20. S.Ducasse 20 State + Behavior + Identity
- 21. S.Ducasse 21 State + Behavior + Identity • State: Objects it contains or refers to • Ex: point location • Behavior: an object understands a given set of messages • Identity: an object can be the same (of the same class) than another one but it has still a different identity (location in memory)
- 23. S.Ducasse 23 • What: Messages – Specify what behavior objects are to perform – Details of how are left up to the receiver – State information only accessed via messages • How: Methods – Specify how operation is to be performed – Must have access to (contain or be passed) data – Need detailed knowledge of data – Can manipulate data directly Behavior + State + Control Data Methods Messages
- 24. S.Ducasse 24 Equality and Identity • I want to eat the pizza that you are eating • Equality: I want to eat the “same” kind of pizza • Identity: I eat your pizza
- 26. S.Ducasse 26 Encapsulation • Object protects its data • We cannot access private data • Object protects its implementation choice • Clients use a public interface • Object can change its implementation
- 27. S.Ducasse 27 Object Summary Objects have an identity have attributes have behavior have relationships with other objects Objects protect their data offer services, protect their implementation
- 28. S.Ducasse 28 Roadmap • Context: Software MUST evolve • OOP Modeling • Objects • Classes • Inheritance
- 29. S.Ducasse 29 Classification • We naturally put objects into classes that have similar characteristics. • John is a man. • Mary is a woman. • Bob is a dog. • All women are people. • All people are mammals.
- 30. S.Ducasse 30 A Class generates Instances
- 31. S.Ducasse 31 Classes: Factory of Objects • Reuse behavior => Factor into class • Class:“Factory” object for creating new objects of the same kind • Template for objects that share common characteristics
- 32. S.Ducasse 32 Class: Mold of Objects • **Describe** state but not effective values of all the instances of the class – Position, width and length for rectangles • **Define** behavior of all instances of the class Rectangle>>area ^ width * height
- 33. S.Ducasse 33 Instances • A particular occurrence of an object defined by a class • Each instance has its own value for the instance variables • All instances of a class share the same methods 400@10 100 20 300@20 10 140
- 34. S.Ducasse 34 An example • Let’s control robots.... • http://smallwiki.unibe.ch/botsinc/
- 35. S.Ducasse 35 Instances Creation • Asking a class to create an instance • The Bot factory creates a new robot
- 36. S.Ducasse 36 Instance Interaction • We send messages to individual robots too
- 37. S.Ducasse 37 Instances are autonomous...
- 38. S.Ducasse 38 Instances vs. Classes • The class Bot does not understand go: 100 • The class Bot understand new to create new robots • aBot does not understand new • aBot understands robot messages such as turn:, go:, jump:, turnLeft:, color, lookLikeTriangle
- 39. S.Ducasse 39 Roadmap • Context: Software MUST evolve • OOP Modeling • Objects • Classes • Inheritance
- 40. S.Ducasse 40 How to Share Specification? • Do not want to rewrite everything! • Often times want small changes • Man are a specialization of People • OOP language offers inheritance to reuse or specialize classes • Class hierarchies for sharing of definitions • Each class defines or refines the definition of its ancestors
- 41. S.Ducasse 41 Inheritance • New classes • Can add state and behavior (ColoredRectangle) • Can specialize ancestor behavior (GoldenRectangle) • Can use ancestor’s behavior and state • Can hide ancestor’s behavior • Direct ancestor = superclass • Direct descendant = subclass
- 42. S.Ducasse 42 Comparable Quantity Hierarchy
- 43. S.Ducasse 43 Summary • Classes • **Describes** the attributes, and relationships of a set of objects • Define the behavior of a set of objects • Reuse, extend, specialize behavior from other classes • Subclasses/superclasses form graph of generalizations
- 44. S.Ducasse 44 Summary An object has a state, a behavior and a unique identity. The structure and behavior of similar objects is shared in their class Instances of a class and objects are terms that cn be exchanged Classes as organized in generalisation/specialisation hierarchy What is an instance? What is the difference between instantiation and inheritance?
Editor's Notes
- #5: Well, better requirements engineering indeed helped to identify stable ground in the muddle of CHANGING REQUIREMENTS. Unfortunately, an empirical survey done by Lientz and Swanson revealed that the majority of changes requested have to do with EXTRA FUNCTIONALITY. That’s why modern requirements engineering tries to define SCENARIOs FOR FUTURE EXTENSIONS so that the designers can accommodate their designs. That’s why we try to define good DOMAIN MODELS, so that most of the changes will fit our design. Unfortunately, no matter how good our requirements engineering, we will never be able TO PREDICT THE FUTURE Therefore, there will always be changes that DO NOT FIT OUR ORIGINAL DESIGN, and depending on our problem domain this may be quite a lot. By the way, that’s one of the reasons why AGILE DEVELOPMENT METHODS are so popular nowadays. They observed that for certain problem domains you cannot make good predictions about the 60% perfective maintenance here (POINT TO SLIDE). When that’s the case, its useless to invest in a good design because you don’t know which variation points to build into your design. Half of the times, you will guess wrong and then you loose twice – once for creating a variation point you didn’t use, and once for extending the design with a new variation point.
- #6: The big conclusion we can derive from this as that we are STUCK The worst thing that can happen to a software system is that IT ACTUALLY GETS USED. Because if your system is used, USERS WILL ASK YOU TO ADAPT And because end-users are VERY CREATIVE in finding new ways of using your software, you will end up adding features which were never expected And because you did not expect it, adding these will PROBABLY DESTROY YOUR INITIAL GOOD DESIGN This observation isn't new. Already in the early 80's, Manny Lehman observed the way the IBM Operating system 760 evolved … and derived 7 LAWS OF SOFTWARE EVOLUTION Two of them are particularly RELEVANT IN A REENGINEERING CONTEXT … (READ SLIDE) Since then, these laws have been validated against a number of INDUSTRIAL CASES and shown that they are STILL APPLICABLE … however, open source development seems to be able to ESCAPE THE EXTRA COMPLEXITY, probably because they spend the extra resources to simplify the structure.