转载自：
http://hi.baidu.com/parryblog/blog/item/2d1ae59a72b043bcc9eaf4a0.html 本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：
第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。
第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。
第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。
使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。
书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。接下来，就是要将他们这些期望定义出来。这个过程，就是业务用例获取的过程。笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。
笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。
建模第一步，从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。参考上一篇的需求描述，下载实例
第二步，找出每个用户要做的事，即业务用例，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例
第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。下载实例
第四步，绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。笔者仍然强烈推荐使用activity diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。下载实例
第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。下载实例
第六步，在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。
第七步，根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在business usecase下说明。不过本实例中笔者还是按照正规方法来建模的。下载实例
需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。这也是RUP倡导的迭代开发模式。
经过以上的步骤，我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型。这个过程无法以步骤说明。或许以后笔者会专门针对模型分析写点东西。另外除了模型，还至少需要写业务架构文档、用例规约和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构，但很不好表达业务规则和非业务需求，这些需要在文档中说明。例如用例的前置条件和后置条件就是一种业务规则。读者可以在RUP文档中找到这些文档的模板。
http://hi.baidu.com/parryblog/blog/category/%CF%B5%CD%B3%B7%D6%CE%F6
http://hi.baidu.com/parryblog/blog/category/%D0%E8%C7%F3%B7%D6%CE%F6
通过@PathVariabl注解获取路径中传递参数JAVA
@RequestMapping(value = "/{id}/{str}")
public ModelAndView helloWorld(@PathVariable String id, @PathVariable String str) {
System.out.println(id);
System.out.println(str);
return new ModelAndView("/helloWorld");
}
用@ModelAttribute注解获取POST请求的FORM表单数据JSP
<form method="post" action="hao.do">
a: <input id="a" type="text" name="a"/>
b: <input id="b" type="text" name="b"/>
<input type="submit" value="Submit" />
</form>
JAVA pojo
public class Pojo{
private String a;
private int b;
}
JAVA controller
@RequestMapping(method = RequestMethod.POST)
public String processSubmit(@ModelAttribute("pojo") Pojo pojo) {
return "helloWorld";
}
直接用HttpServletRequest获取JAVA
@RequestMapping(method = RequestMethod.GET)
public String get(HttpServletRequest request, HttpServletResponse response) {
System.out.println(request.getParameter("a"));
return "helloWorld";
}
用注解@RequestParam绑定请求参数a到变量a当请求参数a不存在时会有异常发生,可以通过设置属性required=false解决,
例如: @RequestParam(value="a", required=false)
JAVA
@RequestMapping(value = "/requestParam", method = RequestMethod.GET)
public String setupForm(@RequestParam("a") String a, ModelMap model) {
System.out.println(a);
return "helloWorld";}
Collection是List和Set两个接口的基接口
List在Collection之上增加了"有序"
Set在Collection之上增加了"唯一"
而ArrayList是实现List的类...所以他是有序的.
它里边存放的元素在排列上存在一定的先后顺序
而且ArrayList是采用数组存放元素
另一种List LinkedList采用的则是链表。
Collection和Map接口之间的主要区别在于：Collection中存储了一组对象，而Map存储关键字/值对。
在Map对象中，每一个关键字最多有一个关联的值。
Map:不能包括两个相同的键，一个键最多能绑定一个值。null可以作为键，这样的键只有一个；可以有一个或多个键所对应的
值为null。当get()方法返回null值时，即可以表示Map中没有该键，也可以表示该键所对应的值为null。因此，在Map中不能由get()方法来判断Map中是否存在某个键，而应该用containsKey()方法来判断。
继承Map的类有：HashMap，HashTable
HashMap：Map的实现类，缺省情况下是非同步的，可以通过Map Collections.synchronizedMap(Map m)来达到线程同步
HashTable：Dictionary的子类，缺省是线程同步的。不允许关键字或值为null
当元素的顺序很重要时选用TreeMap，当元素不必以特定的顺序进行存储时，使用HashMap。Hashtable的使用不被推荐，因为HashMap提供了所有类似的功能，并且速度更快。当你需要在多线程环境下使用时，HashMap也可以转换为同步的。
为什么要使用集合类
当你事先不知道要存放数据的个数，或者你需要一种比数组下标存取机制更灵活的方法时，你就需要用到集合类。
理解集合类
集合类存放于java.util包中。
集合类存放的都是对象的引用，而非对象本身，出于表达上的便利，我们称集合中的对象就是指集合中对象的引用（reference)。
集合类型主要有3种：set(集）、list(列表）和map(映射)。
(1)集 （Set）：口袋
集（set）是最简单的一种集合，它的对象不按特定方式排序，只是简单的把对象加入集合中，就像往口袋里放东西。
对集中成员的访问和操作是通过集中对象的引用进行的，所以集中不能有重复对象。
集也有多种变体，可以实现排序等功能，如TreeSet，它把对象添加到集中的操作将变为按照某种比较规则将其插入到有序的对象序列中。它实现的是SortedSet接口，也就是加入了对象比较的方法。通过对集中的对象迭代，我们可以得到一个升序的对象集合。
(2)列表 （List）：列表
列表的主要特征是其对象以线性方式存储，没有特定顺序，只有一个开头和一个结尾，当然，它与根本没有顺序的集是不同的。
列表在数据结构中分别表现为：数组和向量、链表、堆栈、队列。
关于实现列表的集合类，是我们日常工作中经常用到的，将在后边的笔记详细介绍。
(3)映射 （Map）：键值对
映射与集或列表有明显区别，映射中每个项都是成对的。映射中存储的每个对象都有一个相关的关键字（Key）对象，关键字决定了对象在映射中的存储位置，检索对象时必须提供相应的关键字，就像在字典中查单词一样。关键字应该是唯一的。
关键字本身并不能决定对象的存储位置，它需要对过一种散列(hashing)技术来处理，产生一个被称作散列码(hash code)的整数值，散列码通常用作一个偏置量，该偏置量是相对于分配给映射的内存区域起始位置的，由此确定关键字/对象对的存储位置。理想情况下，散列处理应该产生给定范围内均匀分布的值，而且每个关键字应得到不同的散列码。
集合类简介
java.util中共有13个类可用于管理集合对象，它们支持集、列表或映射等集合，以下是这些类的简单介绍
集：
HashSet： 使用HashMap的一个集的实现。虽然集定义成无序，但必须存在某种方法能相当高效地找到一个对象。使用一个HashMap对象实现集的存储和检索操作是在固定时间内实现的.
TreeSet： 在集中以升序对对象排序的集的实现。这意味着从一个TreeSet对象获得第一个迭代器将按升序提供对象。TreeSet类使用了一个TreeMap.
列表：
Vector： 实现一个类似数组一样的表，自动增加容量来容纳你所需的元素。使用下标存储和检索对象就象在一个标准的数组中一样。你也可以用一个迭代器从一个Vector中检索对象。Vector是唯一的同步容器类??当两个或多个线程同时访问时也是性能良好的。（同步的含义：即同时只能一个进程访问，其他等待）
Stack: 这个类从Vector派生而来，并且增加了方法实现栈??一种后进先出的存储结构。
LinkedList: 实现一个链表。由这个类定义的链表也可以像栈或队列一样被使用。
ArrayList: 实现一个数组，它的规模可变并且能像链表一样被访问。它提供的功能类似Vector类但不同步。
映射：
HashTable： 实现一个映象，所有的键必须非空。为了能高效的工作，定义键的类必须实现hashcode()方法和equal()方法。这个类是前面java实现的一个继承，并且通常能在实现映象的其他类中更好的使用。
HashMap： 实现一个映象，允许存储空对象，而且允许键是空（由于键必须是唯一的，当然只能有一个）。
WeakHashMap： 实现这样一个映象：通常如果一个键对一个对象而言不再被引用，键/对象对将被舍弃。这与HashMap形成对照，映象中的键维持键/对象对的生命周期，尽管使用映象的程序不再有对键的引用，并且因此不能检索对象。
TreeMap： 实现这样一个映象，对象是按键升序排列的。
下图是集合类所实现的接口之间的关系：
Set和List都是由公共接口Collection扩展而来，所以它们都可以使用一个类型为Collection的变量来引用。这就意味着任何列表或集构成的集合都可以用这种方式引用，只有映射类除外（但也不是完全排除在外，因为可以从映射获得一个列表。）所以说，把一个列表或集传递给方法的标准途径是使用Collection类型的参数。
List接口
List是有序的Collection，使用此接口能够精确的控制每个元素插入的位置。用户能够使用索引（元素在List中的位置，类似于数组下标）来访问List中的元素，这类似于Java的数组。
和下面要提到的Set不同，List允许有相同的元素。
除了具有Collection接口必备的iterator()方法外，List还提供一个listIterator()方法，返回一个ListIterator接口，和标准的Iterator接口相比，ListIterator多了一些add()之类的方法，允许添加，删除，设定元素，还能向前或向后遍历。
实现List接口的常用类有LinkedList，ArrayList，Vector和Stack。
ArrayList类
ArrayList实现了可变大小的数组。它允许所有元素，包括null。ArrayList没有同步。
size，isEmpty，get，set方法运行时间为常数。但是add方法开销为分摊的常数，添加n个元素需要O(n)的时间。其他的方法运行时间为线性。
每个ArrayList实例都有一个容量（Capacity），即用于存储元素的数组的大小。这个容量可随着不断添加新元素而自动增加，但是增长算法并没有定义。ArrayList当需要插入大量元素时，在插入前可以调用ensureCapacity方法来增加ArrayList的容量以提高插入效率。
和LinkedList一样，ArrayList也是非同步的（unsynchronized）。
Map接口
请注意，Map没有继承Collection接口，Map提供key到value的映射。一个Map中不能包含相同的key，每个key只能映射一个value。Map接口提供3种集合的视图，Map的内容可以被当作一组key集合，一组value集合，或者一组key-value映射。
HashMap类
HashMap和Hashtable类似，不同之处在于HashMap是非同步的，并且允许null，即null value和null key。，但是将HashMap视为Collection时（values()方法可返回Collection），其迭代子操作时间开销和HashMap的容量成比例。因此，如果迭代操作的性能相当重要的话，不要将HashMap的初始化容量设得过高，或者load factor过低。
----------------------------------------------------------------------------
1.-------------------->
List是接口，List特性就是有序,会确保以一定的顺序保存元素.
ArrayList是它的实现类,是一个用数组实现的List.
Map是接口,Map特性就是根据一个对象查找对象.
HashMap是它的实现类,HashMap用hash表实现的Map,就是利用对象的hashcode(hashcode()是Object的方法)进行快速（Hash）散列查找.(关于散列查找,可以参看<<数据结构>>)
2.-------------------->
一般情况下,如果没有必要,推荐代码只同List,Map接口打交道.
比如:List list = new ArrayList();
这样做的原因是list就相当于是一个泛型的实现,如果想改变list的类型,只需要:
List list = new LinkedList();//LinkedList也是List的实现类,也是ArrayList的兄弟类
这样,就不需要修改其它代码,这就是接口编程的优雅之处.
另外的例子就是,在类的方法中,如下声明:
private void doMyAction(List list){}
这样这个方法能处理所有实现了List接口的类,一定程度上实现了泛型函数.
3.--------------------->
如果开发的时候觉得ArrayList,HashMap的性能不能满足你的需要,可以通过实现List,Map(或者Collection)来定制你的自定义类
架构师最基本的素质，总结出两点，1是技术知识广度，2是业务行业深度。
1 架构师是技术领导。 架构师必须要有技术，而且还是领导。架构师要带领自己团队完成自己的任务，完全凭借自己的能力做事情，完全是匹夫之勇，根本不提倡。
2 架构师理解软件流程。 架构师必须了解软件流程，否则无法驱动整个团队前进，如果一个架构师不熟悉开发流程，无法协调产品线相关人员进行高效工作，也无法指导团队成员完成自己的工作。所以来说架构师一般不是空降兵（除非是全新的部门），因为空降兵一般不会熟悉新公司的开发流程，即使是同一个行业的，各个公司的差别还是很大。所以说听说某某去某某公司做首席架构师或者首席科学家，一般是高风险的事情，即使他对这个行业很了解。
3 架构师必须熟悉业务领域。 如果一个架构师不熟悉自己的行业，做的架构就是纸上谈兵，熟悉业务领域的架构师，才能很好的理解需求，做出合适的方案。互联网和网络安全是完全不同的两个方向，即使你熟悉里面的各种具体技术，但是以互联网的架构来做网络安全产品，肯定是100%的失败。
我做PKI的时候，项目最初的使用.net，使用微软的crytoAPI，开发的很顺利。后来来了一位新的架构师，觉得.net不能跨平台，决定?用java，做出产品后，发现找不到arm cpu的jdk，使用平台有限。再次决定使用openssl做，最后这个项目以失败而告终。后来我想过arm cpu都是嵌入式设备用的，根本没有任何嵌入式设备提供CA服务。
4 架构师必须要有广度的知识。 架构师考虑的问题必须全面，必须了解的要广，具体的细节可以不关注，因为细节变化很快。很多具体技术人员出身的架构师，只关注于具体的细节，某些方面做的很好，整体的性能很差。
下面这个项目的成功可以理解为一个笑话。某公司的两个部门都做c程序的，A部门做的平台使用的x86和mips，B部门使用平台是x86和 arm，后来A部门的一个模块要给B部门用，最后发现根本不能运行。最后A部门发现arm平台使用big endian模式，这样A部门的20多名员工，检查代码中所有非零整数，经过数个月苦战，才修改完毕。其实解决方法很简单，因B部门的代码也是首先在 x86做的，做的时候他们考虑了cpu的endian模式。这并不能说B部门架构师很牛，从另一个方面说他的无知。因为板子有跳线，专门切换cpu的是 big endian还是little endian，这样两个部门都可以不修改程序。
5 架构师必须是写程序的高手。
架构师一般都是?发人员出身，一般都是团队的核心。优秀的架构师应该了解团队使用各种技术，有了这些知识，才能和开发人软进行有效沟通。
有一个项目架构使用xml做配置，因为病毒库很庞大，最后导致xml 达30多兆，服务端的java程序使用dom 进行过滤的时候，30兆xml加载很慢，频繁出现out of memory。这个项目后来搁浅。根据以前的经验发现 msxml加载30多M的xml 不过几秒，而且msxml的xpath速度很快，后来专门为此写了JNI处理xml的。
6架构师是优秀的沟通人员。 架构师一定要会忽悠，至少要扯淡。架构师不但要指导本部门员工的工作，也要协调其他部门的资源，还要向用户收集需求，制定规格说明书，重要的把用户的不合理要求砍掉，合理需求遵循自己的思路