第2章 UML础.pptVIP

2. Rational统一过程 (5) 测试 验证各自子系统的交互与集成。 质量管理，贯穿于软件工程的全过程。 单元测试，整体测试。 2. Rational统一过程 (6) 配置 打包、分发、安装软件，升级旧系统；培训用户及销 售人员，并提供技术支持。制定并实施beta测试。 2. Rational统一过程 (7) 设置和变更管理 跟踪并维护系统所有产品的完整性和一致性。 工作量大，技术要求高，大量行业经验的积累， 企业知识的积累。 2. Rational统一过程 (8) 项目管理 为计划、执行和监控软件开发项目提供可行性的指导；为风险管理提供框架。 工作人员的经验，管理规范与动态适应性，开发 团队与管理。 2. Rational统一过程 (9) 环境 为组织提供过程管理和工具的支持。 软件和硬件的管理与支持。 2. Rational统一过程 2.7 微过程的划分 在Rational统一过程中，每次迭代都含有一个微过程，由过程中9个工作流组成。 商业建模：RUP为软件工程师和商业工程师提供共同的语言和过程，在商业模型和软件模型之间创建并保持直接的可跟踪性，使两方面对需要被支持的商业过程达成共识。 需求分析：描述系统做什么，使开发人员和用户达成共识。抽取用户的需求，识别系统参与者和用例。使用文字对每个用例进行详细描述，包括非功能性描述。用例贯穿于整个系统开发周期，是一条主线，同一用例将被用在需求捕捉、分析、设计和测试阶段。 2. Rational统一过程 分析：对问题域进行分析，确定系统问题域中的类。确定类(静态结构)有两种途径: (1) 阅读规格说明、用例、寻找系统问题域中的类及类 间关系类来分析问题域。 (2) 与用户和领域专家讨论，识别出所有关键类及类之 间的相互关系。 确定初步的系统类图描述，为设计阶段打基础。 建模过程中的图是为了方便分析、设计、编码、理 解、交流，因而浅显、烦琐的细节图可以选择不画，避 免浪费精力。 2. Rational统一过程 设计：任务是综合考虑技术限制，扩充和细化分析阶段产生的模型。目的是确定易转化为代码的设计方案，细化分析阶段的抽象类，并增加新类以处理如数据库、通信、硬件等技术领域问题。 分为两个部分： (1) 结构设计：高层设计，划分子系统，确定子系统 之间的依赖性和关联性。 (2) 详细设计：细化子系统，清晰地描述类。 2. Rational统一过程 设计阶段强调技术层面的详细设计，设计的质量将直 接影响到实现阶段。 设计层次依软件规模和公司规模而定。 2. Rational统一过程 实现：目的在于定义代码的组织结构；以组件的形式实现类和对象；对开发出的组件进行单元测试；将开发人员或小组开发的软件集成为可执行系统。 RUP描述如何重用组件，提高系统可重用性。是对类进行编程的过程。 辅助编程： (1) 类图和类的规格说明：类间关系，属性和操作。 (2) 状态图：状态、跃迁、触发跃迁的操作。 (3) 动态图：顺序图、协作图、活动图。 (4) 用例图和规格说明：描述系统的需求和结果。 2. Rational统一过程 测试：目的在于验证对象间的交互作用、软件组件的正确集成、所有需求的正确实现、确保BUG的处理。 RUP测试四个方面：可靠性、功能性、应用程序性能和系统性能。 测试类型： (1) 单元测试：使用规格说明测试单独类或一组类。 (2) 集成测试：使用组件图和协作图测试组件间协作。 (3) 系统测试：使用用例图测试系统需求满足度。 (4) 验收测试：用户测试满意度。 2. Rational统一过程 配置：将软件分发给最终用户。 早期阶段的工作为后期的软件发布做准备。 配置图描述系统的物理结构，说明设备之间的关系， 节点与可执行软件单元的对应关系。 项目管理：平衡冲突目标，管理风险，克服各种限制以同时满足用户费用要求和系统要求。 配置和变更管理：控制同一项目组不同成员的大量产出物。 2. Rational统一过程 避免冲突： (1) 更新同步：小组成员的系统软件版本保持一致。 (2) 有限通知：通知小组成员项目组软件的最新进展， 防止错误理解和重复劳动。 (3) 多版本：保证系统多个版本之间的一致性。一个 大系统中，必须进行版本管理和版本跟踪，对版本的更 新、成员更新信息等要有详细的记载。 环境：为软件开发组织提供软件开发环境。开发环境的选