3 - J (mae)

Ein Unit Test ist ein automatisiertes Stück Code, das eine zu testende Methode oder Klasse aufruft und dann einige Annahmen über das logische Verhalten dieser Methode oder Klasse prüft. Ein Unit Test wird fast immer mithilfe eines Unit Testing Frameworks erstellt. Er kann einfach geschrieben und schnell ausgeführt werden. Er ist vollständig automatisiert, vertrauenswürdig3, lesbar und wartbar.

Logischer Code ist jegliches Stück Code, das irgendeine Art von Logik enthält, so klein es auch sein mag. Es ist Logischer Code, wenn er irgendetwas von dem folgenden enthält: eine if-Anweisung, eine Schleife, eine switch- oder case- Anweisung, Berechnungen oder irgendeine andere Art von entscheidungsfindendem Code.

1. Schreiben Sie einen Test, der fehlschlägt, um zu zeigen, dass im Endprodukt ein Stück Code oder eine Funktionalität fehlt.  

2. Lassen Sie den Test erfolgreich ablaufen, indem Sie Produktionscode schreiben, der die Anforderungen des Tests erfüllt.

3. Überarbeiten Sie Ihren Code (Refactoring).

hochwertigen Code, hochwertige Tests und ein besseres Design für meinen Code zu entwickeln

Refactoring bedeutet die Änderung eines Code-Stücks, ohne die Funktionalität zu ändern. z.B Klasse umbenennen

Lösungsbeschreibung für eine gegebene Anforderung

(Wie die Lösung aufgebaut/konstruiert ist)

Anforderungen (einführung, randbedingungen) => scope!

Strukturen (verschiedene sichten)

übergreifende Themen (technische konzepte, entwurfsentscheidungen, szenarien)

packages

codestrukturen

schichten

namensräume

szenairen (use cases, abläufe)

unter verwendung der bausteine aus der bausteinsicht (wie spielt alles zusammen)

zu jedem usecase ein baustein und umgekehrt...

was läuft wo

persistierung, GUI, Fehlerbehandlungen, Sessionhandling, Frameworks, Protokolle..

welche technologien

=> klar dokumentieren für nachwelt!

teilprobleme weiter aufgesplittet

UML:= Ist eine "Sprache" für die Modellierung der Strukturen und des Verhaltens von Software- und anderen Systemen.  

Ein Stereotyp ist eine Erweiterung vorhandener Modellelemente in UML. In der Praxis geben Stereotype vor allem die möglichen Verwendungszusammenhänge (Verwendungskontext) einer Klasse, einer Beziehung oder eines Paketes an

Ein Classifier innerhalb von UML ist ein abstraktes gedankliches Konstrukt, das Modellierer nie direkt in eines der Diagramme der UML einfügen. Als sogenannte abstrakte Metaklasse ist der Classifier vor allem nützlich für die Autoren der UML-Spezifikation und weniger für Anwender der UML.

Kann in mehreren Aggregatobjekten enthalten sein (kapitel in HTML dokument)

überlebt beim tod des ganzen

selten

kann nur zu einem Aggregatobjekt gehören, dieses aber wechseln (Datei)

stirbt mit dem löschen des Ganzen

is a

erbt von

durchgezogene linie mit weissem dreiecks pfeil, nach oben

beziehung zwischen speziellem zu generellem Classifier

beziehung von oben nach unten (keihn pfeil)

unteres objekt kann zusätzliche merkale haben zu den schon geerbten

Eine Aktion (action) steht für den Aufruf eines Verhaltens oder die Bearbeitung von Daten, die innerhalb einer Aktivität nicht weiter zerlegt wird. Die Aktion beschreibt einen Einzelschritt, der zur Realisierung des durch die Aktivität beschriebenen Verhaltens beiträgt.

Die Summe aller Aktionen, einschließlich der Reihenfolge ihrer Ausführung und der zur Laufzeit erstellten und verwendeten Daten, realisiert die Aktivität.

Die langfristige Wartbarkeit, die gute Verständlichkeit und die Möglichkeit auch nach Jahren den Überblick über die Strukturen und Zusammenhänge innerhalb ihres Systems noch zu wahren

beschreibt die Strukturen des Systems, dessen Bausteine, Schnittstellen und das zusammenspiel

Eine angemessene, "saubere" Architektur bedeutet: 

relevant 

effizient

pflegbar 

sparsam 

verständlich und nachvollziehbar

korrekt und aktuell 

prüfbar 

akzeptiert bei Lesern   

Bindeglied zwischen Projektmanager, Requirements Engineers, Entwickler, Tester und Betreiber

Anforderungen und Randbedingungen klären

expliziten Architektur-Ziele dokumentieren

Strukturen entwerfen (Technologieentscheide, )

Technische Konzepte entwerfen (für Bausteine)

Architektur kommunizieren

Umsetzung begleiten

Flexibilität, Erweiterbarkeit, Benutzerfreundlichkeit, Perfomance

Entwerfen können

Entscheiden können

Vereinfachen können

Implementieren können

Dokumentieren können

Kommunizieren können

Schätzen und bewerten können

Balancieren können

Beraten können

Vermarkten können

Programmierkonstrukte: Klassen, Module, Funktionen, Skripte, Programme

Pakete: Namensräume, Gruppierungen von Programmierkonstrukten

Konfiguration: bestimmen das Verhalten oder die Schnittstelle existierender Softwareteile z.B. Spring-Framework, Hibernate-Mapping, Stylesheets

Bibliotheken, Framworks, Standardsoftware: stellen "fertige" Lösungen dar, welche nicht selber entwickelt aber in eigne Software eingebunden oder müssen

Merke: Jeder Baustein verfügt über eine Schnittstelle und eine Reihe spezifischer Merkmale wie: Verantwortlichkeit, Variabilität, eventuell einen Verweis auf (von diesem Baustein erfüllten) Anforderungen, Ablageort etc. Kurz: Bausteine sind oft Blackboxen.

Beschreibung von

Zweck und die Verantwortung

Funktionen und/oder Services

Ein- und ausgehende Schnittstellen

zeigt innenleben (welches wiederum aus einer menge von kleineren blackboxes besteht)

zeigt die statische Struktur des Systems, Kernstück der Software-Architektur, erklärt aus welchen Bausteinen das System zusammengebaut ist und welcher Baustein fachliche oder technische Eigenschaften des Systems bereitstellen.

Verteilungssicht: zeigt die Verteilung von Systembestandteilen auf Hardware- und Softwareumgebungen => Knoten. Kurz: Klärt, welche Teile eines Systems auf welchen Rechnern, an welchem geografischen Standort auf welcher Umgebung ablaufen können. Zwingend für verteilte Systeme!