就知道吃吃死你
我想知道除了3D可以做出仿真模型,还有什么软件可以？求大神帮助
我用过revit architecture，它是建筑建模软件。
有现成的墙、楼板、窗、楼梯、幕墙等等各种构件（也可以自建），各种构件的属性非常清楚，所以很智能化（比如窗会自动在墙上挖洞附上去，幕墙上画竖挺极为方便）。
建模同时平立剖统统可以出来，所以平立剖之间不可能有不符的地方。
图纸的各种符号比如标高等也可以很方便的生成。
另外它可以渲染.满意请采纳
软件体系结构的应用现状
形成研究热点，仍处于非形式化水平自20世纪90年代后期以来，软件体系结构的研究成为一个热点。
广大软件工作者已经认识到软件体系结构研究的重大意义和它对软件系统设计开发的重要性，开展了很多研究和实践工作。
从软件体系结构研究的现状来看，当前的研究和对软件体系结构的描述，在很大程度上来说还停留在非形式化的基础上。
软件构架师仍然缺乏必要的工具，这种工具应该是显式描述的、有独立性的形式化工具。
在目前通用的软件开发方法中，其描述通常是用非形式化的图和文本，不能描述系统期望的存在于构件之间的接口，不能描述不同的组成系统的组合关系的意义。
难以被开发人员理解，更不能用来分析其一致性和完整性等特性。
当一个软件系统中的构件之间几乎以一种非形式化的方法描述时，系统的重用性也会受到影响，在设计一个系统结构过程中的努力很难移植到另一个系统中去。
对系统构件和连接关系的结构化假设没有得到显式的、形式化的描述时，把这样的系统构件移植到另一个系统中去将是有风险的，甚至是不可能的。
软件体系结构的形式化方法研究软件体系结构研究如果仅仅停留在非形式化的框图阶段，已经难以适应进一步发展的需要。
为支持基于体系结构的开发，需要有形式化建模符号、体系结构说明的分析与开发工具。
从软件体系结构研究的现状来看，在这一领域近来已经有不少进展，其中比较有代表性的是美国卡耐基梅隆大学（Carnegie Mellon University）的Robert J.A11en于l997年提出的Wright系统。
Wright是-种结构描述语言，该语言基于一种形式化的、抽象的系统模型，为描述和分析软件体系结构和结构化方法提供了一种实用的工具。
Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。
它使用显式的、独立的连接模型来作为交互的方式，这使得该系统可以用逻辑谓词符号系统，而不依赖特定的系统实例来描述系统的抽象行为。
该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。
从这些特性的分析来说，Wright系统的确适用于对大型系统的描述和分析。
软件体系结构的建模研究研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。
根据建模的侧重点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。
在这5个模型中，最常用的是结构模型和动态模型。
（1）结构模型这是一个最直观、最普遍的建模方法。
这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。
研究结构模型的核心是体系结构描述语言。
（2）框架模型框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。
框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
（3）动态模型动态模型是对结构或框架模型的补充，研究系统的大颗粒的行为性质。
例如，描述系统的重新配置或演化。
动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。
这类系统常是激励型的。
（4）过程模型过程模型研究构造系统的步骤和过程。
因而结构是遵循某些过程脚本的结果。
（5）功能模型该模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。
它可以看作是一种特殊的框架模型。
这5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软件体系结构更合适。
例如，Kruchten在1995年提出了一个4+1的视角模型。
4+1模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。
每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。
4+1模型如图1所示。
图1 4+1模型发展基于体系结构的软件开发模型软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。
目前，常见的软件开发模型大致可分为三种类型：（1）以软件需求完全确定为前提的瀑布模型。
（2）在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。
（3）以形式化开发方法为基础的变换模型。
所有开发方法都是要解决需求与实现之间的差距。
但是，这三种类型的软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。
因此，研究人员在发展基于体系结构的软件开发模型方面做了一定的工作。
例如，为了形象地表示体系结构的生命周期，北京邮电大学的周莹新博士建立了一个软件体系结构的生命周期模型，该模型如图2所示。
图2 软件体系结构的生命周期模型软件产品线体系结构的研究软件体系结构的开发是大型软件系统开发的关键环节。
体系结构在软件生产线的开发中具有至关重要的作用，在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系统。
在软件产品族之间共享体系结构和一组可重用的构件，可以增加软件工程和降低开发和维护成本。
一个产品线代表...
什么是＂软件设计＂
什么是＂软件设计＂ 面向对象技术，特别是C++，似乎给软件界带来了不小的震动。
出现了大量的论文和书籍去描述如何应用这项新技术。
总的来说，那些关于面向对象技术是否只是一个骗局的问题已经被那些关于如何付出最小的努力即可获得收益的问题所替代。
面向对象技术出现已经有一段时间了，但是这种爆炸式的流行却似乎有点不寻常。
人们为何会突然关注它呢？对于这个问题，人们给出了各种各样的解释。
事实上，很可能就没有单一的原因。
也许，把多种因素的结合起来才能最终取得突破，并且这项工作正在进展之中。
尽管如此，在软件革命的这个最新阶段中，C++本身看起来似乎成为了一个主要因素。
同样，对于这个问题，很可能也存在很多种理由，不过我想从一个稍微不同的视角给出一个答案：C++之所以变得流行，是因为它使软件设计变得更容易的同时，也使编程变得更容易。
虽然这个解释好像有点奇特，但是它却是深思熟虑的结果。
在这篇论文中，我就是想要关注一下编程和程序设计之间的关系。
近10年来，我一直觉得整个软件行业都没有觉察到做出一个软件设计和什么是真正的软件设计之间的一个微妙的不同点。
只要看到了这一点，我认为我们就可以从C++增长的流行趋势中，学到关于如何才能成为更好的软件工程师的意义深远的知识。
这个知识就是，编程不是构建软件，而是设计软件。
几年前，我参见了一个讨论会，其中讨论到软件开发是否是一门工程学科的问题。
虽然我不记得了讨论结果，但是我却记得它是如何促使我认识到：软件业已经做出了一些错误的和硬件工程的比较，而忽视了一些绝对正确的对比。
其实，我认为我们不是软件工程师，因为我们没有认识到什么才是真正的软件设计。
现在，我对这一点更是确信无疑。
任何工程活动的最终目标都是某些类型的文档。
当设计工作完成时，设计文档就被转交给制造团队。
该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同。
如果设计文档正确地描绘了一个完整的设计，那么制造团队就可以着手构建产品。
事实上，他们可以着手构建该产品的许多实物，完全无需设计者的任何进一步的介入。
在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。
对于这个观点，人们进行了很多的争论，无论是赞成的还是反对的都足以写成无数的论文。
本文假定最终的源代码就是真正的软件设计，然后仔细研究了该假定带来的一些结果。
我可能无法证明这个观点是正确的，但是我希望证明：它确实解释了软件行业中一些已经观察到的事实，包括C++的流行。
在把代码看作是软件设计所带来的结果中，有一个结果完全盖过了所有其他的结果。
它非常重要并且非常明显，也正因为如此，对于大多数软件机构来说，它完全是一个盲点。
这个结果就是：软件的构建是廉价的。
它根本就不具有昂贵的资格；它非常的廉价，几乎就是免费的。
如果源代码是软件设计，那么实际的软件构建就是由编译器和连接器完成的。
我们常常把编译和连接一个完整的软件系统的过程称为“进行一次构建”。
在软件构建设备上所进行的主要投资是很少的——实际需要的只有一台计算机、一个编辑器、一个编译器以及一个连接器。
一旦具有了一个构建环境，那么实际的软件构建只需花费少许的时间。
编译50 000行的C++程序也许会花费很长的时间，但是构建一个具有和50 000行C++程序同样设计复杂性的硬件系统要花费多长的时间呢？ 把源代码看作是软件设计的另外一个结果是，软件设计相对易于创作，至少在机械意义上如此。
通常，编写（也就是设计）一个具有代表性的软件模块（50至100行代码）只需花费几天的时间（对它进行完全的调试是另外一个议题，稍后会对它进行更多的讨论）。
我很想问一下，是否还有任何其他的学科可以在如此短的时间内，产生出和软件具有同样复杂性的设计来，不过，首先我们必须要弄清出如何来度量和比较复杂性。
然而，有一点是明显的，那就是软件设计可以 极为迅速地变得非常庞大。
假设软件设计相对易于创作，并且在本质上构建起来也没有什么代价，一个不令人吃惊的发现是，软件设计往往是难以置信的庞大和复杂。
这看起来似乎很明显，但是问题的重要性却常常被忽视。
学校中的项目通常具有数千行的代码。
具有10 000行代码（设计）的软件产品被它们的设计者丢弃的情况也是有的。
我们早就不再关注于简单的软件。
典型的商业软件的设计都是由数十万行代码组成的。
许多软件设计达到了上百万行代码。
另外，软件设计几乎总是在不断地演化。
虽然当前的设计可能只有几千行代码，但是在产品的生命期中，实际上可能要编写许多倍的代码。
尽管确实存在一些硬件设计，它们看起来似乎和软件设计一样复杂，但是请注意两个有关现代硬件的事实。
第一，复杂的硬件工程成果未必总是没有错误的，在这一点上，它不存在像软件那样让我们相信的评判标准。
多数的微处理器在发售时都具有一些逻辑错误：桥梁坍塌，大坝破裂，飞机失事以及数以千计的汽车和其他消费品被召回——所有的...
软件的生命周期
软件生命周期是指从软件定义、开发、使用、维护到报废为止的整个过程，一般包括问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试和维护。
问题定义就是确定开发任务到底“要解决的问题是什么”，系统分析员通过对用户的访问调查，最后得出一份双方都满意的关于问题性质、工程目标和规模的书面报告。
可行性分析就是分析上一个阶段所确定的问题到底“可行吗”，系统分析员对系统要进行更进一步的分析，更准确、更具体地确定工程规模与目标，论证在经济上和技术上是否可行，从而在理解工作范围和代价的基础上，做出软件计划。
需求分析即使对用户要求进行具体分析，明确“目标系统要做什么”，把用户对软件系统的全部要求以需求说明书的形式表达出来。
总体设计就是把软件的功能转化为所需要的体系结构，也就是决定系统的模块结构，并给出模块的相互调用关系、模块间传达的数据及每个模块的功能说明。
详细设计就是决定模块内部的算法与数据结构，也是明确“怎么样具体实现这个系统”。
编码就是选取适合的程序设计语言对每个模板进行编码，并进行模块调试。
测试就是通过各种类型的测试使软件达到预定的要求。
维护就是软件交付给用户使用后，对软件不断查错、纠错和修改，使系统持久地满足用户的需求。
软件的生命周期也可以分为3个大的阶段，分别是计划阶段、开发阶段和维护阶段。
瀑布模型有时也称为V模型，它是一种线型顺序模型，是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用，它提供了一种结构化的、自顶向下的软件开发方法，每阶段主要工作成果从一个阶段传递到下一个阶段，必须经过严格的评审或测试，以判定是否可以开始下一阶段工作，各阶段相互独立、不重叠。
瀑布模型是所有软件生命周期模型的基础。
原型+瀑布模型原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。
原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。
原型建立确认需求之后采用瀑布模型的方式完成项目开发。
增量模型与建造大厦相同，软件也是一步一步建造起来的。
在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
一些大型系统往往需要很多年才能完成或者客户急于实现系统，各子系统往往采用增量开发的模式，先实现核心的产品，即实现基本的需求，但很多补充的特性（其中一些是已知的，另外一些是未知的）在下一期发布。
增量模型强调每一个增量均发布一个可操作产品，每个增量构建仍然遵循设计-编码-测试的瀑布模型。
迭代模型早在20世纪50年代末期，软件领域中就出现了迭代模型。
最早的迭代过程可能被描述为“分段模型”。
迭代，包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上，它类似小型的瀑布式项目。
所有的阶段（需求及其它）都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
