Vorlesung Software Engineering - · PDF fileSoftware Engineering Research Group: Processes and...

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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


Software Unit


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


Data Refinement

Coding Units


Software Unit


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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


Data Refinement

Coding Units


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

Vorlesung Software Engineering - · PDF fileSoftware Engineering Research Group: Processes and...

Documents

Transcript of Vorlesung Software Engineering - · PDF fileSoftware Engineering Research Group: Processes and...