迷途书童

敏感、勤学、多思
随笔 - 77, 文章 - 4, 评论 - 86, 引用 - 0
数据加载中……

软件架构设计(四)——软件架构设计过程

3.10 确定系统需求

确定系统需求即确定系统用例。方法以根据业务用例实现场景分析为输入,分析每个系统Actor的系统用例。每个系统用例一定是一个完整的事件流,注意业务用例和系统用例的区别,业务用例是一个完整的业务目标,而系统用例是一个完整的事件流,是业务目标中的一个环节,如客户代表申请开户是一个完整的系统用例,但不是一个完整的业务目标,其包括多个页面操作。

 

3.11 用例实现分析

对每个系统用例,识别其可能的实现路径,每个实现路径就是一个用例实现,然后针对每个用例实现,分析人机交互,使用活动图绘制用例实现场景。

 

3.12 分析模型

使用分析对象,实现所有的用例实现场景,识别出三种分析对象。在这个过程中,也可以建立界面原型,和客户进一步达成需求的一致理解。分析模型是需求到设计的桥梁,分析类的层次高于设计实现,需求通过分析类转成计算机语言。后续做系统设计的时候,可直接将分析模型转换成设计模型。

在考虑分析模型的过程中,有可能识别出一些公共模块,比如开户、销户过程中都会有一些业务规则校验,需要引入规则引擎的支持,那么类似规则引擎这样的公共模块需要添加到逻辑架构中去。

 

3.13 非功能性需求设计

以性能为例讲一下对非功能性需求设计的过程。

1、确定性能目标:要支持多少用户、多少在线用户、多少并发操作、操作响应时间要求等;

2、以一个简单的三层架构为起点,根据性能目标,识别瓶颈。比如,如果数据库撑不住,那么需要考虑最佳的分库设计,如果是逻辑层撑不住,则要考虑负荷分担,状态同步的逻辑层方案设计,如果操作响应时间要求很高,则可根据不同场景,分析其操作的数据的读写特点,采用合适的缓存方案。如要支撑高并发低时延的大数据量查询,Twitter就采用了垂直缓存,raw缓存的设计方案。

3、验证性能设计。抽取典型场景,实现一个prototype来验证性能设计是否满足性能目标。

在质量属性设计中,如果需要新增模块,则需要修改逻辑架构。

有一些约束类需求也是非常重要的,不能遗漏分析。

经过这一个阶段,我们能够得到一个比较完整的逻辑架构,运行架构、开发架构、物理架构、数据架构的输入了。剩下的工作就是编档的工作了。

 

3.14 架构编档

有了上面的工作作为铺垫,编档就非常容易了,这个就不细讲了。

posted on 2012-07-08 16:46 迷途书童 阅读(1002) 评论(0)  编辑  收藏 所属分类: 随感系统设计业务建模


只有注册用户登录后才能发表评论。


网站导航: