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)
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
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
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
34
Future Development
• ELTS : extended labeled transitionsystems
• Validation of EB3 specification• Reuse of EB3 specification
37
1:N association
E1
ProducerAModifierAConsumerA
ProducerE1ModifierE1ConsumerE1
A
ke1
date
1 *
E2
ProducerE2ModifierE2ConsumerE2
ke2
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.”
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