object oriented modeling and multistage stochastic programming€¦ · object oriented modeling and...

Object Oriented Modeling and Multistage Stochastic

Programming

Robert Fourer Leo Lopes

18th October 2003

Abstract

In this research, we study the applicability of object-oriented modeling techniques

to stochastic optimization. We propose a methodology that uses the UML to model

stochastic optimization problems.

1 Introduction

While Operations Research (OR) applications and software applications differ from each otherin fundamental ways, they also share some very important characteristics, which lie at theheart of the motivation for the development of software engineering methods. These charac-teristics include: system complexity; cross-disciplinary nature; and the interaction betweendomain experts and methodology experts. Furthermore, OR applications often include im-portant software components, and often reside inside Information Technology (IT) infrastruc-tures, further enhancing the value of finding commonality between development of OR-centricsystems and software engineering systems.

Over the last 30 years, software systems have increased in complexity to an astonishingdegree. In order to manage large projects, facilitate analysis and documentation, and enhancemaintainability and reliability, several software engineering techniques emerged over time.Two very important aspects of many of these techniques are: the object-oriented paradigm;and graphical modeling languages.

The main goal of this research is to investigate whether some of these software engineeringtechniques, and particularly the object-oriented paradigm and graphical modeling languagescan be used to simplify the development of Stochastic Optimization Models.

In this research, we explore how Object-oriented (OO) methodology can be brought intothe OR-specific context, with stochastic programming as an example. Our motivation to do

1

2 GRAPHICAL MODELING AND COMMUNICATION ISSUES IN OPTIMIZATION 2

so comes from two perspectives: a theoretical one, and a pragmatic one. From a theoreticalperspective, we observe that the OO methodology has had great success in tackling verydifficult but well structured problems similar in some ways to OR-problems. Thus we askourselves whether the methodology can be successfully applied to our own field. From apragmatic perspective, we observe that the OO methodology is pervasive and still expandingin reach and penetration. Thus we inquire whether an OO modeling language can be used tocommunicate with business and IT professionals and maintain them involved in OR-centricprojects.

The remainder of this paper proceeds as follows: In section 2 we examine previous effortsin the OR community to deal with the issues examined by this research, as well as initiativessimilar to ours in other fields. In sections 3 and 4 we offer brief descriptions of object-orientedsoftware engineering methods, and Multistage Stochastic Programming (MSP) respectively.In section 5, we introduce the major aspects of our language with the aid of illustrativeexamples. In section 6 we discuss a few examples of Stochastic Programming problems fromthe literature, and illustrate how the object-oriented paradigm might be applied to them.Finally, section 7 discusses some conclusions and possible extensions to other types of ORproblems.

2 Graphical Modeling and Communication Issues

in Optimization

Many researchers have, for a long time, raised the issue of formal treatment of modeling inOR. Previous research can, without very great injustice, be grouped into two approaches: amore formal approach, whose goal is to produce more natural formulation environments forproblems that are relatively precise; and a less formal approach, whose goal is to produceanalysis techniques suitable for problems which are by nature very “messy”, where formalitymay not be possible or productive.

Geoffrion’s Structured Modeling[Geoffrion(1987)], Greenberg’s Intelligent MathematicalProgramming System[Greenberg(1996)], and Jones’ work on graph-based Modeling Systems[Jones(1990), Jones(1991)], are representatives of the more formal approach. Some of theideas brought about by those contributions have found their way into implementations likeMODLER and ANALYZE[Greenberg(1993)], and also into graphical systems like MIMI/G[Jones(1996a)], LPForm [Ma et al.(1996)], gLPS [Collaud and Pasquier-Boltuck(1994)], andothers. A fairly new commercial modeling system which takes advantages of many of theideas developed in the research above is the Enterprise Optimizer by River Logic http:

//www.riverlogic.com. An excellent reference collecting much of the work done in this area

2 GRAPHICAL MODELING AND COMMUNICATION ISSUES IN OPTIMIZATION 3

can be found in [Jones(1996b)].The less formal approaches to modeling include techniques commonly referred to as Prob-

lem Structuring Methods (PSM) [Rosenhead(1996)] and Soft Systems Methodology (SSM)[Checkland(2000)]. These approaches take into account issues like conflicting objectives bydifferent actors, group dynamics, incomplete information, ill-defined measures, and other is-sues that can arise in developing complex models in business environments.

Our research is much closer to the first group than to the second, although it containscharacteristics of both. It is closer to the first group because it is fundamentally designed tosupport a formal, well structured OR technique: Stochastic Optimization. The componentsof the second group contained in this research are a result of the fact that we expect theresults to be applied to the early or intermediate stages of the modeling process, at whichtime some of the characteristics mentioned above that are well addressed by PSM and relatedmethodologies may still be present and must be dealt with. In particular, this researchaddresses the need to maintain a Problem Owner, who may not be an OR specialist, involvedas an active modeler[Powell(1997)], and to communicate with other people involved in theOR project, such as Information Technology (IT) professionals.

In this research, we examine the degree to which it is possible to extend and adapt theUnified Modeling Language (UML), a graphical modeling language for OO systems, for usewith OR-centric systems. We produce a meta-model specific to stochastic optimization.

The UML has recently been used as-is or extended to cover modeling in a wide variety offields, including design [Felfernig et al.(2002)], data warehousing [Lujan-Mora et al.(2002)],groupware [Rubart and Dawabi(2002)], hypermedia systems[Hennicker and Koch(2000)], andsecure systems[Jurjens(2002)]. To the best of our knowledge, a recent study of the applica-bility of OO techniques to OR-centric systems is not available, although a study of EntityRelationship Diagrams applied to optimization can be found in [Choobineh(1991)].

Many important details of stochastic optimization problems are not explicit in the dia-grams developed in this research. This characteristic of the diagrams is intentional. Elision,or modeling an element with certain characteristics hidden in a specific view, is a powerfulabstraction mechanism used extensively in the UML as well as in other modeling methodolo-gies. The primary intent of the graphical notation is to provide a mechanism for describingproblems at a very high level of abstraction, such as the level that would be appropriate inconversing with an executive, or the level appropriate between analysts at early stages ofthe modeling process, or the level appropriate for the diagrams to serve as complementarydocumentation to an already developed precise mathematical model. We consider customarymathematical notation adequate to express the relationships at more detailed levels.

A design focused on promoting elision is preferable to one focusing on precise algebraicequivalence because people in charge of studying optimization models in detail are typically

3 GRAPHICAL MODELING AND SOFTWARE ENGINEERING 4

engineers, mathematicians, statisticians, computer scientists, or other professionals with ex-tensive technical background. They are trained to use algebraic notation, and are comfortablemanipulating it. In addition, algebraic notation is far more concise than any graphical nota-tion can ever be in representing the same objects and the same relationships. The algebraicnotation in use today has been relatively stable for roughly 170 years [Cajori(1993)]. Leibnizused the

∫symbol for summation of integers as well as integration. The use of

∑to indicate

summation was introduced by Euler in 1755. Variations in the uses of∑

can be found inthe work of Lagrange, Cauchy, Fourier, and Jacobi up to the 1820s. Since then, except forspecialized uses, the use of

∑has remained stable.

Nonetheless, it is reasonable to speculate that mathematical notation might have evolveddifferently if computers, projectors, multimedia, the Internet, contemporary views on intel-lectual property, and other modern implements existed during Euler or Lagrange’s lifetime.Like any other language, mathematical notation continues to evolve and is likely to be in-fluenced by these developments. With additional assumptions, in specific application areas,it is certainly possible to devise graphical notations that capture all the detail necessary tobuild precise models in a practical way. For example, the Enterprise Optimizer by River Logichttp://www.riverlogic.com is capable of representing a wide variety of (deterministic) lin-ear programs using icons for resources and arcs for resource flows. Thus, we have built enoughexpressiveness an detail into our design so that it is possible to represent any linear expressionusing element diagrams.

There is no unique level of detail adequate for all situations. The level of detail dependsfundamentally on the background and interest of the people involved with each aspect of themodeling process, but also on other aspects, including: company, department, or industryculture; software support availability; and problem-specific considerations. Thus, a quite sig-nificant level of detail can be achieved in element diagrams by using adornments. Adornmentsare optional graphical markers added to an element that add semantic value to its representa-tion. With the aid of adornments, a significant proper subset of algebraic expressions can berendered in a simple way using element diagrams. An additional function of the adornmentsis to provide a convenient and intuitive link to access more sophisticated (usually algebraic)expressions within the context of a software system.

3 Graphical Modeling and Software Engineering

Since the beginning of the computer age, engineers have had a strong incentive to use graphicalmeans of representation to aid the software development process. Graphical modeling isuseful in the context of software development, because software development is inherently

3 GRAPHICAL MODELING AND SOFTWARE ENGINEERING 5

dynamic, multidisciplinary, and involves multiple interested parties with varied backgroundsand motivations.

As systems became more complex, new methodologies for software engineering evolved. Tosupport each of these methodologies, one or more set of graphical notations were developed.Diagrams have been developed to cover two main aspects of systems: structural; and dynamic.The structural aspect describes how parts of the system relate to each other. The dynamicaspect describes the operation of the system step by step.

The first widespread diagram was the fluxogram. Fluxograms defined a type of statemachine, and documented characteristics of each state using special icons for printing, diskstorage, tests, etc... Fluxograms provided the basic concepts that would be reused by all theother modeling diagrams that were concerned with the dynamic aspect of systems.

As systems became more complex, the structured paradigm became more and more pop-ular in software engineering. The main characteristic of this paradigm was the idea of acontinuous flow of control. Small structures were used for each iterative process, and withineach iteration, the system could again be described by a continuous flow of control. Fluxo-grams, which are based strongly on redirection constructs (such as goto statements), did notencourage structured thinking, and thus became less and less popular.

Multiple graphical modeling systems were created to support structured software engi-neering. Michael Jackson diagrams, entity-relationship diagrams and data flux diagrams areamong the most well known. However, numerous other diagramming techniques were devel-oped and adopted widely. As a result, people who were trained to use one set of diagrammingtechniques were not always comfortable using another set, even when both sets were used infundamentally similar way.

As software systems continued to become more complex, the structured paradigm wasrapidly reaching its limits, and the object-oriented paradigm was becoming more and morepopular. This paradigm brought to the forefront of the modeling process many concepts whichwere previously dealt with in a far less formal way. Some examples include: encapsulation,the notion that an object has a clear interface, but its implementation is hidden from view;specialization, the concept of having a general class in charge of common functionality, andspecialized subclasses for specific behavior; visibility, the notion that the definition of a classshould clearly specify the access privileges other components of a system have to each of itsown components; and polymorphism, the notion that an interface may operate differently ondifferent objects.

None of the above concepts were necessarily new. However, in the object-oriented frame-work, they were being handled explicitly at the modeling level, and enforced by the develop-ment systems. As a result, practitioners were forced to understand them and employ them intheir daily work.

4 MULTISTAGE STOCHASTIC PROGRAMMING 6

As with the structured paradigm, many modeling methodologies were proposed for theobject-oriented context, and new ones continue to be proposed. Accompanying these method-ologies, multiple graphical notations were also proposed. Three became particularly popular:the Booch method, by Grady Booch; OMT, by James Rumbaugh and associates; and OOSEby Ivar Jacobson. The three authors are commonly known in the software engineering com-munity as the “Three Amigos”.

In the early nineties, the Three Amigos got together at Rational Software Corporation,now part of IBM, and unified their three methods, taking the strongest parts of each andreconciling any inconsistencies between them. The result was the Unified Modeling Language(UML). Subsequently, the language went through a standardization process, and is now anObject Management Group (OMG) standard. The standard is currently on version 1.5, withwork on revision 2.0 in progress.

Forward engineering and reverse engineering can both benefit from the use of graphicalmodeling notations. In forward engineering, the modeling process begins with an abstractrepresentation. This representation is then successively refined, until an operational modelis available. In reverse engineering, a detailed, preexisting model is analyzed. The result ofthis analysis is a more abstract representation of the same model. This representation canthen be used to support future changes to the model, interactions between different expertsin charge of the models, and communication with a problem owner. We expect the languagedefined by this research to be used to support both of these processes.

4 Multistage Stochastic Programming

In this paper, we will focus on the connection between stochastic programming and graphicalmodeling, using the UML as a framework. For a good introduction to stochastic programming,see [Birge and Louveaux(1997), Chapter 1].

The specific class of stochastic programming models we are interested in are MultistageStochastic Programs with Recourse (MSPR). In these models, we do not know all the datafor the problem with certainty when the decision is taken. However, we know that at certain(known) points in the future, the data we are modeling as uncertain will be observed. Unfor-tunately, our decision needs to be taken before the uncertainty is resolved. Our objective is tomake a decision now which minimizes its current (known) cost plus its expected future cost.The future cost is impacted by recourse decisions available after the uncertainty has beenobserved. Those decisions, in turn, may also have to be taken under uncertainty. Thus, thedecision process may repeat itself a finite number of times, in recursive fashion, as illustratedby figure 4.1.

4 MULTISTAGE STOCHASTIC PROGRAMMING 7

MakeAdjustment

ObserveUncertainty

MakeDecision

MakeAdjustment

ObserveUncertainty

MakeAdjustment

ObserveUncertainty

...

Figure 4.1: A stochastic programming model.

Figure 4.2: A simple class.

The space in time between points where some of the uncertain data are observed is referredto as a stage. Depending on the outcome of the uncertain events of interest, different decisionsmay be available after observing the uncertainty. This dynamic component of stochasticoptimization is one of the characteristics that makes a graphical representation such as thosebased on the UML valuable. We have developed stochasticity diagrams (section 5.2) to specifythe time-related aspects of the relationships between the uncertainty and the sets of decisionsbeing made.

Within any given stage, the objective is to optimize the decisions available at that timeperiod. Those decisions, however, are typically dependant on decisions taken earlier. There areconstraints that describe what types of decisions are available at each stage, and constraintsthat describe how decisions taken earlier affect the decisions available at each stage. Some ofthe costs associated with the decisions, the effects of previous decisions, and the limits on theavailable resources may be uncertain. Element diagrams (section 5.3) are designed to aid inmodeling these static aspects of the decision process. Element diagrams are also designed toexpress what parameters should be treated as uncertain at any point in time.

Decisions often need to be made over sets of objects of the same kind. For example, afacility location model may be used to decide which warehouses to open. Each warehousehas a number of characteristics like fixed cost or maintenance cost. Each warehouse may beconsidered to be an instance of a Warehouse class. A class is represented in UML by a boxwith compartments for different types of elements, as in figure 4.2. We will show that UMLclass diagrams (section 5.1) can be very useful abstraction tools in developing and explaining

5 A META-MODEL FOR MULTISTAGE STOCHASTIC PROGRAMMING 8

optimization models.

5 A Meta-model for Multistage Stochastic Programming

The collection of definitions which include Objective, Constraint, Random Variable, etc... ispart of the Meta-model for stochastic programming. Every problem is an instance of the classdefined by these definitions, in the same sense that the traveling salesperson problem is aninstance of a combinatorial optimization problem. The concept of Meta-model is similar tothe concept of a Graph Schema in [Jones(1990), Jones(1991)].

There are three main types of diagrams in our meta-model: Class Diagrams, special-ized from UML Class Diagrams; Stochasticity diagrams, specialized from UML StatechartDiagrams; and Relationship Diagrams, also specialized from UML Class Diagrams. In thissection, we will explain and illustrate each type.

At several points in the exposition, we will use as an illustration a stochastic location-routing problem (SLRP) with the following characteristics:

• The objective is to locate a number of facilities in order to maximize expected profitover a finite horizon.

• Facilities must be opened at one or more of several candidate locations before the demandis observed.

• At the start of each planning period, all orders to be served during that period are known.Orders are shipped in less-then-truckload quantities by a fixed number of trucks, eachof which has limited capacity.

• Each truck services a number of areas, each of which has some demand associated withit. There is a limit to the time spent on each route, which includes travel time as wellas service time.

• New routes can be devised at the beginning of each planning period, but a penalty isincurred for changing routes. A penalty is also incurred when a region that was served inthe previous planning period is dropped, if that region’s demand in the current planningperiod is greater than zero.

• Demand not served may be lost to a competitor.

Clearly this problem has many nuances, and many formulations and solution approaches areplausible. However, for the purposes of this research, we will focus on devising a mechanismto communicate the essential information above to a decision maker, or quickly capture thatinformation from a description given by a decision maker.


Figure 5.1: A class diagram.

5.1 Class Diagrams

Class diagrams are the most widely used type of UML diagram. Their basic function is torepresent all the classes that are part of a system, and the relationships between them. InUML, classes are represented by a box with compartments. The first 3 compartments areused for the class name, attributes, and operations. Other compartments may be used inspecific applications for other characteristics.

Relationships between classes are also displayed using class diagrams. In figure 5.1, we cansee a specialization relationship between Warehouse and Facility. A specialization indicatesan is-a type of relationship. In this case, a Warehouse is-a Facility, so that it incorporates allthe properties of facilities. We can also see an association relationship between two Facilities,called distance. The two are differentiated graphically by the type of arrow. The specializationhas an open triangle, while an association has a stick arrow.

There is also an association between Warehouse and Retailer, called shippingCost. No-tice that this association does not have an arrow associated with it, but is still valid. In thecase of an association, the arrow is optional.

Within the framework defined by this research, the class diagram summarizes all the dataused in the optimization problem, and all the information coming out of the optimizationprocess. For this reason, it is likely to be the most important diagram for communicatingbetween OR experts and those responsible for the IT infrastructure. Therefore, we havemade an effort to reuse as much functionality from the class diagram as possible. However,elements of a class in the context of an optimization problem have important properties


that distinguish them from their software engineering counterparts. Here we discuss theappropriate mechanisms for describing them using the UML.

There are two major types of characteristics which define the state of an object in thecontext of mathematical programming: variables (decisions); and parameters. In the contextof stochastic programming, parameters may be thought of as having two categories: deter-ministic; and stochastic. There are several alternative ways to reconcile this framework withthe constructs available through the UML.

Both decisions and parameters can be modeled as attributes of a class. We will examineparameters first. Parameters that are not stochastic are only initialized once, when the classinstance is created. The UML contains a provision for describing this situation. Adding theproperty {frozen} (in the UML, properties are expressed by their label in curly brackets)to an attribute specifies the behavior we desire. In the UML, unless specified otherwise, allattributes have the {changeable} property. This makes sense in general software engineering,but is undesirable in our case, since typically in stochastic programming only a few parametersare modeled as stochastic. One way to resolve these issues is to add a note indicating thatall attributes are {frozen} unless otherwise noted.

Stochastic parameters do not perfectly fit into any concept currently in the UML. Theycertainly satisfy the {changeable} property, but they are changeable in a very specific way.One alternative here is to add the property {stochastic}, to be used in this situation.

Decisions are arguably the most fundamental component of an optimization model. Inthe UML, there are several mechanisms that can be used to represent decisions associatedwith classes. Depending on the background of the reader, one or another may seem morenatural. This presents a design problem. We will analyze the alternatives here, and justifyour recommendation.

Decision variables are also {changeable} attributes of a class. But again, this is notsufficient. Decisions have a domain, an essential part of the description of an optimizationproblem.

It might initially seem reasonable to think of decisions as operations on a class. Bothusually given action verbs as names; and both often affect other characteristics of the class.In this view, opening or closing a facility is in fact an action taken on a facility. Unfortunatelythis view has difficulties. Unlike operations, decision variables are not, in the stochasticprogramming with recourse framework, allowed to affect parameters of a class. They may,however, affect other decisions. In the object-oriented framework, operations cannot changeother operations. Thus, while operations and decisions share some characteristics, one cannot be considered a subclass of the other.

Decision variables, therefore, do not neatly fit into any standard category in the UML.However, they are subclasses of attributes. Within the modeling framework defined in this


Figure 5.2: Classes in the SLRP.

research, we suggest defining a stereotype for handling decisions. Stereotyping is one ofthe extension mechanisms in the UML. The mechanism is used to create meta-classes withspecific characteristics. This works very well for decision variables. In particular, the taggedvalues upperBound and lowerBound can be associated with the «decision» (in the UML,stereotypes are expressed by their label between guillemots) stereotype. The stereotype isused to define decision variables as special types of attributes.

In figure 5.2, we can see all the classes needed to define the stochastic location-routingproblem (SLRP) defined earlier. Notice that there is an addition to the syntax discussedearlier. A role has been added to the association between some of the classes, indicated by averb followed by a triangle I or J pointing from the subject to the object of the role. The rolehas no direct translation to the stochastic programming framework. In particular, it is notholding the place of a decision variable. Diagram 5.2 implies that we are not concerned withwhich truck gets assigned to each route (perhaps they all have the same MaximumLoad).If that decision were part of the model, an association class would need to be created andattached to the association between Truck and Route.

The maximum cardinality of all the components of the model are unambiguous in the classdiagram. For example, given M1 Warehouses and M2 Retailers, an automatic tool can easilydeduce that there are M1 × M2 ShippingCosts. Such a tool can also automate parts of thedata acquisition routines, as well as perform integrity checks. It is legal for a tool to allowcertain additions to the syntax. With these additions, it is possible to generate equationsautomatically, as we will show.

Decisions of arity > 1 present no difficulty. Decisions can be associated with arrays or


dictionaries when appropriate. In particular, some types of 1-to-many associations are oftenwritten as attributes with arrays when convenient. Associations of arity > 2 are also easilyhandled within the UML (association classes are an example). All that is needed is to drawthe lines between classes in a manner that shows unambiguously that the associations involvetuples of classes as opposed to a set of classes taken two at a time. This framework requiresno implied normalization. The associations in the examples in this paper are all of arity 2only for simplicity of exposition.

More important than generating equations automatically is having a graphical languagethat improves communication between different analysts. A professional with an IT back-ground, who is likely to know where some of the desired information can be found, willappreciate having a description of the data in a familiar language.

People interacting with the model solely at a decision maker level will also appreciate theinformation about the model contained in the diagram. For example, from the model in figure5.2 it is clear that direct shipments between the warehouse and individual Client Clusters arenot available as a recourse action, without the need for any mathematical notation or textualdescription. Another example is the relationship between Truck and Route. If the trucks allhave the same maximumLoad, then the association isAssignedTo is probably not goingto have a decision associated with it. However, if maximumLoad is different for each truck,and the smallest load is close to the typical demand for a cluster, then the isAssignedTo

association will become a class containing a decision.

5.2 Stochasticity Diagrams

In this section, we are particularly concerned with how information becomes available overtime, and how it affects our ability to make decisions. The stochasticity diagram is designedto address these questions. The stochasticity diagram is a UML statechart, with each staterepresenting a decision process and each event representing the observation of some set ofrandom variables.

We use stochasticity diagrams to describe the dynamics of the information acquisitionand randomness in the system. In particular, we wish to describe two aspects of the system:at which point in time each piece of information becomes available with certainty; and theconsequences of observing the information for the decision process.

There exists a mathematical construct useful in describing the first aspect above. It iscalled a (discrete time) filtration process. Filtration processes are stochastic processes thatdescribe what information becomes available at each point in time. The random variablesin the model are then conditioned on the information available. The detailed notation andmathematical definition of filtration processes are not necessary for this discussion, except to


Figure 5.3: A simple state machine for a location-routing problem with 5 stages.

note that modeling systems focusing on the dynamic aspect of stochastic programs can bereferred to as filtration-oriented. For a more detailed exposition on filtration processes, see[Neftci(2000)]. We use state machines to describe the filtration process. Figure 5.3 representsthe filtration process for the SLRP.

In this methodology, every diagram has an initial state (the solid circle) and a final state(the other circle). In between, there are a number of other states (the round-edged boxes),each representing a set of decisions taken based on the same information. Each state has aname.

In between each pair of states there is an event (represented by an arc) that describeswhat new information becomes available causing the state transition. Each event may havea name and may take parameters. If this is the case, the parameters should be the randomvariables being observed. An event may also have a guard condition (represented in betweensquare brackets). When an event occurs, the transition only takes place if the guard conditionis satisfied. A signal may also be sent when an event occurs, represented in the diagram bythe send keyword followed by the name of the signal. The signal is used to represent thedecisions taken at some period t that must be taken into account at period t + 1.

Stochasticity diagrams represent a very abstract view of the decision process. The actualmathematical expressions that define the conditional probabilities, as well as the algebraicrelationships between problems defined at different stages are not shown directly on the dia-gram. Their definition should take place inside elements associated with each event or state.

The system being depicted by the Stochasticity diagram is the decision process. We wantto express which decisions we are in the process of making, and then what decisions we willbe in the process of making once certain events happen. In our case, the relevant events arethe observation of new information.

One of the assumptions underlying this modeling methodology for modeling stochasticprogramming is that the observation of uncertainty is the fundamental aspect that defines


stochastic programming models. The decisions available in the model depend on what isuncertain, when the uncertainty can be observed, and how it influences the data. This viewof the role of the uncertainty in stochastic programming can be contrasted with the view thata stochastic program is a multistage mathematical program with uncertain parameters. Thedistinction is subtle, and more relevant from a modeling perspective than from a solutionperspective, since both views should produce the same instances: in the former, time assumesa central role; in the latter, time is simply another index.

5.3 Element Diagrams

Element diagrams are used to represent the relationships between elements in the model. Thealgebraic structure in the model should be a refinement of the relationships described in theelement diagram.

Element diagrams, unlike activity graphs [Schrage(2002)], the diagrams in LPFORM[Ma et al.(1996)], or gLPS [Collaud and Pasquier-Boltuck(1994)], do not necessarily trans-late directly into algebraic expressions. The idea in element diagrams is to specify first whatelements are related, rather than specifically how they are related to each other. There aretwo justifications for this design: the refinement level in which element diagrams are designedto operate; and the adequacy of the current notation.

The primary reason for not tying element diagrams directly to algebraic expressions is thatelement diagrams are designed to be used at several stages of refinement. In some of thesestages, the specific expressions that determine how elements are related may not be especiallyrelevant. Element diagrams are designed to be useful as tools for communication betweenoptimization experts and problem owners. In the context of this communication, the problemowner may be unaware of, uncomfortable with, or unconcerned with the specific dynamics ofthe relationships between elements. However, he or she is likely to be interested in knowingthat the relationship is part of the model.

In order to introduce some basic ideas of element diagrams, we will consider initially asimple problem without stochasticity. In figure 5.4, we have an unadorned element diagramof the traveling salesperson problem (TSP). While not particularly useful for computation,figure 5.4 contains a correct and complete representation of the major components of themodel. There is an objective (represented by the triangle), to minimize (thus the trianglepoints down) the total distance; a decision to be made (represented by the diamond), theroute to choose; and a constraint (represented by the box), to visit all nodes. There are alsoassociations between the different elements in the diagram, represented by the lines connectingthem.

If adornments are used, the element diagram has sufficient expressive capability to repre-


Figure 5.4: An unadorned representation of the TSP.

sent any linear program. In fact, when the element diagram is examined one set of constraintsat a time, or one objective at a time, such as it would be in the algebraic description, it pro-duces an expression tree equivalent to one used by a modeling language to generate instances.

Figure 5.4 can be contrasted with figure 5.5. In figure 5.5, an adorned element diagramof the same problem is used to represent the following classical Dantzig-Fulkerson-JohnsonTSP formulation in detail: We use Given a graph (V,E) with n nodes, use δ(U), U ⊂ V torepresent the cut of the node set U . Define a binary variable xe, and a cost parameter ce

associated with each edge e ∈ E:

min∑e∈E

cexe∑e∈δ({v})

xe = 2 ∀v ∈ V∑{e∈δ(U)}

xe ≥ 2 ∀U ⊂ V, 2 ≤ |U | ≤ n− 1

The class diagram accompanying figure 5.5 can be found in figure 5.6.Each constraint in figure 5.5 has an equality symbol in its body, identifying it as an

equality constraint. Each constraint also includes an Object Constraint Language (OCL)expression in curly brackets. OCL is not to be confused with the concept of constraint in anoptimization problem. OCL is a formal modeling language defined as a subset of the UML toaid in clarification of the semantics of models. In the context of constraints, OCL expressionsare used to specify multiplicity.


Figure 5.5: An adorned representation of a typical formulation of the TSP

Figure 5.6: The Arc and Node classes used in the TSP Element Diagram in figure 5.5.


The enforcement of the OCL expressions is left to the implementation[UML(2003)]. Acomputer implementation is free to replace the OCL with any other language, formal, ornot. In particular, an implementation is free to replace these OCL expressions with validexpressions in a modeling language.

An association is used to capture the relationship between different instances of a class[Booch et al.(1999)]. Thus, each association has a cardinality associated with it. The cardi-nality may, of course, be elided, as in figure 5.4. In most cases, when the cardinality is not1, the association corresponds to a summation or product. In the linear programming case,an OCL expression can be added to the association to specify which instances of constraintand variable classes are related, as in figure 5.5. An implementation may choose to use theseexpressions to generate algebraic modeling language code.

Each association in figure 5.5 has a double arrow (it is important to use the double arrowto avoid confusion with other concepts already defined in the UML) at one of its ends. Thearrow indicates flow balance regarding the constraint. An alternative way to think of thedirection of the arrow is in terms of credits and debits. In this view, the constraint is abalance. An arrow pointing toward the constraint is a credit, and an arrow pointing awayfrom the constraint is a debit.

Each association may also have a name. If so, then this name should be a parameter relatedwith each instance of the association. Notice that it is not the instance of the parameter thatis used for the name, but the class. For example, in the TSP diagram above, notice that c isthe name of the association between the decision and the objective, and not ce.

In general, it is not necessary to specify all the multiplicities of the associations. Eachimplementation may choose to interpret the association as it wishes. For example, in LINGO[Schrage(2002)], in cases like the one in figure 5.5, it is not necessary to index each variableor parameter in an expression. The parser infers the multiplicity according to a well-definedsyntax. In AMPL[Fourer et al.(1993)], however, every variable must be specified with itscomplete unambiguous indexing. Both approaches can be supported by this design.

Consider the (SLRP). Figure 5.7 represents the lower-right state (Determine Routes) infigure 5.3.

Unlike in the TSP above, in this diagram some elements have double lines associated withthem. The double lines indicate some element of stochasticity or externality. For example,the facility.open decision was made before entering this state. Even though it is representedas a decision (and indeed it is), it is not mutable at this stage. The facility.open parameterwas received in this state as a signal sent by another state, as indicated in the stochasticitydiagram 5.3 by the send openedFacilities notation associated with the two states involved.The routes decision has a special marker on it, to indicate that this is a decision that mightinfluence decisions made in future stages.

6 ILLUSTRATIONS FROM THE LITERATURE 18

Figure 5.7: The determine route state in the SLRP.

The demand parameter also has double lines. This indicates that it is a random variable.Similarly to the adornments discussed in the context of the TSP, none of the adornments

displayed in this example are necessary for the model to be syntactically correct. Whentaking notes, they are very useful in capturing essential aspects of the problem. However,when presenting a model, especially to a non-specialized decision maker, the analyst shoulduse careful judgment and avoid overwhelming the audience with notation.

6 Illustrations from the literature

In this section, we will present a few classical examples taken from [Ariyawansa and Felt(2001)].For each example, we will provide an abstract textual description (an edited version of thedescription in [Ariyawansa and Felt(2001)]), elided class, stochasticity and element diagrams.

6.1 Airlift Operations Schedule

This model comes from [Midler and Wollmer(1969)]. Its goal is to minimize the expected costof airlift operations. Aircraft resources are allocated based on a forecast of the demands forspecific routes. However, the actual demand is unknown. The recourse actions available are:allowing allocated flight time to go unused; switching aircraft from one route to another; andpurchasing commercial flights.


Figure 6.1: Airlift operations class diagram

6.1.1 The Class Diagram

The class diagram 6.1 illustrates the important components of the model and their relation-ships. The main classes are Flight and Plane. Each plane has a certain number of availablehours. Each route has several parameters associated with it. The most important are: origin

and destination; demand, in units, which is stochastic; spot market cost, which is theunit cost of purchasing commercial flights on that route; and unused capacity cost, theunit penalty for reserving Plane capacity and then leaving it unused. Each Route also hastwo decisions associated with it: spot purchase, the amount of demand that will be coveredby commercial flights; and unused, the amount of capacity reserved but left unused for thisroute.

The other classes are association classes. Association classes are appropriate when theassociations between different classes have parameters of their own. The Assignment andReassignment classes are very similar. They both have the following parameters: hours,the time it takes for a given plane to fly a given route; cost, the unit cost of flying a givenroute with a given plane; and capacity, the number of units a given plane can carry whenflying a given route. Because these parameters appear as members of Assignment instead ofPlane, it is clear that in this model they depend on the specific combination of Plane andRoute, as opposed to other plausible situations, where some parameters may depend only onPlane. An analogous situation is seen with Reassignment.


AssignPlanes

RessignPlanes

demand/send reservedFlights

Figure 6.2: Airlift operations stochasticity diagram

6.1.2 The Stochasticity Diagram

The stochasticity diagram 6.2 is quite simple. There is the first stage decision, to assign planesto routes; then the second stage decision, to do any reassignments necessary.

6.1.3 The Element Diagrams

The first stage element diagram 6.3 is simple. It prescribes that in this stage, we are to deviseassignments of minimum cost respecting the number of hours available for each flight.

The second stage element diagram 6.4 is more sophisticated. For example, there aretwo arrows connecting the reassignment decision to the Satisfy demand constraint. Thisindicates that by reassigning flights to routes, we may both increase and decrease the demandsatisfied. In particular, as expected, the diagram indicates, by using a constraint togetherwith each arc, which of the reassignment decisions result in increases or decreases of satisfieddemand. The actual expressions in the original paper involve each plane’s carrying capacity,and ratios between flight-hours in different routes for each plane, but they are elided here.

6.2 Forest Planning

This model comes from [Gassmann(1989)]. The goal of this model is to maximize the revenueobtained from a forest area, by deciding which parts of the forest should be harvested at eachpoint in time. The forest is segmented by the age of trees in a region, and each segment maybe worth a different amount per unit area. Due to fire, disease, or other casualties, part ofthe trees that are not cut may be lost before it moves into the next age group.


The class diagram 6.5 is very simple. There is only one class and no associations. Even thoughan age method is present, it has no semantic meaning within the context of optimization.


Cost

Assignment

AvailableHours Flight Hours

<=

Assignment.hours

Figure 6.3: Airlift first stage element diagram


Figure 6.4: Airlift second stage element diagram

Figure 6.5: Forest planning class diagram.


Cut [stage=stages]

casualties[stage<stages]

Figure 6.6: Forest planning stochasticity diagram

It is present to illustrate that objects used within this framework can be shared with otherparties who may have different uses for them.


The stochasticity diagram 6.6 has a self-transition, which takes place every period. It istriggered by the random vector casualties and is processed so long as the stage is less thanthe total number of stages. Otherwise, the planning horizon ends.

6.2.3 The Element Diagram

The element diagram 6.7 is associated with the cut state in figure 6.6. Both cut and uncutforest have value. The amount of forest available in each category is determined by a balance

constraint, that takes into account the amount available in in the previous period, the amountcut in the previous period, and any casualties that may have occurred. Notice that the doublearrow linking the available variable from the previous period to the balance constraint ishollow, in contrast to all the others. This is a visual cue to indicate that this parameter isstochastic.

The amount of forest that can be cut now is limited by the available variable, as indicatedby the Availability constraint. Lastly, the amount of timber the market is ready to acceptis bounded above and below by the amount that was cut in the previous period. Thus, theIndustry capacity constraint has arrows coming both in and out of both the current stageand previous stage cut variables. The Industry capacity constraint could be separated into alower industry bound and an upper industry bound if desired.


Value

Available Cut

Availability

AvailableAvailable

CutCut

IndustryCapacity

Balance

<=

casualty

Figure 6.7: Forest planning element diagram


Figure 6.8: Electricity investment class diagram.

6.3 Electrical Investment Planning

This model comes from [Louveaux and Smeers(1998)]. The objective is to minimize totalinvestment and maintenance costs for electricity generation. Several technologies are available,with different capacities, costs, availabilities, and lifetimes. Some of these characteristics arestochastic, and the goal is to balance all of them in determining an effective investment andoperational schedule.


The class diagram 6.8 displays the major components of the model. Demand for electricity canbe thought of as coming in different modes, which discretize the demand curve over a cycle.For a certain amount of time during a cycle (duration in the class diagram), an amount ofpower exceeding the previous mode (power in the class diagram) will be needed.

The total demand (demand in the class diagram) for each Demand Mode can beproduced by using several Technologies, each of which has: an availability, the proportionof time a plant using the production technology can be operated in a period; an operating

cost, which is stochastic (it may depend, for example, on fuel costs); and a planned capacity


Figure 6.9: Electricity investment stochasticity diagram

already contracted for.In addition, it is possible to invest in certain technologies. In this case, one must take

into account and investment cost, which is stochastic (it may depend, for example, ontechnological achievements), a leadtime, the delay between when the contract is signed andwhen the facility becomes operational; and also a lifetime, describing for how many periodsthe technology will be usable.

The decision maker may increase the available capacity of an Investible Technology

(which is a subclass of technology), which determines, when combined with the already con-tracted capacity, leadtime, and lifetime considerations, the actual available capacity at anypoint in time.

There is also a special type of Investible Technology called the Spot Market, in whichtypically the operating costs are very high. Spot Market purchases require no investment,have no leadtime, and only last for the current period.


The stochasticity diagram 6.9 illustrates that the relevant random variables to be observedare the demand and costs (both operating and investment). There is only one set of decisions,defined by the Invest state. The information exchanged between stages is the portfolio ofcurrent investments.

7 CONCLUSIONS AND FURTHER WORK 27

Figure 6.10: Electricity investment element diagram.

6.3.3 The Element Diagram

The element diagram 6.10 shows that there are two constraints to be considered. Satisfy

demand ensures that the amount produced or purchased in the spot market is sufficientto satisfy all of the demand for all modes. The Capacity constraint relates how capacityadded in previous planning periods and capacity originally contracted affects the productioncapability at this stage.

The added capacity decision has a special marker to indicate that it will influence futuredecisions. Demand, operating cost and investment cost are marked as stochastic, thefirst because of the ellipse with double lines, and the others because of the hollow double-arrows.

In this section, we will provide a description of all the elements referred to in this paper.In section

7 Conclusions and further work

Many researchers and practitioners have expressed a concern with the increasing complexityof the models we study. This complexity, in tandem with the educational background of thepeople making decisions in the practice environment, hinders the ability of the OR professionalto convey the value added by OR. We recognize this disconnect between the OR professionaland the decision maker as a strategic problem facing our profession. This research is an effort

7 CONCLUSIONS AND FURTHER WORK 28

to address this problem within the specific context our our expertise.In this research, we developed a graphical modeling language based on UML designed for

facilitating communication of OR-models between OR-specialists and non-OR-specialists.The concept of elision is fundamental to this research. While this language can be used

to describe linear programs in their entirety, we do not expect it to be used that way. Doingso is essentially the equivalent of modeling algebraic expressions by drawing reverse polishnotation expression trees. In most cases, using regular algebraic modeling languages wouldbe more appropriate.

The situation in which this language is most effective is in communicating and docu-menting the general tradeoffs considered in a model, as well as the pieces of informationnecessary to adequately analyze the situation underlying the model. The process of produc-ing elided views of models from specific views of models, with the intent of reexamining basicassumptions, documenting, or transmitting a model to a different audience is referred to asreverse-engineering.

Another scenario where this language would be useful is in providing a framework for thedevelopment of models. In this case, the language would be used within a software systemcovering the entire lifetime of a model. The development of the model would start with thecreation of a set of diagrams, and those diagrams would be used to organize the expressionsin the model. This process is referred to as forward-engineering.

In this paper, we have shown how this language can be used for reverse-engineering. Toshow that it can also be used for forward engineering, we could implement a computer systemthat organized the development of a model in a way similar to what is prescribed above. Thisis a matter for future research.

Another aspect that might warrant further examination is whether using the UML asa base language is strictly necessary. We believe that the UML is sufficiently expressive,tractable, and extensible to be a good choice for this problem. The UML offers benefits(i.e. industry and software support, familiarity for technology professionals, standardization,etc...) that, in our opinion, compensate for the occasional compromises on expressivenessor simplicity we have had to make at different stages of the design process. However, otherresearchers may disagree, and attempt to produce other graphical languages which are perhapsmore clear or more expressive by dropping the UML assumption. Even within the UML,there are different ways of organizing the objects that make a stochastic optimization models.Perhaps a more elegant set of classes can be devised to address the same problem.

Yet another possible direction for future research is to attempt to develop graphical lan-guages that express other types of OR problems. Certainly variables, parameters, uncertaintyand time are not concepts exclusive to stochastic optimization. Developing a language thatcould cover more classes of problems, or showing that this particular language can be gener-

REFERENCES 29

alized to cover other classes of problems well is an interesting consideration.Ultimately, as with any language, practice will dictate which diagrams becomes common.

We have certainly considered the constraints involving the mathematical objects, the compu-tational environment, and especially the people involved with the use of a language like thisone. However, there is no substitute for practical usage, and it is likely that variations on thediagrams would prove more appropriate under different environments. The set of objects anddiagrams proposed here, however, provide an excellent starting point.

References

[UML(2003)] (2003). OMG Unified Modeling Language Specification. Object ManagementGroup. Version 1.5.

[Ariyawansa and Felt(2001)] Ariyawansa, K. A. and Felt, A. J. (2001). On a new collec-tion of stochastic linear programming test problems. Technical Report 4, Department ofMathematics, Washington State University, Pullman, WA 99164.

[Birge and Louveaux(1997)] Birge, J. R. and Louveaux, F. (1997). Introduction to StochasticProgramming. Springer-Verlag.

[Booch et al.(1999)] Booch, G., Rumbaugh, J., and Jacobson, I. (1999). The Unified ModelingLanguage User Guide. ACM Press.

[Cajori(1993)] Cajori, F. (1993). History of Mathematical Notations. Dover Publications, Inc.

[Checkland(2000)] Checkland, P. (2000). Soft systems methodology: a thirty year retrospec-tive. Systems Research and Behavioral Science.

[Choobineh(1991)] Choobineh, J. (1991). A diagramming techniuqe for representation oflinear programming models. Omega.

[Collaud and Pasquier-Boltuck(1994)] Collaud, G. and Pasquier-Boltuck, J. (1994). glps: Agraphical tool for the definition and manipulation of linear problems. European Journal ofOperations Research.

[Felfernig et al.(2002)] Felfernig, A., Friedrich, G., Jannach, D., and Zanker, M. (2002). Con-figuration knowledge representation using uml/ocl. LNCS.

[Fourer et al.(1993)] Fourer, R., Gay, D. M., and Kernighan, B. W. (1993). AMPL A ModelingLanguage For Mathematical Programming. Boyd & Fraser.

[Gassmann(1989)] Gassmann, H. I. (1989). Optimzal harvest of a forest in the presence ofuncertainty. Canadian Journal of Forest Research, 19, 1267–1274.

[Geoffrion(1987)] Geoffrion, A. M. (1987). An introduction to structured modeling. Manage-ment Science.

REFERENCES 30

[Greenberg(1993)] Greenberg, H. (1993). A Computer-Assisted Analysis System for Math-ematical Programming Models and Solutions: A User’s Guide for ANALYZE. KluwerAcademic Publishers.

[Greenberg(1996)] Greenberg, H. J. (1996). A bibliography for the development of an intelli-gent mathematical programming system. ITORMS.

[Hennicker and Koch(2000)] Hennicker, R. and Koch, N. (2000). A uml-based methodologyfor hypermedia design. LNCS.

[Jones(1990)] Jones, C. V. (1990). An introduction to graph-based modeling systems, part i:Overview. ORSA Jorunal on Computing.

[Jones(1991)] Jones, C. V. (1991). An introduction to graph-based modeling systems, part ii:Graph-grammars and the implementation. ORSA Jorunal on Computing.

[Jones(1996a)] Jones, C. V. (1996a). Mimi/g: A graphical environment for mathematicalprogramming and modeling. Interfaces.

[Jones(1996b)] Jones, C. V. (1996b). Visualization and Optimization. Operations Research/-Computer Science Interface Series. Kluwer Academic Publishers.

[Jurjens(2002)] Jurjens, J. (2002). Umlsec: Extending uml for secure systems development.LNCS.

[Louveaux and Smeers(1998)] Louveaux, F. V. and Smeers, Y. (1998). Optimal investmentsfor electricity generation: A stochastic model and a test-problem. In Numerical Techniquesfor Stochastic Optimization, chapter 24, pages 445–453. SpringerVerlag.

[Lujan-Mora et al.(2002)] Lujan-Mora, S., Trujillo, J., and Song, I.-Y. (2002). Extending theuml for multidimensional modeling. LNCS.

[Ma et al.(1996)] Ma, P., F. H. Murphy, and E. A. Stohr (1996). An Implementation ofLPFORM. INFORMS Journal on Computing.

[Midler and Wollmer(1969)] Midler, J. L. and Wollmer, R. D. (1969). Stochastic program-ming models for scheduling airlift operations. Naval Research Logistics Quarterly, 16,315–330.

[Neftci(2000)] Neftci, S. N. (2000). An Introduction to the MAthematics of Financial Deriva-tives. Academic Press.

[Powell(1997)] Powell, S. G. (1997). The teachers’ forum: From intelligent consumer to activemodeler, two mba success stories. INTERFACES.

[Rosenhead(1996)] Rosenhead, J. (1996). What’s the problem? an introduction to problemstructuring methods. Interfaces.

[Rubart and Dawabi(2002)] Rubart, J. and Dawabi, P. (2002). Towards uml-g: A uml profilefor modeling groupware. LNCS.

[Schrage(2002)] Schrage, L. (2002). Optimization Modeling with Lingo. LINDO Systems Inc.,4th edition.

object oriented modeling and multistage stochastic programming€¦ · object oriented modeling and...

Documents