Team 1

• Georg Prenner, 0306299@unet.univie.ac.at 
• Alexander Rotheneder, 0503810@unet.univie.ac.at 
• Christopher Pfleger, 0608535@unet.univie.ac.at 

Szenario-X: Untersuchung im Krankenhaus (Aufgabe 1)

Abbildung 1: Untersuchung

Variante A

Abbildung 2: Untersuchung Variante A

• Löschen des Pools Krankenschwester 
• Verschiebung der Tasks aus „Krankenschwester“ zu „Arzt“ 
• Auflösen der Parallelität Labor/Sozialanamnese 
• Einfügen einer Entscheidung nach Task „Labor“ 
• Verzweigung zu Task „Entlassung“ einfügen (Patient ist gesund) 
• Verzweigung zu Task „Sozialanamnese“ einfügen (Patient lügt) 
• Einfügen einer Entscheidung nach vorheriger Entscheidung (Patient krank) 
• Einfügen des Tasks „Stationäre Aufnahme“ als Alternative zu „Behandlung“ 
• Einfügen des zweiten Endergebnisses nach Task „Stationäre Aufnahme“ 

Variante B

Abbildung 3: Untersuchung Variante B

• Einfügen einer Entscheidung nach Parallelitäts-Join „Labor“ 
• Verzweigung zu Task „Entlassung“ einfügen (Patient ist gesund) 
• Verzweigung zu Task „Sozialanamnese“ einfügen (Patient lügt) 
• Verzweigung zu Task „Behandlung“ einfügen (Patient krank) 

Aufgabe 2-1: Differenzen

Von Szenario X zu Prozess A

1. Verschiebung der Tasks aus dem Pool Krankenschwester zu Arzt 
2. Löschen des Pools Krankenschwester  
3. Verschieben des Tasks Labor nach Sozialanamnese 
4. Einfügen einer Entscheidung nach Task Labor 
5. Verzweigung zu Task Entlassung einfügen (Der Patient ist gesund)  
6. Verzweigung zu Task Sozialanamnese einfügen (Der Patient lügt)  
7. Einfügen einer Entscheidung nach vorheriger Entscheidung (Der Patient krank)  
8. Einfügen des Tasks Stationäre Aufnahme als Alternative zu Behandlung  
9. Einfügen des zweiten Endergebnisses nach Task Stationäre Aufnahme 
10. Aufräumen: Löschen der leeren Parallelität 

Von Szenario X zu Prozess B

1. Einfügen einer Entscheidung nach dem Parallelitäts-Join Labor 
2. Verzweigung zu Task Entlassung einfügen (Der Patient ist gesund)  
3. Verzweigung zu Task Sozialanamnese einfügen (Der Patient lügt)  
4. Verzweigung zu Task Behandlung einfügen (Der Patient ist krank)  

a.)

b.)

c.)

PseudoCode Variante: Szenario X

PseudoCode Variante: Prozess A

PseudoCode Variante: Prozess B

c.) Diff Pseudocode Variante von X nach A

XML Variante: Szenario X

XML Variante: Prozess A

XML Variante: Prozess B

Beschreibung: XML Struktur

Idee & Zielsetzung der Repräsentation

Diff:

Pseudo Code

1. Finde die Anzahl/Typ/Name der Knoten in den Prozessen 
2. Definiere welche Knoten entweder hinzugefügt oder entfernt wurden.  
3. Finden der longest common subsequenc auf Basis der ID Refs  
4. Definiere an welchem Punkt (ID,PRE,TARGET) Änderungen vorgenommen werden müssen.  
5. Erstellen des changesets  

Beispiel: Einfügen eines tasks

1. Vergebe eine ID für den neuen TASK 
2. Setze die Nachfolger ID 
3. Setze die Vorgänger ID 
4. Vom Nachfolger die Vorgänger ID ändern 
5. Vom Vorgänger die Nachfolger ID ändern 

d.)

Differenzen zwischen Prozess A und Prozess B mittels XML Repräsentation

Beispiel DIFF für Prozess X nach Prozess A

Aufgabe 2-2: Merge

1. Auflösen der Parallelität Labor/Sozialanamnese 
2. Einfügen einer Entscheidung nach Task „Labor“ 
3. Verzweigung zu Task „Entlassung“ einfügen (Patient ist gesund) 
4. Verzweigung zu Task „Sozialanamnese“ einfügen (Patient lügt) 
   ….. 

a.) Einfacher Merge

Abbildung 4: Untersuchung Variante C

Abbildung 5: Untersuchung Variante D

Merge Szenario (C) mit Szenario (D)

b.) Prozesse E und F

Abbildung 6: Untersuchung Variante E

Abbildung 7: Untersuchung Variante F

Merge Szenario (E) mit Szenario (F)

c.) Prozesse G und H

Abbildung 8: Untersuchung Variante G

Abbildung 9: Untersuchung Variante H

Merge Szenario (G) mit Szenario (H)

d.) Probleme beim Merging

e.) Probleme der schrittweisen Anleitung

Verbesserungsvorschlag

Aufgabe 3: Maschinenunterstuezte Differenzen

Abbildung 10: Untersuchung

Abbildung 11: Untersuchung Variante A

Abbildung 12: Untersuchung Variante G

Repräsentation: Bedingungen

1. Jeder Knoten hat eine eindeutige ID. Eine ID bezieht sich immer auf den Namen eines jeden Knotens. IDs bzw. Namen sind auch Kontext abhängig (conditions und branches) 
2. IDs werden einmal vergeben. Ein Task mit dem Namen "Test" kann immer nur eine ID haben. "Test2" hat mit Sicherheit eine andere ID. Diese Einschränkung wird gerechtfertigt,  

1. Start kann es nur einmal geben und hat immer einen Nachfolger der nicht End sein darf. 
2. Tasks haben immer Vorgänger und Nachfolger  
3. Conditions haben keinen Nachfolger (denn es kann mehrere geben, sodass nicht eindeutig definiert) sondern nur einen Vorgänger 
4. Branches haben immer einen Vorgänger und einen Nachfolger 
5. Parallel Start hat immer einen Vorgänger und einen type s 
6. Parallel End hat immer einen Nachfolger und einen type e 
7. End hat einen Vorgänger und keinen Nachfolger (kann mehrfach existieren) 
8. Alle nodes haben ein value, welches elementar ist 

Beispiel: diffx FROM:X TO:A

Erklärung des diffs

1. Diff = Wie komme ich von einem Prozess zu einem anderen Prozess 
2. Idee: Mengenbasierter Ansatz 
3. Alle Elemente die aus dem Ausgangsprozess gelöscht wurden 
4. Alle Elemente die hinzugefügt wurden 
5. Alle Elemente die zwar in beiden Prozessen vorkommen, aber in einer anderen Anordnung (moved) 
6. Alle Sequenzen die in beiden Prozessen vorkommen. (Eine Sequenz besteht aus min. 2 oder mehr zusammenhängenden Elementen) 
7. Alle diese Mengen müssen nun zusammengesetzt werden (change Anweisung: wähle Element mit der id=xy und ändere ihre pre || target auf ID=xyz) 

Algorithmus

1. Finde alle Elemente die aus dem Ausgangsprozess gelöscht wurden. 
2. Finde alle Elemente die zum Zielprozess hinzugefügt wurden. 
3. Finde alle Sequenzen in der Menge der Elemente die in beiden Prozessen enthalten sind.  
4. Nach diesem Schritt muss nachvollziehbar gemacht werden, wie die Elemente und Sequenzen verbunden werden können. 
5. Sequenzen müssen/können nur am Anfang bzw. am Ende modifiziert werden ⇒ Anfang/Ende durchsuchen und mit Zielprozess vergleichen 
6. Moved Items werden nach dem selben Schema zugeordnet 
7. Erstellen der change Anweisungen 

diffx tool

• Programmiersprache: C++ 
• Optionen: Write to File (-o), Write to std out (-d). 
• Input Files: FROM_FILE , TO_FILE 
• Status: Alpha 

diffx tool (Strukturbasierter Ansatz)

• Programmiersprache: C++ 
• Status: under construction (vorübergehend stillgelegt) 

Test Tool

• Programmiersprache: C++ 
• Verfahren: 

1. Vergleich der Anzahl aller "DELETE", "ADD", "MOVED" und "SEQUENCE" Tags. 
2. Wenn obige Bedingung erfüllt: Vergleich der ID# in der "CHANGING" section. 
3. –> ID Vergleich der "Targets" und "Pres" 
4. "Semantischer" Vergleich 

Aufgabe 4: Three-Way Merge

Test Tool

Beschreibung:

Aufgabe 4.1: 3way mergex tool

• Programmiersprache: C++ 
• Optionen: Write to File (-cw, –cwrite), Write to std out (-c, –complete). 
• Input Files: PROCESS_FILE_1 *.prcx, PROCESS_FILE_2 *.prcx, PROCESS_FILE_ANCESTOR *.prcx  
• Status: pre-alpha  
• Known Issues: 

1. Programm Abstürze nicht ausgeschlossen 
2. Fehler in der richtigen Verknüpfung bei komplexeren Prozessen möglich 
3. Einige Routinen sind noch nicht vollständig implementiert und werden nachgereicht 
4. User Dialog nicht vollständig umgesetzt 

Beschreibung:

1. Einlesen der Prozess files: A.prcx, B.prcx, X.prcx 
2. Erstellen der diffx files: X_A.diffx und X_B.diffx 
3. Erneutes einlesen der *.diffx files  
4. Anwenden der Changes 
5. Erkennen und Aufteilen der Änderungen in (dieser ersten Phase des Algorithmus) "konfliktfreihe" und "konfliktbehaftete" Elemente 
6. Im nächsten Schritt (reduce() Methode) wird entschieden welche Änderungen aus welchem *.diffx File aufgenommen werden können (Abgleich mit gelöschten Vorgängern/Nachfolgern) 
7. Erkennen von Konflikten die sich aus den verschiedenen Verknüpfungen (pre/target) auf geänderte Elemente ergeben 
8. In manchen Fällen ist eine automatische Zuordnung möglich, etwa: Ein neuer Task und eine Condition werden an der selben Stelle eingeführt. Wer kommt zuerst? Antwort: der Task 
9. In einigen Fällen kann nicht automatisch zugeordnet werden. Der User wird mit Vorschägen zur Verknüpfung konfrontiert. 
10. Nach Abarbeitung der Fragen werden neue Change Anweisungen generiert die sich potenziell auf alle beteiligten Elemente eines Prozesses auswirken können (SCHWER!) 
11. Ausgabe eines *.diffx files auf std out oder in einem file 

Aufgabe 5: Metriken & Vergleichbarkeit herstellen

Aufgabe 5.1 Vergleichbarkeit herstellen

Abbildung 13: Umwandlung in Sumatra (Prozess X)

Abbildung 14: Umwandlung in Sumatra (Prozess A)

Abbildung 15: Umwandlung in Sumatra (Prozess B)

Speichern sie dann das Testset und schreiben Sie einen Uebersetzer der die XML Description (+

Endpunkte + Datenelemente) in ihr Format übersetzt:

Ausgehende XML Repräsentation von Prozess A

Übersetzter Prozess A in eigene XML Repräsentation:

Probleme

• Ancestor muss gespeichert werden um die Attribute 'pre' und 'target' referenzieren zu können  
  • Bei Verzweigungen besonders aufwendig: 'conditions'- und 'parallel'-  
• Ausgehende Datenstruktur unterstützt keine willkürliche Referenzierung auf andere tasks bei conditions 
  • Einschränkung der conditions führt zu einer semantischen Änderung unserer Prozesse 

Aufgabe 5.2 Prozess diff/merge Metriken

Beschreibung

1. (diffx) Einlesen des Ancestors 
2. (diffx) Einlesen eines Abgeleiteten Prozesses 
3. (diffx) diff berechnen und schreiben 
4. (diffx) Wiederholung der Schritte 1-4 für den zweiten abgeleiteten Prozess 
5. (mergex3) Einlesen des ancestors 
6. (mergex3) Einlesen des 1. diffs 
7. (mergex3) Einlesen des 2. diffs 
8. (mergex3) merge durchführen (ohne schreiben des fertigen Prozesses) 

Aufgabe 6.1 Vergleichen

Translator

Team 2

Zeichnung des merged Prozesses

Abbildung 16: Prozess A3_B3

Zeichnung des merged Prozesses

Team 3

diffx der beiden Prozesse zu ihrem Ancestor

3way merge der beiden diff files mit dem ancestor

Zeichnung des merged Prozesses

Abbildung 17: Prozess A3_B3

Ergebnis

Appendix

Abbildung 18: Prozess A_B (Ancestor=X)