软件架构

总览：

架构作用：组成和决策

方法：物理逻辑数据开发运行

过程：需求分析领域建模确定关键需求概念架构设计（关键需求解决策略）细化架构（5视图）验证架构

个人技能：编码设计UML工具软件过程

比如解耦合，依赖关系角色理论设计模式

 

 

架构思想：组成+决策

领域模型：概念抽象+关系抽象| （业务）目标+用户（用例）+行为（流程）

模块划分：水平+垂直（EDD，功能模块+分层 - >细粒度 - >用例）| 自底向上（用例驱动，内外对话 - >内部协作，用例 - >鲁棒 - >时序 - >模块）

参与角色：用户客户开发管理

缘由（一下想清） - >思想（分治+迭代） - >方法（逻辑+物理） - >案例（拉出工程）

 

软件架构：3原则6步骤

需求分析：三横是顺序的方法，两纵是持续的观念| 需求就是不断交替，彼此印证的过程性的事情

领域建模： 原理=> 过程  =>内容 + 方法  + 实现

关键需求：预见->权衡->折衷

概念架构：目标->设计->选型

细化架构：5视图（组件+交互）

架构验证：验证内容+方法

 

 

 

概念思想：组件划分和交互 (组成)| 组件关系和依赖（决策）

架构=组件+交互（mvc）

架构设计，模块切分类决策 和 技术选型类决策

-------------------------------------------------------------------

架构细化(SOA)，软件是由组件递归组合而成的

组件（交互）=原子组件+复合组件（框架 子系统 系统 ...）

 

领域建模，理顺概念关系，搞清业务规则，通过概念抽象和关系抽象建立模型

需求实践论，

需求工作项（业务目标 用例图  用例规约+流程建模）

提交的文档（目标列表 需求规格/用例模型+流程模型） 

所处需求层次（业务 用户 行为）

 

概念架构：1个决定（划分顶级子系统），4个选型（架构风格 开发技术 集成技术 二次开发技术）

需求分析，

高层需求分析（系统目标 需求范围  特性 上下文图）

需求分析：流程 功能（用例）  非功能

概念性架构设计：切分顶级子系统，明确关键需求（架构风格，顶级子系统构成，3大选型）

细化架构设计，前端 后端  API 插件 

 

模块划分方法，

水平，分层

垂直，功能模块，功能树

用例到类，再到模块（用例驱动，类分组，自底向上）

 

架构视图化，为用户设计

客户  不等于  最终用户

客户（理解难易度） 用户（使用难易度） 开发（开发难易度） 软件经理（管理难易度）

 

缘由，架构师不可能 一下子 想清楚

思想：分而治之（大->小）+迭代设计（已知->未知）

方法：逻辑（类 方法 接口）+物理（服务 数据 并发）

 

案例：邮件转发 

 

用例图：客户系统（提交邮件 反馈结果） 管理员系统（设置规则 和 地址 ） 定时器（发邮件） 邮件转发器（发邮件）

 

逻辑架构：用户交互+系统交互 业务逻辑 数据访问

物理架构：客户系统+管理工作站  转发服务器 数据库服务器

 

迭代（软件单元和硬件机器映射关系）

 

逻辑--

用户交互（设置地址 设置规则） + 系统交互（代理模块 Mail Server）

业务逻辑：调度 设置地址 设置规则 发送 反馈

数据访问 设置信息读写 邮件信息读写 发送结果信息读写

 

3个工程（包含的程序单元）

客户系统代理    管理员web应用 

            服务器软件

 

物理--

 

客户系统 Api

                         转发服务器 Server           数据库服务器 DB

管理工作站 Web

 

说明，多视图 不等于 多阶段，避免对某个模块一下过于深入，逻辑和物理本身就是不断相互验证 和 促进设计优化的过程 

 

 

 

3原则和6步骤：

1.看透需求：需求

需求（重大 特色 风险 | 全面 矛盾 追溯 | 功能 质量 约束）

两纵（功能 非功能）三横（目标—范围 feature 上下文 -用例模型）

+

领域模型(业务决定功能 功能决定模型)

写出业务目标  ==> 给出功能范围（现在的功能和未来的功能） 层级关系 和 用户交互逻辑  ==>建立用例模型

 

 

2.架构方向：高层架构

关键需求 功能+质量+约束==>关键功能+关键质量

+

概念架构 关键功能和质量==>鲁棒图+目标 场景 决策==>概念架构（划分子系统 | 架构风格  开发技术 集成技术 二次开发技术）

 

3.设计架构：架构设计

细化架构 不只是关键需求，而是所包括的需求，按照概念架构开始，逻辑的领域和数据的存储收在领域指导下进行

逻辑   模块  接口   领域

开发   技术  文件   编译

运行   技术  流程   同步

物理   硬件  部署   方案

数据   技术  存储   数据

+

架构原型 规避风险，尽早开发出来，尽早地验证它 

 

 

 

 

需求分析：交替进行（问题->解决->衍生问题-> … ...）

 

+用例图,

需求捕获（用户需求：用例图+用例简述）  全面

需求分析（行为需求：用例规约）               细致，可推后细化，待用户需求明确了后（需求沟通 需求启发  需求验证）

系统分析（初步设计：鲁棒图） 

 

+流程图，拿出单独的一项，判断粒度大小，粒度足够小了，判断全IT 半IIT 还是用户，如果需要IT系统协助，加入到用例图中，

 

 

 

三横是顺序的方法，两纵是持续的观念

三横（顺序）：方法==>愿景=业务目标 + 高层需求（范围 特性 上下文）

--按照系统目标 

—给出功能范围和强调的特性，范围广，特性可强调某几个特性，也可非常细致，可大可小

--绘制上下文图，不关注内部的功能和结构，中心+四周的UML用例，明了待开发的系统 用户 和 交互系统

--绘制用例图，系统外部的使用者Actor 和内部的功能Case，并细化其功能指向

   明确用例规约，用例名称 简要说明事件流（基本事件流+扩展事件流） 非功能需求前置条件后置条件  扩展点 优先级

 

 

两纵（持续）：观念==>需求分析大局观，不拘泥于需求列表 1，2，3，二维需求观（功能 质量 约束 + 组织 用户 开发）

 

+功能（职责协作链条）—用户输入和系统动作交互， 业务规则 例外处理   特殊需求  相关功能 注释说明

+非功能：

+质量（性能：内部质量决定 外部质量）—运行（外部质量）（性能 安全 易用 可用 交互 容错） 开发（内部质量）（扩展 维护 移植 重用 测试 易理解）

+约束：各种环境限制（转化为功能+质量+环境）

 

 

 

 

领域建模： 原理=> 过程  =>内容 + 方法  + 实现

 

原理：松耦合，通过抽象接口隔离变化

过程：需求词语+界面内容==>设计+持久化数据+扩展性 （核心业务可视化-内，抽象成OO类-外）

 

内容：

UML图  模块的包含关系 顺序关系和映射关系

状态图   状态、转化原因和引起的动作，以及子状态      

扩展性  就是潜在的UML功能+状态变化

 

方法：

理顺概念关系—领域词汇（达成共识）

搞清业务规则—领域模型 （次第展开）

 

实现：

领域==>扩展功能类，   增加数据类

功能==>领域模型修改，完善数据关系 

 

 

 

明确关键需求（预见权重更大的目标）

= 关键质量（二维ADMEMS）+关键功能（核心 必须 高风险 独特）

关键需求决定架构，其他需求验证架构,

需求范围—>关键需求—>需求折衷 

 

概念架构设计

 

目标—>设计思想—>选择

 

1.功能+质量

关键功能--

原理：用例到鲁棒图，每个用例多个场景，每个场景是一串职责链条

工具：鲁棒图（ v-边界对象交互  m-业务逻辑 + c-应用逻辑（控制对象 行为） 数据（实体对象 信息））

方法：增量建模，职责 -> 职责关系 -> 发现新职责

 

关键质量-目标（功能）+场景 （用户动作，和数据处理效率）+决策 （对策）

 

2.架构设计：1个决定，4个选择，先明确顶级子系统和架构风格，再明确集成和开发技术选型

 

3.备选方案：

系统组成：前端 后端 API 插件

技术选型：架构风格 应用集成  UI集成  开发技术 

 

 

需求+领域模型+概念架构==>细化架构设计（5视图 组件+交互）

（繁中带简）

逻辑（模块划分 接口定义）= 职责单元 + 协作关系

开发（技术选型 文件划分） = 程序单元 + 依赖关系

运行 = 控制流 + 同步关系

物理（硬件分布 软件部署） = 物理节点 + 拓扑关系

数据 （存储格式 数据分布）= 数据单元 + 数据关系

 

 

试试看 成本远低于 正式干 ==>架构验证

原型分类

          抛弃            演进

水平   界面探索     定型

垂直   功能探索     迭代

 

验证内容：评审开发质量-扩展 重用 理解 和 测试运行质量-性能 伸缩 高可用 安全 

验证方法：原型法（架构师最担心的 和 用户最关心的）+框架法（实现一个小的垂直原型）

==>重大技术风险是否已解决可否大规模开发 

 

 

模块划分：

1.经验

功能树（隶属关系）  功能大类  功能组   功能项

                                  用例图     鲁棒图  功能模块  

 

功能分层：上下文图—>分层

EDD：功能模块 —> 粗粒度分层—>细粒度模块—>用例驱动

通用模块，高层有较高扇入，底层有较多扇出（该模块被更多上级模块共享)

框架化，没有提取机制的情况下，机制是一种隐式代码| 重用几率和重用带来的价值量成反比

 

2.推理

用例驱动： 需求—>设计 +  先大局后细节，而不是先详细后架构

用例—> 用例规约(内外对话，系统黑盒)—> 鲁棒图（哪些些类）—>时序图（内部协作（打开系统内部黑盒） 类之间的关系）—>类划归模块，模块间接口 

 

 

 

实践使用：

 

 

  架构细节
  图片用法
  运用学习
  
  梳理需求：功能+质量+约束
  流程图（可拆分成用例图|活动成败 - >出售成败 - >打款成败）用例图（人和动作|财务：报表+审核编辑：发布+打款管理员：权限）+用例规约（系统和人交互|前置条件 - >购买成败+活动失败 - >审核（呈现操作人和时间，活动信息和打款状态） - >后置条件 - >退款+分收益）状态图（细化用例图| 未申购已申购（有结果无结果）退款中已退款分收益）明确
         
         需求：关键功能+质量
         鲁棒图（交互界面+控制逻辑+实体信息| 字段信息curd数据操作人机交互功能目的内测代码外测运行上线方案）+目标场景选择（用户操作=>数据影响==>技术方案| 导出全部excel - >数据量大==> 1.提示不要这样操作2.分批次生成多个excel，然后发送邮件）==> 1个系统4个选择（前后端测试+线上pc + wap线上线下系统人工新老功能| lanmp）
                
                实现需求：细化架构+架构验证
                细化（组件+交互：职责协作 - >代码依赖数据映射 - >物理拓扑运行同步）+验证（原型：水平/垂直+抛弃/演进=>开发质量（扩展性重用性可理解）运行质量（性能安全高可用伸缩））==>开始大规模开发


  

领域模型图（UML）用户描述 - >领域模型 - >用例图 - >用例规约（细化用户描述）