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

Slides:



Advertisements
Similar presentations
Informatics 122 Software Design II 1 Portions of the slides in this lecture are adapted from a/classes/5448/f12/lectures/
Advertisements

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 223 Applied Software Design Techniques.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 223 Applied Software Design Techniques.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 4 Duplication.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 8 Duplication.
MVC Nick Lopez Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.
Design patterns exercise Nick Lopez Duplication of course material for any commercial purpose without the explicit written permission of the professor.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 14.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Informatics 122 Software Design II Lecture 5 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
© 2010 University of California, Irvine – André van der Hoek1June 10, 2015 – 06:18:06 Informatics 121 Software Design I Lecture 10 André van der Hoek &
© 2009 University of California, Irvine – André van der Hoek1June 10, 2015 – 18:31:15 Informatics 122 Software Design II Lecture 2 André van der Hoek &
© 2009 University of California, Irvine – André van der Hoek1February 8, 2009 – 21:49:30 Informatics 122 Software Design II Lecture 9 André van der Hoek.
© 2010 University of California, Irvine – André van der Hoek1June 12, 2015 – 07:51:20 Informatics 121 Software Design I Lecture 8 André van der Hoek &
Week 2 Design Examples and Designing for Change Alex Baker.
© 2009 University of California, Irvine – André van der Hoek1June 13, 2015 – 18:19:12 Informatics 122 Software Design II Lecture 5 André van der Hoek &
(c) 2009 University of California, Irvine – André van der Hoek1June 13, 2015 – 21:42:16 Informatics 122 Software Design II Lecture 8 André van der Hoek.
© 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 &
© 2010 University of California, Irvine – André van der Hoek1June 15, 2015 – 14:08:09 Informatics 122 Software Design II Lecture 4 André van der Hoek &
© 2009 University of California, Irvine – André van der Hoek1June 17, 2015 – 09:17:24 Informatics 122 Software Design II Lecture 6 André van der Hoek &
(c) 2010 University of California, Irvine – André van der Hoek1February 21, 2010 – 18:05:18 Informatics 122 Software Design II Lecture 10 Nick Lopez Duplication.
© 2010 University of California, Irvine – André van der Hoek1June 22, 2015 – 23:08:13 Informatics 122 Software Design II Lecture 4 Nick Lopez Duplication.
© 2010 University of California, Irvine – André van der Hoek1June 26, 2015 – 00:06:40 Informatics 122 Software Design II Lecture 6 André van der Hoek &
(c) 2010 University of California, Irvine – André van der Hoek1June 29, 2015 – 08:55:05 Informatics 122 Software Design II Lecture 8 André van der Hoek.
Introduction to Software Engineering Lecture 8 André van der Hoek.
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
© 2010 University of California, Irvine – André van der Hoek1July 14, 2015 – 14:37:42 Informatics 122 Software Design II Lecture 4 Nick Lopez Duplication.
(c) 2010 University of California, Irvine – André van der Hoek1July 16, 2015 – 13:45:31 Informatics 122 Software Design II Lecture 8 Nick Lopez Duplication.
+ Informatics 122 Software Design II Lecture 8 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
+ Informatics 122 Software Design II Lecture 1 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Week 2 Design Examples and Designing for Change Alex Baker.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 12.
COMP 354 Software Engineering I Section BB Summer 2009 Dr Greg Butler
CSE 219 Computer Science III Program Design Principles.
+ Informatics 122 Software Design II Lecture 2 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
© 2010 University of California, Irvine – André van der Hoek1October 23, 2015 – 10:21:58 Informatics 122 Software Design II Lecture 1 André van der Hoek.
+ Informatics 122 Software Design II Lecture 14 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 10.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Introduction to Design. What is Design? 2 minutes Pairs.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 14.
Informatics 122 Software Design II Lecture 12 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 5 Duplication.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 6 Duplication.
+ Informatics 122 Software Design II Lecture 13 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
+ Informatics 122 Software Design II Lecture 3 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Chapter 4: Business Process and Functional Modeling, continued
Informatics 121 Software Design I
Informatics 121 Software Design I
Informatics 121 Software Design I
Informatics 122 Software Design II
Informatics 122 Software Design II
Informatics 122 Software Design II
Informatics 121 Software Design I
Informatics 121 Software Design I
Informatics 122 Software Design II
Informatics 122 Software Design II
Informatics 121 Software Design I
Informatics 121 Software Design I
Informatics 121 Software Design I
Informatics 121 Software Design I
Informatics 122 Software Design II
Informatics 122 Software Design II
Informatics 122 Software Design II
Informatics 122 Software Design II
Informatics 121 Software Design I
Informatics 121 Software Design I
Presentation transcript:

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

+ Today’s Lecture Design aesthetics Your BeNumbered designs 2

+ 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 3

+ 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? 4

+ 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 5

+ 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, … 6

+ 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, … 7

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

+ Designs Rated Highly By Peers

+ Some “Obvious” Room for Improvement

+ 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 may be an indicator in peer’s rankings, but not necessarily in ours It is easier to review than to design, or is it? 11

+ 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 12

+ 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 13

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

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

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

+ 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 … 17