软件工程课程设计

1、PAGE PAGE 17目录1. 背景2 2. 摘要.2 3. 系统说明2 4. 系统需求分析3 4.1 客户服务系统主要功能需求34.2 建立用例模型34.3 用例描述64.4 建立分析模型74.5 建立领域模型114.6 构建分析类124.7 交互图135. 系统的非功能性需求156. 总结167. 参考文献161.背景 信息时代的今天，各企业的商家所关心的不再局限于自身的产品质量、生产设备、员工的素质，更多的是关心自己的销售集体（客户群），关心他们的想法、需求、购买目的。众所周知，顾客就是我们的上帝，我们只有满足了上帝的需求，上帝才能给我们带来一切。一个企业要生存发展，就是要不断地满足顾

2、客的需求，无论我们做出什么样的决策，最终都是为了这个目的。每个领域都有自身生存法则，但无论这个法则如何变化，为客户服务的宗旨是不会变的。随着信息技术的日益发展，产品售后服务的信息化已成为产品售后服务系统的必然趋势。而售后服务便是围绕着商品销售过程而展开的配套服务体系。做好售后服务，是商业企业销售服务工作的一个重要组成部分，也是整个商品交易过程中的一个重要组成部分。摘要本文通过对售后服务管理系统平台构建过程的各种需求分析，提出企业构建信息化系统的步骤和解决办法，提出售后服务信息化系统的作用和意义关键字： 信息化 结构化方法 面向目标3. 系统说明产品售后服务系统主要为公司解决售后服务管理的需求，

3、协助工作人员对客户进行日常调查和客户管理，提高管理效率，降低运作成本，增强企业长期竞争力。通过该系统，公司系统管理人员能实现对用户、客户的管理系统；系统管理人员能随时了解用户的情况；根据售后服务管理的主要工作内容，售后服务管理系统的用户是售后服务人员和企业管理人员，系统包括问题类别设置、问题级别管理、客户信息管理、问题管理、客户服务调查、问题分配管理、工作记录管理、常见问题管理等主要功能具体功能如下: （1）客户问题类别的添加、修改、删除和查询。 （2）客户问题级别的添加、修改、删除和查询。 （3）客户信息的添加、修改、删除和查询。 （4）客户问题级别的添加、修改、删除、提交和查询。 （5）客

4、户服务调查信息的添加、修改、删除和查询。 （6）客户问题的分配、解决和查询。 （7）工作记录信息的添加、修改、删除和查询。 （8）常见问题的添加、修改、删除和查询。 4. 系统需求分析4.1 客户服务系统主要功能需求（1）客户可以 通过不同方式（如电话、互联网）对软件产品或项目提出使用中的bug或疑难杂症问题以及投诉建议等内容。（2）客户服务人员应当保存客户资料，保存客户历次来电内容，并对客户提出的问题给予解答。对于不能在电话中处理的应当交由相关技术工程师继续跟进处理。（3）对需要安排上门维护的申请应能及时反映给相关部门领导，并由其作出派工处理。（4） 应能及时反馈有派工任务的消息给相关技术工

5、程师，并能保存其处理结果。（5）各部门领导应能对投诉的申请给予及时处理，并能保存处理结果。（6）公司领导和部门领导应能及时查询客户的来电内容，了解产品使用情况及客户服务人员的售后服务质量等相关业务的综合统计信息。4.2 建立用例模型A. 用户中心用例图B. 客户资料中心用例图(1) 登录系统(2) 查询客户信息及咨询记录(3) 查询经验库信息(4) 查询基础资料信息(5) 补充完善经验库信息(6) 维护客户资料(7) 维护来电记录 用例图C. 维护人员的用例：(1) 查询自己的派工单及报告信息(2) 接受并处理自己的派工单(3) 填写报告用例图D. 部门领导的用例：(1) 查询客户资料及咨询信

6、息(2) 查询项目及产品信息(3) 查询维护人员派工单的执行情况(4) 安排派工任务用例图E. 系统管理员的用例：(1) 管理用户(2) 维护基础资料(3) 维护系统 用例图4.3用例描述客户资料维护1.简要说明该用例提供客户服务人员对公司客户资料进行录入、修改和删除功能Actor（角色）：客户服务人员2. 事件流 2.1 基本流（1）Actor选择“维护客户资料”功能启用该用例：（2）系统显示维护客户资料的主界面，其中列出查询界面；（3）Actor选择新增客户资料；（4）系统提示录入客户资料；（5）Actor输入客户编号、来源、类型、省份、公司名称、联系人、联系电话、EMAIL、登记时间、地

7、址、邮编等。输入完成后提交这些信息。（6）系统验证输入数据是否正确：如验证正确则增加这个信息；如验证不正确，则提示用户重输入，并返回客户资料维护主界面；（7）Actor选择“退出”，该用例结束。2.2备选流修改客户资料（1）在客户资料维护的主界面，用户选择查询客户资料；（2）系统显示符合条件的客户资料，内容包括：编号、来源、类型、省份、公司名称；（3）Actor选择修改客户资料；（4）系统显示修改客户资料界面；（5）Actor修改来源、类型、省份、公司名称、联系人、联系电话、EMAIL、登记时间、地址、邮编等。输入完成后提交这些信息。（6）系统验证输入数据是否正确：如验证正确则增加这个信息；如

8、验证不正确，则提示用户重输入，并返回客户资料维护主界面；取消修改客户资料（1）在修改客户资料界面中，用户选择“取消”；（2）系统退回到客户资料维护主界面删除客户资料（1）在客户资料维护主界面的客户资料里显示部分，用户选择“删除”某客户资料；（2）系统提示用户确认删除；（3）用户选择“确认”；（4）系统删除所选客户资料，并返回客户资料维护主界面；取消删除客户资料（1）在提示用户确认删除的界面中，用户选择“取消”；（2）系统返回到客户资料维护主界面；（3）前置条件：客户服务人员已经登陆系统；（4）后置条件：系统中保存了用户所输入的客户资料。4.4建立分析模型 类的属性、类之间的关系及其UML表示A

9、. 关联关系关联类是一种关联关系，它具有类的特征（例如属性、操作和关联关系）。它用一条从关联关系路径到类符号的虚线表示，其中类符号包含此关联关系的 属性、操作和关联关系。这些属性、操作和关联关系适用于原始关联关系本身。关联关系中的每个链接都有指定的特征。关联关系表示不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。在客户服务系统中，派工单是对应于某一个客户的，为了能够让客户服务人员随时了解某客户所对应的派工单，系统就必须让客户对象随时能引用到其所有的派工单对象。因此可以判定它们之间是关联关系。 B. 依赖关系与关联关系不同，依赖关系表示两个实例之间的临时关联关系，且本身不生成

10、专门的实现代码。对于类而言，依赖关系可能由各种原因引起，如一个类向另一个类发送消息，或者一个类是另一个类的操作的参数类型等。依赖关系不只是局限于表示类之间的关系，其他建模元素，如用例之间，包之间都可以使用依赖关系来表示。在UML中依赖关系是使用虚线箭头连接两个类来表示，箭头方向是“维护人员”指向“派工单”，表示为维护人员依赖于派工单。如下图：C. 泛化关系泛化关系是一般元素和具体元素之间的一种分类关系。具体元素与一般元素完全一致，但包含一些额外的信息。在实际生活中，有许多东西都具有共同的特征。例如，狗和猫都是动物。泛化关系表示一个类对另一个类的继承。继承而得的类称为后代。被继承的类称为祖先。继

11、承意味着祖先的定义对于后代的对象也是有效的。泛化关系是从后代类到其祖先类的关系。UML中用一头为空心三角形的连线表示泛化关系。客户服务人员、维护人员、部门领导同属于系统用户，都具有用户ID、姓名、性别等属性，根据重用原则，可以创建一个“系统用户”类。该类包含了各个系统用户的公有特征，客户服务人员、维护人员和部门领导通过泛化（继承）与“系统用户”类建立联系如下图所示：（图中，“系统用户类”的类名为斜体，表明该类被定义为抽象类。） 泛化关系D. 聚合关系一个“派工单”类可以有客户评价和客户意见这些客户评价方面的属性，可以用一个“客户评价”对象来表示这些属性，但同一个“客户评价”对象也可以表示别的对

12、象如“来电咨询”的一些客户评价方面的属性。“客户评价”对象也可以用在别的地方，是可以共享的。如果“派工单”这个对象不存在了，不一定意味着“客户评价”这个对象也不存在了。 “客户评价”与“来电咨询”以及“派工单”类之间的关系可以使用关联关系来表示，但是在需求描述中有用到“包含”、“组成”等词语，所以将它们之间的关系用“聚合”来表示；聚合是一种特殊形式的关联。在UML中，聚合关系表示为带空心菱形头的实线，空心菱形位于“整体”类的一端。 如图所示，聚合关系E. 组合关系聚合和组合是类图中很重要的两个概念。聚合关系描述的对象是整体与部分之间的关系，且两者具有不同的生命周期，而组合描述的对象具有相同的生

13、命周期。聚合关系表示事物的整体/部分关系的较弱的情况，组合关系表示事物的整体/部分关系的较强的情况。在聚合关系中，代表部分事物的对象可以属于多个聚合对象，可以为多个聚合对象所共享，而且可以随时改变它所从属的聚合对象。代表部分事物的对象与代表聚合事物的对象的生存期无关。在组合关系中，代表整体事物的对象负责创建和删除代表部分事物的对象，代表部分事物的对象只属于一个组合对象。 在客服系统中，客户资料对象与客户联系方式对象虽然也是整体-部分关系，但是两者具有相同的生命周期，即客户资料不存在了，该客户资料的客户联系方式也不存在。所以将它们两者的关系定义为组合关系。组合是一种特殊形式的聚合。UML中，组合

14、关系表示为带有实心菱形头的实线，实心菱形位于“整体”类的一端。 如图所示：4.5 建立领域模型领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。领域模型表示的是关键抽象之间的关系，建立领域模型就是发现系统业务实体的过程。在客服系统中，分析得到关键抽象包括以下内容：a. 客户服务人员 b. 维护人员c. 部门领导 d. 软件产品及项目e. 咨询记录 f. 客户资料g. 派工单领域模型图如下图：4.6 构建分析类分析类是概念层面的内容，与应用逻辑直接相关。分析类直接针对软

15、件的功能需求，因而分析类的行为来自于对软件功能需求的描述（用例的内容）。分析类分为三种类型：边界类、控制类和实体类。 边界类边界类提供了对参与者或外部系统交互协议的接口。边界类将系统和外界的变化隔离开来。一个系统可能会有多种边界类：用户界面类：帮助与系统用户进行通信的类。系统接口类：帮助与其他系统进行通信的类。设备接口类：为监测外部事件的设备（如传感器）提供接口的类。 在客户服务系统中，包括了用户和管理员使用客户服务系统的图形用户界面接口。而在维护客户资料用例中，只有客户服务人员会与系统发生交互，在分析模型的构造中，它是独立于设计模型和最后实现的。故而，在此使用 CustomerInfoFor

16、m 类来抽象客户服务人员与系统交互的图形界面或者浏览器页面。 用例对应的边界类及边界类的两种UML表示形式（2）控制类控制类用于封装一个或几个用例特有的行为。控制类增强了系统的可理解性，因为它们建立了系统的动态行为模型。一些复杂的用例可能需要多个控制类来协调其它对象的行为。控制类有效地分离了边界对象和实体对象，使系统更能承受系统边界的变更。但是边界类和实体类之间并非始终需要一个控制类。当事件流比较复杂并具有可以独立于系统的接口（边界类）或者信息存储（实体类）的动态行为时，有必要使用一个控制类。控制类的例子包括事务管理器、资源协调器和错误处理器。 在客户服务系统维护客户资料用例中，Custome

17、rInfoController 就被赋予控制类的职责。 控制类的两种UML表现形式（3）实体类实体类是用于对必须存储的信息和相关行为建模的类，它们的主要职责是存储和管理系统中的信息。实体类通常都是持久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。 实体类代表了系统中各个模块之间流动数据信息的抽象。每一个实体类的实例都代表和抽象了一个实物的存在。根据客户服务系统中的维护客户资料用例分析，客户服务人员在维护客户资料时要接触的实体是“客户资料”。所以，在系统中设计了CustomerInfo实体类对应该实体。 实体类的两种UML表现形式4.7 交互图类图表示了一个系统的静

18、态结构，而系统既有静态方面也有动态方面，动态方面可以通过对象之间的交互来实现。UML中，可以用交互图来对一个系统的动态行为建模。交互图有两种：顺序图和协作图。这两种图展示了对象以及它们执行脚本时交换的信息。在客服系统中，根据“维护客户信息”用例的分析类图，可以采用顺序图来反映类之间的交互过程。顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序，强调的是时间的先后关系。使用 Rational Rose 绘制的“维护客户信息”用例的修改功能顺序图如下图所示：顺序图 与顺序图不同，协作图主要强调了各个类或者模块之间的协作关系。根据已经绘制的修改客户资料的顺序图，使用 Ration

19、al Rose 绘制的修改客户资料用例的协作图如图 协作图 5.系统的非功能性需求5.1安全性需求安全性需求通常分为四类：用户认证需求：阐述系统表示用户和用户认证的方法。授权：如果认证成功，根据用户的级别，允许其执行不同的系统功能。数据完整性和隐私需求：确保数据完整，不会影响系统安全。事务完整性和审计需求：确保用户无法清除自己的在系统中的活动。 记录活动相关的数据，使得系统管理员可以发现所有可能的危险行为。5.2 用户认证需求系统使用一组用户ID 和密码来表示一个用户。在用户登录20 分钟后，如果没有任何的动作，则自动退出登录。如果再次试图访问受保护页面，则自动显示登录页面。5.3 授权需求系

20、统必须实现一定的页面访问限制。用户只能访问自己有权限操作的页面（具体可操作的部分详见系统的功能性需求中各模块的用例）5.4 可靠性需求系统每天至少保持23 小时30 分的可用时间，每日凌晨3:30 到4:00 之间进行日常系统 5.5 并发性需求在多个并发用户更新同一账户信息时，第一个可以成功更新。随后的更新在提交之前， 显示错误信息“用户数据已经改变，是否需要刷新用户数据？”。6.总结 一 本次课程设计做了一个需求分析，需求分析是项目开发的基础，这关系到后面的所有的工作，在做需求分析之前必须先明确客户的基本需求。然后再针对客户的需求做需求分析，首先要对整个的功能及子功能分析然后要对每个子功能的细化工作做好，做好这些之后，我们要针对不同的功能做用例图及功能描述。 二 就本次课程设计