1. Chapter 2Object-Oriented Paradigm Overview

2. Getting Acquainted with the Class Project • Read the requirements specification carefully • Make note of any clarifications or ambiguities • Discuss your understanding of the requirements with your development team • Identify an aspect of the project in which you are particularly interested • Start to formulate informal scenarios

3. Guidelines for Formulating Informal Scenarios • Should be short • Should address one activity • Should specify concrete values • May address some form of user error • Implementation details should be omitted • System state prior to initiation should be described • The next scenario should be indicated

4. Object-Oriented Conceptualization • Visualize the tangible elements comprising the software system, like books, patrons etc • Also think about non-tangible nouns • Think about the intangible nouns • Think about how the nouns (objects) interrelate with each other • Patron checks out a book • Librarian reshelves books

5. Inter-Object Relationships • Application specific relationships • Relationships determined by the application domain • Inheritance • Super/subclass relationship • Aggregation/Containment • One object is a component of another object

6. UML Inter-Object Relationships • Dependency • Objects of one class use instances of another • Association • One class has link to another class • Includes aggregation and application specific relationships • Generalization • Super/subclass relationship • Realization • One class provides a service for another class

7. The Software Life Cycles • Top-down development • Traditional development approach • Prototyping • Using system mock-up to gain user feedback • Incremental/Iterative • Suggested for object-oriented systems • Hybrid • Some combination of development approaches

8. Waterfall Process • Requirements analysis • Product design • System design • Programming • Testing • Maintenance

9. Other Software Development Activities • Customer communication • Project planning • Risk analysis • Engineering • Product construction and release • Customer evaluation

10. Object-Oriented Model Building • Allows the management of complexity • As developers become more familiar with the software system, their understanding can be recorded through the modeling notation • Different types of models are built to express different aspects of the system • Models express system characteristics unambiguously

11. Properties of Quality Modules • Cohesion • Accomplishes a clearly delineated task • Loose coupling • Not overly interconnected with other modules • Encapsulation • Hides implementation details • Presents a simple interface • Reusability • Written in a general purpose way

12. Unified Modeling Language • The software modeling notation used by the textbook • Programming language independent • Industry standard notation • Flexible and expressive • A subset of UML will be used in the textbook

13. Use of Models in Object-Oriented Software Engineering • To create non-narrative, unambiguous expressions of objects,class and their interrelationships • To model a variety of perspectives of the software system for use during analysis and design • To express system requirements at varying levels of abstraction

14. More: Models in Object-Oriented Software Engineering • To facilitate communication among technical personnel • To create complete, verifiable, and unambiguous programming specifications • To serve as system documentation • To assist in project planning and management • To support quality assurance and verification activities

15. Qualities of Good Software Systems • Functionality • Suitable to users • Accurately accomplishes user requirements • Interoperable with other systems • Secure • Reliability • Fault tolerant • Recoverable • Mature - uses advanced features well

16. More: Qualities of Good Software Systems • Usability • Understandability • Learnability • Operability • Efficiency • Time behavior • Resource use

17. More: Qualities of Good Software Systems • Maintainability • Analyzability • Changeability • Stability • Testability • Portability • Adaptability • Conformance • Replaceability

18. Holding Effective Team Meetings • Create a clear agenda addressing the essential tasks that must be accomplished in order to complete the necessary deliverables • Stick to the agenda during the meeting • Ensure that each team member understands his or her tasks before the meeting is adjourned • Ensure that tasks are equitably distributed

19. Class Project Deliverables • The deliverables associated with the class project are essential to successfully completing the project • The class project is not merely a programming assignment • The deliverables result from completing tasks associated with analysis, design, implementation, and testing the class project