一、需求分析
软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。软件需求是指用户解决问题或达到目标所需的条件或能力, 是系统或系统部件要满足合同、标准、规范
或其他正式规定文档所需具有的条件或能力, 以及反映这些条件或能力的文档说明。
1、需求的层次
( 1) 业务需求: 业务需求是指反映企业或客户对系统高层次的目标要求, 通常来自项 目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。
( 2) 用户需求: 用户需求描述的是用户的具体目标, 或用户要求系统必须能完成的任
务。
( 3) 系统需求: 系统需求是从系统的角度来说明软件的需求, 包括功能需求、非功能 需求和设计约束等。
① 功能需求: 也称为行为需求。它规定了开发人员必须在系统中实现的软件功能, 用户 利用这些功能来完成任务, 满足业务需要。
② 非功能需求: 是指系统必须具备的属性或品质,又可细分为软件质量属性和其他非功 能需求。
③ 设计约束: 也称为限制条件或补充规约,通常是对系统的一些约束说明。
2、质量功能部署
质量功能部署( QFD) 是一种将用户要求转化成软件需求的技术, 它将软件需求分为三类, 分别是常规需求、期望需求和意外需求。
( 1) 常规需求: 用户认为系统应该做到的功能或性能, 实现越多用户会越满意。
( 2) 期望需求: 用户想当然认为系统应具备的功能或性能, 但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现, 会让用户感到不满意。
( 3) 意外需求: 意外需求也称为兴奋需求, 是用户要求范围外的功能或性能, 实现这些需求用户会更高兴, 但不实现也不影响其购买的决策。
3、需求获取
是一个确定和理解不同的项目干系人的需求和约束的过程。常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
4、需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。
使用SA 方法进行需求分析, 其建立的模型的核心是数据字典, 围绕这个核心, 有三个层次的模型, 分别是数据模型、功能模型和行为模型。在实际工作中, 一般使用实体联系图
( E-R 图) 表示数据模型, 用数据流图( DFD) 表示功能模型, 用状态转换图( STD) 表示行为模型。
5、软件需求规格说明书
软件需求规格说明书( SRS) 是需求开发活动的产物, 编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解, 使之成为整个开发工作的基础。
6、需求验证
需求验证也称为需求确认, 其活动是为了确定以下几个方面的内容。
① SRS 正确地描述了预期的、满足项目干系人需求的系统行为和特征。
② SRS 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
③ 需求是完整的和高质量的。
④ 需求的表示在所有地方都是一致的。
⑤ 需求为继续进行系统设计、实现和测试提供了足够的基础。
在实际工作中, 一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS 进行技术评审。
二、UML
UML 是一种定义良好、易于表达、功能强大且普遍适用的建模语言。
1、UML 中的关系
UML 用关系把事物结合在一起, 主要有下列四种关系:
( 1) 依赖: 依赖是两个事物之间的语义关系, 其中一个事物发生变化会影响另一个事物的语义。
( 2) 关联: 关联描述一组对象之间连接的结构关系。
( 3) 泛化: 泛化是一般化和特殊化的关系, 描述特殊元素的对象可替换一般元素的对象。
( 4) 实现: 实现是类之间的语义关系, 其中的一个类指定了由另一个类保证执行的契约。
2、UML2.0 中的图
UML2.0 包括14 种图, 分别列举如下:
( 1) 类图: 类图描述一组类、接口、协作和它们之间的关系。类图给出了系统的静态设计视图, 活动类的类图给出了系统的静态进程视图。
( 2) 对象图: 对象图描述一组对象及它们之间的关系。
( 3) 构件图: 构件图描述一个封装的类和它的接口、端口, 以及由内嵌的构件和连接件构成的内部结构。
(4) 组合结构图: 组合结构图描述结构化类的内部结构, 包括结构化类与系统其余部分的交互点。
( 5) 用例图: 用例图描述一组用例、参与者及它们之间的关系。
( 6) 顺序图( 也称序列图): 顺序图是一种交互图, 交互图展现了一种交互, 它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
( 7) 通信图: 通信图也是一种交互图, 它强调收发消息的对象或参与者的结构组织。顺序图强调的是时序, 通信图强调的是对象之间的组织结构( 关系)。
( 8) 定时图( 也称计时图): 定时图也是一种交互图, 它强调消息跨越不同对象或参与者的实际时间, 而不仅仅只是关心消息的相对顺序。
( 9) 状态图: 描述了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转移。
( 10)活动图:活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它强调对象间的控制流程。
( 11) 部署图: 部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图, 通常一个节点包含一个或多个部署图。
( 12) 制品图: 制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
( 13) 包图: 包图描述由模型本身分解而成的组织单元, 以及它们之间的依赖关系。
( 14) 交互概览图: 交互概览图是活动图和顺序图的混合物。
3、UML 视图
( 1) 逻辑视图: 逻辑视图也称为设计视图, 它表示了设计模型中在架构方面具有重要意义的部分, 即类、子系统、包和用例实现的子集。
( 2) 进程视图: 进程视图是可执行线程和进程作为活动类的建模, 它是逻辑视图的一次执行实例, 描述了并发与同步结构。
( 3) 实现视图: 实现视图对组成基于系统的物理代码的文件和构件进行建模。
( 4) 部署视图: 部署视图把构件部署到一组物理节点上, 表示软件到硬件的映射和分布结构。
( 5) 用例视图: 用例视图是最基本的需求分析模型。
4、类之间的关系表示
( 1) 关联关系。关联提供了不同类的对象之间的结构关系, 它在一段时间内将多个类的实例连接在一起。。
( 2)依赖关系。两个类A 和B,如果B 的变化可能会引起A 的变化,则称类A 依赖于类B。
( 3) 泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系, 也就是父类与子类之间的关系。继承关系是泛化关系的反关系, 也就是说, 子类继承了父类, 而父
类则是子类的泛化。
( 4) 共享聚集。表示类之间的整体与部分的关系, 例如, 汽车和车轮就是聚合关系,车子坏了, 车轮还可以用: 车轮坏了, 可以再换一个新的。
( 5) 组合聚集。类之间的整体与部分的关系。例如, 一个公司包含多个部门, 它们之间的关系就是组合关系。公司一旦倒闭, 也就没有部门了。
( 6) 实现关系。实现关系将说明和实现联系起来。
三、软件架构设计
1、软件架构风格
软件架构不仅指定了系统的组织结构和拓扑结构, 并且显示了系统需求和构件之间的对应关系, 提供了一些 设计决策的基本原理。软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。解决好软件的复用、质量和维护问题, 是研究软件架构的根本目的。
软件架构设计的核心问题: 是能否达到架构级的软件复用。
( 1) 数据流风格: 包括批处理序列和管道/ 过滤器两种风格。
( 2) 调用/ 返回风格: 包括主程序/ 子程序、数据抽象和面向对象, 以及层次结构。
( 3) 独立构件风格: 包括进程通信和事件驱动的系统。
( 4) 虚拟机风格: 包括解释器和基于规则的系统。
( 5) 仓库风格: 包括数据库系统、黑板系统和超文本系统。
2、软件架构评估
① 不同类型的系统需要不同的架构, 甚至一个系统的不同子系统也需要不同的架构;
② 软件架构评估可以只针对一个架构, 也可以针对一组架构;
③ 在架构评估过程中, 评估人员所关注的是系统的质量属性。
四、软件设计
需求分析阶段解决“ 做什么” 的问题, 而软件设计阶段解决“ 怎么做” 的问题。从方法上来说, 软件设计分为结构化设计与面向对象设计。
1、结构化设计
SD 是一种面向数据流的方法,基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构, 分为概要设计和详细设计两个阶段。在SD 中, 需要遵循一个基本的原则: 高内聚, 低耦合。内聚表示模块内部各成分之间的联系程度; 耦合表示模块之间联系的程度。
2、面向对象设计( OOD)
OOD 是OOA( 面向对象分析) 方法的延续, 对于OOD 而言, 在支持可维护性的同时, 提高软件的可复用性是一个至关重要的问题,如何同时提高软件的可维护性和可复用性,是OOD需要解决的核心问题之一。
3、设计模式
( 1) 设计模式是前人经验的总结, 它使人们可以方便地复用成功的软件设计。设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
( 2) 根据处理范围不同, 设计模式可分为类模式和对象模式。类模式处理类和子类之间的关系, 这些关系通过继承建立, 在编译时刻就被确定下来, 属于静态关系; 对象模式处理对象之间的关系, 这些关系在运行时刻变化, 更具动态性。
( 3) 根据目的和用途不同, 设计模式可分为创建型模式、结构型模式和行为型模式三种。创建型模式主要用于创建对象; 结构型模式主要用于处理类或对象的组合; 行为型模式主要用于描述类或对象的交互以及职责的分配。




