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

“京北”网上购物商城项目需求与设计文档批注[D1]:该文档作为•个案例，读者可参看系统分

析、设计主要达到什么目的；需求分析和设计方案如

何去伙、描述.一人实际系统的需求分析和渺计文档

比该案例文档要更加细致、全面，该文档案例的目的

足使读者了解需求分析和设计要完成哪些工作、需求

分析和设汁文档应包括什么内容.实际项目中需求和

设计文档的撰写要求非常严格,内容要全面、表述准

确。

该文档的设计部分K包含详细设计。

1系统愿景.................................................................................4

1.1概述...............................................................................4

1.2定位..............................................................................4

1.2.1问题描述....................................................................1

1.2.2项目定位.....................................................................1

1.3用户概述及目标....................................................................4

i.3.1用户概述....................................................................4

1.3.2目标........................................................................4

1.3.3用户环境...................................................................

1.4项日说明.........................................................................

1.5系统特性..........................................................................

1.5.1关键特性...................................................................

1.5.2其他特性...................................................................

1.6其他新求和约束...................................................................

1.6.1质量属性..................................................................

1.6.2约束......................................................................

2需求分析.................................................................................8

2.1用例建模..........................................................................8

2.1.1参与者和用例................................................................8

2.1.2用例优先级.................................................................13

2.1.3关混用例...................................................................13

2.2补充规约.........................................................................16

2.2.1非功能性需求...............................................................16

2.2.2约束.......................................................................16

2.3术语表...........................................................................16

3面向对象分析模型........................................................................17

3.1业务建模..........................................................................17

3.1.1上下文描述..................................................................17

3.1.2识别类.......................................................................17

3.1.3类间关系的确定..............................................................17

3.1.4类图........................................................................18

3.2分析层一一职责照定及分配.........................................................18

3.3分析层一一关键用例实现...........................................................20

3.3.1提交订单用例实现..........................................................20

3.3.2传后处理用例实现..........................................................23

3.3.3话MS广场管理用例实现......................................................26

4面向对软设计模型........................................................................29

4.1架构设计.........................................................................29

4.2用例设计.........................................................................32

4.2.1提交订单用例设计............................................................32

4.2.2售后处理用例设计............................................................34

4.2.3话即广场管理用例设计........................................................35

4.3子系统设计........................................................................36

4.4类的设计..........................................................................37

5精化设计与模式应用......................................................................38

5.1创建型模式........................................................................38

5.1.1单例模式...................................................................38

5.1.1工厂方法模式...............................................................38

5.2结构型模式.......................................................................39

5.2.1门面模式...................................................................39

5.2.2适配黑模式.................................................................40

5.3行为型模式.......................................................................41

5.3.1观察者模式..................................................................41

5.3.2状态模式....................................................................42

5.3.3策略模式....................................................................43

1系统愿景

1.1概述

在科技匕速发展的今天，互联网已日益成为提供信息的最佳渠道并逐步进入传统的演通领域.只依赖

线卜专•卖店韬伟的模式跟不上时代进步•几P所有的传统行业都面临向信息时代转型的扬战.民众的购买

习惯也在渐渐地朝若“配送到户：随时、自由购买”的方向发展.网络明物在“实地消战、网络卜单”的

基础上依界网络极大地丰富了两品销售行业的服务手段.充分利用了互联网“时效性强、客户淋普及”的

特点.增加了利润的来源空间，扩大了受利祥体。

1.2定位

1.2.1问题描述

“京北”网上购物商城系统，该系统致力于满足用户能享受商品及时配送等多元化优需求,提升用户

的使用体验，给更多的商家提供机会,使其利用线上销佬的模式拓展自身的业务范国.

1.2.2项目定位

“京北”网上购物商城系统效力丁•用科技打造人们的生活服务平台,推动商品销售行业的数字化进程。

它能解决传统商品线下购买难计算、难杳找、难更改、易出错、效率低等问咫，为用户提供便捷的服务和

极致的体验，为店铺提供•体化的运营方案,系统面向大众群体，覆盖了当前购物系统值基本功能，并在

此暴础上进行了优化，为用户提供更丰富与更贴心的使用体验。

1.3用户概述及目标

1.3.1用户概述

该系统的主要用户为全球范国内的登录者，具体包括顾客、商家、职员等，其中，顾客可以进行购物、

订单信息管理、收藏管理、修改个人信息、举报投诉等操作，商家可以进行商品信息管理、订单信息管理、

举报投诉管理、交流论坛管理等操作。

1.3.2目标

该系统的短期目标为占据中国及周边国家的网上购物系统市场，长远目标为占据全洋网上购物系统中

场.

1.3.3用户环境

PC端推荐使用*nd”s、Linux系统，用户可以根据自己的需要选择，没有特殊的平台限制.手机端

APP支持Android4.0以上及ios8以上的任何手机系统.

财务人员喜欢使用Excel等工具来处理财务事务，他们布里能幡方便、快把他查看和导出订单数据、

销售数据以及其他相关的财务数据.希望该系统能鲂提供荷洁明了的报表功能，支持导出数据为Excel格

式.方便进行数据分析和处理.商家希望能够轻松管理和监控自己的店铺和商品销售情况,希望能终实时

查看店铺的访客流量、订单量以及销售额等关键指标,并可以方便地对商品迸行上下架、价格调整等操作.

同时,他们也希望能够及时收到订单和处理退换货的申请等通知：

L4项目说明____________________________________批注[D2]:1.4标题改为“项目需求说明”

该系统的用户主要分为三类，分别为：顿客、商家和职员。顾客通过账号登陆系统国台，可以执行购

物、收藏管理、修改个人信息、举报投诉等徽作，并可以杳看订单信息、个人信息、购修车信息等内容，批注[D3]:该段中对顾客、商家、职员需求的说明与

商孝通过账号登陆系统.可以执行商4梏总管理.订单怙息管理.举报投诉管理等操作,同时可以通过娱“用户概述部分重空”用户概述部分可以移到项目说

统查询店铺信息、商品信息、订单信息等内容.职员可以执行广告发布、公告发布、消费者保护等操作.明部分，单列一个三级标题-

该系统可与其他外部系统进行交互，例如：通过微信、QQ等第三方登录系统进行身份验证登录该系统：从

第三方支付系统进行订单支付：从第三方文件系统查看和导出特定格式的订单数据、植但数据以及其他相

关的财务数据等,方便进行数据分析和处理。

京北网上购物商城系统语境图

图1-1京北网上购物系统语境图

该系统由众多的功能模块构成,如商品铐理、订单管理、购物车管理等，高我功能模块并不是固定的,

而是可以根据实际M要进行增删，具有充分的灵活性。

部分功能模块介绍：

商品管理：商品信息的增、删、改查等.

评价管理：进行商品评价等.

购物年管理：添加商品到购物车、从购物车中移出商品等。

批注[D4]:因为该图只是描述了该系统可能只行

的功能模块，并不表示拓扑关系。所以图名为“拓

京北网上购物系统功能结构图

扑结构图”不妥，改为“功能构成图”

图1-2京北网上购物系统功能结构图

1.5系统特性

1.5.1关键特性

商品搜索和过滤：提供高效的搜索功能，支持关犍词搜索，也支持商从分类、价格范围等多种过灌方

式，帮助用户快速找到所需商品。

个性化推荐引擎：基于用户的方史购买记录、浏览行为和偏好，提供个性化的商品指荐，增加购买转

化率.

社交互动।话题广场允许用户发表关于美食、长厅、出行、本地生活等主题的帖子,与其他用户互动.

分享经脸和建议.

1.5.2其他特性批注[D5]:该段对各种特性的说明不够明确、详细.

美观性：该系统的界面由众多专业的美工人员设计，且听取了部分用户的建议，对界面布局等进行了

专门优化.计划使用Element-ui界面开发工具，Element-ui•囊括了众多小巧美观的组件，可开发出灵动

而荏有现代气息的界面.

易用性：考虑到使用系统的用户遍布各个年龄段且认知水平不同,需要进行易用性设计.界面设计人

员分析了不同用户的常用功能.并将它们放置在界面的主要区域,从而做到了一点即达.减少不必要的操

作.不同类别用户的界面因功能不同略有差别,均应做到简洁易用.此外，界面应提供白天/夜间模式切换、

长辈关怀模式等功能，充分考虑不同用户人样的需要。

完备性：在设计系统时，充分考虑了用户的各种功能诉求，据此构建出功能完备的系统。该系统可以

满足用户的各种商求，并且还将根据情况变化不断完善丰富。

灵活性：考虑到不同地区不同国家旭物诉求不发相同，系统功能模块间的摘合度较低，可以根据实际

褥要进行功能模块的削战，以满足实际的需宴.此外，系统采用前后端分离的模式开发，便于进行灵活的

调整维护.

1.6其他需求和约束

1.6.1质量属性

性能：响应快一一核系统需要能在用户请求后的500m内做出响应，及时地反馈结果给用户，不能让

用户长时间等待。如果某些功能嘀实需要较长时间返I可结果，则应考虑将其分拆成更小能功能模块，或者

在界面的醒目位置适时给予用户梃示，告知当前事务的处理情况.页面加载快一核系统需要能在■内加载

完成所需页面，以保证用户体验.高吞吐毋一该系统支持每秒处理，谓个并发请求.

高可靠：该系统需要支持高并发,并且能稳定运行，不能因为各种原因轻易崩溃.该系统需要在99.9%

的时间内保持可用状态.最多只允许每月1小时的不可用时间.

高安全：考虑到网上购物系统与用户的弘密息息相关,该系统必须具有很强的安全主要体现在以

下几个方面：数据库中的数据加密存储.不能被轻易®i改.且保持有多份备份.定期更新：系统能防御常

见的网络攻击和入侵，如DDOS攻击、SQL注入攻击等；系统运行时需要保存运行口忠，使,发现问题后及

时处理，

合规性：该系统需要遵守各种法律法规的要求，不能逾越制度红线。

1.6.2约束

开发过程约束：要求本软件系统开发方要组建一支专业的开发团队，在客户现场进行开发，

运行环境及技术约束：为节省软件运行、维护的成本，要求未来软件运行环境尽量采用开源软件.

交付及部署约束：要求必须在三个月内完成开发.部归时要利用客户已有的硬件资源，包括wob服务

器和数据库服务器.

批注[D6]:该部分建议增加活动图,把业务模型描述

2需求分析得更清晰。再分析利表述业务内容和流程后再给出用

例图。

2.1用例建模

2.1.1参与者和用例

通过先找外部环境的参与者，再通过找参与者需要的功能、参与者需要知道的消息以及系统内部需要

的维护、设设等功能，确定的参与者和用例如下。

本系统的参与者为顾客、商家和职员•顾客、商家和职员与用户之间是淮承关系，所有用户均可以执

行注册、登录、个人信息管理'话题广场管理和交互管理等操作.顾客可以执行搜索商品、购物车管理、

提交订单、优惠卡办理和评价等操作.商家可以执行商品管理、仓库管理、销售管理、订单管理、售后处

理和店铺信息管理等操作.职员可以执行广告发布、公告发布和消费者保护等掾作.

图2-1京北网上购物系统顶层用例图

用户可以根据自己的需要修改账号冷码：身份认证，用于提升此号的安全性和信任级别，认证后的有商家

记录的账号不能修改认证信息：设置安全保F回；箱,不同于登录邮箱.当用户选择“安全保护何胭”找回

密码时.填写正确的问趣答案后,系统会将所需码发到用户的安全眦箱：设置手机绑定.绑定手机后，用

户即可享受京北丰富的手机服务,如手机登录，手机找回密码、开通手机动态密码等.

图2-2京北网上用户用例图

顾客把所需的商品加入购物车.后进入到查看购物车页面.品示购物车中所有两品名称、数量、单价、金

额、积分、优惠、以及总价，可以修改商品的数房、删除商品、清空购物车等；选定商品或加入购物车完

毕,即可进入提交订单状态，成功，便可执行确认订单信息收货地址、确认订单信息（数量,送货方式、

政客留言）、配置付款方式等操作：购买商家的商品以后，给出评分；只要成功购买过蔺家的商M,就有

可能获褥该商家的会员卡，会员卡可以打折，商家可以通过设定会员卡标准将顾客设定为苞级会员，YIP会

员或者至尊YIP会员.

图2-3京北网上购物系统顾客用例图

待交易状态为“顾客已付款”，可以根据顾客留下的收货地址联系快递公司进行发货,牯货物发出后，需

要在发货页面填写正确的发货信息，交易状.虫将更改为“商家已发货”,待顾客收到货修确认打款给商家

后，商家的支付宝账户就会收到该笔交％的就项.双方也就完成该笔交易，如顾客未主动掾作确认付款给

商家.且也未在交易超时打款之前卬请退款.那么等交易超时后，系统将自动打软给商家：在未发货状态

下点击”同意退款申请”,同意退款,并填爰支付密码、在己发货状态下点击“同意退款中请”，选择“同

意顾客退款协议”，并选择退货地址（必选，、或者在顾客退贪后同意退款降议点击“同意退款”，并填

写支付密码可退款成功；绑定的支付宝账户已经通过实名认证，商家可以点击我是商家，我要卖，选择商

品类目，编辑商品信息，进行商品的发布；商家可以点击我是商家，仓库里的商品，待您处理的违规商品，

查看被下架的违规商从，如果这些违规商M已经被您重新编辑并上架，则会在出售中的商品显示，如已删

除,则不会再显示.

商家用例图

«extend»

询卖完商显〉

z«extend»

v・・・・・・・・■,•・••

/G犀管…

//«extend»

规处座二）

京

«extend»

商家、…………CD

«extend*

\

有史〉

«extend*

一,•••..

\\df—!5—>.

…《j薮贮）

Uj.信息管理二〉

图27京北网上购物系统商家用例图

职员可以分别对没有如实描述、假一赔三、20天维脩、7天退换等情况进行处理，以对消费者进行保护。

批注［D7］：把“假•赔三”改为“赔偿管理”

图25京北网上她物系统职员用例图

2.1.2用例优先级

注：为了便于比较，仅描述顶层用例图的用例优先级.优先级数值越低表明该用例优先级越高。批注［D8］：用例优先级往往与用例功能所涉及到的进

1用例名称

用例概述用例优先级程优先级和用例开发的安排有关，此处的优先级给得

搜索商品按某种条件搜索特定商品。0很随遨.

丽品管理增加'删除,修改商品等01

个人信息管理设置、修改个人信息等，2

提交订单顾客提交订单信息以生成订单请求.3

订单管理接受顾客订，1请求、杳询所有订单信息等。4

件后处理订单结束后，处理顾客发起的退换货等请求.5

购物车管理查看购物车,加入购物车、修改前物车等.6

话题广场管理发布话题、发布帖子、回复帖子、查看帖子等.7

交互管理用户发出消息，与其他用户进行实时交互。8

仓库管理商品上架、查询卖完商品、违规处理等，9

铜竹管理特定时间段采用特殊策略进行销售。10

店铺信息管理设置店铺信息、修改店福信息等.11

注册为不同目的登录系统的用户注册为不同的角色。12

登录用户进入系统时验证用户身份。13

评价订单结束后,顾客对商品做出评价.14

优惠卡办理顾客提交订单时的优惠处理，15

消费者保护职员对处于不同情况的消费者采取不同的保护方16

式。

广告发布在页面侧栏进行广告发布以达到立传的目的。17

公告发布将平行的特殊情况公告给每个用户.18

2.1.3关键用例

1提交订单用例

•生成仃单用例描述

用例名称：生成订单

用例编号：001

用例简述：顾客选好商品后发起生成订用请求.

基本事件流：

（1）顾客将商品加入购物车后,点击生成订单。

（2）系统进行结算,选择支付方式进行付款.

<3）付款成功，生成订单信息。

主要参。者，顾客

前置条件：顾客成功进入购物车业务功能界面。

后置条件：系统向商家发送提醒信息，当前交易状态更改为“限客已付款”。

•查看订单用例描述

用例名称：查看订单

用例编号：002

用例筒述：在订单生成后，晚客查看订用信息.

基本事件流：

（1）顾客进入查看订单信息界面，

（2）系统显示该用户提交订单的批新详细信息。

主要参与者：顾客

前置条件：蜿,客成功进入直看订的信息业务功能界面。

后置条件：界面显示订单最新详细信息，

•取消订单用例描述

用例名称：取消订单

用例编号：003

用例筒述，顾客在订单状态变更之前取消订单.

基本事件流：

（1）顾,客在查看订单信息界面点击取消订单。

（2）订单被取消,删除该订单相关信息。

主要参与者：顾客

前置条件：顾客成功进入查看订单信息业务功能界面.

后置条件：将该订单信息在商家的订单列表中用除。

•修改订单用例描述

用例名称:修改订单

用例编号：004

用例筒述：顾客在订单状态变更之前修改订单.

基本事件流：

（1）顾客在查看订单信息界面点击修改订单.

（2）顾客在修改订单信息界面重新输入需要修改的订单信息。

（3）顾客重新输入订单信息完毕后点击确定。

<1）系统根据柬新提交的订单信息更新订单信息，自动刷新杳看订单信息界面。

主要参与者：顾客

前置条件：顾客成功进入立布I丁单怡息叱务功能界面.

后置条件：将该订单信息在商家的订单列表中更新.

2售后处理用例

•退货处理用例描述

用例名称:退货处理

用例编号：005

用例简述：㈣客发起退货请求。

基本事件流：

情况若商M状态为“未发货”：

<1）顾客在查看订单信息界面点击退货，

（2）第三方支付系统直接退款，

（3）第三方支付系统通知商家退款信息.商家修改商品状态.

情况二，若商品状态为“已发货”：

（1）顾客在查看订单信息界面点击退货.

（2）顾客提交退货订单和退货相关信息（话费哪方支付等）给笫三方支付系统。

（3）笫三方支付系统再发送给商家,商家是否接受退货相关信息。

（4）商家不接受则堪续协商；商家接受则顺容在指定地点寄出商品,商家收到顾客的商品笄确认退货处理,

第三方支付系统自动把付款退回顾客.

主要参与者：顾客、商家

前置条件：顾客成功进入查看订单信息业务功能界面.

后置条件：将该订单信息更新。

3话题广场管理用例

•杳看帖子用例描述

用例名称：查看帖子

用例编号：006

用例筒述：用户发起查否帖子请求.

基本事件流：

（1）用户进入活膻广场,选择感兴趣的某一话题.

（2）用户点击该话题卜的某篇帖子.

（3）系统显示该被选中帖子的详细信息.

主要参与者：用户

前置条件：用户成功进入话即广场业务功能界面，

后置条件：界面显示被选中帖子的详细信息，

•发布帖子用例描述

用例名称:发布帖子

用例编号：007

用例简述：用户发起发布帖子请求.

基本事件流：

（1）用户进入话膻广场,选择感兴趣的某一话题.

（2）用户点击发布帖子.

<3）用户输入要发布的帖子内容，点击发布。

（4）系统显示城新发布的帖子信息。

主要参与者:用户

前置条件：用户成功进入话题广场业务功能界面，

后置条件：界面显示最跖发布的帖/伯恩。

•删除帖子用例描述

用例名称：删除帖子

用例编号:008

用例简述।用户发起删除帖子请求.

基本事件流：

<1）用户进入自己发布的IL需要删除的,篇帖子。

（2）用户点击删除帖子.

（3）系统删除该帖子的相关信息.

主要参与者：用户

前置条件：用户成功进入话曲广场业务功能界面.

后置条件：将该帖子信息则除.

•评论帖子刖例描述

用例名称：评论帖子

用例编号:009

用例筒述：用户发起评论帖子请求。

基木事件流：

（1）用户进入选择感兴趣的某一帖子.

（2）用户点击发布评论.

（3）用户输入要发布的评论内容，点击发布。

<4）系统显示最新发布的评论信息。

主要参与者：用户

前置条件：用户成功进入话82广场业务功能界面，

后置条件：界面显示最新发布的评论信息，

2.2补充规约

2.2.1非功能性需求

性能：响应快一一该系统制要能在用户谙求后的500ms内做出响应，及时地反馈结果给用户，不能让

用户长时间等待，如果某些功能确实痛要较长时间返回结果，则应考虑将其分拆成更小住功能模块，或普

在I界面的88目位置适时给予用户提示,告知当前事务的处理情况.页面加费快——该泵统需要能在2s内加批注［D9J:该部分内容与《1.6.1质疑属性3部分

就完成所需页面，以保证用户体验，高吞吐后——该系统支持句秒处理1000个并发请求，IfiS.系统愿景部分间于需求分析部分的内容建设移

高可靠：该系统需要支持高并发，并且能稳定运行,不能因为各种原因轻易崩溃.该系统需要在99.9%到需求分析部分.

的时间内保持可用状态.最多只允许每月1小时的不可用时间.

高安全：考虑到网上购物系统与用户的乱密息息相关，该系统必须具有很强的安全伯.主要体现在以

卜.几个方面：数据库中的数据加格存储・不能被轻易篡改,且保持有多份备份•定期更新：系统能防御常

见的网络攻击和入侵，如DDOS攻击、SQL注入攻击等：系统运行时需要保存运行日志，使,发现问题后及

时处理，

合规性：该系统需要遵守各种法律法规的要求，不能遭越制度红线。

2.2.2约束

开发过程约束：要求本软件系统开发方要组建一支专业的开发团队，在客户现场进行开发。

运行环境及技术约束：为节省软件运行、维护的成本，要求未来软件运行环境尽砒采用开源软件.

交付及部署约束：要求必须在三个月内完成开发.部署时要利用客户已有的硬件资源，包括wob服务

器和数据库服务器.

2.3术语表

读者可能不熟悉用例描述或其他项目文档,术语表用于定义该问题域的术语.通常，这个表格可以用作非

正式的数据字典,捕获数据定义,以便用例描述和其他项目文档可以关注系统必须处理的信息.

术语定义

顾客在本系统中注册、登录,并且可能在本系统购买商品的对象.

商家网上销仰商品的对象，可以上架下架商品，可以调整商品价格，可以杳若订单信息。

账号用户登录本系统的唯一标识,在本系统中用手机号或邮箱号作为注册.登录账号.

商品商家上佚到平台网店的实物信息或者虚拟货物。

商品信息对商品的详细说明，包括商品的价格和折扪、商品的规格、商品适用范国或者使用方法

等详细信息。

购物车用来给顾客存储商品，顾客可以通过对购物车的操作来满足自己对商品的管理需求.在

购物车中，顾客可以修改商品数量、删除商品等.

原金额购买的商品原价格的总金领，没有减去优惠、折扣的金额加上邮费，

实忖金就峋买的商品鲜过优惠价、折扣的处理后用到的金颛.加1•加甜（有可邰中邮加物）.

支付系统现行网络1:拥有金融牌照且有合作关系的网络支付系统。

商品评价指的是顾客收到商品之后，通过使用对比商品之后，对自己主观感受的麦达，同时评价

的内容有助于帮助其他顾客更好了解商品.

批注[D10]:建议增加状态图，使主要对象的状态变

3面向对象分析模型化过程更清晰.例如:订单状态图.

批注[DU]:建议绘出业务模型和详细的业务说明.

3.1业务建模

包括业务内容和业务流程,可利用活动图表达业务模

型。

3.1.1上下文描述

“京北”网上购物商城系统的店铺件实幅吊和用户购买商品2条服务主线展开所涉及到的类的上下文：

1.店铺令实商品：商城里有店铺，店铺里有商家卖的各种商品,店铺有自己己成交的相关订单记录，

2.用户购买商品：商城里有注册的用户，顾客有一个以于自己的购物车，购物车里有顾客考虑购买的商品。

顾客有自己已提交的相关订单记录，订单记录里有用户购买的商品。用户有自己发起的供交流的消息队列。

商城里有话题，各话SS下有用户关于购买体驶的帖子，帖了•下台评论，

3.1.2识别类

从3.1.I上下文中，识别出可能用作类的名句或名何也培，下面列表展示临选出的类:

名称解释

商城一个网上购物平台。

店铺供应商品或服务的虚疚场所。

商品被销隹的产品或服务，

订单记录买方需求的交易氾录.

用户使用该系统购物的人，

购物车康拟的存放商品的容隅.

消息记录用户交流内容的地方。

话题用户在平台上交流讨论的主跑.

帖子用户在平台上发布的一篇上章，

评论时枭篇帖子表达的意地.

3.1.3类间关系的确定

通过对系统进行分析得各类之间关系有:

商城有多家店铺・是一对多的聚合关系：店桶可以有一个或多个商品.是一对多的聚合关系：店铺接受零

个或多个订单，是一对多的关联关系.

商城有零个或多个用户,是一对多的聚合关系：一个用户确定唯一购物车.是一对一的关联关系：购物车

可以有零个或多个商品，是一对多的聚合关系,用户下可以有零个或多个订单，是一对多的关联关系：

个订单可以仅购买一个商品，也可以同时购买多个商品，是一对多的聚合关系。用户可以发起零个或多个

消息队列，是•对多的关联关系,商城有零个或多个话题，是•对多的聚合关系；话题下发布零个或多个

帖子，是•对多的聚合关系：帖了•下发布零个或多个评论，是•对多的组合关系。

批注对类的成员和属性应更加明确、细化。

3.1.4类图[D12]:

类图以反映类的结构（属性、操作）以及类之间的关系为主要H的.描述了软件系统的结构,是一种静

态建模方法.卜图是从项目的业务功能抽象出的“京北”网上购物商城系统的类图.

3.2分析层一职责确定及分配

UML将职选定义为分类器的契约或义务一由元素（如类或子系统）提供的knowing或doing的服务或

服务组.

关于软件对象和大型组件的设计，一种流行的思考方式是从职贡、角色和协作的角度来考虑.也就是职责

驱动设计RDD.在RDD中.职贡与对象在其用色方面的的义务或行为相关。将职责分配给对象的基本原则

是：将职费分配给拥有完成该职责所需信息的类。所以我们可以先确定职员，再由职责盟动确定完成该职

责所需的概念类，是对从业务模型筛选出的类的一个验证。

CRC代友Class-ResponsibilityYollaborator.CRC卡每个类•个，显示其职击以及它必须与哪些其他类

孙作才能履行每个职贡。

下面就用各CRC卡片展示在“京北”网上购物商城系统中的职费确定及其分配给各类的情况,

类名：商城■

［类名：用户

协作者：

职费：•订单

•个人信息管理•商品

•广告发布•店铺

•公告发布

•消费者保护

［类名：话题

协作者：

职责:•商城

•话曲广场管理•用户

•帖子

•评论

•商品

•店铺

1类名：消息

1类名：商用

;类名：购物车_

■

类名:订单■

3.3分析层——关键用例实现

用例实现描述某个用例基于协作对象如何在设计模型中实现，用例实现是IP术语，用以提示我们在展

示为用例的遁求和满足麟段同象物的联叁___________________________________________________批注[D13]:该段义字可删除。

分析类代表了“系统中具有送任和行为的事物”的早期概念模型。分析类主要处理比熊需求，它们从

业务模型中获取建模对象.一个系统有三个方面可能会发生变化：L系统与其参与者之何的边界：2.系统

的使用信息：3.系统的控制逻耕.为了聃离系统中将发生变化的部分，不同类型的分析类被标识为一组“固

定'’的职责：边界类一界面和系统外事物之间的中介：实体类一系统的关键抽象：控制类一用例行为协调

器.

实体类需要从业务模型中筛选出的分析类实现全覆盖•控制类不仅决定了参与用例实现的实体类,还

决定了实体类之间的关系，是对从业务模型箭选出的类及其之间美系的脍证。

3.3.1提交订单用例实现

1分析关挖房

边界类：在提交仃单用例中，只有顾客叁与系统发生交互，在分析模型的构造中，其是独立于设计模

型和最后实现的，故而，在此使用提交订单页面类来抽象政客与系统交互的图形界面或者浏览怒页而，

控制类：代表了一个特定用例的控制器，一般来说，在分析模型阶段，山这个控牺类实现与它绑定的

用例所有的业务逻辑控制，如果业务逻辑过于红杂，住构建分析模型的后期或者构建设计模型的前期可以

将其分化为多个控制类.在此用例中.提交订单类就被赋予控制类的职责.

实体类：代表了系统中各个模块之间流动数据信息的抽收.每一个实体类的实例都代表和抽您了一个

实物的存在.报据生活常识,不难得出，顾客在提交订单时省定要接触的实体有：商品、购物车、订单和

店铺。所以,报据这些实体，在系统中分别谀计了其相对应的实体类来代表系统中关于这些实体信息的抽

象。

1分析类类名解择

边界类提交订单页面顾客在该页面发起提交订单请求。

控制类提交订单由核控制类转去执行相应的提交订单搽作。

实体类商品被销俗的产品或服务。

购物车虚拟的存放商品的容潴，

订单记录买方需求的交易记录.

店铺供应商品或IK务的虚拟场所，

2分析类间关系确定

可分析得各分析类之间关系有：

助客使用的提交订单页面只有一个.而控制类也只需一个.如果需要考虑并发控制.那么只在控制类中加

以实现即可.所以提交订单页面边界类和提交订单控制类,是一对一的关联关系。同一个控制类可能要同

时处理同一个用户的不同商品、不同用户的购物乍和订单以及将订单推送给不同的店铺，所以提交订单控

制类与商品、购物车、订单及店铺实体类，是一对多的关联关系。啊物下可以有零个或多个商品，是•对

多的聚合关系：一个订单可以仅购买•个商而，也可以同时购买多个商M,是一对多的聚合关系；店铺可

以有一个或多个商船，是一•对多的聚合关系：店铺接受零个或多个订单，是一对多的关联关系。

3结构

类图以反映类的结构以及类之间的关系为主要目的.下面就用分析类图展示对该用例中各分析类间结

构的分析.

提交订单用例实现分析类图

图3-2提文订单用例实现分析类图

4交互

我们可以分析出整个提交订单过程的业务流程为：

（1）顾客由提交订单页面边界类通知提交订单控制类获取所有商品信•息，提交订单控制类控制商品实体类

从数据库中获取这些信息,将这叫信息交付给提交订单页面边界类显示给顾客。

（2）顾客选中一件商品后，由提交订单页面边界类通知提交订单控制类获取这件商品的详细信息•提交订

的控制类控制商品实体类从数据库中获取这件商品的详细信息,将其交付给提交订单页面边界类显示给顾

客.

（3）顾客出提交订单页面边界类通知提交订单控制类添加欲购买的商品信息到购物乍，提交订版控制类控

制购物车实体类在数据库中增加这些商品的信息。

（4）顾客由提交订单页面边界类通知提交订单控制类提交订单，提交订单控制类控制提交订单页面边界类

向顾客收集订单信息，提交订单控制类控制订单实体类在数据库中加加收集的订单信息。

（5）梃交订单控制类控舸店铺实体类在数据库中增加收集的订单信息，将这些信息交付给提交订单页面边

界类显示给商家.

系统顺序图主要反映了系统中各个类，模块或者角色之间，交互方法的先后调用次序,下面就用系统

顺序图展示对该用例中各分析类间交互的分析.

图3-3提交订单的顺序网

5操作说明

操作COh获取所有商品信息

操作：获取所有商品信息O

交叉引用：用例：提交订单

前置条件：顾客成功登入了该系统，进入提交订单页面.

后置条件I顾客页面显示所有商品信息.

操作C02：获取意向商品信息

操作：获取意向商品信息（商品：商品：

交叉引用：用例；提交订单

前置条件：顾客成功登入了该系统，进入提交订单页面。

后置条件：顾客页面显示意向商M信息，

操作C03：加入购物车

操作：加入购物车（商品:商品）

交叉引用，用例：提交订单

前置条件：顾'客成功登入了该系统,进入提交订单•页面.

后置条件：购物车数据库表中增加了选中的商品信息，

操作C04：提交订单

操作：提交订单（订单：订单）

交叉引用：用例:提交订单

前置条件：顾客成功登入了该系统，进入提交订单页面.

后置条件：基于顾客提交的订单信息，更新了商家的显示页面.

3.3.2售后处理用例实现

1分析类挖去

边界类：在竹后处理用例中，顾客、商家都会与系统发生交互，在分析模型的构造中，其是独立于设计模

型和最后实现的，故而，在此使用件后处理页面类来抽象用户与系统交互的图形界面或者浏览器页面。

控制类：代表了•个特定用例的控制器，•般来说，在分析模型阶段，由这个控制类实现与它绑定的用例

所有的业务逻辑控制，如果业务逻辑过于复杂，在构建分析模型的后期或