软件工程-理论与实践（精装版）课件 8 软件体系结构设计、9 用户界面设计、10 软件详细设计

软件体系结构设计内容何为软件体系结构概念、视图、模型及UML表示软件体系结构风格软件体系结构设计任务、目标、要求和原则体系结构设计过程文档化和评审软件体系结构设计文档模板、验证原则1.1软件体系结构的概念软件体系结构(SoftwareArchitecture，SA)也称软件架构，从高层抽象角度刻画组成软件系统的设计元素及它们之间的逻辑关联MMMMMMMMM软件体系结构如何体现了高层和抽象的特征？这里的设计元素是什么？1.2软件体系结构的设计元素构件(Component)构成体系结构的基本功能部件连接件(Connector)组件之间的连接和交互关系约束(Constraint)组件中的元素应满足的条件以及组件经由连接件组装成更大模块时应满足的条件MMMMMM1.2.1构件何为构件软件系统中的物理模块，具有特定的功能和精确定义的对外接口，外界可通过接口来访问它特点可分离：一个或数个可独立部署执行码文件可替换：构件实例可被其它任何实现了相同接口的另一构件实例所替换可配置：可通过配置机制修改构件配置数据，影响构件对外服务的功能或行为可复用：构件可不经源代码修改，无需重新编译，即可应用于多个软件项目或软件产品示例：构件.dll文件.jar文件构件不是源程序，而是可运行的二进制代码构件是客观物理存在的（即有实际的文件），而非是逻辑存在的构件是可访问的，以获取其功能和服务构件应该是粗粒度的，而非细粒度的示例：软构件Acrobat软件中的软构件构件的UML表示可以用不同的UML图符来表示软构件思考和讨论举例和示范你计算机中安装的软件及其构件对比软构件与源代码、软构件与.class之间的区别和联系为什么要将软件组织为一组构件1.2.2连接子连接子表示软构件之间的连接和交互关系每个软构件并非孤立，它们之间通过连接进行交互交互的目的是为了交换数据、获得服务软构件之间的典型交互方式过程调用、远程过程调用（RemoteProcedureCall，RPC）、消息传递、事件通知和广播、主题订阅等等连接和接口二种接口(Interface)供给接口：对外提供的接口需求接口：请求其他构件帮助所需的接口连接端口(Port)每个端口绑定了一组供给接口和/或需求接口构件通过端口与外部世界交互当外部请求到达端口时，构件的端口知道如何将外部请求路由至合适的接口的实现体当构件通过端口请求外部服务时，端口也知道如何分辨该请求所对应的需求接口构件通过接口对外提供服务构件通过接口与其他构件进行交互构件与接口构件的实现与构件的接口相分离构件开发者可自由选择实现方法，只要它实现供给接口中的操作及属性两个构件的实现遵循相同接口定义，它们就可自由替换示例：构件之间的连接和交互节点A节点B节点C订阅者发布者话题/消息订阅者发布者话题/消息客户端服务请求服务端服务响应连接和接口的表示对外提供的接口访问其他构件的接口思考和讨论如果一个软构件没有对外的接口是否可以？没有接口的软构件会带来什么问题？1.2.3约束高层次软件元素可向低层次软件元素发请求，低层次软件元素完成计算后向高层次发送应答，反之不行每个软件元素根据其职责位于适当的层次，不可错置，如核心层不能包含界面输入接收职责每个层次都是可替换的，一个层次可以被实现了同样的对外服务接口的层次所替代1.3软件体系结构的不同视图逻辑视图：要素及关系，站在结构视点和抽象层次运行视图：在特定时刻软构件的具体情况开发视图：构件的代码组织及其形式物理视图：软构件的部署及其连接软件体系结构是从结构的角度来刻画软件可从不同角度、层次来表示和分析软件体系结构1.3.1软件体系结构的逻辑视图：包图包模型刻画包间的构成和依赖关系包可以包含一组具有逻辑关联的UML模型元素包间关系：构成关系、依赖关系包图可描述软件系统的高层结构包图以结构化、层次化方式组织、管理大型的软件模型，使得分别处理不同包的开发团队之间的相互干扰程度降至最低包图：系统（子系统）、构件及关系示例：软件体系结构的包图表示包图表示软件体系结构1.3.2软件体系结构的逻辑视图：构件图描述软件系统中构件及构件间的关系结点：构件、类和包关系：构成关系、依赖关系对软件体系结构的描述描述软件系统中构件的接口定义及构件间的依赖关系，以便评估软件变更的影响范围描述软件系统或其中某个局部的构件化设计，为在后续开发阶段实现构件化的软件模块订立设计规约示例：软件体系结构的构件图表示“Customer”的内部体系结构构件接口和端口关系(依赖)1.3.3软件体系结构的开发视图各软件要素源代码的程序分包及目录结构采用的类库、中间件和框架，它们与逻辑视图中各个软件元素之间的映射关系小米便签的代码开发视图1.3.4软件体系结构的部署视图部署图软件安装部署的物理机器及其连接，各个件元素在这些机器上的部署位置表示软件系统可执行工件在运行环境中的分布情况工件(Artifact)工件：软件系统中相对独立的物理实现单元示例：Windows平台下DLL文件、Java系统中类库（jar）文件两种部署图逻辑层面的描述性部署图物理层面的实例性部署图示例：描述性部署图构件通信计算节点工件1.3.5软件体系结构的运行视图软件运行时进程、线程的划分，它们之间的并发和同步，它们与逻辑视图和开发视图之间的映射关系可用UML的活动图、对象图来表示1.4描述软件体系结构的三类UML图包图构件图部署图1.4.1包图©CopyrightXinjunMao27视点图（diagram）说明结构

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

状态图(statechartdiagram)描述状态的变迁活动图(activitydiagram)描述系统活动的实施通信图(communicationdiagram)描述对象间的消息传递与协作顺序图(sequencediagram)描述对象间的消息传递与协作部署部署图（deploymentdiagram）描述系统中工件在物理运行环境中的部署情况用例用例图（usecasediagram）从外部用户角度描述系统功能包图功效刻画包间的构成和依赖关系图的构成节点：包边：包间的关系包间的关系组成和依赖何为包？一组具有逻辑关联的UML模型元素（例如用例、类等）、模型图（用例图、类图、交互图、状态图、活动图等），以及其他的包包在模型管理过程中是配置管理的基本单元，同时也为访问控制提供基本手段Name包的作用作为软件模型的组织单元将大型软件系统划分成不同包，以构建各类模型作为模型管理的基本单元以包为单位分派开发任务安排计划，包是天然的基本处理单元作为系统高层结构中的组成元素。逐级细分的包才是软件高层结构中恰当的组成元素作为访问控制的基本手段将包视为名字空间，每个模型元素可通过在其名称之前拼接包名，构成全系统范围内的唯一限定名来指称它，正如在文件系统中以文件的全路径名来唯一地指称一个文件示例：包图1.4.2构件图视点图（diagram）说明结构

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

状态图(statechartdiagram)描述状态的变迁活动图(activitydiagram)描述系统活动的实施通信图(communicationdiagram)描述对象间的消息传递与协作顺序图(sequencediagram)描述对象间的消息传递与协作部署部署图（deploymentdiagram）描述系统中工件在物理运行环境中的部署情况用例用例图（usecasediagram）从外部用户角度描述系统功能构件图功效描述软件系统中构件及构件间的构成和依赖关系图的构成节点：构件，具有对外接口、可分离和独立功能物理模块边：构件间的依赖关系构件及其接口构件一个或者多个可独立部署的执行码文件具有精确定义的供给接口和需求接口可分离，接口和实现分离可替换，构件实例可被任何实现相同接口的同一构件实例所替换接口一组操作和/或属性的说明（不含操作的实现），它用作服务提供方和使用方之间的协议每个构件还可以定义一些端口（port），每个端口绑定了一组供给接口和/或需求接口接口由类或构件实现©CopyrightXinjunMao34构件和接口的表示构件的三种图元构件及其接口的两种表示方法示例：构件图©CopyrightXinjunMao36示例：构件图1.4.3部署图视点图（diagram）说明结构

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

状态图(statechartdiagram)描述状态的变迁活动图(activitydiagram)描述系统活动的实施通信图(communicationdiagram)描述对象间的消息传递与协作顺序图(sequencediagram)描述对象间的消息传递与协作部署部署图（deploymentdiagram）描述系统中工件在物理运行环境中的部署情况用例用例图（usecasediagram）从外部用户角度描述系统功能部署图功效表示软件系统可执行工件(artifact)在运行环境中的部署和分布情况工件是指软件中相对独立的物理实现单元，如动态链接库（DLL）文件、Java类库（jar）文件图的构成节点：计算节点、工件、构件边：通信和依赖两种部署图逻辑层面的描述性部署图描述软件的逻辑布局物理层面的实例性部署图针对具体运行环境和特定的系统配置描述软件系统的物理部署情况©CopyrightXinjunMao39描述性部署图的节点节点表示软件运行环境中的一组计算资源（如Web服务器、应用服务器、数据库服务器等），软件工件驻留于其中，并依赖其提供的基础服务工件以构造型<<artifact>>标识，工件位于节点图元之内构件位于节点之内的构件表示该构件部署于相应节点，位于节点之外的构件主要用来指明工件与构件之间的依赖关系与用例有关的执行者在部署图中引入执行者意在强调执行者与部署于节点中的工件之间的使用关系及信息交互描述性部署图的边节点之间的通信关联表示两个节点间的通信连接工件之间的依赖关系如果工件定义了对外接口，那么应确保工件间的依赖关系表现为工件接口上的依赖关系，如此可降低工件之间的耦合度工件与构件之间的依赖关系表示工件具体实现了构件用例执行者与工件之间的依赖关系表示执行者使用工件提供的服务或工件使用执行者提供的服务示例：描述性部署图实例性部署图实例性部署图与描述性部署图之间的关系可类比为对象图与类图之间的关系实例性部署图中节点的命名方式为“节点名:类型名”，其中类型名为描述性部署图中的节点名部署图的建模原则节点按行上下对齐，按列左右对齐，边绘制成水平线段、垂直线段或者由水平、垂直两种线段组合而成的折线，避免斜线工件和构件的放置应尽量使依赖关系的方向从左至右供给接口位于构件的左侧，需求接口位于构件的右侧示例：实例性部署图1.5软件设计模式借用以往的经验来解决问题以设计重用为目的，采用一种良定义的、正规的、一致的方式记录的软件设计经验关注在一般或特定设计环境中可能重复出现的设计问题，并给出经过充分实践考验的软件解决方案名称问题施用和约束条件解决方案效果不同抽象层次的设计模式体系结构风格面向整个软件系统构件设计模式面向子系统或者构件实现设计模式针对子系统或构件中的某个特定问题整体、全局局部细节体系结构设计风格面向整个软件系统，在抽象层次给出软件体系结构的结构化组织方式提供一些预定义的子系统或者构件，规定其职责，明确它们之间的相互关系、协作方式的规则或指南针对不同的问题采用不同的体系结构模式常用软件体系结构风格分层风格管道与过滤器风格黑板风格MVC风格SOA风格总线风格……1.5.1分层体系结构模式模式思想将软件系统按照抽象级别逐次递增或递减的顺序，组织为若干层次，每层由一些抽象级别相同构件组成典型层次示例顶层：直接面向用户提供软件系统的交互界面底层：则负责提供基础性、公共性的技术服务，它比较接近于硬件计算环境、操作系统或数据库管理系统中间层：介乎二者之间，负责具体的业务处理何为抽象级别？示例：分层体系结构风格服务业务界面合理地设计抽象层次和组织软构件是关键交互和约束分层体系结构模式的约束层次间的关系每层为其紧邻上层提供服务，使用紧邻下层所提供的服务上层向下层发出服务请求，下层为上层反馈服务结果下层向上层提供事件信息，上层对下层通知做出处理服务接口的组织方式层次中的每个构件分别公开其服务接口每个层次统一对外提供整合的服务接口分层体系结构模式的特点松耦合减低整个软件系统的耦合度可替换一个层次可以有多个实现实例可复用层次和整个系统可重用标准化支持体系结构及其层次、接口的标准化1.5.2管道与过滤器风格构件将软件功能实现为一系列处理步骤，每个步骤封装在一个过滤器构件中连接子相邻过滤器间以管道连接，一个过滤器的输出数据借助管道流向后续过滤器，作为其输入数据数据软件系统的输入由数据源（datasource）提供软件最终输出由源自某个过滤器的管道流向数据汇（datasink）典型数据源和数据汇包括数据库、文件、其他软件系统、物理设备等管道与过滤器模式的示例管道与过滤器风格的约束过滤器与管道之间的协作方式过滤器以循环的方式不断地从管道提取输入数据，并将其输出数据压入管道，称为主动过滤器管道将输入数据压入到位于其目标端过滤器，过滤器被动地等待数据，称为被动过滤器管道负责提取位于其源端过滤器的输出数据设计考虑如果管道连接的两端均为主动过滤器，那么管道必须负责它们之间的同步，典型的同步方法是先进先出缓冲器如果管道的一端为主动过滤器，另一端为被动过滤器，那么管道的数据流转功能可通过前者直接调用后者来实现示例：管道与过滤器风格词法分析语法分析生成中间码代码优化源代码词法分析结果语法分析结果中间码可执行代码编译器采用的就是一个典型的管道/过滤器风格管道与过滤器模式的特点自然地解决具有数据流特征的软件需求可独立地更新、升级过滤器来实现软件系统的扩展和进化1.5.3黑板风格将软件系统划分为黑板、知识源和控制器三类构件黑板：负责保存问题求解过程中的状态数据，并提供这些数据的读写服务知识源：负责根据黑板中存储的问题求解状态评价其自身的可应用性，进行部分问题求解工作，并将此工作的结果数据写入黑板控制器：负责监视黑板中不断更新的状态数据，安排（多个）知识源的活动。黑板风格示意图黑板风格的约束控制构件通过观察黑板中的状态数据来决定哪些知识源对后续的问题求解可能有所贡献，然后调用这些知识源的评价功能以选取参与下一步求解活动的知识源被选中的知识源基于黑板中的状态数据将问题求解工作向前推进，并根据结果更新黑板中的状态数据控制构件不断重复上述控制过程，及至问题求解获得满意的结果黑板风格的特点可灵活升级和更换知识源和控制构件知识源的独立性和可重用性好知识源之间没有交互软件系统具有较好的容错性和健壮性知识源的问题求解动作是探索性的，允许失败和纠错1.5.4MVC风格模型构件负责存储业务数据并提供业务逻辑处理功能视图构件负责向用户呈现模型中的数据控制器在接获模型的业务逻辑处理结果后，负责选择适当的视图作为软件系统对用户的界面动作的响应MVC体系结构示意图MVC风格的约束创建视图，视图对象从模型中获取数据并呈现用户界面视图接受界面动作，将其转换为内部事件传递给控制器所有视图在接获来自模型的业务数据变化通知后向模型查询新的数据，并据此更新视图控制器将用户界面事件转换为业务逻辑处理功能的调用控制器根据模型的处理结果创建新的视图、选择其他视图或维持原有视图模型进行业务逻辑处理，将处理结果回送给控制器，必要时还需将业务数据变化事件通知给所有视图1.5.5SOA风格将软件系统的软构件抽象为一个个的服务（Service），每个服务封装了特定的功能并提供了对外可访问的接口任何一个服务既可以充当服务的提供方，接受其他服务的访问请求；也可充当服务的请求方，请求其他服务为其提供功能任何服务需要向服务注册中心进行注册登记，描述其可提供的服务以及访问方式，才可对外提供服务SOA软件体系结构风格示意图服务注册中心服务请求方服务提供方注册和发布服务查询服务访问和获得服务SOA风格的特点将服务提供方和服务请求方独立开来，因而支持服务间的松耦合定义允许任何一个服务在运行过程中所扮演角色的动态调整，支持服务集合在运行过程中的动态变化，因而具有非常强的灵活性提供了诸如UDDI、SOAP、WSDL等协议来支持服务的注册、描述和绑定等，因而可有效支持异构服务间的交互1.5.6消息总线风格包含了一组软构件和一条称为“消息总线”的连接件来连接各个软构件消息总线成为软构件之间的通信桥梁，实现各个软构件之间的消息发送、接收、转发、处理等功能每一个软构件通过接入总线，实现消息的发送和接收功能消息总线风格示意图消息总线软构件软构件软构件软构件软构件讨论：实践项目的软件体系结构基于上述软件体系结构模式，思考你的实践项目应该采用什么样的软件体系结构模式？为什么？内容何为软件体系结构概念、视图、模型及UML表示软件体系结构风格软件体系结构设计任务、目标、要求和原则体系结构设计过程文档化和评审软件体系结构设计文档模板、验证原则2.1软件体系结构设计的任务建立满足软件需求的软件体系结构明确定义各子系统、构件、关键类的职责划分及协作关系明确它们在物理运行环境下的部署特点针对软件系统全局性、基础性技术问题给出技术解决方案宏观、全局、层次、战略、多视点、关键性软件体系结构设计示意图软件体系结构设计功能性需求质量需求开发约束需求软件体系结构风格遗留软件和可重用软件资源软件体系结构模型2.2软件体系结构设计的目标满足软件需求实现软件需求……追求高质量可扩展可伸缩易维护…….软件体系结构设计软件需求软件体系结构模型制约因素满足高质量非功能需求在体系结构设计中起着非常重要的作用软件体系结构设计vs软件需求体系结构是以软件需求实现为目标的软件设计蓝图软件需求是体系结构设计的基础和驱动因素软件需求，尤其是非功能需求，对软件体系结构具有关键性的塑形作用软件体系结构设计软件需求软件体系结构模型制约因素软件体系结构设计vs详细设计体系结构设计为详细设计提供可操作指导详细设计是对体系结构设计中设计要素的局部设计详细设计须遵循体系结构设计：如接口和约束详细设计只能实现、不能更改体系结构设计中规定模块的接口和行为体系结构设计人机界面设计详细设计整合与验证迭代设计、反复精化、持续优化基于体系结构设计的结果来指导详细设计软件体系结构设计的重要性和关键性承上启下软件需求—详细设计，后续的详细设计和软件实现的主要工作基础影响深远对性能、灵活性、可修改性、可扩充性等质量需求的影响是决定性的，软件质量的瓶颈定型质量对软件质量的全局性、决定性影响思考和讨论对比建筑物的体系结构设计，如果软件体系结构设计的不好，会产生什么样的问题？CTI软件开发的实际经历2.3软件体系结构设计的过程软件体系结构设计的原则高层抽象和组织模块化信息隐藏软件重用多视点分离遵循这些设计原则有助于得到高质量的软件体系结构2.3.1设计初步的软件体系结构任务基于功能性和非功能性软件需求，参考业界已有的软件体系结构设计风格，设计出目标软件系统的初始体系结构，明确每个构件的职责以及构件间的通信和协作关系输出：初步的软件体系结构针对软件需求，寻求体系结构风格，给出初步和粗糙的顶层架构，以供后续设计阶段的精化和细化无需关注架构中各个子系统或构件内部的实现细节用UML中的包图对所设计的顶层架构进行直观的表示初始体系结构设计的方法初创体系结构设计关键软件需求体系结构模式一个或者多个初始体系结构模式软件开发经验辨识关键软件需求确定最能体现待开发软件特色的核心功能需求通常是杀手功能，独有的功能确定核心或基础性功能其他功能依赖于这些功能或仅当这些功能实现后其他功能才有意义确定为实现对外接口所必需的支持功能对外接口的实现依赖于这些功能需求项的实现标识实现难度较大、实现风险较高的功能高难度、高风险功能的设计，及其可操作的风险化解策略确定对用户满意度影响大的功能需求直接影响用户对软件系统的评价剔除对体系结构塑形无贡献的功能需求项抛弃不重要的软件需求根据关键需求选择合适体系结构风格积累体系结构风格清单人们总结出了几十种软件体系结构风格对风格进行分门别类便于快速找到适合于关键需求的风格要熟悉每种风格的特点和应用场所各种风格适合解决的问题和需求针对关键需求对比多种风格正面效果是否适合、负面效果是否可容忍、是否与关键需求相冲突不同体系结构风格适合的应用类别特点典型应用管道/过滤器风格数据驱动的分级处理，处理流程可灵活重组，过滤器可重用数据驱动的事务处理软件，如编译器、Web服务请求等层次风格分层抽象、层次间耦合度低、层次的功能可重用和可替换绝大部分的应用软件MVC风格模型、处理和显示的职责明确，构件间的关系局部化，各个软构件可重用单机软件系统，Web应用软件系统SOA风格以服务作为基本的构件，支持异构构件之间的互操作，服务的灵活重用和组装部署和运行在云平台上的软件系统消息总线风格提供统一的消息总线，支持异构构件之间的消息传递和处理异构构件之间消息通信密集型的软件系统示例：初步软件体系结构的设计(1)“空巢老人看护软件”的关键软件需求监视老人、自主跟随老人、获取老人信息、检测异常状况、通知异常状况、控制机器人、视频/语音交互、提醒服务等八项功能性需求为核心软件需求。其他二项软件需求为非关键软件需求。分析不同质量需求对软件系统的竞争力带来的影响和挑战，可将性能、易用性、安全性、私密性、可靠性、可扩展性等质量需求作为关键需求“空巢老人看护软件”需要采用分布式的运行和部署形式，前端软件制品部署在Android手机上，后端软件制品要支持多种机器人的运行，以方便老人家属和医生的灵活和便捷使用。该开发约束将作为关键软件需求来指导软件体系结构的设计。示例：初步软件体系结构的设计(2)“空巢老人看护软件”初步软件体系结构设计

2.3.2重用开源软件及已有软件资产搜索已有的粗粒度软件资产可重用的软件开发包，如函数库、类库、构件库等互联网上的云服务，为特定问题提供独立功能，如身份验证、图像识别、语音分析等等遗留软件系统，已存在的软件系统开源软件，提供针对特定功能的完整程序代码寻找可用于支持目标软件系统构建的软件制品实现软件架构中某个（些）子系统或构件的功能将软件资产集成到体系结构设计中可直接使用的软件资产清晰地定义它们与当前软件系统间的交互接口包括数据交换的格式、互操作协议等不可直接使用但具复用潜力的设计资产采用接口重构、适配器等方法将其引入到当前体系结构中接口重构是指，调整当前体系结构中面向可复用设计资产的调用接口，使之与其提供的服务接口相匹配到哪里找开源软件？Github(/)开源软件托管平台和开源社区，180万商业组织，2700万开发者，8000万个版本库SourceForge(/）开源软件仓库和开发平台，370万用户，43万项目Gitee(/)

中国人的开源社区......示例：搜寻和重用软件资产(1)软件系统需要实现“视频/语音双向交互”的功能访问GitHub，在搜索框输入“Linphone”点击进入“Linphone”查看开源软件项目下载和获取“Linphone”开源代码示例：搜寻和重用软件资产(2)机器人的自主跟随功能搜寻和重用ROS代码“turtlebot_follower”来实现在Github搜索“turtlebotapp”点击“turtlebot_follower”，阅读和下载其开源代码示例：搜寻和重用软件资产(3)搜寻和重用“离线语音合成”软件包OLVTI-SDK实现文字到语音转换讯飞开放平台（/）提供“离线语音转换和合成”功能平台提供软件开发包SDK示例：“空巢老人看护软件”的开源软件重用思考和讨论为什么软件体系结构设计时要考虑重用粗粒度软件资产？如果在此过程中没有考虑软件重用，会带来什么样问题？软件体系结构设计阶段的软件重用有何特点？2.3.3精化软件体系结构选择软件体系结构所依赖的公共基础设施确定其中的基础性服务，从而为目标软件系统的运行提供基础性的技术支撑，如操作系统、软件中间件、数据库管理系统、软件开发框架、安全服务等确定软件体系结构中的设计元素包括子系统、软构件和关键设计类等，明确其职责和接口，从而为开展详细设计奠定基础确定公共基础设施及服务软件体系结构中的各个要素（如软构件、子系统等）都需要依赖于特定的基础设施来运行从最底层的操作系统，到稍高层次的软件中间件、软件开发框架等等，或者表现为诸如数据库管理系统、消息中间件等形式为目标软件系统的运行提供基础性的技术支持，而且还为目标软件系统的构造提供可重用的基础服务设计其所需的基础服务结合软件需求以及基础设施提供的功能及接口，开展基础服务的设计如数据持久服务、隐私保护服务、安全控制服务、消息通讯服务等等基础服务应具有良好的稳定性，即使软件需求发生了变化，基础服务仍可为其提供服务示例：“空巢老人看护软件”的基础设施确立设计元素基于初步软件体系结构，以实现软件需求为目标，精化和确立设计元素，明确设计元素的职责划分及相互间的协同设计元素三类：子系统、构件和类设计元素的接口及相互间的协作子系统构件类（1）确定子系统及其接口遵循问题分解和系统组织思想，将分析类按相关性原则加以组织和归类，形成软件系统的若干子系统用例相关性原则：将用例按业务相关性或相似性进行分组，每组用例组成一个子系统，参与这些用例的实现的分析类均成为此子系统的“设计类”实现途径相关性原则：分析用例的交互图，将具有相关或相似业务处理职责的控制类归为一个子系统；或将所有这些控制类的职责归并后按某种业务上的相关性或相似性进行分组，每组职责归为一个子系统实体类相关性：从便于管理和控制的角度，将分析模型中的实体类进行分组，每组对应于一个子系统，由子系统对所属的实体类加以管理评估和改进所确立的子系统每个子系统有明确、独立的职责不同子系统间的职责是正交的，不应具有相同或相似职责所有子系统职责覆盖软件系统所有职责避免特别庞大或特别细小的子系统子系统接口极小化，仅公开为外界使用该子系统所必需的接口函数，尽可能隐藏内部实现细节确定子系统的接口每个子系统需要提供二类接口与外界进行交互服务提供接口：支持外部设计元素访问子系统服务请求接口：支持子系统访问外部设计元素以完成子系统职责一个子系统可根据业务处理的需要，定义一个或者多个服务提供接口和服务请求接口示例：

确定“空巢老人智能看护系统”子系统子系统OlderMonitoringRobotBiCallUserReminder……（2）

确定构件及其接口将一些分析类的相似或相关职责封装为一个构件，通过接口向软件系统的其他部分提供功能和服务构件的内聚度应该高于子系统构件的设计应该追求可复用性目标构件的规模小于子系统子系统中可以包含构件，但构件中不会包含子系统（3）确定关键设计类及其接口关键设计类对于软件需求的实现具有比较重要的作用，但未归入子系统和构件的某项职责与子系统或构件交互，或者作为软件体系结构中已有的设计元素之间的交互“桥梁”，缺少这种交互将导致体系结构无法完整地实现某项重要的软件需求所谓关键是指重要、不可或缺2.3.4设计部署模型设计软件系统的物理部署模型刻画软件系统的各个子系统、软构件如何部署到计算节点上运行的，描述它们的部署和运行环境《Artifact》ElderCarerApp智能手机《OS》AndroidPC机《Artifact》RobotControl《Framework》ROS《Component》DataService《DBMS》MySQL《OS》UbuntuTurtlebot2Robot思考和讨论子系统和构件都提供了接口，可对外提供服务和功能，那么二者有何区别和联系？在什么情况下应该设计为子系统，在什么情况下应该设计为软构件？2.4整合体系结构设计整合和组织体系结构设计产生的设计结果包括引入的开源软件和软件资产、顶层软件架构、确定的各类设计元素等等整合的目的理清设计元素间的关系，明确它们之间的交互和协作确保所产生的软件设计模型具有更好的模块性、封装性、可重用性等特征最终获得目标软件系统体系结构的完整逻辑视图整合体系结构设计整合外部系统对应的子系统与分析模型中负责与外部系统交互的边界类子系统是服务提供方，边界类是服务请求方整合引入的开源软件或者软件资产必要时引入相关的接口以实现开源软件或者软件资产与设计元素之间的交互，从而它们与软件系统的设计融合整合外部系统与目标软件系统中的设计类进一步清晰地定义相关的接口，支持它们之间的协作优化体系结构设计分解一些规模较大的子系统合并若干职责相同或相似的设计元素以软件重用为目的适当的调整设计元素所封装的功能、承担的职责和对外提供的接口用简洁的软件元素，以尽可能高效、合理的方式实现所有软件需求将不同设计元素中的公共职责提取成为服务构件或服务类整合体系结构设计的结果设计元素的职责划分更为明确系统与外部接口、相关设计元素间的接口和协作更为清晰整体体系结构设计方案更为优化内容何为软件体系结构概念、视图、模型及UML表示软件体系结构风格软件体系结构设计任务、目标、要求和原则体系结构设计过程文档化和评审软件体系结构设计文档模板、验证原则撰写软件体系结构设计文档文档概述系统概述设计目标和原则设计约束和现实限制逻辑视点的体系结构设计部署视点的体系结构设计开发视点的体系结构设计运行视点的体系结构设计评审软件体系结构设计满足性体系结构是否能够满足软件需求，体系结构怎样满足软件需求优化性体系结构是否以充分优化方式实现所有软件需求项可扩展性是否易于扩展，以应对软件需求的变化可追踪性软件体系结构中的所有设计元素是否有相对应的软件需求项详尽程度体系结构的详略程度是否恰当软件体系结构设计的输出软件模型用UML包图、部署图等描述的软件体系结构模型软件文档体系结构设计规格说明书文档小结软件体系结构设计的特殊性具有宏观、全局、层次、战略、多视点、关键性等特点逻辑视点、物理视点等，可用包图、部署图来表示软件体系结构设计的重要性针对软件系统全局性、基础性技术问题给出技术解决方案软件体系结构的风格管道、层次、MVC、黑板等等，针对不同软件需求及特点软件体系结构设计的过程、策略和成果考虑软件关键需求、利用已有软件资产、关注软件质量软件体系结构的设计模型和文档综合实践一任务：开源软件的体系结构设计方法针对开源软件新增加的软件需求，考虑软件体系结构风格，搜寻可用的软件资源（包括开源软件），扩展和优化原有的软件体系结构，引入新的设计元素或者重新设计软件体系结构要求针对开源软件及其新构思的软件需求，在原有软件体系结构的基础上，调整、优化或重新设计开源软件的体系结构结果：软件体系结构模型（至少包括逻辑视点和物理视点的体系结构模型），软件体系结构设计文档综合实践二任务：软件体系结构设计方法针对关键软件需求，考虑软件体系结构风格，搜寻可用的软件资源（包括开源软件），设计初步的软件体系结构；对软件体系结构进行精化设计，进一步确定其软构件、子系统和设计类等设计元素，以满足所有软件需求；给出软件体系结构的部署模型要求针对构思的软件需求，开展软件体系结构设计，产生软件体系结构设计模型结果：软件体系结构模型（至少包括逻辑视点和物理视点的体系结构模型），软件体系结构设计文档思考和讨论软件体系结构设计的最大挑战是什么？如何分析和评价软件体系结构设计的质量？问题和讨论用户界面设计内容用户界面基础人机交互方式用户界面的组成元素及UML表示用户界面设计任务、过程和原则具体的设计步骤及方法用户界面输出及评审用户界面的输出用户界面的评审计算机软件与外界的二种不同交互方式用户软件接口软件人机交互通过软件接口与其他的软件系统进行交互通过人机交互与软件用户进行输入和输出其它软件接口访问用户界面设计元素1.1人机交互的常见方式文本通过文本方式进行输入和输出，如DOS、Linux下的文本命令，特点：须记忆命令、不友好图形化界面通过图形化界面进行输入和输出，如窗口、按钮、对话框，特点：直观、简洁、友好语音通过语音来进行输入和输出，如与机器人的交互、Siri、手机导航软件等，特点：将双手解放出来，需要麦克风手势通过姿势(gesture)来进行交互，如与无人机交互等，特点：准确性不高，需要视频传感器示例：基于文本输入的用户界面DOS中的用户命令的文本输入以及文本的输出基于文本的交互方式有何局限性？示例：“腾讯会议”的图形化用户界面图标展示软件名称按钮点击完成相关的操作加入会议注册/登录基于图形化界面的交互方式有何优势？示例：基于语音的人机交互设计基于语音交互设计的友好性和满意度计算机能够准确地理解用户的语音用户能否听得到、听得清计算机反馈的语音信息能否在不同的环境（如嘈杂、安静）下具有不同的音亮能否针对用户的位置来定向式地播放语言……什么情况下用语音交互方式比较合适？思考和讨论除了图形化界面之外，人和计算机之间还有哪些交互手段，并列举典型的软件示例。1.2人机交互的关键用户的满意度用户通常将用户界面视为软件本身，用户界面是用户接触软件的主体要素用户界面设计的质量直接决定了用户对软件系统的评价，影响用户对软件系统的满意度方便输入快速、便捷、准确、友好的输入；鼠标、点击、选择等直观输出直观、显式、可理解、简洁的输出；所见即所得、图形展示等以用户为中心设计用户界面将用户特征作为用户界面设计决策的依据识别用户及其特征；用户是谁，有何特点如操作习惯、文化背景、教育程度分析用户与计算机系统之间的交互信息及合适的手段尽可能获得用户反馈并以此来改进和优化设计如何来获得用户反馈？软件原型从用户立场出发、便于用户理解和操作以用户体验感受和满意度为依据评审交互设计1.3用户界面元素及实现方式静态元素与软件系统的运行状态无关，没有变化如文本、图标、图形、图像动态元素与软件运行状态和业务逻辑相关，不允许用户修改如不可编辑文本、表格、图标、图形等用户输入元素由用户填写或者选择如编辑文本、单选按钮、多选框等用户命令元素点击后激活后端的业务处理或者刷新界面如按钮、菜单、超链接等用户界面元素示例用户输入元素静态元素用户命令元素动态元素？？？？思考和讨论静态、动态、命令、输入界面元素有哪些？1.4用UML类图表示用户界面元素窗口或对话框

对象类静态和动态元素

类属性输入元素

类属性命令元素

类方法ClassName：PrinterSettingProperty: PrinterName: PrinterStatue: PrinterType: ……Methods: SetProperty() OK() Cancel()……用类图表示用户界面用UML顺序图表示界面的跳转关系跳转用顺序图表示用户界面的跳转内容用户界面基础人机交互方式用户界面的组成元素及UML表示用户界面设计任务、过程和原则具体的设计步骤及方法用户界面输出及评审用户界面的输出用户界面的评审2.1用户界面设计的任务根据软件需求及其操作流程，为其设计出与用户进行交互的界面，支持用户对软件的操作和使用2.2用户界面设计原则（1/2）直观性界面元素贴近业务领域，具有简洁、明确、直观特性界面中屏幕间的跳转关系简单、自然易操作性简单、简洁、不繁琐尽量减少用户输入的次数和信息量反应性界面必须在合理时间内对用户操作做出响应对耗时较长的内部处理过程必须提供及时的进度反馈用户界面设计原则（2/2）一致性保持一致的界面风格和操作方式与业界相关的用户界面规范和操作习惯相一致容错性界面设计应降低用户的误操作率、容忍用户的误操作对所有可能造成损害的动作，必须在用户确认后才进行允许用户对尽可能多的界面操作反悔（Undo）人性化在适当时机给用户提供需要的帮助或建议在任何情况用户均能理解软件系统的当前状态和响应信息界面的布局和色彩应使用户感觉舒适、自然思考和讨论是否以用户为中心是否遵循以上原则存在哪些不足缺陷有何改进意见建议讨论和分析软件界面设计中存在的问题和不足，提出改进意见2.3用户界面设计过程用户界面初步设计建立界面跳转关系精化各个界面设计评审界面设计用户界面设计以软件需求模型为依据，基于用例模型、用例交互模型等，采用自顶向下、逐步求精的设计原则2.3.1用户界面初步设计根据需求确定用户界面基于用例模型和用例交互模型确定界面中包含的元素设计静态元素、动态元素、输入元素、命令元素注意点关注界面元素及内容，不追求布局和美观（1）确定用户界面的设计元素分析软件需求的用例模型及用例交互模型用户向用户界面发送消息参数意味着用户需要提供某些信息，对应于用户需要输入信息，因此在用户界面上必须对应有相应的输入界面元素，并需提供配套静态界面元素以帮助和支持用户输入信息，这些设计元素就构成了用户界面类的相关属性如果用户界面类对象要向其他的类对象反馈信息，那么这些信息对应于用户界面需要输出的信息，此时在用户界面上必须对应有相应的动态元素以向用户显示信息处理的结果，这些动态元素就构成了用户界面类的相关属性（2）确定用户界面的操作分析软件需求的用例交互模型用户界面类对象向其他类对象发送的消息表示用户向后端业务处理系统提交的命令，它们对应于用户界面中的用户命令界面元素以及相应的操作这些操作大体表现为以下几种形式用户命令元素触发的操作（如点击“确认”按钮）动态元素的值的改变导致的操作（如显示的系统状态发生了变化）思考和讨论用例交互顺序图该用户界面应该有哪些输入和输出信息？有哪些方面的操作？示例：“空巢老人看护系统”用户界面概念设计引导界面“GuidingUI”登录界面“LoginUI”监视老人状况界面“MonitoringUI”控制机器人运动界面“MotionCtrlUI”

与老人交互界面“BiCallUI”系统设置界面“SettingUI”示例：用户界面“MonitoringUI”设计动态元素动态元素用户命令元素用户输入元素示例：用户界面的设计类图用户界面设计类图示例：登录用例的顺序图及其用户界面设计登录用例的顺序图登录用户界面用户输入元素用户命令元素示例：“LoginUI”的设计类图登录界面的设计类图登录用户界面2.3.2建立用户界面间的跳转关系目标确定主界面，用户刚使用某项用例时系统呈现的界面，其他界面均源自于主界面，且用户对其他界面操作后一般会回归到主界面确定界面间的跳转关系，即一个界面在何种情况下，或者在响应何种用户操作命令后将跳转至另一界面原因单个屏幕空间容量有限，不足以表现所有必要的界面元素用户在主屏幕上的界面操作可能导出新的屏幕，以便在新屏幕上进行面向特定业务功能的界面交互用UML图来表示用户界面的跳转关系交互图表示特定场景下的跳转及跳转发生时的消息传递类图表示界面间所有可能发生的跳转及跳转的原因示例：“空巢老人看护系统”用户界面跳转关系表示界面跳转的顺序图示例：“空巢老人看护系统”用户界面跳转关系表示界面跳转的类图示例：界面跳转实际的界面跳转2.3.3精化用户界面基于概念设计和界面流设计，给出目标软件产品界面的完整、详细的设计从界面概念设计成果出发进行细化、补充等，将界面流中每次跳转动作与具体的事件或界面动作关联起来在软件系统的全局范围内对屏幕的设计和界面流进行优化将精化后的界面设计成果提交给美工设计师，由其进行必要的装饰、美化工作精化内容补齐概念设计遗漏或者故意忽略的界面元素采用最合适的界面元素来组织信息的呈现或录入树形结构还是Tab、用什么样的选择按钮将哪些界面集结于一个区域，哪些界面元素应对齐将界面操作与UML类方法对应起来精化界面时同步修改、补充界面设计的UML类图考虑合并某些界面或者拆分某些界面确保界面设计风格的一致性内容用户界面基础人机交互方式用户界面的组成元素及UML表示用户界面设计任务、过程和原则具体的设计步骤及方法用户界面输出及评审用户界面的输出用户界面的评审3.1用户界面设计的输出用户界面原型可运行和演示、可操作和评估用户界面设计的UML模型顺序图类图3.2用户界面评审的内容和原则用户界面是否符合用户的操作习惯和要求，用户能够接受用户界面的展示形式用户界面的风格是否一致用户界面及其设计元素是否美观所有用户界面布局是否合理，跳转是否流畅，界面跳转与用例中的交互动作序列在逻辑上是否协调用户界面与其UML模型描述二者之间是否一致，用户界面的类图和顺序图二个模型之间是否一致用户界面的不同元素之间是否一致，如静态/动态元素描述与用户的输入/命令元素之间是否一致等等总结用户界面设计以用户为中心遵循理解性、易操作性、一致性、容错性和人性化等原则用户界面设计的过程以软件需求为依据概念设计、跳转关系设计、界面精化、设计评审用户界面设计的结果用户界面原型UML类图、交互图等模型课程实践1：设计开源软件的用户界面任务：开源软件的用户界面设计方法针对开源软件新增加的软件需求，考虑软件的用例模型和用例交互模型，对开源软件的用户界面进行设计，以支持用户与开源软件的输入和输出，进而实现开源软件的新功能要求基于开源软件新构思的软件需求，针对其用例模型和用例交互模型，要以用户为中心进行设计和优化结果：用户界面原型，用户界面的UML类图模型以及界面跳转的顺序图模型课程实践2：设计新开发软件的用户界面任务：软件用户界面设计方法基于用户的软件需求，针对软件系统的用例模型和用例交互模型，设计软件系统的用户界面，明确每个用户界面的设计要素，界面之间的跳转关系，以支持用户与软件系统之间的输入和输出要求针对所构思的软件需求，包括用例模型和用例交互模型，要以用户为中心开展用户界面的设计结果：用户界面原型，用户界面的UML类图模型以及界面跳转的顺序图模型思考和讨论你认为哪个软件的用户界面你最喜欢？为什么？问题和讨论软件详细设计内容软件详细设计概述任务、过程和原则详细设计的UML模型软件详细设计活动用例设计类设计数据设计子系统和构件设计详细设计文档化和评审1.1软件设计过程及关注点的变化结构性全局性关键性粗粒度过程性局部性细节性细粒度设计模型和文档体系结构设计人机界面设计详细设计整合与验证迭代设计、反复精化、持续优化1.2详细设计的任务输入：软件体系结构设计、用户界面设计、软件需求任务：对体系结构设计和用户界面设计成果进行细化和精化，获得高质量、面向实现的设计模型面向实现：直接支持编码和程序设计精化和细化的具体对象：子系统、构件、关键设计类和界面类软件详细设计软件需求软件详细设计模型体系结构设计模型用户界面设计模型实现约束和限制何为面向实现？详细设计是高层设计和底层实现间的桥梁高层软件体系结构设计软件详细设计软件实现辅助和支持落实和细化详细设计的定位体系结构设计与软件实现间的“桥梁”基于体系结构设计和用户界面设计后续程序设计的基础和依据确保体系结构设计得到落实的“关键”基于体系结构设计和用户界面设计，关注于体系结构中设计元素的内部细节设计更加关注软件的“实现”与体系结构设计相比较，详细设计抽象层次更低、粒度更小、更加关注实现细节1.3详细设计过程软件详细设计的活动（1/2）用例设计给出用例的具体实现解决方案，描述用例是如何通过各个设计元素（包括子系统、软构件、设计类等）的交互和协作来完成的类设计给出每个设计类的具体实现细节，包括类的属性定义、方法的实现算法等，使得程序员能够基于类设计给出这些类的实现代码软件详细设计的活动（2/2）数据设计对软件所涉及的持久数据及其操作进行设计，明确持久数据的存储方式和格式，细化数据操作的实现细节子系统/软构件设计针对粗粒度的子系统和软构件，给出其细粒度的设计元素，如子子系统、设计类等，明确这些设计元素之间的协作关系，使得它们能够实现子系统/软构件接口所规定的相关功能和服务1.4软件详细设计的要求和原则针对软件需求从软件需求出发，确保每一项软件需求都有相应的详细设计元素加以实现深入优化设计精心设计，以充分优化软件系统的性能、效能等，提高软件系统的可靠性、可重用性和可维护性等设计足够详细得到详实程度足以支持程序员编码的软件设计模型充分软件重用从多个不同的维度和层次进行充分的软件重用，以提高软件开发的效率和质量，减低开发成本活动图©CopyrightXinjunMao178视点图（diagram）说明结构

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

状态图(statechartdiagram)描述状态的变迁活动图(activitydiagram)描述系统活动的实施通信图(communicationdiagram)描述对象间的消息传递与协作顺序图(sequencediagram)描述对象间的消息传递与协作部署部署图（deploymentdiagram）描述系统中工件在物理运行环境中的部署情况用例用例图（usecasediagram）从外部用户角度描述系统功能1.5何为活动图描述实体为完成某项功能而执行的操作序列，其中某些操作或其子序列存在并发和同步示例：活动图活动决策点信息流和控制流泳道活动图的构成活动点：表示计算过程决策点：根据条件进行活动决策边：表示控制流或信息流控制流：表示一个操作完成后对其后续操作的触发信息流：刻画操作间的信息交换并发控制控制流经此节点后分叉（Fork）成多条可并行执行的控制流，或多条并行控制流经此节点后同步合并（Join）为单条控制流泳道将活动图用形如游泳池中的泳道分隔成数个活动分区，每个区域由一个对象或一个控制线程负责泳道将活动图用形如游泳池中的泳道分隔成数个活动分区，每个区域由一个对象或一个控制线程负责每个活动节点应位于负责执行该活动的对象或线程所在的区域内带泳道的活动图更清晰地表示了对象或线程的职责、它们之间的分工、协同和同步活动图的绘制原则从决策点出发的每条边上均应标注条件，且这些条件必须覆盖完整且互不重叠必须确保分叉和汇合节点之间的匹配性对任一分叉节点，其导致的并发控制流必须最终经由一个汇合节点进行控制流的同步和合并一张活动图可以浓缩成另一活动图中的单个活动节点，前者称为子活动图，后者称为父活动图内容软件详细设计概述任务、过程和原则详细设计的UML模型软件详细设计活动2.1用例设计2.2类设计2.3数据设计2.4子系统和构件设计详细设计文档化和评审思考和讨论需求分析阶段的用例描述了软件功能，那么这些功能是如何实现的？需求分析阶段描述了用例的交互图，它刻画了用例哪些方面的信息？其中的对象类称之为分析类，为什么？需求用例及其实现用例反映了软件需求，基于需求来指导和细化设计用例描述了业务逻辑的实施流程用例设计要明确需求是如何实现的软件要素实现需求2.1用例设计的任务任务针对需求分析模型中的每个用例，基于体系结构和用户界面设计模型给出的设计元素，设计用例的软件实现方案设计和建模各个设计元素如何通过协作完成用例关联各个设计元素，包括子系统、构件、对象类、界面等产生详细的设计信息，如新的设计元素、细节、关联结果描述用例设计的顺序图、类图等设计模型用例设计的任务用例设计用例模型用例交互模型分析类模型软件体系结构设计模型用户界面模型用例设计模型（用例实现交互图、设计类图等）用例的实现方案用例如何通过各个设计元素来实现的子系统、构件、设计类、界面元素类等这些设计元素之间在用例实现过程中的协同和交互消息传递精化各个设计元素的设计如接口、实现细节等设计元素最终需要通过代码加以实现用例设计原则以软件需求为基础以需求模型为前提，包括用例模型、交互模型、分析类模型等不能抛开软件需求来给出用例的实现方案通过整合设计元素来实现用例整合软件体系结构设计、用户界面设计等产生了一系列设计元素，包括：子系统、构件、关键设计类等等不能抛开前期设计工作成果精化软件设计用例设计不仅要给出用例实现的解决方案，也要依此为目的进一步精化软件设计，以获得更为详实的设计信息为后续的详细设计奠定基础用例设计的过程设计用例实现方案构造设计类图优化和评审用例设计方案用例设计子系统/构件设计类设计数据模型设计设计整合与验证2.1.1设计用例实现方案基础分析每个用例的UML交互图，它是开展用例设计的依据考虑体系结构和用户界面设计要素，它们是用例实现参与者明确各个设计元素（如对象类、构件等）的职责方法在分析阶段用例交互图的基础上，将交互图的分析类转化为用例实现的设计类，同时引入体系结构设计和用户界面设计所生成的设计元素，共同形成关于用例实现的交互模型结果生成用例实现的顺序图引入更多的设计元素，如构件、子系统、类等精化更多的设计细节，如接口、方法、交互等示例：需求分析阶段的用例交互图分析阶段的用例交互图说明了什么？其中的类是分析类！分析类与设计元素间对应关系(1/3)一个分析类的一项职责由一个设计元素的单项操作完整地实现分析类和设计类有何本质的区别？分析类与设计元素间对应关系(2/3)一个分析类的一项职责由一个设计元素的多项操作来实现细化和分解的过程分析类与设计元素间对应关系(3/3)一个分析类的一项职责由多个设计元素协同完成细化和分解的过程示例1:“用户登录”用例顺序图（需求）示例2:“用户登录”用例设计方案（设计）设计元素及其交互所有设计元素最终通过代码加以实现示例2:“系统设置”用例的顺序图（需求）示例2:“系统设置”用例设计方案（设计）所有设计元素最终通过代码加以实现设计元素及其交互示例3:“提醒服务”用例的顺序图（需求）示例3:“提醒服务”用例设计方案（设计）所有设计元素最终通过代码加以实现设计元素及其交互示例4：”远程控制机器人”用例顺序图（需求）示例4:“远程控制机器人”用例设计方案（设计）所有设计元素最终通过代码加以实现设计元素及其交互2.1.2构造设计类图基于用例实现方案给出详细设计模型中的设计类图类图中的设计元素可以为子系统、构件和UML类用不同的构造型或者相应图符来表示对UML类图稍作扩充以表示详细设计类图允许在类图中出现子系统和构件，它们的类别可以采用不同的UML构造型或者不同的图元符号来表示构造设计类图的方法创建初始的设计类从分析类图、体系结构图、用例实现的顺序图寻找确定设计类的职责每个设计类都有职责，取决于对交互图中消息的响应确定设计类间的关系如果A与B有消息，那么它们间有关系：关联、聚合和组合确定设计类的属性需要保存哪些数据项、其他对象类信息形成整体设计类图模块化、职责和功能单一化原则，调整和优化注意事项确保设计类图与分析类图之间、设计类图与用例设计模型之间的一致性分析类图中的类在设计类图中有相应的对应物用例设计模型中的设计元素（主要是指参与用例实现的对象、对象间的消息传递）在设计类图中要有相应的对应物（主要是指设计类及其方法）示例：“用户登录”用例实现的设计类图用例设计的交互图示例：“用户登录”用例实现的设计类图用例设计对应的设计类图2.1.3优化和评审用例设计方案尽可能重用已有软件资产来实现用例并依此构建用例实现方案如开源软件、云服务、遗留系统、软件开发包等等合并设计元素将具有相同或相似职责的多个设计元素（包括类、子系统和构件等）进行整合，归并为一个设计元素。将设计元素（如类等）中具有相同或相似功能的多个方法整合为一个方法，以减少不必要的冗余设计。重组设计元素借助继承或代理机制，对设计元素进行必要的组织和重组，以发现不同类之间的一般和特殊关系，抽象出公共的方法。确保所有用例实现方案在软件系统中和谐共存，无逻辑冲突用例设计的输出用例设计的顺序图用例设计的类图用例设计小结任务：为需求模型中每个用例设计软件实现方案原则：整体性、正确性、优化性等输出：用例实现方案的交互图、设计类图设计用例实现方案构造设计类图优化和评审设计方案思考与讨论为什么需要用例设计？需求阶段的用例交互模型与详细设计阶段的用例设计模型有何本质区别？内容软件详细设计概述任务、过程和原则详细设计的UML模型软件详细设计活动2.1用例设计2.2类设计2.3数据设计2.4子系统和构件设计详细设计文档化和评审类设计的任务任务对界面类、关键设计类、设计类等进行设计优化和精化，明确设计类的内部实现细节精化到可以提交软件实现的程度设计与建模明确类的可见范围，类的操作和属性，类之间的关系等对类设计进行建模结果类图、状态图、活动图等类设计的任务类设计用例模型用例交互模型分析类模型软件体系结构设计模型用户界面模型类设计模型（类图、活动图、状态图等）用例设计模型类设计的地位和作用“承上”类设计要充分考虑软件需求，基于体系结构设计、用户界面设计、用例设计、子系统/构件设计的成果“启下”类设计要为后续阶段的编码和实现奠定基础，需要产生足够详细的设计结果类设计示例精化类图还不够精化，需要更多的详细设计模型基于该类图，程序员指导如何进行编码吗？精化到什么程度类的可见范围属性的数据类型方法的实现算法类间关系状态变化或者活动情况类设计原则准确化对类的内部结构、行为等给予准确的表达，以支持程序员精准地理解类设计，进而编写出类的程序代码细节化对类的接口、属性、方法等方面给予足够详细的设计，以便程序员能够对类进行编程一致性要确保类的关系、属性、方法等的设计是相互一致的，类的内部属性、方法等设计与类的职责、关系等是相互一致的遵循软件设计的基本原则按照模块化、高内聚度、低耦合度、信息隐藏等基本原则来进行类设计，必要时需要基于这些原则对所设计的类进行必要的拆分和合并，以提高类设计的质量类设计过程确定类的可见范围精化类间关系构造状态图和活动图精化类属性和方法评审和优化类设计用例设计子系统/构件设计类设计数据模型设计设计整合与验证2.2.1确定类的可见范围可见范围如果类仅仅被其所在的包所使用，那么该类是“私有的”，否则是“公开的”原则尽量缩小类的可见范围，除非确有必要，否则应将类“隐藏”于包的内部public:公开级范围，软件系统中所有包中的类均可见和可访问该类protected：保护级范围，只对其所在包中的类以及该类的子类可见和访问private：私有级范围，只对其所在包中的类可见和访问为什么要缩小类的可见范围？2.2.2精化类间的关系明确类间的语义关系类间关系的语义强度从高到低依次是：继承，组合，聚合，（普通）关联，依赖类间关系定义的原则“自然抽象”原则，类间关系应该自然、直观地反映软件需求及其实现模型“强内聚、松耦合”的原则，即、尽量采用语义连接强度较小的关系精化类间的关系1:1，即一对一1:n，即一对多0:n，即0对多n:m，即多对多等等示例1：精化类间的关系示例2：精化类间的关系精化用户界面类间的关系示例3：精化类间的关系精化关键设计类间的关系2.2.3精化类的属性和方法精化类属性的设计精化类方法的设计（1）精化类属性的设计类属性的命名用业务领域的名词或者名词短语来命名类属性的可见范围public，对软件系统中的所有类均可见protected：仅对本类及其子类可见private：仅对本类可见遵循“信息隐藏”

原则，尽可能地缩小作用范围结合类关系来精化类属性设计如果类A与类B间存在1:1关联或聚合（非组合）关系，那么在A中设置类型为B的指针或引用（reference）的属性如果类A到类B间存在1:n关联或聚合（非组合）关系，那么在A中设置一个集合类型（如列表等）的属性，集合元素的类型为B的指针或引用如果类A与类B间存在1:1的组合关系，那么在A中设置类型为B的属性如果类A到类B间存在1:n的组合关系，那么在A中设置一个集合类型（如列表等）的属性，集合元素的类型为B示例：精化User类属性的设计二项属性：用户名“name”和用户密码“password”类型均为String可见范围均为“private”属性的初始值均为空串示例：精化LoginUI类属性的设计静态元素、用户输入元素和命令界面元素“loginPicture”

类型为静态元素“account”类型为用户输入元素，如文本框“password”

类型为用户输入元素（如文本框）可见范围均为“private”初始值“loginPicture”属性的初始值不为空，要有一个预加载的图标；“account”和“password”的初始值为空串示例：精化Robot类属性的设计privateintvelocity表示机器人的速度privateintangle表示运动角度privateintdistance表示与老人的距离privateintstate表示运动状态，包括“IDLE”空闲状态、“AUTO”自主跟随状态、“MANNUAL”手工控制状态（2）精化类方法的设计细化和明确类中各个方法的以下设计信息方法名称参数表（含参数的名称和类型）返回类型作用范围功能描述实现算法前提条件（pre-condition）、出口断言（post-condition）等示例：用活动图描述的Login()方法的详细设计关注特殊方法的设计对象创建方法在实例化类对象时会被执行，其职责能通常是完成类对象的初始化工作，包括初始化属性值等等对象删除方法在类对象生命周期结束前被执行，其职责通常是完成对象生命周期结束前的一些事务性工作，如释放对象所占用的资源等等对象比较方法比较类的两个实例对象，判断它们是否相同对象复制方法将类的一个实例对象的属性值复制到另一对象示例：精化detectFallDown()方法的详细设计分解和合并类方法优化类方法的设计实现类对象间的消息传递OOP提供四种手段