BlogJava-Programming on the fly-随笔分类-25.UMLhttp://www.blogjava.net/Werther/category/40732.htmlLive as if you were to die tomorrow. Learn as if you were to live forever. zh-cnTue, 09 Nov 2010 17:14:08 GMTTue, 09 Nov 2010 17:14:08 GMT60SVN使用技巧http://www.blogjava.net/Werther/archive/2010/11/08/337506.htmlWertherWertherMon, 08 Nov 2010 02:39:00 GMThttp://www.blogjava.net/Werther/archive/2010/11/08/337506.htmlhttp://www.blogjava.net/Werther/comments/337506.htmlhttp://www.blogjava.net/Werther/archive/2010/11/08/337506.html#Feedback0http://www.blogjava.net/Werther/comments/commentRss/337506.htmlhttp://www.blogjava.net/Werther/services/trackbacks/337506.html阅读全文

Werther 2010-11-08 10:39 发表评论
]]>为什么要用UML建模之建模原理http://www.blogjava.net/Werther/archive/2009/07/10/286333.htmlWertherWertherFri, 10 Jul 2009 15:28:00 GMThttp://www.blogjava.net/Werther/archive/2009/07/10/286333.htmlhttp://www.blogjava.net/Werther/comments/286333.htmlhttp://www.blogjava.net/Werther/archive/2009/07/10/286333.html#Feedback0http://www.blogjava.net/Werther/comments/commentRss/286333.htmlhttp://www.blogjava.net/Werther/services/trackbacks/286333.html
　　第一，选择要创建什么模型，对如何动手解决问题和如何形成解决方案有着意义深远的影响。
　
　　换句话说，就是要好好地选择模型。正确的模型将清楚地表明最棘手的开发问题，提供不能轻易地从别处获得的洞察力；错误的模型将使人误入歧途，把精力花在不相关的问题上。

　　暂时先把软件问题放在一边，假设现在正试图解决量子物理学上的一个问题。诸如光子在时空中的相互作用问题，其中充满了令人惊奇的难解的数学问题。选择一个不同的模型，所有的复杂问题一下子就变得可行了（虽然不容易解决）。在这个领域中，这恰恰是Feynmann图的价值，它提供了对非常复杂问题的图形表示。类似地，在一个完全不同的领域里，假设正在建造一座新建筑，将会关心疾风对它的影响。如果建立了一个物理模型，并拿到风洞中去实验，虽然小模型没有精确地反映出大的实物，但也可以从中找出一些有趣的东西。因此，如果正在建立一个数学模型，然后去模拟，将知道一些不同的东西；与使用物理模型相比，也可能获得更多新的场景。通过对模型进行严格的持续的实验，将更信任已经建模的系统，事实上，它在现实世界中将像期望的那样工作得很好。

　　对于软件而言，所选择的模型将在很大程度上影响对领域的看法。如果以数据库开发者的观点建造一个系统，可能会注意实体—联系模型，该模型把行为放入触发器和存储过程中。如果以结构化开发者的观点建造一个系统，可能得到以算法为中心的模型，其中包含从处理到处理的数据流。如果以面向对象开发者的观点建造一个系统，将可能得到这样一个系统：它的体系结构以一组类和交互模式（指出类如何一起工作）为中心。可执行的模型对测试有很大帮助。上述的任何一种方法对于给定的应用系统和开发文化都可能是正确的，经验表明，在构建有弹力的体系结构中面向对象的方法表现得更为出众，即使对使用大型数据库或计算单元的系统也是如此。尽管事实如此，但要强调一点，不同的方法将导致不同种类的系统，并且代价和收益也是不同的。

　　第二，可以在不同的精度级别上表示每一种模型。
　　
　　如果正在建造一座大厦，有时需要从宏观上让投资者看到大厦的样子，感觉到大厦的总体效果。而有时又需要认真考虑细节问题，例如，对复杂棘手的管道的铺设，或对少见的结构件的安装等。

　　对于软件模型也是如此。有时一个快速简洁且是可执行的用户界面模型正是所需要的，而有时必须耐着性子对付比特，例如，描述跨系统接口或解决网络瓶颈问题就是如此。在任何情况下，最好的模型应该是这样的：它可以让你根据谁在进行观察以及为什么要观察选择它的详细程度。分析人员或最终用户主要考虑“做什么”的问题，开发人员主要考虑“怎样做”的问题。这些人员都要在不同的时间以不同的详细程度对系统进行可视化。

　　第三，最好的模型是与现实相联系的。

　　如果建筑的物理模型不能以与真实的建筑相同的方式做出反应，则它的价值是很有限的；飞机的数学模型，如果只是假定了理想条件和完美制造，则可能掩盖真实飞机的一些潜在的、致命的现实特征。最好是有能够清晰地联系实际的模型，而当联系很薄弱时能够精确地知道这些模型怎样与现实脱节。所有的模型都对现实进行了简化；但有一点要记住，关键是简化不要掩盖掉任何重要的细节。

　　软件领域中结构化分析的致命弱点是在分析模型和系统设计模型之间没有基本的联系。随着时间的推移，这个不可填充的裂缝会使系统构思阶段和实施阶段出现不一致。在面向对象的系统中，可以把各个几乎独立的系统视图连结成一个完整的语义整体。

　　第四，单个模型或视图是不充分的。对每个重要的系统最好用一小组几乎独立的模型从多个视角去逼近。

　　如果正在建造一所建筑物，会发现没有任何一套单项设计图能够描述该建筑的所有细节。至少需要楼层平面图、立面图、电气设计图、采暖设计图和管道设计图。并且，在任何种类的模型中都需要从多视角来把握系统的范围（例如不同楼层的蓝图）。

　　在这里的重要短语是“几乎独立的”。在这个语境中，它意味着各种模型能够被分别进行研究和构造，但它们仍然是相互联系的。如同建造建筑物一样，既能够单独地研究电气设计图，但也能看到它如何映射到楼层平面图中，以及它与管道设计图中的管子排布的相互影响。

　　面向对象的软件系统也如此。为了理解系统的体系结构，需要几个互补和连锁的视图：用况视图（揭示系统的需求）、设计视图（捕获问题空间和解空间里的词汇）、交互视图（展示系统各部分之间以及系统与环境之间的联系）、实现视图（描述系统的物理实现）和部署视图（着眼于系统的工程问题）。每一种视图都可能有结构方面和行为方面。这些视图一起从整体上描绘了软件蓝图。

　　根据系统的性质，一些模型可能比另一些模型要重要。例如，对于数据密集型系统，表达静态设计视图的模型将占主导地位；对于图形用户界面密集型系统，静态和动态的用况视图就显得相当重要；在硬实时系统中，动态进程视图尤为重要；最后，在分布式系统中，例如Web密集型的应用，实现模型和部署模型是最重要的。

Werther 2009-07-10 23:28 发表评论
]]>为什么要用UML建模之建模的重要性http://www.blogjava.net/Werther/archive/2009/07/09/286164.htmlWertherWertherThu, 09 Jul 2009 15:17:00 GMThttp://www.blogjava.net/Werther/archive/2009/07/09/286164.htmlhttp://www.blogjava.net/Werther/comments/286164.htmlhttp://www.blogjava.net/Werther/archive/2009/07/09/286164.html#Feedback0http://www.blogjava.net/Werther/comments/commentRss/286164.htmlhttp://www.blogjava.net/Werther/services/trackbacks/286164.html阅读全文

Werther 2009-07-09 23:17 发表评论
]]>