\documentclass[a4paper,10pt]{article}

\usepackage{graphicx}
\usepackage{url}
\usepackage{palatino}
%%\usepackage{rotating}



% A java class name
\newcommand{\cn}[1]{{\sf #1}}
% A java method name or call
\newcommand{\mn}[1]{{\sf #1}}

% A scenario
\newcommand{\scenario}[1]{{\em #1}}

% A TDD pattern in text
\newcommand{\tp}[1]{{\em #1}}


% A design pattern pattern in text
\newcommand{\dpn}[1]{{\scshape #1}}


\begin{document}

\title{SWEA Iteration 6: Compositional Design and Test Spy}

\author{
  \texttt{<<Group name>>}\\
  Computer Science, University of Aarhus\\
  8200 {\AA}rhus N, Denmark\\
  \makeatletter
  $<<$Names$>>$\\
}

\date{$<<$Date$>>$}

\maketitle

% =====================================================================
\section{Private Interfaces and ISP}

\subsection{Private Interface Design}

[Describe your improved design using private interfaces to handle
  internal mutation of domain abstractions Game, Card, and Hero]

\subsection{Refactoring}

[Show code before the refactoring; and next the refactored code based
  upon private interfaces, for the Game domain abstraction.]


% =====================================================================
\section{EtaStone}

\subsection{Design and UML}

[Sketch a compositional design using UML for EtaStone which uses a
  role interface]

\vspace{0.5cm}

[INCLUDE UML DIAGRAM HERE - A GOOD PICTURE OF HANDRAWN IS OK.]

[Argue for a
  single Role Interface that covers both Hero Powers as well as Card
  Effects.]

\subsection{Unit Testing using Test Spy}

[Include test code for ensuring correct behavior of the effect of one of
  the EtaStone cards]

[Include relevant code fragments of your Test Spy to support the above
  test case]

[Argue that you are doing Unit testing and not Integration testing in
  the above shown code fragments]

% =====================================================================
\section{SemiStone}

\subsection{Configuration Table}

[Fill in Table 1., similar to the table from FRS §17.2]

\begin{table}[th]
\caption{HotStone configurations}
\begin{center}
\begin{tabular}{|l||l|l|l|}
\hline
 & \multicolumn{3}{|c|}{ {\bfseries Variability points}} \\
\hline
{\bfseries Product} & {\bfseries Mana Prod.} & {\bfseries Winning} & {\bfseries \ldots} \\
\hline
\hline
AlphaStone & 3 every round & Findus/round 4 & - \\
BetaStone & +1 pr round & Defeat opponent & -\\
GammaStone & - & - & - \\
\ldots & - & - & \\
SemiStone & - & - & - \\
\hline
\end{tabular}
\end{center}
\label{table:configurations}
\end{table}

\subsection{SemiStone Code Configuration}

The SemiStone variant is configured in our code like this \dots
\vspace{1em}

[Provide production code fragment(s) that show the code that configure the GameImpl for
the SemiStone variant]
\vspace{1em}

The design of the HotStone system, with emphasis on the SemiStone variant,
is shown by the following UML diagram:
\vspace{1em}

[Include the UML diagram of all interfaces and classes in HotStone
  related to variant handling---but
  show only the associations between the SemiStone abstract factory
  implementation to its products, \emph{not} all the other
  associations between concrete factory classes.]

% =====================================================================
\section{Parametric 'getWinner()'}

The method \mn{getWinner()} in GameImpl would look like this if a
purely parametric design had been employed as variant handling
technique in the HotStone code:
\vspace{1em}

\noindent
[Provide (pseudo) code fragment(s) the show how a parametric design
  could be implemented]

% =====================================================================
\section{Backlog}


\begin{itemize}
\item \ldots
\item \ldots
\end{itemize}


\end{document}


