1 Requirements Specification Analysis model Not all requirements - - PDF document

1

1

How to build a UML model

RUP Steriotypes, packages, and

• bject 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

• ther 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..1 0..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..1 0..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

• f 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 letters mail 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: akurn@fipster.com 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() * Template Parser

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