Example: Further Elaboration on Automated Assessments
Steven Zeil
1 Recapping
Here’s where we last left our assessment model:
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:
2 Analysis of the “Create Assessment” Use 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”.
-
Seems unlikely that authors will administer the assessments
-
-
Similarly, we have learned that “Questions” are more generically referred to as “Items”.
2.1 Step 1
- Author creates items of varying kinds, adding each to his/her item bank.
- I will generally use the anonymous form until I discover that I need an actual name for an object (to refer to it as a parameter or return value in some call).
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 creation of a new item.
- adding of that item to the item bank.
The item bank is a new class, one that was not in our CRC cards.
- We could add a card for it, but we’re far enough along that we should probably start being a bit more formal.
#![CreateAssessment]
author:Author[a]
/item:Item[a]
bank:Itembank[a]
#
author:item.new
author:bank.add(item)
The Item Bank
- Start with the idea that each author has a personal item bank.
Item Banks are Containers
- And that the item banks are repositories of items.
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.2 Step 2
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]
/assess:Assessment[a]
#
[c:loop *more new questions conceived]
author:item.new
author:bank.add(item)
[/c]
author:assess.new(title,policies,avail)
2.3 Step 3
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 followingadd()
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]
/assess:Assessment[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
- We add the add function to our 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]
/assess:Assessment[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]
2.4 Step 4
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
- In early elaboration, we can punt on this by postulating a store of assessments, and later noting that this might be ordinary files or might be something more elaborate.
#![CreateAssessment]
author:Author[a]
/item:Item
bank: Itembank[a]
/assess: Assessment[a]
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.
2.5 Create Assessment alternative paths
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)
3 Recap: How to Use a Use Case
-
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