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.
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
1
Today’s Lecture
 Design aesthetics
 Assignment 1
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
2
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]
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
3
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?
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
4
Design Aesthetics
 Some brainstorming…
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
5
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
–
–
–
–
–
March 17, 2016 – 19:36:06
coder
software performance engineer
software maintenance specialist
software tester
…
© 2009 University of California, Irvine – André van der Hoek
6
Design Aesthetics
 Subjective, as it should be
goals (langs)
knowledge (langs)
knowledge (langs)
activities
activities
tools
ideas (langs)
March 17, 2016 – 19:36:06
goals (langs)
tools
representations (langs)
© 2009 University of California, Irvine – André van der Hoek
ideas (langs)
7
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
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
8
Shared Design Aesthetics
Individual
Project
Organization
School of Thought
Community
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
9
But…
 …what kind of shared understandings exist?
 …where do these shared understandings come from?
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
10
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
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
11
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, …
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
12
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, …
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
13
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, …
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
14
Approaches to Date
 Enumerate objectives
 Define principles
 Provide strategies
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
15
Approaches to Date
 Enumerate objectives
– overall process
– overall design
– individual classes
 Define principles
 Provide strategies
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
16
Objectives for Overall Process
 Apply rigor
 Separate concerns
– modularize
– abstract
 Anticipate change
 Generalize
 Work incrementally
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
17
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)
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
18
Objectives for Class Design
 Cohesion
 Completeness
 Convenience
 Clarity
 Consistency
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
19
Approaches to Date
 Enumerate objectives
 Define principles
– keep it simple, stupid! (KISS)
– information hiding
– acyclic dependencies
– …
 Provide strategies
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
20
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
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
21
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
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
22
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)
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
23
Approaches to Date
 Enumerate objectives
 Define principles
 Provide strategies
– program to the interface
– refactor
– apply software patterns
– use aspects
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
24
Program to the Interface
 Program to an interface, never directly to an implementation
 Always wrap a class in an interface
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
25
Refactor
 (to be discussed in future lectures)
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
26
Apply Software Patterns
 (to be discussed in future lectures)
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
27
Use Aspects
 (discussed in Informatics 102)
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
28
Approaches to Date
 Enumerate objectives
 Define principles
 Provide strategies
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
29
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, …
March 17, 2016 – 19:36:06
© 2009 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 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
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
31
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
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
32
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
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
33
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.
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
34
First Assignment: Ogre (Examples)
P
P
P
March 17, 2016 – 19:36:06
P
P
O
P
P
O
P
P
S
P
P
S
P
© 2009 University of California, Irvine – André van der Hoek
O
S
35
First Assignment: Ogre (Video)
 http://www.youtube.com/watch?v=gtDq0EGSDSg
March 17, 2016 – 19:36:06
© 2007 University of California, Irvine – André van der Hoek
36
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.
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
37
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 12th, start of class
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
38
First Assignment: Grading
 Understandability
– can someone pick it up and implement it?
 Flexibility
– can the design support future changes?
March 17, 2016 – 19:36:06
© 2009 University of California, Irvine – André van der Hoek
39