\documentclass[11pt,a4paper]{article}

%\usepackage{ngerman,a4}
\usepackage{amstext}
\usepackage{amssymb}
\usepackage{amsmath}
%\usepackage{stmaryrd}
\usepackage{enumerate}
%\usepackage{alltt}
\usepackage[latin1]{inputenc}
%\usepackage{graphicx}
\usepackage{cancel}
\usepackage{arcs}
%\usepackage{fuzz}

\thispagestyle{empty}

\title{Softwaretechnik (WS 2005/2006) - Übungsblatt 9}
\author{Jan Hendrik Dithmar - Matrikelnummer 2031259 \\
		Übungsgruppe Mi, 8-10 Uhr \\
		Dirk Heine - Matrikelnummer 2030941 \\
		Übungsgruppe Di, 14-16 Uhr \\\\
		Rückgabe: Übungsgruppe Di, 14-16 Uhr
	}
\date{}

\begin{document}

\newcommand{\AND}{\ensuremath{\wedge}}
\newcommand{\OR}{\ensuremath{\vee}}
\newcommand{\SetR}{\ensuremath{\mathbb{R}}}
\newcommand{\SetN}{\ensuremath{\mathbb{N}}}
\newcommand{\SetC}{\ensuremath{\mathbb{C}}}
\newcommand{\SetZ}{\ensuremath{\mathbb{Z}}}
\newcommand{\SetQ}{\ensuremath{\mathbb{Q}}}
\newcommand{\SetB}{\ensuremath{\mathbb{B}}}
\newcommand{\R}{\ensuremath{\mathbb{R}}}
\newcommand{\N}{\ensuremath{\mathbb{N}}}
\newcommand{\C}{\ensuremath{\mathbb{C}}}
\newcommand{\Z}{\ensuremath{\mathbb{Z}}}
\newcommand{\Q}{\ensuremath{\mathbb{Q}}}
\newcommand{\B}{\ensuremath{\mathbb{B}}}
\newcommand{\QED}{\ensuremath{\hspace*{\fill}\square}}
\newcommand{\FLASH}{\ensuremath{\hspace*{\fill}\lightning}}
\newcommand{\OnotO}{\ensuremath{\mathcal{O}}}
\newcommand{\bild}[4]{
	\begin{figure}[htpb]
		\centering
			\includegraphics[width=#1cm]{#2}\\[0.2cm]
			\caption{#3}
			\label{#4}
	\end{figure}
	}

\maketitle

\newpage
\section*{Aufgabe 1}
\begin{center}
\begin{tabular}{|l|c|c|c|c|}
\hline
& Abstraktion & Einkapselung & Modularität & Hierarchie \\ \hline
Klassen & ja & ja & ja & ja \\ \hline
Schnittstellen & ja & ja & ja & nein \\ \hline
Sichtbarkeitsmodifizierer & nein & ja & ja & nein \\ \hline
Vererbung & ja & nein & ja & ja \\ \hline
Dynamische Bindung & nein & nein & ja & ja \\ \hline
\end{tabular} \\[1.0cm]
\end{center}
\begin{itemize}
	\item \textbf{Abstraktion}
		\begin{itemize}
			\item \textbf{Klassen:} Klassen tragen zum Prinzip der Abstraktion bei, da durch sie mittels geeigneter Schnittstellen die Interna der Klassen verborgen werden können, und es somit möglich ist von der konkreten Implementierung des Objektes zu abstrahieren.
			\item \textbf{Schnittstellen:} Schnittstellen tragen zum Prinzip der Abstraktion bei, da durch sie die gesamten Interna einer Klasse nach außen verborgen werden, und somit von den Details der Klasse abstrahiert werden kann.
			\item \textbf{Sichtbarkeitsmodifizierer:} Sichbarkeitsmodifizierer tragen nicht zum Prinzip der Abstraktion bei. Sie können zwar einzelne Werte nur bestimmten Objekten zugänglich machen, diese aber nicht effizient nach außen verbergen.
			\item \textbf{Vererbung:} Vererbung trägt zum Prinzip der Abstraktion bei, da hierdurch abstrakte Oberklassen gebildet werden können, welche die tatsächlichen Details erst einmal ausblenden, und somit eine abstrakte Sicht auf das Objekt ermöglichen.
			\item \textbf{Dynamische Bindung:} Dynamische Bindung trägt nicht zum Prinzip der Abstraktion bei, da hierdurch nicht unmittelbar ein Verbergen der konkreten Informationen eines Objektes möglich wird.
		\end{itemize}
	\item \textbf{Einkapselung}
		\begin{itemize}
			\item \textbf{Klassen:} Klassen tragen zum Prinzip der Einkapselung bei, da durch sie die Interna der Klasse innerhalb der Klasse selbst bearbeitet werden, und somit nicht nach außen dringen.
			\item \textbf{Schnittstellen:} Schnittstellen tragen zum Prinzip der Einkapselung bei, da sie es unmöglich machen sich von den Internas eines andern Objektes abhängig zu machen (wenn sie richtig verwendet werden).
			\item \textbf{Sichtbarkeitsmodifizierer:} Sichtbarkeitsmodifizierer tragen zum Prinzip der Einkapselung bei, da durch sie erst Schnittstellen und damit Klassen ihre Internas verbergen können.
			\item \textbf{Vererbung:} Vererbung trägt nicht zum Prinzip der Einkapselung bei, da eine Vererbungshierarchie keine zusätzlichen Daten einkapselt, welche nicht schon die einzelnen Klassen eingekapselt haben.
			\item \textbf{Dynamische Bindung:} Dynamische Bindung trägt nicht zum Prinzip der Einkapselung bei, da auch sie keine Möglichkeit bietet, die internen Daten nach außen zu verstecken.
		\end{itemize}
	\item \textbf{Modularität}
		\begin{itemize}
			\item \textbf{Klassen:} Klassen tragen zum Prinzip der Modularität bei, da sie das Mittel sind, um aus dem Gesamten einzelne Objekte zu formen.
			\item \textbf{Schnittstellen:} Schnittstellen tragen zum Prinzip der Modularität bei, da durch sie die Interaktion, die Kopplung, sowie die Unabhängigkeit der einzelnen Objekte untereinander sichergestellt werden kann, indem die einzelnen Objekte aufgrund der Schnittstelle automon agieren können müssen.
			\item \textbf{Sichtbarkeitsmodifizierer:} Sichtbarkeitsmodifizierer tragen zum Prinzip der Modularität bei, da sie sich nicht von den Internas andere Objekte abhängig machen, und somit die Wiederverwendbarkeit der anderen Objekte sicherstellen können.
			\item \textbf{Vererbung:} Vererbung trägt zum Prinzip der Modularität insofern bei, als dass man abstrakte Oberklassen bilden kann, auf denen man arbeiten kann, und sich somit bei eventuellen Abhängigkeiten nicht auf die Abhängigkeit von einer konkreten Klasse beziehen muss.
			\item \textbf{Dynamische Bindung:} Die Dynamische Bindung trägt insoweit zum Prinzip der Modularität bei, als dass man sich erst zur Laufzeit entscheiden kann welche Bindungen man eingehen möchte, und dies nicht im Quellcode fest vorgeben muss.
		\end{itemize}
	\item \textbf{Hierarchie}
		\begin{itemize}
			\item \textbf{Klassen:} Klassen tragen zum Prinzip der Hierarchie bei, da sie die Mittel sind um komplexe Vererbungshierarchien zu erstellen.
			\item \textbf{Schnittstellen:} Schnittstellen tragen nicht zum Prinzip der Hierarchie bei, da durch die Wahl der Schnittstelle erst einmal keine Hierarchie geschaffen werden kann.
			\item \textbf{Sichtbarkeitsmodifizierer:} Sichtbarkeitsmodifizierer tragen nicht zum Prinzip der Hierarchie bei, da die Modifikation der Sichtbarkeit eines Objektes keine Hierarchie impliziert.
			\item \textbf{Vererbung:} Vererbung trägt zum Prinzip der Hierarchie bei, da durch sie erst große Abhängigkeitsbäume, welche eine Hierarchie vorgeben, ermöglicht werden.
			\item \textbf{Dynamische Bindung:} Dynamische Bindung trägt zum Prinzip der Hierarchie bei, da mittels Dynamischer Bindung das Open/Close Prinzip verwirklicht werden kann.
		\end{itemize}
\end{itemize}

\section*{Aufgabe 2}
\subsubsection*{(a)}
\begin{itemize}
	\item \textbf{Open-Close-Prinzip:} Das Open-Close-Prinzip beschreibt, dass ein Objekt zwar auf der einen Seite geschlossen für Änderungen, also in seinem aktuellen Zustand unveränderlich, jedoch auf der anderen Seite offen für Erweiterungen, also jederzeit an eventuelle Änderungen anpassbar sein soll. Dieses Prinzip kann man im Objektorientierten Ansatz zum Beispiel durch Vererbung verwirklichen. Während die Klasse \textit{Auto} unveränderlich ist, kann man jederzeit, falls nötig, durch Vererbung ein Auto erzeugen welches sehr gut im Gelände ist, und auf der anderen Seite auch ein Auto erzeugen welches zwar im Gelände nicht vorwärtskommt, dafür aber auf festen Straßen sehr schnell fährt. Diese beiden Klassen \textit{Geländewagen} und \textit{Rennwagen} sind somit von Auto abgeleitet und selbst auf die neuen Anforderungen angepasst. Die Oberklasse \textit{Auto} wurde jedoch niemals verändert.
	\item \textbf{Abhängigkeits-Prinzip:} Abhängigkeiten sollten nur zu Abstraktionen und nicht zu konkreten Unterklassen bestehen. Als Beispiel kann man ebenfalls obiges Beispiel anführen. Ein spezieller Typ Auto (z.B. ein \textit{Panzer}) sollte nicht von \textit{Geländewagen}, sondern von \textit{Auto} abgeleitet sein.
\end{itemize}
Im gegebenen Beispiel sieht es so aus, dass die Klasse \textit{University} eine Methode \texttt{getTotalSalaries()} hat, um über die Klasse \textit{Employee}, und deren Methode \texttt{getSalary()}, welche das Gehalt eines \textit{Employee} ausgibt, um die Gesamtsumme der Gehaltszahlungen der Universität auszugeben. Will eine Universität auf einmal nicht nur Hiwis und Professoren Geld zahlen, sondern auch den Studenten, so reicht es aus, eine weitere Klasse \textit{Student} von der Klasse \textit{Employee} abzuleiten, und die entsprechenden Mehtoden in \textit{Student} zu implementieren. Somit kann die Universität weitere Angestellte bekommen ohne dass sie dazu selbst verändert werden müsste. Auch die Änderungen in der Klasse \textit{Employee} belaufen sich (falls nötig) auf Kleinigkeiten. Somit ist die gesamte Hierarchie einfach um weitere Gehaltsempfänger zu erweitern, ohne dass die Struktur als solches dafür groß geändert werden müsste.

\subsubsection*{(b)}
\textbf{Problem:} Diese Implementierung ist zu speziell: die Auswertung verwendet hauptsächlich Details der Implementierung. Sie ist also sehr nahe an der gegebenen Struktur und es fehlt ihr an Abstraktion. Es gibt keine Klasse, die es erlaubt, das Gehalt aller Professoren zu ermitteln. Änderungen sind nur schwer durchzuführen, da klar definierte Schnittstellen fehlen. Das Demeter-Prinzip wird ebenfalls verletzt, da sich die Funktion zum Ermitteln der Daten ihren Weg durch die ganze Klassenhierarchie bahnt. \\[1cm]
\textbf{Verbesserte Lösung:} \\
Wir müssen zunächst das Design geringfügig ändern: \\
Die Klasse \textit{University} bekommt eine neue Funktion \texttt{double getTotalProfSalaries()}
\begin{verbatim}
public double getTotalProfSalaries() {
  double sum = 0;
  Iterator e = employees.iterator();
  while (e.hasNext()) {
    if(e instanceof Professor) sum+=((Employee e.next()).getSalary();
  }
  return sum;
}

public double getProfSalaries() {
  double sum = 0;
  University u;
  for (int i = 0; i < universities.size(); i++) {
    u = (University) universities.get(i);
    sum+=u.getTotalProfSalaries();
  }
  return sum;
}
\end{verbatim}
Mit diesen Änderungen wird das Demeter-Prinzip eingehalten. Außerdem findet das Open-Close-Prinzip Anwendung, da bei der Implementierung weitestmöglich abstrahiert wird.
%\begin{verbatim}
%public double getProfSalaries() {
%  double sum = 0;
%  Iterator u = universities.iterator();
%  Iterator e = null;
%  while (u.hasNext()) {
%    e = u.employees.iterator();
%    while (e.hasNext()) {
%      if(e instanceof Professor) sum+=((Employee) e.next()).getSalary();
%    }
%  }
%  return sum;
%}
%\end{verbatim}

\newpage
\section*{Aufgabe 3}
\subsubsection*{(a)}
\begin{itemize}
	\item \textbf{Vorbedingungen:} keine
	\item \textbf{Nachbedingungen:}
		\begin{itemize}
			\item \verb!size = size + 1!
			\item \verb!pop(push(x,Stack)) = Stack!
			\item \verb!top(push(x,Stack)) = x!
		\end{itemize}
\end{itemize}

\subsubsection*{(b)}
Die Methode \texttt{push()} des \textit{BoundedStack} sollte eine Exception werfen, falls trotz vollem Stack ein Objekt hinzugefügt werden soll. Das hinzuzufügende Objekt selbst sollte nicht hinzugefügt werden, der Stack also unverändert bleiben.

\subsubsection*{(c)}
\begin{itemize}
	\item \textbf{Vorbedingungen:}
		\begin{itemize}
			\item \verb!isFull() == false! \quad also \quad \verb!size < maxsize!
		\end{itemize}
	\item \textbf{Nachbedingungen:}
		\begin{itemize}
			\item \verb!size = size + 1!
			\item \verb!size! $\leq$ \verb!maxsize!
			\item \verb!pop(push(x,Stack)) = Stack!
			\item \verb!top(push(x,Stack)) = x!
		\end{itemize}
\end{itemize}

\subsubsection*{(d)}
In der von uns gewählten Implementierung von \textit{BoundedStack} ist diese keine Erweiterung des Stack nach dem Liskov-Prinzip, da \textit{BoundedStack} zwar stärkere Nachbedingungen hat, jedoch auch die stärkere Vorbedingung, dass der Stack seine maximale Größe beim Hinzufügen eines Elementes noch nicht erreicht haben darf, was dem Prinzip von Liskov widerspricht.

\newpage
\section*{Aufgabe 4}
\subsubsection*{(a)}
\begin{verbatim}
aspect a4a {
  pointcut publicJavaUtilCall():
    (call (public * java.util.*.* (..)));
	
  before(): publicJavaUtilCall() {
    System.out.println("Entering: " + thisJoinPoint);
  }
}
\end{verbatim}

\subsubsection*{(b)}
\begin{verbatim}
aspect a4b {
  public long MyVector.countNullItems() {
    return this.capacity() - this.size();
  }
}
\end{verbatim}

%\newpage
\subsubsection*{(c)}
\begin{verbatim}
aspect a4c {
  pointcut StrictMathSqrtChecking(): 
    call (public double Math.sqrt(double));
	
  after(double a) returning: (
      StrictMathSqrtChecking() && 
      args(a) &&
      !cflow(StrictMathSqrtChecking())
    ) {
    double result_math = Math.sqrt(a);
    double result_strictmath = StrictMath.sqrt(a);
    if (result_math != result_strictmath) {
      System.out.println(
          "In " + thisJoinPoint.getSourceLocation() + ": "
          + thisJoinPoint + ":\n\t"
          + "Math.sqrt(" + a + ")=" + result_math 
          + ", while StrictMath.sqrt(" + a + ")=" + result_strictmath);
    }
  }
}
\end{verbatim}

\end{document}