一：UML定义了5类，10种模型图

UML提供的基本模型图包括：

(1)、用例图：展示系统外部的各类执行者与系统提供的各种用例之间的关系

(2)、类图：展示系统中类的静态结构(类是指具有相同属性和行为的对象，类图用来描述系统中各种类之间的静态结构)

(3)、对象图：是类图的一种实例化图(对象图是对类图的一种实例化)

(4)、包图：是一种分组机制。在UML1.1版本中，包图不再看作一种独立的模型图)

(5)、状态图：描述一类对象具有的所有可能的状态及其转移关系(它展示对象所具有的所有可能的状态以及特定事件发生时状态的转移情况)

(6)、顺序图：展示对象之间的一种动态协作关系(一组对象组成，随时间推移对象之间交换消息的过程，突出时间关系)

(7)、合作图：从另一个角度展示对象之间的动态协作关系(对象间动态协作关系，突出消息收发关系)

(8)、活动图：展示系统中各种活动的执行流程(各种活动的执行顺序、执行流程)

(9)、构件图：展示程序代码的物理结构(描述程序代码的组织结构，各种构件之间的依赖关系)

(10)、配置图：展示软件在硬件环境中(特别是在分布式及网络环境中)的配置关系(系统中硬件和软件的物理配置情况和系统体系结构)

建模过程

首先：描述需求

次之：根据需求建立系统的静态模型，以构造系统的结构

第三：描述系统的行为

其中第一步与第二步中所建立的模型都是静态的，包括用例图、类图（包括包图）、对象图、构件图和配置图等六种图。这些图构成了标凖建模语言UML的静态建模机制。

第三步中所建立的模型或者可吧执行或者表示执行时的时序状态或交互关系，它包括状态图、活动图、顺序图和合作图等四种图。这些图构成了标准建模语言UML的动态建模机制。

可用以下常用视角来描述一个系统：

(1)、系统的使用实例：从系统外部的操作者的解度描述系统的功能

(2)、系统的逻辑结构：描述系统内部的静态结构和动态行为，即从内部描述如何设计实现系统功能

(3)、系统的构成：描述系统由哪些程序构件所组成

(4)、系统的并发性：描述系统的并发性，强调并发系统中存在的各种通信和同步问题

(5)、系统的配置：描述系统的软件和各种硬件设备之间的配置关系

二：软件开发过程(RUP概述)：

迭代开发过程：

由四个阶段构成，每个阶段都包含软件开发的每个过程：分析、设计、实现和测试阶段

四个阶段：初始阶段、细化阶段、构造阶段、移交阶段

通常在移交阶段后进行总体测试、性能测试、用户培训等

1. 初始阶段：

项目的总体需求、可行性分析等，并确认是否启动该项目

2. 细化阶段：（1/5周期）

启动该项目后，

（1）、实际要做什么？

（2）、如何做？

（3）、将采用什么技术？

风险分析和风险管理

（1）、需求风险：不能偏离用户需要，要充分了解用户需求及各需求的相对优化程度

处理需求风险：用例分析技术。列出该系统的所有用例，安排开发人员与客户交流，以便收集用例。其中要对领域概念模型作充分说明（行业术语，如电信中的产品）。

建立域模型：类图、活动图

（2）、技术风险：你是否有相关技术经验，熟悉程度如何？

使用类图和交互图来描述构件间的通信

使用包图来描述构件的高层结构

使用配置图来描述系统功能的分配

（3）、技能风险：能否得到相关技术人才或专家？

（4）、政策风险：是否存在一些政策性因素影响整个项目的进行

细化阶段的重要结果之一：建立系统的基线体系结构

（1）、用例表：用于描述系统需求

（2）、域模型：用于获取应用领域中的关键类的起点，反映你对系统将要提供的业务和服务的理解

（3）、技术平台：描述重要的实现技术以及技术间的协作和集成

细化阶段何时结束：

（1）、开发人员能给项目估算

（2）、考虑所有的风险，并制定出相应对策和计划

计划：

1.第一阶段：

用例是制定项目计划的基chu，对用例进行分类：

（1）、用户应当列出用例的优先级。通常为三级，首先要实现的，短期内可以没有，长期内可以没有的

（2）、对于每一个用例，开发人员都应考虑体系结构风险。三级：高风险，可能的风险，完全不可能的风险

（3）、开发人员还应评价自己对每个用例开发工作量的做算，称之为进度风险。三级：确信自己对时间的估算，只能估算到人月，无法估算

注意：估算应由开发人员估算，项目经理只是评审复核作用。由些开发人员可以充分理解用例，应估算到人周

2.第二阶段：

确定每次迭代的开发周期，每次迭代的工作量（迭代次数3至5次）

3. 构造阶段

两个概念：（1）、程序重组：指对程序中与新添功能相关的成分进行适当改造，使其在结构上完全适合新功能的加入。
（2）、模式：

构造阶段是通过一系列迭代过程建设系统。每次迭代开发都是一个小项目，需要对所有要求的用例进行分析、设计、编码、测试和集成。完成一次迭代后，应向用户演示，并完成系统测试，以表明所要求的用例已正确实现。

4. 移交阶段：

迭代式开发关键在于规范化地进行整个开发过程。在移交阶段，不能再开发新的功能（除了个别小功能或非常基本的以外），而只是集中精力进行纠错工作，优化工作。

三：用例

用例的基本概念及相关介绍

主要方法：与客户交流，一系列用例的集合，就是整个系统的需求

如何区分用户目标和系统交互功能

用例模型的获取：

用例模型是获取需求、规划和控制项目迭代过程的基本工具。是初始阶段首先要做的工作，是细化阶段的主要任务之一。

a、获取执行者

获取用例首先要找出系统的使用者。

（1）、谁使用系统的主要功能（主要使用者）？

（2）、谁需要系统支持他们的日常工作？

（3）、谁来维护、管理系统使其能正常工作（辅助使用者）？

（4）、系统需要控制哪些硬件？

（5）、系统需要与其他哪些系统交互？这是系统包含其他计算机系统和其他应用程序。

（6）、对系统产生的结果感兴趣的是哪些人或哪些事物？

b、获取用例

对每个执行者提出一些问题，然后从执行者对这些问题的答案中获取用例

（1）、执行者要求系统提供哪些功能（执行者需要做什么）？

（2）、执行者需要读、产生、删除、修改或存储系统中的信息有哪些类型？

（3）、必须提醒执行者的系统事件有哪些？或者

（4）、执行者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？

针对系统的问题

（1）、系统需要何种输入输出？输入从何处来？输出到何处去？

（2）、当前运行系统（也许是一些手工操作而不是计算机系统）的主要问题是什么？

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号