University of Engineering and Technology, Taxila s4

UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA

FACULTY OF TELECOMMUNICATION AND INFORMATION ENGINEERING

SOFTWARE ENGINEERING DEPARTMENT

LAB 02

Case Study and procedure of extracting Use Cases for the System Design

Case Studies

Introduction to OOA/D is illustrated in some ongoing case studies that are followed throughout the book, going deep enough into the analysis and design so that some of the details of what must be considered and solved in a realistic problem are considered, and solved.

Use Cases

Use cases are text stories, widely used to discover and record requirements. They influence many aspects of a project including OOA/D and will be input to many subsequent artifacts in the case studies.OOD (and all software design) is strongly related to the prerequisite activity of requirements analysis, which often includes writing use cases. Therefore, the case study begins with an introduction to these topics, even though they are not specifically object-oriented.

This section presents a bird's-eye view of a few key steps and diagrams, using a simple example a "dice game" in which software simulates a player rolling two dice. If the total is seven, they win; otherwise, they lose.

Requirements analysis may include stories or scenarios of how people use the application; these can be written as use cases. Use cases are not an object-oriented artifact they are simply written stories. However, they are a popular tool in requirements analysis. For example, here is a brief version of the Play a Dice Game use case: Play a Dice Game: Player requests to roll the dice. System presents results: If the dice face value totals seven, player wins; otherwise, player loses. Software Requirements Engineering 3rd Semester-SE UET Taxila UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA

The client and the development team make up an important set of stakeholders in a system. One equally important part of the picture is missing, however—the user. Neither the static view nor the dynamic view shows the system's behavior from the user's point of view. Understanding that point of view is key to building systems that are both useful and usable—that is, that meet requirements and are easy (and even fun) to work with Modeling a system from a user's point of view is the job of the use case. How users will use a system drives the way you design and build it. The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders Use cases are fundamentally a text form, although they can be written using flow charts, sequence charts, Petri nets, or programming languages. Under normal circumstances, think of a use case as a collection of scenarios about system use. Each scenario describes a sequence of events. Each sequence is initiated by a person, another system, a piece of hardware, or by the passage of time. Under normal circumstances, they serve to communicate from one person to another, often to people with no special training. Simple text is, therefore, usually the best choice.

For the remaining portion of lab manual description and understanding Refer to case study CarMatch sharer from the book Schaum’s outlines second edition.

Basic Notation for Use Case:

In a use case diagram use case are drawn as an ellipse. The name of the use case is usually written inside the ellipse, but can be placed beneath it.

use case name

Use case name

Figure 2.1: Use Cases

Note: do not mix these two styles in the same model.

Use case names are text strings that contains letters, numbers and most punctuation marks except for the colon, which is used to separate use case names from the names of packages and it is good idea to keep them short.

Software Requirements Engineering 3rd Semester-SE UET Taxila UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA

Use case names are normally made up of an active verb and a noun phrase that concisely describe the behavior of the system that you are modeling.

For example:

Register Car Sharer, Match car Sharers or Record Sharing agreement are the names of use cases for the Case Study CarMatch

Register car sharer

Figure 2.2: Use Case Example

Procedure for creating UseCase using StarUML

In order to create UseCase, click [Toolbox] -> [UseCase] button and click the position where to place UseCase on the [main window]. UseCase is expressed in the forms of textual, decoration, iconic. To change UseCase's view style, select menu item under [Format] -> [Stereotype Display] or select [ ]button's combo item.

Actors

Entities that initiate sequences are called actors. The result of the sequence has to be something of use either to the actor who initiated it or to another actor.

Basic Notation for Actor:

Actor is drawn as a stick person with role name written beneath

Actor role name

Figure 2.2: Actor

When dealing with human actors, it is important to remember that the name of an actor is the name of the role that the actor performs in relation to the system and not just the job title.

For example:

In a CarMatch office there may be people with different job titles (clerk, receptionist and supervisor) who can all register new car sharers in the system. Rather than drawing three different actors ,we identify what is common to their jobs and create an actor for that role, in the case CarMatch Administrator

CarMatch Administrator

Figure 2.4: Actor Example

Procedure for creating Actor using StarUML

In order to create Actor, click [Toolbox] -> [UseCase] -> [Actor] button and click the position where to place Actor. Actor is shown in the form of stick man or rectangle with icon, that is decoration view. To display actor in decoration view, select [Format] -> [Stereotype Display] -> [Decoration] menu item or select [Decoration] item in [ ] combo button on toolbar.

Associations

Actors are connected to the use cases with which they interact, by a line that represents a relationship between the actors and the use cases. The relationship indicates that there is an association between an actor and a use case.This means that a particular system in that actor role will communicate with particular instances of the use case, in which they will participate in the sequence of events that is represented by the use case.

Figure 2.5: Association between actor and use case

Note: in practical terms; the use case will eventually be implemented as some kind of computer program and the actors will use the program by entering information, receiving information or both.

A single actor may be associated with more than one use cases or a single use case may be associated with more than one actors

Figure 2.6: Actors and Use Cases

Procedure for creating multiple UseCases used by Actor at once

In order to create multiple UseCases related to Actor at once, use shortcut creation syntax of Actor. At the Actor's quick dialog, enter UseCase's name after "-()" string. To create multiple UseCases, enter same but separate UseCase's name by "," character. And press [Enter] key. Several UseCases associated with the Actor are created and arranged vertically.

Behavior Specifications:

As mentioned above in the manual, that use case represents sequence of activities, that results in some observable outcome for the actor or actors who interact with it. The sequence of activities is documented in a behavior specification. the link to a behavior specification may be represented in a CASE tool by a link to a diagram that provides the specification. This could be a sequence diagram or a communication diagram and others. Often an internal specification is provided as a use case description. In a CASE Tool it may be possible both to enter an informal description of a use case’s behavior and to specify it formally by linking it to another diagram.

Some UML diagrams have formal rules about the syntax of textual information. This makes it possible to execute the model and simulate the system and eventually to translate the model into program code in a language such as java or C++.However, use case descriptions do not have formal syntax and you can write the descriptions in the format that is most useful to you. You may be working in an organization that has its own rules or guidelines for how use cases are documented, in which case you should abide by those guidelines .the guidelines may include the use of a template for writing use case descriptions and the sections of the template may include pre conditions and post conditions that can be formally specified in Object Constraint Language (OCL). Three common approaches to writing use case descriptions: 1. Simply to write one or few statements describing sequence of activities. For example:

You can add details for Register Car Sharer as follows

The user will enter the name, address and telephone number of the potential car sharer.For each journey that this person wants to share, the start address, the destination address, the start time and the finish time of the journey are entered.

Figure 2.7: Simple Use Case Description for Register Car Sharer

2. To list in two columns the activities of actor and the responses of the system. 3. To use a document template that contains sections for different aspects of the use case that you want to record.

In StarUML you could generate the Use Case Document and complete its description. Follow the following steps to generate the Use Case Description Document

To generate artifacts by template, it must be applicable to current working UML model. 1.Select [Tools]->[StarUML Generator...] Menu

2.In the [Select templates for generation] Page, Check templates to generate in the ListBox and Click [Next] Button.

3.To bind values with parameters, Click Button of each template item in the ListBox, and set values of parameter as you want. (Refer to Registering Template for more information about template parameters)

4.In the [Select target path] Page, Select a folder that generated artifacts will be placed and click [Next] button.

If you want to create a new folder, click [New Folder...] button and input name of the new folder.

5.In the [Generating...] Page, click [Generate] button. You can check the progress of generation and it will be logged on Logs. If you want to cancel the generation process, click [Cancel] button. When all artifacts are successfully generated, [Finish] will be enabled and clicking it will finish the artifact generation. To see generated artifacts, double-click the item that want to see in the [Generation List] then the generated artifact will be opened.

Your Use case document has been generated you can open the document and edit its details.

Study the case study of VolBank from the Schaum’outline book and identify the use cases, actors and their associations between them. Draw them give their description also.

References:

1. Schaum’s Outlines book 2nd edition 2. Writing effective use cases Addison Wesley 3. Applying UML and Patterns by Craig Larman 4. Sams teach Yourself UML in 24 Hours 3rd edition By Joseph Schmuller 5. StarUML help contents

Software Requirements Engineering 3rd Semester-SE UET Taxila