soa cordys lab report
TRANSCRIPT
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 2/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 3/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 4/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 5/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 6/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 7/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 8/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 9/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 10/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 11/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 12/32
System Analysis Chapter 3
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 13/32
System Analysis Chapter 3
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 14/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 15/32
System Design Chapter 4
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 16/32
System Design Chapter 4
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 17/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 18/32
Implementation Chapter 5
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 19/32
Implementation Chapter 5
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 20/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 21/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 22/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 23/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 24/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 25/32
Snapshot Chapter 7
21
7.2 Authorized student details XForm
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 26/32
Snapshot Chapter 7
22
7.3 Adding the issued book details to the database
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 27/32
Snapshot Chapter 7
23
7.4 The details of issued book displayed – Xform
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 28/32
Snapshot Chapter 7
24
7.5 The Updated database
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 29/32
Snapshot Chapter 7
25
7.6 Testing a query
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 30/32
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.
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 31/32
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
8/14/2019 SOA Cordys Lab Report
http://slidepdf.com/reader/full/soa-cordys-lab-report 32/32
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.