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 Identify an aspect of the project in which you are particularly interested Start to formulate informal scenarios
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
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
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
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
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
Waterfall Process Requirements analysis Product design System design Programming Testing Maintenance
Other Software Development Activities Customer communication Project planning Risk analysis Engineering Product construction and release Customer evaluation
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
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
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
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
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
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
More: Qualities of Good Software Systems Usability Understandability Learnability Operability Efficiency Time behavior Resource use
More: Qualities of Good Software Systems Maintainability Analyzability Changeability Stability Testability Portability Adaptability Conformance Replaceability
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
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