Difference between revisions of "UBPML Referenz"
AndreasLeue (talk | contribs) |
AndreasLeue (talk | contribs) |
||
(One intermediate revision by the same user not shown) | |||
Line 58: | Line 58: | ||
| [[Image:UBPMLProcedure.png]] | | [[Image:UBPMLProcedure.png]] | ||
| {{T|Ein Schritt besschreibt, ''was'' getan werden, welche Veränderung stattfinden soll. Er legt nicht fest, ''wie'' dies geschieht. Dies erfolgt durch Zuordnung einer ''Prozedur'' zu einem Schritt. Prozeduren können verschiedenes sein: eine Handlungsanweisung für einen Mitarbeiter, eine verfeinerte Vorgehensweise oder eine maschinelle Operation (Aufruf eines Dienstes). Verfeinerte Vorgehensweisen wiederum können entweder aus UBPML Schritten oder aber aus BPMN- bzw. UML-Aktivitäten bestehen.|A Step describes ''what'' shall be done, which change shall happen. It does not fix ''how'' this is achieved. The latter happens by assigning a ''Procedure'' to the Step. There are different types of Procedures: manual instructions, a refined proceeding or execution of machine operations (invocation of a service). Refined proceedings then may be described with UBPML Steps or BPMN- resp. UML-activities.}} | | {{T|Ein Schritt besschreibt, ''was'' getan werden, welche Veränderung stattfinden soll. Er legt nicht fest, ''wie'' dies geschieht. Dies erfolgt durch Zuordnung einer ''Prozedur'' zu einem Schritt. Prozeduren können verschiedenes sein: eine Handlungsanweisung für einen Mitarbeiter, eine verfeinerte Vorgehensweise oder eine maschinelle Operation (Aufruf eines Dienstes). Verfeinerte Vorgehensweisen wiederum können entweder aus UBPML Schritten oder aber aus BPMN- bzw. UML-Aktivitäten bestehen.|A Step describes ''what'' shall be done, which change shall happen. It does not fix ''how'' this is achieved. The latter happens by assigning a ''Procedure'' to the Step. There are different types of Procedures: manual instructions, a refined proceeding or execution of machine operations (invocation of a service). Refined proceedings then may be described with UBPML Steps or BPMN- resp. UML-activities.}} | ||
| [[UML]] standard | |||
|- | |||
| [[Image:UBPMLProcess.png]] | |||
| {{T|Ein Prozess ist eine nach inhaltlichen Kriterien zusammengestellte, im weiteren aber beliebige Menge von Schritten, die zu durchaus verschiedenen Schrittklassen gehören können. Ein Prozeß ist insbseondere nicht das gleiche wie eine Schrittklasse. Das Beispiel zeigt eine Prozeßinstanz, die sowohl auf einen Schritt verweist,als auch auf eine Schrittklasse. Der Verweis zur Schrittklasse bedeutet, daß alle Instanzen dieser Klasse (Klassen Extension) zum Prozeß gehören. |A Process is set of step classes assembled by criteria with regards to content. These steps may belong to quite different Step classes. Specifically, a Process is not the same as a Step class. The example shows a Process instance referring to both a Step instance as well as a Step class. The reference to Step class denotes that all instances of that class (class extent) belong to the Process.}} | |||
| [[UML]] standard | | [[UML]] standard | ||
|- | |- | ||
Line 94: | Line 98: | ||
| [[Image:UBPMLStepAttributes.png]] | | [[Image:UBPMLStepAttributes.png]] | ||
| {{T|Da Schritte auch Klassen sind, können sie wie diese natürlich auch Attribute aufweisen. Die Befüllung der Attribute zu Beginn und zum Ende kann an den Transformations-Relationen angegeben werden.|Since Steps are classes, of course they may contain attributes. The initial and final values of these attributes at the beginning and end of the transformation can be specified at the transformation relations.}} | | {{T|Da Schritte auch Klassen sind, können sie wie diese natürlich auch Attribute aufweisen. Die Befüllung der Attribute zu Beginn und zum Ende kann an den Transformations-Relationen angegeben werden.|Since Steps are classes, of course they may contain attributes. The initial and final values of these attributes at the beginning and end of the transformation can be specified at the transformation relations.}} | ||
| [[UML]] standard | |||
|- | |||
| [[Image:UBPMLStepWithTools.png]] | |||
| {{T|Schritte können als Klassen auch auf weitere Klassen oder Objekte verweisen, die nicht verändert werden und mit denen kein primärer Informationsaustausch stattfindet. Solche Objekte sind typischerweise Werkzeuge und andere Hilfsmittel.|Steps as classes can refer to further classes or objects, which are not changed and no primary information flow takes place. Such objects are typically tools or further supporting material.}} | |||
| [[UML]] standard | | [[UML]] standard | ||
|- | |- |
Latest revision as of 20:15, 23 February 2011
UBPML Notation
Download UBPML Notation Overview in PDF format
Notation
|
Semantics
|
Conformity
|
---|---|---|
A class
|
UML standard | |
An instance of a class
|
UML standard | |
A class in a certain state
|
UBPML | |
A class in a certain state. The state itself is also declared here, and that by specifying a condition, which true and only true if that state is given.
|
UBPML | |
An instance of a class in a certain state.
|
UML standard (seit 2.0 in Aktivitätsdiagrammen) | |
A certain system state, defined by a set of classes (i.e a Constellation) in certain states, as well as optionally additional constraints that have to be met by that classes and their relationships. A Constellation is a UML class, i.e. dervied from Class in the metamodel.
|
UBPML | |
An instance of a Constellation, i.e. a set of instances in certain states, which satisfy the constraints of the Constellation-class.
|
UBPML | |
A Step denotes a change (transformation) of the system from one constellation into possibly several alternative other ones. It is thereby the elementary unit of a planned change. A Step is a UML class, i.e. dervied from Class in the metamodel.
|
UBPML | |
An instance of a Step. Diagrams containing Step instances may serve to describe Projects. Thereby it is possible to describe Projects and Processes within one uniform notation.
|
UBPML | |
A Step describes what shall be done, which change shall happen. It does not fix how this is achieved. The latter happens by assigning a Procedure to the Step. There are different types of Procedures: manual instructions, a refined proceeding or execution of machine operations (invocation of a service). Refined proceedings then may be described with UBPML Steps or BPMN- resp. UML-activities.
|
UML standard | |
A Process is set of step classes assembled by criteria with regards to content. These steps may belong to quite different Step classes. Specifically, a Process is not the same as a Step class. The example shows a Process instance referring to both a Step instance as well as a Step class. The reference to Step class denotes that all instances of that class (class extent) belong to the Process.
|
UML standard | |
Each Step is associated with exactly one initial Constellation, as well as at least one but possibly several final, mutual exclusive ones. The relationship arrows are borrowed from state transition diagrams (transitions) and named Transformation here.
|
UBPML | |
An instance of a Step connected to Constellation instances. This notation is useful e.g. in project diagrams.
|
UBPML | |
Shows the details of an constellation as an aggregation: a Constellation consistsof classes in a certain state, these classes are shown.
|
UBPML | |
Shows the details of a Constellation instance as an aggregation
|
UBPML | |
Alternative way of showing the details of a Constellation, corresponds to the previous presentation as an aggregation.
|
UBPML | |
Alternative way of showing the details of a Constellation instance
|
UBPML | |
Instead of showing a Constellation the constituting classes in a certain state are directly connected to the Step. This is just a simpler way of presentation, there are implicitly (anonymous) Constellations defined, too. If a class in a certain state is referenced multiply in different roles, the rolenames are used to ditinguish this.
|
UBPML | |
Since one and the same resulting class might exist within several target Constellations, the respective Constellations can be declared as relationship conditions.
|
UBPML | |
Since Steps are classes, of course they may contain attributes. The initial and final values of these attributes at the beginning and end of the transformation can be specified at the transformation relations.
|
UML standard | |
Steps as classes can refer to further classes or objects, which are not changed and no primary information flow takes place. Such objects are typically tools or further supporting material.
|
UML standard | |
A multiplicity of 1 at the initial transformation arrow at the side of the Step says, that for each initial Constellation instance exactly one Step shall exist. In other words, the processing is initiated automatically. Alternatively, by declaring a sequence of points in time (e.g. "1st monday of each month" ) at a timer symbol, a automatically recurring instantiation is defined. E.g., this is useful if the existence of initial raw material is desired.
|
UML standard/UBPML | |
This symbol associates an error state condition to an arbitrary class of a UML model, basically it is just a simplified notation of a UML condition. By associating such conditions to Steps also gradually problematic - and not just fatal - processing conditions can be expressed and made analyzable.
|
UBPML | |
Possible problem states
|
UBPML | |
By attaching Actors to processing steps it's responsibility is expressed. There are different types of responsibility available.
|
UBPML | |
Possible responsibility types.
|
UBPML | |
Also classes in a certain state are derivable from each other.
|
UML standard | |
As classes also Steps can be derived from each other.
|
UBPML | |
It might be useful in project diagrams to express the completion of a state partially.
|
UBPML | |
Also "Locations" are just a special kind of States, therefore the transfer of an object is expressed in the same way.
|
UBPML | |
This notation, which is just a simplifying form, the transfer of objects is shown clearly. The presentation is intentionally similar to swimlanes.
|
UBPML |