UMLand RationalRose

8/3/2019 UMLand RationalRose

http://slidepdf.com/reader/full/umland-rationalrose 1/87

UML and Rational Rose NotesUML and Rational Rose Notes B.I.T.,MESRA 1

UML and Rational Rose Notes




Objectives

To become familiar with the Unified ModelingLanguage (UML) notation

To create UML diagrams

To review and critique UML models To use the Rational Unified Process to do

object-oriented software development

To use Rational Rose as a tool to developUML documents, models, diagrams




Requirements

Introductory knowledge of object-oriented

terminology and concepts

Have used some techniques for finding classes,

attributes, and associations (e.g., CRC, Shlaer-Mellor, Coad-Yourdon)




Organization

Introduction ± Requirements Gatherings Approaches ± Traditional Deliverables

Unified Modeling Language

± Rational Unified Process ± 4+1 Architectural Views and their Deliverables Use Case Model Logical View Process View

Deployment View Implementation View (Component View in Rose)

Using Rational Rose ± Case Study and Exercises




Introduction

Requirements Gatherings ± Goals and Challenges

± Standard Approaches

± Example Requirements List

± Documenting Operational Requirements Traditional Deliverables ± Requirements Specification Documents

± Analysis Diagrams:

Context Diagram, Entity Relationship Diagram,

Data/Control Flow Diagram

± Prototype




Requirements Gathering




Goals of Requirements Gathering

Find out what the users need

Document needs in a Requirements Specification

± Avoid premature design assumptions

± Resolve conflicting requirements ± Clarify ambiguous requirements

± Eliminate redundant requirements

± Discover incomplete or missing requirements

± Separate functional from nonfunctional requirements Ensure Requirements Traceability




Requirement Specifications seldom

clearly capture customer needs

What user wanted How customer described it How analyst specified it How designer implemented it




Challenges in Requirements Gathering

Consider a scenario illustrating the normal state of flux:Often you are using new business procedures, and

your job has changed to head development of a brand

new application your company has announced, and

you are scheduling training for you and your team to master anew computer environment and new software development techniques and new tools using a new programming language,

how do you figure out and document how the new applicationis supposed to work in a way that is clearly understood by:

end users, analysts, training staff customers, designers, support staff marketing staff, implementers, maintenance staff,managers, testers, . . . ?




Standard Approaches for Requirements Gathering

Elicit requirements through user interviews

Gathering representatives of stakeholders:

* executives developers maintenance

users support staff ...

in one room at during uninterrupted session(s) to decide onrequirements under an experienced leader/consensus maker:

Joint requirements planning (JRP)

focus on what the system will do

Joint application design (JAD) focus on how the system will work

produce a document which includes a list of requirements

Developing a Rapid Prototype




Example Requirements List 1 (1 of 3)Table of Requirements with review comments by Kulak & Guiney1

1 Daryl Kulak and Eamonn Guiney. U se Cases: Requirements in Context , Addison-Wesley, NewYork, NY, 2000.

[KG00p16-18]

Requirement Kulak and Guiney CommentsThe system will support client inquiries from 4 access points: in

person, paper-based mail, voice communication, and electronic

communication (Internet, dial-up, and LAN/WAN

Four access points are how; we should

focus on who needs access and from

where

The telephone system must be able to support an 800 number system Can't use 888 or 877? Missing who needs

what kind of access from where

The telephone system must be able to handle 97,000 calls/yr. andmust allow for a 15% annual growth. It is estimated that 19% of

these calls will be responded to in an automated manner and 81%

will be routed to call center staff for response. 50% of calls can be

processed without reference to the electronic copy of the paper file,

and approximately 50% will require access to system files.

Valuable statistics. This requirement isactually pretty good.

For the calls that require access to system information, response

times for the electronic files must be less than 20 seconds for the

first image located on the optical disk, less than 3 seconds for electronic images on a server, and less than 1 second for data files.

"optical disk" is a design assumption.

Response times are good non-functional

requirements if not linked to designassumptions (hardware device types).




Table of Requirements with review comments by Kulak & Guiney

[KG00p16-18]

Requirement Kulak and Guiney CommentsThe telephone system must be able to support voice recognition of

menu selections, touch-tone menu selections, and default to a human

operator. The telephone menu will sequence caller choices in order

of most frequently requested information to the least requested

Pretty good one. Can you find anything

wrong?

The telephone system must be able to provide a voice response

menu going from a general menu to a secondary menu.

This seems to be trying to provide some

pretty obvious advice to a dumb designer

The system must allow for the caller to provide address information

through a digital recording and to indicate whether it is permanent.

"Through a digital recording"? This is a

design assumption

The system must allow for the caller to provide address information

through voice recognition and to indicate whether it is permanent.

Sound familiar? (It's redundant)

The telephone system must be able to store and maintain processor

IDs and personal identification numbers to identify callers and to

route calls properly to the appropriate internal response telephone.

Simplify it: "The system must be able to

identify callers and route calls to the

appropriate internal response telephone".The telephone system must be able to inform callers of the

anticipated wait time based on the number of calls, average duration

of calls, and the number of calls ahead of them.

Great!

Example Requirements List 1 (2 of 3)




Table of Requirements with review comments by Kulak & Guiney

Note: Each requirement should have a number to provide traceability.

[KG00p16-18]

Requirement Kulak and Guiney CommentsThe journal will contain entries for key events that have occurred

within the administration of an individual's account. The system

will capture date, processor ID, and key event description. The

system will store pointers to images that are associated with a

journal entry as well as key data system screens that contain more

information regarding the entry.

This is a design for a journal. Why have

it? What is its purpose?

If an individual double-clicks on an event in a member's journal, thesystem will display the electronic information and the images

associated with the event.

Double-click is a user interface designassumption

The system will restrict options on the information bar by processor

function. When an icon is clicked, the screen represented by the

icon will be displayed and the system will display appropriate

participant information.

This one has many user interface design

assumptions.

Example Requirements List 1 (3 of 3)




Eliciting Operational RequirementsProblems with traditional ways of specifying problems:

1. customer may not adequately convey the needs of the user.

2. developer may not be an expert in the application domain,which inhibits communications.

3. users and customers may not understand the requirements

produced by the developer 4. developer's requirements specifications typically specifies

system attributes such as functions, performance factors, design constraints, system interfaces and quality attributes,

but typically contains little or no information concerningoperational characteristics of the specified system.

[FT97] R. E. Fairley and R. H. Thayer, "The Concept of Operations: The Bridge from Operational Requirements to Technical

Specifications," S oftware Engineering , M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, Los Alamitos,CA, 1997.




Guidelines for Operational Concept Document

Operational Concept

Document (OCD) describes the mission of the system, its operational and support environments, and the

functions and characteristics of the computer system within an

overall system.

Several guidelines and standards exist to prepare an OCD:

Mil-Std 498 for Department of Defense SW development

IEEE Standard 1498 for commercial SW development,

AIAA OCD 1992 for the American Inst. of Aeronautics and Astronautics

(for embedded real-time systems)

ConOps 1997 Concept of Operations Document Guidelines proposed by

Fairley and Thayer [FT97] because they felt the above guidelines weresystems-oriented and developer-oriented instead of user-oriented.

[FT97] R. E. Fairley and R. H. Thayer, "The Concept of Operations: The Bridge from Operational Requirements to Technical

Specifications," S oftware Engineering , M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, LosAlamitos, CA, 1997.




The Concept of Operations Document

Identifies classes of users and modes of operation

normal mode emergency mode maintenance mode backup mode degraded mode diagnostic mode

Users communicate essential needs desirable needs -- prioritized optional needs -- prioritized

Prioritized user needs provide the basis for establishing an incremental development process, and making trade-offs among

operational needs, schedule and budget.

[FT97]




Concept Analysis Team, include representatives from

user organization training buyer organization operational support

developer organization or development experts/consultants

Results of concept analysis are recorded in the ConOps document

written in narrative prose using users' language, and using visualforms (diagrams, illustrations, graphs, etc.) wherever possible.

Each operational scenario needs a test scenario to validate the

system in user's environment. Validate proposed system by

walking thru all scenarios, include both normal and abnormaloperations:

exception handling, stress load handling,

handling incomplete data, handling incorrect data.

ConceptAnalysis

[FT97]




5 Concepts of Operations for the New or Modified Proposed System

5.1 Background, Objectives & Scope5.2 Operational Policies & Constraints5.3 Description of Proposed System5.4 Modes of Operation5.5 User Classes

5.5.1 Organization Structures5.5.2 Profiles of User Classes5.5.3 Interactions among User Classes

5.6 Other Involved Personnel5.7 Support Environment

6 Proposed Operational Scenarios

7 Summary of Impacts

7.1 Operational Impacts

7.2 Organizational Impacts

7.3 Impacts During Developments

8 Analysis of Proposed System

8.1 Summary of Improvements

8.2 Disadvantages & Limitations8.3 Alternatives/Tradeoffs considered

9 Notes, Appendices, and Glossary

1 Scope

1.1 Identification

1.2 System Overview1.3 Document Overview

2 Referenced Documents

3 The Current System or Situation3.1 Background, Objectives, & Scope3.2 Operational Policies & Constraints3.3 Description

3.4 Modes of Operation3.5 User Classes3.5.1 Organizational Structure3.5.2 Profiles of User Classes3.5.3 Interactions3.5.4 Other Involved Personnel

3.6 Support Environment4 Justification for and Nature of Proposed

Changes & New Features4.1 Justification

4.2 Description4.3 Priorities among Changes/ Features4.4 Changes/Features Considered but

Not Included4.5 Assumptions and Constraints

Outline for a Concept of Operations Document

[FT97]




Rapid Prototype

[www.dilbert.com 2/24/2000]

Having a prototype during requirements phase gives yousomething to work from when communicating with the

users and client, and results in a user-centered GUI design




Traditional Expressions of

Functional Requirements Requirements specifications ± Hard to read. Contract-like.

Context Diagram ± Specifies users, software, hardware that interface with system

Data-flow Diagrams (DFD) ± Useful for technical people but tend to confuse users

± Useful in design of non-object-oriented systems

Entity-relationship diagrams (ERD) ± Critical to database design but are not easily understood by users

Prototypes ± Good communication tool to elicit information from user.

± Great for proof-of-concept tasks.

± Useful in developing user interface designs.




Unified Modeling Language

(UML)




UML Diagrams

Instead of the Context, Data-Flow and Entity-Relationship Diagrams used in Structured Analysis,UML produces 9 types of diagrams

± Use Case Diagram

± Sequence Diagram ± Collaboration Diagram

± Statechart Diagram

± Activity Diagram

± Class Diagram

± Object Diagram

± Component Diagram

± Deployment Diagram




Use Cases




History of Use Cases

Ivar Jacobson and his team at Ericsson in

Sweden introduced Use Cases in their book:I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-

Oriented S oftware Engineering: A U se Case Driven Approach, ACM

Press, 1992.

Use Cases were included as part of their overall system

development lifecycle methodology, called Objectory, which

was sold to Rational Software. Now Use Cases are part of the

Rational U

nified Process, created by the "three amigos":I. Jacobson, G. Booch and J. Rumbaugh. The U nified S oftware

Development Process , Addison-Wesley, 1999.




What is a Use Case?

The Use Cases describe the behavior of a systemfrom a user's standpoint using actions and reactions.

The Use Case Diagram defines the system's boundary, and the relationships between the system

and the environment: ± different human users roles interact with our system

± other software systems/applications

± hardware systems/devices

Use Cases support the specification phase by providing a means of capturing and documentingrequirements




Use Case Deliverables

There are two parts to document a use case:

± the use case diagram,

provides visual overview of important interactions

captures scope (identifies external entities) ± the use case itself

documents in a textual form the details of the

requirements, what the use case must do.

A use case is actually a page or two of text representingeach oval in the use case diagram

A project should have a standard template for use cases.




Use Case Diagram

Buyer

Advisor

Seller

Sell Property

Real Estate System

actor

interaction

use case

system




Use Case Documentation TemplateUse Case Number: A unique numeric identifier Use Case Name: A unique descriptive identifier

Iteration: F acade (Outline and high-level description), F illed (Broader, deeper), F ocused (Narrower, pruned), F inished

Summary: Briefly state the purpose of the use case in one or two sentences to provide a high-level definition of the functionality provided by the use case.

Basic Course of Events: 4. Include the following:

4.1 What interaction the use case has with the actors

4.2 What data is needed by the use case

4.3 When and how the use case starts and ends

4.4 The normal sequence of events for the use case

4.5 The description of alternate or exceptional flows,

what happens if ...5. The description of each step grows in detail as analysis progresses

1. This is a numbered list. The use case number is used

togetherfor with this number to provide requirements

traceability

2. Write this as a flow of events describin what the system should

do, not how the system should do it.

3. Write it in the language of the domain, not technical jargon

Alternative Paths: W hat happens if ... invalid information is entered, unusual types of processing occurs, or uncommonconditions occur, how is the flow completed?

Exception Paths: W hat happens if... an error occurs, how is the flow affected?

Extension Points: Describes an <<extend>> relationship, shows steps which are extended by optional steps in another case

Trigger: Describe entry criteria for use case, may describe business need, may be time-related, or completion of other case

Assumptions: Critical section for project manager. Things (out of scope of system) you assume to be true but might not be true

Preconditions: List things that must be in place before interaction can occur. (Part of contract between use case & outside world.

Postconditions: List things that will be satisfied if use case is completed successfully. Independent of alternative paths taken.

Related Business Rules: W ritten and unwritten company business rules that relate to requirements presented in this use case

Author: This is placed at the bottom, together with the date to allow critical information to be speed read

Date: F acade, F illed, F ocused, F inished dates

[KG0042]




Use Case Documentation ExampleUse Case Number: 1 Use Case Name: Sell Property

Iteration: Filled (Four stages of iteration are Facade, Filled, Focused, and Finished)

Summary: System Context Use Case. The seller lists the property, a buyer purchases the property, and the agent guides them

through the process and offers advice, caution, and recommendations

Basic Course of Events: 9. System responds by notifying seller and seller's agent

10. Seller responds to the offer with a counteroffer.

11. System responds by notifying buyer and buyer's agent.

12. Buyer and seller agree to terms

13. System responds by recording the agreement

14. Buyer indicates a loan is required

15. System responds by locating an appropriate loan provider

16. Buyer and loan provider agree to loan terms.

17. System responds by recording terms of loan18. Buyer and seller close on property.

19. System responds by recording details of close.

1. Seller selects an agent

2. System responds by assigning an agent and notifying theseller's agent.

3. Seller lists the property to sell.

4. System responds by displaying this property in the propertylisting and linking it for searches

5. Buyer selects an agent.

6. Buyer reviews the property listings by entering search criteria7. System displays properties matching buyer's search criteria

8. Buyer finds a property and makes an offer on it.

Alternative Paths: N/A

Exception Paths: N/A

Extension Points: N/A

Trigger: N/A

Assumptions: N/A

Preconditions: N/A

Postconditions: N/A

Related Business Rules: N/A

Author: Rumpel Stilskin

Date: March 10, 2001 ± Facade; April 20, 2001 -- Filled

[KG00p25-26]




A Simpler Use Case Template

A simpler template for Use Case documentation isrecommended by Terry Quatrani [TQ98]

For each use case:

X Flow of Events for the <name> Use Case

X.1 Preconditions

X.2 Main Flow

X.3 Subflows (if applicable)

X.4 Alternative Flowswhere X is a number from 1 to the number of the usecase

[TQ98] Terry Quatrani. V isual Modeling with Rational Rose and U ML, Addison-Wesley, Reading, Mass., 1998.




Associations in Use Case Diagram Associations can exist

± between an actor and a use case,

± between use cases, and ± between actors

Types of U se Case Associations ± Communicates between actor and use case

named or unnamed relationship showing participation of actor in use case,use a solid line connecting actor to use case

± Generalization between actors ± Adornments = Stereotyped Associations between use cases <<extend>>

indicates relationship between use cases in which a special use case (thenon-arrow end) extends an original use case (the arrow end)

<<include>>reuses steps in a use case instead of cut-and-pasting steps into multiple usecase documents, by pulling out common steps into a new use case andspecifying with an arrowed line the <<include>> association between thisnew use case and those use cases requiring the steps

<<uses>>An instance of the source use case includes behavior described by the targetShows a stereotyped generalization relationship between use cases




Example of Generalization between

Use Case Actors

Service Representative

Customer Service Representative Field Service Representative

[KG00p40]




Example of Communicates

Use Case Relationship

Buyer

Sell Property

Buyer

Sell PropertyTriggers




Example <<uses>> and <<extends>>Use Case Relationships

Remote Customer

Transfer by computer

Transfer

<<extends>>Local Customer

Identification

<<uses>>

[PM97p97]

[PM97] Pierre-Alain Muller. Instant U ML, Wrox Press, Birmingham, UK.




Office Administrator

Schedule Customer

Appointment

<<extends>><<includes>>

Example <<include>> and<<extends>> Use Case Relationships

Schedule Recurring

Customer AppointmentSchedule Designer

Enter Customer Order

<<includes>>

[KG00p41]




Course Registration ExerciseProblem Statement:

At the beginning of each semester, students may request a course catalogcontaining a list of course offerings needed for the semester. Informationabout each course, such as professor, department and prerequisites areincluded to help students make informed decisions.

The new system will allow students to select four course offerings for thecoming semester. In addition, each student will indicate two alternativechoices in case a course offering becomes filled or canceled. No course

offering will have more than ten students or fewer than three students. Acourse offering with fewer than three students will be canceled. Once theregistration process is completed for a student, the registration system sendsinformation to the billing system so the student can be billed for the semester.

Professors must be able to access the online system to indicate which coursesthey will be teaching, and to see which students signed up for their courseofferings.

For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to addor drop courses.

Exercise: Create a Use Case Diagram and Use Case Documentation.

[TQ98p17]




Introduction to Rational Rose

Rational Rose 2000 (v6.5)

1 month trial version needs keywww.rational.com




Diagram

window

Diagram toolbar (unique to each

type of diagram)Browser window

(used to organizeand navigate)

Documentation

window

Standard toolbar Standard menu

Status bar

Can be hidden,

docked or floating




The View Menu

Allows you to control the desk top arrangement byhiding, or displaying:

± The Browser Window

± The Documentation Window

± The Status Bar

± The Standard Toolbar

± The Diagram Toolbox

Right clicking on one of the above items (on one of the components in them) allow the item to be

± Docked

± Floating

± Hidden




The Toolbars

Right Clicking on a Toolbar/Toolbox buttonallows you to:

± Dock the Toolbar

± Float the Toolbar ± Use Large Buttons

± Customize

If the Toolbar/Toolbox is not visible, select itusing the View Toolbars menu




The Tools Menu

Under the Tools menu item, can: ± Generate Code in

Ada

Java

Oracle8

C++

XML_DTD

± Reverse Engineer Models from Code

± Add Version Control

± ...




The Browser Window Used to navigate through the

models and documentationusing an textual outline Expand and contract using

or in front of the View

Select model/component

Browser may be madevisible or hidden by using the Viewmenu, or

right-clicking on an item in the

Browser window.

Browser may be docked or floating by right-clicking on one of the

items in the Browser window.

Views from the

Browser window

+

-




4+1 View of Software Architecture Software architecture consists of 5 concurrent views [PK94]

Rational Rose provides 5 different perspectives/views.

Selecting a view allows users to focus only on what isarchitectural significant and meaningful to them

View Target Audience:Use-Case View End User

Logical View Analyst/Designer

Process View System Integrator

Deployment View System Engineer

Implementation View Programmer

[PK 94] Philippe Kruchten. S oftware Architecture and Iterative Development . Rational Software Corporation,

Santa Clara, CA, April 1994.

in Rose: Component View




4 Views + 1 Architectural View

[RR00]

in Rose:Component View




The Use-Case View From end-users' perspective

Concerned with ± Understandability

± Communication

± Usability

Use Case Model

captures system's intended functions andinteractions with environment

± use case diagrams

± use case flow of events

± supplemental documentation

± activity diagrams (optional)

requirements specification.Use Case Model can serve as a contract between customer and developer instead of the traditional text requirement specification

A Use Case Diagram [RR00]




The Logical View

Concerned with functional requirementsof the systems

From analyst/designer

perspective Includes use case realization diagrams

class diagrams

interaction diagrams

statechart diagrams (optional) activity diagrams (optional)

A Class Diagram [RR00]




The Process View

Presents a perspective for theS ystem Integrators

Non-functional requirements

Include:

± Performance

± Scalability ± Availability

± Fault Tolerance

± Throughput

± Concurrency and synchronization threads

processes

Note: Not necessarily a single processing environment




The Deployment View

For S ystem Engineers Used only for distributed systems

Captures how executables and other run-timecomponents are to be mapped to platforms or

computer nodes Includes:

± Performance ± Delivery

± Scalability ± Installation

± Availability

± Fault Tolerance

± Deployment Diagram




The Implementation View Called Component View in Rational Rose

Aimed at Programmers

Captures organization of static software modules:

± packaging, layering, and configuration management source code files

data files components executable, etc.

Concerned with derived requirements: ± ease of development

± software management ± reuse ± constraints imposed by programming language and development tools ± sub-contracting ± off-the-shelf components




The Documentation Window

Used to create, view and modify textdocumenting a selected item.

May be visible or hidden; docked or floating

± can be changed by selecting using View menu or

right clicking on an item in the Documentation Window

The information added to the documentation

window automatically updates theDocumentation field in the appropriatespecification.




The Diagram Window

Allows you to create, update, and modifygraphical views of the current model.

The Diagram Toolbox is unique to the diagram

type, and changes automatically when youchange types of diagrams.

Select a diagram or add a diagram by selecting

it from those listed under the appropriate viewin the Browser Window




The Specification Window

Textualrepresentation of amodel element that permits viewing and

manipulating theelement's model properties

Open by rightclicking on a Viewin the Browser Window




The Log Window

Reports ± progress

± results

± errors

Right click in theLog Window to setavailable action

Ctrl-tab from LogWindows returns to previous diagram




Creating the 4+1 Views




The Rational Unified Process

Inception

Elaboration

Construction

Transition

1 2 3 ...

Inception Phase:

establish business rationale for project

decide project scope

get go-ahead from project sponsor

Elaboration Phase:

collect more detailed requirements

do high-level analysis and design establish baseline architecture

create construction plan

Construction Phase:

build, test and validate the project

Transition Phase: beta-test

tune performance

train users




Developing the Use Case View

In the Inception Phase

± Identify actors

± Identify principal use cases

In the Elaboration Phase ± More detailed information is added

associations

stereotypes

± Additional use cases are added as needed




Finding Actors Actors are NOT part of the system.

Actors represent anyone or anything that interactswith (input to or receive output from) the system

Questions to help find actors [TQ98p21-22]

± Who is interested in a certain requirement?

± Where is the system used within the organization?

± Who will benefit from the use of the system?

± Who will supply the system with information, use this information, andremove this information?

± Who will support and maintain the system?

± Does the system use an external resource? ± Does one person play several different roles?

± Do several people play the same role?

± Does the system interact with a legacy system?




Creating Actors in Rational Rose

1. Right-click on the Use Case View package in the browser to make the shortcut menu visible.

2. Select the NewActor menu option. A new actor called New Class will appear in the browser

under Use Case View

3. The New Class actor to the desired name

4. Move cursor to the Documentation Window and

add the documentation.5. Repeat until all actors are added and documented




Finding Use Cases Use case = a sequence of transactions performed by a system

that yields a measurable result of values for a particular actor The use cases = all the ways the system may be used.

Questions to help find use cases [TQ98p25]

± What are the tasks of each actor?

± Will any actor create, store, change, remove or read information in thesystem?

± What use cases will create, store, change, remove, or read thisinformation?

± Will any actor need to inform the system about sudden, externalchanges?

± Does any actor need to be informed about certain occurrences in thesystem?

± What use cases will support or maintain the system?

± Can all functional requirements be performed by the use cases?



UML and Rational Rose NotesUML and Rational Rose NotesB.I.T.,MESRA 60

Creating Use Cases in Rational Rose

1. Right-click on the Use Case View in theBrowser to make shortcut menu visible.

2. Select the NewUse Case menu option.

3. With the unnamed use case selected, enter the desired name.

4. Move cursor to documentation window and

add a brief description.5. Repeat for each use case.




Finding Flow of Events Flow of events document is typically created in the

elaboration phase

Each use case is documented with flow of events ± a description of events needed to accomplish required behavior

± written in terms of what the system should do, NOT how it should do it

± written in the domain language, not in terms of the implementation

Flow of events should include ± When and how the use case starts and ends

± What interaction the use case has with the actors

± What data is needed by the use case

± The normal sequence of events for the use case

± The description of any alternate or exceptional flows

Each project should use a standard template. ± See the previous slides in the requirements section for two suggested

templates used to document in detail each requirement.




The Use Case View

for the

Case Study:Course Registration System




The Actors In the Course Registration System, answering the

questions suggested to find actors yields: ± Students want to register for courses

± Professors want to select courses to teach

± Registrar must create the curriculum and generate a catalog for thesemester

± Registrar must maintain all the information about courses, professors,and students

± Billing System must receive billing information from the system

Actors identified from above: ± Student ± person registered/registering in classes at the University

± Professor ± person certified to teach classes at the University ± Registrar ± person who maintains the Course Registration System

± Billing System ± external software system that does student billing




Add Actors to System

[TQ98p24-25]




The Use Cases Answering the questions to find use cases yields:

± The Student actor needs to use the system to register for courses ± After the course selection process is completed, the Billing System must besupplied with billing information

± The Professor actor needs to use the system to select the courses to teachfor a semester, and must be able to receive a course roster from the system

± The registrar is responsible for the generation of the course catalog for asemester, and for the maintenance of all information about the curriculum,the students, and the professors needed by the system

Based on the needs, the following cases are identified:1. Register for courses

2. Select courses to teach

3. Request course roster

4. Maintain course information5. Maintain professor information

6. Maintain student information

7. Create course catalog[TQ98p24-25]




Add Use Cases to the SystemGive a brief description of

each use case i theDocumentation window

This is the summary

description for R egister for courses

[TQ98p28-29]




The Flow of Events E xercise: Form a team and agree on a standard

template to use for documenting flow of events for the use cases. ± Look at Quatrani's recommended template [TQ98] and

The following flow of event for the Select

Courses toTeach use case follows Quatrani'srecommended template [TQ98]

For each use case:X Flow of Events for the <name> Use Case

X.1 Preconditions

X.2 Main

Flow

X.3 Subflows (if applicable)

X.4 Alternative Flows

where X is a number from 1 to the number of the use case




The Flow of Events (1 of 4)

[TQ98p30]





[TQ98p31]





[TQ98p31-2]




Use Case Diagram (1 of 2)

[TQ98p38]




The Logical View

Develop Class Diagrams

Develop Interaction Diagrams

Develop State DiagramsDevelop Activity Diagrams




Developing the Logical View One of the main diagram produced in the logical view is the

Class Diagram. The Rational Unified Process suggests using a model-view-

controller perspective to partition the system by separating theview from the domain from the control needed by the system.

Typical Class Stereotypes:

± Entity Classes (or Domain Classes) may reflect real-world entity or may perform tasks internal to the system.

may be used in multiple applications; are surrounding independent

± Boundary Classes model system interfaces between the actors and the application

are surrounding dependent ± Control Classes

coordinate events needed to realize one or more use cases

typically are application-dependent




Top-Down or Buttom-Up?

Top-Down ± Identify Packages first, then Classes ± Right click on Logical View in the Browser, select NewPackage, or drag-

drop toolbox icon into the Class Diagram, name the package and fill

documentation. More details are added using Specification Window.

± To insert new classes into the package: Right click on the package in the Browser,and select NewClass, name the class and fill documentation description

± To insert existing classes into the package: In the Logical View in the

Browser, click on class and drag into package.

Buttom-Up ± Identify classes first, then group ± Right click on Logical View in the Browser, select NewClass, name the

class and fill documentation. Repeat until most classes are identified. ± Organize classes into groups by creating packages

± Insert the classes into the appropriate package: In the Logical View in the

Browser, click on class and drag into package

S l U C d S bFl




Select a Use Case and SubFlow Look at a use case: S elect Courses to Teach

Select a subflow: Add a Course Offering

Although the flow is written sequentially, in the real world manysteps may occur concurrentlyThe professor logs onto the Registration System and enters password. The system verifies the password is valid (E1) and prompts the professor to select the current semester or a futuresemester (E2). The professor enters the desired semester. The system prompts the professor toselect the desired activity: ADD, DELETE, REVIEW, PRINT, or QUIT. The professor chooses

ADD, the S-1: Add a Course Offering subflow is selected.

S-1 Add a Course Offering

The system displays the course screen containing a field for a course name and number. The professor enters the name and number of a course (E-3). The system displays the course offeringsfor the entered course (E-4). The professor selects a course offering. The system links the professor to the selected course offering (E-5). The use case then begins again.

E-3: An invalid course name/number is entered. The user can re-enter a valid name/number

combination or terminate the use case

E-4: Course offerings cannot be displayed. The user is informed that this option is not availableat the current time. The use case begins again.

E-5: A link between the professor and the course offering cannot be created. The information issaved and the system will create the link at a later time. The use case continues




What is a Scenario?

What is a scenario? ± A use case is a class, not an instance; it describes the

functionality as a whole and includes possible alternatives,

exceptions and errors that are possible during the execution

of the use case. ± A scenario is an instantiation of a use case or a collaboration.

It represents an actual usage of the system -- a specific

execution path through the flow of events.

Example from [EP98]:

U se Case: Signing Insurance

S cenario: "John Doe contacts the system by telephone and signs for

car insurance for his new Toyota Corolla"




Scenarios Scenarios are used to complement (not replace) and

clarify a use case description in terms a user canunderstand

A set of scenarios are used to illustrate the use case or collaboration. Make sure to select scenarios that

illustrate normal and abnormal (using exceptions andalternate flows). ± When a scenario is viewed as a use case, describe only the

external behavior toward the actors

± When a scenario is viewed as an instance of a collaboration,

describe the internal implementation of the involved classes,their operations and communications

A scenario is presented as a numbered sequence of steps.

R l ti hi b t U C




Relationship between Use Case,

Collaboration, and Scenario

Scenario

[EP98p61]




[EP98p63]




Identify Classes and Create Packages

Identify Boundary Classes

Identify Entity Classes

Identify Control Classes

Create Packages




Identify Boundary Classes

Identify Boundary Classes ± With what actors does the use case interact?

Professor

What information do we need to keep track of?

± what options is the professor allowed to use

» add, modify, delete, review, print course offering

ProfessorCourseOptions

What information do we

± Class to take care of use case subflow: AddACourseOffering

What general flows do we need to support?




Identify Entity Classes

Domain Classes identified:± Course

± CourseOffering

± ProfessorInformation keeps track of

professor's course assignment




Identify Control Classes

Add control classes to handle the flow of events for the use case:

± ProfessorCourseManager




Create Packages

Classes identified: ± Boundary Classes

ProfessorCourseOptions

AddACourseOffering

± Entity ClassesCourse

CourseOffering

ProfessorInformation

± Control ClassesProfessorCourseManager

Group classes into packages:

Three Logical Groups:

Interfaces

UniversityArtifacts

People




References

References used:[EP ] Hans-Erik Eriksson and Magnus Penker. U ML Toolkit , John Wiley & Sons, New

York, NY, 1998. ISBN 0-471-19161-2

[MF97] Martin Fowler with Kendall Scott. U ML Distilled: Applying theS tandard Object

Modeling Language, Addison-Wesley, Reading, Mass, 1997. ISBN 0-201-32563-2

[KG00] Daryl Kulak and Eamonn Guiney. U se Cases: Requirements in Context , Addison-

Wesley, New York, NY, 2000. ISBN 0-201-65767-8[PK 94] Philippe Kruchten. S oftware Architecture and Iterative Development . Rational

Software Corporation, Santa Clara, CA, April 1994.

[PM97] Pierre-Alain Mueller. Instant U ML, WROX Press, Chicago, IL

[TQ98] Terry Quatrani. V isual Modeling with Rational Rose and U ML, Addison-Wesley,

Birmingham, UK, 1998. ISBN 1-861000-87-1



UML d R ti l R N tUML d R ti l R N t

Useful URLs

http://members.aol.com/acockburn -- Alistair Cockburn's papers on use cases

UMLand RationalRose

Documents

Transcript of UMLand RationalRose