CS计算机代考程序代写 database KIT206 Scenario Template

Scenario Template

KIT506 Sample Structured Scenarios for Assignment 2 starting point

1/9

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

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

2/9

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

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

3/9

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

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

4/9

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

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

5/9

Example low fidelity prototypes
You do not need to follow these designs in your application

Doe, Jane (Dr)
Doe, Jane (Ms) Jane Doe
Doe, Jane (Dr)
Doe, Jane (Ms)John Smith
Smith, John (Dr)
Smith, John (Dr) John
Smith, John (Dr)
Smith, John (Mr)

MainMenu

ResearcherListView
ResearcherDetailView

(including PublicationsListView)

Show:

students only
A
B
C
D
E

all researchers

ResearcherListView

MainView

Filter by name: j

PublicationDetailView

PublicationsListView
(detail elsewhere)

Name: Jane Doe
Title: Dr
Unit: Engineering & ICT
Campus: Hobart
Email: jane. .au
Current job: Senior Lecturer
Commenced with institution: 18/01/2011
Commenced current position: 01/01/2014
Previous positions:

18/01/2011 31/12/2013 Lecturer

Tenure: 4.6 years Publications: 9
3-year average: 2.6 Performance: 116.7%
Supervisions: 1
Degree: Supervisor:

ResearcherDetailsView

Show Names

Cumulative Count

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

6/9

Sample UML models
Note that these would have been one per page in your submission

Research DatabaseView

Bidirectional dependency is because views pass messages back to controllers

Control

Example package diagram

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

Position

+level: EmploymentLevel
+start: Date
+end: Date

+Title(): string
+ToTitle(l: EmploymentLevel): string

EmploymentLevel
<>

+Student
+A
+B
+C
+D
+E

occupies

11..*

Staff

+ThreeYearAverage(): float
+Performance(): float

Student

+Degree: string
supervises

1 0..*

Publication

+DOI: string
+Title: string
+Authors: string
+Year: Date
+Type: OutputType
+CiteAs: string
+Available: Date

+Age(): integer

Many of these operations could

become attributes if the associated

data is calculated when the model

is loaded from the database

OutputType
<>

+Conference
+Journal
+Other

has

Control::PublicationsControllerControl::ResearcherController

displayed list

master list

main list

This additional collection will become clear

when we study WPF and data binding

uses

Details have been omitted from

‘imported’ control classes

Researcher includes an integer ID,

which comes from the database

(you were not expected to include

this in your Assignment 1 designs)

Research package

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

7/9

ResearcherController

+LoadReseachers()
+FilterBy(level: EmploymentLevel)
+FilterByName(name: string)
+LoadResearcherDetails()

PublicationsController

+loadPublicationsFor(r: Researcher): Publication[]

uses

Control package

These control classes will probably need additional methods to those shown

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[]

Adapter provides access to the

Employment and Research Database

and can load collections of

Researchers and Publications (or

individual items)

PublicationAdapter

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.

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

ResearcherAdapter

Database package

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

8/9

ResearcherListView

ComboBox

researcher type drop down

ListBox

names list

ResearcherDetailView

MainView

View package

PublicationsListView

PublicationsDetailView

CumulativePublicationsView

ListBox

supervisions list

positions list

ListBox ListBox

You were not expected to include these library classes in your design

You will have more View classes than shown here

KIT206/506 Sample Structured Scenarios for Assignment 2 starting point

9/9

alt

[r is Staff]

: User

: ResearcherListView : ResearcherController : ERDAdapter : ResearcherDetailView r : Researcher

1 : select entry
2 : LoadResearcherDetails()

3 : r := completeResearcherDetails()

4 : update details()

Would actually be a sequence

of properties settings

5 : updated model
6 : SetModel()

7 : CurrentJobTitle()

8 : job title
9 : CurrentJobStart()

10 : start date

11 : Tenure()

12 : tenure

13 : PublicationsCount()

14 : count

15 : ThreeYearAverage()

16 : average
17 : Performance()

18 : performance

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

19 : GetPositions()

20 : list of positions

21

UC16_User_selects_Researcher

: User

: MainView : ResearcherListView : ResearcherController : ERDAdapter

1 : starts system
2

<>

UC8_User_views_Researchers

3 : LoadReseachers()
4 : fetchBasicResearcherDetails()

5 : researchers6 : researchers

7 : selects entry in Filter By list

8 : FilterByLevel()

9 : list updated

10 : presses enter in name filter field
11 : FilterByName()

12 : list updated

There will probably be some common, private filtering

method called in both of these interactions