\documentclass[12pt,fleqn,a4paper]{report}
%% \usepackage[austrian]{babel}
%% \usepackage{german}
\usepackage{makeidx}
\usepackage{graphicx}
\usepackage{epsfig}

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

% A makro, used to formulate questions.
\def\question#1{\footnote{#1}}
\makeindex
\begin{document}

\begin{titlepage}
\vspace{5cm}
\centerline{\large  PS Software Engineering I}
\centerline{\large WS 2001/02}
\vspace{10cm}
\centerline{\huge{\textbf{Project: "Info Warrior"}}}
\vspace{20pt}
\centerline{\textbf{Team 4}}
\clearpage
\end{titlepage}

\tableofcontents

\chapter{Introduction}
\section{Problem Statement}
\par A news agency (e-news) wants to conduct collection of informations and presentation of informations with support of electronic devices. This processes should be intended to work in a quite simple way.
\\ Potential user should mainly be seen as authors of information and users who request informations. Those requests can be made either by persons or by external systems.
\\ This will likley result in two scenarios \begin{itemize}
\item Informations are passed on to other systems by InfoWarrior. In this case, XML should be used.
\item Informations are passed on to single persons. Of course, this demands an applicable presentation of informations. \end{itemize}
An important aspect of InfoWarrior should be the easy maintenance of the system. Especially, there should be no local installation of system components.
\\ In addition, e-news should have the possibility to prepare informations following the needs of different users; this should mean not too much work.
\\ As a first step, InfoWarrior may be reduced to its core parts. However, additional features concerning future releasements ought to be considered.

\section{Basic Considerations}
Information is a very important part of our life. Human beings
always wanted to and want to be good informed on what is happening
in their neighbourhood as well as in their cities, countries and
continets. Fresh information has an influence on our decisions, and that 
is why people like to be fast and good informed.
The most common way the people get informed today is by watching TV,
reading newspapers, listening to the radio, etc. However all this 
information is to be collected and presented to the end-users.
Computer-based system are very suitable for collecting and presenting
of information.

\chapter{CRC-Session}
\section{Preparing a First CRC-Session}
In this section which should be seen as an introduction to the project, we will summarize ideas and concepts we developed when thinking about how to prepare a first meeting with a client. The aim of this section is to get a rough impression what this system could look like, and to find out which questions need to be answered before going on with this project.

\subsection{Which aims are to be pursued?}
\begin{itemize}
\item develop a first cut modell of the project
\item clarify possible misunderstandings
\item articulate questions that seem important at this stage
\end{itemize}

\subsection{Possible Candidate Classes that appear at first glance}
\begin{itemize}
\item A receiving unit that gets informations and prepares them for storage
\item A storing unit that administrates stored informations, integrates new informations and offers access to stored informations
\item A request unit that handles requests to the system to look for specified informations
\end{itemize}

It may be advisible to distinguish two ways how requests are posed to the system:
\begin{itemize}
\item by (personal) users that operate via a front-end system
\item by other systems that make requests via electronic standards
\end{itemize}

\subsection{Scenarios that may give an impression on how the system could work}
\begin{itemize}
\item News-messages are transmitted to the system and now have to be prepared for storage. This has to be done very fast, so that the new informations are immediately available to users of the system.
\item (Personal) users are looking for informations concerning a specific topic. The systems goes through the sored informations, selecting those which may be of interest for the user. Found informations are presented in an appealing and easy-to-overlook way, maybe according to the user's individual preferences.
\item Requests for information are sent via electronic standards. Informations are selected like they are in the scenario above, but are prepared for neatly transmitting them via electronic devices.
\end{itemize}
\subsubsection{Some Additional Thoughts Concerning Scenarios}
\begin{itemize}
\item Can data collector XY manipulate all currently available data, and
what happens if XY tries to access or change data out of scope of his access
rights?\\ 
Suggestion: There should be some kind of access manager that
restricts access only to the field relative for collector XY. If XY tries
to access date without permission there will be an error message shown.
\item What happens if fresh news from some area is/are available?\\ 
Suggestion: There are for example two possibilities:
\begin{itemize}
\item User sets her/his preferences upon registration and gets news delivered
per e-Mail automatically if there is something new in the area she/he is
registered for. 
\item User sets her/his preferences upon registration and when
she/he visits homepage of e-news agency, upon login page is created with links
to news that user is interested in.
\item others
\end{itemize}  
\item How does system respond if data collector XY enters data that already
exist in database? 
\item What happens if user requieres news for which no fresh occurrence is
available\\
Sugestion:
\begin{itemize}
\item System reports that no fresh news is available
\item System shows the most recent news, that user already knows about
\end{itemize}
\end{itemize} 
Other scenarios that can be considered are:
\begin{itemize}
\item Enter News(manually)
\item Delete News
\item Edit existing News entries
\item News request from automated system
\item News browsing
\end{itemize}
Beyond these basic scenarios there can be some others, if user management is
necessary, or we want to provide access control:
\begin{itemize}
\item Create User
\item Login
\item Modify User rights/preferences
\item News entry not found
\item Access violation
\end{itemize}

\subsection {Questions that still need to be answered:}
\begin{itemize} 
\item Are there any characteristics that may classify informations of different contents and styles?
\item What are the main sources the system will use for receiving new informations?
\item Which are typical scenarios that describe adequately the way the system will likely work?
\item Are there any aspects we have not at all considered so far?
\end{itemize}

\section{Results of a First Meeting with Client}
As a result of this first meeting, many questions were answered and a more detailed description of the system was achieved. I will summarize the most important points.
This section should give a deeper understanding of the problem domain and provide a more detailed description of demands and profiles.

Data acquisition should be easy and compact, as should its presentation and input. Usually, data will be input through "manual typing", but a possibility for automatic input may also be considered.

Data acquisition is mainly done by a group of editors. Each editor oversees the work of about 10 reporters. Editors have the responsibility of controlling the reporters' work. Articles ($\rightarrow$ informations) may consist of pure text, but can also contain pictures or be designed as multimedia-presentations.

The team consists of 5 editors, each of them presiding over group of about 10 reporters. Reporters send informations every day, usually up to 5 articles every 24 hours.

Each reporter sends his articles to one editor. Editors, however, may have access to any of the reporters' articles; releasing of articles for publication is the responsibility of only one editor.

Additional characteristics that are needed to classify informations (meta-data) will be supplied. The classification of data is done through editors.

Modifications of data should be possible, as editors are responsible for controlling reporters' input and releasing them for publication. Once articles are put to the archives, their appearance should be stable.

It should be expected that the amount of stored data becomes very huge very fast. Therefore, the following modell should be considered: informations should be quickly available for one month (as long as they are up to date). When they are put to the archives, access may take a bit more time.

Access to the system should be partly limited. Informations of general interest schould be freely available, but content of high importance and/or high relevance may be charged for.

Other systems that may communicate with "Info-Warrior" could include clients as the CNN-Homepage, other new's agencies, Handies (SMS) and so on. Therefore, we can assume that all those systems do already exist. The designing of interfaces needn't follow any specific instructions.

Transmission of data may be subdivided into two scenarios:
\begin{itemize}
\item \textit{Pull-Method:} Users request actively informations, that is by logging in on the system.
\item \textit{Push-Method:} The systems actively sends informations to users that have subscribed for those services (e.g. e-mail, SMS, ...).
\end{itemize}
All those applications should be WEB-based, of course.

For this first stage of development, the essential tasks will be modelling the kernel of the system, more detailed aspects like accounts for users needn't be intensively discussed so far. However, the desiging of an applicable Customer-Relationship-Modell (CRM) should already be considered.

Another important aspect that was mentioned was an "Essential User-Interface Modelling". As informations needed for login (name, password, ...) should be considered, the administration of users and their authorizations should be neatly solved.

For a CRC-session next time, the following subjects should be remembered: reporter; editor; informations; user: name, address, ... ; communication-interfaces; "persons" (for purposes of inherence); ...

As a next step, Use-Cases should be discussed as potential examples of applications that may reveal the functionality of the system. Consequently, scenarios will be developed. 

\section{Results of CRC-Session}

\subsection{Main Aspects of CRC-Session}
\begin{itemize}

\item {discussed and developed classes and interactions} 

\item {prepared crc cards}

\item {created an essential user interface prototype diagram}

\item {identified some use cases}

\end{itemize}


\subsection{Candidate Classes}

 Classes we've yet identified and consider useful. Some questions, like different classes for user interfaces (eg editor, customer) remain open.

\begin{itemize}
\item actors

        \begin{description}

                \item [responsibility] representation

                \item [collaborators] Second item

        \end{description}



\begin{itemize}
\item editor

        \begin{description}

                \item [responsibility] edit article, release article

                \item [collaborators] user interface, message

        \end{description}



\item {reporter

        \begin{description}

                \item [responsibility] compose article

                \item [collaborators] user interface, message

        \end{description} 

\item user

        \begin{description}

                \item [responsibility] read articles

                \item [collaborators] user interface, message

        \end{description} 

\item external system

        \begin{description}

                \item [responsibility] request articles

                \item [collaborators] external systems interface

        \end{description}



\end{itemize}
\item user interface

        \begin{description}

                \item [responsibility] provide news to user

                \item [collaborators]user, external systems interface

        \end{description}



\item external systems interface

        \begin{description}

                \item [responsibility] provide news, convert messages and requests from external format to core format

                \item [collaborators] user interface, message, external system, request

        \end{description} 

 

 \item access control

        \begin{description}

                \item [responsibility] supervise data access

                \item [collaborators] login, user core, external systems interface

        \end{description} 



 

\item login

        \begin{description}

                \item [responsibility] internal representation of actors

                \item [collaborators] user core, access control

        \end{description}



\item user core

        \begin{description}

                \item [responsibility] manage user data storage

                \item [collaborators] external systems interface, access control, user data storage

        \end{description} 



\item message core

        \begin{description}

                \item [responsibility] manage message storage and information flow

                \item [collaborators] message, external system interface, message storage, archive

        \end{description}

\item request

        \begin{description}

                \item [responsibility] specify request to interface

                \item [collaborators] actor, external systems interface, message core

        \end{description} 



\item message

        \begin{description}

                \item [responsibility] article representation

                \item [collaborators] actor, user interface, external systems interface

        \end{description} 

\item message storage

        \begin{description}

                \item [responsibility] news data storage

                \item [collaborators] message, message core

        \end{description}



\item archive

        \begin{description}

                \item [responsibility] storage for older articles

                \item [collaborators] message, message core

        \end{description}



\item user data storage

        \begin{description}

                \item [responsibility] storage for user data

                \item [collaborators] user core

        \end{description} 

\end{itemize}

\chapter{User-Interface-Modelling}
A very important aspect for InfoWarrior is the User-Interface, as the system will substantially work as front-end-system. In a Second Meetin with the client, we presented our suggestions which will be summarized in the next paragraphs.

 This part contains some ideas about essential user interfaces for the different types of users of the InfoWarrior system. It consists of a textual description and graphical drafts / diagrams. 
\section{Description}

\begin{itemize}
        \item Customer User Interface
          \begin{itemize}
                \item Introduction
Since the costumer front-end is mainly web based, the user interface consists of web pages.

                 \item basic web pages
                   \begin{itemize}
                        \item Start Page

the home page. \\ it is the first thing a (potential) costumer sees after typing in the url, so it should be attractive, clear and well-structured. It features the latest headlines and provides links to the most important subpages.\\ Important features: User Login, link to Sign Up Page. 

                        \item Sign Up Page

main purpose: customer registration.\\ Features input boxes for user data, like name, surname, country, state, e-mail address, a login name and password etc, and options for pay level, payment mode.



                        \item Category Page

main purpose: structuring of articles, facilitating efficient browsing. \\categories might be economy, science, politics, with subcategories world politics, regional politics etc. links lead to other category pages (related categories or subcategories), and article pages. Also provides an input box for quick search for articles within the category.

                        \item Search Page

provides advanced search options to fine-tune a search, like searching for older articles, AND/OR junction of keywords, searching within a specific category etc.\\

search results are displayed on Search Result Page.

                        \item Search Result Page

presents links to articles the search engine has found, also information about date, content, and category. may also show headlines of articels of a higher pay level than user's, with suggestions to sign up to higher level.

                        \item Welcome User Page

page that opens after user login, featuring headlines of user's preferred categories.

                        \item Preferences Page

main purpose: (registered) users can set different options like default search settings, preferred categories etc and subscribe to services that are within their pay level. 

                        \item Article Page

Displays article text in attractive, readable form as well as pictures, offers accompaning multimedia files for download etc. Links to related articles.

 

\end{itemize}
\end{itemize}
        \item Staff User Interface

        \begin{itemize}
                \item Introduction

As the Staff User has a different approach to the InfoWarrior system than the customer, the requirements to a user interface are also quite different. The Staff User needs an interface to get his/her work efficiently done. If the Staff User Interface will be partiallly or fully web based like the Customer Interface remains open at this stage of design. The login procedure could be done via the Customer Interface Start Page.

                        \item Reporter Interface

                        \begin{itemize}
                        \item Reporter Page

Each reporter's home page / main window, that is opened after login.\\ It gives an overview on the reporter's recent work, listing article headlines with information about date and whether the article has yet been submitted and released. Links to Edit Article Page (to create/edit articels), a task list, a search page/window to search for articles, and maybe an emailprogram to send email to the responsible editor.

                        \item Edit Article

enables reporters to compose, edit, and save articles, add files that accompany the article text (like pictures, sound files, and other multimedia), and submit them to the responsible editor. Input boxes for text, abstract and headline. 



\end{itemize}
                \item Editor Interface

Since editors can also write articles, their interface provides the same functionality as the reporters', with additions. 

\begin{itemize}
                        \item Editor Page

Home page / main window. Similar to the Reporter Interface, it displays recent article headlines from the editor's section, with information about date, author, and whether the article was yet released. Article headlines link to View Article Page/Window. Link to email program to send tasks to reporters. 

                        \item View Article

Displays articles as they are seen on the homepage/Customer Interface (ie Article Page). Buttons to release, delete or edit article (-> Edit Article Page).



                        \item Edit Article

As in Reporter Interface. (See above)

\end{itemize}
                \item Administrator Interface

\end{itemize}
\end{itemize}


\section {Diagrams/Drafts}

\section {Results of Second Meeting with Client}
\par As a result of this second session, several more details of system requirements and administrative business were discussed and clarified:
\begin{itemize}
\item \textit{Payment-Methods:}
\vspace{5pt}
\\ Invoice for payment concerning services that do not come for free will be done on a monthly basis. This should give a possibility to check whether users are still paying or willing to pay in time. Usually, invoices will be sent to users' postal adresses.
\item The system should be developed as platform independent. The main aspect should be an easy maintenance of the system.
\item \textit{Actors:}
\vspace{5pt}
\\ The following items were agreed upon:
\begin{itemize}
\item \textit{human actors:} editors, reporters, users of the system (clients)
\item \textit{external systems}
\item \textit{archives:} containing news that reach further back in time
\item \textit{storage units:} subdivided into a message storage (containing high priority information) and user data (adaministrating access control etc.)
\end{itemize}
\item \textit{entry page - user interface:}
\vspace{5pt}
\\ The entry page should present at least some accurate and on time information from all "over the world". Informations should refer to certain categories. Access to informations will be granted for different levels of payment. The user interface may also present an option to subscribe for services.
\item \textit{Sign-in-Procedures:}
\vspace{5pt}
\\ Sign-in is required for push-methods. Therefore, it will be necessary to extract informations from articles for different purposes. This should enable e.g. an SMS-News-Service, that is a minimum information in a given format.
\item \textit{Technical Requirements:}
\vspace{5pt}
\\ Editing of articles is done only once for different services. The input form of articles will thus provide seperate areas for entries such as headline, abstract (up to ... characters), categorization, payment-level of information, ... . As a last instance, the editor will supervise all entries.
\\ Editors may compose news, too. Anyway, the two-level-process of releasement has to be secured, so any time an editor acts as "reporter", his article has to be approved by another editor.
\item \textit{Technical Aspects of Administration:}
\vspace{5pt}
\\ New subscriptions to services should be processed automatically. Thus, the system has to meet any requirements necessary. However, anytime an action concerning users of the system is taken, the administrator or people of the administration office should be informed personally. Frequent actions may be summarized as reports. Persons, however, should not be required to take actions in order to complete a standardized process.
\end{itemize}
\par In this second session, a first concept of User-Interface was presented and approved in general.
\vspace{10pt}
\par The following items should be prepared for the next meeting:
\begin{itemize}
\item \textit{Use Cases:} The whole process should be described in natural language.
\\ For the most important Use Cases, drawings in UML may be prepared, too.
\item In addition, transparencies concerning Use Cases, UML and User-Interface may be provided.
\end{itemize}

\chapter{Use Cases}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Identifying Actors}
\begin{itemize}
\item Editor
\item Reporter
\item End-user
\item External System
\item Administrator
\item InfoWarrrior Application 
\item Access Control Manager
\item News
\item InfoWarrior Search Machine
\item Storage Unit
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section {Identifying Use Cases}
\begin{itemize}
\item Subscribe to InfoWarrior Services
\item Unsubscribe from InfoWarrior Services
\item User logs in
\item End-User edits Preferences
\item Editor edits News
\item User searches News 
\item Administrator modifies User Data
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Description}
\begin{enumerate}
\item {\bf Name:} Subscribe to InfoWarrior Services \\
{\bf Description:} Somebody wants to subscribe to InfoWarrior services. She/he
opens the official InfoWarrior web-page and  clicks ``Sing up now!'' link and
enters necessary information (username, password, e-mail address,...) in order
to create an account. The user can decide weather she/he wants to use just free
or billable InfoWarrior services as well. After submitting this information
she/he becomes a user of the corresponding InfoWarrior services.
\item {\bf Name:} Unsubscribe From InfoWarrior Services \\
{\bf Description:} A user wants to unsubscribe from InfoWarrior Services.
She/he clicks ``Unsubscribe From InfoWarrior Servceses'' link. Then she/he
will be asked does she/he want to unsubscribe from free InfoWarrior services,
billable InfoWarrior services or from the both ( free and billable ) services.
After submitting her/his answer, she/he won't be a user of corresponding
InfoWarrior services anymore.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item {\bf Name:} User logs in \\
{\bf Description:} A user (editor, reporter, end-user) wants to log in. She/he
opens the official InfoWarrior web-page and enters her/his user name and
password in the corresponding fields. If a user (editor, reporter, end-user)
enters incorrect user name or password a login incorrect window will be
opened, and a user can try to log in again.Upon successful login new User
Interface is shown, with features available depending on access level. That
means, if for example, a reporter logs in, a reporter specific window will be
opened.
%%{\bf blah}
\item {\bf Name:} End-User edits Preferences \\ 
{\bf Description:} An End-User wants to edit her/his preferences. After login
every user has a link ``Edit Preferences''. When she/he clicks this link, a
page with her/his preferences will be opened. The preferences page contains 
user specific information : user name, encrypted password, e-mail address,
mobile phone number, etc., that is, it contains all information given upon
subscribing to InfoWarrior services. The user can now modify her/his
preferences. After editing, she/he clicks a button ``Submit changes'' in
order to apply changes to her/his account.
\item {\bf Name:} Editor edits News \\ 
{\bf Description:} An editor wants to edit news. That means she/he wants to
add, delete, or alter news. Upon login every editor has buttons for each of
these actions. When she/he clicks one of these buttons, she/he can browse the
files, that she/he wants to add/delete/alter. After editing she/he has to
commit ``Submit changes'' in order to apply changes to the system storage unit.
\item {\bf Name:} User searches News in the Primary Storage System \\
{\bf Description:} A user(editor, reporter, end-user) wants to search for recent
news. She/he clicks ``Search'' link in order to start search page. A user
enters wanted pattern in the corresponding field and clicks ``Start Search''
button. The InfoWarrior Search Machine outputs all news corresponding to the
searching pattern. 
\item {\bf Name:} User searches News in the Secondary Storage System \\
{\bf Description:} A user(editor, reporter, end-user) wants to search for older
news. She/he clicks ``Advanced Search'' link in order to start the advanced search page. 
Afterwards she/he enters wanted pattern in the corresponding field and clicks
``Start Search'' button. The InfoWarrior Search Machine outputs all news corresponding
to the searching pattern. 

\item{\bf Name: Administrator logs in}   \\
The administor opens the standard login page and provides the his loginname and password.
After validating the login data, the administrator is shown the administrator main page, that
provides links for essential administrative activities.
\item{\bf Description}

\item {\bf Name:} Administrator creates a User \\
{\bf Description:} The administrator wants to create a new reporter or editor in the system.
>From the admin main page he uses the create user page and enters the users essential data and 
privileges. After the admininistrator confirms the data, the system creates a new user.

\item{\bf Name:} Administrator searches User \\
{\bf Description} The administrator wants to view existing users. He enters search criteria
for the users to be returned and clicks search. The system returns a list of matching users, from which
the administrator can select a user.

\item {\bf Name:} Administrator modifies User Data \\
{\bf Description:} The administrator wants to modify user data or privileges. He searches the
specific user as described in ``Administrator searches User''. He selects to modify the user and
the user modification page is returned. There he changes the data and confirms them by clicking a ``submit��
button. The system commits the changes to the user database.

\item {\bf Name:} Administrator deletes a User \\
{\bf Description:} The administrator wants to delete a user. He searches the
specific user as described in ``Administrator searches User''. He selects to delete the user. 
After confirmation from the administrator, the system user is removed from the user database.

\item {\bf Name:} Administrator creates a category \\
{\bf Description:} The administrator wants to create a new category for news. He selects the link on the 
main page and enters the name of the category. After the administrator confirms the data, the system 
creates a new category

\item {\bf Name:} Administrator deletes a category \\
{\bf Description:} The administrator wants to delete a category. He selects the link on the
main page and on the next page the category he wants to delete. He gets a warning how much news will be deleted
on cascade if he will delete the category. After the administrator confirms the data, the system
deletes the category and all news assigned to it.


\end{enumerate} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section {Essential User Interface Prototyping}
\begin{center}
\includegraphics{EssentialUInterface2a.eps}
\end{center}
System contains one main window with links/buttons to other pages/windows. It
is the same for normal users, editors and reporters. Upon login new User
Interface is shown with features available depending on access level
and demanded service. It can be ``An Editor specific Window'', ``A Reporter
specific Window'', ``Sign up window'', ``A registered User specific Window'',
``InfoWarrior Search Window'', or ``Free Info Window'' 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{center} 
\includegraphics{EssentialUInterface2.eps}
\end{center}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
After successful login, a user can open different windows/pages, for
example:  
\begin{center}
\includegraphics{EssentialUInterface3.eps}
\end{center}
\newpage

\par In the third session, Use Cases were discussed with the client. Therefore, we may now proceed by starting drawing class-diagrams.

\end{document}