从分析客户需求到总体设计
2、用例建模:参与者(代表独一无二的系统用户)和用例(系统参与者说执行的一系列操作步骤,包含一个和主要事件序列,还包含其他一个或多个可选事件序列)。需求两种形式:功能性和非功能性需求(如可用性和性能之类的并且很难应用用例建模)
3、标识参与者:在阅读工程项目描述或收集项目需求时,可以问问自己几个重要的问题:谁将使用该功能?谁提供或获取信息?谁可以改变信息?是否有的别的一些系统同正在开发的一些系统进行交互?最后通过筛选得到最终的参与者个数。以在线银行交易系统为例,参与者可以是:客户、管理人员、供应商、邮件系统、LoadsDirect系统、BillsDirect系统。
4、用例查找:站在参与者(系统用户)的视角和请求,来捕获系统执行的事件序列。
5、用例图:
以下是银行在线交易系统关于资金转账的用例图:
6、顺序图:交互关系图的一种,强调交互发生的时间顺序。按照参与者与系统的交互关系来描述用例。顺序图用于捕获每一种用例的主要流程,乃至每一个交替变换的流程。
7、活动图:更容易地显示参与者的决定和系统异常所要执行的多条路径。顺序图倾向于显示单一方案环境中对象之间的交互关系。在概念上与流程图很相似,用它来为工作流程建模,以及用来图解用例的动态行为和操作的详细设计是很有用的。
在线银行系统中可以作为两种不同产品提供给客户:一种应用是真正拨号接入银行系统;另一种是使用Internet的基于Web的应用。这两种解决方案功能需求是相同的,但他们实现起来却有着巨大的差别。
9、精化用例描述:
从用户的观点来看以上用例设计也许已经足够了,但是对开发者实现系统来讲当然是不够的。在用例分析阶段,应该将用例的细节部分体现的更精确。如下面银行转账用例的更详细版本的顺序图:
10、细化的顺序图:
用于资金转账的精化的顺序图:
11、协作图:另一种类型的对象交互图(起辅助手段)。与顺序图关注的交互作用的时间顺序不同,协作图强调的是显示参与者之间的关系和通信连接。
12、类图:可以被开发成用于捕获参与实现用例的不同元素之间的静态关系。VOPC图的目的:在一个简单的图中,用图说明系统体系结构的各个方面,它是通过一个特定的用例来实现的。分析级交互作用图中的每一条独特的消息与分析操作(用于表示分配给类的职责)之间是一一映射关系。
13、聚合分析类:标识类为中心,这些类可能跨越用例被复写,应该对这些类进行合并(如具有相同行为或表示相同概念的类就应该被合并,具有相同属性的实体类也应该被合并,并且把它们的行为组合为一个单独的类)。
14、打包:可以让您把类和相关类分组到独立的包中,从而来安排复杂的任务。包为管理复杂的项目和团队工作的分配提供了一个便利的机制。在UML中,文件夹图标表示一个包。包可以包含模型元素,如类和接口,也可以嵌套。包与包之间也存在依赖关系。通过依赖性分析可以理解项目中的变化说造成的影响。(应该把所有的依赖性关系的箭头都指向同一个方向)
出处:从分析客户需求到总体设计