从分析客户需求到总体设计

从分析客户需求到总体设计

 

 1、问题分析：问题分析最好在群组环境中进行，让不同的人来分析同一种需求，让领域专家和需求的客户来参与讨论也是必要的。尽量减少多重需求，并把中的需求抽取到较小的部分。避免在分析时从事设计的诱惑。积极跟踪客户来避免需求的蔓延。

 

2、用例建模：参与者（代表独一无二的系统用户）和用例（系统参与者说执行的一系列操作步骤，包含一个和主要事件序列，还包含其他一个或多个可选事件序列）。需求两种形式：功能性和非功能性需求（如可用性和性能之类的并且很难应用用例建模）

 

3、标识参与者：在阅读工程项目描述或收集项目需求时，可以问问自己几个重要的问题：谁将使用该功能？谁提供或获取信息？谁可以改变信息？是否有的别的一些系统同正在开发的一些系统进行交互？最后通过筛选得到最终的参与者个数。以在线银行交易系统为例，参与者可以是：客户、管理人员、供应商、邮件系统、LoadsDirect系统、BillsDirect系统。

 

4、用例查找：站在参与者（系统用户）的视角和请求，来捕获系统执行的事件序列。

   以银行交易系统的资金转账过程为例：

   （1）客户申请资金转账  >> (2)系统要求确定在哪两个账户间进行转账,转账金额是多少  >>（3）客户选择资金转入 OR 转出账户，并指明要转账的金额 >> (4)系统检查资金转出账户，以核实该账户上是否有足够转账资金（可选事件） >>(5)将转账金额分别借记转出账户，贷记转入账户。

   查找用例的简单方法：考虑您标识的每一位参与者，在兼顾系统需求的前提下，尽量为其标识出参与者的行为信息。然后以参与者做为起始点，产生用例列表作为候选：

    登录、注销（不满足用例条件，没有产生一些值给客户）、更改密码、查看账户余额、交易列表、下载交易、资金转账、编辑图表、添加供应商、删除供应商、付账、检查证券账户余额、浏览证券、买证券、卖证券。（每一种用例都必须产生一种显而易见的结果，最后根据此规则进行简化用例）

 

5、用例图：

   
    用例关系：

    “包含”和“扩展”关系，可用于诸如在用例中重用的建模。

    （1）“包含”允许您在独立的用例中捕获通用的功能段，然后通过包含关系在另一个用例中包含该用例，它显示为一种依赖的关系。用<<include>> 标记表示。

  
    （2）“扩展”允许您为用例的任选行为建模，也可以在一个独立的用例中捕获某些行为，并在另一个用例中指出精确的扩展点。通过这些点也许能把那个独立的用例作为该用例的一部分任意调用。用<<extend>>标记。

以下是银行在线交易系统关于资金转账的用例图：

6、顺序图：交互关系图的一种，强调交互发生的时间顺序。按照参与者与系统的交互关系来描述用例。顺序图用于捕获每一种用例的主要流程，乃至每一个交替变换的流程。

7、活动图：更容易地显示参与者的决定和系统异常所要执行的多条路径。顺序图倾向于显示单一方案环境中对象之间的交互关系。在概念上与流程图很相似，用它来为工作流程建模，以及用来图解用例的动态行为和操作的详细设计是很有用的。

8、用例实现：被用于为相同的一组需求设计多重实现方案.

在线银行系统中可以作为两种不同产品提供给客户：一种应用是真正拨号接入银行系统；另一种是使用Internet的基于Web的应用。这两种解决方案功能需求是相同的，但他们实现起来却有着巨大的差别。

9、精化用例描述：

从用户的观点来看以上用例设计也许已经足够了，但是对开发者实现系统来讲当然是不够的。在用例分析阶段，应该将用例的细节部分体现的更精确。如下面银行转账用例的更详细版本的顺序图：

 

10、细化的顺序图：

   一旦将灰盒细节添加到用例的文本描述中后，就可以创建用于显示系统内部工作的更加细化的顺序图了。不再只是显示参与者与系统整体间的交互关系，而是把系统分割成分析级对象。

   三种分析对象，每一种在精化的系统模型中执行一种特定的作用：（1）边界对象（系统周边，与外部系统进行交互，每一个用例/参与者关系就是一个潜在的边界对象<<boundary>>）、（2）实体对象（表示对系统的持久化的重要信息并能在一个延续的时期内存在，主要作用在于表示和管理系统内的信息，一个用例或系统中会存在大量实体对象<<entity>>）、（3）控制对象（用于系统内的模型行为，不必实现行为，但可以与其他对象协作来完成用例的行为。实际上是过渡性的，一旦用例完成就消失<<control>>）

  注意三种分析对象：边界对象（转账页面）、实体对象（账户、客户信息、交易登记）和控制对象（转账资金）的图标表示法：

  

用于资金转账的精化的顺序图：

  

11、协作图：另一种类型的对象交互图（起辅助手段）。与顺序图关注的交互作用的时间顺序不同，协作图强调的是显示参与者之间的关系和通信连接。

12、类图：可以被开发成用于捕获参与实现用例的不同元素之间的静态关系。VOPC图的目的：在一个简单的图中，用图说明系统体系结构的各个方面，它是通过一个特定的用例来实现的。分析级交互作用图中的每一条独特的消息与分析操作（用于表示分配给类的职责）之间是一一映射关系。

13、聚合分析类：标识类为中心，这些类可能跨越用例被复写，应该对这些类进行合并（如具有相同行为或表示相同概念的类就应该被合并，具有相同属性的实体类也应该被合并，并且把它们的行为组合为一个单独的类）。

14、打包：可以让您把类和相关类分组到独立的包中，从而来安排复杂的任务。包为管理复杂的项目和团队工作的分配提供了一个便利的机制。在UML中，文件夹图标表示一个包。包可以包含模型元素，如类和接口，也可以嵌套。包与包之间也存在依赖关系。通过依赖性分析可以理解项目中的变化说造成的影响。（应该把所有的依赖性关系的箭头都指向同一个方向）

出处：从分析客户需求到总体设计