T. Margaria STRESS ‘06 – 24.5.2006 Tiziana Margaria Chair of Service and Software Engineering Universität Potsdam Service Engineering Service Engineering

T. Margaria STRESS ‘06 – 24.5.2006

Tiziana Margaria

Chair of Service and Software EngineeringUniversität Potsdam

Service EngineeringService Engineering- between Software and Business -



OverviewOverview

• A motivating scenario

• How does it work

• The roots

• Web services (Example)

– The Tool Provider view

– The Tool User view

• Status and perspectives


Elementary Services

CoordinationCoordination

Presentation

Components

Coordinating Heterogeneous EntitiesCoordinating Heterogeneous Entities

Demo this afternoonDemo this afternoon


Aggressive Model Driven DesignAggressive Model Driven Design

M1

C1 Cn

Mn MnM1

Running System Running System

Compilation/Synthesis

Synthesis/Technology Mapping

Model Library

Component Library

Global Model

Integration Integration

Integration asConsistency/Compatibility

AMDDComponent Based Design

…

…

…


Aggressive Model Driven DesignAggressive Model Driven Design

Systems on a Chip

a board a chip


ABC: Library-based, ABC: Library-based, Actor-oriented Modelling & Design Actor-oriented Modelling & Design

SIB1

Macro 1

SIBnFLGnFLG1

Running System

Feature Library

Global SLG

uses .. …

Component Model Library

.. Macro n

Temporal Constraintsand Types

Service Logic Graphs = System ModelsService Logic Graphs = System Models

Temporal Formulas = Property SpecificationsTemporal Formulas = Property Specifications

Service Independent Building Blocks = ActorsService Independent Building Blocks = Actors

Actor Orientation• model checking composition of

behaviors• separation of behav. interface

from implementation

Actor Orientation• model checking composition of

behaviors• separation of behav. interface

from implementation


Layered Architecture Layered Architecture of jABC Applicationsof jABC Applications

Application

Services

Components

Business Objects

Persistency

Presentation

Agents

Features

Classes

User CentricLayers

System CentricLayers

Coordination

SIBs,SLGs,Macros


Challenge: Inconsistent NeedsChallenge: Inconsistent Needs

Scenario:

complex, distributed, and interdependent service provision

Central issue: user-level flow of control

• Flexibility: complete online reconfigurability of features, a whole service, and of role definition

• Scalability: manage many such services on the same ASP cluster and use remote services

• Telecommunication-level quality of service, (availability and reliability)


Concept - Coarse Granular LevelConcept - Coarse Granular Level

• combine basic functionalities• by means of a graphical notation• according to the control flow

Device-A-hook-up

Correct-Signal-In-Application?

passed failed


Link to UML-based Design-ToolsLink to UML-based Design-Tools

• SLGs sequence and activity diagrams


Tiziana Margaria


Martin Karusseit

Chair of Programming SystemsUniversität Dortmund

How to Engineer a Complex ApplicationHow to Engineer a Complex ApplicationHow to Engineer a Complex ApplicationHow to Engineer a Complex Application


Report

Report

PC MembersPC Members

PC ChairPC Chair

ReviewersReviewers

AuthorsAuthors

Articles

Final Report

Report Task

Report Task

AMDD for Design:AMDD for Design:

The Online Conference Service


Roles

Top level Features

Subfeatures


Hierarchical DesignHierarchical Design

Main Functionalities

Create NewsgroupSLG

SIBs

SLGs


Create Newsgroup

SIBs…

The SIB ModelThe SIB Model

<<Name>><<Category>><<Formal Parameter>><<Branches>> <<Executable Code>>

SIBSIB

CVSCreateConnection SIB Specification


SLG of the Application

SkeletonService

Features

…

Global Global LogicLogicPlanePlane

OnlineOnlineConferenceConferenceService:Service: >2800 SIBs>4000 branches


Feature Feature

• piece of (optional) functionality on top of a base system.

• (monotonic) • may consider or require other features• defined from an external point of view

(e.g. users and/or providers of services)• granularity determined by marketing or

provisioning


„Article“ Feature SLG

Sub-Features

…

Feature LogicFeature Logic

Submit Article


Feature-oriented Description Feature-oriented Description

• behaviours of a base system and a set of optional features

• as Service Logic Graphs (SLGs)

• library of reusable components:

Service Independent Building-Blocks (SIBs).

• set of abstract requirements for the intended purposes

• Interactions are expressed via constraints.

• Any feature composition is allowed that does not violate the

constraints.


Main Features Sub-Features Article Bidding Delegation Report Tasklist

Article

SubstituteSubmitArticle

SubstituteSubmitArticle

ModifyArticle

SubmitFinalArticleVersion

SubmitArticle

ReadDownloadArticle x

DelegateArticle x

Reportlist x

SubmitReport x

SubmitFinalReport

ModifyFinalReport x

AcceptRejectReviewTask x

RemoveArticle

SendMailtoAuthor

ShowAbstracts

OCS Feature Reusal (excerpt)OCS Feature Reusal (excerpt)

Reusal at the application level!


Design ValidationDesign Validation

– Local constraints

– Global constraints


Model Checking Service Logic GraphsModel Checking Service Logic Graphs

Structures: Logic:

Control view of Service Logic Graphs,

i.e.:• SIBs as states• Edges as transitions• SIB names as observations

(automaton alphabet)• SIB parameters as additional

observations

Full mu-calculus• universal and existential

specifications• forward and backward

modalities• first order extensions

referencing SIB parameters


The Model: DFAThe Model: DFA

• defined as a quadruple (S, Act, , s0 ) set of building blocks S set of possible branching conditions Act a set of transitions S Act S initial block s0

• visualised as a graph

• constitute basis for design of (web) applications

• constitute basis for checking consistency


Global constraints:Global constraints:

• formulated as SLTL formulas

A: atomic propositions over Sc: propositional logical formula over Act

• interpreted over set of all possible sequences

UG |)(||||:: cA


What do we check?What do we check?

• Role Management feature:

– A user can modify the defined roles only after having successfully registered as Administrator

~(‘ModifyRoles) unless ‘UserLogin [Role=Admin]

• ForgottenPwd feature:

– once the form for the private question is displayed, the correctness and completeness of the user-entered data should always be checked

‘ShowFrameSetFiles => [{ok}] AF_F (‘CheckReqParam)

– If this check fails, redisplay the input form

‘CheckReqParam =>

[{missing, exists_empty}] AF_F (`ShowFrameSetFiles)


What do we check?What do we check?

• ForgottenPwd feature: – The password question should only be shown once a

valid e-mail address has been input.

‘ShowPwdQuestion =>

(AF_B(‘CheckEmailAddr) /\

AWU_B(~’CheckEmailAddr, ![{successful}]!T))

– The notification page that an e-mail with the new password has been sent should not be shown before it was really sent out:

‘Service2Context =>

ASU_F ( ‘ShowPwdAck,’SendMimeMessage)


Agile Process-Oriented DesignAgile Process-Oriented Design

Running Process

Process Model

ProcessRequirements

Deployment

Validation, Analysis

Testing & Monitoring

Orchestration

PlatformServices

Business Process Analysis

Service-Oriented Design: Service-Oriented Design:

The Roots The Roots

Service-Oriented Design: Service-Oriented Design:

The Roots The Roots

Manfred ReitenspießBusiness Development

RTP4 Continuous Services

Bernhard SteffenProgramming Systems

and Compilers

Tiziana Margaria

Service Engineering

for Distributed Systems


Granny´sGranny´sFreephoneFreephone


The IN Service Definition EnvironmentThe IN Service Definition Environment

Early AMDDEarly AMDD


IN ArchitectureIN Architecture

DesignProvisioning

Management

Execution


IN Conceptual Model PlanesIN Conceptual Model Planes

serviceplane

globalfunctional

plane

distributedfunctional

plane

physicalplane -

protocolsand

processing

global service logic

GSL1

GSL2

GSLn

POI

POR

SIB1

SIB2

SIBn

BCP

service1 service2

SF1

SF2

SFn

PE1

PEn

PE2

P1 P2

Pn

FE1FE2

FE1

FE2

FEA

EF

EF

EF

EF

FEA


Service PlaneService Plane

The Service Plane represents an exclusively service-oriented view.

This view contains no information whatsoever regarding the implementation of the services in the network. What is perceived is the network's service-related behavior as seen, for example, by a service user.

Services are composed of one or more Service Features (SFs), which represent the "lowest level" of services.

The Global Service Logic (GSL) describes how service features are built using SIBs.


IN CS.1 ServicesIN CS.1 Services

• Automatic Alternative Billing (AAB)• Abbreviated Dialing (ABD) • Account Card Calling (ACC)• Credit Card Calling (CCC)• Call Distribution (CD)• Call Forwarding (CF)

– Comp. of Call to Busy Subscriber

– Conference Calling (CON)• Call Rerouting Distribution (CRD)• Destination Call Routing (DCR)• Follow-Me-Diversion (FMD)• Freephone (FPH)

• Mass Calling (MAS)• Malicious Call Identification (MCI)• Premium Rate (PRM)• Security Screening (SEC)• Selective Call Forward on

Busy/Don’t Answer (SCF)• Split Charging (SPL)• Televoting (VOT)• Terminating Call Screening (TCS)• User-Defined Routing (UDR)• Universal Access Number (UAN)• Universal Personal

Telecommunications (UPT)• Virtual Private Network (VPN)


IN CS.1 Service FeaturesIN CS.1 Service Features

• Abbreviated Dialing (ABD) Customized Recorded Announcement (CRA)• Attendant (ATT) Customized ringing (CRG)• Authentication (AUTC) Destinating User Prompter (DUP)• Authorization Code (AUTZ) Follow-Me Diversion (FMD)• Automatic Call Back (ACB) Mass Calling (MAS)• Call Distribution (CD) Meet-Me Conference (MMC)• Call Forwarding (CF) Multiway Calling (MWC)• Call Forwarding on Busy (CFC) Off-Net Access (OFA)• Call Gapping (GAP) Off-Net Calling (ONC)• Call Hold with Announcement (CHA) One Number (ONE)• Call Limiter (LIM) Origin Dependent Routing (ODR)• Call Logging (LOG) Originating Call screening (OCS)• Call Queuing (QUE) Originating User Prompter (OUP)• Call Transfer (TRA) Personal Numbering (PN)• Call Waiting (CW) Private Numbering Plan (PNP)• Closed User Group (CUG) Reverse Charging (REVC)• Consultation Calling (COC) Split Charging (SPLC)• Customer Profile Management (CPM)


Example: Authentification FeatureExample: Authentification Feature


Service Independent Building BlocksService Independent Building Blocks

• SIBs are

– reusable modular building blocks,

– describing a single complete activity,

– used by the service designer to create services

• independent from any physical architecture considerations (PIM)

• Each SIB has an interface with inputs and outputs

SIBs = {Algorithm, Charge, Compare, Distribution, Limit,

Log Call Information, Queue, Screen, Service Data Management, Status Notification, Translate, User Interaction,Verify}


Example: The Queue SIBExample: The Queue SIB

Entry

Context

Parameters

Branches


Example: Universal Personal TelephonyExample: Universal Personal Telephony

UPT is a mobility service which enables subscribers to use a number of telecommunications services to

• initiate any type of service and

• receive any type of call on the basis of a unique Personal Telecommunications

Number (PTN) across multiple networks at any user-network access (fixed, movable or mobile), irrespective of geographic location, limited only by terminal and network capabilities.

The PTN will be translated to an appropriate destination number for routing based on the capabilities subscribed to by each Service Subscriber (SS).


Example: Service mappingsExample: Service mappings

• Authorization Code (AUTZ) • Follow-Me Diversion (FMD)• Personal Numbering (PN)• Split Charging (SPLC)

• Authorization Code (AUTZ) • Follow-Me Diversion (FMD)• Personal Numbering (PN)• Split Charging (SPLC)


Service Creation Environment (SCE)Service Creation Environment (SCE) • Framework for defining, developing and testing SLPs

e.g.– graphical SIB-based ‘drag and drop’– graphical SDL-based– high level, 4GL language based– low level C-language based with special resources e.g. libraries and runtimes– proprietary graphic and/or text based

• Services are loaded via SMS to SCPs


Example of IN Service CreationExample of IN Service Creation

• IN: Service logic design with SDL and coding with C

mes s ageId=123Start

(wfDbTimer)

Not OK

wf_nt_res p

Yes

Play

Announcement

db_nt_reques t

Not in us e

Connec tTo

Res ource

idle

Re leas eCall

700-s ervice?

InitialDP

idle

idle

Re leas eCall

(* CVOPS state-automaton for 700-service *)(* state input actions *)

idle InitialDP {

(* Call c-function that checks calledPartyNumber *) result=numberTranslationService() if(result==700SERVICE){ (* send query to database and wait for reply *) db_nt_request start(wfDbTimer) to(wf_nt_resp) } else if(result==SERVICE_NOT_IN_USE){ (* Play annoucement to user *) ConnectToResource messageId=123 PlayAnnouncement ReleaseCall to(idle) } else{ (* error *) ReleaseCall to(idle) }}

wf_nt_resp db_nt_resp {

stop(wfDbTimer) if(dbStatus==OK){ ...



OverviewOverview



• The roots





Tiziana MargariaChristian Kubczak

Service Engineering for Distributed Systems

Bernhard SteffenRalf Nagel

Chair of Programming Systemsand Compilers

The SWS Challenge inThe SWS Challenge in jETIjETIThe SWS Challenge inThe SWS Challenge in jETIjETI

Tiziana MargariaChristian Winkler

Chair of Service and Software Engineering

Bernhard SteffenChristian Kubczak

Ralf Nagel

Chair of Programming Systemsand Compilers

The jABC/jETI Approach The jABC/jETI Approach

to Mediation and Choreographyto Mediation and Choreography

The jABC/jETI Approach The jABC/jETI Approach

to Mediation and Choreographyto Mediation and Choreography


The ETI Idea (1996)The ETI Idea (1996)

• Make tools remotely available

• Simple GUI to use tools

• (operating) System independent

technology• Simple way of integrating tools

Giving Software/Tools a Trial as easy as Test Driving a Car ?


The ETI Idea (1996)The ETI Idea (1996)

• Make tools remotely available

• Simple GUI to use tools

• (operating) System independent technology

• Simple way of integrating tools


Providing Tool AccessProviding Tool Access

For structured access to the tool functionalities in the tool repository, users can

– get detailed information on each available tool feature

– combine heterogeneous tool functionalities to programs

– execute single tool features

– run the programs via the Internet

tool coordination and Internet-based executionfacilities are the conceptual key features


The ETI Community ServiceThe ETI Community Service

• a Web-based, open platform

• interactive experimentation with

heterogeneous tools

• elaborate coordination support

• coordination programs can be run

via the Net


Weaknesses of the OriginalWeaknesses of the Original Process Process

Integrator

• needs to be familiar with HLL and C++• needs direct access to ETI’s core

Integration becomes support-intensive!

Tool-Provider ≠ Tool-Integrator


ABC / Java ABC (jABC)ABC / Java ABC (jABC)

SIBs

SLGs

Plugins

Demo this afternoonDemo this afternoon


OverviewOverview



• The roots






ToolExecuter

HTML ToolConfigurator

Tomcat Servlet Container

j ET I T ool Provider

jE T I ToolP rovider

File Edit

j ET I Client

SIB JavaC lass

ABC V FS In terface

<X M L>Tool

Desc.</XM L>

j A BC Component S erver

S IB C reator

<XM L>Too l

D escription< /XM L>

jETI Plugin

jETI PlatformjETI Platform

jABC FrameworkjETI Extension


Step 1: Tool IntegrationStep 1: Tool Integration

Tool P rovider

Local tool

ToolExecuter



jE T I Tool P rovider

<XM L>Too l



ToolExecuter


Tomcat Servlet Conta iner


A B C V FS In terface

jA B C C omponent S erver

<XM L>Too l


Step 2: Tool RegistrationStep 2: Tool Registration

<X M L>Tool

Desc.</XM L>

SIB JavaC lass

S IB C rea tor


OverviewOverview



• The roots






Step 3: Tool Invocation Control FlowStep 3: Tool Invocation Control Flow

File Edit

jE T I C lient

SIB JavaC lass

ABC V FS In terface

<X M L>Tool

Desc.</XM L>

jA B C C omponent S erver

S IB C reator

jETI Plugin


Step 4: Execute Tool Control FlowStep 4: Execute Tool Control Flow

ToolExecuter




File Edit

jE T I C lient

<XM L>Too l


jETI Plugin


ToolExecuter





File Edit

j ET I Client

SIB JavaC lass

ABC V FS In terface

<X M L>Tool

Desc.</XM L>


S IB C reator

<XM L>Too l


jETI Plugin

Deploy jETI-Configurator and jETI-ExecutorDeploy jETI-Configurator and jETI-Executor


ToolExecuter





File Edit

j ET I Client

SIB JavaC lass

ABC V FS In terface

<X M L>Tool

Desc.</XM L>


S IB C reator

<XM L>Too l


jETI Plugin

Tool ConfigurationTool Configuration


ToolExecuter





File Edit

j ET I Client

SIB JavaC lass

ABC V FS In terface

<X M L>Tool

Desc.</XM L>


S IB C reator

<XM L>Too l


jETI Plugin

Tool Parameter ConfigurationTool Parameter Configuration


ToolExecuter





File Edit

j ET I Client

SIB JavaC lass

ABC V FS In terface

<X M L>Tool

Desc.</XM L>


S IB C reator

<XM L>Too l


jETI Plugin

Register Tools at Component ServerRegister Tools at Component Server

ToolDescription


jETI Tool-ConfigurationjETI Tool-Configuration


Creating a New ToolCreating a New Tool


Creating Tool ParametersCreating Tool Parameters


Specify Tool ParameterSpecify Tool Parameter


Tool Parameters SpecifiedTool Parameters Specified


Tool Configuration CompletedTool Configuration Completed


Tools Registered at Component ServerTools Registered at Component Server


OverviewOverview

• An Evolving framework


• The Tool Provider view

• The Tool User view

• Perspectives


Starting jABC ClientStarting jABC Client

available tools


Setting Tool ParametersSetting Tool Parameters

tool node name

tool parameter

edit single parameter

tool execution results

selected tool invocation


Tool Invocation Control FlowTool Invocation Control Flow


Execute Tool Control FlowExecute Tool Control Flow


ToolExecuter





File Edit

j ET I Client

SIB JavaC lass

ABC V FS In terface

<X M L>Tool

Desc.</XM L>


S IB C reator

<XM L>Too l


jETI Plugin

Execute Tool SequenceExecute Tool Sequence


OverviewOverview

• An Evolving framework


• The Tool Provider view

• The Tool User view

– An Example execution

• Perspectives


Model Preparation (1)Model Preparation (1)


Model Preparation (2)Model Preparation (2)


Calling the TracerCalling the Tracer


Executing the CodeviewerExecuting the Codeviewer


Output of the CodeviewerOutput of the Codeviewer


Executing the JADExecuting the JAD


Output of JAD (1)Output of JAD (1)


Executing ZKM and JADExecuting ZKM and JAD




Executing SOOT and JADExecuting SOOT and JAD




Execution CompletionExecution Completion


FMICS jETI Repository of MC ToolsFMICS jETI Repository of MC Tools

Participants:

CWI: Jaco van de Pol, Bert Lisser (T) INRIA: Hubert Garavel, Radu Mateescu ISTI: Stefania Gnesi, Diego Latella, Franco Mazzanti (T), Gianluca Trentanni (T) U. Brno: Lubos Brim, Jiri Barnat (T) U. Dortmund/U. Potsdam: Tiziana Margaria, Bernhard Steffen Christian Kubczak (T), Stefan Naujokat (T) Marco Bakera (T), Christian Topnik (T) U. Malaga: Pedro Merino, Jesus Martinez (T) U. Saarbrücken: Holger Hermanns, Reza Pulungan (T) [CCLRC: Juan Bicarregui, Alvaro Arenas] for information

Coordination: Tiziana Margaria, Christian Kubczak, all the group leaders of the groups above.


OverviewOverview



• The roots




• SWS Challenge 2006



SWS Challenge 2006 SWS Challenge 2006 Phase I : Service MediationPhase I : Service Mediation

SWS Challenge 2006 SWS Challenge 2006 Phase I : Service MediationPhase I : Service Mediation


A ServiceA Service Mediation ScenarioMediation Scenario


Solution:Solution:

1. Generate SIBs from Moon’s WSDL descriptions of the Legacy System

2. Model Mediator workflow in jABC (SLG)

3. Generate web service out of the mediator SLG

4. Use generated web service with RosettaNet Client


Web-Service

Integrating (Web) ServicesIntegrating (Web) Services

BuildingBlock

WSDLjETI

SOAPSOAP

1. Generate SIBs from Moon’s WSDL descriptions of the Legacy System


2. Moon Mediator Workflow2. Moon Mediator Workflow




2. Moon Mediator Workflow - WS2. Moon Mediator Workflow - WS


Web-Service

Web-Service

3. Integrating/Providing (Web) Services3. Integrating/Providing (Web) Services

BuildingBlock

WSDL

jETI-Tool

BuildingBlock

SOAP

WSDLjETI

Mediator


jETI Status jETI Status

• Generic Orchestration SIBs

• SWS Challenge (Web Services)• Bioinformatics (Services and SIBs)• GIS (SUN/Ricoh/ProDV) • Office Automation Support• IKEA SCM• FMICS jETI Platform

…

Halle 1 Stand A90/A91


jETI StatusjETI Status


Conclusions and PerspectivesConclusions and Perspectives

• Service-oriented, model-driven

• Not new!

• Web Service technology:

– Integration by registration

– Seamless remote execution

• Experience in many different domains

• Compile vs. runtime

• Standardizing services in a domain (Service catalogues)

• Services as “functions”

• Semantics!


Tiziana Margaria


Christian Kubczak Marc Njoku

Chair of Programming Systems SEDSUniversität Dortmund Universität Göttingen

Workflows in BioinformaticsWorkflows in BioinformaticsWorkflows in BioinformaticsWorkflows in Bioinformatics

Gene name/ EnsemblID

Llist of species

Get Ortholo-gous IDs

Get Sequences for all IDs

Region

WUBlast each aginst each(Asynchronous Webservice)

Search Array of Positions for the best Position

For each ID, output the best Position

List with ID‘s

Liste with Sequences

List of species (s.above.)

Identify the ‚right‘ WUBlast-match

WU-Blast Result

Array of Positions[ID1 / ID2]

(recursively)


Orthologe ID‘s holenOrthologe ID‘s holen

• Sinn: – Stellt ein Set aller zueinander orthologen Gene (ausgehend von dem

Eingangs-Gen) in allen gegebenen Arten zusammen.• Eingangsinterface

– String ensemblID– organismType(XML)[] organismList

• Ausgangsinterface– Array mit den Informationen Artname, EnsemblID (Array of orthologs, XML?)

• Vorhanden– Webservice, der die ‚orthologen IDs‘ für ein Artenpaar zurück gibt

• Eingabe 2* organismType und eine ensemblID• Ausgabe Acessionnumber[] idList

• Problem– Das Holen der ‚orthologen IDs‘ muss rekursiv und jeder gegen jeden

erfolgen• TODO

– rekursiver Ansatz verwirklichen– Ausgangsinterface besser definieren


Sequenzen für alle ID‘s holenSequenzen für alle ID‘s holen

• Sinn: – Sequenzen für das anschließende Blasten bereitstellen.

• Eingangsinterface– organismType(XML) Artname – String EnsemblID– String Bereichsangabe (first exon, promotor etc.)

• Ausgangsinterface– sequenceType(XML) Sequenz

• Vorhanden– Ensembl Java API, Beispielprogramm

• Problem– Modul holt eine Sequenz und muss in Schleife

angesprochen werden• TODO

– Modul schreiben– Schleife konzipieren


For each species, until

list empty

For each species but the current one,

till list empty

For all IDs, till all compared

For each ID, till list empty

Get sequence ID

WU Blast

Identify hit

For each species, till list empty

For each ID of the blasted species

Add results to matrix

(ID -> species)

For each species but the current

one, till list empty

Prepare matrixfor all IDs(ID x ID)

Go through matrix

columns

Determine best position (ID) in a

column Collect

position result

ID

Species

Complete ID List

Sequence

Result

Positions

Positions for one ID

Position matrix

Column

Best positions for all IDs

Gene name

Get ID Get orthologue IDs

List of species

Species

ID

List of species

Refined Specs


Getting the pairs


Build the result

Format the result




The Final SLGThe Final SLG


Tiziana Margaria





Services…Services…

for comfort

and increased productivity

(Peter Naur, NATO Software Engineering ConferenceGarmisch Partenkirchen, 1968)


Tiziana Margaria Bernhard Steffen

Mike Hinchey (NASA Goddard)Christopher Rouff (SAIC)Jim Rash (NASA Goddard)

Enhancing R2D2C with LearningEnhancing R2D2C with LearningEnhancing R2D2C with LearningEnhancing R2D2C with Learning


Requirements (to Design) to CodeRequirements (to Design) to Code

Requirements expressed as scenarios

CodeModels

Engineered system:

Two ways to apply R2D2C:

Existing code generating tools

Existing model extraction (reverse engineering) tools

Mathematical laws of concurrency

(reversed)

Reverse engineered system: first , then

7


NASA‘s R2D2CNASA‘s R2D2C

D1 Scenarios Capture: Engineers, end users, and others write scenarios describing intended system operation. The input scenarios may be represented in a constrained natural language using a syntax-directed editor, or in other textual or graphical forms.

D2 Traces Generation: Traces and sequences of atomic events are derived from the D1 scenarios

D3 Model Inference: A formal model, or formal specification, expressed in CSP is inferred by an automatic theorem prover (here ACL2) using the traces derived in D2.

D4 Analysis: uses available commercial, public domain, and specially developed tools (CSP based)

D5 Code Generation:Uses special purpose tools, or FDR, or e.g., conversion of CSP to B and then using the B Toolkit).


Requirement specifications in terms of individual traces are by their nature very partial.

They represent only the most prominent situations.

Techniques for systematically completing such partial requirement specifications are of major practical importance.

Requirements completion based on Automatic (active) automata learning.

Learning-Based Requirements CompletionLearning-Based Requirements Completion


Enhanced R2D2C Enhanced R2D2C (with Requirement Completion) (with Requirement Completion)

L1Temporal

Constraints

L2Requirem.

Completion

Traces

Seq.Model

Seq.Model


Enhanced R2D2C:Enhanced R2D2C:

Replace Mode [D3/L2]:

• the requirements completion component L2 replaces model inference (bypassed):

• Analysis and code generation work on the model produced by L2.

• Currently, this means that we restrict ourselves to sequential models.


Enhanced R2D2C:Enhanced R2D2C:

Integrated mode:• the requirement completion component L2 is added to

the original process. • L2

– supports the evaluation of the given set of requirement traces,

– hints at underspecified portions

– which may be successively completed.

• This option strengthens the original R2D2C process.

For true model-based system-level design!


R2D2C UsesR2D2C Uses

• End-to-end automatic code generation of provably correct systems

• Automatic reimplementation after any requirements change

• Exploiting re-use across platforms

• Reverse engineering legacy systems to a mathematically sound model

• Analysis and documentation of existing systems (e.g., expert systems)

• Re-engineering of legacy systems to a provably correct new implementation

12


Benefits of the MethodBenefits of the Method

• Automation of entire development process

• Significant increase in quality

– Ability to do formal proof on properties of implementations– Ability to do formal proof of correctness – Automated means for requirements analysis– Guaranteed correspondence between requirements and

their implementation as code

• Model-enabling also legacy systems

11


Domains (to date)Domains (to date)

• Verification of Robotic Procedures (e.g. Hubble Space Telescope Robotic Servicing Mission)

• Wireless Sensor Networks

• Communication Systems

• Agent Based Systems



MaTRICS: MaTRICS: Remote Configuration of SystemsRemote Configuration of Systems


MaTRICS Sendmail Config. MaTRICS Sendmail Config.

modelled and implemented as SLG:


Client Protocol ManagerPalette


Documents

T. Margaria STRESS ‘06 – 24.5.2006 Tiziana Margaria Chair of Service and Software Engineering Universität Potsdam Service Engineering Service Engineering