Windchill系统开发技术三剑客
从Windchill的系统架构来看，主要支撑Windchill实现的技术有三个：
1、扩展Windchill Service的能力，在原有服务水平上增加系统的服务内容，通常表现为模型的扩展和事件监听器的实现；Windchill系统提供了Rational Rose模型，用户可基于该模型对系统进行扩展，产生自定义的数据模型和实现方法。
2、建立新的JSP页面，实现个性化应用，通常用于系统和用户的个性化交互；
3、利用Info Engine，实现基于HTTP和XML的服务协议，可以应用于各类非Java客户端，如.net/DELPHI/C++，当然也可以用于Java的富客户端。
这三个技术在Windchill的帮助文档中有相应的介绍，读者可以参考WCCustomizersGuide.pdf和IEUsersGuide.pdf。
对于Windchill的设计模型，用户可以使用Rational Rose打开系统的MDL文件查看各个包之间的关系和API。Windchill的类实现了许多接口，并且关系复杂，如果要做深入的开发，需要有丰富的面向对象的知识，同时需要对Windchill的设计模型有了解。
比如零件类图(WTPart)，实现了20多个接口，对象之间的关系非常复杂，同时系统也提供了详细的API文档，所以下一步我将介绍Windchill的几个常用设计模式。
Class WTPart {Analysis} derived from: PartVersion, RevisionControlled, ContentHolder, EffectivityManageable, ViewManageable, Baselineable, BuildTarget, IBAHolder, IteratedSubjectOfForum, RequirementsManageable, Federatable, Representable, Typed, ElectronicallySignable, UsesOccurrenceContext, AnnotationTarget, ConfigurationManageable, WTContained, Viewable, OrganizationOwnedVersion, Releasable, PathOccurrenceContext, PathOwner, ConfiguredVersion, Genericizable, ImportTrackable, IdentityAccessControlled, OVTemplate, Variant, ArchiveablePrimary, NoteHolder
Documentation
This reference implementation of a <code>PartVersion</code> represents a snapshot of the changeable aspects of a part, is managed by {@link WTPartService} and has an associated {@link WTPartMaster} which represents the unchanging aspects of this part. Many of the significant associations of parts happen at the <code>WTPartMaster</code> level.
<p>
Associations:
<ul>
<li>{@link WTPartUsageLink} links this <code>WTPart</code> to a <code>WTPartMaster</code> that it uses (actually it uses one of the <code>WTPart</code>s associated with the <code>WTPartMaster</code> based on a config spec)
<li>{@link WTPartSubstituteLink} links a <code>WTPartMaster</code> to a <code>WTPartUsageLink</code> making it (actually one of its <code>WTPart</code>s based on a config spec) a substitute part for that particular usage
<li>{@link WTPartAlternateLink} links one <code>WTPartMaster</code> to another that is an alternate part for any usage (alternates are NOT defined at this <code>WTPart</code> level)
</ul>
<p>
By virtue of its being {@link wt.enterprise.RevisionControlled} it can be:
<ul>
<li>checked in and checked out
<li>assigned to views
<li>baselined
<li>assigned to an effectivity
<li>hold content
</ul>
The intention is that this WTPart represents one stage in the development and change of the part. A part may have many versions (and iterations, which are like sub-versions) and a large part of the implementation of parts deals with making new versions (and/or iterations) from existing ones and selecting the correct version(s) or iteration(s) that is (are) relevant in a particular situation by using a {@link WTPartConfigSpec}. Much of the version/iteration functionality comes from being {@link wt.enterprise.RevisionControlled}.
<ul>
<li>{@link WTPartUsageLink} links to a WTPartMaster that is a component of this part
<li>{@link WTPartReferenceLink} links to a WTDocumentMaster
<li>{@link WTPartDescribeLink} links to a WTDocument
</ul>
@see wt.vc.wip for information on check in and check out
@see wt.vc.views
@see wt.vc.baseline
@see wt.effectivity
@see "Making Parts Content Holders" in Customizer's Guide"
@see wt.enterprise.RevisionControlled
@see "Part Abstractions" in "Application Developer's Guide"