期刊在线咨询服务,发表咨询:400-888-9411 订阅咨询:400-888-1571股权代码(211862)

期刊咨询 杂志订阅 购物车(0)

需求分析示例模板(10篇)

时间:2023-09-04 16:22:57

需求分析示例

需求分析示例例1

中图分类号: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.

需求分析示例例2

中图分类号: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%。

结语

总而言之,通过应用兼容需求侧资源的电力系统负荷预测方法,创建兼容需求侧资源的馈线负荷预测模型,能够有效的预测一定范围供电系统的电力负荷状况,并且该种负荷预测分析方法具有一定的可扩展性、可复制性以及可操作性,值得广泛的推广和应用。

需求分析示例例3

腹膜透析患者多需长期进行治疗,而这对患者的心理状态造成不同程度的危害,表现出对治疗态度的影响。而对于腹膜透析患者进行心理疏导方面的研究显示,此类患者中较多对心理疏导的需求程度较高,临床研究显示,对此类患者针对性心理疏导的前提是对其需求程度与影响因素的掌握[1-2],但是临床中此方面的研究十分不足,且差异较大。故本文中我们就腹膜透析患者心理疏导需求程度及其影响因素进行研究与分析,分析结果总结如下。

1资料与方法

1.1一般资料 选取2014年3月~2016年12月本院进行腹膜透析治疗的90例患者为研究对象,其中男性51例,女性39例,年龄:

1.2方法 将90例患者进行心理疏导需求程度的评估,然后将其中不同性别、年龄、文化程度、社会支持程度、情绪状态、透析时间、经济状况及治疗依从性患者的心理疏导需求程度,同时采用Logistic分析上述因素与此类患者心理疏导需求程度的关系。

1.3评价标准 心理疏导需求程度采用不记名问卷的形式进行评估,本问卷中主要包括三个选项,即患者对心理疏导的需求程度,三个选项分别为需求较高、需求一般及无需求,由医护人员对患者进行问卷填写前的培训告知,问卷均有效回收。

1.4统计学分析 本研究中采用软件SPSS18.0的数据检验,数据检验方式为t检验和?字2检验,P

2结果

2.1 心理疏导需求程度比较 90例患者中心理疏导需求程度较高者51例,占56.67%,不同性别、年龄、文化程度、社会支持程度、情绪状态、透析时间、经济状况及治疗依从性患者的心理疏导需求程度也存在明显差异,P

2.2研究因素与心理疏导需求程度的关系分析 经Logistic分析显示,性别、年龄、文化程度、社会支持程度、情绪状态、透析时间、经济状况及治疗依从性均与此类患者心理疏导需求程度有密切的关系,见表2。

3讨论

临床中关于腹膜透析治疗患者的各个方面研究显示[4-5],此类患者的治疗、生活质量及其他多个疾病相关方面均受其心理状态影响较大,因此此类患者的心理疏导干预是护理过程中的重点。而要实现较好地心理疏导效果,患者自身对心理疏导的需求程度是一个重要的影响方面[6-7],只有患者自身对于心理疏导的需求程度较高,其才会在心理疏导的过程中更为有效地配合及接受心理疏导,达到较好地心理疏导效果。故认为对腹膜透析患者进行心理疏导需求程度的干预价值较高,因此对其现状及影响因素的研究与掌握是近期的研究重点。

本文中我们就腹膜透析患者心理疏导需求程度及其影响因素进行研究与分析,结果显示,90例腹膜透析患者中心理疏导需求程度较高者为51例,占56.76.%,同时不同性别、年龄、文化程度、社会支持程度、情绪状态、透析时间、经济状况及治疗依从性患者的心理疏导需求程度也存在明显差异,表现为女性患者、年龄较高、文化程度较低、社会支持程度较低、焦虑抑郁、透析时间较长、经济状况较差及治疗依从性较低者的心理疏导需求程度较高,且Logistic分析显示,上述因素均与患者的心理疏导需求程度有密切的关系。分析原因,我们认为女性患者的心理状态更为细腻,对于疾病及其他相关方面的心理应激更为突出,因此其疏导需求也即更高;文化程度较低及社会支持程度较低的患者其疾病认知度较低,对于疾病治疗、预后的担忧程度更高,心理不良波动也更大,心理疏导需求也更高;透析时间较长及经济状况较差者对于治疗的耐性较差,懈怠感较强,对于预后的影响也较大,心理疏导需求也较高;治疗依从性较低及焦虑抑郁者心理状态较差,疏导需求随之更高。综上所述,我们认为腹膜透析患者心理疏导需求程度较高,且性别、年龄、文化程度、社会支持程度、情绪状态、透析时间、经济状况及治疗依从性均是其重要影响因素,应针对这些因素进行干预。

参考文献:

[1]方晶.长期透析患者心境障碍的心理疏导[J].神经损伤与功能重建,2014,9(5):445-446.

[2]程玉华.中青年血液透析患者心理状况分析及干预效果研究[J].中国伤残医学,2015,23(24):187-189.

[3]李敏,程静,严冬仙.不同年龄段维持性血液透析患者的心理分析与护理对策[J].实用临床医学(江西),2014,15(1):116-117.

[4]冯艳平.维持性血液透析并发恶性肿瘤患者的心理现状和干预方法[J]. 中华肿瘤防治杂志,2015,22(B22):290.

需求分析示例例4

首先是获得当前系统的物理模型。物理模型是对当前系统的真实写照,可能是一个由人工操作的过程,也可能是一个已有的但需要改进的计算机系统。首先是要对现行系统进行分析、理解,了解它的组织情况、数据流向、输入输出,资源利用情况等,在分析的基础上画出它的物理模型。然后抽象出当前系统的逻辑模型。

逻辑模型是在物理模型基础上,去掉一些次要的因素,建立起反映系统本质的逻辑模型。接下来建立目标系统的逻辑模型。通过分析目标系统与当前系统在逻辑上的区别,建立符合用户需求的目标系统的逻辑模型。最后补充目标系统的逻辑模型。对目标系统进行补充完善 ,将一些次要的因素补充进去,例如出错处理等。

UML(The Unified Modeling Language,即统一建模语言)是一种编制系统蓝图的标准化语言,可以对复杂的系统建立可视化的系统模型,目前已经被工业标准化组织OMG(Object Management Group)接受,一经推出便得到许多著名的计算机厂商如Microsoft、HP、IBM、Oracle等的支持,也在逐步开始应用到需求分析过程中。

在使用UML建立当前系统逻辑模型过程中,初学者通常会遇到一些问题:

1.什么时候真正需要业务模型?什么时候用例模型独立存在?

2.在进行精确的业务建模时能用哪些UML图形?如何知道是否用顺序图或者交互图?

3.业务模型如何涉及到其他模型(如领域模型,用例模型等等)呢?如何有机地组织这些模型?

本文将通过图书馆管理系统这个简单而典型的实例来进行一次UML需求分析实践之旅。

许多读者对图书馆图书管理工作比较熟悉,主要是围绕读者、图书和工作人员的借还书展开工作。我们先看看图书馆工作人员和部分读者的需求。

读者来图书馆借书,可能先查询书库的图书记录。查询可以按书名、作者、图书编号、关键字查询。查询有两种结果,如果查到则记下书号,交给工作人员,然后等候办理借书手续。如果该书已经被全部借出,则可做借书登记,等待有书时被通知。如果图书馆没有该书的记录,则做缺书登记。

办理借书手续时先要出示图书证,没有图书证则去申请图书证。如果借书数量超出规定,则提示“借书数量超限,不能继续借阅”。工作人员登记借阅人信息、借阅的图书信息、借出时间和应还书时间。系统自动修改书库的图书记录、读者库信息。

当一位读者还书时,工作人员根据图书证编号,找到读者的借书信息,查看是否超期,如果已经超期,则进行超期处罚。

如果图书有破损、丢失,则进行破损处罚。清除借阅记录,同时系统自动查看是否有等待借阅登记,如果有则发出通知,修改书库记录,该书设置为已预订状态,否则设置为可借状态。

图书采购人员进行图书采购时,要参考各类图书的库存数和借阅率,注意合理采购。如果有缺书登记则随时进行采购。正在采购的图书组成一个采购中书库。

采购到货后,进行验收,编号,同时加入图书库,修改采购中书库,并且查看订阅库,发出到书通知,并且已经修改书库的图书记录为已预订状态。

借书登记是当欲借的书被借空后,读者自愿选择的一种操作,它应该记录读者名和联系方式,一旦有这本书后可通知读者。

到书通知,当读者预订的书来到之后,按照读者给出的联系方式发出通知。

缺书登记是当读者需要的书库内查询没有记录时,将此信息转入缺货库,通知采购员采购。

图书注销,如果图书丢失或旧书淘汰,则将该书从书库中清除。

根据需求描述整理一张需求表:

需求分析时首先要识别出系统的参与者,在简单的图书馆管理系统中,可以划分出两种参与者:读者和管理员。当然,根据业务的复杂程度,参与者也可以进行细分,比如读者可以再分为学生读者、教师读者、校外读者,管理员根据业务和权限的不同可以再细分为库房管理员、借还书操作员、系统维护人员、图书馆管理人员等不同角色。在这里,为了简化处理,我们只列出了读者和管理员。对参与者描述如下:

(1) 读者

描述:读者可以借阅、预定、归还物理书刊,可以对书籍和个人信息进行查询,可以取消预定,可以提出办卡申请。

示例:持有借阅卡的任何人和组织。

(2) 管理员

描述:图书管理员对系统进行维护,包括读者信息的创建、修改、删除,书刊信息的维护,条目信息的维护,还有系统信息的维护。

示例:图书管理员。

通过识别的参与者,对需求进一步分析,将业务需求进行分解,获得每个参与者的使用用例。在本例中,我们可以得到以下用例:

1.书籍借出:提供借阅物理书刊的功能。

2.书籍归还:提供归还物理书刊的功能。

3.读者办卡:提供为读者办理借阅卡的功能。

4.预定书刊:提供对某一个种类的书刊的预约功能。

5.取消预定:提供对预定进行取消的功能。

6.书籍查询:为读者提供网上的书籍查询功能。

7.信息查询:为读者提供信息查询的功能。

8.读者信息维护:提供读者信息的录入、修改、查询、删除的功能。

9.书刊信息维护:提供物理书刊的录入、修改、查询、删除的功能。

10.条目信息维护:提供书刊条目的录入、修改、查询、删除的功能。

11.系统信息维护:提供对系统的参数的设置。

12.登录:管理员需要先登录才能进入系统。

并且,可以画出如下系统用例图:

通过用例图,可以对系统功能有一个大概的了解,对于复杂系统,我们可以结合IDEF方法,通过分层分解,逐步细化的方法来描述系统的功能。对于用例图,建议不要画的过于复杂,特别是用例之间的关系,因为复杂的用例图不仅不能让需求分析人员与客户之间更好的沟通,反而是制造了一种沟通障碍。

下一步就是编制每一个用例的详细说明,对用例说明的主要信息包括有:用例名称、编号、用例的简短描述、用例的参与者、与其他用例的管理、用例启动的前提条件、用例结束后的事后条件、用例的输入、输出、用例的执行事件流等。在实际项目中,我们并不一定要面面俱到,而是根据实际情况对用例描述进行裁减。其中有几点重要信息是不能裁减的:用例名称、描述、输入、输出、执行事件流、参与者。另外,如果实际情况需要,还可以使用MS Visio等工具画出界面的示意图来。

如上例所述,我们对每一个用例都进行详细的描述,建立当前系统的功能用例模型。需求沟通与分析是一个迭代的过程,通过与用户的不断沟通,最终达成对目标系统的一致理解。如果用户确认了需求分析的成果,一般是需求规格说明书之后,项目开始进入系统分析设计阶段,也就是开始构造目标系统的逻辑模型。

为了让系统设计能够以结构、组织方式和代码重用的形式表现出来,要对系统进行设计规划,设计阶段应该与分析阶段交迭。需求是不断地发展,而设计本身也会推动需求的发展(反之亦然) 。在图书馆管理系统的建模设计中,以下3个方面的问题是要关注的:业务对象的表示、业务服务的实现、用户界面的组织。

业务对象的表示

在图书馆管理系统系统中,业务对象主要是数据库和数据实体类的表示方式。建模时,可以构造出系统的静态模型,也就是系统类图来表示。如下图则描述了借书这一用例的静态结构图。为了体现类之间的关系,在下图中没有显示出每一个类的属性和基本操作。

业务服务的实现

业务服务的实现需要完成的功能是各种业务规则和逻辑的实现,如借书处理的业务逻辑。每个模块的信息录入、修改、删除、查询等。业务规则和逻辑的实现基本相似,没有太多的规律可循。采用UML来进行业务服务的建模,可以使用UML 的序列图、状态图、活动图。这个部分的工作,通常通过一系列的类之间的交互来完成。为了在更动态的层面上描述系统,UML 提供了许多其他类型的图。

对于B/S系统设计而言,情节图(Scenario Diagram) 特别有用。情节图分成两种:协作图(Collaboration Diagram) ,序列图(Sequence Diagram) 。UML 建模工具Rational Rose 能够从协作图生成序列图也可以从序列图生成协作图。例如,借阅书刊的业务过程可以采用如下序列图来描述:

借阅书刊过程主要包括:管理员选择“借阅书刊”菜单,弹出对话框,管理员输入书刊信息和用户信息,系统查找数据库,是否存在该种物理书刊,如果不存在,显示提示信息,用例结束;是否存在借阅者信息,如果不存在,显示提示信息,用例结束;否则,管理员单击确认按钮后,该图书借阅给该借阅者,系统存储借阅信息到数据库。

用户界面的组织

用户界面布局图能够帮助组织系统页面、文件、服务的布局结构。在UML 中,对于页面和文件的组织,可以使用构件图(Component Diagram) 或类图(Class Diagram) 建模型。本系统中使用类图对界面组织建模,页面结构以及各种业务服务被捆绑到不同的区域。

在 UML 中,系统的体系结构使用部署图(DeploymentDiagram) 来完成。应用部署的规划对于规划整个B/ S 系统是很有用的。它确定了一种有效的应用部署的规划组织方式,还可以作为一个模式在多个类似B/ S 系统上应用。

在建模完成后,开发人员利用一些UML Case工具如Rational ROSE生成程序代码框架,并对代码框架进行修改和补充,形成完整代码;而且,还可根据代码逆向生成 UML模型。这就较好地保证了模型与代码的一致性。

需求分析示例例5

中图分类号:G642

文献标识码:A

文章编号:1672-0717(2014)05-0029-05

收稿日期:2014-06-03

基金项目:湖南省学位与研究生教育教学改革研究重点课题“法律硕士专业学位研究生实务技能培养机制创新研究”(JG2012A009);湘潭大学法学院研究生教改科研项目“全真法学案例演示教学研究”(FXYJG002)。

作者简介:胡军辉(1976-),男,湖南娄底人,湘潭大学法学院副教授,法学博士,硕士研究生导师,主要从事法学教育研究。

我国现有的法学研究生教育注重法学理论知识的传授,对实务技能的培养重视不够,学生普遍缺乏动手能力。“法科毕业生到实务部门后,要能够适应审判案件、处理案件、各种法律事务的需要,至少还要三到五年的时间”[1]。法学研究生实务技能的培养是一项系统工程,而法学研究生教学方法的改良是非常重要的一环。传统的教学方法没有给学生提供足够的提升实务技能的机会,也没有培养学生活跃的法学思维方式,因而学生普遍动手能力差、解决实际问题的能力差。对此问题,笔者在长期的教学过程中作了一些思考,并提出了旨在提升法学研究生实务技能的新的教学方法――全真案例演示教学法,现特撰文加以介绍,以期有益于相关问题的解决。

一、全真案例演示教学法的含义及其核心要素

所谓全真案例演示教学法,是在法律实务课程的教学过程中,教师挑选其亲自参与过的法律案件作为教学案例,由学生扮演案件中的不同角色进行模拟演练,然后由教师对案件的真实处理流程及结果进行演示,比较案件模拟演练与真实处理过程和实际效果,从而使学生切身感受案件的处理流程、技巧与技能,并深刻了解司法实践中真实案件的运行状况,进而拓展学生实务知识,提升实务技能。全真案例演示教学法的核心要素如下:(1)真实的案例。“案例是一种描写性的研究文本,通常是以叙事的形式呈现,它基于真实的生活情境或事件。……案例必须是真实的”[2]。全真的案例是这种教学方法成功运用的基础,因为只有全真的案例才能展示真实的司法文书和案卷材料,才能使学生了解到真实的案件处理流程,详细地理解案件涉及到的法律问题,全面地认知真实的司法运行状况。而且,教师作为案件的真实参与者通常有机会也有必要对案件进行全面透彻地分析,其在办案过程中对于案件的分析工作转化为了教学的准备工作。全真的案例融入了教师少则几个月、多则几年的思考,他们将自己亲身经历的、思考良久的案件作为教学案例更加有益于法律分析方法、思维方式、诉讼技巧等内容的全面传授。在通常情况下,教师是不太可能花上几个月来思考一堂普通的教学课程的,因而“全真案例”本身保证了课堂教学的质量。(2)学生的模拟演练。在教师提供了全真的案例之后,就需要学生积极地参与进来,主要方式是学生通过扮演不同的案件主体角色来参与案件的处理。在全真案例演示教学法的课堂上,每位学生都需要承担特定的任务,必须全身心地投入到案例的分析与讨论中来。在讨论的过程中,学生可以感受到法律条文和理论知识在实践中的运用方法,也可以培养学生多角度、深层次的法律思维方式,以及培养制定最优法律方案的能力。同时,通过模拟整个案件的处理流程,学生可以亲身体会到司法实践当中的问题,使学生对法律在社会当中的作用有一个更清醒的认知。(3)教师的演示。在全真案例演示教学法体系中,教师的角色不仅仅是案卷材料的提供者,更应该成为教学过程中的引导者和演示者。教师在课堂讨论当中,应当引导学生讨论、思考,点评学生在课堂讨论和案件模拟中的做法,指出他们的优点、不足和问题。在学生形成一定的法律意见之后,教师应当及时地演示案件的真实处理过程和实际效果,比较学生演练的方案和案件实际的处理方案,引导学生评价两者的优缺点,让学生感受到各种方案的特点,从而培养学生多视角分析问题的能力。(4)课后的总结。在上课过程中,学生通过自身的分析、相互的研讨以及教师的讲解与演示等对于案件的相关问题形成了一定的认识,并对相关法律知识有一定程度的掌握,但因上课时间短、任务重,对于“知识养分”只能做到粗消化,因而课后学生的系统总结是相当重要的,这是全真案例演示教学法成功运用不可或缺的元素。

二、全真案例演示教学法与其他案例教学法的区别及其特点

在我国现有的法学教育实践中,法学教育者们已经探索出了多种案例教学方法。全真案例演示教学法与现有案例教学方法既有一定程度的联系,也有着一定的区别:(1)与案例教学法的比较。“案例教学法是通过对典型案例的解剖、分析以及组织学生对其进行研究、讨论,引导学生从实际案例中学习、理解和掌握法的一般原理、原则的一种教学方法”[3]。全真案例演示教学法与传统案例教学法均以案例为教学素材,均通过模拟、讨论等形式让学生获得实践知识,均注重培养学生的实务技能。但全真案例演示教学法要求教学必须选择自身参与的案件作为授课案例,在教学过程中重视教师示范和指导,并要求学生根据案件素材分角色进行演练。(2)与亚案例教学法的比较。所谓亚案例教学法是通过高度激活教师与学生认知活动中的非智力因素,使教与学双方的积极性同时最大化、获得满意教学效果的一种教学方法[4]。全真案例演示教学法和亚案例教学法都属于参与型教学方法,教学过程都强调学生的主体作用,都重视学生动手能力的培养。但两者的区别也是较为明显的,全真案例演示教学法包含了全真案例、学生模拟、教师演练、点评与总结等亚案例教学法所没有的元素。全真案例演示教学法更加明确地强调学生的参与、学生实务技能的提升以及学生开放性思维方式的培养。(3)与个案全过程教学法的比较。个案全过程教学法是由复旦大学法学院教授章武生教学科研团队推出的一种教学方法,是在吸收美国“个案教学法”精髓基础上立足我国国情提出的一种真实案例教学方法[5]。全真案例演示教学法和个案全过程教学法之间也存在一定的区别:其一,前者强调案例是由主讲教师曾经实际参与过的案件,后者并无此要求;其二,前者不要求对每个案件的全部过程进行模拟演练,而是将案件的精华部分挑选出来作为教学素材,后者则要求学生对案件的全过程进行学习;其三,前者同时包含了学生演练和教师演示两环节,后者仅强调学生的模拟,对教师的演示并不特别强调;其四,前者要求参与案件模拟演练的学生根据案件的原始材料作出自己的方案、形成自己的文书,依据自己的思路进行演练,而后者提供给学生演练的素材是已经形成的真实案件材料和文书,相比之下学生主动思考的空间受到了限制,难度明显降低。

通过以上的比较和分析,我们可以看出全真案例演示教学法具有以下突出的特点:(1)全真案例演示教学法具有“案例性”特点。这一教学方法是一种典型的案例教学法,在实施的过程中不是以理论讲解和法条的教授为主,而是注重以具体的案例为依托来传授法律知识。(2)全真案例演示教学法具有“实践性”特点。对于全真案例演示教学法而言,实践性既体现在教学过程之中,又体现在教学结果之上。一方面,学生查明事实、分析法律并将两者结合起来解决具体案件的过程是一个法律实践的过程。另一方面,学生通过在课堂中分析法律、使用法律达到了提升法律实践能力的目的。(3)全真案例演示教学法具有“真实性”特点。这种真实性主要体现在案件的真实性和案卷材料的真实性两个方面。真实的案件和案卷材料对于提升学生的实务技能非常重要,因为其反映了真实的案件事实、反映了真实的案卷材料以及真实的法律运行状态。这有利于学生适应真实的法律社会,解决真实的法律问题,获取真实的法律实践能力。(4)全真案例演示教学法具有“互动性”特点。这种互动性体现在多个方面:一是老师演示教学与学生模拟分析的互动;二是学生与学生之间的互动,学生通过相互合作、相互对抗的方式来提高法律运用能力和水平;三是课前、课中和课后的互动,全真案例演示教学的时间范围并不限于上课时间,学生在课前和课后均需投入一定的时间来进行学习,特别是课后的总结是非常重要的固定教学环节。(5)全真案例演示教学法具有“综合性”特点。全真案例演示教学过程中需要综合运用多种教学手段,比如学生的讨论、模拟和总结,教师的分析和演示等;而且,全真案例演示教学法需要综合运用多种法律部门知识,比如一个案件的顺利解决可能既涉及到程序法知识又涉及到实体法知识,既涉及到民商法知识又涉及到行政法知识,还可能涉及到刑事法知识。(6)全真案例演示教学法具有“合作性”特点。全真案例教学法强调学生的团队协作,在案件讨论和模拟阶段,不同组别的学生需要相互配合、相互帮助共同完成教学任务。学生在相互讨论、学习、交流和合作过程中能够逐渐意识到团队作战的重要性,意识到合作在司法实务中的重要价值。

三、全真案例演示教学法的实施要求、课前准备及流程

全真案例演示教学法的实施需要满足一定的要求,具体而言包括以下几项:(1)对授课教师的要求。全真案例演示教学法对于授课教师提出了一定的要求:首先,教师必须是谙熟实务技能的法律实践者,其应当以某种或者某几种角色参与过大量案件的处理,具备较为丰富的法律实践经验和阅历以及相当的实务技能;其次,教师应当同时具备法律实务技能和讲解、演示和传授实务技能的能力;三是教师需要积累大量且比较齐备的案卷材料。(2)对听课学生的要求。全真案例演示教学法是一种互动型教学法。在运用该方法进行教学的过程中,学生需要具备一定的法律知识和一定的法律分析的能力,能够胜任一定角色的扮演。(3)对适用课程的要求。全真案例演示教学法的适用课程主要是针对那些具有很强应用性的法学学科,而对于理论性课程的讲授则不宜使用。法律硕士的培养过程中培养方案设置了较多的应用性课程,全真案例演示教学法具有较大的应用机会;(4)对授课设备设施的要求。全真案例演示教学法的教学过程包括学生分组讨论、学生分角色模拟、教师演示等重要实践性教学内容。顺利完成这些教学内容需要配备相应的硬件设施。

全真案例演示教学需要做好充分的课前准备。教师的课前准备工作主要包括以下几项内容:一是挑选合适的案例。教师应当根据学生专业方向、法律知识基础、课程开设情况等来综合选择合适的案例,案例难度要适中,具有典型性,在时间上优先考虑新近发生的案件;二是增补案卷材料。现有的案卷材料是根据案件实际的处理需要而准备的,可能与教学工作的需要并不完全契合,因而教师在课前需要对案卷材料进行必要的整理,核实是否具备教学所需的所有法律文书和资料,如果没有,须尽量相办法增补,否则会影响课堂的教学效果。三是对法律文书资料进行分类、分组并编号。在教学中不同的角色扮演者所掌握的案卷材料是不一样的,同一角色扮演者在不同的阶段所掌握的案件信息和案卷材料也是不一样的,因而在课前需要对案卷材料进行分类、分组并编号。

全真案例演示教学法的课堂实施主要包括以下程序:(1)教师介绍案情并对学生分组。教师首先需要向学生介绍案件的大致情况,案情介绍可以从当事人、法院或者人等不同的主体视角来进行介绍,这取决于教师办理案件的角度和拟开展教学工作的切入角度。介绍案情应当掌握信息透露的度,通常情况下只需介绍本课所演练的案件类型、相关的法律主体、案件发生的时间、地点等基本信息即可。案件相关信息透露得过多会影响学生思考的空间和演练的难度,进而影响实际的教学效果。对案件作基本的案情介绍后,需要对学生进行分组,如何分组需要结合具体案情和学生的人数、法律实务能力等因素来确定。(2)分发材料,确定各组任务。扮演不同角色的学习小组所拥有的材料、掌握的信息、所能运用的方法、所要实现的法律目标是不一样的。教师将预先准备好的材料分发给不同的学习小组,并确定各小组的任务。各小组应当明确负责人,由负责人来组织内部成员的分工和协作。(3)学生分组讨论。学生的分组讨论是全真案例演示教学的关键环节之一,该环节要重点把握以下几个问题:一是尽量给每组学生提供一个相对独立的讨论空间;二是强调各组学生的独立讨论,防止各自信息、思路和方案的泄露;三是允许并鼓励学生查询各种资料、法律信息和法律条文;四是要求学生形成一份讨论报告。(4)学生对案件进行模拟演练。在案件分组讨论工作完成后,学生开始进行模拟演练。模拟演练由授课教师主持,学生在模拟演练中扮演预定的角色,从各自所扮演角色的角度进行思考和学习。演练活动要尽量模拟现实的司法环境,要立足现实的案情和情境。模拟演练可以分阶段进行,也可以依照案件的处理流程全过程进行。(5)点评与全真案例演示。该环节包括三项核心任务:一是关于模拟演练的点评。学生可以对分组讨论所形成的案件处理方案、模拟演练过程中的问题及经验等方面进行点评。点评可以包括学生的自评、学生的互评以及老师的点评。二是教师对全真案例的演示。教师的演示包括对法律方案和思路的展示、全真案例法律文书的展示、具体问题的处理技巧和技能的演示等内容,教师的演示和点评可以交叉进行。三是比较全真案例处理过程与学生演练过程中的各环节和要素。(6)撰写全真案例演示教学课堂总结。撰写课堂教学总结的目的在于督促学生对案件过程中涉及到的法律知识、所运用的法律方案、各种方案的利弊进行系统的思考和总结。课堂总结需要涉及到的内容包括案件的主要内容、案件涉及到的重要法律关系、各方主体的核心利益、各种案件处理方案的利弊以及个案处理的心得等内容。

四、全真案例演示教学法实务技能提升路径及其教育价值

全真案例演示教学法通过多种途径来提升学生的实务技能,其中最主要的路径包括:(1)通过督促学生动脑、动手、动口等法律实践来提升实务技能。全真案例演示教学法需要学生自主完成的学习任务包括案卷资料整理、法条收集分析、法律方案的讨论与制定以及法律方案的模拟和案件总结等。参与这一学习过程的学生,能够获得大量动脑、动手和动口练习的机会,他们的实务技能能够在大量的法律实践中得到提高。(2)通过教师的演示与点评等方式提升实务技能。全真案例演示教学的核心内容之一是教师对于真实案件的演示,在演示的过程中教师会对真实的法律方案、思路进行分析,会对具体问题处理的技巧技能进行讲解,对真实的法律文书进行展示,对学生处理案件的思路、方案以及真实的处理办法进行点评与比较。教师的演示过程是学生深刻总结、反思和改良案件处理方案的最佳时机。学生通过教师的演示、点评和比较,能够从更深的层面理解和运用法律,进而达到提升实务技能的目的。(3)通过培养学生综合而开放的思维方式来提升实务技能。我国现行的法学教育是以部门法为基础进行课程设置的,培养的层次越高,学生所学习的知识就越专。民法专业的研究生不懂刑法,刑法专业的研究生不懂民法,实体法专业的学生不懂程序法,程序法专业的学生不懂实体法的现象非常普遍。然而,现实的案件不会只涉及到某一部门法,而是会同时涉及到多部法律,且程序法和实体法在应用过程中始终是不分离的。知识面过窄,各部门知识不能贯通运用严重制约着学生实务能力的发展。全真案例演示教学过程中运用的案例需要学生从多个学科来进行综合分析,需要综合运用各种救济程序。(4)通过展现全真的案件素材来提升学生的实务技能。全真案例教学的核心要素之一是“全真的案件”。全真的案件意味着法律关系、法律主体、法律事实、法律文书、案件处理流程等一系列相关案件素材均是真实的。学生能够通过分析案件材料,观摩教师的演示等方式直接了解司法实践的运行状况,可以在课堂上看到真实的法律文书,了解真实的案件处理流程,感知法律条文如何被真实地运用于实践,进而使学生的理论知识与司法实践形成有机结合,使学生能够在毕业后立马适应真实的法律环境。

全真案例演示教学法具有重要的教育价值:其一,有利于学生动手能力的提升。全真案例演示教学与传统的案例教学有一定的区别,其不仅强调教师对于全真案例的讲解和演示,更重视学生动脑、动口和动手来参与案件的解决和处理。学生动手解决法律问题是这一教学方法的最重要理念之一,是这一教学方法最重要的价值和目标所在。其二,有利于学生法律职业思维的形成。法律职业思维是指职业法律群体根据法律的品性对人的思维走向进行抽象、概括所形成的一种思维定势,是受法律意识和操作方法所影响的一种认识社会现象的方法,是一种法律职业共同体独有的思维模式。形成良好的法律思维是成为一名成功法律实务工作者的前提和基础。在全真案例演示教学过程中,教学活动运用的真实案例将一些真实的法律问题带入课堂,学生在教师的引导下练习如何处理真实的纠纷,像法律职业人士一样思考和分析,在学习过程中逐步形成严密的法律职业思维。其三,有利于学生提前熟悉现实的法律社会。法律理论教学与法律现实社会存在一定区别,法律理论知识虽然源自法律实践,但其是从法律实践中抽象出来的,已经不能直接地反映真实的法律社会。全真的案例将现实的法律元素带入了课堂,真实的案件、真实的当事人、真实的法律思维、真实的案卷材料等对学生熟悉现实的法律社会具有重大的价值,这一教学方法可以大大缩短毕业新生适应社会的时间。其四,有利于学生自主学习能力的培养。在全真案例演示教学活动过程中,学生的分组讨论环节、模拟演练环节以及案件的总结和分析环节均是需要学生自主完成的学习任务。在完成这些学习任务的过程中,学生需要自主检索法律条文、自主收集资料、自主分析和讨论案件并自主总结分析。这一系列的学习活动推动了学生自主学习能力的提升。其五,有利于学生协作意识的养成。协作意识是法律职业活动所需要的一种重要的思想观念。在全真案例演示教学过程中,诸如分组讨论、角色扮演等教学任务是需要学生相互合作才能高效完成的。通过在学习活动中的相互协调和配合,学生能够感受到团队合作的优势,意识到相互协作的意义和价值,进而形成协作意识。

参考文献

[1] 张卫平.个案全过程教学法―一种有效提升学生法律实务技能水平的新路径[N].人民法院报,2013-04-19(04).

[2] [美国]Katherine.K.Merseth.案例、案例教学法与教师专业发展[J].世界教育信息,2004(Z1):77-78.

需求分析示例例6

在参照我国现行水泥化学分析方法中相关要求,对水泥原材中,氧化镁含量进行测定的过程当中,多以基于EDTA的滴定差减法作为首选测定方案。在应用此种方案对氧化镁含量进行测定的过程当中,需要将酒石酸钾钠、三乙醇胺选取作为测定作业中的掩蔽剂,并以酸性铬蓝分析纯试剂以及萘酚绿分析纯试剂的混合形成K-B指示剂,最终以EDTA 标准溶液对其进行滴定分析。由此可见,在整个测定氧化镁含量的过程当中,以酸性铬蓝分析纯试剂以及萘酚绿分析纯试剂的混合形成K-B指示剂在很大程度上会对测定数据的准确性产生影响,应当作为此法实施下的质量控制要点。为进一步研究合理的K-B指示剂应用要点,本文展开以下分析,望引起重视。

1 对水泥中氧化镁含量的测定试验分析

在对水泥样本中氧化镁含量进行测定与分析的过程当中,所涉及到的仪器设备主要包括以下几个方面:①分析天平装置;②高温炉反应装置;③EDTA分析纯;④酸性铬蓝K分析纯;⑤萘酚绿B分析纯;⑥三级实验室用水。

具体而言,为了实现对水泥样本中,氧化镁所含量情况进行及时且精确的测定,要求严格按照以下步骤展开试验:

第一步:需要对样品进行预处理:在对水泥待测样品进行预处理的过程当中,应用分析天平装置精密称取0.5g剂量的水泥样品,将银坩埚放置于高温炉反应装置当中进行高温处理。在处理温度达到700℃的情况下,进行持续20min时间的熔融处理(注意:熔融处理过程当中,需要间隔10min的时间,取出银坩埚反应装置并加以摇动)。熔融处理完成之后,需要取出反应样品,并将其放置于烧杯当中(烧杯预先煮沸三级用水,添加剂量为100.0ml)。银坩埚样品全部脱干净到烧杯中,称取30.0ml剂量盐酸分析纯试剂,以及1.0ml剂量硝酸加入反应并充分搅拌。对所形成的溶液再次进行加热处理,煮沸后自然冷却。冷却标准以达到室温20℃~25℃范围内为宜。在此基础之上,转移定容处理,形成待分析试剂250.0ml。

第二步:需要对样品进行综合分析:在对经过预处理后样品进行综合分析的过程当中,需要吸取剂量为25.0ml的处理液试剂,其中注入175.0ml的试验三级用水,充分搅拌均匀的基础之上,形成剂量为200.0ml的综合反应试剂。在此基础之上,向所形成的综合反应试剂当中加入1.0ml剂量的酒石酸钾钠溶液,5.0ml剂量三乙醇胺溶液,25.0ml剂量缓冲溶液(要求缓冲溶液的酸碱值为10.0及以上标准)。在此基础之上,加入酸性铬蓝分析纯试剂以及萘酚绿分析纯试剂,同时应用EDTA标准溶液试剂,滴定至分析试剂呈纯蓝色状态。需要特别注意的一点是:在对样品进行综合分析的过程当中,若测定一氧化锰的含量高于0.5%比例,则需要通过增加三乙醇胺溶液剂量至10.0ml的方式,以确保检测结果的准确性。

2 对水泥中氧化镁含量的测定结果分析

首先,在通过以上方式对水泥样品中氧化镁含量加以测定的过程当中,可以通过对酸性铬蓝分析纯试剂以及萘酚绿分析纯试剂的方式,对两种分析纯试剂的添加各比例进行观察,并研究其相对应的重点颜色产生的影响。具体的实验数据如下表所示(见表1)。结合表1中的数据可知,为了能够最大限度的保障在综合加入酸性铬蓝分析纯试剂以及萘酚绿分析纯试剂状态下,终点变化的有效性与明显性,就要求设定两者之间的添加比例为1.0(酸性铬蓝分析纯试剂):1.2(萘酚绿分析纯试剂)。

表1 K-B指示剂与终点变化的关系数据示意表(单位:g)

其次,在通过以上方式对水泥样品中氧化镁含量加以测定的过程当中,需要以现行的氧化镁化学分析方法为依据,结合所测定试验的实际情况,添加适当的K-B指示剂。在不同K-B指示剂加入量的作用之下,溶液颜色以及终点颜色均会产生一定程度上的变化,具体的实验数据示意表如下表所示(见表2)。结合表2中的数据可知:为了能够确保溶液显示颜色以及终点颜色的合理性,要求按照0.1g剂量标准的方式,加入相应的K-B指示剂。

表2 K-B指示剂加入量与溶液颜色的关系数据示意表(单位:g)

综合对以上数据的分析认为:在应用K-B指示剂参与对水泥中氧化镁含量测定作业的过程当中,为了确保测定数据的准确性与可靠性,要求将K-B指示剂的混合比例确定为:1.0(酸性铬蓝分析纯试剂):1.2(萘酚绿分析纯试剂),同时将K-B指示剂的加入量设定为0.1g,以保障滴定终点颜色的明确性。按照以上方式所配置形成K-B指示剂再作用于对水泥中氧化镁含量测定与分析的过

程当中,测定数据的误差基本能够控制在2.5范围之内,

属于水泥化学分析标准中的允许误差范围,因而值得采纳。

3 应用K-B指示剂中的关键问题分析

首先,要求对K-B混合指示剂在配置过程当中的添加顺序加以有效的控制:由于K-B指示剂中酸性铬蓝K和萘酚绿B含量较少,先称取烘干过的硝酸钾放入研钵中,再称酸性铬蓝K和萘酚绿B适量加入硝酸钾中。因为若先称取酸性铬蓝K和萘酚绿B放入研钵中,再称取硝酸钾,研磨时少量的酸性铬蓝K和萘酚绿B易粘研钵壁上,减少含量;其次,需要对K-B混合指示剂进行均匀的研磨:通过此种方式,保证酸性铬蓝K、萘酚绿B、硝酸钾混合均匀,确保实验加入后显示蓝色且终点不变色。

4 结束语

在我国现行的水泥化学分析方法当中明确规定,在应用K-B指示剂干预水泥中氧化镁测定与分析作业的情况下,若出现终点颜色不正确、不明显等方面的问题,则需要通过对K-B指示剂使用剂量以及配合比例进行调整的方式,避免此问题对最终氧化镁的测定数据准确性产生不良的影响。

在本文有关以上问题的研究与分析过程当中,重点研究了在应用K-B指示剂对水泥样品中氧化镁含量进行测定的过程当中,酸性铬蓝分析纯试剂以及萘酚绿分析纯试剂的合理配合比例,同时确定了K-B混合指示剂的有效干预剂量。

实践证实:在将K-B指示剂的混合比例确定为:1.0(酸性铬蓝分析纯试剂):1.2(萘酚绿分析纯试剂),同时将K-B指示剂的加入量设定为0.1g的条件下,可确保滴定终点颜色的明确性,并将实际误差控制在允许误差范围之内,因而值得进一步的推广并加以应用。

参考文献:

[1]王述银,董维佳,王迎春等.中低热微膨胀水泥混凝土性能试验研究[J].水利学报,2000(4):24-28.

[2]唐小丽,刘昌胜.重烧氧化镁粉的活性测定[J].华东理工大学学报(自然科学版),2001,27(2):157-160.

需求分析示例例7

【关键词】儿科患儿及家属;护理;需求;满意度

近几年来,快速高科技的发展对整个医疗护理体系带来较大的冲击,现代儿科护理人员应掌握科技化、现代化、综合化的先进知识与技能,才能确保护理质量安全,很多因素影响护理质量的效果,而患儿及家属作为被护理对象,是护理质量工作中最主要的因素,所以对住院患儿及家属进行正确需求评价并协助满足是护理人员的重要责任。本研究问卷调查,为进一步提高护理服务质量、促进患者全面早日康复提供依据。

1 对象与方法

1.1 研究对象本研究以立意取样方式调查内蒙古妇幼保健院住院病房患儿及家属共100例发放调查问卷,回收有效问卷94份,问卷有效率94%,94例中3~5岁患儿30例,6~10岁30例,完全不能自理患儿的家属40例。

1.2 方法采用问卷调查法。以Likert量表五分法来计算(51,表示非常满意,满意,尚可,不满意,非常不满意)。问卷内容分三部分:患儿的的基本资料、需求内容及满意度内容。患儿的基本资料为年龄、性别、自理程度、住院天数。需求内容分别由环境设备、专业技能、操作政策、家属对护理服务需求程度、护理关怀5方面构成。问卷采取无记名方式直接发给患儿或家属,当场回收,完成每份问卷大约需要15~20分钟。

1.3 资料分析应用spss套装软件作资料处理与统计分析,统计方法有X2,one-way,ANOVA,pair-t及step-wise multiple regression。

2 结 果

2.1 患儿及家属对护理需求之分布,见表1。

以one-way ANOVA作分析,且事后以Bon-ferroni test作比较。结果显示在整体对护理服务需求程度已CCU值最高,BC最低,在护理关怀及环境设备两方面只需求CCU显著高于BC,而在专业技能及探视政策两方面之需求均无差异。

2.2 家属对护理服务满意度之分布,见表2。

以one-way ANOVA作分析,且事后以Bon-ferroni test作比较。结果显示在整体对护理关怀、专业技能及环境设备三方面之满意度CCU均显著高于其他单位,而在探视政策之满意度均无差异。

2.3 家属对护理服务需求与满意度之比较以Pair-t test作比较结果显示在整体护理服务需求与满意度之比较(FnnFns)以CCU可达满意程度;在护理关怀需求与满意度之比较(FnnFns)以CUU,BC,SI可达满意程度,在专业技能需求与满意度之比较(FnnFns)易CUU可达满意程度,在环境设备需求与满意度之比较(FnnFns)以CUU,BC,SI可达满意程序,在探视政策需求与满意度之比较(FvnFvs)以CCU可达满意程度。

2.4 预测家属需求之分析以Multiple Regression作分析。结果显示家属年龄越大,对环境设备需求越多;患者住院天数越多,对护理关怀需求越多;患者住院天数越多,家属对探视需求越多;患者住院天数越多,家属对护理服务需求越多;患者住院天数越少,则家属对护理服务需求越高,亦即表示第一次住院患儿之家属其对护理服务之需求最高。

2.5 预测家属满意度之分析以Multiple Regression作分析。结果显示护理人员的临床经验与专业技能、护理关怀及整体护理服务之满意度相关,而与环境设备,探视政策是无关的。

3 结 论

3.1住院患儿家属整体护理服务需求平均为4.24分,整体护理服务满意度平均分为3.96分。

3.2 就整体对护理服务需求:CCU需求显著最高,且其中对护理关怀、环境设备之需求,CCU显著高于BC。

3.3 就整体对护理服务满意度:其中对护理关怀、专业技能、环境设备之满意度,CCU显著较高。

3.4 就整体护理需求与满意度作比较,CCU其对护理服务之整体需求大满意程度。

3.5 家属年龄越大,住院天数越多,住院次数越少,则家属对护理服务之需求会越多。

需求分析示例例8

1软件需求分析

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。包括业务需求、用户需求、系统需求3个不同层次。在需求获取阶段所得到的需求是杂乱的而不明确的,很多需求既重复又矛盾,而一个合格的需求描述应该具备完整性、可测试性、确定性、无歧义、可跟踪性、正确性、必要性等特性,而需求分析就是把这些杂乱的用户要求和期望转化有效而合格的需求描述的过程。首先,系统分析师通过对所获取的需求进行分类,创建出不同的业务模型:通过由领域专家(当系统分析师具有足够的领域经验时,可泛化为领域专家)途径得到业务类模型,制作出被领域广泛认可的需求模型;通过与客户/用户沟通得到业务用例模型,获得当前业务的独有特征,再将两个需求集合统一,构成业务模型。1.1需求分析的方法在软件工程的研究中,人们提出了多种需求分析的方法,其中主要有结构化分析法(StructureAnalysis,SA)、面向对象分析法(Object-OrientedAnalysis,OOA)和面向问题域的方法。另外,还有一些形式化方法,但由于实用性不强,一般只用在学术研究中。1.1.1SA方法SA方法主要关注于功能的分层和分解。这非常符合人们自上而下,逐步分解问题直到可解决的自然思考方式。但通过细分系统模块的功能来描述整个系统做法,很容易混淆需求和设计的界限,使系统分析师感到迷惑,不知道系统需求应该详细到何种程度。并且从用户的角度来看,他们并不想了解系统内部结构和设计,他们所关心的是系统所能提供的服务。SA方法模型的核心是数据字典(DataDictionary,DD),围绕这个核心分3个层次的模型,分别是:数据模型、功能模型和行为模型(也称状态模型)。1.1.2OOA方法OOA方法主要是运用面向对象的方法,对问题域进行分析和理解。OOA模型独立于具体实现,即不考虑与系统具体实现有关的因素。仅思考“做什么”的问题。OOA使用统一建模语言进行需求的分析,利用用例模型获取需求,进而由分析模型描述系统的基本逻辑结构等。统一建模语言(UnifiedModelingLanguage,UML)通过逻辑视图、进程视图、实现视图、部署视图以及用例视图来体现系统架构。其中又包含了多种不同的图来对所开发系统的某一特定方面进行分析。1.1.3PODA方法面向问题域的分析方法(ProblemOrientedDomainAnalysis,PODA)是一项很新的技术,目前还处于研究阶段,它主要关注问题域,并关注系统实现的待求行为,用一个文档对解系统的待求行为进行描述。1.2结构化分析方法实例下面以一个嵌入式接口处理软件为例,介绍结构化分析方法的实例。该软件使用串口1与控制器进行交互:要求具备串口升级功能,要求具备由控制器进行启动模式设置完成重启、保存控制器发送的重要配置数据以及将常规指令通过串口2转发至一个外部模块。下面用状态转换图(StateTransitionDiagram,STD)以及数据流图(DataFlowDiagram,DFD)举例说明结构化分析方法。根据以上需求可分析出当程序正常启动后进入就绪状态,等待串口语句指令:若接收到升级指令则进入升级状态,升级过程中等待升级数据包,升级完成程序结束等待重启;若接收到启动指令,则进入重启状态;若接收到配置及常规转发指令则完成不同状态处理后重新进入就绪状态。数据流图按照自顶向下的分解方法,首先绘制一张顶层图,将整个待开发系统表示为一个加工。系统顶层如图1所示,顶层用来描述系统有什么输入输出的数据流,与哪些外部实体直接相关。完成顶层图建模之后,在此基础上进一步分解,得到图2的1层图示例,1层图将系统细化为3个加工。继续对1层图中的加工1进行分解,并将所分解的加工命名为1.1,1.2……,可以看到在细化的2层图中引入了数据存储,看到对于配置参数、启动设置数据等需要进行存储操作。就这样在不断细化的过程中完成分析工作。1.3面向对象分析方法实例同样根据上述需求的例子,利用面向对象的分析方法进行分析,通过分析不同参与者所关注的不同需求,得到以下的用例图示例,如图4所示。在获取用例后,还需要继续深入分析,对用例间的活动关系进行研究,同时对升级用例进行了细化分析,便得到了以下的活动图示例。在后续分析中可使用该方法进行进一步的活动细化。

2软件需求管理

需求是软件项目成功的核心所在,它是后续软件工作开展的基础和基石。在软件需求工程中,需求管理贯穿于整个过程。首先,最重要的是系统分析师应充分思考客户的需求,制定计划前要有充分的沟通,若这点没有实现,继续展开下一步制作,只会使得双方的理念偏离越来越大,最终做出来的软件也很有可能不符合用户的商业用途。编写需求文档,确定需求的范围和标准,加以约束限制,然后对需求进行细化,在具体实施过程中还需进行不断地调整。有时计划赶不上变化,受许多非确定因素影响,若不能及时有效处理这些改变,将会拖延工期,面临很大的风险。系统设计师对系统自身需求、客户需求都要有深刻认识,要充分了解各个阶段的计划,预测软件开发的进程,软件生产做到有目的性、阶段性、可行性,才能保证项目开发的顺利进行。在需求管理中,应该认识到整个需求开发过程的各个阶段并不是瀑布式发展的,而是应该采用迭代方式。由这一思想去进行需求管理及控制,保证项目的顺利进行是非常有必要的。需求管理涉及3个主要问题:将需求进行标识、分类以及组织,并为需求建立文档;管理需求的变更,说明不可避免的需要变更是如何被提出、协商、确认的,并且将整个变更过程记录在案;对需求进行跟踪,保持需求和软件产品之间的一致性,及相互关联性。[参考文献][1]雷斯泽克,马克扎克.需求分析与系统设计[M].马素霞,王素琴,谢萍,译.北京:机械工业出版社,2009.[2]张友生.系统分析师教程[M].北京:清华大学出版社,2010.[3]李超,谢坤武.软件需求分析方法研究进展[J].湖北民族学院学报(自然科学版),2013(2):204-211.间的一致性,及相互关联性。图5活动图示例2.1需求变更的原因分析需求变化问题是一直存在的,也是不可避免的,需求不可能一开始就做到百分之百完善,往往都需要在后续阶段不断地改进,对于项目团队而言,必须要正确对待变更,按照既定流程管理变更,尽量降低由于变更带来的成本、进度及质量的负面影响。需求变更的原因常见有:(1)最初对用户需求缺乏认识,产生了错误,需要改变;(2)用户产业有了变化,软件开发概念也要随之改变;(3)需求了解不够全面,需求要增加;(4)系统的升级换代使软件的运行环境发生改变,软件的兼容性必须满足,安全性也必须提高。无论是哪种情况所导致的需求变更通常都意味着新需求的增加和原有需求的修改,对于较少发生的减少需求的情况,则比较容易处理。无论对何种变更,都必须采取规范的流程去管理,以保证变更后不会带来新的问题。2.2需求变更的管理控制为保证需求变更不对软件质量产生负面影响,必须规范软件开发过程,开发出标准的管理流程。近些年,软件大量生产,若没有一个规范统一的开发流程模式,软件开发过程中由于需求的变更,增加了生产工期,生产成本提高,扩大了风险,很可能导致项目失败。需求变更动机往往是为了满足用户需要,顺应市场的动态变化,但是为了能使整个工程能够如期完成,必须制定一个合理有效的变更机制,确定一个变化范围,考虑到软件制作的合理性,不能一味地听从用户的体验需求,而不思考项目组能否在不违背完整性约束的条件下开发出软件。对以往的需求变更进行收集、整理、分类,将变更方案的档案记录下来,在下次遇到需求变更时能够快速应对,迅速制作出处理方案。软件开发做到严格按照流程实施,对需求变更流程路线做到统一规范。首先是对各种需求变更的详细原因进行收集,并写成需求变更请求报告,提交评审小组进行变更评审。在需求评审过程中,对需求变更项目进行审查,将可执行的需求挑选出来,不合理的需求进行排除,还有一部分尚不确定的还需要和用户进行下一阶段的沟通处理,再次通过审核,直到通过评审才能到下一步的流程。而当变更周期完成后,还需要对变更情况进行测试及跟踪。在中途有新的变更时,需要通重新进行这一流程处理。因此看似简单的变更,实施过程中却并不简单。只有严格按照规定流程进行管理,才能得到质量保证与质量的控制。初步的需求变更完成后,为了加强需求变更后的准确性,技术人员必须对软件进行测试,检查该阶段的性能,保证与其他方面的合理衔接,预测软件的整体运行情况,做到一致和统一,而质量控制部门也必须有质量保证人员执行测试,保证得到高质量的最终产品。

需求分析示例例9

中图分类号:TP182文献标识码:A文章编号:1009-3044(2011)09-2081-04

UML-based Clinical Nutrition Diet for Diabetes Expert System for Configuration Design

YANG Ke-rong1, HAN Xing-shun2, LIU Ying3

(1.Zunyi Medical College, Zunyi 563000, China; 2.Guizhou College of Finance and Economics, Guiyang 550004, China; 3.Zunyi Centers for Disease Control and Prevention, Zunyi 563000, China)

Abstract: Unified modeling language (UML) is an object-oriented modeling language standard. In this article, the prototype that diabetes clinical nutrition dietary configuration expert system, based on UML technology and methods to analysis and design the system.

Key words: diabetes clinical nutrition dietary configuration; expert system; unified modeling language

UML(Unified Modeling Language)作为面向对象分析与设计的一种标准,有助于解决系统设计与开发过程中各类人员(系统分析师,软件设计员,客户,用户等)之间相互交流困难的难题。UML是面向对象分析与设计方法的发展的高潮产物,它融入了软件工程领域的新思想、新方法和新技术,还支持从需求分析开始的软件开发的全过程,最终统一为大众所接受的标准建模语言[1]。

本文把面向对象的设计方法运用于B/S结构的软件系统中,利用Sparx Systems 的Enterprise ArchitectUML工具完成B/S结构的糖尿病临床营养膳食配置专家系统的UML建模;通过这种基于UML的内聚式、迭代式的建模设计,清晰展现系统的逻辑和框架结构,并设计出一套 B/S 模式糖尿病临床营养膳食配置专家系统的UML模型。

1 UML简介

UML是一种可视化的、通用的、离散的建模语言,它能够让系统构造者用标准的、易于理解的方式建立起能够表达他们设计思想的系统蓝图,并且提供一种机制,以便于不同的人之间有效地共享和交流设计成果。

每一种UML 的视图都是由一个或多个图组成的,一个图就是系统架构在某个侧面的表示。统一建模语言按面向对象的思想,其过程大致可以分成三个环节:用例建模、静态建模、动态建模。它们从不同的角度形成系统的不同视图,一类为静态视图, 包含用例图、类图、对象图、包图、组件图和配置图。另一类为动态视图,包括状态图、活动图、顺序图和协作图[2]。

Enterprise Architect的UML可视化建模系统支持从系统需求、系统分析到系统设计的整个建模过程。在需求分析阶段, UML可以通过用例模型来捕获用户需求。通过需求建模,描述对系统感兴趣的外部角色及其对用例的功能要求。在分析和设计阶段,通过UML的静态建模和动态建模对问题域的对象建模,描述类的属性、类之间的关系、系统动态特征。编码是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。 UML模型还可作为测试阶段的依据。同 UML还支持对系统体系结构的建模。

2 专家系统简介

2.1 什么是专家系统

在一般意义上,专家系统是指一个含有某个领域专家的大量的专业知识与专业经验的智能计算机程序系统,它的智能化主要表现为能够在特定的领域内模仿人类专家思维来求解复杂问题。例如,一个医学专家系统就能够像真正的专家一样,诊断病人的疾病,判别出病情的严重性,并给出相应的处方和治疗建议等。专家系统的基本结构如图1所示,其中箭头方向为数据流动的方向。

2.2 专家系统的构成

专家系统通常由、知识库、推理机、解释器、综合数据库等构成。其中:

1)知识库:用来存放专家提供的知识。专家系统的问题求解过程是通过知识库中的知识来模拟专家的思维方式的,因此,知识库中知识的质量和数量决定着专家系统的质量水平。

2)综合数据库:专门用于存储推理过程中所需的原始数据、中间结果和最终结论,往往是作为暂时的存储区。

3)解释器:能够根据用户的提问,对结论、求解过程做出说明,能够向用户解释专家系统的行为,包括解释推理结论的正确性以及系统输出其它候选的原因。

4)推理机:针对当前问题的条件或已知信息,反复匹配知识库中的规则,获得新的结论,以得到问题求解结果。推理机就如同专家解决问题的思维方式,知识库就是通过推理机来实现其价值的。

5)人机界面:能够使系统与用户进行对话,使用户能够输入必要的数据、提出问题和了解推理过程及推理结果等。人机界面是系统与用户进行交流时的界面。通过该界面,用户输入基本信息、回答系统提出的相关问题,并输出推理结果及相关的解释等。

3 糖尿病临床营养膳食配置专家系统的UML设计

3.1 糖尿病临床营养膳食配置专家系统

糖尿病是一种常见的内分泌代谢疾病,是由于胰岛素分泌及(或)作用缺陷引起的以血糖升高为特征的代谢病。限于目前的医学水平,糖尿病还是一种不可根治的慢性疾病,因此糖尿病需要持续的医疗照顾,而饮食治疗是所有糖尿病治疗的基础,是糖尿病自然病程中任何阶段预防和控制糖尿病必不可少的措施。

随着信息技术的高速发展,计算机技术已应用到社会生活的各个领域,在医学上也得到长足发展,利用计算机高速运算、网络等技术,使得医生的诊断更加精确和高效。而糖尿病这种常见的流行性内分泌疾病的临床治疗更是离不开计算机技术。针对糖尿病,如何利用计算机系统对其营养膳食进行个性化配置,并为糖尿病患者的临床治疗提供平衡的营养食谱,是此专家系统研究的主要内容。

经过对糖尿病临床营养膳食配置专家系统的边界确定,功能分析,得出如图2所示的糖尿病临床营养膳食配置专家系统的工作流程图。

3.2 系统的用户和角色

系统分析要求接触用户,同时系统还要能够控制不同的用户角色和权限。通过对用户进行分类并了解他们的需求,从而确定安全机制、功能限制方案、用户界面分组和对具体内容的需求。

通过对此专家系统的分析,确定了如图3所示的几组不同的系统用户(在UML 中称为Actor , 即参与者) 。

3.3 系统用例模型

需求建模的过程就是用例的获取过程。用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。对系统需求的建模是通过UML的用例(USE CASE)图实现的。用例模型描述的是外部执行者(Actor)所理解的系统功能。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和UML的各个模型[3]。

通过对系统的参与者及其主要活动的分析,得到了如图4所示的糖尿病临床营养膳食配置专家系统用例模型。图中的椭圆是用例,表示用户与计算机之间的一次典型交互作用,图形化表示的小人是执行者,表示用户在系统中所扮演的角色,用例和执行者之间的连线表示两者之间的关联。通过用例图,使得设计者在系统设计的最初阶段将主要精力集中在系统的功能上,而不是系统的具体实现上。对于比较复杂的系统,可以增加活动图显示活动流程和并发行为,使得建立的需求模型更加完整。

3.4 系统功能分析与设计

为了让系统设计能够以结构、组织方式和代码重用的形式表现出来,要对系统进行设计规划,设计阶段应该与分析阶段 交迭。需求是不断地发展,而设计本身也会推动需求的发展(反之亦然) 。

糖尿病临床营养膳食配置专家系统的建模设计中,以下3个方面的问题是要关注的:业务对象的表示、业务活动的实现、用户界面的组织。

3.4.1 业务对象的表示

在糖尿病营养膳食专家系统中, 业务对象主要是数据库和解决数据实体类的表示方式。在糖尿病营养膳食专家系统的建模中,外专的基本信息和参加学术活动模块及学术活动模块的静态模型可以用类 图表示(如图5所示) ,(图中只列了一些关键信息)其中的空心箭头表示了这些实体类对共用实体(Common Entity) 的泛化关系, 继承Common Entity 的公用方法,本图中没有显示这些实体的私有属性和方法。

3.4.2 业务活动的实现

业务服务的实现需要完成的功能是各种业务规则和逻辑的实现,如学术活动模块的信息录入、修改、删除、查询。每个模块的信息录入、修改、删 除、查询,业务规则和逻辑的实现基本相似,没有太多的规律可循。采用UML 来进行业务服务的建模,可以使用UML 的序列图、状态图。这个部分的工作,通常通过一系列的类之间的交互来完成。

在研究系统中一般用户的活动状态的基础上,得出了如图6所示的状态图。圆方框表示了用户登录系统后状态变化的过程。

图6 糖尿病临床营养膳食配置专家系统用户状态图

根据状态图和图2所示的流程,确定了如图7所示的序列图。

因为在糖尿病营养膳食专家系统中糖尿病患者和营养专家的操作时序和动作有所不同,在对系统的分析后,画出如图8和图9所示的序列图。

3.4.3 用户界面的组织

用户界面布局图能够帮助组织系统页面、文件、服务的布局结构。在UML 中,对于页面和文件的组织,可以使用构件图(Component Diagram) 或类图(Class Diagram) 建模型。本系统中使用类图对界面组织建模,页面结构以及各种业务服务被捆绑到不同的区域。

3.5 系统实现

系统实现就是对类进行编程的过程, 将设计模型转换成能够运行的程序代码。本系统采用浏览器/服务器(B/S)结构,是由数据库服务器、应用服务器和客户机组成的3层体系结构,为了实现这个系统,依据本系统各方面的特点,选用SQL Server 2005作为后台数据库,面向对象程序设计语言C#.net作为前端开发工具进行编程。在系统建模过程中,使用Enterprise Architect作为本系统的UML分析与设计、软件的实现与测试工具, 并建立相应的软件模型;并利用Enterprise Architect逆向工程的功能修改模型中的缺陷。

4 结束语

建模过程实际上就是描述系统功能、构成的过程, 本文利用UML 面向对象建模机制对糖尿病营养膳食专家系统的进行分析设计, 并在建模过程中充分发挥UML 语言优势, 从系统分析、设计和实现等方面充分体现面向对象方法的主要思想, 有助于开发人员更好地理解答疑流程, 减少语义差异, 并以功能方式建立模型, 从不同角度描述系统, 界面和实现分离, 使系统结构良好、接口清晰, 为后续的程序开发打下良好基础。

UML是理解和分析系统结构的有力工具,其建模方式的标准化,提高了糖尿病营养膳食专家系统开发的规范性和实用性,提高了软件开发效率和软件用户层的可重用性。笔者在糖尿病营养膳食专家系统的建模和开发中,将UML应用于系统开发的各个阶段,建立了系统的需求模型、静态模型和动态模型。这种基UML建模的迭代式开发方法具有传统开发方法无可比拟的优点[4]。UML建模使系统设计完全面向对象 , 实现了信息封装、数据抽象。UML能够帮助人们轻松地构造出 B/S 结构系统的模型。在一定程度上实现了软件开发的自动化,实现了设计和编码的无缝的连接,提高了软件开发的效率和质量。

参考文献:

[1] Boggs W,Boggs M.UML与Rational Rose 2002 从入门到精通[M].邱仲潘,译.北京:电子工业出版社,2002.

需求分析示例例10

中图分类号:TP315文献标识码:A 文章编号:1009-3044(2008)29-0397-03

Modeling of Network Examination System Based on UML

WANG Hui

(Department of Information technology,Jingzhou Institute of Technology,Jingzhou 434100,China)

Abstract: This paper presents background knowledge for UML and its basic model.Based on analysis for Network Examination System, we design model of Network Examination System based on example chart,class chart, precedence diagram and coordination diagram of UML. It is beneficial to development and maintenance during the late stages of System.

Key words: Unified Modeling Language; example chart; class chart; precedence diagram; coordination diagram; network examination system

1 引言

考试是教学过程中的一个重要环节,也是检验教学效果的一个主要手段,但传统的考试方式,局限性大、资源浪费严重,不能适应远程教育的要求,取而代之的网上无纸化考试方式。基于网络的考试系统的应用,能减轻教师的评卷工作量,加快教学信息的反馈等,已成为一种发展趋势。

考试要求考试系统必须具有很强的稳定性、可维护性和可重用性。面向对象的系统分析方法被认为是最具发展潜力的分析方法。UML(Unified Modeling Language)[1-2]是Rational Software公司研制的一种基于面向对象技术的、定义良好、易于表达、功能强大且普遍适用的描述系统架构的建模语言。它涵盖了面向对象的分析、设计和实现,融合了早期面向对象建模方法和各种建模语言的优点,并融入了软件工程领域的新思想、新方法和新技术,为面向对象系统的开发、软件自动化工具与环境提供了丰富的、严谨的、扩充性强的表达方式。使用UML 进行系统分析和设计,可以加速开发进程,提高代码质量,支持动态的业务需求,能促进软件复用,使系统功能层次清楚,角色任务明确,便于团队沟通,可以提高工作效率,保证系统设计的可靠性。它使得整个软件分析设计相对传统E-R图来说更有助于提高开发效率。

本文以网上考试系统的分析为例,给出了基于UML的面向对象的系统建模的方法。通过使用UML 建模语言和Rational Rose工具对系统进行建模,给出了考试系统的用例图、类图、顺序图和协作图,这对后期系统的开发和维护起到了很好的效果。

2 UML建模简介

UML 是由著名的三位技术专家Gray Booch、Jim Rum baugh 和Ivar Jacobson 发起,在Booch、OMT和OOSE方法基础上的完善。它是一种可以对复杂系统的各个侧面进行可视化描述、构造系统模型以及建立和维护各种所需文档的标准的图形化建模语言,是汇集了多种面向对象建模技术的精华而发展起来并成为面向对象建模语言的工业标准。UML 采用的是一种图形表示法,即它将模型中的信息用标准图形元素直观的显示。建立模型后,所有重要的信息将一目了然。例如,用户可以通过模型直观地看到用户与系统间的交互,分析人员可以看到系统对象间的交互,开发人员可以看到要开发的对象和每个对象的任务,测试人员可以看到对象间的交互并根据这些交互准备测试案例,项目管理人员可以看到整个系统各部分的交互。

UML可以对任何具有静态结构和动态行为的系统进行建模。UML共定义了10种模型图从静态与动态两方面来描述系统。静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系,表示静态结构的模型图有用例图、类图、对象图、组件图和部署图;动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制,表示动态行为的模型图有顺序图、协作图、活动图和状态图。此外,UML还定义了一些关系:类与类之间的关系有关联、继承(泛化)、依赖和聚合,用例与用例之间的关系有包含、扩展和泛化。

UML定义的五类、共10种模型图如下[3]:

1) 第一类是用例图。它从用户的角度描述系统的功能,并指出各功能的操作者。用例图有助于系统开发者与用户之间进行交流,以获取用户需求。

2) 第二类是静态图,包括类图、对象图和包图。其中类图用于定义系统中的类,包括描述类之间的联系(如关联、依赖、聚合等)以及类的内部结构,即类的属性和操作;对象图显示类的对象实例,一个对象图是类图的一个实例;包图由包或类组成,主要表示包与包、或包与类之间的关系,用于描述系统的分层结构。

3) 第三类是行为图,描述系统的动态模型和组成对象间的交互关系。一种是状态图,它描述一类对象的所有可能的状态以及事件发生时状态的转移条件;另一种是活动图,它描述为满足用例要求所要进行的活动以及活动间的约束关系。

4) 第四类是交互图,它描述对象间的交互关系,系动态视图。一种称之为顺序图,用以显示对象之间的动态合作关系;另一种是协作图,它着重描述对象间的协作关系。

5) 第五类是实现图,包括构件图和配置图。构件图描述代码部件的物理结构以及各部件之间的依赖关系;配置图定义系统中软硬件的物理体系结构。这些图为系统的分析、开发提供了多种图形表示,它们的有机结合就有可能分析与构造一个一致的系统。

另外,Rose 是美国Rational 公司的可视化UML建模工具,是UML市场上领先的重量级产品。可以用来先建模系统再编写代码,从而一开始就保证系统结构合理。利用模型可以更方便地捕获设计缺陷,从而以较低成本修正这些缺陷。Rational Rose还可以帮助开发人员产生框架代码,适用于多种程序开发语言。

下面以网上考试系统为例,介绍运用UML 的建模机制来进行面向对象的系统建模的完整过程。

3基于UML的网上考试系统建模过程

运用UML 进行面向对象的系统分析设计,其过程通常由3个步骤组成:首先是描述需求,其次是根据需求建立系统的静态模型,以构造系统的结构,最后是描述系统的行为。其中前两步中所建立的模型都是静态的,而在第三步中所建立的模型或者是可以执行、或者是执行时的时序图或交互图,是动态的。

3.1系统需求分析

需求分析的目的就是确定系统的功能,而UML的用例图能形象地描述系统的功能。用例图展示了系统的参与者(角色)、用例以及它们之间的相互关系。角色是指位于所工作的系统外部的人或其它系统。用例就是用户因某外部事件而与计算机进行的一次交互。建立用例图,首先要识别系统的使用者和相关外部系统,确立好角色(Actor),然后再依据系统功能来建立用例图。

在网上考试系统中系统的参与者有三种:一是系统管理员,二是教师,三是考生。系统管理员管理题库的增加、删除、修改和用户权限的分配。教师可以自主管理自己权限下的试题和试卷,对其进行添加、更改、删除、组卷以及批阅试卷等操作。学生则主要是进行考试。针对这三种用户,系统可以分为三大模块:用户管理模块、考试管理模块和试题管理模块。本文主要围绕考试管理模块进行建模。

由上述的需求分析,可以定义考试系统全局用例图,如图1所示。

3.2 系统总体设计

使用UML对系统进行总体设计,即建立系统的对象模型。系统的对象模型通常包括两个部分:静态模型和动态模型。在此阶段, 由需求分析入手,建立系统的静态模型与动态模型。

3.2.1 系统静态模型

用例图只考虑系统应该提供什么样的功能,而对这些功能的内部运作情况不予考虑,为了揭示系统的内部关系,需要建立系统的静态模型。

系统静态模型主要是对系统静态结构的描述。在UML中,系统的静态结构主要用类图、包图及对象图进行描述。类图是对一类具有相同特征的对象的描述它定义了系统中的类以及类之间的联系,如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。由于类图描述的是一种静态关系,所以在系统的整个生命周期都是有效的。类图设计是面向对象方法的核心技术,通过类图将用例的实现具体到每个类中,从而完成设计走向细化的过程。

建立系统类图,主要找出系统中的类与对象以及它们之间的关系。即:首先需识别出系统中的对象,并进一步从对象中抽象出类,然后定义类的内部特征,最后找到类的外部关系。

根据系统用例图,可以确定系统中的主要类有:试题、试卷、教师、考生、系统管理员、考试。对于考试模块,它涉及到的主要类为:试题、试卷、考生、考试。“试卷”类和“试题”类之间存在聚合关系。“试卷”由一道道试题组成,每一道试题可能在多份试卷中。考生类和考试类有依赖关系,考试和试卷类之间是单向关联关系。考试模块的类图如图2所示。

3.2.2 系统动态模型

动态模型是对静态模型的补充。在UML中,动态模型主要用顺序图、协作图和状态图来描述。状态图描述一个对象所处的可能状态及状态之间的转换,并给出了状态变化序列的起点和终点。顺序图描述对象之间按照特定顺序发生的交互关系。协作图描述的是对象之间交互的语境与交互的对象的整体组织。UML通过顺序图、协作图和状态图来描述对象间的交互关系和交互顺序、对象的生命周期以及生命周期中对象可能存在的状态和状态间的转换约束[4-5]。

顺序图和协作图都是用来描述一个用例的行为,只是两者的侧重点不一样,顺序图着重体现交互的时间顺序,协作图主要表示对象与对象之间的连接。下面对网络考试系统的主要用例―考试用例建立顺序图和协作图。

1) 顺序图。考试用例的顺序图如图3所示。

从这个顺序图中可以看出,参与考试过程有四个对象类:考生、考试、试卷、试题。考试开始时,考生登录系统、考试对象检查考生考试状态,然后试卷对象从试题对象中读取考试试题供考生作答。每答完一道题,试卷对象保存考生答案,同时考试对象保存与考试相关的一些信息:考试剩余时间、当前题目号等。答题完毕后,考生对象选择交卷从而完成考试。

2) 协作图。它用于描述系统的行为是如何由系统的对象实现的。对考试系统的主要用例绘制协作图,以便深入地了解和表示系统的行为和各个对象的作用。考试用例协作图如图4所示。

4 结束语

网上考试系统实现了计算机考试整个过程的自动化,有很强的实用性。UML是一种面向对象的建模语言,可用于网络考试系统的建模。通过分析系统功能需求,得出系统的用户模型;通过分析并设计用例,得出系统的静态模型和动态模型;基于对系统的需求分析、总体设计,完成程序代码编写,最终实现系统的建立。使用UML建立系统模型,使开发流程变得十分清晰,提高了软件开发的效率和保证了软件设计的质量,有利于提高系统的稳定性、可维护性和可重用性,并为不同背景、不同领域下的专家、开发人员以及用户提供了一条标准的交流途径。

参考文献:

[1] 刘超,张莉.可视化面向对象建模技术[M].北京:北京航空航天大学出版社,1999.

[2] Larman C. UML和模式应用―面向对象分析与设计导论[M].姚淑珍,李虎,译.北京:机械工业出版社,2002.