This article will teach you about UML structural diagrams, used to help you keep track of the structure of your models. It was excerpted from chapter three of Fast Track UML 2.0, written by Kendall Scott (Apress, 2004; ISBN: 1590593200).
An analysis-level class diagram typically shows attributes; it may show other adornments such as multiplicity and role names as well. An analysis-level diagram, though, shouldn’t have operations, because deciding where to put what operations definitely falls into the design arena. (See Use Case Driven Object Modeling with UML2 for more on this topic.)
Figure 3-2 shows an example of an analysis-level class diagram.
Figure 3-2. Analysis-level class diagram
This is clearly an early version of this diagram, because there will certainly be more attributes for PurchaseOrder, GLAccount, Order, and Account, as well as a full set of attributes for the other classes. The point is that class diagrams evolve as knowledge of the domain being modeled grows.
Note the term {encrypted} that is attached to the Account attribute password. This is a user-defined constraint that indicates that the password undergoes encryption before being stored in the system. This is something of a design decision, but since this decision exists at the attribute level, it makes sense to go ahead and include the constraint on a class diagram at this level of precision.
