Predavanje10.SA.kreiranje Na Sistemi So Koristenje Na Gotovi Komponenti

7/30/2019 Predavanje10.SA.kreiranje Na Sistemi So Koristenje Na Gotovi Komponenti

1/27

SCSITV Semester

Architecture and Design of SoftwareSystems


2/27

.

.

.


3/27

,

.

.

.


4/27

:

.

.

backup plan


5/27


6/27


7/27

.

.

, .

,

.


8/27

interface.

API ,

. ,

.


9/27

What can we do aboutinterface mismatch?

Besides changing your requirements sothat yesterday's bug is today's feature(which is often a viable option), there

are three things: Avoid it by carefully specifying and

inspecting the components for yoursystem.

Detect those cases you have not avoidedby careful qualification of thecomponents.

Repair those cases you have detected byadapting the components.


10/27

TECHNIQUES FOR REPAIRINGINTERFACE MISMATCH

To date, mismatch correction (or"component/interface repair") hasreceived little systematic attention

Often repairing interface mismatches isseen as a job for hackers

One obvious repair method is to change

the code of the offending component. However, this is often not possible,

given that commercial products seldomarrive without their source code.


11/27

Even if possible, changing acomponent is often not desirable

If it is used in more than one system?

The alternative to changing the codeof is to insert code that reconcilestheir interaction in a way that fixes

the mismatch.

There are three classes of repaircode: wrappers, bridges, and

mediators.


12/27

Wrappers

Wrapper implies a form ofencapsulation whereby somecomponent is encased within analternative abstraction

It simply means that clients accessthe wrapped component services only

through an alternative interfaceprovided by the wrapper


13/27

We can interpret interface translationas:

Translating an element of a componentinterface into an alternative element

Hiding an element of a componentinterface

Preserving an element of a component'sbase interface without changes


14/27

Bridges

A bridge translates some requiresassumptions of one arbitrary componentto some provides assumptions of another

The key difference between a bridge anda wrapper is that the repair codeconstituting a bridge is independent of

any particular component. Bridges typically focus on a narrower

range of interface translations than dowrappers because bridges address specific

assumptions


15/27

Mediators

Mediators exhibit properties of bothbridges and wrappers

The major distinction between bridgesand mediators, however, is thatmediators incorporate a planningfunction that in effect results in runtime

determination of the translation A mediator is also similar to a wrapper

insofar as it becomes a more explicitcomponent in the overall system

architecture


16/27

TECHNIQUES FOR DETECTINGINTERFACE MISMATCH

We present the process of identifyingmismatches as an enhanced form ofcomponent qualification.

determining whether a commercialcomponent satisfies various "fitness foruse criteria

Component qualification processesinclude prototype integration ofcandidate components as an essentialstep in qualifying a component.


17/27

Evaluation starts with the observationthat, for each service offered by acomponent, a set of requiresassumptions must be satisfied inorder to provide that service

The assumptions list may reveal more

interesting dependencies


18/27

TECHNIQUES FOR AVOIDINGINTERFACE MISMATCH

Specifying as many assumptionsabout a component's interface asfeasible

Private interfaces

Parameterized interface

Negotiated interface


19/27

Component-Based Design asSearch

The architect must determine if it isfeasible to integrate the componentsin each ensemble

Furthermore, it needs to evaluatewhether an ensemble can live in thearchitecture and support system

requirements. In effect, each possible ensemble

amounts to a continued path of

exploration


20/27

The simultaneous exploration ofmultiple paths is expensive

Some flexibility in systemrequirements is beneficial in theintegration of component-basedsystems

But it is also important to recognizewhen a requirement is essential to thesuccess of the system and to not allow

these requirements to be compromised


21/27

To evaluate the feasibility of acomponent ensemble, including itsability to support the system's

desired quality attributes, we usemodel problems

model problem is a description of the

design context, which defines theconstraints on the implementation

A prototype situated in a specificdesign context is called a modelsolution


22/27

A model problem may have anynumber of model solutions,depending on the severity of risk.

Model problems are normally used bydesign teams

Optimally, the design team consists

of an architect who is the technicallead on the project and makes theprincipal design decisions


23/27

The process consists of thefollowing six steps

The architect and the engineersidentify a design question

The architect and the engineersdefine the starting evaluationcriteria

The architect and the engineers

define the implementationconstraints.


24/27

The engineers produce a modelsolution situated in the designcontext.

The engineers identify endingevaluation criteria

The architect performs an

evaluation of the model solutionagainst the ending criteria


25/27


26/27

Summary

Quality attributes can be maintainedin a system, even if that system is largelyintegrated from off-the-shelf components

However, achieving quality attributes inthis type of system requiressignificantly different practices thanfor custom-developed code

The requirements process needs to bemore flexible, allowing what is availablein the marketplace to modifyrequirements to provide a better overall

business solution


27/27

Essential requirements need to beidentified and introduced as a criticalconstraint in the evaluation offeasible component ensembles

Multiple contingencies need to beconsidered, and as essential

requirements increase in number anddifficulty, custom development mustbe considered as a fallback.

Documents

Predavanje10.SA.kreiranje Na Sistemi So Koristenje Na Gotovi Komponenti