Hi, I'm Carrie Anne and welcome to Crash Course Computer Science! 嗨，我是 Carrie Anne，欢迎收看计算机科学速成课！ Today we start our journey up the ladder of abstraction, 今天我们开始"抽象"的旅程 where we leave behind the simplicity of being able to see every switch and gear, 不用管底层细节，把精力用来构建更复杂的系统 but gain the ability to assemble increasingly complex systems. 不用管底层细节，把精力用来构建更复杂的系统 Last episode, we talked about how computers evolved from electromechanical devices, 上

Hi I'm Carrie Anne, this is Crash Course Computer Science 嗨，我是 Carrie Anne，欢迎收看计算机科学速成课！ and today we're going to talk about how computers store and represent numerical data. 今天，我们讲计算机如何存储和表示数字 Which means we've got to talk about Math! 所以会有一些数学 But don't worry. 不过别担心 Every single one of you already knows exactly what you need to know to follow along. 你们的数学水平绝对够用了 So, last episode we talked about how transistors can be used to build logic gates, 上集我们

软件产品线体系结构是对上述一系列软件核心部分的设计，既然是对核心部分的设计，那么它是没有包含对核心部分之外的其他部分的设计的，所以需要针对具体的软件来具体补充。

当一个公司需要开发一系列不同但是相似的软件的时候，并不是单独开发的，而是开发这些软件的核心部分，然后在核心部分的基础上补充其他部分，来构成不同软件，这样可以很大程度上节约成本提高开发效率。因此，公司需要有核心部分开发组开发核心部分、产品开发组开发其他部分并构成软件，以及管理组协调核心部分开发组和产品开发组之间的关系。

组件是观察者类和被观察类，如果需要被观察类的对象变化能够引起观察者类的对象变化，那么就需要在观察者类中引用被观察类的对象，以获得变化，也需要在被观察类中引用观察者类的对象，以通知发生了变化。

组件是中介者类，当多个类之间的交互比较复杂的时候，可以让这些类不直接交互，而是通过中介者类交互，这样可以降低设计的复杂性。中介者模式和上述的外观模式非常像，后者关注的是模块内外类的交互，而前者是任意类的交互。

组件是数据处理类，当需要根据数据的不同使用完全不同方法处理数据的时候，可以把每一种方法放到一个数据处理类里面，然后串联这些数据处理类。这样数据先输入第一个数据处理类，如果该类能够处理，则处理完毕，如果不能处理，则把该数据转发到下一个数据处理类，以次类推。

组件是代理类，该类包含一个已经实现类的对象，并作一种变化。从结构上来说，代理模式可以看作是简单的装饰器模式，但是后者偏重于对象外观的装饰，而前者偏重于对象展示方式访问权限等非外观的装饰。

组件是组合类，该类包含一组函数，用于把该类的多个对象连接起来，构建对象树。

组件是外观类，某个模块里面的类和外面的类交互比较复杂的时候，为了简单起见，可以给模块增加一个外观类，让里面的类和外面的类通过这个外观类进行交互。

组件是装饰器类和它的子类，当有时候需要给一个已经实现的类做一系列变化的时候，有时候又需要做另一系列变化的时候，可以使用装饰器类和它的子类，让装饰器类包含这个已经实现类的对象，也包含装饰器类自身的对象，让每一个子类包含一种变化。这样就可以使得子类1的对象包含子类2的对象，而子类2的对象又包含子类3的对象，以此类推，最后子类n包含已经实现类的对象，即给已经实现的类先做了子类n的变化，又做了子类n-1的变化，以此类

组件是适配器类，如果已有一个已经实现好的类，但是它的函数与定义好的接口即所需要使用的函数略有区别，那么根据开闭原则，不应该修改这个已经实现好的类，而是要在类和接口之间加一个适配器类进行转换。转换的方式分为两种：一是让适配器类继承已经实现好的类，再让适配器类实现接口，二是让适配器类包含已经实现好类的对象，再让适配器类实现接口。

组件是建造者类，有时软件需要把多个类的对象合并到一起形成一个复合类，比如需要把车轮、车身、发动机三个类的三个对象合并成一个汽车对象，那么该模式就把合并对象这一操作放到一个单独的建造者类之中，这样可以增加相关类的聚合度，降低相关类之间的耦合度。

组建是单例类，该类只能创建一个对象，如果再次调用则不能创建对象，这可以满足软件某个类只有一个对象的要求。

组件是工厂类，该模式把软件中负责创建对象的部分单独作为一个类，可以减少软件各个类之间整体的耦合度。对工厂方法模式来说，工厂类一次只创建一个类的一个对象；而对抽象工厂模式来说，工厂类一次可以创建多个类的一组对象。

设计模式是一些成熟的、可供设计师参考的详细设计的部分。

组件除了客户端模块、服务器模块，还有目录模块，目录模块记录网络上各个服务器模块的信息，为客户端模块的不同请求提供相应的服务器模块的地址，供客户端模块快速访问相应的服务器模块。

组件是事件即消息的分发模块，以及消息的处理模块，消息到来之后，分发模块把消息发送给处理模块，处理模块进行处理。

组件是Peer即同伴模块，同伴模块之间是平等的，任何一个同伴模块既依赖于其他同伴模块，使用其他同伴模块提供的服务，又被其他同伴模块所依赖，为其他同伴模块提供服务。

组件是层级模块，高层的模块依赖于低层的模块。

组件是模型模块、视图模块、控制器模块，该风格与客户端服务器风格的关系是，该风格相当于把客户端模块划分为视图模块和控制器模块，而模型模块与客户端模块对应。

组件是客户端模块和服务器模块，服务器模块负责数据存储，以及部分数据处理，客户端模块负责另一部分数据处理。根据客户端负责数据处理量的多少，分为胖客户端和瘦客户端两种子风格；根据服务器模块的数量，分为两层客户端服务器和三层客户端服务器子风格。前面所述的存储器风格相当于特殊的客户端服务器风格，服务器模块只负责数据存储，而不负责数据处理。

存储器风格的组件是一个共享数据模块，以及多个客户端模块，多个客户端模块与共享数据模块相连，每一个客户端对共享数据的修改都对其他客户端可见。

管道过滤器风格的组件是过滤器，即处理数据的模块，组件的关系是管道，即传输数据的模块，该风格把数据经过滤器A处理后，通过管道A传输到过滤器B，然后再由过滤器B处理，以次类推。

体系结构风格是一些成熟的、可供设计师参考的概要设计。

不同的包的关联程度要尽量低，包含三个原则： 1 无环依赖原则：这样构建一个图，让每一个包对应一个图的节点，一个包依赖于另一个包就给相应的节点之间连一条有向边。因此，如果这个图有环，那么修改环上的任意一个包，都会影响到其它包，说明包之间的依赖关系比较高，需要想办法去掉图中的环。一个办法是包级别的依赖反转原则，反转环的一条边即可。 2 稳定依赖原则：如果一个包被多个包依赖，并且它自身依赖于很少的包，那么它就是

把相关的类放到一个包中，包含三个原则： 1 复用-发布等价原则：把可复用的类放到一组包中，把不可复用的类放到另一组包中； 2 共同复用原则：把一起复用的类放到同一个包中； 3 共同闭包原则：把将来会一起更新的类放到同一个包中。

打包原则是一组特殊的设计原则，是关于包层面设计的原则，即已经完成了类层面的设计之后，怎样把类放到不同的包里面。

该原则顾名思义，也主要用于类的层面。如果一个接口对应好几个类，那么应该把这个接口分割为多个，每一个对应一个类。该原则可以保证接口的聚合性，所以可以看作是特殊的单一责任原则。

组件是策略类，当某个类在不同输入数据下，需要有不同但相似的数据处理方式时，可以把每一种处理方式放到一个新的类中，这样便于增加或更新数据和处理方式，然后让这些类继承自一个统一的父类以供调用。该模式与状态模式相似，都为不同的数据处理方式增加了新的类，但是状态模式是基于状态的；该类与责任链模式也相似，把每一种数据处理方式放到一个类里面，但是责任链模式是数据处理方式差别很大时所使用的。

组件是状态类，当某个类在不同状态下，需要有不同的数据处理方式时，可以把每一种处理方式放到一个新的类中，这样便于增加或更新状态和相应的处理方式。

该原则主要用于类的层面。一个类A依赖于另一个类B的时候，可以在A和B之间加入一个B的接口，让A依赖于这个接口，B实现这个接口。这样可以降低A和B的耦合性，所以依赖反转原则可以看作是特殊的开闭原则。

该原则的组件为类，含义是父类的对象应该能被子类的对象替代，即看着是父类对象其实是子类对象，而不产生问题。首先分析出现问题的原因是，子类重写了父类的一些函数，看着是父类对象，以为调用的是父类的函数，其实是子类对象，调用的是子类的函数。因此为了避免出现问题，设计的时候尽量不要让子类重写父类的函数。

对于两个有调用关系的组件来说，它们的依赖程度需要越低越好，这样更新任何一个组件都不会太影响另一个组件。两个组件依赖程度低，也就是说它们有较低的耦合性。

每个组件的功能尽量单一，当然不可能每个组件只有一个功能，但是可以让每个组件的若干功能都属于一类。如果在设计中遇到功能不够单一的组件，可以把它一分为多个组件即可。一个组件功能单一，也就是说该组件有较高的聚合性。

只有了解了什么失败的设计，才能更好的理解设计原则。失败的设计包括以下几个特征： 1 僵硬性：软件难以修改，难以进行后续的版本更新； 2 脆弱性：对软件的修改容易导致软件崩溃； 3 不可移动性：软件的各个部分难以被其他软件复用； 4 粘性：随着软件版本的更改，软件越来越具有以上的僵硬性、脆弱性、不可移动性 5 不必要的复杂性：软件设计包含大量没有必要的模块和细节 6 不必要的重复性：软件设计包含大量重复的模块和细节 7 不透明

前面说过，软件体系结构的质量属性就是非功能性需求，功能性需求可以通过用例图描述，而非功能性需求的描述就是质量属性脚本。宏观来说，质量属性脚本是对非功能性需求的描述，具体来说，一个质量属性脚本就是是针对某一个软件使用场景，对软件应该做什么的描述。举例来说，一个软件安全性脚本可以是这样的：针对黑客攻击的时候，软件正常运行。既然软件质量属性脚本描述软件使用场景，那么它就包括以下几部分：激励即出现了什么情

1 性能：软件速度有多快，度量标准包括吞吐量即每秒处理多少任务、响应时间即多长时间相应一个请求、死线即什么时间以前完成任务； 2 扩展性：软件支持多大访问量，度量标准包括请求量、连接数、处理数据大小，也指软件可部署在多少计算机上； 3 修改性：软件版本更新有多大难度； 4 安全性：软件有多安全； 5 有效性：软件可以运行多久没有问题，也指软件出问题需要多长时间恢复； 6 可用性：软件对用户来说有多好用。

软件体系结构的质量属性简单来说就是非功能性需求，非功能性需求难以完全在需求分析阶段确定，所以也需要软件设计师考虑。

不同软件设计师对同一设计的画法不同，需要统一，于是统一建模语言即UML应运而生。用UML可以画不同类型的图，而这些图有一些可以作为“4+1”模型的某个模型，另一些可以作为“4+1”模型的另一个模型。UML画的图有13种，其中主要的图包括：类图、包图、时序图、部署图、用例图，可分别作为“4+1”模型的逻辑模型、开发模型、过程模型、物理模型、脚本模型。具体图的特点在软件工程概论课程说明，这里不作赘述。

只用一个视图模型来描述软件的设计是不够的，要给不同的人看不同的视图模型。研究表明，“4+1”个模型是比较合适的，其中，“4”个模型包括逻辑模型、开发模型、过程模型、物理模型，“1”个模型是脚本模型。逻辑模型描述软件的组件和组件的关系，来源于功能性需求；开发模型描述软件开发时的任务划分，来源于可扩展性、可维护性等非功能需求；过程模型描述软件运行时的模块之间的通信同步，来源于性能、并发度等非功能性需求；物理

首先要明白什么是模型，把脑子里的软件设计表达在纸上，所表达的东西就是软件模型。这里的“表达”可以是“文字描述”，也可以是“画图”，我们一般用画图的方式，所以软件模型是软件视图模型。

第一，便于接下来的开发；第二，便于相关人员理解软件设计，统一思想。1 软件体系结构介绍完毕。

影响设计的因素主要有软件相关人员、设计师自身、技术环境。软件相关人员包括投资人、工程师、用户等；设计师其实属于特殊的相关人员，单独拿出来；技术环境就是软件需要用什么技术开发，C语言和Java软件的设计是不一样的。

需要考虑的因素包括：组件、组件的关系、组件的属性。组件包括软件的包、包里的类、类的函数等，组件的关系是组件之间的包含调用关系，比如包包含类、类调用类等，组件的属性可以忽略。

从历史来看，开发软件越来越不需要关注底层，只需要调用各种库函数，所以软件开发变得越来越容易开发，软件变得越来越大越复杂，但是软件设计变得越来越难。这就是开设这门课的原因：研究和学习软件设计。

经核实吧主屋顶喝啤酒的人 未通过普通吧主考核。违反《百度贴吧吧主制度》第八章规定http://tieba.baidu.com/tb/system.html#cnt08 ，无法在建设 包尔老师的软件课程吧 内容上、言论导向上发挥应有的模范带头作用。故撤销其吧主管理权限。百度贴吧管理组

Hello world, I'm Carrie Anne, and welcome to Crash Course Computer Science! Hello world！我是 Carrie Anne，欢迎收看计算机科学速成课！ Over the course of this series, we're going to go from bits, bytes, transistors and logic gates, 在这个系列中，我们会学习 Bits(位)，Bytes(字节)，晶体管, 逻辑门， all the way to Operating Systems, Virtual Reality and Robots! 一直到操作系统，虚拟现实和机器人! We're going to cover a lot, but just to clear things up 我们要学很多东西，但预先说明 we ARE NOT going to teach you how to pro

1 计算机早期历史：http://tieba.baidu.com/p/6527376302?red_tag=c1748386412 2 电子计算机：http://tieba.baidu.com/p/6527388004?red_tag=d0058970856 3 布尔逻辑和逻辑门：http://tieba.baidu.com/p/6527391781?red_tag=h0088852542 4 二进制：http://tieba.baidu.com/p/6527395004?red_tag=t0102534634 5 算术逻辑单元：http://tieba.baidu.com/p/6527398239?red_tag=i0125939447 6 寄存器和内存：http://tieba.baidu.com/p/6527401610?red_tag=o0161025082 7 中央处理器：http://tieba.baidu.com/p/6527405039?red_tag=u0190618623 8 指令和程序：http://tieba.baidu.com/p/65274327