Component Diagram Syntax

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 component diagram that uses many of the mentioned features.

General elements

• A component diagram always starts with @start-cpd, ends with @end-cpd, and requires to put a title in quotation marks right after the start tag, e.g. @start-cpd "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 component diagram looks like the following example:

   @start-cpd "My Title"
   @end-cpd

• Unique keywords are used to define core UML elements such as components, classes, interfaces, etc.
• Indentation is 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 component 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:

component Componentname {
}

Interface definition

• Interfaces are defined with the keyword interface. For instance:
  • interface Auto
• Long interface names can be noted at the class with the keyword as followed by the long interface name, which have to be given in quotes. For instance:
  • interface Long as "Long Interface Name".
• Interfaces can hold attributes and methods (see below)

Definition of attributes and methods

• The definition of attributes and methods is placed within braces after the definition of an interface.
• 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", the keyword is placed before the attribute name. For instance:
  • static 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)
• To specify a method to be abstract, the keyword abstract is placed between the keyword method and the visibility. For instance:
  • private abstract myMethod() : void
• To specify the visibility of a method or attribute, the following notations must be placed before them:
  • public or + for a public method or attribute (default, if visibility is not given)
  • private or - for a private method or attribute
  • protected or # for a protected method or attribute
  • ~ for a package

Component definition

• A component is introduced with the keyword component followed by a unique id.
• The id must not include spaces and should follow the CamelCase convention. For instance:
  • component MyComponent.
• Long component names can be noted at the component with the keyword as followed by the long component name, which has to be given in quotes. For instance:
  • component Long as "LongComponentName".
• The order of elements within a component is pre-defined and must be kept. At first, interface relations (provided and required interfaces) are defined, followed by ports, parts, connectors, and nested element. Details of each element description is given in the subsequent sections.

Interface relations

• Components and classes can have interface relations.
• Providing an interface is defined by the keyword provide followed by the name of this relationship and the name of the interface that is provided.

class MyComponentPortType {
  provide payment IPayment
}

• Requiring an interface is defined by the keyword require followed by the name of this relationship and the name of the interface that is required.

class MyComponentPortType {
  require bankAccount IBankAccount
}

• You can use an alias introduced by the keyword as to define a long name for the interface relation

class MyComponentPortType {
  provide payment as "Payment Provider" IPayment
}

Ports

• Ports are defined by the keyword port within a component followed by its name, the keyword realizes and the name of the realized property.
• Interfaces, classes and components can be realized by a port
• To specify the visibility of a port, the same syntax is used as for the visibility of methods.
• To specify that the realized property is conjugated, the keyword conjugated or ~ is placed before its name.
  • Conjugated means that the meaning of provides and requires is swapped for this port. This is useful if you want to connect two components via ports.
  • For instance, you can define port that realizes an interface in one component and specify the same port in the other component. In the other component, however, you set conjugated, which means that this port now required the given interface instead of providing it.

Parts

• Parts are used to define component instances to be used together with the defining component. We have to use them in connectors between ports of different components.
• At first the name is given, followed by a colon, followed by the component type: partName: componentType

component Booking
component HotelManagement { 
  bookingService : Booking 
}

Connectors

• Connectors are defined by the keyword con, followed by the name of the connector and the connector ends in braces.
• A connector end is a port within the same component or the port of a part within the component

interface IBookings
interface IRoomManagement
component Booking {
  port bookings realizes IBookings
  port roomManagement realizes ~ IRoomManagement
}
component RoomManagement {
  port roomManagement realizes IRoomManagement
}

component HotelManagement {
  port bookings realizes IBookings
  
  bookingService : Booking
  roomService : RoomManagement
  
  con bookingDelegation (bookings, bookingService.bookings)
  con bookingRoomAssembly (bookingService.roomManagement, roomService.roomManagement)
}

Nested Elements

• Nested elements within a component can be interfaces, classes or components.

Class definition

• A class can serve as a type of a port in a component diagram. This means that the provides and require relations of the class become the provides and requires relations of the port.
• A class is introduced with the keyword class followed by a unique id.
  • 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".
• A class can contain interface relations

interface IBookings
interface IRoomManagement
class BookingServicePortType {
  provide IBookings
  require IRoomManagement
}
component Bookings {
  port bookingInterface : BookingServicePortType
}

Notes

• Notes can be given for components, classes and interfaces. They start with the keyword note followed by the quoted comment.
• They can have a note after their name if there are no further specifications contained in curly brackets or as first entry after the curly bracket if there are further specifications.

component MyComponent {
  note "Some comment"
  component NestedComponent
}
interface MyInterface note "Some other comment"

Example

@start-cpd "example"

component CashDeskLine {
	note "models a cash desk line"
	require IBank2 BankOfTrust.Bank
	+ port portCashDeskLine realizes CashDesk
	cashDeskInstance : CashDesk
	con connect (portCashDeskLine,cashDeskInstance.portCashDesk)
	component CashDesk {
		require IBank BankOfTrust.Bank
		+ port portCashDesk realizes BankOfTrust.Bank
	}
}

component BankOfTrust {
	provide IBank Bank
	port portBank realizes Bank
	interface Bank {
		maxAmount : int
		+ handleTransaction (amount : int) : boolean
	}
}

@end-cpd