《软件项目管理原理与实践》 课件 第9章 Rational统一过程.pdf

第9章Ka住onal统一过程内容提要 9.1软件过程模式定义o9.1.1 几种典型的软件过程模式o9.1.2 定义软件过程模式的意义 9.2 Rational统一过程o9.2.1 Rational 简介o9.2.2 RUP的二维结构o9.2.3 阶段和里程碑o9.2.4 RUP 规程 9.2.5 RUP的模型、工件和信息流 9.3案例研究：利用视图与用例来捕获和描 述需求Co re Pro c ess Wo rk Fl o wRUP Phase ModelBusiness Modeling RequirementsAnalysis&DesignImplementation Test DeploymentCo re Suppo rting Wo rk Fl o wConfiguration&Change Management Project Management EnvironmentPhasesInception Elaboration Construction TransitionElab*2InitialConst i ConstConst i 2 1-mnIteratio ns3GRM artifacts Initial eptc trees Inibai prqec t bac kl o g Initial c urrent estimateDelivered system incrementsIteration 1 80/20 Specifications Data mo del So urc to-targ et mapp James Rumbaugh与Ivar Jacobson,同时，他们又是面向对象开发的行业标准语言 UML的创立者。13Enc apsul atio n(Objec t-Oriented Pro g ramming System)Objec tCl ass面向对象编程思想做IB M15Name:Objec t 1”Size:2Name:Objec t 2”Size:3Name:uObjec t 3”Size:1*Each object has its own values for fields and can call the methods found in the class面向对象编程思想Pro c edural Oriented Pro g rammingObjec tOriented Pro g rammingGl o bal DataGl o bal DataFunc tio n 27Func tio n 1Lo c al DataLo c al DataFunc tio n 317软件过程模式 从软件过程模式的角度而言，RUP对软件过程模式中的四大要素及相 互关系进行了详尽的论述。(1)在生命周期方面O RUP构架了一个迭代与增量的二维生命周期结构，其横轴为生命周期的四个阶段，即先启、精化、构建与产品化，各阶段结束于一个项目里程碑；纵轴为九个核心工 作流程，即业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项 目管理、环境。(2)在人员方面o RUP定义了角色概念，并从角色视角对不同人员从事的不同活动进行了规范。(3)在方法方面o RUP采用UML进行可视化建模、基于用例驱动且以构架为中心的分析设计，并且进 一步为整个过程提供了一整套支持各种方法和技术实施的开发工具Ratio nal So l utio ns,包括UML建模工具Ro se、文档自动生成工具So DA、测试工具PuHfy和 Qual ity配置管理工具Cl earCase、变更管理工具Cl earQuest等。(4)在产品方面o RUP将各种中间和最终产品称之为工件，对不同工作流程中的输入、输出工件类型 进行了规范，同时提供了多种工件的模板。18定义一个对象原型Define a bicycle object prototypeattributes:speedclass bicycle:*properties#Class variables.gear=1 speed=0 gearbehavio urs:def init(selff gear,speed):self.gear=gear self.speed=speed speed updef speedup(self,increase):self.speed+=increase apply brakedef changeGear(self,newGear):self.gear=newGear change geardef applyBrake(self,decrease):self.speed-=decrease192,敏捷过程为了应对软件开发人员所面临的挑战，矫正 某些官僚、烦琐的软件过程是很重要的。2001年2月，17个方法学家发起成立了敏捷软件开发联 盟，通常简称为敏捷联盟(Agile Alliance)。从软件过程模式的角度而言，敏捷过程对软 件过程模式中的四大要素及相互关系也分别进行了论述。/Agile4岛叵eCORPORATE MEMBER203.微软过程微软过程(Microsoft Process,MP)是由微 软公司根据自身实践经验为企业设计的一套 有关软件开发的准则。O作为世界上最大的软件公司之一，微软公司三十多年来 成功的软件开发史表明了微软过程的可实践性与有效性O从软件过程模式的角度分析，微软过程也是 紧密围绕软件过程模式中的四大要素及相互 关系展开论述。21Stage 1Gather dataStage 2Create insightsInfuse with AlEnterprise Business Pro c essSystemOperatio nalUserTelemetry dataBusinessIng est pro c ess,sto reMo nito r,repo rt and visual ize business pro c essesPerfo rm Al and mac hine l earning tasks to make business dec isio nsApplnsights Microsoft Azure Data LakeBusiness$cendfio$Process insight)Learning22UMLv RUP目前，全球有上千家公司在使用RUP,如爱立信、MCL英国宇航公司、施乐、沃尔沃、英特尔、VISA、甲骨文等，它们分布在电信、交通、航空、国防、制造、金融、系统集成等不同的行业和应 用领域，开发着或大或小的项目，这表现了RUP 的多功能性和广泛的适用性。FRUPRational Unified Process23Business Mo del l ingRequirementsAnal ysis&Desig nImpl ementatio nTestDepl o ymentCo nfig uratio n&Chang e Mg mt_|_Enviro nment24AGILEDepl o yTestPl an 1Review.Desig n JDevel o pLaunc hBefore During AfterCreate insightsValidate,simulate,and testMonitor and make decisions269.1.2 定义软件过程模式的意义相对软件生命周期模型而言，软件过程模式 这一概念的提出有如下理论和现实意义。O软件过程模式不仅关注软件过程中各生命周期阶段中的 活动，更重要的是它同时关注过程中的人员与角色分配、过程中采用的方法及过程各阶段的输入输出产品。O软件过程中这四大要素相辅相成、相互作用，从而构成 一个有机的整体，缺一不可。279.1.2 定义软件过程模式的意义相对软件生命周期模型，软件过程模式更全 面、深刻、细致地反映了软件过程中的各个 层面和各个环节。O作为对软件生命周期模型的补充和发展，软件过程模式 的四要素及相互关系是项目计划、风险评估、人员管理、质量保证等项目实践的重要依据，将它用于指导软件 开发实践具有现实的可操作性。O从软件过程模式的角度分析几种最新的、颇具影响力的 软件过程（如RUP、敏捷过程与微软过程），能迅速而 准确地把握这些软件过程的思想木质、原则规范、主要 特点和实现策略等各个方面。289.1.2 定义软件过程模式的意义现代软件开发除了需要建模技术与语言之外，还 需要一个先进的能够指导软件开发人员进行开发 活动的开发过程方法学。o 1998年最早由Ivar Jacobson提出的Rational对象过程(Rational Obj ect Process,ROP)被正式命名为Rational统一过程(Rational Unified Process,RUP),并且将UML作为其建模语言 o由此RUP成为IT业界最为成熟和成功的软件开发过程。o 2002年12月6日，旧M收购了Rational软件公司，从此赋予了RUP 新的生命力；通过加入旧M多年软件开发的最佳实践，形成了强大 的IRUP(IBM Rational Unified Process)架构。O先进的理论与旧M的最佳实践相结合使得现代软件开发能够通过切 实可行的指导来及早地发现并规避风险，通过统一建模、用例驱动、选代开发、需求管理、变更控制来提高软件产品的质量。292.核心概念可以通过一个示意图，把RUP的一些核心概 念表达出来，概念间的关系用箭头表示。工作流程明细,工件303.开发实践 迭代开发O在软件开发过程中，用户需求经常改变，通过多个迭代周期，分解需求，使得高风 险、高优先级的需求能够尽早实现，从而极大地减少软件开发项目的风险。O每个迭代过程都会生成一组可交付客户的产品，使客户反馈能够及时地反映到产品 中。需求管理O RUP借助用例来获取、组织与文档化用户的功能需求，并以此来驱动软件设计、功 能实现和产品测试，使交付的系统能尽量满足用户的需求。基于组件的体系结构O Ratio nal统一开发过程支持基于组件的软件开发方法。该方法关注于早期的开发和 健壮可执行的体系结构的基线(Basel ine),以设计灵活的、便于修改和理解的弹 性软件架构，以促进有效的软件重用、提高开发效率。可视化建模O在软件产品开发中，Ratio nal统一开发过程借助工业级的建模标准语言，即统一建 模语言(Urdfied Mo del Lang uag e,UML)来进行可视化建模软件体系架构，描述 各组件的结构与行为。O可视化抽象建模有助于加强开发团队的沟通交流，深入了解软件的不同层面，考查 各组件的配合情况，确保实现与设计的一致性及代码的兼容性。313.开发实践 质量验证O软件产品的质量涉及多个层面，例如功能性、可靠性、易用性、系统性能、可扩展性等。O Rational统一开发过程统一规划、设计、实现、执行并 评估这些验证活动，并通过迭代周期的可交付产品，引 入客户反馈来持续进行质量验证和改善工作。变更控制O Rational统一开发过程具有良好的变更管理能力，描述 了如何控制、跟踪和管理变更以完成迭代开发，拥抱客 户的需求变更请求。可定制的软件产品O包括方法学指导、过程定义、文档模以及示例工程等等329.2.2 RUP的二维结构 RUP是一个面向对象且基于网络的程序开发方法 论。o根据Rational（Rational Rose与统一建模语言的开发者）的说法，它好像一个在线的指导者，可以为所有方面与层次的程序开发提供 指导方针、模板以及事例支持。RUP与类似的产品例如面向对象的软件过程（Object Oriented Software Process,OOSP），以及 Open Process都是理解性的软件工程工具，把开发 中面向过程的方面（例如定义的阶段、技术和实 践）和其他开发的组件例如文档、模型、手册以 及代码等等）整合在一个统一的框架内。339.2.2 RUP的二维结构 RUP软件开发生存周期，可看作一个二维的 软件开发模型。O横轴通过时间组织，是过程展开的生存周期特征，体现 开发过程的动态结构，用来描述它的术语主要包括周期、阶段、迭代和里程碑。O纵轴以内容来组织为自然的逻辑活动体现开发过程的静 态结构，用来描述它的术语主要包括活动、要素、工作 者和工作流。34Rational的二维示意图35RUP Phase ModelPhasesCo re Pro c ess Wo rk Fl o wInceptionElaborationConstructionTransitionBusiness Modeling RequirementsAnalysis&DesignImplementation Test DeploymentCo re Suppo rting Wo rk Fl o wConfiguration&Change ManagementProject Management EnvironmentInitialElab*1 Elab 2ConstConstConstTnnTrantlL nN#1 2Iteratio ns36PhasesDiscipines口 Business Mo del ing口 Requirements Anal/sis&Desig n口 Impl ementatio n To si Depl o yment口 Co nfig uratio n&Chang e Mg mt Pro jec t Manag ement口 Enviro nment37RUP的特点(i)迭代开发与分阶段。(2)开发复用。这样可以减少开发人员的工作量,同时保证软件质量。(3)项目初期可降低风险。(4)对需求进行有效管理。(5)可视化建模。(6)使用构件体系结构，使软件体系结构更具弹 性。(7)贯穿整个开发周期的质量核查。(8)对软件开发的变更控制。38RUP的迭代开发（软件工程过程）39Top Software Development Best Practices前5名软件开发最佳实践DEVELOPMENT DELIVERING PRODUCTTO THE CUSTOMERDEFINING THE I MAINTENANCEPROJECT SCOPE STABILIZATION AND SUPPORTBest Practices for Enterprise App DevelopmentKnowing&Targeting Your AudienceProblem SolvingSecurity&FunctionalityFocusing on User Experience42Rational Unified Process(RUP)go/NO GOLifec yc l eObjec tiveLifec yc l eArc hitec tureInitial Operatio nal Capabil ityPro duc tRel easeCo mmit reso urc es fo r c o l abo ratio nCo mmit reso urc es fo r c o nstruc tio nPro duc t mature&c usto mer readyCusto mer ac c eptanc e o r end-o f-l ife43PHASES OF RUPGO/NO GOLifecycleObjectiveLifecycleArchitectureInitial Operational CapabilityProductReleaseCommitResources for ElaborationCommit Resources for ConstructionProduct nature&Customer readyCustomer Acceptance Or end of life44感4 3依.CufTtfrt EcWMMcv.le.n.rr.*i!c?e t JCr i .ar.j，:jj，I，：，45Rational Unified Process(RUP)Rtvii l iramari代Focusing on Nine Disciplines of RUPBy.Pawan Kumar9.2.2 RUP的二维结构SptinlWork47923 阶段与里程碑从管理角度出发，RUP中的软件生存周期在时间上被 分解为4个顺序的阶段，分别是初始阶段、细化阶段、构造阶段与交付阶段。初始 细化 构造 移交生命周期 目标里程碑生命周期 体系结构 里程碑始作力EW 初操能甥产品 发现 里程碑A48表1 不同阶段工作量和进度安排的分布表初始细化构造移交工作量5%20%65%10%进度安排10%50%50%10%各个阶段在进度安排(Schedule)和工作量(Effort)方面是不相 同的。和工作量会依据项目不同而有相当大的变化，但对一个中等规模 项目的典型初始开发周期，应该可以预计到工作量和进度安排之 间有以下的分布49资源不同阶段工作量和进度安排的分布图50初始阶段初始阶段的最重要目的，是实现所有项目干 系人在项目的生命周期目标上达成一致。O初始阶段对于新开发的工作很重要，在这些工作中，继 续项目之前，存在必须确定的重要业务与需求风险。对于专注于增强现有系统功能的项目，初始阶段会更加 简单，但仍专注于确保项目值得执行并可能执行。51初始阶段初始阶段的主要目标包括：O(1)确定项目的软件范围和边界条件，包括操作愿景、验收条件 以及产品中预计包含和不包含的内容。O(2)识别系统的关键用例和操作的主要场景，以促进主要设计的 平衡。O(3)对照一些主要场景，演示并证明至少一个候选体系结构。O(4)评估整个项目的整体成本和进度安排(以及为细化阶段的更 详细估计)O(5)评估潜在风险(不可预测源)O(6)准备项目的支持环境初始阶段结束时产生第一个重要的里程碑：生命 周期目标里程碑。生命周期目标里程碑用来评价项目基本的生存能522,细化阶段细化阶段的目的，是建立系统体系结构的基线，为构造阶段中的大量设计和实现工作提供稳固基 础。O体系结构可引发对最重要需求（那些对系统体系结构有巨大影响的 需求）和风险评估的考虑。O通过使用一个或者更多体系结构原型来评估体系结构的稳定性。细化阶段结束时产生第二个重要的里程碑：生命 周期结构里程碑。O生命周期结构里程碑为系统的结构建立了管理基线，据此，项目小 组能够在构建阶段中进行对比衡量。O此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的 解决方案。532,细化阶段细化阶段的主要目标包括：O(1)确保体系结构、需求和计划足够稳定，并将风险缓解至足以 预先确定完成开发所需的成本和进度安排。对于大多数项目，通过 该里程碑也意味着从低成本、低风险的操作转向有大量组织惯性的 高成本、高风险操作。O(2)针对项目在体系结构方面重要的风险。O(3)建立已创建基线的体系结构，它是针对在体系结构方面重要 的场景(通常显示项目的主要技术风险)得到的。O(4)产生达到生产质量的构件的演进原型，以及可能一个或多个 探索性、废弃性原型以缓解特定风险，例如，设计/需求的权衡，构件重用，产品可行性或对投资方、客户和最终用户的演示。O(5)证明建立了基线的体系结构将以合理的成本和时间满足系统 需求。O(6)建立支持环境。543.构造阶段构造阶段的目的，是根据建立了基线的体系 结构，理清剩余的需求并完成系统的开发。o构造阶段在某种意义上是制造流程，强调管理资源和控 制操作，以优化成本，同时保证进度和质量。o在此意义上，管理理念体系从初始和细化阶段的知识资 产的开发转向构造和移交阶段的可部署产品的开发。553.构造阶段构造阶段的主要目标包括：O(1)通过优化资源和避免不必要的浪费和重复劳动，使开发成本降到最低。O(2)尽可能快地达到质量要求。o(3)尽可能快地完成有用的版本(alpha、beta和其他 测试发行版)。O(4)完成所有必需功能的分析、设计、开发和测试。O(5)以迭代和增量方式开发完整的产品，该产品已准 备好转移到其用户团体。这暗含了O(6)描述剩余的用例和其他需求、充实设计、完成实 现并测试软件。O(7)确定软件、站点和用户是否已全部准备好部署应 田程序C563.构造阶段 一个在开发团队的工作中达到一定的并行度。O即使对于较小的项目，通常也存在可彼此独立开发的构件，使得团 队之间的工作一般具有并行性（如资源允许）。O这一并行性可以显著加快开发活动，但也增加了资源管理和工作流 程同步的复杂度。O如要实现任何重大的并行性，一个强壮的体系结构是必需的。构建阶段结束时产生第三个重要的里程碑：初始 操作里程碑。O初始操作里程碑决定了产品是否可以在测试环境中进行部署。O此刻，要确定软件、环境、用户是否可以开始系统的运作。o此时的产品版本也常被称为“beta”版。574.移交阶段移交阶段的重点，是确保用户可使用软件。O移交阶段可以跨越若干迭代，并包含为发行版准备的产 品测试，并根据用户反馈做出较小的调整。O在软件生命周期中的此时刻，用户反馈应主要集中在调 整产品、配置、安装和可用性问题上，所有重大的结构 问题应在项目生命周期早期得到处理。584.移交阶段移交阶段的主要目标包括：O(1)Beta测试，以对照用户期望验证新系统。o(2)Beta测试以及与正在替换的旧系统相关的并行操作。o(3)转换操作数据库。o(4)培训用户和维护人员。o(5)展示给市场营销、分发人员。o(6)特定于部署的工程，如接入、商业包装和生产、销售展示、现场人员培训。O(7)调整诸如错误修订、性能和可用性增强之类的活动。O(8)对照整个愿景和产品的可验收条件来评估部署基线。o(9)实现用户的自支持能力。o(10)实现项目干系人在已完成部署基线这一点上达成一致。o(11)实现项目干系人在部署基线与愿景的评估条件一致这一点上 达成一致。599.2.4 RUP 规程规程(Discipline)是相关任务的集合，这些 任务定义主要的关注区域(Area of Concern)oo在软件工程中，规程包括业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理以及 环境。以前的版本称为RUP的核心工作流(Core Workflow),并分为6个核心过程工作流(Core Process workflow)和3个核心支持工作 流(Core Supporting Workflows)。609.2.4 RUP 规程将任务分组为规程主要是帮助从传统的瀑布 式角度理解项目。O尽管人们通常同时跨多个规程执行任务（例如，紧密结 合分析与设计任务来执行特定的需求任务），但将这些 任务分成不同的规程可有效地组织内容，从而使理 解变得容易一些。O按相同规程对多个任务进行分类的另一个原因是这些任 务都代表实现更高目标中的一个组成部分，或代表执行 互相关联的任务中的一个组成部分。O每个规程都定义执行由规程分类的工作的标准方式。61商业建模(Business Modeling)(1)商业建模(B usiness Modeling)O商业建模工作流描述了如何为新的目标组织开发一个构 想，并基于这个构想在商业用例模型与商业对象模型中 定义组织的过程、角色和责任。_L冬启阶段初期J nF-,评估业务状态 I业?延模1国 歌对J 确定业务流程 谶说明当前业务值园 金 生改进当务流程|00|ol|I 流程自动化研究开发领域模型国设计业务流程实现鬲改进角色和职责62需求工作流程图(2)需求(Requirement)O需求工作流的目标，是描述系统应该做什么，并使开发人员和用户 就这一描述达成共识。O为了达到该目标，要对需要的功能与约束进行提取、组织、文档化,最重要的是理解系统所解决问题的定义和范围。63分析与设计工作流程图(3)分析和设计(Analysis&Design)o分析与设计规程将需求转化成未来系统的设计，为系统开发一个健壮的结 构并调整设计使其与实现环境相匹配，优化其性能。O分析设计的结果是一个设计模型与一个可选的分析模型。设计模型是源代 码的抽象，由设计类和一些描述组成。o设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem),而描述则体现了类的对象如何协同工作实现用例的功能。早期精华迭代精华迭 _分析行为64实现工作流程图(5)测试(Test)o测试规程要验证对象间的交互作用，验证软件中所有组件的正确集成，检 验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并 处理，RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可 能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型,分别从可靠性、功能性和系统性能来进行。65部署工作流程图(7)配置和变更管理(Configuration&Change Management)O配置和变更管理规程描绘了如何在多个成员组成的项目中控制大量的产物 O配置和变更管理工作流提供准则来管理演化系统中的多个变体，跟踪软 件创建过程中的版本。O规程描述了如何管理并进行开发、分布式开发、如何自动化创建工程，同 时也阐述了对产品修改原因、时间、人员保持审计记录。计划项目配置 与变更控制创建项目配置 管理环境变更鸟支付 配置项管理基线 与发布V 66项目管理工作流程图(8)项目管理(Project Management)o软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并 成功交付使用户满意的产品。O其目标包括为项目的管理提供框架，为计划、人员配备、执行与监控项目 提供实用的准则，为管理风险提供框架褊于最初迭代申 仅用于最初迭代+结束 迭代67环境工作流程图(9)环境(Environment)o环境工作流的目的，是向软件开发组织提供软件开发环境，包括过 程和工具。O环境工作流集中于配置项目过程中所需要的活动，同样也支持开发 项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实 现过程。689.2.4 RUP规程 RUP具有很多长处。RUP提高了团队生产力，在迭代的开 发过程、需求管理、基于组件的体系结构、可视化软件建 模、验证软件质量以及控制软件变更等方面，o针对所有关键的开发活动为每个开发成员提供了必要的准则、模板与工具 指导，并确保全体成员共享相同的知识基础，建立了简洁和清晰的过程结 构，为开发过程提供较大的通用性。但是，同时它也存在一些不足。O RUP只是一个开发过程，并没有涵盖软件过程的全部内容。此外，它没有支持多项目的开发结构，这在一定程度上降 低了在开发组织内大范围实现重用的可能性。O可以说，RUP是一个非常好的开端，但并不完美。在实际的应用中可根据 需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对 RUP进行补充和完善。699.2.5 RUP模型、工件及信息流对于一个大型项目，RUP这9个规程的活动 不可或缺，但对于有些项目可能不需要经过 所有9个规程，在项目开发时需要对这些规 程涉及的活动做具体的裁剪，以适应具体项 目的开发需要。70主要的规程及模型业务建模主要的模型是业务用例模型和业务对象/分析模型，需求主要的模型是用例模型，分析 设计主要是设计模型，实现主要是实现模型，测 试主要是测试模型。测试模型71从需求、分析设计、实现、测试到部署的活动中涉及多个工件(Artifact),包括干系人请求、愿景文档、术语表(Glossary)、软件 需求规约/规格说明书、分析模型、设计模型、软件体系结构文档、实 现模型(Implementation Model)等，软件需求规约主要包括用例模型(Use Case Model)与补充规约(Supplementary Specification)。O 从项目管理的角度来说，还有风险列表(Risk List)软件开发计划、测试计划和部署计划等BB涉众请求某软件公司的项目开发小组要针对某型号的 IT路由设备开发一整套调试系统。用户的需求是：调试技术工程人员使用该调试系统，能 够实时监测设备状态和发送调试命令。O设备的状态信息由专用数据采集装置实时采集。731.用例图描述需求根据客户需求分析，可以设计出该系统的用 例图随后，项目开发小组运用“4+1视图”方法,用不同的视图进行架构的设计，分别满足 不同需求的用户要求。设备74设备调试系统的用户需求约束运行期质 量属性开发期质 量属性功能需求程序的嵌入式部 分必须用C语言 开发一部分，开 发人员没有嵌入 式开发经验高性能易测试性查看设备 状态发送 调试命令75首先按照功能需求进行初步设计，进行大粒度的职责划分OO(1)应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命 令。O(2)应用层使用通信层与嵌入层进行交互，但应用层不知道通信的细节OO(3)通信层负责在RS2 3 2协议之上实现一套专用的“应用协议”。o(4)当应用层发送来包含调试指令的协议包，由通信层负责按RS2 3 2协 议将之传递给嵌入层。76设备调试系统架构的逻辑视图O(5)当嵌入层发送来原始数据，由通信层将之解释为应用协议包发送给 应用层。O(6)嵌入层负责对调试设备控制，并高频度地从数据采集器读取设备状 态数据。O(7)设备控制指令的物理规格被封装在嵌入层内部，读取数据采集器的 具体细节也被封装在嵌入层内部。应用层通信层嵌入层77由架构设计来完成，这些决策如果被安置到 后边，最终到了大规模并行开发阶段才发现,可能会造成大量出现“程序员拍大腿决定”的情况，软件质量必将无法保障以至于导 致项目失败。78设备调试系统架构的开发视图其中，采用哪些现成框架、哪些第三方软件开发工具包(Software Development Kit,SDK)和哪些中间件平台，者B 应该考虑是否由软件架构的开发视图决定。O展示了路由设备调试系统的一部分软件架构开发视图：应用层将基于MFC 设计实现，而通信层采用了某串口通信的第三方SDK。79对于约束性需求来说，约束应该是每个架构 视图都应该关注与遵守的设计限制。例如：考虑到“部分开发人员没有嵌入式开 发经验”这条约束，架构师一定有必要明确 说明系统的目标程序是如何编译而来的80设备调试系统架构的开发视图整个系统的桌面部分的目标程序pc-module.Exe与 嵌入式模块rom-module.hex是如荷编译而来。O这个全局性的描述对没有嵌入式开发经验的开发人员来说提供了真 实感，有利于全面地理解系统的软件架构。81性能是软件系统运行期间所表现出的一种质 量水平，一般用系统响应时间与系统吞吐量 来商量。O为了满足高性能的要求，软件架构师应针对软件的运行 情况，进行分析与设计，这就是所谓的软件架构处理视 图目标。O处理视图关注进程、线程和对象等运行时概念，以及相 关的并发、同步和通信等问题。82架构师为了满足高性能需求，采用了多线程 的设计：O(1)应用层中的线程代表主程序的运行，它直接利用 了 MFC的主窗口线程。口无论是用户交互，还是串口的数据到达，均采取异步事件的方 式处理，杜绝了任何“忙等待”无谓的耗时，也缩短了系统响 应时间。O(2)通信层有独立的线程控制着“进进出出”的数据,并设置了数据缓冲区，使数据的接收与数据的处理相 对独立，从而数据接收不会因暂时的处理忙碌而停滞，增加了系统吞吐量。O(3)在嵌入层的设计中，分别通过时钟中断与RS232 口中断来触发相应的处理逻辑，达到轮询与收发数据的 口 AA_83设备调试系统架构的处理视图84任何软件最后都要驻留、安装或部署到硬件 上才能运行，而软件架构的物理视图关注目 标程序及其依赖的运行库与系统软件最终如 何安装或部署到物理机器，以及如何部署机 器与网络来配合软件系统的可靠性、可伸缩 性等要求。85设备调试系统架构的物理视图所示的物理架构视图，表达了设备调试系统 软件与硬件的映射关系。可以看出，嵌入部分驻留在调试硬件中，而PC上是常 见的应用程序的形式。86设备调试系统架构的物理视图项目组还可以根据实际情况的需求，通过物 理架构视图更清晰地表达具体目标模块及其 通信结构877.案例小结深入理解软件需求分类的复杂性，明确区分 功能需求、约束、运行期质量属性和开发期 质量属性等不同种类的需求才能设计和开发 出用户满意的软件产品。O各类需求对架构设计的影响截然不同。O通过案例的分析，展示了如何通过RUP的“4+1视图”和用例方法，针对不同需求进行架构设计，从而确保重 要的需求一一被满足。88设备调试系统架构的逻辑视图(1)应用层负责设备状态的显示，并提供模拟控 制台供用户发送调试命令。(2)应用层使用通信层与嵌入层进行交互，但应 用层不知道通信的细节。(3)通信层负责在RS2 3 2协议之上实现一套专用 的“应用协议”。(4)当应用层发送来包含调试指令的协议包，由 通信层负责按RS2 3 2协议将之传递给嵌入层。(5)当嵌入层发送来原始数据，由通信层将之解 释为应用协议包发送给应用层。(6)嵌入层负责对调试设备控制，并高频度地从 数据采集器读取设备状态数据。(7)设备控制指令的物理规格被封装在嵌入层内 部，读取数据采集器的具体细节也被封装在嵌入 层内部。89软件架构的开发视图应当为开发人员提供实 在的指导。O任何影响全局的设计决策都应由架构设计来完成，这些 决策如果被安置到后边，最终到了大规模并行开发阶段 才发现，可能会造成大量出现“程序员拍大腿决定”的 情况，软件质量必将无法保障以致于导致项目失败。90对于约束性需求来说，约束应该是每个架构 视图都应该关注与遵守的设计限制。91性能是软件系统运行期 间所表现出的一种质量 水平，一般用系统响应 时间与系统吞吐量来衡 量。O为了满足高性能的要求，软件 架构师应针对软件的运行情况,进行分析与设计，这就是所谓 的软件架构处理视图目标。O处理视图关注进程、线程和对 象等运行时概念，以及相关的 并发、同步和通信等问题。92设备调试系统架构的物理视图项目组还可以根据实际情况的需求，通过物 理架构视图更清晰地表达具体目标模块及其934 REQUIREMENTSUnderstand the technical requirements of this project.Every piece of softwarewhether its an app,website redesign,or new feature-needs to solve a customer problemANALYSIS cThis step is about analyzing the performance of the software at various stages and making notes on additional requirements.Analysis is very important to proceed further to the next step.3 DESIGNThe objective in this step is to define internal structure and algorithms for components that meet client-oriented specifications.CODING AAfter the best or the most appropriate design has been selected,ZI implementation starts immediately.The team develops and implements software according to the pre-defined specifications.5 TESTINGThe testing stage assesses the software for errors and documents bugs if there are an