APPENDIX A Small UML Guide The OMG Unified Modeling Language™ (OMG UML) is a standardized graphical language to create models of software and other systems. Its main purpose is to enable developers, software architects, and other stakeholders to design, specify, visualize, construct, and document artifacts of a software system. UML models support the discussion between different stakeholders, serve as an aid for a clarification of requirements and other issues related to the system of interest, and can capture design decisions. This appendix provides a brief overview of that subset of UML notations that are used in this book. Each UML element is illustrated (syntax) and briefly explained (semantic). The short definition for an element is based on the current UML specification [OMG15] that can be downloaded for free from OMG’s website. An in-depth introduction to the Unified Modeling Language should be made with the help of appropriate literature, or by taking a course at a training provider. Class Diagrams Among varied other applications, class diagrams are usually used to depict structures of an object-oriented software design. Class The central element in class diagrams is the class. CLASS A class describes a set of objects that share the same specifications of features, constraints, and semantics. An instance of a class is commonly referred to as an object. Therefore, classes can be considered as blueprints for objects. The UML symbol for a class is a rectangle, as depicted in Figure A-1. © Stephan Roth 2017 273 S. Roth, Clean C++, DOI 10.1007/978-1-4842-2793-0 APPENDIX a ■ SMaLL UML Guide Figure A-1. A class named Customer A class has a name (in this case “Customer”), which is shown centered in the first compartment of the rectangled symbol. If a class is abstract, that is, it cannot be instantiated, its name is typically shown in italicized letters. Classes can have attributes (data, structure) and operations (behavior), which are shown in the second, respective, and third compartments. The type of an attribute is noted separated by a colon after the attribute’s name. The same applies to the type of the return value of an operation. Operations can have parameters that are specified within the parentheses (round brackets). Static attributes or operations are underlined. Classes have a mechanism to regulate the access to attributes and operations. In UML they are called visibilities. The visibility kind is put in front of the attribute’s or operation’s name and may be one of the characters that are described in Table A-1. Table A-1. Visibilities Character Visibility kind + public: This attribute or operation is visible to all elements that can access the class. # protected: This attribute or operation is not only visible inside the class itself, but also visible to elements that are derived from the class that owns it (see Generalization Relationship). ~ package: This attribute or operation is visible to elements that are in the same package as its owning class. This kind of visibility doesn’t have an appropriate representation in C++ and is not used in this book. - private: This attribute or operation is only visible inside the class, nowhere else. A C++ class definition corresponding to the UML class shown in the above Figure A-1 may look like this: Listing A-1. The Customer class in C++ #include <string> #include "DateTime.h" #include "CustomerIdentifier.h" class Customer { public: Customer(); virtual ~Customer(); 274 APPENDIX a ■ SMaLL UML Guide std::string getFullName() const; DateTime getBirthday() const; std::string getPrintableIdentifier() const; private: std::string forename; std::string surname; CustomerIdentifier id; }; The graphical representation of instances is rarely necessary, so the so-called object diagrams of the UML play only a minor role. The UML symbol to depict a created instance (that is, an object) of a class, a so-called Instance Specification, is very similar to that of a class. The main difference is that the caption in the first compartment is underlined. It shows the name of the specified instance, separated by a colon from its type, for example, the class (see Figure A-2). The name may also be missing (anonymous instance). Figure A-2. The Instance Specification on the right represents a possible or actual existence of an instance of class Customer Interface An interface defines a kind of a contract: a class that realizes the interface must fulfill that contract. INTERFACE An interface is a declaration of a set of coherent public obligations. Interfaces are always abstract, that is, they cannot be instantiated by default. The UML symbol for an interface is very similar to a class, with the keyword «interface» (surrounded by French quotation marks that are called “guillemets”) preceding the name, as depicted in Figure A-3. 275 APPENDIX a ■ SMaLL UML Guide Figure A-3. Class Customer implements operations that are declared in interface Person The dashed arrow with the closed but not filled arrowhead is the interface realization relationship. This relationship expresses that the class conforms to the contract specified by the interface, that is, the class implements those operations that are declared by the interface. It is, of course, allowed that a class implements multiple interfaces. Unlike some other object-oriented languages, such as Java or C#, there is no interface keyword in C++. Interfaces are therefore usually emulated with the help of abstract classes that solely consist of pure virtual member functions as shown in the following code examples. Listing A-2. The Person interface in C++ #include <string> #include "DateTime.h" class Person { public: virtual ~Person() { } virtual std::string getFullName() const = 0; virtual DateTime getBirthday() const = 0; }; 276 APPENDIX a ■ SMaLL UML Guide Listing A-3. The Customer class realizing the Person interface #include "Person.h" #include "CustomerIdentifier.h" class Customer : public Person { public: Customer(); virtual ~Customer(); virtual std::string getFullName() const override; virtual DateTime getBirthday() const override; std::string getPrintableIdentifier() const; private: std::string forename; std::string surname; CustomerIdentifier id; }; To show that a class or component (see section Components below) provides or requires interfaces, you can use the so-called ball-and-socket notation. A provided interface is depicted using a ball (a.k.a. “lollipop”), a required interface is depicted with a socket. Strictly speaking, this is an alternative notation, as Figure A-4 clarifies. Figure A-4. The ball-and-socket notation for provided and required interfaces The arrow between class Customer and interface Account is a navigable association, which is explained in the following section about UML associations. 277 APPENDIX a ■ SMaLL UML Guide Association Classes usually have static relationships to other classes. The UML association specifies such a kind of relationship. ASSOCIATION An association relationship allows one instance of a classifier (e.g., a class or a component) to access another. In its simplest form, the UML syntax for an association is a solid line between two classes as depicted in Figure A-5. Figure A-5. A simple association relationship between two classes This simple association is often not sufficient to properly specify the relationship between both classes. For instance, the navigation direction across such a simple association, that is, who is able to access whom, is undefined by default. However, navigability in this case is often interpreted as bidirectional by convention, that is, Customer has an attribute to access ShoppingCart and vice versa. Therefore, more information can be provided to an association. Figure A-6 illustrates a few of the possibilities. 278 APPENDIX a ■ SMaLL UML Guide Figure A-6. Some examples of associations between classes 1. This example shows an association with one end navigable (depicted by an arrowhead) and the other having unspecified navigability. The semantic is: class A is able to navigate to class B. In the other direction it is unspecified, that is, class B might be able to navigate to class A. ■■Note It is strongly recommended to define the interpretation of the navigability of such an unspecified association end in your project. My recommendation is to consider them as non-navigable. This interpretation is also used in this book. 2. This navigable association has a name (“has”). The solid triangle indicates the direction of reading. Apart from that, the semantics of this association is fully identical to example 1. 3. In this example, both association ends have labels (names) and multiplicities. The labels are typically used to specify the roles of the classes in an association. A multiplicity specifies the allowed quantity of instances of the classes that are involved in an association. It is an inclusive interval of non-negative integers beginning with a lower bound and ending with a (possibly infinite) upper bound. In this case, any A has zero to any number of B’s, whereas any B has exactly one A. Table A-2 shows some examples of valid multiplicities. 4. This is a special association called aggregation. It represents a whole-part- relationship, that is, the one class (the part) is hierarchically subordinated to the other class (the whole). The shallow diamond is just a marker in this kind of association and identifies the whole. Otherwise everything that applies to associations applies to an aggregation too. 279 APPENDIX a ■ SMaLL UML Guide 5. This is a composite aggregation, which is a strong form of aggregation. It expresses that the whole is the owner of the parts, and thus also responsible for the parts. If an instance of the whole is deleted, all of its part instances are normally deleted with it. ■■Note Please note that a part can (where allowed) be removed from a composite before the whole is deleted, and thus not be deleted as part of the whole.