| 基于软件工程开发的领域本体构建研究 |
|
|
|
求在特定的设计团队中适用吗？
③需求满足。需求能够满足吗？两个或多个需求间相互冲突吗？更高抽象级别的需求怎样满足评估？
④文档生成。需求属于哪类文档？哪些是与需求文档中的段落相符的需求？不属于客户报告的需求有哪些（商业机密）？
⑤升级。这是需求的最新版本吗？需求的旧版本有哪些？为什么还要改变需求？变化对需求文档的一致性和完整性有影响吗？
（2）考虑复用现有领域本体
一些本体已经初具规模，可以在网上找到相应的本体库及相关资料，在具体开发之前，有必要在这些本体中寻找系统可以重用的本体，这样可以省去元本体和顶层本体的建立，而把本体建立的目标重点放在领域本体的建立上。
2.2.2领域本体分析阶段
（1）定义类和类层次
类描述了领域的概念而非单词。在类和类层次的定义过程中，需要依据以下8个原则：
①确保类层次的正确性
恰当使用is—a和kind-of等类间关系，is-a关系指类A是类B的子类，前提是B的每个实例也是A的实例。类的子类表示概念是kind-of父类表示的概念；层次关系间具有传递性，并应区分直接子类和间接子类的关系；避免类层次的循环，确保类层次随着领域发展而进化。 ②分析类层次中的兄弟关系
在类层次中，兄弟关系是同一类的直接子类，并在同一抽象级别上。关于直接子类的个数并没有明确规定，但父类一般只有2-12个直接子类，过多或过少不都合适。
③多重继承关系
一个类可以是几个类的子类，则子类的实例是其所有父类的实例，子类将继承所有父类的属性和关系约束。
④引入新类的时机
当类的子类有其父类不具有的新属性，或有已定义的新属性值，或覆盖父类属性的约束，此时可以引入一个新类。新类可以没有任何新的属性，没有必要为了一个额外的限定条件来创建新类。
⑤新类或特性值
如果有不同属性值的概念变成其他类中不同属性的约束，则应该生成新类，以便加以区别；类的单个实例不应经常改变，当使用概念的外在（非固有）属性来区别类时，这些类的实例将需从一个类移动到另一类。
⑥类或实例
判断类结束和单个实例开始上一页 [1] [2] [3] [4] [5] [6] [7] [8] 下一页 |
|
|
| |
|
上一个论文： 浅谈卓越软件工程人才的培养
下一个论文： 静物油画的姿态 |
|
用户登录 
新用户注册 