cards+
Der Baustein Entity
Moti­vation

Unab­hängig vom Archi­tektur­stil ver­wendet jedes IT-System Infor­mations­objekte. Diese Objekte sind ganz all­gemein Daten (“etwas, das existiert”) oder repräsen­tieren einen Zustand im einem Daten­speicher. Ein Infor­mations­objekt hat häufig eine Identi­tät. Der Bau­stein Entity ist ein Arte­fakt der System­struk­tur, mit dem wir solche Ergeb­nisse der Soft­ware-Ent­wick­lung doku­mentieren. Dabei steht der fach­liche Nutzen des Dienstes im Vorder­grund. Der Titel des Bau­steins gibt einem wich­tigen Infor­mations­objekt einen ein­deutigen Namen.

Autoren wollen im Bau­stein Entity nur das doku­mentieren, was Ent­wick­ler nicht durch les­bare Teile vom Code oder code-nahe Arte­fakte bereits aus­reichend gut doku­mentiert haben. Mit einem Avro-Schema oder einem Json-Schema kann beispiels­weise ein auf JSON basierendes Infor­mations­objekt spezifi­ziert werden. Mit einem XML-Schema spezifi­zieren Ent­wick­ler ein auf XML basierendes Infor­mations­objekt. Autoren beschrei­ben im Wiki nur, was sich gar nicht oder sehr schwer aus dem Code heraus­lesen lässt. Sie erläutern Code ausschließlich dort, wo es notwendig ist.

Pro­jekt­manage­ment

Der Pro­dukt­­verant­wort­liche hat mit dem Bau­stein Entity die Mög­lich­keit, früh­zeitig ein wich­tiges Infor­mations­objekt als Ent­wurf zu erfassen, wenn es für das Ver­ständnis der Anwen­dungs­domäne hilf­reich ist. Er macht das in Abstim­mung mit dem Team.

Im Steck­brief des Bau­steins befindet sich eine Liste der geplan­ten Techno­logien für die Implemen­tierung des Infor­mations­objektes. Das ist eine sehr wert­volle Infor­mation für das Archi­tektur­manage­ment, um Themen wie Lizenz­kosten, tech­nische Unter­stützung vom Her­steller oder unter­nehmens­weite Vor­gaben recht­zeitig zu behan­deln.

Anfor­derungs­analyse

Der Pro­dukt­­verant­wort­liche hat mit dem Bau­stein Entity die Mög­lich­keit, alle Eigen­schaften eines Infor­mations­objektes zu beschrei­ben, die wich­tig für das Ver­ständnis der Fähig­keiten der Soft­ware sind. Er macht das in Abstim­mung mit dem Team.

Pro­dukt­entwick­lung

Der Bau­stein Entity ist für Leser (z.B. Ent­wick­ler oder Tester) der zen­trale Ein­stieg, um sich über die Bedeu­tung eines Infor­mations­objekt und seiner Eigen­schaf­ten zu infor­mieren. Der Über­blick im Bau­stein muss jeden Leser in die Lage ver­setzen, das Objekt fach­lich einzu­ordnen. Die Fest­legung der Identi­tät eines Infor­mations­objektes ist hilf­reich, um ein­deutige Schlüssel für Indi­zierung oder Partitio­nierung ablei­ten. In der im Bau­stein ver­öffent­lichten Spezifi­kation finden Leser alle Details zur Imple­mentierung des Infor­mations­objektes.

Gemäß Prinzip COD gilt der Titel des Bau­steins und die Namen der beschrie­benen Eigen­schaften als Vor­gabe für den Namen der Imple­mentierungs­klasse und die Bezeich­ner der Attri­bute eines Infor­mations­objektes. Mit dieser ein­­fach umzu­­setzen­den Regel muss kein Autor mehr eine spezi­elle Doku­­mentation im Wiki schrei­ben, um ein Infor­mations­objekt mit der tech­­nischen Lösung zu ver­­knüpfen. Der Titel des Bau­steins reicht als Ein­­stieg in die Imple­­mentierung.

Das Wiki.

Ein Erfolgsfaktor.

  1. Schnitt­stel­len­­beschrei­bung für Part­ner­­sys­teme

    Schnitt­stellen­beschrei­bungen sind alter­nativ­los in einer kom­plexen IT-System­land­schaft mit vielen unab­hängi­gen Par­tner­systemen aus ver­schiede­nen Organi­sationen eines Unter­nehmens. Ein Pro­dukt­verant­wort­licher darf sich trotz­dem die Frage stel­len, wie umfang­reich so ein Doku­ment sein muss. Mit cards+ kann er das Wiki zu seinem Vorteil nutzen.

    Jetzt lesen