Prev | Next |
Package Organization Regimes
As suggested earlier, the librarians, administrators or engineers involved with the set up of the repository can find themselves conflicted about which direction to take because there is a wide range of organizing principles that can be used to structure the contents of the repository. Some of these are:
- A Breakdown structure - Systems | Subsystems | Components | Parts
- Engineering Teams, working on different aspects of a system - Team One | Team Two
- Programs of work and Projects - Program One | Project One, Project Two
- Divisions within a method - Architecture | Requirements | Design
- Security and Access Control
- Ease of Navigation
Any one or any combination of these principles can be used to structure the repository, and they can be changed over time to suit the evolution of the engineering practice and the model usage and experience of the users. Possibly the most difficult of these principles is the need to make the repository friendly to its inhabitants, to ensure ease of navigation so that they can easily find what they are looking for. Enterprise Architect has some useful facilities to reduce this tension, allowing other mechanisms to be used for navigation and freeing the repository design to develop based on a number of the other more important principles. Some of these tool features are listed here.
Model Views
Provide a flexible and powerful mechanism allowing an engineer or team to create any view of the model that they find useful. Using this facility removes the need for modelers and engineers to access the Browser window, as they can locate the elements of interest through the Model Views window.

For example, views can be created based on a search that returns elements from any part of the repository; an engineer could define a view that returned all requirements that were high priority, with the status 'Approved' and flagged as 'Difficult', regardless of which project they were part of or where in the Package hierarchy they were located. Alternatively, a modeler might just cherry-pick particular elements and diagrams of importance to them and include them in a Favorites View, or create a view based on newly created Components. This facility provides a highly flexible mechanism for accessing the important parts of the repository, and views can be created at modeler or team level. We will return to the Model Views facility in a later topic, as it is an extremely useful part of the tool.
Diagram Navigation Cells
Enterprise Architect has made it easy for users to navigate through a repository by providing a powerful diagram mechanism to hyperlink to any diagram in the repository.

This allows librarians and even modelers themselves to create any number of diagrams that act as launch pads that will take a viewer to diagrams of interest, effectively shielding them from needing to know how the repository is structured. These diagrams are viewable through the Internet browser and Cloud products, and provide a compelling experience for casual users and non-modelers.
Search Facility
This is a power feature that provides built-in and user defined searches to retrieve a list of elements or diagrams that meet a specified set of criteria. The amount of information contained in a repository can grow exponentially as more people contribute to the models and information is imported from external sources such as Risks, Policies, Rules, Principles and more. There is a rich and useful set of searches that are defined as part of the product and in many circumstances one of these built-in searches will suffice for a modeler or engineer to locate the elements or diagrams they are looking for. These searches can be parameter driven providing a mechanism to reuse a search to find a variety of elements. For example a search could be written that has a user input parameter of Status allowing users to input a status, for example 'Proposed' at the time the search is run.

Searches can be created by non-technical staff using the intuitive Query Builder but there are also a number of other ways that searches can be created including SQL based queries that do require knowledge of the database tables and Add-in queries that require a technical person to create a program that defines the search. These searches can be used by a number of other facilities including, as discussed earlier, Model Views.