需求分析示例篇1
关键词：需求分析;用例分析技术;用例模型;参与者
中图分类号：tp311.5文献标识码：B
文章编号：1004373X(2008)0304803
applicationofUseCasetechniqueinmilitaryRequirementanalysis
wanGmingqiang,QiaoBo
(instituteofCommandautomation,pLaUniversityofScienceandtechnology,nanjing,210007,China)
abstract：thisthesisgivesadetailaccountofthecharacteristicoftherequirementanalysisinmilitarysoftwareandthesuperiorityofusecasetechniqueinthecommunionbetweenthesoftwaredeveloperandtheuser.itexpoundsthatusecaseanalysistechnologycontributestoimprovetheefficiencyandthequalityofrequirementanalysisinmilitarysoftware,anditprobesintothestepsofusecaseanalysistechnologymodeling,describesaneffectivemethodbyusecasetechniqueaboutrequirementanalysisinmilitarysoftware.
Keywords：requirementanalysis;usecaseanalysistechnology;usecasemodeling;actor
1引言
需求分析是软件开发过程中一个十分重要的环节。需求分析的结果决定了软件系统能否符合用户的要求，也奠定了软件工程和项目管理的基础。在军事软件需求分析阶段，软件开发人员和军事人员都习惯于从自己的角度考虑问题，用自己的专业术语进行沟通，这就使得双方在软件需求方面容易产生误解，影响需求分析结果的正确性。因此，采用什么技术进行需求分析设计，对军事软件需求分析的效率高低和分析结果的正确与否有着直接的影响。
用例分析技术是面向对象的需求分析技术。用例分析技术比传统的需求分析技术更易于被用户所理解，是开发人员和用户之间针对系统需求进行沟通的一个有效手段。使用用例分析技术能够提高需求分析的效率,增强分析过程的科学性，是军事软件需求分析的重要途径。
2需求分析的概念和任务
需求是计算机应用系统必须为其用户所做的事,是系统必须提供的具体功能、特性、质量,以体现系统存在价值。需求分析一般分为需求获取、分析建模、需求描述3个步骤。软件需求分析的任务是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。他所做的工作是深入描述软件的功能和性能，确定软件设计的边界和软件同其他元素的接口，定义软件的其他有效性要求。
3军事需求分析的特点
军事软件系统的用户需求是一个十分复杂的问题，系统的成败首先在于他能否满足作战环境和使用软件系统的指挥员和参谋人员的作战需求。满足用户需求是软件系统必须具备的能力，良好的需求描述方法是系统开发的关键。而在军用软件系统需求分析中存在两个重要问题：
需求描述问题一方面，指挥人员由于缺乏使用系统的实践经验，很难把系统需求说得很清楚；另一方面，研制人员对作战指挥的需求缺乏实际体会，而且相当一部分系统开发的技术人员为非军事人员，对军用软件的特殊需要和指挥流程、指挥结构不够明确。
需求管理问题一方面，在系统建设过程中，需求变更会从需求层次起，影响后续的所有工作直至设计实现和检验，需求描述不能满足需求重用的需要；另一方面，需求描述通用性不强，由于多种原因引起的系统设计人员或技术骨干人员的变更，使系统研制的连续性受到破坏，新进入项目研发成员对原需求描述方法掌握需要时间，影响效率。
本文主要目的是针对军事软件系统需求在需求描述和需求管理方面存在的问题，通过运用科学、规范化的描述方法，来直观形象地反映系统需求，力求建立系统分析和软件设计阶段之间的桥梁，使需求描述具有互操作性并使之符合军事软件系统的功能和结构要求。
4用例分析技术
用例分析技术是一项源于实践的需求分析技术。他通过用例的参与者和用例以及用例之间的关系来描绘系统外在可见的需求，他从外部用户和外部系统的角度，分析和考察系统的行为，把需求与设计完全分离开来，并通过参与者与系统之间的交互关系描述系统对外提供的功能特性。这正好满足了用户的需求,因为他们并不真想了解系统的内部结构和设计,他们所关心的是系统能提供什么样的服务。所以，用例分析技术为解决现代软件需求问题提供了一个有效的解决方案。首先,他描述了待开发系统的功能需求；其次，他将系统看作黑盒，从外部参与者的角度理解系统；第三，他驱动了需求分析之后的各阶段的开发工作。不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段。因此用例分析技术适合军事软件系统需求分析的需要，用例模型在军事需求分析中的作用如图1所示。
图1用例模型在需求分析中的作用
4.1用例的概念
用例是系统外在可见的需求，定义参与者如何使用系统。每一个用例描述的是用户需要系统完成的某一个完整的功能，所有的用例共同描述从用户角度看到的系统的完整功能。用例主要有3方面的含义:
(1)用例通常是由最终用户或外部环境发起的。用例的发起者被称为参与者。参与者是同系统交互的所有事物,例如:人、其他的软件、硬件设备等。
(2)每个用例只描述单独的任务,而不能描述多个任务。
(3)用例必须产生一个对用户有意义的结果。
4.2用例建模
用例建模就是通过分析用户的功能性需求,从而得到用例模型的工作过程。用例建模的主要步骤为:
(1)确定参与者。
(2)确定用例。
(3)撰写用例规约。
4.3UmL中的用例图
用例图是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]DeanLeffingwell,Donwidrig.managingSoftwareRequirements:aUseCaseapproach[m].Secondedition.DeanLeffingwell,2004.
[2]SuzanneRobertson,JamesRobertson.masteringtheRequirementsprocess[m].addisonwesley,2003.
[3]DarylKulak,eamonnGuiney.UseCasesRequirementsinContext[m].Secondedition.addisonwesley,2004.
[4]王建军.UmL建模:实例分析[J].微计算机信息,2002(5):66―68.
[5]王晶,雷光秀.一种构造用例模型的方法研究[J].新疆石油天然气,2005,23(4):158―159.
作者简介王明强男，1979年出生，黑龙江双鸭山人，硕士研究生。主要研究方向为指挥自动化理论、软件工程。
需求分析示例篇2
在需求分析阶段，要对经过可行性分析所确定的系统目标和功能作进一步的详细论述，确定系统“做什么？”的问题，最终建立起目标系统的逻辑模型。
首先是获得当前系统的物理模型。物理模型是对当前系统的真实写照，可能是一个由人工操作的过程，也可能是一个已有的但需要改进的计算机系统。首先是要对现行系统进行分析、理解，了解它的组织情况、数据流向、输入输出，资源利用情况等，在分析的基础上画出它的物理模型。然后抽象出当前系统的逻辑模型。
逻辑模型是在物理模型基础上，去掉一些次要的因素，建立起反映系统本质的逻辑模型。接下来建立目标系统的逻辑模型。通过分析目标系统与当前系统在逻辑上的区别，建立符合用户需求的目标系统的逻辑模型。最后补充目标系统的逻辑模型。对目标系统进行补充完善,将一些次要的因素补充进去，例如出错处理等。
UmL（theUnifiedmodelingLanguage，即统一建模语言）是一种编制系统蓝图的标准化语言，可以对复杂的系统建立可视化的系统模型，目前已经被工业标准化组织omG（objectmanagementGroup）接受，一经推出便得到许多著名的计算机厂商如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方法，通过分层分解，逐步细化的方法来描述系统的功能。对于用例图，建议不要画的过于复杂，特别是用例之间的关系，因为复杂的用例图不仅不能让需求分析人员与客户之间更好的沟通，反而是制造了一种沟通障碍。
下一步就是编制每一个用例的详细说明，对用例说明的主要信息包括有:用例名称、编号、用例的简短描述、用例的参与者、与其他用例的管理、用例启动的前提条件、用例结束后的事后条件、用例的输入、输出、用例的执行事件流等。在实际项目中，我们并不一定要面面俱到，而是根据实际情况对用例描述进行裁减。其中有几点重要信息是不能裁减的:用例名称、描述、输入、输出、执行事件流、参与者。另外，如果实际情况需要，还可以使用mSVisio等工具画出界面的示意图来。
如上例所述，我们对每一个用例都进行详细的描述，建立当前系统的功能用例模型。需求沟通与分析是一个迭代的过程，通过与用户的不断沟通，最终达成对目标系统的一致理解。如果用户确认了需求分析的成果，一般是需求规格说明书之后，项目开始进入系统分析设计阶段，也就是开始构造目标系统的逻辑模型。
为了让系统设计能够以结构、组织方式和代码重用的形式表现出来，要对系统进行设计规划，设计阶段应该与分析阶段交迭。需求是不断地发展，而设计本身也会推动需求的发展(反之亦然)。在图书馆管理系统的建模设计中，以下3个方面的问题是要关注的:业务对象的表示、业务服务的实现、用户界面的组织。
业务对象的表示
在图书馆管理系统系统中，业务对象主要是数据库和数据实体类的表示方式。建模时，可以构造出系统的静态模型，也就是系统类图来表示。如下图则描述了借书这一用例的静态结构图。为了体现类之间的关系，在下图中没有显示出每一个类的属性和基本操作。
业务服务的实现
业务服务的实现需要完成的功能是各种业务规则和逻辑的实现,如借书处理的业务逻辑。每个模块的信息录入、修改、删除、查询等。业务规则和逻辑的实现基本相似，没有太多的规律可循。采用UmL来进行业务服务的建模，可以使用UmL的序列图、状态图、活动图。这个部分的工作,通常通过一系列的类之间的交互来完成。为了在更动态的层面上描述系统，UmL提供了许多其他类型的图。
对于B/S系统设计而言，情节图(ScenarioDiagram)特别有用。情节图分成两种:协作图(CollaborationDiagram)，序列图(SequenceDiagram)。UmL建模工具RationalRose能够从协作图生成序列图也可以从序列图生成协作图。例如，借阅书刊的业务过程可以采用如下序列图来描述:
借阅书刊过程主要包括:管理员选择“借阅书刊”菜单，弹出对话框，管理员输入书刊信息和用户信息，系统查找数据库，是否存在该种物理书刊，如果不存在，显示提示信息，用例结束;是否存在借阅者信息，如果不存在，显示提示信息，用例结束;否则，管理员单击确认按钮后，该图书借阅给该借阅者，系统存储借阅信息到数据库。
用户界面的组织
用户界面布局图能够帮助组织系统页面、文件、服务的布局结构。在UmL中，对于页面和文件的组织，可以使用构件图(ComponentDiagram)或类图(ClassDiagram)建模型。本系统中使用类图对界面组织建模，页面结构以及各种业务服务被捆绑到不同的区域。
在UmL中,系统的体系结构使用部署图(DeploymentDiagram)来完成。应用部署的规划对于规划整个B/S系统是很有用的。它确定了一种有效的应用部署的规划组织方式,还可以作为一个模式在多个类似B/S系统上应用。
在建模完成后，开发人员利用一些UmLCase工具如RationalRoSe生成程序代码框架，并对代码框架进行修改和补充，形成完整代码;而且，还可根据代码逆向生成UmL模型。这就较好地保证了模型与代码的一致性。
测试必须在整个项目周期中进行，对每个阶段都要用所建立的模型进行测试，这样才能保证开发的质量，减少开发的风险。
需求分析示例篇3
【摘要】目的分析儿科住院患儿及家属对护理服务需求及满意度的评分、探讨及影响之因素。方法选取住院患儿及家属共100例,发放调查问卷,回收有效问卷94份进行分析。结果患儿及家属需求广泛,渴望值太高,对医院的硬件设施需求比例较高。结论现成儿科护理服务内容应增多,软硬件需要加强,以促进宝宝早日康复。
【关键词】儿科患儿及家属;护理;需求;满意度
近几年来,快速高科技的发展对整个医疗护理体系带来较大的冲击,现代儿科护理人员应掌握科技化、现代化、综合化的先进知识与技能,才能确保护理质量安全,很多因素影响护理质量的效果,而患儿及家属作为被护理对象,是护理质量工作中最主要的因素,所以对住院患儿及家属进行正确需求评价并协助满足是护理人员的重要责任。本研究问卷调查,为进一步提高护理服务质量、促进患者全面早日康复提供依据。
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-wisemultipleregression。
2结果
2.1患儿及家属对护理需求之分布,见表1。
以one-wayanoVa作分析,且事后以Bon-ferronitest作比较。结果显示在整体对护理服务需求程度已CCU值最高,BC最低,在护理关怀及环境设备两方面只需求CCU显著高于BC,而在专业技能及探视政策两方面之需求均无差异。
2.2家属对护理服务满意度之分布,见表2。
以one-wayanoVa作分析,且事后以Bon-ferronitest作比较。结果显示在整体对护理关怀、专业技能及环境设备三方面之满意度CCU均显著高于其他单位,而在探视政策之满意度均无差异。
2.3家属对护理服务需求与满意度之比较以pair-ttest作比较结果显示在整体护理服务需求与满意度之比较(FnnFns)以CCU可达满意程度;在护理关怀需求与满意度之比较(FnnFns)以CUU,BC,Si可达满意程度,在专业技能需求与满意度之比较(FnnFns)易CUU可达满意程度,在环境设备需求与满意度之比较(FnnFns)以CUU,BC,Si可达满意程序,在探视政策需求与满意度之比较(FvnFvs)以CCU可达满意程度。
2.4预测家属需求之分析以multipleRegression作分析。结果显示家属年龄越大,对环境设备需求越多;患者住院天数越多,对护理关怀需求越多;患者住院天数越多,家属对探视需求越多;患者住院天数越多,家属对护理服务需求越多;患者住院天数越少,则家属对护理服务需求越高,亦即表示第一次住院患儿之家属其对护理服务之需求最高。
2.5预测家属满意度之分析以multipleRegression作分析。结果显示护理人员的临床经验与专业技能、护理关怀及整体护理服务之满意度相关,而与环境设备,探视政策是无关的。
3结论
3.1住院患儿家属整体护理服务需求平均为4.24分,整体护理服务满意度平均分为3.96分。
3.2就整体对护理服务需求:CCU需求显著最高,且其中对护理关怀、环境设备之需求,CCU显著高于BC。
3.3就整体对护理服务满意度:其中对护理关怀、专业技能、环境设备之满意度,CCU显著较高。
3.4就整体护理需求与满意度作比较,CCU其对护理服务之整体需求大满意程度。
3.5家属年龄越大,住院天数越多,住院次数越少,则家属对护理服务之需求会越多。
3.6护理人员的病房临床工作年资越久,则家属对护理服务满意度越高。
需求分析示例篇4
关键词：UmL；用例图；类图；顺序图；协作图；网上考试系统
中图分类号：tp315文献标识码：a文章编号：1009-3044(2008)29-0397-03
modelingofnetworkexaminationSystemBasedonUmL
wanGHui
(Departmentofinformationtechnology,Jingzhouinstituteoftechnology,Jingzhou434100,China)
abstract:thispaperpresentsbackgroundknowledgeforUmLanditsbasicmodel.BasedonanalysisfornetworkexaminationSystem,wedesignmodelofnetworkexaminationSystembasedonexamplechart,classchart,precedencediagramandcoordinationdiagramofUmL.itisbeneficialtodevelopmentandmaintenanceduringthelatestagesofSystem.
Keywords:UnifiedmodelingLanguage;examplechart;classchart;precedencediagram;coordinationdiagram;networkexaminationsystem
1引言
考试是教学过程中的一个重要环节，也是检验教学效果的一个主要手段，但传统的考试方式，局限性大、资源浪费严重，不能适应远程教育的要求，取而代之的网上无纸化考试方式。基于网络的考试系统的应用，能减轻教师的评卷工作量，加快教学信息的反馈等，已成为一种发展趋势。
考试要求考试系统必须具有很强的稳定性、可维护性和可重用性。面向对象的系统分析方法被认为是最具发展潜力的分析方法。UmL(UnifiedmodelingLanguage)[1-2]是RationalSoftware公司研制的一种基于面向对象技术的、定义良好、易于表达、功能强大且普遍适用的描述系统架构的建模语言。它涵盖了面向对象的分析、设计和实现，融合了早期面向对象建模方法和各种建模语言的优点，并融入了软件工程领域的新思想、新方法和新技术，为面向对象系统的开发、软件自动化工具与环境提供了丰富的、严谨的、扩充性强的表达方式。使用UmL进行系统分析和设计，可以加速开发进程，提高代码质量，支持动态的业务需求，能促进软件复用，使系统功能层次清楚，角色任务明确，便于团队沟通，可以提高工作效率，保证系统设计的可靠性。它使得整个软件分析设计相对传统e-R图来说更有助于提高开发效率。
本文以网上考试系统的分析为例，给出了基于UmL的面向对象的系统建模的方法。通过使用UmL建模语言和RationalRose工具对系统进行建模，给出了考试系统的用例图、类图、顺序图和协作图，这对后期系统的开发和维护起到了很好的效果。
2UmL建模简介
UmL是由著名的三位技术专家GrayBooch、JimRumbaugh和ivarJacobson发起，在Booch、omt和ooSe方法基础上的完善。它是一种可以对复杂系统的各个侧面进行可视化描述、构造系统模型以及建立和维护各种所需文档的标准的图形化建模语言，是汇集了多种面向对象建模技术的精华而发展起来并成为面向对象建模语言的工业标准。UmL采用的是一种图形表示法，即它将模型中的信息用标准图形元素直观的显示。建立模型后，所有重要的信息将一目了然。例如，用户可以通过模型直观地看到用户与系统间的交互，分析人员可以看到系统对象间的交互，开发人员可以看到要开发的对象和每个对象的任务，测试人员可以看到对象间的交互并根据这些交互准备测试案例，项目管理人员可以看到整个系统各部分的交互。
UmL可以对任何具有静态结构和动态行为的系统进行建模。UmL共定义了10种模型图从静态与动态两方面来描述系统。静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系，表示静态结构的模型图有用例图、类图、对象图、组件图和部署图；动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制，表示动态行为的模型图有顺序图、协作图、活动图和状态图。此外，UmL还定义了一些关系：类与类之间的关系有关联、继承（泛化）、依赖和聚合，用例与用例之间的关系有包含、扩展和泛化。
UmL定义的五类、共10种模型图如下[3]：
1)第一类是用例图。它从用户的角度描述系统的功能，并指出各功能的操作者。用例图有助于系统开发者与用户之间进行交流，以获取用户需求。
2)第二类是静态图，包括类图、对象图和包图。其中类图用于定义系统中的类，包括描述类之间的联系(如关联、依赖、聚合等)以及类的内部结构，即类的属性和操作；对象图显示类的对象实例，一个对象图是类图的一个实例；包图由包或类组成，主要表示包与包、或包与类之间的关系，用于描述系统的分层结构。
3)第三类是行为图，描述系统的动态模型和组成对象间的交互关系。一种是状态图，它描述一类对象的所有可能的状态以及事件发生时状态的转移条件；另一种是活动图，它描述为满足用例要求所要进行的活动以及活动间的约束关系。
4)第四类是交互图，它描述对象间的交互关系，系动态视图。一种称之为顺序图，用以显示对象之间的动态合作关系；另一种是协作图，它着重描述对象间的协作关系。
5)第五类是实现图，包括构件图和配置图。构件图描述代码部件的物理结构以及各部件之间的依赖关系；配置图定义系统中软硬件的物理体系结构。这些图为系统的分析、开发提供了多种图形表示，它们的有机结合就有可能分析与构造一个一致的系统。
另外，Rose是美国Rational公司的可视化UmL建模工具，是UmL市场上领先的重量级产品。可以用来先建模系统再编写代码，从而一开始就保证系统结构合理。利用模型可以更方便地捕获设计缺陷，从而以较低成本修正这些缺陷。RationalRose还可以帮助开发人员产生框架代码，适用于多种程序开发语言。
下面以网上考试系统为例，介绍运用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]LarmanC.UmL和模式应用―面向对象分析与设计导论[m].姚淑珍,李虎,译.北京:机械工业出版社,2002.
[3]周伯生,张莉.标准建模语言UmL及其支持环境[J].计算机世界,1998(43):24-25.
需求分析示例篇5
关键词：mBD；模型检测；nuSmV；规约
中图分类号：tp368.6文献标识码：a文章编号：1009-3044(2011)09-2028-02
无论从哪个方面来看，近年来已大量的用于商用和军用对安全性要求极高的密码协议软件，其大小和复杂性呈指数级增长。当前的验证方法已经不能有效的应对下一代密码协议软件。一些新的验证过程被发展增加分析技巧的测试，例如形式化方法。这些方法将帮助密码协议软件以一个合理的花费来验证从而达到要求的安全级别。
在过去形式化的方法没有广泛的使用主要有以下几个障碍：
1）构造单独分析模型的费用。
2）所构建模型和所设计的软件保持一致性的困难。
3）建模和分析使用一些不为大家所熟悉的符号。
4）没有足够的工具来应对工业化的问题
广泛传播和使用的mBD工具正在扫除前三个障碍。mBD倾向于使用占统治地位的描述（经常用图型）建模语言，这就使得实际的系统被构建之前可以在仿真的环境下执行。使用这样的建模语言允许工程师创造一个系统模型，在他们自己的桌上执行。更进一步工具现在发展到可以把设计模型翻译成分析模型从而可以被形式化的方法工具所检验，结果会返回到原始的模型等号中。这个过程支持原来的建模成果并且允许工程师在他们的领域用他们所熟悉的符号。
快速提高分析算法和由摩尔法则所预言的CpU性能稳定提升而价格下降正在消除第四个障碍。更快的算法和更便宜的硬件意味着在十年前不能分析完成的任务现在只是一秒钟的事情。
1模型检测
模型检测机有着高度的自动化，要求很少或不要求使用者的交互。一个模型检测机将考虑每个可能的状态和输入的组合来决定是否满足系统所要求的一系列的属性。如果其中有某一个不满足，模型检测机将会给出一个反例来显示那个属性是怎么样违反的。
这里有许多类型的模型检测机，每一个都有自己的长处和短处。我们有以BBDs为基础的模型检测器nuSmV可以分析超过10的120次方空间。以可满足性数模理论（SatisfiabilitymodulotheoryiesSmt）为基础的模型检测器例如SaL和prover使用一种归纳的形式能自动的证明模型所持属性。这允许检测器可以处理很大级别的模型，甚至包括无限状态空间模型。暗示的状态模型检测器例如二分图（BinaryDecisionDiagramsBDDs）存取每一个经历的状态的代表符号。这样暗示模型检测器可以允许处理比明示模型检测器要大得多的状态空间。明示的状态模型检测器例如Spin直接执行形式化模型并且存储每一个经历的状态。在一些情况下这使得以Smt为基础的模型检测器比明示或暗示状态空间模型检测器更难使用。
发展更有效率且更强算法的模型检测是当前研究的一个热点。在过去的十年我们已经取提了很大的提高，分析模型所要时间我们已经减少了几个数量级，且大大提高了可以分析模型的尺寸和复杂度。摩尔法则更进一步提高CpU的频率且价格更低使我们桌面电脑有更强的能力。所在这些都意味着更强大的模型检测工具可以为工程师所得到来分析工业级的规模的问题。
2验证过程
在以分析为基础的验证过程，我们一般认为对于一个特定的子系统有功能相关的要求。环境假定和约束限定了执行的环境。属性限定了子系统的行为（输出值或状态变量），该行为必须保证在指定的假定环境中所在的系统状态可以达到。属性其实就是一个简单且精确的反映其我们将要分析的系统需求的规约。
在需求被详细说明成待检验的属性，模型已经被构建来执行需求，这时形式化的分析可以开始了。模型被翻译成模型检测工具所认识的语言然后检验其属性。模型检测器然后执行其分析得出结果，要么报告属性是正确的，或提供一个反例来说明违反了其属性。
使用模型检测器的一个优点就是如果违反了属性可以产生一个反例，该反例可以确切的显示属性是怎么样违反的。这就给开发者提供了一个指导，即什么错了怎么样去改正它。仅仅通过模型检测器的输出对于一个大的系统是非常困难且很需要时间去判定错误的根本原因，但仿真的mBD工具这时就可以来重放其反例。
当一个反例被发现的时候，要采取正确行动来改正它。产生反例的原因可能是下面当中的其一：
1）需求错误
2）模型错误
3）属性形式化错误
4）不正确或丢失子系统的不变量
在实际中模型检测器从一组违反属性中可能产生一个在真实环境中没有意义的一个反例，即产生的反例在真实环境中不可能发生的。为了去掉这些在真实系统中不可能的反例，有时需要一些环境的约束。这些约束作为一个精确的环境假设的描述.
3nS协议实际应用
我们最初的尝试是使用该方法应用在一个实际的例子是needham-Schroeder(nS)协议是使用密钥分发中心KDC(KeyDistributionCenter)实现认证的经典协议.对称密码体制nSSK协议按功能划分为两个部分:获取共享密钥和双方身份认证。协议分析前提:完善保密(perfectencryption)前提,即协议采用的密码算法是完善保密的;参与协议运行的主体除了诚实的合法用户外,还有不怀好意的入侵者;入侵者的知识与能力,即使不知道加密部分的内容,也可重放他所看到的任何消息。
nS协议模式逻辑非常适合使用我们的翻译框架来和形式化的模型检测器例如nuSmV来分析。我们分析其模式逻辑由五个模式转换图，总共10个模式中，51个事件，85个转换。每一个模式图中一个状态的改变会至少影响一个，经常是多个别的模式图。即便每个单个的图可以直接的理解，但能抓住图之间的交互是非常困难的。
分析其早期模式逻辑的规约我们发现了3个错误。其中3个错误中的2个我们发现如果用传统的方法如测试方法是不能发现其错误的。
用这个分析方法其中一个主要优点当需求仍然在开发阶段的时候我们在研发过程早期就可以进行分析了。
4结束语
当前的研究主要集中进一步扩大模型检测器能有效应用检测模型的范围。我们的框架可以处理整型和定点数的类型，但新的分析方法需要要能处理更多的数据类型，如浮点数和非线性方程等。从分析算法的角度Smt模型检测器显得有非常好的前途。
随着mBD工具的越来越流行，模型检测器的功能越来越强大，使得形式化验证成为商业的实际应用。这解决了主要障碍中的一个，即在软件工程师所用的商用模型工具和已经存在的形式化验证工具架起了桥梁。这就让模型检测可以整合到开发过程从而模型可以自动分析，且不用付出很大的努力。
通过所做的一些检测案例我们感觉模型检测有很大的实际应用前途。我们可以在开发早期发现且改正设计错误，其中很多错误是通过测试是很难发现的。在研发早期消灭错误可以大大地减少整个软件开发的费用。
参考文献：
需求分析示例篇6
在民法案例的分析中，我国一直缺乏一套规范、严谨的分析方法和思维，每个人都根据自己的学术背景、思维模式来分析案例，欠缺一种规范的分析方法。在实务中，有一些法官常常是先确定了事实，然后就直接确定结论，其后为了支持结论再去寻找一些法律依据；也有的判决中，事实清楚，法律的适用也是正确的，但是没有对事实和法律的适用的连接点分析；还有的在判决中，常常从事实就直奔结论，判决缺乏推理过程，逻辑的三段论不能得到运用。这种状况表明逻辑三段论和民法解释学等方法在实务中未能得到广泛的认可和采用。由于缺乏统一的法学方法作为共同基础，这也导致在讨论时语境上的差异和沟通上的隔阂，并影响了法律人才的培养[1]。
请求权基础是民法实例研习的一种方法，有利于培养法律人处理实际问题的能力；也是司法实务实现正确推理、保障司法公正的手段，有利于法官素质的提高。
请求权基础理论
请求权规范基础是指可支持一方当事人得向他方当事人有所主张的法律规范，即为请求权规范基础，简称请求权基础。也就是说一方当事人在权利受到侵害时，若想使自己的权利得到法律上的救济需要依据何种法律规范来保护自己的合法权益、弥补损失。由于请求权在民法的诸多权利体系中占据着重要的地位，请求权的正确行使与实现将直接关系着民事主体的财产权和人身权能够得到有效的保护，并最终实现法律的保护、补偿等基本功能。
实体法上的请求权基础理论是通过分析具体案件而抽象总结出来的案例分析方法理论。www.133229.com在该理论的指导下，可以较准确地确定请求权及所依据的法律规范并以此去论断具体案件当事人间的权利义务关系，具有法学方法论的意义。
1、请求权基础分析案例方法的结构概括为“谁得向谁，依据何种法律规范，主张何种权利”。法官判案或当事人分析案例用的是形式逻辑三段论的方法，即案件事实为小前提，法律规范为大前提，然后找到大前提与小前提的联结点，最后得出结论。由于请求权基础案例分析法的结构模式是固定的，因此无论案情简单或繁杂，其思维步骤和程序是固定的。请求权基础分析方法通过对案件事实小前提的整理与说明，通过对法律规范大前提的解释，建立起大前提与小前提之间的联系，是形式逻辑三段论推理过程的一部分，这种方法其实是形式逻辑在法律思维中的运用，在具体运用过程中，它必须与法律解释方法相结合，本文由http://收集整理形成自己独特的分析方法。
2、用请求权基础分析案例的方法，有对请求权有检索的顺序的要求，即按照契约上请求权，无权等类似契约关系上请求权，无因管理上请求权，物权关系上请求权，不当得利请求权，侵权行为损害赔偿请求权，其他请求权。依此种顺序检查的目的“尽量避免于检讨某特定请求权基础时，受到前提问题的影响。”而且在面对具体的案例时原则上对请求权基础做通盘依序的检查，“藉此养成邃密深刻的思考；避免遗漏；维护当事人利益”。
3、构成要件的检视顺序，非但对数个请求权规范的检视有先后，对单个请求权规范之构成要件的检视也有次序。
4、经过以上检查，若某一请求权可以成立，则还需要检查于此请求权上是否存在抗辩。包括权利消灭和权利阻止抗辩。
基于请求权基础的案例分析方法
案例：a教授于3月1日接获b出版社寄来的《台湾法学百科全书》目录，载明该全书共十册，价款一万元，并附订书单一张。a教授于三月四日填妥订书单，即于上课后交c生回家途中于邮局投寄之。c生离去之后，a教授忆起其同事d教授曾参加该全书编辑工作，答应赠送一套，即自四楼研究室窗口呼叫，“不要投寄”，c生于下课钟声中误听为，“不要忘记”，点头离去，而投寄之。a教授于三月五日下午知其事，即以限时专送致函于b出版社，叙明是由，表示撤回订书单，仓促之间，未帖限时专送标签，并误投于平邮筒，延至三月七日上午实行到达。b出版社于三月六日上午收到a教授的订书单，即于当日下午寄发该百科全书，于三月九日到达，a教授拒绝受领。试问b出版社得主张何种权利[2]？
此案的分析堪称范本，极具启发意义，按照请求权基础理论架构、按照请求权检索顺序所做的分析展示如下：
1、b出版社得依法律规定，向a教授请求支付价金及受领标的物。理由：
（1）买卖契约的成立，须当事人就标的物及其价金互相同意。
首先，b出版社寄送的台湾法学百科全书第目录及订书单，仅为要约的引诱。
其次，a教授寄发订书单成立要约。a教授填具订书单，其将信件交与使者投寄时，于交付之际，其意思表示已脱离其支配范围，亦属要约已为发出。
a教授试图阻止c生投寄订书单未果，使者权限的授予或撤回，亦属意思表示，于对话人间须于相对人了解时，始生效力。a教授呼叫“不要投寄”，c生于下课钟声中误听为“不要忘记”，未能了解其内容，a教授的撤回不生效力，要约的发出不因此而受影响。a教授于发出要约之后，试图取回，阻止要约达到相对人，乃内心效果意思的变更，对于意思表示的效力，不生影响。
a教授的要约，于三月六日上午达到b出版社，其撤回的通知于三月七日始到达，不生撤回的效力。又此项撤回的信件，不能同时或先时到达，b出版社无即发迟到通知之义务。
b出版社于三月六日上午收到a教授的订书单，于当日下午即寄发书，是为承诺，于三月九日到达a教授时发生效力。
综上，a教授与b出版社之间购书的相互表示意思一致，其买卖契约成立。
（2）a教授支付价金及受领标的物之义务
a教授于三月五日致函于b出版社，表示撤回订书单。撤销
迟到，不生效力。
a教授忘记赠书之事，乃动机错误，不在撤销之列。又a教授亦不得以c生传达不实，撤销其意思表示。
2、b出版社得依法律规定，向a教授请求支付价金一万元，并受领标的物。
第一、此案例分析隐含的前提条件
为案件定性的问题，然后才能立案和审理。如果不能正确定性，找“法”的过程就比较麻烦。解决定性的问题可以用法律关系分析方法。
“法律关系分析的方法，是指通过理顺不同的法律关系，确定其要素及变动情况，从而全面地把握案件的性质和当事人的权利义务关系，并在此基础上通过逻辑三段论的适用以准确适用法律，做出正确的判决的一种案例分析方法。”[1]这种分析方法的优点在于“在存在多种复杂的法律关系时，能够条分缕析地分析各种权利义务。通过对法律关系的分析和把握，将各种法律关系比分开来，以不同的法律关系确定当事人的法律权利和义务；排除非法律关系的因素，即在区别法律关系与非法律关系的基础上，将考虑对象聚焦于法律关系；把握法律关系的要素。任何民事法律关系都由几项要素构成，要素发生变化，具体的民事法律关系就随之变更；把握法律关系的变动。把握法律关系产生、变更、消灭的脉络。”[1]请求权基础方法仅适用于请求之诉，对于确认之诉和变更之诉并不适应，本文由http://收集整理上述分析中这些前提条件是隐含着的。
第二、分析案例的关键要点
（1）关于请求权基础规范（具体法条的得出）的判断，确定适用案件的请求权。
找到制定法对该请求权的具体规定，这个思维过程有时与纸面上展现的过程并不一致。在具体案例分析过程中需要按照下列顺序加以通盘检讨：契约上请求权、无权等类似契约关系上请求权、无因管理请求权、物权关系上请求权、不当得利请求权、侵权行为损害赔偿请求权、其他请求权。各案的情况与上述类型之一对应起来时，才缩小了在制定法中寻找某一具体请求权的范围，对现行制定法的熟练程度和对案例接触的量有助于更快地寻找出请求权基础。
在“a教授的订书单”一案中，王泽鉴老师给出的请求权基础规范法条是台湾地区现行民法第367条：“买受人对于出卖人，有交付约定价金及受领标的物之义务。”这个结论的得出也是应该在整个案例分析的结尾才产生的，此构成三段论中的大前提。
（2）关于请求权基础构成要件的分析
需求分析示例篇7
0引言
在系统工程及软件工程中，需求分析指在创建一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作。需求分析是软件工程中的一个关键过程[1]，是整个系统开发的基础。需求分析的结果将直接影响到整个软件工程的成功与失败[2]，需求分析阶段的任务是确定软件系统功能。
在UmL中，需求模型又称为用例模型，主要用于描述系统的功能性需求，即软件可以实现的功能。将UmL的用例模型应用到医学院校临床毕业实习管理系统的需求分析中可以更有效地获取系统功能需求，并清晰描绘出系统功能。
1医学院校临床毕业实习管理系统需求分析
医学院校临床毕业实习根据专业性质不同一般为36～52周，通常安排在第五学年进行。临床医学毕业实习工作主要包括：实习计划制订、实习医院落实、实习生分配、各实习医院学生名单公布，实习日期确定;学生分赴实习医院、确定实习科室轮转日程、确定实习指导教师、分配实习分管床位、按计划进入各实习科室、出科考试。参与这些工作的用户有管理员、教师、学生、系统管理员，不同的用户对系统有不同的功能需求。
学生用户的功能需求为：查询和修改个人信息，填报实习医院，查询实习医院，查看、下载、上传作业，查看各种公共信息，查询学生成绩等;教师用户的功能需求为：查询及维护个人信息，添加、修改、删除实习科目，查看、添加、删除、修改公告，查看、添加、修改、删除作业，查询学生记录、录入学生成绩;管理员用户的功能需求为：查询、添加、删除、修改、审核或导入医院信息、专业信息、实习科目信息和教师信息，、查看、修改公告审核和调整学生实习医院等;系统管理员用户的功能需求为：管理整个临床毕业实习管理系统，负责不同用户组的权限定义，进行整个系统的信息初始化及数据维护备份，注册系统用户，负责系统安全管理，硬件环境及网络的管理与维护。
根据上述各种用户的功能需求描述，可以将临床毕业实习管理业务功能归纳为：用户管理、公用信息管理、作业管理、实习成绩管理、公告管理、实习医院管理，如图1所示。
2基于UmL用例建模的系统用户功能需求描述
用例(UseCase)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早由ivaJackboson博士[3]提出，后来被综合到UmL规范之中，成为一种标准化的需求表述体系。UmL是目前最常用的一种面向对象建模语言，主要包括7种常见类型，即用例图、类图、序列图、状态图、活动图、组件图和部署图，分别用于不同的建模用途。用例图主要用于对系统、子系统或类的行为进行建模。它只说明系统实现什么功能，而不必说明如何实现。用例图包括系统的执行者和若干个执行用例[4]，以图形化的方式表示系统内部用例、系统外部参考者以及它们之间的交互[5]，从系统外部用户的观点看系统所具功能的高级视图[6]。
医学院校临床毕业实习管理系统中的主要执行者有系统管理员、普通管理员、带教教师及实习学生等，常见的执行用例为数据备份与恢复、用户管理、公用信息管理、公告管理、作业管理、实习成绩管理、实习医院申报和审核管理，由此可以得到系统顶层用例如图2所示。
2.1用户管理用例建模
在医学院校临床实习毕业系统中，为了保证系统数据的安全，建立用户管理。用户管理实现系统中所有用户使用系统资源的权限管理。用户管理的执行者是系统管理员，执行用例为添加用户、修改和查询用户、删除用户、权限定义。具体用例如图3所示。
2.2公用信息管理用例建模
公用信息是维护整个系统正常运行所需的基础数据集，公用信息管理的执行者是各院系管理员，执行用例包括专业信息管理、班级信息管理、学生信息管理、管理员信息管理、部门信息管理、公告类型信息管理、实习科目信息管理、成绩系数管理，具体用例如图4所示。
2.3作业管理用例建模
为巩固学生实习所学知识，检测学生实习效果，并使所学知识转化为技能技巧，在实习过程中，带教教师常常布置相应的作业，教师通过批改学生作业，检查实习效果，因此在医学院校临床毕业实习管理系统中设置作业管理用例图。作业管理的执行者是带教教师和实习生，执行用例包括添加作业、管理作业、批改作业、做作业。具体用例如图5所示。
2.4成绩管理用例建模
医学院校临床毕业考试成绩通常由毕业实习成绩、毕业实践技能考核成绩、毕业理论考核成绩按一定比例构成。专业不同，实习科目不同，毕业实习成绩计算方法也不同。例如临床医学专业实习科目为内科、外科、妇产科、儿科，每个科目的出科考试成绩通常由医德医风考核、病历书写考核、临床实践技能考核、理论考试按一定比例构成，内科、外科、妇产科、儿科的出科考试的平均分构成毕业实习成绩。录入成绩后，学生可查询成绩，各院系(或者医院)的管理员将学生每门实习科目的出科考试成绩按一定系数比例汇总成毕业实习成绩，各院系管理员将毕业实习成绩、毕业实践技能考核成绩、毕业理论考核成绩按一定比例汇总成毕业考试成绩上交给教务处。成绩管理的执行者有教师、院系管理员和实习生，执行用例包括录入成绩系数、录入成绩、查询成绩、汇总成绩。具体用例如图6所示。2.5公告管理用例建模
公告管理的执行者为系统管理员、管理员和实习生，管理员又可分为教师、教务处管理员、院系管理员、医院管理员，执行用例包括添加公告、上传公告、查看公告、修改公告、删除公告。公告管理用例如图7所示。
公告管理系统内的任何用户都可以查看系统内所有已的公告。系统管理员、各院系临床实习教学管理员、医院临床实习管理员、教师都可以添加公告，在公告没有前可以修改自己添加的公告，各用户可以删除自己已的和未的公告。
2.6实习医院申报和审核管理用例建模
实习生在实习前首先要进行实习医院的申报，各院系管理员根据实习生的申报情况进行实习医院的调整，调整完后，学生可以查询具体实习医院信息。各医院管理员根据实习生分配情况，对每一实习科目指派带教教师。实习医院申报和审核管理的执行者为实习生和院系管理员，执行用例包括填报实习医院、查询实习医院(扩展用例包括查询实习科目、查看带教教师)、调整实习医院、管理带教教师。具体用例如图8所示。
3系统模块设计
综合上述需求分析和用例模型分析，采用结构化设计的方法设计出临床毕业实习管理系统功能模块，包括用户管理、公用信息管理、作业管理、实习成绩管理、公告管理、实习医院管理共6个子系统，这些子系统又包含了若干子模块，如图9所示。
4结语
UmL提供了一套标准、规范、直观、易懂的，描述客户需求的UseCase元素。正确规范地使用这些元素能够高效地建立起一个可视化的客户业务模型，通过该业务模型可以使软件系统的需求分析人员和客户之间建立起一个高效、便捷、良好的沟通渠道，这对建立一个详尽、准确的客户需求分析文档极为重要。本文根据各类需求通过UmL用例建模法详细概述了医学院校临床毕业实习管理系统各类用户的功能需求，然后按照用例建模的一般步骤，进行了活动者、用例的定义，设计了医学院校临床毕业实习管理系统用例模型，完成了系统的初步设计工作。
需求分析示例篇8
关键词：任务分析；初中物理；教学
一、任务分析的发展及价值
任务分析（taskanalysis）是一个心理学术语，起源于第二次世界大战时期，由心理学家米勒提出。当时，行为主义心理学工作者力图用当时发展起来的刺激、反应和强化等心理学原理为依据训练新兵使用新式武器，但是效果平平。一部分心理学家认识到，人类的学习是十分复杂的，涉及内在的认知与情感和外显的行为。用单一的行为主义学习原理不能解释人类的复杂学习。任务分析技术应运而生。加涅（R.m.Gange）发展了任务分析理论并将其应用于教学设计。20世纪后期乔纳森等三人写任务分析的专著《教学设计中的任务分析方法》（D.H.Jonassen，m.tessmer&w.H.Hannam，1999），由皮连生引入我国。“任务分析”是一种关于教学设计的技术，指在开始教学活动之前，预先对学习目标中所规定的，需要学生习得的能力或倾向的构成成分及其层次关系详加分析，为学习顺序的安排和教学条件的创设提供心理依据。
教师在教学设计过程中，往往通过个人的经验制定教学的顺序和各个环节，很少对学生学习任务进行科学分析。任务分析是揭示教学目标规定的学习结果的类型及其构成成分和层次关系的重要技术，并帮助教师提供学习结果习得的教学条件，为教学设计各环节顺序的安排和教学重难点的确定提供科学的心理学依据。
二、任务分析的方法
文中主要关注两种任务分析的方法，一种称之为层级任务分析，第二种称为程序性任务分析。
在层级分析中，教师或教学设计者需要从上到下地分解学习任务，使学习的各任务之间呈现出一种层级关系，分析到学生的起点能力中止。教学时，按照任务分析出的层级关系，从下到上地逐步推进教学。层级分析或先行条件分析，适用于智力技能类的学习任务。程序性任务分析就是把学生必须经历的心理或行为步骤分解开来，以便于任务得以顺利完成。适用的条件是具有先后顺序的程序性技能，通常使用一个流程图呈现出来。
三、任务分析的步骤
文中结合两个初中物理教学中的例子介绍任务分析技术的实施步骤。
例1.由两个电阻R1和R2串联组成的电路，它们两端的电压是100V，其中R1的阻值是80Ω，R2两端的电压是40V，求：串联电路中的电流。
例2.沪科版教材第十五章《探究电路》第四节“伏安法”测电阻是一节基于欧姆定律的应用的一节实验探究课。
对这两个例子的分析步骤如下：
1.确定终点目标
例1是利用欧姆定律求解串联电路中的电流，终点目标是求出串联电路的电流。例2的终点目标是通过实验操作，用“伏安法”测算出定值电阻的大小。
2.分析终点目标的学习类型
加涅对教学过程中的学习结果进行分类。他把学习结果分为五类，分别是言语信息、智慧技能、认知策略、动作技能和态度。这五类学习结果有效教学条件不同。例1中的学习结果是学生掌握了智慧技能，而例2中学生学习结果属于动作技能的范畴。
3.确定任务分析的基本方法
通过上面确定的学习结果类型来看，程序性任务分析适用于例1中的学习结果，层级任务分析适用于例2中的学习结果。
为了了解达到任何一种既定的目标所需经历的步骤以及需要掌握的前提技能，加涅在他的教学设计思想中，提出了针对学习的任务分析技术。对学习任务进行分析主要有两种技术。第一种技术是将学生完成一任务时必须执行的一系列步骤分析出来，这种分析的技术不仅揭示了一些可以从外部观察到的步骤，而且揭示了一些内在的心理步骤，这种任务分析技术称为序列任务分析或信息加工分析（informationprocessinganalysis），第二种任务分析技术是为了分析学生为了掌握某一技能，需要掌握哪些简单的从属技能，进而分析掌握这些从属技能的从属技能，直到分析到学生无需再学（学生已经掌握的技能）的层次为止，这种任务分析技术称为学习任务分析（learningtaskanalysis）。
四、信息加工分析在中学物理教学中的应用
初中物理教学中，教师较多地关注学生的学习结果，对于学生的学习过程及思维过程不能很好地监控，主要原因是教师能够观察到的是学生的行为。信息加工分析超越了可以观察到的行为，考虑了在整个任务完成中的智慧技能的部分。完成任务的一系列的步骤可以用流程图的方式很好地表示出来。下面用一个例子介绍该技术在物理学习中的应用。
上面的题目中，学生解题时容易出现用R2两端的电压是40V去除以R1的阻值是80Ω得到0.5a。显然这是一个错误的结果，出现错误的原因是学生缺少一个判断和决策的过程，如图1所示，菱形部分表示的是该计算题的一个决策过程，学生只有判断好并进行决策才能得出正确的结果。
这是一个简单的例子，初中物理中需要判断和决策的例子还有很多，如解决密度计算题、速度计算题等。在物理技能学习的过程中，新的学习者必定会有某些或全部的环节未把握，因此不可能得出完整的“描绘”。基于信息加工分析的任务分析技术，就是帮助教师了解学生智慧技能的掌握情况。基于信息加工的任务分析技术能很好地帮助物理教师了解学生完整的思维过程，了解是哪个环节没有掌握，并有针对性地进行指导。
五、学习任务分析在中学物理教学中的应用
在学生初中物理的学习过程中，学生的学习是层层深入的，综合性是越来越高的。后面遇到的问题往往需要用前面掌握的技能来解决。这就需要分析学生为了掌握某个技能需要的哪些从属技能，这些从属技能掌握到了什么程度，哪些地方需要教师和学生重点关注，哪些地方需要在教师的帮助下完成。这样就给我们在教学活动中教师确定教学重点、教学难点、教学起点提供了科学和理论支撑，更重要的是该分析有助于教师设计教学的顺序。这种方法通常用学习层级图表示出来。下面用一个例子来说明这一点。
例2沪科版教材第十五章《探究电路》第四节“伏安法”测电阻是一节基于欧姆定律的应用的一节实验探究课。
本节课学习任务分析如图2所示，通过分析可以很直观地看到，学生要掌握“伏安法”测电阻这一技能需要掌握的从属技能自上而下层层展开，直至学生掌握的起点技能为止，而教师教学设计的顺序应该是自下而上的。
本节课的教学重点在图中体现得最为明显，就是对欧姆定律的变形公式进行正确深入的理解。因此，教师教学中设计问题时可以设计如：“为什么多次测量的定值电阻基本是不变的？导体电阻的大小和什么因素有关？能不能认为电阻随着电流的增加而减小？”在教学实践中，通过提问，学生对知识的掌握变得顺畅了，充分体现了任务分析技术对教学具有很高的应用价值。
参考文献：
需求分析示例篇9
所谓装备mRo知识，是指与装备维护、维修和运行相关的维修资料、维修知识和运行状态数据等综合信息资源，其知识体系结构如图1所示。装备mRo知识主要包括2类：①基本的维修资料与知识，例如设计阶段通过设计Bom组织的设计资料、技术手册等，制造阶段通过制造Bom组织的物料信息、装配信息等，使用维护阶段通过维修Bom组织的维修历史、状态数据等；②使用数据挖掘等技术获得的推理性知识，例如通过数据挖掘形成的规则知识、利用知识工程获取的专家知识和通过案例积累形成的案例知识等。基于上述知识的支持，系统提供维修计划、健康评估、故障预测、案例检索等多种装备运维服务。从装备mRo知识体系结构看，其知识特点主要体现在以下5个方面：（1）类型繁多。装备运维服务涉及的mRo知识纷繁复杂，知识分布于全生命周期的各个阶段，既包括维修规程、物料信息、维修历史等基本的维修资料与知识，又包括使用数据挖掘等技术获得的推理性知识。（2）结构复杂。装备mRo知识与装备整机及其零部件相联系，在结构上具有层次性特点。维修计划、健康评估等维修决策需要的状态数据、维修历史、维修规程等装备、部件和零件多个层次的mRo知识相互联系共同辅助维修决策。此外，在装备的不同部位可能存在相同的零部件，它们存在共性的CaD模型等设计知识，但由于位置不同而拥有个性的维修历史等维修知识。（3）周期性长。对机、火车等大型复杂装备来说，从设计制造、使用维护直至报废整个生命周期的时间跨度很长，需要管理装备全生命周期过程中的数据，并利用数据挖掘、统计分析等技术手段从中发现有价值的知识。（4）动态变化。装备在其全生命周期过程中Bom结构处于从设计Bom、制造Bom到维修Bom的不断演化过程中，并且随着维修活动的发生，维修Bom不断发生变化，与之相联系的维修历史、维修案例等知识也随维修活动而不断变化。另外，在装备的运行过程中，实时状态数据处于不断采集的动态过程，对实时的数据流进行处理，可从中发现隐含的数据模式，同样也需要对动态变化知识进行管理。（5）应用多样。为装备制造商、维修商及用户提供的运维服务多种多样，如装备健康评估、故障预测、维修计划制定等，这些服务各自涉及不同的技术、工艺和资源等相关知识，直接建立服务与知识间的联系会出现效率低下等问题，需要建立完善的装备mRo知识管理体系，针对不同服务建立相应的知识模型。根据上述知识特点，完善的装备mRo知识管理体系应能够根据维修规程、维修资源等知识的特点进行知识表示，在装备的使用维护阶段将全生命周期的知识进行组织，支持知识的演化过程，保证知识追踪与追溯，并围绕维修计划制定、健康评估等的装备运维服务，将这些知识进行综合并建立知识模型，以满足运维服务的可扩展性，同时应满足知识的快速检索要求，以提高知识应用的效率。
2装备mRo知识管理体系
基于上述分析，本文提出围绕装备运维服务的mRo知识管理体系，如图2所示。在对服务需要的维修规程、维修资源、维护历史以及维修案例等相关知识进行分析和表示的基础上，以装备维修Bom结构为核心对知识进行组织管理，并围绕装备运维服务，建立基于本体的知识模型。整个装备mRo知识管理体系从全局的角度系统性地提供了知识管理与应用的思路。
2．1mRo知识及其表示装备mRo知识的准确表示是进行mRo知识管理的前提和基础。装备mRo知识类型繁多，对于维修过程所需要的知识，维修规程规定的维护周期是确定维修任务、编制维修计划的重要依据；维修资源是维修计划顺利进行的重要保障；装备维修历史，结合状态监测、日常检修等可以得到变动维护周期，对其进行统计分析能够得到零部件质量等知识；维修案例为解决维修过程中的新问题提供重要参考。因此，本节对装备的维修规程、维修资源、维修历史及维修案例进行分析及知识表示。
2．1．1维修规程的知识表示维修规程规定了装备整机及其零部件的大修、中修、小修等预防性维护保养的内容和规范。以装备的维护周期为例，维护周期在维修规程中已做出规定，但根据装备的状态监测、日常检修，维护周期也会适时调整，需对变动大修、中修、小修和零部件保养周期进行管理。这些维护周期知识属于典型的结构化知识，可用框架表示法进行知识表示，如图3所示。装备维护周期是产生维修预警信息、确定维修任务以及编制维修计划的重要依据。根据上述装备维护周期知识，可以确定装备整机及其零部件的维护时间。对于部件C，其上次维修时间为t0，维护周期为tp（tp可为维修规程中规定的固定周期，也可以是根据装备状态和维修历史等确定的变动周期），则部件C的维护时间为。
2．1．2维修资源的知识表示维修资源包括维修备件、维修人员、维修工位、维修工具等，是制定维修计划的约束，尤其在多个装备共用维修资源的情况下，需要通过对维修资源的有效管理，实现合理调度。以维修计划中维修任务对维修备件的需求为例，各维修任务能够确定需要的维修备件的需求量及需求时间等。
2．1．3维修历史的知识表示装备的零部件经过拆卸、修理等维修活动，产生了维修历史信息，对其进行数据挖掘等获取的隐含知识对于装备的维修决策具有重要价值。装备的维修历史（maintenancehistory，简称mH）用元组表示为：mH：：＝（iD，piD，FH，mC，t，…）（3）其中，iD为装备编号；piD为装备维修零部件编号；FH为故障现象；mC为维修处理过程；t为维修时间。对元组进行实例化即可表示装备的一条维修历史记录，由多条记录组成一张二维表，类似于关系型数据库中的表。对于装备的维修历史信息，利用统计分析方法，分析特定型号所有装备零部件的维修次数，或者分析具体装备零部件的维修次数，按维修次数确定装备中频繁出现故障的零部件，反馈到设计制造部门来提升产品质量或改进产品设计，或者反馈到采购部门要求生产厂家改进产品质量或更换生产厂家。此外，利用装备的维修历史记录，结合其设计使用寿命，利用数据挖掘技术，对零部件进行维修预测取得合理的维修周期并产生维修预警信息，以辅助维修决策。
2．1．4维修案例的知识表示装备维修案例描述故障维修的全过程，其中蕴含的经验、技巧对于解决新问题提供了重要的参考。通过案例推理，寻找与新问题相似的历史案例，指导新问题的解决。维修案例的知识表示是进行案例推理的前提和核心。维修案例的知识表示方法可以采用本体、框架等表示法，此外，案例知识表示法本身作为一种表示法也可以进行维修案例的知识表示。维修案例知识结构一般包括3个部分：①故障描述，即维修案例的描述，如发生故障装备、故障部件、故障现象等；②解决方案，即故障的解决过程，如分析故障原因、处理方法等；③反馈评价，即解决方案的总结与评价，如经验总结、效果评价等。维修案例知识结构如图4所示。
2．2以维修Bom为核心的mRo知识组织装备的mRo知识纷繁复杂，但就维修计划制定、健康状态评估等具体的运维服务来说，由于服务过程清晰、目标明确，因此需要的知识能够预先进行组织。为组织装备运维服务需要的知识，建立以维修Bom为核心的mRo知识组织方式，如图5所示，其优点在于维修业务活动导致的装备结构变化对知识结构的影响较小。从与装备结构的关联角度分析，运维服务需要的知识一般包括3类：①静态知识，是同型号或同批次装备共享的知识，如某型号装备的维修规程、维修工艺等；②动态知识，是具体单台装备独有的知识，如装备的维修历史、运行记录等；③其他知识，是不与装备结构直接关联的知识，如制定维修计划过程中的约束条件、维修资源等。文献［9］提出将装备使用维护阶段的维修Bom，经优化设计成由中性Bom、位置Bom及实例Bom组成的复合式维修Bom，并提出在中性Bom和位置Bom上组织维修资料与知识，在实例Bom上组织维修业务数据。本文在此基础上，利用具有层次性的Bom结构来表达mRo知识体系，实现运维服务需要的知识与相关零部件的关联，构成以维修Bom为核心的mRo知识组织方式。根据运维服务需要的知识分类，静态知识由中性Bom进行组织，动态知识由实例Bom进行组织，其他知识则依托于服务本身。
2．3基于本体的mRo知识管理本体（ontology）的概念起源于哲学领域，是共享概念模型的明确的形式化规范说明，在领域知识表示方面具有表达准确、规范和结构清晰等优点［13］。由于装备运维服务具有复杂性、多样化等特点，利用本体确定的概念间关系，实现服务涉及的维修规程、维修需求、资源约束等知识的整合；通过基于本体的mRo知识视图，实现知识的快速定制与检索。
2．3．1装备运维服务的知识本体围绕上述以维修Bom为核心的装备mRo知识组织方式，本文结合owL的基本元素和六元组本体表示方法［14］，将装备运维服务的知识本体形式化定义如下。现以汽车的维修计划制定过程为例，过程如下：在维修任务确定后，需要组织维修备件、维修人员等维修资源，以及根据不同的约束条件制定装备的维修计划，约束条件包括备件库存成本、人员工资、工时安排、维修成本、停机损失成本等。综合以上考虑，以最低成本为目标，进行分派维修人员与维修备件等过程制定维修计划。维修计划制定的知识本体如图6所示。
2．3．2基于本体的mRo知识视图为满足装备运维服务涉及的mRo知识同步动态数据管理与快速知识追踪检索的需求，本文引入知识视图的概念。视图是计算机数据库中的术语，是虚拟的表，其内容由查询定义，能够在现有的数据中根据需求筛选特定的数据，实现定制数据的需求。围绕装备运维服务，根据其知识本体，建立需要的mRo知识视图，正符合装备运维服务对mRo知识的要求。基于本体的mRo知识视图建立过程如图7所示。过程如下：①明确知识需求，根据装备运维服务的知识本体，通过获取概念、知识、知识属性、知识数据属性和知识对象属性5个过程，逐层细化mRo知识需求；②筛选知识数据，根据mRo知识需求进行筛选，由于装备知识是以Bom为核心进行组织的，并且装备全生命周期过程中Bom视图间存在转换关系，利用这些关系可以在零散繁多的知识中筛选出需要的mRo知识；③建立知识视图，通过查询定义等方式，利用知识对象属性确定的知识关联，建立起知识视图以及视图间的关联关系。mRo知识视图中数据经过知识本体模型中定义的模型规则处理，用以支持维修计划制定等运维服务。
3面向服务的装备mRo知识管理系统
面向服务架构（serviceorientedarchitecture，简称Soa）是以服务为核心的组件模型，采用中立方式定义的接口，使得服务间具有松耦合性，能够灵活地适应环境变化，动态响应新的需求。结合装备mRo知识管理体系，利用面向服务架构的思想，建立面向服务的mRo知识管理系统架构。由于装备运维服务多种多样，装备全生命周期过程中的知识零散繁多，而运维服务只需要特定的一些知识，直接建立服务与所需知识间关联会导致效率低下、不易扩展等问题。为解决上述问题，以服务为核心，向外提供运维服务支持，向内建立服务的知识本体，根据知识本体确定的知识需求，从装备全生命周期过程的知识中获取特定的知识建立知识视图，提高知识管理的效率并利于运维服务的扩展。因此，面向服务的装备mRo知识管理系统架构划分为4层，分别是知识层、本体层、服务层、应用层，如图8所示。（1）知识层。知识层用作组织和管理装备全生命周期过程中的mRo知识，如维修规程、维修工艺、维修历史等，以及通过数据挖掘形成的规则知识、利用知识工程获取的专家知识和通过案例积累形成的案例知识等。这些mRo知识以装备全生命周期各阶段Bom视图为核心进行组织和管理，例如设计Bom管理维修规程等、维修Bom管理维修保养历史等。（2）本体层。维修活动复杂繁多、周期长、涉及因素多，针对具体的装备运维服务，建立相应的知识本体，如故障诊断本体、健康评估本体、维修案例本体、维修计划本体等，这些本体确定了该运维服务中的知识需求及其模型规则处理方法。根据知识本体中确定的mRo知识需求，并从知识层中筛选知识建立各运维服务的知识视图。（3）服务层。针对装备生产商、维修商和用户对运维服务的需求，提供动态可扩展的装备运维服务，如故障诊断服务、健康评估服务、案例检索服务、维修计划服务等。这些服务拥有对应的知识本体，对知识本体对应的视图中的知识经过知识推理等规则模型处理，结果以web服务等形式对外提供服务接口支持。（4）应用层。用户通过客户端软件、移动终端或者门户网站等多种途径向远程服务器发出服务请求，远程服务器获取到请求后调用服务层中相应运维服务，并将处理结果进行反馈。这些运维服务是以服务接口形式提供，装备生产商、维修商和用户能够按需使用不同的运维服务，用以支持维修决策和辅助维修业务活动等。本文基于上述系统架构，开发了车辆运维知识管理系统。该系统基于J2ee和Soa架构，通过对知识管理工具和运维服务的封装，实现了维修规程、维修历史、维修资源、维修案例等mRo知识管理，并在此基础上，围绕基于知识的应用，分别面向制造商开发了维修Bom管理工具、知识管理工具等服务应用，面向维修商开发了维修计划制定、维修案例管理、维修资源管理等服务应用，面向用户开发了车辆健康评估、维修案例检索、维修保养提醒等服务应用。此外，对于运维服务的知识本体模型构建，系统采用protégé4．0作为本体编辑工具、owL（webontologyLan－guage）作为本体描述语言，以利于运维服务的扩展。目前，该系统已以某品牌型号下的汽车为应用测试对象，验证了系统的可行性和有效性。
4结束语
需求分析示例篇10
关键词：初中数学教学问题案例问题特性数学思维能力
教育学认为，数学是思维活动的“艺术”科学。数学学科的抽象性、逻辑性、严密性，为学习对象的数学思维能力训练，搭建了实践“载体”，提供了活动“平台”。数学案例是数学教材内涵要义的生动“概括”和外在“代言”。初中生在感知、研析、解答不同类型代数案例和几何案例的进程中，需要通过思考、分析、概括、推理、判断等思维活动，使得他们的数学思维能力能够得到锻炼和提升。数学案例在锻炼和培养初中生数学思维能力方面的“功效”，已经得到了广大教学工作者的肯定和认可，数学案例已成为培养初中生数学思维能力的一个有效“载体”和重要“途径”。现我就运用数学案例特点，培养思维能力进行论述。
一、巧借案例解析特性，培养逻辑推理能力
判断、推导、概括，是数学思维能力的重要活动形式。学生在探知、找寻、总结解决问题思路及解答问题策略方法的进程中，需要进行思考、探析、推导、概括等数学思维活动。学生在其探析问题案例的实践进程中，逻辑推理能力能够得到有效的培养和锻炼，从而为思维活动的深入有效开展打基础、积素养。初中数学教师在案例讲解过程中应该充分发挥解题活动的解析特性，对整个案例解析过程进行有效设计，引导学生参与到对数学案例条件及解答思路的分析、思考等实践活动中，组织学生分析找寻问题条件内在关系，层层紧扣，环环相连，逐步推导解决问题的方法步骤。教师做好初中生思维分析活动的指导点拨工作，保证案例解析活动效果，推理过程严密合理，逐步提高初中生逻辑推理能力。
问题：如图1所示，eF∥aD，∠1=∠2，∠BaC=70°，求∠aCG的度数是多少？
图1
生：解析问题条件，结合解题要求，指出：根据问题条件及要求，可以发现应利用平行线的性质内容构件等量关系求该角的度数。
师：对解析活动进行指点：要注意eF∥aD这一条件，利用问题条件中的关系，通过等量代换，建立有效等量关系式。
生：推导该案例解题思路：由eF∥aD，可以得到∠2=∠3，通过等量代换推导出DG∥Ba，然后根据平行线的性质即可求解。
师进行解题思路点评：要注意运用平行线的判定和性质，同时要注重数形结合解题思想的运用。
生：解决问题，展示解题过程，相互进行评判。
师：引导学生共同总结归纳该案例解题策略。
二、巧借案例数形特性，培养空间想象能力
空间想象能力，是数学思维能力的重要内涵之一。我发现，很多初中生空间想象能力低下，面对复杂抽象的空间图形时，手足无措，不能进行很好的抽象分析和想象思维。初中阶段是承上启下的过渡阶段，高中阶段数学学科案例解答中，特别是解析一些立体几何图形案例的过程中，需要学生具有良好的空间思维能力。这就要求初中数学教师要做好初中生空间想象能力培养的基础工作。初中数学学科问题案例，特别是几何部分问题案例，它通过精确的数学语言和直观的图形符合二者之间的有机融合，为初中生空间想象能力的培养提供了有效“抓手”。因此，教师应借助初中数学案例数形结合的特性，设计数与形有机结合的问题案例，指导初中生结合数学问题条件内容，画出相对应的平面图形或观察图形画出条件揭示的关系，从而进行深刻的思维活动，逐步培养初中生良好的空间想象能力。如“o是aBC的一个内接圆，aB=aC，BD是o的弦，并且aB∥CD，现在过a点作这个圆的切线ae和DC，它们的延长线交于点e，aD与BC交于点F，求证四边形aBCe是平行四边形。如果ae=6，CD=5，试求出oF的长度”的讲解中，教师直接讲解问题条件及要求，初中生比较难以接受。此时，要求初中生结合问题条件内容，将数学语言转化为图形符号，画出如图2所示的图形，初中生在数形互补的条件下，再进行问题条件分析，就游刃而解，较容易得到问题解答的关键之处在于：“正确作出连接ao，交BC的与点H，双向延长oF分别交aB，CD于点n，m的辅助线。”这一过程有助于初中生空间想象力的有效培养。
图2
三、巧借案例发散特性，培养创新求异能力
教育发展学指出，数学案例具有显著的发散特性，具体表现在案例表现形式具有多样性，解题要求上具有递进性，解题途径上具有多样性。数学案例所具有的发散特性，为初中生创新求异思维能力的培养创造了条件。教师在问题案例讲解时，应借助数学案例发散特性，在问题设计上要力求丰富性，在解题要求上力求深刻性，在解题方法上力求灵活性，多设置具有一题多解、一题多问、一题多练等开放特点的案例，鼓励和指导初中生进行丰富多样、形式灵活的思维研析活动，让初中生在发散性问题案例解析中，创新求异的思维得到有效锻炼。
如“如图3所示，在aBC中，BeaC，CFaB，BD=aC，CG=aB”条件基础上，教师采用变式训练的形式，设计出“求证：aD=aG”、“aD与aG的位置关系如何”等解题要求，组织初中生进行思维和探究活动，从其他角度进行思考分析活动，以此锻炼初中生创新思维能力。又如在“全等三角形的判定和性质”案例解析中，初中生根据问题条件进行探析三角形全等的活动时，构建不同等量关系，可以通过不同判定定理正确两个三角形全等，教师此时对他们的解题思路进行肯定，然后进行对比分析，选择最合适的解答方法。在此过程中，初中生思维创新能力得到有效训练。
图3
值得注意的是，思维能力训练是系统、长期工程，需要教师落实在点点滴滴的活动中，需要学生认真进行实践活动，提升数学思维能力素养。
参考文献：
[1]李秋燕.应用“问题教学”方法培养学生创新精神和实践能力[J].教学月刊（中学版），2012，06.