How best to structure model files?

[nickbrown1968]

I think I'm getting myself into a bit of a pickle with my modelling. I started with a single model file for all the systems in our company. We're relatively small so this seemed like the right way to go. After all that's the best way to capture the whole enterprise, surely? I can re-use elements. I can see the existing relationships for elements and understand how existing systems may be impacted by new designs. All good. Except it's all gotten a little messy. I'll try and explain how.

I'm generating a lot of relationships that make sense in the context a particular viewpoint, but not when viewed in the model as a whole. There a few ways this can come about:

- Temporal/State: I might model as-is, transition and to-be states. The relationships between elements are defined for each state. I might re-use an element in another viewpoint, look at the visualiser and see all these relationships. When viewed this way there's no context so they all look like as-is dependencies.
- Business context: I have a "Broker" role. It is assigned to a number of business processes when working with a particular team and a slightly different set of processes when working with a different team. Again, when I see the model in the visualiser, I see all these relationships that are only really valid within context.
- Derived relationships: For simplicity, some viewpoints benefit from using derived relationships. I've added these manually, but there's no specific way that they are distinguished as derived. Again, when I visualise the model, probably in another context, I then see all these relationships.

Not sure if I've articulated the problem well, but I'm beginning to think I should create separate model files for each piece of work/context. It may mean that I have to model components, but my model will be less "cluttered". But what is the best way to partition my model files? By project? By business unit?

I'd be interested to know how other people manage their model files.

[romuald]

Hi,

As I understand :

- Temporal/State : It's normal to have all the links from past to futur. When futur become present, it's your duty to remove the past link in the model

- Business Context : Well, your 'broker' role has all the business process. View with team A may not be view with team B. But the proket has all the business process

- Derivated relationship : I have the same issue. I had a lot of relationship to see this. Why? Because if Application A needs Application B wich needs Application C then A needs C. And there is no simple way to see this relation A-C if you do not put it in the model.

[rchevallier]

For derived relationship, 2 different ways I have been using to distinguish from primitive ones:

1) I add the "/" in the name to indicate a derived relationship
2) I add a property "derived" = true to the relationship