架构-软件工程2-工程
逆向工程
软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。
软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面
概述
软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
逆向工程的四个级别：
- 实现级：包括程序的抽象语法树、符号表、过程的设计表示。
- 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
- 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型、对象模型
- 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型、UML图、状态图、部署图。
其中，领域级抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程
- 重构/重组：是指在同一抽象级别上转换系统描述形式
- 设计恢复：是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
- 再工程：是指在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能
- 正向工程：它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进它的综合质量。
- 逆向工程：分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
净室软件工程
净室软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。
净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。
在净室软件工程背后的哲学是：通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。
净室软件工程(CSE)的理论基础主要是函数理论和抽样理论。
净室软件工程应用技术手段：
- 统计过程控制下的增量式开发：控制迭代
- 基于函数的规范与设计：盒子结构
定义3种抽象层次：行为视图（黑盒）->有限状态机图（状态盒）->过程视图（明盒） - 正确性验证。CSE的核心
- 统计测试和软件认证：使用统计学原理，总体太大时必须采用抽样方法
净室软件工程在使用过程的一些缺点:
- CSE太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。
- CSE 开发小组不进行传统的模块测试，这是不现实的。
- CSE也会带有传统软件工程的一些弊端。
基于构件的软件工程
基于构件的软件工程(CBSE)是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE 体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于己有构件的组装。
用于CBSE 的构件应该具备以下特征：
- 可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
- 可部署性:软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
- 文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
- 独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
- 标准化：构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型构件模型定义了构件实现、文档化以及开发的标准，其包含的模型要素为：
- 接口。构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。
- 使用信息。为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。
- 部署。构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。
构件模型提供了一组被构件使用的通用服务，这种服务包括以下两种：
- 平台服务，允许构件在分布式环境下通信和互操作。。
- 支持服务，这是很多构件需要的共性服务。例如，构件都需要的身份认证服务。
- 中间件：实现共性的构件服务，并提供这些服务的接口。
CBSE过程是支持基于构件组装的软件开发过程，过程中的6个主要活动：
- 系统需求概览、
- 识别候选构件、
- 根据发现的构件修改需求、
- 体系结构设计、
- 构件定制与适配、
- 组装构件创建系统。
CBSE过程与传统软件开发过程不同点：
- CBSE早期需要完整的需求，以便尽可能多地识别出可复用的构件。
- 在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需2’就应该考虑由复用构件支持的相关需求。
- 在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。
- 开发就是将已经找到的构件集成在一起的组装过程。
构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。
常见的组装构件有以下3种组装方式。
- 顺序组装。通过按顺序调用己经存在的构件，可以用两个已经存在的构件来创造一个新的构件。如一个构件输出作为下一个构件的输入
- 层次组装。这种情况发生在一个构件直接调用自另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。二者之间接口匹配兼容。
- 叠加组装。这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口，而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。
构件组装的三种不兼容问题(通过编写适配器解决)：
- 参数不兼容。接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。
- 操作不兼容。提供接口和请求接口的操作名不同。
- 操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集，或者相反。
检测并消除体系结构失配：体系结构失配问题由 David Garlan 等人在 1995 年提出。
失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设（assumption）与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：
（1）由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在 冲突引起的失配；
（2）由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的 失配；
（3）由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。