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

软件架构设计与模式薛君敖博士JunaoXuePh.D2009年12月9-11日12讲师介绍81年赴美，美国哥伦比亚大学电脑科学硕士、物理学博士。85-87在美国芝加哥AT/TBellLaboratory工作期间，参与编编写写5ESS（超大型交（超大型交换换机）机）DatabaseRetrofit的数据的数据库库架构架构层层面的面的设计设计和和实实施方案施方案，包括：设计和管理安全的数据库架构，设计和管理高可用性解决方案，优化和实施数据库的数据恢复计划，设计、部署和巩固数据库架构。88-94在美国新泽西州AT/TBellLaboratory工作期间，是DACS（大型传输交换连接设备）的Architect组成员，为DACS的的逻辑逻辑架构、物理架构和系架构、物理架构和系统统架构架构设计设计提供解决方案提供解决方案，并主持DACS的FSTS（工厂测试系统）系统设计，从硬件基础设施、技术平台、应用平台到应用的设计和实施。之后参与编编写写SDH和和DWDM两大光通两大光通讯讯网网络络的网管系的网管系统统（INMS）的）的逻辑逻辑/物理物理/系系统统架构架构设计设计方方案案。94-02LucentTechnologiesBellLabsInnovations在任朗讯科技贝尔实验室网管技术支持小组组长兼任原邮电部网管专家顾问期间，为北京，上海，深圳，武汉，南昌等地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（最有价值专家）（最有价值专家）3Agenda软件架构导引软件架构导引业务建模业务建模&UML需求分析需求分析软件架构视图软件架构视图架构设计实践架构设计实践架构设计模式架构设计模式面向服务架构面向服务架构SOA软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。主流的标准观点有：ANSI/IEEE610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”。MaryShaw和DavidGarlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进行选择。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(EnterpriseArchitect)EA的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title是首席软件架构师，实际上就是EA角色。基础结构架构师IA(InfrastructureArchitect)IA的工作是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些是技术型公司传承下来的最宝贵的财富。特定技术架构师TSA(Technology-SpecificArchitect)TSA主要从事类似安全架构、存储架构等专项技术的规划和设计工作。解决方案架构师SA(SolutionArchitect)SA的工作则专于解决方案的规划和设计，所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。软件架构师基本上是EA+TSA+IA，是程序员向上发展的道路，比如JAVA架构师、DotNet架构师、LAPM架构师等等，系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。架构师分类71、确认需求确认需求在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。2、系系统统分解分解依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。这体现了软件架构师的功力。3、技技术选术选型型架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。例如：WebServer运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？是否需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？架构师对产品和技术的选型只限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。4、制定技制定技术规术规格格说说明明架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。架构师通过它制定的技术规格说明书（UML视图、Word文档，Visio文件）与开发者沟通，保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。架构师还需要与项目经理、需求分析员，甚至与最终用户保持沟通。架构师的主要职责8架构师的全面职责架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。领导与协调整个项目中的技术活动（分析、设计和实施等）推动主要的技术决策，并最终表达为软件构架确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”确定设计元素的分组以及这些主要分组之间的接口为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻理解、评价并接收系统需求评价和确认软件架构的实现9从普通程序员到高级程序员，再到架构师，是一个经验积累和思想升华的过程，必须要有经验积累和素质培养。架构师要具备的素质有：1、发挥团队发挥团队作用的沟通能力作用的沟通能力为了提高效率，架构师必须赢得团队成员、项目经理、客户或用户认同，这就需要架构师具有较强的沟通能力。2、基于技、基于技术术和知和知识识的的领导领导能力能力架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底。架构师要保证这种执行力就需要具有领导能力。但架构师在项目里面可能更多地使用非正式的领导力，即影响力，包括个人魅力、技术能力、知识传递等等。3、抽象思、抽象思维维和和逻辑逻辑分析能力分析能力架构师必须具备抽象思维和逻辑分析的能力，才能看清系统的整体，掌控全局，形成大局观。架构师不仅要有在问题领域上的经验，也需要有在软件工程领域内的经验，这样才能准确的理解需求，用软件工程的思想，把需求转化和分解成可用计算机语言实现的程序。4、拥拥有深度和广度的技有深度和广度的技术术和知和知识识架构师必须精通面向过程和面向对象的基本概念和实施途径，具备这种技术能力才可以更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响力。架构师的技术知识广度也很重要，这样才可能综合各种技术，选择更加适合项目的解决方案。架构架构师应师应是是项项目目团队团队中的技中的技术权术权威。威。架构师的素质要求10它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由组件组成的，而这些组件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。系统包括架构组件（ArchitectureComponent）、连接器（Connector）、任务流（Task-flow）。架构组件是组成系统的核心“砖瓦”，而连接器则描述这些组件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些组件和连接器完成某一项需求。它是建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。在决定时，要考虑独特的架构风格和恰当的架构模式。软件系统架构要素11软件软件架构的目标架构的目标可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能，才能适应用户的市场扩展得可能性。可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。可延伸性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展可维护性（Maintainable）。软件系统的维护包括两方面：1。排除现有的错误，2。将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费客户体验（CustomerExperience）。软件系统必须易于使用。市场时机（TimetoMarket）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。12软件软件架构的种类架构的种类软件系统的逻辑架构图逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等13软件软件架构的种类架构的种类物理架构：软件元件是怎样放到硬件上的软件系统的物理架构图14软件软件架构的种类架构的种类系统架构系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，是架构设计工作中最为困难的工作。架构的两要素：元件划分和设计决定。元件划分元件划分一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。设计决定设计决定进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。15元件划分元件划分一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。设计决定设计决定进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。架构设计的要素16视图可以表示系统的整体设计，但构架与以下几个具体方面相关：模型的结构，即组织模式，例如分层。基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要：系统演进，即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量，例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。构架重点1718Agenda软件架构导引软件架构导引业务建模业务建模&UML需求分析需求分析软件架构视图软件架构视图架构设计实践架构设计实践架构设计模式架构设计模式面向服务架构面向服务架构SOARUP统一开发过程19业务建模流程20评估业务状态评估业务状态关键工件关键工件获取常用业务词汇业务前景维护业务规则目标组织评估评估目标组织业务建模指南设定和调整目标业务词汇表制定业务建模指南业务规则说明当前业务说明当前业务关键工件关键工件评估目标组织目标组织评估找出业务主角和用例业务用例模型设定和调整目标业务用例找出业务角色和实体补充业务说明业务前景业务对象模型业务用例实现确定业务流程确定业务流程关键工件关键工件维护业务规则业务规则设定和调整目标业务前景定义业务构架业务构架文档获取常用业务词汇业务词汇表找出业务主角和用例业务用例模型业务用例补充业务说明业务建模过程过程21完善业务流程完善业务流程关键工件关键工件详细说明业务用例业务用例模型审核业务用例模型业务用例调整业务用例模型的结构补充业务说明审核记录设计业务流程的实现设计业务流程的实现关键工件关键工件获取常用业务词汇业务词汇表找出业务角色和实体业务对象模型维护业务规则业务用例实现定义业务构架业务规则业务构架文档完善角色和职责完善角色和职责关键工件关键工件详细说明业务实体业务角色详细说明业务角色业务实体审核业务对象模型组织单元审核记录业务建模过程过程22研究流程自动化研究流程自动化关键工件关键工件设定和调整目标业务前景定义自动化需求用例模型分析模型补充说明开发领域模型开发领域模型关键工件关键工件维护业务规则业务规则获取常用业务词汇业务词汇表详细说明业务实体业务对象模型找出业务角色和实体业务实体审核业务对象模型审核记录业务前景业务规则业务前景审核记录用例模型目标组织评估业务用例模型业务对象模型业务角色分析模型业务建模指南业务用例业务用例实现业务实体补充说明业务词汇表补充业务说明业务构架文档组织单元业务建模关键工件业务建模过程过程231。从涉众中找出用户。从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用businessactor类型。2。找出每个用户要做的事，即业务用例，。找出每个用户要做的事，即业务用例，在ROSE中应使用Businessusecase类型。请参考用例的类型与粒度有关文章以帮助确定用例的粒度。建议为每一个businessactor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉businessactor需要做的事。而且在以参与者为中心的视图不要漏掉某个业务用例的参与者。3。利用业务场景图帮助分析业务流程，。利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图使用活动图Activitydiagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名用户名字作为泳道名，使用第二步中定义的业务用例名作业务用例名作为活动名为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的businessactor和businessusecase完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否businessactor和businessusecase定义不完善或错误。如果不是所有的businessactor和businessusecase都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的businessactor和businessusecase。同时，绘制业务场景图绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。4。绘制用例场景图。绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。使用的是activitydiagram。在用例场景图用例场景图的绘制中，必须使用使用第一步中定义的业务业务用户作为泳道用户作为泳道。必须这么做的原因是，它能帮助你发现发现在定义业务用例图时的错误，比如是是否漏掉了某个业务用例的潜在使用者否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。业务建模一般步骤和方法24业务建模一般步骤和方法5。从从3或或4中绘制的活动图中找到每一步活动将使用到的或产生的结果中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型业务实体模型。应该使用businessentity类型。6。在上述过程中，随时补充词汇表在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。7。根据业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系根据业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被被调用一方调用一方，那么应该把它改为boundary类型，意味着将来它是一个外部接口外部接口。另一种是该业务用例主动调用主动调用系统内业务用例，那么应该将它改为business actor类型。与普通businessactor不同的是，由业务用例转换而成的业务用例转换而成的business actor不是人不是人，而通常是一个外部外部系统进程系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的businessusecase应当对应的生成一个businessusecaserealization，以后的设计工作将归纳到这些实现用例中。这一步并非很关键的，可将协作图，象活动图，类交互图等直接在协作图，象活动图，类交互图等直接在 business usecase下说明下说明。25工作工作发现和定义涉众画定业务边界获取用例绘制用例场景图绘制业务实体模型（领域模型）编制词汇表业务建模要作的工作和涉众涉众涉众业业主主业主是系统建设的出资方，投资者，它不一定是业务方。业务提出者业务提出者 业务提出者是业务规则的制定者，一般是指业务方的高层人物，比如CEO，高级经理等。业务管理者业务管理者 业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。业务执行者业务执行者 业务执行者是指底层的操作人员，是与将来的计算机直接交互最多的人员。第三方第三方第三方是指与这项业务而关联的，但并非业务方的其他人或事。承建方承建方是老板。老板的期望也是非常重要的。相关的法律法规相关的法律法规相关的法律法规是一个很重要的，但也最容易被忽视的涉众。用户用户用户是一个抽象的概念，是指预期的系统使用者。26271997年，OMG组织（ObjectManagementGroup对象管理组织）发布了统一建模语言（UnifiedModelingLanguage，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划。UML的主要创始人是JimRumbaugh、IvarJacobson和GradyBooch，他们最初都有自己的建模方法（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个基本个基本元素元素：初始起点使用实心圆实心圆来绘制；状态之间的转换使用具有开箭头的线段开箭头的线段来绘制；状态使用圆角矩形圆角矩形来绘制；判断点使用空心圆空心圆来绘制；一个或者多个终止点使用内部包含实心圆的圆包含实心圆的圆来绘制。要绘制状态图，首先绘制起点和一条指向该类的初始状态的转换线段。状态本身可以在图上的任意位置绘制，然后只需使用状态转换线条将它们连接起来。从上图中可以看出贷款处理系统最初处于LoanApplication状态。当批准前（pre-approval）过程完成时，根据该过程的结果，或者转到LoanPre-approved状态，或者转到LoanRejected状态。这个判断（它是在转换过程期间做出的）使用一个判断点来表示-即转换线条间的空心圆。通过该状态图可知，如果没有经过LoanClosing状态，贷款不可能从LoanPre-Approved状态进入LoaninMaintenance状态。而且，所有贷款都将结束于LoanRejected或者LoaninMaintenance状态。状态图32活动图表示在处理某个活动时，两个或者更多类对象之间的过程控制流过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等。这是因为与序列图相比，活动图在表示上“不够技术性的”。活动图的符号集与状态图中使用的符号集类似。像状态图一样，活动图也从一个连接到初始活动的实心圆实心圆开始。活动是通过一个圆角矩形圆角矩形（活动的名称包含在其内）来表示的。活动可以通过转换转换线段线段连接到其他活动，或者连接到判断判断点点，这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一个终止点终止点（就像在状态图中一样）。作为一种选择，活动可以分组为泳道（swimlane），泳道用于表示实际执行活动的对象。活动图33组件图提供系统的物理视图物理视图。它的用途是显示系统中的软件对其他软件软件对其他软件组件（例如，库函数）的依赖关系组件（例如，库函数）的依赖关系。组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次2上显示。组件图的建模最适合通过例子来描述。下图显示了4个组件：ReportingTool、BillboardService、Servlet2.2API和JDBCAPI。从ReportingTool组件指向BillboardService、Servlet2.2API和JDBCAPI组件的带箭头的线段，表示ReportingTool依赖于那三个组件。组件图34部署图表示该软件系统如何部署到硬件环境中软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模，系统的生产人员就系统的生产人员就可以很好地利用这种图可以很好地利用这种图。部署图中的符号包括组件图中所使用的符号元素，另外还增加节点节点的概念。一个节点可以代表一台物理机器，或代表一个虚拟机器节点（例如，一个大型机节点）。要对节点进行建模，只需绘制一个三维立方体三维立方体，节点的名称位于立方体的顶部。所使用的命名约定与序列图中相同：实例名称:实例类型（例如，:ApplicationServer）。部署图用户使用运行在本地机器上的浏览器访问ReportingTool，并通过公司intranet上运行在名为的ApplicationServer上的HTTP协议连接到ReportingTool组件。ReportingTool组件绘制在IBMWebSphere内部，后者又绘制在节点内部。ReportingTool使用Java语言通过IBMDB2数据库的JDBC接口连接到它的报告数据库上，然后该接口又使用本地DB2通信方式，与运行在名为的服务器上实际的DB2数据库通信。ReportTool组件还通过HTTPS上的SOAP与BillboardService进行通信。1。从涉众中找出用户。2。找出每个用户要做的事，即业务用例业务建模实例35业务视图3。针对每项业务视图绘制业务场景图业务建模实例36嵌入GRC的业务建模实例3738Agenda软件架构导引软件架构导引业务建模业务建模&UML需求分析需求分析软件架构视图软件架构视图架构设计实践架构设计实践架构设计模式架构设计模式面向服务架构面向服务架构SOA39需求流程分析问题分析问题关键工件关键工件获取常用词汇词汇表确定前景前景找出主角和用例用例模型制定需求管理计划管理需求计划理解涉众需要理解涉众需要关键工件关键工件获取常用词汇词汇表确定前景前景获取涉众请求涉众请求找出主角和用例用例模型管理需求依赖关系补充说明审核变更请求定义系统定义系统关键工件关键工件确定前景词汇表获取常用词汇用例模型找出主角和用例补充说明管理需求依赖关系4041限定系统范围限定系统范围关键工件关键工件确定前景软件构架文档管理需求依赖关系确定用例的优先级审核变更请求完善系统定义完善系统定义关键工件关键工件详细说明用例补充说明详细说明软件需求用例用户界面建模软件需求说明设计用户界面原型用例场景示意用户界面原型管理需求变更管理需求变更关键工件关键工件管理需求依赖关系需求管理计划审核变更请求软件需求说明审核需求补充说明调整用例模型的结构用例模型词汇表涉众请求用例需求管理计划前景用例模型软件需求说明用例模型补充说明用例场景示意管理需求计划软件构架文档用户界面原型需求关键工件需求关键工件：42分析设计流程定义备选构架定义备选构架关键工件关键工件制定设计指南软件构架文档确定用例的优先级用例实现构架分析分析模型用例分析参考构架提交变更请求部署模型完善构架完善构架关键工件关键工件确定用例的优先级软件构架文档说明运行时构架设计类说明分布设计模型确定设计机制设计包确定设计元素设计子系统整合现有设计元素接口审核构架建立实施模型分析行为分析行为关键工件关键工件用例分析设计类确定设计元素设计模型制定系统集成计划设计包审核设计设计子系统接口工作版本整合计划分析模型用例实现43设计构件设计构件关键工件关键工件类的设计构件子系统设计设计子系统用例设计接口审核上述设计用例实现实施构件测试构件单元测试设计实时构件设计实时构件关键工件关键工件类的设计设计类封装体设计封装体子系统设计协议用例设计构件审核上述设计设计子系统实施构件接口单元测试用例实现测试构件设计数据库设计数据库关键工件关键工件类的设计设计类数据库设计数据模型审核上述设计构件实施构件44IEEE软件工程标准词汇表（1997年）中定义需求为：（1）用户解决问题或达到目标用户解决问题或达到目标所需的条件或权能条件或权能（Capability）。（2）系统或系统部件要满足系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能条件或权能。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明文档说明。软件需求包括三个不同的层次：业务需求业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本（scenario）说明中予以说明。功能需求功能需求(functionalrequirement)定义了开发人员必须实现的软件功能也包括非功能需求，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求的定义和层次45方法方法1、会谈、询问：围绕软件目标提出具体问题；2、调查表：经过仔细考虑的书面回答可能比会谈中的回答更加准确；3、收集分析客户使用的各种表格、有关工作责任、工作流程、工作规范、相关数据标准、业务标准的各种文字资料；4、收集同类相关产品的宣传资料、技术资料、演示程序或软件程序；5、情景分析：利用情景分析诱导用户能够把它们的需求告知分析员（可以描述当前一项业务怎么做、也可以描述设想的系统中此项业务怎么做）；6、可视化方法：结和情景分析，利用画用户界面图、业务流程图、功能结构图、时序图等图形与客户进行讨论。策略策略1、首先确定用户的软件开发目标，确定系统基本范围确定系统基本范围，然后围绕这一目标，确定要访问的部门和人员，要了解的业务，在基本范围内展开调研；2、以部门职责为基础搞清各种现有业务、要填写的表簿册文档报表等，其数据来源及去数据来源及去 向向；3、以业务为主线以业务为主线，搞清每个业务的每个环节的流程关系、涉及部门、输入输出项；4、以数据为主线以数据为主线，搞清数据采集方式、数据流向、数据之间的内在联系；5、搞清哪些业务或数据是已建系统的，它们和新系统的关系是衔接还是替换是衔接还是替换；6、应思考是否有新技术可以改进现有工作，用户提出的需求用现有技术能否实现现有技术能否实现。需求调研方法和策略46需求工程和需求分析47软件需求各个部分之间的关系48(1)获得当前系统的物理模型获得当前系统的物理模型：首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、