自我总结

这次项目学习到了很多关于前端的基础知识。包括进一步加深了前后端交互的认识。对于项目的运作周期也有了很深的认识。调试的过程中发现了很多错误，也学习了更高效的方法来找到并且解决这些问题。尤其需要感谢@MichealWind，在前端方面给予了很多指导。载整个项目学习过程中，我学习到的新知识点如下：

• vue.js技术深入
• 前端debug技术深入，学会使用network查看如何与后端对接
• 后端API的调试
• 根据文档实现具体应用逻辑

PSP 2.1 统计表

Git统计报告

工作清单

前端整体架构搭建

前端部分页面UI实现：登陆页面，注册页面，电影列表页面，影院列表页面

前后端部分功能对接：登陆，注册，获取电影列表，获取影院列表

后端API测试：登陆返回值，注册返回值。获取图片，获取影片信息，获取影院信息。

技术博客

Vue.js

使用 ECB 实现 make reservation 用例的详细设计（包含用例简介，顺序图，类图）

用例介绍：用户搜索旅馆，根据结果选择房间并填写入住信息完成预定

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

描述软件架构与框架之间的区别与联系

软件架构：

• 定义：软件架构就是把系统分解为一些部件，描述这些部件的职责及它们之间的协作行为

• 软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。

• 当软件工程具一定规模时，软件开发不完全是以数据结构+算法的形式存在，而是基于技术选择和用户需求等众多因素将软件“分而治之”，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。

框架：

定义：框架是特定语言和技术的架构应用解决方案

• 框架是具体语言和技术相关的
• 框架是一种或多种架构的组合的实现
• 框架是集成了你的代码和多种第三方解决方案的工具，让你聚焦 业务逻辑代码 而 不是技术实现

开发人员通过软件框架行为调整机制，将领域中具体应用中所特有的软件模块绑定到该软件框架的可变点上，从而得到了最终的应用系统，这个过程称为软件软件框架的例化，软件框架的存在使得开发人员将主要的精力放在系统所特有的模块的开发上，从而提高软件的生产率和质量。

软件框架的行为调整机制是指如何针对具体的应用调整该框架的可变部分、如何在可变点加入特定应用模块所采用的方法和规则

总结：

• 为了尽早验证架构设计，或者处于支持产品线开发的目的，可以将关键的通用机制甚至整个架构以框架的方式进行实现；
• 业界（及公司内部）可能存在大量可供重用的框架，这些框架或者已经实现了软件架构所需的重要架构机制，或者为未来系统的某个子系统提供了可扩展的半成品，所以最终的软件架构可以借助这些框架构造

以你的项目为案例

• 绘制三层架构模型图，细致到分区
• 结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利

三层架构带来的便利：

• 三层架构使得整个软件的层次很清晰，并且模块化分明。这样使得程序员们可以分别开发各自的模块而不会相互影响。
• 这种低耦合性能够大大提高程序员的开发效率。
• 每个模块都是可扩展的并且重用性强。
• 因为模块化明确，所以可以比较方便轻易地替换原有的模块。
• 后期的维护成本比较低，出现问题也只需要修改相应模块，而不用卷土重来

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

Flux 状态管理：

异：

• Flux是一种前端状态管理架构思想，专门解决软件的结构问题。基于Flux的设计思想，出现了一批前端状态管理框架。
• Vue的状态管理是通过Vuex来实现的，而Vuex是基于Flux设计思想的一个状态管理框架。
• Flux分为四层，分别是view、action、dispatcher和store，而它的数据流顺序为： View发起Action -> Action传递到Dispatcher -> Dispatcher将通知Store -> Store的状态改变通知View进行改变

• Vuex的核心为：

  • state：存放多个组件共享的状态（数据）
  • mutations：存放更改state里状态的方法，用于变更状态，是唯一一个更改状态的属性
  • getters：将state中某个状态进行过滤，然后获取新的状态，类似于vue中的computed
  • actions：用于调用事件动作，并传递给mutation
  • modules：主要用来拆分state vuex的数据流顺序为： View调用store.commit提交对应的请求到Store中对应的mutation函数 -> store改变(vue检测到数据变化自动渲染)

    同：

• 由于Vuex是基于Flux开发的，因此它们思想上是相同的。

• Flux和Vuex都是通过store来存储状态。

https://github.com/SEN-Wanted/Dashboard/blob/gh-pages/modeling-practice/%E6%8F%90%E4%BE%9B%E7%9A%84%E5%BB%BA%E6%A8%A1%E6%96%87%E6%A1%A3/AT%E5%BA%94%E7%94%A8%E7%9A%84%E8%AF%B4%E6%98%8E%E6%96%87%E6%A1%A3.md

使用 UML State Model

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

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

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

• 按 Task2 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸
• 说明：请不要受 PCMEF 层次结构影响。你需要识别实体（E）和 中介实体（M，也称状态实体）
  • 在单页面应用（如 vue）中，E 一般与数据库构建有关， M 一般与 store 模式 有关
  • 在java web 应用中，E 一般与数据库构建有关， M 一般与 session 有关

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

• 按 Task 3 要求，给出系统的 E-R 模型（数据逻辑模型）
• 建模工具 PowerDesigner（简称PD） 或开源工具 OpenSystemArchitect
• 不负责的链接 http://www.cnblogs.com/mcgrady/archive/2013/05/25/3098588.html
• 导出 Mysql 物理数据库的脚本
• 简单叙说 数据库逻辑模型 与 领域模型 的异同

/*==============================================================*/
/* DBMS name:      Sybase SQL Anywhere 12                       */
/* Created on:     2018/4/29 11:21:50                           */
/*==============================================================*/


if exists(select 1 from sys.sysforeignkey where role='FK_HOTEL_REFERENCE_ROOM') then
    alter table Hotel
       delete foreign key FK_HOTEL_REFERENCE_ROOM
end if;

if exists(select 1 from sys.sysforeignkey where role='FK_HOTEL_REFERENCE_CITY') then
    alter table Hotel
       delete foreign key FK_HOTEL_REFERENCE_CITY
end if;

if exists(select 1 from sys.sysforeignkey where role='FK_RESERVAT_REFERENCE_CUSTOMER') then
    alter table Reservation
       delete foreign key FK_RESERVAT_REFERENCE_CUSTOMER
end if;

if exists(select 1 from sys.sysforeignkey where role='FK_RESERVAT_REFERENCE_HOTEL') then
    alter table Reservation
       delete foreign key FK_RESERVAT_REFERENCE_HOTEL
end if;

if exists(select 1 from sys.sysforeignkey where role='FK_SHOPPING_REFERENCE_RESERVAT') then
    alter table ShoppingBasket
       delete foreign key FK_SHOPPING_REFERENCE_RESERVAT
end if;

if exists(select 1 from sys.sysforeignkey where role='FK_SHOPPING_REFERENCE_CUSTOMER') then
    alter table ShoppingBasket
       delete foreign key FK_SHOPPING_REFERENCE_CUSTOMER
end if;

drop table if exists City;

drop table if exists Customer;

drop table if exists Hotel;

drop table if exists Reservation;

drop table if exists Room;

drop table if exists ShoppingBasket;

/*==============================================================*/
/* Table: City                                                  */
/*==============================================================*/
create table City 
(
   cityName             long varchar                   not null,
   constraint PK_CITY primary key clustered (cityName)
);

/*==============================================================*/
/* Table: Customer                                              */
/*==============================================================*/
create table Customer 
(
   name                 long varchar                   not null,
   email                long varchar                   null,
   phone                long varchar                   null,
   constraint PK_CUSTOMER primary key clustered (name)
);

/*==============================================================*/
/* Table: Hotel                                                 */
/*==============================================================*/
create table Hotel 
(
   name                 long varchar                   not null,
   roomType             long varchar                   null,
   cityName             long varchar                   null,
   constraint PK_HOTEL primary key clustered (name)
);

/*==============================================================*/
/* Table: Reservation                                           */
/*==============================================================*/
create table Reservation 
(
   CheckInDate          date                           null,
   CheckOutDate         date                           null,
   RoomType             long varchar                   null,
   HotelName            long varchar                   null,
   ReservationId        integer                        not null,
   name                 long varchar                   null,
   Hot_name             long varchar                   null,
   CustomerName         long varchar                   null,
   constraint PK_RESERVATION primary key clustered (ReservationId)
);

/*==============================================================*/
/* Table: Room                                                  */
/*==============================================================*/
create table Room 
(
   roomType             long varchar                   not null,
   quantity             integer                        null,
   constraint PK_ROOM primary key clustered (roomType)
);

/*==============================================================*/
/* Table: ShoppingBasket                                        */
/*==============================================================*/
create table ShoppingBasket 
(
   CustomerName         long varchar                   null,
   ReservationId        integer                        not null,
   name                 long varchar                   null,
   constraint PK_SHOPPINGBASKET primary key clustered (ReservationId)
);

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

alter table Hotel
   add constraint FK_HOTEL_REFERENCE_CITY foreign key (cityName)
      references City (cityName)
      on update restrict
      on delete restrict;

alter table Reservation
   add constraint FK_RESERVAT_REFERENCE_CUSTOMER foreign key (name)
      references Customer (name)
      on update restrict
      on delete restrict;

alter table Reservation
   add constraint FK_RESERVAT_REFERENCE_HOTEL foreign key (Hot_name)
      references Hotel (name)
      on update restrict
      on delete restrict;

alter table ShoppingBasket
   add constraint FK_SHOPPING_REFERENCE_RESERVAT foreign key (ReservationId)
      references Reservation (ReservationId)
      on update restrict
      on delete restrict;

alter table ShoppingBasket
   add constraint FK_SHOPPING_REFERENCE_CUSTOMER foreign key (name)
      references Customer (name)
      on update restrict
      on delete restrict;

数据库逻辑模型于领域模型的异同：
领域模型是一个商业建模范畴的概念，它和软件开发无关系。即使一个企业不开发软件也应该有业务模型。

数据模型是系统设计以及实现的一部分。描述的是对用户需求在技术上的实现方法，用户不需要关心系统的数据模型，但必须关注领域模型。

用例建模

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

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

• 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例
• 尽可能识别外部系统，并用色彩标注新的外部系统和服务
  
  绿色是创新用例，红色是外部系统

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

  在项目早期要参考与本产品类似的产品，了解其实现的功能，并且画出核心用例图。然后根据调查了解本土用户对于产品的需求，对产品进行赶紧核创新。

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

业务建模

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

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

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

用例文本编写

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

• use case:
  • 优点：明确系统边界，展示了系统及其使用者，用例以及子用例
  • 缺点：用例之间关系不明确
• activity diagram
  • 优点：展示了用例的完整使用流程。可以使用活动图将重要场景描述出来
  • 缺点：无法描述多个用例过程
• 多泳道图：
  • 优点：清晰的看到了每个用例发生在哪个参与者或系统中
  • 缺点：无法区分系统边界

Vue.js

声明式渲染

<div id="app">
  {{ message }}
</div>

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

通过渲染这种方式我们可以将数据和DOM建立关联。

条件与循环

条件

<div id="app-3">
  <p v-if="seen">现在你看到我了</p>
</div>

var app3 = new Vue({
  el: '#app-3',
  data: {
    seen: true
  }
})

在这个例子中，我们把数据绑定到了DOM结构。

循环

<div id="app-4">
  <ol>
    <li v-for="todo in todos">
      {{ todo.text }}
    </li>
  </ol>
</div>

var app4 = new Vue({
  el: '#app-4',
  data: {
    todos: [
      { text: '学习 JavaScript' },
      { text: '学习 Vue' },
      { text: '整个牛项目' }
    ]
  }
})

处理用户输入

<div id="app-5">
  <p>{{ message }}</p>
  <button v-on:click="reverseMessage">逆转消息</button>
</div>

var app5 = new Vue({
  el: '#app-5',
  data: {
    message: 'Hello Vue.js!'
  },
  methods: {
    reverseMessage: function () {
      this.message = this.message.split('').reverse().join('')
    }
  }
})

v-on是一个事件监听器，我们可以通过它来调用在vue实例中的监听方法

一切的开始

var vm = new Vue({
  // 选项
})

我们可以通过传入选项来控制vm的行为。一个Vue应用由一个根Vue实例以及可选的嵌套的，可复用的组件树组成

生命周期钩子

在生命周期的各个阶段，我们都可以添加钩子函数，来为vue添加不同的方法。以created为例：

new Vue({
  data: {
    a: 1
  },
  created: function () {
    // `this` points to the vm instance
    console.log('a is: ' + this.a)
  }
})
// => "a is: 1"

简答题

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

• 瀑布模型

  • 优点：

    • 降低软件开发的复杂程度，提高软件开发过程的透明性，提高
    • 推迟软件实现，强调在软件实现前必须进行分析和设计工作软件开发过程的可管理性
    • 以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，使产品达到预期的质量要求

  • 缺点：

    • 强调过程活动的线性顺序
    • 缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题
    • 风险控制能力较弱
    • 瀑布模型中的软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量
    • 管理人员如果仅仅以文档的完成情况来评估项目完成进度，往往会产生错误的结论
• 增量模型
  • 优点：
    • 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
    • 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
    • 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
  • 缺点：
    • 要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。
      -螺旋模型
  • 优点：
    • 设计上的灵活性,可以在项目的各个阶段进行变更。
    • 以小的分段来构建大型系统,使成本计算变得简单容易。
    • 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
    • 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
    • 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
  • 缺点：
    • 很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

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

1. 用例驱动既做到了以客户为中心，以客户的角度看系统，为客户创建真正可用的系统的构造方式，又解决了传统面向对象方法面临的无法有效的从需求中提取对象的困难，从而填平了需求分析方法和对象设计方法之间的鸿沟。

• 以架构为中心，坚持综合考虑软件系统的各个方面，并优先解决各个方面的主要问题，同时创建常见问题的通用解决方案，从而为解决软件项目的主要风险、准确估算项目进度、提高软件复用、保证软件的整体风格打下了坚实基础。
• 迭代和增量式开发，以风险为驱动，分阶段针对不同的风险制定对策，以保证软件项目的成功完成。

1体现用户驱动的开发，3体现风险驱动开发。

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

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

细化阶段：进化软件构架；里程碑：生命期构架；

构造阶段：构造软件；里程碑：初试运作功能：

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

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

工期是提前协议好了，每一个阶段都有规定的完成时间，不能随意更改。而质量则是提前规定好的交付条件。因此只有项目/内容是易于控制的。其它都不能控制。

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

因为UP的软件生命周期被分为四个阶段，每个阶段是两个主要里程碑的分隔。在每个阶段结束时，我们根绝执行评估阶段目标来决定是否进入下一个阶段。因此UP提供了固定节奏的生产。

与此同时，UP是一个风险驱动的生命周期模型。UP通过渐进的方式进行演进，以此来有效控制风险。在软件生命周期中，每个阶段被划分为多个迭代，每个迭代确定一个内部里程碑，因此，UP也为固定周期发布软件产品提供依据。

项目管理使用

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

• 每个人的任务是明确的。即一周后可以看到具体成果
• 每个人的任务是1-2项。
• 至少包含一个团队活动任务

简答题

软件工程的定义

软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

解释software crisis、COCOMO 模型。

Software Crisis:软件危机是指早期在计算机领域中没有办法在给定时间内写出高效有用的代码。软件危机的成因是计算机的快速发展和待解决问题的复杂度急速上升。随着软件复杂度上升以及现有方法的低效，很多软件问题出现了。

COCOMO：Constructive Cost Model是一个由Barry W.Boehm提出发展的软件代价评估模型。模型的参数来源于将历史项目的数据放入回归公式中。COCOMO可以应用于三种软件项目

• Organic projects
• Semi-detached projects
• Embedded projects

软件生命周期

在软件工程中，软件开发过程是把软件开发划分为不同的阶段来提高设计，产品管理和项目管理。因此它又被称作是软件生命周期。软件生命周期可分为六个阶段：

• 可行性分析与计划阶段
• 需求分析阶段
• 设计阶段
• 实现阶段
• 测试阶段
• 运行与维护阶段

大部分现代开发过程都可以称之为敏捷开发。其他的开发模型还包括瀑布，原型，迭代，增量，螺旋等等。

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

• Software requirements（软件需求）
• Software design（软件设计）
• Software engineering management（软件工程管理）
• Software engineering process（软件工程过程）
• Software engineering models and methods（软件工程模型与方法

解释 CMMI 的五个级别

1. 初始级：软件工程管理制度缺乏，过程缺乏定义、混乱无序。成功依靠的是个人的才能和经验，经常由于缺乏管理和计划导致时间、费用超支。
2. 可重复级：基于类似项目中的经验，建立了基本的项目管理制度，采取了一定的措施控制费用和时间。管理人员可及时发现问题，采取措施。一定程度上可重复类似项目的软件开发。
3. 已定义级：已将软件过程文档化、标准化，可按需要改进开发过程，采用评审方法保证软件质量。
4. 已管理级：针对制定质量、效率目标，并收集、测量相应指标。利用统计工具分析并采取改进措施。对软件过程和产品质量有定量的理解和控制。
5. 优化级：基于统计质量和过程控制工具，持续改进软件过程。质量和效率稳步改进。

SWEBok

软件工程知识体系指南：一个职业在核心知识体系上达成一致，是所有学科的关键里程碑。这本指南清晰的指出了知识体系是发展一个职业关键的一步。因为它代表了对于软件工程专业人员应该知道什么的一个广泛的一致意见。没有这样的一致，就没有任何职业许可的考试。就不能为专业人员参与考试准备课程表。也不能形成一个认证一个课程表的准则。达成一致也是一个组织中采纳发展连贯技能和继续职业教育程度的前提。

SWEBok的目标是促进世界范围内对软件工程的一致观点。阐明软件工程相对其他学科的位置，确立分界。刻画软件工程学科的内容。提供使用知识体系的主题。为卡法课程表和个人认证与许可材料提供一个基础。

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

阅读《现代软件工程》的 PSP: Personal Software Process 章节。

http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html

按表格 PSP 2.1， 了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？

一个软件工程师在接到任务之后需要：

1. 计划任务需要时间
2. 开发
   1. 需求分析
   2. 生成设计文档
   3. 设计复审
   4. 代码规范
   5. 具体设计
   6. 具体编码
   7. 代码复审
   8. 测试
3. 报告
   1. 测试报告
   2. 计算工作量
   3. 总结，提出改进计划。

根据需要做的事，我们可以给出一个软件工程师所需要的技能有需求分析，开发，测试，写文档以及工作总结能力。