软件需求分、架构设计与建模最佳实践
软件需求分、架构设计与建模最佳实践
- cxx 2019-04-13
一、为什么要详细设计，价值？
- 在多人团队环境中，详细设计驱动开发可实现明确交付的目标和标准
- 可复用的设计成果
- 提高代码的可维护性
- 可对交付进行工作量和质量的评估
- 实现知识传承，提高软件生命周期
二、控制软件复杂性的基本方法
- 分解法
- 抽象法
三、UML有哪些元素
- 结构
- 行为
四、基于用户目标的需求组织形式
-
交互式需求
-
清晰的责任
-
场景化
文档的五大功效
-
有助于编写使用手册
-
测试用例转化：帮助开发人员设计测试用例
-
需求用例
-
利于详细设计时序图的设计
-
组件设计：功能复用
五、分析要点。。。
- 定性
- 定量
- 场景
- 约束需求
- 并发
- 数据量
- 带宽
六、用户体验的指令
- 功能性体验
- 易用性体验
- 性能体验
- 可靠性体验
七、设计用例
- 识别执行者（*）
确定系统边界，避免需求膨胀
Actor:人，系统，时间，温度、阈值
系统外：必须和它交互：主Actor（需求行为的发起者）,辅助Actor（需求行为的参与者）【边界、接口】
直接交互
有意义的交互
任何事物
-
识别执行者 (宁多不少)
谁使用系统主要功能--潜在会员、会员
谁改变--会员、货管员、经理
谁获得信息--潜在会员、会员、货管员、经理
谁需要系统的支持完成日常工作
谁负责维护、管理
系统需要应付那些硬件设备
系统需要和那些外部系统交互
谁对系统产生结果感兴趣
有没有自动发生事件--检查账户
下午：
识别用例：
- 选择执行者
- 用例的直接交互者
- 角色可以抽象泛化
- 主执行需要辅助执行者
- 基本定义
- RUP：用例实例：系统中执行的一系列动作(步骤)，这些动作将生成特定执行者可见的价值结果（价值）。
- 执行者通过该系统所要达成的目标。
书写用例文档--用例模板
前置条件、后置条件
用例交互四部曲
- Actor发起请求
- 系统验证请求
- 系统处理请求
- 系统响应请求
编一个用例
用例名称：申购单笔基金
模板：
第二天、架构设计及详细设计、设计原则、模式
日期：2019-04-14
1、架构设计
-
标识领域范围
从需求规格说明书入手
通过遗留的软件增强认识
-
输出模块组件接口
模块分解系统
组件实现复用
接口解决耦合
-
模块划分方法
-
业务领域
同种类型行为
-
基于角色
相同的角色
-
组织架构
-
组织架构+领域(ERP)
生产管理，客户关系、人力资源
-
系统->子系统->模块
-
组件
复用型、服务型、展显型
-
接口
用组件图来画
类型 图形 模块 包图 组件 组件图 接口 组件图
2、OOAD建模
UC开发迭代
v1->80%
V2->90%
V3->100%
边做设计，便进行coding
敏捷：TDD
MDA:Model-Driven Architecture
PIM: Platform Independent Model,作为分析阶段的产物--平台独立的
3、UML建模流程
ICONIX
Use Case Model->Domain -> Sequence Diagram
-
技术责：文档、代码、测试用例
-
注释先行，思维进入设计状态
-
dofige
类图
以功能进行组织类，数量10~20之间
识别类熟悉
基于用例进行分析
先在白纸上进行绘图
下午
closeDoor()
class Door{}
class People{}
class Wind{}
基本原则：函数放在那个类中，函数操作属性主要由那个类提供
类和类之间关系：关联、泛化、组合、聚合
Actor和Actor之间关系：泛化
Use Case和Use Case之间关系：泛化、包含、扩展
顺序图-时序图
需要用例文档、类图
开源代码去重工具：SonarQube---代码质量管理平台
右键-高级-转换为实例
高内聚、低耦合
高内聚：
描述模块内各元素的紧密结合程度
开源工具sourcemoitor扫描代码复杂度
函数》80-100行 类》1000-1500行
顺序图---重要
活动图：
partition,inition,final,activity,分支decision,send,receive
练习：
160页，活动图练习1
状态图：
分析》》》Excel
| 无预订 | 部分预订 | 预订完 | 预订关闭 | |
|---|---|---|---|---|
| 无预订 | ||||
| 部分预订 | ||||
| 预订完 | ||||
| 预订关闭 |
时间序列图：timing，定时图
