半把刀小说:应用软件建模的各个阶段

面向对象的软件工程和面向对象的方法学是前人经验的积累，我觉得应用软件建模的可以用四个阶段：需求建模、分析建模、构架建模、设计模式。
如何获取需求，如何对描述问题域的需求模型导出分析模型，如何进行架构建模、设计出高度可扩展性的良好架构，如何应用设计模式、对模型进行不断改进和重构，这些都是必须实践的问题，也是必须从各种各样方法学进行学习的问题。
在需求方面，根据不同的情况，Use case, Use map, CRC都是可以利用的，还有Alistair Cockburn的用例模版；
在建模方面，UML是标准，建模过程中需要经常借鉴分析模式的内容，分析模式对系统问题域的建模作用是无穷的，对诸如party , business rule , inventory , account这样的东西，对问题域的分析和分析模型的抽象获取很有帮助；
对于软件体系架构建模也有很多前人的经验供参考与借鉴，在此基础上根据应用系统的不同环境灵活应用对架构建模非常有益，比如在《Pattern-Oriented Software Architecture (面向模式的软件体系架构) 》中首次提出了8种体系结构模式： 层（Layers）、管道和过滤器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-视图-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）
在设计时，通过建立的模型从而应用设计模式是常用的方法，发觉设计模式社团是如此的丰富，以至于你几乎很难再去构造出新的模式，但根据长期的使用积累，对具体的一些场景会有一些小的发现。譬如，在系统里使用factoryMethod创建对象，Observer, strategy 实现MVC，用command和来实现undo , redo,用fa?ade模式来进行层与层之间的交互，State模式应用，例如购物过程（登录、下单、结账），Singleton就不用说了，使用模式进行分析和设计是如此灵活、有效，我觉得他们能解决设计中大部分问题。
根据不同的实现语言，应用一些面向对象的基本技巧如idiom , refactoring对模型进行重构、优化也非常重要。

1、需求建模
在软件工程中，用例是一种在开发新系统或者软件改造时捕获潜在需求的技术。每个用例提供了一个或多个场景，该场景揭示了系统是如何同最终用户或其它系统交互的，从而获得一个明确的业务目标。用例要避免技术术语，取而代之的是最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
需求建模误区：在需求获取的过程中有一个非常容易犯错的误区即把软件的用户界面模型当成需求模型，其中在网站类的软件项目尤为突出，从事网站或者类似的软件需求的许多人都不懂真正的软件需求是什么东西，甚至包括一些SAP/ERP项目这类都是同样的问题，尽管那不是网站，他们犯的一般共同的错误就是把网页表现形式（那其实是美工的工作），以及内容的采排看作是需求，完全没有一个用例的观念。

2、分析建模：
面向对象开发过程中一个很重要的原则是：设计软件使得软件的结构反映问题的结构。按照这样的一个原则，我们发现从分析到设计所得到的模型最终都存在某种内在的相似性，使得大多数人觉得它们之间没有多大的区别。事实是否如此呢？
分析和设计之间还是存在着不同之处，这些不同之处也就是分析模式的用武之地。在进行分析时想方设法去理解问题的本质，这不仅仅是用用例(Use Case)列出需求清单这么简单的事情。在软件建模过程中，经过需求建模，从问题域得到系统的需求模型，从需求获取的角度上看这是一件很有价值的事，但并不代表着就可以直接进入到设计阶段，对捕获的需求模型进行深入分析、抽象，引用业界已有的分析模式对需求模型描述的问题域进行进一步抽象，获得分析模型。

3、架构建模
在开发过程中得到的一些好的架构经验总结，称之为架构框架。所谓的架构框架实际上是一种可重用的架构模式，这种模式是从好的架构模式里总结出来，这些架构模式可以进一步地被其他人所重用。
在经历60年代的软件危机之后，使人们开始重视软件工程的研究。来自不同应用领域的软件专家总结了大量的有价值的知识。 当初，人们把软件设计的重点放在数据结构和算法的选择上，如Knuth提出了数据结构+算法=程序。 但是随着软件系统规模越来越大、越来越复杂，使软件系统的架构越来越重要。
软件设计的一个核心问题是能否使用重复的体系架构，即能否达到体系架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一体系架构。基于这个目的，许多学者们开始研究和实践软件体系架构的模式问题。在《Pattern-Oriented Software Architecture (面向模式的软件体系架构) 》中首次提出了8种体系结构模式： 层（Layers）、管道和过滤器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-视图-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。

4、设计模式
设计模式是支撑架构的一种重要组件，这与建筑有很相象的地方，一个建筑物建立设计需要建筑架构设计，在具体施工中，有很多建筑方面的规则和模式。 在一定程度上，架构设计是骨架，设计模式就是肉
设计模式是在一定的上下文环境中，用于解决一定的问题，在寻求解决方案时会遇到的一些阻力以及给出的解决方案。在设计模式使用的过程中，灵活应用是关键，一般有两种方案能够帮助开发、设计人员比较好的使用设计模式：一是，根据场景，但凡设计模式都是在一定场景下某些问题的解决方案，对系统进一步分析，找出适合一些被广泛承认的设计模式使用的场景，并根据模式给出解决方案；二是、重构设计方案，设计进行的过程中对已有的设计方案进行重构，一个可改进的设计，设计方案本身会呈现一些与“臭味道”，重设计模式的角度，对设计方案不断重构，也是一种设计良好系统的方法。
在系统的进一步设计和开发中，必将用到大量的设计模式，模式并非发明的，是在应用的过程中发现的，作者也试图去发现一些在某些场景中的某些问题的通用解决方案，并归纳成模式。设计模式的灵活应用也是很有意义的，这就需要根据个体的经验和掌握程度来决定。

五、综述
在以上应用软件建模的几个领域中，每一个领域都解决了软件模型构建过程中一定层面上的问题，这些都是值得研究的重点。对这几个领域模型的了解、学习、使用、总结、抽象，试着自己提出在一定上下文环境中针对一些特定问题的解决方案的模式，这些工作我认为都是很有意义的。