A Package is first something like a directory and may contain other packages, use case views, class views, component views and deployment views, and dependencies, in any order :
A package allows also to indicate where the code must be produced by the generator for each language, and to specify the C++ and Php namespace / Java package / Python package / Idl module. A generator producing code for a component looks at the package containing the component view where is the component to get these information.
The project is in fact the top level package.
The packages stereotyped profile define a profile, refer to the chapter profile.
The relation between packages are dependencies and inheritances. Because here the inheritance is very soft, A inherits on B when A contains a class inheriting an other one defined in B, BOUML accept that circular inheritances.
The project and package menus appearing with a right mouse click on their representation in the browser are something like this, supposing them not read-only nor deleted :
|
project menu |
(non project) package menu |
import project allows to import a BOUML project into the current package as a standard package with its contain. Note that the imported project's default settings are not imported. It is not possible to import a project formated by a release of BOUML less than 1.3, then to import an older project you have to reformat it. To do this, load the project to import with a release greater or equal to 1.3, edit the project package, hit Ok (BOUML doesn't check if something is really modified) then save the project.
Allows to import a project as a library. A project imported as a library can't be modified in the importing project, but it can be updated to follow changes done in the imported project. In case the project imported as library contains others projects imported as library this ones are not considered like that, this means you can't update these sub projects separately but you have to ask for to update the container project you directly imported. This feature is dedicated to use projects defining libraries, not to work at several on the same project, for that see Project control and Project synchro
To update a project imported as a library to take into account all the changes done since the last update ot the initial importation. To simplify management you can't update a project imported as library while the project is modified, this means you have to save first your project or to reload it to forget changes you don't want, and at the end of the update the project is saved, so you can't undo an update.
edit allows to show/modify the project/packages properties with the following dialog (here Php is not selected in the top level menu Languages, so its tab is not visible) :
The project's name cannot be changed through this dialog, use save as in the project menu.
The stereotype of the project and packages doesn't have a special meaning for BOUML.
The editor button visible above and associated here to the description, allows to edit the description in an other window, or to call an external editor (for instance Xcoral) specified through the environment dialog. Note that this external editor have to create an own window, its parameter is the pathname of the file containing the description, its execution is done in parallel with BOUML which looks each second at the file contents to get the new definition until the dialog is closed (I do not like very much this polling but this works even QT isn't compiled with the thread support).
The C++, Java, Php, Python and Idl tabs (visible only i these languages are all set in the Languages menu) allow to specify the directory where the generation are made and the namespace/package/module :
When a directory specification is empty, the generation is made in the directory specified through the last tab of the generation settings dialog. As it is mentioned in the dialogs, in case a root directory is specified through the generation settings dialog, the directory specifications in the three dialogs above may be relative, the directory(ies) used by the code generators will be the root directory collapsed with the appropriate relative directory. This allows to move all the generated files changing only one path.
When a namespace/java package/python package/module specification is empty, the generated code will not be placed in a namespace/package/module (!), else you have to specify the full namespace/package/module specification : this allows to have a browser's package tree different than the namespaces/packages/modules imbrication.
For instance in case the C++ namespace is mynamespace, the generated code will be placed in the namespace mynamespace (!). In case the C++ namespace is mynamespace::subnamespace::subsubnamespace, the generated code will be placed in the namespace subsubnamespace itself nested in the namespace subnamespace itself nested in the namespace mynamespace. In Java and Python the separator is a “.” rather than “::”. In Idl the separator is “::”.
This entry is only available in the project's menu. Allows to set a default stereotypes list for some kinds of object, the dialog's tab associated to the packages is :
As you can see, it is possible to set a default stereotypes list for the packages and the dependency relation starting from a package. In the lists the stereotypes must be separated by a space.
The stereotypes import and from are specially known by the Python generator and allow to add import and from .. import * forms.
As you can see, this setting allows to set a default visibility at the UML level for the attributes, relations and operations. This setting may be redefined in nested packages and class views. At the project level you have to choose between public, protected and private, elsewhere you may also choose default, this means that the visibility of the upper level is followed (which itself may be default etc ... up to the project level). When you create a new package or class view the visibilities are set to default.
The biggest menu in BOUML, used to specify a default definition/declaration for all the generated forms. This entry is only available in the project's menu, for the package point of view the associated dialog's tab is the last one named Directory :
This one allows to specify a root directory where the generations will be made, this the possibility to change it at each package level as it was previously said. This root directory may be relative to the project. The browse buttons call a file browser.
To specify through regular expression the files and / or directories whose must not be taken into account during a reverse and roundtrip, for instance to bypass test programs :
This dialog allows to specify how the diagrams must be drawn by default, at the package level you may specify all the drawing settings because a package may contain indirectly all the kinds of diagram. Except at project level you may choose default for each value, in this case the effective value if specified in the upper level (which itself may specify default etc ... up to the project level).
Refer to drawing for the settings concerning the packages.
To specify the default geometry to use for the dependencies, inheritances, other associations, flow and transitions in the diagrams :
The default geometry is followed when you create the relation / flow / transition or because it is automatically added in a diagram because draw all relation is set. To change the default geometries doesn't affect the already drawn relations / flows / transitions. The default geometries are global to the project.
Allows to import the generation settings (except the specification of the base directories) or the default stereotypes from an other project.
The delete entry is only present when the package is not read-only. Note that this entry is proposed even the package cannot be deleted because a children at any sub-level is read-only or referenced by a read-only relation, these cases are checked when you ask for the deletion for performance purpose (else the menu may take too many time to appears).
Delete the package and all its children, and all the representation of them in the opened diagrams. After that it is possible to undelete them (from the browser) until you close the project : obviously the deleted items are not saved !
To know who are the packages referencing the current one class through a relation.
See mark
It is possible to put a lock on a class or an artifact. A locked element cannot be modified editing it nor roundtriped, and there is no code generation for it. When you put/unput a lock on a class it is also put/unput on its sub classes and on the associated artifact and all the other classes associated to this artifact and their sub classes. When you put/unput a lock on an artifact it is also put/unput on the associated classes and their sub classes. It is also possible to put/unput locks recursively from a package, a class view and a deployment view.
To generate the C++/Java/Idl code of all the sub-items. To generate C++/Java/Idl code for all the project, do it at the project level or through the Tools menu. Note that the generators does not re-write a file when it is not necessary, to not change the last modification date of the files for nothing, make will appreciate !
Refer to C++ generator, Java generator, Php generator, Python generator and Idl generator for more details.
To reverse sources placing the result into the current package.
Refer to C++ reverse, Java reverse, Java catalog , Php reverse and Python reverse for more details.
The menu entry tool is only present in case at least a plug-out may be applied on the project/package.
When a package is drawn in a diagram, the available options are :
package name in tab : to indicate if the package's name must be written in the tab which is the small rectangle on the top :
show classes and packages context : to indicate if the context where the package is defined must be written, it is not the case just above. The context may be the “UML context” which is the path of the package in the browser (choice followed for awt below), or the C++ / Php namespace specified by the package, or the Java package specified by the package (choice followed for picture below), or the Python package specified by the package or at least the Idl module :
show stereotype properties : to indicate through a note the (non empty) value of the stereotype properties in case the package is stereotyped by a stereotype part of a profile. By default the stereotype properties are hidden.
package color : when you create a new project, the packages are transparent by default.
In all the diagrams, a package may be resized.
If the package is stereotyped by a stereotype part of a profile and this stereotype has an associated icon, this icon will be used unchanged when the scale is 100% else it is resized.
When you move a package in a diagram, the artifacts, classes, components, deployment nodes, sub-packages and use cases defined in the package (not through an other one) and in collision with the package at the beginning of the move are also moved. If you want to also move the connected elements, do a very short move (for instance use the keyboard arrows to do a move and its opposite) then ask for select linked items and restart the move. Note : contrarilly to the states when you resize a package the sub-elements are not moved to stay in it.
A right mouse click on a package in a diagram calls the following menu :
the add related elements menu allows to add elements having a relation with the current element, the following dialog is shown :
The drawing settings concerns only the picture for which the menu is called.
set associated diagram allows to automatically open the current diagram when a double mouse click is made on the package representation in a diagram or the browser. After that the only way to edit the package is to choose the edit entry in the menu.
Previous : browser items
Next : use case views
