《软件工程复习.docxVIP

软件的特性软件是一种逻辑实体，而不是具体的物理实体。它具有抽象性软件的开发设计、生产、维护与硬件不同在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题大多数软件是定制的软件的开发和运行常常受到计算机系统的限制对计算机系统有着不同程度的依赖性软件开发至今尚未完全摆脱手工艺的开发方式软件是复杂的软件成本相当昂贵相当多的软件工作涉及到社会因素软件危机的表现 、原因软件危机---主要表现：对软件开发成本和进度的估计不准确用户不满意软件质量不高、可靠性差软件常常不可维护、错误难以改正缺乏适当的文档资料软件成本占系统总成本的比例逐年上升（1985----90%）软件开发速度跟不上计算机发展速度归结为主要为三方面--“时间、成本、质量”软件危机--原因：软件规模日渐庞大（数量、功能、成本、质量、时间）软件开发管理困难。逻辑部件而不是物理部件。在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。开发人员错误的观念、方法和技术重编程、轻需求。生产方式落后：个体手工方式。开发技术落后\开发工具落后忽视软件开发前期的需求分析 开发过程缺乏统一的、规范化的方法论的指导文档资料不齐全或不准确忽视与用户之间、开发组成员之间的交流忽视测试的重要性不重视维护或由于上述原因造成维护工作的困难需求变化预料不足用例归约用例规约--进行用例阐述用例规约：更进一步的精度用例文档的核心，而用例图作为用例文档的总图进一步的精度：有层次的文档文档中每一句话都有其价值用例规约组成用例名称：处理销售用例标识涉及的参与者涉及的用例描述用例的规格说明前置条件 与 后置条件 正常事件流备选事件流其它非功能需求、设计约束、尚存在的问题举例(非正式型)处理退货主要成功场景：顾客带着商品到收款处退货，出纳员使用POS终端记录每一件被退回的商品。。。。可选场景：如果系统中找不到商品标识，那么就通知出纳员并建议他手工输入商品标识码（或许商品的标识已经破损）；如果系统检测到和外部税金计算系统之间的通信失败，那么就。。。正式型用例 UC1：处理销售主要参与者：出纳员受益人及其利益：出纳员：需要精确、快速的输入，并且不出现支付错误销售人员：需要销售款得到更新顾客：需要购买并花费最小的精力得到快速的服务，并需要支持退货功能公司：需要精确地记录交易并满足客户的利益。需要支付授权服务记录可接受的支付。需要一些容错功能。需要账目和存货清单得到自动的快速更新政府税务机构：需要从每一次销售中收税。支付授权服务：需要用正确的格式和协议传来的数字授权请求。需要精确计算它们可支付给商店的款额前置条件：出纳员需要身份识别并授权后置条件：存储了销售情况，正确地计算了税金，更新了账目和存货清单，记 录了销售额，打印了收据主要成功场景：顾客带着商品到POS终端出准备购买出纳员开始一次新的销售出纳员输入商品标识码系统记录销售的商品并给出商品的描述、单价和折扣，并根据某些价格规则计算所应付的款额。出纳员重复步骤3和步骤4，一直到处理完所有商品为止。系统给出所应支付的总款额并计算税金出纳员告诉顾客总价并请求付款顾客付款，系统处理支付系统记录下已完成的销售，并将销售和支付信息发送给外部的账目系统以及存货清单系统系统打印收据顾客带着收据和商品离开类与类图类及类之间的关系案例李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。发现类李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。 筛选备选类“李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规