用例模型
组成
参与者
用例（取名：短小精悍的动名词，如“取钱”、“修改密码）
用例描述 （作为领域模型的输入、设计的输入、开发的输入…)
系统边界
系统顺序图
操作契约
参与者
位于系统外部并与系统进行交互的一类事物(人,物和其他子系统等)
参与者的三类
主要参与者:通过该系统来实现自己的需求如Pos系统的收费员
协助性参与者:提供支持如第三方接口,POS系统的信用卡支付的授权认证服务
幕后参与者:对系统功能感兴趣,但不是很强烈如POS系统的政府税收代理人员
用例
用例是一系列动作或处理,且能为参与者产生有价值的结果
用例描述的三种详细程度
简短格式:主事件流
随意的：写到哪是哪里
正式的: 按照指定格式来写
定义“合适“的用例
①用例是否描述了应该做什么，而不是如何做？
②用例的描述是否采取了参与者的视点？
③用例是否对参与者有价值？
④用例描述的时间流是否是一个完整场景？
⑤是否所有的参与者、用例都有相应的关联用例或关联参与者？
系统边界
用例描述
关注参与者的目标,描述事务的本质。与界面无关,与实现机制无关。
用词简洁
“黑盒”的用例描述:描述做什么功能,而不是该功能是怎么实现的。
从参与者及其目标的角度进行描述:询问他们的目标,典型场景,聚焦”产生有价值的结果”
示例
契约式设计
问题的引入
名词解释
客户,客户端:需要服务的一方
服务端,服务器:提供服务的一方
一份契约承载着客户端和服务端的义务
客户端:只有满足服务端的前置条件下,才能使用服务端提供的服务
服务端:服务端结果服务后,必须满足后置条件。
如顾客到商店买食品。必须是真钱，不是假币。食品必须卫生、安全、符合
质量要求
实现：断言
单个操作:每个功能定义一个前置条件和一个后置条件
类不变量:类的所有操作都需要遵守
操作契约
强调一些动作的开始的前置条件和结束的后置条件。
示例
描述后置条件的策略
instance creation and deletion
attribute modification
associations formed and broken
设计
软件架构
定义
组织类以形成模块,分成,子系统,命令空间等
设计方法:分层法
层:表示一定规模的结构元素,来完成特定功能。
注:在“分”的同时,也要考虑“合”
分层架构的优点
各层都容易被替换
较低层次包含更多的操作细节，容易成为可重用的构件
每层都容易分布部署与连接
分层时考虑的问题
服务是放在高层还是底层
服务是作为应用专门的，还是通用的
面向对象设计
面向对象设计的关注点
主要工作和业务逻辑相关，不关注用户界面和数据存储。
设计思想的来源
软件设计最新的概念
同学们要经常去关注，比如 www.csdn.net , 一些开源网站等
研习针对大规模/小规模问题的“最佳实践”解决方案
教材、论文记录的一些方法
在不同上下文中重用——不要从头开始设计解决方案
注设计还需要一点灵感
大规模系统设计遇到的问题
如何定义领域层对象与子系统之间的协作
如何定义UI对象到领域层对象之间的协作?
如何设计与实现“向上”的协作？
设计的总体思路
标识职责 responsibilities，并把它们分配给不同的类
1 职责描述是一种抽象，粒度大小不一
软件对象只有方法 methods，没有职责
从职责到对象方法的转换比如，“负责永久存储”，粒度太大，比如“负责计算税费” ，粒度要好一些
2 职责驱动的设计 RDD，对象设计时可以问这样的问题
这个对象有哪些职责？
这个对象与哪个对象协作？
如何分配职责
GRASP是很好的指导原则:通用的职责分配软件原则(模式）GRASP General Responsibility Assignment Software Principles（patterns）
