Bits & Bytes

Posts Tagged ‘OOD’

UML Class Diagrams – part 4

Continued . . .

In this section, we give the final details of the attributes and operations that can be modeled with UML. With the central elements covered, we are going to add some examples of attributes with initial values and operations with default argument values. Additionally, we will give some examples of attributes and operations with properties, and we will talk about some of the commonly used properties. Finally, we will show how to of model scope and operation binding.

Our arc class below, called CAArc, should serve to illustrate the remaining elements of UML that can be modeled for operations and attributes. This class contains three operations and three attributes. Of the operations, two are instance operations and the third is a class operation. The word static is used in C++ to indicate a class member, rather than an instance member. The word virtual before GetLength() indicates that that function has dynamic binding, while GetOrientation() is statically, or compile-time, bound. Also, the ” = 0″ is used to indicate that GetLength() is not implemented for this class, but rather is a pure virtual function or an abstract operation.

Of the classes attributes, two are instance members and one, the constant skdPi, is a class member. The constant is initialized at compile-time to the value 3.14159. The other member variables, dStartAngle and dEndAngle, have no initial value that is apparent here and are non-constant, so they can be changed at anytime.

class CAArc
{
public:
    virtual double GetLength() = 0;
    int GetOrientation();
    static double GradToDeg(double dA = 0.0);
private:
    static const double skdPi = 3.14159;
    double dStartAngle;
    double dEndAngle;
};

The arc class above can be modeled in UML using the diagram below. Since the GetLength() is an abstract operation, we italicize it to show this. We use the property “leaf” to indicate that the operation GetOrientation() is statically bound and can not be overridden. The operation is GradToDeg() has an argument with a default argument value, as shown. Also, we have underlined GradToDeg() to show that it is a class operation. Likewise, we underline skdPi, since it is a constant with class scope. The initial value for skdPi is shown along with the qualifier “frozen” to indicate that this is a constant. The instance members dStartAngle and dEndAngle are just ordinary member variables.

As far as properties, notice that the constant skiPi has the property “frozen” after it and the function GetOrientation() has the property “leaf” after it. However, we also have the property “changeable” on our instance variables. This can be used with attributes to specify that the variable’s value can be changed. We can also use “addOnly” on attributes with multiplicity to indicate that the values can only be added, say to an array, for instance. For operations, we can use the property “isQuery” to indicate that the operation does not change values; this is the C++ equivalent of a function that is constant. Additionally, we can specify operations having the properties “sequential”, “guarded”, or “concurrent” in the context of processes and threads.

To be continued . . .

UML Class Diagrams – part 3

Continued . . .

So far, we have modeled our classes with considerable detail, but there is still more that we can show. C++ provides several levels of visibility for variables and operations. The three primary visibility designations are public, protected, and private. Additionally, variables can have package level visibility, which means that they can only be accessed within the file in which they are defined. Package visibility is seldom used in C++, but is common in C.

The first three visibility settings are commonly used in most object-oriented languages. The public setting means that the member function or variable can be accessed by anything that can access the main object. The protected setting means that the member can only be accessed by functions from the class that the member is declared in and all functions of classes that inherit the class. Finally, private visibility means that the member can only be accessed by functions within the class where the member is declared.

The C++ class below shows the header for a car class, called CCar. This class has three member functions and three member variables, each with a different visibilty setting. In C++, members of a class have private visibility by default. Otherwise, they have the visibility of the last specification that is above them in the class. So, for example, mdPosition has protected visibility. For clarity, we have listed the visibility specifiers for the class in the order of decreasing visibility, from public to private.

class CCar
{
public:
    void Accelerate();
    double mdTopSpeed;
protected:
    double GetSpeed();
    double mdPosition;
private:
    bool HasAntilock();
    double mdSpeed;
};

This car class can be modeled by the UML class diagram shown below. The visibility of a member is specified by a symbol that precedes the variable or function name. We use +, #, and – for public, protected, and private, respectively. So, we see that in the UML diagram, we have one variable and function with each type of visibilty.

Finally, we remark that we can have variables with package visibility. This is designated by a ~ symbol. Package visibility is more common in other programming languages like Java, but has been passed down to C++ from C. To declare a package level variable, we declare the variable in global scope and precede the declaration by the word static, like this

static int i;

Of course, these visibility specifiers are not strictly meaningful in C++. In C++, we can break the encapsulation of a visibility specifier via the friend specification, but that is uncommon and can be modeled by other means.

To be continued . . .

Categories

Recent Posts

Bits & Bytes

Posts Tagged ‘OOD’

UML Class Diagrams – part 4

UML Class Diagrams – part 3