在本次项目中，本人主要负责产品分析、产品MVC和UML设计、程序框架构建和UI交互设计以及demo测试等工作。

在开发微信小程序初期，对于各个用例的编写以及用例图、状态图、顺序图、类图和包图的绘制，使得我对于整个软件的设计以及开发过程有了更深的认识。 同时对产品UI的交互设计让我知道了产品能够被高频率使用的关键所在。在demo测试中让我和小组成员一起发现了很多问题并成功解决，对于我和小组成员的合作能力有很好的帮助。这次的工作主要收获如下

1）学习到了在产品策划时需要考虑多个方面，并且对于需求的把握也十分重要。在我本次对UI交互的设计过程中也学习到了应该多和前端人员交流，使得界面的设计和前端人员的制作尽量可行且一致。

2）在项目进度方面，需要在计划阶段就确定好几个关键的时间节点，不然就会导致我们不分成员因为个人原因使得整体项目延后的结果。

3）对于功能的选择，同样要在需求上下功夫，我们第一次迭代时就没有好好考虑用户和商家的交互，使得初代版本与商家的交互不够理想；在我们之后的不断总结中最终完成了较好的产品与用户和商家、多个用户以及用户与商家之间的较好的交互结果。

这次的项目合作在我担任产品经理的过程中，让我更好地体会到了管理项目的步骤和过程，虽然有时候会因为队员的某些因素导致整体进度的延迟，但是良好的团队合作以及项目管理是我们这次基本完成微信小程序开发的关键。

用例简介

该用例首先开始搜索酒店，然后根据搜索方式开始按照酒店名称搜索酒店，在得到搜索完成的表单后根据表单，用户选择酒店，完成后用户再选择房间类型，最后验证预定就完成了整个过程。

顺序图

类图

2.将逻辑设计类图映射到实际项目框架的包图。用树形结构表述实现的包和类

定义：

软件架构：

软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构描述的对象时直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致的描述组建之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

软件框架：

软件框架是将代码放到一个看不到的容器中，规定架构。当时用的时候直接调用。他实现了该领域的共性部分，并提供了一些定义良好的可变点以保证灵活性和可扩展性。他是领域分析结果的软件化，是领域内最终应用的模板，是特定语言和技术架构应用解决方案。

区别：

框架是软件，架构不是软件。

框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为构建解决方案提供良好的基础。它是一个半成品，是系统或子系统的半成品；框架中的服务被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。

架构不是软件，而是关于软件如何设计的重要策略。软件架构决策设计到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。引入软件架构之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。

2.以你的项目为案例

·绘制三层架构模型图，细致到分区

·结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利

三层架构允许将任务合理地分配，表示层、业务层、持久化层各自的需求由不同的成员各自同时实现，到最后汇总即可，不会出现一环依赖另一环的情况，大大提高了开发者的工作效率。并且较低层的复用性较高，为开发者减少了重新开发的麻烦以及代码量。接口设计需要也符合对扩展开发，对修改关闭的原则，增强了系统的安全性。

3.研究 VUE 与 Flux 状态管理的异同

Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。VUE 没有使用 Dispatcher 来接收 Actions 、执行回调函数并通知 Store 改变状态，而是通过使用 Mutation 来改变状态。

Flux 状态管理，Flux 通过强制单向数据流来解决在MVC 中，一个 Model 可能使多个 Views 去通知 Controllers，并可能触发更多的 Model 更新，这样结果就会变得非常复杂的问题。

他们的相同点

VUE 和 Flux 的状态管理都是基于 Flux 思想的有效实现，通过对数据流进行严格管理来规范数据在 Web 引用中流动方式的框架。

他们的不同点

Vuex把action细分成了action和mutation，分别应对异步场景和同步场景，由store自身充当dispatcher（负责注册/分发action/(mutation)。VUE与Flux在状态管理上的差异主要体现在对数据流的管理方式不同。

Flux 通过强制数据的单向流动来解决业务数据复杂度的问题。它主要将一个应用分成四个部分：①View 视图层②Action（动作）视图层发出的消息（比如mouseClick）③Dispatcher（派发器）用来接收Actions、执行回调函数④Store（数据层）用来存放应用的状态，一旦发生变动，就提醒Views要更新页面。而VUE 的状态管理由vuex实现。

根据 飞猪酒店预订文档 进行建模，要求画出用例图、活动图、领域模型、状态图、系统顺序图

1.用例图

2.活动图

3.领域模型

4.订单状态图

5.支付顺序图

建模对象： 参考 Asg_RH 文档， 对 Reservation/Order 对象建模。

建模要求： 参考练习不能提供足够信息帮助你对订单对象建模，请参考现在 定旅馆 的旅游网站，尽可能分析围绕订单发生的各种情况，直到订单通过销售事件（柜台销售）结束订单。

研究淘宝退货流程活动图，对退货业务对象状态建模

a.阅读 Asg_RH 文档，按用例构建领域模型。

b.数据库建模(E-R 模型)

E-R模型

物理模型

导出 Mysql 物理数据库的脚本

/*==============================================================*/
/* DBMS name:      MySQL 5.0                                    */
/* Created on:     2018/4/28 19:11:06                           */
/*==============================================================*/


drop table if exists CreditCard;

drop table if exists Destination;

drop table if exists Hotel;

drop table if exists Reservation;

drop table if exists Room;

drop table if exists Traveller;

/*==============================================================*/
/* Table: CreditCard                                            */
/*==============================================================*/
create table CreditCard
(
   CardNumber           varchar(20) not null,
   userid               int,
   cardid               int not null,
   primary key (CardNumber)
);

/*==============================================================*/
/* Table: Destination                                           */
/*==============================================================*/
create table Destination
(
   cutyName             varchar(20) not null,
   primary key (cutyName)
);

/*==============================================================*/
/* Table: Hotel                                                 */
/*==============================================================*/
create table Hotel
(
   hotelid              int not null,
   cutyName             varchar(20),
   hotelname            varchar(20),
   primary key (hotelid)
);

/*==============================================================*/
/* Table: Reservation                                           */
/*==============================================================*/
create table Reservation
(
   resid                int not null,
   userid               int,
   CheckinDate          date,
   CheckoutDate         date,
   primary key (resid)
);

/*==============================================================*/
/* Table: Room                                                  */
/*==============================================================*/
create table Room
(
   roomid               int not null,
   hotelid              int,
   resid                int,
   roomType             varchar(20),
   primary key (roomid)
);

/*==============================================================*/
/* Table: Traveller                                             */
/*==============================================================*/
create table Traveller
(
   userid               int not null,
   "E-mail"            varchar(20),
   Name                 varchar(20),
   primary key (userid)
);

alter table CreditCard add constraint FK_Relationship_1 foreign key (userid)
      references Traveller (userid) on delete restrict on update restrict;

alter table Hotel add constraint FK_Relationship_5 foreign key (cutyName)
      references Destination (cutyName) on delete restrict on update restrict;

alter table Reservation add constraint FK_Relationship_2 foreign key (userid)
      references Traveller (userid) on delete restrict on update restrict;

alter table Room add constraint FK_Relationship_3 foreign key (resid)
      references Reservation (resid) on delete restrict on update restrict;

alter table Room add constraint FK_Relationship_4 foreign key (hotelid)
      references Hotel (hotelid) on delete restrict on update restrict;

简单叙说 数据库逻辑模型 与 领域模型 的异同

数据逻辑模型是一种图形化的展现方式，一般采用面向对象的设计方法，有效组织来源多样的各种业务数据，使用统一的逻辑语言描述业务。

领域模型是对领域内的概念类或现实世界中对象的可视化表示。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

数据库逻辑模型需要考虑一些更加细节的东西，而数据库逻辑建模会更偏向于实践而不再是概念的建模。用户不需要关心系统的数据模型，但是必须关注领域模型，因为领域模型反映的是问题域的相关业务概念以及其关系，领域模型是用户业务描述的高度抽象，来源于业务需求的描述，同时又可以帮助用户和需求分析人员更好的理解业务需求。

a.阅读 Asg_RH 文档，绘制用例图。 按 Task1 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸

b.选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：

- 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例

- 尽可能识别外部系统，并用色彩标注新的外部系统和服务

c.对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法

答：我认为在早期对于城市卫星的应用还未得到完善，所以不能很好的在地图上查找酒店，其次在支付的方面在线支付的手段单一，一般只能通过网银来进行支付，方式也不便捷。因此需要针对这些不利的地方来对软件的使用得到创新和改善，比如国内日渐流行的支付宝、微信等支付平台，国内卫星的普及使用以及更加高效的用户评论热度功能大大优化了软件的使用，开发软件就是在一次次的迭代和创新中越做越好的。

d.请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求 （backlog）

2.业务建模

a.在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法。

b.选择你身边的银行 ATM，用活动图描绘取款业务流程

c.查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例

3.用例文本编写

·在大作业基础上，分析三种用例文本的优点和缺点

① 摘要用例

优点：简洁，每个场景基本只有一段文字，可以快速了解主题，简洁的一段式概要，通常用于主场景

缺点：缺乏细节，不能对所有情况进行说明。

②非正式用例

优点：简洁、比摘要用例更加详细。

缺点：不够正式化，不能用在特别详细的用例场景当中。

③详述用例

优点：详细编写所有步骤及各种变化，同时具有补充部分，有严格的书写格式规范。

缺点：由于过于详细，因此很难实现，需要耗费大量的时间，成本较高。

·UMLet

UMLet是一个开放源代码轻量级UML建模工具，它能够帮助我们快速地构建 UML 用例图、UML 静态图、UML 行为图和 UML 实现图等各种 UML 模型。

###①安装 （1）运行UMLet需要电脑上安装有java运行环境，可以前往Oracle官网，根据自己的电脑系统下载相应的JDK。 （2）安装好java运行环境后，前往UMLet官网下载相应的安装包。

###②运行

上图是我们小组的扫码点餐的用例图。

（1）可以看到在右上侧区域是用于绘制各种UML模型图，内双击想要添加的对象，对象被自动添加到面板中。

（2）在右上侧的最上面有一个模板选择区，用于选择UML的各种模板。

（3）选中刚刚添加进来的对象，在右下角的属性面板中，可以修改对象的属性。这一块区域用于编写UML元素的属性，如类名称、字段、背景等。

（4）保存创建完成的UML模型图，也可以导出来为其它格式。

###③总结 这个工具总的来说能够导出不同的格式，界面很简单，要进行的操作也很简单。

2.技术学习报告

·微信小程序QuickStart项目

###①代码构成

（1）一个QuickStart项目中有四个不同类型的文件，分别是.json 后缀的 JSON 配置文件，.wxml 后缀的 WXML 模板文件，.wxss 后缀的 WXSS 样式文件和.js 后缀的 JS 脚本逻辑文件

（2）对于app.json

是对当前小程序的全局配置，包括了小程序的所有页面路径、界面表现、网络超时时间、底部 tab 等。QuickStart 项目里边的 app.json 配置内容如下：

{

  "pages":[

    "pages/index/index",

    "pages/logs/logs"

  ],

  "window":{

    "backgroundTextStyle":"light",

    "navigationBarBackgroundColor": "#fff",

    "navigationBarTitleText": "WeChat",

    "navigationBarTextStyle":"black"

  }

}

其中pages字段用于描述当前小程序所有页面路径，这是为了让微信客户端知道当前你的小程序页面定义在哪个目录。window字段是小程序所有页面的顶部背景颜色，文字颜色定义在这里的。

（3）对于WXML模板

从事过网页编程的人知道，网页编程采用的是 HTML + CSS + JS 这样的组合，其中 HTML 是用来描述当前这个页面的结构，CSS 用来描述页面的样子，JS 通常是用来处理这个页面和用户的交互。

同样道理，在小程序中也有同样的角色，其中 WXML 充当的就是类似 HTML 的角色。打开 pages/index/index.wxml，你会看到以下的内容:

<view class="container">

  <view class="userinfo">

    <button wx:if=""> 获取头像昵称 </button>

    <block wx:else>

      <image src="" background-size="cover"></image>

      <text class="userinfo-nickname"></text>

    </block>

  </view>

  <view class="usermotto">

    <text class="user-motto"></text>

  </view>

</view>

和HTML非常相似，有标签、属性等等构成。但是也有很多不一样的地方：

1.标签名字有点不一样 往往写 HTML 的时候，经常会用到的标签是 div, p, span，开发者在写一个页面的时候可以根据这些基础的标签组合出不一样的组件，例如日历、弹窗等等。

1. 多了一些 wx:if 这样的属性以及 这样的表达式 在网页的一般开发流程中，我们通常会通过 JS 操作 DOM (对应 HTML 的描述产生的树)，以引起界面的一些变化响应用户的行为。
   WXML 是这么写 :

<text></text>

JS 只需要管理状态即可:

this.setData({ msg: "Hello World" })

（4）对于WXSS样式

WXSS 具有 CSS 大部分的特性，小程序在 WXSS 也做了一些扩充和修改。

1.新增了尺寸单位。在写 CSS 样式时，开发者需要考虑到手机设备的屏幕会有不同的宽度和设备像素比，采用一些技巧来换算一些像素单位。

2.提供了全局的样式和局部样式。和前边 app.json, page.json 的概念相同，你可以写一个 app.wxss 作为全局样式，会作用于当前小程序的所有页面，局部页面样式 page.wxss 仅对当前页面生效。

3.此外 WXSS 仅支持部分 CSS 选择器

（5）对于JS交互逻辑

一个服务仅仅只有界面展示是不够的，还需要和用户做交互：响应用户的点击、获取用户的位置等等。在小程序里边，我们就通过编写 JS 脚本文件来处理用户的操作。

<view></view>

<button bindtap="clickMe">点击我</button>

点击 button 按钮的时候，我们希望把界面上 msg 显示成 “Hello World”，于是我们在 button 上声明一个属性: bindtap ，在 JS 文件里边声明了 clickMe 方法来响应这次点击操作：

 Page({

  clickMe: function() {

    this.setData({ msg: "Hello World" })

  }
  
})

以上是我对于微信小程序的部分学习，其中小程序的框架等部分尚未介绍。

·简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。

①瀑布模型：

瀑布模型的优点：有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。

瀑布模型的缺点：（1）开发过程一般不能逆转，否则代价太大；（2）实际的项目开发很难严格按该模型进行；（3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。（4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。 

②增量模型：

增量模型的优点：（1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源；（2）如果核心产品很受欢迎，则可增加人力实现下一个增量；（3）可先发布部分功能给客户，对客户起到镇静剂的作用。

增量模型的缺点：（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

③螺旋模型：

螺旋模型的优点：（1）设计上的灵活性,可以在项目的各个阶段进行变更；（2）以小的分段来构建大型系统,使成本计算变得简单容易；（3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性；（4） 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。 

螺旋模型的缺点：（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；（2）过多的迭代次数会增加开发成本，延迟提交时间。

·简述 UP 的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？

UP的三大特点：用例驱动、以架构为中心、受控的迭代式增量开发 其中用例驱动和受控的迭代式增量开发体现了用户驱动的开发，以架构为中心体现了风险驱动的开发。

·UP 四个阶段的划分准则是什么？关键的里程碑是什么？

①划分的准则是根据开发生命周期中不同的关键里程碑划分

②关键里程碑是：

初始阶段-获得项目的基础：生命期目标；

细化阶段-进化软件构架:生命期构架；

构造阶段-构造软件：初试运作功能：

移交阶段-把软件部署到用户环境：产品发布。

·IT 项目管理中，“工期、质量、范围/内容” 三个元素中，在合同固定条件下，为什么说“范围/内容”是项目团队是易于控制的

因为在合同固定的条件下，工期和质量在合同中已经有了明确的规定，是不能随意更改的，但是项目的范围/内容则会根据软件开发过程中遇到的实际情况或者项目团队与客户商议做出调整。

·为什么说，UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据？

因为UP的软件生命周期分为四个阶段，每一个阶段由主要里程碑所终止，并且它是迭代和增量的，每次迭代都具有各自的需求分析、设计、实现和测试活动，并且特定工作流的重点依赖于项目生命周期中的迭代发生的位置，所以说UP为企业按固定节奏生产、固定周期发布软件产品提供了依据。

2.项目管理使用

使用截图工具（png格式输出），展现你团队的任务 Kanban，请注意以下要求

①每个人的任务是明确的。即一周后可以看到具体成果

②每个人的任务是1-2项。

③至少包含一个团队活动任务

·软件工程的定义

①软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。 ②在现代社会中，软件应用于多个方面。典型的软件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，也提高了工作效率和生活效率 。

·阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型。

①software crisis是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机（Software crisis）一词。而1960年代中期开始爆发众所周知的软件危机，为了解决问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工程的概念。 ②对于项目的成功而言，项目人员的素质、人员的组织管理是比使用的工具或采用的技术方法更重要的因素。从而Boehm的COCOMO模型发现团队质量目前是项目成功最大的决定因素，实际上是下一个次重要因素的4倍。现在，软件工程的大多数学术研究集中在工具上。

·软件生命周期

软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段。

·按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？

本课程关注①软件需求（Software Requirements）②软件设计（Software Design）③软件构造（Software Construction）④软件工程工具和方法（Software Engineering Tools and Methods）

·解释 CMMI 的五个级别

①初始级（Initial）：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。

②可管理级（Managed）：建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

③已定义级（Defined）：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。

④量化管理级（Quantitatively Managed）：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。

⑤优化管理级（Optimizing）：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

·用自己语言简述 SWEBok 或 CMMI （约200字）

CMMI是能力成熟度模型集成，它的目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件，其中它依据的想法是集中尽力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。它的基本思想有三点，一是解决软件项目过程改进难度增大问题，二是实现软件工程的并行与多学科组合，三是实现过程改进的最佳效益。CMMI的价值主要体现在能够保证软件开发的质量与进度，有利于成本控制，有助于提高软件开发者的职业素养，能够解决人员流动所带来的问题以及有利于提升公司和员工绩效管理水平等。

2.解释 PSP 各项指标及技能要求：

一个软件工程师在接到一个任务之后应该怎么做:

统计每项数据首先应该确定每个阶段的工作任务和结束的指标，然后再每一阶段开始时记录时间，并且有些阶段可能是并行开始的，要做以明确的区分，当所有任务完成之后，就能将之前记录的结果合起来做统计分析。