Head First Object-Oriented Design and Analysis学习笔记（六）

第六章

Solving really big problems

“My Name is Art Vandelay… I am an Architect”

前言：

这一章带着我们一步一步地去分析一个big problem，介绍了其他分析设计的工具，例如domain analysis，use case diagrams等。基本过程：Gathering features, Domain analysis, Breaking system into modules, Figuring out system use the MVC pattern

案例分析：

案例描述：

现在我们要开发一个游戏框架，客户的基本描述是这样的：该框架可以让游戏设计者使用来创建回合制的策略游戏，不像其他依赖视觉和音色效果来吸引玩家的游戏，本游戏会注重策略的技术细节。然后该框架提供了bookkeeping details使得设计者可以容易的开发某个游戏，同时减少编码方面的负担，然后这个Game System Framework会提供所有Gary’Games的所有核心，同时它会被作为一个有良好接口定义的库供广大游戏开发团队使用，这个框架基本功能是，定义和展现地板配置，定义军队和配置武器及其其他作战单元，能在地板上移动物件，判断合法的移动，构建战役，提供单元配置信息。

问题提出：

1 面对一个大问题，而且客户只给出上面的信息，我们应该怎么入手？

问题解决：

1 仅仅根据上面的信息，我们如果武断的进行需求分析和用例描述，是不明智的，相反，我们应该通过各种手段获得更多的信息，知道系统究竟是怎样的，通过和客户的交谈了解必要信息后才能写好需求。

问题提出：

1 那么我们应该怎样得到我们所需要的信息呢？

问题解决：

1 one way you can find out more about a system is to figure out what the system is like. In other words, are there some things that you do know about the system functions or behaves like? (这一点有点像我现在正在做的项目的解决思路)

Another great way to find out what a system should do is to figure out what it is not like. This help you determine what you do not need to worry about in your system.

有了上面的方法论后，我们应该好好的听听客户所说的。。。。。

有了一大堆信息后，我们应该figure out the features（所谓的feature是对系统应该，能，做的进行高度概括，而且在大型项目中，从feature开始会比较好，这样不会一开始就陷入了细节，从一个feature中我们可以得到多个requirement）

The main thing is that if you are stuck on where to get started, especially with a big project, you can gather features to get a handle on the high-level things you know you will need to take care of in the system you are building.

问题提出：

1 得到requirement之后，或许我们可以开始着手写use case了

问题解决：

1 就目前而言，我们不能太过注重细节，而use case又是在细节层面上的过程，我们应该继续figure out what the framework actually is先，就是要有big picture point of view。

使用use case diagrams！使用用例图

用例图可以让我们清楚知道我们的系统应该做什么。而且针对现阶段的目标---big picture，使用用例图是很适合的。（it does help you keep your eye on the fundamental things that your system must do）之后根据feature或者requirement来添加用例图的元素，经过对feature或者requirement的一系列的分析后（注意当前目标是big picture），我们得到

问题提出：

完成了系统功能性概括后，我们应该对系统进行模块划分，分而治之

问题解决：

这个框架可以分为Units，Board，Game, Utilities，Controller，Graphics模块（这里的模块划分比较困难，需要分析得比较好。）

Important Point：

1 The best way to look at a big program is to see it as lots of individual pieces of functionality. You can apply things you know to solve these individual problems

2 前面已经学过的知识

（1） 把多变的部分封装起来，使得系统更容易改变， 同时封装也可以将系统分成不同的功能块

（2） 要对接口进行编码而不是已经具体化的某个对象，这一就可以减少对象间，代码间的依赖性，使得系统更松散耦合

（3） 好的分析就是能指出系统应该完成什么功能，这样分析了小部分功能后也很容易将他们combine

（4） 分析可以帮助我们系统在真实世界正确运行，先分析各个部分，再分析他们中间的交互

（5） 好的软件应该容易改变和拓展，而且最重要的是他能满足客户需求。

3 Get features from the customer, and then figure out the requirements you need to implement those features.

4 use cases do not always help you see the big picture.(user case 一般都涉及到很多的系统细节，急于进行use case的编写，会使得你lose sight of the big picture)

5 use a feature or requirement list to capture the big thing that your system needs to do

6 domain analysis: the process of identifying, collecting, organizing, and representing the relevant information of a domain,

7

8 the best way to look at a big problem is to view it as a collection of smaller problems

小结：整个big problem的解决过程其实都有一种方法论在里面指导，和RUP的迭代有比较大的不同，基本上属于瀑布式开发模式，读者要明白这一点，才不会深深的陷入瀑布式开发里面。本章比较好的地方是介绍了对系统的轮廓的大致描述的过程，可以参考。