%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Paper of Seminar Software Engineering
%%     Professor Mag.DI. Roland Schwaiger.
%% Created for the
%%     Paris-Lodron-University, Institute of Computer Sciences.
%% By
%%     Lucia Fimberger, Marion Nidetzky, Robert Harald Rescher,
%%     Elisabeth Strobl, Oskar Schobesberger.
%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

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

\usepackage{geometry}
\usepackage{graphics}

%\textheight     680pt
%\textwidth      460pt
%\topmargin      -40pt
%\oddsidemargin    5pt
%\evensidemargin   5pt
\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{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}

\tableofcontents


\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 Progress}
\begin{enumerate}
\item System Requirements
\item CRC Cards
\item Use Cases
\item Essential User Interface Prototyping
\item Class Diagram
\item User Interface Flow Diagram
\end{enumerate}

\chapter{Problem Description} 
\section{System Requirements}
\begin{itemize}
\item Collecting information (in our case real-estate).
\item Possibility to enquire 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}


\chapter{CRC Cards}
\section{Short Introduction into CRC}
Founder are Beck and 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 circularly 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 Rrocessor
\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 submits 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 System Interface
\end{itemize}
\item \underline{Recorder} \\
 \\
responsibilities \hfill collaboration
\begin{itemize}
\item makes possibility for input available \dotfill System Interface
\item passes completely collected real-estates \dotfill Real-Estate Collection
\item accepts information about real-estates
\end{itemize}
\end{enumerate}


\chapter{Use Cases}
\section{What is a Use Case}
A {\em Use-Case} describes a possible application of the system. Therefore, we need to know what the system offers, and what the system can be done with. Furtheron, a use case can be subdived into another or a number of other use cases. This encapsulation is often need to distinguish several possibilities without copying a part of another use case (as we also could see when creating classes).
\section{Each individual Use Case}
First of all, the main use cases, which are to input and enquiry real-estates.
\begin{enumerate}
\item \underline{\bf Record Real Estate} \\
\underline{Description}: User can record (input) a new real-estate. \\
\underline{Precondition}: User is logged in and has the right to record real estates. \\
\underline{Postcondition}: A new real-estate is stored in the system.
\begin{itemize}
\item System presents input-mask.
\item User inputs data and submits them.
\item System verifies data and asks the user to recheck it.
\subitem Okay stores data.
\subitem Cancel: Back to input and submit data.
\end{itemize}

At any time:
\begin{itemize}
\item Cancel: Presents reset choice mask.
\item Logout: Presents login mask.
\end{itemize}

\item \underline{\bf Enquiry Real Estates} \\
\underline{Description}: User can make a query for one or a group of real-estates. \\
\underline{Precondition}: User is logged in. \\
\underline{Postcondition}: User receives data refering to his security level.
\begin{itemize}
\item System presents enquiry mask.
\item User chooses searching criteria from several possibilities.
\item System searches real-estates refering to the query and the security level. The found real-estates are presented the user.
\end{itemize}

At any time:
\begin{itemize}
\item Cancel: Presents reset choice mask.
\item Logout: Presents login mask.
\end{itemize}
\end{enumerate}

These were the main use cases. As one can see, they contain parts which are equal in some cases. On this point, the use cases are subdivided into the sub-use-cases.
\begin{enumerate}
\item \underline{\bf Login} \\
\underline{Description}: Logs in a user. The login also defines the user's security level and access rights. \\
\underline{Precondition}: None. \\
\underline{Postcondition}: User is logged in.
\begin{itemize}
\item System presents login mask.
\item User inputs his identification and password.
\item System verifies his input and logs him in.
\end{itemize}

At any time:
\begin{itemize}
\item Cancel: Presents reset login mask.
\end{itemize}

\item \underline{\bf Action Choice} \\
\underline{Description}: User chooses \(Record\) or \(Enquiry\). \\
\underline{Precondition}: User is logged in and has the right to record data. \\
\underline{Postcondition}: System presents enquiry- or record-mask.
\begin{itemize}
\item System presents this choice mask.
\item User chooses either \(Record\) or \(Enquiry\).
\item System presents the mask in compliance to the user's choice.
\end{itemize}

At any time:
\begin{itemize}
\item Logout: Logs out the user and presents the login mask.
\end{itemize}

\item \underline{\bf Participation at the Auction} \\
\underline{Description}: User has the possibility to take part at the auction and to bid. \\
\underline{Precondition}: User is logged in, has the right security level, has found the enquired real-estate. \\
\underline{Postcondition}: User holds highest offer. \\
\begin{itemize}
\item System displays the details of the enquired real-estate and offers the user the possibility to take part at the auction.
\item User bids.
\item System asks the user to confirm his bid.
\subitem User confirms: System actualizes score and refreshes the display.
\subitem User cancels: System returns to the detailed view of the real-estate.
\end{itemize}

At any time:
\begin{itemize}
\item Cancel: Presents searching results.
\item Logout: Presents login mask.
\end{itemize}
\end{enumerate}

\chapter{Essential User Interface Prototyping}
Here is a rough draft for two versions of the user interfaces. They meet the compliances of the use cases.
The following six "screen-images" are thought to be useful for a HTML version. \\
\medskip
\includegraphics{userifprot1.ps} \\
\includegraphics{userifprot2.ps} \\
\includegraphics{userifprot3.ps} \\
\includegraphics{userifprot4.ps} \\
\includegraphics{userifprot5.ps} \\
\includegraphics{userifprot6.ps} \\

This was the user interface prototype for a HTML Version. We created another
protoype which should be suitable for using the system on a mobile phone.
There are more screens, of course, because the size of a mobile phone display
is expected to be far smaller. \\
\medskip
\includegraphics{handy1.ps} \\
\includegraphics{handy2.ps} \\
\includegraphics{handy3.ps} \\
\includegraphics{handy4.ps} \\

Now we know that the names of the masks, and we can put them into a flow diagram.
First there is a flow diagram for HTML display. \\
\includegraphics{flowdiag.eps} \\

Each input field (the ones with the slant side lines) is a mask from the user interface prototype, which also means that the numbers are equal.
This diagram is drawn in the usual way we learned to draw flow diagrams.
The followin flow diagram (for the mobile version) is quite different, drawn in another
possible way to make user interface flow diagrams, which we found by the
help of the internet. \\
\includegraphics{flowwml.ps} \\

Now we see, where the masks have to be put into. 

\chapter{Class Diagram}
\section{What is a Class Diagram}
The use of a class diagram is to document the static structure of the system, by meaning what classes are given and in what kind of relationship they have. The CRC cards, the essential user interface and the use cases are the basis for the class diagram.
\section{Class Diagram}
\subsection{Description of the Class Diagram}
The Representation Processor knows from the System Interface the Session (e.g. number) and presents the login mask. The classes Login and Session, which is waiting for complet and correct login, are instantiated. The user writes the login, then the System Interface gets these information from the Representation Processor. Further on, the user submits the login and his data are returned to the System Interface, which passes the information to the Session. Then the Session opens.\\
The actions (Auction, Enquiry, record) the user can do depend on his level.\\
\begin{description}
\item[Record] The Session passes the information to the System Interface and further to the Representation Processor to present the record mask. The recorder gets the informationindirectly from the Terminal ans calls the proper method of the Writer by justification.
\item[Enquiry] Like Record, calls the Recorder's method enquiry.
\item[Auction] Makes query. Then it opens a link for auction mask. On justification, Auction calls the Writer to alter the bid-state of the real-estate.
\end{description}
\subsection{Diagram}
\includegraphics{classdiagram.ps}

\chapter{User Interface Flow Diagram}

\appendix
\chapter{Protocols}
\section{2001-31-October}
\begin{enumerate}
\item Person responsible for protocol \\
\emph{Rescher Robert Harald}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky \mbox{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 people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky \mbox{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 inputs 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{2001-14-November}
\begin{enumerate}
\item Person responsible for protocol \\
\emph{Rescher Robert Harald}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky \mbox{Marion}, Fimberger Lucia}
\item Topics talked about \\
\emph{Presentation of the use cases for recording and enqurying data. Furhteron, a draft of the user interface prototype was mentioned.}
\item New assignments \\
\emph{Making an auction.}
\end{enumerate}

\section{2001-21-November}
\begin{enumerate}
\item Person responsible for protocol \\
\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 ``Auction'' and User Interface Prototyping ``Auction''. Presentation of Class diagram: class references, inheritation and instantiation.}
\item New assignments \\
\emph{We should avoid inheritation. \\ Multiple user, solved by instantiation \\ New classes: Auction, Session, Login. \\ User Interface Flow Diagram for WML and HTML and proof of functionality.}
\end{enumerate}

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

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

