论文部分内容阅读
1.引言
航运调度是港口物流企业作业的核心和关键，直接关系到公司的生产效率，生产指挥系统模型的好坏直接影响着公司调度指挥系统的设计和实现。UML（UNIFIED MODELING LANGUAGE统一建模语言）是一种面向对象的建模技术，是由世界著名的面向对象技术专家Grady Booch，Jim Rumbaugh和Ivar Jacobson发起的，在Booch方法，OMT方法和OOSE方法的基础上，几经修改完成的，它是为工业界所广泛接受的一种标准建模语言，使用UML表达生产系统的模型，概念明确，建模简洁，结构清晰，容易被程序员和用户所理解。PowerDesigner是一种CASE工具，支持数据库建模和面向对象建模，支持UML中的用例图、包图、类图、活动图、部署图、协作图、组件图、复合结构图、对象图、顺序图、状态图等，以描述系统的静态结构和动态结构，我们选择它作为UML的建模工具进行生产指挥系统的建模。
2.需求模型
在软件生命周期中，需求分析是其中一个重要的阶段。从软件工程的角度来说，需求分析的质量对软件的质量影响是巨大的，在后续阶段改正需求分析的错误要付出高昂的代价，往往导致软件的功能不是用户想要的，而用户的真正需求却并未实现。PowerDesigner的RQM是一种实用的需求管理工具，可以记录用户需求，定义需求的优先级、工作量、风险，管理需求的状态。经过与业务人员的沟通，我们确定了系统主要解决三个方面的问题：船舶管理、作业管理、系统接口。其中船舶管理包括船舶资料的登记、预确报管理和船舶动态（靠泊、离泊、移泊）管理;作业管理包含作业计划、配工和作业线管理;系统接口包括与公司杂货系统的接口、与公司机务系统的接口以及与集团调度系统的接口。
3.系统模型
我们根据前面的功能划分，将生产指挥系统分为三个相关的子系统，其中作业管理子系统需要接口管理子系统提供的库场货物信息和机械信息，船舶管理子系统为作业管理子系统提供船舶资料和动态信息。
3.1业务简述
调度综合计划员与船代沟通，掌握近日预抵的船的动态，并将船舶信息登记在月度船舶登记表中。船舶到港前，综合计划员接到集团调度中心的船舶动态，编制靠泊安排，安排船舶靠泊，在船舶在港期间，如因作业需要实施移泊，应编制移泊安排。单日计划员根据在港船舶的动态和载货情况、货物库存等信息编制昼夜作业计划表，交给值班调度。值班调度根据昼夜作业计划表和当班人机情况，制定班作业配工表，发给装卸队和机械队，并签发作业票给装卸队。作业开始后，值班调度掌握各作业线状态，作业结束后记录当班作业量。装卸队和机械队接到班作业配工表后，在配工表上实施“挑勾”，各自分配每个队组或机械的工作，作业开始后，分别记录作业线上工人变化情况和机械变化情况。
3.2功能定义
我们根据调度业务过程，界定了生产指挥系统的范围，确定了系统的功能。从系统的执行者的角度出发，只定义功能的内容和功能分工，并不体现出功能的内部实现，便于被系统的用户所理解，使得用户了解自己在系统中的角色。
我们经过分析用例，得到了生产指挥系统的系统功能大致如下：
1）船舶资料管理和登记。包括船舶基本资料的增、删、改，船舶登记表的维护。
2）船舶动态管理。包括船舶靠泊、移泊、停泊的计划安排。
3）昼夜计划。昼夜作业计划表和装卸要求的增删改。
4）作业配工。配工表的制定和发布到装卸队、机械队等单位。
5）作业线状态管理。包括作业线的开工、待工、复工和完工状态的维护。
6）日作业实际。当班次作业数据的增删改。
7）挑勾。装卸队和机械队在配工表上选择自己承担的工作，并反馈给值班调度员。
8）作业人员的变更和作业机械的调整。包括补人记录和机械变更记录。
9）接口功能。从杂货系统中取得货物信息，从集团调度系统中获取船舶预报信息，从机务系统中得到机械信息。
3.3系统设计
我们使用类图建立了系统模型的静态结构，以表达组成系统的类及其相互间的关系，通过类间关系的建立，我们可以清楚地了解系统中对象的结构和所处的层次，及各类的属性和该类执行的主要操作。
3.3.1设计原则
1、系统类模型建立时应该尽量少地考虑实现。系统模型是业务逻辑的抽象，只体现了业务实体在业务流程中的相互作用关系，模型的实现方式、编码语言和运行平台等因素不能影响业务模型的设计，过多地考虑系统的实现会束缚模型的设计，影响模型的质量。
2、设计的目标模型应该尽可能地符合开放封闭原则（Open Closed Principle）。当增加功能需求的时候，可以方便地通过扩充新的类来支持新功能的实现，而不能够修改原有模型的类和类中的方法以支持新加入的功能。
3、类间的关联要适度，系统类设计应该遵循迪米特法则（Law of Demeter）。迪米特法则，又称为最少知识原则（Least Knowledge Principle： LKP），对象与其它对象的了解要尽可能少。这样做的好处是将大大降低类间的耦合，减少类对其他类的依赖，可以使系统的功能模块相对独立，相互间少有依赖关系，使得对于类及类的功能扩展不至于导致模型的大面积修改，使模型稳定而增强健壮性。系统的模块分解和编码也应该遵循这一原则。
4、盡可能地复用功能相近的类及其方法，一来可以使模型功能的修改相对容易，修改点少，二可以减少模型中的类，使得模型简单且易于理解。
3.3.2设计思路
我们从用例出发，逐层分解，先找到在业务模型中所作用的类，再通过分析这些类，将密切联系的类组织到一起，并分组，标记类间的关联和类的依赖关系，最后填充类的信息，形成类图，以描述目标业务系统的模型。
3.3.3建立模型
作用于系统中的类主要有CompPlanner（综合计划员）、DailyPlanner（单日计划员）、Watcher（值班调度员）、Vessel（船）、Cargo（货）、CarriTeam（装卸队）、MechanicalTeam（机械队）、Workline（作业线）、Dailysheet（昼夜计划表）、MatchSheet（配工表）、DynamicSheet（动态单）。
4.结束语
本文使用了面向对象方法以描述生产指挥系统的建模过程，以PowerDesigner为建模工具，UML为建模语言建立了生产指挥系统的模型。随着信息技术的逐步深入，面向对象方法在软件的分析和设计中所发挥的作用越来越大，面向对象分析和设计可复用、易扩展、结构清晰的优点日益突出，在面向对象思想指导下的软件开发，会提高软件的效率和质量，保证软件的健壮性和可维护性。
航运调度是港口物流企业作业的核心和关键，直接关系到公司的生产效率，生产指挥系统模型的好坏直接影响着公司调度指挥系统的设计和实现。UML（UNIFIED MODELING LANGUAGE统一建模语言）是一种面向对象的建模技术，是由世界著名的面向对象技术专家Grady Booch，Jim Rumbaugh和Ivar Jacobson发起的，在Booch方法，OMT方法和OOSE方法的基础上，几经修改完成的，它是为工业界所广泛接受的一种标准建模语言，使用UML表达生产系统的模型，概念明确，建模简洁，结构清晰，容易被程序员和用户所理解。PowerDesigner是一种CASE工具，支持数据库建模和面向对象建模，支持UML中的用例图、包图、类图、活动图、部署图、协作图、组件图、复合结构图、对象图、顺序图、状态图等，以描述系统的静态结构和动态结构，我们选择它作为UML的建模工具进行生产指挥系统的建模。
2.需求模型
在软件生命周期中，需求分析是其中一个重要的阶段。从软件工程的角度来说，需求分析的质量对软件的质量影响是巨大的，在后续阶段改正需求分析的错误要付出高昂的代价，往往导致软件的功能不是用户想要的，而用户的真正需求却并未实现。PowerDesigner的RQM是一种实用的需求管理工具，可以记录用户需求，定义需求的优先级、工作量、风险，管理需求的状态。经过与业务人员的沟通，我们确定了系统主要解决三个方面的问题：船舶管理、作业管理、系统接口。其中船舶管理包括船舶资料的登记、预确报管理和船舶动态（靠泊、离泊、移泊）管理;作业管理包含作业计划、配工和作业线管理;系统接口包括与公司杂货系统的接口、与公司机务系统的接口以及与集团调度系统的接口。
3.系统模型
我们根据前面的功能划分，将生产指挥系统分为三个相关的子系统，其中作业管理子系统需要接口管理子系统提供的库场货物信息和机械信息，船舶管理子系统为作业管理子系统提供船舶资料和动态信息。
3.1业务简述
调度综合计划员与船代沟通，掌握近日预抵的船的动态，并将船舶信息登记在月度船舶登记表中。船舶到港前，综合计划员接到集团调度中心的船舶动态，编制靠泊安排，安排船舶靠泊，在船舶在港期间，如因作业需要实施移泊，应编制移泊安排。单日计划员根据在港船舶的动态和载货情况、货物库存等信息编制昼夜作业计划表，交给值班调度。值班调度根据昼夜作业计划表和当班人机情况，制定班作业配工表，发给装卸队和机械队，并签发作业票给装卸队。作业开始后，值班调度掌握各作业线状态，作业结束后记录当班作业量。装卸队和机械队接到班作业配工表后，在配工表上实施“挑勾”，各自分配每个队组或机械的工作，作业开始后，分别记录作业线上工人变化情况和机械变化情况。
3.2功能定义
我们根据调度业务过程，界定了生产指挥系统的范围，确定了系统的功能。从系统的执行者的角度出发，只定义功能的内容和功能分工，并不体现出功能的内部实现，便于被系统的用户所理解，使得用户了解自己在系统中的角色。
我们经过分析用例，得到了生产指挥系统的系统功能大致如下：
1）船舶资料管理和登记。包括船舶基本资料的增、删、改，船舶登记表的维护。
2）船舶动态管理。包括船舶靠泊、移泊、停泊的计划安排。
3）昼夜计划。昼夜作业计划表和装卸要求的增删改。
4）作业配工。配工表的制定和发布到装卸队、机械队等单位。
5）作业线状态管理。包括作业线的开工、待工、复工和完工状态的维护。
6）日作业实际。当班次作业数据的增删改。
7）挑勾。装卸队和机械队在配工表上选择自己承担的工作，并反馈给值班调度员。
8）作业人员的变更和作业机械的调整。包括补人记录和机械变更记录。
9）接口功能。从杂货系统中取得货物信息，从集团调度系统中获取船舶预报信息，从机务系统中得到机械信息。
3.3系统设计
我们使用类图建立了系统模型的静态结构，以表达组成系统的类及其相互间的关系，通过类间关系的建立，我们可以清楚地了解系统中对象的结构和所处的层次，及各类的属性和该类执行的主要操作。
3.3.1设计原则
1、系统类模型建立时应该尽量少地考虑实现。系统模型是业务逻辑的抽象，只体现了业务实体在业务流程中的相互作用关系，模型的实现方式、编码语言和运行平台等因素不能影响业务模型的设计，过多地考虑系统的实现会束缚模型的设计，影响模型的质量。
2、设计的目标模型应该尽可能地符合开放封闭原则（Open Closed Principle）。当增加功能需求的时候，可以方便地通过扩充新的类来支持新功能的实现，而不能够修改原有模型的类和类中的方法以支持新加入的功能。
3、类间的关联要适度，系统类设计应该遵循迪米特法则（Law of Demeter）。迪米特法则，又称为最少知识原则（Least Knowledge Principle： LKP），对象与其它对象的了解要尽可能少。这样做的好处是将大大降低类间的耦合，减少类对其他类的依赖，可以使系统的功能模块相对独立，相互间少有依赖关系，使得对于类及类的功能扩展不至于导致模型的大面积修改，使模型稳定而增强健壮性。系统的模块分解和编码也应该遵循这一原则。
4、盡可能地复用功能相近的类及其方法，一来可以使模型功能的修改相对容易，修改点少，二可以减少模型中的类，使得模型简单且易于理解。
3.3.2设计思路
我们从用例出发，逐层分解，先找到在业务模型中所作用的类，再通过分析这些类，将密切联系的类组织到一起，并分组，标记类间的关联和类的依赖关系，最后填充类的信息，形成类图，以描述目标业务系统的模型。
3.3.3建立模型
作用于系统中的类主要有CompPlanner（综合计划员）、DailyPlanner（单日计划员）、Watcher（值班调度员）、Vessel（船）、Cargo（货）、CarriTeam（装卸队）、MechanicalTeam（机械队）、Workline（作业线）、Dailysheet（昼夜计划表）、MatchSheet（配工表）、DynamicSheet（动态单）。
4.结束语
本文使用了面向对象方法以描述生产指挥系统的建模过程，以PowerDesigner为建模工具，UML为建模语言建立了生产指挥系统的模型。随着信息技术的逐步深入，面向对象方法在软件的分析和设计中所发挥的作用越来越大，面向对象分析和设计可复用、易扩展、结构清晰的优点日益突出，在面向对象思想指导下的软件开发，会提高软件的效率和质量，保证软件的健壮性和可维护性。