Xiaowu/20230322 (microsoft#787)

* update

* update

* Update 12.0 技术架构.md

* update

* Update 13.7 手机Edge浏览器概要设计.md

* update

* update

* update

* update

* update

* Update 14.3 第1步：用例分析与数据流图.md

* update

* Update 14.3 第1步：用例分析与数据流图.md

* update

* Update 14.3 第1步：用例分析与数据流图.md

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* update

* Update 14.9 第7步：接口设计.md

* update

* update

* update

* update

* update

基础教程/A5-现代软件工程（更新中）/第1步 - 软件与工程/第1章 - 软件与工程/与架构相关的概念.md

@@ -0,0 +1,48 @@
+
+
+
+
+
+
+软件工程的三要素：方法、工具、过程
+
+方法
+
+方法一词的产生有两个由来：
+
+1. 与工匠有关。
+
+    墨子说：“轮人（做车的工匠）操其规，将以度量天下之圆与不方圆。曰中吾规者谓之圆，不中吾规者谓之不圆，则圆法明也。匠人亦操其矩，将以度量天下之方与不方也。曰中吾矩者谓之方，不中吾矩者谓之不方，则**方法**明也。” 大概意思是做木工活的时候，工匠用特殊的工具来度量木材是否是圆的或方的，由此我们知道了**规矩**和**方法**的来历，只是**圆法**这个词并没有流传下来。
+
+2. 与中医有关。
+
+    传说我国古代有一位皇帝患上了噎膈病，进食即吐，找了很多医生开了许多方子，都没有见效。最后请来一位隐居的和尚，经过一番望、闻、问、切，拟出一方，让太监速去取药。可太监拿到药方后，不由一愣，自言自语道：“什么高明医术？这不和之前医生所开方药一模一样吗？” 和尚拿过前医所开药方一看，药味、药量均与他分毫不差，但只是沿用传统的水煎口服，而皇帝现如今是滴水不进，何况药液？于是和尚亲自把药熬好，并浓缩到只剩下两匙勺，让皇帝拿小勺把药盛到嘴里用舌头慢慢舔尽，如此反复直至把药液舔完为止。连服数剂药之后，病果然大有起色。
+
+    和尚解释说：“医者，既要有方，又要有法。前医之方虽对症，但用法不对。皇上饮药反胃都吐了出来，自然不能发挥作用；而我让皇上舔取精华，量少而不反胃，乃是据症选法。” 皇帝听后，恍然大悟说道：“方法，方法，**方**与**法**结合也。” 从此，便产生了**方法**一词。
+
+所以，方法其实是由“方”和“法”组成，方法既规矩，是一种知识体系或衡量标准。
+
+
+
+
+
+
+道：思想
+法：方法
+术：技术
+器：工具
+
+https://zhuanlan.zhihu.com/p/137343992
+
+
+https://blog.csdn.net/weixin_43914604/article/details/105047495
+
+https://blog.csdn.net/weixin_44529208/article/details/106359025?spm=1001.2101.3001.6650.11&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-11-106359025-blog-105047495.pc_relevant_recovery_v2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-11-106359025-blog-105047495.pc_relevant_recovery_v2&utm_relevant_index=21
+
+
+
+分析图：
+ - 要素（数据、元素、构件）
+ - 逻辑（功能，关系，业务）
+ - 模型（外观，界面，架构）
+

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第11章 - 原型开发/11.2 技术选型.md

@@ -188,3 +188,29 @@ ML-flow 是基于 Python 环境的，所以需要一台虚拟机部署，木头
 - Flask 是一个使用 Python 编写的轻量级 Web 应用框架。其 WSGI 工具箱采用 Werkzeug ，模板引擎则使用 Jinja2 。Flask也被称为 “microframework” ，因为它使用简单的核心，用 extension 增加其他功能。Flask没有默认使用的数据库、窗体验证工具。Flask 很轻，花很少的成本就能够开发一个简单的网站。非常适合初学者学习。Flask 框架学会以后，可以考虑学习插件的使用。例如使用 WTForm + Flask-WTForm 来验证表单数据，用 SQLAlchemy + Flask-SQLAlchemy 来对你的数据库进行控制。
 
 还有4、5个其它的框架，都有很多拥趸。对于我们这个系统，用户很少，所以对性能没什么要求，只要开发简单、能够稳定运行即可。所以最后木头选择了 Flask API，只用十几行代码就可以搞定框架部分，每个 API 定义一个函数，指定好传入的参数，非常的方便，调试也很简单。
+
+
+### 11.2.8 客户端软件选型
+
+||Solution|客户端逻辑|用户交互|安全透明|风险、缺点|服务器端|
+|-|-|-|-|-|-|-|
+|1|Python代码|客户端逻辑丰富，可以主动发起请求|需要客户端安装<br>Python库，命令行形式|可以看到源代<br>码，完全透明|有可能被<br>不小心改掉|Azure存储+REST API|
+|2|Python代码<br>打包成exe|客户端逻辑丰富，可以主动发起请求|不需要客户端安装<br>Python库，命令行形式|对客户不透明|有可能会不被信<br>任，需要签协议|Azure存储+REST API|
+|3|JS写客<br>户端并打包|客户端逻辑丰富，可以主动发起请求|独立exe，需要安装，有界面，可交互 | 对客户不透明 |有可能会不被信<br>任，需要签协议|Azure存储+REST API|
+|4|AzCopy + Curl|客户端逻辑丰富，可以主动发起请求|脚本，命令行形式|微软官方提供<br>的exe程序|无|Azure存储+REST API|
+|5|Storage Explorer|只能上传下载文件，无客户端逻辑，不智能|有界面，友好|微软官方<br>提供安装包	|无法与服务器交互	|Azure存储|
+|6|SFTP客户端（现有模式）|只能上传下载文件，无客户端逻辑，不智能|命令行形式，并且需要<br>人工（微信）通知|安全|需要维护<br>SFTP服务器，磁盘消耗大|VM + Disk|
+
+- 个人倾向于使用solution 1或4。
+- 如果用5，可以在上传完数据后，手动命令发起请求。
+- 如果仍然用6，必须在服务器端增加逻辑，把Disk File转换成Storage Blob存储，再进行后续操作。
+- 如果在服务器端监控上传数据行为，不能保证在将来的scenario变化（比如一天内需要上传多个数据文件）时服务器逻辑的正确性，从而给系统维护带来负担。
+
+关于主动发起请求的问题：
+- 客户端在上传完毕数据后，会自动给服务器发送REST API请求以启动推理服务。这是节约能耗和降低系统复杂度的最佳解决方案。
+
+关于客户端源代码的问题：
+- 在客户端的逻辑并不是很复杂，即使有源代码，也是比较少，比如50~200行以内。
+
+关于签协议问题：
+- 如果我们提供exe产品，需要客户信任该产品，微软方需承诺“不会窃取用户计算机信息”等。

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.0 技术架构.md

@@ -2,28 +2,28 @@
 
 <img src="img/Slide1.SVG"/>
 
-技术架构是一个很模糊的概念。
+技术架构是一个很模糊的概念，根据笔者的理解，它可以是逻辑架构、运行架构、数据架构、开发架构、物理架构的混合体，在第十三章中有更多的解释。在这里，读者可以理解为是软件系统的一种与技术相关的高层次的架构设计。
 
-<img src="img/Slide2.SVG"/>
-
-
-https://blog.csdn.net/lfsf802/article/details/8487990
+在本章中，木头会照例先讲一个技术架构演化的故事，拉进读者与技术架构的关系；然后列出了星形、串行、树形、环形四种类型的技术架构模式的拓扑结构、扩展模式、应用实例以及它们各自的优缺点；最后介绍了康威定律在 Cortana 中的具体体现。
 
-https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
-
-https://zhuanlan.zhihu.com/p/41395345
+<img src="img/Slide2.SVG"/>
 
-https://blog.csdn.net/Jayphone17/article/details/103651076
 
-https://zhuanlan.zhihu.com/p/41395345
+- 13种常见软件体系结构风格定义分析，Jayphone17（网名）
+  https://blog.csdn.net/Jayphone17/article/details/103651076
 
-https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-a55ad27726d6
+- Architectural patterns，Open Universiteit（组织）
+  https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-a55ad27726d6
 
-https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
+- 10 Common Software Architectural Patterns in a nutshell，Vijini Mallawaarachchi
+  https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
 
-https://max.book118.com/html/2016/1115/63079375.shtm
+- 软件体系结构风格案例分析，原创力（组织）
+  https://max.book118.com/html/2016/1115/63079375.shtm
 
-https://blog.csdn.net/hguisu/article/details/78259898
+- 事件驱动架构，阿里云（组织）
+  https://help.aliyun.com/document_detail/207135.html
 
+- 《从零开始学架构》，李运华，电子工业出版社
 
-https://help.aliyun.com/document_detail/207135.html
+- 《大型网址技术架构》，李智慧，电子工业出版社

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.2 技术架构模式.md

@@ -11,31 +11,19 @@
 2. 功能定义：定义这些部分各自完成的局部功能；
 3. 关系建立：建立这些部分相互沟通的机制，使之结合为一个整体，并完成这个整体所需要的所有功能。
 
-
-在软件系统设计中，有四种常用的架构方法：
-
-- RUP（Rational Unified Process）统一开发过程
-- UML（Unified Model Language）统一建模语言
-- TOGAF（The Open Group Architecture Framework）开发组织定义的架构框架
-- 其它流派
-
-我们在第十三章中还要重点讨论。
-
 #### 2. 什么是技术架构？
 
 在众多的架构组成中，技术架构定义为：
 
 $$
-技术架构 = 逻辑功能 + 数据存储 + 运行过程 + 软件开发 + 物理部署
+技术架构 = 逻辑功能 + 运行过程 + 数据存储 + 软件开发 + 物理部署
 $$
 
-这些概念还是很复杂，所以读者可以先简单地认为，技术架构包括设计、实现、部署的一系列方案的混合体，就是面向实现的架构设计，主要是给开发人员内部看的，用于统一认识。
+这些概念还是很复杂，所以读者可以先简单地认为，技术架构包括设计、实现、部署的一系列方案的混合体，就是面向技术实现的架构设计，主要是给开发人员内部看的，用于统一认识。
 
 #### **3. 什么是技术架构模式？**
 
-**模式**是主体行为的一般方式，包括科学实验模式（包括软件开发）、经济发展模式、企业盈利模式等，是理论和实践之间的中介环节，具有一般性、简单性、重复性、结构性、稳定性、可操作性的特征。
-
-我们经常说“从理论到实践，再从实践到理论”，其实就是为了总结出一个解决问题的通用思路来，这个思路就是模式。所以，模式解决某一类问题的方法论。
+**模式**是主体行为的一般方式，包括科学实验模式（包括软件开发）、经济发展模式、企业盈利模式等，是理论和实践之间的中介环节，具有一般性、简单性、重复性、结构性、稳定性、可操作性的特征。我们经常说“从理论到实践，再从实践到理论”，其实就是为了总结出一个解决问题的通用思路来，这个思路就是模式。所以，模式解决某一类问题的方法论。
 
 **技术架构模式**是在给定上下文中对软件构建中常见问题的通用的、可重用的解决方案。
 
@@ -70,10 +58,17 @@ $$
 - 反馈模式
 - 事件驱动模式（Event-driven pattern）
 
-一个复杂系统的技术架构是利用上面这些基本模式的一个或几个有机组合而成。当然，上面这些并不是全部，只是笔者认为比较重要的、在实际应用中经常被用到的模式。
+一个复杂系统的技术架构是利用上面这些基本模式的一个或几个有机组合而成。当然，上面这些并不是全部，只是笔者认为比较重要的、在实际应用中经常被用到的模式。如图 12.2.1 所示。
+
+<img src="img/Slide7.SVG"/>
+
+图 12.2.1 常见的技术架构模式
+
 
 ### 12.2.3 技术架构模式一览
 
+表 12.2.1 列出了上述技术架构的简单描述和软件质量评价。
+
 表 12.2.1 技术架构模式一览表
 
 |名称|简单描述|质量评价|

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.7 康威定律.md → 基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.7 软件的技术架构与康威定律.md

@@ -1,29 +1,31 @@
 
-## 13.7 康威定律
+## 12.7 软件的技术架构与康威定律
 
-康威定律是一句格言，指出“**一个团队设计的系统来通常反映了他们自己的组织沟通结构**”。它以计算机程序员梅尔文·康威的名字命名，他于1967年提出了这个想法。原文是：
+### 12.7.1 康威定律
 
-**Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.**
+康威定律是一句格言，指出“**一个团队设计的系统通常反映了他们自己的组织沟通结构**”。它以计算机程序员梅尔文·康威的名字命名，他于1967年提出了这个想法。原文是：
 
-笔者最初也是不明白康先生在讲什么，直到在写作的时候分析了微软 Cortana 的产品战略和系统架构之后，才恍然大悟。意思是说：假设一个组织内部有三部分人来共同完成一个项目（不一定是软件系统），那么系统设计中起码会有三个组成部分，因为每个组成部分是由三部分人之中的一部分来完成的。
+**Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.**
 
+笔者最初也是不明白康先生在讲什么，直到在写作的时候分析了微软 Cortana 的产品战略和系统架构之后，才恍然大悟。意思是说：假设一个组织内部有三个领导各自带领一个小组来共同完成一个项目（不一定是软件系统），那么系统设计中起码会有三个组成部分，因为每个组成部分是由一个小组来完成的。
 
-见图 13.7.1。
+图 12.7.1 对比了亚马逊的 Alexa 和微软的 Cortnan 的（简易）技术架构，用于说明康威定律。
 
 <img src="img/Slide20.SVG"/>
 
-图 13.7.1 亚马逊 Alexa 与 微软 Cortana 的对比
+图 12.7.1 亚马逊 Alexa 与 微软 Cortana 的对比
 
 图例：
 
-- 单箭头虚线：开发行为
-- 黄色开发者：外部开发者
-- 蓝色开发者：内部开发者
-- 蓝色虚线框：产品边界
-- 黄色虚线框：第三方服务
-- 带双箭头的实线：网络或数据通信
+- 单箭头虚线：开发行为。
+- 双箭头实线：网络或数据通信。
+- 黄色开发者：外部开发者。
+- 蓝色开发者：内部开发者。
+- 蓝色虚线框：产品边界。
+- 黄色虚线框：第三方服务。
+
 
-#### 13.7.1 半开放的亚马逊 Alexa
+### 12.7.2 半开放的亚马逊 Alexa
 
 亚马逊智能音箱产品 Alexa 无疑是一个**成功**的产品，在 2018 年的一个第三方的统计报告中的数字告诉我们：
 
@@ -33,20 +35,20 @@
 - Alexa 已经为人们唱了数百万此生日快乐歌，讲了超过 1 亿个笑话；
 - 热门技能包括：音频和音乐播放、游戏问答、智能家居控制、生活方式辅助、教育，等等。
 
-亚马逊的 Alexa 是一种半开放的环境。见图 xxx 左侧子图
+亚马逊的 Alexa 是一种半开放的环境。见图 12.7.1 左侧。
 
 在 Client 端就是一台音箱，具备 ASR（语音识别）和 TTS（文本转语音）功能，并通过互联网与 Server 端通信传输数据。
 
 在 Server 端开发了一套无代码/低代码的服务框架，第三方开发者在服务器上注册登录后，根据服务器端指定的流程，输入一些可定制的规则，完成两件事：1. 识别用户的语音问话的含义；2. 做出相应的响应。
 
 
-#### 13.7.2 封闭的微软 Cortana
+### 12.7.3 封闭的微软 Cortana
 
 微软的 Cortana 也无疑是一个**不成功**的产品。
 
 首先从定位上看，Alexa 是放在用户家里的，为用户提供生活服务；而 Cortana 是运行在计算机上的，局限在为用户提供工作助理功能上，这是先天性的缺陷。
 
-其次我们看看它的产品架构。在 图 13.7.1 中我们省去了很多架构的细节，关键的元素是开发者所处的位置：
+其次我们看看它的产品架构。在图 12.7.1 中我们省去了很多架构的细节，关键的元素是开发者所处的位置：
 
 - Alexa，开发者是第三方的，在虚线框外部；
 - Cortana，开发者是第一方，在虚线框内部。
@@ -67,9 +69,9 @@
 
 除此之外，还有一个天然的缺陷，就是 Cortana 被设定在“办公助理”的位置，那么谁会在办公室里对着 Cortana 大喊要做什么做什么呢？岂不是暴露了自己正在上班摸鱼的秘密？
 
-#### 13.7.3 假设 Cortana 有一个开放架构...
+### 12.7.4 假设 Cortana 有一个开放架构...
 
-所以，笔者自己在 Windows 现有的技术基础上构想了一个架构，如图 13.7.1 最右侧所示
+所以，笔者自己在 Windows 现有的技术基础上构想了一个架构，如图 12.7.1 最右侧所示
 
 - Cortana App 依然存在，由 Windows Team 维护；
 - 增加一个 Cortana（Assistant）UWP App，它对外可以接入第三方服务，对内可以被 Cortana App 通过 UWP 内部机制调用（相当于是一个本地启动的服务）。这样做的好处是：虽然 Cortana App 跟随 Windows 的发布节奏（至少半年才发布一次），但是 Cortana UWP 可以随时在 Windows 应用商店中发布，像普通的 UWP App 一样，自由地迭代更新。这个 UWP App 由 Cortana 项目组来负责。

基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第13章 - 概要设计/13.0 概要设计.md

@@ -4,7 +4,7 @@
 
 本章的标题是概要设计，但是在前面几个小节中讲述了大量的“架构设计”的知识。那么**概要设计**和**架构设计**之间的区别和联系是什么呢？
 
-在本章中，首先会澄清一些关于“设计”的概念；然后木头会给读者讲一个故事，引入架构设计的概念；接下来介绍几个主流的架构设计方法供大家参考；当然笔者也会从中总结出自己认为较为合理的架构设计的任务、关注点以及最佳实践。接下来会把架构设计降维到概要设计，成为一系列的基本的设计任务，并形成概要设计说明书。最后会讲到如何实现设计的核心目标，如性能、可用性、可扩展性等等。
+在本章中，首先会澄清一些关于“设计”的概念；然后木头会给读者讲一个故事，引入架构设计的概念；接下来介绍几个主流的架构设计方法供大家参考；当然笔者也会从中总结出自己认为较为合理的架构设计的任务、关注点，最重要的是**把架构设计降维到概要设计**，成为一系列的基本的设计任务以及最佳实践，并形成概要设计说明书；最后会讲到如何实现设计的核心目标，如性能、可用性、可扩展性等等。
 
 <img src="img/Slide2.SVG"/>