rational unified process how rup builds a...
TRANSCRIPT
1
1
How to build a UML model
RUP Steriotypes, packages, and object diagrams Case study
Announcements
❚ HW3 – Phase 1 due on Feb 6th, 5:00pm (need to create new pairs, accounts)
❚ Feedback on M2: turn procedural code into OO code, Planning game (show tables with features, subtasks, estimates, actuals, pair-programming partners)
❚ Register for the Feb 18 Industry Reception
CS361 7-2
CS361 7-3
Rational Unified Process
❚ Designed to work with UML ❚ No longer being promoted by IBM
❚ Roles - (out of 20 or so) ❙ Architect ❙ UI designer ❙ Use case specifier ❙ Use case engineer ❙ Component engineer
CS361 7-4
How RUP builds a model
❚ Gather use cases from customer ❚ Make initial object model ❚ For each use case: ❙ step through use case, ❙ note the objects it requires ❙ note the operations it uses
❚ Clean up the model
CS361 7-5
Architect
❚ Determine which use cases need to be developed first.
❚ High priority use cases ❙ describe important and critical functionality ❘ security ❘ database
❙ hard to retrofit later
CS361 7-6
UI design
❚ Logical design ❙ Which user-interface elements are needed for
each use case? ❙ What information does the actor need to
receive from or give to the system?
❚ Prototyping ❙ Often is on paper. ❙ Test on real users
2
CS361 7-7
Requirements Specification
❚ Not all requirements go in a use case. ❙ Example: security ❙ Example: global performance
❚ Requirements document describes all other requirements that are not suitable for use cases.
CS361 7-8
Analysis model
❚ Class diagrams ❙ vague interfaces (“responsibilities”) ❙ vague associations (ignore navigability) ❙ stereotype classes: ❘ boundary - UI, associated with actor ❘ control - control associated with a use case ❘ entity - persistent, the “real” objects
❚ Use-case realization (Analysis)
CS361 7-9
Stereotypes
Adjudicator
+handle claim()+ID : string
Claim
+accept/reject()
-field1 : any-field2 : any
Postal system
+send letter()
Mainframe system
+handle claim()
0..10..n
Automatic claim processor
+handle claim()
0..n<<boundary>> <<entity>>
<<boundary>> <<control>>
<<boundary>>
CS361 7-10
Packages
❚ Logical grouping ❚ Used to ❙ divide large system into smaller subsystems ❙ show dependencies between subsystems
❚ Can contain ❙ class diagrams or packages ❙ use cases, sequence diagrams, etc.
CS361 7-11
Packages
Image processing Claims
«Facade»Claims processing system
Mainframe interface
CS361 7-12
Packages and dependencies
❚ Reduce coupling (so that teams can work independently)
❚ Increase cohesion ❚ In packages ❙ cohesion is between classes in a package ❙ coupling is between classes in different packages
❚ In classes ❙ cohesion is between methods in a class ❙ coupling is between methods in different classes
3
CS361 7-13
Architect
❚ Responsible for the integrity of analysis model ❙ Makes sure packages fit together ❙ Makes sure each package is good ❙ Identifies obvious entity classes ❙ Lets other classes be defined during use-case
realizations and component analysis
CS361 7-14
Architect
❚ Identify common special requirements ❙ Persistence ❙ Distribution and concurrency ❙ Security ❙ Fault tolerance ❙ Transaction management
CS361 7-15
Use case engineer
❚ Identify analysis classes needed by use-case
❘ Boundary classes, control classes, entity classes
❚ Distribute behavior of use-case to classes ❚ Make use-case realization: a precise
description of use-case ❙ sequence diagram ❙ collaboration diagram
CS361 7-16
Component Engineer
❚ Analyze classes ❙ Gather information from use cases ❙ Make sure class is coherent ❙ Make model as simple as possible, but no
simpler.
❚ Analyze a package ❙ Relationships between classes ❙ Relationships between packages
CS361 7-17
Outline of RUP process for analysis
❚ Find use cases ❚ Architect determines order ❚ Repeatedly, ❙ take next use case ❙ change class diagram to accommodate use
case ❙ simplify class diagram
CS361 7-18
Object diagram
❚ Snapshot of objects in a system at a point in time
❚ If there is just one object of each class, the class diagram and the object diagram are the same
❚ As classes become more reusable, object diagram becomes more interesting
4
CS361 7-19
Class diagram
Adjudicator
+handle claim()+ID : string
Claim
+accept/reject()
-field1 : any-field2 : any
Postal system
+send letter()
Mainframe system
+handle claim()
0..10..n
Automatic claim processor
+handle claim()
0..n<<boundary>> <<entity>>
<<boundary>> <<control>>
<<boundary>>
CS361 7-20
Class and object diagrams
Jane:Adjudicator
Jim:Adjudicator
:Claim Processor
102:Claim
103:Claim
104:Claim
105:Claim
101:Claim
Id:301478334
Id:620194211
CS361 7-21
Summary
❚ Analysis is converting vague user needs into a precise model of what the system should do.
❚ Analysis is incremental; look at one piece of the problem at a time.
❚ Requires continually changing the model until you are done.
CS361 7-22
Analysis/Design in XP ❚ Similar to RUP except that ❙ everyone does it ❙ little written, more oral ❙ less is done before writing code
CS361 7-23
Modeling example in XP
❚ Code is the model!! ❚ Build up model bit by bit ❚ Look at one requirement at a time ❚ A new requirement might require ❙ adding to model ❙ changing model
❚ Model should support all the requirements you’ve seen so far
CS361 7-24
Why we model incrementally?
❚ We can only think about one thing at a time
❚ Criticism is easier than creation ❚ As long as we get the right answer, it
doesn’t matter how we got it
5
CS361 7-25
The Viking
❚ A direct marketing system ❚ Sends customized mail and e-mail ❚ http://designfest.acm.org/Problems/
Viking/Viking_00.pdf ❚ Description consists of a set of use cases
CS361 7-26
Use Case Diagram for The Viking
User
generating letters
sending lettersmail system
adding customer info
template creation
delivery monitoring
customer selection
list information support
CS361 7-27
Generating letters
A user selects a set of customers to whom they wish to send letters and a template that defines the letter format. The Viking then generates a letter per customer that is based on filling in the “pluggable” information for the template with customer-related information. The user then previews the result of expanding the template list for each of the customers.
CS361 7-28
Customer Template letterFor()
Letter Viking selection
customers
CS361 7-29
Template
Dear <<Proper Salutation>> <<Customer Name>> Thank you very much from ordering from us on <<Date of most recent order>>. We recently received several thousand cans of the special ingredient, … If you are interested, please click on http://theHappyViking.com/SpecialOrder/<<special order number>>/Order.html
CS361 7-30
Customer Template letterFor()
Viking
customers
Constant value stringFor()
TemplateComponent stringFor()
Field name stringFor()
*
*
*
stringFor(aCustomer) { return aCustomer.valueOf(name)}
Letter preview
6
CS361 7-31
Customer Template letterFor()
Property name valueOf()
Viking
customers
Constant value stringFor()
TemplateComponent stringFor()
Field name stringFor()
*
*
*
stringFor(aCustomer) { return aCustomer.valueOf(name)}
*
Letter
CS361 7-32
Use template to create a letter for a customer
letter := empty letter;for each component c of template, add c.stringFor(customer) to letter
If c is a constant, c.stringFor() is c.value. If c is a field, c.stringFor(customer) is
customer.valueOf(c.name)
CS361 7-33
Sending letters
A user chooses from among the generated letters and decides which ones to send out and by which MailingSystem to send them. The Viking should already have information associated with each customer so it can properly distribute the letter by a particular MailingSystem; the user should not need to enter this information as part of the sending process.
CS361 7-34
Customer
Letter
PostalSystem mail()
selection
customers *
* Viking
MailingSystem mail()
SMTP mail()
Property name valueOf()
*
CS361 7-35
Customer Letter PostalSystem mail()
customers * *
Viking MailingSystem mail()
SMTP mail() Property
name value
*
A Customer has a property “e-mail address” and “postal address” which are used by the MailingSystems to obtain an address.
* selection
*
CS361 7-36
Adding Customer Information
A user knows of a new customer that she wants to add to The Viking. The user can create a new customer entry and record relevant information (Name, Salutation, Address, Recent Purchase, and anything needed by other parts of The Viking) for that customer.
7
CS361 7-37
Customer customers *
Viking
Property name value
*
CS361 7-38
Interface for creating customer
Anna Kurn Ms. 712 Maple Ave, Toronto NY E-mail: [email protected] Recent purchase: #e45
Name: Salutation: Address: E-mail: Recent purchase:
Create New Customer
CS361 7-39
Template Creation
A user creates a new template either from scratch or by copying an existing template. A template needs to support both constant and “pluggable” information, and a user should be able to create a template and preview its appearance.
CS361 7-40
Template letterFor()
Viking
Constant value stringFor()
TemplateComponent stringFor()
Field name stringFor()
*
CS361 7-41
Template letterFor()
Viking
Constant value stringFor()
TemplateComponent stringFor()
Field name stringFor()
* TemplateParser
CS361 7-42
User interfaces
❚ Generate letters (select a set of customers and a template) and preview them
❚ Select letters to send and the mailing system to use
❚ Create new customer and enter info ❚ Create new template and preview it
8
CS361 7-43
Delivery Monitoring
A user reviews the letters to see which have been sent and whether any of them have “failed delivery”. If so, the user can choose to resend them either by the same Mailing System or by a different one. Also, to support this story, the Mailing System must be able to tell The Viking which sent letters “failed delivery”.
CS361 7-44
Letter PostalSystem mail()
*
*
Viking MailingSystem mail()
SMTP mail()
CS361 7-45
Letter status
PostalSystem mail()
*
*
Viking MailingSystem mail()
SMTP mail()
CS361 7-46
Mail delivery failure
❚ Some failures are permanent (“no such user”) and some are temporary (“mailbox full”). Need different status for each.
❚ Can have secondary addresses. ❚ “Select permanent failures and send to
secondary address” is special case of “select messages and send them”
❚ Need UI for changing status
CS361 7-47
Customer selection by criteria
Upgrade the template from Story#1 to support selecting the set of customers by various search criteria. For example, select all customers who spent more than US$100 on their most recent order, or all customers who have ever bought a particular product.
CS361 7-48
❚ What query language? ❙ SQL? ❙ Dialog box?
❚ What criteria? ❙ Any history? ❙ Orders, products
❚ Change the UI for “select customers”
9
CS361 7-49
Conclusion
❚ Only half done ❚ Process to finish is the same ❚ Each step makes progress ❚ Keep track of open issues and make sure
they get resolved ❚ Amount you write down depends on how
much you remember
Next time
❚ Design Fest in class: CRC, UML
CS361 7-50