Recommendation for organizing a project

Hi community,

I’d like to know how a project could be best organized.

We have over 20 use case diagrams, we get more and more requirement diagrams and we have already some class, activity and sequence diagrams. The number of diagrams is increasing. It is like with most projects, I guess.

Should we use the logical view or should we create overview diagrams? I think it would be good if I could assume that even a new team member could understand the project and find his or her way through the diagrams. Are there some samples regarding this topic?

BTW: How should the logical view get properly used at all? I assume that this is a or the major view. Is it?


Hi Robert,

Thanks for your post. I suggest create “Models” or packages in Model Explorer to manage your diagrams and elements. When you create Model/package in Model Explorer, you can create diagrams as sub-diagrams of the Model/package, and the models created on the sub-diagrams will be under the Model/package. This approach will help you manage the model structure in the project, also help you manage the models in difference phases of development. Having a good management of model elements will definitely helpful for finding out the models you need in the project.
You can get more details of how to make use of Model/package for model structure management from the following flash movie:

BTW, when you want to know which diagram(s) the models exist, you can right-click on the model in Model Explorer and select Show View in the popup menu. For details, please visit:

The logical View is for grouping the diagrams only, it won’t let you to view the elements on the diagrams or tell you the model structure. Therefore creating Models and packages in Model Explorer will be a better approach for managing your model elements.

Please feel free to ask if there is any further inquiry.

Best regards,
Lilian Wong

Thank you so far.

So this could be called a model-oriented approach? Is this even model-driven design/development or does that mean something different?

I still wonder how I could structure things, also in the model explorer. FYI, we already have a software that we’re currently trying to map to VP. We’re doing a reverse engineering in order to reimplement our software later. Therefore it could be that I have an affected perspective. So, if I use the model explorer and I’d like to arrange our elements, how should it be done? Currently we have use cases and requirements. In this stage there shouldn’t be any components, as I think. So should I have just a ‘folder’ with unstructured elements, e.g. for the requirements? The elements could be grouped, but with packages or models? Or with diagrams? Or anything else?

Do you think the model changes during a project? Ok, I don’t expect that you say No. What I mean is that in the begining requirements, use cases, crc cards and what not are grouped somehow, maybe in groups like ‘our requirements’, ‘our use cases’ and so on. Later the requirements will be moved into the according components, i.e. the models or packages. So later you would have a model that is mainly structured into components.

Could you provide an example? At least an example that shows how a model could be structured. Ideally a VP project file, but some text showing the hierarchie would be also okay.

It would be also interesting to know what you think about overview diagrams. Would you recommend them to document the project? Are they a good mean to give an overview? Or is the model explorer or the logical view the better choice?

I have to say that I’m missing a documentation of how to use VP the reasonably. The provided documentation does not say much about this. Some hints would be helpful. I hope you can give me (and others) some a bit more detailed information. It would help us a lot.

Thank you once again,

Hi Robert,

Thanks for replying. This is not model-driven but object-oriented approach. Once you use a model to model something, it can be said as mode-driven. But object-oriented focuses on object (a kind of model) and features of the object, it’s more specific than model-driven approach.

Before take a look at the details of using Model, you can watch the following flash movie which gives a real example of managing model elements of a business process: is Model.html

And attached is a sample VP project which can be a result project of the flash movie, and you can take a look at the attached image for what’s those Models and packages stand for.

At this point, I would like to clarify the different between Model and package:
Both Model and package can be used for grouping model elements. Model describes the abstraction of physical system with certain purpose, which determines what is to be included in the model and what is irrelevant. Package provides a namespace for the grouped elements in code engineering.

Definitely models may change during modeling, and you can change the model structure according to the changes or phases of development. Within Model Explorer, you can not only create Models/packages and create sub-diagrams for them, but also move the models among the Models/packages for changing the model structure.
With a good management of Models, packages and model element, your team members can understand the purposes/function of the model elements in the development.

During modeling of project, you may have different perspective and require different approach to present. A diagram can help you to present how models are related; Overview Diagram can show the relationship between diagrams, but cannot show the model structure or how models are related; Model Explorer displays the model structure in your project.

Hope the flash and sample project gives you a clearer mind of how to make use of the Model Explorer with Models and packages. Please feel free to contact me if you have any further inquiry.

Best regards,
Lilian Wong


Hi Robert,

I would like to remind you that you may need to increase the volume of your headphone/speaker as the flash movie is with voice in small volume.

Best regards,
Lilian Wong

Thank you, but I noticed this already :slight_smile:

Could you please have a look into your private messages?


Hi Robert,

Thanks for replying. I just replied your message and please check your private message.

Best regards,
Lilian Wong

I still don’t get the difference between the model explorer and the logical view.

We would like to keep no structure in the model explorer => easy to find everything back

And create different logical views for the diagrams.

I understand it well that the model explorer is for subsystems (with interfacing to use elements of other subsystem)
the logical view is to provide functional views regardless the fact if the diagrams are in the same of different systems.

It would be nice if there were some guidelines how to use the diagram explorer (per diagram type) the model explorer (elements per subsystem) and the logical view (diagrams per functional domain).

I would be nice to be able to see the list of elements in a logical view and to which subsystems the belong.

Any help would be appreciated