Stupendiously stumped on Stubs

[sargasso]

Total cranial implosion   :-/

I am trying to develop a component model for this new job and show explicitly where some components are replaced by "stubs" in the test bed.  For example, the component "SWIFT EMS" is replaced by the "SWIFT Message Simulator" component.

Any one got a idea of what the "correct" connector what I should use is?   "Delegate" looked promising but its not that.

bruce

[KP]

How does a realization feel? From UML 2.1:

A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form in respect to a certain modeling context.

You actual code is the specification (i.e. supplier) and your stub code is an implementation of the specification (i.e. client).

[sargasso]

Thanks KP,  

That'll do me!

bruce

[Paolo F Cantoni]

How does a realization feel? From UML 2.1:
You actual code is the specification (i.e. supplier) and your stub code is an implementation of the specification (i.e. client).

Guys,

I would have said both codes (the stub and the full) implementations are Realizations of the Interface.

I mean, isn't that the point of the stub?

My AU$0.05
Paolo

[thomaskilian]

I'd say that the stub DEFINES the interface while the implementation REALIZES it. IOW stub = socket symbol, implementation the box.

[KP]

I would have said both codes (the stub and the full) implementations are Realizations of the Interface.

I mean, isn't that the point of the stub?

Certainly for a class model, but Bruce is building a component model. Wouldn't that detail be better hidden at the component level?

[Paolo F Cantoni]

I'd say that the stub DEFINES the interface while the implementation REALIZES it. IOW stub = socket symbol, implementation the box.

Well, in the general case, many stubs contain some limited functionality, and there may be many stubs (aka "Mocks") (see Domain Driven Design forums).  For example, an in memory mock, an XML based mock, the full code - all implementing a Data Transfer Component interface.

From a modeling perspective, I feel it's better to define the interface and then provide a variety of "mocks" up to to the full implementation.

Also, taking this route opens up the possibility of many full implementations, each technology specific.

Paolo