Software Engineering Tools

1
Software Engineering Tools

• MOE 225 Software Engineering
• Topic 6

2
Stepwise Refinement

• A basic principle underlying many software
  engineering techniques
• Postpone decisions as to details as late as
  possible to be able to concentrate on the
  important issues
• Millers law (1956)
• A human being can concentrate on 72 items at a
  time

3
Stepwise Refinement Case Study

• Design a product to update a sequential master
  file containing name and address data for monthly
  magazine True Life Software Disasters
• Three types of transactions
• Type 1 INSERT (new subscriber into master file)
• Type 2 MODIFY (existing subscriber record)
• Type 3 DELETE (existing subscriber record)
• Transactions are sorted into alphabetical order,
  and by transaction code within alphabetical order

4
Typical file of input transactions
5
Decompose Process

• No further refinement is possible

6
First Refinement
7
Stepwise Refinement Case Study (contd)

• Assumption
• We can produce a record when PROCESS requires it
• Separate INPUT and OUTPUT, concentrate on PROCESS
• What is this PROCESS?

8
Second Refinement
9
Third Refinement

• This design has a major fault

10
Stepwise Refinement Case Study (contd)

• The third refinement is WRONG
• Modify JONES followed by Delete JONES
• After the third refinement has been corrected
• Details like opening and closing files have been
  ignored up to now
• Fix after the logic of the design is complete
• The stage at which an item is handled is vital
• Opening and closing files is
• Ignored in early steps, but
• Essential later

11
Appraisal of Stepwise Refinement

• A basic principle used in
• Every phase
• Every representation
• The power of stepwise refinement
• The software engineer can concentrate on the
  relevant aspects
• Warning
• Millers Law is a fundamental restriction on the
  mental powers of human beings

12
CostBenefit Analysis

• Compare estimated future benefits, costs
• Estimate costs
• Estimate benefits
• State all assumptions explicitly

13
Software Metrics

• To detect problems early, it is essential to
  measure
• Examples
• Lines of code (LOC) per month
• Defects per 1000 LOC

14
Different Types of Metrics

• Product Metrics
• Examples
• Size of product
• Reliability of product
• Process Metrics
• Example
• Efficiency of fault detection during development
• Metrics specific to a given phase
• Example
• Number of defects detected per hour in
  specification reviews

15
The Five Basic Metrics

• Size
• In Lines of Code, or better
• Cost
• In dollars
• Duration
• In months
• Effort
• In person months
• Quality
• Number of faults detected

16
CASE (Computer-Aided Software Engineering)

• Scope of CASE
• Can support the entire life-cycle
• Graphical display tools (many for PCs)
• Data flow diagrams
• Entity-relationship diagrams
• Module-interconnection diagrams
• Petri nets
• Structure charts

17
Automated process support (CASE)

• Computer-aided software engineering (CASE) is
  software to support software development and
  evolution processes
• Activity automation
• Graphical editors for system model development
• Data dictionary to manage design entities
• Graphical UI builder for user interface
  construction
• Debuggers to support program fault finding
• Automated translators to generate new versions of
  a program

18
Case technology

• Case technology has led to significant
  improvements in the software process though not
  the order of magnitude improvements that were
  once predicted
• Software engineering requires creative thought -
  this is not readily automatable
• Software engineering is a team activity and, for
  large projects, much time is spent in team
  interactions. CASE technology does not really
  support these

19
Taxonomy of CASE

• UpperCASE versus lowerCASE
• Tool versus workbench versus environment

20
CASE classification

• Classification helps us understand the different
  types of CASE tools and their support for process
  activities
• Functional perspective
• Tools are classified according to their specific
  function
• Process perspective
• Tools are classified according to process
  activities that are supported
• Integration perspective
• Tools are classified according to their
  organisation into integrated units

21
Functional tool classification
22
Activity-based classification
23
CASE integration

• Tools
• Support individual process tasks such as design
  consistency checking, text editing, etc.
• Workbenches
• Support a process phase such as specification or
  design, Normally include a number of integrated
  tools
• Environments
• Support all or a substantial part of an entire
  software process. Normally include several
  integrated workbenches

24
Tools, workbenches, environments
25
Graphical Tool

• Additional features
• Data dictionary
• Screen and report generators
• Consistency checker the various views are always
  consistent
• Specifications and design workbench
• Online Documentation
• Problems with
• Manuals
• Updating
• Essential online documentation
• Help information
• Programming standards
• Manuals

26
Essential Coding Tools

• Coding tools
• Products (such as text editors, debuggers, and
  pretty printers) designed to
• Simplify programmers task
• Reduce frustration
• Increase programmer productivity
• Conventional coding scenario for
  programming-in-the-small
• Editor-compiler cycle
• Editor-compiler-linker cycle
• Editor-compiler-linker-execute cycle
• There must be a better way

27
Syntax-directed Editor

• Understands language
• Speeds up implementation
• User interface of an editor is different to that
  of a compiler
• There is no need to change thinking mode
• No mental energy is wasted on these adjustments
• One piece of system software, two languages
• High-level language of module
• Editing command language
• Pretty-printer

28
Online Interface Checker

• Example
• The programmer tries to call procedure
  computeAverage, but the linker cannot find it
• The programmer realizes that the actual name of
  the procedure is computeMean
• A structure editor must support online interface
  checking
• Editor must know name of every procedure
• Interface checking is an important part of
  programming-in-the-large

29
Online Interface Checker (contd)

• Example
• The user enters the call
• average computeAverage (dataArray,
  numberOfValues)
• Editor immediately responds with a message such
  as
• Procedure computeAverage not known
• Programmer is given two choices
• Correct the name of the procedure
• Declare new procedure computeAverage and specify
  its parameters
• Enables full interface checking

30
Online Interface Checker (contd)

• Example
• Declaration of q is
• void q (float floatVar, int intVar, String s1,
  String s2)
• Call (invocation) is
• q (intVar, floatVar, s1, s2)
• Online interface checker detects the fault
• Help facility
• Online information as to parameters of method q
• Better Editor generates a template for the call
• Shows type of each parameter
• Programmer replaces formal by actual parameter

31
Online Interface Checker (contd)

• Advantages
• No need for different tools with different
  interfaces
• Hard-to-detect faults are immediately flagged for
  correction
• Wrong number of parameters
• Parameters of wrong type
• Essential when software is produced by a team
• If one programmer changes the interface
  specification, all modules calling that changed
  module must be disabled

32
Online Interface Checker (contd)

• Remaining problem
• The programmer still has to exit from the editor
  to invoke the compiler (to generate code)
• Then, the linker must be called to link the
  product
• Must adjust to the JCL, compiler, and linker
  output

33
Operating System Front-End in Editor

• Single command
• go or run
• Use of the mouse to choose icon, or menu
  selection
• Causes editor to invoke the compiler, linker,
  loader, and execute the product

34
Operating System Front-End in Editor (contd)

• Online documentation
• Help information regarding
• Operating system
• Editor
• Programming language
• Programming standards
• Manuals
• Editor manuals
• Programming manuals

35
Source Level Debugger

• Example
• Product executes terminates abruptly and prints
• Overflow at 4B06, or
• Core dumped, or
• Segmentation fault

36
Source Level Debugger (contd)

• The programmer works in a high-level language,
  but must examine
• Machine code core dumps
• Assembler listings
• Linker listings
• Similar low-level documentation
• Destroys the advantage of programming in a
  high-level language
• We need
• Interactive source level debugger (like dbx)

37
Programming Workbench

• Structure editor with
• Online interface checking capabilities
• Operating system front-end
• Online documentation
• Source level debugger
• Constitutes a simple programming environment

38
Programming Workbench (contd)

• This is by no means new
• All the above features are supported by FLOW
  (1980)
• The technology has been in place for years
• Surprisingly, some programmers still implement
  code Ye Olde-Fashioned Way

39
Software Versions

• During maintenance, at all times there are at
  least two versions of the product
• The old version, and
• The new version
• Two types of versions revisions and variations

40
Revisions and Variations

• Revision
• Version to fix a fault in the module
• We cannot throw away an incorrect version
• Perfective and adaptive maintenance also results
  in revisions

41
Revisions and Variations (contd)

• Variation
• Version for different operating systemhardware
• Variations are designed to coexist in parallel

42
Configuration Control

• Every module exists in three forms
• Source code object code executable load image
• Configuration
• Version of each module from which a given version
  of a product is built

43
Version Control Tool

• Essential for programming-in-the-many
• First step toward configuration management
• Must handle
• Updates
• Parallel versions

44
Version Control Tool (contd)

• Possible notation
• printerDriver (laser) / 13
• printerDriver (inkJet) / 25
• Problem of multiple variations
• Deltas
• Version control is not enoughmaintenance issues

45
Configuration Control and Maintenance

• Two programmers working on the same module
• mDual / 16
• mDual / 17
• Baselines
• Private workspaces
• Freezing
• Configuration control during development
• Informal testing
• SQA

46
Build Tools

• Example
• UNIX make
• Compares the date and time stamp on
• Source code, object code
• Object code, executable load image
• Can check dependencies
• Ensures that correct versions/variations are
  compiled and linked