1. UML基础
1.1 UML简介
1.1.2 UML背景
1970年期间,面向对象方法出现,1989-1994得 到大发展。不同的方法大发展,触使建立一个标准的、统一的建模语言。
1990年代,3个最流行的面向对象方法:++OMT(强分析弱设计)、Booch(强设计弱分析)、OOSE(强分析弱其它)++。
++统一建模语言UML (Unified Modeling Language)的出现++结束了符号方面的”方法大战“。UML统一了Booch、OMT、OOSE方法的符号,并采纳了其他面向对象方法的许多好概念。
1.1.2 UML发展
1.1.3 UML内容(定义,重要)
- 元数据(描述数据的数据)
- 语义(元模型的定义)
- 表示法(UML符号表示方法)
适用范围(重要)
Unified Modeling Language (UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。
UML元数据(重要)
概念理解
- 描述数据的数据,是一种抽象;
- 描述数据的含义和性质,以便更好地理解、管理和使用数据的数据。
示例
数据:图书馆中的书籍
元数据:标题、作者、关键词、ISBN号
UML语义(重要)
UML语义给出了基于UML的精确的元模型定义。元模型为UML的所有元素在语法和语义上提供简单、一致、通用的定义性说明,使开发者在语义上取得一致。支持元模型的扩充定义。
UML表示法(重要)
UML表示法定义了UML符号的表示方法,为系统建模提供标准。表达应用级的模型,在语义上是UML元模型的实例。
1.1.4 UML主要特点
- UML统一了Booch、OMT、OOSE和其他面向对象方法的基本概念和符号。
- UML是一种先进实用的标准建模语言,其发展存在着一个进化过程。
- UML是一种建模语言而不是一种方法。UML独立于过程,用户根据不同的需要选用不同的过程。UML是一种语言,独立于过程,最好应用于用例驱动的、以体系结构为中心的、迭代的、递增的过程。
1.1.5 UML功能(重要)
- 为软件系统的产出建立可视化模型.利于交流、理解,系统结构直观、软件易维护。
- 规约软件系统的产出.定义分析、设计和实现规格。
- 构造软件系统的产出.支持模型到语言的前向工程,语言到模型的逆向工程。(是否支持软件的改进性、适用性与实用性?)
- 为软件系统的产出建立文档.包括需求、体系结构、设计、源代码、项目计划、测试、原型、发布。(软件工程的全过程)
UML优点(重要)
- UML具有定义良好的语义,不会引起歧义。
- UML是可视化的建模语言,为系统提供了图形化的可视模型,使得系统的结构变得直观,易于理解。
- 用UML为软件系统建模,不但利于交流,还有利于对软件的维护。
1.1.6 UML组成 (重要)
- 元素
- 关系
- 图
元素(重要)
包括结构元素、行为元素、分组元素、注释元素。
- 结构元素(静态):类(Class)、接口(Interface) 、协作(Collaboration)、用例(UseCase) 、活动类(ActiveClass)、组件(Component)和节点(Node)。(协作实现用例)
- 行为元素(动态):交互作用和状态机。对象间交互:消息、动作序列、连接。
- 分组元素(组织):包。
- 注释元素(解释):注解。
关系(重要)
- 依赖关系 (Dependency):调用关系,语义联系。
- 关联关系 (Association):一对一,一对多,多对多。
- 类属关系 (Generalization):类或对象间的继承和派生。
- 实现关系 (Realization):接口与类。
图(重要)
- 用例图:从用户角度描述系统功能(用户和操作);
- 静态图:描述类的静态结构,包括类图和对象图;
- 行为图:描述系统的动态模型和系统对象间的交互关系,包括状态图和活动图;
- 交互图:描述对象间的交互关系,包括时序图、协作图(信息交换,对象间的关系,对象组织);
- 实现图:描述代码组件的物理结构及各组件之间的依赖关系,包括组件图和配置图。
1.2 Rationa统一过程
1.2.1 RUP的发展(Rational Unified Process)
软件项目失败的原因(重要)
- 混乱的需求管理(不要仅考虑新技术,更需考虑用户的实际要求,新旧技术的良好接口,合理地选择最合适的开发软硬件环境);
- 开发者之间以及开发者和用户不清晰的交流(没有统一标准,尤其是开发者和用户之间缺乏行之有效的沟通方式、手段);
- 架构不够坚固(与软件和硬件均有关系,尽可能地选择经过严格测试的工具进行开发,减少因开发平台不当造成开发失败的可能性);
- 没有发现需求、设计和实现中的不一致(硬件和软件两方面);
- 缺少有效的测试(单元测试、整体测试、用户测试、Beta发布测试,测试人员的素质不高,无实际开发经验无法做好测试工作,现代QoS测试贯穿于软件工程全过程);
- 对项目状态的主观估计(开发团队的经验,市场的正确估计,用户的充分参与,有效的单元测试与阶段性整体测试) ;
- 没有正确地处理项目开发过程中的风险(风险预期不足,风险控制应对机制准备不足,技术储备不足,用户需求变化估计不足,市场变化估计不足,同类产品的发展估计不足,风险规避还是风险追求) ;
- 没有对项目变更进行控制(严重影响软件开发质量和可维护性的一个因素,可能由开发人员流动产生,可能由用户需求变化产生,可能由市场变化产生,直接对项目文档变更造成重大困难,尤其是文档的实时行,内部环境变化) 。
1.2.2 什么是RUP
- RUP是一个软件工程化过程。
- RUP是由Rational软件公司开发和维护的过程产品。
- RUP为如何有效地使用统一建模语言UML提供指导。
- RUP说明了如何有效地使用成熟技术开发软件。
- RUP是一个可配置的过程(软件可配置)。
1.2.3 过程概览(重要)
RUP的四个阶段(重要)
1.2.4 时间轴(各阶段工作,重要)
- 起始阶段 (Inception)
- 细化阶段 (Elaboration)
- 构建阶段 (Construction)
- 交付阶段 (Transition)
起始阶段
- 明确说明项目规模,了解环境以及最重要的需求和约束(需求动态变化),以便可以得出最终产品的验收标准;
- 计划和准备商业理由,评估风险管理、人员配备、项目计划以及成本/进度/收益折衷的被选方案;
- 综合考虑被选构架,评估构架;
- 准备项目的环境(软硬件环境),评估项目和组织,选择工具,决定流程中要改进的部分。(评估:风险、费用、人事、流程改进)
细化阶段
细化阶段的焦点是需求、分析和设计工作流。需求贯穿于软件工程全过程。
- 标明用例模型中的用户和参与者,并且建立用例的描述文档,用例模型需完成80%;
- 创建软件系统开发过程中的软件结构的描述文档(文档时间可能非常长,至数年);
- 创建可执行的系统原型(开发项目的积累) ;
- 细化商业案例和风险列表(大型软件) ;
- 创建整个项目的开发计划(针对公司实际与当前开发情况,并行完成项目) 。
构造阶段
- 优化资源、避免不必要的报废和返工,使开发成本降到最低;
- 尽快达到质量的要求;
- 快速完成有用的版本,例如Alpha 版、Beta 版和其他测试发布版;
- 完成所有功能的分析、开发和测试;
- 迭代式、递增地开发随时可以发布的产品(降低开发风险,快速应对各种可预期和不可预期的变化);
- 确定准备好软件系统的外部环境。构建阶段的焦点是实现工作流。
交付阶段
- 进行Beta版测试,按用户的要求验证新系统;
- 替换旧的系统;
- 对用户和维护人员进行培训;
- 开始调整活动,例如调试、性能或可用性的增强(电信,银行,7X24方式维护);
- 与用户达成共识,配置基线与评估标准一致。
- 交付阶段的焦点是实现和测试工作流。
1.2.5 迭代(反复多次)
RUP中的每个阶段可以进一步分解为迭代。
- 吻合需求
- 适应变化
- 降低风险
- 积累经验
- 人员易安排
- 保证质量
- 用户真实意图挖掘
1.2.6 工作流(描述工作过程,重要)
过程分为核心过程工作流和核心支持工作流
RUP中有9个核心工作流,分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。
6个核心过程工作流
商业建模(Business Modeling):理解系统的组织结构及其商业运作,确保所有参与人员对开发系统有共同的认识。确定系统功能和用户需要。
需求分析(Requirements):定义系统功能及用户界面,明确客户需要的系统的功能,开发人员理解系统的需求,为项目预算及计划提供基础。 注重功能性需求与非功能性需求相结合。
- 分析与设计(Analysis and Design):把需求分析的结果转化为实现规格。
.考虑实现环境,可行的技术方案,周期可能很长,大大长于实现和测试时间。 - 实现(Implementation):定义代码的组织结构、实现代码、单元测试、系统集成。 同时修正分析与设计的结果。
- 测试(Test):验证各自子系统的交互与集成。质量管理,贯穿于软件工程的全过程。单元测试,整体测试。
- 配置(Deployment):打包、分发、安装软件,升级旧系统;培训用户及销售人员,并提供技术支持。制定并实施beta测试。
3个核心支持工作流
- 配置和变更管理(Configuration and Change Management):跟踪并维护系统所有产品的完整性和一致性。 工作量大,技术要求高,大量行业经验的积累, 企业知识的积累。
- 项目管理(Project Management):为计划、执行和监控软件开发项目提供可行性的指导;为风险管理提供框架。工作人员的经验,管理规范与动态适应性,开发 团队与管理。
- 环境(Environment):为组织提供过程管理和工具的支持。软件和硬件的管理与支持。
1.2.7 微过程的划分(细化,粒度依软件规模而定)
商业建模:RUP为软件工程师和商业工程师提供共同的语言和过程,在商业模型和软件模型之间创建并保持直接的可跟踪性,使两方面对需要被支持的商业过程达成共识。
需求分析:描述系统做什么,使开发人员和用户达成共识。抽取用户的需求,识别系统参与者和用例。使用文字对每个用例进行详细描述,包括非功能性描述。用例贯穿于整个系统开发周期,是一条主线,同一用例将被用在需求捕捉、分析、设计和测试阶段。
分析:对问题域进行分析,确定系统问题域中的类
确定类(静态结构)有两种途径:
(1) 阅读规格说明、用例、寻找系统问题域中的类及类间关系类来分析问题域。
(2) 与用户和领域专家讨论,识别出所有关键类及类之间的相互关系。设计:任务是综合考虑技术限制,扩充和细化分析阶段产生的模型。目的是确定易转化为代码的设计方案,细化分析阶段的抽象类,并增加新类以处理如数据库、通信、硬件等技术领域问题。
分为两个部分:
(1) 结构设计:高层设计,划分子系统,确定子系统之间的依赖性和关联性。
(2) 详细设计:细化子系统,清晰地描述类。实现:目的在于定义代码的组织结构;以组件的形式实现类和对象;对开发出的组件进行单元测试;将开发人员或小组开发的软件集成为可执行系统。
测试:目的在于验证对象间的交互作用、软件组件的正确集成、所有需求的正确实现、确保BUG的处理。
测试类型:
(1) 单元测试:使用规格说明测试单独类或一组类。
(2) 集成测试:使用组件图和协作图测试组件间协作。
(3) 系统测试:使用用例图测试系统需求满足度。
(4) 验收测试:用户测试满意度。配置:将软件分发给最终用户。早期阶段的工作为后期的软件发布做准备。配置图描述系统的物理结构,说明设备之间的关系,节点与可执行软件单元的对应关系。
项目管理:平衡冲突目标,管理风险,克服各种限制以同时满足用户费用要求和系统要求。
配置和变更管理:控制同一项目组不同成员的大量产出物。
避免冲突:
(1) 更新同步:小组成员的系统软件版本保持一致。
(2) 有限通知:通知小组成员项目组软件的最新进展,防止错误理解和重复劳动。
(3) 多版本:保证系统多个版本之间的一致性。一个大系统中,必须进行版本管理和版本跟踪,对版本的更新、成员更新信息等要有详细的记载。
环境:为软件开发组织提供软件开发环境。开发环境的选择最好是最适合于当前项目的开发,对当前项目开发有最多的各方面支持。
静态建模:创建并建立一个系统的静态特征
- 用例图:描述系统功能及功能的使用者.
- 类 图:表现系统里实体的关系,责任,类和类之间的关系,属性及方法.
- 对象图:当类图不能完全显示关系时用对象图.描述对象的属性,对象名,方法.
- 组件图:对类功能的封装,一个组件包含多个类.
虚线:表示依赖关系. - 部署图:描述系统中的物理结构.
实线:表示连接
动态间模:用来展示系统的行为
- 时序图:描述对象的交互过程.以时间为参考(强调的是时间顺序).
虚线:(生命线)表示对象的生命周期.
实线:对象消息.
虚线:返回消息.
长方形:活动(激活).
叉:对象消亡. - 协作图:跟时序图一样,但强调对象的连接关系.
- 状态图:描述对象的自身的状态(一个对象的类型不同可能行为很古怪,行为变化很大).
- 活动图:(类似于流程图)描述一个环境中的交互顺序.