二次订单设计（共7篇）
二次订单设计 篇1
一、变革中的城市设计:从一次订单设计到二次订单设计
1. 从理论研究到实践探索
现代城市设计作为中国城市规划体系中的重要组成部分, 自引入以来其地位和作用不断加强, 城市设计也从初期的概念引入、理解争论, 中期的理论研究、方法创新, 走向了设计实践和指导建设的应用。目前, 关于总体规划 (以下简称总规) 阶段的整体城市设计和控制性详细规划 (以下简称控规) 阶段的局部城市设计实践探索已相当广泛, 城市设计在三维空间形态研究上的优势也得以充分体现, 大大弥补了总规与控规的不足。
2. 从重视方案到重视导则
从理论研究到实践探索, 是中国城市设计发展迈出的重要一步, 然而大量的问题仍然摆在面前。凝聚了规划工作者大量心血与努力的优秀城市设计方案为数不少, 应该成为指导城市建设的一种工具, 而城市设计导则就是连接方案设计与指导实施的一座桥。
美国伊利诺伊大学的瓦可·乔治 (R.Varkki George) 教授提出:当下的城市设计方法应该是“二次订单设计” (Second-order Design) 方法, 即城市设计师并非像建筑师那样直接设计出具体产品, 而是设计影响城市形态的一系列“决策环境”, 使得下一层次的设计者们在这一决策规则指导下进行专业化的具体设计。[1]
城市设计导则正是实现城市设计目标最重要的管理依据, 是城市设计方案的最终体现, 目前关于它的研究已成为推动城市设计技术发展的重要方面, 其在实践中的作用和意义甚至超过了方案研究本身。
3. 从设计师主导到“集群化”设计团队
随着城市问题越来越复杂, 城市设计的研究范畴已经远远超出了对城市物质空间的关注, 涉及的学科领域越来越多, 多专业合作的设计团队越来越普遍。另外, “二次订单设计”要求城市设计与管理实施结合, 这也促使规划管理部门与项目实施主体的共同参与。
在“集群化”设计团队背景之下, 城市设计及设计师的角色都发生了重大转变。城市设计更加强调从设计到实施的全过程参与, 而设计师本身也需要更加关注设计平台搭建、信息资源梳理、建立沟通渠道等方面, 推进设计的实施操作。
本次研究针对城市发展中的具体问题, 以“顺义老城区城市设计”为基础, 将理论研究与实施操作相结合, 探索城市设计导则的编制方法。
二、更新中的顺义老城:从相对滞后到新城核心
1. 发展背景与现状问题
国家目前的一系列政策指向表明, 北京的功能定位将进一步调整, 非首都核心功能将被疏解, 新城成为承担疏解中心城区人口和功能、集聚新产业、带动区域发展的重要地区。
顺义老城区作为顺义新城的心脏, 聚集着大量的优势资源, 但由于长期发展所遗留的诸多问题难以解决而逐渐成为多重矛盾的交织点。
2. 针对现状问题的改造度分析
顺义老城区城市设计方案基于现状问题, 从改造的可行性评价和必要性评价两方面入手, 化繁就简, 选择改造空间。
面对老城区复杂的现状问题, 我们从建筑质量、容积率、用地权属三个子项入手, 以地块为单元进行综合评价和打分, 原则上以建筑质量越差、容积率越低、用地权属越单一 (或沟通协调难度越小) 判断改造的可行性越高, 以此划分改造可行性的强弱分区。这是一种自下而上, 从现状入手的分析方法。
在此基础上, 我们同时对老城区改造必要性进行分析。原则上, 对于老城未来目标实现和品质提升具有重要影响的地区, 以及有明确改造意向或强烈发展需求的地区, 虽然改造难度较大, 但仍必须作为改造区域进行重新规划设计。这是一种自上而下, 从目标入手的分析方法。
将改造可行性分析与必要性分析的结论进行叠加, 改造度较强的区域与近期必须改造的区域即为近期改造区域, 与之相反, 改造度较弱的区域与改造必要性较小的区域即为近期保留区。前者是本次城市设计的重点。
3. 针对核心理念的研究框架
面对老城区现有的复杂问题及高端发展定位, 本次城市设计提出三大核心理念。
其一, 立体环网建构安全城区。交通专项研究的目标是要为顺义老城区建构人性化无障碍的“环状”步行系统、四通八达的轨道交通“节点”及便捷高效的交通换乘系统, 实现城市交通的三维立体发展。
本次城市设计从交通的平面转换和竖向转换两个方面入手, 分别对平面交通转换中的地面车行系统、地面步行系统、地下交通系统、地上二层交通系统和竖向交通转换中的步行交通转换、车行交通转换进行研究, 并提出相应策略及解决方案, 实现安全、高效的立体环网交通格局。
其二, 复合功能打造活力中心。功能专项研究的核心理念是以多种功能打造老城复合功能极核, 以功能集聚提升老城核心区竞争力, 以三维功能组织塑造人性化城市空间。
结合新城控规, 本次城市设计对用地进行了进一步的优化与调整, 商业、服务业设施用地及公共管理与公共服务用地在老城核心区中占据较大比重, 现有的体育场馆及公园得到保留。
其三, 整体思维引领现代风貌。风貌研究的核心是构建人性化的城市空间, 为下一层次规划及建筑设计提供基本的控制原则。本次城市设计以建筑控制线、建筑界面、建筑高度等控制要素对城市风貌进行统一控制, 作为城市设计导则编制的依据。
在此基础上, 形成以绿色生态环、人文公共环为基础, 以光明街景观轴、新顺街商业轴、府前街办公轴为骨架, 集办公、商业、医疗、体育、文化、娱乐、休闲于一体的城市核心区 (图1) 。
三、探索中的导则编制:四大核心切入点
城市设计导则是连接城市设计目标与城市建设管理之间的纽带, 是城市设计实施的关键点, 其核心内容在于将城市设计谋划的美好蓝图转化为有效的管理工具, 通过“二次订单设计”, 实现城市设计控制目标, 从设计引导和建设管理两个方面发挥作用, 为城市设计的实施提供一个操作平台。
通过对顺义老城区城市设计的研究, 此次城市设计导则的编制紧扣核心问题, 从以下四个切入点进行研究。
1. 切入点之一:以北京控规为研究基础
本次研究明确城市设计导则的编制必须以控制性详细规划的编制为前提, 即控规必须先于城市设计编制, 然后将城市设计导则成果作为控规成果的有效补充, 共同作为规划控制依据。
根据北京新城控规划分的街区层面和地块层面两个层次, 城市设计导则控制也将分为两个层面。考虑到城市设计研究深度, 本次导则控制的重点集中在街区层面。
注:“●”为规定性控制内容, 以细则控制要求为准;“△”为引导性控制内容, 以设计通则为准
尽管本次城市设计导则研究和现行的北京新城控规都是在总体规划指导下对局部地段和局部要素的设计, 但两者并不等同。
首先, 从性质和管理效果来看, 两者既有相同点, 又有不同点 (表1) 。
其次, 从控制要素来看, 控制性详细规划对城市公共空间方面的控制内容较为欠缺, 一些控制内容还不够具体, 未能全面反映公共空间的控制目标;城市设计导则针对城市中某类或某一公共空间制定, 其控制以公共空间为核心, 围绕涉及公共空间的各方面展开 (表2) 。
控制性详细规划管理与城市设计导则管理各具优势与不足, 建议规划管理采用两者结合的使用模式, 以兼顾环境建设的质量和开发管理的效率与公平 (图2) 。
2. 切入点之二:以公共空间为研究对象
本次城市设计导则研究以公共空间管理为载体, 以人的需求为出发点, 研究人对公共空间的视觉感受、认识、体验、利用等方面的要求。城市公共空间属于公共价值领域的城市空间, 是城市规划干预的公共价值领域的主要对象, 其主要内容是城市人工开放空间, 或言之人工因素占主导地位的城市开放空间。
本次对城市公共空间的城市设计导则控制主要集中在四个方面:公共开放空间, 包括广场、公园、商业步行街、滨水步道等;公共交通, 包括步行道、车行道、轨道交通、停车设施等;公共建筑形态, 包括建筑界面、建筑高度轮廓线、建筑色彩、建筑元素等;公共环境设施, 包括地面铺装、绿化种植、广告指示牌、坐憩设施等。
3. 切入点之三:以通则和细则为成果体系
街区层面的城市设计导则成果体系包括通则和细则两个部分 (表3, 图3) 。
通则是在总目标指导下, 用以指导城市设计编制, 对其重点控制内容提出的普适性要求, 是指导细则编制的重要依据。通则的制定不针对某个特定区域, 但特定区域的城市设计可以根据实际需要, 选择与之相适应的通则控制内容。
依据北京新城城市设计总目标提出的要求, 本次城市设计导则通则确定了公共开放空间、公共交通、公共建筑形态、公共环境设施四个方面的重点控制内容, 并分别提出建设目标、策略及实施途径。针对上述四个方面共提出的49条策略是通则控制的具体内容。
与通则的普适性不同, 细则是针对具体设计地段和项目作出的具体控制要求, 因此细则的研究必须以具体城市设计方案为基础。本次城市设计导则细则研究以北京顺义老城区城市设计为基础, 针对顺义老城区改造提出具体的控制细则。
4. 切入点之四:因地制宜选择控制要素
城市设计导则细则是实现城市设计目标的控制手段, 因此, 其控制要素的选择也必须基于城市公共空间设计要素之上。细则要素的选择, 实质上就是在细则控制要素库中选择直接影响城市设计目标实现的核心要素, 作为规划管理与控制的核心内容 (表4) 。
四、试点中的实施平台:城市设计导则管理
1. 法定保障程序
城市设计导则的管理必须以法定的程序作为保障, 北京目前已将城市设计导则成果纳入规划管理程序。在此基础上, 还必须保证城市设计导则顺利有效地实施, 这就要求在下一层次的方案编制、方案审批及方案实施的每一个过程中, 都要严格遵守城市设计导则中规定的内容。
2. 管理手段
城市设计导则的管理采用“一表一图”的形式, 即在一张表上完成对城市设计导则通则内容的管理, 在一张图上完成对具体项目城市设计导则细则的管理。
城市设计导则管理表一共分为五大栏, 其中, “类别”列出城市设计导则通则控制的四个方面, “控制内容”是城市设计导则提出策略内容的概述, “适用性”是对城市设计导则控制内容是否适用做出的判断, 而“项目审核”则是规划管理部门对城市设计导则政策是否执行作出的选择判断 (表5) 。
街区城市设计导则细则控制图纸是城市开发的设计条件之一, 是开发建设单位进行所有开发活动必须遵循的法定依据。在对地块进行开发时, 开发单位和设计单位可在其控制要求范围内制定地块城市设计导则细则控制的各项指标 (图4) 。
结语
城市设计导则是对“蓝图式”城市设计成果形式的延伸, 重点在于影响城市设计形态“决策环境”的设计。正如本期卷首语所期待的, 希望“二次订单设计”成果, 对中国新型城镇空间建设和品质的提升起到积极作用。
摘要：本文以瓦可·乔治教授提出的“二次订单设计”为理论基础, 论述城市设计导则控制的研究方法、成果体系、成果表达及管理方式, 探索“二次订单设计”的城市设计成果编制体系, 并以北京顺义老城区城市设计项目实践探索。
关键词：城市设计,导则控制,城市设计管理,二次订单设计
参考文献
[1]GEORGE R V.当代城市设计诠释[J].金广君, 译.规划师, 2000 (6) :98-103.
物流订单信息平台的分析与设计 篇2
物流业是系统服务性行业, 车辆资源是其重要的基础资源, 其中的大部分车辆资源集中于个体手中。为了更好的整合社会物流车辆资源, 充分将社会中个体和企业车辆投入物流运输中, 可以针对其建立物流订单的信息平台。托运人也可以扩大选择范围, 从该平台中选择适合的承运人。为保证信息的真实性, 平台将对托运人和承运人进行身份认证审核。
在本文中, 首先介绍该系统的需求, 然后对系统进行需求分析和系统设计, 结合UML相关图形, 建立面向对象分析设计模型, 其中详细说明系统的用例模型, 静态模型和数据库概念模型。
2 系统需求
(1) 托运人在需要发货时, 可以及时查看各类承运人的信息, 包括资质、联系方式、历史记录评价、车辆状态等信息, 便于快速对比选择和联系, 用最短的时间找到最合适的承运人。
(2) 承运人可以随时查看各类托运人发布的信息, 选择适合的订单联系托运人, 降低空车时间, 提高收入水平。
(3) 提供了对托运人和承运人真实身份的审核认证, 避免虚假信息, 保证交易双方的诚信。
(4) 访客在进行身份审核认证之前, 无法看到包含托运人和承运人联系方式的具体信息。
(5) 为交易双方提供评价机制, 建立评价档案, 既能约束双方高效优质的完成订单过程, 又可以为日后其他各方提供参考。
(6) 托运人和承运人之间订单交易中的资金由本平台的网站运营方托管, 保证双方不会因为资金原因无法完成订单。订单交易记录 (包括资金记录) 可以作为纠纷发生时的证据。
(7) 为保证运输安全, 对承运人收取一定的保证金, 保证金额可以由托运人指定, 在交易成功后退回, 保证金由本平台的网站运营方托管。
(8) 提供纠纷管理机制, 发生货运事故时, 双方可以提供货运事故记录等证据的扫描件, 由本平台的网站运营方进行协调处理, 最大限度的保证双方利益。
3 需求分析建模
(1) 用例模型
业务参与者包括系统管理员、承运人、托运人和访客。系统管理员是指整个网站系统的管理者。承运人是指使用汽车从事货物运输并与托运人订立货物运输合同的经营者。托运人是指与承运人订立货物运输合同的单位和个人。承运人和托运人均包括个体和企业两种类型。
系统管理员负责系统基础数据管理, 账号权限等系统管理, 对用户进行身份认证审核管理等。托运人和承运人均需要进行身份认证, 在审核通过后托运人才可以下托运订单, 承运人才可以接托运订单。承运人在托运人下订单后, 可以查看托运人信息, 承接适合的托运订单。托运人在托运人接订单后可以查看承运人信息, 选择适合的承运人。订单意向达成后, 托运人需委托系统进行运费托管, 承运人也需要向系统提交保证金。如运输过程中发生各类事故导致订单货物出现问题, 则双方进行货运事故处理。托运人确认订单标志订单完成, 双方可以进行评价。双方也可以对订单进行各类统计。访客无需进行身份认证, 可以直接浏览业务信息, 但无法查看包含托运人和承运人联系方式的完整信息。
可以使用业务用例图对整个系统进行业务分析建模, 如图1所示:
(2) 静态模型
从用例分析中提取系统相关的名词, 使用类图中的类进行描述, 分析类与类之间的关系, 使用关联、继承等关系连接两个类, 系统分析类图如图2所示:
4 系统设计
(1) 体系结构设计
采用领域驱动建模方法进行体系结构设计, Repository层实现对数据库的访问操作, Model层实现系统模型, Service层实现业务服务, 使用Web Service方法具体实现, Web UI层实现界面操作。
(2) 数据库设计
考虑静态类之间的关系, 按照以下原则进行数据库设计:
a.当关联关系中两个类之间为1:1关系时, 两个实体类合并为一张数据表, 比如人员信息和认证信息、居民身份证、账户之间的关系均为1:1, 所以合并为1张人员信息表 (Member) 。
b.当关联关系中两个实体类之间为1:n关系时, 两个类对应两张数据表, n方增加对1方的外键引用, 比如托运订单和托运订单明细之间的关系为1:n, 所以对应两张表, 即托运订单表 (Order) 和托运订单明细表 (Order Detail) , 托运订单明细表中增加Order ID属性关联托运订单表。
c.当关联关系中两个实体类之间为m:n关系时, 两个类对应三张数据表, 每个类对应一张表, 增加一张关系表, 比如权限和人员信息类 (人员信息与账户为1:1关系) 为m:n关系, 所以对应人员信息表 (Member) 和权限表 (Authority) , 再增加关系表Member Authority。
d.继承关系采用将父类和子类合并为一张数据表的方法, 比如企业信息 (父类) 和个体工商户 (子类) , 企业法人 (子类) 合并为一张企业信息表 (Enterprise) 。
使用E-R图对整个系统进行概念模型建模, 如图3所示。
5 结束语
本文运用面向对象的分析与设计方法, 分析设计了一个物流订单平台系统, 为同类系统的分析设计过程提供了参考, 具有一定的理论意义和现实价值。
摘要：物流订单信息平台旨在整合社会车辆资源, 帮助托运人和承运人之间建立物流订单相关的信息平台。本文介绍了该系统的需求内容, 使用UML用例图建立用例模型, 使用UML类图建立静态模型, 以描述系统的需求模型。在系统设计阶段, 设计了该系统的软件体系结构和数据库。
关键词：物流订单,OOAD UML
参考文献
[1] (英) 克里斯托弗著, 何明珂等译.物流与供应链管理 (第4版) .北京:电子工业出版社, 2012
[2]邵维忠, 杨芙清.面向对象的分析与设计.北京:清华大学出版社, 2013
[3] (英) 萨默维尔著, 程成等译.软件工程 (原书第9版) .北京:机械工业出版社, 2011
[4]谭云杰.大象——Thinking in UML (第二版) .北京:水利水电出版社, 2012
二次订单设计 篇3
目前汽车行业越来越广泛采用了多路传输分布式汽车电子电气系统, 在确保满足总装电子电气工艺领域的单件订单化生产的要求情况下, 整车装配完成后还需要实施大量的相关工艺操作和工序内容[1]。在这个过程中总装现场电子电气生产设备提出了大量电子电气订单生产信息的新需求[2], 并且有很高实时性和订单化的要求。因此如何设计建立相关的汽车总装电子电气订单生产信息系统成为整车企业面临的重要现实问题。
1 整车电子电气系统总装阶段工业化的特点
目前的行业趋势是在整车电子电气系统设计时, 主要考虑的是如何在尽可能减少各类零件数量的同时, 实现相关零件的标准化, 而且还能满足不同配置的个性化功能的需要。这比较类似于如今计算机制造业的思路。基于这种思路, 整车电子电气系统在总装阶段的工业化方案设计也提出了新的要求[3]。在相关传统工业化方案设计的基础上, 还应满足的新原则是:
(1) 软硬件分离的设计思路, 将电控单元硬件标准化, 也就是构成电控单元的单板机或单片机硬件系统的设计结构相对固化。同时将功能和配置的差别用软件的方式实现。
(2) 各电控单元的软件加载的现场实时化, 即在整车装配完成后, 根据订单的要求和车辆配置级别要求, 在现场进行软件植入加载操作。这样可以利用相对单一的电控单元硬件加载不同的软件。可以减少电控单元零件的种类, 减少采购成本, 同时便于物流和生产的管理[4]。例如不同的车型采用的是同一电喷系统, 其硬件完全一致, 只是在总装生产线上实时的加载不同的发动机控制软件, 以满足其不同驾驶特性。
(3) 电控单元系统的编码配置的现场实时化, 即在电控单元软件加载完成后, 通过设置电控单元中某些参数的值, 使得该电控单元系统能够完全与每台车辆的配置和装备情况一致, 而这些配置可能是订单化的。例如很多高端车型的不同配置水平差别较大, 但其关键性核心电控单元采用的统一的零件, 只是在生产现场根据车辆的配置订单情况, 实时的对其参数进行设置 (多时可达数百甚至上千个参数) , 确保与整车配置情况协调一致。使得车型以其丰富灵活的配置组合满足了用户个性化的需求。
(4) 对于需要精密电子控制的场合, 实施现场自学习操作。这样既可以达到精确控制的目的, 又降低了对相关控制部件的制造精度要求, 节约了相关的制造成本。例如电子稳定程序控制系统 (ESC) 需要精确的车辆直线行驶时的方向盘角度位置, 由于每台车和组成部件不可避免的制造误差, 这些误差的累积使得不可能给出一个统一的零位值。为此需要在现场根据每台车进行方向盘的零位学习记忆。从而确保了ESC系统的精确和可靠的运作。
2 总装电子电气订单生产信息需求
基于上节所述的工艺设计思路, 总装现场工序的完成需要实施生产相关产品和工业化信息的传递和导入, 在生产线上对每个订单车辆实施电子加载和电子编码工艺操作, 以及电子电气相关自动化检查 (以下简称“电检”) 时, 必然会遇到一个订单车辆识别和信息的获取和传递的问题。尤其是针对国内多数整车企业总装生产线车型高度混流的现状, 既有不同系列和级别的车型, 又有同一车型内不同配置和档次的车辆混流[3]。在实施电子加载和编码操作时必须能够准确的获取待加载订单车辆的车型和配置信息, 同时必须正确获得每个电控单元的配置参数设置信息, 以便完成其电子编码的操作。
总装电子电气订单生产信息传递基本路径见图1。产品及其制造信息由计算机主机通过内部工业网络和后面要介绍的无线方式传输到专用的诊断设备上, 如ODISSEE现场专用诊断仪。然后由诊断设备将信息进行处理, 转化成相应的KWP2000或UDS服务语句, 然后按CAN诊断协议的标准将数据帧发送到车辆的诊断口, 最终针对某一特定的电控单元零件进行电子加载和电子编码等操作。
3 总装电子电气订单生产信息系统
3.1 系统总体结构和运行流程
为了适应这些产品和制造信息的转化和传输, 整车企业需要建立和调整相应的计算机系统, 以确保能将需生产订单车辆的电子电气信息传送到现场工业设备上。
总装电子电气订单生产信息系统的基本结构见图2。在制造信息处理系统中根据市场部门维护到车辆订单系统的订单需求信息, 提取相应的电子电气产品和制造信息, 并按照车辆打包传输到生产计划排产系统中。订单车辆上线装配时就可以实时获得这些信息, 以进行相应的电子电气工艺操作。从生产信息系统传到专用诊断设备的方式为2D即二维条码的方式。在数据初始化工艺程序里面对电子加载和编码的操作的输入信息完全是来自上游信息系统。而在电检工序使用一维31位条码的方式传递信息, 具体编码信息的检查, 则需要工艺人员将各电控单元的纸质编码定义表的内容维护到工艺电检程序中去。采用两种模式以便进行印证一致性检查。
3.2 条码式车辆识别子系统
在进行数据初始化操作时需要输入的信息包括:车辆识别码 (VIN) 、防盗系统密码、ODISSEE信息码。图3是电子电气工艺程序中对他们的处理流程图。
其中ODISSEE信息码中包含的信息很多, 如电子电气系统配置情况, 部分店空单元的软件零件号, 全部电控单元的配置参数编码信息等, 这些都是进行ODISSEE数据初始化操作不可缺少的, 总的信息量可达数千字符。为了便于操作, 诊断设备一般都是属于便携性的, 操作者可以携带设备对一定区域内的车辆进行电子电气工艺操作, 对于电子电气返修工序来说, 甚至包含整个返修区域。为了将大量的信息实时传送到设备中, 在实践中可以采用1D (一维) 和2D (二维) 条码系统并用。
在VIN号、防盗密码和电检码上采用1D条码, 因为信息量不大, 完全可以胜任。而对于多达数千字符的ODISSEE信息码则可采用2D条码的方式, 如图4是一个2D条码的简单例子, 其表示的字符是:“#ID11010LD-CC43X2950190300;111CB5A4HAT550A060M0ZRQ1FC;01202;1310420UW10252;01401;046B50;04700;24AMM6;4BBSI;24FRD4;24GCCD;24JCLI;24KCMB;24LAFF;4MAC4;24PESP;24RAAS;24SVMF;24YEPC;24ZEPP;6BBSM;26HBCD;26JALA;6UDIR>020877#”, 可见一个条码可表达数百个字符, 根据订单车辆的复杂情况, 一般用5到6个条码来载录和传输信息。
3.3 在线实时无线数据导入子系统
上述的2D条码系统似乎解决了大量数据向移动式诊断设备的传输问题, 整车企业在车型试生产阶段又可能遇到了新的能力瓶颈问题。由于纸质2D条码的扫描对纸质和扫描枪的要求很高, 加上又要扫描多个2D条码, 再加上2D条码的生成和打印时间, 使得实际操作工时大大超出了要求。
在如何解决信息传输瓶颈问题上可采用无线数据传输的方案。方案实不但节约工时, 还能避免扫描质量不稳定的问题。图5是该设计方案的结构框图。可以采用双网卡的工控机系统, 其一端接到工业网上, 另一端则连接两个无线接入集线器, 同时接两台打印机。ODISSEE便携诊断仪加装了无线网卡。工控机负责信息的发送接收校验、无线通讯网的冲突和优先级的管理等。
ODISSEE诊断仪在为订单车辆做数据初始化时, 首先扫描该车随车卡上的VIN条码, 获取VIN码之后就通过无线网络和交换机发送给工控机, 接着工控机通过公司内部工业网连接到生产排产系统 (SPPV) , 从SPPV系统中取出对应该VIN码的数据初始化数据信息, 然后电子电气数据信息又通过交换机和无线网络传给了ODISSEE诊断仪, 这样诊断设备就获得了数据初始化所需要的数据。ODISSEE数据初始化结束之后, 诊断设备会将结果信息再次通过无线网络和交换机发送给对应的打印机来打印数据初始化结果。这样就完成了整个数据初始化操作。
当ODISSEE数据初始化无线输入系统出现了问题不能正常工作时, 设备将可以进入降级工作模式, 即放弃使用无线传输系统。直接向工控机扫描输入车辆VIN码, 工控机从SPPV系统获取2D条码信息之后, 直接通过打印机将2D条码打印出来。ODISSEE数据初始化时设备直接按顺序逐一扫描打印出来的2D条码获得数据初始化数据。数据初始化结束后将ODISSEE设备与打印机通过RS232串行口直接连接打印数据初始化结果。此降级方案大大加强的整个系统的安全性。
另外方案还设置了数据初始化结果数据库, 以便对该工序的工作状态进行监控和分析, 便于开展电子电气工艺质量的持续改进工作。同时方案还预留了一些数据接口, 为以后的功能扩展打下了很好的基础。
4 结论
整车企业汽车总装电子电气订单生产信息系统的建立, 不但满足了其总装电子电气工艺领域的单件订单化生产的要求, 大大提高了生产效率和生产一次合格率水平, 而且还可以实现产品生产过程逐一记录并可追溯, 同时通过与企业生产系统和售后服务系统的互联形成完整的产品质量管控链条, 保证了企业产品的高质量、多样化且可追溯, 大大提高了其市场竞争力。
摘要：通过对整车电子电气系统总装阶段工业化的特点的分析, 确定了大量总装电子电气订单生产信息对于总装现场生产活动的必要性。设计建立了适应现场需求的汽车总装电子电气订单生产信息系统, 并包含条码式车辆识别和在线实时无线数据导入两个子系统。本系统的建立实施不但满足了总装电子电气工艺领域的单件订单化生产的要求, 大大提高了生产效率和生产一次合格率水平, 而且保证了企业产品的高质量、多样化且可追溯, 大大提高了其市场竞争力。
关键词：汽车总装,电子电气,订单生产,信息系统
参考文献
[1]冯艳双.现场总线的特点及其应用研究[J].科技传播, 2011 (18)
[2]汝刚.Web混合模式下面向订单装配的生产管理系统[J].中国管理信息化, 2011 (17)
[3]饶运清, 李培根, 李淑霞, 朱传军, 张超勇, 金愿华, 张晴.制造执行系统的现状与发展趋势[J].机械科学与技术, 2002 (06)
二次订单设计 篇4
大批量定制正在成为21世纪主流生产模式,它将批量生产和定制生产两种完全不同生产方式有机融合在一起,通过产品结构和制造过程的重组将定制产品的生产转化为批量生产[1,2,3]。根据产品复杂性、用户个性化需求和客户订单分离点(CODP)的不同,大批量定制可以分为:按订单销售(Sale-to-Order,STO)、按订单装配(Assemble-to-Order,ATO)、按订单制造(Make-to-Order,MTO)和按订单设计(Engineering-to-Order,ETO)4种方式[4]。对于不同的定制方式,可以采用不同的开发设计技术[5,6]。ATO产品的特点是只需对现有组件进行装配操作,而不需构造新的组件,因此,由于ATO产品的低成本、短交货期、个性化产品功能愈来愈受到顾客的肯定,目前越来越多的产品开始实施按订单装配的生产方式。实现ATO生产方式的关键技术是产品配置设计方法,它是实现客户个性化产品快速响应定制设计的重要设计手段。因此,分析研究面向ATO产品的配置设计原理与过程对于提高企业以批量生产的低成本、高效益快速满足客户需求、设计个性化产品的能力有着重要的现实意义。
本研究主要探讨按订单装配型定制产品配置设计过程研究。
1 ATO产品配置设计原理
ATO生产方式是一种利用已有库存零部件配置成客户所需定制产品的生产方式。ATO产品是一个序列,具有标准化、模块化的设计,组成产品的零部件均是企业根据市场预测提前生产出来的,只有装配和销售活动是由客户订货驱动的,如计算机和轿车等。ATO产品的配置设计是在现有产品及产品组件的基础上根据客户订单需要,有针对性地选择组合产品组件的设计技术,可以将其看作在已知组件、配置知识、产品结构组成的基础上对符合客户个性化定制需求的产品进行求解的过程。ATO产品配置设计可以描述为:
Define of (Conf_Design_Result)=f(CRequests, R(FRequests, Product_comp),Comp) (1)
式中 CRequests—客户需求;Comp—组件,是指具有一定功能的构件,除了零部件外,还包括电子元件、计算机程序、文档等;R(FRequests, Product_comp)—配置知识,表示如何根据客户的功能需求,在现有的产品结构及零部件组件基础上得到满足其个性化产品的规则,它是产品配置时选择组件的准则,是进行ATO产品配置设计的核心。
由于ATO产品中组件模块化程度较高,组件之间关联性相对其他类型产品简单。同时,ATO产品的配置组件集是一个完全限定集,集合元素不可变。因此,一般采用基于规则的方法来配置按订单装配的产品。基于规则的配置方法的优点在于配置知识的表达直观、自然,其推理过程与设计人员处理产品配置问题的思维类似,因此求解过程比较容易,易于通过推理获得所需定制产品。
大批量定制环境下ATO产品配置设计原理,如图1所示。销售人员在已有产品配置模型基础上,通过与客户的交流,将客户对定制产品的功能需求提取出来,并不断的将其输入到PDM支持下的产品配置系统中,然后利用配置规则根据客户需求选择组件配置出相应的个性化定制产品。对于一些比较复杂的定制产品,配置系统很难做到全自动工作,这时需要设计人员根据评价指标进行评估和修改获取想要的产品实例。这里的产品配置模型是指描述了一个可配置的,包括所有标准组件的模块化产品系统的组成情况,用户可以根据不同客户的要求,从中派生出客户的定制产品实例。对于许多产品配置系统还具有很好的图像显示能力,产品销售人员可以一边与客户交谈,一边向客户展示所配置的产品外形,使得客户对定制产品有更加直观的了解,可以提出更多的具体意见和建议。
2 ATO产品配置设计过程
产品配置设计过程是为了完成确定的设计目标而进行的一系列逻辑相关的设计活动。为了详细研究ATO产品配置设计过程,本研究提出了将其设计过程分为3个阶段和5个域的方法,从而更好的分析研究ATO产品配置设计过程,实现ATO产品定制设计。
2.1 ATO产品配置设计过程的3个阶段
依据ATO产品配置设计原理,根据设计过程中面向对象的不同,从总体上可以将配置设计过程分解成获取客户需求、配置求解和输出配置结果3个阶段。在以PDM为基础的产品配置系统的支持下ATO产品配置设计的3个阶段,如图2所示。
(1) 获取客户需求。销售人员或市场人员通过对话、电话访问、学习型营销和网络技术了解客户需求等,然后通过变量条件、有效性原则等,将客户的技术要求或性能说明等需求转化为配置系统可识别与可推理的表达方式或参数。
(2) 配置求解。产品配置系统利用系统建立的基于规则的决策系统及推理机制,结合ATO产品配置模型对用户输入的定制数据进行运算求解,选择并确定组件及组件之间的配置关系,并保证产品的合理性。同时对组件在产品中的有效性和对客户要求的满足度做出评价。
(3) 输出配置结果。配置系统根据部门的不同,如设计、制造等对产品信息需求的角度不同,输出多种类型的BOM供其使用。同时,将配置结果及配置过程存入数据库以备后用。
2.2 ATO产品配置设计过程的5个域
在ATO产品配置设计过程3阶段的基础上,结合公理化设计理论[7],根据产品配置过程中使用数据的不同,可以将配置设计过程中所有数据信息分成5个域:客户域(Customer domain, CD)、功能需求域(Functional Domain,FD)、设计参数域(Design Parameter Domain,DP)、物理组件域(Physical Component Domain,PD)、评价域(Estimate domain,ED)。这5个域之间在ATO产品配置设计过程中的关系,如图3所示。
(1) 客户域(CD)。客户域是在广泛调研的基础上针对细分市场,根据客户需求和客户特征对潜在客户或已有客户进行分类的客户信息。它描述的是细分的客户群,组成元素是某一类特定客户群。客户域可以表示成如下形式:CD={CD1,CD2,…,CDi,…,CDn},其中,CDi为该产品所面向的某一特定客户群,其中定义了客户群名称、编号、特征以及客户需求等。例如:在计算机配置设计中,设计人员将客户群大致分成以下几类:商用客户群、家庭娱乐客户群、网吧客户群等。
定义客户域最大的作用在于可以根据客户需求来选择需要定制的功能,并快速地寻找所需要的配置模型,有针对性的进行配置。同时在对配置结果进行评价时,根据CDi中定义的客户需求的顺序给各个指标赋予相应的权重。
(2) 功能需求域(FD)。功能需求域是描述客户或销售人员需要何种功能以及需要的功能强度的集合。它的依据主要来源于两个方面:市场调查和对已有产品的分析。功能需求域通常是描述一个产品族全部功能的元素集合,它可以表示成为以下形式:FD={FD1,FD2,…,FDi,…,FDn},其中,FDi描述的是产品的一项独立的子功能,该功能与其他功能无相关性。例如:计算机的功能需求域中常见的有:价格需求、性能需求(包括运算速度、容量)、重量需求、颜色需求、品牌需求等众多需求。
作为产品配置设计的驱动源,定义合理的功能需求是配置设计成功的最基础的条件。功能需求域是为了准确地获取客户需求,并将客户需求通过某种确定性的方式准确地描述出来而建立的。在配置过程中,将模糊性的、多层次的、动态的信息通过以上定义将客户需求完整的描述出来。
(3) 设计参数域(DP)。设计参数域是在进行产品配置设计过程中描述产品所有属性的设计参数的集合。与功能需求元素相互独立不同,设计参数之间往往存在一定关联性,有时甚至是全相关的。例如:在计算机配置中,主要的设计参数有:CPU运算速度、内存容量、硬盘容量、颜色、显存容量等。设计参数的取值一般是设计人员选择组件最重要的依据。设计参数域可以表示成如下形式:DP={DP1,DP2,…,DPi,…,DPn},其中,DPi为某一设计参数,可采用如下形式定义:
Define of(DPi)= {m_name, m_id, , m_units, m_range, m_value}
其中,m_value与功能需求域FD之间存在着密切关系,一般是通过定义函数方法得到具体值,即DPi(m_value)= fi{FD1,FD2,…,FDn},有时往往具体值是非数值形式的。配置之前该值为NULL。
(4) 物理组件域(PD)。物理组件域是定义配置模型中物理组件的集合。物理组件域是产品族最广泛的组件集合,具有明确的指向性。物理组件域可表示成如下形式:PD={PD1,PD2,…,PDi…,PDn},其中PDi为某一组件的定义,本研究中物理组件元素通常以3种形式存在:①以元件的形式存在。它是组成产品结构的最基本的单元,例如机械产品中的零件、软件中的某个类;②以组合件的形式存在。它是由多个产品元件构成,具有某一特定功能的组件,例如汽车上的变速器、软件中的类库;③虚拟组件。它除了名称、编号没有其他内容,没有实际意义,只是为了描述某些组件关系,降低设计复杂性。
(5) 评价域(ED)。评价域是为了评价配置结果的基型而设定的全局性指标集合。它通常由配置产品的成本、采购时间、生产时间、交货期、性能等指标组成。评价域可采用如下形式表示:ED={ED1,ED2,…,EDi,…,EDn},依据配置开始时所选择的客户域中的客户群元素来确定各个指标的权数,然后计算平均的评价权数来评价配置产品的客户需求的满足度。例如:在计算机产品配置中,评价域表示如下:ED={Cost, Time_to_Market},其中,Cost={Cost_evaluate,ed001,Min,*.cost added up ,units=RMB}。该定义表示每次配置结束将配置结果的成本相加,取其中成本最低的作为最终结果。
在给定其他功能需求的情况下,对客户需求进行了求解,理论上配置结果应该是完全满足客户需求的。因此,只需对其他全局性因素做出评价即可,评价过程是通过选定的组件的属性进行运算得到,如上例中叠加成本。
销售人员或设计人员通过与客户的沟通交流获得定制产品功能需求之后,由功能需求向物理组件域映射得到客户定制产品结构组件的关系,如图4所示。
从图中可以看出,从功能需求域到物理组件域是采用间接映射的方式,即先从功能需求域到设计参数域,然后由设计参数域到物理组件域,从而最终获得构成满足客户个性化需求的定制产品的物理组件。
2.3 ATO产品配置设计的域作用机制
ATO产品配置通过域及域与域之间的映射实现了配置设计知识表达和数据传递,为了保证数据传递的畅通性、正确性,必须建立一套机制。下面从整个配置设计流程对域与域之间的相互作用作进一步研究,具体的域作用机制,如图5所示。
(1) 确定客户类型。从整个配置设计流程看,客户域是配置活动的开始。首先确定客户域中客户群元素。选择何种客户群元素取决于当前客户与域内客户群元素的特征匹配情况。如果当前用户特征与某个客户群元素的特征相符,那么客户确定为该客户群元素。例如在仪表配置过程中,目标客户是炼油企业,它的特征与石化行业的特征相符,该客户就被确定成石化客户群元素。
一旦确定了客户群元素,通过映射就确定了功能需求域中功能需求类型(确定何种需求),同时还确定了评价域中各评价指标的权重。这一过程是通过分析目标客户,根据它的应用特点确定需求类型和关注重点,以便配置设计活动有针对性的展开。
(2) 确定客户需求。确定了客户需求的类型后,接下来确定客户对产品功能具体要求(确定需要何种程度需求)。通常工作人员可以通过市场调研、直接拜访等方式获取客户对产品的功能需求(如多大功率、多大的外形等)。
从配置设计过程中数据传递的角度,客户需求开始由数据链从外部输入到内部,并对功能需求进行具体赋值。例如,在计算机配置中,目标客户对键盘颜色提出具体要求。这里需要注意的是:在不能获取全部客户需求时,比如在营销阶段,常得到非完全确定性客户需求,可取功能需求元素的默认值。
(3) 求解设计参数。确定了功能需求种类以及具体功能参数值,就可以开始对设计参数域进行求解。当客户需求为非确定性需求时,选择默认值功能需求值进行赋值求解。这一求解过程将不定方程转化为定方程,将原有不确定性多个解转变成单一正确解。此方法虽可提高运算效率,但必然会减少正确解的个数,求得的设计参数也未必是最佳设计参数解。在非完全确定需求的条件下,通过多次循环,未必获得最佳解,但一定可获得较优解。
(4) 判断规则,选择组件。求解出设计参数之后,对配置规则中的设计参数进行赋值,判断规则的条件真伪,并执行相应的结论。通过匹配设计参数域与配置规则,进行推理判断,根据前提选择结论对物理组件的状态进行赋值。
(5) 获取初次配置结果。然后判断物理组件域中物理组件的状态来获取产品配置组成。如果客户需求是全确定的,这一配置组成是唯一解;更多的情况是客户需求非完全确定,那这一配置解是其中一个正解。后者的情况,产品必须进行再配置,配置过程与前一次类似,唯一的区别是对非确定需求重新赋值(一般取其他默认值),再次求解。
(6) 循环配置,确定较优解。评价域依据评价指标中的方法将配置结果的属性、客户域的权重进行计算,获得评价指标值。多次赋值、多次求解、多次配置、多次评价,最后比较各个配置结果的评价指标值来获取较优的配置结果。由于ATO产品功能、组件相对较为确定,通过功能需求的默认赋值求得最优解的可能性非常高;同时,这一方法又可大大简化配置求解过程,将不定方程转化为多个定方程来处理,具有一定的实用价值。
上述流程可以基本保证域与域之间的数据传递的有效性和准确性。尤其是评价域与功能需求域之间的数据反馈,为求得较优解提供了条件。
3 结束语
产品配置设计是实现大批量定制环境下按订单装配产品的核心支撑技术。本研究在给出ATO产品配置设计概念和基本原理的基础上,提出了将其设计过程分为3个阶段和5个域的方法。通过对ATO产品配置设计过程的分析研究,有利于企业更好的掌握其设计规律,增强配置设计过程的规范性和智能性,提高产品设计速度和设计质量,进而增强企业对市场的快速响应能力,实现满足客户个性化需求的ATO产品定制设计。
参考文献
[1]RONALD L.Mass customization:the next industrial revolu-tion[J].Industrial Management,1995,37(5):18-19.
[2]HALAL W E.The top 10 emerging technologies[J].TheFuturist,2000,34(4):29-38.
[3]GILOVANI D S,DENIS B,FLAVIE S F.Mass customiza-tion:literature review and research directions[J].Interna-tional Journal of Production Economies,2001,72(1):1-13.
[4]祁国宁,顾新建,李仁旺.大批量定制及其模型的研究[J].计算机集成制造系统-CIMS,2000,9(9):776-783.
[5]祁国宁,顾新建,谭建荣,等.大批量定制技术及其应用[M].北京:机械工业出版社,2003.
[6]鲁玉军,祁国宁.基于MC环境的面向订单的产品设计方法研究[J].中国机械工程,2006,17(22):2354-2358.
二次订单设计 篇5
本文的内容首先对i OS平台开发相关技术进行了简要介绍,然后对订单配送路径规划系统进行分析,设计出了整体的技术方案与系统架构,然后对系统功能进行详细实现,包括仓库、订单查询,地图位置显示、路线规划及导航等功能,最后进行结果分析与总结。
1 iOS开发平台介绍
1.1 iOS系统架构
iOS平台应用的开发语言主要有Objective-C和Swift语言,由于swift作为一门新生语言使用人数较少的原因,本系统采用了主流开发语言Objective-C进行编码开发。Objective-C作为ANSI C的超集[4],不仅扩展了面向对象设计的能力,如类、消息、继承,同时它可以调用C的函数,也可以通过C++对象访问方法,具有对C和C++语言的兼容性。
苹果公司最新推出的i OS 10 SDK(Software Development Kit,软件开发工具包)增加了新的API(Application Programming Interface,应用程序编程接口)和服务,能够支持更多新类型的应用程序和功能。目前基于i OS平台开发的应用程序可以扩展到消息、Siri、电话和地图等系统自带服务,拥有了更吸引人的功能。图1为i OS系统架构图:
图中可触摸层主要提供用户交互相关的服务如界面控件、事件管理、通知中心、地图,包含以下框架:UIKit、Notification Center、Map Kit等;媒体层主要提供图像引擎、音频引擎及视频引擎框架;核心服务层为程序提供基础的系统服务如网络访问、浏览器引擎、定位、文件访问、数据库访问等。最底层的核心系统层为上层结构提供了最基础的服务包括操作系统内核服务、本地认证、安全、加速等。
1.2 i OS地图SDK
i OS地图SDK是高德提供的一套基于i OS 6.0.0及以上版本的地图应用程序开发接口,供开发者在i OS应用中加入地图相关的功能[6]。它提供的四种地图模式包括:标准地图、卫星地图、夜景模式地图和导航模式地图。开发者不仅可以利用其地图计算工具实现坐标转换和距离或面积计算,而且可以调用API完成出行路线规划及点标注、折线、面的绘制等工作。这些实现的提前需要注册并认证成为高德开发者,接着为应用申请APIKey,然后将i OS地图SDK配置到应用工程中,这里可以采用手动和自动化两种配置方式。前者的配置过程简单易操作,但更新操作代价大,后者配置过程稍显负杂,但更新很方便。手动配置的方式则需要手动向工程项目中导入MAMap Kit.framework和AMap Search Kit.framework两个包,当框架有更新时需将工程中旧框架删除并添加新框架,其使用稍显麻烦。本系统的实现采用了自动化配置工程的方式,利用第三方库管理工具Cocoa Pods通过命令:pod‘AMap3DMap’,‘~>4.0’和pod‘AMap Search’,‘~>4.0’完成自动导入框架的目的,当框架更新时只需执行pod update即可实现项目中框架的更新。
2 整体方案设计
通常App功能复杂的情况下需要有后台服务器的业务处理支持,本文涉及的路径规划功能需要处理的计算量会随着配送点个数的增长呈指数阶上升,因此需要后台服务器的强大计算能力处理路径规划结果,进而减轻客户端内存使用压力。
本系统整体技术方案的设计综合考虑了移动应用端、服务端(包括应用服务器和提供商服务器)以及数据库服务器三部分所涉及的技术及其简要的功能模块划分,如下图2所示:
其中应用服务端是典型的电商进销存管理系统,移动端LBS应用——易配送App的实现需要在进销存Web系统的表示层、业务逻辑层、数据持久层添加相应的订单配送接口,该接口将服务端经过处理的数据结果封装成XML标准的数据格式通过HTTP协议传输给App。
3 基于i OS的路径规划App设计
3.1 App开发模式
易配送App采用Objective-C开发语言,开发工具为Xcode7.0,主要针对i Phone进行设计的。系统的设计模式采用了MVC范型如图3。由于系统所涉及的内容数据均通过网络请求服务器实时更新获取,故采用了i OS App开发模式中的Native App,以保证有较好的网络环境以及节省的带宽,以便利用充分的设备资源来提供良好的交互体验。
该系统平台中的位置信息主要体现在:位置服务和地图。位置服务是由Core Location框架负责,它将用户的位置及方向信息以Objective-C语言能识别的形式罗列出来[4];地图服务通过应用中集成的高德开发平台提供的MAMap Kit框架负责,利用它可以展示出地图和图钉标注等信息。易配送App的路径规划模块有效地将Core Location框架和MAMap Kit框架结合起来,以实现地图定位、距离测试、路线显示及导航功能。
3.2 重要功能设计及关键技术实现
系统的主界面设计采用了图文结合的布局方式如图4,使用户能够快速便捷的操作系统。对于信息查询类似功能的界面多采用表视图结构,得到了清楚地展示大量内容信息的效果如图5所展示的待配送订单列表。
系统主要的路径规划功能在电子地图的地理信息背景下完成了标注及路线可视化如图6所示,其关键技术的实现如下:
1)初始化地图服务
系统中地图服务的使用首先需要初始化地图控件,这需要在创建MAMap View之前需要先绑定APIKey:[MAMap Services shared Services].api Key=APIKey;和[AMap Search Services sharedServices].api Key=APIKey;接着初始化MAMap View地图控件:_map View=[[MAMap View alloc]init With Frame:self.view.frame];并给系统添加地图视图:[self.view add Subview:_map View];
2)分组待配送订单
因为业务要求需要将待配送订单按各自对应的出货仓库进行分组配送,系统中通过自定义实现分组方法:-(void)group Action:(NSMutable Array*)array;其中参数array中存储着多个配送单对象XJDelivery Order。方法实现中利用可变的集合对象NSMutable Set保存的内容对象不重复的特性,用_warehouse Set记录不同的仓库信息:_warehouse Set=[NSMutable Set set];[array enumerate Objects Using Block:^(XJDelivery Order*_Nonnull order,NSUInteger idx,BOOL*_Nonnull stop){[_warehouse Set add Object:order.warehouse Name];}];同时该方法中利用谓词NSPredicate过滤数组array实现按仓库名称分组:[_warehouse Set enumerate Objects Using Block:^(NSString*_Nonnull warehouse Name,BOOL*_Nonnull stop){NSPredicate*predicate=[NSPredicate predicate With Format:@"warehouse Name=%@",warehouse Name];NSArray*temp Arr=[NSArray array WithArray:[array filtered Array Using Predicate:predicate]];[group Arr add Object:temp Arr];}];
3)添加标注及气泡视图
给地图添加标注需要调用地理编码请求:[self.search AMap Geocode Search:geo];其中对象geo为AMap GeocodeSearch Request类对象且其属性值address不为空,该请求会回调AMap Search Delegate中的方法:-(void)on Geocode SearchDone:(AMap Geocode Search Request*)request response:(AMap Geocode Search Response*)response;其中response对象中包含了经纬度信息并且该方法中调用了添加标注方法:[_map View add Annotation:point An];其中对象point An为MAPoint Annotation类对象。
实现触摸标注弹出气泡的效果需要实现MAMap View Delegate委托中-(MAAnnotation View*)map View:(MAMap View*)map Viewview For Annotaion:(id<MAAnotation>)annotation;和-(void)map View:(MAMap View*)map Viewdid SelectAnnotationView:(MAAnnotation View*)view;方法。
4)路径规划及绘制路线
i OS地图API提供了按参数顺序进行路径规划的方法:[_search AMap Driving Route Search:request];其中request为AMap Driving Route Search Requ-est对象,需要给定request的属性:起点origin、终点destination和沿途点waypoints的值。而对于最优路径的规划只能通过自定义方法:-(void)plan Best Paths With Loaction:(CLLocation Coordinate2D)location way Points:(NSArray*)way Points;该方法中调用了网络请求服务器方法,并能够获取服务器返回的处理结果,其结果中包含了多个经纬度字符串,需要利用方法-(CLLocation Coordinate2D*)coordinates ForString:(NSString*)string coordinate Count:(NSUInteger*)coordinate Count parse Token:(NSString*)token;来解析经纬度,然后系统利用解析得到的经纬度调用[MAPolyline polyline With Coordinates:coordinates count:count]来绘制路线。
5)最优路径算法
本系统的服务端路径规划接口实现中采用了适合解决单回路最短路径问题的算法——最近点插入算法。最近插入法是一种启发式算法,它不仅适用于各种复杂的TSP问题,对于中小规模问题同样适用。图7为算法具体流程。算法的实现是在后台服务端通过java语言实现的,这里就不做详细说明了。
4 系统测评与应用实例
为了对系统的功能及路径优化效果进行测试,采用了如下的实验环境:客户端是所有系统为i OS 7.0及以上i Phone手机,安装App后即可使用;服务端为可安装运行在windows平台下的进销存管理系统;数据库为Oracle数据库安装在Linux数据库服务器上。
本系统中路径规划功能的实现采用了将多个仓库多配送点的路径规划分解为多个单仓库多点配送的思想。下面一系列图示说明了多个单仓库出发到多个配送点的路径规划对比结果。
图8中显示当天需要规划路径的所有点,包括三个仓库和八个客户位置。接下来分别对三个仓库进行出货配送安排,如图9为从总仓库出发的配送路线对比,其中上图为按下单顺序依次配送的路线图,下图为根据与出发仓库距离由近到远的依次配送的路线图,从图中可以明显看出两者各自的路程代价,表1为各仓库配送路径的对比结果。
通过实验测试结果表明,当单次规划的配送数量小于等于6时,本系统的最优路径准确且计算处理很快,几乎网络无延迟。当单次规划的配送数量大于6小于17时,优化结果准确但是处理速度变慢,并且处理响应时间虽配送数量呈现指数阶增长。当单次规划的配送数量大于16时,服务端需通过一定路径优化算法处理大规模计算,但其结果往往是最优解的近似值而非最优路径值。
5 结束语
本文是在i OS系统上基于电子地图的应用开发,基本实现了小规模订单配送的路径规划功能。经过优化的路径的确节省了许多里程,真正意义上为企业提高了效益。但是本系统还存在一些不足之处,如适合处理小规模订单配送路径规划的局限性,系统的可扩展性有待加强。在今后的学习和研究中,将进一步深化和扩展该应用的功能,提供更加丰富的视图信息和交互方式,实现更良好的路径规划体验。
参考文献
[1]WANG Tiejun,WU Kaijun.Study multi-depots vehicle routingbased on improve-ed particle swarm optimization[J].Comput-er Engineering and Applications,2013,49(2):5-8.
[2]马建华,房勇,袁杰.多车场多车型最快完成车辆路径问题的变异蚁群算法[J].系统工程理论与实践,2011(8).
[3]李波,邱红艳.基于双层模糊聚类的多车场车辆路径遗传算法[J].计算机工程与应用,2014(5).
[4]胡杨帆,杨刚,胡颢石.结合LBS和信息推送的博物馆App的设计实现[J].计算机应用与软件,2013,12(30):108-112.
[5]百度百科.手机定位技术[EB/OL].http://baike.baidu.com/link?url=Fd Vs R1e UHO4p Xu-1m Dn Boar4Vvjz DHE03VEw3qj0Zr XNvdq Z4Nj URdz Um75kq8px Ljs ATh N-8Fj Bpzd AWde Yn BVKIc-wng DEQ6Nw R8K9F-Pemfn634Nr VYuo Nj Nb F_le E_sq_lq Jotl5_Zx Ki4Eiy5K.
二次订单设计 篇6
随着人们生活水平的提高,市场对绿色、无污染的高品质鲜活农产品需求增加,将生产指向高价值的鲜活农产品领域也能为农民、农产品加工企业带来更多利益。而要实现鲜活农产品生产环节的规范化、规模化,需要大量资金和技术投入。在农民自有资本不足的情况下,外部金融机构的资金支持成为主要方式。然而,由于农民信用基础薄弱、受自然灾害影响大且缺乏可供抵押的资产,造成其信贷风险大而难以获得银行的支持,严重制约了现代农业的发展。因此,如何结合鲜活农产品供应链的运作特征及需求特征,设计新的融资模式非常必要。
订单融资模式作为一种新的融资模式迅速发展,有效解决了中小企业资金短缺问题。实施订单融资加大了金融机构向农业领域的资金支持,解决了农民生产过程的资金约束问题,同时,农民按照订单进行生产,能避免因生产过量而遭受损失,降低了生产的不确定性。发达国家已经将订单融资作为农业金融支持的主要方式,在借鉴国外经营模式的基础上,我国依据农业发展现状和特色,实施了不同的鲜活农产品供应链订单融资模式。例如:龙江银行实施了以中粮集团为核心的农产品供应链融资模式(关喜华,2011);中国农业银行峨眉山支行开展了“农业银行+龙头企业+专业合作社+农户”的蔬菜价值链融资模式(马九杰,2011);栖霞地区通过对安德利果汁公司的分析探讨苹果价值链的融资模式(王晓甜,2015)。
随着订单融资模式在我国农业中的迅速发展,其运营过程中的问题逐渐暴露。例如,农产品生产过程的天然弱质性使银行面临巨大的自然灾害风险,市场价格的波动性导致订单履约率低。这些问题均降低了银行的贷款意愿,阻碍了订单农业的发展。发达国家针对订单农业发展中的问题采取了一系列措施,例如,建立完备的保险制度转移农产品生产过程的自然风险(Glauber,2002);利用期货市场的套期保值和价格发现功能,有效规避订单农业的市场风险,提高合约的履约率(Zant W.,2001)。国外学者已经对农业保险和农产品期货市场作用进行过充分研究,但对两者如何提高订单合约的信用度、影响金融机构贷款意愿、支持订单农业发展的研究却非常缺乏,我国订单融资中的问题并未得到根本解决。
近年来,我国金融市场成熟发展,为鲜活农产品供应链订单融资模式创新营造了良好的环境。鉴于此,本文将借鉴发达国家发展订单农业的经验,以龙海市订单农业为例,结合当地的农业特点以及鲜活农产品供应链运营状况,构建现代化鲜活农产品供应链信息体系,创新性地引入农业保险和期货市场提高订单合约的信用度,以订单合约和农业保单共同作为抵押物向银行申请贷款。
二、鲜活农产品供应链营运流程及核心企业的信用扩散
1. 鲜活农产品供应链营运流程。
鲜活农产品供应链是指从生产材料的购买、生产、农产品的收购、包装加工、保鲜流通、市场销售直至零售终端的整个流程,将物流、资金流、信息流高度整合。鲜活农产品供应链包括两种形式:生产者驱动模式和购买者驱动模式。
我国鲜活农产品供应链多是以加工企业为购买者的驱动模式,即订单农业。如图1所示,即生产前由加工企业与农村合作组织签订订单合约,承诺以一定价格收购农产品,同时对农产品的数量、质量以及交货时间进行严格限定。到生产季节时,农村合作组织根据订单组织农民采购原材料进行生产,并提供技术指导。生产结束到销售季节时,加工企业按照订单的规定收购农民生产的所有农产品,并对收购的农产品进行加工如清洗、包装等处理后运往零售市场,按一定的价格进行销售,至此完成一个农产品的生产、销售周期。
2. 核心企业的信用扩散。
在鲜活农产品供应链金融中,选取农产品加工企业为核心企业,如图2所示,加工企业规模大、实力强,且处于流通体系的中心位置,是资金流、物流、信息流的集散中心,与农村合作组织的贸易行为将其信用进行扩散,使得农民和农村合作组织的信用等级提高到与核心企业相同的水平。核心企业的信用扩散具体包括以下四个层面:1首先,银行与发出订单的核心企业协商开展基于订单的融资服务,得到核心企业的确认,同时核心企业向银行推荐熟悉的农村合作组织。2农村合作组织获得核心企业的订单后,将订单及相关材料呈递给银行申请贷款,银行在核心企业的协助下审核订单的有效性、可实现性。3银行确认发放贷款后,与核心企业、农村合作组织签订合约。合约将确定授信额度、贷款期限,并将授信偿还与核心企业进行责任捆绑。4生产完成交付订单后,核心企业直接将货款打入贷款银行。以核心企业的预期货款作为还款来源,确保了资金的可获得性。
因此,在鲜活农产品供应链订单融资模式下,银行等金融机构打破传统的信用评级模式,转而考察订单的真实性和可实现性、核心企业的规模和信誉度以及所在供应链的运营状况。
三、现有订单融资模式存在的问题
订单融资模式在鲜活农产品供应链中的应用取得了一定的成效,缓解了生产环节资金不足的问题。但通过实践发现,我国鲜活农产品订单融资模式依然存在一系列问题:
1. 鲜活农产品供应链各环节联系不紧密,信息流通滞后,具有较高的交易成本。
首先,我国鲜活农产品供应链参与成员各自为政、缺乏整合,成员之间大多呈现产销分离状态,合作化水平低。其次,国内的鲜活农产品供应链总体信息化程度低,从生产、加工到销售各流通环节信息滞后、失真问题严重,缺乏有效的电子商务平台。
2. 鲜活农产品生产过程存在风险。
首先,市场上对绿色、无污染的高品质鲜活农产品需求增加,农民传统的粗放式生产方式使产品的质量、数量不达标。其次,农产品生产过程具有天然弱质性,受自然条件的影响,面临巨大的自然灾害风险。
3. 鲜活农产品供应链销售环节存在违约行为。
首先,农民有逐利心态,农产品完成生产时,市场上若出现更高的价格其便有可能违约。其次,农产品加工企业也有可能是违约主体,不少企业未能充分预测到市场前景,在农产品价格大跌时若仍以合同定价收购,必然亏损,从而导致农产品加工企业选择违约。由此可以看出,农业订单普遍失范,缺乏有效的约束机制。
综上可见,目前订单融资模式组织化程度低,存在生产风险、市场价格波动风险等,严重影响了订单合约的信用度,使得农民凭借订单合约向银行借贷依然十分困难,制约了我国现代农业的发展。为此,根据我国订单农业的运作特征与资金需求,设计新的融资模式以提高订单合约信用度非常必要。
四、鲜活农产品供应链订单融资模式设计——以龙海市订单农业为例
鲜活农产品供应链金融创新模式的设计核心是构建供应链信息管理体系,选取现代化的核心企业,借助农业保险与期货市场的金融保障功能提高订单合约的信用度,形成组织化程度高、信息流通迅速的订单融资模式。近年来,龙海市积极开展订单农业,形成了集生产、加工包装、销售于一体的鲜活农产品供应链,为订单融资模式的实施建立了基础。下面选取龙海市的明德食品加工有限公司为核心企业,展开鲜活农产品供应链订单融资模式的设计。其融资基本构架如图3所示。
供应链上除了主要参与主体农业银行、农民、农村合作组织、加工企业以及下游的经销商,还增加了农业保险和再保险机构、期货市场、政府财政补贴环节,缓解了农产品市场风险、自然风险。
1. 鲜活农产品供应链的主要参与主体。
(1)核心企业。作为核心企业的龙海市明德食品加工有限公司,负责农产品的生产指导、果蔬加工、运输包装和销售。公司创建于2009年3月,注册资本为1200万元,拥有占地面积达7600平方米的工厂,采用国内最先进的生产流水线及流态化单体速冻机,年产量可达8000吨以上。其在鲜活农产品供应链中的主要职能有:对鲜活农产品生产的全过程进行无偿技术指导,从而保证订购产品的质量和数量;提供鲜活农产品市场价格信息,与农村合作组织签订订单合约,同时向银行推荐长期合作的农村合作组织;拥有专业的销售和后勤服务团队、长期合作的物流和快递公司,使得农产品的运输过程更安全迅速;对收购的鲜活农产品质量进行把关,并进行加工包装,负责产品销售和渠道扩展。
(2)农村合作组织。分散农户参与市场竞争的弱质性催生了农村合作组织,它能代表小农与核心企业谈判,签订契约,根据核心企业的订单组织小农有秩序地开展生产,并且提供技术指导,同时向银行申请贷款。农村合作组织大大提升了鲜活农产品生产者在供应链中的地位,为其争取到更大利益,同时也降低了贷款交易成本,优化了鲜活农产品供应链。
(3)农民,鲜活农产品生产者,资金需求主体。大部分农民因生产规模小、生产风险大且缺乏可供抵押的资产而难以获得银行贷款。农民参与农村合作组织后,自愿签订“联保协议”,以3~5户农民为单位成立联保小组,小组成员互相对其他成员贷款承担连带担保责任。当农民获得银行贷款时,需要缴纳10%的贷款保证金,若农民发生违约行为,在冻结贷款保证金的同时向小组成员追索剩余款项,保证了该笔贷款资金的安全性。
(4)农业银行,为鲜活农产品供应链生产环节提供金融支持。农业银行对农村合作组织提交的农业订单进行审核,通过后银行将根据订单大小为农村合作组织发放贷款,同时委托核心企业监督生产过程的顺利进行。农业银行为鲜活农产品供应链提供金融支持的同时也负责与政府、农村合作组织、核心企业以及物流企业的沟通交流,对资金流进行监管控制,实施有效的风险控制措施。
2. 鲜活农产品供应链新加入的环节。
在传统的“银行+核心加工企业+合作组织+农户”的鲜活农产品供应链中,我们加入了新的环节来防范市场风险、生产风险、违约风险,并构建信息化体系,使得从农户到零售终端各流通环节农产品信息能够迅速采集、整理和发布。
(1)增加了农产品期货市场。核心企业利用期货市场的套期保值和价格发现功能,保证了鲜活农产品供应链的稳定运行。鲜活农产品生产前,核心企业与农村合作组织签订收购订单,从而将农产品价格波动风险转移给核心加工企业,供应链的封闭性导致订单履约率低。因此,核心企业利用期货市场的套期保值功能,通过购买相应的农产品期货转移农产品市场价格波动风险,提前锁定订单利润,有效提高了订单合约的信用度,增加了银行的贷款意愿。同时,核心企业将利用期货市场的价格发现功能,制定订单合约价格,农村合作组织将根据期货市场的农产品价格信息预估未来价格走势,指导农民的生产决策,避免生产过程的盲目性,保障了核心企业和农民生产的利润。
(2)增加了农业保险机构与再保险机构。农业保险是专为生产者在从事鲜活农产品生产过程中遭受的自然灾害、意外事故、疫病等造成经济损失提供保障的一种政策性保险。农业保险有效降低了生产过程中自然灾害、意外事故、疫病等造成的经济损失,保障了农民从事农业生产的收入,提高了订单合约的信用度。农业再保险是指农业保险公司承担的风险过大威胁到其自身经营稳定时,通过订立再保险合同,将其承担的风险责任在其他保险公司之间转移、分散。2014年11月21日,中国农业再保险共同体成立,填补了农业保险大灾风险分散体系行业层面空白,为农业再保险业务的展开奠定了基础。
(3)政策支持和财政补贴。政策支持方面,在加强农村基础设施建设基础上引进先进的生产技术和科学的经营管理方法,实现了现代化农业生产。财政补贴方面,发展了政策性银行并引导其提供低息贷款,差额部分由政府提供利息补贴;委托保险公司设计农业保险,提供保费补贴,并成立保险共同体,将单个保险公司承担的风险在体系内转移、分散。
(4)随着互联网金融的发展,在参与主体越来越多、环节越来越复杂的鲜活农产品供应链中构建信息化体系非常有必要。信息化体系构建实现了信息流、物流、资金流的透明化和集成化。1构建高效、协同的信息共享模式。借助计算机信息技术、电子商务技术将鲜活农产品生产者、加工企业以及零售市场的价格信息、需求信息等进行整合。信息进行处理后一方面用来指导农民和农村合作组织的生产活动,另一方面加工企业可以利用信息决定订单量和订单价格,并预测未来农产品的价格走势以及需求量,以合理安排生产加工。2构建电子商务平台,使互联网技术覆盖鲜活农产品供应链生产运营的全过程,在提高各环节工作效率的同时降低了采购、交易以及贷款成本,实现了供应链资金流、物流、信息流的透明化和可视化,保障了交易过程的安全进行。3构建规范的运营模式,借助计算机信息技术将鲜活农产品供应链各操作环节进行编程,通过预先设定好的软件进行一对多、多对多的管理,实现管理体系组织结构的扁平化、智能化操作、程序化决策,使鲜活农产品供应链各环节联系更紧密。
3. 鲜活农产品供应链订单融资模式业务流程。
龙海市订单农业经过多年发展,核心企业明德食品加工有限公司与农村合作组织、农户建立了长期、信任、稳定的合作关系,为鲜活农产品供应链订单融资模式的开展创造了条件,形成了“银行+核心加工企业+合作组织+农户+期货市场+农业保险+政府”的多环节多组织的融资模式。
我们将订单融资业务划分为三个阶段,即贷款发放阶段、购买原材料生产阶段以及贷款收回阶段。
(1)贷款发放阶段。首先,银行与发出订单的核心企业协商展开基于订单的融资服务,得到核心企业的确认与支持,同时核心企业向银行推荐长期合作的农村合作组织。农村合作组织在获得核心企业订单时,购买农业保险和再保险防范生产过程自然风险,然后将订单及农业保单呈递给银行申请贷款,银行与核心企业合作审核订单和农业保单的真实性以及农村合作组织的生产能力后,银行将与核心企业、农村合作组织签订贷款合约,合约将考虑订单产品大小以及生产特点,确定授信额度、贷款期限。同时建立封闭账户,根据合约规定的授信额度拨付资金,其贷款为低息贷款,差额部分由政府提供利息补贴。
(2)购买原材料生产阶段。农村合作组织在封闭账户内可以使用贷款进行针对该订单的原材料采购,组织农民进行生产。核心企业为合作组织成员农户提供优良的农产品种子、农药化肥,无偿提供技术指导,同时银行将派出专员对生产过程进行中期检查。
(3)贷款收回阶段。农村合作组织组织农户生产完成后,核心企业将派出物流配送人员收购农产品,并直接将货款打入银行为农村合作组织贷款时开立的专项账户;贷款银行收到货款后,扣除贷款本息,剩余款项解冻,农村合作组织可以自由支配。这笔基于核心企业的订单融资业务结束。
4. 订单融资模式风险控制。
从贷款的发放、订单的实施到货款的收回,需要经历一个相当复杂的过程,中途可能会遇到各种问题,为了保证银行贷款顺利收回,我们将从订单融资业务的三个阶段进行风险控制。
(1)发放贷款阶段,强化封闭式账户管理是该环节重要的风险控制措施。为农村合作组织在融资银行开立专项账户,严格遵守和执行“双签”制度,即要有农村合作组织和银行双方的签字才能使用贷款,一般情况下,银行会要求款项支付对象即原材料供应商也在本行开立账户,以保证该笔贷款在银行可监管范围内流转,防止资金用于其他场合。这种做法大大提高了银行对订单生产过程信息真实性的掌握程度,进而提高了贷款资金的安全并减少了贷款风险。
(2)购买原材料生产阶段,可能存在产品的质量、数量不达标问题以及较高的自然灾害风险。农村合作组织在接到核心企业的订单时,将购买农业保险和再保险来防范自然灾害风险。核心企业预期支付的货款为还款来源,对农产品生产具有担保责任,因此有动力为合作组织成员农户提供优良的农产品种子、农药化肥,无偿提供技术指导,同时贷款银行也将派出专员定期考察鲜活农产品生产情况,以保证产品的高质量、高效率生产。
(3)贷款收回阶段,存在两种违约行为,即农村合作组织(农民)的违约和下游加工企业的违约。当农民不愿意按照合约交货时,农村联保小组承担连带担保责任,银行将冻结联保小组缴纳的保证金以及订单涉及的物流和资金流,并向联保小组成员追索其余货款;当下游核心企业不履行收购农产品的合约时,银行首先采取措施迫使企业履行合约,否则将处置订单产品,如果订单产品无法弥补贷款,银行将有权追索核心企业的责任,并将核心企业的违约行为记录到诚信档案中。
五、总结与展望
随着订单农业的迅速发展,生产环节的资金需求增加,而现有的订单融资模式面临自然风险、市场价格波动风险等,没有从根本上解决鲜活农产品生产者(农民)的融资需求。为此,本文在传统的“银行+核心加工企业+合作组织+农户”的订单融资模式中,引入农业保险和期货市场,借助其金融保障功能保证订单融资有效运营,并以订单合约和农业保单共同作为抵押物,向银行申请贷款,很大程度上提高了银行的贷款意愿,彻底解决了农业生产中的融资难问题。鲜活农产品供应链订单融资模式在解决农民融资问题的同时能为核心企业稳定高质量的货源,为农业银行扩展了信贷范围,实现了多方甚至三方共赢。
但是,目前我国农业企业、农户对期货的认识不足,未能充分意识到期货市场对订单融资模式的积极作用。农业保险覆盖面窄、保险赔付水平低抑制了农民参保的积极性。因此,想要实现订单融资模式的顺利发展,需要政府构建良好的期货市场,加大对农业保险的扶持力度,同时增强农民、农业企业运用金融工具的意识。
参考文献
马九杰,张永升,佘春来.基于订单农业发展的农业价值链金融创新策略与案例分析[J].农村金融研究,2011(7).
王晓甜.我国苹果产业价值链融资研究[D].合肥:安徽财经大学,2015.
二次订单设计 篇7
关键词：订单系统,J2EE轻型架构,设计模式
0.引言
随着信息化的高速发展, 电子商务的应用已经得到普及, 在网络上与客户的交互情况、客户的满意程度决定了客户对公司的信任度, 并影响公司未来的业务发展。近年来电子商务系统所采用的技术正在逐步、转向J2EE轻型架构。J2EE轻型架构是一个多层体系结构, 包括表现层、业务逻辑层和数据持久层, 表现层运用Struts、JSF等MVC框架, 业务逻辑层采用Spring框架, 数据持久层采用Hibernate。
1. J2EE轻型架构
在WEB应用的初期, SUN公司就提出了系统的技术开发蓝图, 并定义了WEB应用的两种模型[1], 即熟知的模型1和模型2。模型2实际上就是MVC模式, 图1是模型2体系结构。模型2中的事务逻辑和显示逻辑是相互独立的, 独立性确保了代码的重用
MVC是模型 (Model) 、视图 (View) 和控制Controller) 的缩写。Model层实现系统业务逻辑, View层用于与用户的交互, Controller层是Model与View之间沟通的桥梁, 它可以分派用户的请求并选择恰当的视图来显示, 同时它也可以解释用户的输入, 并将它们映射为模型层可以执行的操作。MVC是帮助控制变化的一种设计模式, 它减弱了业务逻辑接口和数据接口之间的耦合[2]。
1.1 Struts
Struts是一个基于MVC模式的开源应用架构。Struts是由一组相互协作的类、Servlet和JSP标记组成, 它们组成一个可重用的MVC2设计模式。Struts利用taglib获得可重用代码和抽象Java代码, 利用Action Servlet配合Struts-config.xml实现对整个系统导航, 增强开发人员对系统的整体把握, 提高系统的可维护性和可扩展性, 大大提高Web应用的开发速度。图2是Struts实现的MVC框架[2,3]。
1.2 Spring
Spring是一个开源的应用框架, Spring提供了管理业务对象的一致方法, 能够管理和维护轻型架构中各层之间的衔接关系。Spring框架基于Java Bean属性的Io C容器, 它可以在很多应用层面发挥作用。Spring包含许多功能和特性, 包括数据访问抽象, 提高了效率, 减少了错误, 并被很好地组织在Spring AOP、Spring ORM、Spring Web、Spring DAO、Spring Context、Spring Web MVC、Spring Core七个模块中。Spring支持不绑定到特定J2EE服务的可重用业务和数据访问对象对象可以在不同J2EE环境 (Web或EJB) 、独立应用程序、测试环境之间重用。图3是Spring的应用框架图。
Spring提供了"web应用上下文"概念, 将控制反转机制Io C (Inversion of Control) 容器无缝结合到web环境中[4], 借助面向切面编程AOP (Aspect-Oriented Programming) 和Io C, 轻量级容器能够最大程度地降低代码对于专用接口的依赖性, 以轻型和可移植的方式实现业务对象。对Io C机制来说, 不是组件来控制它所依赖的外部设施, 而是由外部的框架来控制这些组件所需要的功能设施, 这种反转可以确保外部框架以"透明"的方式来提供功能。Io C机制使用三种不同的方式提供框架的服务和组件之间的"解藕"[5]。
(1) 接口注入 (Interface Injection) :多数J2EE使用该方式, 保证自己编写的组件实现并遵循一系列接口, 同时配置对应的元数据, 这样框架就能正确管理它们
(2) 标准SET方法注入 (Setter Injection) :该方式需要一个外部配置文件定义编写的组件之间的关系及如何执行。Spring采用了该Io C方式, 它的配置数据在springconfig.xml文件中。
(3) 构造器注入 (Constructor Injection) :使用这种方式, 编写的组件需要在框架中登记, 包括创建组件所需要的参数 (业务逻辑类的构造器所需要的参数) , 这样框架就可以创建你编写组件的实例, 并且为该实例提供所需要的特定功能设施。
在组件开发和企业应用中, Io C机制正变得越来越流行, Spring框架正是架构在Io C机制的基础上, Io C机制保证Spring将组件所需要的轻量级功能设施注入到组件中。Spring使用Io C机制的配置文件springconfig.xml将切面应用到自己开发的业务模块中, springconfig.xml配置文件在运行时期通知Spring框架, 注入业务模块所需要的功能设施, Spring用这种方式来提供轻量级的AOP功能。
1.3 Hibernate
Hibernate是一个开放源代码的对象关系映射框架O/R Mapping, 用来把对象模型表示的对象映射到基于SQL的关系模型的数据结构中去[6]。它对JDBC进行了轻量级的对象封装。Hibernate管理Java类到数据库表的映射 (包括Java数据类型到SQL数据类型的映射) , 提供数据查询和获取数据的方法, 减少SQL和JDBC处理数据的时间。
Hibernate用于Java的中间层应用, 实现面向对象的业务模型和商业逻辑的应用, Hibernate可以应用在任何使用JDBC的场合, 包括Java的客户端、Servlet/JSP的Web应用, Hibernate可以在应用EJB的J2EE架构中取代CMP, 完成数据持久化的重任。Hibernate通过配置文件和映射文件 (一般为.hbm.xml为后缀) 完成对象和关系模型之间的映射, 实现面向对象的方式操纵数据库。
2. ZMZ订单系统分析
根据公司提出的业务需求, 对系统功能和数据库分别进行分析设计, 系统采用原型开发方法。在系统分析过程中, 和公司的相关人员分析系统的各种需求, 确定静态页面, 审核功能和效果是否满足需求, 避免设计和编写代码后, 出现功能不能满足公司实际要求的问题。在系统设计和实现所采用的架构方面, 采用J2EE轻型架构, 并考虑轻型架构的实际应用和实现技术[5,7]。ZMZ订单系统采用图4的架构模式。
经过系统分析, 订单系统的静态页面主要包括:订单列表页面, 创建订单页面, 创建订单明细页面, 查看订单明细页面, 分配接单人页面, 修改付款方式页面, 查看客户初始要求页面, 上传画家作品页面, 作品效果预览页面, 客人查看作品页面, 查看客人修改要求页面等。
在深刻理解ZMZ公司的需求和ZMZ订单系统的业务流程后, 将系统设计为8个Java包:
(1) ch.jmu.dao:采用J2EE核心模式的DAO模式, 衔接中间层和集成层, 减少耦合度, 采用这种模式, 中间层无须考虑底层与数据库的交互是用那种技术实现, 例如ORM或JDBC。
(2) ch.jmu.hibernate:采用Hibernate技术对DAO接口的具体实现, 包括数据库的实际操作。
(3) ch.jmu.model:描述了整个系统模型及其实现。
(4) ch.jmu.service:为业务逻辑提供统一接口, 上层只要调用相应接口方法, 无须考虑实现方式, 降低耦合, 增加灵活度。
(5) ch.jmu.service.impl:描述了中间层及其具体实现。
(6) ch.jmu.struts.action:它是Struts的控制层, 主要用来控制请求和转发工作。
(7) ch.jmu.util:这是一个工具包, 主要是系统中通用的一些类和方法。
(8) ch.jmu.vo:这个包负责各层之间的数据传输。
3. ZMZ订单系统设计
3.1 系统模块设计
(1) 订单模块
管理员根据不同的输入参数, 创建各种类型的订单, 上传油画照片模型。在需求中, 照片模型的分辨率通常都很高, 大小一般在800-900k B左右, 为了增加系统的浏览速度, 必须将上传好的照片模型分割成100X80的小图。
管理员创建订单页面, 输入客户名和数量等信息, 并提交请求。系统在收到请求后, 根据请求中的数量, 确定要生成的订单明细, 同时, 管理员填写其他相应的信息, 并通过本地系统, 上传一张客人所要求的油画照片, 经确认后提交订单, 系统根据请求参数, 转发到相应的action中。action收集请求参数并将它们包装成Order VO对象, 传输给业务逻辑层, 业务逻辑层根据OrderVO对象将其转换成相应的Order业务对象和Picture业务对象, 调用创建订单的业务方法将这些信息持久化到数据库中。
系统提供了统一的控制层访问接口service, 控制层只需调用service接口方法就能实现相应的功能, 设计人员无须考虑service接口是如何实现的, 也就是说, 对于控制层除了与service接口交互外, 其他是透明的。
(2) 定时提醒模块
系统根据订单的状态给管理员自动发送提醒消息, 及时处理相应订单。主要发送如下类型的消息:
·订单成功创建后, 发送"订单创建完成, 请尽快为订单分配接单人"。
·作品分配接单人后, 发送"XXX (订单ID) 订单已经为作品XXX (作品ID) 分配接单人, 已分配作品为X (根据作品的分配情况确定) 张, 已完成的作品为X (根据作品的完成状态确定) 张"。
·离交付画的前一天, 发送"XXX (订单ID) 订单明天就要到期了, 请确认订单现在的完成情况"。
根据公司需求, 在订单创建后, 若没有分配接单人, 每天发送一条提醒消息;若订单分配了接单人以后, 离交付油画日期的一半时间发送一条消息。
为实现定时提醒功能, 系统分配一个线程对订单进行监听, 由于持续监听将降低系统的性能, 因此, 在每天晚上11时进行订单监听, 监听时将遍历每张订单, 如果系统当时的时间已经超过了订单的完成时间, 不做任何处理;如果订单还没有分配接单人, 发送一条消息给管理员;当管理员为订单分配了接单人后, 系统将根据订单的创建时间和规定的完成时间进行相应的计算, 并根据计算结果发送消息。
(3) 状态控制
在管理员对订单操作的过程中, 状态控制是非常重要的一个环节, 状态的变化控制着流程的改变, 每一步操作都会使得订单状态或者作品状态发生变化, 系统根据不同的状态对订单及作品执行不同的操作。对于一幅作品来说, 能够进行的操作只有"分配接单人", 此时, 管理员寻找接单的画家, 通过"分配接单人"操作给画家分配作品, 作品状态变为"已发稿"。
每幅作品发稿后, 必须等待画家将画好的作品发给管理员, 收到作品后才能执行后续操作。系统规定发稿3天后才能执行"完成操作", 管理员通过"完成操作"将作品的状态变为"已完成", 并允许上传画家作品, 作品上传后, 系统生成预览页面, 管理员审核上传作品的效果, 若上传作品错误或不满意, 可以要求重新上传, 确认后, 系统把自动生成的网址页面以邮件方式发送给客人, 作品状态变为"等待确认", 此时, 管理员的工作告一段落。客人收到邮件后, 打开网址页面查看作品是否符合自己的要求, 管理员根据客人提交的结果, 作品将变成"已确认"或者"需要修改"状态, 已经确认后的作品真正的完成了一个业务流程, 剩下的工作就是将作品寄给客人, 如果需要修改, 管理员根据客人的修改意见, 通知画家进行修改, 并重复上述操作流程, 直到客户满意为止。
状态的改变主要是更新数据库Product表的P_STATUS, 页面根据从数据库中读出来的状态字段决定进行什么样的功能。对于有时间限制的操作, 应结合作品的状态和当前时间的计算结果来决定相应的处理。
(4) 综合查询
管理员可以查看订单和作品的各种信息, 例如, 客人的初始要求、客人要求的修改意见、作品的大图和局部图等, 管理员只有掌握了订单的各种状况, 才能做出合适的处理, 满足客户的需求。
查询功能, 需要Hibernate的映射机制, 将数据库的记录包装成业务对象, 然后转换成传输对象在各个层之间传输, 例如, 当需要查看客人的初始要求时, 应先根据订单导航到某个作品, 然后将相应的信息在页面上显示即可。查看客人反馈消息等也是采用同一个机制。
3.2 数据库优化技术
系统运行平台是Window 2003 Server英文版, 应用服务器为Tomcat 4.1.3, 数据库使用My SQL 4.0.13。在数据库设计优化方面, 我们除了考虑常规的数据库设计规范外, 系统采用了连接池技术[8], 由于传统的JDBC独立连接, 每次有一个用户请求的时候, 都要和数据库建立一个连接, 操作结束后又要马上断开连接, 数据库每次配置连接都要将Connection对象加载到内存中, 再验证用户名和密码, 在大量的用户并发访问的时候, 必定影响系统的性能和速度, 所以, 为了提高系统的性能, 使用连接池技术来保存应用程序与数据库之间的连接, 程序访问数据库时, 只需从连接池中取出空闲状态的数据库连接, 当程序访问数据库结束再将数据库连接放回连接池。
3.3 系统主要配置
(1) Spring框架配置
系统采用Spring框架配置各种资源, 首先在WEB应用的WEB-INF文件夹下建立Spring配置文件application Context.xml, 其他任何资源都放在<bean></bean>标签中。数据源配置如下:
采用统一配置文件来管理资源, 大大提高了系统的灵活性和可扩展性。这里使用了DBCP的开源连接池技术和My SQL的驱动[9]。如果将来为了更换别的连接池技术或者是数据库, 只需在配置文件里进行更改即可, 不用重新编译代码。
(2) 在Tomcat中启动Spring框架
应用Tomcat服务器时, 对于每个Web应用都会在WEB-INF文件夹下存在一个web.xml文件, 在这个文件的<listener></listener>标签对中做如下配置:
这样在Tomcate服务器启动的时候就自动加载WEB-INF文件夹下的application Context.xml文件, Spring容器通过这个文件启动并执行相应的初始化工作。
(3) 配置Hibernate和Spring的连接
通过配置*.hbm.xml文件, 就能够完成数据库和对象之间的映射。Spring作为一个Io C容器, 本身对Hibernate等提供了良好的支持, 在Spring中使用Hibernate, 只需要如下配置文件。
在初始化的时候, Spring通过Io C, 可以将已经配置好的数据源分配给Hibernate的Session Factory, 这样就不用Hibernate自己创建数据源, 这一点也充分体现出了Io C容器的特点和高度的可接插性。
4. 小结
与正统的J2EE采用的EJB和Web Services架构相比, J2EE轻型架构技术解决方案最大程度地降低了代码对专用接口的依赖, 它采用Struts框架、Spring框架和Hibernate实现了MVC模式, 轻型架构同样实现了事务处理、分布式对象管理和Web请求三大功能。ZMZ订单管理系统采用了J2EE轻型架构技术, 较好地实现了系统的各项功能。
参考文献
[1].阎宏.Java与模式[M].北京:电子工业出版社, 2005.
[2].James Holmes.Struts:The Complete Reference[M].The Mc-Graw-Hill Companies, 2004.
[3].林琴, 谭骏珊.基于Struts框架的WEB报表展示的设计与实现[J].计算机系统应用, 2006 (1.1) :27-30.
[4].孙卫琴.精通Hibernate:Java对象持久化技术详解[M].北京:电子工业出版社, 2005.
[5].Rod Johnson, Juergen Hoeller.Expert one-on-one J2EE Development without EJB中文版[M].北京:电子工业出版社, 2005.
[6].夏昕, 曹晓钢, 唐勇.深入浅出Hibernate[M].北京:电子工业出版社, 2005.
[7].Deepak Alur, John Crupi.J2EE核心模式[M].刘天北等译.北京:机械工业出版社, 2005.
[8].Vikram Vaswani.MySQL完全手册[M].徐小青, 路晓村等译.北京:电子工业出版社, 2004.