第二部分软件需求分析与建模.优秀PPT.ppt

其次部分 需求分析与建模范锐广东海洋高校软件学院2014年3月11/5/第4讲 软件需求分析过程v什么是软件需求？v软件需求分析有哪些过程？v如何启动分析过程？v需求规格文档有哪些内容？v需求分析有哪些技术？11/5/软件需求v功能需求：描述系统预期供应的功能或服务v对系统应供应的服务v如何对输入做出反应v系统在特定条件下的行为v非功能需求：指那些不干脆与系统具体功能相关的一类需求v产品需求v机构需求v外部需求v领域需求：源于系统的应用领域需求11/5/需求分析过程v需求分析主要是理解客户须要什么、分析要求、评价可行性、协商合理的方案、无歧义地具体说明方案、确认规格说明、管理需求以至将这些需求转化为可行系统v过程包括：v初步沟通v导出需求v分析和精化v可行性探讨v协商与沟通v规格说明v需求验证v变更管理11/5/软件需求规格软件需求规格v一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组运用场景、一个原型或以上各项的随意组合。v软件需求规格（SRS，Software Requirement Specification）是需求分析任务的最终“产品”，它是客户、管理者、分析工程师、测试工程师、维护工程师沟通的标准和依据。v软件需求规格描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以及其他与需求相关的信息。v分为：用户需求和系统需求11/5/需求规格文档标准需求规格文档标准1 引言 1.1 编写目的 1.2 项目背景（单位和与其他系统的关系）1.3 定义（特地术语和缩写词）2 任务概述 2.1 目标 2.2 运行环境 2.3 条件限制3 数据描述 3.1 静态数据 3.2 动态数据 3.3 数据库描述 3.4 数据字典 3.5 数据采集4 功能需求 4.1 功能划分 4.2 功能描述5 性能需求 5.1 数据精确度 5.2 时间特性 5.3 适应性6 运行需求 5.1 用户界面 5.2 硬件接口 5.3 软件接口 5.4 故障处理7 其他需求（检测或验收标准、可用性、可维护性可移植性、平安保密性）11/5/需求验证v需求验证对需求文档和制品进行质量评估，确保需求说明精确、完整v包括以下内容：v正确性v一样性v完整性v可行性v必要性v可检验性v需求的可跟踪性v最终签字11/5/启动分析过程v确定共利益者：干脆或间接从正在开发的系统中获益的人。v例如，POS机系统中的共利益者有：收银员，售货员，顾客，公司，经理，支付授权服务，帐务系统和库存系统等v识别视点：从不同的视角看待该系统。v比如，收银员关切精确、快速生成一次销售，且没有支付错误；售货员关注销售提成v协同工作：共利益者之间的协作v首次提问：集中于客户和其他共利益、整体目标、收益等11/5/非形式化需求分析技术v会谈：v正式会谈：提出一些可自由回答的问题v非正式会谈：提出一些事先准备好的议题v情景分析：需求分析从对场景的评论中得到信息，然后再将其以形式化方式表示出来。v运用调查表v制定调查表v分析v建立原型v界面v执行过程11/5/实例分析：POS机系统v收银员：能够精确、快速地输入，而且没有支付错误，因为假如少收货款，将从其薪水众扣除。v售货员：自动更新销售提成。v顾客：希望以最小代价完成购买活动并得到快速服务。便捷、清晰地看到所输入的商品项目和价格。得到购买凭证，以便退货。v公司：希望精确地记录交易，满足顾客要求。确保记录了支付授权服务的支付票据。有确定的容错性。能够自动、快速地更新记帐和库存信息。v经理：能够快速执行超控操作，并易于更正收银员的不当操作。v支持授权服务：依据正确的通信格式进行授权服务。v库存系统：正确的方式更新库存信息。v记账系统：能够精确地记录每次销售支付信息。11/5/POS机系统主要功能需求机系统主要功能需求v处理销售：收银员完成一次销售记录，并出具票据和更新库存系统和帐务系统。v处理支付：完成一次销售对应的支付，包括现金支付，信用卡支付和支票支付。v处理退货：依据顾客恳求完成商品退货处理。v办理睬员卡：注册、注销和更新会员记录。11/5/实例分析：图书馆系统v图书馆系统的共利益者与视点有：图书流通管理：负责图书借还工作。用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。编目管理员：负责图书的管理、用户管理和处理罚金等。11/5/图书馆系统的主要功能需求图书馆系统的主要功能需求v图书借出：管理员完成一次借书过程。v图书归还：管理员完成一次还书过程。v图书预约：用户查询要借的图书，若不能借，可预约该图书。v图书续借：用户可以将图书的归还日期延长一段时间。v图书管理：添加新书。更新图书馆信息，销毁图书。v用户管理：注册新用户，更新用户信息，注销用户。v处理罚金：用户缴纳罚金吼，系统将罚金数额清零。11/5/小结v需求分析也称为需求工程，是一个特别重要而有很困难的，须要交替进行，反复迭代的过程。v软件需求分为功能需求和非功能需求。功能需求描述系统所预期供应的服务，而非功能需求描述与系统不干脆相关的一些需求。v领域需求是一种特有的功能需求，反应应用领域的基本问题。v软件需求规格说明文档描述了系统的数据、功能、行为、性能需求、设计约束、验收标准以及其他于需求相关的信息，它有可能成为客户与开发商之间的合同。v需求分析过程通过执行初步沟通、需求导出、分析与精化、可行性探讨、协商和沟通、规格说明、验证和变更管理八个不同的活动来完成。v非形式技术主要包括会谈、调查表和场景技术，用于获得用户需求和系统需求。11/5/第第5讲讲 结构化分析建模结构化需求分析面对数据的建模方法案例分析11/5/结构化分析建模结构化分析建模v需求分析的任务就是精确地指出“软件目标产品必需做什么？”v需求分析的一个重要过程就是需求建模的过程v结构化分析方法是一种传统的系统建模技术11/5/结构化分析模型结构结构化分析模型结构实体-关系图数据流图加工规约数据对象描述状态转换图控制规约11/5/结构化分析模型结构结构化分析模型结构v分析模型结构的核心是数据字典（DD，Data Dictionary），包含了软件运用或生产的全部数据对象描述的中心库。v分析模型结构的中间层有三种视图：v数据流图（DFD，Data Flow Diagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。v实体关系图（E-RD，Entity-Relationship Diagram）描述数据对象间的关系，用来进行数据建模活动的记号。v状态转换图（STD，State Transition Diagram）指明作为外部事务的结果，系统将如何动作。v分析模型结构的外层是规约描述：v在实体关系图中每个数据对象的属性可以运用数据对象来描述。v在数据流图中出现的每个加工/处理的功能描述包含在加工规约中。v软件限制方面的附加信息包含在限制规约中11/5/面对数据的建模方法v系统建模的一个重要方面就是要定义系统处理的逻辑结构。v最广泛接受的数据建模技术是实体-关系模型，它描述数据实体、关联及实体属性。v实体关系模型可用ERD实体关系图）来表示：v实体v关联v实体属性v基数11/5/实例分析：图书馆系统图书馆系统1借书记录预约记录借/还/续借1M1NM包含预约借书者图书书目11/5/实例分析：图书馆系统图书馆系统v实体：图书、借书者、管理员、借书书目、预约记录、书目v属性给出如下：v借书者：借书者编号、姓名、性别、借书数、最大借书数、罚金金额、有限期v图书：图书号、书目号v书目：书目号、书名、作者、出版社、丛书名、保藏数、在馆数、预约数v借书记录：图书号、借书者编号、借出日期、应还日期、续借次数v预约记录：书目号、借书者编号、预约日期11/5/实例分析：POS机系统机系统1NM111包含付款描述销售支付商品描述商品11/5/实例分析：POS机系统机系统v实体有销售、支付、商品、商品描述v关联：销售包含一组商品；每个商品都有相应的描述信息；每个支付对应一个销售。v实体的属性：销售：编号、总价、1商品*，日期支付：编号、支付客户、找零、销售编号商品：编号、数量商品描述：名称、产地、厂家、单价11/5/小结v分析模型帮助用户逐层深化理解问题，为软件设计供应基础。v结构化分析方法是一种自顶向下，逐步分解的面对数据和数据流的建模方法。v面对数据的建模以实体、关系和属性三个基本元素描述系统，涉及数据及其它们之间的关系，用ERD表示。11/5/第第6讲讲 结构化分析建模结构化分析建模面对数据流的建模面对数据流的建模v面对数据流的建模是结构化需求分析方法之一v接受自顶向下逐层分解，描绘满足用户要求的软件模型v表示：v数据流图：描述系统处理过程v数据字典：模型中的数据信息集合v状态转换图：描述系统对内部或外部事务响应的行为模型11/5/数据流图符号数据流图符号数据源点或终点变换数据的处理数据存储数据流或或或11/5/数据流图举例数据流图举例v设一个工厂选购部每天须要一张定货报表。定货的零件数据有：零件编号、名称、数量、价格、供应者等。零件的入库、出库事务通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应当再次定货。v数据流分析：v数据源点：仓管员（负责入库或出库事务给定货系统）；v数据终点：选购员（接收每天的定货报表）；v数据流：事务，定货；v数据存储：定货信息，库存清单；v处理：处理事务，产生报表。11/5/数据流图举例数据流图举例v画基本系统模型采购员事务定货报表仓管员定货系统11/5/数据流图举例数据流图举例v第一步求精定货信息库存清单定货信息库存信息采购员定货报表产生报表仓管员处理事务事务11/5/数据流图举例数据流图举例v其次步求精仓管员采购员处理入库事务入库事务出库事务定货报表处理定货定货信息处理出库事务产生报表定货信息库存清单库存信息11/5/数据字典卡片方式示例卡片方式示例名字：定货报表别名：定货信息描述：每天一次需要定货的零件表定义：定货报表=零件编号+零件名称+定货数量+价格+1供应者3 位置：输出到打印机名字：零件编号别名：描述：惟一标识一个特定零件的关键组成定义：零件编号=8位字符位置：定货报表、定货信息 库存清单名字：定货数量别名：描述：某个零件一次定货的数目定义：定货数量=1|2|3|4|5 位置：定货报表 定货信息名字：价格别名：价格范围描述：某个零件目前参考价格或者上下限定义：价格=1零件单价2位置：定货报表 定货信息 库存清单11/5/状态转换图v状态模型是一种描述系统对内部或者外部事务响应的行为模型。v它描述系统状态和事务，以及事务引发系统在状态间的转换。v这种模型适用于描述实时系统v状态模型一般接受状态转换图（简称状态图）的标记方法v状态图描述了系统中某些困难对象的状态变更v状态是可视察的行为模式，用圆角矩形表示；v变迁表示状态的转换，用箭头表示；v事务是引发变迁的消息，用箭头上的标记表示。v状态图还可以用事务后的方括号表示先决条件，只有当这个条件为真时，才会发生状态变更；用状态自身的弧线箭头表示先决条件不为真时，状态不会变更。11/5/复印机限制软件状态图复印机限制软件状态图读命令复印重加载纸诊断问题闲置与“读命令”相关非卡纸与“读命令”相关卡纸与“完成问题”相关“满”和“开始”与“复印”相关复印与“读命令”相关满与“读命令”相关11/5/图书馆系统图书馆系统 借书 还书 续借 预约管理员借书者书目号和借书证号书目号书目号标题号和借书证号11/5/图书馆系统图书馆系统管理员借书者验证借书者和图书借书者图书创建借书记录显示失败信息更新借书者更新图书信息显示借书成功不允许借书记录图书信息允许借书者信息11/5/图书馆系统实体关系图图书馆系统实体关系图借书目条码号分类号ISBN注册/更改/注销录入/更新/删除ISBN号书名作者出版社馆藏数价格可借数系统管理工号姓名性别权限密码标题借书证号条码号借书日期归还日期续借次数借书记录借书证号姓名性别地址身份借书数罚金借书者还包含续借借书证号ISBN预约日期图书号预约11/5/图书馆系统数据字典图书馆系统数据字典名称：标题别名：抽象的图书描述：描述一个抽象的图书的信息定义：标题=ISBN+书名+作者+出版社+出版日期版次+价格+目录+内容简介+馆藏数+可借数+预约数位置：图书查询、借书、还书、预约名称：书目别名：具体的书描述：对应标题的具体的一本书定义：书目=条码号+分类号+ISBN位置：借书、还书、更新11/5/小结结构化分析方法是一种自顶向下，逐步分解的面对数据和数据流的建模方法。基于数据流的方法用于描述数据如何在系统中流淌或被变换，用数据流图、数据字典、加工规程等形式表示。11/5/第第7讲讲 面对对象分析面对对象分析v面对对象建模v用例模型v领域模型v案例分析11/5/面对对象建模v面对对象模型v对象模型：定义了“做什么”的实体v动态模型：规定在何种状态下，接受什么事务的触发而“做什么”v功能模型：指明白系统应当“做什么”11/5/统一建模语言UMLv统一建模语言（UML，Unified Modeling Language）是一种基于面对对象的可视化建模语言。vUML用丰富的图形符号隐含表示了模型元素的语法，而用这些图形符号组成元模型表达语义，组成模型描述系统结构（或称为静态特征）以及行为（或称为动态特征）。vUML的模型元素：v一类模型元素用于表示模型中的某个概念，如类、对象、用例、结点、构件、包、接口等；v另一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依靠、聚集（表示整体与部分的关系）等。11/5/UML模型元素模型元素聚集依赖泛化关联状态对象属性操作类属性操作角色用例结点构件包接口注释11/5/UML模型视图vUML主要是用来描述模型的。它可以从不同视角为系统建模，形成不同的视图（View）。每个视图是系统完整描述中的一个抽象，代表该系统一个特定的方面；每个视图又由一组图（Diagram）构成，图包含了强调系统某一方面的信息。v两类图：v静态图：包括用例图、类图、对象图、构件图和部署图v动态图：包括状态图、时序图、协作图和活动图v五种视图：v用例视图从用户角度表达系统功能；v结构视图主要运用类图和对象图描述系统静态结构；v行为视图展示系统动态行为及其并发性；v实现视图展示系统实现的结构和行为特征；v部署视图展示系统的实现环境和构件是如何在物理结构中部署的11/5/用例建模v需求捕获的目标：v发觉真正的需求v以适用于用户、客户和开发人员的方式加以表示v系统用户表示为一个参与者v参与者在与用例进行交互时运用系统v用例向参与者供应某些有价值结果而执行一些动作序列11/5/编写用例v用例着眼于为用户增加价值，供应了一种捕获功能需求的系统且直观的方法，可驱动整个开发过程。v用例从某个特定参与者的角度用简洁易懂的语言说明一个特定的运用场景。v要起先开发用例，应列出特定参与者执行的功能或者活动。v用例模型帮助客户、用户和开发人员在如何运用系统方面达成共识。v用例图描述部分用例模型，显示带有联系的用例和参与者的集合11/5/POS机系统部分用例图机系统部分用例图11/5/用例图用例图v用例图包括：参与者、用例、关联和边界四个要素。v参与者：用小人形表示v用例：用椭圆表示v关联：用直线表示说明参与者驱动某个用例v边界：用矩形框表示，说明系统关注点。11/5/开发用例开发用例v用例运用非正式的描述性风格编写，也可以运用某个结构化的格式编写，有些格式更强调描述的直观性。11/5/POS机系统中处理销售的场景机系统中处理销售的场景v用例名称：处理销售用例名称：处理销售v范围：范围：POS机应用机应用v级别：用户目标级别：用户目标v主要参与者：收银员主要参与者：收银员v涉众及其关注点：涉众及其关注点：v收银员：希望能够精确、快速地输入，而且没有支付错误，因为假如少收货款，收银员：希望能够精确、快速地输入，而且没有支付错误，因为假如少收货款，将从其薪水众扣除。将从其薪水众扣除。v售货员：希望自动更新销售提成售货员：希望自动更新销售提成v顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。所输入的商品项目和价格。希望得到购买凭证，以便退货。v公司：希望精确地记录交易，满足顾客要求。希望确保记录了支付授权服务的公司：希望精确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有确定的容错性，即便在某些服务器构件不行用时（如远程信支付票据。希望有确定的容错性，即便在某些服务器构件不行用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。v经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。v前置条件：收银员必需经过确认和认证。前置条件：收银员必需经过确认和认证。v成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付授权的批准。生成票据，记录支付授权的批准。11/5/主成功场景v1.顾客携带所购商品或服务到收银台通过POS机付款。v2.收银员起先一次新的销售交易。v3.收银员输入商品条码。v4.系统逐步记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。v5.系统显示总额和计算折扣。v6.收银员告知顾客总额，并请顾客付款。v7.顾客付款，系统处理支付。v8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。v9.系统打印票据。v10.顾客携带商品和票据离开。11/5/开发活动图vUML活动图通过供应特定的场景内沟通的图形化表示来补充用例。v活动图符号：v两端为半圆形的矩形表示一个特定的系统功能v箭头表示通过系统的流v判定菱形表示判定分支v水平线、分叉点和连接表示并发活动v对象节点表示活动对象v活动图通常能够既表示限制流又表示数据流。vUML活动图代替传统的数据流图（Data Flow Diagram）表示法11/5/处理销售用例中的处理销售用例中的UML活动图活动图11/5/泳道图vUML泳道图（swimlane）是活动图的一种有用的变形v可以让建模人员表示用例所描述的活动图，同时看哪个参与者或分析类对活动矩形所描述的活动负责。v泳道用纵向分割图的并列条形部分表示，就像游泳池中的泳道，也称特定分区。vUML泳道图通常对于涉及众多参与者的特别困难的业务过程建模具有价值。11/5/泳道图举例11/5/建立领域模型v领域模型能捕获语境中最重要的对象模型，领域对象代表系统工作的环境中存在的事情或发生的事务。v领域有三种典型的形式：v业务对象，表示业务中可操作的东西，例如订单、帐户和合同等。v系统须要处理的现实世界中的对象和概念，如导弹、轮船等。v将要发生或已经发生的事务，例如飞机起飞或午餐休息等。v领域建模的目的是理解和描述在领域语境中最重要的类11/5/分析类分析类v分析类侧重于处理功能性需求v通过较高的、非形式化层次的职责类定义某行为v分析类三种基本构造型：v边界类：边界类用于建立系统与其参与者之间交互的模型，常常代表对窗口、窗体、窗幕、通信接口、打印机接口、传感器、终端以及API等的抽象。每个边界类至少应当与一个参与者有关，反之亦然。v限制类：限制类代表协调、排序、事务处理以及其他对象的限制，常常用于封装与某个具体用例有关的限制。限制类还可以用来表示困难的派生与演算，如业务逻辑。v实体类：实体类用于对长效长久的信息建模。大多数状况下，实体类是干脆从业务对象模型中相应的业务实体类得到的。11/5/分析类举例分析类举例11/5/限制类限制类v限制类类似于设计模型中的限制器类，其目的是UI层之上的第一个对象，主要负责接收和处理系统操作消息。把职务安排给能代表以下选择之一的类：v代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些是外观限制器的全部变体。v代表用例场景，在该场景中发生系统事务，通常命名为UsecaseName+Handler、UsecaseName+Coordinator或UsecaseName+Session。11/5/限制类举例限制类举例11/5/用例实现分析v用例实现分析是分析模型内部的一种协作，主要描述了如何依据分析类及其交互的分析对象来实现和执行一个具体的用例。v用例实现包括事务流的文本描述、反映参与者用例实现的分析的类图以及依据分析对象的交互作用描述特定流实现或用例脚本的交互图。v用例实现侧重于功能性需求。11/5/处理销售类图处理销售类图11/5/交互图交互图v当参与者向系统发送某种形式的消息而激活用例时，起先执行该用例中的动作序列。v边界类对象将接收来自参与者的消息。v边界对象向其他对象发送一个消息，并使有关对象与之交互从而实现该用例。v在分析阶段，通常运用协作图类描述用例的实现。v协作图又称为通信图，是以图或网络格式描述对象交互，其中对象可以置于图中任何位置。11/5/11/5/分析包分析包v分析包描述了对分析模型的制品进行组织的方式，它可以包括分析类、用例实现及其他分析。v分析包应是有强内聚性与低耦合性，具有以下特点：v分析包可以表示对分析内容的分割。v在统一过程中，服务的概念是由服务包支持的。服务包在依据系统供应的服务而组织的分析包层次结构中处于较低层。服务包包含了一组活动相关的类，服务包不行分割。v在实现用例时，可能会有一个或多个服务包参与其实现。服务包相对独立，可以复用。vUML包图用于描述系统的逻辑架构层、子系统、包等。vUML包用一大一小两个矩形组合而成。假如内部显示了其成员，则包名称标在上面的小矩形内，否则，可以标在包内。11/5/UML包图包图11/5/逻辑架构逻辑架构v逻辑架构是类的宏观组织结构，它将类组织为包、子系统和层等。v层是对类、包或子系统的甚为粗粒度的分组，是有对系统主要方面加以内聚的职责。11/5/分层逻辑架构分层逻辑架构11/5/关联与依靠v两个分析类以某种方式相互联系，这些联系被称作关联。v关联可进一步指出多样性，也称为基数。v两个分析类之间存在客户服务器联系，客户类在某些方面依靠于服务器类并且建立了依靠关系。11/5/识别属性和操作v属性描述类的性质，可以通过分析该类存在的一些信息类构建。v操作定义了某个对象的行为。v操作可以分为四种类型：v以某种方式操纵数据，例如：添加、删除、选择、更新等。v执行计算的操纵，例如：销售中的计算总价。v恳求某个对象状态的操作。v监视某个对象发生某个限制事务的操作。v操作的构造须要交互图和场景描述等手段多次反复分析才能获得。在探讨语法分析并分别动词作为候选的操作。举荐的一个方法是运用CRC技术。11/5/CRC技术技术vCRC(Class-Responsibility-Collaborator,类-职责-协作者)建模供应识别和组织与产品相关的类。v一旦系统的基本运用场景（用例）确定后，则要标识侯选类，指明它们的责任和协作，即类-责任-协作者建模：v责任是与类相关的属性和操作，即责任是类知道要做的事情。v协作者是为某类供应完成责任所须要的信息的类，即协作类。vCRC建模方法供应了一种简洁标识和组织与系统或产品需求相关的类的手段。vCRC模型是一组表示类标准的索引卡CRC卡的集合。vCRC卡的内容分成三个部分：v类的名字v类的责任v协作类11/5/销售类销售类CRC卡卡11/5/第8讲 面对对象分析行为建模v行为模型显示了软件如何对外部事务或激励做出响应。要生成行为模型，分析师必需按如下步骤进行：v评估全部的用例，以使得完成理解系统内的交互序列。v识别驱动交互序列的事务，并理解这些事务如何和具体的类相互关联。v为每个用例生产序列。v创建系统状态图。v评估行为模型以验证精确性和一样性。11/5/系统依次图系统依次图v系统依次图（System Sequence Diagram,SSD）是为了阐述与探讨系统相关的输入和输出事务而快速、简洁地创建的制品。v它们是操作契约和重要对象设计的输入。v用例文本及其所示的系统事务是创建SSD的输入。vSSD展示了干脆与系统交互的外部参与者，系统以及由参与者发起的系统事务。vSSD可以用UML依次图的形式表示，用以阐述外部参与者到系统的事务。v系统事务就是将系统看作黑盒，参与者为完成功能而向系统发出的事务。11/5/处理销售用例的系统处理销售用例的系统SSD11/5/操作契约操作契约v操作契约运用前置条件和后置条件的形式，具体和精确描述领域模型中的对象的变更，并作为系统操作的结果。v操作契约的主要输入是SSD中确定的系统操作、领域模型和领域专家的见解。v操作契约四部分：v操作是指操作的名称和参数v交叉引用是指会发生此操作的用例v前置条件是指执行操作之前对系统领域模型对象状态的假设v后置条件是指完成操作后，领域模型对象的状态11/5/后置条件后置条件v后置条件（Post Condition）描述了领域模型内对象状态的变更。v领域模型状态变更包括创建用例、形成或消退关联以及变更属性。v后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的视察结果。v后置条件可以分为三种类型：v创建或删除实例v属性值的变更v形成或消退关联11/5/操作操作enterItem的契约的契约v操作名称操作名称：enterItem(id,quantity)v交叉引用交叉引用：处理销售用例v前置条件前置条件：正在进行的销售v后置条件后置条件：（1）创建了SaleLineItem的实例（创建关联）（2）SaleLineItem与当前Sale关联（形成关联）（3）SaleLineItem.quantity赋值为quantity(修改属性)（4）基于id匹配，将SaleLineItem关联到Product Description(形成关联)11/5/依次图与协作图v表现系统行为方式的一种方式是UML的依次图和协作图。v依次图和协作图的作用相同，但依次图强调事务的时间关系。v依次图表现了导致行为从一个类流淌到另一个类的关键类和事务。v依次图的主要元素有：v对象：参与交互的类的实例，对象之间可以发送事务和接收事务。v参与者：描述本次交互的发起者，即用例的驱动者。用小人形态表示。v生命线：表示一个类的实例，用虚线表示。v消息：表示对象间的每个事务，用带箭头的实线表示。v执行规格条：表示限制焦点的限制期，也称为激活条。v消息标签：指明消息的名称。消息可以有两种方式返回结果：v运用消息语法return var=message（parameter）；v在执行规格条末端运用应答消息线（带箭头虚线）。11/5/处理支付用例的依次图处理支付用例的依次图11/5/11/5/状态图v两种不同的状态描述：v系统执行其功能时每个类的状态，类状态动两种特征：v被动状态较简洁，是某个对象全部属性的当前状态；v主动状态表示的是对象进行持续变换和处理时的当前状态。v系统执行其功能时从外部视察到的系统状态。vUML状态图描述系统的动态行为。vUML状态图描述了某个对象的状态和感爱好的事务以及对象响应当事务的行为。UML状态图的元素有：v状态：指对象在事务发生之间某时刻所处的情形，用圆角矩形表示。v转移：指两个状态之间的关系，它表明当某事务发生时，对象从从前状态转换到后来的状态，用带有标记事务的箭头表示。v事务：某个事情的发生。v初始状态：当实例创建时，对象所处的状态。11/5/POS机的一个简洁的状态图机的一个简洁的状态图11/5/实例分析：POS机系统11/5/实例分析：POS机系统11/5/11/5/添加商品项的依次图添加商品项的依次图11/5/计算总价计算总价11/5/处理支付依次图处理支付依次图11/5/小结v分析建模的目标是创建各种表现形式，以描绘软件信息、功能和行为需求。v行为模型运用SSD、操作契约、依次图和状态图来分析系统的动态行为。11/5/v其次部分（完）其次部分（完）11/5/2022