Design Issues

Practice: A generic View

Design Principles
Reference
 “Software Engineering, A Practitioner’s
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.
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 !
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?
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?
Carry Out the Plan
 Does the solution conform to the plan?
 Is each component part of the solution
probably correct?
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?
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!
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!, DON’T DO IT!
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.
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…
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.
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.
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!
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.
Design Modeling Principles
 A software design model is the equivalent of
an architect’s plans for a house.
 Many systems of design have been used:
 Data driven design.
 Data structure driven design.
 Pattern Driven design.
 Object Oriented design.
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.
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.
Design Model

Component
Level Design
Interface
Design

Architectural
Design

Data/Class Design
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.
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.
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.
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.
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.
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.
Good Design Attributes
 Functionality
 Feature set
 Generality of functions
 Security of overall system
 Usability
 Reliability
 Performance
 Supportability
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)
Design Concepts (cont.)
 Architecture
 Overall structure
 Represented using one or more models
 Structural models
 Framework models
 Dynamic models
 Process models
 Functional models
Design Concepts (cont.)
 Patterns
 Here’s where the Design Patterns that Michael
has covered fit.
 Design Concepts (cont.)
 Modularity

Total Software Cost

Region of
Cost or Effort

Minimum Cost
Cost To Integrate

Cost / Module

Number of Modules We can’t predict an accurate M!

Design Concepts (cont.)
 Information Hiding
 Characterized by design decisions that (each)
hides from all others.
Design Concepts (cont.)
 Functional Independence
 Single minded
 Aversion to excessive interaction
 Cohesion (We want HIGH cohesion!)
 Coupling (We want LOW coupling!)
Design Concepts (cont.)
 Refinement
 Standard top-down strategy.
 Originally proposed by Wirth in 1971!
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.
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.