I define Multiplicity (also called Cardinality) as the rule that states how many instances of one element may relate to another. I use it in class diagrams. For example, I use it to show how many orders a customer may place. Moreover, I use it to show how many values an attribute can hold. Therefore, multiplicity clarifies structure and reduces ambiguity.
First, I explain the notation. For this, I use simple symbols. For example, I write 1 to mean exactly one. Next, I write 0..1 to mean zero or one. Then, I write 0..* or * to mean zero or many. After that, I write 1..* to mean at least one. Moreover, I write n..m to mean a specific range. Thus, the notation tells lower and upper bounds. In addition, I can use an exact number like 3 to mean exactly three.
Second, I apply multiplicity to associations. For example, in a book-ordering model, I state that 1 customer places 1..* orders. Consequently, a customer may place many orders over time. In the same model, I can set that an order contains 1..* books if business rules require at least one book per order. However, I can also set an order to contain exactly one book if I want to simplify the scenario. Moreover, I list multiplicity at each end of the association. Therefore, stakeholders see how many objects may or must relate to the other object.
Third, I use multiplicity for attributes. For example, I write firstName: string [1] to mean one first name. However, I avoid using multiplicity to express string length. Indeed, the UML fragment firstName:string[20] means twenty first names, not a string length of twenty. Therefore, I define a special data type or add a textual constraint when I need to limit the length of a string.
Furthermore, I handle special cases. For instance, I model a person with exactly one residence address and exactly one correspondence address. Hence, I set multiplicities that reflect both required and optional roles. In addition, I mark derived attributes with a leading slash when the value derives from other values. For complex constraints, I use OCL or textual requirements for precision and clarity.
Next, I offer practical tips. First, I ask stakeholders whether a relation may be optional, mandatory, single, or multiple. Second, I prefer explicit ranges over vague labels. Third, I document ambiguous cases using textual requirements or stereotypes. Finally, I test multiplicities against real use cases to ensure they match rules.
Because multiplicity affects data persistence and business logic, I treat it as a key part of requirements modeling. As a result, I avoid miscommunication about system behavior. Moreover, I align multiplicity choices with glossary definitions and data models. Thus, I help the team implement the correct constraints during design and development.
In short, I use multiplicity to define counts of related objects or values. I use clear notation. I add textual constraints when needed. Consequently, I make models easier to understand and easier to translate automatically.