软件开发建模

软件开发建模（一）

在软件工程的全部实施过程中都采用模型的方式而非文字的表达方式来进行描述，这样的实现过程称之为全程建模。全程建模的特点是：模型相互之间是有关联的，模型成为软件工程过程各阶段展现的主体而不是文字描述作为主体存在。通过建模的方式将原来纯文字加图形描述的各种文档模型化，使得从需求到代码能够统一起来，实现需求的变动直接影响到代码的变化。提高代码对需求的有效性联系，同时，解决过去经常出现的：编码改动，文档就失效的问题。

软件建模方法有很多种，至今为止最广泛使用的是UML。UML是Unified Modeling Language，统一建模语言，主要由Booch、Rumbaugh及Jacobson三人提出，他们三人把自己分别提出的建模方法Booch、OMT、OOSE融合为一种方法称为UML。Booch在《The Unified Modeling Language User Guide》中对UML的定义是“UML是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言”。可以简单的理解UML是软件建模的一种语言，它的特色是使用图形化的方法来进行软件建模。UML的特点如下：统一的标准，UML已经被OMG接受为标准的建模语言，而且越来越多的开发人员使用ULM语言进行开发；UML是支持面向对象技术的建模语言；可视化、表示能力强大；独立于过程，UML不依赖于特定的软件开发过程；概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。

UML能够用来为系统进行面向对象建模，但是并没有指定应用UML的过程，它仅仅是一种语言，它是独立于任何过程的。如果想要成功的应用UML一个好的过程是必要的。合理的过程能够有效的测度工作进度，控制和改善工作效率。RUP是一个很好的软件过程，它的核心就是解决可操作性的问题，可以帮助开发人员完成使用UML全程建模的问题。RUP虽好，但是RUP十分庞大对于一些小的项目实施起来比较困难。所以有很多人一直在探讨敏捷建模的方法。本人参考了RUP、青润的《软件工程之全程建模实现》及尤克滨的《UML应用建模实践过程》并结合自己的工作经验形成敏捷建模的过程，在此将它分享出来，希望对大家有所帮助，另外也希望大家多提包括意见，让我成长。这个过程应用在以前我参与的一个软件项目开发过程中，为了方便表达将该系统称为A系统。下面的内容包括5节：需求模型、分析模型、设计模型、物理架构模型、代码导出。由于内容太长将分几次上传。

1 需求模型

1.1 用例模型

1. 用例及用例图

用例是一个角色使用系统的某项功能时交互过程的文字描述。用例的本质是系统中各个相关人员之间就系统的行为所达成的契约，是系统的功能性需求。用例从使用系统的角度描述系统中的信息，即站在系统外部观看系统的功能，而不考虑系统内部对该功能的具体实现方式。用例描述了用户提出的一些可能需求，对应一个具体的用户目标，用例可以促进与用户沟通、理解正确的需求，同时也可以用来划分系统与外部实体的界限，是面向对象系统设计的起点，是类、对象、操作的来源。用例图主要用于描述拟建系统和外部环境的关系。用例图中主要包括用例、角色及用例间的关系。用例间的关系通常有包含、范化、扩展。

如何实现用例模型呢？用例图包括角色、系统边界、用例以及元素间的关联。首先识别出角色，根据角色再识别用例。建立用例模型的主要工作：找出角色；找出用例；描述用例；用例间的关系处理；验证模型，通过这样的一些步骤就可以建立用例模型。

2. 识别角色

 

角色不仅仅是使用系统的用户也可以是硬件、外部系统等等。角色应该和系统具有交互行为，即角色向用例发送消息或者接收用例反馈的消息。角色之间存在继承关系。通过回答以下6个问题来识别A系统的角色：

（1）谁使用系统的主要功能。

回答：质监人员。

（2）谁需要系统的支持以完成日常工作。

回答：质监人员。

（3）谁负责维护、管理并保持系统正常运行。

回答：质量监督结构的管理员。

（4）系统需要应付哪些设备。

回答：不需要。

（5）系统需要和哪些外部系统交互。

回答：无。

（6）谁或什么对系统运行结果感兴趣。

回答：质监人员。

综上所述我们分析出来的A系统角色有质监人员、管理员。

3. 识别用例

识别用例时由于角色已经识别出来，所以我们主要根据角色来识别用例，识别用例的人为因素很大，不同的人针对同一个需求识别出的用例不一定是相同的，用例识别和经验关系很大。我们以角色“管理员”为例，根据这个角色来识别相关的用例。

（1）某个角色要求系统为其提供什么功能？该角色需要做哪些工作？

回答：管理员登录软件以后主要进行用户管理。另外系统的新建数据库、连接数据库这些工作也主要由管理员来做。

（2）角色需要阅读、创建、销毁、更新或存储系统中某些信息吗？

回答：管理员需要创建、删除、修改用户信息，进行用户管理。

将这个角色涉及到的用例进行分析得到和这个角色相关的用例：管理用户、选择数据库、建立数据库、登录。采用类似的方法还可以分析出系统的其他用例。

4. 用例图

通过上面的分析我们获得初步的用例图。我们还需要对用例进行拆分或合并。根据以上分析的结果绘制该软件的用例图。软件的用例图如图1所示。

图1 用例图

 

1.2 用例描述

用例描述是通过文字语言描述用户的实际需求，用例采用自然语言描述角色和系统进行交互时双方的行为，不追求形式化的语言。用例描述没有一个统一的标准，但一般应该包括以下的内容：用例的目的；用例是怎样启动的；角色和用例之间的消息是如何传送的；用例中除了主要路径外，其他路径是什么；用例结束后系统的状态；其他需要描述的内容。表1是一个用例描述的示例。

表1 “选择建设项目”用例描述

用例名称：	选择建设项目
综述：	所有建设项目的数据保存在同一个数据库中，当用户登录后需要选择某个建设项目或者新建建设项目。
前置条件：	登录成功，打算对某个项目进行操作
后置条件：	进入软件主界面
基本操作流：	1、 系统提供已有建设项目供用户选择。 2、 用户从系统提供的项目列表中选中某个建设项目。 3、 系统对当前选中的建设项目进行标识，进入主界面。
可选操作流：	可选流1： 1、系统提供查询条件，查询条件包括公里等级、项目名称。 2、用户输入查询条件 3、系统提供满足条件的项目，如果用户没有输入系统提示，并不进行查询操作。 4、 用户选中建设项目。 5、 系统对当前选中的建设项目进行标识，进入主界面。 可选流2： 1、 用户选择建设项目的界面上提供新建建设项目功能。 2、 系统提供新建建设项目页面 3、 用户输入建设项目信息 3、系统导航到新建建设项目界面

 1.3界面建模

软件界面建模浅析

 

在青润的《软件工程之全程建模实现》一文中提出将界面设计作为需要分析阶段的一项工作。我以前也曾在需求分析阶段进行了界面建模，并用界面模型和用户进行交流，取得了良好的效果。界面建模是需求工作中重要的步骤，同时又属于设计工作的内容，所有很多人在争论界面建模应该在什么时间开始。我很赞同做将界面建模放在需求分析阶段，一方面软件界面的需求也是用户需求的一部分，另一方面使用界面模型和用户交流系统的功能需求直观、明确，用户很容易理解。界面就结合自己以前开发的一个项目谈谈软件界面建模的事情。

1、界面设计的基本要求

·         界面设计要完整的体现出用户需求的表现形式。

·         界面设计要美观大方，一般来说界面设计的结果要符合用户群的习惯、感官、感觉。

·         界面设计中的交互操作过程要符合用户习惯性的工作过程。

2、界面建模的主要工作

首先确定界面元素，通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等等。对用户工作效率有明显影响的元素包括：输入输出方式、交互方式、功能分布。界面元素所要达到的设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用系统。本项目的这个部分的工作由界面设计人员和美工协同完成，并且以界面设计规范的形式确定下来。

再次要通过对软件的背景，使用的行业特点、用户的使用水平、喜好等方面的了解提出针对用户的一些设计。考虑到本系统的用户为公路行业，计算机应用水平比较低，所以很多部分力求简洁、明了，尽量提供用户操作、使用上的方便，很多地方尽量模拟用户的手工操作，符合他们的使用习惯。比如在功能布局上以工作流的方式来进行功能布局，这样用户很清楚做完了这个工作下一步应该怎样做。另外我们专门设计数据录入界面完全和用户实际工作中的表格相同。

最后建立用户界面模型，并且同用户进行交互。这个工作对于界面建模是很重要的，因为用户对于功能的需求相对是比较明确的，对于界面方面的需求却比较模糊，但是当一个系统展现在他们面前的时候，他们却有很多的要求和想法，通过这个工作可以将用户对界面的需求挖掘出来，而且也比较容易暴露设计中的缺陷。我们在设计完界面模型之后请用户参与了我们的评审会，之后根据用户的意见进行了界面模型的修改。

3、建模工具

我选择Visio作为界面建模工具。Visio是微软的一个图表绘制软件。Visio的模具中提供了Windows界面元素和各种标注元素，能够使我们很方便地建立Windows用户界面模型。另外，Visio还提供了比较好的发布功能允许我们将Visio文档发布为网页格式。由于UML对界面建模支持的不好，所以使用UML建模工具进行界面建模比较难。

4、界面模型示例

这个系统使用Visio来表达界面元素的布局、功能分布、交互方式等，对于不能在该模型中表达的某些内容（比如字体的大小等）用界面设计规范来表达。我们使用该模型在前期阶段和用户进行交流，帮助测试人员了解系统功能。在后期阶段将界面层对业务层的调用叠加在界面模型中，也就是在界面模型上指明在什么情况下调用哪个对象的什么方法来实现用户的请求，从而指导开发人员构筑系统。这样做，在某些方面和UML的动态建模机制有异曲同工之妙，而且更加直观有效。

 

图1 主界面

图2　管理用户界面

 

图3 叠加了实现的管理用户界面

 

未完待续......

 

 

软件开发建模（二）

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类的示例，当然这个类不仅仅是从选择建设项目这个用例获取的信息，它是综合了所有相关的用例分析的结果。

未完待续...... 

软件开发建模（三）

3 设计模型

3.1 映射分析类到设计类

设计类是指设计层面的类，映射分析类到设计类的过程实际上就是细化分析类的属性、方法，使类达到可以进行面向对象编程的程度。在分析类的属性和职责的表示方式可以比较随意、不强调规范，在设计类中就需要按照UML的语法进行表示。在从分析类到设计类的映射过程并不一定是分析类的一个属性对应设计类的一个属性，分析类的一个职责对应设计类的一个方法。类的属性和方法应该按照UML中的格式表示。

类的属性格式为：

〔可见性〕属性名〔：类型〕〔‘〔‘多重性〔次序〕’〕’〕〔＝初始值〕〔｛特性｝〕

类的操作格式为：

〔可见性〕操作名〔（参数列表）〕〔：返回类型〕〔｛特性｝〕

图9是一个由分析类Project映射而来的设计类。

图9 设计类Project

3.2 整理设计类

在最终的类图上并不是所有的类都是由分析类映射而来的，系统中的绝大部分类都是由分析类映射而来的。在完成映射之后，还需要对已有的类根据设计原则进行优化。面向对象主要的设计原则有：开放-封闭原则（OCP）、Liskov替换原则（LSP）、依赖倒置原则（DIP）、接口分离原则（ISP）等。

1. 开放-封闭原则（OCP）

开放-封闭原则描述为“对于扩展是开放的，对于更改是封闭的”。对于扩展是开放的，这意味着模块的行为是可以扩展的。当应用的需求改变时，可以对模块进行扩展，使其具有满足改变的新行为。也就是说，我们可以改变模块的功能。“对于更改是封闭的”对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。

2. Liskov替换原则（LSP）

若对每个类型S的对象O1，都存在一个类型T的对象O2，使得在所有针对T编写的程序P中，用O1替换O2后，程序P行为功能不变，则S是T的子类型。

3. 依赖倒置原则（DIP）

高层模块不应该依赖于低层模块。二者都应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。

4. 接口隔离原则（ISP）

不要强迫客户依赖于它们不用的方法。

遵循以上原则，可以使我们的软件更具灵活性，强壮性。但灵活是需要付出代价的，由多态带来的性能损失就是最明显的一个问题。所以我们需要权衡，需要做出选择，在灵活与性能之间做出选择。

依据一些面向对象设计原则对现在的类进行整理是一种最基本的形式。有一些已经遵守了面向对象设计原则的技术在设计中经常使用，比如设计模式。设计模式是已经得到很好证明的巧妙、优良、通用面向对象系统的解决方案。当我们在设计中应用设计模式时，为了设计上的考虑将会引入新的类加入到我们的设计中。

使用设计模式具有以下好处：首先，使用设计模式可以更准确地描述问题和它们的解决方案；其次，使用设计模式可以具有一致性，即如果对一些已知的问题我们有一类标准的解决方案，那么在遇到相同问题时，我们能够采取一致的方法，这就使代码更容易理解；再次，在遇到问题时，无需每次都从底层做起，而是可以从标准解决方案入手，并对它改编，使之适应特殊问题的需要。这样就节省了时间，并且提高了开发的质量和效率。

我们根据系统的架构将设计类进行了整理，在表示层主要是窗体类，他们的基类是TForm，所有窗体类太多，所以没有把他们一一列出，仅仅列出几个自定义的表示层的基类，如图10所示。

图10 表示层中的类

图11业务逻辑层中的实体类

 

图12　业务逻辑层中的边界类图

 

3.3 更新用例实现

当完成了类的设计后，需要根据类的设计更新在分析阶段的用例实现。主要工作是更新交互图，使用类的方法更新交互图中的内容。图13~图15是在类的设计完成之后更新“选择建设项目”这个用例的用例实现中的顺序图。

图13 “选择建设项目”基本流的顺序图

 

图14 “选择建设项目”可选流1的顺序图

 

图15 “选择建设项目”可选流2的顺序图

3.4 类细节设计

在上面对类设计的步骤中，设计了类的属性、方法。有些情况下设计到这个层次就可以了。由开发人员在程序编写过程中设计类中方法的具体实现。我个人的意见是如果条件允许在设计阶段尽量对类的重要方法进行设计。下面将以一个具体的类来说明类图中的详细设计。在该软件中有一个类叫做Tevaluate，它的类图如图16所示

图16 Tevaluate类图

详细设计可以很好地指导开发人员进行开发。另外，如果概要设计和详细设计一气呵成，设计中的问题会相对较少。详细设计可以采用自然语言、流程图、伪代码等多种方式实现。如图17使用伪代码对Tevaluate的方法PartEvaluate进行的详细设计。

图17 类的详细设计

图 18 PartEvaluate的活动图

可以使用活动图描述类图中一些比较复杂的类的实现。如图18所示，它描述的就是类Tevaluate中的方法PartEvaluate的实现，根据类的详细设计和活动图很容易就能够了解设计者的意图，开发人员很快就能够将其实现。

 未完待续......

软件开发建模（四）

 

4 物理架构模型

系统的物理架构模型主要通过组件图和部署图来表达。组件图的主要目的是显示系统组件间的结构关系。部署图用来描述系统硬件的物理拓扑结构以及在此结构上运行的软件。

图19是A系统的一个组件图，它描述了系统有两个可执行程序，一个是质量鉴定的主程序，另外一个是进行数据库设置和创建新数据库的工具。主程序依赖这个工具。

图19 组件图

 

图20是部署图，它是一个C/S结构的部署方案，但同时还考虑该系统同其它系统的数据交互。同一个企业内部多个鉴定客户端通过局域网连接到同一个SQL Server服务器上工作。如果这个企业需要和其它的企业交互数据，采用通过Access数据库传递数据的方式。由于客户需要交互的数据量比较少，所以这样的设计能够满足要求而且实现简单。通过软件的导出功能将数据存储在一个Access数据库文件中，通过其它的传输途径到了目的地，通过软件的导入功能，将数据传入目的数据库中。而且导出的Access文件可以使用A系统进行阅读。

图20 部署图

5 代码导出

软件建模的作用就是要将用户的需求平滑地过渡到代码。模型应该可以生成代码，模型也应该与代码保持同步。很多的建模工具都支持将模型转化成代码。使用建模工具的一个好处是它的正向工程可以产生模型对应的代码，而逆向工程功能可以根据代码更新模型。本软件的建模采用ModelMaker，它具有很强的代码生成能力，可以容易产生Delphi的源代码，而且它还可以集成到Delhpi的IDE环境中，很方便地实现代码和模型同步。ModelMaker的代码生成功能是根据类图来产生代码。下面使用Tuser类来说明代码生成。它的类图如图21所示。

图21Tuser类图

ModelMaker根据类图和模板来生成代码。图22是ModelMaker中默认的单元模板，其中包括宏和控制标记，用户也可以定制自己的模板。

图22 ModelMaker默认的单元模板

图23 TUser类的Delphi代码

图23是使用ModelMaker根据TUser类产生的Delphi代码。