1. Chapter 2 Object-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