软件需求分析与设计－业务建模和需求细化

软件需求分析与设计业务建模和需求细化,2018/1/30,2,业务建模和需求细化,主要内容迭代1基础领域模型系统顺序图操作契约,2018/1/30,3,初始不是需求阶段,细化阶段的迭代1强调的是基础范围和在构建对象系统中所使用的常见OOA/D技术构件软件其他技术也要涉及数据库设计可用性工程UI设计在迭代开发中，并非一次实现所有需求在多次迭代里对同一用例进行增量式开发,2018/1/30,4,用例的实现可能在多个迭代中展开,2018/1/30,5,初始阶段的工作,简单的需求讨论会大多数参与者、目标和用例名称大多数以摘要形式编写的用例确定大多数具有影响和风险的质量需求编写设想和补充性规格说明的第一个版本风险列表技术上的概念验证原型和其他调查，用于揭示特殊需求的技术可行性面向用户界面的原型，用于确定对功能需求的设想对购买/构建/复用构件的建议对候选的高层架构和构件给出建议,2018/1/30,6,细化工作,细化是核心架构、解决高风险元素、定义大部分需求，以及预计总体进度和资源对核心、有风险的软件架构进行编程和测试发现并稳定需求的主题部分规避主要风险细化通常有两个或多个阶段细化不是设计阶段,2018/1/30,7,细化最佳实践,实行短时间定量、风险驱动的迭代及早开始编程对架构的核心和风险部分进行适应性的设计、实现和测试尽早、频繁、实际地测试基于来自测试、用户、开发者的反馈进行调整通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次,2018/1/30,8,细化阶段的制品样例,2018/1/30,9,何时知道自己并没有理解细化阶段,对于大部分项目，细化阶段都比“几个”月更长只有一次迭代在细化开始之前就定义了大部分需求没有处理具有风险的元素和核心架构没有产生可执行架构，没有进行产品代码的编写认为细化阶段主要是需求和设计阶段，为构造阶段的实现进行准备试图在编程之前进行彻底和细致的设计只有少量的反馈和调整；用户没有持续地参与评估和反馈没有尽早和实际的测试在编程之前推测地结束架构设计认为细化阶段是进行概念验证编程阶段，而不是对产品核心架构编程阶段,2018/1/30,10,领域模型,是对领域内的概念类或现实世界中对象的可视化表示也称概念模型、领域对象模型和分析对象模型在UP中，是对现实世界概念类的表示，而非软件对象的表示，该术语并不是指用来描述软件类、软件构架类领域层或有职责软件对象的一组图UP领域模型是UP业务对象模型的特化UML，领域模型被描述为一组没有定义操作的类图，它提供了概念透视图领域对象或概念类概念类之间的关联概念类的属性,2018/1/30,11,用例制品关系样例,2018/1/30,12,领域模型,2018/1/30,13,领域模型,是对所关注的现实世界领域中事物的可视化，以下元素不适用于领域模型软件制品，如窗口或数据库责任和方法,2018/1/30,14,领域模型表示真实世界概念类，不是软件类,Sale,dateTime,对领域内所关注的真实世界概念的可视化并非表示软件类,2018/1/30,15,领域模型并非表示软件制品或类,2018/1/30,16,领域模型传统含义,“软件对象的领域层”在表示层或UI层之下的软件对象层是由领域对象组成的领域对象是表示问题领域空间事物的软件对象与“业务逻辑”或“领域逻辑”方法有关在本课中用“领域层”表示上述含义,2018/1/30,17,概念类,概念类是思想、事物或对象符号，表示概念类的词语或图形内涵，概念类的定义外延，概念类所适用的一组示例,2018/1/30,18,概念类具有符号、内涵和外延,2018/1/30,19,领域模型,领域模型不是数据类允许没有明确要求记录其相关信息的类允许没有属性的概念类如纯行为角色的概念类,2018/1/30,20,OO建模减少了表示之差,2018/1/30,21,领域模型准则,如何创建领域模型寻找概念类将其绘制为UML类图中的类添加关联和属性如何找到概念类重用和修改现有的模型使用分类列表确定名词短语,2018/1/30,22,表91 概念类分类列表,2018/1/30,23,表91 概念类分类列表,2018/1/30,24,主成功场景1、顾客携带所购商品或服务到POS机付款处进行购买交易2、收银员开始一次新的销售交易3、收银员输入商品标识4、系统逐条记录出售的商品，并显示该商品项目的描述、价格和累计额。价格通过一组价格规则来计算收银员重复34步，直到结束5、系统显示总额和所计算的税金6、收银员告知顾客总额，并提请付款7、顾客支付，系统处理支付8、系统记录完整的销售信息，并将销售和支付信息发送到外部的帐务系统（进行帐务处理和提成）和库存系统（更新库存）9、系统打印票据10、顾客携带商品和票据（如果有）离开扩展7a. 现金支付1、收银员输入收取的现金额2、系统显示找零金额，并弹出现金抽屉3、收银员放入收取的现金，并给顾客找零4、系统记录该次现金支付,2018/1/30,25,寻找和描绘概念类,2018/1/30,26,业务建模准则,敏捷建模绘制类图的草图敏捷建模是否要实用工具维护模型报表对象模型中是否要包含“票据”一般来说，在领域模型中显示其他信息的报表并没有意义，因为其所有的信息都是源于或复制于其他信息源的像地图绘制者一样思考；使用领域术语使用地域中现有的名称排除无关或超出范围的特性不要凭空增加事物如何对非现实世界建模吸取领域专家所使用的核心词汇和概念,2018/1/30,27,业务建模准则,属性与类的常见错误如果我们认为某概念类不是现实世界中的数字或文本，那么X可能是概念类而不是属性,Sale,Store,Sale,Store,phoneNumber,Flight,destination,Flight,Airport,name,或?,或?,2018/1/30,28,何时使用”描述”类建模,描述类包含描述其他事物的信息产品描述（ProductDescription）在以下情况下需要增加描述类需要有关商品或服务的描述，独立于任何商品或服务的现有实例删除其所有描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来减少冗余或重复信息,2018/1/30,29,关于其他事物的描述,较好,较差,2018/1/30,30,关联,关联（association）是类之间的关系，表示有意义和值得关注的链接 UML中，关联被定义为“两个或多个类元之间的语义联系，设计这些类元实例之间的连接”,2018/1/30,31,关联准则,何时表示关联如果存在需要保持一段时间的关系，将这种语义表示为关联从常见关联列表中派生的关联重点关注需要记住的关联n*(n-1)/2关联是否会在软件中实现领域模型不是数据模型，添加关联是为了突出对重要关系的大致理解，而非记录对象或数据结构,2018/1/30,32,应用UML关联表示法,以“类名动词短语类名”格式为关联命名，其中的动词短语构成了可读的和有意义的顺序,2018/1/30,33,应用UML角色,关联的每一端为角色多重性表达名称导航,2018/1/30,34,应用UML多重性,定义了类A有多少个实例可以和类B的一个实例关联多重性的值表示在特定时刻有效关联的实例数量多重性的值和建模者和软件开发者的关注角度有关，因为他表达了将要（或可能）早软件中反映的领域约束多重性是与语境有关联的,2018/1/30,35,关联的多重性,多重性的值,应用UML多重性,2018/1/30,36,应用UML两个类之间的多重性关联,2018/1/30,37,2018/1/30,38,NextGen Pos部分领域模型,2018/1/30,39,属性,属性是对象的逻辑数据值当需求建议或暗示需要记住信息时，引入属性大部分建模者会假设属性的可见性为私有的，除非有另外的表示导出属性信息由其他信息计算出来表示法visibility name :type multiplicity = defaultproperty-sting,2018/1/30,40,表示法,2018/1/30,41,属性的类型,领域模型中的属性应该是数据类型Boolean, Date , Number, Character, string, TimeAddress, Color, Geometrics(Point, rect) PhoneNumber/Social Security Number, Universal Product Code (UPC), 邮政编码、枚举类型通过关联而不是属性来表示概念类之间的关系,2018/1/30,42,较好,较差,非“”数据类型“数据,使用关联而不是属性表示关系,2018/1/30,43,数据类型,数据类型是“基本”类型，通常对内容区分没有实际意义数据类型值往往时恒定不变的何时增加新的类型由不同的小节组成具有与之相关的操作具有其他属性单位的数量具有以上性的一个或多个类型的抽象,2018/1/30,44,表示对象的数据类型特性的两种方式,2018/1/30,45,属性,应使用关联而不是属性来将类型关联起来,较差,较好,“简单”属性，但是用作外键与其他对象关联,2018/1/30,46,对数量建模,用数字表示数量不应该表示为纯数字给数量加上单位可以把数量表示为单独的Quantity类，并且关联到Unit,2018/1/30,47,对数量建模,2018/1/30,48,NextGen Pos部分领域模型,2018/1/30,49,UP制品及其时限示例（s:开始，r:精化）,2018/1/30,50,UP制品关系示例,领域模型,sale,date.,1,1.*,quantity,SalesLineItem,. . . . .,. . . . .,用例模型,Process Sale1.Custom arrives2.Cashier makesnew sale.3. ,用例名称,用例图,用例文本,Operation:enter Item()Post-conditions:,操作契约,:Cashier,:System,Make New Sale(),enter Item( id ,quantity),系统顺序图,系统操作,设想,词汇表,补充性规格说明,要设计的启动事件,参数和返回值的细节,:Register,:Product Catalog,:Sale,设计类型,Enter Item (itemID, quantity),Spec=getProductSpec(itemID),addLineItem(spec,quantity),业务建模,需求,设计,图6-1 UP制品影响示例,2018/1/30,51,系统的外部参与者,UML循环交互图框具有布尔量守护表达式,与前一消息关联的返回值；忽略了表现和媒介的抽象；如果没有任何返回，则返回线式可选的,具有参数的消息；抽象地表示了以某种机制输入支付数据的系统事件,系统作为黑盒，其命名可以是“NextGenPos”,但是“System”保持了简洁性；,2018/1/30,52,系统顺序图,系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品在交互中，参与者对系统发起系统事件，通常需要某些系统操作，对这些事件加以处理系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件需要处理和响应这些事件来设计软件来自参与者（人或计算机）的外部事件时间事件错误或异常,2018/1/30,53,只有现金支付并简化的处理销售场景1、顾客携带所购商品和服务到POS机付款处进行购买交易2、收银员开始一次新的销售交易3、收银员输入商品项目标识4、系统逐条记录出售的商品项目，并显示该商品项目的描述、价格和累计额。价格通过一组价格规则来计算收银员重复步骤34，指导结束5、系统显示总额和所计算的税金6、收银员告知顾客总额并提请付款7、顾客支付，系统处理支付。,2018/1/30,54,系统事件的命名,系统事件应该在意图的抽象级别而非物理的输入设备级别来表达系统事件的名称以动词开始,较好的命名,较差的命名,2018/1/30,55,UP制品关系示例,领域模型,sale,date.,1,1.*,quantity,SalesLineItem,. . . . .,. . . . .,用例模型,Process Sale1.Custom arrives2.3.Cashier enters item identifier,用例名称,用例图,用例文本,Operation:enter Item()Post-conditions:,操作契约,:Cashier,:System,Make New Sale(),enter Item( id ,quantity),系统顺序图,系统操作,设想,词汇表,补充性规格说明,要设计的启动事件，并包含了软件必须满足的更为细化的需求,软件必须满足需求,:Register,:Product Catalog,:Sale,设计类型,Enter Item (itemID, quantity),Spec=getProductSpec(itemID),addLineItem(spec,quantity),业务建模,需求,设计,图6-1 UP制品影响示例,系统事件,用于后置条件的想法,经历变化的领域对象、属性和关系,2018/1/30,56,契约CO2:enterItem,2018/1/30,57,操作契约内容,2018/1/30,58,定义系统操作,系统操作为黑盒构件的系统在其公共接口中提供的操作设计所有用例的系统操作的完整集合将系统视为一个构件或类，定义了公共的系统接口