ImplementationByJD Pack

Implementation• Implementation is required• Impact of architecture• Prescriptive and restrictive

• Gives implementers direction on how to produce, structure, and interconnect code

• Prohibits certain behaviors or states

• Architectural concepts must coincide directly with its implementation, known as mapping

• Software libraries must be shared among many components• Unmaintained mapping results in degradation• Implementation technologies can affect a system both ways

The Mapping Problem• Mapping is a form of traceability• Tool to trace implementations to their architectures

• Purposed for several design decisions• Connectors and Components

• Maintaining mapping between different architectural and software partitions

• Interfaces• Complexity can determine level of implementation required

• Configurations• Linked graphs/interactions must be preserved

• Design Rationale• External documentation/code comments

The Mapping Problem (cont.)• Dynamic Properties (Behavior)

• Formal specifications can lack language-level bindings that can make proper implementation detection challenging

• Non-Functional Properties• Documentation rationale, testing, and user studies • Converting non-functional properties to design decisions

• Models evolve and must be kept in sync• One-way – architecture is updated first• Round-trip – Changed are allowed at both levels

• Round-trip is better at drift/erosion detection, but more complex

Architecture Implementation Frameworks

• Ideally, implementation technologies are selected based upon architectures being implemented• Difficult to achieve due to explicit support and impact of external

factors• Frameworks are a strategy used to connect them together• Standard I/O library (UNIX)

• Bridges pipe-and-filter architectural style with noncurrent languages• Frameworks are not required, but mapping is more difficult to

maintain without it• They often contain implementations for commonly used

components, e.g. user input

Frameworks (cont.)• Multiple frameworks can support various languages, styles,

and operating systems• One arch. style can be supported by many frameworks

• Java.io and C standard library, C++ iostream and C stdio• Multiple frameworks can support the same environment

combinations• Java.nio and java.io

Evaluating Frameworks

• Frameworks can vary greatly based on quality type• Platform Support

• Determine what language and OS should be used based on architectural style

• Fidelity• Choose what design decisions should be implemented directly and what

should be left at the discretion of the implementers• Matching Assumptions

• Frameworks may assume additional constraints upon the system and its components, e.g. multiple inheritance

• Efficiency• A framework might slow down communications between different

components• Other Considerations

• Cost, size, availability, portability, ease of use, etc.

Middleware• Middleware - technologies created to provide services that

may not be included natively with the OS or language• JavaBeans, .NET, Android libraries, CORBA, etc.• Very similar to frameworks• Can induce architectural constraints

• CORBA breaks up applications into objects, which expose their services and methods using IDL

• Referred to as “distributed objects” style

Middleware (cont.)• Two important conflicts can arise between middleware and

frameworks• Architectural style doesn’t match what is needed for the middleware• Designers chose middleware based on services such that it is

inconsistent with the style• Middleware that is chosen may cause undesired architectural drawbacks

such as sync or latency issues

• Solutions include• Changing either style or middleware• Developing glue code• Ignoring unneeded middleware services• Hiding middleware in the components that benefit from it

Using Middleware to Implement Connectors• Middleware packages provide communication services for

components• Can be used as the base for implementing connectors instead of

the entire app itself• Architects should first define the connector capabilities• Middleware can be selected based on how well it fits with the

project• The result allows middleware to be used while ignoring certain

assumptions

Building a New Framework• Reasons why new frameworks must be made• The architecture style is not well-known or is new• The style and platform have no current framework• Existing frameworks are inadequate

• Certain guidelines• Architectural style must be well-understood• Limit framework to address style issues• Decide the scope of the framework• Avoid over-engineering• Limit overhead• Develop a strategy for off-the-shelf resources

Concurrency• Most styles have provisions for dealing with concurrency

issues• For example, pipe-and-filter takes advantage of concurrency to

process partial results in parallel• However, concurrent applications are difficult to program

• Race conditions/deadlock bugs are difficult to locate• Encapsulating concurrent implementations can reduce, but not

eliminate, their risk

Generative Technologies• Idea of generating software implementations directly from

their designs• Deriving implementations from designs is appealing, but

generally difficult and only partial• Generative Strategies• Generation of whole implementations of systems or elements

• Drift and erosion can be eliminated, but requires extensive specifications

• Generation of skeletons or interfaces• Generation of compositions

• Domain-specific software engineering

• One-way vs. Round-trip approach

Ensuring Architecture-to-Implementation Consistency• Create and maintain traceability links• Explicit links/automated link checking can help keep architecture

and implementation consistent• Include the architectural model• The model’s description can contain valuable instantiation and

connection information • Generate implementation from the architecture• Using generation technologies to build at least some or all of the

portions of the implementations using the architecture model

Existing Pipe-and-Filter Frameworks

Standard I/O (stdio) Java.io

Platform Support C Java

Fidelity Programs can utilize their own versions of streams (e.g. GUI)

Comprehensive support that can be ignored

Matching Assumptions

Each filter will be a separate OS process

Native threading support, concurrent filters

Efficiency Dependent upon OS Designed to achieve high efficiency on multiprocessor machines

C2 Frameworks• Must provide asynchronous messaging to match architecture

constraints• C2 components and connections are each partitioned as separate

modules• Developed for many different language/OS combinations

• Lightweight C2 (Java)• 16 classes, 3000 lines• Threading is left up to objects

themselves• Connector/Component classes• ConnectorThread/

ComponentThread classes• Ports

• Not all constraints are enforced by the framework• No support for separate in-

process memory spaces

• Flexible C2 (Java)• 73, classes, 8500 lines• Interfaces

• fundamental concepts rather than abstract classes

• Any base class can be extended by using the proper interface

• Defined queuing policies• Performed using

MessageHandlers and ArchitectureEngines • One-Queue-Per-Interface• One-Queue-Per-App• One-Thread-Per-Brick• Thread Pool• Steppable Engine

Lightweight and Flexible C2Figure 9.1: Lightweight C2 Figure 9.2: Flexible C2

C2 Frameworks (cont.)Lightweight C2 Flexible C2

Platform Support JVM multi-platform JVM multi-platform

Fidelity Does not actively enforce C2 constraints

Does not actively enforce C2 constraints

Matching Assumptions

Components/Connectors must inherit base abstract classes; messages consist of name-value pairs or string names

Must implement required interfaces; serializable messages

Efficiency Small, can be single-threaded but risks deadlock

Many pre-defined threading policies to choose from on an app-by-app basis