Commit d9a644e3 authored by uschwar1's avatar uschwar1
Browse files

all from umlgenerator/master

parents b9b1a53a ec6f4b78
This is a legend for the relation types given in the diagram about activities in
a PID architecture
```plantuml
actor "user" as l_user1
'actor "user" as l_user2
'rectangle "registration body" as l_orga1
'rectangle "registration body" as l_orga2
database "registry" as l_reg1
database "registry" as l_reg2
database "registry" as l_reg3
database "registry" as l_reg4
agent "actor" as l_actor
database "registry" as l_reg1
rectangle "registration body" as l_orga7
rectangle "registration body" as l_orga8
l_user1 --> l_reg1 : open access user/actor activities
l_reg3 <.. l_reg2 : unrestricted internal registry activities
'l_orga1 ..> l_orga2 : internal registration activities
l_actor o--> l_reg4 : activities with credential based access control
l_orga7 *..> l_orga8 : activities with contract based access control
```
# Activities in a PID Architecture
These are diagrams that show the main foreground and background activities in
a PID architecture
## The PID consumer's view of the global PID architecture
PID Registration and Resolution in the Global PID Architecture is shown in the following diagram
```plantuml
'actor User as User
'agent Repository as Repo
agent "PID consumer" as PIDconsumer
agent "global PID Architecture" as PIDarch
'database "PID Service" as PIDserv
'rectangle "Local PID Provider" as PIDprov
'User o--> Repo : "registers Data"
'User <--* Repo : "issues credential"
'User --> Repo : "accesses Data"
PIDconsumer --> PIDarch : "queries PID"
PIDarch ..> PIDconsumer : "resolves PID"
'Repo --> Repo : "manages Data"
PIDconsumer o--> PIDarch : "registers PID"
PIDarch <--o PIDconsumer : "accesses Prefix"
PIDarch *..> PIDconsumer : "issues credential"
'PIDarch ..> PIDarch : "resolves Prefix namespace"
'PIDarch *....> PIDarch : "retrieves allocated Prefix"
'PIDarch <....* PIDarch : "provides PID service info"
'PIDarch <..o PIDarch : "implements and runs PID service"
PIDconsumer *--> PIDarch : "requests Prefix"
```
## User and Repository are the PID consumers
The user's and repository's view of the global PID architecture is given in the following diagram
```plantuml
actor User as User
agent Repository as Repo
agent "global PID Architecture" as PIDarch
'database "PID Service" as PIDserv
'rectangle "Local PID Provider" as PIDprov
User o--> Repo : "registers Data"
User <--* Repo : "issues credential"
User --> Repo : "accesses Data"
User --> PIDarch : "queries PID"
'Repo --> Repo : "manages Data"
Repo o--> PIDarch : "registers/modifies PID"
PIDarch ..> User : "resolves PID"
PIDarch <--o Repo : "accesses Prefix"
PIDarch *..> Repo : "issues credential"
'PIDarch ..> PIDarch : "resolves Prefix namespace"
'PIDarch *....> PIDarch : "retrieves allocated Prefix"
'PIDarch <....* PIDarch : "provides PID service info"
'PIDarch <..o PIDarch : "implements and runs PID service"
Repo *--> PIDarch : "requests Prefix"
```
## Global PID Registration and Resolution with Repository and User
The local PID service together with an abstraction of the global PID
Registration and Resolution as well as Repository and User is given in the following diagram
```plantuml
actor User as User
agent Repository as Repo
agent "global PID Registration and Resolution" as PIDreg
database "PID Service" as PIDserv
rectangle "Local PID Provider" as PIDprov
User o--> Repo : "registers Data"
User <--* Repo : "issues credential"
User --> Repo : "accesses Data"
User --> PIDreg : "queries PID"
'Repo --> Repo : "manages Data"
Repo o--> PIDserv : "registers/modifies PID"
PIDserv ..> User : "resolves PID"
PIDserv <--o Repo : "accesses Prefix"
PIDserv *..> Repo : "issues credential"
PIDreg ..> PIDserv : "resolves Prefix namespace"
PIDreg *....> PIDprov : "retrieves allocated Prefix"
PIDreg <....* PIDprov : "provides PID service info"
PIDserv <..o PIDprov : "implements and runs PID service"
Repo *--> PIDreg : "requests Prefix"
```
## Global PID Registration and Resolution with PID Consumer
The local PID service together with an abstraction of the global PID
Registration and Resolution as well as PID Consumer is given in the following diagram
```plantuml
'actor User as User
'agent Repository as Repo
agent "PID consumer" as PIDconsumer
agent "global PID Registration and Resolution" as PIDreg
database "PID Service" as PIDserv
rectangle "Local PID Provider" as PIDprov
'User o--> Repo : "registers Data"
'User <--* Repo : "issues credential"
'User --> Repo : "accesses Data"
PIDconsumer --> PIDreg : "queries PID"
'Repo --> Repo : "manages Data"
PIDconsumer o--> PIDserv : "registers/modifies PID"
PIDserv ..> PIDconsumer : "resolves PID"
PIDserv <--o PIDconsumer : "accesses Prefix"
PIDserv *..> PIDconsumer : "issues credential"
PIDreg ..> PIDserv : "resolves Prefix namespace"
PIDreg *....> PIDprov : "retrieves allocated Prefix"
PIDreg <....* PIDprov : "provides PID service info"
PIDserv <..o PIDprov : "implements and runs PID service"
PIDconsumer *--> PIDreg : "requests Prefix"
```
## Internals of the Global PID Registration and Resolution
The same diagram with an unfolding of the internals of the global pid registration and resolution
```plantuml
'actor User
'actor "Type Registrar" as DTRboard
'actor "Organisation/Community" as Cmty
'agent Repository as Repo
agent "PID consumer" as PIDconsumer
database "PID Service" as PIDserv
database "Global PID Registry" as GPR
'database "Data Type Registry" as DTR
'database "Profile Registry" as ProfR
rectangle "Local PID Provider" as PIDprov
rectangle "Top-level Registration Authority" as TRA
rectangle "Second-level Registration Authority" as SRA
rectangle "Second-level Prefix Registrar" as SPR
PIDconsumer --> GPR : "queries PID"
PIDconsumer o--> PIDserv : "registers/modifies PID"
PIDserv ..> PIDconsumer : "resolves PID"
PIDserv <--o PIDconsumer : "accesses Prefix"
PIDserv *..> PIDconsumer : "issues credential"
SRA *..> SPR : "registers Prefix namespace"
SPR o..> GPR : "registers Prefix"
TRA o..> GPR : "assigns Prefix namespace"
TRA o..> GPR : "implements and runs GPR service"
TRA *..> SPR : "issues credential"
GPR ..> PIDserv : "resolves Prefix namespace"
SPR *....> PIDprov : "retrieves allocated Prefix"
SPR <....* PIDprov : "provides PID service info"
PIDserv <..o PIDprov : "implements and runs PID service"
PIDconsumer *--> SRA : "requests Prefix"
```
## Overview
The same diagram unfolding PID consumer into user and repository:
```plantuml
actor User
'actor "Type Registrar" as DTRboard
'actor "Organisation/Community" as Cmty
agent Repository as Repo
database "PID Service" as PIDserv
database "Global PID Registry" as GPR
'database "Data Type Registry" as DTR
'database "Profile Registry" as ProfR
rectangle "Local PID Provider" as PIDprov
rectangle "Top-level Registration Authority" as TRA
rectangle "Second-level Registration Authority" as SRA
rectangle "Second-level Prefix Registrar" as SPR
User o--> Repo : "registers Data"
User <--* Repo : "issues credential"
User --> Repo : "accesses Data"
User --> GPR : "queries PID"
'Repo --> Repo : "manages Data"
Repo o--> PIDserv : "registers/modifies PID"
PIDserv ..> User : "resolves PID"
PIDserv <--o Repo : "accesses Prefix"
PIDserv *..> Repo : "issues credential"
'Repo ..> DTR : "looks up Type"
SRA *..> SPR : "registers Prefix namespace"
SPR o..> GPR : "registers Prefix"
TRA o..> GPR : "assigns Prefix namespace"
TRA o..> GPR : "implements and runs GPR service"
TRA *..> SPR : "issues credential"
GPR ..> PIDserv : "resolves Prefix namespace"
SPR *....> PIDprov : "retrieves allocated Prefix"
SPR <....* PIDprov : "provides PID service info"
PIDserv <..o PIDprov : "implements and runs PID service"
Repo *--> SRA : "requests Prefix"
'DTRboard o--> DTR : "registers/modifies Type"
'DTRboard <--* DTR : "issues credential"
'PIDserv ..> DTR : "refers to Types"
'Cmty o--> ProfR : "registers/modifies Profile"
'Cmty <--* ProfR : "issues credential"
'Repo ..> ProfR : "looks up Profile"
'PIDserv ..> ProfR : "complies to Profile"
```
## Including Types and Profiles in Global PID Registration and Resolution with PID Consumer
The relations of types and profiles to the local PID service together with an
abstraction of the global PID Registration and Resolution as well as PID Consumer is given in the following diagram
```plantuml
'actor User as User
'agent Repository as Repo
agent "PID consumer" as PIDconsumer
agent "global PID Registration and Resolution" as PIDreg
database "PID Service" as PIDserv
rectangle "Local PID Provider" as PIDprov
agent "Type Registrar" as DTRboard
agent "Organisation/Community" as Cmty
database "Data Type Registry" as DTR
database "Profile Registry" as ProfR
'User o--> Repo : "registers Data"
'User <--* Repo : "issues credential"
'User --> Repo : "accesses Data"
PIDconsumer --> PIDreg : "queries PID"
'Repo --> Repo : "manages Data"
PIDconsumer o--> PIDserv : "registers/modifies PID"
PIDserv ..> PIDconsumer : "resolves PID"
PIDserv <--o PIDconsumer : "accesses Prefix"
PIDserv *..> PIDconsumer : "issues credential"
PIDreg ..> PIDserv : "resolves Prefix namespace"
PIDreg *....> PIDprov : "retrieves allocated Prefix"
PIDreg <....* PIDprov : "provides PID service info"
PIDserv <..o PIDprov : "implements and runs PID service"
PIDconsumer *--> PIDreg : "requests Prefix"
DTRboard o--> DTR : "registers/modifies Type"
DTRboard <--* DTR : "issues credential"
PIDserv ..> DTR : "refers to Types"
Cmty o--> ProfR : "registers/modifies Profile"
Cmty <--* ProfR : "issues credential"
PIDconsumer ..> ProfR : "looks up Profile"
PIDserv ..> ProfR : "complies to Profile"
```
## Overview Including Types and Profiles
The complete description of all internal relations including types and
profiles is given in the following diagram:
```plantuml
actor User
agent "Type Registrar" as DTRboard
agent "Organisation/Community" as Cmty
agent Repository as Repo
database "PID Service" as PIDserv
database "Global PID Registry" as GPR
database "Data Type Registry" as DTR
database "Profile Registry" as ProfR
rectangle "Local PID Provider" as PIDprov
rectangle "Top-level Registration Authority" as TRA
rectangle "Second-level Registration Authority" as SRA
rectangle "Second-level Prefix Registrar" as SPR
User o--> Repo : "registers Data"
User <--* Repo : "issues credential"
User --> Repo : "accesses Data"
User --> GPR : "queries PID"
'Repo --> Repo : "manages Data"
Repo o--> PIDserv : "registers/modifies PID"
PIDserv ..> User : "resolves PID"
PIDserv <--o Repo : "accesses Prefix"
PIDserv *..> Repo : "issues credential"
Repo ..> DTR : "looks up Type"
SRA *..> SPR : "registers Prefix namespace"
SPR o..> GPR : "registers Prefix"
TRA o..> GPR : "assigns Prefix namespace"
TRA o..> GPR : "implements and runs GPR service"
TRA *..> SPR : "issues credential"
GPR ..> PIDserv : "resolves Prefix namespace"
SPR *....> PIDprov : "retrieves allocated Prefix"
SPR <....* PIDprov : "provides PID service info"
PIDserv <..o PIDprov : "implements and runs PID service"
Repo *--> SRA : "requests Prefix"
DTRboard o--> DTR : "registers/modifies Type"
DTRboard <--* DTR : "issues credential"
PIDserv ..> DTR : "refers to Types"
Cmty o--> ProfR : "registers/modifies Profile"
Cmty <--* ProfR : "issues credential"
Repo ..> ProfR : "looks up Profile"
PIDserv ..> ProfR : "complies to Profile"
```
<<<<<<< HEAD
# Activities in a PID Architecture
=======
# UML Generator with PlantUML
## PlantUML in a nutshell
PlantUML is a component that allows to quickly write a couple of different
diagram types.
There are a few UML diagrams that are used in most situations in software development or systems modeling, including IT infrastructure and business systems. The top three UML diagrams that you should get comfortable with include use case diagrams, class diagrams (if you are a programmer), and sequence diagrams.
### Sequence diagram
Sequence diagrams are used to visualize both interactions within programs, business processes and IT infrastructures. They describe the sequence of interactions (messages) between actors and objects (things like databases or external interfaces).
```plantuml
Alice -> Bob: Authentication Request`
Bob --> Alice: Authentication Response`
Alice -> Bob: Another authentication Request`
Alice <-- Bob: another authentication Response`
```
```plantuml
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response
Alice -> Bob: Another authentication Request
Alice <-- Bob: another authentication Response
```
### Usecase diagram
Use case diagrams are created when you are looking at the requirements of your system or program.
They represent the functions or features, the actors and how these relate to each other (their relationships).
```plantuml
(First usecase)
(Another usecase) as (UC2)
usecase UC3
usecase (Last\nusecase) as UC4
UC3 -- UC4:related
```
```plantuml
(First usecase)
(Another usecase) as (UC2)
usecase UC3
usecase (Last\nusecase) as UC4
UC3 -- UC4:related
```
### Class diagram
Object oriented programming languages are based on classes and the relationships between them. UML class diagram notation was developed to represent these programs visually.
Classes contain their attributes (their data) and behaviors (member functions), and are related to each other with a variety of connectors.
```plantuml
Class01 "1" *-- "many" Class02 : contains
Class03 o-- Class04 : aggregation
Class05 --> "1" Class06
```
```plantuml
Class01 "1" *-- "many" Class02 : contains
Class03 o-- Class04 : aggregation
Class05 --> "1" Class06
```
```plantuml
Class01 <|-- Class02
Class03 *-- Class04
Class05 o-- Class06
Class07 .. Class08
Class09 -- Class10
```
```plantuml
Class01 <|-- Class02
Class03 *-- Class04
Class05 o-- Class06
Class07 .. Class08
Class09 -- Class10
```
```plantuml
Class11 <|.. Class12
Class13 --> Class14
Class15 ..> Class16
Class17 ..|> Class18
Class19 <--* Class20
```
```plantuml
Class11 <|.. Class12
Class13 --> Class14
Class15 ..> Class16
Class17 ..|> Class18
Class19 <--* Class20
```
```plantuml
Class21 #-- Class22
Class23 x-- Class24
Class25 }-- Class26
Class27 +-- Class28
Class29 ^-- Class30
```
```plantuml
Class21 #-- Class22
Class23 x-- Class24
Class25 }-- Class26
Class27 +-- Class28
Class29 ^-- Class30
```
### Activity diagram
Activity diagrams model the behavior of users and systems as they follow a process. They are a type of flow chart or workflow, but they use slightly different shapes.
```plantuml
start
:Hello world;
:This is on defined on
several **lines**;
stop
```
```plantuml
start
:Hello world;
:This is on defined on
several **lines**;
stop
```
### Component diagram
A component diagram shows how the various components in a complex software system relate to each other and communicate using interfaces. They aren’t used for simpler or straight-forward systems.
```plantuml
DataAccess - [First Component]
[First Component] ..> HTTP : use
```
```plantuml
DataAccess - [First Component]
[First Component] ..> HTTP : use
```
### State diagram
State diagrams have been used in programming to describe the various states that a system can be in for decades. They aren’t limited to programming – every system and process has states. These diagrams are faster to create than activity or sequence diagrams, but show less information.
State diagrams show which states lead to each other, and what triggers a change of state.
```plantuml
[*] --> State1
State1 --> [*]
State1 : this is a string
State1 : this is another string
State1 -> State2
State2 --> [*]
```
```plantuml
[*] --> State1
State1 --> [*]
State1 : this is a string
State1 : this is another string
State1 -> State2
State2 --> [*]
```
### Object diagram
Object diagrams in UML are a specialized form of class diagrams. They visualize the more abstract class diagrams as if they have been instantiated and help software developers check whether their abstract structures will work in practice.
```plantuml
object firstObject
object "My Second Object" as Object02
firstObject o-- "4" Object02
```
```plantuml
object firstObject
object "My Second Object" as Object02
firstObject o-- "4" Object02
```
### Deployment diagram
This is another specialized diagram for large and complex systems where software is deployed over multiple systems. These days, web services like Amazon Web Services (AWS) and Google Cloud Platform (GCP) have their own notations
```plantuml
actor actor
agent agent
artifact artifact
boundary boundary
card card
cloud cloud
component component
control control
database database
entity entity
file file
folder folder[
This is a <b>folder
----
You can use separator
====
of different kind
....
and style
]
frame frame
interface interface
node node
package package
queue queue
stack stack
rectangle rectangle
storage storage
usecase usecase
card --> cloud : label1
```
```plantuml
actor actor
agent agent
artifact artifact
boundary boundary
card card
cloud cloud
component component
control control
database database
entity entity
file file
folder folder[
This is a <b>folder
----
You can use separator
====
of different kind
....
and style
]
frame frame
interface interface
node node
package package
queue queue
stack stack
rectangle rectangle
storage storage
usecase usecase
card --> cloud : label1
```
### Timing diagram
This is a special type of sequence diagram that follows the behavior of objects over time. They are used more commonly when designing embedded systems, like programming control software for a washing machine.
```plantuml
robust "Web Browser" as WB
concise "Web User" as WU
@0
WU is Idle
WB is Idle
@100
WU -> WB : URL
WU is Waiting
WB is Processing
@300
WB is Waiting
```
```plantuml
robust "Web Browser" as WB
concise "Web User" as WU
@0
WU is Idle
WB is Idle
@100
WU -> WB : URL
WU is Waiting
WB is Processing
@300
WB is Waiting
```
## The following non-UML diagrams are also supported:
### Wireframe graphical interface
```plantuml
```
```plantuml
```
### Archimate diagram
```plantuml
```
```plantuml
```