【建模需要什么软件】三维建模软件都有哪些软件是用在工程中完成三...

一、有助于按照现实或者实际情况进行直观的描述。

二、能够规定软件或者模型的结构，行为，属性。

三、能够指导软件构造的模板。

四、对决策进行文档化 当然建模并不只适用于大的系统，甚至像非常小的一个应用，我们都可以建模，在建模中受益，然而越大的软件，功能越杂，业务越不清晰，从而阻挠软件开发者的思路和效率。

在这种情况下，我们使用建模的重要性就越大，一个很简单的原因是：因为不能理解一个很复杂而庞大的软件工程，所以要对他建模 。

而且人们对复杂的事物或者问题的理解是有局限的，人们总是习惯去理解 简单易懂的东西。

所以通过建模可以 缩小研究范围，只着重研究其很小的一部分功能，这就要求了一个复杂的软件系统“分而治之”，从而通过建模简单化。

从而你会发现其实很复杂的系统软件或者工程总是变得很简单，解决了这小部分的简单问题，就形成了复杂而庞大的软件或者工程。

建模能帮助开发组更好地进行系统规划，并帮助他们进行架构软件，使用开发效率提高。

如果不建模，项目越复杂，就越会失败或者出现错误的东西。

...

功能建模的目的是什么？

中文名功能建模目的解决业务领域所需要的系统功能领域销售管理等1定义2建模思路3功能建模在销售管理系统中的应用4文档功能建模定义编辑功能建模是指在业务建模的基础上，为解决业务领域的问题所需要的系统功能，并按照“系统子系统功能程序”的思路编排，且需说明解决哪部分业务以及功能间的关系

在使用ProE软件进行建模的过程中,如何解决再生失败问题？

在使用ProE软件进行建模的过程中，如果无法成功地解决父子关系、几何情况，或者零件或组件模型中丢失参照，就会发生再生失败。

由于 再生失败的原因有多种，所以，在修正再生问题之前必须先行诊断。

首先，找出并解释模型的设计信息（包括特征的尺寸、草绘、父项、子项及模型的名称、单位、剖面及参照组件等），这样就可以确定模型的现在设计意图，包括父子关系、几何和参照，一旦确定了设计意图，就能更加容易地调查和解决全部可能发生的模型失败。

通常有下面四种情况再生失败：1、 零件再生失败一旦特征再生失败，即进入“解决模式”，在此模式中会出现以下情况：文件保存命令不可用，模型无法保存失败的特征和全部后续特征都不会再生，当前模型只显示上一次成功再生时的特征。

系统在消息窗口中指出存在的问题在菜单管理器中显示“求解特征”菜单诊断失败窗口出现利用系统提供的解决环境，可以实现下列操作：撤消导致失败的所有更改调查模型失败的原因使用标准功能的同时，在此特殊环境内修复问题使用快捷方式对失败特征执行包括重定义、重定参照、隐含和冻结在内的标准操作，尝试快速修复问题。

2、绘图再生失败以绘图而言，再生失败通常会发生在编辑零件或组件的尺寸之后，最新再生的零件或组件无效。

在出现再生失败之后，系统会进入零件失败同样的解决环境，对再生失败的绘图进行调整。

3、解决组件再生失败组件是由元件组成的，所以元件是组件的父项。

当元件在再生或检索期间失败时，会导致组件再生失败，装配模式下发生元件失败通常有下面三种原因：元件丢失（可能已经将其移到其它文件夹中、可能已经在组件不在进程中的情况下被重新命名、可能已经将其从文件夹中删除）元件参照可能丢失（元件的特征可能已经过重新定义，从而移除了参照、元件特征可能已经被删除或被隐含）模型几何可能已更改，导致组件约束变为无效（元件的尺寸可能已被更改）系统在运行过程中会提示具体是哪一部分出现问题，针对不同的问题，对元件及组件进行更改，即可解决组件再生失败问题。

4、父子关系再生失败在零件中，一个特征通常是另一特征的子项。

如果来自父特征的参照发生了更改，则当该参照不再有效时会导致子特征失败。

组件由元件构成。

元件是组件的父项。

如果移动其中一个元件，或者如果某个元件中用于装配该元件的参照已更改或移除，则将导致组件失败。

绘图由零件和组件构成。

零件和组件是绘图的父项。

如果零件或组件再生失败，则绘图也会随之失败。

彻底了解在特征与元件之间创建的父子关系是有效解决再生失败的关键。

以上介绍了在使用软件过程中经常碰到的再生失败问题，请大家具体情况具体分析，并紧密结合自己的对实体及特征的操作，这样才能快速解决再生失败问题。

什么是＂软件设计＂

什么是＂软件设计＂ 面向对象技术，特别是C++，似乎给软件界带来了不小的震动。

出现了大量的论文和书籍去描述如何应用这项新技术。

总的来说，那些关于面向对象技术是否只是一个骗局的问题已经被那些关于如何付出最小的努力即可获得收益的问题所替代。

面向对象技术出现已经有一段时间了，但是这种爆炸式的流行却似乎有点不寻常。

人们为何会突然关注它呢？对于这个问题，人们给出了各种各样的解释。

事实上，很可能就没有单一的原因。

也许，把多种因素的结合起来才能最终取得突破，并且这项工作正在进展之中。

尽管如此，在软件革命的这个最新阶段中，C++本身看起来似乎成为了一个主要因素。

同样，对于这个问题，很可能也存在很多种理由，不过我想从一个稍微不同的视角给出一个答案：C++之所以变得流行，是因为它使软件设计变得更容易的同时，也使编程变得更容易。

虽然这个解释好像有点奇特，但是它却是深思熟虑的结果。

在这篇论文中，我就是想要关注一下编程和程序设计之间的关系。

近10年来，我一直觉得整个软件行业都没有觉察到做出一个软件设计和什么是真正的软件设计之间的一个微妙的不同点。

只要看到了这一点，我认为我们就可以从C++增长的流行趋势中，学到关于如何才能成为更好的软件工程师的意义深远的知识。

这个知识就是，编程不是构建软件，而是设计软件。

几年前，我参见了一个讨论会，其中讨论到软件开发是否是一门工程学科的问题。

虽然我不记得了讨论结果，但是我却记得它是如何促使我认识到：软件业已经做出了一些错误的和硬件工程的比较，而忽视了一些绝对正确的对比。

其实，我认为我们不是软件工程师，因为我们没有认识到什么才是真正的软件设计。

现在，我对这一点更是确信无疑。

任何工程活动的最终目标都是某些类型的文档。

当设计工作完成时，设计文档就被转交给制造团队。

该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同。

如果设计文档正确地描绘了一个完整的设计，那么制造团队就可以着手构建产品。

事实上，他们可以着手构建该产品的许多实物，完全无需设计者的任何进一步的介入。

在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。

对于这个观点，人们进行了很多的争论，无论是赞成的还是反对的都足以写成无数的论文。

本文假定最终的源代码就是真正的软件设计，然后仔细研究了该假定带来的一些结果。

我可能无法证明这个观点是正确的，但是我希望证明：它确实解释了软件行业中一些已经观察到的事实，包括C++的流行。

在把代码看作是软件设计所带来的结果中，有一个结果完全盖过了所有其他的结果。

它非常重要并且非常明显，也正因为如此，对于大多数软件机构来说，它完全是一个盲点。

这个结果就是：软件的构建是廉价的。

它根本就不具有昂贵的资格；它非常的廉价，几乎就是免费的。

如果源代码是软件设计，那么实际的软件构建就是由编译器和连接器完成的。

我们常常把编译和连接一个完整的软件系统的过程称为“进行一次构建”。

在软件构建设备上所进行的主要投资是很少的——实际需要的只有一台计算机、一个编辑器、一个编译器以及一个连接器。

一旦具有了一个构建环境，那么实际的软件构建只需花费少许的时间。

编译50 000行的C++程序也许会花费很长的时间，但是构建一个具有和50 000行C++程序同样设计复杂性的硬件系统要花费多长的时间呢？ 把源代码看作是软件设计的另外一个结果是，软件设计相对易于创作，至少在机械意义上如此。

通常，编写（也就是设计）一个具有代表性的软件模块（50至100行代码）只需花费几天的时间（对它进行完全的调试是另外一个议题，稍后会对它进行更多的讨论）。

我很想问一下，是否还有任何其他的学科可以在如此短的时间内，产生出和软件具有同样复杂性的设计来，不过，首先我们必须要弄清出如何来度量和比较复杂性。

然而，有一点是明显的，那就是软件设计可以 极为迅速地变得非常庞大。

假设软件设计相对易于创作，并且在本质上构建起来也没有什么代价，一个不令人吃惊的发现是，软件设计往往是难以置信的庞大和复杂。

这看起来似乎很明显，但是问题的重要性却常常被忽视。

学校中的项目通常具有数千行的代码。

具有10 000行代码（设计）的软件产品被它们的设计者丢弃的情况也是有的。

我们早就不再关注于简单的软件。

典型的商业软件的设计都是由数十万行代码组成的。

许多软件设计达到了上百万行代码。

另外，软件设计几乎总是在不断地演化。

虽然当前的设计可能只有几千行代码，但是在产品的生命期中，实际上可能要编写许多倍的代码。

尽管确实存在一些硬件设计，它们看起来似乎和软件设计一样复杂，但是请注意两个有关现代硬件的事实。

第一，复杂的硬件工程成果未必总是没有错误的，在这一点上，它不存在像软件那样让我们相信的评判标准。

多数的微处理器在发售时都具有一些逻辑错误：桥梁坍塌，大坝破裂，飞机失事以及数以千计的汽车和其他消费品被召回——所有的...