Cadena an integrated environment for developing high assurance component based systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 62

Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems PowerPoint PPT Presentation


  • 77 Views
  • Uploaded on
  • Presentation posted in: General

Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems. SAnToS Laboratory, Kansas State University, USA. http://www.cis.ksu.edu/cadena. Principal Investigators. Postdocs and Students. Radu Iosif Hongjun Zheng Corina Pasareanu Georg Jung. Robby

Download Presentation

Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Cadena an integrated environment for developing high assurance component based systems

Cadena:An Integrated Environment for Developing High-Assurance Component-based Systems

SAnToS Laboratory, Kansas State University, USA

http://www.cis.ksu.edu/cadena

Principal Investigators

Postdocs and Students

Radu Iosif

Hongjun Zheng

Corina Pasareanu

Georg Jung

Robby

Venkatesh Ranganath

Oksana Tkachuk

William Deng

Matt Dwyer

John Hatcliff

Support

US National Science Foundation (NSF)

US National Aeronautics and Space Agency (NASA)

US Department of Defense

Advanced Research Projects Agency (DARPA)

US Army Research Office (ARO)

Rockwell-Collins ATC

Honeywell Technology Center and NASA Langley

Sun Microsystems

Intel


Conclusions

Conclusions

  • Software is moving rapidly towards distributed, component-based systems

  • Since concurrent/distributed systems are difficult to reason about, we would like to apply model-checking, static-analyses, and other formal methods

  • To make this feasible, one needs multiple layers of abstraction (modern systems are huge!)

  • Interface Definition Languages (e.g., CORBA IDL) provide an excellent hook for attaching light-weight formal specifications

  • Model-checking modern software (heavily OO) requires using a tool like dSpin


Cadena an integrated environment for developing high assurance component based systems

Analysis & Verification of Fighter Aircraft Mission Control Systems

  • Mission-control software for Boeing military aircraft, e.g., F-18 E/F, Harrier, UCAV

  • Boeing’s Bold Stroke Avionics Middleware

    • CORBA event-based systems

  • Focus is developing a rigorous design process with formal design artifacts that can be automatically checked for common design flaws


Boeing bold stroke platform

Boeing Bold Stroke Platform

Focus Domain

Nav Sensors

Weapon

Management

Data Links

Weapons

Periodic & Aperiodic

Constrained Tactical Links

Many Computers

Mission

Computer

Multiple Safety Criticalities

Radar

Vehicle

Mgmt

COTS

Information Security

Multiple Buses

O(106) Lines of Code

Hard & Soft Real-Time


Software infrastructure

Software Infrastructure

  • Programmed using a component-based Real-Time CORBA framework

  • CORBA is middleware

    • rich infrastructure for building heterogeneous object-oriented distributed systems

  • Components communicate by

    • publishing/subscribing to events

    • making method calls on component interfaces

  • Loose coupling addresses a number of issues

    • easier to reuse components, distribution of resources on aircraft, easy to incorporate real-time aspects, easier to have disjoint groups of developers


Control push data pull

Control-Push Data-Pull

dataAvailable

getData()

dataAvailable

getData()

Configuration

Run-time Actions

Bisubscribe to a dataAvailable event published by A

A publishes a dataAvailable event

Biconnect to an interface of A that provides a getData() method

Bicall the getData() method of A to fetch the data

Typical situation

Component A computes some data that is to be read by one or more components Bi

B1

A

Bk


Control push data pull structure

Control-Push Data-Pull Structure

4

4

1. Logical GPS component receives a periodic event indicating that it should read the physical GPS device.

1

2. Logical GPS publishes DATA_AVAILABLE event

3. Airframe component fetches GPS data by calling GPS GetData method

2

4. Airframe updates its position data and publishes DATA_AVAILABLE event

3

6

5. NavDisplay component fetches AirFrame data by calling AirFrame GetData method

5

6. NavDisplay updates the physical display


Larger configuration

Larger Configuration

…moving up to 1000+ components


System requirements

System Requirements

Output Requirements

  • The system shall disable the display of steering information when deselected by the pilot.

  • When the navigation steering mode is selected, the system shall:

    • Update navigation steering information display outputs at 20Hz rate based on current airframe data and the current list of navigation points that have been submitted by the navigator. The latency between the GPS data inputs and the display output shall be less than a single 20 Hz frame. The latency between navigation point input and the associated output shall be less than a single 5 Hz frame.

  • When the tactical steering mode is selected, the system shall:

    • Update tactical steering information display outputs whenever the airframe position data changes.

  • The system shall display new aircraft position data at a 20 Hz rate. The latency between associated inputs and this output shall be less than a single 20 Hz frame.

Very idealized(!), but should give you the flavor

Input Requirements

  • The system shall request new inputs from the GPS subsystem at a 40 Hz rate.

  • The system shall poll for a pilot steering mode input at a 1 Hz rate.

  • The system shall receive data from the navigator controls at a 5 Hz rate.


System design aspects

System Design Aspects

Outputs required @ different rates

Inputs triggered @ different rates

Intermediate components correlate incoming data and produce higher-level info

Sensor1

60Hz

20Hz

Display

Sensor1

AirFrame

1Hz

1Hz

Mode Switch

Control

20Hz

Sensor1

20Hz

Display

5Hz

Sensor1

Implement mode semantics for changing subsystem behavior

Map components to onboard network nodes

Declare rates/priorities for intermediate event handlers

Off


Development process

Development Process

Component Integration

Platform-specific

Components

Common Components

Connect components, assign priorities, locking schemes, distribute

Real Board Testing

Analysis & Functional Testing

Test real-time aspects, frame-overruns, etc.

Debuggers, call-graph analyzers, scheduling tools

Component Development


Current challenges

Current Challenges

  • Systems with 1000+ components

  • Development team of 100+ developers

  • Process moves directly from informal textual requirements documents to C++ coding (!)

  • UML artifacts (e.g., collaboration diagrams) are usually produced only as documentation

    • not automatically analyzed

    • not leveraged in any way to e.g., generate configuration information

    • usually show partial descriptions and are not maintained

  • Still resistance by “legacy developers” to higher-level descriptions

    • moving away from machine code has been difficult for some developers


Research context

Research Context

  • Provided with an Open Experimental Platform (OEP) from Boeing

    • a sanitized version of the real system

    • 100,000+ lines of C++ code (including RT CORBA middleware)

  • Provided with 150+ page document that outline development process and describe challenge problems

  • Must provide tool-based solutions that can be applied by Boeing research team realistic systems

  • Must propose solutions that fit within current development process

  • Must propose metrics for tool performance and ease of use

    • evaluation by Boeing research team

  • Must make significant progress in one year with regular evaluation milestones


Cadena an integrated environment for developing high assurance component based systems

Next…

Short-comings in Bold Stroke development that we will attempt to address


Lack of modeling

Lack of Modeling

C++ component library

development

Informal natural language requirements

<CONFIGURATION_PASS>

<HOME> <…>

<COMPONENT>

<ID> <…></ID>

<EVENT_SUPPLIER>

<…events this component supplies…>

</EVENT_SUPPLIER>

</COMPONENT>

</HOME>

</CONFIGURATION_PASS>

XML configurator information

  • Current development includes little high-level modeling

  • Design errors appear late in development cycle and correction is more costly

    • what are the ramifications of switching from lazy-active to eager-active components?

    • what are the ramifications of distributing components to different boards?


Unleveraged artifacts

Unleveraged Artifacts

  • Current design/model artifacts are used as informal documentation

    • not connected to analysis/visualization tools

    • not connected to configuration generation

    • not connected to code generation


Lack of model analysis

Lack of Model Analysis

4. All components from a particular rate group

5. Cycle checks

…15-20 others related to dependencies

Boeing OEP Challenge Problems

1. Forward & backward data and event dependencies

2. Dependency intersections

3. Components with high data coupling

…also mode-aware dependences


Lack of model analysis1

Lack of Model Analysis

Boeing OEP Challenge Problems

If component 1 is in mode A when component 2 produces event E, then component 3 will consume event F

(Section 4.1.5.3.6)

A temporal property!


No unifying mechanism

No Unifying Mechanism

?

C++ Component Code

UML Design Artifacts

<CONFIGURATION_PASS>

<HOME> <…>

<COMPONENT>

<ID> <…></ID>

<EVENT_SUPPLIER>

<…events this component supplies…>

</EVENT_SUPPLIER>

</COMPONENT>

</HOME>

</CONFIGURATION_PASS>

High-level Specification Language

Bold Stroke XML Configurator Info

Integrated Development Environment

Analysis and QoS

Aspect Synthesis


Cadena

Cadena

Cadena

CCM Interface Definition Language

Java/C++ Component Code

TAO Extensions

UML Design Artifacts

State Transitions

System Configuration

<CONFIGURATION_PASS>

<HOME> <…>

<COMPONENT>

<ID> <…></ID>

<EVENT_SUPPLIER>

<…events this component supplies…>

</EVENT_SUPPLIER>

</COMPONENT>

</HOME>

</CONFIGURATION_PASS>

High-level Specification Language

Eclipse Plug-In

Bold Stroke XML Configurator Info

Integrated Development Environment

Analysis and QoS

Aspect Synthesis


Example system

Example System


Component ports

Component Ports

event sink

CORBA 3

CCM IDL

eventtype TimeOut {}

eventtype DataAvailable {}

interface ReadData {

readonly attribute any data;

}

component BMDevice {

consumes TimeOut timeout

publishes DataAvailable dataCurrent

provides ReadData dataOut

}


Component ports1

Component Ports

CORBA 3

CCM IDL

eventtype TimeOut {}

eventtype DataAvailable {}

interface ReadData {

readonly attribute any data;

}

component BMDevice {

consumes TimeOut timeout

publishes DataAvailable dataCurrent

provides ReadData dataOut

}

event source


Component ports2

Component Ports

CORBA 3

CCM IDL

eventtype TimeOut {}

eventtype DataAvailable {}

interface ReadData {

readonly attribute any data;

}

component BMDevice {

consumes TimeOut timeout

publishes DataAvailable dataCurrent

provides ReadData dataOut

}

data source

(facet)


Component code generation

Component Code Generation

Using CCM IDL Compiler

Completely auto-generated code templates + component logic

component BMModal {

consumes DataAvailable dataInReady;

uses ReadData dataIn;

publishes DataAvailable dataOutReady;

provides ReadData dataOut;

provides Toggle switch;

}

User only fills in body of methods for event-handlers, interfaces

Currently in Bold Stroke

8-12 classes drawn by hand in Rational Rose, then code templates generated from this (component structure must be re-specified each time).

=

Push()

GetData()

tacticalSteering :

BM__ModalComponent

Push()

GetData()


Cadena component assembly

Cadena Component Assembly

abstract distribution nodes

system ModalSP {

locations l1,l2,l3;

rates 1,5,20,60;

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

instance GPS

of BMDevice on l2 {

connect timeout

to EventChannel.timeout20

}


Cadena component assembly1

Cadena Component Assembly

system ModalSP {

locations l1,l2,l3;

rates 1,5,20,60;

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

instance GPS

of BMDevice on l2 {

connect timeout

to EventChannel.timeout20

}

rate group declaration


Cadena component assembly2

Cadena Component Assembly

system ModalSP {

locations l1,l2,l3;

rates 1,5,20,60;

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

instance GPS

of BMDevice on l2 {

connect timeout

to EventChannel.timeout20

}

create instance of LazyActive component called AirFrame


Cadena component assembly3

Cadena Component Assembly

connect event INPUT port of current component to event OUTPUT port of GPS component

system ModalSP {

locations l1,l2,l3;

rates 1,5,20,60;

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

instance GPS

of BMDevice on l2 {

connect timeout

to EventChannel.timeout20

}


Cadena component assembly4

Cadena Component Assembly

connect data INPUT port of current component to data OUTPUT port of GPS component

system ModalSP {

locations l1,l2,l3;

rates 1,5,20,60;

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

instance GPS

of BMDevice on l2 {

connect timeout

to EventChannel.timeout20

}


Cadena component assembly5

Cadena Component Assembly

system ModalSP {

locations l1,l2,l3;

rates 1,5,20,60;

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

instance GPS

of BMDevice on l2 {

connect timeout

to EventChannel.timeout20

}

create instance of DeviceComponent called GPS


Cadena component assembly6

Cadena Component Assembly

system ModalSP {

locations l1,l2,l3;

rates 1,5,20,60;

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

instance GPS

of BMDevice on l2 {

connect timeout

to EventChannel.timeout20

}

connect event INPUT port of current component to event OUTPUT port of EventChannel


Cadena component assembly7

Cadena Component Assembly


Cadena visualization

Cadena Visualization


Glue code generation

Glue Code Generation

Cadena “Glue Code” Generation

Glue Code

Execution gives allocation and deployment of component instances and connections(complete system)

Current Boeing Glue Code Generation

<CONFIGURATION_PASS>

<HOME> <…>

<COMPONENT>

<ID> <…></ID>

<EVENT_SUPPLIER>

<…events this component supplies…>

</EVENT_SUPPLIER>

</COMPONENT>

</HOME>

</CONFIGURATION_PASS>

Bold Stroke XML Configurator Info

Glue Code


Code generation summary

Code Generation Summary

component BMModal {

consumes DataAvailable dataInReady;

uses ReadData dataIn;

publishes DataAvailable dataOutReady;

provides ReadData dataOut;

provides Toggle switch;

}

component BMModal {

consumes DataAvailable dataInReady;

uses ReadData dataIn;

publishes DataAvailable dataOutReady;

provides ReadData dataOut;

provides Toggle switch;

}

component BMModal {

consumes DataAvailable dataInReady;

uses ReadData dataIn;

publishes DataAvailable dataOutReady;

provides ReadData dataOut;

provides Toggle switch;

}

“Glue Code” Generation

Glue Code

Execution gives allocation and deployment of component instances and connections(complete system)

Component Code Generation

BM.Device

BM.LazyActive

BM.Modal


Assessment

Assessment

  • We’ve done a lot of work already and none of it has to do with model-checking.

    • Tool building + reading CCM spec (1000+ pages!)

  • But…

    • Boeing developers now have high-level artifacts that definitely want to use (a substantial benefit)

    • We can now try to “sneak in” formal methods attached to these high-level artifacts

      • add behavioral annotations to high-level artifacts

      • modify code generation process to generate “cookie-crumbs” in the code that can be recognized by formal-methods tools to, e.g., help check refinement.


Ultimate modeling view

Ultimate Modeling View

Code Layer

Check that implementations satisfy/refinement high-level specs – leverage the fact that code skeletons are automatically generated

CCM IDL

Model

Layer

Check mode behaviors, temporal properties, timing constraints

Generate code, fill-in skeletons, check for refinement


Component behavior

Component Behavior

input ports

component BMModal {

uses ReadData dataIn;

consumes DataAvailable inDataAvailable;

publishes DataAvailable outDataAvailable;

provides ReadData dataOut;

provides ChangeMode modeChange;

enum Modes {enabled,disabled};

Modes m;

behavior {

handles dataInReady (DataAvailable e) {

case m of

enabled {

dataOut::data <- dataIn.getData();

push {} dataOutReady;

}

disabled {}

}


Component behavior1

Component Behavior

component BMModal {

uses ReadData dataIn;

consumes DataAvailable inDataAvailable;

publishes DataAvailable outDataAvailable;

provides ReadData dataOut;

provides ChangeMode modeChange;

enum Modes (enabled,disabled);

Modes m;

behavior {

handles dataInReady (DataAvailable e) {

case m of

enabled {

dataOut::data <- dataIn.getData();

push {} dataOutReady;

}

disabled {}

}

output ports


Component behavior2

Component Behavior

component BMModal {

uses ReadData dataIn;

consumes DataAvailable inDataAvailable;

publishes DataAvailable outDataAvailable;

provides ReadData dataOut;

provides ChangeMode modeChange;

enum Modes (enabled,disabled);

Modes m;

behavior {

handles dataInReady (DataAvailable e) {

case m of

enabled {

dataOut::data <- dataIn.getData();

push {} dataOutReady;

}

disabled {}

}

mode declaration using CORBA IDL


Component behavior3

Component Behavior

component BMModal {

uses ReadData dataIn;

consumes DataAvailable inDataAvailable;

publishes DataAvailable outDataAvailable;

provides ReadData dataOut;

provides ChangeMode modeChange;

enum Modes (enabled,disabled);

Modes m;

behavior {

handles dataInReady (DataAvailable e) {

case m of

enabled {

dataOut::data <- dataIn.getData();

push {} dataOutReady;

}

disabled {}

}

behavior for events on dataInReady port


Component behavior4

Component Behavior

component BMModal {

uses ReadData dataIn;

consumes DataAvailable inDataAvailable;

publishes DataAvailable outDataAvailable;

provides ReadData dataOut;

provides ChangeMode modeChange;

enum Modes (enabled,disabled);

Modes m;

behavior {

handles dataInReady (DataAvailable e) {

case m of

enabled {

dataOut::data <- dataIn.getData();

push {} dataOutReady;

}

disabled {}

}

behavior mode cases


Component behavior5

Component Behavior

component BMModal {

uses ReadData dataIn;

consumes DataAvailable inDataAvailable;

publishes DataAvailable outDataAvailable;

provides ReadData dataOut;

provides ChangeMode modeChange;

enum Modes (enabled,disabled);

Modes m;

behavior {

handles dataInReady (DataAvailable e) {

case m of

enabled {

dataOut::data <- dataIn.getData();

push {} dataOutReady;

}

disabled {}

}

data flow specification


Component behavior6

Component Behavior

component BMModal {

uses ReadData dataIn;

consumes DataAvailable inDataAvailable;

publishes DataAvailable outDataAvailable;

provides ReadData dataOut;

provides ChangeMode modeChange;

enum Modes (enabled,disabled);

Modes m;

behavior {

handles dataInReady (DataAvailable e) {

case m of

enabled {

dataOut::data <- dataIn.getData();

push {} dataOutReady;

}

disabled {}

}

publish event


Assessment1

Assessment

  • CCM IDL, connection information, and behavioral specification are enough to

    • generate precise mode-aware dependence information

    • generate models suitable for model-checking model-behavior

  • Seems natural to some one in the model-checking community

  • Boeing team thought writing behavior specs would be too much effort(!)


Light weight dependency specs

Light-weight Dependency Specs

triggers no other actions

in enabled mode, shows actions triggered by dataIn.get_data()

in disabled mode, inDataAvailable triggers no other port actions

dependencydefault == all;

dependencies {

modeChange() ->;

case modeChange.modeVar of {

enabled: inDataAvailable

-> dataIn.get_data(),

outDataAvailable;

disabled: inDataAvailable ->;

}

}

behavior { ... }


Cadena an integrated environment for developing high assurance component based systems

Next…

Now, on to modeling…


Corba overview

CORBA Overview

CORBA

middleware

Proxies and middleware take of marshalling & unmarshalling of data and moving data across communication links

Interface specification for called methods

(written in IDL)

Java Proxies

C++

Proxies

C

Proxies

C#

Proxies

Interface Definition Language

Functionality

Distributed, heterogeneous systems

C++

Java

C#

C


Event channel

Event Channel

A lot going on behind the scenes…

implements event correlation

maintains a list of consumers

GPS(event supplier)

AirFrame(event consumer)

Proxy Supplier

Proxy Consumer

Event Channel

Automatically generated


System model

System Model

Component models

(common component models stay same, application-dependent ones are generated for each application)

Event ChannelModel(same for every system)

Event Connections

(different for each system)


Event channel1

Event Channel

internal structure of event channel


Dspin modeling of components

DSpin Modeling of Components

Function references allow to easily plug in references representing component connections

Structure follows component behavior spec and connection representation closely

any NavSteering_internalData;

mode NavSteering_componentState;

ftype Ref_NavSteering_dataIn1_getData,

Ref_NavSteering_dataIn2_getData;

ftype Ref_NavSteering_update;

function Fun_NavSteering_source1 (mtype t) {

printf("NavSteering: source1 handler invoked.\n");

if

:: NavSteering_componentState == enabled ->

NavSteering_internalData =

Ref_NavSteering_dataIn1_getData ();

printf("NavSteering: publishing update.\n");

Ref_NavSteering_update (NavSteering_DataAvailable)

:: else

fi

}


Dspin modeling of connections

DSpin Modeling of Connections

instance AirFrame

of BMLazyActive on l2 {

connect dataAvailable

to GPS.dataCurrent

atRate 20

connect dataIn

to GPS.dataOut

Modeled very directly in DSpin

Ref_GPS_dataCurrent = Proxy_GPS_dataCurrent;

GPS_dataCurrent_NumberSubscribers = 1;

GPS_dataCurrent_SubscriberList = new functionField[1];

GPS_dataCurrent_SubscriberList[0].Entry

= Fun_AirFrame_dataAvailable;


Functional properties

Functional Properties

Property I:

System never reaches a state where

TacticalSteering and NavSteering are both disabled

Property II:

If navSteering is enabled when 20Hz timeout occurs, then airFrame should fetch navSteering data [before end of frame]


Temporal property specs

Temporal Property Specs

Trigger event

Required event

…with condition

“Monitoring” automaton


Assessment2

Assessment

  • Custom-built (reusable model of event channel)

    • This is a general approach that we are taking to modeling middle-ware

    • Component models are automatically generated for each application

  • System generated tons of infeasible interleavings (priorities/scheduling not taken into account)

    • took all night to check for deadlock

    • 20million+ states

  • Enhanced model to include a notion of priority

    • transitions have explicit guards to check for current priority setting

    • down to 1 million states and finished in a few minutes


Assessment3

Assessment

  • DSpin models functions and pointers with very little overhead compared to Spin

    • we had an inlined version and the performance was worse

    • in general, DSpin’s heap representation incurs little overhead

    • note: garbage collection not required in this application


Assessment4

Assessment

  • Encoding explicit scheduling dramatically reduced the number of states

    • BIR model-checker will allow different scheduling mechanisms to be encoded

  • Encoding of time-aspects is primitive, but allows checking of interesting functional properties

  • We are exploring how real-time capabilities can incorporated into BIR checker


Assessment5

Assessment

  • Why might this technique scale for this application?

    • Even though the number of components will grow dramatically, there are few threads in thread pool (one per rate group – 4 max)

  • We are now experimenting with larger scenarios


Conclusions again

Conclusions (again!)

  • We have spent extra effort on non-model-checking aspects to develop a framework where we believe that a variety of formal methods can be applied effectively

    • model-checking, static-analysis, refinement between specs & code, SAT-solving to check first-order logic predicates constraining component connections

    • Cadena allows (eventually) end-to-end development of high-assurance CCM distributed systems

  • We are leveraging a high-level specification format (CCM IDL)

    • light-weight formal specs can be attached

    • CCM IDL compilation process can be tweaked to insert “markers” to aid in checking conformance of code to specs

  • Modern software architectures need facilities for functions, pointers, GC, etc. and these can be incorporated directly into conventional explicit-state model-checking engines


Cadena capabilities

Cadena Capabilities

  • High-level specification of system control

    • given basic data dependencies, how is control structured to move data from producers to consumers

  • Multiple ways to leverage modeling information

    • visualization, dependency analysis, model-checking, component skeleton generation, configuration code generation

  • Incremental capabilities within an IDE

    • ability to leverage and reason about incomplete specs

    • tools designed to support incremental, iterative construction

  • System modes and modal behavior

    • move to more high-level specs instead of having mode implementation distributed to individual components

http://www.cis.ksu.edu/santos/cadena


  • Login