PS Software Engineering

November 21, 2001

ImmoWarrior

Report

Andrea Geierspichler, Roman Gross, Christian Koidl, Michael Pober, Gunnar Ruhs

andreageierspichler@hotmail.com

Academic Supervisor Mag. DI Dr. Roland Schwaiger

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

ImmoWarrior

Andrea Geierspichler, Roman Gross, Christian Koidl, Michael Pober, Gunnar Ruhs

Department of Computer Science University of Salzburg A-5020 Salzburg, Austria

Chapter 1

The Project

To learn the how-to’s of ”Software Engineering” we simulate a real life situation in the proseminar. 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:

• Immowarrior sends the information to an other computer system by using XML

• Immowarrior displays the information for a person - what requires us to design an appropriate user-interface.

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

A CRC Session

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.

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.

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.

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. Perform Use-Case Scenario Testing

1. Call out a new scenario. In this phase of the CRC-session the scenario is discussed and described in basic

2. Determine which card should handle the responsibility.

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

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

5. Act out the collaboration between the different classes. Advantages of CRC-Modelling

1. The analysis is done by people who understand the problem domain (experts)

2. The future-users are actively involved in defining the model for the program.

3. CRC-modelling can easily be explained to a group of people.

4. The CRC-session leads directly into class-diagramming. Things you have to keep in mind

• Start with simple scenarios.

• Take the time to select meaningful class names.

• Take the time to write a description of the class.

• If in doubt, act it out!

• Layout the cards on the table to get a feeling for system structure.

• Be prepared to be flexible.

Our CRC Cards

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

Classname: Admin Responsibilities Collaborators 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

Classname: EditorAndUser Responsibilities Collaborators 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

Classname: Editor Responsibilities Collaborators access user interface user interface view free offers log in configurate account place/edit/delete real estate log off Classname: User Responsibilities Collaborators access user interface user interface view free offers log in configurate account search for real estate view real estate info log off

Classname: Guest Responsibilities Collaborators access user interface user interface view free offers request new read account

Classname: User Interface Responsibilities Collaborators

read input  guest
forward data  user
show info  editor

start session editoranduser admin session

Classname: Session Responsibilities Collaborators 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

Classname: Account Responsibilities Collaborators access info storage

session

modify account info

info storage

forward account info Classname: Information Storage Responsibilities Collaborators store account info

session

store real estate info

account

forward data

search for info

Classname: Search for Info Responsibilities Collaborators perform search

info storage

forward search results

session

Classname: Send Account Info Responsibilities Collaborators send username to e-mail/cell phone

account

send password to e-mail/cell phone

session

send account privileges to e-mail/cell phone

Classname: Send Real Estate Info Responsibilities Collaborators send info to e-mail/cell phone

session

look up account info account

Appendix A

Protocolls

A.1 1^{st} Lesson - October, 25^{th}, 2001

Basical information about the course and division into groups.

A.2 2^{nd} Lesson - October, 31^{st}, 2001

First meeting with the client and CRC-session.

1. Groupleader: Christian Koidl

2. Participating Groupmembers: Andrea Geierspichler, Gunnar Ruhs, Roman Gross, Michael Pober

3. Topics talked about: Analysis of the problem and basic class-definition

4. Results:

(a) The client wants the possibility to obtain relevant information on offers via the internet or the mobile phone.

(b) The information should be sent to the customer either automatically by the system (push) or on individual request (pull).

(c) Clients as banks, authorities and private persons get only one account.

(d) The system should provide an access-control-system.

(e) Private persons receive their username/password by e-mail.

(f) Private persons have to pay provision for publishing their information

(g) There should be the possibility to include different multimedia-elements (pic-

tures, movies, sounds,...).

5. List of possible classes: Session, User Interface, Account, Permission, Information Storage, Real Estate, Editor, Private Person, Prospective Buyer

6. New assignments: Refining the problem-statement. Discuss and act out possible use-cases. Think about the user-interface.

7. Open questions:

(a) Should permanent accounts be available for privat persons?

(b) Do private persons have to pay a fee although the object is not sold?

(c) Is it necessary to have an account to request information?

A.3 3^{rd} Lesson - November, 7^{th}, 2001

1. Groupleader: Andrea Geierspichler

2. Participating Groupmembers: Christian Koidl, Gunnar Ruhs, Roman Gross, Michael Pober

3. Topics talked about: Essential Use-Case-Definition, Essential User-Interface-Modeling

4. Use-Cases discussed:

(a) 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.

(b) 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 informationstorage. 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.

5. Essential user interface:

Homepage, subscribe screen, subscription successful, subscription error, login screen, access denied, form for placing offers, infoscreen successful, infoscreen error,

6. List of possible classes: Session, User Interface, Account, Privilege, Information Storage, Real Estate, Editor, Private Person, User, Send Account Information

7. New assignments: Present the essential use-cases and the essential user-interface using slides.

8. Open questions:

(a) How is a user able to manage his account?

(b) Is ”Privileges” necessary?