1. Welcome to M301 P2 Software Systems & their Development
Mrs. Hala Dernayka
(Subject: AOU) Tel: Sat-Wed 10:00 AM-1:00 PM
Thur 4:00 PM-8:00 PM O.H. to be set.
AOU

2. Basic Object-oriented Software Development with UML
Block 4
Basic Object-oriented Software Development with UML

3. Unit 2 Uses Cases Section 1: Simple Use Case Models
Section 2: More details on Use Case models
Section 3: Modeling user's routines
Section 4: Getting users involved

4. Simple Use Case Models Emphasis on the user:
Use Case model is important
1. Helps in modeling the requirements of a software system;
2. Acts as a discussion tool between developer and user;
3. Offers a common language for agreeing the functions of the software system.

5. The use cases for a software system are a record of the system behavior that is visible to its users.
This behavior is what the system does when responding to the events that arise from its interaction with a set of actors.
Actor is anything outside a software system that interacts with it.
Actor could be human (e.g. User) or non-human (e.g. software system, device)

6. Example: (Hotel chain)

7. A use case diagram should be:
A concise representation of the main tasks & their relevant users.
Concentrates on What system will do not on How.
Actors  in situation where two or more actors are associated with a use case, one of them must initiate the actions and the other(s) will play a passive role.
Use cases  we need to have a good idea about what each use case mean.

8. Use cases can take two forms

9. Scenarios are instances of a use case
Scenarios are instances of a use case. A use case is a related set of scenarios. Scenario describes a sequence of interaction between the system and some actors.
For a given use case there is
One main success scenario describing the flow of event leading to a successful conclusion. (e.g. Ali wants to reserve a room at Hilton for a 15/11  found & made reserve)
May be other scenarios describing alternative or additions to the main scenario. (e.g. No free room on that date present an option to Ali)
You have to record information for each use case not just for the main success scenario; but for all the relevant scenarios.

10. Description of use case should include:
Unique identifier for the use case (for traceability).
The name of the initiator actor.
Description of the goal of the use case.
A single sequence of steps describing the main success scenario.
Description of the pre- and post- conditions.

11. Example (make reservation)
Identifier and Name UC_1 Make reservation
Initiator Guest or Receptionist
Goal Reserve a room at a hotel for a guest
Pre-condition None (there are no conditions to be satisfied
prior to carrying out this use case)
Post-condition A room of the desired type will have been
reserved for the guest for the requested
period and the room will no longer be free for
that period.
Assumptions The expected initiator is a guest using an
Internet browser to perform the use case.
The guest is not already known to the hotel’s
software system (see step 5).

12. Main success scenario 1 The guest requests to make a reservation.
2 The guest selects the desired hotel, dates and type of room.
3 The hotel system provides the availability and price for the request.(An offer is made.)
4 The guest agrees to proceed with the offer.
5 The guest provides identification and contact details for the hotel system’s records.
6 The guest provides payment details.
7 The hotel system creates a reservation and gives it an identifier.
8 The hotel system reveals the identifier to the guest.
9 The hotel system creates a confirmation of the reservation and sends it to the guest.

13. Use cases in development activities
Use cases help in requirement capture (by identifying actors & tasks in the system).
Use cases help in development (by helping the developer to plan delivery times).
Use cases help in validating the system (each use case is examined to check that the system supports the functionality of the task).

14. General Observation
A good 1st step is to establish the context for the proposed system by:
Identifying the actors.
2. Investigating the behavior that each actor will expect from the proposed system  form the use cases for your model.

15. More details on Use Case models
More about actors
Actors are outside the boundary of a software system. If you need to record information about actor  include it in your class diagram.
In UML, a classifier is a discrete concept in a model. (e.g. Use Cases, actors, classes, data types)
UML provides a notation to use generalization between actors, by using the noun from the verb used to identify the use case.

16. Roles that People Play

17. Modeling the relationship between use cases
There are two situations when you consider adding new use cases to your diagram :
1:To identify a common task between two or more use cases.
2:To record any alternatives or additions to the main success scenario.
What is a stereotype?
A stereotype is a way of attaching extra classifications to a model. It can be user-defined  a way of extending the UML <<….>> 

18. UML notation denote Purpose Example Advantages
Two stereotypes
UML notation
<<include>>
<<extend>>
denote
Indicates a situation where a use case is reused.
Indicates a conditional extension to the original use case  alternative behavior.
Purpose
To demonstrate commonality between tasks  reuse can be achieved.
To separate out a special case.
Example
Record the shared behavior in a new use case and connect it to the use cases that it came from with an open-headed, dashed arrow.
You should add a condition to each extension point to specify when the behavior will be included.
Advantages
Simplify the original use cases  easier to understand.
Reusability.

19. <<include>>

20. <<extend>>
Case 1

21. <<extend>>
Case 2

22. Problems with use cases
The main source of confusion for the developer who has been asked to produce a use case diagram for a potential software system is the separation of the problem from its potential solution.
Problems rose when a software system is developed from a set of use cases
System may end up being a top-down function-oriented system  Inflexible & difficult to maintain
Possibility of missing source requirements because not all the requirements will emerge in this process.

23. Conclusion
A developer should use more than one model of a proposed system. (e.g. class modeling should be performed alongside use case modeling since one informs the other).
Use cases help mainly with requirements capture & testing but not with the design.
Many tasks involved in preparing a use case diagram:
Identifying actors
Analyze the behavior that each actor expects from system (identify use cases)
Identify common behavior and variations (<<include>> and <<extend>>)
Draw a model (use cases, actors, relationship between them)
Improve your model as you learn more about requirements

24. Modeling user's routines
Understanding the problem domain
Each use case represent a task: consists of a number of actions to complete the task.
An activity diagram is used to model the coordination and sequencing of actions in order to achieve a given purpose. Can also be extended to show which actor is responsible for which activity.
Help investigate the flow of control from one activity to another.
Help in understanding the basic behavior of a system.
Can be used to model concurrent systems.
Can record scenarios of use cases.

25. Example

26. Activity diagrams & workflows
Activity diagram can help: Identifying the stages at which the actors require some interaction with the proposed software system
Workflow  a flow of activities.
To model a workflow it is possible to identify which actor is responsible for a particular activity  by partitioning an activity diagram into swimlanes (one swimlane for each role)

27. Example

28. Getting users involved
Prototyping for and with user
The main uses of prototyping:
A way to improve the analysis of requirements
Help with design of user interface
Getting users involved with the development of the software system  Minimize misunderstanding & errors.

29. Activity diagram for the prototyping process: A prototype is not intended to be a complete working version of the software system.

30. General Note: Final Note:
No single type of model is adequate to describe a good software system.
You need a variety of types of model since each model type has its own strengths & weaknesses.
Final Note:
This Block depends on your reading of more examples to achieve good understand of the material concepts…

31. End of the Second meeting