This shows you the differences between two versions of the page.
applications:prom:workbreakdownstructure [2013/02/27 15:40] rtavassoli |
applications:prom:workbreakdownstructure [2013/02/27 17:04] (current) rtavassoli |
||
---|---|---|---|
Line 34: | Line 34: | ||
> Auch hier kann es passieren, dass das Löschen von dem Teilprojekt PSP als erstes beobachtet wird, und dass das gewandelte Teilprojekt somit vorübergehend aus dem Lesemodell verschwindet. | > Auch hier kann es passieren, dass das Löschen von dem Teilprojekt PSP als erstes beobachtet wird, und dass das gewandelte Teilprojekt somit vorübergehend aus dem Lesemodell verschwindet. | ||
===== Wandeln eines Teil-PSP in ein Haupt PSP ===== | ===== Wandeln eines Teil-PSP in ein Haupt PSP ===== | ||
- | Das funktioniert ganz ähnlich. Hierbei entsteht aber ein neues Aggregate, was bisher nicht der Fall war, es blieb alles noch Teil von PSP 1((Dafür wurden zwar neue Aggregates erzeugt, doch ohne Referenz auf sie waren sie nie Teil des Lesemodells)). Es muss also ein verteilter Prozess her, der am besten von einer Saga gesteuert wird. Wenn aus Projekt 1.1.1 ein Hauptprojekt werden soll, dann wird das Projekt und das Produkt aus PSP 1 gelöscht, und danach ein neuer PSP für das Projekt 1.1.1 angelegt((ein Haupt-PSP)): | + | Das funktioniert ganz ähnlich. Hierbei entsteht aber ein neues sichtbares Aggregate, was bisher nicht der Fall war, es blieb alles noch Teil von PSP 1((Dafür wurden zwar neue Aggregates erzeugt, doch ohne Referenz auf sie waren sie nie Teil des Lesemodells)). Es muss also ein verteilter Prozess her, der am besten von einer Saga gesteuert wird. Wenn aus Projekt 1.1.1 ein Hauptprojekt werden soll, dann wird ein neuer PSP für das Projekt 1.1.1 angelegt, und zugleich das Projekt und das Produkt aus PSP 1 gelöscht: |
{{ :applications:prom:converttomainprojectstructure.png?nolink |}} | {{ :applications:prom:converttomainprojectstructure.png?nolink |}} | ||
- | ===== Verschieben von Elementen eines Projektstrukturplans allgemein ===== | + | Am einfachsten ist der Prozess darüber zu steuern, dass der neue PSP 1.1.1 im Status //schwebend// angelegt wird, was eine Garantie dafür ist, dass er fest geschrieben werden kann und auch wieder gelöscht werden kann. Dann können das Projekt und das Produkt aus PSP 1 gelöscht werden, und der Status von PSP 1.1.1 auf //fest// gesetzt werden. |
- | Wenn mann analysiert, was in den letzten beiden Abschnitten beim Wandeln passiert ist, dann sieht mann, dass der Teil-PSP erzeugt und auch wieder gelöscht wird. Was ist denn beim Verschieben innerhalb einer rekursiven Struktur so gefährlich? Zirkelbezüge können enstehen, wenn sich zwei Elemente gegenseitig referenzieren, entweder direkt oder indirekt über mehrere Ebenen. | + | >Abhängig der Reihenfolge der Ereignisbehandlung kann es sein, dass Projekt 1.1.1 und Produkt 1.1.1.1 entweder vorübergehend verschwinden((Löschen aus PSP 1 wird zuerst behandelt)), oder dass sie zweimal erscheinen((Alle Ereignisse, inkl. dem Festsetzen von PSP 1.1.1 werden behandelt, bevor das Löschen aus PSP 1 behandelt wird)). Das sind aber beides nur vorübergehende Zustände, die i.d.R. gar nicht beobachtet werden, und wenn ja, ist das System ja schließlich konsistent. |
- | \\ \\ | + | ===== Wandeln eines Hauptprojektes in ein Teilprojekt ===== |
- | Was aber, wenn man beim Verschieben die Referenzen nicht einfach umbiegt, sondern die verschobene PSP komplett kopiert? Nun ja, in dem Fall können keine Zirkelbezüge entstehen | + | Das wird nicht erlaubt. Das ist genauso //gefährlich// wie das freie Umhängen in der Gesamten Projektstruktur, zwischen PSPs. Wenn ein Element des Hauptprojektes nämlich bereits ein Element aus der PSP referenziert, in die es gehängt werden soll, haben wir einen Zirkelbezug. Wandeln auf derselben Ebene ist erlaubt, Verschieben innerhalb einer PSP, oder Verschieben //nach oben//((Hauptprojekt aus Teilprojekt machen)). Verschieben auf eine Ebene unter der eigenen birgt die Gefahr der Erzeugung eines Zirkelbezugs. Eventuell kann man das noch unter gewissen Umständen einbauen, aber erst mal wird das nicht erlaubt. |
+ | ====== Aufbau des Lesemodells ====== | ||
+ | Das einfache Datenmodell((ohne ES)) sieht in etwa aus wie folgt: | ||
+ | {{ :applications:prom:projectstructuredatamodel.png?nolink |}} | ||
+ | Wenn man nur die Haupt Projektstrukturpläne anzeigt, und Teilpläne durch Anklicken im UI aufruft, haben wir in der PSP Element Tabelle samt Detailtabellen alles, was wir zur Anzeige brauchen. Eine Denormalisierung bis zum untersten Element wäre auch sinnvoll, das spare ich mir aber für später auf, denn PRO•M kennt keine Teil-Projektstrukturpläne, und daher brauche ich für die Anzeige und Datenhaltung dafür erst mal keine Gedanken machen. |