Is an external data base an Actor

[henke]

Hi
I'm modeling a system, "A", that should be able to (among other things) import customer information from an other system "B". The A system will be able to access the data base of the "B" system directly not through any interface in the "B" system. Should I model the "B" system as an actor to the "A" system, orh should I just write in the use case description that the system is importing data from an external data source?

Thanks in advance!
/Henke

[thomaskilian]

Henke,
the external Database is an Actor. Everything outside your System (bejond the boundary) is an actor if it's interacting via a Use Case. Depending on what the Use Case is (definitely not "Exchange Data"  ) place your actor "System B" near the Use Case and set the relation from Actor to Use Case (if the System is sending data eventually) or vice versa (if the Use Case is started from another Actor and the data exchange occurs somewhere within the Use Case).

[sargasso]

OFF TOPIC
One has to wonder about the wisdom of not going through an interface to the system B database.  If the schema changes to suit some requirement of system B the stability of A is broken.
By imposing an interface on system B (or by producing an external interface component, say iAB), the stability is retained and encapsultation is better.  However, in that case, the interface may be modelled in your system A models, thus making system A more than an actor!

JM2CW

Bruce

[thomaskilian]

Bruce,
imagine System B is a human. In that case your interface would likely be a GUI. If System B is a system then you have some kind of program interface. Both, GUI and program interface, you would place in the domain model in order to show what kind of data are exchanged and which methods you use. However, person an machine would be modeled as Actor in the Use Case model.

(BTW: public const answer = 42)

[sargasso]

True  (infer not enough coffee).

What I was mumbling about was modelling the interface not the db.  

If system B were human and the interface was a GUI then the interface would lie in the bounds of the system A, as you say!  However, if system B were human and the interface lay within that system - say a bionic ear, then attributes of the system are "of interest" to this model and system B may well be modelled as a facet of this system, rather than an actor.

However, this is a very obscure case, and I'm probably wrong anyway ... as you say.

IMO the interface "belongs" to the component that publishes the information - as that component is responsible for rendering the information in a format suitable - syntactically, if not semantically - for the component receiving the information.  BTW this is true wheter or not there is an "interface machine" in the middle.  The only requirement the recipient can place on the publisher is syntax - semantic content was, is and shall (ever) be in the domain of the publisher.  

So, in henke's situation what I'm saying is that system B is the publisher - it has the ownership of the interface.  ...  and to cut a long story short ... since the interface is "of interest" to System A, we may choose to include it in our modells.

That's all....  mumble mumble ....



Brucce

[thomaskilian]

Hi Bruce,
probably this is a philosophic question. Of course the interface "belongs" to System B (the outside). You would model it somewhere outside and just use it inside the system. The difference is: who is responsible for the interface. GUI: System A; Bionic Ear: System B. However, from the Use Case view you would always model System B as Actor. In the first case this Actor will (passively) use the GUI interface. In the second case it will (actively) supply its Bionic Ear interface.

So for Henke's example: System B is (still) an Actor and it additionally will supply it's interface for the domain model, where it can be used as usual.

But: suppose System B is also in a state of development. Then you may design the interface (as you do with GUI) inside your model and bring these requirements to
System B.

I guess an interface is not simply something that is designed inside a class - period. An interface is something to communicate to the outside. It is designed by requirements from outside - ellipsis. In practice you will use the interface or make assumptions about it and then you eventually have to change it. That's life.

[sargasso]

That's what I was trying to say!  
B