Analyst Workbenches. State of The Art Report

421 Pages·1987·7.9 MB·English

by  R. Rock-Evans (Eds.)

Analyst
workbenches
15:1
State of the Art Report
Pergamon Infotech Limited A member of the Pergamon Group Oxford New York Toronto Sydney Beijing Frankfurt
Published by
Pergamon Infotech Limited
Berkshire House Queen Street
Maidenhead Berkshire
England SL6 INF.
Telephone: [phone]
International + 44 628 39101
Telex: 847319
(Answerback INFO G)
Printed by
A Wheaton & Company Limited
Exeter Devonshire
England.
UDC 681.3
Dewey 658.505
ISBN 0 08 034111 X
© Pergamon Infotech Limited, 1987
All rights reserved. No part of this publication
may be reproduced, stored in a retrieval system,
or transmitted in any form or by any means,
electronic, mechanical, photographic, or other-
wise, without the prior permission of the copy-
right owner.
It should be noted that the copyright for the
Report as a whole belongs to Pergamon Infotech
Ltd. The copyright for individual contributions
belongs to the authors themselves.
iv
Foreword
Whenever a new software tool appears on the market, it always causes a wave of interest. Never is this
more true than when that tool looks as if it may change the way of working of DP professionals throughout
the UK, Europe and the US.
Analyst workbenches have generated a rash of publicity and a host of feature articles, both in the popular
press and in the specialist magazines. This can be seen from looking through the Bibliography where many
of the references are to recent articles about workbench products.
Within the Analysis the editor has tried to examine not only the tasks and data that these workbenches
should support, but also to discuss their future and what they will support in five to 10 years time. She
has also tried to compile a comprehensive list of the available analyst workbenches—both the experimental
and the commercial products.
The Invited Papers have all been written by people who have had considerable involvement with analyst
workbenches. Some of the contributors have developed their own products, some are the architects of some
of the 'front-runners' and others work for, or own, the firms whose methodology is embodied within the
products. The Invited Papers show a remarkable similarity of view and agreement, both in the direction
being taken now and in the direction in which we should be going.
Perhaps for the first time the DP world has found a standard approach to its problems which works and
agreement, at least in principle, with the direction in which DP should be going.
R Rock-Evans: Editor
vii
Publisher's note
This Report is divided into three parts:
1 Invited Papers.
2 Analysis.
3 Bibliography.
The Invited Papers in this State of the Art Report examine various aspects of analyst workbenches. If a
paper cites references they are given at the end of the Invited Papers section, numbered in the range 1-99
but prefixed with the first three letters of the Invited Paper author's name.
The Analysis has the following functions:
1 Assesses the major advances in analyst workbenches.
2 Provides a balanced analysis of the state of the art in analyst workbenches.
The Analysis is constructed by the editor of the Report to provide a balanced and comprehensive view of
the latest developments in analyst workbenches. The editor's personal analysis of the subject is supple-
mented by quotations from the Invited Papers, written by leading authorities on the subject.
The following editorial conventions are used throughout the Analysis:
1 Material in Times Roman (this typeface) is written by the editor.
2 Material in Times Italic {this typeface) is contributed by the person or publication whose name precedes
it. The contributor's name is set in Times Italic. Numbers in parentheses in the ranges 001-099 or 100-199
following the name refer to the original source as specified in the Analysis references or the Bibliography,
respectively, which both follow the Analysis. References within the text are numbered in the same way.
A contributor's name without a reference refers to an Invited Paper published in this Report.
3 The quotations in the Analysis are arranged at the discretion of the editor to bring out key issues. Three
or four dots within a single quotation indicate that a portion of the original text has been removed by
the editor to improve clarity.
The Bibliography is a specially selected compilation of the most important published material on the subject
of analyst workbenches. Each key item in the literature is reviewed and annotated to assist in selecting the
required information.
ix
1: The ICL approach to
automating analysis and
design
A Beer
International Computers Ltd (ICL)
Reading
Berkshire
UK
ICL has for many years had a leading
data dictionary system. When it was first
introduced, in the late 1970s, this data
dictionary system made use of the tech-
nology available at the time. The environ-
ment in which a data dictionary is used has
changed in two respects—good-quality
graphics micros are now available which
can be used by analysts and programmers
alike; analysis and design methods have
been formalised and are now an accepted
part of the DP developer's toolkit. This
paper shows how ICL has integrated the
three aspects of dictionary, graphics and
a formal analysis and design method to
produce an up-to-date environment for the
development of computer applications.
© A Beer 1987
3
A Beer
Alan Beer is currently em-
ployed by ICL in their Man-
agement Support Business
Cer^re in Reading. He is
responsible for QuickBuild
developments and their intro-
duction into the marketplace. Mr Beer has 20 years
computing experience gained while working for
computer manufacturers, a major consultancy and
several user sites. His experience encompasses
database management systems, on-line processing,
including distributed processing, and Fourth
Generation languages. He has written and spoken
on various of the above topics at major seminars
throughout the world.
4
The ICL approach to automating
analysis and design
What do current approaches offer?
There is a lot of talk nowadays about 'What You See Is What You Get' (WYSIWYG). To the layman
it might seem that with current computer systems we can describe exactly what happens in the workplace,
all in easy-to-understand terms, and then magically produce a computer system to deal with it.
In reality, however, this cannot yet be achieved. For example, how do we interpret a picture of a lorry
delivering goods at a gate? Is the lorry arriving or leaving? Is it a factory or a warehouse? Does it happen
every day or twice a year? (Of course the really clever computer would read the date on the driver's digital
watch from the picture.) Current systems technology at International Computers Ltd (ICL) allows us to
draw pictorial representations of this event and to put sufficient text around it for the computer to generate
a working system from these details. However, to obtain the details normal analysis and design has to be
undertaken.
The ICL approach to analysis and design
The ICL approach starts off with the assumption that the best way to build better computer applications
is to look at the business view first and to worry about the implementation detail afterwards. If early on
there is a clear idea of user requirements there is less chance of error in the later stages. If the user is involved
in an ongoing manner the system will be better and will be used in a better way.
Analysis and design involves taking the user requirements and interpreting them in such a way as to:
• Match them to business requirements so that the resulting system is appropriate for company needs
• Produce a supportive system which will enable the user to perform his job more effectively.
Analysis and design therefore involves a certain amount of fact gathering, specifically about what the user
wants, how he currently performs his tasks and how things could be improved. Similarly, where a new
system is to interact with existing systems the fact gathering is related to how these systems perform and
to what information they use and/or contain. Where existing systems are properly documented in a
dictionary this latter phase is much easier, in that it is itself automated. Later examples show this analysis
process using the ICL dictionary in a cost-effective way.
Analysis and design using the QuickBuild WorkBench and the associated QuickBuild method involves
capturing details about:
• What the user does
• How this is done
• Where this fits into the organisation and how the organisation operates
• Where the computer is best able to support the user.
5
QuickBuild provides an environment in which Virtual Machine Environment (VME) applications can be
developed rapidly, yet in a controlled manner. There are various standards built in when adopting the
QuickBuild approach. The QuickBuild method works best when analysis and design is approached using
these standard techniques, which can be summarised as follows:
1 If a system is to be computerised it is necessary to know what that system is to do and how it fits in
with the way people work.
2 Once people get to rely on a computer system they must have access to information in order to do their
jobs. It is therefore necessary to know what information they use and how they use it.
While these two points are obvious, it is only recently that there have been standards for documenting what
people do and the information that they require to do what they do. Using these documentation standards
two pictures or representations can be drawn to map out the required information for the development
of any application.
In plain English the QuickBuild method can be likened to the analyst using a camera to take 'snapshots'
of people at work. As a result of the analysis of these photographs and the questions asked during these
sessions the analyst will draw up various diagrams. For example, suppose that one of the pictures is of
the above-mentioned lorry arriving at a gate with some goods. If the supplier's name is on the side of the
lorry the analyst may deduce that the supplier makes delivery direct. If, however, a distributor's name is
on the side of the lorry a different deduction will be made. Questioning the users will determine what
actually happens.
Similarly, snapshots of people at work will reveal:
• How different parts of the organisation relate to each other
• What functions are undertaken
• What information is required to perform these functions and so on.
The QuickBuild method therefore results in a diagrammatic representation of the system as agreed with
the user. Details of these diagrammatic representations are explained later. There are two basic diagrams:
1 A data flow diagram (see Figure 1).
2 An entity model (sometimes referred to as a data model) (see Figure 2).
The data flow diagrams are drawn as a result of an analysis of the functions undertaken in the organisation.
The entity models are drawn as a result of an analysis of the data used within the organisation. These
diagrams may be drawn at the terminal using the QuickBuild WorkBench and may then be used to generate
the system automatically, directly from the diagrams, using QuickBuild Pathway. The details of this process
are given later in this paper. A final diagram, a process flow, is often used as a cross check. This shows
in more detail how tasks are undertaken, including the precise sequence, conditions and so on. If the
diagrams are drawn on paper the details contained in them may be entered, on formatted screens, using
QuickBuild Pathway.
From specification to working system
Before looking at the QuickBuild WorkBench and how it works, it is appropriate to look at it in context.
How does it fit in with the analysis/design/implementation process?
Figure 3 shows what the process of analysis and design has been like in the past. It starts with the user,
as the system is developed to support the user in performing his job more effectively. Assume that the user
has an idea of the system that he wishes to implement and talks with an analyst. The analyst asks many
questions of the user, interprets the idea and sees how it fits in with the corporate objectives, the way the
business operates and the way the business will continue to operate. The analyst then goes through a process
of formal analysis and design, implementation, testing and acceptance. Formal analysis and design does
not mean months and years it just means a formal approach. An example of formal design from the past
is that one was quite strict about writing down a file layout, say, before programming.
If the timescale from the user forming an idea right through to accepting the system is long then there is
a potential problem. For example there is a chance that the user may have changed, that the business may
6
Beer
Figure 1: Λ data flow diagram
Figure 2: An entity model
1
Is it what
User
the user
has idea
wanted?
Analyst
Design Implement Test Accept
interprets
Figure 3: How it used to be
have changed and, therefore, that the requirements may have changed, so the system may not be what the
user wants. There is the added risk that the idea may not have been understood in the first place. In this
case the system as implemented is bound to be not what the user wanted.
As a company manufacturing computers and producing software, ICL has had various attempts
at improving the productivity of this cycle. There has been special emphasis on the tools used within
this process (see Figure 4). The process of analysis, design, code, test and acceptance into live
running is looked at. Assembler was an attempt to speed up the performance of the writing of the
machine code. Instead of writing bits and bytes, virtually on/off switches, one wrote in mnemonic
language. With COBOL, again, the same sort of thing made it possible to code a system in a higher-
level language.
Products like Application Master and QuickBuild Pathway are termed Fourth Generation languages, which
adopt a particular design methodology. They take us out of code and into design. In reality an attempt
is being made to automate the process earlier on in its life-cycle on the grounds that the quicker it is shown
to the end user the greater chance of providing what he wants.
Using the QuickBuild WorkBench we can analyse and design on a graphics terminal and then automate
everything after that; therefore, QuickBuild with the WorkBench and Pathway talking together allows us
to draw a diagram on the graphics head on the DRS.300 and then generate the system from the diagram.
The basic idea is as follows: the job of implementing systems is one undertaken by a DP professional. That
job requires certain skills. It may even require the use of purpose-built tools and it certainly requires a
supportive environment. ICL has therefore provided this.
What is meant by this? What is a workbench? Well, let us consider the dentist. We are probably all familiar
with the dentist's chair, or couch. We may try to relax in the comfort of the chair and dream of remote
tropical islands to take the dread of the dentist away. However, the couch is not there for the comfort of
the patient. It is there to enable the dentist to work efficiently in a very small area.
Moving across to the professional systems developer, the question that should be asked is 'Have we had
the same approach in developing systems in the past?' Is there a supportive environment? Can we work
efficiently with all the tools to hand?
Computer development has mostly been like the following second example. Suppose I want to build a
go-cart for my son without using a kit. I can go down to a scrapyard and get all the bits and pieces required
and then I can build it. I might find a motor from an old lawn-mower, perhaps a set of wheels from a
mini, and so on. Apart from the initial skills associated with design, I will need various skills to actually
construct the go-cart. For example, I may need the skills of:
• A welder
• A mechanic
• A wheel-balancer and so on.
There is a similarity to building systems in COBOL, with the separate need for job control language skills,
on-line transaction processing monitor skills and database design and implementation expertise.
8