LEAP A Language for Architecture Design, Simulation and Analysis

LEAP
A Language for Architecture Design, Simulation and
Analysis

Tony Clark1 , Balbir S. Barn1 , Samia Oussena2

1 Middlesex University, London, UK
2 School of Computing, University of West London, UK

April 18, 2012

Tony Clark, Balbir S. Barn, Samia Oussena (Universities of Somewhere and Elsewhere) Simulation and Analysis 18, 2012
LEAP A Language for Architecture Design, April 1 / 44

Plan

Problem, Hypothesis, Solution.
LEAP.
Use-Cases.
LEAP-based Research Areas


Architectural Complexity


Proposal

Identify the key features:
Components, port, connectors.
Information models, highly structured data.
Speciﬁcation of behaviour, state machines.
High-level operations, complex where necessary.
Event processing.
Simulation.
Text for deﬁnition, diagrams for understanding.
Identify use-cases.
Incrementally extend features as necessary.


The LEAP Tool


Data Models

component library {
model {
class Reader {
name:str
}
class Book {
name:str
}
assoc Borrow {
reader:Reader;
book:Book
}
}
}


Syntax Checking


Invariants
component library {
model {
class Reader { name:str }
class Book { name:str }
assoc Borrow {
reader:Reader;
book:Book
}
}
invariants {
reader_can_borrow_3_books {
forall Reader(n) in state {
(length([n | Borrow(Reader(n),_) <- state ])) <= 3
}
}
}
}


State


State

Tony Clark, Balbir S. Barn, Samia Oussena (Universities of Somewhere and Elsewhere) Simulation and Analysis 2012
LEAP A Language for Architecture Design, April 18, 10 / 44

Ports and Interfaces

model {
class Reader { name:str }
class Book { name:str }
assoc Borrow {
reader:Reader;
book:Book
}
}
port manage_readers[in]: interface {
register(r:str):void
}
port manage_books[in]: interface {
borrow(r:str, b:str):void
}
}


Speciﬁcations

component library {
model { // Reader, Book, Borrow...
}
// ports manage_readers, manage_books...
spec {
register(r:str):void {
pre not(Reader(r))
post Reader(r)
}
borrow(r:str,b:str):void {
pre Reader(r) Book(b) not(Borrow(_,Book(b)))
post Borrow(Reader(r),Book(b))
}
}
}


Operations
component library {
model { // Reader, Book, Borrow...
}
// ports manage_readers, manage_books...
operations {
register(r) {
new Reader(r)
}
borrow(r,b) {
find reader=Reader(r) in state {
find book=Book(b) in state {
find Borrow(_,book) in state {
error(’book ’ + b + ’ already borrowed’)
} else new Borrow(reader,book)
} else error(’no book: ’ + b)
} else error(’no reader: ’ + r)
}
}
}

Simulation 1


Simulation 2


Simulation 3


Simulation 4


Simulation 5


Simulation 6


Simulation 7


Data Representation
model {
class Faculty {
name:str;
schools:[Department]
}
class Department {
name:str;
groups:[Group]
}
class Group {
name:str;
members:[Staff]
}
class Staff {
name:str;
age:int
}
}

Constructing Trees

init {
new Faculty(’Engineering’,[
Department(’Maths’,[
Group(’Pure’,[
Staff(’Dr. Piercemuller’,60),
Staff(’Dr. Eager’,30)
]),
Group(’Applied’,[
Staff(’Prof. Lappin’,57),
Staff(’Mr. Qip’,40)
])
]),
Department(’Computing’,[])
])
}


Comprehensions

operations {
staff_names() {
[ name | Faculty(_,departments) <- state,
Department(_,groups) <- departments,
Group(_,staff) <- groups,
Staff(name,_) <- staff ]
}
staff_over(age) {
[ name | Faculty(_,departments) <- state,
Department(_,groups) <- departments,
Group(_,staff) <- groups,
Staff(name,staff_age) <- staff,
?(staff_age > age) ]
}
}


Recursive Functions

operations {
staff_names() {
letrec get_names =
fun(data)
case data {
[] -> [];
h:t -> (get_names(h))+get_names(t);
Faculty(_,departments) -> get_names(departments);
Department(_,groups) -> get_names(groups);
Group(_,staff) -> get_names(staff);
Staff(name,_) -> [name]
}
in get_names(state)
}
}


Rules
component order_processing {
port authorization[in]: interface {
finance(id:int):void;
manager(id:int):void;
procurement(id:int):void
}
port dispatch[out]: interface {
order(id:int):void
}
operations {
finance(id) { new Finance(id) }
manager(id) { new Manager(id) }
procurement(id) { new Procurement(id) }
}
rules {
order: Finance(id) Manager(id) Procurement(id) {
dispatch <- order(id)
}
}
}Clark, Balbir S. Barn, Samia Oussena (Universities of Somewhere and Elsewhere) Simulation and Analysis18, 2012
Tony LEAP A Language for Architecture Design, April 25 / 44

State Machines: Messages
port authorization[in]: interface {

// Messages are received when specific
// authorization is received. The order
// id is supplied...

finance(id:int):void;
manager(id:int):void;
procurement(id:int):void;
complete(id:int):void;
reset():void
}
port dispatch[out]: interface {

// Sent to the output port when the
// order is complete...

order(id:int):void
}

State Machines: Types

machine(Start:start) {

// Types are used to define states.
// Types may be named and then used in
// the rest of the machine...

type start = Start
type finance = Finance(int)
type manager = Manager(int)
type procurement = Procurement(int)
type end = End(int)

// Transitions...
}


State Machines: Transitions
machine(Start:start) {
// (finance
// (manager procurement + procurement manager)
// complete reset)*
go:start->finance
finance(i) Start->Finance(i);
multiple_finance:finance->finance
finance(i) Finance(i)->Finance(i);
got_manager:finance->manager
manager(i) Finance(i)->Manager(i);
got_procurement:finance->procurement
procurement(i) Finance(i)->Procurement(i);
end1:manager->end
complete(i) Manager(i) -> End(i) { dispatch <- order(i) }
end2:procurement->end
complete(i) Procurement(i) -> End(i) { dispatch <- order(i) }
reset:end->start
reset End(i) -> Start;
}

State Machines: Execution


Communication: Deﬁnition
component container {
component sender {
port output[out]: interface {
m():void
}
init { output <- m() }
}
component receiver {
port input[in]: interface {
m():void
}
machine(0:int) {
t:int->int m 0->0 {
print(’RECEIVED MESSAGE’)
}
}
}
init {
connect(sender.output,receiver.input)
}

Communication: Execution


GUI: Contacts


Manager

component manager {
// Ports changed and manage...
operations {
add(n) {
new Contact(n);
changed <- show([name | Contact(name) <- state])
}
remove(n) {
delete Contact(n);
changed <- show([name | Contact(name) <- state])
}
}
}


GUI
component gui {
display = jcomponent(’frames.GUI’)
// Ports manage and update...
add_button = Button(’add’,fun(e) manage <- add(e.contact))
operations {
show(data) {
display.in <- display(
Table(
[[Text(n),delete_button(n)] | n <- data] +
[[Input(’contact’,’’,10),add_button]]
))
}
delete_button(name) {
Button(’delete’,fun(e) manage <- remove(n))
}
}
}


GUI: Execution


Use Cases and Research Areas
Simulation.
Refinement.
Alignment.
Goal modelling and goal modelling.
Analysis of non-functional properties:
Cost.
Performance.
Security.
Architectural Patterns.
Product Lines and Configuration.
Slicing.
Testing.
Publications: [3, 1, 2, 4], InfoSys SETLAB Briefings, WAMBSE
Workshop. ICSoft alignment paper submitted.


T. Clark, B.S. Barn, and S. Oussena.
Leap: a precise lightweight framework for enterprise architecture.
In Proceedings of the 4th India Software Engineering Conference,
pages 85–94. ACM, 2011.
Tony Clark and Balbir S. Barn.
Event driven architecture modelling and simulation.
In SOSE, pages 43–54, 2011.
Tony Clark and Balbir S. Barn.
A common basis for modelling service-oriented and event-driven
architectures.
In 5th India Software Engineering Conference, IIT Kanpur, ISEC 12,
2012.
Tony Clark, Balbir S. Barn, and Samia Oussena.
A method for enterprise architecture alignment.
In PRET at CAISE 2011, 2012.


LEAP A Language for Architecture Design, Simulation and Analysis

More Related Content

Similar to LEAP A Language for Architecture Design, Simulation and Analysis (20)

More from ClarkTony (20)

Recently uploaded (20)

LEAP A Language for Architecture Design, Simulation and Analysis