Displaying items by tag: uml

It is no coincidence that the package element in UML is represented by a folder icon, similar to directories in a file system Graphical User Interface (GUI).  Packages are used to organize the elements of a model just as folders are used to organize files.  The contents of a package are any kind of element that is part of a model, including other packages.  Beyond that description there's not much more information on how to use packages in the UML specification.  Since they are a general grouping thing, it is up to usage scenarios to suggest what the best practices are for using packages.  There are some practices that apply in most situations, and more that depend upon the modeling methodology or the purpose of the model.

First and foremost, use packages to organize your model, regardless of the model purpose.  Even the most trivial model quickly becomes unmanageable without some kind of organization.  There is no single correct way to organize a model.  A modeler may choose to organize around process or product or some combination of the two.   Second, use the package diagram to provide visualizations of that organization.   The model browser view below illustrates how even a simple model can begin to be confusing with no organization of the model elements.

 In addition to being able to gather like items together to allow modelers to focus their attention on relevant elements and make those elements easier to find in the browser, packages provide a namespace for the elements they contain.  Namespaces allow modelers to create unambiguous named references to each of the elements in a model.  This is useful in situations such as when a modeler is evolving a system and creating an as-is and a to-be system model.   It is natural to have elements named the same in each model.  In order to disambiguate elements with the same name, they can be placed in different packages so that the fully-qualified names are different.

Packages can be placed on a UML package diagram.  The modeler might choose to do this to present a high-level view of a model or to show relationships among the packages of elements.  Three different package diagrams representing the model organization shown above are presented here.  Each of these diagrams uses the optional diagram frame, showing the diagram type (pkg) and diagram name (Use Case View).  Note that although  the diagram and the package have the same name (Use Case View) this is not required.  In the first diagram, the two high-level packages are shown.  As with many other modeling situations, only the details we need are presented, and the details of the package contents are elided.

In the second diagram, the packages contained in the Actors package are shown.  The labels on the Human and Non-Human package describe the namespace of the containing package.  The containment relationship also serves to describe the namespace.  In this example, the fully qualified name of the Actor Operator is Use Case View::Actors::Human::Operator.

In the third diagram, the contents of the packages are shown embedded in the package elements.  This representation is the third presentation option found in the UML specification.

Your package diagrams will in all likelihood be some combination of each of these styles, as will your choice of organizing principles.  Choose the one that is appropriate for its intended use. 

LieberLieber is proud to announce a new and free Enterprise Architect plug-in called EnArValidationRules essential for all Enterprise Architect users who want to validate their models with individual and customizable validation rules. In addition, it provides the possibility to auto-correct any errors and warnings that occur, based on the pre-defined validation rules.

Key features:

• Validate your models and diagrams
• Enable/Disable each validation rule
• Activate auto-correction for each rule
• Backup your models automatically

As depicted in the screenshot, we have defined different rules for demonstration purposes. For example, the total account of elements for each package or diagram is limited to a certain number. Furthermore, it is only allowed to use instances of classes within a sequence diagram. And each element has to realize at least one requirement or test case. Of course, these rules can be adopted and extended.

You can download this free plug-in here.

If you are interested in more rules for your modeling projects, do not hesitate to contact sales(at)lieberlieber(dot)com.

With commitment and appreciation,

The UML is a popular modeling notation for programmers, but it is little used by database developers. Nevertheless, the UML is highly effective for high-level conceptual data modeling. The UML notation avoids confusing database details, making it easier for business experts to understand data models. The suppression of details promotes deep thinking about data models, such as the use of abstract patterns. This talk explains the UML notation by comparison to IDEF1X.