There is an object (Visio calls it a “master shape”) in the Static Structure template for creating these, aptly named binary association.ĭrag that onto the page, and connect the two classes for which you wish to show a relationship. The relationship shown above is called a binary association, because it shows the association between two classes. Showing Relationships With Visio’s UML Stencil First, we’ll cover the steps in visio for creating the relationship shown above. We’ll talk more about relationships in a bit. The business wants to know where to send bills for the customer. That is the relationship between the customer and the address. The customer receives bills at an address. How do we show a relationship between a customer and an address? A credit rating is a property of a customer. The distinction is one of design, but generally speaking, if the concept stands on its own, it should be its own class. That feels bad, from a design standpoint. If we were to represent an address as attributes of a customer, we would have to include each of the “sub attributes” as a separate attribute of customer. That is a good indicator that it is likely to be a class of its own. But an address is a compound object made up of multiple attributes.Īn address can have multiple lines of street address information, as well as city, state, zip code and country information. One way to make a distinction is to say that if an attribute has other attributes, it should be a class. How do you know when something should be an attribute, and not another class? In our example above, think about Customer and Address and Credit Rating. And customers have addresses and credit ratings. When a stakeholder cares about a concept, idea, or thing, we represent it as a class. In it, we presented the notion of a class.
We started this discussion of class diagrams last week. That understanding prevents mistakes in interpreting requirements. Using a class diagram to supplement other requirements documents provides for a centralized reference that enables a shared understanding of the problem domain.
Drawing these relationships can dramatically clarify requirements documents.
We continue our exploration of UML Class Diagrams with this article that explores how to represent basic business relationships in a class diagram.
0 kommentar(er)
