1 / 18

Object-Oriented Software Development

Object-Oriented Software Development. Introduction to software engineering. Course outline. Focus on practical software engineering techniques and tools for component-based object-oriented system. The objective of this course is to learn how to design and construct OO systems

gthompson
Download Presentation

Object-Oriented Software Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object-Oriented Software Development Introduction to software engineering

  2. Course outline • Focus on practical software engineering techniques and tools for component-based object-oriented system. The objective of this course is to learn how to design and construct OO systems • Main topics identified by the IEEE software engineering body of knowledge: • Software engineering process: Extreme programming • Software design: object oriented design with UML • Software construction: OO coding practice, design patterns, refactoring, concurrency, aspect-oriented programming • Software testing: integrated test with JUnit • Software engineering tools and methods: formal specification techniques, design by contract, and tools

  3. Applied software engineering • This course is about • Testing • Debugging • Profiling • Coding standards • Documentation • Tools • Java • This course is not about • Process and project management • Requirement analysis • Software metrics

  4. Goal of this course • Object-oriented software engineering • How to design systems of objects • How to explore inheritance and subsumption to make system generic and flexible • How and when to refactor systems to simplify their designs • Software quality • How to test and validate software • Good coding practice • How to document a design

  5. Traditional software engineering • 1967 NATO study group coined the term software engineering • 1968 NATO declare software crisis: quality of software is abysmal and deadline and cost limits not met • The cost of software development • Small fraction devoted to coding • More than half of the cost is for maintenance

  6. Software process • Requirement phase • Requirement phase testing • Specification phase • Specification phase testing • Design phase • Design phase testing • Implementation phase • Implementation phase testing • Integration phase • Integration phase testing • Maintenance phase • Maintenance phase testing • Retirement phase

  7. Software life cycle models • waterfall and spiral models

  8. What is software quality? • Correctness is the ability of software products to perform their exact tasks as described by their specifications • Robustness is the ability of software system to react appropriately to abnormal conditions • Extensibility is the ease of adapting software products to changes of specifications • Reusability is the ability of software elements to serve for the construction of many different applications • Compatibility is the ease of combining software elements with others • Efficiency is the ability of a software system to place as few demands as possible to the hardware and software environments • Ease of use is the ability of people with various backgrounds and qualifications can learn to use software products Bertrand Meyer, Object-Oriented Software Construction

  9. How to achieve software quality • By design • Pre and post conditions, class invariants • Disciplined exceptions • Design patterns, refactoring • By test • Unit tests, system tests • Repeatable regression tests • Do it, do it right, do it fast • Aim for simplicity and clarity, not performance • Fine-tune performance only when there is a demonstrated need

  10. Why object-oriented programming • Modeling • Complex systems can be naturally decomposed into software objects • Data abstraction • Clients are protected from variations in implementation • Polymorphism • Clients can uniformly manipulate plug-compatible objects • Component reuse • Client/supplier contract can be made explicit, simplifying reuse • Evolution • Classes and inheritance limit the impact of change

  11. Object-oriented design • OOD factors a system into objects with well-defined responsibilities • Objects are responsible for maintaining information and providing services • Operations are always associated to responsible objects • Always delegate to another object when you cannot do it yourself • A good design exhibits • High cohesion of data and operations within classes • Low coupling between classes and subsystems • Iterative development and extreme programming • Refactor the design as it evolves and test each time you compile

  12. UML • Unified modeling language is a standard set of techniques for describing object-oriented designs • Class models • Use case models • Interaction diagrams • State and activity diagrams • …

  13. UML • Drawing editor class diagram Shape DrawingEditor 0..* boundingBox() createManipulator() Line TextShape TextView +text 1 boundingBox() createManipulator() boundingBox() createManipulator() getExtent()

  14. UML • Interaction diagram editor: DrawingEditor txShape: TextShape text: TextView boundingBox() getExtent()

  15. Refactoring • Refactor your design whenever your code starts to smell • Methods that are too long or too hard to read • Decompose and delegate responsibility • Duplicated code • Factor out common parts • Violation of encapsulation • Too much communication between objects • Big case statements • Introduce subclass responsibilities • Hard to adapt to different context • Separate mechanism from policy

  16. XP • eXtreme Programming – Kent Beck • A light weight methodology for small or medium sized teams developing software in the face of vague and fast changing requirements • Tenets of XP: • If code reviews are good, then let’s review all the time (pair programming) • If testing is good, then everybody will test all the time (unit & functional testing) • If design is good, make it part of the daily routine (refactoring) • If simplicity is good, always choose the simplest design • If integration test is important, integrate & test several times a day • If short iterations are good, make the iteration really short – minutes and hours, instead of weeks and months

  17. Why Java? • C++ -- complexity • Clean integration of features • A language academics do not have to be shamed of • Large standard libraries • Simple object model • Almost everything is an object • No pointers • Garbage collection • Single inheritance • Multiple subtyping • Static and dynamic type checking

  18. References • Gamma, Helm, Johnson, Vlissides, Design Pattern – Elements of Reusable Object-Oriented Software, 1995 • Lea, Concurrent programming in Java (2nd Ed.), 1999 • Gosling, Joy, Steele, The Java Language Specification, 1997 • Yellin, The Java Virtual Machine Specification, 2nd Ed. 1999 • Beck, eXtreme Programming explained – embrace change, 1999 • Fowler, Refactoring: Improving the Design of Existing Code, 1999 • Pooley, Steven, Using UML – Software Engineering using Objects and Components, 1999 • Kernighan, Pike, The Practice of Programming, 1999 • Brooks, The Mythical Man-Month, 1982

More Related