© Copyright by Jeffrey Culver Barcalow, 1997
STRATEGIC PLANNING SUPPORT
FOR A FINANCIAL MODEL FRAMEWORK
BY
JEFFREY CULVER BARCALOW
B.S., University of Illinois, 1995
THESIS
Submitted in partial fulfillment of the requirements
for the degree of Master of Science in Computer Science
in the Graduate College of the
University of Illinois at Urbana-Champaign, 1997
Urbana, Illinois
Acknowledgments
I would like to thank John Brant, Mark Kendrat, Jee Ku, Joseph Yoder, Dmitry Zelenko, and
everyone else at Caterpillar/NCSA for making my graduate school experience enjoyable, interesting,
challenging, and worthwhile. My thanks also go to everyone in the UIUC Patterns Reading Group.
I have learned a great deal from those people, and they always challenged me to do more. I also
wish to thank my advisor, Ralph Johnson. For over two years he has shaped my learning with his
valuable insights and has guided me towards great opportunities.
A special thanks goes to my sister, Tammy, who always seemed to “blaze a path for me.” And most
of all I would like to thank my parents, John and Susan Barcalow, the most wonderful parents a son
could ever hope for.
ii
Table of Contents
1 Introduction ........................................................................................................................... 1
1.1 Motivation ............................................................................................................................................... 1
1.2 Example Use........................................................................................................................................... 1
2 Background ............................................................................................................................ 3
2.1 Financial Model ...................................................................................................................................... 3
2.2 A Decision Making Model ................................................................................................................... 4
2.3 Scenario Planning .................................................................................................................................. 6
2.4 Additional Background ......................................................................................................................... 8
3 The User’s Perspective ........................................................................................................ 11
3.1 Users ......................................................................................................................................................11
3.2 Scenarios ...............................................................................................................................................12
3.3 Business Rules ......................................................................................................................................13
3.4 Decisions ...............................................................................................................................................16
3.5 Policies ...................................................................................................................................................17
3.6 Comparison Sets ..................................................................................................................................20
4 How It Works....................................................................................................................... 22
4.1 Architecture ..........................................................................................................................................22
4.2 Object Editing Interfaces ...................................................................................................................25
4.3 Base Objects .........................................................................................................................................26
4.4 Base Support Objects ..........................................................................................................................29
4.5 Business Logic Layer ...........................................................................................................................31
4.6 Functions...............................................................................................................................................36
4.7 Generating Output ..............................................................................................................................39
5 Conclusions and Future Work ............................................................................................. 42
Bibliography ............................................................................................................................ 44
iii
List of Figures
Figure 1 – Scenario Editor ............................................................................................................ 13
Figure 2 - Business Rule Editor .................................................................................................... 15
Figure 3 – Single Decision Editor ................................................................................................. 17
Figure 4 – Composite Decision Editor.......................................................................................... 17
Figure 5- Policy Editor .................................................................................................................. 19
Figure 6 – Conditional Editor ....................................................................................................... 19
Figure 7 – Selection Box ............................................................................................................... 20
Figure 8 - Editor Layers ................................................................................................................ 22
Figure 9 - Logic Layers of a Completed System ........................................................................... 24
Figure 10 - Scenarios, Descriptions, and Business Rules ............................................................. 27
Figure 11 - Composite Decision ................................................................................................... 28
Figure 12 - Managing BusinessEntities with Multiple Products in ValueSpace .......................... 30
Figure 13 - FutureEntity ................................................................................................................ 33
Figure 14 - A ValueSpace Instance ............................................................................................... 34
Figure 15 - Lazy Initialization in ValueSpace and FutureEntity................................................... 35
Figure 16 - Strategy in FutureEntity and TimedFutureEntity ....................................................... 36
Figure 17 - Functions .................................................................................................................... 37
Figure 18 - A StrategicFunction Instance ..................................................................................... 37
Figure 19 - The evaluateAt: methods ............................................................................................ 39
Figure 20 - Comparison Graph for Scenarios ............................................................................... 40
iv
1 Introduction
1.1 Motivation
The future cannot be accurately predicted.
Although financial reports can be helpful when
analyzing how a business has been doing, decision-makers need to know how the business will be
doing in the future. A solution to this problem must allow a decision-maker to model the future
alternatives and to see how they impact the business. Scenario planning with a financial model
framework is one way to deal with an uncertain future. A financial model framework has been
developed at the University of Illinois through a National Center for Supercomputing Applications
(NCSA) industrial partnership with Caterpillar, Inc. This thesis describes the design of a strategic
planning tool that extends the functionality of this financial model framework.
The rest of this chapter introduces the examples that will be used throughout the paper. The next
chapter provides some background information for financial models, a decision model, and scenario
planning. An understanding of this domain will be used when evaluating design trade-offs. The
third chapter describes what the strategic planning tool looks like from a user’s perspective. The
architecture and object design chapter of the strategic planning tool is next. The final chapter
suggests possible future work.
1.2 Example Use
Two continuing examples will be used throughout this thesis. This section introduces the decisionmakers for the examples and describes the decisions they wrestle with. The people, companies, and
products used in these two examples have been created for the examples, and any correspondence
to real people, companies, and products is accidental.
Farmer Bob has used the financial model framework to model his farm operations and now wants
to use it to plan for next season. He has to decide whether or not to buy an improved, but more
expensive, pesticide. He also has to decide how much soybeans and corn to plant next season.
Some of the factors influencing his decisions, such as seed and fertilizer cost and crop selling price,
1
are financial. Others, such as weather conditions and crop rotation principles, are not financial.
And some, like expected pesticide effectiveness, are only estimated. A strategic planning tool will
help Bob evaluate his options.
Manager Jill is in charge of factory operations at a toaster production plant for Generic Appliances,
Inc. Generic Appliances is also pushing to cut expenses. Some of Jill’s concerns include supply
purchases, machine utilization, and worker shift schedules. Buying from a different supplier could
reduce supply expenses. Hiring more employees could help utilize the factory machines better. She
hopes to use a strategic planning tool to evaluate how these decisions impact the factory’s “bottom
line” profitability.
2
2 Background
2.1 Financial Model
A financial model is a representation of the financial state of a business. Any financial model should
include several basic features. First, users should be able to split and break down the data for any
selection criteria, such as time period, business division, and product model. The financial model
should have good reporting tools that help users to visualize the data in many ways. Also, it should
encapsulate all of the business logic and rules for how values are derived. Since the business logic
will probably change throughout the life of the business, it should be easy to change the rules
without a large redesign of the financial model.
These features let a financial model serve several purposes. The primary purpose of a financial
model is end of the period reporting and analysis. The model's reporting framework should be
flexible enough to generate any end of the month report, although a simple error analysis and
correction system may need to be added. By adding a more complex transaction system, a financial
model also could serve as the bookkeeping system for a business. This addition could require
developing a separate interface for data entry, and the whole model would need to be designed for
concurrency and real-time transaction concerns.
A third use of a financial model is planning. Planning can be separated into operational and
strategic planning. Operational planning, or day-to-day planning, involves making decisions such as
when to purchase supplies, when to schedule workers, and how to configure the assembly line. It is
more suited to a factory model or simulation tool. Strategic planning is where a financial model can
be most beneficial. Strategic planning is for more long-term decisions, and strategic decisions are
analyzed by how much risk they are to the “bottom line.” A financial model can be used for simple
strategic planning by storing temporary or budget values in the database. These values would be
loaded from the database, and the financial model would apply the normal business logic to them.
The budget results would be reported the same way that historical values are reported.
Unfortunately, budget values stored in a database are static and cannot react to future conditions. A
more complete and useful strategic planning tool is the topic of this paper.
3
The Caterpillar Business Modeling Team, working through an NCSA industrial partnership, has
developed a flexible financial modeling system [Yoder].
The financial model framework was
developed in VisualWorks Smalltalk [PP95] running on top of an ORACLE relational database.
The financial model is not intended to be a bookkeeping system, but includes frameworks for
displaying “drill-down” reports, summary reports, detailed reports, and graphs. It also includes
formula object and query object frameworks. [BY97] An especially important feature is how the
data that encapsulates the business logic and parameters for the various frameworks is stored in a
database. This feature allows developers to easily customize and build financial models for new
businesses using a financial language and visual programming tools, rather than the language of the
frameworks, Smalltalk. This financial model framework is the foundation for the strategic planning
tool described in this paper. Throughout the rest of this paper, “the financial model” refers to the
Caterpillar/NCSA Financial Model Framework and financial models built from it.
2.2 A Decision Making Model
Decision theory is a broad field of study with many different approaches. Some approaches use
probability and expected value analysis to make decisions, while others use rule-based expert
systems.
Game theory considers the objectives of decision-makers and analyzes when those
objectives conflict with each other. [PCP] Which approach is best usually depends on the field of
study. Investors worried about risk would likely rely on expected value techniques, while artificial
intelligence researchers are concerned with expert systems that automatically make decisions based
on input from the environment and knowledge bases. Psychologists and economists, on the other
hand, are more interested in game theory. The purpose of the strategy planning extension is to help
decision-makers evaluate their decisions. It is not an expert system that will replace a decisionmaking manager, and it does not use probabilistic methods to predict the most reasonable outcome.
Recently, data mining and OLAP (On-line Analytical Processing) have been used in decision
support systems for huge databases. [Codd93] The strategic planning tool, on the other hand, can
be used with smaller databases because it does not try to derive relationships in the data. Instead, it
tries to accurately model business logic and rules. Its goal is to help decision-makers visualize the
potential impact of their decisions so they either will have more confidence in their decisions or will
start planning for alternative futures. For the purposes of the strategic planning tool, a much
4
simpler decision model is used. The system only needs a model that can describe and represent the
effect of a decision-maker's decisions.
One important distinction regarding decisions is the difference between implicit decisions and overt
decisions. [Forrester92] Implicit decisions, sometimes called unconscious decisions, are in terms of
things that cannot be directly controlled. For example, toaster shipments cannot be immediately
changed, but are instead a function of factors such as available machines, machine utilization,
available supplies, and manpower. Available supplies, in turn, are a function of supply orders and
the suppliers' ability to deliver. Factory production is actually an unconscious decision based on
those other factors. In this same example the overt, or conscious, decisions are factors such as
supply orders, employee hirings, and shift schedules. A manager has more direct, conscious control
over these factors.
The strategic planning system’s decision model will not distinguish between implicit and overt
decisions. Implicit decisions could be derived from overt decisions, but doing so could require
complete marketing, source and supply, and factory models which encapsulate how the quantitative
values for those decisions are derived. Being aware of the difference, however, can be helpful when
developing a strategic plan. Modeling implicit and overt decisions uniformly would ease a transition
to using these other business models in the future.
One special type of decision is a policy. A policy is a decision to automatically enable an action
whenever certain conditions are present. An example would be to purchase more toaster supplies
automatically when current supplies will be exhausted in a week. Realizing that ethanol demand is
directly proportional to gasoline prices, Farmer Bob could have a policy of planting more corn when
the gasoline price increases over a certain amount. The results of a policy are the same as any other
decision, but the instigation of the policy is automatic. The decision-maker only intervenes to set up
the policy initially.
The process behind making a decision can be broken into two steps: recognition time and reaction time.
Recognition time is the time it takes to realize what the future is most likely going to be and what
course of action is needed. This time is when a decision’s risk reaches an acceptable level or when
5
unforeseeable factors forcing a new course of action come into play.
A good example of
recognition time is the time it takes Farmer Bob to realize his crops have been infested by an insect
that was not killed by his normal pesticide. Reaction time is the time it takes a company to adjust its
policies, to make decisions, and to follow through with the decisions that will help the company in
the recognized future. Reaction time is the time it takes Bob to run to the store to buy a new
pesticide and to apply it to his fields. In some circumstances, reaction time could take too long. For
example, building a new toaster factory which will be completed in three years has too long of a
reaction time when Jill’s factory is trying to meet an immediate increase in demand. The strategic
planning tool helps reduce both recognition time and reaction time.
2.3 Scenario Planning
Strategic planning in this system is designed around a technique known as scenario planning. The
U.S. Air Force originally used scenario planning after World War II to plan military strategy
alternatives. Scenario planning moved to the business domain during the 1960’s. The full potential
of scenario planning was realized by Royal Dutch/Shell Oil Company, which used scenario planning
to anticipate and prepare for the oil crisis of the 1970’s and the price crash of the 1980’s. Shell's
success with scenario planning led some to believe scenario planning is a technique for predicting
the future. In reality, however, scenario planning is a technique to help prepare for and make better
decisions about the future. [Schwartz91]
A scenario is a story describing a possible future. As part of the story, a scenario includes signposts
that indicate how the future is unfolding.
Also a scenario should have a descriptive name.
Memorable names, such as "Global Marketplace" and "Deep Recession," give decision-makers a
common terminology with which to brainstorm and discuss ideas. Some quantitative information
can help clarify the impact of a scenario. The story behind the scenario, though, is what gives the
scenario meaning in the eyes of the decision-maker.
Since part of the goal of scenario planning is to get decision-makers to start thinking about an
uncertain future, scenarios should never be presented in isolation. They should be presented in sets.
Since the future could turn out several different ways, there should be a scenario describing each of
6
the possible futures. Of course it would be unfeasible to try to consider every possible future.
Instead, several representative scenarios are used. Because writing stories takes a lot of time, the
total number of scenarios should be small.
Two scenarios are too few to produce a good
understanding of how the future could impact a business. Three scenarios are problematic because
of the psychological urge to assume the middle choice. Depending on the complexity of each
scenario, six or more scenarios may be too difficult to compare simultaneously. Four or five
scenarios would be preferred. Four scenarios prevent a "middle-of-the-road" choice, while the fifth
scenario can be an offshoot that challenges normal assumptions.
Scenario planning directly addresses the problems of recognition and reaction time. The signposts
in a scenario's story help to reduce recognition time. By presenting several likely futures, a decisionmaker is encouraged to plan for many possible futures. When a decision-maker realizes a particular
scenario's signposts are occurring, he implements the appropriate plan. Of course, a plan usually
must be implemented before the signposts reveal themselves, but scenarios help decision-makers go
into a plan with their eyes wide open about possible risks. If the signposts begin to indicate that a
different scenario is unfolding, the company can react faster using a contingency plan developed
during scenario planning.
Scenario planning also excels in generating a consensus among decision-makers. The common
terminology introduced encourages group discussions. Forcing them to consider multiple scenarios
often challenges their assumptions and mental models of how the business works. Challenging their
assumptions makes them more open to each other’s ideas. Sharing mental models inevitably helps
them to better understand how the future can impact the “bottom line” and where the business
could be vulnerable.
Here are some scenarios that will be used in the examples. None of the scenarios are presented in
full; see The Art of the Long View [Schwartz91] for some good examples of scenarios.
Manager Jill’s scenarios:
1. Microtoasters - a new microwave which can also toast is invented
2. Labor Unrest - a union strike reduces factory output
7
3. Anti-Brandmania - consumers are more concerned about low cost than brand names
4. Globalization - increased sales in new global markets, unaware of brand names
Farmer Bob is considering four scenarios:
1. Waterworld/Sahara - severe weather reduces crop yield, but selling prices are high
2. Little Government - government cuts back farm aid and price support
3. Successful Season - crop yield between Waterworld/Sahara and Beautiful Sunset, prices
are right at the ten-year average.
4. Beautiful Sunset - outstanding weather, increased exports, increased ethanol demand
A fifth possible scenario, which will not be used, is
5. Farmers’ Almanac - exactly what the almanac says
2.4 Additional Background
The design of the strategic planning tool has been influenced by several software design ideas and
practices. These influences include frameworks, refactoring, and patterns.
Framework is defined in many different ways. In most cases, a framework is one way in which a
system takes advantage of re-use. For some purposes the infrastructure code which glues together
reusable components is called the framework. Other times, the reusable components themselves are
called frameworks. For purposes of this paper, framework will be defined as a reusable, domainspecific design. In any case, it is important to realize frameworks are not complete applications.
They are the reusable and customizable skeletons which are common between applications in a
certain domain. HotDraw [Johnson92] is an example of a drawing framework and CORBA is a
distributed object framework. [OMG]
Frameworks can have different scopes. A simple framework could be for relational database queries
or graphing data.
The financial model is a more domain-specific framework for financial
applications, and it is composed of several other frameworks. The common thread throughout
these frameworks is that they have been designed for maximum reusability within their domains.
8
The strategic planning extension described in this paper tries to keep with the spirit of the lowerlevel frameworks that compose the financial model by minimizing its dependencies on other
frameworks.
One key consideration when extending any system is to not break the system. Of course this is
easier said than done. Inevitably the existing system will need to be changed to support some
unplanned for features of the extension. How can the systems’ correctness be ensured and how can
the system be extended while not sacrificing its usability?
One approach for ensuring a system continues to work properly is to use a regression test suit.
Regression tests are repeatable tests that test as much of the system's functionality as possible. On a
regular basis, either nightly or when the system changes significantly, the regression test suite is run
to search for newly introduced bugs. The most important evaluation criterion for a regression test
suite is coverage. The percentage of code tested by the test suite is its coverage. The effectiveness of
the test suite depends upon it exercising every line of code and every path through the code.
Complete coverage is difficult to achieve, and it is even more difficult in frameworks because they
may not utilize all of the code for a particular application.
A second approach is refactoring. Refactoring is a formal approach for evolving a design. A
refactoring verifies pre-conditions before making a change so only valid operations are performed.
Refer to Refactoring Object-Oriented Frameworks [Opdyke92] for more details about refactoring.
Extending a system for a purpose it was not initially designed for usually requires a large refactoring
effort. The financial model, though, is continually being refactored to make its financial reporting
and business logic language more flexible and expressive. This refactoring effort helped the design
of the strategic planning tool because the financial model framework could go through smaller and
less painful refactorings to get ready for the strategic planning tool. It is hard to pinpoint specific
changes that served the goals of the strategic planning tool but did not also improve the financial
model in its original reporting domain. The gradual, iterative evolution of the financial model
exemplifies the effectiveness of iterative development when building a framework. It also shows
how a framework’s design can benefit from something saying, “What if, down the road, we want to
9
use the framework for something new?” Flexibility versus complexity is a difficult trade-off in
framework development, but brainstorming reasonable incarnations of a framework’s use can help
find a balance for the trade-off.
First used by Christopher Alexander to describe city and building architecture, the concept of
patterns has been adopted for describing computer software architecture. [Lea94] A pattern is a
common solution to a problem in a context.
Unlike most design descriptions, which only
emphasize the solution, patterns emphasize the forces and trade-offs at work for a particular
problem. Patterns also discuss when the pattern's solution is appropriate and inappropriate. Just as
object-oriented programming is a way to reuse code, patterns are a way to reuse design. Patterns
range in complexity from simple coding style idioms, to design patterns, to architectural patterns, to
application patterns. Design Patterns [GOF95] and the Pattern Languages of Program Design books
[PLoP1, PLoP2, and PLoP3] have many good examples of effective patterns. In this paper, patterns
are introduced with bold type.
10
3 The User’s Perspective
Part of the goal of a framework is to develop a language which that it very easy to build applications
in the framework’s domain. From a user’s perspective, this language will be domain-specific and not
look anything like the underlying development language. Sometimes, this language is visual, bases
on graphics and dialog boxes, rather than on text. Creating a visual language is the Visual Builder
pattern in the framework’s evolution. [RJ97] The strategic planning language has five principle
concepts: scenarios, business rules, decisions, policies, and comparison sets. The first section of this chapter
introduces the users of the strategic planning language. The following five sections discuss the
principle language concepts and the Graphical User Interfaces (GUIs) they can use for visual
programming.
3.1 Users
Financial model users have four possible roles: developer, database administrator, modeler and
accountant. The developer designs and programs the underlying frameworks using VisualWorks™
Smalltalk. The database administrator sets up the Oracle relational database backend, creates users,
and manages the security framework. The modeler understands how the business logic is computed
and how the financial model's information should be displayed. The accountant is the end-user who
interacts with a completed financial model.
Users of the strategic planning tool can have two additional roles: futurist and manager. The futurist
role is for someone who has some ideas about how the future may turn out. This person could be
an economist or market analyst. The futurist is responsible for creating, inputting and managing
scenarios. The manager role is for a decision-maker. The manager is the end-user who models
possible decisions and evaluates their impact.
Users with a modeler, futurist, or manager role will use the visual builder in the strategic planning
tool to define an application.
11
3.2 Scenarios
Scenarios have two distinct parts: qualitative information and quantitative data. Each scenario has a
basic description that includes a name, an author, and a version number. Also, a scenario includes a
summary, a story, and a list of signposts. This qualitative information is entered by the futurist using
a visual builder. Although the qualitative information is a scenario, it could be organized many
different ways, providing a standardized template will help managers by giving them a normal,
anticipated way to view the scenario information in a more structured form.
While the qualitative information helps a manager understand and relate to a scenario, the
quantitative information is more useful in the financial model.
Unfortunately, generating
appropriate data for a scenario is not straightforward. Historical data can be used for many
statistical approaches, but the results could have large uncertainty factors. In quickly evolving
markets, there may not even be appropriate historical data on which to model all scenarios. The
strategic planning tool assumes that the futurist has developed the appropriate statistical models by
using a separate statistical package.
Unlike historical data, which could be stored as daily transactions, scenario data is summary data for
a fixed time period. For most industries, long-term planning data will be yearly, but for quickly
changing or short business cycle industries, the data could be monthly. For quantitative data, each
scenario should indicate the time interval length (monthly or yearly) along with a collection of
datasets. Each dataset is a series of values (fixed amounts, changes, or percent changes), along with
the financial account and product models to which the data applies.
The strategic planning visual tool that a futurist would use to build scenarios is shown in Figure 1.
The top half of the window provides description and summary information. The Story Editor and
Signpost Editor buttons open new windows that contain text editors. The Datasets section is used
for entering quantitative data for the scenario. Each row of the table corresponds to one dataset,
and there is one column for each month or year forecasted by the scenario. In Figure 1, the table
contains four datasets, each with seven years of percent changed values. If a large amount of data
were coming from the output of a statistical package, it would probably be easier to write a script to
save the data to the database.
12
Figure 1 – Scenario Editor
3.3 Business Rules
The financial model contains business logic and formulas used for deriving financial values from
transactions stored in a database. These transactions may have migrated to the financial model from
a general ledger system. If this is the case, the ledger system probably encapsulates additional
business logic. Also, additional business rules may have been applied before entering transactions
into the general ledger system. An ideal situation would be to have all of the business logic and rules
in one place, but this situation is not very likely, especially for larger businesses, which deploy and
upgrade various systems over many years. The financial model may not have all of the business
rules necessary to evaluate a scenario. One example is variable costs, which are those costs directly
13
proportional to production. Crop seed is a variable cost, as is wire for toaster coils. To the financial
model, sales and variable costs are simply dated transactions stored in database records.
By
definition, though, variable costs are the non-fixed costs directly dependent upon sales.
For
financial analysis of historical data, the financial model does not need to know this relationship.
However, when a scenario says that in two years sales will drop by five percent but does not say
anything about variable costs, variable costs should drop by a corresponding percentage. The
strategic planning language allows these extra relationships to be represented as business rules.
A business rule computes a function for a single business entity. A business entity often corresponds
to a financial account combined with a product selection. Examples of business entities are net sales
of corn and depreciation expenses for a machine on the factory floor.
Here are some examples of how business rules can be used:
1. Depreciation Expense := Fixed Assets * 7%
2. Variable Cost of Hogs := Number of Hogs * $200
3. Tax Owed Expense(t) := Net Income(t-1) * 17% - Prepaid Tax Expense(t-1)
4. Sales of Corn := Acreage of Corn Planted * Bushel Corn Yielded per Acre
* Dollars per Bushel of Corn
The first rule relates Depreciation Expense to Fixed Assets across all products. The second rule
relates the cost of feed (a variable cost) to the number of hogs owned by Farmer Bob. The third
rule demonstrates a time lag by defining a flat tax rule which bases the amount paid to the
government in the current year, to the previous year’s prepaid taxes and net income. The visual
builder in Figure 2 shows the fourth rule.
A modeler would use the GUI in Figure 2. The Account combo box refers to some financial bit of
information, such as Sales. This financial information was either generated from the results of a
query or from other business rules and formulas. More than one product can be selected in the
Products list. The Function section is used for building a function whose result will be stored in the
business entity. The New Term buttons prompt for a number, a parenthesized subexpression, or a
14
Figure 2 - Business Rule Editor
business entity. The new term is sequentially appended to the function. Time Term button appends
a time lag to the last term.
For a business rule to be meaningful, it must either define a final business entity that users will use,
or it must be referenced by other functions. In other words, the rule must be internally referenced
within the financial model, or it must be possible to reference the rule from an external source. To
help see the problem, consider the following rules:
1. Operating Profit := Variable Margin - Period Costs.
2a. Period Costs := a query result
3. Depreciation := Fixed Assets * 7%.
If only rules 1, 2a, and 3 are used, Operating Profit will be derived from the query result of Period
Costs. For Operating Profit to reflect the Depreciation in rule 3, rule 2b must be used instead of 2a.
This new rule connects Operating Profit’s derivation to Depreciation through Period Costs.
2b. Period Costs := R&D Expense + Office Expense + Depreciation + Other Expenses
The time functions should be dependent on past results.
Supply Expense(t) := Production
Quantity(t+1)*30% is not allowed, because it is not a realizable function and could introduce cycles
in the business logic. While this prevents a user from creating cycles in the business logic with
15
respect to time, care still must be taken to avoid non-time dependent cycles in business logic.
Debugging tools for business logic could be used to avoid this problem. [RJ97]
3.4 Decisions
When the scenarios and extra business rules have been defined, the strategic planning tool is ready
for use by a manager. A decision is a business rule with an explanation and a time. Like scenarios,
decisions have both qualitative and quantitative information. A decision's qualitative information is
its name, owner, version number, and comment. The comment field lets the manager describe the
reason for the decision, how the decision will be carried out, or any other useful information. On
the quantitative side, a decision also has either a function representing the financial impact of the
decision or a set of other decisions.
The GUI editor for single decisions is shown in Figure 3. A single decision only affects one business
entity at one point in time. Notice the bottom half of the editor is similar to a business rule editor.
A single decision also has an implementation lag time. Lag time is the amount of time after a
decision is made that the function should be applied.
Here are some decisions that could be represented as legal decisions:
1. Office Expense(t) := Office Expense(t-1) * 0.95
2. Land for Corn(t=current year) := Land(t=current year) * 60%
The first decision is to decrease office expense by five percent. The decision’s comment could
indicate what steps are being taken to reduce office expense. The second example decision is used
in Figure 3.
16
Figure 4 – Composite Decision Editor
Figure 3 – Single Decision Editor
Decisions can be constructed from other decisions. The strategic planning visual builder for
composite decisions is shown in Figure 4. The composite decision is to plant corn and soybeans at a
60% to 40% ratio. This composite decision is modeled as two single decisions, one to plant corn on
60% of the land and another to plant beans on 40% of the land. The Add and Edit buttons in the
GUI open an editor for either a single decision or a composite decision.
17
3.5 Policies
Policies can be viewed in two different ways. One perspective is that a policy is a decision which,
instead of having a fixed application time, can be applied at any time under certain conditions. A
policy can also be viewed as a manager-controlled business rule with a conditional statement.
Here are some examples of how policies are used:
1. if (Profit(t-1) > 0) then R&D(t) := 10% * profit (t-1)
2. if (Corn Yield > 10000) then Food Sales := 10000
3. if (Corn Yield > 10000) then Sales to Chemical Companies := Corn Yield - 10000
The first example says that if Jill’s factory makes a profit, ten percent of the profit should be
reinvested in research and development. The second and third examples indicate that the first ten
thousand bushels of corn are sold for food and any extra corn is sold for chemical processing
18
Figure 6 – Conditional Editor
Figure 5- Policy Editor
Figure 5 shows the strategic planning visual builder for policies. Policies have the same name,
owner, version, and comment fields that decisions have, so this part of the GUI is the same as the
decision visual builders. Policies also have target business entities and functions like single decisions.
Instead of an implementation lag time, though, a policy has a conditional statement. The policy
shown in Figure 5 is a crop rotation policy. Since this policy is always followed (the conditional
statement is always true), it could be modeled as a business rule. Business rules, however, are usually
built by modelers to define how business entities are fundamentally computed. This policy’s
function describes a default annual decision and could be changed by the decision-maker at any
time.
19
Figure 7 – Selection Box
A policy’s conditional statement consists of two arguments and a comparison operator (i.e.: <, <=,
=, >=, and >). The arguments are functions themselves. The policy’s function is applied when and
if the conditional statement is true. Since the conditional statements could be true at any time, the
function could be applied multiple times. A conditional editor is opened by the Conditional Editor
button and is shown in Figure 6. This conditional statement checks if this year’s sales of corn and
beans and half of this year’s sales of hogs is less than last year’s sales for all products.
3.6 Comparison Sets
After defining the appropriate scenarios, business rules, decisions, and policies, a manager will want
to do a test run through the financial model and strategic planning tool to see how those scenarios
and decisions affect the business. To run an experiment, the selection criteria must first be set.
Date and product model selections carry over from the financial model. A scenario, the active
decisions, and the active policies must be also be selected for strategic planning. All business rules
are automatically active. When multiple decisions and policies are selected, they should not apply to
overlapping business entities. For example, if two decisions affect sales of toasters, the strategic
planning tool will not know which to use. Figure 7 shows a selection box for setting up strategic
selection criteria. In this example selection box, Jill’s selection would be used to check how the
three selected decisions and the two selected policies impact the business in a Globalization
scenario.
20
A second way to use the strategic planning tool is to compare scenarios, decisions, and policies. For
example, a manager may want to see how policies perform under various scenarios, or a manager
may want to find which decision is best for a particular scenario. A comparison set is a collection of
selection criteria settings that will be compared. The strategic planning tool calculates results for
each selection criteria in a comparison set. The separate results can then be merged into graphical
reports for easy comparison.
21
4 How It Works
Until this point, the strategic planning tool has been discussed in terms of why it is needed and what
it does. This chapter explains what the strategic planning tool looks like under the hood, what
design trade-offs were considered in its design, and how it works.
4.1 Architecture
Since the strategic planning tool is built to work with the financial model, much of its architecture
parallels the financial model’s architecture. In the following architectural diagrams, the right sides of
the diagrams show some conceptual models that make up the financial model, while the left sides
show the strategic planning tool.
Figure 8 - Editor Layers
22
Figure 8 shows a three-layered architecture for the financial model’s and strategic planning tool’s
editors. Visual Builders in the Strategic Editors module edit values from the object layer. The
objects in this module are responsible for querying data, distributing the data to the appropriate
locations in the interface, checking user input for correctness, and building new objects for storage
back in the database.
Mapping objects to a database can be handled several ways. The financial model is built on top of a
relational database, so the strategic objects could be stored using VisualWorks’ ObjectLens
framework. The second option, which is used by financial model, is a framework build from the
Query Object pattern. [BY97] This framework improves mapping between an object model and a
relational schema. The strategic planning tool could reuse the query object framework to store its
data in the same database or another relational database. A third option is to store values directly as
objects in an object-oriented database (OODB) that interfaces with VisualWorks, such as
GemStone. With the OODB approach, data describing the business logic and user interfaces
would be stored in the OODB, where it could be stored in object from. Historical data, such as
sales records, would remain in the relational database that the financial model is currently built
around and QueryObjects would be use to interface with the data.
Farmer Bob would probably prefer to keep all historical and planning data in the same relational
database because of the extra work involved in setting up a second database. When a relational
database is used for objects, approaches such as those discussed in “Crossing Chasms,” [BW96]
should be used. Using a single database is less of an issue for Jill, since the historical and planning
data probably comes from different departments and multiple databases are probably already
distributed throughout her appliance company. The disadvantage of using both relational and
OODBs is that the overall data model is split between two different database paradigms. Sticking to
one paradigm means developers do not have to learn a new paradigm and can reuse frameworks and
techniques already learned while developing the financial model. Shifting only the planning and user
interface data to an OODB has two key advantages. First, the OODB’s data model for planning
and user interface data is more straightforward because it maps directly to the run-time object
model.
Also, the qualitative data in scenarios and decisions, such as stories, comments, and
versions, maps better to an OODB where object ownership, security, and version information can
23
be controlled at the object level. Using an OODB for all of the data is probably not practical,
however, because historical financial data is likely already stored in a relational database. The query
object framework should be used in this case. With such a wide variety of legacy and complexity
issues, the strategic planning tool’s implementation should be independent of the underlying
database architecture to allow flexibility in database implementation.
Figure 9 shows an architectural diagram for the strategic planning tool when it is being used by a
manager. The bottom two layers behave just like above. An additional Business Logic Layer lies
Figure 9 - Logic Layers of a Completed System
24
between the User Interface and the Object Layers. This new layer is what gives the frameworks
dynamic runtime behavior. In the financial model, the Report Value module is responsible for
connecting window, menu, and query specifications to their corresponding values. In the strategic
planning tool, the Value Space module determines if a business entity’s value should be loaded from
a historical financial model query, from scenario data, or from the results of a business rule, decision,
or policy. The User Interface Layer consists of GUIs that display the output of a scenario and a
manager’s decisions. The Selection module lets the user enter selection criteria that affect the
Report Values and Value Space modules. Then the results of the Business Logic Layer module feed
back to the output GUIs in the User Interface Layer.
The detailed design will focus on the strategic planning parts on the left half of these architecture
diagrams. The financial model design is discussed only when necessary or useful for comparison.
4.2 Object Editing Interfaces
The financial model framework includes a series of GUIs for visually defining business logic and
reports. GraphSpecEditor, ReportWindowEditor, and ElementSpecEditor are classes that serve as
visual builders for the financial model. The strategic planning tool has its own set of editors for
creating and modifying strategic planning information. These GUIs were presented in the previous
chapter, and together they make up the Strategic Editing module. The classes and corresponding
figure numbers for these GUIs are ScenarioEditor (Figure 1), BusinessRuleEditor (Figure 2),
SingleDecisionEditor (Figure 3), CompositeDecisionEditor (Figure 4), PolicyEditor (Figure 5), and
ConditionalFunctionEditor (Figure 6). Each of the classes is a subclass of ApplicationModel. An
ApplicationModel behaves as a mediator [GOF95] between a model, which in this case is the object
being edited, and the model’s view and controller.
The editors have several responsibilities as mediators. They are responsible for parsing objects from
the Object Layer, wrapping them in ValueModels and distributing them to the appropriate
subcanvases. The editors are also designed to ensure safety. For example, each editor has the
instance variable hasChanged, which keeps track of whether or not the object has changed, so the
interface can prompt the user before discarding changes. Each editor also is responsible for
25
checking the user’s input when it is saved to make sure it makes sense and is legal. When the values
are legal, the editor instantiates the appropriate object from the object layer, populates the instance
variables with the corresponding values from its subcanvases and widgets, and pushes the object
into the database.
Since many of the editors’ models have common instance variables, the editors for those instance
variables are pulled out and grouped into separate classes. By composing complex editors from
simpler editor subcanvases, components of visual builders are reused.
BusinessEntityCanvas,
FunctionCanvas, DatasetCanvas, BusinessRuleCanvas, and DescriptionCanvas are reused in other
editors. The ScenarioEditor, for example, uses DescriptionCanvas and DatasetCanvas, while the
BusinessRuleCanvas itself uses FunctionCanvas and BusinessEntityCanvas. Splitting the editing
responsibility among several classes makes parsing and rebuilding the model more complicated
because the ValueModels that hold the model’s attributes are spread out over the instance variables
of several classes. This disadvantage is far outweighed by the advantage of reusing the subcanvas
classes’ control, widget specification, and value checking code.
4.3 Base Objects
The previous chapter discussed five key concepts: scenarios, business rules, decisions, policies, and
comparison sets. The first four of these correspond to objects that must be persistently stored. This
section defines these objects. Any new classes introduced will be discussed in the following
sections.
Scenario objects have five instance variables: description, summary, story, signposts, and datasets.
The description variable is a Description object, that identifies the Scenario. The summary, story,
and signposts variables are strings which make up the qualitative contribution of the Scenario. The
datasets variable holds the quantitative contribution of a Scenario in a DatasetCollection. Figure 10
shows how Scenario, Description, and DatasetCollection are related. Figure 1 shows an example
Scenario object is being built with a ScenarioEditor.
26
Figure 10 - Scenarios, Descriptions, and Business Rules
BusinessRule objects associate a function with a business entity to which the function is applied.
The entity variable is a BusinessEntity, and the function variable is a StrategicFunction. Figure 10
shows how BusinessRule and BusinessEntity are related. BusinessRule objects can be built with the
BusinessRuleEditor in Figure 2. Figure 2 provides an example of such BusinessRule.
Multiple decision objects can be combined to create a new decision object. To make it easier to
treat decisions uniformly, decision objects are implemented with the Composite pattern. [GOF95]
Using this pattern, a concrete decision object is either a CompositeDecision or a SingleDecision.
Both SingleDecision and CompositeDecision are subclasses of the abstract superclass
ComponentDecision.
ComponentDecision defines the shared public interface and the shared
instance variables, description and comment. The description variable is a Description object. The
comment variable is a string that could contain helpful reference information about the reason for,
implementation of, or implications of a decision. SingleDecision adds the variables rule, time, and
timeUnit. The rule variable is a BusinessRule that is applied for the decision. The timeUnits
variable holds either #months or #years, and the time variable indicates the number of months or
years, after a decision is made, that the business rule should be conservative. Together these make
27
up the reaction time discussed in Section 2.2.
Instead of business rules and reaction time,
CompositeDecision defines a variable, decisions, which stores a set of ComponentDecisions.
SingleDecision and CompositeDecision are built with SingleDecisionEditor in Figure 3 and
CompositeDecisionEditor in Figure 4, respectively. Those figures provide good examples of the
various types of decision objects.
The Policy class also inherits from ComponentDecision, so a composite policy can be made from
several policies. Additionally, Policy and SingleDecision objects could be grouped in the same
CompositeDecision. This feature is currently not supported by the strategic editors, however, to try
to keep the concepts separate and the visual language simpler for the modeler.
Like a
SingleDecision, Policy adds an instance variable, rule. The rule variable is a BusinessRule, but its
function is a ConditionalFunction instead of a StrategicFunction. Policy does not include time and
timeUnit variables for reaction time like SingleDecision does, so Policy can logically fall between
ComponentDecision and SingleDecision in the inheritance hierarchy. Figure 11 shows the revised
inheritance hierarchy for decisions. A Policy is built with a PolicyEditor shown in Figure 5 and the
Figure 11 - Composite Decision
28
ConditionalEditor in Figure 6.
Those editors show an example of a Policy object with it’s
ConditionalFunction
To make printing and identifying these base objects easier, they each define the methods #printOn:
and #key. The #printOn: method is used in the visual builders and selection box, and the #key
method is used for persistent storage and retrieval.
4.4 Base Support Objects
ComponentDecision and Scenario each have an instance variable of type Description. Description
contains the information needed to uniquely identify a scenario. These “primary key” values include
the name and author variables, which are strings, and the version variable, which is a Version object.
The Version class has a single instance variable, id, which stores a collection of numbers. These
numbers are used to generate versions such as ‘4’, ‘5.01’, and ‘5.01.3’. Version objects are useful
because of their methods. The #versionString method returns a string generated from the id
variable. Version objects understand < and =, so they can be compared and sorted. These
operators can be used to determine the latest version of an object. Version also has methods like
#increment, #addLevel, #trim, and #incrementLevel: which change the version collection. To see
how these work, assume a Version object, ‘v’, has id = ‘3.0.1’. v increment makes v versionString =
‘3.0.2’. v addLevel makes v versionString = ‘3.0.1.0’. v incrementLevel: 1 makes v versionString =
‘4.0.0’.
The Version class does not have to be implemented the way it is here. Another implementation
could use timestamps to indicate when the object last changed. The important idea for any version
implementation is that version information should be encapsulated in a separate object. The benefit
of this idea is that incrementing versions and sorting objects with versions is easy.
A BusinessEntity object is the combination of an account, such as ‘Net Sales’ or ‘Office Expense,’
and set of products, stored in the variables financial and products, respectively. BusinessEntity
objects are used in functions to build up business logic. They are also used as target locations for
29
ValueSpace methodsFor: 'computing'
valueAt: timedBusinessEntity
| futureEntities |
futureEntities := self futureEntitiesFor: timedBusinessEntity businessEntity.
^futureEntities inject: 0 into: [:sum :each | sum + (each valueAt: timedBusinessEntity time)]
Figure 12 - Managing BusinessEntities with Multiple Products in ValueSpace
the results of the functions. TimedBusinessEntity wraps its BusinessEntity, stored in the entity
variable, with an additional variable, time.
A TimedBusinessEntity is used to index into a
ValueSpace, and it can be created by sending the #timed: message to a BusinessEntity.
Since the products variable holds a set of strings, objects which use a BusinessEntity must handle
single and multiple products correctly. Figure 12 shows some code that deals with multiple products
in one BusinessEntity. ValueSpace with be discussed in depth later, but this example demonstrates
the difficulty of allowing multiple products. ValueSpace’s #futureEntitiesFor: method returns one
object for each product in timedBusinessEntity. Since only one value is requested, the values for
these objects are summed using the #inject:into: block.
Quantitative scenario data is stored in DatasetCollection objects. A DatasetCollection has three
instance variables: numberOfYears, timeUnits, and datasets. The datasets variable holds a set of
Dataset objects. The numberOfYears and timeUnits variables are used to calculate how many
values should be in each Dataset. DatasetCollections and Datasets are shown in the diagram for
Scenario and BusinessRule, Figure 10.
Each Dataset in the DatasetCollection has the following variables: entity, values, and type. The
entity variable indicates the BusinessEntity object for the data. The data is stored in the values
variable as an OrderedCollection of numbers. Each number can indicate how much the value will
#change, the #percent the value will change, or the #fixed amount the value will become. All of
the numbers for a single Dataset have the same type, however, which is indicated in the type
variable.
30
4.5 Business Logic Layer
Section 4.2 discussed the classes in the User Interface Layer for editing, and Sections 4.3 and 4.4
discussed classes in the Object Layer. This section details the Business Logic Layer, which is
between the User Interface and Object Layers. At run-time, many components will need access to
the values for various financial accounts. Values embedded in the Business Logic Layer can be
generated from historical data, scenario data, business logic, and decisions. All of these values are
stored in ValueSpace objects for dynamic, run-time evaluation. First, this section details what
objects are in the Business Logic Layer and explains how they find each other. Next, it describes
how the ValueSpace is initialized using a selection criteria and objects from the Object Layer. The
section finishes by explaining how a value for a specific BusinessEntity, with a specific product
selection, at a specific time, is selected from the wide array of choices.
ValueSpace is a repository that organizes all of the values and functions that will be used by the
strategic planning tool. A computed value for TimedBusinessEntity tbe, in ValuesSpace vs, can be
retrieved by vs valuesAt: tbe.
ValueSpace is implemented as a dictionary of dictionaries. The first dictionary is indexed by a
financial name (i.e., Net Sales), and the second dictionary is indexed by a product (i.e., bagel
toasters). The financial index and product index together are a BusinessEntity, so the second level
of dictionaries can be directly accessed by passing a BusinessEntity object to #valuesAt:. The
second level of dictionaries is populated with FutureEntity objects. All references into the
ValueSpace should be done from the top level ValueSpace object to hide the complexity of the
underlying structure and to decouple its implementation from the rest of the system. In this way,
ValueSpace presents a facade [GOF95] to the rest of the system.
Since every function needs to access these FutureEntity objects, the ValueSpace object must be
easily accessible from almost anywhere. The most straightforward notion is to apply the Singleton
pattern [GOF95] to ValueSpace. The Singleton pattern guarantees that there will only be one
ValueSpace object at a time and that it will be globally accessible at a fixed location, such as
ValueSpace instance.
Implementing ValueSpace as a singleton makes it impossible to compare
multiple ValueSpace objects, so this solution is unacceptable. Another possibility is for every object
31
that needs a ValueSpace to keep a reference to it. In some circumstances, this may require adding
an instance variable to a lot of classes. All of the objects that share a reference to the same
ValueSpace have a common scope, with respect to that ValueSpace. This second approach is the
Session pattern.
The Session pattern is used in the financial model. Many objects have a session variable, state,
which holds an FMState object. The strategic planning tool reuses FMState by adding an instance
variable, valueSpace. Since the financial model does not need this variable, it is added in a subclass
of FMState, StrategicState. Subclassing this way is an example of the Programming-By-Difference
pattern. [FY97] StrategicState's initialization loads objects from the database. StrategicState itself is
not persistent, so the selection criteria must be passed to it during initialization. The only strategic
planning tool objects that need to perform ValueSpace lookups are the functions discussed in the
next section. The session variable must be added to these function classes and any class that creates
these function classes.
It is interesting to note that the query object framework uses both the Session and Singleton
patterns. The session variable for a QueryObject is queryDataManager. If queryDataManager is nil,
then the singleton, QueryDataManager instance, is used.
A ValueSpace is populated with FutureEntity objects. Each FutureEntity holds the business rules
and policies that impact a BusinessEntity. Each FutureEntity can have at most one BusinessRule, at
most one Policy, and at most one FMStateFormula associated with it. The BusinessEntity for the
rule, policy, and formula is referenced in FutureEntity’s entity variable. If the entity is carefully
named to match the financial model database, FutureEntity can use its entity to generate a query for
historical data. FMStateFormula is a less flexible business rule that has been used on the reporting
side of the financial model to create functions without time and product attributes. It is stored in
the stateFormula variable.
Each FutureEntity must also store scenario data and a decision formula for each time period. This
information is held in the timedValues variable, which is an array of TimedFutureEntity objects.
Each TimedFutureEntity stores a single value from a scenario in its scenarioFunction variable and a
32
Figure 13 - FutureEntity
single ComponentDecision in its decisionFunction variable. The dynamically computed result of a
TimedFutureEntity is cached in the value variable. A TimedFutureEntity also holds a reference to
its parent FutureEntity.
Figure 13 show how TimedFutureEntity, FutureEntity, ValueSpace,
FutureEntity, and TimedFutureEntity are related. Figure 14 shows an instance of a ValueSpace
object.
FutureEntity and TimedFutureEntity have several instance variables that refer to the base objects.
FutureEntity also refers to its business entity, and TimedFutureEntity refers to its BusinessEntity
through is parent, stored in the futureEntity variable. Since each object knows its business entity,
FutureEntity and TimedFutureEntity do not need complete base objects. StrategicState leverages
this during its initialization by discarding the qualitative parts of BusinessRule, Scenario, and
ComponentDecision objects and storing only the functional parts in the FutureEntity and
TimedFutureEntity objects. So, although a FutureEntity could have a business rule and a decision
stored in its variables, both the business rule and the decision would be functions. The advantage to
this approach is that the scenarioFunction, decisionFunction, policyFunction, and ruleFunction have
the same interface.
33
Figure 14 - A ValueSpace Instance
When a StrategicState is initialized, it loads datasets and uses them to populate the values in its
valueSpace. The number of values in each Dataset determines the number of TimedFutureEntity
objects per FutureEntity. The size of a Dataset is stored in ValueSpace’s scenarioSize variable, so
these FutureEntity and TimedFutureEntity objects can be created by applying the Lazy
Initialization pattern. [Beck 97] For Datasets with a type variable equal to #fixed, each value is
wrapped in a StrategicFunction and split off to the appropriate TimedFutureEntity.
For the
Datasets with a #change or #percent type, a StrategicFunction is constructed based on the same
BusinessEntity, but at time (t-1) (i.e., the previous TimedFutureEntity).
A StrategicState is initialized with a StrategySelectionBox that contains a collection of decision
descriptions, a collection of policy descriptions, and a single scenario description. The StrategicState
loads the selected objects from the database and passes its valueSpace to each of these objects using
the #addSelfTo: method.
The object’s #addSelfTo: method puts a StrategicFunction in the
ValueSpace at the object’s entity location. Datasets put their fixed values in StrategicFunctionTerms
34
ValueSpace methodsFor: 'computing'
futureEntitiesFor: businessEntity
| financialDictionary |
financialDictionary := self values at: businessEntity financial ifAbsentPut: [Dictionary new].
^businessEntity products collect: [:product |
financialDictionary at: product ifAbsentPut: [
FutureEntity ofSize: scenarioSize for: businessEntity businessEntity]]
FutureEntity methodsFor: 'computing'
valueAt: time
(timedValues at: time) isNil
ifTrue:
[| timedValue |
timedValue := TimedFutureEntity new.
timedValues at: time put: timedValue.
timedValue futureEntity: self; time: time].
^(timedValues at: time) value
Figure 15 - Lazy Initialization in ValueSpace and FutureEntity
so the scenario data can be accessed through the same interface as decision functions and rule
functions. If a Dataset has values of type #percent or #change, it builds a StrategicFunction with a
TimedStrategicFunctionTerm that is dependent on the previous Dataset value for that entity.
When functions lookup values in a ValueSpace, they are are trying to retrieve the value of a
TimedFutureEntity. This value is evaluated by lazy initialization, as demonstrated in Figure 15.
FutureEntity and TimedFutureEntity are not created until they are first requested. Uninitialized
values are recognized by the #at:ifAbsentPut: and #isNil methods. The value is computed from the
decision, scenario, policy, business rule, state formula, and historical value referenced by that
TimedFutureEntity. Only one of these factors will be used to initialize the value variable, but
keeping the functions separated permits a strategy [GOF95] to determine function precedence.
TimedFutureEntity maintains the strategy.
The default strategy has the following order of
precedence from highest to lowest: decision function, scenario function, policy function, business
rule function, FM state formula, the previous timed value, and query object. When the value
variable is lazy initialized, the strategy starts with the highest precedent function, in this case decision
function, and checks to see if a decision function exists for this TimedFutureEntity. If it exists, then
the result of decision evaluateAt: time is stored in the value variable. If a decision function does not
35
FutureEntity methodsFor: 'computing'
computeQuery
"generate query"
computeValue
self policyFunction notNil ifTrue: [^self policyFunction evaluate].
self ruleFunction notNil ifTrue: [^self ruleFunction evaluate].
self stateFormula notNil ifTrue: [^self stateFormula value].
self query values asOrderedCollection first
TimedFutureEntity methodsFor: 'computing'
computeValue
self decisionFunction notNil ifTrue: [^self decisionFunction evaluateAt: time].
self scenarioFunction notNil ifTrue: [^self scenarioFunction evaluateAt: time].
^self futureEntity value.
Figure 16 - Strategy in FutureEntity and TimedFutureEntity
exist, then the strategy proceeds to the next highest precedent function. The lowest level is query
object. At this level, the strategy tries to construct a query into the historical database, using an
appropriate business entity.
Figure 16 shows how FutureEntity and TimedFutureEntity work
together to implement the default strategy.
4.6 Functions
BusinessRule introduced the StrategicFunction class, and Policy introduced the ConditionalFunction
class. These functions are used to derive values in TimedFutureEntity objects in a ValueSpace.
They are an example of the Function Objects pattern. [BY 97] This section discusses how these
functions are constructed and how they work.
A StrategicFunction contains an OrderedCollection of StrategicFunctionTerms and implements the
#evaluate method. A StrategicFunction could be built from the ground up as a binary tree, but
instead it uses a design that produces flatter trees and makes the overall function easier to see and
edit. A StrategicFunctionTerm is composed of an operator (+, -, *, or /) and a value. The value can
be a StrategicFunction, a BusinessEntity, or a number. The first term in a StrategicFunction always
has a + or - operator. How to compose these terms is best seen with an example. The letters in this
example represent BusinessEntity objects. To represent the function A - (B * C) / 3, the top level
36
Figure 18 - A StrategicFunction Instance
Figure 17 - Functions
StrategicFunction needs three terms. The first has operator + and value A. The second has
operator - and a StrategicFunction for the value. The third term has operator / and value 3. The
nested StrategicFunction has terms +B and *C.
Figure 17 shows how the functions and their support classes are related. Figure 18 shows an
instance of a StrategicFunction object. Functions can be constructed with the visual builders in
BusinessRuleEditor (Figure 2),
SingleDecisionEditor (Figure 3), PolicyEditor (Figure 5), and
ConditionalFunctionEditor (Figure 6).
It is important to note that StrategicFunction’s #evaluateAt: method evaluates terms sequentially
from left to right, as is the case in Smalltalk. Thus, operator precedence does not apply and can only
be imposed by building a tree of StrategicFunctions. Each StrategicFunction child corresponds to a
parenthesized expression. Unless otherwise specified, all StrategicFunctions are evaluated with
respect to the same time period. This time must be provided during evaluation with function
evaluateAt: aTime.
TimeStrategicFunctionTerm is a subclass of StrategicFunctionTerm, adding a
timeLag variable. The timeLag variable holds a positive integer for a time delay which makes
functions such as A[t-2] - (B * C) possible. In this example, timeLag equals 2.
37
A StrategicFunctionTerm holds on to a BusinessEntity and will create a TimedBusinessEntity, if
needed. The value of this TimedBusinessEntity must be looked up in a ValueSpace. Therefore,
every function must follow the Session pattern by keeping a reference to its ValueSpace. Also, every
function that creates a function must also know the session with the correct ValueSpace. Since
ValueSpace performs all of the lazy initialization of its future entity object, which contain the
functions, the ValueSpace is responsible for building the functions. Thus, ValueSpace must keep a
reference to its StrategicState to pass along to new functions.
Conditional functions are used by policies to constrain the application of a business rule. The
ConditionalFunction class has four variables: operator, left, right, and function. Legal values for
operator are <, <=, =, >=, and >.
Figure 19 shows how the #evaluateAt: method is implemented in various classes. StrategicFunction
sequentially evaluates its terms and combines them into a total. ConditionalFunction only evaluates
its function if the left-operator-right conditional evaluates as true. StrategicFunctionTerm returns a
value, continues to evaluate a subexpression, or looks up a value in ValueSpace.
TimedStrategicFunctionTerm does the same, except it subtracts the timeLag first.
38
StrategicFunction methodsFor: 'actions'
evaluateAt: time
^terms inject: 0 into: [:total :term | total perform: term operator with: (term evaluateAt: time)]
ConditionalFunction methodsFor: 'actions'
evaluateAt: time
^((left evaluateAt: time) perform: operator with: (right evaluateAt: time))
ifTrue: [function evaluateAt: time] ifFalse: [nil]
StrategicFunctionTerm methodsFor: 'actions'
evaluateAt: time
value isReal ifTrue: [^value].
(value isKindOf: StrategicFunction) ifTrue: [^value evaluateAt: time].
^state valueSpace valueAt: (value timed: time)
TimedStrategicFunctionTerm methodsFor: 'actions'
evaluateAt: time
^super evaulateAt: time - timeLag
Figure 19 - The evaluateAt: methods
4.7 Generating Output
The financial model includes several frameworks for displaying results, including a table report
framework, a summary report framework, and a graphing framework.
There are two routes toward using these frameworks with the values in a ValueSpace. In the first
approach, the frameworks could be redesigned to take FutureEntity objects as input. In the other
approach, the values in the FutureEntity objects need to be processed into or wrapped as different
objects so the frameworks know how to use them. Although the frameworks could be carefully
refactored, redesigning them is very likely to introduce bugs into working financial models.
Therefore, the second approach will be used.
39
The graphing framework uses ElementSpec and QueryObjects to get values for a graph and uses
complicated ReportGraphSpecs to define the appearance of a graph. It was originally designed to
graph raw values in a TwoDList of numbers, so this original interface could be used. To use this
interface, ValueSpace must be able to pull out the numerical values in its TimedFutureEntity objects
and put them into the TwoDList in the right order.
ValueSpace implements the
#businessEntityAsGraph: method, which puts data in the format the graph framework requires and
opens a graph based on time. It also implements the #valueAtFutureEntity method:, which returns
a list of every value in the TimedFutureEntity objects of a FutureEntity.
Figure 20 - Comparison Graph for Scenarios
40
These techniques are used by ComparisonSet to get values for each ValueSpace it holds so it can
construct a comparison graph similar to Figure 20. Other reports are usually not time based, so they
can simply take advantage of the fact that SingleElementSpec and TimedFutureEntity are
polymorphic with respect to the #value method.
41
5 Conclusions and Future Work
There is always room for improvement in software design. From a usability standpoint, several
areas could be improved. The visual builders check user input, but they could benefit from several
approaches discussed in “The CHECKS Pattern Language of Information Integrity.”
[Cunningham95] An integrated context-sensitive help system would be another welcome addition.
Currently, the success of the visual builders hinges on the user inputting valid rules which, among
other things, do not introduce logic cycles or feedback loops. Framework debugging tools are
needed to avoid this problem. [RJ97] From a conceptual standpoint, there are several ways the
strategic planning tool can be for extended. It would be interesting to see other decision models
interface with this system’s model. A more complex decision model could provide risk analysis
support and automatic scenario data generation. It would also be interesting to see a factory model
drive the business rules in this system.
The financial model was undergoing its own refactoring during the design of the strategic planning
tool. As a result, the strategic planning tool had to remain independent of the base financial model
in a couple areas. Now, the old and new systems could be merged in two keys areas. First, the
financial model uses ElementSpecs heavily, and ElementSpecs are tied to database queries. This link
between ElementSpecs and QueryObjects is a problem because the strategic planning tool does not
store its dynamic data in a database. The ElementSpec framework could be extended to use
BusinessEntity and TimedBusinessEntity objects instead of QueryObjects in order to map into a
ValueSpace object instead of a database. The second issue is that a FormulaSpec framework has
been added to the base financial model.
It is used to represent and evaluate formulas.
FormulaSpecs would need to be refactored to support timed functions. Also it cannot currently
perform ValueSpace lookups. Applying the strategy pattern to FormulaSpec would solve this
second problem. The strategy would allow a FormulaSpec to look a different place for its values
This design is just a snapshot of the financial model and the strategic planning tool. The best test of
the strategic planning tool would be to have real users try it out. With more refactoring and design
iterations, the framework can only become more powerful, more flexible, and easier to use. The
42
strategic planning tool also can serve as a gathering point for bringing all business logic, from a
financial model, a database and a factory model, together.
43
Bibliography
[Beck97] Beck, K. Smalltalk Best Practice Patterns. Prentice Hall, Upper Saddle River, NJ. 1997.
[BW96] Brown, K. and Whitenack, B. "Crossing Chasms: A Pattern Language for Object-RDBMS
Integration." In Vlissides, J., Coplien, J., and Kerth, N, editors. Pattern Languages of Program
Design 2. Addison-Wesley, Reading, MA. 1996. URL:
http://www.ksccary.com/ORDBJrnl.htm.
[BY97] Brant, J. and Yoder, J. "Reports." Collected papers from the PLoP '96 and EuroPLoP '96
Conference. Technical Report #wucs-97-07, Department of Computer Science, Washington
University Department of Computer Science. February 1997. URL:
http://www.cs.wustl.edu/~schmidt/PLoP-96/yoder.ps.
[Codd93] Codd, E.F.; Codd, S.B.; and Salley, C.T. “Providing OLAP (On-line Analytical
Processing to User-Analysts: An IT Mandate.” E.F. Codd & Associates. 1993. URL:
http://www.arborsoft.com/essbase/wht_ppr/codd/TOC.html.
[Cunningham95] Cunningham, W. “The CHECKS Pattern Language of Information Integrity.”
In Coplien, J. and Schmidt, D., editors. Pattern Languages of Program Design. pp. 145-156.
Addison-Wesley, Reading, MA. 1995. URL: http://c2.com/ppr/checks.html.
[Forrester92] Forrester, J. "Policies, decisions and information sources for modeling." European
Journal of Operational Research, Vol. 59, pp. 42-63. 1992.
[FY97] Foote, B. and Yoder, J. "Attracting Reuse." In Martin, R., Riehle, D., and Buschmann, F.,
editors. Pattern Languages of Program Design 3. Addison-Wesley, Reading, MA. 1997.
[GOF95] Gamma, E.; Helm, R.; Johnson, R.; and Vlissides, J. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley, Reading, MA. 1995.
44
[Howard95] Howard, T. The Smalltalk Developer’s Guide to VisualWorks. SIGS Books, New York,
NY. 1995.
[Johnson92] Johnson, R. "Documenting Frameworks using Patterns." Proceedings of OOPSLA '92,
Object-Oriented Programming Systems, Languages, and Applications. Vancouver, BC., Canada. Oct.
1992. URL: ftp://st.cs.uiuc.edu/pub/papers/HotDraw/documenting-frameworks.ps.
[Lea94] Lea, D. "Christopher Alexander: An Introduction For Object-Oriented Designers,"
Software Engineering Notes. Vol. 19, #1,. pp. 39-45. January 1994. URL:
ftp://g.oswego.edu/pub/papers/ca.ps.
[OMG] Object Management Group. “OMG Home Page.” URL: http://www.omg.org.
[Opdyke92] Opdyke, W. Refactoring Object-Oriented Frameworks. PhD thesis, University of
Illinois at Urbana-Champaign. 1992. Also Technical Report No. #UIUCDCS-R-92-1759,
Department of Computer Science, University of Illinois at Urbana-Champaign. URL:
ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdyke-thesis.ps.Z.
[PLoP1] Coplien, J. and Schmidt, D., editors. Pattern Languages of Program Design. Addison-Wesley,
Reading, MA. 1995.
[PLoP2] Vlissides, J., Coplien, J., and Kerth, N, editors. Pattern Languages of Program Design 2.
Addison-Wesley, Reading, MA. 1996.
[PLoP3] Martin, R., Riehle, D., and Buschmann, F., editors. Pattern Languages of Program Design 3.
Addison-Wesley, Reading, MA. 1997.
[PCP] Heylighen F.; Joslyn C., and Turchin V., editors. “Web Dictionary of Cybernetics and
Systems.” Principia Cybernetica Web. Principia Cybernetica Project. URL:
http://pespmc1.vub.ac.be/ASC/INdexASC.html.
[PP95] ParcPlace-Digitalk, Inc. VisualWorks User’s Guide. Revision 2.5. 1995.
45
[RJ97] Roberts, D. and Johnson, R. "Evolve Frameworks into Domain-Specific Languages." In
Martin, R., Riehle, D., and Buschmann, F., editors. Pattern Languages of Program Design 3.
Addison-Wesley, Reading, MA. 1997. URL:
http://st-www.cs.uiuc.edu/users/droberts/evolve.html.
[Schwartz91] Schwartz, P. The Art of the Long View. Doubleday Currency, New York, NY. 1991.
[Yoder] Yoder, J. “Financial Modeling Framework.” URL:
http://www-cat.ncsa.uiuc.edu/~yoder/financial_framework/
46