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

• 用例简介如下图
  • 搜索
    • 1.1 选择国家
    • 1.2 选择城市
    • 1.3 选择日期
    • 1.4 选择酒店
  • 选房
    • 2.1 选择房型
  • 支付
    • 3.1 确认订单
    • 3.2 支付方式
    • 3.3 确认支付
• 顺序图
• 类图

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

docker compose ?

docker-compose 是一个用来把 docker 自动化的东西。 有了 docker-compose 你可以把所有繁复的 docker 操作全都一条命令，自动化的完成。

环境

确保您已经安装了Docker Engine和Docker compose。您不需要安装Python或Redis，因为它们都由Docker images提供。

docker-compose 常用命令

Commands:
  build              Build or rebuild services
  bundle             Generate a Docker bundle from the Compose file
  config             Validate and view the compose file
  create             Create services
  down               Stop and remove containers, networks, images, and volumes
  events             Receive real time events from containers
  exec               Execute a command in a running container
  help               Get help on a command
  kill               Kill containers
  logs               View output from containers
  pause              Pause services
  port               Print the public port for a port binding
  ps                 List containers
  pull               Pull service images
  push               Push service images
  restart            Restart services
  rm                 Remove stopped containers
  run                Run a one-off command
  scale              Set number of containers for a service
  start              Start services
  stop               Stop services
  top                Display the running processes
  unpause            Unpause services
  up                 Create and start containers
  version            Show the Docker-Compose version information

• 解释一下

  build 构建或重建服务
  help 命令帮助
  kill 杀掉容器
  logs 显示容器的输出内容
  port 打印绑定的开放端口
  ps 显示容器
  pull 拉取服务镜像
  restart 重启服务
  rm 删除停止的容器
  run 运行一个一次性命令
  scale 设置服务的容器数目
  start 开启服务
  stop 停止服务
  up 创建并启动容器
  

  docker-compose 如何配置

  先看看一个 docker-compose.yml

  version: '2'
  services:
    nginx:
            image: bitnami/nginx:latest
            ports:
                - '80:80'
                - '1443:443'
            volumes:
                - /root/wp_yunlan/nginx/:/bitnami/nginx/
    mariadb:
            image: bitnami/mariadb:latest
            volumes:
                - /root/wp_yunlan/mariadb:/bitnami/mariadb
    wordpress:
            image: bitnami/wordpress:latest
            depends_on:
                - mariadb
                - nginx
            environment:
                - WORDPRESS_USERNAME=neptunemoon    #这个账户你是自己设定的
                - WORDPRESS_PASSWORD=123123         #这个密码是你自己设定的
            ports:
                - '8080:80'
                - '8081:443'
            volumes:
                - /root/wp_yunlan/wordpress:/bitnami/wordpress
                - /root/wp_yunlan/apache:/bitnami/apache
                - /root/wp_yunlan/php:/bitnami/php
  

• nginx 和 mariadb，wordpress 是要启动的三个服务
  • 顺序不是重要的,我们看见wordpress中有个 depends_on: 的属性
• depends_on: 依赖
  • 代表wordpress 依赖于
  • mariadb
  • nginx
  • 两个服务， 所以他们两个会先启动
• image: 镜像
  • 就是你的 docker 镜像
  • 我们用

    docker search mariadb
    

  • 找到我们需要的镜像
• environment 环境变量
  • 这个是在好理解不过的了。
  • 不过这和我们程序语言设计层面的还是不一样的，这个是容器层面的环境变量。
  • 如果我们写程序做一些逻辑判断的时候，肯定会使用
  • 比如我们判断现在的编译器，我们会使用
  • #if GNUC 或者 #if _MSC_VER
  • 相应的，我们的容器里面肯定也有这样的逻辑，我们经常使用环境变量来传值，或者定义一个行为。写过程序的人都懂。
• ports 端口映射
  • 映射本机还有镜像的端口。这个没有什么好说的。
• volumes 文件映射
  • 有两种格式，
  • 可以对应 docker 操作中的 -v my/path/:/docker/path
  • 还可以使用单方面的 -v /path
  • 这样的话 就相当于 一个匿名映射， 其实还是在本机有对应目录的。
  • 使用docker inspect -f /path 可以看到详细信息

docker-compose 需要注意的

• 不要把 docker 当做数据容器来使用，数据一定要用 volumes 放在容器外面
• 不要把 docker-compose 文件暴露给别人， 因为上面有你的服务器信息
• 多用 docker-compose 的命令去操作， 不要用 docker 手动命令&docker-compose 去同时操作
• 写一个脚本类的东西，自动备份docker 映射出来的数据。
• 不要把所有服务都放在一个 docker 容器里面

区别:

• 架构不是软件，而是关于软件如何设计的重要策略。软件架构决策设计到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中。
• 框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务尅被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。
• 架构先全局后局部。框架先通用后专用。架构是问题的抽象解决方案，它关注大局而忽略细节。而框架是通用半成品，还必须根据具体需求进一步定制开发才能变成应用系统。

联系

• 架构决策往往会体现在框架之中，框架技术和架构技术的出现，都是为了解决软件系统日益复杂所带来的困难而分而治之的结果。

以你的项目为案例

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

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

• 三层架构具有低耦合性、高重用性、较低的生命周期成本、快速部署、高可维护性、利于软件工程化管理等特性。
• 以我们的项目为例，如果我们要增添一个新的功能（比如后台添加成员管理），三层架构允许我们将任务合理地分配，表示层、业务层、持久化层各自的需求由不同的成员各自同时实现，到最后汇总即可，不会出现一环依赖另一环的情况，大大提高了开发者的工作效率。

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

异

flux

• 它分为四层：view视图层 action层 dispatcher派发层 store仓库层
• vuex适用于构建大型的项目，如果不是大型项目，使用vuex会使代码更加繁琐
• view——>action——>dispatcher——>store返回——>dispatcher——>view(接收的方法：register（）)

VUE

• vuex核心： 　　state：存放多个组件共享的状态（数据）

　　mutations：存放更改state里状态的方法，用于变更状态，是唯一一个更改状态的属性

　　getters：将state中某个状态进行过滤，然后获取新的状态，类似于vue中的computed

　　actions：用于调用事件动作，并传递给mutation

　　modules：主要用来拆分state

• vueComnent——>(dispatch)Action——>（commit）——>Mutations——>（mutate）State——>（render）VueComponent

同

flux

• 状态集管理框架，由facebook创建，专门用来构建前端框架结构的框架，便于维护，用于安全考虑

VUE

• vuex是专门为vue提供的状态管理工具
• 便于维护，保证安全，vue中引入vuex,解决状态之间共享的问题
• 多个组件调用一个状态，将原来组建与组件之间的状态传递改成组件与仓库之间的传递

• 建模工具： UMLet 14.1.1 stand-alone

请根据ofo共享单车App用车业务描述，绘制如下几个图：

• ofo共享单车App用车业务的用例图

  

• ofo共享单车App用车业务的活动图

  

• ofo共享单车App领域模型

  

• ofo共享单车App用车业务的状态图

  

• ofo共享单车App用车业务的系统顺序图与操作协议

  

• 建模工具： UMLet 14.1.1 stand-alone

1）使用 UML State Model

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

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

• 状态图如下：

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

• 状态图如下：

1、 领域建模

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

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

• task2

• answer

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

• 按 Task 3 要求，给出系统的 E-R 模型（数据逻辑模型）

• task3

• E-R

• 建模工具 PowerDesigner（简称PD） 或开源工具 OpenSystemArchitect
• 不负责的链接 http://www.cnblogs.com/mcgrady/archive/2013/05/25/3098588.html
• 导出 Mysql 物理数据库的脚本

/*==============================================================*/
/* DBMS name:      MySQL 5.0                                    */
/* Created on:     2018/4/28 22:34:28                           */
/*==============================================================*/


drop table if exists Bill;

drop table if exists Credit_Card;

drop table if exists Hotel;

drop table if exists Reservation;

drop table if exists Room;

drop table if exists Traveler;

/*==============================================================*/
/* Table: Bill                                                  */
/*==============================================================*/
create table Bill
(
   Price                double,
   Email                text,
   Card_Number          text,
   Bill_Number          text not null,
   Reservation_Number   text not null,
   primary key (Bill_Number)
);

/*==============================================================*/
/* Table: Credit_Card                                           */
/*==============================================================*/
create table Credit_Card
(
   Card_Number          text not null,
   Owner                text,
   Saving               double,
   Security_Code        text,
   primary key (Card_Number)
);

/*==============================================================*/
/* Table: Hotel                                                 */
/*==============================================================*/
create table Hotel
(
   Hotel_Name           text not null,
   City                 text,
   Address              text not null,
   primary key (Hotel_Name, Address)
);

/*==============================================================*/
/* Table: Reservation                                           */
/*==============================================================*/
create table Reservation
(
   Room_Number          text not null,
   Check_In             date not null,
   Check_Out            date not null,
   Hotel_Name           text not null,
   Address              text not null,
   Adult_Count          int,
   Child_Count          int,
   Child_Age            int,
   Price                double,
   Traveler_Name        text,
   Reservation_Number   text not null,
   Bill_Number          text not null,
   primary key (Reservation_Number)
);

/*==============================================================*/
/* Table: Room                                                  */
/*==============================================================*/
create table Room
(
   Room_Number          text not null,
   Hotel_Name           text,
   Address              text,
   Availability         bool,
   primary key (Room_Number)
);

/*==============================================================*/
/* Table: Traveler                                              */
/*==============================================================*/
create table Traveler
(
   Name                 text,
   Email                text not null,
   Smoking              bool,
   primary key (Email)
);

alter table Bill add constraint FK_Reference_3 foreign key (Email)
      references Traveler (Email) on delete restrict on update restrict;

alter table Bill add constraint FK_Reference_4 foreign key (Card_Number)
      references Credit_Card (Card_Number) on delete restrict on update restrict;

alter table Bill add constraint FK_Reference_6 foreign key (Reservation_Number)
      references Reservation (Reservation_Number) on delete restrict on update restrict;

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

alter table Reservation add constraint FK_Reference_5 foreign key (Hotel_Name, Address)
      references Hotel (Hotel_Name, Address) on delete restrict on update restrict;

alter table Reservation add constraint FK_Reference_6 foreign key (Bill_Number)
      references Bill (Bill_Number) on delete restrict on update restrict;

alter table Room add constraint FK_Reference_2 foreign key (Hotel_Name, Address)
      references Hotel (Hotel_Name, Address) on delete restrict on update restrict;

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

都常用于系统分析与设计，特别是涉及数据表的设计。不同之处在于，领域模型偏向概念，设计者无需考虑系统内数据的具体存放方式，而更需考虑如何结合系统用例以满足用户需求。数据库逻辑模型则更适用于软件开发者，它要求对数据库有较具体的设计，比领域模型考虑更细致。

1、 用例建模

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

• task1

• answer

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

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

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

• 时代进步很快，项目的设计要紧跟科技发展的潮流
• 要适应顾客心理活动规律
• 可以先在白板上画出用例图草图，与团队成员共同探讨、修改，从而确定重要的用例，采用迭代与进化式的开发，在迭代中逐渐明确需求，得出创新点。

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

• 搜索酒店
  进入网站，选择城市、日期、关键字，点击搜索 关键字选填
• 预订酒店 在酒店列表点击选择酒店，进入详情页，查看酒店信息，选择日期、房型后，点击预订 注意不成功场景的反馈
• 付款
  选择付款方式，输入密钥，进行付款 注意成功和不成功场景的反馈

2、业务建模

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

• 从活动图中寻找可以抽象、复用的部分，并把它们抽象为子用例。
• 沿着活动图图的开始状态，选择活动图中任意一个的分支点到活动图的结束状态，就是一个子用例.

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

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

3、用例文本编写

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

• 摘要，即一段简洁的概要，通常用在主成功场景。在我们点餐系统的Inception阶段，为了在便于在小 组会议上讨论主题和范围，进行早期需求的分析，会用到摘要式的用例文本。能快速编写、简洁明了是它的优点，但缺点就是不够细致，只用作对问题粗略的认识。

• 非正式，即多个非正式的段落格式，用几个段落覆盖不同场景，同样用于早期的需求分析过程，优点是编写简便，比起摘要式用例文本要详细一些，有利于进一步认识问题，缺点是不够正式，需要在后续阶段精化。

• 详述，即详细地编写用例所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。详述式用例文本通常用在以摘要形式编写了很多用例以后，详细地编写其中少量具有重要意义和价值的用例中，它的优点是细节充足，正式且深入，且具有结构性，缺点是编写耗时长，比较繁琐。

• Angularjs通过创建实时模板来代替视图，而不是将数据合并进模板后更新DOM，任何一个独立视图组件中的值都是动态替换的。

数据绑定和第一个AngularJS Web应用：

• 用法简单，只需引入Angular.js文件，并在某个DOM元素上明确设置ng-app属性即可，ng-app属性声明所包含的内容都属于这个Angularjs应用，这样我们就可以在web应用中嵌套Angularjs应用的原因，只有被具有ng-app属性的DOM元素包含的元素才会受到Angularjs影响。

模块：

• AngularJS允许我们使用angular.module()方法来声明模块，这个方法能够接受两个参数，第一个是模块的名称，第二个是依赖列表，也就是可以被注入到模块中的对象列表。 angular.module(‘myApp’, []);
• 带有属性ng-app的标签相当于一个模块，ng-app属性可以带属性值也可以不带，一个模块只允许加载一次，ng-app用来自动加载模块，bootstrap用来手动加载模块。 angular.module(‘appName’, []) angular.bootstrap(angular.element(“#divID”), [“divID”])

作用域：

• $scope 的使用贯穿整个 Angular App 应用,它与数据模型相关联,同时也是表达式执行的上下文。
• $scope对象的生命周期处理有四个不同阶段。
• 创建：在创建控制器或指令时，AngularJS会用$injector创建一个新的作用域，并在这个新建的控制器或指令运行时将作用域传递进去
• 链接：当Angular开始运行时，所有的$scope对象都会附加或者链接到视图中。所有创建$scope对象的函数也会将自身附加到视图中，这些作用域将会注册当Angular应用上下文发生变化时需要运行的函数。
• 更新：当时间循环运行时，它通常执行在顶层$scope对象上(被称作$rootscope)，每个子作用域都执行自己的脏值检测。每个监控函数都会检查变化，如果检测到任意变化，$scope对象就会触发指定的回调函数。
• 销毁：当一个$scope在视图中不再需要时，这个作用域将会清理和销毁自己。

控制器：

• AngularJS中的控制器是一个函数，用来向视图的作用域中添加额外的功能。由于AngularJS会负责处理控制器的实例化过程，我们只需编写构造函数即可。 AngularJS同其他JavaScript框架最主要的一个区别就是，控制器并不适合用来执行DOM操作、格式化或数据操作，以及除存储数据模型之外的状态维护操作。它只是视图和$scope之间的桥梁。

• 控制器可以嵌套，相当于继承，子控制器可以获取父控制器的属性

表达式：

#####特性：

• 1、所有表达式都在scope这个context里被执行，因此可以使用所有本地 $scope 中的变量。
• 2、如果一个表达式的执行导致类型错误或引用错误，这些错误将不会被抛出。
• 3、表达式里不允许任何控制函数流程的功能（如if/else等条件语句）

• 4、表达式可接受一个或多个串联起来的过滤器。

• $parse是一个表达式解析器，返回一个函数 app.controller(‘myController’,function($scope,$parse){}); $interpolate是一个带三个参数返回一个函数的服务 app.controller(‘myController’,function($scope,$interpolate){});

过滤器：

• 过滤：currency，date，filter(字符串,对象,函数)，json，limitTo，lowercase，number，orderBy，uppercase,自定义过滤器
• 表单验证：HTML5自带的表单验证使用很方便，只需给标签添加属性即可。
• 必填项：required
• 最小值：ng-minlength=”5”
• 最大值：ng-maxlength=”20”
• 正则：ng-pattern=”[a-zA-Z]”
• 电子邮箱：
• 数字：
• URL：

表单属性：

• user.name.$dirty(输入框使用了规则为True) 脏值检测
• user.name.$pristine(输入框没有使用规则为True)
• user.name.$invalid(是否验证未通过)
• user.submitted(是否提交)
• 错误信息(进行错误判断)

1.3版本以后新增了ng-messages属性， 相对于$error属性用起来会简洁一些 ng-message=”required”/ng-message=”minlength”

指令简介：

• 自定义指令 语法： directive(‘myDirective’,function(){})。 种类：元素（E）、属性（A）、类（C）或注释（M） 在我们的例子中使用my-directive声明指令，根据驼峰命名法，指令定义必须以myDirective为名字。(hello)

• 当前作用域：每个控制器都有自己的作用域，同时控制器可以嵌套，最内层的控制器可以通过当前$scope直接访问原型中的任意属性

指令详解：

• directive：对于指令，可以把它简单的理解成在特定DOM元素上运行的函数，指令可以扩展这个元素的功能。指令中我们可以返回函数也可以返回对象。当返回一个函数时，这个函数通常被称作链接传递（postLink）函数，利用它我们可以定义指令的链接（link）功能。由于返回函数而不是对象会限制定义指令时的自由度，因此只在构造简单的指令时才比较有用。
• priority：ngRepeat是所有内置指令中优先级最高的，设置为1000
• template：如果模板字符串中含有多个DOM元素，或者只由一个单独的文本节点构成，那它必须被包含在一个父元素内templateUrl：默认情况下，调用指令时会在后台通过Ajax来请求HTML模板文件。有两件事情需要知道。一、在本地开发时，需要在后台运行一个本地服务器，用以从文件系统加载HTML模板，否则会导致Cross Origin Request Script（CORS）错误。二、模板加载是异步的，意味着编译和链接要暂停，等待模板加载完成。scope：如果一个元素上有多个指令使用了隔离作用域，其中只有一个可以生效。只有指令模板中的根元素可以获得一个新的作用域。因此，对于这些对象来说scope默认被设置为true。作用域的继承机制是向下而非向上进行的。 scope：以下方式会创建新的子作用域，并且进行原型继承： ng-repeat、ng-include、ng-switch、ng-view、ng-controller, 用scope: true和transclude: true创建directive。
• transclude：只有当你希望创建一个可以包含任意内容的指令时，才使用transclude: true。
• link：指令中的controller和link函数可以进行互换。控制器主要是用来提供可在指令间复用的行为，但链接函数只能在当前内部指令中定义行为，且无法在指令间复用。还有个区别：Controller(在编译前执行)而Link(在编译后执行) 子级指令的所有 link function ：包括 pre 和 post 两个link都会在父级的post link之前被执行，我们通常所说的link function，其实是 post link 的快捷方式罢了。 当想要同当前屏幕上的作用域交互时，可以使用被传入到link函数中的scope参数。 directive的scope与其外层的controller的scope是同一个作用域
• controllerAs：使我们可以在路由和指令中创建匿名控制器的强大能力。这种能力可以将动态的对象创建成为控制器，并且这个对象是隔离的、易于测试的。
• require：可以被设置为字符串或数组，字符串代表另外一个指令的名字。require会将控制器注入到其值所指定的指令中，并作为当前指令的链接函数的第四个参数。require参数的值可以用下面的前缀进行修饰，这会改变查找控制器时的行为：
• ?：如果在当前指令中没有找到所需要的控制器，会将null作为传给link函数的第四个参数。
• ^：如果添加了^前缀，指令会在上游的指令链中查找require参数所指定的控制器。
• ?^：将前面两个选项的行为组合起来，我们可选择地加载需要的指令并在父指令链中进行查找。
• 没有前缀：如果没有前缀，指令将会在自身所提供的控制器中进行查找，如果没有找到任何控制器（或具有指定名字的指令）就抛出一个错误。
• conpile：编译函数负责对模板DOM进行转换。链接函数负责将作用域和DOM进行链接。在作用域同DOM链接之前可以手动操作DOM

多重视图和路由：

ng-view是由ngRoute模块提供的一个特殊指令，它的独特作用是在HTML中给$route对应的视图内容占位。它会创建自己的作用域并将模板嵌套在内部。ng-view是一个优先级为1000的终极指令。AngularJS不会运行同一个元素上的低优先级指令。ng-view不支持多层视图嵌套，可以考虑加强版的ui-view 路由：如果reloadOnSearch选项被设置为true（默认），当$location.search()发生变化时会重新加载路由。如果设置为false，那么当URL中的查询串部分发生变化时就不会重新加载路由。这个小窍门对路由嵌套和原地分页等需求非常有用。

• $location 服务：path()/replace()/absUrl()/hash()/host()/port()/protocol()/search()/url()
• $location服务不会重新加载整个页面，它只会单纯地改变URL。如果我们想重新加载整个页面，需要用$window服务来设置地址。$window.location.href = “/reload/page”;
• 路由模式：标签模式和HTML5模式(显示原始路径，如果路径是#/List/Add这种标签模式，它会自动重写URL)
• 路由事件：$routeChangeStart/$routeChangeSuccess/$routeChangeError/$routeUpdate

服务：

• 控制器只会在需要时被实例化，并且不再需要就会被销毁。这意味着每次切换路由或重新加载视图时，当前的控制器会被AngularJS清除掉。 服务提供了一种能在应用的整个生命周期内保持数据的方法，它能够在控制器之间进行通信，并且能保证数据的一致性。服务是一个单例对象，在每个应用中只会被实例化一次（被$injector实例化），并且是延迟加载的（需要时才会被创建）。服务提供了把与特定功能相关联的方法集中在一起的接口。 不推荐在控制器中使用$watch，这里只是为了方便演示。在实际生产中会将这个功能封装进一个指令，并在指令中设置$watch。 在自定义服务之前注入所有的AngularJS内置服务，这是约定俗成的规则。 所有创建服务的方法都构建在provider方法之上。provider()方法负责在$providerCache中注册服务。 如果希望在config()函数中可以对服务进行配置，必须用provider()来定义服务。 value()方法和constant()方法之间最主要的区别是，常量可以注入到配置函数中，而值不行。通常情况下，可以通过value()来注册服务对象或函数，用constant()来配置数据，constant定义的常量不能被装饰器拦截。

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

瀑布模型

• 优点： 为项目提供了按阶段划分的检查点 当前阶段完成后，只需要关注后续阶段 可在迭代模型中应用
• 缺点： 在项目各个阶段之间极少有反馈 只有在项目生命周期的后期才能看到结果 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

增量模型

• 优点： 人员分配灵活，刚开始不用投入大量的人力资源。 如果核心产品很受欢迎，则可增加人力实现下一个增量能有计划地管理技术风险
• 缺点： 如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定 如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布 由于进度和配置的复杂性，可能会增大管理成本，超出组织的能力

螺旋模型

• 优点： 设计上的灵活性，可以在项目的各个阶段进行变更 以小的分段来构建大型系统，使成本计算变得简单 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性 使客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
• 缺点： 很难让用户确信这种演化方法的结果是可以控制的 建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求

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

• 用例驱动
• 以架构为中心的
• 受控的迭代式增量开发

其中，用例驱动、受控的迭代式增量开发体现用户驱动开发，2体现风险驱动开发

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

• 初始：大体上的构想、业务案例、范围和模糊评估。
• 细化：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。
• 架构：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。
• 移交：进行beta测试和部署。
• 里程碑：迭代的结束点，此时有重要决策或评估产生。

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

• 工期是在合同里面确定好的，项目的每一个阶段都有规定的完成时间，不能随意更改。而客户在合同中也规定好了项目的验收条件，质量也是不由团队控制的。范围/内容是由团队控制的，因为只有由团队来控制，项目才能够顺利完成。

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

• UP中，软件开发生命周期根据时间（固定周期发布）和RUP的核心工作流（固定节奏生产）划分为二维空间。时间维从组织管理的角度描述整个软件开发生命周期，是RUP的动态组成部分，核心工作流从技术角度描述RUP的静态组成部分。

项目管理使用

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

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

Software Engineering Definition

• 1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。

软件工程包括两种构面：软件开发技术和软件项目管理。

• 软件开发技术：软件开发方法学、软件工具和软件工程环境。
• 软件项目管理：软件度量、项目估算、进度控制、人员组织、配置管理、项目项目等。

Software crisis

• 软件危机（英语：Software Crisis）是早期计算机科学的一个术语[1]，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。[2]软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。[3]软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。

软件危机其原因，衔接到硬件的整体复杂度，与软件开发流程。危机表现在几个方面：

• 项目运行超出预算。
• 项目运行超过时间。
• 软件质量低落。
• 软件通常不匹配需求
• 项目无法管理，且代码难以维护。

硬件成长率每年大约30％，软件每年只勉强以4～7％速度在成长，信息系统的交付日期一再延后，许多待开发的软件系统无法如期开始。1960年代软件开发成本占总成本20％以下；1970年代软件成本已达总成本80％以上，软件维护费用在软件成本中高达65％。1986年公布的数据，所有验收的外包软件中，竟然只有4％可用，其余96％却是不堪一用。大部分的企业自行开发的信息系统中，有四分之三也是功败垂成。因此软件维护成本居高不下，软件产品质量低落是最主要的原因。

COCOMO模型

COCOMO，英文全称为Constructive Cost Model，中文为结构性成本模型。它是由巴里·勃姆（Barry Boehm）提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式，使用从项目历史和现状中的某些特征作为参数来进行计算。 COCOMO模型可以分为三个层次：

• 基本COCOMO：适用对软件开发进行快速、早期地对重要的方面进行粗略的成本估计，但因其缺少不同的项目属性（“成本驱动者”）的因素，所以准确性有一定的局限性。
• 中级COCOMO：考虑进了这些成本驱动者。
• 详细COCOMO：加入了对不同软件开发阶段影响的考量。

SDLC

软件生命周期(Software Life Cycle,SLC)又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。

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

• Software requirements (软件需求)
• Software design（软件设计）
• Software construction（软件构造）
• Software engineering tools and methods（软件工程工具与方法）

解释 CMMI 的五个级别

• level1-Initial：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
• level2-Managed：建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的 成功经验。第二级共7个过程域：需求管理、项目规划、项目跟踪与控制、供应商协议管路、度量与分析、过程与产品质量保证、配置管理。
• level3-Defined：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。第二级共14个过程域：需求开发、技术解决方案、产品集成、验证、确认、组织过程焦点、组织过程定义、组织培训、集成项目管理、风险管理、决策分析和解决、集成团队、集成组织环境、集成供应商管理。
• level4-Quantitatively Managed：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。第四级共两个过程域：组织过程性能、量化项目管理。
• level5-Optimizing：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。第五级共两个过程域：组织创新与部署、原因分析与决策。

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

• CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型）[1] ，是美国国防部的一个设想，1994年由美国国防部（United States Department of Defense）与卡内基-梅隆大学（Carnegie-Mellon University）下的软件工程研究中心（Software Engineering Institute，SEISM）以及美国国防工业协会（National Defense Industrial Association）共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的前提条件是该企业具有有效的软件企业认定证书。
• 其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
• CMMI是一套融合多学科的、可扩充的产品集合， 其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。CMMI的本质是软件管理工程的一个部分。软件过程改善是当前软件管理工程的核心问题， 50多年来计算机的发展使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。基于模型的过程改进是指采用能力模型来指导组织的过程改进，使之过程能力稳定的进行改善，该组织也能变得更加成熟。

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

• 阅读《现代软件工程》的 PSP: Personal Software Process 章节。 http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html

• 按表格 PSP 2.1， 了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？ （期末考核，每人按开发阶段提交这个表）

• 统计数据可以按照下表统计

  Personal Software Process Stages	Time (%)
  计划
  ·         估计这个任务需要多少时间
  开发
  ·         需求分析 (包括学习新技术)
  ·         生成设计文档
  ·         设计复审 (和同事审核设计文档)
  ·         代码规范 (为目前的开发制定合适的规范)
  ·         具体设计
  ·         测试（自我测试，修改代码，提交修改）
  报告
  ·         测试报告
  ·         计算工作量
  ·         事后总结, 并提出过程改进计划