1. Informatics 122 Software Design II
Lecture 1 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 27, 2018 – 18:23:16
(c) 2007 University of California, Irvine – André van der Hoek

2. © 2007 University of California, Irvine – André van der Hoek
Today’s Lecture
Logistics
Review
Preview
Assignment 1
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

3. © 2007 University of California, Irvine – André van der Hoek
Logistics
Teaching Assistant: Kristina Winbladh
Book: “Design Patterns: Elements of Reusable Object-Oriented Software”
Grading:
No midterm, no final
Class participation is an important part
Team evaluations for group work
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

4. Review: Alternative Design Exercises
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

5. Review: The Term “Design”
“Design” may refer to an activity
“When I design, I always use a whiteboard first”
“Design” may refer to a product
“My design is super cool, I know it will work”
“Design” may refer to a field
“Software design is complex”
Should we include this? We don’t quite stick to it…
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

6. © 2007 University of California, Irvine – André van der Hoek
Design Fields Abound
There are countless design fields
Architecture design
Graphic design
Fashion design
Game design
Chip design
Car design
Instrument design
Product design …
But also
Law
Chemical synthesis
Process design
Study design …
And also
Writing
Painting
Sculpturing
Music composition
Physical versus “non-physical” versus “meta-physical” (not the right word)
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

7. Design Fields Abound And, of course, Software Design
There are countless design fields
Architecture design
Graphic design
Fashion design
Game design
Chip design
Car design
Instrument design
Product design …
But also
Law
Chemical synthesis
Process design
Study design …
And also
Writing
Painting
Sculpturing
Music composition
Physical versus “non-physical” versus “meta-physical” (not the right word)
And, of course, Software Design
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

8. © 2007 University of California, Irvine – André van der Hoek
The Design Product
C = conceivable
F = feasible D = desirable SP = still possible
design space C C C F D
outcome space SP D
designer
project
customer
A design product is a point in the design space that represents a set of decisions that together delineate a set of possible outcomes in the outcome space
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

9. © 2007 University of California, Irvine – André van der Hoek
The Design Process
activities
goals (languages)
knowledge (languages)
ideas (languages)
representations (languages)
tools
The design process is defined as the set of information manipulation activities through which a successful design is obtained
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

10. Some Important Design Theories
Pure thought
Reflective conversation with materials
Divergence, transformation, convergence
Team communication
Community building
Objectives, expectations, and success
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

11. Review: Informatics 121 (and thus 122!) View
System design
describes what the software system should do
“How do we fundamentally approach the problem?”
“What is desirable?”
typically represents an intermediate “design in progress”
architecture design can be part of system design
Implementation design
describes what the implementer should do
“How do we make the approach reality?”
“What is a feasible answer?”
typically represents a final “completed design”
module design can be part of implementation design
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

12. Review: Informatics 121 (and thus 122!) View
System design
describes what the software system should do
“How do we fundamentally approach the problem?”
“What is desirable?”
typically represents an intermediate “design in progress”
architecture design can be part of system design
Implementation design
describes what the implementer should do
“How do we make the approach reality?”
“What is a feasible answer?”
typically represents a final “completed design”
module design can be part of implementation design
Both are intertwined much more than the 121/122 split indicates
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

13. © 2007 University of California, Irvine – André van der Hoek
Review: Definitions
A system design is
problem solving
describing a desired outcome
aimed at customers, implementation designers, testers
An implementation design is
creating a roadmap
describing a path from the system design to the outcome
aimed at programmers, testers, feedback to system designer
Both require creativity, flexibility and design
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

14. Informatics 121 View of System Design
JSD …
text
informal drawing
UML
System Design
pseudo code
architecture
Highlighted are those that are underappreciated, perhaps worth drawing extra attention to
interface mockups
code
data flow diagrams
statecharts
use cases
any and all as needed
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

15. Review: System Design Concerns
A problem consists of many different concerns that must be addressed by a design solution
Some of these concerns are more important than others
“I want my e-commerce site to have a recognizable logo”
“My e-commerce site must scale to 1 million hits per minute”
Sometimes, the importance and/or impact of a concern is not obvious (the devil is in the details)
“I want my payroll software to properly handle the exchange rate”
As a designer, you need to find the concerns that are most important and have most impact
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

16. Transitioning From 121 to Informatics 122
To date, much of our focus has been on system design
creative thinking
learning to rely on colleagues
incomplete specifications
no implementation
Make sure we warn them that some coding is in order
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

17. Transitioning From 121 to Informatics 122
To date, much of our focus has been on system design
creative thinking
learning to rely on colleagues
incomplete specifications
no implementation
Now, it is time to turn our attention to implementation design
nuts and bolts (but still some creative thinking)
specifying for colleagues (but still relying on colleagues)
complete specifications
implementation
Make sure we warn them that some coding is in order
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

18. Transitioning From 121 to Informatics 122
To date, much of our focus has been on system design
creative thinking
learning to rely on colleagues
incomplete specifications
no implementation
Now, it is time to turn our attention to implementation design
nuts and bolts (but still some creative thinking)
specifying for colleagues (but still relying on colleagues)
complete specifications
implementation
Make sure we warn them that some coding is in order
Through discussion and practice we will learn:
What is a good software implementation design?
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

19. © 2007 University of California, Irvine – André van der Hoek
Rough Schedule
Create some designs
evaluate others’ designs
discuss those designs
implement those designs
Reverse engineer a large design
Design patterns
implementing design patterns
Software components
Large scale vs. small scale design
A final design (and implementation) project
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

20. First Assignment: Scrabble
You are to create a UML, object-oriented design for a software implementation of the game of Scrabble
The game should support two human players playing against each other
it is ok for one player to see the letters of another player (i.e., they both play using the same computer)
The game is not networked, nor web-based
You should assume simple textual in- and output (i.e., no need to design lots and lots of classes for a graphical user interface)
More information on Scrabble
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

21. First Assignment: Scrabble
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: Tuesday, October 2nd, beginning of class
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek

22. First Assignment: Grading
Understandability
can someone pick it up and implement it?
Flexibility
can the design support future changes?
November 27, 2018 – 18:23:16
© 2007 University of California, Irvine – André van der Hoek