信息系统分析与设计复习new

②对一些重要模块还必须根据数据流图、数据字典及H图绘制具体的IPO图。数据流图的种类变换型（Transform）结构。事务型（Transaction）结构。数据流图模块结构图变换分析：用来描述输入、处理、输出数据流。确定DFD中的变换中心、逻辑输入和逻辑输出。设计软件结构的顶层和第一层——变换结构。--第一级分解A.变换中心确定以后，就相当于决定了主模块的位置，这就是软件结构的顶层；其功能是主要完成所有模块的控制，它的名称是系统名称，以体现完成整个系统的功能。B.顶层确定之后，设计软件结构的第一层。第一层至少要有输入、输出和变换三种功能的模块。C.为每个逻辑输入设计一个输入模块，其功能为向顶层模块提供相应的数据。D.为每个逻辑输出设计一个输出模块，其功能为输出顶层模块的信息。E.为变换中心设计一个变换模块，它的功能是将逻辑输入变换为逻辑输出。设计中、下层模块——对第一层的输入、变换及输出模块自顶向下、逐层分解。--第二级分解A.输入模块的下属模块的设计(每个输入模块可以设计成两个下属模块：一个接收，一个转换。用类似的方法一直分解下去，直到物理输入端。)B.输出模块的下属模块的设计(每个输出模块可以设计成两个下属模块：一个转换，一个发送，一直到物理输出端。)C.变换模块的下属模块的设计(根据DFD变换中心的组成情况，按照模块独立性的原则来组织其结构，一般对DFD中每个基本加工建立一个功能模块。)设计优化——以上步骤设计出的软件结构仅仅是初始结构，还必须根据设计准则对初始结构精细和改进。A.输入部分的求精：对每个物理输入设置专门模块，以体现系统的外部接口；其他逻辑输入模块并非真正输入，当它与转换数据的模块都很简单时，可将它们合并成一个。B.输出部分的求精：为每个物理输出设置专门模块，其他逻辑输出模块并非真正输出，当它与转换数据的模块都很简单时，可将它们合并成一个模块；同时注意把相同或类似的物理输出模块合并在一起，以降低耦合度。C.变换部分的求精：根据设计准则，对模块进行合并或调整。总之，软件结构的求精，带有很大的经验性。往往形成DFD中的加工与结构图中的模块之间是一对一的映射关系，然后再修改。但对于一个实际问题，可能把DFD中的两个甚至多个加工组成一个模块，也可能把DFD中的一个加工扩展为两个或更多个模块，根据具体情况要灵活掌握设计方法，以求设计出由高内聚和低耦合的模块所组成的、具有良好特性的软件结构。事务分析：用来描述多种事务类型的处理。虽然在任何情况下都可以使用变换分析方法设计软件结构，但是在数据流具有明显的事务特点时，也就是有一个明显的“发射中心”(事务中心)时，还是以采用事务分析方法为宜。综合DFD的映射一个大型系统的DFD中，既有变换流，又有事务流，属于综合的数据流图，其软件结构设计方法如下：A.确定DFD整体上的类型。事务型通常用于对高层数据流图的变换，其优点是把一个大而复杂的系统分解成若干较小的简单的子系统。变换型通常用于对较低层数据流图的转换。变换型具有顺序处理的特点，而事务型具有平行分别处理的特点，所以两种类型的DFD导出的软件结构有所不同。只要从DFD整体的、主要功能处理分析其特点，就可区分出该DFD整体类型。B.标出局部的DFD范围，确定其类型。C.按整体和局部的DFD特征,设计出软件结构。分层DFD的映射A.对于一个复杂问题的数据流图，往往是分层的。B.分层的数据流图映射成软件结构图也应该是分层的，这样便于设计，也便于修改。C.由于数据流图的顶层图反映的是系统与外部环境的界面，所以系统的物理输入与物理输出都在顶层或0层图，相应的软件结构图的物理输入与输出部分应放在主图中，便于同DFD的顶层图对照检查。D.分层DFD的映射方法分类：主图是变换型，子图是事务型主图是事务型，子图是变换型模块的内聚是什么，内聚的类型及其含义、紧密程度。模块的内聚模块的内聚反映模块内部联系的紧密程度。原则：一个模块只需要做好一件事情，不要过分关心其他任务。高内聚性的好处是可以提高程序的可靠性。内聚的类型及其含义、紧密程度偶然内聚：当同一个子程序中的操作之间无任何联系时，为偶然内聚性，也叫作“无内聚性”。（比如只是为了将程序中某几处凑巧相同的一些语句组合起来形成的一个模块。）低逻辑内聚：将几个逻辑上相似的功能放在一个模块中。（比如常见的出错处理模块，工作模块发现错误后，调用错误处理模块，将错误号作为控制参数传入，然后出错处理模块根据不同的错误号执行相应的操作。）低准备准备算平均成绩算最高成绩返回Y取平均成绩?N时间内聚：将在有限时间单元内处理的成分组合为同一模块。（可视化程序设计中在窗口打开时初始化窗口中的控件内容，如列表框的项目、文本框或单选钮的缺省取值；还比如：C++的构造函数、析构函数。）低enterdatacheckdatamanipulatedataenterdatacheckdatamanipulatedata中通信内聚：当模块内的成分引用共同的数据，而不存在其他联系时，称为通信内聚。中顺序内聚：模块中某个成分的输出是另一成分的输入。（比如显示期末成绩通知。）高是步骤内聚和通信内聚的结合。顺序内聚有较强的内聚性，但仍然不是最高的内聚类型

读入学号

读取成绩

取不及格科目取科目补考安排

显示数据

判断留退级功能内聚：一个模块包括并且仅仅包括为完成一个具体任务所需要的所有成分。高功能内聚性是最强也是最好的一种内聚。仅用一个动宾词组能明确指出这个模块的所有功能。结构化设计中软件结构的深度、宽度、扇入数和扇出数的概念。1、深度：表示软件结构中从顶层模块到最底层模块的层数；2、宽度：表示控制的总分布；3、扇出数：指一个模块直接控制下属的模块个数；4、扇入数：指一个模块的直接上属模块个数。平均扇出系数最好是3~5；一个模块扇出的上限不超过7；高层模块高扇出，最低层模块高扇入；一个好的软件结构的形态准则是：上面尖、中间宽、下面小，像清真寺的塔。结构化程序设计使用的三种基本逻辑结构。（顺序结构，选择结构，循环结构）

（当循环）（直到循环）(a)顺序(b)循环(c)选择(d)条件结构化模块详细设计的建模工具，会使用这些工具绘制模块内部的处理过程，复习7.6节的思考题。程序流程图（程序框图）盒图（NS图）在NS图中，每个处理步骤用一个盒子表示。盒子可以嵌套。盒子只能从上头进入，从下头走出，除此之外别无其他出入。程序设计语言（PDL）是用来描述模块内部具体算法的非正式的比较灵活的语言，或称类语言、伪码。思考题下面是用类C语言描述的一段程序，试分别程序流程图和N-S图表示。while（p）{A;do{B;}while（！Q）;}=1\*GB3①对应的N-S图如下：=2\*GB3②程序流程图如下：结构化分析和设计的建模工具。第八章-面向对象分析什么是消息。消息是指向对象发出的服务请求(对象间的交互信息)。一个对象向另一个对象发消息请求某项服务，接收消息的对象响应该消息，激发所要求的服务操作，并把操作结果返回给请求服务的对象。一个消息应当包含以下信息：消息名、接收消息对象的标识、服务类型、输入信息、回答消息。要求服务的消息具有特定的格式和输入参数，这种规定也称为消息协定。因为两个对象是各自独立运行的，对象A如果在某个时刻需要对象B的某项服务，就可以依据消息协议向对象B发送一个消息，对象A在消息发送后可以等待返回消息，也可以不要求回答就执行其他的事务。消息的实现形式：在面向对象设计和实现中，消息的一般形式就是函数调用【方法调用】。UML的特点。统一了面向对象方法的表示。表示能力强大，可用于各种软件系统建模，以及其他系统建模，如商业系统。与开发过程无关。允许扩展。本身不设计特点语言的语法及规则，但可对应到各种OOP语言框架。RUP软件开发过程四个阶段的任务及工作焦点。RUP的二维结构初始阶段：确定所设立的项目是否可行。明确说明项目规模，了解环境以及最重要的需求和约束。划分主要子系统，给出系统的体系结构概貌。考虑时间、经费、人员、技术、项目计划和效益等因素。分析项目执行的风险。工作焦点：需求和分析工作流。细化阶段：识别出大多数用例（80%）。建立健全的体系结构基础，编制项目计划，细化风险评估。用例模型需要完成80%。创建软件结构的描述性文档。创建可执行的系统原型。细化风险列表。创建整个项目的开发计划。工作焦点：分析和设计工作流。构造阶段：识别出最后剩余的用例。每一次迭代开发都对用例进行分析、设计、编码、测试和集成过程，最终得到满足项目需求的产品。优化资源，使开发成本降到最低。尽快达到质量要求。尽快完成有用的版本。完成所有功能的分析、开发和测试。迭代式、递增地开发随时可以发布的产品。确定准备好软件系统的外部环境。工作焦点：实现工作流。交付阶段：完成最后的软件产品和产品验收测试，并编制用户文档，进行用户培训等工作。将完整的系统部署到用户所处的环境，确保软件对最终用户是可用的。按用户的要求验证新系统。替换旧的系统。对用户和维护人员进行培训。开始调整工作，例如性能或可用性的增强。与用户达成共识，部署基线与评估标准一致。工作焦点：测试和部署工作流。UML中四种关系的表示和区别。类之间的联系方式：1、继承/泛化（generalization）：类之间的关系是指对象分类的层次关系，继承关系对于类中的所有对象都成立，而不特指某个具体对象。2、实现（realization）：即描述和实现。一个接口可以提供某些操作的描述，另一些类需要具体来完成这些操作，即对接口进行实现。对象关系则是存在于具体对象实例之间的联系：3、关联（association）：表达对象与对象的静态联系，是一种长期关系，比如整体和部分关系。4、依赖（dependency）：表达对象与对象的动态联系（运行时），是一种短期关系。五、复习用例图、用例规格说明，会画用例图，书写用例规格说明，会识别用例间的关系，复习课件8.5节的例子、课堂练习。1、用例建模的内容获取原始需求开发一个可以理解的需求识别参与者。参与者是系统之外与系统进行交互的任何事物。从三个方面来识别：A.使用系统的个人谁负责提供、使用或删除信息？谁将使用某项功能？B.系统所连接的外部硬件。例如：控制建筑物中温度的通风系统不断地从传感器获取温度信息，传感器就是一个参与者。C.与该系统进行通信的其他信息系统。例如为自动柜员机系统建模时，中央银行系统就是它的一个参与者。信用卡系统是销售系统中的一个参与者。只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者。有时，数据的来源和去向，即提供数据的人员不一定会执行系统功能。Eg1.新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者。Eg2.如果学生直接通过Web方式提交个人信息，则认为学生是参与者。主要参与者（primaryactor）是从系统中直接获得可度量价值的用户。次要参与者（secondaryactor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用用例分析的重点是要找到主要参与者。比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？图书管理人员是直接操作者，他们的需求和变化对于用例的影响最大。因此，图书管理员是主要参与者。在UML中，参与者使用小人符号。在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。购买商品识别用例。购买商品用例就是功能性需求。每个用例至少和一个参与者相关，用例名称要体现参与者希望系统提供的功能。相关的参与者应是该功能的执行者或者是该功能的直接交互者。不能混淆用例和用例所包含的步骤。比如“借出图书”功能要经过验证读者信息、检查超出可借数量、保存借书记录、修改图书状态等步骤。在系统中这些步骤通常不作为单独的功能提供给参与者使用，它们只是一个用例所包含的事件流，或者是用例的子功能。当针对整个业务领域建模时，需要使用业务用例。比如图书馆系统有一项重要工作就是“整理书架”，图书都要放回到固定的位置上。信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，即有信息处理的那部分功能。需要使用系统用例。构建用例图。详细、完整地描述需求书写用例规格说明。重构用例模型识别用例间的关系。对用例进行组织和分包。用例举例1：a.客户提出申请要求贷款，申请中包括期限、金额、用途和本人基本情况。银行收到申请后，置于“申请档案”中，以申请号标识。b.某公司内部工作岗位的提供：不论何时，只要一有职位空缺，该地区的人力资源部领导就会通知该地区的所有员工并给其他地区的HR领导发送消息，邀请员工们提出申请。然后，其他地区HR领导将招聘信息贴在公告板上。所有对此感兴趣的员工都可以将申请发送到职位空缺的地区的HR领导那里。用例举例2：在门诊挂号处只能挂当天的号，挂出的号可以退。病人拿到挂号单后，到相应的科室进行就诊。医生根据挂号的顺序号，依次给病人看病开处方。病人拿处方去收款处交费，并拿到发票。病人拿已经收费的处方去药房拿药。图书馆系统的用例图:图书馆系统实行开架阅览，并为读者提供了客户端，读者可以查询到馆藏书目和本人在借的图书。对目前已借出无馆藏的图书可以进行预定，也可以取消预定，这项功能也可以通过互联网实现。图书管理员通过系统记录图书的出借和归还，以及进行书目的维护、读者信息和借书卡的维护。书写用例规格说明用例名称主要参与者/次要参与者简要描述前置条件后置条件主事件流（主要成功场景/基本路径）备选事件流（扩展路径/替代流程/异常事件流）特殊要求/非功能性需求发生频率用例的前置条件和后置条件前置条件（pre-condition）：表述在系统允许用例开始以前，系统应确保为真的条件。这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到系统中。后置条件（guarantee）：或称为成功保证。表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。某些用例可能没有前置条件或后置条件，比如“查询书目”用例可以没有后置条件。用例与场景用例描述的是一组动作序列，在复杂的系统中，用例细节可能存在多种不同的情节，称为变体。比如：购买商品的用例中收款可以是现金支付、信用卡支付或支票支付。针对每一种情况有不同的场景，一个场景就是一个具体的故事现场，重现一个参与者如何具体完成用例。主成功场景：故事的主线，用例通常得到成功执行的典型场景。扩展场景：失败场景，或因为一些特别条件而出现行为分支的步骤（包括失败和成功）。用例与事件流用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。事件流的描述包括：a.用例何时开始和结束.b.用例何时与参与者交互.c.参与者与系统之间有什么对象或信息被交换.d.该行为的主事件流和备选事件流.用例的简要描述用例名：购买商品参与者：出纳员简要描述：顾客带着所要购买的商品来到收款处。收款员记录下商品信息并收款。付款完成后，顾客带着所购买的商品和收据离开。用例描述的双列格式书写用例的准则使用简单的语法，主语明确，语义易于理解。明确指出“谁控制球”，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制。从俯视的角度来编写，指出参与者的动作，以及系统的响应，也就是第三者的角度。显示过程向前推移，也就是每一步都有前进的感受。显示执行者的意图而不是动作，否则不易理解用例的含义。不涉及界面细节，如按下XX按钮、输入xx键等。包含合理的活动集，例如：挂号员提供挂号信息给系统，不用分别写各种信息。使用“确认”、“验证”，而不是“检查是否”，“如果…否则”等，条件分支采用扩展场景。例如：系统确认读者借书资格有效。用例间的关系包含关系：经过封装后可以在各种不同的基本用例中复用的行为称为包含用例。基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。（包含用例是基本用例存在的必要条件。）一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。扩展关系：表达某些可选或只在特定条件下才执行的系统行为的用例，它们是对基本用例的扩展。称为扩展用例。扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。扩展用例的缺失不影响对基本用例的理解。泛化关系：如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例)，子用例继承父用例的所有结构、行为和关系，并含有自己特殊的部分。父用例通常是抽象的，如果两个子用例都对同一父用例进行特殊化，则两个子用例是相互独立而且完整的，这一点与包含关系扩展关系不同。图书馆系统的用例图（具有包含和扩展关系）:课堂练习：用例建模=1\*GB2⑴完成“旅店预定系统”的系统用例图，注意用例的命名和用例间的关系的使用。=2\*GB2⑵选择一个体现系统核心业务功能的用例，完成用例规格说明。“旅店预定系统”初步用户需求:某公司要开发一个旅店预定系统，该旅店可对外开放豪华双人间、双人间、三人间和单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。这些功能均需通过旅店前台与旅客的交互实现。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。用例图：：用例规格说明1：用例名称：预定房间涉及的参与者：酒店前台描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定的同时旅客按规定须提交10%定金。前置条件：前台工作人员必须已经登录到这个系统后置条件：预定信息正确的记录到系统中正常事件流：1)前台人员向系统提供需要预定房间的类型、时间和预定天数。2)系统确认有相应档次的空闲房间，并计算出总费用和定金。3)前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。4)系统记录旅客信息。5)前台人员确认已经交纳定金。6)系统记录房间已经预定，工作完成。备选事件流：2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束5a.顾客没有交纳定金，前台工作人员取消预定，用例结束。用例规格说明2：用例名称：取消预订主要参与者：酒店前台描述：酒店前台利用该用例来取消顾客的预定，如果在指定时间内，则取消时需要返还顾客定金前置条件：用户必须已经预订了某个房间后置条件：系统将取消预定的房间恢复为空闲，并且定金已返还给顾客正常事件流：=1\*GB2⑴前台人员提供给系统顾客信息，比如顾客姓名或证件号码；系统进行检查并返回该顾客的预订信息，包括顾客姓名、证件号码、联系电话、=2\*GB2⑵房间类型、预订时间、预订天数和总费用；--前台人员确认取消该预定；--系统取消该房间预订。备选事件流：2a.系统提示没有该顾客的预定信息4a.当取消预订在6小时之内，系统提示需要退还顾客定金4a1.系统提示返回金额；4a2.前台人员确认已退还定金；4a3.系统记录定金已退还。复习类图，会画反映系统静态结构的类图，会识别对象和对象的关联关系（重点复习聚集关系），类的泛化关系，复习POS系统对象关联的思考题、静态建模的课堂练习。（课件8.6.1节、8.6.3节、8.6.4节、8.6.5节）类图Wirfs-Brock名词短语策略阅读理解需求文档（或用例说明）；反复阅读，筛选出名词或名词短语，建立初始对象清单（候选对象）；将候选对象分成三类，即显而易见的对象、明显无意义的对象和不确定类别的对象；舍弃明显无意义的名词或短语；小组讨论不确定类别的对象，直到将它们都合并或调整到其他两类。不同类别的概念人员：系统需要保存或管理其信息的人员（如录像商店的会员、图书馆的读者），或在系统中中扮演一定角色的人员（如录像商店的职员、图书馆的管理员）。组织：在系统中发挥一定作用的组织机构（如录像商店的连锁店，医疗保险系统中的医院，学校中的系）。物品：需要由系统管理的各种物品（如录像商店的商品、图书），包括无形事物（如学校的一门课程、毕设题目）。设备：在系统中被使用或由系统进行监控的设备、仪器等，系统运行中的硬件设备（如打印机）除外。事件：需要由系统长期记忆的事件（如在自动柜员机上的每次取款事件、每次借书事件）。规格说明：系统中关于对象的规格信息的描述。如图书品种，每种图书有一个唯一的馆藏号，同时该图书还包含一些描述信息，如书号、价格、作者、出版社等，多本图书对象共用这些规格说明。这是一种经过了抽象的概念，应该识别为概念类。业务规则或政策：系统中经常使用的业务规则或政策的文字描述。业务规则通常会在用例文档之外以其他条款说明。如图书馆系统中，对不同违规行为指定不同的罚款金额，商店对不同顾客或产品有不同的折扣策略等。如果这些规则无法并入到其他对象中，则可以作为概念类建立。通常规则可能仅有属性，或者仅有操作，比如折扣策略可能是一个纯粹的计算类。识别对象关联关联表示不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。可以使用关联表示对象了解其他对象的程度。关联名称多数关联是二元的（即只存在于两个类的实例之间），在图中表示为连接两个类符号的实线路径。使用关联名称，应该反映该关系的目的，并且应该是一个动词词组。比如教师对象和课程对象的关联名称就是“讲授”，医生和处方单的关系是“书写处方”。关联名称应放置在关联路径上或其附近。对象在关联中的角色关联所联系的每一端叫做一个角色。角色名称应该是一个名词，能够表达被关联对象在关联中所充当的角色，角色名称紧邻关联线的末端。多重性定义了一个类A的实例在一段特定的时间内能够和多少个类B的实例发生关联。借书记录借书记录*一个读者可以有0个或多个借书记录图书1..*一个图书品种馆藏1本或多本图书处方条目1..6一个处方可以开出1个到6个处方条目足球队员11一个足球队正好由11个队员组成借书记录0..1一本图书可以有0个或1个借书记录导向性角色的导向性特征表示可以通过关联从源类导向到目标类上。也就是说给定关联一端的对象就能够容易并直接地得到另一端的对象。识别关联的导向可以推迟，与设计实现有关。通常是源对象存储了对目标对象的一些引用。整体-部分关联如果对象a是对象b的一个组成部分，则称b为a的整体对象，a为b的部分对象，二者对应的关联形式称为整体-部分关联。这种结构可以用b“has”a进行验证。整体-部分关联是关联中使用较频繁的一种模式，用于对模型元素之间的组装关系进行建模。组成关系在现实生活中可以表现为以下几种形式：--客观上或逻辑上的整体事物和它的组成部分（机器和零件、人体和器官、书和章节、图和元素）--组织机构和它的下级组织及部分（公司和子公司、医院和科室）--团体（组织）和成员（科室和医生、班级和学生）--空间上的容器事物和其包容物（车间和机器/工人、教室和设备）整体/部分关联——聚集聚集（aggregation）是用于为整体-部分关系建模的一种关联，使用连接线和菱形表达，菱形一端的对象是整体对象。整体-部分关联有两种类型：=1\*GB2⑴组合聚集描述整体-部分的关系，部分可能同时属于多个整体对象。关联路径的末端有一个空心菱形，用来表示聚集关系。=2\*GB2⑵共享聚集a.组合聚集具有很强的归属关系，部分只能是一个组合对象的成员，而且部分对象的存在是依赖于整体对象，与整体同生共死。b.整体端的重数不会超过1（即它无法被多个整体对象共享）,关系建立后是不可变更。c.关联路径的末端有一个实心菱形，用来表示组合关系。关联原则找出问题域中的对象远远比找出关联更为重要.注意力集中在那些需要将对象之间的关系信息记忆一段持续时间的关联，对解决问题有关键作用的关联.关联太多不仅不能有效展示概念模型，反而会使概念模型变得混乱.要避免关联之间的信息冗余以及减少派生关联.关联使用关联名称、角色、多重性和导向性来说明.类的泛化关系泛化是在多个概念之间识别共性，定义超类（一般概念）和子类（特定概念）关系的活动。--如在图书馆系统中，发现图书馆目前还收藏了其他资源，比如影碟（VCD/DVD）、音乐CD、电子书等品种。它们和图书一样可以被任何读者借出，每个对象都有条码和状态。但它们也有自己的特性，比如属性项、借阅期限、逾期惩罚不同，必须区别对待。一般-特殊结构如果类A具有类B的全部属性和行为，而且具有自己特有的某些属性或服务，则A叫做B的特殊类，B叫做A的一般类。这种关系也称为一般-特殊关系、泛化-特化关系、继承关系。特点：--可以简化模型，有效地反映问题空间的分类层次。--必须确认子类一定是父类的一个特殊类型，即可以用“is-a-kind-of”进行验证。--注意控制泛化的粒度，额外的泛化增加复杂性。什么时候需要划分一般-特殊结构类的属性或行为不适合该类的全部对象。如果定义“学生”类有“导师”属性，有“教学实践”行为的话，则该类的对象对于本科生不适合，只适合于研究生对象，采用一般-特殊结构重新分类，建立“学生”和“研究生”之间的一般-特殊结构，研究生可以继承所有学生的特性。属性和行为相似的类。将这些类的共性抽象出来作为超类，各自特性仍旧保留而作为超类的子类。抽象类如果一般类A的每个实例还必须是它的一个特殊类的成员，那么类A就被称为一个抽象类。--比如“学生”、“研究生”中，“学生”不是一个抽象类。--比如“支付”、“现金支付”、“信用卡支付”中，“支付”就是一个抽象类。抽象类意味着不能创建该类的实例。在UML中抽象类的类名采用斜体字表示，如“馆藏资源”。多继承继承有单继承和多继承。多继承是指一个子类继承了两个父类的属性和行为。如果某个类从若干个类中进行继承，就必须检查祖先中操作和属性的命名（同名处理）。一般不建议使用多继承，解决方法是采用组装结构来描述。思考题：POS系统“购买商品”用例规格说明参与者：出纳员（主）、顾客目标：完成一次商品销售和支付前置条件：管理员必须已经启动系统，出纳员必须已经登录到这个系统后置条件：销售信息正确的记录到系统中触发条件：顾客带着所要购买的商品来到一个POS机终端主事件流（主成功场景/基本路径）：出纳员将每项商品的信息录入系统商品信息录入完毕后，系统计算商品价格总额出纳员通知顾客商品总额顾客支付现金，出纳员确认收取现金系统计算找零并打印收据，记录交易情况出纳员将收据交给顾客备选事件流：4a.顾客提供信用卡，出纳员将信用卡信息录入系统，系统请求信用卡授权服务机构验证信用卡，最后确认支付并记录支付信息4a1.信用卡支付请求被拒绝，系统要求顾客采用其他方式支付4b.顾客出示证件和支票，出纳员将支票信息录入系统，系统请求支票授权服务机构验证支票，最后确认支付，出纳员记录支票信息4b1.支票支付请求被拒绝，系统要求顾客采用其他方式支付=1\*GB2⑴名词短语策略——POS系统的概念类=1\*GB3①商品信息总是和具体的商品联系在一起，不是一个独立的对象。=2\*GB3②商品价格总额、销售信息表示了整个的交易情况，因此交易情况可由二者导出，可舍弃；同理收据也可由二者导出，可舍弃。=3\*GB3③商品价格总额、销售信息具体归属哪个概念类，结合第二种方法识别。=2\*GB2⑵不同类别的概念——POS系统的概念类=1\*GB3①销售事件为了处理方便，可以拆成“销售项”、“销售项条目”两个概念类，以反映一次销售的总体情况和相应的具体条目.=2\*GB3②销售信息可由“销售项”、“销售项条目”两个概念类导出。=3\*GB3③商品价格总额可以作为支付事件概念类的属性，也不作为独立的对象。=3\*GB2⑶POS系统的概念类=4\*GB2⑷POS系统的对象关联课堂练习：静态结构建模根据下述的描述，画出相应的对象模型：一台微机有一个显示器，一个主机，一个键盘，一个鼠标，汉王笔（可有可无）。主机包括一个机箱，一个主板，一个电源，若干存储器等部件。存储器又分为固定存储器、活动存储器，固定存储器又分为内存和硬盘，活动存储器又分为软盘和光盘。复习顺序图，会画反映系统动态行为的顺序图，复习借书、还书的顺序图、课堂思考题。顺序图参与者参与者实例是一个交互过程（用例）的发起者，通常放置在最左边。对象对象——对象就是类的一个实例，在顺序图中上方以和类相同的图形符号表示，并带有一条叫做“生命线”的垂直虚线。生命线上的矩形条表示对象在特定时间的生存期。UML规定了对象实例的表示方法：生命线生命线（lifeline）说明了对象的生命周期。对象如果被销毁了，其生命线就会中断。激活框激活框（activationbox）表明交互中对象何时起作用，激活框在顺序图中是可选的。消息消息是对象之间的通信，消息传递的同时对应活动随之发生。在顺序图中，消息被表示为从一个对象的生命线到另一个对象的生命线的水平箭头。箭头通过消息名称及消息参数来标记，箭头自上至下的垂直位置来表示时间的先后顺序。消息响应后可能会回送结果，采用反向的虚线和箭头表示，但为了模型的清晰，对显而易见的返回通常不必绘出。控制框架如果用例的备选事件流活动较多，可单独绘制一个顺序图。一个顺序图中也可以描述控制流（UML2.0）：--利用交互框架来标示。--框架可以将顺序图中的某个区域框起，并划分成若干片断。--每个框架有一个操作符。对于循环操作，可以使用loop操作符，条件操作则使用alt操作符。--每个分支片断有一个监护条件，满足该条件才会执行该片断内的事件流。具有复杂控制结构的行为采用活动图会更清晰分支片断借书的顺序图还书的顺序图八、复习一下C语言（三种结构）和Java语言（类的定义）的基本语法。思考题：当按下手机的某个数字键时，数字按钮适配器将会把该数字正确地转换成内部代码，并将代码发给手机的拨号器，拨号器一方面将该代码发送给显示屏进行显示，另一方面驱动手机的发声器发出拨号声音。根据描述识别概念类，并绘制手机拨号的顺序图。第九章-面向对象设计弄清顺序图的消息如何转变为类的方法。将消息转化为类的方法交互图中的消息映射为接受消息的对象类的方法（操作）。消息表达式中的参数和返回值等映射为类方法函数的参数和返回值。同义词释疑：操作是关于行为的定义，方法是行为的实现，服务是行为的对外表现，消息是行为如何协作，它们用于不同的角度、场合、时机和模型中，但可以将它们认为是同义词。两类特殊的方法对象创建方法UML中使用create消息表示对象实例化和初始化。--例如，在C++和Java中，使用new操作符接构造函数的调用方式来实现实例的自动分配和初始化。常在设计类图中忽略相关的方法（如构造函数）。属性存取方法在某些语言中，所有属性都声明为私有的，因此对每一个属性提供存取方法是一个常见的做法。--例如getPrice和setPrice。为了模型的简洁，有时也省略这些方法，但在类图中可以通过属性的可见性来明确它们是否存在。软件体系架构中，经典的三层结构和扩展四层结构，及每层对应的软件类，软件类的职责。经典的三层结构表现层：处理用户和信息系统之间的交互。可以是简单的命令行窗口，也可以功能完善的图形用户界面（胖客户端程序），如基于HTML的浏览器界面（瘦客户端程序）。业务逻辑层：也称为领域层或应用层，是信息系统所有和领域相关的工作。如根据输入数据或已有数据进行计算，依赖于数据访问层获取数据或保存数据，类库形式。数据访问层：一般指与数据库的交互，主要责任是数据库记录的存取。如专门的数据访问类。扩展四层结构表现层：等同于三层中的表现层。控制层/中介层：是表现层和领域层的中介层，也称应用控制器。主要表示业务逻辑中的工作流，一般针对于用例的事件流控制。此外还负责会话状态、数据的合成或分解等事务。领域层：业务逻辑中的领域类的集合，不包含复杂工作流。数据访问/数据映射层：负责将基于对象的领域层数据映射到数据库关系表中的记录。也称为数据持久层，可自行开发或采用持久化框架。根据分层设计软件类边界类根据用例图，每个参与者与一个用例交互，必定导出一个边界类。实体类边界类仅负责数据的输入和输出，不应承担和数据处理有关的业务逻辑。边界类通过与实体类的交互，获得有关数据处理的结果。控制类当用例逻辑较为复杂，并涉及到多个实体类时，可以考虑采用控制类。简化方案：控制类的职责合并给边界类。获取获取验证：图书管理员创建«boundary»

：借书用户界面«control»

：借书控制类«entity»

：读者«entity»

：资源项目«entity»

：借书记录第十章-系统实施系统测试的类型，各类型测试所包含的测试内容。1、模块测试也称单元测试，根据模块的功能说明检验每个单独的模块是否存在错误。模块测试又称单元测试，是针对软件设计的最小单位——程序模块，进行的测试工作。在模块编程后，由编程者执行。模块测试的目的在于发现各模块内部可能存在的各种差错。模块测试需要从程序的内部结构（即白盒法）出发设计测试用例，多个模块可以平行地独立进行单元测试。模块测试方法：驱动模块比如人工吹气测试自行车的气门芯，测试没有问题后再安装。桩模块──存根模块某演员缺席使用替补，彩排继续。2、联合测试也称集成测试，检验模块及系统结构。=1\*GB3①将所有模块集成在一起所进行的系统功能的测试=2\*GB3②集成测试的策略有多种：一次性组装(整体拼装)首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。B.自顶向下的组装--按系统程序结构，沿控制层次自顶向下进行组装。--通过设置下层模块为桩，检查控制流，较早地验证了主要的控制和判断点。--需要制作较多的桩模块，并且桩模块不能返回真实的数据。C.自底向上的组装--从程序模块结构的最底层的模块开始组装和测试。--对于一个给定层次的模块，它的子模块及其下属模块已经组装并测试完成，所以不再需要桩模块。--要到最后才窥得全貌，重大结构问题不能及早发现3、确认测试检验系统说明书的各项功能与性能是否实现，是否满足要求。也可称验收测试。确认测试主要是进行功能的有效性测试。运用黑盒测试的技术，验证被测软件是否满足需求规格说明书列出的需求。目的是使软件符合需求，获得客户的确认，为验收作准备。α测试和β测试、回归测试4、系统测试是对整个信息系统的测试，将硬件、软件、操作人员看作一个整体，检验其是否符合系统说明书。系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试。系统测试为系统的正式运行做准备，也可称为试运行。功能测试、可靠性测试、强度测试（压力测试）、性能测试、恢复测试、启动／停止测试、配置测试、安全性测试、可使用性测试、可支持性测试、安装测试、兼容性测试、容量测试、文档测试。理解两大类系统测试技术，对应于这两大类测试技术又有哪几种具体的测试方法。黑箱测试/黑盒测试这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序模块的详细说明，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。黑箱的穷举测试：用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。测试用例设计——等价类划分等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其他值的测试。等价类的划分有两种不同的情况：有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据