California State University, Sacramento (CSUS)

Computer Science Department

CSC 230
Software System Engineering

Spring 2015
Instructor: Dr. Doan Nguyen

Final Project Report

Quick Response Reader

iOS Application

Submitted by:
Sarika Adik (Contribution 50%)
Yogesh Isawe (Contribution 50%)
 TABLE OF CONTENTS

Chapter Page No.

Preface……………………………………………………………………………...1

List of Tables……………………………………………………………………… 4

List of Figures……………………………………………………………………... 5

1. INTRODUCTION………………………………………………..……………..….6

1.1 Problem………………………………………………………………………. 6

1.2 Solution………………………..…………………………………………….. 6

1.3 Objectives………………………..…………………………………………….6

2. TIMELINE FOLLOWED……………………………………………………….......7

3. INTERFERANCE Requirements…………………………………………………...9

3.1 User Interface...…………..…………………………………………………….9

3.2 Hardware Interface ………………...………..………………………………....9

3.3 Software Interface……….…………..…………………………………………9

3.4 Communication Interface…….………..………………………………………9

4. REVISED SYSTEM REQUIREMENTS……….………………………………….10

4.1 Glossary…………………..…………………………………………………...10

4.2 Revised Functional Requirements…………..………………………………...12

4.3 Revised Non-Functional Requirements…………..…………………………...17

5. DIAGRAMS…………………..……………………………………………..…….18

5.1 System Diagram……………………………………………………….……..18

5.2 Software Component Diagram…………………...………………..…...……..19

5.3 GUI Diagrams……………………………………...…………………..…......20

5.3.1 UI 1 - QR Reader……………..……………………………….………......20

  2  
 5.3.2 UI 2 – QR Records…………..………………………………..………........21

5.3.3 UI 3 – Edit Account…..……………………………………..………...…...22

5.4 Class diagram………………………………………………………………….24

5.4.1 Admin Class..………………………………………………………...…...….25

5.5 ERD diagram………………………………………………………………….27

5.5.1 Frontend ERD………………………………………………………...…...…27

5.5.2 Backend ERD………………………………………………………...…...…29

5.6 Use Case Diagrams…………………………………………..…………...……31

5.6.1 UC1 – Login………………………………………………………...…...…..31

5.6.2 UC2 – Edit Account………………………………………………...…...…...32

5.6.3 UC3 – QR Code Handling……………………….…………………………..33

5.6.4 UC4 – QR Records Handling………………………………………….…….34

5.7 Sequence Diagram……………………………………………………………..35

5.7.1 SD1 – overall working of the system………………………………………...35

5.7.2 SD2 – Check working of camera………………………………………...…..36

5.7.3 SD3 – Search for a record in the device……………………………………..37

6. ACTORS AND STAKEHOLDERS…………………………………………………..38

7. TRACEABILITY MATRIX…………………………………………………………39

8. PROGRAMMING/DEVELOPMENT TOOLS……………………………………...40

9. RESTRICTIONS AND LIMITATIONS…………...………………………………...41

9.1 Restrictions…………………………………………………………………….41

9.2 Limitations…………………………………………………………………….41

  3  
 LIST OF TABLES

Table No. Table Name Page No.

1. Glossary……………………………………………………………………………11

2. Functional Requirements………………………………………………………..…16

3. Non-Functional Requirements.………………………………………………….....17

4. Traceability Matrix……………………………….………………………………...38

  4  
 LIST OF FIGURES

Figures No. Page No.

1. System Diagram……………………………………………………………………...18

2. Software Component Diagram……………………………………………………....19

3. QR Reader UI………………………………………………………………………..20

4. QR Records UI…………………………………………………………………...….21

5. Edit Account UI……………………………….………….………………………….22

6. Class Diagram………………………………………………………………………..24

7. Admin Class……...………………………………………………………………….26

8. Frontend ERD………………………………………………………………………..27

9. Backend ERD………………………………………………………………………..29

10. Login Use Case……………………………….………….…………………………. 31

11. Edit Account Use Case.……………………………….………………………..……32

12. QR Code Handling Use Case………………………………………………………..33

13. QR Records Handling Use Case …………………………………………………….34

14. Check Camera Working Sequence Diagram………………………………………...35

15. Search Records Sequence Diagram………………………………………………….36

16. Entire System Working Sequence Diagram……...………………………………….37

  5  
 1. CUSTOMER STATEMENT OF REQUIREMENTS

1.1 Problem
Barcodes and quick response codes are machine-readable label that contains information.
Used for ‘automatic identification and data capture’ (AIDC) a methods that automatically
identifies objects, collecting data about them, and entering that data directly into
computer systems. These codes have become commercially successful and are widely
used to automate systems. QR code has gained popularity in consumer space in recent
years as a way to encode URL of a landing page or marketing information. The use of
QR code has been on the rise it appears in magazines, newspapers, advertisement,
billboards and even name cards. Apple portable devices such as iPhone, iPod and iPad
etc. iOS devices don’t have QR code scanner application. The QR Code system has
become popular due to its fast readability and greater storage capacity compared to
standard barcodes. Applications include product tracking, item identification, time
tracking, document management, general marketing, and much more.

1.2 Solution
Quick response code is type of matrix barcode. A QR code uses four standardized
encoding modes (numeric, alphanumeric, byte / binary, and kanji) to efficiently store
data; extensions may also be used. Unlike the basic barcode QR code contains
information in both horizontal and vertical direction, this contributes to its capability of
storing larger amount of data in both numeric and letterform.
As a solution to the problem discussed is an iOS application that can be deployed on the
portable Apple devices like iPhone, iPod and iPod with built in camera. Using camera on
these devices the QR code can be scanned and the application then decodes the
information stored and provides it to the user on the screen.
Code scanning in iOS including QR code for this application is based on video capturing.
AVFoundation framework is one of several frameworks that can be used to play and
create time-based audiovisual media. It provides an Objective-C interface to work on a
detailed level with time-based audiovisual data. The features like examine, create, edit, or
re-encode media files and also to get input streams from devices and manipulate video
during realtime capture and playback are used to design the solution.

1.3 Objectives
Main objective is to design an iOS application for Apple portable devices with camera.
The application can scan the QR code by simply pointing the camera towards the code.
The application then decodes the QR code and displays the information stored to the user.

  6  
 2. TIMELINE FOLLOWED

Weeks 1-2: Inception Phase- For initial full weeks we did thorough research on the idea
for the project. To come up with proposing the development of some software which was
new to most of the people and also which belonged to our domain of development
expertise. At the end of second week we settled on Quick Response code reader
development topic.
Week 3: Elicitation Phase- coming up with a problem statement as to QR reader for
which platform? Using which techniques? And doing the requirement analysis for QR
Reader.
Week 4: Learning Phase- Both the team mates have knowledge of objective C but for
the implementation of this project advanced knowledge of the language was needed so
we gave one week for reviewing and refreshing our knowledge.
Weeks 5: Specification Phase- We Finalized the specifications of our system as in it’s
Database requirements, memory requirements, developing environment and developing
platform finalizing. Using SQLite database was finalized, iOS environment and xcode
IDE for development environment.
Week 6: Negotiation Phase- In this the previously analyzed and specified hard and fast
criterias were negotiated a little amongst ourselves so as to keep project in doable range
and avoid lagging behind the submission checkpoints given by professor.
Week 7: Elaboration Phase- Design and architecture methodology was finalized. We
finalized to use Extreme Programming methodology and MVC architecture for our
system. System requirements, which were analyzed in the elicitation phase, were further
elaborated using ERD diagrams, Class diagrams and Use case diagrams.
Weeks 8: Sub structure layout- modules to be used in the Application were finalized.
The parameters for the connection between modules were formulated and flow as
designed by use case diagrams was planned and fixed.
Week 9: User interface design- UI plays an important role in making customers buy our
product so we made sure we spent proper amount of time and efforts on UI design. At the
end of this week screens design were finalized and we started working on interface side
by side to our main coding of the App.
Week 10: Service tier design and implementation- Here in our App we have used 4-tier
architecture. User tier, Application tier, SQLite tier and database tier are 4 tiers we have
allowed. Connectivity among all these tiers was done in this week
Week 11: System implementation- when all the data and implementation method was
finalized, we started developing individual modules in this week. We have used in total 3
modules. We did unit testing of these modules as soon as they were coded

  7  
Week 12: Integration Phase- Integration of all the individual modules was done in this
phase. As all the requirements were clear integration was easy and testing of whole
system was done for different values and surfaces
Week 13: Tried to figure out limitations of our system and came up with methods to
rectify them. But since the software is already ready there is not much to rectify now. But
that e will include I the documentation part and include in the future scope of the project.
Week 14: Further more testing was done here and report making was undertaken.

  8  
 3. INTERFACE REQUIREMENTS
3.1 User Interface

The product will be very intuitive to the average user. The User Interface of our
App will have many similarities to the other programs that the common users are familiar
with using on iOS. This App will use maximum user interface than any other interface for
it’s normal working.

3.2 Hardware Interface

The App will not need any hardware interface for it’s functioning other that the
device which has iOS and on which the valid user has downloaded the App. No other
external hardware device or component has to be connected to the iPhone, on which the
Quick Response Reader has to work.

3.3 Software Interface

The App will have interfacing with the Operating System of the device, which is
the main software interface of the App. It also need interface with the software routine
handler which takes care of the working of the camera on the device.

3.4 Communication Interface

The device will be connected to the internet, but the product will not need internet
for it’s full functioning. Main part of the App will be converting the captured image to
the URL which has a fixed framework for processing, but that too doesn’t need internet
or any other communication with external world once it is installed and is functioning on
the device. Although, Communication Interface will play an important role in the
updating the software of the App once it’s new versions are available, but that part is
beyond the scope of this project. So overall, there is no need of communication interface
once the App is downloaded.

  9  
 4. REVISED SYSTEM REQUIREMENTS

The systems functional and non-functional are derived from the solution required for the
problem. Identifiers such as FR-# and NFR-# are used for distinguishing functional and
non-functional requirements respectively. A priority weightage is assigned on the scale of
1-5.

4.1 Glossary:
(DEFINITIONS, ACRONYMS, AND ABBREVIATIONS)

  10  
 Table 1: Glossary

  11  
4.2 Functional Requirements

Note: The columns which have value ‘—‘ below means input, processing and output are
not applicable to that functional requirement, which means those values are device
specific, user cannot give input to set or choose any value for certain functionality to
occur specifically.

  12  
   13  
   14  
   15  
 Table 2: Functional Requirements

  16  
4.3 Non-Functional Requirements

Table 3:Non-Functional Requirements

  17  
 5. Diagrams

5.1 System Diagram:

This diagram gives the diagrammatic view of the different systems which interface
with each other so that the Application works fine. This diagram gives different types of
interfaces needed for the working of the Software as discussed in the chapter 2 above.

Fig1: System diagram

This diagram also gives the various interfacing functionalities that are performed by
different systems involved.

  18  
5.2 Software Component Diagram:

This diagram gives the schematic view of all the software components, which work
together for the working of the Quick Response Reader App for the iOS.

Fig2: Software Component Diagram

User with the iOS device opens the application and the camera on devices turns on,
user can point and shoot the QR code similar to taking image. The application detects the
code and sends the captured code to the AVFoundation Framework for processing. The
decoding of this captured code takes place in processing unit. Then the decoded
information from the code is displayed to the user.

  19  
5.3 GUI Diagrams:

5.3.1 UI1: QR Reader

This is the main page after the user has logged in after entering the password. Using
this user interface actor of the system can select one of the 5 options to proceed with the
processing of the system.

Fig 3: QR Reader UI

1. QR Code : The processes related to scanning 2-dimensional bar

code are done under this tab.
2. Edit Account : The account details which are entered while downloading the
App can be changed or deleted from this tab.
3. QR Records : Each individual record contains the URL for the image captured.
4. Check Camera : This functionality is added just to be sure that important
component of working of this App which is camera of the device is full
functional.
5. Quit Application : to exit from the Application back to the device.

  20  
5.3.2 UI2: QR Records

Fig 4: QR Records UI

This tab opens on the screen when actor of the system press QR Records on the main
screen. This tab contents various functionalities for records like following:
1. Search : Search for particular record in the databse memory of the Application.
2. Open :Once the record is found this button will open the record and actor
can see the encoded code for the captured 2D barcode.
3. Edit : Renaming the record, changing the location of the saved URL, sorting
the records based on the frequency of the usage in folders which are accesible
handy.
4. Delete :This option will delete the record from the database permanently.
5. Back : This will take the user back to the main page.

  21  
5.3.3 UI3: Edit Account

Fig 5: Edit account UI

This tab is made taking into consideration that each App has it’s system specific
account details which are private to the individual. The account of the Application
contains tabs for performing operations based on security or organisational needs. User is
many times picky about location being handy and accessible in App memory and staying
organised against the memory overhead and performance. The Edit Account tab contains
operations like :

1. Check for update : the current version of the application is 1.0 and since it will be
freely available on the App store and our project team is the only investor in the

  22  
 App update of it is not projected to come anytime sooner now. But user can keep
checking for the update once it is released.
2. Memory Details : If actor wants to allocate more memory to the App then allocated
while installing on the device then this editing can be done from this tab.
3. Payment info : The payment info is taken from the external user as one of the
compulsory inputs while setting up the account. Although the App is free initially
there is possibility of it getting upgraded and the upgraded version will have a
yearly maintenance fees.
4. Change Password : Just like any account it is advisable to change the password of
this account every 6 months at least since the barcode that are scanned may be
very confidential and you do not want to risk their integrity in any way.
5. Back : Just like last UI back button here also is meant to take the user to
the main screen of the App.

  23  
5.4 Class Diagram for the system:

Fig 6: Class Diagram

  24  
Explanation:

The class diagram figure # shows the basic functionalities that Quick Response Code
Reader application for iOS provides such as starting new session for decoding the QR
code, managing the account, accessing the records and checking status of the camera
application.
Classes for these functionalities with the attributes and methods/functionality performed
by these classes are also shown in the diagram.
‘Manage account’ class has attributes like user_id, user_name, user_password and it can
perform actions/functionalities like create new account, edit existing account information
and delete the existing account.
Class ‘manage records’ have attributes like record_id, record_name and it can perform
actions/functionalities like search the record using record name or record id or record
creation date, it also consist of methods to edit the record information and to delete a
particular record.
‘Decode’ class is the main class of the system that has attributes like record_id,
record_name and it can perform actions/methods to create new session of
recording/capturing the QR code and decode the recorded code information.
Class ‘check functionality’ performs system wide check to find out the status of camera
functionality and memory availability. It performs hardware check, software check and
database check and it has attributes like request_id to perform system check.
From the figure # we can see that class ‘iOS system’ instantiates the database, Video
system, AVFoundation and Hardware port for the application. It provides application
access to the systems functionalities such as access to root, access to database and access
to input/output ports.

5.4.1 Admin Class

Explanation:

Admin class features are very important and have to be noted specifically in any project
documentation because the whole project revolves around the use cases of this one class
and it’s different attributes act as the main strings to manipulate, update and delete
throughout the working of the App. Here admin class in the external user, who is the iOS
user who uses this App. It’s main characteristics like username and password set by him
act as login credentials of the App. All it’s different functionalities specified above are
performed on all the other entities in the software like camer of the device, SQLite
database, App store account, QR Reader App, etc. Thus, admin class and it’s
functionalities play important role in making App work as required.

  25  
 Fig 7: Admin Class

  26  
5.5 ERD Diagrams:

5.5.1 Frontend ERD

Fig 8: Frontend ERD

Explanation:

Frontend ERD shows the working of the App as external sees it. He has no idea of
background working, all the modules relevant to user interface are included in the front
end ERD. All these modules consists of
1. iPhone user: user is using the system. While showing the working of the system
he will include himself as the important part of the system. All the functionalities
to be performed by the user are included in this entity.
2. QR Reader App: one user has access to only one App so the cardinality of the
App is 1:1.
3. Camera: iPhone user captures image using camera of the device. One user can
have access to 1 or many cameras, thus cardinality is 1:n.

  27  
 4. AVFoundation Framework: this module has connection to camera and QR
Reader. And the output fro this framework goes to the database of the device.
5. Database: the database component is divided into 2 main parts. One is database
for App named Database_SQLite1 and user_database2. SQLite_Database stores
URL generated from the AVFoundation Framework. User_database stores user
information like login credentials and payment information. But for frontend
knowing that database entity is used is enough. Details about it are explained in
the backend ERD.
6. Hardware ports: every device has hardware ports which are doin the functionality
of streaming output and accepting input.

  28  
5.5.2 Backend ERD

Fig 9: Backend ERD

Explanation:

1. iPhone user: user is using the system. While showing the working of the system he
will include himself as the important part of the system. All the functionalities to be
performed by the user are included in this entity.

2. QR Reader App: one user has access to only one App so the cardinality of the App is
1:1.

3. Database1_SQLite: this database is provided input by Stop_function entity and QR

Reader App. And it outputs data using hardware ports. 1 SQLite database outputs
using 0 or more ports, thus cardinality is 1:0…n.

4. Stop_func: This function stops accepting input from camera once the image for
processing is captured properly. Input to this function is provided by stop button on

  29  
 the main screen of the App by user. Output fro this entity goes to AVFoundation
Framework for the processing of captured image.

5. User_database2: This has all the details about the user like login credentials and
payment information. Link to validating App store username and password of that
user

6. Hardware_port: there are several hardware ports streaming output from database
when user requests fetch operation.

  30  
5.6 Use Case Diagrams:

5.6.1 UC1: Login

Fig 10: UC1: Login

This Use Case diagram shows the working of the Login scenario of the External user. For
Login Use Case three functionalities are used mainly and these 3 functionalities use 2
more extended functionalities
1. Enter Username : User is prompted to enter his unique username.
2. Enter Password : User is asked to enter his unique passowrd.
3. Validate combination of Username and Password : System database is checked
to find and verify if the combination of entered username and password are valid.
Forgot Username/Password : Here password/Username recovery module is called so that
user can be verified and he is given chance to log in to the system using new password
that he selects.

  31  
5.6.2 UC2: Edit Account

Fig 11: UC2: Edit Account UC

External user can check for version update of the software, check and change memory
details according to his changed needs, Add another card for payment or edit existing
payment details. Check for update functionality includes another functionality called
Login. It means, The upgraded version is available only for the valid user of the devise,
any guest user who attempts to upgrade the software will fail in the attempt. Same applies
to the Change username/password scenario, validate user functionality is included in the
existing functionality. While Adding/editing payment info sometime need bank details
like routing number, Branch code, etc. so that functionality is extended in that case.

  32  
5.6.3 UC3: QR Code Handling

Fig 12: QR Code Handling UC

This Use Case handles the main functionality of the App for which the App is built and
named after. Here user can capture the image of the 2D barcode, display the info of the
captured image. The URL that is decoded from the captured image can be saved to the
desired memory location.

  33  
5.6.4 UC4: QR Records Handling

Fig 13: QR Records Handling UC

Description of UC 4:

This use case handles functionalities related to database of the Application.

View records presents all available records to the user.
Search for particular record can be performed using the name of the record which is the
name given to the record when it is saved after capturing and second method is searching
using the date of creation of the record in the database.
A scenario showing the searching process of record using date of creation is shown in
SD2.
Once the record is found it can be opened to see all it’s details using open record tab. And
edit record will help in changing the location of the record or renaming it.

  34  
5.7 Sequence Diagrams:

5.7.1 SD1: Checking working of the camera of the device

Fig 14: check camera working SD

This Sequence Diagram provides another scenario where user chooses the option of
checking the working of the camera. First system checks with the device software
whether the software part of camera is working fine. Secondly the functioning of
hardware portion of camera is checked with device hardware. Once it says the working is
fine then the system checks memory. It is checked whether media coming from camera
has enough memory on the App account.

  35  
5.7.2 SD2: Search for a record in the application memory

Fig 15: Search record SD

This sequence diagram shows the scenario where External User is searches for the record
in the database using the date of creation of the record. Using sequence diagram the
timing of occurrence of each individual command is also visible. User gives the input
date, which is the creation date of the record which he is looking for. System lookup the
memory and give all the records, which were created on the day user, specified. From
these records, which are presented, user selects the one which he was looking for.
Once the record is found user can edit or delete it.

  36  
5.7.3 SD3: working of all the tiers of the entire system

Fig 16: System Working

Explanation:
This sequence diagram shows the working of all the tires of the system to make whole
system perform as per user requirement. Internal working of each model is not shown
here. Performance of which needs the user to go to which entity is hown by this scenario
of whole system working.

  37  
 6. ACTORS AND STAKEHOLDERS OF THE SYSTEM

The iOS user is the user of the application and therefore the only actor of our system.

Characteristics of the Actor:

1. The user must have knowledge of handling iOS in general, iPhone in particular.
2. User must have iCloud account to download the application.
3. User must know how to download applications from iOS App Store.
4. User must be able to follow the instructions provided.
5. User must know which functionality to look for under which tab from the naming
conventions of tabs.
6. User must be comfortable using iPhone functionalities like rear-camera, password
recovery, operations of media gallery.

For this system of the software stakeholder will be the ones who have invested in the
development of this Application which is our team of two members, Sarika Adik and
Yogesh Isawe. Once we upload the App on the AppStore and if reviews are good and if
lots of people are happy to use it and if it seem that people are even ready to pay for using
our QR Reader Application then Apple might put it’s stakes on the App and will be
another stakeholder.
But as of now we are the investors and stakeholders of the App.

  38  
 7. Traceability Matrix

The traceability matrix allows particular use case to trace back to its corresponding
requirement either functional or nonfunctional. Thus it provides the information about
which use case satisfies which functional or non-functional requirement. The total
weightage provides the information about the importance of each use case. It’s calculated
by summing up the weightages of the requirements applicable for that particular use case.

Table 3: Traceability Matrix

  39  
 8. PROGRAMMING/DEVELOPMENT TOOLS

Operating System used: iOS, version 10.9.5

As the App is only for iOS devices it’s development operating system also has to be iOS
so as to make it’s debugging and complitation easier and testing more effortless to the
user.

Model name: MacBook Pro 11,1

Processor: 2.6 GHz Intel Core i5

Processor speed: 2.6 GHz

RAM: 8 GB, 1600 MHz DDR3

IDE: Xcode

We have used xcode of all the IDEs present because it write code using a professional
editor with advanced code completion, code folding, syntax highlighting, and message
bubbles that display warning, errors, and other context-sensitive information inline with
the code. With all these features development of project, which is done in stages like our
QR Reader can be kept well organized. We have perfomed different testing
methodologies like unit and system testing and for this some environment supporting
coding parallel with testing was needed and Xcode was the best option for this
requirement. It made development process easier and well organized.
It has interface builder built in because of which design and test of our interface without
writing a line of code, prototype in minutes, then graphically connect the interface to the
source within the Xcode editor was executable.
With the iOS SDK, Xcode can build, install, run, and debug Cocoa Touch apps in a Mac-
based iOS Simulator for a streamlined development workflow. Since we do not have
developers certificate we could not deploy our App on App store to actually download
and install in as we recommend any external user to do, so use of simulator was hard and
fast for our project. Xcode also provided this requirement of our team.

  40  
 9. RESTRICTIONS AND LIMITATIONS

This chapter is based on the results of the testing process executed on our App. Testing
proves the system is working and that all the requirments which were specified by SRS
are met in the actual software that is developed. For our QR Reader software one cannot
specify the test sets based on numeric input as it is done normally to any software,
because to our software the input is in the form of image.

8.1 Restrictions:

Our system is not the one which accepts universal system it has restriction on the
conditions in which it wont operate as required or input which it wont process. This
aspect of the App can also be noted from the functional requirements of the software that
were specified in SRS.
The restrictions are as follows:

1. Works only on devices having iOS.

2. Works only on the devices having camera attached to it
3. Works only with the system having free memory at least 30 MB.
4. Works with the device whose camera captures images with resolution between
1600 X 1200 pixels to 3264 X 2448 pixels.
5. Device must have touch screen display.
6. Device’s display must be multi touch as we need to give multi touch to the screen
while capturing QR code image.
7. User must have valid App store account.

8.2 Limitations:

This aspect of the App notes the limitations in the working of the App. After the
development of the App there are some glitches remaining which turns out to be the
limitations of the App.
The limitations of our software system are as follows:

1. It is not as much efficient in minute resolution capturing as much is needed to

capture the image on wooden surface. All the other surfaces like glass, paper,
plastic and fiber work fine just not wooden.
2. For proper working of our App the device must have battery only as low as 10%.
We had predicted that it will work for device battery as low as 2%.
3. Overwriting of database after it is full is not possible yet. So when databse is full
user manually has to go to the memory and delete previously stored URLs and
create space for new incoming URLs from AV Framework.
4. Main feature of the App is that it is an iPhone App and this very exciting feature
is it’s limitation itself. It’s platform specific.

  41