%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Paper of Seminar Software Engineering
%%     Professor Mag.DI. Roland Schwaiger.
%% Created for the
%%     Paris-Lodron-University, Institute of Computer Sciences.
%% By
%%     Oskar Schobesberger.
%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass[12pt,fleqn,a4]{report}

\usepackage{geometry}
\usepackage{graphics}

\sloppy
\parindent        1cm
\geometry{a4paper,tmargin=-1cm,bmargin=1cm,lmargin=1.6cm,rmargin=1.6cm}

\begin{document}
\begin{titlepage}
\centerline{\today}
\vspace{0.5cm}
\centerline{\large Seminar Software Engineering}
\vspace{0.5cm}
\hspace{2.3cm}


\vspace{2cm}
\centerline{\Huge\bf ImmoWarrior }

\vspace{2cm}
\centerline{\bf Report}
\centerline{\bf}

\vspace{2cm}
\centerline{\large  Schobesberger Oskar}
\vspace{0.2cm}
\centerline{oskarschobesberger@hotmail.com}
\vspace{4.5cm}
\centerline{Academic Supervisor Mag. Dipl.-Ing. Schwaiger Roland}

\vspace{1cm}
\centerline{\large Department of Computer Science}
\vspace{0.2cm}
\centerline{\large University of Salzburg}

\vspace{3cm}
Correspondence to: \\
\centerline{Universit\"{a}t Salzburg} \\
\centerline{Institut f\"{u}r Computerwissenschaften und Systemanalyse} \\
\centerline{Jakob-Haringer-Stra\ss e 2} \\
\centerline{A-5020 Salzburg} \\
\centerline{Austria}

\clearpage
\end{titlepage}

\tableofcontents

\chapter{Introduction}
\section{About this paper}
This paper contains a collection of my personal solutions to the weekly tasks.
Therefore it mainly consists of pictures showing certain diagrams. The
order of the chapters do not exactly resemble the order of the tasks to
which they belong, because i thought it is more useful to put the user
interface flow diagrams directly after user interface prototyping.
Of course there is nevertheless lack of consistency, because this paper does not describe every
single step of thinking and it does not contain our group results, which
are documented in the group paper anyway (although it is quite probable
that there are going to be many similarities to the group paper, on one
hand, because each group solution has been the ground for the following task
and on the other hand, because group interaction can not be expected to
be turned off until everybody has their personal solution).

\section{Short description of the problem}
The company called e-Immo wants us to design a software product that manages
(parts of) online-auctions for real estates. The System should basically
provide the following possibilities: \underline{record real estate} information and \underline{call real estate}
information.\\
It should be possible for single persons, but also for other systems to
call information.
 
\section{Development Progress}
\begin{enumerate}
\item CRC Cards
\item Use Cases
\item User Interface Prototyping
\item User Interface Flow Diagrams
\item Class Diagram
\item Activity Diagrams
\item Sequence Diagrams
\end{enumerate}

\chapter{CRC Cards}

\section{Short Description of CRC Cards}
CRC Cards should help to get a basic structure into the design. Functional
units can be worked out and grouped.
Each CRC Card contains the name of a class and two columns, with Responsibilities
of the left, and Collaborations on the right. Responsibilities show what a class contains and what a class "does".
Collaborations show which other class is involved in a certain Responsibiliy.\\
The following Picture, which describes my first ideas (obviously, i forgot
lots of important things, especially the login and user data) about the project via
CRC Cards, also has lines between the single card, which indicate collaboration.
\section{Image of CRC Cards}
\includegraphics{crc.eps} \\

\chapter{Use Cases}
Differently to what we presented as group i did not specify sub-use cases,
but only wrote down the two main use cases for record and enquiry.

\section{Record Real Estate}

\underline{Description}: User can record a new real-estate \\
\underline{Precondition}: User has the right to record real estates \\
\underline{Postcondition}: A new real-estate will be recorded 
\begin{enumerate}
\item \bf System presents login mask.\
\item \bf User submits username and password.\
\item \bf System verifies password and presents action choice mask.\
\item \bf User chooses Recording.\
\item \bf System presents Record Mask.\
\item \bf User submits real estate data.(optionally: cancel leads to 3.)\
\item \bf System asks to re-check data.\
\item \bf User verifies data and gives ok.(optionally: cancel leads to 5.)\
\item \bf System records real estate.\
\end{enumerate}
Optionally at any point: User can logout, which leads to step 1.

\section{Enquire Real Estate}

\underline{Description}: User enquires real-estate \\
\underline{Precondition}: none \\
\underline{Postcondition}: System Displays Real Estate Details
\begin{enumerate}
\item \bf System presents login mask.\
\item \bf User submits username and password.\
\item \bf System verifies password, checks rights level, and presents action choice mask.(optionally,
if user does not have record rights:step 5)\
\item \bf User chooses Enquire.\
\item \bf System presents Enquery mask.\
\item \bf User chooses search criteria. (optionally: cancel leads to 3.)\
\item \bf System presents result table, according to the rights level of the
user.\
\item \bf User selects one real estate and requires details (optionally: cancel leads to 5.)\
\item \bf System displays details for selected real estate.\
\end{enumerate}
Optionally at any point: User can logout, which leads to step 1.

\chapter{Essential User Interface Prototyping}
Essential User Interface Prototyping is done to get an image of what the
user is going to be presented on each screen the system provides. (How
you get from one screen to another is explained by the User Interface Flow
Diagrams in the next chapter)\\
This chapter contains two versions of User Interface Prototyping, the first
one shows what the screens in html implementation should consist of (six
screens). The wml version, which follows afterwards, still contains the
idea that there should not be more than one input field each screen and
"buttons" are replaced by keys that are available on every mobile phone.
As it was done at a time when i had no idea about wml, it is pretty far
away from our later wml-files (which were, like the html files, group-work and are therefore not
included in this paper).
\section{HTML-Screens}
\medskip
\includegraphics{hlogin.eps} \\
\includegraphics{haction.eps} \\
\includegraphics{hrecord.eps} \\
\includegraphics{henquire.eps} \\
\includegraphics{hresults.eps} \\
\includegraphics{hdetails.eps} \\

\section{WML-Screens}
\medskip
\includegraphics{wlogin.eps} \\
\includegraphics{action.ps} \\
\includegraphics{record13.ps} \\
\includegraphics{record48.ps} \\
\includegraphics{record9.ps}\\
\includegraphics{record10.ps}\\
\includegraphics{wenquire.eps}\\
\includegraphics{qresults.ps}\\
\includegraphics{details.ps}\\
\chapter{User Interface Flow Diagrams}
As mentioned above, the User Interface Flow Diagrams mainly show how the
user gets from one screen to another. I think the Diagrams are easy to
understand, every rectangle represents one screen and the arrows show their
directed connections. Text beside/above the arrows indicates which user
input triggers a certain screen change.
\section{HTML User Interface Flow Diagram}
\includegraphics{flowhtml.eps} 
\section{HTML User Interface Flow Diagram}
\includegraphics{flowwml.eps} \\

\chapter{Class Diagram}
While the previous chapters focussed on the perspective of a user, the class
diagram should help to understand the structure of the system. It shows
how the main components, the classes, are linked together and it also includes
basic methods and attributes of the classes. Its creation
allowed to identify new demanded classes, in order to provide the functionality
it should, according to use cases, crc cards and interface prototyping.
I included my second version of the diagram, because the first draft turned
out to be rather useless.
\includegraphics{classdiag.eps}
\section{Short Description}
Each time the program is started, the system interface creates an object
session, which furtheron instantiates login. If login fails, the session is
destroyed, otherwise login returns the data for the actual user. Then the
session can instantiate Record, Enquire, or auction together with input that
comes from the terminal/mobile phone (over the representation processor). Those access
the database which manages the user collection and the real estate collection. 


\chapter{Activity Diagram}
The Actvity Diagram shows the logic of system activities. The rhombuses
are decision points. I tried to put the whole system into a single diagram.
\includegraphics{actdiag.eps}
\chapter{Sequence Diagram}
The Sequence Diagram describes the messages between objects in time flow.
My diagram shows this only for the use case Record Real Estate. In order not
to let it become too complicated I assumed that the user has record rights
and, as i would say, behaves correctly. So there are no conditional statements in the
diagram.
\includegraphics{seqdiag.eps}

\appendix
\chapter{Protocols}
\section{2001-31-October}
\begin{enumerate}
\item Project Leader\\
\emph{Rescher Robert}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{What is a CRC-Session?} \\
\emph{Presentation of our CRC cards.}
\item New assignments \\
\emph{We need to re-organize the storage of user and real estate information.
We generally need new classes to refine our crc-model.}
\item Open questions \\
\emph{Auction online? \\Different user rights?} \\
\end{enumerate}

\section{2001-07-November}
\begin{enumerate}
\item Project Leader \\
\emph{Strobl Elisabeth}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{Presentation of refined CRC cards.}
\item New assignments \\
\emph{Auction is online.\\User interface prototype.} \\
\emph{User rights are organized like an onion: the more you pay, the more
you get} \\
\emph{Maybe include a possibility to search only real estates in a distance below
e.g 30 km}
\end{enumerate}

\section{2001-14-November}
I was absent.

\section{2001-21-November}
\begin{enumerate}
\item Project Leader \\
\emph{Fimberger Lucia}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{Presentation of the Use Case and User Interface Prototyping for Auction. Presentation of Class diagram}
\item New assignments \\
\emph{Make a new class diagram, that is more suitable for analysis phase;
avoid inheritation; define more classes; seperate database management from
system interface; create a class, called something like session, that is instantiated for each
user}
\end{enumerate}

\section{2001-05-December}
\begin{enumerate}
\item Project Leader \\
\emph{Schobesberger Oskar}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{Presentation of refined class model. Presentation of User Interface
Flow diagrams for wml and html.}
\item New assignments \\
\emph{Stick to one kind of User Interface Flow Diagrams. Make a html and
a wml progam that show the Interfaces.\\ Include a possibility for user administration
in the system}
\end{enumerate}

\section{2001-12-December}
\begin{enumerate}
\item Project Leader \\
\emph{Rescher Robert}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Fimberger Lucia, Schobesberger Oskar,
Nidetzky Marion}
\item Topics talked about \\
\emph{Presentation of activity diagrams and sequence diagrams}
\item New assignments \\
\emph{Subdiagram Record: seperate Input/OK (two activities).\\ Subdiagram
User Administration: create a subdiagram for add.\\
Sequence diagram: make time-steps more obvious.}
\end{enumerate}

\end{document}

