Software Design

Requirements

Reqs. may be from customer or home invented

Design
Code-Implementation
Test Case Design

Testing
Builds

Rel.
Maintenance

Important End-Results of Design

Well-Designed software results in final
solution that is:
Easy to learn/understand
Easy to use

Clear, Consistent, Complete?

Easy to code
Easy to maintain (Extensible)

Which ones do the users care?

Affordable (economical)
Reusable
Dependable
Valuable (increase user productivity, life saving, etc. meets
customer requirements )

Any other property that you may want to add? -- easy to integrate or test
--- secure ---?

Design of Software Product

Designers are interested not only in the code,
but the complete product which includes:

Documentation and User Instructions

Code (functionality, data, security, reliability, etc.)
Interfaces (both systems and user)
Packaging and Delivery Scheme
Installation
Service (including maintenance)

This seems like a lot of topics that software designers must cover !!
So, there are specializations within the field of software design.

Design as an Activity (verb)

Software Product Design is the activity of
specifying:
- the nature and
- composition
of software products that satisfy the clients
- needs and
- desires
subject to certain set of constraints

What are the concepts behind nature of versus composition of ?

What about needs versus desire ?

Understanding the Problem

Design occurs after requirements (which identifies the

problems)
after is fuzzy time boundary there is no clean boundary

Think of Design as both a) understanding & b) solving

problems
1. Customer (user) identification of problem (requirements)
sometimes borders on solution --- but is really a constraint. Thus
we should thoroughly understand problems
2. For each problem there may be several solutions or designs that
apply
3. Use some time-honored problem solving techniques

Modifying the problem slightly to

a) facilitate easier/cheaper solution or
b) to match previously solved problem

Trial and error (e.g. iterative prototyping is the fancy term)

Group brainstorming (I only recommend a small group)

Two Basic Design Techniques

Abstraction
Focusing on the relevant properties of an entity
by suppressing and ignoring some other properties
and the details ----- trick is deciding on the
relevant.

Modeling
Constructing a model entity to represent the real
entity of interest through:
Associating : parts of the model to the parts of the real
entity
Associating: the relationships among parts of the model to
the relationships among parts of the entity of interest.

2 aspects of Abstraction
A) Problem/Solution Simplification:
concentrating on only the key property
(For example): In drawing a figure, we choose to first focus on
shape of the figure (e.g. circle, oval, rectangle, diamond, etc.)
before worrying about the details ( color, the line width,
solid/dotted line, etc.) ---- based on past experiences?

B) Problem/Solution Refinement: simplify first

and then enhance the solution with more details
Top-down refinement (Decomposition): partition the problem
into several key components first and then solve the details of
each component
Bottom-up aggregation: solving pieces of a complex problem and
then aggregate the solutions
Note: Bottom-up solution usually requires a top-down framework of
key components.

Modeling

Modeling is based on problem/solution simplification aspect of

Abstraction.
Decide on the key components (abstraction) of the entity of interest.
Decide on the key relationships that exist among the components of
the entity of interest.
Construct the components of the model to represent the
components of the entity of interest.
Construct the relationships among the components of the model to
reflect the relationships among the components of the original entity
of interest.

In doing so:
There may be parts in the model that do not match the original entity
There may be relationships in the model that do not match that in the
original entity

Note: If everything matched, then the model would just be a

copy, not an abstraction of the original entity.

Modeling: components and relations

Part B
Part A

Thing-X that
modeling
Needs
modeling

Part D

Part C

Part F

Another Definition of Design (from K. Lano)

Design is the activity of (i) constructing
components and (ii) organizing their
interactions in order to achieve the system that
will satisfy the requirements.
Components:
Identifying/specify -- the components
Specifying --- their functionalities
Specifying --- any constraints (performance, security, etc.)

Interactions:
Identify and Specify Component relations (for OO classes ----inheritance, aggregation, etc.)
Identify and Specify Component dependencies/interactions
(interfaces, joint responsibilities, sequences of interactions,
etc.)

Compare this with previous definition --- is this a better refinement?

Develop a Software Model for A Solar System

Start the discussion of this in class
The remaining parts are given as an
assignment.
(see Assignment 1)
For this assignment also think about what
Is a well constructed model or design
e.g.

easy to understand
easy to implement
etc.

See earlier slide

Advantages of Modeling
Allows us to understand the problem or
requirements better (model of the problem)
Allows us to create an initial rough design
Model of problem develops

Model of solution

Allows us to investigate and study both the problem

and the solution in more detail
Allows us to have a documentation of the
problem/solution descriptions (models)

Two Types of Design Models

Static model:
Represents the parts, relationships, and attributes
that do not really change (during execution of the
software )

Dynamic model:
Represents what happens during the execution of
the software.

In this course we will be using both static and dynamic models of software

Software Product Designer &

Engineering Designer
A software product designer is concerned with:
Product features and capabilities
Visually appealing and easy to use user-interfaces
Fitting into users business processes and operability
Product packaging
** ( a closer tie to what is specified in the product requirements )

(similarities and differences?)

A software engineering designer is concerned with:

Individual functionalities and performance

Internal structure of the software system
Individual programs and their interfaces & interactions
The data flow through the software system (including inputs and
outputs)
System maintenance and evolution
** (a closer tie to the internal technical design )

Software Design Team

We Need both:
Software Product Designer
Software Engineering Designer

Different sets of skills needed:

Product Designer knowledge of: user interface, communicating the
requirements/product design,
marketing, business processes, applications
domain knowledge
Engineering Designer knowledge of: architecture, programming,
database and data structures, development
platforms, networking, operating
systems

Software Design
product designer

Requirements

engineering designer

Design
product designer

Code-Implementation
Test Case Design

Testing
Builds

Rel.
Maintenance
(product and
engineering
redesign)

Software Product Design

.vs.
Software Engineering Design

Product Design Activity output is a software requirements

specification document
Answers mostly what the user and customer needs and wants --formulates the problem in an organized way :
Functionalities & features
Looks and interfaces
Constraints

organize: relating these

* * * Information/data needs to be folded in also * * *

Engineering Design Activity output is a design specification

document
Answers mostly how the software will be put together to respond
to the users needs and wants --- formulates the solution in an
organized way
High level software:
Components and
How they interact
Rationale behind your design decisions ( * my addition )

Low level specifications of programs and data and their behavior

Where is the analysis / innovation / creativity? ---- what do you think?

Is There a Design Method?

There is no ONE design method in the form of a
recipe for design.
Note: There are cooking recipes! But most software designs are too large
and complex compared to food dishes; so there are no design recipes .

There are several methods that all speak to:

Design process: a set of steps that starts with some inputs
and transform that input to some output and eventually results
in a design specification (e.g. structured method, OO-method,
etc.)
Design notation: a set of symbolic representations and how
the symbols are to be used (e.g. UML, DFD, etc.)
Design heuristics: a set of guiding rules (e.g. low coupling
and high cohesion)

More importantly, the mental activities that perform the design (analysis/innovation), I
believe, is not easily explainable or understood ---- thus it would be hard to teach it!

Brief History of Major Design Methods

Niklaus Wirth; E. Dijkstra (early 1970s) : Stepwise
Refinement
functional
abstraction

top-down approach that repeatedly decomposed procedures

into smaller ones until we reach programming level.

Stevens, Myers, and Constantine (mid-1970s):

Structured Design: (also DeMarco; Ross; Mills; etc.)
functional
& data
abstraction

Also top-down and procedural in nature

Included dataflow diagram and entity-relationship considerations
Started people on using CASE tools and associated notations
provided by the tools

Object Oriented Design (late 1980s- mid 1990s)

Based on Objects/ Classes (inheritance, polymorphism, etc.)
object
Uses standard UML design notation (Booch, Jacobson,
abstraction
Rumbaugh)
- Recently, we are pushing ------ design with patterns