University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook Lecture 12: Modelling Business Rules & Processes Ü Review of all the UML modelling techniques  Modelling notations we’ve covered  When to use each  What haven’t we captured? Ü Business Rules  Constraints and Derivations  Representations for Business Rules Ü Modeling business processes  Concurrency and synchronization  Activity Diagrams

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook Example Business Rules Constraints (BR1) The manager of a department must belong to that department. (BR2) An employee cannot earn more than her manager. (BR3) A department of the Toronto office can only be managed by an employee who has ≥ 10yrs experience. (BR4) An employee can only participate in projects associated with her department. Derivations (BR5) The budget of a project is the sum of all salaries of participating employees, multiplied by 3.

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook Capturing Business Rules Ü Why do we care about business rules?  They help us to understand the business context  They could be important constraints for the design of the new system  E.g. constraints on when and how operations can happen  E.g. constraints on the state space of objects  They help us write “operation specifications” for class operations Ü How do we specify business rules?  Natural Language  such descriptions can be highly ambiguous  Structured English  use a subset of a natural language (limited syntax and vocabulary)  can be hard to write, hard to verify, and too close to program code  Decision Tables  use a table representation of alternative outcomes (similar to truth tables)  Decision Trees  use a tree representation of alternative outcomes  Object Constraint Language  UML notation for adding extra constraints to models  Can also be used for specifying pre- and post-conditions on operations  Activity Diagrams…

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook Structured English  Use only nouns and terms defined in the project dictionary  Avoid compound sentences because they can be highly ambiguous  Avoid vague adjectives and adverbs (such as “good”, “nice” etc.)  unless clearly defined in the dictionary as a value ranges (e.g. “good” = 65-75%)  Avoid language that destroys the natural flow of control within the process Use a limited set of flow constructs:  sequencing, if-then-else, while do etc.  Example: For each LOAN ACCOUNT NUMBER in the LOAN ACCOUNT FILE do the following steps: If the AMOUNT PAST DUE is greater than $0.00 then while there are LOAN ACCOUNT NUMBERS for the CUSTOMER NAME do the following: sum the OUTSTANDING LOAN BALANCES sum the MINIMAL PAYMENTS sum the PAST DUE AMOUNTS report the CUSTOMER NAME, LOAN ACCOUNT on OVERDUE CUSTOMER, LOAN ANALYSIS For each LOAN ACCOUNT NUMBER in the LOAN ACCOUNT FILE do the following steps: If the AMOUNT PAST DUE is greater than $0.00 then while there are LOAN ACCOUNT NUMBERS for the CUSTOMER NAME do the following: sum the OUTSTANDING LOAN BALANCES sum the MINIMAL PAYMENTS sum the PAST DUE AMOUNTS report the CUSTOMER NAME, LOAN ACCOUNT on OVERDUE CUSTOMER, LOAN ANALYSIS

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook Decision Tables Ü Inputs as columns, actions (outputs) as rows  If there are n parameters (conditions) to a decision, each with k 1, k 2,…,k n values, then table has:  k 1 x k 2 x … x k n columns  as many rows as there are possible actions  For example:  “If the plane is more than half full and the flight costs more than $350 per seat, serve free cocktails, unless it is a domestic flight. Charge for cocktails in all domestic flights where cocktails are served, i.e., those that are more than half full” conditions outcomes Domestic?YYYYNNNN ≥half full?YYNNYYNN ≥$350/seatYNYNYNYN Serve cocktails?XXX??? Free cocktails?X

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook CompletionSimplification Completion vs. Simplification Ü Completion:  explicitly lists all combinations of inputs Ü Simplification:  reduce repeated columns with “*” for don’t care  remove redundant rows Ü Example: Domestic?YYYYNNNN ≥half full?YYNNYYNN ≥$350/seatYNYNYNYN Serve cocktailsXXXXX Free cocktailsXX Charge cocktailsXXX No cocktailsXXX Domestic?YYNNN ≥half full?YN*YN ≥$350/seat**YNN Free cocktailsX Charge cocktailsXX No cocktailsXX

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook Decision Trees Ü Represent the decision logic as a tree:  Nodes of the tree represent input parameters (questions)  Leafs of the tree represent outputs (actions) Ü Example: Short Trip? In-Town Trip? Out-of-Town Trip? Have Car? on a budget? Take Car Walk Taxi Have Car? Take Car TTC Taxi Have Car? Take Car Fly on a budget?

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook Object Constraint Language (OCL) Ü UML naturally captures some constraints:  e.g. multiplicity of an association. Ü For others, we need a general language  OCL is a formal language for specifying constraints  used to supplement the models created in UML diagrams.  OCL has a precise syntax that enables the construction of unambiguous statements. Ü Each expression has  An associated context  usually the class to which the expression is attached.  may alternatively be an association  A property  some aspect of the context: e.g. an attribute or association  An operation that is applied to the property  E.g. mathematical operations, set operations, type operations

University of Toronto Department of Computer Science © Castro, Mylopoulos and Easterbrook OCL examples