软件架构的一种新表示方法-EAD模型.pdfVIP

《EAD模型》 ⼀种程序架构描述⽅法 柯元旦2015年7 ⽉25 ⽇（⻄安） 序：想写这个⽂章很久了，忙（亦或是盲），今天把TA完成，作为本⽉给各位技术朋友们 的礼物。在Google的Android部⻔，⼯程师使⽤Omni Graffle(/)这个软件 进⾏软件架构描述，上的相关软件架构图描述，都是使⽤这个软件完成的， 本⽂所提出的EAD模型描述⽅法，也可以使⽤Omni Graffle这个软件完成，因为我设计了⼀套Omni Graffle的库，以形成统⼀的规范。这种⽅法本质并不复杂，因此，我希望⽤最简短的篇幅描述，让 ⼤家能迅速的⽤起来。 本⽂⺫的：程序员在设计软件架构师，尤其是代码级别的分析、设计，通常使⽤线框图 表⽰，对于读者⽽⾔，⼤多都会出现误解，因为线框图不能清晰表⽰程序架构的以下⼏个重要⽅⾯ ： 1 ，线程模型。架构中有多少个线程在执⾏，彼此的关系是什么？ 2 ，主流程中包含的关键类、⽅法是什么？ 3 ，关键辅助类、⽅法是什么，和主流程之间的调⽤关系？ 4 ，明确区分函数之间的调⽤关系。 EAD模型的全称是Entity(主体)、 Action(⾏为)、 Data(数据)的缩写，因为从代码实现的⾓度 来讲，代码的本质可以抽象为这三类元素。 Entity包括：线程、类、函数 Action包括：调⽤、展开、⼲播、读写数据、发送消息等等。 Data包括：队列、⽂件、⼆进制数据、池、列表等。 本⽂提出了⼀种⽅法，定义三类重要元素的图⽰，并定义⼀种规则（或者叫经验）能够清晰、 ⽆歧义的表⽰以上三类元素在代码中的关系，从⽽⽅便设计者进⾏⾃检，以及⼯程师之间的代码思 路交流，也便于源码解读者描述源码的关键代码逻辑。我曾经⽤这种⽅法描述了Android 内核源码的 很多关键流程，⽐如： “Android系统的启动流程” “第⼀个Android应⽤的启动流程” “Android内部消息处理流程” 由于这些流程图是在以前所在公司完成的，所以不能秀给⼤家。 好了，现在开始吧。下⽂的撰写思路是，⾸先定义EAD三元素的内容、以及所使⽤的图⽰， 然后再举例说明这些元素使⽤的规则，最后再附加⼀个常⻅问答。 第⼀部分：主体（Entity） 主体包括，线程、类、函数、模块。三者所使⽤的图⽰如下： Class 以上图⽰的特点在于。 类，这是⾯向对象中最常⻅的主体，在UML语⾔的表⽰⽅法中，使⽤的就是这种图⽰，因 此，我们只是沿⽤。 函数，⾮常普遍，所以我们采⽤最常⻅的矩形框，程序员之间在讨论代码时，经常画⼀个框， 让对于听者很容易混淆，这到底是⼀个函数呢、模块、类？所以，本⽂严格定义，矩形框仅仅代表 ⼀个函数。 线程，当别⼈告诉你，他的软件设计思路时，其中重要的⼀点就是线程模型，⽐如这个架构 在运⾏时，⼀共有多少个线程？每个线程的作⽤是什么？会不会存在线程效率问题？线程之间如何 传递数据？从视觉的⾓度来看，我们希望能够⼀⺫了然，⼀眼看过去，就能⽴即看出以上问题，因 此，使⽤了粗⿊线的矩形框。 模块，架构设计时，往往是多个模块之间共同的关系，为了描述⾃⼰所负责模块的内部逻辑， 可以忽略外部模块的具体细节，只⽤⼀个模块表⽰，模块我们定义为倒圆⾓的矩形。 第⼆部分：⾏为（Action) 过去，所有的程序员交流时，想表达两个主体之间的关系时，都喜欢画⼀个带指向的剪头， 可是这个剪头却让听着不爽，时间⻓了连⾃⼰也不清楚这个剪头是啥意思，因为，剪头所代表的⾏ 为实在很丰富，本⽂重新定义这些⾏为。 图⽰的规则是，在剪头的下⽅⽤不同的⼩图案代表不同的⾏为，这是很好的，之前我还想过 ⽤不同的剪头表⽰不同的⾏为，经过⾃⼰实际尝试，最后选择了这种⽅法