（一）基本概念



  1. 软件架构指的是计算机与组件之间的交互，同时也可以理解为模块、职责划分、接口定义、交互机制、开发技术、组织元素、子系统、非功能性等一系列架构问题的树形决策
  2. 软件架构一方面从大局着手，就技术方面的重大问题作出决策，构造一个由粗粒度模块组成的解决方案，从而可以把不同模块分配给不同小组分头开发；另一方面，软件架构设计方案规定了各模块之间如何交互的机制和结构，在开发小组之间起到沟通桥梁和合作契约的作用。（模块划分及之间的相互关系）
  3. 架构设计时需要考虑的几种角色人员：
  1. 用户：UI、功能需求、易用性
  2. 客户：业务规则、业务目标、上线期限、预算
  3. 开发人员：模块设计、交互方式、可重用性
  4. 管理人员：模块划分及交互关系、配置管理

（二）从需求到架构的步骤



  1. 寻找需求，包括功能需求、质量需求、约束性需求，从中选出重大需要，特色需求以及高风险需求，并使用一定的领域建模术语进行需求描述；
  2. 根据选择的大需求进行概念架构，选取架构大方向，包括划分顶级子系统，选型架构风格，选型开发技术，选型集成技术，选型二次开发技术；
  3. 将概念架构进一步细化到模块+接口级，得到逻辑架构设计（模块划分、接口定义、领域模型）、开发架构设计（技术选型、文件划分、编译关系）、运行架构设计（技术选型、控制流划分、同步关系）、物理架构设计（硬件分布、软件部署、方案优化）、数据架构设计（技术选型、存储格式、数据分布）；
  4. 对细化后的架构进行验证。

（三）每一步骤的关键内容注意事项

  1. 寻找需求相关：
  • 寻找需求时利用上下文图来描述待开发系统与周围所有事物之间的界限与联系，明确系统主体，明确系统使用方，明确系统需要与哪些系统进行交互；
  • 需求分析全过程：需求捕获（需求采集卡）--->需求分析（交付需求规格说明书）--->系统分析（交付数据流图、分析类图、鲁棒图、序列图等），执行步骤为：明确系统目标--->确定范围+Feature+上下文图--->画用例图--->写用例规约
  • 上下文图由于在明确系统需求时，用以确定系统用户、系统范围、系统交互的对象
  • 需求规格说明书里精确阐述系统必须提供的功能，必须到达的质量属性指标以及必须遵守的约束。其中最常用的用例技术聚焦每个系统应该提供的具体行为功能，刻画系统为外部用户或系统提供的服务。
  • 需求分为组织级、用户级、开发级，每个级别有各自的功能需求、质量属性（运行期、开发期）以及约束（业务环境、使用环境、构建环境、技术环境），需求是一张二维表。

领域建模相关

  • 将业务概念以可视化的方式抽象成一套模型，在uml中用类图和状态图来表示；
  • 领域模型是需求到设计的中间转化过程，连接业务端与开发端两方人员，使得他们可以进行沟通

概念架构相关

  • 关键需求决定架构，关键需求包括：最具代表的需求、必须实现的需求、会为系统带来风险的需求、独特需特殊考虑的需求；
  • 概念架构针对重大需求、特色需求、高风险需求形成的高层架构设计成果，用于界定系统的高层组件以及组件间的关系，对高层组件进行笼统界定而不涉及接口细节，是直指目标的设计思想、重大选择；
  • 概念架构的设计阶段需要根据需求画出用例图，鲁棒图可以帮助检查用例规约是否正确，其包含3个要素（交互、行为、信息）： 边界对象：模拟外部环境和未来系统之间的交互，负责接收外部输入、处理内部内容的解释并表达或传递相应的结果；交互对象一般是外部系统、设备、人；控制对象：对行为进行封装，描述用例中事件流的控制行为，行为一般分为应用逻辑、业务逻辑、数据访问逻辑；实体对象：对信息进行描述，往往来自领域建模里的对象，信息指的就是内存或DB中的数据；
  • 鲁棒图和场景卡做完后就开始选择架构风格，划分顶级子系统，并对架构风格、开发技术选型、二次开发技术选型、集成技术选型等四个方面进行确定。
  • 鲁棒图画完一般功能需求都满足了，接下来需要使用场景卡即目标-场景-决策的方式来考虑多种非功能的情况，提升架构设计的质量。
  • 概念架构中需要对功能模块进行划分，一般以使用人员的分类来划分，同时兼顾开发上涉及的类、函数、数据结构等共性的功能划分到同一模块里，其中公用类的寻找可以通过用例驱动的方式，找到鲁棒图对应的公用类，进而将这些图对应的功能划分同一模块里，当然需要注意通用公共模块如日志、安全验证等划分到独立模块。如果是水平划分模块，则是所谓的分层架构；
  • 常见两种分层模式，1是分为展现层、业务层、数据层；2是分为UI用户界面层、SI系统交互层、PD问题领域层、DM数据管理层；
  • 一个独立的功能用例即是某一功能模块在具体某一层的功能集合。

架构细化

  • 架构设计迭代先逻辑架构再物理架构，逻辑架构迭代以交互为主线，包括用户交互、系统交互、业务逻辑、数据访问四个方面逐步进行迭代，每次迭代后进行物理架构的迭代，以上述四个方面为依据，首先找到需要的服务器数量，然后设计他们之间的关系及备份关系。如此往复，逐步细化。
  • 逻辑架构：规定了软件系统由哪些逻辑元素组成以及这些逻辑元素之间的关系。（层、子系统、模块等的划分决定+交互接口和交互机制[方法调用、RMI、消息]）
  • 物理架构：规定了组成软件系统的物理元素（进程、线程、类的运行时实例等），以及这些元素之间的关系和它们部署到硬件上的策略。
  • 从逻辑架构（模块划分、接口定义、领域模型）、物理架构（硬件分布、软件部署、方案优化）、运行架构（技术选型、控制流划分、同步关系）、数据架构（技术选型、存储格式、数据分布）、开发架构（技术选型、工程分布、编译关系）5个方面，15个内容来细化架构。