1. © 2009 University of California, Irvine – André van der Hoek1June 10, 2015 – 18:31:15 Informatics 122 Software Design II Lecture 2 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. © 2009 University of California, Irvine – André van der Hoek2June 10, 2015 – 18:31:15 Today’s Lecture Design aesthetics Assignment 1

3. © 2009 University of California, Irvine – André van der Hoek3June 10, 2015 – 18:31:15 Aesthetics “a particular theory or conception of beauty or art : a particular taste for or approach to what is pleasing to the senses and especially sight” [Merriam-Webster]

4. © 2009 University of California, Irvine – André van der Hoek4June 10, 2015 – 18:31:15 Design Aesthetics What makes a given software design “beautiful”? What is it that makes someone appreciate a particular software design? What are the qualities that determine whether a particular software design is “good” or “bad”? What is it, then, that we can strive for in creating a software design that will help others in appreciating it?

5. © 2009 University of California, Irvine – André van der Hoek5June 10, 2015 – 18:31:15 Design Aesthetics Some brainstorming…

6. © 2009 University of California, Irvine – André van der Hoek6June 10, 2015 – 18:31:15 Design Aesthetics Different people will have a different aesthetic appreciation of different designs –as informed by their own, pre-existing knowledge –as informed by their own understanding of the design goals –as informed by their own ideas Different roles in the software development project may have different aesthetic appreciation of different designs –coder –software performance engineer –software maintenance specialist –software tester –…

7. © 2009 University of California, Irvine – André van der Hoek7June 10, 2015 – 18:31:15 Design Aesthetics Subjective, as it should be representations (langs) goals (langs) activities goals (langs)knowledge (langs) ideas (langs) tools activities knowledge (langs) ideas (langs) tools

8. © 2009 University of California, Irvine – André van der Hoek8June 10, 2015 – 18:31:15 Design Aesthetics Subjective, as it should be But we need some kind of shared “language”, some common touchstones that we can use to: –understand the underlying implications of certain designs –understand the intentions of designers –effectively frame our communication about designs

9. © 2009 University of California, Irvine – André van der Hoek9June 10, 2015 – 18:31:15 Shared Design Aesthetics Individual Project Organization Community School of Thought

10. © 2009 University of California, Irvine – André van der Hoek10June 10, 2015 – 18:31:15 But… …what kind of shared understandings exist? …where do these shared understandings come from?

11. © 2009 University of California, Irvine – André van der Hoek11June 10, 2015 – 18:31:15 Purpose of Implementation Design An implementation design is a road map An implementation design describes a path from application design to the outcome An implementation design describes what the implementers should do An implementation design is a guide towards future change

12. © 2009 University of California, Irvine – André van der Hoek12June 10, 2015 – 18:31:15 Purpose of Implementation Design An implementation design is a road map –understandable, unambiguous, consistent, helpful, … An implementation design describes a path from application design to the outcome –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, …

13. © 2009 University of California, Irvine – André van der Hoek13June 10, 2015 – 18:31:15 More of a Shared Understanding (Not Perfect!) An implementation design is a road map –understandable, unambiguous, consistent, helpful, … An implementation design describes a path from application design to the outcome –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, …

14. © 2009 University of California, Irvine – André van der Hoek14June 10, 2015 – 18:31:15 Less of a Shared Understanding An implementation design is a road map –understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome –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, …

15. © 2009 University of California, Irvine – André van der Hoek15June 10, 2015 – 18:31:15 Approaches to Date Enumerate objectives Define principles Provide strategies

16. © 2009 University of California, Irvine – André van der Hoek16June 10, 2015 – 18:31:15 Approaches to Date Enumerate objectives –overall process –overall design –individual classes Define principles Provide strategies

17. © 2009 University of California, Irvine – André van der Hoek17June 10, 2015 – 18:31:15 Objectives for Overall Process Apply rigor Separate concerns –modularize –abstract Anticipate change Generalize Work incrementally

18. © 2009 University of California, Irvine – André van der Hoek18June 10, 2015 – 18:31:15 Objectives for Overall Design Strive for grouping related functionality (high cohesion) Strive for ungrouping semi-related functionality (high cohesion) Strive for reducing interdependency (low coupling)

19. © 2009 University of California, Irvine – André van der Hoek19June 10, 2015 – 18:31:15 Objectives for Class Design Cohesion Completeness Convenience Clarity Consistency

20. © 2009 University of California, Irvine – André van der Hoek20June 10, 2015 – 18:31:15 Approaches to Date Enumerate objectives Define principles –keep it simple, stupid! (KISS) –information hiding –acyclic dependencies –… Provide strategies

21. © 2009 University of California, Irvine – André van der Hoek21June 10, 2015 – 18:31:15 Keep It Simple, Stupid! (KISS) Nothing should be more complicated than absolutely essential and, even then, everything should be analyzed as to whether it can be done simpler

22. © 2009 University of California, Irvine – André van der Hoek22June 10, 2015 – 18:31:15 Information Hiding Hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed

23. © 2009 University of California, Irvine – André van der Hoek23June 10, 2015 – 18:31:15 Acyclic Dependencies Structure packages (grouping classes and interfaces) of a software system in such a manner that the dependencies among them form a directed acyclic graph (DAG)

24. © 2009 University of California, Irvine – André van der Hoek24June 10, 2015 – 18:31:15 Approaches to Date Enumerate objectives Define principles Provide strategies –program to the interface –refactor –apply software patterns –use aspects

25. © 2009 University of California, Irvine – André van der Hoek25June 10, 2015 – 18:31:15 Program to the Interface Program to an interface, never directly to an implementation Always wrap a class in an interface

26. © 2009 University of California, Irvine – André van der Hoek26June 10, 2015 – 18:31:15 Refactor (to be discussed in future lectures)

27. © 2009 University of California, Irvine – André van der Hoek27June 10, 2015 – 18:31:15 Apply Software Patterns (to be discussed in future lectures)

28. © 2009 University of California, Irvine – André van der Hoek28June 10, 2015 – 18:31:15 Use Aspects (discussed in Informatics 102)

29. © 2009 University of California, Irvine – André van der Hoek29June 10, 2015 – 18:31:15 Approaches to Date Enumerate objectives Define principles Provide strategies

30. © 2009 University of California, Irvine – André van der Hoek30June 10, 2015 – 18:31:15 Purpose of Implementation Design An implementation design is a road map –understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome –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, …

31. © 2009 University of California, Irvine – André van der Hoek31June 10, 2015 – 18:31:15 Purpose of Implementation Design An implementation design is a road map –understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome –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, … The approaches to date help, but much more remains to be done

32. © 2009 University of California, Irvine – André van der Hoek32June 10, 2015 – 18:31:15 Why Aesthetics? Aesthetics aims higher than “usable” or “complete” or … It aims to set a bar for design for which we as professional designers should strive –designs that are elegant –designs that communicate their intent seamlessly –designs that overall exude an air of sophistication that sets them apart from ordinary designs –designs that others will appreciate, for the right reasons

33. © 2009 University of California, Irvine – André van der Hoek33June 10, 2015 – 18:31:15 First Assignment: Ogre (Overview) Your client reminisces about the classic DOS game Beast, wherein you push blocks to try to crush beasts which, in turn, try to eat you. You are to create a UML, object-oriented design for a software implementation of a rough remake of Beast, called Ogre Beast Screenshot

34. First Assignment: Ogre (Rules) The game takes place on a 38 x 21 grid, which randomly contains: –A single hero –A large number of blocks and superblocks –A small number of enemies (ogres and superogres) The player moves the hero orthogonally, with the keyboard. Every time the player moves, each enemy also moves one space. If an enemy touches a player, the player loses one life and the enemy disappears. If a player loses 3 lives, the game is over. A player can push blocks in a line, but a superblock stops all movement. –Superblocks cannot be pushed. –The outer walls of the level are considered superblocks. If an enemy is behind a pushed block, it is moved. If there is another block in the way, and it is a regular ogre, it is crushed and killed. –Superogres, however can only be crushed against superblocks and will just continue the push chain otherwise. When all enemies are dead, the game is repopulated with objects. © 2009 University of California, Irvine – André van der Hoek34June 10, 2015 – 18:31:15

35. First Assignment: Ogre (Examples) PP POP POP O PSPS PSP PP © 2009 University of California, Irvine – André van der Hoek35June 10, 2015 – 18:31:15

36. First Assignment: Ogre (Video) http://www.youtube.com/watch?v=gtDq0EGSDSg © 2007 University of California, Irvine – André van der Hoek36June 10, 2015 – 18:31:15

37. First Assignment: Ogre (Other details) Graphics may be done as text output, you do not need to worry about building complex designs for the GUI. Other game design decisions, such as the number of blocks and the method used to determine how the enemies move, is up to you. The customer is not sure what will make the game fun, and may demand new block types, enemy types, or other changes in the future. © 2009 University of California, Irvine – André van der Hoek37June 10, 2015 – 18:31:15

38. © 2009 University of California, Irvine – André van der Hoek38June 10, 2015 – 18:31:15 First Assignment: Ogre (Assignment Details) You should provide additional documentation beyond the raw UML diagrams, where needed. You should feel free to use any UML or diagramming tool. You should bring one printed copy of your design to class. This is merely part 1 of this assignment, it will continue for several more lectures –you will be evaluating and implementing each other’s designs Due: January 12 th, start of class

39. © 2009 University of California, Irvine – André van der Hoek39June 10, 2015 – 18:31:15 First Assignment: Grading Understandability –can someone pick it up and implement it? Flexibility –can the design support future changes?