Reflection Partial 2

Analysis and Modeling of Software

Dies ist die zweite Zusammenfassung der bisherigen Blogeinträge für das zweite drittel des Semesters im Fach Analysis and Modeling of Software an der TEC de Monterrey in Guadalajara, Mexico.

Wie auch schon in Reflection 1 soll in diesem Post zunächst eine kurze Zusammenfassung aller in diesem Drittel behandelten Themen folgen und zum Schluss noch meine persönlichen Gedanken zu diesem Abschnitt an der Uni in mxn.

DESIGN PATTERNS #MASTERY 05

In der Software-Entwicklung gibt es sogenannte Design Patterns, dabei handelt es sich um bewährte Lösungsschablonen für typisch auftretende Probleme beim Programmieren. Sie sind wie Blaupausen aufgebaut, sprich es handelt sich um vorgefertigten Code, den man dann an die eigenen Anforderungen anpassen kann um wiederauftretende Design-Probleme zu lösen.

WORAUS BESTEHT EIN PATTERN?

Die vier wesentlichen Bestandteile von Patterns:

• Absicht, welche kurz das Problem und dessen Lösung beschreibt
• Motivation, beschreibt Problem und Lösung eingehender
• Struktur der Klassen zeigt alle Teile des Patterns und wie diese zusammenarbeiten
• Code-Beispiel, mit einer bekannten Programmiersprache wird anhand eines Beispiels die Idee hinter dem Pattern besser verständlich

Geschichte der Patterns

Arten von Patterns

Es gibt viele verschiedene Arten von Patterns, zwei der wichtigsten sind zum Beispiel Singelton Patterns und Delegate Patterns.

Mehr zum Thema findest du in meinem Blogeintrag zum Thema Patterns:

https://pythonbasiccourse.home.blog/2019/10/01/design-patterns-mastery-05/

UML

UML oder auch Unified Modeling Language ist eine graphische Modelierungssprache. Sie gehört also zu den in Mastery 04 angesprochenen Modeling Languages. Sie dient zur Spezifikation, Konstruktion und Dokumentation von Software-Teilen und anderen Systemen.

UML PART 1 #MASTERY 06

Im Blog-Post UML Part 1 habe ich mich intensiv mit drei Arten von Diagrammen beschäftigt, nämlich: SEQUWENZDIAGRAMME KLASSENDIAGRAMME und OBJEKTDIAGRAMMEN

Als Beispiel soll ein Programm dienen mit dem man die Abläufe in einem Restaurant beschrieben werden. Natürlich werde ich auch hier wieder den zugehörigen Post verlinken in dem die einzelnen Diagramme unter anderem mithilfe von Videos erklärt werden.

SEQUWENZDIAGRAMME

Diese Art von Diagramm ist denkbar einfach gehalten. Ganz oben sind alle beteiligten Instanzen, in unserem Beispiel also die Personen im Restaurant (Gäste, Kellner, Koch, usw.). Die Zeit verläuft von oben nach unten.

KLASSENDIAGRAMME

In unserem Restaurant-Beispiel kann man hier annehmen, dass jeder Gast, Kellner, Koch oder eben der Betreiber eine Klasse darstellt. Jede Klasse hat unter dem Klassennamen die Atribute mit den zugehörigen Datentypen dahinter und wieder darunter befinden sich die Methoden der Klassen mit Klammern am Schluss. Wie üblich wird alles klein geschrieben.

OBJEKTDIAGRAMMEN

Wir gehen nun davon aus, dass wir in unserem Klassendiagramm eine Klasse Bestellung haben, deren Atribute die Nummer des bestellten Gerichts, Nummer des bestellten Getränks sowie der ausgerechnete Preis der Bestellung sind.

UML PART 2 #MASTERY 07

In diesem Post wurden drei weitere Diagramm-arten behandelt und ich habe mich auch noch kurz mit GRASP und MVC auseinandergesetzt.

Zustandsdiagramme

Mit Zustandsdiagrammen wird das Verhalten oder auch der „Zustand“ eines Objekts dargestellt. Wichtig ist hier dass man die Rechtecke, die die Zustände beschreiben runde Ecken haben und die Pfeile nach hinten offen sind.

Packetdiagramme

Im Prinzip stell das Paketdiagramm eine Zusammenfassung von verschiedenen Klassendiagrammen dar und wird dazu verwendet die Struktur eines modellierten Systems darzustellen.

Komponentendiagramm

Die Komponenten dieses Diagramms sind als eine Art Zusammenfassung mehrerer Klassen und ihrer Schnittstellen (ports) zu verstehen. Außerdem wird auch dargestellt, wie Komponenten voneinander abhängen und wie sie verbunden sind.

GRASP und MVC

Bei GRASP handelt es sich um Entwurfsmuster, die beschreiben welche Klassen und Objekte wofür zuständig sein sollen. Auf diese Art und Weise soll Einsteigern und Ungeübten ein besseres Bewusstsein für die Qualität des Codes vermittelt werden und die Kommunikation zwischen Softwareentwicklern erleichtert werden.

Man benutzt MVC, um eine spätere Erweiterung oder Änderung zu erleichtern und Wiederverwendbarkeit der einzelnen Komponenten zu ermöglichen. Es handelt sich dabei sowohl um ein Architekturmuster, als auch um ein Entwurfsmuster.

Classes to Tables #Mastery 08

Tabellen sind eine hervorragende Möglichkeit um große Mengen an Daten unter zu bringen. Außerdem bieten sie nebenbei den Vorteil, dass diese Daten auch noch übersichtlich geordnet sind.

Deswegen ist es im Softwareengeneering von großem Interesse, dass man mit Tabellen arbeitet. Besonders die Umwandlung von Klassen in Tabellen spielt hier eine nicht zu vernachlässigende Rolle.

Speziell in UML stellt sich die frage, wie man zum Beispiel ein KLassendiagram in eine Tabelle umwandelt um so eine einfachere Darstellung zu erlangen. Im wesentlichen handelt es sich dabei um fünf elementare Schritte:

1. Entscheide, welche Klassen zusammen gehören und wähle ein Schlüsselwort für eine Tabelle, die alle Hauptklassen enthält
2. Erstellen einer Tabelle, die alle Unterklassen enthält und benutze als Schlüsselwort den Namen der zugehörigen Hauptklasse
3. Verbinden der Unterklassen miteinander und einbinden aller einfachen Attribute
4. Verbinden der Hauptklassen miteinander und einbinden aller zugehörigen Attribute
5. Aneinanderreihen der Tabellen

Classes to Code #Mastery 09

Es stellt sich nun auch die Frage, wie man ein in UML erstelltes Klassendiagramm in lauffähigen Programmcode konvertieren kann.

Als einfaches Beispiel möchte ich hier wieder das klassenDiagramm aus #Mastery 06 nehmen.

Um aus diesem vorgefertigtem Diagramm Quellcode zu machen geht man wie folgt vor:

jo

Eigene Reflexion zum zweiten Abschnitt des semesters

Der zweite Teil meines Semesters hier an der TEC in Guadalajara war sehr aufschlussreich bezogen auf die beiden Kurse, die ich bei Ken habe. Ich bin immer noch sehr von seiner Art des Unterrichten überzeugt.

Die Möglichkeit fast alles selbständig und über das Internet zu erledigen gefällt mir sehr und ist meiner Meinung nach auch mehr als zeitgemäß. Dabei dienen die Vorlesung perfekt als Ergänzung für offenen Fragen oder zum besseren Verständnis.

Die Freiheit selbstständig durch eigene Recherche die Themen zu verstehen und anschließend mit eigenen Worten wieder zu geben sorg für ein noch besseres Verstehen der Themen als reines Auswendiglernen oder üben.

Ich denke man hat ein kompliziertes Thema erst dann richtig verstanden, wenn man es in eigenen Worten möglichst simpel und kurz wiedergeben kann.

Alles in allem bin ich weiterhin sehr angetan vom Schreiben eines Blog anstatt einfach den Stoff in sich hinein zu pressen zu versuchen. Man kann lernen wo und wann man möchte, dies trägt immens zur Motivation bei.

Meine gesteckten Ziele, die ich in Reflection 1 gesteckt habe habe ich nicht komplett erreicht. Ich bin zufriedener mit der Qualität meiner Posts und habe seit dem auch einige überarbeitet, jedoch konnte ich die Posts bisher nicht besser untereinander verlinken. Dies möchte ich noch nachholen.

Was den noch zu lernenden Stoff angeht bin ich sehr gespannt, was noch auf uns zukommen wird. Die bisherigen Themen konnte ich sehr gut verstehen und teils auch auf andere Fächer übertragen. Als Beispiel möchte ich hier meinen zweiten Kurs bei Ken aufführen, der sich auch in meinem Blog unter dem Namen Problemsolving with Programming TC1017.90 befindet.

Link zu TC1017.90 https://pythonbasiccourse.home.blog/category/tc1017-90/