UML
静态图
-
对象图
- 展现了某一时刻一组对象以及他们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照,给出系统的静态设计视图或静态进程视图
-
类图
- 展现了一组对象、接口、协作和他们之间的关系
-
用例图
-
展现了一组用例、参与者以及它们之间的关系。主要支持系统的行为,即该系统在它的周边环境的语境中所提供的外部可见服务
- 用于对于一个系统的需求进行建模,包括说明这个系统应该做什么(从系统外部的一个视点出发),而不考虑系统应该怎么做
-
动态
-
交互图
-
用于对系统的动态方面进行建模,一张交互图表现的是一个交互,由一组对象和他们之间的关系组成,包含它们之间可能传递的消息
-
通信图
- 强调收发消息的对象的结构组织
-
时序图
- 关注沿着线性时间轴、生命线内部和生命线之间的条件改变,描述对象状态随着时间改变的情况,很像示波器,审核分析周期和非周期性任务
-
交互概览图
-
活动图的变体,描述业务过程中的控制流概览,软件过程中的详细逻辑概览,以及将多个图进行连接,抽象掉了消息和生命线
- 强调控制流的交互图
-
-
序列图
-
场景的图形化表示,描述了以时间顺序组织的对象之间的交互活动
- 一个用例和多个对象的行为
-
-
-
-
部署图
-
用来对面向对象系统的物理方面建模的方法,展现了运行时处理结点以及其中构件(制品)的配置
- 用于展示所交付系统中软件组件和硬件直接的物理关联
-
-
组件图
- 展现了一组组件之间的组织和依赖
设计模式
抽象工厂
-
意图
- 提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类
-
场景情形
- 一个系统要独立于其产品的创建、组合和表示时
- 一个系统要由多个产品系列中的一个来配置
- 当需要强调一系列相关的产品对象的设计以便进行联合使用时
- 党提供一个产品类库,而只想显示他们的接口而不是实现时
桥接模式
-
场景
- 对于希望使用已经存在的类,但其接口不符合需求的情形
创建型
-
与对象的创建有关
-
Factory Method(工厂模式)
-
Abstract Factory(抽象工厂)
-
Builder(构建者)
-
适用于
- 当创建复杂对象的算法应该独立于该对象的组成部分以及他们的装配方式时
- 当构造过程必须被构造的对象有不同的表示时
-
-
Prototype(原型)
-
Singleton(单例)
-
结构型
-
处理类或对象的组合
-
Adapter(类)
-
Adapter(对象)
-
Bridge(桥接)
-
适用于
- 不希望在抽象和它的实现部分之间有一个固定判定关系描述
-
-
Composite(组合)
-
适用于
- 想表示对象的部分-整体层次结构
- 希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象
-
-
Decorator(装饰者)
-
Fafade(外观)
-
为子系统中的一组接口提供一个一致的界面,内部复杂,有一个简洁的接口(定义了一个高层接口)
- 要为一个复杂子系统提供一个简单接口时,子系统往往因为不断演化而变得越来越复杂
- 客户程序与抽象类的实现部分之间存在着很大的依赖性
- 当需要构建一个层次结构的子系统时,使用外观模式定义子系统中每层的入口点
-
-
Flyweight(享元)
-
运用共享技术有效地支持大量细粒度的对象
-
适用于
- 一个应用程序使用了大量的对象
- 完全由于使用大量的对象,造成很大的存储开销
- 对象的大多数状态都可变为外部状态
- 如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象:应用程序不依赖于对象标识
-
-
-
Proxy(代理)
-
在需要比较通用和复杂的对象指针代替简单的指针的时候
-
常见情况
-
远程代理(Remote Proxy)
- 为一个对象在不同地址空间提供据不代表
-
-
-
行为型
-
对类或对象怎样交互和怎样分配职责进行描述
-
Interpreter(接口)
-
Template Method()
-
Chain of Responsibility(责任链)
-
Command
-
Iterator(迭代器)
-
Mediator()
-
Memento Observer State Strategy
-
适用于
- 当一个抽象模型有两个方面,其中一个方面依赖于另一个方面。将这两者封装在独立地对象中以使它们可以各自独立地改变和复用
- 当对一个对象的改变需同时改变其他对象,而不知道具体有多少对象有待改变时
- 当一个对象必须通知其他对象,而它由不能假定其他对象是谁,即不希望这些对象是紧耦合得到
-
-
Visitor
-
一个对象结构包含很多类对象,而系统要求这些对象实施一些依赖于某具体类的操作时
- 需要对一个对象结构中的对象进行很多不同的并且币相关的操作
-
-
工厂方法
-
定义一个用于创建对象的接口,让子类决定将哪个类实例化,使一个类的实例化延迟到其子类。
-
适用于
- 当一个类不知道它所必须创建的对象的类的时候
- 当一个类希望由它的子类来指定它所创建的对象的时候
- 当类将创建对象的职责委托给多个帮助子类中的某一个,并且希望将哪一个帮助子类是代理者这一信息局部化的时候
-
面向对象
哈夫曼树
权值最小的两个节点互为兄弟节点
外部实体
组织机构
人员
第三方系统
内聚
过程内聚
- 如果一个模块内部的处理成分是相关的,而且这些处理必须以特定的次序执行
时间内聚
- 如果一个模块完成的功能必须在同一时间内执行(如系统初始化),但这些功能只是因为时间因素关联在一起
顺序内聚
- 如果一个模块的各个成分和同一个功能密切相关,而且一个成分的输出作为另一个成分的输入
逻辑内聚
- 几个逻辑上相关的功能被放在同一个模块中
编译器工作过程
词法分析
- 记号流,也就是语法分析的输入
符号表
在编译程序工作的过程中需要不断收集、记录和使用源程序中一些语法符号的类型和特征等相关信息
- 这些信息一般以表格形式存储在系统中
嵌入式操作系统
特点
-
微型化
- 从性能和成本角度考虑,希望占用的资源和系统代码量少
-
可定制
- 从减少成本和缩短研发周期考虑,要求嵌入式操作系统能运行在不同的微处理器平台上,能针对硬件变化进行结构与功能上的配置,以满足不同应用的需求
-
实时性
- 嵌入式操作系统主要应用于过程控制、数据采集、传输通信、多媒体信息及关键要害领域需要迅速响应的场合,所以对实时性要求较高
-
可靠性
- 系统构建、模块和体系结构必须达到应有的可靠性,对关键要害应用还要提供容错和防故障措施
-
易移植性
- 为了提供系统的移植性,通常采用硬件抽象层和版级支持包的底层设计技术
耦合类型
数据耦合
- 一个模块访问另一个模块时,彼此之间是通过简单数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的
公共耦合
- 若一组模块都访问同一个公共数据环境,则他们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等
外部耦合
- 一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息,则称之为外部耦合
标记耦合
- 一组模块通过参数表传递记录信息,就是标记耦合。这个记录是某一数据结构的子结构,而不是简单变量。
HTTP的一次请求过程
在浏览器中输入URl,并按下回车键
-
浏览器向DNS服务器发出域名解析请求并获得结果
-
根据目的IP地址和端口号,与服务器建立TCP连接
-
浏览器向服务器发送数据请求
-
服务器将网页数据发送给浏览器
-
浏览器解析收到的数据并显示
- 通信完成,断开TCP连接
-
-
-
-
能力成熟模型
连续式模型
-
CL0(未完成的)
- 过程域未执行或未得到CL1中定义的所有目标
-
CL1(已执行的)
- 其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品,以实现支持过程域的特定目标
-
CL2(已管理的)
- 其共性目标是集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程,项目遵循已文档化的计划和过程描述,所有正在工作的人都有权使用足够的资源,所有工作任务和工作产品都被监控,控制和评审
-
CL3(已定义级的)
- 其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程中裁剪得到的,还必须收集过程资产和过程的度量,并用于将来对过程的改进
-
CL4(定量管理的)
- 其共性目标集中于可定量管理的过程的制度化。使用测量和质量保障来控制和改进过程域,建立和使用关于质量和过程执行的质量目标作为管理准则
-
CL5(优化的)
- 使用量化(统计学)手段改变和优化过程域,已满足客户的改变和持续改进计划中的过程域的功效
阶段式模型
数据库中
视图-外模式
存储文件-内模式
基本表-模式
软件测试
白盒测试
-
结构测试
-
用于单元测试阶段
- 把程序堪称装在一个透明的盒子里,测试者完全知道程序的结构和处理算法
-
黑盒测试
-
功能测试
-
用于集成测试和确认测试阶段
-
把软件看成一个不透明的黑盒子,完全不了解如那件的内部结构和处理算法,他只检查软件功能是否能按照软件需求说明书的要求正常使用,软件是否能适当地接收输入数据并产生正确的输出信息,软件运行过程中能否保持外部信息的完整性等
- 等价类划分,边值分析,错误推测,因果图
-
-
α测试
-
用户在开发者的场所由开发者指导完成的测试
- α测试是在受控的环境中进行的
β测试
-
一个或多个用户的现场由改软件的最终用户实施的,开发者通常不在现场,用户负责记录发现的错误和使用中遇到的问题,并把这些问题报告给开发者。
- β测试是在非受控环境中进行的
回归测试
-
测试软件变更之后,变更部分的正确性和对变更需求的符合性,以及软件原有的,正确的功能,性能和其他规定的要求的不损害性
- 只要软件发生了变更,都应该做相应的回归测试