Software Engineering Tools - PowerPoint PPT Presentation

Loading...

PPT – Software Engineering Tools PowerPoint presentation | free to view - id: 2715c2-N2NhM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Software Engineering Tools

Description:

'Postpone decisions as to details as late as possible to be able ... Surprisingly, some programmers still implement code Ye Olde-Fashioned Way. Software Versions ... – PowerPoint PPT presentation

Number of Views:65
Avg rating:3.0/5.0
Slides: 47
Provided by: coursew
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com