【软件系统架构设计】知识点汇总 |
您所在的位置：网站首页 › 存储体系架构有哪些 › 【软件系统架构设计】知识点汇总 |
【软件系统架构设计】知识点汇总
|
第一章 系统分析与设计概述
信息系统概述
信息系统组成：
信息系统类型： 业务处理系统 TPS管理信息系统 MIS决策支持系统 DSS专家系统 ES办公自动化系统 OA知识工作支持系统 KWS 信息系统软件软件系统类型：应用软件、支撑软件（中间件）、系统软件 举例说明中间件软件的功能作用？ 系统软件和用户应用软件之间连接的软件，搭建应用软件的环境，以便于软件各部件之间的沟通，如Tomcat 信息系统开发过程信息系统生命周期：
各个阶段主要活动： 系统规划：明确问题，提出解决方案与建设计划，可行性分析，启动项目系统需求分析：信息采集，定义需求，原型验证，划分优先级，需求规格说明系统设计阶段：构件设计、系统架构设计、程序流程设计、数据库设计、用户界面与系统接口设计、网络环境设计、安全机制设计系统构造阶段：系统集成、软件部署、程序编写、开发环境搭建、设备安装系统测试阶段系统运行和维护阶段信息系统和软件系统的关系？信息系统生命周期和软件生命周期的关系？ 信息系统范围更大，包含了软件系统；信息系统生命周期多了系统规划阶段 系统开发过程模型瀑布开发过程模型： 严格开展，大量文档组织简单，划分明确，大量文档工作，周期长，初期难以获得完整需求难以开展适用需求明确规模小的项目原型开发过程模型： 基于初始需求快速开发，下一版本迭代开发速度快，反馈快，难以标记里程碑，管理复杂，稳定性有挑战适用需求不明确，有大量人机交互的项目螺旋式开发过程模型： 迭代式开发，兼顾原型和瀑布引入风险分析，但是成本增加，项目管理更复杂适用大型复杂的系统开发，特别强调风险分析统一软件开发过程模型： 面向对象、用例驱动、以架构为中心增量迭代开发，与UML配套全面考虑，适用于大型复杂系统开发敏捷软件开发模型： 轻量级开发，编程人员与业务专家紧密合作，注重人的作用，适应需求快速变更注重系统快速开发，且适用于解决早期需求模糊或需求变更频繁的系统开发项目。不适合大型系统开发原型开发过程模型能解决瀑布开发过程模型的哪些问题？ 用户参与度低、需求变更不明确、风险管理不足 系统开发方法与工具 系统开发方法：自行开发、委托开发、购买商品软件、联合开发系统开发方法：结构化方法（面向过程）、面向对象开发方法、基于构件软件开发方法、面向服务的系统开发方法系统开发工具：项目管理工具，版本控制管理工具，分析与设计工具，程序开发工具，系统测试工具，系统维护工具系统开发环境是指在计算机硬件和系统软件平台上，进行信息系统开发及维护所使用的软件工具及集成环境。系统运行环境是指信息系统运行所依赖的平台环境，包括操作系统软件、数据库软件、运行时软件等软件环境，以及服务器、网络设备、存储设备等硬件支持环境。 第二章 面向对象建模语言 UML建模语言用例图：包括系统用例图和业务用例图（业务用例图有斜线，区分系统用例图） 活动图 类图 顺序图、通信图：返回消息用虚线 边界类：圆圈左边一个横着的 T控制类：圆圈加逆时针箭头实体类：圆圈下面一条线通信图：对象之间要有连接才能通信，连接用实线状态机图 构件图 构件的画法：右上角有标识接口和端口，接口之间的连接依赖：半圆指向圆圈代理连接：半圆伸出去实线部署图 常见的构造型：、包图：包的画法：方框左上角加一个方框 对象图 构件图、包图和部署图一般是在系统分析与设计的哪个阶段使用？ 系统设计 顺序图和通信图有什么联系与区别？ 联系：都用于表示系统中对象之间的交互和消息传递。 区别：顺序图更关注对象之间消息的时序和顺序，用于展示交互的时间顺序和时序约束，通信图更关注对象之间的关系和交互。 类图与对象图有什么联系与区别？ 类图可以看做是对象图的实例，用来表达各个对象在某一时刻的状态 类图在系统开发哪些阶段使用? 系统分析阶段和系统设计阶段 BPMN建模语言模型元素 方块是活动（任务），圆圈是事件，菱形是网关
子流程有加号，代表复合活动
注意消息流要用虚线 业务模型通常有哪些模型图？它们作用是什么? 组织机构图：它描述了组织内部的结构，包括各个部门之间的关系和层级关系。它有助于理解组织内部的决策流程和责任分配。业务流程图：它描述了组织内部的业务流程，包括各个步骤和环节。它有助于理解业务流程的运作方式，以及如何优化流程以提高效率。业务协作过程图：它描述了组织内部各个部门之间如何协同工作以完成特定任务。它有助于理解组织内部的协作方式，以及如何改进协作以提高效率。业务信息关系图：它描述了组织内部各个部门之间信息交换的方式和流程。它有助于理解信息交换的方式，以及如何优化信息交换以提高效率。 第三章 系统规划 系统规划概述为什么在信息系统建设前需要进行系统规划？ 系统规划提供了机构信息化建设的基本纲领和总体指向。 系统规划是工程项目实施的前提与依据。 做好系统规划可避免盲目信息化建设给机构带来巨大的损失 系统规划主要解决什么问题？ 根据组织机构使命及其战略目标，制定信息系统建设总体目标与愿景; 针对组织机构信息化需求，确定信息系统总体框架、技术路线与实施方案: 在充分考虑组织机构的技术、设备和人力资源等因素下，制定组织机构的信息系统实施建设项目计划，并分析评估信息系统建设方案可行性。 系统规划方法业务系统规划法 BSP： 信息系统必须支持组织机构战略目标系统规划应该表达出组织机构各个管理层次的信息化需求信息系统应为各部门提供一致的数据信息信息系统应适应机构管理体制的变化“自上而下”分析与“自下而上”设计相结合业务流程重组法 BPR： 以客户服务为中心，优化业务流程。跨部门业务流程重组优化。以过程管理代替职能管理，取消不增值的管理环节。取消不必要的信息处理环节，消除冗余信息集。价值链分析法 VCA： 分析企业中的主要业务活动链企业基本业务包括内部物流、产品生产、外部物流、产品销售、售后服务等环节。利用IT技术针对这些业务环节提供支持，促进它们对产品或服务产生更多价值。战略目标集转移法 SST： 根据组织机构战略目标确定信息系统目标。从组织机构战略集的支撑因素识别出相应信息系统战略约束。根据信息系统目标和约束提出信息系统的建设战略。关键成功因素法 KSF： 管理者可以根据机构目标确定关键成功因素，从中提取相应关键成功因素的关键绩效指标(Key Performance Indicator，KPI) 。根据KPI指标评价管理工作成效，从而形成以调控行为成效为目标的反馈控制系统。管理者就可以借助信息系统观测关键KPI指标而得知关键成功因素的状态，再通过关键成功因素状态调控来控制子目标的实现，进而促成机构目标的最终实现。BPR方法适合于哪类组织机构的系统规划？ BPR方法适用于那些需要进行全面变革、彻底重构业务流程的组织机构。这种方法可以帮助组织重新设计和优化其业务流程，以实现更高效、更灵活和更有竞争力的运营模式 系统项目计划项目工作分解 WBS：将项目工作按照交付成果方式，定义项目的详细任务过程。 任务活动排序：
画法：要有开始和结束，要有箭头 项目工期估算 三点估计法：项目经理或系统分析人员根据历史数据经验对某类任务活动的工期完成时间分别给出乐观时间（记为a）、悲观时间（记为b）和正常时间（记为m)。采用如下经验公式计算得到任务活动工期E。 E = ( a + 4 m + b ) / 6 E=(a+4m+b)/6 E=(a+4m+b)/6 德尔菲法： 项目成本估算与预算区别： 项目成本估算一般用于项目立项，先估算项目各任务成本，然后计算出项目总体费用。项目预算则用于项目计划，它是将项目成本总经费在各活动任务上进行经费分配，以便后期作为项目成本控制管理的基准。项目进度安排 项目任务网络中最长的一条路径称为关键路径，它决定了完成该项目的工期。关键路径上的每一项任务都是关键任务。这些任务的完成时间一旦有延迟，就会影响项目的完成时间。 甘特图方法 前置任务：前置任务是指在一个任务前面必须完成另一个任务，即任务之间的先后顺序。在项目计划中，可以使用甘特图或网络图的方式来表示任务之间的前置关系。 并行任务：有些任务可以同时进行，互不干扰，这时候可以将它们设置为并行任务。并行任务的好处是能够缩短项目的总时间，提高效率。 里程碑任务：里程碑任务是项目中的重要节点，表示一个阶段的完成或者是整个项目的完成。里程碑任务可以作为项目管理的重要依据，帮助管理者及时发现和解决问题。
PERT 图方法 甘特图与PERT图有何异同？ 甘特图侧重展现流程，PERT图侧重展现依赖关系 项目可行性分析包括：技术可行性分析，进度可行性分析，经济可行性分析，社会可行性分析等 第四章 系统需求分析 需求采集研究现有文档和系统：组织机构图，系统规划文档，工作规范文档，业务单据，报表，问题描述文档，领域专业知识，现有相关软件系统 与客户及相关人员进行面谈 问卷调查法：适合目标清晰、业务简单的项目 观察法 头脑风暴法 原型法： 进化式原型：逐渐演化，要求稳定性、可拓展性抛弃式原型：达到目的后抛弃，代价少，适合解决需求不确定性，减少风险，可以帮助用户和开发者激发需求开发过程： 快速应用开发 RAD：融合进化型原型法和头脑风暴法 快速应用开发与原型法在需求获取中有何异同？ 相同点：都可以用于项目初期需求不明确的时候使用。 不同点：快速应用开发是头脑风暴法与进化式原型开发的结合。而原型法有进化式和抛弃式两种。 下列哪些系统适合抛弃式原型开发实现？哪些系统适合进化式原型开发实现？ 全自动洗衣机控制系统网上学习系统人力资源管理系统抛弃式，进化式，进化式 可视化需求建模业务流程建模： 普通流程建模：包含私有业务流程（单泳池）和公开业务流程（多泳池） 合作流程建模：通常包含两个或更多泳池 编排流程建模：无泳池
业务用例建模：UML业务用例图 系统用例图：UML用例图，用例规约：写名称、简介、参与者、前置条件、基本流程、备选流程、后置条件 活动图建模 分析类图建模： 从问题领域抽取类：用例驱动、名词短语方法抽取类、公共类模式方法、CRC方法定义类名及其属性建模类之间的关系：关联、依赖、泛化、聚合、组合等业务建模与系统需求建模是什么关系？ 业务建模是系统需求建模的基础，两者相互关联 针对用例图中的各功能用例，如何进一步描述内部的处理要求？ 用例规约表、活动图 用例图、活动图和分析类图分别描述系统需求的什么内容？ 用例图：系统的功能需求 活动图：系统的业务流程流程 分析类图：系统的结构，系统中类之间的关系 需求文档化 功能性需求非功能性需求：性能需求、可靠性需求等 性能需求：响应时间、吞吐量、并发用户数、资源利用率等 接口需求： 用户接口（命令行还是图形用户界面）软件接口：调用API服务接口硬件接口：设备驱动、接插件标准通信接口：局域网通信协议、蓝牙4.0协议、WiFi协议等 需求管理需求管理内容：当需求数目比较少时，采用需求依赖矩阵是一种发现需求矛盾或需求重叠的有效技术方法。 需求变更管理 需求风险分析与优先级 需求变更对于项目有哪种风险？ 项目工作量增加，项目延期，项目成本增加，降低项目质量 如何对需求变更过程控制进行有效管理？ 采用需求变更管理工具 银行ATM机系统有哪些功能需求？哪些非功能需求？ 功能需求：登录、存款、取款、查询余额、转账、打印凭条 非功能需求：性能需求、可靠性、易用性、安全性、可维护性等 第五章 系统架构设计 系统设计概述系统设计过程： 系统设计基本方法： 抽象化：抽象过程是指从特殊对象到一般对象建立反映事物本质要素的过程。上层概念是对下层概念的抽象。通过抽象可实现系统全局建模描述。抽象使得设计者能在宏观层面描述过程和数据，不需被低层细节所困扰。逐步求精：逐步求精是将把问题的求解过程分解成若干步骤或阶段进行，每步处理都 比前步处理更加精化，更接近问题的解法。模块化信息隐藏模块独立系统设计方法分类： 抽象设计与逐步求精是什么关系? 抽象设计使得设计者能在宏观层面描述过程和数据而忽略低层的细节，逐步求精有助于设计者在微观层面设计低层技术细节。 在面向对象开发中，系统设计模型与系统分析模型如何联系? 分析与设计是无缝迭代过程，系统设计模型是在系统分析模型的基础上，对新建系统进行设计与具化的建模过程 系统架构基础系统架构类型： 系统总体架构是从全局层面给出系统各种组成要素之间结构关系。它通常包括基础设施、运行平台、应用软件、业务部门、信息数据以及用户等。 系统拓扑结构是指从系统基础设施平台层面描述节点与节点之间的通信连接关系。节点是指系统中处理逻辑相对独立的物理实体，如PC计算机、服务器、外围设备等。 服务器一般有web服务器，数据库服务器，应用服务器，DNS服务器还可以有缓存服务器，系统备份服务器等系统拓扑结构设计是从系统基础设施平台层面给出系统节点在网络环境中的结构关系，包括节点分布、节点类型、节点运行环境以及节点之间的通信联系。 基本类型：总线型、树型、星型、网状型、混合型
系统数据架构是指从数据管理视角所描述的系统架构，它通常用来反映各类数据咨源的组织与存储。系统数据架构不仅需要反映机构的数据结点分布关系。还需要考虑数据资源的存储结构与存储方式，如文件存储、数据库存储或数据仓库存储 系统数据分层架构设计：在大数据应用系统中，按照数据不同处理要求，可以将它们组织到不同层次的数据管理系统进行计算与分析处理。 数据源+数据集成+文件存储+数据存储+编程模型+数据分析 系统数据治理架构设计：在信息系统中， 一般是按照业务管理的数据治理需求，将数据资源部署到不同业务部门系统服务器进行数据访问与权限管理。系统数据治理架构与组织 机构的数据管理职能有直接关系。 系统数据存储架构设计：在信息系统中，一些数据资源需要采用文件系统存储，另外一些数据资源需要采用数据库系统存储，还有一些数据资源则需要数据仓库系统进行数据存储。每类存储系统在设计上需要满足应用需求，如支持高可用、高性能的存取访问。
系统应用架构是指从应用功能视角所描述的系统架构。系统应用架构关注立用功能划分、应用功能配置、服务访问、服务管理等要素。 企业级应用架构：在企业信息化全局层面，系统应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。一般在系统规划阶段设计。 系统应用架构：在开发单个信息系统时，设计系统的应用功能结构，并考虑系统各个层次的功能结构组成，如前端展示层、业务处理逻辑层、数据访问层的功能模块结构。一般在系统开发阶段设计。 系统管理包括：权限管理、日志管理、备份管理、数据管理等 应用支持平台可以有云计算平台、大数据引擎、消息队列、搜索引擎、动态加载等
软件体系架构（简称软件架构）是一种从软件视角所描述的系统架构，它对软件系统的结构、行为进行高层抽象，一般通过构件、连接件、配置、端口、角色等图符元素进行描述。 从上到下：展示层、业务层、数据层（数据处理层、数据存储层）、运行环境 如何理解系统架构？系统架构对信息系统有何影响？ 系统架构是指软件系统的组织结构，它确定了系统中的各个元素之间的关系和组织结构。 系统架构对信息系统的影响主要体现在以下几个方面： 确定系统的组成和结构：系统架构明确了系统的各个组成部分以及它们之间的关系，以及系统的整体结构。指导系统设计：系统架构是系统设计的基础，它为系统的开发、维护和扩展提供了指导和框架。确定系统功能：系统架构明确了系统的功能和职责，以及各个组成部分的功能和职责。影响系统性能：系统架构对系统的性能有很大的影响，不同的架构可能会导致不同的性能表现。约束系统开发：系统架构对系统的开发有一定的约束，它规定了系统的开发方式、开发工具和技术选择等方面的要求。为什么系统架构需要从多个视角进行描述？ 不同的视角可以反映系统的不同方面，有助于全面理解系统。从多个视角进行描述可以提高系统的可读性和可维护性，有助于团队成员之间的沟通和协作。从多个视角进行描述可以帮助团队更好地理解系统的质量属性，如性能、可靠性、安全性等，从而更好地满足业务需求哪种系统拓扑架构适合电子商务平台系统？ 混合型 针对具有高可用性的信息系统，采用什么数据架构更合适？ 数据治理架构 软件架构与系统架构有何不同? 软件架构是关注软件系统内部组件的结构和行为，定义了系统的整体框架和组件之间的协作方式。 系统架构则更广义，包括软件、硬件和网络等多个组成部分的设计和组织，考虑整个计算机系统的结构和互动关系。软件架构是系统架构的一部分 软件架构风格软件架构风格是指针对不同系统共性问题提供一般性可重用的软件架构解决方案，它反映了领域中众多系统所共有的软件结构及其模式。 分层体系架构：采用层次化方式组织功能构件，每一层都是为上一层提供服务，并使用下一层提供的功能服务。 优点：设计简化，系统结构清晰；支持拓展设计；只要提供接口就可以功能复用缺点：层次划分没有统一的方法，层次过多系统性能降低，层内部耦合拓展困难 数据共享体系架构：一种以数据存储服务器为中心，为客户软件提供数据共享、数据交换访问的软件架构风格。在数据共享体系架构中，各个客户软件相互独立，它们通过共享数据存储实现数据交换。一个客户软件对共享数据进行了修改，其他客户软件可以获得数据变更信息。 优点：体系架构简单开发容易；有效实现大量数据共享；客户软件独立执行缺点：共享数据结构发生变化，客户软件都要跟着变；共享数据性能压力大；一旦故障整个系统无法运行；分布式困难 事件驱动体系架构：基于事件与消息机制实现软件构件之间进行通信的软件架构。构件（子系统)之间并不直接交互，而是通过触发一个或多个事件，隐式调用另一构件执行。系统各构件需要在消息处理器中注册相关事件，一旦事件触发，将隐含调用注册构件进行处理，并将处理结果返回事件发布构件。 优点：可拓展性好，便于维护，耦合性低缺点：削弱了构件对系统的控制能力，不能高效解决数据交换问题 客户机/服务器体系架构（C/S架构和B/S架构）：一种典型的分布系统体系架构，其软件分为客户端构件和服务端构件，客户端构件通常在客户机上运行，服务端构件在服务器上运行。 C/S架构优点: 可实现分布式计算处理，有利于系统负载分担。交互性强、具有安全的存取模式、响应速度快、利于处理大量数据。 C/S架构缺点: 缺少通用性，系统维护、升级需要重新安装部署，增加了维护和管理的难度。只限于小型的局域网应用。 B/S架构优点: 分布性强——服务器可以在任何地点运行。访问方便——只要有网络、浏览器，就可以对系统应用进行访问。系统处理负载能力强——可以将负载分布在Web服务器、应用服务器、数据库服务器处理。此外，通过负载均衡、集群技术可以支持更大负载处理。系统运维方便——只需要在服务器进行功能修改与发布，即可实现所有用户访问的同步更新。用户共享性强——可以支持不同地点用户共享访问系统。 B/S架构缺点: 个性化处理、人机交互性能不如C/S架构软件。在系统安全性设计需要考虑更多内容。 微核体系架构：又称为“插件架构”，系统基本核心功能在软件内核中实现，其功能较少，系统大部分功能和业务逻辑都通过插件实现。 优点：良好的拓展性，插件之间是隔离的，可定制性高，可以渐进式开发缺点：伸缩性差不易分布式，开发难度高 微服务架构：面向服务架构( service-oriented architecture，SOA）的轻量级实现版本。 优点：拓展性好，容易部署，容易开发，易于测试缺点：服务可能会拆分得很细。这导致系统依赖大量的微服务，变得凌乱和笨重，性能不佳；分布式处理使得微服务较难实现原子性操作，交易回滚会比较困难。 软件架构模式软件架构模式就是针对特定需求问题及其环境，所给出通用的软件架构设计解决方案。软件架构模式相对软件架构风格，所涉及范围要窄些，解决更具体问题。 代理者模式 在代理者模式的软件架构中，需要使用代理者扮演客户端和服务端的中介角色。 代理者使得客户端不再需要知道某个服务在哪里，就可以获得这个服务，从而使得客户端可以方便地定位服务。
集中式控制模式 在集中式控制模式的软件架构中，中央控制构件按照特定对象状态机逻辑对系统全局行为进行控制操作。中央控制构件接收输入构件或用户界面构件的输入操作。中央控制构件根据输入事件引发的系统状态变迁，对相关部件实施操作控制，从而实现系统功能控制。 分布式控制模式 在分布式控制模式的软件架构中，系统控制分布在多个控制构件之中，不存在总控全局的单一构件。每个控制构件按照特定对象状态机逻辑对系统特定部分的行为进行控制操作。多个控制构件通过消息通信协作完成整个系统的控制处理。 多层控制模式 在多层控制模式的软件架构中，系统控制分布在多个控制构件之中，此外，通过协调者构件控制所有控制构件实现整个系统的控制。 协调者构件提供全局控制，而每个控制构件按照特定对象状态机逻辑对系统特定部分的行为进行控制操作。 协调者控件发布命令到各个控制构件执行控制操作，同时协调者控件也从控制构件接收状态消息。
抽象分层模式 在抽象分层模式的软件架构中，复杂的软件构件关系被抽象到不同的功能层次。每个层次构件只能访问它的相邻下层服务同时也只对相邻的上层提供服务。相邻上下层次构件之间通过请求调用访问、返回响应消息方式进行交互实现系统功能处理。 多客户/单服务模式 在多客户/单服务模式的软件架构中，软件构件被部署到多个客户端结点和一个服务端结点。各客户端结点的软件构件通过网络连接访问服务端结点上运行的服务。在本模式下，多个客户端构件可并发向一个服务端构件提出服务请求，服务端构件一次将处理结果返回给请求的客户端构件。 多客户/多服务模式 在多客户/多服务模式的软件架构中，软件构件被部署到多个客户端结点和多个服务端结点上运行。客户端构件通过网络连接访问多个服务器结点上运行的服务。在本模式下，多个客户端构件可并发向多个服务端构件提出服务请求，服务端构件各自将处理结果返回给请求的客户端构件。 多层客户/服务模式 在多层客户/服务模式的软件架构中，除了基本的客户端层次和服务端层次外，还有一个同时扮演客户端角色和服务端角色的中间层。中间层对于它的服务层而言是一个客户端，但对其他客户端而言又是一个服务端。客户端、中间层、服务端的结点通过网络进行通信，支持多个客户端构件向服务端构件提出服务请求，服务端构件将处理结果返回给请求的客户端构件。 软件架构通信模式关注构件之间通信的方式。典型的软件架构通信模式如下: 调用/返回模式异步消息通信模式、同步消息通信模式服务注册、转发、发现模式广播/组播模式软件架构事务模式关注构件之间的事务处理，以确保业务数据完整性。典型的软件架构事务模式如下: 两阶段提交协议模式复合事务模式长事务模式软件架构模式与软件架构风格有何区别? 软件架构模式强调解决某种特定场景、特定问题的架构模式，而软件架构风格强调解决某一类型问题的架构表现方式，是概念层面上的、抽象的。 代理者模式如何解决客户端透明访问服务的问题? 代理者扮演客户端和服务端的中介角色，使客户端不再需要知道某个服务在哪里就可以获得这个服务，从而实现客户端透明访问服务 集中式控制模式与分布式控制模式各有哪些优缺点? 集中式控制模式：简单好管理，一致性高，成本低，但是有单点故障风险，可拓展性差。 分布式控制模式：容错性强，可拓展性好，但是复杂，成本高，一致性不好保障。 哪种通信模式的软件架构适合高并发访问系统? 异步消息通信模式、服务注册、转发、发现通信模式 软件架构UML建模设计 UML设计类图：在面向对象系统设计中，采用UML设计类图模型将软件系统的类程序组成静态结构可视化呈现出来。UML包图：针对各个子系统，分别给出它们的类图设计，但在高层设计中采用UML包图对系统的软件静态结构进行抽象设计。通信图/顺序图：在UML软件建模设计中，可以采用交互图（通信图或顺序图）描述软件对象之间的协作通信，从而反映对象之间通过动态消息交互行为实现系统功能。软件架构的物理结构模型：软件架构的物理结构模型用于反映软件系统架构的实现方案。在面向对象系统设计中，软件架构采用UML构件图和UML部署图表示系统物理结构实现方案。 第六章上 软件建模详细设计 软件建模详细设计原则 开闭原则：软件实体（类、构件等）应该对功能扩展具有开放性，对代码修改具有封闭性。当应用需求改变时，在不修改软件实体源代码的前提下，就可以扩展模块的功能，使其满足新的需求。里氏替换原则：子类可以扩展基类的功能，但不能改变基类原有的功能。子类在继承基类时，除了添加新的方法且完成新增功能外，不要重写基类的方法代码。子类必须遵守基类与外部类之间的隐含约定。依赖倒置原则：基于抽象类编程，不依赖具体类编程。面向接口编程，不要面向实现编程。接口分离原则：一个构件对外应提供不同服务的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的构件去调用，避免客户端依赖不必要的接口方法。提供者构件应该为每个不同访问构件类型提供一个特定的接口。 单一职责原则：一个类应该有且仅有一个功能职责，否则该类应该被拆分。单一职责原则的核心就是控制类的粒度大小，将对象解耦，提高其内聚性。最少知识原则：迪米特法则的定义是:只与你的朋友交谈，不跟“陌生人”说话。在程序设计中，如果两个软件实体没有直接关系，那么就个直接调用，可以通过第三方转发该调用。高内聚原则松耦合原则可重用原则
UML软件静态结构视图建模
类的聚合关系细分： 专属聚合：依赖性、传递性、非对称性、固定性从属聚合：依赖性、传递性、非对称性拥有聚合：传递性、非对称性成员聚合：四个性质都不存在，仅仅是将一组对象组合在一起实现继承： 拓展继承：子类组合来自超类的特征，并增加新的特征限制继承：子类组合来自超类的特征，并重载部分继承来的特征方便继承：某些类之间具有一定相似的实现，但它们之间不存在泛化关系，即没有概念上的分类关系。方便继承是指将它们中一个类作为其它类的超类。高级类图建模： 可见性： + public公共可见性:该元素对任何类都可见- private私有可见性:该元素只对本类可见;# protected保护可见性:该元素对本类及子类可见;~ package包可见性:该元素对同一包中的元素可见。 导出信息限定关联关联类与具体化类接口与抽象类： 接口用于定义一个类或者构件的功能操作函数集。如果接口使用构造型标签表示，实现关系线是一条末端带有空心三角的虚线，箭头指向接口，虚线上可以加上构造型关键字《implement》。抽象类指不具有实例的类，它通常作为父类，不创建实例对象。抽象类的子类可以实例化。抽象类一般至少有一个抽象操作。抽象类的作用是为其子类描述它们的公共属性和行为。UML采用斜体表示抽象类的名称，也可以可使用{abstract}约束来表示。类内聚与耦合： 类耦合的种类： X包含Y，或者X有一个属性指向Y的一个实例X有一个方法引用了Y的一个实例，如:X使用一个Y类型的局部变量;或者返回Y类型的对象X调用Y的服务X是Y的直接或间接子类X类具有一个输入参数为Y类实例的对象Y类是一个接口，而X类实现了该接口 类之间6种关系的耦合强度依次增强：依赖 |
【本文地址】
今日新闻 |
推荐新闻 |