软件设计方案(编程规范总则)

 

1、排版

1)程序块要采用缩进风格编写,缩进的空格数为4个,对于由开发工具自动生成的代码可以不一致;

2)相对独立的程序块之间、变量说明之后必须加空行;

3)较长的语句要分成多行书写,长表达式要在低优先级操作符处划分新行,操作符放在新行之首,划分出的新行要进行适当的缩进,使排版整齐,语句可读;

4)循环、判断等语句中若有较长的表达式或语句,则要进行适应的划分,同3);

5)若函数或过程中的参数较长,也要进行适当的划分;

6)不允许把多个短语句写在一行中,即一行只写一条语句;

7)iffordowhilecaseswitchdefault等语句自占一行,且iffordowhile等语句的执行语句部分无论多少都要加括号{};

8)对齐只使用空格键,不使用TAB键;

9)函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格,case语句下的处理语句也要遵从语句缩进要求;

10)程序块的分界符(如大括号‘{’和‘}’)应各独占一行并且位于同一列,同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及iffordowhileswitchcase语句中的程序都要采用如上的缩进方式;

11)在两个以上的关键字、变量、常量进行对等操作时,它们之间的操作符之前、之后或者前后要加空格,但不要连续留两个以上空格。进行非对等操作时,如果是关系密切的操作符(如->)后不应加空格。

采用这种松散方式编写代码的目的是使代码更加清晰,在已经非常清晰的语句中没有必要再留空格。如果语句已足够清晰,则括号内侧(即左括号后面和右括号前面)不需要加空格,多重括号间也不必加空格。 在长语句中,如果需要加的空格非常多,那么应该保持整体清晰,而在局部不加空格。

(1)逗号、分号只在后面加空格。

int a, b, c;  

(2)比较操作符、赋值操作符、算术操作符、逻辑操作符、位操作符等双目操作符的前后加空格。

a = b + c;

a *= 2;

a = b ^ 2;

(3)"!"、"~"、"++"、"--"、"&"(地址运算符)等单目操作符前后不加空格。

flag = !isFull;

p = &com;       

i++;            

(4)"->"、"."前后不加空格。

(5)ifforwhileswitch等与后面的括号间应加空格,使if等关键字更为突出、明显。

if (a >= b && c > d)

12)一行程序以小于80字符为宜,不要写得过长。

2、注释

注释应该说明代码的目的,要讲清为什么要那么做,而不是怎么去做。 1)一般情况下,源程序有效注释量必须在20%以上。注释的原则是有助于对程序的阅读理解,在该加的地方都加,注释不宜太多也不能太少,注释语言必须准确、易懂、简洁;

2)注释格式尽量统一,建议使用“/* …… */”;

3)说明性文件(如头文件.h文件、.inc文件等)头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系等,头文件的注释中还应有函数功能简要说明;

4)源文件头部应进行注释,列出:版权说明、版本号、生成日期、作者、模块功能、主要函数及其功能等;

5)函数头部应进行注释,列出:函数功能、输入参数、输出参数、返回值等;

6)边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性;

7)避免在注释中使用缩写,特别是非常用的缩写。如无法避免,应对缩写进行必要的说明;

8)注释应与其描述的代码相近,对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,如放于上方则需与其上面的代码用空行隔开;

9)变量、常量、宏的注释有时也是必须的,应放在其上方相邻位置或右方;

10)数据结构声明(包括数组、结构、类、枚举等),如果其命名不是充分自注释的,必须加以注释。对数据结构的注释应放在其上方相邻位置,对结构中的每个域的注释放在此域的右方;

11)全局变量要有较详细的注释,包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明;

12)将注释与其上面的代码用空行隔开,注释与所描述内容进行同样的缩排;

13)对变量的定义和分支语句(条件分支、循环语句等)必须编写注释。这些语句往往是程序实现某一特定功能的关键,对于维护人员来说,良好的注释帮助更好地理解程序,有时甚至优于看设计文档;

14)通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构,使代码成为自注释的,减少不必要的注释;

15)当代码段较长,特别是多重嵌套时,在程序块的结束行右方加注释标记,以表明某程序块的结束;

16)建议注释多使用中文,除非能用非常流利准确的英文表达。

3、标识符命名

1)标识符的命名要清晰明了,有明确含义,同时使用完整的单词或大家基本可以理解的缩写,避免使人产生误解。较长的单词可取单词的头几个字母形成缩写,一些单词有大家公认的缩写;

2)命名中若使用特殊约定或缩写,应该在源文件的开始之处,进行必要的注释说明;

3)命名风格要自始至终保持一致;

4)对于变量命名,禁止取单个字符(如i、j、k...)。单个字符容易敲错,且编译时又不易检查出来。建议除了要有具体含义外,还能表明其变量类型、数据类型等,但i、j、k作局部循环变量是可以的;

5)命名规范必须与所使用的系统风格保持一致,并在同一项目中统一。除非必要,不要用数字或较奇怪的字符来定义标识符;

6)在同一软件产品内,应规划好接口部分标识符(变量、结构、函数及常量)的命名,防止编译、链接时产生冲突;

7)用正确的反义词组命名具有互斥意义的变量或相反动作的函数等;

下面是一些在软件中常用的反义词组:

add / remove       begin / end         create / destroy

insert / delete       add / delete         get / release

increment / decrement                  put / get

lock / unlock       open / close         first / last  

min / max          old / new          start / stop

next / previous      send / receive       show / hide

source / target       source / destination

cut / paste          up / down

8)除了特殊应用,应避免使用以下划线开始和结尾的定义。

4、可读性

1)注意运算符的优先级,并用括号明确表达式的操作顺序,避免使用默认优先级;

2)避免使用不易理解的数字,用有意义的标识来替代;

3)源程序中关系较为紧密的代码应尽可能相邻,便于程序阅读和查找;

4)不要使用难懂的技巧性很高的语句,除非很有必要时。程序的高效率并不等同于语句的高技巧,而在于算法。

5、变量与结构

1)去掉没必要的公共变量,以降低模块间的耦合度;

2)仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系;

3)明确公共变量与操作此公共变量的函数或过程的关系,如访问、修改及创建等。这种关系的说明可在注释或文档中描述;

4)当向公共变量传递数据时,要十分小心,防止赋与不合理的值或越界等现象发生。若有必要应进行合法性检查,以提高代码的可靠性、稳定性;

5)构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象;

6)使用严格形式定义的、可移植的标准数据类型,尽量不要使用与具体硬件或软件环境关系密切的变量;

7)结构的功能要单一,是针对一种事务的抽象。结构中的各元素应代表同一事务的不同侧面,而不应把描述没有关系或关系很弱的不同事务的元素放到同一结构中;

8)不同结构间的关系不要过于复杂,否则应合为一个结构;

9)仔细设计结构中元素的布局与排列顺序,使结构容易理解、节省占用空间,并减少引起误用的现象;

10)结构的设计要尽量考虑向前兼容和以后的版本升级,并为某些未来可能的应用保留余地;

11)留心具体语言及编译器处理不同数据类型的原则及有关细节;

12)编程时,要注意数据类型的强制转换。对编译系统默认的数据类型转换要有充分的认识,尽量减少没有必要的数据类型默认转换与强制转换,合理地设计数据并使用自定义数据类型,避免数据间进行不必要的类型转换;

13)对自定义数据类型进行恰当命名,使它成为自描述性的,以提高代码可读性,但要注意其命名方式在同一产品中的统一。

6、函数与过程

1)设计高扇入、合理扇出(小于7)的函数。较良好的软件结构通常是顶层函数的扇出较高,中层函数的扇出较少,而底层函数则扇入到公共模块中;

2)函数的规模尽量限制在200行以内,不包括注释和空格行;

3)对所调用函数的错误返回码要仔细、全面地处理;

4)在同一项目组应明确规定对接口函数参数的合法性检查应由函数的调用者负责还是由接口函数本身负责,缺省是由函数调用者负责;

5)防止将函数的参数作为工作变量。对必须改变的参数,最好先用局部变量代之,再将该局部变量的内容赋给该参数;

6)一个函数仅完成一件功能,不要设计多用途的函数。函数名应准确描述函数的功能;

7)函数的功能应该是可以预测的,也就是说只要输入数据相同就应产生同样的输出;

8)避免设计多参数函数,不使用的参数从接口中去掉,减少函数间接口的复杂度;

9)非调度函数应减少或防止控制参数,尽量只使用数据参数,防止函数间的控制耦合;

10)检查函数所有参数输入与非参数输入的有效性;

11)在编程时,经常遇到在不同函数中使用相同的代码,许多开发人员都愿把这些代码提出来,并构成一个新函数。若这些代码关联较大并且是完成一个功能的,那么这种构造是合理的,否则这种构造将产生随机内聚的函数;

12)功能不明确且较小的函数,特别是仅有一个上级函数调用它时,应考虑把它合并到上级函数中,而不必单独存在;

13)减少函数本身或函数间的递归调用。除非为某些算法或功能的实现方便,应减少没必要的递归调用;

14)仔细分析模块的功能及性能需求,并进一步细分,若有必要画出有关数据流图,据此来进行模块的函数划分与组织;

15)对于提供了返回值的函数,在引用时最好使用其返回值;

16)当一个过程(函数)中对较长变量(一般是结构的成员)有较多引用时,可以用一个意义相当的宏代替。

7、可测性

1)在同一项目组或产品组内,要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数,并且要有详细的说明;

2)在同一项目组或产品组内,调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名(或源文件名)及行号;

3)编程的同时要为单元测试选择恰当的测试点,并仔细构造测试代码、测试用例,同时给出明确的注释说明。测试代码部分应作为(模块中的)一个子模块,以方便测试代码在模块中的安装与拆卸(通过调测开关);

4)使用断言来发现软件问题,提高代码可测性。用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况,但不能用断言来检查最终产品肯定会出现且必须处理的错误情况;

5)对较复杂的断言加上明确的注释,用断言确认函数的参数,保证没有定义的特性或功能不被使用,对程序开发环境的假设进行检查;

6)正式软件产品中应把断言及其它调测代码去掉(即把有关的调测开关关掉),以加快软件运行速度;

7)在软件系统中设置与取消有关测试手段,不能对软件实现的功能等产生影响;

8)用调测开关来切换软件的DEBUG版和正式版,而不要同时存在正式版本和DEBUG版本的不同源文件,以减少维护的难度;

9)软件的DEBUG版本和发行版本应该统一维护,不允许分家,并且要时刻注意保证两个版本在实现功能上的一致性;

10)在编写代码之前,应预先设计好程序调试与测试的方法和手段,并设计好各种调测开关及相应测试代码如打印函数等;

11)调测开关应分为不同级别和类型。针对模块或系统某部分代码的调测,针对模块或系统某功能的调测,对性能、容量等的测试;

12)编写防错程序,然后在处理错误之后可用断言宣布发生错误。

8、程序效率

1)在保证软件系统的正确性、稳定性、可读性及可测性的前提下提高代码效率,包括全局效率、局部效率、时间效率及空间效率;

2)局部效率应为全局效率服务,不能因为提高局部效率而对全局效率造成影响;

3)通过对系统数据结构的划分与组织的改进,以及对程序算法的优化来提高空间效率;

4)仔细考虑循环体内的语句是否可以放在循环体之外,使循环体内工作量最小,从而提高程序的时间效率;

5)仔细考查、分析系统及模块处理输入(如事务、消息等)的方式,并加以改进;

6)对模块中函数的划分及组织方式进行分析、优化,改进模块中函数的组织结构,提高程序效率;

7)不应花过多的时间拼命地提高调用不很频繁的函数代码的效率;

8)仔细地构造或直接用汇编编写调用频繁或性能要求极高的函数。嵌入汇编可提高时间及空间效率,但也存在一定风险;

9)在保证程序质量的前提下,通过压缩代码量、去掉不必要代码以及减少不必要的局部和全局变量,来提高空间效率;

10)尽量减少循环嵌套层次。在多重循环中,应将最忙的循环放在最内层,以减少CPU切入循环层的次数;

11)避免循环体内含判断语句,应将循环语句置于判断语句的代码块之中;

12)尽量用乘法或其它方法代替除法,特别是浮点运算中的除法;

13)不要一味地追求紧凑的代码,因为紧凑的代码并不代表高效的机器码。

9、质量保证

1)在软件设计过程中构筑软件质量;

2)代码质量保证优先原则

(1)正确性,指程序要实现设计要求的功能;

(2)稳定性/安全性,指程序稳定、可靠、安全;

(3)可测试性,指程序要具有良好的可测试性;

(4)规范/可读性,指程序书写风格、命名规则等要符合规范;

(5)全局效率,指软件系统的整体效率;

(6)局部效率,指某个模块、子模块、函数的本身效率;

(7)个人表达方式,指个人编程习惯。

3)只引用属于自己的存贮空间;

4)防止引用已经释放的内存空间;

5)过程/函数中分配的内存,在过程/函数退出之前要释放;

6)过程/函数中申请的(为打开文件而使用的)文件句柄,在过程/函数退出之前要关闭;

7)防止内存操作越界;

8)认真处理程序所能遇到的各种出错情况;

9)系统运行之初,要初始化有关变量及运行环境,防止未经初始化的变量被引用,并对加载到系统中的数据进行一致性检查;

10)严禁随意更改其它模块或系统(不属于自己)的有关设置和配置,不能随意改变与其它模块的接口;

11)注意易混淆的操作符。当编完程序后,应从头至尾检查一遍这些操作符,以防止拼写错误;

12)有可能的话,if语句尽量加上else分支,对没有else分支的语句要小心对待。switch语句必须有default分支;

13)不使用与硬件或操作系统关系很大的语句,而使用建议的标准语句,以提高软件的可移植性和可重用性;

14)精心构造算法,并对其性能、效率进行测试,对较关键的算法最好使用其它算法来确认;

15)注意表达式是否会上溢、下溢,使用变量时要注意其边界值;

16)系统应具有一定的容错能力,对一些错误事件(如用户误操作等)能进行自动补救;

17)对一些具有危险性的操作代码要仔细考虑,防止对数据、硬件等的安全构成危害,以提高系统的安全性。

10、代码编辑、编译与审查

1)同产品软件(项目组)内,最好使用相同的编辑器,并使用相同的设置选项;

2)打开编译器的所有告警开关对程序进行编译;

3)通过代码走读及审查方式对代码进行检查;

4)编写代码时要注意随时保存,并定期备份,防止由于断电、硬盘损坏等原因造成代码丢失;

5)某些语句经编译后产生告警,如果你认为它是正确的,那么应通过某种手段去掉告警信息;

6)使用代码检查工具对源程序检查,使用软件工具进行代码审查。

11、代码测试与维护

1)单元测试要求至少达到语句覆盖;

2)整理或优化后的代码要经过审查及测试;

3)代码版本升级要经过严格测试;

4)使用工具软件对代码版本进行维护;

5)正式版本上软件的任何修改都应有详细的文档记录;

6)发现错误立即修改,并且要记录下来;

7)关键的代码在汇编级跟踪;

8)仔细设计并分析测试用例,使测试用例覆盖尽可能多的情况,以提高测试用例的效率;

9)尽可能模拟出程序的各种出错情况,对出错处理代码进行充分的测试;

10)仔细测试代码处理数据、变量的边界情况;

11)保留测试信息,以便分析、总结经验及进行更充分的测试;

12)不应通过“试”来解决问题,应寻找问题的根本原因;

13)对自动消失的错误进行分析,搞清楚错误是如何消失的;

14)测试时应设法使很少发生的事件经常发生;

15)明确模块或函数处理哪些事件,并使它们经常发生;

16)坚持在编码阶段就对代码进行彻底的单元测试,不要等以后的测试工作来发现问题;

17)去除代码运行的随机性,让函数运行的结果可预测,并使出现的错误可再现。

 

  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
范围:CPU上可以识别的代码和数据。全部的代码总和。 要求:从定义开始的设计。完整性,彻底地定义从无开始的整个设计。这是因为软件之软,也是因为硬件平台的多样性和特殊性。 完整把握,从头设计是第一原则。因为软件世界自己并不能统一,还有继续分化的趋势。没有根本一致的基础可能是软件的本性。退回到一无所有是处理软件问题的根本。 在这样的视野下,操作系统只是一个部分,一个模块,不同的操作系统任你选择;语言的选择是运行环境的选择(每种语言有每种语言的运行时布局);所谓框架只是“类库+运行环境”的一种构造。 没有对其负载能力、操作强度进行评估前,这些东西(操作系统、语言、框架)还都不能纳入设计规范。 性能:运行过程的收敛(长时间运行的均态)。操作强度设计(串行处理速度),负载能力设计(并发处理的量)。可靠性设计。 软件问题的3个方面: 1、硬件,软件的操作对象和运行软件的数字系统(CPU系统和数字加速硬件) 2、交互操作(界面),专业界面设计 3、软件调度性能,实时的自动化过程(设备控制和自动测量)和用户交互过程(请求服务过程和干预过程;本地交互和远程交互),程控和网络访问的调度(服务器)。 软件项目的3个部分:(把3个阶段由纵向横过来,进行统筹) 分解文档,集成平台,可维护性要求。 软件设计必须有自说明特性。不能对文档产生依赖性。软件代码中合适的地方,需要对文档进行恰如其分说明。原则是,每段代码,每处需要理解的地方,如果和总体架构相关,就要有说明。 软件领域需要简化。需要还原软件本来的面目。EDA有泛滥的趋势,软件的各个方面都需要简化。软件形态、需求分析、文档说明、开发工具等。 需求分析过分强调适应生命周期的变化和没有需求分析是一样的。不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。 软件只有一个,而观察的视角很多。要采用最适合的观察视角,让软件一目了然。 软件的生成过程和观察过程是两个不同的观念。生成过程又可以区分为:研究过程和工程过程。研究过程可以通过结果,研究报告反映;工程过程则必须采用过程刻画。 软件规范使用的语言一定要有普遍语义,但描述本身具有特殊性;不能强求它的全球唯一。一定要雄视全体,才能选择正确的立足点,这就要求对目前的软件技术有一个了解;要考虑纳入新的发展,那么规范应该分层,把一般的和具体易变的成分分开;要有具体的指导意义,越具体指导意义越大,但通用性则越小。 所谓架构,可能是十分具体应用的代表;不同类别的应用必然有不同的架构。软件架构本身是“应用架构”。因此,不能规范具体的架构。到是可以做:应用架构规范规范。 逻辑架构的特殊性。可以判断,任何一款实用的软件采取的软件逻辑抽象都是别样的,特例的逻辑。否则,软件不可能那么轻快实用。软件逻辑,鬼魅也。而需求分析,必须是现实实用的,而不是同构/仿真的-这似乎是反对象分析的。因为这里强调的是和软件的交互界面,这个界面远远没有反映现实世界的结构。须知,软件强调的是数据处理,是输入输出。否则,就不能达到最简化。 可能现实世界的结构映射,最适合的方式是数据库 - 采用纯数据结构进行映射。除此之外,能有更合适的技术吗? 面向对象建模是吗?那么对象又如何与现实世界的对象绑定在一起呢? 这再次表明,在软件技术和需求分析之间有鸿沟。软件技术作为特殊的技术,有它的有限性。也反映了,包含软件应用在内的现实架构已经固定。 如果软件是数据处理,是输入输出,那么软件结构也就可以确定了! 可视化、用户操作界面解开了另外的软件世界,因为可视化可以代表用户更抽象的逻辑。用户希望操作可视对象,象操作现实对象一样。软件从模拟现实对象的过程中继承了其结构。 工业控制也开启了新的软件世界,因为软件要从分离的输入建立“综合感知”,感知到设备状态,然后做出响应。 软件有其固有的物理属性,也就是计算的量。算法领域,无论算法的论证多么曲折,求得的结果,物化为软件,总是“早已熟知”的软件。这一区分,是定义软件规范的基石。 算法构造领域是和软件完全不同的领域,算法不是软件算法类似数学系统。也一如数学系统那样多样。 软件构造。算法总要转化为软件,这就是软件构造问题。寻址系统,数组。软件把自己的生成作为问题,给算法开辟了新的领域。软件生成,是一个“构造-编译”问题。手工构造,自动编译。语言的发展,是一个软件生成的历史。所谓统一建模,所谓设计模式,其实都是软件生成的问题。 需求分析。需求分析本质上是独立的。所谓OOA,面向对象的建模,把程序构造概念上升到需求分析领域可能是不对的。一个先验的,复杂的难于掌握的限制,只会让人对需求分析望而却步;即使勉强掌握,难求对需求分析的创造性发展。需求分析应该专注于需求分析本身,独立发展,一切为了准确、快捷的分析。 需求分析层次高一些,抽象一些,自由一些,这样可以充分表达需求的本质。反而可以促进更高级别的程序自动生成。 软件生成的历史。软件生成是为了解决人机沟通,让“计算机语言”更接近普通人的思维逻辑。把这种“高级计算机语言”翻译成可以执行的代码,就是软件生成(代码生成)的任务。而软件编制是专业人员的事情,因此语言问题的本质其实不那么重要。须知,经过培训,莫尔司码的电报发报可以比说话的语速还快!因此,计算机语言的前途迷茫;实际上也确实迷茫,历史上语言的层出不穷本身就说明了问题,至今仍然如此。在当今,必须建立这样的观点:语言是因人而异的;面对一个语言的时候,要清醒,首先明确“这是为谁设计的语言”;也就是说,需求分析之前的需求是要明确,让什么人来设计软件,然后为他们选择合适的语言。软件生成除了代码生成,还包括另外一个意思:软件构造。这在前面已经论述过了。只是,这里的软件构造机制已经在语言中奠定了。手工参与的软件构造只是语言给出的构造机制的应用。手工的软件构造就是语言构造机制的复制,产生大量的代码,应付实际问题的量。 立体构造。这里还有一个立体问题,实际问题的构造可能产生立体构造,如同建筑,基本的构件组装出复杂的立体结构。这里是建筑设计师的功劳。可能目前我们在语言层面上混淆不清的关键也在这里,没有区分语言和立体构造的责任。一个趋势是语言本身总是试图包揽建筑师的责任。把立体构造独立出来,带来的问题是:这个构造本身必须能够证明自己是正确的。1)能产生软件2)构造逻辑上正确,确实能解决应用问题。构造本身有一个属性,它有通用性。根本原理是通用的;总体构造本身具有一般性,也就是抽象性、实际问题无关性;局部构件具有通用性。也就是说,这里存在容器和容量的区别,构造是容器,实际问题是装在容器中的量。一个好的容器要能顶住容量的压力;一个好的建筑架构要能满足负载和抗振性要求。而架构本身的承受能力是客观的,只与架构本身有关。这也就是说,架构本身自我构造的,因此也就是科学。可能软件构造本身是澄清问题的工作,明确“容量”的特点,为软件构造的选择提供准确的依据,杀鸡不要用牛刀。实际问题的“容量”很容易测量,因为它反映为应用的规模,流程的流量。(架构是什么?架构是否存在?如果我们所说非虚,那么如何为架构下一个定义-一定是一个由具体业务流量和模式支撑的架构) 软件算法)的构造。一个是数据的复杂性(内在互相关系),一个是计算方法(步骤和缓冲)。从宏观角度,数据关系是更根本的东西。目前的高级语言,变量和流程(顺序、分支-步骤;循环-缓冲和迭代)研究的多,而数据复杂性构造不足。 同构现象。CPU指令集合可以说是硬件直接实现的软件软件帝国从这里提取软件精神,并升华它。从硬件的角度,从寄存器和指令执行流程,体现出的是变量和迭代(顺序更迭,循环往复)。(迭代流程)基于固定寻址的变量,经过寻址接口,可以处理任意数据,从而把迭代流程变成了一般流程。CPU的基本过程,产生了指令和数据,指令天生具有子程序的基因(一般流程),数据天生具有数据结构(寻址能力)的基因。高级的构造一般也是这种结构的类似:设计一套类似CPU的机制,支撑程序和数据;独特的“寻址机制”和“CPU处理能力”是实现构造的核心机制;迭代是所有这种机制的动力学和构造方式。而数据化是“寻址机制”的基础。抽象是数据化的工厂,也因此必须研究抽象技术。 抽象技术。所谓抽象,就是具体化,是范围的界定和比对(两种具体化对象之间的比对)。如果范围界定的完整,那么比对建立的联系就是普遍联系,普遍联系也就是所谓抽象原则。 评价标准。软件架构需要评测。这种评测是“在商言商”似的评测。评测的基础是软件架构的具体化。当掌握了架构的构造方法,每种架构本身也就具体化,是一种具体的架构。一种具体化的架构,就可以识别;可以识别则可以客观评测。可以按照立体架构的“压力”、“流量”等概念进行评测。 需求的把握-需求的变化。我们希望永恒不变的需求,核心需求和需求方式(表现和满足步骤);而事实上需求总在演化。软件必须无条件、最大限度地方便需求的表达和需求的满足。软件可能永远只是皮肤,需求源于现实核心深处,软件是一件衣服。这种观点下,软件是没有中心的一种架构。软件架构和需求之间联系的定量评测。 软件算法的分开 软件的构造作为软件的通用属性 需求的独立 推论:算法是应用的算法。比如数学公式的计算、图形图象的处理、频谱分析、词法和语法分析。因此算法不是通用的软件算法。也因此软件构造是软件规范的一部分,因为它是通用的软件构造技术。 计算技术和应用之间有明显的区别,是两种不同的成分。软件规范是纯粹的,只关心计算技术。而不关心应用建模。计算方法本身早已经被发现了(也就是怎么自动计算,或者说什么是可计算的),剩下的问题只是应用问题。把应用问题的解决纳入软件计算模式。自动计算技术在汇编指令集合那里得到了说明。所谓软件设计是把这种计算方式发扬广大。 所谓算法,就是明确问题,然后发现用自动计算的方式解决问题。从这个意义上说,软件是应用问题导向的。那么,也就是要以问题为中心谈论软件。不同类型的问题需要的解决方式有独特的强调。这也就反映为所谓不同的软件技术。所以,区分软件计算技术和应用问题的成分,是软件规范需要首先识别的东西。 解决问题。本质上是把问题装到变量里面的过程,是放大CPU寄存器的过程。表示层:(把局面、环境;起点和终点需要定义在一个世界里)装进去,组织起来。计算层(展开层):基于表示,定义问题解决步骤(定义运动和过程)。 需求分析。问题描述采用的方法可能应该和软件算法完全分开。否则不能发现问题描述的创造性方法,不能表达问题本质。阐述问题,写文章我们有某篇布局之法;哲学研究我们有严谨的逻辑方法。需求分析,我们一定可以创造自己的方法。这是什么方法?满足使用要求,满足使用流程。离散/隔离各个需求。事实上,面向外部的分析理解和面向内部的分析理解之间有鸿沟。因为这是两个不同的世界。在两个相差悬殊的世界之间,搭建的构造也必然多种多样,以奇为平常。那么,建立联系的媒介少的可怜。可能问题本身也正在于这种联系的分析和设计。 软件的量,是静态的。强调这部分就忽略了活跃的、奇异的、动态的部分。软件的出现不仅仅是被动地适应显示需求,同时也改变了现实需求本身。这种和现实需求融合在一起形成的状态,正是软件活跃的部分。在以前,仅仅以“应用软件”指称是不够的。(操作系统、编译软件、应用软件) 在范畴上,分为三个层次,或说3个范畴域: 1、 活跃的、黏性的动态层次。应用层。和现实之间的界面,是设备逻辑。需求简化、解决方案的奇异性;应用算法的专业性。这是软件形象最活跃的部分。 这里用的是抽象(业务流程)和具体(设备能力)统一的思维方法,构造逻辑的软件过程同时又是可以用具体进行描述的;动态的、物理的分析手段(物理的量)。 业务流程的设计几乎就是艺术设计。 2、 中间层。程序构造层。语言、编译技术、数据结构、设计方法(过程、数据、对象)等可以形式化的计算机科学的任务。对程序能力进行抽象,设计程序自动化生成的一套系统:语言、计算系统、编译系统。这是在静态和活跃部分之间的层次。这里的观念:设计方法、主程序、程序过程(和应用层的过程不是一一对应的)。 3、 静态层。软件的量,度量层。所有程序构造过程的差别消失了。这是软件的静态观点。 每层都有对软件的自己的理念,概念、过程和模型。两个层的对比,则凸显出不可调和的差别。也是所有关于软件的不成熟的印象、抽象产生的地方。 在应用层,抽象的、逻辑过程强一些。想象的部分占据主要的部分。需要对现实的业务,基于设备的具体能力,进行构造。 3个范畴定义了“软件”和“程序”的分别。第1层和第3层论述的是“软件”,而第2层论述的是“程序”。 软件和程序的研究方法不同。程序研究方法是完备的,而软件不完备。 程序开发应当体现软件特性。1)是逻辑的过程,总体的过程和子过程的观察和校验程序。2)软件的量层次上,软件的规模、运行强度和稳定性指标的自测试程序。 第二阶段 一定要有一个标准。软件如衣服,软件的交付文档应当显示出衣服是如何编织起来的。(相对于需求,软件是衣服,非核心;相对于硬件,软件是衣服,包裹) 要有一个理论说明。 架构也是衣服的一个部件,类似衣服的连接方式,模块集合的重心比对。 衣服是一个没有核心的结构。软件也一样要显示出这个特性。 无论如何,我们需要有观察软件的眼光,无论一套软件依据什么样的理论产生。 什么是软件?描述是软件的存在形式(文本格式)。软件一定是可执行的(这是软件的严肃性,精确、定量)。软件是异化的,一般异化为具体、特例(对抽象力最好的归结方式)(没有完美满足需求的软件,相对于需求,软件只能满足固定的需求,而不能满足需求的变化,即一款软件总是具体的;由一般产生出具体的思考方法,也就是构造的方法;或着是磁力打造,一个好的理论一定对现实素材有吸引力,向磁铁一般;这也是在矛盾中建造现实的方法,只要是具体的就肯定是可以分析出潜在矛盾、不完美的,问题不仅仅是分析、认识现实,还要能够构造现实;不存在完美的现实,只存在完美的理论 科学研究的方法是简化。工程的方法是‘相似’,复制发现事物时的状态,那么事物的表现就会复现。 在具体化这里,软件和硬件工作的方法在结果上实现了一致。只是方向不同,软件是从一般进行到具体;硬件一开始就是从具体出发,层层构造,搭建系统。硬件的设计明显具有以工艺、器件为核心的特征。配合器件的特新,进行外围设计。在硬件领域,是‘具体’为上;在软件领域,是‘具体’为下。) 对具体性的解释:组成所有物资的电子、质子、中子是圆的、相同的,但是这些相同的东西组成的原子则有几百种不同。每次量的规模的添加,都导致特殊性的添加。对于软件来说,也是如此。如下的概念是母庸质疑的,软件如同大山,沟壑鲜明。(这种巨大的特殊性,一定是和巨大的需求特殊性相应的)。 “软件以文本形式存在;软件在执行着;软件以个例的形式存在”,归结为在一起就是“软件是具体的”。 低一级别的定义:软件与数据和逻辑相关(数据和逻辑是软件的基本语义)。软件与过程相关(积分(存储,数据的数据化)和步骤(逻辑);过程是步骤的遍历,是数据的消长变化)。 执行的异化。区分独立执行和整体执行的概念。独立执行的代码称为模块,否则只是‘片段’。独立性和数据完整性相关,数据越庞大那么不独立的代码片段越多,模块就越大。模块独立性具有比和整体执行所要求的更大的自由度,也就是说整体只是使用了模块一部分的执行能力。模块独立执行获得的自由度是应该能够度量;模块的执行设计应该为了获取更大的自由度;自由度是模块可执行性质量的评定指标。对于整体执行的设计来说,自由度设计可能是设计过程的主导方法,它和全面、完整的需求理解相关,也和需求变化相关;因此自由度设计也是需求定位的设计。 软件的量,也就是软件的能力。这是理解软件解决问题的方式的基础。比如逻辑能力、计算能力、存储能力、图象能力等。 软件是运行的,软件是自我构造的,软件的全体的各个环节都有自己的量。编译、操作系统、文件管理等各环节都是不同分工的软件实现的。 需要构造在功能层次上的互相配合,解释这种完整性。显然每个部分都具有独立的完整性;完整性和完整性的配合构成一个总体的系统。因此未必要求系统的完整性、长期性、稳定性。反过来,系统满足需求的快速性、快速变化适应性、和现实一起变化、消长的特性、瞬态响应特性可能更接近系统的本质。 这好比太极拳,要在一个完满的氛围里运动。 软件能力是比代码高一个级别的抽象。又是构成软件内涵的基础语义。 ‘设备能力’的概念更基础,可以统一所有其它能力;又可以作为以硬件为中心的观念的基础。 能力的获得在于‘二分’。在于互相支撑的界面,支撑在一起的双方互为能力。 1.所谓需求分析,我们总是在创造一套新的方法和语言。而最有效的需求分析是自然语言分析。借助人们心目中的全部理解所用到的描述形式。也就是进入到实际存在的需求中去理解需求,分析需求。 因为领域、术语、行业表述习惯的原因,这个阶段千差万别。 2.其次是电脑的使用方式-电脑技术(外设、通信和电脑本身的硬件形态),尝试去设计合适的使用方式和硬件解决方案。 这里有使用环境、专业技术、成本、时间,以及个人习惯等原因,同样是一个精彩的过程。对领域工作方式的熟悉、外设相关的专业技术背景、折中技术决定了这是一个经验至上的活动。这就是电脑使用方式的确定。 3.进一步,确定使用者角色。使用者和使用地点关联。使用地点也就是前面电脑使用方式的一部分。 这是一个沟通过程,也是对有了电脑辅助参与,相关领域习惯改革的问题。 4.然后,进入二元分析阶段:使用者管角度、客观功能角度,分析功能,并完成二者之间的映射。 这个阶段,功能被量化。职能量化。职能和功能之间会有模糊,有授权的转移。这个阶段就是充分考虑这些问题。 5.然后,进入传统的需求分析阶段。 计算架构和功能描述的规格分析。使用者界面规划(详细、规格级别)。 界面规划、功能、架构三者之间组成互动的具体化过程。 最后会产生系统级别的文档。运行实体、接口;系统运行态、实体接口的输入输出规格。 6.然后,实体级别的程序构造阶段。 算法构造和程序构造。主要是从资源占用的角度确定宏观的算法。在这个阶段,是程序文档化阶段。文档这个属于是这个阶段的工具。 最后会产生严格的程序模块的文档。所有这些文档组合起来,可以构成运行流程。这些文档化的程序就是逻辑化的程序本身。 7.最后,编码阶段 用一种具体的语言,按照模块文档的接口、资源、算法要求,编制代码。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值