DOC PREVIEW
UNF COP 2551 - Object Oriented Design

This preview shows page 1-2-3-19-20-39-40-41 out of 41 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 41 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Chapter 6Object-Oriented DesignOutlineProgram DevelopmentRequirementsDesignImplementationTestingSlide 9Identifying Classes and ObjectsSlide 11Slide 12Slide 13Slide 14Slide 15Slide 16Static Class MembersThe static ModifierStatic VariablesStatic MethodsSlide 21Slide 22Slide 23Slide 24Slide 25Class Relationships – Essential Concept!DependencySlide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35AggregationSlide 37Aggregation in UMLSlide 39Slide 40Slide 41Chapter 6Object-Oriented DesignPart 1© 2004 Pearson Addison-Wesley. All rights reserved 2/42Object-Oriented Design•Now we can extend our discussion of the design of classes and objects•Chapter 6 focuses on: software development activities determining the classes and objects that are needed for a program the relationships that can exist among classes the static modifier writing interfacesthe design of enumerated type classesmethod design and method overloadingGUI design and layout managers© 2004 Pearson Addison-Wesley. All rights reserved 3/42OutlineSoftware Development ActivitiesIdentifying Classes and ObjectsStatic Variables and MethodsClass RelationshipsInterfacesEnumerated Types RevisitedMethod DesignTestingGUI Design and Layout© 2004 Pearson Addison-Wesley. All rights reserved 4/42Program Development•The creation of software involves four basic activities:establishing the requirementscreating a designimplementing the code (programming)testing the implementation•These activities are not strictly linear – they overlap and interact© 2004 Pearson Addison-Wesley. All rights reserved 5/42Requirements•Software requirements specify the ‘whats’ (tasks) that a program must accomplish what to do, not how to do it•Often an initial set of requirements is provided, but they should be critiqued and expanded•It is difficult to establish detailed, unambiguous, and complete requirements•Careful attention to the requirements can save significant time and expense in the overall project•You cannot design and implement that which you do not understand!© 2004 Pearson Addison-Wesley. All rights reserved 6/42Design A software design specifies how a program will accomplish its requirements That is, a software design determines:how the solution can be broken down into manageable pieceswhat each piece will do An object-oriented design determines which classes and objects are needed, and specifies how they will interact Low level design details include how individual methods will accomplish their tasks© 2004 Pearson Addison-Wesley. All rights reserved 7/42Implementation•Implementation is the process of translating a design into source code Novice programmers often think that writing code is the heart of software development, but actually it should be the least creative step Almost all important decisions are made during requirements and design stages•Implementation should focus on coding details, including style guidelines and documentation•Implementation (programming and testing) is really the ‘implementation of a design.’•The DESIGN is the solution!© 2004 Pearson Addison-Wesley. All rights reserved 8/42Testing•Testing attempts to ensure that the program will solve the intended problem under all the constraints specified in the requirements•A program should be thoroughly tested with the goal of finding errors•Debugging is the process of determining the cause of a problem and fixing it•We revisit the details of the testing process later in this chapter© 2004 Pearson Addison-Wesley. All rights reserved 9/42OutlineSoftware Development ActivitiesIdentifying Classes and ObjectsStatic Variables and MethodsClass RelationshipsInterfacesEnumerated Types RevisitedMethod DesignTestingGUI Design and Layout© 2004 Pearson Addison-Wesley. All rights reserved 10/42Identifying Classes and Objects•The core activity of object-oriented design is determining the classes and objects that will make up the solution•The classes may be part of a class library, reused from a previous project, or newly writtenMath class, etc. Existing classes etc. in the API… One way to identify potential classes is to identify the objects discussed in the requirements Objects are generally nouns, and the services that an object provides are generally verbs© 2004 Pearson Addison-Wesley. All rights reserved 11/42Identifying Classes and Objects•A partial requirements document:The user must be allowed to specify each product byits primary characteristics, including its name andproduct number. If the bar code does not match theproduct, then an error should be generated to themessage window and entered into the error log. Thesummary report of all transactions must be structuredas specified in section 7.A. Of course, not all nouns will correspond toa class or object in the final solution© 2004 Pearson Addison-Wesley. All rights reserved 12/42Identifying Classes and Objects Remember that a class represents a group (classification) of objects with the same behaviors•Generally, classes that represent objects should be given names that are singular nouns•Examples: Coin, Student, Message•A class represents the concept of one such object•We are free to instantiate – that is, create a object - as many of each class as needed© 2004 Pearson Addison-Wesley. All rights reserved 13/42Identifying Classes and Objects•Sometimes it is challenging to decide whether something should be represented as a class For example, should an employee's address be represented as a set of instance variables or as an Address object•The more you examine the problem and its details the more clear these issues become When a class becomes too complex, it often should be decomposed into multiple smaller classes to distribute the responsibilities© 2004 Pearson Addison-Wesley. All rights reserved 14/42Identifying Classes and Objects•We want to define classes with the proper amount of detail•For example, it may be unnecessary to create separate classes for each type of appliance in a house It may be sufficient to define a more general Appliance class with appropriate instance data It all depends on the details of the problem being solved© 2004 Pearson Addison-Wesley. All rights reserved 15/42Identifying Classes and Objects Part of identifying the classes we need is the


View Full Document

UNF COP 2551 - Object Oriented Design

Download Object Oriented Design
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Object Oriented Design and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Object Oriented Design 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?