KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
Selected Scenarios for RAP
Use Case #8: User_views_ResearcherList
Requirement:
Upon application start up, the user shall be presented with an interactive list of researchers (consisting of both staff and research students), known hereafter as the Researcher List view.
Overview:
The users views the researcher list when the application first loads. This list should display names in the format ‘Family Name, Given Name (Title)’, as in ‘Einstein, Albert (Dr)’. In addition to using the list to access researcher details, the user can also filter the list, either by a researcher’s employment level (including ‘student’) or (if time available in project) partial name match, or both. For basic filtering, the user should be able to list all researchers, students only, level A, level B, level C, level D or level E. If implementing name matching then the list contents would be restricted to show only those staff whose given name or family name contains the text entered by the user. Partial matches that span combinations of given and family name do not need to be supported, so look for matches within both names independently.
Preconditions:
1. RAP database exists and is populated with data
Scenario:
Action
Software Reaction
1. User starts application
1. MainView created with ResearcherListView and adjacent ResearcherDetailView visible
2. System retrieves basic researcher details from database: name, title and current employment level
3. Researchers are sorted alphabetically by family name 4. System shows names in ResearcherListView
2. User selects an employment level (including the ‘students only’ or ‘all’ options) from a dropdown list of levels
1. System updates current set of filters to include selected level
2. System creates temporary list of researchers based on current set of filters (level or name, if present)
3. System refreshes the ResearcherListView with the filtered list
3. User modifies text in filter-by-name text field
1. No reaction; not supporting automatic refresh of list contents
4. User presses enter key inside filter-by- name text field
1. System updates current set of filters to include given text or, if search text is blank, removes any existing text from set of filters
2. System creates temporary list of researchers based on current set of filters (level or name, if present)
3. System refreshes the ResearcherListView with the filtered list
5. User selects researcher in list
See UC16 User_selects_Researcher
1/9
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
Scenario Notes:
Actions 1 is a precondition for all others. The other actions may occur in any order, although it is more typical for Action 3 to be followed by Action 4 (the user pressing enter to trigger name-based filtering). The reaction to Actions 2 and 4 produces the intersection of the two filters.
Post Conditions:
ResearcherListView displays all or a subset (particular level or with matching names)
of researcher names
Required Views: (GUIs)
ResearcherListView
Exceptions:
1. If the database is inaccessible or another unexpected error occurs then the system should respond with a message to this effect, requesting that the user close and restart the software. (In a later release the system should be made robust to such exceptions and be able to reload the database without being restarted.)
Use Cases utilised
UC16_User_selects_Researcher
2/9
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
Use Case #16: User_selects_Researcher
Requirement:
When the user selects a name in the list the researcher details view will be displayed.
Overview:
Selecting a researcher’s name in the ResearcherListView will show their details (and, ultimately, their list of publications) in the ResearcherDetailView. The details shown will vary depending on whether the researcher is staff or student. Each detail will have a label in the display. All researchers will have: name; title; school/unit; campus; email; photo (this is stored as the URL of an image); current job title; commenced with institution; commenced current position; tenure; number of publications. Staff will also have the following displayed: 3-year average of publications per year; publication performance; and supervisions. Students will also have the following displayed: degree; and supervisor name. Staff-specific fields are left blank for students, while student-specific fields are left blank for staff.
The following data need to be derived from the information in the database:
Current Job Title is derived from their current position’s level: student is
Student; A is Postdoc; B is Lecturer; C is Senior Lecturer; D is Associate Professor;
E is Professor
Commenced with institution is the start date of their earliest position
Commenced current position is the start date of their current position
Tenure is the time in (fractional) years since the researcher commenced with the
institution
3-year Average is the total number of publications in the previous three whole
calendar years, divided by three. For example, if the current calendar year is
2015 then the average is over the period spanning 2012, 2013 and 2014
A staff member’s performance is their three-year average for publications
divided by the expected number of publications given their employment level, expressed as a percentage with one decimal place shown. The expected number of publications per year for each level is as follows: A, 0.5; B, 1; C, 2; D, 3.2; E, 4.
Supervisions is the number of students the staff member is currently or has previously supervised
It would enhance the application if the ResearcherDetailsView also includes a table of a staff member’s previous positions and those positions’ start and end dates (this is not required for students).
Preconditions:
1. HRIS database exists and is populated with data
2. ResearcherListView is visible
Scenario:
Action
Software Reaction
1. User selects staff name in ResearcherListView
1. System retrieves from the database any additional details about the researcher member, including photo and publications list
3/9
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
2. System calculates basic derived values, including current job title, commencement dates, tenure
3. If selected researcher is staff then three-year average for most recent three whole calendar year period and performance are calculated, as well as total number of supervisions. ‘Show Names’ button adjacent to number of supervisions made visible if number of supervisions is not zero
4. If selected researcher is staff then details of all previous positions held are loaded from database and added to small table in ResearcherDetailView
5. If selected researcher is student then supervisor’s name is retrieved from database. Table of positions, list of supervisions and ‘Show Names’ button are hidden
6. System enlarges application window size if too small to display ResearcherDetailView
7. UC34_User_views_Publications is triggered
2. User clicks ‘Show Names’ button next to number of supervisions
See UC29_User_expands_Supervisions
3. User clicks ‘Cumulative Count’ button
See UC32_User_views_CumulativeCount
Scenario Notes:
Action 1 must occur before Actions 2 or 3, which are independent of each other.
Action 2 is only possible if the displayed researcher is a member of staff.
Post Conditions
ResearcherDetailView displays details of selected researcher and PublicationsListView displays that researcher’s publications
Required Views: (GUIs)
ResearcherListView ResearcherDetailsView CumulativePublicationsView PublicationsListView
Exceptions:
1. If the database is inaccessible or another unexpected error occurs then the system should respond with a message to this effect, requesting that the user close and restart the software. (In a later release the system should be made robust to such exceptions and be able to reload the database without being restarted.)
2. If the selected researcher is staff and has not published within the three-year window then performance should be shown as ‘n/a’
Use Cases utilised
UC8_User_views_ResearcherList (precondition) UC29_User_expands_Supervisions UC32_User_views_CumulativeCount UC34_User_views_Publications
4/9
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
Example low fidelity prototypes
You do not need to follow these designs in your application
MainMenu
ResearcherListView
ResearcherDetailView (including PublicationsListView)
PublicationDetailView
MainView
Name:
Title:
Unit:
Campus:
Email:
Current job: Senior Lecturer
Commenced with institution: 18/01/2011 Commenced current position: 01/01/2014 Previous positions:
Jane Doe
Dr
Engineering & ICT Hobart [email protected]
18/01/2011 31/12/2013 Lecturer
Tenure:4.6years Publications:9 CumulativeCount 3-year average: 2.6 Performance: 116.7% Supervisions: 1 Show Names
Degree: Supervisor:
PublicationsListView (detail elsewhere)
Filter by name: j Show:
all researchers
Doe, Jane (Dstru)dents only Doe, Jane (MA s) Jane Doe Doe, Jane (DBr)
C
Doe, Jane (Ms)John Smith
D Smith, John (Dr)
Smith, JohnE(Dr) John Smith, John (Dr) Smith, John (Mr)
ResearcherListView
ResearcherDetailsView
5/9
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
Sample UML models
Note that these would have been one per page in your submission
Example package diagram
View
Research
Database
Bidirectional dependency is because views pass messages back to controllers
Research package
Researcher includes an integer ID, which comes from the database (you were not expected to include this in your Assignment 1 designs)
occupies
main list
Details have been omitted from ‘imported’ control classes
uses
This additional collection will become clear when we study WPF and data binding
has
Many of these operations could become attributes if the associated data is calculated when the model is loaded from the database
Control::ResearcherController
Control
+level: EmploymentLevel +start: Date
+end: Date
Position
Staff
displayed list
master list
1..*
1
1
0..*
<
OutputType
+Conference +Journal +Other
+ThreeYearAverage(): float +Performance(): float
Researcher
-id: integer +GivenName: string +FamilyName: string +Title: string +School: string +Campus: string +Email: string +Photo: URL
+GetCurrentJob(): Position +CurrentJobTitle(): string +CurrentJobStart(): Date +GetEarliestJob(): Position +EarliestStart(): Date +Tenure(): float +PublicationsCount(): integer
Publication
+DOI: string
+Title: string +Authors: string +Year: Date +Type: OutputType +CiteAs: string +Available: Date
+Title(): string
+ToTitle(l: EmploymentLevel): string
Student
supervises
+Degree: string
+Age(): integer
<
EmploymentLevel
+Student +A
+B
+C
+D +E
6/9
Control::PublicationsController
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
Control package
ResearcherController
uses
These control classes will probably need additional methods to those shown
+LoadReseachers() +FilterBy(level: EmploymentLevel) +FilterByName(name: string) +LoadResearcherDetails()
Database package
Adapter provides access to the Employment and Research Database and can load collections of Researchers and Publications (or individual items)
Optional: these could probably be rolled into the ERDAdapter; they would contain similar operations to what I’ve shown in the ERDAdapter at the moment
PublicationAdapter
ERDAdapter
+fetchBasicResearcherDetails(): Researcher[] +fetchFullResearcherDetails(id: integer): Researcher +completeResearcherDetails(r: Researcher): Researcher +fetchBasicPublicationDetails(for: Researcher): Publication[] +completePublicationDetails(p: Publication): Publication +fetchPublicationCounts(from: Date, to: Date): integer[]
ResearcherAdapter
This set of operations is for an optimised pattern of database retrievals, where objects containing the bare minimum of details are loaded first, then their details are filled in later, as needed.
7/9
PublicationsController
+loadPublicationsFor(r: Researcher): Publication[]
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
View package
MainView
You will have more View classes than shown here
ResearcherListView
ResearcherDetailView
PublicationsDetailView
names list
positions list
researcher type drop down
CumulativePublicationsView
PublicationsListView
supervisions list
ListBox
ComboBox
ListBox
ListBox
ListBox
You were not expected to include these library classes in your design
8/9
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
UC8_User_views_Researchers
: User
1 : starts system
<
3 : LoadReseachers()
: MainView
: ResearcherListView
: ResearcherController
: ERDAdapter
4 : fetchBasicResearcherDetails() 5 : researchers
There will probably be some common, private filtering method called in both of these interactions
7 : selects entry in Filter By list
10 : presses enter in name filter field
UC16_User_selects_Researcher
12 : list updated
: ERDAdapter
: ResearcherListView
: ResearcherController
: User
1 : select entry
2 : LoadResearcherDetails()
Would actually be a sequence of properties settings
When you actually implement this using WPF and data binding there will be far fewer method calls involved as these methods will be properties of each Researcher object
6 : SetModel()
6 : researchers
8 : FilterByLevel()
9 : list updated
11 : FilterByName()
: ResearcherDetailView
3 : r := completeResearcherDetails()
r : Researcher
4 : update details()
5 : updated model
7 : CurrentJobTitle()
8 : job title
9 : CurrentJobStart()
10 : start date 11 : Tenure()
12 : tenure
13 : PublicationsCount()
14 : count
alt
[r is Staff]
15 : ThreeYearAverage()
16 : average 17 : Performance()
18 : performance 19 : GetPositions()
20 : list of positions
21
9/9
Reviews
There are no reviews yet.