某集团软件设计规范V2.docx
- 文档编号:7230573
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:8
- 大小:75.81KB
某集团软件设计规范V2.docx
《某集团软件设计规范V2.docx》由会员分享,可在线阅读,更多相关《某集团软件设计规范V2.docx(8页珍藏版)》请在冰豆网上搜索。
某集团软件设计规范V2
内部资料注意保密
某集团
软件设计规范
(版本:
V1.0)
文档修订记录
文档安全
版本编号
说明:
如形成文件、变更内容和变更范围
日期
执行人
审核日期
审核人
1.
软件设计概述
软件设计是把需求转化为软件系统的最重要的环节,系统设计的优劣在根本上决定了软件系统的质量。
软件系统设计通常包括五个核心内容:
体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。
一般把设计过程划分为两个阶段:
概要设计阶段和详细设计阶段,如下所示:
⏹概要设计阶段的重点是体系结构设计。
⏹详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计等。
可根据项目的情况进行文档裁减和过程合并,如项目开发过程只有一个设计阶段和设计文档。
2.软件设计时间定义
通常来说,与用户完成前期交流为用户编写方案时,就涉及到了软件设计。
主要包括体系结构设计与模块设计。
在于用户进行需求交流的过程中,涉及到用户界面设计、模块设计。
需求已确认,项目进行到详细设计阶段,主要工作是模块设计、数据库设计(实体设计)、数据结构和算法设计。
3.软件设计规范定义
3.1体系结构
根据与用户的前期交流和以往经验,考虑软件结构模式,把用户需求落实到具体系统中去,也就是说把用户的项目划分为一个或多个子系统。
以下为体系结构的设计原则:
3.1.1合适性
即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。
设计出恰好满足客户需求的软件,并且使开发方和客户方获取最大的利益,而不是不惜代价设计出最先进的软件。
3.1.2结构稳定性
详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等,都是在体系结构确定之后开展的,而编程和测试则是更后面的工作,因此体系结构应在一定的时间内保持稳定。
软件开发最怕的就是需求变化,但“需求会发生变化”是个无法逃避的现实。
人们希望在需求发生变化时,最好只对软件做些皮皮毛毛的修改,可千万别改动软件的体系结构。
如果当需求发生变化时,程序员不得不去修改软件的体系结构,那么这个软件的系统设计是失败的。
设计者应当能够分析需求文档,判断出哪些需求是稳定不变的,哪些需求是可能变动的。
于是根据那些稳定不变的需求设计体系结构,而根据那些可变的需求设计软件的“可扩展性”。
3.1.3可扩展性
可扩展性是指软件扩展新功能的容易程度。
可扩展性越好,表示软件适应“变化”的能力越强,从而应对用户反复无常的需求变更!
3.1.4可复用性
在一个新项目中,有些功能是成熟的。
如何把我们已经积累的功能、系统应用到新项目中去,从而提高工作效率,保证项目质量。
同时要善于发现新项目中一些通用的功能、系统,尽可能的从项目中独立出来作为今后工作的积累。
3.2用户界面设计
为了提高用户界面的易用性和美观程度,总结了十个设计原则。
用于提高易用性的界面设计原则有8个:
3.2.1用户界面适合于软件的功能
用户界面的合适性是指界面与软件功能相融洽的程度。
软件的功能需要通过用户界面来展现,用户界面一定要适合于软件的功能,这是最基本的要求。
界面的合适性既提倡外美内秀,又强调恰如其分。
3.2.2容易理解
提高用户界面可理解性的一些规则如下:
⏹界面中的所有元素(如菜单、工具条等)没有错误,也不会让人误解。
⏹所有的界面元素应当提供充分而必要的提示,例如当鼠标移动到工具条上的某个图标按钮时,应当在该图标旁边出现功能提示。
⏹界面结构能够清晰地反映工作流程,以便用户按部就班地操作。
⏹对于复杂的用户界面而言,最好提供界面“向导”,及时让用户知道自己在界面结构中所处的位置。
例如对于基于Web的应用软件,应该在界面上显示“当前位置”,否则用户很容易在众多的页面中迷失方向。
3.2.3风格一致
风格一致有两方面的含义:
一个软件的用户界面中,同类的界面元素应当有相同的视感和相同的操作方式。
例如命令按钮是最常见的界面元素,所有命令按钮的形状、色彩以及对鼠标的响应方式都是一致的。
同一类型软件的用户界面应当有一定程度的相似性。
例如Microsoft公司的Office家族里有Word、Excel、PowerPoint、Outlook等软件,这些软件提供的“复制、剪切、粘贴”功能的操作方式都是相同的。
3.2.4及时反馈信息
用户进行某项操作后,如果过了一会儿(几秒钟)用户界面一点反应都没有,这将使用户感到迷茫和不安,因为他不知道是自己操作错了还是软件的原因导致死机了。
所以及时反馈信息很重要,至少要让用户心里有数,知道该任务处理得怎么样了,有什么样的结果。
例如下载一个文件,界面上应当显示“百分比”或相关数字来表示下载的进度,否则人们不知道要等待多少时间。
如果某些事务处理不能提供进度等数据,那么至少要给出提示信息如“正在处理,请等待…”,最好是提供合适的动画,让用户明白软件正在干活、没有死机。
3.2.5出错处理
在设计用户界面时必须考虑出错处理,目的是让用户不必为避免犯错误而提心吊胆、小心翼翼地操作。
常见的错误处理方式有:
提供对输入数据进行校验的功能。
当用户输入错误的数据时,及时提醒用户改正数据。
对于在某些情况下不应该使用的菜单项和命令按钮,将其“失效”(屏蔽)可以有效防止该项功能被错误地使用。
例如:
对于某些管理软件,不同的用户有不同的操作权限。
如果低权限的用户登录到系统,那些只有高级权限用户才能使用的功能应当被屏蔽(如变成“灰色”不可操作)。
提供Undo功能,用以撤销不期望的操作。
执行破坏性的操作之前,应当获得用户的确认。
例如用户删除一个文件时,应当弹出对话框:
“真的要删除该文件吗”,当用户确认后才真正删除文件。
3.2.6合理的布局
首先,界面的布局应当符合逻辑,最好能够与工作流程吻合。
界面设计人员只有仔细地分析软件的需求,才能提取对界面布局有价值的信息。
其次,界面的布局应当整洁(整齐清爽)。
界面元素应当在水平或者垂直方向对齐,行、列的间距保持一致。
窗体的尺寸要合适,各种控件不能过分拥挤也不能过分宽松。
要善于利用窗体和控件的空白,以及分割用的线条。
3.2.7和谐的色彩
用户界面是否美观,主要取决于该界面的布局和色彩搭配。
实现“合理的布局”相对比较容易一些,设计和谐的色彩太困难了,因为色彩的组合千变万化,并且人们对颜色的喜好也极不相同。
对于广大软件开发人员而言,虽然我们没有必要让普通软件的界面漂亮到WindowsXP这种程度,但是掌握一些界面色彩的设计原则无疑是非常有益的。
如果不是为了显示真实感的图形和图像,那么应当限制一帧屏幕的色彩数目,因为人们在观察屏幕的时候很难同时记住多种色彩。
应当根据对象的重要性来选择颜色,重要的对象应当用醒目的色彩表示。
使用颜色的时候应当保持一致性,例如错误提示信息用红色表示,正常信息用绿色表示,那么切勿篡用红色和绿色。
在表达信息时,不要过分依赖颜色,因为有些用户是色盲或色弱。
3.3数据库设计
我们过去以表结构设计为主,如果使用Hibernate框架可以考虑采用实体设计,实体设计的好处在于更直观、更方便,而且通过框架特性可以自动生成相应的表结构。
推荐使用实体设计。
3.3.1数据库选择
没有特殊要求的情况下一律使用Oracle,便于管理、协助解决问题。
3.3.2数据库性能优化问题
数据库设计的主要挑战是“高速处理大容量的数据”。
如何优化数据库的性能是设计人员经常面临的问题。
数据库性能优化主要有两种途径:
优化表结构本身。
例如对第三范式的表结构进行反规范化处理,允许表中存在冗余数据,从而减少多个表链接操作,达到提高性能的目的。
合理使用数据库索引,在大数据量的情况下,完善的索引可以大大提高表的查询速度!
对于海量数据表可以采用表分区或者其他技术手段。
3.3.3规范化表结构设计的讨论
在表的物理设计阶段,通常设计人员应当按照第三范式设计表结构(即规范化处理)。
这样做的好处是:
表中没有冗余数据,表结构很清晰,将来修改或者扩充非常方便。
但是按第三范式设计也存在一些缺点:
产生了许多表,每个表有相对较少的列,并且这些列必须使用“主健/外健”关联起来,因此某个查询操作可能会产生复杂的表链接,导致性能降低。
反规范化处理是指对第三范式的表进行修改,通过合并一些表,或者在表中创建冗余的列,从而减少表链接操作代价,达到提高性能的目的。
要注意的是反规范化处理存在很大的负面影响:
管理冗余数据很麻烦,如果冗余数据不同步的话,那么会发生数据错误这种严重的问题。
所以,对表进行第三范式的规范化处理是第一重要的,而反规范化处理则需谨慎考虑、不宜过多使用。
“规范化处理”以及“反规范化处理”不是自相矛盾之举,而是性能优化的策略。
3.3.4硬件条件的讨论
除了优化表结构之外,优化数据库的环境参数也能够提高数据库的性能。
例如给服务器配置更快的CPU,增加内存。
运行数据库是非常消耗内存的,内存对数据库性能影响比较大。
由于现在市场上的内存条越来越便宜,所以为服务器配置足够多的内存恐怕是成本最低、难度最低、见效最快的性能优化方法。
3.3.5数据库安全
提高软件系统的安全性应当从“管理”和“技术”两方面着手。
这里仅考虑技术手段(因为安全管理超出了软件工程范畴),一般原则如下:
用户只能用帐号登陆到应用软件,通过应用软件访问数据库,而没有其它途径可以操作数据库。
对用户帐号的密码进行加密处理,确保在任何地方都不会出现密码的明文。
确定每个角色对数据库表的操作权限,如创建、检索、更新、删除等。
每个角色拥有刚好能够完成任务的权限,不多也不少。
在应用时再为用户分配角色,则每个用户的权限等于他所兼角色的权限之和。
3.3.6保障程序安全
建立数据库表时,一定要加上约束条件!
即便是开发阶段。
不要怕麻烦,不要偷懒。
在系统上线后,约束条件一定在程度上能够抵御因为程序错误而带来的灾难,真的能够在灾难来临前救你一命。
程序报错比脏数据要好处理的多!
3.4模块设计
在设计好软件的体系结构后,就已经在宏观上明确了各个模块应具有什么功能,应放在体系结构的哪个位置。
我们习惯地从功能上划分模块,保持“功能独立”是模块化设计的基本原则。
因为,“功能独立”的模块可以降低开发、测试、维护等阶段的代价。
但是“功能独立”并不意味着模块之间保持绝对的孤立。
一个系统要完成某项任务,需要各个模块相互配合才能实现,此时模块之间就要进行信息交流。
评价模块设计优劣的三个特征因素:
“信息隐藏”、“内聚与耦合”和“开闭原则”。
3.4.1信息隐藏
为了尽量避免某个模块的行为去干扰同一系统中的其它模块,在设计模块时就要注意信息隐藏。
应该让模块仅仅公开必须要让外界知道的内容,而隐藏其它一切内容。
模块的信息隐藏可以通过接口设计来实现。
接口是模块的外部特征,应当公开;而数据结构、算法、实现体等则是模块的内部特征,应当隐藏。
一个模块仅提供有限个接口,执行模块的功能或与模块交流信息必须且只须通过调用公有接口来实现。
3.4.2高内聚
内聚是一个模块内部各成分之间相关联程度的度量。
内聚程度从低到高大致划分为低端、中段和高端。
模块设计者没有必要确定内聚的精确级别,重要的是尽量争取高内聚,避免低内聚。
3.4.3低耦合
耦合是模块之间依赖程度的度量。
内聚和耦合是密切相关的,与其它模块存在强耦合的模块通常意味着弱内聚,而强内聚的模块通常意味着与其它模块之间存在弱耦合。
耦合的强度依赖于以下几个因素:
一个模块对另一个模块的函数调用数量;一个模块向另一个模块传递的数据量;一个模块施加到另一个模块的控制的多少;模块之间接口的复杂程度。
耦合程度从低到高大致划分为低端、中段和高端。
模块设计应当争取“高内聚、低耦合”,而避免“低内聚、高耦合”。
3.5数据结构与算法设计
数据结构与算法设计的一般流程如下:
(1)数据结构与算法有全局和局部之分,当然先设计全局的,后设计局部的(通常在模块设计时进行)。
(2)根据问题的特征,先查找已经存在的数据结构与算法,挑选最合适的(并不一定是最先进的)。
如果不存在现成的,那么自己设计。
(3)设计并且编写代码之后,要进行测试。
如果不满足性能要求,那么要进一步优化数据结构和算法。
4.软件设计规范流程
1.售前人员与用户进行前期交流编写售前方案。
2.评审售前方案,如果不通过进行修订,如果通过可以交付给用户。
3.立项、需求调研阶段完成后,进行系统详细设计。
4.在详细设计评审前需要与相关评审人员召开需求碰头会,会议的形式灵活,目的使评审人员了解项目需求。
5.在相关评审人员充分理解项目需求后召开详细设计评审会。
6.详细设计评审会通过项目组可以进行实现开发,不通过继续修改系统设计。
5.软件设计相关文档
详见附件。
6.软件设计有关的问题思考
1.系统的问题更多是来自于糟糕的设计而不是糟糕的代码
2.谈谈你对模块设计和系统架构之间的关系及理解
3.你如何看待设计模式
4.设计并非一蹴而就,需要不断的修正完善
5.如何理解使用更合适的技术而不是更先进的技术
6.如何理解开发的规范性和创造性之间的关系
7.给自己重构的勇气
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 集团 软件设计 规范 V2