=Paper=
{{Paper
|id=None
|storemode=property
|title=Application Development Trends and Directions
|pdfUrl=https://ceur-ws.org/Vol-961/paper32.pdf
|volume=Vol-961
|dblpUrl=https://dblp.org/rec/conf/caise/Welter89
}}
==Application Development Trends and Directions==
https://ceur-ws.org/Vol-961/paper32.pdf
1.0 CAS E 8 9
1.1 Application Del1e[opmenl Trends and Directions
Presentation by Miles Welter, Illy! Corporation, Santa Teresa CA, USA.
Let's talk a little bit about software engineering. Software engineering is an attempt to take the
same concepts that arc used for building a bridge, constructing a building, or designing a computer
hardware system, and apply them to the proeess of developing, maintaining and managing the
software that runs on that computer system. These things have been done for a long time and
called programming. The advent of software engineering is an attempt to formalize the disciplines
that so many people in the programming business just did as an aJ1. They include methodologies
and tools. I recall when I started in the business some 33 years ago, my m'Ulager called me in 'Uld
said, Irs a shame that you've started into the business at this poi.nt in time because we have just
come up with a new method that is destined to allow aU programs to he produced 011 time, within
( budget, and meet all other requirements of the end users. That method was CPM, Critical Path
Method. My manager went on further tu say that we have a new tool that allows us to fully utilize
this new methodology. That tool is called PERT.
Since that begllUling a long time ago, many other methodologies and many tools have followed.
It's to the point now where a large number of tools is available for the user to select. These tools
each promise a significant increase in application development productivity and individua.lly these
tools provide that very increase in productivity. However, as more and more of these tools are ad·
ded, it becomes obvious they were not de'signed with the other tools in mind. Thus IUM has
embraced a new idea to produce a framework for integrating all these tools, and it's this framework
and the supporting platfom1 implementing this framework that I want to discuss with you today .
.' :
The notion of this framework is to allow a natural extension to the highly successful SAA - Syst~ms
Application Architecture· to assist the application dcvclopcr. Professional Data Processors have
been trying to automate the various individual departments fqr a long time. Now these same prin·
ciplcs will help the progranuner who has been providing that automation. The basic change to
accomplish this task is to take the traditional life cycle curve which starts with an cnd·uscr coming
in with a problem. That problem is interprcted by the professional data processors and they in turn
assemble a team to try to solve that cml·uscr's problcm. And there's a very wcll known set of
procedures that go on and on, each inuividual instaUation has their own, but they are all similar in
that they start out with some kind of requiremcnts gathering, analysis and design at a high level,
analysis and design, developing thc aelual program, testing that program and finally putting that
program into production. This cycle is commonly called the waterfall cycle, aJ1d I'll talk about that
cycle a lillie later on. That cycle takes a long time; lhat cycle does not communicate properly
betweei1the professional data processor and the end-user. In the end, quite frequently, the product
that is delivered, although a product that perfon11S very well according to the specifications that the
professional data processors set out to meet, docs not satisfy the end·user and that's for a variety
of reasons. frequently the major one of those reasons is that it takes a long ti.me. This long time
involves a large number of resources expended and as Software Engineering techniques are imple-
mented, one of the key changes required is to reduce the number of resources expended and that
can be done best by shortening the development life cycle. '
The secondary thing that must be done is get the application designed properly thc first time so that
it actually meets the specific requirements of the end user. It is a well-known fact that changes in
the application become much more costly further along into the application devclopment life cyde.
Let's esamine that life cycle in .. little more detail. It starts out with a.person in the business re-
cognizing that data processing can assist in reducing the time it takes to' do a job or actually in all-
owing a new job to be done...ol1e that was never done before. That person is typically ca.lleo an
end-user. The end-user meets with the professional data processor 'md they discuss what thcy
would like to produce. It \\"Quld .be Iliee if at this point in time a business model could be produced,
an enterprise·wide business model, that would provide a pictorial view of the business. A view that
businessmen managing the business and lhe professional data processors attempting to assist by
letting the power of the computer help in those diOlcult areas could visually see how the business
was operating. This is an area that is becoming increasing,ly more popular, but the industry is still
not able to handle. Thus, a business model is not created, but instead some sort of .specifieation.
"'ext what happens is a group of professional data processors, highly skilled·)echnieians arc gathered
togelher. They might have functions of database design, screen design, report design, specific
functional 4esign. These people read the specification that was decided ulJon by the end·user aJ1d
the analyst. They in tum produce their own interpretation of that, each aligned along the area of
CASl89
their speciality. Now instead of one spccification, thrce or four or fivc diJferent spccifications cxist,
all attcmpting to get back at thc root of what the end-user wanted. .
These arc given to a team of programmers, and the programmers then produce a program which
in turn is tested, integrated with other systems in the organizalion, and promoted to production.
That is the situation today. I low can Software Engineering teclmiques assist in this situation?
IBM has been working on a notion of a central repository. TillS central repository would contain
control infonnation for all items that were required during the application devclopment life cycle.
If such a central repository were available, let's review how the scenario jusl mentioned would ap-
pear. The same end-user would come together with the same professional dala processor and they
would be discussing now how to solve tillS end-user's problem. Only this time a set of software
engineering tools could be delivered to the end-user by a progranunable workstation and the pro-
fessional data processor along with the end-user can determine exactly what this business model
should be. This is going to take a sophisticated typc of tool and one that is still in the prototyping
stages today, but this is the direction that the entire data processing industry wants to move.
Ifthat business model has sufficient infonnation and semantic vitality, it's possible at this very early (
stage that some sort of prototyping could take place so that the businessman could visually see what
his thoughts transfonned into a business model actually meant to the running of the business. It
would be possible to iterate through this prototype in such a fashion that the businessman could
be quite sure that he had totally conununicated ever)'th.ing he wanted to the professional data pro-
cessor.
(
Next, as in the previous example, the tearn of professionals would be assembled. Tlus time however
the)' would be provided with a series of analysis tools. These tools, agairl delivered on a pro-
granunable workstation, would allow the reading from the central repository a maclune stored
version of the business model. These tools would transform that business model into the specialties
that each profcssional brought to thc table. For examplc the database dcsign, the screen design,
specific progranurling specifications, etc.
The next phase could be to allow a progranuner, again operating on a programmable workstation,
to read these new specifications stored under the control of the central repository and produce the
application, going through testing and promotion into production in a very sinlilar way as stated
before.
The major change between thesc two scenarios is the usc of a centralized repositor)' for control of
all objects. This in tum facilitates the recording in a machine readable fonnat of the business model
and the problem that the end-user is going to solve, and then a series of transfonnations from that
repository controlled infonnation to ultimately produce the program willch executes what the
end-user had in mind. As more and more tools arc made available to professional data processors
or even to the end-users, the process will gradually mO\'e to the time when that life eyele, that wa-
terfalllife cycle that I deseribcd in the first part of the paper, could actually be modified. Up to this
point in tinle, the data processing industry has concentrated on providing tools that allow a faster
transition of cach one of these steps in the application development life cycle. For example, tools
have bcen provided to facilitate moving from the bcgimung of the progranuning stage, the actual
production of the progranuning code to the end of that progranurling stage. These tools arc quite
familiar to people in data processing. They started out with third generation languages; we're
moving now into application generators or fourth generation languages; and on the horizon is the
expert systems arena or futh generation languages.
It's all well and good to traverse these life e)'ele steps faster, and we the industry have gained signi-
ficant activit)' by utilizing these tools. However, to get a quantum leap in application development
productivity it becomes incumbent upon the developers of such a system to look at actually elimi-
nating steps in the application development life eyele, reducing the rigor, reducing the amount of
documentation required, reducing the number of chcckpoints that are necessary to go from an idea
to a finished program. I hinted at the beginrllng of this paper as to what fonn that reduction 1I'0uid
take. It is in the fonn of a prototyping capability. TillS protot)'ping capability must be sufficiently
robust to let the end-user, along with the professional data processor, see exactly what will happen
based on changes to this enterprise business model.
Once the prototype is agreed upon, in some number of cases, in the early stages of this new type
of application business model driven development there will be few times when this will happen,
but in some cases the application can go directly into production. As the industry develops more
sophisticated tools and the end-users and the professional data processors become more convinced
that tIllS is the way to do it, an increasingly larger number of applications should be able to go from
prototype into production.
CASI::89 2
Let's talk a little bit now about the platform and vision that must be necessary for a serieS' of tools
to work together in such harmony as I've depicted in the early part· of, tlus paper. Three things
must be present: There must be a repository, a very full funciion repository that will facilitate the
control and sharing of information in all phases of the application development }jfe cycle.. · Thcre
must be a complete set of uscr tools. These tools over time need to cover the entire .applieation
development }jfe cycle, and they need to derive the infoOllation that they require from the reposi-
tory. And on top of aU tillS, there must be an efficient, casy to usc, and consistent interface into
tlus environment. Those three tllings I want to speak about in a·little more detail.
First the interface that the user would have to this. Let's call this the user ·services interface. User
services is the glimpse that the user has of this environment for increased application development
productivity. Tlus glimpse he has should be exactly the same no matter what tool he's using, what
function he wants to invoke and no matter what phase of the application development life eycle is
currently in operation. Thus, the user services can be broken also into two pieces. The dialog in-
terface (that is the specific interface that the user will see) and the actual tool invocation, because
all tools should be invoked in exactly the same way. IBM has put into the market two products
that can assist in tlus area. The fust one of these is a product that runs on the main frame and is
a system controlled way of driving a methodology and invoking tools. That tool is called ADPS
(Application Development Process System). It's a very rigorous product. It requires a fair 'unount
of effort and time to fully utilize. But once installed, will provide a sign.ificant application deve-
lopment boost.
The second product is the Professional Work Manager product. This is it product that operates
on a progranunablc workstation and allows the user to determine what sequence is required to
execute the application devclopment life c);c1e. The Professional Work Manager, once tlus se-
quence has been detconincd, executes tlus sequence over and over for the program.l1lcr.
Next, the repository, or the base on wluch all of this is boilt: The repository to assist in application
development must be able to handle the entity attribute relationslup way of storing and controlling
those tllings that are necessary for the application development life cycle. Tlus ER, as it's frequently
called, way of storing data is the one that is conung forward as the standards controlling application
development gradually matures.
Since object management is also important, a repository should have the ability to take a step up
and handle a larger aggregate of entities frequently c,dled objects.
To insulate the builders of lools from changes arId also to provide the ultimate in flexibility, mul-
tiple views of this information is necessary. The conceptual view, or the view of the entire business
enterprise, is the foundation of the repository based application devclopment systcm. Each tool
that uses the repository or that references this conceptual view looks at this view in a slightly dif-
ferent way. Therefore each tool needs to have its own logical view of the overall business wide
conceptual view. These views ultimately result in physical data being storcd ...physical entities,
physical relationships and attributes. This data is stored in yet a third vicw...the storage view. Given
these three views and given that the repository is able to handle entity atlJibute relationship and
object management data, the start of a system of sharing of information between all tools is pos-
sible. This brings us to looking at the third piece of tlus enviJOlUnent....lhat of the tools themselves.
A wide range of tools is necessary to completely fulfill this dream expressed in the earlier part of the
paper to allow a very easy migration from a change in the business model to a brand new program.
It will probably be a good long time before a complete sci of tools is available. In the meantime,
existing tools from a variety of vendors, both In\tt and independcnt software vendors can be mo-
dified to utilize a repository based development environment.
This modification comes in two directions. First, conformance to a standard way of accessing the
tools. Accessiog means the way that the user looks at thc tools and the way the tools arc invoked.
Looking 10 SAA for guidance, the Consistent User Access interface or CUA interface is an excellent
interface to take as a pattern. It spells out exactly how items should be represented on the screen
and could be extended to indicate how tools should actually be invoked. At the other end of the
spectmffi is the Common Conununications Support. Tlus facilitates the commUlucation between
workstations and the SAA host platforms. These host platforms are MVS, VM, OS/400 and OS/2.
'fhc vicw into the entire S/\I\ cllvironment is through a series of Common Programming Interfa-
ces. Those Common Programming Interfaces (CPl's) ensure that a program wlittcn in any system
as long as it abides by the SAA common programming interfaces or cprs will run uj any other
envu·Olilllent. There arc II eun·ently declared intelfaces, arld those ullerfaces range from Fortran
to SQL to CSP to RPG. A natural extension of those interfaces would be to provide an additional
common programming interface or CI'I to support repository services.
CASEH9 3
Given these two kinds of interfaees, CUA and a repository services interface, the tools currently in
the marketplace can gradually migrate into this cnvironment by adopting all of the requirements
of these interfaces. It is anticipated that this adoption will take some time and that a starter set of
tools needs to be provided by IBM. These tools will most likely consist of IBM products and some
independent software products and will gradually be expanded to cover the entire range of thc
application development life cycle.
Once this has happened, the picture you can visualize for application development would be a se-
parate application development system with a cooperative model, all interfaces bcing done on a
programmable workstation, the PS/2 with OS/2 Extended Edition, and interfacing to any of the
SAA hosts. This enviromllent would in tum produce target applications that could run on any of
the SAA environments.
In summary, I am looking to a new way of devcloping programs. A way that is model drivcn. A
way that will involve the end-user early in the life cycle and through prototyping ensuring he is
gelling what he wants. A repository based developmeot enviromnent will facilitate the shariog of
information between tools, and as new advances comc, these new tools can be inserted into the
environment in the same way the existing tools are.
If all of these things come to pass, then the first steps toward changing the watcrfall cyele and eli-
minating actual steps can take place. The idea of a business enterprise model can be established.
The SAA application environment can be extcnded so that a user is sure that if he sticks to the
interfaces that are published, he will be able to takc advaotage of all changes in technology that are
coming in the foreseeable future. It may possibly get to the stage where programmers in the tra-
ditional sense as seen today, that is handcrafting a specific program to meet a specific set of requi-
rements, will become a thing of the past. And, the programming talent that exists today will be
marshalled to produce beller and beller tools, all integrated on a common repository, and all allo-
wing that huge backlog of systems to be implemented in a very quick and efficient way.
CAS[89 4