In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical and electrical changes may be made without departing from the scope of the present invention. It should also be understood that the exemplary methods illustrated may include additional or fewer steps or may be performed in the context of a larger processing scheme. Furthermore, the methods presented in the drawing figures or the specification are not to be construed as limiting the order in which the individual steps may be performed. The following detailed description is, therefore, not to be taken in a limiting sense.
Embodiments of the present invention provide a solution to the specification bottleneck in applying optimization problems to specific systems. This solution is provided by enabling domain experts to express optimization problems in terms understood by the domain expert. In particular, the optimization problem is expressed using graphical modeling notation familiar to the domain expert, such as Unified Modeling Language, Logic Data Structures, etc, and functional notation that references the elements of the modeling notation diagrams. Embodiments of the present invention map or convert the expression of the problem, as created by the domain expert, to algebraic form. In particular, embodiments of the present invention are adapted to enable expression and conversion of both linear programming (LP) and mixed integer-linear programming (MILP) optimization problems. The algebraic form call then be passed to commercially-available mathematical solver to solve the optimization problem. Hence, the specification bottleneck is avoided by eliminating the need for a domain expert to become an optimization expert.
As mentioned above, embodiments of the present invention are adapted to handle both LP and MILP optimization problems. A typical LP and MILP problem definition consists of index sets and variables, parameters, decision variables, constraints, and an objective. An index set is a finite mathematical set whose elements typically correspond to real-world objects. An index variable is a variable bound to an index set. For example, the following is a group of index variables and sets,
In the above group, Aircraft, Station, and Flight are all index variables tied to their respective index sets (i.e. {N291US, N296US, N299US}, {SFO, JFIK, BOS}, and {NW23, NW144, NW729}, respectively). A parameter is a quantity whose value is given as a part of the problem statement. Parameters are related to index variables and sets in that a parameter has zero or more index variables as subscripts. For example, departure Timef is a parameter representing the departure time of flight f. Therefore, in this example, the value of departureTimef will change according to the particular instance (or value) of index variable f. Additionally, explicit mathematical constants may be used wherever parameters are used.
A decision variable represents a quantity whose value is to be determined as part of the problem solution. A decision variable, like a parameter, has zero or more subscripts. For LP problems, all decision variables are real-valued. For MILP problems, a decision variable may be real-valued or integer-values. For example, in a common special case, a decision variable is binary-valued, i.e. restricted to values 0 and 1. A constraint is an equality or inequality among the problem's parameters and decision variables. For typical LP and MILP problems, constraints take the form of:
where I is a set of zero or more index variables over which the constraint is universally quantified, J is a set of zero or more index variables over which the summation is performed (If J is empty, there is no stuimnation), pA and qC are parameters, vB is a decision variable, and A, B, and C are sequences of zero or more index variables or index values appropriate for the decision variable or parameter. An objective is simply a statement of the form “maximize v” or “minimize v” for some decision variable v. Described below are examples of an optimization problem represented using a graphical modeling notation and methods of converting or mapping the graphical model to algebraic form.
An entity, as used herein, is an object, concept, or event relevant to the optimization problem and about which data is collected. An entity can be though of as a noun, i.e. a person, place, thing or concept. For example, an entity can be employees, projects, cities, etc (an entity instance is a specific entity value, e.g. Los Angeles). An attribute describes a property of the entity to which it is associated. For example, gender, height, and social security number, etc. Some attributes are identifying attributes in that the value of the attribute uniquely identifies the entity instance to which it is associated. For example, a social security number attribute uniquely identifies an employee instance, whereas gender and height are non-identifying attributes because they do not uniquely identify the employee entity instance. Relationships are made up of two links and describe an association between two entities or a recursive association of an entity with itself. Links, and consequently relationships, can be thought of as verbs. Links describe how the entities are related. For example, an employee entity works on a project entity and a project entity is assigned to an employee. The two links in this example, works on and is assigned to make up the relationship between the employee entity and the project entity.
Entities 102a-102n are shown in
Each of entities 102a-102n, in this example, has at least one attribute 106a-106x which defines characteristics of a given instance of entities 102a-102n. For example, entity 102b has one attribute 106b called “tailNumber,” while entity 102c has 4 attributes called “flightNumber,” “departureTime, ” “arrivalTime,” and “assignedOrder.” (assignedOrder represents the position of a particular flight in the list of flights flown by the same aircraft). However, in other embodiments, ail entity may have no attributes and is identified by its relationships with other entities.
An attribute value is a specific value of the attribute for a particular instance of the entity. In addition, each of entities 102a-102n is connected to at least one other entity by at least one relationship 104a-104m. As mentioned above, a relationship is an association between two entities, and is indicated by a line in
Each relationship 104a-104m has two links, which are the interpretations of the relationship in each direction. For example, link 108a indicates that a flight isFlownBy an aircraft, and link 108b indicates that an aircraft flies a flight. Link values are the corresponding concept at the instance level and correspond to sets. Therefore, given the relationship instance example above, the value of link 108a for flight instance NW23 is {N291US}, whereas the link value of link 108b for aircraft instance N291US may be {NW23, NW144}, indicating that this aircraft is assigned to fly both flights. In particular, the modeling notation in this example indicates the maximum degree of a link (i.e. the largest allowable size of the set.)
In this example, using Logic Data Structures (LDS), the possible choices of maximum degree are one and infinity. A maximum degree of one is indicated by a simple line end on a relationship 104a-104m. A maximum degree of infinity is indicated by a “chicken foot” or “crowfoot” on a line end of a relationship 104a-104m. For example, link 108a of relationship 104b has a simple line end at entity 102b, indicating that each instance of a flight is flown by at most one aircraft. In addition, link 108b of relationship 104b has a “chickenfoot” line end at entity 102c, indicating that each instance of an aircraft may fly zero or more flights. Hence, relationship 104b represents a one-to-many relationship between aircraft and flights. Although, the present example only allows for a maximum degree of one or many, it is to be understood that, in other embodiments, other models allow for the specification of other values for maximum degree and allow for the specification of minimum degree as well.
Since attributes 106a-106x and links 108a-108z are similar, the more general term “descriptor” is often used to refer to either a link or an attribute. Similarly, a descriptor value is an attribute value or a link value. In addition entities 102a-102n, attributes 106a-106x, relationships 104a-104m, and links 108a-108z all have names. A relationship's name, in this embodiment, is the concatenation of its two link names. For example relationship 104b is named “isFlownByFlies.” The mapping approach described below requires that no two entities 102a-102n or relationships 104a-104m have the same name, and that no two descriptors (links 108a-108z and attributes 106a-106x) of the same entity have the same name.
Entities 102a-102n are uniquely identified by an identifier. An identifier is a minimal set of an entity's descriptors that are sufficient to distinguish one instance of the entity from another. If the identifiers for entities 102a-102n consist solely of attributes, then each instance of entities 102a-102n is identified by the values for those attributes. However, if an entity identifier includes one or more links, then instances of the corresponding entity is partly or entirely identified by instances of other entities. The identifiers for entities 102a-102n, in this embodiment, are indicated graphically by bars that underline attributes and cross through the near ends of relationship lines. For example, “flightNumber” in entity 102c and “tailNumber” in entity 102b are identifying attributes. Also, each of entities 102b, 102c and 102n, in this example, have a cross bar in the near end of a relationship associating each entity to entity 102a. Hence, the identifier for entity 102c includes link and is {flightNumber, isPartOf}. Similarly, the identifier for entity 102b includes link 108c and is {tailNumber, isPartOf). In other embodiments, system entity 102a is not included. In such embodiments, the identifier for entities 102c and 102b would be simply the respective identifying attributes {flightNumber} and {tailNumber}. Identifying attributes correspond to index variables in the algebraic expression discussed above. Hence, each identifying attribute has an enumerated data type with known possible values. Non-identifying attributes correspond to parameters and decision variables, so each may be of data type real, integer, or binary depending on the particular embodiment and application.
Embodiments of the present invention can designate an entity (e.g. entities 102a-102n), a non-identifying relationship (e.g. relationship 104b) or a non-identifying attribute (e.g. attribute 106c) as a decision element. In this example embodiment, decision elements are marked by an asterisk. For example, relationship 104b, attribute 106c, and attribute 106a are all marked with an asterisk indicating that each is a decision element. Designating a non-identifying attribute as a decision element means that the attribute's value must be determined. The set of possible values is determined by the attribute's type (e.g. real, integer, or binary). Designating an entity or a non-identifying relationship as a decision element means that the solution must state which instances of the model element exist, among all the possible instances. The ability to define an optimization problem in which the existence of an entity or relationship instance is to be determined goes beyond the prior art where only attribute values may be determined.
In this example, some constraints on the optimization problem are expressed as part of the modeling notation. For example, the constraint that a given flight may only be assigned to at most one aircraft is expressed by the use a simple line ending as described above. However, other constraints are expressed using a functional notation. In particular, a constraint to define the decision variable and each flight's assigned order are defined, in this example, using a functional notation. For example, the constraint defining the decision variable in this example is given as: System.flightsFlown=count(System.hasAircraft.flies). The left hand of the expression references the single instance of entity 102a and the decision attribute 106a. The right hand of the expression navigates from this instance to the set of instances of entity 102b (i.e. aircraft), and from there to the set of instances of entity 102c (i.e. flights) that have been assigned to the aircraft. The size of this set of instances is computed by the count function.
The constraints are Boolean expressions that references elements of the diagram 100. In particular the Boolean expression, in this example, can be formed from one or more equalities between numeric expressions (e.g. Flight[fn1].assignedOrder=Flight[fn2].assignedOrder-1), inequalities between numeric expressions (e.g. Flight[fn1].arrivalTime<=Flight[fn2].departureTinme), equalities between single-valued entity references (e.g. Flight[fn1].flies=Flight[fn2].flies) and relationship references (e.g. IsFlownByFlies[flightNumber, tailNumber]). Additionally, in this example, a term in a numeric expression can be one of a numeric constant, a single valued attribute reference, the count function applied to an entity reference, and the sum function applied to an attribute reference. The functional notation used to express constraints not contained in the diagram 100 is relatively easier to understand than the algebraic form.
Additionally, in order to ensure that entities 102a-102n and relationships 104a-104m are uniquely identified, some embodiments of the present invention impose one or more of the following constraints: 1) each entity (other than system entity 102a) must have exactly one identifier, 2) Each identifier must include at least one link, 3) If a link is part of an identifier, its maximum degree must be one, and 4) the directed graph defined by entities 102a-102n and identifying links (e.g. links 108c and 108d) must contain no cycles. Some embodiments do not use all 4 constraints. For example, in some embodiments, an entity has more than one identifier. Also, even if the constraint requiring identifiers to include a link is used, this requirement is satisfied by using a link referencing system entity 102a as in the embodiment in
In particular, the identity constraint of diagram 200 is expressed as:
Each side of the identity constraint is a sequence of links (e.g. link 208a and 208b) that starts at entity 202d (the source entity) and navigates via identifying links to entity 202b (the destination entity). Each link is part of its entity's identifier and both path expressions have the same destination entity. Intuitively, it means that if you start from a specific instance of the source entity and navigate by either sequence of links, you will arrive at the same instance of the destination entity. Identity constraints are sometimes needed for relationships also, as described below in regards to
In particular, the constraint in this example is expressed by the functional notation:
A user can then modify, add to and delete from the data model through the interaction of user input element 406, processing unit 402 and display element 408. The user uses the graphical modeling notation to define the entities, attributes, relationships, and constraints, such as described above with regards to
Additionally, processing unit 402 retrieves instance data. In some embodiments, the instance data is retrieved from explicit user input via user input element 406 when defining the optimization problem. However, in this example embodiment, processing unit 402 retrieves the instance data from relational database 404. Processing unit 402 then uses a commercially available mathematical optimization package, such as GAMS/CPLEX, to solve the optimization problem. In some embodiments, processing unlit 402 is implemented through a processor and computer readable instructions. In such embodiments, instructions for carrying out the various methods, process tasks, calculations, control functions, and output of data are implemented in software programs, firmware or computer readable instructions. These instructions are typically stored on any appropriate medium used for storage of computer readable instructions such as floppy disks, conventional hard disks, CD-ROM, flash memory ROM, nonvolatile ROM, RAM, and other like medium.
At 504, constraints not defined by the graphical modeling notation are defined by the user using a functional notation. Such constraints include identity constraints, such as identity constraints described above with regards to
As described above with regards to
At 508, instance data for non-decision elements is retrieved. For each entity and non-identifying relationship, the set of instances are provided and consist simply of a set of key value sequences. For each non-identifying attribute, the value(s) are provided, along with the key value sequence that identifies the instance to which the attribute value(s) apply. In some embodiments, the instance data is provided explicitly via the user input element as part of the problem statement when defining the optimization problem. In other embodiments, the instance data is retrieved from a relational database, such as database 404, or similar source.
At 510, the processing unit maps the model and functional notation to algebraic form. In this example embodiment, mapping the model and functional notation includes mapping each enumerated data type used by an identifying attribute to an index set and mapping each decision entity to a binary decision variable. In addition, non-identifying relationships are mapped to one of a binary decision variable or parameter based on designation of the relationship as a decision element or not. The parameter values are defined by the instance data. A value of 1 indicates that a relationship exists between the associated entity instances and a value of 0 indicates that the relationship does not exist. Similarly, each decision attribute is mapped to a decision variable of the same type and other non-decision non-identifying attributes are mapped to parameters of the same type. The values of the parameters are again defined by the instance data. The decision variables and parameters have index variables corresponding to elements of the key of the entity for which the attribute is defined.
In addition, in this example, non-decision entities are mapped to binary parameters, where the parameter values are defined by the instance data. However, in other embodiments, the non-decision entities are not mapped. The identifying relationships between two entities are mapped implicitly and represented by the subscripts that the two entities have in common. In addition, the processing unit generates constraints. For example, for each non-identifying link that has maximum degree one, a constraint is generated to enforce the maximum degree. Similarly, for each identifying link, a constraint is generated to enforce referential integrity. In other words, for every instance of an entity whose identifier references a second entity, there must be a corresponding instance of the second entity. Likewise, for each non-identifying relationship, two referential integrity constraints are generated to ensure that relationship instances link only entity instances that actually exist.
In some embodiments, constraints only reference parameters and not decision variables. In such embodiments, the constraints serve as integrity checks on the instance data. However, in other embodiments, a referential integrity constraint may force the existence of a particular instance of a decision entity because instance data indicates that a dependent entity or relationship instance exists. Various techniques are known to one of skill in the art for mapping a Boolean constraint to an LP or MILP constraint. However, unique to embodiments of the present invention is the mapping of constraints dealing with entity references that include link names.
Entity references consist of an entity name, qualified by a sequence of key variables and/or explicit key values, followed by zero or more link names. If any of the links as a maximum degree of infinity, the entity reference is multi-valued, otherwise it is single-valued. A constraint is implicitly universally quantified over all possible values of all key variables appearing in the constraint. Similarly, an attribute reference consists of an entity reference followed by an attribute name. The attribute value is single- or multi-valued, depending on the entity reference.
In this example embodiment, mapping a constraint dealing with entity references that include link names, each link traversal results in a summation over the key variable(s) of the destination entity. For example, the constraint Flight[flightNumber].assignedOrder>=count(Flight[flightNumber].isFlownBy includes the link isFlownBy. This constraint states that each flight's assigned order must be at least 1 if the flight is assigned to an aircraft. The Boolean constraint above is mapped, in this example, as assignedOrder[flightNumber]>=sum(Flight[flightNumber]*IsFlownByFlies[flightNumber, tailNumber], tailNumber).
At 512, the algebraic form is passed to a commercially available mathematical solver, such as GAMS/CPLEX. In this example embodiment, the processing unit itself uses the mathematical solver to solve the optimization problem. However, in other embodiments, the processing unit passes the algebraic form to another processing unit for processing with the mathematical solver. A portion of the algebraic form for diagram 100 in
In order to illustrate some of the advantages of embodiments of the present invention over other methods of representing optimization problems graphically,
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement, which is calculated to achieve the same purpose, may be substituted for the specific embodiment shown. This application is intended to cover any adaptations or variations of the present invention. Therefore, it is manifestly intended that this invention be limited only by the claims and the equivalents thereof.