《软件方法》阅读笔记(三)

《软件方法》阅读笔记(三)

对于业务建模,有一个案例----参加公开课;

“参加公开课”用例的业务序列:

1、参加公开课----发布消息<公司助理决定公开课事宜,技术专家查看日程,决定合适的时间和课程,记录日程,通知助理,助理制作网页使用Dreamweaver,公司助理把网页上传到Cuteftp,查看所有联系人,挑选待通知联系人,通知联系人,发邮件>

2、参加公开课----准备上课设施<公司助理选择合适的会议室,租会议室,汇会议室租金,汇款给银行,为讲师定差旅,定机票车票,定酒店>

3、参加公开课----报名<开发人员回答公开课事宜,公司助理接电话,开发人员办理报名,公司助理收邮件、合并报名信息、编辑文档、报名反馈、恢复邮件、开发人员接收汇款凭据,公司助理收传真、收邮件、检查汇款凭据、制作听课证、编辑文档、打印文档、Word转换为PDF,公司助理发听课证、回复邮件>

4、参加公开课----准备上课材料<准备上课材料,公司助理统计待开发票、书写发票、制作签到表、编辑文档、打印文档、制作座位号签、编辑文档、打印文档、打印练习题、打印文档、接收上课所需材料,技术专家检查材料齐全>

5、参加公开课----上课<办理签到(听课证),现场助理查对名单、判断有无发票、请求签到和签发票、指引座位>

交互概述图:参加公开课

发布消息→准备上课设施→报名→准备上课材料→换购发票(发票用完)|→购买耗材(耗材用完)→上课

如果通过进一步信息化来改进现状,应该会给现状带来什么样的改进?“进一步信息化”不一定需要引进一个全新的系统,也可以通过修改现有系统的责任达到。所有的系统都是在遗留系统基础上改进得到,最早的遗留系统是人肉系统。

改进一:物流变成信息流

改进二:改善信息流转

改进三:封装领域逻辑

 

阿布思考法需找改进的思路是:

(1)假设有充足的资源去解决问题,得到一个完美的方案;

(2)用手上现有的资源去山寨这个完美方案;

需求指系统用例图

系统执行者的定义:在所研究系统外,与该系统发生功能性交互的其他系统;

1、系统外:系统执行者不是所研究系统的一部分,是该系统边界外的一个系统,这个系统边界不是物理的边界,而是责任的边界;

2、交互:系统执行者必须和系统有交互,不和系统交互的不算是系统的执行者;

3、功能性交互:执行者和系统发生的交互是系统的功能需求;

4、系统:系统可以是一个人肉系统,也可以是一个非人智能系统,甚至是一个特别的外系统-----时间

用例技术使用“执行者”和“涉众”代替了原来的“用户”,从而把演员和观众分开了。演员(执行者)在台上表演,观众(涉众)在台下看,演员表演什么是由观众的品味决定的,演员可以不是人,但是观众是人。“用户”这个词混淆了演员和观众的界限。

识别系统执行者,以前的做法是头脑风暴,想一想谁使用系统来工作?谁维护系统?系统需要和哪些其他智能系统交互?有没有时间引发的事件?但是有了前面的业务建模,就不需要头脑风暴了,直接从业务序列图中映射即可。

系统用例的定义:系统能够为执行者提供的、涉众可以接受的价值。用例可以看作执行者和系统之间买卖的平衡点。

思考用例的过程就是发现价值的过程。

开发人员最常犯的错误就是:把步骤当做用例;另一个经常碰到的问题是CRUD问题(做需求的目的不是为了安慰自己或走过场,而是让产品更加好卖。不以这个为出发点的需求工作是没有意义的。及时再难,也只能从涉众的视角来定义需求,不能贪图方便选择一个自己熟悉的视角应付了事。做好业务建模,尽量从业务序列图中映射出系统用例)。

软件工程更接近于经济学,而非计算机科学。

业务序列图中,从外部指向所研究系统的消息,可以映射为该系统的用例,在用例图中,有的箭头是从执行者指向用例,这样的执行者称为用例的主执行者,有的箭头从用例指向执行者,这样的执行者称为用例的辅执行者。主执行者主动发起用例的交互,辅执行者在交互的过程中被动参与进来;

你可能感兴趣的:(《软件方法》阅读笔记(三))