Example: Further Elaboration on Automated Assessments
Steven Zeil
Here’s where we last left our assessment model.
Let’s explore how these use cases would allow us to refine that model.
1 Analysis of the “Create Assessment” Use Case
Use Cases
We will concentrate, in this example, on 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.
Validating the “Create Assessment” Use Case
Our approach will be to
- Step through the use case 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
-
Thinking about Authoring
Previously we had
Assessment |
---|
: seq of Question |
|
Instructor |
---|
: GradeBook
|
administer(: Assessment, to: seq Student) |
Question |
---|
: Rubric |
|
and might have described the authoring process like this:
Updating Names
-
Now we have learned that “Instructor” is better replaced by more specific roles, in this case, the role of “Author”.
-
Seems unlikely that all authors will administer the assessments
-
-
Similarly, we have learned that “Questions” are more generically referred to as “Items”.
We’ll break down the analysis of this use case by each step in the main sequence.
1.1 Step 1
- Author creates items of varying kinds, adding each to his/her item bank.
So, we can see immediately 3 objects that are going to be required. We’ll list those three objects within a title frame named for the use case.
- I will generally use the anonymous form (no name – just a data type) 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) or that I have multiple objects of the same type in the scenario and need to give them separate names to help tell them apart.
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 class relationship diagrams. So we have just learned something that we need to add to our model.
#![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)
1.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)
1.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]
1.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.
1.5 Create Assessment 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)
2 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