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

\textheight	690pt
\textwidth	480pt
\topmargin	-50pt
\oddsidemargin	  4pt
\parindent	  0pt

\pagestyle{headings}

\begin{document}
\begin{titlepage}
\centerline{\today}
\centerline{\large  Seminar Software Engineering}


\vspace{2cm}
\centerline{\Large\textbf{Title}}
\vspace{0.5cm}
\centerline{\Huge\textbf{ImmoWarrior}}

\vspace{1cm}
\centerline{\textbf{Report}}
\centerline{\textbf{Individual-Paper}}

\vspace {1cm}
\centerline{\large Lucia Fimberger}
\vspace{0.2cm}
\centerline{lfimberg@cosy.sbg.ac.a}
\vspace {1cm}
\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{7cm}
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{\Large\textbf{ImmoWarrior} }

\author{{\large Lucia Fimberger}\\
{\small Department of Computer Science} \\
{\small University of Salzburg} \\
{\small A--5020 Salzburg, Austria} \\
{\small lfimberg@cosy.sbg.ac.at}}

\date{}

\maketitle


\tableofcontents


%%%%%%%%%%%%%%%%%%%%%%%%%% CHAPTER %%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Introduction}
%%%%% SECTION %%%%%%%
\section{Terms of Reference}
A real-estate auction company (\(e-Immo\)) needs a new software for processing the acquisition of information and for the representation of this information by means of in support of electronic data processing (\(ImmoWarrior\)). These processes should be simple. \\
Potential users of the system are of course the collector of the information and the inquirer, who can be a person or a another system. \\
Resulting from this, there are two different scenarios:
\begin{itemize}
\item The collected information is passed on another system by ImmoWarrior. (XML)
\item On condition that the collected inforamtion is passed on people by ImmoWarrior, there has to be an appropriate processing of the data.
\end{itemize}
A special requirement on the system is that ImmoWarrior should be easy to service, by meaning, it should not be necessary to install the components local. \\
Furtheron, \(e-Immo\) should have the possibility to influence the data processing for individuals.  
%%%%% SECTION %%%%%%%
\section{Project Development Progress}
Points are listed in order of the homeworks.
\begin{enumerate}
\item CRC Cards
\item Use Cases
\item Essential User Interface Prototyping
\item Class Diagram
\item User Interface Flow Diagram and HTML and WML Prototypes (was group work)
\item Activity Diagram
\item Sequence Diagram
\end{enumerate}
%%%%% SECTION %%%%%%%
\section{System Requirements}
Following points have to be bear in mind:
\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}

%%%%% SECTION %%%%%%%
\section{Book}
P. Stevens and R. Pooley: \\
UML Softwareentwicklung mit Objekten und Komponenten \\
Addison-Wesley

%%%%%%%%%%%%%%%%%%%%%%%%%% CHAPTER %%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{CRC Cards} 
%%%%% SECTION %%%%%%%
\section{Basics on CRC Cards}
CRC means Class-Responsibility-Collaboration. (invented by Beck and Cunningham 1989). \\
Although CRC cards are not part of UML, they are used in an early stage of software development to identify classes and their assoziations. CRC Cards are a technique for helping create a better object model for an object-oriented system.
%%%
\subsection{Creating CRC Cards}
A CRC card contains:
\begin{description}
\item[Name] of the class (at the top)
\item[Responsibilities] of the class (on the left side)
\item[Collaborators] of the class, which support the execution of the responsibilities (on the right side)
\end{description}
The general idea is looking through the requirements for all the nouns that play a part in the functionality. These nouns become the classes. \\
Responsibilities identify problems to be solved.  A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise is the design.  One class, normally, should not has more than three or four responsibilities. Are there to much responsibilities, it should be thought of subdividing the class. \\
One of the distinguishing features of object design is that all objects stand in relationship to others, on whom they rely for services and control. At least, for characterizing object designs: the collaborators of an object. Collaborators are objects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. 
\paragraph{Finding Classes}
Read through the requirements and use cases looking for nouns and noun phrases. Make a list of these, changing the plurals to singulars, then throw out all words and phrases that are obviously nonsense. While doing this, convert all the passive sentences to active sentences. Also, convert all pronouns (I, it, he, they, etc.) to the noun that they stand for. \\
Be careful with adjectives - they may be irrelevant, or they may indicate different behaviors, and therefore potentially different subclasses.
\paragraph{Finding Responsibilities}
Responsibilities of an object include both the knowledge it maintains and the actions it can perform. When considering responsibilities, remember that they are the publicly available services, and that they specify what the object does, not how it does it.
\paragraph{Finding Collaborations}
By assigning responsibilities, consider if the class is capable of fulfilling the responsibility by itself. If not, what help does it need from other classes? These other classes will become collaborators.
%%%
\subsection{CRC Session}
The members of a CRC session are a project leader, facilitator and some colloborators. The goal of a CRC session is the discussion of the problems of the system. Furtheron, it is a quite good possibility to increase the team spirit.

%%%%% SECTION %%%%%%%
\section{CRC Cards for ImmoWarrior}
This is the first very rough draft of the CRC Cards:

\vspace{1cm}
\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Real-Estate} \\ \hline \hline
knows its characteristics &  \\ 
(kind, objectname, size, address, age, & \\
status, ... & \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Client} \\ \hline \hline
knows its characteristics &  \\ 
(name, address, ...) & \\ \hline
can search Real-Estates & Search \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Auction} \\ \hline \hline
knows Real-Estates & Real-Estates \\ \hline
handels bid & \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Searching} \\ \hline \hline
searches Real-Estates & Real-Estates \\ \hline
returns results & \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Input Data} \\ \hline \hline
handels input of Real-Estates & Real-Estates \\ \hline
handels input of Clients & Client\\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Seller} \\ \hline \hline
knows his Real-Estates & Real-Estates \\ \hline
can input data & Input data \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

Second draft: \\ \\

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Real-Esate} \\ \hline \hline
knows its characteristics & \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Collection of Real-Estates} \\ \hline \hline
knows Real-Estates & Real-Estates \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{User} \\ \hline \hline
knows its characteristics & \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Collection of Users} \\ \hline \hline
knows Users & User \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Enquirer} \\ \hline \hline
recieves searching criteria & Data Converter \\ \hline
searches  & Collection of Real-Estate  \\ \hline
transmits results & Data Converter \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Data Converter} \\ \hline \hline
recieves and transmits data & Terminal, Enquirer \\ \hline
formats data  &  \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Terminal} \\ \hline \hline
recievs and displays data & Data Converter \\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

\begin{tabular}{|l|l|} \hline
\multicolumn{2}{|c|}{Recorder} \\ \hline \hline
recieves data & Data Converter \\ \hline
can input data & Collection of Real-Estates\\ \hline
\end{tabular}
\hspace{1cm} \vspace{0.5cm}

%%%%%%%%%%%%%%%%%%%%%%%%%% CHAPTER %%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Use Case}
%%%%% SECTION %%%%%%%
\section{Basics of Use Cases}
Use Cases are a critical technique in developing an application. Within the UML Use Cases are used primarily to capture the high level user-functional requirements of a system. This long winded description is important because Use Cases cannot usefully be used to capture non-functional requirements. Nor can they usefully be used to capture "internal" functional requirements. Attempting either or both is a sure path to disaster for two reasons. Firstly because Use Cases are an informal and imprecise modelling technique. But then they were never intended to be anything else. Secondly because the other use that we make of Use Cases is to define the fundamental structure of our application. The Use Case is not only important as a unit of requirement definition but also as our unit of estimation and our unit of work. \\
The Use Case model is about describing WHAT our system will do at a high-level and with a user focus for the purpose of scoping the project and giving the application some structure. The Use Cases are the unit of estimation and also the smallest unit of delivery. Each increment that is planned and delivered is described in terms of the Use Cases that will be delivered in that increment. \\
Use Cases are not a functional decomposition model. Use Cases are not intended to capture all of the system requirements. Use Cases do not capture HOW the system will do anything - nor do they capture anything the actor does that does not involve the system. All of these things are better modelled using other modelling techniques that were developed for those purposes. The Object Model to capture the static structure of the system and the composition of the classes. Object Sequence Diagrams and State Transition Diagrams to capture the detailed dynamic behaviour of the system - the HOW. The Business Process Model to capture the overall business processes - both computerised and manual. \\
Use Cases are not an inherently object-oriented modelling technique. There is no fundamental reason why they couldn't be used as the front-end to a structured development method - but they're not because the methods gurus are concentrating on the development of OO methods. \\
\paragraph{Elements of Use Case}
An actor, who is described by a matchstick man, stands for the user of the system. The actor is connected to an use case (by a line) if he is allowed to interact with the system to assist by the execution of the jobs. Pay attention to two things:
\begin{enumerate}
\item The actor is not an individual person, but a role, which someone is playing.
\item The communication relation between the actor and an Use Case do not mean, that someone, in that role, assists realla by the execution of the jobs. It means actually, that the possibility is given.
\end{enumerate}

%%%%% SECTION %%%%%%%
\section{Use Cases of ImmoWarrior}

The following points describe Fig. \ref{uc}.
%%%
\subsection{Record}
\begin{description}
\item[Description] User can input a new real-estate.
\item[Precondition] 
\item[Postcondition] A new real-estate is stored in the datacollection.
\end{description}
\begin{tabular}{c l l}
 & user & system \\ \hline
1. & & presents the input mask \\
2. & inputs data of real-estate and submits & \\
3. & & verifies data and ask for a recheck \\
4. & okay & stores data \\
   & cancel & rejects data, goes to point 1 \\ \\
\end{tabular}
%%%
\subsection{Enquiry Real-Estates}
\begin{description}
\item[Description] User can search real-estates with help of different searching criteria.
\item[Precondition] 
\item[Postcondition] User gets the searching results.
\end{description}
\begin{tabular}{c l l}
   & user & system \\ \hline
1. & & presents enquiry mask \\
2. & chooses different serching & \\
   & criteria and submits & \\
3. & & searches real-estates refering to  \\
   & & searching criteria and  \\
   & & presents results to user \\ \\
\end{tabular}
%%%
\subsection{Participate an Auction}
\begin{description}
\item[Description] User can bid.
\item[Precondition] User has found his favorite real-estate.
\item[Postcondition] User holds highest bid.
\end{description}
\begin{tabular}{c l l}
   & user & system \\ \hline
1. & & presents details of choosen real-estate \\
2. & bids & \\
3. & & ask to submit \\
4. & okay & actualizes data of real-estate \\
   & cancel & back to point 1 \\ \\
\end{tabular}

\begin{center}
\begin{figure}[!h]
\includegraphics[width=8cm]{lfusecase}
\caption{Use Case Diagram of ImmoWarrior}
\label{uc}
\end{figure}
\end{center}

%%%%%%%%%%%%%%%%%%%%%%%%%% CHAPTER %%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Essential User Interface Prototyping}

This is only a rough draft: \\

\begin{tabular}{|l |l l|} 
\multicolumn{2}{l}{Start} \\ \hline
Buttons:  & Text: & Welcome and a short description of the company \\ 
News & \\
Search for Real-Esates & & \\
Go to Auction & & \\ 
Contact & & \\ \hline
\end{tabular} 
\\ \vspace{0.5cm}

News \\
\begin{tabular}{|l|} \hline
The latest inputed Real-Estates are displayed. \\ \hline
\end{tabular} 
\\ \vspace{0.5cm}

\begin{tabular}{|l l|} 
\multicolumn{2}{l}{Search} \\ \hline
Text: & Howto's for searching \\ 
Criteria & Kategory, size, location, prize, age, number of rooms, ... \\ \hline
\end{tabular} 
\\ \vspace{0.5cm}

Searching Results \\
\begin{tabular}{|l|}  \hline
Displays searching results \\ 
Buttons: For Details \\
Buttons: Back \\ \hline
\end{tabular} 
\\ \vspace{0.5cm}

Details \\
\begin{tabular}{|l|}  \hline
Displays Details of required Real-Estate \\ 
Buttons: Back \\ \hline
\end{tabular} 
\\ \vspace{0.5cm}

Contact \\
\begin{tabular}{|l|}  \hline
For sending an E-Mail. \\
Subjectm, text, sender \\ \hline
\end{tabular} 
\\ \vspace{0.5cm}

Record Real-Estate \\
\begin{tabular}{|l|}  \hline
Edit fields: Of real-estate attributes (Name, Size, Prize,...) \\
Buttons:  Ok, Back \\ \hline
\end{tabular}
\\ \vspace{0.5cm}


%%%%%%%%%%%%%%%%%%%%%%%%%% CHAPTER %%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Different Diagrams}
%%%%% SECTION %%%%%%%
\section{Class Diagram}
%%%
\subsection{Basics of Class Diagrams}
The class diagram is a central modeling technique that runs through nearly all object-oriented methods. This diagram describes the types of objects in the system and various kinds of static relationships which exist between them. There are three principal kinds of relationships which are important: associations, subtypes and aggregation. \\
Associations represent relationships between instances of types. The interpretation of them varies with the perspective. Conceptually they represent conceptual relationships between the types involved. In specification these are responsibilities for knowing, and will be made explicit by access and update operations. \\
Associations may be bi-directional (can be navigated in either direction) or uni-directional (can be navigated in one direction only). Conceptually all associations can be thought of as bi-directional, but uni-directional associations are important for specification and implementation models. For specification models bi-directional associations give more flexibility in navigation but incur greater coupling. In implementation models a bi-directional association implies coupled sets of pointers, which many designers find difficult to deal with. \\
One of the key aspects of associations is the cardinality of an association (sometimes called multiplicity). This specifies how many companies a person may work for, how many children a mother can have, etc. This corresponds to the notion of mandatory, optional, 1-many, many-many relationships in the Entity-Relationship approach. The UML has standard the mass of different approaches that existed here.

%%%
\subsection{Class Diagram}

\includegraphics[width=18cm]{lfclass}


%%%%% SECTION %%%%%%%
\section{Activity Diagram}
%%%
\subsection{Basics of Activity Diagrams}
The activity diagram focuses on activities, chunks of process that may or may not correspond to methods or member functions, and the sequencing of these activities. In this sense it is like a flow chart. It differs, however, from a flow chart in that it explicitly supports parallel activities and their synchronization. \\
What is an Activity Diagram: \\
\begin{itemize}
\item Describes activities and flows of data or decisions between activities.
\item Provides a very broad view of business processes. 
\item Can be used to break out the activities that occur within a use case.
\end{itemize}
When to use an Activity Diagram: \\
\begin{itemize}
\item When describing work flow across many use cases.
\item When analyzing a use case.
\end{itemize}
This diagram is useful in showing work flow connections and describing behavior that has a lot of parallel processing.\\

%%%
\subsection{Activity Diagram}

\includegraphics{lfactivity}


%%%%% SECTION %%%%%%%
\section{Sequence Diagram}
%%%
\subsection{Basics of Sequence Diagrams}
Object Sequence Diagrams are about deciding and modelling HOW our system will achieve WHAT we described in the Use Case model. During analysis this will still be at quite a high level possibly without even any user interaction modelled. But into design the OSD will be a complete description of exactly how each object in our system interact in order to perform a particular task. That task equates to a Use Case. \\
%%%
\subsection{Sequence Diagrams}

\begin{figure}[!h]
\includegraphics{lfsequence1}
\caption{Sequence Diagram of Use Case Register}
\label{seq1}
\end{figure}

\begin{figure}
\includegraphics{lfsequence2}
\caption{Sequence Diagram of Use Case Login and Action Choice}
\label{seq2}
\end{figure}

\begin{figure}
\includegraphics{lfsequence3_s}
\caption{Sequence Diagram of Use Case Record}
\label{seq3}
\end{figure}

\begin{figure}
\includegraphics{lfsequence4}
\caption{Sequence Diagram of Use Case Enquiry and Auction}
\label{seq4}
\end{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%% APPENDIX  %%%%%%%%%%%%%%%%%%%%%%%%%%
\appendix
\chapter{Protocols}
\section{October 31, 2001}
\begin{enumerate}
\item Person responsible for Protocoll \\
\emph{Rescher Robert}
\item Participating People \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{What is CRC? \\ Presentation of our CRC cards}
\item New Assignments \\
\emph{To less classes}
\item Open Questions \\
\emph{Is the auction online? \\ Can everybody participate the auction? \\ Is there any restriction? \\ Has the user to be identified? \\ Can everyone record real-estates?}
\end{enumerate}

\section{November 7, 2001}
\begin{enumerate}
\item Person responsible for Protocoll \\ 
\emph{Rescher Robert}
\item Participating People \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{Presentation of the overworked CRC cards}
\item New Assignments \\
\emph{Auction is online. \\ Everybody can paricipate an auction. \\ The restriction is on the complete object via onion-modell. \\ User has to be identified. \\ Everyone, who wants to offer a real-estate can input, perhaps he has to pay for this.}
\end{enumerate}

\section{November 14, 2001}
\begin{enumerate}
\item Person responsible for Protocoll \\
\emph{Rescher Robert}
\item Participating People \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia}
\item Topics talked about \\
\emph{Presentation of the different use cases. \\ Furtheron, a rough draft of user interface prototyping}
\item New Assignments \\
\emph{The auction is part of the system.}
\end{enumerate}

\section{November 21, 2001}
\begin{enumerate}
\item Person responsible for Protocoll \\
\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 class diagram.}
\item New Assignments \\
\emph{Do not think of implementation. \\ Avoid inheritation. \\ New classes: auction, session, login. \\ User Interface Flow Diagram for WML and HTML and proof of functionality.}
\end{enumerate}

\section{December 5, 2001}
\begin{enumerate}
\item Person responsible for Protocoll \\
\emph{Schobesberger Oskar}
\item Participating People \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{Presentation of our user interface flow diagrams.} 
\item New Assignments \\
\emph{Make HTML and XML site. \\ Sequence diagram. \\ Activity diagram.}
\end{enumerate}

\section{December 12, 2001}
\begin{enumerate}
\item Person responsible for Protocoll \\
\emph{Rescher Robert}
\item Participating People \\
\emph{Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia, Schobesberger Oskar}
\item Topics talked about \\
\emph{Presentation of our activity and sequence diagrams. \\  WML and HTML will be sent.}
\end{enumerate}


\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END OF DOCUMENT %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



\begin{figure}[]
\includegraphics{}
\caption{}
\label{}
\end{figure}


\section{}
\begin{enumerate}
\item Person responsible for Protocoll \\
\item Participating People \\
\item Topics talked about \\
\item New Assignments \\
\item Open Questions \\
\end{enumerate}