Programmierung ist die Materialisierung von Ideen.



    Die Hauptthese dieses Artikels: Softwareentwicklung sollte als Materialisierung von Ideen durch die Transformation von mentalen Modellen in Programmcode betrachtet werden.
    Der Artikel beschreibt das Paradigma der Materialisierung von Ideen in der Softwareentwicklung (engl .: RPSE: Reification as Paradigm of Software Engineering).

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

    Schlüsseldefinitionen


    Bevor Sie mit den Hauptpunkten dieses Artikels fortfahren, müssen Sie sich über die Bedeutung der darin verwendeten Grundbegriffe einig werden.

    Software-Engineering


    Unter Software-Engineering verstehen wir die klassische Definition der Software-Engineering-Disziplin aus dem IEEE-Wörterbuch [1]: Software-Engineering ist die Anwendung eines systematischen, disziplinierten und 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 anerkannten Regeln und Gesetzen sowie Methoden zur Lösung von Problemen in einem bestimmten Bereich der Wissenschaft.

    Mehr zu Paradigmen
    Чтобы точнее определить используемое далее понятие парадигмы, полезно привести две известных цитаты из книги Куна:
    Под парадигмами я подразумеваю признанные всеми научные достижения, которые в течение определенного времени дают научному сообществу модель постановки проблем и их решений…

    Вводя этот термин, я имел в виду, что некоторые общепринятые примеры фактической практики научных исследований — примеры, которые включают закон, теорию, их практическое применение и необходимое оборудование, — все в совокупности дают нам модели, из которых возникают конкретные традиции научного исследования.

    Der Dualismus dieses Konzepts besteht darin, dass das Paradigma einerseits durch eine Expertengemeinschaft gekennzeichnet ist, die es erkennt. Es sind die Spezialisten eines bestimmten Fachgebiets, die seine Teile bestimmen, erschaffen und weiterentwickeln. Andererseits bedeutet die Anerkennung 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 die Verwendung dieses Konzepts in der Technologie und in verschiedenen Bereichen des sozialen Lebens ist. In diesem Zusammenhang tauchten in der Fach- und Populärliteratur zahlreiche Veröffentlichungen zu Paradigmen und deren Wandel in der Automobilindustrie, Stadtplanung, Behandlung bestimmter Krankheiten usw. auf.

    Das Software-Engineering und insbesondere seine wichtige Komponente, die Programmierung, bildeten keine Ausnahme. Derzeit gibt es viele konkurrierende Programmierparadigmen. Ihre Aufzählung ist Gegenstand eines eigenen Wikipedia-Artikels [3] sowie interessanter Übersichten wie [4].

    Ü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 der einen oder anderen Programmiersprache. Ich denke, viele Fachleute sind sich einig, dass echte Softwareprojekte nicht nur im Rahmen eines dieser Paradigmen (zum Beispiel funktionale Programmierung) abgeschlossen werden können.

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

    Über die Grenzen der Paradigmen des Software-Projektmanagements
    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 genannten 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 auch noch keine eigene entwickelte theoretische Grundlage, aber heute sind seine Entwicklungspfade bereits 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 über ein Computerprogramm in ein explizites Datenmodell oder ein anderes in einer Programmiersprache erstelltes Objekt umgewandelt wird.“ [6]

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

    Schon im frühesten der uns zukommenden philosophischen Traktate wurde beschlossen, das Ideal (die Welt der Ideen) dem Material (der Welt der Dinge) gegenüberzustellen.

    Wir können das Ideal am besten fühlen (oder denken, dass wir es fühlen). Ein Indikator für ein solches Idealgefühl kann eine Stimmungsänderung oder ein Gedankengang nach dem Anhören eines Musikstücks, eines Lesefragments eines Buches usw. sein. Damit meine ich natürlich die indirekte Wirkung von 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 zu formulieren, führen in der Regel nicht zum Erfolg.
    Der große russische Dichter Fedor Iwanowitsch Tjutschew bemerkte dazu bemerkenswert:
    Wie drückt sich das Herz aus?
    Wie könnte man dich sonst verstehen?
    Wird er verstehen, wie du lebst?
    Der ausgesprochene Gedanke ist eine Lüge ... [7]
    Selbst praktische Ideen wie kleinere Reparaturen zu Hause oder die Zubereitung einer neuen Variante eines bekannten Gerichts sind zunächst schwer zu formulieren. Und erst nach Überlegungen oder Erklärungsversuchen bekommt die Idee immer klarere „Umrisse“.

    Wir wenden uns nun der Betrachtung des Idealbegriffs zu der Betrachtung des Materials zu. Wir können materielle Objekte um uns herum fühlen 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 von materiellen Objekten objektiv identifizieren.

    Für die Bewertung oder Messung (um quantitative Merkmale zu erhalten) ist kein Artikel erforderlich. Es reicht, 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 verhandelt werden. Modelle können standardisiert (formalisiert) werden.

    In einigen Bereichen der menschlichen Tätigkeit ist die Standardisierung von Modellen so weit fortgeschritten, 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.

    Im Bewusstsein der relativen Ungenauigkeit der vorgeschlagenen Definition werde ich später in diesem Artikel die Welt der Phänomene unserer inneren und äußeren Welt U teilenin zwei Teile:

    U = M + I,

    wobei die Menge M aus Phänomenen besteht, die objektiv aufgezeichnet oder gemessen werden können (materielle Welt), und I - alles andere.

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

    Oder als These formulieren: 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 erfasst oder gemessen.
    Der Prozess der Erstellung oder Änderung 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 ein mentales Modell nennen .

    Über Zwischenmodelle
    In einfachen Systemen oder mit einfachen Hinzufügungen / Ä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 Anforderungsliste bis zu umfangreichen formalen Modellen (z. B. UML- oder BPMN-Modelle).

    Materialisierung von Ideen in angrenzenden Bereichen des Software Engineerings


    Es ist klar, dass die obige Definition nicht radikal neu ist und (bewusst oder unbewusst) in Bereichen der intellektuellen Arbeit, die an die Programmierung angrenzen, 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 in dieser Hinsicht viel über die Programmierung lernen.

    Im Maschinenbau sehen wir einen vollständigen Zyklus der Materialisierung von Ideen - von der Entstehung einer Idee im Kopf des Designers über das Durchdenken, Detaillieren, 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 folgendermaßen grafisch dargestellt werden:



    Die Mathematik verwendet daher eine größere Anzahl abstrakterer Modelle und betrifft praktisch nicht den Bereich extrem konkreter Modelle, wie z. B. Konstruktionszeichnungen.

    Im Maschinenbau hingegen werden relativ wenige abstrakte, aber viele spezifische Modelle verwendet. Zum Beispiel solche, für die physikalische 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 ähnelt der Programmcode mathematischen Formeln, und manchmal ist es ihre direkte Reflektion. In jedem echten Softwaresystem müssen jedoch viele spezifische Aspekte der Umgebung und der Interaktion mit Benutzern oder anderen Systemen berücksichtigt werden. Dies macht den Programmcode spezifischer als mathematische Formeln.

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

    Multimodell der Welt


    In 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 erschien ein Verständnis über die Austauschbarkeit von Segmenten auf der Ebene und Zahlen. Dann kristallisierte sich das Konzept einer algebraischen Variablen und die Reduktion geometrischer Probleme auf algebraische Gleichungssysteme heraus.

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

    Morphismus von Modellen und Konsistenz von Begriffen und Notationen


    Die Mathematik hat gelernt, nicht nur die gleichen 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 Zweigen der Mathematik zu bestimmen und sie ineinander zu transformieren. Viele bahnbrechende Lösungen für die wichtigsten mathematischen Probleme der letzten Jahre sind im Wesentlichen getrennte Beweisketten, für die jeweils ein spezialisierter Apparat aus einem speziellen Bereich der Mathematik verwendet wird. An den Knotenpunkten dieses hochspezialisierten Beweises transformiert die Mathematik geschickt die Modelle einer mathematischen Sektion in die Modelle einer anderen Sektion. Beim Programmieren passiert etwas Ähnliches jetzt, wenn der Quellcode eines Programms kompiliert wird und wenn Code aus DSL (Domain Specific Language) oder Metadaten generiert wird.

    Modelle im Maschinenbau


    Und was kann Software Engineering in Bezug auf Materialisierung vom Maschinenbau lernen?
    In vielen Branchen und selbst in großen Unternehmen gibt es Ketten koordinierter formaler und semi-formaler Modelle. Diese Ketten enden mit Modellen, auf deren Basis physikalische 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 verschiedener Profile bei der Entwicklung und Herstellung technischer Produkte.

    Vor diesem Hintergrund sieht die Situation in der IT noch viel schlimmer aus. Nur innerhalb sehr großer IT-Unternehmen wurden in den letzten Jahren Versuche unternommen, vergleichbare Sätze von Modellen und Prozessen zu erstellen. Kleine Unternehmen und IT-Startups haben in der Regel nicht nur formale Modelle und Prozesse entwickelt, sondern ahnen auch nicht, dass sie existieren. Diese Situation wird derzeit durch die folgenden Faktoren bestimmt:

    • Die mangelnde Effizienz bestehender Modelle und Prozesse
    • Der mangelnde Bekanntheitsgrad dieser Modelle außerhalb großer Konzerne
    • Unzureichende Ausbildung für Entwickler und insbesondere Manager
    • Der Rückstand der Hochschulausbildung aus den realen Bedürfnissen des Software-Engineerings.

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


    Wir haben alle notwendigen Konzepte identifiziert, um das vorgeschlagene Paradigma grundlegend zu definieren. 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 wesentlichen Softwareentwicklungsprozesse sind spezifische Versionen (Implementierungen) des Prozesses der Konstruktion von Ketten mentaler und materieller Modelle. Das letzte spezifischste Modell in dieser Kette ist in der Regel Programmcode.
    2. Das Wesen der Softwareentwicklung besteht darin, solche Ketten zu erstellen.
    3. Alle Hauptaspekte der Entwicklungsoptimierung, Kostensenkung und Qualitätsverbesserung können auf die Optimierung des Aufbaus der entsprechenden Modellkette reduziert werden.

    Warum materialisieren und nicht modellieren?
    Es ist zu beachten, dass, obwohl sich die Definition von RPSE auf die Konstruktion von Modellketten bezieht, vorgeschlagen wird, das Paradigma als Materialisierung und nicht als Modellierung zu bezeichnen. Es wird versucht, die Besonderheit von Modellketten herauszustellen, 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 zu lösen ist, vollständig ausgereift ist, die er dann in kurzer Zeit in einen Programmiersprachencode übersetzt. In den meisten realen Projekten koexistieren der Lösungsfindungsprozess und seine Implementierung, entwickeln sich parallel und interagieren 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.

    Häufig fehlt der Code in einer Programmiersprache praktisch, da bei der Erstellung einer neuen Lösung nur die Masken von Konfiguratoren oder Generatoren verwaltet werden müssen, z. B. 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 das eigentliche Konzept des Prozessors, auf dem der Code ausgeführt wird, in den letzten Jahren erheblich erweitert. Waren es früher Prozessoren auf Platinen, die wiederum in 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, kann man seine Konturen irgendwie genauer umreißen?

    Der nächste Schritt zur Verfeinerung des Paradigmas nach dem Versuch, seine Hauptdefinition anzugeben, ist der Versuch, die Hauptkategorien der Phänomene aufzulisten, die davon betroffen sind. Unter Hinweis auf Kuhns Definition müssen wir versuchen, die von RPSE eingeführten und verwendeten Modelltypen aufzulisten.

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

    • Mentale Modelle
    • Code in Programmiersprachen oder seinen Äquivalenten als Modell für ausführbaren Code.
    • Fortgeschrittene Modelle.

    Die am wenigsten erforschten in dieser Triade sind mentale Modelle. Was genau ist damit 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 beispielsweise vom Programmierer selbst auf mentaler Ebene registriert werden. Nach dem derzeitigen Stand der Technik können diese Modelle mit Instrumenten nicht zuverlässig gemessen werden.

    Eine der gut funktionierenden Möglichkeiten, solche Modelle zu reparieren und zu messen, besteht darin, das Medium der Idee zu verwenden. Offensichtlich beeinflusst der Interviewprozess oder ähnliches das mentale Modell selbst dramatisch. Jeder von uns muss eine Situation mehr als einmal erlebt haben, als der Versuch, ein Problem zu formulieren, um sich mit einem Kollegen allein zu beraten, zu „Einsicht“ und oft zu einer Lösung des Problems führte.

    Die Befragung ermöglicht es, anhand korrekt formulierter Fragen relativ objektiv Modelle unterschiedlicher Komplexität zu erstellen. Die gebräuchlichsten sind:
    Strukturmodelle:

    • Listet Binär-, Aufzählungs-, Zahlen-, Zeichenketten- und andere Werte auf.
    • Graph- und Netzwerkdatenstrukturen

    Verhaltensmodelle:

    • Sieben formale Verhaltensmodelle
    • Formale Modelle zur Verhaltensbestimmung (zB Zustandsautomaten)

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

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


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

    • Die Möglichkeit für alle Teilnehmer des Prozesses, 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 auszuwerten und zu verwalten.
    .

    Die wichtigsten Herausforderungen für die Entwicklung des Paradigmas


    Theoretische Probleme


    Wie wiederholt festgestellt wurde, auch im Buch Kuhn [2], sind Wissenschaftler in den meisten Fällen an der Lösung potenzieller Probleme beteiligt, und es ist weniger wahrscheinlich, dass sie diejenigen aufgreifen, bei denen nicht klar ist, wie sie angegangen werden sollen. Das sind aber genau unsere Aufgaben. Hier sind die wichtigsten:

    1. Konstruktive Definition des Begriffs des mentalen Modells.
    2. Finden konstruktiver Kriterien zur Beurteilung des Grads an Abstraktheit / Idealität vs. Spezifität / Materialität von Modellen.
    3. Kriterien für die Auswahl von Kandidaten für die Rolle von Zwischen- und Zusatzmodellen finden.
    4. Auswahl und Entwicklung von Kriterien und Methoden zum Vergleich von Modellen verschiedener Typen, einschließlich deren direkter und umgekehrter Rückverfolgung.
    5. Entwicklung von Methoden zur automatisierten und automatischen Transformation von Modellen.

    Praktische Aufgaben


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

    1. Erstellung von Tools für: a) Extraktion und Fixierung von mentalen Modellen. b) Automatisierte und automatische Transformation von mentalen Modellen in intermediäre. c) Spuren und Schätzungen von Änderungen des Inhalts transformierbarer Modelle
    2. Erstellung der erforderlichen Fach- und Bildungsliteratur sowie sonstiger medialer Unterrichtsmaterialien.
    3. Organisation von Foren und Konferenzen zu diesem Thema

    Fazit


    Dieser Artikel versucht, das Paradigma des Software Engineerings als Materialisierung von Ideen zu definieren. Das Wort zu definieren (und nicht offen) wird hier nicht zufällig verwendet. In der Tat beschäftigen sich die Teilnehmer an IT-Projekten seit langem mit der Erstellung, Transformation und Verwendung von Modellen, ohne dass dies bemerkt wird.

    Im strengen 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 große Gemeinschaft von Menschen gibt, die es unterstützen, und ein 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 intermediäre Modelle sprechen.

    Literatur


    1. IEEE Standard Glossar 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 (Stand: 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.
    Software Engineering Paradigmen 5. Modelle und Informationen Teil Technologie Essay
    www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (Zustand - 2018.08.27)
    6. Reification (Computer Science) en.wikipedia.org/wiki/Reification_ (Computer_Science) (Stand - 27.08.2008)
    7. Fedor Ivanovich Tyutchev. Silentium! (Stille (lat.), 1829.
    8. Borovik, Alexandre. Mathematik unter dem Mikroskop: Hinweise zu kognitiven Aspekten der mathematischen Praxis. Amerikanische Mathematische Gesellschaft. ISBN-13: 978-0821847619.

    Illustration: geralt

    Jetzt auch beliebt: