The Table

Adaptor	-
This appears to act as a Middle-Layer to provide easier access to Hardware specific components, from which data is to be obtained!

Afw OPC Server	Proxy
The Client-Server nature of the AIP system supports the creation of many proxy-like components so as to ensure abstraction and loose coupling of clients and servers. This also facilitates fault tolerance. The Aspect Framework provides many of those proxy-like components to the applications on top of the AIP system.

Afw Service Handler

Stub

Again in the spirit of Client-Server, each client gets a service handler. The service handler makes all the necessary calls to servers within the network in order to obtain a provider to delegate the clients' requests. Unlike the typical stub, there are not updates of stubs for new services. All updates are handled through a clever and a bit complex Naming Server and Naming Service by the AIP system. There seems to be a great deal of client server communication and I do not see how the over all performance is handled. Is it entirely up to the system or does the programmer have a say on this? For example how many handlers do you have caching handler objects? How are large (in size) requests being handled since you have to deal with Network bottlenecks?

Afw Service	Daemon
This is identical to a Daemon process, an around the clock process that accepts requests and assigns the appropriate process/thread/resource to handle the requests. (c.f. FTP-daemon with a pool of service threads )

Aspect

A more constraint definition for the typical Object in OOP

From an OOP point of view: "An object is a self-contained entity that consists of both data as well operations (procedures/methods) to manipulate the data." From ABB's Aspect Definition: "A representation of a facet of a real world entity, which is represented as an Aspect Object. An aspect defines a piece of information, and a set of functions to create, access, manipulate the information." Appears to be a slice of an Object. The fact that each aspect only deals with one piece of information seems to be a further division of an object but with the restriction that only one piece of information is to be encapsulated by each instance.

Aspect Category	A notion to further create Types for Aspects
This looks, at first, like "Java Packages" but the extra ability to further add properties to the whole Category gives it a "Type" flavor and another way to group related Aspect Types and to add properties to them as a whole. From ABB's Definition: "A generalization of an Aspect Type." A notion of further grouping of Aspect Types. Aspect Categories include other Aspect Categories.

Aspect Framework

Similar to AMF but with extensions for API and tools

The Aspect Moderator Framework (AMF) uses the same conceptual technique. That is, a Framework that will facilitate deployment and integration of aspects. However for the framework to be usable, aspects have to conform to a specific implementation form (API). The AMF being a much more simplistic design than the Aspect Framework, does not have some of the additional features. Conceptually though the two ideas share a common ground.

Aspect Object

Meta-Object (?)

The Aspect Object itself, is simply a place holder for ABB Aspect implementations. The Aspect Object, to the user, is the encapsulation of a real world entity (a valve or a pump). From the above two observations the closest programming term that I could relate Aspect Objects with is a Meta-Object.?theo: a meta-object can provide a new implementation of method calls, for example. I think that aspect objects are very close to objects. Or we can say that an aspect object is a composition of object slices.

Aspect Object Architecture	-
Defines the Aspect Object concept along with AIP, Afw, the systems topology, concepts rules etc. Appears to be a term to refer to the whole idea ...

Aspect Object Type

Abstract Type

From ABB's docs : An Aspect Object Type defines certain characteristics that are shared between several Aspect Object Instances, such as a basic set of common aspects. The way that this is defined is something along the lines of an abstract type that holds a skeleton definition of its interface (in this case aspect references) which I can reuse to instantiate Aspect Objects, instead of defining Aspect Objects from scratch for all my pumps, I could define some general Aspect Object Types for Valve1, Valve2 etc. and instantiate those.

Aspect System	Aspect Module/Package
A software system which implements one or several aspect types by providing one or more aspect system objects. An aspect package, or aspect Module which contains ABB aspect definitions. The Aspect System makes available (some) of its definitions to clients.

Aspect System Object (ASO)

Moderator in AMF

The Moderator in AMF is responsible for following up which aspects (in the AOSD sense of an aspect) are to be evaluated and in what order. Also the moderator holds information as to where these aspects are. Although the position of the Moderator in AMF is not at the same place as the ASO in AIP, they seem to share the same (general) functionality. However ASOs tend to have a lot more operations related to their behavior than a moderator in the AMF.

Aspect Type	Aspect
An Aspect Type represents the implementation of a certain aspect. I think Aspect Types are more close to the notion of a definition of an aspect. A class in OO terminology from which definition will be carried to the instantiated aspect when creation of the aspect occurs. Similar to how one would code an Aspect in AspectJ. ?theo? any pointcuts in an aspect type?

Composite Aspect Object	Aggregation of Aspect Objects
An Aspect Object that contains other object instances. Containment is implemented by having other objects as children in one or more structures where the composite object is placed. This is similar to the "has-a" relationship in OO but deals with aspect objects instead of classes. Aggregation for aspect objects.

Composite Aspect Object Type	Code definition of Composite Aspect Object
A composite Aspect Object Type describes a set of Aspect Objects organized in a structure. Holds the definition of the structure that a Composite Object has. Note that the structure defines a parent and siblings. The siblings being aspect types defined elsewhere. The sibling instances are only visible to the parent. There is a notion of scope here.

Connectivity Component	Driver and Libs
Bridges the gap between hardware specific calls and the Aspect Object Architecture. Provides extensions to the Aspect Framework so that access to devices and information is now available through Aspect Objects and correctly defined interfaces. The Connectivity Component also provides the building blocks for the GUI components to the device.

Connectivity Package

Device Driver/Libs module

Connectivity Components, up-loader, supporting aspect systems, graphical elements, faceplates, Aspect Object Types, bundled together to provide the integration of a certain type of devices. ABB's device driver package. Loading this package into your system will provide all necessary aspects and services to your new device within your system. The packages is also aware of how to register, publicize and integrate all its new information with the overall Aspect Object Architecture.

Connector

Attaching mechanism in AMF (?)

Connector seems to be the part of the Afw Server that deals with the whole mechanism of adding the new Connectivity Components found in a Connectivity Package. As far as Runtime Adaptability goes, AOSD seems to have 2 proponents. AMF and JAC. JAC uses Wrappers and Reflection so that new Aspects can be incorporated. The AMF uses Reflection. The difference between AMF and JAC is that AMF is language independent while JAC uses certain extensions to its platform (Java being that platform). The general notion of Runtime Adaptability and Reconfigurability is still a very new area in AOSD and AIP seems to go about it in its own way! The work at BBN about run-time adaptability with respect of quality-of-service is also relevant here. BBN QuO. [2].

Faceplate

An Aspect (Concern)

Faceplates appear to (from the Docs that I have the section on Faceplates is not there) to be related to the GUI interface of Aspect Objects. Depending on who and with what properties is to view an Aspect Object, a Faceplate defines the accessible components of a device along with its corresponding GUI definitions. This has the flavor of views. One could essentially provide similar behavior with context sensitive AspectJ aspects that are enabled according to who and from where a resource is accessed.

Graphic Display

An Aspect

An aspect that provides the visual representation of devices. These three (AOSD)aspects (Faceplate, Graphic Display, Graphic Element) encapsulate all GUI interactions of Aspect Objects and user operations. As such all Aspect Objects have a way of being displayed, and operated on by the user. These are specialized aspects in my view, that have global quantification over the GUI operations that can be performed on an Aspect Object.

Graphic Element	An Aspect
An aspect that is associated with an Aspect Object Type. This is used in graphic displays to represent dynamic information for instances of that type. See Graphic Display above!

History Collector	An Aspect
A specialized aspect that deals with providing information about the history of data. This is yet again a specialized aspect that the AIP system uses regularly. Documents indicate that this aspect facilitates better performance than the corresponding OPC/DA operations to gather this historical information.

Object Display	An Aspect
An aspect that provides displaying and tuning facilities to an Aspect Object. [ Note: NOT AN ASPECT OBJECT TYPE]. A specialized aspect that is shared (used) by all Aspect Objects. Allows for the GUI interaction with an instance of an Aspect Object Type.

Object Trend	An Aspect
An aspect to represent curve representation of historical values. This looks interesting. There seems to be an aspect interaction between this aspect and the History Collector. Object Trend is yet another GUI specialized aspect that allows plotting (or displaying as a curve) the historical data about an Aspect Object.

Up-Loader	Loader for Objects/Aspects
Used to 'import' a configuration from a device, to read in and build a set of Aspect Objects from the information present in the device. A factory pattern (!). Although information is read in from the device and then all necessary objects/aspects are instantiated as needed. Maybe a more appropriate mapping would be something like Java's ClassLoader.

Certain AIP aspects (e.g. History Collector)

Crosscutting Concerns

Some of the aspects found in the AIP system do exhibit this sort of behavior with the History Collector being one of them. The key identification point is the fact that the aspects only have some semantic meaning if deployed between specific operations. A history collector on a system that does not alter its data is pointless. However a history collector that collects information according to modifications (before and after) is of greater use. A crosscutting concern is a concern whose implementation results in its corresponding code being tangled with the implementation code of other concerns.

Aspect Object Types

JoinPoints

It appears that in AIP JoinPoints are the Aspect Object Types since that is the place where one can introduce extra behavior. The introduction can happen at Aspect Object Type definition, at Aspect Object deployment or even at runtime. A JoinPoint is defined as the point of execution to which extra behavior can be added (a "crosscut"). These JoinPoints can be static (denote static program information and could be identified statically) or dynamic in nature (denote points within the program that require runtime information in order to be determined).

-

PointCuts

It appears that in AIP we have to explicitly define one by one all aspects that are to be part of an Aspect Object. As such there is no mechanism (as far as I have read) that would allow the introduction of an Aspect to a set of Aspect Object Types. A PointCut refers to the way by which one can denote a set of join points. A join point is either (dynamic case) a point in the execution of a program or (static case) a point in the program text.

Aspect Objects along with .COM technology

JoinPoint Model

In AIP this seems to be the notion of Container Objects that can be defined to hold any number of Aspects. This containment definition is mostly static although via .COM technology one could extend an Aspect Object at runtime. So I would say that its a static Open Class model with runtime reconfigurability. The join point model refers to the frame of reference, that an AOP system uses, in order to provide and define the points of crosscutting between concerns.

History Collector and Object Trend	Non-Orthogonal Aspects
From the definitions of both the History Collector as well as the Trend Object one could deduce that the 2 are non-orthogonal. So within AIP non-orthogonal aspects are supported. This refers to a pair (or more) of Aspects that are co-dependent. Co-dependent here means that the operations of one depend on data data and/or operation of the other.

-

Concern and Separation of Concerns

The term Concern is used to refer to a system concept (e.g. Logging is a concern, Synchronization etc). Separation of Concerns is the ability to design a system so that the different concerns are cleanly separated and encapsulated into loosely coupled entities. These entities, will interact in a specific way so as to yield the desired behavior of the overall application. The idea of Separation of Concerns is generally attributed to Parnas and Dijkstra. Note, that achieving separation of concerns does not necessarily denote Aspect Orientation. The argument with Aspect Orientation is that it allows for better separation of concerns than we already were able to achieve with other methodologies (e.g. OOP).

-

Multi-Dimensional Separation

The term was coined by IBM, under the HyperJ research project. The main idea revolves around Hyperspaces, Hyperslices etc. Conceptually, each concern is defined as a Dimension. Dimensions could them be separated and composed with other dimensions (concerns) to yield a new Hyperspace/Hyperslice. These dimensions are essentially portions of your class hierarchy(ies) which you identify as a Concern that you would like to extract/concentrate on. The tool developed by IBM (HyperJ) that support the ideas works with Java .class files.

-

Structure-Shy

The term is used under the Demeter tools. DemeterJ (and DJ) allow for traversing object/class structures through the usage of Visitors. The programmer has the ability to direct the path along the class/object structure which the Visitor will traverse through. The specification of the path to be taken (i.e. the Strategy) can refer to only important object/classes in the traversal. As such, changes to the underlying class/object structure will not affect your Visitor and its behavior. Achieving adaptable programs and structure-shy encapsulation to traversal-related behavioral concerns. DJ uses the notion of an object graph slice. An object graph slice defines a slice of an object o that cuts across multiple other objects with which o collaborates. Using DJ, we define the behavior of an object o by combining multiple object graph slices rooted at o and attaching to each a visitor. This has a similar flavor as defining an aspect object using AIP.

-

Traversal Related Concern

Like a Concern, Traversal Related Concerns deal with system properties which require the collaboration of several objects/classes within your object/class hierarchy. Consider a software system that reflects the organizational structure of a large company and its employees (Managers, CEO, Developers etc.). The company has departments, each of which maintains its own Employee hierarchy. Each object in the employee hierarchy contains a field which denotes its salary. Calculating the total Salary that each department has is a traversal related concern, that can be encapsulated with the Demeter tools with a Traversal.

-

Weaving

In an Aspect Oriented System, we have Aspects that cut across other software components (Objects, Class, Aspects, packages etc). Each Aspect contains information as to when a piece of Advice(write a log message to a file) is to be executed (before the call to Valve.alert() ). The process by which the advice code(logging) is inlined with the base code (before Valve.alert() is called) is termed as Weaving.

-

Dynamic Adaptability/Reconfigurability

Dynamic Adaptability (in the context of Aspects), denotes the ability of an Aspect System which at runtime, could adapt and evolve without the need to stop the over all System. Addition or removal of aspects could be done at runtime without stopping the execution of the System. Reconfigurability and Adaptability are closely related since reconfigurability could be obtain through adaptability (by replacing the FIFO scheduling aspect with a LIFO scheduling aspect). However, reconfigurability could be obtained by directly altering code of already loaded aspects in your system.

-

Non-invasive Composition

The term is used mostly by the HyperJ group. Within the HyperJ context, the ability of HyperJ to compose Hyperslices without the need to alter the original source code from which a Hyperslice originated from. Recall that HyperJ works on Java .class files and thus does not require Java source code. Hyperslices can be created from a full blown application. HyperJ allows one to specify a concern (i.e. Logging) by pointing out the relevant method signatures. Having isolated the Hyperslices that you are interested in then you can proceed to compose them into a new Hyperslice, onto an existing application or create a new application from scratch. The ability to perform this composition without altering your original source code (either by additions, deletions or amendments) allows for non-invasive composition

-	Aspect
The modular encapsulation of a crosscuting concern. In general an Aspect holds the advice(behavior) that the Aspect introduces as well as a means to define points within the execution/structure of an application/software component where the advice would take effect.

-	Comparing Aspect Systems
The AOSD community compares AOSD systems by referring to their corresponding join point models. A join point model consists of a definition of a set of join points a means for specifying sets of join points (pontcuts) and a means of defining additional behavior at those join points (advice). See Communications of the ACM, October Isuue 2002.