Sparx Systems Forum

Enterprise Architect => Uml Process => Topic started by: sargasso on September 20, 2006, 08:02:21 pm

Title: Stupendiously stumped on Stubs
Post by: sargasso on September 20, 2006, 08:02:21 pm

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

Title: Re: Stupendiously stumped on Stubs
Post by: KP on September 20, 2006, 10:19:03 pm

How does a realization feel? From UML 2.1:

Quote

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

Title: Re: Stupendiously stumped on Stubs
Post by: sargasso on September 20, 2006, 10:39:18 pm

Thanks KP,  

That'll do me!

bruce

Title: Re: Stupendiously stumped on Stubs
Post by: Paolo F Cantoni on September 21, 2006, 06:21:14 am

Quote

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

Title: Re: Stupendiously stumped on Stubs
Post by: thomaskilian on September 21, 2006, 02:25:50 pm

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

Title: Re: Stupendiously stumped on Stubs
Post by: KP on September 21, 2006, 04:16:11 pm

Quote

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?

Title: Re: Stupendiously stumped on Stubs
Post by: Paolo F Cantoni on September 21, 2006, 05:03:43 pm

Quote

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