企业体系结构开发Word格式.docx
- 文档编号:18203822
- 上传时间:2022-12-14
- 格式:DOCX
- 页数:9
- 大小:481.74KB
企业体系结构开发Word格式.docx
《企业体系结构开发Word格式.docx》由会员分享,可在线阅读,更多相关《企业体系结构开发Word格式.docx(9页珍藏版)》请在冰豆网上搜索。
重要的目标在于:
促进在步骤7中并行迭代开发(即编码和测试)的生产率。
我们在这里强调步骤7中所进行的活动,是因为在这些步骤中包含了我们认为在当前企业开发中存在的关键的问题,即体系结构规划活动。
我们需要强调:
这个过程本质上就是迭代和递增的,可能需要修改以前的步骤的制品(结果)。
然而,因为它们之间互相依赖,预开发步骤确实有一个瀑布式的进程。
整个的过程是质量驱动的,最终的目标是提供一个稳定可靠的体系结构描述和一个能适应变化的运行软件代码库,以满足最终用户的需求。
步骤1:
系统构想
讨论建模的时候,我们曾提到关键词有目的、焦点、假设和优先级,它们都是系统级的“构想描述(VisionStatement)”的基本元素。
如果它们在系统开发过程中改变,那么项目就有抛弃自身模型的危险。
因此,以体系结构为中心的开发的第一步就是建立一个构想描述。
一旦开始(步骤7),就假定构想描述不会改变。
所有的改变必须在关键的项目计划中有所反映——特别是在系统体系结构(步骤3)中。
实际上,构想描述是一个系统开发人员与系统用户之间共同的协议,它必须简短而切中要点,根据系统不同而不同,通常不到十页文本。
构想描述建立了从需求分析开始的所有接下来的项目活动的语境(上下文)。
步骤2:
需求分析
需求应该定义系统的外部行为和外观,而不用设计系统的内部结构。
外部行为包括了用来保证外部行为能够完成而所需的内部行为(比如持续性或计算)。
外观包括用户界面的布局和导航。
一个有效地捕捉行为需求的方法是通过用例(usecase)。
一个用例包含一个顶层的图和扩展的文字描述。
用例符号简单得令人难以置信,但它却具有不可估量的价值:
它促进了抽象。
用例符号在已发明的表述复杂概念的记法中,是最有效的。
因此,它非常适合于用来保证在表述顶层需求概念时的简单性和清晰度。
图中的每个圆(称做一个单独的用例)都有一个相关需求的扩展文字描述。
这种方法采用了包含一系列活动的长列表形式,用特定领域的平铺直叙的文字来描述。
定义用例应该和领域专家一起进行。
如果没有领域专家的长期参与,这种活动只能是一种常见的反模式,称为“伪分析”,这是需要避免的。
用例为定义体系结构提供了一个系统的领域模型。
用例也发挥着顺流(downstream)的角色。
在开发的步骤7中,用例被特定系统的场景图表所扩展,最后这些场景会在软件测试中详尽的予以阐述。
用户界面的外观、功能和导航同用例紧密相联。
一个有效定义屏幕的方法叫做低保真度原型(low-fidelityprototyping)。
在这种方法中,屏幕是用纸和笔先画出来的。
同样,最终用户领域专家也始终参与到屏幕定义的过程中去。
有了用例和定义的用户界面,我们已经建立了体系结构规划的环境。
在产生文档之外(包括纸、笔的草图),体系结构小组获得在最终用户领域中对所需的系统功能的更深刻的理解。
需求分析的最终产品是一个项目词汇表,它应在体系结构规划(步骤3)中被扩展。
步骤3:
体系结构规划
体系结构沟通了需求和软件之间巨大的语义上的鸿沟。
因为需求语言是平铺直叙的,从本质上说,需求是模糊的、直观的和不正式的——这是右脑所要考虑的问题。
而软件则具有相反的性质:
软件的源代码是一种正规的符号;
软件被机器无二义性地翻译,它的含义在逻辑上也是不直观的(即,很难解码)——这是左脑所要考虑的问题。
体系结构的第一个任务就是定义这两个极端之间的映射。
体系结构用一种更为正规的方式来捕捉直觉的决定(这对程序员来说是很有用的),它在硬连线(hardwire)形成编码(这样当前和将来的需求可以满足)之前定义了内部的系统结构。
体系结构作为一项计划,它用允许系统构建和适应变化的方法来管理系统的复杂性。
体系结构还有另一个显著的任务:
定义软件项目的组织(参见步骤6)。
在当前的许多软件项目、过程和方法中,体系结构规划是容易被忽略的重要步骤。
造成这个鸿沟的原因之一是长期以来关于什么是体系结构的讨论。
幸运的是,这个问题已被软件体系结构专家用开放分布式处理的正式ISO标准予以了明确的回答。
开放分布式处理(ODP)是一种考虑复杂系统的强有力的方法,它使作出决定变得更加容易(更为聪明地工作,而非更加费劲)。
它从5个标准的视点组织了系统的体系结构,描述了同一系统的重要方面。
这些视点包括企业、逻辑信息、计算接口、分布式工程和技术选择(参见图3.4)。
对于每个视点,确认体系结构需求的一致性是非常重要的。
如果一致性没有客观的定义,那么体系结构是没有意义的,因为它对实现没有明确的影响。
开放分布式处理促进了这个过程,因为它内嵌了一个普遍的一致性方法。
简单的一致性清单包含识别体系结构中一致点所需的全部内容。
在下面的几个小节中,我们将总结各个视点。
采用开放分布式处理,一个典型的体系结构规范是简洁的,包含大约100页,因系统不同而有所不同。
每个视点包含5~20页。
通常希望每个开发者一页一页地详细阅读这个文档,并了解它的内容。
我们建议把内容做成向导(视图),并通过一个几天的初始会议(见步骤7)同开发者进行细节上的交流。
图3.4ODP视点
业务企业体系结构
业务企业体系结构(企业视点)用高层企业对象来定义业务目的和系统策略。
这些业务对象模型标识出系统的关键性约束,包括系统目标和重要的系统策略。
策略包含三类明确的表达方式:
①责任——业务对象必须做什么;
②许可——业务对象可以做什么;
③禁止——业务对象不可以做什么。
一个典型的业务企业体系结构包含一系列逻辑对象图(用UML表示)和对图的语义平铺直叙的文字描述。
第3章软件体系结构:
准备战斗
3.3正确的方法:
企业体系结构开发(3)
逻辑信息体系结构
逻辑信息体系结构(信息视点)标识出系统必须知道什么。
这种体系结构通过一个对象模型来表达,强调定义系统状态的属性(attribute)。
因为开放分布式处理是一种面向对象的方法,模型包含了关键信息的处理,它使用属性来进行封装,如传统的对象概念。
一个重要的特性是,体系结构对象并不是编程的对象,例如,信息对象并不代表必须要被编程的对象。
在另一方面,体系结构倒不排斥这种尝试。
体系结构对象表示对系统正面和负面的约束。
正面约束标识出软件必须做什么。
负面约束标识出软件不需要做什么。
关于这些约束的知识对于程序员来说极其有用,因为它们消除了在把需求翻译成软件过程中的许多的猜测工作。
架构师应该把他们的建模集中于系统中具有高风险、高复杂性和模糊性的关键方面,而把直接的细节放在开发的环节中。
信息模型并不包含工程的设计。
特别是,工程分析,如数据库标准化,明显地代表了开发活动(步骤7)。
计算接口体系结构
计算接口体系结构(计算视点)常常被架构师所忽略,它定义了顶层的应用程序接口(API),这些是完全工程化的子系统边界的接口。
在实现时,开发者将对他们的模型在这些边界上进行编程,以消除多个开发者和小组的主要设计争端。
这些接口的体系结构控制对于一个支持变化和控制复杂性的稳定的系统结构来说,是很重要的。
开放分布式处理计算体系结构的一个ISO标准记法是CORBA接口定义语言(IDL)。
IDL对于软件架构师而言,是一种基本的记法,因为它完全独立于编程语言和操作系统。
IDL可以被商业上可得到的编译器自动地翻译成
CORBA和微软技术库(COM/DCOM)等大多数流行的编程语言。
定义计算体系结构的相关技术包括体系结构挖掘和领域分析。
分布式工程体系结构
分布式工程体系结构(工程视点)定义了底层结构的需求,而独立于所选的技术(参见图3.5)。
工程视点解决了一些最复杂的系统策略,包括物理位置、系统规模可变性和通信服务质量。
ODP的一个最大的好处就是关注点(即设计要点)分离。
幸运的是,前面的视点解决了许多其他复杂问题,那些是分布式系统架构师较少关注的,如API、系统策略和信息纲要(schemas)。
相反地,这些其他的视点能够解决它们各自的设计要点,而独立于分布式的考虑。
许多软件和硬件工程师发现体系结构建模这部分最为有趣。
做出好的决定必须考虑系统的各个方面,如对象复制、多线程和系统拓朴。
技术选择体系结构
技术选择体系结构(技术视点)确定了实际的技术选择。
所有其他视点都独立于这些决定。
因为大多数体系结构设计是独立的,商业技术的发展可以很容易地适应。
一个系统的选择过程包括初始的概念性机制的确认(如持久性或通信)。
概念性机制的特定属性可以从其他视点中得到。
具体的机制被标识出来(如DBMS、OODBMS和平面文件)。
这些特定的参选机制是从可得到的技术(如Sybase、Oracle和对象设计数据库)中选出来的。
基于对候选者的初始选择,这个过程根据产品价格、培训要求和维护风险之类的项目因素而反复进行。
记住所做的选择的原因是很重要的,因为所有这些视点可以作为以后体系结构约束的理由。
记录可以放在一个由体系结构小组维护的非正式项目记事本上,用于以后参考。
步骤4:
实现模型
步骤2的屏幕定义被用来建立系统的一个在线模型(mockup)。
虚拟数据和简单文件I/O可以用来提供对用户界面关键部分的更为现实的模拟。
模型用于向最终用户和资方赞助人展示。
最终用户和架构师应该一起审查模型并贯穿于用例(步骤2)来证实需求有效。
通常,在这个交流中会出现新的或修改过的需求。
对于修改过屏幕的屏幕垃圾,为了接下的开发活动而需要标注它们。
对于需求的任何修改都要结合到随后的其他的体系结构活动中去。
通过模型,管理层能够看到可视化的进展,这对大多数项目来说是一个重大的成就。
这个步骤是一个在外部(或垂直)增加的例子,用来在行政或其他方面降低风险。
采用快速原型技术(如屏幕生成向导),对于大多数系统来说,不到一个工作月的时间模型就可以生成。
第3章软件体系结构:
企业体系结构开发(4)
步骤5:
体系结构原型
体系结构原型是对系统体系结构的一种模拟。
通过对系统API定义的编译以及编写根程序来模拟运行中的系统。
体系结构原型用于证实计算和工程体系结构,包括穿越分布式边界的控制流和定时。
使用CORBA这样的技术,一个体系结构的规范能够被自动地编译成带有分布式stub(请求方)和框架程序(服务方)的一系列程序头文件。
通过在框架程序中插入虚拟代码来模拟处理过程。
编写简单的客户程序用虚拟数据来穿越边界发送请求。
一些关键的(例如高风险的)用例被替换的客户程序所模拟。
原型的执行被计时以确保与工程约束相一致。
计算、工程和技术体系结构的变化应被提出和评估。
步骤6:
项目管理规划
作为预开发过程的最后一个步骤,项目管理规划被确定下来,以解决资源问题,包括人员、设备、器材和商业技术的采购。
根据资源的可用性(交付时间)和项目活动,要建立一个进度表和预算。
步骤7的进度表是根据外部和内部增量的并行活动制定的。
外部增量支持减少需求和管理方面的风险(见步骤4)。
内部增量支持开发资源的有效使用——比如被多个子系统使用的后台服务的开发。
当前最好的策略是实现几个小的内部增量来支持大规模的外部增量,这叫做VW分级(VWstaging)。
理想情况是,形成几个4人项目小组,并能在3个月内交付外部增量。
在实践中,这已被证明是最有效率的小组规模和增量周期。
以体系结构为中心的过程允许并行增量。
因为系统被定义得很好的计算边界所分割,开发小组能在被分配的边界中独立工作,与其他小组相并行。
集成规划包括跨越体系结构边界的增量。
项目规划的细节不应该是不一致的。
规划应该描述早期的增量细节,并且应该包括为了以后的项目部分重新规划的活动。
这一点也体现了项目规划者并不预先知道所有一切的现实。
还需要准备一个减少风险的计划,即技术备份的确定。
模型和体系结构原型开发小组应该继续开发使用高风险技术的试验性原型,而这些技术是绝大多数开发者未掌握的。
我们称之为“领头小组”,它是减少风险的一个关键要素。
项目管理规划的最后一项活动是体系结构审查和作出决定。
对于这一点,同完整的开发相比(大约5%的系统代价),企业负责人只作出相对较少的决定。
项目的执行委托人必须作出是否要建立系统的业务决定。
这个执行决定将迅速导致许多其他的决定,而那些几乎是无法逆转的(如技术限制、花费和供应商的广告宣传等)。
在这一点上,系统架构师在当前的业务和技术环境中,要提供最佳的解决策略和方法。
如果同机会成本相比,系统概念仍然对业务有意义,那么企业在实现系统方面处于有利的位置,因为它们采用了正确的方式开发软件。
步骤7:
并行增量开发
项目开发的初期涉及几项重要的活动。
开发者必须学习和吸收体系结构及需求。
一个有效的途径是开几天出师会议,要包含进领域专家和架构师的详细指导。
以前所有步骤的结果对开发者迅速和全面的推进起着影响作用。
我们建议把讲座用录像的形式记录下来,这样替补人员可以接受同样的培训。
每个增量都涉及一个完整的开发过程,包括设计、编码和测试等。
最初的时候,绝大多数的增量集中于各个子系统。
在项目的进行中,越来越多的增量将涉及多个子系统的集成。
项目节奏被确定下来,使开发建设和测试能够彼此协调。
对于大多数软件开发活动而言,除了在某些计划的点(在那些点可以无缝插入体系结构的更新),体系结构均被冻结。
体系结构的稳定性使并行开发成为可能。
例如,在一个主要外部增量的最后,可以在下一个增量开始之前插入计算体系结构的更新。
增量从软件的更新开始,并与变化相一致。
在实践中,随着项目的进行,更新会越来越少。
架构师的目标是根据开发经验的反馈来提高该解决方案的稳定性和质量。
在部署一个合适的稳定配置之前,一个典型的项目需要两次体系结构的重构(refactoring)。
步骤8:
系统转换
把系统部署到最终用户的试验性群体中是开发过程中的一个必需的部分。
根据在初始的部署中所学到的,开发的迭代可能会加入到计划中去。
计划落空是不可避免的,而严重的质量缺陷如果是因为显而易见的原因,这是无法容忍的。
通过重构软件(改进软件结构)来提高质量是系统中的一个重要的花费,不应该被忽视。
在这一步骤中,架构师的一个重要任务是系统验收。
架构师要确定系统的实现同工程设计书相一致,并且确实满足了最终用户的需求。
这项任务称为体系结构认证。
实际上,架构师应该是在最终用户的兴趣和开发者兴趣之间公正的仲载者。
如果最终用户定义了新的需求而与体系结构的假设相冲突,架构师将评估这个要求,并同双方一起规划一个可行的解决方案。
步骤9:
操作和维护
操作和维护(O&
M)是以体系结构为中心开发的真正的检验之地。
以正确的方式开发软件是否有效,将在这一步中得到检验。
大部分的系统成本都花在这里。
多达70%的O&
M开销是因为系统扩展——需求和技术的变化,这是持续开发的源泉。
典型地,程序员一半的时间不得不花在试图指出系统如何工作上。
以体系结构为中心的开发用一系列清晰、简洁的文档,即系统体系结构,来解决这个混乱。
步骤10:
系统移植
把系统移植到后继的目标体系结构通常发生在系统生命周期的最后阶段。
系统移植的两个主要方法分别称为“爆破式(bigbang)”和“渐进式(chickenlittle)”。
爆破式是对遗留系统的完全取代。
在实践中,爆破式几乎不会成功,它是系统移植的一个常见的反模式。
渐进式方法更为有效,并且最终更易获得成功。
渐进式包含对目标和遗留系统同时部署的操作。
最初的目标系统用户是试验性群体(像步骤8中那样)。
网关(gateway)集成在遗留系统和目标系统之间。
正向网关允许遗留系统用户访问已移植到目标系统的数据。
反向网关允许目标用户具有对遗留系统数据的访问透明性。
数据和功能被增量地从遗留系统移植到目标系统中。
系统移植是一个持续的变革过程。
随着时间的推移,新的用户被加入到目标系统中,并且脱离了原先的环境。
从长远考虑,切换遗留的系统是切实可行的。
到那时,目标系统在一次新的系统移植中又将作为遗留系统出现。
步骤8的目标系统转换和步骤10的遗留系统移植是交叉重叠的,在渐进式方法中,步骤8、9、10都是连续的移植过程的一部分。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 企业 体系结构 开发