Computer-aided software engineering CASE technology

z Production-process support technology

z Software tool support for • Tools to support development activities such as
specification, design, implementation, etc.
software development z Process management technology
• Tools to support process modeling and
management
z Meta-CASE technology
• Generators used to produce CASE toolsets

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 2

Impact of CASE technology CASE classification

z CASE technology has resulted in significant z CASE systems can be classified according to
improvements in quality and productivity their
z However, the scale of these improvements is • Functionality - what functions do they provide
less than was initially predicted by early • Process support - what software process activities
technology developers do they support
• Many software development problems such as • The breadth of support which they provide
management problems are not amenable to z Classification allows tools to be assessed and
automation compared
• CASE systems are not integrated
• Adopters of CASE technology underestimated the
training and process adaptation costs

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 3 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 4

Functional tool classification Activity-based tool classification

Tool type
Planning tools
Editing tools
Change management tools
Configuration management tools
Prototyping tools
Method-support tools
Language-processing tools
Re-engineering tools
Examples
Testing tools
PERT tools, estimation tools, spreadsheets
Debugg ing tools
Text editors, diagram editors, word processors
Prog ram analysis tools
Requirements traceability tools, change control systems Language-processing
tools
Version management systems, system building tools
Method suppor t tools
Very high-level languages, user interface generators
Prototyping tools
Design editors, data dictionaries, code generators
Configuration
Compilers, interpreters management tools

Change management tools

Program analysis tools Cross reference generators, static analysers, dynamic analysers
Documentation tools
Testing tools Test data generators, file comparators
Editing tools
Debugging tools Interactive debugging systems
Planning tools
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems Specification Design Implementation Verification
and
V alidation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 5 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 6
 Quality of CASE support CASE integration

Quality of tool support z Tools

Excellent • Support individual process tasks such as design
consistency checking, text editing, etc.
Good z Workbenches
• Support a process phase such as specification or
Moderate
design, Normally include a number of integrated
tools.

Poor
z Environments
• Support all or a substantial part of an entire
software process. Normally include several
Requirements Formal Function- Data Testing Maintenance
integrated workbenches.
Object-oriented
definition Specification oriented modeling design Programming Management
design

Activity
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 7 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 8

Tools, workbenches, environments CASE workbenches

z A set of tools which supports a particular

phase in the software process
z Tools work together to provide comprehensive
support
z Common services are provided which are
used by all tools and some data integration is
supported

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 9 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 10

Types of workbench Programming workbenches

z Programming, design and testing z A set of tools to support program development

workbenches z First CASE workbenches. Include compilers,
z Other types of workbench are linkers, loaders, etc.
• Cross-development workbenches for host-target z Programming workbenches are often
development integrated around an abstract program
• Configuration management workbenches representation (the abstract syntax tree) which
Documentation workbenches for producing
allows for tight integration of tools
professional system documentation
• Project management workbenches. z Integration around shared source-code files is
also possible

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 11 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 12
 Design and analysis workbenches An analysis and design workbench
Structured Report
z Support the generation of system models Data
diagramming generation
dictionary
during design and analysis activities tools facilities

z Usually intended to support a specific

structured method
Central Query
z Provide graphical editors plus a shared Code
generator
information language
repository facilities
repository
z May include code generators to create source
code from design information Design, analysis
Forms
and checking Import/export
creation
tools facilities
tools

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 13 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 14

Testing workbenches A testing workbench

Test data
Specification
generator
z Testing is an expensive process phase.
Testing workbenches provide a range of tools
Source Test
to reduce the time required and total testing code manager Test data Oracle

costs
z Most testing workbenches are open systems Dynamic
analyser
Program
being tested
Test
results
Test
predictions
because testing needs are organization-
specific
z Difficult to integrate with closed design and Execution
report
Simulator
File
comparator
analysis workbenches
Report Test results
generator report

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 15 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 16

Workbench advantages Meta-CASE

z Generally available on relatively cheap z Design and analysis workbenches are

personal computers
z Results in standardized documentation for
software systems
z Estimated that productivity improvements of
40% are possible with fewer defects in the
completed systems
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4
conceptually similar. Often the differences are
only in the diagram types supported and the
method rules and guidelines
z Programming workbenches are integrated
around a syntax representation which may be
separately defined
z Meta-CASE workbenches are tools which
assist the process of creating workbenches.
They reduce the costs of CASE workbench
creation
Slide 17 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 18
 The CASE life cycle A CASE life cycle model

z Procurement
z Tailoring
CASE system CASE system CASE system
z Introduction procurement tailoring introduction
z Operation
z Evolution
z Obsolescence CASE system CASE system CASE system
operation evolution obsolescence

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 19 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 20

CASE procurement CASE system tailoring

z Existing company standards and methods z Installation
• The environment must support existing practice • Set system dependent hardware and software
z Existing and future hardware parameters
• The environment must be compatible with existing z Process model definition
hardware. It should run on industry-standard • Define the activities that the environment is to
machines support
z The class of application to be developed z Tool integration
• The environment should support the principal type • Describe what tools are to be part of the
of application developed by an organization environment and how they are to be integrated
z Security z Documentation
• The environment should provide appropriate • Provide appropriate, in-house documentation for
access control facilities using the environment
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 21 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 22

CASE introduction and operation CASE system evolution

z May require changes to working practice
• User resistance because of conservatism or a feeling
that environments are for managers rather than
engineers
• Lack of training. Organisations often don't invest
enough in training
• Management resistance. Managers may not see how
the environment will reduce project costs
z Migrate projects slowly to the CASE system
• New projects should start with the environment after
initial pilot projects have demonstrated its advantages
• It is usually impractical to convert existing projects to
the CASE system
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4
z As the system is used, new requirements arise
• Process requirements. Changes in the process
model will be identified
• Tool requirements. New tools will become
available and will have to be incorporated
• Data requirements. The data organisation will
evolve
z An evolution budget must be available or the
environment will become progressively less
useful
z Forward compatibility must be maintained
Slide 23 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 24
 CASE system obsolescence

z At some stage, an environment will outlive its

usefulness and will have to be replaced
z Replacing an environment must be planned
and should take place over an extended time
period
z Currently supported projects must be moved to
a new environment before their supporting
environment is scrapped

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 25