|
 |
|
|
Business process diagram |
|
Visualize inner and inter organizations operations with Business Process Modeling Notation (BPMN). Logizian supports BPMN 2.0 notations and comes with a bunch of diagramming toolset like voice documentation, sweeper and magnet.
|
|
|
Business process diagram
|
Conversation diagram
|
Data flow diagram
|
EPC diagram
|
Process map diagram
|
Organization chart
|
|
|
|
|
Business process diagram |
|
|
|
Notation
 | | Start Event |  | | Intermediate Event | |  | | End Event |  | | Pool | |  | | Lane |  | | Task | |  | | Sub-Process |  | | Gateway | |  | | Group |  | | Choreography Task | |  | | Choreography Sub-Process |  | | Call Activity | |  | | Call Choreography Activity |  | | Text Annotation | |  | | Data Object |  | | Data Input | |  | | Data Output |  | | Data Store | |  | | Sequence Flow |  | | Message Flow | |  | | Association | |
| DefinitionVisualize inner and inter organizations operations with Business Process Modeling Notation (BPMN). Logizian supports BPMN 2.0 notations and comes with a bunch of diagramming toolset like voice documentation, sweeper and magnet. |
|
| |
Start Event | |  | | Definition | | A Start Event indicates where a particular Process will start. In terms of Sequence Flow, the Start Event starts the flow of the Process, and thus, will not have any incoming Sequence Flow. No Sequence Flow can connect to a Start Event. |
| | Properties | | | Name | The name of start event. | | ID | Used to uniquely identify BPMN elements. | | Trigger | The Trigger for a Start Event is designed to show the general mechanisms that will instantiate that particular Process. Below is a list of available triggers:
| None | The None Start Event does not have a defined trigger. | | Message | A Message arrives from a Participant and triggers the start of the Process. | | Timer | A specific time-date or a specific cycle (e.g. every Monday at 9am) can be set that will trigger the start of the Process. | | Conditional | This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The Condition Expression for the Event must become false and then true before the Event can be triggered again. | | Signal | A Signal arrives that has been broadcast from another Process and triggers the start of the Process. Note that the Signal is not a Message, which has a specific target for the Message. Multiple Processes can have Start Events that are triggered from the same broadcasted Signal. | | Multiple | This means that there are multiple ways of triggering the Process. Only one of them is required. | | Parallel Multiple | This means that there are multiple triggers required before the Process can be instantiated. All of the types of triggers that are listed in the Start Event MUST be triggered before the Process is instantiated. |
| | Assignments | An assignment can be used to specify a simple mapping of data elements using a specified expression language. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. | | Documentation | Used to annotate the start event, such as descriptions and other documentation. |
|
|
|
| | | Intermediate Event | |  | | Definition | | As the name implies, the Intermediate Event indicates where something happens (an Event) somewhere between the start and end of a Process. It will affect the flow of the Process, but will not start or (directly) terminate the Process. |
| | Properties | | | Name | The name of intermediate event. | | ID | Used to uniquely identify BPMN elements. | | Trigger | When a token arrives at an Intermediate Event that is placed within the normal flow of a Process, one of two things will happen. If the Event is used to "throw" the Event Trigger, then Trigger of the Event will immediately occur (e.g., the Message will be sent) and the token will move down the outgoing Sequence Flow. If the Event is used to "catch" the Event Trigger, then the token will remain at the Event until the Trigger occurs (e.g., the Message is received). Then the token will move down the outgoing Sequence Flow. | | Assignments | An assignment can be used to specify a simple mapping of data elements using a specified expression language. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. | | Documentation | Used to annotate the intermediate event, such as descriptions and other documentation. |
|
|
|
| | | End Event | |  | | Definition | | The End Event indicates where a Process will end |
| | Properties | | | Name | The name of end event. | | ID | Used to uniquely identify BPMN elements. | | Result | Define the consequence of reaching an End Event. | | Assignments | An assignment can be used to specify a simple mapping of data elements using a specified expression language. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. | | Documentation | Used to annotate the end event, such as descriptions and other documentation. |
|
|
|
| | | Pool | |  | | Definition | | A Pool represents a Participant in a Collaboration or a Choreography. |
| | Properties | | | Name | The name of pool. | | ID | Used to uniquely identify BPMN elements. | | Process | The process the pool contains | | Participant | A Participant represents a specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that Participants in a Collaboration | | Children | Flow elements within the pool | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. | | Documentation | Used to annotate the pool, such as descriptions and other documentation. | | Black box | An empty pool that does not contain a process. |
|
|
|
| | | Lane | |  | | Definition | | A Lane is a sub-partition within a Pool or a Process. |
| | Properties | | | Name | The name of lane. | | ID | Used to uniquely identify BPMN elements. | | Parent lane | The lane that contains this lane. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. | | Documentation | Used to annotate the lane, such as descriptions and other documentation. |
|
|
|
| | | Task | |  | | Definition | | A Task is an atomic Activity within a Process flow. A Task is used when the work in the Process cannot be broken down to a finer level of detail. |
| | Properties | | | Name | The name of task. | | ID | Used to uniquely identify BPMN elements. | | Type | There are different types of Tasks identified within BPMN to separate the types of inherent behavior that Tasks might represent. Below is a list of available types:
| Abstract | A Task which is not further specified is called Abstract Task | | Service | A Service Task is a Task that uses some sort of service, which could be a Web service or an automated application. | | Send | A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process). Once the Message has been sent, the Task is completed. | | Receive | A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Once the Message has been received, the Task is completed. | | User | A User Task is a typical "workflow" Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort. | | Manual | A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location. | | Business Rule | A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The InputOutputSpecification of the Task will allow the Process to send data to and receive data from the Business Rules Engine. | | Script | A Script Task is executed by a business process engine. The modeler or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed. |
| | Loop type | Activities may be repeated sequentially, essentially behaving like a loop. | | Process type | The type of process. | | Status | The current state of this activity instance. | | Start quantity | This attribute defines the number of tokens that must arrive before the Activity can begin. | | Completion quantity | This attribute defines the number of tokens that must be generated from the Activity. This number of tokens will be sent done any outgoing Sequence Flow | | Data Objects | The data objects attached to the task. | | Documentation | Used to annotate the task, such as descriptions and other documentation. | | Compensation | This attribute defines the number of tokens that must be generated from the Activity. | | Enable instance compensation | A flag that identifies whether this activity is intended for the purposes of compensation. If false, then this activity executes as a result of normal execution flow. If true, this activity is only activated when a Compensation Event is detected and initiated under Compensation Event visibility scope | | Procedures | The working procedure of task. | | Assignments | An assignment can be used to specify a simple mapping of data elements using a specified expression language. | | Properties | Modeler-defined properties MAY be added to an Activity. These properties are "local" to the Activity. | | Input Sets | Activities and Processes often required data in order to execute. In addition they may produce data during or as a result of execution. Data requirements are captured as Data Inputs and Input Sets. | | Output Sets | Activities and Processes often required data in order to execute. In addition they may produce data during or as a result of execution. Data that is produced is captured using Data Outputs and Output Sets. | | Resources | Defines the resource that will perform or will be responsible for the activity. The resource, e.g. a performer, can be specified in the form of a specific individual, a group, an organization role or position, or an organization. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Sub-Process | |  | | Definition | | A Sub-Process is an Activity whose internal details have been modeled using Activities, Gateways, Events, and Sequence Flow. |
| | Properties | | | Name | The name of sub-process. | | ID | Used to uniquely identify BPMN elements. | | Type | There are different types of Sub-Processes. Below is a list of available types:
| Embedded Sub-Process | The Sub-Process can be in a collapsed view that hides its details or a Sub-Process can be in an expanded view that shows its details within the view of the Process in which it is contained. In the collapsed form, the Sub-Process object uses a marker to distinguish it as a Sub-Process, rather than a Task. | | Reusable Sub-Process | A Reusable Sub-Process identifies a point in the Process where a global Process or a Global Task is used. | | Reference Sub-Process | There may be times where a modeler may want to reference another Sub-Process that has been defined. If the two Sub- Processes share the exact same behavior and properties, then by one referencing the other, the attributes that define the behavior only have to be created once and maintained in only one location. |
| | Loop type | Activities may be repeated sequentially, essentially behaving like a loop. | | Process type | The type of process. | | Status | The current state of this activity instance. | | Start quantity | This attribute defines the number of tokens that must arrive before the Activity can begin. | | Completion quantity | This attribute defines the number of tokens that must be generated from the Activity. This number of tokens will be sent done any outgoing Sequence Flow | | Data Objects | The data objects attached to the task. | | Documentation | Used to annotate the sub-process, such as descriptions and other documentation. | | Compensation | This attribute defines the number of tokens that must be generated from the Activity. | | Is transaction | A Transaction is a specialized type of Sub-Process which will have a special behavior that is controlled through a transaction protocol | | Enable instance compensation | A flag that identifies whether this activity is intended for the purposes of compensation. If false, then this activity executes as a result of normal execution flow. If true, this activity is only activated when a Compensation Event is detected and initiated under Compensation Event visibility scope | | Triggered by event | A flag that identifies whether this Sub-Process is an Event Sub-Process. If false, then this Sub-Process is a normal Sub-Process. If true, the this Sub-Process is an Event Sub-Process and is subject to additional constraints. | | Procedures | The working procedure of sub-process. | | Assignments | An assignment can be used to specify a simple mapping of data elements using a specified expression language. | | Properties | The working procedure of sub-process. | | Input Sets | Activities and Processes often required data in order to execute. In addition they may produce data during or as a result of execution. Data requirements are captured as Data Inputs and Input Sets. | | Output Sets | Activities and Processes often required data in order to execute. In addition they may produce data during or as a result of execution. Data that is produced is captured using Data Outputs and Output Sets. | | Resources | Defines the resource that will perform or will be responsible for the activity. The resource, e.g. a performer, can be specified in the form of a specific individual, a group, an organization role or position, or an organization. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Gateway | |  | | Definition | | Gateways are used to control how the Process flows (how Tokens flow) through Sequence Flow as they converge and diverge within a Process. If the flow does not need to be controlled, then a Gateway is not needed. The term 'gateway' implies that there is a gating mechanism that either allows or disallows passage through the Gateway, that is, as tokens arrive at a Gateway, they can be merged together on input and/or split apart on output as the Gateway mechanisms are invoked. |
| | Properties | | | Name | The name of gateway. | | ID | Used to uniquely identify BPMN elements. | | Type | Gateways can define all the types of Business Process Sequence Flow behavior: Decisions/branching (exclusive, inclusive, and complex), merging, forking, and joining. Thus, while the diamond has been used traditionally for exclusive decisions, BPMN extends the behavior of the diamonds to reflect any type of Sequence Flow control. Each type of Gateway will have an internal indicator or marker to show the type of Gateway that is being used
| Data-Based Exclusive Decision/Merge (XOR) | A diverging Exclusive Gateway (Decision) is used to create alternative paths within a Process flow. This is basically the 'diversion point in the road' for a Process. For a given instance of the Process, only one of the paths can be taken. | | Event-Based Exclusive Decision/Merge (XOR) | The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on Events that occur, rather than the evaluation of Expressions using Process data (as with an Exclusive or Inclusive Gateway). A specific Event, usually the receipt of a Message, determines the path that will be taken. Basically, the decision is made by another Participant, based on data that is not visible to Process, thus, requiring the use of the Event-Based Gateway. | | Inclusive Decision/Merge (OR) | A diverging Inclusive Gateway (Inclusive Decision) can be used to create alternative but also parallel paths within a Process flow. Unlike the Exclusive Gateway, all condition expressions are evaluated. The true evaluation of one condition expression does not exclude the evaluation of other condition expressions. All Sequence Flow with a true evaluation will be traversed by a Token. Since each path is considered to be independent, all combinations of the paths may be taken, from zero to all. However, it should be designed so that at least one path is taken. | | Complex Decision/Merge | The Complex Gateway can be used to model complex synchronization behavior. An Expression activationCondition is used to describe the precise behavior. For example, this Expression could specify that tokens on three out of five incoming Sequence Flow are needed to activate the Gateway. What tokens are produced by the Gateway is determined by conditions on the outgoing Sequence Flow as in the split behavior of the Inclusive Gateway. If token arrive later on the two remaining Sequence Flow, those tokens cause a reset of the Gateway and new token can be produced on the outgoing Sequence Flow. To determine whether it needs to wait for additional tokens before it can reset, the Gateway uses the synchronization semantics of the Inclusive Gateway. | | Parallel Fork/Join (AND) | A Parallel Gateway is used to synchronize (combine) parallel flows and to create parallel flows. |
| | Direction | An attribute that adds constraints on how the gateway may be used.
| unspecified | There are no constraints. The Gateway MAY have any number of incoming and outgoing Sequence Flow. | | converging | This Gateway MAY have multiple incoming Sequence Flow but MUST have no more than one outgoing SequenceFlow. | | diverging | This Gateway MAY have multiple outgoing Sequence Flow but MUST have no more than one incoming Sequence Flow. | | mixed | This Gateway contains multiple outgoing and multiple incoming Sequence Flow. |
| | Assignments | An assignment can be used to specify a simple mapping of data elements using a specified expression language. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. | | Documentation | Used to annotate the gateway, such as descriptions and other documentation. |
|
|
|
| | | Group | |  | | Definition | | A Group is a grouping of Activities that are within the same Category. |
| | Properties | | | Name | The name of group. | | ID | Used to uniquely identify BPMN elements. | | Documentation | Used to annotate the group, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Choreography Task | |  | | Definition | | A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which is a coherent set (1 or more) of Message exchanges between two (2) Participants. |
| | Properties | | | Name | The name of choreography task. | | Participant 1 | The first participant within the interaction. | | Participant 2 | The second participant within the interaction. | | Initiating participant | The participant that initiates the interaction. | | ID | Used to uniquely identify BPMN elements. | | Loop type | Activities may be repeated sequentially, essentially behaving like a loop. | | Documentation | Used to annotate the choreography task, such as descriptions and other documentation. | | Procedures | The working procedure of task. | | Message Flows | Although not graphical represented, Choreography Task contain one (1) or more Message Flow that represent the interaction(s) between the Participants referenced by the Choreography Task. |
|
|
|
| | | Choreography Sub-Process | |  | | Definition | | A Choreography Sub-Process is a compound Activity in that it has detail that is defined as a flow of other Activities, in this case, a Choreography. Each Choreography Sub-Process involves two (2) or more Participants. |
| | Properties | | | Name | The name of choreography sub-process. | | ID | Used to uniquely identify BPMN elements. | | Loop type | Activities may be repeated sequentially, essentially behaving like a loop. | | Documentation | Used to annotate the choreography sub-process, such as descriptions and other documentation. | | Procedures | The working procedure of task. | | Participants | The participants that involve in the choreography sub-process. |
|
|
|
| | | Call Activity | |  | | Definition | | A Call Activity identifies a point in the Process where a global Process or a Global Task is used. The Call Activity acts as a "wrapper" for the invocation of a global Process or Global Task within the execution. The activation of a call Activity results in the transfer of control to the called global Process or Global Task. |
| | Properties | | | Name | The name of call activity. | | Called element | The element to be called. | | Documentation | Used to annotate the call activity, such as descriptions and other documentation. |
|
|
|
| | | Call Choreography Activity | |  | | Definition | | A Call Choreography Activity identifies a point in the Process where a global Choreography or a Global Choreography Task is used. The Call Choreography Activity acts as a place holder for the inclusion of the Choreography element it is calling. This pre-defined called Choreography element becomes a part of the definition of the parent Choreography. |
| | Properties | | | Name | The name of call choreography activity. | | Called element | The element to be called. | | Documentation | Used to annotate the call choreography activity, such as descriptions and other documentation. |
|
|
|
| | | Text Annotation | |  | | Definition | | Text Annotations are a mechanism for a modeler to provide additional information for the reader of a BPMN Diagram. |
| | Properties | | | Name | The name of text annotation. | | ID | Used to uniquely identify BPMN elements. | | Text | Text is an attribute that is text that the modeler wishes to communicate to the reader of the Diagram. | | Documentation | Used to annotate the text annotation, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Data Object | |  | | Definition | | The primary construct for modeling data within the Process flow is the DataObject element. |
| | Properties | | | Name | The name of data object. | | ID | Used to uniquely identify BPMN elements. | | State | Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object | | Item subject | Data object represent items that are manipulated, transferred, transformed or stored during Process flows. These items can be either physical items, such as the mechanical part of a vehicle, or information items such the catalog of the mechanical parts of a vehicle. | | Required for start | The default value for this attribute is True. This means that the Input is required for an activity to start. If set to False, then the activity MAY start within the input if it is available, but MAY accept the input (more than once) after the activity has started. | | Produced at completion | The default value for this attribute is True. This means that the Output will be produced when an activity has been completed. If set to False, then the activity MAY produce the output (more than once) before it has completed. | | Documentation | Used to annotate the data object, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Data Input | |  | | Definition | | Activities and Processes often required data in order to execute. In addition they may produce data during or as a result of execution. Data requirements are captured as Data Inputs and Input Sets. |
| | Properties | | | Name | The name of data input. | | ID | Used to uniquely identify BPMN elements. | | State | DataInput elements can optionally reference a DataState element, which is the state of the data contained in the DataInput. The definition of these states, e.g. possible values, and any specific semantics are out of scope of this specification. | | Item subject | Data input represent items that are manipulated, transferred, transformed or stored during Process flows. These items can be either physical items, such as the mechanical part of a vehicle, or information items such the catalog of the mechanical parts of a vehicle. | | Documentation | Used to annotate the data input, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Data Output | |  | | Definition | | Activities and Processes often required data in order to execute. In addition they may produce data during or as a result of execution. Data that is produced is captured using Data Outputs and Output Sets. |
| | Properties | | | Name | The name of data output. | | ID | Used to uniquely identify BPMN elements. | | State | DataOutput elements can optionally reference an DataState element, which is the state of the data contained in the DataOutput. The definition of these states, e.g. possible values, and any specific semantics are out of scope of this specification. | | Item subject | Data output represent items that are manipulated, transferred, transformed or stored during Process flows. These items can be either physical items, such as the mechanical part of a vehicle, or information items such the catalog of the mechanical parts of a vehicle. | | Documentation | Used to annotate the data output, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Data Store | |  | | Definition | | A DataStore provides a mechanism for Activities to retrieve or update stored information that will persist beyond the scope of the Process. The same DataStore can be visualized, through a Data Store Reference, in one (1) or more places in the Process. |
| | Properties | | | Name | The name of data store. | | ID | Used to uniquely identify BPMN elements. | | Capacity | Defines the capacity of the Data Store. | | Item subject | Data store represent items that are stored during Process flows. These items can be either physical items, such as the mechanical part of a vehicle, or information items such the catalog of the mechanical parts of a vehicle. | | Documentation | Used to annotate the data store, such as descriptions and other documentation. | | Unlimited | If true, then the capacity of a Data Store is set as unlimited and will override any value of the capacity attribute. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Sequence Flow | |  | | Definition | | A Sequence Flow is used to show the order of Flow Elements in a Process or a Choreography. Each Sequence Flow has only one source and only one target. |
| | Properties | | | Name | The name of sequence flow. | | ID | Used to uniquely identify BPMN elements. | | From | The FlowNode that the Sequence Flow is connecting from. | | To | The FlowNode that the Sequence Flow is connecting to. | | Condition type | An optional Boolean Expression that acts as a gating condition. A token will only be placed on this Sequence Flow if this conditionExpression evaluates to true. | | Data Objects | The data objects attached to the task. | | Condition expression | An optional Boolean Expression that acts as a gating condition. | | Documentation | Used to annotate the sequence flow, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Message Flow | |  | | Definition | | A Message Flow is used to show the flow of Messages between two Participants that are prepared to send and receive them. |
| | Properties | | | Name | The name of message flow. | | ID | Used to uniquely identify BPMN elements. | | From | The node that the Message Flow is connecting from. | | To | The node that the Message Flow is connecting to. | | Data Objects | The data objects attached to the task. | | Message | Identifies the Message that is being sent. | | Documentation | Used to annotate the message flow, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
| | | Association | |  | | Definition | | A data association is used to model how data is pushed into or pulled from item-aware elements |
| | Properties | | | Name | The name of association. | | ID | Used to uniquely identify BPMN elements. | | From | Identifies the source of the data association. | | To | Identifies the target of the data association. | | Direction | The direction of association | | Documentation | Used to annotate the association, such as descriptions and other documentation. | | Categories | Categories have user-defined semantics for documentation or analysis purposes. For example, flow elements can be categorized has being customer oriented vs. support oriented. The value attribute specifies one or more values of the category. |
|
|
|
|
| |
| Definition of notations is quoted from Object Management Group Unified Modeling Language (OMG UML) Superstructure Version 2.2 and former versions (for notations that do not exist anymore in latest specification). |
| |
|
Business process diagram
|
Conversation diagram
|
Data flow diagram
|
EPC diagram
|
Process map diagram
|
Organization chart
|
|
|
|
|
 |
|
