软件架构设计与模式PPT学习课件.ppt

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,软件架构设计与模式,薛君敖 博士,Junao,Xue,Ph.D,xuejunao,2009,年,12,月,9-11,日,1,2,讲师介绍,81,年赴美，美国哥伦比亚大学电脑科学硕士、物理学博士。,85-87,在美国芝加哥,AT/T Bell Laboratory,工作期间，参与,编写,5ESS,（超大型交换机）,Database Retrofit,的数据库架构层面的设计和实施方案,，包括：设计和管理安全的数据库架构，设计和管理高可用性解决方案，优化和实施数据库的数据恢复计划，设计、部署和巩固数据库架构。,88-94,在美国新泽西州,AT/T Bell Laboratory,工作期间，是,DACS,（大型传输交换连接设备）的,Architect,组成员，为,DACS,的逻辑架构、物理架构和系统架构设计提供解决方案,，并主持,DACS,的,FSTS,（工厂测试系统）系统设计，从硬件基础设施、技术平台、应用平台到应用的设计和实施。之后参与,编写,SDH,和,DWDM,两大光通讯网络的网管系统（,INMS,）的逻辑,/,物理,/,系统架构设计方案,。,94-02,Lucent Technologies Bell Labs Innovations,在任朗讯科技贝尔实验室网管技术支持小组组长兼任原邮电部网管专家顾问期间，为北京，上海，深圳，武汉，南昌等地,SDH/DWDM/,光网络及网管的设计和实施提供技术解决方案,03-06,在任“微软,-,北京邮电大学软件学院,-,亚鸿世纪软件联合研究中心”副主任、兼任北京亚鸿世纪软件公司总经理和中科软国际部技术顾问期间，为中国电信业,提供业务流程重组（,BPR,）、业务流程管理（,BPM,）的,IT,解决方案,；领导编写为韩国电信和中国电信用的,基于,COBIT/ITIL/MOF,的,IT,解决方案,，指导开发基于,Biztalk,和,SPS,的,OSS/BSS,已部署在河南通信、威海通信。,06-,现在 普信管理,&,祝成科技在任首席,IT,专家期间，为上海浦发银行、上海农商行、中国兵器集团财务公司提供包括,对,IT,建设,/IT,服务管理,/IT,应用的评估咨询服务,，并为它们做了,IT,评估报告和,IT,规划,包括,21,个,IT,系统的升级架构设计和需求分析；以,RUP,为指导，领导开发了,基于,SOA/BPM/Web2.0,技术平台的银行,/,金融业,GRC,综合管理平台,。,85-01,贝尔实验室,DMTS,（资深研究员），,04-09,微软,MVP,（最有价值专家）,3,Agenda,软件架构导引,业务建模,&UML,需求分析,软件架构视图,架构设计实践,架构设计模式,面向服务架构,SOA,软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。主流的标准观点有：,ANSI/IEEE 610.12-1990,软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理,(principle)”,。,Mary Shaw,和,David Garlan,认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进行选择。,Garlan&Shaw,模型,1,的基本思想是：软件体系结构,=,构件,(component),、连接件,(connector),和约束,(constrain),。其中构件可以是一组代码，如程序的模块；也可以是一个独立的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用,(RPC),等，用于表示构件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。,Bass,定义、,Booch&Rumbaugh&Jacobson,定义、,Perry&Wolf,模型,7,、,Boehm,模型等，虽然各种定义关键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以,Garlan&Shaw,模型为代表，强调了体系结构的基本要素是构件、连接件及其约束（或者连接语义），这些定义大部分是从构造的角度来甚至软件体系结构，而,IEEE,的定义不仅强调了系统的基本组成，同时强调了体系结构的环境即和外界的交互。,什么是架构,?,4,框架，即,framework,。是某种应用的半成品，是一组组件，供用户选用完成自己的系统。,简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软,件。框架一般处在低层应用平台（如,J2EE,）和高层业务逻辑之间的中间层。,因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问,题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只,需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统,很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多,人使用，所以结构很好，扩展性也很好，而且它是不断升级的，你可以直接享受别人升级,代码带来的好处。,架构与框架的区别与联系如下：,1,呈现形式不同架构的呈现形式是一个设计规约，而框架则是程序代码。,2,目的不同体系结构的目的是指导一个软件系统的实施与开发；而框架的目的是为复用。,因此，一个框架可有其架构，用于指导该框架的开发，反之不然。,3,有种特殊的架构，,DSSA,（领域特定体系结构）其目的也是为了复用。,4.,架构风格在其用程序代码实现后就成了,Corba,、,COM,架构框架，也叫中间件集成框架，,或对象中间件。,架构与框架,5,软件架构,这次培训的主关注点。,硬件架构,包括,CPU,内存，硬盘，周,边设备例如打印机，与连接这些元素的,部分。,组织架构,是一些关于商业进程，组,织结构，规则和职责，与组织核心能力,的部分。,信息架构,包含组织好的信息结构。,软件架构、硬件架构、组织架构和信,息架构是全部系统架构的子结构。,企业架构与系统架构很相似，包括硬件，软件，人员等。但是，企业架构与商业有很强的联系，因为它专注于商业对象的联系，专注于商业敏捷性和组织效率。企业架构可能穿插于公司间。,架构的范围,6,企业架构师,EA(Enterprise Architect),EA,的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的,Title,是首席软件,架构师，实际上就是,EA,角色。,基础结构架构师,IA(Infrastructure Architect),IA,的工作是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架,和组件，这些是技术型公司传承下来的最宝贵的财富。,特定技术架构师,TSA(Technology-Specific Architect),TSA,主要从事类似安全架构、存储架构等专项技术的规划和设计工作。,解决方案架构师,SA(Solution Architect),SA,的工作则专于解决方案的规划和设计，所谓解决方案，就是把产品、技术或理论，,不断地进行组合，来创造出满足用户需求的选择。,软件架构师基本上是,EA+TSA+IA,，是程序员向上发展的道路，比如,JAVA,架构师、,DotNet,架构师、,LAPM,架构师等等，系统架构师实际上是,SA+TSA,，更着力于综合运用已有的产品和技术，来实现客户期望的需求。,架构师分类,7,1,、,确认需求,在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。,2,、,系统分解,依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。这体现了软件架构师的功力。,3,、,技术选型,架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。例如：,Web Server,运行在,Windows,上还是,Linux,上？数据库采用,MSSql,、,Oracle,还是,Mysql,？是否需要采用,MVC,或者,Spring,等轻量级的框架？前端采用富客户端还是瘦客户端方式？架构师对产品和技术的选型只限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。,4,、,制定技术规格说明,架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。架构师通过它制定的技术规格说明书（,UML,视图、,Word,文档，,Visio,文件）与开发者沟通，保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。架构师还需要与项目经理、需求分析员，甚至与最终用户保持沟通。,架构师的,主要,职责,8,架构师的,全面,职责,架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调,。,领导与协调整个项目中的技术活动（分析、设计和实施等）,推动主要的技术决策，并最终表达为软件构架,确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、,设计、实施和部署等,“,视图,”,确定设计元素的分组以及这些主要分组之间的接口,为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并,保证相关决定被有效的传达和贯彻,理解、评价并接收系统需求,评价和确认软件架构的实现,9,从普通程序员到高级程序员，再到架构师，是一个经验积累和思想升华的过程，必须要有经验积累和素质培养。架构师要具备的素质有：,1,、发挥团队作用的沟通能力,为了提高效率，架构师必须赢得团队成员、项目经理、客户或用户认同，这就需要架构师具有较强的沟通能力。,2,、基于技术和知识的领导能力,架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底。架构师要保证这种执行力就需要具有领导能力。但架构师在项目里面可能更多地使用非正式的领导力，即影响力，包括个人魅力、技术能力、知识传递等等。,3,、抽象思维和逻辑分析能力,架构师必须具备抽象思维和逻辑分析的能力，才能看清系统的整体，掌控全局，形成大局观。架构师不仅要有在问题领域上的经验，也需要有在软件工程领域内的经验，这样才能准确的理解需求，用软件工程的思想，把需求转化和分解成可用计算机语言实现的程序。,4,、拥有深度和广度的技术和知识,架构师必须精通面向过程和面向对象的基本概念和实施途径，具备这种技术能力才可以更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响力。架构师的技术知识广度也很重要，这样才可能综合各种技术，选择更加适合项目的解决方案。,架构师应是项目团队中的技术权威。,架构师,的素质要求,10,它是一个软件系统从整体到部分的最高层次的划分。,一个系统通常是由,组,件组成的，而这些,组,件如何形成、相互之间如何发生作,用，则是关于这个系统本身结构的重要信息。,系统,包括架构,组,件（,Architecture Component,）、连接器（,Connector,）、任务流（,Task-flow,）。,架构组件是组成系统的核心,“,砖瓦,”,，而连接器则描述这些 组件之间通讯的路,径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些组件和,连接器完成某一项需求。,它是,建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的,决定。这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎,重的研究和考察。在决定时，要考虑独特的架构风格和恰当的架构模式。,软件系统架构,要素,11,软件,架构的目标,可靠性（,Reliable,）。软件系统对于用户的商业经营和管理来说极为重要，因,此软件系统必须非常可靠。,安全,性,（,Secure,）。软件系统所承担的交易的商业价值极高，系统的安全性非,常重要。,可扩展性（,Scalable,）。软件必须能够在用户的使用率、用户的数目增加很快,的情况下，保持合理的性能,，,才能适应用户的市场扩展得可能性。,可定制化（,Customizable,）。同样的一套软件，可以根据客户群的不同和市场,需求的变化进行调整。,可,延伸,性（,Extensible,）。在新技术出现的时候，一个软件系统应当允许导入,新技术，从而对现有系统进行功能和性能的扩展,可维护性（,Maintainable,）。软件系统的维护包括两方面,：,1,。,排除现有的错,误，,2,。,将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效,地降低技术支持的花费,客户体验（,Customer Experience,）。软件系统必须易于使用。,市场时机（,Time to Market,）。软件用户要面临同业竞争，软件提供商也要面,临同业竞争。以最快的速度争夺市场先机非常重要。,12,软件,架构的种类,软件系统的逻辑架构图,逻辑架构,：,软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等,13,软件,架构的种类,物理架构,：,软件元件是怎样放到硬件上的,软件系统的,物理,架构图,14,软件,架构的种类,系统架构,：,系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、,性能等。,系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，是架,构设计工作中最为困难的工作。,架构的两要素：元件划分和设计决定。,元件划分,一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以,及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等,做出贡献，是非常重要的信息。,设计决定,进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它,们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，,就很难更改的。,15,元件划分,一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。,设计决定,进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。,架构,设计,的要素,16,视图可以表示系统的整体设计，但构架,与,以下几个具体方面相关：,模型的结构，即组织模式，例如分层。,基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。,几,个关键场景，它们表示了整个系统的主要控制流程。,记录模块度、可选特征、产品线状况的服务。,构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突,出重要的特征。在考虑以下方面时，这些特征非常重要：,系统演进，即进入下一个开发周期。,在产品线环境下复用构架或构架的一部分。,评估补充质量，例如性能、可用性、可移植性和安全性。,向团队或分包商分配开发工作。,决定是否包括市售构件。,插入范围更广的系统。,构架重点,17,18,Agenda,软件架构导引,业务建模,&UML,需求分析,软件架构视图,架构设计实践,架构设计模式,面向服务架构,SOA,RUP,统一开发过程,19,业务建模,流程,20,评估业务状态,关键工件,获取常用业务词汇,业务前景,维护业务规则,目标组织评估,评估目标组织,业务建模指南,设定和调整目标,业务词汇表,制定业务建模指南,业务规则,说明当前业务,关键工件,评估目标组织,目标组织评估,找出业务主角和用例,业务用例模型,设定和调整目标,业务用例,找出业务角色和实体,补充业务说明,业务前景,业务对象模型,业务用例实现,确定业务流程,关键工件,维护业务规则,业务规则,设定和调整目标,业务前景,定义业务构架,业务构架文档,获取常用业务词汇,业务词汇表,找出业务主角和用例,业务用例模型,业务用例,补充业务说明,业务建模过程过程,21,完善业务流程,关键工件,详细说明业务用例,业务用例模型,审核业务用例模型,业务用例,调整业务用例模型的结构,补充业务说明,审核记录,设计业务流程的实现,关键工件,获取常用业务词汇,业务词汇表,找出业务角色和实体,业务对象模型,维护业务规则,业务用例实现,定义业务构架,业务规则,业务构架文档,完善角色和职责,关键工件,详细说明业务实体,业务角色,详细说明业务角色,业务实体,审核业务对象模型,组织单元,审核记录,业务建模过程过程,22,研究流程自动化,关键工件,设定和调整目标,业务前景,定义自动化需求,用例模型,分析模型,补充说明,开发领域模型,关键工件,维护业务规则,业务规则,获取常用业务词汇,业务词汇表,详细说明业务实体,业务对象模型,找出业务角色和实体,业务实体,审核业务对象模型,审核记录,业务前景,业务规则,业务前景,审核记录,用例模型,目标组织评估,业务用例模型,业务对象模型,业务角色,分析模型,业务建模指南,业务用例,业务用例实现,业务实体,补充说明,业务词汇表,补充业务说明,业务构架文档,组织单元,业务建模关键工件,业务建模过程过程,23,1,。,从涉众中找出用户。,并定义这些用户之间的关系。在,ROSE,中，应该使用,business actor,类型。,2,。找出每个用户要做的事，即业务用例，,在,ROSE,中应使用,Business use case,类型。请参考,用例的类型与粒度,有关文章以帮助确定用例的粒度。建议为每一个,business actor,绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉,business actor,需要做的事。而且在以参与者为中心的视图不要漏掉某个业务用例的参与者。,3,。利用业务场景图帮助分析业务流程，,在,ROSE,中，这个阶段最好,使用活动图,Activity diagram,。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的,用户名字作为泳道名,，使用第二步中定义的,业务用例名作 为活动名,来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的,business actor,和,business use case,完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否,business actor,和,business use case,定义不完善或错误。如果不是所有的,business actor,和,business use case,都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的,business actor,和,business use case,。同时，,绘制业务场景图,也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。,4,。绘制用例场景图。,与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。使用的是,activity diagram,。在,用例场景图,的绘制中，必须,使用,第一步中定义的,业务用户作为泳道,。必须这么做的原因是，它能帮助你,发现,在定义业务用例图时的错误，比如,是 否漏掉了某个业务用例的潜在使用者,。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。,业务建模一般步骤和方法,24,业务建模一般步骤和方法,5,。,从,3,或,4,中绘制的活动图中找到每一步活动将使用到的或产生的结果,。这是找到物的过程。找到后，应当建立这些物之间的关系。在,ROSE,中，这称为,业务实体模型,。应该使用,business entity,类型。,6,。,在上述过程中，随时补充词汇表,Glossary,。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。,7,。,根据业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内,。那些不打算纳入建设范 围内的业务用例有两种情况，一种是该业务用例是,被调用一方,，那么应该把它改为,boundary,类型，意味着将来它是一个,外部接口,。另一种是该业务用例,主动调用,系统内业务用例，那么应该将它改为,business actor,类型。与普通,business actor,不同的是，由,业务用例转换而成的,business actor,不是人,，而通常是一个,外部系统进程,，因此应该在被调用的系统内业务用例与它之间增加一个,boundary,元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的,business use case,应当对应的生成一个,business use case realization,，以后的设计工作将归纳到这些实现用例中。这一步并非很关键的，可将,协作图，象活动图，类交互图等直接在,business usecase,下说明,。,25,工作,发现和定义涉众,画定业务边界,获取用例,绘制用例场景图,绘制业务实体模型（领域模型）,编制词汇表,业务建模,要作的工作和涉众,涉众,业主,业主是系统建设的出资方，投资者，它不一定是业务方。,业务提出者,业务提出者是业务规则的制定者，一般是指业务方的高层人物，比如,CEO,，高级经理等。,业务管理者,业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。,业务执行者,业务执行者是指底层的操作人员，是与将来的计算机直接交互最多的人员。,第三方,第三方是指与这项业务而关联的，但并非业务方的其他人或事。,承建方,是老板。老板的期望也是非常重要的。,相关的法律法规,相关的法律法规是一个很重要的，但也最容易被忽视的涉众。,用户,用户是一个抽象的概念，是指预期的系统使用者。,26,27,1997,年，,OMG,组织（,Object Management Group,对象管理组织）发布了统一建模语言（,Unified Modeling Language,，,UML,）。,UML,的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。,UML,提出了一套,IT,专业人员期待多年的统 一的标准建模符号。通过使用,UML,，这些人员能够阅读和交流系统架构和设计规划,。,UML,的主要创始人是,Jim Rumbaugh,、,Ivar Jacobson,和,Grady Booch,，他们最初都有自己的建模方法（,OMT,、,OOSE,和,Booch,），彼此之间存在着竞争。最终，他们联合起来创造了一种开放的标准。,UML,成为,“,标准,”,建模语言,是它,与程序设计语言无关，,UML,符号集只是一种语言而不是一种方法学。它可以在不做任何更改的情况下很容易地适应任何公司的业务运作方式。,UML,不是一种方法学，它就不需要任何正式的工作产品,，,它提供了多种类型的模型描述图（,diagram,），使得开发中的应用程序更易理解。最常用的,UML,图包括：用例图、类图、序列图、状态图、活动图、组 件图和部署图。,UML,简介,28,用例图描述了系统提供的一,个,功能单元,。,它,的主要目的,是帮助开发团队以一种可视,化的方式理解系统的功能需,求，包括基于基本流程的,角色,（,actors,，也就是与,系统交互的其他实体）关系，,以及系统内用例之间的关系。,用例图一般表示出用例的组,织关系,-,要么是整个系统的,全部用例，要么是完 成具有,功能（例如，所有安全管理,相关的用例）的一组用例。,要在用例图上显示某个用例，,可绘制一个,椭圆,，然后将用,例的名称放在椭圆的中心或,椭圆下面的中间位 置。要在用例图上绘制一个角色（表示一个系统用户），可绘制一个,人形符号,。角色和用例之间的关系使用简单的,线段,来描述，如,上,图所示。,用例图,29,类 图表示不同的实体（人、事物和数据）如何彼此相关；,它显示了,系统的静态结构,。类图可用于表示,逻辑类,，逻辑,类通常就是业务人员所谈及的,事物种类,。类图还可用于表,示,实现类,，实现类就是程序员,处理的实体,。实现类图或许,会与逻辑类图显示一些相同的类。然而，实现类图不会使,用相同的属性来描述，因为它很可能具有对诸如,Vector,和,HashMap,这种事物的引用。,类在类图上使用包含三个部,分的矩形来描述，如,右上,图,所示。最上面的部分显示,类,的名称,，中间部分包含,类的,属性,，最下面的部分包含,类,的操作,（或者说,方法,）。,在右下,图这样的类图,中,使用带有,三角形顶点,指向父,类的箭头的线段来绘制,继承,关系,。如果两个类都彼此知道对方，则使用,实线,来表示关联关系；如果只有其中一个类知道该关联关系，则使用,开箭头,表示。在,上,图中，,可,看到继承关系和两个关联关系。,CDSalesReport,类继承自,Report,类。一个,CDSalesReport,类与一个,CD,类关联，但是,CD,类并不知道关于,CDSalesReport,类的任何信息。,CD,类和,Band,类都彼此知道对方，两个类彼此都可以与一个或者多个对方类相关联。一个类图可以整合其他许多概念,。,类图,30,序列图显示具体用例（或者是用,例的一部分）的详细,流程,。它几,乎是自描述的，并且显示了流程,中不同对象之间的调用关系，同,时还可以很详细地显示,对不同对,象的不同调用,。,序列图有两个维度：垂直维度以,发生的,时间顺序,显示消息,/,调用的,序列；水平维度显示,消息被发送,到的对象实例,。,序列图的绘制非常简单。横跨图,的顶部，每个框（见,右,图）表示,每个类的实例（对象）。在框中，,类实例名称和类名称之间用空格,/,冒号,/,空格来分隔，例如，,myReportGenerator,:,ReportGenerator,。如果某个类实例向另一个类实例发送一条消息，则绘制一条具有指向接收类实例的开箭头的连线，并把消息,/,方法的名称放在连 线上面。对于某些特别重要的消息，您可以绘制一条具有指向发起类实例的开箭头的虚线，将返回值标注在虚线上。绘制出包括返回值的虚线，可以使得序列图更易于阅读。,阅读序列图,是,从左上角启动序列的,“,驱动,”,类实例开始，然后顺着每条消息往下阅读。,序列图,31,状态图表示某个类所处的不同,状态和该类的状态转换信息。,每个类都有状态，但不是每个,类都应该有一个状态图。只对,“,感兴趣的,”,状态的类（在系统,活动期间具有三个或更多潜在,状态的类）才进行状态图描述。,状态图的符号集包括,5,个基本,元素,：初始起点使用,实心圆,来,绘制；状态之间的转换使用具,有,开箭头的线段,来绘制；状态,使用,圆角矩形,来绘 制；判断点,使用,空心圆,来绘制；一个或者多个终止点使用内部,包含实心圆的圆,来绘制。要绘制状态图，首先绘制起点和一条指向该类的初始状态的转换线段。状态本身可以在图上的任意位置绘制，然后只需使用状态转换线条将它们连接起来。从,上图,中可以看出贷款处理系统最初处于,Loan Application,状态。当批准前（,pre-approval,）过程完成时，根据该过程的结果，或者转到,Loan Pre-approved,状态，或者转到,Loan Rejected,状态。这个判断（它是在转换过程期间做出的）使用一个判断点来表示,-,即转换线条间的空心圆。通过该状态图可知，如果没有经过,Loan Closing,状态，贷款不可能从,Loan Pre-Approved,状态进入,Loan in Maintenance,状态。而且，所有贷款都将结束于,Loan Rejected,或者,Loan in Maintenance,状态。,状态图,32,活动图表示在处理某个活动时，两个或者更多类对象之间的,过程控制流,。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等。这是因为与序列图相比，活动图在表 示上,“,不够技术性的,”,。,活动图的符号集与状态图中使用的符号集类似。像状态图一样，活动图也从一个连接到初始活动的,实心圆,开始。活动是通过一个,圆角矩形,（活动的名称包含在其内）来表示的。活动可以通过,转换线段,连接到其他活动，或者连接到,判断点,，这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一个,终止点,（就像在状态图中一样）。作为一种选择，活动可以分组为泳道（,swimlane,），泳道用于表示实际执行活动的对象,。,活动图,33,组件图提供系统的,物理视图,。它的用途是显示系统中的,软件对其他软件组件（例如，库函数）的依赖关系,。组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次,2,上显示。,组件图的建模最适合通过例子来描述。,下,图显示了,4,个组件：,Reporting Tool,、,Billboard Service,、,Servlet 2.2 API,和,JDBC API,。从,Reporting Tool,组件指向,Billboard Service,、,Servlet 2.2 API,和,JDBC API,组件的带箭头的线段，表示,Reporting Tool,依赖于那三个组件。,组件图,34,部署图表示该,软件系统如何部署到硬件环境中,。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模，,系统的生产人员就可以很好地利用这种图,。,部署图中的符号包括组件图中所使用的符号元素，另外还增加,节点,的概念。一个节点可以代表一台物理机器，或代表一个虚拟机器节点（例如，一个 大型机节点）。要对节点进行建模，只需绘制一个,三维立方体,，节点的名称位于立方体的顶部。所使用的命名约定与序列图中相同：,实例名称,:,实例类型,（例如，,:Application Server,）。,部署图,用户使用运行在本地机器上的浏览器访问,Reporting Tool,，并通过公司,intranet,上运行在名为,的,Application Server,上的,HTTP,协议连接到,Reporting Tool,组件。,Reporting Tool,组件绘制在,IBM WebSphere,内部，后者又绘制在,节点内部。,Reporting Tool,使用,Java,语言通过,IBM DB2,数据库的,JDBC,接口连接到它的报告数据库上，然后该接口又使用本地,DB2,通信方式，与运行在名为,的服务器上实际的,DB2,数据库通信。,Report Tool,组件还通过,HTTPS,上的,SOAP,与,Billboard Service,进行通信。,1,。,从涉众中找出用户。,2,。,找出每个用户要做的事，即业务用例,业务建模,实例,35,业务视,图,3,。,针对每项业务视图绘制业务场景图,业务建模,实例,36,嵌入,GRC,的业务建模实例,37,38,Agenda,软件架构导引,业务建模,&UML,需求分析,软件架构视图,架构设计实践,架构设计模式,面向服务架构,SOA,39,需求流程,分析问题,关键工件,获取常用词汇,词汇表,确定前景,前景,找出主角和用例,用例模型,制定需求管理计划,管理需求计划,理解涉众需要,关键工件,获取常用词汇,词汇表,确定前景,前景,获取涉众请求,涉众请求,找出主角和用例,用例模型,管理需求依赖关系,补充说明,审核变更请求,定义系统,关键工件,确定前景,词汇表,获取常用词汇,用例模型,找出主角和用例,补充说明,管理需求依赖关系,40,41,限定系统范围,关键工件,确定前景,软件构架文档,管理需求依赖关系,确定用例的优先级,审核变更请求,完善系统定义,关键工件,详细说明用例,补充说明,详细说明软件需求,用例,用户界面建模,软件需求说明,设计用户界面原型,用例场景示意,用户界面原型,管理需求变更,关键工件,管理需求依赖关系,需求管理计划,审核变更请求,软件需求说明,审核需求,补充说明,调整用例模型的结构,用例模型,词汇表,涉众请求,用例,需求管理计划,前景,用例模型,软件需求说明,用例模型,补充说明,用例场景示意,管理需求计划,软件构架文档,用户界面原型,需求关键工件,：,42,分析设计流程,定义备选构架,关键工件,制定设计指南,软件构架文档,确定用例的优先级,用例实现,构架分析,分析模型,用例分析,参考构架,提交变更请求,部署模型,完善构架,关键工件,确定用例的优先级,软件构架文档,说明运行时构架,设计类,说明分布,设计模型,确定设计机制,设计包,确定设计元素,设计子系统,整合现有设计元素,接口,审核构架,建立实施模型,分析行为,关键工件,用例分析,设计类,确定设计元素,设计模型,制定系统集成计划,设计包,审核设计,设计子系统,接口,工作版本整合计划,分析模型,用例实现,43,设计构件,关键工件,类的设计,构件,子系统设计,设计子系统,用例设计,接口,审核上述设计,用例实现,实施构件,测试构件,单元测试,设计实时构件,关键工件,类的设计,设计类,封装体设计,封装体,子系统设计,协议,用例设计,构件,审核上述设计,设计子系统,实施构件,接口,单元测试,用例实现,测试构件,设计数据库,关键工件,类的设计,设计类,数据库设计,数据模型,审核上述设计,构件,实施构件,44,I E E E,软件工程标准词汇表（,1 9 9 7,年）中定义需求为：,（,1,）,用户解决问题或达到目标,所需的,条件或权能,（,C a p a b i l i t y,）。,（,2,）,系统或系统部件要满足,合同、标准、规范或其它正式规定文档所需具有的,条件或权能,。,（,3,）一种反映上面（,1,）或（,2,）所描述的条件或权能的,文档说明,。,软件需求包括三个不同的层次,：,业务需求,（,business requirement,）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。,用户需求,(user requirement),文档描述了用户使用产品必须要完成的任务，这在使用实例（,use case,）文档或方案脚本（,s c e n a r i o,）说明中予以说明。,功能需求,(functional requirement),定义了开发人员必须实现的软件功能也包括非功能需求，使得用户能完成他们的任务，从而满足了业务需求。所谓特性,(f e a t u r e),是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。,软件需求的定义和层次,45,方法,1,、,会谈、询问：围绕软件目标提出具体问题；,2,、,调查表：经过仔细考虑的书面回答可能比会谈中的回答更加准确；,3,、,收集分析客户使用的各种表格、有关工作责任、工作流程、工作规范、相关数据标准、,业务标准的各种文字资料；,4,、,收集同类相关产品的宣传资料、技术资料、演示程序或软件程序；,5,、,情景分析：利用情景分析诱导用户能够把它们的需求告知分析员（可以描述当前一项,业务怎么做、也可以描