Landylee's learning Space

所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。在这里可以看到非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。非功能性需求必须考虑软件既要可用，又要易用。

对于非功能性需求描述的困难在于很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚，在描述这类需求时候我们经常采用软件性能要好，查询要在多少时间内出结果，软件健壮性要好等较模糊的描述词语。这类描述词语都是脱离了软件的执行环境，人和相关的场景的描述，因此信息很难体现到软件架构设计和具体的实现中。我们在架构设计中关注的安全，系统开发框架，并发和性能，异常日志等不是凭空产生出来的，而是来源于我们对非功能性需求的分析。

一个软件系统必须完整，因此不仅仅包括了可执行的程序，还包括了在线帮助，数据和用户管理，日志异常查询，自动升级等相关功能特征。这些需求不仅仅是为了满足用户的需要，也是为了我们后续维护和监控系统的需要。

系统的可靠性，可维护性和适应性是密不可分的。当系统出现故障和用户出现错误的操作后是否支持恢复，当用户在使用过程中遇到错误的时候是否可以立即定位问题，但业务场景和逻辑发生变化的时候系统是否支持，当网络不稳定或使用中异常中断的情况下系统是否都有相应的容错措施，这些都是需要在非功能性需求中考虑到的问题。

易用性也是我们在开发非功能性需求中必须要考虑到的问题，易用性同时还涉及到美工和UI界面，人机工程，交互式设计，心理学，用户行为模式等多方面的知识。易用性的三原则就是易见，易学和易用或者叫为发现，易懂，效率。易见就是各种功能操作不要藏得太深，用户很容易找到他们期望进行的各种操作；易学需要软件系统通过在线帮助，导航，向导等各种方式保证软件是可自学习的；易用的重点则在软件在熟练使用后应该可以更快的进行各项操作。这三者相互间也存在冲突，需要平衡，而平衡的一个重点就是真正的做到以用户为中心进行设计，需要去细分场景和用户。

对于非功能性需求的描述，在描述过程中必须要强调到人，业务场景，环境等各方面的内容。强调的目的就是要说明非功能性需求不是无限度的，任何一项非功能性需求的实现往往会付出更大的研发人力成本和硬件网络成本。比如我们在描述一个表单的模糊查询功能的时候，如果简单的描述为所有查询都要在多少秒内完成，那么这种需求将很难得到满足，以下是一些可选的描述方式。

1.估计用户数为1万人，每天登录用户数为3000左右，网络的带宽为100M带宽。
2.在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。
3.当通过互联网接入系统的时候，期望在编号和名称搜索时最长查询时间<15秒。

有了这些场景和数据后，我们在进行架构设计的时候就可以有针对性的选择我们的开发框架和模式，数据库，软硬件环境配置已经复杂功能的具体实现方式等。同时这些需求还可以更好的指导我们对通过性能测试等工具对这些非功能性需求进行验证。

GB2312：

一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，
这样我们就可以组合出大约7000多个简体汉字了。
在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，
连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，
而原来在127号以下的那些就叫"半角"字符了。
一个汉字算两个英文字符！一个汉字算两个英文字符……

GBK:

不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，
不管后面跟的是不是扩展字符集里的内容。
结果扩展之后的编码方案被称为 GBK 标准，
GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。

GB18030:

又加了几千个新的少数民族的字，GBK 扩成了 GB18030。

中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 "DBCS"（Double Byte Charecter Set 双字节字符集）。
在DBCS系列标准里，
最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，
因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，
如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。

每个国家都搞出自己的一套编码，为了全世界的使用统一，于是有了。。。

ISO （国际标谁化组织）的国际组织决定着手解决这个问题。
他们打算叫它"Universal Multiple-Octet Coded Character Set"，简称 UCS, 俗称 "UNICODE"。

UNICODE:
ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，
对于ascii里的那些“半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，
而其他文化和语言的字符则全部重新统一编码。
由于"半角"英文符号只需要用到低8位，所以其高 8位永远是0，
因此这种大气的方案在保存英文文本时会多浪费一倍的空间。

他们的strlen函数靠不住了，一个汉字不再是相当于两个字符了，而是一个！
是的，从 UNICODE 开始，无论是半角的英文字母，还是全角的汉字，
它们都是统一的"一个字符"！同时，也都是统一的"两个字节"，
“字节”是一个8位的物理存贮单元，而“字符”则是一个文化相关的符号。
在UNICODE 中，一个字符就是两个字节。

从 Windows NT 开始，MS 趁机把它们的操作系统改了一遍，
把所有的核心代码都改成了用 UNICODE 方式工作的版本，
从这时开始，WINDOWS 系统终于无需要加装各种本土语言系统，就可以显示全世界上所有文化的字符了。

但是，UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容，
这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的，
没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，
这种转换必须通过查表来进行。

UNICODE 是用两个字节来表示为一个字符，他总共可以组合出65535不同的字符，
这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，
说简单了就是四个字节来表示一个字符，样我们就可以组合出21亿个不同的字符出来（最高位有其他用途），
这大概可以用到银河联邦成立那一天吧！

UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，
于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，
顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，
只不过为了传输时的可靠性，从UNICODE到 UTF时并不是直接的对应，而是要过一些算法和规则来转换。

从网上引来一段从UNICODE到UTF8的转换规则：

Unicode
UTF-8

0000 - 007F
0xxxxxxx

0080 - 07FF
110xxxxx 10xxxxxx

0800 - FFFF
1110xxxx 10xxxxxx 10xxxxxx

例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间，
所以要用3字节模板：1110xxxx 10xxxxxx 10xxxxxx。
将6C49写成二进制是：0110 1100 0100 1001，
将这个比特流按三字节模板的分段方法分为0110 110001 001001，
依次代替模板中的x，得到：1110-0110 10-110001 10-001001，
即E6 B1 89，这就是其UTF8的编码。

当一个软件打开一个文本时，它要做的第一件事是决定这个文本究竟是使用哪种字符集的哪种编码保存的。软件一般采用三种方式来决定文本的字符集和编码：
检测文件头标识，提示用户选择，根据一定的规则猜测
最标准的途径是检测文本最开头的几个字节，开头字节 Charset/encoding,如下表：
EF BB BF UTF-8
FE FF UTF-16/UCS-2, little endian
FF FE UTF-16/UCS-2, big endian
FF FE 00 00 UTF-32/UCS-4, little endian.
00 00 FE FF UTF-32/UCS-4, big-endian.

ANSI字符集：ASCII字符集，以及由此派生并兼容的字符集，
如：GB2312，正式的名称为MBCS（Multi-Byte Chactacter System，多字节字符系统），
通常也称为ANSI字符集。

big endian和little endian
big endian和little endian是CPU处理多字节数的不同方式。
例如“汉”字的Unicode编码是6C49。那么写到文件里时，
究竟是将6C写在前面，还是将49写在前面？
如果将6C写在前面，就是big endian。
还是将49写在前面，就是little endian。

从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，
即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。

UTF-8就是以8位为单元对UCS进行编码。

UTF-16以16位为单元对UCS进行编码。
对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。
对于不小于 0x10000的UCS码，定义了一个算法。
不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，
所以就目前而言，可以认为UTF -16和UCS-2基本相同。
但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，
所以就不得不考虑字节序的问题。

我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，
分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。
但这些标记是基于什么标准呢？

即读取文件时，
若为unicode时，前两个字节可以不用读取。注：固定是两个字节一个字。
若为utf-8时，前三个字节可以不用读取。
若为ansi时，前面没有多余字节，可从文件头直接读取。

在 IIS 7.0 中，您可以创建网站、Web 应用程序和虚拟目录，以便与 Internet、Intranet 或 Extranet 上的用户共享信息。网站、Web 应用程序和虚拟目录以一种分层结构的关系协同进行工作，用作寄存联机内容的基础构建块。

简而言之，网站包含一个或多个 Web 应用程序，Web 应用程序包含一个或多个虚拟目录，虚拟目录则映射到 Web 服务器或远程计算机上的物理目录。下面的小节将分别详细介绍这三个概念。

什么是网站？
网站是 Web 应用程序的容器，您可以通过一个或多个唯一绑定来访问网站。网站绑定由 IP 地址、端口和可选的主机头组合而成，HTTP.sys 在此侦听对网站的请求。

什么是 Web 应用程序？
Web 应用程序是一种在应用程序池中运行并通过 HTTP 协议向用户提供 Web 内容（通常以 HTML 格式）的软件程序。创建 Web 应用程序时，Web 应用程序的名称将成为网站 URL 的一部分，用户可以通过 Web 浏览器请求该 URL。

在 IIS 7.0 中，每个网站必须拥有一个必需的 Web 应用程序，它被称为根 Web 应用程序或默认 Web 应用程序。但网站可以包含多个 Web 应用程序。例如，您可能有一个在线商务网站，该网站包含若干 Web 应用程序，例如购物车应用程序和登录应用程序，前者允许用户在购物过程中收集商品，后者允许用户在购买时回溯已保存的支付信息。

什么是虚拟目录？
虚拟目录是您在 IIS 中指定并映射到本地或远程服务器上的物理目录的目录名称。然后，目录名称将成为 Web 应用程序 URL 的一部分，用户可以通过 Web 浏览器请求该 URL 以访问物理目录的内容，例如网页或其他目录和文件的列表。如果为虚拟目录指定了不同于物理目录的名称，将增加用户在服务器上查找实际物理文件结构的难度，因为 URL 无法直接映射到网站的根。

在 IIS 7.0 中，每个 Web 应用程序都必须拥有一个命名为根虚拟目录的虚拟目录，该虚拟目录可以将 Web 应用程序映射到包含 Web 应用程序内容的物理目录。但 Web 应用程序可以拥有多个虚拟目录。例如，如果您希望 Web 应用程序包含文件系统的其他位置上的图像，但又不希望将这些图像文件移动到映射至 Web 应用程序根虚拟目录的物理目录中，则可以使用虚拟目录。
转载请注明出自高地网 - 笔记本技术区 http://enbbs.gaodi.net/,本贴地址:http://enbbs.gaodi.net/viewthread.php?tid=1616

　　二阶段构造是Symbian中的一个重要的内存处理机制，是Symbian软件开发者所必需掌握的知识。
　　本文通过三个问题及其相应解答来解析Symbian中二阶段的基本原理和使用方法，希望对大家的学习有所帮助。
问题1：为什么需要二阶段构造？
　　首先考虑如下的语句：
　　CClassName* ptr = new (ELeave) CClassName();
　　在内存有足够空间的情况下，代码首先在堆上分配一个CClassName类型的对象，并将地址赋给ptr指针，然后调用类的构造函数初始化这个对象。
这样，如果类的构造函数出现了异常，则会发生问题，这种异常发生时没有任何指针指向成功分配给CClassName对象的内存区域，因此这些内存成为孤立内存，发生内存泄漏。这就引出了symbian内存处理的一个重要规则：构造函数绝对不能异常退出。
 
问题2：为什么二阶段函数能够避免内存泄漏？
　　二阶段构造函数，顾名思义就是将一个对象的构造分为两个阶段：
　　第一个阶段是常规的的构造函数，在该构造函数中，没有可能导致异常退出的代码；
　　第二个阶段是可能会产生异常的构造阶段，实现为函数ConstructL()；
　　这样，对象的构造过程就应当包括了如下的代码：
　　CClassName* self = new (ELeave) CClassName();
　　CleanupStack::PushL(self);
　　self->ConstructL();
　　CleanupStack::Pop(self);
　　这样的构造方式为什么就能够避免内存泄漏呢？下面我们来逐行分析代码：
　　CClassName* self = new (ELeave) CClassName();
　　重载的运算符new首先将内存分配给新的self实例，如果分配失败，那么程序异常退出，如果成功给新的对象分配了内存，那么接着执行不会异常退出的第一阶段构　　造函数；
　　CleanupStack::PushL(self);
　　接着我们将本地指针self推入清除栈，因为下面要调用可能发生异常的退出函数。
　　self->ConstructL();
　　如果该二阶段构造函数在执行时异常退出，那么新的CClassName的指针由清楚栈负责清楚，避免了内存泄漏；另外，如果该函数没有异常退出，则拥有了一个完　　全构造的CClassName实例。
　　CleanupStack::Pop(self);
　　安全的将本地指针从清除栈中弹出；
　　每实例化一个对象就要写上述代码确实有些啰嗦了，Symbian OS为了简化实例化的步骤，又引入了NewL(),NewLC()两个函数(其实也可以写成一个NewL(),然而　　　　大家都比较推崇同时创建NewL()和NewLC())，其具体的实现方式见问题3；
 
问题3：如何在新的类中创建二阶段构造函数？
.h头文件：
Class CClassName : public CBase
{
public:
       static CClassName* NewL();
       static CClassName* NewlC();
       ~CClassName();
private:
       CClassName(); //第一阶段构造
       void ConstructL(); //第二阶段构造
      
……
}
 
cpp源文件:
CClassName* CClassName::NewL()
{
       CClassName* self = CClassName::NewLC();
       CleanupStack::Pop(self);
       return self;
}
CClassName* CClassName::NewLC()
{
       CClassName* self = new (ELeave) CClassName();
       CleanupStack::PushL(self);
       self->ConstructL(); //二阶段构造
       return self;
}
void CClassName::ConstructL()
{
/**************可能产生异常的代码************/
}

出处：http://blog.csdn.net/Atoric/archive/2008/05/26/2481631.aspx