fundamentals of software engineering 2nd edition chapter 3
DESCRIPTION
The book introduces the student to the foundations of the field of software engineering. The first edition of this book was published in 1991 and was successfully used by many students and teachers over the years. The second edition maintains the structure of the first edition and updates the material based on the research developments in the last decade. Software engineering is evolving rapidly with changes in technologies and application areas. This book is about the principles and not the current hot topics. It helps the student cope with the rapid changes by presenting a firm foundation to the field. All phases of software are covered: requirements, architecture, design, and validation. It also presents process models and software tools.That principles form the basis of methods, techniques, methodologies and toolsThe importance of principles that remain true despite changes in technology and tools.The role of methodologies that package tools and techniques to encourage a particular approach to software development.The definitions and importance of the following seven principles, which may be used in all phases of software development and in designing software processes: rigor and formality, separation of concerns, modularity, abstraction, anticipation of change, generality, and incrementality.How to apply the seven principles and recognize the relationships among them.The importance of modularity as the cornerstone principle supporting software design.TRANSCRIPT
Ch. 3 1
Software Engineering Principles
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
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
Ch. 3 4
A visual representation
Principles
Methodologies
Principles
Methods and techniques
Methodologies
Tools
Ch. 3 5
Key principles
• Rigor and formality• Separation of concerns• Modularity• Abstraction• Anticipation of change• Generality• Incrementality
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
Ch. 3 7
Examples: product
• Mathematical (formal) analysis of program correctness
• Systematic (rigorous) test data derivation
Ch. 3 8
Example: process
• Rigorous documentation of development steps helps project management and assessment of timeliness
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
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
Ch. 3 11
Example: product
• Keep product requirements separate– functionality– performance– user interface and usability
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
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
Ch. 3 14
A visual representation
(a) (b)
high coupling low coupling
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
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)
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
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
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
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
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
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
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
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)
Ch. 3 25
Modularity
• Compilation process decomposed into phases– Lexical analysis– Syntax analysis (parsing)– Code generation
• Phases can be associated with modules
Ch. 3 26
Representation of modular structure
Lexicalanalysis
Parsetree
Sourcecode
Symboltable
Objectcode
“Tokenized”code
Parsing Codegeneration
Lexicaldiagnostics
Syntax diagnosticsboxes represent modulesdirected lines represent interfaces
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
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
Ch. 3 29
Anticipation of change
• Consider possible changes of– source language (due to
standardization committees)– target processor– I/O devices
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
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
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
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
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
Ch. 3 35
A modular structure
Elevator
Control apparatus
B3
B2
B1
buttons at floor i
Ch. 3 36
Module decomposition may be iterated
Elevator Engine
BrakesCabin
Internal Buttons
Control apparatus
Ch. 3 37
Abstraction
• The modular view we provided does not specify the behavior of the mechanical and electrical components– they are abstracted away
Ch. 3 38
Anticipation of change, generality
• Make the project parametric wrt the number of elevators (and floor buttons)
Elevators
Control apparatus
Floor buttons