Software Engineering mit UML

Beim Training von Software-Engineering mit UML ergibt sich immer wieder das Problem, dass entweder die Unterlagen schlecht sind oder Beispiele nicht zum Teilnehmer passen. In Schulungen sind ca. 90% der Teilnehmer aus dem Banken-, Handel- und Versicherungsbereich. Da wären Bespiele aus der Technik, wie in Ampelsteuerung eher schlecht, da der Teilnehmer diese nicht für seine Arbeit adaptieren kann. Ein weiteres Problem ist, dass die UML eigentlich aus der objektorientierten Softwareentwicklung stammt. Die Objektorientierung nutzt ein anderes Paradigma. Passt man da nicht auf, wird aus einem Klassen-Diagramm schnell ein Datenmodell.  Ein weiteres Problem ist, dass gerne bei den Trainern und Beratern der goldene Hammer greift.

Eine Wunderwaffe (englisch Golden hammer) ist ein bevorzugter Lösungsweg, der als universell anwendbar angesehen wird.

“if all you have is a hammer, everything looks like a nail.”

„Wenn man nur einen Hammer hat, sieht alles wie ein Nagel aus.“

Viele Trainer und Trainings haben genau das Problem. Ich schule nur das, was wie ein Hammer aus sieht (den kenne ich ja) und ich nutze nur die Diagramme, die ich aus dem prozeduralen Umfeld zu kennen glaube. Tatsächlich besteht die UML nicht aus einem unzusammenhängenden Rudel von Diagrammen, sondern die Diagramme bauen durchaus aufeinander auf (siehe auch ). Schulungen in diesem Bereich (ohne Golden Hammer Sicht) sind meine Spezialität.

Welche Schulungen ich im Bereich Softwareengineering durchführe entnehmen Sie bitte der Liste aktueller Kurse.