下载文档原格式
第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。
如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
为完成这一转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。
实现方案用UML交互图表示。
（2）设计技术支撑设施。
在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。
这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。
例如，数据的持久存储服务、安全控制服务和远程访问服务等。
在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。
（3）设计用户界面。
（4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。
此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。
面向对象的软件设计过程如图8-1-1所示。
图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、协作图）适于用例实现方案的表示。
因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。
该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。
一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。
在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。
顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。
第1章软件工程学概述1.1 软件危机1.1.1 软件危机旳简介软件危机(软件萧条、软件困扰): 是指在计算机软件旳开发和维护过程中所碰到旳一系列严重问题。
软件危机包括下述两方面旳问题:怎样开发软件, 满足对软件日益增长旳需求；怎样维护数量不停膨胀旳已经有软件。
软件危机旳经典体现:（1）对软件开发成本和进度旳估计常常很不精确；（2）顾客对“已完毕旳”软件系统不满意旳现象常常发生；（3）软件产品旳质量往往靠不住；（4）软件常常是不可维护旳；（5）软件一般没有合适旳文档资料；（6）软件成本在计算机系统总成本中所占旳比例逐年上升；（7）软件开发生产率提高旳速度, 远远跟不上计算机应用迅速普及深入旳趋势。
1.1.2 产生软件危机旳原因（1）与软件自身旳特点有关（2）与软件开发与维护旳措施不对旳有关1.1.3 消除软件危机旳途径对计算机软件有对旳旳认识。
认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完毕旳工程项目。
应当推广使用在实践中总结出来旳开发软件旳成功技术和措施, 并继续研究探索。
应当开发和使用更好旳软件工具。
总之, 为了处理软件危机, 既要有技术措施(措施和工具), 又要有必要旳组织管理措施。
1.21.2.1 软件工程旳简介软件工程: 是指导计算机软件开发和维护旳一门工程学科。
采用工程旳概念、原理、技术和措施来开发与维护软件, 把通过时间考验而证明对旳旳管理技术和目前可以得到旳最佳旳技术措施结合起来, 以经济地开发出高质量旳软件并有效地维护它, 这就是软件工程。
（期中考）软件工程旳本质特性:软件工程关注于大型程序旳构造软件工程旳中心课题是控制复杂性软件常常变化开发软件旳效率非常重要友好地合作是开发软件旳关键软件必须有效地支持它旳顾客在软件工程领域中是由具有一种文化背景旳人替具有另一种文化背景旳人发明产品1.2.2 软件工程旳基本原理用分阶段旳生命周期计划严格管理坚持进行阶段评审实行严格旳产品控制采用现代程序设计技术成果应能清晰地审查开发小组旳人员应当少而精承认不停改善软件工程实践旳必要性1.2.3 软件工程措施学软件工程包括技术和管理两方面旳内容。
软件工程第八章维护第一点：软件维护的定义和重要性软件维护是指在软件发布后对其进行的一系列操作和活动，旨在确保软件系统的持续可用性、可靠性和性能。
软件维护是软件开发生命周期中的一个重要环节，它涉及到对软件进行修正、优化和升级。
软件维护的重要性体现在以下几个方面：1.保障软件质量：软件在实际运行过程中可能会出现各种问题，维护可以帮助及时修复这些问题，保证软件的正常运行。
2.提高用户满意度：通过维护，可以对软件进行功能优化和界面调整，使其更加符合用户的需求，提高用户的使用体验。
3.降低风险：软件维护可以帮助提前发现并解决潜在的风险，避免因软件问题导致的损失。
4.延长软件寿命：通过不断的维护和升级，可以使软件适应不断变化的环境和需求，延长其使用寿命。
5.提高开发效率：良好的维护可以避免因软件问题导致的重复开发，提高开发团队的效率。
第二点：软件维护的类型和策略软件维护可以分为以下几种类型：1.改正性维护：这种维护类型主要是针对软件中存在的问题和错误进行修复，保证软件的正常运行。
2.适应性维护：随着环境的变化和用户需求的变化，软件需要进行相应的调整和优化，以适应新的环境和工作需求。
3.完善性维护：这种维护类型主要是针对软件的功能进行增强和扩展，以满足用户的新需求。
4.预防性维护：预防性维护是为了避免软件出现潜在的问题和风险，提前对软件进行调整和优化。
在进行软件维护时，可以采取以下策略：1.计划维护：制定详细的维护计划，包括维护的时间、内容、责任人等，确保维护工作的有序进行。
2.变更管理：对于软件的修改和更新，需要进行严格的变更管理，确保每次变更都是经过审核和评估的。
3.版本控制：通过版本控制工具，对软件的不同版本进行管理，确保软件的每个版本都是可追踪和可恢复的。
4.文档管理：对软件的维护过程和结果进行详细的文档记录，方便对软件进行管理和维护。
5.持续集成：将软件的维护工作与开发工作结合起来，通过持续集成的方式，确保软件的质量和稳定性。
第一章绪论1.1 软件工程概念的提出与发展1.2 软件开发的本质1.3 本章小结第二章软件需求与软件需求规约2.1 需求与需求获取2.1.1需求定义2.1.2 需求分类2.1.3 需求发现技术2.2 需求规约2.2.1 需求规约定义2.2.2 需求规约（草案）格式2.2.3 需求规约（规格说明书）的表达2.2.4 需求规约的作用2.3 本章小结第三章结构化方法3.1 结构化需求分析3.1.1 基本术语1.数据流2.数据存储3.数据源和数据谭3.1.2 系统功能模型表示数据流图（Dataflow Diagram）3.1.3 建模过程1.建立系统环境图, 确定系统语境2.自顶向下, 逐步求精, 建立系统的层次数据流图3.定义数据字典数据流条目给出所有数据流的结构定义数据存储条目给出所有数据存储的结构定义数据项条目给出所有数据项的类型定义4.描述加工（1）结构化自然语言（2）判定表（3）判定树3.1.4 应用中注意的问题（1）模型平衡问题（2）信息复杂性控制问题3.1.5 需求验证3.2 结构化设计3.2.1 总体设计1.总体设计的目标及其表示（1）Yourdon提出的模块结构图（2）层次图（3）HIPO图2.总体设计步骤（1）变换型数据流图——变换设计（2）事物型数据流图——事物设计3.模块化及启发式规则（1）模块化1）耦合①内容耦合②公共耦合③控制耦合④标记耦合⑤数据耦合2）内聚①偶然内聚②逻辑内聚③时间内聚④过程内聚⑤通信内聚⑥顺序内聚⑦功能内聚（2）启发式规则1）改进软件结构, 提高模块独立性2）力求模块规模适中3）力求深度、宽度、扇出和扇入适中4）尽力使模块的作用域在其控制域之内5）尽力降低模块接口的复杂度6）力求模块功能可以预测3.2.2 详细设计1.结构化程序设计2.详细设计工具（1）程序流程图（2）盒图（N-S图）（3）PAD图（Problem Analysis Diagram）（4）类程序设计语言IPO图、判定树和判定表等也可以作为详细设计工具3.3 本章小结第四章面向对象方法——UML 4.1 UML术语表4.1.1 表达客观事物的术语1.类与对象1）类的属性（Attribute）2）类的操作3）关于类语义的进一步表达①详细叙述类的职责（Responsibility）②通过类的注解和/或操作的注解, 以结构化文本的形式和/编程语言, 详述注释整个类的语义和/或各个方法③通过类的注解或操作的注解, 以结构化文本形式, 详述注释各个操作的前置条件和后置条件, 甚至注释整个类的不变式④详述类的状态机⑤详述类的内部结构⑥类与其他类的协作4）类在建模中的主要用途①模型化问题域中的概念（词汇）②建立系统的职责分布模型③模型化建模中使用的基本类型2.接口（Interface）（1）采用具有分栏和关键字《interface》的矩形符号来表示（2）采用小圆圈和半圆圈来表示3.协作（Collaboration）4.用况（Use Case）5.主动类（Action Class）6.构件（Component）7.制品（Artifact）8.节点（Node）4.1.2 表达关系的术语1.关联（Association）（1）关联名（Name）（2）导航（3）角色（Role）（4）可见性（5）多重性（Multiplicity）（6）限定符（Qualifier）（7）聚合（Aggregation）（8）组合（Composition）（9）关联类（10）约束①有序（ordered）②无重复对象（set）③有重复对象（bag）④列表（list）或序列（sequence）⑤只读（readonly）2.泛化（Generalization）①完整（Complete）②不完整（Incomplete）③互斥（Disjoint）④重叠（Overlapping）3.细化（Realization）4.依赖①绑定（Bind）②导出（Derive）③允许（Permit）④实例（InstanceOf）⑤实例化（Instantiate）⑥幂类型（Powertype）⑦精化（Refine）⑧使用（Use）可模型化以下各种关系（1）结构关系1）以数据驱动2）以行为驱动（2）继承关系（3）精化关系（4）依赖关系4.1.3 表达组合信息的术语——包1）访问（Access）2）引入（Import）4.2 UML模型表达格式1.类图（Class Diagram）（1）模型化待建系统的概念（词汇）, 形成类图的基本元素（2）模型化待建系统的各种关系, 形成该系统的初始类图（3）模型化系统中的协作, 给出该系统的最终类图（4）模型化逻辑数据库模式2.用况图（Use Case Diagram）所包含的内容（1）主题（Subject）（2）用况（Use Case）（3）参与者（Actor）（4）关联、泛化与依赖模型化工作1）关于系统/业务语境的模型化①系统边界的确定②参与者与用况的交互③参与者的语义表达④参与者的结构化处理2）关于系统/业务需求的模型化①确定系统/业务的基本用况②用况的结构化处理③用况的语义表达3.状态图（1）状态1）名字2）进入/退出效应（Effect）①entry②exit③状态内部转移3）do动作或活动4）被延迟的事件（2）事件1）信号（Signal）事件2）调用（Call）事件3）时间事件4）变化事件（3）状态转移①源状态②转移触发器③监护（guard）条件④效应（effect）⑤目标状态实际应用中, 使用状态图的作用①创建一个系统的动态模型②创建一个场景的模型4.顺序图（1）术语解析1）消息2）对象生命线3）聚焦控制（the Focus of Control）（2）控制操作子1）选择执行操作子（Operator for Optional Execution）2）条件执行操作子（Operator for Conditional Execution）3）并发执行操作子（Operator for Parallel Execution）4）迭代执行操作子（Operator for Iterative Execution）4.3 本章小结第五章面向对象方法——RUP5.1 RUP特点1.以用况为驱动2.以体系结构为中心3.迭代增量式开发5.2 核心工作流5.2.1 需求获取1.列出候选需求2.理解系统语境（1）业务用况模型（2）业务对象模型3.捕获系统功能需求（1）活动1: 发现并描述参与者（2）活动2: 发现并描述用况（3）活动3: 确定用况的优先级（Priority）（4）活动4: 精化用况（5）活动5: 构造用户界面原型1）用户界面的逻辑设计2）物理用户界面的设计3）开发用户界面原型并演示为了执行该用况, 用户怎样使用该系统（6）活动6: 用况模型的结构化5.2.2 需求分析1.基本术语（1）分析类（Analysis Class）1）边界类（Boundary Classes）2）实体类（Entity Classes）3）控制类（Control Classes）（2）用况细化（Use Case Realization）（3）分析包（Analysis Package）2.分析模型的表达3.分析的主要活动（1）活动1: 体系结构分析（Architectural Analysis）1）任务1: 标识分析包2）任务2: 处理分析包之间的共性3）任务3: 标识服务包4）任务4: 定义分析包的依赖5）任务5: 标识重要的实体类6）任务6: 标识分析包和重要实体类的公共特性需求（2）活动2: 用况分析1）任务1: 标识分析类①标识实体类②标识边界类③标识控制类2）任务2: 描述分析（类）对象之间的交互（3）活动3: 类的分析1）任务1: 标识责任2）任务2: 标识属性①关于实体类属性的标识②关于边界类属性的标识③关于控制类属性的标识3）任务3: 标识关联和聚合①关于关联的标识②关于聚合的标识③关于泛化的标识（4）活动4: 包的分析4.小结（1）关于分析模型1）分析包2）分析类3）用况细化（2）关于分析模型视角下的体系结构描述（3）用况模型和分析模型比较（4）分析模型对以后工作的影响1）对设计中子系统的影响2）对设计类的影响3）对用况细化[设计]的影响5.2.3 设计1.设计层的术语（1）设计类（Design Class）（2）用况细化[设计]（3）设计子系统（4）接口（Interface）2.设计模型、部署模型以及相关视角下的体系结构描述（1）设计模型及其视角下的体系结构描述1）子系统结构2）对体系结构有意义的设计类3）对体系结构有意义的用况细化[设计]（2）部署模型及该模型视角下的体系结构描述3设计的主要活动（1）活动1: 体系结构的设计1）任务1: 标识节点和它们的网络配置2）任务2: 标识子系统和它们的接口①标识应用子系统②标识中间件和系统软件子系统③定义子系统依赖④标识子系统接口3）任务3: 标识在体系结构方面有意义的设计类和它们的接口4）任务4: 标识一般性的设计机制①标识处理透明对象分布的设计机制②标识事务管理的设计机制（2）活动2: 用况的设计1）标识参与用况细化的设计类2）标识参与用况细化的子系统和接口（3）活动3: 类的设计1）任务1: 概括描述设计类2）任务2: 标识操作3）任务3: 标识属性4）任务4: 标识关联和聚合5）任务5: 标识泛化6）任务6: 描述方法7）任务7: 描述状态（4）活动4: 子系统的设计1）任务1: 维护子系统依赖2）任务2: 维护子系统所提供的接口3）任务3: 维护子系统内容4.RUP设计小结1）RUP设计的突出特点2）关于RUP的设计方法①给出用于表达设计模型中基本成分的4个术语, 包括子系统, 设计类, 接口, 用况细化[设计]②规约了设计模型的语法, 指导模型的表达③给出了创建设计模型的过程以及相应的指导3）RUP的设计模型①设计子系统和服务子系统②设计类（其中包括一些主动类）, 以及他们具有的操作、属性、关系及其实现需求。
第8章软件工程（授课2学时）内容提要本章对软件工程中相关的概念和内容作介绍。
通过本章学习应理解软件工程和软件生存期的含义，了解软件开发的工程化方法，知道软件开发的瀑布模型、渐增模型、演化模型、螺旋模型、喷泉模型和智能模型。
了解软件开发的工程化方法，特别应对面向对象方法和软件复用技术有比较深入的了解。
了解软件过程工程和过程改进的概念，特别应对软件能力成熟度模型有比较深入的了解。
教学目标：理解软件工程和软件生存期的含义，了解软件开发的工程化方法，特别应对面向对象方法和软件复用技术有比较深入的了解。
了解软件过程工程和过程改进的概念，特别应对软件能力成熟度模型有比较深入的了解。
教学内容：8.1软件工程的概念教学要求：理解软件工程和软件生存期的含义重点：什么是软件工程难点：软件生存周期教学设计：讲解。
结合一个软件开发的实例讲解。
8.1.1为什么提出软件工程20世纪60年代，国外在开发一些大型软件系统时，遇到了许多困难：❖有些系统最终彻底失败了❖有些系统虽然完成了，但比原定计划推迟了好几年，而且费用大大超过了预算；❖有些系统未能圆满地符合用户当初的期望；❖有些系统则无法进行修改维护。
这是由于大型软件系统大大增加了软件复杂性，软件规模的增加使技术复杂性和管理复杂性呈指数上升。
20世纪60年代末期所发生的软件危机，体现在软件可靠性没有保障、软件维护费用不断上升、进度无法预测、成本增长无法控制、程序人员无限度地增加等各个方面，以致形成人们难以控制软件开发的局面。
软件开发工程化的概念和方法应运而生。
8.1.2什么是软件工程软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
是应用计算机科学、数学及管理科学等原理,借鉴传统工程的原则、方法来创建软件,从而达到提高质量、降低成本的目的。
其中计算机科学和数学用于构造模型、分析算法，工程科学用于制定规范、明确样例、评估成本、确定权衡，管理科学用于进度、资源、质量、成本等的管理。
8.1.3软件生存周期是一个从用户需求开始，经过开发、交付使用，在使用中不断地增补修订，直至让位于新的软件的全过程，是指软件产品从考虑其概念开始，到该软件产品不再能使用为止的整个时期。
一般包括：概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装阶段以及交付使用阶段、运行阶段和维护阶段。
8.2软件开发模型教学要求：了解软件开发模型重点：瀑布模型、渐增模型难点：瀑布模型、渐增模型教学设计：结合软件开发实例讲解8.2.1瀑布模型瀑布模型(Waterfall Model)是1970年Winston Royce提出的最早出现的软件开发模型。
它将软件开发过程中的各项活动规定为依固定顺序连接的若干阶段工作，形如瀑布流水，最终得到软件系统或软件产品。
制定计划、需求分析和定义、软件设计、程序编写、软件测试、运行和维护6个步骤见。
8.2.2渐增模型渐增模型(Incremental Model)亦称有计划的产品改进型，它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。
第一个中间版本纳入一部分需求，下一个中间版本纳入更多的需求，依此类推，直到系统完成。
每个中间版本都要执行必要的过程、活动和任务。
这种模型在开发每个中间版本时，开发过程中的活动和任务顺序地或部分平行地使用。
当相继中间版本在部分并行开发时，开发过程中的活动和任务可以在各中间版本间平行地采用。
8.2.3演化模型演化模型(Evolutionary Model)主要针对事先不能完整定义需求的软件项目开发。
许多软件开发项目由于人们对软件需求的认识模糊，很难一次开发成功，返工再开发难以避免。
为此，人们对需开发的软件给出基本需求，作第一次试验开发，其目标仅在于探索可行性和弄清需求，取得有效的反馈信息，以支持软件的最终设计和实现。
通常把第一次试验性开发出的软件称为原型(prototype)。
❖“丢弃型”方式为当原型开发后，已获得了更为清晰的需求反馈信息，原型无需保留而丢弃，开发的原型仅以演示为目的，这往往用在软件的用户界面的开发上；❖“样品型”方式为原型规模与最终产品相似，只是原型仅供研究用；❖“渐增式演化型”把原型作为最终产品的一部分，它可满足用户的部分需求，经用户试用后提出精化系统、增强系统能力的需求，开发人员根据反馈信息，实施开发的迭代过程。
8.2.4螺旋模型螺旋模型(Spiral Model)是由TRW公司的Barry Boehm于1988年提出的，它将瀑布模型和演化模型等结合起来，并且强调了其他模型均忽略了的风险分析。
螺旋模型更适合于大型软件的开发，应该说它对于具有高度风险的大型复杂软件系统的开发是较为实际的方法。
该模型通常用来指导大型软件项目的开发，它将开发划分为制订计划、风险分析、实施开发和客户评估4类活动。
沿着螺旋线每转一圈，表示开发出一个更完善的新的软件版本。
如果开发风险过大，开发机构和客户无法接受，项目有可能就此终止。
多数情况下，会沿着螺旋线继续下去，自内向外逐步延伸，最终得到满意的软件产品。
8.2.5喷泉模型喷泉模型（Fountain Model)是由B．H．Sollers和J．M．Edwards于1990年提出的一种新开发模型。
喷泉模型主要用于采用对象技术的软件开发项目，喷泉一词本身就体现了迭代和无间隙的特性。
软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。
无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限。
由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。
8.2.6转换模型转换模型是用形式化的方法自动生成程序，转换的主要步骤为❖采用形式化的规格说明书。
❖通过自动系统自动地变换成代码。
❖必要时做一些优化，改进性能。
❖交付用户使用。
❖根据使用的经验来调整形式化的规格说明书。
返回第一步重复整个过程。
转换模型的优点是解决了代码结构经多次修改而变坏的问题；减少了许多中间步骤，如设计、编码、测试等等，是软件自动生产的有意义的尝试。
但是，转换模型仍有较大局限。
8.2.7智能模型智能模型(Intelligent Model)也称为基于知识的软件开发模型，它是知识工程与软件工程在开发模型上结合的产物；它有别于上述的几种开发模型，并可协助软件开发人员完成开发工作。
8.3软件开发方法教学要求：理解软件开发方法的含义重点：结构化方法难点：面向对象方法教学设计：结合学生正在学习的C/C++语言程序设计讲解。
8.3.1模块化方法模块化方法（Modular Method）是把一个待开发的软件分解成若干较为简单的部分，称为模块(modules)，每个模块分别独立地开发、测试，最后再组装出整个软件。
这种开发方法是对待复杂事物的“分而治之”的一般原则在软件工程领域的具体体现，即将软件开发的复杂性在分解过程中降低。
把系统分解成模块，应遵循以下规则：（1）在一个模块内部体现最大程度的关联，只实现单一功能的模块具有这种特性。
（2）最低的耦合度，即不同的模块之间的关系尽可能弱。
（3）模块的层次不能过深，一般应尽量控制在7层以内。
（4）接口清晰、信息隐蔽性好。
（5）模块大小适度。
（6）尽量采用已有的模块，提高模块复用率。
8.3.2结构化方法结构化方法是强调结构的合理性以及所开发的软件的结构合理性，由此提出了一组提高软件结构合理性的准则，如分解和抽象、模块的独立性、信息隐蔽等。
针对不同的开发活动，它有结构化分析、结构化设计、结构化编程和结构化测试。
结构化分析方法给出一组产生功能规约的原理和技术，利用图形表示用户需求，以数据流图和控制流图为基础，伴以数据词典，并配上结构化语言、判定表和判定树等等手段，达到为问题的解决建立模型。
结构化分析的步骤：❖分析当前情况，作出反映当前物理模型的数据流图。
❖推导出等价的逻辑模型的数据流图。
❖设计新的逻辑系统，生成数据词典和基元描述。
❖建立人机接口界面，提出可供选择的目标系统的物理模型数据流图。
❖确定各种方案的成本和风险等级，据此对各种方案进行分析❖选择一种方案。
❖建立完整的需求规约。
8.3.3面向数据结构方法面向数据结构方法是结构化方法的变形，它注重数据结构而不是数据流。
结构化方法以分析信息流为主，用数据流图来表示信息流；面向数据结构方法，是从数据结构方面分析，即分析信息结构，并用数据结构图(特指该类方法所用的图形描述工具，如Jackson结构图、Warnier图)来表示，再在此基础上进行需求分析，导出软件的结构。
面向数据结构的开发方法包括分析和设计活动。
由于一些应用领域的信息都有层次分明的信息结构，如输入数据、内部存储数据和输出数据都有层次性，因此在分析活动时可以用数据结构来分析和表示问题的信息域，在设计活动时，不同性质的数据结构可以用具有相应的控制结构的程序来处理。
面向数据结构方法有Warnier法、Jackson法以及DSSD(数据结构系统开发)方法等。
8.3.4面向对象方法在软件开发过程中把面向对象的思想运用其中并指导开发活动的系统方法，称为面向对象方法(Object Oriented Method)，简称OO方法。
对象是由数据和容许的操作组成的封装体，与客观实体有直接的对应关系。
所谓面向对象就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。
用面向对象方法开发的软件，其结构基于客观世界界定的对象结构，因此与传统的软件相比较，软件本身的内容结构发生了质的变化，其易复用性和易扩充性都得到了提高，而且能支持需求的变化。
面向对象设计具体设计步骤如下：1.应用面向对象分析对用其他方法得到的系统分析的结果进行改进和完善。
2.设计交互过程和用户接口。
包括描述用户及任务并根据需要分成子系统、把交互作用设计成类、设计命令层次、设计交互作用过程及接口并用相应符号系统表示。
3.设计任务管理。
包括根据前一步骤确定是否需要多重任务、确定并发性、确定以何种方式驱动任务、设计子系统及任务之间的协调与通信方式、确定优先级。
4.设计全局资源协调。
包括确定边界条件、确定任务或子系统的软、硬件分配。
5.设计类等。
包括各个类的存储和数据格式、设计实现类所需的算法、将属性和服务加入到各个类的存储对象中、设计对象库或数据库。
8.3.5统一建模语言由于国际上出现了多种面向对象的方法，每种方法都有自己的表示法、过程和工具，甚至各种方法所使用的术语也不尽相同。
这一现状导致开发人员经常为选择何种面向对象方法而争论，但是每种方法都各有短长，很难找到一个最佳答案，UML的初衷是结束面向对象领域中的方法大战，形成了大家公认的一套建模方法。
