Software Engineering Tools and Environments Ch. 9 1 Outline How - - PowerPoint PPT Presentation

• Ch. 9

1

Software Engineering Tools and Environments

• Ch. 9

2

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

3

Historical evolution

• Dominant factors affecting evolution

– technological developments

• made certain tools necessary or possible

– better understanding of software engineering processes

• Ch. 9

4

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

5

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

6

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

7

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

8

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

9

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

10

Representative tools: Interpreters

• Traditionally at the programming

language level

• Also at the requirements specification

level

– requirements animation

• Can be numeric or symbolic

• Ch. 9

11

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

12

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

13

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: Test case description: Description of results: Tested module: Comments:

• Ch. 9

14

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

15

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

16

Representative tools: GUI tools

• Graphical User Interfaces are now

standard

• Common abstractions include

– windows and the desktop metaphor

Pole disks 1 3

2 3

• Ch. 9

17

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

18

UIMS as development tool and end-product component Run-time dialog component Dialog development tools Progr. language run-time support End user Developer Progr. env.mt

• Ch. 9

19

Run-time structure of a UIMS

SCREEN

First name Last name Birth date day month year Person First nameLast nameBirth date Day Month Year Run-time dialog component

INTERNAL DATA STRUCTURE

• Ch. 9

20

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

21

CVS

1.1 1.2 1.3 1.4 1.1 1.2 1.3 1.2.1.1 1.2.1.2 2.1 2.1 2.2

sequence of revisions a branch and a later join

• Ch. 9

22

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

23

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

24

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

25

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

26

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

27

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

• ther through control messages

• Ch. 9

28

Forces influencing tool evolution

• To support new technology
• To support new software processes
• To support a particular method or

methodology