This page provides details and resources to the revised human Architecture Description Language (hADL). The outdated and no longer maintained specification and hADL implementation in GME (Generic Modeling Environment) can be found here.
The revised hADL language is split into different specifications depending on its application purpose inspired by xADL (links point to the current XML schema definition in the master branch hosted in the bitbucket project: christophdorn/hADL ):
- hADLcore: defines the central elements such as human component, collaboration connector, and collaboration object, their actions, links, substructure, references, and cardinalities.
- hADLexecutable: defines elements for executing hADL elements through the mechanism of surrogates. A surrogates represents either a single human component, collaboration connector, or collaboration object and behaves as a wrapper around the actual collaboration system that provides the respective underlying interaction capabilities.
- hADLruntime: defines the elements that represent a running hADL model instance, tracking the instances of human component, collaboration connector, or collaboration object and their links and references. hADLruntime elements exhibit a link to their type (i.e., the hADLexecutable element) and status to indicate whether they actually participate in a collaboration, or are yet scheduled to join/leave.
- hADLcomposable: is intended for describing collaboration-centric configurations that are applied only at system deploytime and remain fixed during runtime (such as a MediaWiki based Wiki). See the joint work with Timur Sungur.
In contrast to the old hADL version based on GME, the revised version has the above XML schema as it’s canonical format. No graphical representation has been specified, although I repeatedly used a Visio visualization (which, however, doesn’t display all properties) for conveying the high-level structure and elements of a hADL model.
The purpose and expressiveness of hADL is best demonstrated through a set of examples.
The dual wiki use case of my ICWE paper with Timur (hADL model file) demonstrates the use of hADL to model and configure user permissions of the MediaWiki server, and how one can model a combination of two differently configured server instances.
In the motivating scenario (Fig.1 far left), project members, project editors, public read, public editor and public expert roles are the HumanComponents. The Wiki Quality Manager and Vandalism Detector roles represent CollaborationConnectors. They aren’t strictly necessary, but greatly facilitate collaboration. A CollaborationConnector is thus responsible for the efficient and effective interaction among HumanComponents. It thereby may cover the full automation spectrum: from purely human, to software-assisted, to purely software implemented.
Users employ diverse means of interaction that range from emails, to chat rooms, shared wiki pages, and Q&A forums, to vote collection. These means implement vastly different interaction semantics: a message is sent and received, a shared artifact is edited, a vote can be cast. CollaborationObjects abstract from concrete interaction tools and capture the semantic differences in subtypes, e.g., Message, Stream, or SharedArtifact.
In our example, the two Wikis ( Fig.1 mid left) provide collaboration in the form of a shared artifact, while the Alert notification provides messaging-centric capabilities. The actual notification mechanism may then be implemented through email, XMPP, SMS, or even a combination thereof.
Actions specify what capabilities a component or connector requires to fulfill his/her role, e.g., edit an article or receive an alert message. Complementary, actions on CollaborationObjects determine the offered capabilities. To this end, actions distinguish between Create, Read, Update, and Delete (CRUD) privileges. Action cardinalities further specify the upper and lower boundaries on the number of collaborators which may simultaneously have acquired the action’s capabilities. The Alert Notification Receiving action, for example, thus demands at least one component or connector having receiving privileges when exhibiting an action cardinality of (1..*).
Ultimately, Collaboration Links connect HumanComponent and CollaborationConnector actions to CollaborationObject actions, thus wiring up a particular collaboration structure. The Structure element provides a containment mechanism for complex, hierarchical CollaborationObjects and interaction patterns composed from the basic hADL elements. The scenario depicts the use of substructures for detailing the internal structure of each wiki collaboration object. The parent element references a pre-existing structure (here the Wiki Base Structure), and provides a mapping between parent action (e.g., Internal Wiki – Editing) and substructure action(s) (here Wiki Page – create, import …) via substructure wires (Fig.1 center, dashed lines). Multiple substructure wires between a single parent action and multiple sub actions imply aggregation semantics. Hence, the Internal Wiki editing action aggregates the Wiki Page create, import, import-upload, Page page-edit, etc capabilities. Likewise, two substructure wires from different parent actions to the same sub-action imply capability reuse, i.e., both parent actions make the sub-action’s capability available. The substructure mechanism thus allows different configuration of the same base structures. Internal Wiki and External Wiki only need to exhibit the desired substructure wiring without having to duplicate the Wiki Base Structure.