Building systems from off the shelf components


Published on

Building systems from off the shelf components

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building systems from off the shelf components

  1. 1. Building Systems from Off-the-Shelf Components Dr. Himanshu Hora SRMS College of Engg. & Tech., Bareilly INDIA
  2. 2. Building Systems from Off-the-Shelf Components: • Systems are being constructed with more and more off-the-shelf components, for economic reasons and because the expertise needed in many technical areas is so specialized. • Quality attributes can be maintained in a system, even if that system is largely integrated from the-off- shelf components whose design and interaction mechanisms are not under the architecture.
  3. 3. Cont… • The requirements process needs to be more flexible, allowing what is available in the marketplace to modify the requirements to provide a better overall business solution. • For systems built from off-the-shelf(OTS) components, component selection involves a discovery process, which seeks to identify assemblies of compatible components,. • Understand how they can achieve the desired quality attributes, and deciding whether they can be integrated the system being built.
  4. 4. Architectural Mismatch • Not all components work together- even if they are commercial products that claim compatibility. • Components that were not developed specifically for your system may not meet all of your requirement. • Architectural mismatch usually shows up at system integration time-the system will not compile, will not link, or will not run.
  5. 5. Cont… • What can you do about interface mismatch? Besides changing your requirements so that yesterday’s bug is today’s feature there are three things: I. Avoid it by carefully specifying and inspecting the components for your systems. II. Detect those case you have not avoided by careful qualification of the components. III. Repair those cases you have detected by adapting the components.
  6. 6. Techniques For Repairing Interface Mismatch • The alternative to changing the code of one or both mismatched components is to insert code that reconciles their interaction in a way that fixes the mismatch. • There are three classes of repair code: I. Wrappers II. Bridges III. Mediators
  7. 7. Cont..  Wrappers: • The term wrapper implies a form of encapsulation. • We can interpret interface translation as including: • Translating an element of a component interface into an alternative element. • Hiding an element of a component interface. • Preserving an element of a component’s base interface without change.
  8. 8. Cont…  Bridges: • A bridge translates some requires assumptions of one arbitrary component to some provides assumptions of another. • The key difference between a bridge and wrapper is that the repair code constituting a bridge is independent of any particular component.
  9. 9. Cont…  Mediators: • Mediators exhibit properties of both bridge and wrappers. • The major distinction between bridges and mediators is that incorporate a planning function.
  10. 10. Techniques For Detecting Interface Mismatch • Discovering all of the requires assumptions of the components for each of the services that will be used by the system. • Making sure that each requires assumption is satisfied by some provides assumption in the system.
  11. 11. Techniques For Avoiding Interface Mismatch • One technique for avoiding interface mismatch is to undertake, from the earliest phases of design a disciplined approach to specifying as many assumptions about a component’s interface as feasible. • Assumptions stated assertions about the sufficiency of the services provided by each module and the implement ability of each service by identifying resources necessary to the module.
  12. 12. Model problem workflow • An illustration of the model problem workflow is shown in Figure. The process consists of the following six steps that can be executed in sequence: I. The architect and the engineers identify a design question. II. The architect and the engineers define the starting evaluation criteria.
  13. 13. Cont… III. The architect and the engineers define the implementation constraints. IV. The engineers produce a model solution situated in the design context. V. The engineers identify ending evaluation criteria. VI. The architect performs an evaluation of the model solution against the ending criteria.
  14. 14. Thank You Dr. Himanshu Hora SRMS College of Engg. & Tech., Bareilly INDIA