[关键词] UML QFD 需求分析
一、引言
开发软件系统的工作首先便是获取系统需求并进行需求分析，需求分析是软件开发生命周期的第一个阶段，它贯穿于整个开发生命周期，是软件系统开发中的关键问题。但至今需求分析仍是软件系统开发中最复杂、最困难的过程之一。表现在1.需求获取困难。软件需求获取中缺乏领域知识的问题常常是模糊的、不精确的，而需求获取及分析偏向创造性思维活动，其过程让第三者难以理解；2.需求分析不完整。是软件开发失败的主要原因之一；3.需求建模较复杂。在软件需求中混杂着各种各样的需求，功能性需求与非功能性需求错综复杂的联系，以及当前对非功能需求分析建模技术的缺乏都大大增加了需求建模的复杂性。如何有效地分析客户需求并映射到系统设计开发过程，实现系统需求的跟踪管理和控制，是软件系统开发中的重要课题。
针对需求分析中存在的困难，提出了一种基于UML的QFD需求定量分析方法，把UML用例建模应用到软件需求分析中，用作为需求获取和分析过程可视化，以及建立可视化模型的工具，利用QFD客观地使需求项目层次化，可视化和充分化，从而降低需求建模的复杂性。同时给出一个需求分析框架，使该方法具有较强的可操作性。
二、UML需求建模
UML（Unified Modeling Language） 是一种通用的可视化建模语言，它支持从需求分析开始的软件系统开发的全过程。在软件系统需求分析中可通过用例图对系统的需求进行分析建模。UML 作为一种强大的图形化建模语言，是理想的需求描述和建模分析工具，对大规模的、复杂的、不断变化的用户需求有着很强的控制力。
用例（USE CASE）是系统执行的一系列动作，通过这些动作能获得对参与者(Actor，包括客户、用户和开发人员等)有价值的结果。
1.用例与需求的关系。用例体现参与者需要系统完成何种操作，强调实现用户的真正目标，以一种简单而有效的方式表达系统的行为，更体现系统对用户的价值，把需求书写者的注意力从程序员关心的系统功能列表，回到用户需求上。
需求分为业务需求、用户需求、软件需求三个层次，如图1所示。需求工程应该从上向下，从宏观到微观，且循环迭代补充完整。
在UML中，软件需求定义为“系统所需的特性、属性或行为”。软件需求就是系统必须遵循的条件和所具备功能的陈述，它们都是可以观察的外部系统行为规范，它表明了用户或者另一系统要求调用系统必须完成的工作，因此这些需求必须是详细且明确的，同时软件的需求又可以明确地指导系统的实现和测试工作。
用例图关注的是系统功能高层次的形状，而不关注系统的具体实现方法，它着重从用户的角度描述系统功能，适用于系统的需求分析阶段，是系统的核心，驱动着其他模型的开发。
系统所有的参与者和所有用例组成用例模型，用例模型帮助参与者在如何使用系统方面达成共识，参与者在与用例进行交互时使用系统。一张用例图描述部分用例模型，显示带有关联关系的用例和参与者的集合。用例建模得到的功能需求明确规定了参与者执行的特定任务，使用户能清晰看到系统提供的有价值操作，有效地降低待开发系统的复杂度，帮助人们理解复杂的问题。
2.使用用例进行需求分析。在软件需求分析过程中，需求一般可以分为两类：功能需求和非功能需求。功能需求是系统必须能够实现的系统行为，而不需要在条件中加入物理约束，它指定了系统的输入和输出行为；非功能性需求指定了了系统必须具有的其他性质，描述的是系统的特征或者系统的环境特征。
在使用UML进行需求建模时，通过用例图从用户目标和系统交互功能两方面来分析。在软件系统开发的过程中，客户先给了项目组《用户需求书》，其中描述了业务需求和用户需求，主要内容是用户希望的系统功能，然后由需求小组进行需求获取和需求分析。用例将软件需求放在环境中，将功能性需求放入实际操作的用户环境中，当系统与用户或其他系统交互时，可以描述系统的行为。
(1)用例的提取。通过《用户需求书》，对领域内的相关词法进行分析，将用户和客户的需要作为需求，筛选出有效的备选需求，将功能性需求表示为用例模型中的用例，其他的需求放到一个单独的列表中，以待在质量功能展开时进行分析，同时对用例图中的用例进行语义描述。
(2)建立需求用例模型。用例模型是所有用于描述指定系统的用例、参与者和用例―参与者关联关系的组合。在UML中用例模型是这样定义的：用例模型可用于描述系统的功能性需求或者用例的其他分类。在软件开发过程中，使用模型对现实进行简化、概括，从而可以加强对真实构建系统的理解。
通过用例描述发现用例之间的关系，在用例图中描述出来建立用例模型，对用例之间的关系进行可视化的描述，使用户和领域专家能够更好地对系统的需求分析及其建模结果进行审评，及早发现需求的不足，减少系统开发的风险。
3.质量功能展开需求分析。通过UML可视化地表达系统需求的发现与描述，克服了系统需求分析中纯文字性说明的不足之处，体现了直观、规范、易交流等优点，这是需求表达的一种有效手段。在需求分析阶段，还有一个关键的工作在于怎样尽力降低初始阶段的开发费用，加快初始阶段的开发进度。但在系统分析人员缺少相关的领域知识，不熟悉其业务流程的情况下, 提取需求、精确描述需求之间关系、对于需求用例的优先级控制、性能性需求和技术特性需求等问题难以解决。
质量功能展开QFD (Quality Function Deployment)模型也是针对软件系统开发周期各阶段而建立的模型，特别是可对需求和技术特性进行定量需求分析。在系统需求分析中，QFD以用户的需求为输入，采用关系矩阵的方法对用户需求加以描述、迭代展开，将用户需求与技术特性、用户需求的重要性与竞争性联系起来，并把用户的需求转化为技术特性、构件接口和体系框架，从而提高系统需求获取质量和需求分析质量，为从需求到设计的映射打下了好的基础。
质量屋HOQ (House of Quality) 的概念是由美国学者J. R. Hauser和Don Clausing在1988年提出的。质量屋是由一个输入到―个输出的转换过程，它提供了一种将用户需求转化成为技术特性，并配置到建造过程中去的结构方法。QFD采用HOQ建立用户需求和功能特性之间的相互联系，针对需求抽取困难的问题，把QFD应用到系统需求管理中，质量屋矩阵可用作需求获取和分析过程可视化，及构造可视化模型的工具。质量屋的基本结构如图2所示。
一个完整的质量屋包括6个部分:(1)用户需求及重要度：确定了什么才是用户最需要的;（2)技术特性：在需求分析时，由系统项目组根据用户需求来提取出满足这些需求的技术特性；（3）关系矩阵：描述了用户需求和技术特性之间的关系程度；（4）竞争分析：站在用户的角度，对本软件系统在满足用户需求方面进行评估，以确定本系统的竞争优势和劣势以寻找突破性的改进方向和领域;(5)技术评估：技术评估包括技术特性的权重、竞争性评估和设计质量;（6)关联矩阵：表示出了各技术特性之间相互支持或阻碍的关系。
经过反复的质量功能展开，HOQ阵逐渐被整理成层次化结构形式，而软件需求和数据项目也被同时并列地层次化。HOQ矩阵的层次与需求项目的层次相对应，反映了需求的一次水平、二次水平、三次水平等层次关系，并通过技术评估检验需求是否满足要求。
4.基于UML的QFD软件系统需求定量分析过程。基于已建立的初始用例模型，由于领域业务、需求变化的因素可能导致需求分析的演化，即在现有需求分析的基础上进行下一遍的需求分析及建模。基于不同领域知识互补的必要性，以演化的观点来考虑系统的需求分析，项目经理应与参与者共同分析。不同类型的参与者在需求分析建模过程中，从不同的层次、不同的角度分析系统的需求，并通过UML表示出需求。如，需求分析人员主要考虑系统范围的设定；构架设计师必需处理关键和重大的风险，确认那些制定构架计划所需要的用例。经过QFD展开分析定量确定用例的优先级，对于本阶段的目标是无关紧要的用例，只投入少量的精力，同时检验分析的需求是否足够地满足用户的需求。
需求分析及建模需要经过多次反复才能完成，系统需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其他不足的地方。基于UML的QFD软件系统需求定量分析过程包括以下的循环过程：
（1)对领域内的相关词法进行分析，筛选出有效的备选需求；
（2)将功能性需求表示为用例；
(3)建立需求用例模型；
（4)列出用例模型中的功能需求和用户的性能需求；
(5)对每一个需求尽可能量化应该做的工作；
（6)列出用户需求与技术特性之间的关系；
(7)对需求的重要性进行排序，并给出评分；
(8)需求评审，对技术特性相对重要度较低的需求重复上述过程进行修正。
基于UML的QFD软件系统需求定量分析模型如图3所示。
用例作为新的需求分析技术，但若项目组对用例的划分、用例的描述、用例与用例之间的关系把握不好，仍会造成项目的失败。所以在实际工作中，建立用例模型后，为了保证获取正确的需求，应采用关系矩阵的方法加以描述、迭代展开，从而提高需求分析的质量，保证对用例的一致理解，最终获取需求的成功。
本文提出的基于UML的QFD需求定量分析方法已用于通用多媒体播放器的界面设计、超市管理系统的需求分析及中小企业ERP实施规划中，收到了很好的效果。
参考文献:
[1]熊伟新藤久和渡边喜道:软件需求定量分析及其映射的模糊层次分析法[J].软件学报.Vol.16, No.3,2005,16(3) 427～433
[2]黄雨田聂丽琴段富何华军:用例需求分析技术的应用[J].太原理工大学学报.Vol.36, No.2,2005(3)24～27
[3]闫健恩王翠华林建秋王俊义:用例建模在软件需求分析中的应用[J].内蒙古大学学报(自然科学版) Vol.38 No.5，2007（9）578～581
[4]刘渝妍赵卿陈媛:基于UML的老年人口生活质量指标体系框架模型设计[J].重庆工学院学报. 2005(10):20～25
[5]王敏:基于UML的快速原型方法的研究和实现-推理快速生成法IFBM[J].华东师范大学硕士论文2005(10)
[6]刘渝妍杨永发:基于SQFD的软件需求分析技术[J].计算机应用研究增刊2007
[7]邵家骏:质量功能展开[M]．北京：机械工业出版社.2004
关键词：需求分析;用例分析技术;用例模型;参与者
中图分类号：TP311.5 文献标识码：B
文章编号：1004373X(2008)0304803
Application of Use Case Technique in Military Requirement Analysis
WANG Mingqiang,QIAO Bo
(Institute of Command Automation,PLA University of Science and Technology,Nanjing,210007,China)
Abstract：This thesis gives a detail account of the characteristic of the requirement analysis in military software and the superiority of use case technique in the communion between the software developer and the user.It expounds that use case analysis technology contributes to improve the efficiency and the quality of requirement analysis in military software,and it probes into the steps of use case analysis technology modeling,describes an effective method by use case technique about requirement analysis in military software.
Keywords：requirement analysis;use case analysis technology;use case modeling;actor
1 引 言
需求分析是软件开发过程中一个十分重要的环节。需求分析的结果决定了软件系统能否符合用户的要求，也奠定了软件工程和项目管理的基础。在军事软件需求分析阶段，软件开发人员和军事人员都习惯于从自己的角度考虑问题，用自己的专业术语进行沟通，这就使得双方在软件需求方面容易产生误解，影响需求分析结果的正确性。因此，采用什么技术进行需求分析设计，对军事软件需求分析的效率高低和分析结果的正确与否有着直接的影响。
用例分析技术是面向对象的需求分析技术。用例分析技术比传统的需求分析技术更易于被用户所理解，是开发人员和用户之间针对系统需求进行沟通的一个有效手段。使用用例分析技术能够提高需求分析的效率,增强分析过程的科学性，是军事软件需求分析的重要途径。
2 需求分析的概念和任务
需求是计算机应用系统必须为其用户所做的事,是系统必须提供的具体功能、特性、质量,以体现系统存在价值。需求分析一般分为需求获取、分析建模、需求描述3个步骤。软件需求分析的任务是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。他所做的工作是深入描述软件的功能和性能，确定软件设计的边界和软件同其他元素的接口，定义软件的其他有效性要求。
3 军事需求分析的特点
军事软件系统的用户需求是一个十分复杂的问题，系统的成败首先在于他能否满足作战环境和使用软件系统的指挥员和参谋人员的作战需求。满足用户需求是软件系统必须具备的能力，良好的需求描述方法是系统开发的关键。而在军用软件系统需求分析中存在两个重要问题：
需求描述问题一方面，指挥人员由于缺乏使用系统的实践经验，很难把系统需求说得很清楚；另一方面，研制人员对作战指挥的需求缺乏实际体会，而且相当一部分系统开发的技术人员为非军事人员，对军用软件的特殊需要和指挥流程、指挥结构不够明确。
需求管理问题一方面，在系统建设过程中，需求变更会从需求层次起，影响后续的所有工作直至设计实现和检验，需求描述不能满足需求重用的需要；另一方面，需求描述通用性不强，由于多种原因引起的系统设计人员或技术骨干人员的变更，使系统研制的连续性受到破坏，新进入项目研发成员对原需求描述方法掌握需要时间，影响效率。
本文主要目的是针对军事软件系统需求在需求描述和需求管理方面存在的问题，通过运用科学、规范化的描述方法，来直观形象地反映系统需求，力求建立系统分析和软件设计阶段之间的桥梁，使需求描述具有互操作性并使之符合军事软件系统的功能和结构要求。
4 用例分析技术
用例分析技术是一项源于实践的需求分析技术。他通过用例的参与者和用例以及用例之间的关系来描绘系统外在可见的需求，他从外部用户和外部系统的角度，分析和考察系统的行为，把需求与设计完全分离开来，并通过参与者与系统之间的交互关系描述系统对外提供的功能特性。这正好满足了用户的需求,因为他们并不真想了解系统的内部结构和设计,他们所关心的是系统能提供什么样的服务。所以，用例分析技术为解决现代软件需求问题提供了一个有效的解决方案。首先,他描述了待开发系统的功能需求；其次，他将系统看作黑盒，从外部参与者的角度理解系统；第三，他驱动了需求分析之后的各阶段的开发工作。不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段。因此用例分析技术适合军事软件系统需求分析的需要，用例模型在军事需求分析中的作用如图1所示。
图1 用例模型在需求分析中的作用
4.1 用例的概念
用例是系统外在可见的需求，定义参与者如何使用系统。每一个用例描述的是用户需要系统完成的某一个完整的功能，所有的用例共同描述从用户角度看到的系统的完整功能。用例主要有3方面的含义:
(1) 用例通常是由最终用户或外部环境发起的。用例的发起者被称为参与者。参与者是同系统交互的所有事物,例如:人、其他的软件、硬件设备等。
(2) 每个用例只描述单独的任务,而不能描述多个任务。
(3) 用例必须产生一个对用户有意义的结果。
4.2 用例建模
用例建模就是通过分析用户的功能性需求,从而得到用例模型的工作过程。用例建模的主要步骤为:
(1) 确定参与者。
(2) 确定用例。
(3) 撰写用例规约。
4.3 UML中的用例图
用例图是9种UML图之一,他用于描述参与者和用例之间、一个用例和另一个用例之间的关系。用例图的表示法很直观，如图2所示。用例用一个椭圆表示，他的名字可以放在椭圆里也可放在椭圆下面。参与者用一个人形的符号表示，参与者的名字放在参与者图标的下方。参与者和用例之间或用例和用例之间的关联均用直线表示。
图2 用例图
参与者和用例之间或用例和用例之间的基本关联有3种:包含、扩展和泛化。
包含一个用例中重用另一个用例的关系，在用例图中使用带箭头的虚线表示,箭头指向被包含的用例，同时在线上加上用双尖括号扩起的“include”。
扩展表示一个特殊用例扩展原有的用例。他的表示与包含相似，不同的是箭头指向原用例且用“extend”标识。
泛化指一个用例继承了另一个用例，参与者之间也可能有泛化关系。泛化可用实线加上空心箭头表示,箭头指向父用例或父参与者。
5 军事系统用例建模方法
5.1 确定参与者
在军事软件需求分析中，应该由军事专家、军事系统使用人员、建模专家、建模工程师四类角色参与。军事专家具备丰富的军事知识，熟悉军事体系结构和军事软件应用背景，对系统设计的总体有效性和正确性进行验证；军事系统使用人员熟悉军事软件具体应用的作战指挥环境和具体指挥应用要求，提出系统具体的细节；建模专家应熟悉系统开发方法，并且有丰富的建模经验，能针对军事系统的特点，提出需求分析的指导原则、实施方案、需求建模的文档规范，并对需求分析及建模的进度实施必要的控制；建模工程师应熟悉具体建模方法和丰富的建模领域知识，同时具备技术实现领域知识，能够和技术实现人员良好的沟通，在建模专家的指导下充分挖掘需求、并提出一些初步的方案，形成最终的需求分析文档。在需求分析过程中,由于建模专家、建模工程师同军事人员的知识领域的差异,他们在同一个问题上常常有两种完全不同的理解。所以最终的用例模型是军事人员与软件工程人员之间反复交互的结果，也是军事人员和技术实现人员交流的桥梁。
5.2 确定基本用例模型
这个阶段主要任务是由军事专家、军事系统使用人员同建模人员进行充分的沟通,以清晰的方式表述客户的需求。为便于军事人员对需求分析结果正确性的确认,在这个阶段对模型的描述主要采用自然语言和图形为主。首先使用业务流程图对业务流程进行建模。业务流程图是需求分析中经常使用的一种非结构化工具，由于业务流程图是使用人员业务的再现，所以军事人员能够清晰正确地理解并利用他充分表达自己的意见,和建模人员形成一致的认识。业务流程图直观和易于理解的优点在需求分析过程中具有显而易见的优势，军事人员可以向建模人员清楚地表达业务流程图主要描述的作战指挥方式、指挥流程、指挥手段、指挥机构组成、指挥人员编制等军事需求。我们可以得到一个清晰的、能同时被建模人员和军事人员正确理解的基本模型,这个模型是构造用例模型的基础。
5.3 细化用例模型
基本用例描述了系统外部的参与者要实现的目标，只反映用户需求而不干涉系统应提供具体功能细节，为获得这些功能细节，以便于软件构架的建立和将来的设计和实现工作，就要将用例细化。在需求模型建立后，系统分析员就可以以需求模型和用例图作为起始点详细描述每个用例，并将每个用例逐步描述细化为精确动作序列的分析模型。
细化每个用例的主要任务是详细描述其事件流。事件流是描述参与者执行用例过程中发生的各种交互的序列，包括用例如何开始、结束以及如何与参与者进行交互。事件通常会形成两种路径: 一种是参与者顺利达成目标的基本路径称为基本流，另一种是反映可选或异常情况行为的备选路径，称之为备选流。
基本流描述的是该用例最正常的一种场景,在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。基本流的描述格式为：
(1) 每一个步骤都需要用数字编号清楚地标明步骤的先后顺序。
(2) 用一句简短的标题来概括每一步骤的主要内容，这样可以通过浏览标题来了解用例的主要步骤。
(3) 当整个用例模型基本稳定之后，再针对每一步骤详细描述参与者和系统之间所发生的交互。每一步骤都需要从正反两个方面来描述，既参与者向系统提交了什么信息和系统对此的响应。
备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素：
(1) 起点：该备选流从事件流的哪一步开始；
(2) 条件：在什么条件下会触发该备选流；
(3) 动作：系统在该备选流下会采取哪些动作；
(4) 恢复：该备选流结束之后，该用例应如何继续执行。
参与者要完成用例,必须通过整条基本路径，而备选路径则不一定会通过。需要时可先确定用例的基本路径和关键的备选路径，在以后的迭代中再增加其他的备选路径。此外,在细化用例时还应指出用例的前提条件和后置条件。前提条件指调用用例时必须满足的条件,后置条件指用例结束时必须满足的条件。
细化后的用例描述内容：
参与者：与系统发生交互的人或其他系统；
用例名：表明主角通过他的交互能达到什么目的；
简明描述：简要说明系统实现的功能和方式；
事件流程：是用例的核心，对参与者的操作以及系统的响应的文本描述。
备选事件流：系统对非主事件流状态下，对参与者操作的响应。
前置条件：用例开始之前需要满足的系统状态和环境条件；
后置条件：用例结束后系统可能处于的状态；
特殊需求：主要定义可靠性、可用性、性能等非功能需求。
5.4 建立测试模型
“用例技术的最大好处就是他构建了一组可用来驱动测试过程的资产”。用例可以直接派生测试用例的开发，用例的场景为单个测试用例创建模板，增加数据值将完成测试用例，最后测试非功能性要求来完成对软件的测试。测试用例的过程为：
(1) 确定用例的场景；
(2) 对每个场景，确定一个或多个测试用例；
(3) 对每个测试用例，确定让他执行的条件；
(4) 增加数据值来完成测试用例。
图3 跟踪用例到测试用例
图4 跟踪用例到测试用例场景
6 结 语
用例模型用于需求分析阶段，描述待开发系统的功能需求，驱动需求分析之后各阶段的开发工作。用例分析技术运用文字和标准的图形来描述用户需求，易于开发人员和客户之间交流、沟通和理解并精确地定义软件需求，保证开发人员和客户之间对需求理解的一致性。因此，用例分析技术有助于提高军事系统需求分析的效率和质量，在整个软件项目开发过程中起着非常重要的作用。
参考文献
[1]Dean Leffingwell,Don Widrig.Managing Software Requirements:A Use Case Approach[M].Second Edition.Dean Leffingwell,2004.
[2]Suzanne Robertson,James Robertson.Mastering the Requirements Process[M].Addison Wesley,2003.
[3]Daryl Kulak,Eamonn Guiney.Use Cases Requirements in Context[M].Second Edition.Addison Wesley,2004.
[4]王建军.UML建模:实例分析[J].微计算机信息,2002(5):66―68.
[5]王晶,雷光秀.一种构造用例模型的方法研究[J].新疆石油天然气,2005,23(4):158―159.
作者简介 王明强 男，1979年出生，黑龙江双鸭山人，硕士研究生。主要研究方向为指挥自动化理论、软件工程。
《网络安全技术》是计算机网络技术专业的核心专业课程，实践性与理论性并重，对专业知识综合运用能力也有较高要求。然而采用“教师主动，学生被动”的传统教学模式教学，教学效果差，学生“知其然，不知其所以然”。在《网络安全技术》课程中打破传统教学模式，以案例作为课程导入，将内容融入项目，做到课堂与实际应用无缝对接，取得了不错的教学效果。特提出“案例项目制”的教学方法。
传统教学模式的不足
教学方法单一。传统教学模式采用“被动式教学”，师讲，学生听；教师演示，学生模仿。课程以理论知识讲解为起点，辅以教师通过实验演示来验证知识结果。课堂缺乏互动，学生将主要精力放在如何模仿教师的实验演示上，留给学生自我分析的空间不足，导致学生灵活运用知识的能力和创新能力不够。
课堂与实际应用衔接不够。传统教学模式中，没有很好地将知识融入实际应用。实验安排过于理论化，教师往往就某个知识点安排实验，导致学生学习后，该如何应用于实际。
实践考核方式落后。《网络安全技术》课程是综合性较强的课程，重点是考察和锻炼学生对专业知识的综合掌握和运用能力。而传统的考核方式往往是老师绘制一个拓扑结构图，甚至规划出网络参数，提出所需实现的功能，学生按照拓扑结构图搭建环境，根据功能要求进行实施。没有给学生留出足够的思考空间，不利于规划、设计、实施网络等能力的锻炼。
“案例项目制”教学方法
“案例项目制”教学法，可细分为“案例教学”“项目制实施”两部分。“案例教学”是教师根据教学内容安排，设计典型案例。通过对案例的分析，导入授课内容，是引导学生分析、解决问题的一种启发式、贴近实战的教学方法。“项目制实施”教学法，是以典型项目为实践教学对象，将知识融入项目，以项目组的方式具体实施。学生围绕项目需求，对网络进行规划、设计，并在实验环境下进行实施。“项目实施”教学方法主要应用于实验考核，它抛弃了传统考核模式，没有具体的技术暗示与限制。这对于学生思维的扩展和综合运用能力的锻炼都非常有好处。如图1所示：“案例项目制”教学方法的实施流程。
案例教学。“案例教学”方法在课堂开始就实施，教师给出一个具体的应用案例情景，引导学生对应用案例情境进行分析，提出解决问题的办法。通过解决办法引出当天课程内容，然后围绕内容开始理论分析与讲解。理论讲解完成，教师将所引案例通过实验模拟出来，最后让学生练习，教师辅以指导。
项目制实施。“项目制实施”是针对实践考核环节。每一次实践考核就是一次真实项目模拟，做到实践考核和实际应用的无缝对接。教师将学生分为项目组，每一项目组模拟一个公司，教师给出一个全新案例，教师只提需求，至于如何绘制拓扑结构图、网络参数如何规划、采用何种技术实现需求等，教师不做任何技术限制和技术暗示。充分给予学生思考空间，锻炼学生分析、规划、设计网络的能力。
“案例项目制”教学方法举例
以《网络安全技术》中的“网络地址转换NAT”为例，分析如何在课程中使用“案例项目制”的教学方法。
案例分析
给出案例。上课开始，教师给出案例：XX公司购进30台电脑，需要搭建公司内部网络，以方便公司办公和相关业务开展。具体需求为：需求1：实现公司内部通信；需求2：由于业务原因，公司员工需要经常访问internet。请在先进性、低成本的条件下为该公司网络进行规划、设计并实施。
需求分析。（1）分析1：目前企业构建内部网络，可采用私有IP地址。私有IP地址的使用无需向IANA申请，也无需付费，既能满足用户经济性的要求，又能满足用户内部通信需求。因此为公司分配私有IP网段：192.168.10.0/24。（2）分析2：由于在需求1中采用私有IP地址构建公司网络。但私有IP地址在Internet上无合法路由，无法直接在Internet上使用。为了满足用户需求2的要求，必须采用“网络地址转换”NAT技术，将内部私有地址转换为公有地址，以公有地址的身份访问外部网络。
导入知识
通过对XX公司网络需求进行分析，得出需要采用“网络地址转换”NAT技术满足用户需求的结论。
知识讲解
知识导入以后，此时教师就围绕“网络地址转换”NAT技术进行理论知识分析和讲解。
实验演示
理论讲解完毕，教师根据之前所提案例需求，规划网络，绘制出详细实验拓扑结构图，如图3所示。并在实验环境下演示实验。
学生实验
教师演示完实验，要求学生进行练习。在练习过程中，老师现场辅导。
实践考核
实践考核以案例和项目制方式进行，教师给一个案例，提出具体需求，要求学生能自我规划、设计并实施网络。
考核案例：xx公司有四个部门：市场部、产品部、人事部、技术部。现需要设计网络，具体网络需求为：需求1：网络具有高可用性、安全性、可管理性，要求每个部门处于单独网段；需求2：各部门之间能实现相互通信；需求3：每个部门都能访问Internet。请认真分析XX公司网络需求，并进行规划、设计并实施。
关键词:需求获取;UML;用例驱动;B方法;形式化需求
中图分类号:TP309文献标识码:A
文章编号:1004-373X(2009)12-045-04
Case Study of Acquiring Formal Software Requirement
ZOU Shengrong,PENG Yujing,GUO Zhongwei,LIU Chunqiu,ZHOU Ta,WEI Li,GU Aihua
(Information Engineering College,Yangzhou University,Yangzhou,225009,China)
Abstract:Acquiring software requirement is the basis of software modeling and analysis,traditional software requirement modeling has two important defects:one is informal requirements description often leads toambiguity and inconsistency of requirements,so it is difficult to validate and verificate;and the other is variability.According to the above problems,this paper presents the use case driven analysis method of software requirements by Unitied Modeling Language(UML),and describes it by formal method,relizes formal software requirement.Practice proves that acquiring software requirement of use case driven can obtain effectively correct and reasonable software requirement,in addition to requirement description of formal B method.This method effectively avoids the above problems.
Keywords:requirement acquirement;UML;use case driven;B method;formal requirement
0 引 言
随着计算机技术的发展,软件规模日益庞大,软件开发也日益复杂。随之而来的问题是许多IT系统都无法实现期望,它们要么无法实现业务目标,要么无法有效支持用户任务,要么成本很难控制在预算之内。究其原因,相当多的软件失败是因为需求不明白或者不确定而致。自1991年J.Martin提出“需求工程”[1] 概念后,需求分析作为软件工程的一个重要阶段开始形成一门独立学科,称为需求工程。软件需求的重要性正在不断提高,因为它是用户预先知道将以什么样的成本,获得什么样产品的途径。
需求工程在软件系统开发中的重要性已不容置疑。需求的获取是需求工程的主体,是软件系统开发过程中最为困难,也是最为重要的部分。只有真正满足用户需求的软件产品才能为用户接受,不能满足用户需求的产品,不管采用了多么先进的技术,对用户来说都是毫无用处的。根据Leffingwell 在1997 年的研究,软件项目中40%～60%的问题都是在需求的获取和分析阶段埋下了祸根[2]。在过去几年,文献主要强调需求建模和规约方法,现在重点转移到了软件需求获取的有效方法。
传统的需求分析过程通常采用数据流图等方式来描述系统的逻辑模型。由于这些非形式化以及半形式化方法所需求的描述都未给出数学意义上严格的语法和语义说明,因此需求阶段建立的模型或多或少的带有不精确性、不完全性和不一致性。形式化方法(Formal Methods)是全面系统地使用基于数学的语言、技术和工具,精确地说明、开发和验证的软件系统,使用形式化方法描述的规约具有规范性和无二义性,而且形式化语言是一种机器可处理的描述语言,可以保证软件复用自动化成为可能。
1 用例驱动的需求获取
1.1 用例模型
用例模型是系统既定功能和系统环境的模型,它可以作为客户和开发人员之间的契约。系统建模有许多种方法,每种建模方法,均可满足不同的目的。然而,用例模型最重要的作用是将系统行为传达给客户或最终用户,因此模型必须易于理解。用例模型驱动了需求分析之后开发工作的各个阶段和UML的各个模型。
用例模型采用若干个用例图描述。用例图是一个参与者和用例以及另外的定义和说明的可视化表示。用例图不仅是一个图,而且是系统想要的行为的全文档化模型[3-5]。
1.2 用例
用例表示一个完整的给用户传值的功能性单元。用例是系统和用户之间的动作序列,而不是逐条的个体需求。显著的用例改进了这一问题。现在,需求是用例的形式,需求以顺序的方式提供系统的行为,以相关的替换和异常信息结束。用例只说明了系统要做什么,而且在设计上领先,因为它对于收集需求和开始设计过程都非常便利。
1.3 参与者
参与者和用例从功能需求的分析中就确定了,功能需求具体化为用例,用例通过给参与者提供某个值的结果来满足功能需求。业务分析员是选择首先表识参与者,然后再表识用例或者相反。
1.4 用例关系
用例描述的是系统外部可见的行为,是系统为某一个或几个参与者提供的一段完整服务[4]。从原则上来讲,用例之间都是并列的,它们之间并不存在包含的从属关系,但是从保证用例模型的可维护性和一致性角度来看,可以在用例之间抽象出包含(include)、扩展(extend)和泛化 (generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息,然后通过不同的方法重用这部分公共信息,以减少模型维护的工作量。
1.5 案例分析
这里分析一个体液免疫的实例。体液免疫是由B细胞介导的免疫应答。体液免疫可由胸腺依懒性抗原(TD)和非胸腺依懒性抗原(TI)诱发。这里讨论由TD诱发的体液免疫。
TD诱发的体液免疫必须要有抗原递呈细胞APC(Antigen Presenting Cell) 和辅助T细胞(TH细胞)。TD诱发的体液免疫过程大致如下:当抗原侵入机体内时,抗原递呈细胞识别抗原,并处理和递呈抗原状决定族给辅助T细胞;辅助T细胞识别抗原状决定族,然后把抗原状决定族传递给B细胞,辅助T细胞自身活化,增殖分化成效应T细胞;B细胞接受来自辅助T细胞的抗原状决定族,活化并增殖分化为效应B细胞和记忆细胞;效应B细胞产生抗体,当同种抗原再次进入机体时,记忆B细胞便分化成大量的效应B细胞,进而使抗体与抗原结合,抗体将抗原杀死[6]。
分析上述体液免疫的过程,可以把该软件系统需要实现的功能归结为以下几个问题:
(1)抗原入侵机体;
(2) 抗原递呈细胞摄取抗原;
(3) 抗原递呈细胞处理抗原;
(4) 抗原递呈细胞递呈抗原状决定族给辅助T细胞;
(5) 辅助T细胞识别来自抗原递呈细胞传递的抗原;
(6) 辅助T细胞传递抗原决定簇给B细胞;
(7) 辅助T细胞增殖、分化形成效应T细胞;
(8) B细胞接受辅助T细胞的抗原决定簇;
(9) B细胞增殖、分化形成记忆B细胞;
(10) B细胞增殖、分化形成效应B细胞;
(11) 效应B细胞产生抗体;
(12) 记忆B细胞记忆抗原;
(13)同一种抗原再次进入B机体,记忆B细胞增殖分化成大量的效应B细胞;
(14) 抗体和抗原结合杀灭抗原。
根据上述这些问题,可以把所涉及的操作归结为:入侵、识别、摄取、处理、传递、活化、增殖分化、产生、记忆、结合并杀灭这几个方面。根据这些分析结果,可以创建以下用例:入侵(Intrusion);摄取(Inhale);处理(Processing);传递(Present);活化(Activation);增殖分化(Proliferation and Differentiation);产生(Produce);记忆(Memory);识别(Recognition);结合并杀灭(Binding and Kill)。
根据上述分析,系统的参与者分别为抗原递呈细胞(APC);辅助T细胞(TH);B细胞(B);抗原(antigen);记忆B细胞(memory B cell);效应B细胞(effect B cell);抗体(antibody)。
根据上述分析,可以画出图1所示的体液免疫用例图。
图1 体液免疫用例图
这里采用顺序图建立对象间的动态交互的模型。
由TD介导的体液免疫过程已在上面详细描述,由于篇幅限制,体液免疫的顺序图不再列出,但是它的形式化描述将在下面介绍。
2 形式化需求
2.1 形式化B方法的介绍
B方法是形式化方法之一。B方法以规格说明语言的研究为背景,在引入一些面向对象机制等特点的同时,保留了语言的优点。B方法使用相对简单且运用人们熟悉的符号表示法广义代换表达状态的转换,从软件的规格说明到编码的形成是一致的形式描述,使程序和程序的规格说明处于统一的数学框架之下,以一种基于集合论的符号表示法来书写,减少了出现语义错误的可能性。这种数学框架是通过谓词变换和扩展的最弱前置条件为前提的[6,7]。
B包含一种AMN的结构化机制,AMN是B方法中的一种基本封装机制,非常接近人们在程序设计中所熟知的一些概念,如类(SIMULA)、抽象数据结构(CLUE)、模块(MODULA-2)、包(ADA)、对象(EIFFEL)等概念[8,9]。
AMN中有赋值和条件语句,也有前置条件、多重赋值、约束选择、卫、无约束选择。AMN中没有定序和循环,理解AMN的根据是状态及改变状态的操作,即包括静态和动态分析。静态对应状态的定义,动态对应其操作[10]。
下面通过论述的实例来获得体液免疫形式化B的需求。
2.2 用B形式化需求
根据上述用例图,定义如下转换规则[11]:
(1) 所有的参与者用枚举集合来表示,并把相应的变量、不变式等封装在参与者的机器里;
(2) 所有的用例用枚举集合来表示,并把相应的变量、不变式等封装在参与者的机器里;
(3) 参与者与用例的关联关系用二元关系组成的枚举集合来表示,并把相应的变量、不变式等封装在关联关系的机器里。
因为在本例里,没有参与者与用例的关联关系,所以不在此列出,方法类似规则(2)。根据以上规则,得出参与者与用例关联关系的机器如下:
MACHINE
Association
SETS
ACTOR={Antigen,antibody,TH,B,APC,effect T,effect B,memory B};
USECASE={instrusion,present,processing,recognition,inhale,activation,proliferate,differentiate,producce,memory,bind and kill};
ASSOCIATION={(Antigen,intrusion),(APC,inhale),(APC,present)(APC,processing),(TH,recognition),(TH,present),(TH,activation),(TH,proliferate),(TH,differentiate),(B,recognition),(B,activation ),(B,proliferate ),(B,differentiate ),(effect B,produce),(memory B,memory),(memory B,proliferate),(memory B,differentiate),(antibody,bind and kill)}
VIRIABLES
actor,usecase,association
INVARIANT
actor∈ACTOR∧
usecase∈USECASE∧
association∈ASSOCIATION
INITIALIZATION
actor,usecase,association:={},{},{}
OPERATIONS
…
END
这样就可以把参与者与用例之间的关系用形式化B的语言表示出来,而参与者机器和用例机器在这里不一一列出。
下面再来看如何把顺序图转换成形式化B的语言,定义以下几个规则:
把顺序图中的对象用枚举集合来表示;
把顺序图中对象之间的操作名用枚举集合来表示;
把顺序图中对象之间的操作顺序用枚举集合来表示;
定义常量并对其设置前置条件;
定义变量并对变量设置不变式;
根据转换规则,得到顺序图形式化B的机器表示形式如下:
MACHINE
ImmuneResponse
SETS
OBJECT={ Antigen,antibody,TH,B,APC,effect T,effect B,memory B };
MESSAGE={ instrusion,present,processing,recognition,inhale,activation,proliferate,differentiate,producce,memory,bind and kill };
MSGID={m1,m2,m3,m4,m5,m6,m7,m8,m9,m10,m11,m12,m13,m14,m15,m16}
CONSTANTS
ID_max
PROPERIES
ID_max∈NAT1
VARIABLES
object,msgid,msg,sequence
INVARIANT
object∈OBJECT∧msg∈objectMESSAGE∧
msgid∈objectMSGID∧
sequence∈sequence(MSGID)
INITIALIZATION
object,msg,msgid,sequence:= {},{},{},{}
OPERATIONS
Sequence(i1)
PRE i1∈ MESSAGEmsgid∧ i1>=msgid
THEN sequence:=sequence(msgid)
END
END
这里得到了形式化B的规格说明,避免非形式化需求描述的歧义性,并且形式化的规则说明易于验证前后的一致性等问题。
3 结 语
采用基于用例建模的方法进行需求获取。该方法的主要好处是以用户为中心,用例方法可以使用户更清楚地认识到新系统允许他们做什么。把用例建模获取的需求变成形式化B的描述方法,形式化的需求具有无歧义、精确性等优点,能提高规格说明的正确性。下一步的工作就是用B方法的证明技术来验证机器,并将其精化、程序实现。
参考文献
[1]Zave P.Classification of Research Efforts in Requirements Engineering[J].ACM Computing Surveys,1997,29(4):315-321.
[2]WIegers K E.软件需求[M].陆莉娜,译.北京:机械工业出版社,2000.
[3]F Martin.UML精粹[M].2版.徐家福,译.北京:清华大学出版社,2002.
[4]汤小康,王志刚,曹步文.UML用例图的Z形式规范[J].计算机与现代化,2006(11):12-13,16.
[5]范晓平.UML建模实例详解[M].北京:清华大学出版社,2005.
[6]陈慰峰.医学免疫学[M].4版.北京:人民卫生出版社,2007.
[7]裘宗燕.B方法[M].北京:电子工业出版社,2004.
[8]邹盛荣,阳雪平,郭峰,等.免疫因子网络的Immune-B模型设计[J].吉首大学学报:自然科学版,2006,27(3):27-32.
[9]Zou Shengrong.Modeling Distributed Algorithm Using B[A].Proceeding of the International Grid and Cooperative Computing Conference[C].2004:683-689.
例1如图，已知: AC=2BC，M是AB的中点，MC=6，求AB的长.
分析与解图中只有一条线段MC=6是已知，这时想从这一条线段出发求出其他的线段则不太容易.考虑设其中一条未知线段为x，利用题中的等量关系用含x的代数式表示其他的未知线段，然后立方程求解.如设AM=MB=x，则AC=x+6，BC=x-6，又AC=2BC，所以x+6=2（x-6），解之，得x=18，则AB=AC+BC=24+12=36.
例2如图，AB与CD相交于点O，OF平分∠EOB，OB平分∠COF，若∠DOE=39°，求∠AOE的度数.
分析与解图中只有一个角∠DOE=39°是已知的，其余的都是未知的，这时考虑设其中一个未知的角的度数为x，用含x的代数式表示其他的未知的角，然后立方程求解.如设∠COB=∠BOF=∠FOE=x，则∠AOD=∠BOC=x，则∠AOE=∠AOD-∠DOE=x-39°，又∠AOE+∠EOF+∠FOB=180°，所以x-39°+x+x=180°，解之得x=73°，所以∠AOE=x-39°=34°.
例3如图，ABC中，AB=AC，BD=BC，AD=DE=EB，求∠A的度数.
分析与解本题中没有一个角的度数是知道的，但是角与角之间却隐藏着众多的关系：如三角形的内角和是180°，等腰三角形的两个底角相等，三角形的一个外角等于不相邻的两个内角之和等.可设∠DBE=x，则∠EDB=∠DBE=x，又∠DEA=∠EDB+∠DBE=2x，则∠A=∠DEA=2x，又∠CDB=∠A+∠DBE=3x，则∠C=∠CDB=3x，又∠ABC=∠C=3x，则在ABC中，∠C+∠A+∠ABC=180°，则3x+2x+3x=180，则x=22.5°，所以∠A= 2x=45°.
评析从上面的三例可以看出，当题目中的未知量较多时，可以考虑设其中一个用字母表示，然后尽量挖掘题目条件中的等量关系，用含字母的代数式表示出其他的未知量，最后列方程解决问题.这样使解题过程显得一目了然，这就是字母表示数的一大魅力.
例4如图，已知：∠AOB=90°，∠AOC是锐角，ON平分∠AOC，OM平分∠BOC，求∠MON.
分析与解分析本题的条件可以发现：若知道∠AOC的度数就好了.这时设∠AOC=2x，则∠AON=∠CON=x，又∠MOC=∠MOB=（∠AOB+∠AOC）=（2x+90°）=45°+x，又∠MON=∠MOC-∠CON=45°+x-x=45°.
这真是个热心肠的字母，需要的时候来帮你一下，当你不需要的时候就自觉的离去.另外，其实∠MON的度数与∠AOC的度数无关，只与∠AOB的度数有关，你能发现它们之间的关系吗？
例5如图，AB=8cm，M是AC的中点，N是BC的中点，求MN.
分析与解与例3类似，若知道BC的长就好了.设BC=2x，则BN=NC=x，则AM=MC=（AB+BC）= （8+2x）=4+x，所以MN=MC-NC=4+x-x=4.和例3一样的效果.
例6如图，在ABC中，AB=AC，D是BC上的一点，∠BAD=40°，E是AC上的一点，AE=AD，求∠EDC的度数.
分析与解直接由∠BAD=40°来求出其他的角的度数是不太容易的，可先设∠EDC=x，∠B=y，则∠B=∠C=y，又∠AED=∠EDC+∠C=x+y，则∠ADE=∠AED=x+y，所以∠ADC=∠ADE+∠EDC=2x+y，又∠ADC=∠BAD+∠B=40°+y，所以2x+y=40°+y，得x=20°，∠EDC=20°
评析我们发现在用字母表示某个未知的角或线段后，计算过程显得特别的顺手.和例1与例2不同的是：例3与例4中所设的字母在计算到最后时却主动的消失了，在你需要它时它帮你，不需要时就自动的消失，这不是很神奇吗？这是字母表示数的另一神奇魅力.
[关键词] 统一建模语言 管理系统 建模 应用
一、引言
统一建模语言UML(Unified Modeling Language)是一种用于描述、视化和构架软件系统以及商业建模的语言。它提供了多种基本的模型图,并通过对这些图的综合运用来全面刻画整个系统的全貌。UML符号表示法为开发者使用这些图形符号和文本语法进行系统建模提供了标准,具体可分为5大类,9种图形。5大类分别是用例图、静态图、行为图、交互图和实现图。静态图包括类图和对象图,用来描述静态关系;行为图包括状态图和活动图,用来描述系统的动态模型和组成对象之间的交互关系；交互图包括协作图和顺序图,用来描述对象间的交互关系；实现图包括组件图和配置图,分别用来描述代码组件的物理结构以及系统中软硬件的物理体系结构。
二、基于UML 的系统开发过程
UML是一种建模语言而不是方法，UML本身独立于过程，使用UML进行开发时，仍有统一的过程框架。UML的开发过程是一种柔性开发过程，即在需求牵引下，自顶向下分层细化地建模，然后通过对模型的虚拟执行，由底向上地逐层上移修改，直至各层的模型结果都满足需求为止。
系统的开发过程包括需求定义、分析、设计、实现几个阶段。需求定义阶段建立系统的需求模型，分析阶段建立系统的分析模型，这两个模型是系统设计和实现的基础。
建立系统需求模型包括:
1.问题陈述。根据用户初始需求，在用户帮助下，写出问题陈述；
2.定义参与者(Actor)。在用户参与下定义系统的参与者；
3.建立GUI界面原型。在用户参与下，用可视化编程工具为每个参与者建立GUI界面原型；
4.定义用例。观察参与者与界面原型的交互过程，导出用例。建立系统分析模型主要包括:
(1)静态建模。根据问题陈述和用例，对系统的静态结构建模，静态模型可以用类图表示，它概要地描绘了问题域对象类，同时也表示出这些类的基本属性和类间的关系。
(2)动态建模。根据用例及静态模型进行动态建模，动态模型可用顺序图、合作图、状态图等表示。动态模型表达了系统的动态特征。
下面以集装箱管理系统的开发实例阐述如何利用UML 建立系统的需求模型和分析模型。
三、建立CFS 业务信息系统的需求模型
1.问题描述
CFS是集装箱货运站（CONTAINER FREIGHT STATION）的缩写，是处理拼箱货的场所,它的主要业务分成两大块，即进口货拆箱业务和出口货装箱业务。在进口货拆箱业务中，货主或其先将记录着集装箱装货信息的箱单送到货运站，申明有重箱(即装有进口货的集装箱)要送来拆箱。在其后的某一时间，重箱由某车队送到货运站，货运站马上根据箱单进行拆箱操作，通常，拆出的货物还要放入仓库的跺位中，空箱子由车队及时拉走送到另外的堆箱场地(即集装箱堆场)。以后，收货人来提货时货运站再从跺位中取出货物交给收货人。在出口货装箱业务中，货主或其先发出装箱委托(假定都是整箱货委托)。其后，货到时，就将货放入分配给该委托单位的垛位。此后的某一时间，进行配积载并实施装箱。最后，重箱交给车队送往港区。由于拆装箱是货运站的主要业务，仓库存放货物是辅动作，为了加快周转，在货运站仓库堆放货物，有个免费仓期问题。
2.参与者与用例分析
首先，确定了系统的两个参与者(Actor)，即仓库管理员和仓库主管。通过为他们建立系统界面原型，观察他们与界面交互的过程，可以分析出每个参与者使用的用例。所谓用例就是参与者与系统的一次对话中所执行的一系列相关事务序列。系统中各用例间及用例和参与者间的关系可由例图表示，本系统的用例图(部分)如图1所示。
用例图只是表达了用例间及用例和参与者间的关系，我们还必须文档化每个用例的具体内容。集装箱货运站系统各用例描述如下:
(1)拆箱受理。仓库管理员收到客户拆箱委托时执行本用例。①仓库管理员创建新的拆箱委托单；②仓库管理员填写委托信息。如发货人和收货人名称、提单号、箱号、受理日期、计划拆箱日期、货物信息(包括货类、货物描述、数量、单位等)。系统自动生成委托号。③系统标记委托单状态为“受理”。
(2)重箱进场。本用例从客户将重箱送进场时开始。①仓库管理员调出拆箱委托单，输入重箱进场日期；②系统标记委托单状态为“已进场”。
(3)预分配垛位。仓库管理员受理拆箱委托后，可以根据情况在重箱进场前或重箱进场后但尚未拆箱时为该笔委托单预分配一个垛位。①仓库管理员查询垛位状态图；②仓库管理员为拆箱委托单预分配一个空垛位；③系统标记该垛位为“锁定”状态；④系统标记委托单状态为“预分配”。若分配的垛位不处于“空闲”状态，则系统拒绝接受预分配垛位操作。
(4)拆箱入垛。在已为拆箱委托单预分配垛位并且重箱进场后，可以执行拆箱入垛用例。①仓库管理员调出拆箱委托单；②仓库管理员执行拆箱入垛操作；③系统标记该垛位为“占用”状态；④系统标记委托单状态为“已入垛”。
(5)货物交出。当将垛位的货物提出交给客户时,执行本用例。①仓库管理员调出拆箱委托单，执行货物交出操作，输入交货日期；②系统标记该垛位为“空闲”状态；③系统标记委托单状态为“已交货”。以上为进口拆箱业务用到的用例。出口装箱业务用到的用例包括如下几个用例(为简明起见，不再详细描述各用例的具体内容)。
(6)装箱受理。仓库管理员收到客户装箱委托时执行本用例。
(7)预分配垛位。仓库管理员根据情况在适当时间为该笔装箱委托单预分配一个垛位。若分配的垛位不处于“空闲”状态，则系统拒绝接受预分配垛位操作。
(8)收货入垛。仓库管理员收到客户的货物并且已为装箱委托单预分配一个垛位后执行收货入垛用例。
(9)装箱。货物从垛位提出装箱时执行装箱用例。
(10)重箱交接。将装好的重箱交给客户时执行本用例。以上为出口装箱业务用到的用例。下面是几个查询用例。
(11)垛位查询。①仓库管理员向系统查询垛位状态；②系统显示垛位状态。
(12)库存货状态查询。①仓库主管要求查询仓期超过一个月的委托单；②系统显示满足条件的委托单。
(13)客户装、拆箱数查询。①仓库主管要求查询某客户某段时期内的装、拆箱数；②系统显示查询结果。
这里要着重说明的是，描述用例时，最好不要包含界面实现细节方面的词汇。如“用户在列表框中选择收货人”，这句话中的“列表框”就表达了界面实现细节，因而不是好的描述方法。之所以要强调描述用例时不要包含界面实现细节，是因为在初始的需求分析阶段，构造的界面原型只是一个草稿，我们仅仅用它来方便用例的导出。而最终用于实现用例的界面要做进一步的优化和调整，它们可能和初始界面原型很不相同。如果在用例中过多描述跟初始界面原型相关的实现细节，就会大大限制设计人员设计最终用户界面的创造性，从而无法设计出最优的最终用户界面。以上问题陈述、参与者、GUI界面原型和用例一起构成了系统的需求模型。
四、建立CFS 业务信息系统的分析模型
完成需求定义，得到需求模型后，下一步进入系统分析阶段。分析阶段的主要任务是构造系统的分析模型，该模型主要包括静态模型(用类图表示) 和动态模型(用顺序图、合作图、状态图等表示) 。
首先，可以根据问题描述及用例，通过词法分析，提炼出系统的对象，进而画出类图，用以表示系统静态模型。寻找对象的基本规则是名词和名词词组成为候选对象，动词是对象的服务，形容词可能暗示存在子类。当然，由于自然语义并不十分精确，所以不能机械地套用基本规则，还须做进一步的分析与调整。本系统的类图模型如图2所示。
该图中，三角形符号表示父类与子类联系，棱形表示聚集联系，连线代表一般联系。连线边的标注表明该端对象在该联系中扮演的角色，如客户在与委托单的联系中扮演发货人角色(适用于任一子类) ，在与拆箱委托单的联系中扮演收货人角色(仅适用于拆箱委托单) 。各对象类的主要属性已标注在类中，但对象的服务没有全部标出。建立对象模型后，为了表达系统的动态特征，可以建立系统的动态模型。动态模型可用顺序图、合作图、状态图表示。本系统选择顺序图和状态图。
理论上说，我们可以为每个用例开发一个顺序图，但实际上，通常可以省略那些过于简单的用例的顺序图。顺序图表达了参与一个用例的几个对象协同工作的行为。这里，给出本集装箱货运站系统中为拆箱委托单预分配垛位用例的顺序图(如图3) 。
顺序图适于表达一个用例中几个对象的交互行为，若想表达跨越多个用例的单个对象的行为，可以使用状态图。同样，我们也不必为每个对象开发状态图，而只须为关键的对象和具有复杂状态的对象开发状态图。这里，给出“拆箱委托单”和“垛位”的状态图见图4。
完成了顺序图和状态图后,可据此研究对象间的消息传递，从而进一步修订、精化类图,为类添加服务。例如在“拆箱委托单预分配垛位顺序图”中，事件“预分配垛位”成为委托单类的“预分配垛位”服务;事件“验证可用性”成为垛位类的“检查垛位状态”服务,事件“锁定垛位”成为垛位类的“设置垛位状态”服务。这样,最终的类图、顺序图、状态图和模型词典共同构成了分析模型。此后,在系统设计阶段,可以根据类图设计数据库，根据界面原型设计界面对象，根据数据访问要求设计数据服务层对象。进而,扩展原来的类图,让它包含界面对象和数据服务层对象。最终,在系统实现阶段,把各层对象组装起来,形成完整的应用程序。
五、结语
通过集装箱管理系统的开发过程看到，UML是一种面向对象、可视化的系统分析建模语言，它支持从需求描述开始的软件开发全过程。采用UML语言进行系统建模分析和设计，解决了领域专家、软件设计人员和客户之间交流的难题，使用它的图形元素便于开发人员更好地理解业务流程，建立更为完善的系统模型，使用户和开发者对问题的描述理解达成一致，排除语义差异，提高分析的正确性，从而加速了开发的进程，保障了系统的开发质量。
参考文献:
[1]刘光明陈炼马永生:基于UML需求分析技术的应用研究[J].科技广场, 2005,(03)
[2]冯玲玲沈轶:基于UML的需求分析与建模[J].科学技术与工程, 2005,(09)
[3]徐宪武刘永泰:UML与RUP在科技项目评审系统中的应用[J].电脑开发与应用, 2005,(07)
关键词：需求侧资源；电力系统；负荷预测分析
中图分类号：TM71 文献标识码： A
一、前言
目前，我国并没有针对电网规划提出具体、有效的方法，基于此文章提出了一种兼容需求侧资源的电力系统负荷预测分析方法，实现对电网的规划，以此解决电网设备利用率低、电网建设投资消耗大、电网规划落实难等问题。
二、需求侧资源的类型分析
综合考虑技术进步、行业发展以及我国的相关政策导向（例如《有序用电管理办法》、《可再生能源管理办法》）等因素，根据需求侧资源对负荷曲线的影响效率，将电力系统负荷预测中的需求侧资源分为负荷类能源和能效类资源两类。负荷类资源：指的是用户自愿选择，通过改变用电时间或者减少用电设备的电量，以此实现降低电力负荷目标的各种行政措施或者经济措施，其中行政措施包括直接负荷控制、有序用电管理等，经济措施包括可中断电价、季节性电价、阶梯电价、丰谷电价等电价政策，负荷类资源的规划以及实施能够有效的达到节约电能、降低电力负荷的目的。能效类资源，指的是通过提高用电效率，以此实现降低电力负荷水平以及用电量的技术措施，例如采用节能空调、节能电梯、电动机系统节能、变压器节能、节能型家用电器、绿色照明等，通过引入能效类资源能够在所有时间段降低用电量。
三、兼容需求侧资源的电力系统负荷预测总体思路以及模型构建分析
1兼容需求侧资源的电力系统负荷预测总体思路分析。兼容需求侧资源的电力系统负荷预测的总体思路表现为：通过合理的统计与估算某个地区内各种类型需求侧资源的类型与潜力，然后将其考虑到电力系统负荷预测过程中，能够更加有效的增加预测电力系统负荷预测的准确性，以此避免由于粗放扩容方案造成资源的浪费。
2模型构建分析。文章以某10kV变电站供电区域为例，该变电站包含了三条线路，每一条线路都覆盖有商业用户、工业用户、居民用户以及其他用户等，某一条线路上的用户分类以及初始用电状况如表1所示，其中P1为初始最大负荷、Q0表示初始月用电量、n表示电力用户数量。
2.1单一需求侧资源的电力系统最大负荷预测模型。每一种雷丁的电力用户都存在多用用电方式，例如商业用户的用电主要包括空调、照明；工业用户的用电主要包括电动机、照明等；居民用户的用电主要包括热水器、冰箱、空调以及照明等；其他用户的每个用电环节都存在需求侧资源。首先研究单一需求侧资源的电力系统最大负荷预测模型，某种类型电力用户考虑单一需求侧资源的电力系统最大负荷预测模型表示为：
（公式1）
公式中γLR表示该类用户在LR作用下的电力负荷；rEER表示该类用户在EER作用下的降耗率； 表示在需求侧资源作用下的最大电力负荷。
2.2多种需求侧资源的电力系统最大负荷预测模型。由于EER是电力用户采用的各种技术措施的组合，直接对应某种类型，例如节能空调、绿色照明等，并且降耗率是相对于原来用电类型而言的，并不是用户的整体用电状况，所以EER的节点效果应该根据用电类型进行计算，分析多种EER作用下总电量的变化状况。假设ΔQ表示节电量，ΔQi表示用电环节i的节电量；ui表示能效类资源能够存在的状态系数；riEER表示用电环节i在EER作用下的降耗率；Qi，0表示用电环节i预测年的初始用电量，如果ui的取值为1，则表明该用户具有此类资源，如果ui的取值为0，则表明该用户不具备该类资源。由此可以获得该类用户用电环节i在EER作用下的节电量，节电量的公式表示为：
（公式2）
总的节电量为各种用电环节的节电量的总和，因此EER作用下的用电量公式表示为：
（公式3）
2.3兼容需求侧资源的电力系统负荷预测分析结果。通过采用兼容侧资源的电力系统负荷预测，在LR作用下能够准确的预测电力系统的负荷，能够在用电高峰段实现负荷的转移，以此实现削峰填谷的目标，有效的提高负荷率，通过对该综合变电站的该条线路进行负荷预测分析，对比需求侧资源作用前后最大负荷预测值的结果，P0为初始最大负荷、P1表示不考虑需求侧资源的最大负荷，PDSR表示兼容需求侧资源作用的最大负荷，经过实践表明，在兼容需求侧资源作用下，该条线路的电力用户的最大电力负荷降低了23.56%。
结语
总而言之，通过应用兼容需求侧资源的电力系统负荷预测方法，创建兼容需求侧资源的馈线负荷预测模型，能够有效的预测一定范围供电系统的电力负荷状况，并且该种负荷预测分析方法具有一定的可扩展性、可复制性以及可操作性，值得广泛的推广和应用。
参考文献
