结构设计软件有哪些选用原则
第一,根据需要选择。
如果是建筑结构设计可以选择PKPM、ETBAS、SAP2000等;如果是桥梁设计可以选择迈达斯;如果是钢结构设计可以选择3D3S、MTS、STS、perform-3D等;如果是偏向研究可以选择ANSYS、ABAQUS等有限分析软件,这些软件可以根据需求进行二次开发,十分方便。
第二,永远选择自己最熟悉的软件。
软件工程的目标和原则
?就笔者的观点来看:软件设计是采用编程或脚本语言优雅地表达并解决现实需求的一门科学和艺术。
优雅地表达想传递的意思是,所设计出来的软件应当能容易被人理解、方便扩展和维护。
从这一定义可以看出软件设计首先是一门科学,是一门解决用户需求的软件科学。
既然是科学,不可避免的要掌握相关的科学知识,比如数据结构、计算机组成原理、编程语言等等,而这些内容也正是大学计算机相关专业所传授的知识。
科学知识或许更加容易被量化,拿数据结构为例,一种算法比另一种算法是否更优可以从算法的时间冗余度和空间冗余度进行衡量。
除了科学的部分,软件设计还涉及艺术的范畴。
既然是一门艺术,那就一定存在欣赏的问题,也就意味并不是每个从业人员都能欣赏这种艺术,而只有达到了一定的层次且形成了自己的思想后才能欣赏它。
由于设计中艺术的非直观性,造成其在现实中不容易被量化,因此难以形成相应的评估准则,进而造成在软件行业容易被忽视。
试想想,大学课程有多少内容是在教我们将软件设计当作艺术进行欣赏并追求?好的软件设计能相对方便(甚至是很方便)地实现新的需求问题。
需求分析是告诉我们做什么,其显然非常的重要,而设计更多地涉及怎么做更好。
既然对于设计的好坏不能完全通过量化的方式进行衡量,那如何去评价一个软件设计的好坏呢?或者在进行软件设计时,如何去思考以做出一个好的设计呢?这可以通过对一些软件设计原则的把握来做到。
设计原则可能有很多,但并不是每一个项目都要同时满足所有的设计原则,另外,不同的项目其特性有可能使得有些设计原则并不适用。
另外,设计原则也不是一成不变的,可能因项目的特点又可以抽取出另外的设计原则。
笔者将在后续的文章中阐述日常工作中所遵守的软件设计原则。
软件设计是一个不断提炼和抽象的过程。
说它是一个提炼的过程,是因为在设计之初会想到很多需要考虑的因素,这些因素在设计工作没有深入之前,并不能发现它们有些是重叠的,或者有些根本就不需要考虑。
随着设计的深入,会从众多的因素中得到其中的关键因素并将这些因素付之于实践。
设计也是一个抽象过程,需要从众多的表象中找到它们的共性,通过表达共性从而最终描述每个个性,而不应当局限于直接去描述每一个个性。
设计的深入过程并不只是一味地思考,除非设计者以前有过类似的设计经验,否则设计过程通常需要进行一定的代码编写工作,以辅助思考,这一点对于开发软件架构师(系统架构师不包括在内)也应当是一样的。
软件设计是一个创造模型的过程。
通过对需求的理解和抽象,好的设计将最终构造出一个模型,而且这个模型与现实世界的某样东西可能是相类似的。
这个模型除了实现了用户的需求,还向他人展示了她自己是什么模样以及可能会如何行事。
打个比方,如果有人发明了一种新的交通工具,他如何最为有效地表达这一新的交通工具到底是什么样的呢?是直接拿一张图纸给他人并说你看看图纸就知道了好呢?还是打一个大家都耳熟能详的比方好呢?显然,后者更好。
如果他说这个新的交通工具与现在的轿车很像,只不过,如此一来,听众马上就会想,这个新的交通工具有四个轮子、也有方向盘等等。
显然,后者能很快地让听众利用其生活经验快速的接收信息,而好的软件设计也应当做到这一点。
软件设计时的模型创造过程,其实就是赋予软件代码生命的过程,由此看来一个好的设计应当是 有生命的。
软件设计是一个做选择的过程。
人有时没有选择反而轻松。
一个刚毕业的大学生如果只拿到了一个offer,他可能没有选择单位的烦恼,不论单位好坏都去报道就是了。
但是,如果他拿了两个offer,选择的烦恼也就有了 是去A单位好呢?还是B单位好?不幸的是,软件的设计过程往往存在大量的选择。
是用空间换时间好呢?还是用时间换空间好?是现在考虑可扩展性呢?还是将来?等等。
因此,毫不夸张地说,设计是痛苦的,除非设计主题很简单或直接了当。
有苦当然也就有乐,在设计没有最终定下来时,需要痛苦地思考和选择,往往是一个觉得这个也不行、那个也不好的过程。
但是,一旦设计最终定稿,会发现这就是我想要的设计,随之而来的是三百六十度的大转变,觉得这个也应当就是这样,那个也应当是这样,其结果是设计者能从中体会到一种美,并从中收获乐趣。
软件设计是一个在有限理性范围内追求完美的过程。
有限理性非常重要,设计者需要在各种条件允许的情况下做出合理的设计选择。
另外,促使设计者用心并痛苦地进行设计的动力是设计者追求完美的品德。
(37) 下面不属于软件设计原则的是
单一职责原则:(SRP)一个类,最好只做一件事,只有一个引起它变化的原因。
开放-封闭原则:(OCP:The Open-Closed Principle)软件实体(类,模块,函数等等)应该是可以扩展的,但是不可修改的。
依赖倒转原则:(DIP)这个原则的内容是:要依赖于抽象,不要依赖于具体。
或者说是:要针对接口编程,不要对实现编程(Program to an interface,not an implementation)。
高层模块不应该依赖底层模块,两个都应该依赖抽象。
里氏代换原则:(Liskov Substitution Principle,LSP)在一个软件系统中,子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。
迪米特原则:(Least Knowledge Principle,LKP)最少知识原则,又称为“Law of Demeter”,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。
如果其中一个类需要调用另一个类的方法的话,可以通过第三者转发这个调用。
结构化程序设计原则
展开全部 结构化程序设计原则主要有四个原则: 1.自顶向下:程序设计时,应先考虑总体,后考虑细节;先考虑全局目标,后考虑局部目标。
不要一开始就过多追求众多的细节,先从最上层总目标开始设计,逐步使问题具体化。
2.逐步求精:对复杂问题,应设计一些子目标作为过渡,逐步细化。
3.模块化:一个复杂问题,肯定是由若干稍简单的问题构成。
模块化是把程序要解决的总目标分解为子目标,再进一步分解为具体的小目标,把每一个小目标称为一个模块。
4.限制使用goto语句结构化程序设计方法的起源来自对GOTO语句的认识和争论。
肯定的结论是:在块和进程的非正常出口处往往需要用GOTO语句,使用GOTO语句会使程序执行效率较高;在合成程序目标时,GOTO语句往往是有用的,如返回语句用GOTO。
否定的结论是:GOTO语句是有害的,是造成程序混乱的祸根,程序的质量与GOTO语句的数量呈反比,应该在所有高级程序设计语言中取消GOTO语句。
取消GOTO语句后,程序易于理解、易于排错、容易维护,容易进行正确性证明。
作为争论的结论,1974年Knuth发表了令人信服的总结,并取消了GOTO语句。
扩展资料: 结构化程序,是以模块化设计为中心,将待开发的软件系统划分为若干个相互独立的模块。
结构化程序设计由迪克斯特拉(E.W.dijkstra)在1969年提出,是以模块化设计为中心,将待开发的软件系统划分为若干个相互独立的模块,这样使完成每一个模块的工作变单纯而明确,为设计一些较大的软件打下了良好的基础。
由于模块相互独立,因此在设计其中一个模块时,不会受到其它模块的牵连,因而可将原来较为复杂的问题化简为一系列简单模块的设计。
模块的独立性还为扩充已有的系统、建立新系统带来了不少的方便,因为我们可以充分利用现有的模块作积木式的扩展。
参考资料:百度百科-结构化程序...