Understanding Metamodels

Outline Understanding metamodels Applying reference models Fundamental metamodel for describing software components Content management system reference models

Understanding Metamodels Metamodels are “models of models”. A metamodel is a language for describing another model. Its like a grammar for a language. For example, UML describes the syntax of diagrams expressed in UML.

Three-Layer Model of Knowledge Representation Ontology layer – contains core concepts of abstractions and their relationships Domain layer – contains domain models, such as models of specific business domains Technology layer – composed of models that are the technology projections of the domain layer

Applying Reference Models A reference model abstracts software components and expresses the system as connectors and components. Reference models are common in mature domains such as HCI. A user interface is a type of connecting element and the user and the application are components.

Seeheim Model The Seeheim reference model for interactive applications is composed of three software elements: Application Dialogue control Presentation A fourth element, the user, interacts with the presentation element only

Seeheim Model (Cont’d) Presentation User Dialogue Control Application

Seeheim Model (Cont’d) The presentation logic is separated so that this component is aware only of presentation technology. It contains lexical knowledge. Application logic is separated so that this component is only concerned with the application level logic. It contains the semantic knowledge. In between is the dialogue control which translates user interface commands (lexical actions) into application commands (semantic actions). It ensures that the lexical elements are used in the correct context.

Seeheim Model (Cont’d) The Seeheim model addresses modifiability and portability qualities. By separating the presentation layer, the logic could be ported to a different user interface or windowing system. The separation of the dialog control from the application logic allows for changes in the interaction model without having to modify the application logic itself.

Arch/Slinky Model This is another metamodel for interactive applications and is composed of five elements: Presentation Virtual toolkit Dialogue control Virtual application Application

Arch/Slinky Model (Cont’d) Dialogue Control Virtual Application Virtual Toolkit Presentation

Arch/Slinky Model (Cont’d) The arch/slinky decomposition emphasizes portability and modifiability. The presentation and virtual toolkit components together correspond to the Seeheim presentation component. Separating these components allows a presentation component to be ported to a variety of presentation technologies without changing the dialogue.

Enterprise Application Reference Model Enterprise applications have a common set of archetypal components: A data store An application logic layer A presentation layer The application layer accesses and updates the data store. The presentation layer interacts with the application layer and potentially requires multiple technologies (e.g., , Web, client applications, Web services, etc.) The presentation layer provides input and output services to external entities (e.g., human users, other systems, etc.)

Enterprise Application Reference Model (Cont’d) accessor presentation layer utility physical presentation virtual toolkit dialogue control virtual application business layer data store/persistence layer organization application process resource utility organization process resource utility arch/slinky reference model 3-tier reference model business application ontology

Technology Stacks and Architectural Layers Although technology stacks are commonly used as architectural descriptions, the architectural layers do not typically line up with technologies. The use of a technology stack as an architectural description can be a source of confusion. In the design process, the application of technology should come later rather than sooner.

Fundamental Metamodel for Describing Software Components Software design axioms of Buhrer’s fundamental design pattern: The software must obtain input data from one or more external (hardware) interfaces. The software must deliver output data to one or more external (hardware) interfaces. The software must maintain internal data to be used and updated on every execution cycle. The software must transform the input data into the output data (possibly using the internal data) The software must perform the data transformations as quickly as possible.

Fundamental Metamodel for Describing Software Components (Cont’d) Buhrer defines four design elements that satisfy the above axioms: Data entity – Data entities represent the software system’s input data, output data, and internal data. This is a data element. I/O Server – I/O servers encapsulate the external (hardware) interfaces with which the software interacts. This is considered interacting with the hardware because data is stored somewhere like RAM, registers, or on disk. This is a type of connecting element.

Fundamental Metamodel for Describing Software Components (Cont’d) Buhrer defines four design elements that satisfy the above axioms (cont’d): Transformation server – Transformation servers perform the transformation from input data to output data. This is also known as a processing element. Data flow manager – Data flow managers obtain input data from the I/O servers, invoke the transformation servers and deliver output data to the I/O servers. They own the internal data. This is a type of connecting element.

Fundamental Metamodel for Describing Software Components (Cont’d) Buhrer describes this model as apattern upon which other patterns can be described. This makes it a candidate as a metamodel. We can use Buhrer’s model as an ontology for implementation components. All software embodies these capabilities, but that are not always explicitly identified as separate modules, objects, or functions.

Examples: Content Management System Reference Models Metamodels for a content management and publishing application Reference models that are useful for designing a publishing system.

Domain Model > Publishing Enterprise > Business Division > Content Authoring > Content Publishing > Content Delivery > Content

Domain Model (Cont’d) Activities of the content authoring and publishing process: Authoring/editing/assembling – creating content and source code for an electronic content product and assembling it into a collection. Snapshot (edition) – creating a snapshot of the repository content that defines a product (known as creating an edition). Compilation/production – creating a ready for delivery product. The content comes entirely from a snapshot and is specific to the delivery mode.

Domain Model (Cont’d) Activities of the content authoring and publishing process (cont’d): Deployment (manufacturing) – a tangible product is created (a book is printed or content is uploaded to a production Web server. Delivery/consumption – this is where a user receives or gains access to content.

Content Collaboration Reference Model The work area/staging area/edition model (WSE) It’s contents are: Managed asset – an atomic unit of version- controlled data such as a file or database entity. Work area – a branch that has a separate life cycle from its corresponding staging area but is periodically merged back into the staging area.

Content Collaboration Reference Model (Cont’d) WSE contents are (cont’d): Staging area – a collection of managed assets. A staging area may have one or more associated work areas. A staging area may also be a work area for another staging area. Editions – a versioned collection of specific versions of managed assets that can be retrieved at an arbitrary point in time. An edition is a snapshot of a subset of a staging area.

Content Collaboration Reference Model (Cont’d) The operations of the WSE are: Create work area – create a branch off of a staging area with current copies of managed assets. Submit – copy assets from work area to staging area. Compare – compare assets in staging area to work area. Update – copy from staging to work area, also know as synchronizing. Merge – Combine data in the staging area nad work are versions of an asset and resolve conflicts if present. Snapshot (edition) – create an edition

Content Management Reference Model The content management metamodel complements the WSE metamodel with the following types of services: Content storage – low-level services, including data storage and retrieval, indexing and searching, backup, and data import and export. Version control – version control semantics including asset versioning, locking, rollback, and file differencing. Branching – allows an asset to have several simultaneous versions with different histories, yet can be merged with other versions on different branches. Workflow – allows users to manage specific business processes around the creation and management of assets.

Content Management Reference Model (Cont’d) The content management metamodel complements the WSE metamodel with the following types of services: Meta data – used to communicate the structure of data from one system to another Publish and deployment – aggregate assets into sets and define the presentation content Subscription services – allows users to subscribe to syndicated subscriptions. Syndication services – the ability to syndicate content for other systems to consume

Summary Metamodels are useful tools for describing, understanting, and evaluating architectures. Metamodels are models for describing other models and can be thought of as a grammar for a class of models. Reference models are a type of metamodel that capture domain knowledge such as HCI and enterprise applications.

Summary (Cont’d) The arch/slinky reference model describes the components of an interactive application. The fundamental metamodel for describing software components in composed of a set of primitive building blocks for software components. The workflow/staging area/edition and content management models are useful reference models for describing content management systems.