Implementing Software Architecture Software architecture is a set

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 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? 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 Print. Writer – 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 C 2 (Component & Connector) Style “Implementation” [sample Classes from C 2 Lightweight Framework] Recall, C 2 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 C 2. 1 Architecture 1 1 Ccomponent <<abstract>> 1 top 0. . * * 0. . * bottom Iport <<interface>> Brick <<abstract>> 0. . * weld Connector. Thread <<abstract>> 1 1 0. . * Note the difficulty in checking the architectural “constraints” with this diagram Connector <<abstract>> 1 bottom Port <<abstract>> Fifo. Port 1 top 1 Component. Thread <<abstract>> Note: Aggregation of Iports may be parts of connector or parts of component Message Name: string Properties: map Request 0. . * Notification