UML and WSDL for JISC e-Learning Projects Major Practical Richard Hopkins [email protected] NeSC Training Team Member [email protected].

UML and WSDL for JISC e-Learning Projects

Major Practical

Richard Hopkins [email protected]

NeSC Training Team Member

JISC UML/WSDL – Introduction, 9th Nov. 2004 2

Organisation

Two Teams –

A B


STAGE 1 : 9.00 – 11.0009.00 - Introduction to the day

09.10 - Low level service definitionsEach team develops specifications of four of low-level services.

Based on outline requirements provided The same set of services for both teams.The output of the design is

class diagrams, put into Poseidon plus any additional text documentation if this is

considered necessary

11.00 - Exchange of definitionsTeams Exchange their definitions,

via stickThis is during coffee break


STAGE 2 : 11.30 – 14.30

11.30 – Service Definition study and WSDLEach team studies the specifications it has received from the other teamIn order to find any areas where clarification is needed –

In stage 3, team A will use Team B’s low-level service definition in constructing a high level service

Vice versaThis is focussed by each team producing WSDL definitions for the received class diagram specifications Within a team, probably each team member does one definition (up to you)

Lunch Break, any time from 12.30

14.30 – End of Stage 2


STAGE 3 : 14.30 – 15.0014.30 - Service Definition Clarification Meetings

Team B discusses with Team A any points of clarification needed in the

specifications received from Team A Likewise teams D and C

This might result in modifications to the class diagrams and WSDL

Two simultaneous meetings each with two from team A, two from team B

Clarification of team A’s specifications – A’s home areaClarification of team B’s specifications – B’s home area

Aim to restrict the clarification discussions to this half-hour period (no inter-team talking over lunch!!)


STAGE 4 : 15.00 - … 15.00 – Coffee. high level services outline provided

High Level Service Definition15.30 – end of day (17.30 - whenever!)

Both teams are provided with an outline requirements for a high level serviceWhich should be realisable in terms of the low-level services.Same for both teamsEach team develops a specification for that service.

use-case diagrams class diagrams possibly state diagrams any additional documentation deemed necessary

And a realisation design a collection of sequence diagrams showing how the high level service operations are realised in terms of invocations of the low-level services


Stage 5: 9.00 – 10.30

09.00 –Introduction to the day09.10 - Small group discussions

Two simultaneous meetings each with two from team A, two from

team BWithin each group

Team A gives brief presentation of its work from stage 4– Including any low-level service extensions required

Team B gives brief presentation of its work from stage 4 Whole group discusses differences

10.00 - General discussion – of the previous day's practical

10.30 - Coffee


REST OF DAY

11.00 – Class Diag – WSDL Re-vamped practical

11.30 – WSDL styles – lecture

12.00 – Additional UML - Lecture

12.30 – Discussion of whole course…. - Lunch


Now -STAGE 1

09.10 - Low level service definitionsEach team develops specifications of four of low-level services.

Based on outline requirements provided The same set of services for both teams.The output of the design is

class diagrams, put into Poseidon plus any additional text documentation if this is

considered necessary

11.00 - Exchange of definitionsTeams Exchange their definitions,

This is during coffee break11.30 – Stage 2


Low Level Services - OutlinesPerson Service

Provides a means to manage basic information about people, such as names and contact information.

Group ServiceSupports access to information about groups, including courses, seminar groups, teams and departments.

Member ServiceSupports the management of membership of persons in groups, such as student enrolments on modules.

Forum ServiceSupports the use of asynchronous collaborative messaging, as offered by Web forums and message boards.

Repository ServiceEnables access to, and management of, a repository. The repository may contain any type of content specifically an item in the repository can be defined to be a collection of other items in the repository.


Person Service Details

An example fuller definition, to give a flavour of what the definitions might beShows one way of documenting the structure –

Not necessarily best

Operations

createPersondeletePersonreadPersonupdatePerson

You can modify/extend this if it seems appropriateIncluding, modifying data definitions -


Person Service – Class Diagrams

Person Service

createPerson (in data : personData, out id : PersonId) Status

deletePerson (in id :PersonId) Status

readPerson (in id : PersonId, out pData : PersonData) Status

updatePerson (in id : PersonId, in data : personData) Status

Person Data Model

Person

PersonData

1

1

PersonId

1

1Common Definitions

A person service provides a repository for information about entities who are assumed to be actual persons. When a person is created, s/he is allocated an identifier, unique within the service, for use in subsequent operations.

People : Person [*]

Status


Person Data Model – Class Diagram

Person

PersonData

1

1

PersonId

1

1Common Definitions

Identifier

String

SurName

FirstNameName

Address

AddressLine

2..4

1

1

0..*

1 1 1

1


Common Defns. – Class Diagram

Identifier

String

Name

Address

AddressLine

2..4

1

Status

OkStatus

WarnStatus

FailStatus

OperationNotImplemented

IdentiferNotRecognised

. . .


THE REST IS NOT RELEASED TILL 3.15


STAGE 4 : 15.00 - … 15.00 - Coffee high level services outline provided

High Level Service Definition15.30 – end of day (17.30 - whenever!)

Both teams are provided with an outline requirements for a high level serviceWhich should be realisable in terms of the low-level services. But may need - LL service enhancementsSame for both teamsEach team develops a specification for that service.

use-case diagrams class diagrams possibly state diagrams any additional documentation deemed necessary

And a realisation design a collection of sequence diagrams showing how the high level service operations are realised in terms of invocations of the low-level services


The Learning Group ServiceSupports the concept of a collaborative-learning group –

a group of students collaboratively studying a module of e-learning material.

It provides (at least) facilities forcreating a collaborative-learning module

as a sequencing of pre-existing modulescreating a collaborative-learning group

for a specific pre-existing collaborative-learning module with an associated forum for student discussion and a means for group members to annotate the modules

a prospective student to: discover what collaborative-learning groups exist; discover for a particular collaborative learning group

– Its collaborative-learning module– the set of students who are part of the group;

join and leave a collaborative-learning group.


Modifying the Functionality

You can extend/modify functionalityBut this is an exercise in UML modellingNot in e-learning services If you want to modify –

Consider functionality that might be difficult to express in UML/WSDL

If you really need extensions to the Low Level services – define these and assume that their provision can be agreed

UML and WSDL for JISC e-Learning Projects Major Practical Richard Hopkins [email protected] NeSC Training Team Member [email protected].

Documents

team b clarification

group team

jisc umlwsdl introduction

repository service

group service

member service

forum service

low level service definitions