企业标准体系结构开发Word格式文档下载.docx
《企业标准体系结构开发Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《企业标准体系结构开发Word格式文档下载.docx（9页珍藏版）》请在冰豆网上搜索。
图3.3展示了覆盖整个系统生命周期以体构造为中心开发十个环节。
重要目的在于：
增进在环节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都是持续移植过程一某些。
升级会员 