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