1. 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.
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

2. © 2010 University of California, Irvine – André van der Hoek
Today’s Lecture
Design aesthetics
Assignment 1
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

3. © 2010 University of California, Irvine – André van der Hoek
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]
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

4. © 2010 University of California, Irvine – André van der Hoek
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?
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

5. © 2010 University of California, Irvine – André van der Hoek
Design Aesthetics
Some brainstorming…
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

6. © 2010 University of California, Irvine – André van der Hoek
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 …
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

7. © 2010 University of California, Irvine – André van der Hoek
Design Aesthetics
Subjective, as it should be
Final Design
Alternative Designs
Product
Designers
Stakeholders
Users
Experiences
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

8. © 2010 University of California, Irvine – André van der Hoek
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
I think all 3 of these are very important points actually, perhaps worth of their own slides?
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

9. Shared Design Aesthetics
Individual
Project
Organization
Nice!
School of Thought
Community
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

10. © 2010 University of California, Irvine – André van der Hoek
But…
…what kind of shared understandings exist?
…where do these shared understandings come from?
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

11. 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
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

12. 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, …
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

13. 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 / 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, …
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

14. 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, …
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

15. © 2010 University of California, Irvine – André van der Hoek
Approaches to Date
Enumerate objectives
Define principles
Provide strategies
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

16. © 2010 University of California, Irvine – André van der Hoek
Approaches to Date
Enumerate objectives
overall process
overall design
individual classes
Define principles
Provide strategies
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

17. Objectives for Overall Process
Apply rigor
Separate concerns
modularize
abstract
Anticipate change
Generalize
Work incrementally
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

18. 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)
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

19. Objectives for Class Design
Cohesion
Completeness
Convenience
Clarity
Consistency
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

20. © 2010 University of California, Irvine – André van der Hoek
Approaches to Date
Enumerate objectives
Define principles
keep it simple, stupid! (KISS)
information hiding
acyclic dependencies …
Provide strategies
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

21. 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
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

22. © 2010 University of California, Irvine – André van der Hoek
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
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

23. © 2010 University of California, Irvine – André van der Hoek
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)
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

24. © 2010 University of California, Irvine – André van der Hoek
Approaches to Date
Enumerate objectives
Define principles
Provide strategies
program to the interface
refactor
apply software patterns
use aspects
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

25. Program to the Interface
Program to an interface, never directly to an implementation
Always wrap a class in an interface
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

26. © 2010 University of California, Irvine – André van der Hoek
Refactor
(to be discussed in future lectures)
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

27. Apply Software Patterns
(to be discussed in future lectures)
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

28. © 2010 University of California, Irvine – André van der Hoek
Use Aspects
(discussed in Informatics 102)
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

29. © 2010 University of California, Irvine – André van der Hoek
Approaches to Date
Enumerate objectives
Define principles
Provide strategies
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

30. 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, …
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

31. 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, …
The approaches to date help, but much more remains to be done
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

32. © 2010 University of California, Irvine – André van der Hoek
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
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

33. First Assignment: BeNumbered (Overview)
Your client reminisces about the game Bejeweled 2, wherein you switch pairs of jewels to try to create sequences of 3, 4, and 5 jewels, but wishes to experiment with more challenging rules
You are to create a UML, object-oriented design for a software implementation of a rough remake of Bejeweled 2, called BeNumbered
Bejeweled 2 Screenshot
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

34. First Assignment: BeNumbered (Rules)
The game takes place on a 8x8 grid, with each cell initially assigned a random number from 1 to 7
At each turn, the player chooses two adjacent cells (e.g., two vertically above each other or two horizontally next to each other)
the numbers in those cells are swapped only if the result makes a desired sequence of 3, 4, or 5 numbers in a row, either horizontally or vertically
(with some moves, it is possible to create more than one such sequence, sometimes even involving the same cell)
the cells containing the sequence(s) of numbers are emptied, and the numbers above it fall down, with new empty cells at the top of the grid filled in with new random numbers from 1 to 7
(this may produce new sequences that undergo the same treatment of being removed, triggering new numbers, etc.)
When a sequence of 4 is removed, a power number (equivalent in its behavior to the “power gem” in Bejeweled 2) is also inserted
When a sequence of 5 is removed, a magic number (equivalent in its behavior to the “hypercube” in Bejeweled 2) is also inserted
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

35. First Assignment: BeNumbered (Rules)
The game has two modes
in regular mode, a desired sequence is a linear sequence (e.g., 1-2-3, 4-3-2, )
in advanced mode, a desired sequence is any valid mathematical expression using + and –, with the last number being the outcome (e.g., 1+2=3, 4-2=2, =5)
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

36. First Assignment: BeNumbered (Rules)
Scoring is incremental:
the first sequence of 3 removed in a turn is worth 10 points, each sequence also removed in that turn is worth 10 more than the previous removed sequence
the first sequence of 4 removed in a turn is worth 25 points, each sequence also removed in that turn is worth 25 more than the previous removed sequence
the first sequence of 5 removed in a turn is worth 75 points, each sequence also removed in that turn is worth 75 more than the previous removed sequence
The game consists of three levels, each level ending when the player reaches 1,000 points
The player loses if no more swaps can be made
The player wins if they successfully complete all three levels
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

37. First Assignment: BeJeweled 2 (Inspiration)
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

38. First Assignment: BeNumbered (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 how levels differ, the exact randomizer used, or points for power and magic numbers, are up to you
The customer is not sure what will make the game challenging to them, and may demand different rules by which a sequence of numbers is removed, non-number obstacles of sorts, or other changes in the future
Point out that ogre movement can be done randomly if they like.
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

39. First Assignment: BeNumbered (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 12th, start of class
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek

40. First Assignment: Grading
Understandability
can someone pick it up and implement it?
Flexibility
can the design support future changes?
November 22, 2018 – 22:54:26
© 2010 University of California, Irvine – André van der Hoek