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

Data/Class Design

Architectural Design

Interface Design

Component Level 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

Number of Modules

Co

st o

r E

ffo

rt

Cost / Module

Cost To Integrate

Total Software Cost

Region of

Minimum Cost

We can’t predict an accurate M!

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.