All**Gemein**wissen

| Back to Overview

Hier ein paar Sachen, für die ich keine eigene Seite aufmachen will.

Warum ist SWT eigentlich so random und unstrukturiert. Wofür war dieser kleine Exkurs in UI Design eigentlich?? Wieso gab es den?

oder der Ausflug zu den Programmierparadigmen wie Objektorientierung, warum das ganze nochmal...

Hinweise zur Klausur

Hier etwas das ich frech kopiere.

-Der Diagrammtyp oben rechts im Kasten ist notwendig und wird möglicherweise Gnadenpunkte bringen. Ein fehlen gibt Punktabzug. -Bei Klassendiagramme nicht vergessen, das man bei ner Klasse ohne Attributliste irgendwie zeigt, dass die leer ist z.B. indem man da quasi son mini Rechteck zwischen dem Rechteck vom Klassennamen und der Methodenliste hat. -Bei Objektdiagrammen und auch im Sequenzdiagramm müssen die Namen unterstrichen sein, also Objektidentifikator:Klassenname_des_Objekts -Beim Sequenzdiagramm sollte, falls ein Objekt returned wird der Objektidentifikator auf dem return-Pfeil sein. -Wenn ihr irgendwas in nem Diagramm oder in ner Antwort haben solltet, was ihr korrigiert habt, streicht das durch, da die ansonsten diesen Teil der Aufgabe nicht bewerten können/Punkte abziehen. -Pinselt beim Use-Case-Diagramm keine lustigen Figürchen hin. Auch wenn das ein Auto ist, ist das im Use-Case-Diagramm ein Strichmännchen. -Bei einem "extend" im Use-Case-Diagramm ist die Zweiteilung des Kreises angebracht (3. Anforderungsanalyse - 3.4. Use Case Modellierung, Folie 48) -Bei Statcharts ist es nicht erlaubt, dass man zwei unterschiedliche Ereignis[Bedingung]/Aktion auf einen Pfeil schreibt, auch wenn das schöner aussieht. -Bei Featurediagrammen mit dem XOR aufpassen, ein Schelm könnte bei nem "gespaltenem" XOR bei drei Optionen möglicherweise reininterpretieren, dass das zwei XOR statt ein XOR ist. Aber da kann man dann in der Einsicht diskutieren.

-Merkt euch den weirden Stuff mit semantischer Differenz von Featurediagrammen, das könnte drankommen. -Allgemein kann alles drankommen 🤷 .

Kopplung und Kohäsion

Ist vermutlich wichtig, aber auch wenig

Kohäsion ist ein Maß für die innere Zusammengehörigkeit von Elementen eines Moduls. Heißt wenn es ein Element gibt, dass nicht mit den anderen Elementen zutun hat, ist die Kohäsion niedrig. ⇒\Rightarrow Höhe Kohäsion, mehr besser

Kopplung ist das Maß der Zusammenhang zwischen Modulen. Man möchte zum Beispiel das UI Framework doch auch vielleicht mal austauschen, hierfür braucht man Schwache Kopplung ⇒\Rightarrow Schwache Kopplung, weniger = besser

Prototyping

Prototyping ist eigentlich das was ich hier gerade betreibe, eine Vorversion von etwas, um es zu testen. Es gibt die Folgenden Subarten:

  • explorativ: Zur Analyse in der Analysephase. Wir danach nicht weiterentwickelt.
  • experimentell: Für Entwickler, um zu testen. Wird auch normalerweise nicht weiterentwickelt.
  • evolutionär: Der Zustand der Software wird ständig weiterentwickelt.

DevOps

Ganz spannendes Thema... halt wirklich. Wenn man schon so agile in der Entwicklung ist, ists ja blöd, wenn ich dann auf das Operations Team warten muss, bis die mal wieder meine Software updaten.

Deswegen gibt es das Continuous Delivery. Heißt das automatisierte (kontinuierliche) Deployment von Software. Bei mir wird automatisch der master-Branch auf dem Repo deployed.

Continuous Integration heißt das automatische zusammenführen der Komponenten heißt hier linken, testen und compilen. GitLab integriert ci in seiner Platform.

Security

Naja parsed nicht Sprachen aller Art (csv, java, etc...) mit Regex und vorallem nicht mit String concatenation.

XSS: Cross site scripting: Eine anderer Benutzer oder Seite kann Code auf deiner Seite ausführen. SQL Injection: Ein anderer Benutzer oder Seite kann beliebige SQL-Statements auf deiner Datenbank ausführen.

Architekturmuster

Könnte auch ein eigenes Doc sein, hatte aber keine Lust:

  • MVC: Model View Controller: Trennung von Daten, Darstellung und Logik
  • Layered: Trennung in verschiedene Schichten (z.B. Datenbank, Business, UI)
  • Pipes: Daten fließen durch Pipes durch. (z.B. unix-pipes)
  • Blackboard: Daten werden an einem Punkt (Blackboard) gesammelt, worauf mehrere Komponenten zugreifen. (z.B. AST in Compilern)
  • Proxy: Zwischenstück zwischen zwei Komponenten. (z.B. Proxy-Server)

Code-Generierung & Digialisierung mit Monti*

DSL (domain-specific language => DSL??) ist eine Sprache, die für eine bestimmte Domäne (z.B. Umgebung) entwickelt wurde (z.B. mit Monticore definitert).

MontiGem erstellt einen digitalen Zwilling von z.B. einer Pumpe. Wenn du am digitalen Zwilling was veränderst, wird das auch in der realen Pumpe verändert und umgekehrt.

Versionsverwaltung

Git ist der einzige Ort wo, code aufbewahrt werden sollte.

Es ermöglicht das gut zusammenarbeiten an einem Projekt.

Es gibt ein externen Speicherort (Remote) an dem ein Projekt (Repository) gespeichert wird. Beim git clone wird das Repository lokal kopiert. Es gibt verschieden Versionen von Dateien (Branches), die über den git checkout gewechselt werden können und über merge/pull-requests zusammengeführt werden.

Es werden nur die Änderungen gespeichert (Diffs), nicht die komplette Datei. Dadurch ist es möglich, dass mehrere Leute an einer Datei arbeiten können, die Änderungen werden über git commit -m "Beschreibung" lokal gespeichert und können über git push auf den Remote gespeichert werden. Sie können dann durch git pull oder git fetch zusammengeführt bzw. nur geladen werden.

Verfickte scheiße lernt endlich git, es ist nicht schwer.

Automatisierungen

Make, Gradle etc. sind Build-Tools. Sie können automatisch die Abhängigkeiten von Projekten herstellen und die Projekte compilen/builden.

Make

Hier falls es noch hilft eine kleine einführung in Makefiles:

# | target | dependencies | command |
prog: data.o main.o # <- Abhängigkeiten
      cc data.o main.o –o prog # <- Befehl
main.o: data.h main.h main.c
        cc –c main.c
data.o: data.c data.h
        cc –c data.c
clean: rm *.o prog

Bevor also prog ausgeführt wird, wird zuerst data.o und main.o ausgeführt usw. mit make prog führ man dann einen target aus.

Maven

Maven konfiguriert man mit xml (pom.xml) Dateien, es ist deutlich komplizierter (Es organisiert die Dependencies und es gibt Repositories von Öffentlichen Bibliotheken). Die gekennzeichneten Tags waren:

  • groupID: Eindeutige Identifikation z.B. Java package
  • artifactID: .jar Name
  • version: Version des Projektes
  • properties: Eigenschaften & Versionen des Projektes
  • dependencies: Abhängigkeiten des Projektes (Werden auch mit groupID und artifactID identifiziert)

Gradle

Gradle ist nochmal ein Stück komplizierter es funktioniert in zwei Phasen:

  • Konfiguration: Hier werden die Abhängigkeiten und Plugins definiert => Abhängigkeitsgraph wird erstellt
  • Ausführung: Hier werden die Tasks vom Abhängigkeitsgraph ausgeführt und compiliert.

Wenn hierzu was spezifisches abgefragt wird, beginnt die Revolution.

Sonstiges

Ja in den Folien ist noch viel mehr [über Produktlinien] (vor allem unnötiger Müll) aber

Ich hoffe nicht viel anderes kommt dran, sonst wird das hier noch länger, zudem bedeutet jede Sekunde das hier zu schreiben heißt -1IQ.

Lernt die Diagrammtypen und die Umwandlung in Code mit Entwurfsmuster