لطفا منتظر باشید ...
Hints and Tips
When you model packages in the UML, remember that they exist only to help you organize the elements of your model. If you have abstractions that manifest themselves as objects in the real system, don't use packages. Instead, use modeling elements such as classes or components. A well-structured package
- Is cohesive, providing a crisp boundary around a set of related elements.
- Is loosely coupled, exporting only those elements other packages really need to see, and importing only those elements necessary and sufficient for the elements in the package to do their job.
- Is not deeply nested, because there are limits to the human understanding of deeply nested structures.
- Owns a balanced set of contents; relative to one another in a system, packages should not be too large (split them up if necessary) or too small (combine elements that you manipulate as a group).
When you draw a package in the UML,
- Use the simple form of a package icon unless it's necessary for you to explicitly reveal the contents of that package.
- When you do reveal a package's contents, show only elements that are necessary to understand the meaning of that package in context.
- Especially if you are using packages to model things under configuration management, reveal the values of tags associated with versioning.
