PS Software Engineering I

SE-001-2001 31st October 2001

InfoWarrior Example1

Report

Dr. Schwaiger Roland

rschwaig@cosy.sbg.ac.at

Academic Supervisor Dr. 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

InfoWarrior - Example1

Dr. Schwaiger Roland

Department of Computer Science University of Salzburg A–5020 Salzburg, Austria rschwaig@cosy.sbg.ac.at

Abstract

Our goal is to step through the whole software engineering process in order to transform the requirements of a specific problem at hand into a model which may be implemented in a subsequent step. The specific problem description is below. Through the various steps of the process, s.a. requirements modeling, analysis, design we will utilize the unified modeling language (UML). Our goal is to step through the whole software engineering process in order to transform the requirements of a specific problem at hand into a model which may be implemented in a subsequent step. The specific problem description is given below. Through the various steps of the process, s.a. requirements modeling, analysis, design we will utilize the unified modeling language (UML).

Chapter 1

Problem Statement

We were contacted by a news agency, called “e-News”. They asked us develop a system for information gathering and presentation (project name “InfoWarrior”). Potential users of the system are human data collectors and human data consumers. Other systems may, as well, play the part of data collectors and comsumers. Thus there are at least two resulting scenarios:

• The collected information is handed over to other systems either actively or passively (XML has to be used).

• The collected information is requested by human users. Thus the information has to be presented in an adequate way.

e-News noted as a prime requirement the ease of maintainance of InfoWarrior, e.g. no local installation of collection and presentation interfaces for the system. Further they want to easily change the presentation layout for human users of InfoWarrior. In the first phase of the project we are asked and required to concentrate the project to the essentials. Nevertheless InfoWarrior should easily be expandable to further requirements.

Chapter 2

CRC Session

2.1 Goals

For a detailed discussion see [1]. Class responsibility collaborator (CRC) is a low-tech method for communication between developers and business domain experts (BDE). As the prime result business requirements are understood and identified. Originally CRC cards were introduced by Beck and Cunningham ([2]) as a method for teaching object-oriented (OO) thinking. A CRC card is divided into three sections. One section holds the name, the next holds the responsibilities (data and functionality), and the third holds collaborators. Our goal in this context is to develop a CRC model^{1} for the problem given in the beginning.

2.2 CRC Session Planning

Some aspects have to be thought of planning a CRC session:

• Put together a CRC modeling team: The roles are: BDE about four in order to get a broad view and experience of the problem domain at hand, Facilitator to coordinate the session, Scribe to write down the detailed business logic, Observer a passive role.

• Organize the modeling room: Room with flip chart, whiteboard. Some index cards. A modeling table where the cards may be put and moved around. Chairs for the participants.

• Do some brainstorming: Quite important before starting the session (see [1] for relevant questions)

• Explain the CRC technique.

• Iteratively perform the steps of CRC modeling: Find classes, find responsibilities, define collaborators, define use-cases, arrange cards on table.

• Perform use-case scenario testing.

1A CRC model is a collection of CRC cards that represents whole or part of a problem domain.

2.3 Interrelationship of CRC Modeling with other Mod-

eling Techniques

IN figure 2.1 the interconnection of the CRC Model with other models is shown.

Figure 2.1: Interconnection of the CRC model with other models.

Chapter 3 Next Section

... here goes your text...

Appendix A

Protocols

A.1 31.10.2001

1. Person responsible for protocol: Schwaiger 2. Participating persons: Schwaiger

3. Topics talked about: CRC model

4. New assignments:

5. Open questions:

6. etc.

Bibliography

[1] S. W. Ambler, CRC Modeling. Bridging the Communication GAP Between Developers and Users. No. November 29, www.ambysoft.com, 1998.

[2] K. Beck and W. Cunningham, “A Laboratory for Teaching Object-Oriented Thinking.,” OOPSLA’89, pp. 1–6, 1998.