软件设计与设计工程

1. 软件设计与设计工程 王林章，陈鑫，张天 软件工程组 南京大学计算机科学与技术系 lzwang@nju.edu.cn http://sec.nju.edu.cn/ Software Engineering Group

2. 软件问题回顾 Software Engineering Group

3. 解决问题的思路 Software Engineering Group

4. 回顾 Software Engineering Group

5. 回顾 • 软件需求分析的成果 • 需求分析规约 • 分析模型 • 功能 • 行为 Software Engineering Group

6. 回顾 • 程序设计的任务和内容 • 算法 • 数据结构 • ？ Software Engineering Group

7. 回顾 Software Engineering Group

8. 提纲 • 软件设计概述 • 软件设计任务 • 软件设计方法 • 软件设计过程 • 软件设计规约与文档化 • 软件设计规约分析与验证 • 软件设计与建模管理与工具 Software Engineering Group

9. 软件设计概述 • 软件设计 • 软件设计原则 • 软件设计相关概念 Software Engineering Group

10. 软件设计概述 • 软件需求分析解决“做什么”的问题，软件设计过程则解决“怎么做”的问题 • 软件设计是把软件需求变换成软件表示的过程 • 软件设计的优劣在根本上决定了软件系统的质量。 • 软件设计 • 创造性活动 • 关联点：用户需求、商业需求、技术考虑 • 设计空间： • 表达软件数据结构、架构、接口、组件、配置 Software Engineering Group

11. 软件设计原则 • 设计可以追溯到分析模型 • 关注待建系统的架构 • 数据设计与功能设计的同等重要性 • 设计接口 • 界面设计需要符合用户需求 • 模块化 • 组件化 • 组件间、组件与外部系统间的松耦合 • 设计文档及模型的易理解 • 迭代式增量设计 • 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。 Software Engineering Group

12. 设计概念 • 抽象 • 信息隐藏 • 封装 • 模块化 • 软件体系架构（风格） • （设计）模式 • 组件 • 精化 • 建模 Software Engineering Group

13. 抽象 • 抽象是人们用来处理复杂问题的基本原理之一。使用待解决的问题领域内的术语描述的解决方案。 • 抽象有几种形式，如数据抽象、对象抽象、实体抽象、行为抽象、过程抽象等。 • 数据、实体的抽象使得软件操作的对象和参数是针对逻辑结构，而非存储结构。 • 行为、过程的抽象使得操作的指派是依据标识而非地址，由此产生了操作的接口和动态约束描述。 • 在处理系统复杂性方面，抽象起到了重要的作用。减少组件耦合、接口与实现的分离等，都得益于抽象。

14. 信息隐藏 • 信息隐藏是软件工程的最基本和最重要的原理之一。 • 信息隐藏对用户隐藏了组件的实现细节，用来更好地处理系统的复杂性和减少各组件之间的耦合。 • 为了更好地应用，用户不需要知道的细节都应该由组件封装起来。 • 封装原理经常被用来作为实现信息隐藏的方法，信息隐藏也可以通过接口与实现分离的原理来实现 Software Engineering Group

15. 封装 • OOD：封装是一种重要的机制。所谓对象的概念就是属性（数据）及其操作（行为）的封装体。 • SD：封装在函数和子程序当中也得到了体现。封装有利于提高抽象的层次，有利于结构和实现的分离，最终提高了软件的可维护性、可重用性和可靠性。 Software Engineering Group

16. 模块化 • 模块化主要关心的是如何将一个软件系统分解成子系统和组件，其主要任务就是决定怎样将构成应用的逻辑结构物理地分割成代码实体。模块化的主要做法，就是在一个系统内引入具有良好定义的分界，依次来处理系统的复杂性。模块化与封装原理的联系非常密切。模块化带来了复杂系统资源管理、维护和应用的逻辑和条理性，增加了应用设计的灵活性。另外，它对于系统的运行设计和管理调度也提供了方便。 Software Engineering Group

17. 软件体系架构 • 软件体系架构是具有一定形式的结构化元素，即组件的集合，包括处理组件、数据组件和连接组件。 • 对子系统、软件系统组件以及他们之间关系的描述。 • 体系架构 = 组件 + 连接（件） + 设计约束 • 子系统和组件一般定义在不同的视图内，以显示软件系统的相关功能属性和非功能属性。 • 对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已变得明显重要得多 • 软件体系架构模式 • 管道过滤器；MVC；代理者；层；MDA，SOA… Software Engineering Group

18. 软件体系架构 • 复用 • 分工 • 市场竞争 工程化开发方法和工业化生产技术 • 从传统工业借鉴方法和技术 • 基于标准化组件的生产技术 • 汽车生产：汽车零件 • 建筑工程：建筑材料 • …… • 第三方提供 vs. 自身积累 • 汽车轮胎 ……变速箱总成 Software Architecture

19. 软件体系架构 P2P技术原理 移动Agent技术 XML/SOAP/ WSDL/SOAP/BPEL Model-driven Architecture RPC、RMI CORBA 语言、工具 软件设计 Component P2P/Agent SOA/MDA Cloud ADL/Arch Studio EJB Cloud Computing 物联网 Client-Server Broker 3-tiers JSP JBoss Implicit Invocation MVC Java AWT .NET Delegation MS .NET 现场演示 Layer Pipe and Filter Blackboard 基本概念 微内核、插件 动态代理、JEE支撑 Architectural View Architectural Pattern 网络互连技术 协议堆栈设计 人工智能系统 一般程序框架 Unix管道 Axis架构 Introduction and Concepts Software Architecture

20. 设计模式 • 对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案 • 设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免会引起麻烦的紧耦合，以增强软件设计面对并适应变化的能力。 • 设计模式 • 桥接模式；Abstract Factory模式；命令模式；Decorator模式；。。。。 • 算法能不能算是一种设计模式？ Software Engineering Group

21. 组件 • 功能独立的系统单元、模块化的构造块 • 组件（component) • 组件可以理解为软件系统的一个组成部分。 • 组件通过一定接口组成复杂的软件系统。 • 从系统构成角度：在系统运行中承担一定功能、发挥一定作用的软件体 • 从程序设计角度：模块、类、对象、函数或者一个相关功能集合 • 基于组件的软件开发已成为一种软件开发范型 • 不同和无关联的责任应该在软件系统中分离开来，让它们出现在不同的组件中。 • 相互协作完成某一个特定任务的组件应该和其他任务中执行计算的组件分离开来。 • 如果一个组件在不同的环境下扮演不同的角色，在组件中这些角色应该独立且相互分离。 • 接口和实现的分离 • 软件复用的基础 • 通过复用已有的组件，软件开发者可以“即插即用”地快速构造应用软件 Software Engineering Group

22. 软件组件 定义 • “一个非平凡的、几乎独立的、可替换的系统组成部分，它在定义完善的体系架构环境中实现某一清晰的功能”(a nontrivial, nearly independent, and replaceable part of a system that fulfils a clear function in the context of a well defined architecture) --Brown & Wallnau • “组件是一个独立部署的的单元，是一个第三方合成的单元，组件没有持久性状态”（A component is a unit of independent deployment .A component is a unit of third-party composition. A component has no persistent state） -- Clemens Software Architecture

23. 软件组件 Software Architecture 主流组件模型和平台 • OMG: CORBA • SUN: EJB • Microsoft: COM/DCOM

24. 软件组件 软件自身特点所带来的问题 • 复用 • 不完全一致的使用场景 • 分工 • 难以完全解除的组件耦合 • 市场竞争 • 不能沿用物质产品的盈利模式 基于组件的软件开发 • 一直未曾完全实现的老想法 • 影响因素不仅限于技术层面

25. 精化 • 自定向下的设计策略 • 从需求到设计过程中逐步细化 • 抽象与精化互补 Software Engineering Group

26. 耦合和内聚 • 耦合和内聚最初是作为结构化设计方法的部分原理而提出的。 • 耦合强调模块之间的特性，而内聚强调模块内部的特性。耦合是用来衡量一个模块同另一个模块的联系的紧密程度的。紧密的耦合就会使系统变得复杂，因为如果一个模块和另外的模块有很密切关联的话，这个模块就很难理解、调试、维护。通过弱耦合组件的设计可以降低系统的复杂性。 • 内聚用来衡量单一模块内功能和元素间联系的紧密程度。内聚有几种形式，最期望获得的是功能内聚，它说明一个模块或者组件内的所有元素都共同来完成具有良好边界的行为。最差的形式是偶然内聚，这种形式将毫无联系的抽象放置到同一模块之中。其他形式的内聚还有：偶然内聚、时间内聚、过程内聚、通信内聚、顺序内聚和不规则内聚。 Software Engineering Group

27. 建模 • 建模：更好地理解待建系统 • 结构化建模 • OO建模 • 分析模型：表示用户需求 • 信息域 • 功能 • 行为 • 设计模型：表示软件的特性以帮助实现人员构造系统 • 数据设计 • 架构设计 • 组件设计 • 接口设计

28. 软件设计任务 • 使用一种设计方法，软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段 • 产生数据/类设计 • 体系架构设计 • 接口设计 • 组件级设计。 • 从工程管理的角度来看，软件设计分步骤、分不同方面完成，产生软件设计规约 • 概要设计＋详细设计 • 结构模型＋行为模型 Software Engineering Group

29. 软件设计任务 • 使用分析模型，选择合适的架构风格和模式 • 把分析模型划分成若干设计子系统并按架构分配到各子系统中 • 确定子系统的功能耦合性 • 设计子系统接口 • 把分析的类或功能成功分配到各子系统中 • 使用信息域模型，设计合适的数据结构 • 设计用户界面 • 组件级设计 • 在较低抽象级别上确定所有的算法 • 精化组件接口 • 定义组件级数据结构 • 开发部署模型 Software Engineering Group

30. 软件设计方法 • 结构化设计方法 • 将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段。 • 结构化设计方法给出一组帮助设计人员在模块层次上区分设计质量的原理与技术。它把系统作为一系列数据流的转换，输入数据被转换为期望的输出值，通过模块化来完成自定而下实现的文档化，并作为一种评价标准在软件设计中起指导性作用，通常与结构化分析方法衔接起来使用，以数据流图为基础得到软件的模块结构。 Software Engineering Group

31. 软件设计方法 • 面向对象设计方法 • OOA－OOD－OOP • 采用面向对象的思想对软件系统进行设计 Software Engineering Group

32. 软件设计建模 • SDM： • 流程图 • 方块图 • PAD图 • OOM：UML模型 • 结构模型 • 行为模型 Software Engineering Group

33. 软件设计过程 • 制定规范 • 为软件开发组制定在设计时应共同遵守的标准。 • 软件体系架构设计 • 组件设计 • 接口／界面设计 • 数据/类设计 • 编写设计文档 • 设计评审 Software Engineering Group

34. 软件设计规约与文档化 • 软件设计说明书 • 程序开发人员的依据 • 文档标准与模板 Software Engineering Group

35. 软件设计规约分析与验证 • 质量指导原则 • 评估设计质量 • 质量属性FURPS • 功能性 (Functionality) • 易用性（Usability） • 可靠性（Reliability） • 性能（Performance） • 可支持性（Supportability） Software Engineering Group

36. 软件设计规约分析与验证 • 评估设计质量的方法 • 自动化（形式）验证 • 检查（Inspection） • 正式复审（Review） • 走查（Walk Through） Software Engineering Group

37. 软件设计规约分析与验证 设计的检查 • 检查具有正规的复审和非正规的复审两方面的特点； • 从复审的形式与内容上看，检查方法是相当正规的--有专门的职责、活动安排、交付的文档、核对表以及管理办法等等，一切都是事先规定好的； • 然而，涉及到的人员以及他们的相互联系则是比较随便的，通常都以小组进行活动。 Software Engineering Group

38. 软件设计规约分析与验证 设计的复审 • 软件的设计由管理方面的代表、技术开发方面的代表和其他有关人员（诸如用户、质量保障和软件支持者等）共同进行复审。 • 对设计进行复审的明显好处是可以比较早地发现软件的缺陷，从而可以使每个缺陷在进行编程、测试和交付之前予以纠正，从而显著地降低随后的开发阶段和维护阶段的费用。 • 设计复审包括正规的审查、非正规的审查和检查三种方式。 Software Engineering Group

39. 软件设计规约分析与验证 • 设计复审的标准 • 易追溯性： 该软件设计包括了软件需求规格说明的所有要求了吗？该软件的每个组件与某个具体的软件要求有关吗？ • 风险：实现该设计会有很大风险吗？也就是说，没有技术性的突破该设计也能完成吗？ • 实用性：该软件对软件要求所确定的问题是一种实用的解决办法吗？ • 易维护性：该设计是否将导致一个便于维护的系统？ • 质量：该设计具备一个“好”的软件应有的质量特征吗？ • 接口：外部和内部的接口已经规定得足够明确了吗？ • 技术清晰度：该设计的表达方式是否使它便于转化成程序？ • 选择方案：考虑了其他设计方案了吗？采用什么标准来选择最后方案呢？ • 限制：软件限制是否现实？与要求相符合吗？ • 某些具体的问题：该软件便于人控制机器吗？便于测试吗？与其他系统部分相适应吗？有足够的文档吗？ Software Engineering Group

40. 软件设计规约分析与验证 • 正规的复审 • 通常是为了评价软件的结构和接口； • 这种类型的复审的特点在于：设计人员和复审人员都要认真的准备；有相当多的复审者参加，他们对该软件研制项目有不同程度的兴趣； • 管理方面和技术方面站得高，视野开阔； • 提供正式的设计文档； • 由通知到开会的时间间隔至少有两个星期。 Software Engineering Group

41. 软件设计规约分析与验证 • 非正规的复审 所谓非正规的复审指的是从临时通知的碰头会到有关同事参加的比较有组织的复审这整个范围而言的，一般由通知到开会的时间间隔只有二至三天。 Software Engineering Group

42. 软件设计规约分析与验证 • 软件设计评审检查单 • ？？ Software Engineering Group

43. 软件设计与建模管理与工具 • 建模工具 • VISIO • RSA • 管理工具 • RTC Software Engineering Group

44. 小结 • 软件设计工程 • 过程 • 软件设计方法 • 结构化设计／建模方法 • 面向对象设计／建模方法 • 工具 Software Engineering Group