1. © 2010 University of California, Irvine – André van der Hoek1June 26, 2015 – 00:06:40 Informatics 122 Software Design II Lecture 6 André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

2. © 2010 University of California, Irvine – André van der Hoek2June 26, 2015 – 00:06:40 Today’s Lecture Design aesthetics Your BeNumbered designs

3. © 2010 University of California, Irvine – André van der Hoek3June 26, 2015 – 00:06:40 Design Aesthetics What makes a given software implementation design “beautiful”? What is it that makes someone appreciate a particular software implementation design? What are the qualities that determine whether a particular software implementation design is “good” or “bad”? What is it, then, that we can strive for in creating a software implementation design that will help others in appreciating it?

4. © 2010 University of California, Irvine – André van der Hoek4June 26, 2015 – 00:06:40 Purpose of Implementation Design An implementation design is a road map An implementation design describes a path from application / interaction / architecture design to the product An implementation design describes what the implementers should do An implementation design is a guide towards future change

5. © 2010 University of California, Irvine – André van der Hoek5June 26, 2015 – 00:06:40 Purpose of Implementation Design An implementation design is a road map –understandable, unambiguous, consistent, helpful, … An implementation design describes a path from application / interaction / architecture design to the product –correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do –elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change –evolvable, …

6. © 2010 University of California, Irvine – André van der Hoek6June 26, 2015 – 00:06:40 Less of a Shared Understanding An implementation design is a road map –understandable, unambiguous, consistent, helpful, … An implementation design describes a path from application / interaction / architecture design to the product –correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do –elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change –evolvable, …

7. © 2010 University of California, Irvine – André van der Hoek7June 26, 2015 – 00:06:40 Some Caveats We are going to be showing, praising, and critiquing your designs –not to ridicule, rather to provide constructive feedback This is a normal part of any design studio class Rules of the game –do not identify someone, even if you know whose design it is –someone may choose to volunteer and explain their design, but they may also choose not to do so We only highlight parts of certain designs, so please do not correlate our comments here with your final grade for this assignment We only do this based on the UML diagram, not the text

8. Designs Rated Highly By Peers 15 18 22 © 2010 University of California, Irvine – André van der Hoek8June 26, 2015 – 00:06:40

9. Some “Obvious” Room for Improvement 1 3 11 13 16 19 25 © 2010 University of California, Irvine – André van der Hoek9June 26, 2015 – 00:06:40

10. What About These? 6 14 23 © 2010 University of California, Irvine – André van der Hoek10June 26, 2015 – 00:06:40

11. Some Subtler Issues 2 4 7 8 9 © 2010 University of California, Irvine – André van der Hoek11June 26, 2015 – 00:06:40

12. © 2010 University of California, Irvine – André van der Hoek12June 26, 2015 – 00:06:40 Important Points to Observe (Assignment) Being a “1” or a “5” on someone’s ranking is not an absolute evaluation –if you are a “1” on someone’s ranking, the other designs may have all been relatively poor –if you are a “5” on someone’s ranking, the other designs may have all been relatively stellar Length of the document seems to be an indicator in peer’s rankings, but not necessarily in ours It is easier to review than to design, or is it?

13. © 2010 University of California, Irvine – André van der Hoek13June 26, 2015 – 00:06:40 Important Points to Observe (UML) Having a document “heavy on UML” by itself is not a guarantee for a great design –it may indeed be more complete –it may also be less understandable If we cannot find the “flow” in the UML diagram, something tends to be wrong –for some designs, we end up searching for their meaning –for others, it is clear from the diagram  physical layout, often, has something to do with this Design languages are a factor –UML by itself is insufficient

14. © 2010 University of California, Irvine – André van der Hoek14June 26, 2015 – 00:06:40 Important Points to Observe (Process) Where to start? –what about with the set of nouns in the description of the problem (e.g., word, rack, tile, board, …) –what about with the set of verbs in the description of the problem (e.g., challenge, play, double, triple, …) Work towards completeness –does my current design account for all possible features –does it do so explicitly, or are some features hidden This is merely a rough and rules of thumb process, but one that tends to help the beginning designer

15. © 2010 University of California, Irvine – André van der Hoek15June 26, 2015 – 00:06:40 A Checklist for the Overall Process Apply rigor Separate concerns –modularize –abstract Anticipate change Generalize Work incrementally

16. © 2010 University of California, Irvine – André van der Hoek16June 26, 2015 – 00:06:40 A Checklist for Overall Design Strive for grouping related functionality (high cohesion) Strive for ungrouping semi-related functionality (high cohesion) Strive for reducing interdependency (low coupling)

17. © 2010 University of California, Irvine – André van der Hoek17June 26, 2015 – 00:06:40 A Checklist on Class Design Cohesion Completeness Convenience Clarity Consistency

18. © 2010 University of California, Irvine – André van der Hoek18June 26, 2015 – 00:06:40 A Checklist on Principles and Strategies Principles –keep it simple, stupid! (KISS) –information hiding –acyclic dependencies –… Strategies –program to the interface –refactor –apply software patterns –use aspects –…

19. © 2010 University of California, Irvine – André van der Hoek19June 26, 2015 – 00:06:40 Appendix For completeness, you have received a packet with all of the designs