1 / 19

Implementation

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

dana
Télécharger la présentation

Implementation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementation By JD Pack

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

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

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

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

  6. 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.nioand java.io

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

  8. Middleware • 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

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

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

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

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

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

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

  15. Existing Pipe-and-Filter Frameworks

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

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

  18. Lightweight and Flexible C2 Figure 9.2: Flexible C2 Figure 9.1: Lightweight C2

  19. C2 Frameworks (cont.)

More Related