MCIT-DIT Sponsored National Workshop on Testing of Object Oriented Software

IBM Rational Suite Training

Better understanding

Modeling is a way of thinking about the problems using models organized around the real world ideas.

understanding of various interrelationships of a system fastest way to delineate the complex relationships easier for developers, software architects and customers to communicate on a common platform
3

 Large a

enterprise applications

way that enables

Scalability security robust execution under stressful conditions

code

reuse

There are three classifications of UML diagrams: Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams. Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams. Structure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams
6

 Version

1.x Version 2.x

Diagram Activity Diagram Class Diagram

Description Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system Shows a collection of static model elements such as classes and types, their contents, and their relationships.

Communication Diagram Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. Component Diagram Composite Structure Diagram Deployment Diagram Interaction Overview Diagram Object Diagram Package Diagram Sequence Diagram Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system. Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram. Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. Shows how model elements are organized into packages as well as the dependencies between packages. Models the sequential logic, in effect the time ordering of messages between classifiers.

State Machine Diagram Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. Timing Diagram Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events. Shows use cases, actors, and their interrelationships.
9

Use Case Diagram

WHAT WHY AND HOW !!!

10

ROSE = Rational Object Oriented Software Engineering Rational Rose is a set of visual modeling tools for development of object oriented software. Rose uses the UML to provide graphical methods for nonprogrammers wanting to model business processes as well as programmers modeling application logic. facilitates use of the Unified Modeling Language (UML), Component Object Modeling (COM), Object Modeling Technique (OMT), and Booch 93 method for visual modeling.

11

12

Modeling can be useful at any point in the application development process. Initial Design Work (Requirement Analysis and Definition) Use Cases Class Diagrams Sequence Diagram

Generality is Good in early design.

13

Refinement of Early Models (System & Software Design) Introduced in Middle of Project

Rational Rose includes tools for reverse engineering as well as forward engineering of classes and component architectures. You can gain valuable insights to your actual constructed architecture and pinpoint deviations from the original design. Rose offers a fast way for clients and new employees to become familiar with system internals
14

Browser Diagram window Diagram toolbar Documentation Window

docked/floating * Locked and unlocked modes of icons ** Customizing the tool bar
15

Overview

Rational Rose Environment

Standard menu

Standard toolbar

Diagram toolbar Browser window

(used to organize and navigate) (unique to each type of diagram)

Diagram window

Can be hidden, docked or floating Documentation window Status bar

16

 Allows
The The The The The

you to control the desk top arrangement by hiding, or displaying:

Browser Window Documentation Window Status Bar Standard Toolbar 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

17

 Right

Clicking on a Toolbar/Toolbox button allows you to:

Dock

the Toolbar Float the Toolbar Use Large Buttons Customize

If

the Toolbar/Toolbox is not visible, select it using the View Toolbars menu

18

 Under

the Tools menu item, can:

Code in

Generate

Ada Java Oracle8 C++ XML_DTD

Reverse

Engineer Models from Code Add Version Control ...

19

 Used to navigate through the models and documentation using an textual outline Expand and contract using + or - in front of the View
Select model/component

Browser may be made visible or hidden by

using the View menu, or right-clicking on an item in the Browser window.

Views from the Browser window

Browser may be docked or floating by

right-clicking on one of the items in the Browser window.

20

 Software
[PK94]

architecture consists of 5 concurrent views

Rational

Rose provides 5 different perspectives/views. Selecting a view allows users to focus only on what is architectural significant and meaningful to them View Target Audience:
Use-Case View Logical View Process View Deployment View Implementation View View in Rose: Component End User Analyst/Designer System Integrator System Engineer Programmer

[PK 94] Philippe Kruchten. Software Architecture and Iterative Development. Rational Software Corporation, Santa Clara, CA, April 1994.

21

in Rose: Component View

[RR00]
22

Views

Diagrams

23

24

 Concerned with functional requirements of 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]

25

 Presents

a perspective for the System Integrators Non-functional requirements Include:

Performance Scalability Availability Fault Tolerance Throughput Concurrency and threads processes

synchronization

Note: Not necessarily a single processing environment

26

 For

System Engineers Used only for distributed systems Captures how executables and other runtime components are to be mapped to platforms or computer nodes Includes:
Performance Scalability Availability Fault

Delivery Installation

Tolerance Deployment Diagram

27

 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

28

 Used

to create, view and modify text documenting 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 the Documentation field in the appropriate specification.

29

 Allows

you to create, update, and modify graphical views of the current model. The Diagram Toolbox is unique to the diagram type, and changes automatically when you change types of diagrams. Select a diagram or add a diagram by selecting it from those listed under the appropriate view in the Browser Window

30

 Textual

representation of a model element that permits viewing and manipulating the element's model properties Open by right clicking on a View in the Browser Window
31

 Reports
progress results errors

Right

click in the Log Window to set available action Ctrl-tab from Log Windows returns to previous diagram

32

Specification window

Log window

33

Options window

Stereotype display

34

If you want to save a Rational Rose model as a different format, you may select any of the following options from the Save As Type list in the Save Model To dialog box: Models *.mdl (the current version of Rose) Petal *.ptl Rose 6.1/6.5 Model Rose 4.5/6.5 Model Rose 4.0 Model Rose 3.0 Model If you prefer, you can modify the rose.ini file to always save in a specified format, eliminating the need to select Save As.

Difference between the saved model and workspace.

35

Hiding and Displaying the Browser Positioning the Browser

Docked and floating

Expanding and Collapsing the Browser Tree Selecting Multiple Elements in the Browser Navigating a Model Creating and Editing Model Elements Naming an Element in the Browser

36

 Use Case

Collaboration Sequence Class Statechart Activity Component Deployment

37

Creating a diagram Linking a diagram

1. Create a note on any diagram. 2. Display the browser if not already visible. 3. In the browser, locate the diagram that you want to link. 4. Drag the diagram icon from the browser onto the note icon on the diagram. As you position the cursor onto the note, you will see the shortcut symbol (a dotted square and a curved arrow inside a solid square). 5. The fully qualified name is displayed in an underline font. Note: You may need to resize the note to see the entire name. 6. Change the text in the note (if desired) to something more meaningful to your project. 7. Double-click on the note to view the linked diagram.

Displaying a diagram Rename a Diagram Deleting a diagram

38

Shallow Delete Click Edit > Delete Press CTRL + X Press the DELETE key Note: If you perform a shallow delete on an element without a name, Rational Rose will delete the model element completely out of the model. Deep Delete Click Edit > Delete from Model Press CTRL + D Right-click on an element in the browser and then select Delete from the shortcut menu
39

Capture a Business Process Model. Map a Use Case Model to the Business Process Model to define exact functionality. Refine the Use Cases - include requirements, constraints, complexity rating, notes and scenarios. From the inputs and outputs of the Business Process Model and the details of the use cases, begin to construct a domain model (high level business objects), sequence diagrams, collaboration diagrams and user interface models. From the domain model, the user interface model and the scenario diagrams create the Class Model. This is a precise specification of the objects in the system, their data or attributes and their behaviour or operations.
40

As the Class Model develops it may be broken into discrete packages and components. So from the Class Model a Component Model is built to define the logical packaging of classes. Concurrent with the work you have already done, additional requirements should have been captured and documented. The Deployment model defines the physical architecture of the system. Build the system: Take discrete pieces of the model and assign to one or more developers. In a Use Case driven build this will mean assigning a Use Case to the development team, having them build the screens, business objects, database tables, and related components necessary to execute that Use Case. Track defects that emerge in the testing phases against the related model elements - e.g.. System test defects against Use Cases, Unit Test defects against classes & etc. Track any changes against the related model elements to manage 'scope creep'. Update and refine the model as work proceeds

41

42

 To

become familiar with the Unified Modeling Language (UML) notation To create UML diagrams To review and critique UML models To use the Rational Unified Process to do objectoriented software development To use Rational Rose as a tool to develop UML documents, models, diagrams

43

 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)

44

 Introduction Requirements Gatherings Approaches Traditional Deliverables Unified Modeling Language Rational Unified Process 4+1 Architectural Views and their Deliverables

Using Rational Rose Case Study and Exercises

Use Case Model Logical View Process View Deployment View Implementation View (Component View in Rose)

45

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

46

47

 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
48

What user wanted

How customer described it

How analyst specified it

How designer implemented it

49

 Consider

flux:

a scenario illustrating the normal state of

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 a new 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 application is 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, ...?

50

 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 on requirements 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

Developing

produce a document which includes a list of requirements

a Rapid Prototype

51

Table of Requirements with review comments by Kulak & Guiney1

Requirement
The 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 The telephone system must be able to support an 800 number system

Kulak and Guiney Comments

Four access points are how; we should focus on who needs access and from where 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. and must Valuable statistics. This requirement is allow for a 15% annual growth. It is estimated that 19% of these calls actually pretty good. 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. For the calls that require access to system information, response times "optical disk" is a design assumption. for the electronic files must be less than 20 seconds for the first image Response times are good non-functional located on the optical disk, less than 3 seconds for electronic images on requirements if not linked to design a server, and less than 1 second for data files. assumptions (hardware device types).
1

Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context, AddisonWesley, New York, NY, 2000. [KG00p16-18]
52

Example Requirements List 1 (2 of 3)

Table of Requirements with review comments by Kulak & Guiney Kulak and Guiney Comments Requirement
The telephone system must be able to support voice recognition of Pretty good one. Can you find anything menu selections, touch-tone menu selections, and default to a human wrong? operator. The telephone menu will sequence caller choices in order of most frequently requested information to the least requested The telephone system must be able to provide a voice response menu going from a general menu to a secondary menu. The system must allow for the caller to provide address information through a digital recording and to indicate whether it is permanent. The system must allow for the caller to provide address information through voice recognition and to indicate whether it is permanent. This seems to be trying to provide some pretty obvious advice to a dumb designer "Through a digital recording"? This is a design assumption Sound familiar? (It's redundant)

The telephone system must be able to store and maintain processor IDs Simplify it: "The system must be able to and personal identification numbers to identify callers and to route calls identify callers and route calls to the properly to the appropriate internal response telephone. appropriate internal response telephone". The telephone system must be able to inform callers of the anticipated Great! wait time based on the number of calls, average duration of calls, and the number of calls ahead of them.

[KG00p16-18]
53

Example Requirements List 1 (3 of 3)

Table of Requirements with review comments by Kulak & Guiney Kulak and Guiney Comments Requirement
The journal will contain entries for key events that have occurred This is a design for a journal. Why have it? within the administration of an individual's account. The system will What is its purpose? 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. If an individual double-clicks on an event in a member's journal, the system will display the electronic information and the images associated with the event. Double-click is a user interface design assumption

The system will restrict options on the information bar by processor This one has many user interface design function. When an icon is clicked, the screen represented by the icon assumptions. will be displayed and the system will display appropriate participant information.

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

[KG00p16-18]
54

Example Requirements List 2 (1 of 2)

Table of Requirements with review comments by Kulak & Guiney Kulak and Guiney Comments Requirement
6.7.1.2 The system must provide the capability to capture all of the customer transactions for fiscal year Too vague. Implies fiscal year has some impact on how customer transactions are organized, but does not specify what that is. Implies some data entry, but needs to be stated more specifically. May be trying to make a statement about volume, meaning old transactions can't be archived until they are a year old?

6.7.1.3 The system will provide Saying "restricted" is OK, but details about the restriction (who can, who can't) restricted remote inquiry access should be stated clearly in this context. Also vague is the reference to remote (via dial-in) to view images and inquiry. How remote? Saying "remote access" when referring to mobile employees data separately or working in the field but still within a couple of miles of the office or worldwide simultaneously access. Can have huge implications on system. 6.7.1.4 The system will barcode Makes several technical design assumptions. Barcoding is a solution, not a documents automatically prior requirement. This system probably needs a way to identify each document to distribution. At a minimum, uniquely, but it doesn't have to be barcodes. If all existing systems use document the codes will be used to barcoding (not the case with this system), should write a nonfunctional identify to which work queue requirements that states, "Unique identification of all documents will be done the documents should be routed through barcoding". By specifying barcoding in the functional specifications, within the organization when changing to glyphs, optical character recognition (OCR) will be more difficult. The they are returned reference to queues makes an assumption about a workflow-package-oriented system. Better to state: "At a minimum, the unique id will ensure routing to a specific worker in the organization when documents are returned."

[KG00p3-7]
55

Example Requirements List 2 (2 of 2)

Table of Requirements with review comments by Kulak & Guiney Kulak and Guiney Comments Requirement
6.7.1.5 When a workflow is initiated, the Look at references to workflow. Requirements document has system must be able to prefetch the specified a workflow solution! This whole entry is suspicious. Seems documents that are in electronic image format to be saying that we must cache documents by two different criteria: by document type or grouping of documents by type or by process. Criteria are good requirements, but by process caching(prefetching) is a solution to address performance problems. 6.7.1.6 The system must create an entry in the Assumes presence of a journal file containing entries inserted when a journal file whenever a letter is created letter is created. Seems focused on front end ("do this") instead of back end ("in order to get this"). Why put entries in a journal file? To create a list of all letters created, when and by whom? This would make a better, clearer requirement. 6.7.1.7 System must maintain list of current, open work processes and identify work process to be executed and workflow queue for process. When documents are scanned, system determines whether there is a process open for that SSN. If there is, the system routes document to appropriate workflow queue, displays work process script, and highlight current work process. Seems to be focused on how rather than what. Instead of specifying the steps a system must go through, clearly document the end in mind. Example: "When a new document image is brought into the system, it should be routed to the worker who has the account open for the same SSN as the new document and should be made obvious to that worker. If no worker has an open account, the document should be made available to any worker."

[KG00p3-7]
56

Eliciting Operational Requirements

Problems 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, design constraints, quality attributes, performance factors, system interfaces and

but typically contains little or no information concerning operational 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," Software Engineering, M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, Los Alamitos, CA, 1997.

57

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 were systems-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," Software Engineering, M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, Los Alamitos, CA, 1997.

58

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]
59

Concept Analysis
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 visual forms (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 abnormal operations:
exception handling, handling incomplete data, stress load handling, handling incorrect data.
[FT97]
60

Outline for a Concept of Operations Document

1 Scope 1.1 Identification 1.2 System Overview 1.3 Document Overview 2 Referenced Documents 3 The Current System or Situation 3.1 Background, Objectives, & Scope 3.2 Operational Policies & Constraints 3.3 Description 3.4 Modes of Operation 3.5 User Classes 3.5.1 Organizational Structure 3.5.2 Profiles of User Classes 3.5.3 Interactions 3.5.4 Other Involved Personnel 3.6 Support Environment 4 Justification for and Nature of Proposed Changes & New Features 4.1 Justification 4.2 Description 4.3 Priorities among Changes/ Features 4.4 Changes/Features Considered but Not Included 4.5 Assumptions and Constraints 5 Concepts of Operations for the New or Modified Proposed System 5.1 Background, Objectives & Scope 5.2 Operational Policies & Constraints 5.3 Description of Proposed System 5.4 Modes of Operation 5.5 User Classes 5.5.1 Organization Structures 5.5.2 Profiles of User Classes Classes 5.5.3 Interactions among User 5.6 Other Involved Personnel 5.7 Support Environment Proposed Operational Scenarios Summary of Impacts 7.1 Operational Impacts 7.2 Organizational Impacts 7.3 Impacts During Developments Analysis of Proposed System 8.1 Summary of Improvements 8.2 Disadvantages & Limitations 8.3 Alternatives/Tradeoffs considered Notes, Appendices, and Glossary [FT97]
61

6 7

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

Having a prototype during requirements phase gives you something to work from when communicating with the users and client, and results in a user-centered GUI design

62

 Requirements

specifications

Hard to read. Contract-like.

Context

Diagram Diagrams (DFD) diagrams (ERD)

Specifies users, software, hardware that interface with system

Data-flow

Useful for technical people but tend to confuse users Useful in design of non-object-oriented systems

Entity-relationship

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.

63

64

 Instead

of the Context, Data-Flow and EntityRelationship 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

65

66

 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 Software Engineering: A Use 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 Unified Process, created by the "three amigos":
I. Jacobson, G. Booch and J. Rumbaugh. The Unified Software Development Process, Addison-Wesley, 1999.
67

 The

Use Cases describe the behavior of a system from 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

system other software systems/applications hardware systems/devices

Use

human users roles interact with our

Cases support the specification phase by providing a means of capturing and documenting requirements
68

 There
the

are two parts to document a use case:

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 representing each oval in the use case diagram A project should have a standard template for use cases.

69

actor

system

Real Estate System

Buyer Sell Property Seller

Advisor interaction

use case

70

Use Case Number: A unique numeric identifier

Use Case Documentation Template

Use Case Name: A unique descriptive identifier 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 ... The description of each step grows in detail as analysis progresses

Iteration: Facade (Outline and high-level description), Filled (Broader, deeper), Focused (Narrower, pruned), Finished 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: 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 5.

Alternative Paths: What happens if ... invalid information is entered, unusual types of processing occurs, or uncommon conditions occur, how is the flow completed? Exception Paths: What 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: Written 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: Facade, Filled, Focused, Finished dates

[KG0042]
71

Use Case Number: 1 Iteration: Filled

Use Case Name: Sell Property

(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: 1. 2. 3. 4. 5. 6. 7. 8. 9. System responds by notifying seller and seller's agent 10. Seller responds to the offer with a counteroffer. Seller selects an agent 11. System responds by notifying buyer and buyer's agent. System responds by assigning an agent and notifying the seller's 12. Buyer and seller agree to terms agent. 13. System responds by recording the agreement Seller lists the property to sell. System responds by displaying this property in the property listing 14. Buyer indicates a loan is required 15. System responds by locating an appropriate loan provider and linking it for searches 16. Buyer and loan provider agree to loan terms. Buyer selects an agent. 17. System responds by recording terms of loan Buyer reviews the property listings by entering search criteria 18. Buyer and seller close on property. System displays properties matching buyer's search criteria 19. System responds by recording details of close. Buyer finds a property and makes an offer on it.

Alternative Paths: N/A Exception Paths: N/A Extension Points: N/A Trigger: Assumptions: Preconditions: Postconditions: N/A N/A N/A N/A

Related Business Rules: N/A Author: Rumpel Stilskin Date: March 10, 2001 Facade; April 20, 2001 -- Filled
72

[KG00p25-26]

simpler template for Use Case documentation is recommended by Terry Quatrani [TQ98] For each use case:
X X.1 X.2 X.3 X.4 Flow of Events for the <name> Use Case Preconditions Main Flow Subflows (if applicable) Alternative Flows

[TQ98] Terry Quatrani. Visual Modeling with Rational Rose and UML, Addison-Wesley, Reading, Mass., 1998.

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

73

 Associations Types
between between between

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

of Use Case Associations

an actor and a use case, use cases, and actors

can exist

<<extend>>

<<include>>

indicates relationship between use cases in which a special use case (the non-arrow end) extends an original use case (the arrow end) reuses steps in a use case instead of cut-and-pasting steps into multiple use case documents, by pulling out common steps into a new use case and specifying with an arrowed line the <<include>> association between this new use case and those use cases requiring the steps

<<uses>>

An instance of the source use case includes behavior described by the target Shows a stereotyped generalization relationship between use cases
74

Service Representative

Customer Service Representative

Field Service Representative

[KG00p40]
75

Sell Property Buyer

Triggers
Buyer

Sell Property

76

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

Transfer by computer Remote Customer

<<extends>>
Transfer

Local Customer

<<uses>>

Identification
[PM97p97]
77

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

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

Schedule Customer Appointment Office Administrator

<<includes>>

<<extends>>
Schedule Recurring Customer Appointment

Schedule Designer

<<includes>>
Enter Customer Order

[KG00p41]
78

Problem Statement: At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about each course, such as professor, department and prerequisites are included to help students make informed decisions. The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students or fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information 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 courses they will be teaching, and to see which students signed up for their course offerings. 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 add or drop courses. Exercise: Create a Use Case Diagram and Use Case Documentation.
[TQ98p17]
79

 From

end-users' perspective Concerned with

Understandability Communication Usability

Use

Case Model

captures system's intended functions and interactions 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]

80

81

Inception Elaboration Construction 1 2 3 ... Transition

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

82

 In

the Inception Phase

Identify

actors Identify principal use cases

In

the Elaboration Phase

detailed information is added
associations stereotypes

More

Additional

use cases are added as needed

83

 Actors

are NOT part of the system. Actors represent anyone or anything that interacts with (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, and remove 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?

84

1.

2.

3. 4.

Right-click on the Use Case View package in the browser to make the shortcut menu visible. Select the NewActor menu option. A new actor called New Class will appear in the browser under Use Case View The New Class actor to the desired name Move cursor to the Documentation Window and add the documentation.
85

 Use

system that yields a measurable result of values for a particular actor

case = a sequence of transactions performed by a

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 the system? What use cases will create, store, change, remove, or read this information? Will any actor need to inform the system about sudden, external changes? Does any actor need to be informed about certain occurrences in the system? What use cases will support or maintain the system? Can all functional requirements be performed by 86 the use cases?

1. 2. 3. 4. 5.

Right-click on the Use Case View in the Browser to make shortcut menu visible. Select the NewUse Case menu option. With the unnamed use case selected, enter the desired name. Move cursor to documentation window and add a brief description. Repeat for each use case.

87

 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.
88

Develop Class Diagrams Develop Interaction Diagrams Develop State Diagrams Develop Activity Diagrams

89

 One

of the main diagram produced in the logical view is the Class Diagram. The Rational Unified Process suggests using a modelview-controller perspective to partition the system by separating the view 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 model system interfaces between the actors and the application are surrounding dependent

Boundary Classes

Control Classes

coordinate events needed to realize one or more use cases typically are application-dependent
90

 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
91

 Look

at a use case: Select Courses to Teach Select a subflow: Add a Course Offering Although the flow is written sequentially, in the real world many steps may occur concurrently
The 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 future semester (E2). The professor enters the desired semester. The system prompts the professor to select 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 offerings for 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 available at the current time. The use case begins again. E-5: A link between the professor and the course offering cannot be created. The information is saved and the system will create the link at a later time. The use case 92 continues

 What
A

is a scenario?

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]: Use Case: Signing Insurance Scenario: "John Doe contacts the system by telephone and signs for car insurance for his new
93

 Scenarios

are used to complement (not replace) and clarify a use case description in terms a user can understand 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 and alternate 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.

94

Scenario

[EP98p61]
95

[EP98p63]
96

Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves. These diagrams contain the following elements.

Classes, which represent entities with common characteristics or features. These features include attributes, operations and associations. Associations, which represent relationships that relate two or more other classes where the relationships have common characteristics or features. These attributes and operations.

97

Export Control field.

Public, private, protected, implementation

The Cardinality Concurrency

A class concurrency defines its semantics in the presence of multiple threads of control.

98

Identify Boundary Classes Identify Entity Classes Identify Control Classes Create Packages

99

 Identify
With

Boundary Classes Professor

what actors does the use case interact?

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?

100

 Domain

Classes identified:

Course CourseOffering ProfessorInformation

keeps track of professor's course assignment

101

 Add

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

102

 Classes

identified:
Classes

Group

Boundary

classes into packages:

Three Logical Groups: Interfaces UniversityArtifacts People

ProfessorCourseOptions AddACourseOffering
Entity

Classes

Course CourseOffering ProfessorInformation

Control

Classes

ProfessorCourseManager

103

Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements:

Objects, which represent particular entities. These are instances of classes. Links, which represent particular relationships between objects. These are instances of associations.

104

Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams. Sequence diagrams contain the following elements:

Class roles, which represent roles that objects may play within the interaction. Lifelines, which represent the existence of an object over a period of time. Activations, which represent the time during which an object is performing an operation. Messages, which represent communication between objects.
105

106

Collaboration Diagrams describe interactions among classes and associations. These interactions are modeled as exchanges of messages between classes through their associations. Collaboration diagrams are a type of interaction diagram. Collaboration diagrams contain the following elements.

Class roles, which represent roles that objects may play within the interaction. Association roles, which represent roles that links may play within the interaction. Message flows, which represent messages sent between objects via links. Links transport or implement the delivery of the message.
107

108

Statechart (or state) diagrams describe the states and responses of a class. Statechart diagrams describe the behavior of a class in response to external stimuli. These diagrams contain the following elements:

States, which represent the situations during the life of an object in which it satisfies some condition, performs some activity, or waits for some occurrence. Transitions, which represent relationships between the different states of an object.

109

110

Activity diagrams describe the activities of a class. These diagrams are similar to statechart diagrams and use similar conventions, but activity diagrams describe the behavior of a class in response to internal processing rather than external events as in statechart diagram.

Swimlanes, which represent responsibilities of one or more objects for actions within an overall activity; that is, they divide the activity states into groups and assign these groups to objects that must perform the activities. Action States, which represent atomic, or noninterruptible, actions of entities or steps in the execution of an algorithm. Action flows, which represent relationships between the different action states of an entity
111

112

Component diagrams describe the organization of and dependencies among software implementation components. These diagrams contain components, which represent distributable physical units, including source code, object code, and executable code.

113

114

115

116

117

References
[EP ]

used:

Hans-Erik Eriksson and Magnus Penker. UML Toolkit, John Wiley & Sons, New York, NY, 1998. ISBN 0-471-19161-2

[MF97] Martin Fowler with Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, Reading, Mass, 1997. ISBN 0-201-32563-2 [KG00] Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context, Addison-Wesley, New York, NY, 2000. ISBN 0-20165767-8 [PK 94] Philippe Kruchten. Software Architecture and Iterative Development. Rational Software Corporation, Santa Clara, CA, April 1994. [PM97] Pierre-Alain Mueller. Instant UML, WROX Press, Chicago, IL [TQ98] Terry Quatrani. Visual Modeling with Rational Rose and UML, Addison-Wesley, Birmingham, UK, 1998. ISBN 1-861000-87-1

118

 UML

Home Page http://www.platinum.com/corp/uml/uml.htm Tutorials for Rational Rose -

Online

http://www.rational.com/products/rose/gstart/online.jtmp
Rose

Whitepapers Architect E-Magazine

http://www.rational.com/products/rose/prodinfo/whitepapers/index.j

Rose

http://www.rosearchitect.com/mag/index.shtml 119

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

120