Migrating From Requirements To Design

7/21/12
Object-Oriented Analysis and Design Using UML: Student Guide
Chapter 4
Migrating from Requirements to Design
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.
Objectives
In this chapter, you will learn to: Set the system boundaries and project scope Refine the system definition
www.niitstudent.com/india/Content/063OUML1S1/OEBPS/10_ch04.htm
1/34
7/21/12
Setting Boundaries and Project Scope

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 subsystems. 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.
Identifying System Boundary

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 U s eC a s eA and U s eC a s eB .
The steps to identify the system boundary are: 1. Prioritize the use cases of the system. The use cases that implement the basic features of the software system have the highest priority.
www.niitstudent.com/india/Content/063OUML1S1/OEBPS/10_ch04.htm 2/34
7/21/12
2. 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. 3. Identify the interaction among the use cases and actors of each iteration. 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: Give Appointment: Gives an appointment to the patient using the automated voice response system. Accept Fee : Accepts payment from patients for the services of the doctor. Reordering Medicines : Orders medicines whenever the medicines reach the reorder level. Print Slip: Prints the prescription on the doctor's computer. Accept Payment: Accepts payment from patients for the purchased medicines. Modify Schedule : Enables the doctor to enter new information or modify the existing information in the schedule. 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: Accept telephone calls from patients to give new appointments and cancel the existing appointments. 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. The use cases required to implement the requirements of the first iteration are: Give Appointment Modify Schedule The G i v eA p p o i n t m e n tuse case gives appointments to patients. The M o d i f yS c h e d u l euse case enables doctors to modify the schedule. The actors identified for the first iteration of the hospital administration system are: Patient Doctor The following figure depicts the use case diagram with the system boundary for the first iteration of the hospital administration system.
3/34
7/21/12
In the second iteration, you can add the printing the prescribed medication slip requirement to the prototype developed in the first iteration. The P r i n tS l i puse case is required to implement the additional requirement of the second iteration. The actors of the second iteration are P a t i e n tand D o c t o r . The following figure depicts the use case diagram with the system boundary for the second iteration of the hospital administration system.
In the third iteration, you can add the following requirements to the prototype developed in the second iteration: Accept fee from the patient for the services of the doctor Print fee receipt for the patient The use cases identified to implement the additional requirements of the third iteration are: Accept Fee : Enables patients to use their credit cards to make payment for the availed services of the doctor.
7/21/12
Print Fee Receipt: Enables patients to obtain a fee receipt in return of payment. The following figure depicts the use case diagram with the system boundary for the third iteration of the hospital administration system.
Similarly, you can create the use case diagram depicting the system boundary for the fourth iteration of any software system.
Establishing Project Scope

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: Project functions : Refer to the objectives that the deliverable product should fulfill. Project resources : Refer to the resources that are available for project development. Available time : Refers to the time in which the project should be completed. 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
7/21/12
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: 1. 2. 3. 4. Identify the requirements of the system. Set priorities for the requirements to identify successive iterations. Assess the efforts required to implement the requirements. Analyze the impact of implementing each requirement of the system.
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: Check whether or not the end users, such as the receptionist and other doctors, are authorized to access a doctor's schedule. Provide a user-friendly interface at the credit card counters where the patients make payments for medicines and doctors services. 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: The hospital administration system needs to maintain a database to store the information about the end users who access the schedules of the doctors. The hospital administration system needs to implement validations for the user-friendly interface to authenticate that the patients input the correct information. 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.
6/34
7/21/12
Just a minute:
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 Answer: 1. Project Functions
7/34
7/21/12
Refining the System Definition

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.
Refining Use Cases

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: 1. Review the actors of the use cases. This enables you to redefine the function of the actors to make the function more specific. 2. Review the names of the use cases. This enables you to rename the use cases to make them descriptive. 3. Refine the description of the use cases. This enables you to redefine the functions of the use cases to make the functions more specific. 4. Define and refine the flow of events. This enables you to accurately identify the flow of events for a use case. 5. 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. 6. 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. 7. Identify the non-functional requirements, such as reliability and performance of a system.
Establishing Relationship Among Use Cases

You can also establish relationships among use cases to further refine the software system definition. The following relationships can be established among use cases: 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 U s eC a s e Ais implemented in the first iteration and is extended in the second iteration to obtain U s eC a s eB , the two use cases have an extend relationship, as shown in the following figure.
8/34
7/21/12
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 u s ec a s e Bare required by U s eC a s eA , then use case A includes U s eC a s eB . In such a scenario, the two use cases have an include relationship, as shown in the following figure.
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
7/21/12
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 C h e c kS c h e d u l euse case needs to be created, the functions of which are required in the functions of the G i v eA p p o i n t m e n tuse case and the M o d i f yS c h e d u l euse case. For this reason, the C h e c kS c h e d u l euse case can be included in the G i v eA p p o i n t m e n tuse case and the M o d i f yS c h e d u l euse 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 P r i n tF e eR e c e i p tand A c c e p tF e euse cases are added to the prototype developed in second iteration. The P r i n tS l i puse case of the second iteration can be extended to obtain the P r i n tF e eR e c e i p tuse case of the third iteration. The following figure depicts the use case diagram for the third iteration of the hospital administration system.
10/34
7/21/12
Realizing Use Cases in the Design Phase

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.
11/34
7/21/12
Collaboration represents the following aspects of use cases: Structural: Describes the static structure of a system that includes the role of classes, interfaces, and sub-systems in use cases. Behavioral: Describes the dynamic structure of the system that specifies the interaction among the classes, interfaces, and sub-systems of use cases. Consider the example of the M o d i f yS c h e d u l euse 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 M o d i f yS c h e d u l euse case and its use case realization.
The preceding figure indicates the M o d i f yS c h e d u l ecollaboration with its respective participating classes. In other words, to realize the M o d i f yS c h e d u l euse case, you need to identify the classes, such as A p p o i n t m e n tand S c h e d u l e r , which will implement the functions of the use case.
Using Use Cases for Generating Test Cases

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
7/21/12
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: 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. The effort required for testing is proportional to the number of test cases. The design and development of tests and the resources required for the testing depend on the test cases. 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: Basic flow of events and all the alternate flows. Descriptions of preconditions and post conditions for the functions of a use case. Non-functional requirements, such as performance, reliability, usability, and supportability of the system.
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: 1. 2. 3. 4. Identify the instances of a use case. Identify the test input and expected results for each instance of the use case. Identify the conditions required to execute each use case instance. Add test input values to complete the test cases.
Identifying the Instances of a Use Case

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: The instances of each use case in a numbered list. The basic and alternate flows represented by each instance of a use case. For example, in the hospital administration system, an instance of the G i v eA p p o i n t m e n tuse case represents the following sequence of actions: 1. The patient makes a call to take an appointment. 2. The software system asks for the age of the patient.
7/21/12
3. The patient enters the age. 4. The software system checks the schedule of the doctor and gives the appointment accordingly. Another instance of the G i v eA p p o i n t m e n tuse case may represent the following sequence of actions: 1. 2. 3. 4. The patient makes a call to take an appointment. The software system asks for the age of the patient. The patient enters an invalid age, such as zero. The software system will generate an error and prompt the patient to enter a valid age.
The two instances of the G i v eA p p o i n t m e n tuse case can be organized in the following test matrix.
In the preceding example, only two instances have been created. However, other
7/21/12
instances can also be created. For example, age less than 14 and age greater than 14 are also separate instances.
Identifying the Execution Conditions for the Use Case Instances

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: Valid (V): Specifies a condition that must be true for the basic flow of events in the use case to execute. Invalid (I): Specifies a condition that invokes the alternate flow of events in a use case. Not Applicable (N/A): Indicates that the specified condition is not applicable to a particular test case. The execution conditions for the instances of the G i v eA p p o i n t m e n tuse case are: The patient enters a valid age. An appointment is available in the doctors schedule. The following test matrix lists the execution conditions and their states for the instances of the G i v e A p p o i n t m e n tuse case.
15/34
7/21/12
Adding Test Input Values

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 G i v eA p p o i n t m e n tuse case.
7/21/12
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.
Tracing Requirements
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: The customer requirements may change during the SDLC of a project. The implementation of a use case in an iteration may affect the functions of the other use cases of the system. To perform requirements traceability, you can use the following two approaches:
7/21/12
Backward: Involves tracing requirements from the testing phase to the requirement gathering phase. Forward: Involves tracing requirements from the requirement gathering phase to the testing phase. 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 G i v eA p p o i n t m e n tuse case checks whether or not the software system performs the following actions: Asks for the age of the patient Checks the schedule of the doctor Gives an appointment accordingly 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.
Types of Use Cases used in an Iterative Process

Use cases evolve during iterative requirements gathering. You can create the following use cases for an iterative model: Facade use case Filled use case Focused use case
Facade Use Case

F a c a d euse cases describe the software system in three terms: information, input, and output. You can also include actors in a f a c a d euse 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: Use case name : Describes the function name, which is implemented by the use case, in the customer terminology. Description: Describes the purpose and output of the use case functions. Role name : Provides additional information about the role of the actor involved in the association relationship with the use case. Input and output: Indicates the input and output of the process modeled by the use case.
Filled Use Case

F i l l e duse 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:
7/21/12
Pre-conditions Triggers Actors Basic course of events Exceptions Business rules
Focused Use Case

F o c u s e duse 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: 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. 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. 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. Manage risks and assumptions : Track the risks and assumptions that you have made to achieve the functions specified in the use case. Review: Verify whether or not the use case contains the necessary and correct information.
19/34
7/21/12
Activity: Refining the System Definition for the InfoSuper Bank ATM System
Problem Statement
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: Cash Withdrawal: Enables the bank customer to withdraw cash. Cash Deposit: Enables the bank customer to deposit cash. Check Deposit: Enables the bank customer to deposit checks. Transaction Summary: Enables the bank customer to get a transaction summary. Change PIN: Enables the bank customer to change the Personal Identification Number (PIN) of their account. Fund Transfer: Enables the bank customer to transfer funds within the same bank. Checkbook Request: Enables the bank customer to request for a checkbook. Validation: Validates the ATM card and PIN of the bank customer. The actors identified for the InfoSuper bank ATM system are: 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. 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. 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: The ATM should allow customers to withdraw cash from the current and savings account. The ATM should allow customers to change their PIN. The ATM should allow customers to obtain a transaction summary. 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 Chapter 3.
7/21/12
Solution
To design the prototype for the ATM system, you need to perform the following tasks: 1. Identify the system boundary for the first iteration and create the corresponding use case diagram. 2. Refine the use case diagram for the first iteration. 3. Identify the system boundary for the second iteration. 4. Create the use case diagram for the first and second iterations using Visio. Task 1: Identifying the System Boundary for the First Iteration 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: Cash Withdrawal(Savings) PIN change(Savings) Transaction Summary(Savings) The Actors for the first iteration are: Bank Customer Centralized Bank System The following figure shows the System Boundary for the first iteration of the ATM system.
21/34
7/21/12
Task 2: Refine the Use Case Diagram In the first iteration, the C a s hW i t h d r a w a l( S a v i n g s ) ,C h a n g eP I N( S a v i n g s ) , and T r a n s a c t i o nS u m m a r y( S a v i n g s )Use Cases are using the functions of the V a l i d a t i o n Use Case. Therefore, the V a l i d a t i o nUse Case should be included in the C a s hW i t h d r a w a l ( s a v i n g s ) ,C h a n g eP I N( S a v i n g s ) , and T r a n s a c t i o nS u m m a r y( S a v i n g s ) 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
in the UML Use Case stencil.
The following figure shows the r e f i n e duse case diagram for the first iteration.
7/21/12
Task 3: Identifying the System Boundary for the Second Iteration 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
in the UML Use Case stencil.
The following figure depicts the use case diagram that represents the system boundary for the second iteration.
7/21/12
When you refine the use cases, you actually reuse the functions of the included and extended use cases. For example, the use cases, C a s hW i t h d r a w a l ,C h a n g e P I N , and T r a n s a c t i o nS u m m a r y , 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.
Task 4: Creating the Use Case Diagram To create the use case diagram, you need to perform the following tasks: 1. Create the Use Case Diagram for First Iteration 2. Refine the Use Case Diagram for the First Iteration 3. Create the Use Case Diagram for the Second Iteration Creating the Use Case Diagram for First Iteration
7/21/12
To create the Use Case diagram for the first iteration, you need to perform the following steps: 1. Select StartAll ProgramsMicrosoft OfficeMicrosoft Office Visio for Enterprise Architects . 2. 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 Chapter 3.

3. Right-click the Top Package folder in the Model Explorer window, and select NewPackage . The UML Package Properties dialog box appears. 4. Type Iteration1 in the Name text box, as shown in the following figure.
5. Click the OK button. The Iteration1 folder is added and appears in the tree structure of the Model Explorer window. 6. Right-click the Iteration1 in the Model Explorer window, and select NewUse Case Diagram. The Use Case-1 page with the blank drawing page appears. 7. Draw the following use cases, actors, and their associations for the first iteration: The use cases for the first iteration are: Cash Withdrawal(Savings)
7/21/12
PIN change(Savings) Transaction Summary(Savings) The Actors for the first iteration are: Bank Customer Centralized Bank System 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.
8. Drag the System Boundary symbol ( ) 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.
26/34
7/21/12
You can rename the system boundary by double-clicking on it and then typing the new name.
Refining the Use Case Diagram for the First Iteration To refine the use case diagram for the first iteration, you need to perform the following steps: 1. 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. 2. Connect the Validation Use Case with the Centralized Bank System Actor using the Communication symbol. 3. Drag the Uses symbol ( ) 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.
27/34
7/21/12
4. Similarly, create the include relationships between the C h a n g eP I N( S a v i n g s )and V a l i d a t i o nUse Cases and the T r a n s a c t i o ns u m m a r y( S a v i n g s )and V a l i d a t i o nU s eCases, as shown in the following figure.
Creating the Use Case Diagram for the Second Iteration To create a use case diagram for the second iteration perform the following steps:
7/21/12
1. Right-click the Top Package in the Model Explorer window, and select New Package . The UML Package Properties dialog box appears. 2. 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. 3. Right-click the Iteration2 in the Model Explorer window, and select NewUse Case Diagram. The Use Case-1 page with the blank drawing page appears. 4. 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: Cash Withdrawal(Current) PIN change(Current) Transaction Summary(Current) After creating all the use cases for second iteration, the use case diagram should appear, as shown in the following figure.
5. Drag the Extends symbol ( ) 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.
29/34
7/21/12
6. 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.
7. Save and close the Bank _ATM model.

7/21/12
8. Close Microsoft Visio.
31/34
7/21/12
Summary
In this chapter, you learned that: The system boundary enables you to identify the iterations involved in SDLC based on the priority of use cases. 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. To refine the system definition, you refine the use cases identified for the system. The extend and include relationships are established among use cases to refine the system definition. 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. In UML, use case realizations are modeled using collaborations. Collaboration is a collection of classes, interfaces, and subsystems that interact to implement the functions of a use case. Use cases are used to generate test cases. Requirements are traced to ensure that the developed system fulfills the needs of the customer adequately. There are two approaches to trace requirements, backward and forward requirements traceability.
Exercises
Exercise 1
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. Module 1: Maintain Tenant Details 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: First name, last name, and Social Security Number (SSN) of an individual The company name and federal tax ID for an organization 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
7/21/12
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. Module 2: Maintain Capital Details 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.
Exercise 2
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: 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. 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. 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.
33/34
7/21/12
Reference Links
Setting Boundaries and Project Scope

Reference Reading: Books Managing Software Requirements: A Use case Approach by Dean Leffingwell Don Widrig Publisher: Addison Wesley Reference Reading: URLs http://www-106.ibm.com/developerworks/ rational/library/998.html
Refining the System Definition

Reference Reading: Books Managing Software Requirements: A Use case Approach by Dean Leffingwell Don Widrig Publisher: Addison Wesley Reference Reading: URLs http://www-106.ibm.com/developerworks/ rational/library/998.html
34/34

Migrating From Requirements To Design

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Migrating From Requirements To Design

Încărcat de

Drepturi de autor:

Formate disponibile

7/21/12

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Setting Boundaries and Project Scope

Identifying System Boundary

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Establishing Project Scope

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Refining the System Definition

Refining Use Cases

Establishing Relationship Among Use Cases

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Realizing Use Cases in the Design Phase

Object-Oriented Analysis and Design Using UML: Student Guide

Using Use Cases for Generating Test Cases

Object-Oriented Analysis and Design Using UML: Student Guide

A related set of test cases is known as a test scenario.

Identifying the Instances of a Use Case

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Identifying the Execution Conditions for the Use Case Instances

Object-Oriented Analysis and Design Using UML: Student Guide

Adding Test Input Values

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Types of Use Cases used in an Iterative Process

Facade Use Case

Filled Use Case

Object-Oriented Analysis and Design Using UML: Student Guide

Pre-conditions Triggers Actors Basic course of events Exceptions Business rules

Focused Use Case

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

The Uses symbol appears as

in the UML Use Case stencil.

Object-Oriented Analysis and Design Using UML: Student Guide

The Extends symbol appears as

in the UML Use Case stencil.

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

The Bank_ATM file was created in the activity of Chapter 3.

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

7. Save and close the Bank _ATM model.

Object-Oriented Analysis and Design Using UML: Student Guide

8. Close Microsoft Visio.

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Object-Oriented Analysis and Design Using UML: Student Guide

Setting Boundaries and Project Scope

Refining the System Definition

S-ar putea să vă placă și