Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSE 111: Object Oriented Design. Design “To program is human but to design is divine” (WEH)

Similar presentations


Presentation on theme: "CSE 111: Object Oriented Design. Design “To program is human but to design is divine” (WEH)"— 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


Download ppt "CSE 111: Object Oriented Design. Design “To program is human but to design is divine” (WEH)"

Similar presentations


Ads by Google