软件体系结构SoftwareArchitecture.ppt

《软件体系结构SoftwareArchitecture.ppt》由会员分享，可在线阅读，更多相关《软件体系结构SoftwareArchitecture.ppt（137页珍藏版）》请在三一文库上搜索。

1、软件体系结构 (Software Architecture),讲义13：统一软件开发过程（RUP）,一、引言,为屏蔽计算机硬件的异构性，发展了操作系统,C/C+ 语言,Java 语言,支撑软件中间件,为屏蔽操作系统和编程语言的异构性，发展了支撑软件和中间件,Fortran 语言,为了祢补应用软件与现实计算环境之间的距离,应用系统,网 络 层,综观 软件技术 的发展,应用系统,概念不同，逻辑不同。 解决问题的思维逻辑 不同。 -“距离”,语 言,网络 异构,VB、VC -程序设计环境,中间件技术与产品,面向领域的软件体系结构,应用框架,领域软件生产线,系统建模,运行平台,开发平台,软件工程学科所

2、要解决的问题,软件开发的本质 可概括为： 第一点： 问题空间的概念 与 解空间的模型化概念 之间的映射 例如：对象 = F（张山） （模型化概念） （问题空间的概念） 其中， 对应的过程：需求分析 使用的技术：面向对象 使用的原理：数据抽象 目的：作为计算的客体。,第二点：问题空间的处理逻辑 与 解空间处理逻辑 之间的映射 例如1： 加工1（及相关的数据流）=F（计算学生成绩） 其中：使用的方法：结构化方法； 对应的过程：需求分析 使用的原理：过程抽象,加工1 计算学生平均成绩,科目+年级/班,学生成绩文件,学生平均成绩,规约后的处理逻辑,例如2： 交互图1=H（计算学生成绩） 其中：对应的过

3、程：需求分析 使用的方法：面向对象 使用的原理：行为结构抽象（简称行为抽象） 作用：作为计算规则,：教务员,：教员,递交A科学生成绩表,A科学生成绩表,：教学主任,求A科平均,A科平均,由于以上两个映射是由“人”完成的，因此 就软件开发而言，需要解决两个方面的问题： 1：技术 2：管理 进一步说，技术问题主要是指软件开发过程通常需 要遵循的途径和方向 其中，过程方向 确定用于创建问题模型和设计解的 特定的抽象层次 例如，需求、设计、实现、部署等,问题空间,需求-一个抽象层,设计-一个抽象层,实现-一个抽象层,部署-一个抽象层,特定的notation,特定的notation,特定的notatio

4、n,特定的notation,验 证/ 确 认,问题空间,需求-一个抽象层,设计-一个抽象层,实现-一个抽象层,部署-一个抽象层,特定的notation,特定的notation,特定的notation,特定的notation,验 证/ 确 认,它们体现了我们所说的一些软件设计原理,过程途径 实现不同抽象层次的映射,？,？,？,？,？,？,？,？,典型的途径有： 结构化方法 面向数据结构方法 面向对象方法以及 维也纳开发方法（VDM）等 注：主要讲解结构化方法和面向对象方法。,RUP的本质及特点 (1) 是一种迭代的、以架构为中心的、用例驱动的软件开发方法 (2) 是一种具有明确定义和结构的软件工

5、程过程，包括规定了人员的职责、如何完成各项工作以及何时完成各项工作。还提供了软件开发生命周期的结构，明确定义了主要里程碑和决策的关系 (3) 是一个过程产品，提供了可定制的软件工程的过程框架。可以适用于于不同规模的开发团队和规范程度不同的开发方法,RUP的基本原理 尽早并且不断化解重大的风险 确保满足客户的需求 把注意力放到可执行软件上 尽早在项目中适应变化 在早期确定一个可执行的架构 使用构件构造系统 建立高效的开发团队,突出特点是： Use Case 驱动的、 以体系结构为中心的、 迭代、增量的开发 ., 何谓 USE CASE 驱动,USE CASE,分 析,输入,设 计,实 现,跟踪,

6、输入,跟踪,输入,跟踪,输入,输入,测 试,输入,跟踪,输入,从USE CASE模型的视觉,从分析模型的视觉,从设计模型的视觉,从实现模型的视觉,从部署模型的视觉,给 出,体 系 结 构,描 述, 何谓以体系结构为中心,阶 段,核心工作流, 何谓迭代、增量的开发,初始阶段（the inception phase）的基本目标是： -了解项目的范围 -建立业务模型 -得到涉众的认可 换言之，其目标是：建立该项目的生存周期目标 （objectives）, 精化阶段（ the elaboration phase）的基本目标是 -建立体系结构基线 -捕获大多数的需求 -降低主要的技术风险 -减少次要的错

7、误风险，即建立生存周期体系结构 （ the life cycle architecture）. 到该阶段末，就能够估算成本、进度，并能详细地 规划构造阶段（ the construction phase）。,构造阶段（ the construction phase）的基本目标是： -开发完整的系统 -确保产品可以开始向客户交付, 即具有初始操作能力。 交付阶段（ the transition phase）的基本目标是： -确保有一个实在的产品，发布给用户群。 期间，培训用户如何使用该软件。 注：这4个阶段是演化模型的一个变体。,由上可见：USDP对于如何运用UML的概念进行软件开发提供了详细指

8、导。即： 指导开发队伍安排其开发活动的次序； 为各开发者和整个开发组指定任务； 明确地规定需要开发的制品； 提供对项目中的制品和活动进行监控与度量的准则。,1）需求获取的目标 对大系统的开发来说，需求一般包括需求获取和需求分析 需求获取的目标是： 需求分析的目标是：,客观问题（系统）,系统需求获取模型,形成-涉及：不同概念和不同处理逻辑,形成-涉及：不同概念和不同处理逻辑,系统分析模型,描述系统需求获取模型,体系结构描述 -USE CASE模型,体系结构描述 -Analysis模型,实现需求获取目标的基本途径 实现需求获取的目标，即实现实际问题到软件开发需求获取层的映射，从软件开发的角度-实现

9、第一次抽象。其中至少涉及以下3个问题： 如何定义需求获取层，即给出该层的术语； 如何确定模型表示工具； 如何映射。,实际问题,需求获取层,模型表示 工具,注：这些概念体现了一些设计原理,（1）需求获取层的术语（概念） USE CASE actor 以及 4个表达关系的概念：关联、包含、扩展、泛化。 以及USE CASE图。,实际问题,模型表示 工具 -USE CASE图,体系结构描述 -USE CASE模型,（2） 需求工作流,实际问题,？,需求获取模型 -（USE CASE 模型）,形成,体系结构描述 -USE CASE模型,形成,2.1 需求工作流及所创建的制品 一般来说，需求工作流包括以

10、下四步，但它们并非是严格 分离的。,要做的工作 产生的制品 -列出候选的需求 特征（Feature）列表 -理解系统语境 领域模型或业务模型 -捕获功能需求 Use case 模型 -捕获非功能需求 补充需求或针对一些特定需求 的use cases,特征（Feature）: 一个功能项（function item ）以及相关的简要描述 称为特征（ feature）。作为需求, 并被转换为其它制品。,应用系统,潜在的抽象层,例如：按学科计算每一学生的期末考试平均成绩。 统计2科以上不及格的人数。 给出各分段（0-60，60-85，85-100）的人数分布情况。,feature,作为需求, 被转换

11、为其它制品。,应用系统,潜在的抽象层 （特征层）,一个抽象层 （ USE CASE 层）,USE CASE1,USE CASE,USE CASE2,USE CASE3,制品：USE CASE模型,规约,规约,形成,Actor,关联,关于特征的几点说明： -每一特征有一个简短的名字和简要的说明或定义。 -每一特征还有一组对规划有意义的信息，可以包括： 状态（ Status），例如 ，提交，批准，确认 是组成的等。 估算的实现成本。( 所需的资源类型和人/时）。 优先级（Priority）(e.g.,critical, important, or ancillary)。 实现中相联的风险等级。,

12、业务模型或领域模型 领域模型 领域模型捕获了系统语境中的一些重要对象类型。其中领域 对象表示 系统工作环境中存在的事物或发生的事件。 一般来说，领域类以三种形态出现： 业务对象：表示那些被业务所操纵（ manipulate）的事物 （ thing），例如定单，帐目和合同等。 实在对象（Real-world objects）和概念：例如 飞机， 火箭等。 事件（Events）：例如飞机到达，飞机起飞等。 一般来说，领域模型是以类图予以描述的。,Order date of submission delivery address,Item description picture cost,Invoi

13、ce amount date of submission last date of payment,Account balance owner,1* payable,1*,buyer 1,seller 1,A class diagram in a domain model, capturing the most important concepts in the context of the system,Example: Domain Classes Order, Invoice, Item, and Account,业务模型 业务模型可以分为以下2个层次： 业务 use case 模型 通

14、过业务use case和业务 actors 来描述业务过程，他们分别 对应业务过程（business processes）和客户（customers ）。 一般来说，业务 use case 模型 是以use case 图予以描述的. 业务对象模型 业务对象模型是一个业务的内部（interior）模型。描述每 一个业务use case 是如何通过一组workers 、business entities 、 work units予以细化的。,其中， Business entity 表示某些事物（ something）,例如 一张发票。 它们在一个业务use case中被使用之。 A work un

15、it 是这样实体的一个集合，对最终用户 而言，形成了可认知的整体。 Business entities 和 work unit 用于表达同一类概念，作为 领域类，例如定单，栏目，发票等。 每一个业务use case的细化可以通过交互图和活动图予以 表示。, 以 use case 捕获需求 Use-Case 模型 Use-Case 模型 用以表达客户认可的需求-系统必须 满足的条件和能力。 Use-Case模型 作为客户和开发人员之间的一种共识。 Use-Case 模型是一个系统的一种模型，包括 actors、 use cases 以及它们之间的关系。,Use-Case system,Use-C

16、ase model,Actor,Use case,*,*,1,The Use-Case system denotes the top-level package of the model,Use-Case 模型以及其内容,参与需求工作流的有关人员,System Analysis,responsible for,Use-case Specifier,responsible for,User-interface designer,responsible for,Architect,responsible for,use case model,Actor Glossary,Use case,User

17、 interface prototype,Architecture Description,需求捕获工作流中的活动 1、发现并描述Actor （1）发现 Actor的方法 发现 actor的这一任务，依赖于起始点： - 当存在业务模型时 可以直接地发现一些候选的 actors，即： 对于业务中的每一个工作人员，可以建议一个候选的 actor 对于每一个将要使用该信息系统的业务actor （即每一个业务客户）， 可以建议候选的一个 actor。 - 当有或没有领域模型时 分析人员就要与客户一起标识 actor，并将所标识 actor进行分类，形成 一些候选的 actors。 Note:还要标识表

18、示外部系统的actor和系统维护和运行所需要的actor 。,在确定系统actors 时可用的2条准则： 第一条准则：至少要识别出一个用户，可以扮演候选的 actor。 该准则将帮助我们仅发现那些相关的actors，避免 actor 仅是一些想象的“事物”。 第二条准则：系统中不同actors 实例之间，其角色的重叠 应是最少的。 如果2个或多个actors有着几乎相同的角色，那么就应该 考虑： 是否将这些角色组合到一个actor的角色中，或 是否需要发现另外一个“一般化”的actor，使之具有那些 重叠的、公共的角色 ，并可以通过“泛化”，形成那些特 定actor。,（2）Actors的命名

19、与描述 Actors的命名： 对actors给出恰当的名字是非常重要的。这样的名字可以 “传达”（ convey）所期望的语义。 Actors的描述： 对actor的描述，应包含其角色（责任）以及为了完成其 责任所需要的条件。,例如: the Buyer, Seller,and Accounting System Actors Buyer A Buyer represents a person who is responsible for buying goods or services as described in the business use case Sales: from Ord

20、er to Delivery. This person may be an individual or someone within a business organization. The Buyer of goods and services need the Billing and Payment System to send order and to pay invoices., Seller A Seller represents a person who sells and delivers goods or services. The Seller uses the system

21、 to look for new orders and to send order confirmations, invoices, and payment reminders., Accounting System The Billing and Payment System sends verifications of transactions to the Accounting System.,Order Goods or Services,Confirm Order,Invoice Buyer,Pay Invoice,Perform Transaction,Pay Overdraft

22、Fee,Send Reminders,extend,Initiator,Initiator,Initiator,Initiator,Initiator,Buyer,Seller,Accounting system,Use case in the Billing and Payment System that support the business use case Sales:From Order to Delivery. The role initiator, attached to the associations, indicate which actor starts the use

23、 case.,2、发现并描述 Use Case (1) 对 use case的回顾 A use case specifies a sequence of actions, including alternatives of the sequence , that the system can perform , interacting with actor of the system. actor 使用系统的每一方法（ way ），被表示为一个use case Use case 是系统向它的actors 提供结果（值）的功能块 （chunks ）。 例如， use case 实例,Withdr

24、aw money,The use case Withdraw money enables instances of the actor Bank Customer to withdraw money through an ATM,因此 对一个 use case的描述可以使用正文事件流、状态图、活动 图、通讯图和顺序图。 在一个 use case中的一条路径，可以看作： 启动了该use case实例，并使之处于一个开始状态； 该状态由一个外部的actor所引发（ invoke）；并由一个 动作序列的执行，使之转化为另一状态。其中该序列包含 内部计算、路径选择和向某一 actor发送消息。 在一个

25、新的状态中，等待actor发送另一外部消息。 该状态由一个新的消息予以引发（ invoke），以此继续， 通过了许多状态，直到该use case实例被终止.,大部分是一个actor实例引发一个use case实例， 但也可能由一个事件所引发，例如由系统之外的定时时钟所引发。 Use case有其自己的属性,例如 Withdraw money 这一use case 可以认为它有属性“帐目”（account）、存款数目（ amount to be withdrawn）等，这些值局部于一个use case实例 Use case实例不能与其它 use case 实例发生交互。 在 use case模型

26、中，唯一的一类交互可以发生在 actor实例和use case 实例之间。这是由于我们把use case实例看作是原子的，每一个use case的行为可以被其它 use case所中断， 这就确保了我们可以理解一个特定的use case模型。,(2) 发现Use Case的方法 当开始点是一个业务模型时 一旦我们发现了一个工作人员或业务actor的所有角色， 标识一些暂时的use case最直接的方法是： 对每一工作人员和业务actor 的每一角色，对应地创建 一个use case。,因此， 针对每一业务 use case ,为每一工作人员和业务 actor，设置 一个 use case。 细

27、化并调整这些暂时的use cases. 决策工作人员和业务 actor 的那些任务应该由系统自动地 予以实现，作为use cases，并重新组织这些 use case，更好 地适应 actors的要求（ needs） 。 结论： 为参与业务 use case细化（ realization）的、使用该信息系统的 每一工作人员的 每一角色，建议一个use case。,当开始点没有业务模型时 要通过与客户以及用户一起工作来标识 use case。其中： 应一个一个地审阅 actors, 为每一个actor建议一些侯选的 use case。 例如，可以与他们进行交谈，研究需要哪些 use case。

28、其中，均应根据actor的需求来发现 use case： - actor通常需要use cases来支持他们的工作： 创建、改变、跟踪、迁移业务use cases中使用的业务对象， 例如定单和帐目。 -actor 可能还要通知系统一些外部事件，包括已经发生的 一些事件，例如：发票已经过期。 -还可能存在一些其他的actors ，他们执行系统的启动、终 止和维护。, 对发现的候选use cases 的初始处理： 根据以上发现的那些侯选的use cases， 为了使系统use cases容易修改、复审、测试和管理，应考虑它们之间的组成关系。 为每一use cases 选择一个名字（一般应以动词开始

29、），这个可以引导我们思考其中向actor产生值的特定动作序列。用户和系统的一个交互序列，可以在一个use case中予以规约，也可以在多个use case中予以规约。 当决定把一个侯选的use case 最终作为系统的一个 use case 时，必须考虑：它是否是完整的 （complete）； 它是否是另一use case的组成部分。, use case大小的确定 确定 use case的大小，有时是相当困难的. 对此，必须了解： - use case 应为它的actors产生相应的值. -特别地，use case 向一个特定的actor交付了可见 的结果（值）. 以上的了解，可以指导我们合适

30、的确定use case大小。 其中要注意2个关键词： 结果（值）（ result of value ） 特定的actor（ particular actor ）,结果（值） (result of value) 每一个成功执行的 use case 应向actor 提供一些值，使actor 达到某一目的。 注意：一个 use case 实例，例如电话呼叫，可能涉及多个 actor. 在这种情况中，应当应用“可见的结果值”这一准则，启动actor （to initiating actor）. “结果（值） result of value ” 这一准则，可以帮助我们避免使发现的 use cases 太

31、小。,特定的actor ( particular actor) 通过使标识的 use cases 都有相应的真实用户，这样可以确保不会太大。 针对一些 actors, 我们第一次发现的 use cases 常常需要予以重新组织，重新评估，使之更加 “稳定”。例如，一旦我们已经有了一个体系结构，那么对于我们捕获的新的 use cases 就必须进行调整，以便适应已有的体系结构。这样，就有可能需要相当大的变动。,(3) use case的简单描述 当分析员标识use case时，首先，一般要给出该use case的 名字。 继之，对use case给出简单描述： 开始，用几句话概括其中的动作； 而

32、后，对系统与其actor交互时要做的事情予以一步一 步地描述. 例如：描述 Pay Invoice Use Cases 概括动作 The use case Pay Invoice is used by a Buyer to schedule invoice payments. The Pay Invoice use case then effects the payment on the due date., 一步一步的描述 Before this use case can be initiated, the Buyer has already received an invoice (del

33、ivered by another use case called Invoice Buyer ) and has also received the goods or services ordered.:,1. The buyer studies the invoice to pay and checks that it is consistent with the original order. 2. The Buyer schedules the invoice for payment by the bank. 3. On the day payment is due, the syst

34、em checks to see if there is enough money in the Buyers account. If enough money is available, the transaction is made.,(4) 确定use case的优先级（ Priority） 目的 用于决定哪些use case在早期的迭代中予以开发（即分析、 设计、实现等），哪些use case在后期的迭代中予以开发。 输入与输出,Architect,Use Case model outlined,Supplementary Requirements,Glossary,Architect

35、ure Description view of the use case model,Prioritized Use Cases,视角与使用 视角：从体系结构的视觉，来审视所建立的use case 模 型。并给出在这一视觉下的体系结构描述。 （注：其中必须与项目经理一起来工作。） 使用：由该视角形成的体系结构，可以在规划的一个迭代中 针对要开发什么时予以使用。其中，要注意：在这 一规划中，还需要考虑其它非技术因素，例如系统 开发的业务和经济方面的因素。,内容：Use Case 模型视觉下的体系结构描述，刻画了在体 系结构方面具有重要意义的use cases。包含： -某些重要、关键功能的use

36、 case ；或 -那些必须在软件生存周期早期予以开发的某些重要 需求的use case。,（5）Detail a Use Case 目的 详细地描述事件流，包括use case是怎样开始的，是怎样结束 的，是怎样与actors 进行交互的。 输入与输出,Use case Specifier,Use Case model outlined,Supplementary Requirements,Glossary,Use Case detailed,Detail a Use Case,The result is a detailed description of a particular use

37、case in text and diagram.,细化途径 涉及： 如何描述一个 use case中所有可选的路径； 在一个 use case的描述中包括的内容； 如何在必要时形式化地给出use case的描述。 其中规约人员应当： -紧密地与该use case的实际用户一起工作； -在与用户的交谈中，通常需要记录他们对该use case 的 理解； -与用户讨论建议方案，并请他们复审use case描述。,有效技术：事件流技术 关于事件流（Flow of Events）的作用： 当所规约的use case执行时，事件流规约了系统做什么。即每一个use case的事件流，可以作为use ca

38、se的动作序列的正文描述。 当所规约的use case执行时，事件流还规约了系统怎样与其actors进行交互 基本要求：从管理的角度来说，一个事件流的描述应包括一组动作序列，该组动作序列适于修改、复审、设计、实现和测试，并作为用户手册的一节。,以事件流描述Use Case所采用的结构 一个 use case 可以被认为有一个开始状态，一些中间 状态，并从一个状态转换为另一状态，如下所示：,其中， 红箭头线表示基本路径，曲线是其它路径。 当被一个事件（例如一个消息）激发时，每一这样的转 换是该use-case的一个实例所执行的一个动作序列。,细化USE CASE，即： 从开始状态到终止状态选择一

39、条完整的基本路径，并在一 节中对该路径予以描述。 其中，这一路径的选择应该是用户认为它是一条最通常的 路径，并对 相关的actor产生最明显的值（ the most obvious value ）。 一般来说，这样的一条路径应该包含系 统不大需要的一些例外和异常处理。, 接之，在另一节中描述其余的可选路径 其中，有些可选的路径是很小的，是否可以把它作为基本 路径的组成部分还是在一个独立的一节中作为可选路径予以 描述，这是一个设计决策问题，取决于该描述是否精确，是 否容易阅读。. 注意：不管我们选择了什么描述技术，都必须描述所有的 可选路径，否则就不能说给出了对该use case的规约。,Exa

40、mple: Paths of the Pay Invoice Use Case Precondition: The buyer has received the goods or services ordered and at least one invoice from the system. The buyer now plans to schedule the invoice(s) for payment. Flow of Events Basic Path 1 The buyer invokes the use case by beginning to browse the invoi

41、ces received by the system. The system checks that the content of each invoice is consistent with order confirmations received early(as part of the Confirm Order use case) and somehow indicates this to the buyer. The order confirmation describes which items will be delivered, when , where, and at wh

42、at price.,2 The buyer decides to schedule an invoice for payment by the bank, and the system generates a payment request to transfer money to the sellers account. Note that a buyer may not schedule the same invoice for payment twice. 3 later, if there is enough money in the buyers account, a payment

43、 transaction is made on the scheduled date. During the transaction, money is transferred from the buyers account to the sellers account, as described by the abstract use case Perform Transaction(which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. Th

44、e bank collect a fee for the transaction, which is withdrawn from the buyers account by the system. 4 The use case instance terminates.,Alternative Path In Step 2, the buyer may instead ask the system to send an invoice rejection back to the seller. In Step 3, if there is not enough money in the acc

45、ount, the use case will cancel the payment and notify the buyer. Post-condition: The use case instance ends when the invoice has been paid or when the invoice payment was canceled and no money was transferred.,Use Case 描述中的基本内容 一个 use-case 描述中，必须包括： 定义其开始状态，作为一个前置条件（recondition）. 定义第一个要执行的动作，例如 Step

46、 1，即描述该 use case 是如何开始的，什么时候开始。 定义所要求的次序，即给出其中的动作必须以该次序予以 执行。例中，该次序是通过步骤号予以定义的（ (Step 1-4) ）。 描述该 use case 是如何结束的，什么时候结束（ Step 4 ）。 定义可能的结束状态，作为后置条件（post conditions）., 给出在基本路径描述中的可选路径的描述。 给出那些基本路径之外的可选路径的描述。 定义与actors 的系统交互以及它们之间的交换 (Step 2 and Step 3)，即描述该use case 动作序列，这些动作是如何被 相关的actors予以激发（ invok

47、e）以及它们是如何执行的， 以响应actor的要求。 描述系统中有关对象、值和资源的用法（Usage ） (Step 3). 即描述在一个use-case使用中的动作序列以及对该use-case属 性所赋予的值。,如果该系统与其它系统交互，则必须规约这一交互,例如引用 一个标准的通讯协议。 注意：在use-case 描述中，我们必须显式地描述系统做什么 （执行的动作） ， 以及actor做什么。应从actors 做 什么中分离出系统的责任。否则， 对系统规约的使用 来说，这样的use-case描述就不够精确。,当use case 描述是： 可理解的； 正确的（即捕获了正确的需求）； 完备的（ complete，例如，描述了所有可能的路径）; 一致的. 我们才可以说，结束了use case的描述。 该描述可以在需求捕获结束的复审会中，由分析员予以评估，也可以由用户和客户予以评估。但仅客户和用户才能确认该use cases是否是正确的。,半形式化的Use-Case描述 前置条件 对于一个复杂的实时系统， use case可能是相当负责的， 例如actors和 use c