Implementing Software Architecture
• Software architecture is a set of principal
design decisions; thus it is both:
– Prescriptive:
• Gives “direction” on what to implement
– Restrictive:
• Gives guidelines and constraints
- How do software implementers benefit from the software architecture ?
- How do we ensure that the architecture is maintained through:
a) development cycle into the implementation?
b) multiple product versions?
Architectural “Mapping”
Architectural
Representation
Architecture
mapping
mapping
Implementation
Code
The “mapping” from architecture to implementation comes in
at least 2 stages if not more, with every stage presenting a
potential for drift, erosion, misinterpretation, omission, etc.
Mapping of Architecture to “Detailed” Deign
• Recall -- Architecture (via Perry & Wolf) has:
– Elements :
• Components (processing, data, connecting) and
• Connectors (interfaces)
– Form:
• Static Configuration & Interfaces
• Dynamic Flow & Properties --- at multiple levels
– Rationale:
• Design Comment/Explanation
• Non-Functional Properties
Items to Consider in Mapping to Code &
Potential “Mapping Problems”
• Components and Connectors:
– How are these “partitioning” decisions mapped into code (into classes,
packages, methods, etc. )?
• Interfaces:
– How are architectural specification of interfaces mapped into code
interfaces (into method calls, communications protocols, etc.)?
• Configurations:
– How are “statically” linked graph of components and connectors
reflected into the “dynamically” executing code (especially dynamical
linking during execution such as polymorphism and run time binding)?
• Design Rationale:
– How do we map this? --- into “comments” in source code?
• Dynamic Properties and Behavior:
– How are these functional specifications mapped into code --- assuming
programming language has the constructs – e.g. JAVA has exception
processing with “throw” or parallelism with “threads”
• Non-Functional Properties:
– How do we map properties, such as security or usability, to actual
code (this may be the most difficult for mapping) ?
Architecture Implementation Framework
• The “ideal” situation is to develop the software architecture first and
then select the implementation techniques and tools.
However, the ideal approach often run into real problems
when the programming language or underlying middleware
or operating system do not allow a clear mapping from
architecture to the code.
• One strategy is to use an “architecture implementation framework”
An architecture implementation framework is a piece of software that
acts as a bridge between an architecture style and a set of
implementation technology/code. It provides the “key elements” of the
architecture (in code form) in a manner that assists the developers to
conform to the prescriptions and restrictions of the architecture.
** We may need multiple frameworks to support the same architectural style.
(e.g. for different programming languages or different operating systems)
** We may have to develop this framework ----- only in “large enterprises”
- common
components
- connectors
- interfaces
in a library ?
Criteria for Evaluating Frameworks
• Platform support: what (i)operating system (ii) programming
languages and (iii) arch style are supported.
• Fidelity: how strictly (faithfully) does the framework adhere to
the prescriptive and restrictive portions of the architectural style.
(How much of the “architecture’s decisions” are supported?)
• Matching assumptions:
– a) how well the framework matches other parts of the system
or other assumptions of the implementation technology and
tools; (does it create “conflicts” with other parts?)
– b) how well does the framework implement the desired
architectural style
• Efficiency: how much extra inefficiency is introduced by the
framework (e.g. performance degradation for “strict layers”)
• Other: cost, quality, availability of source code, portability, etc.
Middleware and Frameworks
• There are many execution tools that “integrate”
software components and provide services beyond
compiler and operating & are often “called”:
–
–
–
–
Framework
Middleware
Connectors
etc.
• Some common ones are:
–
–
–
–
–
–
CORBA
MS Component Object Model (COM)/ DCOM
MS.NET
Java Enterprise Edition (from Oracle)
PHP-SQL tools such as Xampp
SOA tools
Architectural Framework is a “middleware” software that focuses
on architecture style
Mismatches between Middleware and
Architecture Style
1. The chosen architectural style does not
match what is supported by the ( or any)
middleware
2. The chosen middleware provides services
that are not compatible with the architecture
style
Architecture
Style
compatible?
compatible?
Architecture
Framework
(middleware)
Options to Resolve Mismatches
(architecture .vs. Framework)
Should choose the architectural style first ---- then find the matching framework
•
•


Change the architecture style to fit the framework -- NO
Change the framework to fit the architecture - - OK
Develop “glue” code to get around the mismatches
Ignore the extra services, if the mismatch is extra code
in the framework
• Hide the framework into some specific component or
connector, if the framework is only used in certain
specific area of the architecture -- OK
Most of the time the framework or middleware package is used for
communication among components; thus acts as a super connector
or as the “bus”. One would then focus on the “bus” architecture to
ensure that it fits the original software system architecture.
Mismatches may lead to “building” your own
Framework
• Building a framework should be a last resort unless you are in the
software framework business such as Google, IBM or Microsoft.
But you may consider it if:
– The architectural style is novel and new (only time I would do it)
– The architectural style is not implemented on the platform of choice
– The existing frameworks are just inadequate and you must have one
• Points to consider when developing a framework:
–
–
–
–
Understand the architectural style well
Limit the framework to only the desired architectural style
Choose the scope of the framework
Avoid over-engineering of functionalities and properties; also limit the
overhead needed
 Build it with the notion of re-use by others (this may conflict with scoping and
over-engineering) --- also consider, integration with some existing/external
components that were not developed with any framework
 As more and more systems are distributed and run on multiprocessors, one
characteristic of interest is “Concurrency” and “Multi-threading” in the framework
“Code Generation” Technologies
• Instead of just the “bus” framework to help the
software development effort, one may consider a
complete generation of software from architecture
model. (extremely difficult and don’t have this yet.)
 Generation of the software application skeleton (this
already exists in the form of application frameworks
for small software).
 Compose pre-developed components and connectors
by generating “glue” code from the architectural
model (this exist in primitive form for some specific
software packages such as SAP)
With all these possibilities, we still need to ensure that the “implementation
of architecture is “consistent’”with the original architecture/ architectural model
Frameworks for Pipe-and-Filter Architecture Style
• Standard I/O from C Programming: # include <stdio.h>
– Included as a header file for C compiler to provide the library of
I/O functionalities, such as getchar( ), putchar( ), scanf( ) and
printf( ) for keyboard input and screen output
– This library of code :
• Platform: Is supported wherever C compiler is supported
• Fidelity: comprehensive and strictly for stream I/O support
• Matching assumptions: yes - each filter is supported as a
separate “process” by the underlying operating system; this
allows input stream to be coming in at the same time some
processing of the input stream can occur simultaneously.
• Efficiency: implementation of the stdio.h library provides
concurrency - if the underlying operating system provides it.
Frameworks for Pipe-and-Filter
Architecture Style
• Java.io package from the standard library: import
java.io.*
– Imported as a package of classes that provide I/O related
functionalities such as File, Scanner, and PrintWriter
– Java programming language and compiler provides multithreading and a fuller set of functionalities such as buffering
and error exception
• Platform: is supported wherever Java compiler is supported
• Fidelity: comprehensive and strictly I/O support
• Matching assumptions: yes, especially with multi-threading
support in Java
• Efficiency: Java provides more direct control over the processes
such as buffering and concurrency
A C2 (Component & Connector) Style “Implementation”
[sample Classes from C2 Lightweight Framework]
Recall, C2 is a layered networks of concurrent components connected together by
message routing connectors , abiding to the top of component hooked to bottom of
connector and other connection rules. Component-component direct communication
is disallowed. Also, Iport, buffering provided by this framework is not part of C2.
1
Architecture
1
1
Ccomponent
<<abstract>>
1
top 0..
0.. *
*
0.. *
Iport
<<interface>>
Brick
<<abstract>>
0.. *
0.. *
1
top
Connector
<<abstract>>
1
bottom
bottom
1
ComponentThread
<<abstract>>
Note: Aggregation of Iports may be parts of
connector or parts of component
Port
<<abstract>>
weld
ConnectorThread
<<abstract>>
1
FifoPort
1
0.. *
0.. *
Note the difficulty in checking the
architectural “constraints” with this
diagram
Message
Name: string
Properties: map
Request
0.. *
Notification