分析遵循：首先分析元素以及关系，然后在针对每个元素分析其内部的活动/流程，组织为新的元素，再分析其内部有哪些流程，在进行职责归类（识别类）。
分析架构之前的C4原则和System/Segment/SubSystem/Compent其实是一脉相承的，但是Booch又提出一点就是黑盒-白盒思想，每在一个抽象层次上都是首先应用黑盒来分析行为推导提供的服务/接口，然后是白盒分析里面的元素；对于分析出来的元素，在使用黑盒分析行为，得到服务/接口，然后白盒分析其内部元素，以此类推，一直到类的方法。
所以Context是站在系统的角度，来分析元素，首先是你的系统，和外部的系统有哪些交互；每个一个系统都是一个元素，这个分析过程是用例分析阶段1；然后聚焦待开发系统，分析它要提供给外部那些功能，以及外部系统要提供给你的系统那些接口；然后是Container，聚焦到你的系统，分析你的系统里面都有哪些元素，这里需要对于主流程进行梳理，这个时候活动图上场了；其实就是流程图，对于比较重的流程，用例分析是要写文档的，但是对于轻量级开发而言，用例流程图就可以是一张张描述比较清晰的流程图即可。比如传输，可以分析出来组件（子系统）包括接入，传输，加解密以及交付四大组件（子系统），然后在分析各个组件需要对外提供的服务（接口），这个是黑盒分析，然后再聚焦每个组件进行深入分析...
分析永远都是从黑盒开始，从一个宏观上来看待分析对象（系统、子系统、模块、子模块本身就是“对象”）；获取宏观用例，对用例进行梳理后，进行组织安排，进行分组，然后再对一组用例进行细化，这组用例有的是为外部提供的服务，有的内部活动，但是要一组为单位进行细化。
所以分析的本质再“分”，不断地对于“活动”进行细化，但是细化是以组为单位进行细化，以保证逻辑的连贯性。
如此架构成了。
--读《OO Aanlysis and Design with Application》有感