The Software Design Process CPSC 315 – Programming Studio Fall 2009.

Slides:



Advertisements
Similar presentations
Software Engineering Key design concepts Design heuristics Design practices.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Structured Design. 2 Design Quality – Simplicity “There are two ways of constructing a software design: One is to make it so simple that there are obviously.
COMPSCI 105 S Principles of Computer Science 12 Abstract Data Type.
Object-Oriented Software Development CS 3331 Fall 2009.
By Justin Hendrix. Design Challenges Design is the activity that links requirements to coding and debugging. Good design is useful on small project and.
Chapter 13 Design Concepts and Principles
High Quality Code Why it matters. By Ryan Ruzich.
The Bridge Pattern.. Intent Decouple an abstraction from its implementation so that the two can vary independently Also known as: Handle/Body.
Object-Oriented Analysis and Design
Object-Oriented Metrics. Characteristics of OO ● Localization ● Encapsulation ● Information hiding ● Inheritence ● Object abstraction.
1 Software Testing and Quality Assurance Lecture 12 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)
Design The goal is to design a modular solution, using the techniques of: Decomposition Abstraction Encapsulation In Object Oriented Programming this is.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Object-Oriented Metrics
Software Development Overview CPSC 315 – Programming Studio Spring 2009.
Chapter 1 Principles of Programming and Software Engineering.
© Copyright Eliyahu Brutman Programming Techniques Course.
Chapter 10 Class and Method Design
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Engineering CSE470: Systems Engineering 35 Computer System Engineering Computer System Engineering is a problem-solving activity. Itemize desired.
Software Development Overview CPSC 315 – Programming Studio Spring 2008.
1 Working with Classes Chapter 6. 2 Class definition A class is a collection of data and routines that share a well-defined responsibility or provide.
Slide 1 Chapter 10 Class and Method Design. Slide 2 REVISITING THE BASIC CHARACTERISTICS OF OBJECT-ORIENTATION.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
The Design Discipline.
Design Patterns.
Chapter 5CSA 217 Design in Construction Chapter 5 1.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
CSE 303 – Software Design and Architecture
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
Software Design Deriving a solution which satisfies software requirements.
THE SOFTWARE DESIGN PROCESS CSCE 315 – Programming Studio Spring 2010.
SE: CHAPTER 7 Writing The Program
Object-Oriented Design Principles and Patterns. © 2005, James R. Vallino2 How Do You Design? What principles guide you when you create a design? What.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
CSE 403, Spring 2008, Alverson Software Design “There are two ways of constructing a software design: one way is to make it so simple that there are obviously.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
CSCI-383 Object-Oriented Programming & Design Lecture 10.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Dr D. Greer, Queens University Belfast )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
CS 350 – Software Design Expanding Our Horizons – Chapter 8 The traditional view of objects is that they are data with methods. Sometimes objects could.
Review of Parnas’ Criteria for Decomposing Systems into Modules Zheng Wang, Yuan Zhang Michigan State University 04/19/2002.
Design. Practices Principles Patterns What are the characteristics of good design? What are good solutions to common design problems? How do we go about.
High Quality Code – Style Matters  Design in Construction  Layout and Style Software Construction by Jeff Nogy.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Object-Oriented Design Concepts University of Sunderland.
ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 1.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
Basic Characteristics of Object-Oriented Systems
1 Object-Oriented Programming Using C++ CLASS 17 Honors.
Design I. Properties of good design Minimize complexity Maintainable Loose coupling Extensibility Reusability High fan in Low to medium fan out Portability.
Design in Construction
Chapter 1: Software design
Algorithms and Problem Solving
Object-Oriented Programming Concepts
MPCS – Advanced java Programming
Best Practices for Software System Design
Data Abstraction: The Walls
TIM 58 Chapter 8: Class and Method Design
The Software Design Process
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Algorithms and Problem Solving
Object Oriented Design & Analysis
Presentation transcript:

The Software Design Process CPSC 315 – Programming Studio Fall 2009

Outline Challenges in Design Design Concepts Heuristics Practices

Challenges in Design A problem that can only be defined by solving it Only after “solving” it do you understand what the needs actually are e.g. Tacoma Narrows bridge design “Plan to throw one away”

Challenges in Design Process is Sloppy Mistakes Wrong, dead-end paths Stop when “good enough” Tradeoffs and Priorities Determine whether design is good Priorities can change

Challenges in Design Restrictions are necessary Constraints improve the result Nondeterministic process Not one “right” solution A Heuristic process Rules of thumb vs. fixed process Emergent Evolve and improve during design, coding

Levels of Design Software system as a whole Division into subsystems/packages Classes within packages Data and routines within classes Internal routine design Work at one level can affect those below and above. Design can be iterated at each level

Key Design Concepts Most Important: Manage Complexity Software already involves conceptual hierarchies, abstraction Goal: minimize how much of a program you have to think about at once Should completely understand the impact of code changes in one area on other areas

Good Design Characteristics Minimal complexity Favor “simple” over “clever”

Good Design Characteristics Minimal complexity Ease of maintenance Imagine what maintainer of code will want to know Be self-explanatory

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Keep connections between parts of programs minimized Avoid n 2 interactions! Abstraction, encapsulation, information hiding

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Should be able to add to one part of system without affecting others

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Reusability Design so code could be “lifted” into a different system Good design, even if never reused

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Reusability High fan-in For a given class, have it used by many others Indicates good capture of underlying functions

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Reusability High fan-in Low-to-medium fan-out Don’t use too many other classes Complexity management

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Reusability High fan-in Low-to-medium fan-out Portability Consider what will happen if moved to another environment

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Reusability High fan-in Low-to-medium fan-out Portability Leanness Don’t add extra parts Extra code will need to be tested, reviewed in future changes

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Reusability High fan-in Low-to-medium fan-out Portability Leanness Stratification Design so that you don’t have to consider beyond the current layer

Good Design Characteristics Minimal complexity Ease of maintenance Loose coupling Extensibility Reusability High fan-in Low-to-medium fan-out Portability Leanness Stratification Standard Techniques Use of common approaches make it easier to follow code later Avoid unneeded exotic approaches

Design Heuristics Rules-of-thumb “Trials in Trial-and-Error” Understand the Problem Devise a Plan Carry Out the Plan Look Back and Iterate

Find Real-World Objects Standard Object-Oriented approach Identify objects and their attributes Determine what can be done to each object Determine what each object is allowed to do to other objects Determine the parts of each object that will be visible to other objects (public/private) Define each object’s public interface

Form Consistent Abstractions View concepts in the aggregate “Car” rather than “engine, body, wheels, etc.” Identify common attributes Form base class Focus on interface rather than implementation Form abstractions at all levels Car, Engine, Piston

Inheritance Inherit when helpful When there are common features

Information Hiding Interface should reveal little about inner workings Example: Assign ID numbers Assignment algorithm could be hidden ID number could be typed Encapsulate Implementation Details Don’t set interface based on what’s easiest to use Tends to expose too much of interior Think about “What needs to be hidden”

More on Information Hiding Two main advantages Easier to comprehend complexity Localized effects allow local changes Issues: Circular dependencies A->B->A Global data (or too-large classes) Performance penalties Valid, but less important, at least at first

Identify Areas Likely to Change Anticipate Change Identify items that seem likely to change Separate these items into their own class Limit connections to that class, or create interface that’s unlikely to change Examples of main potential problems: Business Rules, Hardware Dependencies, Input/Output, Nonstandard language features, status variables, difficult design/coding areas

Keep Coupling Loose Relations to other classes/routines Small Size Fewer parameters, methods Visible Avoid interactions via global variables Flexible Don’t add unnecessary dependencies e.g. using method that’s not unique to the class it belongs to

Kinds of Coupling Data-parameter (good) Data passed through parameter lists Primitive data types Simple-object (good) Module instantiates that object Object-parameter (so-so) Object 1 requires Object 2 to pass an Object 3 Semantic (bad) One object makes use of semantic information about the inner workings of another

Examples of Semantic Coupling Module 1 passes control flag to Module 2 Can be OK if control flag is typed Module 2 uses global data that Module 1 modifies Module 2 relies on knowledge that Module 1 calls initialize internally, so it doesn’t call it Module 1 passes Object to Module 2, but only initializes the parts of Object it knows Module 2 needs Module 1 passes a Base Object, but Module 2 knows it is actually a Derived Object, so it typecasts and calls methods unique to the derived object

Design Patterns Design Patterns, by “Gang of Four” (Gamma, Helm, Johnson, Vlissides) Common software problems and solutions that fall into patterns Provide ready-made abstractions Provide design alternatives Streamline communication among designers

More on Design Patterns Given common names e.g. “Bridge” – builds an interface and an implementation in such a way that either can vary without the other varying Could go into much more on this

Other Heuristics Strong Cohesion All routines support the main purpose Build Hierarchies Manage complexity by pushing details away Formalize Class Contracts Clearly specify what is needed/provided Assign Responsibilities Ask what each object should be responsible for

More Heuristics Design for Test Consider how you will test it from the start Avoid Failure Think of ways it could fail Choose Binding Time Consciously When should you set values to variables Make Central Points of Control Fewer places to look -> easier changes

More Heuristics Consider Using Brute Force Especially for early iteration Working is better than non-working Draw Diagrams Keep Design Modular Black Boxes

Design Practices (we may return to these) Iterate – Select the best of several attempts Decompose in several different ways Top Down vs. Bottom Up Prototype Collaborate: Have others review your design either formally or informally Design until implementation seems obvious Balance between “Too Much” and “Not Enough” Capture Design Work Design documents