SOFTWARE

DESIGN
DESCRIPTION
PROBLEM STATEMENT
Prepared by

10/06/2022

Contents
 June 09, 2022
1. Overview 2
1.1 Scope 2
1.2 Purpose 3
1.3 Intended audience 3
1.4 References 3
2. Definitions, Acronyms and Abbreviations 3
3. Conceptual Model for Software Design Descriptions 5
3.1 Software Design in Context 5
3.2 Software Design Descriptions within the Life Cycle 5
3.2.1 Influences on SDD Preparation 5
3.2.2 Influences on Software Life Cycle Products 5
3.2.3 Design Verification and Design Role in Validation 6
4. Design Description Information Content 6
4.1 Introduction 6
4.2 SDD Identification 7
4.3 Design Stakeholders and Their Concerns 7
4.4 Design Views 7
4.5 Design Viewpoints 7
4.6 Design Elements 8
4.7 Design Overlays 9
4.8 Design Rationale 9
4.9 Design Languages 9
5. Design Viewpoints 9
5.1 Introduction 9
5.2 Context viewpoint 9
5.2.1 Design concerns 10
5.2.2 Design Elements 10
5.2.3 Example Languages 12
5.3 Composition Viewpoint 12
5.3.1 Design Concerns 12
5.3.2 Design Elements 13
5.3.3 Example Languages 13
5.4 Logical Viewpoint 13
5.4.1 Design Concerns 13
5.4.2 Design Elements 14
5.4.3 Example Languages 14
5.5 Dependency Viewpoint 14
5.5.1 Design Concerns 15
1
 June 09, 2022
5.5.2 Design elements 15
5.5.3 Example Languages 15
5.6 Information Viewpoint 15
5.7 Patterns Use Viewpoint 15
5.8 Interface Viewpoint 15
5.8.1 Design Concerns 15
5.8.2 Design Elements 16
5.9 Structure Viewpoint 17
5.9.1 Design Concerns 17
5.9.2 Design Elements 17
5.9.3 Example languages 17
5.10 Interaction viewpoint 18
5.10.1 Design Concerns 18
5.10.2 Design Elements 18
5.10.3 Examples Languages 19
5.11 State Dynamics Viewpoint 19
5.11.1 Design Concerns 19
5.11.2 Design elements 20
5.11.3 Example languages 20

2
 June 09, 2022

1. Overview

1.1 Scope
The developed product is a system that implement a web-app that can provide the health
status of a human body according to certain inputs and to suggest some exercises that can improve
the current scenario of His/her Physical Health. Objective of the system is to make access to health
information easier for anybody who is interested. Each design concern of the stakeholders is topic
of at least one design view and these design views are described with corresponding design
elements and modeled with related UML diagrams. The document is prepared in IEEE 1016-2009
standards.

1.2 Purpose
The purpose of this document is to provide a description of the design of the web-app to
allow for software design to proceed with a perceptive of the design that is to be structured and
how the process of it develops. The topics of, general description of design elements and their
interactions, how the system will be structured, data & functional structure are to be further
discussed in order to help producing test cases, and help in maintenance services, and also satisfy
requirements, design details indicated in the SRS document.

1.3 Intended audience

The intended audience of this document is all major stakeholders which include the development
team (TeamZ), the project owner, the project mentor (Mrs. Arsha J K), faculty members of VJCET
and anyone evaluating the project.

1.4 References
[1] IEEE. IEEE Std 1016-2009 IEEE Standard for Information Technology – System Design –
Software Design Descriptions. IEEE Computer Society, 2009
[2] Software Specification Requirements (SRS) Document of Human Body Health Status Software
prepared by TeamZ.
[3] https://www.ycombinator.com
2. Definitions, Acronyms and Abbreviations
All the definitions, acronyms and abbreviations which are used in this document are described in

3
 June 09, 2022
the following table.

Block diagram A diagram showing in schematic form the general arrangement of the
parts or components of a complex system or process.

Class Diagram A type of static structure diagram in UML that describes the structure of a
system by showing the system's classes, their attributes, operations (or
methods), and the relationships among the classes

DDB Distributed Database

HTTPs Hypertext Transfer Protocol Secure

IDE Integrated Development Environment

IEEE Standard International Electric Electronic Engineering Standards 1016-2009

PC Personal Computer

SQL Structured Query Language

SDD Software Design Description

SDK Software Development Kit

SRS Software Requirement Specification

Stakeholders Any person with an interest in the system who is not a developer of the
system.
StarUML Design tool of diagrams

State Transition A type of static structure diagram in UML that describes the transition of
Diagram the system functions
UI User Interface

Use Case A type of static structure diagram in UML that describes user's interaction
Diagram with the system
User Person who wants to use the system

4
 June 09, 2022
User Interface An interface that our system contacts with the user of the system. It gets
all needed information for its running, from user to our system.
XML Extensible Markup Language

3. Conceptual Model for Software Design Descriptions

This section includes basic Human Body Health Status System terms, concepts and context
of SDD in which the documentation is prepared. The purpose of conceptual model is to give a
better understanding of system terminology and software life cycle that the system resides on. The
conceptual model also gives information about stakeholders who will use SDD and how the SDD
will be used.

3.1 Software Design in Context

The Human Body Health Status System will be designed as a web application. The system
will be implemented with HTML, CSS, JS, PHP using Visual Studio Code as IDE using Laravel
framework. The system will try to give the most accurate result in a most applicable, proper and
correct time; so, it can respond to users’ wants correctly and quickly. The speed of Human Body
Health Status system depends on the computational specifications of the search engine, browser,
and the computer.
Our Human Body Health Status System is planned to be an application that run on the web
browser in any personal computers which have access to Internet. The system can be accessible to
all users who have some web browsers installed in their Linux, windows, mac or any other
operating systems.

3.2 Software Design Descriptions within the Life Cycle

This software will be created following IEEE standards. The primary milestones of this
system are requirements analysis, design description analysis, implementation and finally
verification and validation.

3.2.1 Influences on SDD Preparation

The very first influence on software design process is the Human Body Health Status
System SRS document. In SDD, we considered the product perspective, functional/nonfunctional
5
 June 09, 2022
requirements and interface requirements that were included in the SRS. Given specifications and
the possible new requests from the stakeholders will specify the design process of this system.

3.2.2 Influences on Software Life Cycle Products

Firstly, all interfaces should be designed. Before officially launching the system, user
interface should be shown with sample examples to the stakeholders. As a result of this process,
stakeholders can share their ideas and requirements about the Human Body Health Status System.
Finally, the system can be published as fully functioning website.
Furthermore, SDD will guide us all the way through the system. According to this document
or the first phase, some requirements can be added or removed from the software requirements.
Consequently, requirements of the stakeholders can be met more precisely after each sprint of our
development process.

3.2.3 Design Verification and Design Role in Validation

Verification is the process that we will test the Human Body Health Status System whether
it meets a set of design specifications. In this process, we will look the SRS and SDD documents
for correctness of specifications. We will control that whether all functional and nonfunctional
requirements are correctly implemented according to the requirements of SRS and SDD
documents. Furthermore, we will control that whether the design viewpoints of the final Human
Body Health Status System are met in the viewpoints part of the SDD document.
Validation is the process that the stakeholders and developers decide if the Human Body
Health Status System is consistent with the main goal provide the health status of a human body
according to certain inputs and to suggest some exercises that can improve the current scenario of his/her
physical health.

After the complete implementation of system, the testing process will be handled with SDD
influenced test plans and cases.

4. Design Description Information Content

4.1 Introduction
Software design description of the Human Body Health Status System analyzes how the
system will be designed and implemented. This section investigates these according to
6
 June 09, 2022
identification of the SDD, identified design stakeholders and design concerns, related design
viewpoints, design views, overlays, rationale and languages. Furthermore, this section includes
design elements which are design entities, attributes, relationships and constraints.

4.2 SDD Identification

Human Body Health Status System will be released by the end of June 2022 after validation and
verification tests. Prototype of the system will be shown in the middle of June 2022. Modification
and distribution of Human Body Health Status System can only be done by the copyright holder
who is TeamZ because of the exclusive rights property.
Scope, references, context and summary can be found under the section “Overview”.
Glossary can be found under the section “Definitions, Acronyms and Abbreviations”.

4.3 Design Stakeholders and Their Concerns

Stakeholders comprise a developer team which is TeamZ at the Viswajyothi College of
Engineering and Technology Department of Computer Science Engineering members. Mainly
concerns of the stakeholders are accuracy of the information which is provided by the system
because it must be perfect. In addition, this project may be a little difficult to design and develop.

4.4 Design Views

Design views help design stakeholders about focusing on design details from a specific
perspective and meeting relevant requirements. Each identified design concern must be the topic of
at least one design view so that SDD is complete. Each design concern identified in the previous
subsection is the topic of most of the design views in this document; thus, this SDD is completed.
For example, concerns about cost are a topic of composition view. Moreover, concerns about
accuracy of data are a topic of logical view. In this document, context, composition, logical,
dependency, information, patterns use, interface, interaction and state dynamics views will be
explained in section 4.5 as their corresponding viewpoints. For some views, relevant UML
diagrams will be shown in order to clarify.

4.5 Design Viewpoints

This document describes context, composition, logical, dependency, information, patterns
use, interface, structure, and interaction and state dynamics viewpoints.

7
 June 09, 2022
Context Viewpoint: It describes the relationships, dependencies and interactions between the
system and its environment such as users and other interacting stakeholders. Interactions between
the system and its actors are very intense, hence concerns of this viewpoint are important and
suitable for the Human Body Health Status System. It includes a use case, context and block
diagram showing the system boundary.
Composition Viewpoint: It describes how the design subject split up into its components and
which roles these components have. It can be used in estimating cost, staffing and scheduling
duties of a development team. It includes a deployment and component diagram.
Logical Viewpoint: It describes class structures, interactions between them and how they are
designed and implemented. Also, it supports development and reuse of existing logical
components. It includes a class diagram which defines objects and classes, and relationships
between them.
Dependency Viewpoint: It describes the components of the system and dependencies between
these components. It gives information about shared information and order of execution of these
components.
Information Viewpoint: It describes data items, data types and classes, data stores and access
mechanisms. It gives information about data attributes.
Patterns Use Viewpoint: It describes design patterns and usage of design patterns which meet
design ideas of the project.
Interface Viewpoint: It describes the details of external and internal interfaces. It provides
information to the designers, programmers and testers before proceeding with the detailed design
of the system. This also provides designers, programmers and testers to use the system as a random
user.
Interaction Viewpoint: It describes the sequence of actions and how, why, where and at what level
actions occur in the system. It is preferred to use state dynamics views in detail for this project.
State Dynamics Viewpoint: It describes the internal behavior of the system. System dynamics
include modes, states, transitions and reactions to events. It gives information step by step about
the system operation. It includes a state machine diagram which defines conditions, states,
transitions and relationships between them.
4.6 Design Elements
Any item which appears in a design view is named as design elements. It may be one or some of
these subcases; design entity, design relationship, design attribute and design constraints. All
8
 June 09, 2022
design elements are defined with subcases under their corresponding viewpoint in section 5 of the
software design description.

4.7 Design Overlays

Design overlays are usually used to add information to the existing views. This concept will be
explained clearly, when necessary, in the design viewpoints section which is 5.

4.8 Design Rationale

The Object-Oriented approach was chosen while designing because by this way the hardware part
and software part will be combined easily. Software part includes parsing and reading notes and
transmitting data. To design these lots of packages were used. These packages are connected
between each other and they can be controlled separately. Furthermore, for the hardware part a
package was used and there is another package to combine software and hardware parts.

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
This section provides several main design viewpoints of Human Body Health Status
System with their corresponding design concerns and appropriate design languages. Respectively,
context, composition, logical, dependency, information, patterns, interface, structure and
interaction viewpoints are defined in the following subsections. Short descriptions relating a
minimal set of design entities, design relationships, design entity attributes, and design constraints
are provided for each viewpoint.
5.2 Context viewpoint
The context viewpoint of Human Body Health Status software shows the functions
provided by a design subject with reference to an explicit context. The services are the functions,
which describes the relationships, dependencies, and interactions between the system and its
environment like users and other stakeholders.
9
 June 09, 2022
5.2.1 Design concerns
Design concerns consist of services, actors and system boundaries. Human Body Health
Status is formed of a website interface. There are two type of actors who uses the system; people
who access the system regularly (users with an account) and who access it infrequently (guest
Users). Therefore, the constraints vary according to users.
The user uses the Human Body Health Status Software interface to access the calculator
login or signup page. Information flow between the user and the Human Body Health Status
System is provided by the interface. Below diagram shows the system boundary which includes the
relationship between the user and the other major components of the system.

Figure 1: Block Diagram of the Human Body Health Status System

5.2.2 Design Elements

One of the design entities is the actor of the system, user. Stakeholders are other design entities of
the Human Body Health Status System. They consist of a project management and developer team.
Below diagram shows the design relationship which includes provided input and received output
between the user and the other major components of the system.

10
 June 09, 2022

Figure 2: Context Diagram of the Human Body Health Status Software

Figure 3 given below describes system interaction and functionality with the user. There are two
types of users, ones who use all the functionalities related to the system (Regular Users) and those
who access selected functionalities (Temporary Users).

Figure 3: Use Case Diagram of the Human Body Health Status Software
11
 June 09, 2022

5.2.3 Example Languages

The diagrams given in the previous subsections are created by the UML. One of these diagrams is
the block diagram describing interrelationships of a system. Another one is the context diagram
defining the boundary between the system and its environment. The last one of them is the use
case diagram showing user interactions with the system.

5.3 Composition Viewpoint

The purpose of the composition viewpoint of Recommendation System is to define the system as
a composition of its subsystems. The project is formed by 4 main submodules: GUI, Calculator,
Database and Account Manager. Detailed explanation about the relations between these modules
will be explained in coming sections.

5.3.1 Design Concerns

With the help of information in composition viewpoint, system stakeholders and developer team
can plan and control the software product. The design of this project is structured into sub-modules
and components such as interface and other packages. The project is managed by planning,
monitoring and controlling these components. All acquired information about the project provides
estimated cost, staffing, and schedule for the development effort.
Below UML deployment diagram shows run-time (physical) decomposition of the system.

Figure 4: Deployment Diagram of the Human Body Health Status Software

12
 June 09, 2022

5.3.2 Design Elements

The project is formed of interfaces and classes inside packages as design entities. There are three
packages which are User Interface, Calculator and Account Manager which allow the system to be
run as an application. A figure showing the relations between these modules is given below:

Figure 5: Component Diagram of the Human Body Health Status Software

5.3.3 Example Languages

A component diagram showing functional (logical) decomposition of the system and a
deployment diagram showing run-time (physical) decomposition of the system have been given in
the previous sections by using UML modeling language.

5.4 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. For each entity,
there will be a diagram to overview the entity and then a table that name, return type; visibility of
the entity/class diagram is shown in. Also, definitions of each element is provided. After all
elements are explained, the class diagram that shows relationships between the classes is drawn.

5.4.1 Design Concerns

The logical viewpoint is employed to show the development and reuse of abstractions and
their implementations. This means, object-oriented programming simplifies to maintain and
modify existing code while new objects are created. Since identifying object classes is often a
13
 June 09, 2022
difficult part of object-oriented design, during the implementation phase of the project there can be
some changes in object identification.

5.4.2 Design Elements

The project has three packages named User Interface, Calculator and Account Manager. All
packages have different classes. All package connections and their classes can be seen in the
figure:

Figure 6: Class Diagram of the Human Body Health Status Software

5.4.3 Example Languages

A class diagram which describes the structure of a system by showing classes of the system
has been given in the previous sections by using UML modeling language.

5.5 Dependency Viewpoint

The Dependency viewpoint specifies the relationships of interconnection and access among
entities. These relationships include shared information, order of execution, or parameterization of
interfaces.

5.5.1 Design Concerns

Dependency viewpoint helps maintainers to isolate entities causing system failures or
resource bottlenecks. In producing the system integration plan, the system is identified with the
sub-modules and the components which are dependent on each other.

14
 June 09, 2022
5.5.2 Design elements
The product is composed of the user interface and classes inside packages as design
entities. Detailed explanation about the dependency between the entities and the modules are
explained with the component and deployment diagrams in the section 5.3.2.

5.5.3 Example Languages

The component diagram showing functional (logical) decomposition of the system in the
section 5.3.2 and the package diagram depicting the dependencies between the packages in the section
5.9.2 are created by UML.

5.6 Information Viewpoint

This section is not required for our project.

5.7 Patterns Use Viewpoint

This section is not required for our project.

5.8 Interface Viewpoint

In this part of the document, the details of external and internal interfaces will be defined. There
shall be two interfaces in Human Body Health Status System, which are Database Interface and
user interface. Database interface is hidden from users. Clients interact through user interface and
provide necessary information’s for calculation procedures and those information’s are stored in
the database.
.

5.8.1 Design Concerns

Interface viewpoint provides information to the designers, developers and testers before
proceeding with the detailed design of the system. It also informs them about how cooperating
entities will interact. With the ease of each interface descriptions, designers and developers can
know internal and external connections of system to develop it. This contributes ease of
maintenance.

5.8.2 Design Elements

In this subsection, user interface of the home page of the Human Body Health Status System is
shown. In addition, usage of these interfaces is given in details.

15
 June 09, 2022

Figure 7: User Interface of Human Body Health Status System

Figure 7 shows the only interface of the Human Body Health Status System. This interface shows
what a client sees when they first visit the website. Two options were provided at this page; one for
using the basic website features without creating any account (used by temporary users) and the
other for using all available features after creating a valid account with necessary information
(used by regular users). Users can choose between these two options based on their preferences.
Users who selected the first option will be eligible two try out some services provided by the
website so that they can get a small clear-cut understanding of the services provided by the Human
Body Health Status System. The users who selected the second option will be eligible for trying
out all the services and functionalities provided by the Human Body Health Status System without
any restrictions.
All necessary UML component diagrams have been given in the previous sections of this SDD
document.

5.9 Structure Viewpoint

5.9.1 Design Concerns

Structure viewpoint informs user and the developer about the interaction between the packages in
the system.

5.9.2 Design Elements

16
 June 09, 2022

Figure 8: Package Diagram of the Human Body Health Status System

Figure 8 above shows the package diagram of the whole Human Body Health Status System . Users
can use the system via User Interface which connects hardware and software parts of the system.
Developer manages interaction between parts.

Detailed component diagram is given in section 5.3 and class diagram given in section 5.4.
5.9.3 Example languages
UML package diagram showing interaction between the parts of the system and the user
has been given in the previous sections by using UML modeling language.

5.10 Interaction viewpoint

In this section, main functionalities of the system are given by the help of sequence
diagrams. Moreover, it defines strategies for interaction among entities.

5.10.1 Design Concerns

For designers, this section includes evaluating allocation of responsibilities in collaborations
and description of interactions in terms of messages among affected objects in fulfilling required
actions with the help of sequence diagrams.

17
 June 09, 2022
5.10.2 Design Elements
Given sub-sections below, user and system interactions are illustrated.

5.10.2.1 Interactions of Regular Users

Figure 9: Sequence Diagram for Interactions of Regular Users

Above sequence diagram shows the different ways in which a regular user interacts with
the system. They have basically two courses of action: Sign-up or Login. The sequence of steps
and related actions in both these alternatives are shown in the sequence diagram.
5.10.2.2 Interactions of Temporary Users

18
 June 09, 2022

Figure 10: Sequence Diagram for Interactions of Temporary Users

The sequence diagram above shows the temporary user and system interaction. Unlike the regular
users, temporary users are not required to create an account so it is convenient for those who just
need to do some calculations only (Note: Calculations and its range are limited for temporary
users).
5.10.3 Examples Languages
Sequence diagrams which show how processes operate with one another and in what order
has been given in the previous section by using UML modeling language.

5.11 State Dynamics Viewpoint

In this section, system behavior and states of the system are given via the state transition
diagram.

5.11.1 Design Concerns

Designers, developers and testers are informed about the dynamic view of the system
which includes modes, states, transitions and reactions to events.

5.11.2 Design elements

The different states of Human Body Health Status Software and how they interact with
each other are specified in the figure given below:

19
 June 09, 2022

Figure 12: State Machine Diagram of the Human Body Health Status System

5.11.3 Example languages

State machine diagram given in the previous section which shows the internal behavior of
the system by state transitions is created by the UML.

20