<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Konsistenzprüfung von Architekturbeschreibungen mit Anforderungen mittels linguistischer Analyse</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Kai Niklas</string-name>
          <email>kai.niklas@inf.uni-hannover.de</email>
          <email>kai.niklas@talanx.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Stefan Gärtner</string-name>
          <email>stefan.gaertner@inf.uni-hannover.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>und Kurt Schneider</string-name>
          <email>kurt.schneider@inf.uni-hannover.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Leibniz Universität, Software Engineering Group</institution>
          ,
          <addr-line>Hannover</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Talanx Systeme AG</institution>
          ,
          <addr-line>Hannover</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <fpage>109</fpage>
      <lpage>111</lpage>
      <abstract>
        <p>Zur Qualitätssicherung von Architekturbeschreibungen, z.B. Komponentenoder Schnittstellenbeschreibungen, ist eine Konsistenzprüfung gegen die gegebenen Anforderungen sinnvoll. Gerade wenn neue oder geänderte Anforderungen die Änderung bestehender Architekturbeschreibungen zur Folge haben, sollte die Konsistenz zu den Anforderungen bewahrt bleiben. Wir präsentieren eine Methode, basierend auf linguistischer Analyse, um eine solche Konsistenzprüfung zu unterstützen. Wir demonstrieren unsere Methode anhand eines industriellen Fallbeispiels.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Zusammenfassung</title>
      <p>Copyright c by the paper’s authors. Copying permitted for private and academic purposes.</p>
    </sec>
    <sec id="sec-2">
      <title>Automatische Konsistenzprüfung durch linguistische Analyse</title>
      <p>Schritt 1) Extraktion von Begriffen aus Anforderungen und Architekturbeschreibungen: Die wesentlichen Begriffe
werden aus den jeweiligen Artefakten mit Hilfe von linguistischen Methoden extrahiert. Hierzu werden NLP-Tools für
Partof-Speech Tagging und Lemmatisierung benutzt [Sch94]. Die extrahierten Begriffe stehen in einer Beziehung zueinander,
wenn sie innerhalb eines Artefakts gemeinsam genutzt werden. Bei natürlichsprachlichen Anforderungen wird hierzu die
lexikalische Struktur des Textes mit einbezogen. Zum Beispiel stehen zwei Begriffe in Beziehung zueinander, wenn sie
innerhalb einer Aufzählung gemeinsam verwendet werden. Bei Architekturbeschreibungen, z.B. in einem UML Diagramm,
entstehen Beziehungen durch Hierarchie- und Geschwisterbeziehungen der Klassen und Attribute.</p>
      <p>Domänenspezifische Begriffe, die untereinander in Beziehung stehen, bilden sogenannte Konzeptgraphen [Sow76].
Hierbei werden Begriffe als Knoten, und Beziehungen zwischen Begriffen als Kanten abgebildet.</p>
      <p>Schritt 2) Vergleich der extrahierten Begriffe: Im Rahmen unserer Arbeit sind zwei Artefakte zueinander konsistent,
wenn sie Begriffe in gleicher Art und Weise verwenden. Das bedeutet, dass verwendete Begriffe, und deren Beziehungen
zueinander, aus den Anforderungen mit den Begriffen, und deren Beziehungen zueinander, aus der
Architekturbeschreibung übereinstimmen müssen. Es wird nicht geprüft, ob alle Begriffe und Beziehungen aus den Anforderungen auch
tatsächlich verwendet werden. Zur Prüfung der Konsistenz werden hierzu die aus den Anforderungen und der
Architekturbeschreibung erstellten Konzeptgraphen automatisch miteinander verglichen [Bun00]. Passen die Begriffe in den Knoten,
unter Einbeziehung der Struktur des Graphen, semantisch nicht zueinander oder sind die Knoten unterschiedlich
miteinander verbunden, so liegt eine Inkonsistenz vor. Das heißt, dass die verwendeten Begriffswelten voneinander abweichen.
Aus dem Ergebnis des Vergleichs können somit Rückschlüsse auf die Konsistenz der jeweiligen Artefakte gezogen und
Empfehlungen zur Korrektur abgeleitet werden.</p>
      <p>Der Ansatz kann zur Entwicklungszeit zwischen der Anforderungs- und Entwurfsphase angewendet werden. Er eignet
sich insbesondere für die Wartung langlebiger Systeme, da geänderte Anforderungen kontinuierlich gegen die
Architekturbeschreibungen geprüft werden können.</p>
      <p>Durch die Verwendung linguistischer Methoden kann unserer Ansatz auf schwach strukturierte Anforderungen in
natürlicher Sprache, ohne manuelle Vorverarbeitung, automatisiert angewendet werden. Vorteile sind somit die Ausnutzung
bestehender Anforderungen im industriellen Umfeld und die Unterstützung verschiedener Projektgrößen. Die Methode
wird nur durch die Qualität der Artefakte und Leistungsfähigkeit verwendeter linguistischer Methoden beschränkt. Zum
Beispiel wird die sinnvolle Anwendung des Ansatzes erschwert, wenn innerhalb der Anforderungen Begriffe nicht
einheitlich verwendet werden.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Industrielles Fallbeispiel</title>
      <p>Das folgende Beispiel demonstriert den Einsatz der vorgeschlagenen Methode anhand eines industriellen Fallbeispiels. Im
Kontext einer serviceorientierten Architektur (SOA) soll die Konsistenz einer Service-Schnittstellenbeschreibung gegen
die zugrundeliegenden Anforderungen geprüft werden. Services werden zur Integration von Anwendungen und (Teil-)
Systemen genutzt. Sie werden mit Hilfe einer unternehmensinternen, domänenspezifischen Sprache beschrieben und sind
zentrale, langlebige Architekturbeschreibungen. Aus den formalen Beschreibungen werden später Code und
Dokumentation zur Umsetzung von Services generiert. Die natürlichsprachlichen Anforderungen liegen als schwach strukturiertes
Fachkonzept vor, welches zwischen Fachbereich und IT abgestimmt wurde. Es beinhaltet keine spezifische
Servicebeschreibung, sondern beschreibt nur Funktionalitäten aus fachlicher Sicht.</p>
      <p>In Abbildung 1 sind Ausschnitte der extrahierten Konzeptgraphen dargestellt: Ga (Anforderungen) und Gb
(Schnittstellenbeschreibung). Zu erkennen ist die Übereinstimmung der markierten Knoten und Kanten in Ga und Gb. Der verwendete
Begriff „Produktkategorie“ aus Gb ist jedoch nicht in Ga vorhanden und wird somit auch nicht als Begriff in den
Anforderungen verwendet. Dies stellt eine Inkonsistenz zu Ga dar. In Ga finden wir jedoch andere Begriffe an entsprechender
Stelle im Graphen, z.B. „Zuordnung“ oder „Spezifizierung“. Zur Herstellung der Konsistenz zwischen Anforderung und
Schnittstellenbeschreibung können dem Entwickler diese Alternativen vorgeschlagen werden. Dieser kann dann einen zum
Kontext passenden Begriff für die Schnittstellenbeschreibung auswählen.
[CG01]
[Kim08]</p>
    </sec>
    <sec id="sec-4">
      <title>Literatur</title>
      <p>Abbildung 1: Ausschnitte aus Konzeptgraphen von Anforderungen und Schnittstellenbeschreibung
Horst Bunke. Graph Matching: Theoretical Foundations, Algorithms, and Applications. In International Conference on
Vision Interface, Seiten 82–84, Mai 2000.</p>
      <p>Marsha Chechik und John Gannon. Automatic analysis of consistency between requirements and designs. IEEE
Transactions on Software Engineering, 27(7):651–672, 2001.</p>
      <p>Do Hyung Kim. Method and Implementation for Consistency Verification of DEVS Model against User Requirement.
Proceedings of the 10th International Conference on Advanced Communication Technology, Seiten 400–404, 2008.
A. Kozlenkov und A. Zisman. Are their design specifications consistent with our requirements? Proceedings of the IEEE
Joint International Conference on Requirements Engineering, Seiten 145–154, 2002.</p>
      <p>Helmut Schmid. Probabilistic part-of-speech tagging using decision trees. In Proceedings of the international conference
on new methods in language processing, Jgg. 12, Seiten 44–49. Manchester, UK, 1994.</p>
      <p>George Spanoudakis und Andrea Zisman. Inconsistency management in software engineering: Survey and open research
issues. Handbook of software engineering and knowledge engineering, 1:329–380, 2001.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [PSM+09]
          <string-name>
            <surname>Hendrik</surname>
            <given-names>Post</given-names>
          </string-name>
          , Carsten Sinz, Florian Merz, Thomas Gorges und Thomas Kropf.
          <source>Linking Functional Requirements and Software Verification. Proceedings of the 17th IEEE International Requirements Engineering Conference, Seiten 295-302</source>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>John F.</given-names>
            <surname>Sowa</surname>
          </string-name>
          .
          <article-title>Conceptual graphs for a data base interface</article-title>
          .
          <source>IBM Journal of Research and Development</source>
          ,
          <volume>20</volume>
          (
          <issue>4</issue>
          ):
          <fpage>336</fpage>
          -
          <lpage>357</lpage>
          ,
          <year>1976</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>