90 likes | 121 Vues
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
E N D
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
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.
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…
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
Decision Tables • Inputs as columns, actions (outputs) as rows • If there are n parameters (conditions) to a decision, each with k1, k2,…,kn values, then table has: • k1 x k2 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
Completion vs. Simplification • Completion: • explicitly lists all combinations of inputs • Simplification: • reduce repeated columns with “*” for don’t care • remove redundant rows • Example: Completion Simplification
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: Out-of-Town Trip? Short Trip? In-Town Trip? Have Car? Have Car? Fly Have Car? on abudget? on a budget? Take Car Take Car Take Car TTC Walk Taxi Taxi
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