Freitag, 31. Mai 2013

Das Abstraktionsprinzip

Name, Kurzform
Abstraktionsprinzip
Synonyme
Prinzip der Abstraktion
Beschreibung
Bilde Abstraktionen.
Erläuterung
Das Abstraktionsprinzip ist eines jener Prinzipien, die so grundlegend für die Software-Entwicklung sind, dass sie kaum mehr als Handlungsanweisung verstanden werden können. Die Entwicklung von Software ohne Bildung von Abstraktionen ist praktisch nicht vorstellbar. Als übergeordnetes Prinzip, auf dem zahlreiche andere Prinzipien basieren, ist es jedoch von großer Bedeutung.
Beispiel(e)
Das Abstraktionsprinzip ist grundlegend für zahlreiche Tätigkeiten der Software-Entwicklung:
  • Abstraktion ist ein Basismechanismus menschlicher Kognition, der u. a. zur Erreichung folgender Ziele eingesetzt wird (siehe [Balzert1998]):
    • Erkennen, Ordnen, Klassifizieren
    • Trennen des Wesentlichen vom Unwesentlichen.
  • Abstraktion und ihr Gegenstück Konkretisierung sind die Grundlage jeder schrittweisen Verfeinerung (Top-Down-Ansatz, Teile und herrsche) und damit auch ein wesentliches Zerlegungskriterium.
  • Jegliche Modellbildung kann als Abstraktion betrachtet werden.
  • Elementare Konzepte von Programmiersprachen basieren auf Abstraktion, darunter Funktionen (funktionale Abstraktion), Datentypen (Datenabstraktion) oder Klassen (beides).
Historie
[Wang2007] gibt an, dass bereits Tony Hoare Abstraktion zu den wesentlichen Prinzipien der Softwaretechnik zählte. Erste Konzepte hierzu führte er bereits Ende der 60er Jahre ein.
Auch [Wasserman1996] zählt Abstraktion zu den fundamentalen Prinzipien, welche die Softwaretechnik als Ingenieursdisziplin ausmachen sollen.
Im deutschen Sprachraum wurde die Formulierung des Abstraktionsprinzips insbesondere durch [Balzert1998] eingeführt.
Wang selbst (ebenfalls [Wang2007]) nimmt das Abstraktionsprinzip als erstes von insgesamt 31 Prinzipien in sein „Integrated Set of Software Engineering Principles“ auf.
Art des Prinzips
  • Grundlegende Einteilung: Produkt, Prozess.
  • Technologiebezug: Allgemeingültig.
  • Entwurfsgüte: Zerlegungskriterium, Strukturprinzip.
  • Handlungsbezug: Änderung, Wiederverwendung, Verstehen.
  • Kognitionsbezug: Abstraktion.
(Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation
Gering.
Vorteile
  • Allgemeine Anwendbarkeit.
  • Wichtige Grundlage für zahlreiche speziellere Prinzipien.
Nachteile
  • Die Bildung „richtiger“ Abstraktionen ist nicht trivial.
  • Abstraktion kann auch zur Erschwerung des Verstehens führen (siehe Nichttrivialität der Softwaretechnik).
  • Die Bildung von Abstraktionen kann erhöhten Umsetzungsaufwand verursachen.
Übergeordnete Prinzipien
-
Abgleitete Prinzipien
  • Geheimnisprinzip
Qualitätsmerkmale
(+) Änderbarkeit, (+) Verständlichkeit, (+) Wiederverwendbarkeit, (+) Komplexität

Quellen

[Balzert1998] - Lehrbuch der Software-Technik, Helmut Balzert, 1998
[Wang 2007] - Software Engineering Foundations - A Software Science Perspective, Wang, Yingxu (2007)
[Wasserman1996] - Toward a Discipline of Software Engineering, IEEE Software, Nov.,
pp.23-31., Wasserman, A. (1996)

Samstag, 25. Mai 2013

Zur Kategorisierung der Prinzipien

Bis heute hat sich kein einheitliches System zur Kategorisierung von Prinzipien der Softwaretechnik etabliert. In verschiedenen wissenschaftlichen Arbeiten werden unterschiedliche Ansätze präsentiert. Einige dieser Ansätze sollen im Folgenden kurz geschildert werden. Schließlich schlage ich eine differenziertere Einteilung für eine bestimmte Teilmenge der Prinzipien (nämlich produktbezogene) vor.

Einteilung nach Entwicklungsphase

[Davis1995] teilt seine Prinzipiendarstellung nach Entwicklungsphasen ein. Er unterscheidet die folgenden Kategorien:
Diese Einteilung basiert allerdings weniger auf den Eigenschaften der Prinzipien selbst, sondern ordnet die Prinzipien lediglich bestimmten Tätigkeitstypen zu. Um Ordnung in die Vielzahl der Prinzipien zu bringen, erscheint dies unzureichend.

Granularität

[Simon2006] klassifiziert Qualitätsindikatoren nach Granularität. Ließe sich diese Unterscheidung auf Prinzipien anwenden?
  • Code: Prinzipien, die sich auf Eigenschaften des Quellcodes beziehen.
  • Entwurf: Prinzipien, die sich auf nichtglobale Entwurfseigenschaften beziehen.
  • Architektur: Prinzipien, die sich auf globale Entwurfseigenschaften beziehen.
  • Technologie: Prinzipien, die für das System als Ganzes gelten.

Die Anwendung dieser Unterscheidung erscheint verlockend. Tatsächlich lassen sich zahlreiche Prinzipien im Bereich der Objektorientierung der Entwurfs-Ebene zuordnen. Andererseits existieren zahlreiche Prinzipien, die keiner der genannten Ebenen zuzuordnen sind - sie gelten entweder in allen Granularitäts-Ebenen oder eine Zuordnung zu einer dieser Ebenen ist nicht sinnvoll. Eine Einteilung der Prinzipien entlang der Granularität ist daher nicht zielführend.

Sinnvolle Grobeinteilung

In ihrer Untersuchung von insgesamt 313 unterschiedlichen Prinzipien gelangen [Séguin 2010] zu einer groben Einteilung in drei Kategorien:
Diese grobe Einteilung basiert auf einer breiten empirischen Basis und erscheint insgesamt sinnvoll. Insbesondere die Unterscheidung zwischen produktverbessernden und prozessverbessernden Maßnahmen wird im Kontext des Qualitätsmanagements häufig getroffen. [Simon2006] unterscheidet beispielsweise Prozess-, Produkt- und Ressourcenmetriken.

Bei den bisher von mir ausgewählten Prinzipien handelt es sich durchweg um produktbezogene Prinzipien. Für diese möchte ich eine differenziertere Einteilung vorschlagen.

Differenzierung der produktbezogenen Prinzipien

Technologiebezug

Prinzipien lassen sich grob in technologiespezifische, technologieübergreifende und allgemeingültige Prinzipien einteilen. Als technologiespezifisch sind dabei alle Prinzipien zu verstehen, die ausschließlich innerhalb der engen Rahmenbedingungen einer Technologie gelten. Als technologieübergreifend sollen hingegen solche Prinzipien eingestuft werden, die über eine einzelne Technologie hinaus angewandt werden können. Allgemeingültige Prinzipien haben für alle relevanten Technologien Gültigkeit. Unter einer Technologie ist dabei ein Entwicklungs- oder Entwurfs-Paradigma im weitesten Sinne zu verstehen.

So ist beispielsweise das Liskovsche Substitutionsprinzip ein technologiespezifisches Prinzip, das nur im Bereich der Objektorientierung angewendet werden kann. Das [Prinzip der losen Kopplung] ist ein technologieübergreifendes Prinzip, da es für zahlreiche (wenn auch nicht alle) Technologien gilt. Das Lokalitätsprinzip kann für alle Technologien Gültigkeit beanspruchen. Die folgende Abbildung veranschaulicht die Unterscheidung:

Der Bezug zum Menschen: Mit Software umgehen und Software verstehen

Im meinem Post zur Nichttrivialität der Softwaretechnik habe ich die grundlegenden Schwierigkeiten bei der Software-Konstruktion beschrieben und als Motivation für das Aufstellen von Prinzipien herangezogen. Gäbe es bei der Software-Konstruktion keine Schwierigkeiten, so wäre auch die Formulierung von Prinzipien überflüssig.

Daraus ergibt sich, dass Prinzipien immer etwas damit zu tun haben, welchen Problemen wir im Umgang und beim Verständnis von Software begegnen. Prinzipien lassen sich demnach typischen Handlungen oder Tätigkeiten einerseits sowie kognitiven Mustern zuordnen. Die folgende Abbildung soll dies veranschaulichen.
Ich werde im Rahmen der Katalogeinträge jeweils den Handlungsbezug und den Kognitionsbezug angeben.

Entwurfsbezug

Zahlreiche Prinzipien dienen der Entwurfsgüte auf verschiedenen Granularitätsebenen - von der Code-Ebene bis hin zur Architektur. Eine grobe Unterteilung dieser Prinzipien könnte wie folgt aussehen:
  • Zerlegungskriterium: Wie soll modularisiert werden? Wann ist Zerlegung, wann Zusammenfassung zu einem Modul empfehlenswert?
  • Bausteinkriterium: Welche Eigenschaften sollte ein einzelnes Software-Element aufweisen? In einigen Fällen dienen solche Eigenschaften auch als Zerlegungskriterium.
  • Strukturprinzip: Welche Strukturen sollte man vermeiden? Welche sollten bevorzugt werden? Dabei geht es eher um grundsätzliche Struktureigenschaften als um konkrete Strukturen. Letzterer werden eher durch Patterns oder Antipatterns behandelt.

Übersicht

Zusammenfassend ergibt sich das folgende Kategorienschema, wobei eine Differenzierung der prozess- oder ressourcenbezogenen Prinzipien noch auszuarbeiten ist:

Quellen

[Davis1995] - 201 Principles of Software Development, Alan M. Davis, 1995

[Séguin 2010] - Software Engineering Principles - A Survey and an AnalysisNormand Séguin, Alain Abran, and Robert Dupuis. C3S2E, page 59-65. ACM, (2010)

[Simon2006] - Code-Quality-Management, S. 113, Frank Simon, Olaf Seng, Thomas Mohaupt, 2006

Donnerstag, 2. Mai 2013

Das Geheimnisprinzip

Das Geheimnisprinzip gilt heute als allgemein anerkannt, so dass es schwer vorstellbar ist, dass seine Einführung einmal auf Widerstände stieß. Es stellt ein wichtiges Partnerprinzip zur Modularisierung dar, die ohne Geheimnisprinzip zahlreiche Vorteile einbüßen würde.


Name, Kurzform Geheimnisprinzip
Synonyme Prinzip der Geheimhaltung, Information Hiding (-Prinzip), Prinzip der Kapselung (engl. encapsulation)
Beschreibung Außerhalb eines Software-Elements sollen die Interna dieses Elements nicht sichtbar sein.
Erläuterung
Die oben notierte Kurzversion des Geheimnisprinzips bedarf einiger Erläuterung:
  • Um welche Software-Elemente geht es?
  • Welche Eigenschaften sind als Interna aufzufassen?
Als Software-Element kommt jede syntaktische oder physikalische Einheit einer Software in Betracht, die Funktionen oder Daten oder beides beherbergt und die über eine öffentliche Zugriffsschnittstelle verfügt. Beispiele solcher Software-Elemente sind Module, Klassen, Komponenten, Bundles, Services, Anwendungen u.v.m.
Es sollen insbesondere folgende Eigenschaften solcher Software-Elemente verborgen werden:
  • Eigenschaften mit einer hohen Änderungswahrscheinlichkeit.
  • Eigenschaften, deren Sichtbarkeit nach außen nicht unbedingt erforderlich ist.
Das Geheimnisprinzip steht in enger Verwandtschaft mit einigen anderen sehr grundlegenden Prinzipien:
  • Es stellt eine Einschränkung des Prinzips der Modularisierung dar.
  • Durch das Verbergen von Details wird oftmals faktisch eine Abstraktion erreicht (Abstraktionsprinzip).
Beispiel(e)
Programmiersprachen:
  • Beschränkung des Zugriffs auf interne Attribute oder Methoden mittels sogenannter Access-Modifier (wie private, protected usw.).
Modularisierungs-Technologie:
  • Explizite Exports für OSGi-Bundles.
Entwurf:
  • Blackbox-Reuse mittels Komposition.
Gegenbeispiel:
  • Inheritance breaks encapsulation“
Historie
David Parnas hat zur „Entdeckung“ des Geheimnisprinzips in [Parnas2002] eine amüsante Geschichte erzählt, die zugleich verdeutlicht, dass dieses heute weithin anerkannte Prinzip zunächst durchaus auf den Widerstand von Fachkollegen stieß. Ein Artikel, den Parnas einer Fachzeitschrift zusandte, wurde vom Reviewer mit den Worten
Offensichtlich versteht Parnas nicht wovon er redet, denn niemand tut es auf diese Weise“
zunächst abgelehnt. Als erste Veröffentlichung gilt heute Parnas Artikel „On the Criteria To Be Used in Decomposing Systems into Modules“ [Parnas1972]. Parnas stellt in diesem Artikel zwei Möglichkeiten zur Zerlegung eines angenommenen Beispiel-Systems einander gegenüber:
  • Zerlegung auf der Grundlage eines Flussdiagramms: Die Module werden entsprechend einzelnen Verarbeitungsschritten gebildet.
  • Zerlegung auf der Grundlage von Design-Entscheidungen mit hoher Änderungswahrscheinlichkeit („design decisions which are likely to change“): Die Zerlegung erfolgt hier, um derartige Entscheidungen in den einzelnen Modulen zu verbergen.
Bis heute hat sich das Geheimnisprinzip, wie bereits die oben gewählten Beispiele zeigen, in zahlreichen Erscheinungsformen bis in die Syntax von Programmiersprachen und Modularisierungstechnologien verbreitet.
Art des Prinzips
  • Grundlegende Einteilung: Produktprinzip.
  • Technologiebezug: Allgemeingültig.
  • Entwurfsgüte: Zerlegungsprinzip.
  • Handlungsbezug: Erleichterung von Änderung, Wiederverwendung und Verstehen.
  • Kognitionsbezug: Komplexitätsreduktion, Abstraktion.
(Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation
Im Falle syntaktischer Unterstützung in folgender Hinsicht hoch:
  • Die verborgenen Systemteile können syntaktisch festgestellt werden.
  • Verstöße gegen das Geheimnisprinzip werden auf diese Weise bereits zur Kompilierzeit festgestellt.
Weniger gut formalisierbar sind folgende Aspekte:
  • Die Erkennung von System-Elementen, die unnötigerweise nicht verborgen wurden, ist schwierig.
  • Die Gruppierung von Elementen an Hand von Änderungserwartungen kann ebenfalls nicht formal überprüft werden.
Vorteile
  • Einfach verständlich.
  • Fördert zahlreiche Qualitätsmerkmale.
  • Macht Modularisierung erst wirkungsvoll.
Nachteile
  • Basiert auf Änderungserwartungen und ist in dieser Hinsicht von Annahmen über künftige Entwicklungen abhängig.
  • Erfordert Erfahrung und Weitsicht beim Schnittstellen-Entwurf.
Übergeordnete Prinzipien
  • Modularisierungsprinzip.
  • Abstraktionsprinzip
  • Prinzip der Änderungsnotwendigkeit
Abgleitete Prinzipien -
Qualitätsmerkmale
(+) Komplexität, (+) Änderbarkeit, (+) Testbarkeit,
(+) Wiederverwendbarkeit, (+) Verständlichkeit,
(+) Zuverlässigkeit

Quellen  

[Parnas1972] – On the Criteria To Be Used in Decomposing Systems into Modules, David L. Parnas, in: Communications of the ACM, 1972

[Parnas2002] – Software Pioneers, Hrsg. M. Broy und E. Denert, Kapitel The Secret History of Information Hiding (ab Seite 399), David L. Parnas, 2002