nasa-cr-188077 · nasa-cr-188077 19910010409 a reproduced copy • ... software engineering...
Post on 18-Oct-2018
226 Views
Preview:
TRANSCRIPT
NASA-CR-188077 19910010409
A Reproduced Copy
•
Reproduced for NASA
by the
NASA Scientific and Technical Information Facility
CnP'l1 rt~BRAR'l 1'\..1 a -
J nJ9 \ 9 \99\
L -.. ~trc!~ ~1 U··r.~ r.~:.. .. · I -. -'- C"\~~~1 t!~S!\ ..... ~, r'\!\
~·--,p~O:l \nnG i. ; L
\.~..... . 111111111111111111111111111111111111111111111
NF01201
J
https://ntrs.nasa.gov/search.jsp?R=19910010409 2018-10-18T06:43:12+00:00Z
1.-,- _ ...
\ ",
-
/V'-<-/ /V-
, 3 117601357 0081
RICIS'88 SYMPOSIUM CONFERENCE PRESENTATION
APPENDIX
(':o\-";'-.,;'-!..,",,71t "(.r~ L"'i° "Y"'~'l.illJ" r .., _,- ;. _ - , ~ ..... ~. .., r. r _: • T .\ T' ! .... "'. A" ..... ~ ..... ~ 1 Y { .... ou ~ to.l,Jn
.... r i v. ) 1 -; > "
~,Q~-1'112.;.
-- r -1_1/-
:."1-t"1 !J u.,c, .J S
oJ ~...: ,,:, .. 'j
.-L E L L t
L
L L I .. \ ..
Druffel. Lany
Yudkin. Howard
Affiliatjgn
RICIS '88
COlfll'ERENCZ PRESENTATION APPENDIX
Prntntatjgn nit Software Engineering Institute Software Development Environments:
Status and Trends
Software Productivity Consortium The Nut Generation
Jensen. E. Douglas Concurrent Comput. Corp. A New Generation of .-... Trne DOS Ted1no1c1gY for Misaicn-Orienced System Integration and Operation
S ... Michael
Shetton. Chuck
Krasner. Herb
Hall. Dana
I MacOonaJd. Robert
PaMr. Tim
NASAlJSC
Lockheed
Lockheed
NASA HO/SSPO
NASAIJSC
SAle Comsystems
Misaion Operations Director.e: Facility and S~ Systems Division -
Tool and Data Interoperability in tl' .. SSE System
Empirical Studies of Software Design: Implications for SSe.
The Role of Software Engineering in the 5pKe StzO'" Program
Software Engineering as an Engineering Discipline
Leaona lnmed fron an Ada Conversion Project
The Research Institute for ComputIng and Infonnation Systems' 2nd anruaI RICIS S~ium was ""' on November 9-10, 1988 at the South Shore Harbor Resort Hotel in Houston. While the maIO"" ~ presentations were inckIded in the RICIS '88 Slt!7IlQ$jum pmqedings there were some presetlUlC'" that were not induded. Theretore. we have c:oGeded the presentation PIPItS and slides that were nor #'
the original proc:eecinQs and Incb:fed them r.1his volume for your reference. If you have any questions Of raquire r. jtionaI copies. please COfUd:
SoftwIl.-EnQinMring Professional EdnCllionc.urlJIi.Oeat Lake, Box 270
2700 Bay Area BM1 Houan. Texas. 77058-1088
(713) 488-9433.
__ ------------...;..----------- ... --.--..••• _ .... __ •• ~~.L ... !o.JIJ.L .. !.t .... '."'::t.l ..... :: -:- ...... Pt' ,4, " ff it; .. -, , '"'. Carnegie Mellon Univclslly
Software Engineering Institute
Eh"iro-nment Concerns , ~
I • User - conceptual integrity - tool integration - 'new tool additions - life-cycle coverage ~ method supported - language(s) supported - hardware pase '.
• Environment architect - software architecture - representation of objects - •••
• Tool builder • interfaces - •••
06237DOj8
..
--~~------~~~--1
----. ...
~
==z- Carnegio Mellon Univelslly
Software Engineering Institute
Environment Roulette
• Backing into enviftlnmenjs - incrementally
/ • False ec'on~my • focus on hardware
• Lure of the PC • scaling up'
• Heterogeneity
..... tJ. .. 'I~ ,.I
'~rl
..
· ............ -..... --.... ~-"'.- .. -.. ~ ..... -•.. -- .. ~ ...... -... . .. ~, "-"1. "4t:.' 1 t, f,4", I' 4.'.{,' t.· ... Ie
.,
:::::.-;;. Caln.gl. M.Uon UnlV./lUy ,
~ Software Engineering Institute
I
Tool Integration and Tailoring .
• Because of heterogeneity and risk factor of monolithic, single vendor environment:
• assembly of components,. e.g., design tool, code generator, document preparation, mailer, editor
• tailorability of tools and their interaction
-I
f :, 4 -' 'T·----~ .,.,.. • .------.. --.-. .• --.-,...---.~'-.:-r"":- ,- -\. ""~.' i ·,1"1 it "'... • ., C:", ..... _ _. poo-.
'- . .'.
-
~ CarntQl. Millon UnIv",lly • ~ Software Engineering Institute
/
Software Heterogeneity
• Host target software qevelopment and maintenance, e.g., Ada emb-ecce-d- systems ".
~--- .
• Distribution of life-cycle support across machines requiring Integration, e.g., NASA Space Station
• Different services on different hardware
• Different models, e.g., access control, project management, configuration management
,.. ~
F······· .. _", .... ~ ~'-'P ....... -~ ....... , ... "" .......... ,..,. .. ~ ,"' ,.""'.
~ Cltn.gl. M.Uon Unlv",IIY i ~ Software Engineering Institute
Implications • Arch Itectu re
• language-centered - process-driven
• Tallorability
I • Software maintenance
"
\r-..:. '.t:'"l"""!'f";""'; ",' ,n, lAC " N. i\\ ~:~. ~
.' ':'
•
~ ~lIn.gl. M.llon Unj~'''lIy , ~ Software Engineering Instllut~
Problems
• Remote resource management (not centralized) :"
• Integration of hardwar6 for different services
• Data interoperabllity~ . " • life cycle or life-cycle phase • between tools and between machines
I
• Hardware changes over life cycle
• Need transparent view via uniform interface
:'
.. '
" . " ..... 9' Ii
fCC( ,CUi Ri' 444;0 1"#« c.
•
---~ Garnegie Mellon University
~ Software Engineering Institute
, Structure-Oriented
• Common rep.resentation " . "
• Editor-contrplled
• Multiple views -- .... _-
• Semantic-directed browsing
:-
Wi , , •
I • Examples .. Gandalf; Rational, Cornell Synthesizer
"',.."'''' .. ",....''''
F_ -~
~,----- ,. , • , .... 0, t ... >"1'" ." "to- if. ' .. ". +i!!' ___ t d 94F." -1 .Sllll .. ·a ..... ~~ ...... ~ .. ~".r~., .......... ~ .. ~ .... ~~~
Carnegie Mellon UniverSlly
Software Engineering Inslilu\e
Method/Process~Based
Method-based 0 "
• Support specific method .. • Often include graphical representation • Some formal foundation • Examples - JSD, SADT, SA/SO, Statemate, Refine
\. J
Process-based' • Support a specific-process model . • Enforce a discipline
I. Language independent -. • Examples - Refine, ISTAR
"
06237DOi7
--,- - .... ---," ;; ." "SO;,, .$44' 1#iO " ,;' •. S. _.'I! . '!i._. .• ,---
" --- Carnegie Mellon University
Software Engineering Institute I ,
Toolkit
• Operating system extens·ions
• Languageindependence :-
• Standard interface
• Gener~lity - tools applied to files
• Team cooperatlorLrequires discipline
• Examp~es· UNIX PWB, CAIS, peTE I
Oti.'J100,4
::, u<. '("",,>,,'4 ~,pe que,,, .S W!'" if" • - ....... .......- . ..
~
~ Carnegie Mellon Unillelsiry
~ Software Engineering Institute
-..
, Language-Centered
• Support for semantics of. specific language ...
• Interactive
• Incremelital-
• Enco~rages exploratory development style
• Examples ·'Interlisp, Smalltalk, Cedar, Rational
I
rw:- --"'--;"-:-;;;"-~:': ;';"'-~''';:-'-.-- "-~ .. ~~' ~.-: .. _'" , .::---- ... ~-~~---. r-- --. r--;- -
-~ Carnegie Mellon University
~ Software Engineering Institute
Management Support
• Management of resource,s I
• Management of product ...
• Management of process
• Management of environment
---~---
I
O"88(i82 •
~~~--~-- .. . .. _'"'"
Car~egjo Mellon University
Software Engineering Institute
'Environment Trends
• Toolkit "
• Language-centered--- ':"
"
• Structure-oriented-I
• Method/process-based
./0
~ • c... J .', . • ,11,) t .~.-: ..
.. r--
Carnegie Mellon University Software Engineering Institute
Motivation for Software Oevelopment Environments
• Programming support tools ~ .
• Management of complexity
• Support Jor the process '.
/ - . 1
,':tJ .. J :(J ... I,.! I
--- . ... -
Integration • Conceptual - across life cycle phases
':'
• Tool- permit tools to pass data
• User interface - user interacts in consistent manner • -+-. '-"--- -._---
• Language centered - assumes activities in specific I language
• Incremental - tools are finer grained - spreadsheet
• View - allow mUltiple vl~ws
* Not necessarily mutually exclusive
~ .. ~ 1
r.
_" ..... _. __ .. __ , .... ,.."'''~'''''''~I '.-.. 1!.::W:U::: •• V •.. ! .!fN.i'" 14. "" .v, •..• t '" '* '*.. -po .,
•
--~ Cllnlgll Millon Univ.nily .
Software Engineering Insillute
Strengths .
• Usual benefits of automation: consistency, repeatability (plus some inflexibility)
• Working representations are captured, online, and deliverable .
• Increasing ability·to·'not only analyze, but also query and browse "
/ • Less time spent during inspections and walkthroughs on syntax errors, and more time spent on errors of substancr
i
f
I I
i·
I !
I
".
'-
:;:we • • --.... ~ W' .-... ; ..... - ... ----.-.-.-.--...... ~-, ..• \ '''., .1' f't ill!f.Jt£l! -, ·~c
~ C~'n.gl' M.llon Univ."iIY
. ~ Software Engineering In~titute
Trends
• Animation of state transition models of behavior I '
• Performance 'modeling ':'
• Enthusiasm for object-oriented design
• Integration of tool sets with different capabilities from different vendors '
• Deliv~rabl~s satisfying 2167 I
~
'~~R
. : ~
iii
~_4 ...... ....., ••• ~ j. . .......... - ... -..--.............-.. ........ -t'.~~-,
.,' .. ,~ ' •. ",.,. :~ •. ; " f
" f
. ~ Clln.gi. M.IIo~ Univillily
~ Software Engineering Institute
,Tools Taxonomy
D,v,lopment !project management Ph.s, !Svstem/SW Aeq'ts Analysis
ISW Aequlrements Analysis IPrellmlnary Design
Detailed Desl911 ~odlng 'and Unit Testing
CSC Integration and Testing IeSCI Testing
I lSys InteglTest Oplf,tlon t on Object Other
~ Crute
Trln.form
Group ---~. -- -'- --
Analyze ". , ,
Aeflne -I
, Import
Export
Ot~or ---~- - -_.- -.-~- -
4. • W
~ Clfn-a" M.1IOn UniV./I;ly ; ~ Software Engineering Institute ........ .
lz:;::;:::z::.,~·a;::;:::a= .... uCti. ...---.,
Evaluation Attributes
• Ease of use ':'
• Power
• Robustness
• Functionality
• Ease of insertion
• Quality of support
!
\ I.
- r· r I· --., ,- -~ ."
...:::iIIIiii:. Clln.gl. M.lion Unlv.lll1y
. ~ Software Engineering Institute
View of
Problem
/
. Classificatio·n of Methods ':"
Stages of Development
specification " design
functional da'a flow POL diagrams
structural enllly ntlrarcnlcal r.laU,onstllp struc,ur •. dlaarams charls .,.,. ,
behavioral tr.nsltlon dlaarams
Different views dominate at different stages Views are comple-m8rllary-
Implementation
Iii
o
~ earn.gl. Mellpn UnlvllailY
° ~ Software Engin~ering InsUtute
Tools
• Software supporting the software development process ~ .
• Publicly availa.ble and supported
- Offered in expanding commercial market
• Value provided through
• Relevance to required development activities • Assistance to human labor
!'
---- .. -
I 0_ ._._. t,-'::: -
~~-
Carn.gl. M.non U(\iv.rally Software Engineering Instlt~e
"
Or, Larry ~. Uuffel
RIelS SyrnposiUIll '88
Novem.ber 9, 1988 ':"'
Software J?eveloplllent Environm.ents Status and Trends
Software Engineering Institute Carnegie ~ellon University Pittsburgh, PA 15213
Sponsored by the u.s. Department of Defense
--" .. -- -"- ~--
~ co· )...l
I ' ... (Q
...:J \\" 1-.:>" -....... \) .
t~~,!, ~
\~ ~ l
, ., " "" 0" ,"JI " 0 .""0 .. ' .. • ... ,,'. " •• ',' ,r!' - - , '1 _--.,;'11 't ..... , , ..... ' ......-- ,~ • •• • t • • & I '
" . !- ..... - .... ----. ; '-- ... "-' - - .
V' TOOL AND DATA INTEROPERABILITY IN THE SSE SYSTEM
I
De§igo ApprOAch for Transformation Procedures
• Identify Common Subset of. Tool Capabilities - Requir~s Detailed Underst~nding of the Tool
Suite as well as Application Domain
• Develop Text-based, Machine-readable Representation ~ Text-based format avoids machine-dependencies - Compiler Technology- can -be Applied in most Cases
• Common Interoperability Format should be Hidden from Applications, unless it is their Native Format
- Allows easy modification of Interoperability Format
.'. Transformation Procedures Require Similar support routines~ Design for Portability and Reuse - Up to 75% of code in an Interoperability to Tool Transformation Procedure is common.
,
. . -
" --""'.i.,~ • .lO.....--.. •.• ~ •• " .,.;::.;-...:.,..;,, ___ .• ~ .• ~_.-~l';.-'; ;;., ..... 1 ... ~-,;:r ••
v TOOL AND DATA INTEROPERABILITY IN THE SSE SYSTEM
Interoperability Overview
Tool A
Tool·$peclflc Forrpat
Transformation Procedure -A-
Tool 8
Tool·specific Format
Transformation Procedure "B"
Toole
Tool·specific Format
Transformation Procedure "C"
. .. ~
I·
l-=
S 54. •• ....! .,., if +4. !' ... r:o: tit: .r-.
•
!it •
TOOL AND DATA INTEROPERABILITY IN THE SSE SYSTEM
interoperability Overview
'.' Automated Document Production Procedure : ~ : ... :,: ..
INTSTYLE
r:'"~~·: I ,« 7' • , INTSCRIBE
Postscript Graphics
INTPOST
t----_.~I Scribe (Vax) ~: ~ ./
'--~ __ --:-____ """";' ____ -illntegrated Text and Graphics Document
---~
i . , i
I
I i
-
C 2 2+. • • ,~ W i' --:---'" - rr-t i '\: .~~ .. , '.. ... a ... fld!S_!1_' ..... _ .. aO SJiJ.iL!!!!SEJE!C2.' :. Pi
" ..
.!!!!!!!!II''- TOOL AND DATA INTEROPERABILITV ~ IN THE SSE SYSTEM
SSE Interoperability Solutio~
• Develop Data Interoperability Formats for Each Class of Design and Development Tool
• Provide Applicf\tion-JeveJ Views of Data, Versus Network, O/S or File System Views
• Tool/Data Interoperability Is Related to Information-bearing Entities, Not Physical Implementations or Interpretations ,
• Interoperability Formats Support the Intersection I of Tool Capabilities, Not the Union
a
v TOOL AND DATA INTEROPERABILITY IN THE SSE SYSTEM
I
Interoperability Overview
Mac II
,/
Apollo
+ Project Objects
/IBMPS/2
Project Objects
~
... .,:r:-~ -- ?----;
r--
\
" .. \ .,. .... ,.- l'· ... '· '.":··~''''~~:::!:'!~:-,r;.·;::~!'''·~.':''.!. .t:::!J:,tOO:':-;-::=.- ...
&
v TOOL AND DATA INTEROPERABILITV IN THE SSE SYSTEM
SSE Interoperability Issues
I
• Multiple Hosts in a .Distributed Environment
- Vax/VMS
-IBM/VM
• Multiple Workstations Networked to Hosts
- Apollo
- Macintosh II
- IBM PS/2 ____ . __ . __ _
r-- rT .,
\ . ,- \. .. ...... ,." _ , ...... ___ __ ......... _.} .1 ~ ... 1_15C. ~..,i~;,..U .. ' ..... ____ "!"' ____________ ~_.:.. ____ oIL
!!!!!!!!I''- TOOL AND DATA INTEROPERABILITV ,..,.. IN THE SSE SYSTEM -- -,-- -" r---~~.~--- I'
SSE Interoperability Issues (cont'd)
• Design Tool Interoperability - Cadre Teamwork, Iconix PowerTools, Excellerator
,-
• Graphics Development Tool Interoperability
-Interleaf, MacDraw, GEM Draw
• Document Development Tool Interoperability i
.. Interleaf, Microsoft Word (RTF and DCA Formats)
• Document Production
- Scribe I Postscript
r .. ['--
• 0 ,~ • Ie "" F"!. '.1 .l;: .. ~"'::'; .. ·.:l.;·.:".~;.""_
r--
" . . ,.". " ,
!!!!!!!!!!!!I''-. TOOL AND DATA INTEROPE~ABILITV ~ IN THE SSE SYSTEM
The Interoperability Problem.
~ Commonality of Data and Information
• Information Exchange between Diverse Tool Sets
• Interoperability Qetween Heterogeneous Hosts
• Interoperabilitybetween Heterogeneous Tools
Ii
.( wp ,1 r eu) P I' . i. .. ..... • __ ......... _ .. -... .:..---,,:...-'""'III~...,."""-~--......... -----~-,...'-.............. ..,'.,."'I'Q:r'" .... ~. - '.. '" 'H" jI .",! ~ 'f '~"1 ,...., ... ,-....,.. i Y ~ .... • -:1 :;s ... w '
W", TOOL AND DATA INTEROPER'ABILITV IN THE SSE SYSTEM
,
I
Past Attempts at Solving the Interoperability Problem
• CommOn Hardware Architecture .-I
- IBM 360, SDP, Various 'PC Standards
• Common or Standard Operating Systems - CP/M, MSDOS, Unix/POSIX
• Industry-develOped Data ·Formats - DIFF, DCA, RTF - IGES, TIFF, GIF - EDIF
• Stand-alone Tool Integration - Mac O/S_ - Software Backplane
,
· If- '" "''' < iCC;'. , ' "" ,"U," $ U i a P.;,;.. I *' .. _ ..;.. - ~ "'"": t-_. . .. ." ...... -.--.~ ......... -- -~ ...... -.---- --- r :
v SSE SYSTEM PROJECT·
Tool and Data Interoperability in the SSE System
Chuck Shotton ( I,
PRC 'I' t 11/10/88 I.
? I) '/ ..
,
.t Overview
TOOL AND DATA INTEROPERABILITV IN THE SSE SYSTEM
• Industry Problems with Program and Data Interoperability
• SSE System Interoperability Issues
• SSE Solutions to Tool and Data Interoperability
• Attaining Heterogeneous Tool/Data InteroperabiJity
- _ ........
,
L~ __ ~
., . ,.~! ::-.. ......... I ... :...~. ~ 0: .1- •••• .;. .... · •• ~." •• -;~:-.- • .I.--.~~~.-.-;-.-
•
~ Clln.gl. M.llon Univ'"dr '
. ~ Software Engineering Institute "
Software Development Methods ."
"
• Representations -:-
• Deriving the representations
• Examining the representations
r-- r- -I '
: .. S~ft;~~~vE~~ineering In$titute
Goals I
• Maintain separation of methods from tools supporting the methods ~ ..
• Point 0f view of methods and tool users, not tool-builders
• Separate classification from evaluation
• Repository for information
• Determine "gaps" in methods and tools
-------------____ - _ .a
; = z~
='"' -z I _. :g ; :0 -.. I 0 a- :0 ... ~: t----
t :A-A I ---. - ..
~A Z~
;i ~-z-:>
t T· =3 ci _ .. %c c_ ; ~z- .
~ -C'" ;,; z !--(I') c ---: ~
(I') ~i i >:
W . _z . c.J
~
C ~ ;=
1 .. - ----cr= c WI::. ~=
c.. :: -- .. j; == .. ! a:= : ~~ :._we
1 Q) W ! -::J cc - c:z: ;::
1 (/) 3: .s I-el- u-
1 c c .... .~
(I') _:~z
Q) !!c 4 Q) ~~:!!
u- ::::; . . 5
___ 0
i i C C.:4U ?:' el ·z .. !g ; t:. -I i= ,.
Ul 2 c-C W Cc
~ :;:) u. C Q) Q ,g ~-
0 ~ (G-
\ ~~ ~ { fo -I • en u c:z:
\t CC -c.. ORfG!!'IA!. ;:A;~2 rs en OF POOft QUAUTY
.. • I ~ ...... -" , 4 , >(, '?; ;';;:$ 4 4f '*."44 2 sa c. •. 4 .; A •• i 'R
4
---~ Catnegili Mellon Univelsiry
-"~ Software Engineering Institute "
Process Definition
• A sequence of life cycle ta$ks, which when properly executed produces the desired result
:-
• An effective process must consider-
- tJle relationships of all the required tasks
- the. tools and methods used
- the skills, tl aining, motivation, and management of the' people involved
n.:" .orn."
,
,-
~.
I ,. i
.. •
~ Carnegie Mellon University . ~ Software Engineering Institute
Strategy
.. . . Promote the evolution of software engineering from an ad hoc, labor-int:ensive activity to a m~naged, technology-supported discipline
~ I
, i
. \
~ ..
Cl!n.gl. M.Uon UnlvllIUy . Sqftware EngIneering InstitUte
Implementation 9f Strategy .. ';'
• Put process under management control - defirye - measure - optimize
• Adopt appropriate met~ods
• Insert technology that provides automated support for the process and methods
• ColI~ct automated tools into an integrated environment ,:
• Educate people
_ .... _ ... _,.--, ....... --,
,
.- r- ,r--. r- r~ r-- .,. ...... 1
• ~ Carn.gl. M.lIon Unlv./lily
. ~ Software Engineering Institute
CASE
• Process, . • Method.s
Components • Computers • Tools • Support environments • Engineers
Currently the engineers. are the ess~ntial Integrating factors tying all these components together I
The engineers today empower the tools versus. the tools empowering the engineers
~
• .P 1$4 ¥ 1
~ Carnegie Mellon University ~ Software Engineering Instltut~ :'
,---- ------- -----
Issue's ,n Software Engineering I
• Quality - correctness ':'
- reliability - performance
• Managing the software engineering process - oosts
I I
- schedules
• Productivity - individuals - groups
~ ~
Ot~237D0i1 ,. '-1 .. ..-_.
_ ,--- r--'- ---, • •• ,- .- r-: -r- r:- r- r- r- r-- ~
I . "",
."
PROCESSESIMETHODOLOGIES lIowarJ Yudkln
,
.. HOW WE STAND NOW
• OK For Small Projects, Not So Good For Large Projects • Not Good For Addressing Iterative Nature Of Requirements
Resolution & Implementation. ~ostly Based On Waterfall) • Does Not Address Complexity Issues Of Requirements
Stabilization (Based On Functional Decomposition)
• Does Not Explicitly Address Reuse Opportunities • Does Not Help With People Shortages . 2:
U> ~
I I
NEED TO DEFINE AND AUTOMATE IMPROVED I
SOFtwARE ENGINEERING PROCESSES • I
t-6 t~ CD -'v L\ ~ \)~ 2I..~ ~ , ,¥. ~
CJl ':\---"S\
~ .flODUC11VnY I 2:)
CONSOkTIUU-
~
~' -~ "
/
REUSE AND PROT01YPING -TWO SIDES OF THE SAME COIN
• Reuse Library Parts Are Used.To Generate Good Approximations To Desired Solutions, i.e., Prototypes'
" !.-
• Rapid Prototype Composition'Implies Use Of Pre-existent Parts, I.E., Reusable Parts
- Prptotype Quality Depends On Fit Of The Available Parts
- The Parts Will Often Require Some Adaptation As The Set of Parts Available Becomes 'Richer The ,Prptotypes Will Better Approximate Acceptable Pieces of Final Systems .
!y~SOFTWAaB ...... , ___ p¥AIpr'aoDU~VITY •
~
It' = ZQ2 .\ W - 'WI:.. .==UI.'_"'_t:nOi= , --' r--- r-·· ,--- r- ~ ;---,:- :__ ~
-.--.- n ". ;.
/ REUSE PAY-OFF
•
R
Big Gains In Productivity E L
Will Come From Reusing A T Fewer Larger Parts Or I
Assemblies Of Smaller Parts, v Not From Many B
Unassembled Small Parts. p
• 80% Proportion of Reused Code
R
Productivity Gain vs Cost Is 0 D
Accep~ble If Assemblies Of u 20~ C Parts Are Reused Frequently. T
•
I 15Mr. V I 100" T 0" Y 20" ,40" 60" a~ 1~
RElA11VB COST TO REUSB
j. 11,15.22& .... ' .. _ MitA_ ... n e , .... ~ ., -- ... _- - '11 ., 'r~
._-_._--
SYNTHESIS MOTIVATED BY AND ORIENTED TOWARD • /
• Reuse: Exploit Similarities Across Systems • Iteration: Feedback and Enhancement
• Composition and Adaptation: Using Standard Schemes, Parts, and Designs
• Specialists: Incorporate Expertise, and Facilitating and Coordinating
• Systems View: Engineering Process
• Applying Synthesis to "Synthesizer"
CEO-SR-0041.06-IO 1381-11/16
i I
~ r-_:___ __' '"' ~_: _~- _NOr- . r -,.
/
( , THREE MAJOR SYNTHESIS SUBPROCESSES
D~main A~alysls
Application System Modelina Toolaet
DO~aiD In~opendent Toolsets
I '
--~.----.-
Project
Library &.
Work
Areas
System Development & Evolution
Reuse Libraries
•
Scavenging or
'.
Reo Engineering
~
_--I~. Reusable Work Productl -=--=-:3Ij"~ Single System Work Products -~~~ Developed Toolset
Pl.ODUCfIVJTY '--coNsoanu ... •
~
-~- ¥. PO "
~ r-, .... ~
\. .
LIBRARY CONTENTS ,
, . Application Models Executable Code
lr---~:== / I :!i'! i ii;::;!1
,
I.b: i ;','ii.lflthl:i!!i::::U: 1.:; "",
:':,' ,
, -op-"ii:iiiii L J!,l :,~; --
I.
• Other Work Products
~M.~
CEO-SR-0041.06-IO I ~aa- 15/16
I '---
I
\ L
\ L
,
..
..
TARGET APPLlCAll0NS FOR. DOMAIN-ANALYSIS -AIRPLANE EXAMPLE
Systems
C sf. c::.....,..
Subsystems Assemblies
;,. ~. i _loth].Ii --R ? e ( ..• -... ~ ,,~ . ~
,"",\
ESSENCE OF DOMAIN ANALYSIS
. ' • ~ach appli~ation area must be analyzed and characterized by
s~andard designs or architectures that capture the way that many systems in that a~e~ __ ~~~~~ reasonably be built.
"
• The application eng-irieer must be able to state his needs in ,I application terms and have those needs mapped appropriately
to an instance of the standard design.
• The design instance can be realized by specification of a set of parts from a reus~ library and a set of rules for combining those parts.
•
........., - ----~SOfTWA.e
. ""-.,r---:?!.r JCTI •
I
I •
'" (, _._--.- r-- r-, r-- r" - i ( II $., AF Hi i ' ell 1
'-". t, • , .
SYNTHESIS SUBPROCESS - SeA VENGING •
• Many systems with software have portions amenable to adaptation for reuse.
• Scavenging theSe systems for reusable parts' involves:
- Extraction
- Generalization
- Standardization
~ Certification
- Cataloging and storing in reuse libraries.
CEO-SR-0041.06-IOI )aa-lal2~
--
Il
A ......,
"
I A MISSILE GUIDANCE SYNTHESIS PROTOTYPE TOOL
An example of the application of reuse, prototyping, and synthesis using a reuse library in a specific domain
• Based on U.S. Air Force "Common Ada Missile Packages" (CAMP) parts
• Initially demonstrates a ~ongitudinal autopilot control system,
• Ald~ understanding of the economics of
I
reuse
r--- ... ------I S ---------------~ I Iy :N IT Iu I I 'E
S I Z E R
OUIDANCE I I r------M .. DECISION SUPPORT I
SYSTEM I I I
I I I I I I I I I I I
'--------_ .... ----
& sonw".! ... "'«:"' ,,~: .. ~!, -: ' ... ---....-
---_.,,..-' ..... ..,
User I
Inter-face Services
-(-,
PARTS OF SYNTHESIS/SYNTHESIZER - .... _- ... -
------------------Domain Analysis
Application System Modeling Toolset
Domain I"dcpendcnt ------.1 . Dynamics Design Assessment
Composition II Traceability
Coding II Verification
Management OA and Coordinatio Documentation
Reuse Libraries
Project
Library
&
Work
Areas
. '
System Development & Evolution
CEO-SR-0041.06-IOI388-191l6 ,
[_ n.~_.- --:'. '-'r"'-;:::=-- '-1
,
~
Scavengin$
....... ..
·--.. -----.--...... "'-.--- . · ·1 A
A METHODOLOGY FOR PARTS SPECIFICATION AND MODEL-ASSEMBLY IS EVOLVING ~
"
• / Based On NRL'Software Cost Reduction-Methodology ~ Information Hiding Module 'Families - Abstract Interfaces
• Accommodates Ada Packaging And Tasking Concepts - Ta~king Guidelines Evolved (ADARTS)
• Initial Guidebooks Written And In Use
~
~SOFTWARB
oM ~ PRODUCTIVITY • - ~ I~~ , l
__________ - •• ". ____ .. __ :¥.nq~.:. ''f' .~~ e Z-U";:f:TTC"=na;n: _ ... t.::. W
r~ [- r-' 1-· ••
/
Info ..... tlon.1 Fllien
-
sr. .:.oGIO,02';IOT'ur-n,.
n r•
PRODUCTSETIASTRucrURE
AAD Editor
Prl!.er I ~ w
"
Ada Skeleton Genentor
~
~
Diagram Graphical· Database 1 ... 1---------'
~
HADC DIANA Dlacnmmer
~
PDL File
PDL->DIANA
PDL Se •• ntlc An.lyzer
(IW)C FE)
t PDL
d.tabase (DIANA)
:'\. '\.,
;:s. \----..... -~ -__..--- " ." ,~.-r: ........ '" ~, ~
.....
.,~
DYNAMICS ASSESSMENT TOOLSET COMPONENTS
,.I
........
~~ ... ........... 1 ........... ;
• .. ,.... .. 1
. , ........... ........... ~-- ' ..... '
Onphic Editor
g
" .
. __ .... _-._---
~ Results t=
..... ttfTTfl EEEEI I I
_.- --.- - ',·1
\ '\\
, • 4 ,<,. Wid '''''1'\!. ,,\4; "?!I" 'lP'P';;,';:;". 4)A!ijhi!~, ,'.'_-9- 4 ,4Fi ~
•
/
Tool
. . . . . . .
,User , Int~rfa~ services
• • • • • • •
XKfndow System
r. ""'~ A' ............ ..
,,~
UIS ARCHI'IECI'URE
User \ , Interrace Code
Computation Code .
Widget Instantiation Calls
X Toolkit
X Library X Protocol Networlc MelSQlII
X Display Server
Tool Computation Callbacks "
(or Integrated Server lor X and Native Window System)
'.
~ .
!
~ . ? 4 • ... • II " , . , '" q '-"3} I' .,"t' 't"d'_~Cl - ~ .
,~
THE LAYERED REPOSITORY CONCEPT
ONE lOR EACH MEMBER COMPANY NawORJt LOCAnON
ONE lOR EACH .ROJECT
RKPOSITOR
,
" .
DlSTRIBurED DATA, LEVEL
- - - - -- - - - - - - - - --- - - - - - - ---- - - - - - - - --I
OfflC ,0. MOD ~R EACH DATAllASB LOCAnON
C"TKD • ..,ON Pa«)J1CI' NDDS
(cxx.LK11OHI CAN CONTAIN DATA oaJecT. ANDIOl cmtll COLf,.ICTION' )
,PAR'lTftON
COLLECI10
INDIVIDUAL DATABASE LOCA110N LEVE~
~ - - - ~ - - - -- - - - - --- - - - - - - --- - - - - .....- - - _ ... OBJECT LEVEL ACI1JAL DATA
OBJECI'S. INCLUDa B011I RDBMS sroRAGE AND cors CM SfORAGE
~~A.Il. , ___________ - ___ .~.:O~'~~M·~ .... J
• tf • ..~. ••
• • It 4. p;:::::W::: - - r-- I ~ ,-- --- ;-s-. ;:::z: ,.--:- .--- "I (j.
typICAL PROJECf LmRARY ACCESS,
A'PLICAll0NS CODE: TYPICAL COMMANDS DMS CODE COTS PRODUCTS ..
• • - DJISIOH TOOL : - ASSISSMI!NT lOOL • - TaAClAIILm : - HAItNISS 'tOOLS - ~C DlVILOPBD
lOOLS
TOOLK
DATA OBJECT RELATED
- CReATB DATA OBJECT - DELBTB DATA OBJECT - CHICK OUT DATA
OJJECTIODY - CHICK IN DATA
OBJECf BODY - OBT ATI1tI.UTE
ATTRIIUTES
AElATIONSHFS
- SBT ATI1tIIUTB - OBT CONTENTS LIST •
DYNAMIC SOL INTERPACE
--- --··---· ... ~-ri ~----..... ,
RELAllONSHIP RelATED •
- CREATB RELATIONSHIP: DASlDMS ...
- OBT ATIlUBUTE: : - SBT ATrRIBUTE· • '. . - DBLBTIl RELATIONStUP • I I ~
• • • UNIQUE 10 RELATED • TAILORED CODB • INTERPACB
- pAnfHAME 1'0 UID " - RELATIONSHIP 1'0 UID "
QUERY RELATEP
- PBTCH BY A1TRIBUTI! VALUE
- OET ItI!LATIONSHIP TYPES
- OeT IlELATI()NStUPS
--------------~-------------------
OBJECT IQ)IES
~~AU AfJIIfIIJ&P0DUCTM1'Y •
~ 0"" · ""', -1 .....
,
~
Tracing relatlonahlpl to a .. t ... 5 3,1.1.2 cap 12Sep8(J' ITII of related object • o JIJIItdIJ .. 3.1.1.2. t
• JIIjcfddtInk 5 3.1.1.2.2 0411
• .-mIen 2 3.'.1.2.3 cap · "",. 2 3.1.1.3 cap I
D 1MIdf .. .. 3.1.1.3.1 In
• Naldfmk .. 3.1.1.3.2 OUI ,Change pt!I!!!!ij,~ce!~> • I !. ==&&!.L · ... ..,.., 12 3.1.1.3.3 cap
0 __ • 3.1. I .• --- -_ .... ~.---
o IIrIIdIM l 3.1.1 .•. 1 In "
/ ~ NAV - TraCe ReIaUonshlps [!J Tr-anG from requirement. obfoctl In NAV ~ 1 ,
it 'P,,1/1 .I"'~~ ,
"l4a"tHUltJp a lmpIemenIed by "".(,)' n cMftveCt f,om
a~1n a .'Jkallikldi'o
'P"1/1 ,co". oj "deilt,
IIVU:CCMS I I fiiQ]
- ------
~nwAU
. 1001' . .,v," . -- ] *~ _..' • to
'I ,c, ". o
a i t;C~. ,r~.~~~!BII~LU~~~_~!m~B!"BI"BlIBII"~B!""~"II""""alm
" 1····- t-· r- . ,._. r- ~. r- r- l
. ModInca~ Rcqutit
/
(J.
IMPACT ANALYSIS TOOLSET OVERVIEW , . ,
Pcraon
... non
Inltl.1 Imp.ct Sct
r;:~ Anal,.. ToOl
OBJeCT CHANoe LIST: -" - -' •. Ust ollmp.ctcd obJecu to
cufnln.
o o Yel o
~ /' g I
10
EatJmaa.d ...... lei
I Mana..,' , Co.dl •• COIIInIIIId.
/ Veril, that penon np.ctedlchlnaed aU obJICU In the chance lilt
forpt III 1=::-1
as
I
...
•
~ - 1
CANDIDATE USER INTERFACE FOR RLT , ..
'l)pc. 01 ur. C1de obJectsf S.ledJo. Crtt.rla
ClauiftcatJon l)o(umenta!Jon
Sowce Code
aequltcmcnu
DcaJ", r--
L~ Executable code t- -- --
D MlseeUaneow
DaJ", --
DIII&n ~
LCO InrormaUon ~"pl'1
General Attributes ~CO 1)pca Pin ID
1087 Nlme "ttrlbute.
opp Struccure Description
-- --- ----Tlte P 15 opp structure ..... ~latJonahJpl
· · " 1 ·
~~A.I!
--- -.--:-~·~~!a:!7Mr~_,
L L -L
·L L
1_
•
Concunent a c. 6 .2.. 1.. , , .. ((
N91-19~-z.6' A New Generation of 3.: :: ~ .; 0 ~ ~
Real-Time DOS Technology for
Mission-Oriented System Integration and Operation ,.-
E. Douglas Jensen
. Concurrent Computer Corporation
Westford. MA (50&)692-6200
edj@cs.cmu.edu. uunet.uu.net!masscomp!jensen
University of Houston RICIS and SASNJohnson Space Center Symposiu:n-on-
lntegrmed Computing Environments for Large. Camp/a Systems
November 10. 1988
Concurrent I" ."
,- Outline
• System Integration and Operation (SIO) Requirements
• New Generation Technical Approaches for SIO
"-
__ _ ~ J ..... __ .. 5 .., ~;.e _ $." _ 55 A.
I I I ' - I:
\ l 1 I ;
. I !-, ! •
. .
! :
. ,
Concurrent .. 51 .. ;.CX .0 .. %. ..J .
System Integration and Operation (SIO) OS Requirements
• Real-time
• Distribution
• Survivability
• Adaptability
. c. _ A .£2 j ) . _ 4). 4.3. . ,. s _.. s w· .. ~.. It .. " u
~': I ... --....~E _ .......... c:...-.. a: I"", 1
.--
Concutrenf a .P.i,
SIO Application Requirements
Real-Time
• The application, and thus the os, activities have various types of stringent time constraints (~.g., hard and soft deadlines) for their completion, which are part of the correctness criteria of the activities because they are critical to mission success and the survival of human life and property
• SIO is a dynamic and stochastic environment
• a high percentage of the activities are aperiodic with critical time constraints
• not all periodic and aper;iodic time· constraints can always be met, in whic~ case application-specified recourse must be taken i
• A-ctivitieshave dynamic (time- and context-dependent) relative importance (functional criticality) as well as urgency (time criticality)
• The perfonnance of the system, and of its as, must be optimized for high-stress exception cases, such as emergencies (e.g., due to faults, errors, and failures, or even hostile attack)
••••.•. y ',. _ •• __ ~U .. B.a, .. J., ,I (4 ,j£ i JA t"~N .3 _ .. k
u • ,.
. i I
,
t I I
l ·
.Concurrent a .. t .. i 5. i.H.S
SIO Application Requirements
Distribution
• Each system consists of many subsystems containing singleand multiple· processor machines which, for technical and logistical reasons, are loosely interconnected (Le., via i/o paths such as buses or links) -
in some systems, the subsystems may be physically dispersed across tens or even hundreds of meters
• These interconnected machines constitute a single integrated computing system, dedicated to a particular application, executing-complex distributed programs-
J . ,
• A multiplicity of such systems ~ommunicate application data and status among one another. and are implicitly or ,
explicitly coordinated in their mission activities -
the distances among systems may be hundreds of meters
• System integration and operation is automatecL and under the control of a (human) hierarchical command authority
, JJJ •. S. USO .JA LUM ) .... M£,__ £ _'. 0 ..
s
Concurrent . p. , ...
SIO Application Requirements
Survivabilitv
• The computing system must tolerate conditions far more severe than those encountered in non-real-time contexts
• some systems are subject to hostile a~ack, so their hardware faults tend to be clustered-in space and time
• different systems have a wide variety of mission periods for which there -is no single robustness approach: from hours to decades
• limited or no repairs may be possible during the misSIon
• the system usually has to remain -in .non-stop service during recovery from faults
• extreme safety concerns: system failure; may jeopardize the mission, human life, and property :
• Because the hardware and software are distributed, there are multiple independent fault modes
• Overloads, faults, and resource contention are inevitably dynamic and stochastic
• Optimal perfonnance under exceptional stress is the raison d' etre of the system
6 '.
. (
t \ \ J
1 i ;!
Concurrent a . .c .
SIO Application Requirements
Adaptabilitv
• Application limitations often demand maximum computing capability for the allowable size, weight, and power, which argues for special-purpose hardware and as; but there is not just one set of fIxed computing requirements
• There are many widely divergent real-time SIC applications, and the high costs of developing their computing systems argues for generality, standardization, and re-usability of the hardware and as . !
! ,
• The computing requirements for any particttlar application evolve continuously over the entire lifetime: of the system because
• the application is extremely complex and difficult to understand
• the application environment varies with time
• technology advances rapidly
and the application system lifetime can be decades
. 49.4 _. 5.53 5,. ... # "LS ). . ).39P .M , .' j ,
i I I
\ i
\
Concurrent . Ii ,i . l... . ¥ '" iI· fiE'" ? H f'
New Generation Technical Approaches for System Integration and Operation
• Real-Time
• Distribution
• Survivability
• Adaptability
a
, .LS .;s ... e $ S .. £,.3 _ •... 2 .J ..... . Z_. 5: L
• ,
: \ i I
. \ ., , '-
, . i.
\ .
. \ - ,
".
.. . . 1
•
Concurrent Q 4.i
New Generation Technical Approaches for System Integration and Operation
Real-Time
a
• Manage all physical and logical resources directly with actual application-specified time constraints as ~xpressed by time-value functions for all activities -
• manages periodic and aperiodic activities m an integrated, unifonn manner
• distinguishes between urgency and importance
• allows not only hard deadlines but also a wide variety of soft (Le., residual value) time constraints
• accommodates dynamic variability and evolution of both periodic and aperiodic time constraints j
• provides behavior which is as deterministic as desired and affordable '
• handles overloads gracefully according to applicationspecified policies
• suppons the clean-up of computations which fail to satisfy their time constraints, to avoid wasting resources and executing improperly timed actions"
• employs the same block-structured, nested, atomic commit/abort mechanisms· as for transactions
• Optimize perfonnance for exception cases
... UJA LL£.~._. .e:z:e.x .
t
Concuaent ·w .... 3 •. 9 .. .. m Xi'
Sample Time-Value Functions
.. , l J ~ :if 11 ~ II .' a ,~ ' . .. l( .. ~ .-i
I ! i ~;et '
v a 1+-----. u e
time
Non-Real-Time System
0 Exception V
e r h e Normal
a d
time
. 5 .. LW. Z.. _ s.s. .W ._. __ ... 3
v a 1 u e
time
Real-Time System
0-
V
e Exception r n Nomuzl h e-
a d
time
I I
I 1i
1
i I
J. •
.~
.. ----- ---- -
Concunent . t ... 6 . 8A f. i $(. . J.. , .U
New Generation Technical Approaches for System Integration. and Operation
.' Distribution
• Provide a new programming model which is well-suited for writing large-scale, complex real-time distributed software:
objects (passive abstract data types - code plus data), in which there may be any number of concurrent control points; and threads (loci of control point execution) which move among objects via operation invocation
• A thread is a distributed computation which transparently (and reliably) spans physical nodes, carrying its local state and attributes-for timeliness, rODusmess, etc.;
I •
these attributes are uSed at each node to perform resource j
management on a system-wide basis in the best interests i (i.e., to meet the time constraints) of the whole distributed: application
• Distributed computations must explicitly maintain consistency of data and correcmess of actions, despite asynchronousreal concurrency (and multiple- independent hard-
• ware faults) - to accomplish this requires (at -the kernellevel, because the as must itself be distributed)
,
• real-time transaction mechanisms for atomicity, -application-specific concurrency control, and pennanence
• system- and user-supplied commit and abort,handlers ".
j U ; .
Concunent is .. 3
New Gener~tion Technical Approaches for System Integration and Operation
Survivabilitv
• The survivability properties and approaches include
ex
• graceful degradation: best-effort resource manage-ment policies; dynamic reconfiguration of objects
,
• fault containment: data encapsulation (objects); object instances in private address spaces; capabilities
• consistency of data, correctness of actions: concurrency control objects; resource tracking; thread maintenance; abort blocks; l real-·ime transaction mechanisms (atomicity, concurrency control, ~ermanence)
• high availability of services and data: object replication; dynamic reconfiguration of objects
• The- survivability features are presented through the programming model as a set of mechanisms which can be selected and combined as desired - their cost is proportional to their power
• Transactions
• are scheduled according to the same real-time policies as are all other resources
• allow application-specific commit and abort handlers
.. utA t . 3. .L •. e. :.; .... £'._. £ . £ 51
"Z
•
Concunent . . x. JS . .t,.). ow , ,. ,¥ Ei W ..
New Generation Technical Approaches for System Integration and Operation
Adaptabilitv
a
• Adhere to the philosophy of policy/mechanism separation:
• have a kernel of primitive mechanisms from which everything else is constructed according to a wide possible range of application-specific policies to meet particular functionality, perfonnance, and cost objectives
• provide these mechanisms at the optimal level of functionality - i.e., both necessary and sufficient to create large scale, complex real-time distributed systems
• Encourage application-specific information· to be exploited statically and dynamically - e.g.,
• special-purpose objects can be migrated into the kernel
• references to objects can be monitored for locality
• any attributes can be carried along with threads
• special hardware augmentations can be objects
• concurrency control and abort handlers can be special
• resource management policies are application-defmed
• Employ elastic resource management which flexes to tolerate variability in loading, timing, etc .
. • _ ... ~ __ ,.,.€5
"'
Concunent a Alpha Program Management Overview
• Alpha originated at CMU-CSD as part of the Archons Project on real-time distributed computer architectures and operating systems-Doug Jensen was the Principal Investigator
• As part of a long-continuing ''Think-Do'' cycle, new concepts and techniques were created, based on the PI's 15 years of industrial R&D experience with real-time computer systems,
then many of these were embodied in a feasibility test vehicle: the Alpha real-time decentralized as
• The Alpha prototype ("Release 1")
• lead by Duane Northcutt, with a team of five programmers for about three years
• written for (homebrew) multiprocessor Sun worksta;' tions connected via Ethernet
• consists of a high-functionality kernel, some system-layer functions, some software development tools
• installed at General Dynamics/Ft Worth in 1987 and demonstrated to many DoD agencies with a real-time C2 application
• numerous technical repons now becoming available
'.
l-
-------- -
Concurrent a Alpha Program Management Overview
(continued)
• Alpha Release 2
• intended to make the technology externally accessible, on reproduceable hardware platfonn, and further develop it
• _ kernel interface spec subcontracted by eMU to Kendall Square Research, which Jensen later joined
substantial functional enhancements were included
• initial detailed design. subcontracted to Concurrent "-
when Jensen moved there
• continuing research and remainder -of design and implementation is part of a pending procurement
• Jensen's Ph.D. students continuing research at CMU
• pre-release available mid-CY89. release- at end -of CY89
• portable, open, multi-vendor hosted
• Release 3
• si~cant enhancements over Release 2 ....
• release at end of CY90
25. .
,
---,
IL - ~-I
It --" - ,
I \ ,
, ,
- -- .-:-:--.- -_.--_ .. _. -
~
a-: - .:,. ~ ~; /
N91-19727 ~<\
"" ..J
~ 2 LLI
~
~ ZCO :Jco LL.
en ... "" .. - en '" >0:: ...Jw «= 2:E«LLI ",> .... 0 22 W
~ W 0:: -:J a LLI IX
LLI W
"" . .... ...J w' « -X-I~ ; ~, I i
........ --
\
\
...
. - .~ ' .. " .·.:·.,.,,·.,.,··_·.:-..'·.··.·c,· _ .. " ... -c-=,....--.-.• ~."'~,
INTRODUCTION
ADVANCED PROJECTS SECTION
• ELEMENT WITHIN MISSION OPERATIONS DIRECTORATE
• RESPONSIBILITIES
'1
- DEVELOP/COORDINATE USER REQUIREMENTS FOR GROUND INFORMATION SYSTEMS SOFTWARE (E.G., MISSION CONTROL CENTER UPGRAD~) AND TRANSMIT TO DEVELOPER.
- REPRESENT OPERATIONS COMMUNITY (USERS) TO DEVELOPER.
- REPRESENT DEVELOPER TO US~RS.
- DEVELOP/PROTOTYPE USER APPLICATIONS .
.. PROVinE CONFIGURATION MANAGEMENT OVERSIGHT FOR USER APPLICATIONS.
"
"
(I'
•
.,
PROBLEM
• SOfTWARE PRODUCTS OF THE CURRENT DEVELOPMENT PROCESS OFTEN DO NPT FULLY MEET "TRUE" USER NEEDS UPON DELIVERY.
- DELIVERY OF NEEDED CAPABILITIES IS DELAYED.
- COST OF CORRECTING SYSTEMS AFTER DELIVERY IS HIGH •
• PROBLEM IS ROOTED IN REQUIREMENTS DEFINITION AND ANALYSIS
PROCESS •
r-
!/
..
CAUSES
• REQUIREMENTS DEFINITION FOR CONTEMPORARY INFORMATION SYSTEMS IS INHERENTLY DIFFICULT.
- HIGH HUMAN/COMPUTER INTERACTION
- APPLICATIONS DEVELOPED BY USER COMPLICATES APPLICATION INTERFACE REQUIREMENTS DEVELOPMENT
• REQUIREMENTS CHANGE RAPIDLY .
. - USER POPULATION IS DYNAMIC.
- USER APP~ICA TIONS ARE CONSTANTLY EVOLVING.
" -~~~ , . I
- NEW PROGRAMS (E.G., SPACE STATION) INTRODUCE NEW OPERATIONS CONCEPT$ •
• NEW TECHNOLOGY IS CONSTANTLY EMERGING.
- EXPERIENCE WITH CURRENT SYSTEM UNCOVERS NEW REQUIREMENTS.
..
r+Y ..-- •.••. , . "IIIf ......,.. .• ..... , ..... "-" , .. , ,''''-', .... ·.·.1·.. ,iP'Ii.." 4*. ':" C ..
CAUSES (CONTINUED) .
• REQUIREMENTS ARE OFTEN INCOMPLETE/CONFLICTING DUE TO DIVERSITY OF USER COMMUNITY.
- TASKS
- FLIGHT SYSTEMS (E.G., DISCRETE VS. ANALOG, TELEMETRY VS. TRAJECTORY)
- USER EXPERIENCE LEVEL
• REQUIREMENTS ARE EASILY MISINTERPRETfr. .. . ELOPER.
- USERS ORGANIZATIONALLY SEPARATED FROM DEVELOPERS.
- WRITTEN DESCRIPTIONS OF VISUAL SYSTEMS IS INADEQUATE.
.. • THESE C9NDITiONS A.RE NOT UNIQUE TO NASA MISSION OPERATIONS.
i-
-.
'-
INTRODUCTION TO SESSION 1
REQUIREMENTS ANALYSIS FUNDAMENTALS
• "REQUIRE~ENTS ANALYSIS, DOMAIN KNOWLEDGE, AND DESIGN, II COLIN . POTTS/MCC SOFTWARE TECHNOLOGY PROGRAM
SUGGESTS INNOVATIVE METHODOLOGY TO:_
• ACCOMMODATE CHANGING/CONFLICTING REQUIREMENTS.
- SYST~MATIZE TRANSLATION OF REQUIREMENTS INTO DESIGN, REDUCING MISINTERPRETATION.
- IMPROVE REQUIREMENTS COMPLETENESS •
• ENHANCE TRACEABILITY.
,
...i
.. ____ u __ • __ ~ __ ,-_ • ..: ........... .;;. ..... " • " ... --=- i' 1 r--
INTRODUCTION TO SESSION 1 (CONTINUED)
• "KNOWLEDGE-BASED REQUIREMENTS ANALYS.IS FOR AUTOMATING SOFTWARE DEVELOPMENT," LAWRENCE MARKOSIAN/REASONING SYSTEMS, I~C.
PROPOSES NEW SOFTWARE DEVELOPMENT PARADIGM THAT:
- AUTOMATES DERIVATION OF IMPLEMENTATIONS FROM REQUIREMENTS, REPUCING MISINTERPRETATION.
- INCREASES DEVELOPMENT PRODUCTIVITY.
- VALIDATES FORMALIZED REQUIREMENTS.
- ENHANCES TRACEABILITY.
, I
I WI
r-r-- ,.-- ,-- - .--. I' f I
RICIS '88
SOFTWARE ENGINEERING AS AN ENGINEERING DISCIPLINE
ROBERT B. MacDONALD -I
MISSION SUPPORT DIRECTORATE NASA/JOHNSON SPACE CENTER
11
J
\0' ~ '" ::.\
,
. . ~ w ,. "~.,,, '\.~! '.¥.'jP·i;c;;'·4t 4,. ,i",.,'P'f4 J;:»:OS' ."i'(,ti ;. .... _~_ ...... _:_:'0 .J ;$ AS ._._
RielS '88
DEFINITIONS. OF ENGINEERING
• ... appl1cat1on of mathematical and scIent tflc 'bodies or know le~ge' as captured by predictive models, laws, etc. to the problem of ~estgn1ng and construct 1 ng econom 1 ca I and reliable systems whlchfulrUI some real need."
..... establ1shment and use or sound engineering pr1nc1ples to obtatn econom1caJ software that Is reJ1a~Je and works efftclently on real machInes"
I I
I ' I
• 5 I a IF ow 4 4 ".... q ;. "'" r:q i.
, ,-- ----,. ,-.- r- r-- - r- r·- r-
Engineering
Tailor (Craft)
Tinker (Pr.Craft)
RICIS '88
DEVELOPMENT OF COMPUTING: A PERSONAL MODEL
Hardware
1940's '50's' '60's '70's - ·'SO's '90's->
l~
I °CJ -tI) z -(J - -a: a: 0' w
W en en Z :E ::& cr: ~. -CJ II:
CJ CJ Z 0 o· W a: a:
D- _D. W ,
-I
a: -- c( -cc til a: a: I-
~ w· en > :::) - Q Z
t.L. ::) z -0 0 0 til
0-
, '. -
() . ? 'J
,..,
CHALLENGES I
HOW TO GET 4-5 YEARS OF CONTENT PACKED INTO A aURR I CULUM
VERIFYING THE DESIGN
DEVELOP MODELS OF A MATURE DISCIPLINE, E.G. MAXWELL'S EQUATION OR NEWTON'S LAWS
.,
",
RielS '88
,
, ."
I
I
f
I. _ .
r- r- ~
'.
I
"Empirical Studies Of Software Design: Implications for SEEs
Herb Krasner :2! <C t-' I , Manager, Software Process Research
Lockheed Software Technology Center Austin, Texas , I
~~ ,~
A :--~~.\'
~Lockheed Missiles & Space Company, lI1c. Soltwara Technology Center .11758
,
."
/
l('"
Empirical Research on the Software Process :.\':
LIFT e)(perlment
8 e)(perl~nced programmer" deSigning the control struclUre for a set of elevators during an Intense 2 hr. session
Object server e)(p.
Videotaped team meetings from a 7 mo. efforl 10 design and build a tool to support object oriented programming
ClIslolllnr
I~" ~ f;I'X",X lunm .
~1~9,':l\__ .... I'ruJnell'-' ... Jill ~ .. loom .
Ohsorvors
--,
~~:?t~l~t}J:tlUt!tj~W~h~ ,', ',t';::;1!(~ ~>w~i{1"ro ~9tJ~v~I'::·~\i"j,;l.' }."f;.~1"~'-~'\\; .!}~, ~;)\':'l'i ", ~:J liO' '.\:, ." ~d.~
<
Field study Detailed Interviews with key members of 18 large development projects to model their decisionmaking and communication process
.....
Flolcl 0 0 _~ Sllnroholdor SIIllIY~. c\"<r ~I) I)[o)oel tomll [!J Y;'t mombor
_ 'W' I-Jml...r
~Lockheed Missiles & Space CompalW, Inc. Sollw<lro TochllolocJY Conlor 11759
...
I
.. -
Results of the Field Study
'--._-._-
--,
• Observations about commonality/difference of projects •
• Identification of five areas of organizational breakdown (within , that sixteen specific problem$)
• Implications for process modeling
• Mapping of problems onto lower-level phenomena
"You need to understand, this project isn't the way we develop software at our company." . '
~Lockheed Missiles & Space Company, Inc. Sollwal8 T echnologv Conler 11760
.. _.0 •. w_.~._ .. ______ ·
,
Pro-ject
1 2
/ 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17
'- a
Characteristics of Projects Studied
Stage of We Cycle Real
KLOC---· -·-t1m'e
Terminated -.". Qevelopment 24 ~
Development 50 ~
Development 50 ~
Design 70 Development 130 Development 150+ ~
Maintenance 194 " Development Maintenance 250 Development 350+ Maintenance 400 Design ~OO ~
Maintenance 725 ~
DevelQpment 1000 Maintenance 50k+ V Requirements 100k+ V
Characteristics
Dist. Emb. Svs. Svs.
~
~ V'
~
~I
V-
V- V-V- V-
Gov. Application
" Support Software Radio Control Process Control Operating System CAD
~ CAD ~ Avionics
V- C3 Compiler Run-time Library Compiler Transaction Proc. Telephony Operating System Telephony
V- Radar, C3
V- el, Lile Support
~Lockheed Missiles & Space Company, Inc. Soli Wille Technology Conlol 11761
lIP
I I
j I
Summary Qf Results from MCC Field Study·
_ ..• _--.- .. _-
• Analysis of three significant problems
/ • Layered _behaviorial model of software processes
• Conclusions and implications
• Pap~r appearing in this months CACM ~Lockheed
Mlssllos & Space Company, Inc. Sollwa/s Tochnology Conic/ 11762
-i
I'
. ~.-
Analysis of Three Significant Problems in Software Design for Large Systems
/
Application Knowledge Acquisition
Fluctuating ______ •. JlOd Conflicting
Requirements
Communications Breakdowns
Effect on " productivity ---" and quality
I through
I behavioral processes
~Lockheed Missiles & Space Company, Inc. Sollwale Technok>9v Cenlel 11763
I·"~
I
•
Layered Behavorial M9del of Software Processes
--~ __ --,II " Cognilloll and Group Mollvallon Dynamics
Organlzallonal Behavior
~Lockheed Missiles & Space Company, Inc. SoliwOl.G T ochnologv Cenler 11764
---
&'\
Implications of Field Study Results
• For Software T e~tmology - Environment support needed for:
- Knowledge integration - Change facilitation - Broad communication and coordination
- Be~lnnlngs of an empirical model to meaSllre improvement for a tooVpractice
• For Project Management - Expertise is the primary determinant. new ways of effectively Qrganizing should be pursued - Key role players identified and described: .
superconceptualizer. diagnostician.-Qatekeeper. boundary spanner - Coordination by shared model of process. product
• For Software Process Models I - Difference between prescriptive and actual processes - Current process models do not reflect:
learning. technical communic(ltion. requirements negotiation. and customer interaction - Framework for an "ideal" process model emerging
• For Further Empirical Research on Professional Software Engineering - Much more to do - Focus on "variation" and its effect on the difference in productivity and quality outcomes
among p~ple, situations, and their interaction
~Lockheed Missiles 8, Spa co Company, I~c. Sollwaro T ochnologv Canlor 1 t 765
.... .--. r-. - --.-
The Software Project as an Ecological System
Changing World
External Tec~nology
I
Contracting / Mechanisms
Industry and Company P&P, Standards, Etc.
I InteroalProcesses of Interest • Assimilation of knowledge • Communication and coordination • Managing change ' ·-Issue-resol~tion and decision making • Technical qesign • Organizational bureaucracy"
Application Knowledge
/
" Specific Needs of Customers
~Lockheed Missiles & Space Company, Inc. Sohwals T ochoology Coolor , '766
r--
..
Five Crucial Problem Areas in Large Software Projects·
I
ApplicaUqn Knqwledqe
• 500 STP·a90·8~p
Context Change & Uncertainty
Communication and Coordination
Design Evolution and Analysis
Technology Transfer
~Lockheed Missiles & Space Company, Inc. SOIiWollQ T ochnology ConlOI 11767
1- •
Overall Conclusion
The Greatest Leverage Is in Sup~ortinfJ the Intersection of:
The Technical Task
• Assessing customer neeqs • Assimilating application knowledge • Negotiating requirements, technology, and resources • Identifying and exploring oesign assumptions/alternatives • Decomposing and recomposing functionality • Defining and_controlling component interfaces
The ManagementTask
• Strate'gically managing system features and attributes • Assessing and controlling risks ' • Ensuring developer'swcyrk fronl the same models
/
~Lockheed Missiles & Space Company, Inc. Sollwaro TochnulQ(JY Con!or , '768
~ I
Results of the "~IFT" Study
• Observations on relative effort distribution
• Observations _ abQ!JUnQlvidual differences
• Identification of six process b~eakdowns " ,
I • A cognitive model of desi~n problem solving
~Lockheed Missiles & Space Company, Inc. Soli war. Technology Center 11769
~ .~ -
•
_ ..
Problem Models
/
Information Model of Design Exploration
/ /
/.-----. I comniitmenfs -1--I~~su~ptions' , scenarios
of use
test cases
simulations
trade-off analysis
I
"" "-
Issues , '
I constraints
evaluation criteria
discarded alternatives
Solution Models
~Lockheed .U/sslles & Space Company, Inc. Sollwa/o TochnolO{)v Coulor 11770
I
i
S
/
...
Indiv~dual Differences in Software Design Strategies
Domain-Specific Strategies
Exemplar (Jrive'n \ Experienced
Method (process) driven \ Intermediate
_._----
Computational par~digm driven
Trial and error driven
General computation strategies
"
Beginner
~Lockheed Missiles & Space Company, Inc. Sollwilro Tochnolouy Conlor ,1771
~
a
.,
I
•
Results of the Team ~esign Study·
• Identification of conflict behavior as key to achieving shared models
• Observations on the limitations of "documents"
• Observation of ombudsman to facilitate communication between custom~r and design teams ..
• Observations on the effect of midnight prototype creation
• Vic;feotape identified as history capture mechanism ~-.-- -._---
'.
• being (:ompleled at U.T •• D. Walz, 1988
~Lockheed Missiles & Space Company, Il1c. Software Technology Center 11772
~
"
-..
\,
Future SSEs Should Qontain Facilities For
';-1) Focus on Productivity and Quality
- Statistical ac - Reduce waste and redundancy -Institutionalized reuse process yields component parts (via standards)
2) Process Engineering - Introduction of good prac~ices, tools, etc. - Process definition, tailoring, monitoring, analysis, and improvement - Embodimept in education programs
3) Prpcess Efficiency through Teamwork and Communication - Revocation of Brook's Law - High performance teamwork - "Groupware"
4) Flexible Organization Evolution - Coordinated technology, policy and org~nizational structure
around process management concerns , - Commlltment to improve (facilitation of change) - Capture of corporate domain knowledge (via issue-oriented domain analysis) - Negotiation-based requirements technology --
5) L1veware Support' / - Variety of "experts" (stakeholders)
- Significant variation in abilities
~Lockheed Missiles & Space Company, Inc. SoH wale Technology Center .,,773
,
l .
i
I.
,
PUBLICATIONS
Field Study Papers
Curtis, B., Krasner,. H., and Iscoe, N. (1988), A Field Study of the Software Design Process for Large Systems, in Communications of the ACM, Vol. 31, No. 11. November, 1988
Krasner, H., Curtis. B. and Iscoe, N. (1987) Communications Breakdowns and Boundary Spanning Activites on Large Software Projects, In Proceedings of the Second Annual Conference on Empirical Studies of Programmers, Chapter 4. Ablex. Inc .• Norwood. NJ. .
Curtis. B., Krasner •. H., Shen. V. and Iscoe. N. (1987), On Building Process Models Under the Lamppost.ln the Proceedings of the Ninth International Conference on Software Engineering. Washington. DC: IEEE Computer Society, 1987,96-103.
Krasner, H .• Shen, V .• Curtis. B. and Iscoe. N. (1986) Preliminary Observations from the MCC Field Study of Large Software Projects, MCC Technical Report Number STP-390-86P.
Shen. V .• Krasner. H .• Curtis. B. (1986) A Field Study Plan for Developing Models of the Design Process. MCC Teclmical Report Number STP-llS-86P.
Team Study Papers
Elam, J., Walz, D., Krasner, H., Curtis. B. (1987). A Methodolbgy for Studying Software Design Teams: An Investigation of Conflict BehaviorS in the Requirement~ Defmition Phase,In Proceedings oCthe Second Annual Workshop (;)0 Empirical Studies-of-Programmers;Chapter6. Able,x.lnc .• Norwoood, NJ.
Walz, D. (1988). Phd Dissertation. U. of Texas. to appear
Individual Study Papers
Guindon. R-. Krasner. H..-Curtis. B. (1987) Breakdowns and Processes During the Early Activities of Software Design by Professionals. In Proceedings of the SeconJ Annual Workshop on Empirical Studies of Programmers. Clapter 5. Ablex, Inc .• Norwoood. NJ.
Guindon, R-. Krasner. H •• Curtis. B.(l987b) A Model of Cognitive Processes in Software Design: An Analysis of Breakdowns in Early Design Activities by Individuals. MCC Technical Report Number STP-283-87. '-
iii
. __ . J
Motivational Slide for this Morning /
-.~-.--
In a study of 38 U.S. and Japanese Companies a wide variety of software management strategies were observed (Cusumano, 1987). It Was concluded that Japanese firms are significantly ahead in applying a disciplined and flexible factory approach, as evidenced by:
Japan
u.s.
.26 bugs 1000 SLOC
8.3 bugs 1000 SLOC
5% projects late
43% projects late
340/0 reuse
15% reuse
~Lockheed Missiles & Space Company, Inc. Sollwalo Tvct)nology.conl., t, 790
~
r,...
, I .
• _ •. f. ,__ ~
I !
THE ROLE OF SOFTWARE ENGINEERING . ,
IN THE S;'ACE STATION PROGRAM
RICIS SYMPOSIUM 1988 INTEGRATED COMPUT,NG ENVIRONMENTS
FO~ LAR~E, COMPLEX SYSTEMS
NOVEMBER 9-10, 1988 \\l Z ", (Q t.-\ ~ t-'~
I \J' I ~
~ ~-~~ /"'/ --.......c,o.
--~.---,-
DANA HALL SPACE STATION PROGRAM OFFIC~ ~ : RESTON, VIRGINIA CO I
I
r -
, .,
SNAPSHOIS OF SOFTWARE ENGINEERING APPLICATIONS WITHIN THE
. ,
SPACE STATION FREEDOM PROGRAM '
INTEGRATED INTERN~ TIONAl DEVELOPMENT ENVIRONMENT
INTEGRATED Sll,tUlATION
ENVIRONMENT
HIERARqHIAL FLIGHT/GROUND COMMAND AND
CONTROL
--._--._--
SOFTWARE ENGINEERING
AND Ada TRAINING
SOFTWARE REUSE
l -
~ .-
j
of
., -
SOFTWARE ENGINEERING AND ADA TRAINING
o SOFTECH (RICIS) 1987 SURVEY OF NASA:
• OVER 150 ADA PROJECTS WITHIN 5 YEARS • MINIMAL EXPERIENC-=O PERSONNEL • MUCH SOFTWARE ENGINEERING AND ADA TRAINING
NEEDED • . FEW WRITTEN SOFTWARE DEVELOPMENT POLICIES
o TRAINING RECEIVING MUCH MORE ATTENTION (but its still too little and ..... maybe too late)
EXAMPLES:
• EXPANDED COMPUTER·BASED AND CLASS ROOM TRAINING FROM SSE
• TOP MANAGEMENT ATTENTION
. \ .'
~
SOFTWARE REUSE
o WANT TO CAPITALIZE ON RESEARCH AND EXPERIENCE TO DATE
• EXAMPLES: 0 ARMY 'RAPID' TOOL FOR LIBRARY MANAGEMENT
o UNIVERSITY TAXONOMYI ATTRIBUTES WORK
o POLICY WILL ENCOURAGE REUSE
• COMPONENT DEVELOPMENT • TRY DURING RAPID PROTOTYPING
o PIVOT POINTS
•
•
CONTRACTOR INCENTIVES ACCOUNTABILITY AND LIABILITY
! - ..
, ,. .... ~-... _ .......... p.- ................... ,~ .. - ......... , ,IC .................................. _. --_. •
HIERARCHIAL COMMAND AND CONTROL
ONIO Equipment
.,
JAPAN
'. ,
PROGRAM CHARACTERISTICS DISTRIBUTED SOFTWARE DEVELOPMENT & MAINTENANCE
'-
u.~ .. & CANADA
EUROPE
@WG:J .. _.)._ .... _- .,....
I J.:l~ft~11 L..:.LK!:'j/
".
The Software Integration Challenge
-- ~
INTEGRAtED, INTERNATIONAL ENVIRONMENTS (HOW MUCH IS NECESSARY FOR SPACE STATION FREEDOM PROGRAM?)
o ESA, NASDA, AND CANADA WILL PROVIDE MISSION/LIFE CRITICAL FLIGHT SOFTWARE
_ QUALITY OF PARTNER DEVELOPMENT ENVIRONMENTS UNKNOWN AND UNCONTROI-LED
_ LIMITED EXPERIENCE IN MAN-RATED. COMPLEX SOFTWARE
o HOW COMMON OR INTEROPERABLE MUST BE THE DEVELOPMENT ENViRONMENTS? •.•• AND HOW DO WE ANSWER THAT QUESTION?
• WRITE TIGHT INTERFACE SPECS? --4.~ HOW qAN WE DETERMINE NECESSARY
DATA EXCHANGES?
• PROVIDE THE SSE TO THE PARTNERS?
""O-"--4~. TECHNOLOGY TRANSFER (?)
• SHARE A CR'TICAL SUBSET?
. __ •• STANDARDS? TOOLS? ALL OR PART? ENVIRONMENTS ARE TIGHTLY INTEGRATED
THIS ISSUE MUS+ BE SETILED SOON I !_ c:: ..
- I
·- .~
(
SIW PROD.
fACILITIES {
OMS SYSTEM
SIW
\
\ \
SOFTWARE PRODUCTION, INTEGRATION, AND MANAGEMENT
PROP. APPl. SIW
GNC APPl. SIW
WP2
C&T APPl. SIW
TtlERMAl APPl. SIW
flUIDS APPl. SMI.
WPl
ECLS APPL. SIW
(+ INTERNAL PAYLOADS)
I I I I I I I I I I I
MUl TI·~YSTEMS I J;
INTEG~ATION fACILITY
,--------~--------~ : OTHER GROUND : TESTS :
• I
·--------l--------4 r---- __ .. _________ ~ FliGIH
I I I I I •••• ___ •••• _______ 4
WP4 I WP3
POWER I H5 APPl. ( + EXTERNAL SIW PA YlOADS)
..--
~
INTERNAT'l PAJ\TNERS
APPl. SIW
(DEPENDS ON IIF)
'- ~
~ii
~I ~~ -
~:
,
\ \
, ,
"
INTEGRATED SIMULATION ENVIRONMENT I , "
I I ~ Simulallon ConI.,. PIOg'lm ~
r-'
TORS FMS MSC Allached SIM StM SIM Payload
SIM
"\ I /
~ I L
88CC CIT CIT
~. ECLSS
81M SIM
EPS LAB LAB
~ EPS OMA OMA SI~ OMA SIM
TCS HAB HAS
TCS OMA ~ SIM OMA SIM
\ I
p~b'n ~ LOG GN.C LOG OMA
OMA SIM I
/ I I \.
JEM GN&C Propul.'n Columbus SIM SIM SIM SIM
I 1 1 c-- ~r·_all_' ~tr"-·· rr- .. , i· -/1"'--
--'--. --'-
--f-
"-
~
" .. '
,
CLEAN OMMUNICATIONS
SOFTWARE ENGINEERING
INCREASED PRODUCTIVITY
MORE RETURN
ON INVESTMENT
EFFICIENT SOFTWARE
DEVELOPMENT
COST· RELIABLE
I
EFFECTIVE SOFTWARE EVOLUTION
GOOD (but not
excessive) DOCUMENTATION
I
AND SAFE
SOFTWARE
SOFTWARE ENGINEERING IS THE KEY TO MAXIMIZING PROGRAM "PROFIT"
-
'. , ... :- ~ r- ,r--,-- r- r-:-
- -LESSONS LEARNED
. FROM AN
Ada CONVERSION PROJECT
Tim Perter
10 November 1988 , '
• -;~ SAle lXJMSt~7l:A6 . ~ ., w ........ -.''''', • .........
2: co· ... I •
q). ~ ~ ~ ~ ~ ~ ~ ~ CoO "
?~ ----- II
N
,
,-
--f3A(:K(;I{OUND
.'SOFfWARE AUTOMATED VERIFICATION AND VALIDATION SYSTEM (SA VV AS)
• bRIGINALL Y DEVELOPED - FOR VAX/VMS - USING DEC Ada
• PORTED FOR NASA SPACE STATION SSE - TO IBM3090/VM - USING ALSYS Ada
.... ' ......
\ ,
11-5AIC~ II An £~OtwNIdllM~o/
t-· c:'-- r::-:' I.
,,... •
, ..
- -13A(~K(; RO UNO
• SOFfWARE AUTOMATED VERIFICATION AND VALIDATION SYSTEM (SAVVAS)
• ORIGINALLY DEVELOPED - FQR VAX/VMS - USING DEC Ada
• POJ{TED FOR NASA SPACE STATION SSE - TO IBM30~O/VM - USING ALSYS Ada
1
• - SAlt: CXMIStSTEMS • M£~Ctlnplf1J'
L.II I L
\ ~ (
~ I
.~
i I
~ l
~~~ \ ,
.~ 1ij ~ ~ ~ ~.~ ~
..J
~ ~ §'-~
a:l : t
<:
·t~! ;:;:
i I . ~ ..
t ~ I ,
".....
~ ~ -~ v -"I,
-~ ! -~ :x
.~ ~ '" < ~
~~£~ ~
~ "", -~ ~ ~~
a
!
~
~ i'~ u~ ~~' l ~l
~J ~I~~ ~
I~
II .,11
•
.'
( .•
• •
- -/
I-lOW I)() WE IMPI{()VE PC)R·rABILI1~Y?
• STANDARD LANGUAGE - Ada
• ISOLATION OF NON-PORTABLE CODE
• CONSfRAINTS ON LANGUAGE FEATURES I
• VIRTUAL INfERFACES
II . - . SAle (XJCtS~~7rAIS -~/~",,,,,, ~,. ; .... "' . ·------11
• t . ,.......-.
f '-.-¥ •••• -~-- .... --... -----.
,I - r- r--
- -l-IIS'I'()I{Y OF ADA
1972 DoD recognizes rapid grcmth d satware oosts for military systems
1975 HOL WG reviews language'requirements
1979. Ada selected from 1 angli age design etforts
1983 Ada established as an ANSI standard
1985 lliD spends $11 tillioo on scitware
1987 Ada mandated by DoD directive 5034.2 NASA awards Space Statim SSE CDltrad
1988 STARS Canpeting Primes crntrads awarded
1995 DoD projected software spending is gver $25 til1ion
.-5AIC~ • M£~Jtw»d~",
•
•
'~-".'--'-~
,
- ! -
IS()IA'rl()N ()F N()N P()J{'I'AJ3LE (~()JJE
• CAPITALIZE ON Ada'S FEATURES
- PACKAGES'
• CLASSES OF DEPENDENT SOFfWARE
- INPUT/OUTPUT
- DATABASE ACCESS
- OPERATING SYSTEM SERVICES
• -M~~~1SIB6 •
~
(,
.- .-- r- r- r--
- -. SIMPLE'fERMINAL INTEI{FACE PACKAGE
package SIMPLE_TERMINAL_INTERFACE is .
prcad~re GO_TO_POSTIION_CX, Y: in INTEGER);
procedure DISPLAY_TEXT (MESSAGE: in STRING);
end SlMPLE_TERMINAL_INTERFACE;
wit~ TEXT _IQ use TEXT_IQ pack~ge lxxiy SIMPLE_TERMINAL_INTERFACE is
praEdure GO_TO_POSITION_ cx, Y: in INTEGER) is bL'gin
Send the app'(:p'iatc a:xJc scquenre to the tcnninal. TheiC arc different fa v~rying tcnninal types. .
end GO_TO_POSTJlON;
procedure DISPLAY_TEXT (tv!ESSAGE: tn STRING) is begin
.. Send the~getothetermlnal.
.. Indudtng any required axie·~ences.
end nISPI.AY_TEXT;
md SIMrJ.E_TERMINAI._INTERFACI~
.-SA/C~IS • AnE~(~",
i
--CONSTRAlN~rS OF LANGUAGE FEATURES
• TASKS
• PRAGMAS
• GENERICS
• EXCEPTION HANDLING
.-SAlC~- • "",~, ... ~, .. "."~
t··· r --. c-
.~
\ \ \
\
~
" ...
,', [,
r- r-
- -
II
V I Rrr lJAI ~ I Nl'ERf'ACES
• DATABASE ACCESS - Ada/SQL - MODULE APPROACH
• INPUT/OUTPUT -XWINDOW -Ada-GKS
• OPERATING SYSfEM --CAIS - PCfE - POSI>{
54/C (t.6"'~7lAIS ---------.. 0' .... , ...... \0,,,,, ••.•.• " ,
....... _.-..
,
·.--------------------~-----------~
I L
-·---------------11
-.... >-""" -~ ., -,~ -
r--.r--.~~-:c~ - .... -:"J N C"':
~-
.-, --. 7
" ". -' /. ...J<-
L
• • • • • • •
ORIGINAL PAGE IS OF POOR QUAUTY
~
u! ~l
l~ 11---------------11
I '-I "J ..
r . .' ... - _....... :-_.- .. _- .-- ,- r- r-
- -./
MC)IJI FI(~X]'I()NS 'I'() TI-IE PlAY BOOK
• CONSISTENT DESIGN METHODOLOGY.
• DESIGN AND CODING STANDARDS
• VIRTUAL INTERFACES '.
• COMPREHENSIVE Ada TRAINING
• - SAle fXJYSrSTEMS • Ant~(~CPnp.lny
\
top related