Software Design: Creating Solutions for Ill-Structured Problems

✍ Scribed by David Budgen

• Publisher: Routledge
• Year: 2020
• Tongue: English
• Leaves: 365
• Edition: 3°
• Category: Library

✦ Synopsis

Software Design: Creating Solutions for Ill-Structured Problems, Third Edition provides a balanced view of the many and varied software design practices used by practitioners. The book provides a general overview of software design within the context of software development and as a means of addressing ill-structured problems. The third edition has been expanded and reorganised to focus on the structure and process aspects of software design, including architectural issues, as well as design notations and models. It also describes a variety of different ways of creating design solutions such as plan-driven development, agile approaches, patterns, product lines, and other forms.

Features

•Includes an overview and review of representation forms used for modelling design solutions

•Provides a concise review of design practices and how these relate to ideas about software architecture

•Uses an evidence-informed basis for discussing design concepts and when their use is appropriate

This book is suitable for undergraduate and graduate students taking courses on software engineering and software design, as well as for software engineers.

Author

David Budgen is a professor emeritus of software engineering at Durham University. His research interests include evidence-based software engineering (EBSE), software design, and healthcare informatics.

✦ Table of Contents

Cover
Half Title
Series Page
Title Page
Copyright Page
Dedication
Contents
Preface to the Third Edition
The City Car Club
I:
Addressing Ill-Structured Problems
1.
What Is Designing About?
1.1.
When is design needed?
1.2.
A bit about software
1.4.
Three perspectives upon design thinking
Key take-home points about what designing is about
2.
Doing Design
2.1.
Designing as a creative process
2.2.
Ill-structured problems
2.3.
What does a designer do?
2.4.
A simple example: the house move
Key take-home points about designing
3.
Managing the Design Process
3.1.
Cognitive capacity
3.2.
The power of abstraction
3.3.
Modelling and making design choices
3.4.
Recording design decisions
3.5.
Communicating ideas about a design model
Key take-home points about the design process
4.
Design Knowledge
4.1.
What do expert software designers do?
4.2.
Some software design principles
4.2.1.
Fitness for purpose
4.2.2.
Separation of concerns
4.2.3.
Minimum coupling
4.2.4.
Maximum cohesion
4.2.5.
Information hiding
4.3.
The evolution of design ideas
4.4.
The nature of expert design knowledge
Key take-home points about design knowledge
5.
Empirical Knowledge about Software Design
5.1.
Measuring software development processes
5.1.1.
Measuring physical phenomena
5.1.2.
Measuring human reactions
5.2.
Empirical studies in software engineering
5.2.1.
The empirical spectrum
5.2.2.
The research protocol
5.2.3.
Qualitative studies
5.2.4.
Quantitative studies
5.2.5.
Case studies
5.3.
Systematic reviews
5.4.
Using empirical knowledge
Key take-home points about empirical knowledge
II:
Design as a Noun: How Software Is Structured
6.
Software Architecture
6.1.
What architecture provides for us
6.2.
Architectural style
6.2.1.
Pipe-and-filter architectural style
6.2.2.
Call-and-return architectural style
6.2.3.
Data-centred repository architectural style
6.3.
Architectural patterns
6.3.1.
Model-view-controller (MVC)
6.3.2.
Layers
6.4.
Empirical knowledge about architecture
Key take-home points about software architecture
7.
Modelling Software Properties
7.1.
What is a design model?
7.2.
Representations, perspectives and viewpoints
7.2.1.
The constructional viewpoint
7.2.2.
The behavioural viewpoint
7.2.3.
The functional viewpoint
7.2.4.
The data-modelling viewpoint
7.3.
Design notations
7.3.1.
Textual description forms
7.3.2.
Box and line description forms
7.3.3.
Mathematical notations
7.4.
Empirical knowledge related to viewpoint notations
Key take-home points about design modelling
8.
Sketching Design Models
8.1.
Why do designers sketch?
8.2.
Sketching: developing informal models
8.3.
Characterising the design elements
8.3.1.
Software design as an ISP
8.3.2.
Sketching initial models
8.4.
Empirical knowledge about the use of sketching
Key take-home points about sketching
9.
Modelling Software Processes
9.1.
Characteristics of software processes
9.2.
Modelling function: the data-flow diagram (DFD)
9.3. Modelling behaviour: the state transition diagram (STD) and the state transition table (STT)
9.4. Modelling data: the entity-relationship diagram (ERD)
9.5.
Modelling construction: the structure chart
9.6.
Empirical knowledge about modelling processes
Key take-home points about modelling processes
10.
Modelling Objects and Classes
10.1.
Characteristics of objects and classes
10.1.1.
The notion of an object
10.1.2.
Objects and classes
10.2.
Relationships between objects
10.3.
Conceptual issues for object modelling
10.4.
Object modelling: the issue of notations
10.5.
Modelling construction: the class diagram
10.5.1.
Distinguishing classes from objects
10.5.2.
Class relationships
10.6.
Modelling behaviour: the statechart and the message
10.6.1.
The statechart
10.6.2.
The message sequence diagram
10.7.
Modelling function: the activity diagram
10.8.
Use cases
10.9.
Empirical knowledge about modelling objects and
10.9.1.
The object model
10.9.2.
Object modelling notations
10.9.3.
Object-oriented metrics
Key take-home points about modelling objects and classes
11.
Modelling Software Components and Services
11.1.
Reuse
11.2.
Modelling software components
11.2.1.
Component characteristics
11.2.2.
Component frameworks
11.2.3.
Designing components
11.2.4.
COTS
11.3.
Modelling software services
11.4.
Empirical knowledge about modelling components
11.4.1.
Empirical knowledge about components
11.4.2.
Empirical knowledge about services
Key take-home points about modelling components and services
III:
Design as a Verb: Designing Software
12.
Structuring the Ill-Structured
12.1.
Challenges in creating a design
12.2.
Evolution of knowledge transfer mechanisms
12.3.
Designing with others
12.4.
Empirical knowledge about design creation
13.
Plan-Driven Software Design
13.1.
What does plan-driven mean?
13.2.
Decompositional and compositional strategies
13.2.1.
Top-down decomposition
13.2.2.
Compositional design strategies
13.3.
What do plan-driven methods provide?
13.4.
SSA/SD: example of an early plan-driven form
13.4.1.
SSA/SD representation part
13.4.2.
SSA/SD process part
13.4.3.
SSA/SD heuristics
13.5.
SSADM: a designed design method
13.5.1.
SSADM representation part
13.5.2.
SSADM process part
13.5.3.
SSADM heuristics
13.6.
Plan-driven design for object-oriented models
13.6.1.
The Fusion method
13.6.2.
The Unified Process (UP)
13.7.
Empirical knowledge related to plan-driven design
Key take-home points about plan-driven design practices
14.
Incremental Design in Agile Software Development
14.1.
Using software prototypes
14.2.
Incremental development and the spiral model
14.3.
RAD: the DSDM method
14.3.1.
The DSDM principles
14.3.2.
The DSDM process
14.4.
The agile manifesto
14.5.
Extreme programming (XP)
14.6.
Agile development: Scrum
14.7.
Refactoring
14.8.
Empirical knowledge about design in agile development
14.8.1.
Empirical knowledge about DSDM
14.8.2.
Empirical knowledge about agile methods
14.8.3.
Empirical knowledge about refactoring
Key take-home points about designing in an agile context
15.
Designing with Patterns
15.1.
Patterns as a mechanism for knowledge transfer
15.2.
Architectural patterns
15.2.1.
Model-view-controller (MVC)
15.2.2.
Layers
15.2.3.
Broker
15.3.
Design patterns
15.3.1.
Proxy (207)
15.3.2.
Observer (293)
15.3.3.
Abstract Factory(87)
15.4.
Other uses of patterns
15.4.1.
Software service patterns
15.4.2.
Design anti-patterns and code smells
15.5.
Designing with patterns
15.6.
Empirical knowledge about designing with patterns
Key take-home points about designing with patterns
16.
Designing with Components and Services
16.1.
Modular design
16.2.
Designing with components
16.3.
Designing with software services
16.4.
Empirical knowledge about modular design
Key take-home points about designing with components and services
17.
How Good Is My Design?
17.1.
Quality assessment
17.1.2.
Design metrics
17.2.
Reviews and walkthroughs
17.3.
Refactoring of designs
17.4.
Empirical knowledge about quality assessment
Key take-home points about assessing design quality
18.
And What About...
18.1.
Open source software (OSS)
18.2.
Formal description techniques (FDTs)
18.3.
Model driven engineering (MDE)
18.4.
And the rest. . .
Bibliography
Index