Professional Documents
Culture Documents
B.I.T.,MESRA
Objectives
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 object-oriented software development To use Rational Rose as a tool to develop UML documents, models, diagrams
UML and Rational Rose Notes
B.I.T.,MESRA
Requirements
Introductory knowledge of object-oriented terminology and concepts Have used some techniques for finding classes, attributes, and associations (e.g., CRC, ShlaerMellor, Coad-Yourdon)
B.I.T.,MESRA
Organization
Introduction
Requirements Gatherings Approaches Traditional Deliverables
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
UML and Rational Rose Notes
B.I.T.,MESRA 5
Requirements Gathering
B.I.T.,MESRA
B.I.T.,MESRA
B.I.T.,MESRA
* 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
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 The telephone system must be able to handle 97,000 calls/yr. and must 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. 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.
1 Daryl
"optical disk" is a design assumption. Response times are good non-functional requirements if not linked to design assumptions (hardware device types).
Kulak and Eamonn Guiney. Use Cases: Requirements in Context, Addison-Wesley, New York, NY, 2000. [KG00p16-18]
B.I.T.,MESRA
11
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) Simplify it: "The system must be able to identify callers and route calls to the appropriate internal response telephone". Great!
[KG00p16-18]
B.I.T.,MESRA
12
Double-click is a user interface design assumption This one has many user interface design assumptions.
[KG00p16-18]
B.I.T.,MESRA
13
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.
B.I.T.,MESRA
14
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.
B.I.T.,MESRA
15
B.I.T.,MESRA
16
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] B.I.T.,MESRA 17
Rapid Prototype
[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
UML and Rational Rose Notes
B.I.T.,MESRA 19
Requirements specifications
Hard to read. Contract-like.
Context Diagram
Specifies users, software, hardware that interface with system
Prototypes
Good communication tool to elicit information from user. Great for proof-of-concept tasks. Useful in developing user interface designs.
B.I.T.,MESRA
20
B.I.T.,MESRA
21
UML Diagrams
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
B.I.T.,MESRA 22
Use Cases
B.I.T.,MESRA
23
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.
B.I.T.,MESRA
24
Use Cases support the specification phase by providing a means of capturing and documenting requirements
UML and Rational Rose Notes
B.I.T.,MESRA 25
Buyer
Advisor interaction
use case
B.I.T.,MESRA
27
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]
B.I.T.,MESRA
28
Related Business Rules: N/A Author: Rumpel Stilskin Date: March 10, 2001 Facade; April 20, 2001 -- Filled
[KG00p25-26] B.I.T.,MESRA 29
B.I.T.,MESRA
30
<<include>>
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
B.I.T.,MESRA 31
[KG00p40]
B.I.T.,MESRA
32
Triggers
Buyer
Sell Property
B.I.T.,MESRA
33
<<extends>>
Transfer
Local Customer
<<uses>>
Identification
[PM97] Pierre-Alain Muller. Instant UML, Wrox Press, Birmingham, UK. [PM97p97]
B.I.T.,MESRA
34
<<includes>>
<<extends>>
Schedule Designer
<<includes>>
Enter Customer Order
[KG00p41]
B.I.T.,MESRA
35
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]
B.I.T.,MESRA
36
Standard menu
Standard toolbar
Diagram window
B.I.T.,MESRA
38
Right clicking on one of the above items (on one of the components in them) allow the item to be
Docked Floating Hidden UML and Rational Rose Notes
B.I.T.,MESRA 39
The Toolbars
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
UML and Rational Rose Notes
B.I.T.,MESRA
40
B.I.T.,MESRA
42
B.I.T.,MESRA
43
[RR00]
B.I.T.,MESRA
44
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
B.I.T.,MESRA
45
B.I.T.,MESRA
46
B.I.T.,MESRA
47
B.I.T.,MESRA
48
The information added to the documentation window automatically updates the Documentation field in the appropriate specification.
UML and Rational Rose Notes
B.I.T.,MESRA 50
B.I.T.,MESRA
51
Right click in the Log Window to set available action Ctrl-tab from Log Windows returns to previous diagram
UML and Rational Rose Notes
B.I.T.,MESRA 53
B.I.T.,MESRA
54
B.I.T.,MESRA
56
Finding Actors
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?
B.I.T.,MESRA 57
B.I.T.,MESRA
58
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 the use cases?
B.I.T.,MESRA
59
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
B.I.T.,MESRA
61
The Use Case View for the Case Study: Course Registration System
B.I.T.,MESRA
62
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 the semester Registrar must maintain all the information about courses, professors, and students Billing System must receive billing information from the system
[TQ98p24-25]
B.I.T.,MESRA
64
B.I.T.,MESRA
65
[TQ98p28-29]
B.I.T.,MESRA
66
The following flow of event for the Select Courses to Teach use case follows Quatrani's recommended template [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
B.I.T.,MESRA
67
[TQ98p30]
B.I.T.,MESRA
68
[TQ98p31]
B.I.T.,MESRA
69
[TQ98p31-2]
B.I.T.,MESRA
70
B.I.T.,MESRA
71
[TQ98p38]
B.I.T.,MESRA
72
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
B.I.T.,MESRA
74
Top-Down or Buttom-Up?
Top-Down Identify Packages first, then Classes
Right click on Logical View in the Browser, select New Package, or dragdrop 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 New Class, 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.
B.I.T.,MESRA
75
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 continues
B.I.T.,MESRA
76
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]: Use Case: Signing Insurance Scenario: "John Doe contacts the system by telephone and signs for car insurance for his new Toyota Corolla"
B.I.T.,MESRA
77
Scenarios
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
Scenario
[EP98p61]
B.I.T.,MESRA
79
[EP98p63]
B.I.T.,MESRA
80
ProfessorCourseOptions
What information do we
B.I.T.,MESRA
83
B.I.T.,MESRA
84
Create Packages
Classes identified:
Boundary Classes
ProfessorCourseOptions AddACourseOffering
Entity Classes
Course CourseOffering ProfessorInformation
Control Classes
ProfessorCourseManager
B.I.T.,MESRA
85
References
References used:
[EP ] [MF97] [KG00] [PK 94] [PM97] [TQ98] Hans-Erik Eriksson and Magnus Penker. UML Toolkit, John Wiley & Sons, New York, NY, 1998. ISBN 0-471-19161-2 Martin Fowler with Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, Reading, Mass, 1997. ISBN 0-201-32563-2 Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context, AddisonWesley, New York, NY, 2000. ISBN 0-201-65767-8 Philippe Kruchten. Software Architecture and Iterative Development. Rational Software Corporation, Santa Clara, CA, April 1994. Pierre-Alain Mueller. Instant UML, WROX Press, Chicago, IL Terry Quatrani. Visual Modeling with Rational Rose and UML, Addison-Wesley, Birmingham, UK, 1998. ISBN 1-861000-87-1
B.I.T.,MESRA
86
Useful URLs
http://members.aol.com/acockburn -- Alistair Cockburn's papers on use cases
B.I.T.,MESRA
87