软件架构设计模板

物理架构还需要解决非功能性需求 物理架构还要和后续设计和实现进行衔接 非技术人员可能难以理解
架构设计规范最新版实例
见架构设计规范模板和实例
架构设计小结
架构设计为系统的总体设计，决定了系统的组 件划分、关键技术方案决策、技术选型
架构设计上接需求，下接进一步的设计和实现， 是决定系统实现的质量、效率、成本的关键阶 段
四、概要设计与详细设计
概要设计内容
功能模块划分（功能一览表） 模块设计和划分的依据：系统用例
接口定义（以上分解出的模块间的接口， 包括接口名称、功能概要、参数、返回值）
概要设计阶段活动模型
系统用例
开发组件一览 表
架构师
系统分析 师
高级开发 人员
功能一览 表
接口说明 书
详细设计内容
带路(餐桌编Байду номын сангаас) 登记入座信息(餐桌编号, 餐桌状态)
到门口迎宾()
点餐(餐桌编号)
业务分析实例
业务流程分析的意义
动态表达业务运转的过程 只有很好的理解了业务流程，才能设计出更好的支持该业务
的系统 通过对比系统实施前后的流程变化，分析优化点，评估系统
价值
二、需求分析
需求工程总览
需求开发
架构设计
课程背景
随着信息系统规模越来越大，业务和技术越来越复杂， 对架构师的能力要求越来越高，架构师需要掌握规范的 设计方法
业内对于架构设计的方法，并没有非常统一的说法。在 实际工作中，架构师们由于出身不同，设计方法各不相 同，产物的形式多种多样，不利于横向交流和后续指导
不同企业对架构师岗位理解不尽相同，架构师的职责范 围也因此不尽相同，架构师需要有一定的适应能力
+ 文件名: String + 文件内容: String + 路径: String
0..*
1
1
配置集
- 配置项列表: List<配置项> - 配置文件列表: List<配置文件>
开发领域模型的常见错误
将待开发系统也放在领域模型里面 概念划分不清，关系没有画到位
领域模型的用途
整理业务中的概念以及关系，帮助理解业务 指导数据库设计 指导系统功能设计 指导开发
逻辑架构中，组件名称使用母语以便理解 逻辑架构不涉及技术元素，只是纯概念上的表述 逻辑架构的读者可以是非技术人员 逻辑架构设计完成后应和系统分析师、产品经理等
人员一起确认，检查是否满足需求
物理架构
将逻辑架构中的组件转换为技术性的物理组件， 名称使用英文，在实现时应遵循这些命名
物理组件粒度有大有小，可表现为子系统、进 程、对象等多种形式
代码中的领域层
UI BL DAO DB 无领域层时
UI BL Domain DAO
DB 有领域层时
1.2 业务对象
业务执行者(Business Actor) 使用组织所提供的业务的人
业务工人(Business worker) 提供业务的组织的内部支撑人员
业务实体(Business Entity) 提供业务的组织的内部信息系统
2.3 非功能性需求
可用性 性能 安全性 可扩展性 可伸缩性 可移植性 经济性
讨论
需求与设计的边界是什么？ 用户需求与系统需求的关系是什么？ 我们的产品人员有无产出需求分析成果？
需求分析实例
三、架构设计
系统设计的阶段划分
系统简单时 概要设计 详细设计
系统复杂时 架构设计 概要设计 详细设计
纯功能角度对系统进行分解 从组件、功能两个角度对系统进行分解
组件、功能、模块的区别和联系
组件是架构设计阶段考虑的单元，功能、模块是概要设计、 详细设计考虑的单元
一个组件可包含多个模块，涉及多个功能 一个功能的实现可能需要多个组件中的相应模块来协作完成
1
+
*
+ +
+
1
手机
品牌: String
型号: 配置:
String String
*
颜色: String
1
*
移动APP *
+ ID: String + 名称: String + 版本: String *
1+
运营商 名称: String
1+
手机厂商 名称: String
+ 1
开发商 名称: String
class 领域模型（餐饮）
领位员
点菜员
领域模型举例一
1
1
收银员
*
*
顾客 + 人数: int
1 1
* 餐桌 + 编号: String
1 厨师
1
*
1
帐单
菜品实例
*
+ +
金额: float 点菜清单: List<菜单项>
1
*
+
名称: String
1
*
*
1
上菜员
*
*
1 大堂 + 名称: String
1 包厢
1
0..*
+
+ +
版本号: String
ID: String 名称: String
+ 部署环境名称: String
1
0..* 1
0..* 0..*
0..*
0..*
0..* 0..* 0..* 0..*
配置项 + KEY: String + VALUE: String
0..*
0..*
0..*
0..*
配置文件
课程理论来源
课程大纲
一．业务分析 二．需求分析 三．架构设计 四．概要设计与详细设计 五．理想软件过程探讨 六．总结
上游工程白话解释
业务分析：系统要支撑的业务是怎样的 需求分析：系统在业务中要做什么 架构设计：系统总体上怎么做
一、业务分析
业务分析概述
业务分析是在系统开发之前对系统要解决的业务领域的研究 过程，目的是搞清楚该业务领域的概念以及业务的运转过程
组件、功能、模块举例
WEB前端
• 用户查 询页面
• 用户新 增页面
模块
组件
后台接口
• 用户查 询接口
• 用户新 增接口
后台服务
• 用户查 询服务
• 用户新 增服务
功能 用户查询功能 用户新增功能
什么是层？
什么是架构？
系统的内部结构（组件以及它们之间的关系）
系统
组件
组件
组件
组件
组件
系统的一些重要决定（以变更的代价来衡量）
系统用例是业务用例相应流程中对系统的一个 操作
功能与用例的区别和联系
用例是需求分析的产物，描述的是某种用户使用系统完 成什么业务
功能是设计阶段的产物，是根据系统用例和架构中的组 件推导出来的
功能是静态的，用例是动态的 从语法角度来说，用例是动词短语，功能是名词短语
例：用例命名（查询空位），功能命名（空位查询） 常见的错误：描述需求时拿出一份功能清单
系统要通知点餐员前来辅助顾客点餐； 如果有宝宝椅需求，系统需要通知服务员送来宝宝椅
讨论
业务分析中的业务执行者、业务工人与系统用 户的关系是什么？
业务分析中有业务流程，那么需求分析阶段要 不要画系统流程？
业务用例与系统用例的区别和联系
业务用例是描述组织对外提供的能力，系统用 例是描述系统对外提供的能力
引言
什么是方法论 什么是设计
设计首先是实现意图的书面表现形式，而非口头的东西 设计是要让实现者能理解设计者的意图 设计是要让不同的实现者做出来的东西差不多 设计是严肃的，后续实现者不能随意偏离设计
什么是架构
课程目标
掌握业务分析过程的要点 掌握需求分析过程的要点 掌握架构设计过程的要点 了解概要设计和详细设计的内容 理解软件工程理想过程
用例名称 用例描述 主要参与者 次要参与者 主要事件流
可选事件流 前置条件 后置条件
登记入座信息
顾客在某餐桌就座后，领位员在系统中输入相应信息
领位员
无
领位员选择入座的餐桌； 领位员输入就餐人数； 领位员设置餐桌状态为“等待点餐”，提交 如果需要宝宝椅，领位员在系统中设置需要的宝宝椅的 数量 顾客已经在某餐桌就座
领位员 点餐员
顾客 餐饮管理系统
厨师
上菜员
收银员
管理员
经营者
外部业务系统
2.2 系统用例
概念 系统被使用的案例
分析过程 从业务流程中推导
系统用例命名规范 动词短语（例：添加用户、查询话费）
系统用例举例
uc 系统用例 领位员
餐厅管理系统 查找空位
登记入座信息
相关业务流程
系统用例细化
目标
理想敏捷
软件工程的理想过程
自上而下 循序渐进 由内而外
上游工程活动回顾
业务分析 需求分析 架构设计 概要设计 详细设计
上游工程理想分工探讨
产品经理
业务分析 需求分析 架构设计
业务理解 业务说明
需求调研 需求分析 需求细化
评审
概要设计 评审
详细设计 界面设计
应用市场 1
+ 名称: String
小米 华为
class 领域模型v2
部署环境 + 名称: String + 位置: String
1
0..*
应用实例
解决方案
应用
应用版本
+ 应用名称: String
+
名称: String 1
1..*
+ +
名称: 类型:
String String
1
1..*
+ +
应用名称: String 版本号: String
问题
界面原型是什么？为什么很多项目喜欢先做界 面原型？
功规是什么？跟架构的关系是什么？ 开发人员的输入是什么？有什么问题？
瀑布VS敏捷
起点 起点 起点
起点
目标 目标
理想瀑布 实际瀑布
目标
实际敏捷
敏捷过程的总代价要大于瀑布模型 敏捷容易成为不按方法论、不守流程规范、轻视文档的借口
采用敏捷过程的通常理由：需求不清楚，我们不妨边做边瞧 But why?没有方法论
开发系统的目的一般是为了优化业务流程，使业务运转得更 加高效、经济
系统的价值主要在于实施后能够帮助客户带来多少业务价值 不管有无系统，业务通常是不变的
业务分析阶段活动模型
业务知识 类似产品
客户 领域专家
业务分析师
领域模型 业务模型
1.1 领域模型
领域模型是对领域内的概念类或现实世界中对 象的可视化表示。又称概念模型、领域对象模 型、分析对象模型。它专注于分析问题领域本 身，发掘重要的业务领域概念，并建立业务领 域概念之间的关系。
模块内部实现逻辑描述 界面设计 数据库设计
详细设计阶段活动模型
功能一览表
系统用例 接口说明书
UED
中级开发 人员
界面设计
模块内部 设计
领域模型
DBA
数据库设 计
五、理想软件过程探讨
公司项目典型过程
产品人员产出界面原型、功能规格说明书 架构师产出架构相关文档 以上两种重要角色的工作没有什么交集
架构设计的目标
满足功能性需求 满足非功能性需求
架构设计阶段活动模型
需求规格说明 书
系统分析师
项目经理
系统架构师
架构工作计划 逻辑架构设计 物理架构设计 开发组件一览表 部署组件一览表 技术选型一览表
架构设计好坏的衡量标准
设计完成时检验 设计资料的规范性 设计思路、方案决策、技术选型的合理性
+ 名称: String
*
1
菜单项
+ 名称: String + 价格: float + 图片: Image
*
*
*
1
1
餐厅 + 名称: String 1
1 菜单 *
class 领域模型（移动应用）
领域模型举例二SIM卡 + 号码: String * *
手机用户
+ +
姓名: String 身份证: String
• 需求调研 • 需求分析 • 需求定义
需求管理
• 需求确认 • 需求跟踪 • 需求变更控
制
需求分析阶段活动模型
领域模型 业务模型 需求调研成果
系统分析师
系统上下文 功能性需求（用例模型） 非功能性需求（性能等）
2.1 系统上下文
概念
系统与周边用户和其它系统的关系
系统上下文图举例
cmp 系统上下文
系统实现后检验 功能性需求的满足程度 非功能性需求的满足程度
架构工作阶段划分
架构工作计划 逻辑架构设计 物理架构设计 架构跟踪
架构工作计划
见计划模板
逻辑架构
将系统分解成若干逻辑组件，并建立它们之间的关 系，以满足系统需求。关系分静态和动态，其中静 态关系用组件图表示，动态关系用序列图表示。
领位(人数, 大厅|包厢)
到门口迎宾()
点餐员
查找空位(人数, 大厅|包厢): 餐桌编号
带路(餐桌编号) 点餐(餐桌编号)
到门口迎宾()
业务流程举例（系统实施后）
sd 领位流程（系统实施后）
顾客
领位员 到门口迎宾()
餐厅管理系统
点餐员
领位(人数, 大厅|包厢)
查找空位(人数, 大厅|包厢): 餐桌编号
class 业务对象
业务执行者
«business actor» 顾客
餐厅
领位员
点餐员
厨师
收银员
上菜员
经营者
餐厅管理系统
管理员
1.3 业务用例
概念：组织对外提供的业务服务
1.4 业务流程
概念：某个业务用例的实现流程，通常用UML序列图表示
业务流程举例（现状）
sd 领位流程（现状）
顾客
领位员