soa cordys lab report

8/14/2019 SOA Cordys Lab Report

http://slidepdf.com/reader/full/soa-cordys-lab-report 1/32

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

iii

CONTENTS

CHAPTER Page No.

Acknowledgement (i)

Synopsis (ii)

List of Figures (iii)

1. INTRODUCTION 1

1.1. Problem Definition 1

1.2. Objective of the Project 1

1.3. Significance of the Project 11.4. Outline of the Project 2

2. SYSTEM STUDY 3

2.1. Proposed System 3

3. SYSTEM ANALYSIS 5

3.1 Requirement Analysis 5

3.2 Feasibility Study 5

3.3 Technology Overview 6

4. SYSTEM DESIGN 8

4.1 Use case Diagram 8

4.2 Sequence Diagram 9

4.3 Collaboration Diagram 10

4.4 Activity Diagram 11

4.5 State chart Diagram 12

5. SYSTEM IMPLEMENTATION 13

5.1 Development 13

5.2 Implementation 15

6. TESTING 166.1 Unit Testing 16

6.2 Integration Testing 18

6.3 Sample Test Cases 19

7. SNAPSHOT 20

7.1 The GUI for sid input 20



Contents

iv

7.2 Accepted Software 21

7.3 SQA Details Update 22

7.4 Testing a query 25

CONCLUSION 26

FUTURE ENHANCEMENTS 27

BIBLIOGRAPHY 28



Synopsis

ii

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 SoftwareSpecifications 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.



Future Enhancements

27

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.



List of Figures

iii

LIST OF FIGURES

FIGURE NO LIST OF FIGURES PAGE NO.

Fig: 2.1 System Architecture 4

Fig: 4.1 Use case diagram 8

Fig: 4.2 Sequence diagram 9

Fig:4.3 Collaboration diagram 10

Fig:4.4 Activity diagram 11

Fig 4.5 State chart diagram 12



Acknowledgement

i

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.



Introduction Chapter 1

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.



Introduction Chapter 1

2

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.



System Study Chapter 2

3

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

SQA

System

Display Results

Standard

Specifications

Database

Developed

Software

Specifications

Compare Quality

Attributes



System Analysis Chapter 3

5

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 RequirementsThe 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




6

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-to-

change. However, many organizations are hindered by IT landscapes that are built-to-

last. 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




7

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 creatingand managing a SQL Server cluster



System Design Chapter 4

8

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 Documentation

Database

Standard Specifications

Analyst

Re-Design

Decision Making

SoftwareDevelopment Team




9

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 Analyst DB

1: Developed Product

2: Req For D ocumentation

3: Doc and Specification

4: Process Doc

5: Retrieve Product Specifications

6: Req For STD Spec

7: Retrieve Spe c

8: Spec S td's for that S/w

9: Compare Product Spec and Std Spec

10: If Re-Design Need ed

11: Re-Design




10

4.3 COLLABORATION DIAGRAM

SDTAnalyst DB

1: Developed Product

2: Req For Documentation

3: Doc and Specification

4: Process Doc5: 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

4. 4 ACTIVITY DIAGRAM

Is Doc isReady ?

After SoftDevNo

Documentation

Re - Design

Get StandardSpec

Validate

Results ?

StdSpecification

Soft SpecStd Spec

Not Satisfied

OK. Fine

DBAnalystSDT



Implementation Chapter 5

13

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.




14

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.




15

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.



Testing Chapter 6

16

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 requiredresults. 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 TESTINGUnit 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



Testing Chapter 6

17

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



Testing Chapter 6

18

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.



Testing Chapter 6

19

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 Result

Is DB Connectivity is Accessible? OK

Is the new Software info updated in database? OK

Is the SQA attributes are properly checked? OK

Is user could find the application manageable? OK



Snapshot Chapter 7

20

CHAPTER 7

SNAPSHOT

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

7.1 The GUI for student id input - XForm



Snapshot Chapter 7

21

7.2 Authorized student details XForm



Snapshot Chapter 7

22

7.3 Adding the issued book details to the database



Snapshot Chapter 7

23

7.4 The details of issued book displayed – Xform



Snapshot Chapter 7

24

7.5 The Updated database



Snapshot Chapter 7

25

7.6 Testing a query



Conclusion

26

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.



Bibliography

28

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 EducationISBN 81-7758-476-6

Websites

http://www.cordys.com/

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



APPENDIX

Creating a BPM

1. Cordys studio -> repository ->business models -> business processmodel ->create new folder(right click on BPM) -> right click folder and create newbusiness process model ->create flow chart using start icon, stop icon andactivity boxes.

Creating an xform

1. repository ->application models ->xforms -> right click and create newxform ->design xform.

2. right click xform ->publish to runtime.

Creating database

1. Microsoft enterprise manager -> console root -> Microsoft SQL servers -> SQLserver group -> SOALAB-VM\PSGINSTANCE ->databases -> create newdatabase -> tables-> right click table and create new table

2. To insert values in table -> right click table -> return all rows (password-s0aadm1n)

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.

soa cordys lab report

Documents