Informatics 121 Software Design I Lecture 6 Andr

  • Slides: 55
Download presentation
Informatics 121 Software Design I Lecture 6 André van der Hoek Duplication of course

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. 25 September 2020 – 23: 02: 50 (c) 2006 University of California, Irvine – André van der Hoek 1

Today’s Lecture n Software design 25 September 2020 – 23: 02: 51 © 2006

Today’s Lecture n Software design 25 September 2020 – 23: 02: 51 © 2006 University of California, Irvine – André van der Hoek 2

When Does Design Take Place? 25 September 2020 – 23: 02: 51 © 2006

When Does Design Take Place? 25 September 2020 – 23: 02: 51 © 2006 University of California, Irvine – André van der Hoek 3

When Does Design Take Place? n For a graphic designer? 25 September 2020 –

When Does Design Take Place? n For a graphic designer? 25 September 2020 – 23: 02: 52 © 2006 University of California, Irvine – André van der Hoek 4

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? 25 September 2020 – 23: 02: 53 © 2006 University of California, Irvine – André van der Hoek 5

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? n For an architect? 25 September 2020 – 23: 02: 54 © 2006 University of California, Irvine – André van der Hoek 6

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? n For an architect? n For a lawyer? 25 September 2020 – 23: 02: 54 © 2006 University of California, Irvine – André van der Hoek 7

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? n For an architect? n For a lawyer? n For a musician? 25 September 2020 – 23: 02: 55 © 2006 University of California, Irvine – André van der Hoek 8

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? n For an architect? n For a lawyer? n For a musician? n For a painter? 25 September 2020 – 23: 02: 56 © 2006 University of California, Irvine – André van der Hoek 9

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? n For an architect? n For a lawyer? n For a musician? n For a painter? n For a game designer? 25 September 2020 – 23: 02: 56 © 2006 University of California, Irvine – André van der Hoek 10

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? n For an architect? n For a lawyer? n For a musician? n For a painter? n For a game designer? n For a novelist? 25 September 2020 – 23: 02: 57 © 2006 University of California, Irvine – André van der Hoek 11

When Does Design Take Place? n For a graphic designer? n For a product

When Does Design Take Place? n For a graphic designer? n For a product designer? n For an architect? n For a lawyer? n For a musician? n For a painter? n For a game designer? n For a novelist? n For a software engineer? 25 September 2020 – 23: 02: 58 © 2006 University of California, Irvine – André van der Hoek 12

Positioning Software Design n Waterfall: once, in between requirements and implementation – “design is

Positioning Software Design n Waterfall: once, in between requirements and implementation – “design is a phase” n Incremental: repeatedly, in between requirements and implementation – “design is a phase” n Prototyping: once, in between prototyping/requirements and implementation – “design is a phase” n Spiral: intermittently, when the risks being faced demand it – “design is a phase” n XP: all the time, when coding – “design is in the code” n … 25 September 2020 – 23: 02: 59 © 2006 University of California, Irvine – André van der Hoek 13

rib de sc ms ble pro no le sib os sp ign s de

rib de sc ms ble pro no le sib os sp ign s de of of no ed Requirements domain of requirements 25 September 2020 – 23: 01 domain of design © 2006 University of California, Irvine – André van der Hoek 14

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements 25 September 2020 – 23: 03 domain of design © 2006 University of California, Irvine – André van der Hoek 15

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design We do not want it like this 25 September 2020 – 23: 04 © 2006 University of California, Irvine – André van der Hoek 16

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design And we do not want it like this 25 September 2020 – 23: 03: 10 © 2006 University of California, Irvine – André van der Hoek 17

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design We do want it like this 25 September 2020 – 23: 03: 10 © 2006 University of California, Irvine – André van der Hoek 18

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design But we do not want it like this 25 September 2020 – 23: 03: 11 © 2006 University of California, Irvine – André van der Hoek 19

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design We do want it like this 25 September 2020 – 23: 03: 14 © 2006 University of California, Irvine – André van der Hoek 20

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design The reality is typically more like this 25 September 2020 – 23: 03: 15 © 2006 University of California, Irvine – André van der Hoek 21

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design But this means: (1) the problem is not completely clear! 25 September 2020 – 23: 03: 18 © 2006 University of California, Irvine – André van der Hoek 22

Requirements one problem some problems one design some designs many problems many designs domain

Requirements one problem some problems one design some designs many problems many designs domain of requirements domain of design But this means: (2) some design decisions have already been made! 25 September 2020 – 23: 03: 20 © 2006 University of California, Irvine – André van der Hoek 23

A Brief Example: Web. DAV n “Distribution and replication are at the heart of

A Brief Example: Web. DAV n “Distribution and replication are at the heart of the Internet. All Web. DAV 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 Web. DAV extensions must be able to operate in a distributed, replicated environment. ” n “The Web. DAV 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. ” 25 September 2020 – 23: 03: 31 © 2006 University of California, Irvine – André van der Hoek 24

A Brief Example: Web. DAV n “Distribution and replication are at the heart of

A Brief Example: Web. DAV n “Distribution and replication are at the heart of the Internet. All Web. DAV 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 Web. DAV extensions must be able to operate in a distributed, replicated environment. ” n “The Web. DAV 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. ” 25 September 2020 – 23: 03: 33 © 2006 University of California, Irvine – André van der Hoek 25

A Brief Example: ATM 25 September 2020 – 23: 03: 34 © 2006 University

A Brief Example: ATM 25 September 2020 – 23: 03: 34 © 2006 University of California, Irvine – André van der Hoek 26

A Brief Example: ATM 25 September 2020 – 23: 03: 36 © 2006 University

A Brief Example: ATM 25 September 2020 – 23: 03: 36 © 2006 University of California, Irvine – André van der Hoek 27

sc rib e de ns sig de sp ion tat en m ple le

sc rib e de ns sig de sp ion tat en m ple le sib no os of im of no d Implementation domain of design 25 September 2020 – 23: 03: 36 domain of implementation © 2006 University of California, Irvine – André van der Hoek 28

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design 25 September 2020 – 23: 03: 36 domain of implementation © 2006 University of California, Irvine – André van der Hoek 29

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation We do not want it like this 25 September 2020 – 23: 03: 41 © 2006 University of California, Irvine – André van der Hoek 30

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation And we do not want it like this 25 September 2020 – 23: 03: 42 © 2006 University of California, Irvine – André van der Hoek 31

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation We do want it like this 25 September 2020 – 23: 03: 44 © 2006 University of California, Irvine – André van der Hoek 32

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation We do not want it like this 25 September 2020 – 23: 03: 45 © 2006 University of California, Irvine – André van der Hoek 33

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation We do want it like this 25 September 2020 – 23: 03: 46 © 2006 University of California, Irvine – André van der Hoek 34

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation The reality is typically more like this 25 September 2020 – 23: 03: 46 © 2006 University of California, Irvine – André van der Hoek 35

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation But this means: (1) the design is not completely clear! 25 September 2020 – 23: 03: 47 © 2006 University of California, Irvine – André van der Hoek 36

Implementation one design some designs one implementation some implementations many designs many implementations domain

Implementation one design some designs one implementation some implementations many designs many implementations domain of design domain of implementation But this means: (2) some implementation “design” decisions have been made! 25 September 2020 – 23: 03: 49 © 2006 University of California, Irvine – André van der Hoek 37

A Brief Example: SOAP 25 September 2020 – 23: 03: 50 © 2006 University

A Brief Example: SOAP 25 September 2020 – 23: 03: 50 © 2006 University of California, Irvine – André van der Hoek 38

A Brief Example: PHP MYSQL 25 September 2020 – 23: 03: 54 © 2006

A Brief Example: PHP MYSQL 25 September 2020 – 23: 03: 54 © 2006 University of California, Irvine – André van der Hoek 39

Positioning Software Design n Waterfall: once, in between requirements and implementation – “design is

Positioning Software Design n Waterfall: once, in between requirements and implementation – “design is a phase” n Incremental: repeatedly, in between requirements and implementation – “design is a phase” n Prototyping: once, in between prototyping/requirements and implementation – “design is a phase” n Spiral: intermittently, when the risks being faced demand it – “design is a phase” n XP: all the time, when coding – “design is in the code” n … 25 September 2020 – 23: 03: 56 © 2006 University of California, Irvine – André van der Hoek 40

Positioning Software Design – Informatics 121 n Informatics 121: all the time, in many

Positioning Software Design – Informatics 121 n Informatics 121: all the time, in many phases – “design is design” – in other words, do not try to pigeonhole the activity nor the artifact n 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 25 September 2020 – 23: 03: 58 © 2006 University of California, Irvine – André van der Hoek 41

Design All The Time, in Many Phases – Bad? n Yes – many will

Design All The Time, in Many Phases – Bad? n 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 n 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 25 September 2020 – 23: 04: 00 © 2006 University of California, Irvine – André van der Hoek 42

Design Diamond Domain of Materials Domain of Use Representation Knowledge Ideas Activity Goal 25

Design Diamond Domain of Materials Domain of Use Representation Knowledge Ideas Activity Goal 25 September 2020 – 23: 04: 01 © 2006 University of California, Irvine – André van der Hoek concern manipulates informs captures enhances 43

Goal – Software n Objectives that frame a design problem n n n Vague

Goal – Software n Objectives that frame a design problem n n n 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 n 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 25 September 2020 – 23: 04: 03 © 2006 University of California, Irvine – André van der Hoek 44

Ideas – Software n Individual understanding of a design problem and its solution n

Ideas – Software n Individual understanding of a design problem and its solution n Ideas can be vague intuitions, firm decisions, relations among ideas, thoughts on possible directions, rationale, preferences, facts, recall of previously-visited alternatives, … n Sometimes, one idea can make a big difference – a good metaphor, for instance n 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 25 September 2020 – 23: 04: 03 © 2006 University of California, Irvine – André van der Hoek 45

Representation – Software n Expression of an understanding of a design problem and its

Representation – Software n Expression of an understanding of a design problem and its solution n A choice of expression depends a lot on its purpose: – individual exploration, team communication, handing off a design to someone else, … n 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, … n Examples – UML, software architecture, code (in extreme programming), Statecharts, formal languages, and many informal sketches and drawings 25 September 2020 – 23: 04 © 2006 University of California, Irvine – André van der Hoek 46

Activity – Software n Acts that contribute to the crafting of a design solution

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

Knowledge – Software n Individual wisdom about design problems and their solutions n Knowledge

Knowledge – Software n Individual wisdom about design problems and their solutions n Knowledge is vital to any software design project – if you do not have (all of) it, get someone involved who does n A particularly thorny issue is that what one must know shifts rapidly – model-driven architecture, Ajax, web services, software factories, … n 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 25 September 2020 – 23: 04: 06 © 2006 University of California, Irvine – André van der Hoek 48

Domain of Use – Software n Collective wisdom about design problems and their solutions

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

Domain of Materials – Software n Collective wisdom about the general resources available to

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

To Summarize 1. We will recognize that design takes place all the time, during

To Summarize 1. We will recognize that design takes place all the time, during many phases of the software lifecycle n sometimes more, sometimes less n sometimes in one form, sometimes in another 2. We will recognize the role of the Design Diamond n understand limitations involved in a particular design exercise n exploit possibilities present in a particular design exercise 3. We will recognize and exploit the role of design theories n understand limitations involved in a particular design exercise n exploit possibilities present in a particular design exercise 25 September 2020 – 23: 04: 08 © 2006 University of California, Irvine – André van der Hoek 51

Fifth Assignment n Design a novel Google Maps application n Bring your design on

Fifth Assignment n Design a novel Google Maps application n Bring your design on a poster to class – design is a goal – Tuesday, April 25 n Bring your design on a poster to class – design is a revised high-level goal and a high-level architecture – Thursday, April 27 n Bring your design on a poster to class – design is a revised high-level goal and revised high-level architecture – Tuesday, May 9 25 September 2020 – 23: 04: 10 © 2006 University of California, Irvine – André van der Hoek 52

Fifth Assignment n We will organize the class as a design studio – everyone

Fifth Assignment n 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 n Helpful resources – maps. google. com – www. google. com/apis/maps/ – http: //www. econym. demon. co. uk/googlemaps/ – http: //www. developer. com/java/web/article. php/10935_3528381_1 – http: //www. lifehacker. com/software/search-engines/google-mapapplications-roundup-111996. php 25 September 2020 – 23: 04: 11 © 2006 University of California, Irvine – André van der Hoek 53

Fifth Assignment n Tuesday, April 25 – clearly articulate the goal of your design

Fifth Assignment n 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) n 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) 25 September 2020 – 23: 04: 12 © 2006 University of California, Irvine – André van der Hoek 54

Fifth Assignment n Tuesday, May 9 – clearly summarize the goal of your design

Fifth Assignment n 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) n 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 25 September 2020 – 23: 04: 13 © 2006 University of California, Irvine – André van der Hoek 55