Upload
linette-booth
View
220
Download
3
Tags:
Embed Size (px)
Citation preview
Ch 03 1
Software Engineering Principles
Ch 03 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 03 3
Some definitions• Methods:
– General guidelines that govern the execution of some activity; methods are rigorous, systematic, and disciplined approaches.
• Technique:– Techniques and methods are used interchangeably.– Techniques are more technical and mechanical than
methods; often they also have more restricted applicability.
– Methods and techniques are packaged to form methodology.
• Methodology:– used to promote a certain approach to solving a problem
by pre-selecting the methods and techniques to be used.
• Tools:– Developed to support the application of techniques,
methods, and methodologies.
Ch 03 4
A visual representation
Principles
Methodologies
Principles
Methods and techniques
Methodologies
Tools
• Principles apply to process and product• Principles become practice through methods and techniques
Ch 03 5
Key principles
• Rigor and formality• Separation of concerns• Modularity• Abstraction• Anticipation of change• Generality• Incrementality
Ch 03 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 03 7
Examples: product
• Mathematical (formal) analysis of program correctness– By specifying the program using a formal
specification (Z, B-method, Temporal logic, ..) and check specific properties.
• Systematic (rigorous) test data derivation:– Test data that covers most significant cases.
Ch 03 8
Example: process
• Rigorous documentation of development steps helps project management and assessment of timeliness
Ch 03 9
Separation of concerns• Tackles with the complexity of large
systems, by separating different issues to concentrate on one at a time (Divide & Conquer)
• Supports parallelization of efforts and separation of responsibilities.
• Separation of concern at functional and non-functional activities:– Functional (views): function, data, network,
deployment, process, etc.
– Non-functional (qualities): correctness, efficiency, reliability, etc.
Ch 03 10
Example: process / product
• Process: go through phases one after the other (as in waterfall)
– Applies separation of concerns by separating activities with respect to time
• Product: keep product requirements separate– functionality– performance– user interface and usability
Ch 03 11
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 03 12
Cohesion and coupling
• Each module should be highly cohesive– module must be understandable as a meaningful
unit (i.e., it provides a single functionality)
– Elements (i.e., functions) of a module are closely related to one another, in terms of sharing similar attributes.
• Modules should exhibit low coupling– modules have low interactions with others– understandable separately– More maintainable, low change propagation
Ch 03 13
A visual representation
(a)(b)
high coupling low coupling
Ch 03 14
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 03 15
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 03 16
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 03 17
An example
• Programming language grammar described through an abstract syntax (e.g., statement, expression, term) ignores details of different programs that can be generated by the same grammar.
– abstraction ignores details such as precision of number representation or addressing mechanisms
Ch 03 18
Abstraction in process
• When we do cost estimation we only take some key factors into account
• We reuse the results of previous similar cases for the new cost estimation, and ignore the differences among similar cases.
Ch 03 19
Anticipation of change• A basis for software evolution that requires
anticipating potential future changes
• Examples: – Set up a configuration management environment for
the project to take care of different changes in future (vs. having a fix system configuration).
– Anticipate the expansion of a company by considering reserve fields for the attributes of different stakehoders in the company.
– In desinging MicroProcessors, several registered are reserved for future expansions (versions) of the processor.
Ch 03 20
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
• E.g., defining a general tree traversal algorithm that receives a tree and a method of traversal (pre-order, in-order, post-order) to traverse every tree. As opposed to define three different methods. Even more general, to desing an Iterator algorithm.
Ch 03 21
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 and other (non-functional) qualities.
– deliver a first prototype and then incrementally add effort to turn prototype into product
Ch 03 22
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
Cas
e St
udy:
Com
pile
r
Ch 03 23
Separation of concerns: examples
• Functional qualities:– When designing different components of a
compiler, you concentrate on one at a time. For example, in designing lexical scanner to tokenize program’s text, you don’t consider the method of parsing (e.g., LR, LL, or LALR parser).
• Non-functional qualities:– When designing optimal register allocation
algorithms (runtime efficiency) no need to worry about runtime diagnostic messages (user friendliness)
Cas
e St
udy:
Com
pile
r
Ch 03 24
Modularity example
• Compilation process decomposed into phases– Lexical analysis
– Syntax analysis (parsing)
– Code generation
• Phases can be associated with modules
Cas
e St
udy:
Com
pile
r
Ch 03 25
Representation of modular structure
Boxes represent modules, andarrows represent flow of data
Cas
e St
udy:
Com
pile
r
Lexicalanalysis
Parsetree
Sourcecode
Symboltable
Objectcode
“Tokenized”code
Parsing Codegeneration
Lexicaldiagnostics
Syntax diagnostics
Languagegrammar
Ch 03 26
Module decomposition may be iterated
Intermediatecode generationParse
tree
Objectcode
Codegenration
Intermediatecode
Symbol table
Machine codegeneration
further modularization of code-generation module
Cas
e St
udy:
Com
pile
r
Ch 03 27
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
Cas
e St
udy:
Com
pile
r
Ch 03 28
Anticipation of change
• Consider possible changes of:
– source language (due to standardization committees)
– target processor
– I/O devices
Cas
e St
udy:
Com
pile
r
Ch 03 29
Generality
• Parameterize with respect to target machine (by defining intermediate code)
• Develop compiler generating tools (compiler compilers) instead of just one compiler:– Given a language Grammar the tool
produces a language to parse
Cas
e St
udy:
Com
pile
r
Ch 03 30
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
Cas
e St
udy:
Com
pile
r
Ch 03 31
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
Cas
e St
udy:
Ele
vato
r
Ch 03 32
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
Cas
e St
udy:
Ele
vato
r
Ch 03 33
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
Cas
e St
udy:
Ele
vato
r
Ch 03 34
A modular structure
Elevator
Control apparatus
B3
B2
B1
buttons at floor i
Cas
e St
udy:
Ele
vato
r
Ch 03 35
Module decomposition may be iterated
Elevator Engine
BrakesCabin
Internal Buttons
Control apparatus
Cas
e St
udy:
Ele
vato
r
Ch 03 36
Abstraction
• The modular view we provided does not specify the behavior of the mechanical and electrical components– they are abstracted awayC
ase
Stud
y: E
leva
tor
Ch 03 37
Anticipation of change, generality
• Make the project parametric with respect to the number of elevators (and floor buttons)
Elevators
Controlapparatus
Floorbuttons
Cas
e St
udy:
Ele
vato
r