Tipps für die Benennung von Komponenten 

Bei der Benennung von Komponenten sollten Sie folgende einfache Regeln beachten:

·        Die Namen von Softwarekomponenten (SC) und Komponenten (DCs) müssen global eindeutig und statisch sein. Der Name einer Komponente wird beim Anlegen dieser Komponente definiert und kann danach nicht mehr geändert werden. Weitere Informationen über Reservierung global eindeutiger Komponentennamen  finden Sie unter Namen von Komponenten.

·        Abhängigkeiten zwischen SCs werden nicht für konkrete Stände oder Versionen deklariert. Daher sollen Namen von Softwarekomponenten keine explizite Kennzeichnung der Version oder des Releases enthalten.

Vermeiden Sie Namen wie example.org/component_1.0 und example.org/technology_6.30.

Verwenden Sie stattdessen einfache Namen wie example.org/component und example.org/technology.

·        Die Zuordnung von DCs zu SCs ist nicht statisch und kann sich im Lauf der Zeit ändern. Daher soll der Name einer DC weder den Namen der SC enthalten, der er zugeordnet wird, noch deren Versions- oder Release-Bezeichnung.

Vermeiden Sie Namen wie example.org/sc/1.0/accounting. Verwenden Sie stattdessen einfach example.org/accounting. Lediglich zur Vermeidung von Mehrdeutigkeiten (etwa wenn in einer anderen SC eine Komponente des gleichen Namens existiert) kann es sinnvoll sein, den Namen der SC voranzustellen, etwa example.org/sc/accounting.

·        Abhängigkeiten zwischen DCs werden nicht für konkrete Stände oder Versionen deklariert. Daher sollen Namen von Komponenten keine explizite Kennzeichnung der Version oder des Releases enthalten

Vermeiden Sie Namen wie example.org/accounting/release_6.30. Verwenden Sie stattdessen einfach example.org/accounting.

·        Die Einschließungsbeziehung zwischen DCs ist nicht statisch und kann sich im Lauf der Zeit ändern. Der Name einer inneren DC kann die Einschließungsbeziehung widerspiegeln, dies wird aber nicht empfohlen, da dieser Name bei einer Änderung der Beziehung für Verwirrung sorgen könnte. Ist es wahrscheinlich oder absehbar, dass sich die Struktur einer Komponentenhierarchie ändern wird (z.B. eine innere Komponente aus einer umschließenden Komponente herausgezogen werden wird), sollte der Name keinen Bezug auf diese Beziehung nehmen.

Der Name example.org/customer_releations/accounting kann problematisch werden, wenn example.org/customer_releations/accounting eine innere Komponente der Komponente example.org/customer_relations ist, zu einem späteren Zeitpunkt aber der neuen Komponente example.org/financials zugeordnet werden soll.

·        Auf bestimmte Zustände einer DC kann gleichzeitig von unterschiedlichen Workspaces aus Bezug genommen werden (z.B. von DEV und CONS). Daher darf die Workspace-Bezeichnung nicht Teil des DC-Namens sein.

Vermeiden Sie Namen wie example.org/accounting/DEV und example.org/accounting/CONS.

·        Komponentennamen sollten keinerlei Versions- oder Zustandsinformationen enthalten. Dazu zählen auch z.B. “Specification“- und “Implementation“-Versionen für die J2EE-Plattform.

·        Komponentennamen müssen eine global eindeutige Herstellerkennzeichnung (Vendor Identifier) haben. Üblicherweise wird die Kennung aus einer Internet-Domäne abgeleitet, die dem Hersteller gehört (z.B. “sap.com“).

Wenn Ihnen eine Internet-Domäne mit der Bezeichnung example.org gehört, stellen sie diese Kennung ihren Komponentennamen voran, z.B. example.org/accounting. Dies macht Ihre Komponentennamen herstellerübergreifend eindeutig.

·        Komponentennamen sollten keine Kennungen von Entwicklern, Gruppen oder Abteilungen einer Firma enthalten. Die Zuständigkeiten können sich ändern, Komponentennamen aber nicht. Auch die Verwendung von Zeitstempeln, Datumsangaben, Servernamen usw. wird nicht empfohlen.

Vermeiden Sie Namen wie example.org/department4711/accounting, example.org/john.dow/accounting oder example.orgaccounting/09_11_2003_09.27pm.

·        Komponentennamen sollten nur den Zweck und die Funktionalität einer Komponente widerspiegeln.