January 9, 2002

Seminar Software Engineering

ImmoWarrior

Report

Schobesberger Oskar

oskarschobesberger@hotmail.com

Academic Supervisor Mag. Dipl.-Ing. Schwaiger Roland

Department of Computer Science University of Salzburg

Correspondence to:

Universität Salzburg

Institut für Computerwissenschaften und Systemanalyse

Jakob-Haringer-Straße 2

A-5020 Salzburg Austria

Contents

1 Introduction 2 1.1 About this paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Short description of the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Development Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 CRC Cards 3 2.1 Short Description of CRC Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Image of CRC Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Use Cases 5 3.1 Record Real Estate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Enquire Real Estate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Essential User Interface Prototyping 7 4.1 HTML-Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 WML-Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 User Interface Flow Diagrams 12 5.1 HTML User Interface Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 HTML User Interface Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Class Diagram 14 6.1 Short Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Activity Diagram 17

8 Sequence Diagram 19

A Protocols 21 A.1 2001-31-October . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.2 2001-07-November . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.3 2001-14-November . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.4 2001-21-November . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.5 2001-05-December . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.6 2001-12-December . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 1

Introduction

1.1 About this paper

This paper contains a collection of my personal solutions to the weekly tasks. Therefore it mainly consists of pictures showing certain diagrams. The order of the chapters do not exactly resemble the order of the tasks to which they belong, because i thought it is more useful to put the user interface flow diagrams directly after user interface prototyping. Of course there is nevertheless lack of consistency, because this paper does not describe every single step of thinking and it does not contain our group results, which are documented in the group paper anyway (although it is quite probable that there are going to be many similarities to the group paper, on one hand, because each group solution has been the ground for the following task and on the other hand, because group interaction can not be expected to be turned off until everybody has their personal solution).

1.2 Short description of the problem

The company called e-Immo wants us to design a software product that manages (parts of) online-auctions for real estates. The System should basically provide the following possibilities: \underline{record real estate} information and \underline{call real estate} information. It should be possible for single persons, but also for other systems to call information.

1.3 Development Progress

1. CRC Cards

2. Use Cases

3. User Interface Prototyping

4. User Interface Flow Diagrams

5. Class Diagram

6. Activity Diagrams

7. Sequence Diagrams

CRC Cards

2.1 Short Description of CRC Cards

CRC Cards should help to get a basic structure into the design. Functional units can be worked out and grouped. Each CRC Card contains the name of a class and two columns, with Responsibilities of the left, and Collaborations on the right. Responsibilities show what a class contains and what a class ”does”. Collaborations show which other class is involved in a certain Responsibiliy. The following Picture, which describes my first ideas (obviously, i forgot lots of important things, especially the login and user data) about the project via CRC Cards, also has lines between the single card, which indicate collaboration.

2.2 Image of CRC Cards

4

Use Cases

Differently to what we presented as group i did not specify sub-use cases, but only wrote down the two main use cases for record and enquiry.

3.1 Record Real Estate

\underline{Description}: User can record a new real-estate \underline{Precondition}: User has the right to record real estates \underline{Postcondition}: A new real-estate will be recorded

1. System presents login mask.

2. User submits username and password.

3. System verifies password and presents action choice mask.

4. User chooses Recording.

5. System presents Record Mask.

6. User submits real estate data.(optionally: cancel leads to 3.)

7. System asks to re-check data.

8. User verifies data and gives ok.(optionally: cancel leads to 5.)

9. System records real estate. Optionally at any point: User can logout, which leads to step 1.

3.2 Enquire Real Estate

\underline{Description}: User enquires real-estate \underline{Precondition}: none \underline{Postcondition}: System Displays Real Estate Details

1. System presents login mask.

2. User submits username and password.

3. System verifies password, checks rights level, and presents action choice mask.(optionally, if user does not have record rights:step 5)

4. User chooses Enquire.

5. System presents Enquery mask.

6. User chooses search criteria. (optionally: cancel leads to 3.)

7. System presents result table, according to the rights level of the user.

8. User selects one real estate and requires details (optionally: cancel leads to 5.)

9. System displays details for selected real estate. Optionally at any point: User can logout, which leads to step 1.

Essential User Interface Prototyping

Essential User Interface Prototyping is done to get an image of what the user is going to be presented on each screen the system provides. (How you get from one screen to another is explained by the User Interface Flow Diagrams in the next chapter) This chapter contains two versions of User Interface Prototyping, the first one shows what the screens in html implementation should consist of (six screens). The wml version, which follows afterwards, still contains the idea that there should not be more than one input field each screen and ”buttons” are replaced by keys that are available on every mobile phone. As it was done at a time when i had no idea about wml, it is pretty far away from our later wml-files (which were, like the html files, group-work and are therefore not included in this paper).

4.1 HTML-Screens

8

4.2 WML-Screens

9 10 11

User Interface Flow Diagrams

As mentioned above, the User Interface Flow Diagrams mainly show how the user gets from one screen to another. I think the Diagrams are easy to understand, every rectangle represents one screen and the arrows show their directed connections. Text beside/above the arrows indicates which user input triggers a certain screen change.

5.1 HTML User Interface Flow Diagram 5.2 HTML User Interface Flow Diagram

13

Class Diagram

While the previous chapters focussed on the perspective of a user, the class diagram should help to understand the structure of the system. It shows how the main components, the classes, are linked together and it also includes basic methods and attributes of the classes. Its creation allowed to identify new demanded classes, in order to provide the functionality it should, according to use cases, crc cards and interface prototyping. I included my second version of the diagram, because the first draft turned out to be rather useless.

6.1 Short Description

Each time the program is started, the system interface creates an object session, which furtheron instantiates login. If login fails, the session is destroyed, otherwise login returns the data for the actual user. Then the session can instantiate Record, Enquire, or auction together with input that comes from the terminal/mobile phone (over the representation processor). Those access the database which manages the user collection and the real estate collection.

Chapter 7 Activity Diagram

The Actvity Diagram shows the logic of system activities. The rhombuses are decision points. I tried to put the whole system into a single diagram.

18

Sequence Diagram

The Sequence Diagram describes the messages between objects in time flow. My diagram shows this only for the use case Record Real Estate. In order not to let it become too complicated I assumed that the user has record rights and, as i would say, behaves correctly. So there are no conditional statements in the diagram.

20

Appendix A

Protocols

A.1 2001-31-October

1. Project Leader Rescher Robert

2. Participating people Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia, Schobesberger Oskar

3. Topics talked about What is a CRC-Session? Presentation of our CRC cards.

4. New assignments We need to re-organize the storage of user and real estate information. We generally need new classes to refine our crc-model.

5. Open questions Auction online? Different user rights?

A.2 2001-07-November

1. Project Leader Strobl Elisabeth

2. Participating people Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Strobl Elisabeth, Nidetzky Marion, Fimberger Lucia, Schobesberger Oskar

3. Topics talked about Presentation of refined CRC cards.

4. New assignments Auction is online. User interface prototype. User rights are organized like an onion: the more you pay, the more you get Maybe include a possibility to search only real estates in a distance below e.g 30 km

A.3 2001-14-November

I was absent.

A.4 2001-21-November

1. Project Leader Fimberger Lucia

2. Participating people Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Fimberger Lucia, Schobesberger Oskar

3. Topics talked about Presentation of the Use Case and User Interface Prototyping for Auction. Presentation of Class diagram

4. New assignments Make a new class diagram, that is more suitable for analysis phase; avoid inheritation; define more classes; seperate database management from system interface; create a class, called something like session, that is instantiated for each user

A.5 2001-05-December

1. Project Leader Schobesberger Oskar

2. Participating people Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Fimberger Lucia, Schobesberger Oskar

3. Topics talked about Presentation of refined class model. Presentation of User Interface Flow diagrams for wml and html.

4. New assignments Stick to one kind of User Interface Flow Diagrams. Make a html and a wml progam that show the Interfaces. Include a possibility for user administration in the system

A.6 2001-12-December

1. Project Leader Rescher Robert

2. Participating people Mag. Dipl. Ing. Schwaiger Roland, Rescher Robert, Fimberger Lucia, Schobesberger Oskar, Nidetzky Marion

3. Topics talked about Presentation of activity diagrams and sequence diagrams

4. New assignments Subdiagram Record: seperate Input/OK (two activities). Subdiagram User Administration: create a subdiagram for add. Sequence diagram: make time-steps more obvious.