<- Previous

Next up is one of the most versitile elements of UML Class Diagrams, the "Property" element.

What is a Property?

"Properties are StructuralFeatures that represent the attributes of Classifiers, the memberEnds of Associations, and the parts of StructuredClassifiers."

We've already introduced the concept of "attributes" in the previous lesson. In this lesson, we will dive further into what a Property is, and how a Property serves as an "attribute", a "memberEnd", and a "part".

Property as an "attribute"

At a fundamental level, a Property is a characteristic of a Class, or more accurately, of all the instances of that Class. It's job is to be the state or structure of Classes.

Following our example, we might have decided on a Class named “Screwdriver” to represent our tool. But of course there are attributes about screwdrivers that may be relevant to distinguish one screwdriver instance from another or to simply describe a single screwdriver. For example, you may categorize them by “type” like “Phillips” or “flathead”. You may want to describe them by “handle grip” or whether the metal portion “is magnetized”. Each of these could be added as properties of the “Screwdriver” class.

Properties of a Class are referred to as “attributes” of the Class and appear in the “attributes” compartment of a Class.

Property as a "memberEnd"

A Property can also be one of the ends that take part in an Association. When this happens the Property can be referred to as an “Association end” or as a "member end" of an Association.

"A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not."

Properties that are member ends of a Class can either appear in the “attributes” compartment of a Class or on the opposite end of the Association line.

Property as a "part"

A Property can be a "part" of a Class when values of that Property are meant to be grouped together and are tightly coupled with instances of that Class. We talk about this in terms of "aggregation". When the Property's aggregation is considered to be "composite", values of that Property are strongly tied to the instances of the Class.

What this means further is that values of that Property do not make sense to exist without instances of that Class. So, when the instance of the Class gets deleted, values stored in that Property should also be deleted.

To give a better example, let's consider an order tracking system. Each order is composed of 1 or more items. In this example, we could model it as an "Order" Class with a Property of "orderItems". If one of our users deletes or cancels an Order, does it make sense for the "orderItems" to exist on their own? Probably not. So the "orderItems" Property should be considered a "composite" aggregation, and as such is considered a "part" of the "Order" class.

Property "type"

Each Property has a “type” which determines the valid values or instances that can be assigned to that Property. A Property's "type" appears after to the Property name and a ":" character.

Property "visibility"

A Property has a "visibility" which determines to what level other elements are able to see and access data from that Property. A Property has a visibility of either public, private, protected, or package.

• "public" visiblity means the Property can be seen and accessed from anywhere and is the least restrictive visibility. This is indicated by a "+" sign preceding the Property name.
• "private" visibility means the Property can be seen and accessed only within the Class itself and is the most restrictive visibility. This is indicated by a "-" sign preceding the Property name.
• "protected" visibility means the Property can be seen and accessed within the Class itself and any inheriting Classes. This is indicated by a "#" sign preceding the Property name.
• "package" visibility means the Property can be seen and accessed within the Class itself and any other Class within the Package. This is indicated by a "~" sign preceding the Property name.

Property "multiplicity"

Properties have a "multiplicity" which indicates whether that Property is a single value or a collection of values.

It's "lower" bound indicates a minimum number of values the Property must have and effectively whether the Property is required. And it's "upper" bound indicates a maximum number of values the Property must have and and whether the Property is a collection or single value.

When a Property has a lower bound of "0", a value for that Property is optional. When a Property has a lower bound of "1" a value for that Property is required.

When a Property has an upper bound of "1", a value for that propety is a single value. When a Property has an upper bound of "2", greater than "2", or "*", the Property is a collection. "*" is a special value indicating an unlimited numer of values.

Multplicity value can appear after the "type" of the Property in brackets "[]" or on the opposite end of the association line when the Property is an Association end.

"static" Properties

A Property can be "static". When a Property is static, it characterises the Class itself instead of all of the instances of that Class.

A "static" Property is indicated by it's name being underlined.

"derived" Proprties

A Property can also be derived from other properties or by an operation on that class.

A "derived" Property is indicated by a "/" preceding it's name.

Property "aggregation"

• "none" aggregation means the Property should exist on it's own. This is the default and probably the most common.

  

• "shared" aggregation means the Property has shared aggregation. This is indicated by an open diamond on the end of the association line.

  

• "composite" aggregation means the Property composes parts of the owning Class and coupled strongly with the Class. This is indicated by a filled diamond on the end of the association line.

  

How do you know when to define a new Property?

To find out whether something is or should be a Property when modeling, you can think of the adjectives that might describe an instance of that Class (“expensive”, “large”, “blue”) and then trace back to the category that adjective is describing (“price”, “size”, “color”). Those categories are the properties.

Another method is to think of relevant questions you would ask an instance of that Class if it could give you an answer, (“are you complete or not?”, “how much will it cost?”, “when were you created?”) and then shorten those questions to one or two words (“isComplete”, “cost”, “created”). Those words can also become properties of a Class as well.

Additionally, you might think of the relationships that one instance of a Class may have with other Classes (“friend”, “owner”, “piece”) and those may also be properties of that Class represented as memberEnds.

How do you decide if a Property is "composite"?

The way to figure out if the property is "composite" is to ask the question, "Does it make sense for this thing to exist on it's own or does it really represent a thing that composes something else?' If it doesn't make sense to exist on its own, it's composite. If it does, it's not composite.

Comparison to Object-Oriented Programming Languages

Properties sometimes are referred to as “attribute” or “field” in Object-oriented programming languages and loosely model the same thing.

Abstract Syntax

To illustrate what a Property is, UML provides abstract syntax which we have recreated in UML Class Diagrams.

Next ->