Last modified: Mar 21, 2014
Assessment | |
---|---|
Has questions |
GradeBook | |
---|---|
record a score for a Student on an Assessment | |
GradedQuestionResponse? | |
---|---|
Has score, feedback | |
GradedResponse? | |
---|---|
has GradedQuestionResponses? | |
compute total score | |
Instructor | |
---|---|
administer assessment to group of Students | Student |
Response | |
Grade Book | |
Question | |
---|---|
grade(Rubric) | Rubric |
QuestionResponse? | |
---|---|
grade(Rubric): score | |
Response | |
---|---|
has QuestionResponses? | Rubric |
grade a seq of Questions via a seq of Rubrics | |
Rubric | |
---|---|
grade(QuestionResponse): score | |
Student | |
---|---|
take an Assessment: Response | Assessment |
receive a GradedResponse | |
Class Diagrams - Assessment Generalization
Assessments come in many kinds
Question Generalization
So do questions
Key Documents in the Assessment World
There is a parallel structure to the main documents in this world, based upon the questions that make up the assessment..
Use Cases
We will concentrate, in this example, on the “Create Assessment” case:
Validating the “Create Assessment” Use Case
Take the first use case (Create Assessment).
Step through it to be sure our model can support it. As we do, we will
Record any interface changes in a UML class diagram
Validate our progress by constructing a sequence diagram
The Create Assessment Case
Here is the use case:
Create Assessment
1: Author creates items of varying kinds, adding each to his/her item bank.
2: Author creates an empty assessment, adding a title and indicating the grading policy (graded immediately or in batch, grades recorded in grade book or not), policy on re-attempts permitted, dates & time of availability, and security policy (suspend & resume permitted, open/closed book, etc.).
3: Author selects questions from item bank and adds them to the assessment, assigning point value as he/she does so.
4: Author concludes creation of the assessment, making it available to the appropriate proctors.
Alternative: Edit assessment
2: Author edits an existing assessment, possibly altering one or more of the assessment properties.
Alternative: Save assessment
4: Author concludes this work session, saving the assessment for later editing without releasing it to the proctors.
Thinking about Authoring
Previously we had
Assessment | |
---|---|
Has questions |
Instructor | |
---|---|
administer assessment to group of Students | Student |
Response | |
Grade Book | |
Question | |
---|---|
grade(Rubric) | Rubric |
and might have described the authoring process like this:
Updating Names
Now we know that “Instructor” is better replaced by more specific roles, in this case, the role of “Author”.
Similarly, we have learned that “Questions” are more generically referred to as “Items”.
- Author creates items of varying kinds, adding each to his/her item bank.
Note: The sequence diagrams in these notes were prepared with the free sdedit program (see the Library page for more info). The input for this diagram was
#![CreateAssessment]
author:Author[a]
item:Item[a]
bank: Itembank[a]
I will continue to show these inputs in the notes so that you can see how to build similar diagrams of your own.
Step 1 (cont.)
- Author creates items of varying kinds, adding each to his/her item bank.
The item bank is a new class, one that was not in our CRC cards.
#![CreateAssessment]
author:Author[a]
item:Item[a]
bank: Itembank[a]
#
author:item.new
author:bank.add(item)
The Item Bank
Item Banks are Containers
Back to the Create Assessment Use Case
Finally, we note that this is a sequence that is repeated multiple times.
#![CreateAssessment]
author:Author[a]
item:Item[a]
bank: Itembank[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
What’s in the new items?
Now, nothing is said about what kind of information goes into each of these items.
It’s possible that all the necessary info is supplied as a parameter to the 3 constructor calls.
It’s possible that there are several steps after construction to fill in the info.
We just don’t have that info right now and should make a note to try to find out later. (solicit more use cases)
2: Author creates an empty assessment, adding a title and indicating the grading policy (graded immediately or in batch, grades recorded in grade book or not), policy on re-attempts permitted, dates & time of availability, and security policy (suspend & resume permitted, open/closed book, etc.).
So we learn a lot about the attributes of an assessment.
Assessment Attributes
Creating an Assessment Object
And we add the creation of a new assessment to our sequence diagram:
#![CreateAssessment]
author:Author[a]
item:Item[a]
bank: Itembank[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
author:assess.new(title,policies,avail)
3: Author selects questions from item bank and adds them to the assessment, assigning point value as he/she does so.
Two operations get added to the sequence diagram:
Comments
I use the return arrow from the getItem() call as a way of labelling the value being returned so that I can use that same name in the following add() call to indicate that the item being added is the one just retrieved.
And I used a different name than “item” because I wanted to indicate that the selected items were not necessarily only ones that had been created earlier in the scenario.
Validating the new Operations
We already have the getItem() operation in the ItemBank class.
But the add function needs to be added to our Assessment class.
#![CreateAssessment]
author:Author[a]
item:Item[a]
bank: Itembank[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
author:assess.new(title,policies,avail)
author:selected=bank.getItem(...)
author:assess.add(selected,pointValue)
Updating the Assessment Class
Repeating The Addition of Items
Finally, we note that these operations are also repeated.
#![CreateAssessment]
author:Author[a]
item:Item[a]
bank: Itembank[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
author:assess.new(title,policies,avail)
[c:loop *more questions desired]
author:selected=bank.getItem(...)
author:assess.add(selected,pointValue)
[/c]
4: Author concludes creation of the assessment, making it available to the appropriate proctors.
What is meant by concluding the creation of the assessment?
Well, at the very least, it would entail saving the author’s work.
But where is it saved to? A file? A special container of assessments?
An architectural design issue
In the real world, this is probably something very prosaic and individual: a desk drawer, a file cabinet, the proctor’s mailbox, the author’s briefcase…
AssessmentBanks
#![CreateAssessment]
author:Author[a]
/item:Item
bank: Itembank[a]
/assess: Assessment
abank:AssessmentBank[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
author:assess.new(title,policies,avail)
[c:loop *more questions desired]
author:selected=bank.getItem(...)
author:assess.add(selected,pointValue)
[/c]
author:assess.makeAvailableTo(proctorList)
author:abank.save(assess)
Storing Assessments
And we update our model accordingly:
Authors have Banks
And each author would have a collection of their assessments.
Alternative Paths
Our Use Case include alternate paths, e.g.,
Alternative: Save assessment
4: Author concludes this work session, saving the assessment for later editing without releasing it to the proctors.
In Same Diagram
Alternative paths can be handled within the same diagram, e.g.,
#![CreateAssessment]
author:Author[a]
/item:Item
bank: Itembank[a]
/assess: Assessment
abank:AssessmentBank[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
author:assess.new(title,policies,avail)
[c:loop *more questions desired]
author:selected=bank.getItem(...)
author:assess.add(selected,pointValue)
[/c]
[c:opt finished?]
author:assess.makeAvailableTo(proctorList)
[/c]
author:abank.save(assess)
In Separate Diagram
Or in a separate diagram, if that makes things clearer, e.g.:
Alternative: Edit assessment
2: Author edits an existing assessment, possibly altering one or more of the assessment properties.
This would be hard to incorporate into the main path diagram because, by definition, the lifetime of the assessment is very different in the two scenarios.
Edit Assessment
#![CreateAssessment (Edit asessment)]
author:Author[a]
/item:Item
bank: Itembank[a]
assess: Assessment
abank:AssessmentBank[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
author:assess=abank.fetch(...)
author:assess.[optional] setTitle()
author:assess.[optional] set policies()
author:assess.[optional] setAvailability()
[c:loop *more questions desired]
author:selected=bank.getItem(...)
author:assess.add(selected,pointValue)
[/c]
[c:opt finished?]
author:assess.makeAvailableTo(proctorList)
[/c]
author:abank.save(assess)
As an aid to analysis: read through the case, looking for objects and interactions not listed in the current model.
As an aid to validation: Model the use case as a series of passed messages, recording the interactions in a sequence diagram. Update the model as necessary so that a cause-and-effect chain can be demonstrated from the start of the use case to its end.
As a statement of requirements