An Architectural Approach to Extensible Applications
description
Transcript of An Architectural Approach to Extensible Applications
![Page 1: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/1.jpg)
...or...“towards making system evolution
as natural as creation”Andrew McVeighJeff MageeJeff KramerImperial College, LondonFebruary 2011
![Page 2: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/2.jpg)
An extensible application...... allows functionality to be added, replaced or removed
without requiring the source code of the application to be revealed or modified [KF98]
In other wordsIt can be evolved by someone other than the creatorWe must support expansion and contraction [Par78]No guarantee of source code
![Page 3: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/3.jpg)
Why is extensibility important?Allows others to customise an application
Takes the burden off the system creatorsAllows niche requirements to be metScalable ecosystem – better for end users
![Page 4: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/4.jpg)
But, extensibility is difficult...“It seems impossible to predict change, and very often,
a successful system will change in ways which are inconceivable to the original designers.”
Keith Bennett et al [BBHL04]
We cannot fully plan for all changes...Someone will want to make unanticipated changesAny design decision will limit some extensibilityAny extension mechanism we build in limit changes!
![Page 5: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/5.jpg)
Why is extensibility so difficult?Our techniques are biased towards system creation
... but this is strange, as we know that ...Evolution and maintenance can be the largest part of a
system’s entire effort [Ben03]
Are we unnecessarily giving freedom in the initial creation phase that cause problems further down the line?
The big question:Can we align system creation and subsequent evolution?
![Page 6: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/6.jpg)
What would an ideal extensibility approach look like?
![Page 7: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/7.jpg)
Audiosoft
Developer X
Radio Station Developers
Developer Y
An extension scenario
![Page 8: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/8.jpg)
5 key requirementsi. ALTER
Able to make *any* change requiredUnanticipated change!Changes proportionate to functionality alteredAt the correct level of abstraction
ii. NO_IMPACTChanges shouldn’t impact others if they don’t want them
So, we can’t push just any changes into the “base”...
![Page 9: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/9.jpg)
5 key requirementsiii. NO_SOURCE
We don’t want to modify (or even see) the source codeCommercial & complexity reasons
Would extensibility problems go if source was available?No...Evidence: many open source systems are extensible
Fork a codebase to make a change == owning it?!Common TCO issue in industry...
![Page 10: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/10.jpg)
5 key requirements... and one extraiv. COMBINE
Detect conflict between automaticallyAllow correction of any conflict as a further extension
v. UPGRADEDespite changes, we should always be able to upgrade baseUpdated versions of extensions
*. ARCHITECTURESystem structure should be explicit; capabilities clear
![Page 11: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/11.jpg)
How do we currently handle extensibility?
![Page 12: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/12.jpg)
Frameworks & extension points
Build a common framework as baseExtension points are like sockets
Explosion of optionsOver time = union of featuresSort of works within 1 organisationTime pressures lead to forked
codebase
![Page 13: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/13.jpg)
Plugin architecturesTakes framework approach several steps further
Everything is a pluginExtension points + plugins + registryVersioned plugins; plugins for plugins
Deals well with planned change but...ALTER restrictedCOMBINE manually checked“flat, coarse-grained” architectures
E.g. WSAD
![Page 14: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/14.jpg)
Aspects & weavingEncapsulate cross-cutting concerns in 1 placeAdd & adjust behaviour at various locations in base
Join points are created naturally!
IssuesSecondary versus primary axisLexical fragilityALTER restricted, COMBINE poor
![Page 15: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/15.jpg)
![Page 16: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/16.jpg)
Desk
m1 : MicDevice m2 : MicDevice
dc : DeviceController
m : Mixer
mixerVolume = 100
a
audio
control
audio
control
controllers
output
input IAudioChannel
out
b
component Desk { ports: out; parts: m: Mixer mixerVolume = 100; dc: DeviceController; m1: MicDevice; m2: MicDevice; connectors: desk1 joins output@m to out; desk2 joins audio@m1 to input@m; desk3 joins control@m1 to controllers@dc; desk4 joins control@m2 to controllers@dc; desk5 joins audio@m2 to input@m; }
Composing the “base”: audio desk
![Page 17: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/17.jpg)
Extending the structure...We are building layers (and burying abstractions)Operate on the hierarchical structure via deltas?
How can we add a turntable that requires cueing audio?
![Page 18: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/18.jpg)
The key insightIf we could adjust the compositional structure via deltas,
we could make any change *and* still preserve the original application.
Base application
An important question
How do we make this a satisfying design experience?
![Page 19: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/19.jpg)
Concept 1: Stratum
combined
fixesturntable CD
desk 1.0
upgraded
A module that holds definitions
Keeps deltas separate from the “base”
X Y
R
RA
A
Ownership of parties reflects extension scenario interplay
![Page 20: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/20.jpg)
Concept 2: ResemblanceNew component as delta changes to another’s structure
Add / delete / replace complete remake possible
Desk
ExtendedDesk
dc : DeviceController
m1 : MicDevice : TurntableDevice
: CuingMixer
a
audiocue
control
cueOutput
output
input
IAudioChannel
cueOut
IAudioChannel
out
b
component ExtendedDesk resembles Desk { ports: cueOut; replace-parts: m becomes cm: CuingMixer; m2 becomes t: TurntableDevice; connectors: cconn joins cueOutput@m to cueOut; iconn joins cue@m2 to cueInput@m; }
Like an advanced form of structural inheritance... [SGW94]
![Page 21: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/21.jpg)
Concept 3: Evolution =resemblance + replacement
Add “replacement” to “resemblance”Allows our new incremental definition to supersede the
previous one...turntable
ExtendedDesk
desk 1.0
Desk
desk 1.0
Desk
turntable
Desk̀(replaces :: desk 1.0 :: Desk)
component resembles Desk replaces Desk { ports: cueOut; replace-parts: m becomes cm: CuingMixer; m2 becomes t: TurntableDevice; connectors: cconn joins cueOutput@m to cueOut; iconn joins cue@m2 to cueInput@m; }
![Page 22: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/22.jpg)
Merging different extensions
CD
Desk̀(replaces :: desk 1.0 :: Desk)
turntable
Desk̀(replaces :: desk 1.0 :: Desk)
desk 1.0
Desk
• Add a CD extension
CD
Desk̀(replaces :: desk 1.0 :: Desk)
turntable
Desk̀(replaces :: desk 1.0 :: Desk)
desk 1.0
Desk
combined• Merge using another stratum
combined
Desk̀(replaces :: desk 1.0 :: Desk)
turntable
Desk̀(replaces :: desk 1.0 :: Desk)
desk 1.0
Desk
CD
Desk̀(replaces :: desk 1.0 :: Desk)
• Correct using an evolution
![Page 23: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/23.jpg)
The expanded resemblance graphBuild up for each perspective...
NewDesk
Desk
Desk̀ (turntable)
NewDesk
Desk
NewDesk
Desk̀ (CD)
Desk
Desk̀ (turntable)
NewDesk
Desk̀ (turntable)
Desk̀ (combined)
Desk̀ (CD)
Desk
![Page 24: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/24.jpg)
Revisiting the extension scenario
combined
fixesturntable CD
desk 1.0
upgraded
![Page 25: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/25.jpg)
• Deltas allow combining extensions
• Combinations checked automatically
• UUIDs avoid lexical fragility
• No source required, only structural description
Checking against requirements...ALTER
NO_IMPACT
NO_SOURCE
COMBINE
UPGRADE
ARCHITECTURE
• Upgrades are also extensions
• Check existing extensions with upgrade
• Only see changes if extension stratum included!
• Combine using dependencies
• Make any structural changes required
• Granularity of components determines cost
• Automatically creates extension points
• Full focus on architecture
• Explicit architecture helps extension developers
![Page 26: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/26.jpg)
Aside: why hierarchical components?Leads to explicit architecture
Compositional hierarchy = multiple levels of abstractionIntuitive electronics “circuit board and chip” metaphor
But, haven’t components “had their day”?[MDEK95] – Darwin, [PBJ98] – SOFA
No! OO techniques are moving gradually in this directionBest practice is composition rather than class inheritanceSpring/Guice/EJB3 are simple component systems
![Page 27: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/27.jpg)
Summary of EvolveArchitecture / structure is always explicit
Encodes many best practices
Creation and extension help each otherCreation does not limit extensibility – creates extension ptsExtensibility does not compromise further creation
Unifies reuse and evolution concepts at design stageHard to “let go” of designing in extension pointsSlightly “uncanny” feeling – agile architecture!
Evolve is aimed at industry developers!http://www.intrinsarc.com
![Page 28: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/28.jpg)
Restrictions and LimitationsNo semantic or behavioural guarantees after extension
Future work aimed at behavioural protocols & goals[PV02] [MK06]
Extensions will be able to alter these descriptions
Cost of change not always proportional to desired changeGranularity of components
Alien approach to many industry developersMoving beyond a textual description!Teach composition first?
![Page 29: An Architectural Approach to Extensible Applications](https://reader034.fdocuments.net/reader034/viewer/2022042718/568167e4550346895ddd4c95/html5/thumbnails/29.jpg)
Bibliography [KF98]- Toward a Formal Theory of Extensible Software
Shriram Krishnamurthi, Matthias Felleisen, SIGSOFT '98/FSE-6 [Par78] - Designing Software for Ease of Extension and Contraction
David Parnas, ICSE ’78 [BBHL04] - Software Evolution
Keith Bennett, David Budgen, Tony Hoare, Paul LayzellGrand Challenges for Computing, 2004
[Ben03] - The software maintenance of large software systems: Management, methods and tools Keith Bennett, Reliability, Engineering and System Safety 1991
[SGW94] – Real-Time Object Oriented Modeling B. Selic, G.Gullekson, P. Ward, John Wiley & Sons, 1994
[MDEK95] - Specifying Distributed Software Architectures Jeff Magee, Naranker Dulay, Susan Eisenbach, Jeff Kramer, ESEC 1995
[PBJ98] - SOFA/DCUP: Architecture for Component Trading and Dynamic Updating Plasil F., Balek, D., Janecek, R., ICCDS 1995
[PV02] - Behavior Protocols for Software Components Plasil, F. and Visnovsky, S., IEEE Transactions on Software Engineering 2002
[MK06] - Concurrency (State Models and Java Programs) Magee, J. and Kramer, J., John Wiley and Sons Ltd 2006