PS Software Engineering I WS 2001/02

Project: ”Info Warrior”

Team 4

Contents

1

Chapter 1

Introduction

1.1 Problem Statement

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

• Informations are passed on to other systems by InfoWarrior. In this case, XML should be used.

• Informations are passed on to single persons. Of course, this demands an applicable presentation of informations.

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.

1.2 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. Computerbased system are very suitable for collecting and presenting of information.

CRC-Session

2.1 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.

2.1.1 Which aims are to be pursued?

• develop a first cut modell of the project

• clarify possible misunderstandings

• articulate questions that seem important at this stage

2.1.2 Possible Candidate Classes that appear at first glance

• A receiving unit that gets informations and prepares them for storage

• A storing unit that administrates stored informations, integrates new informations and offers access to stored informations

• A request unit that handles requests to the system to look for specified informations

It may be advisible to distinguish two ways how requests are posed to the system:

• by (personal) users that operate via a front-end system

• by other systems that make requests via electronic standards

2.1.3 Scenarios that may give an impression on how the system could work

• 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.

• (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.

• 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.

Some Additional Thoughts Concerning Scenarios

• 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.

• What happens if fresh news from some area is/are available?

Suggestion: There are for example two possibilities:

– 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.

– 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.

– others

• How does system respond if data collector XY enters data that already exist in database?

• What happens if user requieres news for which no fresh occurrence is available Sugestion:

– System reports that no fresh news is available

– System shows the most recent news, that user already knows about

Other scenarios that can be considered are:

• Enter News(manually)

• Delete News

• Edit existing News entries

• News request from automated system

• News browsing

Beyond these basic scenarios there can be some others, if user management is necessary, or we want to provide access control:

• Create User

• Login

• Modify User rights/preferences

• News entry not found

• Access violation

2.1.4 Questions that still need to be answered:

• Are there any characteristics that may classify informations of different contents and styles?

• What are the main sources the system will use for receiving new informations?

• Which are typical scenarios that describe adequately the way the system will likely work?

• Are there any aspects we have not at all considered so far?

2.2 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 (→ 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:

• Pull-Method: Users request actively informations, that is by logging in on the system.

• Push-Method: The systems actively sends informations to users that have subscribed for those services (e.g. e-mail, SMS, ...).

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.

2.3 Results of CRC-Session

2.3.1 Main Aspects of CRC-Session

• discussed and developed classes and interactions

• prepared crc cards

• created an essential user interface prototype diagram

• identified some use cases

2.3.2 Candidate Classes

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

• actors

responsibility representation

collaborators Second item – editor

responsibility edit article, release article collaborators user interface, message

– reporter responsibility compose article collaborators user interface, message

– user responsibility read articles collaborators user interface, message

– external system responsibility request articles collaborators external systems interface

• user interface responsibility provide news to user collaborators user, external systems interface

• external systems interface

responsibility provide news, convert messages and requests from external format

to core format collaborators user interface, message, external system, request

• access control responsibility supervise data access collaborators login, user core, external systems interface

• login responsibility internal representation of actors collaborators user core, access control

• user core responsibility manage user data storage collaborators external systems interface, access control, user data storage

• message core responsibility manage message storage and information flow collaborators message, external system interface, message storage, archive • request

responsibility specify request to interface collaborators actor, external systems interface, message core

• message responsibility article representation collaborators actor, user interface, external systems interface

• message storage responsibility news data storage collaborators message, message core

• archive responsibility storage for older articles collaborators message, message core

• user data storage responsibility storage for user data collaborators user core

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.

3.1 Description

• Customer User Interface

– Introduction Since the costumer front-end is mainly web based, the user interface consists of web pages.

– basic web pages

∗ 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.

∗ Sign Up Page main purpose: customer registration. Features input boxes for user data, like name, surname, country, state, email address, a login name and password etc, and options for pay level, payment mode.

∗ 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.

∗ 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.

∗ 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.

∗ Welcome User Page page that opens after user login, featuring headlines of user’s preferred categories.

∗ 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.

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

• Staff User Interface

– 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.

– Reporter Interface

∗ 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.

∗ 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.

– Editor Interface Since editors can also write articles, their interface provides the same functionality as the reporters’, with additions.

∗ 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.

∗ 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).

∗ Edit Article As in Reporter Interface. (See above)

– Administrator Interface

3.2 Diagrams/Drafts

3.3 Results of Second Meeting with Client

As a result of this second session, several more details of system requirements and administrative business were discussed and clarified:

• Payment-Methods:

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.

• The system should be developed as platform independent. The main aspect should be an easy maintenance of the system.

• Actors:

The following items were agreed upon:

– human actors: editors, reporters, users of the system (clients)

– external systems

– archives: containing news that reach further back in time

– storage units: subdivided into a message storage (containing high priority information) and user data (adaministrating access control etc.)

• entry page - user interface:

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.

• Sign-in-Procedures:

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.

• Technical Requirements:

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.

• Technical Aspects of Administration:

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.

In this second session, a first concept of User-Interface was presented and approved in general.

The following items should be prepared for the next meeting:

• Use Cases: The whole process should be described in natural language. For the most important Use Cases, drawings in UML may be prepared, too.

• In addition, transparencies concerning Use Cases, UML and User-Interface may be provided.

Use Cases

4.1 Identifying Actors

• Editor

• Reporter

• End-user

• External System

• Administrator

• InfoWarrrior Application

• Access Control Manager

• News

• InfoWarrior Search Machine

• Storage Unit

4.2 Identifying Use Cases

• Subscribe to InfoWarrior Services

• Unsubscribe from InfoWarrior Services • User logs in

• End-User edits Preferences

• Editor edits News

• User searches News

• Administrator modifies User Data

4.2.1 Description

1. Name: Subscribe to InfoWarrior Services 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.

2. Name: Unsubscribe From InfoWarrior Services 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.

3. Name: User logs in 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.

4. Name: End-User edits Preferences 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.

5. Name: Editor edits News 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.

6. Name: User searches News in the Primary Storage System 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.

7. Name: User searches News in the Secondary Storage System 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.

8. 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.

9. Description

10. Name: Administrator creates a User 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.

11. Name: Administrator searches User 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.

12. Name: Administrator modifies User Data 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.

13. Name: Administrator deletes a User 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.

14. Name: Administrator creates a category 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

15. Name: Administrator deletes a category 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.

4.3 Essential User Interface Prototyping

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”

After successful login, a user can open different windows/pages, for example:

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