Software Design Description Reportcengleblebi.weebly.com/uploads/2/5/6/4/25640587/... · Technology...

Software Design Description Report 29.12.2013 Leblebi Hüseyin Alper ÇINAR Feyza YILMAZ

Özlem ÇÖKÜK

Hazal MOĞULTAY

Preface

In this document the Software Design Descriptions of Post Marketing Safety Study Tool (PMSST)

Project are explained.

This document is based on IEEE Standards. For this purpose “IEEE Standard for Information

Technology – Systems Design – Software Design Descriptions – IEEE Std 1016™-2009” document was

taken as reference. This software design document involves detailed and complete definitions and

specifications that can guide developers throughout implementation of this software.

In the first chapter of document overview about SDD is provided. In the following chapter definitions

used throughout this document is given. In third chapter conceptual model for software design

descriptions explained. In fourth chapter design descriptions are provided and finally in fifth chapter

all necessary viewpoints that are context, composition, logical, information, patterns use, interface,

interaction, state dynamics and resource viewpoints to develop this project are explained.

Table of contents 1 Overview .......................................................................................................................................... 6

1.1 Scope ....................................................................................................................................... 6

1.2 Purpose .................................................................................................................................... 6

1.3 Intended Audience .................................................................................................................. 6

1.4 References ............................................................................................................................... 6

2 Definitions ....................................................................................................................................... 6

3 Conceptual model for software design descriptions....................................................................... 6

3.1 Software design in context ...................................................................................................... 7

3.2 Software design descriptions within the life cycle .................................................................. 7

3.2.1 Influences on SDD preparation ....................................................................................... 7

3.2.2 Influences on software life cycle products ...................................................................... 7

3.2.3 Design verification and design role in validation ............................................................ 7

4 Design description information content ......................................................................................... 8

4.1 Introduction ............................................................................................................................. 8

4.2 SDD identification .................................................................................................................... 8

4.3 Design stakeholders and their concerns ................................................................................. 8

4.4 Design views ............................................................................................................................ 8

4.5 Design viewpoints ................................................................................................................... 8

4.5.1 Context Viewpoint: .......................................................................................................... 9

4.5.2 Composition Viewpoint ................................................................................................... 9

4.5.3 Logical Viewpoint ............................................................................................................ 9

4.5.4 Information Viewpoint .................................................................................................... 9

4.5.5 Patterns use viewpoint .................................................................................................... 9

4.5.6 Interface Viewpoint ......................................................................................................... 9

4.5.7 Interaction Viewpoint ...................................................................................................... 9

4.5.8 State Dynamics Viewpoint ............................................................................................... 9

4.5.9 Resource Viewpoint ......................................................................................................... 9

4.6 Design elements ...................................................................................................................... 9

4.7 Design overlays ........................................................................................................................ 9

4.8 Design rationale ..................................................................................................................... 10

4.9 Design languages ................................................................................................................... 10

5 Design viewpoints ......................................................................................................................... 10

5.1 Introduction ........................................................................................................................... 10

5.2 Context viewpoint ................................................................................................................. 10

5.2.1 Authentication ............................................................................................................... 11

5.2.2 Eligibility Criteria ............................................................................................................ 13

5.2.3 Data Selection ................................................................................................................ 16

5.3 Composition viewpoint ......................................................................................................... 18

5.3.1 Internals of PMMST ....................................................................................................... 19

5.3.2 Externals o PMSST ......................................................................................................... 19

5.4 Logical Viewpoint .................................................................................................................. 20

5.4.1 Class relations ................................................................................................................ 21

5.4.2 EligibilityCriteria ............................................................................................................ 22

5.4.3 CriteriaGroup ................................................................................................................. 22

5.4.4 GroupItem ..................................................................................................................... 22

5.4.5 Criterion ......................................................................................................................... 22

5.4.6 ClinicalStatement .......................................................................................................... 22

5.4.7 MedicationCriterion ...................................................................................................... 22

5.4.8 MedicationInformationModel ....................................................................................... 23

5.4.9 ConditionCriterion ......................................................................................................... 23

5.4.10 TemporalConstraintModel ............................................................................................ 23

5.4.11 CodeModel .................................................................................................................... 23

5.4.12 IvlTSModel ..................................................................................................................... 23

5.4.13 PQModel ........................................................................................................................ 23

5.4.14 IvlPQModel .................................................................................................................... 24

5.4.15 DataSelection................................................................................................................. 24

5.4.16 DataTree ........................................................................................................................ 24

5.4.17 DataElement .................................................................................................................. 24

5.4.18 Variable .......................................................................................................................... 25

5.4.19 Value .............................................................................................................................. 25

5.4.20 Question ........................................................................................................................ 25

5.4.21 Date Variable ................................................................................................................. 25

5.4.22 Numeric Variable ........................................................................................................... 25

5.4.23 DateValue ...................................................................................................................... 25

5.4.24 NumericValue ................................................................................................................ 25

5.4.25 DateQuestion................................................................................................................. 25

5.4.26 NumericQuestion .......................................................................................................... 25

5.4.27 Result ............................................................................................................................. 26

5.5 Information Viewpoint .......................................................................................................... 26

5.5.1 Authentication ............................................................................................................... 26


5.5.3 Data Selection ................................................................................................................ 27

5.6 Patterns use viewpoint .......................................................................................................... 28

5.6.1 Model View Controller Pattern ..................................................................................... 28

5.6.2 Singleton Pattern ........................................................................................................... 28

5.7 Interface viewpoint ............................................................................................................... 28

5.7.1 Login / Logout Page ....................................................................................................... 29

5.7.2 Eligibility Criteria Page ................................................................................................... 29

5.7.3 Data Selection Page ....................................................................................................... 30

5.7.4 Result Page .................................................................................................................... 30

5.8 Interaction viewpoint ............................................................................................................ 31

5.8.1 Authentication ............................................................................................................... 31


5.8.3 Data Selection ................................................................................................................ 38

5.8.4 Result ............................................................................................................................. 41

5.9 State Dynamics Viewpoint ..................................................................................................... 42

5.10 Resource viewpoint ............................................................................................................... 42

5.10.1 Backbone ....................................................................................................................... 42

5.10.2 Backbone-Relational ...................................................................................................... 43

5.10.3 Backbone Marionette .................................................................................................... 43

5.10.4 jQuery ............................................................................................................................ 43

5.10.5 Bootstrap ....................................................................................................................... 43

5.10.6 Require JS ...................................................................................................................... 43

5.10.7 Underscore .................................................................................................................... 43

1 Overview In this document we describe the design details of Post Marketing Safety Study Tool (PMSST). In

second chapter we gave definitions that we used in this document. Then in next chapter conceptual

model for software design description is provided. In the following chapter design descriptions are

given in details. Lastly in chapter 5 the 9 viewpoints that are associated with our project explained in

details with diagrams.

1.1 Scope The scope of this document is giving detailed design description about the software that will be

developed. Since SDD will be the primary reference for code development, it includes all necessary

information about the project. We explained all development states by dividing them into viewpoints

in order to provide quick reference to related functionality.

1.2 Purpose This document aims to describe the design of the project of the group number 25 named Leblebi

about Post Marketing Safety Study. It describes the design descriptions of required product features,

constraints and modules. It provides a complete reference for development of software.

1.3 Intended Audience This Software Design Description document is intended for:

- Developers can use this document in order to understand the software easily and in this way

they can easily improve the features or add new functionalities to the system.

- Testers can use this document in order to find some bugs for their testing strategy.

Generally, bugs are easy to find by using software requirements document.

1.4 References Project Proposal Document of PMSST, 2013

Software Requirement Specification of PMSST, 2013

IEEE. IEEE Std 1016™-2009. IEEE Standard for Information Technology—Systems Design—

Software Design . Software & Systems Engineering Standards Committee of the IEEE

Computer Society, 2009.

2 Definitions

PMSST Post Marketing Safety Study Tool

ADE Adverse Drug Events

EHR Electronic Health Record

CHF Congestive Heart Failure

User Safety analysts, hospitals, pharmacists etc.

MDR Metadata Repository

SILDS Semantic Interoperability Layer Data Service

3 Conceptual model for software design descriptions This section gives a conceptual model for SDD to give the basic knowledge needed to understand the

software.

3.1 Software design in context As explained in the SRS targets of this project are health professionals. We will try to give the most

accurate result in a most feasible time.

For this purpose we will create this software in an object oriented model and we will use different

libraries to make sure everything is calculated properly and fast. These libraries are explained later.

This software can be extended to solve many different health issues, but at the moment we will

focus on the database operations according to the users choices and the statistical examination of

the results.

3.2 Software design descriptions within the life cycle This software will be created following the IEEE standards. The main milestones of this project are

requirements analysis, design description analysis, implementation and finally verification and

validation.

3.2.1 Influences on SDD preparation

SRS document is the guideline for design process of this software. In this document we considered

every functional and non-functional requirement that were covered in the SRS. Given specifications

and the possible new demands of the user that were not explained in the SRS will specify the design

process of this project.

3.2.2 Influences on software life cycle products

First of all user interfaces should be designed. Before connecting to the databases user interfaces and

statistical calculations should be demonstrated with a sample data taken from the database. With

this approach user can have an idea about the final version of this product.

Moreover, SDD document will lead us all the way through the project. According to this document or

the first phase, some specifications may be added or removed from the software requirements. With

this approach, requirements of the user can be met exactly before starting to the test phase.

3.2.3 Design verification and design role in validation

Verification is the process that we will test the software whether it satisfies all the requirements. In

this process SRS and SDD documents will be our guidelines. We will check whether all the functional

and non-functional properties of the final product, are met in the requirements of these documents.

Moreover, we will check whether the viewpoints that are explained in section 5 are implemented

correctly.

Validation is the stage where the user decides if the product is consistent with the main purpose.

This software is created to be able to help safety analysts to investigate the relation between

illnesses and drugs. This system will be validated in terms of its usage within the area. SDD will rise all

the design issues and will be helpful in the validation process.

4 Design description information content

4.1 Introduction Software Design Description of PMSST identifies how this tool will be designed and implemented.

While the design of PMSST is a modular object-oriented structure and practical, qualified interface

will be designed.

The contents are also going to be explained in this section are as follows:

- Identification of the SDD,

- Identified design stakeholders,

- Identified design concerns,

- Selected design viewpoints, each with type definitions of its allowed design elements and

design languages,

- Design views,

- Design overlays,

- Design rationale

4.2 SDD identification Project authorship, organization of the project team and date of the report are given in cover page of

SDD. In the first section an overview of SDD is given. Scope of the SDD report refers to the section

1.1, Purpose of the SDD report refers to section 1.2 and Intended Audience of this document refers

to section 1.3. For design conceptual model for software design descriptions refer to the section 3.

Lastly, for the design viewpoints including context, composition, logical, information, patterns use,

interface, interaction, state dynamics and resource viewpoints refer to the section 5.

4.3 Design stakeholders and their concerns The design stakeholders of PMSST are safety analysts which we call as the user in document. The

design concerns of the users are using this application in order to investigate the relation between

illnesses and drugs and side effects of drugs on patients.

4.4 Design views One of the design concerns is that the extendibility of the project. All of the classes and relations are

designed to make the system as flexible and extendable as possible.

Another concern is that, secure transactions between the servers. All the connections are

encapsulated so that no other process will interrupt the connections.

The design views are governed by the design viewpoints that are explained in chapter 5.

4.5 Design viewpoints This section will be used to give brief outline on the design viewpoints which are used in section 5.

A design viewpoint addresses a different perspective to be focused on to effectively encompass

requirements that have been previously created and to identify the users as to which these

requirements are relevant. There are eleven design viewpoints which have been used to address the

range of the design concerns.

4.5.1 Context Viewpoint:

The context viewpoint depicts services provided by a design subject with reference to an explicit

context. That context is defined by reference to actors that include users and other stakeholders,

which interact with the design subject in its environment. The Context viewpoint provides a “black

box” perspective on the design subject.

4.5.2 Composition Viewpoint

The Composition viewpoint describes the way the design subject is (recursively) structured into

constituent parts and establishes the roles of those parts.

4.5.3 Logical Viewpoint

The purpose of the Logical viewpoint is to elaborate existing and designed types and their

implementations as classes and interfaces with their structural static relationships. This view point

also uses examples of instances of types in outlining design ideas.

4.5.4 Information Viewpoint

The Information viewpoint is applicable when there is a substantial persistent data content expected

with the design subject.

4.5.5 Patterns use viewpoint

This viewpoint addresses design ideas (emergent concepts) as collaboration patterns involving

abstracted roles and connectors.

4.5.6 Interface Viewpoint

The Interface viewpoint provides information designers, programmers, and testers the means to

know how to correctly use the services provided by a design subject. This description includes the

details of external and internal interfaces not provided in the SRS. This viewpoint consists of a set of

interface specifications for each entity.

4.5.7 Interaction Viewpoint

The Interaction viewpoint defines strategies for interaction among entities, regarding why, where,

how, and at what level actions occur.

4.5.8 State Dynamics Viewpoint

Reactive systems and systems whose internal behavior is of interest use this viewpoint.

4.5.9 Resource Viewpoint

The purpose of the Resource viewpoint is to model the characteristics and utilization of resources in

a design subject.

4.6 Design elements The main design elements are entities, attributes and some other member associated with

communication and relations between modules and user of our project. These main design elements

are defined inside the related viewpoints in detail in chapter 5.

4.7 Design overlays Design Overlays usually used to add information to the existing views. This concept will be explained

clearly when necessary in the design viewpoints section.

4.8 Design rationale We choose Object-Oriented approach while designing our project because by this way we will be

able to separate models, views and other functionalities. Moreover, the object oriented design will

help us encapsulating the server connections.

For database design, we choose to create tables as much similar as the classes we used. Therefore,

the communication between databases and our system will be easier and the synchronization

between UI and database will not require any other efforts.

4.9 Design languages In this document Unified Modeling Language(UML) will be used as the modeling language for the

diagrams. The modeling language is used for emphasizing the static structure and dynamic behavior

of the system.

5 Design viewpoints

5.1 Introduction In this chapter, the viewpoints of the PMSST project are explained in detail. The viewpoints

explained, with order, as follows:

Context viewpoint

Composition viewpoint

Logical viewpoint

Information viewpoint

Patterns use viewpoint

Interface viewpoint

Interaction viewpoint

State dynamics viewpoint

Resource viewpoint

5.2 Context viewpoint Post Marketing Safety Study software context viewpoint shows the functions provided by a design.

There are four major parts which are Login/Logout, Eligibility Criteria, Data Selection and Result View

parts in the system. Each part has sub-parts too. The context is defined by the elements that interact

with the software like users:

5.2.1 Authentication

5.2.1.1 Sign Up

Diagram:

Description Part:

When users open the application, firstly meets the login page. In this part, user can sign up before

the login part of the system.

Normal Flow of Events:

1. User opens the web page.

2. Login page occurs on the screen.

3. User presses the “Sign Up” button.

4. User can fill the required information.

5.2.1.2 Login

Diagram:

Description Part:

Thanks to username and password, user can enter the system by login.




3. User enters the name.

4. User enters the password.

5. User presses the “Login” button.

5.2.1.3 Logout

Diagram:

Description Part:

This part provides to quit from the system.




3. User login to system.

4. User makes the analyses with filters using application.

5. User presses the “Logout” button.

5.2.1.4 Edit User Settings

Diagram:

Description Part:

In this part, user can change the information like name, surname, password and email after

the login part.




3. User logins to system.

4. User presses the “Edit User Settings” button.

5. The information belong to user can be changed here.

5.2.2 Eligibility Criteria

5.2.2.1 Add Criterion

Diagram:

Description Part:

Eligibility Criteria page allows user to populate patient health record such as age, diseases,

diseases time, drugs etc. without gathering any private data like name and country. To determine the

patient type, user can choose different medicals and conditions in this part.



2. Eligibility Criteria page occurs on the screen.

3. User determine the conditions that restricted by Search concept.

4. User chooses the condition among determined conditions.

5. User also chooses the medicals that patients use.

5.2.2.2 Edit Criterion

Diagram:

Description Part:

To determine the patient type, user chooses different condition. After that, user can change

the type of the condition in this part. For example; at first, user chooses a patients with disease B and

later, change this with disease A.




3. User chooses the condition.

4. User changes condition parameters.

5.2.2.3 Edit Constraints

Diagram:

Description Part:

User can give the patient gender, disease time or drug used by patient to condition in order to

filter specifically in this part.




3. User chooses the criterion as condition or medical.

4. User changes condition parameters

5. User edits condition with different selected data type.

5.2.2.4 Setting Relations

Diagram:

Description Part:

In this part, user can combine many selected criteria to create different type filter system.

Therefore, user selects one of the relations like And, Or etc.




3. User chooses the conditions

4. User chooses another the conditions

5. User determines the relation for 2 conditions.

5.2.2.5 Setting Temporal Relations

Diagram:

Description Part:

With temporal relations, the relations that are selected in previous part can be restricted by

specific data such as age, time and gender. Therefore, the filter system eliminates many criteria

about patients for user.




3. User chooses the conditions

4. User determines the relation with a temporal.

5.2.2.6 Search Concept

Diagram:

Description Part:

While user is writing the condition name into related box, all conditions are automatically

checked for to list all the matching conditions.




3. User writes the condition into related box.

4. All matching conditions are listed on the screen.

5.2.3 Data Selection

5.2.3.1 Select Object Class

Diagram:

Description Part:

Data Selection page allows user to populate the patient information according to conditions -

patient type- that are determined in Eligibility criteria part. This information includes patient data like

allergy, disease type and time.



2. User determines the type of patients in Eligibility Criteria.

3. Then, Data selection page occurs on the screen.

4. User selects new conditions formed according to data in Eligibility Criteria part.

5.2.3.2 Select Data Element

Diagram:

Description Part:

According to selected condition in add condition part, new sub-conditions occur on the screen.

In this part, user can determine very specific conditions to add the filter system.


1. Data selection page occurs on the screen.

2. User selects an object class

3. User chooses data element.

5.2.3.3 Variable Assignment

Diagram:

Description Part:

In this part, user can redefine an object class or data element. User makes this by giving a new

name to selected object class. Actually, user creates a condition object with this definition. The

results are also shown with this variable name. This method is also very helpful when user wants to

compare and combine two nested condition lists. It just gives a simple name.



2. User selects object class

3. User chooses data element and gives it a name.

5.2.3.4 Value Assignment

Diagram:

Description Part:

In this part, user defines the information of patients like age, gender and so on to make explicit

selection.





4. User gives patient information.

5.2.3.5 Query Assignment

Diagram:

Description Part:

According to result of Value assignment part, user can determine what kinds of information

about patient are wanted with this selection.





4. User gives patient information.

5. User selects what kinds of information he/she wants from system to filter.

5.3 Composition viewpoint In this section, the modules of the PMSST and the other systems that the PMSST interacts with are

described.

5.3.1 Internals of PMMST

Internally, PMSST have 4 main packages. These packages are described in the following component

diagram.

5.3.1.1 Database

Database module helps to manage databases. The PMMST keeps the user information and their

selections in EligibilityCriteria and DataSelection modules in databases. All of the database modules

are singletons to keep the database management safe and easy.

5.3.1.2 Core

This package contains core classes of PMSST. All of the models used in PMMST are kept in this

module. Moreover, this package keeps the classes to manage authentication, eligibility criteria and

data selections. Lastly, results are prepared in this module.

5.3.1.3 Web

Web package contains a REST API that interacts with Core package. This package is a bridge between

UI and Core packages.

5.3.1.4 UI

UI package contains all of the views and controllers to define a user interface. The pattern used in

this module is MVC. This package is directly interacted with the user.

5.3.2 Externals o PMSST

PMSST interacts with 3 other servers. These servers are described in the following deployment

diagram.

5.3.2.1 Semantic Metadata Repository (MDR)

Semantic MDR involves the PMSST in two operations. First, the PMSST will take the information of

the data elements which the user may select. The user will be able to select from these data

elements. Also, the PMSST server keeps the information that how a data element can be retrieved

from a patient history. When preparing the results, PMSST will interact with Semantic MDR to get the

extraction specifications of the data elements that the user is selected in data selection page.

5.3.2.2 Terminology Server

This server keeps the coded data for different code systems. It has a rest API that allows searching

across coded values. The PMSST will connect this server whenever a coded value is needed.

5.3.2.3 Semantic Interoperability Layer Data Server (SIL-DS)

This server keeps the patient history. It retrieves the histories from databases of different hospitals.

It has a REST API that accepts an eligibility criteria and returns eligible patients.

5.4 Logical Viewpoint In this section, the classes used in the project and their relations are explained in details. Firstly, a

complete class diagram containing all classes and their relations are given. Then, each of the classes

and their methods and fields are explained in detail.

5.4.1 Class relations

5.4.2 EligibilityCriteria

EligibilityCriteria is used to define the population of the patients that the user wants to work with. In

other words, the user may select the common criteria for the patients.

Method/Field Definition

List<CriteriaGroup>inclusionCriteria The criteria list that the user wants the patients to have.

List<CriteriaGroup>exclusionCriteria The criteria list that the user wants the patients not to have.

void addInclusionCriteria() Adds a new inclusion criteria.

void addExclusionCriteria() Add a new exclusion criteria.

5.4.3 CriteriaGroup

CriteriaGroup represents a set of criteria that related with each other with logical operators.


Boolean negatiationIndicator Indicates whether the criteria group is negated or not.

CodeModel conjunctionCode Logical operator from a code system.

List<GroupItem>groupItems The group items that the current criteria group is consisted of.

void setConjunctionCode(CodeModel code) Set the logical operator.

void addGroupItem(GroupItem groupItem) Add a new group item.

5.4.4 GroupItem

GroupItem represents whether a single criterion or a criteria group.


CriteriaGroup criteriaGroup CriteriaGroup that the criteria group represents

Criterion criterion A single criterion that the criteria group represents

void setCriterion(Criterion criterion) Sets the group item as a single criterion

void setCriteriaGroup(GroupItemgroupItem) Sets the group item as a criteria group

5.4.5 Criterion

Criterion class represents a clinical statement and its temporal constraint. For example, the user may

define a clinical statement that starts 10 days after the other conditions that are logically related are

occurred.


ClinicalStatement clinicalStatement Clinical statement of the criterion

TemporalConstraintModel temporalConstraint Temporal constraint for the criterion

5.4.6 ClinicalStatement

Clinical statement class is the base class for the criteria. MedicationCriterion and ConditionCriterion

classes are derived from this class.

5.4.7 MedicationCriterion

MedicationCriterion class represents a criterion that related with medications.


MedicationInformationModel medicationInformation

Information about the medication

CodeModel productForm The way that the medication is applied. (e.g. oral)

IvlTSModel medicationStartStop The date interval that the medication is applied.

PQModel dose The dose of the medication.

5.4.8 MedicationInformationModel

MedicationInformationModel contains information about a medication.


CodeModel codedActiveIngredient Active ingredient of the medication.

CodeModel codedProductName Name of the medication.

CodeModel codedBrandName The name of the producer of the medication.

5.4.9 ConditionCriterion

ConditionCriterion class represents a criterion that related with conditions. (e.g. illnesses, allergies,

disabilities etc.)


CodeModel problemCode The code of the problem.

CodeModel problemStatus The code of the status of the problem.

CodeModel problemSeverity The code of the severity of the problem.

IvlTSModel problemDate The time interval that the condition exists.

5.4.10 TemporalConstraintModel

TemporalConstraintModel is a class that represents a temporal constraint. (i.e. defining the sentence

"3 years later" in a standardized way)


PQModel pauseQuantity The quantity of the temporal constraint.

CodeModel type The type of the temporal constraint.

5.4.11 CodeModel

CodeModel represents a value with its code and code system.


String code The code of the value.

String codeSystem The code system that the code belongs to.

String displayName The human readable name of the code.

5.4.12 IvlTSModel

IvlTSModel represents a time interval.


DateTime start The beginning of the time interval.

DateTime end The end of the time interval.

5.4.13 PQModel

PQModel represents a value with its unit.


String unit The unit of the value.

Float value The value of the model.

5.4.14 IvlPQModel

IvlPQModel represents a PQModel interval.


PQModel low The low value of the PQModel interval.

PQModel high The high value of the PQModel interval.

5.4.15 DataSelection

Data selection class is used to specify the type of the data that the user wants to examine.


List<DataTree>dataTrees The list of the selected data.

List<Variable> variables The list of the defined variables.

void addDataTree() Add a new selected data.

void deleteDataTree() Deletes a selected data.

5.4.16 DataTree

Data tree is the list of data elements that the user is selected. The selected data elements are kept in

a tree structure to provide reusability and define sequential data elements.


DataElement current The data element that the user selected.

List<DataTree> children The child data elements which are related with the current data element.

void addDataElement() Adds a data element.

void removeDataElement() Removes a data element.

void updateDataElement() Updates a data element.

5.4.17 DataElement

DataElement is used for specifying the data to be selected. This data element can be set as value or

question. Moreover, a data element can be assigned to a variable.


String name The name of the data element.

String dataType The data type of the data element.

String commonDataElementID The ID of the data element kept in MDR.

String definition The definition of the data element.

String codeSystem The code system that the data element is coded.

Variable variable The corresponding variable of the data element.

Value value The given value of the data element.

Question question The asked question for this data element.

void setAsVariable() Sets the data element as variable.

void setAsGiven() Gives the data element a value.

void setAsAsked() Signs the data element as asked.

5.4.18 Variable

Variable class represents a defined variable from a data element. Moreover, a user may define

operations (e.g. addition) on this variable.


String name The name of the variable

String dataElementId The id of the data element that the variable corresponds to

String operator The operator type of the variable

List<Object>args The arguments used for defined operator.

Value val The value given for the operation

5.4.19 Value

Value represents a value with some operations on it.


String val The actual value.

String operator The operator to modify value.

List<Object>args The arguments to modify the value.

5.4.20 Question

Question represents a query with some relations with it.


String type The type of the question.

String operator The operator to add some details a question.

List<Object>args The details of the modification

5.4.21 Date Variable

DateVariable is inherited from Variable class. It is used to assign variables to date values or questions.

5.4.22 Numeric Variable

NumericVariable is inherited from Variable class. It is used to assign variable to numeric values or

questions.

5.4.23 DateValue

DateValue is inherited from Value class. It is used to keep date values.

5.4.24 NumericValue

NumericValue is inherited from Value class. It is used to keep numeric values.

5.4.25 DateQuestion

DateQuestion is inherited from Question class. It is used to query date values.

5.4.26 NumericQuestion

NumericQuestion is inherited from Question class. It is used to query numeric values.

5.4.27 Result


Object getResults() Gets eligible patients, processes user's data selection and returns the results.

Object getResultsHumanReadable() Returns the result in a human readable format.

5.5 Information Viewpoint In this section, relations of the different classes are explained. Main purpose of the following ER

diagrams is to explain class diagrams in a different way. One can understand relationships between

classes without being confused by attributes easily by these diagrams. More detailed information

about the classes can be found in logical viewpoint section.


The PMSST keeps all the authentication information and user preferences. The following ER diagram

represents the tables and their relations of the authentication database.


The eligibility criteria that the user selected will be saved into database to make them reusable. The

following ER diagram represents the tables and their relations to save eligibility criteria to a DB.


The data selections that the user selected will also be saved into database. The following ER diagram

represents the tables and their relations to save data selections to a DB.

5.6 Patterns use viewpoint In order to make some parts of the software reusable, some design patterns are used. In our project

we will use two main patterns which are model view controller and singleton. These patterns are not

only reusable but also applicable to any data. Usage of the patterns is explained below.

5.6.1 Model View Controller Pattern

This pattern enables us to separate basic information about the data and user interface. Model

constitutes the hidden data. View represents the form that the data is presented to the user. Finally

the controller converts input to the compatible type for the model or the view.

5.6.2 Singleton Pattern

This pattern is useful when we need a specific class to be instantiated with only one object. Singleton

Pattern is used when we need an object that is controlling the main flow of the software.

5.7 Interface viewpoint The Interface viewpoint provides information for designers, programmers, testers and users to know

how to correctly use the services provided by the system. For this purpose we will provide a

schematic interface for each use case that was defined in SRS.

5.7.1 Login / Logout Page

Login page provides user different options like login, sign up, edit user settings and logout. At

beginning of the application, these parts are represented by buttons. After selecting a button, the

related subpage occurs on the screen.

1. Login allows user to enter the system.

2. Sign up allows user to record login information.

3. Edit user settings part allows user to change information needed to login part.

4. Logout allows user to quit from the system.

5.7.2 Eligibility Criteria Page

Eligibility Criteria page allows user to populate patient health record such as age, diseases, diseases

time, drugs etc. without gathering any private data like name and country. To determine the patient

type, user can choose different conditions in this part. “Setting relations” button includes different

relations such as And, Or and so on. It is also provided to add a temporal feature like time and age

interval besides relations. This gives user a chance for very detailed filtering. Moreover, while user

writing the condition name into related box, system automatically searches and lists all conditions

matched with letters. This is called “search concept” part and it occurs when user starts to write

condition.

5.7.3 Data Selection Page

Data Selection page includes some data that are determined according to selected conditions in

Eligibility Criteria. These data also include sub-parts. If user selects a data, the related sub-data occur

on the screen. When user choose a data (also called condition), it can be represented with different

name. This new name is used to show the results. Besides, user can combine this new condition with

other conditions in an easy way. These processes are called “choose data” and “data assignment”

parts. New criteria can be added if user wants.

5.7.4 Result Page

Result page is very important for the filtering system. All results are shown as a statistical and

graphical data. User can understand results clearly in this page. By using “Save” and “Download”

buttons, user can store results in the system and get the result into computer. Besides, all

specifications selected in previous test or login time can be recorded automatically in system.

5.8 Interaction viewpoint In this viewpoint we explained the relations of modules and functions to each other and the flow of

events. This viewpoint clarifies the communication and messaging between user and modules. In

order to show the relations and interactions, sequence diagram is used in this viewpoint. The flow of

events is shown sequentially which makes understanding the occasion times of events easy. We

separate this viewpoint according to modules and every module includes sequence diagrams

showing its functions and fields which provide communication between user and other modules.


The parts of Authentication module are signup, login and logout. These functionalities are explained

below in details using sequence diagrams to show process step by step.

5.8.1.1 Sign Up

The user has to sign up to system in order use it. The procedure for one user to sign up is shown in

the sequence diagram below.

It can be seen from diagram that user should send signup request in order to sign up to system. Then

Authentication module return sessionID if signing up is successful.

5.8.1.2 Login

User should be logged in to use application. The procedure for logging in for one user is shown in the

sequence diagram below.

In the diagram user sends login request to Authentication module and receives sessionID.

5.8.1.3 Logout

After finishing, user should be log out from system by sending logout request to Authentication

module.

5.8.1.4 Editing User Settings

The user can edit his/her settings after logging in to system. The procedure for editing user settings is

shown in the below diagram step by step.

After login user should send editUserSettings request to Authentication module.


Eligibility Criteria module provides the user specifying patient population. The functionalities used for

this purpose are adding and editing criterion, searching concept and setting relations. The flows and

relations of these functionalities are explained below with sequence diagrams.

5.8.2.1 Adding and Editing Criterion

The procedure to add and edit criterion is shown in sequence diagram below.

User should be logged in first. After that in order to add criterion addCriterion request should be

send to Eligibility Criteria module. In order to edit criterion user must be defined that criterion first.

Then with editCriterion request to the Eligibility Criteria module user can edit the criterion.

5.8.2.2 Searching Concept

Searching Concept is the functionality that provides finding the code for desired medication or

condition to add criterion list. The flow of events for search concept functionality is shown below.

In order to search concept the criterion must be already added. Then user can send seachConcept

request to the Eligibility Criteria module. This module gets results according to user request from

Terminology Server and returns it to user. Then user can select the result s/he desired between

them.

5.8.2.3 Setting Relations

There are two different relation functionality that can be used namely setRelation and

setTemporalRelation. Set relation functionality is used for defining AND/OR relation and set

Temporal Relation is used for setting time interval between two defined criterions. The steps are

shown in sequence diagram below. The steps to set relations are shown below in sequence diagram.

As in the diagram, user first must be logged in and already added two criterions to set their relations.

Then with setRelation request user can set AND/OR relation between these defined criterions and

with setTemporalRelation request can set time interval between them.


Data Selection module provides user to specify the information s/he needs. For this purpose there

are functionalities such that selecting data element from the list of data elements in object class and

specifying it.

5.8.3.1 Selecting Data Element

Selecting Data Element provides user to choose data element which helps to keep the information

that s/he wants. The steps for selecting data element are shown below.

Again user must be logged in. Later getContextList request sends to Data Selection module when

user opens Data Selection page. Data selection module sends getAllContext request to Metadata

Repository in order to return contexts to user. Then Metadata Repository returns contexts in XML

format. Data Selection module converts its type to json and returns it to user. User selects the

context and Data Selection Module sends getDataElements requests to Metadata Repository, gets

data elements, groups them according to object classes and return the list of object classes related to

context that user chose. Then user specifies the object class that s/he wants from Data Selection

Module and the list of data elements inside that object is return to user. Lastly user can choose the

data element that s/he can keep the related information.

5.8.3.2 Specification of Chosen Data Element

After data element is chosen user must specify its properties such as giving a value, setting as query

and assigning variable. The steps for all specifications are shown below.

There are two options that user can assign to one data element namely giving a value to data

element and setting as query. User can apply only one of them to one data element.

In order to give a value to chosen data element user should send giveValueToDataElement to Data

Selection Module. Then this module sends getValueCode requests to Terminology Server and gets its

code so that the value of current data element set to that code.

In order to set data element as query user should send setAsQuery request to Data Selection

Module. Then the information kept on that data element is set according to given query type, for

example first value, last value or all values of the query that data element is associated.

Lastly the value can be assigned to data element by sending assignVariable request to Data Selection

module. The value that user assigned is saved and then user can reuse it.

5.8.4 Result

This module shows the results based on selections that user made in previous modules. The function

flows in result module is explained in sequence diagram below.

The getResults requests send to result module when user opens result page. Then Result module

sends getEligiblePatients request to Semantic Interoperability Layer (SIL-DS) and gets information of

patient that are eligible the specifications that user made in Eligibility Criteria module. After that for

all patient information returned from SIL-DS, getExractionSpecification request is send to Metadata

Repository. Repository returns extractionSpecification for patient information and then data is

extracted and processed according to specifications that user made in Data Selection Module. Lastly

produced results are returned to user and s/he is able to save or download these results.

5.9 State Dynamics Viewpoint This viewpoint is used to specify what happens when specific events occur. In our system in order to occur one module the other one must be completed. Since there is an order between modules and their methods we used this viewpoint to show that order and state transitions clearly. State Transition diagram is used to display relations and dependencies between modules and user from the beginning to the end of the application.

In our application, first, user should be logged in to system. Then the page to define eligibility criteria

is displayed. User has to define one or more criteria in this page. After defining eligibility criteria, the

user will be able to select the data to be extracted from data selection page. In data selection page

the available information that can be extracted from patient histories will be displayed. Finally, after

selecting data, the user will be able to display results. Moreover the user will be able to download

the results to their personal computers.

5.10 Resource viewpoint In this section some basic information about the used libraries is given. Related references can be

found in the references. Note that we will use the final versions of each of them.

5.10.1 Backbone

When creating a web application, one of the very hard things is to synchronize the data with the

DOM. The compulsive thing is to handle the queries and reflect the needed result to the user

simultaneously.

Backbone provides us models that we can bind to the RestAPI. When a model changes, we will not

need to update the DOM. Backbone will update everything related when this change triggers to.1

1http://backbonejs.org/

http://backbonejs.org/

5.10.2 Backbone-Relational

Backbone relational provides many types of relations to Backbone. By the help of backbone

relational we can control the serialization of different objects, determine the type of relations which

binds one object to many, and when a change triggered we can make sure that not only one object is

updated, also all other objects that has relations are changed.2

5.10.3 Backbone Marionette

Marionette is an application library for Backbone. It simplifies the construction of large JavaScript

applications.

Marionette is a collection of design patterns that we use when we are building a project with

backbone, also it includes some application, event driven and messaging architectures, 3

5.10.4 jQuery

jQuery is a fast JavaScript library. jQuery will help us to manipulate HTML document and also API is

much simpler and it is usable with every browser. 4

5.10.5 Bootstrap

Bootstrapisafreecollectionoftoolsforcreatingwebsitesandwebapplications. It contains HTML and CSS-

based design templates for typography, forms, buttons, navigation and other interface components,

as well as optional JavaScript extensions.5

5.10.6 Require JS

RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used

in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS

will improve the speed and quality of the code.6

5.10.7 Underscore

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming

support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in

JavaScript objects. Underscore provides 80-odd functions that support both the usual functional

suspects: map, select, invoke — as well as more specialized helpers: function binding, javascript

templating, deep equality testing, and so on. It delegates to built-in functions, if present, so modern

browsers will use the native implementations of forEach, map, reduce, filter, every, some and

indexOf.7

2http://backbonerelational.org/

3http://marionettejs.com/

4http://jquery.com/

5http://getbootstrap.com/

6http://requirejs.org/

7http://underscorejs.org/

http://backbonerelational.org/

http://marionettejs.com/

http://jquery.com/

http://jquery.com/

http://requirejs.org/

http://underscorejs.org/

6 Planning

6.1 Team Structure Our team consists of 4 senior year students from Computer Engineering Department. We plan to

divide the workload equally. Our names, student ids and e-mail addresses are listed below.

1 Feyza YILMAZ 1746494 [email protected]

2 Hazal MOĞULTAY 1746262 [email protected]

3 Özlem ÇÖKÜK 1746585 [email protected]

4 Hüseyin Alper ÇINAR 1746577 [email protected]

6.2 Estimation (Basic Schedule)

Time Period Topic Responsible

13th October Project Proposal All End of October SRS All 15th November Technology Research All End of November SDD All 7th December Project Initialization All 15th December Design of the Eligibility Criteria

Page Feyza & Alper

15th December Design of the Data Selection Page

Hazal & Özlem

16th December First Iteration All End of December Report Updates All 7th January Team Presentation and Second

Iteration All

End of January First Prototype of the Eligibility Criteria Page

Feyza & Alper

End of January First Prototype of the Data Selection Page

Hazal & Özlem

15th March SILDS & Terminology Server Integration

Feyza & Alper

15th March Semantic MDR Integration Hazal & Özlem 15th April Algorithm Development for

Result Page All

End of April First Prototype of the Result Page

Feyza & Hazal

End of April Server - side implementations of Result Page

Alper & Özlem

15th May Project Revisions and Tests All End of May Finalization of the Project All

Software Design Description Reportcengleblebi.weebly.com/uploads/2/5/6/4/25640587/... · Technology...

Documents

Transcript of Software Design Description Reportcengleblebi.weebly.com/uploads/2/5/6/4/25640587/... · Technology...