对基于模型的软件开发的理解
　

---

对基于模型的软件开发的理解

我们认识事物从感性到理性的过程就是一个建立模型的过程马克思的共产主义社会就是一个社会模型有特色的社会主义也是一种社会模型你对未来生活的理想也是一个模型模型包含了什么

系统是模型的实例

模型其实是一个时空范畴，在这个时空里有一些要素（对象）的存在，这些要素自发的、或源于某种激励产生运动，由于各种要素的相关性，引起其他要素的运动，一些对象生死。一些结果产生。这象上帝创早了世界，然后世界开始发展变化。成为一个混沌。

复杂的软件模型往往也走向混沌，但模型的建立有目的性的，我们要求它产生所需要的结果，这也是软件模型建立的价值所在。这种目的性引导我们构建模型。（用例的价值）

将这种模型构建为为我们服务的机器的过程开始展开接纳输入计算提供结果这是典型的过程设计思路

接纳输入-分派给处理对象-处理对象处理-结果输出这是windows编程中一种典型思维一个处理流程(用例） 1、一个处理流程包含多方面的要素参与 2、各种要素相互关联，相互影响

需要明确的使：在实际运行的系统中不再有类的概念，一个个对象产生，完成任务，然后死去，这是面向对象的编程观但对编程者可能面向类思考更为准确。

类为对象规格的完备描述，同类的对象可以执行相同的操作。在执行期的分界点上：类与对象被分割开来，软件设计人员建立了各种类，机器依据这些类生成对象，接受激励，完成计算。

因此编程者关注点在如何构造类，类如何生成对象。类的构造：1、oo观点 确定了问题域中某类对象的概念，明确了语义

2、ADT观点 确定了一种新的数据类型（数据集和运算集）

因此某类的存在一定使语义与概念清楚的，能够参与计算的数据类型

在明确以上内容之后，开始类的构造过程

类的构造过程技术实现上应关注以下两点： 1、继承

继承技术至少有两点好处第一为少写代码，复用，但实际应用中可能另一方面更为重要，就是接口契约观点，依据这种观点在设计期可以定义整体的架构，使软件更富弹性。

2、关联

对象间的关联在类设计期确定下来可以使软件设计模型更准确反映问题的本质，假想另一种设计一个对象计算需要另一个对象时生成它，其实也一定可以完成功能，但至少有以下问题:1、所需的对象可能为特定的一有对象，若没有一个接口引入它，重新生成很浪费。2、在模型中看不到这种相关性，为维护留下隐患。3、生命周期难于管理
概念上
关联的存在表达了什么？
1、组合完成功能委托
2、客观上的持有关系
3、协作完成某种机制
4、关联的实例对象引用点


技术上
1：N关联可能容器
关联对象的引入接口（参数,直接赋值，自主生成）
导航关系

这时的类定义很大程度上决定于经验与对概念的认识

模型中已经有了类，我们可以期待系统运行时会有各种对象依照规则产生，但问题的复杂性刚刚开始，系统并非启动时就生成所有的对象，一般我们的MAIN中只生成APPLICATION

对象何时产生在需要时产生

 文章写得不错。支持一下！不过，
　

---

写的比较抽象，是转载的么？如果在网上，随手就能这样写出来，可能除非一些大师级的人物还差不多吧。

 回复: 文章写得不错。支持一下！不过，
　

---

谢谢，的确为本人写的
www.cnic.org 软件设计思想研究
不过本人水平不高，目前想找份软件设计的工作，有合适的帮忙推荐

 刚才夸奖了一下，现在可能要……呵呵
　

---

其实，你提到的每一个话题都是一个非常大的话题，但是，你却使用一个混沌的概念一统而之。给人一种不终不结的感觉，如果你这片文字作为一本书的序言也许还不错，因为，后续肯定有大量的篇幅来表述自己的观点，阐明一个结论，但是，单单这段文字而言，位置过高，高而浮，有一种上不着天下不着地的感觉。
最好你能有一些补充，形成一个完整的描述，不管是正确的还是错误的，实践后可以得到很多经过验证的东西都可以放在里面支持自己的看法。
个人观点，仅供参考！

 回复: 请讨论模型中的行为调度问题
　

---

您说的对，所以我放在wiki上，让自己丰富它
我现在写到模型的动态方面，对象行为的调度时有些糊涂了，
使用设计模式在建模时总感觉有点不对头，认识事物总该从事物本身出发，
不能硬套
　

 回复: keyi
　

---

近来不用编程，想总结一下，才很多问题很糊涂
而软件建模本身要求必须为精确的，确定的，其实很多软件后期的问题为前期的不确定造成的。模型的实例就是系统
　

 回复: 请讨论模型中的行为调度问题
　

---

如果说到具体模型中的行为调度问题，我个人理解认为：这需要结合实际项目或者实际需要解决的问题来讨论。或者说是通过案例来说话！然后对案例进行分类形成对某一些特性案例的抽象解决方式。通用的解决方法是否能够找到，这就很难说了，所以，我觉得至少目前还不适合讨论。
最好能够先讨论例子，然后再进行扩展！

通俗一点说：软件的模型是一个过程的模型，这与房子的模型是小木片搭起来的格子或图纸上的格子是不一样的。
面向对象建模的意思不是对一个静态的事物建立它的结构模型（那更象ER模型的作用），而是对一个连续运转的过程建立的模型，因为支持这个过程运转的实体全部都是对象。正因为对象是用来支持一个运动的过程的，对象就必须要有自己的行为特征和表象特征，这就是对象的方法和属性。不同对象的行为连接起来运转，就造就了过程的实现。
模型只是对实物的抽象化或离散化。软件作为一种工具的实物，在构造它之前为它建立模型无非是为了降低构造它的风险。正如god2000所说“系统是模型的实例”，这说中了模型是实物的抽象化的一面。
模型是实物的离散化也是很好理解的，学过信号处理的同仁会知道对连续函数的离散采样，建立一个非线性函数的离散模型的方法。离散化是数字化的基础，从这一层含义上说，对现实世界的运转过程进行离散化是建立数字世界的必然手段，于是，建模的任务成为开发计算机软件必不可少的工作——尽管有的模型只在程序员头脑中建立。
软件只是把现实世界的过程搬到计算机中去重现，当然，重现的效率会更高，这是人类制造所有工具的共性。计算机世界其实也是现实世界的另一种表象，所以软件开发的任务只是完成现实世界中同一过程的两种不同表象之间的映射关系的建立。
要完成这种映射关系的建立，可以在不同的现象到本质的中间层折回，折回进入的本质层次越深，重用的机会越大。完全在现象层建立映射关系的软件也不少，他们一般很脆弱，缺乏软件应有的柔性。

软件模型就是这些逐层建立的映射关系的全集。

 回复: 请讨论模型中的行为调度问题
　

---

我觉得这是建模中的一个本质问题，uml中使用了很多图表达动态方面
但使用起来总觉得不顺，原因在于不象类图有oo和er这样深厚的思想背景

再者对在一个系统中如何形成较一致的调度机制好像指导也不多，我的思考
也在这方面。不过讨论的起点应该为uml的动态图，这些图后面到底时什么样的
认识论
有个例子最好，我暂时想不出来

 不太同意。
　

---

我觉得讨论的起点不应该基于某一种描述性语言。
讨论内容的表述才应该是通过这种语言来表达。
考虑实例的时候，更应该如此，而不是一开始就考虑如何用uml来绘制图形，而应该是在绘制图形的过程中采用了uml。主客观的差异可能会造成项目在中后期过于依赖某一种技术而最终却发现该技术的某个缺点造成项目无法实施。
这样的例子可是有很多的呀！

 回复: 不太同意。
　

---

我的感觉为动态的几类图好像理论基础不完善，从图出发向后寻找他的理论基础
　

 我还好，你呢？还好么？
　

---

你是哪位呀？为什么问好？有什么事情么？

很高兴可以在这里看到你，你就以前CSDN上的那个吧。

在模型层次解决了问题认识、重用等之后，编程就简单多了。

 回复: 对基于模型的软件开发的理解
　

---

说得对，我做的每个项目后期都压力极大，有时都痛苦的想离开这行了
从软件工程上看很正常，但提高设计的质量的确能解决部分问题
目前半失业状态，因此我将关注点放在设计上，想研究里面的一些问题

有没有某一具体领域内的模型，作过例子,
讨论computer science 的知识,
喧嚣的会计软件?用什么模型

送你一句话：
会uml,懂rup,会用xxx不代表你就是好的设计师。
要想成为一个好的设计师
就要多讨论，多思考，要有机会接触别人设计的比较好的东西，和自己的想法对比着分析。
DESIGN PATTERN等等对于一个程序设计是来说，是很好的东西，但是对于系统的设计，我觉得对县官技术的原理，优点，缺点，应用环境，以及限制条件等等都很重要，面要广，根要深，没有5~7年的训练，基本上是不太可能的。

我没看懂
怎么办
这个看起来更想“独孤九式“，不过中间夹杂着“黑虎掏心“。：）
我猜测这个老兄一定是个有心人
是个人才
就是还没找到舞台
　

 回复: 对基于模型的软件开发的理解
　

---

有关问题的澄清
文章写的过于抽象，不代表我不实干。我是一个合格的程序员，半合格的分析
员，因为公司小，我大量的时间做编程工作，很多事一个人从头到尾自己做（很苦很累呀）。
软件过程=建模+编程。我知道这肯定要引起反对，但我目前就这样认识，这至少说明了建模很实在，与编程一样的实在。
把建模神秘化是一种通病，好像只有对一个案例才能研究，无法用理论总结，不可言说。但实际上建模也是有它的理论和技能的，不过不系统，在大学里没人教，全靠经验体会。uml+rup至少是一种可供学习的知识，而不是不可言说。
我欣赏rup的建模指导，软件过程更喜欢xp
本人才疏学浅，目前半失业状态，在此只是抛转引玉。希望有识之士重视这一问题即传授建模知识，看看babituo先生的一些文字就知道建模不是神秘论或不可言说
关于混沌问题
1、混沌至少是一种状态的表达
2、软件世界不能混沌，我们建模的目的就是解除这种混沌
3、走出混沌的第一步就是认识系统的目标，系统的目标由用例来表达
系统并非现实的完全再现，而是有价值目标的部分
分割出用例，再进行余下的工作

用例的目标性可以参考babituo先生关于"见好就收"的说法，它比我厉害多了

有心的朋友帮我看看那些公司招人。谢谢








　

 回复: 对基于模型的软件开发的理解
　

---

老兄批评的对
这源于我的工作经历与环境，我在青岛，一个IT贫瘠的土地。没什么好的公司
高人我也没发现。自己在工作中总结学习，得出的心得。特想与高人学习交流
或者换个环境
　

把思考的范围缩小一些，太大了就成哲学了。

决无批评的意思
也许你应该换个环境

你多大了？
我建议你如果年龄不大
就换个地方
软件如果没有一个好的土壤
靠自己一个人琢磨
不光是累
是
很快就会被别人拉开距离
晴到哪里不适合作软件

 回复: 对基于模型的软件开发的理解
　

---

近期umlchina讨论的一些心得
1、离散和点线面观
2、分析阶段行为调度与设计模式是不相关的问题(你说的黑虎掏心）
我希望不要误导别人，有些东西确实有问题
3、研究建模的启发式过程更有意义
能否交个朋友
chenmingyong2@hotmail.com

 回复: 前面1/3我觉得：混沌得原因是把100%的精力用在证明性的、百科全书型的风格上，做“批评”很行，用来创造解决问题的方法思路不行；另一种是智能型的，启发性为主的，从全局的联系出发权衡利弊的，专门用来对付混顿的。教条才会混沌。
　

---

说的很对，启发式思维更重要，能否展开发表高论

 回复: 建的什么模，欢迎讨论
　

---

我们对建模的理解不一致
建模应该有分析和设计两个阶段，在设计阶段引入设计模式知识应该没错
我感到对建的什么模的问题应该深入讨论，我觉得建的就是一个oo计算模型
这种提法欢迎批评

包括设计，但是包括很少的设计

 完全不同意，系统是模型的实例
　

---

全文凌乱，也许是我水平不够。
系统，应该是system吧
模型，应该是model吧
实例，应该是instance吧
模型应该是系统的抽象，模型所提供的信息是不完全的，但是模型在一定层次上或者一些方面提供了系统的一定层次上的信息。
MDA中定义的阶段性制品是PIM - PSM - System - ... - 0/1
instance是说class和object的关系。
虽然模型中也多是用class来表现的，最后的系统中也都是object，但是，他们绝对不是一一对应的。至少现在不是。
over

 回复: 从指导编程的角度
　

---

编程者为建模过程的一个参与者，他所期待的就是能够指导编程
我的真正意思为模型已经控制了系统实现，可能表述不太精确，但我不想太学术化，

 文才一般
　

---

不过思路不错
兄弟，你的观点还很初级，得多琢磨琢磨才行 ^_^

 系统不是system，那是什么呢？请楼主答疑
　

---

要么就是我理解的model意义要比你说的model更宽泛。

 回复: 系统不是system，那是什么呢？请楼主答疑
　

---

软件开发从某种角度来讲，为一种规约化过程，我当时的想法表述为
模型规约了开发过程，可能更准确，对这个问题不要纠缠了，我们尽量能
引进新的思想，指导开发，这是根本

 回复: 更正：系统与模型为实现关系，不是实例关系
　

---

在这一问题上大家争论较多，我更正自己的看法