软件体系结构SoftwareArchitecture

1、软件体系结构(Software Architecture)讲义13：统一软件开发过程（RUP）1一、引言为屏蔽计算机硬件的异构性，发展了操作系统.NET/COMWeb ServicesJ2EE/EJB操作系统UNIXWindowsLinuxC/C+语言Java语言支撑软件中间件为屏蔽操作系统和编程语言的异构性，发展了支撑软件和中间件为了屏蔽中间件之间的异构性，出现了Web技术。Fortran语言为了祢补应用软件与现实计算环境之间的距离应用系统 网 络 层 综观 软件技术 的发展 应用系统概念不同，逻辑不同。解决问题的思维逻辑不同。 -“距离”语 言网络 异构VB、VC -程序设计环境中间件技术

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

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

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

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

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

7、该阶段末，就能够估算成本、进度，并能详细地规划构造阶段（ the construction phase）。 构造阶段（ the construction phase）的基本目标是： -开发完整的系统 -确保产品可以开始向客户交付, 即具有初始操作能力。 交付阶段（ the transition phase）的基本目标是： -确保有一个实在的产品，发布给用户群。 期间，培训用户如何使用该软件。注：这4个阶段是演化模型的一个变体。 由上可见：USDP对于如何运用UML的概念进行软件开发提供了详细指导。即： 指导开发队伍安排其开发活动的次序； 为各开发者和整个开发组指定任务； 明确地规定需要开发的制

8、品； 提供对项目中的制品和活动进行监控与度量的准则。1）需求获取的目标 对大系统的开发来说，需求一般包括需求获取和需求分析 需求获取的目标是： 需求分析的目标是： 客观问题（系统）系统需求获取模型形成-涉及：不同概念和不同处理逻辑形成-涉及：不同概念和不同处理逻辑系统分析模型描述系统需求获取模型体系结构描述 -USE CASE模型体系结构描述 -Analysis模型实现需求获取目标的基本途径 实现需求获取的目标，即实现实际问题到软件开发需求获取层的映射，从软件开发的角度-实现第一次抽象。其中至少涉及以下3个问题： 如何定义需求获取层，即给出该层的术语； 如何确定模型表示工具； 如何映射。实际问

9、题需求获取层模型表示工具注：这些概念体现了一些设计原理（1）需求获取层的术语（概念） USE CASE actor 以及 4个表达关系的概念：关联、包含、扩展、泛化。 以及USE CASE图。实际问题模型表示工具-USE CASE图体系结构描述 -USE CASE模型（2） 需求工作流实际问题？需求获取模型-（USE CASE 模型）形成体系结构描述 -USE CASE模型形成 2.1 需求工作流及所创建的制品 一般来说，需求工作流包括以下四步，但它们并非是严格分离的。 要做的工作 产生的制品 -列出候选的需求 特征（Feature）列表 -理解系统语境 领域模型或业务模型 -捕获功能需求 U

10、se case 模型 -捕获非功能需求 补充需求或针对一些特定需求 的use cases 特征（Feature）: 一个功能项（function item ）以及相关的简要描述称为特征（ feature）。作为需求, 并被转换为其它制品。 应用系统潜在的抽象层例如：按学科计算每一学生的期末考试平均成绩。 统计2科以上不及格的人数。 给出各分段（0-60，60-85，85-100）的人数分布情况。feature作为需求, 被转换为其它制品。应用系统潜在的抽象层（特征层）一个抽象层（ USE CASE 层）USE CASE1USE CASEUSE CASE2USE CASE3制品：USE CASE

11、模型规约规约形成Actor关联关于特征的几点说明： -每一特征有一个简短的名字和简要的说明或定义。 -每一特征还有一组对规划有意义的信息，可以包括： 状态（ Status），例如 ，提交，批准，确认 是组成的等。 估算的实现成本。( 所需的资源类型和人/时）。 优先级（Priority）(e.g.,critical, important, or ancillary)。 实现中相联的风险等级。 业务模型或领域模型领域模型 领域模型捕获了系统语境中的一些重要对象类型。其中领域对象表示 系统工作环境中存在的事物或发生的事件。 一般来说，领域类以三种形态出现： 业务对象：表示那些被业务所操纵（ man

12、ipulate）的事物（ thing），例如定单，帐目和合同等。 实在对象（Real-world objects）和概念：例如 飞机，火箭等。 事件（Events）：例如飞机到达，飞机起飞等。 一般来说，领域模型是以类图予以描述的。 Order date of submission delivery address Item description picture cost Invoice amount date of submission last date of payment Account balance owner1.* payable1.* buyer 1 seller 1 A c

13、lass 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 模型 通过业务use case和业务 actors 来描述业务过程，他们分别 对应业务过程（business processes）和客户（customers ）。 一般来说，业务 use case 模型 是以use cas

14、e 图予以描述的. 业务对象模型 业务对象模型是一个业务的内部（interior）模型。描述每 一个业务use case 是如何通过一组workers 、business entities 、 work units予以细化的。 其中， Business entity 表示某些事物（ something）,例如 一张发票。 它们在一个业务use case中被使用之。 A work unit 是这样实体的一个集合，对最终用户 而言，形成了可认知的整体。 Business entities 和 work unit 用于表达同一类概念，作为 领域类，例如定单，栏目，发票等。 每一个业务use case

15、的细化可以通过交互图和活动图予以 表示。 以 use case 捕获需求 Use-Case 模型 Use-Case 模型 用以表达客户认可的需求-系统必须 满足的条件和能力。 Use-Case模型 作为客户和开发人员之间的一种共识。 Use-Case 模型是一个系统的一种模型，包括 actors、 use cases 以及它们之间的关系。Use-Case systemUse-Case model Actor Use case*1The Use-Case system denotes the top-level package of the modelUse-Case 模型以及其内容 参与需求工

16、作流的有关人员 System Analysis responsible for Use-case Specifier responsible forUser-interface designer responsible for Architect responsible for use case model Actor Glossary Use case User interface prototype Architecture Description 需求捕获工作流中的活动 1、发现并描述Actor（1）发现 Actor的方法发现 actor的这一任务，依赖于起始点： - 当存在业务模型时

17、可以直接地发现一些候选的 actors，即： 对于业务中的每一个工作人员，可以建议一个候选的 actor 对于每一个将要使用该信息系统的业务actor （即每一个业务客户）， 可以建议候选的一个 actor。 - 当有或没有领域模型时 分析人员就要与客户一起标识 actor，并将所标识 actor进行分类，形成 一些候选的 actors。 Note:还要标识表示外部系统的actor和系统维护和运行所需要的actor 。 在确定系统actors 时可用的2条准则： 第一条准则：至少要识别出一个用户，可以扮演候选的 actor。 该准则将帮助我们仅发现那些相关的actors，避免 actor 仅是

18、一些想象的“事物”。 第二条准则：系统中不同actors 实例之间，其角色的重叠 应是最少的。 如果2个或多个actors有着几乎相同的角色，那么就应该 考虑： 是否将这些角色组合到一个actor的角色中，或 是否需要发现另外一个“一般化”的actor，使之具有那些 重叠的、公共的角色 ，并可以通过“泛化”，形成那些特 定actor。（2）Actors的命名与描述 Actors的命名： 对actors给出恰当的名字是非常重要的。这样的名字可以“传达”（ convey）所期望的语义。Actors的描述： 对actor的描述，应包含其角色（责任）以及为了完成其责任所需要的条件。例如: the Bu

19、yer, 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 Order to Delivery. This person may be an individual or someone within a business organization. The Buyer of goods and services

20、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 to look for new orders and to send order confirmations, invoices, and payment reminders. Accounting System The Billing and P

21、ayment System sends verifications of transactions to the Accounting System. Order Goods or ServicesConfirm OrderInvoice BuyerPay InvoicePerform TransactionPay Overdraft FeeSend RemindersextendInitiatorInitiatorInitiatorInitiatorInitiatorBuyerSellerAccounting systemUse case in the Billing and Payment

22、 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 case.2、发现并描述 Use Case (1) 对 use case的回顾 A use case specifies a sequence of actions, including alternatives of the sequence , that the system

23、can perform , interacting with actor of the system. actor 使用系统的每一方法（ way ），被表示为一个use case Use case 是系统向它的actors 提供结果（值）的功能块 （chunks ）。 例如， use case 实例Withdraw moneyThe use case Withdraw money enables instances of the actor Bank Customer to withdraw money through an ATM因此 对一个 use case的描述可以使用正文事件流、状态图

24、、活动 图、通讯图和顺序图。 在一个 use case中的一条路径，可以看作： 启动了该use case实例，并使之处于一个开始状态； 该状态由一个外部的actor所引发（ invoke）；并由一个 动作序列的执行，使之转化为另一状态。其中该序列包含 内部计算、路径选择和向某一 actor发送消息。 在一个新的状态中，等待actor发送另一外部消息。 该状态由一个新的消息予以引发（ invoke），以此继续， 通过了许多状态，直到该use case实例被终止. 大部分是一个actor实例引发一个use case实例， 但也可能由一个事件所引发，例如由系统之外的定时时钟所引发。 Use case

25、有其自己的属性,例如 Withdraw money 这一use case 可以认为它有属性“帐目”（account）、存款数目（ amount to be withdrawn）等，这些值局部于一个use case实例 Use case实例不能与其它 use case 实例发生交互。 在 use case模型中，唯一的一类交互可以发生在 actor实例和use case 实例之间。这是由于我们把use case实例看作是原子的，每一个use case的行为可以被其它 use case所中断， 这就确保了我们可以理解一个特定的use case模型。(2) 发现Use Case的方法 当开始点是一个

26、业务模型时 一旦我们发现了一个工作人员或业务actor的所有角色， 标识一些暂时的use case最直接的方法是： 对每一工作人员和业务actor 的每一角色，对应地创建一个use case。因此， 针对每一业务 use case ,为每一工作人员和业务 actor，设置 一个 use case。 细化并调整这些暂时的use cases. 决策工作人员和业务 actor 的那些任务应该由系统自动地 予以实现，作为use cases，并重新组织这些 use case，更好 地适应 actors的要求（ needs） 。 结论： 为参与业务 use case细化（ realization）的、使用

27、该信息系统的每一工作人员的 每一角色，建议一个use case。当开始点没有业务模型时 要通过与客户以及用户一起工作来标识 use case。其中： 应一个一个地审阅 actors, 为每一个actor建议一些侯选的 use case。 例如，可以与他们进行交谈，研究需要哪些 use case。 其中，均应根据actor的需求来发现 use case： - actor通常需要use cases来支持他们的工作： 创建、改变、跟踪、迁移业务use cases中使用的业务对象，例如定单和帐目。 -actor 可能还要通知系统一些外部事件，包括已经发生的一些事件，例如：发票已经过期。 -还可能存在一

28、些其他的actors ，他们执行系统的启动、终止和维护。 对发现的候选use cases 的初始处理： 根据以上发现的那些侯选的use cases， 为了使系统use cases容易修改、复审、测试和管理，应考虑它们之间的组成关系。 为每一use cases 选择一个名字（一般应以动词开始），这个可以引导我们思考其中向actor产生值的特定动作序列。用户和系统的一个交互序列，可以在一个use case中予以规约，也可以在多个use case中予以规约。 当决定把一个侯选的use case 最终作为系统的一个 use case 时，必须考虑：它是否是完整的 （complete）； 它是否是另一u

29、se case的组成部分。 use case大小的确定 确定 use case的大小，有时是相当困难的. 对此，必须了解： - use case 应为它的actors产生相应的值. -特别地，use case 向一个特定的actor交付了可见 的结果（值）. 以上的了解，可以指导我们合适的确定use case大小。 其中要注意2个关键词： 结果（值）（ result of value ） 特定的actor（ particular actor ） 结果（值） (result of value) 每一个成功执行的 use case 应向actor 提供一些值，使actor 达到某一目的。 注意：一

30、个 use case 实例，例如电话呼叫，可能涉及多个 actor. 在这种情况中，应当应用“可见的结果值”这一准则，启动actor （to initiating actor）. “结果（值） result of value ” 这一准则，可以帮助我们避免使发现的 use cases 太小。特定的actor ( particular actor) 通过使标识的 use cases 都有相应的真实用户，这样可以确保不会太大。 针对一些 actors, 我们第一次发现的 use cases 常常需要予以重新组织，重新评估，使之更加 “稳定”。例如，一旦我们已经有了一个体系结构，那么对于我们捕获的新

31、的 use cases 就必须进行调整，以便适应已有的体系结构。这样，就有可能需要相当大的变动。(3) use case的简单描述 当分析员标识use case时，首先，一般要给出该use case的名字。 继之，对use case给出简单描述： 开始，用几句话概括其中的动作； 而后，对系统与其actor交互时要做的事情予以一步一 步地描述.例如：描述 Pay Invoice Use Cases 概括动作 The use case Pay Invoice is used by a Buyer to schedule invoice payments. The Pay Invoice use c

32、ase then effects the payment on the due date. 一步一步的描述 Before this use case can be initiated, the Buyer has already received an invoice (delivered 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 i

33、t 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 system 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） 目的 用于决定哪些us

34、e case在早期的迭代中予以开发（即分析、设计、实现等），哪些use case在后期的迭代中予以开发。 输入与输出 Architect Use Case model outlined Supplementary Requirements Glossary Architecture Description view of the use case modelPrioritized Use Cases 视角与使用 视角：从体系结构的视觉，来审视所建立的use case 模 型。并给出在这一视觉下的体系结构描述。 （注：其中必须与项目经理一起来工作。） 使用：由该视角形成的体系结构，可以在规划的一

35、个迭代中 针对要开发什么时予以使用。其中，要注意：在这 一规划中，还需要考虑其它非技术因素，例如系统 开发的业务和经济方面的因素。内容：Use Case 模型视觉下的体系结构描述，刻画了在体 系结构方面具有重要意义的use cases。包含： -某些重要、关键功能的use case ；或 -那些必须在软件生存周期早期予以开发的某些重要 需求的use case。 （5）Detail a Use Case 目的 详细地描述事件流，包括use case是怎样开始的，是怎样结束的，是怎样与actors 进行交互的。 输入与输出 Use case Specifier Use Case model out

36、lined Supplementary Requirements Glossary Use Case detailedDetail a Use Case The result is a detailed description of a particular use case in text and diagram.细化途径 涉及： 如何描述一个 use case中所有可选的路径； 在一个 use case的描述中包括的内容； 如何在必要时形式化地给出use case的描述。 其中规约人员应当： -紧密地与该use case的实际用户一起工作； -在与用户的交谈中，通常需要记录他们对该use

37、case 的 理解； -与用户讨论建议方案，并请他们复审use case描述。 有效技术：事件流技术 关于事件流（Flow of Events）的作用： 当所规约的use case执行时，事件流规约了系统做什么。即每一个use case的事件流，可以作为use case的动作序列的正文描述。 当所规约的use case执行时，事件流还规约了系统怎样与其actors进行交互 基本要求：从管理的角度来说，一个事件流的描述应包括一组动作序列，该组动作序列适于修改、复审、设计、实现和测试，并作为用户手册的一节。 以事件流描述Use Case所采用的结构 一个 use case 可以被认为有一个开始状态

38、，一些中间状态，并从一个状态转换为另一状态，如下所示：其中， 红箭头线表示基本路径，曲线是其它路径。 当被一个事件（例如一个消息）激发时，每一这样的转换是该use-case的一个实例所执行的一个动作序列。细化USE CASE，即： 从开始状态到终止状态选择一条完整的基本路径，并在一节中对该路径予以描述。 其中，这一路径的选择应该是用户认为它是一条最通常的路径，并对 相关的actor产生最明显的值（ the most obvious value ）。 一般来说，这样的一条路径应该包含系统不大需要的一些例外和异常处理。 接之，在另一节中描述其余的可选路径 其中，有些可选的路径是很小的，是否可以把它

39、作为基本路径的组成部分还是在一个独立的一节中作为可选路径予以描述，这是一个设计决策问题，取决于该描述是否精确，是否容易阅读。. 注意：不管我们选择了什么描述技术，都必须描述所有的可选路径，否则就不能说给出了对该use case的规约。Example: 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

40、 the invoice(s) for payment.Flow of EventsBasic Path 1 The buyer invokes the use case by beginning to browse the invoices 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 someho

41、w indicates this to the buyer. The order confirmation describes which items will be delivered, when , where, and at what 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 m

42、ay not schedule the same invoice for payment twice.3 later, if there is enough money in the buyers account, a payment 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

43、Transaction(which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. The bank collect a fee for the transaction, which is withdrawn from the buyers account by the system. 4 The use case instance terminates.Alternative PathIn Step 2, the buyer may instead

44、 ask the system to send an invoice rejection back to the seller.In Step 3, if there is not enough money in the account, 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

45、 money was transferred. Use Case 描述中的基本内容 一个 use-case 描述中，必须包括： 定义其开始状态，作为一个前置条件（recondition）. 定义第一个要执行的动作，例如 Step 1，即描述该 use case 是如何开始的，什么时候开始。 定义所要求的次序，即给出其中的动作必须以该次序予以 执行。例中，该次序是通过步骤号予以定义的（ (Step 1-4) ）。 描述该 use case 是如何结束的，什么时候结束（ Step 4 ）。 定义可能的结束状态，作为后置条件（post conditions）. 给出在基本路径描述中的可选路径的描述。

46、 给出那些基本路径之外的可选路径的描述。 定义与actors 的系统交互以及它们之间的交换 (Step 2 and Step 3)，即描述该use case 动作序列，这些动作是如何被 相关的actors予以激发（ invoke）以及它们是如何执行的， 以响应actor的要求。 描述系统中有关对象、值和资源的用法（Usage ） (Step 3). 即描述在一个use-case使用中的动作序列以及对该use-case属 性所赋予的值。如果该系统与其它系统交互，则必须规约这一交互,例如引用 一个标准的通讯协议。注意：在use-case 描述中，我们必须显式地描述系统做什么 （执行的动作） ， 以

47、及actor做什么。应从actors 做 什么中分离出系统的责任。否则， 对系统规约的使用 来说，这样的use-case描述就不够精确。 当use case 描述是： 可理解的； 正确的（即捕获了正确的需求）； 完备的（ complete，例如，描述了所有可能的路径）; 一致的. 我们才可以说，结束了use case的描述。 该描述可以在需求捕获结束的复审会中，由分析员予以评估，也可以由用户和客户予以评估。但仅客户和用户才能确认该use cases是否是正确的。 半形式化的Use-Case描述 前置条件 对于一个复杂的实时系统， use case可能是相当负责的，例如actors和 use c

48、ase 之间的交互可能经过相当多的状态和状态转换，从而几乎不可能保持正文描述的use case 的一致性。 相关的技术 为此，需要使用更结构化的描述技术，这样的技术一般使用可视化的建模技术，来描述use cases 。以下技术可以帮助系统分析人员更好地理解use cases ：BrowsingScheduleRejectInvoice ScheduledPay on due dateInvoice PaidInvoice CancelledThe statechart diagram for the Pay Invoice use case showing how an instance of

49、 the Invoice use case moves over several states in series of state transitions.UML 状态图 用于描述use case的状态和状态之间的转换。活动图 用于描述状态之间更详细的动作序列。 注：活动图源于SDL的状态转换图（ SDL state transition diagrams），它是已予证明的、用于电信的一种语言。交互图 用于描述一个use case的实例如何与 actor 的一个实例 进行交互。为此，交互图给出了use case 以及参与的 actor（s）。注意: 在使用这些图当中，由于问题的复杂性，有时可

50、能会出现一些大的、复杂的图，以至于很难阅读和理解，特别对于那些不是软件开发人员来说更难阅读。 这些图是一些更接近开发细节的图，应与系统其它模型保持一致。建议： 应谨慎地使用这些图，在一般情况下，应采用 use case的正文描述（即事件流描述）。 在很多情况中，正文描述和这些图是互补的。(6) 用户界面的原型构造 目的 建造一个用户界面的原型，使用户有效地执行use cases。 步骤 第一步，用户界面的逻辑设计 第二步，物理用户界面的设计 第三步，开发用户界面原型，演示为了执行该use case，用户怎样使用该系统。 注：如何进行以上三步，可参见有关文献。 (7) Use Case 模型的结

51、构化 前置条件: 系统分析员已经标识了actors 和 use cases, 已经以图予以了描述，并给出了整个use case 模型的说明。 use case 规约人员已经对每一use case开发了详细的描述。 做什么： 抽取use case描述中一般的、共享的功能，用于特定 use case描述。 抽取use case描述中附加的或可选的（additional or optional）功能，它们可能被扩展为特定use case描述。 使用泛化关系，标识并描述那些共享功能 例如：BuyerSellerPay InvoicePay Invoice 和 Perform Transaction这2

52、个 use case之间的泛化关系Perform Transaction使用扩展关系，标识并描述附加的或可选的功能 例如：BuyerSellerPay Invoice Pay Invoice 和 Pay Overdraft Fee 这2个use cases之间的扩展关系extendPerform TransactionPay Overdraft Fee标识use case之间的其它关系 use cases之间还包括其它关系，例如包含关系（include ）。注意：（3点） 在结构化 use case中应注意以下3个问题： 建立 use cases的结构和它们的关系，应尽可能地反映use cas

53、es的实际情况。否则，不论对用户或客户还是对开发人员本身，要理解这些use cases以及它们的意图就变得相当困难. 每一个use case都需要被进一步处理为一个特定的制品。有时，use case规约人员需要给出它的描述；在后续的分析和设计中，use case需要用不同的use-case细化（realization）予以细化。为此， use cases不应太小或太多，从而需要对use case结构化工作予以有效地管理。 应避免分解use case 模型中use cases的功能。最好在分析和设计中对每一 use case进行精化（refining）。这一精化，如果需要的话，是以面向对象风格将

54、由use cases所定义的功能作为概念分析层面上对象之间的协作，以便产生对需求的深入理解.总结-需求获取 需求获取以及相关制品 work to be done result artifacts -List candidate requirements Feature list -Understand system context Business or domain model -Capture functional requirements Use case model-Capture nonfunctional Supplementary requirements requirement

55、s or individual use cases (for use case specific req.)业务模型或领域模型 建立了系统的语境，是创建系 统use case 模型的基础。use case 模型 Use-Case Model 是软件和客户就需求的一个共识，即系统必须具有的条件（conditions）和能力（capabilities） 。 The Use-Case 模型为系统分析、设计、实现以及测试提供了基本的输入。 A Use-Case 模型是系统的一个模型，包含系统中 actors 、 use cases 以及它们之间的关系。即：Use-Case systemUse-Case

56、 model Actor Use case*1The Use-Case model and its contents. The Use-Case system denotes the top-level package of the model use-case 模型捕获了功能需求。非功能需求特定于单个的use case，其规约具有一般性，并不针对一个特定的use case 。 use-case 模型的描述，可以通过： - a survey description -a detailed description of each use case. 对于use case 模型中的每一 use c

57、ase ，应驱动开发的后续工作，并实现它们的无缝连接。即在分析阶段和设计阶段，应标识相匹配的 use-case 细化（realization），并标识测试阶段中的一组测试用例（ test cases ）。 捕获需求阶段的活动序号输入活动执行者输出1业务模型或领域模型,补充需求, 特征表发现参与者和用况系统分析员、客户、用户、其他分析员用况模型概述，术语表2用况模型概述，补充需求，术语表赋予用况优先级体系结构设计者体系结构描述用况模型角度3用况模型概述，补充需求，术语表细化用况用况描述者用况详述4用况详述，用况模型概述，补充需求，术语表人机接口原型化人机接口设计者人机接口原型5用况详述，用况模型

58、概述，补充需求，术语表构造用况模型系统分析员用况模型详述2、 需求分析 实际问题？需求获取模型形成？需求分析模型形成需求获取需求分析注：实现第二次抽象注：实现第一次抽象 1) 需求分析层的术语 分析类（Analysis class） Use Case细化（Use Case Realization-Analysis） 分析包（ Analysis Package） 分析类（Analysis class） 一个分析类抽象地表达了 系统设计中 的一个或多个类和/或子系统。 分析类的基本性质： 分析类关注处理功能需求，而将非功能需求的处理延迟到 以后的设计和实现活动中，并作为类的特殊需求。 分析类很少通

59、过操作和其声明（ signatures）定义或提 供接口。其行为一般是通过高层的责任予以定义的。一 个责任是高内聚的一组由类所定义的行为的正文描述。 分析类的属性也是在很高层次上定义的。这类属性经常是 问题域上的概念，并可通过问题域就可以了解其含义。 分析类所涉及的关联，多数是概念性的，例如关联的导航 性，在分析中并非十分重要，而在设计中就是基本的。目的：使分析类在问题域中更加突出，与设计和实现中的类相比，粒度大，是概念性的。Boundary classes: 内涵：用于系统与其actors 之间交互的建模。 该交互一般涉及向用户和外部系统发出请求和从他们那里接 受信息。 与设计平台的关系：边

60、界类常常是在更高的概念层上，对windows, forms, panes, communication interfaces, printer interfaces, sensors, terminals, and APIs 等的抽象，忽略其中的一些细节，例如： every widget of a user interface，并且不需要描述该交互的物理实 现（realize）。 基于的设计原理：分离用户界面或通讯界面中的变化，形成一个或 多个边界类。 分析类的种类：通常具有三种：边界类（Boundary classes）, 实体类（ Entity classes）， 控制类（ Control