1. Software Design

2. decompose system into parts many attempts to measure the results
Main issues:
decompose system into parts
many attempts to measure the results
design as product  design as process
The resulting design description fakes the actual process followed.
© SE, Design, Hans van Vliet

3. Programmer’s Approach to Software Engineering
Skip requirements engineering and design phases;
start writing code

4. Why this programmer’s approach?
Design is a waste of time
We need to show something to the customer real quick
We are judged by the amount of LOC/month
We expect or know that the schedule is too tight

5. However, ...
The longer you postpone coding, the sooner you’ll be finished

6. Up front remarks Design is a trial-and-error process
The process is not the same as the outcome of that process
There is an interaction between requirements engineering, architecting, and design
See also the architecture chapter
© SE, Design, Hans van Vliet

7. Software design as a “wicked” problem
There is no definite formulation
There is no stopping rule
Solutions are not simply true or false
Every wicked problem is a symptom of another problem

8. Design Purpose

9. Purpose of Design
Design is where customer requirements, business needs, and technical considerations all come together in the formulation of a product or system
The design model provides detail about the software data structures, architecture, interfaces, and components
The design model can be assessed for quality and be improved before code is generated and tests are conducted
Does the design contain errors, inconsistencies, or omissions?
Are there better design alternatives?
Can the design be implemented within the constraints, schedule, and cost that have been established?

10. Purpose of Design
A designer must practice diversification and convergence
The designer selects from design components, component solutions, and knowledge available through catalogs, textbooks, and experience
The designer then chooses the elements from this collection that meet the requirements defined by requirements engineering and analysis modeling
Convergence occurs as alternatives are considered and rejected until one particular configuration of components is chosen
Software design is an iterative process through which requirements are translated into a blueprint for constructing the software
Design begins at a high level of abstraction that can be directly traced back to the data, functional, and behavioral requirements
As design iteration occurs, subsequent refinement leads to design representations at much lower levels of abstraction

11. Design Quality

12. Design Quality – Quality’s Role
The importance of design is quality
Design is the place where quality is fostered
Provides representations of software that can be assessed for quality
Accurately translates a customer's requirements into a finished software product or system
Serves as the foundation for all software engineering activities that follow
Without design, we risk building an unstable system that
Will fail when small changes are made
May be difficult to test
Cannot be assessed for quality later in the software process when time is short and most of the budget has been spent
The quality of the design is assessed through a series of formal technical reviews or design walkthroughs
Object oriented design is the topic of a chapter on its own.
© SE, Design, Hans van Vliet

13. Design Quality - Goals of Good Design
The design must implement all of the explicit requirements contained in the analysis model
It must also accommodate all of the implicit requirements desired by the customer
The design must be a readable and understandable guide for those who generate code, and for those who test and support the software
The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective
Object oriented design is the topic of a chapter on its own.
"Writing a clever piece of code that works is one thing; designing something
that can support a long-lasting business is quite another."
© SE, Design, Hans van Vliet

14. Design Tasks

15. From Analysis Model to Design Model
Each element of the analysis model provides information that is necessary to create the four design models
The data/class design transforms analysis classes into design classes along with the data structures required to implement the software
The architectural design defines the relationship between major structural elements of the software; architectural styles and design patterns help achieve the requirements defined for the system
The interface design describes how the software communicates with systems that interoperate with it and with humans that use it
The component-level design transforms structural elements of the software architecture into a procedural description of software components

16. From Analysis Model to Design Model
Data/Class Design
(Class-based model, Behavioral model)
Architectural Design
(Class-based model, Flow-oriented model)
Interface Design
(Scenario-based model, Flow-oriented model
Behavioral model)
Component-level Design
(Class-based model, Flow-oriented model

17. Design Elements Data/class design Architectural design
Creates a model of data and objects that is represented at a high level of abstraction
Architectural design
Depicts the overall layout of the software
Interface design
Tells how information flows into and out of the system and how it is communicated among the components defined as part of the architecture
Includes the user interface, external interfaces, and internal interfaces
Component-level design elements
Describes the internal detail of each software component by way of data structure definitions, algorithms, and interface specifications
Deployment-level design elements
Indicates how software functionality and subsystems will be allocated within the physical computing environment that will support the software

18. Dimensions of the Design Model
High
Analysis model
Abstraction Dimension
Design model
Data/Class
Elements
Architectural
Elements
Interface
Elements
Component-level
Elements
Deployment-level
Elements
Low
Process Dimension (Progression)

19. Design Tasks
Examine the information domain model and design appropriate data structures for data objects and their attributes
Using the analysis model, select an architectural style (and design patterns) that are appropriate for the software
Partition the analysis model into design subsystems and allocate these subsystems within the architecture
Design the subsystem interfaces
Allocate analysis classes or functions to each subsystem
Create a set of design classes or components
Translate each analysis class description into a design class
Check each design class against design criteria; consider inheritance issues
Define methods associated with each design class
Evaluate and select design patterns for a design class or subsystem

20. Design Tasks
Design any interface required with external systems or devices
Design the user interface
Conduct component-level design
Specify all algorithms at a relatively low level of abstraction
Refine the interface of each component
Define component-level data structures
Review each component and correct all errors uncovered
Develop a deployment model
Show a physical layout of the system, revealing which components will be located where in the physical computing environment

21. Design Principles

22. Design principles Abstraction Modularity, coupling and cohesion
Information hiding
Limit complexity
Hierarchical structure

23. Abstraction procedural abstraction:
natural consequence of stepwise refinement
a sequence of instructions that have a specific and limited function
abstraction
subproblems
time

24. application-oriented
Abstraction
data abstraction:
aimed at finding a hierarchy in the data
a named collection of data that describes a data object
application-oriented
data structures
simpler data
structure
general
data structures

25. Modularity
structural criteria which tell us something about individual modules and their interconnections
Separately named and addressable components (i.e., modules) that are integrated to satisfy requirements (divide and conquer principle)
Makes software intellectually manageable so as to grasp the control paths, span of reference, number of variables, and overall complexity
Functional independence
Modules that have a "single-minded" function and an aversion to excessive interaction with other modules
cohesion and coupling
cohesion: the glue that keeps a module together
coupling: the strength of the connection between modules
High cohesion – a module performs only a single task
Low coupling – a module has the lowest amount of connection needed with other modules

26. How to determine the cohesion type?
describe the purpose of the module in one sentence
if the sentence is compound, contains a comma or more than one verb  it probably has more than one function: logical or communicational cohesion
if the sentence contains time-related words like “first”, “then”, “after”  temporal cohesion
if the verb is not followed by a specific object  probably logical cohesion (example: edit all data)
words like “startup”, “initialize” imply temporal cohesion

27. strong cohesion & weak coupling  simple interfaces 
simpler communication
simpler correctness proofs
changes influence other modules less often
reusability increases
comprehensibility improves

28. Information hiding each module has a secret
design involves a series of decision: for each such decision, wonder who needs to know and who can be kept in the dark
The designing of modules so that the algorithms and local data contained within them are inaccessible to other modules
This enforces access constraints to both procedural (i.e., implementation) detail and local data structures
information hiding is strongly related to
abstraction: if you hide something, the user may abstract from that fact
coupling: the secret decreases coupling between a module and its environment
cohesion: the secret is what binds the parts of the module together

29. Complexity
measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …)
use these numbers as a criterion to assess a design, or to guide the design
interpretation: higher value  higher complexity  more effort required (= worse design)
two kinds:
intra-modular: inside one module
inter-modular: between modules

30. intra-modular attributes of a single module Two types:
measures based on size
measures based on structure

31. Sized-based complexity measures
counting lines of code
differences in verbosity
differences between programming languages
a:= b versus while p^ <> nil do p:= p^

32. Structure-based measures
based on
control structures
data structures
or both
example complexity measure based on data structures: average number of instructions between successive references to a variable
best known measure is based on the control structure: McCabe’s cyclomatic complexity

33. Hierarchy - System structure: inter-module complexity
looks at the complexity of the dependencies between modules
draw modules and their dependencies in a graph
then the arrows connecting modules may denote several relations, such as:
A contains B
A precedes B
A uses B
we are mostly interested in the latter type of relation

34. In a picture:
hierarchy
chaos
strict
hierarchy
tree

35. Design Methods

36. Design methods Functional decomposition Data Flow Design
Design based on Data Structures
Object Oriented design

37. Functional decomposition
bottom-up
top-down

38. Functional decomposition (cnt’d)
Extremes: bottom-up and top-down
Not used as such; design is not purely rational:
clients do not know what they want
changes influence earlier decisions
people make errors
projects do not start from scratch
Rather, design has a yo-yo character
We can only fake a rational design process
Mention another important article by David Parnas
© SE, Design, Hans van Vliet

39. Data flow design Yourdon and Constantine (early 70s)
nowadays version: two-step process:
Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams
Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts

40. Entities in a data flow diagram
external entities
processes
data flows
data stores

41. Top-level DFD: context diagram
library
system
direction
request
management
client
report
ack’ment

42. First-level decomposition
client
management
request
report
direction
prelim.
doc
prelim.
doc
log data
return
request
borrow
request
acknowledgement
log data
borrow
title
prelim.
doc
log file
title
title
catalog adm.

43. Second-level decomposition for “preliminary processing”
data base
log file
request
client info
log data
check
client
data
process
request OK
borrow
return
not OK
request
request

44. Example minispec Identification: Process request Description:
Enter type of request
1.1 If invalid, issue warning and repeat step 1
1.2 If step 1 repeated 5 times, terminate transaction
Enter book identification
2.1 If invalid, issue warning and repeat step 2
2.2 If step 2 repeated 5 times, terminate transaction
Log client identification, request type and book identification
...

45. OOAD methods three major steps: identify the objects
determine their attributes and services
determine the relationships between objects

46. (Part of) problem statement
Design the software to support the operation of a public library. The system has a number of stations for customer transactions. These stations are operated by library employees. When a book is borrowed, the identification card of the client is read. Next, the station’s bar code reader reads the book’s code. When a book is returned, the identification card isnot needed and only the book’s code needs to be read.

47. (Part of) problem statement
Design the software to support the operation of a public library. The system has a number of stations for customer transactions. These stations are operated by library employees. When a book is borrowed, the identification card of the client is read. Next, the station’s bar code reader reads the book’s code. When a book is returned, the identification card isnot needed and only the book’s code needs to be read.

48. Candidate objects software library system station customer transaction
book
library employee
identification card
client
bar code reader
book’s code

49. Carefully consider candidate list
eliminate implementation constructs, such as “software”
replace or eliminate vague terms: “system”  “computer”
equate synonymous terms: “customer” and “client”  “client”
eliminate operation names, if possible (such as “transaction”)
be careful in what you really mean: can a client be a library employee? Is it “book copy” rather than “book”?
eliminate individual objects (as opposed to classes). “book’s code”  attribute of “book copy”

50. Relationships From the problem statement: employee operates station
station has bar code reader
bar code reader reads book copy
bar code reader reads identification card
Tacit knowledge:
library owns computer
library owns stations
computer communicates with station
library employs employee
client is member of library
client has identification card

51. Result: initial class diagram

52. Usage scenario  sequence diagram

53. Design Guidelines

54. Design Quality Guidelines
A design should exhibit an architecture that
Has been created using recognizable architectural styles or patterns
Is composed of components that exhibit good design characteristics
Can be implemented in an evolutionary fashion, thereby facilitating implementation and testing
A design should be modular; that is, the software should be logically partitioned into elements or subsystems
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
Object oriented design is the topic of a chapter on its own.
© SE, Design, Hans van Vliet

55. Design Quality Guidelines
A design should lead to components that exhibit independent functional characteristics
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
Object oriented design is the topic of a chapter on its own.
© SE, Design, Hans van Vliet

56. Characteristics of Well Defined Design
Complete and sufficient
Contains the complete encapsulation of all attributes and methods that exist for the class
Contains only those methods that are sufficient to achieve the intent of the class
Primitiveness
Each method of a class focuses on accomplishing one service for the class
High cohesion
The class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities
Low coupling
Collaboration of the class with other classes is kept to an acceptable minimum
Each class should have limited knowledge of other classes in other subsystems
Object oriented design is the topic of a chapter on its own.
© SE, Design, Hans van Vliet

57. Design Vocabulary
Architecture - The overall structure of the software and the ways in which the structure provides conceptual integrity for a system. Consists of components, connectors, and the relationship between them
Patterns - A design structure that solves a particular design problem within a specific context. It provides a description that enables a designer to determine whether the pattern is applicable, whether the pattern can be reused, and whether the pattern can serve as a guide for developing similar patterns
Stepwise refinement - Development of a program by successively refining levels of procedure detail. Complements abstraction, which enables a designer to specify procedure and data and yet suppress low-level details
Refactoring - A reorganization technique that simplifies the design (or internal code structure) of a component without changing its function or external behavior. Removes redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failures

58. Conclusion Essence of the design process: decompose system into parts
Desirable properties of a decomposition: coupling/cohesion, information hiding, (layers of) abstraction
There have been many attempts to express these properties in numbers
Design methods: functional decomposition, data flow design, data structure design, object-oriented design
Object oriented design is the topic of a chapter on its own.
© SE, Design, Hans van Vliet

59. References
Software Engineering Practitioner’s Approach, Roger Pressman
Software Engineering Design, Hans van Vliet