Software Design

1
Software Design
2
What is Software Design?

• Output of the requirements process is a system
  specification or black-box model of the proposed
  systems behavior.
• The purpose of design is to create a plan or
  blueprint for implementing the solution called
  for in the system specification.
• A software design expresses the overall structure
  and organization of the planned implementation.

3
Design is a Universal Activity

• Any product that is an aggregate of more
  primitive elements, can benefit from the activity
  of design.

4
Product Design Versus Engineering Design
System Behavior and User Interface
Product Design
Engineering Design
Internal System Structure
5
Essential Design Skills

• Knowledge of methods, patterns, principles and
  techniques of design
• Knowledge of heuristics for creating and
  evaluating designs
• Understand criteria for assessing a design
• Ability to communicate designs and design ideas
• Architect to programmer (implementation specs)
• Among colleagues (design ideas)
• Among practitioners (experience and expertise)

6
Organization of Topics

• What is Software Design?
• Design is a Universal Activity
• Product Design versus Engineering Design
• Key Concepts in Software Design
• Design Occurs at Multiple Levels
• Good Design Minimizes Intellectual Complexity
• Characteristics of an Effective Design
• Analysis Versus Design
• Design Challenges
• A Generic Design Process
• Understand the Problem
• Look for Existing Solutions
• Divine the Design
• Build Prototypes
• Document and Review the Design
• Evolve the Design
• Design Methods
• Structured Analysis and Design
• Object-Oriented Analysis and Design

• Design Techniques/Tactics
• Noun-Verb Analysis
• CRC Cards
• Test-Driven Development
• Principles and Heuristics of Design
• Modularity
• Information hiding
• Encapsulation
• Separation of Concerns
• Coupling and Cohesion
• Abstraction
• Principle of Least Surprise
• Dont Repeat Yourself (DRY)
• Single Responsibility Principle (SRP)
• Dependency Inversion Principle
• Open-Closed Principle (OCP)
• Keep is Simple
• Consider Brute Force
• Object-Oriented Design Heuristics

7
Design Occurs at Multiple Levels
Standard Levels of Design
8
The Importance of Good Design

• Poorly designed programs are difficult to
  understand and modify.
• The larger the program the more pronounced are
  the consequences of poor design.

9
Software Complexity

• One of the most important obligations of
  developers is managing the intellectual
  complexity of software solutions.
• To better understand how to manage technical
  complexity, its helpful to distinguish between
  two major types of complexity when solving
  problems with software
• Essential complexities complexities that are
  inherent in the problem.
• Accidental complexities complexities that are
  artifacts of the solution.
• The total amount of complexity in a solution then
  is
• Essential Complexities Accidental complexities

10
The Limited Capacity of the Human Mind for
Dealing with Complexity

• The motivation for controlling complexity is the
  fact that humans have a very limited capacity for
  dealing with complexity.
• The average person is able to deal with 5-9 items
  of information at a time. The Magical Number
  Seven, Plus or Minus Two
• We can compensate for our limited cognitive
  abilities by employing techniques such as
  chunking (modularity), abstraction, information
  hiding, etc.

11
Design An Antidote to Complexity

• Design is the primary tool for managing essential
  and accidental complexities in software.
• Good design doesnt reduce the total amount of
  essential complexity in a solution but it will
  reduce the amount of complexity that a programmer
  has to deal with at any one time.
• The main goal of design is to manage essential
  complexities inherent in the problem without
  adding to accidental complexities consequential
  to the solution.

12
Design Techniques for Dealingwith Software
Complexity

• Modularity subdivide the solution into smaller
  easier to manage components.
• Information Hiding hide details and complexity
  behind simple interfaces

13
More Techniques for Dealingwith Complexity

• Abstraction use abstractions to suppress
  details in places where they are unnecessary.
• Cohesion group like elements together.
• Coupling minimize dependencies between
  components.
• Hierarchical Organization larger components may
  be composed of smaller components.

14
Characteristics of an Effective Design

• Understandable Learnable.
• Not Fragile. Making a change in one area of the
  system shouldnt cause unexpected problems in
  another.
• The amount of effort needed to make a change
  should be proportional to the impact the change
  has on the problem concept. In other words, a
  small change in the problem concept (how users
  perceive the problem) should result in a small
  change to the system implementation.
• The design should make it relatively easy to find
  the code that needs to be changed once you
  understand the change request.
• Testable. Once a change is made, it should be
  relatively easy to verify the change was made
  correctly.
• Reusable. It should be relatively easy to reuse
  portions of the design and implementation in
  other similar applications.

15
Analysis Versus Design

• Design is difficult because design is an
  abstraction of the solution which has yet to be
  created

16
Design Challenges

• Design (and more generally, software) is largely
  invisible. Its hard to work with something that
  lacks a visual form.
• Software has static and dynamic forms. Design
  must address both.
• A design is an abstraction of yet-to-be completed
  implementation. Have to envision future state.
  Thats hard to do without some experience with
  the implementation.
• There are usually many acceptable solutions, a
  few great ones, and no easy way of telling the
  difference (i.e. no analytic deterministic
  criteria for judging the quality/efficacy of a
  design)

17
Design Challenges Cont

• There is no analytical or deterministic process
  guaranteed to produce an optimal design. Design
  relies on inspiration and insight.
• The problem isnt finding a design that works,
  there are many of those. The problem is finding
  an optimal design.
• The existence of many mediocre designs
  complicates the task of finding a great design
  because there is no definitive criteria for
  distinguishing good design from bad design

18
Coping with Design Challenges

• Concepts / Principles
• Methods / Techniques
• Patterns

19
Methods

• Design methods provide a procedural description
  for obtaining a design solution
• Most methods include
• A representation part or notation for
  representing problem and intermediate forms of
  the design solution (usually from different view
  points)
• Process part or procedures to following in
  developing the solution
• Heuristics guidelines and best practices.
  Remember, design isnt deterministic.

20
Example Methods

• Structured System Analysis and Structured Design
• Jackson System Development (JSD)
• Object-Oriented Analysis and Design

21
Structured Analysis and Design

• General representational forms data flow diagram
  (DFD) and structure chart
• General design process (1) model the system
  processes and information flow with a DFD, (2)
  transform the DFD into a hierarchical set of
  subprograms
• General heuristics (1) use concepts of coupling
  and cohesion when deciding how to apportion
  responsibility among subprograms, (2) try to
  identify a central transform in the DFD (or
  create your own) such that all other processes
  can be subordinate to this transform in the
  resulting structure chart.

22
Object-Oriented Analysis and Design
Representational Forms

• Class diagrams for static structure
• Sequence diagrams for dynamic behavior
• Textual and visual form of use cases are used to
  create and validate analysis and design
  representational forms
• Other UML models are also useful for
  understanding the problem and conceptualizing a
  solution (state machine diagram, activity
  diagram, etc.)

23
Object-Oriented Analysis and Design Process

• Express system requirements with use cases
• Create analysis models with the goal of better
  understanding problem domain and system
  requirements
• Take final analysis model and make it the first
  draft of the design (solution) model
• Look for opportunities to use architecture and
  lower-level design patterns
• Elaborate design solution
• Use design principles to guide decisions and
  evaluate evolving design forms.

24
Evolution of Design Methods

• Patterns play an important role in the design
  methods of today

25
Methods and Patterns

• Methods and patterns are the principle techniques
  for dealing with the challenges of design
• They are useful for
• Creating a design
• Documenting and communicating a design
• Transferring design knowledge and experience
  between practitioners

26
Patterns

• A pattern is a reusable solution to a commonly
  occurring design problem
• Design patterns are adapted for the unique
  characteristics of the particular problem
• Just as there are levels of design, there are
  levels of design patterns
• Architecture Styles
• Architecture Patterns
• Design Patterns
• Programming Idioms

27
Generic Design Process

• Understand the problem (SRS)
• Construct a black-box model of solution. This
  is the system specification.
• Look for existing solutions (i.e. design
  patterns) that cover some or all of the software
  design problems identified.
• Divine the design
• Consider building prototypes
• Document and review design
• Iterate over solution (Evolve the design until it
  meets functional requirements and maximizes
  non-functional requirements)

28
Inputs to the design process

• User requirements and system specification
  (including any constraints on design and
  implementation options)
• Domain knowledge (If its a healthcare
  application the designer will need some knowledge
  of healthcare terms and concepts.)
• Implementation knowledge (capabilities and
  limitations of eventual execution environment)

29
Design Representational Forms

• Offers particular abstractions of the system from
  a certain perspective (viewpoint)
• Types of representational forms
• Visual models
• Text
• Pseudocode
• Design representations Functional, static
  structural, dynamic behavioral, data modeling
  (database schema)

30
Attributes of a design

• Static structure of system (components and their
  relationships)
• Interactions between components
• System data and its structure (database scheme)
• Physical packaging and distribution of components
• Algorithms

31
The Evolution of Designs

• Design as a single step in the software life
  cycle is somewhat idealized.
• More often the design process is iterative and
  incremental.
• Designs tend to evolve over time based on
  experience with their implementation.

32
Design Qualities

• Fitness for purpose. Satisfies product
  requirements
• Reliability
• Robustness
• Efficiency
• Usability
• Maintainability
• Evolvability

33
Design Strategies

• Top-Down Decomposition
• Bottom-Up Aggregation/Composition
• Round-Trip Gestalt
• Transformation and Elaboration
• Organizational Influences on Design

34
Elaboration and Transformation
35
Design Principles and Heuristics

• Abstraction
• Simplicity
• Coupling and Cohesion
• Information Hiding
• Encapsulation
• Modularization
• Separation of Concerns
• Single Point of Reference
• Separation of Interface and Implementation

36
Abstraction

• Abstraction is a concept used to manage
  complexity
• An abstraction is a generalization of something
  too complex to be dealt with in its entirety
• Abstraction is for humans not computers
• Abstraction is a technique we use to compensate
  for the relatively puny capacity of our brains
  (when compared to the enormous complexity in the
  world around us)
• There arent enough neurons (or connections) in
  our brain to process the rich detail around us
  during a single moment in time
• Successful designers develop abstractions and
  hierarchies of abstractions for complex entities
  and move up and down this hierarchy with splendid
  ease

37
Information Hiding

• Information hiding is a design principle
• The information hidden can be data, data formats,
  behavior, and more generally, design decisions
• When information is hidden there is an implied
  separation between interface and implementation.
  The information is hidden behind the interface
• Parnas encourages programmers to hide difficult
  design decisions or design decisions which are
  likely to change
• The clients of a module only need to be aware of
  its interface. Implementation details should be
  hidden

38
Encapsulation

• Encapsulation is an implementation mechanism for
  accomplishing the principle of information hiding
• There is no clear widely accepted definition of
  encapsulation. It can mean
• A grouping together of related things (records,
  arrays)
• A protected enclosure (object with private data
  and/or methods)

39
Object-Oriented Analysis and Design Heuristics

• Favor composition over inheritance
• Encapsulate highly complex or likely to change
  design decisions
• Scope entities as tight as possible
• Principle of substitution
• Law of Demeter
• Its better to depend on abstractions than
  concrete entities (Dependency Inversion Principle
  Martin)

40
Design Example

• Imagine an on campus resource center that
  supports the teaching mission of a University.
  Lets call it the Faculty Resource Center (FRC).
• The FRC loans books, tapes, DVDs, and software
  up to 2 weeks. It allows audio/visual equipment
  to be reserved and borrowed during the day. It
  also allows conference rooms to be reserved by
  the hour. In the future it plans to host seminars
  on effective teaching methods.

41
Understand the Requirements

• No matter what design method you follow, the
  first step is always understand the
  requirements.
• Models of the problem domain may be created to
  better understand concepts in the problem domain

42
Principle of Least Surprise