Aufrufe
vor 3 Jahren

02 | 2015 public

  • Text
  • Verwaltung
  • Factory
  • Konsolidierung
  • Anforderungen
  • Einsatz
  • Frameworks
  • Anwendung
  • Systeme
  • Software
  • Unternehmen
Schwerpunkt: Konsolidierung der IT-DLZ

SINN UND UNSINN VON

SINN UND UNSINN VON FRAMEWORKS – TEIL II Frameworks unterstützen und vereinfachen den Softwareentwicklungsprozess, indem sie zusätzliche Abstraktionsschichten einziehen. Aber genau diese können sich im Entwicklungsprozess als Stolperstein entpuppen. | von JOHN LOUTZENHISER Dass der Einsatz von Frameworks im Softwareentwicklungsprozess grundsätzlich nützlich und hilfreich ist, haben wir im ersten Teil unserer Artikelserie dargestellt. 1 Dort haben wir beschrieben, wie sie zum einen die Wiederverwendung von Code sowie die flexible Kopplung zwischen Systemen erleichtern können und wie sie zum anderen geeignet sind, die akzidentielle und psychologische Komplexität, die oft mit Softwaresystemen verbunden ist, durch hilfreiche Abstraktionsschichten und die Verkapselung von systemnahen Implementierungsdetails zu minimieren. Dass der Einsatz von Frameworks durch Abstraktionen auch genau das Gegenteil bewirken und den Softwareentwicklungsprozess immer komplexer werden lassen kann, zeigen wir im zweiten Teil unserer Serie. Dieses Phänomen tritt insbesondere dann ein, wenn ein oder mehrere „Stolpersteine“ auf dem Weg liegen. STOLPERSTEIN ERHÖHTE KOMPLEXITÄT Die Gefahr einer erhöhten Komplexität durch ein Framework besteht in der Regel immer dann, wenn • eine Abstraktion, die bestimmte Komplexitäten zu verbergen oder verkapseln versucht, nicht korrekt implementiert wird. • eine Abstraktion zwar einen wertvollen Werkzeugsatz zur vereinfachten Lösung einer fachlichen oder softwaretechnischen Fragestellung bietet, dazu jedoch Programmierkonzepte (Idiome) und -paradigmen einführt, die hochspezialisiert, kompliziert zu lernen und schwer anzuwenden sind. • eine Abstraktion zwar für eine losere Kopplung zum Betriebssystem, zur Datenbank oder zum Browser sorgt, aber dafür eine Abhängigkeit zu der spezifischen Technologie oder dem Lieferanten des Frameworks herstellt. 1 .public 01-2015 42 | .public 02-15 | Informationstechnologie

„Die Softwaretechnik bietet reichlich Gelegenheit für „undichte“ und unbeabsichtigte (akzidentielle) Abstraktionen.“ Lev Gorodinski STOLPERSTEIN „UNDICHTE“ ABSTRAKTIONEN STOLPERSTEIN HOHE LERNKURVE Joel Spolsky hat das „Gesetz der undichten Abstraktionen“ formuliert, nach dem alle nicht-trivialen Abstraktionen gewissermaßen „undicht“ sind. Sogenannte „leaky abstractions“ liegen vor, wenn Frameworks ihre unterliegende Komplexität nur in den meisten Fällen verbergen, die Lösung bestimmter Probleme oder Anwendungsfälle aber erfordert, dass der Programmierer sich mit dieser Komplexität auseinandersetzt – das heißt, die Komplexität auf die Lösungsebene durchschlägt. Diese Undichtigkeit sorgt dafür, dass der Entwicklungsprozess durch Abstraktionen nicht in dem Ausmaß vereinfacht wird wie ursprünglich erhofft oder beabsichtigt. Die Einführung einer Abstraktionsschicht bedeutet in der Regel auch die Einführung neuer Konzepte, Denk- und Arbeitsweisen. Allerdings gibt es keine Garantie, dass diese auch einfacher zu lernen und zu verwenden sind als das, was durch sie abstrahiert werden soll. Die erwarteten Produktivitätsvorteile können durch die Einführung einer Abstraktionsschicht sogar zum Nachteil werden – und zwar dann, wenn ihre Beherrschung mit einer hohen Lernkurve verbunden ist. Und da die durch ein Framework mit hoher Lernkurve erworbenen Kenntnisse und Erfahrungen in der Regel hochspezialisiert und proprietär sind, lassen sie sich auch nur bedingt für andere Projekte nutzen. Für Unternehmen lohnen sich Investitionen in solche speziellen Framework-Kenntnisse daher oft nicht. Moderne Frameworks liefern eine Fülle von Beispielen für undichte Abstraktionen, die die psychologische oder auch die akzidentielle Komplexität erhöhen, besonders wenn sie • Kenntnisse ihres Abstraktionsmechanismus, • Kenntnisse der Details der zugrunde liegenden Fachlichkeit oder Systemdetails, die durch die Abstraktion verkapselt werden sollten, • Erfahrungen mit den Fällen, in denen die Abstraktion beziehungsweise Verkapselung nicht funktioniert, voraussetzen. Ohne die Abstraktion wäre nur die Kenntnis aus dem zweiten Punkt notwendig gewesen! Bei der Evaluierung eines Frameworks sind daher folgende Fragen wichtig: • Sind die Abstraktionen des Frameworks dicht? • Welche Kenntnisse der zugrunde liegenden (vermeintlich verkapselten) Details sind trotz der Verwendung des Frameworks notwendig? • Sind Fälle bekannt und dokumentiert, in denen die Abstraktion „undicht“ ist? Muss man damit rechnen, im Projekt mit solchen Fällen konfrontiert zu werden? Auch und vor allem proprietäre Frameworks können hochspezialisierte Fertigkeiten voraussetzen, wodurch die Wiederverwendbarkeit und Übertragbarkeit der Kenntnisse und Erfahrungen problematisch wird. Dagegen kann ein Framework, das allgemein bekannt ist und auf üblichen, allgemein bekannten Mustern und Konzepten basiert, sehr gut wiederverwendet und die damit gemachten Erfahrungen auf andere Projekte übertragen werden. So wie das Erlernen einer neuen Programmiersprache ein machbares und realistisches Unterfangen ist, wenn man bereits eine Programmiersprache beherrscht, kann man Design Patterns – das heißt (größtenteils) nichtproprietäre Abstraktionen von Lösungen für gewöhnliche softwaretechnische Probleme – auch leicht in einer anderen Sprache implementieren, wenn man die Konzepte hinter den Entwurfsmustern verstanden und sie bereits in einer bestimmten Programmiersprache implementiert hat. Bei der Evaluierung eines Frameworks muss daher hinterfragt werden: Informationstechnologie | .public 02-15 | 43

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum