![Page 1: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/1.jpg)
Ch. 3 1
Software Engineering Principles
![Page 2: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/2.jpg)
Ch. 3 2
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
![Page 3: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/3.jpg)
Ch. 3 3
Application of principles
• Principles apply to process and product
• Principles become practice through methods and techniques– often methods and techniques are
packaged in a methodology– methodologies can be enforced by
tools
![Page 4: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/4.jpg)
Ch. 3 4
A visual representation
Principles
Methodologies
Principles
Methods and techniques
Methodologies
Tools
![Page 5: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/5.jpg)
Ch. 3 5
Key principles
• Rigor and formality• Separation of concerns• Modularity• Abstraction• Anticipation of change• Generality• Incrementality
![Page 6: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/6.jpg)
Ch. 3 6
Rigor and formality• Software engineering is a creative
design activity, BUT• It must be practiced systematically• Rigor is a necessary complement to
creativity that increases our confidence in our developments
• Formality is rigor at the highest degree– software process driven and evaluated
by mathematical laws
![Page 7: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/7.jpg)
Ch. 3 7
Examples: product
• Mathematical (formal) analysis of program correctness
• Systematic (rigorous) test data derivation
![Page 8: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/8.jpg)
Ch. 3 8
Example: process
• Rigorous documentation of development steps helps project management and assessment of timeliness
![Page 9: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/9.jpg)
Ch. 3 9
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
![Page 10: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/10.jpg)
Ch. 3 10
Example: process• Go through phases one after the
other (as in waterfall)
– Does separation of concerns by separating activities with respect to time
Feasibility study
Requirements
Design
Coding and module testing
Integration and system testing
Delivery, deployment, and maintenance
![Page 11: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/11.jpg)
Ch. 3 11
Example: product
• Keep product requirements separate– functionality– performance– user interface and usability
![Page 12: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/12.jpg)
Ch. 3 12
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
![Page 13: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/13.jpg)
Ch. 3 13
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
![Page 14: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/14.jpg)
Ch. 3 14
A visual representation
(a) (b)
high coupling low coupling
![Page 15: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/15.jpg)
Ch. 3 15
Abstraction• Identify the important aspects of a
phenomenon and ignore its details• Special case of separation of
concerns• The type of abstraction to apply
depends on purpose• Example : 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
![Page 16: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/16.jpg)
Ch. 3 16
Abstraction ignores details
• Example: equations describing complex circuit (e.g., amplifier) allows designer to reason about signal amplification
• Equations may approximate description, ignoring details that yield negligible effects (e.g., connectors assumed to be ideal)
![Page 17: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/17.jpg)
Ch. 3 17
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
![Page 18: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/18.jpg)
Ch. 3 18
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
![Page 19: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/19.jpg)
Ch. 3 19
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
![Page 20: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/20.jpg)
Ch. 3 20
Anticipation of change
• Ability to support software evolution requires anticipating potential future changes
• It is the basis for software evolvability
• Example: set up a configuration management environment for the project
![Page 21: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/21.jpg)
Ch. 3 21
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
• Carefully balance generality against performance and cost
• Sometimes a general problem is easier to solve than a special case
![Page 22: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/22.jpg)
Ch. 3 22
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
![Page 23: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/23.jpg)
Ch. 3 23
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
![Page 24: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/24.jpg)
Ch. 3 24
Separation of concerns example
• When designing optimal register allocation algorithms (runtime efficiency) no need to worry about runtime diagnostic messages (user friendliness)
![Page 25: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/25.jpg)
Ch. 3 25
Modularity
• Compilation process decomposed into phases– Lexical analysis– Syntax analysis (parsing)– Code generation
• Phases can be associated with modules
![Page 26: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/26.jpg)
Ch. 3 26
Representation of modular structure
Lexicalanalysis
Parsetree
Sourcecode
Symboltable
Objectcode
“Tokenized”code
Parsing Codegeneration
Lexicaldiagnostics
Syntax diagnosticsboxes represent modulesdirected lines represent interfaces
![Page 27: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/27.jpg)
Ch. 3 27
Module decomposition may be iterated
Intermediate code generation Parse
tree
Object code
Code genration
Intermediate code
Symbol table
Machine code generation
further modularization of code-generation module
![Page 28: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/28.jpg)
Ch. 3 28
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
![Page 29: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/29.jpg)
Ch. 3 29
Anticipation of change
• Consider possible changes of– source language (due to
standardization committees)– target processor– I/O devices
![Page 30: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/30.jpg)
Ch. 3 30
Generality
• Parameterize with respect to target machine (by defining intermediate code)
• Develop compiler generating tools (compiler compilers) instead of just one compiler
![Page 31: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/31.jpg)
Ch. 3 31
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
![Page 32: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/32.jpg)
Ch. 3 32
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
![Page 33: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/33.jpg)
Ch. 3 33
Rigor&formality (1)
• 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
![Page 34: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/34.jpg)
Ch. 3 34
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
![Page 35: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/35.jpg)
Ch. 3 35
A modular structure
Elevator
Control apparatus
B3
B2
B1
buttons at floor i
![Page 36: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/36.jpg)
Ch. 3 36
Module decomposition may be iterated
Elevator Engine
BrakesCabin
Internal Buttons
Control apparatus
![Page 37: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/37.jpg)
Ch. 3 37
Abstraction
• The modular view we provided does not specify the behavior of the mechanical and electrical components– they are abstracted away
![Page 38: Fundamentals of Software Engineering 2nd Edition Chapter 3](https://reader034.vdocument.in/reader034/viewer/2022052308/55cf8ef8550346703b979428/html5/thumbnails/38.jpg)
Ch. 3 38
Anticipation of change, generality
• Make the project parametric wrt the number of elevators (and floor buttons)
Elevators
Control apparatus
Floor buttons