Trennung von Bedenken

Im Informatik, Trennung von Bedenken ist ein Designprinzip zur Trennung a Computer Programm in verschiedene Abschnitte. Jeder Abschnitt befasst sich mit einer separaten Anliegen, eine Reihe von Informationen, die den Code eines Computerprogramms beeinflussen. Ein Anliegen kann so allgemein sein wie "die Details der Hardware für eine Anwendung" oder so spezifisch wie "der Name, welcher Klasse zum Instanziieren". Ein Programm, das SOC gut verkörpert, heißt a modular[1] Programm. Modularität und damit die Trennung von Bedenken wird durch erreicht Einkapselung Informationen in einem Codeabschnitt mit einer genau definierten Schnittstelle. Einkapselung ist ein Mittel von Informationen verstecken sich.[2] Layered Designs in Informationssystemen sind eine weitere Verkörperung der Trennung von Bedenken (z. B. Präsentationsschicht, Geschäftslogikschicht, Datenzugriffsschicht, Persistenzschicht).[3]

Die Trennung von Bedenken führt zu mehr Freiheitsgraden für einen Aspekt des Designs, des Einsatzes oder der Verwendung des Programms. Unter diesen ist eine erhöhte Freiheit zur Vereinfachung und Aufrechterhaltung des Code. Wenn Bedenken gut getrennt sind, gibt es mehr Möglichkeiten für Modul-Upgrade, Wiederverwendung und unabhängige Entwicklung. Durch das Ausblenden der Implementierungsdetails von Modulen hinter einer Schnittstelle können Sie den Codeabschnitt eines einzelnen Bedenkens verbessern oder ändern, ohne die Details anderer Abschnitte zu wissen und entsprechende Änderungen an diesen anderen Abschnitten vorzunehmen. Module können auch verschiedene Versionen einer Schnittstelle freilegen, die die Freiheit erhöht, ein komplexes System ohne vorläufigen Funktionsverlust auf eine stückweise Weise zu verbessern.

Die Trennung von Bedenken ist eine Form von Abstraktion. Wie bei den meisten Abstraktionen bedeutet das Trennen von Bedenken zusätzliche Code -Schnittstellen und erstellt im Allgemeinen mehr Code, die ausgeführt werden sollen. Trotz der vielen Vorteile gut getrennter Bedenken gibt es oft eine damit verbundene Ausführungsstrafe.

Implementierung

Die Mechanismen für modulare oder objektorientierte Programmierung, die von a bereitgestellt werden Programmiersprache sind Mechanismen, die es Entwicklern ermöglichen, SOC bereitzustellen.[4] Zum Beispiel, Objekt orientierte Programmierung Sprachen wie C#, C ++, Delphi, und Java kann Bedenken trennen in Objekteund architektonisch Designmuster wie MVC oder MVP kann Separate Inhalte von der Präsentation und die Datenverarbeitung (Modell) aus dem Inhalt. Service-orientiertes Design kann Bedenken trennen in Dienstleistungen. Verfahrensprogrammierung Sprachen wie C und Pascal kann Bedenken trennen in Verfahren oder Funktionen. Aspekt-orientiertes Programmieren Sprachen können Bedenken in trennen Aspekte und Objekte.

Die Trennung von Bedenken ist auch in vielen anderen Bereichen ein wichtiges Designprinzip, wie z. Stadtplanung, die Architektur und Informationsdesign.[5] Ziel ist es, komplexe voneinander abhängige Systeme effektiver zu verstehen, zu entwerfen und zu verwalten, damit Funktionen wiederverwendet, unabhängig von anderen Funktionen optimiert und vom möglichen Versagen anderer Funktionen isoliert werden.

Zu den allgemeinen Beispielen gehören das Teilen eines Raums in Räume, so dass die Aktivität in einem Raum nicht Menschen in anderen Räumen betrifft und den Herd auf einer Schaltung und die Lichter auf einer anderen hält, so dass die Überlastung am Herd die Lichter nicht ausschaltet. Das Beispiel mit Räumen zeigt eine Kapselung, in der Informationen in einem Raum, z. B. wie chaotisch es ist, den anderen Räumen nur durch die Schnittstelle zur Tür zur Verfügung stehen. Das Beispiel mit Schaltungen zeigt, dass die Aktivität innerhalb eines Moduls, die eine Schaltung mit verbundenen Stromverbrauchern ist, die Aktivität in einem anderen Modul nicht beeinflusst, sodass jedes Modul nicht mit dem befasst ist, was in der anderen passiert.

Herkunft

Der Begriff Trennung von Bedenken wurde wahrscheinlich von geprägt von Edsger W. Dijkstra in seiner Arbeit von 1974 "über die Rolle des wissenschaftlichen Denkens".[6]

Lassen Sie mich versuchen, Ihnen zu erklären, was für meinen Geschmack für alle intelligenten Denkens charakteristisch ist. Es ist, dass man bereit ist, einen Aspekt des eigenen Themas isoliert zu studieren, um seine eigene Konsistenz zu willen, und wissend, dass man sich nur mit einem der Aspekte besetzt. Wir wissen, dass ein Programm korrekt sein muss und wir es nur aus diesem Standpunkt aus studieren können. Wir wissen auch, dass es effizient sein sollte und wir können sozusagen seine Effizienz an einem anderen Tag untersuchen. In einer anderen Stimmung können wir uns fragen, ob und wenn ja: Warum ist das Programm wünschenswert. Aber nichts wird - im Gegenteil! - gewonnen, indem diese verschiedenen Aspekte gleichzeitig angegangen werden. Es ist das, was ich manchmal als "Trennung von Bedenken" bezeichnet habe, die, auch wenn sie nicht perfekt möglich ist, die einzige verfügbare Technik für die effektive Ordnung der eigenen Gedanken ist, die ich kenne. Dies ist es, was ich mit "die Aufmerksamkeit auf einen Aspekt konzentrieren" meine: Es bedeutet nicht, die anderen Aspekte zu ignorieren, sondern nur der Tatsache, dass aus diesem Sicht dieses Aspekts der andere irrelevant ist. Es ist gleichzeitig ein und mehrfach und multiple Track.

Fünfzehn Jahre später war es offensichtlich der Begriff Trennung von Bedenken wurde eine akzeptierte Idee. 1989 schrieb Chris Reade ein Buch mit dem Titel " Elemente der funktionalen Programmierung[7] Das beschreibt die Trennung von Bedenken:

Der Programmierer muss mehrere Dinge gleichzeitig tun, nämlich, nämlich,

  1. beschreiben, was berechnet werden soll;
  2. Organisieren Sie die Berechnungssequenzierung in kleine Schritte;
  3. Organisieren Sie die Speicherverwaltung während der Berechnung.

Reade sagt weiterhin,

Im Idealfall sollte sich der Programmierer auf die erste der drei Aufgaben konzentrieren können (die beschreiben, was berechnet werden soll), ohne von den beiden anderen, administrativen Aufgaben abgelenkt zu werden. Es ist klar, dass die Verwaltung wichtig ist, aber indem wir sie von der Hauptaufgabe trennen, werden wir wahrscheinlich zuverlässigere Ergebnisse erzielen und das Programmierungsproblem lindern, indem wir einen Großteil der Verwaltung automatisieren.

Die Trennung von Bedenken hat auch andere Vorteile. Zum Beispiel wird das Programmprogramm, das nachweislich mehr realisierbar ist, wenn Details der Sequenzierung und Speicherverwaltung im Programm fehlen. Darüber hinaus sollten die Beschreibungen des Berechnens von solchen detaillierten schrittweisen Beschreibungen dessen, wie es geht, frei sein, wenn sie mit verschiedenen Maschinenarchitekturen bewertet werden sollen. Sequenzen kleiner Änderungen an einem Datenobjekt, das in einem Speicher gehalten wird, können eine unangemessene Beschreibung sein, wie man etwas berechnet, wenn eine hoch parallele Maschine mit Tausenden von Prozessoren verwendet wird, die auf dem Maschine verteilt sind, und nicht in lokalen und nicht globalen Speicheranlagen.

Die Automatisierung der administrativen Aspekte bedeutet, dass der Sprachimplementierer sich mit ihnen befassen muss, aber er/sie hat weitaus mehr Möglichkeiten, sehr unterschiedliche Berechnungsmechanismen mit unterschiedlichen Maschinenarchitekturen zu nutzen.

Beispiele

Internet -Protokollstapel

Die Trennung von Bedenken ist entscheidend für die Gestaltung des Internets. In dem Internet -ProtokollsuiteEs wurden große Anstrengungen unternommen, um Bedenken in gut definierte Bedenken zu trennen Schichten. Auf diese Weise können Protokolldesigner sich auf die Bedenken in einer Schicht konzentrieren und die anderen Schichten ignorieren. Das Anwendungsschichtprotokoll SMTP ist beispielsweise besorgt über alle Details zur Durchführung einer E -Mail -Sitzung über einen zuverlässigen Transportdienst (normalerweise TCP), aber nicht im wenigsten besorgt darüber, wie der Transportdienst diesen Service zuverlässig macht. In ähnlicher Weise ist TCP nicht besorgt über das Routing von Datenpaketen, die am behandelt werden Internetschicht.

HTML, CSS, JavaScript

Hypertext -Markup -Sprache (HTML), Cascading Style Sheets (CSS) und JavaScript (JS) sind komplementäre Sprachen, die bei der Entwicklung von Webseiten und Websites verwendet werden. HTML wird hauptsächlich für die Organisation von Webseiteninhalten verwendet. Historisch gesehen war dies nicht der Fall: Vor der Einführung von CSS erfüllte HTML beide Aufgaben zur Definition von Semantik und Stil.

Subjektorientierte Programmierung

Subjektorientierte Programmierung Ermöglicht, dass separate Bedenken als separate Softwarekonstrukte behandelt werden, die jeweils mit den anderen auf gleichen Standen geführt werden. Jedes Anliegen liefert eine eigene Klassenstruktur, in die die gemeinsamen Objekte organisiert sind, und leistet Zustand und Methoden zum zusammengesetzten Ergebnis, wo sie sich übereinander schneiden. Korrespondenzregeln beschreiben, wie die Klassen und Methoden in den verschiedenen Bedenken an den Punkten, an denen sie interagieren, miteinander zusammenhängen, und ermöglicht das zusammengesetzte Verhalten, damit eine Methode aus mehreren Bedenken abgeleitet werden kann. Mehrdimensionale Trennung von Bedenken Ermöglicht die Analyse und Zusammensetzung von Bedenken als mehrdimensionale "Matrix", in der jedes Problem eine Dimension liefert, in der verschiedene Punkte der Wahl aufgezählt werden, wobei die Zellen der Matrix von den entsprechenden Software-Artefakten besetzt sind.

Aspekt-orientiertes Programmieren

Aspekt-orientiertes Programmieren erlaubt Übergreifende Bedenken als Hauptanliegen behandelt werden. Zum Beispiel erfordern die meisten Programme irgendeine Form von Sicherheit und Protokollierung. Sicherheit und Protokollierung sind häufig sekundäre Bedenken, während das Hauptanliegen häufig darin besteht, Geschäftsziele zu erreichen. Bei der Gestaltung eines Programms muss seine Sicherheit jedoch von Anfang an in das Design eingebaut werden, anstatt als sekundäres Problem behandelt zu werden. Die Anwendung von Sicherheit führt häufig zu einem unzureichenden Sicherheitsmodell, das zu viele Lücken für zukünftige Angriffe hinterlässt. Dies kann mit aspektorientiertem Programmieren gelöst werden. Zum Beispiel kann ein Aspekt geschrieben werden, um durchzusetzen, dass Anrufe an eine bestimmte API immer protokolliert werden oder dass Fehler immer protokolliert werden, wenn eine Ausnahme ausgeliefert wird, unabhängig davon, ob der Verfahrenscode des Programms die Ausnahme behandelt oder sie verbreitet.[8]

Analyseebenen in der künstlichen Intelligenz

Im Kognitionswissenschaft und künstliche IntelligenzEs ist üblich, sich auf David Marrs zu beziehen Analyseebenen. Zu jedem Zeitpunkt kann sich ein Forscher auf (1) auf (1), was ein Aspekt der Intelligenz berechnen muss, (2) welchen Algorithmus er verwendet wird oder (3) wie dieser Algorithmus in Hardware implementiert wird, konzentriert. Diese Trennung von Bedenken ähnelt der Schnittstelle/Implementierung Unterscheidung in Software- und Hardware -Engineering.

Normalisierte Systeme

Bei normalisierten Systemen ist die Trennung von Bedenken eines der vier Leitprinzipien. Das Einhalten dieses Prinzips ist eines der Tools, mit dem die kombinatorischen Effekte reduziert werden, die im Laufe der Zeit in Software eingeführt werden, die aufrechterhalten wird. Bei normalisierten Systemen wird die Trennung von Bedenken aktiv durch die Tools unterstützt.

SOC über Teilklassen

Die Trennung von Bedenken kann durchgesetzt und durchgesetzt werden Teilklassen.[9]

SOC über Teilklassen in Ruby

Bear_hunting.rb
Klasse Tragen  def Jagd  Wald.auswählen(&:Lebensmittel?)  Ende Ende
Bear_eating.rb
Klasse Tragen  def Essen(Lebensmittel)  heben "#{Lebensmittel} ist nicht essbar! " wenn nicht Lebensmittel.Antworten auf? : Nutrition_Value  Lebensmittel.Nutrition_Value  Ende Ende
Bear_hungger.rb
Klasse Tragen  Attr_Accessor :Hunger  def Monitor_hunger  wenn Hunger > 50  Lebensmittel = Jagd  Hunger -= Essen(Lebensmittel)  Ende  Ende Ende

Siehe auch

Verweise

  1. ^ Laplante, Phillip (2007). Was jeder Ingenieur über Software -Engineering wissen sollte. CRC Press. ISBN 978-0849372285.
  2. ^ Mitchell, Dr. R. J. (1990). Verwaltung der Komplexität im Software -Engineering. IEE. p. 5. ISBN 0863411711.
  3. ^ Microsoft Application Architecture Guide. Microsoft Press. 2009. ISBN 978-0-7356-2710-9.
  4. ^ Maler Robert Richard (2006)."Softwarepläne: Mehrdimensionale feinkörnige Trennung von Bedenken".Penn State. Citeseerx 10.1.1.110.9227. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  5. ^ Garofalo, Raffaele (2011). Erstellen von Unternehmensanwendungen mit der Windows -Präsentationsstiftung und dem Modell View ViewModel -Muster.Microsoft Press.p.18. ISBN 978-0735650923.
  6. ^ Dijkstra, Edsger W. (1982). "Über die Rolle des wissenschaftlichen Denkens". Ausgewählte Schriften zum Computer: Eine persönliche Perspektive.New York, NY, USA: Springer-Verlag.pp.60–66. ISBN 0-387-90652-5.
  7. ^ Reade, Chris (1989). Elemente der funktionalen Programmierung.Boston, MA, USA: Addison-Wesley Longman. ISBN 0-201-12915-9.
  8. ^ Jess Nielsen (Juni 2006). "Aufbau sicherer Anwendungen" (PDF). Abgerufen 2012-02-08.
  9. ^ Tiago Dias (Oktober 2006). "Hyper/NET: MDSOC -Unterstützung für .NET" (PDF). DSOA 2006. Abgerufen 2007-09-25.

Externe Links