短信平台架构评审报告.docx
- 文档编号:8170544
- 上传时间:2023-01-29
- 格式:DOCX
- 页数:14
- 大小:299.63KB
短信平台架构评审报告.docx
《短信平台架构评审报告.docx》由会员分享,可在线阅读,更多相关《短信平台架构评审报告.docx(14页珍藏版)》请在冰豆网上搜索。
短信平台架构评审报告
MessagePlatform
ArchitectureAssessmentReport
短信平台
架构评审报告
Preparedby
拟制
辛贺
Date
日期
2011/10/23
Reviewedby
评审人
段凯强
Date
日期
2011/10/23
Approvedby
批准
段凯强
Date
日期
2011/10/23
Copyright©2011HUSTExp.GroupofRaindai
AllRightsReserved
目录
1.引言1
1.1.编写目的1
1.2.背景1
1.3.定义1
1.4.参考资料2
2.第0阶段:
合作关系及准备工作2
3.第1阶段:
评估3
3.1ATAM方法表述3
3.2商业动机表述3
3.3架构表述4
3.4对架构方法进行分类7
3.5生成质量属性效用树7
3.6分析构架方法9
4.第2阶段:
评估(继续)9
4.1集体讨论并确定场景的优先级9
4.2分析构架方法9
4.3结果表述10
5.第3阶段:
后续工作10
1.引言
1.1.编写目的
本文档的编写目的是对短信平台的概要设计进行说明,为后继的详细设计等工作提供参考和依据,本文档主要描述的内容有:
●表述
●调查和分析
●测试
●形成报告
本文档的预期读者为:
系统设计人员、测试人员、用户及其它有权限查阅本文档的相关人员。
1.2.背景
●系统名称:
短信平台V1.0
●任务提出者:
段凯强
●开发者(承接单位):
华中科技大学软件学院
●用户:
各种学生组织,如学生会、资委、社团协会等等。
目前学生组织之间通讯主要依靠飞信,但是电信和联通用户的存在使得飞信通讯存在很大的弊端。
一个能够跨越移动、电信、联通的手机消息通讯平台,就显得很有必要出现。
在这样的背景下,短信平台项目就应运而生。
1.3.定义
1.3.1三层架构
软件开发的三层架构是指:
UI(UserInterface)用户界面层,BLL(BusinessLogicalLayer)业务逻辑层以及DAL(DataAccessLayer)数据访问层,用户界面层设计出友好的用户界面,并做好对后台的接口工作,数据访问层负责对数据进行封装以及其他相关操作,业务逻辑层则介于两层之间,负责前后台的整合、业务的描述以及实现。
1.3.2工厂模式
工厂模式的定义是:
提供创建对象的接口。
工厂模式分为是三类:
简单工厂模式(SimpleFactory)、工厂方法模式(FactoryMethod)以及抽象工厂模式(AbstractFactory)。
这三种模式从上到下逐步抽象,并且更具一般性。
通常使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类:
即对于产品树上类似的种类使用简单工厂模式来实现。
抽象工厂模式创立的抽象工厂角色是工厂方法模式的核心,它与应用程序无关。
1.3.3ATAM
ArchitectureTradeoffAnalysisMethod(构架权衡分析方法)。
他是评价软件构架的一种综合全面的方法。
这种方法不仅可以揭示出构架满足特定质量目标的情况,而且(因为它认识到了构架决策会影响多个质量属性)可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标。
1.4.参考资料
[1]软件工程.(英)萨默维尔著,程成,陈霞译.机械工业出版社,2006
[2]软件架构实践. (美)Paul Clements,Len Bass,Rick Kazman著,车力红译. 清华大学出版社,2004年3月第一版
[3]《短信平台--可行性研究报告》
[4]《短信平台--项目开发计划》
[5]《短信平台--软件需求说明书》
[6]《短信平台--数据要求说明书》
2.第0阶段:
合作关系及准备工作
对项目的评估是使用的ATAM架构评估综合方法。
此次进行ATAM评估的学生组织在我们的宣传消息中了解了有关ATAM的事情,之后就派遣代表和我们就此事进行了协商。
待评估的系统为短信平台V1.0系统,这是一个能够跨越移动、电信、联通的手机消息通讯平台。
有如下两个评估原因:
首先,无论如何,如果架构本身在根本上存在缺陷,则早发现比晚发现要好得多;其次,该系统需要适用于多个学生组织,因此必须保证该架构具有足够的健壮性、可扩展性以及可修改性。
协商完成后,我们组成了一个评估小组,成员表如下:
表1:
评估小组成员
成员
角色
1
评估小组负责人、评估负责人、提问者
2
评估负责人、提问者
3
场景书记员、提问者、数据收集员
4
进展书记员
在此次评估中,我们设立了两个评估负责人,他们讲轮流负责聘雇过程的进展。
安排两个负责人可以防止负责人过度劳累,并有助于改善评估结果。
选择提问者的标准为看他们是否熟悉性能和可修改性。
在第一阶段开始之前,评估小组进行了一定时间的会晤,小组负责人再次审查角色分配,以确保每个人都知道自己的职责是什么。
此外我们大致看了一下已经完成的架构文档,对它说明的模式和战术做了注解。
这个简单的会晤,对后面对模式和方法进行分类的各个步骤打下基础。
3.第1阶段:
评估
3.1ATAM方法表述
评估负责人使用对ATAM方法进行了说明的一系列标准视图进行表述,并在表述中列出了该方法的步骤和阶段,描述了ATAM的概念基础(如场景、架构方法、敏感点等),并列出了评估结束后将产生的结果。
决策者基本上已经熟悉了ATAM,在第0阶段的讨论中已听到过对该方法的描述。
因此这步进展很顺利,没有任何问题。
3.2商业动机表述
评估期间,客户组织从开发组织以及将购买该系统的组织角度,表述了短信平台的商业目标。
对于开发组织来说,短信平台结局了如下业务需求:
(1)用户的正确登录。
系统中应当有两种级别的用户:
普通用户和账号管理用户。
普通用户具有系统提供的所有普通使用功能,账号管理用户除拥有普通功能的使用权外,还具有向普通用户分配可发短信条数的权限。
(2)通讯录的管理功能。
用户应当可以创建或导入多个通讯录,并且可以对已有通讯录做修改。
(3)群发短信功能。
为用户提供多种发送的模式。
普通发送或即时发送,定时发送,根据回复情况定时发送,比如用户可以设置在第一次发送1小时后对于未回复的联系人再次发送。
(4)统计回复功能。
对每一条群发的短信统计回复情况,包括回复的时间以及回复的内容。
客户原通信方式弊端:
学生组织之间通讯主要依靠飞信,但是电信和联通用户的存在使得飞信通讯存在很大的弊端。
客户的业务需求包括:
(1)方便学生工作中短信的群发与交流;
(2)能够自动统计回复情况和内容;
(3)设置定时发送、即时发送、重发提醒等人性化功能;
(4)具有友好的用户界面;
(5)短信平台的推出可以实线大规模短信群发和接收功能,并能够实现手机和互联网的无缝结合;
(6)基于短信平台开展多方面的拓展应用,包括B2C业务,例如校车出租查询、校园导航,也包括B2B业务,例如校园短信网关;
(7)实现人力和费用的节省,提高人员的动作效率,让消息发布者以最快的方式、最少的开销完成信息的发布;
(8)实现管理方式的提升,系统的短信管理可以让管理者对信息发布的状态了如指掌,消除管理误会,提高管理精度。
该系统的限制包括:
(1)本软件开发在寝室进行,服务器基于windows服务器版本环境,数据库采用Access2007,虽然Access具有简洁方便、不依赖Server也能对数据进行操作的优点,但是它的安全性不够,加了最高权限的密码后也容易被破解,因此需要做大量的保密算法。
另外,Access数据大小为2G,要做到大规模的管理,其能力还是有所欠缺的。
工作环境为寝室,身处校园内,在资源的接收与获取方面,资料的主要来源为网络、学校公共平台、校内专业人员,同外界企业相比较,我们的资料来源相对有限。
(2)赞助资金有限,只有有限条短信进行测试,因此需要在极小的测试与调试空间内对产品进行测试、改进与修复。
在测试阶段,测试用例的有效性将成为左右产品质量的最大标杆。
如下质量属性被确认为高优先级的质量属性:
(1)性能。
短信的处理要求快速的响应时间,系统吞吐量为性能的关注点。
(2)易用性。
这是决定系统用户量的一个关键的因素,新的系统必须容易学习和使用。
(3)健壮性。
系统必须可维护、可配置、可拓展,以支持新的市场需求。
下列属性质量确定为重要、但优先级较低的属性:
(1)可靠性:
能在由于系统问题或其它原因产生错误后,做出相对应处理,使程序具有较高的容错性能。
(2)开发文档易理解:
保证以后自己二次开发或他人接手开发时,能够清晰的理解整个系统的设计思路和实现细节。
(3)模块化设计此软件的功能:
不同的模块实现不同的功能,使得软件易于以后的维护与扩展,在以后可以更好的完善本软件的功能,更方便于在工作中的应用。
3.3架构表述
在评估小组与设计师进行交流期间,在评估开始前和评估进行中,需要有几个构架视图和构架方法。
如下几点内容非常关键:
(1)短信平台主要由五大数据模块构成:
AddressBook、Contact、MsgRely、MsgSend、UserInfo。
(2)要将短信平台的构建为具有极高的可配置性。
(3)平台系统需要进行分层。
(4)短信平台是一个基于存储库的系统,该系统的中心有一个实用的数据库。
图1:
非正式的分层视图
每当用户通过短信平台向所需的联系人手机发送短信,联系人手机就会收到来自短信平台的系统短信,同时平台数据库记录发送内容、发送时间以及收件人。
联系人收到短信后回复系统号码,短信平台收到联系人回复后将联系人发送时间、联系人号码、联系人回复内容等信息写入数据库相应的表项中。
只有在系统向联系人发送信息后,联系人才能对平台的系统号码进行回复。
为发映出数据的全部映射,使得大家能更好的了解ATAM评估的实际情况,我们给出了整体视图和各个层的数据流图。
图2:
总体视图
图3:
一层数据流图
图4:
二层数据流图
图5:
三层数据流图
图6:
系统逻辑视图
图7:
系统层次模型
短信平台的这些视图都同样合理,它们传达了重要的信息。
每个视图都展示了与不同关注点相关的一个方面,加上数据流视图的层层递进,所有这些视图都用来实行ATAM评估的分析步骤。
3.4对架构方法进行分类
进行了架构表述后,评估小组列出他们曾听到的架构方法,以及那些在对文档进行评估前的评审中所了解到的方法。
这额和其他方法为小组提供了一个概念上的立足点,当场景分析开始时,他们可以据此询问探察性问题。
3.5生成质量属性效用树
下表给出了在对短信平台评估期间生成的质量属性效用树,有几个质量属性求精没有与之相关的场景。
这种情况经常出现,这并不是问题,对于某个质量属性,人们有时能够想出一个合理的求精,但当让他们在自己的系统的上下文中对该质量属性聚义用例进行说明时,却发现该求精实际上并不适用。
表2:
对短信平台进行ATAM评估的效用树表格
质量属性
属性求精
场景
性能
响应时间
吞吐量
生成报表
在系统处于峰期负载时,对信息发送做出响应,进行群发短信息处理,信息处理响应要在三秒以内完成(H,M)
在峰期负载下,系统每秒能处理150次短信事务
没有建议的场景
易用性
熟练度操作
正常操作
在短信行业有一定经验的情况下,用户在一个特定的环境中请求短信群发帮助,系统为该帮助短信提供支持(H,L)
学生组织成员使用短信平台相互交流,无需引入系统延迟便完成该过程(M,M)
可配置性
学生组织需要改变短信群发套餐,开发配置小组在一个单位的工作时间内完成该改变,不需要改变源代码(H,M)
可维护性
维护人员遇到了搜索和响应时间缺陷,修复该bug,并分配bug修复(H,M)
报告需求要改变短信生成的数据元(M,M)
E-MAY公司发布了一个新的数据接口版本,必须尽快安装该版本(H,M)
可扩展性
添加新产品
创建了校园短信导航的产品(M,H)
可靠性
机密性
意外故障处理
允许高级管理员创建与分配管理员账号,但不能查看其任何私人隐私信息(H,M)
在运行过程中遇到意外导致系统停止运行,需要重启平台系统并回复原正在处理的信息,响应时间不超过30秒(H,M)
可扩充性
发展平台
两个学生组织合并重排部门,要求划分数据库(L,H)
其中一个学生组织削减了一个部门(L,M)
另外一个学生组织合并了两个部门(L.M)
模块性
功能子集
可更换性(灵活性)
构建一个可以与核心功能自治地运行的平台系统(H,H)
更换操作系统(H,H)
更换数据库可移植性层(H,H)
更换短信计费软件包(H,H)
可互操作性
构建一个与学校主业数据库具有接口的系统
表中的场景给出了决策者所分配的优先级。
在每一对有序的字母中,第一个代表能力的重要性,第二个戴白哦设计师对实现该质量属性的难度的估计。
我们需要注意到,一些场景已经很完备了,具备了刺激、环境和响应三个部分;一些场景没有刺激,还有一些场景么有响应。
在这个阶段,只要涉众能够理解场景的含义,不明确的场景说明是允许的。
如果所选择的场景用于进行分析,那么该场景中的刺激和响应必须得到足够的明确。
3.6分析构架方法
评估小组首先分析最重要而且最难实现的场景,每次分析一个最高优先级的场景,同时我们的设计师详细地解释了构架如何支持每个场景。
小组成员探查设计师用来实现场景的架构方法,把相关架构决策编成文档,一共确定了4个敏感点,1个权衡点,5个风险点以及3个机遇点。
4.第2阶段:
评估(继续)
在第二阶段除了参加第1阶段狐疑的项目决策者外,还有9位涉众参加了会议。
他们包括开发人员、维护人员、第一个客户的代表和两个最终用户。
第2阶段首先进行的活动是为新的参与人员重复第一步(描述ATAM),然后概述第1阶段的结果,以使每个人都熟悉评估。
完成这些工作后,进行一下的活动步骤。
4.1集体讨论并确定场景的优先级
在这一步骤中,涉众提出了总共21个的场景,在这些有的场景在第5步的效用树叶上,但是在第1阶段并没有进行分析。
这样做不仅正确而且值得鼓励,涉众以这种方式表达了他们的观点:
有一些场景要比第一阶段的场景值得投入更多的尽力。
下表给出了部分在本步骤中提出的部分更感兴趣场景。
表3:
集体讨论确定的场景(部分)
场景号
场景
1
将以前公用的数据变为私有,并据此调整访问权限
2
写入过程中的一个错误导致本地数据库无法和服务器数据库同步
3
一个组织将大量可支付账户卖给了另一个组织
4
手机用户和客户端不在同一服务区
5
手机用户在客户端为发送短信的情况下向客户端莫用户求助
6
系统中的一个错误导致客户端不能向服务端缴纳费用
7
支持英文版
8
高级管理员想要一份旗下管理员的消费状况账单
9
需要使两个来自不同服务区的客户端同时生成短信报表
10
服务端规则引擎中某条规则被激发,数据访问太慢
把几个类似场景合并后,涉众进行投票,我们给每个涉众发放了6张选票(21个场景的30%),涉众投票选举出6个优先级排名最高的场景放在第5步的树叶上。
4.2分析构架方法
在对新的场景与效用树进行后,我们开始分析得票最多的场景,考虑到空间限制,我们只对其中的一个场景进行了总结。
4.3结果表述
这一步骤是一次长达半个小时的表述,它总结了次次评估的结果。
这一步开始时先提供了一组包含方法概述的样本幻灯片,然后提供了一些可以在其中添上商业动机总结、架构总结、方法列表、效用树、场景分析以及分析结果列表的空白的模版幻灯片。
对于短信平台,我们确立了5个风险题:
(1)防止短信平台成为有些学生或其他组织的广告工具,影响广大群众的正常生活。
(2)当众多团队涉足断行行业领域之后,如何防止出现新一轮的恶性竞争和内容的同质化,是一个需要仔细思考的问题。
(3)团队开发起步相对较晚,根据先入为主的市场规则,从竞争对手中夺取用户资源的难度增大,新市场的拓宽会因为市场经验的不足而进程变慢。
(4)由于市场逐渐走向成熟,需要更加有竞争力和价值的产品才能吸引用户。
(5)平台开发入门槛较低,产品容易被模仿,需要及时更新设计以摆脱竞争对手。
5.第3阶段:
后续工作
ATAM评估的一个具体结果就是生成了最终报告,该报告包括一个有风险决策、误风险决策、敏感点和权衡点的列表。
他还包括一个涉及如下内容的目录:
所使用的架构方法、效用树、经过集体讨论确定的场景以及所选择的每个场景的分析记录。
最后,最终报告还包括由该评估小组所确定的风险主题的集合,并指出了每个风险主题所危及的商业动机。
像结果的表述一样,我们使用一个样板文件模版,其中有许多已完成的标准部分(例如ATAM描述),以及有待填充内容的其它部分。
这个时候,准备工作得到了回报:
过去需要花费大量时间为ATAM客户生成最终报告,现在越半天就可以得到完成。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 短信 平台 架构 评审 报告