© 2010 University of California, Irvine – André van der Hoek1June 14, 2015 – 15:24:35 Informatics 121 Software Design I Lecture 11 André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

Today’s Lecture Design rationale In-class design exercise © 2010 University of California, Irvine – André van der Hoek2June 14, 2015 – 15:24:35

A Simple Question Why is a given design as it is? © 2010 University of California, Irvine – André van der Hoek3June 14, 2015 – 15:24:35

A Difficult Answer Any design involves 100s if not 1000s of decisions that are tough to all remember Worse yet, any design involves 100s if not 1000s of discussions, considerations of alternatives, and reasons why certain choices are made, which are even tougher to all remember © 2010 University of California, Irvine – André van der Hoek4June 14, 2015 – 15:24:35

A Difficult Answer Any design involves 100s if not 1000s of decisions that are tough to all remember Worse yet, any design involves 100s if not 1000s of discussions, considerations of alternatives, and reasons why certain choices are made, which are even tougher to all remember Especially three months later, a year later, two years later… © 2010 University of California, Irvine – André van der Hoek5June 14, 2015 – 15:24:35

Knowing Why Is A Crucial Need Helps explain particular features to the customer Helps assist with coding Helps build a shared understanding of the design among a team of designers Helps guide maintenance and other design changes –evolution –roadblocks Helps reflect on one’s own design practices © 2010 University of California, Irvine – André van der Hoek6June 14, 2015 – 15:24:35

Sketchbooks © 2010 University of California, Irvine – André van der Hoek7June 14, 2015 – 15:24:35

Sketchbooks © 2010 University of California, Irvine – André van der Hoek8June 14, 2015 – 15:24:35

Sketchbooks © 2010 University of California, Irvine – André van der Hoek9June 14, 2015 – 15:24:35

Software “Sketchbooks” If they exist, they tend to be text, text, text, text, text, and the occasional picture of a whiteboard… Maybe an architecture diagram Maybe a UML diagram … © 2010 University of California, Irvine – André van der Hoek10June 14, 2015 – 15:24:35

Design Decisions Explicitly recognizing design decisions helps in documenting the “design space”, and at least articulating the available choices Some of your homeworks even discuss tradeoffs, and motivate the choices you make for your final design –though typically ignoring any intermediate decisions that may have been made to which you later may need to return The actual rationale, though, tends to be quite small in comparison to design decisions –and reconstructing it is difficult © 2010 University of California, Irvine – André van der Hoek11June 14, 2015 – 15:24:35

An Example © 2010 University of California, Irvine – André van der Hoek12June 14, 2015 – 15:24:35

Design Rationale Design rationale is focused on capturing a historical record of the analysis that led to the choice of a particular artifact or feature in question, and in the most general sense is an explanation of why something is designed the way it is Design rationale involves explicit capture of the design decisions that shaped a particular software system and the reasons for those decisions (‘know-why’ knowledge) © 2010 University of California, Irvine – André van der Hoek13June 14, 2015 – 15:24:35

Design Rationale Descriptive –retroactive –aims to communicate a design’s intent Prescriptive –in-the-moment –aims to improve the design process © 2010 University of California, Irvine – André van der Hoek14June 14, 2015 – 15:24:35

IBIS © 2010 University of California, Irvine – André van der Hoek15June 14, 2015 – 15:24:35

gIBIS © 2010 University of California, Irvine – André van der Hoek16June 14, 2015 – 15:24:35

Modern Variant © 2010 University of California, Irvine – André van der Hoek17June 14, 2015 – 15:24:35

Design Histories Expand on design rationale by capturing design processes as they occur over time, as most design does not take place in a single meeting More focused on description than prescription to date © 2010 University of California, Irvine – André van der Hoek18June 14, 2015 – 15:24:35

ADDSS © 2010 University of California, Irvine – André van der Hoek19June 14, 2015 – 15:24:35

Alex’ Homegrown © 2010 University of California, Irvine – André van der Hoek20June 14, 2015 – 15:24:35

In-Class Design Exercise Collectively, using the tablets and Calico, design a history representation that you could have used for the previous assignment (or use for the next assignment) Use your tablets to support your verbal contributions, annotate our design in progress, develop another idea in parallel, etc. Remember stakeholders, goals, audience, uses, … Remember techniques and notations available © 2010 University of California, Irvine – André van der Hoek21June 14, 2015 – 15:24:35