1. ArchJava
Connecting Software Architecture to
Implementation
13/03/2012
University of St Andrews

2. Software Architecture (recap)
• Software architecture
 describes the structure of a system
 Enabling more effective design, program
understanding, and formal analysis
 Existing approaches decouple implementation
code from architecture
 Leads to inconsistencies, confusion, violation of
architectural properties
 Inhibits software evolution
University of St Andrews

3. Software Architecture Recap(cont’d)
• Software system collection of
 components,
their connections
• Showing constraints on component interaction
• Describing architecture in formal ADL’s
University of St Andrews

4. ADL’s (briefly)
• ADL’s aid in specification and analysis of high
level designs
• Existing ADL’s loosely coupled to
implementation languages causing problems
in analysis, implementation, understanding
and evolution
• No guarantee that implementation code obeys
architectural constraints
University of St Andrews

5. Module Interconnection
Languages(MIL)
Support system decomposition from separate
modules
ADL’s make connectors explicit to describe
data and control flow between components
MIL’s describe the uses relationship between
modules
But MIL’s provide encapsulation by hiding
names
University of St Andrews

6. ArchJava
• ArchJava is an extension to Java that
• seamlessly unifies software architecture with
implementation,
• ensuring that the implementation conforms to
architectural constraints.
• Guarantees communication integrity between
an architecture and its implementation
University of St Andrews

7. ArchJava
ArchJava seamlessly unifies architectural
structure and implementation in one language
allowing flexible implementation techniques
ensuring traceability between architecture
and code, and
 supporting the co-evolution of
architecture and implementation.
University of St Andrews

8. ArchJava
Guarantees communication integrity even in
presence of advanced architectural features
like run time component creation and
connection
Similar to Darwin which supports dynamic
changes in distributed architectures
University of St Andrews

9. ArchJava Cont’d
• Key benefits
include better program understanding,
reliable architectural reasoning about code
keeping architecture and code consistent as
they evolve,
encouraging more developers to take
advantage of software architecture.
University of St Andrews

10. ArchJava
• Introduces new language constructs
 components
 connections
 ports
• These constructs work together to express
software architecture
University of St Andrews

11. ArchJava
• Language constructs
A component is a special object that
communicates with other components in a
structured way. Is an instance of the
component class
Components communicate at same level
through explicitly declared ports
Regular method calls not allowed
University of St Andrews

12. ArchJava
• Language constructs
A port represents a logical communication
channel between a component and one or
more components its connected to
Ports declare 3 methods specified using
requires, provides, and broadcasts keywords
University of St Andrews

13. ArchJava Language constructs
• Provided method implemented by component
and available to other components connected
to the port
• Required method provided by other
components to this port
• Broadcast methods similar to required
methods but can be connected to any number
of implementations
University of St Andrews

14. ArchJava Language constructs
This port design specifies services
implemented by a component and services
required by a component to do it job
Required interfaces make dependencies
explicit
Ports also make it easier to reason about
components communication patterns
Abstract design allows specification and type
checking before implementation starts
University of St Andrews

15. ArchJava Language constructs
• Connections
Connection consistency checks ensure that
each required method is bound to a unique
provided method
Alternative connection semantics
implemented by writing ‘smart connector’
components
University of St Andrews

16. ArchJava
• Communication integrity
Components in an architecture can only call
each other’s methods along declared
connections between ports
Components are only able to directly invoke
methods of their subcomponents
University of St Andrews

17. ArchJava
• Dynamic architectures
Covered by creating and connecting together
a dynamically determined number of
components
Connected using a connect expression at run
time
A Connection pattern used to describe set of
connections instantiated at run time using
connect expressions
University of St Andrews

18. ArchJava
• Port interface
Describes a port that can be instantiated
several times to communicate through
different connections
University of St Andrews

19. ArchJava
• Removing components and connections
No explicit way to remove components and
connections
Components garbage-collected when they are
no longer reachable through direct references
or connections
University of St Andrews

20. ArchJava
• Communication integrity
All inter-component method calls must follow
the architectural connections
Except method calls from a component to its
children
University of St Andrews

21. ArchJava
• Direct method calls
All direct component calls made from a
sending component instance must be to the
component itself or to its immediate
subcomponent
University of St Andrews

22. ArchJava
• Method calls through ports
a connection pattern in a component allows
method calls between its immediate
subcomponents through connected ports
Uses a two-part test to verify that all method
calls conform to a connection pattern
Every connect expression must match a
connect pattern in the component
University of St Andrews

23. ArchJava
• Limitations
Only applicable to a programs in a single
language and running on a single JVM
Focus on communication integrity doesn’t
support other architectural reasoning such as
connection protocols, architectural styles, or
component multiplicity
University of St Andrews

24. ArchJava
• Evaluation
• Can ArchJava express architecture of a real
program of significant complexity?
• How difficult is it to reengineer a Java
program to express its architecture explicitly in
ArchJava?
• Does expressing a programs architecture in
ArchJava help or hinder software evolution?
University of St Andrews

25. ArchJava
• Hypothesis
Hypothesis 1:
Developers have a conceptual model of their
architecture that is mostly accurate, but this
model may be a simplification of reality, and it
is often not explicit in the code.
University of St Andrews

26. ArchJava
• Hypothesis 2
 Programming languages that prohibit sharing
data between components are too inflexible to
express the natural architecture for many
programs.
• Hypothesis 3
 Describing an existing program’s architecture
with ArchJava may involve significant
restructuring if the desired architecture does not
match the implementation well
University of St Andrews

27. ArchJava
• Hypothesis 4
 Refactoring an application to expose its
architecture is done most efficiently in small
increments.
Hypothesis 5
• Applications can be translated into ArchJava
with a modest amount of effort, and without
excessive code bloat.
University of St Andrews

28. ArchJava
• Hypothesis 6
 Expressing software architecture in ArchJava
highlights refactoring opportunities by making
communication protocols explicit.
• Hypothesis 7
 Using separate ports and connections to
distinguish different protocols and describing
protocols with separate provided and required
port interfaces may ease program understanding
tasks.
University of St Andrews

29. ArchJava
• Hypothesis 8
Communication integrity in ArchJava
encourages local communication and helps to
reduce coupling between components
 Hypothesis 9
An explicit software architecture makes it
easier to identify and evolve the components
involved in a change
University of St Andrews