第一章 软件和软件工程
1.软件的含义:
目前,软件的正确含义应该是:
1.当运行时,能够提供所需要求功能和性能的指令(instruction)或计算机程序集合;
2.该程序能够满意地处理信息的数据结构(data structures);
3.描述程序功能需求以及程序如何操作和使用所要求的文档。
2.软件的特点
表现形式不同:软件是无形的(intangible)。
生产方式不同:软件副本的大批量生产轻而易举;软件业是劳动密集型的;一个没有经过充分训练的软件开发人员很容易编写出难以理解和修改的软件。
要求不同:硬件产品可以有误差,而软件产品不可以有误差;
维护不同:软件本身很容易修改,但由于它的复杂性,又很难正确地修改 ;
软件不会用坏:软件不像其他的工业产品那样会因使用而磨损,随着反复修改,它的设计会逐渐退化。
3.软件危机的表现和原因
表现:
原因
1.项目没有被很好地理解;计划不周,最终导致进度拖延。
2.没有充分的文档资料(documentation)
3.软件可靠性缺少度量的标准,质量无法保证,特别对于规模庞大的软件。
4.软件难以维护,不易升级。
4.软件工程三要素
软件工程包含以下四个元素:
方法(methodologies)
语言(languages)
工具(tools)
过程(procedures)
5.软件工程的定义
软件工程(software engineering): 是用工程、科学和数学的原则与方法开发、维护计算机软件的有关技术及管理方法。
第二章 软件工程模式
常用软件工程模式
1.瀑布模型
优点:
提供了软件开发的基本框架,有利于大型软件开发过程中人员的组织、管理,有利于软件开发方法和工具的研究与使用,因此,在软件工程中占有重要的地位。
缺点:
在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。
在需求分析阶段,当需求确定后,无法及时验证需求是否正确、完整。
作为整体开发的瀑布模型,由于不支持产品的演化,缺乏灵活性,对开发过程中很难发现的错误,只有在最终产品运行时才能暴露出来,从而使软件产品难以维护。
应用场景:
瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如:操作系统、编译系统、数据库管理系统等系统软件的开发。
应用有一定的局限性。
2.(快速)原型模型
优点:
1)开发人员和用户在“原型”上达成一致。这样一来,可以减少设计中的错误和开发中的风险,也减少了对用户培训的时间,而提高了系统的实用、正确性以及用户的满意程度。
2)缩短了开发周期,加快了工程进度。
3)降低成本。
缺点:
1)当告诉用户,还必须重新生产该产品时,用户是很难接受的。这往往给工程继续开展带来不利因素。
2)开发者为了使一个原型快速运行起来,往往在实现过程中采用这种手段。
3) 不宜利用原型系统作为最终产品。采用原型模型开发系统,用户和开发者必须达成一致:原型被建造仅仅是用户用来定义需求,之后便部分或全部抛弃,最终的软件是要充分考虑了质量和可维护性等方面之后才被开发。
应用场景:
原型模型比瀑布模型更符合人们认识事物的过程和规律,是一种较实用的开发框架。
它适合于那些不能预先确切定义需求的软件系统的开发,更适合于那些项目组成员(包括分析员、设计员、程序员和用户)不能很好交流或通信有困难的情况。
原型模型适用于那些不能预先确切定义需求的软件系统的开发,更适用于那些项目组成员(包括分析员、设计员、程序员和用户)不能很好的交流或者通信的情况下。
2.增量模型
优点:
(1)能在较短时间内向用户提交可完成一些有用的工作产品,即从第1个构件交付之日起,用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品,从而减少一个全新的软件可能给用户组织带来的冲击。
(3)项目失败的风险较低,虽然在某些增量构件中可能遇到一些问题,但其他增量构件将能够成功地交付给客户。
(4)优先级最高的服务首先交付,然后再将其他增量构件逐次集成进来。因此,最重要的系统服务将接受最多的测试。
缺点:
采用增量模型需注意的问题
(1)在把每个新的增量构件集成到现有软件体系结构中时,必须不破坏原来已经开发出的产品。
(2)软件体系结构必须是开放的,即向现有产品中加入新构件的过程必须简单、方便。
因此,采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计。
应用场景:
incremental model增量模型也称为渐增模型,是Mills等于1980年提出来的。
使用增量模型开发软件时,把软件产品作为一系列的增量构件来设计、编码、集成和测试。
每个构件由多个相互作用的模块构成,并且能够完成特定的功能。
第三章 软件的生存周期
1.软件生存周期的定义
软件的开发过程从定义开始,经过开发、使用和维护,直到最终退役的全过程称为软件生存周期。
2.划分时期和阶段
3.任务及主要成果
任务: 通过各种维护活动使软件系统持久地满足用户的需求。
阶段划分: 分为概要设计、详细设计、编码和单元测试、集成测试和系统测试。其中前两个阶段又称为系统设计,后两个阶段又称为系统实现。
阶段性成果:
概要设计说明书;
数据库或数据结构说明书;
组装测试计划等文档。
第四章 软件的可行性分析
可行性分析的目的和任务
可行性分析的目的: 开发一个基于计算机的系统通常都受到资源(人力、财力、设备等)和时间上的限制,可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行,能否在规定的资源和时间的约束下完成。
可行性分析的任务包括:
经济可行性
技术可行性(风险、资源、技术)
法律可行性
操作可行性
第五章 软件的需求分析
1.需求分析的任务
需求分析的任务: 刻画软件的功能和性能,确定软件与其他系统元素的接口,并建立软件必须满足的约束。
2.功能与非功能需求的含义
功能需求: 描绘系统应该提供的服务、如何对输入做出反映以及系统在特定条件下的行为的描述。
非功能需求: 从各个角度对系统的约束和限制,反映了应用对软件系统质量和特性的额外要求,例如响应时间、数据精度、可靠性、开发过程的标准等。
3.高质量需求的特征
无二义性(例子:需求描述1)
不同的人员对需求的理解应该是一致的。一般情况下,描述需求都使用自然语言,因此容易引起需求理解的二义性。
完整性(例子:需求描述2)
不能遗漏任何必要的需求;
每一项需求要完成的任务必须要描述清楚,以便开发人员明白实现这项需求的所有信息,用户能够审查这项需求描述的正确性
正确性
每项需求都必须准确地反映用户要完成的任务。
可行性
每一个成功的软件系统其解决方案都应该是可行的,可行性体现在技术、经济、操作可行性。
必要性
每项需求都应该是客户所需要的,开发人员不要自作主张添加需求。
4.数据流图
数据流图用于功能建模;
数据流程图:(Data Flow Diagram:DFD)舍去了具体组织机构、信息载体、物资、材料等,单从流动过程来考查实际业务的数据处理模式。
5.数据字典
数据字典: 在系统分析中的作用是给数据流图上每个成分以定义和说明,其描述的主要内容有:数据流、数据元素、数据存储、加工、外部项等关于系统的详细信息。
在数据字典中,仅定义数据的静态特征,具体包括:
(1)数据项的名称、编号、别名和简述;
(2)数据项的长度;
(3)数据项的取值范围和取值含义;
(4)与它有关的数据结构等。
数据字典条目类型一: 数据流
6.决策树(策略树)
7.策略表,决策表
第六章 软件的概要设计
1.抽象
抽象使得设计者能够描述过程和数据而忽略低层的细节;
2.模块化
模块: 是数据说明、可执行语句等程序对象的集合,它是单独命名的,并且可以通过名字来访问。例如,过程、函数、子程序、宏、类 等。
模块化: 即把软件按照规定原则,划分为一个个较小的,相互独立的但又相互关联的部件,实际上是系统分解和抽象的过程。
3.信息隐藏与局部化
信息隐藏: 是指模块中包含的信息(算法和数据)不被不需要这些信息的其他模块访问。模块间只交流实现软件功能所必需的信息。
局部化: 是指把一些关系密切的软件元素物理的放得彼此接近。例如:在模块中使用局部数据元素就是局部化的一个例子。
通过信息隐藏可以定义和加强模块内的过程细节和模块所使用的任何局部数据结构的访问限制
4.耦合和内聚及分类
耦合(coupling)
•模块之间的相对独立性的度量
•耦合的强弱取决于模块接口的复杂程度、调用模块的方式以及通过接口的信息。
分类
内聚(cohesion)
•一个模块内部各个元素彼此结合的紧密程度的度量。
•独立性强的模块应该是高内聚低耦合的模块。
分类
5.模块的扇入扇出、深度、宽度
结构的深度
结构的层次数。结构的深度一定意义上反映软件结构的规模和复杂度。
结构的宽度
•层次结构中同一层模块的最大模块个数。
•扇出表示一个模块直接调用(或控制)的其它模块数目。
•扇入则定义为调用(或控制)一个给定模块的模块个数。
•多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块。
6.结构化设计方法(构建模块)《的实施要点》(7点)
(1) 研究、分析和审查数据流图。
(2) 根据数据流图决定问题的类型:变换型和事务型。针对两种不同的类型分别进行分析处理。
(3) 由数据流图推导出系统的初始结构图。
(4) 利用一些启发式原则来改进系统的初始结构图,直到得到符合要求的结构图为止。
(5) 根据分析模型中的实体关系图和数据字典进行数据设计,包括数据库设计或数据文件的设计。
(6) 在上面设计的基础上,并依据分析模型中的加工规格说明、状态转换图进行过程设计。
(7) 制定测试计划。
第七章 软件的详细设计*
1.代码的种类及设计应用
种类
①顺序码。将顺序的自然数和字母赋予编码对象。用连续数字代表编码对象。如张平的职工号为0001,李立的为0002等,顺序码的优点是简单,易追加,缺点是可识别性差,无逻辑性。
②分段码。将整个编码长度分成几段,分别表示不同的分类信息,每段具有一定的含义,如我们熟悉的学号,就是一种分段编码。
③字母码。用具有特定意义的字母代表某一类项目。如电视用“TV”,厘米用“cm”。字母码的优点是可用汉字拼音或英语联想帮助记忆,缺点是位数多、处理不便,易产生重复。
④组合码。由上述编码组合而成。如学号就由分段和顺序码组合而成。
⑤混合码。用字符、数字混合组码,如汽车牌号“冀F33622”。
⑥特征组合码。将分类对象按其属性或特征分成若干个“面”,每个“面”内的诸类目按其规律分别进行编码。
设计应用
•代码是一组可以包含事物的类别、属性、状态等信息的符号或记号,它可以是字符、数字、特殊符号或它们的组合。代码以简短的符号形式代替了具体的文字说明,具有简洁、形象、便于记忆、便于计算机识别和处理的特点。
•如职工编号、物资编号、部门编号、产品编号、零部件及材料编号等。
代码对软件系统的作用大致体现在五个方面:
①标识作用。代码在系统内具有唯一性,可用来标识和确定某个具体的对象,避免了文字描述、术语和别名等的二义性,以便于计算机的识别。
②便于录入、分类、统计、检索等操作。当实体信息按属性或类别进行编码后,简化了统计和检索处理过程。
③代码可以用来标明事物所处的状态,便于对象的动态管理。
④可以节省存储空间,提高处理速度与精度。
⑤可以提高数据标准化程度。
2.概念模型
“实体-关系”模型(概念模型):具有三种基本成分:实体、关系和属性。在系统分析与设计过程中,常用“E-R图”来表示。
第八章 软件的编码
1.程序设计语言分类
•按应用特点分类
•面向机器语言(机器语言和汇编语言)
•高级语言
•基础语言(BASIC、Fortran)
•现代语言(Pascal、C、C++)
•专用语言(Lisp、Prolog)
•按语言内在特点分类
•系统实现语言
•静态高级语言
•块结构高级语言
•动态高级语言
2.好程序的代码的特点
好程序的代码逻辑简明清晰、易读易懂:
①程序的内部文档;
②数据说明;
③语句构造;
④输入/输出方法;
第九章 软件质量与质量保证
软件质量因素
软件的可靠性: 在特定的环境和时间内,计算机程序无故障运行的概率。
平均失效间隔时间(MTBF) = 平均失效时间(MTTF) + 平均维修时间(MTTR)
可用性 = [MTTF / (MTTF + MTTR)] * 100%
MCC77软件质量因素(McCall和同事提出)
•正确性:程序满足其需求规格说明书和完成用户任务目标的程度。
•可靠性:期望程序以所要求的精度完成其预期功能的程度。
•效率:程序完成其功能所需的计算资源和代码量。
•完整性:对未授权的人员访问软件和数据的可控程度。
•易用性:对程序学习、操作、准备输入和解释输出所要的工作量。
•可维护性:定位和修复程序中的一个错误所需的工作量。
•灵活性:修改一个运行的程序所需的工作量。
•可测试性:测试程序以确保它能完成预期功能所需的工作量。
•可移植性:将程序从一个硬件或软件系统中移植到另一个系统所需的工作量。
•可复用性:程序或一段程序可以在另一个程序中使用的程度。
•互操作性:将一个系统连接到另一个系统所需的工作量。
ISO9126质量因素
•功能性。软件满足所陈述需要的程度,由适宜性、准确性、互操作性、依从性和安全性构成。
•可靠性。软件可用的时间长度,由成熟性、容错性、和可复用性构成。
•易用性。软件容易使用的程度,由可理解性、易学性、和可操作性构成
•效率。软件优化使用的系统资源程度,从时间表现和资源表现衡量。
•可维护性。软件易于修复的程度,由可分析性、可修改性、稳定性和可测试性构成。
•可移植性。软件可以从一个环境移植到另一个环境的容易程度,由适应性、可安装型、符合性、和可替代性构成。
六西格玛是软件界应用最广泛的基于统计的质量保证策略。六西格玛方法学的核心步骤:
•定义:通过与客户交流的方法来定义客户需求、可交付性,以及项目目标。
•测量:测量现有的过程及其产品,以确定当前的质量状况,收集缺陷度量信息。
•分析:分析缺陷度量信息,并挑选出重要的少数原因。
•设计:设计过程以避免缺陷产生的根本原因;满足客户需求。
•验证:验证过程模型是否确实能够避免缺陷,并且满足客户需求。
第十章 软件测试
1.软件测试目的
•测试是程序的执行过程,目的在于发现错误;
•一个好的测试用例在于能发现至今未发现的错误;
•一个成功的测试是发现了至今未发现的错误的测试。
2.软件测试步骤
1.模块测试(单元测试):把每个模块作为一个单独的实体来测试,发现的往往是编码和详细设计的错误。
2.集成测试(子系统测试):把经过单元测试的模块放在一起形成一个子系统来测试,着重测试模块的接口。
3.确认测试:把软件系统作为单一的实体进行测试,在用户积极参与下,使用实际数据进行测试。目的是验证系统能否满足用户的需要。发现的往往是系统需求说明书中的错误。
4.系统测试:把经过测试的子系统装配成一个完整的系统来测试。发现运行平台中的错误,包括软件、硬件、网络环境等。
5.验收测试(平行运行):
•是同时运行新开发出来的系统和将被它取代的旧系统,以便比较新旧两个系统的处理结果。
•可以在准生产环境中运行新系统而又不冒风险;用户能有一段熟悉新系统的时间;可以验证用户指南和使用手册之类的文档;能够以准生产模式对新系统进行全负荷测试,可以用测试结果验证性能指标。
3.白盒测试和黑盒测试及主要方法
3.1白盒测试
•白盒测试:把测试对象看做一个透明盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序的所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
•白盒测试又称为结构测试 或逻辑驱动测试。
软件人员使用白盒测试方法,主要想对程序模块进行如下的检查:
•对程序模块的所有独立的执行路径至少测试一次;
•对所有的逻辑判定,取“真”与取“假”的两种情况都至少测试一次;
•在循环的边界和运行界限内执行循环体;
•测试内部数据结构的有效性等;
3.2黑河测试
•黑盒测试: 把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。
黑盒测试又叫做功能测试或数据驱动测试。
•黑盒测试的主要方法有:
1.等价划分;
2.边界值分析;
3.错误推测;
4.因果图。
第十一章 软件维护
1.软件维护的分类及成本
软件维护的分类:
•改正性维护(Corrective maintenance)
•适应性维护(Adaptive maintenance)
•完善性维护(Perfective maintenance)
预防性维护(Preventive maintenance)、
成本
有形的维护代价: 费用。
无形的维护代价有更大的影响:
•贻误良机;
•一些合理的修复或修改请求不能及时安排,使得客户不满意;
•变更的结果引入新的故障,使得软件整体质量下降;
•把软件人员抽调到维护工作中,干扰了软件开发工作。
2.修改程序的副作用
•修改代码的副作用
•修改数据的副作用
•文档副作用
第十二章 软件项目管理
1.软件项目管理
•为什么需要软件项目管理?
•是否需要管理是专业软件开发和业余编程之间的重要区别之一;
•专业的软件开发活动总是要受预算和工程进度等的制约;
•有多方面的参与者需要协调或管理;
•软件项目管理者要确保项目符合预算和进度要求,还要确保交付的软件能达到既定的目标;
再好的管理也不能保证项目绝对成功,但糟糕的管理常常造成项目失败。
•什么是软件项目管理?
•根据选定的软件开发过程进行组织、分工;按照计划的进度以及成本管理、风险管理、质量管理的要求,控制并管理软件开发和维护的活动,最终以最少的资金完成软件项目规定的全部任务。
•有五个条件制约着每一个项目:工作范围、时间、成本、质量和资源。
•项目经理的最主要工作之一就是平衡各种项目约束,从而实现或超过项目干系人的期望值。
2.项目经理及职责
项目经理的最主要工作之一就是平衡各种项目约束,从而实现或超过项目干系人的期望值。
第十三章 进度安排与跟踪
1.工作分解结构(WBS)
•是以可交付成果为导向的对项目成分的分组,从而组织并定义整个项目范围。WBS不包括的工作就不在项目的范围之内。
•WBS是自顶向下逐层构建的,表现形式可以是图表也可以是文字大纲。
•最高层,是项目本身。接下来是项目的可交付成果以及进一步分解的、更小的可交付成果。然后就是创建这些成果的活动。
2.甘特图Gantt图
甘特图Gantt图
显示基本的任务信息
可以查看任务的工期、开始时间和结束时间以及资源的信息。
只有时标,没有活动的逻辑关系
甘特图(Gantt chart)又称为横道图、条状图(Bar chart)。以提出者亨利·L·甘特先生的名字命名。
甘特图内在思想简单,即以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。基本是一条线条图,横轴表示时间,纵轴表示活动(项目),线条表示在整个期间上计划和实际的活动完成情况。它直观地表明任务计划在什么时候进行,及实际进展与计划要求的对比。管理者由此可便利地弄清一项任务(项目)还剩下哪些工作要做,并可评估工作进度。
甘特图是基于作业排序的目的,将活动与时间联系起来的最早尝试之一。该图能帮助企业描述对诸如工作中心、超时工作等资源的使用图。甘特排程图可用于检查工作完成进度。它表明哪件工作如期完成,哪件工作提前完成或延期完成。
优点:甘特图较为简单直观,易于普通用户理解。一般适用于不超过 30 项活动的中小型项目,且无须担心复杂计算和分析。
缺点: 甘特图事实上仅仅部分地反映了项目管理的三重约束(时间、成本和范围),因为它主要关注进程管理
第十四章 项目度量与成本估算
常见的估算方式
软件规模的估算方法:
•代码行(LOC: lines of code)
•功能点分析(FPA: function points analysis)
•德尔菲法(Delphi technique)
•COCOMO模型
•特征点(feature point)
•对象点(object point)
•3-D功能点(3-D function points)
•Bang度量(DeMarco‘s bang metric)
•模糊逻辑(fuzzy logic)
•标准构件法(standard component)
第十五章 资源管理
资源的分类
资源可以分为7类:
将软件项目所需的资源分成以下七类:
•劳动力(Labor)。 软件项目的主要人员是开发项目组的成员, 例如项目经理、 系统分析员和软件开发人员等。 同等重要的还有质量保证组和其他支持人员, 以及承担或参与特定活动所要求的客户组织的任何雇员。
•设备(Equipment)。 显而易见的设备包括工作站以及其他计算机和办公设备。 不要忘记员工还需要使用桌子和椅子等设备。
•材料(Material)。 材料是要消耗的资源, 不是要使用的设备。 在多数项目中材料不是很重要, 但是对有些项目来讲可能是非常重要的, 例如要广泛分发的软件可能要求提供专门购买的光盘。
•场地(Space)。 对于由已有员工承担的项目来讲, 场地一般不是问题。 如果需要任何额外的员工(新招聘的或签订合同的), 则需要寻找办公场地。
•服务(Service)。 有些项目要求获取专门学科的服务, 例如广域分布式系统的开发要求计划好长途通信服务。
•时间(Time)。 时间是可由其他主要资源弥补的资源, 有时可以通过增加其他资源来减少项目的时间, 而且如果其他资源意外减少, 几乎可以肯定要延长项目的时间。
•资金(Money)。 资金是次要的资源。 资金用于购买其他资源, 当使用其他资源时, 就要消耗资金。 类似于其他资源,资金要用一定的成本来获得, 这就是利息费。
第十六章 风险分析与管理
软件风险及其影响、风险
什么是软件风险?
•使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件。
•例如,人员的临时流失,计划过于乐观,设计的低劣,第三方软件不满足部分需要。
风险特点:
•不确定性:风险可能发生,也可能不发生;
•损失:风险如果变成现实,会带来损失;
•风险是尚未发生的问题,问题是业已成真的风险。
•在风险突然变成问题的那一刻,我们说风险“具现”了。这也是风险转化的时刻。
第十七章 软件配置管理
软件配置管理及作用、配置项
•什么是软件配置管理
•在软件的整个生命周期中,对软件配置项( Software Configuration Item )进行以下工作:
•系统地控制SCI的标识、存储、更动和发放;
•记录、报告其状态;
•验证SCI的正确性和一致性;
•对上述工作的审计。
所谓的软件配置管理是指在整个软件生命周期中,建立和标识软件配置管理项,并对其进行控制和管理,以维护其完整性、一致性和可跟踪性。
第十八章 基于Web的系统及应用特点
1.基于Web的系统及应用特点
能否将软件工程的原理、概念和方法应用到Web开发中?很多是可以的,但有些需要调整。
•网络密集性:WebApp驻留在网络上,服务于不同客户群的需求。
•并发性:在同一时间可能有大量的用户使用WebApp。
•无法预计的负载量:WebApp的用户每天都可能有数量级的变化。
•性能:如果一位用户必须长时间等待,该用户就会转向其他地方。
可得性:大多是WebApp用户通常要求“24/7/356”全天候的可访问。
•数据驱动:WebApp一般都会访问来自数据库中的信息。
•内容敏感性:内容的质量和艺术性仍然在很大程度上决定WebApp的质量。
•持续化:传统的应用程序是随规划好的时间间隔演化的,而WebApp则持续演化。
•即时性:将软件尽快推向市场的迫切需求。
•保密性:Web是通过网络来使用的,要限制访问的最终用户数量。保护敏感的内容,提供保密的数据传输模式等。
•美学性:Web应用具有吸引力的不可否认的部分是其观感。
WebApp工作中最长碰见的应用类型:
•信息型:使用简单的导航和链接提供只读内容。
•下载型:用户从相应的服务器下载信息和资源。
•可定制型:用户根据自己的特殊需求定制内容。
•交互型:在用户群体中,通过BBS、公告或即时消息来传递信息。
•用户输入型:基于表格的输入是满足通信的主要机制。
•面向事务型:应用程序向用户提供服务。
•门户型:应用程序将用户引导到本门户应用范围之外的其他Web内容或服务。
•数据库访问型:用户查询一个大型数据库并提取信息。
•数据仓库型:用户查询一组大型数据库并提取信息。
2.WebApp设计原则
设计目标
•简单性:设计者往往倾向于给用户提供“太多的东西”,但是最好还是做到适度和简单。
•一致性:内容构造一致(文本格式和字体风格,图形,颜色配置和风格);美术设计统一的外观等。
•相符性:设计必须与将要构造的应用系统所处的领域保持一致。
•健壮性:健壮的内容和功能。
•导航性:用户知道如何使用WebApp。
•视觉吸引:美丽的外观无疑是最吸引观看者的眼球的。
•兼容性:WebApp会应用于不同的环境,必须相互兼容。
WebApp设计金字塔
•界面设计:描述用户界面的结构和组织形式,包括屏幕布局、交互模式的定义和导航描述。
•美学设计:美术设计,包括颜色配置,几何图案,文字大小字体和位置等。
•内容设计:所有内容定义布局,结构和轮廓。
•导航设计:针对所有功能,描述内容对象之间的导航流程。
•体系结构设计:确定WebApp的所有超媒体结构。
•构件设计:开发实现功能构件所需要的详细处理逻辑。
优秀网页设计的技巧
•有明确的标志和口号;
•让你的页面遵循用户体验,易于浏览;
•可以方便的与其联系;
•分类你的工作;
•学会推荐;
•提供一个可下载印刷按钮;
•让网站内容清晰明了;
•不要忘记你网站的独特性,做好自己。
界面设计原则与指导方针:
•有效的界面在视觉效果上是明显的、宽容的,并且慢慢地给用户灌输控制感。用户能够很快地看到他们的选择范围,领会怎样达到他们的目标,开始他们的工作。
•有效的用户界面使用户不必关心系统的内部操作。可以在任何时间取消任何操作。
•有效的界面和服务从用户那里要求最少的信息,而完成最多工作。
•预测——对WebApp进行设计,使其能够预测出用户的下一个步骤。
•传达——界面应该能够传达由用户启动的任何活动状态。
第十九章 面向对象的系统分析与设计
面向对象的方法则是以对象为核心来构造软件框架的,在框架不需要变化的前提下,通过对象的协作和参与,就能够协作实现更多的系统功能。如果完成某项任务要求有特殊的对象能力,只需要增强对象的能力就可以实现。因此,这样的结构所具备的应对需求变更的能力是与生俱来的。每个对象封装起来的操作具有强内聚性。
•面向对象 = 对象 + 类 + 继承 + 消息通信
•对象:包含现实世界物体特征的抽象实体,它反映了系统为之保存信息和与它交互的能力。对象是一些属性和服务的封装体。
对象 = 数据 + 作用于这些数据上的操作
•类:对象在程序中是通过一种抽象数据类型来描述的,这种抽象的数据类型称为类。类是具有相同操作功能和相同的数据格式的对象的集合与抽象。
设计:所有内容定义布局,结构和轮廓。
•导航设计:针对所有功能,描述内容对象之间的导航流程。
•体系结构设计:确定WebApp的所有超媒体结构。
•构件设计:开发实现功能构件所需要的详细处理逻辑。
优秀网页设计的技巧
•有明确的标志和口号;
•让你的页面遵循用户体验,易于浏览;
•可以方便的与其联系;
•分类你的工作;
•学会推荐;
•提供一个可下载印刷按钮;
•让网站内容清晰明了;
•不要忘记你网站的独特性,做好自己。
界面设计原则与指导方针:
•有效的界面在视觉效果上是明显的、宽容的,并且慢慢地给用户灌输控制感。用户能够很快地看到他们的选择范围,领会怎样达到他们的目标,开始他们的工作。
•有效的用户界面使用户不必关心系统的内部操作。可以在任何时间取消任何操作。
•有效的界面和服务从用户那里要求最少的信息,而完成最多工作。
•预测——对WebApp进行设计,使其能够预测出用户的下一个步骤。
•传达——界面应该能够传达由用户启动的任何活动状态。
第十九章 面向对象的系统分析与设计
面向对象的方法则是以对象为核心来构造软件框架的,在框架不需要变化的前提下,通过对象的协作和参与,就能够协作实现更多的系统功能。如果完成某项任务要求有特殊的对象能力,只需要增强对象的能力就可以实现。因此,这样的结构所具备的应对需求变更的能力是与生俱来的。每个对象封装起来的操作具有强内聚性。
•面向对象 = 对象 + 类 + 继承 + 消息通信
•对象:包含现实世界物体特征的抽象实体,它反映了系统为之保存信息和与它交互的能力。对象是一些属性和服务的封装体。
对象 = 数据 + 作用于这些数据上的操作
•类:对象在程序中是通过一种抽象数据类型来描述的,这种抽象的数据类型称为类。类是具有相同操作功能和相同的数据格式的对象的集合与抽象。