How to build a UML model

Transcription

1 How to build a UML model RUP Stereotypes, packages, and object diagrams Case study 1 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 COSC 425/6 2 1

2 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 3 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 COSC 425/6 4 2

3 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 5 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. COSC 425/6 6 3

4 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 7 Stereotypes <<control>> Automatic claim processor +handle claim() <<boundary>> Mainframe system +handle claim() <<entity>> Claim -field1 : any -field2 : any +accept/reject() 0..n n <<boundary>> Adjudicator +ID : string +handle claim() <<boundary>> Postal system +send letter() COSC 425/6 8 4

5 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 9 Packages «Facade» Claims processing system Image processing Claims Mainframe interface COSC 425/6 10 5

6 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 11 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 COSC 425/6 12 6

7 Architect Identify common special requirements Persistence Distribution and concurrency Security Fault tolerance Transaction management COSC 425/6 13 Use case engineer Identify analysis classes needed by usecase 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 COSC 425/6 14 7

8 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 15 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 COSC 425/6 16 8

9 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 17 Class diagram <<control>> Automatic claim processor +handle claim() <<boundary>> Mainframe system +handle claim() <<entity>> Claim -field1 : any -field2 : any +accept/reject() 0..n n <<boundary>> Adjudicator +ID : string +handle claim() <<boundary>> Postal system +send letter() COSC 425/6 18 9

10 Class and object diagrams 101:Claim :Claim Processor Jim:Adjudicator Id: Jan:Adjudicator Id: :Claim 103:Claim 104:Claim 105:Claim COSC 425/6 19 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. COSC 425/

11 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 21 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 COSC 425/

12 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 23 An example: The Viking A direct marketing system Sends customized mail and Description consists of a set of use cases COSC 425/

13 Use Case Diagram for the Viking generating letters sending letters mail system adding customer info User template creation delivery monitoring customer selection list information support COSC 425/6 25 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 customerrelated information. The user then previews the result of expanding the template list for each of the customers. COSC 425/

14 selection Customer customers Viking Template letterfor() Letter COSC 425/6 27 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 order number>>/order.html COSC 425/

15 Viking selection preview Letter customers Customer Template TemplateComponent letterfor() stringfor() stringfor(acustomer) { return acustomer.valueof(name)} Field name stringfor() Constant value stringfor() COSC 425/6 29 selection Viking customers Customer Template letterfor() Property name value stringfor(acustomer) { return acustomer.valueof(name)} Letter TemplateComponent stringfor() Field name stringfor() Constant value stringfor() COSC 425/

16 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 31 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. COSC 425/

17 Customer Property name value selection Viking Letter customers MailingSystem mail() PostalSystem mail() SMTP mail() COSC 425/6 33 customers Customer Letter Property name value Viking selection MailingSystem mail() PostalSystem mail() SMTP mail() A Customer has a property address and postal address which are used by the MailingSystems to obtain an address. COSC 425/

18 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 35 Customer Property name value Viking customers COSC 425/

19 Interface to create customer Name: Salutation: Address: Recent purchase: Create New Customer Anna Kurn Ms. 712 Maple Ave, Toronto NY Recent purchase: #e45 COSC 425/6 37 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. COSC 425/

20 Viking Template letterfor() TemplateComponent stringfor() Field name stringfor() Constant value stringfor() COSC 425/6 39 Viking Template Parser Template letterfor() TemplateComponent stringfor() Field name stringfor() Constant value stringfor() COSC 425/

21 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 41 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. COSC 425/

22 Viking MailingSystem mail() Letter PostalSystem mail() SMTP mail() COSC 425/6 43 Viking MailingSystem mail() Letter status PostalSystem mail() SMTP mail() COSC 425/

23 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 45 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. COSC 425/

24 Customer selection by criteria What query language? SQL? Dialog box? What criteria? Any history? Orders, products Change the UI for select customers COSC 425/6 47 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 COSC 425/