软件生命期一般包括软件计划与可行性研究问题定义、可行性研究、需求分析、软件设计概要设计和详细设计、编码、软件测试、运行与维护。为了提高软件的开发效率出现了从不同角度作为出发点的软件开发方法常见的有数据库驱动开发DDDDatabase-Driver- Development、测试驱动开发TDDTest-Driver-Development、模型驱动开发MDDModel-Driver-Development。UML建模在模型驱动开发中运用比较多。UML模型有用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图、包图、组合结构图、交互概览图等他们的用途如下用例图从用户角度描述系统功能。类图描述系统中类的静态结构。对象图系统中的多个对象在某一时刻的状态。状态图是描述状态到状态控制流常用于动态特性建模活动图描述了业务实现用例的工作流程顺序图对象之间的动态合作关系强调对象发送消息的顺序同时显示对象之间的交互协作图描述对象之间的协助关系构件图一种特殊的UML图来描述系统的静态实现视图部署图定义系统中软硬件的物理体系结构包图对构成系统的模型元素进行分组整理的图组合结构图表示类或者构建内部结构的图交互概览图用活动图来表示多个交互之间的控制关系的图在软件生命周期的不同阶段选用不同的UML模型可以帮助我们更好的理解业务需求和系统逻辑。按照开发阶段使用UML建模时可以将模型架构分为业务模型、需求模型、分析模型、设计模型、实现模型、部署模型。1. 需求分析用例图、类图、活动图1.1 需求获取用例图使用用例图获取需求这一阶段的主要任务就是了解用户需求并将其转换为业务用例图。绘制业务用例图时需要注意三点业务用例是仅从系统业务角度关注的用例而不是具体系统的用例。它描述的是“该实现什么业务”而不是“系统该提供什么操作”。例如在实际系统中“登录”肯定要作为一个用例但是这是软件系统中的操作而用户所关注的业务是不包含“登录”的。业务用例仅包含客户“感兴趣”的内容。业务用例所有的用例名应该让客户能看懂如果某个用例的名字客户看不懂什么意思它也许就不适合作为业务用例。以CMS系统为例根据需求描述得出如下业务用例1.2 分析状态图、类图、活动图完成了业务用例图后就要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中用户可能会进行的操作序列。活动图有个很重要的使命从业务用例分析出系统用例。以管理新闻业务为例他的活动图如下可以看到一个“管理新闻”这个业务用例分解出很多系统操作。活动图中很多“活动”都很可能是一个系统用例例如这个活动图中可能包含以下备选系统用例登录、注销登录、查看新闻列表、修改新闻、删除新闻。将每个业务用例都绘制出相应的活动图后再将其中的“活动”整合就得出所有备选系统用例。找出所有的备选系统用例后需要进行合并和筛选。合并就是将相同的用例合并成一个筛选就是将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作例如“查看新闻列表”就不能算一个系统用例因为他只是某系统用例的一个序列项。最终我们得出的系统用例图如下得出系统用例图后应该对每一个系统用例给出用例规约。用例规约没有通用的格式可以按照习惯的格式进行编写,对用例规约唯一的要求就是“清晰易懂”。例如“登录”这个系统用例的规约如下下面就是绘制业务领域类图了。业务领域类图要识别出系统中的实体、实体间的联系以及实体的操作主要要描述以下三点系统中有哪些实体这些实体能做什么操作实体间的关系CMS系统的业务领域类图如下注意业务领域类图中的实体不是Actor而是Actor使用系统时使用的所调用的实体是处在系统边界之内的实体。例如管理员就没有作为一个实体出现在这里因为管理员处在系统边界之外它所有的工作都可以通过调用这三个类的方法完成。并且这里的“User”实体也不是刚才用例图中注册会员这个Actor而是作为一个系统内的业务实体供Actor们使用的。例如其中的register功能是给注册会员这个Actor使用而remove功能则是给管理员这个Actor使用的。业务领域类图中的实体一定是在系统边界之内的如果混淆了实体和Actor的关系将导致画出的领域类图不准确或职责分配不准确。在领域分析阶段实体的属性并不重要重要的是找出实体的操作。识别出系统中的实体后还需要对业务规则进行分析。例如可以使用状图图描述新闻的发布规则2. 设计阶段类图、包图、活动图、协作图、顺序图设计阶段一般要绘制实现类图。实现类图和领域类图不一样它描述的是真正系统的静态结构是和最后的代码完全一致的。因此它和平台关系密切必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此实现类图是很复杂的而且是平台技术有关的。实现类图跟具体的平台技术相关下面是一个实现类图的示意图实现类图是一种静态结构需要给出动态结构才能看清系统间的类是如何交互的。一般使用活动图、协作图、顺序图进行描述建议不要做详细的协作图或顺序图-很难维护。例如系统登录的时序图各个类间的调用关系可以使用协作图来描述。3. 实施阶段组件图、部署图系统开发完成后为了更好的帮助实施人员进行系统部署一般使用部署图进行描述系统组成及软硬件的关系。例如
UML建模在软件生命周期中的应用
发布时间：2026/6/6 19:14:06
软件生命期一般包括软件计划与可行性研究问题定义、可行性研究、需求分析、软件设计概要设计和详细设计、编码、软件测试、运行与维护。为了提高软件的开发效率出现了从不同角度作为出发点的软件开发方法常见的有数据库驱动开发DDDDatabase-Driver- Development、测试驱动开发TDDTest-Driver-Development、模型驱动开发MDDModel-Driver-Development。UML建模在模型驱动开发中运用比较多。UML模型有用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图、包图、组合结构图、交互概览图等他们的用途如下用例图从用户角度描述系统功能。类图描述系统中类的静态结构。对象图系统中的多个对象在某一时刻的状态。状态图是描述状态到状态控制流常用于动态特性建模活动图描述了业务实现用例的工作流程顺序图对象之间的动态合作关系强调对象发送消息的顺序同时显示对象之间的交互协作图描述对象之间的协助关系构件图一种特殊的UML图来描述系统的静态实现视图部署图定义系统中软硬件的物理体系结构包图对构成系统的模型元素进行分组整理的图组合结构图表示类或者构建内部结构的图交互概览图用活动图来表示多个交互之间的控制关系的图在软件生命周期的不同阶段选用不同的UML模型可以帮助我们更好的理解业务需求和系统逻辑。按照开发阶段使用UML建模时可以将模型架构分为业务模型、需求模型、分析模型、设计模型、实现模型、部署模型。1. 需求分析用例图、类图、活动图1.1 需求获取用例图使用用例图获取需求这一阶段的主要任务就是了解用户需求并将其转换为业务用例图。绘制业务用例图时需要注意三点业务用例是仅从系统业务角度关注的用例而不是具体系统的用例。它描述的是“该实现什么业务”而不是“系统该提供什么操作”。例如在实际系统中“登录”肯定要作为一个用例但是这是软件系统中的操作而用户所关注的业务是不包含“登录”的。业务用例仅包含客户“感兴趣”的内容。业务用例所有的用例名应该让客户能看懂如果某个用例的名字客户看不懂什么意思它也许就不适合作为业务用例。以CMS系统为例根据需求描述得出如下业务用例1.2 分析状态图、类图、活动图完成了业务用例图后就要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中用户可能会进行的操作序列。活动图有个很重要的使命从业务用例分析出系统用例。以管理新闻业务为例他的活动图如下可以看到一个“管理新闻”这个业务用例分解出很多系统操作。活动图中很多“活动”都很可能是一个系统用例例如这个活动图中可能包含以下备选系统用例登录、注销登录、查看新闻列表、修改新闻、删除新闻。将每个业务用例都绘制出相应的活动图后再将其中的“活动”整合就得出所有备选系统用例。找出所有的备选系统用例后需要进行合并和筛选。合并就是将相同的用例合并成一个筛选就是将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作例如“查看新闻列表”就不能算一个系统用例因为他只是某系统用例的一个序列项。最终我们得出的系统用例图如下得出系统用例图后应该对每一个系统用例给出用例规约。用例规约没有通用的格式可以按照习惯的格式进行编写,对用例规约唯一的要求就是“清晰易懂”。例如“登录”这个系统用例的规约如下下面就是绘制业务领域类图了。业务领域类图要识别出系统中的实体、实体间的联系以及实体的操作主要要描述以下三点系统中有哪些实体这些实体能做什么操作实体间的关系CMS系统的业务领域类图如下注意业务领域类图中的实体不是Actor而是Actor使用系统时使用的所调用的实体是处在系统边界之内的实体。例如管理员就没有作为一个实体出现在这里因为管理员处在系统边界之外它所有的工作都可以通过调用这三个类的方法完成。并且这里的“User”实体也不是刚才用例图中注册会员这个Actor而是作为一个系统内的业务实体供Actor们使用的。例如其中的register功能是给注册会员这个Actor使用而remove功能则是给管理员这个Actor使用的。业务领域类图中的实体一定是在系统边界之内的如果混淆了实体和Actor的关系将导致画出的领域类图不准确或职责分配不准确。在领域分析阶段实体的属性并不重要重要的是找出实体的操作。识别出系统中的实体后还需要对业务规则进行分析。例如可以使用状图图描述新闻的发布规则2. 设计阶段类图、包图、活动图、协作图、顺序图设计阶段一般要绘制实现类图。实现类图和领域类图不一样它描述的是真正系统的静态结构是和最后的代码完全一致的。因此它和平台关系密切必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此实现类图是很复杂的而且是平台技术有关的。实现类图跟具体的平台技术相关下面是一个实现类图的示意图实现类图是一种静态结构需要给出动态结构才能看清系统间的类是如何交互的。一般使用活动图、协作图、顺序图进行描述建议不要做详细的协作图或顺序图-很难维护。例如系统登录的时序图各个类间的调用关系可以使用协作图来描述。3. 实施阶段组件图、部署图系统开发完成后为了更好的帮助实施人员进行系统部署一般使用部署图进行描述系统组成及软硬件的关系。例如
