Software Engineering Tools

and Environments

Ch. 9 1
 Outline
• How did the field evolve?
• How can tools and environments be
classified and compared?
• What are the main categories?
• How can tools be integrated?
• What motivates new tools/environments?

Ch. 9 2
 Historical evolution
• Dominant factors affecting evolution
– technological developments
• made certain tools necessary or possible
– better understanding of software
engineering processes

Ch. 9 3
 Technological developments
—examples—
• Advances in graphical displays and user
interfaces
– graphical editors
– graphical user interfaces (GUIs)
– visual languages
• Advances in distributed systems
– tools supporting distributed configuration
management and teams (groupware)

Ch. 9 4
 Evolution
• Individual tools developed to support single
activities (e.g.,compilation, debugging)
→Integrated environments, i.e., tools that work
together
– e.g., environment supporting one programming
language
→Open environments
– tools have public interfaces which allow them to
communicate and cooperate with other tools
which respect those interfaces

Ch. 9 5
Dimensions for comparison (1)
• Interaction mode
– batch-oriented tools
– interactive tools
• Level of formality
– syntax/semantics of documents produced
• Dependency on phase of life cycle
• Degree of standardization
Ch. 9 6
Dimensions for comparison (2)
• Static vs. dynamic
• Development tools vs. end-product
components
• Single-user vs. multi-user
• Single-machine vs. network-aware

Ch. 9 7
 Representative tools:
Editors
• Textual or graphical
• Can follow a formal syntax, or can be
used for informal text or free-form
pictures
• Monolingual (e.g., Java editor) or
multilingual

Ch. 9 8
 Representative tools:
Linkers
• Combine object-code fragments into a
larger program
– can be monolingual or polylingual
• In a broader sense, tools for linking
specification modules, able to perform
checking and binding across various
specification modules

Ch. 9 9
 Representative tools:
Interpreters
• Traditionally at the programming
language level
• Also at the requirements specification
level
– requirements animation
• Can be numeric or symbolic

Ch. 9 10
 Representative tools:
Code generators
• In a general sense, transform a high
level description into a lower-level
description
– a specification into an implementation
• Practical example
– 4th Generation Languages

Ch. 9 11
 Representative tools:
Debuggers
• May be viewed as special kinds of
interpreters where
– execution state inspectable
– execution mode definable
– animation to support program
understanding

Ch. 9 12
 Representative tools:
Software testing (1)
• Test documentation tools
– support bookkeeping of test cases
• forms for test case definition, storage, retrieval

Project Name: Date of test:

Tested function:

Tested module:

Test case description:

Description of results:

Comments:

Ch. 9 13
 Representative tools:
Software testing (2)
• Tools for test data derivation
– e.g., synthesizing data from path condition
• Tools for test evaluation
– e.g., various coverage metrics
• Tools for testing other software
qualities

Ch. 9 14
 Representative tools:
Static analyzers
• Data and flow control analyzers
– can point out possible flaws or suspicious-
looking statements
• e.g., detecting uninitialized variables

Ch. 9 15
 Representative tools:
GUI tools
• Graphical User Interfaces are now
standard
• Common abstractions include
– windows and the desktop metaphor
Pole disks
1 3
2 0
3 0

Ch. 9 16
User-Interface Management
Systems
• Provide a set of basic abstractions (windows,
menus, scroll bars, etc.) that may be used to
customize a variety of interfaces
• Provide a library of run-time routines to be
linked to the developed application in order to
support input and output
– UIMS fall both under the category of development
tools and under the category of end-product
components

Ch. 9 17
 UIMS as development tool and
end-product component

Progr.
language Run-time dialog End
run-time
support component user

Dialog
Progr. development Developer
env.mt tools

Ch. 9 18
 Run-time structure of a UIMS

INTERNAL DATA STRUCTURE

Person
SCREEN
First name Last name First nameLast nameBirth date

Day Month Year

day

Birth date month

Run-time
year dialog
component

Ch. 9 19
 Representative tools:
Configuration Management
• Repository
• shared database of artifacts
• Version management
• versions stored, change history maintained
• Work-space control
• check-out into private work-space
• check-in into shared work-space
• Product modeling and building
• facilities to (re)build products

Ch. 9 20
 CVS
1.1 1.2 1.3 1.4 2.1 2.2

sequence of revisions

1.1 1.2 1.3 2.1

a branch and a
later join

1.2.1.1 1.2.1.2

Ch. 9 21
 make
aids in building and rebuilding a product
helps keep a system in a consistent state after modifications

1. sys : mod1.o mod2.o

2. ld mod1.o mod2.o -o sys
3. mod1.o : mod1.c incl.h
4. cc -c mod1.c
5. mod2.o : mod2.c incl.h
6. cc -c mod2.c

Ch. 9 22
 Representative tools:
Tracking tools
• Used during entire process to maintain
information about the process and track
that information
• The most important of these are defect-
tracking tools
– used to store information about reported
defects in the software product and track
that information
Ch. 9 23
 Representative tools:
Reverse and reengineering
• Program understanding systems
– synthesize suitable abstractions from code
• e.g., control and data flow graphs or use graphs
– extract cross-references and other kinds of
documentation material on the product
• Reverse engineering tools also support the
process of making the code and other
artifacts consistent with each other

Ch. 9 24
 Representative tools:
Process support
• Maintain "to do" lists, reminding next
activities in the process
• Automate sequences of recurring
actions
• Full process support via PSEEs (Process-
centered Software Engineering
Environments)
– driven by a process-modeling language

Ch. 9 25
 Representative tools:
Management
• Tools for Gantt and PERT charts
– graphical interface
– support to analysis
• Cost estimation tools
– based on models, such as COCOMO

Ch. 9 26
 Tool integration
• Data integration approach
– store all process artifacts in a repository
– common data representation for artifacts
that different tools can use to
communicate with each other
• Control integration approach
– different tools can communicate with each
other through control messages
Ch. 9 27
 Forces influencing tool
evolution
• To support new technology
• To support new software processes
• To support a particular method or
methodology

Ch. 9 28