记录督促学习历程21

方面最早是作为一个变成语言的结构引入的，关注点的概念实际上是从系统需求中导出的，因此在系统开发过程的所有阶段采用面向方面的方法是很有意义的，在软件工程的早期阶段，采用面向方面的方法意味着利用分离关注点的概念作为考虑需求和系统设计的基础。
识别关注点和对关注点的建模应该是需求工程和设计过程的一部分，面向方面的程序语言提供技术支持在你的系统实现中维护关注点的分离。

设计一个系统时，我们应该让系统支持不同的信息持有者的关注点，把系统看成是一个核心系统加若干扩展，核心系统是实现系统关键目标的一组系统特征。

有几种不同类型的扩展，
1第二类功能性扩展
2政策扩展
3Qos扩展
4基础结构扩展

扩展总是向核心系统添加某类功能或者额外的特征。方面是实现这些扩展的方法，它们还可以在面向方面的编程环境中利用编织工具和核心系统功能相组合。

面向关注点的需求工程，关注点反应了信息持有者的需求，这些关注点可能反应了信息持有者所要求的的功能需求 、系统服务的质量、机构政策或者是与系统总体特性相关的一些问题。因此，为需求工程采用一种方法去识别和制定不同信息持有者的关注点很有意义。“早期方面”这个术语曾用来指在软件生命周期的早期阶段队方面的使用，在此极端强调的是关注点的分离

人们认识到再需求工程期间分离关注点的重要性已经有好多年了，表现系统不同角度的视点概念是分离不同信息持有者关注点的一种方法，而且它已经融入到很多需求工程的方法中，这些方法分离不同信息持有者的关注点，视点反应不同的信息持有者群体所要求的独特功能。

所有不同视点的信息持有者都需要能够赵傲特殊的设备项，浏览每个地点的可用设备并从仓库登记接触设备，因而这些是核心系统的需求，第二类需求支持每个视点的更多的特殊需要，对于系统扩展来说，有支持设备使用、管理和维护这样一些第二类需求。
通过视点所识别出来的第二类功能性需求不一定横贯来自其他视点的需求，例如，只有维护视点关注记录维护操作的完成，这些需求反应了该视点的需要，那些关注点可能无需与其他视点共享，然而，除此第二类功能性需求之外，还有横切关注点，产生对部分或所有视点都很重要的需求。

这些通常反应的是作用于整个系统的服务需求的政策和质量。

在设备库存系统中，横切关注点的一个例子是系统可用性，紧急情况的发生可能很少或者根本没有警告。

需求工程过程的成果应该是一组需求，这个需求集合被划分到核心系统和扩展组件两概念对应的子集中。

作为一般规则，要避免让系统有太多的关注点和扩展，这些太多的关注点和扩展只能让读者混淆并可能导致不成熟的设计，这一点限制了设计者的自由，并有可能导致系统的设计不能满足服务需求的质量。

面向方面的设计是利用方面进行系统设计的过程，通过方面来实现那些在需求工程过程中所找出来的横切关注点和扩展，在此阶段，我们需要把索要解决的问题相关联的关注点翻译成程序中对应的方面，我们需要了解如何将这些方面与系统的其他组件组合在一起，并确保不发生组合的二义性。

需求的高层生命为识别某些系统扩展提供了基础，这些扩展可以实现为方面，接下来，就需要给出更详细的需求，从而识别出更多的扩展并了解所需要的功能。

如果接受和使用面向方面的设计，那么给出一种高效的面向方面的设计过程就是非常重要了，建议面向方面的设计过程有这些活动：
1核心系统设计
2方面识别和设计
3合成设计
4冲突分析和解决
5名字设计

这个过程自然地是个迭代过程，首先是有一个初始的设计建议，然后在分析和理解设计问题的基础上不断地细化它。

面向方面设计过程的输出结果时一个面向方面的设计模型，这可以用UML扩展版本来表叔，此版本包括新的方面特有的结构，“方面UML”的基本元素包括一些方面建模的手段和制定连接点的手段，此连接点既是方面建议应和核心系统组合在一起的地方。

如果要采用面向方面的方法来设计你的系统，就必须找出核心功能和扩展，将扩展实现为横切的方面，于是编程过程的焦点将是编写代码实现核心系统和扩展功能。在方面中定义切入点，这样方面建议就能够在正确的地方被编制进基础代码中。

正确地制定切入点是非常重要的，因为它们定义了方面的建议在哪里和核心功能结合起来，

如果在切入点的描述上犯错误，那么方面的建议将在错误的地方被编制到程序中，这将导致不希望的也是不可预料的程序行为。坚持在系统设计过程中遵循所建立的命名标准使必要的。

同时也要复查所有的方面以保证如果有两个或读个方面在相同的连接点上编制进核心系统时没有冲突发生，一般来说，最好能够完全避免，但是有时候，将它们实现为一个关注点可能是最好的方法。

在这种情况下，就必须保证方面是完全独立的，程序的行为不应依赖于方面编织进程序的顺序。

检验和有效性验证，检验和有效性验证是证明一个程序符合它的描述以及符合它的信息持有者的真正需要的过程，静态检验技术集中于手动或自动分析程序的源代码。

对于面向方面的系统，其有效性验证测试的过程和对其他系统没有什么区别，最终执行的程序被看做是一个黑盒，设计测试以说明系统是否符合它的需求。

程序的可理解性准则是读者能够自左向右、自顶向下地阅读程序而不用切换主力已到其他代码部分。

在面向方面的系统中，顺序地阅读代码是不可能的，阅读者必须检查每个方面，了解它的切入点和面向方面语言的连接点墨香。

代码阅读工具可以使面向方面的程序“变平“”展现在读者面前的是已经将方面在指定的连接点出编织进程序的代码。

白盒或结构化测试是系统化测试方法，使用程序源代码知识去设计缺陷测试，其目标是设计能提供一定程度的程序覆盖的测试，
典型的，测试集应该保证程序中的每个逻辑路径都执行过，使得每个程序语句都至少执行过一次。

面向方面的系统中，主要有两个问题：
1程序代码的知识如何能用来系统地导出程序测试?
2测试覆盖的真正含义是什么？

对没有无条件分支语句的结构化程序设计测试，可以导出程序流程图，流程图现实了贯穿程序的每个逻辑执行路径，可以检查代码，针对流程图中的每个路径，选择使路径能够执行的输入。

在面向方面的程序中，还有一个问题，那就是确定测试覆盖的内涵，意味着每个方面的代码至少执行一次，这是一个非常弱的条件，因为方面和基代码之间在方面被编织的连接点处有交互。

与程序检查和白盒测试中的问题一一，指出在面向方面编程中测试环节存在的其他一些问题：
1应该如何定义方面以便能从中推出对方面的测试》
2相对于索要编织到的基系统，如何对方面进行独立测试》
3如何测试方面的干涉？
4如何设计测试，使得所有程序中的连接点都执行到，且适当的方面测试得到实施？

这些测试问题的发生时因为，方面是与系统的主体代码紧凑集成的而不是分散集成的，因此它们很难孤立进行测试。因为它们可能在很多不同的地方编织进程序，我们就不能肯定在一个连接点能成功工作的方面在其他连接点处也能正常工作，所有这些都是面向方面的软件开发所需要进一步研究的问题。