Geekly articles weekly

Programmierung ist die Materialisierung von Ideen.



Die Hauptthese dieses Artikels: Softwareentwicklung sollte als Materialisierung von Ideen durch die Umwandlung von mentalen Modellen in Programmcode gesehen werden.
Der Artikel beschreibt das Paradigma der Materialisierung von Ideen in der Softwareentwicklung (engl.: RPSE: Reification als Paradigma der Softwareentwicklung).

Englische Version des Artikels: RPSE : Reification als Paradigma des Software Engineering . Die Abkürzung RPSE wird später im Text verwendet, um das beschriebene Paradigma anzugeben.

Schlüsseldefinitionen


Bevor Sie mit der Erörterung der Hauptpunkte dieses Artikels fortfahren, müssen Sie sich auf die Bedeutung der darin verwendeten Grundbegriffe einigen.

Softwareentwicklung


Mit Software-Engineering ist die klassische Definition der Software-Engineering-Disziplin aus dem IEEE-Wörterbuch [1] gemeint: Software-Engineering ist „die Anwendung eines systematischen, disziplinierten, quantifizierbaren Ansatzes für die Entwicklung, den Betrieb und die Wartung von Software“.

Paradigma


Der in diesem Artikel verwendete Begriff Paradigma basiert auf der klassischen Definition des Thomas-Kuhn-Paradigmas [2]: Ein Paradigma ist ein Kreis von Problemen, eine Reihe von Konzepten, allgemein anerkannte Regeln und Gesetze, Methoden zur Lösung von Problemen in einem bestimmten Bereich der Wissenschaft.

Mehr zu Paradigmen
Um das unten verwendete Konzept des Paradigmas genauer zu bestimmen, ist es nützlich, zwei bekannte Zitate aus Kuhns Buch zu zitieren:
Mit Paradigmen meine ich anerkannte wissenschaftliche Errungenschaften, die der wissenschaftlichen Gemeinschaft seit einiger Zeit ein Modell für die Aufstellung von Problemen und deren Lösungen geben ...

Mit der Einführung dieses Begriffs meinte ich, dass einige allgemein anerkannte Beispiele für die tatsächliche Praxis der wissenschaftlichen Forschung - Beispiele wie Recht, Theorie, ihre praktische Anwendung und die notwendige Ausrüstung - uns alle Modelle geben, aus denen spezifische Traditionen der wissenschaftlichen Forschung hervorgehen.

Der Dualismus dieses Konzepts liegt in der Tatsache, dass das Paradigma einerseits durch eine Gemeinschaft von Spezialisten gekennzeichnet ist, die es erkennen. Es sind die Spezialisten eines bestimmten Bereichs, die seine Teile bestimmen, erstellen und entwickeln. Andererseits bedeutet das Erkennen eines bestimmten Paradigmas für einen Spezialisten, der sich einer solchen Gemeinschaft anschließt.

Thomas Kuhn hat in seinem Buch wissenschaftliche Paradigmen betrachtet. Sehr bald nach der Veröffentlichung der ersten Ausgabe des Buches wurde jedoch deutlich, wie nützlich es ist, dieses Konzept in der Technologie und in verschiedenen Bereichen des sozialen Lebens einzusetzen. In diesem Zusammenhang erschienen zahlreiche Veröffentlichungen zu Paradigmen und ihrem Wandel in der Automobilindustrie, zur Stadtplanung, zur Behandlung bestimmter Krankheiten usw. in der Fach- und Populärliteratur.

Software-Engineering und insbesondere seine wichtige Komponente - Programmierung - waren keine Ausnahme. Derzeit gibt es viele konkurrierende Programmierparadigmen. Ein separater Artikel auf Wikipedia [3] sowie interessante Rezensionen wie [4] widmen sich ihrer Aufzählung.

Über die Grenzen von Programmierparadigmen
Die Autoren der in [3] und [4] beschriebenen Paradigmen konzentrieren sich auf einen engen Teilbereich der Softwareentwicklung, nämlich das Schreiben von Programmen in einer bestimmten Programmiersprache. Ich denke, viele Fachleute sind sich einig, dass echte Softwareprojekte nicht nur im Rahmen eines dieser Paradigmen (z. B. funktionale Programmierung) abgeschlossen werden können.

Das in diesem Artikel beschriebene Paradigma ist dagegen auf eine Vielzahl von Themenbereichen und Phasen der Softwareentwicklung anwendbar.

Über die Grenzen von Software-Projektmanagement-Paradigmen
Einige Autoren nennen beispielsweise in der Übersicht [5] verschiedene Ansätze oder Modelle zur Organisation und Durchführung von Softwareprojekten als Paradigmen. Beispielsweise werden Wasserfallmodelle, V-Modelle oder agile Modelle verglichen. Es ist unwahrscheinlich, dass diese Ansätze im Gegensatz zu den oben erwähnten Programmierparadigmen aufgrund ihrer relativen theoretischen Einfachheit und des Fehlens einer breiten theoretischen Basis als Paradigmen im Sinne von Kuhns Definition bezeichnet werden können.

Das in diesem Artikel vorgeschlagene Paradigma hat ebenfalls noch keine eigene entwickelte theoretische Basis, aber seine Entwicklungspfade sind bereits heute sichtbar.

Materialisierung von Ideen


Der in diesem Artikel verwendete Begriff Materialisierung von Ideen (engl.: Reification ) ist eine Erweiterung der klassischen Definition von Reification in der Informatik: „Reification ist der Prozess, durch den eine abstrakte Idee eines Computerprogramms in ein explizites Datenmodell oder ein anderes in einer Programmiersprache erstelltes Objekt umgewandelt wird.“ [6].

Mehr über die Welt der Ideen, die Welt der Dinge und die Materialisierung
Das Wesentliche der Erweiterung der klassischen Definition des in diesem Artikel verwendeten Materialisierungskonzepts kann wie folgt definiert werden.

Bereits in den frühesten philosophischen Abschnitten, die uns überliefert sind, war es üblich, das Ideal (die Welt der Ideen) dem Material (der Welt der Dinge) gegenüberzustellen.

Wir können das Ideal bestenfalls fühlen (oder denken, dass wir es fühlen). Ein Indikator für ein solches Gefühl des Ideals kann eine Stimmungsänderung oder ein Gedankengang nach dem Hören eines Musikstücks, eines gelesenen Fragmentes eines Buches usw. sein. Natürlich meine ich die indirekte Wirkung, zum Beispiel der Musik, auf unser Bewusstsein und nicht die primitive physiologische Unterordnung des Körpers unter das Dröhnen eines Rockkonzerts oder den Rhythmus einer Disco.

Versuche, unseren Sinn für das Ideal in der Regel zu formulieren, führen nicht zum Erfolg.
Der große russische Dichter Fedor Ivanovich Tyutchev bemerkte dies bemerkenswert:
Wie drückt sich das Herz aus?
Wie kann man dich sonst verstehen?
Wird er verstehen, wie du lebst?
Der geäußerte Gedanke ist eine Lüge ... [7]
Selbst praktische Ideen wie kleinere Reparaturen rund ums Haus oder die Zubereitung einer neuen Variante eines bekannten Gerichts sind zunächst schwer zu formulieren. Und erst nach Überlegungen oder dem Versuch, es einem anderen zu erklären, nimmt die Idee immer klarere „Umrisse“ an.

Gehen wir nun von der Betrachtung des Idealbegriffs zur Betrachtung des Materials über. Wir können materielle Objekte um uns herum erfassen und registrieren, um ihre Eigenschaften qualitativ zu unterscheiden. Die Eigenschaften vieler Objekte können objektiv gemessen werden. Wir können auch Hierarchien und andere Strukturen materieller Objekte objektiv identifizieren.

Um zu bewerten oder zu messen (um quantitative Merkmale zu erhalten), ist es nicht erforderlich, einen Gegenstand zu haben. Es reicht aus, sein Modell zu haben. Darüber hinaus kann das Modell in vielen praktisch interessanten Situationen ohne Objekt verwendet werden. Modelle können mit anderen besprochen werden. Modelle können ausgehandelt werden. Modelle können standardisiert (formalisiert) werden.

In einigen Bereichen der menschlichen Tätigkeit ist die Standardisierung von Modellen so weit gegangen, dass Teile (z. B. Gewindebolzen), die auf der Grundlage eines standardisierten Modells (z. B. einer Zeichnung) von verschiedenen Personen oder Maschinengewehren hergestellt wurden, aus technologischer Sicht nicht zu unterscheiden sind.

Um die relative Ungenauigkeit der vorgeschlagenen Definition zu erkennen, werde ich später in diesem Artikel die Welt der Phänomene unserer inneren und äußeren Welt U in zwei Teile teilen:

U = M + I.

wo die Menge M aus ihren Phänomenen besteht, die objektiv registriert oder gemessen werden können (materielle Welt) und ich - alles andere.

Ob diese Formel auf absolut alle Phänomene der Welt um uns herum anwendbar ist, ist eine offene philosophische Frage. Später in diesem Artikel beschränken wir den Umfang dieser Formel auf die Welt der Phänomene aus der Welt der Softwareentwicklung.

Oder als These formuliert: Die gesamte Menge der Phänomene im Zusammenhang mit der Softwareentwicklung kann in eine Teilmenge des Ideals und eine Teilmenge des Materials unterteilt werden. Darüber hinaus werden Materialphänomene anhand ihrer Modelle aufgezeichnet oder gemessen.
Das Erstellen oder Ändern eines Softwaresystems endet in den meisten Fällen mit der Erstellung des einen oder anderen Codes, der mithilfe eines Computers in einem physischen Prozess angezeigt wird (ein reales Phänomen).

Dieser Prozess beginnt mit der Entstehung bestimmter Ideen über das zukünftige System in den Köpfen von Kunden oder Entwicklern. Wir werden diese Ideen und Ideen als mentales Modell bezeichnen .

Über Zwischenmodelle
In einfachen Systemen oder mit einfachen Ergänzungen / Änderungen an großen Systemen schreibt der Entwickler sofort Code oder konfiguriert das System basierend auf seinem mentalen Modell. In den meisten Fällen werden jedoch Zwischenmodelle mit unterschiedlicher Komplexität und unterschiedlichem Formalisierungsgrad erstellt - von einer einfachen Liste von Anforderungen bis hin zu umfangreichen formalen Modellen (z. B. UML- oder BPMN-Modelle).

Materialisierung von Ideen in Bereichen neben Software Engineering


Es ist klar, dass die obige Definition nicht radikal neu ist und in Bereichen der intellektuellen Arbeit neben der Programmierung (bewusst oder unbewusst) weit verbreitet ist. Betrachten Sie beispielsweise zwei solche Bereiche - Maschinenbau und Mathematik.

Diese beiden Bereiche nutzen die Materialisierung von Ideen seit langem und effektiv. Sie müssen diesbezüglich viel über das Programmieren lernen.

Im Maschinenbau sehen wir einen vollständigen Zyklus der Materialisierung von Ideen - von der Entstehung einer Idee im Kopf eines Designers über das Denken, Ausarbeiten, Abbilden in ein Modell bis hin zur Herstellung aus einem bestimmten Material.

In der Mathematik ist die Situation anders.

Zur Materialisierung von Ideen in der Mathematik
Interessante Fakten und Überlegungen zur Materialisierung von Ideen in der Mathematik finden sich in Abschnitt 7.3 des Buches [8].

Das „Endprodukt“ der Mathematik sind formale Modelle mit streng nachgewiesenen Eigenschaften.

Aus dieser Sicht liegt die Programmierung in der Mitte. Dies kann grafisch wie folgt dargestellt werden:



Daher verwendet die Mathematik eine größere Anzahl abstrakterer Modelle und gilt fast nicht für den Bereich extrem spezifischer Modelle wie Konstruktionszeichnungen.

Im Gegensatz dazu verwendet der Maschinenbau relativ wenige abstrakte Modelle, aber viele spezifische. Zum Beispiel solche, für die physische Objekte eindeutig hergestellt werden können.

Aus dieser Sicht liegt die Programmierung in der Mitte.

Warum ist die Programmierung in der Mitte?
Das endgültige Programmierprodukt ist Software-Code. Und obwohl es, wenn es auf Hardware ausgeführt wird, auf bestimmte physikalische Objekte (elektrische Signale und Felder verschiedener physikalischer Natur) abgebildet wird, sind diese Objekte schwer mit Muttern, Zahnrädern und Karosserien zu vergleichen. Andererseits kommt der Programmcode mathematischen Formeln nahe, und manchmal ist es ihre direkte Reflexion. In jedem realen Softwaresystem müssen Sie jedoch viele spezifische Aspekte der Umgebung und der Interaktion mit Benutzern oder anderen Systemen berücksichtigen. Dies macht den Programmcode spezifischer als mathematische Formeln.

Was Software Engineering von benachbarten Gebieten in Bezug auf die Modellnutzung lernen kann
Betrachten Sie zuerst die Mathematik.

Multimodell der Welt


Seit mehreren tausend Jahren ihrer Entwicklung hat die Mathematik gelernt, dieselben Phänomene der realen oder imaginären Welt in sehr unterschiedlichen Begriffen zu beschreiben. Die alten Griechen lernten, rein verbale Aufgabenbeschreibungen durch geometrische Figuren zu ersetzen und mit ihrer Hilfe praktisch wichtige Probleme zu lösen. Später zeigte sich ein Verständnis für die Austauschbarkeit von Segmenten in der Ebene und Zahlen. Dann kristallisierte sich das Konzept einer algebraischen Variablen und die Reduktion geometrischer Probleme auf algebraische Gleichungssysteme heraus.

Schüler wissen bereits heute, dass dasselbe Problem auf unterschiedliche Weise gelöst werden kann (z. B. geometrisch oder algebraisch) und dass dasselbe mathematische Modell, z. B. eine algebraische Gleichung, viele verschiedene physikalische, chemische usw. beschreibt. Phänomene.

Morphismus von Modellen und Konsistenz von Konzepten und Notationen


Die Mathematik hat gut gelernt, nicht nur dieselben realen oder imaginären Objekte und Prozesse mit Modellen sehr unterschiedlicher mathematischer Natur zu beschreiben. Eine wichtige Errungenschaft der Mathematik ist die Fähigkeit, den Ähnlichkeitsgrad von Modellen aus verschiedenen Bereichen der Mathematik zu bestimmen sowie sie ineinander umzuwandeln. Viele bahnbrechende Lösungen für die wichtigsten mathematischen Probleme der letzten Jahre sind im Wesentlichen Ketten getrennter Beweise, von denen jede einen speziellen Apparat aus einem speziellen Bereich der Mathematik verwendet. An den Knotenpunkten dieser hochspezialisierten Evidenz wandelt die Mathematik Modelle eines Abschnitts der Mathematik gekonnt in Modelle eines anderen Abschnitts um. Bei der Programmierung geschieht jetzt etwas Ähnliches, wenn der Quellcode eines Programms kompiliert und Code aus DSL (Domain Specific Language) oder Metadaten generiert wird. Die Kultur der Arbeit mit Modellen im Bereich der Softwareentwicklung liegt jedoch weit hinter der mathematischen zurück.

Modelle im Maschinenbau


Und was kann Software Engineering aus der Materialisierung im Engineering lernen?
In vielen Branchen und sogar in großen Unternehmen gibt es Ketten koordinierter formaler und semi-formaler Modelle. Diese Ketten enden mit Modellen, auf deren Grundlage physische Objekte hergestellt und montiert werden - Geräte und Maschinen. In der Regel gibt es für die meisten Arten von Zwischenmodellen formale Methoden zur Überprüfung ihrer Richtigkeit (technische Standards). Modelle sind die Hauptkommunikationssprache von Spezialisten mit unterschiedlichen Profilen bei der Entwicklung und Herstellung technischer Produkte.

Vor diesem Hintergrund sieht die Situation in der IT viel schlimmer aus. Nur innerhalb sehr großer IT-Belange wurden in den letzten Jahren Versuche unternommen, vergleichbare Modelle und Prozesse zu erstellen. Kleine Unternehmen und IT-Startups haben in der Regel nicht nur keine formalen Modelle und Prozesse entwickelt, sondern vermuten deren Existenz nicht einmal. Diese Situation wird derzeit von folgenden Faktoren bestimmt:

  • Die mangelnde Effizienz bestehender Modelle und Prozesse
  • Der Mangel an Ruhm dieser Modelle außerhalb großer Bedenken
  • Unzureichende Ausbildung für Entwickler und insbesondere Manager
  • Der Rückstand der Universitätsausbildung aus den tatsächlichen Bedürfnissen des Software-Engineerings.

Definition und Konturen des Paradigmas der Materialisierung von Ideen (RPSE)


Wir haben alle notwendigen Konzepte identifiziert, um eine grundlegende Definition des vorgeschlagenen Paradigmas zu geben. Hier ist es:
Softwareentwicklung ist die Materialisierung von Ideen durch die Umwandlung von mentalen Modellen in Code, der auf Computern ausgeführt wird.

Im Rahmen des vorgeschlagenen Paradigmas:

  1. Alle wichtigen Softwareentwicklungsprozesse sind spezifische Varianten (Implementierungen) des Prozesses zur Konstruktion von Ketten mentaler und materieller Modelle. Das letzte spezifischste Modell in dieser Kette ist in der Regel der Programmcode.
  2. Die Essenz der Softwareentwicklung besteht darin, solche Ketten zu erstellen.
  3. Alle Hauptprobleme der Entwicklungsoptimierung, der Kostensenkung und der Qualitätsverbesserung können auf die Optimierung der Konstruktion der entsprechenden Modellkette reduziert werden.

Warum Materialisierung und nicht Modellierung?
Es ist zu beachten, dass sich die Definition von RPSE zwar auf die Konstruktion von Modellketten bezieht, jedoch vorgeschlagen wird, die Paradigmenmaterialisierung eher als Modellierung zu bezeichnen. Daher wird versucht, die Besonderheit von Modellketten hervorzuheben, die immer weniger abstrakt / ideal und immer konkreter / materieller werden.

Die obige Definition hat ihre eigenen Eigenschaften und Variationen in verschiedenen Bereichen der Softwareentwicklung. Nur in sehr wenigen Fällen kommt es vor, dass im Kopf eines Programmierers eine klare Vorstellung davon, wie das Problem vor ihm gelöst werden kann, vollständig reift, die er dann in kurzer Zeit in einen Programmiersprachencode übersetzt. In den meisten realen Projekten besteht der Prozess der Lösungsfindung und deren Implementierung nebeneinander, entwickelt sich parallel und interagiert miteinander. Das heißt, Mentale Modelle, Code und häufig Zwischenmodelle (in Form eines Tests, Bilder, formale Modelle wie UML) wachsen und ändern sich parallel und beeinflussen sich gegenseitig.

Definitionsoptionen
Sehr oft arbeiten mehrere Personen gleichzeitig an einem Problem. Jeder von ihnen hat sein eigenes mentales Modell und möglicherweise seine Zwischenmodelle und Codefragmente.

Oft fehlt der Code in einer Programmiersprache praktisch, da bei der Erstellung einer neuen Lösung Masken von Konfiguratoren oder Generatoren verwaltet werden müssen, beispielsweise bei der Arbeit mit Entwicklungstools in Systemen wie SAP oder WebSphere.

Die Möglichkeiten, manuell geschriebenen oder automatisch generierten Code in ausführbaren Code umzuwandeln, sind heutzutage ebenfalls sehr vielfältig.

Und schließlich hat sich auch das Konzept des Prozessors, auf dem der Code ausgeführt wird, in den letzten Jahren erheblich erweitert. Waren früher Prozessoren auf den Brettern, die wiederum in die Schalen von Desktops, Laptops und Server-Racks eingesetzt wurden, wurde dieses Set jetzt um verschiedene Chips unterschiedlicher Größe erweitert, die in Mobiltelefone, Spielekonsolen und Überwachungskameras eingebaut sind. “ intelligente "Haushaltsgeräte usw. Ganz zu schweigen von Quantencomputern.

Trotzdem ist RPSE aufgrund seiner Allgemeinheit auf alle oben aufgeführten Bereiche anwendbar.

Was kann man heute noch über ein bestimmtes Paradigma sagen? Ist es möglich, seine Konturen irgendwie genauer zu skizzieren?

Der nächste Schritt zur Verfeinerung des Paradigmas nach dem Versuch, seine Hauptdefinition anzugeben, ist der Versuch, die Hauptkategorien von Phänomenen aufzulisten, die es betrifft. Unter Hinweis auf Kuhns Definition müssen wir versuchen, die Modelltypen aufzulisten, die RPSE einführt und verwendet.

RPSE-Modelle können in drei Hauptkategorien unterteilt werden:

  • Mentale Modelle
  • Code in Programmiersprachen oder seinen Entsprechungen als Modelle für ausführbaren Code.
  • Zwischenmodelle.

Die am wenigsten erforschten in dieser Triade sind mentale Modelle. Was genau ist mit ihnen gemeint?

Mentale Modelle sind ein Begriff für Ideen, die im Kopf von Kunden, Programmierern und anderen Teilnehmern des Prozesses existieren und auf deren Grundlage der ausführbare Code schließlich entsteht. Das Vorhandensein solcher Modelle ist unbestreitbar und kann auf mentaler Ebene beispielsweise vom Programmierer selbst registriert werden.Nach dem derzeitigen Stand der technologischen Entwicklung können diese Modelle nicht zuverlässig mit Instrumenten gemessen werden.

Eine der gut funktionierenden Möglichkeiten, solche Modelle zu fixieren und zu messen, besteht darin, das Medium der Idee zu verwenden. Offensichtlich wirken sich der Interviewprozess oder ähnliche dramatisch auf das mentale Modell selbst aus. Jeder von uns muss mehr als einmal eine Situation erlebt haben, in der der Versuch, ein Problem zu formulieren, um sich mit einem Kollegen zu beraten, zu einem „Einblick“ und häufig zu einer Lösung des Problems führte.

Interviews ermöglichen es, basierend auf korrekt formulierten Fragen relativ objektiv Modelle unterschiedlicher Komplexität zu erstellen. Die häufigsten sind:
Strukturmodelle:

  • Listen mit Binär-, Aufzählungs-, Zahlen-, Zeichenfolgen- und anderen Werten.
  • Grafik- und Netzwerkdatenstrukturen

Verhaltensbeschreibungsmodelle:

  • Sieben formale Modelle zur Bestimmung des Verhaltens
  • Formale Modelle zur Bestimmung des Verhaltens (z. B. Finite-State-Maschinen)

Zur Theorie der mentalen Modelle
Diese Muster spiegeln mentale Muster wider. Der Grad der Nähe von mentalen Modellen zu realen Modellen sollte durch Psychologie oder theoretische Pädagogik behandelt werden. Leider sind dem Autor keine ernsthaften Arbeiten in diesem Bereich bekannt. (Dies bedeutet nicht, dass solche Arbeiten nicht existieren).

Warum braucht Software Engineering ein End-to-End-Paradigma?


Das Vorhandensein eines „übergreifenden“ Paradigmas eröffnet den Teilnehmern die folgenden Möglichkeiten, das Paradigma des Prozesses der Erstellung, Änderung und Verwendung von Software zu nutzen:

  • Die Fähigkeit aller Teilnehmer am Prozess, dieselbe Terminologie zu verwenden.
  • Die Fähigkeit, einen End-to-End-Prozess zum Erstellen neuer Software zu erstellen.
  • Die Fähigkeit, seine Prozessparameter, seine Zwischenergebnisse zu bewerten und zu verwalten.
.

Die Hauptziele der Paradigmenentwicklung


Theoretische Probleme


Wie wiederholt festgestellt wurde, einschließlich im Buch Kuhn [2], sind Wissenschaftler in den meisten Fällen an der Lösung potenzieller Probleme beteiligt, die gelöst werden, und es ist weniger wahrscheinlich, dass sie sich mit solchen Problemen befassen, deren Vorgehensweise nicht sehr klar ist. Aber genau das sind unsere Aufgaben. Hier sind die wichtigsten:

  1. Konstruktive Definition des Konzepts des mentalen Modells.
  2. Suche nach konstruktiven Kriterien zur Beurteilung des Grads der Abstraktheit / Idealität vs. Spezifität / Materialität von Modellen.
  3. Suche nach Kriterien für die Auswahl von Kandidaten für die Rolle von Zwischen- und Zusatzmodellen.
  4. Auswahl und Entwicklung von Kriterien und Methoden zum Vergleich von Modellen verschiedener Typen, einschließlich ihrer direkten und umgekehrten Verfolgung.
  5. Entwicklung von Methoden zur automatisierten und automatischen Transformation von Modellen.

Praktische Aufgaben


Neben theoretischen Aufgaben zur Entwicklung und Implementierung des beschriebenen Paradigmas in der Praxis des Software Engineerings müssen mindestens folgende praktische Probleme gelöst werden:

  1. Erstellung von Werkzeugen für: a) Extraktion und Fixierung von mentalen Modellen. b) Automatisierte und automatische Umwandlung von mentalen Modellen in Zwischenmodelle. c) Spuren und Schätzungen von Änderungen im Inhalt transformierbarer Modelle
  2. Erstellung der notwendigen technischen und pädagogischen Literatur und anderen medialen Lehrmaterialien.
  3. Organisation von Foren und Konferenzen zu diesem Thema

Fazit


Dieser Artikel versucht, das Paradigma der Softwareentwicklung als Materialisierung von Ideen zu definieren. Das zu definierende (und nicht offene) Wort wird hier nicht zufällig verwendet. Tatsächlich beschäftigen sich Teilnehmer an IT-Projekten seit langem mit der Erstellung, Transformation und Verwendung von Modellen, möglicherweise ohne dies zu bemerken.

Im engeren Sinne von Kuhns Definition kann der beschriebene Ansatz noch nicht das Recht beanspruchen, als Paradigma bezeichnet zu werden, sondern nur als Kandidat für ein Paradigma, da es keine umfangreiche Gemeinschaft von Menschen gibt, die es unterstützen, und kein gut entwickeltes System miteinander verbundener Modelle. Ich möchte jedoch glauben, dass die Mängel bald behoben sein werden.

Dies ist der erste Artikel in einer geplanten Artikelserie. In den folgenden Artikeln werde ich über mentale und Zwischenmodelle sprechen.

Literatur


1. IEEE-Standardglossar der Software-Engineering-Terminologie, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. Die Struktur wissenschaftlicher Revolutionen. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3. Programmierparadigma: en.wikipedia.org/wiki/Programming_paradigm (Bundesland - 27.08.2008)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. September 2007). ISBN-13: 978-3446407442.
5. Paradigmen und Modelle der Softwareentwicklung Aufsatz
über Informationstechnologie www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (Stand - 28.08.2018 )
6. Reification (Informatik) en.wikipedia.org/wiki/Reification_ (computer_science) (Bundesstaat - 27.08.2008)
7. Fedor Ivanovich Tyutchev. Silentium! (Silence (lat.), 1829.
8. Borovik, Alexandre. Mathematik unter dem Mikroskop: Anmerkungen zu kognitiven Aspekten der mathematischen Praxis. American Mathematical Society. ISBN-13: 978-0821847619.

Illustration: geralt

Source: https://habr.com/ru/post/de425321/

More articles:


All Articles