第二章需求分析与系统设计7000-2

第二章需求分析与系统设计 本章介绍系统设计目标、需求分析，并在此基础上设计了系统总体结构和系统工作流程。 2.1 系统设计目标 系统主要用于对各个工厂所需要的物流进行计算，从而得到一段时间内所要求的物料的需求量。 我们将系统分割为几个功能独立的模块：系统管理模块，基础数据维护模块，主要功能模块，物料 工具模块。由系统管理模块来设置系统的配置信息及规则，由基础数据维护模块来设置生产材料供需清单， 由主要功能模块来对已有的清单根据设置的规则计算网络需求及日常回顾需求，由物料工具模块来计算产 品、物料及物料组的需求量。 系统管理模块的作用是对系统的规则及配置信息的管理。由于规则引擎是灵活的可变的，因此需要 在运行前先将计算的规则先配置好。运算中还会有许多按照用户所要求的一些条件，系统管理模块也将把 这类条件以配置信息的形式提供给用户选择。除此之外，在许多表单中还会有一些共用的数据，这类数据 可能会因为管理方式的改变而改变，例如公司组织方式等等，这些也将作为系统数据的一部分而保存，以 方便基础数据中的表单使用。当然，这么多的选择应该提供一个全面查阅的功能，方便用户查看。 基础数据维护模块的主要作用是根据生产计划，将计划中所需要的各种物料做成基础表单存放。表 单要方便修改并且要能根据生产中可能的各种情况进行调整。因此，这个模块就需要有新产品发布、需求 调整、物流计划发布、物流计划查询、替代部件时间物料单、临时物料单、物料缓冲、交期风险、托运补 给方式、物料异常用法等多个功能。这些数据都会保存在数据库中，以便计算时使用。 主要功能模块的作用是根据已有的基础数据和确定的规则来计算最合适的物流计划。客户要求除了 真正的计算之外，还要提供一个模拟整个计算过程的功能。所以，该模块应该提供有数据检测功能、运行 状态查询功能、网络需求计算、日常回顾计算及相应的模拟计算功能。在计算完成之后，得出的结果将保 存到数据库。 物料工具模块是客户的扩展需求，该模块的作用是用规则引擎计算出物料需求情况，并且提供给用 户根据不同的角度去查询结果的功能。 2.2 系统需求分析 需求分析是在于要弄清用户对应用系统的确切要求，针对其中的数据、工作流程、功能需求作出分 析，征求客户的意见。因为要设计一个有效的应用系统，必须永系统工程的观点来考虑问题。在系统分析 阶段，设计者和用户双方要密切合作，对信息格式、处理界面和处理要求达成一致。 根据以上的分析，本系统主要的结构如图2-1所示： 2.2.1 零部件数据的导入 用户需要将零部件的信息导入到数据库中。奇美公司原来的大量的零部件数据都有用 Excel 来保存 和管理，基础的零件数据可以直接将 Excel 中的数据导入到数据库中。 2.2.2 系统管理模块 由于系统在计算过程中会需要有许多的规则及配置条件，企业的组织结构方式以及一些零件的更替， 这些都需要有专门的输入组件将信息输入。 a）用户管理(User Management) MCS 系统会有多个用户，而不同用户所使用的许多配置是不同的，这里可以对用户的数据进行管理， 以方便用户的使用。 b）模型配置(Modeling Configuration) 规则引擎是将许多个功能模块组合起来发挥作用的，这样才有足够的灵活性应对不同的时期的不同 的决策方式，而不需要重新开发过新的系统。这个模块的作用就是将多个规则模块配置起来而形成用户所 需要的计算规则系统。 c）运行参数(Run Properties) 作为 MCS 的主要功能，通过一些规则去计算物流的分配。而规则的确定就是通过这些参数的选择来 确定的，为了方便而不需要每次运行参数都要重新选择，这里直接将参数保存在数据库中，做模拟的时候 只需要到数据库中将规则参数取出就可以运行了。 d）原始数据重新设置(Input Data Reset) 此功能是为了对一些规则计算中需要的特别的数据进行设置及保存。例如 R4数据，前段，后段及后 段 Rework 数据等等。这些并非运行参数，但在表单中却需要用到。 e）现行机构(Active Org) 这是奇美公司的结构组织形式，奇美(CMO)将公司分为许多个机构(Org)，而在这些机构下面还有多 个分厂(Fab)。由于做企业调整的时候可能会对机构等方面进行变更，因此有必要提供可以方便的改变这 些数据的相关功能。 f）缺省子清单(Default Sub-inventory) 这里是显示系统管理模块中所有已选择的菜单的选项，用户可以通过这里方便的查看自己所选择的 规则以及基础数据，如果有需要修改的地方可以不必一项项去查看。 当 Internet 商业化以后，在全世界，特别是发达国家迅速发展起来。在一些国家（如美国）本地物 流信息 Internet 接入采用包月制，不限时限量，因此 Internet 是近乎免费的的，人们都希望能通过这近乎 免费的网络进行传统的物流信息和传真服务。1995年2月以色列 VocalTec 公司研制出可以通过 Internet 网打长途物流信息的软件产品“Internet Phone” 。 用户只要在多媒体 PC 机上安装该软件，就可以通过 Internet 网和任何地方安装同样软件的联机用户 进行通话。这项技术上的突破引起全世界的瞩目，其背后的无限商机也使许多公司进行此项技术的研究， 从而使 IP 物流信息技术得到迅速发展，人们把这种在 Internet 上实现物流信息业务称为 Internet 物流信 息，应该说是 IP 物流信息的雏形。 Internet 的蓬勃发展使得基于 IP 的语音传输有了它生存的空间，是 VoIP 产生的先决条件。近年来， Internet 以其惊人的发展速度倍受世人瞩目，在 Internet 上传送的数据也呈爆炸性增长，网络上传送的内 容也正在从单一的数据流向多媒体流转变。基于 Internet 的各种应用也如雨后春笋般层出不穷，让人眼花 缭乱。E-Mail、远程控制等都曾经给人们带来很大惊喜。在 Internet 更加普及的今天，网络的不断发展， 宽带网的出现，使得在 Internet 上传输带宽要求相对较高的语音数据成为可能。更加重要的是 IP 及其相 关协议在用户和网络设备中己经大量存在，IP 已经占领了大量的用户终端设备。毫无疑问，许多现存技 术还没有应用到用户终端设备，这使得大量存在于用户的个人计算机和工作站上的 IP 具有了决定性的优 势。IP 的这一“地位”使它成为处理语音业务的理想平台。现在已经有许多人利用 PC 机来帮助他们完成 物流信息呼叫。不久的将来，基于计算机的物流信息就会变得很普遍，并成为现有物流信息系统的自然扩 展。而且，IP 既可以用于广域网也可以用于局域网，而帧中继则只能用于广域网。 技术的成熟是发展 VOIP 的另一个主要原因。由于相关的硬件、软件、协议和标准的不断发展和技 术突破，使得 VOIP 的广泛使用很快就会变成现实。这些领域中的技术进步和发展为创建一个更有效、功 能和互操作性更强的 VOIP 网络起着推波助澜的作用。 传统电路交换物流信息在成本上完全无法和基于分组交换的物流信息竞争，其原因就是带宽合并和 语音压缩技术。一些认为分组语音优于电路交换语音的研究还引用了具体数字，表明在成本上分组语音只 是电路语音的1/4或1/3，有些人还认为这一数字是保守的。Level3 公司的首席执行官 James Crowe 曾说 VOIP 的成本只是电路交换物流信息成本的1/27。 物流信息业务历来都是各国管制最为严格的业务，但对于 IP 物流信息各国大多采取宽容甚至是扶植 的态度，如美国将 IP 物流信息归类为增值业务，从而不必承担长途物流信息公司所受的管制规定，这样 IP 物流信息提供长途物流信息业务时，不必向本地物流信息公司交纳占长途物流信息费40%左右的接入 费。这样庞大的通信市场潜力，必然吸引众多传统和新型的电信公司加入到 IP 物流信息的研究、开发和 经营的队伍中。在我国，VoIP 也是大势所趋，政策压制的原因是开放的条件不成熟。一切政策的制定都 要遵从一个大前提，即保障公开竞争、维护国家和用户利益、防止重复建设。 2.2.3 基础数据维护模块 系统除了需要有自身的一些组成方式及配置参数外，还需要有物料的数据以及生产订单等等其他数 据。因此，需要有基础数据维护模块来对物料、订单及一些其他数据来进行维护。 a）新添产品发布(New Product Release) 这个模块是将新的订单计划保存进数据库。这里需要根据不同地域的公司保存下诸如是哪个机构 (Org)需要的哪些产品(Product)，并且需要设置好该产品是由哪些种类的部件(Item)所组装而成的，以此作 为后面所需要的订单计划的基础而保存进数据库并给这次发布的数据一个版本号。信令技术保证电话呼叫 的顺利实现和话音质量，目前被广泛接受的 VoIP 控制信令体系包括 ITU-T 的 H.323系列和 IETF 的会话 初始化协议 SIP。 SIP19是一种比较简单的会话初始化协议。它不像 H.323那样提供所有的通信协议，而是只提供会 话或呼叫的建立与控制功能。SIP 可以应用于多媒体会议、远程教学 Internet 电话等领域。SIP 既支持单 点发送（Unicast）也支持多点发送，会话参加者和媒体种类可以随时加入一个已存在的会议。SIP 可以 用来呼叫人或机器设备，如呼叫一个媒体存储设备记录一个会议，或呼叫一个点播电视服务器向会议播放 视频信号。 SIP 是一种应用层协议，可以用 UDP 或 TCP 作为其传输协议。与 H.323不同的是：SIP 是 一种基于文本的协议，用 SIP 规则资源定位语言描述（SIP Uniform Resource Locators） ，这样易于实现 和调试，更重要的是灵活性和扩展性好。由于 SIP 仅作于初始化呼叫，而不是传输媒体数据，因而造成的 附加传输代价也不大。SIP 的 URL 甚至可以嵌入到 web 页或其它超文本链路中，用户只需用鼠标一点即 可发出一个呼叫。与 H.323相比，SIP 还有建立呼叫快，支持传送电话号码的特点。 b）需求回顾(Demand Review) 这个模块可以通过一些条件去查询已经发布过的订单信息，并且丰富订单信息，在原始数据上添加 需求类型(Demand Type)、R4类型、前段或者后段数据类型(Front End/Back End Rework/Back End)、每 日版本(Daily Version)、计划类型(Plan Type)以及备注(Remark)等信息。并将回顾过的表单保存进数据库， 作为单据的原始数据。话音压缩编码技术是 IP 电话技术的一个重要组成部分。目前，主要的编码技术有 ITU-T 定义的 G.729、G.723（G.723.1）等。其中 G.729可将经过采样的64kbit/s 话音以几乎不失真的质 量压缩至8kbit/s。由于在分组交换网络中，业务质量不能得到很好保证，因而需要话音的编码具有一定的 灵活性，即编码速率、编码尺度的可变可适应性。G.729原来是8kbit/s 的话音编码标准，现在的工作范围 扩展至6.411.8kbit/s，话音质量也在此范围内有一定的变化，但即使是6.4kbit/s，话音质量也还不错， 因而很适合在 VoIP 系统中使用。G723.1采用5.3/6.3/kbit/s 双速率话音编码，其话音质量好，但是处理时 延较大，它是目前已标准化的最低速率的话音编码算法。此外，静音检测技术和回声消除技术也是 VoIP 中十分关键的技术。静音检测技术可有效剔除静默信号，从而使话音信号的占用带宽进一步降低到 3.5kbit/s 左右；回声消除技术主要利用数字滤波器技术来消除对通话质量影响很大回声干扰，保证通话质 量。这点在时延相对较大的 IP 分组网络中尤为重要。 c）需求调整(Demand Adjust) 这个模块将通过用户选定的条件去取出回顾过的表单，并且对数据的日期，每日需求数量等等进行 调整并保存。VoIP 中网络传输技术主要是 TCP 和 UDP，此外还包括网关互联技术、路由选择技术、网 络管理技术以及安全认证和计费技术等。由于实时传输协议 RTP 提供具有实时特征的、端到端的数据传 输业务，因此 VoIP 中可用 RTP 来传送话音数据。在 RTP 报头中包含装载数据的标识符、序列号、时间 戳以及传送监视等，通常 RTP 协议数据单元是用 UDP 分组来承载，而且为了尽量减少时延，话音净荷通 常都很短。IP、UDP 和 RTP 报头都按最小长度计算。VoIP 话音分组开销很大，采用 RTP 协议的 VoIP 格式，在这种方式中将多路话音插入话音数据段中，这样提高了传输效率。 d）物流计划发布(Material MPS Release) 通过这个模块，将前面调整过的数据根据一定的条件筛选出来，选择所需要的一个或多个清单数据 作为一个 MPS 版本进行发布。 e）物流计划查询(Material MPS Query) 这个模块可以将已经发布的 MPS 清单根据版本号进行查询。 f）物料单时刻表替代物料(Schedule BOM Alternate Item) 该模块对一些作为替代物料的需求量及需求时刻做出计划清单，这些数据将在规则引擎计算的时候 使用上。 g）临时物料单(Temp BOM) 该模块可以设置并保存一些临时使用物料的物料单，这些数据也将在规则引擎计算的时候使用。 h）其他模块 由于业务上的复杂性，基础数据维护模块中还存在着许多实现细节功能的小模块，通过这么多的模 块，客户就能够将复杂且庞大的数据输入到数据库中，以提供给系统计算出最合适的物流分配方式。 2.2.4 主要功能模块 主要功能模块是实现 MCS 系统的核心功能的模块。 有了前面基础数据维护模块所提供的数据，系统就能够从数据库中将所需要的数据取出来，并通过 用户所选定的运算规则去计算出最合理的物流分配方式。用户需要计算的有网络需求物流分配方式和日常 回顾物流分配方式，并且客户要求提供模拟的运算功能。 a）数据状态检测(Data Check Status) 为了保证运算质量，避免因为数据问题而导致的计算问题，系统在计算之前必须提供一个数据状态 检测功能。该功能负责在运算前先去数据库中检查所需的各项数据是否已经到位。检测之后，会将所有数 据的状态都显示在页面上，方便用户查看。如果数据不完整，则无法进行物流计算。 b）运行状态(Run Status) 由于系统对物流的计算中，数据量非常的庞大，处理过程非常的复杂，经常计算一次需要几小时， 甚至是十几个小时。并且系统可能在同一时刻对几个不同需求的物流进行运算。这个时候就需要有一项功 能来查询各项物流的计算情况。运行状态查询功能中还需要能够定时刷新最新状态。 c）供应网络需求计算(Net Requirement) 在经过了数据状态检测之后，如果数据是完整的，那么就可以开始网络需求计算了。用户在选择了 需要的数据后，就可以计算了。系统会根据选择出的版本到数据库中将所有需要的数据取出来进行计算。 计算的结果将会直接保存到数据库中，并给予版本号，方便用户查询。 d）日常回顾计算(Daily Review) 该功能同网络需求计算类似，不同的只是需要的数据以及运算的规则不同。系统同样会从数据库中 取出所需要的数据，通过规则引擎计算出最佳的结果并保存进数据库中。 e）模拟网络需求计算(Net Requirement Simulation) 按照用户的要求，需要提供一个模拟网络需求计算的功能。该模块将会模拟网络需求计算中的取数 逻辑，让用户根据自己的需要来选择数据运行。由于数据之间存在着一些联系，因此在取数的过程中采取 了多个页面分步的取数，将基本的数据先输入，而后根据已经选择的数据按一定的逻辑关系来取得后面所 需要的一些数据。用户可以随时退回到前面的数据进行重新选择，方便了使用。在所有数据选择好之后， 系统会将选择结果分类保存到数据库中，并按表单的方式罗列出来，确认无误之后，用户就可以开始模拟 计算。系统会将参数传递给规则引擎提供的接口，然后自动调用运行状态查询。用户可以在此模块按照系 统运行过的版本号去查询结果并可以通过点击连接来了解此次计算的初始参数。 f）模拟日常回顾计算(Daily Review Simulation) 模拟日常回顾计算模块同模拟网络需求计算是类似的，不同点也是在取数逻辑和最后调用的引擎接 口不同。系统同样会将用户选择的数据分类保存好，然后将参数传递给日常回顾计算的接口进行计算，而 后调用运行状态查询。模块同样提供了用户按照版本查询计算结果的功能。 2.2.5 物料工具模块 物料工具模块是 MCS 项目的二期工作中的一部分。根据已经有的物流计划，进一步计算出物料的情 况，并且能从不同的角度，比如产品的角度(Product View)、物料的角度(Material View)、物料组的角度 (Partgroup View)去查看结果。因此，物料工具模块同样需要从数据库中取得数据，通过规则引擎计算结 果，并提供多个查询结果的方法。 a）数据状态检测(Data Check Status) 由于同样需要引用大量的计算数据，所以在做模拟计算前，同样需要对数据的完整性进行检查。这 个模块会对所有需要的数据都检测过，并且将检测结果显示到页面上。 b）运行状态(Run Status) 物料工具模块中的运行状态查询模块可以查询物料工具模拟计算的运行情况。也会把诸如数据报错， 运行中，运行完毕等状态都显示出来。同样采用了定时刷新的功能。 c）物料工具模拟计算(Material Kit Simulation) 物料工具模拟计算可以让用户选择需要的数据，并将数据分类保存，最后模块将会把参数传给相关 的引擎接口。引擎将会把结果计算好并保存在数据库里方便查询。 d）产品视图查询(Product View) 该模块提供了根据产品的角度来查看物料情况的方式。用户可以根据由模拟计算得到的版本以及一 些更加细节的条件来查询出自己希望得到的内容。 e）物料视图查询(Material View) 该模块提供了根据物料的角度来查看物料情况的方式。用户可以根据由模拟计算得到的版本以及一 些条件来查询出自己希望得到的内容。并且在需求数量为负的时候能通过点击链接来得到物料组的情况。 f）物料组视图查询(Partgroup View) 该模块提供了从物料组的角度来查看物料情况的方式。用户也是通过模拟版本等多项条件来查询运 算出来的结果。 2.3 系统总体设计 2.3.1 系统架构描述 MCS 系统是基于 IBM Websphere 和 Oracle 的软件系统，本系统软件构架使用了 Struts 作为表示层 实现框架，Hibernate 作为持久层实现框架，遵循 J2EE 1.4标准。 总体系统结构如下图2-2所示： a）架构目标和约束 MCS 架构的目标是满足 SOW 中的所有功能性需求和非功能性需求，并且能确保系统的性能、安全 性、可扩展性等要求。 启用 MCS 的限制要求： 实现 MCS 的系统必须符合 J2EE 的安全规范并使用 Websphere 应用服务器 认证统一通过 SSO 服务器进行验证，并遵循 SSO 系统的规范要求。 数据库服务器为 Oracle9i 要求提供优化的求解结果和出色的求解效率 软件架构及所采用技术需符合 CMO 技术规范 b）系统假设条件 Web UI 所部署的 Application Server 上已经正确部署 SSO。 Web UI 与 Engine Server 之间无防火墙。 c）系统架构设计 根据以上的要求，MCS 系统按 CMO 开发规范而采用以 J2EE 为主的多层架构，采用 JAVA 为主要 程序语言。客户端采用浏览器访问所有资料，应用服务端则采用构架于 IBM Websphere 应用服务器之上 的 J2EE 应用，通过 JDBC 连接后台数据库。IBM Websphere 的 web 服务器部分将作为界面实现部分， 其应用服务器部分将作为主要业务运行引擎。 J2EE 是目前世界上最通行的企业应用解决方案首选平台之一。它已被 IT 业界反复证明具有以下优 点：高性能，高安全性，稳定，低成本，可携性高，跨平台，可复用度高，延伸性强和可测试性强等。 J2EE 平台提供了一个基于元件的设计，开发和部署应用的开发环境，同时也提供了多层的分散式应用模 型，统一的安全模型，可复用的元件和弹性的事务控制。7J2EE 平台从软件的整体构架上为 MCS 以及 其他 CMO 基于 Web 的应用的实现提供了最根本的条件。 MCS 采用当前企业应用解决方案中流行的 Struts+Hibernate 的软件系统构架，图2-3从总体上显示 了此软件系统构架的层次和各个元件在平台中的位置： 上图2-3中在系统中最低层运行的可以是 Window 2003/AIX 服务器作业系统，在 Window 2003服务 器作业系统上运行的是 IBM Websphere 应用服务器，在 AIX 作业系统上运行的是 Oracle 9i 数据库服务 器，在 IBM Websphere 应用服务器容器中运行 Apache Struts Web 应用平台和 Hibernate 数据持久化平 台，MCS 系统的核心业务逻辑应用元件就建立于这些平台之上。 Struts 的使用 系统中采取了把 Apach Struts 的各组件包放置于 lib 目录内，Struts 的配置文件 struts-config.xml 则 放置于 web/webContent/WEB-INF 目录中。添加页面时时，只需要在配置文件中添加映射关系，就可以 很方便的使用 Struts 提供的操作。 Hibernate 的使用 系统中采取了将 Hibernate 的组件包放置于 lib 目录内。需要添加持久层映射时，可以使用工具包中 的工具生成持久化对象，并在 Hibernate3.cfg 文件中添加映射关系，就能实现 Hibernate 所提供的功能。 EJB 的使用 系统采用符合 EJB2.x 规范的 Session Bean 作为 Service 层的封装。 业务逻辑在 Java Service 中实现，然后由 Session Bean 继承相应的 Java Service 以获得业务方法。 该设计的优点在于保留 Java Service 易测试性以及可扩展性的同时可以获得 EJB 带来的分散式部署和容 器管理事务等优点。 d）运行环境 系统环境被设计成4个部分：Development、Pre-Production Testing、Production、Simulation。具 体请看下图2-4所示。 2.3.2 实现设计 a）总体结构与模块设计 总体结构图如图2-5所示： 组件图如图2-6所示： 从图中可以看出，系统共有 JSP，Action，Service，DAO，UI Adapter，Engine Adapter，LP Engine 共7种类型的组件。 其中 JSP，Action 遵循 CMO 技术规范要求使用 Struts 作为表示层框架，DAO 使用 Hibernate 作为 持久层框架。 b）通讯设计 由图2-7负责 UI 与 Engine 通讯元件称为“Adapter” ，UI Server 端和 Engine Server 端有各自的 Adapter。UI Adapter 和 Engine Adapter 可以根据事先定义的通讯协定交流，并分别负责于上层的 UI/Engine 交互。为减少对系统平台的依赖，同时也为了灵活和高效，Adapter 将通过 Socket 套接字调用 低层的 TCP/IP 实现数据交换。 Windows, Unix 和 Linux 环境都提供了类似的 Socket 接口，Adapter 只 需要较少的修改就可在这些环境间移植。 c）载入平衡与容错设计 UI Adapter 可以管理多台 Engine Server，其中每台 Engine Server 又可以并发运行多个 LP Engine，UI Adapter 根据各 Engine Server 的负荷情况自动将 Engine 运行任务分配给空闲的 Server 运行， 以达到最大程度利用硬件资源的目的。 对于暂时无法安排运行的任务，UI Adapter 会将其存储在 Queue 中，直到某台 Server 有 Engine 运 行结束再从 Queue 中取出最早到达的任务安排运行。 UI Adapter 需要维护可用 Engine Server 列表，每隔一定的时间间隔向列表中的 Server 发出监控信 号来获取状态，只有可用的 Server 才参与载入平衡。 多台 Server 之间形成 Cluster，当任何一台 Server 出现故障（网路故障、系统崩溃等）导致无法响 应时，UI Adapter 会避免使用故障 Server，直到该 Server 重新恢复响应才会将任务分配给它。容错功能 仅针对尚未发送到故障 Server 的任务有效，已经进入运行状态的任务不能重新切换到其他 Server 执行。 d) 数据库架构设计 MCS 的 Table 可划分为4个部分，分别是：Interface Table、Basic Data Table、UI Table、SCPO Table，其用途分别说明如下： Interface Table：MCS 与外部系统接口表，所有与外部系统的数据交换都通过该组表来进行。 Basic Data Table：存放诸如产品、物料、区域、机构、计划等基础资料，基础资料通过接口表来 进行更新，某些资料也可以通过 Web UI 临时添加。 UI Table：存放通过 UI 维护的资料关系以及 MCS 的各种报表。 SCPO Table：SCPO 产品所属表。由 Engine 输入表、Engine 输出表、参数配置表以及对应的备 份表组成。 从图2-8中可以看出，MCS UI 直接访问的表只有 Basic Data Table 和 UI Table，对 SCPO 相关表的 访问通过内嵌的 SCPO UI 来进行。 e）日志机制 为了了解和记录程序内部执行细节以及便于除错，MCS 系统加入了日志机制。 开发中使用的日志组件为第三方的类库 Log4j。它提供了可扩展的以及多种不同方式的记录日志，包 括命令行、文档、记忆体、syslog 服务器、Win 事件日志等。提供九个不同的日志输出，例如 NOTSET，DEBUG，INFO，NOTICE，WARN，ERROR，CRIT，ALERT 与 FATAL/EMERG。使用者 可以动态控制不同的日志记录，然后有效率地进行编码的调整。 日志记录的配置文档 perties 保存在 Websphere 的 Class Path 目录下。 perties 文档中的包名控制了不同日志记录的设定。在应用系统的每一个需要作日志的 java 类中会得到一个 log4j 的 Logger 类的实例(instance)。然后用日志方法把系统中所有的日志都写到文档中保存。 f）异常处理 本系统中 Exception 按业务逻辑层次可划分为 DAO, Service, Adapter, Action 四个层次。 由 DAO 层抛出的 Exception 全部被封装成 DAOException，其他层次不作处理，直接向更上一个 层次抛出，最后在 struts-config.xml 配置文档里指定相应的处理页面。由于 DAOException 都是由持久层 抛出的，是数据库的异常或者是 Hibernate 的异常，所以根据异常的代码可以统一进行提示，不需要从 DAOException 再继承衍生子类了。 Service 层根据具体业务抛出系统自定义的 ServiceException。所有 Service 层抛出的异常必须继 承自 ServiceException，根据 service 的功能，如果需要根据异常的不同类型，Action 层会做不同的处理， 则可以抛出其他业务相关的 Service Exception 的子类异常。Service 不获取 Java Unchecked Exception，例如：java.lang. NullPointerException 等等，因为此类异常通常表示程序编写的错误。 Actions 层获取由 Service 层抛出的异常（此类异常是用户操作不当造成） ，但是不再封装和抛出 自定义异常。Actions 层必须具体地获取由 Service 层抛出的异常类物件，然后根据每个具体的异常类物 件向 struts 提交相应的 ActionError 的信息，并且选择不同的错误处理页面。 Adapter 层获取前后台 Socket 通讯产生的异常，这类问题通常是网路故障或者 Engine 非正常状 态导致的。这类异常在被捕获后会统一的抛出 Adapter Exception。 除了以上情况外，如果异常是不可补救的，则会一直抛到 struts-config.xml 配置档里指定的 ExceptionHandler 处理。 在 MCS 系统中，所有的应用程序异常都继承自 RuntimeException 类，这类异常无需显式地声明俘 获。每一个子模块在捕获到一个不可修复的应用异常后都会创建一个表示此子模块的异常，并且用它封装 被捕获到的