University of Toronto Department of Computer Science Lecture

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

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

University of Toronto Department of Computer Science 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… © Castro, Mylopoulos and Easterbrook 2002 3

Department of Computer Science University of Toronto 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 © Castro, Mylopoulos and Easterbrook 2002 4

Department of Computer Science University of Toronto Decision Tables Ü Inputs as columns, actions (outputs) as rows Ä If there are n parameters (conditions) to a decision, each with k 1, k 2, …, kn values, then table has: Ø k 1 x k 2 x … x kn 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 © Castro, Mylopoulos and Easterbrook 2002 Domestic? ≥half full? Y Y N N ≥$350/seat Serve cocktails? Free cocktails? Y N Y N X X X ? ? ? X 5

Department of Computer Science University of Toronto Completion vs. Simplification Ü Completion: Ü Simplification: Ü Example: Ä explicitly lists all combinations of inputs Ä reduce repeated columns with “*” for don’t care Ä remove redundant rows Completion Simplification Domestic? Y Y N N ≥half full? Y Y N N ≥$350/seat Y N Y N Serve cocktails X X X Free cocktails Charge cocktails X X X No cocktails © Castro, Mylopoulos and Easterbrook 2002 Y Y N N N ≥half full? Y N * Y N ≥$350/seat * * Y N N Free cocktails X Charge cocktails X X X Domestic? X No cocktails X X X 6

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

University of Toronto Department of Computer Science Object Constraint Language (OCL) Ü UML naturally captures some constraints: Ü For others, we need a general language Ü Each expression has Ä e. g. multiplicity of an association. Ä 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. Ä 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 © Castro, Mylopoulos and Easterbrook 2002 8

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