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.ur­lJIi.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 sys­tem,

• 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 dead­lines) for their completion, which are part of the correct­ness 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 urgen­cy (time criticality)

• The perfonnance of the system, and of its as, must be opti­mized 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 single­and 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 integrat­ed 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 peri­ods for which there -is no single robustness approach: from hours to decades

• limited or no repairs may be possible during the mis­SIon

• the system usually has to remain -in .non-stop service during recovery from faults

• extreme safety concerns: system failure; may jeopar­dize 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 comput­ing 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 require­ments

• There are many widely divergent real-time SIC applica­tions, and the high costs of developing their computing sys­tems 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 inte­grated, 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 application­specified 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 consis­tency of data and correcmess of actions, despite asyn­chronousreal concurrency (and multiple- independent hard-

• ware faults) - to accomplish this requires (at -the kernel­level, because the as must itself be distributed)

,

• real-time transaction mechanisms for atomicity, -appli­cation-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: concurren­cy control objects; resource tracking; thread mainte­nance; abort blocks; l real-·ime transaction mecha­nisms (atomicity, concurrency control, ~ermanence)

• high availability of services and data: object replica­tion; dynamic reconfiguration of objects

• The- survivability features are presented through the pro­gramming model as a set of mechanisms which can be selected and combined as desired - their cost is propor­tional 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 pos­sible range of application-specific policies to meet par­ticular functionality, perfonnance, and cost objectives

• provide these mechanisms at the optimal level of func­tionality - 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 toler­ate variability in loading, timing, etc .

. • _ ... ~ __ ,.,.€5

"'

Concunent a Alpha Program Management Overview

• Alpha originated at CMU-CSD as part of the Archons Pro­ject on real-time distributed computer architectures and operating systems-Doug Jensen was the Principal Investi­gator

• As part of a long-continuing ''Think-Do'' cycle, new con­cepts and techniques were created, based on the PI's 15 years of industrial R&D experience with real-time comput­er systems,

then many of these were embodied in a feasibility test vehi­cle: the Alpha real-time decentralized as

• The Alpha prototype ("Release 1")

• lead by Duane Northcutt, with a team of five program­mers 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' ~ '" ::.\

,

I -tn -u -II:

Q Z :)

o II: CJ ~ o c( m

t

l !8 el) --

( S~ l 'C

I \ l

- t -

~ l

" Z -a: w w z -" ::i!: IJLI

.~ W o Z· -W· -o en

. . ~ 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 pro­grammer" 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 ori­ented 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 decision­making 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

ORtG.1iAl PAGE: IS OF POO9t QUAlITY

i ~ . .. I ..

I ,

.,

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

\

---_. -- -----

End of Document