Fault Management System Documentation
Content
Teleparadigm
Fault management system on cloud
<mm dd yyyy>
<Version 1.0.0>
Contents
Table of Contents
1.
Introduction ………………………………………………………………
2. Phases ……………………………………………………………………. 2.1 Module 1 2.2 Module 2 2.3 Module 3 3. Purpose …………………………………………………………………… 3.1 Scope 4. Application, Objective and Benefits …………………………………….. 5. UML …………………………………………………………………….. 5.1 Structural Diagrams 5.2 Deployment Diagrams 5.3 Behavioral Diagrams 5.4 Sequence Diagrams 5.5 Collaboration Diagrams 5.6 State chart Diagrams 6. Architecture Diagram ……………………………………………………. 7. Database …………………………………………………………………. 8. User Interface …………………………………………………………… 9. Software Requirement Specification (SRS) 9.1 Overview ……………………………………………………………
9.2 Product Perspective ………………………………………………... 9.3 System Interfaces ………………………………………………….. 9.3.1 User Interface ………………………………………………… 9.3.2 Hardware interface …………………………………………… 9.3.3 Software Interfaces …………………………………………… 9.3.4 Memory Constraints ………………………………………….. 9.4 Product Functions …………………………………………………… 9.5 User Characteristics …………………………………………………. 9.6 Constraints …………………………………………………………… 9.7 Logical Database Requirements ……………………………………… 9.8 Design Constraints …………………………………………………… 9.9 Standard Compliance ………………………………………………… 9.10 Reliability …………………………………………………………... 9.11 Availability …………………………………………………………. 9.12 Security ……………………………………………………………. 9.13 Maintainability ……………………………………………………... 9.14 Portability ………………………………………………………….. 9.15 System Mode ………………………………………………………. 9.16 Supporting Information …………………………………………… 9.17 Document Control ………………………………………………… 9.18 Appendix A ……………………………………………………… 9.19 Specific Requirements …………………………………………….. 9.20 Performance requirements …………………………………………. 9.21 Software System Attributes ……………………………………….. 9.22 Features ……………………………………………………………..
9.23 Objects …………………………………………………………….. 9.24 Stimulus …………………………………………………………… 9.25 Response …………………………………………………………… 9.26 Functional Hierarchy ………………………………………………. 9.27 Additional Comments ……………………………………………… 10. Programming Code ………………………………………………………… 11.Technology Features ……………………………………………………….
11.1 JAVA
Technology ………………………………………………….
11.2 SQL Server …………………………………………………………… 11.3 FLEX4 …………………………………………………………….. 12. Testing ……………………………………………………………………… 12.1 Black Box Testing 12.2 White Box Testing 12.3 Security Testing 12.4 Compatibility Testing 13. Conclusions ……………………………………………………………… 14. Future Enhancements ……………………………………………………… 15. References …………………………………………………………………..
1. Introduction:
Cloud computing is a technology that uses the internet and central remote servers to maintain data and applications. Cloud computing allows consumers and businesses to use applications without installation and access their personal files at any computer with internet access. This technology allows for much more efficient computing by centralizing storage, memory, processing and bandwidth. Cloud computing is broken down into three segments: applications, platforms and infrastructure. Amazon Web Services provides virtual server instances managed through a web service API with unique IP addresses and host names assigned dynamically and blocks of storage on demand. Customers use the provider's application program interface (API) to start, stop, access and configure their virtual servers and storage.
Definition: Cloud Computing:
Cloud computing is a general term for anything that involves delivering hosted services over the Internet. These services are broadly divided into three categories: Infrastructure-as-a-Service Platform-as-a-Service and Software-as-a-Service .
Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. Amazon EC2’s simple web service interface allows you to obtain and configure capacity with minimal friction. It provides you with complete control of your computing resources and lets you run on Amazon’s proven computing environment. Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change. Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use. Amazon EC2 provides developers the tools to build failure resilient applications and isolate themselves from common failure scenarios.
Amazon EC2 Functionality Amazon EC2 presents a true virtual computing environment, allowing you to use web service interfaces to launch instances with a variety of operating systems, load them with your custom application environment, manage your network’s access permissions, and run your image using as many or few systems as you desire. To use Amazon EC2, you simply:
•
Create an Amazon Machine Image (AMI) containing your applications, libraries, data and associated configuration settings. Or use pre-configured, template images to get up and running immediately. Upload the AMI into Amazon S3. Amazon EC2 provides tools that make storing the AMI simple. Amazon S3 provides a safe, reliable and fast repository to store your images. Use Amazon EC2 web service to configure security and network access. Choose which instance type(s) and operating system you want, then start, terminate, and monitor as many instances of your AMI as needed, using the web service APIs or the variety of management tools provided. Determine whether you want to run in multiple locations, utilize static IP endpoints, or attach persistent block storage to your instances. Pay only for the resources that you actually consume, like instance-hours or data transfer.
•
• •
•
•
2 Phases:
Modules
Module-1: The first module is designed to provide authentication to individuals who wish to
get connected. The registration details are stored in the database and whenever the user logs in, the user credentials are retrieved to check whether the user is an authorized user or not. The front end is designed using Flex. Module2: In this module the error is reported by the customer a ticket is generated for the fault. Manager views the faults, escalates the faults to available analyzer or technicians. He
monitors the fault management system. He maintains error log and keep track of the problem and person who is working on it. Module-3: In this module Analyzer and Technicians solve the problems allocated by the manager depending on the location from where the error encountered and generate reports after rectifying them. Module-4: In this module administrator maintains error log and keep track of the problem and person who is working on it. Module-5: In this module we will deploy entire application in Amazon Elastic Compute Cloud (EC2) of Amazon Web Service
3. Purpose:
Today Fault Management System is a key part in Network Management Architecture consists of functions such as detect, isolate, determine the cause and correct the malfunctions in network. Fault Management System helps in increasing network availability, reduce network downtime and restore network failure quickly. In this project once error is reported, first step is to detect the fault and make a report of it. Based on this report we will isolate the fault i.e. to find the exact location of the fault and to determine the cause of the fault. Once isolated the fault need to be corrected and appropriate action need to be taken and report is send to administrator. The administrator will maintain error logs and keep track of the person who works on the fault. Finally the entire application is deployed on cloud.
Scope:
•
The Scope of the project is the vendor need not maintain their own fault management system. They can use centralized fault management system which would help them reducing overall cost.
•
Application, Objective and Benefits: • Application:
The application will be utilized by the Users.
•Goal:
The Web Site is intended to avoid server failure, virus attack and decrease the infrastructure costs, maintenance costs occurred to maintain the application .
•Objective:
. 1. Manage the application on cloud
2. 3. 4. 5.
Creating a User Interface for Fault management system on cloud The process involves Registration, Authentication and operator will get the complaint. This application or the UI is converted into Amazon Machine Image(AMI) Deploying the AMI on the Amazon Cloud
•Benefits:
a) No extra maintainenace cost incurred. The application will be maintained by the cloud. b) No need to of extra infrastructure cost. c) Avoid virus attack d) No server failure. 5. UML: Design Patterns brought a paradigm shift in the way object oriented systems are designed. Instead of relying on the knowledge of problem domain alone, design patterns allow past experience to be utilized while solving new problems. Traditional object oriented design (OOD) approaches such as Booch, OMT, etc. advocated identification and specification of individual objects and classes. Design Patterns on the other hand promote identification and specification of collaborations of objects and classes. However, much of the focus of recent research has been towards identification and cataloging of new design patterns. The effort has been to assimilate knowledge gained from designing systems of the past, in various problem domains. The problem analysis phase has gained little benefit from this paradigm. Most projects still use traditional object oriented analysis (OOA) approaches to identify classes from the problem description. Responsibilities to those classes are assigned based upon the obvious description of entities given in the problem definition. Pattern Oriented Technique (POT) is a methodology for identifying interactions among classes and mapping them to one or more design patterns. However, this methodology also uses traditional OOA for assigning class responsibilities. As a result, its interaction oriented design phase (driven by design patterns) receives its input in terms of class definitions that might not lead to best possible design.
The missing piece here is the lack of an analysis method that can help in identifying class definitions and the collaborations between them which would be amenable to application of interaction oriented design. There are two key issues here. First is to come up with good class definitions and the second is to identify good class collaborations. It has been observed in that even arriving at good class definitions from the given problem definition is non-trivial. The key to various successful designs is the presence of abstract classes (such as an event handler) which are not modeled as entities in the physical world and hence do not appear in the problem description. In anticipating change has been proposed as the method for identifying such abstract classes in a problem domain. Another difficult task is related to assignment of responsibilities to entities identified from the problem description. Different responsibility assignments could lead to completely different designs. Current approaches such as Coad and Yourdon, POT etc. follow the simple approach of using entity descriptions in the problem statement to define classes and fix responsibilities. We propose to follow a flexible approach towards assigning responsibilities to classes so that the best responsibility assignment can be chosen. The second issue is to identify class collaborations. Techniques such as POT analyze interactions among different sets of classes as specified in the problem description. Such interacting classes are then grouped together to identify design patterns that may be applicable. However, as mentioned earlier, only the interactions among obvious classes are determined currently. Other interactions involving abstract classes not present in the problem or interactions that become feasible due to different responsibility assignments are not considered. We present some techniques that enable the designer to capture such interactions as well.
Interaction Based Analysis and Design
Top-down approach This approach is applicable to situations where the designer knows the solution to the given problem. It is true for problem domains that have well established high-level solutions and different implementations vary in low level details (for e.g. Enterprise Resource Planning (ERP) systems). Her main concern is to realize that solution in a way such that the implemented system has nice properties such as maintainability and reusability etc. To achieve this goal, the system designer selects appropriate design patterns that form the building blocks of her solution. Having obtained this design template (design type), she maps the classes and objects participating in those patterns to the entities of the problem domain. This mapping implicitly defines the responsibilities of various classes/objects that represent those entities. To help clarify the concept, consider a scenario where an architect is assigned the task of building a flyover. Flyover construction is an established science and the architect knows the solution to the problem. She starts by identifying component patterns such as road strip, support pillars, side railings and so on. Having done that, she maps the participating objects to actual entities in the problem domain. This would involve defining the length and width of the road strip based upon the space constraints specified in the problem. The height and weight of the pillars get decided based upon the load requirements specified. The entry and exit points get decided based upon the geography of the location and so on. This results in a concrete design
instance. Some new classes or objects, not existing in the domain model, may also have to be introduced for a successful instantiation of the design template. For instance, the problem domain may not model an abstract entity such as an event handler which may be a participant in some portion of the design template. Such generic classes/objects may be drawn from a common repository of utility classes. Interaction driven analysis phase here is simple since the interactions (in the form of design patterns) are already well established and directly obtained from the knowledge base. Bottom-up approach This approach is applicable in scenarios where interactions in the problem domain are not well understood and need to be discovered and explored. This situation is a fundamental problem faced by the designers of object oriented systems. It relates to the fact that objects oriented analysis (OOA) does not help much in creating a solution to the problem at hand. The analysis phase is mainly concerned with enhancing the understanding of the problem domain. This knowledge is then later used by a problem solving approach to come up with a solution possessing good design properties. As a result, at the end of the analysis phase the designer has a set of well defined components that need to be assembled together for realizing a solution. For instance, to build a route finder application the OOA phase helps in modeling the domain objects such as roads, vehicles, cities, addresses etc. but does not actually provide a solution for finding routes between two given addresses. This is similar to having various pieces of a jigsaw puzzle but the puzzle still needs to be solved. The problem in software systems is further complicated by the fact that there is generally no unique solution to a problem. There are always trade-offs at various stages and the resulting designs are a reflection of the choices made at those stages. In the jigsaw puzzle example this is similar to the situation where different sets of the same puzzle are available each differing from another in terms of the design of its component pieces. Some component designs may help in solving the puzzle faster and more efficiently than others. The bottom-up approach helps in such situations where the entities in the problem domain have been identified by traditional OOA techniques but multiple choices exist in terms of assigning responsibilities to those entities. Unlike top-down approach, the mapping of responsibilities to entities is not dictated by the design solution specified by the designer. Instead, the task of the designer here is to try various responsibility assignments and create an interaction specification involving those objects. The objective of this interaction driven analysis is to obtain an interaction specification that helps in arriving at a solution with best design characteristics possible. Having identified the entities in the domain, the starting point for the designer is to identify various alternatives available for assigning responsibilities to individual objects. Her domain knowledge helps her in this task. Given these alternatives for potential object definitions and standard utility objects (such as schedulers, event handlers etc.), the next step is to find compositions of these building blocks (i.e. interactions of these objects) that provide alternative solutions to the problem. This task is a non-trivial one especially when done manually. There are just too many combinations to be considered, for any human designer to obtain alternative solutions in a reasonable amount of time. We need to apply (semi-)automated software composition techniques based on some formal specification. Several such approaches have been recently investigated in the context of e-services. These include workflow based approaches and AI Planning based techniques. Other formal techniques for specifying composition include Petri-
net based models, automata-based models; temporal logics etc. from verification community and XQuery, XML constraint tools based techniques from data management community . The resulting candidate compositions (i.e. interaction specifications) then need to be compared with existing design patterns either manually or automatically. It is not beyond imagination to visualize that with advancement in automated composition techniques, new design patterns may get identified during this process. For instance, techniques such as Reinforcement Learning have resulted in new novel solutions in various domains such as playing Backgammon. In such a case, the resulting designs may need to be evaluated manually. The best design among the alternatives is then chosen for implementing the system.
Open Issues
Identifying interactions This is a crucial step in the analysis phase and the success of remaining phases depends on it. The issue here is to identify interactions which are not evident from the problem description but may hold the key to an efficient design solution. The bottom-up approach proposed in this paper takes a step in this direction but a lot more work is needed. The analysis method should be such that it is able to incorporate abstract classes such as event handlers, proxies etc. Moreover, current analysis methods map entities to responsibilities of individual classes in terms of services they provide and methods they invoke on other classes. However, an entity may be realized by a set of classes. For instance, an adapter class hides the interface of an adoptee class and they collectively provide the desired functionality. Similarly, an abstraction and its implementation provide a single functionality through separate classes resulting in increased maintainability. The analysis method needs to be able to determine when is it appropriate to realize an entity responsibility by means of multiple interacting classes. Representation of Class Responsibilities Since we need to specify different alternative class responsibilities, as in bottom-up approach, a mechanism is required to document them in a machine interpretable format. Some of these responsibilities would get captured in the form of methods a class exports or methods it invokes on other classes. However, other responsibilities with respect to its interaction with other classes need to be explicitly specified. These may include pre- and post-conditions for different method invocations, other properties such as ’hasSameInterfaceAs <another class>’, ’hidesInterfaceOf <another class>’ etc. Languages such as could be used as it is or extended for this purpose. Language for Specifying Design Patterns
The approaches for OO Design proposed in this paper favor automatic techniques over manual ones for reasons described earlier. This means that we need a mechanism to be able to express design patterns in a format amenable to be read and interpreted by programs. Some attempts have been made at defining such pattern description languages [14, 13]. One of these or some variation of these could be used to express design patterns in a formal language. Comparison of Software Designs Once we have alternative designs available, they need to be compared to arrive at the best one. Each design may consist of multiple design patterns. The criteria here would not be to simply count the number of design patterns used but to evaluate the interaction between patterns and also between other design elements used. This would involve an understanding of good and bad design interactions and an ability to identify them in a given design. The final challenge would be to do it automatically.
5.1 Structural Diagram Class Diagram:
Class diagrams identify the class structure of a system, including the properties and methods of each class. Also depicted are the various relationships that can exist between classes, such as an inheritance relationship. The Class diagram is one of the most widely used diagrams from the UML specification
Class Diagrams are given to depict interactions
Object Diagram:
Object diagrams model instances of classes. This type of diagram is used to describe the system at a particular point in time. Using this technique, you can validating the class diagram and it's multiplicity rules with real-world data, and record test scenarios. From a notation standpoint, Object diagrams borrow elements from Class diagrams.
Component Diagram:
Component diagrams fall under the category of an implementation diagram, a kind of diagram that models the implementation and deployment of the system. A Component Diagram, in particular, is used to describe the dependencies between various software components such as the dependency between executable files and source files. This information is similar to that within make files, which describe source code dependencies and can be used to properly compile an application.
5.2 Deployment Diagram:
Deployment diagrams are another model in the implementation diagram category. The Deployment diagram models the hardware used in implementing a system and the association
between those hardware components. Components can also be shown on a Deployment diagram to show the location of their deployment. Deployment diagrams can also be used early on in the design phase to document the physical architecture of a system.
5.3 Behavioral Diagrams: Use Case Diagram:
Use Case diagrams identify the functionality provided by the system (use cases), the users who interact with the system (actors), and the association between the users and the functionality. Use Cases are used in the Analysis phase of software development to articulate the high-level requirements of the system. The primary goals of Use Case diagrams include:
• • •
Providing a high-level view of what the system does Identifying the users ("actors") of the system Determining areas needing human-computer interfaces
Use Cases extend beyond pictorial diagrams. In fact, text-based use case descriptions are often used to supplement diagrams, and explore use case functionality in more detail.
Operator
Register Complain
Operator Send refno to customer
Send complain to concern admin
Administrator
C c aa bt h k vi l y e la i
Aoa Wk ll c t e o r Ami t a r d i sr t n o
E p y e eisr t n moe Rg t a l io
Analyzer
Sn Ak ed c
Ce k F u h c s a lt
U d te E o L g p a s rr r o Aa z r n ly e
E c la s F u s a te a lt
G n ra s R p rt e e te e o
Technician
S tart W ork
Tec hnic ian M ak e Reports after c om p work
Higher Authority
Check Escalation Report
Check Isolation Report
Higher Authority Check Technician Report
5.4 Sequence Diagram:
Sequence diagrams document the interactions between classes to achieve a result, such as a use case. The Sequence diagram lists objects horizontally, and time vertically, and models these messages over time.
OPERATOR
Operator userid, pwd
Login
CompReg
SendRefno
SendFlt
v alid
Complain registration Send refno
Send Fault to concern admin
Administrator
Admin Register Login Check availability Allocate Work Emp Regietration
Register
login
valid
Check availabilit y of person
Allocate work
Registers Employees
Analyzer
Analyzer Authentication Check Fault Send Acknowledgement Error Log Escalate Fault Report
login
valid
Check fault
Send Ack
Check error log based on fault
Escalate fault to H A
Send Isolation report to HA
5.5 Collaboration Diagram:
Collaboration diagrams model the interactions between objects. This type of diagram is a cross between an object diagram and a sequence diagram. It uses free-form arrangement of objects which makes it easier to see all iterations involving a particular object.
5.6 State chart Diagram:
State diagrams, are used to document the various modes ("state") that a class can go through, and the events that cause a state transition.
6. Architecture Diagram:
Cloud
7. Databases:
iii)DATABASE TABLES 1.Managers and operators
2.Employee Registration
3.Analyzer Work
4.Complaint Registration
5.Techinician Work
6.Technician work status
7.count the faults
8.Managers work
9.Fault Report
8. User Interface:
<Version 1.0.0>
Approvals Signature Block
Organization Responsibility Customer /customer representative
Signature
Date
Project Manager
Software Quality Assurance Leader Software Configuration Management Leader
User Documentation Leader
Student Name
User Training Leader
Faculty
Definitions, Acronym and Abbreviation
Term or Acronym Cloud Amazon Web Service
Definition A general term for anything that involves delivering hosted services over the Internet Cloud Service Provider
Table x. Definitions and Acronyms
9.1 Overall Description:
In today’s world each vendor has to maintain their own fault management system which increases the overall cost and maintenance for them. In this project we will overcome the above drawbacks by creating a centralized cloud based Fault Management System.
9.2 Product Perspective:
The project is a part of a large system. Block diagram: The major components of the larger system are shown as below.
9.3 System Interfaces:
Description of various interfaces used in the system is described in the subsequent paragraph.
9.3.1 User Interfaces:
Interface between the software product and its users:
User friendly interfaces as depicted below will be used.
1. Screen formats are required to be created with following features:User friendly. Indicate the Mandatory fields by asterisk (*). Fill up default values where ever possible Give combo boxes in all input screens. e) Student, and Data entry personnel details should be stored in the database through “Save” button. f) Authentication of users should be carried out where ever required. a) b) c) d)
2. Web Page or window layouts
Each screen should have • Menu driven facility
• Uniformity • Consistency
3. Outputs
Analytical outputs should be supported by graphs. a) For each output there should be provision of printing c) Emails should be well structured d) Each paper output should be formatted to A4 size paper.
4. DOs (Input)
Each input box to be supported by label Give tool tips where required Give formats (mm/ dd /yy) Provide Tab Index e) Input elements without visible labels should continue to contain text (search, login) a) b) c) d)
þÿ
Search site
f) Password g) radio inputs should have one option checked as default
þÿ
Login
5. DONTs (Inputs)
a) Don’t distract users from their goals b) Don’t use dark background with dark font colors c) Don’t use too many colors
6. Error messages Give small error messages like “Incorrect Data” or “Incorrect Date
Format” or “Field is required” and supplement it with “Ok” Button.
9.3.2 Hardware Interfaces:
Following Hardware Interfaces are required: • • • • Pentium 4 Processor Minimum 512 MB RAM 80 GB HDD
9.3.3 Software Interfaces:
Following Softwares are required:1. Java, J2EE (Servlets) 2. Amazon Web Service - Amazon Elastic Compute Cloud. 3. Flex4
9.3.4 Memory Constraints:
RAM with minimum 1 GB and 40 GB HD space
Broad level software requirements :
Unique ID 1. Requirement Make facility for registration of customer Remarks Provide Registration authentication interface. a and user
2. 3. 4. 5. 6. 7.
Create facility for storing Customer details Provide facility to Customer for error reporting Create facility for generate a ticket for every fault. Create facility for Manager views the faults, escalates the faults to available analyzer or technicians Create facility for Analyzer and Technicians solve the problems allocated by the manager Create facility for a administrator maintains error log and keep track of the problem and person who is working on it
9.4 Product Functions: Database Functions
1. Database should have the facility to a) b) c) d) e) f) g) h) i) insert records, update, edit, delete (Restricted users only), Search and Sort records. Create and edit master and transaction records. All the interaction to and from the database should be through Web Pages. Database should have following tables:-
Data Entry Personnel: First Name, Last Name, Address, Contact Details, Qualification, Place of work, Designation. etc II. Data Entry Points: user credentials.
I. 2.
Authentication
Users at all levels should be authenticated before giving them access.
3. Analysis
Outputs of all analysis should be in the form of a) Data in tabular form b) Graphical representation of Performance.
9.5 User characteristics:
Following are the characteristics of the intended users:Educational Level: Level of the users is between Educated to highly educated. Experience: Experienced in their domain but training in the proposed application. Technical Expertise: Training required in the proposed application.
9.6 Constraints: Site Adaption Requirements:
Only system Administrator and DBA are authorized to carry out this task jointly.
Assumptions and Dependencies
It is assumed that all the systems will have the basic HW, SW and Communication Interfaces available. The users are trained in using the application.
Apportioning of Requirements
Identify requirements that may be delayed until future versions of the system. All requirements will be met.
9.7 Logical Database Requirements:
Logical requirements connected with the database include: a) Most of the values are string types but the count is in numbers. b) Counting of the patients connected with a specific disease is monitored immediately after entering the record of each patient. c) Accessing rights are limited to authenticated users only.
d)
Integrity constraints are maintained by setting the relationships.
Functions:
Validity checks on the inputs
• Data Entry Operators
a) Exact sequence of operations Customer Registration Authentication Error report Manager view the fault and assign for solve Analyzer and technician solve the problem Maintains error log and keep track of the problem by admin b) Responses to abnormal situation, including • Overflow – Periodic Backups • Communication facilities : Internet, Telephone • Error handling and recovery : Periodic Backup, Error alerts, Maintain Error Logs c) Effect of parameters
9.8 Design Constraints
Hardware Constraints • • • • Pentium 4 processor, RAM Minimum 1 GB memory, 40 GB Hard disk. 100 Mbps Modem
Design constraints • • • Charts have to be created using Flex All user interfaces have to be created using Flex Interaction between User Interface and the database should be through Web Services.
9.9 Standards Compliance:
Following standards will be maintained:• • • • Report format. Data naming (As per the Naming Conventions – organization policy) Accounting procedures Audit Tracing (All changes made to student details will be traced in trace files with before and after values)
9.10 Reliability:
Software will be handed over to the client after carryout extensive Unit Testing Integration Testing System Testing After performing periodic demonstrations to the end users on completion of each module and keep a log of the errors / observations made by the user • Number of errors during Unit Testing may be more but they should show decreasing trend during Integration and System Testing and should reduce to zero at the time of delivery. Ensure strict compliance to Project Plan • • • •
9.11 Availability:
Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart. <Click Here to Insert Your Text>
9.12 Security:
• • • • •
•
Authentication module will ensure that only authorized users are provided access control on the web site. Roles will be defined to impose restrictions on the authorized users. Ensure that buffer overflow and integer overflow will be avoided. Whenever user is deleted his privileges will also get deleted. Carryout periodic backup of the database and maintain a log. Honey Pots Intentionally include some PCs in the network which are vulnerable for hackers. They can be used to catch hackers or fix vulnerability.
9.13 Maintainability
Keep a count of the number of lines of code. Though there cannot be a benchmark for the maximum lines of code in a sub routine but higher the lines of code indicates • Higher is the maintenance.
• Need to split up in to child levels. • Place every module in Try Catch () and finally () block to prevent disgraceful exit. Avoid excessive complexity Avoid excessive Inheritance Variable name should not match the field names Reduce complexity of conditional branching
9.14 Portability:
Specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems. This may include a) Percentage of components with host-dependent code b) Percentage of code that is host dependent c) Use of a proven portable language d) Use of a particular compiler or language subset e) Use of a particular operating system. Once the relevant characteristics are selected, a subsection should be written for each, explaining the rationale for including this characteristic and how it will be tested and measured. A chart like this might be used to identify the key characteristics (rating them High, Medium, or Low), or ranking them in order of importance (1, 2, 3, etc.). ID 1 2 3 Characteristic Correctness Efficiency Flexibility etc. Rank
Organizing the Specific Requirements:
For anything but trivial systems the detailed requirements tend to be extensive. For this reason, it is recommended that careful consideration be given to organizing these in a manner optimal for understanding. There is no one optimal organization for all systems. Different classes of systems lend themselves to different organizations of requirements in section 3. Some of these organizations are described in the following subsections.
9.15 System Mode:
Some systems behave quite differently depending on the mode of operation. For example, a control system may have different sets of functions depending on its mode: training, normal, or emergency. When organizing by mode there are two possible outlines. The choice depends on whether interfaces and performance are dependent on mode. Web Site being developed in ASP.NET 2.0 it is compatible to most of the OS and the Web Browsers.
9.16 Supporting Information:
The supporting information makes the SRS easier to use. It includes: a) Table of Contents at the front of the document b) Index c) Appendices: Definitions of important terminologies are given in the Appendix The Appendices are not always considered part of the actual requirements specification and are not always necessary. They may include: (a) Sample I/O formats, descriptions of cost analysis studies, results of user surveys; (b) Supporting or background information that can help the readers of the SRS; (c) A description of the problems to be solved by the software; (d) Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements. When Appendices are included, the SRS should explicitly state whether or not the Appendices are to be considered part of the requirements. Tables on the following pages provide alternate ways to structure section 3 on the specific requirements.
9.17 Document Control: Change History
Revision Release Date Description [list of changed pages and reason for change]
Document Storage
This document was created using standard SRS Template followed by IEEE. The file is stored by the Project Manager, one signed copy is handed over to the authorized representative of the customer and the second copy is kept with the Administrator. It establishes the basis for agreement with the client on what the software product is expected to do, as well as what it is not expected to do.
Document Owner
Project Manager is responsible for developing and maintaining this document.
9.18 Appendix A:
Definitions of the quality characteristics follow. • Correctness - extent to which program satisfies specifications, fulfills user’s mission objectives • Efficiency - amount of computing resources and code required to perform function • Flexibility - effort needed to modify operational program • Integrity/Security - factors that protect the software from accidental or malicious access, use, modification, destruction, or disclosure • Interoperability - effort needed to couple one system with another • Maintainability - ease of maintenance of the software itself • Portability - ease of porting the software to another host • Reliability - factors required to establish the required reliability of the system • Reusability - extent to which it can be reused in another application • Testability - effort needed to test to ensure performs as intended • Usability - effort required to learn, operate, prepare input, interpret output • Availability - factors required to guarantee a defined availability level for the system • Requirement Make facility for registration of customer Create facility for storing Customer details Provide facility to Customer for error reporting Create facility for generate a ticket for every fault. Create facility for Manager views the faults, escalates the faults to available analyzer or technicians Create facility for Analyzer and Technicians solve the problems allocated by the manager Create facility for a administrator maintains error log and keep track of the problem and person who is working on it Database will be in My SQL . Remarks Ensure Correctness and stability References Verifiable References
9.19 Specific Requirements
Uniqu e ID 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Correctness
Java and Flex Technology will be used. Correctness All components of the input screens will have Correctness validation checks Consistency will be maintained throughout the site. Correctness
9.20 Performance Requirements:
Presently we are working on four terminals. It is expected that at any point of time three terminals will be in operation simultaneously. The amount of information will be numerical and text oriented and the volume will be limited.
9.21 Software System Attribute:
Analysis: This is an important module and this module should be able to raise an alert by estimating the probability of disease being escalated to epidemic. Modular approach will be followed. Create Roles. Allow the user to analize the fault Check Performance by higher authority. Deploy the application on Amazon cloud 5. Manage the application
1. 2. 3. 4.
Graphs and email generation should be asynchronous.
9.22 objects:
Following objects are being considered in this application:• • Authorized users. Performance Report.
9.23 Feature:
The features are listed in the subsequent paragraphs in the form of Stimulus and Response.
9.24 Stimulus
• • User ID + Pwd of Data Entry Operators Performance.
9.25 Response:
• • Performance Report. Dynamic Graphs.
•
Authentication Alert.
9.26 Functional Hierarchy:
When none of the above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by common inputs, common outputs, or common internal data access. Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data. Draw DFDs Prepare Data Dictionaries.
9.27 Additional Comments:
Whenever a new SRS is contemplated, more than one of the organizational techniques given in 3.7 may be appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification. Any additional requirements may be put in a separate section at the end of the SRS. There are many notations, methods, and automated support tools available to aid in the documentation of requirements. For the most part, their usefulness is a function of organization. For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful. In any of the outlines below, those sections called “Functional Requirement i” may be described in native language, in pseudo code, in a system definition language, or in four subsections titled: Introduction, Inputs, Processing, and Outputs. <Click Here to Insert Your Text>.
10. Programming Code:
Login Page:
<mx:ViewStack x="10" y="95" id="viewstack1" width="911" height="498"> <s:NavigatorContent label="View 1" width="100%" height="100%" backgroundColor="#B9B49D"> <mx:ViewStack x="212" y="17" id="viewstack2" width="688" height="407" backgroundColor="#B0ADAD"> <s:NavigatorContent label="View 1" width="100%" height="100%" backgroundColor="#C2BCAA"> <mx:Image x="382" y="236" source="assets/cisco.jpeg" height="137" width="265"/> <mx:Image x="387" y="0" source="assets/adtran.jpeg" width="246" height="85"/>
<mx:Image x="385" y="85" source="assets/tele.jpeg" width="261" height="146"/> <s:Panel x="47" y="32" width="324" height="231"> <s:TextInput x="152" y="61" id="user" borderColor="#D7C2C2" width="159" fontSize="14" fontWeight="bold" fontFamily="Georgia"/> <s:Label x="70" y="62" text="UserName :" width="82" height="18" fontWeight="bold" fontSize="14"/> <s:TextInput x="153" y="109" id="pass" displayAsPassword="true" borderColor="#EDE2E2" width="159" fontSize="14"/> <s:Label x="70" y="111" text="Password :" width="82" height="18" fontWeight="bold" fontSize="14"/> <s:Button x="172" y="151" label="Login" width="78" click="login()" fontSize="14"/> <s:Label x="19" y="-7" text=" LoginHere:" width="107" height="16" fontSize="16" fontWeight="bold"/> <s:ToggleButton x="0" y="21" width="324" height="15" buttonMode="false"/> </s:Panel> </s:NavigatorContent> </mx:ViewStack> <s:RichText x="10" y="38" text="Fault management identifies the network problems, failures and trouble events, and corrects them. Fault management is the reactive form of network management. Fault management systems can be used to predict future failures, find faults, and analyze their causes." height="358" width="195" textAlign="center" chromeColor="#2B1515" backgroundColor="#BEB79C" fontWeight="bold" verticalAlign="justify" fontSize="14"/> </s:NavigatorContent> public function login():void { if(user.text==""||pass.text=="") { Alert.show("enter userid/password"); } else { login1.send();
} } <s:HTTPService id="login1" method="POST" resultFormat="text" url="http://localhost:9090/FaultMngmtSystem/servlet/Login1" result="call(event)" > <s:request xmlns=""> <username>{user.text}</username> <password>{pass.text}</password> </s:request> </s:HTTPService> public function call(event:ResultEvent):void { var res:String=event.result.toString(); var arr:Array=res.split(","); logout.visible=true; if(arr[0]=="operator") { str4=arr[1].toString()+""+"PvtLtd"; Alert.show("login success"); //lb1.text=arr[1].toString(); viewstack1.selectedIndex=1; } else if(arr[0]=="manager") { str3=arr[1].toString()+""+"PvtLtd"; //lb2.text=str; viewstack1.selectedIndex=2; } else if(arr[0]=="Analyzer") { str5=arr[1].toString()+""+"PvtLtd"; //lb3.text=arr[1].toString(); analyzerworkdetails.send(); //getTechDetails.send(); viewstack1.selectedIndex=3; } else if(arr[0]=="Technician") { str6=arr[1].toString()+""+"PvtLtd"; getTechWork.send(); //lb4.text=arr[1].toString(); viewstack1.selectedIndex=4; Alert.show("technician");
} else { Alert.show("Plz enter correct username/password"); } } 2.Complaint Registration <s:NavigatorContent label="complaintReg" width="100%" height="100%"> <s:Panel x="30" y="19" width="656" height="436"> <s:Label x="108" y="104" text="CustomerName:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="159" y="72" text="RefNo:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="133" y="210" text="FaultType:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="139" y="169" text="PhoneNo:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="141" y="137" text="Location:" width="57" fontWeight="bold" color="#030000" fontSize="12"/> <s:CheckBox x="210" y="223" label="Cable" fontWeight="bold" id="cable" click="faults()" color="#030000"/> <s:CheckBox x="210" y="287" label="Equipment" fontWeight="bold" id="equipment" click="faults()" color="#030000"/> <s:CheckBox x="211" y="265" label="Traffic" fontWeight="bold" id="traffic" click="faults()" color="#030000"/> <s:CheckBox x="211" y="244" label="Fibre" fontWeight="bold" id="fibre" click="faults()" color="#030000"/> <s:CheckBox x="211" y="312" label="unknown" fontWeight="bold" id="unknown" click="faults()" color="#030000"/> <s:TextInput x="216" y="102" id="custname"/> <s:TextInput x="214" y="69" id="refno"/> <s:TextInput x="214" y="163" id="ph" maxChars="10" restrict="0-9"/> <s:TextInput x="215" y="131" id="loc"/> <s:Label x="-2" y="42" text="ComplaintRegistration" width="318" fontFamily="Verdana" fontWeight="bold" fontSize="21" color="#804205"/> <s:Button x="345" y="69" label="GetDetails" fontWeight="bold" click="getStatus()"/>
<s:Button x="329" y="308" label="Submit" fontWeight="bold" click="submit()"/> <s:TextInput x="407" y="124" id="st" width="146" visible="false"/> <s:Label x="367" y="131" text="status:" fontWeight="bold" id="st1" fontSize="12" color="#070400" visible="false"/> <mx:Image x="401" y="210" source="assets/reg1.jpeg" width="245" height="164"/> <s:Button x="91" y="310" label="Reset" click="reset()"/> <s:TextInput x="402" y="164" id="f1" visible="false"/> <s:Label x="364" y="171" text="Fault:" id="f" fontWeight="bold" fontSize="13" color="#030200" visible="false"/> <s:Label x="137" y="-24" width="298" height="19" id="lb1" text="{str4}" fontSize="20" fontFamily="Verdana" fontWeight="bold"/> </s:Panel> <mx:Image x="693" y="10" source="assets/rep1.jpeg" width="218" height="173"/> <mx:Image x="692" y="185" source="assets/rep2.jpeg" width="219" height="151"/> <mx:Image x="693" y="335" source="assets/rep3.jpeg" width="213" height="163"/> </s:NavigatorContent> import mx.controls.Alert; import mx.rpc.events.ResultEvent; public function submit():void { comp.send(); updatefaults.send(); custname.text=''; loc.text=''; ph.text=''; //fd.text=''; } <s:HTTPService id="comp" method="POST" url="http://localhost:9090/FaultMngmtSystem/servlet/ComplaintReg ister" result="comp_resultHandler(event)"> <s:request xmlns=""> <operator>{user.text}</operator>
<custname>{custname.text}</custname> <phone>{ph.text}</phone> <location>{loc.text}</location> <fault1> {fault1.toString()} </fault1> </s:request> </s:HTTPService> protected function comp_resultHandler(event:ResultEvent):void { var reg:String=event.result.toString(); var reg1:Array=reg.split(","); if(reg1[0]=="1") { //refno.text=reg1[1].toString(); refno.visible=true; Alert.show(reg1[1].toString(),'Complaint Registration success'); } else if(reg=="0") { Alert.show("reg failed"); } } ii)JAVA CODE 1.Login1.java import java.io.IOException; import java.io.PrintWriter; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement;
import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;
public class Login1 extends HttpServlet {
/** * Constructor of the object. */ public Login1() { super(); }
/** * Destruction of the servlet. <br> */ public void destroy() { super.destroy(); // Just puts "destroy" string in log // Put your code here }
/** * The doPost method of the servlet. <br>
* * This method is called when a form has its tag value method equals to post. * * @param request the request send by the client to the server * @param response the response send by the server to the client * @throws ServletException if an error occurred * @throws IOException if an error occurred */ public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html"); PrintWriter out = response.getWriter(); try { Class.forName("com.mysql.jdbc.Driver"); Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/faultmanag ement", "root", "root"); Statement st=con.createStatement(); String uname=request.getParameter("username"); String pwd=request.getParameter("password"); System.out.println(uname); ResultSet rs=st.executeQuery("select * from managers where MId='"+uname+"' and password='"+pwd+"'");
if(rs.next()) { String designation=rs.getString("designation"); String company=rs.getString("company"); String s=designation+","+company; out.print(s); } else { String company1=""; ResultSet rs1=st.executeQuery("select * from employees where empId='"+uname+"' and Password='"+pwd+"'"); if(rs1.next()) { String desig=rs1.getString("designation"); company1=rs1.getString("company"); String add=desig+","+company1; out.print(add); } else { out.print("0"); } } }
catch(Exception e) { e.printStackTrace(); } }
/** * Initialization of the servlet. <br> * * @throws ServletException if an error occurs */ public void init() throws ServletException { // Put your code here }
} 2.Complaint Registration import java.io.IOException; import java.io.PrintWriter; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; import java.text.SimpleDateFormat; import java.util.Calendar;
import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;
public class ComplaintRegister extends HttpServlet {
/** * Constructor of the object. */ Connection con; Statement st; public static final String DATE_FORMAT_NOW = "dd-MM-yyyy"; public ComplaintRegister() { super(); }
/** * Destruction of the servlet. <br> */ public void destroy() { super.destroy(); // Just puts "destroy" string in log // Put your code here
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { Calendar cal = Calendar.getInstance(); SimpleDateFormat sdf = new SimpleDateFormat(DATE_FORMAT_NOW); String date1= sdf.format(cal.getTime()); try{ String company=""; Class.forName("com.mysql.jdbc.Driver");
con=DriverManager.getConnection("jdbc:mysql://localhost:3306/faultmanag ement","root","root"); st=con.createStatement(); System.out.println(" complaint dopost called connection created"); response.setContentType("text/html"); PrintWriter out = response.getWriter(); String operator=request.getParameter("operator"); String custname=request.getParameter("custname"); String location=request.getParameter("location"); //String date=request.getParameter("faultdate"); String fault=request.getParameter("fault1");
String phone=request.getParameter("phone"); String refno=new GenerateRefNum().getRef(); ResultSet rs=st.executeQuery("select company from managers where MId='"+operator+"' and designation='operator'"); if(rs.next()) { company=rs.getString("company"); } ResultSet rs1=st.executeQuery("select fault,custName,count from complaintreg where fault='"+fault+"' and companyname='"+company+"' and custName='"+custname+"' and faultdate='"+date1+"'"); if(rs1.next()) { Integer count=rs1.getInt("count"); count=count+1; int i1=st.executeUpdate("UPDATE complaintreg SET count='"+count+"' where custName='"+custname+"' and fault='"+fault+"' and faultdate='"+date1+"'"); if(i1==1) { System.out.print("Update success"); out.print("2"); } else { System.out.print("Update failed");
} } else { Integer cnt=1; int i=st.executeUpdate("insert into complaintreg(Refno,fault,faultdate,companyname,custName,location,count,P hone,status) values('"+refno+"','"+fault+"','"+date1+"','"+company+"','"+custname+"',' "+location+"','"+cnt+"','"+phone+"','unsolved')"); if(i==1) { System.out.println("complaint registeration successful"); out.print("1"+","+refno); } else { System.out.println("complaint registeration failed"); out.print("0"); } }} catch(Exception e) { e.printStackTrace(); }
}
/** * Initialization of the servlet. <br> * * @throws ServletException if an error occurs */ public void init() throws ServletException { // Put your code here }
}
3.Employee Registration
import import import import import import import import import import java.io.IOException; java.io.PrintWriter; java.sql.Connection; java.sql.DriverManager; java.sql.ResultSet; java.sql.Statement; javax.servlet.ServletException; javax.servlet.http.HttpServlet; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletResponse;
public class EmployeeRegistration extends HttpServlet { /** * Constructor of the object. */ Connection con; Statement st; public EmployeeRegistration() { super();
} /** * Destruction of the servlet. <br> */ public void destroy() { super.destroy(); // Just puts "destroy" string in log // Put your code here } /** * The doPost method of the servlet. <br> * * This method is called when a form has its tag value method equals to post. * * @param request the request send by the client to the server * @param response the response send by the server to the client * @throws ServletException if an error occurred * @throws IOException if an error occurred */ public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String company=""; try{ Class.forName("com.mysql.jdbc.Driver");
con=DriverManager.getConnection("jdbc:mysql://localhost:3306/faultmanagement", "root","root"); st=con.createStatement(); response.setContentType("text/html"); PrintWriter out = response.getWriter(); String empname=request.getParameter("empname"); String empId=request.getParameter("empid"); String phone=request.getParameter("empph"); String pwd=request.getParameter("pass"); String location=request.getParameter("emplocation"); String designation=request.getParameter("empdesig"); String manager=request.getParameter("manager"); ResultSet rs=st.executeQuery("select company from managers where MId='"+manager+"' and designation='manager'"); if(rs.next()) { company=rs.getString("company"); } int i=st.executeUpdate("insert into employees values('"+empname+"','"+empId+"','"+location+"','"+designation+"','"+pwd+"','" +company+"','available','"+phone+"')"); if(i==1) { System.out.println("register success"); out.print("1"); }
else { System.out.println("register failed"); out.print("0"); } } catch(Exception e) { e.printStackTrace(); } } /** * Initialization of the servlet. <br> * * @throws ServletException if an error occurs */ public void init() throws ServletException { // Put your code here } }
11. TECHNOLOGY
Language Java is an Object Oriented language that enables you to create real world applications. The code reusability feature of Java enables the software developers to upgrade the existing applications without rewriting the entire code of the application. Java can be used to create two types of programs: applications and applets.
An application is a program that runs on your computer, under the operating system of that computer. When used to create application, Java is more or less like one created using C computer language. Rather, it is Java’s ability to create Applet that makes it important.
An applet is an application designed to be transmitted over the internet and executed by a Javacompatible Web browser. An applet is actually a tiny java program, dynamically downloaded across the network, just like an image, sound file, or video clip. The important difference is that applet is an intelligent program, not just an animation or media file. In other words, an
applet is a program that can react to user input and dynamically change-not just run the same animation or sound over and over. Java exhibits the following a characteristic because of which java is a suitable language in fulfilling all the requirements of an organization. The characteristics are: Simple, Object-oriented, compiled and interpreted, portable, distributed, secure.
Java is called Object Oriented Language because it supports the following features of OOPS: Encapsulation, Abstraction, Inheritance, Polymorphism 11.2 J2EE • J2EE- JAVA 2 ENTERPRISE EDITION
Enterprise Development Any organization, from the largest corporation to the smallest company, may decide to acquire a software system that helps in its regular activities. All such activities may include the task of making its products available to its customers who may not otherwise know about them, to make data to its internal employees. The need itself is unimportant but the fact that the organization has decided to use some combination of Computer Hardware and software. Enterprise development is any application, set of Systems and sub systems developed for the use of a particular company. Once the decision is made to develop an application, a suitable platform for its development has to be decided. Java 2 Enterprise Edition Java 2, specifically the Enterprise Edition is the most preferable platform selected for the development of Enterprise related software. Java is not restricted to any one medium, domain or technology. J2EE helps in development of secure, scalable and platform independent business solutions. In a Client Server Environment, J2EE provides the framework required for the successful development and deployment of enterprise related software. J2EE is a combination of several technologies like Servlets, Java Server Pages (JSP) and Enterprise Java Beans (EJB’s) that offers a cohesiveness to bond together server side systems and services and produce an industrial strength scalable environment within which web-centric applications can thrive. J2EE simplifies the creation of an enterprise-wide application, because functionality is encapsulated in components of J2EE. This enables designers and programmers to organize the
application into functionality that is distributed across the server-side components built using J2EE. The J2EE technology stack is a shining example of a standard-based approach that works. Look no further than the number of J2EE applications deployed today to validate its success.
Servlets Just like an applet is a client –side program, a servlet is a server side program, written in java, that is dynamically extends the functionality of a server. Similar to the manner in which applets run inside a web browser on the client, Servlets execute inside Apache Tomcat on the server. Unlike applets, Servlets do not display a Graphical Interface to the user. A servlet work is done “behind the scenes” on the server and only the Servlets processing are returned to the client. This is the latest technology from Sunsoft, completely written in java, and is a replace to the CGI implementation with a language (like PERL). It is similar to ASP from Microsoft. Servlets need Apache Tomcat software to run. The latest version Apache contains JSP which is inbuilt. Servlets support to servers can be obtained by implementing the servlet software by Servlet Development Kit (SDK) from Sun. How Servlet works? Servlets are framed to implement the request/response paradigm (pattern). For example: When a browser sends a request to the server, the server may forward the request to a servlet (servlet is request software working inside the server itself). At this point, the servlet process the request (through the database access or any other means) and constructs an appropriate response (answer) that is returned (usually in HTML format) to the client. Servlet is easy to learn as we need not learn any new language like Perl because Servlets are written in pure Java language. If the person knows the syntax and how to use interfaces and methods of Java, it is more than enough. A preliminary touch with HTML is necessary because request/response with Servlet is in HTML format. Servlet Architecture:
The rise of servlet-side java applications is one of the latest and most exciting trends in Java programming. The Java language was originally intended for use in small, embedded devices. It was first hyped as a language for developing elaborate client- side web content in the form of applets. Until recently, Java’s potential as a server-side development platform had been sadly overlooked. Now Java is coming into its own as a language ideally suited for server-side development. Java Servlets are the key components of server-side Java development. A Servlet is a small, pluggable extension to a server that enhances the server’s functionality. Servlets allow developers to extend and customize any Java-enabled server-a web server, a mail server, an application server, or any custom server—with a hitherto unknown degree of portability, flexibility and ease. A servlet is a generic server extension—a Java class that can be loaded dynamically to expand the functionality of a server. Servlets are commonly used with web servers. A Servlet is similar to a proprietary server extension; except that it runs inside a Java Virtual Machine (JVM).Servlets operate solely within the domain of the server: unlike applets, they do not require support for Java in the web browser. Another advantage of Servlets is that they are portable: both across operating systems as we are used to with Java and also across web servers. All the major web servers support Servlets. Java Servlets offer the best possible platform for web application development Servlet API is optimized for Hyper Text Transfer Protocol (HTTP)
Structure of Servlet: The basic structure of Servlet is nothing but the structure of any Java application. We will notice some new methods, interfaces and exceptions. A simple Java program becomes a Servlet when it expands either GenericServlet or its subclass HTTPServlet (like a Java program becomes applet when extends Applet). By doing so, the Java program (now, it is servlet), attains some default functionality o a servlet. The method that we generally override is service () method is a servlet. The method that we generally override is service () method is called by the server automatically when a request is made by the client. Service () method is a general all-purpose method which can be replaced, at the fancy of the developer, by more specific methods like doGet () or doPost ().
Life Cycle of Servlet: The process of creating, invoking and destroying a servlet is known Servlet Lifecycle. These methods that involve life cycle are init (), service () and destroy ().
Init (): This method is called first time when the servlet is loaded. It is similar to a class constructor where initialization code is guaranteed to run. Init () method is where the Servlets life cycle begins. It is called by the server immediately after the servlet is loaded. The servlet creates and initializes any resources including data members that are used in the program. This method returns nothing.
Public abstract void init (ServletConfig config) throws ServletException
Service (): This method is to be overridden by the Servlets to obtain custom functionality. The method that is automatically called by the server in response to a client request is called service () method.
Public abstract void service (ServletRequest req, ServletResponse res) Throws ServletException, IOException
The service () method handles all the requests sent by the client. This is called by default after the execution of the init () method. The service method implements a request or response paradigm. The ServletRequest object (here req) object contains the information sent by the client to the server and ServletResponse (here res) contained the information to be sent to the client by the server.
Destroy (): This method is executed when the servlet is unloaded. It is used to free any resources held by the servlet. Public abstract void destroy () Destroy () method signifies the end of the servlet’s life. It is called by the server when the servlet is unloaded. Should be used to free any resources (like closing of any database connection) held by the servlet. This method returns nothing. Java Servlet API: All the classes and interfaces required to create and execute Servlets are contained within two packages javax.servlet and javax.servlet.http. These two packages put together are known as Java Servlet API and is supplied with Suns’s Java Servlet Development Kit (JSDK). Most commonly used classes are: • • • • • • Http Servlet class Generic Servlet class ServletRequest class HttpServletRequest interface ServletResponse interface HttpServletResponse interface
HttpServlet class: Most HTTP Servlets extend this class. HttpServlet defines methods that are called by the server whenever a servlet request is received. HttpServlet is a subclass of GenericServlet. GenericServlet class:
Most non-HTTP Servlets extend this class. GenericServlet overrides the service () method that is called by the server whenever a servlet request is received. Steps to run Servlet: 1. 2. 3. Compile the program using javac command and obtain a .class file. Copy this file to the classes’ folder in Apache Tomcat. Start the tomcat and this be returned in the background always as long as the servlet is running. Now run the servlet in the browser.
In Servlets once you change the values in the file then one must again save and compile and keep the .class file in the classes’ folder of Apache Tomcat web server. DoGet () and doPost (): DoGet () and doPost () methods are identical. The only difference is the request they service. DoPost are used for request and doGet () for response instead of the general method service (). The parameters of these specific methods are the same as service () method. The doGet () method handles GET requests (of HTML) and doPost () method handles POST requests (of HTML) Redirect: An HTTP redirect is a set of instructions included in the header of an HTTP response that instructs the browser to issue a new request to a new URL. We use redirect in a web as a common phenomenon and is useful in many circumstances. HYPER TEXT TRANSFER PROTOCOL HTTP is a simple, stateless protocol. In a client Server Environment, a client such as a web browser makes a request, the web server responds, and the transaction is done. When the client sends a request, the first thing it specifies is an HTTP command, called method, which tells the server the type of action it wants performed. This first line of the request also specifies the address of a document (a URL) and the version of the HTTP protocol it is using. When the client connects to a server and makes an HTTP request, the request can be of several different types, called methods. The most frequently used methods are GET and POST. Put simply, the GET method is designed for getting information, while the POST method is designed for posting information that is to be stored in a database JDBC
The Java DataBase connectivity is a set of java classes that provide connectivity to relational databases. We can use JDBC from java programs to access almost every SQL database like Oracle, Sybase, DB2, SQL server, Access and FoxBASE, etc. JDBC drivers are available from Symantec, Intersolve, IBM, javasoft and Borelan/Visigenic etc., with little effort we can connect to database. Origin of JDBC: JDBC is not a new query language. It is a simply a java object interface (communication) to SQL. Our applications use JDBC to forward SQL statements to a DBMX. We write SQL statements in a java program to perform database queries and updates. We can think of JDBC as just a java SQL wrapper. JDBC does not enhance or diminish the power of SQL. It’s simply a mechanism for submitting SQL statements. JDC can handle easily the manipulations like connecting to a database, retrieving query results, committing or rolling back transactions. JDBC is based on the X/Open SQL CLI (Call Level Interface), which is also the basis for Microsoft’s ODBC interface. The CLI is not a new query language. It is simply a procedural interface to SQL. JDBC Drivers: JDBC drivers are either direct or ODBC bridged direct driver sits on top of the DBMS’s native interface. For example, Symantec provides direct drivers for Oracle 7.X using ODBC. IBM also provides a native JDBC driver for its DB2 products direct means no transactions will be done between a JDBC program and the database. This will be faster and used in real-time environment. In contrast to direct drivers, bridged drivers are built on the top of existing ODBC drivers. JDBC is created after ODBC. Consequently, there exists a translation between these the two protocols. These types of bridge drivers are slow in communication. Java Soft and Intersolve provide JDBC to ODBC bridge drivers that make it easier to translate between JDBC and the various ODBC drivers. As a result, the JDBC applications, we write are guaranteed to be portable across multi vendor DBMS. That is, a JDBC program is both platform-independent and data-base-independent.
All the classes and interfaces required for writing a JDBC program are included in java.sql package. The java.sql package is supplied with the core jdk software itself. JDBC drivers provide implementation for these classes and interfaces of java.sql package. The other responsibility of drivers is to maintain transaction reliability. The drivers must provide the required synchronization protection. Java Database Connectivity (JDBC)
JDBC is a set of classes and Interface used for the purpose of connecting to a database using applications developed in Java language. To get a connection with the database, a Driver, hich is the implementation of JDBC API loaded. This driver is used to create a Statement, which is an object used to execute SQL queries. Result of a statement is stored as ResultSet.
JDBC
Architecture
JAVA Application
JAVA Application
JAVA Application
JDBC DRIVER MANAGER
JDBC TO ODBC
DRIVER
Sybase
Oracle
DRIVER ODBC DRIVER
DRIVER
MS SQL
SQL
Oracle
SERVER
DRIVER
DATABASE
Web Service Web services can be defined as loosely coupled software components delivered over IP networks. The primary objective of Web services is to simplify and standardize application interoperability within and across companies, leading to increased operational efficiencies and tighter partner relationships.
11.3 MYSQL MySQL is a relational database management system (RDBMS) which has more than 11 million installations. The program runs as a server providing multi-user access to a number of databases. MySQL is owned and sponsored by a single for-profit firm, the Swedish company MySQL AB, now a subsidiary of Sun Microsystems, which holds the copyright to most of the codebase. The project's source code is available under terms of the GNU General Public License, as well as under a variety of proprietary agreements. "MySQL" is officially pronounced (My S Q L), not "My sequel". This adheres to the official ANSI pronunciation; SEQUEL was an earlier IBM database language, a predecessor to the SQL language. However, the company does not take issue with the pronunciation "My sequel" or other local variations. MySQL is popular for web applications and acts as the database component of the LAMP, BAMP, MAMP, SAMP, and WAMP platforms (Linux/BSD/Mac/(Open)Solaris/WindowsApache-MySQL-PHP/Perl/Python), and for open-source bug tracking tools like Bugzilla. Its popularity for use with web applications is closely tied to the popularity of PHP, which is often combined with MySQL. Several high-traffic web sites (including Flickr, Facebook Wikipedia, Google, Nokia and YouTube) use MySQL for its data storage and logging of user data. The MySQL Administrator in Linux MySQL is written in C and C++. The SQL parser uses yacc and a home-brewed lexer.[9][not
citation given] in
MySQL works on many different system platforms, including AIX, BSDi, FreeBSD, HPUX, i5/OS, Linux,MacOSX, NetBSD, Novell NetWare, OpenBSD, OpenSolaris, eComStation , OS/2 Warp, QNX, IRIX,Solaris, Symbian, S
unOS, SCO OpenServer, SCO UnixWare, Sanos, Tru64 and Microsoft Windows. A port of MySQL to OpenVMS is also available. Libraries for accessing MySQL databases are available in all major programming languages with language-specific APIs. In addition, an ODBC interface called MyODBC allows additional programming languages that support the ODBC interface to communicate with a MySQL database, such as ASP or ColdFusion. The MySQL server and official libraries are mostly implemented in ANSI C/ANSI C++. To administer MySQL databases one can use the included command-line tool (commands: mysql and mysqladmin). Also downloadable from the MySQL site are GUI administration tools: MySQL Administrator and MySQL Query Browser. Both of the GUI tools are now included in one package called tools/5.0.html MySQL GUI Tools. In addition to the above-mentioned tools developed by MySQL AB, there are several other commercial and non-commercial tools available. Examples include SQLyog Community Edition, a free desktop based GUI tool and phpMyAdmin, a free Web-based administration interface implemented in PHP.
11.4 FLEX4 Flex is for developing internet and desktop applications. It is a MXML and Action Script-based application development for Flash Player FLEX = MXML+ACTIONSCRIPT. MXML is an XML language that you use to lay out the user interface for Flex applications. MXML provides tags that correspond to classes in the Flex framework. Action Script is the Object Oriented programming language for Flash Player. Action Script (which is based on ECMAScript and is similar to JavaScript) provides flow control and object manipulation features that are not available in MXML. Rich Internet Application(s) A Rich Internet Application (RIA) is an application that runs in the traditional browser but utilizes an intermediate layer. The Intermediate layer contains Flash Player. Rich interfaces use advanced UI controls like trees, tabs and context menus. They provide advanced means of interaction such as drag-and-drop of UI elements. RIAs developed using sound architectural principles and best practices can also greatly increase the
maintainability of an application, as well as greatly reduce the development time to build the application. RIA is possible with flashplayer9 Benefits of developing the applications using Flex.
Enhanced user experience : Flex lets you build applications that provide an engaging user experience. An engaging user experience ensures that customers are drawn into your application, that they understand how to use it, and that they can more quickly complete a task or find the information they are seeking. A complete environment : Flex is a powerful application development solution for creating and delivering RIAs within the enterprise and across the web. It provides a modern, standards based language and programming model that supports common design patterns and includes a highly productive IDE.
Common deployment environment : Flex applications execute on Flash Player 9, which is platform independent, so customers do not need to install custom client software. Also, Flash Player runs consistently in all browsers and platforms, so you do not have to worry about inconsistent behavior in different client environments. Eliminate page loads: Applications running in Flash Player behave like desktop applications, instead of a series of linked pages. Flash Player manages the client interface as a single, uninterrupted flow and does not require a page load from the server when the client moves from one section of the application to another. Client-side processing of user input, including filtering and data validation: Flex data management, which includes data models, data validators, data binding, and data services, lets the user to separate data representation from the way that a user views it. Typically, this design pattern is called Model-View-Controller (MVC). Flex is for developing Internet Applications i.e. Flex applications result in front ends that have “rich”. Web applications have many benefits over desktop applications; they can reach a larger audience. However, Internet applications are not always as "rich" and user-friendly as traditional desktop applications. With Flex, Internet applications can be made richer and more user-friendly.
While Flex applications run in a browser, they take advantage of the Flash Player 9 runtime environment for executing client-side logic, rendering graphics, and playing animation, audio, or video. When the Application is compiled using flex2SDK, it will convert to SWF file, the generated SWF file can be copied in to a directory on the web server or application server the deployed SWF file can be accessed by making an HTTP request in the form: http://hostname/path/filename.swf When a request is made to an SWF file, typically the SWF file is incorporated into a web page by using a wrapper. The wrapper is responsible for embedding the Flex application’s SWF file in a web page. Flex programming model Flex applications are written using a combination of MXML and Action Script. The MXML and Action Script programming languages both give the ability to access the Flex class library. MXML to declaratively define the application user interface elements and the Action Script is used to define client logic and procedural control. Flex application communication with the remote services The MXML components that provide data accesses are called data service components. MXML includes the following types of data service components: Web Service provides access to SOAP-based web services. HTTP Service provides access to HTTP
•
12. Testing:
A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected. This is a non-trivial pursuit. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.
Defects and failures Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirements gaps, e.g., unrecognized requirements that result in errors of omission by the program designer. A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security. Software faults occur through the following process. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. Not all defects will necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new hardware platform, alterations in source data or interacting with different software. A single defect may result in a wide range of failure symptoms. Compatibility A frequent cause of software failure is compatibility with another application or new operating system (or, increasingly web browser version). In the case of lack of backward compatibility this can occur because the programmers have only considered coding the programs for, or testing the software, on the latest operating system they have access to or else, in isolation (no other conflicting applications running at the same time) or under 'ideal' conditions ('unlimited' memory; 'superfast' processor; latest operating system incorporating all updates, etc). In effect, everything is running "as intended" but only when executing at the same time on the same machine with the particular combination of software and/or hardware. These are some of the hardest failures to predict, detect and test for and many are therefore discovered only after release into the larger world with its largely unknown mix of applications, software and hardware. It is likely that an experienced programmer will have had exposure to these factors through "co-evolution" with several older systems and be much more aware of potential future compatibility problems and therefore tend to use tried and tested functions or instructions rather than always the latest available which may not be fully compatible with earlier mixtures of software/hardware. This could be considered a prevention oriented strategy that fits well with the latest testing phase suggested by Dave Gelperin and William C. Hetzel cited below. Input combinations and preconditions A problem with software testing is that testing under all combinations of inputs and preconditions (initial state) is not feasible, even with a simple product. This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, non-functional dimensions of quality (how it is supposed to be versus what it is supposed to do) -- for example, usability, scalability, performance, compatibility, reliability -- can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another. Static vs. dynamic testing
There are many approaches to software testing. Reviews, walkthroughs or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. The former can be, and unfortunately in practice often is, omitted, whereas the latter takes place when programs begin to be used for the first time - which is normally considered the beginning of the testing stage. This may actually begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). For example, Spreadsheet programs are, by their very nature, tested to a large extent "on the fly" during the build process as the result of some calculation or text manipulation is shown interactively immediately after each formula is entered. Software verification and validation Software testing is used in association with verification and validation:
•Verification:
Have we built the software right (i.e., does it match the specification?)? It is process based. • Validation: Have we built the right software (i.e., is this what the customer wants?)? It is product based. The software testing team Software testing can be done by software testers. Until the 1950s the term "software tester" was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing there have been established different roles: test lead/manager, test designer, tester, test automater/automation developer, and test administrator.
Software Quality Assurance (SQA) Though controversial, software testing may be viewed as an important part of the software quality assurance (SQA) process. In SQA, software process specialists and auditors take a broader view on software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in defect rate. What constitutes an acceptable defect rate depends on the nature of the software. An arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than mission critical software such as that used to control the functions of an airliner. Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies. Software Testing is a task intended to detect defects in software by contrasting a computer program's expected results with its actual results for a given set of inputs. By contrast, QA is the implementation of policies and procedures intended to prevent defects from occurring in the first
Testing methods Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. Black box testing Black box testing treats the software as a black box without any knowledge of internal implementation. Black box testing methods include equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing. Specification-based testing Specification-based testing aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Specification-based testing is necessary but insufficient to guard against certain risks. Advantages and disadvantages The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code MUST have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers don't. BUT, on the other hand, black box testing is like a walk in a dark labyrinth without a flashlight, because the tester doesn't know how the back end was actually constructed. That's why there are situations when 1. A black box tester writes many test cases to check something that can be tested by only one test case and/or 2. Some parts of the back end are not tested at all Therefore, black box testing has the advantage of an unaffiliated opinion on the one hand and the disadvantage of blind exploring on the other. White box testing White box testing, by contrast to black box testing, is when the tester has access to the internal data structures and algorithms (and the code that implement these) Types of white box testing The following types of white box testing exist:
• •
•
api testing - Testing of the application using Public and Private APIs. code coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once. fault injection methods.
• •
mutation testing methods. static testing - White box testing includes all static testing.
Code completeness evaluation
White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Two common forms of code coverage are:
•
Function coverage, which reports on functions executed and statement coverage, which reports on the number of lines executed to complete the test.
They both return coverage metric, measured as a percentage. Grey Box Testing In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey-box because the input and output are clearly outside of the black-box we are calling the software under test. This is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages. Acceptance testing Acceptance testing can mean one of two things:
1. A smoke test is used as an acceptance test prior to introducing a build to the main testing
process. 2. Acceptance testing performed by the customer is known as user acceptance testing (UAT). Regression Testing Regression testing is any type of software testing that seeks to uncover software regressions. Such regressions occur whenever software functionality that was previously working correctly stops working as intended. Typically regressions occur as an unintended consequence of program changes. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. Non Functional Software Testing Special methods exist to test non-functional aspects of software.
•
• • •
Performance testing checks to see if the software can handle large quantities of data or users. This is generally referred to as software scalability. This activity of Non Functional Software Testing is often times referred to as Load Testing. Usability testing is needed to check if the user interface is easy to use and understand. Security testing is essential for software which processes confidential data and to prevent system intrusion by hackers. Internationalization and localization is needed to test these aspects of software, for which a pseudo localization method can be used.
In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements), non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing is an example of non-functional testing. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as error-handling routines. Various commercial non-functional testing tools are linked from the Software fault injection page; there are also numerous open-source and free software tools available that perform non-functional testing. Testing process A common practice of software testing is performed by an independent group of testers after the functionality is developed before it is shipped to the customer. This practice often results in the testing phase being used as project buffer to compensate for project delays, thereby compromising the time devoted to testing. Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes. In counterpoint, some emerging software disciplines such as extreme programming and the agile software development movement, adhere to a "test-driven software development" model. In this process unit tests are written first, by the software engineers (often with pair programming in the extreme programming methodology). Of course these tests fail initially; as they are expected to. Then as code is written it passes incrementally larger portions of the test suites. The test suites are continuously updated as new failure conditions and corner cases are discovered, and they are integrated with any regression tests that are developed. Unit tests are maintained along with the rest of the software source code and generally integrated into the build process (with inherently interactive tests being relegated to a partially manual build acceptance process). Testing can be done on the following levels:
•
•
Unit testing tests the minimal software component, or module. Each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors. Integration testing exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components
• •
corresponding to elements of the architectural design are integrated and tested until the software works as a system. System testing tests a completely integrated system to verify that it meets its requirements. System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.
Before shipping the final version of software, alpha and beta testing are often done additionally:
•
•
Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-theshelf software as a form of internal acceptance testing, before the software goes to beta testing. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.
Finally, acceptance testing can be conducted by the end-user, customer, or client to validate whether or not to accept the product. Acceptance testing may be performed as part of the handoff process between any two phases of development.
Regression testing After modifying software, either for a change in functionality or to fix defects, a regression test re-runs previously passing tests on the modified software to ensure that the modifications haven't unintentionally caused a regression of previous functionality. Regression testing can be performed at any or all of the above test levels. These regression tests are often automated. More specific forms of regression testing are known as sanity testing, when quickly checking for bizarre behavior, and smoke testing when testing for basic functionality. Benchmarks may be employed during regression testing to ensure that the performance of the newly modified software will be at least as acceptable as the earlier version or, in the case of code optimization, that some real improvement has been achieved. Testing Tools Program testing and fault detection can be aided significantly by testing tools and debuggers. Types of testing/debug tools include features such as:
•
Program monitors, permitting full or partial monitoring of program code including:
o
Instruction Set Simulator, permitting complete instruction level monitoring and trace facilities Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code code coverage reports Formatted dump or Symbolic debugging, tools allowing inspection of program variables on error or at chosen points Benchmarks, allowing run-time performance comparisons to be made Performance analysis, or profiling tools that can help to highlight hot spots and resource usage Some of these features may be incorporated into an integrated development environment (IDE). Measuring software testing Usually, quality is constrained to such topics as correctness, completeness, security,[citation needed] but can also include more technical requirements as described under the ISO standard ISO 9126, such as capability, reliability, efficiency, portability, maintainability, compatibility, and usability. There are a number of common software measures, often called "metrics", which are used to measure the state of the software or the adequacy of the testing. Testing artifacts Software testing process can produce several artifacts. Test case A test case in software engineering normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps (also known as actions) to follow, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected result. This can be as pragmatic as 'for condition x your derived result is y', whereas other test cases described in more detail the input scenario and what results might be expected. It can occasionally be a series of steps (but often steps are contained in a separate test procedure that can be exercised against multiple test cases, as a matter of economy) but with one expected result or expected outcome. The optional fields are a test case ID, test step or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repository. In a database system, you may also be able to see past test results and who generated the results and the system configuration used to generate those results. These past results would usually be stored in a separate table. Test script
o o • • •
The test script is the combination of a test case, test procedure, and test data. Initially the term was derived from the product of work created by automated regression test tools. Today, test scripts can be manual, automated, or a combination of both. Test data The most common test manually or in automation is retesting and regression testing, In most cases, multiple sets of values or data are used to test the same functionality of a particular feature. All the test values and changeable environmental components are collected in separate files and stored as test data. It is also useful to provide this data to the client and with the product or a project. Test suite The most common term for a collection of test cases is a test suite. The test suite often also contains more detailed instructions or goals for each collection of test cases. It definitely contains a section where the tester identifies the system configuration used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests. Test plan A test specification is called a test plan. The developers are well aware what test plans will be executed and this information is made available to the developers. This makes the developers more cautious when developing their code. This ensures that the developers code is not passed through any surprise test case or test plans. Test harness The software, tools, samples of data input and output, and configurations are all referred to collectively as a test harness. Software testing certification types Certifications can be grouped into: exam-based and education-based. Exam-based certifications: For these there is the need to pass an exam, which can also be learned by self-study: e.g. for ISTQB or QAI. • Education-based certifications: Education based software testing certifications are instructor-led sessions, where each course has to be passed, e.g. IIST (International Institute for Software Testing).
•
Testing certifications
• • • •
CATE offered by the International Institute for Software Testing CBTS offered by the Brazilian Certification of Software Testing (ALATS) Certified Software Tester (CSTE) offered by the Quality Assurance Institute (QAI) Certified Software Test Professional (CSTP) offered by the International Institute for
Software Testing
•
CSTP (TM) (Australian Version) offered by K. J. Ross & Associates
ISEB offered by the Information Systems Examinations Board ISTQB Certified Tester, Foundation Level (CTFL) offered by the International Software Testing Qualification Board • ISTQB Certified Tester, Advanced Level (CTAL) offered by the International Software Testing Qualification Board • CBTS offered by the Brazilian Certification of Software Testing (ALATS) • TMPF Next Foundation offered by the Examination Institute for Information Science
• •
Quality assurance certifications
• • • •
CSQE offered by the American Society for Quality CSQA offered by the Quality Assurance Institute CQIA offered by the American Society for Quality CMSQ offered by the Quality Assurance Institute
Controversy Some of the major software testing controversies include: What constitutes responsible software testing? Members of the "context-driven" school of testing believe that there are no "best practices" of testing, but rather that testing is a set of skills that allow the tester to select or invent testing practices to suit each unique situation. Agile vs. traditional Should testers learn to work under conditions of uncertainty and constant change or should they aim at process "maturity"? The agile testing movement has received growing popularity since 2006 mainly in commercial circles, whereas government and military software providers are slow to embrace this methodology, and mostly still hold to CMMI. Exploratory test vs. scripted Should tests be designed at the same time as they are executed or should they be designed beforehand? Manual testing vs. automated Some writers believe that test automation is so expensive relative to its value that it should be used sparingly. Others, such as advocates of agile development, recommend automating 100% of all tests.[citation needed] More in particular, test-driven development states that developers should write unit-tests of the x-unit type before coding the functionality. The tests then can be considered as a way to capture and implement the requirements. Software design vs. software implementation Should testing be carried out only at the end or throughout the whole process? Who watches the watchmen? The idea is that any form of observation is also an interaction that the act of testing can also affect that which is being tested.
Output screenshots
1.LoginPage(Manager,Operator,Analyzer,Technician)
2.Operator HomePage
3.Manager Home Page
4.Employee Registration (Analyzers and Technicians)
5.AllocateWork To Analyzers
6.AnalyzerHome (will allocate work to technician)
6.Send Acknowledgement
7.TechnicianHome Page
8.Techincian Fault Report
13 Conclusions:
Service Developers want the Service Providers to ensure or provide the capability to dynamically allocate and manage resources in response to changing demand patterns. It is now possible to
provide dynamic visibility and control of services management to meet the rapidly growing demand for Amazon Web Service. This software is developed using Flex as front end, Dot net as middle ware and Sql server as backend. The goals that are achieved by the software are:
• • • • • • • •
Instant Access Improved Productivity Optimum Utilization of resources Efficient management of records Simplification of the operations Less processing time and required information User Friendly Portable and flexible for further enhancements.
Intensive care has been taken by the development team to meet all the requirements of the client. Each module has undergone stringent testing procedures and the integration testing activity has been performed by the team leaders of each module. After completion, execution and successful demonstration, we confirm that the Product has reached client requirements and is ready for launch. Finally we conclude that the project stands up in maintaining its sole motive of betterment to the society and work for a social cause.
14 Future Enhancements:
It is not possible to develop a system that makes all the requirements of the user .user requirements keep changing as the system is being used. Some of the future enhancements that can be done to this system are: 1) The System can be enhanced to increase look and feel of the Application. 2) Will try to scale the application.
15. References
The Unified Modeling Language Users guide By Grady Booch Software Engineering, A practitioners approach By Roger S Pressman
Software Project Management By Walker Royce The applicable IEEE standards as published in ‘IEEE standards collection, for the preparation of SRS’. Backup policy, Naming Conventions as per Teleparadigm Conventions.
Fault management system on cloud
<mm dd yyyy>
<Version 1.0.0>
Contents
Table of Contents
1.
Introduction ………………………………………………………………
2. Phases ……………………………………………………………………. 2.1 Module 1 2.2 Module 2 2.3 Module 3 3. Purpose …………………………………………………………………… 3.1 Scope 4. Application, Objective and Benefits …………………………………….. 5. UML …………………………………………………………………….. 5.1 Structural Diagrams 5.2 Deployment Diagrams 5.3 Behavioral Diagrams 5.4 Sequence Diagrams 5.5 Collaboration Diagrams 5.6 State chart Diagrams 6. Architecture Diagram ……………………………………………………. 7. Database …………………………………………………………………. 8. User Interface …………………………………………………………… 9. Software Requirement Specification (SRS) 9.1 Overview ……………………………………………………………
9.2 Product Perspective ………………………………………………... 9.3 System Interfaces ………………………………………………….. 9.3.1 User Interface ………………………………………………… 9.3.2 Hardware interface …………………………………………… 9.3.3 Software Interfaces …………………………………………… 9.3.4 Memory Constraints ………………………………………….. 9.4 Product Functions …………………………………………………… 9.5 User Characteristics …………………………………………………. 9.6 Constraints …………………………………………………………… 9.7 Logical Database Requirements ……………………………………… 9.8 Design Constraints …………………………………………………… 9.9 Standard Compliance ………………………………………………… 9.10 Reliability …………………………………………………………... 9.11 Availability …………………………………………………………. 9.12 Security ……………………………………………………………. 9.13 Maintainability ……………………………………………………... 9.14 Portability ………………………………………………………….. 9.15 System Mode ………………………………………………………. 9.16 Supporting Information …………………………………………… 9.17 Document Control ………………………………………………… 9.18 Appendix A ……………………………………………………… 9.19 Specific Requirements …………………………………………….. 9.20 Performance requirements …………………………………………. 9.21 Software System Attributes ……………………………………….. 9.22 Features ……………………………………………………………..
9.23 Objects …………………………………………………………….. 9.24 Stimulus …………………………………………………………… 9.25 Response …………………………………………………………… 9.26 Functional Hierarchy ………………………………………………. 9.27 Additional Comments ……………………………………………… 10. Programming Code ………………………………………………………… 11.Technology Features ……………………………………………………….
11.1 JAVA
Technology ………………………………………………….
11.2 SQL Server …………………………………………………………… 11.3 FLEX4 …………………………………………………………….. 12. Testing ……………………………………………………………………… 12.1 Black Box Testing 12.2 White Box Testing 12.3 Security Testing 12.4 Compatibility Testing 13. Conclusions ……………………………………………………………… 14. Future Enhancements ……………………………………………………… 15. References …………………………………………………………………..
1. Introduction:
Cloud computing is a technology that uses the internet and central remote servers to maintain data and applications. Cloud computing allows consumers and businesses to use applications without installation and access their personal files at any computer with internet access. This technology allows for much more efficient computing by centralizing storage, memory, processing and bandwidth. Cloud computing is broken down into three segments: applications, platforms and infrastructure. Amazon Web Services provides virtual server instances managed through a web service API with unique IP addresses and host names assigned dynamically and blocks of storage on demand. Customers use the provider's application program interface (API) to start, stop, access and configure their virtual servers and storage.
Definition: Cloud Computing:
Cloud computing is a general term for anything that involves delivering hosted services over the Internet. These services are broadly divided into three categories: Infrastructure-as-a-Service Platform-as-a-Service and Software-as-a-Service .
Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. Amazon EC2’s simple web service interface allows you to obtain and configure capacity with minimal friction. It provides you with complete control of your computing resources and lets you run on Amazon’s proven computing environment. Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change. Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use. Amazon EC2 provides developers the tools to build failure resilient applications and isolate themselves from common failure scenarios.
Amazon EC2 Functionality Amazon EC2 presents a true virtual computing environment, allowing you to use web service interfaces to launch instances with a variety of operating systems, load them with your custom application environment, manage your network’s access permissions, and run your image using as many or few systems as you desire. To use Amazon EC2, you simply:
•
Create an Amazon Machine Image (AMI) containing your applications, libraries, data and associated configuration settings. Or use pre-configured, template images to get up and running immediately. Upload the AMI into Amazon S3. Amazon EC2 provides tools that make storing the AMI simple. Amazon S3 provides a safe, reliable and fast repository to store your images. Use Amazon EC2 web service to configure security and network access. Choose which instance type(s) and operating system you want, then start, terminate, and monitor as many instances of your AMI as needed, using the web service APIs or the variety of management tools provided. Determine whether you want to run in multiple locations, utilize static IP endpoints, or attach persistent block storage to your instances. Pay only for the resources that you actually consume, like instance-hours or data transfer.
•
• •
•
•
2 Phases:
Modules
Module-1: The first module is designed to provide authentication to individuals who wish to
get connected. The registration details are stored in the database and whenever the user logs in, the user credentials are retrieved to check whether the user is an authorized user or not. The front end is designed using Flex. Module2: In this module the error is reported by the customer a ticket is generated for the fault. Manager views the faults, escalates the faults to available analyzer or technicians. He
monitors the fault management system. He maintains error log and keep track of the problem and person who is working on it. Module-3: In this module Analyzer and Technicians solve the problems allocated by the manager depending on the location from where the error encountered and generate reports after rectifying them. Module-4: In this module administrator maintains error log and keep track of the problem and person who is working on it. Module-5: In this module we will deploy entire application in Amazon Elastic Compute Cloud (EC2) of Amazon Web Service
3. Purpose:
Today Fault Management System is a key part in Network Management Architecture consists of functions such as detect, isolate, determine the cause and correct the malfunctions in network. Fault Management System helps in increasing network availability, reduce network downtime and restore network failure quickly. In this project once error is reported, first step is to detect the fault and make a report of it. Based on this report we will isolate the fault i.e. to find the exact location of the fault and to determine the cause of the fault. Once isolated the fault need to be corrected and appropriate action need to be taken and report is send to administrator. The administrator will maintain error logs and keep track of the person who works on the fault. Finally the entire application is deployed on cloud.
Scope:
•
The Scope of the project is the vendor need not maintain their own fault management system. They can use centralized fault management system which would help them reducing overall cost.
•
Application, Objective and Benefits: • Application:
The application will be utilized by the Users.
•Goal:
The Web Site is intended to avoid server failure, virus attack and decrease the infrastructure costs, maintenance costs occurred to maintain the application .
•Objective:
. 1. Manage the application on cloud
2. 3. 4. 5.
Creating a User Interface for Fault management system on cloud The process involves Registration, Authentication and operator will get the complaint. This application or the UI is converted into Amazon Machine Image(AMI) Deploying the AMI on the Amazon Cloud
•Benefits:
a) No extra maintainenace cost incurred. The application will be maintained by the cloud. b) No need to of extra infrastructure cost. c) Avoid virus attack d) No server failure. 5. UML: Design Patterns brought a paradigm shift in the way object oriented systems are designed. Instead of relying on the knowledge of problem domain alone, design patterns allow past experience to be utilized while solving new problems. Traditional object oriented design (OOD) approaches such as Booch, OMT, etc. advocated identification and specification of individual objects and classes. Design Patterns on the other hand promote identification and specification of collaborations of objects and classes. However, much of the focus of recent research has been towards identification and cataloging of new design patterns. The effort has been to assimilate knowledge gained from designing systems of the past, in various problem domains. The problem analysis phase has gained little benefit from this paradigm. Most projects still use traditional object oriented analysis (OOA) approaches to identify classes from the problem description. Responsibilities to those classes are assigned based upon the obvious description of entities given in the problem definition. Pattern Oriented Technique (POT) is a methodology for identifying interactions among classes and mapping them to one or more design patterns. However, this methodology also uses traditional OOA for assigning class responsibilities. As a result, its interaction oriented design phase (driven by design patterns) receives its input in terms of class definitions that might not lead to best possible design.
The missing piece here is the lack of an analysis method that can help in identifying class definitions and the collaborations between them which would be amenable to application of interaction oriented design. There are two key issues here. First is to come up with good class definitions and the second is to identify good class collaborations. It has been observed in that even arriving at good class definitions from the given problem definition is non-trivial. The key to various successful designs is the presence of abstract classes (such as an event handler) which are not modeled as entities in the physical world and hence do not appear in the problem description. In anticipating change has been proposed as the method for identifying such abstract classes in a problem domain. Another difficult task is related to assignment of responsibilities to entities identified from the problem description. Different responsibility assignments could lead to completely different designs. Current approaches such as Coad and Yourdon, POT etc. follow the simple approach of using entity descriptions in the problem statement to define classes and fix responsibilities. We propose to follow a flexible approach towards assigning responsibilities to classes so that the best responsibility assignment can be chosen. The second issue is to identify class collaborations. Techniques such as POT analyze interactions among different sets of classes as specified in the problem description. Such interacting classes are then grouped together to identify design patterns that may be applicable. However, as mentioned earlier, only the interactions among obvious classes are determined currently. Other interactions involving abstract classes not present in the problem or interactions that become feasible due to different responsibility assignments are not considered. We present some techniques that enable the designer to capture such interactions as well.
Interaction Based Analysis and Design
Top-down approach This approach is applicable to situations where the designer knows the solution to the given problem. It is true for problem domains that have well established high-level solutions and different implementations vary in low level details (for e.g. Enterprise Resource Planning (ERP) systems). Her main concern is to realize that solution in a way such that the implemented system has nice properties such as maintainability and reusability etc. To achieve this goal, the system designer selects appropriate design patterns that form the building blocks of her solution. Having obtained this design template (design type), she maps the classes and objects participating in those patterns to the entities of the problem domain. This mapping implicitly defines the responsibilities of various classes/objects that represent those entities. To help clarify the concept, consider a scenario where an architect is assigned the task of building a flyover. Flyover construction is an established science and the architect knows the solution to the problem. She starts by identifying component patterns such as road strip, support pillars, side railings and so on. Having done that, she maps the participating objects to actual entities in the problem domain. This would involve defining the length and width of the road strip based upon the space constraints specified in the problem. The height and weight of the pillars get decided based upon the load requirements specified. The entry and exit points get decided based upon the geography of the location and so on. This results in a concrete design
instance. Some new classes or objects, not existing in the domain model, may also have to be introduced for a successful instantiation of the design template. For instance, the problem domain may not model an abstract entity such as an event handler which may be a participant in some portion of the design template. Such generic classes/objects may be drawn from a common repository of utility classes. Interaction driven analysis phase here is simple since the interactions (in the form of design patterns) are already well established and directly obtained from the knowledge base. Bottom-up approach This approach is applicable in scenarios where interactions in the problem domain are not well understood and need to be discovered and explored. This situation is a fundamental problem faced by the designers of object oriented systems. It relates to the fact that objects oriented analysis (OOA) does not help much in creating a solution to the problem at hand. The analysis phase is mainly concerned with enhancing the understanding of the problem domain. This knowledge is then later used by a problem solving approach to come up with a solution possessing good design properties. As a result, at the end of the analysis phase the designer has a set of well defined components that need to be assembled together for realizing a solution. For instance, to build a route finder application the OOA phase helps in modeling the domain objects such as roads, vehicles, cities, addresses etc. but does not actually provide a solution for finding routes between two given addresses. This is similar to having various pieces of a jigsaw puzzle but the puzzle still needs to be solved. The problem in software systems is further complicated by the fact that there is generally no unique solution to a problem. There are always trade-offs at various stages and the resulting designs are a reflection of the choices made at those stages. In the jigsaw puzzle example this is similar to the situation where different sets of the same puzzle are available each differing from another in terms of the design of its component pieces. Some component designs may help in solving the puzzle faster and more efficiently than others. The bottom-up approach helps in such situations where the entities in the problem domain have been identified by traditional OOA techniques but multiple choices exist in terms of assigning responsibilities to those entities. Unlike top-down approach, the mapping of responsibilities to entities is not dictated by the design solution specified by the designer. Instead, the task of the designer here is to try various responsibility assignments and create an interaction specification involving those objects. The objective of this interaction driven analysis is to obtain an interaction specification that helps in arriving at a solution with best design characteristics possible. Having identified the entities in the domain, the starting point for the designer is to identify various alternatives available for assigning responsibilities to individual objects. Her domain knowledge helps her in this task. Given these alternatives for potential object definitions and standard utility objects (such as schedulers, event handlers etc.), the next step is to find compositions of these building blocks (i.e. interactions of these objects) that provide alternative solutions to the problem. This task is a non-trivial one especially when done manually. There are just too many combinations to be considered, for any human designer to obtain alternative solutions in a reasonable amount of time. We need to apply (semi-)automated software composition techniques based on some formal specification. Several such approaches have been recently investigated in the context of e-services. These include workflow based approaches and AI Planning based techniques. Other formal techniques for specifying composition include Petri-
net based models, automata-based models; temporal logics etc. from verification community and XQuery, XML constraint tools based techniques from data management community . The resulting candidate compositions (i.e. interaction specifications) then need to be compared with existing design patterns either manually or automatically. It is not beyond imagination to visualize that with advancement in automated composition techniques, new design patterns may get identified during this process. For instance, techniques such as Reinforcement Learning have resulted in new novel solutions in various domains such as playing Backgammon. In such a case, the resulting designs may need to be evaluated manually. The best design among the alternatives is then chosen for implementing the system.
Open Issues
Identifying interactions This is a crucial step in the analysis phase and the success of remaining phases depends on it. The issue here is to identify interactions which are not evident from the problem description but may hold the key to an efficient design solution. The bottom-up approach proposed in this paper takes a step in this direction but a lot more work is needed. The analysis method should be such that it is able to incorporate abstract classes such as event handlers, proxies etc. Moreover, current analysis methods map entities to responsibilities of individual classes in terms of services they provide and methods they invoke on other classes. However, an entity may be realized by a set of classes. For instance, an adapter class hides the interface of an adoptee class and they collectively provide the desired functionality. Similarly, an abstraction and its implementation provide a single functionality through separate classes resulting in increased maintainability. The analysis method needs to be able to determine when is it appropriate to realize an entity responsibility by means of multiple interacting classes. Representation of Class Responsibilities Since we need to specify different alternative class responsibilities, as in bottom-up approach, a mechanism is required to document them in a machine interpretable format. Some of these responsibilities would get captured in the form of methods a class exports or methods it invokes on other classes. However, other responsibilities with respect to its interaction with other classes need to be explicitly specified. These may include pre- and post-conditions for different method invocations, other properties such as ’hasSameInterfaceAs <another class>’, ’hidesInterfaceOf <another class>’ etc. Languages such as could be used as it is or extended for this purpose. Language for Specifying Design Patterns
The approaches for OO Design proposed in this paper favor automatic techniques over manual ones for reasons described earlier. This means that we need a mechanism to be able to express design patterns in a format amenable to be read and interpreted by programs. Some attempts have been made at defining such pattern description languages [14, 13]. One of these or some variation of these could be used to express design patterns in a formal language. Comparison of Software Designs Once we have alternative designs available, they need to be compared to arrive at the best one. Each design may consist of multiple design patterns. The criteria here would not be to simply count the number of design patterns used but to evaluate the interaction between patterns and also between other design elements used. This would involve an understanding of good and bad design interactions and an ability to identify them in a given design. The final challenge would be to do it automatically.
5.1 Structural Diagram Class Diagram:
Class diagrams identify the class structure of a system, including the properties and methods of each class. Also depicted are the various relationships that can exist between classes, such as an inheritance relationship. The Class diagram is one of the most widely used diagrams from the UML specification
Class Diagrams are given to depict interactions
Object Diagram:
Object diagrams model instances of classes. This type of diagram is used to describe the system at a particular point in time. Using this technique, you can validating the class diagram and it's multiplicity rules with real-world data, and record test scenarios. From a notation standpoint, Object diagrams borrow elements from Class diagrams.
Component Diagram:
Component diagrams fall under the category of an implementation diagram, a kind of diagram that models the implementation and deployment of the system. A Component Diagram, in particular, is used to describe the dependencies between various software components such as the dependency between executable files and source files. This information is similar to that within make files, which describe source code dependencies and can be used to properly compile an application.
5.2 Deployment Diagram:
Deployment diagrams are another model in the implementation diagram category. The Deployment diagram models the hardware used in implementing a system and the association
between those hardware components. Components can also be shown on a Deployment diagram to show the location of their deployment. Deployment diagrams can also be used early on in the design phase to document the physical architecture of a system.
5.3 Behavioral Diagrams: Use Case Diagram:
Use Case diagrams identify the functionality provided by the system (use cases), the users who interact with the system (actors), and the association between the users and the functionality. Use Cases are used in the Analysis phase of software development to articulate the high-level requirements of the system. The primary goals of Use Case diagrams include:
• • •
Providing a high-level view of what the system does Identifying the users ("actors") of the system Determining areas needing human-computer interfaces
Use Cases extend beyond pictorial diagrams. In fact, text-based use case descriptions are often used to supplement diagrams, and explore use case functionality in more detail.
Operator
Register Complain
Operator Send refno to customer
Send complain to concern admin
Administrator
C c aa bt h k vi l y e la i
Aoa Wk ll c t e o r Ami t a r d i sr t n o
E p y e eisr t n moe Rg t a l io
Analyzer
Sn Ak ed c
Ce k F u h c s a lt
U d te E o L g p a s rr r o Aa z r n ly e
E c la s F u s a te a lt
G n ra s R p rt e e te e o
Technician
S tart W ork
Tec hnic ian M ak e Reports after c om p work
Higher Authority
Check Escalation Report
Check Isolation Report
Higher Authority Check Technician Report
5.4 Sequence Diagram:
Sequence diagrams document the interactions between classes to achieve a result, such as a use case. The Sequence diagram lists objects horizontally, and time vertically, and models these messages over time.
OPERATOR
Operator userid, pwd
Login
CompReg
SendRefno
SendFlt
v alid
Complain registration Send refno
Send Fault to concern admin
Administrator
Admin Register Login Check availability Allocate Work Emp Regietration
Register
login
valid
Check availabilit y of person
Allocate work
Registers Employees
Analyzer
Analyzer Authentication Check Fault Send Acknowledgement Error Log Escalate Fault Report
login
valid
Check fault
Send Ack
Check error log based on fault
Escalate fault to H A
Send Isolation report to HA
5.5 Collaboration Diagram:
Collaboration diagrams model the interactions between objects. This type of diagram is a cross between an object diagram and a sequence diagram. It uses free-form arrangement of objects which makes it easier to see all iterations involving a particular object.
5.6 State chart Diagram:
State diagrams, are used to document the various modes ("state") that a class can go through, and the events that cause a state transition.
6. Architecture Diagram:
Cloud
7. Databases:
iii)DATABASE TABLES 1.Managers and operators
2.Employee Registration
3.Analyzer Work
4.Complaint Registration
5.Techinician Work
6.Technician work status
7.count the faults
8.Managers work
9.Fault Report
8. User Interface:
<Version 1.0.0>
Approvals Signature Block
Organization Responsibility Customer /customer representative
Signature
Date
Project Manager
Software Quality Assurance Leader Software Configuration Management Leader
User Documentation Leader
Student Name
User Training Leader
Faculty
Definitions, Acronym and Abbreviation
Term or Acronym Cloud Amazon Web Service
Definition A general term for anything that involves delivering hosted services over the Internet Cloud Service Provider
Table x. Definitions and Acronyms
9.1 Overall Description:
In today’s world each vendor has to maintain their own fault management system which increases the overall cost and maintenance for them. In this project we will overcome the above drawbacks by creating a centralized cloud based Fault Management System.
9.2 Product Perspective:
The project is a part of a large system. Block diagram: The major components of the larger system are shown as below.
9.3 System Interfaces:
Description of various interfaces used in the system is described in the subsequent paragraph.
9.3.1 User Interfaces:
Interface between the software product and its users:
User friendly interfaces as depicted below will be used.
1. Screen formats are required to be created with following features:User friendly. Indicate the Mandatory fields by asterisk (*). Fill up default values where ever possible Give combo boxes in all input screens. e) Student, and Data entry personnel details should be stored in the database through “Save” button. f) Authentication of users should be carried out where ever required. a) b) c) d)
2. Web Page or window layouts
Each screen should have • Menu driven facility
• Uniformity • Consistency
3. Outputs
Analytical outputs should be supported by graphs. a) For each output there should be provision of printing c) Emails should be well structured d) Each paper output should be formatted to A4 size paper.
4. DOs (Input)
Each input box to be supported by label Give tool tips where required Give formats (mm/ dd /yy) Provide Tab Index e) Input elements without visible labels should continue to contain text (search, login) a) b) c) d)
þÿ
Search site
f) Password g) radio inputs should have one option checked as default
þÿ
Login
5. DONTs (Inputs)
a) Don’t distract users from their goals b) Don’t use dark background with dark font colors c) Don’t use too many colors
6. Error messages Give small error messages like “Incorrect Data” or “Incorrect Date
Format” or “Field is required” and supplement it with “Ok” Button.
9.3.2 Hardware Interfaces:
Following Hardware Interfaces are required: • • • • Pentium 4 Processor Minimum 512 MB RAM 80 GB HDD
9.3.3 Software Interfaces:
Following Softwares are required:1. Java, J2EE (Servlets) 2. Amazon Web Service - Amazon Elastic Compute Cloud. 3. Flex4
9.3.4 Memory Constraints:
RAM with minimum 1 GB and 40 GB HD space
Broad level software requirements :
Unique ID 1. Requirement Make facility for registration of customer Remarks Provide Registration authentication interface. a and user
2. 3. 4. 5. 6. 7.
Create facility for storing Customer details Provide facility to Customer for error reporting Create facility for generate a ticket for every fault. Create facility for Manager views the faults, escalates the faults to available analyzer or technicians Create facility for Analyzer and Technicians solve the problems allocated by the manager Create facility for a administrator maintains error log and keep track of the problem and person who is working on it
9.4 Product Functions: Database Functions
1. Database should have the facility to a) b) c) d) e) f) g) h) i) insert records, update, edit, delete (Restricted users only), Search and Sort records. Create and edit master and transaction records. All the interaction to and from the database should be through Web Pages. Database should have following tables:-
Data Entry Personnel: First Name, Last Name, Address, Contact Details, Qualification, Place of work, Designation. etc II. Data Entry Points: user credentials.
I. 2.
Authentication
Users at all levels should be authenticated before giving them access.
3. Analysis
Outputs of all analysis should be in the form of a) Data in tabular form b) Graphical representation of Performance.
9.5 User characteristics:
Following are the characteristics of the intended users:Educational Level: Level of the users is between Educated to highly educated. Experience: Experienced in their domain but training in the proposed application. Technical Expertise: Training required in the proposed application.
9.6 Constraints: Site Adaption Requirements:
Only system Administrator and DBA are authorized to carry out this task jointly.
Assumptions and Dependencies
It is assumed that all the systems will have the basic HW, SW and Communication Interfaces available. The users are trained in using the application.
Apportioning of Requirements
Identify requirements that may be delayed until future versions of the system. All requirements will be met.
9.7 Logical Database Requirements:
Logical requirements connected with the database include: a) Most of the values are string types but the count is in numbers. b) Counting of the patients connected with a specific disease is monitored immediately after entering the record of each patient. c) Accessing rights are limited to authenticated users only.
d)
Integrity constraints are maintained by setting the relationships.
Functions:
Validity checks on the inputs
• Data Entry Operators
a) Exact sequence of operations Customer Registration Authentication Error report Manager view the fault and assign for solve Analyzer and technician solve the problem Maintains error log and keep track of the problem by admin b) Responses to abnormal situation, including • Overflow – Periodic Backups • Communication facilities : Internet, Telephone • Error handling and recovery : Periodic Backup, Error alerts, Maintain Error Logs c) Effect of parameters
9.8 Design Constraints
Hardware Constraints • • • • Pentium 4 processor, RAM Minimum 1 GB memory, 40 GB Hard disk. 100 Mbps Modem
Design constraints • • • Charts have to be created using Flex All user interfaces have to be created using Flex Interaction between User Interface and the database should be through Web Services.
9.9 Standards Compliance:
Following standards will be maintained:• • • • Report format. Data naming (As per the Naming Conventions – organization policy) Accounting procedures Audit Tracing (All changes made to student details will be traced in trace files with before and after values)
9.10 Reliability:
Software will be handed over to the client after carryout extensive Unit Testing Integration Testing System Testing After performing periodic demonstrations to the end users on completion of each module and keep a log of the errors / observations made by the user • Number of errors during Unit Testing may be more but they should show decreasing trend during Integration and System Testing and should reduce to zero at the time of delivery. Ensure strict compliance to Project Plan • • • •
9.11 Availability:
Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart. <Click Here to Insert Your Text>
9.12 Security:
• • • • •
•
Authentication module will ensure that only authorized users are provided access control on the web site. Roles will be defined to impose restrictions on the authorized users. Ensure that buffer overflow and integer overflow will be avoided. Whenever user is deleted his privileges will also get deleted. Carryout periodic backup of the database and maintain a log. Honey Pots Intentionally include some PCs in the network which are vulnerable for hackers. They can be used to catch hackers or fix vulnerability.
9.13 Maintainability
Keep a count of the number of lines of code. Though there cannot be a benchmark for the maximum lines of code in a sub routine but higher the lines of code indicates • Higher is the maintenance.
• Need to split up in to child levels. • Place every module in Try Catch () and finally () block to prevent disgraceful exit. Avoid excessive complexity Avoid excessive Inheritance Variable name should not match the field names Reduce complexity of conditional branching
9.14 Portability:
Specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems. This may include a) Percentage of components with host-dependent code b) Percentage of code that is host dependent c) Use of a proven portable language d) Use of a particular compiler or language subset e) Use of a particular operating system. Once the relevant characteristics are selected, a subsection should be written for each, explaining the rationale for including this characteristic and how it will be tested and measured. A chart like this might be used to identify the key characteristics (rating them High, Medium, or Low), or ranking them in order of importance (1, 2, 3, etc.). ID 1 2 3 Characteristic Correctness Efficiency Flexibility etc. Rank
Organizing the Specific Requirements:
For anything but trivial systems the detailed requirements tend to be extensive. For this reason, it is recommended that careful consideration be given to organizing these in a manner optimal for understanding. There is no one optimal organization for all systems. Different classes of systems lend themselves to different organizations of requirements in section 3. Some of these organizations are described in the following subsections.
9.15 System Mode:
Some systems behave quite differently depending on the mode of operation. For example, a control system may have different sets of functions depending on its mode: training, normal, or emergency. When organizing by mode there are two possible outlines. The choice depends on whether interfaces and performance are dependent on mode. Web Site being developed in ASP.NET 2.0 it is compatible to most of the OS and the Web Browsers.
9.16 Supporting Information:
The supporting information makes the SRS easier to use. It includes: a) Table of Contents at the front of the document b) Index c) Appendices: Definitions of important terminologies are given in the Appendix The Appendices are not always considered part of the actual requirements specification and are not always necessary. They may include: (a) Sample I/O formats, descriptions of cost analysis studies, results of user surveys; (b) Supporting or background information that can help the readers of the SRS; (c) A description of the problems to be solved by the software; (d) Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements. When Appendices are included, the SRS should explicitly state whether or not the Appendices are to be considered part of the requirements. Tables on the following pages provide alternate ways to structure section 3 on the specific requirements.
9.17 Document Control: Change History
Revision Release Date Description [list of changed pages and reason for change]
Document Storage
This document was created using standard SRS Template followed by IEEE. The file is stored by the Project Manager, one signed copy is handed over to the authorized representative of the customer and the second copy is kept with the Administrator. It establishes the basis for agreement with the client on what the software product is expected to do, as well as what it is not expected to do.
Document Owner
Project Manager is responsible for developing and maintaining this document.
9.18 Appendix A:
Definitions of the quality characteristics follow. • Correctness - extent to which program satisfies specifications, fulfills user’s mission objectives • Efficiency - amount of computing resources and code required to perform function • Flexibility - effort needed to modify operational program • Integrity/Security - factors that protect the software from accidental or malicious access, use, modification, destruction, or disclosure • Interoperability - effort needed to couple one system with another • Maintainability - ease of maintenance of the software itself • Portability - ease of porting the software to another host • Reliability - factors required to establish the required reliability of the system • Reusability - extent to which it can be reused in another application • Testability - effort needed to test to ensure performs as intended • Usability - effort required to learn, operate, prepare input, interpret output • Availability - factors required to guarantee a defined availability level for the system • Requirement Make facility for registration of customer Create facility for storing Customer details Provide facility to Customer for error reporting Create facility for generate a ticket for every fault. Create facility for Manager views the faults, escalates the faults to available analyzer or technicians Create facility for Analyzer and Technicians solve the problems allocated by the manager Create facility for a administrator maintains error log and keep track of the problem and person who is working on it Database will be in My SQL . Remarks Ensure Correctness and stability References Verifiable References
9.19 Specific Requirements
Uniqu e ID 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Correctness
Java and Flex Technology will be used. Correctness All components of the input screens will have Correctness validation checks Consistency will be maintained throughout the site. Correctness
9.20 Performance Requirements:
Presently we are working on four terminals. It is expected that at any point of time three terminals will be in operation simultaneously. The amount of information will be numerical and text oriented and the volume will be limited.
9.21 Software System Attribute:
Analysis: This is an important module and this module should be able to raise an alert by estimating the probability of disease being escalated to epidemic. Modular approach will be followed. Create Roles. Allow the user to analize the fault Check Performance by higher authority. Deploy the application on Amazon cloud 5. Manage the application
1. 2. 3. 4.
Graphs and email generation should be asynchronous.
9.22 objects:
Following objects are being considered in this application:• • Authorized users. Performance Report.
9.23 Feature:
The features are listed in the subsequent paragraphs in the form of Stimulus and Response.
9.24 Stimulus
• • User ID + Pwd of Data Entry Operators Performance.
9.25 Response:
• • Performance Report. Dynamic Graphs.
•
Authentication Alert.
9.26 Functional Hierarchy:
When none of the above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by common inputs, common outputs, or common internal data access. Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data. Draw DFDs Prepare Data Dictionaries.
9.27 Additional Comments:
Whenever a new SRS is contemplated, more than one of the organizational techniques given in 3.7 may be appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification. Any additional requirements may be put in a separate section at the end of the SRS. There are many notations, methods, and automated support tools available to aid in the documentation of requirements. For the most part, their usefulness is a function of organization. For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful. In any of the outlines below, those sections called “Functional Requirement i” may be described in native language, in pseudo code, in a system definition language, or in four subsections titled: Introduction, Inputs, Processing, and Outputs. <Click Here to Insert Your Text>.
10. Programming Code:
Login Page:
<mx:ViewStack x="10" y="95" id="viewstack1" width="911" height="498"> <s:NavigatorContent label="View 1" width="100%" height="100%" backgroundColor="#B9B49D"> <mx:ViewStack x="212" y="17" id="viewstack2" width="688" height="407" backgroundColor="#B0ADAD"> <s:NavigatorContent label="View 1" width="100%" height="100%" backgroundColor="#C2BCAA"> <mx:Image x="382" y="236" source="assets/cisco.jpeg" height="137" width="265"/> <mx:Image x="387" y="0" source="assets/adtran.jpeg" width="246" height="85"/>
<mx:Image x="385" y="85" source="assets/tele.jpeg" width="261" height="146"/> <s:Panel x="47" y="32" width="324" height="231"> <s:TextInput x="152" y="61" id="user" borderColor="#D7C2C2" width="159" fontSize="14" fontWeight="bold" fontFamily="Georgia"/> <s:Label x="70" y="62" text="UserName :" width="82" height="18" fontWeight="bold" fontSize="14"/> <s:TextInput x="153" y="109" id="pass" displayAsPassword="true" borderColor="#EDE2E2" width="159" fontSize="14"/> <s:Label x="70" y="111" text="Password :" width="82" height="18" fontWeight="bold" fontSize="14"/> <s:Button x="172" y="151" label="Login" width="78" click="login()" fontSize="14"/> <s:Label x="19" y="-7" text=" LoginHere:" width="107" height="16" fontSize="16" fontWeight="bold"/> <s:ToggleButton x="0" y="21" width="324" height="15" buttonMode="false"/> </s:Panel> </s:NavigatorContent> </mx:ViewStack> <s:RichText x="10" y="38" text="Fault management identifies the network problems, failures and trouble events, and corrects them. Fault management is the reactive form of network management. Fault management systems can be used to predict future failures, find faults, and analyze their causes." height="358" width="195" textAlign="center" chromeColor="#2B1515" backgroundColor="#BEB79C" fontWeight="bold" verticalAlign="justify" fontSize="14"/> </s:NavigatorContent> public function login():void { if(user.text==""||pass.text=="") { Alert.show("enter userid/password"); } else { login1.send();
} } <s:HTTPService id="login1" method="POST" resultFormat="text" url="http://localhost:9090/FaultMngmtSystem/servlet/Login1" result="call(event)" > <s:request xmlns=""> <username>{user.text}</username> <password>{pass.text}</password> </s:request> </s:HTTPService> public function call(event:ResultEvent):void { var res:String=event.result.toString(); var arr:Array=res.split(","); logout.visible=true; if(arr[0]=="operator") { str4=arr[1].toString()+""+"PvtLtd"; Alert.show("login success"); //lb1.text=arr[1].toString(); viewstack1.selectedIndex=1; } else if(arr[0]=="manager") { str3=arr[1].toString()+""+"PvtLtd"; //lb2.text=str; viewstack1.selectedIndex=2; } else if(arr[0]=="Analyzer") { str5=arr[1].toString()+""+"PvtLtd"; //lb3.text=arr[1].toString(); analyzerworkdetails.send(); //getTechDetails.send(); viewstack1.selectedIndex=3; } else if(arr[0]=="Technician") { str6=arr[1].toString()+""+"PvtLtd"; getTechWork.send(); //lb4.text=arr[1].toString(); viewstack1.selectedIndex=4; Alert.show("technician");
} else { Alert.show("Plz enter correct username/password"); } } 2.Complaint Registration <s:NavigatorContent label="complaintReg" width="100%" height="100%"> <s:Panel x="30" y="19" width="656" height="436"> <s:Label x="108" y="104" text="CustomerName:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="159" y="72" text="RefNo:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="133" y="210" text="FaultType:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="139" y="169" text="PhoneNo:" fontWeight="bold" color="#030000" fontSize="12"/> <s:Label x="141" y="137" text="Location:" width="57" fontWeight="bold" color="#030000" fontSize="12"/> <s:CheckBox x="210" y="223" label="Cable" fontWeight="bold" id="cable" click="faults()" color="#030000"/> <s:CheckBox x="210" y="287" label="Equipment" fontWeight="bold" id="equipment" click="faults()" color="#030000"/> <s:CheckBox x="211" y="265" label="Traffic" fontWeight="bold" id="traffic" click="faults()" color="#030000"/> <s:CheckBox x="211" y="244" label="Fibre" fontWeight="bold" id="fibre" click="faults()" color="#030000"/> <s:CheckBox x="211" y="312" label="unknown" fontWeight="bold" id="unknown" click="faults()" color="#030000"/> <s:TextInput x="216" y="102" id="custname"/> <s:TextInput x="214" y="69" id="refno"/> <s:TextInput x="214" y="163" id="ph" maxChars="10" restrict="0-9"/> <s:TextInput x="215" y="131" id="loc"/> <s:Label x="-2" y="42" text="ComplaintRegistration" width="318" fontFamily="Verdana" fontWeight="bold" fontSize="21" color="#804205"/> <s:Button x="345" y="69" label="GetDetails" fontWeight="bold" click="getStatus()"/>
<s:Button x="329" y="308" label="Submit" fontWeight="bold" click="submit()"/> <s:TextInput x="407" y="124" id="st" width="146" visible="false"/> <s:Label x="367" y="131" text="status:" fontWeight="bold" id="st1" fontSize="12" color="#070400" visible="false"/> <mx:Image x="401" y="210" source="assets/reg1.jpeg" width="245" height="164"/> <s:Button x="91" y="310" label="Reset" click="reset()"/> <s:TextInput x="402" y="164" id="f1" visible="false"/> <s:Label x="364" y="171" text="Fault:" id="f" fontWeight="bold" fontSize="13" color="#030200" visible="false"/> <s:Label x="137" y="-24" width="298" height="19" id="lb1" text="{str4}" fontSize="20" fontFamily="Verdana" fontWeight="bold"/> </s:Panel> <mx:Image x="693" y="10" source="assets/rep1.jpeg" width="218" height="173"/> <mx:Image x="692" y="185" source="assets/rep2.jpeg" width="219" height="151"/> <mx:Image x="693" y="335" source="assets/rep3.jpeg" width="213" height="163"/> </s:NavigatorContent> import mx.controls.Alert; import mx.rpc.events.ResultEvent; public function submit():void { comp.send(); updatefaults.send(); custname.text=''; loc.text=''; ph.text=''; //fd.text=''; } <s:HTTPService id="comp" method="POST" url="http://localhost:9090/FaultMngmtSystem/servlet/ComplaintReg ister" result="comp_resultHandler(event)"> <s:request xmlns=""> <operator>{user.text}</operator>
<custname>{custname.text}</custname> <phone>{ph.text}</phone> <location>{loc.text}</location> <fault1> {fault1.toString()} </fault1> </s:request> </s:HTTPService> protected function comp_resultHandler(event:ResultEvent):void { var reg:String=event.result.toString(); var reg1:Array=reg.split(","); if(reg1[0]=="1") { //refno.text=reg1[1].toString(); refno.visible=true; Alert.show(reg1[1].toString(),'Complaint Registration success'); } else if(reg=="0") { Alert.show("reg failed"); } } ii)JAVA CODE 1.Login1.java import java.io.IOException; import java.io.PrintWriter; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement;
import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;
public class Login1 extends HttpServlet {
/** * Constructor of the object. */ public Login1() { super(); }
/** * Destruction of the servlet. <br> */ public void destroy() { super.destroy(); // Just puts "destroy" string in log // Put your code here }
/** * The doPost method of the servlet. <br>
* * This method is called when a form has its tag value method equals to post. * * @param request the request send by the client to the server * @param response the response send by the server to the client * @throws ServletException if an error occurred * @throws IOException if an error occurred */ public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html"); PrintWriter out = response.getWriter(); try { Class.forName("com.mysql.jdbc.Driver"); Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/faultmanag ement", "root", "root"); Statement st=con.createStatement(); String uname=request.getParameter("username"); String pwd=request.getParameter("password"); System.out.println(uname); ResultSet rs=st.executeQuery("select * from managers where MId='"+uname+"' and password='"+pwd+"'");
if(rs.next()) { String designation=rs.getString("designation"); String company=rs.getString("company"); String s=designation+","+company; out.print(s); } else { String company1=""; ResultSet rs1=st.executeQuery("select * from employees where empId='"+uname+"' and Password='"+pwd+"'"); if(rs1.next()) { String desig=rs1.getString("designation"); company1=rs1.getString("company"); String add=desig+","+company1; out.print(add); } else { out.print("0"); } } }
catch(Exception e) { e.printStackTrace(); } }
/** * Initialization of the servlet. <br> * * @throws ServletException if an error occurs */ public void init() throws ServletException { // Put your code here }
} 2.Complaint Registration import java.io.IOException; import java.io.PrintWriter; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; import java.text.SimpleDateFormat; import java.util.Calendar;
import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;
public class ComplaintRegister extends HttpServlet {
/** * Constructor of the object. */ Connection con; Statement st; public static final String DATE_FORMAT_NOW = "dd-MM-yyyy"; public ComplaintRegister() { super(); }
/** * Destruction of the servlet. <br> */ public void destroy() { super.destroy(); // Just puts "destroy" string in log // Put your code here
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { Calendar cal = Calendar.getInstance(); SimpleDateFormat sdf = new SimpleDateFormat(DATE_FORMAT_NOW); String date1= sdf.format(cal.getTime()); try{ String company=""; Class.forName("com.mysql.jdbc.Driver");
con=DriverManager.getConnection("jdbc:mysql://localhost:3306/faultmanag ement","root","root"); st=con.createStatement(); System.out.println(" complaint dopost called connection created"); response.setContentType("text/html"); PrintWriter out = response.getWriter(); String operator=request.getParameter("operator"); String custname=request.getParameter("custname"); String location=request.getParameter("location"); //String date=request.getParameter("faultdate"); String fault=request.getParameter("fault1");
String phone=request.getParameter("phone"); String refno=new GenerateRefNum().getRef(); ResultSet rs=st.executeQuery("select company from managers where MId='"+operator+"' and designation='operator'"); if(rs.next()) { company=rs.getString("company"); } ResultSet rs1=st.executeQuery("select fault,custName,count from complaintreg where fault='"+fault+"' and companyname='"+company+"' and custName='"+custname+"' and faultdate='"+date1+"'"); if(rs1.next()) { Integer count=rs1.getInt("count"); count=count+1; int i1=st.executeUpdate("UPDATE complaintreg SET count='"+count+"' where custName='"+custname+"' and fault='"+fault+"' and faultdate='"+date1+"'"); if(i1==1) { System.out.print("Update success"); out.print("2"); } else { System.out.print("Update failed");
} } else { Integer cnt=1; int i=st.executeUpdate("insert into complaintreg(Refno,fault,faultdate,companyname,custName,location,count,P hone,status) values('"+refno+"','"+fault+"','"+date1+"','"+company+"','"+custname+"',' "+location+"','"+cnt+"','"+phone+"','unsolved')"); if(i==1) { System.out.println("complaint registeration successful"); out.print("1"+","+refno); } else { System.out.println("complaint registeration failed"); out.print("0"); } }} catch(Exception e) { e.printStackTrace(); }
}
/** * Initialization of the servlet. <br> * * @throws ServletException if an error occurs */ public void init() throws ServletException { // Put your code here }
}
3.Employee Registration
import import import import import import import import import import java.io.IOException; java.io.PrintWriter; java.sql.Connection; java.sql.DriverManager; java.sql.ResultSet; java.sql.Statement; javax.servlet.ServletException; javax.servlet.http.HttpServlet; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletResponse;
public class EmployeeRegistration extends HttpServlet { /** * Constructor of the object. */ Connection con; Statement st; public EmployeeRegistration() { super();
} /** * Destruction of the servlet. <br> */ public void destroy() { super.destroy(); // Just puts "destroy" string in log // Put your code here } /** * The doPost method of the servlet. <br> * * This method is called when a form has its tag value method equals to post. * * @param request the request send by the client to the server * @param response the response send by the server to the client * @throws ServletException if an error occurred * @throws IOException if an error occurred */ public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String company=""; try{ Class.forName("com.mysql.jdbc.Driver");
con=DriverManager.getConnection("jdbc:mysql://localhost:3306/faultmanagement", "root","root"); st=con.createStatement(); response.setContentType("text/html"); PrintWriter out = response.getWriter(); String empname=request.getParameter("empname"); String empId=request.getParameter("empid"); String phone=request.getParameter("empph"); String pwd=request.getParameter("pass"); String location=request.getParameter("emplocation"); String designation=request.getParameter("empdesig"); String manager=request.getParameter("manager"); ResultSet rs=st.executeQuery("select company from managers where MId='"+manager+"' and designation='manager'"); if(rs.next()) { company=rs.getString("company"); } int i=st.executeUpdate("insert into employees values('"+empname+"','"+empId+"','"+location+"','"+designation+"','"+pwd+"','" +company+"','available','"+phone+"')"); if(i==1) { System.out.println("register success"); out.print("1"); }
else { System.out.println("register failed"); out.print("0"); } } catch(Exception e) { e.printStackTrace(); } } /** * Initialization of the servlet. <br> * * @throws ServletException if an error occurs */ public void init() throws ServletException { // Put your code here } }
11. TECHNOLOGY
Language Java is an Object Oriented language that enables you to create real world applications. The code reusability feature of Java enables the software developers to upgrade the existing applications without rewriting the entire code of the application. Java can be used to create two types of programs: applications and applets.
An application is a program that runs on your computer, under the operating system of that computer. When used to create application, Java is more or less like one created using C computer language. Rather, it is Java’s ability to create Applet that makes it important.
An applet is an application designed to be transmitted over the internet and executed by a Javacompatible Web browser. An applet is actually a tiny java program, dynamically downloaded across the network, just like an image, sound file, or video clip. The important difference is that applet is an intelligent program, not just an animation or media file. In other words, an
applet is a program that can react to user input and dynamically change-not just run the same animation or sound over and over. Java exhibits the following a characteristic because of which java is a suitable language in fulfilling all the requirements of an organization. The characteristics are: Simple, Object-oriented, compiled and interpreted, portable, distributed, secure.
Java is called Object Oriented Language because it supports the following features of OOPS: Encapsulation, Abstraction, Inheritance, Polymorphism 11.2 J2EE • J2EE- JAVA 2 ENTERPRISE EDITION
Enterprise Development Any organization, from the largest corporation to the smallest company, may decide to acquire a software system that helps in its regular activities. All such activities may include the task of making its products available to its customers who may not otherwise know about them, to make data to its internal employees. The need itself is unimportant but the fact that the organization has decided to use some combination of Computer Hardware and software. Enterprise development is any application, set of Systems and sub systems developed for the use of a particular company. Once the decision is made to develop an application, a suitable platform for its development has to be decided. Java 2 Enterprise Edition Java 2, specifically the Enterprise Edition is the most preferable platform selected for the development of Enterprise related software. Java is not restricted to any one medium, domain or technology. J2EE helps in development of secure, scalable and platform independent business solutions. In a Client Server Environment, J2EE provides the framework required for the successful development and deployment of enterprise related software. J2EE is a combination of several technologies like Servlets, Java Server Pages (JSP) and Enterprise Java Beans (EJB’s) that offers a cohesiveness to bond together server side systems and services and produce an industrial strength scalable environment within which web-centric applications can thrive. J2EE simplifies the creation of an enterprise-wide application, because functionality is encapsulated in components of J2EE. This enables designers and programmers to organize the
application into functionality that is distributed across the server-side components built using J2EE. The J2EE technology stack is a shining example of a standard-based approach that works. Look no further than the number of J2EE applications deployed today to validate its success.
Servlets Just like an applet is a client –side program, a servlet is a server side program, written in java, that is dynamically extends the functionality of a server. Similar to the manner in which applets run inside a web browser on the client, Servlets execute inside Apache Tomcat on the server. Unlike applets, Servlets do not display a Graphical Interface to the user. A servlet work is done “behind the scenes” on the server and only the Servlets processing are returned to the client. This is the latest technology from Sunsoft, completely written in java, and is a replace to the CGI implementation with a language (like PERL). It is similar to ASP from Microsoft. Servlets need Apache Tomcat software to run. The latest version Apache contains JSP which is inbuilt. Servlets support to servers can be obtained by implementing the servlet software by Servlet Development Kit (SDK) from Sun. How Servlet works? Servlets are framed to implement the request/response paradigm (pattern). For example: When a browser sends a request to the server, the server may forward the request to a servlet (servlet is request software working inside the server itself). At this point, the servlet process the request (through the database access or any other means) and constructs an appropriate response (answer) that is returned (usually in HTML format) to the client. Servlet is easy to learn as we need not learn any new language like Perl because Servlets are written in pure Java language. If the person knows the syntax and how to use interfaces and methods of Java, it is more than enough. A preliminary touch with HTML is necessary because request/response with Servlet is in HTML format. Servlet Architecture:
The rise of servlet-side java applications is one of the latest and most exciting trends in Java programming. The Java language was originally intended for use in small, embedded devices. It was first hyped as a language for developing elaborate client- side web content in the form of applets. Until recently, Java’s potential as a server-side development platform had been sadly overlooked. Now Java is coming into its own as a language ideally suited for server-side development. Java Servlets are the key components of server-side Java development. A Servlet is a small, pluggable extension to a server that enhances the server’s functionality. Servlets allow developers to extend and customize any Java-enabled server-a web server, a mail server, an application server, or any custom server—with a hitherto unknown degree of portability, flexibility and ease. A servlet is a generic server extension—a Java class that can be loaded dynamically to expand the functionality of a server. Servlets are commonly used with web servers. A Servlet is similar to a proprietary server extension; except that it runs inside a Java Virtual Machine (JVM).Servlets operate solely within the domain of the server: unlike applets, they do not require support for Java in the web browser. Another advantage of Servlets is that they are portable: both across operating systems as we are used to with Java and also across web servers. All the major web servers support Servlets. Java Servlets offer the best possible platform for web application development Servlet API is optimized for Hyper Text Transfer Protocol (HTTP)
Structure of Servlet: The basic structure of Servlet is nothing but the structure of any Java application. We will notice some new methods, interfaces and exceptions. A simple Java program becomes a Servlet when it expands either GenericServlet or its subclass HTTPServlet (like a Java program becomes applet when extends Applet). By doing so, the Java program (now, it is servlet), attains some default functionality o a servlet. The method that we generally override is service () method is a servlet. The method that we generally override is service () method is called by the server automatically when a request is made by the client. Service () method is a general all-purpose method which can be replaced, at the fancy of the developer, by more specific methods like doGet () or doPost ().
Life Cycle of Servlet: The process of creating, invoking and destroying a servlet is known Servlet Lifecycle. These methods that involve life cycle are init (), service () and destroy ().
Init (): This method is called first time when the servlet is loaded. It is similar to a class constructor where initialization code is guaranteed to run. Init () method is where the Servlets life cycle begins. It is called by the server immediately after the servlet is loaded. The servlet creates and initializes any resources including data members that are used in the program. This method returns nothing.
Public abstract void init (ServletConfig config) throws ServletException
Service (): This method is to be overridden by the Servlets to obtain custom functionality. The method that is automatically called by the server in response to a client request is called service () method.
Public abstract void service (ServletRequest req, ServletResponse res) Throws ServletException, IOException
The service () method handles all the requests sent by the client. This is called by default after the execution of the init () method. The service method implements a request or response paradigm. The ServletRequest object (here req) object contains the information sent by the client to the server and ServletResponse (here res) contained the information to be sent to the client by the server.
Destroy (): This method is executed when the servlet is unloaded. It is used to free any resources held by the servlet. Public abstract void destroy () Destroy () method signifies the end of the servlet’s life. It is called by the server when the servlet is unloaded. Should be used to free any resources (like closing of any database connection) held by the servlet. This method returns nothing. Java Servlet API: All the classes and interfaces required to create and execute Servlets are contained within two packages javax.servlet and javax.servlet.http. These two packages put together are known as Java Servlet API and is supplied with Suns’s Java Servlet Development Kit (JSDK). Most commonly used classes are: • • • • • • Http Servlet class Generic Servlet class ServletRequest class HttpServletRequest interface ServletResponse interface HttpServletResponse interface
HttpServlet class: Most HTTP Servlets extend this class. HttpServlet defines methods that are called by the server whenever a servlet request is received. HttpServlet is a subclass of GenericServlet. GenericServlet class:
Most non-HTTP Servlets extend this class. GenericServlet overrides the service () method that is called by the server whenever a servlet request is received. Steps to run Servlet: 1. 2. 3. Compile the program using javac command and obtain a .class file. Copy this file to the classes’ folder in Apache Tomcat. Start the tomcat and this be returned in the background always as long as the servlet is running. Now run the servlet in the browser.
In Servlets once you change the values in the file then one must again save and compile and keep the .class file in the classes’ folder of Apache Tomcat web server. DoGet () and doPost (): DoGet () and doPost () methods are identical. The only difference is the request they service. DoPost are used for request and doGet () for response instead of the general method service (). The parameters of these specific methods are the same as service () method. The doGet () method handles GET requests (of HTML) and doPost () method handles POST requests (of HTML) Redirect: An HTTP redirect is a set of instructions included in the header of an HTTP response that instructs the browser to issue a new request to a new URL. We use redirect in a web as a common phenomenon and is useful in many circumstances. HYPER TEXT TRANSFER PROTOCOL HTTP is a simple, stateless protocol. In a client Server Environment, a client such as a web browser makes a request, the web server responds, and the transaction is done. When the client sends a request, the first thing it specifies is an HTTP command, called method, which tells the server the type of action it wants performed. This first line of the request also specifies the address of a document (a URL) and the version of the HTTP protocol it is using. When the client connects to a server and makes an HTTP request, the request can be of several different types, called methods. The most frequently used methods are GET and POST. Put simply, the GET method is designed for getting information, while the POST method is designed for posting information that is to be stored in a database JDBC
The Java DataBase connectivity is a set of java classes that provide connectivity to relational databases. We can use JDBC from java programs to access almost every SQL database like Oracle, Sybase, DB2, SQL server, Access and FoxBASE, etc. JDBC drivers are available from Symantec, Intersolve, IBM, javasoft and Borelan/Visigenic etc., with little effort we can connect to database. Origin of JDBC: JDBC is not a new query language. It is a simply a java object interface (communication) to SQL. Our applications use JDBC to forward SQL statements to a DBMX. We write SQL statements in a java program to perform database queries and updates. We can think of JDBC as just a java SQL wrapper. JDBC does not enhance or diminish the power of SQL. It’s simply a mechanism for submitting SQL statements. JDC can handle easily the manipulations like connecting to a database, retrieving query results, committing or rolling back transactions. JDBC is based on the X/Open SQL CLI (Call Level Interface), which is also the basis for Microsoft’s ODBC interface. The CLI is not a new query language. It is simply a procedural interface to SQL. JDBC Drivers: JDBC drivers are either direct or ODBC bridged direct driver sits on top of the DBMS’s native interface. For example, Symantec provides direct drivers for Oracle 7.X using ODBC. IBM also provides a native JDBC driver for its DB2 products direct means no transactions will be done between a JDBC program and the database. This will be faster and used in real-time environment. In contrast to direct drivers, bridged drivers are built on the top of existing ODBC drivers. JDBC is created after ODBC. Consequently, there exists a translation between these the two protocols. These types of bridge drivers are slow in communication. Java Soft and Intersolve provide JDBC to ODBC bridge drivers that make it easier to translate between JDBC and the various ODBC drivers. As a result, the JDBC applications, we write are guaranteed to be portable across multi vendor DBMS. That is, a JDBC program is both platform-independent and data-base-independent.
All the classes and interfaces required for writing a JDBC program are included in java.sql package. The java.sql package is supplied with the core jdk software itself. JDBC drivers provide implementation for these classes and interfaces of java.sql package. The other responsibility of drivers is to maintain transaction reliability. The drivers must provide the required synchronization protection. Java Database Connectivity (JDBC)
JDBC is a set of classes and Interface used for the purpose of connecting to a database using applications developed in Java language. To get a connection with the database, a Driver, hich is the implementation of JDBC API loaded. This driver is used to create a Statement, which is an object used to execute SQL queries. Result of a statement is stored as ResultSet.
JDBC
Architecture
JAVA Application
JAVA Application
JAVA Application
JDBC DRIVER MANAGER
JDBC TO ODBC
DRIVER
Sybase
Oracle
DRIVER ODBC DRIVER
DRIVER
MS SQL
SQL
Oracle
SERVER
DRIVER
DATABASE
Web Service Web services can be defined as loosely coupled software components delivered over IP networks. The primary objective of Web services is to simplify and standardize application interoperability within and across companies, leading to increased operational efficiencies and tighter partner relationships.
11.3 MYSQL MySQL is a relational database management system (RDBMS) which has more than 11 million installations. The program runs as a server providing multi-user access to a number of databases. MySQL is owned and sponsored by a single for-profit firm, the Swedish company MySQL AB, now a subsidiary of Sun Microsystems, which holds the copyright to most of the codebase. The project's source code is available under terms of the GNU General Public License, as well as under a variety of proprietary agreements. "MySQL" is officially pronounced (My S Q L), not "My sequel". This adheres to the official ANSI pronunciation; SEQUEL was an earlier IBM database language, a predecessor to the SQL language. However, the company does not take issue with the pronunciation "My sequel" or other local variations. MySQL is popular for web applications and acts as the database component of the LAMP, BAMP, MAMP, SAMP, and WAMP platforms (Linux/BSD/Mac/(Open)Solaris/WindowsApache-MySQL-PHP/Perl/Python), and for open-source bug tracking tools like Bugzilla. Its popularity for use with web applications is closely tied to the popularity of PHP, which is often combined with MySQL. Several high-traffic web sites (including Flickr, Facebook Wikipedia, Google, Nokia and YouTube) use MySQL for its data storage and logging of user data. The MySQL Administrator in Linux MySQL is written in C and C++. The SQL parser uses yacc and a home-brewed lexer.[9][not
citation given] in
MySQL works on many different system platforms, including AIX, BSDi, FreeBSD, HPUX, i5/OS, Linux,MacOSX, NetBSD, Novell NetWare, OpenBSD, OpenSolaris, eComStation , OS/2 Warp, QNX, IRIX,Solaris, Symbian, S
unOS, SCO OpenServer, SCO UnixWare, Sanos, Tru64 and Microsoft Windows. A port of MySQL to OpenVMS is also available. Libraries for accessing MySQL databases are available in all major programming languages with language-specific APIs. In addition, an ODBC interface called MyODBC allows additional programming languages that support the ODBC interface to communicate with a MySQL database, such as ASP or ColdFusion. The MySQL server and official libraries are mostly implemented in ANSI C/ANSI C++. To administer MySQL databases one can use the included command-line tool (commands: mysql and mysqladmin). Also downloadable from the MySQL site are GUI administration tools: MySQL Administrator and MySQL Query Browser. Both of the GUI tools are now included in one package called tools/5.0.html MySQL GUI Tools. In addition to the above-mentioned tools developed by MySQL AB, there are several other commercial and non-commercial tools available. Examples include SQLyog Community Edition, a free desktop based GUI tool and phpMyAdmin, a free Web-based administration interface implemented in PHP.
11.4 FLEX4 Flex is for developing internet and desktop applications. It is a MXML and Action Script-based application development for Flash Player FLEX = MXML+ACTIONSCRIPT. MXML is an XML language that you use to lay out the user interface for Flex applications. MXML provides tags that correspond to classes in the Flex framework. Action Script is the Object Oriented programming language for Flash Player. Action Script (which is based on ECMAScript and is similar to JavaScript) provides flow control and object manipulation features that are not available in MXML. Rich Internet Application(s) A Rich Internet Application (RIA) is an application that runs in the traditional browser but utilizes an intermediate layer. The Intermediate layer contains Flash Player. Rich interfaces use advanced UI controls like trees, tabs and context menus. They provide advanced means of interaction such as drag-and-drop of UI elements. RIAs developed using sound architectural principles and best practices can also greatly increase the
maintainability of an application, as well as greatly reduce the development time to build the application. RIA is possible with flashplayer9 Benefits of developing the applications using Flex.
Enhanced user experience : Flex lets you build applications that provide an engaging user experience. An engaging user experience ensures that customers are drawn into your application, that they understand how to use it, and that they can more quickly complete a task or find the information they are seeking. A complete environment : Flex is a powerful application development solution for creating and delivering RIAs within the enterprise and across the web. It provides a modern, standards based language and programming model that supports common design patterns and includes a highly productive IDE.
Common deployment environment : Flex applications execute on Flash Player 9, which is platform independent, so customers do not need to install custom client software. Also, Flash Player runs consistently in all browsers and platforms, so you do not have to worry about inconsistent behavior in different client environments. Eliminate page loads: Applications running in Flash Player behave like desktop applications, instead of a series of linked pages. Flash Player manages the client interface as a single, uninterrupted flow and does not require a page load from the server when the client moves from one section of the application to another. Client-side processing of user input, including filtering and data validation: Flex data management, which includes data models, data validators, data binding, and data services, lets the user to separate data representation from the way that a user views it. Typically, this design pattern is called Model-View-Controller (MVC). Flex is for developing Internet Applications i.e. Flex applications result in front ends that have “rich”. Web applications have many benefits over desktop applications; they can reach a larger audience. However, Internet applications are not always as "rich" and user-friendly as traditional desktop applications. With Flex, Internet applications can be made richer and more user-friendly.
While Flex applications run in a browser, they take advantage of the Flash Player 9 runtime environment for executing client-side logic, rendering graphics, and playing animation, audio, or video. When the Application is compiled using flex2SDK, it will convert to SWF file, the generated SWF file can be copied in to a directory on the web server or application server the deployed SWF file can be accessed by making an HTTP request in the form: http://hostname/path/filename.swf When a request is made to an SWF file, typically the SWF file is incorporated into a web page by using a wrapper. The wrapper is responsible for embedding the Flex application’s SWF file in a web page. Flex programming model Flex applications are written using a combination of MXML and Action Script. The MXML and Action Script programming languages both give the ability to access the Flex class library. MXML to declaratively define the application user interface elements and the Action Script is used to define client logic and procedural control. Flex application communication with the remote services The MXML components that provide data accesses are called data service components. MXML includes the following types of data service components: Web Service provides access to SOAP-based web services. HTTP Service provides access to HTTP
•
12. Testing:
A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected. This is a non-trivial pursuit. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.
Defects and failures Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirements gaps, e.g., unrecognized requirements that result in errors of omission by the program designer. A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security. Software faults occur through the following process. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. Not all defects will necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new hardware platform, alterations in source data or interacting with different software. A single defect may result in a wide range of failure symptoms. Compatibility A frequent cause of software failure is compatibility with another application or new operating system (or, increasingly web browser version). In the case of lack of backward compatibility this can occur because the programmers have only considered coding the programs for, or testing the software, on the latest operating system they have access to or else, in isolation (no other conflicting applications running at the same time) or under 'ideal' conditions ('unlimited' memory; 'superfast' processor; latest operating system incorporating all updates, etc). In effect, everything is running "as intended" but only when executing at the same time on the same machine with the particular combination of software and/or hardware. These are some of the hardest failures to predict, detect and test for and many are therefore discovered only after release into the larger world with its largely unknown mix of applications, software and hardware. It is likely that an experienced programmer will have had exposure to these factors through "co-evolution" with several older systems and be much more aware of potential future compatibility problems and therefore tend to use tried and tested functions or instructions rather than always the latest available which may not be fully compatible with earlier mixtures of software/hardware. This could be considered a prevention oriented strategy that fits well with the latest testing phase suggested by Dave Gelperin and William C. Hetzel cited below. Input combinations and preconditions A problem with software testing is that testing under all combinations of inputs and preconditions (initial state) is not feasible, even with a simple product. This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, non-functional dimensions of quality (how it is supposed to be versus what it is supposed to do) -- for example, usability, scalability, performance, compatibility, reliability -- can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another. Static vs. dynamic testing
There are many approaches to software testing. Reviews, walkthroughs or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. The former can be, and unfortunately in practice often is, omitted, whereas the latter takes place when programs begin to be used for the first time - which is normally considered the beginning of the testing stage. This may actually begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). For example, Spreadsheet programs are, by their very nature, tested to a large extent "on the fly" during the build process as the result of some calculation or text manipulation is shown interactively immediately after each formula is entered. Software verification and validation Software testing is used in association with verification and validation:
•Verification:
Have we built the software right (i.e., does it match the specification?)? It is process based. • Validation: Have we built the right software (i.e., is this what the customer wants?)? It is product based. The software testing team Software testing can be done by software testers. Until the 1950s the term "software tester" was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing there have been established different roles: test lead/manager, test designer, tester, test automater/automation developer, and test administrator.
Software Quality Assurance (SQA) Though controversial, software testing may be viewed as an important part of the software quality assurance (SQA) process. In SQA, software process specialists and auditors take a broader view on software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in defect rate. What constitutes an acceptable defect rate depends on the nature of the software. An arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than mission critical software such as that used to control the functions of an airliner. Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies. Software Testing is a task intended to detect defects in software by contrasting a computer program's expected results with its actual results for a given set of inputs. By contrast, QA is the implementation of policies and procedures intended to prevent defects from occurring in the first
Testing methods Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. Black box testing Black box testing treats the software as a black box without any knowledge of internal implementation. Black box testing methods include equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing. Specification-based testing Specification-based testing aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Specification-based testing is necessary but insufficient to guard against certain risks. Advantages and disadvantages The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code MUST have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers don't. BUT, on the other hand, black box testing is like a walk in a dark labyrinth without a flashlight, because the tester doesn't know how the back end was actually constructed. That's why there are situations when 1. A black box tester writes many test cases to check something that can be tested by only one test case and/or 2. Some parts of the back end are not tested at all Therefore, black box testing has the advantage of an unaffiliated opinion on the one hand and the disadvantage of blind exploring on the other. White box testing White box testing, by contrast to black box testing, is when the tester has access to the internal data structures and algorithms (and the code that implement these) Types of white box testing The following types of white box testing exist:
• •
•
api testing - Testing of the application using Public and Private APIs. code coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once. fault injection methods.
• •
mutation testing methods. static testing - White box testing includes all static testing.
Code completeness evaluation
White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Two common forms of code coverage are:
•
Function coverage, which reports on functions executed and statement coverage, which reports on the number of lines executed to complete the test.
They both return coverage metric, measured as a percentage. Grey Box Testing In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey-box because the input and output are clearly outside of the black-box we are calling the software under test. This is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages. Acceptance testing Acceptance testing can mean one of two things:
1. A smoke test is used as an acceptance test prior to introducing a build to the main testing
process. 2. Acceptance testing performed by the customer is known as user acceptance testing (UAT). Regression Testing Regression testing is any type of software testing that seeks to uncover software regressions. Such regressions occur whenever software functionality that was previously working correctly stops working as intended. Typically regressions occur as an unintended consequence of program changes. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. Non Functional Software Testing Special methods exist to test non-functional aspects of software.
•
• • •
Performance testing checks to see if the software can handle large quantities of data or users. This is generally referred to as software scalability. This activity of Non Functional Software Testing is often times referred to as Load Testing. Usability testing is needed to check if the user interface is easy to use and understand. Security testing is essential for software which processes confidential data and to prevent system intrusion by hackers. Internationalization and localization is needed to test these aspects of software, for which a pseudo localization method can be used.
In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements), non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing is an example of non-functional testing. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as error-handling routines. Various commercial non-functional testing tools are linked from the Software fault injection page; there are also numerous open-source and free software tools available that perform non-functional testing. Testing process A common practice of software testing is performed by an independent group of testers after the functionality is developed before it is shipped to the customer. This practice often results in the testing phase being used as project buffer to compensate for project delays, thereby compromising the time devoted to testing. Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes. In counterpoint, some emerging software disciplines such as extreme programming and the agile software development movement, adhere to a "test-driven software development" model. In this process unit tests are written first, by the software engineers (often with pair programming in the extreme programming methodology). Of course these tests fail initially; as they are expected to. Then as code is written it passes incrementally larger portions of the test suites. The test suites are continuously updated as new failure conditions and corner cases are discovered, and they are integrated with any regression tests that are developed. Unit tests are maintained along with the rest of the software source code and generally integrated into the build process (with inherently interactive tests being relegated to a partially manual build acceptance process). Testing can be done on the following levels:
•
•
Unit testing tests the minimal software component, or module. Each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors. Integration testing exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components
• •
corresponding to elements of the architectural design are integrated and tested until the software works as a system. System testing tests a completely integrated system to verify that it meets its requirements. System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.
Before shipping the final version of software, alpha and beta testing are often done additionally:
•
•
Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-theshelf software as a form of internal acceptance testing, before the software goes to beta testing. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.
Finally, acceptance testing can be conducted by the end-user, customer, or client to validate whether or not to accept the product. Acceptance testing may be performed as part of the handoff process between any two phases of development.
Regression testing After modifying software, either for a change in functionality or to fix defects, a regression test re-runs previously passing tests on the modified software to ensure that the modifications haven't unintentionally caused a regression of previous functionality. Regression testing can be performed at any or all of the above test levels. These regression tests are often automated. More specific forms of regression testing are known as sanity testing, when quickly checking for bizarre behavior, and smoke testing when testing for basic functionality. Benchmarks may be employed during regression testing to ensure that the performance of the newly modified software will be at least as acceptable as the earlier version or, in the case of code optimization, that some real improvement has been achieved. Testing Tools Program testing and fault detection can be aided significantly by testing tools and debuggers. Types of testing/debug tools include features such as:
•
Program monitors, permitting full or partial monitoring of program code including:
o
Instruction Set Simulator, permitting complete instruction level monitoring and trace facilities Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code code coverage reports Formatted dump or Symbolic debugging, tools allowing inspection of program variables on error or at chosen points Benchmarks, allowing run-time performance comparisons to be made Performance analysis, or profiling tools that can help to highlight hot spots and resource usage Some of these features may be incorporated into an integrated development environment (IDE). Measuring software testing Usually, quality is constrained to such topics as correctness, completeness, security,[citation needed] but can also include more technical requirements as described under the ISO standard ISO 9126, such as capability, reliability, efficiency, portability, maintainability, compatibility, and usability. There are a number of common software measures, often called "metrics", which are used to measure the state of the software or the adequacy of the testing. Testing artifacts Software testing process can produce several artifacts. Test case A test case in software engineering normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps (also known as actions) to follow, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected result. This can be as pragmatic as 'for condition x your derived result is y', whereas other test cases described in more detail the input scenario and what results might be expected. It can occasionally be a series of steps (but often steps are contained in a separate test procedure that can be exercised against multiple test cases, as a matter of economy) but with one expected result or expected outcome. The optional fields are a test case ID, test step or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repository. In a database system, you may also be able to see past test results and who generated the results and the system configuration used to generate those results. These past results would usually be stored in a separate table. Test script
o o • • •
The test script is the combination of a test case, test procedure, and test data. Initially the term was derived from the product of work created by automated regression test tools. Today, test scripts can be manual, automated, or a combination of both. Test data The most common test manually or in automation is retesting and regression testing, In most cases, multiple sets of values or data are used to test the same functionality of a particular feature. All the test values and changeable environmental components are collected in separate files and stored as test data. It is also useful to provide this data to the client and with the product or a project. Test suite The most common term for a collection of test cases is a test suite. The test suite often also contains more detailed instructions or goals for each collection of test cases. It definitely contains a section where the tester identifies the system configuration used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests. Test plan A test specification is called a test plan. The developers are well aware what test plans will be executed and this information is made available to the developers. This makes the developers more cautious when developing their code. This ensures that the developers code is not passed through any surprise test case or test plans. Test harness The software, tools, samples of data input and output, and configurations are all referred to collectively as a test harness. Software testing certification types Certifications can be grouped into: exam-based and education-based. Exam-based certifications: For these there is the need to pass an exam, which can also be learned by self-study: e.g. for ISTQB or QAI. • Education-based certifications: Education based software testing certifications are instructor-led sessions, where each course has to be passed, e.g. IIST (International Institute for Software Testing).
•
Testing certifications
• • • •
CATE offered by the International Institute for Software Testing CBTS offered by the Brazilian Certification of Software Testing (ALATS) Certified Software Tester (CSTE) offered by the Quality Assurance Institute (QAI) Certified Software Test Professional (CSTP) offered by the International Institute for
Software Testing
•
CSTP (TM) (Australian Version) offered by K. J. Ross & Associates
ISEB offered by the Information Systems Examinations Board ISTQB Certified Tester, Foundation Level (CTFL) offered by the International Software Testing Qualification Board • ISTQB Certified Tester, Advanced Level (CTAL) offered by the International Software Testing Qualification Board • CBTS offered by the Brazilian Certification of Software Testing (ALATS) • TMPF Next Foundation offered by the Examination Institute for Information Science
• •
Quality assurance certifications
• • • •
CSQE offered by the American Society for Quality CSQA offered by the Quality Assurance Institute CQIA offered by the American Society for Quality CMSQ offered by the Quality Assurance Institute
Controversy Some of the major software testing controversies include: What constitutes responsible software testing? Members of the "context-driven" school of testing believe that there are no "best practices" of testing, but rather that testing is a set of skills that allow the tester to select or invent testing practices to suit each unique situation. Agile vs. traditional Should testers learn to work under conditions of uncertainty and constant change or should they aim at process "maturity"? The agile testing movement has received growing popularity since 2006 mainly in commercial circles, whereas government and military software providers are slow to embrace this methodology, and mostly still hold to CMMI. Exploratory test vs. scripted Should tests be designed at the same time as they are executed or should they be designed beforehand? Manual testing vs. automated Some writers believe that test automation is so expensive relative to its value that it should be used sparingly. Others, such as advocates of agile development, recommend automating 100% of all tests.[citation needed] More in particular, test-driven development states that developers should write unit-tests of the x-unit type before coding the functionality. The tests then can be considered as a way to capture and implement the requirements. Software design vs. software implementation Should testing be carried out only at the end or throughout the whole process? Who watches the watchmen? The idea is that any form of observation is also an interaction that the act of testing can also affect that which is being tested.
Output screenshots
1.LoginPage(Manager,Operator,Analyzer,Technician)
2.Operator HomePage
3.Manager Home Page
4.Employee Registration (Analyzers and Technicians)
5.AllocateWork To Analyzers
6.AnalyzerHome (will allocate work to technician)
6.Send Acknowledgement
7.TechnicianHome Page
8.Techincian Fault Report
13 Conclusions:
Service Developers want the Service Providers to ensure or provide the capability to dynamically allocate and manage resources in response to changing demand patterns. It is now possible to
provide dynamic visibility and control of services management to meet the rapidly growing demand for Amazon Web Service. This software is developed using Flex as front end, Dot net as middle ware and Sql server as backend. The goals that are achieved by the software are:
• • • • • • • •
Instant Access Improved Productivity Optimum Utilization of resources Efficient management of records Simplification of the operations Less processing time and required information User Friendly Portable and flexible for further enhancements.
Intensive care has been taken by the development team to meet all the requirements of the client. Each module has undergone stringent testing procedures and the integration testing activity has been performed by the team leaders of each module. After completion, execution and successful demonstration, we confirm that the Product has reached client requirements and is ready for launch. Finally we conclude that the project stands up in maintaining its sole motive of betterment to the society and work for a social cause.
14 Future Enhancements:
It is not possible to develop a system that makes all the requirements of the user .user requirements keep changing as the system is being used. Some of the future enhancements that can be done to this system are: 1) The System can be enhanced to increase look and feel of the Application. 2) Will try to scale the application.
15. References
The Unified Modeling Language Users guide By Grady Booch Software Engineering, A practitioners approach By Roger S Pressman
Software Project Management By Walker Royce The applicable IEEE standards as published in ‘IEEE standards collection, for the preparation of SRS’. Backup policy, Naming Conventions as per Teleparadigm Conventions.
