软件工程4.ppt

1,第四章 软件需求工程,软件工程课件,软件工程,2,第四章 软件需求工程,4.1 软件需求工程基础4.2 软件需求获取4.3 传统的需求分析方法4.4 面向对象的需求分析4.5 快速原型化方法4.6 软件需求规格说明4.7 软件需求评审4.8 软件需求管理,软件工程,3,4.1 软件需求工程基础,软件需求工程的基本任务是准确地回答“软件系统必须做什么？”这个问题。它在系统工程和软件设计之间起到桥梁的作用。软件需求工程是软件生存周期中重要的一步，也是决定性的一步。只有通过软件需求工程的活动才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。,软件工程,4,软件需求的定义和层次,1997年IEEE在软件工程标准词汇表对需求（requirement）所作出的定义为：用户为解决某一问题或为达到某个目标所需要的条件或能力。（需方）系统或系统部件为满足合同、标准、规格说明或其他正式的强制性文档所必须具有的条件或能力。（供方）对在a)和b)中所描述的条件或能力的文档化说明。,软件工程,5,GBT 114572006信息技术 软件工程术语等同采用了这个定义。它从两个方面阐述了需求的含义：从用户角度要求系统应具有的外部行为从开发者角度要求系统应具有的内部特性最后强调了需求一定要文档化。软件需求包括 3 个不同的层次：业务需求、用户需求、功能需求和非功能需求。不同层次是从不同角度与不同程度反映着细节问题。,软件工程,6,业务需求（Business Requirement）,业务需求反映了组织或客户高层次的目标要求。业务需求主要来自于项目的投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织的愿景，即为什么要开发一个系统；系统的业务范围、业务对象、客户、特性、价值和各种特性的优先级别等。,软件工程,7,用户需求描述了要求系统必须完成的任务，即用户对系统的目标要求。用户需求通常只涉及系统的外部可见行为，不涉及系统的内部特性。用户需要是用户真正需要的东西，用户需求是用户对其需要的一种陈述，但这种陈述可能与它们的需要不一致。用户需求一般采用自然语言和直观图形相结合的方式描述，例如采用用例（Use Case）文档或场景（Scenario）等方式说明。,用户需求（user Requirement）,软件工程,8,功能需求和非功能需求,功能需求定义了开发者应提供的软件功能或服务，但不涉及这些功能或服务的实现。非功能需求则是对功能需求的补充，包括了对系统的各种限制和用户对系统的质量要求。特性是指逻辑上相关的功能需求的集合以满足业务需求。功能需求记录在软件需求规格说明（SRS）中。非功能需求的描述如下：,软件工程,9,软件工程,10,软件工程,11,系统需求来自于系统分析和结构设计。例如，有一个电信计费系统，它包括许多业务规则，这些业务规则与企业方针、政府条例、会计准则、计算方法有关，它们本身并非软件需求，因为它们不属于任何特定的软件系统的范围，它们属于系统需求。,系统需求,软件工程,12,软件工程,13,所有的用户需求必须与业务需求一致。功能需求必须从用户需求中提取，以满足用户对产品的要求从而完成其任务。开发人员应根据功能需求来设计软件以实现必须的功能。功能需求从外部（用户角度）描述了软件系统所应具有的行为。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集。,各种需求的关系,软件工程,14,非功能需求作为功能需求的补充，包括产品必须遵从的标准、规范和合约；外部接口的具体细节；性能要求；设计或实现的约束条件及质量属性。约束是指在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发者都极为重要。,软件工程,15,软件需求工程过程,软件需求工程阶段研究的对象是软件项目的用户需要。需要注意的是，必须全面地理解用户的各种需求分析和澄清模糊的用户需求准确地表达被接受的用户需求只有经过确切描述的软件需求才能成为软件设计的基础。软件需求工程需要执行的活动包括：,软件工程,16,1)确定目标系统将要面对的各类用户；2)从各类用户的代表那里收集需求；3)了解用户的任务和目标，以及这些任务要实现的业务目标；4)分析从用户那里得到的信息，将用户的任务和目标与软件的功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来；5)将顶层的需求分配到软件系统构架内定义好的软件成分中；6)了解各个质量属性的相对重要性；,软件工程,17,8)协商需求的实现优先级；9)将收集的用户需求表述为书面的需求规格说明和模型；10)审阅需求文档，以确保在认识上与用户需求相一致。应在开发组接受需求之前解决所有分岐。软件开发的目标是实现目标系统的物理模型，即确定待开发系统的各种软件成分，并将功能和信息结构分配到这些软件成分中。但是目标系统的具体物理模型是由当前系统的具体物理模型经过一系列的转换得到的。,软件工程,18,软件需求工程的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。,软件工程,19,Abran和Moore的软件需求工程过程模型（未包括需求管理）,软件工程,20,需求获取1)定义需求开发过程2)定义项目愿景和范围3)确定用户群4)选择用户代理人5)确定用例6)确定系统事件和响应7)描述软件的功能和性能8)指明软件与其他系统元素的接口9)建立软件必须满足的约束,软件工程,21,分析建模分析可行性确定需求优先级为需求建模创建数据字典将需求分配至各子系统应用质量功能进行调整分析模型为日后软件设计提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。,软件工程,22,需求描述需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。采用SRS模板确定需求来源唯一标识每项需求记录业务规范定义质量属性需求有效性验证审查需求文档，确定合格标准,软件工程,23,4.2 软件需求获取,需求获取的目标是确定用户“需要”什么样的软件产品，即新的软件必须能够做什么。没有专业的系统分析人员，用户很难了解到需要开发什么相关信息和功能；另一方面，没有与用户的交流，系统分析人员也很难弄清客户真正需要什么。发现用户需求的过程称为需求获取。一旦提出了最初的需求，进一步推敲、细化和扩充的过程称为分析建模。,软件工程,24,需求获取过程,需求获取包括以下活动：发现和分析问题 发现问题症结，并分析问题的原因/结果关系。获取需求 根据对问题的理解定义需求。使用调查研究方法收集信息；遵循需求获取框架，按照三个成分观察：即数据、过程和接口。需求归档 以草稿形式归档调查结果。形式有用例、决策表、需求表等。,软件工程,25,需求获取技术的基本特征,好的需求获取技术，对于规范需求获取活动，高效准确地获取需求定义，是十分重要的。好的需求获取技术，应具有如下基本特征：提供便于沟通的工具，如易于理解的语言和直观的图表；提供定义系统边界（交互）的方法；提供支持抽象的机制，如“分解”、“映射”等；,软件工程,26,鼓励分析员使用面向问题的术语思考问题，编写文档；为分析员提供多种可供选择的解决方案；适应需求的变化。适于以上特征的需求获取方法：基于数据流图的结构化分析方法；基于用例（use case）的建模方法。需求获取技术的关键点在于：深入浅出 需求获取要尽可能全面、细致。,软件工程,27,获取的需求是个全集，系统真正实现的是个子集。分析时的调研内容并不都纳入到新系统中，目的在于以后的扩充。以流程为主线 在与用户交流的过程中，应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。流程描述有宏观，也有微观。既要强调总体的业务流程、全生存周期的业务流程，又要对流程细化，有分支的业务流程。,软件工程,28,需求获取的主要步骤,开发高层的业务模型理解应用领域，即目标软件的应用环境。如银行、电信公司、书店等。一旦系统分析人员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。分析出企业的业务实体，开发或选取必需的构件，建立稳定的软件体系结构。通过迭代，更深入了解应用领域，再回过头来推敲业务模型。,软件工程,29,定义项目的视图和范围 在项目开始之前，在所有干系人中竖立一个共同的愿景，明确供需各方的权利和义务，并发布得到共识的、对项目目标的理解。在共同愿景的确立过程中要做两件事情:定义项目范围：项目范围描述项目该做什么，不该做什么，可通过陈述和图表（如用例图或数据流图）来表达；定义高层需求：高层需求不涉及过多的细节，主要通过它表示系统的概貌，从而建立需求模型。,软件工程,30,寻求需求的来源 软件需求的来源取决于目标系统的性质和开发环境。典型的需求来源是：与潜在用户进行交谈和讨论描述现有产品或竞争产品的文档系统需求规格说明当前系统的问题报告和改进要求市场调查和用户问卷调查观察用户如何工作用户工作的场景分析事件和响应,软件工程,31,根据所受限制不同，不同类型的应用系统能够从用户那里获取需求的比例也不同。所谓限制，是指受客观物理规律的限制。,软件工程,32,如导弹制导系统更多地受物理运动定律的限制，而非人的决策。视频游戏的大部分需求依赖人，因为它是一个想象出来的产品。应用受到的限制越少，能从人们那里获得的需求比例越大。识别用户类和用户代表确定目标系统的不同用户类型；挑选出每一类用户和其他项目相关者的代表并与他们一起工作;商定谁是项目需求的决策者。,软件工程,33,不同用户类可能还有不同的非功能需求。不同用户类的需求甚至可能发生冲突，导致需求不一致。即使所有利益相关者的需求一致，也可能由于实现代价高昂，需求不能得到完全满足。用户类可以是人，也可以是与系统打交道的其他应用程序或硬件部件。分析员必须在项目初期便确定产品有哪些不同的用户类，并描述它们的特点，这样就能从每个重要用户类的代表那里获取用户需求。,软件工程,34,每一个项目，包括企业信息系统、商业应用软件、数据包、集成系统、嵌入式系统、互联网Internet应用程序等，都需要有合适的用户来提供用户需求。确定目标系统的业务工作流具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。例如，针对信息系统的需求调研方法如下：1)调研用户组织结构、岗位设置、职责定义，从功能上区分子系统，明确系统范围和目标。,软件工程,35,调研每个子系统的处理流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。对调研内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。对与用户沟通的情况及时总结归纳，整理调研结果，初步构成需求基线。需求调研的形式可根据需求的来源来确定。,软件工程,36,访谈和文档记录大部分需求获取是人与人沟通的活动，这些活动经过精心组织，以准确获得最好的效果。准备和访谈客户的过程如下：访谈之前策划访谈的目标和内容：通过查阅组织的组织结构图，搞清业务部门的各种角色，选择访谈的主要对象预约访谈时间准备访谈内容，拟定一些具体问题,软件工程,37,访谈过程中引导访谈对象。发现业务流程背后的用户需求：What：系统要处理的业务内容是什么。When：系统业务过程的主要活动什么时候发生，持续时间有多长。Who：系统业务过程的各个活动中会有哪些相关的人、物、事（系统）。Why：为什么会出现这样的问题。How：为完成系统的业务目标所采用的方法。,软件工程,38,不管用户说什么，分析员首先要分析，然后置疑，从而引导用户说出他们真正的需求所在。访谈之后根据标准模版撰写软件需求规格说明SRS，打客户需求草稿通过电子邮件征求客户意见需求的整理与描述 开发反映主要业务规则的用例（或数据流图或状态图），与用户沟通。,软件工程,39,收集用户的质量属性信息和其他非功能需求，将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。分类在用例（或数据流图）中涉及的数据，包括数据的组成和数据之间的关系。详细拟订用例（或数据流图）的规格说明，建立功能模型，并进行审查。开发并评估界面原型，建立接口规范和信息流传输规则。从功能描述中开发概念测试用例，验证用例（或数据流图）、功能需求和原型。,软件工程,40,描述用户需求,需求可以看成是应用与应用的外部代理（如用户）之间的交互。可利用用例作为表达工具。用例描述了系统外的参与者（Actor）与应用之间的交互情况。主要注重用户对系统的看法。描述客户需求的过程如下：1)标识参与者 标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。2)标识场景 用场景描述目标系统典型功能的活动细节，并与用户沟通，加深开发人员对应用领域的理解。,软件工程,41,3)标识用例 当双方确定了一组场景后，开发人员从该场景抽象出一组用例，描述所有可能的情况。用例表达了系统的范围。4)求精用例 细化每一个用例。引入带有出错处理或带有异常处理的用例，描述系统的行为，保证需求的描述是完全的。5)标识用例之间的关系 描述用例之间的依赖关系，提取相同功能，建立用例模型。6)标识非功能需求 包括系统性能上的约束、文档、使用资源、安全性和质量等需求。,软件工程,42,需求获取期间，开发人员需要访问一些不同的信息资源：客户提供的与应用领域相关的文档和手册。将被目标系统替代的遗留系统的技术文档。最终用户和客户本人。以“图书管理系统”为例，首先标识参与者：Librarian 图书管理员：创建、修改、删除读者信息；添加、编辑、删除书目信息；添加、编辑、删除图书信息。Borrower 读者：借阅、预约、归还图书，以及取消书目预约。,软件工程,43,图书（Book）是指某种书目（Title）的某一流通中的复本。例如“数学分析教程第二册”的 5 本馆藏复本中的第 3 本。识别用例：BorrowBook：借阅图书ReturnBook：返还图书RecerveTitle：预约某种书目CancelReservation：取消预约MaintainBorrowerInfo：维护读者信息，包括创建、修改、取消读者账户MaintainTitleInfo：维护书目信息，包括添加,软件工程,44,修改、删除书目信息MaintainBookInfo：维护图书信息，包括添加、修改、删除图书信息Login：登录识别参与者与用例之间的关系（场景）Borrower执行BorrowBook、ReturnBook、ReserveTitle、CancelReservation等用例。Borrower是通过Librarian完成上述用例的工作。则Borrower与Librarian存在依赖关系。Librarian还与MaintainBorrowerInfo、Main-tainTitleInfo、MaintainBookInfo交互。,软件工程,45,Librarian还需要与用例Login交互。画出用例图,软件工程,46,用例BorrowBook的规格说明1.1 前置条件：在此用例开始之前，Librarian必须登录到系统中。,Librarian,Login,MaintainTitleInfo,MaintainBookInfo,MaintainBorrowerInfo,软件工程,47,1.2 后置条件：如果此用例执行成功，在系统中建立并存储一条借阅记录，必须时需要删除预约记录。如果执行不成功，系统状态不变。1.3 事件流基本流当Borrower借阅某种书目，且Librarian选择“借书”，则此用例启动。提供书目和读者信息。检索书目（E-1）。确定该书目的物理复本（图书）是否在架上（E-2）。,软件工程,48,检索读者（E-3）。将图书交给读者。创建并存储借阅记录。删除预约记录。候补流E-1：若该种书目不存在，系统显示提示信息，用例终止。E-2：若该种图书都已借出，系统显示提示信息，用例终止。E-3：系统中不存在该读者，系统显示提示信息，用例终止。,软件工程,49,与用户沟通的其他工具,1)数据流图某些需求可以很自然地表述为处理元素之间的数据流。顶层图即为系统与外部实体的交互。2)状态图有时把应用看作是几个状态下的应用，而在某一确定时刻的应用始终明确地处于某个状态中。这种状态划分对理解系统比较有益。状态的具体内容到实现阶段会有确切的定义。,软件工程,50,借书过程的数据流图,外部实体、数据流和数据存储都为候选对象,软件工程,51,还书过程的数据流图,系统与外部实体、系统与数据存储的交互，构成系统的接口。相应数据流构成接口数据。,检验错误,还书信息,图书,软件工程,52,图书（对象）的状态图,软件工程,53,图书管理员借书操作的状态图,软件工程,54,草拟用户界面和其他接口,建立初始用户界面，是原型方法的一种，目的是快速与客户沟通。客户通常在看到应用的图形用户界面（GUI）才能相像到这个应用未来的样子。开发用户界面的步骤如下：1)了解客户 深入了解最终用户的想法。根据用户的层次，提供多种用户界面。知识和经验层次：计算机素养、系统经验、使用类似应用的经验、教育水平、阅读水平、打字技能等。,软件工程,55,用户的生理特征：年龄、性别、左右手习惯、生理障碍等。2)理解业务功能 根据应用的整体意图来理解特定用户界面的目的。功能界面出现的顺序通常可以反映用户处理日常业务的方式。用户的任务和工作特征：应用的使用方式、使用频率、雇员的流动率、任务的重要性、任务的重复性、对培训的期望、工作类型等。用户的心理特征：工作态度、能动性、认知方式等。,软件工程,56,3)理解优秀界面设计的原则 目的是加强视觉效果。确保应用的各个界面之间风格的一致性：习惯、步骤、视觉和感觉、位置等。揣测用户通常开始操作的地点导航系统尽量简捷使用分组和分层来强调重要性级别4)选择合适的窗口类型 五类窗口：属性窗口：展示实体的属性对话窗口：完成特定任务或命令的信息,软件工程,57,消息窗口：提供信息面板窗口：展示一组控件弹出窗口：突出显示信息5)制作系统菜单 为用户提供一个稳定的、易于理解的使用环境，可以方便地搜寻需要的选项。提供一个主菜单显示所有相关选择（仅局限于此）将菜单结构与应用要完成的任务对应起来尽量减少菜单的级数,软件工程,58,6)选择合适的基于设备的控件 提供给用户，向系统发送指示的实际手段，包括鼠标、键盘、触摸屏、绘图板、轨迹球、麦克风等。7)选择合适的基于界面的控件 即出现在屏幕上的符号。用户通过这些符号向系统提出他的输入和操作意图，包括图标、按钮、复选框、单选框等。8)组织和安排窗口布局 多窗口的排列规则，如平铺、层叠等。9)选择合适的颜色 尽量保持简捷和低调。颜色需要和谐。,软件工程,59,需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在：需求的不稳定性：在整个软件生存周期内软件需求会随着时间的推移发生变化；需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。需求获取只有通过有效的客户/开发者的合作才能成功。,软件工程,60,分析建模,分析建模是为了分析需求，以确定项目的确切需求。常用的分析模型有数据建模、功能建模和过程建模，从不同视角描述目标系统。常用的分析方法面向数据流的结构化分析方法(SA)面向数据结构的Jackson方法(JSD)面向数据结构的结构化数据系统开发方法(DSSD)面向对象的分析方法(OOA)等,软件工程,61,结构化分析方法最初只是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体-关系图、数据流图和控制流图、状态-迁移图为工具，数据字典为核心，从不同视点建立系统的分析模型。,结构化分析方法,软件工程,62,结构化分析的分析模型,实体关系图,状态迁移图,数据流图,数据对象描述,加工规格说明,数据字典,控制规格说明,软件工程,63,数据建模,数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。在需求分析阶段描述数据对象和它们之间的关系，使用了E-R 图。例如，在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。因此，教学管理中涉及的对象有学生、教师和课程。,软件工程,64,教学数据模型,软件工程,65,实例的关联有三种：一对一(1:1)；一对多(1:m)；多对多(n:m)。这种实例的关联称为“基数”，基数表明了“重复性”。,软件工程,66,软件工程,67,功能建模和数据流,最初,结构化分析方法仅讨论数据流建模，目标系统被表示成如图所示的数据变换流程图。系统的功能体现在核心的数据变换中。,顶层数据流图（上下文环境图）,软件工程,68,数据流图中的主要图形元素,软件工程,69,分层的数据流图,软件工程,70,实例：考务处理系统的功能,问题陈述对考生送来的报名单进行检查;对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站;对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者;制作考生通知单（含成绩及合格/不合格标志）送给考生;按地区进行成绩分类统计和试题难度分析，产生统计分析表。,软件工程,71,功能建模的步骤,首先确定与系统有交互关系的外部实体。这些外部实体即为系统的数据源和数据潭，它们与系统的交互构成系统的输入和输出。外部实体有考生、阅卷站和考试中心考生：填交报名表，退还不合规定的报名表，得到准考证，得到考试通知单。阅卷站：得到考生名单，提交考试成绩单，退还有误成绩单。考试中心：提供合格标准，得到成绩分类统计表和试题难度分析表。画出顶层数据流图。顶层数据流图描述了系统与外部实体的交互，反映了最主要业务处理流程。上例的顶层数据流图如图4.19所示。其中的加工只有一个，它代表了系统本身。它的输入数据流和输出数据流就是系统的输入和输出。,软件工程,72,功能建模的步骤,确定与系统有交互关系的外部实体。这些外部实体即为系统的数据源和数据潭，它们与系统的交互构成系统的输入和输出。本例外部实体有：考生：填交报名表，退还不合规定的报名表，得到准考证，得到考试通知单。阅卷站：得到考生名单，提交考试成绩单，退还有误成绩单。考试中心：提供合格标准，得到成绩分类统计表和试题难度分析表。画出顶层数据流图。,软件工程,73,顶层数据流图描述了系统与外部实体的交互，界定了系统的边界。,软件工程,74,分析考试业务处理的主要功能，建立第0层数据流图。第0层数据流图细化了顶层数据流图。它从输入端开始，根据考试业务工作流程，画出数据流流经的各个加工，逐步画到输出端，以反映数据的实际处理过程。本例有两个加工“登记报名表”和“统计成绩”是系统的主要功能。对每一个加工继续细化。如果加工内还有数据流，可将该加工再细分成几个子加工，并在各子加工之间画出数据流，形成第1层数据流图。,软件工程,75,软件工程,76,软件工程,77,软件工程,78,绘制分层数据流图的原则,数据流图上所有图形符号只限于前述四种基本图形元素，它们的命名应反映其实际含义；数据流图的顶层图上的数据流必须封闭在外部实体之间；每个加工至少有一个输入数据流和一个输出数据流；允许一个加工有多条数据流流向另一个加工，也允许一个加工有两个相同的输出数据流流向两个不同的加工；,软件工程,79,在数据流图中须按层给加工框编号，编号表明该加工所处层次及上下层的亲子关系；规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致，此即父图与子图的平衡；如果一个数据存储仅在展开的数据流子图中使用，可以在父图中不画出；可以在数据流图中加入物质流，帮助用户理解数据流图；数据流图中不可夹带控制流，但针对实时系统可以加入控制流，成为数据流图的扩展形式。,软件工程,80,行为建模,行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。数据流图不描述时序关系，控制和事件流通过行为模型描述。在描述系统或各个数据对象的行为时，采用状态迁移图。通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系统或对象的行为。,软件工程,81,状态迁移图,状态迁移图是描述系统的状态如何相应外部的信号进行推移的一种图形表示。例如，有关处理器分配的进程状态迁移。,软件工程,82,在状态迁移图中，“”表示可得到的系统状态“”表示从一种状态向另一种状态的迁移。在箭头上要写上导致迁移的信号或事件的名字。,软件工程,83,Petri网,Petri网已广泛地应用于硬件与软件系统的开发中，它适用于描述相互独立、协同操作的处理系统，也就是并发执行的处理系统。Petri网简称PNG(Petri Net Graph)，它有两种结点：库所：符号“”，表示系统状态。变迁：符号“|”,表示系统中的事件。有向边“”表示向变迁的输入，或从变迁的输出。,软件工程,84,令牌(token)，是表明系统当前处于什么状态的标志。Petri网可能的变化有：,软件工程,85,例如，处理两个进程PR1和PR2的同步问题（此时两个进程共用一个资源R）：该资源 R 在系统运行的某一时刻只能为一个进程所占用。为了解决两个进程在运行中可能会同时申请资源的矛盾，要用原语 LOCK 和 UNLOCK 控制 R 的使用，保证进程间的同步。,软件工程,86,软件工程,87,数据字典,数据字典是结构化分析方法的核心，与各模型的图形表示配合，能清楚地表达数据处理的要求。词条描述对于在模型中每一个被命名的图形元素，均加以定义，其内容有:名字，别名或编号，分类，描述，定义，位置，其它，等。数据流词条描述数据流名：说明：简要介绍它产生的原因和结果,软件工程,88,数据流来源：来自何方数据流去向：去向何处数据流组成：数据结构数据量流通量：数据量，流通量数据元素词条描述类型：数字(离散值，连续值)，文字(编码类型)长度取值范围相关的数据元素及数据结构3)数据文件词条描述,软件工程,89,数据文件名：简述：存放的是什么数据输入输出数据：数据文件组成：数据结构存储方式：顺序，直接，关键码存取频率：加工逻辑词条描述加工名：加工编号：反映该加工的层次简要描述：加工逻辑及功能简述,软件工程,90,输入输出数据流：加工逻辑：简述加工程序，加工顺序数据源及数据谭词条描述 名称：外部实体名 简要描述：什么外部实体 有关数据流：数目：,软件工程,91,数据结构的描述,符号 含义 举 例 被定义为 与 x=a+b.,.或.|.或 x=a,b,x=a|b.或 m.n 重复 x=a,x=3a8(.)可选 x=(a)“.”基本数据元素 x=a.连结符 x=1.9,软件工程,92,存折户名所号帐号开户日性质(印密)1 存取行50户名 2 字母24所号 001.999帐号 00000001.99999999开户日年月日性质“1”.“6”注：“1”表示普通户，“5”表示工资户等印密“0”注：印密在存折上不显示存取行日期（摘要）支出存入余额操作复核,软件工程,93,基本加工逻辑说明,对数据流图的每一个基本加工，必须有一个基本加工逻辑说明。基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。加工逻辑说明中包含的信息应是充足的，完备的，有用的，无冗余的。描述加工逻辑说明的工具：结构化语言、决策表、决策树。,软件工程,94,结构化语言,结构化语言是一种伪码，它的词汇表由原形动词数据字典中定义的名字有限的自定义词逻辑关系词 if_then_else、switch_case、for、while_do、do_while等组成。它是一种介于自然语言和形式化语言之间的语言。用以消除在语法上的歧义性。,软件工程,95,语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示。其基本控制结构有三种：简单陈述句结构：避免复合语句；重复结构：while_do、for_do或do_while结构。判定结构：if_then_else 或switch_do 结构；用结构化语言描述的规格说明的正文可以在计算机上编辑，不必过多地考虑语言的在语法上的限制，使得分析员可以集中考虑加工的策略或规则。,软件工程,96,if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else（欠款未超期）发批准书，发货单 else（发货单金额未超过$500）if 欠款超过60天 then 发批准书，发货单及赊欠报告 else（欠款未超期）发批准书，发货单,商店业务处理系统中“检查发货单”,软件工程,97,规则,单个条件,单个动作,判定表,如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适。,软件工程,98,以“检查发货单”为例,软件工程,99,判定树,判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。,软件工程,100,4.4 面向对象的需求分析,典型的面向对象分析（OOA）建模方法有以下几种。每种方法都有各自的分析过程和符号体系。Booch方法Booch方法包含“微开发过程”和“宏开发过程”。微开发过程定义了一组任务，并在宏开发过程的每一步骤中反复使用它们以维持演进途径。Booch的OOA宏开发过程的任务包括标识类和对象、标识类和对象的语义、定义类与对象间的关系，以及进行一系列求精实现分析模型。,软件工程,101,Rumbaugh方法又称为对象模型化技术OMT，用于分析、系统设计和对象级设计。分析活动建立三个模型：1)对象模型 描述对象、类、层次和关系2)动态模型 描述对象和系统的行为3)功能模型 类似于高层的DFD，描述穿越系统的信息流Coad和Yourdon方法其OOA过程概述如下：1)使用“要找什么”准则标识对象；,软件工程,102,2)定义对象之间的一般化特殊化结构（又称为分类结构）；3)定义对象之间的整体部分结构（又称为组装结构）；4)标识主题（系统构件的表示）；5)定义对象的属性及对象之间的实例连接；6)定义服务及对象之间的消息连接。Jacobson方法又称为OOSE（面向对象软件工程）。特色是强调用例（Use Case）。,软件工程,103,Jacobson方法概述如下：标识系统的用户和它们的整体责任；通过定义参与者及其职责、用例、对象和关系的初步视图，建立需求模型；通过标识界面对象、建立界面对象的结构视图、表示对象行为、分离出每个对象的子系统和模型，建立分析模型。WirfsBrock方法不明确地区分分析和设计任务。从评估客户规格说明到设计完成，是一个连续的过程。,软件工程,104,与WirfsBrock分析有关的任务如下：1)评估客户规格说明；2)使用语法分析从规格说明中提取候选类；3)将类分组以标识超类；4)定义每一个类的职责；5)将职责赋予每个类；6)标识类之间的关系；7)基于职责定义类之间的协作；8)建立类的层次表示；9)构造系统的协作图。,软件工程,105,UML的OOA方法用 5 种不同的视图，从不同的侧面来描述系统。这些视图概述如下：1)用户模型视图：从用户（参与者）角度来表示系统。它通过用例（Use Case）来建立模型，并用它来描述来自终端用户方面的可用场景。2)结构模型视图：从系统内部来看数据和功能性。即对系统的静态结构（类、对象和关系）建模。,软件工程,106,3)行为模型视图：描述系统的动态和行为。以及在用户模型视图和结构模型视图中所描述的各种结构元素之间的交互和协作。4)实现模型视图：将系统的结构和行为表达成为易于转换为实现的方式。5)环境模型视图：描述系统实现环境的结构和行为。通常，UML分析建模的注意力放在系统的用户模型和结构模型视图，而UML设计建模则定位在行为模型、实现模型和环境模型。,软件工程,107,面向对象分析模型由三个独立的模型构成：由用例和场景表示的功能模型；用类和对象表示的分析对象模型；由状态图和顺序图表示的动态模型。在需求获取阶段得到的用例模型就是功能模型。据此可导出分析对象模型和动态模型。需要注意，这些模型代表的是来自客户的概念，而非实际软件类或实际构件。分析中的类可以看作是高层抽象。,识别类或对象,软件工程,108,在分析对象模型中的对象类分为有实体对象、边界对象和控制对象等三种类型。实体对象表示系统将跟踪的持久信息；边界对象表示参与者与系统之间的交互（接口）；控制对象负责用例的实现。可用UML提供的衍型机制，区分不同类型对象。,软件工程,109,具有两个按钮的手表的分析对象,使用实体对象、边界对象和控制对象等对系统建模时，常常需要提供一些简单的启发式规则来指导开发人员使用这些概念，可以使用相应的类来跟踪。,软件工程,110,分析建模活动包括以下步骤。标识实体对象自然语言分析法 利用Abbott启发式准则，将语言成分映射为模型成分。,软件工程,111,自然语言分析法主要关注用户术语。限制有识别质量高度依赖人们的书写风格；可能会出现许多无关词汇，或同义词。检查每一个用例，标识候选对象用例中的连续名词（如借阅事件）；系统需要跟踪的现实世界中的实体（如借阅记录、书目信息）；系统需要跟踪的现实世界中的活动（如紧急情况操作预案）；数据源或数据潭（如读者、管理员）。,软件工程,112,2)标识边界对象在用例图中，每一个参与者至少要与一个边界对象交互。边界对象收集来自参与者的信息，将它们转换为可用于实体对象和控制对象的表示形式。边界对象对用户界面进行粗略的建模，不涉及如菜单项、滚动条等可视方面的细节。标识边界对象的启发式准则如下：标识用户所需初始用例的用户界面控制;标识用户需要键入系统的数据表格;标识通知和系统用于响应用户的消息;,软件工程,113,当用例中有多个参与者时，根据构想的用户界面来标识参与者的行为;不要使用边界对象对接口的可视方面建模，应使用用户原型对可视用户界面建模;使用用户的术语来描述接口，不要使用来自设计和实现的术语。3)标识控制对象控制对象负责协调实体对象和边界对象。控制对象没有在现实世界中具体的对应物，它通常从边界对象处收集信息，并把这些信息分配给实体对象。,软件工程,114,图书管理系统中的实体对象,Borrower：读者。他们可以借阅、返还、预约和取消预约。因为名字可能重复，可用读者ID识别。Title：书目。它表明某一种书，通过ISBN号码识别。Book：图书。它表明某一种书目的具体物理复本，通过馆藏号码识别。Loan：借阅记录。同一个人关于不同图书的借阅记录是不同的。Reservation：预约记录。,软件工程,115,图书管理系统中的边界对象,mainWindow：主窗口。有借书、还书、预约、取消预约、添加书目、修改书目、删除书目、添加读者、修改读者、删除读者、添加图书、删除图书等操作。BorrowerDialog：读者对话框。有添加读者、修改读者、删除读者等操作。FindBwrDialog：弹出对话框。有根据读者ID查找读者的操作。TitleDialog：书目对话框。有添加书目、修改书目、删除书目等操作。,软件工程,116,FindTDialog：弹出对话框。根据图书的ISBN号码查找书目。BorrowDialog：借书对话框。根据书目的ISBN号码和读者信息，执行借阅动作，创建和保存借阅记录。ReturnDialog：还书对话框根据图书的馆藏号码，执行还书动作，删除借阅记录。ReserveDialog：预约对话框。根据书目的ISBN号码和读者信息，执行预约、取消预约动作。MessageWindow：显示提示信息窗口。LoginDialog：输入用户名和密码的窗口。,软件工程,117,4)使用顺序图将用例映射为对象顺序图将用例与对象联系起来，直观地描述了用例（场景）行为在其参与对象之间是如何实施的。顺序图对用例中各参与对象之间的交互序列进行建模。每一个消息从一个对象（或参与者）发送给另一个对象（或参与者）。消息的接受就触发了一个操作。通过顺序图，将责任以操作集合的形式分配给每一个对象。如果一个