“京北”网上购物商城项目需求与设计文档修订版

“京北”网上购物商城项目需求与设计文档该文档作为一个案例，读者可参看系统分析、设计主要达到什么目的；需求分析和设计方案如何表达、描述。一个实际系统的需求分析和设计文档比该案例文档要更加细致、全面。该文档案例的目的是使读者了解需求分析和设计要完成哪些工作、需求分析和设计文档应包括什么内容。该文档作为一个案例，读者可参看系统分析、设计主要达到什么目的；需求分析和设计方案如何表达、描述。一个实际系统的需求分析和设计文档比该案例文档要更加细致、全面。该文档案例的目的是使读者了解需求分析和设计要完成哪些工作、需求分析和设计文档应包括什么内容。实际项目中需求和设计文档的撰写要求非常严格，内容要全面、表述准确。该文档的设计部分不包含详细设计。作者：中国石油大学（华东）计算机科学与技术学院软件21级樊颖

1系统愿景 41.1概述 41.2定位 41.2.1问题描述 41.2.2项目定位 41.3用户概述及目标 41.3.1用户概述 41.3.2目标 41.3.3用户环境 51.4项目说明 51.5系统特性 61.5.1关键特性 61.5.2其他特性 61.6其他需求和约束 71.6.1质量属性 71.6.2约束 72需求分析 82.1用例建模 82.1.1参与者和用例 82.1.2用例优先级 132.1.3关键用例 132.2补充规约 162.2.1非功能性需求 162.2.2约束 162.3术语表 163面向对象分析模型 173.1业务建模 173.1.1上下文描述 173.1.2识别类 173.1.3类间关系的确定 173.1.4类图 183.2分析层——职责确定及分配 183.3分析层——关键用例实现 203.3.1提交订单用例实现 203.3.2售后处理用例实现 233.3.3话题广场管理用例实现 264面向对象设计模型 294.1架构设计 294.2用例设计 324.2.1提交订单用例设计 324.2.2售后处理用例设计 344.2.3话题广场管理用例设计 354.3子系统设计 364.4类的设计 365精化设计与模式应用 385.1创建型模式 385.1.1单例模式 385.1.1工厂方法模式 385.2结构型模式 395.2.1门面模式 395.2.2适配器模式 405.3行为型模式 415.3.1观察者模式 415.3.2状态模式 425.3.3策略模式 43

1系统愿景1.1概述在科技飞速发展的今天，互联网已日益成为提供信息的最佳渠道并逐步进入传统的流通领域，只依赖线下专卖店销售的模式跟不上时代进步，几乎所有的传统行业都面临向信息时代转型的挑战。民众的购买习惯也在渐渐地朝着“配送到户；随时、自由购买”的方向发展。网络购物在“实地消费、网络下单”的基础上依靠网络极大地丰富了商品销售行业的服务手段，充分利用了互联网“时效性强、客户端普及”的特点，增加了利润的来源空间，扩大了受利群体。1.2定位1.2.1问题描述“京北”网上购物商城系统，该系统致力于满足用户能享受商品及时配送等多元化的需求，提升用户的使用体验，给更多的商家提供机会，使其利用线上销售的模式拓展自身的业务范围。1.2.2项目定位“京北”网上购物商城系统致力于用科技打造人们的生活服务平台，推动商品销售行业的数字化进程。它能解决传统商品线下购买难计算、难查找、难更改、易出错、效率低等问题，为用户提供便捷的服务和极致的体验，为店铺提供一体化的运营方案。系统面向大众群体，覆盖了当前购物系统的基本功能，并在此基础上进行了优化，为用户提供更丰富与更贴心的使用体验。1.3用户概述及目标1.3.1用户概述该系统的主要用户为全球范围内的登录者，具体包括顾客、商家、职员等。其中，顾客可以进行购物、订单信息管理、收藏管理、修改个人信息、举报投诉等操作，商家可以进行商品信息管理、订单信息管理、举报投诉管理、交流论坛管理等操作。1.3.2目标该系统的短期目标为占据中国及周边国家的网上购物系统市场，长远目标为占据全球网上购物系统市场。1.3.3用户环境PC端推荐使用Windows、Linux系统，用户可以根据自己的需要选择，没有特殊的平台限制。手机端APP支持Android4.0以上及ios8以上的任何手机系统。财务人员喜欢使用Excel等工具来处理财务事务，他们希望能够方便、快捷地查看和导出订单数据、销售数据以及其他相关的财务数据。希望该系统能够提供简洁明了的报表功能，支持导出数据为Excel格式，方便进行数据分析和处理。商家希望能够轻松管理和监控自己的店铺和商品销售情况，希望能够实时查看店铺的访客流量、订单量以及销售额等关键指标，并可以方便地对商品进行上下架、价格调整等操作。同时，他们也希望能够及时收到订单和处理退换货的申请等通知。1.4项目说明1.4标题改为“项目需求说明”1.4标题改为“项目需求说明”该系统的用户主要分为三类，分别为：顾客、商家和职员。顾客通过账号登陆系统后台，可以执行购物该段中对顾客、商家、职员需求的说明与“用户概述部分重复”用户概述部分可以移到项目说明部分，单列一个三级标题。、收藏管理、修改个人信息、举报投诉等操作，并可以查看订单信息、个人信息、购物车信息等内容。商家通过账号登陆系统，可以执行商品信息管理、订单信息管理、举报投诉管理等操作，同时可以通过系统查询店铺信息、商品信息、订单信息等内容。职员可以执行广告发布、公告发布、消费者保护等操作。该段中对顾客、商家、职员需求的说明与“用户概述部分重复”用户概述部分可以移到项目说明部分，单列一个三级标题。该系统可与其他外部系统进行交互，例如：通过微信、QQ等第三方登录系统进行身份验证登录该系统；从第三方支付系统进行订单支付；从第三方文件系统查看和导出特定格式的订单数据、销售数据以及其他相关的财务数据等，方便进行数据分析和处理。图图1-1京北网上购物系统语境图该系统由众多的功能模块构成，如商品管理、订单管理、购物车管理等。这些功能模块并不是固定的，而是可以根据实际需要进行增删，具有充分的灵活性。部分功能模块介绍：商品管理：商品信息的增、删、改查等。评价管理：进行商品评价等。购物车管理：添加商品到购物车、从购物车中移出商品等。因为该图只是描述了该系统可能具有的功能模块，并不表示拓扑关系。所以图名为“拓扑结构图”不妥，改为“功能构成图”因为该图只是描述了该系统可能具有的功能模块，并不表示拓扑关系。所以图名为“拓扑结构图”不妥，改为“功能构成图”图图1-2京北网上购物系统功能结构图1.5系统特性1.5.1关键特性商品搜索和过滤：提供高效的搜索功能，支持关键词搜索，也支持商品分类、价格范围等多种过滤方式，帮助用户快速找到所需商品。个性化推荐引擎：基于用户的历史购买记录、浏览行为和偏好，提供个性化的商品推荐，增加购买转化率。社交互动：话题广场允许用户发表关于美食、餐厅、出行、本地生活等主题的帖子，与其他用户互动，分享经验和建议。1该段对各种特性的说明不够明确、详细。.5.2其他特性该段对各种特性的说明不够明确、详细。美观性：该系统的界面由众多专业的美工人员设计，且听取了部分用户的建议，对界面布局等进行了专门优化。计划使用Element-ui界面开发工具，Element-ui囊括了众多小巧美观的组件，可开发出灵动而富有现代气息的界面。易用性：考虑到使用系统的用户遍布各个年龄段且认知水平不同，需要进行易用性设计。界面设计人员分析了不同用户的常用功能，并将它们放置在界面的主要区域，从而做到了一点即达，减少不必要的操作。不同类别用户的界面因功能不同略有差别，均应做到简洁易用。此外，界面应提供白天/夜间模式切换、长辈关怀模式等功能，充分考虑不同用户人群的需要。完备性：在设计系统时，充分考虑了用户的各种功能诉求，据此构建出功能完备的系统。该系统可以满足用户的各种需求，并且还将根据情况变化不断完善丰富。灵活性：考虑到不同地区不同国家购物诉求不尽相同，系统功能模块间的耦合度较低，可以根据实际需要进行功能模块的删减，以满足实际的需要。此外，系统采用前后端分离的模式开发，便于进行灵活的调整维护。1.6其他需求和约束1.6.1质量属性性能：响应快——该系统需要能在用户请求后的500ms内做出响应，及时地反馈结果给用户，不能让用户长时间等待。如果某些功能确实需要较长时间返回结果，则应考虑将其分拆成更小的功能模块，或者在界面的醒目位置适时给予用户提示，告知当前事务的处理情况。页面加载快—该系统需要能在2s内加载完成所需页面，以保证用户体验。高吞吐量—该系统支持每秒处理1000个并发请求。高可靠：该系统需要支持高并发，并且能稳定运行，不能因为各种原因轻易崩溃。该系统需要在99.9%的时间内保持可用状态，最多只允许每月1小时的不可用时间。高安全：考虑到网上购物系统与用户的私密息息相关，该系统必须具有很强的安全性。主要体现在以下几个方面：数据库中的数据加密存储，不能被轻易篡改，且保持有多份备份，定期更新；系统能防御常见的网络攻击和入侵，如DDOS攻击、SQL注入攻击等；系统运行时需要保存运行日志，便于发现问题后及时处理。合规性：该系统需要遵守各种法律法规的要求，不能逾越制度红线。1.6.2约束开发过程约束：要求本软件系统开发方要组建一支专业的开发团队，在客户现场进行开发。运行环境及技术约束：为节省软件运行、维护的成本，要求未来软件运行环境尽量采用开源软件。交付及部署约束：要求必须在三个月内完成开发。部署时要利用客户已有的硬件资源，包括web服务器和数据库服务器。2需求分析该部分建议增加活动图，把业务模型描述得更清晰。再分析和表述业务内容和流程后再给出用例图。该部分建议增加活动图，把业务模型描述得更清晰。再分析和表述业务内容和流程后再给出用例图。2.1用例建模2.1.1参与者和用例通过先找外部环境的参与者，再通过找参与者需要的功能、参与者需要知道的消息以及系统内部需要的维护、设置等功能，确定的参与者和用例如下。本系统的参与者为顾客、商家和职员。顾客、商家和职员与用户之间是继承关系。所有用户均可以执行注册、登录、个人信息管理、话题广场管理和交互管理等操作。顾客可以执行搜索商品、购物车管理、提交订单、优惠卡办理和评价等操作。商家可以执行商品管理、仓库管理、销售管理、订单管理、售后处理和店铺信息管理等操作。职员可以执行广告发布、公告发布和消费者保护等操作。图图2-1京北网上购物系统顶层用例图用户可以根据自己的需要修改账号密码；身份认证，用于提升账号的安全性和信任级别，认证后的有商家记录的账号不能修改认证信息；设置安全保护邮箱，不同于登录邮箱，当用户选择“安全保护问题”找回密码时，填写正确的问题答案后，系统会将新密码发到用户的安全邮箱；设置手机绑定，绑定手机后，用户即可享受京北丰富的手机服务，如手机登录，手机找回密码、开通手机动态密码等。图图2-2京北网上用户用例图顾客把所需的商品加入购物车，后进入到查看购物车页面，显示购物车中所有商品名称、数量、单价、金额、积分、优惠、以及总价，可以修改商品的数量、删除商品、清空购物车等；选定商品或加入购物车完毕，即可进入提交订单状态，成功，便可执行确认订单信息收货地址、确认订单信息（数量，送货方式、顾客留言）、配置付款方式等操作；购买商家的商品以后，给出评分；只要成功购买过商家的商品，就有可能获得该商家的会员卡，会员卡可以打折，商家可以通过设定会员卡标准将顾客设定为高级会员，VIP会员或者至尊VIP会员。图图2-3京北网上购物系统顾客用例图待交易状态为“顾客已付款”，可以根据顾客留下的收货地址联系快递公司进行发货，待货物发出后，需要在发货页面填写正确的发货信息，交易状态将更改为“商家已发货”，待顾客收到货物确认打款给商家后，商家的支付宝账户就会收到该笔交易的款项，双方也就完成该笔交易，如顾客未主动操作确认付款给商家，且也未在交易超时打款之前申请退款，那么等交易超时后，系统将自动打款给商家；在未发货状态下点击“同意退款申请”，同意退款，并填写支付密码、在已发货状态下点击“同意退款申请”，选择“同意顾客退款协议”，并选择退货地址（必选）、或者在顾客退货后同意退款协议点击“同意退款”，并填写支付密码可退款成功；绑定的支付宝账户已经通过实名认证，商家可以点击我是商家，我要卖，选择商品类目，编辑商品信息，进行商品的发布；商家可以点击我是商家，仓库里的商品，待您处理的违规商品，查看被下架的违规商品，如果这些违规商品已经被您重新编辑并上架，则会在出售中的商品显示，如已删除，则不会再显示。图图2-4京北网上购物系统商家用例图职员可以分别对没有如实描述、假一赔三、30天维修、7天退换等情况进行处理，以对消费者进行保护。把“假一赔三”改为“赔偿管理”把“假一赔三”改为“赔偿管理”图图2-5京北网上购物系统职员用例图2.1.2用例优先级注：为了便于比较，仅描述顶层用例图的用例优先级。优先级数值越低表明该用例优先级越高。用例优先级往往与用例功能所涉及到的进程优先级和用例开发的安排有关，此处的优先级给得很随意。用例优先级往往与用例功能所涉及到的进程优先级和用例开发的安排有关，此处的优先级给得很随意。用例名称用例概述用例优先级搜索商品按某种条件搜索特定商品。0商品管理增加、删除、修改商品等。1个人信息管理设置、修改个人信息等。2提交订单顾客提交订单信息以生成订单请求。3订单管理接受顾客订单请求、查询所有订单信息等。4售后处理订单结束后，处理顾客发起的退换货等请求。5购物车管理查看购物车、加入购物车、修改购物车等。6话题广场管理发布话题、发布帖子、回复帖子、查看帖子等。7交互管理用户发出消息，与其他用户进行实时交互。8仓库管理商品上架、查询卖完商品、违规处理等。9销售管理特定时间段采用特殊策略进行销售。10店铺信息管理设置店铺信息、修改店铺信息等。11注册为不同目的登录系统的用户注册为不同的角色。12登录用户进入系统时验证用户身份。13评价订单结束后，顾客对商品做出评价。14优惠卡办理顾客提交订单时的优惠处理。15消费者保护职员对处于不同情况的消费者采取不同的保护方式。16广告发布在页面侧栏进行广告发布以达到宣传的目的。17公告发布将平台的特殊情况公告给每个用户。182.1.3关键用例1提交订单用例生成订单用例描述用例名称：生成订单用例编号：001用例简述：顾客选好商品后发起生成订单请求。基本事件流：（1）顾客将商品加入购物车后，点击生成订单。（2）系统进行结算，选择支付方式进行付款。（3）付款成功，生成订单信息。主要参与者：顾客前置条件：顾客成功进入购物车业务功能界面。后置条件：系统向商家发送提醒信息，当前交易状态更改为“顾客已付款”。查看订单用例描述用例名称：查看订单用例编号：002用例简述：在订单生成后，顾客查看订单信息。基本事件流：（1）顾客进入查看订单信息界面。（2）系统显示该用户提交订单的最新详细信息。主要参与者：顾客前置条件：顾客成功进入查看订单信息业务功能界面。后置条件：界面显示订单最新详细信息。取消订单用例描述用例名称：取消订单用例编号：003用例简述：顾客在订单状态变更之前取消订单。基本事件流：（1）顾客在查看订单信息界面点击取消订单。（2）订单被取消，删除该订单相关信息。主要参与者：顾客前置条件：顾客成功进入查看订单信息业务功能界面。后置条件：将该订单信息在商家的订单列表中删除。修改订单用例描述用例名称：修改订单用例编号：004用例简述：顾客在订单状态变更之前修改订单。基本事件流：（1）顾客在查看订单信息界面点击修改订单。（2）顾客在修改订单信息界面重新输入需要修改的订单信息。（3）顾客重新输入订单信息完毕后点击确定。（4）系统根据重新提交的订单信息更新订单信息，自动刷新查看订单信息界面。主要参与者：顾客前置条件：顾客成功进入查看订单信息业务功能界面。后置条件：将该订单信息在商家的订单列表中更新。2售后处理用例退货处理用例描述用例名称：退货处理用例编号：005用例简述：顾客发起退货请求。基本事件流：情况一，若商品状态为“未发货”：（1）顾客在查看订单信息界面点击退货。（2）第三方支付系统直接退款。（3）第三方支付系统通知商家退款信息，商家修改商品状态。情况二，若商品状态为“已发货”：（1）顾客在查看订单信息界面点击退货。（2）顾客提交退货订单和退货相关信息（运费哪方支付等）给第三方支付系统。（3）第三方支付系统再发送给商家，商家是否接受退货相关信息。（4）商家不接受则继续协商；商家接受则顾客在指定地点寄出商品，商家收到顾客的商品并确认退货处理，第三方支付系统自动把付款退回顾客。主要参与者：顾客、商家前置条件：顾客成功进入查看订单信息业务功能界面。后置条件：将该订单信息更新。3话题广场管理用例查看帖子用例描述用例名称：查看帖子用例编号：006用例简述：用户发起查看帖子请求。基本事件流：（1）用户进入话题广场，选择感兴趣的某一话题。（2）用户点击该话题下的某篇帖子。（3）系统显示该被选中帖子的详细信息。主要参与者：用户前置条件：用户成功进入话题广场业务功能界面。后置条件：界面显示被选中帖子的详细信息。发布帖子用例描述用例名称：发布帖子用例编号：007用例简述：用户发起发布帖子请求。基本事件流：（1）用户进入话题广场，选择感兴趣的某一话题。（2）用户点击发布帖子。（3）用户输入要发布的帖子内容，点击发布。（4）系统显示最新发布的帖子信息。主要参与者：用户前置条件：用户成功进入话题广场业务功能界面。后置条件：界面显示最新发布的帖子信息。删除帖子用例描述用例名称：删除帖子用例编号：008用例简述：用户发起删除帖子请求。基本事件流：（1）用户进入自己发布的且需要删除的一篇帖子。（2）用户点击删除帖子。（3）系统删除该帖子的相关信息。主要参与者：用户前置条件：用户成功进入话题广场业务功能界面。后置条件：将该帖子信息删除。评论帖子用例描述用例名称：评论帖子用例编号：009用例简述：用户发起评论帖子请求。基本事件流：（1）用户进入选择感兴趣的某一帖子。（2）用户点击发布评论。（3）用户输入要发布的评论内容，点击发布。（4）系统显示最新发布的评论信息。主要参与者：用户前置条件：用户成功进入话题广场业务功能界面。后置条件：界面显示最新发布的评论信息。2.2补充规约2.2.1非功能性需求性能：响应快——该系统需要能在用户请求后的500ms内做出响应，及时地反馈结果给用户，不能让用户长时间等待。如果某些功能确实需要较长时间返回结果，则应考虑将其分拆成更小的功能模块，或者在界面该部分内容与《1.6.1质量属性》部分重复。系统愿景部分属于需求分析部分的内容建议移到需求分析部分。该部分内容与《1.6.1质量属性》部分重复。系统愿景部分属于需求分析部分的内容建议移到需求分析部分。高可靠：该系统需要支持高并发，并且能稳定运行，不能因为各种原因轻易崩溃。该系统需要在99.9%的时间内保持可用状态，最多只允许每月1小时的不可用时间。高安全：考虑到网上购物系统与用户的私密息息相关，该系统必须具有很强的安全性。主要体现在以下几个方面：数据库中的数据加密存储，不能被轻易篡改，且保持有多份备份，定期更新；系统能防御常见的网络攻击和入侵，如DDOS攻击、SQL注入攻击等；系统运行时需要保存运行日志，便于发现问题后及时处理。合规性：该系统需要遵守各种法律法规的要求，不能逾越制度红线。2.2.2约束开发过程约束：要求本软件系统开发方要组建一支专业的开发团队，在客户现场进行开发。运行环境及技术约束：为节省软件运行、维护的成本，要求未来软件运行环境尽量采用开源软件。交付及部署约束：要求必须在三个月内完成开发。部署时要利用客户已有的硬件资源，包括web服务器和数据库服务器。2.3术语表读者可能不熟悉用例描述或其他项目文档，术语表用于定义该问题域的术语。通常，这个表格可以用作非正式的数据字典，捕获数据定义，以便用例描述和其他项目文档可以关注系统必须处理的信息。术语定义顾客在本系统中注册、登录，并且可能在本系统购买商品的对象。商家网上销售商品的对象，可以上架下架商品，可以调整商品价格，可以查看订单信息。账号用户登录本系统的唯一标识，在本系统中用手机号或邮箱号作为注册、登录账号。商品商家上传到平台网店的实物信息或者虚拟货物。商品信息对商品的详细说明，包括商品的价格和折扣、商品的规格、商品适用范围或者使用方法等详细信息。购物车用来给顾客存储商品，顾客可以通过对购物车的操作来满足自己对商品的管理需求。在购物车中，顾客可以修改商品数量、删除商品等。原金额购买的商品原价格的总金额，没有减去优惠、折扣的金额加上邮费。实付金额购买的商品经过优惠价、折扣的处理后得到的金额，加上邮费（有可能免邮邮费）。支付系统现行网络上拥有金融牌照且有合作关系的网络支付系统。商品评价指的是顾客收到商品之后，通过使用对比商品之后，对自己主观感受的表达，同时评价的内容有助于帮助其他顾客更好了解商品。3面向对象分析模型建议增加状态图，使主要对象的状态变化过程更清晰。例如：订单状态图。建议增加状态图，使主要对象的状态变化过程更清晰。例如：订单状态图。3.1业务建模建议给出业务模型和详细的业务说明，包括业务内容和业务流程，可利用活动图表达业务模型。建议给出业务模型和详细的业务说明，包括业务内容和业务流程，可利用活动图表达业务模型。3.1.1上下文描述“京北”网上购物商城系统的店铺售卖商品和用户购买商品2条服务主线展开所涉及到的类的上下文：1.店铺售卖商品：商城里有店铺，店铺里有商家卖的各种商品，店铺有自己已成交的相关订单记录。2.用户购买商品：商城里有注册的用户，顾客有一个属于自己的购物车，购物车里有顾客考虑购买的商品。顾客有自己已提交的相关订单记录，订单记录里有用户购买的商品。用户有自己发起的供交流的消息队列。商城里有话题，各话题下有用户关于购买体验的帖子，帖子下有评论。3.1.2识别类从3.1.1上下文中，识别出可能用作类的名词或名词短语，下面列表展示筛选出的类：名称解释商城一个网上购物平台。店铺供应商品或服务的虚拟场所。商品被销售的产品或服务。订单记录买方需求的交易记录。用户使用该系统购物的人。购物车虚拟的存放商品的容器。消息记录用户交流内容的地方。话题用户在平台上交流讨论的主题。帖子用户在平台上发布的一篇文章。评论对某篇帖子表达的意见。3.1.3类间关系的确定通过对系统进行分析得各类之间关系有：商城有多家店铺，是一对多的聚合关系；店铺可以有一个或多个商品，是一对多的聚合关系；店铺接受零个或多个订单，是一对多的关联关系。商城有零个或多个用户，是一对多的聚合关系；一个用户确定唯一购物车，是一对一的关联关系；购物车可以有零个或多个商品，是一对多的聚合关系。用户下可以有零个或多个订单，是一对多的关联关系；一个订单可以仅购买一个商品，也可以同时购买多个商品，是一对多的聚合关系。用户可以发起零个或多个消息队列，是一对多的关联关系。商城有零个或多个话题，是一对多的聚合关系；话题下发布零个或多个帖子，是一对多的聚合关系；帖子下发布零个或多个评论，是一对多的组合关系。3.1.4类图对类的成员和属性应更加明确、细化。对类的成员和属性应更加明确、细化。类图以反映类的结构(属性、操作)以及类之间的关系为主要目的，描述了软件系统的结构，是一种静态建模方法。下图是从项目的业务功能抽象出的“京北”网上购物商城系统的类图。图图3-1京北网上购物系统的类图3.2分析层——职责确定及分配UML将职责定义为分类器的契约或义务—由元素（如类或子系统）提供的knowing或doing的服务或服务组。关于软件对象和大型组件的设计，一种流行的思考方式是从职责、角色和协作的角度来考虑，也就是职责驱动设计RDD。在RDD中，职责与对象在其角色方面的的义务或行为相关。将职责分配给对象的基本原则是：将职责分配给拥有完成该职责所需信息的类。所以我们可以先确定职责，再由职责驱动确定完成该职责所需的概念类，是对从业务模型筛选出的类的一个验证。CRC代表Class-Responsibility-Collaborator。CRC卡每个类一个，显示其职责以及它必须与哪些其他类协作才能履行每个职责。下面就用各CRC卡片展示在“京北”网上购物商城系统中的职责确定及其分配给各类的情况。类名：商城协作者：用户店铺话题职责：注册登录类名：用户协作者：订单商品店铺职责：个人信息管理广告发布公告发布消费者保护类名：话题协作者：商城用户帖子评论商品店铺职责：话题广场管理类名：消息协作者：用户店铺职责：交互管理类名：商品协作者：店铺用户职责：搜索商品商品管理类名：购物车协作者：用户商品职责：购物车管理类名：订单协作者：用户店铺商品职责：提交订单优惠卡办理类名：店铺协作者：订单商品用户职责：评价仓库管理销售管理订单管理售后处理店铺信息管理3.3分析层——关键用例实现用例实现描述某个用例基于协作对象如何在设计模型中实现。用例实现是UP术语，用以提示我们在表示该段文字可删除。为用例的需求和满足需求的对象之间的联系。该段文字可删除。分析类代表了“系统中具有责任和行为的事物”的早期概念模型。分析类主要处理功能需求，它们从业务模型中获取建模对象。一个系统有三个方面可能会发生变化：1.系统与其参与者之间的边界；2.系统的使用信息；3.系统的控制逻辑。为了隔离系统中将发生变化的部分，不同类型的分析类被标识为一组“固定”的职责：边界类—界面和系统外事物之间的中介；实体类—系统的关键抽象；控制类—用例行为协调器。实体类需要从业务模型中筛选出的分析类实现全覆盖，控制类不仅决定了参与用例实现的实体类，还决定了实体类之间的关系，是对从业务模型筛选出的类及其之间关系的验证。3.3.1提交订单用例实现1分析类挖掘边界类：在提交订单用例中，只有顾客会与系统发生交互，在分析模型的构造中，其是独立于设计模型和最后实现的。故而，在此使用提交订单页面类来抽象顾客与系统交互的图形界面或者浏览器页面。控制类：代表了一个特定用例的控制器，一般来说，在分析模型阶段，由这个控制类实现与它绑定的用例所有的业务逻辑控制，如果业务逻辑过于复杂，在构建分析模型的后期或者构建设计模型的前期可以将其分化为多个控制类。在此用例中，提交订单类就被赋予控制类的职责。实体类：代表了系统中各个模块之间流动数据信息的抽象。每一个实体类的实例都代表和抽象了一个实物的存在。根据生活常识，不难得出，顾客在提交订单时肯定要接触的实体有：商品、购物车、订单和店铺。所以，根据这些实体，在系统中分别设计了其相对应的实体类来代表系统中关于这些实体信息的抽象。分析类类名解释边界类提交订单页面顾客在该页面发起提交订单请求。控制类提交订单由该控制类转去执行相应的提交订单操作。实体类商品被销售的产品或服务。购物车虚拟的存放商品的容器。订单记录买方需求的交易记录。店铺供应商品或服务的虚拟场所。2分析类间关系确定可分析得各分析类之间关系有：顾客使用的提交订单页面只有一个，而控制类也只需一个，如果需要考虑并发控制，那么只在控制类中加以实现即可，所以提交订单页面边界类和提交订单控制类，是一对一的关联关系。同一个控制类可能要同时处理同一个用户的不同商品、不同用户的购物车和订单以及将订单推送给不同的店铺，所以提交订单控制类与商品、购物车、订单及店铺实体类，是一对多的关联关系。购物车可以有零个或多个商品，是一对多的聚合关系；一个订单可以仅购买一个商品，也可以同时购买多个商品，是一对多的聚合关系；店铺可以有一个或多个商品，是一对多的聚合关系；店铺接受零个或多个订单，是一对多的关联关系。3结构类图以反映类的结构以及类之间的关系为主要目的，下面就用分析类图展示对该用例中各分析类间结构的分析。图图3-2提交订单用例实现分析类图4交互我们可以分析出整个提交订单过程的业务流程为：（1）顾客由提交订单页面边界类通知提交订单控制类获取所有商品信息，提交订单控制类控制商品实体类从数据库中获取这些信息，将这些信息交付给提交订单页面边界类显示给顾客。（2）顾客选中一件商品后，由提交订单页面边界类通知提交订单控制类获取这件商品的详细信息，提交订单控制类控制商品实体类从数据库中获取这件商品的详细信息，将其交付给提交订单页面边界类显示给顾客。（3）顾客由提交订单页面边界类通知提交订单控制类添加欲购买的商品信息到购物车，提交订单控制类控制购物车实体类在数据库中增加这些商品的信息。（4）顾客由提交订单页面边界类通知提交订单控制类提交订单，提交订单控制类控制提交订单页面边界类向顾客收集订单信息，提交订单控制类控制订单实体类在数据库中增加收集的订单信息。（5）提交订单控制类控制店铺实体类在数据库中增加收集的订单信息，将这些信息交付给提交订单页面边界类显示给商家。系统顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序，下面就用系统顺序图展示对该用例中各分析类间交互的分析。图图3-3提交订单的顺序图5操作说明操作CO1：获取所有商品信息操作：获取所有商品信息（）交叉引用：用例：提交订单前置条件：顾客成功登入了该系统，进入提交订单页面。后置条件：顾客页面显示所有商品信息。操作CO2：获取意向商品信息操作：获取意向商品信息（商品：商品）交叉引用：用例：提交订单前置条件：顾客成功登入了该系统，进入提交订单页面。后置条件：顾客页面显示意向商品信息。操作CO3：加入购物车操作：加入购物车（商品：商品）交叉引用：用例：提交订单前置条件：顾客成功登入了该系统，进入提交订单页面。后置条件：购物车数据库表中增加了选中的商品信息。操作CO4：提交订单操作：提交订单（订单：订单）交叉引用：用例：提交订单前置条件：顾客成功登入了该系统，进入提交订单页面。后置条件：基于顾客提交的订单信息，更新了商家的显示页面。3.3.2售后处理用例实现1分析类挖掘边界类：在售后处理用例中，顾客、商家都会与系统发生交互，在分析模型的构造中，其是独立于设计模型和最后实现的。故而，在此使用售后处理页面类来抽象用户与系统交互的图形界面或者浏览器页面。控制类：代表了一个特定用例的控制器，一般来说，在分析模型阶段，由这个控制类实现与它绑定的用例所有的业务逻辑控制，如果业务逻辑过于复杂，在构建分析模型的后期或者构建设计模型的前期可以将其分化为多个控制类。在此用例中，售后处理类就被赋予控制类的职责。实体类：代表了系统中各个模块之间流动数据信息的抽象。每一个实体类的实例都代表和抽象了一个实物的存在。根据生活常识，不难得出，用户在售后处理时肯定要接触的实体有：订单、商品、店铺、用户和消息。所以，根据这些实体，在系统中分别设计了其相对应的实体类来代表系统中关于这些实体信息的抽象。分析类类名解释边界类售后处理页面用户在该页面发起售后处理请求。控制类售后处理由该控制类转去执行相应的售后处理操作。实体类订单记录买方需求的交易记录。商品被销售的产品或服务。店铺供应商品或服务的虚拟场所。用户使用该系统购物的人。消息记录用户交流内容的地方。2分析类间关系确定可分析得各分析类之间关系有：用户使用的售后处理页面只有一个，而控制类也只需一个，如果需要考虑并发控制，那么只在控制类中加以实现即可，所以售后处理页面边界类和售后处理控制类，是一对一的关联关系。同一个控制类可能要同时处理同一个用户的不同商品、不同用户的订单以及对应的不同的店铺，所以售后处理控制类与订单、商品及店铺实体类，是一对多的关联关系。店铺可以有一个或多个商品，是一对多的聚合关系；店铺接受零个或多个订单，是一对多的关联关系；一个订单可以仅购买一个商品，也可以同时购买多个商品，是一对多的聚合关系；用户下可以有零个或多个订单，是一对多的关联关系；用户可以发起零个或多个消息队列，是一对多的关联关系。3结构类图以反映类的结构以及类之间的关系为主要目的，下面就用分析类图展示对该用例中各分析类间结构的分析。图图3-4售后处理用例分析类图4交互整个售后处理过程的业务流程为：（1）顾客由售后处理页面边界类通知售后处理控制类退货处理，售后处理控制类控制商品实体类从数据库中获取商品状态信息。（2）若商品状态为“未发货”，售后处理控制类控制订单实体类在数据库中修改订单信息，将其交付给售后处理页面边界类显示给顾客，售后处理控制类控制商品实体类在数据库中修改商品状态信息、控制店铺实体类在数据库中修改店铺接受的订单信息，将其交付给售后处理页面边界类显示给商家。（3）若商品状态为“已发货”，售后处理控制类控制售后处理页面边界类向顾客收集退货相关信息，售后处理控制类控制订单实体类在数据库中增加收集的退货相关信息，将这些信息交付给售后处理页面边界类显示给商家。顾客由售后处理页面边界类通知售后处理控制类与商家发送消息进行协商，售后处理控制类控制店铺实体类和用户实体类从数据库中获取创建消息队列需要的信息、控制消息实体类在数据库中增加新创建的消息队列信息，将这些信息交付给售后处理页面边界类显示给顾客和商家。商家同意退货后，由售后处理页面边界类通知售后处理控制类同意退货处理，售后处理控制类控制订单实体类在数据库中修改订单信息，将其交付给售后处理页面边界类显示给顾客，售后处理控制类控制商品实体类在数据库中修改商品状态信息、控制店铺实体类在数据库中修改店铺接受的订单信息，将其交付给售后处理页面边界类显示给商家。系统顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序，下面就用系统顺序图展示对该用例中各分析类间交互的分析。图3-5图3-5售后处理顺序图5操作说明操作CO5：获取商品状态信息操作：获取商品状态信息（商品ID：Integer）交叉引用：用例：售后处理前置条件：顾客成功登入了该系统，进入售后处理页面。后置条件：顾客页面显示商品状态信息。操作CO6：修改订单信息操作：修改订单信息（订单：订单）交叉引用：用例：售后处理前置条件：顾客成功登入了该系统，进入售后处理页面。后置条件：基于顾客提交的退货相关信息，更新了顾客的显示页面。操作CO7：修改商品状态信息操作：修改商品状态信息（商品：商品）交叉引用：用例：售后处理前置条件：顾客成功登入了该系统，进入售后处理页面。后置条件：商品数据库表中的该商品状态信息被更新。操作CO8：修改店铺接受的订单信息操作：修改店铺接受的订单信息（订单：订单）交叉引用：用例：售后处理前置条件：顾客成功登入了该系统，进入售后处理页面。后置条件：基于顾客提交的退货相关信息，更新了商家的显示页面。操作CO10：增加收集的退货相关信息操作：增加收集的退货相关信息（订单：订单）交叉引用：用例：售后处理前置条件：顾客成功登入了该系统，进入售后处理页面。后置条件：基于顾客提交的退货相关信息，更新了商家的显示页面。操作CO11：与商家发送消息操作：与商家发送消息（消息：消息）交叉引用：用例：售后处理前置条件：顾客成功登入了该系统，进入售后处理页面。后置条件：消息数据库表中增加了新创建的消息队列信息，更新了顾客和商家的显示页面。3.3.3话题广场管理用例实现1分析类挖掘边界类：在话题广场管理用例中，只有用户会与系统发生交互，在分析模型的构造中，其是独立于设计模型和最后实现的。故而，在此使用话题广场管理页面类来抽象用户与系统交互的图形界面或者浏览器页面。控制类：代表了一个特定用例的控制器，一般来说，在分析模型阶段，由这个控制类实现与它绑定的用例所有的业务逻辑控制，如果业务逻辑过于复杂，在构建分析模型的后期或者构建设计模型的前期可以将其分化为多个控制类。在此用例中，话题广场管理类就被赋予控制类的职责。实体类：代表了系统中各个模块之间流动数据信息的抽象。每一个实体类的实例都代表和抽象了一个实物的存在。根据生活常识，不难得出，用户在话题广场管理时肯定要接触的实体有：话题、帖子和评论。所以，根据这些实体，在系统中分别设计了其相对应的实体类来代表系统中关于这些实体信息的抽象。分析类类名解释边界类话题广场管理页面用户在该页面发起话题广场管理请求。控制类话题广场管理由该控制类转去执行相应的话题广场管理操作。实体类话题用户在平台上交流讨论的主题。帖子用户在平台上发布的一篇文章。评论对某篇帖子表达的意见。2分析类间关系确定可分析得各分析类之间关系有：用户使用的话题广场管理页面只有一个，而控制类也只需一个，如果需要考虑并发控制，那么只在控制类中加以实现即可，所以话题广场管理页面边界类和话题广场管理控制类，是一对一的关联关系。同一个控制类可能要同时处理不同用户的话题、评论及帖子，所以话题广场管理控制类与话题、评论及帖子实体类，是一对多的关联关系。话题下发布零个或多个帖子，是一对多的聚合关系；帖子下发布零个或多个评论，是一对多的组合关系。3类的结构类图以反映类的结构以及类之间的关系为主要目的，下面就用分析类图展示对该用例中各分析类间结构的分析。图图3-6话题广场管理分析类图4交互我们可以分析出整个话题广场管理过程的业务流程为：（1）用户由话题广场管理页面边界类通知话题广场管理控制类获取所有话题信息，话题广场管理控制类控制话题实体类从数据库中获取所有话题信息，将这些信息交付给话题广场管理页面边界类显示给用户。（2）用户选中一个话题后，由话题广场管理页面边界类通知话题广场管理控制类获取这个话题的详细信息，话题广场管理控制类控制帖子和评论实体类从数据库中获取这个话题的所有帖子及其评论信息，将其交付给话题广场管理页面边界类显示给用户。（3）用户由话题广场管理页面边界类通知话题广场管理控制类发布帖子，话题广场管理控制类控制话题广场管理页面边界类向用户收集帖子信息，话题广场管理控制类控制帖子实体类在数据库中增加收集的帖子信息，将这些信息交付给话题广场管理页面边界类显示给用户。系统顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序，下面就用系统顺序图展示对该用例中各分析类间交互的分析。图图3-7话题广场管理顺序图5操作说明操作CO12：获取所有话题信息操作：获取所有话题信息（）交叉引用：用例：话题广场管理前置条件：用户成功登入了该系统，进入话题广场管理页面。后置条件：用户页面显示所有话题信息。操作CO13：获取选中话题信息操作：获取选中话题信息（话题：话题）交叉引用：用例：话题广场管理前置条件：用户成功登入了该系统，进入话题广场管理页面。后置条件：用户页面显示选中话题信息。操作CO14：发布帖子操作：发布帖子（帖子：帖子）交叉引用：用例：话题广场管理前置条件：用户成功登入了该系统，进入话题广场管理页面。后置条件：基于用户提交的帖子信息，更新了用户的显示页面。4面向对象设计模型完整的设计文档应包括部署设计、用户界面的设计、数据库设计等。该文档作为一个案例，读者可参看系统分析、设计主要达到什么目的；需求分析和设计方案如何表达、描述。一个实际系统的需求分析和设计文档比该案例文档要更加细致、全面。该文档案例的目的是使读者了解需求分析和设计要完成哪些工作、需求分析和设计文档怎么写。完整的设计文档应包括部署设计、用户界面的设计、数据库设计等。该文档作为一个案例，读者可参看系统分析、设计主要达到什么目的；需求分析和设计方案如何表达、描述。一个实际系统的需求分析和设计文档比该案例文档要更加细致、全面。该文档案例的目的是使读者了解需求分析和设计要完成哪些工作、需求分析和设计文档怎么写。设计阶段的任务是精化方案并开发一个明确描述方案的可视化模型，保障设计模型最终能平滑地过渡到该段文字可删除程序代码。设计活动回答“该怎么做”的问题，工作的重点是适应特定的实施环境和部署环境。设计的核心是规划方案的构造，在揭示实施细节的基础上得到方案的详细对象模型。

该段文字可删除4.1架构设计架构是一组重要决策，其中涉及软件系统的组织，对结构元素及其组成系统所籍接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构（这些元素及其接口、协作和组成）的架构风格。层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。同时，层按照“较高”层可以调用“较低”层的服务，而反之则不然的方式组织。总的来说，使用层可以做到关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离，也即是层可以减少耦合和依赖性、增强内聚性、提高潜在的复用性并且使概念更加清晰。基于以上分析，对于“京北”网上购物商城系统的逻辑架构我们选用层次架构。分层架构决定了层与层之间的组织，同时我们需要对每层确定使用的框架，以此来决定每层的对象及其之间的组织，确定对象之间发送消息即交互的机制机理。这里我们将整个系统分为三层，分别是表现层、业务层及持久化层。前端采用Layui框架，后端采用ssm框架，具体为前端表现层采用Layui框架、后端表现层采用SpringMVC框架、业务层采用Spring框架、持久化层采用Mybatis框架。前、后端使用ajax+json进行交互，即前端表现层通过ajax将相应的方法传递到后端表现层，后端表现层获取前端表现层请求并将数据反馈给前端表现层，处理后的数据显示在前端页面上反馈给用户。表现层：负责处理用户界面和用户输入输出的逻辑，将用户的请求发送到下一层。图图4-1京北网上购物系统架构的表现层业务层：负责处理系统主要的功能和业务逻辑。层与层之间的依赖是向下的，在分层设计时，遵循了面向接口设计的思想，在不改变接口定义的情况下，本系统有良好的可替换性及可复用性。主要逻辑通过service接口规定，有较低的耦合性，系统进行二次迭代时可通过替换增强功能，满足开闭原则。图图4-2京北网上购物系统架构的业务层持久化层：负责对数据的访问，本系统是对数据库的访问。系统采用OR映射的方式，将实体对象映射为表，从而达到对表的操作。通过dao接口规定逻辑，降低耦合性。图图4-3京北网上购物系统架构的持久化层总体逻辑架构：图图4-4京北网上购物系统总体架构图4.2用例设计基于以上分层架构和每层所使用的框架，将面向对象分析阶段关键用例实现里的边界类细化，但更多的是控制类的按层分解，实体类及其关系变化也不会太大。4.2.1提交订单用例设计1结构因为在分析阶段职责确定及分配时我们将提交订单职责分配给了订单类，加之上述确定的分层架构及每层使用的框架，所以在此可将分析阶段的一个提交订单控制类按层分解为订单Controller、订单Service、订单Dao。类图以反映类的结构以及类之间的关系为主要目的，下面就用设计类图展示对该用例中各类间结构的分析。图图4-5提交订单设计类图2交互这里以提交订单（订单：订单）操作为例描述各类之间的交互：顾客填写完订单信息后，点击“提交订单”按钮时，系统通过订单Controller中的提交订单（订单：订单）方法将顾客所填写的订单信息传递给订单Service接口，进而调用订单ServiceImpl中的提交订单（订单：订单）方法，订单ServiceImpl具体实现订单Service接口；然后订单ServiceImpl又将信息传递给订单Dao接口，调用订单DaoImpl中的提交订单（订单：订单）方法，订单DaoImpl具体实现订单Dao接口，系统通过订单DaoImpl这个类与数据库进行交互，将顾客填写的订单信息增加到数据库中。系统顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序，下面就用系统顺序图展示对该用例中各类间交互的分析。图图4-6提交订单模块的顺序图4.2.2售后处理用例设计1结构因为在分析阶段职责确定及分配时我们将售后处理职责分配给了店铺类，加之上述确定的分层架构及每层使用的框架，所以在此可将分析阶段的一个售后处理控制类按层分解为店铺Controller、店铺Service、店铺Dao。类图以反映类的结构以及类之间的关系为主要目的，下面就用设计类图展示对该用例中各类间结构的分析。图图4-7售后处理模块的顺序图2交互这里以增加收集的退货相关信息（订单：订单）操作为例描述各类之间的交互：顾客点击“退货处理”按钮时，系统通过店铺Controller中的增加收集的退货相关信息（订单：订单）方法将顾客所填写的退货相关信息传递给店铺Service接口，进而调用店铺ServiceImpl中的增加收集的退货相关信息（订单：订单）方法，店铺ServiceImpl具体实现店铺Service接口；然后店铺ServiceImpl又将信息传递给店铺Dao接口，调用店铺DaoImpl中的增加收集的退货相关信息（订单：订单）方法，店铺DaoImpl具体实现店铺Dao接口，系统通过店铺DaoImpl这个类与数据库进行交互，将顾客填写的退货相关信息增加到数据库中。系统顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序，下面就用系统顺序图展示对该用例中各类间交互的分析。图图4-8售后处理模块的顺序图4.2.3话题广场管理用例设计1结构因为在分析阶段职责确定及分配时我们将话题广场管理职责分配给了话题类，加之上述确定的分层架构及每层使用的框架，所以在此可将分析阶段的一个话题广场管理控制类按层分解为话题Controller、话题Service、话题Dao。类图以反映类的结构以及类之间的关系为主要目的，下面就用设计类图展示对该用例中各类间结构的分析。图图4-9话题广场管理用例实现设计类图2交互这里以发布帖子（帖子：帖子）操作为例描述各类之间的交互：用户填写完帖子信息后，点击“发布帖子”按钮时，系统通过话题Controller中的发布帖子（帖子：帖子）方法将用户所填写的帖子信息传递给话题Service接口，进而调用话题ServiceImpl中的发布帖子（帖子：帖子）方法，话题ServiceImpl具体实现话题Service接口；然后话题ServiceImpl又将信息传递给话题Dao接口，调用话题DaoImpl中的发布帖子（帖子：帖子）方法，话题DaoImpl具体实现话题Dao接口，系统通过话题DaoImpl这个类与数据库进行交互，将用户填写的帖子信息增加到数据库中。系统顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序，下面就用系统顺序图展示对该用例中各类间交互的分析。图图4-10话题广场管理用例实现系统顺序图4.3子系统设计子系统实际上是一种特殊的包，这种包仅具有作为公有元素的接口。这些接口提供了一个封装层，从而使其他模型元素看不到子系统的内部设计。子系统这一概念用于将它和“普通”包区分开来：“普通”包是无语义的模型元素容器；而子系统则表示具有与类相似的（行为）特征的包的特定用法。是否从一组协作分析类中创建子系统，这在很大程度上取决于该协作是否可由单独的设计团队来独立开发。如果协作与协作类可完全包含在一个包中，子系统就可提供比简单包更有效的封装形式。子系统中的内容和协作被一个或多个接口完全隔离起来，因此子系统的客户只能依赖于接口。这样，子系统的设计人员就完全脱离了外部依赖关系；虽然设计人员（或设计团队）需要指定接口的实现方式，但他们可以充分自由地更改子系统的内部设计，而不会影响外部依赖关系。在相当独立的团队所开发的大型系统中，这种程度的隔离和由正式接口所提供的架构执行一同有力证明了应选择子系统而不应选择简单包。总之，子系统设计就是把会变化的、功能类似的功能区内聚起来形成一个子系统，将其与系统的稳定部分隔离开来，以降低系统的耦合性、增加复用性。4.4类的设计前面的设计是类外部的，现在进行最细的设计，即类内部的设计——为类增加属性和方法。图图4-11类的详细设计图5精化设计与模式应用5.1创