Because requirements and implementation technologies are complex and constantly changing, a language must not only facilitate communication about a subject, but also enable us to better manage change and complexity when we communicate about the subject. A language is based on a paradigm, a way of viewing a subject, that defines the types of concepts that may be used in the language and the principles of why they are useful. A language's syntax specifies the notation used for communication and is determined by the language's alphabet. A language's semantics specify the meaning that is communicated and is determined by the language's words and sentences. The syntax of the UML involves diagrams, and its semantics are based on the object-oriented paradigm.
To communicate using a language, we must understand its alphabet, how its alphabet is used to form words, and how its words are used to form sentences. We must also understand the concepts and principles of its underlying paradigm.
An alphabet defines the simplest parts of a language: letters, characters, signs, and marks. For example, the English language has 26 letters. The UML's alphabet consists of symbol fragments (rectangles, lines, and other graphical elements) and strings of characters. These don't have meaning by themselves; the smallest units of meaning in a language are its "words."
A word is a grouping of elements from a language's alphabet that defines a unit of meaning. For example, the English language has various words, including "project," "manager," "team," "lead," "execute," and so forth. In the UML, words belong to two broad categories or types:
Concepts are shown as solid-outline rectangles or symbols labeled with a name.
Relationships between concepts are shown as line paths connecting symbols labeled with a name.
In addition to their names, concepts and relationships may have other strings of characters attached to them specifying other information.
Figure 2-1 shows various concepts identified from the project management system requirements by focusing on nouns, including Project, Manager, Team, Work Product, Requirement, and System.
Likewise, Figure 2-2 shows various relationships identified from the project management system requirements by focusing on verbs, including Manage, Lead, Execute, Input, and Output.
You would not normally show all these relationships in isolation as in Figure 2-2, but would combine them with the concepts shown in Figure 2-1. When you combine relationships with concepts, you are really combining UML words to form UML sentences.
A sentence is a grouping of words from a language's vocabulary that defines a grammatical unit of meaning containing a subject and an expression about the subject. A language's grammar specifies the rules for combining words to form sentences. For example, the English language has rules for combining words to form sentences, in which the sentence "a manager leads a team" follows the grammar rules, but the sentence "leads manager team" does not. UML sentences are diagram fragments or very simple diagrams.
Figure 2-3 shows a UML sentence communicating that a team will execute a project as indicated in the project management system requirements. Team and Project are concepts (nouns), and Execute is the relationship (verb) between the two concepts.
Figure 2-4 shows a somewhat more elaborate UML sentence in which a manager manages a project and leads a team.
Notice that Figure 2-4 communicates about a manager's relationship with a team and project, but it does not communicate that the team will execute the project, as Figure 2-3 did. Just like the English language, we can communicate whatever we want using the UML. Perhaps one way to look at this is that the UML sentence in Figure 2-4 has a different subject (manager) than the UML sentence in Figure 2-3 (team).
The visual location of concepts and relationships does not have any special meaning so long as symbols are not nested inside one another. A relationship is usually read from left to right and top to bottom; otherwise, its name may have a small black solid triangle arrow next to it where the point of the triangle indicates the direction in which to read the name; the arrow is purely descriptive, and the name of the relationship should be understood by the meaning of the concepts it relates. For example, Figure 2-5 communicates the same information as Figure 2-4.
In Figure 2-5, if I did not show the small black solid triangle arrows next to the relationship, we would still know that managers manage projects and lead teams, because that is what it means to be a manager. This is why it is important to know the semantics of what we depict in the UML rather than simply the syntax. Saying that teams lead managers and projects manage managers would be meaningless!