...
 
Commits (4)
......@@ -23,20 +23,8 @@
\usepackage{xtab}
\usepackage[inline]{enumitem}
\usepackage{fontspec}
\setromanfont[
Path=fonts/Roboto/,
BoldFont=Roboto-Bold.ttf,
ItalicFont=Roboto-Italic.ttf,
BoldItalicFont=Roboto-BoldItalic.ttf
]{Roboto-Regular.ttf}
\setmonofont[
Path=fonts/Hack/,
BoldFont=Hack-Bold.ttf,
ItalicFont=Hack-Italic.ttf,
BoldItalicFont=Hack-BoldItalic.ttf
]{Hack-Regular.ttf}
\usepackage[default]{sourcecodepro}
\usepackage[sfdefault]{ClearSans}
%German-specific commands
%--------------------------------------
......@@ -176,7 +164,7 @@ Einzige \textbf{Ausnahme}: architekturrelevante Arbeitspakete können vom System
Nicht nur generische Arbeitspakete aufführen (Generisch: Domainmodell, Use Cases. Nicht-generisch: Funktionalität für Speichern des Warenkorbs), unproduktive Tätigkeiten aufführen (z.B. Serversetup), "abhakbar" schreiben.
\subsection{Nicht Fuktionale Anfoderungen}
\subsection{Nicht Funktionale Anforderungen}
Ergänzen Use-Cases und Domain-Modelle, Performance, Mengegerüst (50'000 Artikel), Sicherheit (Firewalld, Intrusion Detection), Benutzerfreundlichkeit
......@@ -228,7 +216,11 @@ Projekt-Dokumentation, Benutzerhandbuch, Installations-Anleitung
\item Deployment
\item Datenspeicherung
\item Grösse und Leistung
\end{enumerate}
\end{enumerate}
\begin{description}
\item[Software Architektur] Summe der Design-Entscheide die von grosser Tragweite sind und länger leben. - Interfaces zwischen Subsystem, Interfaces zwischen unabhängigen Prozessen, Datenstrukturen (Änderungen haben grösste Auswirkung auf Code), Cross-cutting concerns (Security, Logging, Exception Handling, etc)
\end{description}
\section{Projekt-Automation}
......@@ -248,7 +240,7 @@ Alle Aufgaben, die mehrmals durchgeführt werden, sollten automatisiert werden.
\subsection{Continuous Integration (CI)}
Always have a runnable product, Have fast feedback in case of errors, Allow division of work without losing control. Daily Build / Nightly Build: Alle 24h weil Buildzeit (inkl. Test) > 6h, "Daily Build": Alle 3h weil Buildzeit ~1h, mehr Entwickler => mehr Buildfehler: Teilsysteme entkoppeln damit weniger Entwickler am Gleichen arbeiten.
Always have a runnable product, Have fast feedback in case of errors, Allow division of work without losing control (Integration hell). Daily Build / Nightly Build: Alle 24h weil Buildzeit (inkl. Test) > 6h, "Daily Build": Alle 3h weil Buildzeit ~1h, mehr Entwickler => mehr Buildfehler: Teilsysteme entkoppeln damit weniger Entwickler am Gleichen arbeiten.
\subsubsection{Ingredients}
......@@ -260,7 +252,7 @@ Reduziert Risiken, einfacher Bugs zu entdecken, Basis für Continous Delivery (d
\subsubsection{Risk and measures}
\textbf{Fehler zu spät erkennen} \\rightarrow Automatisierte Tests \textbf{Software nur an einem Ort/Rechner lauffähig} $\rightarrow$ auf verschiedenen Maschinen testen \textbf{Doppelten Code vorhanden} $\rightarrow$ beim Buildprozess Matriktools laufen lassen welche dub. Code erkennen. \textbf{Schlechte SW-Qualität} $\rightarrow$ z.B Checkstyle
\textbf{Fehler zu spät erkennen} $\rightarrow$ Automatisierte Tests \textbf{Software nur an einem Ort/Rechner lauffähig} $\rightarrow$ auf verschiedenen Maschinen testen \textbf{Doppelten Code vorhanden} $\rightarrow$ beim Buildprozess Matriktools laufen lassen welche dub. Code erkennen. \textbf{Schlechte SW-Qualität} $\rightarrow$ z.B Checkstyle
\subsubsection{CI Practices}
......@@ -543,6 +535,20 @@ Person-Months (PM) $$ PM = 3.2 * (KDSI) ^{1.05} $$ Development Time: $$ 2.5 * (P
\section{Metriken}
Projekt besser zu verstehen, Verbesserungspotential sehen und die Qualität zu erhöhen (Technical Debt besser einschätzen)
Zukünftige Projekte besser abschätzen, Effekt von Anpassungen bewerten, Kosten von Projekten zu sehen
\begin{description}
\item[Indikatoren] Grösste SRC-Files (LOC), Cyclomatic Complexiy, Code Guidelines Komformität, Number of Commits, Gefährliche Konstrukte, Duplicate Code, Kopplung/Kohäsion, Test Coverage, Lesbarkeit, Separation of Concerns, Gutes Naming
\item[Typen]
\textbf{Umfangsmetriken} (Anzahl Codezeilen, Anzahl Unterprogramme), \textbf{Logische Strukturmetriken} (McCabe, WMC),
\textbf{Datenstrukturmetriken} (Anzahl Variablen \& ihre Gültigkeit),
\textbf{Stilmetriken} (Namenskonventionen), \textbf{Bindungsmetriken} [Kohäsion und Kopplung] (Anzahl Packages ausserhalb, von denen Klassen im Package abhängen $\rightarrow$ Efferent Coupling)
\item[Tools]
\textbf{Dynamisch}: (Code ausführen) Covertura, EclEmma, Unit Tests, Integration Tests
\textbf{Statisch}: Checkstyle, FindBugs, ReSharper, STAN, structure101, Metrik Anaylse (McCabe), Reviews, Formal Verification
\end{description}
\subsection{Zyklomatische Zahl}
Misst Komplexität der logischen Struktur auf Basis Kontrollflussgraph G eines Programms. Zyklomatische Zahl (Anzahl linear unabhängiger Pfade durch Programm). $G$ berechnet sich $V(G) = e -n + 2p$ mit der Anzahl Kanten (edges) $e$, Anzahl Knoten (nodes) $n$ und Anzahl Komponenten (unabhängige Teil-Graphen) $p$. Für einzelne Funktion/Methode kann die vereinfachte Formel $V(G) = Anzahl Verzweigungen + 1$ verwendet werden.
......@@ -608,6 +614,9 @@ Refaktorisiert werden sollte das Package, welches am Weitesten von der Main-Sequ
Visualisiert Abhängigkeiten mit Richtung und Anzahl Referenzen.
\section{Technical Debt}
Code Smells, Fehlende Tests, Q-Mängel, Keine Zeit für Review, etc.
\section{Code Reviews}
Immer zwischen Peers aus der eigenen Abteilung mit Gruppe mehrerer Personen, definierten Rollen, definiertem Stück Code, begrenzter Zeit, Protokoll und Nacharbeiten.
......@@ -663,12 +672,12 @@ Q = Postcondition \\
Wenn ein Programm \textit{C} aus einem Ausgangszustand ausgeführt wird, welcher die Bedingung \textit{P} erfüllt, wird der Endzustand nach Beendigung von \textit{C} die Postbedingung \textit{Q} erfüllt.
\begin{minted}{go}
{x = a y = b}
\begin{minted}[escapeinside=||,mathescape=true]{go}
{x = a |$\land$| y = b}
t:=x;
x:=y;
y:=t;
{x = b y = a}
{x = b |$\land$| y = a}
\end{minted}
\subsection{Weakest Precondition}
......@@ -731,7 +740,7 @@ while i != x do {Inv: i <= x}
\item Letzte Bedingung in Schleife f = Invariante
\item Schleifen Nachbedingung g = Invariante \&\& !Schleifenbedingung
\item e und b von Unten nach Oben berechnen
\item Beweisen: \texttt{a => b ∧ d => e ∧ g => h}
\item Beweisen: a $\Rightarrow$ b $\land$ d $\Rightarrow$ e $\land$ g $\Rightarrow$ h
\end{enumerate}
Beweisen (z.B. $a => b$
......@@ -850,7 +859,7 @@ Das Anlegen von Objekten ist eine der häufigsten Aktivitäten in einem objektor
\subsection{High cohesion:}
Hohe Kohäsion ist ein Pattern, welches versucht Objekte angemessen fokussiert, überschaubar und verständlich zu halten. Hohe Kohäsion wird im Allgemeinen zur Unterstützung der niedrigen Kopplung verwendet. Hohe Kohäsion bedeutet, dass die Verantwortlichkeiten eines bestimmten Elements stark miteinander verbunden und stark fokussiert sind. Die Aufteilung von Programmen in Klassen und Subsysteme ist ein Beispiel für Aktivitäten, die die kohäsiven Eigenschaften eines Systems erhöhen. Alternativ ist eine nidrige Kohäsion eine Situation, in der ein bestimmtes Element zu viele unabhängige Verantwortlichkeiten hat. Elemente mit geringer Kohäsion leiden oft darunter, dass sie schwer zu verstehen, schwer wiederzverwenden, schwer zu pflegen sowie zu schwer zu verändern sind.
Hohe Kohäsion ist ein Pattern, welches versucht Objekte angemessen fokussiert, überschaubar und verständlich zu halten. Hohe Kohäsion wird im Allgemeinen zur Unterstützung der niedrigen Kopplung verwendet. Hohe Kohäsion bedeutet, dass die Verantwortlichkeiten eines bestimmten Elements stark miteinander verbunden und stark fokussiert sind. Die Aufteilung von Programmen in Klassen und Subsysteme ist ein Beispiel für Aktivitäten, die die kohäsiven Eigenschaften eines Systems erhöhen. Alternativ ist eine nidrige Kohäsion eine Situation, in der ein bestimmtes Element zu viele unabhängige Verantwortlichkeiten hat. Elemente mit geringer Kohäsion leiden oft darunter, dass sie schwer zu verstehen, schwer wiederzverwenden, schwer zu pflegen sowie zu schwer zu verändern sind.
\subsection{Indirection:}
......@@ -862,7 +871,7 @@ Informationsexperte ist ein Prinzip mit dem festgelegt wird, wo Verantwortlichke
\subsection{Low coupling:}
Low coupling ist ein Maß dafür, wie stark ein Element mit anderen Elementen gekoppelt ist. Low coupling ist ein Pattern welches vorgibt, wie man Verantwortlichkeiten zuweist. Geringere Abhängigkeit zwischen den Klassen, Veränderung einer Klasse mit geringeren Auswirkungen auf andere Klassen, höheres Wiederverwendungspotenzial.
Low coupling ist ein Maß dafür, wie stark ein Element mit anderen Elementen gekoppelt ist. Low coupling ist ein Pattern welches vorgibt, wie man Verantwortlichkeiten zuweist. Geringere Abhängigkeit zwischen den Klassen, Veränderung einer Klasse mit geringeren Auswirkungen auf andere Klassen, höheres Wiederverwendungspotenzial.
\subsection{Polymorphism:} According to polymorphism principle, responsibility of defining the variation of behaviors based on type is assigned to the type for which this variation happens. This is achieved using polymorphic operations. The user of the type should use polymorphic operations instead of explicit branching based on type.
......