
\documentclass[12pt,fleqn,a4paper]{report}
%\usepackage[austrian]{babel}
%\usepackage{german}
\usepackage{amsfonts}
\usepackage{latexsym}
\usepackage{xspace}
\usepackage{epsfig}
\usepackage{psfrag}
\usepackage{graphicx}

\textheight     680pt
\textwidth      460pt
\topmargin      -40pt
\oddsidemargin    5pt
\evensidemargin   5pt
\parindent        0pt

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


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

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

\vspace{1cm}
\centerline{\large Fimberger Lucia \hfill Nidetzky Marion \hfill Rescher Robert}  \\
\vspace{0.2cm}
\centerline{redwing@utanet.at \hfill mnidetzk@cosy.sbg.ac.at \hfill rrescher@cosy.sbg.sc.at} \\ 
\vspace{1cm}
\centerline{\large  Strobl Elisabeth \hfill Schobesberger Oskar} \\
\vspace{0.2cm}
\centerline{estrobl@cosy.sbg.ac.at \hfill oschobes@cosy.sbg.ac.at}
\vspace{2.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}



%\begin{abstract}
%{\sl The purpose of this projest is to learn how to make a software, not the implementaion. The aspect we had to view is the planning of software. }
%\end{abstract}

\tableofcontent


\chapter{Introduction}
\section{Terms of reference}           
\\
A real-estate auction firm \(e-Immo\) wants a new software for processing the collection of information and of the representation of information. This processing should be simple. The users of this system are the collector of information and the inquirer, who can be a person or another system. One demand is, that the system is simple to service, by meaning, it should not be necessary to install the collection- and representation-components local. Furtheron, \(e-Immo\) should have the possibility to influence the processing of information for individuals.
\section{Development evolution} \\
\begin{enumerate}
\item Demands on the system
%\item Rough draft
\item CRC cards
%\item Use Cases
%\item Essential user interface prototyping
\end{enumerate}

\chapter{Problem-description} 
\section{Demands to the system} \\
\begin{itemize}
\item Collecting information (in our case real-estate).
\item Possibility to enquiry information.
\item Real-estate collection.
\item No local installation of components.
\item User has to be identified.
\item Different access rights.
\item Processing of representation.
\item Auction is online.
\item User's administration.
\end{itemize}
%\section{Rough draft}


\chapter{CRC cards}
\section{Short introduction into CRC}
Founder is Beck Cunningham (ca. 1989). \\
A \(Class-Responsibility-Collaboration-Session\) concentrates on modelling a CRC-model. A CRC-model defines a class for each part of a problem that should be solved. A class consists of its responsibilities, which are called the \(properties\) and the \(methods\). A property is a non-operatable attribut, it is always an instance of another data type, which can also be a complex type or a class. The class-to-class relation is called collaboration. A method is an operating routine that can be called. \\
CRC-models are made for abstracting the reality by grouping functional units. These functional units communicate with each other. Usually, CRC-models have hierachical structures. It's not usual that two classes communicate circular with each other. \\
The members of a CRC-session are a project leader, some collaborators and perhaps a supervisor. The CRC concept seperates a problem into several classes, which has the advantage that developers do not need to know the functional structure of the whole, but of only one class. Finally, the classes commuicate with each other via defined interfaces, and it's equal to the calling class, how the rest of the called class is structured and implemented.


\section{Each individual CRC card}
\begin{enumerate}
\item \underline{real-estate} \\
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item knows its characteristics
\end{itemize}
\item \underline{real-estate collection} \\
 \\
responsibilities \hfill collaboration
\begin{itemize} 
\item knows the real-estates \dotfill real-estate
\item edits real-estates \dotfill recorder
\item returns real-estates \dotfill enquirer
\end{itemize}
\item \underline{user} \\
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item knows its characteristics
\end{itemize}
\item \underline{user collection} \\ 
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item knows users and their access rights \dotfill user, access rights
\item edits users and their access rights
\item passes information about user and his rights \dotfill system interface
\end{itemize}
\item \underline{access rights} \\
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item knows its characteristics
\end{itemize}
\item \underline{system interface} \\
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item offers login \dotfill representation processor
\item checks login data \dotfill user collection
\item enables request or record of data \dotfill representation processor
\item transmits data \dotfill recorder, enquirer
\end{itemize}
\item \underline{representation processor} \\
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item receives preprocessed data \dotfill enquirer
\item passes query related real-estates \dotfill terminal
\item displays masks for login, input and output
\end{itemize}
\item \underline{terminal} \\ 
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item receives data \dotfill representation processor
\item displays data
\end{itemize}
\item \underline{enquirer} \\
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item requests \dotfill real-estate collection
\item gets required information about real-estates \dotfill real-estate collection
\item returns information \dotfill representation processor
\end{itemize}
\item \underline{recorder} \\ \\
responsibilities \hfill collaboration
\begin{itemize}
\item makes possibility for input available \dotfill represenation processor
\item returns completely collected real-estates \dotfill real-estate collection
\item accepts information about real-estates
\end{itemize}
\end{enumerate}

%\chapter{Use Cases}

\appendix
\chapter{Protocols}
\section{2001-31-October}
\begin{enumerate}
\item Person responsible for protocol \\
\emph{Rescher Robert Harald}
\item Participating persons \\
\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 new classes to refine our application.}
\item Open questions \\
\emph{Is the auction online?} \\
\emph{Is there any restriction?} \\
\emph{Should the user be identified?} \\
\end{enumerate}           
 \\
First of all, the application was built. Therefore, we declared a class named \underline{\bf managing system}, which was our main operating application unit. This unit encapsulates the login managing system as well as the read- and -write-methods to access the database class.\\
The \underline{\bf database} class is the highest level in the hierarchy. It consists of the data pool and the methods to post and enquiry data. The database encapsulates the \(real-estates\), \(users\), \(login-role\) and \(user-rights\). Here are the contents of the classes: \\
\begin{itemize}
\item \underline{\bf real-estates}: This class contains all the necessary entities of the real-estates to be stored.
\item \underline{\bf users}: This class contains all the user information.
\item \underline{\bf login-role}: This class contains the access rights.
\item \underline{\bf user-rights}: This class joins the user class with the login-role class.
\end{itemize}
These classes are part of the database, so they do not need functional routines. For logging in, there will be responsible another class that contains the functional routines, and another one for the user interface. \\
Finally, we constructed a user interface for managing the classes of the database, since the managing system does not distinguish between a user or a further instance of itself when communicating. So, there is a class \underline{\bf user interface}, which calls the methods of the managing system, and is also responsible for the display and input/output to communicate with a human user. The user interface is best described with a \emph{user interface prototype}.



\section{2001-07-November}
\begin{enumerate}
\item Person responsible for protocol \\
\emph{Rescher Robert Harald}
\item Participating persons \\
\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{Restriction on complete object via onion-model.} \\
\emph{Other companies can input an offer.} \\
\emph{Perhaps a special offer: Display offers close to logged in user's area.}
\end{enumerate}
 \\        
The next step will be to refine the user interface. \\
Therefore, we renamed the managing system to \underline{\bf system interface}, since it is better to understand with this terminology. \\
We have to distinguish at least these levels in our problem: The database level containing the real-estates and the one with the entities for user logins. Both these class groups (four class) can be joined by one class which holds the methods for editing and inquirying the data, or one class for the real-estates and one for the classes that contain the users� login information. The second possibility can be used when there is a second system installed in the company that does not distinguish between collaborators and other users. \\
In combination with the login rights are not only the access rights, but also a set of real-estates that are returned when inquirying. So, the class \underline{\bf real-estates} has a property level. The level assigned to the user defined in the user collection must be at least as great as the level defined in the single instances of the real-estates to make them visible to the user. This filtering is done by the \underline{\bf representation processor}, a class that passes the real-estates valuing them by the \underline{\bf user collection}. \\
Since another system can communicate with it, until this point there are only passed data, never a display instruction. A class called \underline{\bf representation processor} formulates the data to a user mask, and passes the inpots done by the user to the higher classes. \\
A further requirement was that there is no local terminal program to be installed. So, the \underline{\bf representation processor} formulates a common format, such as \(hypertext\). In the model appears a class called \underline{\bf terminal} which is not part of our application; it is for example a web-browser that understands hypertext.

%\section{Date}
%Insert information s.a.
%\begin{enumerate}
%\item Person responsible for protocol
%\item Participating persons
%\item Topics talked about
%\item New assignments
%\item Open questions
%\item etc.
%\end{enumerate}


\bibliographystyle{ieeetr}
\addcontentsline{toc}{chapter}{Bibliography}
\bibliography{Paper}
\end{document}
