Establishing a service oriented composite

applications development process

for supporting work- based learning and

competency progression management

Hilary Dexter

Jim Petch

Dan Powley

University of Manchester: Distributed Learning

TenCompetence Workshop January 2007

Terminology

SOCAD: service oriented composite application development

•CBD – Component Based Development• Mature concept – autonomous addressable units• Well established development methods but no large scale

application assembly•SOA – Service Oriented Architecture

• The Web gives new life to CBD – enabling technologies• Still talking about roadmaps to SOA

•Composite Applications• Concept from Gartner (1997) – a vision of agile assembly• Engage multiple applications and thus require integration of

distinct data models and processes•SODA – Service Oriented Development of Applications

• Moving towards establishing a development discipline• Progressively create new components as services, and

combine them with existing services

service oriented composite applications development process for supporting work- based learning and competency progression management

MLE VLE MIS

Technical Mechanisms

C1C2

WS1

C3

C5WS4

WS2WS3

C4

C6

SERVICE COMPOSER

Infrastructure

C8 C9C6 C7

C10

SOCAD Framework

Dynamic Composition of Applications

C1

C3

C5

WS2

C6

C10

C4

New Composite Application

REQUIREMENTS

(Business )PROCESS

TenCompetence Workshop January 2007

The Goal and the Issues

The software development goal is to be able to provide future composite applications from a set of high quality, tested and validated services and components. The development process has to provide systems that can operate in:

• Real environment – integration, change• Real scale – the enterprise• Real complexity – the distributed organisation

This has to be planned and managed since it won’t come about of its own accord. It demands:

• Consistency – vision, vocabulary, granularity• Mature development process – documented, managed,

optimised

TenCompetence Workshop January 2007

The Domain Context

• managing in depth reflective learning;

• creating and maintaining a teacher portfolio;

• providing a learning opportunity bank mapped to a

structured curriculum;

• integrating both formative and summative assessment data

with learner competency profile;

• cross-institutional provision of workplace learning.

In a current project , HeLM (Horus e-Learning Management), the development team is developing services for:

TenCompetence Workshop January 2007

Service Specification Requirements

• Merge with the existing functionality of the Horus

service;

• Operate in new domains, such as dentistry,

pharmacy and audiology;

• Extend to support lifelong learning, considering the

requirements for portfolio integration and an

appropriate skills and competences profile;

• Identify potential generic services.

Service specification has to:

TenCompetence Workshop January 2007

Running Horus

TenCompetence Workshop January 2007

HORUS e-Learning Management: sub-domains

This is not the application architecture!

Each sub-domain has its own domain experts, context and workflows

There is some overlap and some conflict of terminology and viewpoints between the sub-domains

TenCompetence Workshop January 2007

The Development Process Deliverables

TenCompetence Workshop January 2007

Factors for the Move to Successful Service Oriented Composite Application Development

• Model driven development – the model is the system

• Process capability and maturity with continuous monitoring

and evaluation

• System requirements traceability maintained all the way to

the services

• Bridging between domain experts and the technical

implementers

• Supporting the team members with process guidance

TenCompetence Workshop January 2007

The Workflow

TenCompetence Workshop January 2007

Roles and Activities in SOCADActivity Index

Activity Primary RoleAdditional

Role 1Additional

Role 2Milestone

Deliverable

model the domain1 Identify set of domains domain expert2 Elicit requirements from domain

expertssystem analyst domain

expert3 Elicit requirements from

stakeholderssystem analyst domain

expertstakeholder

4 Collect documentation from domain expert

system analyst domain expert

5 Write usage narratives domain expert Usage narratives6 Identify roles in the domain domain expert system

analystSet of roles

7 Identify objects in the domain domain expert system analyst

Set of domain objects

8 Abstract Use Cases from usage narratives

system analyst QA Set of Use Cases

9 Create context diagram for Scope system analyst Context Diagram

10 Collect non-functional requirements

system analyst technical architect

Set of non-functional requirements

A section from the HeLM task list

TenCompetence Workshop January 2007

An early stage application architecture for HeLM

An e-Patio for HeLM domain – with thanks to Mark Stubbs (XCRI)

TenCompetence Workshop January 2007

Thank you for listening.

Questions?

If the community is embarking on a long term complex,

collaborative venture to develop a component-based

service world then a major risk is variety in quality, design

philosophies, granularity and ontologies.

A key factor in minimising this risk is a sound method for

project analysis and management that is understood and

shared across the development community.