231
而我们用例分析，就说最终我们是怎么把这个用例映射到一个设计上，大家都知道，最后你肯定是你理解了主场景用例场景之后，在解决方案空间里面一定会有一个最关键性的模型对象，然后这个模型对象就封装了这个用例里面的关键的行为，这个行为其中一定会有一个关键的方法，这就是业务方法。
而，这个业务方法就是封装的用例的主流程，作为一个主场景的生动体现，这样的话我们就能够回答这样一个问题，用例图谁被授权执行这个问题？
所以，要有角色被授权执行这个问题，然后还需要认证一下，认证用户属于这个角色，然后授权决策授权角色，这是我们整个的核心机制，然后我们在这里面我们建立的概念，就是说谁被授权执行，这个是角色被授权，然后用户属于这个角色，就可以去干这个事情。
这就回答了这样一个问题。就是说我们大家都知道，在这个过程中，你还要回答这个动作主场景，要么被当成一个原子执行，大家想这什么概念？这个用例里面有一组动作，回忆一下用例的那个概念，就是用例是一组动作序列的集合，而是每个动作就是一个表达式，然后现在我们要回答的是，怎么样把它作为一个整体来执行，那就是事物，所以说我们要在这个过程中，在这个方法上加一个事物，所以授权就是加一个事物。
232
当然了可能会出现一种情况，如果我们将来在执行这个动作的过程中，出现差错，我们希望它一定得到处理，我们知道这个方法里面你要写一个串写case，大家想想业务流程，这实际上就形成了这个场景，你这个用例肯定有主场景，而一个业务流程就抽象了一个主场景。
所以，我们用例分析的时候，特别是说进行一个基于组件的开发，实际上就相当于是写一篇优美的散文。你怎么样才能做到形散而神不散，这是我一直强调的。
那么针对用例和场景来说，我们这里面的神，它使得我们动作序列有机有序的组成了一个组件，这样你不觉得乱，因为至少基于组件也是一种架构风格，我们要有大局观，这个系统里面我看到的都是一堆组件，然后说面向对象是一种风格，基于组件也是一种风格，那么，它们分析问题的粒度是不一样的。
233
基于组件这种开发，是比面向对象更高的一个层级，组件之间，因为你不能直接调用，它们必须通过约定的接口，组件之间才能发生作用，所以，这样一来，我们只须要关注组件的开发，并暴露出需要交互的接口，而组件内确是内聚的自成体系的，所以，这样，我们觉得这样一种风格感觉上不是那么乱，或者是事件驱动的这样一种风格，不管什么风格，它表现出最核心概念用例和场景，这是它们的神。
通过用例把它们所有的行为组织在一起，怎么画用例，这要从系统级别的行为描述系统做什么，以及通过协作描述系统如何做，所以说，架构是系统级别的，一个全局性的战略性的这些决策。而，这个用例这些协作它也都是战略级别上，系统级别上的，所以这时我们就知道了，我们的架构是跟这些概念连在一起的。
不理解这些概念，你还怎么去做架构呢？
就是说一个用例，它会有一些场景，是一些动作序列的组合，当参与者和系统进行一次对话的时候，它一定触发了其中的一个场景，选择了其中的一组动作序列，这对我们来说是核心的东西。
234
然后我们都知道场景，构成了一个测试案例，在整个软件工程里面有一个重要的概念case，这个词本身就是案例或者情形，我们翻译成了用例，拿测试用例来讲，假设从我这个角度来讲，我知道你肯定说的是test case，我们把它都约定一下，因为大家可能都是未来企业里面的一些中坚力量，企业里面最关键是统一语言，统一行动，在公司里，最重要的一条永远就是解决问题，达成共识。
在企业里做事，里面没有对和错，反正就是所谓的七步法。
235
具体来说，什么是七步法？
第一步，定义问题
目的：定义待解决的问题
阶段任务：确定项目背景、问题描述、范围、目标、团队
关键问题：
确认产品失效的工况、失效信息（失效照片、索赔信息、频率等）
是否引发人身安全、退机及顾客强烈抱怨等
公司目前的技术能力、人力资源等是否能解决此问题
一个清晰定义的问题等于问题解决了一半。——Charles F Kettering
第二步 现状调查
目的：对问题的现状(缺陷)进行调查，确认问题的现水平
阶段任务：确保数据来源的可靠性，确认问题的现水平
关键问题：
真实的零件检查了吗？检查实际的零件：失效的，新的，未失效的
真实的环境检查了吗？检查实际的环境：作业条件，失效记录，设计/过程变更的记录
必要时做测量系统分析
确定问题的过程能力水平
第三步 识别可能原因
目的：识别可能原因
阶段任务：确定导致失效发生的所有可能原因，并进行筛选，确定可能的原因，采取即时改善措施（包含问题纠正及针对可能原因的即时改善措施）。
关键问题：
依靠有经验/专业的项目小组成员共同查找可能原因并进行筛选
查找到的原因要求是具体的、可以测量的筛选出的原因可以立即做改善的，采取行动实施即时改善
