Implementation - PowerPoint PPT Presentation

1 / 19

  • Uploaded on
  • Presentation posted in: General

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript




JD Pack



  • 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

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

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

    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

    Frameworks (cont.)

    • Multiple frameworks can support various languages, styles, and operating systems

      • One arch. style can be supported by many frameworks

        • and C standard library, C++ iostream and C stdio

      • Multiple frameworks can support the same environment combinations

        • Java.nioand

    Evaluating frameworks

    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 - 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

    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

    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

    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



    • 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

    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

    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

    Existing Pipe-and-Filter Frameworks

    C2 frameworks

    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 MessageHandlersand ArchitectureEngines

          • One-Queue-Per-Interface

          • One-Queue-Per-App

          • One-Thread-Per-Brick

          • Thread Pool

          • Steppable Engine

    Lightweight and flexible c2

    Lightweight and Flexible C2

    Figure 9.2: Flexible C2

    Figure 9.1: Lightweight C2

    C2 frameworks cont

    C2 Frameworks (cont.)

  • Login