Article June 12, 2019

软件工程导论

Words count 25k Reading time 22 mins. Read count 0

软件的定义

  • 程序:通过执行包含在程序中的指令可以满足预期的特征、功能和性能需求
  • 数据结构:使得程序充分利用信息
  • 文档:描述程序的操作和使用

软件的特征


The changing nature of software


软件和硬件的区别

  • 软件是设计开发的,而不是传统意义上生产制造的
  • 软件不会磨损,但是会退化
  • 大多数的软件还是主要采用用户定制的方式

软件工程

  • 将系统化、规范化、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应用于软件。
  • 2对1中所述方法的研究。

软件工程的目标

解决软件危机(the difficulty of writing useful and efficient computer programs in the required time.)

软件工程的层次

软件工程是一种层次化的技术:

  • 工具:为过程和方法提供自动化或半自动化的支持。
  • 方法:建造软件提供技术上的解决方法,包括沟通、需求分析、设计建模、编程、测试和支持。
  • 过程(基础):软件过程将各个层次的技术结合在一起,并实施合理地、及时地开发计算机软件。
  • 质量关注点(根基)

过程框架的五个基本活动

  • 沟通
  • 策划
  • 建模:包括分析(analysis)和设计(design)两个动作
  • 构建
  • 部署

stakeholder(共利益者)

就是可在项目成功中分享利益的人,包括业务经理、最终用户、软 件工程师、支持人员等。

软件神话


过程模型的作用


瀑布模型

是一种基于软件生存周期的线性开发模型。它提出了一个系统的、顺序(sequential)的软件开发方法,从用户需求规格说明开始,通过策划、建模、构件和部署的过程,最终提供一个完整的软件并提供持续的技术支持。

  • 适用于需求定义清晰、熟悉的软件开发

缺点:

  • 实际的项目很少遵守瀑布模型提出的顺序。
  • 用户常难以清楚地描述所有的需求。
  • 客户必须要有耐心,只有在项目接近尾声的时候,他们才能得到可执行的程序。

V模型


增量模型(适用于周期短的项目)

以迭代的方式运用瀑布模型,在每个阶段运用线性序列。这种模型把软件看作是一系列相互联系的增量,在开发过程的各次迭代中,每次完成其中的一个增量。
优点:

  • 早期的增量可以由少量人员实现
  • 可以规避技术风险

RAD模型

是一种侧重于短暂的开发周期的增量过程模型,为大型且必须在严格的时间内提交的项目而设计的。
是瀑布模型的高速变体,通过基于构件的构建方法实现快速开发。
缺点:

  • 大量人力资源
  • 技术风险高时不适合
  • 需求高性能不适合

演化过程模型(evolutionary process model)

每次迭代产生软件的一个更完整的版本。

原型开发(prototyping 用于需求很模糊的时候)

先建立一个能够放映用户主要需求的原型,让用户实际看一下未来系统的面貌,以便判断哪些功能是符合需要的,哪些方面还需要改进,然后将原型反复改进, 直至建立完全符合用户要求的新系统。

螺旋模型(spiral)

  • 采用循环的方式逐步加深系统定义和实现的深度
  • 确定一系列里程碑,确保利益相关者都支持可行的系统解决方案

早期迭代中,软件可能是一个理论模型或者原型,在后期迭代中产生一系列逐渐完整的系统版本

专用过程模型(应用较窄,只适合于某些特定的软件工程方法)

基于构件的开发

本质上是演化模型,需要以迭代方式构建软件。the process to apply when reuse is development objective。

形式化方法模型

主要活动是生成计算机软件形式化的数学规格说明,意义在于提供无缺陷的软件。

面向方面的软件开发(AOSD)

以用户跨越多个系统功能、特性和信息为关注点。

统一过程

是一种增量模型,定义了五个阶段

  1. 起始(inception):包括客户沟通和策划活动,强调定义和细化用例,并将其作为主要模型
  2. 细化(elaboration):包括用户沟通和建模活动,重点是创建分析和设计模型,强调类的 定义和体系结构的表示
  3. 构建(construction):细化设计模型,并将设计模型转化为软件构件实现
  4. 转换(translation):将软件从开发人员传递给最终用户,并由用户完成 Beta 测试和验收
    测试
  5. 生产(production):持续地监控软件的运行,并提供技术支持

敏捷

敏捷软件工程是哲学理念和一系列开发指南的综合。
这种哲学理念推崇

  • 让客户满意和软件的早期增量发布;
  • 小而高度自主的项目团队;
  • 非正式的方法;
  • 最小化软件工程工作产品以及整体精简开发。

敏捷过程

XP 极限编程

  • XP 使用面向对象方法作为推荐的开发范型
  • 四个框架活动:
    • 计划(始于建立一系列描述待开发软件必要特征与功能的故事)
    • 设计(遵循 kis 原则(Keep-it-simple);鼓励使用 CRC 作为有效机制;如果在某个故事设计中碰到困难,实现并评估原型。XP 估计既是构建技术又是设计中的重构)
    • 编码(关键概念之一是结对编程,即两个人面对同一台计算机为同一个故事开发代码)
    • 测试(在编码之前建立单元测试。XP 验收测试由客户确定)

重构

是以不改变代码外部行为而进行改进其内部结构的方式来修改软件系统的过程。
简而言之,重构是在编码完成之后改进代码设计。

SCRUM

一种敏捷过程模型

  • Backlog(待定项):一个能为用户提供商业价值的项目需求或特征的优先级列表项目中待完成的工作列表
  • Sprints (冲刺):一次迭代开发的时间周期
  • 十五分钟例会回答的基本问题:
    A.上次例会之后做了什么 B.遇到什么困难 C.下次例会之前做些什么

DSDM(动态系统开发方法)

是一种敏捷软件开发方法

  • DSDM 建议使用修改版 Pareto 原则,在这种情况下,如果交付整个应用系统需用 100%时
    间,那么80%的应用系统可以用20%的时间交付。
  • DSDM 建议使用迭代软件过程。

需求工程

RE是 design 和 construction 的桥梁。
目的:在设计和构造之间建立起联系的桥梁
任务:启始、导出、细化、协商、规格说明、确认和管理

需求工程通过执行 7 个不同的活动来完成:

  1. Inception(起始)
  2. Elicitation (导出)
    导出需求的困难:范围、理解、易变的问题
  3. elaboration(细化)
  4. negotiation(谈判)
  5. specification(规格说明)
  6. validation(确认)
  7. management(管理)

Use-case

产生了一个参与者与系统的交互。从参与者的角度定义用例,用例从最后用户的角度描述了软件或系统。
参与者(Actor)是人员或设备在和软件交互时所扮演的角色。 Stakeholder可以访问每个用例而且可 以指定每个用例的相对优先级。

需求建模

需求分析

需求分析向软件设计者提供信息(information)、功能(function)和行为(behavior)的表示
这些表示可以被转化为结构(architectural)、接口(interface)和构件级(component-level)的设计

分析模型 方法

  1. 结构化分析(structure analysis):是一种考虑数据和处理的分析建模方法,数据作为独立的实体转换。数据对象建模定义了对象的属性和关系,操作数据对象的处理建模应表明当数据对 象在系统内流动时处理如何转换数据。
  2. 面向对象分析(objected-oriented analysis):就是检查定义为一组用例的问题域,尽量提取定义问题的类。关注于定义类和影响客户需求的类之间的协作方式。UML和统一过程主要是面对对象的。

WIN-WIN

好的谈判力争双赢。
顾客获得满足大多数需求的系统或产品,软件开发团队按照实际情况,在可实现的预算和时间期限内完成工作

数据建模

  • data objects(数据对象):
    数据对象是任何必须被软件理解的复合信息的表示只封装数据,在数据对象内没有任何对数据操作的引用。
  • data attribute(数据属性)定义了数据对象的性质
  • relationship(关系)指明数据对象相互连接的方式
  • ERD 的三个元素:attributes、object、relationship。ERD 主要目的是表示数据对象和它们之间的关系。

  • 数据字典:是对于数据模型中的数据对象或者项目的描述的集合。

基于场景的建模

使用UML需求建模,从开发用例、活动图和泳道图形式的场景开始

面向对象系统中重要的特征

  1. 封装(encapsulation)
  2. 继承(inheritance)
  3. 多态(polymorphism)

信息隐藏(Information Hiding)

这是把系统分解为模块时的思想,即模块内部的数据与过程,应该对不需要了解这些数据与过程的模块隐藏起来。只有为了完成软件的总体功能而必 须在模块间交换的信息,才允许在模块间进行传递。模块应该详细说明且精心设计以求在某个 模块中包含的信息(算法和数据)不被不需要这些信息的其他模块访问。

Behavioral model

  1. 系统状态可以表现特定的外部可观察(externally observable)行为。
  2. 类的状态可以表现当系统执行功能时的行为。

cohesion & coupling

  • 内聚显示了某个模块相关功能的强度。
    内聚程度越高,模块越容易被实现、测试和维护
  • coupling:显示了模块间的相互依赖性。

应当尽量高内聚、低耦合

CRC模型

类-职责-协作者建模可以识别和组织与系统或产品需求相关的类,可以用于定义类之间的联系。

分析包

分析包(package)包括将分析模型元素分类为有用的分组。
包用于组装相关类的集合。

类间关系

设计概念

  • 抽象(abastraction):
  • 体系结构(architecture):软件的整体结构和这种结构为系统提供概念完整性的方式。
  • 模式(patterns):每个设计模式的目的都是提供一个描述,使得设计人员能够确定:模式是否适用于现在的工作,模式能否复用,模式是否能够指导类似模式
  • 求精(refinement):通过连续精化过程细节层次来实现程序开发,通过逐步分解功能的宏观陈述直至形成程序设计语言的语句来实现层次开发。
  • 模块化(modularity):软件划分为独立命名的、可处理的构件。
  • 功能独立(functional independence):开发具有专一功能和避免与其他模块过多交互的模块
  • 设计类(design class):

四种设计

  1. data design
  2. architectural design
  3. interface design
  4. component design

组织良好的设计类的四个特征:

  1. 完整性与充分性
  2. 原始性
  3. 高内聚性
  4. 低耦合性

软件体系结构

一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件,构件外部可见属性以及他们之间的相互关系。
体系结构并非可运行软件。

数据设计的目标

把在分析模型中定义的数据对象转化成软件构件级的数据结构,并且在必要时转化为应用程序级的数据库体系结构。

体系架构设计的复杂性(三种依赖):

  1. sharing dependency(共享依赖):消费者间或生产者间的依赖关系
  2. flow dependency(流依赖):资源的生产者和消费者间的依赖关系
  3. constrained dependency(约束依赖):在一组活动间相关控制流上的约束。

每种风格的体系结构包含:

  1. 完成系统需要的某种功能的一组构件
  2. 能够使构件间实现通信、合作和协作的一组连接件
  3. 定义构件如何集成为系统的约束
  4. 语义模型

构件

在面向对象软件工程观点中,构件包括一个协作类集合。
在传统观点中,一个构件就是程序的一个功能要素,三种角色为:

  1. control component(控制构件)
  2. problem domain component(问题域构件)
  3. infrastructure component(基础设施构件)

构建开发原则

开关原则(OCP):模块应该对外延具有开放性,对修改具有封闭性
优点:无需对构件自身内部做修改就可以进行扩展的方式来说明构件
实现方法:设计者在那些可能需要扩展的功能与设计类本身之间分离出一个缓冲区
LSP、DIP、ISP、REP、CCP、CRP

内聚

不同级别的内聚性:

  • 功能内聚
  • 分层内聚
  • 通信内聚

面向对象构件级设计的步骤

  1. 标识出所有与问题域相对应的设计类
  2. 确定所有与基础设施域相对应的设计类
  3. 细化所有不需要作为可复用构件的设计类
  4. 说明持久数据源并确定管理数据源所需要的类
  5. 开发并细化类或构件的行为表示
  6. 细化部署图以提供额外的实现细节
  7. 考虑每个构件级设计表示,并且时刻考虑其他可选方案

传统构件级设计

传统构件的三种设计表示:

  1. 图形——流程图
  2. 表格——决策表
  3. 文本——PDL

在构件级设计中,面向对象的观点和传统的观点的区别?

  • 面向对象的观点注重细化来自于问题域和基础设施域的设计类
  • 传统的观点则细化三种不同的构建或模块。

用户界面设计的黄金规则

  1. 用户操纵控制
  2. 减少记忆负担
  3. 保持界面一致

用户界面设计分析的四个框架活动:

  1. 用户分析,任务分析,环境分析和建模
  2. 界面设计
  3. 界面构建(implementation)
  4. 见面确认

界面分析的步骤

  1. 用户分析
  2. 任务分析和建模
  3. 显示内容分析
  4. 工作环境分析

界面设计步骤

  1. 定义界面对象和动作
  2. 定义用户动作,并对行为建模
  3. 描述界面状态
  4. 说明用户如何从界面信息解释系统状态

验证与确认

验证:确保软件正确地实现某一特定功能的一系列活动(正确地构造产品吗?)
确认:确保开发的软件可追溯到客户需求的另外一系列活动(构造正确的产品吗?)

测试策略

单元测试

  • 接口
  • 局部数据结构
  • 边界条件:确保模块在达到边界值的极限或受限处理的情形下仍能正确执行
  • 独立路径
  • 错误处理路径

因为构件不是一个独立程序,所以应该为每个单元测试驱动软件或桩软件

集成测试与回归测试

集成测试是构造软件体系结构的系统化技术,同时也是进行一些旨在发现与接口相关的错误的测试。

回归测试

重新执行已测试过的某些子集,以确保变更没有传播不期望的副作用。

为什么说回归测试是集成测试流程中的关键部分?

因为在集成测试策略的环境下,每加入一个新的模块作为测试的一部分时,软件会发生变更,这些变更可能会是使本来可以正常工作的功能产生问题,而回归测试只是重新执行已进行测试的某个子集,以确保变更没有传播不期望的副作用。

确认测试

系统测试

系统测试是对整个系统进行一系列不同考验的测试。所有测试都是为了验证系统成分已经正确地集成在一起,并且完成了指派的功能。

  • 恢复测试
  • 安全测试
  • 压力测试
  • 性能测试
  • 部署测试

测试与调试的关系

  • 测试发现错误,调试诊断错误出现的原因和位置,以便消除错误。
  • 调试出现在成功的测试之后

软件可测试性的特征

可测性(testability)的特征

  1. 可操作性 operability
  2. 可观察性 observability
  3. 可控制性 controllability
  4. 可分解性 decomposability(可划分)
  5. 简单性simplicity
  6. 稳定性 stability
  7. 易理解性 understandability

白盒测试

白盒测试是在了解模块内部结构的情况下进行的测试。
白盒测试集中在程序控制结构上。

基本路径测试

控制结构测试

流图 flow graph

流图是一种简单的控制流表示方法。

  • 边和结点限定的范围称为域
  • 在计算域的数量时,将图的外部区域作为一个域。

独立路径 independent path

独立路径是指任何贯穿程序的、至少引入一组新语句或一个新条件的路径。

黑盒测试

黑盒测试旨在验证功能需求,而不考虑程序的内部工作。

等价类划分

把所有的输入数据划分为若干等价类,并假定:每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。

边界值分析

边界值分析通常在边界值附近设计测试用例

面向对象的测试方法

基于错误的测试

scenario-based testing(基于场景的测试)

是一种面对对象测试方法,意味着捕获用户必须完成的任务,然后在测试时使用它们及其变体。

环路复杂度

$V(G)=E-N+2$ ($E$ 是流图边数,$N$ 是流图节点数)

黑盒测试和白盒测试的比较

SCM 软件配置管理

是一组管理变更的活动,
是应用于整个软件过程的一种普适性活动。

Baseline 基线

已经通过正式评审和批准的规格说明或产品,它可以作为进一步开发的基础,并且只有通过正式的变更控制规程才能修改它。

Software Configuration 软件配置

在软件过程中产生的所有信息项总称为软件配置

Repository 存储库

是一组机制和数据结构,它使软件团队可以有效地管理变更。

SCM Process

  • Identification
  • Change control 变更控制
  • Version control 版本控制
  • Configuration auditing 配置审核
  • Reporting

软件项目管理4P

  1. People
    人员是软件项目的基本要素和关键因素。
  2. Product
  3. Process
    项目团队要选择一个适合于待开发软件的过程模型
  4. Project
    采用科学的方法和工具对项目基本内容进行管理。

风险管理

风险管理就是识别评估风险,建立、选择、管理和解决风险的可选方案和组织方法。

风险种类有

  • 项目风险是指预算、进度、人员、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。
  • 技术风险是指设计、实现、接口、验证和维护等方面的潜在问题。
  • 商业风险威胁到要开发软件的生存能力。
    开发了一个无人真正需要的产品(市场风险)
    开发的产品不符合公司的整体商业策略(策略风险)
    建造了一个销售部门不知如何销售的产品
    由于重点转移失去了高级管理层支持(管理风险)

问题集合

  • For the waterfall model, describe situations where this model can and cannot be used and why.
    瀑布模型:通常用于需要对一个已有的系统进行明确定义的适应性调整或增强的时候;也 可用于发生在一些新的开发项目上,但是需求必须是准确定义和相对稳定的。
    在实际的不遵守瀑布模型的顺序,客户通常难以清楚描述所有的需求,以及软件工作是一 个高速的,永不停止的变化流,特性,功能和信息内容都会变化的情况下不适合用瀑布模型

  • Describe the conditions under which Incremental models should be used and what an “increment” means in terms of project work and delivery.
    增量过程模型:初始软件需求有明确的定义,但是整个开发过程却不宜单纯用线性模型。 同时,可能迫切需求为用户迅速提供一套功能有限的软件产品,然后再后续版本中再细化和扩 展功能。在这种条件下,需要选用一种以增量的形式生产软件产品的过程模型。

  • Discuss the pros and cons of prototyping model and how it differs from the spiral model.
    快速原型的优点在于尽可能快速地建造出软件原型,然后给用户评价,通过反馈可以确定 客户的真正需求。
    缺点是:1一种可能来自用户,他们舍不得将“活生生”的原型废弃不用,要求开发者仅作 “少量修改”就可以使用,这使得软件管理往往陷入失效。2对于开发者,当他们熟悉原型后, 明知它有许多不足,却不愿全部推倒重来,宁可在最终系统中保留一部分不理想的程序,结果 造成并不完美的选择变成了系统的组成部分。
    快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有 显著的效果,和瀑布模型不同的是,采用瀑布模型时候,软件的需求分析也可以再用户和系统 分析员之间反复讨论,使之逐步趋于完善。但这种讨论始终是纸上谈兵,而原型模型则是“真 枪实弹”,能够使用户立刻与想象中的目标系统作出比较。

  • List the key issues stressed by an agile philosophy of software engineering.
    软件工程的敏捷理念强调 4 个关键问题:

  1. 具有控制力的自我组织团队对所展开工作的重要性;
  2. 团队成员之间,开发参与者与客户之间的交流与合作;
  3. 对“变更代表机遇”的认识;
  4. 以及强调快速软件交付以让客户满意。
  • Describe the differences between software construction and software deployment.
    软件的构造包括了编码和测试任务,从而为向客户和最终用户交付可运行软件做好准备。 部署则包括了三个动作:交付,支持和反馈。用于现代软件工程本质上是演变的,因此部署并 不是只发生一次。两者都是软件工程的通用框架活动,但是构件肯定是发生在部署之前,部署 是构件的下一个活动。

  • What are the six steps for requirements engineering?
    需求工程的六个步骤是:起始,导出,精化,协商,规格说明,确认和管理

  • What is equivalence partitioning as it applies to software testing? What is scenario-based testing?
    等价划分是一种黑盒测试方法,它将程序的输入划分为若干的数据类,从中生成测试用例。理想的测试用例是可以单独的发现一类错误,否者在观察到一般错误之前需要进行许多测试用例,等价划分试图定义一个测试用例以发现一类错误,由此减少所需测试用例的总数。
    基于场景的测试:它关心的是用户做什么,而不是产品做什么,捕获用户完成的任务,然后在测试时候使用它们及其变体。场景用来发现交互错误。这种测试倾向于用单一测试检查多个子系统。

  • Describe the general process of creating a data flow diagram (DFD).
    从系统的基本功能模型(把整个系统看成是一个加工)开始,逐层地对系统进行分解。没 分解一次,系统的加工数量就增多一些,加工的功能也具体一些。继续重复这种分解,直到所 有的加工都足够简单为止。最终为待开发的系统画出一组分层的数据流图,以替代一张含有系 统全部加工的包罗万象的总数据流图。

  • Which UML (unified modeling language) diagrams are useful in object-oriented analysis modeling?
    静态图:用例图,类图,对象图,构件图,部署图。
    动态图:状态图,时序图,协作图,活动图。

  1. List the four design models required for a complete specification of a software design and the role of each.
  • Describe the differences between the software engineering terms coupling and cohesion? (coupling)耦合性:指一个模块与其他模块间的联系,也称为块件联系。
    (cohesion)内聚性:指模块内部各个成分之间的联系,也称为块内联系。

  • What is the Unified Modeling Language (UML)?
    统一建模语言,对软件进行可视化、规约、构造、文档化的一种语言。

  • What’s a Use-Case Diagram? Please give an example in UML.
    用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于描述软件系 统和外部参与者之间的交互,由系统边界、用例、参与者和关联等符号组成。

  • What’s an Activity Diagram? Please give an example in UML.
    活动图显示动作流程及其结果,阐明了业务用例实现的工作流程。

  • What’s a Sequence Diagram, Collaboration Diagram respectively? What’s the difference between them?
    Sequence Diagram(顺序图):也叫时序图,用来描述对象之间的动态交互,着重体现对 象间消息传递的时间顺序。以垂直轴表示时间,水平轴表示不同的对象。
    (Collaboration Diagram)协作图:用于描述相互协作的对象间的交互和链接。
    二者区别是:顺序图(时序图)着重体现交互的时间顺序,而协作图着重体现交互间的静态链接。

  • Describe the differences between black-box testing and white-box testing?
    黑盒测试:(也叫功能测试)根据被测试程序的功能来进行的测试。
    白盒测试:(也叫结构设计)是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。
    区别
    黑盒测试:主要从用户的输入和系统输出进行软件外部的测试。
    白盒测试:主要对软件内部的逻辑业务进行测试。

  • Which UML diagrams are useful for analysis modeling?
    Answer:
  1. A use-case diagram is created to visualize the interaction of your system with the outside world.(1 分)
  2. An activity diagram shows the flow of events within our system. (1 分)
    3.A analysis Class diagram shows an overview of the target system by describing the objects and classes inside
    the system and the relationships between them. (1 分)
    4.A State diagram shows the behavior of a single object, specifying the sequence of events that an object goes
    through during its lifetime in response to events. (1 分)
  3. A sequence diagram shows step by step what must happen to accomplish a piece of functionality provided by
    the system. (1 分)
    1. What is umbrella Activities? List at least five of umbrella activities
      Software engineering process framework activities are complemented by a number of umbrella
      activities(3 分).In general, umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. (2 分)
      Typical umbrella activities include:
      Software project tracking and control; Risk management;
      Software quality assurance
      Technical reviews; Measurement; Software configuration management Reusability management
      Work product preparation and production
    1. Describe the role of data design, architecture design, interface design and component-level design required for a complete specification of a software design. For WebApp software, does the above design specification offer a complete design strategy? Add more design activities specified to WebApp engineering. (共 10 分)
      注:试题字迹务必清晰,书写工整。 本题共9页,本页为第5页 教务处试题编号:

课程名称: 任课教师: 学号: 姓名:
Answers: Answer 1:
Data design - high level model depicting user’s view of the data or information.(1 分)
Architecture design – shows relationships and collaborations among specific analysis model software and hardware elements(1 分)
Interface design - interface depicts a set of operations that describe the externally observable behavior of a class and provides access to its operations(1 分)
Component-level design - Describes the internal detail of each software component(1 分)
Answer 2:
Interface design –includes a representation of screen layout, a definition of the modes of interaction, and a description of navigation mechanisms. (1 分)
Aesthetic design –describes the ‘look and feel’ of the WebApp. Includes color schemes, geometric layout, text size, font and placement, the use of graphics, and related aesthetic decisions. (1 分)
Content design – defines the layout, structure, and outline for all content that is presented as part of the WebApp. (1 分)
Navigation design – represents the navigational flow between content objects and for all WebApp functions. (1 分)
Architecture design – identifies the overall hypermedia structure for the WebApp. (1 分)
Component design – develops the detailed processing logic required to implement functional components(1 分)

0%