Software Engineering Research Group: Processes and Measurement
Fachbereich Informatik
TU Kaiserslautern
Grundlagen des Software Engineering Fundamentals of Software Engineering
Winter Term 2011/12
Prof. Dr. Dr. h. c. Dieter Rombach
Chapter 6:
Software Unit Engineering
Last update: 09.12.2011
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 1
Software Unit
Engineering Goals
The goals of this chapter are to
– Understand, what a unit is and which perspectives are useful to describe it
– understand the application of engineering principles to developing software units (what
do the principles in chapter 2 mean for software unit development & specific
technologies?)
– understand how to design a unit from a specification
– be able to apply selected unit engineering approaches
– understand the usefulness of scalable methods (e.g. functional approach) to
engineering software units
Literature – Jalote, P.: “A Concise Introduction to Software Engineering”, Springer London, 2010.
– Jalote, P.: “An Integrated Approach to Software Engineering”, 3nd Edition, Springer-Verlag, 2005.
– Sommerville, I.: “Software Engineering”, 9. Edition, Addison Wesley, 2010.
– IEEE 610 – Standard Glossary of Software Engineering Terminology
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 2
Software Unit
Engineering
Introduction:
Overview
Unit
Requirements
System
Design
Unit
Design
Unit
Code
Executable
Unit
Executable
Sub-system
Validating
Validating
Sys
tem
De
ve
lop
me
nt
Unit Development
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 3
Software Unit
Engineering
Introduction:
Software units are part of a system
Unit (according to IEEE 610)
(1) A separately testable element specified in the design of a computer software component.
(2) A logically separable part of a computer program.
(3) A software component that is not subdivided into other components.
Types of units:
Type I Functions / Procedures
(Type II Data Structures)
Type III Abstract Data Types (ADT)
F1
F2
F3
F1 U1
F2 U2
F3 U3
Export Interface Import Interface
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 4
Software Unit
Engineering
Introduction:
Coupling
Unit Coupling
Represents a measure of the external integration of the unit in the system. Unit coupling
should be kept as low as possible.
We can measure coupling via
# using units
# used units
e.g., (#used units) * (#using units)
We can distinguish between different coupling strengths, e.g.
very weak: Data Flow Coupling (e.g., Call-by-value and parameter transfer)
weak: Data Flow Coupling (e.g., Call-by-reference)
medium: Data Flow Coupling via global variables
strong: Control Flow Coupling (e.g., one unit is inside another one)
very strong: Information Structure Coupling (e.g., joint design decisions)
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 5
Software Unit
Engineering
Introduction:
Cohesion
Unit Cohesion
Represents a measure for the inner cohesion of a unit. Unit Cohesion should be kept
high.
We can distinguish between different cohesion strengths, e.g.
very weak: no cohesion
weak: thematically related functions
weaker: temporal cohesion between functions
medium: procedural cohesion (determined by program course)
stronger: communicative cohesion (joint interfaces)
strong: sequential cohesion
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 6
Software Unit
Engineering
Introduction:
Unit Characteristics from user’s view
Through specified (functional and non-functional) features. Each feature can be described
through the in-/output as well as through their relations.
Example 1:
– {(1,1), (2,4), (3,9), (4,16), ...}
– f: integer integer
– f(i) :=
i:integer f
o:integer
i:integer f o:integer
last
event
i:integer f
o:integer Example 2:
{(3,1), (4,2), (4,8), (3,6), (6,3), ...}
f(i) = ???
Use state variable „last_even“ (values: Y,N)
Initialize state variable with value (N)
f: integer x Boolean integer x Boolean
𝑓 𝑖, 𝑙𝑎𝑠𝑡𝐸𝑣𝑒𝑛𝑡 =
2 ∗ 𝑖, 𝑌′ ′ 𝑖𝑓 𝑖 𝑖𝑠 𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡𝐸𝑣𝑒𝑛𝑡 =′ 𝑌′
2 ∗ 𝑖,′ 𝑁′ 𝑖𝑓 𝑖 𝑖𝑠 𝑢𝑛𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡𝐸𝑣𝑒𝑛𝑡 =′ 𝑌′
2 𝑑𝑖𝑣 𝑖, 𝑌′ ′ 𝑖𝑓 𝑖 𝑖𝑠 𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡𝐸𝑣𝑒𝑛𝑡 =′ 𝑁′
2 𝑑𝑖𝑣 𝑖, 𝑁′ ′ 𝑖𝑓 𝑖 𝑖𝑠 𝑢𝑛𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡𝐸𝑣𝑒𝑛𝑡 =′ 𝑁′
i² ???
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 7
Software Unit
Engineering
Introduction:
Unit Characteristics from developer’s view
Through requested (functional and non-functional) features (export interface), as well as
specific features of other units that can be used (import interfaces).
Interfaces comprise all external relations of a unit.
Import Interface: Listing of objects (data types, data structures, procedures, units) that
were developed outside the unit and are used inside.
Export Interface: Listing of objects that are made available to the outside world
Information Hiding maximized
The internal implementation of used/imported units should be hidden from the
user/developer, i.e. the pertinent decisions should be hidden in the implementation.
The context of the entire implementation can be exchanged unnoticed, as long as
the interface is not changed.
export interfaces
e.g. I/O
Import interfaces
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 8
Software Unit
Engineering
Introduction:
Observation
Unit Requirement (WHAT)
[from the developer‘s view, who has to realize the appropriate unit]
VERSUS
Unit Specification (HOW)
[from the view of the using module that uses an existing unit according to this
specification]
or
[from the view of the developer who has defined this unit]
Unit Verification and Validation (How Good)
Unit Engineering 2
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 9
Software Unit
Engineering P1: Easy to understand
Appropriate notation and structuring of the document.
– The choice of language depends on the qualifications of programmers & type of
application
– The degree of formality of the documentation (e.g. comments) depends on the
intended use, e.g.,
easy understanding
automated designing / coding / test case generation
formal verification
General guidelines
– simplicity of structure (simpler is better!)
– documentation to support complexity handling (e.g. aggregated functions as
documentation)
– complete & consistent specification & documentation
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 10
Software Unit
Engineering P2: Divide & Conquer
Sensible unit concept (e.g., ADT, classes!)
Stepwise refinement documented
Local understanding possible
Even distribution of complexity achieved
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 11
Software Unit
Engineering P2: Divide & Conquer
f: (A B A, B := (B - (B - A) / 2), (B - (B - A) / 2) ) | ()
Specification
procedure example (var A, B: integer);
while A < B do
Begin
A := A + 1;
if A < B then
B := B - 1;
end
end
Code
?
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 12
Software Unit
Engineering P2: Divide & Conquer
procedure example (var A, B: integer);
(* f: (A B A, B := (B - (B - A) / 2), (B - (B - A) / 2) ) | () *)
while A < B do
(* f1: A + 1 < B (A, B := A + 1, B - 1) | (A := A + 1) *)
Begin
(* f11: A := A + 1 *)
A := A + 1;
(* f12: A < B (B := B - 1) | () *)
if A < B then
(* f121: B := B - 1 *)
B := B - 1;
end
end
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 13
Software Unit
Engineering P3: Level Completeness
Semantically complete stepwise refinements
– trivial with functional semantics
– minimzes rework in case of inappropriate design decision
Stepwise verification possible
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 14
Software Unit
Engineering P4: Horizontal Traceability
Consisteny between code & in-line documentation (commentaries)
– trivial with functional refinement
– Established via top-down forward engineering (e.g. stepwise refinement) OR bottom-
up reverse engineering (e.g. stepwise abstraction reading)
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 15
Software Unit
Engineering P5: Vertical Traceability
Consistent Terminology
Traceability: The relation between different functional refinement steps and between
different levels of data abstraction must be clear.
Changes are easily traced. (vertical traceability)
One can concentrate on elementary sub-steps.
-----------------------------------
-----------------------------------
-----------------------------------
-----------------------------------
-----------------------------------
Traceability: SD Unit Req
Traceability: Unit Req Unit Code
System Design
Unit Requirements
Unit Code
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 16
Software Unit
Engineering P6: Documentation of “is verified”
Documentation of external consistency (req code)
– documentation of consistency between code and unit requirements
– documentation per common semantic model (e.g., functional semantics) or bridging
(manual) comments
– documentation automatable or human augmented comments
– Incrementally (if level-complete refinement exists!) or after coding
Documentation of internal consistency (across refinements levels within unit
design/code)
– documentation of internal refinements
– common semantic model exists (coding language)
– documentation automatable or human augmented comments (dito)
– Incrementally (if level-complete refinement exists!) or after coding (dito)
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 17
Software Unit
Engineering P7: Documentation of “is validated”
Documentation of external consistency (Ex.Unit Unit Req.)
– Is the degree of validation recognizable?
– Problems & corrections?
– Is validation (testing) done as reliability evaluation?
– If testing is done for defect detection: Wouldn‘t verification (e.g., inspections) be more
effective/efficient?
The unit specification must enable a decision on whether or not an observed
response is “legitimate”.
example (informal): The unit “SORT” sorts a list of integers in ascending order.
– Case 1: (1, 4, 2, 8) (8, 4, 2, 1) -- contradicts the specification
– Case 2: (1, 4, 1, 6) (1, 4, 6) -- does not contradict the specification, but: is it
desired?
– Case 3: (1, 4, 1, 6) (1, 1, 4, 6) -- does not contradict the specification, but: is it
desired?
example (formal):
SORT (L: List of integers)
Input: not-empty L
Output: "i, 1 i < size(L’): L’[i] L’[i + 1] and L’ = permutation[L]
– Case 1: not correct
– Case 2: not correct
– Case 3: correct
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 18
Software Unit
Engineering Unit Design and Unit Code
Unit Design involves the stepwise refinement of the specification down to the level of
algorithms. The design decisions are documented (traceability).
Unit Code is executable on a concrete machine level.
Unit Design and Unit Code can be contained in one document.
Unit
Requirements
System
Design
Unit
Design
Unit
Code
Executable
Unit
Executable
Sub-System
Validating
Validating
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 19
Software Unit
Engineering Functional Refinement
The design of units is based on the principle of “divide and conquer”
Black Box View
f: {...(-2, “fault”), (-1, “fault”), (0, 0), (1, 1), (2, 4), (3, 9), ...}
or
f: (input 0 f(x) = x² | f(x) = “fault”)
Clear Box View
f1: (input 0 f1(x) := x²)
f2: (input < 0 f2(x) := “fault”)
f f1 | f2
f: input output input:
integer
output:
integer {fault}
Unit:
U1
f1: input|0 integer
U2
f2: input|<0 “fault”
input 0 input:
integer output:
integer {fault}
Unit:
T
F
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 20
Software Unit
Engineering
Functional Refinement:
Design Process
(1) Define the “Black-box” specification of a unit U
– Input (or Stimuli)
– Output (or Responses)
– Function f: enumeration or analytic expression
(2) Design a “White-box” specification of unit U
– decompose U into design parts U1, ..., Un
– define the “Black-box” specification of every design part,
so that f = op(f1, ..., fn) is valid
with op {sequence, alternative, iteration, parallelism}
– Valid refinement operations (structured programming): Sequence, Alternative,
Iteration …
(3) Verify the “White-box” specification against the “Black-box” specification
– f op(f1, ..., fn)
(4) Repeat steps (2) and (3) for the new design parts, until simply codeable parts are
attained (i.e. can be coded directly in the constructs of a well defined programming language)
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 21
Software Unit
Engineering
Data Refinement:
Mills
Black-box view of Unit
f: {(3,1), (4,2), (4,8), (3,6), (6,3), ...}
State-box view of Unit
– last_even is initialized with “false”
– g: (input, last_even = ”even”, true output, last_even = 2 * input, true) | ... | ... | ...)
f: input output input:
integer
output:
integer
Unit:
g: input x S output x S
S: (last_even: Boolean)
input:
integer output:
integer
Unit:
Clear-box view of Unit
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 22
Software Unit
Engineering
Data Refinement:
Mills
Clear-box view of Unit
– f1: input|cond=true x S output x S
– f2: input|cond=false x S output x S
U1
f1
U2
f2
input = even input:
integer output:
integer
Unit:
State variable S
State-box view of Unit
T
F
g 𝑖, 𝑙𝑎𝑠𝑡𝐸𝑣𝑒𝑛𝑡 =
2 ∗ 𝑖, 𝑌′ ′ 𝑖𝑓 𝑖 𝑖𝑠 𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡_𝑒𝑣𝑒𝑛 =′ 𝑌′
2 ∗ 𝑖,′ 𝑁′ 𝑖𝑓 𝑖 𝑖𝑠 𝑢𝑛𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡_𝑒𝑣𝑒𝑛 =′ 𝑌′
2 𝑑𝑖𝑣 𝑖, 𝑌′ ′ 𝑖𝑓 𝑖 𝑖𝑠 𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡_𝑒𝑣𝑒𝑛 =′ 𝑁′
2 𝑑𝑖𝑣 𝑖, 𝑁′ ′ 𝑖𝑓 𝑖 𝑖𝑠 𝑢𝑛𝑒𝑣𝑒𝑛 𝑎𝑛𝑑 𝑙𝑎𝑠𝑡_𝑒𝑣𝑒𝑛 =′ 𝑁′
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 23
Software Unit
Engineering
Data Refinement:
Design Process (1/2)
(1) Define the “Black Box” specification of a unit U
– Input (or stimuli)
– Output (or responses)
– Function f
(2) Design a “State Box” specification of the unit U
– determine state variable S (to capture stimulus histories)
– define the “Black Box” specification of the internal
state function g
input x S output x S
(3) Verify the “State Box” specification against the “Black Box” specification
– f g
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 24
Software Unit
Engineering
Data Refinement:
Design Process (2/2)
(4) Design the “Clear Box” specification of the unit U
– divide U into design units U1, ..., Un
– define the “Black Box” specification of each design unit
so that g = op(f1, ..., fn) is true
with: op {sequence, alternative, iteration, parallel}
(5) Verify the “Clear Box” specification against the “State Box” specification
– g op(f1, ..., fn)
(6) Continue repeating steps (2) - (5) for the design units U1, ..., Un being created, until
design units have been created and can be transformed into code in an elementary way
(i.e., that they can be represented by constructs of a well-defined programming language).
Introduction
Principles
Unit Design and
Unit Code
Functional refinement
Data Refinement
Coding Units
© Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 25
Software Unit
Engineering Coding of Units
Coding of units is done as a consequent continuation of designing.
Basics of Commenting
– Header: the organizational information needed to gain an overview of the unit must be
provided
– Every functional abstraction is documented through its functional specification with
comments (based on the refinement of the design).
redundant comments can be eliminated
– Non self-explanatory data structures need to be documented
Coding Standards
– Programmers spend more time reading code than writing code
– Readability is enhanced if coding conventions are followed by all
Coding standards provide these guidelines for programmers
– Coding standards are regarding naming, file organization, statements/declarations,
comments …
f
Source code
f: A < B B := B - 1 | ()
(* f: A < B B := B - 1 | () *)
if A < B then
B := B - 1