UML Modelling – Part I. 20 General Rules How to Make Good UML Model

For many years I have been interested in modelling of information systems as an analyst and as a developer too. I participated in many projects where UML was used for drafting, system specification and as programming language as well. Here you can find some general UML modelling rules which might be helpful for you:

  1. Do not mix structural, dynamic, physical and model management artifacts
  2. Write entity model (in analytical view) and class model (in design view)
  3. Always create a pre-analysis model (primary UCs, main entities) first, then try to sketch base structure of your model
  4. Use simple and unique model element and diagram identifiers (Use Cases UC123, Use Case Diagrams UCD123, Class Diagrams CD123, …)
  5. Use full names of all elements – don’t use shortcuts!
  6. Do not mix different languages in one model
  7. Always write a glossary
  8. Do not use aliases, unless it is necessary
  9. Try to find the most suitable terms to name and describe model elements (your terms will be used throughout the whole project history)
  10. Create your own templates and patterns – AND USE IT
  11. Do not misuse UML specification
  12. Do not model well-known information (to model something everybody knows – it makes no sense)
  13. Make your model traceable (link-related elements)
  14. Use stereotypes to categorise elements of the model for your own project needs
  15. Don’t draw, if writing textually can be faster – always take the shortest way
  16. Refactor your model after every iteration, if possible
  17. Try to explain all key information in one place – don’t forget that your model is being read by other people without having your know-how
  18. Define default and recommended diagram types for your model (for example AllUseCases, AllClasses, AllDependencies for every package)
  19. Don’t draw diagrams with more than 15 elements (if neccessary, hide noncritical attributes)
  20. Define your project modelling conventions and recommendations and try to adhere to them (and your team too)

It’s obvious that UML is very weak and it is used in different ways depending on project needs and needs of project analysts or developers. The most important is to define long-term sustainable and within the project team generally acceptable rules for modelling of a system in order to avoid model’s opacity, needlessness or its general uselessness and unmaintainability through consecutive project’s history. Except for specific cases (if the model is a key design spec for critical projects or if the model is also a runnable code) the time necessary for modelling should not exceed 10-15 percent for system prototyping and 0-10 percent for change requirements of the total time necessary for their realization.  In the case the time period for model realization and updating exceeds the aforementioned percentages you are on a wrong way resulting to a decrease of your development process agility and to an increase of personnel and funding costs for realization of the requirements, new functionalities and adjustments of your project.

Requirement Engineering, Business Analysis, Agile, Analysis and Design with UML, Java/J2EE, Liferay, Javascript, Embedded C++, MDD, Executable UML, Project Management