Requirements Analysis

This task includes capturing the requirements, identifying the stakeholders, and building the initial architecture of the Web service application. This task is divided into two sub-tasks, i.e. requirements elicitation and requirements specifi-cation and modelling. For each sub-task, a description of the task and how UML fits into it will be presented.

4.1.1 Requirements Elicitation

In the requirements elicitation sub-task, the requirements of the Web service ap-plication are to be identified and gathered. The requirements at this step mean identifying what services the Web service will provide. For example, a statement like”The Web service shall calculate the sum of two numbers”can represent one of the services that a Web service shall provide. Such a requirement is known asa functional requirement for the Web service. Furthermore, quality attributes can be considered as requirements, for example, availability, and reliability are types of possible requirements. Such requirements are known asnon-functional require-ments. The requirements will be collected and captured from different resources such as the users of the Web service, the domain, and current and historical data of similar Web services.

It is important to define a general function for the Web service, which represents a collective or common goal for the Web service. The function will then be decomposed into smaller functions representing the exact services provided by the Web service. The domain of the Web service application must be examined to identify special requirements imposed by the domain, as well as the constraints of business, technology, laws. The customer will play an important role in achieving this purpose. Different techniques, such as interviews and questionnaires can take place in identifying and gathering the requirements for the Web service.

4.1.2 Requirements Specification and Modelling

During and after the requirements elicitation, the specification and modelling of requirements shall take place. The modelling can be done by drawing some figures and shapes reflecting the requirements in understandable way to the customer.

The proposed WSDM uses UMLas a modelling notation for Web services. The allocation of UMLto the tasks and sub-tasks will be based on the best practises proposed by the RUP.

4.1. REQUIREMENTS ANALYSIS 71

4.1.2.1 UML Support

UML provides different types of diagrams that can be used to capture require-ments. This thesis proposes two types ofUMLdiagrams for this purpose, i.e. the use case diagram, and the class diagram.

4.1.2.1.1 Use case diagram

The initial step to model the Web service is to develop the use case diagram.

This will initially specify the boundaries of the Web service application. It also shows the services of the Web service in terms of use cases, since each one can represent one of the these services. Any use case can extend other use cases or include them. The actors in the use case diagram represent the objects outside the Web service application that exchange data with the Web service and interact with it. They either send data to the Web service application, or receive data from it, or both. The use case diagram shall be modelled in two steps, where the first step is to represent the Web service in only one use case. After that, the single use case shall be decomposed into more use cases according to the number of services in the Web service. Several steps of decomposition of use cases on multiple levels can occur. Figure 4.2 shows an example of use case diagrams for a weather Web service. The first use case diagram in Figure 4.2(A) shows one use case that represents a collective goal of the Web service. It also shows three actors, two of which represent normal client applications Client A and Client B, in addition to another Web service (Web Service X), which can also interact with the Web service. The second use case diagram in Figure4.2(B) extends and refines the first one (Figure 4.2(A)). It decomposes the use case in Figure4.2(A) into two use cases representing the exact services of the Web service. Further refinement of the use cases in other use case diagrams shall be possible. Actors remain the same, although they can be refined into more detailed actors. Each actor can request one or more of the provided services. It also shows the system boundaries by means of a rectangular shape, which distinguishes between the internal and external parts involved in the Web service.

4.1.2.1.2 Class Diagram

Class diagrams are very important in any UML model. They identify the re-quirements of Web services, define its architecture, and specify how each element serves in achieving the final goal of the Web service. In addition, they represent the objects in the Web service, such as persons, systems, units, objects and how they are associated. Class diagrams shall be used to represent the basic UML extensions for Web services proposed in the UP4WS.

Several techniques can be adopted to identify the objects in the class diagram.

One of the techniques is the commonly used Class, Responsibilities, Collaborations

72 CHAPTER 4. Web Services Development Model

uc1

[ Weather Web Service ]

Provide Weather Info

Weather Web Service

Provide Temperature Info

Provide Wind Info

Web Service X

Web Service X (B)

(A) Client A

Client A

Client B

Client B

Figure 4.2: Sample Use Case Diagrams Service Object (Weather Service)

Responsibilities Collaborations

set day temperature data object (Temperature and Wind)

provide day temperature

set night temperature proxy client object (Weather proxy client)

provide night temperature

provide average of the temperature set direction of the wind

provide direction of the wind

Table 4.1: CRCCard for Service Object

(CRC) analysis. In theCRCanalysis, nouns and verbs in the description are anal-ysed. Each noun is a candidate to be an object, while each verb is a candidate to be an operation of an object. The operations represent the responsibilities of the objects, while the associations with other objects reflect the collaborations between the objects. The collaborations represent the possible associations of the object with other objects. Table 4.1 shows a sample CRC card for the ser-vice object (e.g. Weather Service). The card is composed of two columns, the responsibilities column shows the functionalities of the Weather service such as set day temperature and provide day temperature. The other column reflects the collaborations, which represents the associations with other objects, such as Tem-perature,Wind and Weather proxy client. TheCRC cards can be done for each candidate object in the Web service to capture its complete specifications.