EEG信号是脑神经细胞群电生理活动在大脑皮层或头皮表面的总体反映,不同的思维状态和病因在大脑皮层的不同位置产生不同的脑电信号。因此,脑电信号含有丰富的有用信息,其对于生理研究与临床应用如癫痫、脑炎、脑肿瘤等脑疾病的诊断都具有十分重要的意义。随着计算机、信号处理技术的发展,脑电图在脑疾病的临床诊断中越来越起到重要的作用,其成效最明显的例子就是癫痫病的诊断。但是这些诊断一般
都是通过检查疾病发作后所记录得到的脑电图实现的,是一种预后行为,因此不论是普通的脑电图诊断还是ICU 的脑电图监护,都做不到对脑疾病如癫痫病的发作进行预测。基于Takens 的时间延迟相空间重构法[1 ,2 ]和基于自适应投影学习算法[3 ]的径向基函数网络,研究了EEG信号的预测问题。通过对径向基函数引入一宽度调节系数α,使网络的预测性能如预测精度、收敛速度均有较大改善。研究结果证明这种预测方法是有效的,具有较好的应用前景。

参见 信号的径向基函数神经网络预测

出版社: 清华大学出版社
作者: 余英林

其中关于脑电图与混沌分析的部分如下
6.3脑电信号的混沌分析255
6.3.1脑电图简介255
6.3.2脑电信号的提取256
6.3.3脑电信号的混沌性257
6.3.4脑电信号的混沌分析258

19:19, #, By linmi
Learning, Others

细胞自动机是由一些规则的格子构成，每个格子可以看做一个细胞，细胞具有一些状态，在某个时刻只能处于一种状态中。

构建一个细胞自动机系统需要包括以下几个步骤：

1. 决定细胞活动的空间维度
2. 定义细胞可能具有的状态
3. 定义细胞状态的改变规则
4. 设定系统中各个细胞的初始状态

复杂性研究方法：

现实世界 ⇒　假说（法则，理论）⇔模拟器（simulation）⇔结果　⇒现实世界

传统研究方法：

现实世界 ⇒　假说（法则，理论）⇔实验⇔结果　⇒现实世界

复杂方法和传统方法的结合：

现实世界 ⇒　假说（法则，理论）⇔模拟器（simulation）⇔结果

                    　　　　　　　　　　　　　　↓↑

                                 实验（人为设定的现实世界）⇔结果    　⇒现实世界

在哲学领域， 还原论（reductionism）一词最早出现在1951年，当时蒯因用它来标记逻辑经验主义的信条。精致的还原论思想却是由卡尔纳普等逻辑经验主义者发展起来的：在二十世纪二、三十年代，他们不加限制的推广使用还原方法，试图通过不同学科之间的严格还原，来达到学科间的理想统一，从而消除学科间的混乱和分歧。一般还原论的思想是建立在这样一个基本假设之上，即“表面上不同种类的存在物或特性是同一的。它声称某一种类的东西能够用与它们同一的更为基本的存在物或特性类型来解释。” 而就建立统一科学的纲领而言，其所依据的还原论前提就是：一种科学的理论可以用另一种更为基本的科学理论来进行系统的解释，或者复合体的定律可以还原为关于构成复合体的部分定律，正如内格尔所说：“还原的目标是要表明，次级学科的定律和一般原理只是初级学科的假定逻辑结果。”

参见：《系统辩证学学报》2004年第2 期 关于还原的一些哲学思考 周维刚

1. 哲学上的本体论：存在论和认识论
2. 字典意义上的本体论：自然语言中的概念字典以及Semantic Web的本体论层
3. 信息学中的本体论：本体论算法。从哲学开始，在逻辑学、数学、语言学、符号学的基础上，集大成了分类学原理。

1. E-R模型（Entity Relationship Model）,用长方形表示实体（人，物，场所，事件，信息，概念等），用菱形表示实体之间的关系。实体和关系拥有属性。

2.数据规范化:常用的范式有三种（第一范式，第二范式，第三范式）

举例：

非规范化数据

发票号

日期

客户代码

客户名

住所

购买1

购买2

购买3

商品号

数量

单价

商品号

数量

单价

商品号

数量

单价

第一范式

发票号

日期

客户代码

客户名

住所

发票号

商品号

数量

单价

第二范式

发票号

日期

客户代码

客户名

住所

发票号

商品号

数量

商品号

单价

第三范式 

发票号

日期

客户代码

客户代码

客户名

住所

发票号

商品号

数量

商品号

单价

1. 数据仓库，也称信息库
2. 数据挖掘
3. data mart ，数据摘要
4. OLAP(OnLine  Analytical Processing),在线分析处理
5. OLTP(OnLine Transaction Processing),在线事务处理
6. 应用系统，如：企业会计系统，在库管理系统，文书管理系统，营业支援系统等

Session管理

select username,sid,machine,serial# from v$session

sql文件执行

启动Sql plus,执行 @文件名

ISO9000和CMM既有区别又相互联系。

ISO9000和CMM是国际上通用的软件质量评估和管理方法。

ISO 9001标准的一些要求在CMM中不存在，而CMM的一些要求在ISO 9001标准中也不存在，两者之间的关系非常密切。

取得ISO 9001认证对于取得CMM的等级证书是有益的，反之，取得CMM等级证书，对于取得ISO 9001认证也是有帮助的。

ISO 9000-1 质量管理及质量保证规格

1.外部质量保证

 购买者以及审查机关对供应者所要求的质量保证系统。

1. ISO9001：设计，开发，制造，安装及附带服务的质量保证模型
2. ISO9002：制造，安装及附带服务的质量保证模型
3. ISO9003：最终检查，测试的质量保证模型

2.内部质量保证

供应者自发执行的质量管理活动

1. ISO9004：质量管理及质量系统的基本要素

1. 功能层次模型
2. 数据流模型（DFD： Data Flow Diagram）
3. 流程控制模型
4. 有限机械状态模型
5. Petri网状模型
6. 数据指向模型（E-R）
7. 面向对象模型
8. 并列过程模型

能力成熟度模型

CMM定义了软件过程成熟度的五个级别。

级别1：初始级，描述了不成熟，或者说是未定义的过程的组织。

级别2：可重复级，

级别3：已定义级，

级别4：已管理级

级别5：优化级

和这些级别相关的KPA是：

　　级别2：需求管理，软件项目计划，软件项目跟踪和监控，软件子合同管理，软件质量保证，软件`构成管理。

　　级别3：组织级过程焦点，组织级过程定义，培训大纲，集成软件管理，软件产品工程，组间协调，同行评审。

　　级别4：定量过程管理，软件质量管理

　　级别5：缺陷预防，技术更新管理，过程更改管理

能力成熟度モデル

通常CMMといった場合、このソフトウェア能力成熟度モデルを指すことが多い。

ＣＭＭの指標はレベルの低いほうから見ていくと表のようになっています。

レベル		内容
レベル１	初期	予測できず、そして貧弱なコントロール
レベル２	反復できる	これまでに習得した仕事を反復できる
レベル３	定義された	プロセス特性が記述され、正しく十分に理解される
レベル４	管理された	プロセスが計測され、コントロールされる
レベル５	最適化する	プロセス改善に集中する

レベル2：要件管理（Requirements Management；RM）、　　ソフトウェアプロジェクト計画（Software Project Planning；SPP）、　　ソフトウェアプロジェクト進捗管理（Software Project Tracking Oversight；PTO）、　　ソフトウェア外注管理（Software Subcontract Management；SSM）、　　ソフトウェア品質保障（Software Quality Assuarance；SQA）、　　ソフトウェア構成管理（Software Configuration Management；SCM）

レベル3：組織プロセス重視（Organization Process Focus；OPF）、　　組織プロセス定義（Organization Process Definition；OPD）、　　トレーニングプログラム（Training Program；TP）、　　ソフトウェア統合管理（Integrated Software Management；ISM）、　　グループ間調整（Intergroup Coordination；IC）、　　ソフトウェアプロダクトエンジニアリング（Software Product Engineering；SPE）、　　ピアレビュー（Peer Reviews；PR）

レベル4：定量的プロセス管理（Quantitative Process Management；QPM）、　ソフトウェア品質管理（Software Quality Management；SQM）

レベル５：欠陥予防（Defect Prevention；DP）、技術変更管理（Technology Change Management；TCM）、　プロセス変更管理（Process Change Management；PCM）

• レベル1：プロセスが確立されていない初期段階
• レベル2：特定のプロジェクトリーダーや技術者に依存している状態
• レベル3：首尾一貫したプロセスを標準として持っている段階
• レベル4：標準化されたプロセスを定量的に測定し、洗練化していく状態
• レベル5：技術・要件環境の違いによって、標準プロセスを最適化して用いられる段階

软件质量特征是指软件的质量评价基准。软件质量特征的考查方法主要有三种，ISO/IEC 9126,Boehm,ISO 9000系列。

1 代码标准化：文字代码，条形码

2 文件格式标准化：

• 图像：JPEG,GIF,BMP,TIFF
• 动画：MPEG-1,MPEG-2,MPEG-4
• 文本：SGML,XML,HTML,Tex
• 格式数据：CSV(Comma Separated Value),SYLK(Symbolic Link)

3 国际单位体系

• M:10(6)
• G:10(9)
• T:10(12)

http://it.icxo.com/htmlnews/2004/07/28/277692.htm

在网上发现关于需求的分析一篇好文，部分摘要如下：

1、 分析人员要使用符合客户语言习惯的表达
　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
　　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。

3、 分析人员必须编写软件需求报告
　　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、 要求得到需求工作结果的解释说明
　　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、 开发人员要尊重客户的意见
　　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、 开发人员要对需求及产品实施提出建议和解决方案
　　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、 描述产品使用特性
　　客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、 允许重用已有的软件组件
　　需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、 要求对变更的代价提供真实可靠的评估
　　有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、 获得满足客户功能和质量要求的系统
　　每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、 给分析人员讲解您的业务
　　分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、 抽出时间清楚地说明并完善需求
　　客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、 准确而详细地说明需求
　　编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
　　在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、 及时作出决定
　　分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、 尊重开发人员的需求可行性及成本评估
　　所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、 划分需求的优先级
　　绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
　　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、 评审需求文档和原型
　　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
　　更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、 需求变更要立即联系
　　不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、 遵照开发小组处理需求变更的过程
　　为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、 尊重开发人员采用的需求分析过程
　　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

1.面向现状

•  主要特征：通过归纳而实现改善，从How to do出发，追求能够改善现状。
• 方法：现状分析，找出问题，提出改善案，需求文档制作

2.面向目标

• 主要特征：通过演绎而实现创新，从What to do出发，追求能够达到目标。
• 方法：目标设定，达成目标的功能界定，提出实现功能方案，需求文档写作。

1. 流水模型
2. 成长模型
3. 螺旋模型
4. 契约模型
5. 试作模型

1. 过程型：C,Fortran,Pascal,BASIC等
2. 函数型：LISP
3. 逻辑型：Prolog
4. 面向对象型：Smalltalk,Java,C++

1. C++
2. VB
3. XML
4. SGML
5. PostScript
6. Java
7. Perl

与Java的企业级应用大致可以分为4类：

1. Web应用程序：Apache,Tomcat/Jetty,Struts,JetSpeed,Cocoon等
2. 事务处理系统：Ejb(Jboss),O/R(Torque/Hibernate/TJDO),RDBMS(PostgreSQL/MySQL)
3. XML:解析器(Xerces/JDOM)，XSLT处理器(xalan/saxon),SOAP等
4. 开发工具：IDE(Eclipse/NetBeans/JDEE),测试（Junit/Cactus/JUnitEE/HttpUnit）,编译工具（Ant/XDoclet/Maven）,项目管理（CVS）,Log管理(Log4j)等

本实验需要两台机器，一台机器运行apache和tomcat,另外一台机器运行tomcat。连接器`可选用Jk或Jk2,本试验采用JK

机器1的配置：xp,apache2.04,tomcat3.32

假设：tomcat安装在c:\tomcat33

Apache的Conf文件的最后加入include "C:\tomcat33\conf\jk\mod_jk.conf"

修改mod_jk.conf文件

LoadModule jk_module modules/mod_jk.dll

<IfModule mod_jk.c>

#JkWorkersFile <fill-path-to>/workers.properties

#JkLogFile  logs/jk.log

#JkLogLevel error

#JkMount /*.jsp ajp12

#JkMount /servlet/* ajp12

#JkMount /examples/* ajp12

JkWorkersFile “C:/tomcat33/conf/jk/workers.properties”

JkLogFile  logs/jk.log

JkLogLevel error

JkMount /*.jsp loadbalancer

JkMount /servlet/* loadbalancer

JkMount /examples/* loadbalancer

</IfModule>

修改workers.properties文件

①     worker.list=ajp12, ajp13 ⇒ worker.list=ajp12, ajp13, Tomcat2, loadbalancer

②     worker.loadbalancer.balanced_workers=ajp12,ajp13⇒worker.loadbalancer.balanced_workers=ajp12,Tomcat2

③     在#------ DEFAULT LOAD BALANCER WORKER DEFINITION ----------------------之前添加以下内容

#

#------ Tomcat2 WORKER DEFINITION ------------------------------

#---------------------------------------------------------------------

#

#

# Defining a worker named ajp12 and of type ajp12

# Note that the name and the type do not have to match.

#

worker.Tomcat2.port=8007

worker.Tomcat2.host=第二台机器的IP

worker.Tomcat2.type=ajp12

#

# Specifies the load balance factor when used with

# a load balancing worker.

# Note:

#  ----> lbfactor must be > 0

#  ----> Low lbfactor means less work done by the worker.

worker.Tomcat2.lbfactor=1

在c:\tomcat\webapp\ROOT中生成test.jsp文件,内容如下：

<html>

<head>

<title>Tomcat1</title>

</head

body >
<center>

<h1>Tomcat 1</h1>
</body>
</html>

机器2的配置：xp,Tomcat33

假设：tomcat安装在c:\tomcat33

在c:\tomcat\webapp\ROOT中生成test.jsp文件,内容如下：

<html>

<head>

<title>Tomcat2</title>

</head

body >
<center>

<h1>Tomcat 2</h1>
</body>
</html>

启动两台机器的Tomcat,然后再启动Apache

打开两个IE窗口分别访问http://机器1/test.jsp, 则返回tomcat1和tomcat2（lbfactor取值相同的情况下）

若以刷新页面的方式，重新访问test.jsp页面时，返回相同的内容

1.Eclipse中设置原代码和输出路径

2.建立工程：Lomboz J2EE Project→J2EE Project Creation Wizard

    命名→添加Web模块和Ejb模块和目标服务器（Jboss）→完成

3.Lomboz EJB Creation Wizard

4.Lomboz Ejb Method Wizard

5.Lomboz J2EE→Add EJB module

6.选中EJB模块→Lomboz J2EE→Generate EJB Classes

7.Deploy

8.建立Client

J2EE是指Java的企业级应用，核心可以分成两块，一块是Web组件，另一块则是业务逻辑组件。Web组件包括Servlet和Jsp技术，业务逻辑组件主要是指EJB技术。

另外，J2EE还包括JDBC，JTA，JMS，JNDI等，以实现Web组件和业务逻辑组件之间的连动。

1.wordbench：工作台, Window⇒New Window

2.Perspective

3.resouse perspective

4.Java Perspective

5.package

6.import

7.Java Browse Perspective

8.debug perspective

9.CVS

10.层次perspective

11.Plugin perspective

12.Editor

数字内容的概念很容易与软件混淆。软件主要是指能够让计算机工作的程序或者在计算机中运行的程序。大致分为两类：操作系统（OS）和应用程序（如word之类）。

我们平常所说的多媒体教学软件可以称得是一种软件应用软件，但是由于这些软件所用软件技术成分较少，其价值是在于其内容，所以把它归为是数字内容的一种更为合适。因为数字内容的开发手法和软件开发应该有很大区别，如果单纯的使用软件方法去开发数字内容，则带有很大危险性。另外，对开发商来说也会该来运营的误区。

数字内容是指以数字数据表现的文章，音乐，图像，影像，数据库及其组合的信息集合。

RUP和XP开发流程管理的两种方法。

RUP是Rational Unified Process的缩写。RUP主要从管理的角度出发，强调反复型的开发，将整个开发过程分为4个阶段：Inception,Elaboration,construction,Transition。

阶段1，以需求分析为主，建立系统整体像。

阶段2，针对第一阶段需求分析结果，进行设计，编程，测试，然后再反馈到需求分析

阶段3，对第阶段的需求进行设计，编程，测试，反馈。重复需求，设计，编程，测试的过程

阶段4，综合测试

XP主要从编程人员的角度出发，需要一定的条件，对编程人员的素质要求较高。

1.避免重复

2.提高各个部件的独立性

3.避免依赖关系循环

软件建模包括三个部分：业务分析，需求定义，设计。

业务分析：整理现实世界的工作流程（why,为什么需要软件）

需求定义：决定可以由计算机分担的工作范围（what,软件能干什么）

设计：决定软件如何做（how,如何实现软件）

软件不是为了描述现实世界，而是替代现实世界的一部分。

所谓的虚拟现实也并非和现实世界一模一样，是把相似的留下，把不同的去除。

面向对象技术实现了用软件来描述现世界的提法是有争议的。

面向对象编程的三大要素包括：封装，继承，多态。

oop是在结构化语言的改进和扩充的基础上发展起来的。封装是在变量，函数或子过程集成的基础上，把仅在内部使用的变量，函数或子过程隐藏起来。

编程语言大致经历了以下阶段：

1. 机器语言
2. 汇编语言
3. 高级语言
4. 结构化语言
5. 面向对象的编程语言

语言间的简单关系：

2 3 4 5⇒编译器⇒1⇒执行环境

OO技术包括以下几个方面：

1.OOP，即面向对象的编程。

2.可重复利用的组件，如：类库，框架结构，控件等

3.设计模式

4.UML

5.建模，包括业务分析，需求定义，设计等

6.开发流程

这是中国人民大学硕士学位论文 论文题目： （中文）领域本体建设的方法论和工具研究

作 者： （中文名） 袁 媛

以下是部分摘要：下载

在“通用网上知识编辑器及示范主题语义网研究”项目中，我们的目标是建立起一个以经济学、法学的学科资源为例的示范语义网，即通过领域本体的支持，对现有资源加工整理，进行语义标注。因此，我们的本体建设工具有两个明确的任务，一是辅助领域本体的建设，二是辅助文本标注。这两个任务是相辅相成的，利用建设好的本体可以对文本自动标注，自动标注的结果并不一定准确（和本体的规模有关），知识工人对自动标注的结果
进行修正，修正的过程反过来影响本体，使本体不断进化。

在整个系统的体系结构中，领域本体建设工具位于中间层次，它包括文本抽取工具，本体构建工具和文本标注工具，其下是来自于Web等信息源的各种文本。文本抽取工具对格式不规范的原始文本进行加工，本体构建工具支持知识工人协同编辑领域本体，文本标注工具协助他们标注资源，从而生成语义Web中的领域本体和经过标注的文本集，向上为用户提供各种信息服务的API接口。

和其他的本体建设工具相比，我们设计的工具具有如下主要特色：

􀂾 结合原型法，提供一个集文本抽取工具、本体构建工具和文本标注工具为一体的本体建设环境。

􀂾 支持领域本体编辑的协同工作。通过权限控制，每个用户在建设过程中可以充分表达自己的观点，最后由一个相对权威的人来对这个结果进行审批。不同用户通过不同的视图浏览本体。

􀂾 辅助本体建设的进化过程。在文本标注工具中增加本体编辑的接口，知识工人在标注的同时可以对已有本体进行编辑，从而使本体得到进化。

􀂾 支持OWL语言，后台采用数据库存储本体对象。

 􀂾 支持中文的本体建设和文档处理。 在文章的最后，以经济学学科为应用领域，建立了一个初步的本体，并用OWL文件描述，为进一步的实践工作打下基础。

在语语义网研究论坛里发现一篇关于Ontology的一篇好文章：

Ontology理论研究和应用建模——《Ontology研究综述》、w3c Ontology研究组文档以及Jena编程应用总结

以下是文中关于Ontology和语义网比较的部分:

 Ontology和语义网络的联系和区别列表如下：

回顾，半年前曾在语义网研究论坛参与讨论语义网和本体论，但没有深入下去。内容如下：

 sophiebb

目前看了一些关于语义网和本体论方面的资料，但是有个疑问到底本体与语义网之间的关系是怎样的？本体是语义网的一种实现方式吗？

baojie   头衔: 论坛坛主
 
  本体, 是逻辑的一种, 描述概念和概念之间的关系

本体论语言, 是一种描述web上概念和概念之间关系的一种可实用的语言. 它将逻辑定义和关系用一组限定的词汇进行表达, 采用XML的语法以适应web上传输的需要.

语义网是对web的一个扩展, 是要把web上的资源(比如一篇文章里的关键词的含义和主题思想)用本体论语言标注明确其语义, 然后进行基于语义的查询. 所谓基于语义的查询, 也就是一个对本体进行逻辑推理的过程.

语义网的基本战略思想, 就是把已经很成熟的逻辑主义人工智能具体运用在web这个领域; 准确的说, 就是用本体来进行web上的知识表现(knowledge representation).
 
 
  baojie   头衔: 论坛坛主 
  所谓常说的"信息是机器可理解的", 无非是说它是用逻辑语言描述的, 可以进行推理. 逻辑的优势是精确的知识表现(是神经网络等连接主义人工智能目前所办不到), 和在这个基础上的可以保证其正确性的推理. 几种最重要的web应用: 检索, 信息集成, 远程调用(也就是web service), 都依赖这种能力. 所以本体极大的促进了语义网的发展.

语义网可以做逻辑主义能做的事, 但不会有更多的智能 - 除非我们在本体的知识表现能力之外, 扩展其"泛化"的能力(这正是逻辑主义的弱点).   
 
  baojie   头衔: 论坛坛主 
  语义网依赖本体来实现, 目前也没有其他的实现形式.
但是本体还可以用于其他方面, 不仅是语义网
 
  linmi  
 
  语义网提出基于WEB的本体描述语言OWL

语义网没有提供本体建设的方法  
  
  baojie   头衔: 论坛坛主 

   "语义网没有提供本体建设的方法"这个说法太模糊. 本体语言的规范和本体的建设本来就是两个问题. 就好像C++语言的设计和软件工程以及具体的软件开发, 项目管理是两个相关但是不同的问题.

何况目前在语义网界还是很多ontology management, ontology learning方面的工作的.   
 
  linmi  
 
语义网所定义的本体论和人工智能上定义的本提论还是有很大区别别的,最明显的一个说法是语义网希望有一个不需要专家参与建设的本体论,而目前的本体论建设方法好象都离不开专家?
因此,我觉得语义网需要研究本体层如何构建.
 
  baojie   头衔: 论坛坛主 
 
  语义网研究界也没有奢望一个自动建立的本体阿
没见过任何一篇论文有这个企图的  
 
  npu007   
  baojie分析得很透彻！！！

本体更多的应该是语义网的前提，反过来语义网并不是要专门研究本体。

关于本体和Logic，JOHN F。SOWA的经典著作Knowledge Representation的第二章是这样说的：“在逻辑中，存在量词是声明某物存在的符号。但是逻辑本身没有词汇来描述存在的这个东西。本体填补了这个缺陷：它研究存在，所有实体的种类——抽象和具体的——从而满足这个世界”

原文：In Logic, the existential quantifier （存在符号） is a notation for asserting that something exists. But logic itself has no vocabulary for describing the things that exist. Ontology fills that gap: it is the study of existence, of all the kinds of entities--abstract and concrete--that make up the world.
 
 
 

软件测试大致可以分成以下6个阶段：

1.单项测试

2.综合测试

3.功能测试（也称为最终用户测试）

4.强度测试（同一多次重复测试）

5.成品测试

6.反馈测试

仕样和课题之间需要进行妥当性验证

设计和仕样之间需要进行正当性验证

课题和设计之间则是反馈和重复的过程

课题的出发点是业务需求

仕样的出发点是系统需求

设计的出发点则是技术的革新

设计包括以下几项：

1.系统构成图

2.软件构成图

3.中间件

4.框架结构

5.组件

6.应用程序

仕样可由以下几个项目构成：

1.用户及业务功能访问对应表

2.4WD(Who-Where-When-What Diagram)

3.UseCase

4.域模型（制约条件，共通处理等）

5.业务逻辑（基本功能和操作）

Oracle的几个默认用户：

课题可以分为两类，一类是已有模型改善，另一类是新建模型。

已有模型改善包括以下几个项目：

1.改善项目一览

2.事件响应模型

3.业务规则等等

新建模型则包括以下几项：

1.对象模型

2.流程模型

3.业务规则等等

近期在读一本日语的软件开发书籍《课题 仕样 设计》，其中仕样是指详细规格说明（Specification）。本书论述了软件开发的三部曲：

首先是寻找问题，其次是解决方案，然后是设计。

Protege是一个Ontology的编辑系统。

Protege OWL-plugin是Protege的一个插件，支持语义网的本体论语言（OWL）。

http://protege.stanford.edu/plugins/owl/

GoFデザインパターン一覧（。中国語）

近期在重修Java,想深入地理解面向对象的思考方式。23种设计模式也称为GoF设计模式，是由Gamma, Helm，Johnson， Vlissides简称Gang of Four,缩写GoF，编著的《Design Patterns》一书中被定义的。日语版

1.       5种创建模式

Factory Method：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。

Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
Builder：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
Prototype：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
2. 7种结构

Adapter：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
Composite：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
Decorator：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
Facade：为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Flyweight：运用共享技术有效地支持大量细粒度的对象。

Proxy：为其他对象提供一个代理以控制对这个对象的访问。
3．11种行为
Chain of Responsibility：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
Command：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
Interpreter：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
Iterator：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
Mediator：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Memento：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
Observer：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。 
State：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
Strategy：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
Template Method：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Visitor：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

XP的三种见解：

其一：中医药大学的徐老师，良师益友。

其二：微软的操作系统，天天用之。

其三：eXtreme Programming的缩写，，软件开发的一种方法，中文多译为极限编程。

去年9月份曾计划领悟领悟XP的妙论，但因学无用武之地为由而放弃，一放就是一年，不由得感叹时间的快！书归正传，我们还是来讨论讨论第三种XP。

XP的目标是实现在快乐中进行软件开发。其实，我们大家都知道做软件是苦力活，干到深更半夜是常事，甚至是通宵，毫无快乐可言，最多是以苦为乐。XP则将实现软件开发者的真正快乐，在XP下，我们告别深夜加班，实现正常的生活。软件的目标之一是让人可以从繁重的计算和事务处理中解脱，但现实中却把开发者陷于繁重的工作之中，真是不合理！如何才能把开发者从繁重的工作中解脱出来呢？XP做了回答，其几个重要特征如下：

1.设计的简单化（尽可能的最小功能，这是极限的精髓）

2.两个人配对开发

3.软件用户参与开发

4.测试驱动开发(测试先于开发，先考虑编写测试程序，然后编写功能程序)

H. Yu 等：用UMLS语义网表达基因知识(Representing Genomic?Knowledge in the UMLS Semantic Network )
    　　统一的医学语言系统(Unified Medical Language System, UMLS)，是医学语言标准化的成果。该文是UMLS的应用类文章。

另参见

http://www.cmia.org.cn/xsyj/2001/p5.html

[摘要] "统一的中国医学语言系统" 旨在建立一个计算机化的可持续发展的生物医学检索语言集成系统。该系统由三个部分组成：中国医学用语数据库、中国医学用语语义网络系统、中国医学用语与标引检索语言对应转换系统。该系统的研制在医学文献计算机辅助标引方面发挥着积极作用，在一体化信息检索系统的开发研制方面具有重要作用。

[关键词] 统一的中国医学语言系统 计算机辅助标引系统 一体化信息检索系统

I.  Episodic vs. Semantic Memory

II.  General Issues

III.  How to study Semantic Memory

IV.  Network Models

V.  Feature Comparison Model

VI.  Conclusions

智能信息处理，它与网格研究的共同点是如何消除信息孤岛和知识孤岛，实现信息资源和知识资源的智能共享。这方面研究常见的名词包括

语义网（Semantic Web）、

知识管理（Knowledge Management）

知识本体（Ontology）

智能主体（Agents）

信息网格

知识网格

一体化智能信息平台等。

我将抽点时间继续研究rough。

这是开篇的宣言，一但有了新的心得，马上在此发布，与大家共享，也希望能得到建议，即使只言片语。。。。。。