1
1
How to build a UML model
RUP
Stereotypes, packages, and
object diagrams
Case study
COSC 425/6 2
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
2
COSC 425/6 3
How models are built in RUP
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
COSC 425/6 4
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
3
COSC 425/6 5
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
COSC 425/6 6
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.
4
COSC 425/6 7
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)
COSC 425/6 8
Stereotypes
Adjudicator
+handle claim()
+ID : string
Claim
+accept/reject()
-field1 : any
-field2 : any
Postal system
+send letter()
Mainframe system
+handle claim()
0..1
0..n
Automatic claim processor
+handle claim()
0..n
<<boundary>> <<entity>>
<<boundary>> <<control>>
<<boundary>>
5
COSC 425/6 9
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.
COSC 425/6 10
Packages
Image processing Claims
«Facade»
Claims processing system
Mainframe interface
6
COSC 425/6 11
Packages and dependencies
Reduce coupling
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
COSC 425/6 12
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
7
COSC 425/6 13
Architect
Identify common special requirements
Persistence
Distribution and concurrency
Security
Fault tolerance
Transaction management
COSC 425/6 14
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
8
COSC 425/6 15
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
COSC 425/6 16
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
9
COSC 425/6 17
Object diagram
An object diagram is a 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 effectively the same
As classes become more reusable, object diagrams become more interesting
COSC 425/6 18
Class diagram
Adjudicator
+handle claim()
+ID : string
Claim
+accept/reject()
-field1 : any
-field2 : any
Postal system
+send letter()
Mainframe system
+handle claim()
0..1
0..n
Automatic claim processor
+handle claim()
0..n
<<boundary>> <<entity>>
<<boundary>> <<control>>
<<boundary>>
10
COSC 425/6 19
Class and object diagrams
Jan:Adjudicator
Jim:Adjudicator
:Claim Processor
102:Claim
103:Claim
104:Claim
105:Claim
101:Claim
Id:301478334
Id:620194211
COSC 425/6 20
Summary of Analysis
Analysis is the process of 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.
11
COSC 425/6 21
Analysis/Design in XP
Similar to RUP except that…
everyone on the team does it (including customer)
less is written down, more oral
less is done before writing code
COSC 425/6 22
Modeling example
The model is built bit by bit
Look at one requirement at a time
A new requirement might require
adding to the model
changing the model
The model should support all the requirements you’ve seen so far
12
COSC 425/6 23
Why do we model this way?
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
COSC 425/6 24
An example: The Viking
A direct marketing system
Sends customized mail and e-mail
Description consists of a set of use cases
13
COSC 425/6 25
Use Case Diagram for the
Viking
User
generating letters
sending letters
mail systemadding customer info
template creation
delivery monitoring
customer selection
list information support
COSC 425/6 26
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.
14
COSC 425/6 27
Customer Template
letterFor()
Letter Viking
selection
customers
COSC 425/6 28
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
15
COSC 425/6 29
Customer Template
letterFor()
Viking selection
customers
Constant
value
stringFor()
TemplateComponent
stringFor()
Field
name
stringFor()
*
*
*
stringFor(aCustomer) {
return aCustomer.valueOf(name)}
*
Letter preview
COSC 425/6 30
Customer Template
letterFor()
Property
name
value
Viking selection
customers
Constant
value
stringFor()
TemplateComponent
stringFor()
Field
name
stringFor()
*
*
*
stringFor(aCustomer) {
return aCustomer.valueOf(name)}
*
Letter
*
16
COSC 425/6 31
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)
COSC 425/6 32
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.
17
COSC 425/6 33
Customer
Letter
PostalSystem
mail()
selection
customers *
* * Viking
MailingSystem
mail()
SMTP
mail()
Property
name
value
*
COSC 425/6 34
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
*
18
COSC 425/6 35
Add 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.
COSC 425/6 36
Customer
customers *
Viking
Property
name
value
*
19
COSC 425/6 37
Interface to create 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
COSC 425/6 38
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.
20
COSC 425/6 39
Template
letterFor()
Viking
Constant
value
stringFor()
TemplateComponent
stringFor()
Field
name
stringFor()
*
COSC 425/6 40
Template
letterFor()
Viking
Constant
value
stringFor()
TemplateComponent
stringFor()
Field
name
stringFor()
* Template
Parser
21
COSC 425/6 41
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
COSC 425/6 42
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”.
22
COSC 425/6 43
Letter PostalSystem
mail()
*
*
Viking MailingSystem
mail()
SMTP
mail()
COSC 425/6 44
Letter
status PostalSystem
mail()
*
*
Viking MailingSystem
mail()
SMTP
mail()
23
COSC 425/6 45
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
COSC 425/6 46
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 every bought a particular product.
24
COSC 425/6 47
What query language?
SQL?
Dialog box?
What criteria?
Any history?
Orders, products
Change the UI for “select customers”
Customer selection by criteria
COSC 425/6 48
Conclusion
We’re only half done, but…
The process to finish is the same
Each additional step makes progress
Keep track of open issues and make sure they get resolved
The amount you write down depends on how much you can remember
