1 / 19

Chapter 2 Object-Oriented Paradigm Overview

Chapter 2 Object-Oriented Paradigm Overview. 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

gram
Download Presentation

Chapter 2 Object-Oriented Paradigm Overview

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. 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

More Related