ONLINE DOCTOR’S APPOINTMENT SYSTEM

CHAPTER 6
SYSTEM DESIGN
6.1 Software Design Description
The Software Design Description specifies the required information content. It provides an
architectural overview, logical design, detail design, physical design, and application design of the
System. This document presents various stakeholders’ diverse types of abstraction. It aims to
provide the stakeholders with a clear understanding of the system. It must contain all the design
information needed by users. This document user may not have the same level of system
understanding. So, they may need a selected portion of SDD. But it should be collected and
presented in a way that assures completeness.

It describes design decisions, architectural design, and the detailed design needed to implement
the system. Typically, SDD is prepared to support the development of a software item. This
information will farther be used for analysis, planning, implementation, development, and
evaluation of the software system, by identifying and addressing essential design concerns. The
main purpose of SDD is:
• Identify required system resources.
• Describe functional structure, algorithm, and process.
• Can be used to impact the requirement change.
• Need for maintenance activity.

6.2 Traceability
The term Traceability or Requirements Traceability refers to the ability to link product
requirements back to stakeholders' rationales and forward to corresponding design artifacts,
code, and test cases. Traceability supports numerous software engineering activities such as
change impact analysis, compliance verification or trace back of code, requirements validation. It
is usually accomplished in the form of a matrix created for the verification and validation of the
project. In transaction processing software, traceability implies use of a unique piece of data which
can be traced through the entire software flow of all relevant application programs.

Messages and files at any point in the system can then be audited for correctness and
completeness, using the traceability key to find the particular transaction. This is also sometimes
referred to as the transaction footprint.

6.3 Architecture Design Process

The Architecture design process is used for identifying the sub system, making up a system and
the framework for sub-system control and communications architectural design. The output of
this design process is a description of the software architecture.

6.4 System Design

System design is the solution for the creation of a new system. This phase focuses on the detailed
implementation of the feasible system. Its emphasis is on translating design. Specifications to
performance specification. System design has two phases of development. They are logical design
and physical design. During the logical design phase, the analyst describes inputs (sources),
outputs (destinations), databases (data stores) and procedures (data flows) all in a format that
meets the user requirements. The analyst also specifies the needs of the user at a level that
virtually determines the information flow in and out of the system and the data resources. Here
the logical design is done through data flow diagrams and database design. Physical design is
followed by physical design or coding. Physical design produces the working system by defining
the design specifications which specify exactly what the candidate system must do. The
programmers write the necessary programs that accept input from the user perform necessary
processing on accepted data and produce the required report on a hard copy or display it on the
screen.

6.4.1 Data Flow Diagram

Data flow diagrams are highly essential for requirement specification of the system that shows
how data is processed and how data flows through a sequence of processing steps by a system.
The data is transformed at each step before moving on to the next stage. The four basic elements
that are used in the diagram are:
• The round shape rectangular which is used to denote an operation/process and is labeled
with a brief description of the operation.
• The rectangular box, used to denote a data source or sink of information.
• The parallel bars, used to denote a data store or file.
• The arc denotes the flow of information between the other three components.

6.4.1.1 Context Diagram

Here three types of users interact with the system patient, doctor and admin. Patient can request
for appointment. The doctor can see all his appointments. And admin can supervise all the
activities.

Figure 6.1: Context Diagram of the System

6.4.1.2 Level 0 DFD
Level 0 DFD is the expansion of context diagrams. It shows the process and data flow more briefly.
In figure 6.2 it shows level 0 DFD for both doctor and patient.

Figure 6.2: Level 0 DFD of the System

6.4.1.3 Level 1 DFD for Doctor
Level 1 DFD is the expansion of level 0 DFD. In figure 6.3 it shows the level 1 DFD for doctor. It
starts from the “sign in” process. After login it goes to “View Appointment” process.

Figure 6.3: Level 1 for Doctor of the System

6.4.1.4 Level 1 DFD for Patient
In figure 6.4 it shows the level one DFD for patients. It starts with “Sign up” process. After signing
up, then login to account, then viewing the doctor’s information from the data store and then the
appointment.

Figure 6.4: Level 1 DFD for Patient of the System

6.4.2 Use Case Diagram

Use case diagram (UCD) is a methodology used to describe the functionality of a system in a
horizontal way. Each case focuses on describing how to achieve a goal or task. The case is made
up of a set of sequences of interactions between system and users or actor in a particular
environment and related to a particular goal. The user or actor might be a person or something
more abstract, such as an external software system or manual process. The three basic elements
that are used in design diagram are:
• The Actor: Actor is one who is using the web site. May be a person, organization, or
external system that plays a role in one or more interactions with the system. In figure
outside the system boundary person like figure is the actor. In the system it has three
actors. Patient, doctor, and admin. They work outside the system boundary.
• Use Cases: It is what the user wants to do. Describe a sequence of action that provides
something of measurable value to an actor and is drawn as a horizontal ellipse. In figure
 within the system boundary oval shapes are the use cases. There are five use cases for
patients, three use cases for doctors and nine use cases for admin.
• System Boundary Boxes – It is what the scope of system for users. A rectangle is drawn
around the use cases, called the system boundary box, to indicate the scope of the system.
Anything within the box represents the functionality that is in scope and nothing outside
the box is.

Figure 6.5: Use Case Diagram of the System

6.4.3 Activity Diagram

Activity Diagrams are graphical representations of workflows of stepwise components in a system
means show the overall flow of control. The elements of the Activity Diagram are presented
below:
• Initial State -The filled blocked circle is the starting point of the diagram. In figure black
circle is the initial state.
• Final State -The activities flow terminates when the transition line of the last action in the
sequence connects to a “final state” symbol that is the ending point, which is a bull’s-eye.
In figure the circle surrounding a smaller solid circle or encircled block circle is the final
node.
• Action State -An action or an activity is indicated on the activity diagram by a “Capsule”
shape. The text inside indicates the action.
• Transition Fork -A transaction fork has one input and one or more output transactions. It
shows what activity state follows another.
• Transaction Join -A transaction join has more than one input and only one output
transaction. It represents many action states combined into one state.
• Decisions -The diamonds represent the decisions where a set of guard conditions are
defined.
 • Control Flow – Control flow adds a transaction state from one to another. It is represented
by an arrow line. In figure arrow lines represent the control flow.

6.4.3.1 Activity Diagram for Patient

In figure 6.6 shows an activity diagram for patients. The first black circle indicates the initial state.
In the next decision state, it checks whether the user is registered or not. If he is registered, then
go to sign in state. Again, check for username password. If valid then he can access his account.
Then he can search for a doctor and then he can view the doctor’s information and can get
appointments with a doctor. After completing all the activities, he can sign out from his account.
And reach to the final state which is represented by circle surrounding a smaller solid circle.

Figure 6.6: Activity Diagram for Patient of the System

6.4.3.2 Activity Diagram for Doctor

In figure 6.7 it shows an activity diagram for doctors. In initial state it checks for a registered doctor
by sign in. It checks the doctor’s name which was registered by admin. Then he can view his
appointed patient. He also can remove his appointed patient after consulting with the patient.
After finishing all the states, he reaches to the final state by signing out.

Figure 6.7: Activity Diagram for Doctor of the System

6.4.4 Class Diagram
Class Diagram is a type of static structure diagram that describes the structure of a system by
showing the systems classes, their attributes, operations (or methods), and the relationships
among objects. The following points should be remembered while drawing a Class Diagram:
• The name of the class diagram should be meaningful to describe the aspect of the system.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly identified.
• For each class, the minimum number of properties should be specified, as unnecessary
properties will make the diagram complicated.
• Use notes whenever required to describe some aspect of the diagram. At the end of the
drawing, it should be understandable to the developer/coder.
• Finally, before making the definitive version, the diagram should be drawn on plain paper
and reworked as many times as possible to make it correct.

There are some components of Class Diagram as follows:

• Class: A class represents a relevant concept from the domain, a set of persons, objects, or
ideas.
• Attribute: An attribute of a class represents a characteristic of a class that is of interest for
the user.
• Generalization: Generalization is a relationship between two classes. ✔ Association: An
association indicates that objects of one class have a relationship with objects of another
class, in which this connection has a specifically defined meaning.
• Multiplicity: A multiplicity allows for statements about the number of objects that
participate in an association.
• Aggregation: An aggregation is a special case of an association.

6.4.5 Database Normalization

Normalization is the process of organizing the data in the database. Normalization is used to
minimize the redundancy from a relation or set of relations. The normal form is used to reduce
redundancy from the database table.
• 1NF: First normal form (1NF) is a property of a relation in a relational database. A relation
is in first normal form if and only if the domain of each attribute contains only atomic
(indivisible) values, and the value of each attribute contains only a single value from that
domain.
• 2NF: Second normal form (2NF) is a normal form used in database normalization. A
relation is in the second normal form if it fulfills the following two requirements: It is in
the first normal form. It does not have any non-prime attribute that is functionally
dependent on any proper subset of any candidate key to the relation.
• 3NF: The third normal form (3NF) is a normal form used in database normalization. Codd's
definition states that a table is in 3NF if and only if both of the following conditions are
held. The relation R (table) is in second normal form (2NF). Every non-prime attribute of
R is non-transitively dependent on every key of R.
6.4.6 Database Schema
A database schema is the structure that represents the way the database is built. The database
scheme defines how data is stored in the database tables and how the relationship among tables
is associated. There are three types of SQL database relationships:
• one-to-one
• one-to-many
• many-to-many

6.4.7 Entity Relationship Diagram

The ER diagram is principally used to capture the relationships that exist between static data
objects in a problem model or a design model. In particular, the Entity-Relationship Model has
provided an essential foundation for the development of relational models. To design an ER
diagram, it is important to select criteria that have different alternatives.

For this purpose, design considering the following steps:

1. To use an attribute or a set of attributes to represent an object.
2. A real-world concept expresses most accurately an entity set or by a relationship.
3. To use a ternary relationship or a pair of binary relationships among the entities.

In an effective system, data is divided into discrete categories or entities. An entity relationship
(E-R) model is an illustration of various entities and the relationship of various entities and the
relationship between them. The ER model is built during the analysis phase of the system
development life cycle. The ER model separates the information required by the system from the
activities performed within a system. In ERD there are,
• Entities: An object or concept that is identified by the Entities. In figure the rectangle box
indicates entity. There are five entities. They are patient, doctor, schedule, admin,
appointment. An entity may have one or more attributes.
• Attributes are the properties of entities. Attributes are represented by means of eclipses.
Every eclipse represents one attribute and is directly connected to its entity. In figure all
the entities have several attributes. Attributes may be primary key or foreign key. Primary
key is denoted by underline.
• Relationships are represented by diamond shaped. The name of the relationship is written
in the diamond box. All entities participating in relationships are connected to it by a line.
In figure there are three relationships. Relationships may be one-to-one, one-to-many,
many-to-one, and many-to-many. Also, a relationship may be binary, ternary or
quaternary. There is only one ternary relationship in the figure which connects doctor,
patient, and manager.
• Links are the connection between entities and relations.