1 / 20

Teams For Day 2 Practical

UML and WSDL for JISC e-Learning Projects Major Practical Richard Hopkins rph@nesc.ac.uk NeSC Training Team Member. 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

rianna
Download Presentation

Teams For Day 2 Practical

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related