DotUML

https://dotuml.com/documentation/
Admin
DotUML is a tool that allows users to define and generate various types of diagrams, including UML...
Tokens:26,777
Snippets:95
Trust Score:7.3
Update:1 year ago
Show doc for...
Tokens:
Raw
### DotUML Full Deployment Diagram Example

Source: https://dotuml.com/documentation/.html

A comprehensive example of a DotUML deployment diagram showcasing nodes, artifacts, and relationships with styling and labels. It demonstrates the creation of a multi-layered system architecture.

```dotuml
DeploymentDiagram [frame=true framecolor=steelblue label="Deployment Diagram"] {
 node webServer as ":WebServer" [color=lightblue] {
  artifact ss as "Student\nAdministration\n" [icon=file]
 }
 node appServer  as ":Application\nServer" [color=indigo]{
  artifact Student [icon=artifact]
  artifact Seminar [icon=artifact]
  artifact Schedule [icon=artifact]
 }
 node dbServer as ":DatabaseServer" [color=tomato] {
  artifact db as "University DB" [icon=database]
 }
 node main as ":MainFrame" [color=pink] {
  artifact cm as "Course\nmanagement"
 }
 webServer -- appServer "RMI"
 appServer -- dbServer "JDBC"
 appServer -- main "message bus" 
}
```

--------------------------------

### State Diagram: Full Example with Styling and Behaviors

Source: https://dotuml.com/documentation/.html

A comprehensive State Diagram example showcasing advanced features like frame styling, state aliasing, entry/exit behaviors, nested states, and conditional transitions.

```dotuml
StateDiagram [frame=true framecolor=steelblue label="State Diagram" splines=ortho] {
  state Test
  state Idle
  state Maintenance
  state Out as "Out of service" [fillcolor=orangered]
  state Service with behaviors "entry / readCard\n exit / ejectCard" [fillcolor=palegreen] {
    state pin as "Pin validation"
    state transaction
    initialState -> pin
    pin -> transaction
    transaction -> finalState
  }
  initialState->Test
  Test -> Idle "Success"
  Test -> Out "Failure"
  Maintenance -> Out "Failure"
  Test <- Maintenance "Completed"
  Idle -> Service "Insert Card"
  Idle -> Maintenance "Service"
  Out -> Maintenance "Service"
  Service -> Out "Failure"
  Idle <- Service "Cancel or\nComplete"
}
```

--------------------------------

### Use Case Diagram Example

Source: https://dotuml.com/documentation/.html

A comprehensive example of a Use Case Diagram illustrating interactions between an Administrator, Customer, and Bank with an ATM System. It defines actors, systems, use cases, and their relationships.

```dotuml
UseCaseDiagram [frame=true framecolor=steelblue label="Usecase Diagram"] {
  attribute usecase [fillcolor=paleturquoise]
  actor a as "Administrator"
  actor c as "Customer"
  system s as "ATM System" [fillcolor=whitesmoke] {
    usecase u1 as "Withdraw" 
    usecase u2 as "Transfer" 
    usecase u5 as "Read log"
    usecase u3 as "Deposit" 
    usecase u4 as "Register ATM" 
  }
  actor b as "Bank" [icon=university]
  c "1" -- "0..1" u1
  c "1" -- "0..1" u2
  c "1" -- "0..1" u3
  a "1" -- "0..1" u4
  a "1" -- "0..1" u5
  u3 "0..*" -- "1" b
  u4 "0..*" -- "1" b
}
```

--------------------------------

### DotUML Loop Fragment Example

Source: https://dotuml.com/documentation/.html

Example of using the 'loop' fragment operator in DotUML to repeat a sequence of messages a specified number of times.

```APIDOC
SequenceDiagram {
 lifeline l1
 lifeline l2
 fragment loop "{1..10}" {
  l1 --> l2 "test"
 }
}
```

--------------------------------

### Sequence Diagram Example

Source: https://dotuml.com/documentation/.html

This snippet demonstrates a full sequence diagram with actors, lifelines, entities, message flows, and conditional logic (alt/case) to represent a resource access flow with authentication.

```dotuml
SequenceDiagram [frame=true framecolor=steelblue label="Sequence Diagram"] {
  actor user
  lifeline ":Web Browser" as web
  lifeline ":Application" as app autoactivate
  lifeline ":Auth server" as auth autoactivate
  entity "Content server" as content autoactivate
  
  user --> web "get resource"
  activate web
  web --> app "request access"
  app -r-> web "Http redirect"

  web --> auth "auth request"
  auth -r-> web "permission form"
  web -r-> user "permission form"

  user --> web "user permission"
  web --> auth "process permission"
  auth -r-> web "Http redirect"
  
  fragment alt "[Permission granted]" {
    web --> app "authorization code"
    app --> auth "authorization code"
    app <-r- auth "access token"
    app --> content "access protected resources"
    app <-r- content "protected resources"
    web <-r- app "protected resources"
    user <-r- web "protected resources"
  case "[no permission]"
    web --> app "no authorization"
    web <-r- app "resource not available"
    user <-r- web "resource not available"
  	deactivate web
  }
}
```

--------------------------------

### DotUML Reference Fragment Example

Source: https://dotuml.com/documentation/.html

Example of using the 'ref' fragment operator in DotUML to reference another sequence diagram or a predefined interaction over specified lifelines.

```APIDOC
SequenceDiagram {
 lifeline l1
 lifeline l2
 fragment ref "reference" over l1, l2
}
```

--------------------------------

### DotUML Mindmap Example

Source: https://dotuml.com/documentation/.html

This snippet shows a complete MindMap diagram definition in DotUML syntax. It includes attributes for frame, frame color, label, font name, and defines various concepts and their relationships within the map.

```DotUML
MindMap [frame=true framecolor=steelblue label="Mind map of Happiness - Contributed by Costa Shulyupin" fontname="cursive"] {
attribute concept [penwidth=0 fillcolor="#f0f0ffA0" fontcolor=indigo]
attribute concept ** [fontsize=16 fontcolor=seagreen]
attribute link [penwidth=4 color="#f0f0ff"]
* Happiness [fontsize=24 fontcolor=red]
** Peace [fontsize=16 fontcolor=seagreen]
*** Connection
**** Acceptance
**** Forgiveness
**** Gratitude
**** Agreement
*** Relationship
**** Friends
**** Community
**** Society
*** Caring
**** Respect
**** Empathy
**** Help
** Love
*** Giving
**** Feelings
**** Support
*** People
**** Family
**** Partner
**** Hug
*** Beauty
**** Esthetics
**** Art
** Soul
*** Emotions
**** Positiveness
**** Tranquility
*** Self
**** Delight
**** Joy
**** Expression 
*** Meditation
**** Contemplation
**** Breath
** Mind
*** Cognition
**** Imagination
**** Perception
**** Thinking
**** Understanding
**** Memory
*** Consciousness
**** Awareness
*** Intelligence
**** Learning
**** Experiment
**** Education
** Life
*** Nature
**** Ocean
**** Forest
**** Pets
**** Wildlife
*** Wellbeing
**** Home
**** Work
**** Finance
**** Clothes
**** Transport
*** Success
**** Creation
**** Profit
**** Win
**** Career
** Health
*** Body
**** Medicine
**** Exercises
**** Nutrition
**** Water
**** Heart
*** Recreation
**** Leisure
**** Sleep
}
```

--------------------------------

### Class Diagram Example

Source: https://dotuml.com/documentation/.html

Defines a class diagram with multiple classes, including abstract classes, regular classes, attributes, methods, and relationships between them. It also demonstrates alignment of elements.

```dotuml
ClassDiagram [frame=true framecolor=steelblue label="Class Diagram"] {
 
abstract class User {
  private userId : string
  private email : string
  private loginStatus : Status
  public login(email: string, password:string)
 }
  
 class Customer {
  private name : string
  private address: Address
  public register()
  public login()
 }

 class Administrator {
  private adminName : string
 }
 
 class Order {
  private orderId : integer
  private date : Date
  private status : Status
  public placeOrder()
  public getTotal(): Amount
 }

 class OrderItem {
  private orderItemId : integer
  private productId : integer
  private quantity : integer
 }

 class Product {
  private productId : integer
  private price : amount
  private name : String
 }

 align {
  Customer
  User
  Product
 }

 align {
  Order
  OrderItem
 }

 Customer -g-> User
 Administrator -g-> User
 Customer "1" --> "0..*" Order;
 OrderItem "1..*" -c-> "1" Order
 Product -- OrderItem  
  
}
```

--------------------------------

### Business Composite Element: Product

Source: https://dotuml.com/documentation/.html

Defines a 'Product' as a business composite element, including its constituent contracts and business services, and their aggregation relationships. This example demonstrates how to model hierarchical structures and service dependencies.

```dot
ArchimateView [rankdir=TB frame=true framecolor=steelblue label="Business Composite Element: Product"] {
  /**
   A product “Insurance” consists of a contract “Insurance Policy” and a business service “Customer Service”,
   which aggregates four other business services: “Application”, “Renewal”, “Claims Processing”, and “Appeal”.
  **/
  product insurance as "Insurance" {
    contract policy as "Insurance\nPolicy"
    business service customerService as "Customer\nService"
    business service application as "Application"
    business service renewal as "Renewal"
    business service processing as "Claims\nProcessing"
    business service appeal as "Appeal"
    customerService aggregates application
    customerService aggregates renewal
    customerService aggregates processing
    customerService aggregates appeal
  }
  
  /**
   An “Auto Insurance” product is a specialization of the generic “Insurance” product,
   with an additional business service “Drive Well and Save”,
   and accompanying contract “Drive Well and Save Agreement”.
  **/
  product autoinsurance as "Auto Insurance" {
    contract driveAgreement as "Drive Well and\nSave Agreement"
    business service drive as "Drive Well\nand Save"
    driveAgreement -> drive
  }
  
  insurance specialized by autoinsurance [align="policy,drive"]
}
```

--------------------------------

### DotUML Applications

Source: https://dotuml.com/documentation/.html

Lists the various DotUML applications covered by these terms of service, including their respective platforms and links.

```APIDOC
DotUML Applications:
  - Web site: https://dotuml.com
  - Atlassian Confluence plug-in: https://marketplace.atlassian.com/apps/1219821
  - Google Workspace add-on: https://gsuite.google.com/marketplace/app/dotuml/881643845287
  - Microsoft Office add-in: https://appsource.microsoft.com/en-ca/product/office/wa104382059
  - Visual Studio Code Extension: https://marketplace.visualstudio.com/items?itemName=BMLSolutions.dotuml
```

--------------------------------

### DotUML Language Syntax

Source: https://dotuml.com/documentation/.html

Explains the fundamental syntax rules of the DotUML language, including case sensitivity, instruction termination, block grouping, commenting, and label declaration. It highlights how to define multi-line labels.

```DotUML
actor a1
actor "second actor" as a2
actor a3 as "third\nactor"
```

```DotUML
usecase u1
usecase "second use case" as u2
usecase u3 as "third\nuse case"
```

--------------------------------

### URL Encoded DotUML Mindmap

Source: https://dotuml.com/documentation/.html

This snippet provides the URL-encoded version of the DotUML MindMap example. This format is useful for embedding diagrams in web applications or sharing them via URLs.

```URL Encoded
MindMap%20%5Bframe%3Dtrue%20framecolor%3Dsteelblue%20label%3D%22Mind%20map%20of%20Happiness%20-%20Contributed%20by%20Costa%20Shulyupin%22%20fontname%3D%22cursive%22%5D%20%7B%0Aattribute%20concept%20%5Bpenwidth%3D0%20fillcolor%3D%22%23f0f0ffA0%22%20fontcolor%3Dindigo%5D%0Aattribute%20concept%20**%20%5Bfontsize%3D16%20fontcolor%3Dseagreen%5D%0Aattribute%20link%20%5Bpenwidth%3D4%20color%3D%22%23f0f0ff%22%5D%0A*%20Happiness%20%5Bfontsize%3D24%20fontcolor%3Dred%5D%0A**%20Peace%20%5Bfontsize%3D16%20fontcolor%3Dseagreen%5D%0A***%20Connection%0A****%20Acceptance%0A****%20Forgiveness%0A****%20Gratitude%0A****%20Agreement%0A***%20Relationship%0A****%20Friends%0A****%20Community%0A****%20Society%0A***%20Caring%0A****%20Respect%0A****%20Empathy%0A****%20Help%0A**%20Love%0A***%20Giving%0A****%20Feelings%0A****%20Support%0A***%20People%0A****%20Family%0A****%20Partner%0A****%20Hug%0A***%20Beauty%0A****%20Esthetics%0A****%20Art%0A**%20Soul%0A***%20Emotions%0A****%20Positiveness%0A****%20Tranquility%0A***%20Self%0A****%20Delight%0A****%20Joy%0A****%20Expression%20%0A***%20Meditation%0A****%20Contemplation%0A****%20Breath%0A**%20Mind%0A***%20Cognition%0A****%20Imagination%0A****%20Perception%0A****%20Thinking%0A****%20Understanding%0A****%20Memory%0A***%20Consciousness%0A****%20Awareness%0A***%20Intelligence%0A****%20Learning%0A****%20Experiment%0A****%20Education%0A**%20Life%0A***%20Nature%0A****%20Ocean%0A****%20Forest%0A****%20Pets%0A****%20Wildlife%0A***%20Wellbeing%0A****%20Home%0A****%20Work%0A****%20Finance%0A****%20Clothes%0A****%20Transport%0A***%20Success%0A****%20Creation%0A****%20Profit%0A****%20Win%0A****%20Career%0A**%20Health%0A***%20Body%0A****%20Medicine%0A****%20Exercises%0A****%20Nutrition%0A****%20Water%0A****%20Heart%0A***%20Recreation%0A****%20Leisure%0A****%20Sleep%0A%7D
```

--------------------------------

### Define Basic Concepts in DotUML

Source: https://dotuml.com/documentation/.html

Demonstrates how to define a central concept with a simple name or a label using the '*' syntax in DotUML.

```dotuml
MindMap {
 * Sports
}
```

--------------------------------

### Use Case Diagram Actor and Use Case Definition

Source: https://dotuml.com/documentation/.html

Demonstrates how to define actors and use cases within a Use Case Diagram in DotUML. It shows syntax for simple names, aliased names, and multi-line labels for both actors and use cases.

```DotUML
UseCaseDiagram {
 actor a1
 actor "second actor" as a2
 actor a3 as "third\nactor"
}

```

```DotUML
UseCaseDiagram {
 usecase u1
 usecase "second use case" as u2
 usecase u3 as "third\nuse case"
}

```

--------------------------------

### Sequence Diagram Autonumbered Messages

Source: https://dotuml.com/documentation/.html

Demonstrates the use of automatic message numbering in Sequence Diagrams. It covers starting numbering at a specific value, incrementing, stopping numbering, and resuming with a specified increment.

```dotuml
SequenceDiagram {
 lifeline l1
 lifeline l2
 autonumber 10 10
 l1 --> l2 "a"
 l1 -s-> l2 "b"
 autonumber stop
 l1 --> l2 "c"
 autonumber resume 1
 l1 --> l2 "d"
 l1 --> l2 "e"
}
```

--------------------------------

### ArchiMate Application Layer Elements

Source: https://dotuml.com/documentation/.html

This section details the core elements of the ArchiMate Application Layer, as defined by The Open Group. It includes descriptions, declaration syntax, and visual notation representations for each element.

```APIDOC
Application Component:
  Definition: Represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable.
  Declaration: `Application component _appcomponent as "Application\ncomponent"`
  Notation: ArchimateView {
Application component _appcomponent as "Application\ncomponent"
}
Applicationcomponent

Application Collaboration:
  Definition: Represents an aggregate of two or more application internal active structure elements that work together to perform collective application behavior.
  Declaration: `Application collaboration _appcollaboration as "Application\ncollaboration"`
  Notation: ArchimateView {
Application collaboration _appcollaboration as "Application\ncollaboration"
}
Applicationcollaboration

Application Interface:
  Definition: Represents a point of access where application services are made available to a user, another application component, or a node.
  Declaration: `Application interface _appinterface as "Application\ninterface"`
  Notation: ArchimateView {
Application interface _appinterface as "Application\ninterface"
}
Applicationinterface

Application Function:
  Definition: Represents automated behavior that can be performed by an application component.
  Declaration: `Application function _appfunction as "Application\nfunction"`
  Notation: ArchimateView {
Application function _appfunction as "Application\nfunction"
}
Applicationfunction

Application Interaction:
  Definition: Represents a unit of collective application behavior performed by (a collaboration of) two or more application components.
  Declaration: `Application interaction _appinteraction as "Application\ninteraction"`
  Notation: ArchimateView {
Application interaction _appinteraction as "Application\ninteraction"
}
Applicationinteraction

Application Process:
  Definition: Represents a sequence of application behaviors that achieves a specific result.
  Declaration: `Application process _appprocess as "Application\nprocess"`
  Notation: ArchimateView {
Application process _appprocess as "Application\nprocess"
}
Applicationprocess

Application Event:
  Definition: Represents an application state change.
  Declaration: `Application event _appevent as "Application\nevent"`
  Notation: ArchimateView {
Application event _appevent as "Application\nevent"
}
Applicationevent

Application Service:
  Definition: Represents automated behavior that can be performed by an application component.
  Declaration: `Application service _appservice as "Application\nservice"`
  Notation: ArchimateView {
Application service _appservice as "Application\nservice"
}
Applicationservice

Data Object:
  Definition: Represents data structured for automated processing.
  Declaration: `Data object _dataobject as "Data\nobject"`
  Notation: ArchimateView {
Data object _dataobject as "Data\nobject"
}
Dataobject
```

--------------------------------

### Generalization and Realization

Source: https://dotuml.com/documentation/.html

Illustrates the syntax for generalization ('-g->') between classes and realization ('-r->') of interfaces by classes. Specifies type constraints for these relationships.

```DotUML
ClassDiagram {
 class ca
 class cb
 cb -g-> ca
 interface i
 class c
 c -r-> i
}
```

--------------------------------

### Apply Attributes to Concepts and Links in DotUML

Source: https://dotuml.com/documentation/.html

Explains how to apply attributes like color, fill color, font color, and font size to concepts and links, including level-specific attributes.

```dotuml
MindMap {
 attribute concept [color=indianred4 fillcolor=indianred1]
 attribute concept *** [color=indianred4 fillcolor=indianred3 fontcolor=white]
 attribute link [color=indianred4]
 * Sports [fontsize=24]
 ** "Individual Sports"
 *** Cycling 
 *** Golf
 *** Tennis
 *** Running
 ** "Team Sports"
 *** Soccer
 *** Basketball
 *** Football
 *** Hockey
 *** Rugby
 **  "Water sports"
 *** Swimming
 *** WaterPolo
 *** Diving
 **  "Winter sports"
 *** Ski
 *** Hockey
 *** Patin
}
```

--------------------------------

### System Grouping

Source: https://dotuml.com/documentation/.html

Groups use cases into a system using the 'system {}' block. Systems can be aliased using 'as'.

```DotUML
UseCaseDiagram {
 actor a1
 system "System" as sys {
  usecase u1
  usecase u2
 }
 a1 -- u1
 actor a2
 a2 -- u2
}
```

--------------------------------

### Archimate Application Behavior Model

Source: https://dotuml.com/documentation/.html

This Archimate model visualizes application behavior, showing the composition of application functions, their realization of application services, and the triggering of application processes by application events. It models the 'Purchase Travel Insurance' scenario.

```Archimate
ArchimateView [rankdir=bt frame=true splines=ortho framecolor=steelblue label="Application Behavior Elements"] {

  /**
   The “Purchase Travel Insurance” application function is composed of two other application functions:
   “Transfer Quotation”, realizing an application service “Get Quotation”,
   and “Finalize Purchase”, realizing an application service “Purchase Quoted Insurance”.
  **/
  application function purchaseApp as "Purchase Travel Insurance" {
    application function transfer as "Transfer\nQuotation"
    application function finalize as "Finalize\nPurchase"
  }
  application service getQuotation as "Get Quotation"
  application service purchase as "Purchase Quoted\nInsurance"
  getQuotation realized by transfer
  purchase realized by finalize

  /**
   These application functions model the behavior of the “Quotation” and “Purchase” application components of Example 27.
   An application event “Request for a Quotation” triggers an application process “Obtain Travel Insurance”,
   which is served by the two aforementioned application services.
  **/
  application process obtain as "Obtain Travel Insurance"
  obtain served by purchase
  obtain served by getQuotation
  application event request as "Request for\na Quotation"
  request triggers obtain

  align request obtain
  
}
```

--------------------------------

### ArchiMate Implementation and Migration Elements

Source: https://dotuml.com/documentation/.html

Defines elements related to the implementation and migration of an architecture, including work packages, deliverables, events, plateaus, and gaps.

```APIDOC
Work package:
  Definition: Represents a series of actions identified and designed to achieve specific results within specified time and resource constraints.
  Declaration: `Work package _Workpackage as "Work\npackage"`
  Notation: ArchimateView {
Work package _Workpackage as "Work\npackage"
}

Deliverable:
  Definition: Represents a precisely-defined result of a work package.
  Declaration: `Deliverable _deliverable as "Deliverable"`
  Notation: ArchimateView {
Deliverable _deliverable as "Deliverable"
}

Implementation event:
  Definition: Represents a state change related to implementation or migration.
  Declaration: `Implementation event _implementationevent as "Implementation\nevent"`
  Notation: ArchimateView {
Implementation event _implementationevent as "Implementation\nevent"
}

Plateau:
  Definition: Represents a relatively stable state of the architecture that exists during a limited period of time.
  Declaration: `Plateau _plateau as "Plateau"`
  Notation: ArchimateView {
Plateau _plateau as "Plateau"
}

Gap:
  Definition: Represents a statement of difference between two plateaus.
  Declaration: `Gap _gap as "Gap"`
  Notation: ArchimateView {
Gap _gap as "Gap"
}
```

--------------------------------

### DotUML Interface Definition

Source: https://dotuml.com/documentation/.html

Demonstrates the syntax for defining interfaces in DotUML, including methods with visibility modifiers.

```APIDOC
ClassDiagram {
 interface Comparable {
  public compareTo(o:Object):int
 }
}
```

--------------------------------

### State Diagram - Basic States

Source: https://dotuml.com/documentation/.html

Illustrates the basic syntax for defining states in a state diagram, including simple states and states with custom labels.

```dotuml
StateDiagram {
 state s1
 state "Super state" as s2
 state s3 as "Other\nstate"
}
```

--------------------------------

### Sequence Diagram Messages

Source: https://dotuml.com/documentation/.html

Illustrates various message types used in Sequence Diagrams, including synchronous, asynchronous, reply, create, delete, lost, and find messages. It demonstrates the syntax for each message type.

```dotuml
SequenceDiagram {
 lifeline l1
 lifeline l2
 lifeline l3
 l1 --> l2 "default==synchrone"
 l1 -s-> l2 "synchronous"
 l1 -a-> l2 "asynchronous"
 l2 -r-> l1 "reply"
 l1 -c-> l3 "create"
 l1 -d-> l3 "delete"
 -f-> l2 "find"
 l1 -l-> "lost"
}
```

--------------------------------

### DotUML Binary Association

Source: https://dotuml.com/documentation/.html

Illustrates the syntax for creating binary associations between two classes, including multiplicity and labels.

```APIDOC
ClassDiagram {
 class ca
 class cb
 ca "1..*" -- "0..1" cb : "Binary association"
}
```

--------------------------------

### DotUML Class Definition

Source: https://dotuml.com/documentation/.html

Defines how to create classes, including empty classes, classes with labels, attributes, operations, visibility modifiers, static members, abstract members, and templates.

```APIDOC
ClassDiagram {
 class Person
}

ClassDiagram {
 class "Person Label" as Person
}

ClassDiagram {
 class Person {
  name:String
  setName(name:String)
  getName():String
  private name:String
  protected setName(name:String)
  public getName():String
  static public PI:double="3.14159"
  static public cos(angle:double):double
  abstract public getArea():double
 }
}

ClassDiagram {
 class Set <T> {
  insert(T)
  remove(T)
 }
}
```

--------------------------------

### State Diagram: Fork and Join Pseudo States

Source: https://dotuml.com/documentation/.html

Illustrates the use of 'fork' and 'join' pseudo states for parallel execution paths in a State Diagram. A fork splits a path into multiple, and a join merges them back.

```dotuml
StateDiagram {
 state s1
 state s2
 state s3
 fork f
 s1 -> f
 f -> s2
 f -> s3
 join j
 s2 ->j
 s3 -> j
 state s4
 j -> s4
}
```

--------------------------------

### Deployment Diagram: Artifact Placement

Source: https://dotuml.com/documentation/.html

Shows how to define an artifact and place it within a node in a Deployment Diagram. Artifacts represent software components or data.

```dotuml
DeploymentDiagram {
 node n1 {
  artifact a1
 }
}
```

--------------------------------

### DotUML Dependency Relationships

Source: https://dotuml.com/documentation/.html

Details the dependency relationships in DotUML, including Serving, Access, Influence, and Association. It explains how elements provide functionality, observe or act upon others, affect motivations, or have unspecified relationships, along with their declarations and notations.

```APIDOC
Serving:
  Represents that an element provides its functionality to another element.
  Declaration:
    el1 serves el2
    el1 -serv-> el2
    el1 -v-> el2
    el1 served by el2
    el1 <-serv- el2
    el1 <-v- el2
  Notation:
    ArchimateView {
      Attribute element [size=small];
      capability el1; value stream el2; el1 serves el2
    }el1 el2
    ArchimateView {
      Attribute element [size=small];
      value stream el1; capability el2; el1 served by el2
    }el1 el2

Access:
  Represents the ability of behavior and active structure elements to observe or act upon passive structure elements.
  Declaration:
    el1 accesses el2
    el1 -acce-> el2
    el1 -a-> el2
    el1 accessed by el2
    el1 <-acce- el2
    el1 <-a- el2
  Notation:
    ArchimateView {
      Attribute element [size=small];
      bus interface el1; bus object el2; el1 accesses el2
    }el1 el2
    ArchimateView {
      Attribute element [size=small];
      bus object el1; bus interface el2; el1 accessed by el2
    }el1 el2

Influence:
  Represents that an element affects the implementation or achievement of some motivation element.
  Declaration:
    el1 influences el2 "++"
    el1 -infl-> el2 "++"
    el1 -n-> el2 "++"
    el1 influenced by el2 "--"
    el1 <-infl- el2 "--"
    el1 <-n- el2 "--"
  Notation:
    ArchimateView {
      Attribute element [size=small];
      driver el1; value el2; el1 influences el2 "++"
    }el1 el2 ++ 
    ArchimateView {
      Attribute element [size=small];
      value el1; driver el2; el1 influenced by el2 "--"
    }el1 el2 --

Association:
  Represents an unspecified relationship, or one that is not represented by another ArchiMate relationship.
  Declaration:
    el1 associated with el2
    el1 -asso- el2
```

--------------------------------

### DotUML Class Association

Source: https://dotuml.com/documentation/.html

Demonstrates the syntax for creating class associations, where a third class participates in the association.

```APIDOC
ClassDiagram {
 class ca
 class cb
 class cc
 ca -- cb with cc : "Class asso"
}
```

--------------------------------

### ArchiMate Diagram: Capability, Resource, and Course of Action

Source: https://dotuml.com/documentation/.html

This snippet defines an ArchiMate model showcasing the relationships between business goals, strategies, outcomes, capabilities, resources, and locations. It illustrates how goals are aggregated, strategies influence outcomes, and capabilities realize courses of action, with resources assigned to capabilities and located in specific organizational locations.

```dot
ArchimateView%20%5Brankdir%3Dtb%20frame%3Dtrue%20splines%3Dspline%20framecolor%3Dsteelblue%20label%3D%22Capability%2C%20Resource%2C%20and%20Course%20of%20Action%22%5D%20%7B%0A%0A%20%20%2F**%0A%20%20%20%E2%80%9CIncrease%20Profit%E2%80%9D%20is%20a%20goal%20that%20can%20be%20decomposed%20into%20a%20number%20of%20other%20goals%3A%0A%20%20%20%E2%80%9CDecrease%20Costs%E2%80%9D%20and%20%E2%80%9CIncrease%20Revenue%E2%80%9D.%0A%20%20**%2F%0A%20%20goal%20increaseProfit%20as%20%22Increase%20Profit%22%0A%20%20goal%20decreaseCosts%20as%20%22Decrease%20Costs%22%0A%20%20goal%20IncreaseRevenue%20as%20%22Increase%5CnRevenue%22%0A%20%20increaseProfit%20aggregates%20decreaseCosts%0A%20%20increaseProfit%20aggregates%20IncreaseRevenue%0A%0A%20%20%2F**%0A%20%20%20The%20former%20is%20related%20to%20the%20%E2%80%9COperational%20Excellence%E2%80%9D%20strategy%20of%20the%20company%2C%20modeled%20as%20a%20course%20of%20action.%0A%20%20This%20is%20decomposed%20into%20two%20other%20courses%20of%20action%3A%20%E2%80%9CCentralize%20IT%20Systems%E2%80%9D%20and%20%E2%80%9CStandardize%20Products%E2%80%9D.%0A%20%20**%2F%0A%20%20course%20of%20action%20strategy%20%20as%20%22Operational%5CnExcellence%22%0A%20%20course%20of%20action%20systems%20as%20%22Centralize%20IT%5CnSystems%22%0A%20%20course%20of%20action%20products%20%20as%20%22Standardize%5CnProducts%22%0A%20%20strategy%20aggregates%20systems%0A%20%20strategy%20aggregates%20products%0A%0A%20%20%2F**%0A%20%20%20These%20result%20in%20two%20outcomes%3A%20%E2%80%9CDecreased%20Costs%E2%80%9D%20and%20%E2%80%9CLoss%20of%20Customers%E2%80%9D%2C%20which%20influence%20the%20goals%20in%20positive%20and%20negative%20ways.%0A%20%20%20This%20shows%20an%20important%20difference%20between%20goals%20and%20outcomes%3A%20not%20all%20outcomes%20lead%20to%20the%20intended%20results.%0A%20%20**%2F%0A%20%20outcome%20decreasedCosts%20as%20%22Decreased%20Costs%22%0A%20%20outcome%20lossCustomers%20as%20%22Loss%20of%5CnCustomers%22%0A%20%20decreaseCosts%20influenced%20by%20decreasedCosts%0A%20%20IncreaseRevenue%20influenced%20by%20lossCustomers%20%22-%22%20%5Bfontcolor%3Dred%5D%0A%20%20decreasedCosts%20influenced%20by%20systems%20%22%2B%22%20%5Bfontcolor%3Dgreen%5D%0A%20%20lossCustomers%20influenced%20by%20products%20%22%2B%22%20%5Bfontcolor%3Dgreen%5D%0A%20%20decreaseCosts%20influenced%20by%20strategy%20%22%2B%2B%22%20%5Bfontcolor%3Dgreen%5D%0A%20%20decreasedCosts%20influenced%20by%20products%20%22%2B%22%20%5Bfontcolor%3Dgreen%5D%0A%0A%20%20%2F**%0A%20%20%20The%20courses%20of%20action%20are%20realized%20by%20a%20number%20of%20capabilities%3A%20%E2%80%9CIT%20Management%20%26%20Operations%E2%80%9D%20and%20%E2%80%9CProduct%20Management%E2%80%9D%2C%0A%20%20%20and%20appropriate%20resources%20%E2%80%9CHuman%20Resources%E2%80%9D%20and%20%E2%80%9CIT%20Resources%E2%80%9D%20are%20assigned%20to%20the%20former.%0A%20%20%20The%20model%20fragment%20also%20shows%20that%20these%20resources%20are%20located%20in%20the%20%E2%80%9CHeadquarters%E2%80%9D%20of%20the%20organization%2C%0A%20%20%20in%20line%20with%20the%20%E2%80%9CCentralize%20IT%20Systems%E2%80%9D%20course%20of%20action.%0A%20%20**%2F%0A%20%20location%20h%20as%20%22Headquarters%22%20%7B%0A%20%20%20%20resource%20human%20as%20%22Human%5CnResources%22%0A%20%20%20%20resource%20IT%20as%20%22IT%20Resources%22%0A%20%20%7D%0A%20%20capability%20capabilityITAndOpe%20as%20%22IT%20Management%20%26%5CnOperations%22%0A%20%20capability%20capabilityProduct%20as%20%22Product%5CnManagement%22%0A%20%20capabilityITAndOpe%20has%20assigned%20human%0A%20%20capabilityITAndOpe%20has%20assigned%20IT%0A%0A%20%20systems%20realized%20by%20capabilityITAndOpe%0A%20%20products%20realized%20by%20capabilityProduct%0A%0A%20%20%2F%2F%20presentation%0A%20%20decreasedCosts%20-%3E%20strategy%0A%7D
```

--------------------------------

### ArchiMate Business Layer Elements

Source: https://dotuml.com/documentation/.html

This section lists and describes the core elements of the ArchiMate Business Layer. It includes definitions, how to declare them in a modeling language, and their visual notation.

```APIDOC
Business actor:
  Definition: Represents a business entity that is capable of performing behavior.
  Declaration: `Business actor _bactor as "Business\nactor"`
  Notation: ArchimateView {
Business actor _bactor as "Business\nactor"
}Businessactor

Business role:
  Definition: Represents the responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event.
  Declaration: `Business role _brole as "Business\nrole"`
  Notation: ArchimateView {
Business role _brole as "Business\nrole"
}Businessrole

Business collaboration:
  Definition: Represents a business entity that is capable of performing behavior.
  Declaration: `Business collaboration _bcollaboration as "Business\ncollaboration"`
  Notation: ArchimateView {
Business collaboration _bcollaboration as "Business\ncollaboration"
}Businesscollaboration

Business interface:
  Definition: Represents a point of access where a business service is made available to the environment.
  Declaration: `Business interface _binterface as "Business\ninterface"`
  Notation: ArchimateView {
Business interface _binterface as "Business\ninterface"
}Businessinterface

Business process:
  Definition: Represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services.
  Declaration: `Business process _bprocess as "Business\nprocess"`
  Notation: ArchimateView {
Business process _bprocess as "Business\nprocess"
}Businessprocess

Business function:
  Definition: Represents a collection of business behavior based on a chosen set of criteria such as required business resources and/or competencies, and is managed or performed as a whole.
  Declaration: `Business function _bfunction as "Business\nfunction"`
  Notation: ArchimateView {
Business function _bfunction as "Business\nfunction"
}Businessfunction

Business interaction:
  Definition: Represents a unit of collective business behavior performed by (a collaboration of) two or more business actors, business roles, or business collaborations.
  Declaration: `Business interaction _binteraction as "Business\ninteraction"`
  Notation: ArchimateView {
Business interaction _binteraction as "Business\ninteraction"
}Businessinteraction

Business event:
  Definition: Represents an organizational state change.
  Declaration: `Business event _bevent as "Business\nevent"`
  Notation: ArchimateView {
Business event _bevent as "Business\nevent"
}Businessevent

Business service:
  Definition: Represents explicitly defined behavior that a business role, business actor, or business collaboration exposes to its environment.
  Declaration: `Business service _bservice as "Business\nservice"`
  Notation: ArchimateView {
Business service _bservice as "Business\nservice"
}Businessservice

Business object:
  Definition: Represents a concept used within a particular business domain.
  Declaration: `Business object _bobject as "Business\nobject"`
  Notation: ArchimateView {
Business object _bobject as "Business\nobject"
}Businessobject

Contract:
  Definition: Represents a formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product and establishes functional and non-functional parameters for interaction.
  Declaration: `Contract _contract as "Contract"`
  Notation: ArchimateView {
Contract _contract as "Contract"
}Contract

Representation:
  Definition: Represents a perceptible form of the information carried by a business object.
  Declaration: `Representation _representation as "Representation"`
  Notation: ArchimateView {
Representation _representation as "Representation"
}Representation

Product:
  Definition: Represents a coherent collection of services and/or passive structure elements, accompanied by a contract, which is offered as a whole to (internal or external) customers.
  Declaration: `Product _product as "Product"`
  Notation: ArchimateView {
Product _product as "Product"
}Product
```

--------------------------------

### State Diagram - States with Behaviors

Source: https://dotuml.com/documentation/.html

Demonstrates how to add behaviors (entry, do, exit actions) to states within a state diagram.

```dotuml
StateDiagram {
 state s1 with behavior "entry/eS1()\ndo/dS1()\nexit/xS1()"
}
```

--------------------------------

### State Diagram: Initial and Final Pseudo States

Source: https://dotuml.com/documentation/.html

Defines initial and final pseudo states in a State Diagram using the keywords 'initialState' and 'finalState'. Shows a simple transition from an initial state to a regular state and then to a final state.

```dotuml
StateDiagram {
 state s1
 initialState -> s1 
 s1 -> finalstate
}
```

--------------------------------

### Navigability in Associations

Source: https://dotuml.com/documentation/.html

Defines how to specify navigability in associations between classes using symbols like 'x', '<', and '>'. Covers combinations for different navigability states.

```DotUML
ClassDiagram {
 class ca
 class cb
 ca x--> cb
}
```
Tokens:
Raw