Ada and the Ada Programming Support Environment (APSE) specifically address the phases of the system/software life cycle which follow after the user's problem was translated into system and software development specifications. The waterfall model of the life cycle identifies the analysis and requirements definition phases as preceeding program design and coding. Since Ada is a programming language and the APSE is a programming support environment, they are primarily targeted to support program (code) development, tecting, and maintenance. The use of Ada based or Ada related specification languages (SLs) and program design languages (PDLs) can extend the use of Ada back into the software design phases of the life cycle. Recall that the standardization of the APSE as a programming support environment is only now happening after many years of evolutionary experience with diverse sets of programming support tools. Restricting consideration to one, or even a few chosen specification and design tools, could be a real mistake for an organization or a major project such as the Space Station, which will need to deal with an increasingly complex level of system problems. To require that everything be Ada-like, be implemented in Ada, run directly under the APSE, and fit into a rigid waterfall model of the life cycle would turn a promising support environment into a straight jacket for progress

Hendricks, John W.

English

NASA Technical Reports Server

/ L - 7  3 Y 4 c  ' w .  N09= 1 6 2 9 9  
Analysis and Specification Tools in Rela t ion  to the APSE 
John W. Hendricks 
Sys tems Technology, Inc. 
Ada and  t h e  Ada Programming Support Environment (APSE) specifically address t h e  
phases of t h e  sys tem/sof tware  l ifecycle which follow a f t e r  the user's problem has 
been t rans la ted  in to  system and sof tware  development specifications. The 
"waterfall" model of the  l ifecycle identifies t he  analysis and requi rements  definition 
phases (now known as the  concept exploration and t h e  demonstration ti validation 
phases in the  l ifecycle as described in the  new DOD-STD-2167) a s  preceeding 
program design and coding. 
Since Ada IS a prograrnming language and the APSE is a prce;ramming support 
environment,  they a r e  primarily ta rge ted  to support program (code) development,  
B.4.2.1 
https://ntrs.nasa.gov/search.jsp?R=19890006928 2020-03-20T03:44:27+00:00Z
t es t ing ,  maintenance,  etc. T h e  use of Ada based or  Ada r e l a t e d  specif icat ion 
languages (SLs) and program design ianguages (PDLs) c a n  ex tend  t h e  use of Ada back 
i n t o  t h e  s o f t w a r e  design phases of t h e  l i fe  cyc le  (for example,  see Goldsack). 
However,  t h e r e  s e e m s  to b e  s o m e  agreement  t h a t  Ada is  no t  appropr ia te  as a language 
for deal ing with t h e  "problem space" and  t h e  ear l ies t  phases of t h e  l i fecycle  (Brodie, 
Mylopoulos, and Schmidt,  p.4 10; Booch,p. 359). 
T h e  Ada Programming Support  Environment (APSE), and indeed t h e  Ada language 
i tself ,  was  defined as a response to t h e  "software crisis" in DOD embedded systems. 
Booch (p.7-8) l i s t s  a number of symptoms of this situation, including: 
o Responsiveness. Computer-based sys tems of ten  do  not  m e e t  user 
needs. 
o Modifiability. Software maintenance is complex, costly,  and er ror  
prone. 
In par t icular ,  sof tware  maintenance is identified as being responsible for  between 
40% and 70% of the  to ta l  hardware and sof tware  expendi tures  f o r  these  systems. W e  
c a n  e x p e c t  t h a t  many of the  systems for  t h e  NASA space  s ta t ion  will s h a r e  impor tan t  
charac te r i s t ics  with t h e  DOD embedded sys tems (e+, complexity,  long-lifetime, 
changing requirements ,  real-t ime inter-iaces), and they should be subject  to many of 
these  s a m e  problems. 
The  world's best  programming ef i o r t  cap not produce a system which is  responsive to 
t h e  user's needs i f  the  requirements  upcn which i t  depends d o  not  descr ibe a n  
appropr ia te  solution t o  t h e  user's problem or i f  the  requirements  a r e  in a form which 
0.4.2.2 
we have great d i f f icu l ty  t ranslat ing i n t o  an  implementable  design. Also, if this 
problem exists with t h e  original requirements  for a system, it c a n  be r e p e a t e d  e v e r y  
t ime there i s  a change  in t h e  problem. W e  do not  have d a t a  which c h a r a c t e r i z e  t h e  
distribution of software maintenance costs be tween "bug fixes" and  changes in 
requirements, but  it would not  be surprising if a la rge  par t  of t h e  "maintenance" costs 
are caused by evolution of t h e  requirements,  especially for sys tems which a r e  in 
serv ice  for a number of years. Therefore,  both the  responsiveness problems and a 
large part of t h e  maintainabili ty problems which charac te r ize  the  sof tware  crisis may 
be beyond t h e  reach  of Ada and t h e  APSE, unless faci l i t ies  to deal with t h e  processes 
of concept  exploration and demonstrat ion & validation can  smoothly be linked in to  the  
APSE. 
There  are a number of developments which demonst ra te  t h e  feasibil i ty and 
desirabil i ty of formalizing specifications or a rch i tec ture  designs at higher levels of 
abstract ion than t h a t  provided by a programming language (e.g., Ralzer;  Zave). These 
e f f o r t s  share  an object ive of reaching out  toward t h e  "problem space" w i t h  a 
representat ion which is much easier  to use than a programming language for 
describing the requirements,  but  is still capable  of being t ranslated or t ransformed 
in to  compilable code with l imited manual intervention (au tomat ic  prograrnming). 
They also share  a commitment  to extensive use of computer  based tools to  suppart  t h e  
processes  of analysis, specification and design. To the  degree  t h a t  these approaches 
succeed,  they can address t h e  problems of responsiveness t o  init ial  user needs and 
main tenance  of responsiveness as these needs change  over  the  l i fe t ime of t h e  sys tem.  
It is unlikely t h a t  any of these e f f o r t s  will e l imina te  t h e  need for substant ia l  a m o u n t s  
of human programming in the  development of the  la rge  and complex sys tems for 
8.4.2.3 
QRlGlPIAL PAGE tS 
OF M W L l N  
which Ada  and t h e  APSE are designed. If these  new techniques a r e  to be 
explo i ted  for major  pro jec ts  such as t h e  N/,SA space stat ion,  they  must  be capable  of 
being used in conjunction with program design and  development  under t h e  APSE. 
O n e  of t h e  m o s t  promising of these new systems is Process  Archi tec ture  Design 
Technology (PADtech). Sys tems Technology is working with t h e  developers  of this  
sys tem,  Associative Design Technology, Ltd  (USA), to introduce and support  
this  new technology for aerospace and mili tary applications. An overview of PADtech  
and s o m e  of t h e  issues raised by its use with t h e  APSE should suggest  both t h e  promise 
of t h e s e  new sys tems and some of t h e  issues to be considered in  "integrating" these  
new tools i n t o  major projects  which will be using t h e  APSE. 
PADtech  includes both a methodology and a set of computer  based tools t o  support  t h e  
use of t h e  methodology in c rea t ing  an  a rch i tec ture  design for  a complex system. The 
methodology provides a representat ion to formally describe: 
o t h e  s t ruc ture  of processes which we expec t  t h e  sys tem to 
implement ,  t h e  events  which  will cause each process to be executed ,  
and t h e  e v e n t s  which  each process c a n  cause  to occur;  and 
o t h e  conceptual  s t ruc ture  of the  en t i t i es  involved in t h e  processes in 
t e r m s  of the  role relation hips between the concepts ,  object  types  
and objects.  
This representat ion (Process  Archi tecture  Design specification Language or  PADL) 
descr ibes  processes which may be implemented by hardware,  or by persons following 
procedures ,  as well 3s by software.  However, PADL has a precise semant ics  which 
enables  i t  to be t ransformed in to  executab le  forms,  ;rid this  inevitabil i ty makes  i t s  
R.4.2.4 
application a more demanding process. By way of contrast ,  Coldsack (p.11) noted t h a t  
"...the ease of use of PSL, SAD" and many others,  is partially due to the  absence of a 
precise ... seman tics." 
The computer  based tools for t he  application of PADtech include the  following: 
A design workbench which provides a high performance, c o b ,  icon 
driven, interact ive graphics interface fo r  t h e  cre.:tion and 
manipulation of the  graphical form of the  Proczs3 Archi tecture  
Design specification Language. The design workbench supports t he  
system archi tec t  in the evolutionary process of analysis, 
specification and design. I t  also provides support for  interactions 
with problem a rea  experts  and with program designers 2nd 
programmers. 
Modules which translate between the graphical form and t h e  textual  
form of the  Process Architecture Design specification LanguagL; 
A da ta  manager which provides bookkeeping support for  the 
evolving process archi tecture  design; 
A facility for building up a customized set of icons, process models, 
etc. which a r e  appropriate for  specific problem areas.  
An interpreter  for simulated execution of the  process archi tecture  
for an early prototyping, i terat ive design cycle. 
A "monitor" which collects the results of the  interprc ; i  ?xecuti\, (. 
A "debug" environment for controlling and examining t h e  results of 
interpretive execution. 
Code generation faci l i t ies  for transf orining Process Architecture 
Design specification Language descriptions for process and 
conceptual s t ructures  into the implementation languages, Ada and 
SQL. 
B.4.2.5 
P A D t e c h  is designed to be applicable to t h e  analysis, specif icat ion and design process 
at several d i f fe ren t  levels. First, i t  can be used at t h e  s t r a t e g i c  planning level. For  
example,  one can build a process architecture to represent  an e n t i r e  organizat ion or a 
major project ,  and use this  "enterprise modeP to ident i fy  and specify a u t o m a t e d  
information and  communication sys tems to support  operat ion of t h e  e n t i r e  enterpr ise .  
Second, PADtech  c a n  be used at t h e  system or integrat ion a r c h i t e c t u r e  level f o r  a 
s p e c i f i c  system. I t  can  be used to design the  a r c h i t e c t u r e  which def ines  t h e  overall  
structure f o r  a comple te  system, or to design and implement  a da tabase  and 
communicat ion "substrate" to in tegra te  many separa te ly  developed modules,  
including man- and hardware-in-the-loop elements .  Third, PADtech  c a n  b e  used t o  
specify,  design and implement  (by code generation) sys tems which c a n  readily be 
c h a r a c t e r i z e d  by "object processing" processes, i.e., processes which c r e a t e  and  
change  t h e  state of both abs t rac t  and "real" objects.  
PADtech  will be most  beneficial  when applied to sys tems with some of t h e  following 
character is t ics :  
o Requirements  which a r e  complex, not  completely understood, and 
a r e  expec ted  t o  evolve over the  life of t h e  system, 
o Requirements  for very high speed execution involving parallel  
and/or distributed execut ion,  
o Requirements  for real- t ime rcsponsiveness, 
0 A requirement  for high speed management  of complex. in te rac t ive  
d a t a  bases and cornmunicatior? s t ruc tures ,  
0 Integration of a large number of processes while maintaining 
protection against  ca tas t rophic  failures. 
R.4.2.6 
W e  expect t h a t  there will b e  a number of space station sys tems with these 
character is t ics ,  and t h a t  PADtech  and o t h e r  innovative tools for analysis, 
specif icat ion and design will b e  required to make these sys tems responsive t o  the 
requirements  and  maintainable  over  a long l ifetime. 
What a r e  s o m e  of t h e  issues raised by the  use of these tools with Ada and the APSE? 
Firs t ,  tools which a r e  geared to crea t ing  a problein space  or iented,  executab le  
specif icat ion or design specif icat ion tend to c u t  across  the  phases of the  lifecycle as 
defined in t h e  waterfal l  model. These tools gain much of their  uti l i ty f rom an  
i t e r a t i v e  cyc le  of analysis, execut ion and evaluat ion of the  specif icat ion as a 
"prototype," re-analysis, e tc .  They emphasize d i rec t  involvement of t h e  users or 
problem area e x p e r t s  in evaluat ing t h e  implications of a design specif icat ion as they 
a r e  revealed by repea ted  prototyping. The analysis and prototyping processes a r c  
supported by an  in te rac t ive  environment  which is heavily dependent  on "prototype 
execution" and graphics for  presentat ion and manipulation. Also, these new 
techniques push formalization back toward the problem specif icat ion and use 
(pdrtially) autoindted t ransformation to genera te  code  modules. This allows 
maintenance which is occasioned by changes in t h e  requirements ,  to be perlorrned on 
t h e  speci[ication/design rather  than on t h e  code. Then, t h e  revised specification is 
transfortned into updated code modules. (Jse of these new techniqttes will be mdde 
inore difficult  i f  a rigid segmentat ion in to  the  phases of a waterfal l  lifecycle model I S  
imposed by procurement  processes or by implementat ions of the  APSE. 
Second, t h e r e  a r e  several  reasons why specification and design tools should be linked 
i n t o  the  APSE. Most important ly ,  if design specif icat ions such as those in PADL a r e  
t o  be used f o r  main tenance  and a r e  to become a par t  of t h e  permanent  documentat ion 
0.4.2.7 
of a systcrn,  i t  is impor tan t  to have  control  over  their  versions as o n e  does f o r  c o d e  
modules. Also, in  sp i te  of cveryone's tendency to claim t h a t  his sys tem is c o m p l e t e  
a n d  u n h e r s d ,  none  we. AJl of t h e  analysis, specif icat ion and design tools  would 
benefi t  f rom being ab le  to i n t e r f a c e  with o ther  sys tems which could complement  the i r  
own capabi l i t ies  (for example,  see Ripken). An "open" APSE could coord ina te  
be tween severa1"outside" tools, as well as between these  tools and code  development  
under t h e  APSE. 
Third, t h e  amount  of e f f o r t  being put into the  development of Ada and t h e  APSE 
create5 a certain mmentum towards making them all inclusive. If Ada is the 
programming language, why not use i t  as the  basis for  a design language, a 
specif icat ion language, a conceptual  design language, etc., and mandate  their  use? I f  
t h e  APSE is to control  the programming process, why not  mandate  t h a t  only tools 
which a r e  fully integrated in to  the  APSE c a n  be used f r o m  concept  exploration 
onwards? The potential  benefi ts  of such a coherent ,  s tar t - to-f inish development  
environment  need to be balanced against  t he  potent ia l  costs of using much less than 
opt imal  tools in the  pre-programming phases of t h e  l ifecycle.  
A detailed examination of these issues would be a major project  and is n o t  
contempla ted  here .  However ,  we  will suggest t h a t  in applying Ada, t h e  APSE and 
s tandards  s u c h  as 2167, we should be careful  not to let their  application expand to a 
point where they stifle innovation. The continuing revolution in microelectronics  is 
providing an  opportunity to c r e a t e  sys tems to solve increasingly complex problems; 
new techniques for  specification and design will also be needed to exploit  this  
opportunity.  which will b e  needed to build t h e  
increasingly complex sys tems we require,  will not b e  developed exclusively for  use by 
Many of these new techniques,  
8.4.2.8 
one industry or one language. Retaining the option to se lec t  different methodologies 
for problems which have differing characteristics may be the only e f fec t ive  approach 
at this  time. 
c 
Recall that the standardization of the APSE as a programming support environment is 
only now happening af te r  many years of evolutionary experience with diverse se t s  of 
programming support tools. Restricting consideration to one, or  even a few chosen 
specification and design tools, could be a real mistake for  an organization or a major 
project such as the  space station, which will need to deal with an increasingly complex 
level of system problems. To require tha t  everything be Ada-like, be implemented in 
Ada, run directly under the APSE, and f i t  into a rigid waterfall model of the  lifecycle 
would turn a promising support environment into a straight jacket for  progress. 
8.4.2.9 
R e f e r e n c e s  
Balzer,  R., "A 15 Y e a r  Perspect ive on Automat ic  Programming," IEEE Trans. 
Software Eng., vol. SE-I I ,  pp. 1257-1268, November 1985. 
Booth, C., Sof tware  EnRineering with Ada, Menlo Park,  CA: Benjamin/Cummings,  
1983. 
Brodie, M., J. Mylopoulos and J. Schmidt  (eds.), O n  Conceptual  Modeling; 
Perspec t ives  f r o m  Artificial  Intelligence, Databases  and Programming Languages,  
New York: Springer-Verlag, 1984. 
Goldsack, S. (ed.), Ada for  Specification: Possibilities and Limitations,  Cambridge,  
England: Cambr idge  University Press, 1985. 
Pepper ,  P. (ed.), Program Transf orrnation and Programming Environments,  Berlin: 
Springer-Verlag, 1984. 
Zave, P., "The Operat ional  Versus t h e  Conventional Approach to Sof tware  
Development," Commun. ACM, vol. 27, pp.104-118, Feb. 1984. 
B.4.2.10 


Analysis and specification tools in relation to the APSE

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server