销售管理系统的UML分析与设计说明.docx

销售管理系统的UML分析与设计说明.docx

《销售管理系统的UML分析与设计说明.docx》由会员分享，可在线阅读，更多相关《销售管理系统的UML分析与设计说明.docx（10页珍藏版）》请在冰豆网上搜索。

销售管理系统的UML分析与设计说明

销售管理系统的UML分析与设计

摘要销售管理系统是现代企业管理系统的一个重要组成部分，传统的系统分析设计方法已经难以保证软件开发的效率和质量，通过将UML应用于销售管理系统建模，可以加速软件开发进程，提高软件质量，支持动态的业务需求，并方便地集成已有的企业管理资源。

 关键词销售管理系统；UML；分析；实现

 1引言

 当前社会对信息系统的需求日益增长，需求变化也越来越快，软件开发的技术发展方向已经从“提升被开发系统的执行效率”转变为“提升开发效率”。

面向对象（OO）技术降低了解决方法域与问题域的差别，提供了良好的复用机制，能够更加有效提高软件开发效率，完全顺应了软件开发技术的发展方向。

 UML（TheUnifiedModelingLanguage,即统模语言）是一个通用的标准建模语言，可以对复杂的系统建立可视化系统模型，目前已经被工业标准组织OMG（ObjectManagementGroup）接受，一经推出便得到许多著名计算机厂商如Microsoft,HP,IBM,Oracle等支持，在国际上应用日益广泛。

 本文通过一个销售管理系统的分析与设计，阐述如何通过UML降低开发难度和提高开发效率。

 2销售管理系统的基本特征和功能模块

 本系统以“订单”为核心，构建出了以“客户”为中心的管理模式。

 该系统具有以下一些特征：

（1）先进的系统结构，面向销售流程，能适应原有销售工作流程并进行合理的改进，从而更贴近实际的应用；

（2）针对大型企业销售管理人员多，销售管理复杂的特点，通过系统提供的灵活的人员权限设置和全面的财务核算方式，实现真正的销售网络化办公；

 （3）在实现订单的电子化、工作流程的数字化同时，帮助公司领导提高决策的科学化水平；

 （4）通过对客户信息的管理，实现对客户广告走势和重要客户情况统计和分析。

 整个系统操作业务人员包括：

销售员、销售经理、仓库管理员、审计员、公司销售主管、和系统管理员。

各个角色承担不同的系统任务，通过网络和通信系统，连接到销售管理系统，使用统一的访问界面，进行日常的销售业务操作，最终实现销售部门业务的正常运转。

 3系统的UML分析与实现

 UML概述及特点

 UML是一种编制系统蓝图的标准化语言，可以对大型复杂系统的各种成分可视化说明并构造系统模型，以及建立各种必要的文档。

UML通过三类图形建立系统模型：

UseCase图，静态结构图（类图，对象图，组件图，配置图）和动态行为图（顺序图，协同图，状态图，活动图），这些图可以从不同抽象角度使系统可视化。

UML具有面向对象、可视化、独立与开发过程和程序设计语言以及易于掌握使用等特点。

UML适用于各种规模的系统开发，能促进软件复用，方便地集成已有的系统并有效减少开发中的各种风险。

 UML在销售管理系统中的实际应用

 UML是一种建模语言，是系统开发的一个组成部分，本身并没有关于开发过程概念的定义和表示符号。

UML的创始人booch,Jacobson和RumBaugh在rational公司的支持下综合了多种系统开发过程的长处，提出新的面向对象的开发过程，称为Rational统一过程（RationalUnifiedProcess,RUP）。

RUP过程的核心工作流程包括：

业务建模、需求分析、系统分析与设计和实现、实现、测试和系统部署。

下面通过UML来分析并构造销售管理系统模型，并结合Rational统一过程加以描述，图形使用RationalRose工具软件绘制。

 3.1销售管理系统的业务建模和需求分析

 业务模型和需求分析的目的是对系统进行评估，采集和分析系统的需求，理解系统要解决的问题，重点是充分考虑系统的实用性。

结果可以用一个业务用例（BusinessUseCase）框图表达，根据销售系统的基本特征和功能可得到本系统的用例图，如图2。

图1销售管理系统业务用例框图

 模型中的活动者代表外部与系统交互的单元，包括销售员、销售经理、仓库管理员、审计员、公司销售主管、和系统管理员；业务用例框图是对系统需求的描述，表达了系统的功能和所提供的服务，包括客户管理子系统、订单管理子系统、销售统计子系统、产品管理子系统系统管理子系统。

 图2是销售管理系统层次的用例模型，只包含了最基本的UseCase模型，是系统的高层抽象。

在开发过程中，随着对系统需求认识的不断加深，用例模型可以从顶向下不断细化，演化出更加详细的UseCase模型。

根据系统的用例图，可以对系统的持久对象进行设计，下图是本系统持久对象类及类之间关系图。

图2核心业务对象类及类之间关系

 3.2销售管理系统设计

 系统分析与设计是研究欲采用的实现环境和系统结构，结果是产生一个对象模型，也就是设计模型。

设计模型包含了UseCase的实现，可以表现对象如何相互通信和运作来实现UseCase流的。

对于系统的静态结构，可以通过类图、对象图、组件图和配置图来描述；对于系统的动态行为，可以通过顺序图、协同图、状态图、活动图描述。

这些图在加上说明文档就构成一个完整的设计模型。

 3.2.1系统架构设计

 销售管理系统拥有大量销售信息资源，这些资源包括各种客户、订单、和产品等信息。

其数据量大、信息变化快，非结构化信息与结构化信息共存。

使用UML对销售管理系统进行基于面向对象的分析和实现，可以从开发的第一步开始，从系统的底层就把握住销售信息资源的特征，为下一步具体实现打好基础。

在销售管理系统建立模型时要涉及到处理大量的模型元素，如类、进口、组件、节点、图等，可以将语意上相近的模型元素组织在一起，这就构成了UML的包，包从较高的层次来组织管理系统模型。

 系统主要有以下四个包：

（1）用户接口包（ＵserInterfacePackage）

 用户接口包在其他包的顶层次，为系统用户提供访问信息和服务。

要注意一点，由于开发工具使用不同，该接口描述也是有区别的。

如果采用JavaWeb开发，就要以JSP（JavaServerPages）为基础，如果采取Microsoft的A开发，其基础就是标准化控件组。

本系统在此将使用JavaWeb开发，下面有关代码的描述都是基于Java的。

（2）业务逻辑包（BusinessRulePackage）

 该包是销售管理系统业务的核心实现部分，包括客户管理、订单管理、产品管理等，其他包可以通过访问该包提供的接口，实现业务逻辑，如客户管理业务等。

 （3）数据持久访问包（DataPersistencePackage）

 该包实现数据的持久化，也就是与数据库交互，实现数据的存取、修改等操作。

 （4）通用工具包（ＵtilPackage）

 该包主要包括应用程序安全检查的类，可以为上面三个包提供安全检查，如客户端检查和服务器端业务规则检查等，同时包括一些系统异常检查与抛出处理以及系统日志服务等。

   3.2.2系统详细设计

 详细设计主要是描述在系统分析阶段产生的类，与分析阶段类的区别就是偏重于技术层面和类的细节实现。

销售管理系统提供的各种服务都是建立在分布、开放的信息结构之上，依托高速、可靠的网络环境来完成的。

每项服务都可以看作一个事件流，由若干相关的对象交互合作来完成。

对于这种系统部的协作关系和过程行为，可以通过绘制序列（Sequence）框图和协作（Collaboration）框图来帮助观察和理解。

此外，描述工作流和并发行为还可以通过活动框图，表达从一个活动到另一个活动的控制流。

同时，可以在理解这些图的基础上，抽象出系统的类图，为系统编码阶段继续细化提供基础。

下面以JavaWeb开发为例，介绍客户管理子系统的详细设计

 1.客户管理子系统的基本结构建模：

下图是客户管理子系统主要类极其关系的详细设计

图3客户关系子系统类的详细设计及类之间关系

 2.序列图：

序列图是一种对象交互图，着重强调了时间序列，而不是静态对象的关系，通过序列图可以清楚地看到“谁在什么时间对谁说了写什么”。

图4客户管理的序列框图

图5销售人员对客户管理的顺序框图

 图4是一个客户管理的序列框图例子。

描述了先加载某个客户；显示某些状态；再更改某些属性值，最后更新数据库状态的一次执行过程。

此图可设计Customer类的loadCustomer（int）和updateCustomer（）方法实现。

 通过序列框图可以清晰看出系统用户、客户管理子系统的用户接口、数据库连接模块之间以时间为顺序的消息交换，这对于把握系统的控制流、顺序行为和交互行为是非常有益的。

建立在分布网络环境下的销售管理系统的事件流和控制流是非常复杂的，需要从顶层到底层进行一步步分解，用多幅能反映动态结构的图来分析与说明。

图5反映了销售人员对客户管理的顺序框图。

 3.状态图适合描述一个对象穿越多个UseCase的行为。

类的状态图表示类的对象可以呈现的状态和这个对象从一种状态到另一种状态的转换。

图6Customer对象状态图

 图6描述了Customer对象的生命期中可能的状态及状态变化（从创建、更新到消亡的转变过程），其中insertOrder/deleteOrder不是直接作用于当前customer对象，而是指当前customer对象所涉及的订单操作。

此例说明其他对象的操作可能改变当前对象的状态。

 4.协作图：

协作图和序列图相似，两种图所表达的是同一种信息，可以将序列图转换为协作图，反之也然。

但两者是有区别的，序列图强调的是交互的时间序列，协作图强调的是交互的语境和参与交互的对象的整体组织。

下图描述的是查询一个客户信息消息传递的过程。

图7、查询客户信息的协作图

 5.活动图：

用于描述业务过程和类的操作，类似与旧流程图，是对业务处理工作流建模，在活动图中可以增加角色的可视化的维数，下图是增加了Customer、Saleman、Warehouse三个角色的系统活动图，反映了在业务处理过程中，每个角色执行的过程。

图8活动图

 通过框图，设计和开发人员可以确定需要开发的类，类之间的关系和每个类操作和责任。

序列框图按照时间排序，用于通过情境检查逻辑流程。

协作框图用于了解改变后的影响，可以很容易看出对象之间的通信，状态图描述了对象在系统可能中的状态，如果要改变对象，就可以方便地看到受影响的对象。

 6.软件系统一般由一组部件组成，换句话说，部件是相对独立的部分软件实施，有自己特有的功能，并可在系统中安装使用，系统中各部件是相互协作合作，给系统提供完整的功能。

下图是本系统运行时的主要部件

图9运行的部件图

 3.2.3销售管理系统的实现、测试和系统配置

 系统采用五层逻辑结构：

客户端只需中文浏览器；表示层用12个JSP（JavaServerPage）文档实现动态页面以创建、操作业务对象；核心对象层用6个Java类以JavaBean形式构成业务处理的核心对象；连接层采用JDBC2提供两种连接方式：

一种是基于DriverManager，主要支持Java应用和测试；另一种基于DataSource；资源层即数据库服务器。

 经过系统分析和设计后，就可以根据设计模型在具体的环境中实现系统，生成系统的源代码、可执行程序和相应的软件文档，建立一个可执行系统；进而需要对系统进行测试和排错，保证系统符合预定的要求，获得一个无错的系统实现。

测试结果将确认所完成的系统可以真正使用；最后完成系统配置，其任务是在真实的运行环境中配置、调试系统，解决系统正式使用前可能存在的任何问题。

 4结束语

 销售管理系统的发展方兴未艾，目前正处于传统手工、半手工管理向数字化过渡的阶段，转变过程中需要应用和集成最新的信息技术，以达到对网络信息资源最有效的利用和共享。

传统的系统分析设计方法难以保证效率和质量，将UML应用于销售管理系统的建设，可以加速开发进程，提高代码质量，支持动态的业务需求。

从实际效果来看，UML可以保证软件开发的稳定性、鲁棒性，在实际应用中取得良好的效果。