系统架构

参加了一个如何画好架构图的培训，总结下来有一下几点：
1.设计也死
2.做正确的架构，正确清晰的表达架构，将架构正确应用到系统
3.Rup 4+1 视图：逻辑视图、进程视图、实现视图、用例视图
4.逻辑视图里包含功能视图主要用于和领导交互
5.活动图展现具体业务逻辑，适合多角色协作的具体业务也叫泳道图
6.序列图和协作图用于沟通需求和类设计
7.数据库设计要做到第三范式
8.软件架构的驱动因素：软件功能、非功能需求、其它约束
9.画软件架构步骤： a 功能视图、用例图
                   b  组件图、部署图
                   c 软件架构概要因素：操作系统、数据库、浏览器、构件、语言

1. 架构=组件+交互
2. 一般应先进行概念性架构的设计，把最关键的设计要素和交互机制确定下来，然后再考虑具体技术的运用，设计出实际架构。
3. 需求分析致力于搞清软件系统要“做什么”，而系统分析开始关注“怎么做”的问题。
4. 用例
5. 领域建模
6. 关键需求决定架构，其余需求验证需求。
7. 事情简单勇者胜，事情复杂智者胜。

参加了一个如何画好架构图的培训，总结下来有一下几点：
1.设计也死
2.做正确的架构，正确清晰的表达架构，将架构正确应用到系统
3.Rup 4+1 视图：逻辑视图、进程视图、实现视图、用例视图
4.逻辑视图里包含功能视图主要用于和领导交互
5.活动图展现具体业务逻辑，适合多角色协作的具体业务也叫泳道图
6.序列图和协作图用于沟通需求和类设计
7.数据库设计要做到第三范式
8.软件架构的驱动因素：软件功能、非功能需求、其它约束
9.画软件架构步骤： a 功能视图、用例图
                   b  组件图、部署图
                   c 软件架构概要因素：操作系统、数据库、浏览器、构件、语言
1. 架构=组件+交互
2. 一般应先进行概念性架构的设计，把最关键的设计要素和交互机制确定下来，然后再考虑具体技术的运用，设计出实际架构。
3. 需求分析致力于搞清软件系统要“做什么”，而系统分析开始关注“怎么做”的问题。
4. 用例
5. 领域建模
6. 关键需求决定架构，其余需求验证需求。
7. 事情简单勇者胜，事情复杂智者胜。