Up-selling When you want to purchase a product, you are sometimes offered an upgrade to a higher specification product, possibly
at a reduced price This activity, known as up-selling is an important way for businesses to maximize both the business benefit and the customer satisfaction generated from each sale the ProductRelationship UpgradableTo captures the possibility of an upgrade to a higher specification ProductType Cross-selling Cross-selling occurs when you choose a product and are then offered a compatible product, possibly at a reduced price We capture the possibility of cross-selling with the ProductRelationship ComplementedBy When up-selling and cross-selling are practiced with integrity, they can generate advantages for both the buyer and the seller Price The Price archetype represents the amount of money that must be paid in order to purchase a good or service The essence of our model of pricing is that each ProductType may have one or more Prices, and each Price has an associated RuleSet that defines the preconditions for the availability of that Price So if, for example, you want to get Price X, you must first satisfy RuleSet Y Pricing case 1. A single, fixed price 2. A reserve (minimum) price and a higher price determined at the point of sale eBay 3. A price that shows some periodicity 4. Multiple prices that depend on the application of business rules CD prices that may be reduced if you are a club member (our local CD shop does this) An item for sale on an auction site such as Seasonal rates for hotel accommodation Example A can of soup in a supermarket
5. Multiple prices that depend on the
application of business rules and that show some time dependence An airline ticket
If several Prices are available, the selling system often filters these Prices by deciding which to offer to the customer and in what order to present them. Filtering is generally based on a combination of customer requirements and specific business drivers, such as the need to sell more of a particular product or to maximize profit on the sale Prices have optional validFrom and validTo attributes that can be used by a RuleSet to decide whether a Price is available and can also be used to get current or historic prices for a ProductType. A particular ProductInstance is associated with an agreed Price from the set of possible Prices for its ProductType or an applied ArbitraryPrice Price Reductions A price reduction that applies to any instance of a ProductType is modeled as one of the ProductType's Prices and may have preconditions. Individual ProductInstances may also have an ad hoc Price applied that overrides all the other possible Pricesfor example, a price reduction for a shop-soiled item. An ad hoc Price is modeled as an ArbitraryPrice. The ArbitraryPrice archetype represents an ad hoc Price applied to a specific ProductInstance that overrides all other possible Prices Finally, price reductions may be applied as Discounts to a whole Order rather than to individual ProductTypes or ProductInstances Package Pricing The PricingStrategy archetype determines how a Price is calculated for a PackageType PricingStrategy ASSIGNED AGGREGATED SERVICES A service represents a process or activity that is offered for sale In fact, only in inventory management is there any difference between goods and services that makes a difference from the modeling perspective Ex:- haircut from barbershop P=x P = (i=1 to n) pi
A haircut is not a thing in itself it is a process. Still, natural language allows you to refer to the haircut process as though it is a noun. This is known as nominalization When you are selling services, rather than selling things, you are actually selling part of your business's capacity to deliver the service ServiceType The ServiceType archetype is a kind of ProductType that represents a type of service Each ServiceType may optionally have two attributes startOfPeriodOfOperation endOfPeriodOfOperation ServiceInstance The ServiceInstance archetype represents an instance or execution of a ServiceType delivered to one or more Parties ServiceInstances have an actual start and end as well as an optional scheduledStart and scheduledEnd for performance monitoring purposes ServiceDeliveryStatus The ServiceDeliveryStatus archetype records the status of the delivery of a particular ServiceInstance This can take one of the values shown SCHEDULED EXECUTING CANCELLED COMPLETED The ServiceInstance has been scheduled for delivery The ServiceInstance is in the process of delivery The ServiceInstance has been cancelled The delivery of the ServiceInstance has been completed
ManHour The ManHour archetype represents an amount of work corresponding to one person working for one hour nonstandard unit Quantity The Quantity archetype represents an amount measured in some Metric. Quantity provides a set of functions to perform the following types of operations: Arithmetic Comparison Rounding Arithmetic operations Add Substract Multiply Divide Comparison operations equalTo greaterThan lessThan Rounding operation Rounding reduces the precision of the amount of a Quantity by approximating it with an amount of lower precision. The RoundingPolicy archetype determines the mathematical semantics of the Quantity archetype's round(...) operation
Rounding policy attributes numberOfDigits roundingDigit roundingStep RoundingStrategy The RoundingPolicy also has a RoundingStrategy. The RoundingStrategy archetype represents an aspect of a RoundingPolicy that determines the type of rounding to be applied ROUND_UP, ROUND_DOWN ROUND Behaves like ROUND_UP if the digit following the specified numberOfDigits is greater than or equal to the specified roundingDigit; otherwise, behaves like ROUND_DOWN ROUND_UP_BY_STEP, ROUND_DOWN_BY_STEP ROUND_TOWARDS_POSITIVE, ROUND_TOWARDS_NEGATIVE StandardConversion and UnitConverter The StandardConversion archetype defines a conversionFactor that can be used to convert a Quantity in a source Unit to a Quantity in a target Unit. The UnitConverter archetype is responsible for converting a Quantity in a source Unit to a Quantity in a target Unit. UnitConverter provides a single operation, convert(...) which tries to find a StandardConversion that references the correct Units for its quantity and targetUnit parameters. The conversion process is very simple. The amount of the Quantity of the source Unit is multiplied by the conversionFactor to produce a Quantity of the target Unit.
Rule archetype pattern
Rules are constraints. A business rule is a constraint on the operation of the business. A business system rule is a constraint on the operation of the software systems of the business. A business rule may constrain the business in two fundamentally different ways 1. It may constrain the structure of the business - relationships between subunits 2. It may constrain the operation of the business - sequence of actions in business workflow Business rules are pervasive and exist at all levels of the organization Business rules form a hierarchy from the very general to the very specific This hierarchy is itself subject to the constraint that all of its rules must be consistent with each other Rules and business processes A business process is a sequence of business activities that, when executed, is designed to lead to some business benefit Rules can affect business processes in two ways 1. They can embody information about the state of the business 2. They can conditionally trigger business activities based on that information The business process here is about selling an insurance policy to a customer This process can be summarized as: if customerAge >= minimumAge then sellPolicy() customerAge = 17 minimumAge = 18 if customerAge >= minimumAge then sellPolicy() Information Information A fact about the customer A fact about the business
Activity A rule that triggers a business activity All rules that trigger activities take this if/then form
Business system rules can exist in three places: 1. In the source code 2. As database triggers 3. As explicit rules managed and manipulated by a rules engine Source code Applications have good performance Rules are very hard to change, and it is expensive to make the change Rules are generally not reusable across applications Applications are inflexible Database triggers Rules are more accessible to change Applications are more flexible Rules are coupled to data Rules are not reusable across data sets Not all rules can be encoded in this way Explicit rules managed by a rules engine Rules are completely accessible to change, and it is easy and inexpensive to make the change Rules are made explicit and so are open to inspection and review Rules are separate from applications and data Applications are very flexible Applications may not perform as well as they would with hard-coded rules this depends on the rules engine
Rules and formal logic The best way to model rules is to use the principles of formal logic Prepositions A proposition is a statement that has a truth value Statement customer002923IsPlatinumCardHolder account001234IsOverdrawn Truth value true false
A typical rules engine maintains a database (factbase) of such statements and uses their values to trigger business activities Propositions can be used to capture Boolean (i.e., true/false) facts about the business As events occur in the business, some of these propositions change their truth values Because propositions are Boolean, you can apply Boolean algebra to them to create new propositions called compound propositions Logical AND Logical OR Logical NOT Logical XOR Variables and predicates Propositions deal with Boolean information, but much of the information about the business is not Boolean. Many notable events in the business involve a change in the value of some quantity. We represent these values as variables. A variable is a symbol that represents the value of something and can assume any of a set of values (account001234IsOverdrawn) is equivalent to ([Link] < 0.0) In formal logic, the statement ([Link] < 0.0) is called a predicate A predicate is a statement containing variables related by quantifiers that is either true or false depending on the values of the variables
Logic and the Rule archetype pattern Using propositions, Boolean operators, predicates, and quantifiers, you can construct a pattern that describes a simple rules engine that works according to the principles of formal logic. In our pattern, the engine's database is broken into two parts. The first part contains the Rules themselves, and the second part (the RuleContext) contains the factbase on which the Rules operate. Rules are evaluated against a RuleContext to return a Boolean result, which may be used to trigger an activity. You can think of this mechanism as being like a lock and a key. The "lock" is a Rule that is triggered only if the right conditions are met. The "key" is the RuleContext that contains the factbase required by the Rule. RuleElement Rules and RuleContexts are both made up of a sequence of one or more RuleElements The RuleElement archetype is an abstract class that represents an element of a Rule or a RuleContext RuleElement has a name that indicates the semantics of the element and an abstract operation getType() that returns the type of the RuleElement Valid types are operator, preposition, variables, datevariable RuleContext The RuleContext archetype contains the informational context for the execution of a Rule. It represents this information as a collection of RuleElements that may be Propositions, Variables, or DateVariables but not Operators RuleContext has operations to add and find the RuleElements that comprise it, as well as an operation to append another RuleContext to itself Rule The Rule archetype represents a constraint on the operation of the software systems of the business. Its semantics are defined by a sequence of RuleElements
Rule has operations to add the various RuleElements that comprise it, as well as one to evaluate the Rule using the information provided by a particular RuleContext Rule Scenario suitableForUpgrade
passengerIsEconomy AND ( passengerIsGoldCardHolder OR passengerIsSilverCardHolder ) AND ( passengerCarryOnBaggageWeightKg LESSTHANOREQUALTO carryOnBaggageAllowanceKg ) AND passengerDressIsSmart
Rule Evaluation get Rule get RuleContext evaluate Rule get next RuleElement pop result process Result RuleSet A RuleSet can be evaluated to a Proposition that is true if and only if every Rule in the set also evaluates to true. It therefore performs a logical AND on all of the Rules it contains The RuleSet is useful for grouping Rules It also allows RuleOverrides to be applied to one or more of the Rules RuleOverride The RuleOverride archetype overrides a Rule in a RuleSet RuleOverride records the ruleName of the Rule that it overrides, the value of the override (i.e., whether the Rule was overridden to true or false), why the override was made, when it happened, and who the override was raisedBy and optionally authorizedBy