软件需求分、架构设计与建模最佳实践
- 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,定时图