2 分析模型
分析是一个十分关键的过程，它是把需求转化为代码实现的中间阶段。软件分析是将自然语言表达的软件需求进一步进行解析的过程。软件设计就是从分析到软件实现的过程。
2.1 架构设计
1. 分层架构
架构设计决定了各子系统如何组织以及如何协调工作。架构设计的好坏影响到软件的好坏，系统越大越是这样。在分解复杂的软件系统时，经常使用的一种架构技术就是分层。分层架构中最困难的问题就是决定建立哪些层以及每层的职责。分层结构的好处主要有：不需要去了解层的实现细节；可以使用另一种技术来改变基础的层，而不会影响上层的应用；可以减少不同层之间的依赖；容易制定出层标准；底下的层可以用来建立顶上层的多项服务；分层有利于标准化工作的执行。分层只是将系统各种逻辑进行更有效的组织。分层架构的缺陷也不容忽视，层次不能封装所有东西，有时候会带来级联修改；过多的层间数据传递会影响性能。
2. 两层结构与三层结构
在分层结构中比较常用的有两层结构和以三层结构为代表的多层结构。基于二层架构的应用通常称为Client/Server应用。很多情况下服务器提供的服务仅仅是数据库服务。在这种模式中客户端负责访问数据，完成业务逻辑处理、接收用户的输入及将结果向用户展示。二层体系结构的主要不利之处是其业务逻辑没有从表示逻辑中分离开来，程序员很难在二层结构的应用中清楚地将业务逻辑从表示逻辑中分割出来，这样就很难维护、改进，可扩展性差，也很难重用。
三层体系结构以传统客户服务器模式为基础，将客户程序和数据库服务器的功能进一步分解，客户程序仅根据需要提出数据请求，数据库服务器也仅负责与数据存储、完整性控制等有关的任务，而数据加工、处理等业务逻辑，交于另一个独立的部分来完成，这样不仅减轻了服务器的负担，也使前台客户程序更加独立，仅注重于与操作人员的交互和数据的单一处理，形成了表示层、业务层、以及数据层三层结构，其中业务层也称为中间层，执行中间层任务的计算机称为应用程序服务器。
与传统的两层结构相比，三层最大的特征是将业务层独立了出来，从而提高了业务层的可复用性。在两层结构中，用户界面和业务处理流程放在一起，因此无法直接复用业务处理的相关功能，也无法将业务处理功能进行灵活的部署。在三层结构中，表示层只处理用户界面相关的功能，主要处理用户和软件的交互，表示层主要有Windows图形界面和基于Web的界面，主要职责就是为用户提供信息，以及把用户的指令传送给业务层。业务层复杂处理业务流程，是三层结构中最重要的一层，可以对业务层进行灵活的部署，开发时也便于业务处理的开发和用户界面的开发同时进行。针对于信息系，数据层的最大的逻辑就是存储持久数据。
三层结构的优点如下：减少客户机的维护量，因为前台程序比较简单；把企业逻辑封装在通用的中间件应用服务器中，不同的客户都可以共享同一个中间层，而不必每个客户都单独实现企业规则，避免了重复开发和维护的麻烦。由于客户程序相当瘦，无论是开发还是发布，都变得简单了。便于升级，当中间件升级的时候，客户程序可能不需要变化；实现了分布式数据处理，把一个应用程序分布在几台机器上运行，可以提高应用程序的性能，也可以把敏感部分封装在中间件，为不同的用户设置不同的访问权限，增强了安全性。
3. 本软件架构设计
在上述的二层结构和三层结构中，三层结构具有明显的优势，能很好的实现业务与界面的分离，在一定程度上实现了重用和松耦合。本软件的结构在三层架构的基础上继续改进，如图2所示。表示层采用Windows界面，主要是结合用户的使用习惯及本项目开发人员的技能综合考虑。数据库采用微软的SQL Server2000及MSDE，对于用户网络环境受限，本软件只能单机安装的情况采用MSDE数据库，其他情况采用SQL Server2000。 在基于数据库系统的三层结构中，业务逻辑层不仅负责业务逻辑，而且直接访问数据库，提供对业务数据的保存、更新、删除和查询操作。系统框架起到容器的作用向业务逻辑层提供服务，它还能够被很好的重用，将一些基础的公共的功能放在系统框架层，这样就没有必要每个项目都从头做起，可以重用以前的成果提高效率。目前该系统框架提供的服务主要有连接池、缓存、日志、安全性、异常、访问配置信息等。
图2 系统架构
2.2 获取分析类
类图的获取是一个不断细化的过程，一般我们先从分析类开始。分析类是概念层面上的类，是进行类设计的基础，获取分析类是系统分析中一项很重要的工作。获取分析类的是一个需要大量技巧的工作，我们主要根据用例描述来确定分析类。表2中列出的问题可以帮助我们识别用例中的类。
表 2 识别用例中类的问题
|
用例描述中出现了那些实体？ |
|
用例的完成需要哪些实体合作？ |
|
用例执行过程中会产生并存储哪些信息？ |
|
用例要求与之关联的每个角色的输入是什么？ |
|
用例反馈与之关联的每个角色的输出是什么？ |
|
用例需要操作哪些硬设备？ |
比如在“选择建设项目”用例描述中对基本流的描述如下：“系统提供已有建设项目供用户选择。用户从系统提供的项目列表中选中某个建设项目。系统对当前选中的建设项目进行标识，进入主界面” 。通过对用例描述的分析可以确定出分析类“建设项目”。通过类似的方式对每个用例描述进行分析，可以获得系统的分析类。如图3所示，就是我们对用例进行分析后获得的系统的分析类。
图3 分析类
2.3 用例实现
获得分析类以后，我们就可以借助分析类通过交互模型对用例如何实现进行描述。用例实现是一个由需求转移到分析、设计的过程。用例描述了用户的功能性需求，用例实现借助分析类以及他们之间的交互来描述用例被如何实现。可以看出使用UML从需求到分析、设计的过渡是很平滑的。在描述用例实现时我们可以使用活动图、顺序图、协作图等方式。活动图和协作图可以互换，一般我们仅选择其中的一种就可以了。由于篇幅的限制项目继续以用例“选择建设项目”为例说明。
图4 “选择建设项目”的活动图
为了使这个用例能够更加清晰，使用了图4所示的“选择建设项目”的活动图对该用例加以描述。进入该用例后，系统提供所有建设项目及新建建设项目功能。此时用户可以浏览已经列出的建设项目进行选择，或者使用查询功能进行查询，或者新建一个并不存在的建设项目，这些操作对应了基本流和可选流。由于用户处理的建设项目不多，所以将所有的建设项目都列出来。通过这样的活动图我们对用例“选择建设项目”将有一个更清晰的认识。
下面的对用例实现的描述主要采用了顺序图来描述，当然也可以同时使用协作图进行描述。顺序图和协作图都属于交互图，都是用于描述系统中对象之间的动态关系。两者可以相互转换，但是两者强调的重点不同，顺序图强调的是消息的时间顺序，而协作图强调的是参与交互的对象的组织。如果我们使用建模工具，创建了顺序图之后，工具可以帮我们自动生成协作图。
用例描述中描述的基本流、可选流可以通过顺序图来进行更加详细的描述。对于用例“选择建设项目”使用一个活动图和三个顺序图来实现它的动态模型。“选择建设项目”的用例描述中有一个基本流，两个可选流。我们将选用3个顺序图分别描述这三个场景。
图5 “选择建设项目”基本流的顺序图
图5所示的顺序图，是“选择建设项目”用例的基本流中对象之间的交互序列。在此顺序图中的对象有质监机构的工作人员、选择建设项目窗体的一个实例、TProject类的一个对象。用户激活选择建设项目窗体的一个实例。该窗体创建TProject类的一个对象。接着窗体调用对象方法，获得的所有建设项目，并且调用自身的方法将这些建设项目进行加载，供质监机构的工作人员选择。用户选择了一个建设项目，窗体调用对象的方法将用户选择的建设项目标识为当前的建设项目，以后所有的操作将在这个建设项目上进行。
图6 “选择建设项目”可选流1的顺序图
图6所示的顺序图是选择建设项目用例的“可选流1”中对象之间的交互序列。也就是用户不使用系统列出的建设项目，而是查询建设项目从中选择。在此顺序图中的对象有某个质监机构的工作人员、选择建设项目窗体的一个实例、TProject类的一个对象。某个质监机构的工作人员激活选择建设项目窗体的一个实例。该窗体创建TProject类的一个对象。接着窗体调用对象方法，获得的所有建设项目，并且调用自身的方法将这些建设项目进行加载，供质监机构的工作人员选择。某个质监机构的工作人员将查询信息提供给窗体进行查询，窗体调用对象的查询方法获得建设项目。窗体调用自身的加载方法，将查询得到的建设项目加载到窗体上，供质监机构的工作人员选择。质监机构的工作人员选择某个建设项目之后，窗体调用对象的方法将用户选择的建设项目标识为当前的建设项目，以后所有的操作将在这个建设项目上进行。
图7 “选择建设项目”可选流2的顺序图
图7所示的顺序图是“选择建设项目”用例的可选流2中对象之间的交互序列。也就是不选择建设项目而新建一个建设项目。在此顺序图中的对象有某个质监机构的工作人员、选择建设项目窗体的一个实例、TProject类的一个对象。某个质监机构的工作人员激活选择建设项目窗体的一个实例。该窗体创建TProject类的一个对象。接着窗体对象的方法，获得所有的建设项目，并且调用自身的方法将这些建设项目进行加载，供质监机构的工作人员选择。某个质监机构的工作人员不进行选择，新建建设项目，窗体调用对象的新建建设项目的功能。该功能在新建建设项目用例中描述。
2.4 整理分析类
整理分析类主要是依据用例实现部分的一系列的交互图。我们已经获得了分析类，在用例实现中我们在交互图中使用了这些类。但是这些类还没有属性、职责。我们需要对他们进行整理，完成分析类的属性、职责以及类之间的关系，并在类图中将他们展示出来。
职责是分析类响应消息并完成特定功能的能力，包括对外提供服务和维护自身的信息。由于消息和职责存在着对应关系，根据消息就可以确定职责。在交互模型中对象之间的交互通过消息进行。将交互图中将和该类有关的消息进行整理确定类的职责。
类之间并不是孤立的，利用类之间的关系就可以找到另一个类。利用协作图中对象之间的连接就是分析类之间的关联方式之一。分析类之间完整的关联关系要根据所有事件序列中对象间的连接加以归纳。
属性是分析类的基本内容。属性的基本来源是用例的事件流描述。如果对分析类及方法的描述比较明确，属性就比较容易获取。要分析属性也要结合分析类的方法，因为职责会使用属性去完成功能。
在整理分析类的过程中一定要注意分析类不仅仅参与了一个用例，它可能参与了很多的用例，因此在分析属性、职责及类之间关联的时候要考虑每个用例的情况，进行归纳总结。通过整理分析类绘制的类图仅仅是分析阶段的类图还需要在后续阶段继续完善和细化。
图8 分析类Project
图8就是整理出的一个分析类Project类的示例，当然这个类不仅仅是从选择建设项目这个用例获取的信息，它是综合了所有相关的用例分析的结果。
未完待续......