智能软件工程 课件 Ch4-如何设计软件

智能软件工程第4章如何设计软件4.1软件设计的基本原则4.2软件系统架构设计4.3微服务架构设计4.4接口设计4.5UI设计4.6数据设计软件设计的重要性目的:联结用户需求("人类的目标世界")和软件开发("技术世界")的关键一步.价值:构建高质量、可维护、可扩展软件系统的关键阶段.影响:奠定系统架构、模块、接口与数据存储结构，直接影响项目质量与维护开销，是项目成功的关键.问题:缺乏设计会导致代码冗余、功能整合困难、交流成本增加、团队士气降低.挑战:无“银弹”通用设计方法，需应对多样化的软件需求和场景4.1

软件设计的基本原则抽象与精化抽象:隐藏复杂细节，聚焦高层次理解，简化问题，抓住本质(如TMS系统中“发送消息”、“信息”概念).精化:逐步分解高层次抽象概念，获取可编码实现的细粒度单元(如“信息”精化为“文本信息”、“图片信息”)模块化将复杂系统分解为功能独立、依赖最小的模块.提升结构清晰度、灵活性与可扩展性(如TMS的用户管理、团队沟通模块)信息隐藏隐藏模块内部实现细节，只暴露必要接口和信息.减少模块耦合，便于独立开发、测试和维护(如TMS博文模块的search()接口，使用者不需要了解搜索的具体算法)关注点分离将不同功能和业务逻辑分离到独立模块或层次，各司其职(如Web应用的Controller,Service,Repository,Model层).与模块化、信息隐藏紧密联系，相辅相成SOLID面向对象设计原则

全称描述S单一职责原则(SRP)SingleResponsibilityPrinciple一个类应该仅有一个责任（一个类应该只有一个引起其变化的原因）。O开放封闭原则(OCP)Open/ClosedPrinciple软件应当对扩展开放，对修改封闭。尽量通过扩展而非修改现有代码来实现功能的变化。L里氏替换原则(LSP)LiskovSubstitutionPrinciple子类对象可以替换父类对象，且程序的正确性不应发生变化。I接口隔离原则(ISP)InterfaceSegregationPrinciple不应强迫客户端依赖它不需要的接口，多个特定用途的接口优于一个宽泛通用的接口。D依赖倒置原则(DIP)DependencyInversionPrinciple高层模块不应依赖于低层模块，二者应通过抽象接口或抽象类来交互，避免直接依赖具体实现。设计模式创建型模式（如工厂方法、单例模式），聚焦对象创建过程的优化与抽象；结构型模式（如装饰器、组合模式），致力于通过灵活组合构建复杂结构；行为型模式（如观察者、策略模式），关注对象间通信与责任分配的动态管理。应用装饰器模式的字体风格叠加场景设计智能化工具在软件设计中的应用帮助学习者理解抽象概念，提供代码反馈，加速理论与实践转化例：学生在学习SOLID中的单一职责原则（SRP），有如下困惑：“单一职责原则要求一个类只有一个改变的理由，但‘改变的理由’具体指什么呢？难道一个类不能做多件事吗？”，右侧是DeepSeek的回答。4.2

软件系统架构设计版权所有©️仅限于教学使用软件系统架构的定义定义:明确系统模块/组件在何种环境下、如何交互，形成可运作的整体.作用:软件系统整体蓝图，对质量与可维护性影响深远，关乎成功.价值:直接响应业务需求与功能需求，提高用户满意度.清晰模块与组件关系，促进开发团队协同工作.降低项目风险，提前识别并解决潜在问题架构风格概念:软件社区积累的宝贵经验与最佳实践，提供通用设计原则.目的:为开发团队提供设计起点，提高系统可维护性与可扩展性.分类:本章介绍五类架构模式：单体、分布式、面向服务、微服务、无服务单体架构特点:整个应用程序作为一个单一、紧密耦合的单元设计与开发常见类型:分层架构(Layered):N层划分(展示、业务、持久化、数据库)，层间隔离，降低耦合单体架构特点:整个应用程序作为一个单一、紧密耦合的单元设计与开发常见类型:主程序-子程序架构(Mainprogram/subprogram):主程序控制，子程序执行任务单体架构特点:整个应用程序作为一个单一、紧密耦合的单元设计与开发常见类型:以数据为中心的架构(Data-centered):数据存储系统为核心，所有操作围绕数据展开，保证数据一致性单体架构特点:整个应用程序作为一个单一、紧密耦合的单元设计与开发常见类型:管道-过滤器架构(Pipe-and-filter):系统分解为一系列过滤器，数据逐步处理与转换单体架构的挑战难以维护与扩展随着系统规模和复杂性增长，作为单一、紧密耦合单元的应用程序，变得难以维护和扩展。所有代码和数据共享，一个缺陷可能影响全局，难以单独修复与更新。部署风险高且耗时每次更新需重新部署整个应用，风险高且耗时。小错误可能导致系统长时间停机。性能受限性能和可靠性受单一服务器限制，难以处理大规模、高并发需求。所有操作集中在数据存储系统上，可能导致性能瓶颈。技术栈异构困难不同模块倾向于使用相同技术栈；新成员采用不同技术栈实现上会比较困难分布式架构定义将应用拆分为多个独立模块/组件分布在不同服务器上，通过网络通信与协调完成任务核心特征解耦：组件独立开发、部署、维护可扩展性：可根据负载横向扩展容错性：某些组件故障不致使整个系统瘫痪典型架构类型微内核架构（MicrokernelArchitecture）事件驱动架构（Event-DrivenArchitecture）微内核架构核心系统仅包含最基础、通用的功能业务功能以插件（Plug-ins/Add-ons）形式扩展又称插件式架构（Plug-inArchitecture）微内核架构典型应用Eclipse、IntelliJIDEA、VSCode（插件扩展功能）Chrome浏览器（插件生态）优势灵活性与可扩展性高核心系统保持精简、稳定插件独立更新、维护，减少对系统其他部分的影响设计注意事项减少插件间依赖，避免削弱架构优势事件驱动架构核心思想基于事件触发和异步通信事件作为系统状态更新的触发器（如提交订单、传感器数据更新）关键组成事件代理（EventBroker）：收集、分发、协调事件流服务（Service）：事件消费者，执行业务逻辑（订单处理、邮件通知等）消息队列：实现异步通信与解耦事件驱动架构工作机制服务通过订阅（Subscribe）关注感兴趣的事件事件发生→发布至事件代理→分发给相关服务服务执行可能产生派生事件（DerivedEvents），进一步触发下游处理事件驱动架构采用事件驱动架构的在线购物平台：下单场景事件驱动架构优势解耦性强：服务独立，更新或故障互不影响异步性高：耗时任务后台执行，提升用户体验高并发支持：适合处理大量用户请求和后台任务灵活扩展：易于增加新服务生态支持：可用框架（Kafka、AmazonEventBridge等）注意点架构复杂度高：比分层架构更难搭建与维护调试困难：异步事件难以像同步系统那样直接监控测试挑战：需关注事件正确触发与处理数据一致性问题：并发读写可能导致冲突面向服务的架构(SOA)核心理念将软件系统抽象为一系列“服务”，每个服务对应一个独立的业务。服务之间松散耦合，对外提供通用接口标准。可重用单独服务，也可组合实现复杂业务。面向服务的架构(SOA)架构组成业务服务(BusinessServices)：从客户角度定义功能，不涉及具体实现。企业服务(EnterpriseServices)：提供业务具体实现，可采用不同技术栈、编程语言或第三方应用。▪例如：“身份验证”可作为企业服务被多个业务复用。服务使用者通过服务注册表查找服务，发送请求并获取结果。服务间交互与整合通信协议：服务间使用既定协议（如SOAP,REST,ApacheThrift,JMS）进行信息交换。企业服务总线(ESB)：关键中间件，实现服务间的调度、编排与通信。面向服务的架构(SOA)应用案例概念1994年提出，2010年左右再次流行，解决资源、数据、团队分布问题。DelawareElectric：整合系统，提高开发效率。Cisco：统一产品订购体验，将“订购流程”作为服务。IndependenceBlueCross(IBC)：确保患者数据使用统一数据源。挑战过度抽象：为适应通用场景可能导致特定应用优化不足，甚至过度开发。严格规范：需要如SOAP等严格接口规范，增加系统复杂性，对开发团队专业性要求高，难以普适微服务架构2011年首次提出，2014年由JamesLewis和MartinFowler给出具体定义。将单一应用程序开发为一组小型服务。每个服务在自己的进程中运行，通过轻量级机制（如HTTPAPI）通信。服务围绕业务功能构建，可独立部署。服务可使用不同编程语言和数据存储技术，最小限度地集中管理。微服务架构案例研究：Amazon初期采用单体架构，随规模增长出现扩展性瓶颈。面临数据库庞大、开发部署周期长、功能添加复杂、系统故障频繁等问题微服务架构案例研究：Amazon逐步将整个系统的每个功能划分为独立的微服务目标是构建更灵活、适应市场和用户需求的系统促成AmazonWebServices(AWS)的诞生，奠定电商领域成功微服务架构案例研究：Netflix早期采用单体架构。2008年严重服务中断：小错误导致大规模数据损坏，停机数天。认识到单体架构难以应对用户增长和业务需求。逐步分离和重构为多个独立微服务，并迁移至AWS。微服务使其能更敏捷地推出新功能，提供更稳定可靠的服务团队协作系统：微服务重设计示例划分为六个独立服务博文、日程、聊天、翻译、用户、通知服务。服务间松散耦合，通过开放公共接口调用。多技术栈设计：博文服务：Java(SpringBoot,MyBatis)。个性化推荐服务：Python(TensorFlow,Flask,MySQL)。微服务架构的优势是对单体架构的分解，以“服务”为单位。每个服务可采用不同技术栈和独立数据源进行开发。实施了“模块化”、“信息隐藏”和“关注点分离”等设计理念。更灵活，系统易于演化和扩展。新需求可作为新微服务加入，错误/不再需要的服务可停用/移除，不影响其他服务。符合软件工程2.0的敏捷开发与拥抱变化思想无服务架构背景软件工程2.0时代为“软件即服务(SaaS)”。微服务架构是“一切皆服务”。微服务仍需开发者管理部署、计算资源、基础架构。“无服务”核心理念实现完整意义的服务化，开发者仅通过API网关访问API服务。开发者无需了解系统基础架构或顾虑资源使用。系统完全由第三方管理。确切翻译应为“无服务器”。无服务架构后端即服务(BaaS)：提供整个后端服务，包括数据库、身份认证、消息队列、存储等。服务运行在云端，开发者无需考虑技术细节与部署。函数即服务(FaaS)：专注于按需运行的独立功能单元。开发者编写小型、独立的函数，在云端由特定事件触发执行。开发者无需考虑算力问题：云服务商自动化扩展，算力“无限”无服务架构发展历程概念最早于2012年由Iron.io提出。Amazon(2014)发布AWSLambda，推动商业化。GoogleCloudFunctions和AzureFunctions(2016)。阿里云与腾讯云等厂商(2018)也推出产品，成为软件架构热门领域愿景BaaS和FaaS可结合使用，提供全面后端支持和特定计算任务处理。将业务与基础设施、硬件算力、组件部署、系统运维等技术细节完全剥离。使开发者能够纯粹专注于业务逻辑4.3

微服务架构设计版权所有©️仅限于教学使用章节目标探讨如何将软件系统设计成微服务架构。回答微服务架构设计中的三个基本问题如何定义“服务”？如何实现服务间的沟通？如何搭建支持微服务的基础设施？讨论构建微服务架构时常用的设计思想如何定义“服务”？在微服务架构中，“服务”是软件系统中可独立更新(upgradeable)、独立部署(deployable)的单元或软件组件。服务通过开放API供其他服务使用或调用其他服务。服务内部更新和重新部署对其他服务影响最小，体现了松耦合性如何拆分“服务”？软件系统架构设计，特别是服务拆分，是创新而非机械的过程，没有固定步骤。基本流程包括：确定领域模型、识别系统操作、服务拆分确定领域模型根据用户故事和场景描述，通过名词识别系统中的关键概念（如：用户、频道、消息、任务、看板）。这些概念构成抽象领域模型。识别系统操作根据用户故事和场景描述，通过动词确定系统操作（如：浏览频道、发布消息、设置任务状态、查看任务看板）。系统操作分为查询型（Query-type）和命令型（Command-type）。操作规范定义应包含参数、返回值、前置条件与后置条件基于业务能力的服务拆分业务能力：企业能够完成的事情或产生价值的活动。从客户角度看，是他们愿意付费的产品功能或服务。业务能力可分层级，最终映射到服务。优势：稳定性高，关注“能做什么”而非“怎么做”，业务实现变化不影响业务能力定义。TMS系统一种可能的基于业务能力的服务拆分基于子域的服务拆分源自领域驱动设计(DDD)，通过深入理解业务捕捉需求。核心理念：通用语言(Ubiquitouslanguage)、领域(Domain)、限界上下文(Boundedcontext)。子域分类：核心域：系统最关键、最具竞争力的部分（如：TMS的实时协作、任务管理）。通用域：多个子域共用，无企业特点，可通用解决方案（如：用户认证、消息通知）。支撑域：支撑核心功能，有企业特点但不具通用性（如：TMS的文件管理）。限界上下文：子域划分边界，同一术语在不同上下文中含义不同。优势：更契合微服务理念，开发团队高度自治，独立负责子域或服务，提高灵活性和响应能力基于子域的服务拆分TMS系统一种可能的基于子域的服务拆分如何实现服务间的沟通？微服务运行在不同机器/不同进程上，通过网络通信。允许服务独立运行，通过定义明确的API交互客户端与服务的对应关系：“一对一”(点对点)：一个请求由一个服务处理。“一对多”：一个请求由多个服务处理。交互方式的异步性：同步模式：客户端请求需实时响应，可能阻塞。异步模式：服务端响应非实时，客户端不阻塞服务间交互类型请求/响应：一对一同步，客户端请求并等待即刻响应（如：获取用户信息）。异步请求/响应：一对一异步，客户端发请求后可继续操作，服务异步响应（如：文件传输成功通知）。单向通知：一对一异步，客户端发送请求不期待任何响应（如：发送日志通知）。发布/订阅：一对多异步，客户端发布消息，零个或多个服务订阅接收（如：新任务消息被多个服务订阅）。发布/异步响应：一对多异步，客户端发布请求，等待感兴趣的服务异步响应（如：查询项目综合状态）。实际微服务架构通常是这些类型的组合API设计理念API是微服务架构的核心，连接系统内外组件。影响系统的灵活性、可维护性与性能。良好API设计是成功基石：需考虑易用性、平台独立性、服务演化可能性。关键：客户端不受API内部实现与演化影响。设计决策包括通信机制、消息格式、接口命名等RESTAPIRepresentationalStateTransfer(REST)：一种软件架构风格，常用于Web服务设计基于标准HTTP协议通信。资源(resource)：通过唯一URI标识（如：/users,/blogs）。操作：通过标准HTTP方法(GET,POST,PUT,DELETE)定义。状态无关(stateless)：每个请求包含足够信息，服务端不存储客户端状态。统一接口：简化客户端与服务器交互遵循REST风格的API称为RESTAPI(RESTfulAPI)RESTAPI主要设计原则以资源为核心进行API设计资源可以是个体或集合。URI使用复数名词表示资源，单个资源用/resources/{resourceId}。资源粒度：避免过细导致过多请求和I/O开销。资源关联性：避免URI过度复杂（如/users/1/projects/2/tasks），保持简洁与直观。避免依赖底层数据实现：抽象数据实现，API独立于数据库表结构，提升可维护性/users/users/1/blogs/blogs/2RESTAPI主要设计原则基于HTTP方法定义API操作GET：获取资源或资源集合。POST：创建新资源，通常应用于资源集合。PUT：更新或创建特定资源，通常应用于单个资源。DELETE：删除指定资源GET/usersGET/users/1DELETE/blogs/2POST/usersPOST/users/1/tasksPUT/users/1RESTAPI主要设计原则API结果设计异步RESTAPI：对于耗时的POST,PUT,DELETE操作，可返回HTTP状态码202(Accepted)，并在Location头部包含查询异步请求状态的链接客户端可以通过轮询此链接来监控请求的执行进度HTTP/1.1202AcceptedLocation:/status/tasks/123HTTP/1.1200OKContent-Type:application/json

{"status":"Inprogress","link":{"rel":"cancel","method":"delete","href":"/status/tasks/123"}}RESTAPI主要设计原则API结果设计消息格式：常用JSON(MIME=application/json)。HATEOAS(HypertextastheEngineofApplicationState)：在GET响应中包含超链接，代表可执行操作，使客户端动态导航和发现资源GET/tasks/123{"taskId":123,"status":"complete","_links":{"files":{"href":"/tasks/123/files"}}}API网关解决的问题：查看复杂项目信息时的服务延迟、跨平台扩展（浏览器/APP）的不同客户端需求、微服务动态发现与演化、底层协议多样性。作用：作为单一入口供客户端访问，类似门面模式。主要功能：请求路由(Requestrouting)：将外部请求路由到内部微服务。请求组合(APIcomposition)：将多个细粒度API组合成一个粗粒度API。协议转换(Protocoltranslation)：统一外部客户访问的API协议（如提供统一RESTAPI）。API定制(APIperclient)：为不同类型的客户端提供定制化API。切面功能(Cross-cuttingfunctions)：集中处理身份验证、授权、缓存、限流、监控等通用功能消息机制用于支持微服务间的异步通信。基本模型：包含消息（主体、头部信息）和消息通道。消息主体：命令式消息含操作及参数；事件式消息含事件领域/状态。消息头部：元数据（发送者、ID、回复通道等）。核心理念：异步通信，发送者和接收者无需同时活跃消息机制常见消息通道：点对点通道(point-to-point)：一对一交互，消息发往具体接收者（常用命令式消息）。发布-订阅通道(publish-subscribe)：一对多交互，消息发布到主题，所有订阅者接收（常用事件式消息）。消息通道实现：通常依赖AMQP等异步通信协议。消息代理(messagebroker)：作为消息中转站，负责接收、存储、传递消息。优势：解耦生产者与消费者，提供缓冲机制。常用代理：ApacheActiveMQ,RabbitMQ,ApacheKafka等RESTvs.消息机制以REST机制设计的任务发布场景以消息机制设计的任务发布场景RESTvs.消息机制结合REST与消息机制的任务发布场景AI辅助的软件架构设计自定义ChatGPT“SoftwareArchitect”对TMS系统的架构设计AI辅助的软件架构设计自定义ChatGPT“SoftwareArchitect”对TMS系统的架构设计AI辅助的软件架构设计SoftwareArchitectureVisualizer为TMS系统生成的PlanUML代码与对应架构图AI辅助的软件架构设计SoftwareArchitectureVisualizer生成的PlanUML代码对应的UML时序图最佳实践：微服务架构设计与指导原则设计挑战：应对不确定性架构设计面临多重不确定性：需求变化、运营压力（如用户涌入）、技术更新、人员流动等。核心前提：明确目标与需求首要任务：明确业务和用户需求，以及非功能性目标（性能、可靠性等）。实施保障：频繁与利益相关者沟通，确保需求理解无偏差。架构选择：没有“银弹”，只有“最合适”4.4

接口设计版权所有©️仅限于教学使用接口的类型类型划分：私有API：供组织内部系统集成使用，通常无需考虑外部认证。公开API(PublicAPI)：向公众开放，推广服务，构建生态（如TwitterRESTAPI）。合作伙伴API：仅对特定合作方开放，需严格认证和功能限制（如支付宝API）。设计维度权衡：API设计需综合考虑访问控制、实现透明性（平衡灵活性与安全性）、以及交互方式（影响性能和体验）接口的设计原则设计基础：接口设计需遵循软件基本原则（如模块化、信息隐藏、关注点分离）接口正交性与必要性：正交性：不同接口应承担独立的职责，避免功能重叠（例如：将createTask和assignTask的职责分清）。必要性：避免提供冗余或不必要的接口。符合用户直觉(命名)：名称应清晰、明确、简洁，避免使用含糊的动词（如避免使用handleUsers()，使用listUsers()）。在RESTAPI设计中，建议使用标准化、复数形式的资源名词接口的设计原则动词描述名词（资源名称）Create创建新资源Blog,Chat,Comment,File,Label,Language,User,Schedule,Task,Todo,etc.Get获取特定资源信息List获取并展示所有资源Delete删除特定资源Update更新特定资源标准化接口的动词+名词示意API的兼容性在更新API时，应避免破坏性变更（如移除或重命名现有字段）采用新增字段而非移除现有字段的方式进行更新，确保旧客户端仍能正常工作API的兼容性另一种常见的做法是使用如下的版本控制来避免大规模的破坏性变更。通过这种设计，老版本API仍然可用，并且给用户留出迁移时间；同时，新版本可以支持新的需求GET/v1/orders/{id}GET/v2/orders/{id}使用AI辅助的接口设计Cursor对接口名称的建议使用Cursor解释含义不清的接口使用AI辅助的接口设计Cursor对冗余的接口提出重构建议Cursor对新增的功能提出的API接口调整建议4.5

UI设计版权所有©️仅限于教学使用视觉设计（外观）定义：决定界面的“外观”，关注如何优化信息呈现和用户体验。核心元素：颜色、字体、形状、间距（留白）、图像与图标、纹理与风格。设计原则：对比(Contrast)：通过颜色/大小突出重点，提高可读性（如Netflix播放按钮）。层次(Hierarchy)：利用尺寸/颜色建立信息优先级，引导用户阅读（如电商页面重点突出标题/折扣）。一致性(Consistency)：界面元素统一，确保用户体验连贯。平衡(Balance)：合理分配视觉元素，避免视觉负担。交互设计（行为）定义：产品的“行为”，关注用户如何与界面互动（点击、跳转、反馈）。目标：决定产品的易用性和流畅度。关键原则：可见性(Visibility)——用户必须能够轻松找到并理解重要功能，降低学习成本原型设计将抽象需求转化为具体产品框架图，促进利益相关者在UI展现形式上达成一致。原型类型与应用：低保真(Low-fi)：手绘草图/线框图。成本低、调整快，适用于设计初期探索核心功能。中保真(Mid-fi)：具备一定交互和视觉元素，用于与开发人员准确沟通设计意图。高保真(High-fi)：接近最终产品外观和交互。适用于后期展示给客户或投资人。原型设计特性低保真原型高保真原型制作时间快速，几分钟到几小时需要较长时间，几天到几周成本低，仅需基本工具高，需要专业设计软件交互体验无交互或仅有简单点击具备完整交互体验视觉效果仅展示基本结构，无颜色、排版近似最终产品，包括所有视觉元素适用阶段早期概念构思、需求讨论设计后期、开发前、用户测试用户反馈适用于信息架构和功能讨论适用于界面设计和交互体验测试修改难度低，容易调整高，改动成本较大4.6

数据设计版权所有©️仅限于教学使用数据组织决定系统如何表示和管理信息，是数据设计的第一步。关键步骤：1.提取核心数据：从需求中识别关键概念（实体），例如TMS中的用户、任务、项目、评论。2.确定属性与类型：确定每个数据的属性及其合适的数据类型，以提高存储效率并减少错误（例如，日期/时间应使用Timestamp而非字符串）。3.明确数据关系：识别实体间的三种关系（一对一、一对多、多对多）。数据组织效率提升：使用ORM框架（ObjectRelationalMapping，如Hibernate）自动将UML类设计映射到数据库表，实现数据设计与类设计的同步TMS系统中Project类的部分代码，通过SpringDataJPA定义了数据间的关系数据存储存储目标：数据持久化、高效检索、数据一致性、并发控制和访问权限管理。数据库选择：数据库的选择对系统至关重要，需根据应用场景决定。关系型数据库(RDBMS)：采用表结构和SQL，适用于结构化数据和存在清晰关联的系统。示例：MySQL、PostgreSQL数据存储NoSQL(非关系型)数据库：键值存储(Key-Value)：适用于快速存取简单数据对（如用户会话缓存、实时热度统计）。文档存储(Document)：适用于半结构化、动态变化的数据（如内容管理系统中的文章），常采用JSON格式。列族数据库(Column-Family)：适用于大规模、高吞吐量的分布式存储，按列族组织数据以提高查询效率。图数据库(Graph)：适用于存储和查询高度关联的数据（如社交关系、推荐系统）。AI辅助的数据设计AI辅助的数据设计本章小结软件设计原则包括抽象与精化、