Peanut

使用Postman测试API接口

2019-06-29T00:00:00+00:00

在后端开发过程中，常常有需要测试API接口能否正常工作的需要。前端也常常需要测试APiece接口的返回结果，和文档中两相对照。传统的命令行API测试工具curl输入繁琐，无法保存请求历史以及在较难一连串的请求中保持cookie，并且返回结果不够清晰。使用图形化工具 Postman 可以情形明了的展示API的工作以及返回情况，同时具备了小组协作、保存历史以及脚本执行的功能。

开始

Postman 的界面非常简单命令。在搜索引擎搜索并进入官网下载。安装、注册后进入使用界面。

使用界面非常清晰。您可以在上图标号1处选择要测试的请求方法，在标号2处输入请求的url，点击标号3处以发送请求。当使用POST等方法，需要添加 Request body的时候，您可以点击标号4处，在标号5所示的地方填写JSON数据对应的key-value对。同时，标号6处的Save可以持久化的储存该请求于您的账号中，而标号7处的请求历史则可以看到本地近些天的请求内容，单击即可加载。

生成请求集合

当您需要测试一系列接口时，首先点击上图1处导航栏的collection项目，并点击标号2处 “New collection”。之后输入该集合的名称及描述后直接点击Create即可。

右键单击生成的 Collection，即标号 3 处，点击 Add Request。

输入Request的名称描述后点击 Save To…，即可在该 collection 下看到新的请求。点击该请求，按照 “开始” 中所述更改请求信息，并点击Save，即可保存到 collection 中。

生成测试脚本

使用 Postman 可以方便生成API测试脚本。上手容易，并且在脚本执行过程中会保存cookie。

在 collection中输入好请求的URL并按顺序调整好，如将“登出”设置到“登陆”的URL之后，右键该collection，单击Export，生成Json文件，即测试脚本。

在测试目录通过 node.js 安装 postman 脚本测试工具 newman，您可以根据需求选择 –g –save等参数,：

$ npm install -g newman

要运行脚本文件，输入：

$ newman run mycollection.json

即可由 newman 工具自行执行您创建的测试脚本，并且会将测试结果显示在控制台。

Team work

小组协作使用 Postman，减轻了前后端沟通压力，省去了每个人各自创建Request的麻烦。推荐使用。

如图，当组长想要创建 Postman 工作小组时，选择页面最上方的My Workspace，在弹出窗口中点击 Team，并点击 Create a team workspace。

在该界面中，填入您要邀请人的账号对应的E-mail（或仅仅时E-mail，该用户点击邮件后再进行注册和登陆）。

进入Teamspace后，再按照上述步骤生成API测试和测试脚本即可。

Reference

Postman docs

提高团队协作效率

2019-06-27T00:00:00+00:00

这是我第一次参加这样一个过程相对完善规范、持续时间相对较长的项目。在项目过程中，我发现如下团队协作工具可以有效提高团队工作效率：

Github Issues

仓库的Issue在这里不仅可以提出疑问，也可用于前后端交流窗口。前后端有Bug或需要什么接口时，如果在社交媒体沟通很容易就被大量的消息刷过去了。使用Issue并标明优先级等是一种合理的沟通方式。

另一方面，Issue还可用于分发细分的任务。比如某个组件的开发、某个逻辑的完善，使用Issue更简单明了，相关问题也可以在Issue中更新回复。

腾讯 / 石墨文档

使用Github更新Readme或API接口文档时常常会出现同时编辑的情况，那么在Merge时不慎就会出现Conflicts。使用腾讯文档在线协同编辑时所有用户看到的界面都是一样的，即它是实时更新的。虽然腾讯文档不能用于编辑Markdown，在编写用户手册等doc文档时十分方便。

Git Bash SSH

使用Git bash自带的ssh功能，小组成员均可连接服务器进行部署等操作。

对服务器的数据库使用SSH做转发后，即使不是服务器的拥有者也可以查看、编辑云端数据库信息。

Linux Screen命令

使用Screen命令可以同时连接多个本地或远程的命令行会话，并在其间自由切换。

GNU Screen是一款由GNU计划开发的用于命令行终端切换的自由软件。

假如后端增加了ssl与前端链接，那么在本地测试后端就是不可行的了，除非也申请一个ssl证书。但是团队开发过程中后端的小组成员经常有测试或查看log的需求，那么通过ssh链接到服务器后，服务器管理者再为他们分别开不同的screen即可测试。

Reference：

Linux Screen命令详解

SWSAD 自我总结

2019-06-27T00:00:00+00:00

自我总结

在本项目中我担任的工作是市场调研以及后端工程师。这是我第一次以一个相对严谨的工作小组和工作流程完成一个项目。我在本项目参与的直接开发时间持续六周以上，于3个月前发布问卷并开始市场调研，我们小组举行会议、设计时间频繁并且很早就开始。这是一个时长较长、规范虽然仍不合格但已在慢慢完善的开发项目，我在这个过程中学到了很多东西。

PSP 2.1 统计表

PSP2.1	Personal Software Process Stages	Time (%)
Planing	计划	1
Estimate	估计这个任务需要多少时间	1
Development	开发	94
Analysis	需求分析	10
Design Spec	生成设计文档	4
Design Review	设计复审	0
Coding Standard	生成代码规范	0
Design	具体设计	10
Coding	具体编码	60
Code Review	代码复审	10
Test	测试	3
Reporting	报告	5
Test Report	测试报告	0
Size Measurement	计算工作量	1
Process Improvement Plan	事后总结及改进计划	4

Git统计报告

Server 部分：

Dashboard部分：

最得意的工作清单

后端实现：本次项目是我第一次完整的参与项目后端的构建，在大佬的帮助下我们的server实现的很棒。耦合度很低，鲁棒性强，基本的业务逻辑后端几乎全部实现。虽然我花了大量的时间Debug，还是一次很好的code体验！
市场调研 & 竞品报告：我花费了大量的时间去思考问卷的设计，并费心在市场上寻找了大量的竞品APP进行比对，最终选择了几个最具有借鉴意义的竞品。

个人博客清单

https://peanutadi.github.io/2019/06/25/swsad-market/

https://peanutadi.github.io/2019/06/26/swsad-nodejs/

致谢

特别感谢盘学之@flyingmanPan 带躺。本小组所有成员工作积极，有过争执但最终呈现的产品质量非常高，大家都辛苦了。

koa学习记录

2019-06-26T00:00:00+00:00

后端小白从零开始之路

Koa

第一次接触到node.js框架，在这之前从来没用node.js编程…好在同组大佬全程手把手指导开发。 Koa框架拥有很强的兼容性，可以使用node和express的组件，使得开发方便并且弹性强。同时Koa具有轻量化的特点，使用async函数，错误处理简洁。

洋葱模型

Koa没有绑定中间件执行，但提供了大量的可选中间件并使用堆栈结构进行函数调用。当级联的下游没有更多的中间件时，堆栈展开且每个中间件执行其上游行为。有大神称其为洋葱模型：使用官网代码作为例子：

var koa = require('koa');
var app = koa();

// response-time中间件
app.use(function *(next){
  var start = new Date;
  yield next;
  var ms = new Date - start;
  this.set('X-Response-Time', ms + 'ms');
});

// logger中间件
app.use(function *(next){
  var start = new Date;
  yield next;
  var ms = new Date - start;
  console.log('%s %s - %s', this.method, this.url, ms);
});

// 响应中间件
app.use(function *(){
  this.body = 'Hello World';
});

app.listen(3000);

那么，请求过程就是：请求进来，先进到response-time中间件，执行 var start = new Date; 然后遇到yield next，则暂停response-time中间件的执行，跳转进logger中间件，同理，最后进入响应中间件，响应中间件中没有yield next代码，则开始逆序执行，也就是再先是回到logger中间件，执行yield next之后的代码，执行完后再回到response-time中间件执行yield next之后的代码。至此，整个Koa的中间件执行完毕。

Context

Koa的Context对象将节点的请求和响应对象封装到单个对象中，该对象为编写Web应用程序和API提供了许多有用的方法。每个请求都将创建一个 Context，并在中间件中作为接收器引用，或者 ctx 标识符。可以通过ctx.requeset对象获得请求, ctx.request.body是处理POST请求时常用的API。 ctx.statue可以用于返回状态码。 ctx.body可以用于返还给client的实体。

架构设计

这次的项目采用一个完全API化的后端,因为所有前端的页面设计都是承载在微信小程序上,故后端不需要解决静态文件的推送,只需要处理各种逻辑的处理,如管理用户,管理订单,管理任务。这样的架构就能顺理成章地让某个逻辑的代码落到某个类的的 controller 中,而这个 controller 暴露出其路由,由上层的初始化层进行综合和启动,并插入一些中间件去处理。而 controller 中只包含了每个API所需要的逻辑处理函数,而部分不和API产生直接关联的函数或者中间件,如数据库的初始化,钱包的操作函数,验证请求的 Session 的中间件,这些都放在了对应的 helper 中,这样避免了逻辑混乱和导致非公开函数被恶意调用，同时也实现了后端的解耦。

MongoDB

MongoDB是我第一次使用的NoSQL，并且安装、使用都十分方便。 NoSQL在使用时不用考虑表格的问题，作为一个数据库设计不那么有经验的团队，我们可能常有属性的增添，MongoDB十分适合。另一方面，MongoDB能直接导入、导出Json，并且增删改查API简单又易于理解。但同时，使用MongoDB无法进行Join查询，需要前端自己进行处理又不是很方便。

Software test

虽然在网上找到了很多用于单元测试的框架，但对于我们这种大量调用中间件的接口测试逻辑太过麻烦，代价太大，所以在写了几个单元测试之后决定只使用Postman提供的 newman 脚本测试工具进行接口测试。

newman进行测试比较简单，在Postman中输入好需要测试的url和http方法即可自动生成。在命令行中利用newman工具即可进行测试。

Workflow words

2019-06-26T00:00:00+00:00

工作流术语表

1) 活动（Activity）：活动室被指派任务的执行，与特定的案例相关。近义词有任务实例、变迁实施、操作。

2) 参与者（Actor）：参与者是直接或间接参与执行工作的人、及其或组织单元。扮演承包人或转包商。

3) AND-join：AND-join 是一组条件同时被满足时才能被执行的任务。可以被比作一个装配阶段，该阶段只有当所有必需的组件都可用时才能开始。当几个并行工作流需要同步时，可以使用AND-join。通过AND-join，可以协调某个案例的若干并行工作流。

4) AND-split：AND-split 的任务和AND-join 的逻辑相反。执行一个AND-split 会创建某个案例上的多个并行工作流。AND-split 把一个案例分成不同部分，以便同时在这些部分上工作。

5) OR-join：OR-join 是一个任务，若干可选工作流汇集于此，若干可选工作流汇集于此。与AND-join 不同，它不需要同步，只要满足其中的一个条件，该任务就可以被执行。

6) OR-split：OR-split 是一个任务，即在此处做出选择，从多个工作流中选出一个。OR-split 分为显示和隐式的，区别在于选择发生的时刻。

7) 指派（Assignment）：指派（或委派），在过程定义中描述，该定义明确地说明了为完成一个案例，哪些任务必须执行，以说明顺序执行，以及必须在什么时间内执行。

8) 审计追踪（Audit trail）：审计追踪是记录工作流历史的电子档案。包含每个案例的详细信息，如开始时间、执行的任务和所分配的资源。

9) 业务过程（Business process）：业务过程是关注于产品的生产过程。这些产品可能是抽象的，也可能是具体的。

10) 业务过程重组（BPR）：是对业务过程的深刻反思和彻底重构，目的是实现成本的大幅下降，质量和服务的大幅提升。

11) 能力规划（Capacity planning）：能力规划决定一定时期为某个资源类分配多少资源。因为案例规模取决于多种因素，比如季节性影响、周模式以及其他的拨动。能力规划重点考虑在请求的资源和可用的资源之间找到一个平衡点。

12) 案例（case）：案例是工作流管理系统控制的目标对象，可以把它看做“在制品”。每个案例都有唯一的标识，此外，案例在任何时刻都处于开发的某个阶段。近义词：项目、处理、产品、服务、处理周期、作业、工作流实例。

13) 案例管理员（case manager）：案例管理员负责处理整个案例，或者负责处理案例的一组任务。

14) 案例状态（case state）：任何时刻，案例都有一个特定状态。该状态决定于已经满足的条件的和相关案例属性的值。

15) 案例类型（case type）：类似的案例属于同一种案例类型。在案例类型和过程之间存在一一对应的关系。换句话说，就是每个过程定义恰好属于一个案例。

16) 计算机支持的协同工作（computer-supported cooperative work）：计算机支持的协同工作是支持协作开展工作的方法、技术和系统的统称。群件产品以及工作流管理系统都属于这个范畴。

17) 群件（Groupware）：群件是支持群体协作的软件产品的统称。

18) 互操作性（Interoperability）：是使得孤立的应用可以彼此通信和协调的能力。因为一个工作流管理系统需要链接和集成不同的应用，所以要强调互操作性。对于大型组织，工作流管理系统之间的互操作性是成功应用工作流管理系统的关键。

19) IPSD 方法：IPSD 方法代表交互式面向过程的系统开发，综合了RAD 和BPR 的要素，形成工作流系统开发方法。

20) 迭代（Iteration）：如果工作流结构中允许一个或者更多任务被重复执行，就需要迭代。只要任务结果不令人满意，则必须重复。

21) 知识管理（Knowledge management）：知识管理是知识的收集、完善和分发的过程。知识管理的目标是确保正确的知识在正确的时刻，送达需要利用这些知识完成某项任务的人。

22) 层次组织（Hierarchical organization）：在层次组织中，权力关系有一个树状结构，通常表现为组织图的形式。

23) 矩阵组织（Matrix organization）：矩阵组织根据功能和层次进行结构化，功能结构基于一个临时的项目。

24) 网状组织（Network organization）：网状组织由独立的参与者组成，他们一起生产产品和/或提供服务。因此在参与者之间存在相互授权关系，我们有时也称之为“虚拟公司”。

25) 组织图（Organizational chart）：组织图是树状结构，图形化地阐明了权利关系。换句话说，它显示了组织职位的层次结构。

26) 组织单元（Organizational unit）：员工通常成组工作。分组可以基于工作场所、基于承担的角色或基于一个工作包。在这样的情况下，我们分别称之为地理的、功能的或基于过程的组结构。具有明确的领导、明确的任务、明确的责任并在一起工作的这群人，我们称之为一个组织单元。一个组织经常采用一种分层的方式划分为组织单元，这样使得一个组织单元可以成为其他组织的一部分。

27) Petri 网（Petri net）：Petri 网是由库所、变迁和弧组成的一个过程描述。具有形式化语义，即有精确定义。

28) 库所（Place）：库所是Petri 网中的被动元素。一个库所可能包含零个，一个或者多个标记。在工作流建模过程中，它用于描述条件。

29) 过程（Process）：过程定义指出哪些任务必须执行、以什么顺序执行，以便成功的完成案例。换句话说，就是所有可能的路由都被定义。过程由任务、条件、子过程组成。通过使用AND-split、AND-join、OR-split、OR-join可以定义并行和选择。子过程也是由任务、条件和更深层的子过程组成的。子过程可以使复杂的结构层次化。

30) RAD：快速应用程序开发（Rapid Application Development）：是一种系统开发方法。此方法主要表现为一个循环的开发过程，在该过程中非常重视与用户的紧密合作。

31) 参考模型（Reference Model）：工作流管理组织定义了一个体系结构，包括工作流执行服务、过程定义工具、工作流客户端应用、被调用应用、管理和监督工具。

32) 资源（Resource）：资源是一个或一组生产工具。资源也包括参与者，比如人、机器、交通工具、应用、部门和业务单位等。资源只能完成某些任务，因此可以将其分成一个或多个资源类。一个资源属于某一资源类，表明了该资源在组织中的职位或所拥有的品质。

33) 资源类（Resource class）：资源只能胜任若干个任务。为了再过程定义时方便地说明一个任务可以由哪些资源执行，我们将资源划分为资源类。一个资源可以属于多个资源类。通常采取根据在组织内的职务（组织单元）和功能特征（角色）两种方式划分资源类。

34) 资源分类（Resource classification）：资源（员工或自动化设备）都只能执行若干个任务，这取决于一个资源能够胜任哪些角色和这些任务需要在上面场所完成。一种资源分类把资源划分为若干子集，也就是资源类。资源分类的例子包括划分角色和划分组织单元。在一个特定的分类规则下，具有相同特性的资源组成一个资源类。

35) 回滚（rollback）：故障可能发生在活动执行期间，一旦工作流管理系统发现了（记录了）一个故障，则一定进行一个回滚，换工作流系统返回到开始时的转台，活动被再次执行。

36) 路由（routing）：过程定义决定了案例如何被路由以穿过不同的任务。通常区分四种类型的路由：顺序、选择、并行和迭代。

37) 基本过程（Primary process）：处理面向顾客的案例的过程，侧重于给公司顾客提交产品和/或服务。

38) 二级过程（Secondary process）：支持基本过程的过程，主要是为基本过程提供资源。

39) 三级过程（Tertiary process）：三级过程是管理过程，用来控制基本和二级过程。

40) 合理的（Sound）：合理性是为工作流网定义的一个正确性标准。一个工作流网是合理的，如果对于任何案例，该过程会最终结束，而且在过程结束时，在汇结库所中有一个标记且其他库所都为空。此外，不应该有死变迁，在工作流中只要沿着恰当的路由就可以执行任何一个任务。

41) 任务（task）：任务是一个原子过程，不能进一步细分为组件过程，是工作的逻辑单位。一个任务要么完整的执行，要么不执行。任务分为自动的、半自动的和手工的三类。

42) 标记（token）：Petri 网的状态由标记在库所中的分布来决定，如果工作流被映射为Petri 网，那么案例的状态对应于一个或多个标记。

43) 事务（transaction）：事务是一个交流协议，通过它形成关于活动的规定。

44) 事务处理系统（transaction processing system）：事务处理系统是一个信息系统，用以注册、转换和传递系统状态流的相关细节。

45) 变迁（transition）：变迁是Petri 网的主动元素，变迁的实施将导致Petri 网状态的改变，在对工作流进行建模时，变迁通常表示任务。

46) 触发（trigger）：只有当一个资源完成初始化之后才能被执行，对这种情况，我们称之为触发。触发也存在其他形式，如一个外部事件或一个时间信号也能触发一个工作项、

47) 工作项（work item）：工作项是案例和要被执行的任务的结合。与活动相似，工作项也被链接到某个特定的案例，工作项在开始执行的时刻转换为活动。

48) 工作流（workflow）：工作流由与一个特定过程相关的案例、资源和触发组成。

49) 工作流定义（workflow definition）：工作流定义由过程定义、所需资源汇总以及这些资源的分类组成。

50) 工作流定义工具（workflow definition tool）：用来定义过程和资源分类的工具。

51) 工作流引擎（workflow engine）：工作里引擎负责实际管理工作流。它主要关注任务分配、资源分配、活动执行、案例准备和修改、应用程序调用和后勤信息记录。

52) 工作流互操作性（workflow interoperability）：工作流互操作性是两个或者多个工作流引擎能够共同处理某个工作流的程度，包括案例的交换和工作项的外包。

swsad project市场调研

2019-06-25T00:00:00+00:00

“挣闲钱”的市场调研过程

本次项目是实现一个“挣闲钱”软件，这个项目的市场调研工作还是蛮有趣味的。

市场调研

问卷

问卷地址：关于大学生众包平台的可行性调查分析

我于3月12日设计好问卷并发放调查。问卷的设计就是一个难题。我认为问卷设计的问题的目的性应当很强，并且要加上组会中已经讨论过但不确定的地方。同时，我认为问卷有一个很有意义的地方就是要了解用户们最在乎的点。

问卷设计，我认为一定要能得出的结论：软件开发的必要性、用户最在乎的功能点、用户最在乎的服务点。

在一段时间后，总共收到60份答卷。答卷的数量虽然不多，但大家的答案有强烈的趋同性，因此我认为这些答卷已经够用了。

问卷我只在学校的群里发给了大家，基本上专业背景都不相同。填写问卷的人却有来自香港、河南、北京、辽宁、湖北、上海甚至国外全国各地的人，看来大家在学期中间摸鱼的还是不少啊。

同时在发放答卷的过程中，我强烈的感觉到了有一个让大家做答卷的众包平台的意义。

竞品分析

寻找竞品本身就是一个不容易的任务。我们的作品定位是“面向大学生”的“众包”“挣闲钱”平台。那么我该怎么找竞品呢？

“挣闲钱”，闲——闲鱼，这是我唯二能想到的与本项目有些类似的软件了。但闲鱼，一是基本是一对一交易，二是人家定位就是个二手交易平台，和我们要做的，希望出售的是人力的平台还是差了很多的。

美团跑腿，这是一个我们组在开第一次组会经过一定的分析后联想到的最相近的应用程序，也是我能想到的另一个类似的产品。不过打开之后发现这真的不是一个我们想象的众包平台，仍然是商家发单、美团骑手接单的给美团骑手在不送外卖的时候干副业的产品。不过这个项目所提供的商家发布任务、骑手接受任务、将任务分类的逻辑仍旧给我们的项目带来了帮助。

淘宝，这是提到闲鱼后自然而然想到的一个产品。如果只看那些想看的商品，比如问卷代填、代课、代写作业这些售卖人力的产品，淘宝其实可以看作我们想要最终实现的成品。于是我们借鉴了淘宝的双方确认、商品个数等。

在应用市场搜索大量关键字加上对问卷的分析让我找到了如下几个竞品：

美团跑腿
美团众包
蜂鸟众包
俺来也

其中，“俺来也”是与本APP最相似。他提供了众包、校园服务、二手市场等，但这个APP似乎仍旧是以校园社交为主。

MongoDB学习记录

2019-06-20T00:00:00+00:00

在本学期的一个课程项目中，作为一个后端小白，第一次接触并使用了MongoDB。以下为学习记录。

MongoDB

MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。

MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。

为什么使用MongoDB

本项目中，我们后端使用的是koa框架。koa和mongoDB总是在一起提到，本项目中我们也自然使用了这一数据库。那么MongoDB带来了什么实际的好处呢？

我总结了在我们项目实际使用中MongoDB带来的好处：

MongoDB 是一个面向文档存储的数据库，操作起来比较简单和容易。查询语言非常强大，增删改查API操作简捷易懂。
提供的Compass等可视化工具使用方便。
我们项目小组作为一个经验较少的小组，数据库开发不够成熟，经常有数据元素的增删。MongoDB作为NoSQL在这方面十分方便。
MongoDB可以直接输入和输出JSON文件。
MongoDB读写操作都非常快，查询后可能是因为：MongoDB使用内存映射存储引擎，把磁盘的IO操作转换成为内存的操作。

在使用MongoDB中发现的不足

MongoDB给我们的开发带来了很多便利，但是在开发过程中也遇见了一些问题：即复杂的查询，如Join，无法实现。

Monk

Monk是提供给koa使用的一个操作MongoDB的组件。

使用Monk提供的API，我们在项目中做到了如下：

以中间件的形式使用Monk，符合koa框架编程习惯。
通过Monk较为简单的连接MongoDB与koa。
使用Monk提供的面向对象接口方便操作MongoDB。

Joi

Joi是一个Shema组件，可以用于将数据转为对象，或将对象转为Json数据，通过这一组件，实现了数据层与应用层之间的数据交换需要。

例如一个用户的标准格式：

const userRegSchema = Joi.object().keys({
    username: Joi.string().alphanum().min(3).max(30).trim().required(),
    password: Joi.string().regex(/^[a-zA-Z0-9]{3,30}$/).required(),
    email: Joi.string().email({ minDomainSegments: 2, }).required(),
    phone: Joi.string().regex(/^[0-9]{11}$/).required(),
    nickname: Joi.string().min(2).max(20).trim().required()
});

Reference

Joi

Monk

MongoDB

Swsad 作业 5

2019-05-26T00:00:00+00:00

根据订旅馆建模文档，Asg-RH.pdf：

绘制用例图模型（到子用例）

给出 make reservation 用例的活动图

根据课程练习“投递员使用投递箱给收件人快递包裹”的业务场景

分别用多泳道图建模三个场景的业务过程
场景1:x科技公司发明了投递柜，它们自建了投递柜以及远程控制系统。注册的投递员在推广期免费使用投递柜。由于缺乏资源，仅能使用y移动平台向客户发送短信通知。

场景2:随着产品推广，x公司与各大快递z公司达成协议。x公司在快递柜上添加了二维码扫描装置，z公司的快递员不仅可在快递柜上登陆（由z公司提供认证服务），且可扫描快递单号，投递入柜后自动由z公司发短信给客户。客户取件后，自动发送给z公司投递完成。

场景3:x公司进一步优化服务，开发了微信小程序实现扫码取快递。如果用户关注了该公司公众号，直接通过过公众号推送给用户取件码等信息。不再发送短信。

根据上述流程，给出快递柜系统最终的用例图模型用正常色彩表示第一个业务流程反映的用例用绿色背景表述第二个业务场景添加或修改的用例，以及支持 Actor 用黄色背景表述第三个业务场景添加或修改的用例，以及支持 Actor

SYSU SDCS Swsad 作业 4

2019-05-24T00:00:00+00:00

简答题

用例的概念

用例（use case），是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。广泛应用于需求的发现和记录工作中。

用例和场景的关系？什么是主场景或 happy path？

用例和场景的关系：每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

主场景（happy path）：典型的、无条件的、理想方式的成功场景。描述了满足涉众关注点的典型成功路径。通常不包括任何条件或分支。

用例有哪些形式

摘要形式：简洁的一段式概要，通常用于主成功场景。在需求分析的早期，我们可以通过它来快速了解项目的主体和范围。
简便形式：非正式的段落格式，用几个段落覆盖不同场景。
详述形式：详细编写所有步骤及各种变化，同时具有补充部分(如：前置条件和成功保证)。它是在确定并以摘要形式编写了大量用例后，在第一次需求讨论会中详细地编写的其中少量的具有重要架构意义和高价值的用例。
对于复杂业务，为什么编制完整用例非常难？

一个复杂的业务，其系统边界常常是很难界定清楚的。除此以外，它涉及的主要参与者也很多，故确定每个主要参与者的目标也会变得非常困难，毕竟我们需要做大量的研究和调查才能了解不同类型参与者的需求。综上，对于复杂业务，编制完整的用例是非常困难的。

什么是用例图？

用例图是指由参与者、用例、边界以及它们之间的关系构成的用于描述系统功能的视图。

基本符号与元素

参与者：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
用例：是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
系统边界：系统边界是用来表示正在建模系统的边界。

箭头：箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。常见的关系有includes和extends。

includes：表示一个用例的存在依赖与另一个用例。

extends：表示一个用例是另一个用例的可选拓展功能。

用例图的画法与步骤

确定系统边界;
识别系统的参与者：参与者包括主要参与者和系统依赖的外部系统。参与者画在系统边界以外，且主要参与者一般画在系统的左边，依赖的外部系统一般画在系统的右边；
识别用例：用例的命名要以动词开始。另外，用例还分为用户级别用例和子功能级别的用例，两种用例之间存在<< includes >>和<< extends >>关系。
建立参与者和用例之间的关联：用无方向的连线将相关联的两者连接起来。 ### 用例图给利益相关人与开发者的价值有哪些？
使领域专家或需求提供者自己编写（或参与编写）用例成为可能，并使这项工作难度降低。
强调了用户的目标和观点，能够根据需要对复杂程度和形式化程度进行增减调节。 ## 建模练习题 ### 选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：

请使用用户的视角，描述用户目标或系统提供的服务
粒度达到子用例级别，并用 include 和 exclude 关联它们
请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
尽可能识别外部系统和服务
为什么相似系统的用例图是相似的？

用例图反映的是系统的功能和使用者与系统的交互方式，相似的系统有着相似的功能和交互方式，因此其用例图也是相似的。

如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

可以利用不同颜色的标注来定位创新点。

请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

ID	Name	Imp	Est	How to demo
1	find hotel by location	8	1	input the hotel name to determine hotel
2	find hotel on map	3	1	slide on map to determine hotel
3	make reservation	7	4	determine hotel, room type, time and then confirm
4	pay reservation	7	3	payment supported by third party system
5	modify reservation	5	2	modify reservation and hotel make approval
6	comment hotel	4	2	traveler rate and comment

SYSU Swsad 作业 3

2019-04-13T00:00:00+00:00

学号：16340291

Q:简述瀑布模型、增量模型、螺旋模型（含原型方法），并分析优缺点

瀑布模型

瀑布模型将软体生命周期划分为制定计划、需求分析、软体设计、程式编写、软体测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软体开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生回圈反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。

优点

为项目提供了按阶段划分的检查点。
当前一阶段完成后，您只需要去关注后续阶段。
可在迭代模型中每轮迭代很类似一个小的瀑布模型。增量迭代应用于瀑布模型。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
它提供了一个模板，这个模板使得分析、设计、编码、测试可以在该模板下有一个共同的指导。

缺点

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
瀑布模型的突出缺点是不适应用户需求的变化。
增量模型

增量模型融合了瀑布模型的基本成分（重覆应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软体的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重覆，直到产生了最终的完善产品。

优点　　

整个项目的资金不会被提前消耗，因为首先开发和交付了主要功能和高风险功能。每个增量交付一个可操作的产品。
每次增量交付过程中获取的经验，有利于后面的改进，客户也有机会对建立好的模型作出反应。
采用连续增量的方式，可把用户经验融入到细化的产品，这比完全重新开发要便宜得多。
通过同一个团队的工作来交付每个增量，保持所有团队处于工作状态，减少了员工的工作量，工作分布曲线通过项目中的时间阶段被拉平。
每次增量交付的结为，可以重新修订成本和进度的风险。
便于根据市场作出反应。
降低了失败和更改需求的风险。
更易于控制用户需求，因为每次曾两开发的时间很短。
由于不是一步跳到未来，所以用户能逐步适应新技术。
切实的项目进展，有利于进度控制。
风险分布到几个更小的增量中，而不是集中于一个大型开发中。
由于用户能够从早期的增量中了解系统，所以更加理解后面增量中的需求。

缺点

由于各个构件是逐渐并入已有的软体体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软体具备开放式的体系结构。
在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软体过程的控制失去整体性。
如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软体开发过程。

螺旋模型

螺旋模型（Spiral Model）的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简单方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型。

螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软体项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软体开发不可忽视且潜在的不利因素，它可能在不同程度上损害软体开发过程，影响软体产品的质量。减小软体风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。

优点

对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
减少了多个测试（浪费资金）或测试不足（产品故障多）所带来的风险。
更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
螺旋模型主要适用于内部开发的大规模软件项目。

缺点

螺旋模型的主要优势在于，它是风险驱动的。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还认为一切正常。
过多的迭代次数会增加开发成本，延迟提交时间。

Q:简述统一过程三大特点，与面向对象的方法有什么关系？

三大特点

软件开发是一个迭代过程，是一种受控的迭代和增量式开发软件开发是由Use Case驱动的，也就是通过测试来推动整个开发过程的进行，在测试中完成需求分析、设计、质量控制等过程。软件开发是以架构设计为中心的

与面向对象的方法的关系

统一过程是一个面向对象且基于网络的程序开发方法论，它给出了有关软件开发过程组织及实施的指导。

Q:简述统一过程四个阶段的划分准则是什么？每个阶段关键的里程碑是什么？

统一过程以其工作内容的时间跨度划分阶段

初始阶段（inception phase）。主要确定项目的风险及其优先次序，初始规划确定业务范围，项目整体预算估计等。里程碑为目标里程碑。
细化阶段（elaborattion phase）。主要深入分析用例、健全架构和制定详细的开发计划。里程碑为结构里程碑。
构造阶段（construction phase）。开发和测试阶段。里程碑是初始功能里程碑。
移交阶段（transition phase）。改进产品的缺陷和不足，准备交付给用户。里程碑是产品发布里程碑。
Q:软件企业为什么能按固定节奏生产、固定周期发布软件产品？它给企业项目管理带来哪些好处？

原因：统一过程模型中，各个阶段的生命周期都是确定的，在固定的周期内，所要完成的科目也是有明确的规范的。换句话说就是，要做什么、要做多久我们都是清楚的。因此企业只要够按照统一过程的标准，就能按固定周期完成产品的生产和发布。

好处：根据固定周期的开发任务以及阶段，企业可以更加便利地掌控开发进度以及控制预算，对产品的质量和生产开发过程都能进行较为精准的把控，方便企业根据实际情况做出调整，规范管理，从而尽可能达到最大的收益。

Peanut

使用Postman测试API接口

开始

生成请求集合

生成测试脚本

Team work

Reference

提高团队协作效率

Github Issues

腾讯 / 石墨文档

Git Bash SSH

Linux Screen命令

Reference：

SWSAD 自我总结

自我总结

PSP 2.1 统计表

Git统计报告

最得意的工作清单

个人博客清单

致谢

koa学习记录

后端小白从零开始之路

Koa

洋葱模型

Context

架构设计

MongoDB

Software test

Workflow words

工作流术语表

swsad project市场调研

“挣闲钱”的市场调研过程

市场调研

问卷

竞品分析

MongoDB学习记录

MongoDB

为什么使用MongoDB

Monk

Joi

Reference

Joi

Monk

MongoDB

Swsad 作业 5

SYSU SDCS Swsad 作业 4

简答题

用例的概念

用例和场景的关系？什么是主场景或 happy path？

用例有哪些形式

对于复杂业务，为什么编制完整用例非常难？

什么是用例图？

用例图的画法与步骤

为什么相似系统的用例图是相似的？

如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

SYSU Swsad 作业 3

Q:简述瀑布模型、增量模型、螺旋模型（含原型方法），并分析优缺点

瀑布模型

增量模型

螺旋模型

Q:简述统一过程三大特点，与面向对象的方法有什么关系？

三大特点

与面向对象的方法的关系

Q:简述统一过程四个阶段的划分准则是什么？每个阶段关键的里程碑是什么？

统一过程以其工作内容的时间跨度划分阶段

Q:软件企业为什么能按固定节奏生产、固定周期发布软件产品？它给企业项目管理带来哪些好处？