新的链状态设计仍有部分特性未实现
部分未成熟的功能
评分方式，以ConstraintStream取代Drools
关于ConstraintStream的底层实现基础，在一篇OptaPlanner官方发布，建议人们将Drools约束移植到ConstraintStream方式的文章里提到，ConstraintStream其底层也是基于Drools引擎的，只是提供一套对Java开发人员更为熟悉的函数式编程的ConstraintStreamAPI，以方便开发人员编写约束。见以下截：
最近一段时间，因为忙于【易排规划平台】的设计与开发工作，平台的一些功能设计，需要对OptaPlanner的各种特性作更深入的研究与应用。慢慢发现，OptaPlanner进入X版本之后，变化还是挺大的。对于我个人的项目、平台及咨询工作，这些变化中，大部分还是帮助很大的，但也发现一些不太合理的地方。这两天终于完成了平台的“规划评分分析功能”，就挤点时间出来，记录一下OptaPlannerX的这些变化吧。
前一个数据集出现异常时，后续再使用相同的ID，就会出现这样的异常
易排通用智能规划平台Q&A
SolverManager的ProblemID问题仍有Bug
上述描述的实现业务过程，也都在ProblemChange这个接口内实现即可。而且整个接口需要实现的方法也只有doChangeg一个方法，构造好一个ProblemChange对象，直接将这个对象传送给SovlerManager对象的addProblemChange方法即可。相对于之前版本的接口简单明了。
而到了X之后，将上述情况都整合成一个接口-ProblemChange.即无论你的操作是增加还是删除对象，无论你操作的对象无论是PlanningEntity还是ProblemFact；对于整个规划问题来说，都是对规划问题的修改，这些操作都抽象成一个接口-ProblemChange。只要我们新建一个类实现ProblemChanged这个接口即可。具体在这个接口的实现类中，需要如何实现新增、删除逻辑，还是需要我们自己去编写的，因为这属于业务逻辑的范畴；但也仅仅涉及这些对象被增删后，规划空间中剩余对象的一些业务性要求而已。而评分之类由引擎自行处理的逻辑则不需我们来处理。例如，在VRP场景中，如果有一个节点临时取消了，那么我们可以通过实时规划把这个节点从一条车辆行驶路线中删除。因为一条路线是由各个节点首尾相接构成的，如果你删掉这条路线上的一个节点，这条路线就被截断了。为了保持路线的完整性，你需要把被删除节点的前后两个节点连接起来，从而保证路线的完整。这就是删除一个节点需要处理的唯一一个需要人工处理的业务逻辑。当然各种场景需要处理的逻辑不同，例如添加一个节点，则不需要任何处理，因为一个新的对象出现，对OptaPlanner来说，相当于有一个对象还未被规划处理而已，它会自动把这个新的对象纳入考虑。
实时规划是OptaPlanner的一重大特有特性，目前在其它求解器还没发现类似的功能。就是考虑到当求解一个问题的时间过长时有可能在求解的过程中，数据已经发生变化，此时，实时规划就可以在未完成整份数据的完全求解，即可通过实时规划的API对数据进行更新，OptaPlanner会在已完成了部分求解的基础上，将变更纳入考虑，而无需停止整个规划过程，重新跑一次规划。实时规划的另一个经典应用场景，就是在VRP过程中的实进车辆调度功能，即车辆按原计划的路线行驶，当遇到路况不佳时，司机可以将路况反馈回服务端，以OptaPlanner为作引擎的服务端会马上作出反馈，重新规划一条新的路线给司机，并对后续的访问节点进行适当调配。其实这一过程同样适用于车间的调度工作，我们的平台将会添加这一功能-车间实时工作调度模块。
综上，大家在使用最新版本OptaPlanner的时候，有些功能还需要根据具体情况使用相应的方法，有一些新加上去的功能，看上去实现起来会更简洁，但其实它不一定成熟的。需要看情况使用。例如，因为上述新的链状功能的实现还没成熟，TaskAssigning示例的Consume功能在新的版本中被屏蔽，还没办法演示员工对任务完成情况的案例。如下。
根据OptaPlanner官方发布的计划，Drools评分方式将会在下一个主版本将会取消相关接口，届时将无法使用Drools脚本实现评分约束。取而代之的是ConstraintStream评分方式。而在我决定开发易排通用规划平台的时候，考虑到以后的兼容性及性能要求，我目前使用的是IncrementalJavaScorecalculation的方式实现相关约束。这种方法虽然实现起来难度最高，但其性能与灵活性也是最好的。考验的是开发人员对约束的实现能力，同时需要实现方案的分数分析，若使用Drools或ConstraintStream这两个主分方式，完成规划后，一个方案的分布也已经自动生成的，而使用IncrementalJavaScorecalculation则需要实现额外的接口，才能得到主分的分布信息。但我认为若作为一个定制项目，这些额外的付出需要根据实际情况考虑，而我们实现的是一个性能、灵活性要求都更高的产品，花更多的时间精力来实现IncrementalJavaScorecalculation是完全有必要的。
EasyJavascorecalculation-相对较容易实现但因为没有增量评分，性能稍差Droolsscorecalculation-基于Drools引擎，直接使用Drools脚本编写约束，性能一般表达方法丰富，但需要学习Drools，在X版本已被标识为“弃用”，即不再更新，预计在X将会取消该种计分方法。Constraintstreamsscorecalculation-新的约束流评分，实现起来较精简，但需要熟悉掌握各个函数式编程API，后台还是基于Drools引擎）IncrementalJavascorecalculation-性能最强、灵活性最高，但官方不推荐，原因是实现难度较大)
目前OptaPlanner关于分数计算有以下方法：
X之后，由该团队成员LukášPetrovický主导的ConstraintStream功能得到长足发展。事实上ConstraintStream早在X版本就已出现，但当时提供的API还是比较少，未能覆盖最常用的Drools表达的所有功能。到了X之后，相长的时间与版本里，都在完善ConstraintStream功能。ConstraintStream我们通常称之为“约束流”，熟悉Java8以上版stream特性的小伙伴应该知道，通过stream功能，可以实现类似SQL脚本一样的复杂查询。规划约束的本质也是对数据集的过滤、条件判断和评分设定。
实时规划接口优化
以下是我应用OptaPlanner过程中归纳的一些关于该软件的发展方向，及此过程中遇到的一些问题。
那么实时规划功能，在OptaPlanner的X版本中有哪些改善呢？我们在X以前一直都已经有实时规划功能，但那些版本我们需要实现实时规划，OptaPlanner提供的接口，还是相对比较零碎且繁复的。例如，当我需要增加一个数据时，需要先判断添加这个数据是一个PlanningEntity，还是一个普通的ProblemFact，不同的情况需要使用不同的API。添加与删除两种操作也使用不同的API区分。要实现实时规划，需要考虑：你是需要从规划空间中增加对象，还是删除对象；你增加/删除的是什么类型的对象；从而采用不同API，编写不同的处理逻辑。
Drools评分是目前最为成熟易用的一种评分方法，规划模型里的第一个约束，对应于Drools脚本中的每一个规则,一个规则体由LHS和RHS构成，其中LHS根据约束的要求实现规则逻辑，当LHS的所有条件都满足了，就会执行RHS中的内容，RHS主要是实现评分功能，即具体是要求引擎对哪个类型、哪个层次作出多少分值的惩罚或奖励。这种方法具有非常丰富的逻辑表达方式，丰富的Drools脚本表达能力也可以充分利用，要掌握Drools脚本也需要有一定的学习过程。
另外一个问题是，在x的其中一个版本，我们之前常用的时间链模式，提供了一种新的方式来实现，并引入了@IndexShadowVariable和@PlanningListVariable两个新的标注,其目标是简化时间链模式，令链实现起来更直观。使用过时间链模型的小伙伴应该还记得，该模式需要定义通过继承父类或实现接口的方式，来定义一条链上的锚和节点的关系，实现起来比较绕，可只要我们一旦掌握了要领，实现起来还是比较灵活的。OptaPlanner为了简单此模式，引入了列表规划变理。但事实上这个功能尚未完全成熟，还是有一特列情况无法实现的，而在官方的示例中，我们可以看到，一些功能未能实现而需要做些取舍。
GeoffreyDeSmet建议本人创建的issue
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论