Implementation By JD Pack Implementation Implementation is required

Implementation By JD 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 • Java. Beans, . 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

C 2 Frameworks • Must provide asynchronous messaging to match architecture constraints • C 2 components and connections are each partitioned as separate modules • Developed for many different language/OS combinations

• Lightweight C 2 (Java) • 16 classes, 3000 lines • Threading is left up to objects themselves • Connector/Component classes • Connector. Thread/Component Thread classes • Ports • Not all constraints are enforced by the framework • No support for separate inprocess memory spaces • Flexible C 2 (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 Message. Handlers and Architecture. Engines • • • One-Queue-Per-Interface One-Queue-Per-App One-Thread-Per-Brick Thread Pool Steppable Engine

Lightweight and Flexible C 2 Figure 9. 1: Lightweight C 2 Figure 9. 2: Flexible C 2

C 2 Frameworks (cont. ) Lightweight C 2 Flexible C 2 Platform Support JVM multi-platform Fidelity Does not actively enforce C 2 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 appby-app basis