FREMA: e-Learning Framework Reference Model for Assessment

Design Patterns for Wrapping Similar Legacy Systems with Common Service Interfaces

Yvonne Howard

Learning Technologies University of Southampton, UK

Background• What is FREMA?

– JISC funded Project between Southampton, Strathclyde and Hull– Aim to produce a Reference Model of the e-Learning Assessment

Domain– To aid interoperability and aid in the creation of Assessment Services for

the e-Framework

• What is the E-Framework?– Service Oriented Architecture for e-learning systems– Layered Web Services (Domain services over Common Services)– Dynamic and evolving

• What is a Reference Model for Assessment?– Assessment is a broad and complex domain– Not enough to describe and define a set of services– Need a proper audit trail of decision making– Start by defining the domain – Work up through use cases to services (and example implementations)– An evolving model– Allow the Community to contribute to every stage

Anatomy of FREMA Reference Model

• Domain Definition– Overview of the domain, and how projects and standards fit within it

Assessment Domain Definition

Use CasesUse CasesUse Cases

Service Profiles

Gap Analysis

Reference Impl’

• Identifying Common Usage Patterns– Scoping the FREMA Project

• Gap Analysis– Mapping of Use Cases to the Services in ELF

• Service Profiles– Formal descriptions of those services

• Example Implementation– Of key/core services– Examples– Validation– Resource

Common Usage Patterns

• Developing Use Cases– Formal descriptions of usage patterns

Semantic Wiki• Used to build a

semantic wiki (a wiki in which all the pages and links are typed)

• Can model all the levels of the Reference Model

• Enables Smart Searching and Analysis

– Semantic Search– Dynamic Gap

Analysis– Concept maps

• Open editing, but with Administrator controls

Analysis Tools: Gap Analysis

Service Usage Model

• Describes a scenario in which services work together

• Use Case Diagram

• Set of Abstract Logical Service Expressions

• Interaction Diagram

SUM: Description

• Formal as a Use Case Diagram

• Informal as a Narrative Description

SUM: Structure and Organisation

Service Expression

• Logical, abstract description

SUM: Functionality

• Workflow and processes

• Semi-formalised as a UML Interaction Diagram

Scenario: Technical Developer

Will, Technical Developer‘I want to lookup use cases and scenarios to help me design my application. This will help me to define my footprint in the assessment domain. I see there are some web services I could re-use but some are missing. What standards and patterns can I use when writing my own web services to ensure that I can interoperate with the web services I’ve chosen?’

Service Patterns

• Exemplar workflows– Described as patterns – Show how service interoperability can be achieved – Solutions to common interoperability problems

• Reference implementations of Service Patterns– WS–Interaction diagrams– WSDL– Java Code to download and install– Running services to try

Assessment Domain Definition

Use CasesUse CasesUse Cases

Service Profiles

Gap Analysis

Reference Impl’

Common Usage Patterns

Wrapping legacy systems with a service interface

• Legacy Systems may contain valuable IP

• Do we wrap legacy systems individually even if they have similar functionality?

• Or build small interfaces that legacy systems can support as appropriate

• Granularity issues– Too small = large design overhead– Too Large = bulky and inappropriate

• Goal– Consolidate functionality into only a few interoperable services

• Robust• complete

Design Patterns

• ‘Gang of Four’ description – Describes a recurring pattern– Its solution– Context in which it applies

• Patterns capture the experience of software engineering and design experts

• 3 patterns– LCD Lowest Common Denominator– MPI Most Popular Interface– NI Negotiated Interface

Lowest Common Denominator • Intent

– simplest common interface for 2 or more components which share some common methods

• Motivation– Similar legacy apps with overlapping functionality– Wrap with common interface– Direct relation between methods of common interface and

functionality of legacy systems

• Implementation– Strict intersection of functionality of legacy components– Create interfaces for individual components– Normalise methods then extract common methods– May have different data models

• Applicability– Feasible when intersection captures meaningful core

functionality

• Consequences– Simple to derive– Value depends of size of intersection– Loses functionality richness

Most Popular Interface• Intent

– Rounded, robust common interface for 2 or more non–identical components with some methods in common

• Motivation– Similar legacy apps with overlapping functionality– Wrap with common interface– Compromise interface– Reflects best practice

• Implementation– Set of methods, M, chosen by experts (best practice)

reflects community expectation of functionality– Legacy components intersection is a proper subset of M

• Applicability– Feasible when there is agreement on core functionality

that should be expected

• Consequences– Complex to derive– May need to create and hold additional information in the

wrapping service– May need analysis or mapping tables in the wrapper– May capture a broad set of functionality from legacy

systems

Negotiated Interface • Intent

– Flexible common interface, preserving richness for 2 or more non–identical components, some common methods

• Motivation– Similar legacy apps with overlapping functionality– Wrap with common interface– Enables all functionality of legacy systems to be

represented, but not necessarily available in all of the systems

• Implementation– Union of functionality of legacy components– Interface includes methods mthods to query which

methods are supported by the wrapped legacy system– Implemented by

• contract describing methods available• Or querying at run-time for method availability

• Applicability– Advisable when novel functionality not universally

supported is required in the interface

• Consequences– Cumbersome to define– Avoids complex decisions about definitive interface– Adds runtime complexity

Analysis Tools: Gap Analysis

Interface Implementations using LCD, MPI and NI patterns

• 2 legacy systems from the assessment domain– TOIA

• Free to use Question Management system• Includes an Item bank• Developed in UK for Higher Education use

– E3AN• Free to use Open Source ‘Item bank’ of QTI

questions

Legacy Item Bank Ontologies

LCD Interface

MPI Interface NI Interface

Web interface to wrapper service and results returned

Lessons Learnt• Writing wrapping services for legacy systems is non

trivial• requires close understanding of the data model (possibly reverse

engineering)

• Complexity rises in proportion to complexity of the data model and the interface

• Mapping terminology used in different systems is time consuming and non-obvious

• Implementations may Interpret Standards differently and may cause unexpected mismatched behaviour

• LCD is simplest and quickest to build but may exclude valued functionality

• MPI selects core methods based on expert judgement but may be expensive to build, as the wrapper may have to hold functionality translation

• NI represents all method in a framework, is flexible but adds runtime overhead of negotiation

and

…Thank You

www.frema.ecs.soton.ac.uk

ymh@ecs.soton.ac.uk