开始进入设计 … Transition to Design
从需求分析到设计
逻辑架构与子系统 Logical Architecture and sub-system
5.1 向设计过程切换 Transition to Design
需求与领域分析阶段During requirements and domain analysis work
做正确的事情 “Do the right thing”
理解领域问题 Understand the domain
澄清并记录约束和需求 Clarify and record the constraints and requirements
本质上，暂不考虑设计，集中在理解问题
设计阶段 During design work
正确地做事情 “Do the thing right”
创建设计模型，以便构建系统 Create a design model that can be used to build the system
满足领域约束 Meet the domain constraints
两类主要的模型: 交互图 Interaction diagrams 设计类图 Design class diagrams
设计的输入
系 统 操 作 System Operations
或者操作契约
迭代
每次迭代，都存在需求 到设计的过程
遇到需求的变化，应当 “拥抱”而不是“回避”
设计的结果
设计一个方案，展示系 统是如何实现需求
5.2 逻辑架构、软件架构
什么是架构 What is Architecture?（有的教材翻译成“结构”）
架构是关于如何组织软件系统的一系列重大决策
An architecture is the set of significant decisions about the organization of a software system
如何选择组成系统的结构元素及其接口
这些结构元素相互协作时的行为规范
这些结构元素如何组合成逐渐变大的子系统
可以参考的架构风格 architectural style，以便指导如何组织这些结构元素、定义它 们的接口、协作、以及组合成子系统的过程
架构的另外一种说法: Logical Architecture、Software Architecture
大规模组织类，以便形成模块、分层、子系统、命名空间等
不同于部署架构 Deployment Architecture 定义这些结构元素分布在不同的物理设备上
可能会影响逻 辑架构的因素, 还包括: 补充规 格说明中约束 、非功能性需 求等
5.3 逻辑架构设计方法 – 分层法
分层 System Partitioning
“分而治之”
标识一定规模的结构元素 large-scale elements (LSEs)
层Layers: 粗粒度地组织结构元素，考虑内聚性，完成特定功能
Coarsegrained grouping of architectural elements cohesively responsible for a specific aspect
子系统 Subsystems
模块 Modules
接口
结构元素之间的协作
在开发的过程中，上述各部分是会变化的
在“分”的同时，要考虑“合”
5.4 分层架构的优点
优点
各层都容易被替换 Layers can be easily replaced
较低层次包含更多的操作细节，容易成为可重用的构件
每层都容易分布部署与连接
分层时考虑的问题 Separation of concerns
服务是放在高层还是底层 High-level vs. low-level services
服务是作为应用专门的，还是通用的 Application specific vs. general services
5.5 分层架构示例
物联网大数据平台TIZA STAR架构http://mt.sohu.com/20161024/n471123659.shtml