1、什么是软件架构
1、1 分2种：
1>、组成派：软件架构 = 组件+ 交互（接口，模块与模块之间交互）；
2>、决策派：软件架构= 重要决策（决定重要的需求）；
两者互相铺成；
1.12软件架构和子系统、框架之间的关系：
1>、复杂性是层次话；
2>、好的架构必须把变化有效的封装到系统的不同部分(关注点分开）：
a、通过关注点分离,达到“系统中的一部分发生变化，不会引起另一部分的变化”。的目标（作为一名架构师应该能熟练的应用设计工具（UML建模，OOD/OOA,GRASP,领域模型，UP);
3>、软件单元粒度：
粒度最小的单元通常为类，也有人说是字段、属性，方法；
A类与其他类之间的协作，构成模块；
由一个或多个模块完成独立的功能，构成子系统；
由一个或多个子系统相互配合满足一个完整应用的需求，从而构成了软件“系统”;
一个大型的企业往往使用多套系统，多套系统相互操作形成“集成系统”，也有人说是WEB机群？？？
注意：软件单元的粒度是相对的，同一个软件单元在不同的场景中我们会以不同的粒度看待他，软件架构不等于框架（2者有联系），框架是一种特殊的软件，框架也有架构；
可以通过架构框架化来达到“架构重用”的目的，如Log4net,SSH;
4>、软件架构的作用
如果一个项目的架构还未确定就不应该进行系统的全面开发；
一个充满缺陷的系统始终是一个充满缺陷的系统
软件架构是将现实世界与计算机世界的一座桥梁，要完成从面向业务到面向技术的转换
需求 —- >>> 架构设计—- >>> 软件架构 —- >>> 系统开发—- >>> 软件系统
a、软件架构对新系统起的作用:
上承业务目标，下接技术决策；
控制复杂性；利于迭代开放和增量交付；提高质量；
b、软件架构对软件产品开发的作用：
固化核心知识；
提高可重用资源；
缩短推出产品的周期；
降低开发和维护成本；
提高产品质量；
支持批量定制；
软件产品线：是一组可管理的、公共特性的、软件密集性系统的集合这些系统满足特定市场的需求，并且按照预定义方式从一个公共的核心资产集开发得；
软件产品线架构：针对一个公司或组织的一系列产品而设计的通用架构；
2、软件架构方法
架构师应当为项目不同的角色而设计；
架构师要为客户负责，满足他们的业务目标和约束条件；
架构要为用户负责，满足他们的功能需求和运行期质量属性；
架构师必须为在一起工作的程序员着想；
架构师必须考虑到项目的管理人员，为他们进行分工管理，协调控制和评估监控等工作提供清晰的基础
五视图法：
逻辑架构：
逻辑架构关注功能；
开发架构：
开发架构主要关注程序包，设计着重考虑开发期质量属性，如：扩展性，重用性、移植性、易理解性、易测试性、可维护性；
运行架构：
运行架构关心进程、线程，对象等运行时的该概念，已经相关的同步通讯等问题；其设计着重于运行质量的属性，例如：性能，可伸缩性，持续可用性和安全性；
物理架构：
物理架构是关注系统最终如何安装和部署到物理设备上。要着重考虑安全和部署需求；
数据架构:
数据架构关注数据持久化数据的存储方案，设计时考虑“数据需求”；
从概念架构到实际架构:
概念性架构是设计时最初的梦想，一般来说概念性架构把最关键的要素进行设计和交互性定制下来，然后考虑技术的运用设计出实际的架构
架构设计中关键及解决策略：
时间就是架构的生命，方法产生恐惧；
面对时间紧迫压力，我们有理由质疑那种不顾时间追求软件质量的做法，软件架构是系统质量的核心，有的时候用时间换质量这样可能会导致项目的失败（开发新手要领悟这点）
架构设计并非好的就是成功的，而是最适合的就是是最成功的（不要一味表现自己的技术多牛B，做出多牛的功能，现在我经常在公司的项目中遇到很多这样的项目经理，他们让架构师去完成一个自认为一个很完美的功能，给用户使用，满足需求客户，但是这样是很威胁的）；
软件架构设计中的关键要素与策略：（新手架构师要特别注意不要认为你比别人技术牛，而是你要站在更高的角度看整个项目情况）
关键要素
策略
是否遗落了巨大的功能需求
全面了解客户需求，多与客户沟通，发现隐藏的需求，提醒你客户需求
是否驯服了巨大平繁变化的需求
关键需求决定架构，每阶段的项目，客户需求中都会有一个或多个亮点，而这些他们自以为是的需求，
认为很好，很强大的功能，就要给了需要要，研发开搞，如果你遇到这种情况，请进行全面分析，时间，技术，有没有合理的开发人员，
需求不明白的地方问清楚；如果发现该需求在每次与客户沟通的时候他们也不能给出正确的业务需求，那么你一开始要跟他一起帮他分析这个需求
，到你1次2次3次在分析的时候发现这个需求关系到系统重要的架构变动，那么你要谨慎了（是否砍掉，你要“吼”住）；呵呵
能否从容的设计软件架构的不同地方
多视图角度看架构（逻辑，数据、运行、开发、物理）
是否及早的验证架构并且做出调整
及早验证架构，现在开发项目是讲究的是团队，要发挥每个成员的作用，做出了架构找大家一起讨论该架构（测试，美工也可以参加）；
这样好处是大家都到了提升，并且你会发现在讨论的过程多你会把自己的最初的架构不断的完善，直到所有人同意了你的架构设计（大家注意了你们在
讨论的时候可能遇到牛人，不要怕，如果是我会把这看成是个机会，我希望他指定一二，并且问清楚他为什么会这么想，至于有什么收获，你们懂的….
软件架构设计到什么程度：
软件架构覆盖整个系统，尽管有些功能只有一寸深
软件架构是团队开发的基础
软件架构设计到什么程度？
(1) 根据不同的开发团队，不同的项目，软件架构设计的程度都不相同，例如有的项目是新开发的，有的只是后期的维护；
(2) 软件架构能给开发人员带来指导与限制；
注意“高来高去”是架构设计：
1、 遗漏了某些重要的视图；
导致开发人员对某些角色的丢失；
2、 名副其实的分层架构；
没有考虑好把各个层，模块的设计，导致接口各个层之间的交互错误；
3、 只是为了完成架构设计活动的架构；
没有深入分析架构，导致在后期项目开发的时候发生严重的问题（例如：用JS进行现实功能，做了一半发现不行，又改用服务器控件完成）；
软件架构设计的过程：
1、一般的软件设计阶段
概念阶段：（分析用户（只要你做什么功能的人而不是要你做需求的人）所说，他们期望是要做一个什么样的功能，也就是用户的愿景）这里面有多种角色的人员要参加,例如：需求分人员，项目经理，架构师，客服人员，用户，也许你们LD也参加了；
1>需求分析：
需求捕获 需求分析 系统分析
把概率阶段用户提出的功能的要求，进一步做需求，把隐藏的需求要及时发现；
需求分析是一个求知的过程，从无到有，并且整理成文档的过程；
需求分析是挖掘知识的过程，它在已概念阶段上进行；
软件架构师必须掌握的需求知识：
软件架构师不是需求捕获者，也不是编写需求文档的专家；但是他要需求分析、需求澄清、需求变的研究方面是专家，否则就跟别的软件架构师就差了一截；
软件需求类型：
按质量类型属性分累
1.1>运行质量属性:
(1) 性能 performance
(2) 持续可用性 availability
(3) 安全性 security
(4) 易用性 usability
(5) 可靠性reliability
(6) 可伸缩性scalability
(7) 可操作性interoperability
(8) 鲁棒性 robustness
1.2>开发期质量属性:
易了解性 understandability
可扩展性 extensibility
可维护性maintaninability
可测试性textability
可重用性 reusability
可copy性
2>领域建模：
领域建模是把实际的问题领域抽象的表示，分析问题领域模型，挖掘出业务领域模型，并且建立与业务领域模型之间的关系；
领域模型对整个开发系统的作用：
(1) 探索复杂问题，固化领域知识；
(2) 决定功能范围，影响可扩展性；
(3) 提供交流基础，促进有效的沟通；
3>确定关键的需求：
关键的需求决定架构，其余的需求决定需求验证架构；
什么是软件中关键的需求？
关键的功能需求，关键的商务需求，关键质量属性需求（是开发质量与运行质量属性哦,hehe）
如何确定关键的需求？
实现并验证软件架构
好的策略必须是一次再一次的验证，测试、发现漏洞，思考解决漏洞的方法，记录内容文档，有时候还会重新策划从头来过；
架构原型对功能性需求的实现非常有限，那么怎么保证“架构验证”？
4>概念架构设计：
分3步： 鲁棒性分析、引入架构模式；
1>鲁棒性分析：它是根据用例文档中的事件流，识别出实现用例规定的功能所需要的主要对象和职责，形成职责模型为主的初步设计；
它是从功能需求向设计方案迈向的第一步，所获得初步设计是一种理想化的职责模型，它的重点是识别组成软件系统的高级模块，规划他们关系；
它还弥补了设计和分析之间的鸿沟（鲁棒性有3种元素：边界对象，控制对象，实体对象）；
2>引入架构模式:例如MVC ,分层，微内核，MVP，MP;
3> 质量属性分析：
5>细化架构：
架构细化是基于五视图方法进行：
架构细化设计工作内容：
架构设计视图
设计任务
逻辑架构
细化功能单元
发现通用机制
细化领域模型
确定系统接口和交互机制
开发架构
确定开放或直接利用的程序包之间的依赖关系
确定采用那个技术
确定采用哪个框架等
确定验证方式、
确定缓存处理、系统异常处理、日志记录、权限验证、安全方面、服务接口、授权、认证等很多；
数据架构
确定数据持久方案；
数据传递、数据复制、数据同步的等策略（可选）；
运行架构
确定引入哪些进程和线程；
确定主动对象、被动对象、以及控制对象；
处理进程线程的创建、销毁、通信机制、资源；
协议设计等；
物理架构
确定配置方案；
确定如何将目标程序映射到物理节点；
逻辑架构设计中“发现通用机制”是特别强调的
机制是模式的实例（设计模式啊）机制是特定上下文中重复出现的问题的特定的解决方案；
具有良好的架构的系统具备概念的完整性，它通过对系统架构建立一种清晰的认识来发现通用的机制和抽象；利用这种共性最终使系统更对简单；
6>验证架构的两种方法：
1>原型法： 它针对与项目式的开发中，即对一组架构设计决策在非公能需求方面满足程度的进行，该原型演进行，而不是抛弃型（在很多外包公司，他们就是包项目，或者是人力但都是针对不项目的，不是产品的，所以外包的弟兄在验证你的组织架构时不要紧张，不要认为这次你错了，别人就怎么看你，其实这是一个必须的过程（一般为3次 你讲 ，大家评审，确定）；
2>框架法：一般用于产品公司，针对产品软件架构的验证，它有更多的优点，该方法采用框架的方式进行呈现，并且在上面进行评估，在框架实现以后，上面的部分功能也基本实现即可实现一个小的垂直原型，从而可以进行实际非功能的测试，与开放质量属性的评估；