Skip this Video
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 19

Implementation - PowerPoint PPT Presentation

  • Uploaded on

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

PowerPoint Slideshow about 'Implementation' - dana

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