David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 8: Designing for Indestructability.

Slides:



Advertisements
Similar presentations
Systems Development Environment
Advertisements

Credit Cards presentation slides. Applying For A Credit Card costs: Annual Percentage Rate (APR) Grace period Annual fees Transaction fees Balancing computation.
David Evans CS200: Computer Science University of Virginia Computer Science Lecture 3: Rules of Evaluation.
Teens lesson eight credit cards.
CSE 331 wrapup CSE 331 University of Washington. CSE 331 goals Enable students to manage complexity ensure correctness write modest programs.
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
CS 5150 Software Engineering
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Lecture 4A: Modular Design IT 202—Internet Applications Based on notes developed by Morgan Benton.
SEG Software Maintenance1 Software Maintenance “The modification of a software product after delivery to correct faults, to improve performance or.
Software Development Concepts ITEC Software Development Software Development refers to all that is involved between the conception of the desired.
INFO415 Approaches to System Development: Part 2
1 A Real-World Development Lifecycle Greg Wilson
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 A proposition behind design patterns is that quality of software systems can be.
AGENDA Introduction to Virtual Mechanic Demo Architectural diagram and summary QA steps and user acceptance testing Bugs in the software Feedback from.
Cs205: engineering software university of virginia fall 2006 Data Abstraction David Evans
1 SYS366 Lecture Visual Modeling and Business Use Case Diagrams.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Teens lesson eight credit cards.
CREDIT CARDS. Advantage/Disadvantages Your Credit Worthiness The 5 ‘Cs’ Capacity Character Credit History Capital Collateral The 5 ‘Cs’ Capacity Character.
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Chapter 7 Software Engineering Introduction to CS 1 st Semester, 2015 Sanghyun Park.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
IS 325 Notes for Wednesday August 28, Data is the Core of the Enterprise.
David Evans CS200: Computer Science University of Virginia Computer Science Lecture 3: Rules of Evaluation.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 12: Subtyping Rules What’s the.
1 Ch. 1: Software Development (Read) 5 Phases of Software Life Cycle: Problem Analysis and Specification Design Implementation (Coding) Testing, Execution.
CSE 331 Software Design & Implementation Hal Perkins Autumn 2012 Wrapup 1.
Product Management Or.. The most important thing most startups forget to do.
Designing Classes. Software changes Software is not like a novel that is written once and then remains unchanged. Software is extended, corrected, maintained,
CS5103 Software Engineering Lecture 02 More on Software Process Models.
Rule of 70 You have to know this for the test – and to compound daily interest on a savings account!
David Evans CS150: Computer Science University of Virginia Computer Science Lecture 4: The Value of Everything.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
CS 1120: Computer Science II Software Life Cycle Slides courtesy of: Prof. Ajay Gupta and Prof. James Yang (format and other minor modifications by by.
Extreme programming (XP) Variant of agile Takes commonsense practices to extreme levels © 2012 by Václav Rajlich1.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
Computer Science 340 Software Design & Testing Software Architecture.
Lecture 4 Page 1 CS 111 Online Modularity and Virtualization CS 111 On-Line MS Program Operating Systems Peter Reiher.
David Evans CS200: Computer Science University of Virginia Computer Science Lecture 15: Intractable Problems (Smiley.
 Many models have been proposed to deal with the problems of defining activities and associating them with each other  The first model proposed was the.
David Evans Class 15: P vs. NP (Smiley Puzzles and Curing Cancer) CS150: Computer Science University of Virginia Computer.
Chapter 1: Introduction Omar Meqdadi SE 3860 Lecture 1 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 9: Designing Exceptionally.
Lecture 3: Rules of Evaluation CS150: Computer Science
CompSci Today’s topics Industry Practice Software Engineering Upcoming The Killer Robot Reading Great Ideas, Chapters 7.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 11: Subtyping and Inheritance.
David Evans CS201J: Engineering Software University of Virginia Computer Science Lecture 7: A Tale of Two Graphs (and.
Discovering the Need for Software Engineering A personal experience Kinga Dobolyi.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Teens lesson eight credit cards presentation slides 04/09.
© Chinese University, CSE Dept. Software Engineering / Software Engineering Topic 1: Software Engineering: A Preview Your Name: ____________________.
David Evans CS200: Computer Science University of Virginia Computer Science Lecture 21: Inheritance.
INTRODUCTION CSE 470 : Software Engineering. Goals of Software Engineering To produce software that is absolutely correct. To produce software with minimum.
Design David Evans cs205: engineering software
Class 22: Inheritance CS150: Computer Science University of Virginia
CS 5150 Software Engineering
Lecture 15: Concurring Concurrently CS201j: Engineering Software
Lecture 21: Inheritance CS200: Computer Science University of Virginia
Why Object-oriented Programming?
CS 1120: Computer Science II Software Life Cycle
Lecture 7: A Tale of Two Graphs CS201j: Engineering Software
Lecture 4: Data Abstraction CS201j: Engineering Software
UNIT 5 EMBEDDED SYSTEM DEVELOPMENT
UNIT 5 EMBEDDED SYSTEM DEVELOPMENT
Software Testing “If you can’t test it, you can’t design it”
Agile Development – a new way of software development?
Top-Down Design & JSP Skill Area Part D
Presentation transcript:

David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 8: Designing for Indestructability

24 September 2002CS 201J Fall Menu Design –Why it matters? –What makes a good design? Modular Dependency Diagrams –Documenting Designs How to Design Systems –How to Design Programs

24 September 2002CS 201J Fall Why Does Design Matter? "How is a taste in this beautiful art to be formed in our countrymen, unless we avail ourselves of every occasion when public buildings are to be erected, of presenting to them models for their study and imitation?...You see, I am an enthusiast on the subject of the arts. But it is an enthusiasm of which I am not ashamed, as its object is to improve the taste of my countrymen, to increase their reputation, to reconcile them to the rest of the world, and procure them its praise." Thomas Jefferson (letter to James Madison, 1785)

24 September 2002CS 201J Fall Software Design Matters Cost/Time to Implement –Some of you learned this the hard way for PS3! Independence of Modules –Decoupled modules can be developed and tested independently Ability to Change –Requirements for software change, poorly designed software is hard/impossible to change

24 September 2002CS 201J Fall The Browser Wars 1996: –Netscape Navigator: 73% –Microsoft IE: ~20% August 2002: –Microsoft IE: 96% –Netscape: ~1%

24 September 2002CS 201J Fall Browser History NCSA Mosaic (first widely used browser) – no design, quick and dirty implementation Dec 1994: developed into Netscape Navigator, V 1.0 (100K lines of code) Oct 1994: Microsoft starts developing IE : both browsers grew uncontrollably –Communicator 4.0: 120 developer, 3M lines of code Based on Daniel Jackson’s Notes

24 September 2002CS 201J Fall Microsoft Componentizes IE 3.0: Microsoft does complete restructuring (Jan-Aug 96) Designed around clear modules Team of 3-4 people designed component architecture –Modules: URL (high-level services), low-level services, MSHTML (HTML rendering), shell document, security services, etc. –Easy to customize browser by replacing components

24 September 2002CS 201J Fall What went wrong for Netscape? 1997: Communicator is impossible to develop –Without clear interfaces and modules, can’t divide work –All 120 developers had to work together “Most of the code is self-contained spaghetti…The core functionality works, but it’s the little squeaks everywhere that break.” Aleks Totic, Netscape, July 1997 “We’re in a really bad situation with our current code base…we’re paying the price for going fast. And when you go fast, you don’t architect...” Michael Toy, Netscape, July 1997

24 September 2002CS 201J Fall Netscape’s Downfall Netscape tries for 2 months to re-architect browser, but failed Tried starting from scratch for Communicator 6.0 (never completed) Eventually, give up and release it as open source Mozilla –Nobody can understand the code, so no one develops anything interesting for it Based on Daniel Jackson’s Notes

24 September 2002CS 201J Fall Microsoft v. Netscape Microsoft knew design mattered –Designed IE 3.0 around clear modules –Easy to add new features, fix problems –Won AOL deal because they could customize appearance of browser Netscape grew a quick-and-dirty implementation without clear modules and interfaces until it was impossible to develop Netscape sold to AOL, IE is the only browser that matters today

24 September 2002CS 201J Fall How should we describe designs?

24 September 2002CS 201J Fall Modular Dependency Diagrams Show the component modules –How is the program organized? Show the dependencies between them –How do modules depend on each other? Why do we want to know?

24 September 2002CS 201J Fall Using MDDs Design Time –Consider different designs –If the MDD has lots of cycles, crossings, etc. the design is not decoupled enough Implementation –Organize the implementation Testing –Where do you look when a test fails? Maintenance –What modules must be considered when specification of one changes?

24 September 2002CS 201J Fall MDD Notation StringTable Module Usually a Java class

24 September 2002CS 201J Fall MDD Notation Module Usually a Java class depends on the specification of TableEntry StringTable

24 September 2002CS 201J Fall Code  MDD If A calls a method of B, then A depends on the specification of B –If the specification of B changes, we need to reconsider A If A mentions the class B, but doesn’t call any methods or access fields, then A weakly depends on B –If the specification of B changes, we don’t need to reconsider A. A B A B

24 September 2002CS 201J Fall PS2 Module Dependencies TableEntry StringTable NameTrends StringIterator If the specification of StringTable changes, do we have to reconsider NameTrends ? Yes, dependencies reveal dependencies.

24 September 2002CS 201J Fall PS2 Module Dependencies TableEntry StringTable NameTrends StringIterator If the specification of TableEntry changes, do we have to reconsider NameTrends ? No, we only have to consider StringTable.

24 September 2002CS 201J Fall PS2 Module Dependencies TableEntry StringTable NameTrends StringIterator If the implementation of StringIterator changes, what classes must be reconsidered? None! Trick question – if specification contract is followed, we only care when spec changes.

24 September 2002CS 201J Fall PS1 Module Dependency Diagram Grid CellAutomata Cell CellState GridDisplay ConwayLifeCell is a subtype of (extends) What’s bad about this design?

24 September 2002CS 201J Fall Evaluating Designs Grid Cell Circular Dependency: Grid depends on Cell Cell depends on Grid

24 September 2002CS 201J Fall Why are circular dependencies bad? Need to finish both modules before you can test them (can use stub versions for testing) If a test fails, may be hard to figure out which module is at fault If spec of one changes, need to reconsider other module, but what if its spec changes as a result? But…sometimes unavoidable –Challenge: come up with a better design for PS1 (with 100 bonus points!)

24 September 2002CS 201J Fall Evaluating Designs Conflicting demands: Dependencies are bad, but reuse is good StringTable NameTrends StringIterator

24 September 2002CS 201J Fall Evaluating Designs Too many modules: lots of dependencies, overall design too complex to understand Too few modules: hard to divide, each module may be too big to implement Guideline: humans can only understand about 7 things at once – if you have more than 7 modules, make the modules bigger (could then subdivide them)

24 September 2002CS 201J Fall Evaluating Designs No absolute rules Important thing is that you can justify your design by explaining why it is better than alternatives A good design will make implementation (relatively) easy, a bad design will make implementation impossible

24 September 2002CS 201J Fall Charge PS4: Design Document –Due Thursday Wednesday, 8pm: AC’s will hold recitation on useful programming techniques –Not intended to help with design for PS4 –But, will be helpful for coding for PS4 and beyond…