AN ANALYSIS AND DESIGN OF SOFTWARE VALIDATION SCHEME USING SERVICE ORIENTED ARCHITECTURE

BAKTAVATCHALAM.G (08MW03)

MASTER OF ENGINEERING Branch: SOFTWARE ENGINEERING
of Anna University

November 2008

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
PSG COLLEGE OF TECHNOLOGY
(Autonomous Institution)

COIMBATORE – 641 004

Contents

CONTENTS

CHAPTER
Acknowledgement Synopsis List of Figures 1. INTRODUCTION 1.1. 1.2. 1.3. 1.4. 2. 3. 2.1. 3.1 3.2 3.3 4. 4.1 4.2 4.3 4.4 4.5 5. 5.1 5.2 6. 6.1 6.2 6.3 7. Problem Definition Objective of the Project Significance of the Project Outline of the Project Proposed System Requirement Analysis Feasibility Study Technology Overview Use case Diagram Sequence Diagram Collaboration Diagram Activity Diagram State chart Diagram Development Implementation Unit Testing Integration Testing Sample Test Cases

Page No.
(i) (ii) (iii) 1 1 1 1 2 3 3 5 5 5 6 8 8 9 10 11 12 13 13 15 16 16 18 19 20 20

SYSTEM STUDY SYSTEM ANALYSIS

SYSTEM DESIGN

SYSTEM IMPLEMENTATION

TESTING

SNAPSHOT 7.1 The GUI for sid input

iii

Contents

7.2 7.3 7.4

Accepted Software SQA Details Update Testing a query

21 22 25 26 27 28

CONCLUSION FUTURE ENHANCEMENTS BIBLIOGRAPHY

iv

Synopsis

SYNOPSIS
In this project, we do analysis and design of how the software validation is done according to the given specifications. Here we store all the Standard Software Specifications into some Database. Whenever the software Development Team finished their development work, that software specifications are given to the Analyst. The Analyst then gets Standard Specifications from Database as per that Software Business & Problem Domain. Then he will do the validation of the Software Specifications using Standard Specifications. If the developed Software Specifications meet the Standard Specifications then that Software is accepted otherwise it will sent to Development Team for ReDesign. Some of the Specifications includes Software Quality Metrics like CC, LOC, FPA, Bugs Per LOC, Code Coverage, Cohesion, Coupling, … we can use any of these or all of these.

ii

Future Enhancements

FUTURE ENHANCEMENTS
Currently, in the system developed with some minimal number of Quality Attributes for the comparison, in future it comprises all the Attributes are included to give the Software Quality Assurance.

27

List of Figures

LIST OF FIGURES

FIGURE NO Fig: 2.1 Fig: 4.1 Fig: 4.2 Fig:4.3 Fig:4.4 Fig 4.5

LIST OF FIGURES System Architecture Use case diagram Sequence diagram Collaboration diagram Activity diagram State chart diagram

PAGE NO. 4 8 9 10 11 12

iii

Acknowledgement

ACKNOWLEDGEMENT
I wish to express our sincere gratitude to our respected Principal Dr. R.
Rudramoorthy for having given me the opportunity to undertake our project.

I also wish to express my sincere thanks to Dr. S. N. Sivanandam, Professor and Head of the Department of Computer Science and Engineering, for his encouragement and support that he extends towards the project work. I extend my sincere thanks to our internal guide, Ms.Uma Maheswari, Lecturer, Department of Computer Science and Engineering, for her guidance and help rendered for the successful completion of the project. Finally, I would like to thank all my friends without whom this project work would not have been completed successfully.

i

Introduction

Chapter 1

CHAPTER 1
INTRODUCTION
This chapter provides a brief overview of the Software Quality Assurance System, objectives and significance of the project and an outline of the report.

1.1 PROBLEM DEFINITION
The Software Quality Assurance System validates the given software quality attributes values and compare all with Standard quality attributes which are in Database. So we conclude the developed software is had enough quality using this system.

1.2 OBJECTIVE OF THE PROJECT
Most of the users (in the project the Analyst) are interested in the user friendly and easy working with the application. Also this system automatically gives the status about the given software quality attributes. According to this system output the user may choose the appropriate actions for that software.

1.3 SIGNIFICANCE OF THE PROJECT
With the enormous growth in Software validation, the Software is validated using the given software quality attributes values and compare all with Standard quality attributes which are in Database.

1

Introduction

Chapter 1

1.4 OUTLINE OF THE PROJECT
The rest of the report is structures as follows. Chapter 2 provides a detailed study of the existing system and the basic ideas of the proposed system. Chapter 3 discusses the requirements for the development of the system and an analysis on the feasibility of the system. Chapter 4 presents the overall design of the system. Chapter 5 discusses the implementation details. Chapter 6 explains various testing procedures conducted on the system. Chapter 7 contains the snapshot of various forms in our system. The last section summarizes the project.

2

System Study

Chapter 2

CHAPTER 2
SYSTEM STUDY
This chapter elucidates the existing system and a brief description of the proposed system.

2.1 PROPOSED SYSTEM
In our system we do analysis and design of how the software validation is done according to the given specifications. Here we store all the Standard Software Specifications into some Database. Whenever the software Development Team finished their development work, that software specifications are given to the Analyst. The Analyst then gets Standard Specifications from Database as per that Software Business & Problem Domain. Then he will do the validation of the Software Specifications using Standard Specifications. If the developed Software Specifications meet the Standard Specifications then that Software is accepted otherwise it will sent to Development Team for Re-Design. Some of the Specifications includes Software Quality Metrics like CC, LOC, FPA, Bugs Per LOC, Code Coverage, Cohesion, Coupling, … we can use any of these or all of these.

Figure 2.1 Compare Quality Attributes

Database

SQA System

Display Results

Standard Specifications

Developed Software Specifications 3

System Analysis

Chapter 3

CHAPTER 3
SYSTEM ANALYSIS
This section describes the hardware and software specifications for the development of the system and an analysis on the feasibility of the system.

3.1 REQUIREMENT ANALYSIS 3.1.1 Software Requirements
After experimenting with various commercial software’s and analyzing the Pros and Cons of the software, the following are chosen.
• • •

Operating System – Platform Independent BPM developer – Cordys Studio Server – Microsoft SQL Server Group ( Enterprise Edition)

3.1.2 Hardware Requirements
The Hardware requirements of the proposed system are as follows:
• • •

Pentium-III machine & above RAM-256 MB Hard Disk with a Capacity of 10 GB

3.2 FEASIBILITY ANALYSIS
Feasibility deals with step-by-step analysis of the system. Analysis showed that this project was feasible in all respects. Three kinds of feasibility factors are considered:
• • •

Economic Feasibility Technical Feasibility Operational Feasibility

5

System Analysis

Chapter 3

3.2.1 Economic Feasibility
The system is developed only using those softwares that are very well used in the market, so there is no need for installation of new softwares. Hence, the cost incurred towards this project is negligible

3.2.2 Technical Feasibility 3.2.2.1 Maintaining
The main aim of our project is to maintain a book shop management database system which could help a commercial user in his/her day to day business activities.

3.2.2 Operational Feasibility
The functions needed to be performed by the system are all valid and without any conflicts. All functions and constraints specified in the requirements are completely operational. The requirements stated are realistically testable. The requirements are adaptable to changes with out any large-scale effects on other system requirements. The system is capable of accommodating future requirements if they arise.

3.3 TECHNOLOGY OVERVIEW
3.3.1 CORDYS STUDIO The Business Process Management (BPM) is one of the main components of the Cordys Business Operations Platform. Successful businesses need to be built-tochange. However, many organizations are hindered by IT landscapes that are built-tolast. Cordys closes this gap through a powerful, next generation BPM product that enables organizations to change in real-time. Cordys Business Process Management (BPM) puts business in direct control of their processes, resulting in: • • • • Near zero lag time between an executive decision making and implementation Faster response to rapidly changing business conditions Continuous process improvement for higher efficiency and effectiveness Low risk leave-and-layer approach that repurposes existing applications and systems

6

System Analysis

Chapter 3

Cordys BPM embraces the Middle-Out design paradigm where business and IT collaboratively define the backbone of a solution: the business process Cordys BPM takes advantage of some of the latest internet innovations and standards. The result is a 100% browser-based process suite with a graphical and highly responsive user interface. In addition, Cordys BPM offers enterprise-grade scalability, reliability, security and standards support. 3.3.2 SQL Server Group Microsoft SQL Server is a relational database management system (RDBMS) produced by Microsoft. Its primary query languages are MS-SQL and T-SQL. SQL Server Enterprise Edition is the full-featured version of SQL Server, including both the core database engine and add-on services, while including a range of tools for creating and managing a SQL Server cluster

7

System Design

Chapter 4

CHAPTER 4
SYSTEM DESIGN
This chapter describes the functional decomposition of the system and illustrates the movement of data between external entities, the processes and the data stores within the system, with the help of UML diagrams. 4.1 USE CASE DIAGRAM

Software Standards Software Development Team Database

Software Documentation Re-Design Standard Specifications

Decision Making

Analyst

8

System Design

Chapter 4

4.2 CLASS DIAGRAM

SDT
pName : String LOC : Long Bugs : Long submit() fix()

Analyst_
verify() getStds() getProjSpec()

DB
storeProjSpec() getProjSpec() storeStdSpec() getStdSpec()

4.2 SEQUENCE DIAGRAM
SDT 1: Developed Product 2: Req For Documentation Analyst DB

3: Doc and Specification 4: Process Doc

5: Retrieve Product Specifications

6: Req For STD Spec 7: Retrieve Spec 8: Spec Std's for that S/w

9: Compare Product Spec and Std Spec 10: If Re-Design Needed

11: Re-Design

9

System Design

Chapter 4

4.3 COLLABORATION DIAGRAM
4: Process Doc 5: Retrieve Product Specifications 9: Compare Product Spec and Std Spec 1: Developed Product 3: Doc and Specification Analyst 2: Req For Documentation 10: If Re-Design Needed 8: Spec Std's for that S/w

11: Re-Design

7: Retrieve Spec

SDT

6: Req For STD Spec

DB

4. 4 ACTIVITY DIAGRAM
SDT Analyst DB

After SoftDev

No

Get Standard Spec Std Specification

Is Doc is Ready ? Soft Spec Documentation

Validate

Std Spec

Results ? Re - Design Not Satisfied OK. Fine

10

Implementation

Chapter 5

CHAPTER 5
IMPLEMENTATION
This phase is broken up into two phases: Development and Implementation. The individual system components are built during the development period. During Implementation, the components built during development are put into operational use. In the development phase of our system, the following system components were built.

5.1 DEVELOPMENT
The development of the library management system is as follows: 5.1.1 Database module The module consists mainly creation of a database. 1. In Microsoft SQL Server group we created a new database named, lib 2. The required table, say sqa(sid,sdesc,cc,loc,fpa,r_cc,r_loc,r_fpa) is created. 3. In cordys studio, a new SOAP node is created under OLEDB metadata services. 4. This node is started. 5.1.2 Query Formulation In the table we created a new method set. Inside the method set, we created a set of methods with queries. A method is generated to display the sqa details, another to update the table and one to display the software details. This method set is published to runtime and imported to cordys studio.

13

Implementation

Chapter 5

5.1.3 GUI module In the repository of the cordys studio we created a new application model. Xforms form its components. An Xform is created with a input box to input sid. A nother Xform displays the sqa details. Then an Xform is created to input attributes required to update the database. The updated details are displayed in another Xform. These xforms are published to runtime and imported to the cordys studio. 5.1.4 BPM module The flowchart is created with activity boxes. The Xforms and queries are mapped to corresponding activities.

14

Implementation

Chapter 5

5.2 IMPLEMENTATION
The BPM model is validated and published to runtime. It is then debugged to see step wise execution. The figure below is a snapshot of the library BPM component.

15

Testing

Chapter 6

CHAPTER 6
TESTING
This chapter explains the various testing procedures conducted on the system. Testing is a process of executing a program with the intent of finding an error. A successful test is one that uncovers an as yet undiscovered error. A testing process cannot show the absence of defects but can only show that software errors are present. It ensures that defined input will produce actual results that agree with the required results. A good testing methodology should include
• • • • • • • • •

Clearly define testing roles, responsibilities and procedures Establish consistent testing process Streamline testing requirements Overcome “requirements slow me down” mentality Common sense process approach Use some elements of existing Process Not an attempt to replace, rewrite or redefine Process To find defects early and to give good time to developers for bug fixes Independent perspective in testing

Some of the testing principles used in this project are:
• •

Unit Testing Integration Testing

6.1 UNIT TESTING
Unit testing is a strategy by which individual components, which make up the system, are tested first to ensure that system works up to the desired extent. It focuses on the verification effort on the smallest unit of the software design i.e. module. Various modules of the system are tested to see whether they perform their intended functions. Using procedural design description, important control paths are tested to uncover the

16

Testing

Chapter 6

errors with in the boundary of the module. While accepting a connection using specified functions we go for unit testing in their respective modules. The unit test is normally a white box test (a testing method in which the control structure of the procedural design is used to derive test cases).

6.1.1 Process Objectives
To test every unit of the software in isolation before integrating it with other units

6.1.2 Definition of Unit
A unit is a module as identified during size estimation process with a size estimate that does not exceed 1000LOC. For GUI applications each screen will be a unit. If the size estimate for a unit exceeds 1000 LOC and it is not feasible to break it into smaller logically independent units that can be tested in isolation, the project lead in concurrence with the SQA can decide to define this as a unit.

6.1.3 Entry Criteria
The entry criteria for this process are the following:
• •

Unit completed Unit peer reviewed

6.1.4 Exit Criteria
The exit criteria for this process are the following:
• •

Unit test cases executed Any defects that are identified during unit testing and that are not fixed before the unit enters component testing is listed in the test report and verified 100% statement coverage If unit will be tested before code review of unit, this must be identified in the

project plan. In these projects the developer will self-review (desk check) the code before unit testing. In cases of exception handling of error conditions that are difficult to generate, thereby making it impossible to achieve 100% statement coverage, the code should be formally reviewed with this additional criteria

17

Testing

Chapter 6

6.2 INTEGRATION TESTING
The integration testing is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing. It is a type of testing by which the individual modules of the system are combined and tested whether they work properly as a whole. The objective is to take unit test modules and build a program that has been dictated by the design. Integration testing can be either ‘Incremental’ or ‘Non-Incremental’. The objective of the integration testing is to help engineers plan and execute the component and Integration testing for their respective projects. Integration testing should include the following objectives:
• •

Performed by the product group/Dev test team after feature complete Determines that all product components on a list of specific platforms function successfully together (The List specified in Master test plan) Performed in a basic product / platform environment (Basic environment specified in Master test plan) Tests the product functionality against the specification Tests functionality of fake languages with sample single and double byte languages Tests scaling to an acceptable minimum level as called out in the master test plan Tests performance, reliability to an acceptable level as called out in the master test plan Final integration tests done after all components are integrated, with the build in production format The tasks of the project have been integrated and the functioning of the entire

• •

system has been found to be satisfactory. The functionality of the entire system has been subjected to a series of tests and all the modules have been found to interoperate properly. Finally the integration testing was performed on the integrated system and found to work properly.

18

Testing

Chapter 6

6.3 SAMPLE TEST CASES
The following are the some of the sample test cases employed along with the test results have been described in the table below. Table 6.1 Sample Test Cases Test Description Is DB Connectivity is Accessible? Is the new Software info updated in database? Is the SQA attributes are properly checked? Is user could find the application manageable? Result OK OK OK OK

19

Snapshot

Chapter 7

CHAPTER 7
SNAPSHOT
This chapter contains the snapshot of various forms in our system.

7.1 The GUI for student id input - XForm

20

Snapshot

Chapter 7

7.2 Authorized student details XForm

21

Snapshot

Chapter 7

7.3 Adding the issued book details to the database

22

Snapshot

Chapter 7

7.4 The details of issued book displayed – Xform

23

Snapshot

Chapter 7

7.5 The Updated database

24

Snapshot

Chapter 7

7.6 Testing a query

25

Conclusion

CONCLUSION
Thus the analysis, design and implementation of SQA system is done successfully so that the user be able to do addition of a set of files in a database and the user be able to view the file in a database created in SQL Server. This system is very useful for Analyst who is maintaining Software Quality. Also the system is very easy for managing the files and end user could easily understand the process of the system.

26

Bibliography

BIBLIOGRAPHY
• • • Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed., Addison-Wesley. ISBN 0-321-19368-7. Penker, Magnus; Hans-Erik Eriksson (2000). Business Modeling with UML. John Wiley & Sons. ISBN 0-471-29551-5. Elmasri Navathe, Somayajulu Gupta. Fundamentals of database system. Pearson Education ISBN 81-7758-476-6

Websites
http://www.cordys.com/ http://www.uml-forum.com/FAQ.htm

28

APPENDIX
Creating a BPM

1. Cordys studio -> repository ->business models -> business process model ->create new folder(right click on BPM) -> right click folder and create new business process model ->create flow chart using start icon, stop icon and activity boxes. Creating an xform 1. repository ->application models ->xforms -> right click and create new xform ->design xform. 2. right click xform ->publish to runtime. Creating database 1. Microsoft enterprise manager -> console root -> Microsoft SQL servers -> SQL server group -> SOALAB-VM\PSGINSTANCE ->databases -> create new database -> tables-> right click table and create new table 2. To insert values in table -> right click table -> return all rows (passwords0aadm1n)

Create soapnode 1. cordys menu -> psgsoa13 -> psgsoaorg7 -> administrator ->admin tools -> soapnodes -> right click -> new -> a browser will open. 2. tick oledb integrator -> name your soapnode -> select all oledb methodsets -> click next until provide details of oledb connector -> database vendor (sql server) -> default database(your database name) ->provider (SQL OLEDB) -> db user (sa) -> machine name ( SOALAB-VM\PSGINSTANCE) -> password(s0aadm1n) > click next and finish.

Sign up to vote on this title
UsefulNot useful