Foundations of Software Design Fall 2002 Marti Hearst

1. Foundations of Software DesignFall 2002Marti Hearst Lecture 7: Object-Oriented Design

2. Design Processes • What is design? • A creative problem solving process • Key aspects of design • Create use scenarios • Consider several options • Iterate, iterate, iterate (rarely right the first time) • How to learn design? • By seeing (lots of) examples • By doing (lots of) examples

3. Key Software Design Goals • Simplicity • Often leads to elegance • Easier to understand and debug the code • Reduces errors • Reliability / Robustness • Can handle unexpected input • Recovers from errors gracefully • Doesn’t damage anything • Effectiveness • Solves the right problems (intuitive for users) • Efficient • Compatible with other software

4. i) CPU using 3 chips (classes) ii) CPU using 3 chips (classes) Complex vs. Simple Design What is the problem here? Slide adapted from James Landay

5. Good vs. Bad Design • The designs functionally equivalent, but the 2nd is • hard to understand • hard to locate faults • difficult to extend or enhance • cannot be reused in another program. • -> expensive to perform maintenance • Good modules must be like the 1st design • maximal relationships within classes (cohesion) • minimal relationships between classes (coupling) Slide adapted from James Landay

6. Other Software Design Goals • Reusability • Adaptability

7. OO Design • Object languages allow advantages, but don’t provide them. • Database models are data-oriented. OO models are responsibility-oriented. • Special emphasis on • Abstraction and generalization • Encapsulation and information hiding • Modularity

8. OOD: Data & Action Are Equal • Actions & data are intertwined • data cannot change unless an action is performed on it • actions without associated data are equally meaningless • Object consists of • data • attributes, state variables, instance vars, fields, … • actions • methods, member functions • plus inheritance • Objects should • model all aspects of one (physical) entity • Objects are independent units • easier to maintain & combine into a larger program Slide adapted from James Landay

9. Information Hiding • Really “details hiding” • hiding implementation details, not information • design classes so that items likely to change are hidden • Localizes future changes • Changes cannot affect other classes Slide adapted from James Landay

10. Inheritance • New data types defined as extensions to previously defined types • don’t have to define from scratch -> provides more data abstraction • Example Define humanBeing to be a class A humanBeing has attributes, such as age, height, gender Assign values to attributes when describing object Define parent to be a subclass of humanBeing A parent has all attributes of humanBeing, plus attributes of his/her own (name of oldest child, number of children) A parent inherits all attributes of humanBeing Slide adapted from James Landay

11. Inheritance (Java) class HumanBeing { privateint age; private float height; public // declarations of operations on HumanBeing } // class HumanBeing class Parent extends HumanBeing { privateString nameOfOldestChild; private int numberOfChildren; public // declarations of operations on Parent } // class Parent Slide adapted from James Landay

12. Multiple Inheritance • Class inherits from more than one superclass • In java, must use an indirect method • Interfaces • We’ll learn more about this when we do sorting

13. OO Design • Write a description of what should happen • Nouns: objects • Verbs: methods • Example: Create an address list • Create an address list that includes each person’s name, address, telephone number, and e-mailaddress. This list should be printed in alphabeticalorder. • Reconsider, and discard some: • Order acts as a modifier, not a noun • Person’s: possessive indicate a potential grouping

14. Person (superclass) OO Design Example • Example: A Party • What are the objects? • Hosts • Guests • Invitation • Address • Of party • Of guest • Date • Theme • Food/Drinks • Music

15. OO Design Example • Example: A Party • What are the methods? • Shop • Cook • Send invitations • Need a list of invitation objects • Clean the house • RSVP • Travel to the party • Which objects have which responsibilities?

16. General Approach • Define the problem • Create scenarios of use • Do interviews, fieldwork, to find out what is needed • Scenarios show typical examples of use • Use CRC cards to define • Objects • Begin with the most important ones • Responsibilities • The main thing(s) these objects do(es) • Relations to other objects

17. Class name: Superclass: Subclasses: Responsibilities: Collaborations: CRC Cards • Class, Responsibility, Collaboration • Responsibilities: tasks to perform • Collaborations: other objects this object works with

18. Class name: Superclass: Subclasses: Responsibilities: Collaborations: CRC Card for Host/Hostess Person Host(ess) Send Invitations Invitation, Person, List Shop Money, Store, Food, Car, … Clean House Sponge, Cleaner …

19. Class name: Superclass: Subclasses: Responsibilities: Collaborations: CRC Card for Guest Person Guest RSVP Phone, Host(ess)

20. CRC to UML • CRC cards are used to define the main classes and their interactions • A brainstorming tool • Write many, throw many away • UML: Unified Modeling Language • Used to • Refine the design • Describe the design to others

21. UML: Unified Modeling Language • Notation for describing OO design • Associated with a design methodology • Several types of diagrams • Class diagrams • Static structure • Use Case diagrams • Functionality using actors and cases • Sequence diagrams • Exchange of messages between classes over time • There are many others http://www.smartdraw.com/resources/centers/uml/uml.htm

22. The Three Steps of OOD • Not a rigid set of rules • There are many different equivalent methods • Represent using UML (unified modeling language) • Three iterative steps • use-case modeling • determine how various results are computed w/o sequencing • largely action oriented • Technique: natural language, flow charts • class modeling (object modeling) • determine the classes, their attributes, & their interrelationships • purely data-oriented • technique: CRC cards followed by UML class diagrams • dynamic modeling • determine the actions performed by or to each class • purely action-oriented Slide adapted from James Landay

23. Class Diagrams • Class Details • (don’t put all this in unless finalizing the design) http://www.stanford.edu/~gpathy/umlshort/

24. Class Diagram – Simpler Version

25. Class Diagram – Complex Version http://www.stanford.edu/~gpathy/umlshort/

26. Class Diagrams’ Relationships • association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes. • aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. • generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. http://www.stanford.edu/~gpathy/umlshort/

27. Class Diagrams • An association has two ends. • An end may have a role name to clarify the nature of the association. • A navigability arrow on an association shows which direction the association can be traversed or queried. • The arrow also lets you know who "owns" the association's implementation • Associations with no navigability arrows are bi-directional. • The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. • Multiplicities are single numbers or ranges of numbers. http://www.stanford.edu/~gpathy/umlshort/

28. PersonalComputer Printer CPU Monitor Keyboard Aggregation UML notation: diamond (1 or more) no diamond (1) Aggregation refers to the components of a class - used to group related items - each of these (CPU, etc.) would be instance var Slide adapted from James Landay

29. Class Diagrams • Composition is a strong association in which the part can belong to only one whole -- the part cannot exist without the whole. Composition is denoted by a filled diamond at the whole end. http://www.stanford.edu/~gpathy/umlshort/

30. HumanBeing (base class) inherits from (“ isA ”) Parent derived (derived class) part additional part Inheritance (UML) UML notation: boxes represent classes open triangle represents inheritance Slide adapted from James Landay

31. To Think about:Using Objects to Make Objects • Goal: Write Java code to create a Saladclass • The main goal is to create and use objects representing the various components of a salad. • Salad is made up of Ingredients • These are not subclasses; they are components • Methods include wash(), chop() • Different types of salads use different ingredients • But all salads have the same methods: • Prepare() • Calories() • Cost()