Using xArchADT

One of the most important components that you will call as an ArchStudio component developer is xArchADT, the main data store for all architecture descriptions.

This component exposes one interface, the IXArchADT . IXArchADT is a distributable (that is, it doesn't pass pointers) version of the interface provided by the Data Binding Library. Additionally, it exposes some low-level convenience functions that are not available in the Data Binding Library, like "find by ID" and "jump to parent." In order to use IXArchADT, you need to become familiar with the Data Binding Library.

Please read throught the Data Binding Library Example that shows how to write a program that manipulates an architecture description directly using the Data Binding Library. It also shows how to write the same example using the IXArchADT.

Now, let's look at how we translated the traditional calls to the Data Binding Library in the createUsingEMF method to calls that go through the IXArchADT in the createUsingXArchADT method.

The first major difference to note is that objects like Components and Connectors never get passed across IXArchADT. Instead, serializable object references, called ObjRefs, are sent instead. The next major difference is that, since ObjRefs are opaque, no calls are ever made on them directly. Instead, IXArchADT does all the work for you.

Translating a call from a Data Binding Library call to an IXArchADT call is easy, since it's merely a matter of rearranging some parameters. Here's a snippet that calls the Data Binding Library from the Data Binding Library example program:

	// Xadlcore_3_0Factory coreFactory = Xadlcore_3_0Factory.eINSTANCE;
	String coreNsUri = Xadlcore_3_0Package.eINSTANCE.getNsURI();
	...
	// Component componentA = structureFactory.createComponent();
	ObjRef componentARef = xarch.create(structureNsUri, "Component");	

Here, the DBL version (i.e., the commented out code) directly creates a Factory from which a Component is created. However, in the IXArchADT version, (i.e., the uncommented out code) the namespace URI of the factory is used and an ObjRef is returned for the created component. The actual factory and Component remain internal to IXArchADT, we only get serializable references to them that can be passed over a network.

Here is another code snippet from the example, where the component is modified:

	// componentA.setId("ComponentA");
	xarch.set(componentARef, "id", "ComponentA");

Again, in the DBL version, the component is directly manipulated. However, with IXArchADT, all object manipulations are done on our behalf. Thus, we tell IXArchADT which object we want to modify, what property on that object, and the new value and it performs the operation on the object for us.

By now, you've probably noticed that there are a lot of ObjRefs floating around. Due to the generality of the IXArchADT, it's impossible for the Java compiler to type-check all the ObjRefs being passed into it. So, you could pass a Link ObjRef where a Component object should go. If this happens, it will cause a runtime exception, most likely an IllegalArgumentException to be thrown.

xArchADT Events

As an event-based component, any change to the internal state of xArchADT is reported through an event. One type of event, an XArchADTFileEvent , indicates when files are created, opened, renamed, and closed. The second type of event, the XArchADTModelEvent is similarly emitted whenever the internal structure of one of the open xADL documents is changed.

It is your responsibility as a component developer to ensure that your component acts correctly when it receives an XArchFlatEvent or any similar event. Assumptions to the contrary need to be well documented.

Contact Us

If you have questions not answered by this website, please feel free to contact the software architectures group at UC Irvine through the ArchStudio developer's (mailman protected) email list at: archstudio-dev [@] uci [.] edu. (Note: You must subscribe to the mail list before you can post to it.)