Modeling which BPs a system implements

[seanassurant]

What it is the accepted way of modeling a software system and the (high level) business process(es) that it performs.

Example: I have a system called SuperMax written in C#, running in an IIS host process. I have a node (?) on my component diagram that represents SuperMax.

I have some business processes defined elsewhere in my business process library. SuperMax implements a few of them, it handles 'Customer Management', 'Fulfillment', 'CRM Data Feed' lets say.

Do I create a composite (i.e. drag the BPs onto the node) ?
Or have simple links to the BPs on the diagram and use connectors (implements?) ?

Any recommendations / best practices would be great.

Thanks.

[Geert Bellekens]

Hi,

Usually there are some more levels of abstraction between the nodes (which are usually machines) and the high level business processes.
There are many variations possible but one of them could be

• High Level Business Process <-- contains
• Subprocess (*) <-- is realised by
• UseCase <-- is specified in
• Collaboration <-- Uses classes and interfaces contained in
• Component <-- is deployed on
• Node

But off course there is nothing preventing you from creating a trace link (I would use a dependency with stereotype <<trace>>) between your Node en the Business process, if those are the only levels you have in your model
[/list]

[bioform]

Nicely described... and I would add as a note that all of the functional requirements (and sometimes NFRs) would be associated most likely with the use cases (and/or the domain elements, UIs, etc.) thus enabling end to end traceability...

Hmm... of course you could knit into that the  Stakeholder's needs which would lead to the solution features, which lead are traced to the use cases, which can be linked to the test cases.... Oh oh... <struggling to put the lid back on that can of worms!>

David