Software Engineering Principles Ch. 31

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. 32

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. 33 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 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. 34

A visual representation Ch. 35 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 Incrementality Not an exhaustive list! They are all related. Ch. 36

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 results Ch. 37

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. 38 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. 39

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. 310

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. 311 Product featuresDevelopment processEconomic & financial matters Offered functionsDevelopment environmentCost of the product Expected reliabilityOrganization of temasInitial budget Efficiency in space&time SchedulingForeseen 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. 312

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. 313

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. 314

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. 315

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. 316

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. 317

A visual representation Ch. 318 high couplinglow 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. 319

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. 320

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. 321

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. 322

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. 323

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. 324

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. 325

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. 326

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. 327

Separation of concerns example When designing optimal register allocation algorithms (runtime efficiency) no need to worry about runtime diagnostic messages (user friendliness) Ch. 328

Modularity Compilation process decomposed into phases –Lexical analysis –Syntax analysis (parsing) –Code generation Phases can be associated with modules Ch. 329

Representation of modular structure Ch. 330 boxes represent modules directed lines represent interfaces

Module decomposition may be iterated Ch. 331 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. 332

Anticipation of change Consider possible changes of –source language (due to standardization committees) –target processor –I/O devices Ch. 333

Generality Parameterize with respect to target machine (by defining intermediate code) Develop compiler generating tools (compiler compilers) instead of just one compiler Ch. 334

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. 335

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. 336

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. 337

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. 338

A modular structure Ch. 339 Elevator Control apparatus B3 B2 B1 buttons at floor i

Module decomposition may be iterated Ch. 340

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

Anticipation of change, Generality Make the project parametric wrt the number of elevators (and floor buttons) Ch. 342

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. 343