1 Requirements Specification Analysis model Not all requirements - PDF document

Announcements How to build a UML model ❚ HW3 – Phase 1 due on Feb 6 th , 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 CS361 7-2 1 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 ❚ For each use case: ❚ Roles - (out of 20 or so) ❙ step through use case, ❙ Architect ❙ UI designer ❙ note the objects it requires ❙ Use case specifier ❙ note the operations it uses ❙ Use case engineer ❚ Clean up the model ❙ Component engineer 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 each use case? ❚ High priority use cases ❙ What information does the actor need to ❙ describe important and critical functionality receive from or give to the system? ❘ security ❚ Prototyping ❘ database ❙ 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: ❘ boundary - UI, associated with actor other requirements that are not suitable ❘ control - control associated with a use case for use cases. ❘ entity - persistent, the “ real ” objects ❚ Use-case realization (Analysis) CS361 7-7 CS361 7-8 Stereotypes Packages <<control>> ❚ Logical grouping <<boundary>> Automatic claim processor Mainframe system ❚ Used to +handle claim() ❙ divide large system into smaller subsystems +handle claim() ❙ show dependencies between subsystems 0..n <<entity>> <<boundary>> <<boundary>> ❚ Can contain Postal system 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» ❚ Increase cohesion Claims processing system ❚ 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, the class diagram and the object diagram ❙ take next use case ❙ 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>> <<boundary>> Automatic claim processor Mainframe system 101:Claim +handle claim() Jim:Adjudicator +handle claim() 102:Claim Id:620194211 0..n 103:Claim <<entity>> <<boundary>> <<boundary>> :Claim Processor Postal system Claim Adjudicator Jane:Adjudicator 104:Claim 0..n -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 time ❚ Build up model bit by bit ❚ Criticism is easier than creation ❚ Look at one requirement at a time ❚ As long as we get the right answer, it ❚ A new requirement might require doesn ’ t matter how we got it ❙ adding to model ❙ 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 generating letters ❚ A direct marketing system ❚ 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 A user selects a set of customers to whom Viking 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 * Letter preview customers * Thank you very much from ordering from us on <<Date of * Customer Template most recent order>>. We recently received several TemplateComponent letterFor() thousand cans of the special ingredient, … 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 for each component c of template, add customers * c.stringFor(customer) to letter Customer Template * TemplateComponent letterFor() * stringFor() If c is a constant, c.stringFor() is c.value. Property name Field Constant valueOf() If c is a field, c.stringFor(customer) is name value customer.valueOf(c.name) stringFor() stringFor() 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 * customers and by which MailingSystem to send them. 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 valueOf() MailingSystem; the user should not need to PostalSystem SMTP mail() mail() enter this information as part of the sending process. CS361 7-33 CS361 7-34 Adding Customer Information A user knows of a new customer that she * MailingSystem Viking mail() wants to add to The Viking. The user can selection * customers create a new customer entry and record * Customer * relevant information (Name, Salutation, Letter PostalSystem SMTP * mail() mail() Address, Recent Purchase, and anything Property needed by other parts of The Viking) for name value that customer. A Customer has a property “ e-mail address ” and “ postal address ” which are used by the MailingSystems to obtain an address. CS361 7-35 CS361 7-36 6