%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 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,
%%     Oskar Schobesberger, Elisabeth Strobl.
%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass[12pt,fleqn,a4]{report}
\usepackage{geometry}
\usepackage{graphics}
\sloppy
\parindent1cm
\geometry{a4paper,tmargin=2.6cm,bmargin=2.6cm,lmargin=1.6cm,rmargin=1.6cm}

\begin{document}

\begin{titlepage}
\centerline{\today}
\centerline{\large Seminar Software Engineering}
\vspace{2.5cm}
\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{2cm}
\center
    {
Correspondence to: \\
Universit\"{a}t Salzburg \\
Institut f\"{u}r Computerwissenschaften und Systemanalyse \\
Jakob-Haringer-Stra\ss e 2 \\
A-5020 Salzburg \\
Austria
    }

\clearpage
\end{titlepage}


\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{Control Diagrams}
Here we have two kinds of diagrams that show the control flow of our application. On the one hand, there is the
\textit{Sequence Diagram} where we will see exactly the system calls. This means that the sequence diagram also will
unveil how the implementation of the classes and their methods will be. In the \textit{State Diagram} we will see
only the shapes of what the system will do internally, the emphasis lies on the negotiations between user and system.

\section{Sequence Diagram}
First of all, we want to have a view on the sequence diagrams of our \textit{e-Immo}-project.

\subsection{Login}
The login case looks a bit complicated, since there are the instantiations of the user classes. We have a
permanent system interface, whilst login and session are instantiated for each user. The database has its
interfaces instantiated in the declaration of the class \textit{Session}. Each time, a user forces a
session to be opened, the session is instantiated in the main method of the \textit{System Interface}
locally. We need to instantiate the session in any case, even though the login could fail. The reason for
it is that the \textit{Login} does not have instantiations of the database in its class declaration. Hence, it
passes its request to the System Interface, where the session is instantiated. Via an aggregation call, the
System Interface can access the database to fetch the data for login check. The check needs two
entities of the database, namely \textit{Users} and \textit{Access Rights}; the fetch must be
realized by a natural join. In any case, the instance of Login (also locally in the previously mentioned method
of the System Interface) is destroyed. If login fails, also the Session will be destroyed; otherwise,
the session can open.
\includegraphics{seq_login.eps}

\subsection{Enquire Real Estate and bid}
If one has understood, how enquiring and bidding works, the most difficult work for understanding this
system is done. In there, we have al we need in future cases: Read from and write to the
database. In here, we have the only one entity, namely \textit{Real Estates}. All the
things that happen between user and Session is equal to the negotiations in \underline{Login} between
user and System Interface. We do not need the System Interface anymore, it must be eased of work,
because it has to manage all the users that can be logged in simultaneously.
\par Any time, does not matter if submit query or require view of details, the signal is passed from the Terminal to
the Session. The Session-object formulates the request for the database, which might be done in the
language SQL, and calls the Enquirer's only method to fetch the data. The fetched data are
returned to the Representation Processor. This must be done via the interface of the called method in
the Session, otherwise we would break the principle of aggregation. By that time, I want to
remark that every return must be done as the return value of a method due to this.
\par To bid for a real estate runs a bit different. We do not need a return value, and we have to
call the recorder.
 We have a fix step width, so the user does not need to input a step.
\includegraphics{seq_enq.eps}

\subsection{Record Real Estate and User Administration}
To record a real estate is not complicated. It is only a simple transaction. A bit more is to regard
in the case of the \textit{User Administration}. Here we have to call both, the reader and writer. We need the
reader to browse forward and backward; and we need the writer to post the modified data. Here it is not
necessary to show in which way we can alternate users --- we can modify, add and delete a user.
However, there is a cycle, namely present and refresh refers to that cycle. Each time, something has been
done, the sequence needs to restart here.
\includegraphics{seq_rec_user.eps}
\centerline{On the top, we see the Record case, on the bottom there is the User Administration.}

\section{State Diagrams}
Now we want to have a view on the state diagrams. Here it is not very interesting how the application processes
the actions, but which states it runs through. They look like flow diagrams, but in flow diagrams the states are not
important; whilst in state diagrams the actions done on the interfaces are not so important.

\subsection{State Diagrams for \textit{e-Immo}}
Let us have a look on the state diagrams to the project.
\\ \includegraphics{state_login.eps}
\includegraphics{state_query_bid.eps}
The diagram for enquirying and bidding looks rather complicated. We have two exit points. Furtheron we have to regard
that this is only a state diagram. Here it is not interesting if the user can bid at all, but what happens if he bids.
\\ \includegraphics{state_recre.eps}
\includegraphics{state_usad}
\\ For user administration we have to distinguish what the adminstritator does, hence the branches.

\section{Designing the running System}
To design a running system requires some know-how. First of all, we need to know how the control elements are able to
react. This means for example, how a button calls an event-controlled method. Event-controlled methods usually have void returns,
since there is no calling to routine to which it can return a value. Furtheron, the system can be designed when it's clear
hin which direction and when and what for some classes should communicate with each other. We need to regard that in
aggregated objects, the communication can only run upward. When we want to have a communication downward, we need to use tricks.
Another point is that the implementation of a problem usually shows certains patterns that are used again and again,
just in different ways; such patterns are called \textit{Design-Patterns}. These are very helpful because then the program
is easier to understand, when it has consistent ways of solutions to solve the certain subproblems.

\subsection{Our Design}
In \textit{e-Immo}, one of these design-patterns is the solution of how to communicate an agreggation downward.
When instantiating the object that has to call a method downward, we set a pointer (reference) in the created object
to the routine in the lower object. Then, the higher object just needs to derefer the pointer that is part of its attributes.
\\ \includegraphics{diagram1.ps}
\\ \includegraphics{diagram2.ps}
\\ \includegraphics{diagram3.ps}
\par Here are the classes again, with their attributes and methods --- and why...
Only the methods will be explained, since they use the attributes somehow.

\begin{description}
\item[Terminal].
\subitem{present(data): To present data which are translated by the
     Representation Processor on the screen.}

\item[Representation Processor]
\subitem{translate(data, sender): To translate data from the format specifications of the
     System Interface into HTML or any other output data. This class is extended
     by inheritance, but not declared in our system. The data are passed to the
     one (either Terminal or System Interface) which is not sender.}

\item[System Interface]
\subitem{createSession(): Calls the Session's constructor. The sessions
    are instantiated in the attributes of the System Interface, here is an array of sessions declared.}
\subitem{destroySession(): Calls the Session's destructor.}
\subitem{passData(data, sender): Receives data and decides to which object to pass. Receiver is again the one which is not sender.}
\subitem{handlingMask(): Passes the information which mask is demanded to the receiver.}
\subitem{handlingLogout(): Will call destroySession.}

\item[Session]
\subitem{create(): Is the constructor which is called by createSession(). It opens the Session for a user.}
\subitem{destroy(): Is the destructor which is called by destroySession(). It destroys the Session with all of its components.}
\subitem{handlingOK(): With the active control (part of the underlying system), it knows what to
      do when pressing an \textit{Okay}-button during the session.}
\subitem{handlingDB(WhatToDo): Knows how to deal with the database.}

\item[Login]
\subitem{Login(): Knows how to deal with the delivered data. First it
    calls handlingMask, then wait for data from the terminal
    and checks it (calls handlingDB) and then calls the destructor.}

\item[Enquirer]
\subitem{enquirer(): Sends MaskID, knows how to deal with the user's query
         input, checks input and so on.}
\subitem{cancel(): Knows how to deal with the all events caused by \textit{Cancel}-buttons.}
\subitem{OK(): Calls handlingOK derefered}.

\item[Auction]
\subitem{Auction(): Is necessary for request if the user really wants to bid.}
\subitem{OK(): Calls handlingOK derefered with the result to call handlingDB and edit the new prize.}
\subitem{cancel(): Cancels the auction.}

\item[Recorder]
\subitem{recorder(): Sends MaskID, deals with the input, request, checks or wait for input.}

\item[Administration, User and Real Estate Administration]
\subitem{seek(): May deal with the enquirer or leaf through the whole database.}
\end{description}

%% Deployment...

\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{2001-5-December}
\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 User Interface Flow Diagram and its masks.}
\item New assignments \\
\emph{Sequence Diagram, State Diagram, WML and HTML pages.}
\end{enumerate}

\section{2001-12-December}
\begin{enumerate}
\item People responsible for protocol \\
\emph{Rescher Robert, Strobl Elisabeth, Schobesberger Oskar, Fimberger Lucia}
\item Participating people \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Fimberger Lucia, Schobesberger Oskar}
\item New assignments \\
\emph{Designing the running system.}
\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}

