Skip to content

Class Diagram Syntax

Stephan Seifermann edited this page Nov 20, 2017 · 30 revisions

The parts of the syntax are explained in the following paragraphs. At the end of the document, there is a complete example of a valid class diagram that uses many of the mentioned features.

General elements

  • A class diagram always starts with @start-cls, ends with @end-cls, and requires to put a title in quotation marks right after the start tag, e.g. @start-cls "My Title". In the second place, the default package “RootElement” can be declared with rootPackage RootElement. If the name of the default package is RootElement, this entry will be omitted. So, the basic structure of a class diagram looks like the following example:
   @start-clsd "My Title"
   @end-clsd
  • Unique keywords are used to define core UML elements such classes, associations, packages, interfaces, etc.
  • Indentation are not relevant. Everything can be formatted left-aligned. However, spaces are relevant to distinguish between elements. Strings are not restricted in length and must be put in quotation marks.
  • The actual description of an element, e.g. a class description, is included in braces and starts right after the element identifier. It is recommended to put the opening brace on the same line as the element identifier. The closing brace shall be put on a single line to facilitate the finding of enclosed blocks:
    class Classname {

    }
  • The order of elements within a class diagram is pre-defined and must be kept. At first, imports are defined, followed by classifiers, associations, and packages. Details of each element description is given in the subsequent sections.

Class definition

  • A class is introduced with the keyword class followed by a unique id.

  • The id should not include empty spaces and should follow the CamelCase convention. For instance:

    • class MyClass.
  • Long class names can be noted at the class with the keyword as followed by the long class name, which have to be given in quotes. For instance:

    • class Long as "LongClassName".
  • To specify the visibility of a class, the following notations must be placed before the keyword class:

    • public class or + class for a public class (default, if visibility is not given)
    • private class or - class for a private class
    • protected class or # class for a protected class
    • ~ class for a package
  • To specify a class to be abstract, the keyword abstract is placed between the keyword class and the visibility. For instance:

    • private abstract class MyClass

Attributes and methods

  • The definition of attributes and methods is placed within braces after the definition of a class.
  • At first the name is given, followed by a colon, followed by the type: attributename: attributetype
  • The following types are supported: string, int, double, boolean, char, byte, short, long, float.
  • To specify the visibility of attributes, or to recognized an attribute as "static" or "final", the corresponding keyword is placed before the attribute name. For instance:
    • final pi:float
  • This scheme is the same for methods:
    • Visibility: public static main(argument: String):void
    • Return parameters: methodename():returnType
    • Multiple parameters are separated with comma: methodename(parametername:parametertyp, param:String)

Interface definition

  • Interfaces are defined with the keyword interface. For instance:
    • interface Auto
  • Attributes and methods are equally defined as for classes.
  • However, the keyword abstract is not valid for interfaces.

Package definition

  • To define a package, the keyword package in combination with a unique id is used.
  • A long name is not allowed for the package name.
  • A package requires to define the containing elements. For instance:
   package Package1{
      class class1
   }
   package Package2{
      import package1
      class class2
   }
  • Packages can be also encapsulated. For instance:
   package Package3{
      class Test
      asc has (Test, Subpackage.Subclass)
      package Subpackage{
      class Subclass
   }

Relationships

The following types of logical connections are described in the following paragraphs: association, realization/implementation, inheritance.The gernal schema followed for all types of assozations is: operators identifier (operand1, operand2).

Association

  • Generally spoken, associations can link any number of classes. It can be differentiated between indefinite associations, aggregations, and compositions. Corresponding keywords are asc, agg, and com.

  • The keyword bi must be placed before the asc keyword to define bi-directional associations. For instance: bi asc.

  • Examples of all 3 types:

    • asc own (Driver, Car)
    • agg consitstOf (Car, Engine)
    • com consitstOf (Car, Wheel)
  • Notes: The order of the operands defines the reading order. Consequently, it makes a difference whether to write asc drives (Driver, Car) or asc has (Car,Driver). For aggregations and compositions, the "whole" is place first, the "parts" at second.

  • Cardinalities are placed right after the operands. They are defined by the keyword card. Respective attributes are written in squared bracket and separated with colon. For instance:

    • asc has (customer, account) card[1:*].
    • Notes: The order of the attributes corresponds to the oder of the operands of the association.
    • Notes: The default cardinality is 0..1
  • Roles are placed right after the operands. They are defined by the keyword role. Respective attributes are written in squared bracket and separated with comma. For instance:

    • asc has (customer, account) role[Owner, _].
    • The order of the attributes corresponds to the oder of the operands of the association.
  • Roles and cardinalities can be combined. For instance:

    • asc has (customer, account) crad[1:*] role[Owner, _]

Realization/implementation

  • Implementing an interface of a class is introduced with the keyword impl.
  • For instance: impl (MyClass, MyInterface).
  • Note: The class that implements the interface is placed first followed by the interface that is implemented.

Inheritance

  • Inheritance means a generalization relationship and is defined by the keyword isa followed by the operands.
  • For instance: isa BMW Auto
  • Note: Inheritance is the only exception where no identifier must be given.

Example

@start-clsd "Christmas Class Diagram"

abstract class Person {
	name : string
}

class Santa as "Santa Claus"
class Child
interface Present
class Toy
class ToyParts
class Clothes

impl (Toy,Present)
impl (Clothes,Present)
isa (Santa, Person)
isa (Child, Person)
asc has (Santa, Present)  card[1:*]
bi com consistsOf (Toy, ToyParts) card[1:*]

@end-clsd
Clone this wiki locally