> kann man in einem konreten _Klassen Diagramm_ ein _Package Diagramm_ verwenden, und _Klassen_ ohne weiteres in ein _Package Diagramm_-Element, _UML_ konventionsgemäß, hinein modellieren? UML ist nur ein Werkzeug, es dient dazu Software-Systeme zu visualisieren und schafft so eine Art Kommunikationsmedium für System-Designer*innen. Wenn du glaubst, dass ein ein bestimmtes Diagramm zum Verstädnis des Systems beitragen könnte, dann zeichne das Diagramm. Wenn es eine UML-konforme Lösung gibt, gut; wenn nicht, dann erfinde deine eigene Notation und schreib eine Erklärung in die Legende. Außerhalb der Schule wird niemand den Rotstift nur wegen der Form ansetzen, solange die Intention klar erkennbar ist. In sehr seltenen Fällen gibt es bürokratische Prozesse, die markelloses UML erfordern, aber selbst dann wird intern sehr viel mit formlosen Diagrammen gearbeitet. Das ist so ein bißchen vergleichbar mit einem Staatsbesuch: wenn der Flieger landet gibt es zunächst eine gehörige Zeremonie mit albernen militärischen Ehren und allem Pipapo. Später in den Arbeitstreffen gehts dann zur Tagesordnung über und dann diskutieren normale Menschen. Das Protokoll will es halt so.

> kann man in einem konreten _Klassen Diagramm_ ein _Package Diagramm_ verwenden, und _Klassen_ ohne weiteres in ein _Package Diagramm_-Element, _UML_ konventionsgemäß, hinein modellieren? UML ist nur ein Werkzeug, es dient dazu Software-Systeme zu visualisieren und schafft so eine Art Kommunikationsmedium für System-Designer*innen. Wenn du glaubst, dass ein ein bestimmtes Diagramm zum Verstädnis des Systems beitragen könnte, dann zeichne das Diagramm. Wenn es eine UML-konforme Lösung gibt, gut; wenn nicht, dann erfinde deine eigene Notation und schreib eine Erklärung in die Legende. Außerhalb der Schule wird niemand den Rotstift nur wegen der Form ansetzen, solange die Intention klar erkennbar ist. In sehr seltenen Fällen gibt es bürokratische Prozesse, die markelloses UML erfordern, aber selbst dann wird intern sehr viel mit formlosen Diagrammen gearbeitet. Das ist so ein bißchen vergleichbar mit einem Staatsbesuch: wenn der Flieger landet gibt es zunächst eine gehörige Zeromonie mit albernen militärischen Ehren und allem Pipapo. Später in den Arbeitstreffen gehts dann zur Tagesordnung über und dann diskutieren normale Menschen. Das Protokoll will es halt so.

> kann man in einem konreten _Klassen Diagramm_ ein _Package Diagramm_ verwenden, und _Klassen_ ohne weiteres in ein _Package Diagramm_-Element, _UML_ konventionsgemäß, hinein modellieren? UML ist nur ein Werkzeug, es dient dazu Software-Systeme zu visualisieren und schafft so eine Art Kommunikationsmedium für System-Designer*innen. Wenn du glaubst, dass ein ein bestimmtes Diagramm zum Verstädnis des Systems beitragen könnte, dann zeichne das Diagramm. Wenn es eine UML-konforme Lösung gibt, gut; wenn nicht, dann erfinde deine eigene Notation und schreib eine Erklärung in die Legende. Außerhalb der Schule wird niemand den Rotstift nur wegen der Form ansetzen, solange die Intention klar erkennbar ist. In sehr seltenen Fällen gibt es bürokratische Prozesse, die markelloses UML erfordern, aber selbst dann wird intern sehr viel mit formlosen Diagrammen gearbeitet. Das ist so ein bißchen vergleichbar mit einem Staatsbesuch, wenn der Flieger landet gibt es zunächst eine gehörige Zeromonie mit albernen militärischen Ehren und allem Pipapo. Später in den Arbeitstreffen gehts dann zur Tagesordnung über und dann diskutieren normale Menschen. Das Protokoll will es halt so.

> kann man in einem konreten _Klassen Diagramm_ ein _Package Diagramm_ verwenden, und _Klassen_ ohne weiteres in ein _Package Diagramm_-Element, _UML_ konventionsgemäß, hinein modellieren? UML ist nur ein Werkzeug, es dient dazu Software-Systeme zu visualisieren und schafft so eine Art Kommunikationsmedium für System-Designer*innen. Wenn du glaubst, dass ein ein bestimmtes Diagramm zum Verstädnis des Systems beitragen könnte, dann zeichne das Diagramm. Wenn es eine UML-konforme Lösung gibt, gut, wenn nicht, dann erfinde deine eigene Notation und schreib eine Erklärung in die Legende des Diagrams. Außerhalb der Schule wird niemand den Rotstift ansetzen, solange die Intention klar erkennbar ist. In sehr seltenen Fällen gibt es bürokratische Prozesse, die makelloses UML erfordern, aber selbst dann wird intern sehr viel mt formlosen Diagrammen gearbeitet. Das ist so ein bißchen vergleichbar mit einem Staatsbesuch, wenn der Flieger landet gibt es zunächst eine gehörige Zeromonie mit albernen militärischen Ehren und allem Pipapo. Später in den Arbeitstreffen gehts dann zur Tagesordnung über und dann diskutieren normale Menschen. Das Protokoll will es halt so.

> kann man in einem konreten _Klassen Diagramm_ ein _Package Diagramm_ verwenden, und _Klassen_ ohne weiteres in ein _Package Diagramm_-Element, _UML_ konventionsgemäß, hinein modellieren? UML ist nur ein Werkzeug, es dient dazu Software-Systeme zu visualisieren und schafft so eine Art Kommunikationsmedium für System-Designer*innen. Wenn du glaubst, dass ein ein bestimmtes Diagramm zum Verstädnis des Systems beitragen könnte, dann zeichne das Diagramm. Wenn es eine UML-konforme Lösung gibt, gut, wenn nicht, dann erfinde deine eigene Notation und schreib eine Erklärung in die Legende des Diagrams. Außerhalb der Schule wird niemand den Rotstift ansetzen, solange die Intention klar erkennbar ist. In sehr seltenen Fällen gibt es bürokratische Prozesse, die markelloses UML erfordern, aber selbst dann wird intern sehr viel mt formlosen Diagrammen gearbeitet. Das ist so ein bißchen vergleichbar mit einem Staatsbesuch, wenn der Flieger landet gibt es zunächst eine gehörige Zeromonie mit albernen militärischen Ehren und allem Pipapo. Später in den Arbeitstreffen gehts dann zur Tagesordnung über und dann diskutieren normale Menschen. Das Protokoll will es halt so.

> kann man in einem konreten _Klassen Diagramm_ ein _Package Diagramm_ verwenden, und _Klassen_ ohne weiteres in ein _Package Diagramm_-Element, _UML_ konventionsgemäß, hinein modellieren? UML ist nur ein Werkzeug, es dient dazu Software-Systeme zu visualisieren und schafft so eine Art Kommunikationsmedium für System-Designer*innen. Wenn du glaubst, dass ein ein bestimmtes Diagramm zum Verstädnis des Systems beitragen könnte, dann zeichne Diagramm. Wenn es eine UML-konforme Lösung gibt, gut, wenn nicht, dann erfinde deine eigene Notation und schreib eine Erklärung in die Legende des Diagrams. Außerhalb der Schule wird niemand den Rotstift ansetzen, solange die Intention klar erkennbar ist. In sehr seltenen Fällen gibt es bürokratische Prozesse, die markelloses UML erfordern, aber selbst dann wird intern sehr viel mt formlosen Diagrammen gearbeitet. Das ist so ein bißchen vergleichbar mit einem Staatsbesuch, wenn der Flieger landet gibt es zunächst eine gehörige Zeromonie mit albernen militärischen Ehren und allem Pipapo. Später in den Arbeitstreffen gehts dann zur Tagesordnung über und dann diskutieren normale Menschen. Das Protokoll will es halt so.