软件工程-理论与实践（精装版）课件 6 分析软件需求、7 软件设计基础

分析软件需求内容分析软件需求概述分析软件需求的任务UML描述方法分析软件需求过程分析和确立软件需求优先级分析和建立软件需求模型软件需求文档化及评审软件需求规格说明书评审软件需求1.1为什么要分析软件需求初步软件需求存在的问题不具体，没有提供软件需求的细节性内容不清晰，对软件需求的描述仍然不够清晰、直观和详实关系不明朗，未深入分析不同软件需求项之间的关系存在潜在缺陷，潜在的需求缺陷难以被发现没有区分不同软件需求，有必要鉴别不同软件需求项的重要性差别，区分不同软件需求的开发优先级示例：初步软件需求这张图说清楚软件需求了吗？1.2分析软件需求的任务基于初步软件需求，进一步精化和分析软件需求，确定软件需求优先级，建立软件需求模型，发现和解决软件需求缺陷，形成高质量的软件需求模型和软件需求规格说明书分析软件需求初步软件需求软件需求规格说明书软件需求模型利益相关方，如用户、客户等需求工程师项目管理者

测试和设计工程师

1.3软件需求的不同视角表示用例视角具有哪些功能、功能间有何关系、功能与利益相关方有何关系UML提供了用例图来分析和描述用例视角的软件需求模型行为视角用例是如何通过业务领域中一组对象以及它们间的交互来达成的UML提供了交互图、状态图来描述行为视角的软件需求模型结构视角业务领域有哪些重要的领域概念以及它们之间具有什么样的关系UML提供了类图来描述和分析业务领域的概念模型功能和行为有何本质性的区别？支持需求建模和分析的UML图视点图（diagram）说明结构

包图（packagediagram）从包层面描述系统的静态结构类图（classdiagram）从类层面描述系统的静态结构对象图（objectdiagram）从对象层面描述系统的静态结构构件图(componentdiagram)描述系统中构件及其依赖关系行为

状态图(statechartdiagram)描述状态的变迁活动图(activitydiagram)描述系统活动的实施通信图(communicationdiagram)描述对象间的消息传递与协作顺序图(sequencediagram)描述对象间的消息传递与协作部署部署图（deploymentdiagram）描述系统中工件在物理运行环境中的部署情况用例用例图（usecasediagram）从外部用户角度描述系统功能1.3.1UML交互图的作用刻画对象间的消息传递，分析如何通过交互协作完成功能用例的功能实现方式软件系统在某种使用场景下对象间的交互协作流程软件系统的某个复杂操作的逻辑实现模型二类交互图顺序图(SequenceDiagram)：强调消息传递的时间序通信图(CommunicationDiagram)：突出对象间的合作表达能力相同，二类图可相互转换顺序图描述对象间的消息交互序列纵向：时间轴，对象及其生命线(虚线)，活跃期(长条矩形)横向：对象间的消息传递顺序图的表示方式对象“[对象名]:[类名]示例：“Tom：Student”或“Student”消息传递对象生命线间的有向边“[*][监护条件][返回值:=]消息名[(参数表)]”“*”为迭代标记表示同一消息对同一类的多个对象发送对象间的消息传递同步消息发送者等待接收者将消息处理完后再继续异步消息发送者在发送完消息后不等待接收方即继续自己的处理自消息一个对象发送给自身的消息返回消息某条消息处理已经完成，处理结果沿返回消息传回创建消息和销毁消息消息传递目标对象的创建和删除消息图元的表示同步消息异步消息带时间延迟的消息注意箭头的图形表示(线条和箭头形状)返回消息示例：顺序图对象生命线活跃期同步消息返回消息自消息消息名称通信图的表示节点表示对象对象间连接称为连接器连接器上可标示一到多条消息消息传递方向用靠近消息小箭头表示消息序号采用多层标号顺序图和通信图的选取原则顺序图和通信图语义上等价没必要针对同一建模目标同时创建这二个图选择原则当需要强调消息传递的时间序时采用顺序图，当需要强调对象间的交互协作关系时采用通信图当刻画场景或用例的动作序列时采用顺序图，当刻画软件内部某项功能的实现构想时，采用通信图在业务分析和需求建模阶段优先考虑顺序图；在设计和实现阶段优先考虑通信图示例：顺序图指出顺序图中各个图形要素及其含义这个图是否有画的不对之处类和对象图©CopyrightXinjunMao17视点图（diagram）说明结构

包图（packagediagram）从包层面描述系统的静态结构类图（classdiagram）从类层面描述系统的静态结构对象图（objectdiagram）从对象层面描述系统的静态结构构件图(componentdiagram)描述系统中构件及其依赖关系行为

状态图(statechartdiagram)描述状态的变迁活动图(activitydiagram)描述系统活动的实施通信图(communicationdiagram)描述对象间的消息传递与协作顺序图(sequencediagram)描述对象间的消息传递与协作部署部署图（deploymentdiagram）描述系统中工件在物理运行环境中的部署情况用例用例图（usecasediagram）从外部用户角度描述系统功能1.3.2类图功效描述系统的类构成，刻画系统的静态组成结构图的构成结点：表示系统中的类（或接口）及其属性和操作边：类之间的关系ClassName1ClassName2类的UML表示©CopyrightXinjunMao19Order<<Constructor>>+Order(id:integer)<<accessor>>+getQuantity():integer<<mutator>>+setQuantity(id:integer)<<businesslogic>>+addOrder(id:integer)+cancelOrder(id:integer)类名称方法参数类型参数名称方法名称-id:integer-quantity:integer=0访问模式属性属性名称属性类型属性值类名属性操作属性的表示[可见性]名称[:类型][多重性][=初值][{约束特性}]可见性公开(+):所有对象均可访问保护(#):所在类及子类对象均可访问私有(-):仅所在类的对象才可访问多重性：属性取值数量,如1，0..1，0..*，1..*，*约束特性可更改性：{readOnly}表示只读，缺省为{changeable}顺序性：{ordered}表示属性取值是有序的，缺省为{unordered}唯一性：{bag}表示属性取值元素允许出现重复元素（缺省）静态性：{static}表示静态属性，属性值由类所有实例对象共享©CopyrightXinjunMao20方法的表示[可见性]名称[(参数表)][:返回类型][{约束特性}]操作的约束特性查询操作：{isQuery=true}表示查询操作，{isQuery=false}表示修改操作，缺省为修改操作。多态性：{isPolymorphic=true}表示本操作允许多态，即可被子类中相同定义形式的操作所覆盖并发性：{concurrency=sequential}任一时刻只有一个对象调用可执行。{concurrency=guarded}并行线程可同时调用多个对象的本操作，但同一时刻只允许一个调用执行。{concurrency=concurrent}并行线程可以同时调用多个对象的本操作且这些调用可并发执行异常：操作在执行过程中可能引发异常接口(Interface)一种不包含操作实现部分的特殊类接口的形式供给接口:对外提供的接口需求接口:需要使用的接口供给接口需求接口类间的关系关联依赖继承实现聚合组合©CopyrightXinjunMao23ClassName1ClassName2类间关系-关联表示类间的逻辑联系多重性：位于关联端的类可以有多少个实例对象与另一端的类的单个实例对象相联系角色名：参与关联的类对象在关联关系中扮演的角色或发挥的作用约束特性：针对参与关联的对象或对象集的逻辑约束类间关系-聚合与组合聚合关系(Aggregation)部分类对象是多个整体类对象的组成示例：一名学生可同时参与多个兴趣小组组合关系(Composition)部分类对象只能位于一个整体类对象中一旦整体类对象消亡，部分类对象也不能苟活组合聚合举例说明组合和聚合的差异性注意箭头图符类间关系-依赖依赖关系有语义上关系且一个类对象变化会导致另一类对象作相应修改依赖形式使用：A类使用B类的某项服务追踪：B类的变化导致A类的变化精化：A类是在B类基础上引进设计、决策等形成实现：A类给出了B类元素的实现派生：A类可通过B类推导或计算出注意箭头图符类间关系-实现表示一个类实现了另一个类中定义的对外接口特殊依赖关系典型应用一个具体类实现一个接口注意箭头图符类间关系-继承子类继承父类所有可继承的特性，且可通过添加新特性或覆盖（override）父类中的原有特性父类抽象多个子类中公共特性，从而避免冗余、简化操作注意箭头图符注意事项用单数名词来描述类名，少用缩写按照方向表示类间关系垂直方向表示继承关系水平方向表示关联、聚合、组合、依赖、实现关系注意画图位置关联名应位于关联边的居中位置多重性、角色名、约束特性等应靠近关联端示例：类图1.3.3对象图功效系统中的对象在运行过程中的瞬时快照结点表示对象，边表示对象间的链接类图在系统的运行过程中某个时刻点上或某一时间段内的实例化样本类图中的一个类在对象图中可表现为多个活跃的对象实例对象图的链接边是类图中关联边的实例化类图中的其他边，如继承、依赖等在对象图中则无从表现对象图是一种静态瞬时快照，归于静态视图范畴对象图示例注意图符表示何时用对象图某些特定的观察点，需要分析系统中的对象情况系统创建之时某些对象消亡之前……通常而言，对象图不常用对象图与类图：区别与联系状态图视点图（diagram）说明结构

包图（packagediagram）从包层面描述系统的静态结构类图（classdiagram）从类层面描述系统的静态结构对象图（objectdiagram）从对象层面描述系统的静态结构构件图(componentdiagram)描述系统中构件及其依赖关系行为状态图(statechartdiagram)描述状态的变迁活动图(activitydiagram)描述系统活动的实施通信图(communicationdiagram)描述对象间的消息传递与协作顺序图(sequencediagram)描述对象间的消息传递与协作部署部署图（deploymentdiagram）描述系统中工件在物理运行环境中的部署情况用例用例图（usecasediagram）从外部用户角度描述系统功能1.3.4状态图功效描述实体（对象、系统）在事件刺激下的反应式动态行为及其导致的状态变化刻画了实体的可能状态、每个状态下可响应事件、响应动作、状态迁移图的构成节点：状态边：迁移，即状态间因事件刺激而触发的状态变化状态图的基本概念状态：对象属性取值构成的一个约束条件不同状态下对象对事件的响应行为完全一样事件：某时刻点发生、需要关注的瞬时刺激或触动消息型事件(同步)：其他对象发来消息信号型事件(异步)：其他对象传来异步信号时间型事件：到达特定时间点条件型事件：对象属性取值满足特定条件动作(action)计算过程，位于迁移边上，简单，执行时间短活动(activity)计算过程，位于状态中，复杂、执行时间长示例：状态图状态：一般、开始、结束迁移：事件、动作、活动复合状态状态s是由子状态s1,…,sn经AND（与）逻辑复合而成是指，对象处于状态s当且仅当对象同时处于s1,…,sn状态s由子状态s1,…,sn经XOR（异或）逻辑复合而成是指，对象处于状态s当且仅当对象处于s1,…,sn中的某个子状态状态的表示由状态名及可选的入口活动、出口活动、do活动、内部迁移构成一旦对象经迁移边从其他状态进入本状态，那么本状态入口活动将被执行一旦对象经迁移边从本状态进入其他状态，那么本状态的出口活动将被执行do活动是当对象进入本状态并执行完入口活动（如果有的话）后应该执行的活动。内部迁移不会引起对象状态的变化，所以它虽有源状态（包含此迁移的状态），但没有目标状态迁移的表示迁移标注为“[事件][监护条件][/动作]”“事件”表示触发此次状态变迁的事件“监护条件”表示约束状态迁移真正发生的条件表达式“动作”表示状态迁移期间应当执行的动作（action）在监护条件和动作中均可引用触发事件参数和对象属性迁移表示为状态节点间的有向边自迁移是指源状态与目标状态相同的特殊外部迁移状态图绘制原则绘图状态节点按行上下对齐，按列左右对齐迁移边绘制成水平线段、垂直线段或者由水平、垂直两种线段组合而成的折线避免斜线初态应位于左上角，终态尽量靠近右下角迁移边上的文本标注应靠近源状态内容分析软件需求概述分析软件需求的任务UML描述方法分析软件需求过程分析和确立软件需求优先级分析和建立软件需求模型软件需求文档化及评审软件需求规格说明书评审软件需求需求分析过程2.1分析和确定软件需求优先级分析软件需求重要性分析软件需求优先级确定用例分析和实现的次序2.1.1分析软件需求重要性从用户和客户的视角，软件需求的重要性是不一样的核心软件需求在解决问题方面起到举足轻重的作用，提供了软件系统所特有的功能和服务，体现了软件系统的特色和优势外围软件需求提供了次要、辅助性的功能和服务示例：“空巢老人看护软件”的需求重要性序号用例名称用例标识重要性1监视老人UC-MonitorElder核心2自主跟随老人UC-FollowElder核心3获取老人信息UC-GetElderInfo核心4检测异常状况UC-CheckEmergency核心5通知异常状况UC-NotifyEmergency核心6控制机器人UC-ControlRobot外围5视频/语音交互UC-A&VInteraction外围6提醒服务UC-AlertService外围9用户登录UC-UserLogin外围10系统设置UC-SetSystem外围2.1.2分析软件需求优先级用户对实现这些软件需求的优先级要求也不一样有些软件需求需要优先实现，尽早交付给用户使用，以发挥其价值；有些软件需求可以滞后实现，晚点交付使用优先级的考虑因素结合软件项目开发的具体约束，考虑不同软件需求的重要性，确定软件需求的实现优先级，确保在整个迭代开发中有计划、有重点地实现软件需求按照软件需求的重要性来确定其优先级按照用户的实际需要来确定软件需求的优先级示例：确定“空巢老人看护软件”的需求优先级用例名称用例标识重要性优先级监视老人UC-MonitorElder核心高获取老人信息UC-GetElderInfo核心高检测异常状况UC-CheckEmergency核心高通知异常状况UC-NotifyEmergency核心高自主跟随老人UC-FollowElder核心高视频/语音交互UC-A&VInteraction外围中控制机器人UC-ControlRobot外围低提醒服务UC-AlertService外围低用户登录UC-UserLogin外围低系统设置UC-SetSystem外围低2.1.3确定用例分析和实现的次序确保有序地开展需求分析、软件设计和实现工作，使得每次迭代开发有其明确的软件需求集，每次迭代开发结束之后可向用户交付他们所急需的软件功能和服务结合软件开发的迭代次数、每次迭代的持续时间、可以投入的人力资源等具体情况充分考虑相关软件需求项的开发工作量和技术难度等因素，确定需求用例分析和实现的先后次序示例：“空巢老人看护软件”需求开发安排用例名称用例标识优先级迭代次序监视老人UC-MonitorElder高

第一次迭代获取老人信息UC-GetElderInfo高检测异常状况UC-CheckEmergency高通知异常状况UC-NotifyEmergency高第二次迭代自主跟随老人UC-FollowElder高视频/语音交互UC-A&VInteraction中第三次迭代控制机器人UC-ControlRobot低提醒服务UC-AlertService低

第四次迭代用户登录UC-UserLogin低系统设置UC-SetSystem低2.2分析和建立软件需求模型的具体步骤分析和确定用例所涉及的对象类分析和确定对象间消息传递绘制用例的交互图确定分析类分析和建立用例交互模型确定分析类职责和属性确定类间关系绘制分析类图分析和建立分析类模型分析和建立状态模型绘制状态图类模型交互模型2.2.1分析和建立用例的交互模型任务分析和描述用例是如何通过一组对象之间的交互来完成的步骤分析和确定用例所涉及的对象及其类分析和确定对象之间的消息传递绘制用例的交互图分析和确定用例所涉及的对象及其类软件需求用例的处理通常涉及三种不同类对象边界类控制类实体类这些类是在用例分析阶段所识别并产生的，通常将它们称为分析类边界类何为边界类每个用例或者由外部执行者触发，或者需要与外部执行者进行某种信息交互，因而用例的业务逻辑处理需要有一个类对象来负责目标软件系统与外部执行者之间的交互由于这些类对象处于系统的边界，需与系统外的执行者进行交互，因而将这些对象所对应的类称之为边界类边界类对象主要起到以下作用交互控制，处理外部执行者的输入数据，或者向外部执行者输出数据外部接口，如果外部执行者表现为其他的系统或者设备，那么边界类对象需要与系统之外的其他系统或设备进行信息交互示例：边界类边界类在顺序图中有何特点？控制类控制类对象作为完成用例任务的主要协调者负责处理边界类对象发来的任务请求，对任务进行适当的分解，并与系统中的其他对象进行协同，以控制他们共同完成用例规定的任务或行为一般而言，控制类并不负责处理具体的任务细节，而是负责分解任务，并通过消息传递将任务分派给其他对象类来完成，协调这些对象之间的信息交互示例：控制类控制类在顺序图中有何特点？实体类用例所对应业务流程中的所有具体功能最终要交由具体的类对象来完成，这些类称之为实体类一般地，实体类对象负责保存目标软件系统中具有持久意义的信息项，对这些信息进行相关的处理（如查询、修改、保存等），并向其他类提供信息访问的服务实体类的职责是要落实目标软件系统中的用例功能，提供相应的业务服务示例：实体类实体类在顺序图中有何特点？2.2.2分析和确定对象之间的消息传递确定消息的名称确定消息传递的信息确定消息的名称消息的名称直接反映了对象间交互的意图，也体现了接收方对象所对应的类需承担的职责和任务，也即发送方对象希望接收方对象提供什么样的功能和服务意图：请求、通知消息名称的表示一般地，消息名称用动名词来表示需求工程师应尽可能用应用领域中通俗易懂的术语来表达消息的名称和参数，以便于用户和需求工程师等能直观地理解对象间的交互语义确定消息传递的信息对象间的交互除了要表达消息名称和交互意图之外，在许多场合还需要提供必要的交互信息这些信息通常以消息参数的形式出现，也即一个对象在向另一个对象发送消息的过程中，需要提供必要的参数，以向目标对象提供相应的信息信息：通知和请求的内容在构建用例的交互图过程中，如果用例的业务流程能够明确相应的交互信息，那么就需要确定消息需附带的信息通常，消息参数用名词或名词短语来表示示例：消息的名称和信息消息的意图和信息是什么？2.2.3绘制用例的交互图绘制顺序图的策略用例的外部执行者应位于图的最左侧，紧邻其右的是用户界面或外部接口的边界类对象，再往右是控制类对象，控制类的右侧应放置实体类对象，它们的右侧是作为外部接口的边界类对象对象间的消息传递采用自上而下的布局方式，以反映消息交互的时序先后一个用例至少构造一个交互图，以刻画用例的行为模型对于较为简单的用例，为其构造一个交互图就足够了对于较复杂的用例而言，需要为此用例绘制多张交互图，每张交互图刻画了用例在某种特定场景下的交互动作序列用例交互图的工作流程外部执行者与边界类对象进行交互以启动用例的执行边界类对象接收外部执行者提供的信息，将信息从外部形式转换为内部形式，并通过消息传递将相关信息发送给控制类对象控制类对象根据业务逻辑处理流程，产生和分解任务，与相关的实体类对象进行交互以请求完成相关的任务，或者向实体类对象提供业务信息，或者请求实体类对象持久保存业务逻辑信息，或者请求获得相关的业务信息实体类对象实施相关的行为后，向控制类对象反馈信息处理结果控制类对象处理接收到的信息，将处理结果通知边界类对象边界类对象对接收到的处理结果信息进行必要的分析，将其从内部形式转换为外部形式，通过界面将处理结果展示给外部执行者示例：顺序图的工作流程顺序图的工作流程有何特点？思考和讨论一个用例用一张顺序图描述够吗？为什么？2.3分析和建立软件需求的分析类模型用例k交互模型1用例k交互模型m软件需求的分析类模型用例1的交互模型1用例1的交互模型n分析和建立分析类模型的步骤确定分析类确定分析类的职责确定分析类的属性确定分析类之间的关系绘制分析类图2.3.1确定分析类

有哪几种分析类？如何确定分析类？用例模型中的外部执行者应该是分析类图中的类在各个用例的顺序图，如果该图中出现了某个对象，那么该对象所对应的类属于分析类，应出现在分析类图中示例：根据用例图来确定分析类有哪些分析类？示例：根据交互图来确定分析类有哪些分析类？2.3.2确定分析类的职责

每一个分析类都有其职责，需提供相关的服务对象接收的消息与其承担的职责之间存在一一对应关系，即如果一个对象能够接收某项消息，它就应当承担与该消息相对应的职责可用类的方法名来表示分析类的职责，并采用简短的自然语言来详细刻画类的职责示例：确定分析类的职责UserLibrary类有何职责？2.3.3确定分析类的属性分析类具有哪些属性取决于该类需要持久保存哪些信息用例顺序图中的每个对象所发送和接收的消息中往往附带有相关的参数，这意味着发送或接收对象所对应的类可能需要保存和处理与消息参数相对应的信息，因而可能需要与此相对应的属性示例：确定分析类的属性UserLibrary类有何属性？2.3.4确定分析类之间的关系

从全局视角理解和描述不同分析类间的关系类之间的关系有多种形式包括继承、关联、聚合和组合、依赖等等具体策略在用例的顺序图中，如果存在从类A对象到类B对象的消息传递，那么意味着类A和B间存在关联、依赖、聚合或组合等关系如果经过上述步骤所得到的若干个类之间存在一般和特殊的关系，那么可对这些分析类进行层次化组织，标识出它们间的继承关系示例：确定分析类之间的关系哪些分析类之间存在怎样的关系？2.3.5绘制分析类图

制出系统的分析类图，建立分析类模型直观描述了系统中的分析类、每个分析类的属性和职责、不同分析类之间的关系如果系列规模较大，分析类的数量多，关系复杂，难以用一张类图来完整和清晰地表示，那么可以分多个子系统来绘制分析类图示例：”空巢老人看护软件”分析类图2.4分析和建立软件需求的状态模型

用UML的状态图来描述这些对象的状态模型，以刻画对象拥有哪些状态、对象的状态如何受事件的影响而发生变化注意二点状态模型是针对对象而言的，而非针对分析类需求工程师无需为所有的类对象建立状态模型，只需针对那些具有复杂状态的对象建立状态模型示例:分析机器人类对象的状态图内容分析软件需求概述分析软件需求的任务UML描述方法分析软件需求过程分析和确立软件需求优先级分析和建立软件需求模型软件需求文档化及评审软件需求规格说明书评审软件需求3.1软件需求文档模板引言1编写目标1.2读者对象3文档概述1.4术语定义5参考文献软件系统概述2.1软件产品概述2.2用户特征2.3设计和实现约束2.4假设与依赖4.非功能性需求5.界面需求6.接口定义7.进度要求8.交付要求9.何种形式来交付10.验收要求

3.功能性需求描述3.1软件功能概述3.2软件需求的用例模型3.3软件需求的分析模型软件需求模型是文档中的重要组成成分3.2撰写软件需求文档的注意事项遵循规范，按照规范来撰写软件需求文档图文并茂，将软件需求模型以及自然语言描述二者结合在一起，给出软件需求的清晰、准确和详实的表述完整表述，要给出软件功能性需求和非功能性需求的描述共同参与，需求工程师要与用户、客户等一起参与软件需求规格说明书的撰写语言简练，软件需求规格说明书的语言表述要简练，便于阅读和理解前后一致，在软件需求文档中，对同一个软件需求的表述前后要一致，不要产生相互矛盾或不一致的需求表达思考和讨论为什么要撰写软件需求文档？没有软件需求文档会产生怎样的情况？3.3分析软件需求的输出软件原型以可运行软件的形式，直观地展示了软件的业务工作流程、操作界面、用户的输入和输出等方面的功能性需求信息软件需求模型以可视化的图形方式，从多个不同的视角，直观地描述了软件的功能性需求，包括用例模型、用例的交互模型、分析类模型、状态模型等软件需求文档以图文并茂的方式，结合需求模型以及需求的自然语言描述，详尽刻画了软件需求，包括功能性和非功能性软件需求，软件需求的优先级列表等3.4软件需求评审的步骤阅读和汇报软件需求制品收集和整理问题讨论和达成一致纳入配置为什么要评审软件需求？评审软件需求（1/2）内容完整性，是否包含了用户和客户的所有软件需求内容正确性，软件需求是否客观、正确地反映了用户和客户的实际期望和要求内容准确性，是否准确地反映了用户和客户的期望和要求内容一致性，所描述的软件需求是否存在不一致问题内容多余性，所描述的软件需求是否都是用户所期望的内容可追踪性，每一项软件需求是否可追踪的评审软件需求（2/2）文档规范性，软件需求规格说明书书写是否遵循文档规范图符规范性，软件需求模型是否正确地使用了UML的图符表述可读性，软件需求文档文字表述是否简洁、可读性好图表一致性，软件需求制品中的图表引用是否正确3.5如何解决软件需求问题（1/2）遗漏的软件需求再次征求用户、客户、领域专家等意见，以补充遗漏的软件需求无源头的软件需求剔除或暂时不用考虑该部分的软件需求，或者将这些软件需求置于低优先级不一致、相冲突的软件需求寻找到具有更高级别的用户或客户，由他们来最终确定软件需求不正确和和不准确的软件需求与用户、客户、领域专家等进行深入的沟通，以正确地理解软件需求的内涵如何解决软件需求问题（2/2）不规范的软件需求文档对照软件需求规范标准和模板，按照其要求来撰写并产生软件需求规格说明书不规范和不正确的软件需求模型学习UML图符和模型的用法，在此基础上绘制出正确和规范的UML模型费解的软件需求文档消除冗余的文字表述，提高语言表达的简洁性，系统梳理和组织软件需求文档的格式，以提高软件需求文档的可读性思考和讨论如果软件需求模型和文档存在诸多的问题，没有得到有效的解决，会产生什么样的后果？小结分析软件是要精化和深化软件需求基于初步软件需求，循序渐进确保软件需求的完整性、一致性和准确性UML提供的、用于描述软件需求的图用例图、交互图、分析类图、状态图分析软件需求的步骤分析和确立软件需求优先级、分析和建立软件需求模型、撰写软件需求规格说明书分析软件需求的输出和评审软件需求模型、软件需求原型、软件需求文档评审软件需求制品©CopyrightXinjunMao94综合实践一任务：分析开源软件的新需求方法借助UML进行需求建模，遵循软件需求规格说明书的标准或模板来撰写开源软件新增软件需求的文档要求建立新增软件需求的用例交互模型、分析类模型和必要的状态模型，按照软件需求规格说明书的规范标准，撰写相应的软件需求文档结果：开源软件新增需求的用例交互图、分析类图、状态图以及软件需求规格说明书综合实践二任务：精化和分析软件需求方法精化和细化软件需求，采用UML的交互图、类图、状态图等，对精化的软件需求进行描述和建模，建立软件需求模型；在此基础上，遵循软件需求规格说明书的模板，撰写软件需求文档；要确保软件需求模型和文档的质量，对最终软件需求制品进行评审要求建立软件需求的用例交互模型、分析类模型和必要的状态模型，按照软件需求规格说明书的规范标准，撰写相应的软件需求文档结果：软件需求的UML模型和软件需求规格说明书问题和讨论软件设计基础内容何为软件设计设计的对象、任务和过程以及产生的设计元素软件设计原则抽象、求精、模块、隐藏、多视点、分离面向对象软件设计方法学基本思想、特点和优势软件设计输出及评审软件设计软件制品、软件设计缺陷及评审要求1.1何为软件设计？软件设计针对软件需求，综合考虑各种制约因素，探究软件实现的解决方案设计前提：软件需求定义了要做什么样的软件设计考虑：制约因素资源：时间、人力、财力、开发辅助工具技术：技术平台，如DBMS还是文件系统软件设计软件需求解决方案制约因素软件设计是要给出软件需求实现的解决方案何为软件系统的解决方案？描述了如何来构造和实现软件系统模块及其功能和接口模块的组织模块之间的交互模块内部的算法人机交互的界面和方式数据结构设计数据库的设计和组织……软件系统的解决方案类似于软件实现图纸设计实现需求设计指导实现不同设计内容不同设计层次不同设计视角从实现的角度，软件设计应该提供什么样的解决方案？示例：“小米便签”的软件实现解决方案整体架构层面的设计从需求到设计和编码需求

设计回答如何做（How）

设计图纸根据需求来进行设计，确保设计的质量设计

实现基于设计来指导施工和实现设计的好坏直接决定了最终产品的好坏！软件设计关注于软件需求的实现问题1.2需求分析、软件设计、软件实现间的关系软件设计软件实现软件设计模型和文档制约因素和质量源程序代码需求分析软件需求模型和文档软件设计处于承上启下的作用软件设计是需求分析和软件实现间的桥梁软件需求软件设计软件代码思考和讨论直接根据软件需求来编写代码行吗？为什么？1.3设计的多样性和差异性：质量用户需求如何区分设计的差异性？如何评价设计的优劣？除了满足需求之外，设计还需要注意哪些要素？设计结果1设计结果2设计结果n软件设计软件设计是一个创作的过程一个软件需求会有多种软件设计方案软件设计的质量要求正确性正确实现所有的软件需求项；设计元素间无逻辑冲突；在技术平台和软件项目的可用资源约束条件下，采用程序设计语言可完整地实现设计模型充分性所有的设计元素已充分细化，模型易于理解，编程人员勿需再面对影响软件功能和质量的技术抉择或权衡优化性以合理的、充分优化的方式实现软件需求模型，目标软件产品能够表现出良好的软件质量属性，尤其是正确性、有效性、可靠性和可修改性简单性模型中的模块的功能或职责尽可能简明易懂，模块间的关系简单直观，模型的结构尽可能自然地反映待解软件问题的结构“好”和“高质量”的软件设计正确可靠可维护可重用可追踪可移植可互操作有效……设计不仅要满足需求，还要有好的质量！要从多个利益相关者的角度来理解设计的“质量”用户、开发者、维护人员等设计要内外兼修内在质量和外在质量思考和讨论“好的”、“高质量”的软件设计应满足什么要求？确保软件设计的质量重要吗？为什么？讨论1.4软件设计的过程1.4.1软件设计的过程–软件体系结构设计从全局和宏观视角、站在最高抽象层次来设计软件系统构成要素及其关系职责分派、接口定义相互交互及协作行为每个模块为“黑盒子”设计关注的质量要素可扩展、可维护、可重用、可移植、可互操作等等要素：函数、方法、类、程序包关系：依赖、交互区别：粒度示例：分层体系结构风格服务业务界面合理地设计抽象层次和组织软构件是关键交互和约束示例：软件体系结构设计软构件及其之间的关系1.4.2软件设计的过程–用户界面设计设计软件对外展示以及与用户进行交互的界面，关注软件如何与用户进行交互输出：告诉给用户的信息输入：需要用户提供的信息设计关注的质量要素直观、友好、易于操作和理解等1.4.3软件设计的过程–软件详细设计对体系结构设计和人机交互设计成果进行细化和精化，获得高质量的、充分细化的软件设计模型数据设计：信息描述

计算机可以处理的数据描述接口设计：构件提供的交互接口类设计：细化各个类设计，包括属性、操作、状态等算法设计：实现特定功能的具体执行流程和算法设计关注的质量要素有效、高效、可靠、易于维护等等示例：类设计publicclassContact{privatestaticHashMap<String,String>sContactCache;privatestaticfinalStringTAG="Contact";privatestaticfinalStringCALLER_ID_SELECTION;publicstaticStringgetContact(Contextcontext,StringphoneNumber)……}给出类层次的设计信息属性方法及其算法等软件设计的过程–其它的工作撰写设计文档基于软件设计及其成果，按照软件设计规格说明书的规范和要求，撰写软件设计文档，详细记录软件设计的具体信息评审软件设计对软件设计制品（包括设计模型和文档）进行评审，验证软件设计是否实现了软件需求，分析软件设计的质量，发现软件设计中存在的缺陷和问题，并与多方人员一起协商加以解决软件设计管理对软件设计变化以及相应的软件设计制品进行有效的管理，包括追踪软件设计变化、分析和评估软件设计变化所产生的影响、对变化后的软件设计制品进行配置管理等等思考和讨论不按照上述过程来进行软件设计行吗？先进行详细设计，再进行体系结构设计会产生什么样的问题？讨论1.5软件设计元素设计类类既是最基本的设计单元，也是最基本的模块单元软构件可分离、可独立部署和执行、可单独重用的一类设计元素如动态链接库（.DLL）、可运行的JavaJAR包、微服务镜像等就属于软构件子系统完成特定功能、逻辑上相互关联的一组模块集合有助于管理软件系统的复杂度，简化软件设计和实现所有的设计元素在编码实现时都有相应的对应物软件设计元素之间的关系示例：软件设计元素体现了哪些设计元素？内容软件设计概述设计元素、任务和过程软件设计原则抽象、求精、模块、隐藏、多视点、分离面向对象软件设计方法学基本思想、特点和优势软件设计输出及评审软件设计软件制品、软件设计缺陷及评审要求2.1软件设计要考虑的因素满足需求正确、一致、可行、完整、无冗余权衡抉择多种设计方案，明确优缺点，综合考虑多方因素关注质量要求应对变化易于理解、扩展、高效如何才能得到高质量的软件设计呢？==》设计原则2.2软件设计基本原则抽象与逐步求精模块化，高内聚度、低耦合度信息隐藏多视点和关注点分离软件重用迭代设计可追踪性2.2.1抽象原则何为抽象?在认识事物、分析和解决问题的过程中，忽略那些与当前研究目标不相关的部分,以便将注意力集中于与当前目标相关的方面不要过早地考虑细节抽象是管理和控制复杂性的基本策略抽象在软件设计中的应用软件开发就是一个从高层抽象到低层抽象逐步过渡过程高层设计

底层设计“逐步求精”软件设计抽象层次的变化体系结构设计抽象类设计抽象算法设计抽象逐步求精结构性全局性关键性过程性局部性细节性软件设计过程中不采用抽象的原则会产生什么样的结果？示例：体系结构层次的设计抽象关注构件的职责和接口外部的功能和服务示例：构件层次的设计抽象考虑构件内部设计元素的职责和协同内部的结构和构成2.2.2模块化、高内聚度和低耦合度原则将软件系统的整体结构分解为一组相关模块模块：包、子系统、构件、类、方法等等每个模块实现单一的功能通过模块之间的交互来组装模块，形成整体框架体现了“分而治之”思想如何达成模块化模块内部强内聚模块之间低耦合模块n模块m不按照模块化的原则来进行软件设计会怎样？高内聚度原则何为模块的内聚度?指该模块内各成分间彼此结合的紧密程度，越高越好，高内聚内聚度分类偶然性内聚:模块内各成分为完成一组功能而结合在一起，关系松散逻辑性内聚:模块完成的诸任务逻辑上相关时间性内聚:模块内诸任务必须在同一时间段内执行过程性内聚:模块内各成分相关且必须按特定次序执行通讯性内聚:模块内各成分对数据结构的同一区域操作顺序性内聚:模块内各成分与同一功能相关且顺序执行功能性内聚:模块内各成分是一整体，完成单个功能低耦合度原则何为模块间的耦合度?模块间的相关程度，越低越好，低耦合耦合度分类非直接耦合:二个模块都不依赖对方而独立存在数据耦合:二个模块通过参数交换信息且仅限于数据控制耦合:二个模块通过参数交换信息包含控制信息特征耦合:介于数据耦合和控制耦合之间外部耦合:二个模块与同一外部环境相关联(文件等)公共耦合:模块间通过全局数据环境相互作用内容耦合:一个模块使用另一模块内的数据和控制信息，或者直接转移到另一模块内执行模块分解与开发成本之间的关系工作量或成本设计模块总数最小成本区域用于接口的开销每个模块的成本2.2.3信息隐藏原则何为信息隐藏?模块应该设计得使其所含的信息对那些不需要这些信息的模块不可访问；模块间仅仅交换那些为完成系统功能所必需交换的信息优点模块的独立性更好支持模块的并行开发（设计和编码）便于测试和维护，减少错误向外传播便于增加新的功能信息隐藏示例模块只提供对外接口，不提供内部实现细节某些方法或属性设计为”private”面向对象方法学如何支持信息隐藏的？2.2.4关注点分离原则何为关注点针对概念、任务和目标的某个部分或者侧面的聚焦关注点：结构、行为等何为关注点分离设计师将若干性质不同的关注点分离开来，以便在适当的时间处理不同的关注点，随后将这些关注点整合起来，形成局部或者全局性的设计结果防止“胡子眉毛一把抓”关注点不分离会产生什么样的后果？2.2.5软件重用原则尽可能地重用已有的软件资产来实现软件系统的功能，同时要确保所开发的软件系统易于为其他软件系统所重用支持软件重用的技术手段封装、接口、继承、多态等软件重用的对象过程和函数、类、软构件、开源软件软件设计模式、软件开发知识为什么软件常用可以提高软件设计的质量？2.2.6软件设计的其它原则设计可追溯到分析模型经常关注待建系统的架构数据设计和功能设计同样重要必须设计接口用户界面设计必须符合最终用户要求设计表述要尽可能易于理解设计应该迭代进行内容软件设计概述设计元素、任务和过程软件设计原则抽象、求精、模块、隐藏、多视点、分离面向对象软件设计方法学基本思想、特点和优势软件设计输出及评审软件设计软件制品、软件设计缺陷及评审要求3.1面向对象软件设计方法学针对面向对象需求分析所得到的软件需求模型（如用例图、交互图、分析类图），对其进行不断精化（而非转换），获得软件系统的各类软件设计元素，如子系统、构件、设计类等，产生不同视角、不同抽象层次的软件设计模型，如软件体系结构图、用例设计交互图、设计类图、活动图等，形成软件系统完整和详尽的设计方案面向对象软件设计方法学面向对象软件设计方法学面向对象软件需求模型面向对象软件设计模型提供了概念和机制来落实软件设计原则，支持高质量的软件设计3.2面向对象软件设计过程软件体系结构设计用户界面设计构件/子系统设计用例设计设计数据设计类设计详细设计面向对象的概念、机制和建模语言示例：面向对象的软件设计表示用包图表示的软件体系结构设计示例：用交互图来表示用户界面设计3.3面向对象软件设计的优势（1/2）高层抽象和自然过渡面向对象概念更加贴近于现实世界，有助于对