<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="de">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Konsistenzprüfung von Architekturbeschreibungen mit Anforderungen mittels linguistischer Analyse</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Kai</forename><surname>Niklas</surname></persName>
							<email>kai.niklas@talanx.com</email>
							<affiliation key="aff0">
								<orgName type="institution">Talanx Systeme AG</orgName>
								<address>
									<settlement>Hannover</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
							<affiliation key="aff1">
								<orgName type="department">Software Engineering Group</orgName>
								<orgName type="institution">Leibniz Universität</orgName>
								<address>
									<settlement>Hannover</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Stefan</forename><surname>Gärtner</surname></persName>
							<email>stefan.gaertner@inf.uni-hannover.de</email>
							<affiliation key="aff1">
								<orgName type="department">Software Engineering Group</orgName>
								<orgName type="institution">Leibniz Universität</orgName>
								<address>
									<settlement>Hannover</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Kurt</forename><surname>Schneider</surname></persName>
							<email>kurt.schneider@inf.uni-hannover.de</email>
							<affiliation key="aff1">
								<orgName type="department">Software Engineering Group</orgName>
								<orgName type="institution">Leibniz Universität</orgName>
								<address>
									<settlement>Hannover</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Konsistenzprüfung von Architekturbeschreibungen mit Anforderungen mittels linguistischer Analyse</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">A73775870B481B8CD8BA1FFE78FBE39D</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T13:58+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><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></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="de">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Inkonsistenz zwischen Anforderungen und Architekturbeschreibungen durch Evolution</head><p>Die begriffliche Konsistenz zwischen Anforderungen und Architekturbeschreibungen hilft Entwicklern und Architekten komplexe Systeme besser zu verstehen. Der Grund ist die vereinfachte Zuordnung von Begriffen aus den Anforderungen zu den dazu passenden Ausschnitten der Architekturbeschreibung. Dadurch kann der Wartungsaufwand reduziert und die Produktivität gesteigert werden <ref type="bibr" target="#b8">[SZ01]</ref>. Inkonsistenzen können entstehen, wenn Anforderungen hinzugefügt oder geändert werden. Wird beispielsweise ein bestehender Begriff in den Anforderungen ersetzt, so muss die Architekturbeschreibung entsprechend angepasst werden. Andernfalls geht die meist implizite Zuordnung zu den Anforderungen verloren. Aus den gleichen Gründen kann es aber auch, durch Änderung der Architekturbeschreibung, zu Inkonsistenzen mit bestehenden Anforderungen kommen.  </p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head></head><label></label><figDesc>Copyright c by the paper's authors. Copying permitted for private and academic purposes.Mit Hilfe von linguistischenMethoden haben wir einen Ansatz zur automatischen Konsistenzprüfung zwischen natürlichsprachlichen Anforderungen und Architekturbeschreibungen entwickelt. Der Ansatz besteht im Wesentlichen aus zwei Schritten. 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. Domänenspezifische Begriffe, die untereinander in Beziehung stehen, bilden sogenannte Konzeptgraphen [Sow76]. Hierbei werden Begriffe als Knoten, und Beziehungen zwischen Begriffen als Kanten abgebildet. 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. 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. 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 Industrielles Fallbeispiel 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. In Abbildung 1 sind Ausschnitte der extrahierten Konzeptgraphen dargestellt: G a (Anforderungen) und G b (Schnittstellenbeschreibung). Zu erkennen ist die Übereinstimmung der markierten Knoten und Kanten in G a und G b . Der verwendete Begriff "Produktkategorie" aus G b ist jedoch nicht in G a vorhanden und wird somit auch nicht als Begriff in den Anforderungen verwendet. Dies stellt eine Inkonsistenz zu G a dar. In G a 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.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0"><head></head><label></label><figDesc></figDesc><graphic coords="3,64.80,54.07,486.01,302.80" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head></head><label></label><figDesc>Der Aufwand zur manuellen Prüfung von Konsistenz ist bei komplexen Softwaresystemen mit umfangreichen Anforderungen sehr hoch. Daher ist eine automatische Überprüfung und Korrekturunterstützung sinnvoll. Ein wesentliches Problem ist, dass Anforderungen in der Praxis überwiegend in natürlicher Sprache vorliegen und meist schwach strukturiert sind. Existierende Ansätze erfordern jedoch formale Notationen [CG01, Kim08] oder besondere Formen von Anforderungen, z.B. Szenarien [KZ02]. Eine Überführung von natürlichsprachlichen Anforderungen in formale Beschreibungen, durch die Entwickler, ist jedoch, gerade im Kontext von Evolution, zeitaufwändig und arbeitsintensiv. Das hat zur Folge, dass bestehende Ansätze zur Konsistenzprüfung nicht skalieren und für viele oder komplexe Artefakte ungeeignet sind [PSM + 09].</figDesc><table /></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<monogr>
		<title level="m">Ausschnitte aus Konzeptgraphen von Anforderungen und Schnittstellenbeschreibung Literatur</title>
				<imprint>
			<biblScope unit="volume">1</biblScope>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Graph Matching: Theoretical Foundations, Algorithms, and Applications</title>
		<author>
			<persName><forename type="first">Horst</forename><surname>Bunke</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">International Conference on Vision Interface</title>
				<imprint>
			<date type="published" when="2000-05">Mai 2000</date>
			<biblScope unit="page" from="82" to="84" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">Automatic analysis of consistency between requirements and designs</title>
		<author>
			<persName><forename type="first">Marsha</forename><surname>Chechik</surname></persName>
		</author>
		<author>
			<persName><forename type="first">John</forename><surname>Gannon</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">IEEE Transactions on Software Engineering</title>
		<imprint>
			<biblScope unit="volume">27</biblScope>
			<biblScope unit="issue">7</biblScope>
			<biblScope unit="page" from="651" to="672" />
			<date type="published" when="2001">2001</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">Method and Implementation for Consistency Verification of DEVS Model against User Requirement</title>
		<author>
			<persName><forename type="first">Do</forename><surname>Hyung</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Kim</forename></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the 10th International Conference on Advanced Communication Technology</title>
				<meeting>the 10th International Conference on Advanced Communication Technology</meeting>
		<imprint>
			<date type="published" when="2008">2008</date>
			<biblScope unit="page" from="400" to="404" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Are their design specifications consistent with our requirements</title>
		<author>
			<persName><forename type="first">A</forename><surname>Kozlenkov</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Zisman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the IEEE Joint International Conference on Requirements Engineering</title>
				<meeting>the IEEE Joint International Conference on Requirements Engineering</meeting>
		<imprint>
			<date type="published" when="2002">2002</date>
			<biblScope unit="page" from="145" to="154" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Linking Functional Requirements and Software Verification</title>
		<author>
			<persName><surname>Psm + ; Hendrik</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Carsten</forename><surname>Post</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Florian</forename><surname>Sinz</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Thomas</forename><surname>Merz</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Thomas</forename><surname>Gorges Und</surname></persName>
		</author>
		<author>
			<persName><surname>Kropf</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the 17th IEEE International Requirements Engineering Conference</title>
				<meeting>the 17th IEEE International Requirements Engineering Conference</meeting>
		<imprint>
			<date type="published" when="2009">2009</date>
			<biblScope unit="page" from="295" to="302" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">Probabilistic part-of-speech tagging using decision trees</title>
		<author>
			<persName><forename type="first">Helmut</forename><surname>Schmid</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the international conference on new methods in language processing</title>
				<meeting>the international conference on new methods in language processing<address><addrLine>Manchester, UK</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1994">1994</date>
			<biblScope unit="volume">12</biblScope>
			<biblScope unit="page" from="44" to="49" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Conceptual graphs for a data base interface</title>
		<author>
			<persName><forename type="first">John</forename><forename type="middle">F</forename><surname>Sowa</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">IBM Journal of Research and Development</title>
		<imprint>
			<biblScope unit="volume">20</biblScope>
			<biblScope unit="issue">4</biblScope>
			<biblScope unit="page" from="336" to="357" />
			<date type="published" when="1976">1976</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">Inconsistency management in software engineering: Survey and open research issues</title>
		<author>
			<persName><forename type="first">George</forename><surname>Spanoudakis</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Andrea</forename><surname>Zisman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Handbook of software engineering and knowledge engineering</title>
		<imprint>
			<biblScope unit="volume">1</biblScope>
			<biblScope unit="page" from="329" to="380" />
			<date type="published" when="2001">2001</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
