Software Engineering Principles

Ch. 3 1

Outline• Principles form the basis of methods,

techniques, methodologies and tools• Seven important principles that may

be used in all phases of software development

• Modularity is the cornerstone principle supporting software design

• Case studies

Ch. 3 2

Software Engineering Principles• Some important & general principles for

developing successful sw will be discussed

• Deal w/ both the process & the product• Either the process or the product to the

exclusion of other?

right process right product

Ch. 3 3

yields

help choosing

Software Engineering Principles• Relationship btw principles, methods, and techniques

– principle: general&abstract statements describing desirable properties

– method: general guidelines governing execution of some activity

• Rigorous, systematic, and disciplined approaches

– technique: technical, mechanical, and restricted applciationsmethods + techniques methodology

– methodology: a certain approach for solving a problem by preselected methods & techniques to be used

• often methods and techniques are packaged in a methodology

– tools: support the application of techniques, methods, and methodologies

Ch. 3 4

A visual representation

Ch. 3 5

Principles

Methodologies

Principles

Methods and techniques

Methodologies

Tools

• Qualities: reliability & evolvability creates basic need for sw eng.• affects our discussion in principles, methods, and techniques

because of non-expert users or a critical application

Key principles of sw development

• Rigor and formality• Separation of concerns• Modularity• Abstraction• Anticipation of change• Generality• IncrementalityNot an exhaustive list! They are all related.

Ch. 3 6

Rigor and formality• SW development is a creative activity• A creative process: be neither precise nor

accurate, follow the inspiration of the moment in unstructured manner

• Rigor: precision & exactness a necessary complement to creativity in engineering

• By a rigorous approach– repeatedly produce reliable products– control their costs– increase confidence in reliability

• Rigor does not need to constrain creativity, rather enhance it– Can only be confident of a creative process after a

rigorous assessment of resultsCh. 3 7

Rigor and formality• Paradox: rigor is an intuitive principle and

cannot be defined rigorously– Various degrees of rigor can be achieved– The highest degree is formality

• Formality: a stronger requirement drive & evaluate by mathematical laws– implies rigor, but not vice versa!

• There is no need to be always formal during design, but the engineer must know how & when to be formal

• For example;– scheduler of a real-time OS– security component of an e-commerce system

Ch. 3 8

need formal description of fcns & formal approach for assessment

Rigor and formality• Definition by natural language must be done

rigorously• Also can be done by a language of logical

statements formally

• ! Programming a formal approach• ! Programs formal objects

Ch. 3 9

Examples

• Product– Mathematical (formal) analysis of

program correctness– Systematic (rigorous) test data derivation

• Process– Rigorous documentation of development

steps helps project management and assessment of timeliness

Ch. 3 10

Separation of concerns• To dominate complexity, separate the issues to

concentrate on one at a time• "Divide & conquer" (divide et impera)• Supports parallelization of efforts and separation

of responsibilities– e.g., divide work for different people w/ different skills (managerial &

technical)

Ch. 3 11

Product features Development process Economic & financial matters

Offered functions Development environment

Cost of the product

Expected reliability Organization of temas Initial budget

Efficiency in space&time

Scheduling Foreseen completion time

Relationship w/ environment

Design strategies

Error recovery mechanisms

Separation of concerns• Concerns are interrelated though

– e.g., design choice of swapping data to disk increases cost, changes recovery mechanism

• Strategy: isolate issues not closely related w/ only relevant details of relates issues

• Ways to separate concerns (in terms of)– Time

• allows precise planning of activities• underlying motivation of the sw life cycle models

– Quality• e.g., a priori correctness of a sw and then restructure to improve

performance

– Views• e.g., when applying reqs, concentrate separately on flow of data & flow

of control synchronizing activities

– Parts / size• a need to dominate sw production complexity

Ch. 3 12

Separation of concerns• Inherent disadvantage of separtion of concerns

is to miss global optimization that would be possible by teackling concerns together

• If two issues are intrinsically intertwined– make an overall design – then effectively separate issues– e.g., multiple on-line transactions accessing a

database (correctness & performance intertwined)• first design: lock database for each transaction what if one

transaction takes too long• alternative design: divide each transaction into parts

– transactions are performed truly issue of correctness– each atomic transaction is fast enough issue of

performance– ! Separated concerns

Ch. 3 13

Example

• Product– Keep product requirements separate

• functionality• performance• user interface and usability

• Process– Go through phases one after the other (as in

waterfall)• Does separation of concerns by separating

activities with respect to time

Ch. 3 14

Modularity

• A complex system may be divided into simpler pieces called modules

• A system that is composed of modules is called modular

• Supports application of separation of concerns– when dealing with a module we can ignore

details of other modules

• Composition bottom-up desing• Decomposition top-down approach

Ch. 3 15

Modularity

Main benefits of modularity1. Capability of decomposing a complex

system into simpler pieces2. Capability of composing a complex system

from existing modules3. Capability of understanding the system in

terms of its pieces4. Capability of modifying a system by

modifying only a small number of its pieces

Ch. 3 16

Cohesion and coupling

• Each module should be highly cohesive– module understandable as a meaningful

unit– Components of a module are closely related

to one another

• Modules should exhibit low coupling– modules have low interactions with others– understandable separately

Ch. 3 17

A visual representation

Ch. 3 18

(a) (b)

high coupling low coupling

Abstraction• Identify the important aspects of a

phenomenon and ignore its details• Special case of separation of concerns

– e.g., the user interface of a watch (its buttons) abstracts from the watch's internals for the purpose of setting time; other abstractions needed to support repair

• The type of abstraction to apply depends on purpose

Ch. 3 19

Abstraction ignores details

• For example;– equations describing complex circuit

(e.g., amplifier) allows designer to reason about signal amplification

• Further abstraction– equations may approximate

description, ignoring details that yield negligible effects (e.g., connectors assumed to be ideal)

Ch. 3 20

Abstraction yields models

• For example, when requirements are analyzed we produce a model of the proposed application

• The model can be a formal or semiformal description

• It is then possible to reason about the system by reasoning about the model

Ch. 3 21

An example

• Programming language semantics described through an abstract machine that ignores details of the real machines used for implementation– abstraction ignores details such as

precision of number representation or addressing mechanisms

Ch. 3 22

Abstraction in process

• When we do cost estimation we only take some key factors into account

• We apply similarity with previous systems, ignoring detail differences

Ch. 3 23

Anticipation of change• Distinguishes sw th most from other idustrial

productions– A sw app is developed w/o its requirements are

not entirely understood

• Ability to support software evolution requires anticipating potential future changes

• It is the basis for software evolvability• For example;

– set up a configuration management environment for the project (as we will discuss)

Ch. 3 24

Generality• While solving a problem, try to discover if it is an

instance of a more general problem whose solution can be reused in other cases– Merge two sorted lists w/ no identical values– If you apply generalization: sort also lists containing

identical values higher reusability

• Carefully balance generality against performance and cost

• Sometimes a general problem is easier to solve than a special case – Off-the-shelf products– Automobiles & textile industry

• Next step: application servers

Ch. 3 25

Incrementality

• Process proceeds in a stepwise fashion (increments)

• Examples (process)– deliver subsets of a system early to get

early feedback from expected users, then add new features incrementally

– deal first with functionality, then turn to performance

– deliver a first prototype and then incrementally add effort to turn prototype into product

Ch. 3 26

Case study: compiler

• Compiler construction is an area where systematic (formal) design methods have been developed– e.g., BNF for formal description of

language syntax

Ch. 3 27

Separation of concerns example• When designing optimal register

allocation algorithms (runtime efficiency) no need to worry about runtime diagnostic messages (user friendliness)

Ch. 3 28

Modularity

• Compilation process decomposed into phases– Lexical analysis– Syntax analysis (parsing)– Code generation

• Phases can be associated with modules

Ch. 3 29

Representation of modular structure

Ch. 3 30

Lexicalanalysis

Parsetree

Sourcecode

Symboltable

Objectcode

“Tokenized”code

Parsing Codegeneration

Lexicaldiagnostics

Syntax diagnosticsboxes represent modulesdirected lines represent interfaces

Module decomposition may be iterated

Ch. 3 31

Intermediate code generation Parse

tree

Object code

Code genration

Intermediate code

Symbol table

Machine code generation

further modularization of code-generation module

Abstraction

• Applied in many cases– abstract syntax to neglect syntactic

details such as begin…end vs. {…} to bracket statement sequences

– intermediate machine code (e.g., Java bytecode) for code portability

Ch. 3 32

Anticipation of change

• Consider possible changes of– source language (due to

standardization committees)– target processor– I/O devices

Ch. 3 33

Generality

• Parameterize with respect to target machine (by defining intermediate code)

• Develop compiler generating tools (compiler compilers) instead of just one compiler

Ch. 3 34

Incrementality

• Incremental development– deliver first a kernel version for a

subset of the source language, then increasingly larger subsets

– deliver compiler with little or no diagnostics/optimizations, then add diagnostics/optimizations

Ch. 3 35

Case study (system engineering): elevator system

• In many cases, the "software engineering" phase starts after understanding and analyzing the "systems engineering” issues

• The elevator case study illustrates the point

Ch. 3 36

Rigor & formality

• Quite relevant: it is a safety critical system– Define requirements

• must be able to carry up to 400 Kg. (safety alarm and no operation if overloaded)

• emergency brakes must be able to stop elevator within 1 m. and 2 sec. in case of cable failures

– Later, verify their fulfillment

Ch. 3 37

Separation of concerns

• Try to separate– safety– performance– usability (e.g, button illumination)– cost

• although some are strongly related– cost reduction by using cheap

material can make solution unsafe

Ch. 3 38

A modular structure

Ch. 3 39

Elevator

Control apparatus

B3

B2

B1

buttons at floor i

Module decomposition may be iterated

Ch. 3 40

Elevator Engine

BrakesCabin

Internal Buttons

Control apparatus

Abstraction

• The modular view we provided does not specify the behavior of the mechanical and electrical components– they are abstracted away

Ch. 3 41

Anticipation of change, Generality• Make the project parametric wrt the

number of elevators (and floor buttons)

Ch. 3 42

Elevators

Control apparatus

Floor buttons

Concluding remarks• We analyzed seven principles• They are cornerstones of sw design

– However, they are abstract

• Principles are important because– As technology evolves methods and

techniques will evolve, less rapidly than tools

– Principles will remain stable constituting the foundation upon which all the rest may be built

Ch. 3 43