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