Domain Model Instantiation

For specifying a product line member we ideally can use the domain model pro- duced in the course of the domain analysis process without doing major

changes to it. Followingly we provide an example how a domain model can be instantiated towards a product-specific model.

For the example we assume that we want to build now the Go Phone XS which according to the Product Map (Table 3) has no attachable or insertable objects, no email or extended sms functionality, but T9 support. Therefore the decision model in Table 5 is reduced to the following resolution model:

Figure 33:GoPhone XS resolution model

The variability model for the Use Case send message is accordingly reduced to:

ID Question Subject Resolution Effect

1 Which kind of attach- ments is the phone capa- ble of? Attach- ments

no objects remove Alt 1 and 2 from step 8 in UC ’send message’;

remove Alt 1 and 2 from step 11 in UC ’show message’;

remove steps 7 to 10 from UC ’show message’; remove Alt 1 from step 6 in UC ’show mes- sage’. 2 Which kind of insert- able objects is the phone capable of?

Inserts no items remove Alt 1 and 2 from step 7 in UC ’send message’;

remove Alt 1 and 2 from step 6 in UC ’show message’.

3 T9 support? T9 yes step 6 of UC ’send message’ is obligatory; extension 6a of UC ’send message’ is obliga- tory;

step 6 of UC ’start chat’ is obligatory; extension 6a of UC ’start chat’ is obligatory. 4 Which kinds of messages are sup- ported? mes- sage types only short

messages remove step 3 of UC ’send message’;remove Alt 2 from step 11 in UC ’send mes- sage’.

Figure 34:Instanti- ated variability model for UC send message

The Use Case for this product is instantiated to: 1 Use Case name

Send message 2 Primary actor mobile user 3 Scope

Software Package of Go Phones, Messaging domain 4 Limitation

This use-case is valid for all Go Phones except Go Car. Go Car has no messaging domain.

5 Level user level

6 Stakeholders and interests

• mobile user (in the following ’user’): wants to send a newly composed text-message

send message

message recipient text editor network

phone number basic short message

normal

7 Precondition

The system shows the main menu. 8 Minimal Guarantee

The mobile keeps operating. 9 Success Guarantee

The message, entered by the user is sent via the network, so that the message reaches its destination in the same shape and content as the user typed it. 10 Main Success Scenario

1. The user chooses the menu-item to send a message. 2. The user chooses the menu-item to start a new message. 3. The system switches to a text editor.

4. The user enters the text message.

5. If T9 is activated, the system compares the entered word with the dictionary. 6. The user can not insert an item into the message.

7. The user can not attach any objects to the message. 8. The user chooses the menu-item to send the message. 9. The system asks the user for a recipient.

10. The user types the phonenumber or chooses the recipient from the address- book.

11. The system connects to the network and sends the message, then it waits for an acknowledgement.

12. The network sends an acknowledgement to the system.

13. The system shows an acknowledgement to the user that the message was succesfully sent.

14. The system asks the user if the message should be saved. If it should be saved, the system saves the message in the ‘sent-message’ folder

15. The system switches to the main menu. 11 Extensions:

2 a) The system does not have enough free memory for composing a new mes- sage. The system states an error message.

4 a) The user enters a symbol the system does not understand. The system shows the user that it does not understand the symbol (e.g. playing a beep tone).

5 a) The user enters a letter. T9 does not find a match. The system shows the user that it does not understand the word (e.g. playing a beep tone). (The user has the possibility to switch T9 off now or enter the word manually).

11 a) The system tries to connect to the network and gets no response. The sys- tem tries again after a number of milliseconds (to be specified). If this try fails again, the system states a message that the message was not sent and the mes- sage is saved in the ‘outbox’ folder.

12 a) The network does not send an acknowledgement: The system tries again after a number of milliseconds (to be specified). If this try fails again, the system states a message that the message was not sent and the message is saved in the ‘outbox’ folder.

12 b) The network sends a message that the message can not be delivered/ is invalid. The system states a message that the message was not sent and the message is saved in the ‘outbox’ folder.

There is an incoming call during the Use Case: The current status is saved and the call is displayed. After the call the saved state is reestablished.

The user can terminate the UC via a menu item after steps 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 14 and 15.

12 Non-functional requirements

• After the user chose send message the message has to be sent to the net- work within 2 sec.

• The text editor must provide easy navigation functionality (high usability). This usability is measured by the use of a customer questionnaire in which more than 60% of the questioned customers rate the usability at least ‘good’ on a scale: very bad, bad, average, good, very good. Furthermore, the time to edit one letter in a message with about 100 letters must be lower than 3 sec.

• The error-rate for sending messages should be below 0.2%. This rate does only cover errors caused by the mobile, e.g. messages that are not conform to the network-protocol.

With the help of the use cases, the feature and the decision model the require- ments on the messaging domain are now clear. With these common and vari- able requirements an architectural model con be built that covers all products of the Go-Phone product line.