Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Implementing Architectures Software Architecture

Foundations, Theory, and Practice Software Architecture 2 Objectives Concepts u Implementation as a mapping problem u Architecture implementation frameworks u Evaluating frameworks u Relationships between middleware, frameworks, component models u Building new frameworks u Concurrency and generative technologies u Ensuring architecture-to-implementation consistency Examples u Different frameworks for pipe-and-filter u Different frameworks for the C2 style Application u Implementing Lunar Lander in different frameworks

Foundations, Theory, and Practice Software Architecture 3 Objectives Concepts u Implementation as a mapping problem u Architecture implementation frameworks u Evaluating frameworks u Relationships between middleware, frameworks, component models u Building new frameworks u Concurrency and generative technologies u Ensuring architecture-to-implementation consistency Examples u Different frameworks for pipe-and-filter u Different frameworks for the C2 style Application u Implementing Lunar Lander in different frameworks

Foundations, Theory, and Practice Software Architecture 4 The Mapping Problem Implementation is the one phase of software engineering that is not optional Architecture-based development provides a unique twist on the classic problem u It becomes, in large measure, a mapping activity Maintaining mapping means ensuring that our architectural intent is reflected in our constructed systems Design Decisions Implementation Artifacts

Foundations, Theory, and Practice Software Architecture The Mapping Problem – More Specifically Components  ? u classes, packages, modules, … Connectors  ? u software buses, message services; what else? Interfaces  ? u API signatures; what about protocols? Configurations  ? u interfaces, function pointers, reflection Design rationale  ? u comments, documentation Behavior  ? u how do we translate FSP, StateCharts, Z, etc. to code? NFPs  ? u indirectly via rationale, inspections, testing, user studies, … SWE 622 – Distributed Software Engineering © Malek,

Foundations, Theory, and Practice Software Architecture 6 Common Element Mapping Components and Connectors u Partitions of application computation and communication functionality u Modules, packages, libraries, classes, explicit components/connectors in middleware Interfaces u Programming-language level interfaces (e.g., APIs/function or method signatures) are common u State machines or protocols are harder to map

Foundations, Theory, and Practice Software Architecture 7 Common Element Mapping (cont’d) Configurations u Interconnections, references, or dependencies between functional partitions u May be implicit in the implementation u May be externally specified through a MIL and enabled through middleware u May involve use of reflection Design rationale u Often does not appear directly in implementation u Retained in comments and other documentation

Foundations, Theory, and Practice Software Architecture 8 Common Element Mapping (cont’d) Dynamic Properties (e.g., behavior): u Usually translate to algorithms of some sort u Mapping strategy depends on how the behaviors are specified and what translations are available u Some behavioral specifications are more useful for generating analyses or testing plans Non-Functional Properties u Extremely difficult to do since non-functional properties are abstract and implementations are concrete u Achieved through a combination of human-centric strategies like inspections, reviews, focus groups, user studies, beta testing, and so on

Foundations, Theory, and Practice Software Architecture 9 One-Way vs. Round Trip Mapping Architectures inevitably change after implementation begins u For maintenance purposes u Because of time pressures u Because of new information Implementations can be a source of new information u We learn more about the feasibility of our designs when we implement u We also learn how to optimize them Design Decisions Implementation Artifacts

Foundations, Theory, and Practice Software Architecture 10 One-Way vs. Round Trip Mapping (cont’d) Keeping the two in sync is a difficult technical and managerial problem u Places where strong mappings are not present are often the first to diverge One-way mappings are easier u Must be able to understand impact on implementation for an architectural design decision or change Two way mappings require more insight u Must understand how a change in the implementation impacts architecture-level design decisions

Foundations, Theory, and Practice Software Architecture 11 One-Way vs. Round Trip Mapping (cont’d) One strategy: limit changes u If all system changes must be done to the architecture first, only one-way mappings are needed u Works very well if many generative technologies in use u Often hard to control in practice; introduces process delays and limits implementer freedom Alternative: allow changes in either architecture or implementation u Requires round-trip mappings and maintenance strategies u Can be assisted (to a point) with automated tools

Foundations, Theory, and Practice Software Architecture 12 Architecture Implementation Frameworks Ideal approach: develop architecture based on a known style, select technologies that provide implementation support for each architectural element Design Decisions Database Software Library OO Class

Foundations, Theory, and Practice Software Architecture 13 Architecture Implementation Frameworks This is rarely easy or trivial u Few programming languages have explicit support for architecture-level constructs u Support infrastructure (libraries, operating systems, etc.) also has its own sets of concepts, metaphors, and rules To mitigate these mismatches, we leverage an architecture implementation framework

Foundations, Theory, and Practice Software Architecture 14 Architecture Implementation Frameworks Definition: An architecture implementation framework is a piece of software that acts as a bridge between a particular architectural style and a set of implementation technologies. It provides key elements of the architectural style in code, in a way that assists developers in implementing systems that conform to the prescriptions and constraints of the style. FrameworkFramework

Foundations, Theory, and Practice Software Architecture 15 Canonical Example The standard I/O (‘stdio’) framework in UNIX and other operating systems u Perhaps the most prevalent framework in use today u Style supported: pipe-and-filter u Implementation technologies supported: concurrent process-oriented operating system, (generally) non- concurrent language like C Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; ｩ 2008 John Wiley & Sons, Inc. Reprinted with permission.

Foundations, Theory, and Practice Software Architecture Another Example

Foundations, Theory, and Practice Software Architecture More Specifically

Foundations, Theory, and Practice Software Architecture Architecture - DEMO class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture (“DEMO”); // create components Component a = new Component (“A”); Component b = new Component (“B”); Component c = new Component (“C”); // create connectors Connector d = new Connector(“D”); // add components and connectors arch.addComponent(a); arch.addComponent(b); arch.addComponent(c); arch.addConnector(d); // establish the interconnections arch.attach(a, d); arch.attach(b, d); arch.attach(d, c); } } Architectural Structure Comp BComp A Comp C Connector D Comp AComp B Comp C

Foundations, Theory, and Practice Software Architecture Architecture - DEMO Component B handles the event and sends a response public void handle(Event e) { if (e.equals( “ Event_C ” )) {... Event e1= new Event( “ RSP_to_C ”, REPLY); e1.addParameter( “ response ”, resp); send(e1); }... } Send (e1) Architectural Interaction Component C sends an event Event e = new Event ( “ Event_C ”, REQUEST); e.addParameter( “ param_1", p1); send (e); Send (e) Comp BComp A Comp C Connector D

Foundations, Theory, and Practice Software Architecture 20 More on Frameworks Frameworks are meant to assist developers in following a style u But generally do not constrain developers from violating a style if they really want to Developing applications in a target style does not require a framework u But if you follow good software engineering practices, you’ll probably end up developing one anyway Frameworks are generally considered as underlying infrastructure or substrates from an architectural perspective u You won’t usually see the framework show up in an architectural model, e.g., as a component

Foundations, Theory, and Practice Software Architecture 21 Same Style, Different Frameworks For a given style, there is no one perfect architecture framework u Different target implementation technologies induce different frameworks stdio vs. iostream vs. java.io Even in the same (style/target technology) groupings, different frameworks exist due to different qualitative properties of frameworks u java.io vs. java.nio u Various C2-style frameworks in Java

Foundations, Theory, and Practice Software Architecture 22 Evaluating Frameworks Can draw out some of the qualitative properties just mentioned Platform support u Target language, operating system, other technologies Fidelity u How much style-specific support is provided by the framework? Many frameworks are more general than one target style or focus on a subset of the style rules u How much enforcement is provided?

Foundations, Theory, and Practice Software Architecture 23 Evaluating Frameworks (cont’d) Matching Assumptions u Styles impose constraints on the target architecture/application u Frameworks can induce constraints as well E.g., startup order, communication patterns … u To what extent does the framework make too many (or too few) assumptions? Efficiency u Frameworks pervade target applications and can potentially get involved in any interaction u To what extent does the framework limit its slowdown and provide help to improve efficiency if possible (consider buffering in stdio)?

Foundations, Theory, and Practice Software Architecture 24 Evaluating Frameworks (cont’d) Other quality considerations u Nearly every other software quality can affect framework evaluation and selection Size Cost Ease of use Reliability Robustness Availability of source code Portability Long-term maintainability and support

Foundations, Theory, and Practice Software Architecture 25 Middleware and Component Models This may all sound similar to various kinds of middleware/component frameworks u CORBA, COM/DCOM, JavaBeans,.NET, Java Message Service (JMS), etc. They are closely related u Both provide developers with services not available in the underlying OS/language u CORBA provides well-defined interfaces, portability, remote procedure call… u JavaBeans provides a standardized packaging framework (the bean) with new kinds of introspection and binding

Foundations, Theory, and Practice Software Architecture 26 Middleware and Component Models (cont’d) Indeed, architecture implementation frameworks are forms of middleware u There’s a subtle difference in how they emerge and develop u Middleware generally evolves based on a set of services that the developers want to have available E.g., CORBA: Support for language heterogeneity, network transparency, portability u Frameworks generally evolve based on a particular architectural style that developers want to use Why is this important?

Foundations, Theory, and Practice Software Architecture 27 Middleware and Component Models (cont’d) By focusing on services, middleware developers often make other decisions that substantially impact architecture E.g., in supporting network transparency and language heterogeneity, CORBA uses RPC u But is RPC necessary for these services or is it just an enabling technique? In a very real way, middleware induces an architectural style u CORBA induces the ‘distributed objects’ style u JMS induces a distributed implicit invocation style Understanding these implications is essential for not having major problems when the tail wags the dog!

Foundations, Theory, and Practice Software Architecture 28 Resolving Mismatches A style is chosen first, but the middleware selected for implementation does not support (or contradicts) that style A middleware is chosen first (or independently) and has undue influence on the architectural style used Strategies u Change or adapt the style u Change the middleware selected u Develop glue code u Leverage parts of the middleware and ignore others u Hide the middleware in components/connectors Use the middleware as the basis for a framework

Foundations, Theory, and Practice Software Architecture 29 Hiding Middleware in Connectors Comp 1 Comp 2 Async Event Comp 1 Comp 2 RPC (thread) Architecture Implementation

Foundations, Theory, and Practice Software Architecture 30 Building a New Framework Occasionally, you need a new framework u The architectural style in use is novel u The architectural style is not novel but it is being implemented on a platform for which no framework exists u The architectural style is not novel and frameworks exist for the target platform, but the existing frameworks are inadequate Good framework development is extremely difficult u Frameworks pervade nearly every aspect of your system u Making changes to frameworks often means changing the entire system u A task for experienced developers/architects

Foundations, Theory, and Practice Software Architecture 31 New Framework Guidelines Understand the target style first u Enumerate all the rules and constraints in concrete terms u Provide example design patterns and corner cases Limit the framework to the rules and constraints of the style u Do not let a particular target application’s needs creep into the framework u “Rule of three” for applications

Foundations, Theory, and Practice Software Architecture 32 New Framework Guidelines (cont’d) Choose the framework scope u A framework does not necessarily have to implement all possible stylistic advantages (e.g., dynamism or distribution) Avoid over-engineering u Don’t add capabilities simply because they are clever or “cool”, especially if known target applications won’t use them u These often add complexity and reduce performance

Foundations, Theory, and Practice Software Architecture 33 New Framework Guidelines (cont’d) Limit overhead for application developers u Every framework induces some overhead (classes must inherit from framework base classes, communication mechanisms limited) u Try to put as little overhead as possible on framework users Develop strategies and patterns for legacy systems and components u Almost every large application will need to include elements that were not built to work with a target framework u Develop strategies for incorporating and wrapping these

Foundations, Theory, and Practice Software Architecture 34 Concurrency Concurrency is one of the most difficult concerns to address in implementation u Introduction of subtle bugs: deadlock, race conditions… u Another topic on which there are entire books written Concurrency is often an architecture-level concern u Decisions can be made at the architectural level u Done carefully, much concurrency management can be embedded into the architecture framework Consider our earlier example, or how pipe-and-filter architectures are made concurrent without direct user involvement

Foundations, Theory, and Practice Software Architecture 35 Generative Technologies With a sufficiently detailed architectural model, various implementation artifacts can be generated u Entire system implementations Requires extremely detailed models including behavioral specifications More feasible in domain-specific contexts u Skeletons or interfaces With detailed structure and interface specifications u Compositions (e.g., glue code) With sufficient data about bindings between two elements

Foundations, Theory, and Practice Software Architecture 36 Maintaining Consistency Strategies for maintaining one-way or round-trip mappings u Create and maintain traceability links from architectural implementation elements Explicit links in a database, in architectural models, in code comments can all help with consistency checking u Make the architectural model part of the implementation When the model changes, the implementation adapts automatically May involve “internal generation” u Generate some or all of the implementation from the architecture

Foundations, Theory, and Practice Software Architecture Example Frameworks Intended for highly distributed and dynamic systems Many aspects shared with other styles u explicit topological rules u components u connectors u asynchronous messages Some unique aspects u substrate independence u context-reflective connector interfaces A D CB Requests Notifications

Foundations, Theory, and Practice Software Architecture Framework Objectives Traceability Platform independence Distribution Dynamism Efficiency Observability Extensibility

Foundations, Theory, and Practice Software Architecture Framework API Architecture Architecture() Architecture(name : String) Architecture(name : String, n : int) start() : void stop() : void shutdown() : void handle(r : Request) : void handle(n : Notification) : void addComponent(comp : Component) : void addConnector(conn : Connector) : void weld(conn : Connector, comp : Component) : void weld(comp : Component, conn : Connector) : void weld(conn1 : Connector, conn2 : Connector) : void removeComponent(comp : Component) : void removeConnector(conn : Connector) : void setThreadCount(n : int) : void getThreadCount() : int threadFunction() : void notifyArchitecture() : void searchFIFO(f : SynchronizedFIFO, o : Object) : Object Component Component(name : String) Component() Component(name : String, junk : String) send(r : Request) : void send(n : Notification) : void ComponentThread ComponentThread() ComponentThread(s : String) run() : void Connector Connector() Connector(name : String) handle(r : Request) : void handle(n : Notification) : void ConnectorThread ConnectorThread(n : String) Message Message() Message(name : String) name() : String addParameter(parameterName : String, parameterValue : Object) : void hasParameter(Name : String) : boolean removeParameter(Name : String) : void getParameter(Name : String) : Object Notification Notification() Notification(Name : String) Request Request() Request(Name : String)

Foundations, Theory, and Practice Software Architecture Initial Framework Design – C2 Architecture FIFOPort IPort Notification Request ComponentThread Semaphor #sem ConnectorThread #sem topOutFilterInclude[] Connector Brick Component Message Port #belongs_to #link #top #bottom componentList connectorList outputBuffer inputBuffer topComponents bottomComponents

Foundations, Theory, and Practice Software Architecture Evaluation of C2 Traceability u design decisions map to style elements, rules, and rationale Platform independence u implemented in Java JVM, C, C++, and Ada Distribution u encapsulated inside “border connectors” Dynamism u leverages context-reflective connectors Efficiency u 2000 SLOC; loads in under 5KB Observability u only by tapping into port message queues Extensibility u only via PL mechanisms (e.g., inheritance)

Foundations, Theory, and Practice Software Architecture Framework Optimizations – oC2 Component BComponent A D R 1 N 1 R 2 R 3 N 2 send Request handleRequest ConnectorC Thread Pool R XR

Foundations, Theory, and Practice Software Architecture Evaluation of oC2 Traceability u faithful to the style’s structural, topological, and data aspects u departure from the style’s behavioral and interaction aspects Platform independence u implemented in Java JVM, J2ME, and EVC++ Distribution u encapsulated inside “border connectors” Dynamism u leverages context-reflective connectors u central message queue improves control over dynamic change Efficiency u 1800 SLOC; loads in under 1.5KB Observability u hampered by the centralized message queue Extensibility u hampered by the centralized message queue

Foundations, Theory, and Practice Software Architecture Framework Extensibility – xC2 IArchitecture NotificationRequest ConnectorThread IScaffold IComponent ComponentThread Serializable IConnector Component #top #bottom ArchitectureEventConstants Brick Address +topId +bottomId Message ArchitectureConnector

Foundations, Theory, and Practice Software Architecture Evaluation of xC2 Traceability u departure from the style in implementing all of its key aspects u extensive use of OO interfaces Platform independence u implemented in Java JVM, J2ME, EVC++, and Python Distribution u encapsulated inside “border connectors” Dynamism u leverages context-reflective connectors u central message queue improves control over dynamic change u supports component mobility Efficiency u 1500 SLOC; loads in under 2.5KB Observability u facilitated by IScaffold interfaces Extensibility u IScaffold remove thread management from Architecture u symmetric treatment of components and connectors

Foundations, Theory, and Practice Software Architecture Evaluation Two benchmarking applications 1 component above 1 below 50 components above 1 below 100,000 messages Intel Pentium III 500MHz, 256MB, JDK 1.4 beta 2, Windows 2000 Shared API Implementations in numerous PLs Communication across PL implementations Hundreds of applications built to date Allow integration of non-C2 compliant components *