Informatics 122 Software Design II Lecture 2 André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Today’s Lecture Design aesthetics Assignment 1 continued May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Aesthetics “a particular theory or conception of beauty or art : a particular taste for or approach to what is pleasing to the senses and especially sight” [Merriam-Webster] May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Design Aesthetics What makes a given software design “beautiful”? What is it that makes someone appreciate a particular software design? What are the qualities that determine whether a particular software design is “good” or “bad”? What is it, then, that we can strive for in creating a software design that will help others in appreciating it? May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Design Aesthetics Some brainstorming… May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Design Aesthetics Different people will have a different aesthetic appreciation of different designs as informed by their own, pre-existing knowledge as informed by their own understanding of the design goals as informed by their own ideas Different roles in the software development project may have different aesthetic appreciation of different designs coder software performance engineer software maintenance specialist software tester … May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Design Aesthetics Subjective, as it should be activities goals (langs) knowledge (langs) ideas (langs) tools goals (langs) representations (langs) May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Design Aesthetics Subjective, as it should be But we need some kind of shared “language”, some common touchstones that we can use to: understand the underlying implications of certain designs understand the intentions of designers effectively frame our communication about designs I think all 3 of these are very important points actually, perhaps worth of their own slides? May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Shared Design Aesthetics Individual Project Organization Nice! School of Thought Community May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek But… …what kind of shared understandings exist? …where do these shared understandings come from? May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Purpose of Implementation Design An implementation design is a road map An implementation design describes a path from system design to the outcome An implementation design describes what the implementers should do An implementation design is a guide towards future change May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Purpose of Implementation Design An implementation design is a road map understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change evolvable, … May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

More of a Shared Understanding (Not Perfect!) An implementation design is a road map understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change evolvable, … May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Less of a Shared Understanding An implementation design is a road map understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change evolvable, … May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Approaches to Date Enumerate objectives Define principles Provide strategies May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Approaches to Date Enumerate objectives overall process overall design individual classes Define principles Provide strategies May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Objectives for Overall Process Apply rigor Separate concerns modularize abstract Anticipate change Generalize Work incrementally May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Objectives for Overall Design Strive for grouping related functionality (high cohesion) Strive for ungrouping semi-related functionality (high cohesion) Strive for reducing interdependency (low coupling) May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Objectives for Class Design Cohesion Completeness Convenience Clarity Consistency May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Approaches to Date Enumerate objectives Define principles keep it simple, stupid! (KISS) information hiding acyclic dependencies … Provide strategies May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Keep It Simple, Stupid! (KISS) Nothing should be more complicated than absolutely essential and, even then, everything should be analyzed as to whether it can be done simpler May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Information Hiding Hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Acyclic Dependencies Structure packages (grouping classes and interfaces) of a software system in such a manner that the dependencies among them form a directed acyclic graph (DAG) May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Approaches to Date Enumerate objectives Define principles Provide strategies program to the interface refactor apply software patterns use aspects May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Program to the Interface Program to an interface, never directly to an implementation Always wrap a class in an interface May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Refactor (to be discussed) May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Apply Software Patterns (to be discussed) May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Use Aspects (discussed in Informatics 102) May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Approaches to Date Enumerate objectives Define principles Provide strategies May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Purpose of Implementation Design An implementation design is a road map understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change evolvable, … May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

Purpose of Implementation Design An implementation design is a road map understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change evolvable, … The approaches to date help, but much more remains to be done May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

© 2007 University of California, Irvine – André van der Hoek Why Aesthetics? Aesthetics aims higher than “usable” or “complete” or … It aims to set a bar for design for which we as professional designers should strive designs that are elegant designs that communicate their intent seamlessly designs that overall exude an air of sophistication that sets them apart from ordinary designs May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

First Assignment Continued: Scrabble You are to update your UML, object-oriented design for a software implementation of the game of Scrabble based on what you learned in class today, as you see fit You should particularly pay attention that it will be others who will be reading and interpreting your design, and that you will not be able to clarify in person May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

First Assignment Continued: 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 six printed copies of your design to class Due: Thursday, October 4th, beginning of class May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek

First Assignment Continued: Grading Completeness does your design provide an entire skeleton for the implementation? in other words, does the implementer need to fill in any blanks or make any changes to classes, class interfaces, or associations? Understandability can someone pick it up and implement it? Flexibility can the design support future changes? May 1, 2019 – 09:29:24 © 2007 University of California, Irvine – André van der Hoek