统一建模语言UML5 UML核心模型.pptVIP

统一建模语言UML ——UML核心模型 UML建模 一个模型提出了论点，静态图是论据，动态图则是论证。 建立模型的过程，就是采用论据来论证论点的过程。 UML核心模型 用例模型 领域模型 分析模型 软件架构和框架模型 设计模型 组件模型 实施模型 用例模型 用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。 用例模型是需求工作流程的结果，可以做分析设计工作流程及测试工作流程的输入。 有三个层次的用例模型： 业务用例模型 概念用例模型 系统用例模型 业务用例模型 先于需求工作流，目的是为现存的或客户预想中的真实业务建立模型，是为理解客户业务，并与客户达成理解上的共识而建立的模型。 不需要考虑计算机环境。 业务用例模型 业务用例模型描述的是业务范围，与系统用例模型不同： 有些业务不适合用计算机实现， 即使可以用计算机实现，但根据运行环境等硬件因素，一些业务需求也可能被排除在系统范围之外。 业务用例模型主要内容 业务用例视图 包括业务主角和业务用例 是业务的高层概要视图 业务用例场景 说明业务用例的执行过程 业务用例规约 对每一个业务用例，说明其使用者、目标、场景、相关业务规则、实体等 业务用例模型主要内容 业务规则 业务对象模型 描述业务模型中关键的业务对象。 业务实现视图 业务用例实现场景 包图 按业务模块或业务主角分包，以组织业务用例。 何时使用业务用例模型？ 开发一个针对商业组织的软件、或交互密集型软件，或较大规模软件时。 待开发的软件问题领域有复杂的组织结构，或有许多业务流程时。 开发人员对该行业业务了解不多时。 客户已有许多孤立的遗留系统，希望做应用整合时。 概念用例模型 当系统规模较大时，业务用例的粒度也较大，其所能描述的业务比较粗略。 需要一种方法来分解较大的业务用例，从中找到关键和核心的工作单元，针对这些工作单元来简化业务，得到一组缩小的用例——概念用例。 概念用例通过包含、泛化、扩展关系连接到基本业务用例。 概念用例模型的主要内容 概念用例视图 分解较大的业务用例，从中找到关键和核心工作单元，并针对这些单元使用包含、扩展、泛化关系与基本业务相连接。 概念用例分析 对重要和典型的业务用例场景进行仔细描述。 分析类视图 对概念用例分析过程中抽象出的分析类进行建模。 分析场景 使用分析类绘制对象交互图 何时使用概念用例？ 所面对的业务领域规模庞大，业务用例粒度较大，不容易过度到系统用例时。 业务领域是网状交叉的，有跨业务用例的业务流程时。 某个业务用例场景过于复杂，步骤和分支过多，使用活动图绘制用例场景困难时。 对系统用例的决定有疑问时。 系统用例模型 系统既定功能及系统环境模型，可以作为客户和开发人员之间的契约。 系统用例模型的主要内容 业务用例 系统用例使用精化关系连接到业务用例，表示追溯关系。 概念用例 作为模型的附加存在。 用例视图 表达系统的所有功能性需求。 用例规约 补充规约 系统用例模型的主要内容 业务规则 用例实现 代表用例的不同应用环境。 用例场景 描述参与者，对象之间的交互，可以使用交互图来描述 分析对象 领域模型 用来对问题领域中某个我们关心的问题来建立对象模型，它代表系统工作环境中存在的“事情”或发生的事情。 是一种“不完整”的业务对象模型，它不包括使用者的信息和使用过程。 通常是先建立业务模型，再来推导领域模型。 领域模型推导 何时使用领域模型？ 为非交互密集型软件建立领域模型； 由于参与者少，获取用例的意义不大。 为交互密集型软件中交叉和重叠的对象建立领域模型； 当问题领域比较复杂，一项业务涉及很多对象，并且对象之间的相互影响很频繁时使用领域模型。 分析模型 是一种可选模型，是从需求向设计模型转化的过渡。 由于分析类忽略实现细节，可以只关心系统如何使用对象来实现需求，采用分析类来维护系统实现与需求的同步能非常大的节省工作量。 如何使用分析模型？ 结合时序图，分析用例场景，把用例场景过程用分析类实现出来。 获得分析类后，进一步定义分析类之间的关系。 对备选的分析类，及其关系进行调整和优化。 分析模型的主要内容 分析模型的意义 一方面为我们提供了系统如何实现需求的理解，一方面为下一步演化到设计模型提供了极好的输入。 软件的架构和框架 软件架构： 在较高的抽象层次上，将系统规划为一些独立的逻辑部件，部件间通过标准的通信接口传递信息，是对系统高层次的定义和描述。 一个架构就是一个系统的蓝图，骨架。 框架： 是针对某个问题领域的通用解决方案， 通常集成了最佳实践和可复用的基础结构，对开发工作起到减少工作量、指导和规范作用。 软件的架构 需要描述两方面内容： 业务架构 软件架构 业务架构 其目标是为业务领域建立一个维护和扩