Design Issues

1
Design Issues

• Practice A generic View
• Design Principles

2
Reference

• Software Engineering, A Practitioners Approach,
  by Roger Pressman, sixth edition, 2005, ISBN
  0-07-285318-2.
• An excellent reference type textbook for Software
  Engineering.
• Used for approximately one-half the CS351
  Software Engineering Courses.
• Design is the place where quality is fostered in
  Software Engineering.

3
The Essence Of Problem Solving

• Understand the problem (communication and
  analysis)
• Plan a solution (modeling and software design)
• Carry out the plan (code generation)
• Examine the results for accuracy (testing and
  quality assurance)
• The main steps above were in a book by George
  Polya, published in 1945 !

4
Understand the Problem

• Who has a stake in the solution of the problem?
• What are the unknowns?
• Can the problem be compartmentalized?
• Can the problem be represented graphically?
• Can an analysis model be created?

5
Plan the Solution

• Have you seen similar problems before?
• Has a similar problem been solved?
• Can subproblems be defined?
• Can you represent a solution in a manner that
  leads to effective implementation?

6
Carry Out the Plan

• Does the solution conform to the plan?
• Is each component part of the solution probably
  correct?

7
Examine the Result

• Is it possible to test each component part of the
  solution?
• Does the solution produce results that conform to
  the data, functions, features, and behavior that
  are required?

8
Core Principles

• The reason it All exists.
• Keep It Simple Stupid.
• Maintain the Vision.
• What you produce, others will consume.
• Be Open to the Future.
• Plan Ahead for Reuse.
• Think!

9
The Reason It All Exists

• A software system exists for one reason to
  provide value to its users.
• Make all decisions with this in mind.
• Before adding something, ask yourself Does this
  add real value to the system?
• If the answer is NO!, DONT DO IT!

10
KISS Keep It Simple Stupid

• All designs should be as simple as possible, but
  no simpler!
• Simple DOES NOT mean Quick and Dirty.
• Simplicity in design makes software that
• Is easier to understand.
• Is easier to maintain.
• Is less error-prone.
• It often takes a lot of thought and work over
  multiple iterations to simplify.

11
Maintain the Vision

• A clear vision is essential to the success of a
  software project.
• Without conceptual integrity, a system threatens
  to become a patchwork of incompatible designs,
  held together by the wrong kind of screws

12
What You Produce, Others Will Consume

• In some way or other, someone else will use,
  maintain, document, or otherwise depend on being
  able to understand your system.
• Always specify, design, and implement knowing
  someone else will have to understand what you are
  doing.
• This audience is potentially large.

13
Be Open To the Future

• Systems with a long lifetime have more value.
• True industrial strength software systems must
  endure.
• They must be ready to adapt to the changing
  environments.
• Never design yourself into a corner.
• Always ask What if?
• Prepare for all possible anwers.

14
Plan Ahead For Reuse

• Reuse saves time and money.
• This can be a hard goal to achieve.
• To reap the benefits of reuse, requires
  forethought and planning.
• Using modern practices helps.
• Communicating opportunities for reuse to others
  in the organization is important.
• Reuse reduces costs and increases value!

15
Think!

• Placing clear, complete thought before action
  almost always produces better results.
• Design itself may be new to students since they
  have often only worked on toy problems and toy
  programs.
• Example
• The web server is down.
• Tried to ssh to my computer and had trouble.
• Stopped for 5 minutes to think about it.
• Remembered I had downloaded slides.

16
Design Modeling Principles

• A software design model is the equivalent of an
  architects plans for a house.
• Many systems of design have been used
• Data driven design.
• Data structure driven design.
• Pattern Driven design.
• Object Oriented design.

17
Design Principles

• Design should be traceable to the analysis model.
• Always consider the architecture of the system to
  be built.
• Design of data is as important as design of
  processing functions. (13 file story, dates)
• Interfaces (both internal and external) must be
  designed with care.
• User interface design should be tuned to the
  needs of the end-user.

18
Design Principles (cont.)

• Component-level design should be functionally
  independent.
• Components should be loosely coupled to one
  another and to the external environment.
• Design representations (models) should be easily
  understandable.
• The design should be developed iteratively. With
  each iteration, the designer should strive for
  greater simplicity.

19
Design Model
Component Level Design
Interface Design
Architectural Design
Data/Class Design
20
Design Model (cont.)

• Data/Class Design transforms analysis-class
  models into design class realizations and data
  structures.
• Architectural Design defines the relationship
  between major structural elements of the
  software.
• Interface design describes how the software
  communicates with systems that interoperate with
  it, and with the humans who use it.
• Component Level design transforms structural
  elements of the software architecture into a
  procedural description of software components.

21
Evaluation Of A Good Design

• The design must implement all of the explicit
  requirements contained in the analysis model, and
  it must accommodate all of the implicit
  requirements desired by the customer.
• The design must be a readable, understandable
  guide for those who generate code, and for those
  who test and subsequently support the software.

22
Evaluation Of A Good Design (cont.)

• The design should provide a complete picture of
  the software, addressing the data, functional,
  and behavioral domains from an implementation
  perspective.

23
Design Quality Guidelines

• The design architecture
• Should be created using recognizable styles or
  patterns.
• Should be composed of components that exhibit
  good design characteristics (more later).
• Should be implemented in an evolutionary fashion
  facilitating implementation and testing.

24
Design Quality Guidelines (cont.)

• A design should be modular.
• A design should contain distinct representations
  of data, architecture, interfaces, and
  components.
• A design should lead to data structures that are
  appropriate for the classes to be implemented and
  are drawn from recognizable data patterns.
• A design should lead to components that exhibit
  independent functional characteristics.

25
Design Quality Guidelines (cont.)

• A design should lead to interfaces that reduce
  the complexity of connections between components
  and with the external environment.
• A design should be derived using a repeatable
  method that is driven by information obtained
  during software requirements analysis.
• A design should be represented using a notation
  that effectively communicates its meaning.

26
Good Design Attributes

• Functionality
• Feature set
• Generality of functions
• Security of overall system
• Usability
• Reliability
• Performance
• Supportability

27
Design Concepts

• Abstraction
• Abstraction is one of the fundamental ways humans
  deal with complexity.
• Procedural abstraction (OPEN for open the door)
• Data abstraction (DOOR for all the parts of a
  door)

28
Design Concepts (cont.)

• Architecture
• Overall structure
• Represented using one or more models
• Structural models
• Framework models
• Dynamic models
• Process models
• Functional models

29
Design Concepts (cont.)

• Patterns
• Heres where the Design Patterns that Michael has
  covered fit.

30
Design Concepts (cont.)

• Modularity

Total Software Cost
Cost or Effort
Region of Minimum Cost
Cost To Integrate
M
Cost / Module
Number of Modules
We cant predict an accurate M!
31
Design Concepts (cont.)

• Information Hiding
• Characterized by design decisions that (each)
  hides from all others.

32
Design Concepts (cont.)

• Functional Independence
• Single minded
• Aversion to excessive interaction
• Cohesion (We want HIGH cohesion!)
• Coupling (We want LOW coupling!)

33
Design Concepts (cont.)

• Refinement
• Standard top-down strategy.
• Originally proposed by Wirth in 1971!

34
Design Concepts (cont.)

• Refactoring
• Reorganizing and simplifying the design (or code)
  of a component without changing its function or
  behavior.
• It is assumed that this change will improve the
  internal structure.

35
Design Concepts (cont.)

• Design Classes
• User Interface Classes
• Business Domain Classes
• Process Classes
• Persistent Classes
• System Classes
• A well-formed design class is complete and
  sufficient, primitive, high cohesion, and low
  coupling.