\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{\large PS Software Engineering}
%\vspace{0.5cm}
%\hspace{5.2cm}
\centerline{\today}

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

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

\vspace {1cm}
\centerline{\large{Andrea Geierspichler, Roman Gross, Christian Koidl, Michael Pober, Gunnar Ruhs }}
\vspace{0.2cm}
\centerline{andreageierspichler@hotmail.com }
\vspace {1cm}
\centerline{Academic Supervisor Mag. DI Dr. Roland Schwaiger}

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

\vspace{8cm}
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}

\title{\Huge\bf ImmoWarrior}
\author{\large{Andrea Geierspichler, Roman Gross, Christian Koidl,\\ Michael Pober, Gunnar Ruhs}\\
\\
{\small Department of Computer Science}\\
{\small University of Salzburg}\\
{\small A-5020 Salzburg, Austria}\\
\date{}}

%\maketitle

\tableofcontents

\normalsize


%------------------------------------------------------------------------
%----------------------------CHAPTER 1-----------------------------------
%------------------------------------------------------------------------


\chapter{The Project}
To learn the how-to's of ''Software Engineering'' we simulate a real
life situation in the pro-seminar. A client, represented by the
seminar-leader, comes to our software-development-firm and gives
us an assignment. \\
\\
The initial information is: A company that auctions real estate wants
us to develop a software-solution for their process of collecting and
representing information. (Code: ``Immowarrior��).  Potential users of
this system are: the ones, who gather and enter the information and
the ones, who want to read it. Those readers can either be persons, or
other systems. This leads to two different scenarios:
\begin {itemize}
\item {Immowarrior sends the information to an other computer
system by using XML}
\item {Immowarrior displays the information for a person - what
requires us to design an appropriate user-interface.}
\end {itemize}
Specially required by the client is, that the software is to be
easily maintainable and that no one has to install client-software
to be able to use Immowarrior.\\
For the first phase of the project, we ought to concentrate on the
basic-functions of the software, but we should keep the
possibility in mind to add expansions, developed in cooperation
with our group.\\
\\
This is the requirement profile for our project. The given
deadline is the end of January 2002


%------------------------------------------------------------------------
%----------------------------CHAPTER 2-----------------------------------
%------------------------------------------------------------------------


\chapter{A CRC Session} 

\section{What is a CRC-session?}

The CRC-session was invented by Ward Cunningham and Kent Beck in 1989 and then popularised by Rebecca Wirfs-Brock.CRC stands for Class, Responsibility and Collaborator.It is an informal technique for object oriented analysis and design, used for visualising the structure and behaviour of object oriented systems. Basically standard index cards are used to represent classes, responsibilities and colaborabtions with other classes, they are collected on the frontside. On the backside descriptions of the classes and attributes are witten down. A class is an abstraction of something from the problem domain. Responsibilities are tasks that can be ascribed to particular classes and a collaborator is another class that you require to talk to in order to carry out your own responsibilities. The goal is to define and to structure the problem domain and to represent the problem in an object oriented way. \\

\section{Organising a CRC-session}

The number of people is important, too few and it becomes difficult to mentally change gear, too many and you are not all involved and the productivity is cut by more disagreements. Five is the ideal number. If there are more people, one solution is to have the extra people be present strictly as observers. The group should be composed of developers, domain experts and an object oriented faciliator. Try to avoid having an excessivly dominant participant - no bosses either. From the system requirements decide on a simple set of scenarios that you want to try out. \\

\section{Starting the session} 

The first step is to extract classes from the problem domain. One useful tool is to find all the nouns and verbs. The nouns are a good key to what classes are in a system and the verbs show what their responsibilities are. With this information you can start a brainstorming session. Now analyse which classes are important for the project. You do not need to find all classes and responsibilities. The scenario will make them more obvious later on. In a CRC-session subclasses and superclasses are also defined. This can be done at any time it becomes obvious. Attributes of the class do not really have to be defined right now. This will be necessary when you get to the design phase.\\

\section{Defining Use-Cases}

Each person should take the responsibility for being a class. Select a scenario, identify and allocate new classes and responsibilities as the scenario unfoldes. Each person has to focus on their own class. The list of classes will grow and then shrink as the group filters out the good ones. Afterwards try out some speacial scenarious like exceptions. Later on, when getting to the design phase consider folowing things: Target environment, language choice of supporting software components, performance requirements.\\

\section{Perform Use-Case Scenario Testing}

\begin {enumerate}
\item \textbf{Call out a new scenario.} In this phase of the CRC-session the scenario is discussed and described in basic  
\item \textbf{Determine which card should handle the responsibility.} 
\item \textbf{Update the card whenever necessary.} If a card needs to be updated one of two situations has arisen: The responsibility needs to be added to an existing card or a new card needs to be created.
\item \textbf{Describe the processing logic.} Now the bussines logic for the responsibilities should be described step by step and the rules for the system should be recorded. 
\item \textbf{Act out the collaboration between the different classes.}
\end {enumerate}


\section{Advantages of CRC-Modelling}
\begin {enumerate}
\item The analysis is done by people who understand the problem domain (experts)
\item The future-users are actively involved in defining the model for the program. 
\item CRC-modelling can easily be explained to a group of people.
\item The CRC-session leads directly into class-diagramming. 
\end {enumerate}


   
\section{Things you have to keep in mind}

\begin {itemize}
\item {Start with simple scenarios.}
\item {Take the time to select meaningful class names.}
\item {Take the time to write a description of the class.}
\item {If in doubt, act it out!}
\item {Layout the cards on the table to get a feeling for system structure.}
\item {Be prepared to be flexible.}
\end {itemize}


%------------------------------------------------------------------------
%----------------------------CHAPTER 3-----------------------------------
%------------------------------------------------------------------------


\chapter{Our CRC Cards}

This is the latest version of the cards we have developed during the course.\\
\\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Admin}}\\
\hline
Responsibilities & Collaborators\\
\hline
access user interface & user interface\\
view free offers & \\
log in & \\
configurate account & \\
create/modify account &\\
search for real estate &\\
view real estate info &\\
place/edit/delete real estate &\\
log off &\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{EditorAndUser}}\\
\hline
Responsibilities & Collaborators\\
\hline
access user interface & user interface\\
view free offers & \\
log in & \\
configurate account & \\
search for real estate &\\
view real estate info &\\
place/edit/delete real estate &\\
log off &\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Editor}}\\
\hline
Responsibilities & Collaborators\\
\hline
access user interface & user interface\\
view free offers & \\
log in & \\
configurate account & \\
place/edit/delete real estate &\\
log off &\\
\hline
\end{tabular}\\ \\

 
\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{User}}\\
\hline
Responsibilities & Collaborators\\
\hline
access user interface & user interface\\
view free offers & \\
log in & \\
configurate account & \\
search for real estate &\\
view real estate info &\\
log off &\\
\hline
\end{tabular}\\ \\
 
\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Guest}}\\
\hline
Responsibilities & Collaborators\\
\hline
access user interface & user interface\\
view free offers &\\
request new read account&\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{User Interface}}\\
\hline
Responsibilities & Collaborators\\
\hline
read input & guest\\
forward data & user\\
show info & editor\\
start session & editoranduser\\
& admin\\
& session\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Session}}\\
\hline
Responsibilities & Collaborators\\
\hline
create/modify/delete account & user interface\\
initiate sending of account info & account\\
forwards data to user interface & send account info\\
initiate search & search for info\\
send real estate info & send real estate info\\
close session & info storage \\
access info storage &\\
request account info &\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Account}}\\
\hline
Responsibilities & Collaborators\\
\hline
access info storage & session\\
modify account info & info storage\\
forward account info& \\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Information Storage}}\\
\hline
Responsibilities & Collaborators\\
\hline
store account info & session\\
store real estate info & account\\
forward data & search for info\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Search For Info}}\\
\hline
Responsibilities & Collaborators\\
\hline
perform search & info storage\\
forward search results & session\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Send Account Info}}\\
\hline
Responsibilities & Collaborators\\
\hline
send username to e-mail/cell phone & account\\
send password to e-mail/cell phone & session\\
send account privileges to e-mail/cell phone &\\
\hline
\end{tabular}\\ \\

\begin{tabular}{|p{200pt}|p{200pt}|}
\hline
\multicolumn{2}{|l|}{Classname: \textbf{Send Real Estate Info}}\\
\hline
Responsibilities & Collaborators\\
\hline
send info to e-mail/cell phone & session\\
look up account info & account\\
\hline
\end{tabular}

%------------------------------------------------------------------------
%----------------------------CHAPTER 4-----------------------------------
%------------------------------------------------------------------------

\chapter{Essential Use Cases}
\begin{center}
\includegraphics[width=12cm]{general_overview.eps}
\end{center}

This general overview shows the main use cases and actors of ImmoWarrior.\\
Five different actors can interact with the system:
\begin{itemize}
\item \textbf{guest}: The guest may view the free offers and request a read account.
\item \textbf{user}: The user may view all offers and has all the guest's privileges.
\item \textbf{editor}: The editor may place real estate offers in the system and has all the guest's privileges.
\item \textbf{user/editor}: The user/editor has the same privileges as the user and additionally the editor's privileges.
\item \textbf{admin}: The admin has all the privileges of the other actors and additionally the write account management privilege.
\end{itemize}


\begin{center}
\includegraphics[width=16cm]{offerplacing.eps}
\end{center}

\newpage
\begin{center}
\large{view free offers / create read account / view all offers}
\end{center}

\begin{center}
\includegraphics[width=15cm]{createaccount_christian.eps}
\end{center}

\newpage
\begin{center}
\large{create/change account}\\
\end{center}

\begin{center}
\includegraphics[width=15cm]{createaccount_gunnar.eps}
\end{center}

\begin{center}
\includegraphics[width=13cm]{manageaccount.eps}
\end{center}

%------------------------------------------------------------------------
%----------------------------CHAPTER 5-----------------------------------
%------------------------------------------------------------------------

\chapter{Essential User Interface}

\begin{center}
\Large{\textbf{OVERVIEW: User Interface}}
\end{center}

\begin{center}
\includegraphics[width=16cm]{ui-overview.eps}
\end{center}

\begin{center}
\includegraphics[width=12cm]{uihomepage.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{ui_create_read_account.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{ui_create_account_change_privileges.eps}
\end{center}

\begin{center}
\includegraphics[width=12cm]{all_offers.eps}
\end{center}

\begin{center}
\includegraphics[width=12cm]{offer_placing_andrea.eps}
\end{center}


%------------------------------------------------------------------------
%----------------------------CHAPTER 6-----------------------------------
%------------------------------------------------------------------------

\chapter{Class Diagrams}

In the previous chapters we dealt with the conceptual model of our system. Now we are going to start with the object oriented analysis.
We have to transform the CRC-Model into object-oriented class-diagrams. Therefore the CRC-Cards become Classes, a new class for each Card. A class contains attributes and essential methods. Furthermore there are different relations between the classes: one to one, on to many, many to many (many may also mean zero).
Inheritance is also a point of interest. Thus attributes and methods of one class are forwarded to another one - the child-class -, which can also have additional attributes and methods.\\

\begin{center}
\includegraphics[width=16cm]{cd_overview.eps}
\end{center}

\begin{center}
\includegraphics[width=12cm]{cd_ui.eps}
\end{center}


\begin{center}
\includegraphics[width=18cm]{cd_account.eps}
\end{center}


\begin{center}
\includegraphics[width=18cm]{cd_real_estate.eps}
\end{center}


\begin{center}
\includegraphics[width=12cm]{cd_session.eps}
\end{center}

\begin{center}
\includegraphics[width=10cm]{cd_database.eps}
\end{center}


%------------------------------------------------------------------------
%----------------------------CHAPTER 6-----------------------------------
%------------------------------------------------------------------------

\chapter{User-Interface Prototyping}

On the basis of the user-interface design we had developed during our previous session with the customer we created a corresponding prototype using HTML (Hypertext Markup Language) and WML (Wireless Markup Language). The purpose of user-interface prototyping is to test out in reality if the conceptual model works. Therefore we have to check if for every use-case a corresponding set of user-interface-sites exist. Another important point is to verify all the sites are interlinked and no unexpected dead ends exist.\\
The flow-diagram of the HTML and WML versions can be found on the succeeding pages.
The prototypes of the Immowarrior user-interface can be found at the following locations: 
\begin {itemize}
  \item HTML version: http://www.cosy.sbg.ac.at/ TILDE mpober/se1/se\_html/
  \item WML version:  http://immowarrior.wap3.de/
\end {itemize}

\begin{center}
\includegraphics[width=16cm]{ui_flow_diagram.eps}
\end{center}

\newpage
\begin{center}
\includegraphics[width=16cm]{ui_flow_diagram_wml.eps}
\end{center}


%------------------------------------------------------------------------
%----------------------------CHAPTER 7-----------------------------------
%------------------------------------------------------------------------

\chapter{Sequence Diagram}

\section{What is a Squence Diagram?}
A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the objects participating in the interaction by their ``lifelines''. It does not show the associations among the objects. The sequence diagram represents an Interaction, which is a set of messages exchanged among objects within a collaboration to effect a desired operation or result.\\
A sequence diagram has two dimensions: the vertical dimension represents time, the horizontal dimension represents different objects. Normally time proceeds down the page. Usually only time sequences are important but in real-time applications, the time axis could be an actual metric. There is no significance to the horizontal ordering of the objects.\\

\section{Modeling a Sequence Diagram}
An objects in a sequence diagram is represented by a rectangle. The objects role is shown as a vertical dashed line called the ``lifeline''. This lifeline represents the existence of the object at a particular time. If the object is created or destroyed during the period of time shown on the diagram, then its lifeline starts or stops at the appropriate point; otherwise it goes from the top to the bottom of the diagram.\\
A message is a communication between objects that conveys information with the expectation that action will ensue. The receipt of a message is a kind of event. A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object. In case of a message from an object to itself, the arrow may start and finish on the same object symbol. The arrow is labeled with the name of the message and its argument values. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are useful on the diagrams for identifying concurrent threads of control.\\

\section{When to use a Sequence Diagram}
A good design can have lots of small methodes in different classes. Because of this it can be difficult to figure out the overall sequence of behavior. This diagram is simple and visually logical, so it easy to see the sequence of the flow of control. The diagram also clearly shows concurrent processes and activations. 


%------------------------------------------------------------------------
%----------------------------CHAPTER 8-----------------------------------
%------------------------------------------------------------------------

\section{Our Sequence Diagrams} 

\begin{center}
\includegraphics[width=16cm]{sd_administration.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{sd_become_member.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{sd_insert_new_re.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{sd_login.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{sd_manage_your_account.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{sd_search_for_re.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{sd_visit_hp_view_free_offers.eps}
\end{center}


%------------------------------------------------------------------------
%----------------------------CHAPTER 9-----------------------------------
%------------------------------------------------------------------------

\chapter{Activity Diagram} 
\section{What is an Activity Diagram?}
Activity diagrams describe the workflow behavior of a system. The diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. An activity is trigged by one or more events and activity may result in one or more events that may trigger other activity or processes.\\ 
Typically an activity diagram is attached to the implementation of an use case. The purpose of this diagram is to focus on flows driven by internal processing (as opposed to external events)\\

\section{Modeling an Activity Diagram}
Basic elemtents for creating an anctivity diagram: 
\begin {description}
        \item[Action State:] Action states represent the noninterruptible actions of objects. Typically an action state is represented by an rectangle with convex arcs as sides.
        \item[Action Flow:] Action flow arrows illustrate the relationships among action states.
        \item[Object Flow:] Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object. 
        \item[Initial State:] A filled circle followed by an arrow represents the initial action state.
        \item[Final State:] An arrow pointing to a filled circle nested inside another circle represents the final action state.
        \item[Branching:] A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard expression. You can also label one of the paths "else."
        \item[Swimlanes:] The activity diagram may be divided visually into ''swimlanes'' each separated from neighboring swimlanes by vertical solid lines on both sides. Swimlanes are used to group related activities into one column. 
\end {description}

\section{When to use an Activity Diagram}
Activity diagrams are used for documenting existing process, analyzing new Process Concepts, identifying and finding reengineering opportunities. They are mostly used to show parallel behavior between the different events and activities. Activity diagrams are also used to document decisions and iterations. From the software engineering perspective they can be used to analyze requirements of the use cases befor modeling and assigning methods. 


%------------------------------------------------------------------------
%----------------------------CHAPTER 10----------------------------------
%------------------------------------------------------------------------

\section{Our Activity Diagrams} 

\begin{center}
\includegraphics[width=8cm]{ad_administration.eps}
\end{center}

\begin{center}
\includegraphics[width=15cm]{ad_createaccount.eps}
\end{center}

\begin{center}
\includegraphics[width=11cm]{ad_editrealestate.eps}
\end{center}

\begin{center}
\includegraphics[width=50cm]{ad_freeoffers.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{ad_insertnewrealestate.eps}
\end{center}

\begin{center}
\includegraphics[width=12cm]{ad_login.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{ad_manageaccount.eps}
\end{center}

\begin{center}
\includegraphics[width=12cm]{ad_searchrealestate.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{ad_wap.eps}
\end{center}

%------------------------------------------------------------------------
%----------------------------Chapter11-----------------------------------
%------------------------------------------------------------------------
\chapter {Design Class Diagram}
\section {What is a Design Class Diagram}
Activity and Sequence Diagrams are the end of the analysis phase. Now we switch from analysis to design phase. The first thing to do is to create a design class diagram.\\
The goal of a Design Class Diagramm is to model the static appearance of the system. Unlike the analysis in which we concentrated on the problem domain, we focus on the solution domain. Changes are now caused by different implementation technologies. In this diagram the classes and their attributes and methods are shown. Additionally the visibilities (public +, protected \#, private -), names, paramters and return values of methods as well as visibilities, names and types of attributes are listed.

\section {Our Design Class Diagram}

\begin{center}
\includegraphics[width=16cm]{design_class_overview.eps}
\end{center}

\begin{center}
\includegraphics[width=18cm]{cm_account_info.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{new_class_diagram_session.eps}
\end{center}

\begin{center}
\includegraphics[width=8cm]{new_class_diagram_ui_controller.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{real_estate_controller_methods.eps}
\end{center}

\begin{center}
\includegraphics[width=12cm]{real_estate_database_methods.eps}
\end{center}

\begin{center}
\includegraphics[width=16cm]{real_estate_info_methods.eps}
\end{center}


%%%%%%%%%%%
%               CHAPTER 12
%

\chapter{Component Diagram}

\section{ What is a Component Diagram}

Component Diagrams show software components and the dependencies between them. The components can exist during compilation, linking or execution. Component Diagrams show the components just as types, not as instances. Component instances are visualized in the deployment diagram. Components are modeled as rectangles with two smaller rectangles jutting out from the left hand side and the name of the component written in the rectangle. Components implement one or more interfaces, modeled using a line with a circle at the end and the name of the interface beside the symbol. Components have dependencies on the interfaces of other components, modeled using the standard UML dependency notation, as seen in our component diagrams.
\section{Our Component Diagrams}
\begin{center}
\includegraphics[width=13cm]{komponent_diagramms1.eps}
\end{center}

\begin{center}
\includegraphics[width=13cm]{komponent_diagramms2.eps}
\end{center}
\newpage
\begin{center}
\includegraphics[width=13cm]{komponent_diagramms3.eps}
\end{center}

\chapter{Deployment Diagram}

\section{What is a Deployment Diagram?}

It shows the configuration of software-components, objects and processes at runtime. A deployment diagram is an important
illustration of the topology of the system (hardware and software combined). By inspecting a single node (i.e. hardware unit) of
the diagram, one can see, what components of the software system are running on it, and of which logical units (classes,
objects,...) these component consist.

\section{Modeling a Deployment Diagram}

This diagram is a graph of nodes, connected by associations showing the communication between them. Nodes may contain
representations of components, meaning, that the corresponding software-components are running on this specific hardware-unit. The
components are interlinked with others by dependencies (dashed arrows in the diagram) and possibly via interfaces. Stereotypes can
be used to describe the kind of dependance (e.g. $\ll$supports$\gg$, $\ll$uses$\gg$,...).
\section{Our Deployment Diagrams}

As you can see in the following diagram our system is based on a \textbf{layered architecture}:
\begin{center}
\includegraphics[width=12cm]{deployment.eps}
\end{center}



%------------------------------------------------------------------------
%----------------------------APPENDIX------------------------------------
%------------------------------------------------------------------------


\appendix
\chapter{Protocolls}


\section{1$^{st}$ Lesson - October, 25$^{th}$, 2001}
Basical information about the course and division into groups.


\section{2$^{nd}$ Lesson - October, 31$^{st}$, 2001}
First meeting with the client and CRC-session.
\begin{enumerate}
\item Groupleader: Christian Koidl
\item Participating Groupmembers: Andrea Geierspichler, Gunnar Ruhs, Roman Gross, Michael Pober
\item Topics talked about: Analysis of the problem and basic class-definition
\item Results:
  \begin {enumerate}
  \item The client wants the possibility to obtain relevant information on offers via the internet or the mobile phone.
  \item The information should be sent to the customer either automatically by the system (push) or on individual request (pull).
  \item Clients as banks, authorities and private persons get only one account.
  \item The system should provide an access-control-system.
  \item Private persons receive their username/password by e-mail. 
  \item Private persons have to pay provision for publishing their information
  \item There should be the possibility to include different multimedia-elements (pictures, movies, sounds,...).
  \end {enumerate}
\item List of possible classes: Session, User Interface, Account, Permission, Information Storage, Real Estate, Editor, Private Person, Prospective Buyer
\item New assignments: Refining the problem-statement. Discuss and act out possible use-cases. Think about the user-interface. 
\item Open questions: 
  \begin {enumerate}
  \item Should permanent accounts be available for privat persons?
  \item Do private persons have to pay a fee although the object is not sold?
  \item Is it necessary to have an account to request information?
  \end {enumerate}
\end{enumerate}


\section{3$^{rd}$ Lesson - November, 7$^{th}$, 2001}
\begin{enumerate}
\item Groupleader: Andrea Geierspichler 
\item Participating Groupmembers: Christian Koidl, Gunnar Ruhs, Roman Gross, Michael Pober
\item Topics talked about: Essential Use-Case-Definition, Essential User-Interface-Modeling 
\item Use-Cases discussed: 
  \begin {enumerate}
  \item Offer-Placing \\
    Actions: Login - Offer-Placing - Logoff\\
    Actors: Editor \\
    Details: The editor contacts the user-interface. The interface forwards the login-inputs to the accout, that checks in the information-storage, if the account exists. When positiv it sends the data to the privilege. The Privilege gets the user-permissions from the information-storage and returns it to the account. Then the account passes the results to the user-interface. If the user is accepted, then the interface starts a session and displays the next screen. Now the user chooses the offer-placing-menu. Here he enters his real-estate data. The interface reads the information and forwards it to the session, that stores it in the information-storage. The storage sends a success message to the user-interface over the session. The interface displays the success message and returns to the menu-screen. The user hits the logout-button and the interface closes the session and shows the login-screen again.       
  \item Create Account \\
    Actions: Viewing free offers - Create Account - Send Account-Information\\
    Actor: User\\
    Details: The User visits the Homepage. The homepage starts a session, that querries the information-storage for the free offers. The storage returns this informations via the session to the homepage and the session is closed. Now the user wants to see more details, so he enters the "create account" menu. Here a session is started and the user is offered a form, where he enters his personal information. The session gets this data and forwards it to the information-storage. Then it activates send-account-information. From here the user gets informed about his username and password. Finally the session querries for the free offers, returns them to the homepage and closes. The free-offers-screen is displayed again.    
  \end {enumerate}
\item Essential user interface:\\
Homepage, subscribe screen, subscription successful, subscription error, login screen, access denied, form for placing offers, infoscreen successful, infoscreen error,
\item List of possible classes: Session, User Interface, Account, Privilege, Information Storage, Real Estate, Editor, Private Person, User, Send Account Information
\item New assignments: Present the essential use-cases and the essential user-interface using slides. 
\item Open questions: 
  \begin {enumerate}
  \item How is a user able to manage his account?
  \item Is "Privileges" necessary?
 \end {enumerate}
\end{enumerate}



\section{4$^{th}$ Lesson - November, 14$^{th}$, 2001}
\begin{enumerate}
  \item Groupleader: Gunnar Ruhs
  \item Participating Groupmembers: Christian Koidl, Andrea Geierspichler, Roman Gross, Michael Pober
  \item Topics talked about: Presentation of the Essential Use-Cases and a basic design for the User-Interface. (For details, please refer to chapter 4)
  \item Results: 
    \begin{enumerate}
      \item The different actors are to be disigned hierachically. Going out from the Guest-Actor, the other persons can be constructed by inheritance. 
      \item We have to add a new class "System" to our list. This represents a foreign system, that tries to interact with our software.
    \end{enumerate} 
  \item List of possible classes: Session, User Interface, Account, Information Storage, Admin, Editor, EditorAndUser, User, Guest, Send Account Info, Search for Info, Push Real-Estate-Info, System
  \item New assignments: Present the class-strucure of the project with slides.  
  \item Open questions: so far: none
\end{enumerate}



\section{5$^{th}$ Lesson - November, 21$^{th}$, 2001}
\begin{enumerate}
  \item Groupleader: Roman Gross
  \item Participating Groupmembers: Christian Koidl, Andrea Geierspichler, Gunnar Ruhs, Michael Pober
  \item Topics talked about: Presentation of the Classdiagrams
    \item Results: 
    \begin{enumerate}
      \item Cardinalities have to be inserted into the class-diagrams 
      \item The attributes "Privileges" and "Address" are to modeled as own classes
      \item The layout for the user-interface can be put into a class, so that all the different sites can be objects of "layout" 
    \end{enumerate} 
  \item New assignments: Build a user-interface prototype for mobile phone using WML (Wireless Markup Language) and for the internet using HTML. 
  \item Open questions: so far: none
\end{enumerate}



\section{6$^{th}$ Lesson - December, 5$^{th}$, 2001}
\begin{enumerate}
  \item Groupleader: Michael Pober
  \item Participating Groupmembers: Christian Koidl, Andrea Geierspichler, Gunnar Ruhs, Roman Gross
  \item Topics talked about: Presentation of the User-Interface-Prototype (WML and HTML)
  \item Results:
  \begin {enumerate}
    \item The possibility to check the user's resolution and then show an optimized user interface for his special requirements should be given.
    \item An extendable permission-system should be considered.
    \item A user should be able to view his own placed real estates, even he just has write-permissions.
    \item If a visitor wants to search for real estates via WAP, his entered search criterias should be listed in each card.
  \end {enumerate}
  \item New assignments: Create sequence diagram and activity diagram
  \item Open questions: so far: none
\end{enumerate}



\section{7$^{th}$ Lesson - December, 12$^{th}$, 2001}
\begin{enumerate}
  \item Groupleader: Christian Koidl
  \item Participating Groupmembers: Michael Pober, Andrea Geierspichler, Gunnar Ruhs, Roman Gross
  \item Topics talked about: Presentation of the activity diagrams and sequence diagrams
  \item Results:
  \begin {enumerate}
    \item The flow diagram has to be created from the users point of view only.
    \item Descriptions of the events have to be added to the left side of the sequence diagrams.
  \end {enumerate}
  \item Open questions: so far: none
\end{enumerate}



\section{8$^{th}$ Lesson - January, $9^{th}$, 2002}
\begin{enumerate}
  \item This meeting did not take place so we will talk about the topics planned for that meeting in the next week.
\end{enumerate}

\section{9$^{th}$ Lesson - January, $16^{th}$, 2002}
\begin{enumerate}
  \item Groupleader: Andrea Geierspichler
  \item Participating Groupmembers: Michael Pober, Roman Gross, Christian Koidl, Gunnar Ruhs
  \item Topcs talked about: Presentation of out Component Diagrams and Deployment Diagrams
  \item Results:
  \begin{enumerate}
    \item One thing that had to be changed in the Deployment Diagram: The direct connection between the UI\_Controller and the Real\_Estate\_Info/Account\_Info as well as the connection between Session and Real\_Estate\_Info/Account\_Info is not necessary.
    \item For security reasons the attributes in the ADDRESS-Class have to be private and the corresponding methods have to be inserted.
    \item Our Search-Methods were working with search strings not unlike those used in CGI but we should use hash tables instead.
    \item We have to extend our CONNECTION-Class. It should theoretically be possible to enter an indefinite number of contact information. Therefore we have to create a "list" for the phone-numbers, etc.
    \item We should to split up the PRIVILEGE-Class into a list of classes, one for every single privilege. Thereby the system is extendable more easily.
  \end{enumerate}
\end{enumerate}



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