UML分析应用总结

一、获取需求

1、定义边界
边界可大可小，无法衡量，也无章可循，需要靠建模者的经验和意识。
定义边界的目的是为我们确定一个分析的起点，界定义的不同会带来不同的结果，因为视角会因边界而变动。
主角、边界、用例三者是相生相灭的关系，其中边界定义最为重要，一旦定义了边界，主角就能定义，
而一旦定义了主角，用例就能发现。

2、发现主角
主角代表了涉众利益，站在边界之外，直接与边界代表的系统交互，对系统有着明确的要求并从系统获得明确的结果。

3、获取业务用例
对系统来说，每一件事情便是一个业务用例，每个业务用例都体现了业务主角的一个系统期望，
而所有这些期望则完成边界所代表的业务目标。

4、业务建模
一个完整的业务模型包括以下一些内容：
（1）业务用例视图
（2）业务用例场景
（3）业务用例规约
（4）业务规则
（5）业务对象模型
（6）业务用例实现视图
（7）业务用例实现场景
（8） 包图

5、领域建模
领域就是我们分析问题时将整体分解以后的相对独立的部分。领域建模正是要发现表象下的本源，
找出那些最基本的对象以及它们之间的关系，并描绘出这些对象如何交互而形成了我们正在分析的问题领域。
建立领域模型需经过提出领域问题、分析领域问题、建立领域模型和检验领域模型这些步骤。

6、提练业务规则
全局规则 ：指那些对于系统大部分业务或系统设计都起约束作用的那些规则。
    全局规则与具体用例无关，它实际是系统应该具备的特性，把这些规则分出来的目的就是为了让系统去负责这些特性

    的实现。 对于架构师来说应关注全局规则。
交互规则 ：不论是活动、状态还是业务对象，它们在活动转移、状态变迁和对象交互时必然会有一些限制性的条件。

  这些条件就是交互规则。它是在用例场景中产生的，规定了满足什么条件后业务将如何反应。对于设计师来说应关注交互 规则。
内禀规则 ：指那些业务对象本身具备的，并且不因为外部的交互而变化的规则。对于程序员来说应关注内禀规则。

7、获取非功能性需求
（1）可靠性（安全性、事务性、稳定性）
（2）可用性
（3）有效性（性能、可伸缩性、可扩展性）
（4）可移植性

二、    需求分析

1、建立概念模型
概念模型是针对需求中的关键业务，或者说业务核心来建立的，是由需求转入系统之间的桥梁，
应当由需求人员、系统分析人员、软件架构人员和系统设计人员共同参与。

2、建立业务架构
业务架构就是对需求细致分析和深刻理解的基础上，抽象出若干相对独立的业务模块，形成自洽的业务构件。
这些业务构件对内可以完成一个或一组特定的业务功能，对外则有着完善的接口，
可以与其他业务构件共同组成更为复杂的业务功能，直至构成整个系统的完整业务功能。
建立业务架构在结构化设计方法中，得到的结果是子系统、模块;在面向对象的设计方法中，得到的结果则是业务构件。
ERP软件产品SAP把业务做到了极致，它已经建立起了那些可以搭建业务平台的积木。再复杂和迥异的需求，都可以用这些积木搭建出来，而这些积木就是业务架构。

3、开发系统原型
系统原型按用途不同分为以下几种：
（1）验证型原型 ：验证技术可形性，以掌握关键的技术难点并证明我们能够使用这些技术或完成这些新的需求。
（2）探索型原型 ：探索初步的设想是否可行以及往下走可以走多远。
（3）辅助原型 ：向客户说明某个产品或概念,为了形象化演示,让客户有直观的认识,以显示的方式向客户展示以加深理解。
系统原型按目的不同分为以下二种：
（1）抛弃型系统原型 ：当原型的目的达到后，原型的使命也就结束了。
（2）渐进形原型 ：开发原型时，考虑将来要在它的基础上逐步完善，乃至形成最终系统。

三、 系统分析

1、确定系统用例
可通过映射、抽象、合并、拆分、演绎等确定系统用例的基本方法从业务用例场景中抽象出备选的系统用例。
描述系统用例的过程也就是系统建模的过程，系统建模与业务建模方法如出一辙，
模型的内容可参照业务建模的模型内容， 业务建模描述的是原来的业务什么样子，工作人员怎样完成任务，
系统建模描述的计算机怎么做，工作人员怎么操作计算机。

2、分析业务规则
要进行业务规则分析，前提是在获取需求时就将业务规则（含全局、交互、内禀规则）提练出来,并且以文档的形式进行管理。

程序员在编写业务规则时不要将规则逻辑代码混在业务处理代码中，
可设计复杂的业务规则管理库程序，包含决策表、决策树、甚至使用脚本语言编译器，建立业务规则引擎。

3、用例实现
用例实现的目的就是实现系统需求，要为实现用例建模，需要经过以下三个步骤：
（1）在用例场景当中发现和定义实体对象。
（2）用控制对象来操作和处理实体对象当中的数据。
（3）用边界对象来构建接收外部指令的界面。

用边界对象、控制对象和实体对象实现场景后，我们就得到了分析类图。分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。
分析类的抽象层次高于设计实现，高于语言实现，也高于实现方式。
高于设计实现 意味着，在为需求考虑系统实现的时候，可以不理会复杂的设计要求，
  比如设计模式的应用、框架规范的要求等，而专心地为从需求到实现搭建一座桥梁。
高于语言实现 意味着，在为需求考虑系统实现的时候，可以不理会采用哪一种语言来编写代码，
 也就可以排除特定语言的语法、程序结构、编程风格和语言限制等杂音，专注在需求实现上。
高于实现方式 意味着，在为需求考虑系统实现的时候，可以不考虑采用哪一种具体的实现方式，例如安全认证。

4、软件架构和框架
软件架构是一种思想，一个系统蓝图，对软件结构组成的规则和职责设定。大部分的软件架构是由一个设计思想，
加上若干设计模式，再规定一系列的接口规范、传输协议、实现标准等文档构成的。一般用包图来描述软件架构。
软件框架是软件架构的一种实现，是一个半成品。它通常针对一个软件架构当中某个特定问题提供解决方案和辅助工具。
选择软件架构和软件框架的理由不是技术先进，而是符合业务需要。

5、分析模型
在建立领域模型时，我们使用分析模型来获得针对某一个问题领域的系统视角理解;
在建立概念模型时，我们使用分析模型来获得针对核心业务的系统视角理解;
在建立用例实现模型时，我们使用分析模型来获得针对系统需求的系统视角理解。
分析模型是项目当中分析阶段所使用的工具。优化分析模型时应关注以下几个关键点：
（1）容易变化的需求需要给予关注，考虑优化分析模型，让其带有一定的可扩展能力。
（2）结构化和藕合度调整，不好的结构是网状结构，对象之间相互依赖，好的结构是树状结构，
       对象之间的依赖是单向的，不交叉的。对于不好的结构应当优化其分析模型。
（3）交互集中点调整,若某一个对象的交互非常多，它依赖或关联到很多类，这个对象就是问题多发地带了，
      也就是通常所说的关键链、瓶颈等。优化的方法一般有重新规划职责、增加冗余对象、增加中间调合对象等方法。
重新规划职责 是指将一个类承担的过多职责分摊到几个新的类中以降低类的复杂程度。
增加冗余 是指将一个类与其他类之间过多的交互分摊到几个新的类中以减少每个类的交互数量。
增加中间调合对象 是指在一群交互很多或相互依赖复杂的类之间增加一个中间对象，
由中间对象来调节它们之间的交互以降低复杂程度。

6、组件模型
组件是用来容纳分析类或设计类的，可以把组件理解为一种特殊的“包”，只不过普通的类包只是将类组织在一起存放，
是一种物理结构。而组件不是一种物理结构，它逻辑地引用，使用某些类，这些类组织起来的目的不是为了存放，
而是为了完成一组特定的的功能。
建立组件模型的条件：
（１）如果所实施的项目需要将某部分业务功能单独抽取出来形成一个可复用的单元，在许多系统或子系统中使用时，可以建立组件模型。
（２）如果所实施的项目需要与其他现存系统或第三方系统集成，集成的接口部分应当建立组件模型。

在组件设计时，组件应当只包含服务的接口，同时只维护调用服务的实现方式。它应只有服务信息与服务实现的
绑定信息，而不应包含实现细节。
（１）组件是可复用的单元，可复用的能力来自它与实现细节的隔离。
（２）组件是可独立变化的单元，可独立变化的能力来自组件与服务实现细节的隔离。
（３）组件是可独立部署的单元，由于组件只包含服务接口和服务绑定，它可以脱离服务实现的运行环境而独立部署。
（４）组件可在软件架构支持环境下自由组装，要实现组件之间的松藕合关系，必须采用某种消息中间件来屏蔽组件
之间的依赖。例在IBM的SOA软件架构体系里，组件应当遵循SCA（服务组件架构）规范。

7、部署模型
部署模型又称为实施模型。它主要的作用就是定义构成应用程序的各个部分在物理结构上的安装和部署位置。
这个物理结构包括客户机、服务器、网络节点、移动设备等所有可能的程序逻辑处理设备和文件存放设备。
建立部署模型时，要从应用程序本身的需要和运行环境的要求两个方面来分析，

再结合两者的分析结果共同绘制部署模型图。
应用程序包含基础软件结构，软件架构，和外部接口等。运行环境包含安全环境，数据环境和外设等。

四、系统设计
系统设计和系统分析是有着显著差别的，主要有以下几方面：
（１）从工作任务上来说，分析做的是需求的计算机概念化，设计做的是计算机概念实例化。
（２）从抽象层次上来说，分析是高于实现语言、实现方式的;设计是基于特定的语言和实现方式的。
        分析的抽象层次高于设计的抽象层次。
（３）从角色上来说，分析是系统分析员承担的，设计是设计师承担的。
（４）从工作成果来说，分析的典型成果是分析模型和组件模型，设计的成果是设计类、程序包。

1、设计模型
设计模型可通过分析模型映射而来，如果系统中的许多功能具备相似的实现模式，则没有必要逐一地建立设计模型，
一个典型功能的设计模型就可以起到指导开发的作用。而对于复杂的、特殊的功能，则应当建立设计模型。

2、接口设计
面向对象给我们带来的一大好处是接口与实现的分离，这使得我们在考虑程序逻辑时可以完全不用考虑程序
将怎样编写，而只考虑对象交互的接口。
（１）为单个对象设计接口 ，极端一点来说，我们应当为每一个对象都设计接口，哪怕这个对象行为与其他任何
对象都不一样，完全没有抽象价值，甚至看不到将来变更的可能。每个接口对应一个实现类，
实现类习惯上以impl为后缀表示。
（２）为具有相似行为的对象设计接口 ，在一个系统里会有许多对象具有相同或相似的行为模式。通常，
这些对象都承担相同或相似的职责，即它们处理事情的办法都差不多，但处理的内容和具体过程可能不同，
可为这些对象设计接口。
（３）为软件各层次设计接口 ，在一个多层次的软件架构中，各层之间的交互是错综复杂的，
我们将软件按层次分开的目的就是为了使得各软件层职责清晰，各负其责。需为层次之间的交互过程设计良好的接口，
可以有基于行为模式和基于服务的两种接口抽象策略。
一种是将类的相同行为抽象成接口，可称之为基于行为模式的接口抽象策略。
另一种是将同一类业务处理抽象成接口，可以称之为基于服务的接口抽象策略。
还有一种基于使用方便目的的接口抽象策略，即使没有抽象价值，出于使用方便的目的，也可以抽象，
整理出一套方便使用的接口。

3、包设计
分包的目的除了将程序文件分类管理，最重要的就是要让软件组织有序并且职责清晰。
一般来说，分包应遵循以下原则：
（１）自顶向下原则 ：分包时要像组织机构一样，从顶级包自顶向下延伸，避免平行化无层次分包。
自顶向下原则的另一个重要含义是下层包不能够访问上层包，并且不能够跨层访问包，
但同层次的包可以相互访问，即只允许存在自顶向下不越层的依赖。
（２）职能集中原则 ：尽量将与一组业务功能有关的类分在同一个包里。
在软件世界里反映为子系统、模块、子模块、功能模块的划分。
（３）互不交叉原则 ：包与包之间的类尽量独立，不要让它们产生相互依赖关系。
    如果不可避免地要产生依赖关系，那也应当是树状依赖关系而不能是网状依赖关系。
分包原则应当遵循先应用自顶向下原则，再应用职能集中，最后应用互不交叉原则的顺序。
按照惯例，包名的命名规则一般为：组织类型（如com,org）+项目或产品名称+具体内容。
职能集中导致一项业务功能所需要的接口和实现类分散在众中的包里，为了完成一项业务功能我们需要
引入很多包并调用众多接口，除了使用不便之外，对编程者也会造成理解上的困难。可以考虑再设计一组接口将分散
的接口组合在一起向外提供服务，即面向服务的设计，SOA并不是定位于系统实现设计的，实际上它要做的事情是将
分散但职能集中的各个系统模块整合起来形成面向服务的一组接口，并通过SOA架构形成组件，向外提供服务。

五、开发

程序开发有二种基本的分工策略：纵向分工和横向分工。

1、纵向分工
纵向分工指的是一位开发人员负责将某项业务功能从软件架构层次的最高层一直实现到最底层的分工策略。
优点：
（1）软件过程过渡清晰自然
（2）有利于开发计划制定
（3）工作效率相对较高
缺点：
（１）不利于软件长期演进战略实施。
（２）培训成本较高
（３）对软件框架和规范的要求高

2、横向分工
横向分工是指，我们获得基于用例的工作量估算以后，并不是以用例为工作包进行计划编制和资源指派，
而是以软件架构层次为基础，重新估算每个软件架构层次上的工作量，并将开发资源指派到每个层次上去。
优点：
（１）适合于软件长期演进
（２）培训成本较小
（３）资源利用率较高
缺点：
（１）失去用例驱动的清晰性
（２）项目计划制定相对困难
（３）项止沟通压力大

六、 测试

评价功能测试是否达到了预期目标有两个基本指标：需求覆盖率和代码覆盖率。
需求覆盖率 ：指测试例所执行过的软件的使用场景占所有可能使用场景的百分比。
代码覆盖率 ：计算测试例所执行过的代码占所有代码的百分比。

在用例驱动的模式下，可通过以下7个步骤来从需求推导出测试例，主要如下：
（１）确定用例，确定测试范围的过程，要把哪些用例纳入到测试范围当中，并为之开发测试用例。
（２）确定用例场景，它是推导测试例的基本出发点，除了事件流描述之外，前置条件和后置条件都是重要的信息。
（３）确定执行路径，开发的测试要能够覆盖所有可能的测试路径。
（４）确定测试场景，以事件流编号作为横坐标，排列出所有可能的场景，并标定这些场景的优先级。
（５）确定测试因素，测试因素指在测试场景即执行路径确定的情况下，可能会影响和改变执行结果的那些因素。
         可分为三大类：用户输入、运行时设置和环境设置。
（６）开发测试矩阵，根据测试场景和影响测试的因素将两者分别按横纵坐标排列起来，就形成了测试矩阵。
       根据测试矩阵的有效组合确定测试的覆盖率。
（７） 开发和执行测试例，将测试矩阵中的每一个测试实例转化为可执行的测试例。