Informatics 122 Software Design II - PowerPoint PPT Presentation

About This Presentation
Title:

Informatics 122 Software Design II

Description:

Informatics 122 Software Design II Lecture 6 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission of the ... – PowerPoint PPT presentation

Number of Views:72
Avg rating:3.0/5.0
Slides: 18
Provided by: Andrv153
Learn more at: https://ics.uci.edu
Category:

less

Transcript and Presenter's Notes

Title: Informatics 122 Software Design II


1
Informatics 122Software Design II
  • Lecture 6Emily Navarro
  • Duplication of course material for any commercial
    purpose without the explicit written permission
    of the professor is prohibited.

2
Todays Lecture
  • Design aesthetics
  • Your BeNumbered designs

3
But first A Few Updates about Assignment 2
  • Deadline extended to Tuesday, February 4
  • Remember, no real GUI is required
  • But you should show the intermediate boards
  • after each sequence is removed but before the
    spaces are filled in with random numbers
  • and after the spaces are filled in with random
    numbers

4
Design Aesthetics
  • What makes a given software implementation design
    beautiful?
  • What is it that makes someone appreciate a
    particular software implementation design?
  • What are the qualities that determine whether a
    particular software implementation design is
    good or bad?
  • What is it, then, that we can strive for in
    creating a software implementation design that
    will help others in appreciating it?

5
Purpose of Implementation Design
  • An implementation design is a road map
  • An implementation design describes a path from
    application / interaction / architecture design
    to the product
  • An implementation design describes what the
    implementers should do
  • An implementation design is a guide towards
    future change

6
Purpose of Implementation Design
  • An implementation design is a road map
  • understandable, unambiguous, consistent, helpful,
  • uses a good naming schema
  • An implementation design describes a path from
    application / interaction / architecture design
    to the product
  • correct, complete, concise, verifiable,
    effective,
  • attention to detail, well-documented, has clear
    flow, has a clear layout, has a clear interaction
    between classes, uses UML syntax correctly
  • An implementation design describes what the
    implementers should do
  • elegant, partitionable, recomposable, resilient,
  • An implementation design is a guide towards
    future change
  • evolvable,

7
Less of a Shared Understanding
  • An implementation design is a road map
  • understandable, unambiguous, consistent, helpful,
  • uses a good naming schema
  • An implementation design describes a path from
    application / interaction / architecture design
    to the product
  • correct, complete, concise, verifiable,
    effective,
  • attention to detail, well-documented, has clear
    flow, has a clear layout, has a clear interaction
    between classes, uses UML syntax correctly
  • An implementation design describes what the
    implementers should do
  • elegant, partitionable, recomposable, resilient,
  • An implementation design is a guide towards
    future change
  • evolvable,

8
Some 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

9
Designs Rated Highly By Peers
  • 20
  • 10
  • 1
  • 25
  • 21

10
Some Obvious Room for Improvement
  • 15
  • 11
  • 6
  • 19
  • 7

11
Important Points to Observe (Assignment)
  • Being a 1 or a 5 on someones ranking is not
    an absolute evaluation
  • if you are a 1 on someones ranking, the other
    designs may have all been relatively poor
  • if you are a 5 on someones ranking, the other
    designs may have all been relatively stellar
  • Length of the document may be an indicator in
    peers rankings, but not necessarily in ours
  • It is easier to review than to design, or is it?

12
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

13
Important Points to Observe (Process)
  • Where to start?
  • what about with the set of nouns in the
    description of the problem (e.g., grid, cell,
    sequence, flame number, )
  • what about with the set of verbs in the
    description of the problem (e.g., chooses
    adjacent cells, cells are swapped, cells are
    emptied )
  • 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

14
A Checklist for the Overall Process
  • Apply rigor
  • Separate concerns
  • modularize
  • abstract
  • Anticipate change
  • Generalize
  • Work incrementally

15
A 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)

16
A Checklist on Class Design
  • Cohesion
  • Completeness
  • Convenience
  • Clarity
  • Consistency

17
A Checklist on Principles and Strategies
  • Principles
  • keep it simple, stupid! (KISS)
  • information hiding
  • acyclic dependencies
  • Strategies
  • program to the interface
  • refactor
  • apply software patterns
Write a Comment
User Comments (0)
About PowerShow.com