Sketch use-case diagrams to show participants in use-cases- Software Engineering
Beginning with ‘make a call’ and ‘end a call’, draw use-case diagrams to show the participants in these use-cases. Then draw other use-cases to say what other significant interactions these participants might have with each other, or with other parties.
Write postconditions for ‘make a call’ and ‘end a call’. Use this procedure:
1. Write the postcondition informally, in users’ terms.
2. Draw a before/after snapshot to illustrate the changes shown in your postcondition. Use an association or attribute to represent each fact referred to in the postcondition.
3. Write a definition of each attribute or association: ‘when this association links objects A and B, it represents the fact that…’.
4. Restate the postcondition in terms of the changes illustrated in the snapshot.
5. If there are other possible outcomes, include these in the postcondition, with the help of another snapshot if necessary.
6. Write a precondition: what must be true for this use-case to occur?
7. Add timing requirements to the use-case, where appropriate.
8. Update the type model, if necessary.
Statecharts
Draw a statechart for a Phone. The transitions should be use-cases. The states you associate with a Phone don’t have to be information recorded within the Phone itself: for example, you might have a ‘suspended’ state for phones whose bills are unpaid. As analysts, we haven’t yet decided where this information might be kept, but it’s more likely to be in the Billing Agency than the Phone itself. Nevertheless, your statechart can include it because the information is associated with the phone somewhere in the world we’re dealing with – and it certainly has an effect on the phone’s behaviour.
We’ll decide at a later design stage, where to put the information. Consider whether it might be more useful to draw a statechart for a Phone Service – that is, the service provided to a customer by various organisations through a phone. A Phone Service has similar states to a Phone; but a Phone Service may continue through the replacement of a broken Phone.
· For each state, write its definition (1) in natural language; (2) as a boolean function of other attributes and associations of Phone (or PhoneService) in your model. You may need to add new associations to the model for this purpose.
· If there are new use-cases you have found, add these to the model and draft pre/postconditions for them.
