© 2009 University of California, Irvine – André van der Hoek 1February 8, 2009 – 21:49:30

Informatics 122Software Design II

Lecture 9

André van der Hoek & Alex Baker

Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

© 2009 University of California, Irvine – André van der Hoek 2February 8, 2009 – 21:49:30

Palantír Design Recovery – Debriefing

How difficult was this? Why?

© 2009 University of California, Irvine – André van der Hoek 3February 8, 2009 – 21:49:30

Palantír Design Recovery – Debriefing

How difficult was this? Why?

More or less difficult than it seemed when you first looked at the code?

© 2009 University of California, Irvine – André van der Hoek 4February 8, 2009 – 21:49:30

Palantír Design Recovery – Debriefing

What strategies did you use?

© 2009 University of California, Irvine – André van der Hoek 5February 8, 2009 – 21:49:30

Palantír Design Recovery – Debriefing

What strategies did you use?

Did you…– …run the program (frequently?)– …seek Palantír documentation?– …seek DependencyFinder documentation?– …use any external tools?– …use Eclipse’s search features?– …read code?– …

– Did you manage to cover all of the code?

© 2009 University of California, Irvine – André van der Hoek 6February 8, 2009 – 21:49:30

Palantír Design Recovery – Debriefing

Did you need to make any assumptions that guided your explorations?

Did those assumptions hold throughout?

© 2009 University of California, Irvine – André van der Hoek 7February 8, 2009 – 21:49:30

The Design of Palantír

How does Palantír work?– a basic architecture

– how does it know about user actions?

– what is its relationship to Eclipse?

– what is its relationship to DependencyFinder?

© 2009 University of California, Irvine – André van der Hoek 8February 8, 2009 – 21:49:30

The Design of Palantír

How does Palantír work?– a basic architecture

– how does it know about user actions?

– what is its relationship to Eclipse?

– what is its relationship to DependencyFinder?

Did you have a breakthrough “a-ha” moment in gaining this understanding?

© 2009 University of California, Irvine – André van der Hoek 9February 8, 2009 – 21:49:30

The Design of Palantír

What are the major design decisions behind Palantír?

© 2009 University of California, Irvine – André van der Hoek 10February 8, 2009 – 21:49:30

The Design of Palantír

What are the major design decisions behind Palantír?

How do you know?

© 2009 University of California, Irvine – André van der Hoek 11February 8, 2009 – 21:49:30

The Design of Palantír

What are the major design decisions behind Palantír?

How do you know?

How confident are you that you know?

© 2009 University of California, Irvine – André van der Hoek 12February 8, 2009 – 21:49:30

Design Critique

Was the design easy to understand?– why?– why not?

© 2009 University of California, Irvine – André van der Hoek 13February 8, 2009 – 21:49:30

Design Critique

Was the design easy to understand?– why?– why not?

How did naming, package structures, and comments help or hurt understandability?

Was it consistent in its organization?

© 2009 University of California, Irvine – André van der Hoek 14February 8, 2009 – 21:49:30

Design Critique

How changeable is Palantír?

Would you easily be able to, for example, …– …add a new event?– …allow for other analyses?– …add a new visualization?– …overlay design deviations?– …

How easily?

© 2009 University of California, Irvine – André van der Hoek 15February 8, 2009 – 21:49:30

Design Critique

What was the impact of using Eclipse?

– positive?

– negative?

© 2009 University of California, Irvine – André van der Hoek 16February 8, 2009 – 21:49:30

Design Critique

Do you think Palantír is well-designed?

What is its biggest failing, and why?

What would you change about its approach?

© 2009 University of California, Irvine – André van der Hoek 17February 8, 2009 – 21:49:30

The Nature of Software Makes This Difficult

Invisibility– we cannot see the designer’s high level picture, obscured

in code details Complexity

– if users want a program to do 30 different things, then the program must do those 30 different things

– can this be done elegantly? Conformity

– Eclipse, DependencyFinder, the ways people make changes – all are invisible forces on the way the design is structured

Changeability– the Palantír code you see has been changed, can cause

problems[Brooks: No Silver Bullet]

© 2009 University of California, Irvine – André van der Hoek 18February 8, 2009 – 21:49:30

Some Theory

Design recovery is a matter of finding the ideas hidden in a bunch of code

The implementer has some responsibility, code can ruin a good design

Metaphor, architecture, organization, naming, and program flow design can go a long way to controlling and communicating this

© 2009 University of California, Irvine – André van der Hoek 19February 8, 2009 – 21:49:30

Feedback

Did you learn about software design from this?– how understandable are your designs?– what plays into understandability?

How did the team dynamic help or hinder your work?

© 2009 University of California, Irvine – André van der Hoek 20February 8, 2009 – 21:49:30

Assignment 4 – Design Patterns

Improve the design of Palantír by replacing existing structures in the UML model with appropriate patterns– start with any of the designs available to your group

You should apply at least 5 different design patterns– at least two not discussed in class

Each use of a pattern should be carefully motivated in a brief accompanying document

© 2009 University of California, Irvine – André van der Hoek 21February 8, 2009 – 21:49:30

Assignment 4 – Design Patterns

Each group must turn in:– the original UML diagram from which you started– a new UML diagram, with each pattern precisely highlighted as

to where it resides in the UML diagram– a document describing

the motivation for each pattern the impact the application of the pattern has on the original design

(i.e., how far reaching is the change to incorporate the pattern?)– graded on usefulness of the pattern, diversity of patterns,

rationale, and level of design understanding

Each person also needs to submit a team evaluation (new forms available on class webpage)

E-mail copy due Monday, February 21st, 4pm– e-mail to André, Alex, and Kyle

© 2009 University of California, Irvine – André van der Hoek 22February 8, 2009 – 21:49:30

Further Tips

Read the book

Discuss the patterns with each other

Imagine possible changes against which you would like to insulate

Try different parts of the code

Use the UML

© 2009 University of California, Irvine – André van der Hoek 23February 8, 2009 – 21:49:30

Team AssignmentsTeam 1 Tomas Ruiz-Lopez Lance Zepeda Matt Fritz Scott Roeder Leslie Liu

Team 2 Lance Cacho Robert Jolly Alton Chislom Alexander Doan Alex Kaiser

Team 3 Daniel Morgan Aylwin Villanueva Robert Duncan Jordan Sinclair Chad Curtis

Team 4 Scott Ditch Jay Bacuetes James Rose Rakesh Rajput Ben Kahn

Team 5 Joshua Villamarzo James Milewski Jeffrey Gaskill Matt Shigekawa David Schramm Derek Lee