《软件方法》阅读笔记（三）
对于业务建模，有一个案例----参加公开课；
“参加公开课”用例的业务序列：
1、参加公开课----发布消息<公司助理决定公开课事宜，技术专家查看日程，决定合适的时间和课程，记录日程，通知助理，助理制作网页使用Dreamweaver，公司助理把网页上传到Cuteftp，查看所有联系人，挑选待通知联系人，通知联系人，发邮件>
2、参加公开课----准备上课设施<公司助理选择合适的会议室，租会议室，汇会议室租金，汇款给银行，为讲师定差旅，定机票车票，定酒店>
3、参加公开课----报名<开发人员回答公开课事宜，公司助理接电话，开发人员办理报名，公司助理收邮件、合并报名信息、编辑文档、报名反馈、恢复邮件、开发人员接收汇款凭据，公司助理收传真、收邮件、检查汇款凭据、制作听课证、编辑文档、打印文档、Word转换为PDF，公司助理发听课证、回复邮件>
4、参加公开课----准备上课材料<准备上课材料，公司助理统计待开发票、书写发票、制作签到表、编辑文档、打印文档、制作座位号签、编辑文档、打印文档、打印练习题、打印文档、接收上课所需材料，技术专家检查材料齐全>
5、参加公开课----上课<办理签到（听课证），现场助理查对名单、判断有无发票、请求签到和签发票、指引座位>
交互概述图：参加公开课
发布消息→准备上课设施→报名→准备上课材料→换购发票（发票用完）|→购买耗材（耗材用完）→上课
如果通过进一步信息化来改进现状，应该会给现状带来什么样的改进？“进一步信息化”不一定需要引进一个全新的系统，也可以通过修改现有系统的责任达到。所有的系统都是在遗留系统基础上改进得到，最早的遗留系统是人肉系统。
改进一：物流变成信息流
改进二：改善信息流转
改进三：封装领域逻辑
阿布思考法需找改进的思路是：
（1）假设有充足的资源去解决问题，得到一个完美的方案；
（2）用手上现有的资源去山寨这个完美方案；
需求指系统用例图
系统执行者的定义：在所研究系统外，与该系统发生功能性交互的其他系统；
1、系统外：系统执行者不是所研究系统的一部分，是该系统边界外的一个系统，这个系统边界不是物理的边界，而是责任的边界；
2、交互：系统执行者必须和系统有交互，不和系统交互的不算是系统的执行者；
3、功能性交互：执行者和系统发生的交互是系统的功能需求；
4、系统：系统可以是一个人肉系统，也可以是一个非人智能系统，甚至是一个特别的外系统-----时间
用例技术使用“执行者”和“涉众”代替了原来的“用户”，从而把演员和观众分开了。演员（执行者）在台上表演，观众（涉众）在台下看，演员表演什么是由观众的品味决定的，演员可以不是人，但是观众是人。“用户”这个词混淆了演员和观众的界限。
识别系统执行者，以前的做法是头脑风暴，想一想谁使用系统来工作？谁维护系统？系统需要和哪些其他智能系统交互？有没有时间引发的事件？但是有了前面的业务建模，就不需要头脑风暴了，直接从业务序列图中映射即可。
系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。用例可以看作执行者和系统之间买卖的平衡点。
思考用例的过程就是发现价值的过程。
开发人员最常犯的错误就是：把步骤当做用例；另一个经常碰到的问题是CRUD问题（做需求的目的不是为了安慰自己或走过场，而是让产品更加好卖。不以这个为出发点的需求工作是没有意义的。及时再难，也只能从涉众的视角来定义需求，不能贪图方便选择一个自己熟悉的视角应付了事。做好业务建模，尽量从业务序列图中映射出系统用例）。
软件工程更接近于经济学，而非计算机科学。
业务序列图中，从外部指向所研究系统的消息，可以映射为该系统的用例，在用例图中，有的箭头是从执行者指向用例，这样的执行者称为用例的主执行者，有的箭头从用例指向执行者，这样的执行者称为用例的辅执行者。主执行者主动发起用例的交互，辅执行者在交互的过程中被动参与进来；