TOGAF架构开发方法（ADM）之业务架构阶段
TOGAF架构开发方法（ADM）之业务架构阶段
1.3 业务架构（Business Architecture）
企业架构开发方法各阶段——业务架构
1.3.1 目标
- 描述基线业务架构
- 开发基于原则、业务目标和策略驱动力的目标业务架构，描述产品和/或服务策略，以及业务环境在组织、功能、过程、信息和地理这些方面的内容
- 分析基线和目标业务架构之间的差距
- 选择和开发相关的架构视角，通过这些视角架构师可以阐述业务架构是如何对各干系人的关注点进行解答的。
- 选择与选中的视角相关的工具和技术
1.3.2 方法
针对业务架构的了解是进行其他领域（数据、应用和技术）架构工作的前提条件，因而如果不是因为组织中其他一些诸如企业规划、业务战略规划以及业务流程再造等方面流程，针对业务架构的制定应该是要首选进行的架构活动。业务架构是用来将其后架构工作的业务价值阐述给相关干系人所必不可少的工具，它也可用来为各个支持和参与后续架构工作的干系人阐明企业架构的投资回报。在实践过程中，业务架构的关键元素也许已经在其他工作中被明确，而在这种情况下，组织就需要验证和更新当前已经文档化的业务战略和规划，并/或在已经明确的业务驱动力、业务战略、目标与架构开发工作相关的特定业务需求之间建立关联。而在另外一种情况下，业务架构工作也许并没有或者很少被执行，而这就需要架构团队研究、验证架构将要支持的各个关键业务目标和流程，并获得相关干系人的认同。然而不论处在以上哪种情况，TOGAF ADM的业务情景技术，或者是其他用来阐明关键业务需求以及为IT架构指明其技术需求的方法，都需要被纳入到架构师的工具箱之中。
需要注意的是，在架构活动中应尽量重用各种已经存在的材料，并且针对信息的收集和分析也应该依据架构工作的范围而采用那些能够促成明智决策的信息。如果架构活动关注于业务流程的定义，则在此阶段组织需要在此方面进行很多细致的工作，而如果关注点更着重于其他领域（数据/信息、应用系统和基础设施）中的目标架构，那么组织就需要在这个阶段构建一幅无需包含众多非必要细节的全景图。
除此之外，在此阶段所涉及到的方法还包括：
开发基线描述
如果企业中已经存在了架构的描述，那么他们可以被用来作为基线描述的基础。这些输入可能在架构愿景阶段中已被用来开发架构愿景，但对于基线描述来说应该也是够用的。而如果这些描述并不存在，组织就需要从各种渠道对这些信息进行收集。针对目标架构的开发通常是采用自上而下的方法，而对基线描述来说，针对当前状态的分析经常是自下而上的，特别是当只有很少或没有架构资产存在时。在这种情况下架构师需要记录关于高层次框架的工作假设，并逐步收集能够将这些工作假设转变为现实的证据。
业务建模
业务模型是架构愿景中各业务情景的逻辑扩展，架构可以借此将高层次的业务需求细化为更详细的需求。在实践中存在着一系列建模工具和技术可以供组织选择使用，例如：
- 活动模型（Activity Models）：活动模型也称为业务流程模型（Business Process Model），他描述了各种与组织业务活动相关的功能、活动之间进行交换的数据和/或信息（内部交换）以及与模型范围之外的其他活动进行交换的数据和/或信息（外部交换）。活动模型在本质上是具有层次型结构的，它涵盖了在业务流程中所进行的各种活动，以及这些活动的输入、控制、输出和所使用的机制或资源（ICOMs：inputs，controls，outputs，and mechanism/resources），并且各种用于描述ICOMs之间关系的业务规则也可被明确地标注在业务模型之中。当前在业界存在着多种用来构建活动模型的技术，其中之一就是IDEF（Integrated Computer Aided Manufacturing （ICAM）DEFinition）建模技术。除此之外，OMG（The Object Management Group）也开发了BPMN（Business Process Management Notation）标准，用于为业务流程建模提供一种标准性语言。
- 用例模型（Use-Case Model）：依据建模关注点的不同，该模型既可以用来描述业务流程也可以描述系统功能，并且它可以从用例、与业务流程相关的角色以及组织参与者的角度来对企业的业务流程进行描述。通常情况下，用例模型是通过用例图和用例说明来进行表述的。
- 类模型（Class Models）：此模型与逻辑数据模型相类似，主要用于描述静态的信息以及这些信息之间的关系。除此之外，类模型还可被用来描述信息的行为。与其他各种模型类似，类模型也是可以在多种粒度层次上进行模型建设的。根据建模意图的不同，类模型既可以用来表达各种业务领域实体，亦可以被用来描述各个用于进行系统实现的类。一个业务领域模型表达了关键的业务信息、他们的性质、行为和关系。类模型的描述通常通过类图进行表现，不过更加详尽的说明和信息将被记录在额外的说明文档之中。
以上三种模型都可以通过统一建模语言（UML：Unified Modeling Language）来进行描述，并且在现实生活中存在着很多可以生成这些模型的工具。除了这些通用性的模型之外，每个行业也有着符合自身特点的各种模型和建模技术。以国防部门为例，如下几种模型就是比较有代表性的（需要注意的是，虽然这些模型源于国防部门，但是在其他政府部门中也逐渐得以采纳，而对于非政府环境来说也具有借鉴意义）：
- 节点连接图（Node Connectivity Diagram）：描述了业务位置（即节点）、业务位置之间的需求关系以及节点间所交换的信息的性质。该模型可以在三种层次之上进行描述，即概念层次、逻辑层次和物理层次。每条节点之间的需求连线代表其所连接的两个节点之间对于信息传输的需求，而每个节点则用来代表一个角色、组织单位、业务位置或设置等。标注在连线上的箭头用于表示信息流的传输方向，而箭头附近的标注则被用来描述所传输的数据或信息的性质（例如，内容、媒介、安全或分类等级、时限和信息系统互操作需求等）。
- 信息交换矩阵（Information Exchange Matrix）：记录企业架构的信息交换需求。信息交换需求表述了三种基本实体（活动、业务节点和他们的元素、信息流）之间的关系，并着眼于信息交换的各种特性（例如性能和安全性）。简单来说，该模型表述了什么人与其他何人交换何种信息，这些信息的必要性以及信息交换的形式。
使用架构资源库
在这一阶段的各项活动中，架构团队需要考虑在架构资源库中是否存在与业务架构相关的资源可供使用，特别是在如下几个方面的资源：
- 组织所在行业的通用业务模型（存储在架构资源库的参考资料库中）。前面提到过的联邦企业架构业务参考模型就是个很好的例子。
- 与在IT行业发布的通用高层次业务领域（例如电子商务、供应链管理等）相关的业务模型，例如主要用于财会系统建模的REA（Resource-Event-Agent）业务模型和关注于产品设计和供应链交互方面的STEP（Standard for the Exchange of Product model data）框架。
- 企业特定的构建块（流程组件、业务规则、工作描述等）。
- 各种适用的标准。
1.3.3 输入与输出
在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：
| 输入 |
参考资料 |
架构参考资料 |
| 非架构性输入 |
架构工作要求书 |
|
| 业务目标、原则和驱动力 |
||
| 能力评估 |
||
| 沟通计划 |
||
| 架构性输入 |
企业架构组织模型，包括：
|
|
| 定制的架构框架，包括：
|
||
| 批准的架构工作说明书 |
||
| 架构原则，包括业务原则（如果事先存在的话） |
||
| 架构连续体 |
||
| 架构资源库，其内容包括：
|
||
| 架构愿景，包括：
|
||
| 输出 |
经过改善和更新的架构愿景阶段中的各交付物，包括：
|
|
| 架构定义文档草案，包括：
|
||
| 架构需求说明草案，包括：
|
||
| 架构路线图的业务架构组件 |
||
1.3.4 步骤
在当前阶段中所要执行的各个步骤归纳如下：
- 选择参考模型，视角和工具
- 开发基线业务架构描述
- 开发目标业务架构描述
- 进行差别分析
- 定义架构路线图组件
- 通观整个架构景观来明确和解决相关影响。
- 进行正式的干系人审查
- 最终确定业务架构
- 创建架构定义文档
启迪思维：链式队列
最近校长火了，微博上各种讽刺校长这个职位信息，还有各种公知转发这些微博(他们无非想说明自己有多么正直，鬼知道背后都干啥)，更有可耻人借此炒作。其实根据各种新闻来看，猥琐少女人有企业高管、校长等等人，我们只能谴责这些心理变态的人(让哪些为恶的人下地狱)，不能因此讽刺校长这个职位，这个就和有些无良媒体报道有搞IT加班累死(个人观点IT公司里累死的兄弟，应该是不懂调整心态)，就判断搞IT是高危行业一样，事实上高危行业应该是挖煤、黑砖厂等等。上周参加一个公益性质的活动，就认识一个很了不起的校长(收养100的个孤儿)，我自己小学校长也是非常好的人，可悲的是初中校长因贪污被双规。
最近网上一贴郭美美的余额短信有闪现我等屌丝的太极眼，其实这个新闻很早都有，是新华社发出，最近因为营销的需要又被炒作起来，腾讯客户端及搜狐客户端都放在头版头条，稍微有点知识的人都知道这是个假新闻，这篇新闻后面全是推销施华洛世奇女鞋的。普通网民只重视情绪，从不管事实，这样就被营销者利用了很成功。这个仅仅是为营销，还更多是坑爹甚至坑爷的新闻，坑着那些不懂得过滤这些垃圾信息的人。
在网络每天都有类似这样假新闻、骗人的广告、公知的装逼(还有电视里各种广告，每次家里亲戚都问是不是真)，学习过滤垃圾信息非常重要(多问、多看、多思考)，坚持一到两年，就能有很好过滤信息能力(个人觉得过滤垃圾信息是搞IT人一个基本能力)，平时也多和家里的亲戚说说，避免他们上当受骗。瞎扯的有点多了，下面进入正题
上一篇博客分析栈的相关知识和分析用数组的方式实现队列(循环顺序队列)，循环顺序队列在内存中的存储位置是连续的，且编译器要求我们在编译期就要确定队列的大小，这样对于多数应用都不能很好的确定初始值(设置过大导致浪费内存，设置过小导致频繁分配造成大量内存碎片)，使用了链表来实现队列，链表中的元素存储在不连续的地址，由于是动态申请内存(也会造成内存碎片)，由于每个节点占用的内存空间一样并且很小，可以用内存池(boost的pool)避免频繁向系统申请和释放内存，基于上面的原因很多开源项目对栈的实现都是链式队列。
一、示例图
二：代码分析
1、节点入队
过程如示例图：
代码分析：
1 /** 2 * 节点入队列 3 */ 4 void EnQueue(const value_type& value){ 5 //创建一个新节点 6 LNode<T> *p = new LNode<T>(value); 7 8 //判断队列是否为空，如果为空直接赋值给front,back 9 if(IsEmpty()){ 10 back = front = p; 11 }else{ 12 //不为空：入口指针指向新的节点 13 back->next = p; 14 //改变入口指针为新创建的节点 15 back = p; 16 } 17 18 }
2、节点出队
过程如示例图：
代码分析：
1 void DeQueue(){ 2 //如果队列不为空，则出队列 3 if(!IsEmpty()){ 4 //释放删除节点占用内存，更多关于auto_ptr知识，请阅读memory里auto_ptr源码 5 std::auto_ptr<LNode<T> > new_prt(front); 6 //修改队列出口指针指向下一个节点 7 front = front->next; 8 } 9 }
3、获取队列入口和出口元素：
可以看到在队列类中，GetFront和GetBack函数是发生重载了，而且是合法的。而且在调用时，只用队列类的const对象才能调用const版本的GetFront和GetBack函数，理论而非const对象可以调用任意一种，通常非const对象调用非const版本的GetFront和GetBack函数。
具体原因：按照函数重载的定义，函数名相同而形参表有本质不同的函数称为重载。在队列类中，由于隐含的this形参的存在，const版本的函数GetFront和GetBack使得作为形参的this指针的类型变为指向const对象的指针，而非const版本的使得作为形参的this指针就是正常版本的指针。此处是发生重载的本质。重载函数在最佳匹配过程中，对于const对象调用的就选取const版本的成员函数，而普通的对象调用就选取非const版本的成员函数，具体的测试请参考test1和test2函数，代码如下。
1 /** 2 *获取队列出口元素 3 */ 4 reference GetFront(){ 5 std::cout<<"GetFront reference"<<std::endl; 6 return front->data; 7 } 8 /** 9 *获取队列出口元素 10 */ 11 const_reference GetFront() const{ 12 std::cout<<"GetFront const_reference"<<std::endl; 13 return front->data; 14 } 15 /** 16 *获取队列入口元素 17 */ 18 reference GetBack(){ 19 std::cout<<"GetBack reference"<<std::endl; 20 return back->data; 21 } 22 /** 23 *获取队列入口元素 24 */ 25 const_reference GetBack() const{ 26 std::cout<<"GetBack const_reference"<<std::endl; 27 return back->data; 28 }
4、清空队列
1 /** 2 *清空队列并回收资源 3 */ 4 void Clear(){ 5 //循环判断队列是否为空 6 while(!IsEmpty()){ 7 //节点出对并回收资源 8 this->DeQueue(); 9 } 10 }
5、判断队列是否为空
1 /** 2 * 判断队列是否为空 3 */ 4 bool IsEmpty() const{ 5 return front == 0; 6 }
6、计算队列长度
1 /** 2 *计算机队列大小 3 */ 4 size_t GetSize() const{ 5 6 size_t size = 0; 7 //获取队列出口 8 LNode<T> *p = front; 9 //循环整这个栈大小，当栈==0，表示栈已经遍历完成 10 while(p != 0){ 11 ++size; 12 //指向下一个栈节点 13 p = p->next; 14 } 15 16 return size; 17 }
7、运行结果
测试队列各方法示例图：
测试const函数重载示例图：
测试代码如下：
View Code
8、完整代码
LinkQueue.h 如下：
View Code
Common.h
View Code
三：环境
1、运行环境：Ubuntu 10.04 LTS+VMware8.0.4+gcc4.4.3；
2、开发工具：Eclipse+make
四：题记
1、上面的代码难免有bug，如果你发现代码写的有问题，请你帮忙指出，让我们一起进步，让代码变的更漂亮和更健壮；
2、鼓励自己能坚持把更多数据结构方面的知识写出来，让自己掌握更深刻，也顺便冒充下"小牛"；
3、感谢Vamei老大的指导，把博客弄漂亮，不被女朋友鄙视了。
4、后续数据结构方面的代码命名规则会严格按照STL的标准，期待这样能有缘人看更明白
欢迎继续阅读“启迪思维：数据结构和算法”系列
一根球杆，几行代码，品世间酸甜苦辣
如果你喜欢这篇文章，欢迎推荐