Andrew McVeighJeff MageeJeff KramerImperial College, LondonFeb 2010

ContentsBrief overview of the formal model structures

Advanced extensibility featuresPort type inferenceHyperports, factories, state machines

The Evolve toolset

Future work

StructureModel is described in the Alloy logic language [Jac02]Built up in layers

Stratum, resemblance, replacement, deltas

Components & interfaces

Structural rules

Strata

sig Stratum{

dependsOn: set Stratum,nestedStrata: set Stratum,exportsStrata: set Stratum,ownedElements: set Element,...

B

C

D

A

CD

Desk̀(replaces :: desk 1.0 :: Desk)

combined

Desk̀(replaces :: desk 1.0 :: Desk)

desk 1.0

Desk

turntable

Desk̀(replaces :: desk 1.0 :: Desk)

Desk

Desk̀ (CD)

Desk̀ (combined)

Desk̀ (turntable)

abstract sig Element{

home: Stratum,replaces: lone Element,resembles: set Element,resembles_e: Element -> Stratum,

...

Elements and Resemblance

Components & Interfacessig Component extends Element {

parts: lone Parts/Deltas,ports: lone Ports/Deltas,connectors: lone Connectors/Deltas,attributes: lone Attributes/Deltas,implementation: lone Implementation/Deltas,

...

sig Interface extends Element {operations: lone Operations/Deltas,implementation: lone Implementation/Deltas,

...

• Port type inference• Hyperports• Factories• State Machines

Inferring port typesPorts of composites have their interfaces inferred

Propagates local changes globally without further deltasExposes interfaces on one port back to “surface”

IBaseIBase

B

C

: A : B

IMore

A

IMore

Cutting through the hierarchyHyperports are auto-connected down the hierarchyMore flexible & general singleton approach [Rum96]

Isomorphic factoriesComponents with lazily instantiated insides [MDEK95]

Use with resemblance and evolutionCan be nested arbitrarily

TransitionsWindowFactory

extension : String

: TransitionsWindow

extension = extension

IWindow

window

IActionListener IJCheckBoxMenuItem

bigFont

ICreate

creator

Executable state machinesComponent variant of state pattern

Big switch componentUse with resemblance and evolutionCombine with conventional components

Advantages over OO approachDon’t get me started!Explicit transitionsExtensible for states and transitionsRich context available for each state

Executable state machines (2)

RentalState

: Start

a : Available r : Rented

IRentalEvent

ITransition

in

stateEvents

purchased

return rental

rent

(+ current focus on Java)

Diagrams versus underlying models

Code generationLossless forward generation

Create bean setters and getters (ports too)Reverse generation

Import beans as full componentsNone of this is mandatory ;-)

Bean.java

Beans.jar

Importing beans as components

RentalCarDetails.java

IRentalCarDetails

RentalCarDetails

model : Stringpurchased : Date

IRenterDetails

renter

details

Running an Evolve application

OR

Generate backbone &run in BB interpreter...

Generate Java wiring code

Other featuresScales to very large models

Diagrams are updated lazilyLessons learnt from UML toolsUses Eclipse UML2/EMF metamodel

Support top-down and bottom-up design approachTolerant of errors in design phase

Team editionMultiple developers working on same model concurrentlyAdvanced object database

Capabilities and challenges

Extensible feature diagramsUsed to define requirements

Product line techniqueResemblance and replacement to extend feature graph

Extensible protocols & goalsBased on behavior protocols for components [PV02]

Aim: allow extension to enforce semantic guarantees

Sequence diagram, ports are actorsCurrently convert to labeled transition systemAnalyse via LTSA [MK06]Find a way to allow extension to “extend”Automatically assemble sequence diagram of composites

Extensible protocols (2)

Backwards compatibilityReverse dependencies

Compresses deltasOlder systems are now deltas against newer system

Replacement for plugin architectureBest of both worlds...

application

DeveloperUser

Some other areas...Reengineering a legacy application

Actually easier than it looks

Active components for concurrencyROOM actor model? [SGW94]

Apply to different environmentsAndroidC#? C++?Hierarchical grid workflows

References Jac02

Jackson, D.Alloy: A Lightweight Object Modelling NotationACM Transactions on Software Engineering and Methodology (TOSEM), ACM Press, 2002, 11, 256-290

Rum96Rumbaugh, J.OMT Insights: Perspectives on ModelingJournal of Object-Oriented Programming, Cambridge University Press, 1996, 123

MDEK9Magee, J.; Dulay, N.; Eisenbach, S. & Kramer, J.Specifying Distributed Software ArchitecturesEsec, 1995, 989, 137-153

MK06Concurrency (State Models and Java Programs)Magee, J. & Kramer, J.John Wiley and Sons Ltd, 2006

PV02Behavior Protocols for Software Components Plasil, F. & Visnovsky, S.IEEE Transactions on Software Engineering, IEEE Press, 2002

SGW94Real-Time Object-Oriented ModelingSelic, B.; Gullekson, G. & Ward, P.John Wiley & Sons, 1994