ZFISH TRACKER

COMP246 Term Project – Parts A, B, C

Group 10
Yushi (Sandy) Shang 301177535
Pinkherwin Relos 301209565
Michael-Angelo Dinuccio 301177707
Colin Moore 301165754
Melissa Westaway 301161203
Jeffrey Sy 980045498
Himali Kothari 301210969
Contents
Part A: Software Requirements Specification........................................................................ 3
1.0 Problem Statement .................................................................................................................... 3
1.1 Opportunity for Software Solution ............................................................................................. 3
1.2 Stakeholders and Associated Roles ......................................................................................... 4
1.3 Application Subsystems.............................................................................................................. 6
1.4 Intended Audience....................................................................................................................... 6
2.0 General Overview Modelling .................................................................................................... 7
2.1 Context Flow Diagram (CFD) .................................................................................................... 7
3.0 Requirements Modelling – Functional & UML Use Case ..................................................... 7
3.1 Goal Use Cases ........................................................................................................................... 7
3.2 Use Case Diagrams .................................................................................................................... 9
3.3 User Stories ................................................................................................................................ 11
3.4 Non-Functional Requirements ................................................................................................. 14
4.0 UML Domain Class Diagram .................................................................................................. 15
4.1 List of Classes ............................................................................................................................ 15
4.2 Domain Class Diagram ............................................................................................................. 16
5.0 Entity Relationship Diagram (ERD) ....................................................................................... 16
6.0 UML Systems Sequence Diagram ........................................................................................ 17
7.0 UML State Diagrams ..................................................................................................................... 19
8.0 Technologies .................................................................................................................................. 19
9.0 Project Management ..................................................................................................................... 20
Part B: Software Design Architecture....................................................................................21
1.0 Overview Model ............................................................................................................................. 21
1.1 Intended Audience..................................................................................................................... 21
1.2 Architectural Context Diagram (ACD) .................................................................................... 21
2.0 Modularization ................................................................................................................................ 22
2.1 Partition of Analysis Model ....................................................................................................... 22
2.2 Class Responsibility Collaborator (CRC) ............................................................................... 23
2.3 Design Class Diagram .............................................................................................................. 24
3.0 Model View Controller Framework .............................................................................................. 26
3.1 MVC Pattern Diagram ............................................................................................................... 26
4.2 Sequence Diagrams .................................................................................................................. 30
 3.3 State Machine Diagrams .......................................................................................................... 31
4.0 Data Layer ...................................................................................................................................... 32
5.0 Technologies .................................................................................................................................. 32
6.0 Project Management ..................................................................................................................... 33
Part C: System Design Document .........................................................................................34
1.0 Software Design Patterns............................................................................................................. 34
1.1.1 State Pattern ..................................................................................................................... 34
1.1.2 Observer Pattern .................................................................................................................... 34
1.1.3 Composite Pattern ................................................................................................................. 34
2.0 Using Common Software Design Patterns ................................................................................ 34
3.0 UI/UX Design.................................................................................................................................. 37
3.1 Identity and Access Management ........................................................................................... 37
3.2 Notification .................................................................................................................................. 38
4.0 High Level Component and Deployment Diagram ................................................................... 39
4.1 Component Diagram ................................................................................................................. 39
4.2 Deployment Diagram ................................................................................................................ 39
5.0 Project Management ..................................................................................................................... 40
6.0 Project Presentation ...................................................................................................................... 40
6.1 Presentation Transcript............................................................................................................. 40
6.2 Presentation Slides ................................................................................................................... 42
6.3 PowerPoint Presentation .......................................................................................................... 42
Part A: Software Requirements Specification

1.0 Problem Statement

1.1 Opportunity for Software Solution

The zebrafish, Danio rerio, is increasingly being adopted by biomedical research facilities as a
developmental model organism for studying human genetic diseases. As its popularity
increases, so does the need for a software solution to help track and manage zebrafish
colonies.

Zebrafish research facilities typically consist of more than one research laboratory and often
have multiple Animal Use Protocols, which require strict record keeping of animals used for
research purposes. Larger facilities can house upwards of thousands of tanks containing
genetically unique strains of zebrafish, making accurate record keeping a challenge.

Often research facilities will utilize paper-based record management systems to keep track of
their zebrafish colonies. These present a number of disadvantages in comparison to digital
record management systems:

Time and Labour Intensive:

• Husbandry technicians are required to manually enter data from a paper-based

system over to a spreadsheet application to perform data analysis
o Represents a redundancy of information recorded
o Increases probability of introducing errors through incorrectly transferring
data

Inability to Observe Trends:

• Canadian zebrafish research facilities are required to undergo weekly veterinary

compliance checks, which consist of looking for trends regarding animal health
o Paper-based systems do not allow for easy observation of trends
pertaining to fish health

Difficulty Generating Reports:

• Canadian zebrafish research facilities are required to generate, at minimum,

annual reports detailing fish morbidity and mortality, and total fish usage as
detailed in lab-specific Animal Use Protocols
o Paper-based systems require data to be transferred to other software
applications, such as spreadsheets, to generate required reports

Data Sharing and Data Backups:

• Paper-based systems do not allow for remote access of information or data-

recovery in-case of fire, flood or theft
1.1.1 Software Solution Capabilities

zFish Tracker is a user-friending Database Management System designed for single and multi-
user zebrafish research facilities. The proposed capabilities include:

• Easy to navigate user-interface for adding or updating zebrafish line information

• Automatic report generation for regulatory compliance
• Data recovery provided by scheduled backups to cloud based provider
• Easy to understand trend analysis for overall fish health
• Notification system to alert technicians when their fish are ready to be placed on the
system or have reached maximum allowable age

• Secure access of information through identity and access management

1.1.2 Benefits of Software Solution

zFish Tracker offers the following benefits over traditional paper-based management systems:

• Direct entry of information into database management system

o Removes intermediary steps of transferring data from a paper-based system into
a spreadsheet application
o Saves time and allows husbandry technicians to focus on other tasks
o Reduces number of errors entered into the system
• Automatic report generation and trend analysis
o Saves time and allows husbandry technician to focus on other tasks
o Provides up-to-date information to generate reports
o Provides up-to-date information regarding zebrafish colony health
• Notification system reminds technicians of when fish need to be moved or have reached
maximum allowable age
o Ensures regulatory compliance is maintained
• Identity and access management feature
o Ensures only authorized individuals can view and/or make changes to the system
• De-centralized management system allows for anytime and anywhere access to
information

o Data is securely backed-up to cloud provider to prevent data loss

1.2 Stakeholders and Associated Roles

Stakeholder Role External or Interest
Position Internal Level

Primary Investigator Secondary user: External High

• Uses reports to determine if AUP
quota is reached
o Better informs decision
making process for future
research projects
• Uses trend analysis to assess
colony health
Lab Manager Secondary user: External High
• Uses trend analysis to assess
colony health

Compliance Secondary user: External Medium

Veterinarian • Uses trend analysis to assess
colony health

Canadian Council on Beneficiary: External Medium

Animal Care Auditor • Provided with easy to read
quarterly reports

Husbandry Direct user: External High

Technician • Uses trend analysis to assess
colony health
• Uses app to generate quarterly
reports
• Adds new fish lines to database
• Records sick and/or sacrificed
fish
• Records fish mortality

Research Direct user: External Medium

Technologist • Adds new fish lines to database
• Records sick and/or sacrificed
fish
• Records fish mortality
• Receives notifications about
status of fish lines

IT Department • Assess security risk to facility’s External Low

intranet services

Project Manager • Meet with external stakeholders Internal High

to assess scope of project
• Delegate tasks to development
team members
• Set project goals and deadlines

Developers • Build application based on Internal High

functional and non-functional
capabilities

UX Designer • Conduct user experience Internal High

research
• Develop user stories and
personas
• Create wireframes and
prototypes
 Database • Develop architecture of database Internal High
Administrator system

IT Security Officer • Ensures software security Internal Low

Software Quality • Monitors software engineering Internal Low

Assurance Engineer process to ensure quality of
software solution

Software Testers • Conduct unit tests of system Internal Low

Investor Group • Provides invests for initial startup External High

Marketing Officer • Develops marketing strategies to Internal Medium

gain new potential clients
• Conducts market research for
new application discovery

1.3 Application Subsystems

zFish Tracker proposes the following application subsystems:

• Identity and access management

• Colony management
• Notifications

• Reporting

1.4 Intended Audience

The intended audience of this document include the following:

• Product Owner
• Design Team
• Development Team
• Marketing Team
• Software Testers
2.0 General Overview Modelling

2.1 Context Flow Diagram (CFD)

3.0 Requirements Modelling – Functional & UML Use Case

3.1 Goal Use Cases

FR# Goal Use Role Player Description
Case

FR01 User Login Primary After validating username and password,

Investigators, users can access the database.
Researcher,
Husbandry,
Lab Animal Services
FR02 Change Primary Registered users can change their
Password Investigators, passwords.
Researcher,
Husbandry,
Lab Animal Services

FR03 User Logout Primary Users can log out of the database.
Investigators,
Researcher,
Husbandry, Lab
Animal Services

FR04 Create New Researcher, Allow users to add a new line of fish into the
Lines Husbandry database. Must include the following
information: line number, genotype, parents,
date of birth, number of fish, number of tanks,
UserID, LabID,

FR05 Record Researcher, Allow users to record mortality on a line.

Mortality Husbandry

FR06 Update Fish Researcher, Allows users to edit, change, and manage
Info Husbandry existing information.

FR07 Receive Researcher, App notifications are given for system

Notifications Husbandry updates/notifications and fish updates.

FR08 Update Researcher, Allows users to update their notification

Preferences Husbandry preferences.

FR09 Access health Husbandry Allow users to create statistics on health

trend analysis trends of zebrafish in the database.

FR10 Generate Husbandry, Lab Allow users to generate final reports for each
quarterly Animal Services annual quarter based on selected criteria.
reports
3.2 Use Case Diagrams
3.3 User Stories

FR01: As a Primary Investigator, Researcher, Husbandry, or Lab Animal Service, I want to Log
In to the application so that I can access my information.

Acceptance Criteria:

Given: User is logged out and wants to log in.

When: User enters username and password correctly

And: User presses the “Login” button.

Then: User will be logged in.

FR02: As a Primary Investigator, Researcher, Husbandry, or Lab Animal Service, I want to

Change the password to the application so that I can manage my identity and access.

Acceptance Criteria:

Given: User is logged into account and wants to change password

When: User selects the “change password” option.

And: User inputs a password that meets the criteria and inputs it a second time to verify it.

Then: The user can manage the identity.

FR03: As a Primary Investigator, Researcher, Husbandry, or Lab Animal Service, I want to Log
Out of the application so that I can disconnect my identity with the database when I want to.

Acceptance Criteria:

Given: User is logged in.

When: User goes to the “Settings”.

And: User clicks on the “Logout” button.

Then: User will be logged out.

FR04: As a Researcher or Husbandry, I want to Create New Lines so that I can input all
relevant details in one step in order to keep track of my zebrafish lines.

Acceptance Criteria:
Given: User wants to create New Lines in the database.

When: User goes to the respective “Database”.

And: User clicks on the “Create” button to add new Lines in the database.

Then: The user will be able to input all the relevant details in the New Lines.

FR05: As a Researcher or Husbandry, I want to Record Fish Mortality so that I can keep track of
how many fish have died.

Acceptance Criteria:

Given: User wants to record Fish Mortality.

When: User goes to the “Fish Mortality” section under the “Fish Information” section.

And: User enters records related to mortality and clicks on the “Save” button.

Then: The user can track the fish mortality.

FR06: As a Researcher or Husbandry, I want to Update Fish Info in the database so that I can
change and modify existing information.

Acceptance Criteria:

Given: User has Fish Information in the database and wants to update the information.

When: User goes to the respective database.

And: User clicks on the “Update” button in the database.

Then: The user can change and modify the existing information in the database.

FR07. As a Researcher or Husbandry, I want to receive notifications so that I can know when
there are changes in my work and the fish in our lab.

Acceptance Criteria:

Given: User is logged in and wants to enable the notifications.

When: User goes to the “settings”.

And: User clicks on the “Enable Notification” button.

Then: User will receive the notifications when the changes happen and it will be shown on the
navigation bar under the notification bell icon.

FR08: As a Researcher or Husbandry, I want to Update my notification preferences so that I can

customize the notifications I receive based on my work requirements.

Acceptance Criteria:

Given: User logged in and wants to customize the notifications.

When: User goes to notification settings and clicks on the “Customize” button.

And: User sets the preferences based on the work requirements.

Then: The user will receive notifications only related to the selected preferences.

FR09: As a Husbandry, Lab Animal Services or Primary Investigator, I want to Access Health
Trend Analysis so that I can create statistics on health trends based on selected criteria.

Acceptance Criteria:

Given: User is logged in and wants to access Health Trend Analysis.

When: User goes to the “Analysis” page.

And: User clicks on the “Health Trend Analysis” button.

Then: The user can create statistics on health trends based on selected criteria.

FR10: As a Husbandry,, I want to Generate Quarterly Reports so that I can create final reports
for each annual quarter based on selected criteria.

Acceptance Criteria:

Given: User wants to generate quarterly reports.

When: User goes to the “Reports” section.

And: User selects “Quarterly” into the given category.

Then: The user will be able to create final reports.

3.4 Non-Functional Requirements
NFR# Requirement Description Priority Requester
Title

NFR01 Usability User interface should be intuitive Mandatory UX Designer

and easy for users to learn basic
navigation and operation of the Research
software. Technologist

The user interface must efficiently Husbandry

allow users to achieve desired Technician
goals as stated in use cases.
Primary
Investigator

NFR02 Reliability Users are able to access Expected Research

zebrafish line information and Technologist
generate/view reports 98% of the
time without failure. Husbandry
Technician

Primary
Investigator

NFR03 Performance Under normal operating Expected Database

conditions, when users are Administrator
retrieving information the system
should return results in under 1 Software Quality
second. Assurance
Engineer
Search results should not exceed
3 seconds under heavier loads.

NFR04 Supportability Applications must be able to Expected Project Manager

operate on both Windows and
macOS operating systems. Development
Team

NFR05 Scalability Application must allow for addition Expected Project Manager
of new features for future
releases. Development
Team
Application must allow for addition
of new researchers and research Primary
labs. Investigator

NFR06 Availability Application must allow for Highly Husbandry

continuous availability under Desirable Technician
normal operating conditions.
 Research
Application must still function in Technologist
absence of internet connection.

NFR07 Security Database security must meet Expected IT Department

HIPAA requirements.
IT Security
Only designated users can add Officer
zebrafish lines or update changes
to existing lines. Primary
Investigator
Only designated users are able to
generate/view reports.

4.0 UML Domain Class Diagram

4.1 List of Classes

Class Name Description

ZebraFishLine Each zebrafish line represents a lineage. One line can exist in more
than one fish tank.

ZebraFishMortality Tracks the death of fish lines

Log A feed of status updates from the system

Notification Notify a user of certain condition

User Superclass that allows people to use the system

Report Generates a report on a specific zebrafish line.

Primary Investigator Primary investigator login

Researcher Researcher login

Husbandry Husbandry login

Lab Animal Lab Animal Services login

Services
4.2 Domain Class Diagram

5.0 Entity Relationship Diagram (ERD)

6.0 UML Systems Sequence Diagram
7.0 UML State Diagrams

8.0 Technologies

zFish Tracker is intended to be a desktop application developed using the follow technologies:
• Client-side
o JavaFX
• Business logic
o Java
 • Database
o Oracle Database
• Hosting service
o MicroSoft Azure
• Version control
o GitHub

9.0 Project Management

Part B: Software Design Architecture

1.0 Overview Model

1.1 Intended Audience

The Software Design Architecture document is intended for engineers, researchers and anyone
who wishes to learn more about the design and implementation of the zFish Tracker system.
It is also intended for anyone looking to modify and/or extend the existing incarnation of the
system.

1.2 Architectural Context Diagram (ACD)

2.0 Modularization

2.1 Partition of Analysis Model

2.1.1 Identity and Access Management Subsystem

• Account
• User
• Researcher
• Primary Investigators
• Husbandry
• Lab Animal Services

2.1.2 Colony Management Subsystem

• Researcher
• Husbandry
• Report
• ZebraFishLine

2.1.3 Notification Management Subsystem

• Researcher
• Husbandry
• Primary Investigators
• Lab Animal Services
• Report
• Message
• Notification
2.2 Class Responsibility Collaborator (CRC)
2.3 Design Class Diagram
3.0 Model View Controller Framework

3.1 MVC Pattern Diagram

3.1.1 Identity and Access Management

3.1.2 Colony Management
3.1.3 Notification
3.1.4 Reporting
4.2 Sequence Diagrams
4.2.1 Access Management
4.2.2 Colony Management

3.3 State Machine Diagrams

3.3.1 Colony Management

3.1.2 Reporting

4.0 Data Layer

5.0 Technologies

There are no updates to the technologies listed priorly in this document.

6.0 Project Management
Part C: System Design Document

1.0 Software Design Patterns

1.1.1 State Pattern

The state pattern is a behavioral design pattern which allows an object to alter its state
depending on its internal state. We could use this in our Colony Management Subsystem to
allow zebrafishLine objects to change from living to deceased to make monitoring mortality rates
easier.

1.1.2 Observer Pattern

The observer pattern allows multiple objects to be notified of when the state of another object
changes. This would be beneficial to us in our notification system. Users could subscribe to
receive notifications about the zebrafish lines that they own and when changes occur within
those lines.

1.1.3 Composite Pattern

The composite pattern allows objects and compositions of objects to be treated the same
way. We could use this in our Identity and Access Management Subsystem to allow all of our
different user class types to be created and managed the same way.

2.0 Using Common Software Design Patterns

Name: Facade Identity and Access Management Subsystem

Pattern

Problem: There are four different types of users with different properties. How
can we make a class that can encompass all four types of users under
one umbrella class?

Solution: We created a composite that is an abstract class, which allows all four
users to retain their different properties while falling under the same
User class.
Example:

Benefits and The benefits to this is that end users will have an easier time creating
Consequences: an account, and it makes it easier to add new users.

The consequence is that it will be difficult to separate the users of

different types when modifying properties of certain types of users.

Name: Observer Notification Management Subsystem

Pattern

Problem: When a line of fish changes state from alive to deceased, the users
attached to these lines need to be notified so they can record the
mortality rate. One user can be attached to many lines of fish, and they
cannot keep up with all of them at once.

Solution: We created a notification system to send an email to the user whenever

a line he is working on changes state.

Example:
Benefits and The benefit of this will allow users that are not working on the fish to be
Consequences: added to the notification list without modifying the fish or users.

The consequence of this will be the excess of notifications, because a

tank contains many lines of fish, and when an entire tank of fish changes
state to deceased, the user will get many emails.

Name: State Colony Management Subsystem

Pattern

Problem: When a line dies, the mortality must be recorded accurately for the Lab
Animal Technicians to review. When multiple lines die on different dates,
in different tanks, with different properties, it is very hard to keep track of
all mortalities.

Solution: We created the record mortality class in this subsystem that triggers
when the line changes state to deceased, all the information of that line
gets uploaded to the reporting system.

Example:

Benefits and The benefit of this is that it will save time when counting all the mortality
Consequences: rates, and finding common properties amongst the lines.

The consequence is that there is no criteria for mortalities to be updated,

which means if there is an user error, you will have to manually delete
the data from the report.
3.0 UI/UX Design

3.1 Identity and Access Management

3.2 Notification
4.0 High Level Component and Deployment Diagram

4.1 Component Diagram

4.2 Deployment Diagram

5.0 Project Management

6.0 Project Presentation

6.1 Presentation Transcript
Introduction
Hello my name is Jeffrey Sy presenting on behalf of group 10 for COMP246 at Centennial
college. [next slide]
Primer: A zebrafish is a small, quick-breeding species of fish that is used for scientific research,
typical human disease. Fish are tracked by their genetic lineages, or ‘lines’. [next slide]

1) Why did you choose the system you did? (1-2 mins)

• We decided to do zFish tracker because we an opportunity to creating something with a

clear need and a purpose
• Existing system was inefficient and outdated; done by hand using pen and paper.
• The idea of creating something that could contribute to scientific research was appealing
to us. [next slide]

2) What will this system do? (2-3 mins)

• Our system will make tracking zebrafish lines more efficient and accurate. Less likely to
make mistakes due to bad handwriting. Data entry will be standardized.
• Make it easier to observe trends, analyze, and compare data across zebrafish lines, and
with other researcher’s work.
• Allow users to generate reports
 • Provide an alert/notification system to users of the system
• Secure data by only allowing authorized access, and to provide data backups [next
slide]

3) How did you approach doing analysis and design for this system? (3-4 mins)

• While we weren’t actually building any software, we tried to apply the lessons we’ve
learned and adapted the Systems Development Life Cycle (SDLC) as a framework by
adapting the the following stages:
o Planning stage, where we gathered information and planned the basic project
approach and feasibility of our project
o Defining requirements, where we outlined all the things our software should be
able to do, this is where use cases and user stories were very helpful.
o Designing the product, this is the stage where we began the diagrams so we got
a better sense of what and how the system would come together
o Testing and Review, this is where we decided to see what was working and what
needed to be modified, if any components of subsystems need to be moved from
one area or another, etc.
o Returned back to the defining requirements stage. [next slide]
• Further refined to scrum methodology for a few reasons, it emphasized individuals and
interactions, customer collaboration and simplicity
• Agile also allowed us to adapt to any changing requirements and feedback from group
members.
• Further decided to adopt the scrum framework as the weekly sprints were very close to
how we wanted to accomplish this task.
• Began with user stories and use cases, and expanded on them through the use of
diagrams based on those elements.

4) So what specifically did you learn in the class and how did you apply your learnings to
the analysis and design of your project? (7-8 mins)

• Learned about the universality of systems design

• Learned how to properly use programs like visual paradigm to design and create UML
diagrams
• How to break down an application down into subsystems/modules. Begin the process of
modularization and the advantage of using that [next slide]
• Learned about software design patterns.
• We used design patterns to simplify the work we had to do. It also made it easier to
make less mistakes, since we’re essentially following templates we don’t need to repeat
the mistakes of the past.
• We used a state pattern for the colony management subsystem. When a zebrafish line
dies, the mortality must be recorded by the lab technicians to review. When multiple
lines die on different dates, in different tanks, with different properties, it is very hard to
keep track of all the moralities. By having a mortality class that triggers when the line
changes state to deceased, the information of that line gets uploaded to the reporting
system.
• Next we have an observer pattern that can be found in our notification management
subsystem. When the zebrafish line dies, it generates a state change that is also
observed by the notification system. Since the observer pattern can be used as a sort of
event handler to track state changes it made sense to use it for this subsystem.
 Therefore when line dies, the state of the zebrafish mortality class changes which can
trigger a notification to the right researcher. [next slide]
• Thenwe utilized a composite pattern for our identity and access management
subsystem. We have an abstract user class that is used by 4 different roles to have their
own properties, in this case, ID numbers, while utilizing the same methods and fields
that they all share. [next slide]
• I think another important lesson we learned was how important aspects of UI/UX design
were.
• Placing user in control
o Making actions reversible, be forgiving
• Make it easy to navigate/interact
o Give visual cues
o Make it predictable
o No technical jargon
o Real world metaphor (delete report as a trash bin) [next slide]
• Reduce things to remember
o User should not have to enter things more than once
o Show status updates (progress bar)
• Make things consistent
o Visual consistency
o Functional consistency
o Consistent user expectations

5) If you could do it again, what would you do differently? (1-2 mins)

-What we would do differently would probably seek more direct feedback from the intended
users of the system. It would be nice to hear their thoughts on how they would intend to use the
system, or what features they would like to see.

6) If you secured funding to build the system you designed, what are next steps from a
software engineering perspective? (1-2 mins)
-The next steps from a software engineering perspective would be to see the demand of such a
system, what kind of funding or interest we could generate, how many labs or research teams
would be interested, and finally begin the process of actually programming the system into
reality by developing the application software.

6.2 Presentation Slides

Please see additional attachment for PowerPoint slides.

6.3 PowerPoint Presentation

Please follow the link below for the presentation:

https://www.youtube.com/watch?v=_hWP14KpQZg