Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When learning about these tools, I (naively) thought that mapping about the business space could be front loaded by doing it only once and refering to those diagrams for each project within a single business unit. However, I am finding that each situation is calling for it's own set of diagrams to properly communicate what's going on. I find that I am dealing with the same objects, but the relationships change.

My first thought to these different situations was that these were sort of disposable* diagrams as they only pertain to a very narrow scope within the business, but I quickly retracted that thought once I found myself scrambling to find the same ER diagram I disposed 3 months ago in a completely different situation. So now I am getting a sence that they are not disposable and should be kept, but I want to avoid just a stack of seemingly contradicting UML and ER diagrams so that someone behind me can make sense of it all. Any suggestions?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

An approach that works well is to seperate model content (the objects), and the different views (diagrams). This has worked for me:

  1. Create a package for each group of objects or problem domain (e.g. Customers, Products, Finance ...)

  2. Create a package for each purpose where you will draw a diagram (e.g. ProductManagementView)

  3. Add the objects to the diagram, including all relationships.

If there are view-specific attributes and relationships that you want to capture seperately, create subpackages and use UML's hierarchy/association/dependency constructs to create specific-objects.

E.g. your model may look like this:

 Model
   +- Customer <<package>>
        +- Customer <<entity>>
        +- Address <<entity>>
        +- CustomerService <<package>>
           +- CustomerService <<entity>> -is a-> Customer (+ supportContract attribute)
           +- SupportContract <<entity>>
   +- Product <<package>>
        +- Product <<entity>>
        +- ProductGroup <<entity>>
   +- ProductManagementView
        +- ProductManagementDiagram <<diagram>>
   +- CustomerServiceView
        +- CustomerServiceDiagram <<diagram>>
share|improve this answer
    
Very interesting, this is exactly what I was looking for. –  hydroparadise Dec 28 '12 at 19:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.