本文转自：http://www.cnblogs.com/netfocus/archive/2011/09/18/2180656.html
先分享一下我的面向对象分析方法
- 找出最关键的一些业务场景；一般通过动词来寻找，比如招聘系统中，一个应聘人投递一个职位就是一次应聘，应聘就是一个业务场景；一个学生参加某门课的考试，那么考试就是一个业务场景；一个学生去图书馆借书，那么借书就是一个业务场景；
- 针对每个业务场景分析出有哪些场景参与者，哪些参与者以对象的形式参与，哪些参与者以服务的形式参与；为什么要区分对象还是服务是因为有时候我们不关心参与者是哪个，而只关心参与者是什么。一般服务在系统中我们只关心它是什么服务，并且在系统中服务一般也只有一个实例；而对象则不同，我们会关心对象是谁，即哪一个；
- 分析每个场景参与者对象的基本状态特征；所谓的基本状态特征是指对象与生俱来的，对象从一开始被创建出来之后就具有的状态特征；最形象的例子就是人的身高体重，当人一出生便具有了身高和体重这两个状态特征；再比如一篇博文，它从被写好之时起就具有了内容这个状态特征，但是我们可以随便修改博文的内容；但是有些状态特征是不能修改的，比如博文的创建时间一旦博文被创建之后便不能再被修改；需要注意的是我们不要把和对象关联的一些关联信息也认为是对象的基本状态特征。比如某人有一本英语六级考试证书，那么人和证书之间的关系是拥有的关系，证书不是人固有的与生俱来的基本状态特征，而是人参与了某次考试这个场景后得来的；后面我会提到这种关联关系该如何去思考和理解！
- 分析每个场景参与者对象分别扮演什么角色参与场景，整个场景的完整交互过程是怎样的，对象在参与场景的过程中执行了哪些交互行为； 相信大家都明白这点非常重要，因为它涉及到对象之间如何交互，涉及到该如何分析哪个对象该具有哪个交互职责；从而最终决定了在代码级别哪个类该具有哪些方法的问题。关于这方面思考的例子我会在下面进行介绍，这里先说一下理论吧。我觉得要点是将整个业务场景中的每个交互行为通过四色原型的分析方法来理解。用一句话来概括四色原型就是：一个什么什么样的人或组织或物品以某种角色在某个时刻或某段时间内参与某个活动。另外一个技巧就是，我们经常可以问自己，这个交互行为是“谁通知谁做什么事情？“，行为的驱动者是谁？行为的执行者是谁？一般行为的驱动者就是通知方，行为的执行者就是被通知方，被通知方拥有”通知方要求做的事情“执行行为；另外，我觉得还需要说明的是，现实生活中的对象并不是说其扮演了某个角色后才具有角色所定义的行为的，而是本来就有的，只不过是在扮演角色后表现出了该行为；所以对于现实生活中的对象，执行角色所定义的行为和扮演角色是同时发生的，没有谁先谁后的说法；但是软件中的对象则不同，因为软件中的对象只是现实生活中的对象的某一个我们所关心的方面，所以它的能力也有限。另外从设计实现的角度职责单一的角度来说，我们也不会将软件中的对象设计的很复杂，包含很多职责，因为这样会导致对象难以维护，这样做虽不违背分析原则，但违背设计原则。软件中的对象我们往往是设计成当它扮演某个角色时，动态给对象注入角色所定义的交互行为，从而给对象赋予了参与场景交互的能力。因此简单的说，软件中的对象，平时只具有基本的状态特征和基本的非交互行为，而当它扮演某个角色时，则动态具有交互行为；
- 分析交互过程结束后分别会对每个场景参与者对象产生哪些基本状态特征的改变；这个很好理解，当一个对象参与了某个交互活动后，一些基本状态特征会发生改变，比如一个人参加一次100米跑步比赛后，心跳速度会加快；心跳速度就是人的基本体征；这个应该很好理解吧，不多举例了。
- 分析如何记录和跟踪这一次交互行为，分析这次交互行为会产生哪些额外的信息；这点估计大家平时很少思考，而这点我想也正是我的面向对象分析思路最具特色的地方吧！大家一定知道，一次对象的交互活动会产生一些与该交互活动相关的交互信息。比如一次应聘活动会产生一些与该活动相关的信息，如是否录取，笔试成绩，面试成绩等；比如一次考试会产生考试成绩这个信息；一次借书会产生一个借阅信息（包含：借书人、被借的书、借书时间，我们可能还会设计一个还书时间）；并且，在很多情况下，这些交互信息会在后续的其他交互场景中再被更新。比如，一次应聘一开始状态可能是”新投递“，表示应聘人刚刚投了简历并选了某个职位，后来她去参加笔试或面试了，那么这次应聘的状态就变为了”已笔试“或”已面试“；在比如一个学生参加一次考试，刚开始还没有成绩，但后来老师批卷子后便有了考试成绩。再比如一次借书后，如果这本书还没被还，则还书时间为空，而一旦还书了之后，便有了还书时间；因此，我们从这些规律中可以发现，交互其实是一个过程，并且该过程一旦开始后就会产生一些相关的信息，如应聘的状态，考试的成绩，借阅信息的归还时间，等等。通常我们会把交互过程本身所涉及的一切信息以及交互过程所产生的所有附加信息作为一个整体来进行考虑。所以，我觉得我们有必要设计一个对象，用来表示某一次交互的结果，这个结果包含交互过程本身所涉及的一切信息以及交互过程所产生的所有附加信息；大家想想，看到”应聘“这个单词，你有时候会认为它是一个动词，优势后会认为它是一个名词。在认为是动词时，我们关注的是交互本身，活动本身，强调行为；而在认为是名词时，我们关注的是应聘行为所产生的一切信息；所以，看到这里，我想大家应该心里有个数了，就是在交互行为结束后，我们往往需要设计一个对象用来表示一次交互活动的相关信息；这些信息一方面体现了交互活动的参与者，（交互时间，交互地点，如果我们关心这些的话），另一方面体现了交互活动所产生的附加的信息，如成绩，应聘状态，借书还书时间，等等。最后，需要强调的是这些信息之所以设计为对象是因为这些信息不是历史，即不是不可改变的，相反，这些信息会在后续的其他交互活动中被更新；所以，看到这里，我想我们就不用在纠结对象在参加交互活动后所产生的一些与它关联的信息该如何存放这个问题了。
好了，上面就是我所掌握的面向对象分析思路。下面以图书借阅系统（点击这里下载源代码）为例，按照上面的分析方法进行分析。
案例分析：图书管理系统需求用例场景描述
图书信息入库场景
图书馆管理员扫描不同名称的书本。大家都知道每本具体的书都有一个ISBN，即International Standard Book Number，国际标注书号。图书馆是根据ISBN来管理书本的，同一个ISBN的书会有很多不同的副本，每一个副本就是一本实实在在的书。所以，严格的说图书馆数据库中保存的是“书本的库存信息”。在图书入库的场景中，只要是ISBN相同，即书名相同的书只会被扫描一次，然后管理员会输入这种书总共有多少本，应该放在什么地方等库存信息。当然这只是我自己理解的业务场景，姑且不论对错，咱们就先当这个理解是正确的吧。
借书场景
- 借书人持图书卡去图书馆，先找到几本要借的书，然后跑到借书处借书；
- 图书管理员扫描借书人的借书卡以及书本的条形码，条形码就是ISBN；
- 借书人拿着书从图书馆离开；
还书场景
- 借书人吃图书卡去图书馆，到还书处还书；
- 图书管理员扫描还书人的借书卡以及书本的条形码，如果有需要罚款的，也在此时会计算出来；
- 还书人离开图书馆；
结合面向对象分析思路和需求用例场景进行分析
图书入库场景的分析
场景参与者
图书馆、书本；其中图书馆在整个图书借阅系统中只需要一个实例，我们也不关心是这个图书馆还是那个图书馆，所以我觉得可以把图书馆设计为一个服务。
参与者基本状态特征
书本的基本状态特征：如书名、作者、出版社等信息；
图书馆的基本状态特征：没有，一般情况下服务是无状态的，服务只提供服务行为；
场景交互过程分析
很容易理解，图书馆本身就具有图书入库的行为。图书入库时，图书馆服务会生成并保存一个书本的“库存信息”，该信息包含了某个名称的书本的数量、书架位置信息。该库存信息中的Count表示某个名称的书有几本。当在借书或还书的场景发生时，这个Count就会改变； 代码示例如下：
图书入库场景类的实现：
public class StoreBookContext
{
private ILibraryService library = null;
private Book book = null;
public StoreBookContext(ILibraryService library, Book book)
{
this.library = library;
this.book = book;
}
public void Interaction(int count, string location)
{
library.StoreBook(book, count, location);
}
}
图书馆图书入库的方法：
public void StoreBook(Book book, int count, string location)
{
//图书入库时生成图书的库存信息
var bookStoreInfo = new BookStoreInfo(book, count);
bookStoreInfo.Location = location;
bookStoreInfoRepository.Add(bookStoreInfo);
}
最后，交互之后，场景参与者的基本状态特征是否发生变化？都没有发生变化。
借书场景分析
场景参与者
图书馆注册帐号、图书馆、书本；图书馆是一个服务、书本也只是一本普通的书，它没有行为，它是被借的。需要着重分析的是图书馆注册帐号这个参与者。先说一下我对：软件使用者（即软件的用户）、注册帐号、图书卡、借书人这四个概念的理解。理解这些概念非常重要！首先，软件使用者就是软件的用户，就是我们平时所说的用户，这点没什么问题。图书卡和注册帐号的关系是什么？我们都知道现实生活中，人持图书卡去借书；而软件中，人通过其注册帐号登录，然后以该注册帐号所代表的“人”做事情；因此，图书卡是用户用来借书的工具；同样注册帐号也是软件用户通过软件进行借书的工具；用户拥有图书卡，用户拥有注册帐号。那么借书人如何理解呢？我们平时所说的借书人其实就是一种角色，即用户在通过借书卡参与借书的行为过程中，我们把正在执行该行为或已经执行了该行为的人叫做借书人。用更通用的表达方式就是，我们通常会给正在做某件事情或已经做了某件事情的参与者一个称谓，如凶手、借书人、还书人、应聘人，等等；所以，有了这些理解之后，我们就知道借书人只是一个角色，某个注册帐号扮演了借书人这个角色后可以行驶借书的行为；
参与者基本状态特征
书本的基本状态特征：如书名、作者、出版社等信息；
图书馆的基本状态特征：没有，一般情况下服务是无状态的，服务只提供服务行为；
注册帐号的基本状态：图书馆注册帐号有基本的状态特征，比如：卡号，所有者姓名，是否锁定，等等；
场景交互过程分析
某个软件的使用者，即软件用户通过某个已注册帐号登录软件系统，然后选择了几本想借的书之后点击“借书”按钮，然后该按钮触发一个借书的场景，该场景创建时包含了部分的场景参与者，在借书这个例子中就是帐号和书，然后借书场景知道帐号应该扮演借书者这个角色。所以帐号在扮演了借书者这个角色后对每一本书行驶借书的交互行为。扮演了借书者角色的注册帐号自动具有了借书的行为，在该行为的内部实现中，通知图书馆把书借出来。随后图书馆接到通知后，首先根据当前书本获取书本的库存信息，如果当前库存信息是0本，说明这本书没有库存，就抛出异常通知软件使用者这本书目前已经被借光了。如果还有库存，则先更新库存信息，比如图书的数量减1，然后根据当前借书人，书本，以及当前时间生成一个借书信息对象，该对象还会包含一个图书归还时间的附加信息。最后将该借书信息对象保存起来。代码示例如下：
借书场景类的实现：
public class BorrowBooksContext
{
private LibraryAccount account = null;
private IEnumerable<Book> books = null;
public BorrowBooksContext(LibraryAccount account, IEnumerable<Book> books)
{
this.account = account;
this.books = books;
}
public void Interaction()
{
var borrower = account.ActAs<IBorrower>();
foreach (var book in books)
{
borrower.BorrowBook(book);
}
}
}
借阅者的借书方法：
public void BorrowBook(Book book)
{
//通知图书馆把书借给我
library.LendBook(book, this);
}
图书馆借出书的方法：
public void LendBook(Book book, IBorrower borrower)
{
//更新书本在图书馆的库存信息，如：数量信息、所在书架位置信息
var bookStoreInfo = bookStoreInfoRepository.GetBookStoreInfo(book.Id);
if (bookStoreInfo.Count == 0)
{
throw new Exception(string.Format("The count of book ‘{0}‘ in library is zero, so you cannot borrow it.", book.BookName));
}
bookStoreInfo.DecreaseCount(); //数量减1
bookStoreInfo.Location = null; //位置清空
//生成借书信息并保存到Repository中
borrowInfoRepository.Add(new BorrowInfo(book, borrower, DateTime.Now));
}
最后，交互之后，场景参与者的基本状态特征是否发生变化？都没有发生变化。
还书场景分析
有了借书场景的分析，那么还书场景也很容易分析了，主要的过程是：注册帐号扮演借阅者角色执行还书行为，执行过过程中通知图书馆接收某本要归还的书，图书馆接到通知后首先调出与该书本对应的那一次借书信息，然后更新其还书时间，最后更新图书的库存信息。另外的基本和借书类似了，相信大家一看代码都应该明白了，直接上代码吧！
还书场景类：
public class ReturnBooksContext
{
private LibraryAccount account = null;
private IEnumerable<Book> books = null;
public ReturnBooksContext(LibraryAccount account, IEnumerable<Book> books)
{
this.account = account;
this.books = books;
}
public void Interaction()
{
var returnner = account.ActAs<IBorrower>();
foreach (var book in books)
{
returnner.ReturnBook(book);
}
}
}
借书者的还书方法：
public void ReturnBook(Book book)
{
//通知图书馆接收我要归还的书
library.ReceiveReturnedBook(book, this);
}
图书馆接收被还的书的方法：
public void ReceiveReturnedBook(Book book, IBorrower borrower)
{
//设置借书信息的还书时间
var borrowedInfo = borrowInfoRepository.FindNotReturnedBorrowInfo(borrower.Id, book.Id);
borrowedInfo.ReturnTime = DateTime.Now;
//这里，真正的系统还会计算归还时间是否超期，计算罚款之类的逻辑，因为我这个是一个演示的例子，所以不做这个处理了
//这里只更新书本的数量信息，因为还书时并不是马上把书本放回书架的，所以此时书本的书架位置信息还是保留为空
//等到我们将这本书放到书架的某个位置时，才会更新其位置信息
var bookStoreInfo = bookStoreInfoRepository.GetBookStoreInfo(book.Id);
bookStoreInfo.IncreaseCount(); //数量加1
}
好了，差不多就这样吧，从整理思考到文章写作完成，花了我不少心思和时间那，希望大家都能看明白！另外一个题外话，大家在看我的源代码时，不要过分注重我的框架实现，而应该注重这种面向对象的分析思路，框架是偏设计的，是用来为了更方便的支持由这种分析思路而产生的代码实现。我想你懂的，呵呵！
原文地址：https://www.cnblogs.com/DreamRecorder/p/8966389.html