1

Synthesizing InformationSystems: the APIS Project

Marc Frappier, Benoît Fraikin,Frédéric Gervais, Régine Laleau,

Mario Richard

Université Paris-12

GRIL

2

Information Systems (IS)

• Typical example : ERP• COTS ERP global market

US$ 16,7 billion in 2005• Canadian application development and

systems integrationCAD$ 4.464 billion in 2006

• Canada : 75 000 jobs in IS development

3

COTS

• Simplicity– buy knowledge, reduce development risk,

(reduce cost)• Rigidity

– business process must conform to theCOTS

– little room for adaptation (hard to integratenew COTS versions)

4

IS Development : State of the Art

• Specification & Design– UML, mostly

• Implementation– J2EE, Hibernate, Spring, JDBC, SQL, ...– Web : Struts, JSF, AJAX, HTML, java

scripts, ...– SOA, WSDL, BPEL, WSCI– MDA

5

IS development is expensive

• Technology is constantly changing• Technology is overloaded with minute

details to deal with• Technology requires a long learning

curve

6

Service systems

• Create value• Precondition

– cheap development costs!• This is where we can contribute

7

The APIS project

• Automatic Production of Information Systems• Objectives

– Automatically derive information systems (IS)implementation from formal specifications

– Validate IS specifications– Reuse IS specifications– Maintain IS specifications– Develop notations and tools to support these

activities

8

Software Synthesis• Automatically derive a software from a

specification

Synthesis

Specification

System

9

Goal : Reducing SoftwareDevelopment Costs

requirementsanalysis

design

coding

unit &integrationtesting

testingacceptance

Traditional Development Synthesis

Goal50 % effort reduction

testingacceptance requirements

analysis

10

• test• not exhaustive• only shows the

presence of errors• does not prove the

absence of errors

• specificationverification /validation

• code generation• fast interpretation• proof of synthesis

algorithms

Traditional Development Synthesis

Goal : Improving System Reliability

11

Goal : Improving Adaptability

• Define specification patterns• Allow them to be instantiated and

personalised• Reuse patterns from business to

business• How to manage integration between

different versions?

12

The EB3 Method

• Designed for information systemspecification

• hybrid notation :– process algebra– one state variable (system trace)– recursive functions for entity attributes– input-output rules

13

EB3 Support : APIS platform

IS Specification

GUISpec.

ERDiagram

ProcessExpressions

AttributeDefinitions

I-ORules

WebInterface DB Schema

QueryPrograms

DBMSEB3PAI

IS User

DCI-Web EB3TG

SoftwareEngineer

Input / output Generate Excecute

EB3IO

UpdatePrograms

DB

14

The EB3 Method - Steps

1. Define business model (UML ER diagram)2. Identify external events for entities and

associations3. Specify entity and association behavior

using a process expression4. Define entity attributes computation using

recursive functions on traces5. Define output using rules on traces and

attributes

15

1 - Business Model

book member

JoinLeave

LendRenewReturn

AcquireDiscardListBook

loan

entity type

associationaction

bookIdtitle

memberIdnamenbLoansmaxNbLoans

date

attribute

1*borrower

16

2 – Actions (events)

inputparameter

outputparameters

Acquire( book : BookId, title : STRING ) : void

Lend( MemberId : MemberId, book : BookId ) : void

ListBookId( book : BookId ) : ( title : STRING, loanCnt : Nat)

17

3 - Entity Type Behavior : Book

book(b : BookId ) =

Acquire(b, _) •

(loan( _, b)*

|||ListBookId(b)*

) •

Discard(b)

18

3 - Entity Type Behavior : Member

member(m : MemberId ) =

Join(m, _,_) •( ||| b : BookId : loan( m, b)* ) • Leave(m)

19

3 - Association Behavior : Loan

loan(bId:BookID, mId:MemberID ) =

nbLoans(mId) < maxNbLoans(mId) Lend(mId, bId) •

( nbLoans(mId) < maxNbLoans(mId) Renew(bId) )* •

Return(bId)

20

3- Main Process

main = ( ||| b : BookId : book(b)* )

||( ||| m : MemberId : member(m)* )

21

4 - Entity Attribute Specification

nbLoans(mId : MemberId) =

Join(mId, _ ) : return 0, Lend(mId, _) : 1 + nbLoans(mId), Return(bId) : if borrower(bId) = mId then nbLoans(mId) - 1, Leave(mId, _ ) : ⊥;

end

22

5 - Input-Output Rules

• Use plain SQL queries• Developing an ER query language

based on a set-theoretic model

23

Expressing Queries

• Use set-theoretic representation of ERmodel– sets– functions– relations

24

-key1 : int-f1 : int

E1

-key2 : intE2

-f2 : intE4

1..*

-f3

1..1- : int

E3

1

-f4

*

1

-f5

*

E1[x].key1, x.f1, E2[y].f3.f2 WHERE x.f4 = y.f5

25

SELECT E1.key1, E1.f1, E4.f2FROM E1, E2, E3, E4WHERE E2.key2 = E4.f3AND NOT EXISTS (SELECT * FROM E3 AS t1E3 WHERE t1E3.key1 = E1.key1 and t1E3.key2 is null)AND NOT EXISTS (SELECT * FROM E3 AS t2E3 WHERE t2E3.key2 = E2.key2 and t2E3.key2 is null)

E1[x].key1, x.f1, E2[y].f3.f2 WHERE x.f4 = y.f5

translates into

26

User Interface Specification

27

UI Specification

28

Example : Mail Reader

29

EB3PAI – Process AlgebraInterpreter

30

Transition Computation by Proof

31

EB3PAI : Algorithmic Complexity

• n : number of entities in an entity type• s : size of specification text

O(s + log(n))• Transaction execution time for library

system

100 ms

32

Attribute Specification

33

34

Future Development

• ELTS : extended labeled transitionsystems

• Validation of EB3 specification• Reuse of EB3 specification

35

ELTS

36

Reuse

• process expressions• attribute definitions• inheritance• instantiation• patterns

37

1:N association

E1

ProducerAModifierAConsumerA

ProducerE1ModifierE1ConsumerE1

A

ke1

date

1 *

E2

ProducerE2ModifierE2ConsumerE2

ke2

38

1-N association

39

Functional Security

• specify security policies at the businessrequirements level– “A broker must obtain approval from his client and

then from senior manager before bidding onproducts of type X”

– “In case of emergency, the emergency personnelmay have access to the patient’s record withoutapproval of treating doctor. The patient and thetreating doctor must be notified of this access.”

40

Functional Security in SOA

41

MDA Functional Security

42

Conclusion

• raise level of abstraction– reduce design, coding and testing

• generate code / symbolic execution• reduce IS development cost and

schedule• increase adaptability of IS• increase reliability• increase verifyability

43

Limits and Perspectives

• still need to write some code for domainspecific operators and functions

• effficiency of symbolic execution / generatedcode

• usability of notation• one-size-fits-all for GUI• need more tools ($$$$$)• integration with legacy systems & new

technology• integration with IS development process

44

Industrial partners

• CGI Group– setting up a chair in IS synthesis– NSERC CRD to submit in May

• ÆBIS– domain modeling– knowledge management

• National Bank of Canada– NSERC strategic grant on

functional security