1 / 19

CSE 111: Object Oriented Design

CSE 111: Object Oriented Design. Design. “To program is human but to design is divine” (WEH). What is a Design?. Different possibilities, e.g. Algorithmic strategy e.g. rate-monotonic scheduling strategy for a real time system Decomposition of a system

coen
Download Presentation

CSE 111: Object Oriented Design

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. CSE 111: Object Oriented Design

  2. Design “To program is human but to design is divine” (WEH)

  3. What is a Design? • Different possibilities, e.g. • Algorithmic strategy • e.g. rate-monotonic scheduling strategy for a real time system • Decomposition of a system • modules with well-defined consistent interfaces • Abstract function hierarchy • abstract functions defined in terms of less abstract functions

  4. Design and Abstraction • Design uses abstraction to create views that are comprehensible • Vs the complete code for the program that cannot be comprehended all at the same time • breaking down a system into pieces involves an abstract model that ties the pieces together

  5. Why Design? • Provides an overall picture of the system • Allows us to focus on one thing at a time • A harmonious, understandable design is our best hope for constructing a program that works • Facilitates (design) reuse (NOT code reuse): transmission of expert knowledge

  6. No Design? • Possible for simple or small well- understood programs • For complex systems: 85% phenomenon • milestone 1: 50% done • milestone 2: 75% done • milestone 3: 85% done • milestone 4: 85% done • milestone 5: 85% done .........

  7. Design Paradigms – Functional 1 • Basic components: functions/procedures • Component relationships: one function calls other functions • Abstraction • one function calls another • defined in terms of less abstract or concrete functions

  8. Design Paradigms - Functional 2 • Design strategy • top level function corresponds to program requirements • define this in terms of less abstract functions • continue on down until all functions are concrete • Refactoring: go back and re-design higher level functions if design becomes ugly

  9. Design Paradigms – Object Oriented 1 • Basic components: • classes: state plus function • Component relationships • one class uses other classes to help it fulfill its responsibilities (by its methods calling methods in the other classes) • inheritance • classes grouped into packages/subsystems

  10. Design Paradigms – Object Oriented 2 • Abstraction • inheritance where a superclass is an abstraction of subclasses • usefulness much more restricted than functional top down abstraction • when one class’s methods call methods in another class, this is often a peer relationship not a (top down) abstraction relationship

  11. Design Paradigms – Object Oriented 3 • Layers abstraction • group classes into “layers” in which the classes in the upper layers can use classes in lower layers but not vice-versa • lower layers simulate existence of an abstract machine that can be “used” by higher layers

  12. Design Paradigms – Object Oriented 4 • Design Strategy • identify basic objects/concepts in application domain, and use these as foundation classes • select a design architecture/metaphor • add additional classes for desired functionality • abstract out superclasses to facilitate understanding and possible re-use • refactor as necessary

  13. Functional versus Object Oriented Design? • Application types • Functional • input – computation – output • input may include persistent data (data base or files) • Object oriented • interactive programs with retained distributed session state between interactions • object methods are functions that can be functionally designed but are often simple

  14. Topics • Development Process • Design Paradigms • Design Patterns • mid to low level design ideas that are useful in certain commonly occurring contexts • UML Modeling and Design Language

  15. Project • Two phases • due at midterm and end of class • Purpose: help learn UML and design patterns • Deliverables • assigned at the end of the lecture in which they are described • not due until end of first and second phase

  16. Running Example • Use to illustrate patterns and corresponding UML diagrams • Template for required simple project • Very simple toy dating system

  17. Dating System Example • Initial Start/End screen • Member and Admin Users • Admin recognized by special name at login • Admin can add and delete users • Member can ask for date or update/initialize member data • After each request reset to Start/End

  18. Some Dating System Details • Member properties: • world view: spiritual/ secular • gender: M/F • Exact matches only • Members identified by their names • If date found, member info returned (name, email address)

  19. Assignment 1 • Form a project team • Choose a project topic • .5 to 1 page brief description • “concept document” • Submit for approval by the end of the week • in class or email to • howden@cse.ucsd.edu

More Related