View
212
Download
0
Tags:
Embed Size (px)
Citation preview
© 2009 University of California, Irvine – André van der Hoek 1April 18, 2023 – 21:10:42
Informatics 122Software Design II
Informatics 122Software Design II
Lecture 6
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 2April 18, 2023 – 21:10:42
Today’s LectureToday’s Lecture
Design aesthetics
Your Ogre designs
© 2009 University of California, Irvine – André van der Hoek 3April 18, 2023 – 21:10:42
Design AestheticsDesign 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?
© 2009 University of California, Irvine – André van der Hoek 4April 18, 2023 – 21:10:42
Purpose of Implementation DesignPurpose of Implementation Design
An implementation design is a road map
An implementation design describes a path from application design to the outcome
An implementation design describes what the implementers should do
An implementation design is a guide towards future change
© 2009 University of California, Irvine – André van der Hoek 5April 18, 2023 – 21:10:42
Purpose of Implementation DesignPurpose of Implementation Design
An implementation design is a road map– understandable, unambiguous, consistent, helpful, …
An implementation design describes a path from application 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, …
© 2009 University of California, Irvine – André van der Hoek 6April 18, 2023 – 21:10:42
Purpose of Implementation DesignPurpose 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, …
© 2009 University of California, Irvine – André van der Hoek 7April 18, 2023 – 21:10:42
Some CaveatsSome Caveats
We are going to be showing, praising, and critiquing your designs– not to ridicule, rather to provide constructive feedback
This is a normal part of any design studio class
Rules of the game– do not identify someone, even if you know whose design it is– someone may choose to volunteer and explain their design, but
they may also choose not to do so
We only highlight parts of certain designs, so please do not correlate our comments here with your final grade for this assignment
We only do this based on the UML diagram, not the text
Designs Rated Highly By PeersDesigns Rated Highly By Peers
© 2007 University of California, Irvine – André van der Hoek 8April 18, 2023 – 21:10:42
© 2009 University of California, Irvine – André van der Hoek 14April 18, 2023 – 21:10:43
What About This One?What About This One?
© 2009 University of California, Irvine – André van der Hoek 16April 18, 2023 – 21:10:44
Some “Obvious” Room for ImprovementSome “Obvious” Room for Improvement
© 2009 University of California, Irvine – André van der Hoek 21April 18, 2023 – 21:10:45
What About These?What About These?
Anybody Else ?Anybody Else ?
© 2007 University of California, Irvine – André van der Hoek 24April 18, 2023 – 21:10:46
© 2009 University of California, Irvine – André van der Hoek 25April 18, 2023 – 21:10:46
Important Points to Observe (Assignment)Important Points to Observe (Assignment)
Being a “1” or a “5” on someone’s ranking is not an absolute evaluation– if you are a “1” on someone’s ranking, the other designs
may have all been relatively poor– if you are a “5” on someone’s ranking, the other designs
may have all been relatively stellar
Length of the document seems to be an indicator in peer’s rankings, but not necessarily in ours
It is easier to review than to design
© 2009 University of California, Irvine – André van der Hoek 26April 18, 2023 – 21:10:46
Important Points to Observe (UML)Important Points to Observe (UML)
Having a document “heavy on UML” by itself is not a guarantee for a great design– it may indeed be more complete– it may also be less understandable
If we cannot find the “flow” in the UML diagram, something tends to be wrong – for some designs, we end up searching for their meaning– for others, it is clear from the diagram
physical layout, often, has something to do with this
Design languages are a factor– UML by itself is insufficient
© 2009 University of California, Irvine – André van der Hoek 27April 18, 2023 – 21:10:46
Important Points to Observe (Process)Important Points to Observe (Process)
Where to start?– what about with the set of nouns in the description of the
problem (e.g., word, rack, tile, board, …)– what about with the set of verbs in the description of the
problem (e.g., challenge, play, double, triple, …)
Work towards completeness– does my current design account for all possible features– does it do so explicitly, or are some features hidden
This is merely a rough and rules of thumb process, but one that tends to help the beginning designer
© 2009 University of California, Irvine – André van der Hoek 28April 18, 2023 – 21:10:46
A Checklist for the Overall ProcessA Checklist for the Overall Process
Apply rigor Separate concerns
– modularize– abstract
Anticipate change Generalize Work incrementally
© 2009 University of California, Irvine – André van der Hoek 29April 18, 2023 – 21:10:46
A Checklist for Overall DesignA Checklist for Overall Design
Strive for grouping related functionality (high cohesion) Strive for ungrouping semi-related functionality (high
cohesion) Strive for reducing interdependency (low coupling)
© 2009 University of California, Irvine – André van der Hoek 30April 18, 2023 – 21:10:46
A Checklist on Class DesignA Checklist on Class Design
Cohesion Completeness Convenience Clarity Consistency
© 2009 University of California, Irvine – André van der Hoek 31April 18, 2023 – 21:10:46
A Checklist on Principles and StrategiesA Checklist on Principles and Strategies
Principles– keep it simple, stupid! (KISS)– information hiding– acyclic dependencies– …
Strategies– program to the interface– refactor– apply software patterns– use aspects– …
© 2009 University of California, Irvine – André van der Hoek 32April 18, 2023 – 21:10:46
AppendixAppendix
For completeness, all of the designs are included in the following slides