标签：element 交互 扩展 需求分析 操作 strong 逻辑架构 需求规格说明书 解决
Architecture架构，每个人的理解都不同。
分为组成派和决策派。
组成派：软件系统的架构将系统描述为计算组件以及组件之间的交互（The architecture of a software system defines that system in term of computational components and interactions among those components. ）。更多地关注软件，分析软件组成。
决策派：某个软件或计算机系统的架构是该系统的一个或多个结构，每个结构均由软件元素、这些元素的外部可见属性、这些元素之间的关系组成（The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. ）。更关注人，归纳了架构决策的类型。
系统、子系统、框架都可以有架构，只是粒度不同。
架构不仅仅是接口的问题，还有并发、部署、性能、安全等因素需要考虑设计方案，而分层很重要，迭代地细化设计，并且灵活应用设计模式。
架构设计需要面向：用户、客户、开发人员、管理人员等，为项目相关不同人员而设计。
物理视图+逻辑视图。
使用分而治之和迭代式设计（而非瀑布式）。
经历设计在前，成为架构师在后。
尽量找机会看看别人的设计成果、多体会别人的设计过程、多试着自己来设计设计。
程序员向架构师转型难在哪里？难在必须要能开始“试着做起来”，并慢慢积累感觉，进而积累经验。
洞察节奏3个原则：1、看透需求（基础）；2、架构大方向正确（确定正确的概念架构）；3、设计好架构的各个方面（通过多视图方法“细化架构”，通过“架构原型”验证架构）。
看透需求：需求要全（功能需求、质量需求、约束需求），矛盾关系，追溯关系（如追溯系统目标）。
架构大方向正确：概念架构，是策略，如架构模式、集成技术选型。（重要！！！直指系统设计目标的设计思想和重大选择，是关乎任何复杂系统成败的最关键的指向性的设计。对比分析几种可能的概念架构）
设计好架构的各个方面：架构师必须具备“忘却”的能力，避免设计太多具体的技术细节，5视图。
有经验的架构师不会一上来就关注如何定义“接口”，他们在大型系统架构设计的早期比较注重识别：重大需求；特色需求；高风险需求；据此来决定如何划分顶级子系统，采用什么架构风格和开发技术，集成是否要支持，二次开发是否要支持（1个决定4个选型）。
掌握过程6个步骤：（1）需求分析（2）领域建模（3）确定关键需求（4）概念架构设计（5）细化架构设计（模块+接口）（6）架构验证（对后续工作产生重大影响返工代价很高的任何工作都应该进行验证，包括需求和架构设计方案）。
领域建模：以提炼领域概念，建立领域模型为目的的活动。精髓是“业务决定功能，功能决定模型”。领域建模活动的输入：功能和可扩展性具体要求。
愿景分析：要解决项目、产品或解决方案的起源问题。所谓明确愿景，就是针对系统目标、主要特性、功能范围、成功要素等进行构思并达成一致。（需求分析，得到需求文档）
愿景=业务目标+规范+Feature+上下文图。
《软件需求规格说明书》（Software Requirements Specification, SRS）需求分层次，需求分不同方面。
ADMEMS矩阵（需求层次-需求方面矩阵）
软件质量：运行期质量属性和开发期质量属性。（性能，安全性，易用性，持续可用性，可伸缩性，互操作性，可靠性，鲁棒性，易理解性，可扩展性，可重用性，可测试性，可维护性，可移植性）
约束需求=业务环境因素+使用环境因素+构建环境因素+技术环境因素
需求=功能+质量+约束
5个视图。15个设计任务。
逻辑架构（模块划分、接口定义、领域模型）。
开发架构（技术选型、文件划分、编译关系）。
运行架构（技术选型、控制流划分、同步关系）。
物理架构（硬件分布、软件部署、方案优化）。
数据架构（技术选型、存储格式、数据分布）。
标签：element 交互 扩展 需求分析 操作 strong 逻辑架构 需求规格说明书 解决
原文地址：https://www.cnblogs.com/lizhuxin/p/10745402.html
