OO系统设计师之路 笔记1

1,软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。而软件框架是一个实现，一个半成品，是针对一个特定问题的解决方案和辅助工具。因此，架构是一个逻辑的构成，而框架是一个可用的半成品
2,J2EE规范描述了一系列逻辑部件，描述了这些部件的职责和它们的规范，约定了这些部件之间交互的接口和协议、标准，规划出一个如何利用这些逻辑部件来实现一个应用系统的蓝图。J2EE是一个软件架构。而根据这一设想，各产商开发出了各自的产品，包括开发工具和应用容器，开发者利用这些工具和容器就能方便的开发出符合J2EE规范的应用程序。这些工具和容器就是软件框架。再比如，MVC是一个设计模式，它将应用程序划分为实体，控制和视图三个逻辑部件，我们可以说它是一个软件架构。而Strus，JSF，WEBWork等分别以自己的方式实现了这一架构，提供了一个半成品，帮助开发人员迅速地开发一个符合MVC架构的应用程序，我们说Strus,JSF,WEBWork是软件框架。
3,软件架构通过架构师定下来后，接着该由设计师来决定每一个层次的具体框架设计了(基类封装)。
4,分析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物
5,OO系统分析员之路中，我们始于什么是用例，结束于需求规格说明书，最后的结果是系统用例。系统用例规定了系统范围，通过用例场景，规定了系统蓝图，让我们知道了系统将如何实现业务用例中规定的业务。这些工作，是由系统分析员来完成的
6,到这里为止，我们还不知道如何让计算机来执行这些业务。大家都知道，在需求过程结束后，即将进行的是分析设计过程，这是系统设计师的职责.说明如何做系统设计，要运用哪些工具，产生哪些结果，以及如何来验证我们的设计是否正确。
7,分析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物
8,分析类:边界类(boundary),实体类(entity,控制类(control),用例场景需要的actor类
9,分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。上述的四个分析类可以完全模拟计算机的执行过程。分析类具化以后产生真正的实现类，即所谓的设计类，也就是大多数设计师所说的类图
10,分析模型正是OO设计的核心，而设计类只是OO的实现手段。组件级的复用实际上是通过分析模型表达的，而设计模型中的复用，只是利用了OO语言的特性，来实现复用的要求。
11,分析模型是MVC模式的经典应用,商业系统无论多复杂，无论什么行业，其本质无非是人，事，物， 规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了
12,析类不代表实现，它具化成设计类以后才是实现。分析类是系统元素的高层抽象。有经验的设计师，特别是那些擅长于使用设计模式的设计师们都知道，OO系统要保持扩展能力，复用性要好，要把变更影响控制在小范围内，就要应用高层次的抽象，用高层次的抽象接口来表达系统行为，而把具体实现delay到子类，配置文档，甚至运行期去
13,分析模型对系统设计来说也同样延续了这样的思想，用四个高度抽象的分析类来表达系统行为，而把实现delay到设计类中去。这些抽象透明于实现方式，也透明于实现语言，它表达的核心观点是系统架构，业务实现模式和规范，需求可回溯的验证
14,我们用一个实体分析类表达了某个业务实体，在分析模型中我们定义了所有针对该实体的交互和存取操作，对分析模型这个层次的抽象来说已经完整表达了计算机系统对业务需求的模拟实现。但其实这时并未真正的实现这个业务需求，一直到具化成设计类后，根据开发语言特性，框架，规范等等要求，这个实体分析类可以被具化成一个或多个SDO，POJO，EntityBean，可以用Hibernate，可以用 Webshpere BO，也可以用Weblogic XMLbean...等等。完全可以根据实际需要来确定实现方式和语言，因此实现得以delay，这就带来了OO扩展和复用的潜在能力。并且这时设计师已经不用担心具化出的设计类是否会脱离需求，它们已经在分析模型层次被验证，而能专心考虑系统实现所要求的那些特性
15,为什么要用分析类而不是设计类去验证需求呢？这是由于抽象层次更高，分析类比设计类验证需求的工作量以及可能的变化都要少很多。比如针对登录要求，如果用分析类来表达，我们只需要向登录control类发一条登录请求就OK了。而设计类由于与实现方式相关，并且已经具化到了实现，所以根据安全验证方式不同，LDAP，CA，SSL，或应用服务器不同，登录方式和方法都不同，并且可能是很多个步骤，例如getUser(),getRole(),getGroup(),register()...你愿意用这么多说明才能表示已经验证了一个简单的登录要求吗?慢着，如果更换了安全模式呢？更换了应用服务器呢？这在现实情况中也很常见，对分析类来说，由于抽象层次高于实现方式，因此继续有效，而设计类却必须更改。这就是为什么要用分析模型来验证需求的原
16,分析模型比设计模型要稳定得多，因此用它来验证和表达系统到需求的映射是很好的。这有助于在开发过程中当实现类变来变去，一个类改两个，突然又加了一个设计模式(这种情形非常的常见吧?)时，保持系统到需求映射的稳定，同时也就保持了一个稳定的系统视图和业务架构。对开发小组来说，不会因为这些变动影响到他们对系统整体的认识
17,不是从UML的定义中去思考如何做软件，而是站在软件工程的角度，去UML中找寻需要的工具。正是这一转变使我对UML的认识茅塞顿开
18,对软件项目来说，OO也好，面向过程也好，UML也好，UC矩阵也好，这些都不是最重要的，软件项目真正的灵魂是软件工程。软件工程的需要才是这些工具诞生的原因
19,在正式开始做分析模型之前，笔者有必要提醒一下，分析模型是系统的高层抽象，是高于实现语言和实现方式的。因此在做分析模型过程中，要跳出固有的java思维，C++思维，同时也暂时不要考虑设计模式的应用，而专心的，用OO思维把四个分析类的职责和交互，以及它们之间的关系定义清楚。如果说用例分析大部分情况下是程式化的（笔者正希望它是程式化的），那么你会发现，分析模型大部分工作也是程式化
20,现在，我们有这样一些原料，用例场景提供了需求的输入，领域模型提供了初始的业务原材料，还有用例规约和补充规约提供了详尽的规则。正如笔者在之前的文章中提到的一句话：用例场景非常非常的重要，后续的工作就靠它了
21,actor分析类来自用例分析中的actor，实体类来自领域模型，边界类来自用例场景中actor-计算机交互，控制类来自业务规则（包括用例规约中的前置、后置条件、业务规则以及补充规约中的全局规则）。所使用的工具是时序图，目标是实现用例场景
22,所有的实体类没有做任何变动，直接照搬了业务实体(领域模型)，所谓的控制类，只是机械的在每一个实体前加了一个控制器，边界类只用了一个。至于过程，更是和用例场景一模一样，只不过形式不同而已，改用了计算机术语.整个过程很简单，很程式化，对吗？不用脑子都能做。尽管如此，我们仍然得到了一个分析模型的静态图
23,在做分析模型时，从时序图开始做，需要用到一个分析类时，就转到类图中创建这个类，再从左边的树形列表里把类拖到时序图上。从一个对象画一条表示交互消息的箭头到另一个对象后，右键点击线条，选择"new operation"，再输入操作名，这时Rose会在线上标明这个操作名称的同时在对应的类上创建这个方法。这样，在绘制时序图的同时也生成了静态类图。最后再把类之间的交互用线连起来表示这个关联关系，静态图就完成了。
24,但是一个系统原型已经出来了。我们得到了可以完全实现需求的一些类，主要的类方法也有了。如果你想偷懒的话，直接把它转换成设计类图，把中文方法名改为英文，再把领域模型文档（不记得了回头查以前的文章）中提到的实体属性填入，就已经可以交付开发了。因为需求已经实现了，类有了，方法有了，类属性有了，别忘了在用例分析过程中已经用静态HTML做了系统原型，因此界面也有了。一切开发需要的东西都全了。比如我们用Strus+hibernate架构，一个实体类就是一个POJO，一个控制类就是一个action，至于界面，在静态HTML里填入java代码改成JSP呗。
25,居然就做了一个设计，恩!？可事实就是这样，谁说分析设计就一定要动脑子？不动脑子就不能做设计吗？就不能体现一个设计师的价值吗？设计的目的是什么？漂亮？好看？采用了很多新技术？体现了设计师的高明手段和渊博知识？NONONO！设计的目的是为了实现需求不是吗？如果需求就是这样简单，我们已经实现了，还能不动脑子，干嘛做那没事找抽型的，老板又不因此少付一分钱工资，能少干点活儿不好吗？很多设计师因为懂得几个设计模式，总要想方设法弄上去，把简单的问题弄复杂，好象只有这样才能体现他的价值
26,设计师的真正价值，是用最简单，最好懂，最简洁的设计完成最复杂的要求，而不是相反！一项技术，正因为能够被大多数人掌握才能流行，否则就只能呆在实验室里
27,之所以我们没动脑子，是因为系统分析员们经过用例分析系列中的卓越工作，给我们打下了如此坚实的基础，才使得我们的工作简单到了不用动脑子的地步。你还得感谢UML用一套很好的方法，让你可以轻而易举的从需求转化到类设计。你已经站在巨人的肩膀上了，所以就一边儿偷着乐吧。
28,很多情况下，事情并没有这么简单。这个粗糙的分析模型虽然可以工作，但的确有很多可以优化的地方。不用担心你会因为做了一份简单而不用动脑子的工作而失去饭碗。因为下一篇，我们将会讨论怎么样，从哪些方面，以及如何依据补充规约，系统架构以及维护要求等来优化和调整这个模型。这下设计师有用武之地了，学习到的知识和积累的经验要发挥作用了，失落的自我价值也能体现了。为了证明设计师不是混吃喝的并且保住饭碗，敬请期待下篇，分析模型的优化和调整。




参考：http://blog.csdn.net/coffeewoo/article/details/5948999