软件体系结构的发展

软件架构发展历史

1. 60年代
   计算机领域经过发展，到达第三代语言结合商业应用的阶段
   这样进行了十年，到了60年代末的时候，爆发了软件危机，开了NATO会议
   此次会议中，没有明确提出架构的定义，但是谈到了好多架构的朴素观点，今天看来依旧是很好的想法
2. 80年代末之前
   80年代末之前，架构多指物理架构，架构的概念还没有过多应用于软件领域
   1975到1986，Brooks、Lampson、Parnas等开始研究软件系统的组织，并发表研究成果
3. 1992年
   Perry和Wolf发表了文章，明去定义了软件架构的定义和概念，这是真正对软件架构有了清晰定义
   Perry文章里提出公式：{element, forms, rationale} = software architeture（软件架构基本元素（即指部件和连接件），构件方法，构建理由组合构成软件架构）；Barry Boehm又增加了constraints（限制条件）进入公式
   提出定义后，人们热衷于用形式化方法表述软件架构框架，火了一段时间，但是没有在工业界得到广泛应用
4. 图示——软件体系结构的十年(by Kruchten)
   
5. 图示——软件体系结构的黄金发展年代(by Shaw)
   
   这是体系结构的历史示意图
   由上到下：
   基础工作(Foundations)：信息隐藏，抽象数据类型，对质量的度量标准
   基础研究(Basic Researchs)：系统结构，风格分类
   概念提出(Concept Formulation)：架构描述语言，视角，体系结构评估等
   大量发展：专业术语，形成规范
   内在增强：开始提炼出架构模式，总结形式化方法等
   对外在的软件工程产生影响
   标准化、产业化

软件架构的重要性

1. 架构是高复杂度的、大规模的、高交互性的系统的关键连接部位
2. 使用架构的基本原因
   架构是共同交流的器件
   架构有助于做出好的早期设计决策（前期决策做得好，后面出错的代价就小，故很重要）
   架构是一种对系统的抽象表征，能降低复杂度，易于理解
   架构时可转换的（意为可从架构过渡到后面的内容如详细设计）

理解软件体系结构

概念和定义

1. Kruchten的定义
   软件架构包括：
   the structure and organisation by which modern system components and subsystems interact to form systems, and the properties of systems that can best be designed and analysed at the system level
   软件系统的组织
   组合成系统的结构化的元素和他们的接口，这种呢结合使元素们形成更大的系统
   组成系统的整体的指导性的架构风格
   软件架构不只与结构与行为有关，也与用途、功能、性能、弹性、重用性、可理解性、经济因素、技术限制和美学因素等有关
2. Shaw的定义
   软件体系结构 = {部件(Component)，连接件(Connector)，配置(Configuration)}
   部件是软件体系结构的基本组成单位之一，承载系统的主要功能，包括处理与数据
   连接件是软件体系结构的另一个基本组成单位，定义了部件之间的交互，是连接的抽象表示
   配置是对形式的发展，定义了部件以及连接件之间的关联方式，将它们组织成系统的总体结构
   一个简洁的软件体系结构定义：一个软件系统的体系结构规定了系统的计算部件和部件之间的交互
3. Perry的定义
   Software Architecture = {Elements, Form, Rationale)
   elements - what
   form - how
   rationale - why
   Process + Data + Connection
4. Wiki的定义
   软件架构设计主要考虑非功能需求，软件详细设计主要考虑功能性需求
   任何一种非功能属性都会影响架构，如秒杀购买和普通购买
5. 总结
   软件架构是一种高级抽象，代表从逻辑上对组织的思考（降低复杂性表示系统，可以逐渐化为系统的具体实现）
   软件架构是利益相关人等关注点（不同的利益相关有不同的关注点），不同人从不同角度看设计——多视角来表达高层抽象
   软件架构是一系列设计决策（早期设计决策）：每个决策都对后面的影响很深远，不容易修改；如果软件架构（早期决策）没做好，后面可能都没法写；如如果将秒杀系统与普通购买系统一起写，可能导致将普通购买系统挤崩溃；每个决策都一定要有理由，便于评判

区分物理和逻辑

1. 物理与逻辑
   高层与低层、抽象与实现
   逻辑层比物理层更高层

2. 举例
   从A地到B地，逻辑上是从A到B，中间过程具体怎么走是物理实现
   系统中物理上只有一块硬盘，C盘、D盘等概念是逻辑盘

3. 概念的、逻辑的、物理的
   概念的：只含有实体的名字和他们的关系
   逻辑的：在概念的基础之上，丰富了属性、主键、外键
   物理的：在逻辑的基础上，增加了表名、每一列的字段名称、类型等具体信息
   概念的、逻辑的、物理的，从简单到复杂，从高抽象到低抽象
   先有高层抽象
   例如数据库设计就涉及概念模型、逻辑模型、物理模型
   数据库设计中的三种模型及他们中的元素图例
   
   

4. 模块操作的逻辑表达和物理实现

   逻辑表达	物理实现
   一个模块调用另一个模块	接口调用（再加上如何传递数据对象的考虑）
   一个模块给另一个模块传递数据流	读写共享数据、pipe等

5. 物理实现的载体
   物理实现也是分层实现的
   低层：基本类型 + 基本控制结构
   中层：（以OO编程语言机制为例）类声明、实例创建与撤销、实例生命期管理；类权限控制机制；复杂机制：继承等
   高层：导入导出和名称匹配（详细见下）

6. 导入导出机制
   
   “一个模块依赖另一个模块”、“一个包依赖另一个包”

   A import B
   

   代表逻辑上的依赖关系
   实现时，为了知道具体是哪个包的哪个类，要进行名称匹配；匹配好类后，又要看是哪个类的哪个方法——实现过程也是物理上的逐层细化

7. 抽象与实现
   举例：一个方法，输入数据流，输出结果中将原来的大写字母转化为小写字母，将原来的小写字母转化为大写字母
   抽象图示
   
   实现图示
   
   逻辑上四个模块，这是逻辑上、概念上的模块，功能的的组织和描述
   逻辑上的模块是设计架构，展示的是功能
   实现视角中，增加配置和IO等模块，实现视角的模块能转化成代码，实现视角更接近代码
   抽象架构代表功能、实现机制为了生成代码
   画图时要先画出逻辑上的上层设计图（抽象的那个），再画出下层的实现视角，最后转换成代码

高层抽象

概述

1. 图示
   
2. 部件是系统计算和状态的聚焦点，连接件是部件之间关系
3. 软件体系结构设计是高层抽象，故在谈某个部件时就不需要纠结他到底是类还是模块还是别的什么
4. 连接件是一个与部件平等的单位
5. 部件与连接件是比类模块等软件单位更高层次的抽象
   部件与连接件可以是类，也可以是模块，也可以是类与模块的某种组织；谈高层的部件不用纠结抽象内部具体是什么，如何实现是后面的事
6. 图（如结构图）在绘制的时候，缺少对连接件的详述（连接件往往只是一条线）；而在高层抽象中，连接件是与部件平等的单位

部件

1. 部件分为规格部分与实现部分
   
   端口：交互接口的一系列方法组合（接口即规格）
2. 原始部件和复合部件
   两种类型的部件
   原始类型的部件可以直接被实现为相应的软件实现机制
   复合部件则由更细粒度的部件和连接件组成，复合部件通过局部配置将其内部的部件和连接件连接起来，构成一个整体
3. 原始部件常用的软件实现机制（部件有可能是……）
   
   高层观察的不管实现内部是什么，他关注的是如何交互
4. 例子中的部件定义

      Component Type Split = {//端口名称Port othersC;port alternateC;};Component Type Upper = {Port originalC;Port upperedC;};Component Type Lower = {Port originalC;Port loweredC;};Component Type Merge = {Port upperedAlternateC;Port loweredOthersC;};
   

连接件

1. 连接件负责component之间的交互
2. 连接件同样分为规格与实现两部分
   
3. 原始连接件与复合连接件
   原始类型的连接件可以直接被实现为相应的软件实现机制
   复合连接件由更细粒度的部件和连接件组成，符合连接件通过局部配置将其内部的部件和连接件连接起来，构成一个整体
4. 原始连接件常用的软件实现机制
   
   高层抽象：直到他能够调用就好，具体怎么实现、什么流程不用现阶段管
   适配器：做接口的转化，如出国后的插头
   委托：想做一个事情，并不需要知道怎样完成任务，将他交给一个人，委托他来完成
   中介：帮忙交流
   显式连接件：自己用代码写来的
5. 例子中的连接件定义（对应上例，四个管子相同）

     Connector Type Pipe = {Role source;Role destination;};
   

配置

1. 配置描述了如何将连接件与部件连接在一起
   配置图示
   
   部件的接口：端口；连接件的接口：角色
   连接时，端口与角色配对连接
   配置决定谁与谁配上，以描述结构
2. 例子中的配置定义

   System Capitalize = {Component split:Split;Component upper:Upper;Component lower:Lower;Component merge:Merge;Connector{stou:Pipe;stol:Pipe;utom:Pipe;ltom:Pipe;}Attachments = {split.alternateC to stou.source;split.othersC to stol.source;upper.originalC to stou.destination;lower.originalC to stol.destination;upper.upperedC to utom.source;lower.loweredC to ltom.source;merge.upperedAlternateC to utom.destination;merge.loweredAlternateC to ltom.destination;};
   };
   

3. Wright语言描述体系结构
   Wright是一个体系结构描述语言
   
4. CSP语言描述体系结构
   CSP是一个体系结构描述语言
   

高层抽象的好处

1. 直观，便于理解：复杂的东西被逻辑上简单的东西表示出来
2. 能一定程度上验证正确性：能看出来能否实现，有利于交互（沟通）
3. 关注度分离，降低复杂度
   如rPC是一个很复杂的过程，有时甚至会设计自己定义的机制和协议，但这些细节之需要做rPC的人知道就行了

体系结构风格初步

主程序、子程序风格

概述

1. 图示
   
   是一个树形结构
2. 成分
   部件：过程、方法、模块
   连接件：过程、方法、模块之间的调用

设计决策与约束

1. 基于声明-使用（程序调用）关系建立连接件，以层次分解的方式建立系统部件，共同组成层次结构
2. 每个上层部件可以使用下层部件，但是下层部件不能使用上层部件，即不允许逆方向调用（否则会形成循环调用）
3. 系统应该是单线程执行：主程序部件拥有最初的执行控制权，并在使用中将控制权转移给下层子程序（同步调用，调用就涉及控制权转移）
4. 子程序只能通过上层转移来获得控制权，可以在执行中将控制权转交给下层的子子程序，并在自身执行完成后必须将控制权交还给上层部件

实现

1. 功能分解（按功能分解）
2. 集中控制
3. 每个构建一个模块实现（主要是单向依赖）
4. 使用utility或tools等基础模块

效果

1. 优点
   流程清晰，易于理解
   强控制性
2. 缺点
   程序调动是一种强耦合的连接方式，非常依赖交互方的接口规格，这会使得系统难以修改和复用
   程序调用的连接方式限制了各部件之间的数据交互，可能会使得不同部件使用隐含的共享数据交流，产生不必要的公共耦合，进而破坏他的正确性控制能力
   注：完全靠模块的I/O形成流：没有共享空间，但是效率可能低（每次用到同层次功能都需要将控制权交还到更高层）；可以开辟共享空间，大家一起用这块空间，提升效率，但是增加耦合

应用

1. 主程序、子程序风格主要用于能够将系统功能依层次分解为多个顺序执行步骤的系统
2. 很多受到限制的编程语言的环境下，这些编程语言没有模块化支持，系统通常也会用主程序、子程序风格，实现是程序实现，即主程序和子程序都被实现为单独程序（没有模块化，用方法来做）
3. 一些使用结构化方法（自顶向下或自底向上）建立的软件系统也属于主程序、子程序风格

面向对象风格

概述

1. 图示
   
2. 成分
   部件：对象、模块
   连接件：方法调用
3. 注意：编程范式是语言层面上讲如何交互；这里软件体系结构风格是架构岑面上（更高层抽象），思想类似，有时可能恰好对应上（如某部件恰好在实现时对应到了一个方法），但这是后话，本阶段依旧是高层

设计决策及约束

1. 依照对数据的使用情况，，用信息内聚的标准，为系统建立对象部件；每个对象部件基于内部数据提供对外服务接口，并隐藏内部数据的表示
2. 基于方法调用机制建立连接件，将对象部件连接起来
3. 每个对象负责维护其自身数据的一致性与完整性，并以此为基础对外提供正确的服务
4. 每个对象都是一个自治单位，不同对象之间是平级的，没有主次、从属、层次、分解等关系
   主程序、子程序关系中的树状结构就不是平等关系
   自治单位之间连接时复杂的（每个部件简单，复杂性转移到连接上去了）

实现

1. 任务分解：（委托式）分散式控制
2. 每个构建一个模块实现
   使用接口将双向依赖转换为单向依赖
   将每个构建分割为多个模块，以保证单向依赖
   每个模块内部可以是基于面向对象方法，也可以是基于结构化（内部如何自定）
3. 使用utility或tools等基础模块

效果

1. 优点
   内部实现的可修改性
   易开发、易理解、易复用的结构组织
2. 缺点
   接口的耦合性
   标识的耦合性
   副作用
       面向对象式风格借鉴了面向对象的思想，也引入了面向对象的副作用：例如，如果A和B都使用对象C，那么B对C的修改可能会对A产生未预期的影响；再如，对象的重入问题：如果A的方法f()调用了B的方法p()，而p()又调用了A的另一方法q()，那么就可能使得q()失败，因为在q()开始执行时，A正处于f()留下的执行现场，这个现场可能是数据不一致的
   注：可重入：一个方法被调用时也可同时被另一方法调用
   对于第一个问题，一般要做好封装，防止互相影响

应用

1. 面向对象式风格适用于那些能够基于数据信息分解和组织的软件系统，这些系统：
   主要问题是标识和保护相关的数据信息
   能构建数据信息和相关操作联系起来，进行封装
2. 实现中，基于抽象数据类型建立的软件系统大多属于面向对象式风格（能封装的东西）

分层风格

概述

1. 图示
   
2. 成分
   部件：典型部件是过程或对象的集合
   连接件：限制可见性下的方法调用
3. 分层风格
   低层——内核：执行最基础指令，提供一些库和包给上层调用；内核之上是业务层程序
   中层——工具
   高层——应用
   用户直接与应用层交互
   电脑软件就是典型的分层结构：最核心的kernel是操作系统

设计决策与约束

1. 从最底层到最高层，部件的抽象层次逐渐提升；每个下层为邻接上层提供服务，每个上层将邻接下层当作基础设施使用；即程序调用机制中上层调用邻接下层
2. 两个层次之间的连接要遵守特定的交互协议，该交互协议应该是成熟、稳定和标准化的；即只要遵循协议，不同部件实例之间是可以互相替换的；接口即协议（协议不稳定会有严重问题）
   成熟稳定标准化是对分层协议的要求，看层之间是否有这样的的协议；只有协议稳定，不易改变，这样层间调用时不容易产生版本问题；如果底下的东西总是改动，对上层应用很不好（如对操作系统来说，应用与内层内核交互规则是稳定的，core一般不太更新）
   层次之间接口协议不变，遵从协议的条件下就可以换不同的部件实例实现
   如，大家都知道网络协议，设备们都知道统一协议；但是设备里如何实现，华为、中兴……各厂商的方案各自如何都不重要，方案只是符合协议要求的不同实现
3. 经典、严格的分层风格中，跨层次的连接是禁止的
4. 逆向的连接是禁止的，否则形成环路，修改时会产生连锁反应
5. 决定是否使用分层风格要看是否容易或能够产生这份协议

实现

1. 关注点分离（每层逐次抽象），不同层次上只要考虑本层的东西就好
2. 层间接口使用固定协议（固定控制），这样每一层的作用与功能就固定了下来，实现起来方便
3. 每层一或多个模块实现
   要保证单向依赖
   层间数据传递建立专门模块，（数据传递的模块在层间共享）
4. 使用utility或tools等基础模块

效果

1. 优点
   设计机制清晰，易于理解——每层只管自己就好
   支持并行开发——经典分层（展示层：界面、人机交互等；逻辑层：业务逻辑；数据层：处理数据、持久化等）的开发中，三种人员知识背景不同，工作方式不同，大团队中常常将三类人员分成不同小组工作，三拨人能够并行开发
   更好的可复用性和内部可修改性——接口确定后，实现可以替换（只要遵从协议）（可重用性高）；底层修改时对上层影响不大（可修改性高）
2. 缺点
   交互协议难以修改版（难以确定、推进、修改和开发代价大）
   性能损失——只能调用相邻下层，每跨一层难以估量经过了多少个实体、多少个方法
   难以确定层次数量和粒度

应用

1. 分层风格适用于
   主要功能是能够在不同抽象层次上进行任务分解的复杂处理（即概念逻辑上就有这种明显的分层）
   能够建立不同抽象层次之间的稳定交互协议
   没有很高的实时性能要求，能够容忍少许延迟（如嵌入式系统这种实时性要求高的系统就不会使用分层风格来做）
2. 此外，那些需要进行并行开发的软件系统也可能会使用分层风格，以便于任务分配和工作开展；在现有的系统中，分层风格是一种经常被用到的体系结构风格，像网络通信、交互等
3. 系统、硬件控制系统、系统平台等都会使用分层风格（如ISO网络通信模型、TCP/IP的网络通信模型都使用了分层风格）

MVC风格

概述

1. 图示
   
2. 角色
   View：展示信息；接受用户动作（并交给Controller）
   Controller：控制器，包含跳转逻辑，负责分派、转发；改变Model的状态（将收来的用户动作映射到Model的某个状态改变）；选择View来做响应
   Model：模型，业务逻辑与数据处理；维护领域知识，通知View数据变更
   图中的爪爪代表交互，圆形头的是供接口，给别人提供功能用的；半圆的爪是需接口，调用别人功能的
3. 运作机制
   点开界面(View)，如改动一个数据，View模块就要调用Controller的接口(User Gesture)——用户动作就被View接受，传给Controller以待后续
   之后，Controller调用Model的接口(State Change)，操纵Model进行状态改变
   Model再和View交互（观察者模式）
   有时会有更换View页面的行为（如用户操控View，行为内容为换个界面，传到Controller后，Controller直接调用View Selection接口让View进行改变）
4. View与Model之间的观察者模式
   观察者模式比轮询更加有效
   效果：View观察Model是否有变化，有变化时，Model会调用View的接口(Change Notification)来通知改变
   建立：Model为被观察者，View为观察者
   View向Model进行注册“我对你感兴趣”（注册时顺便告知Model如果真的发生改变，Model该调用哪个方法告知View）——>Model的数据发生改变后，告知View(Change Notification)——>View知道Model中数据发生改变后，从Model把新数据拿来显示（通过State Query接口）
5. 与经典三层分层风格不同，这个两两之间都有交互
6. 部件：Model，View，Controller
7. 连接件：方法调用
   View与Controller方法调用、View与Model的观察者模式：方法调用、消息、事件；Controller调用Model：方法调用

设计决策和约束

1. 模型、视图、控制分别是关于业务逻辑、表现和控制的三种不同内容的抽象
2. 如果视图需要持续地显示某个数据的状态，他首先需要在模型中注册对该数据的兴趣，如果该数据状态发生了变更，模型会主动通知时图，然后再由视图查询数据的更新情况
3. 视图只能使用模型的数据查询服务，只有控制部件可以调用可能修改模型状态的程序（只读）
4. 用户行为虽然由视图发起，但是必须转交给控制部件处理；对接收到的用户行为，控制部件可能会执行两种处理中的一种或两种：调用模型的服务，执行业务逻辑；提供下一个业务展现（界面跳转，View改变）
5. 模型部件相互独立，既不依赖于视图也不依赖于控制；虽然模型于视图之间存在一个“通知变更”的连接，当该连接的交互协议是非常稳定的，可以认为是非常弱的依赖
   调用别人就是依赖别人
   View与Controller相互可调用；Controller可调用Model，逆向不行；View与Model，基本只是View调用Model（取数据），通知消息那个是Model调用View，但是联系很弱
   Model受外界干扰小，稳定

实现

1. MVC风格需要为Model、View、Controller的每个部件实例建立模块实现，各模块间存在导入/导出关系，程序调用连接件不需要显示的实现（因为他们是方法调用和消息传递）
2. 特定技术实现，通常专用于Web（实现时，每个部件可能有相应模块——会存在导入/导出关系，MVC早期常用桌面应用/CS结构程序（本地）的MVC，后来概念被引入Web）
   Model与Controller单向
   Controller与View双向
   Model与View双向
   注：Web是浏览器与服务器之间的交互，在浏览器上的动作（如输入网址、点击链接等）相当于对服务器等请求（GET、POST等）；服务器端：请求过来以后先判定一下是什么请求（根据协议判定），判别出来要做什么事，之后交给相应的处理对戏那个(Servlet)（相当于Controller，负责要做的事情）；Servlet控制别人完成任务得到结果后，生成一个前端元素传回浏览器——以View等形式展示
3. 典型实现
   View：JSP，HTML
   Controller：Servlet
   Model：JavaBean（包含数据处理和业务逻辑）

效果

1. 优点
   易开发性，视图和控制的可修改性（模型被大家依赖，不易修改）
   模型封装了系统的业务逻辑，所以是三种类型中最为复杂的系统部件；MVC中模型是相对独立的，所以对视图实现和控制实现的修改不会影响到模型实现；再考虑到业务逻辑通常比业务表现和控制逻辑更加稳定，所以MVC有一定的可修改性优势
   适宜于网络开发；MVC不仅允许视图和控制的可修改性，而且其对业务逻辑、表现和控制的分离使得一个模型可以同时建立并保持多个视图，这非常适用于网络系统开发
2. 缺点
   复杂性：MVC将用户任务分解成了表现、控制和模型三个部分，增加了系统的复杂度，不利于理解任务实现
   模型修改困难

应用

1. 适用于用户界面经常修改（甚至时时修改）的系统，界面与数据绑定很好，时时修改时，修改之处很快就能在界面中显示出来（如Web应用）

分层与MVC两种风格的对比

1. 对比
   
   注：HTTP：浏览器向服务器发送单向请求（而不能服务器向浏览器发送请求），单向下，难以进行逻辑层与展示层的数据传递
2. 连锁超市系统的体系结构风格方案图示对比
   分层结构
   
   MVC结构风格
   
   注：客户端本身就有MVC，保证客户端的Model与远端（服务器）的Model同步即可

观察者模式

1. 图示（左为静态模型，右为动态模型）
   
2. 方法调用细节
   attach()-表示产生兴趣的方法
   detach()-取消兴趣的方法
   notify()-通知变动方法——在已经跟自己注册的所有observer遍历（因为每个人的update()都不同（每个人感兴趣不同的数据））这样，自己如果有变动，每个人都通知到

[课业] 18 | 软工 | 软件体系结构基础相关推荐

1. [课业] 19 | 软工 | 软件体系结构设计与构建

   文章目录 体系结构设计 体系结构设计过程 分析关键需求和项目约束 选择体系结构风格 进行软件体系结构逻辑设计(抽象) 依据概要功能需求与体系结构风格建立初始设计 概述 实践案例 使用非功能性需求与项目 ...

2. 软考软件设计师基础知识—法律法规知识

   软考软件设计师基础知识-法律法规知识 视频的地址: https://open.163.com/newview/movie/free?pid=GETVIB0OT&mid=JETVSHAMA 保护 ...

3. 软件体系结构---基础知识点（3）

   第3章 软件体系结构风格 概述 定义: 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式. 体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束. 词汇表中包含一些构件 ...

4. 软件体系结构---基础知识点（2）

   第二章 软件体系结构建模 软件体系结构建模的种类 软件体系结构是具有一定形式的结构化元素,即构件的集合,包括处理构件.数据构件和连接构件. 结构模型 结构模型的核心是体系结构描述语言 框架模型 框架模 ...

5. [课业] 09 | 软工 | 软件工程的发展

   文章目录 软件工程的三个环境因素 综述 Before 1950's 1950's 1960's 1970's 1980's 1990's 2000's 2010's later Summary 软件工 ...

6. 北航软工-软件案例分析-IT问答平台

   项目 内容 这个作业属于哪个课程 2023 年北航软件工程 这个作业的要求在哪里 个人作业-软件案例分析 我在这个课程的目标是 学习软件开发方法,了解并实践一些软件工程的方法论和工具,积累以结对编程和 ...

7. [课业] 13 | 软工 | 需求基础

   文章目录 需求工程 需求的问题 概述 需求开发 需求开发过程模型 需求获取 需求分析 需求规格说明 需求验证 需求管理 需求基础 什么是需求 概述 & 需求开发的目标 需求开发目标各元素 需求 ...

8. 软件体系结构---基础知识点（5）

   第5章 统一建模语言 常用的静态图:用例图.类图.包图.对象图.部署图 常用的动态图:顺序图,通信图,状态机图,活动图 5.1 UML概述 ◇ UML简介 UML是用于系统的可视化建模语言,通常与OO ...

9. 18软工实践 - 第七次作业 - 需求分析报告

   目录 组队后的团队项目的整体计划安排 项目logo及思维导图 项目logo 思维导图 产品思维导图 产品思维导图-引导 产品思维导图-后端数据处理.存储 产品思维导图-短信识别 产品思维导图-智能分析 ...

最新文章

1. Windows® CE 系统中的同步机制
2. Leetcode: Kth Largest Element in an Array
3. apache-maven仓库配置
4. Excel连接到MySQL，将Excel数据导入MySql，MySQL for Excel，，
5. spss 安装包以及许可证
6. idea中XML注释与取消注释快捷键
7. TCP和UDP的区别与联系
8. linux系统下的打印机驱动下载,用于UNIXLinux系统的打印机驱动程序-Lexmark.PDF
9. php底部漂浮广告位代码,网站顶部底部（上下）悬浮（漂浮）广告位代码
10. 电机FOC电流环参数整定
11. 【电机原理与拖动基础】Unit 2 直流电机的电力拖动系统
12. HDMI调试基本原理
13. Unity 3D项目-Adventure of JM Robot
14. 程序员技术入股的那些坑！保护好你的核心技术，想走？没那么容易！
15. bsl计算机术语,一种BSL的确定方法、BIER-TE控制器和计算机存储介质与流程
16. 硬盘安装linux镜像文件iso安装,通过ISO文件硬盘安装Ubuntu系统
17. CSS3 设置模糊背景图片
18. Vue3初识 学习记录(一)
19. github.com连接超时 ping不通
20. 华师大 OJ 2876

热门文章

1. 【扫描线法】 poj 1177 hdu 1828
2. 字符串取出年，月，日
3. 下载和使用TPXO9_atlas
4. 信奥赛和少儿编程的区别
5. 精密整流电路（AD630）
6. HTML5生日祝福蛋糕页面(生日蛋糕树) HTML+CSS+JS 求婚 html生日快乐祝福代码网页 520情人节告白代码 程序员表白源码 抖音3D旋转相册 js烟花代码 css爱心
7. Freeline秒速编译Android项目详细安卓配置流程
8. 【python实现生成隐藏的一句话木马】
9. 蓝桥杯-c语言 高僧斗法
10. 【NDN IoT】Challenges in IoT Networking via TCP/IP Architecture 全文翻译