/ 软件设计

RUP(Rational unified Process)

1 概念

  1. RUP
    统一软件过程一种用例驱动的,以架构为中心的,采用迭代增量方式开发的软件工程过程。它汲取了面向对象软件工程领域多年来的优秀研究成果,应用统一建模语言(UML)进行可视化建模,为面向对象的软件系统的开发提供了方法论的指导。
  2. Unified Modeling Language
    用图形方式描述一个系统的静态结构和动态行为的一种可视化的面向对象建模语言,从不同的角度为系统建模，形成了整个系统的不同视图,UML作为一种建模语言，要和具体的软件过程相结合。这就实现了UML与RUP相结合
  3. 软件过程
    UML是一种可应用于软件开发的非常优秀的建模语言，但是UML本身并没有告诉人们怎样使用它，为了有效地使用UML，需要有一种方法应用于它，这就是软件过程。软件过程是为了获得客户所需要的软件，所进行的一系列任务及各个任务的工作步骤。常见的软件过程模型有瀑布模型、原型模型、增量模型、喷泉模型、RUP（统一软件过程）、敏捷过程等。
  4. RUP特征
    RUP的基本特征：1.迭代式增量开发，2.用例驱动，3.以软件体系结构为中

2 RUP生命周期

  1. 初启：发起人确定项目的主要目标和范围，并进行初步的可行性分析和经济效益分析，为了达到该目的必须识别所有与系统交互的外部实体在较高层次上定义交互的特性它包括识别所有用例和描述一些重要的用例。包括验收规范，风险评估，所需资源估计，体现主要里程碑日期的阶段计划。

  • 本阶段的主要目标如下

    1. 明确软件系统的范围和边界条件包括从功能角度的前景分析产品验收标准和哪些做,与哪些不做的相关决定
    2. 明确区分系统的关键user case和主要的功能场景.
    3. 展现或者演示至少一种符合主要场景要求的候选软件体系结构
    4. 对整个项目做最初的项目成本和日程估计更详细的估计将在随后的细化阶段中做出
    5. 估计出潜在的风险主要指各种不确定因素造成的潜在风险
    6. 准备好项目的支持环境

  • 初始阶段的产出是

    1. 蓝图文档核心项目需求关键特色主要约束的总体蓝图
    2. 原始用例模型完成 10%-20%
    3. 原始项目术语表可能部分表达为业务模型
    4. 原始商业案例包括业务的上下文验收规范年度映射市场认可等等成本预计
    5. 原始的风险评估
    6. 一个或多个原型

  • 初始阶段的评审标准

    1. 风险承担者就范围定义成本 ,日程估计达成共识
    2. 以客观的主要用例证实对需求的理解
    3. 成本,日程优先级风险和开发过程的可信度
    4. 被开发体系结构原型的深度和广度
    5. 实际开支与计划开支的比较
  1. 细化：细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素，标志点项目正式确立，完成以下工作
  • 初步的需求分析,利用用例图表示参与者与用命例以及用例与用例之间的关系。采用类图表示目标软件系统所基于的应用领域中的概念和概念之间的关系。构成的领域模型一方面可以帮助软件项目组理解业务背景，与业务专家进行有效沟通，另一方面，软件结构的主要基础。如果领域中含有明显的流程处理成分，可以考虑利用uml的活动图来刻画领域中的工作流，并标识业务流程中的并发，同步等特征
  • 初步的高层设计。利用包图刻画刻画这些包及其间的关系，形成初步的依据包来划分的用例，用例图，类，类图。
  • 部分的详细设计。对于系统中某些重要或者风险比较高的用命，可以采用交互图进一步探讨其内部的实现过程。
  • 部分的原形构造，针对复杂的用例构造可实际运行的原型，让用户帮助软件项目组确认用户需求是有效方法。
  1. 构建：
    对用例进行迭代，迭代过程由针对用例的分析，设计，编码，测试和集成5个子阶段构成。
    在实际开始构造软件系统之前，有必要预先制定迭代计划，计划制定遵循两项原则：1.用户认为业务价值较大的用例应优先安排，2.开发风险较高的用例优先安排。
  • 在构造过程中，需要使用UML的交互图来设计用例的实现方法，为了与设计得出的交互图协调一致，需要修改或精化在细化阶段绘制的作为领域模型的类图。
  • 在迭代过程中，对细化阶段给出的包图进行修改或精化，以便包图切实反映目标软件最顶层的结构划分状况
  1. 部署：
    将构造阶段获得的软件系统在用户实际工作环境中试运行。

核心工作流：6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）

  1. 业务建模工作流：通过对目标组织的商业活动的分析，建立业务模型，表达目标的业务过程，用UML活动图来描绘涉及到的角色和活动的序列、
  • 需求工作流：通过对目标组织业务分析，确定客户的需求，描述系统应具备的功能需求和性能需求。使用用例图、活动图等。
  • 分析和设计工作流：对问题域进行分析，找出其中的类及类之间的关系。产生软件系统的分析模型。分为架构设计和详细设计。
  • 实现工作流：任务是把设计模型转化成相应的代码。使用类图、状态图、相关动态图描述类的实现过程。
  • 部署工作流：目的是产生可交付的软件版本，并将其发布到客户的工作环境中。主要使用部署图和构件图来描述系统的硬件设备的分布及连接情况、软件构件在硬件上的安装情况。
  • 测试工作流：目的是尽早发现系统中的错误与缺陷、识别并跟踪处理缺陷、验证需求是否满足

3. 基于UML的需求分析

在初步的业务需求描述已经形成的前提下，基于UML的需求分析过程分为两个步骤

  1. 利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总，分类，抽象，形成用例；确定执行者与用例，用例与用例图之间的关系生成用例图
  2. 利用包图和类图表示目标软件系统的总体框架结构。根据领域知识，业务需求描述和经验设计目标软件系统的顶层结构；从业务需求中提取关键概念，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类与类之间的关系，生成类图。

具体实现

  • 生成用例：
    从外部视角看，用例是执行者与目标软件系统之间的一次典型交互作用；从内部视角看，用例代表系统执行的一系列动作，动作执行的结果能够被外部的执行者所察觉。完整的用例描述：用例名称，参与执行者，前置条件，一个主事流程，零到多个辅事件流和后置条件。
用例名称：传感器监测
  参与持行者：各类传感器，警报器，报警电话和显示器
  前置条件：系统已开机
  主事件流：
    1传感器向目标软件系统上报其监测数据，系统差别监测数据是否正常
    2如果不正常，启动警报器，拨打报警电话
    3报警电话接通后，软件系统播出语音，报告异常事件发生的时间 ，地点和事件的性质
    4系统在控制面板的显示器上显示报警时间及当前状态
  辅事件流：
    1如果报警电话无人接听，则重复拨打延迟反复拨号，直至电话接通，再转入主事件流
    2如果重拨次达到系统设置最大值，电话仍无人接听，则跳过主事件流的步骤3，转入步骤4
  后置条件：如果已发现异常的监测数据，系统处于报警状态，否则，系统处于监测状态。
  • 建立顶层结构:为后续的分析和设计活动建立一种结构和分划，便于开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚集于系统的不同部分。
  • UML包图，包的划分是实现“分而治之”的重要技术手段
  • 顶层架构设计,确定架构模式，如流程处理模式，客户/服务器模式

确立顶层架构的过程中综合考虑以下因素:架构中包的数量,架构中包之间的耦合度，系统的稳定性，系统的必然性，物理网络拓扑，软件元素的安全、保密级别，技术专长

4 其于UML的软件设计

4.1 设计用例实现方案

  1. 提取边界类，实体类和控制类；边界类用于描述目标软件系统与外部环境之间的交互，并负责界面控制，外部接口，环境隔离
  2. 构造交互图
  3. 根据交互图精化类图

4.2 设计技术支撑方案

如持久存储服务，安全控制服务，分布式事务管理服务，并发与同步控制服务和可靠消息服务

4.3 设计用户界面

1.熟悉用户并对用户分类
2.按用户类别分析用户的工作流程与习惯
3.设计命令系统并进行优化，优化命令系统时首先考虑命令的顺序，常用命令居先，命令的顺序与用户工作习惯保持一致，其次，根据外部服务之间的聚合关系组织相应的命令；然后充分考虑人类记忆的局限性，最好组织为一棵两层的多叉树；最后，减少用户完成一个操作所需的动作，并为熟练用户提供操作的快捷方式。

4.4 精细设计模型

改进的活动分为精化和合并两种，根据需求和架构原则来划分不同的粗粒度组件，粗粒度组件来源于分析活动中的业务实体，把具有很强相关性业务实体组合起来，形成一个集合。如果可能，在粗粒度组件之间定义单向的关联，有效的减少组件之间的耦合。

5 架构文档化

软件架构用来处理软件高层次结构的设计和实施，软件架构={元素，形式，关系/约束}，软件架构涉及到抽象，分解和组合，风格和美学。可以用四类视图表示

  • 逻辑视图，设计的对象模型
  • 过程视图，捕捉设计的并发和同步特征
  • 物理视图，描述了软件到硬件的映射，反映了分布式特性
  • 开发视图，描述了在开发环境中软件的静态组织结构

结构类别

  • 逻辑结构
    主要支持功能性需求，系统分解为一系统的关键抽象，大多数来自于问题域，表现为对象或对象类的形式。类图用来显示一个类的集合和它们的逻辑关系，状态图可以辅助定义对象的内部形为。公共机制和服务可以在类功能中定义。对于数据驱动程序高的应用程序，可以使用其他形式的逻辑视图，如E-R图来代替面向对象的方法 。
  • 进程架构
    考虑一些非功能性的需求，解决并发性，分布性，系统完整性，容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起。
  • 开发架构
    关注软件开发环境下实际模块的组织。