1. Informatics 121 Software Design I
Lecture 6 André van der Hoek
Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.
January 16, 2019 – 21:33:07
(c) 2006 University of California, Irvine – André van der Hoek

2. © 2006 University of California, Irvine – André van der Hoek
Today’s Lecture
Software design
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

3. When Does Design Take Place?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

4. When Does Design Take Place?
For a graphic designer?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

5. When Does Design Take Place?
For a graphic designer?
For a product designer?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

6. When Does Design Take Place?
For a graphic designer?
For a product designer?
For an architect?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

7. When Does Design Take Place?
For a graphic designer?
For a product designer?
For an architect?
For a lawyer?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

8. When Does Design Take Place?
For a graphic designer?
For a product designer?
For an architect?
For a lawyer?
For a musician?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

9. When Does Design Take Place?
For a graphic designer?
For a product designer?
For an architect?
For a lawyer?
For a musician?
For a painter?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

10. When Does Design Take Place?
For a graphic designer?
For a product designer?
For an architect?
For a lawyer?
For a musician?
For a painter?
For a game designer?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

11. When Does Design Take Place?
For a graphic designer?
For a product designer?
For an architect?
For a lawyer?
For a musician?
For a painter?
For a game designer?
For a novelist?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

12. When Does Design Take Place?
For a graphic designer?
For a product designer?
For an architect?
For a lawyer?
For a musician?
For a painter?
For a game designer?
For a novelist?
For a software engineer?
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

13. Positioning Software Design
Waterfall: once, in between requirements and implementation
“design is a phase”
Incremental: repeatedly, in between requirements and implementation
Prototyping: once, in between prototyping/requirements and implementation
Spiral: intermittently, when the risks being faced demand it
XP: all the time, when coding
“design is in the code” …
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

14. Requirements no of problems described no of designs possible
domain of requirements
domain of design
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

15. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

16. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
We do not want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

17. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
And we do not want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

18. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
We do want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

19. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
But we do not want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

20. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
We do want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

21. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
The reality is typically more like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

22. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
But this means: (1) the problem is not completely clear!
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

23. Requirements one problem one design some problems some designs
many problems
many designs
domain of requirements
domain of design
But this means: (2) some design decisions have already been made!
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

24. A Brief Example: WebDAV
“Distribution and replication are at the heart of the Internet. All WebDAV extensions should be designed to allow for distribution and replication. Version trees should be able to be split across multiple servers. Collections may have members on different servers. Any resource may be cached or replicated for mobile computing or other reasons. Consequently, the WebDAV extensions must be able to operate in a distributed, replicated environment.”
“The WebDAV extensions should keep to a minimum the number of interactions between the client and the server needed to perform common functions. For example, publishing a document to the Web will often mean publishing content together with related properties. A client may often need to find out what version graph a particular resource belongs to, or to find out which resource in a version graph is the published one. The extensions should make it possible to do these things efficiently.”
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

25. A Brief Example: WebDAV
“Distribution and replication are at the heart of the Internet. All WebDAV extensions should be designed to allow for distribution and replication. Version trees should be able to be split across multiple servers. Collections may have members on different servers. Any resource may be cached or replicated for mobile computing or other reasons. Consequently, the WebDAV extensions must be able to operate in a distributed, replicated environment.”
“The WebDAV extensions should keep to a minimum the number of interactions between the client and the server needed to perform common functions. For example, publishing a document to the Web will often mean publishing content together with related properties. A client may often need to find out what version graph a particular resource belongs to, or to find out which resource in a version graph is the published one. The extensions should make it possible to do these things efficiently.”
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

26. © 2006 University of California, Irvine – André van der Hoek
A Brief Example: ATM
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

27. © 2006 University of California, Irvine – André van der Hoek
A Brief Example: ATM
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

28. Implementation no of designs described no of implementations possible
domain of design
domain of implementation
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

29. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

30. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
We do not want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

31. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
And we do not want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

32. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
We do want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

33. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
We do not want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

34. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
We do want it like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

35. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
The reality is typically more like this
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

36. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
But this means: (1) the design is not completely clear!
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

37. Implementation one design one implementation some designs
some implementations
many designs
many implementations
domain of design
domain of implementation
But this means: (2) some implementation “design” decisions have been made!
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

38. © 2006 University of California, Irvine – André van der Hoek
A Brief Example: SOAP
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

39. A Brief Example: PHP MYSQL
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

40. Positioning Software Design
Waterfall: once, in between requirements and implementation
“design is a phase”
Incremental: repeatedly, in between requirements and implementation
Prototyping: once, in between prototyping/requirements and implementation
Spiral: intermittently, when the risks being faced demand it
XP: all the time, when coding
“design is in the code” …
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

41. Positioning Software Design – Informatics 121
Informatics 121: all the time, in many phases
“design is design”
in other words, do not try to pigeonhole the activity nor the artifact
We must:
stay true to ourselves
recognize when we design
recognize the form of design
adopt the activity and representation best fitting the form of design
use the Design Diamond to properly practice design
regardless of what our colleagues say
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

42. Design All The Time, in Many Phases – Bad?
Yes
many will argue against this view of design
the discipline of software engineering currently has few established mechanisms to support this view of design No
software engineering is a design discipline
attempting to squish design into one phase or one kind of artifact is unduly limiting design and our ability to be effective software engineers
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

43. © 2006 University of California, Irvine – André van der Hoek
Design Diamond
Domain of Materials
Domain of Use
Knowledge
Representation
Ideas
Activity
concern
manipulates
informs
Goal
captures
enhances
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

44. © 2006 University of California, Irvine – André van der Hoek
Goal – Software
Objectives that frame a design problem
Vague versus precise
Rigid versus flexible
Singular versus composed of multiple subgoals
Explicitly written down versus hidden in unstated expectations
Driven by external parties versus set by the software designer themselves
Examples
requirements document
“today, I am going to improve the software and make it faster”
customer Joe’s hidden taste of bold colors and layouts when it comes to user interfaces
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

45. © 2006 University of California, Irvine – André van der Hoek
Ideas – Software
Individual understanding of a design problem and its solution
Ideas can be vague intuitions, firm decisions, relations among ideas, thoughts on possible directions, rationale, preferences, facts, recall of previously-visited alternatives, …
Sometimes, one idea can make a big difference – a good metaphor, for instance
Examples
“we should use a pipe and filter architecture on this project”
“that proposed solution will not scale up”
“the customer said this, but from user studies I know that it is not quite true”
other, more abstract mental images of the program’s eventual operation
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

46. Representation – Software
Expression of an understanding of a design problem and its solution
A choice of expression depends a lot on its purpose:
individual exploration, team communication, handing off a design to someone else, …
The ways in which a given set of ideas can be expressed and later implemented vary greatly depending on the design notation chosen and the amount of detail needed
a sketch, a memo, a diagram, a whiteboard drawing, a narrative, a sequence chart, a spoken conversation, …
Examples
UML, software architecture, code (in extreme programming), Statecharts, formal languages, and many informal sketches and drawings
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

47. © 2006 University of California, Irvine – André van der Hoek
Activity – Software
Acts that contribute to the crafting of a design solution to a design problem
A choice of action depends a lot on its purpose
individual exploration, team communication, handing off a design to someone else, …
Not every action directly results in a design artifact; many actions are peripheral and serve to prepare the designer for other, more concrete, tasks
Examples
creating a UML class diagram, evaluating a prototype, starting over, sitting and pondering, generating alternatives, performing research in the problem domain, …
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

48. © 2006 University of California, Irvine – André van der Hoek
Knowledge – Software
Individual wisdom about design problems and their solutions
Knowledge is vital to any software design project
if you do not have (all of) it, get someone involved who does
A particularly thorny issue is that what one must know shifts rapidly
model-driven architecture, Ajax, web services, software factories, …
Examples
familiarity with some architectural style
the experience of designing multiple large databases and the intangible intuitions and insights that come with that experience
knowing that a certain design structure is suitable for software that needs to be highly reliable
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

49. Domain of Use – Software
Collective wisdom about design problems and their solutions
This collective wisdom is generally not reported in “raw”
form, but typically is summarized, coalesced, and organized
in books, catalogues, standards, educational materials, conferences,
The Domain of Use also reflects itself in the Domain of Materials, as new abstractions are created that codify particular uses
Examples
the OSI seven layer network model
the Design Patterns book
numerous, collected rules to keep in mind when designing user interfaces
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

50. Domain of Materials – Software
Collective wisdom about the general resources available to implement design solutions
We must consider the available resources for implementing a design
programming languages, web protocols and standard tools, user interface generators, databases, …
Resources include different classes of programmers
Expert, amateur, novice, …
Examples
C is fast and compact
C++ is object-oriented
Expert programmers do not need a fully detailed class diagram
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

51. © 2006 University of California, Irvine – André van der Hoek
To Summarize
We will recognize that design takes place all the time, during many phases of the software lifecycle
sometimes more, sometimes less
sometimes in one form, sometimes in another
We will recognize the role of the Design Diamond
understand limitations involved in a particular design exercise
exploit possibilities present in a particular design exercise
We will recognize and exploit the role of design theories
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

52. © 2006 University of California, Irvine – André van der Hoek
Fifth Assignment
Design a novel Google Maps application
Bring your design on a poster to class
design is a goal
Tuesday, April 25
design is a revised high-level goal and a high-level architecture
Thursday, April 27
design is a revised high-level goal and revised high-level architecture
Tuesday, May 9
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

53. © 2006 University of California, Irvine – André van der Hoek
Fifth Assignment
We will organize the class as a design studio
everyone will look at everyone else’s poster
provide suggestions
provide constructive criticism
individuals are to take notes of the suggestions and criticism, and to use the notes in subsequent revisions
Helpful resources
maps.google.com
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

54. © 2006 University of California, Irvine – André van der Hoek
Fifth Assignment
Tuesday, April 25
clearly articulate the goal of your design
establish a domain of materials and domain of use
illustrate the design process you followed (divergence)
Thursday, April 27
clearly summarize the goal of your design
clearly articulate the high-level architecture of your design
use appropriate representations and activities
illustrate the design process you followed (transformation)
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek

55. © 2006 University of California, Irvine – André van der Hoek
Fifth Assignment
Tuesday, May 9
clearly summarize the goal of your design
clearly articulate the high-level architecture of your design
use appropriate representations and activities
illustrate the design process that you followed (convergence)
And remember…
…you will not have to implement your design
…but you will have to provide a plausible high-level architecture
…the application should be novel
January 16, 2019 – 21:33:07
© 2006 University of California, Irvine – André van der Hoek