Ohs

<?xml version="1.0" encoding="UTF-8"?
>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ops="http://www.idpf.org/2007/ops">
<head>
<title>Object-Oriented Analysis and Design Using UML: Student Guide</title>
<link rel="stylesheet" type="text/css" href="css/Style.css"/>
<link rel="stylesheet" type="application/vnd.adobe-page-template+xml"
href="page-template.xpgt"/>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf8"/>
<script
src="http://www.niitstudent.com/india/NDCR2/webReaderApplication.Web/JQuery_Sc
ript/jquery-1.7.1.min.js" type="text/javascript"></script>
<script
src="http://www.niitstudent.com/india/NDCR2/webReaderApplication.Web/JQuery_Sc
ript/GlobalContentSecrity.js" type="text/javascript"></script>
<script src="http://www.niitstudent.com/india/Content/analytics.js"
type="text/javascript"></script>
</head>
<body>
<h3 class="chno" id="ch04">Chapter 4</h3>
<h1 class="chname">Migrating from Requirements to Design</h1>
Work in the design phase can start after analyzing the
requirements of a software system in the requirements analysis phase. Before
starting work in the design phase, you need to determine the system boundaries
and the scope of your project so that you can complete the project within the
specified time period. In addition, you need to refine the system definition, which
was created by using use case diagrams in the initial stages of the development
process.
This chapter discusses how to determine the system
boundaries and the project scope. In addition, it explains how to refine the system
definition by refining the use case diagrams.
<h2 class="section-head2">Objectives</h2>
In this chapter, you will learn to:
<img class="inline" src="images/page.jpg"

alt=""/> Set the system boundaries and
project scope
<img class="inline" src="images/page.jpg"
alt=""/> Refine the system definition
 
<h1 class="chapter-head1" id="ch04s01">Setting Boundaries and Project
Scope</h1>
In the requirements modeling phase, you create a use case
diagram to depict the base level interaction among the actors and use cases of the
proposed system. In the design phase, you identify the iterations in which each
requirement will be implemented. In addition, you create use case diagrams to
depict the interaction among the use cases and actors in each iteration.
The use cases and actors defined for a particular iteration
might be different from the use cases and actors defined for another iteration of the
system. To depict the functions in terms of use cases and actors, you set the system
boundaries for each iteration of the system.
In addition, when you design a complex system, you may
need to divide the system into independent sub-systems. In such a case, the system
boundary enables you to clearly demarcate which sub-system is being
modeled.
After you set the system boundary, you need to establish a
scope for the software system. The scope includes estimating the resources
required to complete a project within the stipulated time.
<h2 class="section-head2" id="ch04s01s01">Identifying System Boundary</h2>
The system boundary enables you to focus on the functions
performed by the software system in each iteration. You represent the system
boundary using a rectangular box around the use cases in the use case diagram.
You place the actors outside the system boundary and put a label with the name of
the system inside the system boundary. The following figure shows the system
boundary surrounding Use Case A and Use Case B.
<img src="images/4.3.jpg" alt=""/>
The steps to identify the system boundary are:
<ol class="arabic">
<li>Prioritize the use cases of the system. The use cases that implement the basic
features of the software system have the highest priority.</li>
<li>Identify the iterations to develop the system. The first iteration includes the
basic use cases of the system and the successive iterations include the remaining
use cases according to their priority.</li>
<li>Identify the interaction among the use cases and actors of each iteration.</li>
</ol>
To identify the system boundary, consider the example of
the hospital administration system, which needs to be developed in multiple
iterations. The use cases identified for the hospital administration system at the
requirements analysis phase are:
<ul class="square">
<li>Give Appointment: Gives an appointment to the patient
using the automated voice response system.</li>
<li>Accept Fee: Accepts payment from patients for the services
of the doctor.</li>
<li>Reordering Medicines: Orders medicines whenever the
medicines reach the reorder level.</li>
<li>Print Slip: Prints the prescription on the doctor's
computer.</li>
<li>Accept Payment: Accepts payment from patients for the
purchased medicines.</li>
<li>Modify Schedule: Enables the doctor to enter new
information or modify the existing information in the schedule.</li>
</ul>
Based on the priority of use cases identified in the
requirements phase, you can identify various iterations for the hospital
administration system. For example, in the first iteration, you may decide to
implement the following requirements:
<ul class="square">
<li>Accept telephone calls from patients to give new appointments and cancel the
existing appointments.</li>
<li>Automatically modify the schedule. The doctor should be notified about the
change in schedule due to the cancellation of any appointments. If the doctor still
wants to change the schedule, then all the affected appointments should be
cancelled and the patients should be informed accordingly.</li>
</ul>
The use cases required to implement the requirements of
the first iteration are:
<ul class="square">
<li>Give Appointment</li>
<li>Modify Schedule</li>
</ul>
The Give Appointment use
case gives appointments to patients. The Modify
Schedule use case enables doctors to modify the schedule.
The actors identified for the first iteration of the hospital
administration system are:
<ul class="square">
<li>Patient</li>
<li>Doctor</li>
</ul>
The following figure depicts the use case diagram with the
system boundary for the first iteration of the hospital administration system.
<img src="images/4.5a.jpg" alt=""/>
In the second iteration, you can add the printing the
prescribed medication slip requirement to the prototype developed in the first
iteration. The Print Slip use case is required to
implement the additional requirement of the second iteration. The actors of the
second iteration are Patient and Doctor. The following figure depicts the use case diagram
with the system boundary for the second iteration of the hospital administration
system.
<img src="images/4.5b.jpg" alt=""/>
In the third iteration, you can add the following
requirements to the prototype developed in the second iteration:
<ul class="square">
<li>Accept fee from the patient for the services of the doctor</li>
<li>Print fee receipt for the patient</li>
</ul>
The use cases identified to implement the additional
requirements of the third iteration are:
<ul class="square">
<li>Accept Fee: Enables patients to use their credit cards to

make payment for the availed services of the doctor.</li>
<li>Print Fee Receipt: Enables patients to obtain a fee receipt in
return of payment.</li>
</ul>
The following figure depicts the use case diagram with the
system boundary for the third iteration of the hospital administration system.
<h4 class="note"><img src="images/note1.jpg" alt=""/></h4>
Similarly, you can create the use case diagram depicting
the system boundary for the fourth iteration of any software system.
<h2 class="section-head2" id="ch04s01s02">Establishing Project Scope</h2>
It is important to establish the project scope before you
develop the project. This ensures that all the requirements of the project are fulfilled
in time and with the available resources. The project scope is a function of:
<ul class="square">
<li>Project functions: Refer to the objectives that the
deliverable product should fulfill.</li>
<li>Project resources: Refer to the resources that are available
for project development.</li>
<li>Available time: Refers to the time in which the project
should be completed.</li>
</ul>
The project scope is achievable when the efforts required to
complete the project are equivalent to the resources available during the scheduled
time. For example, in the hospital administration system, the resources available for
the project development are centralized database, programmers, testers, and
quality assurance personnel. The centralized database maintains a schedule of
doctors. A specified period for the completion of the project has been defined. If the
development team concludes that the available resources will fulfill the objectives
of the project in the scheduled time, then the project scope for the hospital
administration system is declared as achievable.
In an iterative approach, you need to establish the project
scope for each of the iteration. To establish a project scope:
<ol class="arabic">
<li>Identify the requirements of the system.</li>
<li>Set priorities for the requirements to identify successive iterations.</li>

<li>Assess the efforts required to implement the requirements.</li>
<li>Analyze the impact of implementing each requirement of the system.</li>
</ol>
When you establish the project scope, you need to estimate
the impact of implementing each additional requirement in the project. This is
because when a new requirement is implemented in the project, the scheduled time
and/or the estimated budget of the project can be adversely affected. For example,
you can add the following requirements in successive iterations of the hospital
administration system:
<ul class="square">
<li>Check whether or not the end users, such as the receptionist and other doctors,
are authorized to access a doctor's schedule.</li>
<li>Provide a user-friendly interface at the credit card counters where the patients
make payments for medicines and doctors’ services.</li>
</ul>
The use cases identified for the preceding requirements are
Verify End User and Provide User-Friendly Interface. The impact of implementing the
use cases may be:
<ul class="square">
<li>The hospital administration system needs to maintain a database to store the
information about the end users who access the schedules of the doctors.</li>
<li>The hospital administration system needs to implement validations for the userfriendly interface to authenticate that the patients input the correct
information.</li>
</ul>
When you implement the requirements, if an absolute
measure for priorities, efforts, and impact is not available, you can provide a
relative measure. For example, you can use the terms, such as critical, important,
and useful, to indicate the priority of a requirement. The following table lists the
priorities, efforts, and impact of implementing the two additional requirements of
the hospital administration system.
<h4 class="note"><img src="images/jam.jpg" alt=""/></h4>
<h4 class="note1">Just a minute:</h4>
Which of the following refers to the objectives that the

deliverable product should fulfill?
1. Project Functions
2. Project Reports
3. System Boundary
4. Available Time
<h4 class="note6">Answer:</h4>
1. Project Functions
<h1 class="chapter-head1" id="ch04s02">Refining the System Definition</h1>
After setting system boundary and establishing the project
scope, you may need to refine the software system definition. This is because the
use cases that are defined in the initial iterations of the development process may
not be elaborate and specific due to inadequate information about the software
system. You require detailed and specific information to design, code, and test the
software system. To refine the software system definition, you refine use cases and
establish relationships among use cases.
<h2 class="section-head2" id="ch04s02s01">Refining Use Cases</h2>
The task of re-factoring and reviewing the requirements to
obtain well-defined and specific use cases is known as refining use cases. To refine
use cases, you need to perform the following steps:
<ol class="arabic">
<li>Review the actors of the use cases. This enables you to redefine the function of
the actors to make the function more specific.</li>
<li>Review the names of the use cases. This enables you to rename the use cases
to make them descriptive.</li>
<li>Refine the description of the use cases. This enables you to redefine the
functions of the use cases to make the functions more specific.</li>
<li>Define and refine the flow of events. This enables you to accurately identify the
flow of events for a use case.</li>
<li>Identify alternate paths. This enables you to identify the alternate flow of
events that you may use to achieve the functions of a use case.</li>
<li>Identify preconditions and post conditions. This enables you to identify the
conditions that must be true before the operation of a use case is triggered and the
conditions that must be true after the operation of a use case is completed.</li>
<li>Identify the non-functional requirements, such as reliability and performance of

a system.</li>
</ol>
<h4 class="section">Establishing Relationship Among Use Cases</h4>
You can also establish relationships among use cases to
further refine the software system definition. The following relationships can be
established among use cases:
<ul class="square">
<li>Extend: Indicates that an existing use case is extended
by additional behavior to obtain another use case. The extend relationship exists
among use cases when the functions of a use case, which is implemented in initial
iterations, are enhanced in successive iterations.
For example, if Use Case A is implemented in the
first iteration and is extended in the second iteration to obtain Use Case B, the two use cases have an extend relationship,
as shown in the following figure.
</li>
<li>Include: Indicates that the functions of one use case
are included in the functions of another. The include relationship exists among use
cases when the functions of a particular use case are required by another use case.
For example, if the functions of use case B are
required by Use Case A, then use case A includes
Use Case B. In such a scenario, the two use cases
have an include relationship, as shown in the following figure.
</li>
</ul>
The direction of the arrow in the extend relationship points
to the use case that is extended to obtain another use case. In addition, the
direction of the arrow in the include relationship points to the use case that is
included in another use case.
When the existing use case is executed, the extending use
case may or may not execute. However, an included use case executes whenever
the existing use case is executed.
You need to recreate the use case diagrams after
establishing extend and include relationships among use cases. For example, in the
use case diagram of the first iteration of the hospital administration system, a
Check Schedule use case needs to be created, the
functions of which are required in the functions of the Give
Appointment use case and the Modify
Schedule use case. For this reason, the Check
Schedule use case can be included in the Give
Appointment use case and the Modify
Schedule use case. The following figure depicts the new use case diagram
for the first iteration of the hospital administration system.
The second iteration use case diagram has not been
refined as it does not contain include or extend relationship.
In the third iteration, the Print Fee
Receipt and Accept Fee use cases are added
to the prototype developed in second iteration. The Print
Slip use case of the second iteration can be extended to obtain the Print Fee Receipt use case of the third iteration.
The following figure depicts the use case diagram for the
third iteration of the hospital administration system.
<h2 class="section-head2" id="ch04s02s02">Realizing Use Cases in the Design
Phase</h2>
In the implementation phase, you need to incorporate the
functions of the refined use cases into code. Therefore, in the design phase, you
need to understand how the functions of a use case can be implemented using
classes, interfaces, and sub-systems in the implementation phase. This is called
realizing use cases.
UML provides specific modeling constructs, known as
collaborations, to model use case realizations in the design phase. Collaboration is a
collection of classes, interfaces, and sub-systems that interact with each other to
achieve the functions of a use case.
The following figure shows the graphical representation of
collaboration in UML.
Collaboration represents the following aspects of use
cases:
<ul class="square">
<li>Structural: Describes the static structure of a system that

includes the role of classes, interfaces, and sub-systems in use cases.</li>
<li>Behavioral: Describes the dynamic structure of the system
that specifies the interaction among the classes, interfaces, and sub-systems of use
cases.</li>
</ul>
Consider the example of the Modify
Schedule use case of the hospital administration system. You need to
realize this use case in the design phase before its functions are implemented in the
implementation phase.
The following figure shows the association between the
Modify Schedule use case and its use case
realization.
The preceding figure indicates the Modify Schedule collaboration with its respective
participating classes. In other words, to realize the Modify
Schedule use case, you need to identify the classes, such as Appointment and Scheduler,
which will implement the functions of the use case.
<h2 class="section-head2" id="ch04s02s03">Using Use Cases for Generating Test
Cases</h2>
In the testing phase, the testers prepare test cases to
examine whether or not the implemented code of the software system complies
with the requirements stated by the customer. A test case developed for a particular
function of the software system includes a set of test input, execution conditions,
and expected results. The quality of the software system depends on the accuracy
with which test cases are designed, created, and executed.
The role of test cases in the testing phase is:
<ul class="square">
<li>Test cases form the foundation on which the test procedures are designed and
developed. Test procedures are a set of detailed instructions for the setup,
execution, and evaluation of results for a particular test case.</li>
<li>The effort required for testing is proportional to the number of test cases.</li>
<li>The design and development of tests and the resources required for the testing
depend on the test cases.</li>
</ul>
You use the use cases to generate test cases. A use case
model that records all the use cases of the system, how the use cases interact, and
how the actors initiate the use cases provides useful information for creating test
cases. The following information about use cases enables you to generate test
cases:
<ul class="square">
<li>Basic flow of events and all the alternate flows.</li>
<li>Descriptions of preconditions and post conditions for the functions of a use
case.</li>
<li>Non-functional requirements, such as performance, reliability, usability, and
supportability of the system.</li>
</ul>
A related set of test cases is known as a test
scenario.
To generate test cases from use cases, you need to perform
the following tasks:
<ol class="arabic">
<li>Identify the instances of a use case.</li>
<li>Identify the test input and expected results for each instance of the use
case.</li>
<li>Identify the conditions required to execute each use case instance.</li>
<li>Add test input values to complete the test cases.</li>
</ol>
<h4 class="section">Identifying the Instances of a Use Case</h4>
A use case instance represents the execution of the
sequence of actions that a use case specifies. You need to organize the instances of
each use case using a test matrix that should contain the following
information:
<ul class="square">
<li>The instances of each use case in a numbered list.</li>
<li>The basic and alternate flows represented by each instance of a use case.</li>
</ul>
For example, in the hospital administration system, an

instance of the Give Appointment use case represents
the following sequence of actions:
<ol class="arabic">
<li>The patient makes a call to take an appointment.</li>
<li>The software system asks for the age of the patient.</li>
<li>The patient enters the age.</li>
<li>The software system checks the schedule of the doctor and gives the
appointment accordingly.</li>
</ol>
Another instance of the Give
Appointment use case may represent the following sequence of
actions:
<ol class="arabic">
<li>The patient makes a call to take an appointment.</li>
<li>The software system asks for the age of the patient.</li>
<li>The patient enters an invalid age, such as zero.</li>
<li>The software system will generate an error and prompt the patient to enter a
valid age.</li>
</ol>
The two instances of the Give
Appointment use case can be organized in the following test matrix.
In the preceding example, only two instances have been
created. However, other instances can also be created. For example, age less than
14 and age greater than 14 are also separate instances.
<h4 class="section">Identifying the Execution Conditions for the Use Case
Instances</h4>
You need to identify the execution conditions to execute
each use case instance, and then specify the state of the execution condition. The
states that can occur for an execution condition are:
<ul class="square">
<li>Valid (V): Specifies a condition that must be true for the
basic flow of events in the use case to execute.</li>
<li>Invalid (I): Specifies a condition that invokes the alternate

flow of events in a use case.</li>
<li>Not Applicable (N/A): Indicates that the specified condition
is not applicable to a particular test case.</li>
</ul>
The execution conditions for the instances of the Give Appointment use case are:
<ul class="square">
<li>The patient enters a valid age.</li>
<li>An appointment is available in the doctors’ schedule.</li>
</ul>
The following test matrix lists the execution conditions and
their states for the instances of the Give Appointment
use case.
<h4 class="section">Adding Test Input Values</h4>
When you add test input values to the test matrix for a
particular test case, it completes the information required to execute the test case.
For example, in the hospital administration system, the test input is the age of the
patient. Therefore, the test cases can have several test input values, such as 10, 14,
and 19.
The following test matrix lists the test cases for the two
instances of the Give Appointment use case.
Each row of the preceding test matrix indicates a particular
test case and the columns indicate use case instances, execution conditions, test
input values for test cases, and expected and actual results.
The originating and alternate flows are indicated using
only the instance number. You may add the originating and alternate flows in the
test matrix.
<h2 class="section-head2" id="ch04s02s04">Tracing Requirements</h2>
In requirements traceability, the customer requirements are
mapped to the features of the software system to ensure that all the requirements
are identified correctly. The use cases are mapped to the requirements to ensure
that use cases for all the requirements are identified. The code is mapped to the use
cases to verify that the code correctly implements the functions of all the use cases.
The test cases are also mapped to the use cases to verify whether or not all the use
cases have been tested. You need to trace requirements for the following two
reasons:
<ul class="square">
<li>The customer requirements may change during the SDLC of a project.</li>
<li>The implementation of a use case in an iteration may affect the functions of the
other use cases of the system.</li>
</ul>
To perform requirements traceability, you can use the
following two approaches:
<ul class="square">
<li>Backward: Involves tracing requirements from the testing
phase to the requirement gathering phase.</li>
<li>Forward: Involves tracing requirements from the
requirement gathering phase to the testing phase.</li>
</ul>
For example, to perform backward requirements traceability
in the hospital administration system, you need to verify whether or not the
identified test cases are adequate to test all the use cases. The test case identified
for the Give Appointment use case checks whether or
not the software system performs the following actions:
<ul class="square">
<li>Asks for the age of the patient</li>
<li>Checks the schedule of the doctor</li>
<li>Gives an appointment accordingly</li>
</ul>
The code should implement all the use cases of the hospital
administration system. You need to ensure that the use cases of the hospital
administration system map to the requirements of the desired software system.
Finally, you also verify that the requirements identified map to the features of the
software system.
<h2 class="section-head2" id="ch04s02s05">Types of Use Cases used in an
Iterative Process</h2>
Use cases evolve during iterative requirements gathering.
You can create the following use cases for an iterative model:
<ul class="square">
<li>Facade use case</li>
<li>Filled use case</li>
<li>Focused use case</li>
</ul>
<h4 class="section">Facade Use Case</h4>
Facade use cases describe the
software system in three terms: information, input, and output. You can also include
actors in a facade use case. You create facade use
cases in the initial phase of the requirements gathering process and, therefore, they
capture the ad-hoc and most basic requirements for the new system. The attributes
that facade use cases contain are:
<ul class="square">
<li>Use case name: Describes the function name, which is
implemented by the use case, in the customer terminology.</li>
<li>Description: Describes the purpose and output of the use
case functions.</li>
<li>Role name: Provides additional information about the role of
the actor involved in the association relationship with the use case.</li>
<li>Input and output: Indicates the input and output of the
process modeled by the use case.</li>
</ul>
<h4 class="section">Filled Use Case</h4>
Filled use cases are evolved
from facade use cases and they contain detailed information that is not provided in
the facade use cases. The information that a filled use case contains is:
<ul class="square">
<li>Pre-conditions</li>
<li>Triggers</li>
<li>Actors</li>
<li>Basic course of events</li>
<li>Exceptions</li>
<li>Business rules</li>
</ul>
<h4 class="section">Focused Use Case</h4>

Focused use cases are
derived from the filled use cases because they eliminate redundant information. It is
pertinent to note that focused use cases describe the interaction of an actor with
the software system. Each interaction in the focused use case provides a solution to
a set of business problems. Focused use cases are clear and contain the final
requirements. There is no additional information and the focus of the system is
apparent. The activities that you should perform to create focused use cases
are:
<ul class="square">
<li>Merge duplicate processes: Merge use cases that are
dependent on each other. For example, if there is a use case that uses the functions
of another use case, then you can merge the two use cases.</li>
<li>Focus on each use case: Ensure that the use case
description is complete and provides sufficient information. In addition, make sure
that the use case depicts the interaction with other software systems.</li>
<li>Manage scope changes: Identify the use cases that cause a
change in the requirements. A change in the requirement can increase or decrease
the project scope.</li>
<li>Manage risks and assumptions: Track the risks and
assumptions that you have made to achieve the functions specified in the use
case.</li>
<li>Review: Verify whether or not the use case contains the
necessary and correct information.</li>
</ul>
<h1 class="chapter-head1" id="ch04s03">Activity: Refining the System Definition
for the InfoSuper Bank ATM System</h1>
<h4 class="section" id="ch04s03s01">Problem Statement</h4>
The InfoSuper bank needs to develop a bank ATM system to
improve the customer satisfaction level and to expand the customer base. The task
of developing the bank ATM system has been entrusted to a development team
called Janes Technologies. The project manager of Janes Technologies identifies the
following use cases for the InfoSuper bank ATM system:
<ul class="square">
<li>Cash Withdrawal: Enables the bank customer to withdraw
cash.</li>
<li>Cash Deposit: Enables the bank customer to deposit

cash.</li>
<li>Check Deposit: Enables the bank customer to deposit
checks.</li>
<li>Transaction Summary: Enables the bank customer to get a
transaction summary.</li>
<li>Change PIN: Enables the bank customer to change the
Personal Identification Number (PIN) of their account.</li>
<li>Fund Transfer: Enables the bank customer to transfer funds
within the same bank.</li>
<li>Checkbook Request: Enables the bank customer to request
for a checkbook.</li>
<li>Validation: Validates the ATM card and PIN of the bank
customer.</li>
</ul>
The actors identified for the InfoSuper bank ATM system
are:
<ul class="square">
<li>Centralized Bank System: Enables the ATM system to
validate the ATM card and PIN and verify the balance of the bank customer. It also
enables the ATM system to make transactions, such as cash withdrawal and cash
deposit. The Centralized Bank System is external to the ATM system and interacts
with the ATM system. Therefore, it is an actor.</li>
<li>Bank Customer: Requests for the various services, such as
cash withdrawal and deposit, offered by the system. In addition, the bank customer
enters the PIN number to access the services.</li>
</ul>
InfoSuper bank wants Janes Technologies to develop a
prototype of the few basic functions of the proposed software system before
proceeding with the final software development. The functions that the InfoSuper
bank wants in the ATM prototype are:
<ul class="square">
<li>The ATM should allow customers to withdraw cash from the current and savings
account.</li>
<li>The ATM should allow customers to change their PIN.</li>
<li>The ATM should allow customers to obtain a transaction summary.</li>
</ul>
The project manager of Janes Technologies, Jennifer, adopts
an iterative approach for the development of the software system. Jennifer decides
to deliver the prototype after the second iteration of the software development life
cycle. In the first iteration, Jennifer plans to implement the required functions only
for the savings accounts. In the second iteration, she plans to implement the
required functions for the current accounts as well. Before developing the prototype,
Jennifer needs to create a design for the prototype.
Prerequisite: To perform this activity,
you will need the BANK_ATM.vsd file, which you created in the
activity “Identifying Requirements and Creating a Use Case Diagram for
the Infosuper Bank” of <a class="hlink" href="09_ch03.htm">Chapter
3</a>.
<h4 class="section" id="ch04s03s02">Solution</h4>
To design the prototype for the ATM system, you need to
perform the following tasks:
<ol class="arabic">
<li>Identify the system boundary for the first iteration and create the
corresponding use case diagram.</li>
<li>Refine the use case diagram for the first iteration.</li>
<li>Identify the system boundary for the second iteration.</li>
<li>Create the use case diagram for the first and second iterations using Visio.</li>
</ol>
<h5 class="section">Task 1: Identifying the System Boundary for the First
Iteration</h5>
To identify the system boundary for the first iteration, you
need to identify the use cases and sctors. The use cases for the first iteration
are:
<ul class="square">
<li>Cash Withdrawal(Savings)</li>
<li>PIN change(Savings)</li>
<li>Transaction Summary(Savings)</li>
</ul>
The Actors for the first iteration are:
<ul class="square">
<li>Bank Customer</li>
<li>Centralized Bank System</li>
</ul>
The following figure shows the System Boundary for the first
iteration of the ATM system.
<h5 class="section">Task 2: Refine the Use Case Diagram</h5>
In the first iteration, the Cash
Withdrawal (Savings), Change PIN (Savings),
and Transaction Summary (Savings) Use Cases are
using the functions of the Validation Use Case.
Therefore, the Validation Use Case should be included
in the Cash Withdrawal (savings), Change PIN (Savings), and Transaction
Summary (Savings) Use Cases. In Visio, the
<<include>> relationship is termed as a
<<uses>> relationship. The symbol for
<<uses>> relationship in Visio is shown in the
following figure.
The Uses symbol appears as <img
src="images/symbol.jpg" alt=""/> in the UML Use Case stencil.
The following figure shows the refined use case diagram for the first iteration.
<h5 class="section">Task 3: Identifying the System Boundary for the Second
Iteration</h5>
In the first iteration, the Use Cases are implementing the
savings account function. In the second iteration, the Use Cases need to implement
the current account function. The basic function of the corresponding Use Cases in
both the iterations is the same. Notice that, the input data, such as the format for
the account number and the ATM card number, may be different. Therefore, the
functions of the Use Cases of the first iteration can be extended to obtain the Use
Cases of the second iteration. In Visio, the
<<extend>> relationship is termed as
<<extends>> relationship. The symbol for
<<extends>> relationship in Visio is shown in the
following figure.

The Extends symbol appears as <img
src="images/symbol.jpg" alt=""/> in the UML Use Case stencil.
The following figure depicts the use case diagram that
represents the system boundary for the second iteration.
When you refine the use cases, you actually reuse the
functions of the included and extended use cases. For example, the use
cases, Cash Withdrawal, Change PIN, and Transaction Summary, are reusing the functions of the
Validation Use Case. Therefore, in the Use Case diagram for the first iteration with
the refined Use Cases, the Validation Use Case is modeled as a reuse
element.
<h5 class="section">Task 4: Creating the Use Case Diagram</h5>
To create the use case diagram, you need to perform the
following tasks:
<ol class="arabic">
<li>Create the Use Case Diagram for First Iteration</li>
<li>Refine the Use Case Diagram for the First Iteration</li>
<li>Create the Use Case Diagram for the Second Iteration</li>
</ol>
<h5 class="section">Creating the Use Case Diagram for First Iteration</h5>
To create the Use Case diagram for the first iteration, you
need to perform the following steps:
<ol class="arabic">
<li>Select Start→All Programs→Microsoft
Office→Microsoft Office Visio for Enterprise Architects.</li>
<li>Open the Bank_ATM Visio file in the Microsoft
Visio window. The Bank_ATM model appears in
Visio.
The Bank_ATM file was created in the activity of <a

class="hlink" href="09_ch03.htm">Chapter 3</a>.</li>
<li>Right-click the Top Package folder in the Model
Explorer window, and select New→Package.
The UML Package Properties dialog box appears.</li>
<li>Type Iteration1 in the Name text
box, as shown in the following figure.
</li>
<li>Click the OK button. The Iteration1
folder is added and appears in the tree structure of the Model
Explorer window.</li>
<li>Right-click the Iteration1 in the Model
Explorer window, and select New→Use Case
Diagram. The Use Case-1 page with the blank
drawing page appears.</li>
<li>Draw the following use cases, actors, and their associations for the first
iteration:
The use cases for the first iteration are:
<ul class="disc">
<li>Cash Withdrawal(Savings)</li>
<li>PIN change(Savings)</li>
<li>Transaction Summary(Savings)</li>
</ul>
The Actors for the first iteration are:
<ul class="disc">
<li>Bank Customer</li>
<li>Centralized Bank System</li>
</ul>
After creating all the use cases, sctors and their association
for first iteration, the use case diagram should appear, as shown in the following
figure.
</li>
<li>Drag the System Boundary symbol (<img

src="images/system_boundary_symbol.jpg" alt=""/>) on the drawing page from the
UML Use Case (Metric) stencil, to create the System Boundary
for the first iteration. Ensure that Use Cases are placed inside the rectangle drawn
and Actors are outside the rectangle, as shown in the following figure.
You can rename the system boundary by double-clicking
on it and then typing the new name.</li>
</ol>
<h5 class="section">Refining the Use Case Diagram for the First Iteration</h5>
To refine the use case diagram for the first iteration, you
need to perform the following steps:
<ol class="arabic">
<li>Drag the Use Case symbol from the UML Use Case
(Metric) stencil inside the System Boundary on the drawing page and
rename it as Validation.</li>
<li>Connect the Validation Use Case with the
Centralized Bank System Actor using the
Communication symbol.</li>
<li>Drag the Uses symbol (<img src="images/symbol.jpg"
alt=""/>) on the drawing page from the UML Use Case
(Metric) stencil, to create a relationship between the Cash
Withdrawal (Savings) and Validation Use Cases, as shown in the following
figure.
</li>
<li>Similarly, create the include relationships between the Change PIN (Savings) and Validation Use Cases and the Transaction summary (Savings) and Validation Use Cases, as shown in the following figure.
</li>
</ol>
<h5 class="section">Creating the Use Case Diagram for the Second Iteration</h5>
To create a use case diagram for the second iteration
perform the following steps:
<ol class="arabic">
<li>Right-click the Top Package in the Model
Explorer window, and select New →Package.
The UML Package Properties dialog box appears.</li>
<li>Type the name as Iteration2 in the
Name text box and click the OK button.
Iteration2 folder is added and appears in the tree structure of
the Model Explorer window.</li>
<li>Right-click the Iteration2 in the Model
Explorer window, and select New→Use Case
Diagram. The Use Case-1 page with the blank
drawing page appears.</li>
<li>In addition to the Use Cases and Actors of the first iteration, draw the
following Use Cases for the second iteration:
The use cases for the second iteration are:
<ul class="square">
<li>Cash Withdrawal(Current)</li>
<li>PIN change(Current)</li>
<li>Transaction Summary(Current)</li>
</ul>
After creating all the use cases for second iteration, the use
case diagram should appear, as shown in the following figure.
</li>
<li>Drag the Extends symbol (<img
src="images/symbol.jpg" alt=""/>) on the drawing page from the UML Use
Case (Metric) stencil, to create a relationship between
Cash Withdrawal(Current) and Cash Withdrawal (Savings) Use Cases, as shown in
the following figure.
</li>
<li>Similarly, create the extend relationship between the Change PIN (Current)
and Change PIN (Savings) Use Cases and the Transaction summary (Current) and
Transaction summary (Savings) Use Cases, as shown in the following figure.

</li>
<li>Save and close the Bank _ATM model.</li>
<li>Close Microsoft Visio.</li>
</ol>
<h1 class="chapter-head1" id="ch04s04">Summary</h1>
In this chapter, you learned that:
<ul class="square">
<li>The system boundary enables you to identify the iterations involved in SDLC
based on the priority of use cases.</li>
<li>The scope of a project depends on the objective of the project, the available
resources, and the time specified for its completion. You need to establish the
project scope before implementing the design of the system.</li>
<li>To refine the system definition, you refine the use cases identified for the
system.</li>
<li>The extend and include relationships are established among use cases to refine
the system definition.</li>
<li>In the design phase, you realize a use case to understand how the functions of
the use case, which cannot be translated directly into code, can be achieved.</li>
<li>In UML, use case realizations are modeled using collaborations.</li>
<li>Collaboration is a collection of classes, interfaces, and subsystems that interact
to implement the functions of a use case.</li>
<li>Use cases are used to generate test cases.</li>
<li>Requirements are traced to ensure that the developed system fulfills the needs
of the customer adequately.</li>
<li>There are two approaches to trace requirements, backward and forward
requirements traceability.</li>
</ul>
<h1 class="chapter-head1" id="ch04s05">Exercises</h1>

<h4 class="section" id="ch04s05s01">Exercise 1</h4>
Blue Valley Consulting Inc. has identified two modules that
satisfy the topmost priorities of the system for its successful implementation. The
refined details of each of these modules are given.
<h5 class="section">Module 1: Maintain Tenant Details</h5>
The system should maintain information about all
leaseholders for the purpose of billing and tracking. This module will enable an
Operations Manager to enter the details whenever there is a change required in the
tenant information or a new tenant is found for leasing purpose. For each tenant,
the system should record an identification number. The data in the identification
number can be one of the following:
<ul class="square">
<li>First name, last name, and Social Security Number (SSN) of an individual</li>
<li>The company name and federal tax ID for an organization</li>
</ul>
The system will match the identification information with the
existing information and display the list of tenants, if any tenants with these details
exist. The Operations Manager can then enter the data and save the changes. If the
changes are not saved, the system will revert to the previous record. The system
will prompt the Operations Manager to enter all the mandatory data and alert him if
any duplicate entry is found. The system will not allow anyone to enter data for any
leaseholder whose lease is still active. This will ensure that the original record of the
leaseholder is not modified. This module will also store the changes made to the
tenant's records along with date and time and the name of the Operations
Manager who modified the record. It will also enable the Property Manager to query
the database to view derived data on the recorded information.
<h5 class="section">Module 2: Maintain Capital Details</h5>
This module will enable the Property Manager to view and
maintain the records of capital committed to the property. The capital includes the
revenues generated by leasing. This module will also enable the Property Manger to
enter data for the new capital and for updating existing records.
A capital investment in the automated Real Estate
Management System will be uniquely identified by the combination of the property
name, location and category, and a system-assigned serial number. The system will
display a list of investments from which Property Managers or Operations Managers
can select or enter an investment name. This module will also store the capital
amount, capital commitment schedule, estimated returns, and the time and date
when the information is modified along with the name of the Property Manager who
modified the record.
A Property Manager can also optionally enter any contact
information of people involved in the investment other than Blue Valley Consulting
Inc. The system will validate if all the mandatory information is entered and prompt
the Property Manager to enter the missing mandatory information, if any.
Prepare the use case diagrams and identify the system
boundaries for the two modules of the Real Estate Management System of the Blue
Valley Consulting Inc.
<img src="images/hint.png" alt="" id="QN03130000102"
class="hint" />
<h4 class="section" id="ch04s05s02">Exercise 2</h4>
A library maintains the record for each copy of a book until
the book is returned. A library member can issue up to six books at a time. If the
requested book is already issued, members can reserve the books in their name. A
member can also make reservations for the books over the phone or the Internet.
For the automated library management system, the following use cases need to be
implemented:
<ul class="square">
<li>Issue books: Validates the library members and checks if
the requested books can be issued to them. If the number of copies in the stock
exceeds the number of reservation requests, the book is issued. Otherwise, the
member is informed that the book is not available.</li>
<li>Extend Period: Extends the period for retaining the book.
The software system checks if there is a reservation on the book. If there is already
a reservation made for the book, the period for retaining the book is not
extended.</li>
</ul>
Draw a use case diagram for the library management
system. The use case diagram should depict the relationships, if any, that exist
among use cases.
<img src="images/hint.png" alt="" id="QN03130000103"
class="hint" />
<h1 class="chapter-head1" id="ch04s06">Reference Links</h1>
<h4 class="section">Setting Boundaries and Project Scope</h4>
<table border="1" cellspacing="0" cellpadding="6" width="100%">
<tr valign="top">
<td align="left" style="width:30%">Reference Reading:
Books</td>

URLs</td>
</tr>
<tr valign="top">
<td>Managing Software Requirements: A Use case Approach by Dean
Leffingwell Don Widrig Publisher: Addison Wesley</td>
<td><a class="hlink" href="http://www106.ibm.com/developerworks/rational/library/998.html">http://www106.ibm.com/developerworks/ rational/library/998.html</a></td>
</tr>
</table>
<h4 class="section">Refining the System Definition</h4>
<table border="1" cellspacing="0" cellpadding="6" width="100%">
<tr valign="top">
Books</td>
URLs</td>
</tr>
<tr valign="top">
<td>Managing Software Requirements: A Use case Approach by Dean
Leffingwell Don Widrig Publisher: Addison Wesley</td>
<td><a class="hlink" href="http://www106.ibm.com/developerworks/rational/library/998.html">http://www106.ibm.com/developerworks/ rational/library/998.html</a></td>
</tr>
</table>
</body>
</html>

Ohs

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ohs

Diunggah oleh

Hak Cipta:

Format Tersedia

<?xml version="1.0" encoding="UTF-8"?

<p class="hanging"><img class="inline" src="images/page.jpg"

<li><strong>Accept Fee</strong>: Enables patients to use their credit cards to

<li>Set priorities for the requirements to identify successive iterations.</li>

<p class="note4"><em>Which of the following refers to the objectives that the

<li>Identify the non-functional requirements, such as reliability and performance of

<li><strong>Structural</strong>: Describes the static structure of a system that

<p class="nonindent">For example, in the hospital administration system, an

<li><strong>Invalid (I)</strong>: Specifies a condition that invokes the alternate

<h4 class="section">Focused Use Case</h4>

<li><strong>Cash Deposit</strong>: Enables the bank customer to deposit

<p class="center"><img src="images/4.25b.jpg" alt=""/></p>

<p class="note1"><em>The Bank_ATM file was created in the activity of <a

<li><p>Drag the <strong>System Boundary</strong> symbol (<img

<p class="center"><img src="images/4.34.jpg" alt=""/></p>

<h1 class="chapter-head1" id="ch04s05">Exercises</h1>

<td align="left" style="width:70%"><strong><em>Reference Reading:

Anda mungkin juga menyukai