Design Overview

1
Design Overview

• Software Design Process
• Design Document Outline

2
Agenda

• Deliverables
• Friday, January 18 _at_ 2400 - Status Report 2
• Wed, January 23 _at_ 2400
• Product Vision
• Project Backlog
• Sprint 1 Backlog
• Mon, Jan 28 _at_ 2400
• Iteration 1 Use Cases
• Iteration 1 Design and Conceptual Architecture
• Advisor Meeting Times
• Lecture Design Overview

3
Advisors

• Every Team must have one
• GT Sponsored projects, customer can be advisor
• Otherwise
• I am advisor by default
• Or you can find your own
• Advisors meet with you frequently to assess
  progress
• Advisors assign 30 of your grade

4
Software Design Fundamentals

• Good design is not accomplished by chance

The beginning of wisdom for a computer
programmer is to recognize the difference between
getting a program to work, and getting it right.
Jackson

• Fundamental concepts provide the framework for
  getting it right

5
Software Design

• Software design is the process of building a
  program to solve a problem while satisfying the
  problem's functional requirements and without
  violating its non-functional constraints
• High level or architectural design and low level
  or detail design
• Architectural design identifies and assigns
  responsibility for functional behavior to various
  modules or components of a software system
• Communication interfaces among the components
  must alsobe specified
• Detail design specifies the logical behavior of
  each ofthe components
• Algorithm selection and data structure
  representation

6
Major Architectural Styles

• Client-Server (Fat/Thin)
• N-Tier
• Blackboard / Shared Memory
• Master Controller
• Event Driven / Implicit Invocation
• Pipe and Filter
• Layered

7
Typical Business Layers
User Interface Services
Application Object Services
Domain Object Services
Low-Level Utility Objects / Technical Services
8
Typical Web Layers
9
Architectural Views

• Conceptual / Logical / Functional
• Process / Runtime
• Module / Code
• Physical
• Not all systems need all views. Need to describe
  how views relate, typically through scenarios.

10
Design Concepts

• Conceptual integrity / coherence
• Coupling / cohesion
• Information hiding
• Abstraction / refinement
• Rationale

11
Conceptual Integrity

• Of these thoughts one of the very first that
  occurred to me was, that there is seldom so much
  perfection in works composed of many separate
  parts, upon which different hands had
  beenemployed, as in those completed by a single
  master. Rene
  Descartes Discourse
  on a Method

12
Conceptual Integrity

• I will contend that conceptual integrity is the
  most important consideration in system design. It
  is better to have a system omit certain anomalous
  features and improvements, but to reflect one
  setof design ideas, than to have one that
  contains many independent and uncoordinated
  ideas.
• Fred Brooks The
  Mythical Man-Month

13
Coupling/Cohesion

• Coupling - the extent to which two components
  depend on each other for successful execution
• Cohesion - the extent to which a component has a
  single purpose or function
• Low coupling and high cohesionincrease
  reusability and maintainability

14
Information Hiding

• Mechanism for reducing coupling
• Use encapsulation to hide implementation details
  (think interfaces)
• Reduces inter-component coupling and thus makes
  maintenance and modification easier.

15
Refinement

• All design methods support the idea of
  abstraction and refinement
• That is, designs are expressed at various levels
  of detail with correspondences between the levels
• Various conceptual devices (abstraction
  mechanisms) are used to refine a design at one
  level to a lower levelProcedures, abstract data
  types, inheritance

16
Rationale

• Design is all about making tradeoffs
• For example time vs. space
• These are called design decisions
• Program's live a long time the original
  designersmay not be available at the time
  changes andenhancements must be made
• Hence, it is important to keep an explicit
  recordof the reasons for making decisions
• The record is call the program's design rationale

17
Approaches to Design

• There are many approaches to design.
• Some espouse a particular point of view as to how
  best to structure a system (for example,
  object-oriented design)
• Some of them are intended for a particular class
  ofapplication (e.g. real-time systems)
• And some are intended for a specific part of
  thesystem structure (such as user-interface
  design).
• All approaches to design, however, contain three
  aspects that may be compared
• Design method, representation and validation

18
Design Method

• A method is a systematic sequence of steps that a
  design team uses to solve a problem
• A method usually encourages a particular
  viewpointon its users
• For example, the object-oriented design method
  encourages designers to view problems in terms of
  their constituent objects before worrying about
  functional behavior.
• A method acts as a discipline on the designers,
  forcing them to order their thoughts and
  activities in certain ways

19
Design Representation

• Non-trivial problems require design solutions to
  be expressed using some form of representation
  conveyed in a design document
• The design representation may be either graphical
  or textual, but it is sufficiently formal that it
  can be checked for certain properties
• A design representation serves two audiences
• The designers themselves. That is, the discipline
  imposed by the method and the representation
  encourages early detection of missing or
  inconsistent aspects of a proposed solution
• Other stakeholders. These might be coders or
  testers. Notably, they might subsequently be
  maintainers trying to understand the designers'
  original intent

20
Design Validation

• Designs must be checked to assure that they
  accomplish their intended goals
• A good design method will have an associated
  validation technique
• For example, Structured Design measures the
  extent of coupling and cohesion to check the
  quality of its designs
• Design inspections and reviews are general
  techniques for assessing design quality. They
  can successfully complement method-specific
  validation techniques
• Validate against projected changes, NFRs

21
Design Information -Traditional

• Architecture (Box and Arrow)
• Processes / functions / algorithms
• Data / data flow
• Control logic / flow
• Performance
• Resource consumption
• UI Mockups

22
Design Information (OO)

• Architecture (UML Package/Component/Deployment
  diagrams)
• Static (UML Class Diagram)
• Dynamic (UML Sequence/Collaboration/Activity/State
  Diagrams)
• UI Mockups

23
Design Information (Web)

• Architecture
• Static (ER Diagram, Table Design, Script/Code
  file descriptions)
• Dynamic (Page Navigation)
• UI Mockups

24
Common Mistakes

• Poor Architecture
• No mapping through levels
• No Dynamic Models (State/Sequence)
• No deployment diagram for distributed systems
• Poor/Incorrect UML
• Poor UI design
• Poor overall design, failure to follow
  principles/patterns of good design.

25
Required Design Information

• Conceptual Architecture
• Static/Dynamic representation
• Design Rationale
• Detail Design
• Static/Dynamic Models (UML or equivalent)
• UI Screen Prototypes/Drawings
• Design Validation (Individual Design Assessment)
• Design Review (with instructor at Iter 2)

26
Individual Design Analysis

• Used for 2 things
• Evaluate you on design understanding
• Assess CoCs prep of you for design
• Format on class web page
• Think about issues and take notes
• Work on it a little at a time across semester
• Most students get 70-80 because it is done as an
  afterthought