第六章 面向对象的需求分析齐治昌《软件工程》第二版

第六章面向对象的需求分析

齐治昌《软件工程》第二版1.概念与思想2.UML概述3.基于UML的需求分析6.OOA概述OOA的核心是利用面向对象的概念和方法建造需求模型。包含：图形语言机制+面向对象方法学历史：60年代中Simula67；80年代初Smalltalk；80年代中后期成为软件开发方法。90年代中后期，UML(统一建模语言)6.1OO的概念与思想OO方法把程序看作是相互协调而又彼此独立的对象的集合。OO方法强调软件开发过程中面向客观世界中的事物，采用人类认识世界的普遍的思维方法。现实世界、问题空间、解空间、语意断层现实世界由实体及其相互关系构成，与问题相关的实体及其属性抽象为问题空间的对象，通过映射为解空间中的基本对象来寻求问题的软件解。6.1OO的概念——对象定义：是现实世界中个体或事物的抽象表示，是其属性和相关操作的封装。理解：构成世界的一个独立单位。对象=属性+服务，属性-静态特征服务-动态特征以数据为中心：围绕数据协调处理，不设置与数据无关的操作。对象是主动的：进行处理的主体。实现了数据封装：数据对外是隐藏的、不可见的。本质上具有并行性。模块独立性好。6.1OO的概念——类定义：某些对象共同特征（属性和操作）的表示。理解：人类认识客观世界常用的思维方法。本质特征、抽象、概念/类。类给出了符合该类所有对象的抽象定义，对象是符合这种定义的一个实体。一个对象称为类的实例，类称作对象的模板。对象有自己的存储空间，类是形式定义。一般类、特殊类6.1OO的概念——继承定义：是现实世界中遗传关系的直接模型，它表示类间的内在联系以及对属性和操作的共享。理解：特殊类自动、隐含地拥有其一般类的所有属性与服务。继承具有传递性。多继承性。多继承的命名冲突。6.1OO的概念——聚集定义：现实世界中部分-整体关系的模拟。理解：物理上的组成关系。抽象概念的组成关系。6.1OO的概念——消息定义：对象与外部世界相互关联的唯一途径理解：对象间通信唯一合法的途径。C++中，所谓消息就是函数（或过程、例程）调用。“消息”有更强的适应性。6.2UML概述——简介用于对软件密集型系统的制品进行可视化、祥述、构造和文档化的图形语言，是一种描绘系统蓝图的标准方法。综合了GradyBooch的Booch方法、Jackson的OOSE和Rumbaugh的OMT方法，1994年底开始，1998年发布了UML1.3版。UML是一种语言，提供了用于交流的词汇表和词汇表中组合词汇的规则。特别着重于对系统进行概念上物理上的可视化描述。主要完成的工作：可视化、祥述、构造、文档化。使用UML描述系统，可直接得到需求、体系结构、项目计划和源代码等文档。6.2UML概述——语言机制图形化的表示机制，十多种视图，分4类：用例图：用户角度：功能、执行者静态图：系统静态结构类图：概念及关系对象图：某种状态或时间段内，系统中活跃的对象及其关系包图：描述系统的分解结构行为图：系统的动态行为交互图：描述对象间的消息传递顺序图：强调对象间消息发送的时序合作图：强调对象间的动态协作关系状态图：对象的动态行为。状态-事件-状态迁移-响应动作活动图：描述系统为完成某功能而执行的操作序列实现图：描述系统的组成和分布状况构件图：组成部件及其关系部署图：物理体系结构及与软件单元的对应关系6.2UML概述——语言机制(用例图)例：p147-1506.2UML概述——语言机制(类图)6.2UML概述——语言机制(顺序图)6.2UML概述——语言机制(协作图)6.2UML概述——语言机制(状态图)6.2UML概述——基于UML的软件开发过程迭代渐进式，四个阶段：初启：确定目标、范围细化：初步需求分析、初步高层设计、部分详细设计、部分原型构造用到的UML语言机制：用例及用例图、类图、活动图、包图、交互图等细化结束的条件：主要需求通过用例及用例图描述；重要风险已标示；能够精确估算实现每一用例的时间（p151）构造：通过迭代完成对所有用例的软件实现。迭代计划及其原则：业务价值大、风险高的用例优先(p151-152)迭代过程：针对用例的分析、设计、编码、测试、集成用到的UML语言机制：p152（1）-（8）移交6.3基于UML的需求分析基于UML的需求分析大致分为两步骤：利用用例及用例图表示需求利用包图及类图表示目标系统结构两步骤无时序关系、可并行。P153图6.76.3需求分析——开发场景场景：从单个执行者的角度观察目标软件系统的功能和外部行为。是用户与系统之间进行交互的一组具体动作。场景是用例的实例，用例是某类场景的共同抽象场景的描述包括：名称、执行者实例、前置条件、事件流和后置条件。例p1536.3需求分析——开发场景(分类)场景的分类（根据作用）：p154实际场景：对实际的业务处理流程或其优化流程的描述。设想场景：分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。评价场景：以确认需求或提出改进建议为主要目的的业务流程描述。培训场景：面向开发人员及用户解释系统的功能和外部行为的业务流程描述。6.3需求分析——生成用例用例：从外部用户的角度看，一个用例是执行者与软件系统间的一次典型的交互作用。从系统内部看：一个用例代表系统执行的一系列动作，且动作结果被外部执行者察觉。用例的描述包括：名称、参与执行者、前置条件、一个主事件流、零到多个辅事件流程和后置条件。用例主要来源于对场景的分类和抽象，可略过场景，直接描述用例。6.3需求分析——生成用例(例子)例p1556.3需求分析——用活动图表示用例UML活动图：节点：活动有向边：活动的执行顺序。条件表达式菱形：判断节点同步条：“泳道”用例的活动图表示例：p156图6.8，p157图6.96.3需求分析——生成用例图执行者与用例间的关系：触发执行/信息交换用例图中的边执行者-〉用例：表示触发执行/信息交换用例-〉执行者：用例生成的信息传递给执行者用例之间的关系使用(use)关系扩展关系(extend)例：p158图6.106.3需求分析——建立顶层架构(包图)建立顶层架构的机制：包图UML包图包：UML对类进行分组的一种机制包之间的关系：依赖、构成连接器：表示包之间的信息传递、事件发送和软件调用关系等，且有单向和双向（无向）之分p1606.3需求分析——建立顶层架构(模式)软件顶层架构设计，几种主要架构模式：流程处理模式：p160图6.12客户/服务器模式：p160图6.13模型-视图-控制器(MVC)：p161图6.14分层模型，p161图6.15。层次划分的原则：p1616.3需求分析——建立顶层架构(原则)建立顶层架构过程中要考虑的问题：p161-162架构中包的数量架构中包的耦合度软件元素的稳定性软件元素的必然性作为软件系统运行环境的物理网络拓扑软件元素的安全、保密级别开发团队的技术专长6.3需求分析——建立领域概念模型机制：类图UML类图UML的类包含：类的名称、属性列表、方法列表。图元：p162图6.16类之间的关系：继承与泛化、聚集（普通、构成，P163图6.17）、关联关系(稳定性)、依赖关系(临时性)关联是依赖的强化、聚