软件体系结构SoftwareArchitecture

单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,*,软件体系结构,(Software Architecture),讲义,13,：统一软件开发过程（,RUP,）,1,一、引言,为屏蔽计算机硬件的异构性，发展了操作系统,.NET/COM,Web Services,J2EE/EJB,操作系统,UNIX,Windows,Linux,C/C+,语言,Java,语言,支撑软件,中间件,为屏蔽操作系统和编程语言的异构性，发展了支撑软件和中间件,为了屏蔽中间件之间的异构性，出现了,Web,技术。,Fortran,语言,为了祢补应用软件与现实计算环境之间的距离,应用系统,网 络 层,综观 软件技术 的发展,应用系统,概念不同，逻辑不同。,解决问题的思维逻辑,不同。,-“,距离”,语 言,网络 异构,VB,、,VC -,程序设计环境,中间件技术与产品,面向领域的软件体系结构,应用框架,领域软件生产线,系统建模,运行平台,开发平台,软件工程学科所要解决的问题,软件开发的本质,可概括为：,第一点：,问题空间的概念,与,解空间的模型化概念,之间的映射,例如：对象,= F,（张山）,（,模型化概念,） （,问题空间的概念,）,其中， 对应的过程：需求分析,使用的技术：面向对象,使用的原理：数据抽象,目的：作为计算的客体。,第二点：,问题空间的处理逻辑,与,解空间处理逻辑,之间的映射,例如,1,： 加工,1,（及相关的数据流）,=F,（计算学生成绩）,其中：使用的方法：结构化方法；,对应的过程：需求分析,使用的原理：过程抽象,加工,1,计算学生平均成绩,科目,+,年级,/,班,学生成绩文件,学生平均成绩,规约后的处理逻辑,例如,2,： 交互图,1=H,（计算学生成绩）,其中：对应的过程：需求分析,使用的方法：面向对象,使用的原理：行为结构抽象（简称,行为抽象,）,作用：作为计算规则,：教务员,：教员,递交,A,科学生成绩表,A,科学生成绩表,：教学主任,求,A,科平均,A,科平均,由于以上两个映射是由“人”完成的，因此,就软件开发而言，需要解决两个方面的问题：,1,：技术,2,：管理,进一步说，技术问题主要是指软件开发过程通常需,要遵循的,途径,和,方向,其中，,过程方向,确定用于创建问题模型和设计解的,特定的抽象层次,例如，需求、设计、实现、部署等,问题空间,需求,-,一个抽象层,设计,-,一个抽象层,实现,-,一个抽象层,部署,-,一个抽象层,特定的,notation,特定的,notation,特定的,notation,特定的,notation,验,证,/,确,认,问题空间,需求,-,一个抽象层,设计,-,一个抽象层,实现,-,一个抽象层,部署,-,一个抽象层,特定的,notation,特定的,notation,特定的,notation,特定的,notation,验,证,/,确,认,它们体现了我们所说的一些软件设计原理,过程途径,实现不同抽象层次的映射,？,？,？,？,？,？,？,？,典型的途径有：,结构化方法,面向数据结构方法,面向对象方法以及,维也纳开发方法（,VDM,）等,注：主要讲解结构化方法和面向对象方法。,RUP,的本质及特点,(1),是一种迭代的、以架构为中心的、用例驱动的软件开发方法,(2),是一种具有明确定义和结构的软件工程过程，包括规定了人员的职责、如何完成各项工作以及何时完成各项工作。还提供了软件开发生命周期的结构，明确定义了主要里程碑和决策的关系,(3),是一个过程产品，提供了可定制的软件工程的过程框架。可以适用于于不同规模的开发团队和规范程度不同的开发方法,RUP,的基本原理,尽早并且不断化解重大的风险,确保满足客户的需求,把注意力放到可执行软件上,尽早在项目中适应变化,在早期确定一个可执行的架构,使用构件构造系统,建立高效的开发团队,突出特点是：,Use Case,驱动的、,以体系结构为中心的、,迭代、增量的开发,.,何谓,USE CASE,驱动,USE CASE,分 析,输入,设 计,实 现,跟踪,输入,跟踪,输入,跟踪,输入,输入,测 试,输入,跟踪,输入,从,USE CASE,模型的视觉,从分析模型的视觉,从设计模型的视觉,从实现模型的视觉,从部署模型的视觉,给 出,体 系 结 构,描,述,何谓,以体系结构为中心,阶 段,核心工作流,何谓,迭代、增量的开发,初始阶段（,the inception phase,）的基本目标是：,-,了解项目的范围,-,建立业务模型,-,得到涉众的认可,换言之，其目标是：建立该项目的生存周期目标,（,objectives,）,精化阶段（,the elaboration phase,）的基本目标是,-,建立体系结构基线,-,捕获大多数的需求,-,降低主要的技术风险,-,减少次要的错误风险，即建立生存周期体系结构,（,the life cycle architecture,）,.,到该阶段末，就能够估算成本、进度，并能详细地,规划构造阶段（,the construction phase,）,。,构造阶段（,the construction phase,）的基本目标是：,-,开发完整的系统,-,确保产品可以开始向客户交付,即具有初始操作能力。,交付阶段（,the transition phase,）的基本目标是：,-,确保有一个实在的产品，发布给用户群。,期间，培训用户如何使用该软件。,注：这,4,个阶段是演化模型的一个变体。,由上可见：,USDP,对于如何运用,UML,的概念进行软件开发提供了详细指导。,即：,指导开发队伍安排其开发活动的次序；,为各开发者和整个开发组指定任务；,明确地规定需要开发的制品；,提供对项目中的制品和活动进行监控与度量的准则。,1,）需求获取的目标,对大系统的开发来说，需求一般包括需求获取和需求分析,需求获取的目标是：, 需求分析的目标是：,客观问题（系统）,系统需求获取模型,形成,-,涉及：不同概念和不同处理逻辑,形成,-,涉及：不同概念和不同处理逻辑,系统分析模型,描述,系统需求获取模型,体系结构描述,-USE CASE,模型,体系结构描述,-Analysis,模型,实现需求获取目标的基本途径,实现,需求获取的目标，即实现,实际问题到软件开发需求获取层的映射，从软件开发的角度,-,实现第一次抽象。其中至少涉及以下,3,个问题：,如何定义需求获取层，即给出该层的术语；,如何确定模型表示工具；,如何映射。,实际问题,需求获取层,模型表示,工具,注：,这些概念体现了一些设计原理,（,1,）需求获取层的术语（概念）,USE CASE,actor,以及,4,个表达关系的概念：关联、包含、扩展、泛化。,以及,USE CASE,图。,实际问题,模型表示,工具,-,USE CASE,图,体系结构描述,-USE CASE,模型,（,2,） 需求工作流,实际问题,？,需求获取模型,-,（,USE CASE,模型）,形成,体系结构描述,-USE CASE,模型,形成,2.1,需求工作流及所创建的制品,一般来说，需求工作流包括以下四步，但它们并非是严格,分离的。,要做的工作,产生的制品,-,列出候选的需求 特征（,Feature,）列表,-,理解系统语境 领域模型或业务模型,-,捕获功能需求,Use case,模型,-,捕获非功能需求 补充需求或针对一些特定需求,的,use cases,特征（,Feature,）,:,一个功能项（,function,item,）以及相关的简要描述,称为特征（,feature,）。作为需求,并被转换为其它制品。,应用系统,潜在的抽象层,例如：,按学科计算每一学生的期末考试平均成绩。,统计,2,科以上不及格的人数。,给出各分段,（,0-60,，,60-85,，,85-100,）,的人数分布情况。,feature,作为需求,被转换为其它制品。,应用系统,潜在的抽象层,（特征层）,一个抽象层,（,USE CASE,层）,USE CASE1,USE CASE,USE CASE2,USE CASE3,制品：,USE CASE,模型,规约,规约,形成,Actor,关联,关于特征的几点说明：,-,每一特征有一个简短的名字和简要的说明或定义。,-,每一特征还有一组对规划有意义的信息，可以包括：,状态（,Status,），例如 ，提交，批准，确认,是组成的等。, 估算的实现成本。,(,所需的资源类型和人,/,时）。, 优先级（,Priority,）,(,e.g.,critical, important, or ancillary,),。, 实现中相联的风险等级。,业务模型或领域模型,领域模型,领域模型捕获了系统语境中的一些重要对象类型。其中领域,对象表示 系统工作环境中存在的事物或发生的事件。,一般来说，领域类以三种形态出现：,业务对象：表示那些被业务所操纵（,manipulate,）的事物,（,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 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,模型,通过,业务,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 unit,是这样实体的一个集合，对最终用户,而言，形成了可认知的整体。,Business entities,和,work unit,用于表达同一类概念，作为,领域类，例如定单，栏目，发票等。,每一个,业务,use case,的细化可以通过交互图和活动图予以,表示。,以,use case,捕获需求,Use-Case,模型,Use-Case,模型 用以表达客户认可的需求,-,系统必须,满足的条件和能力。,Use-Case,模型 作为客户和开发人员之间的一种共识。,Use-Case,模型是一个系统的一种模型，包括,actors,、,use cases,以及它们之间的关系。,Use-Case,system,Use-Case,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 interface prototype,Architecture Description,需求捕获工作流中的活动,1,、发现并描述,Actor,（,1,）,发现,Actor,的方法,发现,actor,的这一任务，依赖于起始点：,-,当存在业务模型时,可以直接地发现一些候选的,actors,，即：,对于业务中的每一个工作人员，可以建议一个候选的,actor,对于每一个将要使用该信息系统的业务,actor,（即每一个业务客户）， 可以建议候选的一个,actor,。,-,当有或没有领域模型时,分析人员就要与客户一起标识,actor,，并将所标识,actor,进行分类，形成,一些候选的,actors,。,Note:,还要标识表示外部系统的,actor,和系统维护和运行所需要的,actor,。,在确定系统,actors,时可用的,2,条准则：,第一条准则：至少要识别出一个用户，可以扮演候选的,actor,。,该准则将帮助我们仅发现那些相关的,actors,，避免,actor,仅是一些想象的,“,事物,”,。,第二条准则：系统中不同,actors,实例之间，其角色的重叠,应是最少的。,如果,2,个或多个,actors,有着几乎相同的角色，那么就应该,考虑：,是否将这些角色组合到一个,actor,的角色中，或,是否需要发现另外一个,“,一般化,”,的,actor,，使之具有那些,重叠的、公共的角色 ，并可以通过,“,泛化,”,，形成那些特,定,actor,。,（,2,）,Actors,的命名与描述,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 Order 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 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 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 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,实例,Withdraw 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,发送消息。,在一个新的状态中，等待,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,模型中，唯一的一类交互可以发生在,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,。, 细化并调整这些暂时的,use cases.,决策,工作人员和业务,actor,的那些任务应该由系统自动地,予以实现，作为,use cases,，并重新组织这些,use case,，更好,地适应,actors,的要求（,needs,） 。,结论：,为参与,业务,use case,细化,（,realization,）的、使用该信息系统的,每一工作人员的 每一角色,，建议一个,use case,。,当开始点没有业务模型时,要通过与客户以及用户一起工作来标识,use case,。其中：,应,一个一个地审阅,actors,为每一个,actor,建议一些侯选的,use case,。,例如，可以与他们进行交谈，研究需要哪些,use case,。,其中，均应根据,actor,的需求来,发现,use case,：,- actor,通常需要,use cases,来支持他们的工作：,创建、改变、跟踪、迁移业务,use cases,中使用的业务对象，,例如定单和帐目。,-actor,可能还要通知系统一些外部事件，包括已经发生的,一些事件，例如：发票已经过期。,-,还可能存在一些其他的,actors,，他们执行系统的启动、终,止和维护。,对发现的候选,use cases,的初始处理：,根据以上发现的那些,侯选的,use cases,， 为了使系统,use cases,容易修改、复审、测试和管理，应考虑它们之间的组成关系。,为每一,use cases,选择一个名字（一般应以动词开始），这个可以引导我们思考其中向,actor,产生值的特定动作序列。用户和系统的一个交互序列，可以在一个,use case,中予以规约，也可以在多个,use case,中予以规约。,当决定把一个侯选的,use case,最终作为系统的一个,use case,时，必须考虑：它是否是完整的 （,complete,）；,它是否是另一,use 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,达到某一目的。,注意：,一个,use case,实例，例如电话呼叫，可能涉及多个,actor.,在这种情况中，应当应用,“,可见的结果值,”,这一准则，启动,actor,（,to,initiating,actor,）,.,“,结果（值）,result of value,”,这一准则，可以帮助我们避免使发现的,use cases,太小。,特定的,actor,(,particular actor),通过使标识的,use cases,都有相应的真实用户，这样可以确保不会太大。,针对一些,actors,我们第一次发现的,use cases,常常需要予以重新组织，重新评估，使之更加,“,稳定,”,。例如，一旦我们已经有了一个体系结构，那么对于我们捕获的新的,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 case 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 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 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,）, 目的,用于决定哪些,use case,在早期的迭代中予以开发（即分析、,设计、实现等），哪些,use case,在后期的迭代中予以开发。, 输入与输出,Architect,Use Case model outlined,Supplementary Requirements,Glossary,Architecture Description,view of the use case model,Prioritized,Use Cases,视角与使用,视角：从,体系结构的视觉，来审视所建立的,use case,模,型。并给出在这一,视觉下的体系结构描述。,（注：其中必须与项目经理一起来工作。）,使用：由该视角形成的体系结构，可以在规划的一个迭代中,针对要开发什么时予以使用。其中，要,注意：,在这,一规划中，还需要考虑其它非技术因素，例如系统,开发的业务和经济方面的因素。,内容：,Use Case,模型视觉下的体系结构描述，刻画了在体,系结构方面具有重要意义的,use cases,。包含：,-,某些重要、关键功能的,use 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 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 case,的动作序列的正文描述。,当所规约的,use case,执行时，事件流还规约了系统怎样与其,actors,进行交互,基本要求,：从管理的角度来说，一个事件流的描述应包括一组动作序列，该组动作序列适于修改、复审、设计、实现和测试，并作为用户手册的一节。,以事件流描述,Use Case,所采用的结构,一个,use case,可以被认为有一个开始状态，一些中间,状态，并从一个状态转换为另一状态，如下所示：,其中，,红箭头线表示基本路径，曲线是其它路径。,当被一个事件（例如一个消息）激发时，每一这样的转,换是该,use-case,的一个实例所执行的一个动作序列。,细化,USE CASE,，即：, 从开始状态到终止状态选择一条完整的基本路径，并在一,节中对该路径予以描述。,其中，这一路径的选择应该是用户认为它是一条最通常的,路径，并对 相关的,actor,产生最明显的值（,the most,obvious value,）。 一般来说，这样的一条路径应该包含系,统不大需要的一些例外和异常处理。,接之，在另一节中描述其余的可选路径,其中，有些可选的路径是很小的，是否可以把它作为基本,路径的组成部分还是在一个独立的一节中作为可选路径予以,描述，这是一个设计决策问题，取决于该描述是否精确，是,否容易阅读。,.,注意：不管我们选择了什么描述技术，都必须描述所有的,可选路径，否则就不能说给出了对该,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 the invoice(s) for payment.,Flow of Events,Basic 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 somehow 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 may 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 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 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 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 money was transferred.,Use Case,描述中的基本内容,一个,use-case,描述中，必须包括：, 定义其开始状态，作为一个前置条件（,recondition,）,.,定义第一个要执行的动作，例如,Step 1,，即描述该,use,case,是如何开始的，什么时候开始。, 定义所要求的次序，即给出其中的动作必须以该次序予以,执行。例中，该次序是通过步骤号予以定义的（,(Step,1-4),）。, 描述该,use case,是如何结束的，什么时候结束（,Step,4,）。, 定义可能的结束状态，作为后置条件（,post conditions,）,.,给出在基本路径描述中的可选路径的描述。, 给出那些基本路径之外的可选路径的描述。,定义与,actors,的系统交互以及它们之间的交换,(Step 2 and,Step 3),，即描述该,use case,动作序列，这些动作是如何被,相关的,actors,予以激发（,invoke,）以及它们是如何执行的，,以响应,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 case,之间的交互可能经过相当多的状态和,状态转换，从而几乎不可能保持正文描述的,use case,的一致,性。,相关的技术,为此，需要使用更结构化的描述技术，这样的技术一般使,用可视化的建模技术，来描述,use cases,。以下技术可以帮助,系统分析人员更好地理解,use cases,：,Browsing,Schedule,Reject,Invoice Scheduled,Pay on due date,Invoice Paid,Invoice Cancelled,The statechart diagram for the Pay Invoice use case showing how an instance of 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,）。,注意,:,在使用这些图当中，由于问题的复杂性，有时可能会出,现一些大的、复杂的图，以至于很难阅读和理解，特别对于,那些不是软件开发人员来说更难阅读。,这些图是一些更接近开发细节的图，应与系统其它模型,保持一致。,建议：,应谨慎地使用这些图，在一般情况下，应采用,use case,的,正文描述（即事件流描述）。,在很多情况中，正文描述和这些图是互补的。,(6),用户界面的原型构造, 目的,建造一个,用户界面的原型，使用户有效地执行,use cases,。,步骤,第一步，用户界面的逻辑设计,第二步，物理用户界面的设计,第三步，开发用户界面原型，演示为了执行该,use,case,，用户怎样使用该系统。,注：如何进行以上三步，可参见有关文献。,(7),Use Case,模型的结构化,前置条件,:,系统分析员已经标识了,actors,和,use cases,已经以,图予以了描述，并给出了整个,use case,模型的说明。,use case,规约人员已经对每一,use case,开发了详细的描述。,做什么,：,抽取,use case,描述中一般的、共享的功能，用于特定,use case,描述。,抽取,use case,描述中附加的或可选的（,additional or,optional,）功能，它们可能被扩展为特定,use case,描述。,使用泛化关系，标识并描述那些共享功能,例如：,Buyer,Seller,Pay Invoice,Pay Invoice,和,Perform Transaction,这,2,个,use case,之间的泛化关系,Perform Transaction,使用,扩展关系，标识并描述附加的或可选的功能,例如：,Buyer,Seller,Pay Invoice,Pay Invoice,和,Pay Overdraft Fee,这,2,个,use cases,之间的扩展关系,extend,Perform Transaction,Pay Overdraft Fee,标识,use case,之间的其它关系,use cases,之间还包括其它关系，例如包含关系（,include,）。,注意,：（,3,点）,在结构化,use case,中应注意以下,3,个问题：, 建立,use cases,的结构和它们的关系，应尽可能地反映,use cases,的实际情况。否则，不论对用户或客户还是对开发人员本身，要理解这些,use cases,以及它们的意图就变得相当困难,.,每一个,use case,都需要被进一步处理为一个特定的制品。有时，,use case,规约人员需要给出它的描述；在后续的分析和设计中，,use case,需要用不同的,use-case,细化（,realization,）予以细化。为此，,use cases,不应太小或太多，从而需要对,use case,结构化工作予以有效地管理。,应避免分解,use case,模型中,use cases,的功能。最好在分析和设计中对每一,use case,进行精化（,refining,）。这一精化，如果需要的话，是以面向对象风格将由,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,requirements 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,system,Use-Case,model,Actor,Use case,*,*,1,The 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 case,，应驱动开发的后,续工作，并实现它们的无缝连接。即在分析阶段和设计阶段，,应标识相匹配的,use-case,细化,（,realization,）,，并标识测试阶段,中的一组测试用例（,test cases,）。,捕获需求阶段的活动,序号,输入,活动,执行者,输出,1,业务模型或领域模型,补充需求,特征表,发现参与者和用况,系统分析员、客户、用户、其他分析员,用况模型,概述,，术语表,2,用况模型,概述,，补充需求，术语表,赋予用况优先级,体系结构设计者,体系结构描述,用况模型角度,3,用况模型,概述,，补充需求，术语表,细化用况,用况描述者,用况,详述,4,用况,详述,，用况模型,概述,，补充需求，术语表,人机接口原型化,人机接口设计者,人机接口原型,5,用况,详述,，用况模型,概述,，补充需求，术语表,构造用况模型,系统分析员,用况模型,详述,2,、 需求分析,实际问题,？,需求获取模型,形成,？,需求分析模型,形成,需求获取,需求分析,注：实现第二次抽象,注：实现第一次抽象,1),需求分析层的术语,分析类（,Analysis class,）,Use Case,细化（,Use Case Realization-Analysis,）,分析包（,Analysis Package,）, 分析类（,Analysis class,）,一个分析类抽象地表达了,系统设计中 的一个或多个类和,/,或子系统。,分析类的基本性质：,分析类关注处理功能需求，而将非功能需求的处理延迟到,以后的设计和实现活动中，并作为类的特殊需求。,分析类很少通过操作和其声明（,signatures,）定义或提,供接口。其行为一般是通过高层的责任予以定义的。一,个责任是高内聚的一组由类所定义的行为的正文描述。,分析类的属性也是在很高层次上定义的。这类属性经常是,