Enhancing the Role of Interfaces in ADLs

1
Enhancing the Role of Interfaces in ADLs

• Seamus Galvin, J.J. Collins,
• Chris Exton, Finbar McGurren
• Software Architecture Evolution (SAE) Group,
• CSIS Department,
• University of Limerick,
• Ireland

2
Problem statement

• Interfaces arguably the most important part of
  architectural description
• Prerequisite for analysis and system building
• Component builders, testers, managers
• Determine ADLs scope of support
• Roundtrip support
• Widespread adoption of ADLs is dependent on
  interface support

3
Background

• Diverse interface support in ADLs
• Different keywords
• Influenced by primary intended use
• Style specific (C2/Rapide)
• style specific interface support
• Formal ADLs (Wright, Darwin)
• Based on corresponding formal notations
• Narrow interface support limited ADL
  applicability
• Generic ADLs (ACME, ADML, xADL)
• properties/tagged values
• Interface metalanguage/ associated tool support
  left to user
• Non-standardised approach - Re-inventing the
  wheel
• How can this be improved??

4
Objectives

• Provision of a seperate interface metalanguage
  for ADLs that
• Reduces the effort required to provide interface
  support in an ADL
• Is modifiable/extensible
• Both language-independent and language-specific
  support
• Reflect commonalities and differences of
  different interface modelling approaches
• Allow different interface approaches to be
  defined in common format
• Long term
• Basis for broad set of interface-based tool
  support
• Support concerns of developmental approach as
  well as immediate concerns of ADL

5
Presentation Overview

• Outline
• Interfaces in architectural documentation
• Two interface meta-language approaches
• Schema specification
• Application of meta-language to ADL
• Application to xADL
• Example of tool support based on meta-language
• Design-by-contract
• Conclusions/future directions

6
Interface features in architecture

• Taxonomy - Bachmann et al. (2002)
• Name/Identity
• Resources provided
• Syntactic/semantic information
• User-defined data types
• Errors raised by resources
• Exception declarations
• Configuration information
• Quality attribute characteristics
• Required resources
• Rationale
• Usage guide
• Concrete parts should be supported by
  meta-language
• Natural language parts by associated tool support

7
Defining an interface meta-language

• Identified two candidate approaches
• Language-independent and language-specific
  support
• Layered vs Explicit mapping
• Treatment of language-specific concerns based on
  interface features of Java, C and CORBA IDL
• Grammar
• XML-Schema standard
• Interface descriptions are .XML files conforming
  to meta-language schema

8
Layered approach

• Premise
• Common platform-specific features basis for
  language independent schema
• Differing features basis for language-specific
  refinement

9
Layered approach
Features common to all platforms modelled as
language-independent complex types
Features outside this set modelled as
language-specific complex types
10
Layered approach - commentary

• Provides sufficient language-specific support
• Narrow language independent set
• Restricts ability to support a broad set of
  language independent concerns
• Changes/extensions are cumbersome
• Removal of common feature impacts on
  language-specific complex types
• Schema layout could be more intuitive
• Associated tools more difficult to construct

11
Explicit mapping - overview

• Identify and define indicidual interface features
• Represent as core set in meta-language
• Language-independent and language-specific
  schemas defined using these features
• May extend core features
• May define features independent of core set
• Mapping/translation required between language
  independent and language specific set

12
Explicit mapping approach - Core types

• Features influenced by multiple sources
• Bachmann et al. taxonomy
• CORBA IDL
• Java, C, Visual Basic
• Modelled as XML schema simple types and complex
  types

 
13
Explicit Mapping Approach Language-Independent
schema

• Defined in terms of core types

Extend core type To represent precise feature
syntax/semantics
Name of feature
Core type used To define it
14
Language-specific schemas

• Language specific schemas defined in similar way
• Exclusive features defined independent of core
  set
• May include features additional to platform (e.g.
  supported by external tools)

15
Explicit mapping approach - commentary

• Comparison vs Layered approach
• Scope of support in language-independent schema
  no longer restricted
• Changes/extensions less cumbersome
• Schema layout is more intuitive
• Tool support easier to construct
• Commonality between features still reflected
• Improvement on first approach
• Current research focus

16
Applying meta-language to an ADL

• ADLs supporting properties/tagged values
• Conforming descriptions can reference XML
  interface descriptions conforming to
  meta-language
• Applied to xADL 2.0 (University of California,
  Irvine)
• Schema-based, extensible
• New schema containing metalanguage added -
  Interfaces

17
Tool Support Example

• Prerequisite for meta-language use
• Creating/Editing interface descriptions
• Editing metalanguage
• Static/Runtime analysis
• Translators between language-independent and
  specific parts
• Design-by-contract prototype
• Influenced by DBCProxy Eliasson02
• Generates constraint-checking code from XML
  interface descriptions in xADL description
• Runtime checking of constraints

18
Stack Example
Stack interface (simplified XML version)

• Stack example in xADL
• StackImpl defined as component type in xADL
• Stack and RemStack interface types
• DBC constraints
• Semi-formal notation
• Java-specific interface schema

invariants
precondition
postcondition
Resource name
19
Stack example code generation

• Generator takes xADL description as input
• Generates language-specific interfaces
• Generates proxy code that carries out runtime
  checks (Java)

20
Stack example instantiation and invocation

• Instantiation - Client calls factory
  getInstance() method
• If constraint checking enabled, proxy instance
  returned
• Invocation - Client invokes operation on
  interface
• Preconditions for op checked
• Operation invoked on component
• Postconditions and invariants checked
• Exception modes reject, ignore, wait

21
Stack example - commentary

• Benefits for meta-language
• Facilitate seperation of specification from
  implementation
• Constraints do not have to be imbedded into
  component
• Can be changed to suit different usage contexts
• Leverage testing support
• Testing harness

22
Conclusions

• An Interface meta-language
• Foundation for more comprehensive, malleable
  interface support in ADLs
• Contribution to MDA philosophy
• Standard approach to feature declarations
• Potential for standardised, reusable mappings
• Current/Future directions
• Further feature identification
• Mappings
• XSLT ideal candidate
• Role of meta-language in development process
• Cheesman Daniels approach Cheesman2000

23
Conclusions

• Meta-language contributing to ongoing Software
  Architecture Evolution projects
• Supporting integration of xADL with a business
  process composition (workflow) language (ConnX)
• Supporting architecture recovery effort
• Industrial-strength ERP software
• Software reconaissance and reflexion modelling
  techniques
• Recovered architecture modelled using xADL
  meta-language

24
Questions??