用例图

顺序图

类图

本项目树状结构

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

软件架构：软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

软件框架：软件框架是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

区别：框架是一种软件、半成品。架构不是软件，而是关于软件如何设计的重要策略。

联系：架构可以以框架的方式实现，所以软件架构可以借助已存在的框架来构造。

###2.以你的项目为案例

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

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

  1. 开发人员可以只关注整个结构中的其中某一层；
  2. 可以很容易的用新的实现来替换原有层次的实现；
  3. 可以降低层与层之间的依赖；
  4. 有利于标准化；
  5. 利于各层逻辑的复用。

###3.研究 VUE 与 Flux 状态管理的异同 VUE：它采用集中式存储管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。提供了诸如零配置的 time-travel 调试、状态快照导入导出等高级调试功能。

Flux：Flux是一套架构模型，将Web应用的各个主要功能以组件的形式进行划分，并进一步划分子组件。而各组件又以动作、存储器和视图来进行架构分层。

联系：vuex是flux的一种实现

区别：VUE是一个构建数据驱动的web界面的渐进式框架。 Flux是一种前端状态管理架构思想。

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

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

2.

SET NAMES utf8;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
--  Table structure for `Hotels`
-- ----------------------------
DROP TABLE IF EXISTS `Hotels`;
CREATE TABLE `Hotels` (
  `id` int(11) NOT NULL,
  `name` varchar(255) NOT NULL,

  `city` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- ----------------------------
--  Table structure for `Orders`
-- ----------------------------
DROP TABLE IF EXISTS `Orders`;
CREATE TABLE `Orders` (
  `id` int(11) NOT NULL,
  `userId` int(11) NOT NULL,
  `roomId` int(11) NOT NULL,
  `start` date NOT NULL,
  `end` date NOT NULL,
  PRIMARY KEY (`id`),
  KEY `roomId` (`roomId`),
  CONSTRAINT `roomId` FOREIGN KEY (`roomId`) REFERENCES `Rooms` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- ----------------------------
--  Table structure for `Rooms`
-- ----------------------------
DROP TABLE IF EXISTS `Rooms`;
CREATE TABLE `Rooms` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `cost` decimal(10,0) NOT NULL,
  `hotelId` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `hotelId` (`hotelId`),
  CONSTRAINT `hotelId` FOREIGN KEY (`hotelId`) REFERENCES `Hotels` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

SET FOREIGN_KEY_CHECKS = 1;

3.

简述 领域模型 在项目开发中的作用

领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。

简述 数据库模型 与 领域模型 的差异

领域模型是一个尽可能贴近真实流程的模型，是基于需求驱动的，不关心与需求无关的，如数据保存等。

假设你主导软件数据设计评审，你认为需要哪些准备文档，会关注哪些要素（不能超过 5 个）。百度哦！

需求分析文档、软件设计文档、数据库设计文档

要素：

1. 设计是否满足软件设计的一般要求
2. 表结构是否合理
3. 是否遵循统一的命名规范

###用例建模

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

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

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

以去哪儿酒店系统为例，流程如下：

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

与Asg_RH相比，去哪儿的酒店预订流程更加闭环，提供给了用户更丰富的信息和更多样的决策方式 在项目早期，可以通过用例图的方式寻找不足，使得功能更加完善，更加符合用户习惯

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

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

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

###用例文本编写

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

摘要 brief 摘要的简洁明了，重点突出，框架明显，但没有细节阐述

非正式 casual 编写简单，相比摘要有更多的细节描述，对问题分析更加深入，但不够正式，精细化程度不足

详述 fully 结构清晰，细节丰富，认识深入全面，但编写耗时长，比较繁琐

React

React 是一个用来构建用户界面的 JavaScript 库，近年来发展迅速，相关生态建设十分繁荣，它主要具有以下特性：

• 声明式编程。开发者只需为简单的为应用的每个状态（state）设计视图（view），业务逻辑只需要关注数据操作，这样当数据改变时，React 将高效地更新渲染出正确的视图。视图采用声名式的方式编写，使得代码更加可预测和易于调试。

• 组件化。React 代码组织方式为组件（Component）的形式。每个组件包含有各自的状态（state）、逻辑和需渲染的视图内容，构建出组件后，再将这些组件进行组合来构建复杂的用户界面。这使得代码组成更加模块化，重用代码代码也更加容易。并且组件逻辑由 JavaScript 编写而不是固定在视图模板中，这可以更加轻易的在应用中传递、处理复杂数据，并保持了应用状态与 DOM 的分离、使代码逻辑更加清晰更易于维护。

• 可使用于多平台。React 并不依赖于其他的技术栈，所以在现有项目中引入 React 时并不需要覆写原有代码。并且 React 可以在使用 Node.js 时实现服务端渲染，并且借助 React Native 可咦提供实现原生移动 App 的能力。

React-Router

React-Router 是一个基于 React 的强大前端路由库，库中提供了一系列声明式的导航组件（Navigational Components），通过这些组件可以方便的管理 URL，并实现组件的切换和状态的变化。

通过 React-Router 可以很便捷地搭建 SPA (Single Page Application，即单页应用）。SPA 通过 AJAX 实现页面局部更新而避免了页面整体重加载，减少了不必要的渲染并消除了重加载所需的等待时间，在􏰁极大提升了用户体验的同时，大大降低了 Web 应用服务端的渲染负担，􏰁提高整个 Web 应用服务的效率。

Redux

React 只是一个视图层的库，是 DOM 的一个抽象层，并不是一套 Web 前端应用的完整解决方案，其本身并没有提供完整的状态管理机制，这在应用包含复杂的业务逻辑时状态变的难以操控。

Redux 是 Flux 模式[标注] 的一种实现，是一个 JavaScript 的状态容器，可以提供可预测化的状态管理。

将整个应用的状态抽离，配合 react 的state -> view 的模式，使 Web 应用成为一个状态机，视图与状态是一一对应的。

使得调试更为简单开发体验，可以提供时间旅行式的调试。

1、简答题

• 简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。
• 简述 UP 的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？
• UP 四个阶段的划分准则是什么？关键的里程碑是什么？
• IT 项目管理中，“工期、质量、范围/内容” 三个元素中，在合同固定条件下，为什么说“范围/内容”是项目团队是易于控制的
• 为什么说，UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据？

2、项目管理使用

• 使用截图工具（png格式输出），展现你团队的任务 Kanban，请注意以下要求
• 每个人的任务是明确的。即一周后可以看到具体成果
• 每个人的任务是1-2项。
• 至少包含一个团队活动任务

回答

1-1

瀑布模型：优点：保证整个软件产品较高的质量，保证缺陷能够提前被发现和解决。缺点：导致项目人力资源过多闲置

增量模型：优点：控制前期风险并解决。 缺点：要求在软件需求规格说明书全部出来后后续的设计开发再进行增量

螺旋模型：优点：随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目。 缺点：对于每一次迭代都要制定出清晰的目标,分析出相关的关键风险和计划中可以验证和测试的交付物。

1-2：

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

1-3：

1. 初始阶段：为系统建立商业案例和确定项目的边界。里程碑：生命周期的目标
2. 细化阶段：分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。里程碑：生命周期的结构
3. 构造阶段：所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。里程碑：初始运作能力
4. 交付阶段：将软件产品交付给用户群体。里程碑：产品发布

1-4：

工期是在合同中规定的，质量也由甲方觉得（合同里包含最后验收的条件）。范围/内容是项目团队在具体实践中真正实现的东西，可以通过不停迭代、增量以扩大范围、完善内容等。

1-5：

因为up有明确的时间限制，每经过一个周期，就会迭代出一个新的产品。

2：

1、简单题

• 软件工程的定义
• 阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型。
• 软件生命周期。
• 按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？
• 解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。
• 用自己语言简述 SWEBok 或 CMMI （约200字）

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

阅读《现代软件工程》的 PSP: Personal Software Process 章节。 http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html 按表格 PSP 2.1， 了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？ （期末考核，每人按开发阶段提交这个表）

回答

1-1：

是指导计算机软件开发和维护的工程学科。

采用工程的概念、原理、技术和方法来开发与维护软件，把经过实践考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

1-2:

software crisis： 软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

cocomo： 从本质上说是一种参数化的项目估算方法，参数建模是把项目的某些特征作为参数，通过建立一个数字模型预测项目成本（类似于居住面积作为参数计算的整体的住房成本）。

1-3：

从时间角度，把整个周期划分为若干个阶段。

划分的原则:各阶段的任务彼此间尽可能相对独立，同 一个阶段各项任务的性质尽可能相同，从而降低每个阶 段任务的复杂性，简化不同阶段之间的联系，有利于软 件开发过程的组织管理。受软件规模、性质、种类、开 发方法等因素的影响。

1-4:

软件需求、软件设计、软件构造、软件测试、软件质量

1-5：

1. 初始级：无序、自然发生
2. 已管理级：需求管理、项目策划、项目监控、测量与分析、过程和产品质量保证、供方协议管理
3. 已定义级：决策分析与定义、组织过程定义、组织过程焦点、技术解决方案、确认验证、组织培训、需求开发、集成项目管理、风险管理、产品集成、风险管理
4. 定量管理级：组织过程绩效、定量项目管理
5. 优化级：原因分析和决定、组织创新和部署

1-6：

CMMI：是通过成熟度，将若干个过程区域分成了5个成熟级别，给使用这个模型的组织一个比较容易实现的过程改进发展道路。

2：

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。