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?

Ch. 3 3

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 applciations methods + 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

Tools Methods and techniques because of non-expert users or a critical application • Qualities: reliability & evolvability  • creates basic need for sw eng.

affects our discussion in principles, methods, and techniques Ch. 3 5

Key principles of sw development

• Rigor and formality • Separation of concerns • Modularity • Abstraction • Anticipation of change • Generality • Incrementality Not 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 • By a rigorous approach – control their costs – increase confidence in reliability assessment of results  a necessary complement to creativity in engineering – repeatedly produce reliable products • Rigor does not need to constrain creativity, rather enhance it – Can only be confident of a creative process after a rigorous Ch. 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 need formal description of fcns & formal approach for assessment Ch. 3 8

Rigor and formality

• Definition by natural language must be done rigorously • Also can be done by a language of logical statements formally • ! Programming  • ! Programs  a formal approach 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)

Product features

Offered functions Expected reliability Efficiency in space&time Relationship w/ environment

Development process

Development environment Organization of temas Scheduling Design strategies

Economic & financial matters

Cost of the product Initial budget Foreseen completion time Error recovery mechanisms Ch. 3 11

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 • 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  modules bottom-up desing • Decomposition  top-down approach Ch. 3 15

Modularity

Main benefits of modularity 1. Capability of decomposing a complex system into simpler pieces 2. Capability of composing a complex system from existing modules 3. Capability of understanding the system in terms of its pieces 4. 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

(a) high coupling Ch. 3 (b) low coupling 18

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 cost  higher reusability • Carefully balance generality against performance and • 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

Lexical diagnostic s Source code Lexical analysis Symbol table Parsing Code generation Parse tree “Tokenized” code boxes represent modules directed lines represent interfaces Ch. 3 Syntax diagnostics Object code 30

Module decomposition may be iterated

further modularization of code-generation module Symbol table Code genration Parse tree Intermediate code generation Intermediate code Machine code generation Object code Ch. 3 31

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

compiler ) instead of just one 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

Control apparatus buttons at floor i B3 Elevator B2 Ch. 3 B1 39

Module decomposition may be iterated

Control apparatus Elevator Engine Brakes Cabin Internal Buttons Ch. 3 40

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) Control apparatus Elevators Floor buttons Ch. 3 42

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