Teams For Day 2 Practical

1. UML and WSDL for JISC e-Learning ProjectsMajor PracticalRichard Hopkins rph@nesc.ac.ukNeSC Training Team Member

2. D A C B Teams For Day 2 Practical • Four Teams – Team D Roberto Fraile Mohammed Islam Daniel May Simon McAlister Team A John Scott Dan Powley M Hassan Sheikh Leif Isaksen Team C Robin Johnson Robert Gilks Sam Easterby-Smith Team B Tjitske Kamphuis Gary Murray Julian Sedding NEED A SECRETARY PER GROUP

3. Tasks For Major UML Practical High Level service HL-1 Low Level services Semi-loosely-coupled LL-1 LL-2 LL-3 LL-4 LL-5 • Stage 3 : HL-1 • Each team is doing the same work • Given outline description of HL-1 • Produce: • use-cases, documentation, classes for interface and internal data structures • Sequence diagrams to show how it uses the LL services • Stage 2 : LL-x • Each team takes one LL service • Given outline description • Produce: use-cases, documentation, classes for interface and internal data structures • Stage 1 : LL-1 • Each team is doing the same work • Given interface definition of LL-1 • Produce: classes for interface and internal data structures For each stage a – team produces diagrams / text – b – collected by Guy and made available on-line c –full group discussion of each teams work – explain – explore differences – possibly modify for next stage

4. Timetable for Major UML Practical 09.15 – 10.30 Stage 1: LL-1 – work in teams • Output due 10.30 • 10.30 Coffee look at others’ work • 11.00 – 11.30 Discussion of Stage 1 – whole group • 11.30 – 14.00 Stage 2: LL-x – work in teams • (with lunch break sometime about 13.00) • Output due 13.45 • 14.00 – 14.30 look at others’ work • 14.30 – 15.00 Discussion of Stage 2 – whole group • 15.00 Coffee • 15.30 – 17.30 Stage 3 : HL-1 – work in teams • Output due 11.00 Day 3 DAY 3 • 09.00 – 10.30 WSDL Practical • 10.30 - 11.00 Completion of Stage 3 • 11.00 Coffee • 11.30 - 12.00 Study of other Teams’ work - work in teams • 12.00 – 12.45 Discussion of Stage 3 – whole group • 12.45 Lunch • 13.30 - 14.00 Additional UML • 14.00 - ??? Feed-back / discussion on whole course

5. LL-1 – MAGIC Service Marking and Assessment for General Instructional Components • Operations – • setTask() – Here’s a task, for which a solution can be marked • setBenchMark() – Here’s the information needed to mark a student solution of a task • evalSolution() – Here’s a student solution to be evaluated against a BenchMark • listTasks() – Returns a list of all the Tasks known to the service • listBenchMarks() – Returns a list of all benchmarks associated with a task Your task: Interface defn. -> class diagram Some “design” of what it really means

6. MAGIC - Types • Types – • Multiple-choice (M-C) • Task: a sequence of questions each with a sequence of possible answers • Benchmark : for each question, which is the right answer • Solution: for each question, which is the answer given • Software (language P) (S-W) • Task: A specification • Benchmark: A collection of test – each with input and required output • Solution: a program in language P • Essay • Task: a description of the required essay • Benchmark: a structure of keywords and patterns in which they should occur in an answer to the question • Solution: an essay

7. MAGIC – Here’s a Task • setTask( theType : Type, theURI : URI, theID : ID, out myID : ID) : status • theType : Type – • whether it is M-C, S-W, Essay • theURI : URI – • the URI of a repository service in which the task definition is stored • theID : ID – • an identifier of the Task which is unique within the tasks stored by the identified repository service • myID : ID – • a new identifier for this task which uniquely identifies the task within this service • returns : status – • whether success / warning / error, with details

8. MAGIC – Here’s a Benchmark • setBenchMark( theType : Type, taskId : ID , theURI : URI, theID : ID, out myID : ID) : status • theType : Type – whether it is M-C, S-W, Essay • taskID : ID – • the unique identifier of the task for which this is a bench mark • theURI : URI – the URI of a repository service in which the benchmark is stored • theID : ID – an identifier of the benchmark which is unique within the tasks stored by the identified repository service • myID : ID – a new identifier for this benchmark which uniquely identifies the task within this service • returns : status – whether success / warning / error, with details

9. MAGIC – Here’s a Solution • evalSolution( theType : Type, BMId : ID , theSolution : Solution, out mark : integer, out theComments : Comments) : status • theType : Type – • whether it is M-C, S-W, Essay • BMID : ID – • the unique identifier of the benchmark against which this solution is being evaluated • theSolution : Solution – • the actual student solution • mark : integer – • The percentage mark, between 0 - 100 • theComments : Comments – • Comments on the solution • returns : status – • whether success / warning / error, with details

10. MAGIC – List Tasks • listTasks(types : Type[*], out theList : TaskData[*]) : status • types : Type[*] • the set of types of tasks required • theList : TaskData[*] • The task data for each task of the required type • TaskData – • content : TaskContent – the actual task • theType : Type – its type • theURI : URI – the URI of the repository service from which the task definition was obtained • theID : ID – an identifier of the Task which is unique within the tasks stored by the identified repository service • myID : ID – the identifier for this benchmark • returns : status – • whether success / warning / error, with details

11. MAGIC – List BenchMarks • listBenchMarks( myID: ID, out theList : BMData[*]) : status • myID: ID • the unique identifier of the task for which the benchmarks are to be listed • theList : BMData[*] • The data for each benchmark • BMData – • content : BMContent – the actual benchmark • theURI : URI – the URI of the repository service from which the benchmark was obtained • theID : ID – an identifier of the benchmark which is unique within the benchmark stored by the identified repository service • myID : ID – an identifier for this benchmark • returns : status – • whether success / warning / error, with details

12. MAGIC – Outline Class Diags MAGIC Service People : TaskInfo [*] • setTask( theType : Type, theURL : URI, theID : ID, out myID : ID) : status • ….. Mechanical – use of Poseidon MAGIC Data Model Creative TaskInfo 1 . . . Common Definitions 0..* ID BenchMark . . . Status . . .

13. Common Definitions Status ID OkStatus String WarnStatus Name OperationNotImplemented FailStatus IdentiferNotRecognised . . .

14. STAGE 1 - Timetable • 09.15 – 10.30 Stage 1: LL-1 – work in teams • input: definition of exposed interface • output: • class diagrams for interface and internal data structure • due 10.30 • Collected by Guy on his memory stick • File names – TeamA-Stage1-…. • 10.30 Coffee - look at others’ work • http://homepages.nesc.ac.uk/~gcw/poseidon/practical.html • Can print out – see poseidon practical instructions • 11.00 – 11.30 Discussion of Stage 1 – whole group • Explanations needed? • Explore differences • Do we want any modification to LL-1 definition?

15. WAIT • WAIT FOR STAGE 2

16. STAGE 2 • 11.30 – 14.00 Stage 2: LL-x – work in teams (with lunch break sometime about 13.00) • Input: outline descriptions of LL-2 .. LL-5 • Note – these and LL-1 will be used together – semi-loosely-coupled • Output, for your team’s LL-x : • class diagram(s) for interface definition and internal data structures; • use-case diagrams; • documentation; • due 13.45 - collected by Guy • 14.00 – 14.30 look at others’ work • 14.30 – 15.00 discussion of Stage 2 – whole group • Explanations needed? • Explore differences • Do we want any modifications to LL- definition? • 15.00 Coffee

17. Low Level Services Magic Service • As previously – can be used as a model of how other services work. Person Service (Team A) • Provides a means to manage basic information about people, such as names and contact information, and to send communications to them. Group Service (Team B) • Supports access to information about groups, including courses, seminar groups, teams, departments. • Supports the management of membership of persons in groups, such as student enrolments on modules. Forum Service (Team C) • Supports the use of asynchronous collaborative messaging, as offered by Web forums and message boards. Repository Service (Team D) • Enables 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; and other relationships between items can be defined.

18. STAGE 3 • 15.30 – 17.30 Stage 3 : HL-1 – work in teams • Input: outline description of HL-1 • Output: • Class diagram(s) for interface definition and internal data structures; • use-case diagram; documentation • Sequence diagrams to show how it uses the LL services • Due 11.00 Day 3 (collected by Richard) • DAY 3 • 9.00 – 11.00 WSDL Tutorial / Completion of Stage 3 if needed • 11.00 Coffee • 11.30 - 12.00 Study of other Teams’ work - work in teams • 12.00 – 12.45 Discussion of Stage 3 – whole group • 12.45 Lunch • 13.30 – 14.00 Addittional UML • 14.00 - ??? Feed-back / Discussion of whole course

19. The Learning Group Service • Supports the concept of a collaborative-learning group – • a group of students collaboratively studying a module of e-learning material. • It provides (at least) facilities for • a tutor to create a collaborative-learning module • a sequencing of pre-existing modules • associated benchmarks for assessment • a tutor to create 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. • a single student, or the group as a whole, to submit a solution to a benchmark and receive an assessment on it

20. DAY 3 • 09.00 – 10.30 WSDL Practical • 10.30 - 11.00 Completion of Stage 3 • 11.00 Coffee • 11.30 - 12.00 Study of other Teams’ work - in teams • 12.00 – 12.45 Discussion of Stage 3 – whole group • 12.45 Lunch • 13.30 - 14.00 Additional UML • 14.00 - ??? Feed-back / discussion on whole course