Unterscheidung zwischen konkret und abstrakt in Software [geschlossen]

Willkommen zum Spaß des Software-Engineering-Jargons! Bei der Arbeit und Freizeit bin ich oft auf das Problem gemeinsamer Begriffe gestoßen, wenn es um das Entwerfen von Softwaresystemen geht. Entschuldigung, wenn ich Ihre Frage nicht richtig beantworte, da scheint viel drin zu sein und ich finde es ein bisschen nebulös. Die eigentlichen inhaltlichen Fragen beantworte ich mit: „Seien Sie vorsichtig und klären Sie ggf. Ihre Dokumentation oder Präsentationen gegenüber Teamkollegen und Anwendern“. Hier ist jedoch etwas Fachjargon, das Sie verwenden können:

"funktionale Anforderungen" - Was kommt rein und was soll raus?

"Architektur" - Wie wird gebaut? Welche Tools und Patterns gibt es?

"logical design" - Wie passt alles in der virtuellen Welt zusammen und behält seine Struktur? Was sind die Regeln des Systems? Das bezieht sich auf "Entitäten", diese Abstraktionen konkreter Dinge aus dem wirklichen Leben, von denen Sie sprachen. Regeln zu Datentabellen, Attributen etc. müssen in einem „Entity-Relationship-Diagram“ skizziert werden.

"Look-and-Feel" Gesamtstimmung - Farben, Klicks, Animationen, Grafikdesign

"Benutzererfahrung" - Auch ux genannt. Selbsterklärend.

"Schnittstelle" - Wie Komponenten oder Benutzer sich mit dem System verbinden.

"Physical Design" Dies sind die "physischen" Anforderungen für das/die Programm(e), welche Eingaben müssen gemacht werden? (einfaches Beispiel: ein Datumsfeld in einem Webformular soll nur ein Datum annehmen). Dies kann sich auch auf konkretere Elemente aus der realen Welt beziehen, wie z. B. die Art des Computers oder anderen Instruments, das hypothetisch mit dem Softwaresystem verwendet wird.

Außerdem möchte ich sagen, dass sich ein Programm nicht sehr darum kümmert, ob das aufgezeichnete Attribut "konkret" oder "abstrakt" ist. Wenn Sie die Anzahl der Passagiere in einem Flugzeug erfassen möchten, verwenden Sie ein Feld genauso, als ob Sie den Wartungsstatus des Flugzeugs erfassen möchten (gut, ausreichend, schlecht usw.).

Wenn Sie speziell die Bedeutung konkreter und abstrakter Klassen im Rahmen der objektorientierten Programmierung verstehen möchten, lassen Sie es mich wissen und ich werde auf dieses Thema näher eingehen. Soweit ich weiß, sind Sie jedoch ein Verbraucher und kein Entwickler von Softwareprodukten.

Wie Sie sehen können, gibt es allein in diesem Beitrag eine Menge gemeinsamer Terminologie und viele inhaltliche Überschneidungen, die diese Begriffe abdecken. Daher gilt meine erste Antwort, vorsichtig zu sein und zu klären, immer. Wenn Sie tiefer graben möchten oder weitere Fragen haben, bin ich gerne bereit, meine Antwort zu erweitern und vielleicht auch etwas zu recherchieren.

Es gibt eine Vielzahl von Möglichkeiten, verschiedene Arten und Ebenen der Abstraktion in der Programmierung zu beschreiben.

Einige in Programmen verwendete Konstruktionen sind abstrakter als andere. Beispielsweise könnten Sie eine Funktion f wie folgt auf die Zahlen 1 bis 5 anwenden: f(1),f(2),f(3),f(4),f(5), oder Sie könnten eine for-Schleife schreiben for(i=1..5,i++){f(i)}, oder Sie könnten eine Funktion höherer Ordnung wie map in a lisp verwenden: (map f (range 1 6)). Diese sind in der Reihenfolge der Abstraktion von der geringsten bis zur höchsten Abstraktion aufgelistet.

Es gibt verschiedene Programmierparadigmen, zB - objektorientierte Programmierung, aspektorientierte Programmierung und funktionale Programmierung. Sie legen Schwerpunkte auf verschiedene Arten von Abstraktionen.

Es gibt auch viel Material zu Typen in der Programmierung, das eine gewisse Verbindung zu abstraktem philosophischem und mathematischem Material wie der Typentheorie hat:

http://plato.stanford.edu/entries/type-theory/

Zu den Programmiersprachen, die Typen betonen, gehören Haskell und Idris.

Meine Vermutung zur Lösung Ihres Problems besteht darin, einen Programmierer zu bitten, es zu lösen. Oder Sie könnten ein bestimmtes Paradigma wie funktionale Programmierung nachschlagen und sehen, ob es zu Ihrer Denkweise über das Problem passt.

Ich werde nur Ihre Überschriftsfrage zur Unterscheidung zwischen abstrakt und konkret angehen.

Der Begriff, der hier behandelt werden muss, ist in der Informatik in der sogenannten Typentheorie; es ist jedoch nicht notwendig, ins Detail zu gehen; und es ist nützlich, hier eine Analogie zur Mengenlehre zu verfolgen.

Ein Typ benennt eine Menge; die Desiderata, die angibt, was dieser Typ beinhaltet, ist wie die definierenden Bedingungen der Menge; die eigentlichen Objekte , die diese Desiderate erfüllen, veranschaulichen den Typus, in der Mengenlehre sind dies die Elemente der Menge.

Zum Beispiel:

Ganzzahl ist ein Typ,

und die ganzen Zahlen 1,2,3,4,... sind Objekte, die diesen Typ veranschaulichen

wir können ganze Zahl schreiben = {x ist eine reelle Zahl: x - Boden x ist Null} = {1,2,3,...}

Typen sind abstrakt und Objekte sind konkret ; Eine Möglichkeit, darüber nachzudenken, ist, dass ein Typ von einer Menge von Objekten ihre gemeinsamen definierenden Eigenschaften abstrahiert .

Hier besteht eine Verbindung zu Aristoteles Vorstellung von Gattung , Art und Differentia ; ein Typ wäre eine Art, ein Supertyp wäre eine Gattung, und eine Differenzierung wäre die definierende Bedingung.

Im obigen Beispiel:

Spezies=Typ=Ganzzahl

Gattung=Supertyp=Real

differentia = Bedingungen definieren = 'x - Boden x ist Null'

Hoffe das hilft.

Von Dingen, die Sie sich fragen:

Gibt es eine Taxonomie oder Konvention zur Definition dieser verschiedenen Arten von Dingen?

und

Wie kann ich also Anforderungen nach der Art der Sache kategorisieren, auf die sich die Anforderung bezieht?

Ich denke, Sie fragen sich vielleicht, ob es einen richtigen Weg gibt, Anforderungen einem Sprachkonstrukt zuzuordnen (z. B. Klasse in objektorientierten Sprachen wie Java, C++). Ich denke, Sie werden es verstehen, nachdem Sie einige Demos oder Projekte in der Produktion abgeschlossen haben. Ich möchte nur einige Prozesse des von Ihnen erwähnten Abstraktionsprozesses erklären.

Nun, es ist offensichtlich, dass eine Software, die die Anforderung erfüllt, so funktionieren kann, wie wir es erwarten (zumindest im Moment), dies kann Folgendes beinhalten: Benutzeroberfläche ist in Ordnung, Anfrageverarbeitung ist in Ordnung usw.

Daher ist es üblich, dass es mehrere oder sogar unzählige mögliche Implementierungen gibt , um das obige Ergebnis zu erzielen, und jede der Implementierungen ist gültig .

Betrachten Sie beispielsweise für eine Website eines Online-Shops wie Amazon die folgenden zwei Modelle in unterschiedlicher Implementierung:

In Implementierung 1 modellieren wir das Produkt als Java-Klasse namens Productund die Kundenkommentare darunter als Java-Klasse namens Comment:

/* impl 1 */
public class Product{
}

public class Comment{
}

In Implementierung 2 modellieren wir Produkt mit Kommentaren als eine Java-Klasse namens Product, da wir Produkt und Kommentare als Ganzes betrachten, und comments, eine Liste von Zeichenfolgen, ist ein privates Attribut/Mitglied der Produktklasse:

/* impl 2 */
public class Product {
 private List<String> comments;
}

Beide Implementierungen können gültig sein. Aber um zu beantworten, ob eine Implementierung richtig ist, müssen Sie oft ein Kriterium durchgehen:

• Ob die Abstraktion des Begriffs klar ist. Unklare Konzepte können dazu führen, dass andere Mitarbeiter das Modell/die Klasse schwer verstehen und verwenden oder dass es in Zukunft schwierig ist, Funktionalität hinzuzufügen (z. B. Erweiterbarkeit). Die Wahl beinhaltet, einige Konzepte zu trennen oder sie in einem einzigen Konzept zu gruppieren, was genau das ist, womit wir oben konfrontiert sind.
• Ob die Sprache, das Framework, die Architektur, die wir wählen, die richtige ist. Dies sind oft große Entscheidungen und auch Entscheidungen, die nicht so leicht zu treffen sind, und wir können dies ohne ein Beispiel aus der realen Welt nicht im Detail diskutieren.

Andere Aspekte umfassen die Lesbarkeit des Codes, die Skalierbarkeit des Systems, die je nach Projekttyp sehr unterschiedlich ist (z. B. Backend vs. Frontend, große Anzahl von Benutzern vs. kleine Anzahl von Benutzern, normales Gerät vs. ressourcenbegrenztes Gerät).

Dies sind einige Aspekte, die ein Implementierer oder eine Architektur berücksichtigen kann, die sich auf die Unterscheidung zwischen gutem Design und schlechtem Design beziehen können.