Software Engineering Lab Record
Software Engineering Lab Record
Theory:
An SRS is basically an organization's understanding (in writing) of a customer or potential
client's system requirements and dependencies at a particular point in time (usually) prior to
any actual design or development work. It's a two-way insurance policy that assures that both
the client and the organization understand the other's requirements from that perspective at a
given point in time.
The SRS document itself states in precise and explicit language those functions and capabilities
a software system (i.e., a software application, an eCommerce Web site, and so on) must
provide, as well as states any required constraints by which the system must abide. The SRS
also functions as a blueprint for completing a project with as little cost growth as possible. The
SRS is often referred to as the "parent" document because all subsequent project management
documents, such as design specifications, statements of work, software architecture
specifications, testing and validation plans, and documentation plans, are related to it.
It's important to note that an SRS contains functional and nonfunctional requirements only; it
doesn't offer design suggestions, possible solutions to technology or business issues, or any
other information other than what the development team understands the customer's system
requirements to be.
A well-designed, well-written SRS accomplishes four major goals:
● It provides feedback to the customer. An SRS is the customer's assurance that the
development organization understands the issues or problems to be solved and the software
behavior necessary to address those problems. Therefore, the SRS should be written in
natural language (versus a formal language, explained later in this article), in an
unambiguous manner that may also include charts, tables, data flow diagrams, decision
tables, and so on.
● It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the
problem, solidifies ideas, and helps break down the problem into its component parts in an
orderly fashion.
● It serves as an input to the design specification. As mentioned previously, the SRS serves
as the parent document to subsequent documents, such as the software design specification
and statement of work. Therefore, the SRS must contain sufficient detail in the functional
system requirements so that a design solution can be devised.
● It serves as a product validation check. The SRS also serves as the parent document for
testing and validation strategies that will be applied to the requirements for verification.
SRSs are typically developed during the first stages of "Requirements Development," which is
the initial product development phase in which information is gathered about what requirements
are needed--and not. This information-gathering stage can include onsite visits, questionnaires,
surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the
customer or client's current business environment. The actual specification, then, is written after
the requirements have been gathered and analyzed.
SRS should address the following
The basic issues that the SRS shall address are the following:
a) Functionality. What is the software supposed to do?
b) External interfaces. How does the software interact with people, the system’s
hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of
various software functions, etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc.
considerations?
e) Design constraints imposed on an implementation. Are there any required
standards in effect, implementation language, policies for database integrity, resource
limits, operating environment(s) etc.
Correct - This is like motherhood and apple pie. Of course you want the specification to be
correct. No one writes a specification that they know is incorrect. We like to say - "Correct and
Ever Correcting." The discipline is keeping the specification up to date when you find things
that are not correct.
Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has
only one interpretation. Again, easier said than done. Spending time on this area prior to
releasing the SRS can be a waste of time. But as you find ambiguities - fix them.
Complete - A simple judge of this is that is should be all that is needed by the software designers
to create the software.
Consistent - The SRS should be consistent within itself and consistent to its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.
Ranked for Importance - Very often a new system has requirements that are really marketing
wish lists. Some may not be achievable. It is useful provide this information in the SRS.
Verifiable - Don't put in requirements like - "It should provide the user a fast response."
Another of my favorites is - "The system should never crash." Instead, provide a quantitative
requirement like: "Every key stroke should provide a user response within 100 milliseconds."
Modifiable - Having the same requirement in more than one place may not be wrong - but
tends to make the document not maintainable.
Traceable - Often, this is not important in a non-politicized environment. However, in most
organizations, it is sometimes useful to connect the requirements in the SRS to a higher level
document. Why do we need this requirement?
A sample of basic SRS Outline
1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies
3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
4. System Features
4.1 System feature
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature
5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined
Result:
The SRS was made successfully by following the steps described above
[Link]: Data Flow Diagram
Date:
THEORY
Data flow diagrams illustrate how data is processed by a system in terms of inputs and
outputs.
Data Flow Diagram Notations
You can use two different types of notations on your data flow diagrams:
Yourdon & Coad or Gane & Sarson.
Process Notations
Yourdon and Coad Process Notations Gane and Sarson Process Notation
Process
A process transforms incoming data flow into outgoing data flow.
Datastore Notations
Dataflow
Dataflows are pipelines through
which packets of information flow.
Label the arrows with the name of the
data that moves through it.
Data Flow Diagram Layers
Draw data flow diagrams in several
nested layers. A single process node
on a high level diagram can be
expanded to show a more detailed
data flow diagram. Draw the context
diagram first, followed by various layers of data flow diagrams.
The nesting of data flow layers
Context Diagrams
A context diagram is a top level (also known as Level 0) data flow diagram. It only contains
one process node (process 0) that generalizes the function of the entire system in relationship
to external entities.
External Entity
External entities are objects outside the system, with which the system communicates.
External entities are sources and destinations of the system's inputs and outputs.
DFD levels
The first level DFD shows the main processes within the system. Each of these processes can
be broken into further processes until you reach pseudocode.
An example first-level data flow diagram
Result
The dataflow diagram was made successfully by following the steps described above.
Ex No:3 Timeline Chart/Gannt Chart
Date:
Aim:
To draw timeline chart/Gannt chart for any project.
Introduction:
Gantt Charts are a way to graphically show progress of a project. Management of a project is
made easier if it is viewed as small manageable items where the dependencies are visually
illustrated, parallel processes are discovered, the overall processing time determined and
progress tracked. The tasks of a project can be quite complex and dependent on each other.
With a project management tool, such as a Gantt chart, all subtasks of a task can be viewed
graphically.
Result:
Thus the gannt chart for an application was drawn successfully
Ex No:4 Introduction to UML
Date:
Aim:
To draw the UML Diagrams
Introduction:
The Unified Modeling Language or UML is a mostly graphical modelling language that is used
to express designs. It is a standardized language in which to specify the artifacts and components
of a software system. It is important to understand that the UML describes a notation and not a
process. It does not put forth a single method or process of design, but rather is a standardized
tool that can be used in a design process.
The Unified Modeling Language (UML) is a standard language for specifying,
visualizing,constructing, and documenting the artifacts of software systems, as well as for
business modeling and other non-software systems. The UML represents a collection of best
engineering practices that have proven successful in the modeling of large and complex systems.
The UML is a very important part of developing object oriented software and the software
development process. The UML uses mostly graphical notations to express the design of
software projects. Using the UML helps project teams communicate, explore potential designs,
and validate the architectural design of the software.
Goals of UML
The primary goals in the design of the UML were:
1. Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
7. Integrate best practices.
[Link] Cases
A use case describes a sequence of actions that provide a measurable value to an actor. A use
case is drawn as a horizontal ellipse on a UML use case diagram.
1. Use Case Names Begin With a Strong Verb
2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases.
2. Actors
An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use Case
diagrams).
1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram
2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events
3. Relationships
There are several types of relationships that may appear on a use case diagram:
● An association between an actor and a use case
● An association between two use cases
● A generalization between two actors
● A generalization between two use cases
Associations are depicted as lines connecting two modeling elements with an optional open-
headed arrowhead on one end of the line indicating the direction of the initial invocation of the
relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing
towards the more general modeling element.
1. Indicate An Association Between An Actor And A Use Case If The Actor Appears
Within The Use Case Logic
2. Avoid Arrowheads On Actor-Use Case Relationships
3. Apply <<include>> When You Know Exactly When To Invoke The Use Case
4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case
Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly New
Business Logic
7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the “Is Like” Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the “Is Like” Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor
1. General Guidelines
Figure1. Modeling a business process with a UML Activity Diagram.
1. Place The Start Point In The Top-Left Corner. A start point is modeled with a filled in
circle, using the same notation that UML State Chart diagrams use. Every UML Activity
Diagram should have a starting point, and placing it in the top-left corner reflects the way that
people in Western cultures begin reading. Figure1, which models the business process of
enrolling in a university, takes this approach.
2. Always Include an Ending Point. An ending point is modeled with a filled in circle with
a border around it, using the same notation that UML State Chart diagrams use. Figure1 is
interesting because it does not include an end point because it describes a continuous process –
sometimes the guidelines don’t apply.
3. Flowcharting Operations Implies the Need to Simplify. A good rule of thumb is that if
an operation is so complex you need to develop a UML Activity diagram to understand it that
you should consider refactoring it.
[Link]
An activity, also known as an activity state, on a UML Activity diagram typically represents the
invocation of an operation, a step in a business process, or an entire business process.
1. Question “Black Hole” Activities. A black hole activity is one that has transitions into it
but none out, typically indicating that you have either missed one or more transitions.
2. Question “Miracle” Activities. A miracle activity is one that has transitions out of it but
none into it, something that should be true only of start points.
3. Decision Points
A decision point is modeled as a diamond on a UML Activity diagram.
1. Decision Points Should Reflect the Previous Activity. In figure1 we see that there is no
label on the decision point, unlike traditional flowcharts which would include text
describing the actual decision being made, we need to imply that the decision concerns
whether the person was enrolled in the university based on the activity that the decision
point follows. The guards, depicted using the format on the transitions leaving the
decision point also help to describe the decision point.
2. Avoid Superfluous Decision Points. The Fill Out Enrollment Forms activity in
FIGURE1 includes an implied decision point, a check to see that the forms are filled out
properly, which simplified the diagram by avoiding an additional diamond.
[Link]
A guard is a condition that must be true in order to traverse a transition.
[Link] Transition Leaving a Decision Point Must Have a Guard
[Link] Should Not Overlap. For example guards such as x <0, x = 0, and x > 0 are
consistent whereas guard such as x <= 0 and x >= 0 are not consistent because they overlap
– it isn’t clear what should happen when x is 0.
[Link] on Decision Points Must Form a Complete Set. For example, guards such as x <
0 and x >0 are not complete because it isn’t clear what happens when x is 0.
[Link] Transition Guards and Activity Invariants Must Form a Complete Set. An activity
invariant is a condition that is always true when your system is processing an activity.
[Link] a [Otherwise] Guard for “Fall Through” Logic.
[Link] Are Optional. It is very common for a transition to not include a guard, even when
an activity includes several exit transitions.
[Link] Activities
It is possible to show that activities can occur in parallel, as you see in FIGURE 1 depicted using
two parallel bars. The first bar is called a fork, it has one transition entering it and two or more
transitions leaving it. The second bar is a join, with two or more transitions entering it and only
one leaving it.
1.A Fork Should Have a Corresponding Join. In general, for every start (fork) there is an
end (join). In UML 2 it is not required to have a join, but it usually makes sense.
[Link] Have One Entry Transition.
[Link] Have One Exit Transition
[Link] Superfluous Forks. FIGURE 2 depicts a simplified description of the software
process of enterprise architectural modeling, a part of the Enterprise Unified Process
(EUP). There is significant opportunity for parallelism in this process, in fact all of these
activities could happen in parallel, but forks were not introduced because they would only
have cluttered the diagram.
Swimlane Guidelines
A swimlane is a way to group activities performed by the same actor on an activity diagram or
to group activities in a single thread. FIGURE 2 includes three swimlanes, one for each actor.
Figure2. A UML activity diagram for the enterprise architectural modeling (simplified).
7 Action-Object Guidelines
Activities act on objects, In the strict object-oriented sense of the term an action object is a
system object, a software construct. In the looser, and much more useful for business application
modeling, sense of the term an action object is any sort of item. For example in FIGURE 3 the
ExpenseForm action object is likely a paper form.
1. Place Shared Action Objects on Swimlane Separators
2. When An Object Appears Several Time Apply State Names
3. State Names Should Reflect the Lifecycle Stage of an Action Object
4. Show Only Critical Inputs and Outputs
5. Depict Action Objects As Smaller Than Activities
Figure [Link] the logic for how to enroll in a seminar. One should often develop a system-
level sequence diagram to help both visualize and validate the logic of a usage scenario. It also
helps to identify significant methods/services, such as checking to see if the applicant already
exists as a student, which the system must support.
The dashed lines hanging from the boxes are called object lifelines, representing the life span of
the object during the scenario being modeled. The long, thin boxes on the lifelines are activation
boxes, also called method-invocation boxes, which indicate processing is being performed by
the target object/class to fulfill a message.
How to Draw Sequence Diagrams
Sequence diagramming really is visual coding, even when you are modeling a usage scenario
via a system-level sequence diagram.
While creating a sequence diagram ,start by identifying the scope of what you are trying to
[Link] should typically tackle small usage scenarios at the system level or a single
method/service at the detailed object level.
You should then work through the logic with at least one more person, laying out classifiers
across the top as you need them. . The heart of the diagram is in the messages, which you add to
the diagram one at a time as you work through the logic. You should rarely indicate return values,
instead you should give messages intelligent names which often make it clear what is being
returned.
It is interesting to note that as you sequence diagram you will identify new responsibilities for
classes and objects, and, sometimes, even new classes. The implication is that you may want to
update your class model appropriately, agile modelers will follow the practice Create Several
Models in Parallel, something that CASE tools will do automatically. Remember, each message
sent to a class invokes a static method/operation on that class each message sent to an object
invokes an operation on that object.
Regarding style issues for sequence diagramming, prefer drawing messages going from left-to-
right and return values from right-to-left, although that doesn’t always work with complex
objects/classes. Justify the label on messages and return values, so they are closest to the
arrowhead. Also prefer to layer the sequence diagrams: from left-to-right. indicate the actors,
then the controller class(es), and then the user interface class(es), and, finally, the business
class(es). During design, you probably need to add system and persistence classes, which you
should usually put on the right-most side of sequence diagrams. Laying your sequence diagrams
in this manner often makes them easier to read and also makes it easier to find layering logic
problems, such as user interface classes directly accessing persistence.
COLLABORATION DIAGRAMS
Collaboration diagrams are also relatively easy to draw. They show the relationship between
objects and the order of messages passed between them. The objects are listed as icons and
arrows indicate the messages being passed between them. The numbers next to the messages are
called sequence numbers. As the name suggests, they show the sequence of the messages as they
are passed between the objects. There are many acceptable sequence numbering schemes in
UML. A simple 1, 2, 3... format can be used, as the example below shows, or for more detailed
and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.
CLASS DIAGRAM
Object-Oriented Concepts
● Attribute: the basic data of the class.
● Method (operation): an executable procedure that is encapsulated in a class and is
designed to operate on one or more data attributes that are defined as part of the class.
● Object: when specific values are assigned to all the resources defined in a class, the result
is an instance of that class. Any instance of any class is called an object.
Discovering Classes
Discovering and defining classes to describe the structure of a computerized system is not an
easy task. When the problem domain is new or unfamiliar to the software developers it can be
difficult to discover classes; a cookbook for finding classes does not exist.
Classes Categories
Classes are divided into three categories:
● Entity: models information and associated behavior that is long-lived, independent of the
surrounding, application independent, and accomplishes some responsibility
● Boundary: handles the communication between the system surroundings and the inside
of the system, provides interface, and facilitates communication with other systems
● Control: model sequencing behavior specific to one or more use cases. Control classes
coordinate the events needed to realize the behavior specified in the use case, and they
are responsible for the flow of events in the use case.
Use Case Driven Method: The scenarios - use cases that are fundamental to the system
operation are enumerated. Going over each scenario leads to the identification of the objects,
the responsibilities of each object, and how these objects collaborate with other objects.
UML Implementation Diagrams
The main implementation diagrams we have in UML are: component diagrams and deployment
diagrams. These diagrams are high level diagrams in comparison with old diagrams you have
already learned.
UML Component Diagram
Component diagrams capture the physical structure of the implementation.
Remember always that when you talk about components, you are talking about the physical
models of code.
You can name them and show dependency between different components using arrows.
A component diagram shows relationships between component packages and components.
Each component diagram provides a physical view of the current model.
Component diagrams contain icons representing:
o Component packages.
o Components.
o Main programs.
o Packages.
o Subprograms.
o Tasks.
o Dependencies.
Deployment Diagrams
A deployment diagram shows processors, devices and connections. Each model contains a single
deployment diagram which shows the connections between its processors and devices, and the
allocation of its processes to processors.
Deployment Diagrams: Processor
A processor is a hardware component capable of executing programs.
A processor is given a name and you should specify the processes that will run on that processor.
You can also specify the scheduling of these processes on that processor.
Types of scheduling are:
Pre-emptive: a higher priority process may take the process from lower priority one.
Non-preemptive: a process will own the processor until it finishes
o Cyclic: control passes from one process to another.
o Executive: an algorithm controls the scheduling of the processes
o Manual: scheduling buy the user.
Deployment Diagrams: Device
A device is a hardware component with no computing power. Each device must have a name.
Device names can be generic, such as “modem” or “terminal.”
Deployment diagrams: Connection
A connection represents some type of hardware coupling between two entities. An entity is either
a processor or a device. The hardware coupling can be direct, such as an RS232 cable, or indirect,
such as satellite-to-ground communication. Connections are usually bi-directional.
Result
The UML diagrams were made successfully by following the steps described above
[Link]: Class Responsibility Collaborator Model
. Date:
Aim:
To draw the class responsibility model
Introduction:
CRC (Class-Responsibility-Collaboration): Used primarily as a brainstorming tool for
analysis and design. CRC identifies classes by analyzing how objects collaborate to perform
business functions (use cases).
A CRC card contains: name of the class, responsibilities of the class and collaborators of the
class. Record name of class at the top; record responsibilities down the left-hand side; record
other classes (collaborators) that may be required to fulfill each responsibility on the right-hand
side.
CRC cards are effective at analyzing scenarios; they force you to be concise and clear; they are
cheap, portable and readily available.
Mixed Approach: A mix of these approaches can be used, one possible scenario is:
● Use CRC for brainstorming.
● Identify the initial classes by domain knowledge.
● Use common class patterns approach to guide the identification of the classes.
● Use noun phrase approach to add more classes.
● Use the use case approach to verify the identified classes.
Class Elicitation Guidelines
● A class should have a single major role.
● A class should have defined responsibilities (use CRC cards if needed).
● Classes should be of a manageable size: if a class has too many attributes or operations,
consider splitting it.
● A class should have a well-defined behavior, preferably by implementing a given
requirement or an interface.
Result:
Thus the Class Responsibility Collaborator was drawn successfully
[Link]: Metrics of Code and Design Quality
Date:
Aim:
To study about metrics of code and design quality
Introduction:
Software metrics can be classified into three categories −
● Product metrics − Describes the characteristics of the product such as size, complexity,
design features, performance, and quality level.
● Process metrics − These characteristics can be used to improve the development and
maintenance activities of the software.
● Project metrics − This metrics describe the project characteristics and execution.
Examples include the number of software developers, the staffing pattern over the life
cycle of the software, cost, schedule, and productivity.
Some metrics belong to multiple categories. For example, the in-process quality metrics of a
project are both process metrics and project metrics.
Software quality metrics are a subset of software metrics that focus on the quality aspects of
the product, process, and project. These are more closely associated with process and product
metrics than with project metrics.
Software quality metrics can be further divided into three categories −
● Product quality metrics
● In-process quality metrics
● Maintenance quality metrics
Product Quality Metrics
This metrics include the following −
● Mean Time to Failure
● Defect Density
● Customer Problems
● Customer Satisfaction
Mean Time to Failure
It is the time between failures. This metric is mostly used with safety critical systems such as
the airline traffic control systems, avionics, and weapons.
Defect Density
It measures the defects relative to the software size expressed as lines of code or function point,
etc. i.e., it measures code quality per unit. This metric is used in many commercial software
systems.
Customer Problems
It measures the problems that customers encounter when using the product. It contains the
customer’s perspective towards the problem space of the software, which includes the non-
defect oriented problems together with the defect problems.
The problems metric is usually expressed in terms of Problems per User-Month (PUM).
PUM = Total Problems that customers reported (true defect and non-defect oriented
problems) for a time period + Total number of license months of the software during the
period
Customer Satisfaction
Customer satisfaction is often measured by customer survey data through the five-point scale
● Very satisfied
● Satisfied
● Neutral
● Dissatisfied
● Very dissatisfied
Satisfaction with the overall quality of the product and its specific dimensions is usually
obtained through various methods of customer surveys. Based on the five-point-scale data,
several metrics with slight variations can be constructed and used, depending on the purpose of
analysis. For example −
● Percent of completely satisfied customers
● Percent of satisfied customers
● Percent of dis-satisfied customers
● Percent of non-satisfied customers
In-process Quality Metrics
In-process quality metrics deals with the tracking of defect arrival during formal machine testing
for some organizations. This metric includes −
● Defect density during machine testing
● Defect arrival pattern during machine testing
● Phase-based defect removal pattern
● Defect removal effectiveness
Defect density during machine testing
Defect rate during formal machine testing (testing after code is integrated into the system
library) is correlated with the defect rate in the field. Higher defect rates found during testing is
an indicator that the software has experienced higher error injection during its development
process, unless the higher testing defect rate is due to an extraordinary testing effort.
This simple metric of defects per KLOC or function point is a good indicator of quality, while
the software is still being tested. It is especially useful to monitor subsequent releases of a
product in the same development organization.
Defect arrival pattern during machine testing
The overall defect density during testing will provide only the summary of the defects. The
pattern of defect arrivals gives more information about different quality levels in the field. It
includes the following −
● The defect arrivals or defects reported during the testing phase by time interval (e.g.,
week). Here all of which will not be valid defects.
● The pattern of valid defect arrivals when problem determination is done on the reported
problems. This is the true defect pattern.
● The pattern of defect backlog overtime. This metric is needed because development
organizations cannot investigate and fix all the reported problems immediately. This is
a workload statement as well as a quality statement. If the defect backlog is large at the
end of the development cycle and a lot of fixes have yet to be integrated into the system,
the stability of the system (hence its quality) will be affected. Retesting (regression test)
is needed to ensure that targeted product quality levels are reached.
Phase-based defect removal pattern
This is an extension of the defect density metric during testing. In addition to testing, it tracks
the defects at all phases of the development cycle, including the design reviews, code
inspections, and formal verifications before testing.
Because a large percentage of programming defects is related to design problems, conducting
formal reviews, or functional verifications to enhance the defect removal capability of the
process at the front-end reduces error in the software. The pattern of phase-based defect removal
reflects the overall defect removal ability of the development process.
With regard to the metrics for the design and coding phases, in addition to defect rates, many
development organizations use metrics such as inspection coverage and inspection effort for in-
process quality management.
This metric can be calculated for the entire development process, for the front-end before code
integration and for each phase. It is called early defect removal when used for the front-end
and phase effectiveness for specific phases. The higher the value of the metric, the more
effective the development process and the fewer the defects passed to the next phase or to the
field. This metric is a key concept of the defect removal model for software development.
Maintenance Quality Metrics
Although much cannot be done to alter the quality of the product during this phase, following
are the fixes that can be carried out to eliminate the defects as soon as possible with excellent
fix quality.
● Fix backlog and backlog management index
● Fix response time and fix responsiveness
● Percent delinquent fixes
● Fix quality
Fix backlog and backlog management index
Fix backlog is related to the rate of defect arrivals and the rate at which fixes for reported
problems become available. It is a simple count of reported problems that remain at the end of
each month or each week. Using it in the format of a trend chart, this metric can provide
meaningful information for managing the maintenance process.
Backlog Management Index (BMI) is used to manage the backlog of open and unresolved
problems.
If BMI is larger than 100, it means the backlog is reduced. If BMI is less than 100, then the
backlog increased
Result:
Thus the study of Metrics of code and Design Quality was done successfully
[Link]: Software Testing
Date:
Introduction
Testing is the process of executing a program with the intent of finding errors. A good test case
is one with a high probability of finding an as-yet undiscovered error. A successful test is one
that discovers an as-yet-undiscovered error.
The causes of the software defects are: specification may be wrong; specification may be a
physical impossibility; faulty program design; or the program may be incorrect.
Basic Definitions
A failure is an unacceptable behavior exhibited by a system.
A defect is a flaw in any aspect of the system that contributes, or may potentially contribute, to
the occurrence of one or more failures. It might take several defects to cause a particular failure.
An error is a slip-up or inappropriate decision by a software developer that leads to the
introduction of a defect.
Unit Testing
Unit testing is testing each unit separately. In unit testing interfaces tested for proper information
flow and local data are examined to ensure that integrity is maintained. Boundary conditions and
all error handling paths should also be tested.
Test case
“A test case has components that describes an input, action or event and an expected response,
to determine if a feature of an application is working correctly.”
There are levels in which each test case will fall in order to avoid duplication efforts.
Level 1: In this level you will write the basic test cases from the available specification and
user documentation.
Level 2: This is the practical stage in which writing test cases depend on actual functional and
system flow of the application.
Level 3: This is the stage in which you will group some test cases and write a test procedure.
Test procedure is nothing but a group of small test cases maximum of 10.
Level 4: Automation of the project. This will minimize human interaction with system and
thus QA can focus on current updated functionalities to test rather than remaining busy with
regression testing.
Result:
Thus the software testing was made successfully
[Link]:
Date: Stock Maintenance System
(1) Aim:
To create a system to perform the Stock maintenance System using StarUML, Eclipse.
(2) PROBLEM STATEMENT
The stock maintenance system must take care of the sales information of the company and must
analyze the potential of the trade. It maintains the number of items that are added or removed.
The salesperson initiates this Use case. The salesperson is allowed to update information and
view the database.
(3) SOFTWARE REQUIREMENT SPECIFICATION
3.0 INTRODUCTION
Stock maintenance is an interface between the customer and the salesperson. It aims at
improving the efficiency of maintaining the stocks.
3.1 PURPOSE
The entire process of Stock maintenance is done manually because the number of customers for
purchase is increasing every year, a maintenance system is essential to meet the demand. So this
system uses several programming and database techniques to elucidate the work involved in this
process.
3.2 SCOPE
● The System provides an interface to the customer where they can fill in orders for the
item needed.
● The salesperson is concerned with the issue of items and can use this system.
● Provide a communication platform between the customer and the salesperson.
3.7 OVERVIEW
SRS includes two sections overall description and specific requirements
Overall Description will describe the major role of the system components and
interConnections
Specific Requirements will describe the roles & functions of the actors.
3.8 OVERALL DESCRIPTION
The user interface must be customizable by the administrator.
3.9 PRODUCT PERSPECTIVE
The proposed stock maintenance system is an online system. This system will provide available
stock products for customer (consumer) needs. This system also provides customer feedback
service.
3.10 SYSTEM FUNCTIONS
● Secure order of information by the customer
● Schedule the customer an appointment for manual delivery of the product.
(8) IMPLEMENTATION:
LOGIN PAGE :
package loginform;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
public class login {
private JFrame frame;
private JTextFieldtxtName;
private JPasswordFieldpasswordField;
private final Action action = new SwingAction();
/** * Launch the application.*/
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
login window = new login();
[Link](true);
} catch (Exception e) {
[Link]();
}
}
});
}
/*** Create the application.*/
public login() {
initialize();
}
/*** Initialize the contents of the frame. */
private void initialize() {
frame = new JFrame();
[Link]().setLayout(null);
JLabel username = new JLabel("USERNAME");
[Link](new Font("Tahoma", [Link], 26));
[Link](new Color(240, 240, 240));
[Link](347, 231, 193, 33);
[Link]().add(username);
txtName = new JTextField();
[Link](707, 231, 193, 33);
[Link]().add(txtName);
[Link](10);
JLabellblNewLabel = new JLabel("PASSWORD");
[Link](new Font("Tahoma", [Link], 26));
[Link](347, 360, 193, 33);
[Link]().add(lblNewLabel);
passwordField = new JPasswordField();
[Link](707, 366, 193, 33);
[Link]().add(passwordField);
JButtonbtnNewButton = new JButton("Login");
[Link](new Font("Tahoma", [Link], 26));
[Link](new ActionListener() {
public void actionPerformed(ActionEvent e) {
String name = [Link]();
String pas = [Link]();
if([Link]("sujan") &&[Link]("myname")){
//[Link](frame,"welcome");
CustomerDetails cus = new CustomerDetails();
[Link]();
}
else{
[Link](frame,"Invalid Password");
}
}
});
[Link](692, 479, 120, 33);
[Link]().add(btnNewButton);
JButton btnNewButton_1 = new JButton("Cancel");
btnNewButton_1.setFont(new Font("Tahoma", [Link], 26));
btnNewButton_1.setBounds(428, 479, 120, 33);
[Link]().add(btnNewButton_1);
JLabel lblNewLabel_1 = new JLabel("STOCK MAINTENANCE SYSTEM");
lblNewLabel_1.setFont(new Font("Tahoma", [Link], 30));
lblNewLabel_1.setBounds(362, 140, 486, 33);
[Link]().add(lblNewLabel_1);
}
private class SwingAction extends AbstractAction {
public SwingAction() {
putValue(NAME, "SwingAction");
putValue(SHORT_DESCRIPTION, "Some short description");
}
public void actionPerformed(ActionEvent e) {
}
}
}
Output :
EXIT :
package EndForm;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
public class EndForm {
private JFrame frame;
/** * Launch the application. */
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
EndForm window = new EndForm();
[Link](true);
} catch (Exception e) {
[Link]();
}
}
});
}
/*** Create the application. */
public EndForm() {
initialize();
}
/** * Initialize the contents of the frame.*/
private void initialize() {
frame = new JFrame();
[Link](100, 100, 1357, 774);
[Link](JFrame.EXIT_ON_CLOSE);
[Link]().setLayout(null);
JLabellblNewLabel = new JLabel("THANK YOU FOR PURCHASING");
[Link](new Font("Tahoma", [Link], 26));
[Link](459, 212, 430, 22);
[Link]().add(lblNewLabel);
JLabel lblNewLabel_1 = new JLabel("COME AGAIN");
lblNewLabel_1.setFont(new Font("Tahoma", [Link], 26));
lblNewLabel_1.setBounds(569, 330, 218, 22);
[Link]().add(lblNewLabel_1);
JButton btnNewButton = new JButton("EXIT");
[Link](new Font("Tahoma", [Link], 20));
[Link](615, 442, 96, 33);
[Link]().add(btnNewButton);
}}
OUTPUT :
(9) TESTING:
Test priority
(Low/Medium/High): Medium
3 Click login The user should User name and Success In case the
be able to password are user gives the
navigate to the validated and the wrong entry
next page after next page is the sign-in
validation displayed page remains
active
(10) RESULT:
Thus the mini-project for the stock maintenance system has been successfully executed and
codes are generated.
ONLINE TICKET RESERVATION SYSTEM
(1)AIM:
To implement the online Ticket Reservation System project using StarUML and Eclipse.
3.1 Introduction:
Online ticket reservation means the ticket book the early from anywhere customer give the id
and other details given from the admin. The admin gives the confirmation number and other
details given to the customer.
3.2 Purpose:
The purpose of Railway Reservation System is to create Reservation, Cancel Reservation,
Viewing Train Information, Viewing Reservation Details, Updating Train Information, Updating
Reservation Details and Generate Reports.
3.3 Scope:
Reservation Clerk is a person to create and Cancel Reservation by entering Login Password.
Manager is a person who updates the Train Information by entering his own Password. The
system can handle only reservation and train details efficiently and it doesn’t contain other details
about the railway administration. The main purpose of this system is Ø Creating reservation
● Cancel reservation
● View reservation status
● View train schedule Generating reports
● Update train schedule
● Update reservation details
The Seats of Reservation cannot be more than the seats of Train at that date. This is a constraint
that has to be followed by the Clerk when he creates the Reservation. For that purpose he wants
to check the seats remaining present in the Train.
The scope of this system in creating Reservation is that, from any Railway Station we can Create
Reservation, which is updated automatically in all the stations. Hence, there is no confusion to
the Reservation Clerk in all the stations to create the Reservation. This can be possible by
maintaining a Global Database. Clerks present at different stations can access the global database
and the clerks can easily understand the remaining reservation seats. It provides the ability to
create reservations from different places for a train.
The system is so secure and the clerk and manager utilize it. Nobody is able to access the system
without his or her permission because of providing a login facility to the system. The password
is in the form of cipher text by using cryptography technology, so it cannot be hacked by any
person. The global database can pass through the network inorder $ to be utilized by managers
clerks at different places. So, we want to provide network security because the data is not tracked
by the other persons when it is going through network cables. This network security is provided
by the cryptography technology.
3.4 Definition:
This is a project, which is used to Create and Cancel Reservation and to Update the Train and
Reservation details.
The Product of this project is Railway Reservation System, which is to create Reservation,
Cancel Reservation, Viewing Train Information, Viewing Reservation Details, Updating Train
Information, Updating Reservation Details and Generate Reports.
The Benefit of this project is to reduce the work of Reservation Clerk and it is easy to check the
remaining seats present in the Train and easily view the Reservation Status of the Train and tell
the passenger.
The Goals of this project is that, from any Railway Station we can Create Reservation, which is
updated automatically in all the stations. Hence, there is no confusion to the Reservation Clerk
in all the stations to create the Reservation.
3.5 Overall Description
Product Description:
The Reservation Clerk gets the details from the passenger and he checks whether the seats are
remaining in order to greet the Reservation. If the seats are available, then he allocates the seat
to the passenger by giving the Reservation Slip to the passenger and he updates the Reservation
details. If weights are not available, hg places the Reservation in ‘Waiting List’.
The Reservation Clerk gets the details from the passenger in order to cancel the Reservation and
Cancels Reservation. He also Update the Reservation details after canceling the Reservation and
he creates the Reservation for the Passenger who are placed in the Waiting [Link] reservation
clerk tells the reservation status to passengers who are on the waiting list. The manager updates
the train information and he generates the report of the train, reservation details.
Product Functioning: ·
1. Create Reservations:
A passenger should be able to reserve seats in the train. A reservation form is filled by the
passenger and given to the clerk, who then checks for the availability of seats for the specified
date of journey. If seats are available them the entries are made in the system regarding the train
name, train number, date of journey,boarding station, destination, person name, sex and total
fare. Passengers are asked to pay the required fare and the tickets are printed. If the seats are
not available then the passenger is informed.
[Link] Reservation:
A passenger wishing to cancel a reservation is required to fill a form. The passenger then submits
the form and the ticket to the clerk. The clerk then deletes the entries in the system and changes
the reservation status of that train. The clerk crosses the ticket by hand to mark as cancelled.
[Link] TrainInfo:
Only the administrator or manager enters any changes related to the train information like change
in the train name, train number, train route etc. in the system.
[Link] Report:
Provision for generation of different reports should be given in the system. The system should
be able to generate reservation charts, monthly train reports etc.
[Link] login:
For security reasons all the users of the system are given a user id and a password. Only if the id
and password are correct is the user allowed entry to the system and selected from the options
available in the system.
This person uses this system to create reservations, cancel reservations, view reservation status,
update reservation details, view train schedules.
Manager:
This person uses this system to update train information and to generate reports.
The basic actions that are performed by the system is given as follows:
3.10.5 Verification of user
3.10.6 Maintain Reservation details
Maintain Train details
6) UMLDIAGRAM:
(8)IMPLEMENTATION
LOGIN:
FORM 1:
Login:
});
public tic() {
initialize();
FORM 2:
(10)RESULT:
The online ticket reservation system was designed and implemented successfully
ATM SYSTEM
(1) AIM:
This project on ATM is based on the processing of debit cards in ATM .There are two main
section and the administrator section .In withdraw module the requested amount is deducted
from the user’s account if sufficient balance is available .If the balance in the user’s account is
insufficient the service is denied .In deposit module the deposited amount is added to the user’s
balance .In balance enquiry module the amount that is present in the user’s account is displayed.
The user must enter his pin and account number to perform any of the transactions.
3.0 INTRODUCTION
3.1 PURPOSE
This SRS defines External Interface, Performance and Software System Attributes requirements
of ATM version1.0. This document is intended for the following group of people:-
● Developers for the purpose of maintenance and new releases of the software.
● Management of the bank.
● Documentation writers.
● Testers.
3.2 SCOPE
This software facilitates the user to perform various transactions in his account without going to
bank. This software offers benefits such cash withdrawals, balance transfers, deposits, inquiries,
credit card advances and other banking related operations for customers. It also allows the
administrator to fix the tariffs and rules as and when required.
3.3 DEFINITIONS, ACRONYMS, AND THE ABBREVIATIONS
3.4 REFERENCES
3.5 OVERVIEW
● Describes the overall functionalities and constraints of the software and user
characteristics.
● Details all the requirements needed to design the software.
3.6.1 MODULES:
● Login
● Deposit
● Withdraw
● Changing pin number
● Balance enquiry
Alternative Flow :
User enters wrong pin and the card gets rejected
Pre-condition :
User must know the correct pin number.
[Link] DEPOSIT AMOUNT:
Basic Flow:
User enters the amount and feds cash to machine.
Alternative Flow:
User cancels transaction.
Pre-condition:
User should know the amount to be deposited.
Post condition:
User balance gets updated in the account.
[Link] WITHDRAWAL:
Basic Flow:
User enters amount and gets cash from machine.
Alternative Flow:
Not enough cash in account and so the card gets rejected.
Pre-condition:
User knows the amount to withdraw.
Post condition:
Balance is updated in account.
[Link] BALANCE ENQUIRY:
Basic Flow:
User enquires about balance and the balance is displayed.
Alternative Flow:
User cancels transaction.
[Link] DELETE ACCOUNT:
Basic Flow:
User confirms deletion and account gets deleted.
Alternative Flow:
User doesn’t confirm and resumes transaction.
The ATM system level 0 is also known as context diagram. It’s supposed to be an abstract view,
with the mechanism represented as a single process with external parties.
This DFD for the ATM (Automated Teller Machine) system depicts the overall structure as a
single bubble. It comes with incoming/outgoing indicators showing input and output data.
The content of ATM (Automated Teller Machine) System DFD level 1 must be single process
node from the context diagram and is broken down into sub processes.
In this level, the system must display or reveal further processing information.
DFD level 2 let’s you know the ideas on where does the data inputs goes and inputs comes within
the ATM (Automated Teller Machine) System. Considering the the dataflow levels mentioned
above, you can determine well the importance of breaking the processes into more specific
manner.
[Link]
import [Link];
public class Account {
public int number;
public int balance;
public Vector myTransaction;
public void statement() {
}
public void enquity() {
}
}
[Link]
public class ATM {
privateintpin_number;
public void transaction() {
}
[Link]
[Link];
public class Customer {
public char name;
publicintcard_number;
public Vector myATM;
public Vector myAccount;
public void pin() {
}
public void password() { }
public void newOperation() { }
}
[Link]
public class Transaction {
public int Trans_amount;
public int balance;
public void date() {
}
public void type() {
}
}
SYSTEM DESIGN AND IMPLEMENTATION:
FORM1:
Package ATM;
[Link];
[Link];
public class tic {
privateJFrame frame;
privateJTextFieldtextField;
[Link];
[Link];
[Link];
[Link];
[Link];
[Link];
[Link];
privateJTextField textField_1;
/** * Launch the application. */
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
tic window = new tic();
[Link](true);
} catch (Exception e) {
[Link]();
}}
});
}
/** * Create the application. */
public tic() {
initialize();
}
/** * Initialize the contents of the frame. */
private void initialize() {
frame = new Jframe();
[Link](100, 100, 450, 300);
[Link](Jframe.EXIT_ON_CLOSE);
[Link]().setLayout(null);
JlabellblUsername = new Jlabel(“Username”);
[Link](42, 31, 70, 15);
[Link]().add(lblUsername);
JlabellblPassword = new Jlabel(“Password”);
[Link](42, 73, 70, 15);
[Link]().add(lblPassword);
JtextAreatextArea = new JtextArea();
[Link](212, 31, 1, 15);
[Link]().add(textArea);
textField = new JtextField();
[Link](184, 29, 114, 19);
[Link]().add(textField);
[Link](10);
textField_1 = new JtextField();
textField_1.setBounds(184, 71, 114, 19);
[Link]().add(textField_1);
textField_1.setColumns(10);
JbuttonbtnSubmit = new Jbutton(“Submit”);
[Link](new ActionListener() {
public void actionPerformed(ActionEvent e) {
String us=[Link]();
String ps=textField_1.getText();
if([Link](“admin”)&&[Link](“admin”))
{
[Link](null,”success”);
}
else
{
[Link](null,”failed”);
}}
});
[Link](61, 126, 117, 25);
[Link]().add(btnSubmit);
JbuttonbtnCancel = new Jbutton(“Cancel”);
[Link](241, 126, 117, 25);
[Link]().add(btnCancel);
FORM2:
package ATM1;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
public class form2 {
private Jframe frame;
private JtextField textField;
private JtextField textField_1;
private JtextField textField_2;
private JtextField textField_3;
String username = “root”;
String password = “root@123”;
private static String ConnectionString=”jdbc:mysql://localhost:3306/project”;
private static Connection Conn=null;
private static Statement stm=null;
/*** Launch the application. */
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {form2 window = new form2();
[Link](true);
} catch (Exception e) {
[Link]();
}}});
}
/** * Create the application. */
public form2() {
initialize();
/** * Initialize the contents of the frame. */
private void initialize() {
frame = new Jframe();
[Link](100, 100, 450, 300);
[Link](Jframe.EXIT_ON_CLOSE);
[Link]().setLayout(null);
Jlabel lblName = new Jlabel(“[Link]”);
[Link](55, 12, 70, 15);
[Link]().add(lbl [Link]);
JlabellblAddress = new Jlabel(“Available balance”);
[Link](55, 49, 70, 15);
[Link]().add(lbl Available balance);
JlabellblNoOfTickets = new Jlabel(“Deposit”);
[Link](43, 94, 99, 15);
[Link]().add(lblDeposit);
JlabellblPlace = new Jlabel(“[Link]”);
[Link](55, 128, 70, 15);
[Link]().add([Link]);
textField = new JtextField();
[Link](154, 6, 172, 27);
[Link]().add(textField);
[Link](10);
textField_1 = new JtextField();
textField_1.setBounds(153, 43, 173, 27);
[Link]().add(textField_1);
textField_1.setColumns(10);
textField_2 = new JtextField();
textField_2.setBounds(154, 88, 172, 27);
[Link]().add(textField_2);
textField_2.setColumns(10);textField_3 = new JtextField();
textField_3.setBounds(164, 122, 172, 27);
[Link]().add(textField_3);
textField_3.setColumns(10);
JbuttonbtnInsert = new Jbutton(“insert”);
[Link](new ActionListener() {
public void actionPerformed(ActionEvent e) {
try{
Conn=[Link](ConnectionString,[Link],Available balance,[Link])
[Link](“Connected”);
stm=[Link]();
[Link](“insert into form2([Link],Available
balance,[Link])values(‘”+[Link]()+”’,’”+textField_1.getText()+’’’+textField
_2.getText()+”’,’”+textField_3.getText()+”’)”);
//[Link](query);
[Link](null, “Query Executed”);
}
catch(SQLException e)
{
[Link](null, [Link]());
});
[Link](26, 155, 99, 50);
[Link]().add(btnInsert);
JbuttonbtnDelete = new Jbutton(“delete”);
[Link](137, 155, 99, 50);
[Link]().add(btnDelete);{
public void actionPerformed(ActionEvent arg0){
try{
Conn=[Link](ConnectionString,[Link],Available balance,[Link])
[Link](“Connected”);
stm=[Link]();
[Link](“delete from form2 where [Link]=’”+[Link]()+”’’’);
//[Link](query);
[Link](null, “Query Executed”);
}
catch(SQLException e)
{
[Link](null, [Link]());
});
JbuttonbtnUpdate = new Jbutton(“update”);
[Link](262, 155, 85, 50);
[Link]().add(btnUpdate);{
public void actionPerformed(ActionEvent arg0){
try{
Conn=[Link](ConnectionString,[Link],Available balance,[Link])
[Link](“Connected”);
stm=[Link]();
[Link](“update form2 set [Link]=’’’+[Link]()+’’’ where available
balance=’’’textField_1.getText ()+’’’’’) ;
//[Link](query);
[Link](null, “Query Executed”);
} catch(SQLException e)
{ [Link](null, [Link]()); });
}
}
(9) TESTING:
Test priority
(Low/Medium/High):Medium
2 Provide valid User should be The user is able Success Incase of wrong
password
Able to To login Password was
given an error
Login Successfully
Message box
was
displayed
3 Click login User should be User name and Success Incase user gives
able to navigate to password is wrong entry the
next page after validated and next sign in page
validation page is displayed remains active
(10) RESULT:
Thus, the ATM system was designed and implemented successfully.
BOOK BANK SYSTEM
(4) AIM:
To develop the Book Bank System using Star UML tools, Eclipse and MySQL.
1. Book Bank System is easiest way to getting book during a semester and it must be returned
at the end of semester.
2. Before getting a book membership is must. It was renewed by using there register number.
3. Students can get six to seven books per semester. If they not return the book before due date,
they should pay the fine amount.
3.0 INTRODUCTION
The book bank is a set up that lends books for all its members which they can return at the end
of each semester. It has a huge collection of books and has to keep track of all its members’
details such as requests, dues and penalties and the books.
3.1 PURPOSE
If the entire process of ‘Issue of book’ is done in a manual manner then it would take several
minutes for the book to reach the student. Considering the fact that the number of students for
book is increasing every [Link] this system uses several programming and database techniques
to elucidate the work involved in this process.
3.2 SCOPE
The book bank holds an online interface with its members for maintaining all kinds of transaction
details. Each member is provided with a unique user id at the time of registering as a member.
● [Link]
● [Link]
● [Link]
● [Link]
3.5 OVERVIEW
SRS includes two sections overall description and specific requirements – Overall description
will describe major role of the system components and inter -connections. Specific requirements
will describe roles and functions of the actors.
This project is a self-contained one for enabling a book bank organization to be connected with
its students, through this system, the students can check for availability of books, makes requests,
etc.
This system functions with a database at the back end, for keeping track of its member’s dues
and payments, and also its available resources. Every student who is a member needs only a web
browser to connect to this system.
The server is directly connected to the client systems. The client systems have access to the
database in the server.
1. Student – They are the people who desire to obtain the book and submit the information to
the database.
2. Administrator – He has the certain privileges to add the book status and to approve the issue
of book.
3.6.5 SAFETY REQUIREMENTS:
The student details should be made available in the database and must be updated every time a
book is issued or returned or some kind of payment takes place to prevent errors.
3.6.6 CONSTRAINTS:
2. Although the security is given high importance, there is always a chance of intrusion in the
web world which requires constant monitoring.
1. The Students and Administrator must have basic knowledge of computers and English
Language.
DFDLEVEL 0:
Book Bank system Data flow diagram (DFD) is often used as a preliminary step to create an
overview of the book bank management without going into great detail which can later be
elaborated normally.
At this level, the system has to show or exposed with more details of processing.
The processes that are important to be carried out are:
● Book delivery
● Search by topic
Data store is used to represent this type of information.
DFD LEVEL 2:
● The Level 2 DFD for library management system should represent the basic modules as
well as data flow between them.
● Since this is the highest abstraction level, its library management system processes must
be detailed that is based on the DFD level 1.
● After figuring the processes given in the system, the user will now have their request
being processed.
Fig 4.3 Second Level Data Flow Diagram
FORM1:
LOGIN FORM:
CODING:
package login;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
private JTextFieldtextField;
[Link](new Runnable() {
try {
[Link](true);
} catch (Exception e) {
[Link]();
}
}
});
public FORM1() {
initialize();
[Link](JFrame.EXIT_ON_CLOSE);
[Link]().setLayout(null);
[Link]().add(lblUsername);
[Link]().add(textField);
[Link](10);
[Link]().add(lblPassword);
[Link]().add(textField_1);
textField_1.setColumns(10);
[Link](new ActionListener() {
String us=[Link]();
String ps=textField_1.getText();
if([Link]("punitha")&&[Link]("666"))
[Link](null, "success");
else
{[Link](null,"failed");}}});
[Link]().add(btnSubmit);
[Link](new ActionListener() {
[Link]().add(btnCancel);
}
FORM2:
INSERT FORM:
REGISTRATION CODE:
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link].*;
private JTextFieldtextField;
String username="root";
String password="root@123";
[Link](new Runnable() {
try {
[Link](true);
} catch (Exception e) {
[Link]();} }};}
public Registration() {
initialize();}
[Link](JFrame.EXIT_ON_CLOSE);
[Link]().setLayout(null);
[Link]().add(lblN);
[Link]().add(lblNewLabel);
[Link]().add(lblBook name);
[Link]().add(lblAddress);
[Link]().add(textField);
[Link](10);
[Link]().add(textField_1);
textField_1.setColumns(10);
[Link]().add(textField_2);
textField_2.setColumns(10);
textField_3.setColumns(10);
[Link]().add(textField_4);
textField_4.setColumns(10);
[Link](new ActionListener() {
try{
conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
//[Link](query);
[Link](null, "QueryExecuted");
catch(SQLException e){
[Link](null,[Link]()}}
[Link]().add(btnInsert);
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
//[Link](query);
[Link](null, "QueryExecuted");
catch(SQLException e)
[Link](null,[Link]());
[Link]().add(btnDelete);
[Link](new ActionListener() {
try{
conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link](null, "QueryExecuted");}
catch(SQLException e)
[Link](null,[Link]());
}}
[Link]().add(btnEdit);
[Link](new ActionListener() {
try{
conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
//[Link](query);
[Link](null, "QueryExecuted");
catch(SQLException e)
[Link](null,[Link]());
}
[Link](301, 190, 117, 25);
[Link]().add(btnSearch);
});
[Link]:
[Link]:
}
[Link]:
(9)TESTING:
Test priority
(Low/Medium/High):Medium
displayed
3 Click login User should be User name and Success Incase user gives
able to navigate to password is wrong entry the
next page after validated and next sign in page
validation page is displayed remains active
(10) RESULT:
Thus the Book bank system was designed and implemented successfully.
Library Management Systems
(1)AIM:
(2)PROBLEM STATEMENT:
A library database is an infrastructure that allows users to search books and book content , add
remove , and download selected books. The problem faced is that library users require an
efficient method to find a specific book or keywords within a book given a continuously
expanding library.
INTRODUCTION:
With increase in number of readers better management of libraries system is required. The
library management system focuses on improving the management of libraries in a city or a
town. The integrated library management is developed on the android platform which basically
focuses on issuing , renewing and reserving a book.
PURPOSE:
The purpose of the project is to maintain the details if the books and library members of different
libraries. The main purpose of this project is to maintain an easy circulation system between
clients and the libraries, to issue books using single library card , also to search and reserve any
book from different available libraries and to maintain details about the user(fine , address ,
phone number). Moreover, the user can check all these features from their home.
SCOPE:
Manually updating the library system into an android based application so that the user can know
the details of the books available and maximum limit on borrowing from their computer and also
through their phones.
The ILM system provides information like details of books, insertion of new books, deletion of
lost books, limitations of issue in books , fine on keeping a book for more than one month from
the issued [Link] users can provide feedback for adding some new books to the library.
4.1 PRODUCT PRESPECTIVE
The proposed Library Management System will take care of the current book detail at any point
of time. The book issue, book return will update the current book details automatically so that
user will get the update current book details.
4.2 SOFTWARE REQUIREMENT
Front end:
• Android developer tool
• Advance java
• Back end:
• MySQL
4.3 HARDWARE REQUIREMENT
• Android version 2.3 ginger bread (minimum, android user’s)
• 2GB ram
• 1.2 GHz processor
• Intel i5
• Windows 7/8/8.1/10
CONSTRAINTS:
Any update regarding the book from the library is to be recorded to have update & correct values,
and anyfine on a member should be notified as soon as possible and should be correctly
calculated.
FORM1:
CODING:
LOGIN 1:
package pkg;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
public class login1 {
private JFrame frame;
private JTextFieldtextField;
private JTextField textField_1;
/*** Launch the application.*/
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
login1 window = new login1();
[Link](true);
} catch (Exception e) {
[Link]();
}
}});
}
/*** Create the application. */
public login1() {
initialize();
}
/** * Initialize the contents of the frame.*/
private void initialize() {
frame = new JFrame();
[Link](100, 100, 450, 300);
[Link](JFrame.EXIT_ON_CLOSE);
[Link]().setLayout(null);
JLabellblNewLabel = new JLabel("username");
[Link](33, 40, 98, 15);
[Link]().add(lblNewLabel);
JLabel lblNewLabel_1 = new JLabel("password");
lblNewLabel_1.setBounds(33, 122, 70, 15);
[Link]().add(lblNewLabel_1);
textField = new JTextField();
[Link](178, 38, 114, 19);
[Link]().add(textField);
[Link](10);
textField_1 = new JTextField();
textField_1.setBounds(178, 100, 114, 19);
[Link]().add(textField_1);
textField_1.setColumns(10);
JButtonbtnSubmit = new JButton("submit");
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
String us=[Link]();
String ps=textField_1.getText();
if([Link]("abc")&&[Link]("123"))
{
[Link](null,"login success");
}
else
{
[Link](null, "login failed");
}}});
[Link](29, 200, 117, 25);
[Link]().add(btnSubmit);
Jbutton btnCancel = new JButton("cancel");
[Link](178, 224, 117, 25);
[Link]().add(btnCancel);
JButtonbtnBooksearch = new JButton("booksearch");
[Link](239, 177, 117, 25);
[Link]().add(btnBooksearch);
}
}
FORM 2:
CODE FOR FORM2:
package pkg;
import [Link];
import [Link].*;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
public class login2 {
private JFrame frame;
/** * Launch the application. */
String username="root";
String password ="root@123";
private static String ConnectionString="jdbc:mysql://localhost:3306/librarymngesys";
private static Connection Conn=null;
private static Statement stm =null;
private JTextFieldtextField;
private JTextField textField_1;
private JTextField textField_2;
private JTextField textField_3;
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
login2 window = new login2();
[Link](true);
catch (Exception e) {
[Link]();});}
/*** Create the application. */
public login2() {
initialize();
}
/** * Initialize the contents of the frame. */
private void initialize() {
frame = new JFrame();
[Link](100, 100, 450, 300);
[Link](JFrame.EXIT_ON_CLOSE);
[Link]().setLayout(null);
Jlabel lblName = new JLabel("name");
[Link](31, 24, 70, 15);
[Link]().add(lblName);
Jlabel lblCourse = new JLabel("course");
[Link](12, 66, 70, 15);
[Link]().add(lblCourse);
Jlabel lblRegno = new JLabel("regno");
[Link](12, 132, 70, 15);
[Link]().add(lblRegno);
Jlabel lblIdno = new JLabel("idno");
[Link](12, 191, 70, 15);
[Link]().add(lblIdno);
Jbutton btnAdd = new JButton("add");
[Link](57, 238, 117, 25);
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
Conn =[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link]("insert into loginen1(name,course,regno,idno)
values('"+[Link]()+"','"+textField_1.getText()+"','"+textField_2.getText()+"','"+text
Field_3.getText()+"')");
//stmexecuteUpdate(query);
[Link](null,"query executed");}
catch(SQLException e)
{
[Link](null,[Link]());
}
}
});
[Link]().add(btnAdd);
textField = new JTextField();
[Link](157, 24, 97, 25);
[Link]().add(textField);
[Link](10);
textField_1 = new JTextField();
textField_1.setBounds(140, 76, 114, 19);
[Link]().add(textField_1);
textField_1.setColumns(10);
textField_2 = new JTextField();
textField_2.setBounds(140, 130, 114, 19);
[Link]().add(textField_2);
textField_2.setColumns(10);
textField_3 = new JTextField();
textField_3.setBounds(140, 161, 114, 19);
[Link]().add(textField_3);
textField_3.setColumns(10);
Jbutton btnDelete = new JButton("delete");
[Link](235, 238, 117, 25);
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
Conn =[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link]("delete from loginen1 where name = saran");
//stmexecuteUpdate(query);
[Link](null,"query executed");
}
catch(SQLException e)
{
[Link](null,[Link]());
}}});
[Link]().add(btnDelete);
Jbutton btnSearch = new JButton("search");
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
Conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link]("select*from loginen1 where regno ='"+textField_2.getText()+"'");
}catch(SQLException e)
{[Link](null, [Link](});
[Link](302, 61, 117, 25);
[Link]().add(btnSearch);
Jbutton btnUpdate = new JButton("update");
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
Conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link]("update loginen1 set regno ='"+textField_2.getText()+"' where
course='"+textField_1.getText()+"'");
}
catch(SQLException e){[Link](null, [Link]())}});
[Link](302, 146, 117, 25);
[Link]().add(btnUpdate);
}
}
9) TESTING:
10) RESULT:
(1) AIM
To develop the E-ticketing system using Star UML tools, Eclipse and MySQL.
2) PROBLEM ANALYSIS AND PROJECT PLAN
To simplify the process of ticket reservation in railways, software has been created by designing
through Star UML tool, using Eclipse as a front end and My SQL as a back end. In this system
the main process is a user has to login to the system and check for the tickets while railway
admin reserves the tickets on availability after the payment are made.
3) SOFTWARE REQUIREMENT SPECIFICATION:
INTRODUCTION
E-ticketing system is an interface between the Passenger and the Railway admin responsible for
allocating tickets. It aims at improving the efficiency of reservation of tickets and reduces the
ambiguities involved in it to the maximum extent.
PURPOSE
If the entire process of ‘Reservation of tickets’ is done in a manual manner then it would take
much time for the tickets to be reserved. Considering the fact that the number of passengers is
increasing every year, an E-ticketing system becomes essential to meet the demand. So this
system uses several programming and database techniques to elucidate the work involved in this
process.
SCOPE
The system provides an online interface to the user where they can fill in their travel details. The
railway admin concerned with the allocation of tickets can use this system to reduce his workload
and process the request in a speedy manner. Provides a communication platform between the
passenger and the railway-admin.
REFERENCES IEEE Software Requirement Specification format
TECHNOLOGIES TO BE USED: Eclipse
TOOLS TO BE USED: Star UML(for UML patterns)
OVERVIEW:
SRS includes two sections: overall description and specific requirements –Overall description
will describe major role of the system components and inter-connections. Specific requirements
will describe roles and functions of the actors.
OVERALL DESCRIPTION
PRODUCT PERSPECTIVE:
The E-ticketing system acts as an interface between the passenger and the railway administrator.
This system tries to make the interface as simple as possible and at the same time not risking the
security of data stored in it. This minimizes the time duration in which the user reserves the
ticket.
SOFTWARE INTERFACE:
1. Front End Client: The passenger and Administrator online interface is built using Eclipse
software.
2. Back End :My SQL
HARDWARE INTERFACE:
The server is directly connected to the client systems. The client systems have access to the
database in the server.
USER CHARACTERISTICS:
1. Passenger/User-They are the people who wish to travel to a destination and check for tickets
availability.
2. Railway Administrator-He has certain privileges to add or remove train details based on their
functioning and seats availability. He may have group of people under him to verify all the
details updated in the database.
CONSTRAINTS:
1. The passengers require a computer to submit their information.
2. Although the security is given high importance, there is always a chance of intrusion in the
web world which requires constant monitoring.
4) DATA FLOW DIAGRAM:
5)TIMELINE
6) SOFTWARE DESIN
6.1 Use Case Diagram:
6.8COMPONENT DIAGRAM
8) IMPLEMENTATION:
LOGIN FORM:
CODE FOR FORM 1:
package login;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
public class FORM1 {
private JFrame frame;
private JtextField textField;
private JTextField textField_1;
/** * Launch the application. */
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
FORM1 window = new FORM1();
[Link](true);
} catch (Exception e) {
[Link]();
}
}});}
/** * Create the application. */
public FORM1() {
initialize();
}
/** * Initialize the contents of the frame. */
private void initialize() {
frame = new JFrame();
[Link](100, 100, 450, 300);
[Link](JFrame.EXIT_ON_CLOSE);
[Link]().setLayout(null);
Jlabel lblUsername = new JLabel("USERNAME");
[Link](91, 75, 87, 15);
[Link]().add(lblUsername);
textField = new JTextField();
[Link](225, 73, 114, 19);
[Link]().add(textField);
[Link](10);
Jlabel lblPassword = new JLabel("PASSWORD");
[Link](91, 134, 97, 15);
[Link]().add(lblPassword);
textField_1 = new JTextField();
textField_1.setBounds(225, 134, 114, 19);
[Link]().add(textField_1);
textField_1.setColumns(10);
Jbutton btnSubmit = new JButton("SUBMIT");
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
String us=[Link]();
String ps=textField_1.getText();
if([Link]("raja")&&[Link]("in"))
{
[Link](null, "success");
}
else
{
[Link](null,"failed");
}
}
});
[Link](111, 206, 117, 25);
[Link]().add(btnSubmit);
Jbutton btnCancel = new JButton("CANCEL");
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
}
});
[Link](250, 206, 117, 25);
[Link]().add(btnCancel);
}
}
REGISTERATION:
CODING:
package pkg;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link]:Set;
import [Link];
import [Link];
public class FORM2{
private JFrame frame;
private JTextFieldtextField;
private JTextField textField_1;
private JTextField textField_2;
private JTextField textField_3;
String username="root";
String password="root@123";
private static String
ConnectionString="jdbc:mysql://localhost:3306/train";
private static Connection Conn=null;
private static Statement stm=null;
/*** Launch the application.*/
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
FORM2 window = new FORM2();
[Link](true);
} catch (Exception e) {
[Link]();
}
}
});
}
/*** Create the application.*/
public FORM2() {
initialize();
}
/*** Initialize the contents of the frame.*/
private void initialize() {
frame = new JFrame();
[Link](100, 100, 450, 300);
[Link](JFrame.EXIT_ON_CLOSE);
[Link]().setLayout(null);
JLabellblNewLabel = new JLabel("Train_no");
[Link](32, 40, 70, 15);
[Link]().add(lblNewLabel);
JLabellblDept = new JLabel("Destination");
[Link](32, 83, 70, 15);
[Link]().add(lblDest);
JLabel lblNewLabel_1 = new JLabel("Date");
lblNewLabel_1.setBounds(12, 140, 70, 15);
[Link]().add(lblNewLabel_1);
JLabel lblNewLabel_1 = new JLabel("No_of _seats");
lblNewLabel_1.setBounds(12, 120, 70, 15);
[Link]().add(lblNewLabel_1);
textField = new JTextField();
[Link](153, 38, 114, 19);
[Link]().add(textField);
[Link](10);
textField_1 = new JTextField();
textField_1.setBounds(153, 83, 114, 19);
[Link]().add(textField_1);
textField_1.setColumns(10);
textField_2 = new JTextField();
textField_2.setBounds(153, 138, 114, 19);
[Link]().add(textField_2);
textField_2.setColumns(10);
textField_3 = new JTextField();
textField_3.setBounds(153, 198, 114, 19);
[Link]().add(textField_3);
textField_3.setColumns(10);
JButtonbtnNewButton = new JButton("ADD");
[Link](279, 40, 117, 25);
[Link](new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try
{
Conn=[Link](ConnectionString,username,password);
stm=[Link]();
[Link]("Connected");
[Link]("insert into details(Train_no,Destination,Date,No_of_seats)
values('"+[Link]()+"','"+textField_1.getText()+"','"+textField_2.getText()+"','"+text
Field_3.getText()+"')");
//[Link](query);
[Link](null,"Query Executed");
}
catch(SQLException e)
{
[Link](null,[Link]());
}
}
});
[Link](42, 215, 117, 25);
[Link]().add(btnNewButton);
JButton btnNewButton_1 = new JButton("SEARCH");
btnNewButton_1.setBounds(296, 124, 117, 25);
btnNewButton_1.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
Conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link]("select*from details where destination ='"+textField_1.getText()+"'”);
}
catch(SQLException e)
{
[Link](null, [Link]());
}
}});
[Link](42, 215, 117, 25);
[Link]().add(btnNewButton);
JButton btnNewButton_2 = new JButton("UPDATE");
btnNewButton_1.setBounds(296, 124, 117, 25);
btnNewButton_1.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
Conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link]("update details set destination ='"+textField_1.getText()+"' where
train_no='"+[Link]()+"'");
}
catch(SQLException e)
{
[Link](null, [Link]());
}
}
});
[Link](171, 199, 117, 25);
[Link]().add(btnNewButton);
JButton btnNewButton_3 = new JButton("DELETE");
btnNewButton_1.setBounds(296, 124, 117, 25);
btnNewButton_1.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
try{
Conn=[Link](ConnectionString,username,password);
[Link]("Connected");
stm=[Link]();
[Link]("delete from details where destination ='"+textField_1.getText()+"'");
}
catch(SQLException e)
{
[Link](null, [Link]());
}
}
});
[Link](42, 215, 117, 25);
[Link]().add(btnNewButton);
}}
9) TESTING:
(10) RESULT:
The E ticket system was designed and implemented successfully.
STUDENT MARKS ANALYZING SYSTEM
(1)AIM:
To develop the student mark analysis system using Star UML tools, Eclipse and MySQL
(2)PROBLEM STATEMENT
Student marks analyzing system has to be developed for analyzing obtained by the students who
scored in Semester Examination The System should provide following functionalities
1. The System obtains following information’s from the faculty generates report Roll No, Name,
Department, Semester, Marks obtained in each subject.
2. The total for each student should be calculated and ranked based on total and pass in all the
subject appeared.
3. The Final report should display rank, percentage, Class, Pass/Fail Status for each student.
(3)SOFTWARE REQUIREMENT SPECIFICATION:
OVERALL DESCRIPTIONS:
MODULES:
[Link]
2.student_mark
[Link] report
MODULE DELIVARABLES:
Login
Basic Flow: This use case starts when the Faculty wishes to Login to the Student Marks
Analyzing System.
1. The System requests that the Faculty enter his/her name and password
2. The Faculty enters his/her name and password
3. The System validates the entered name and password and logs the Faculty into the System
Alternative Flows: Invalid Name/Password
If, in the Basic flow, the Faculty enters an invalid name and/or password, the system displays an
error message. The Faculty chooses to either return to the beginning of the Basic flow or cancel
the login, at which point the use case ends.
Pre-Conditions: None
Post-Conditions: If the use case was successful, the Faculty is now logged into the system. If
not, the system State is unchanged.
Student_Mark
Basic flow: The Faculty uses this usecase to enter marks for each student. The faculty enters the
following details namely Roll No, Student Name, Department, Marks for each student.
Alternative Flows: If faculty not entered any details or invalid marks then gives error Message
Pre-Conditions: The Faculty must logged into the system
Post-Conditions: If this Use case was successful, Student Mark Analysis Report will be
generated for the Students.
View Report
Basic flow: The Actor uses this usecase view the Report .The report contains the following
details Namely Roll No, Student Name, Marks in each subject, total, class, Pass/Fail Status, No
of subjects failed, Rank.
Apart from this there is a separate report Overall Pass percentage of class, No of students cleared
in First class, Overall Top 3 persons of the class.
Alternative Flow: If the Marks is not entered for all the students the use case will ask the faculty
to the enter the marks.
Pre-Conditions: The Faculty must entered marks for all the students in a class.
Post-Conditions: None
(4)DATA FLOW DIAGRAM
(5)TIME LINE CHART
(6)UML DIAGRAMS
6.1 UseCase Diagram
6.2 Activity Diagram
LOGIN PAGE
Coding:
public class Login {
private Jframe frame;
/** * Launch the application. */
Public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
Login window = newLogin();
[Link](true);} catch (Exception e) {
[Link]();
}}}); }
/** * Create the application. */
public Login() {
initialize();
}
/*** Initialize the contents of the frame. */
private void initialize() {
frame = newJFrame();
[Link]().setBackground(Color.LIGHT_GRAY);
[Link]().setFont(new Font("Tahoma", [Link], 15));
[Link](50, 50, 629, 330);
[Link](JFrame.EXIT_ON_CLOSE);
final JtextArea textArea = newJTextArea();
final JtextArea textArea_1 = newJTextArea();
Jlabel lblNewLabel = newJLabel(" USER NAME");
[Link](new Font("Tahoma", [Link], 15));
Jlabel lblNewLabel_1 = newJLabel("PASSWORD");
lblNewLabel_1.setFont(new Font("Tahoma", [Link], 15));
Jlabel lblNewLabel_2 = newJLabel("STUDENT MARK ANALYSING ");
lblNewLabel_2.setFont(new Font("Times New Roman", [Link], 25));
Jlabel lblNewLabel_3 = newJLabel("SYSTEM");
lblNewLabel_3.setFont(new Font("Times New Roman", [Link], 25));
Jbutton btnNewButton = newJButton("SUBMIT");
[Link](newActionListener() {
public void actionPerformed(ActionEvente) {
String name=[Link]();
String pas=textArea_1.getText();
if([Link]("mithilesh")&&[Link]("Mithilesh"){
//[Link](frame,"welcome");
Mainmodule cus = new Mainmodule();
[Link](null);
}else{[Link](frame,"getOut");}}});
MAIN PAGE
CODING
public class Mainmodule {
private JFrame frame;
/*** Launch the application. */
public static void main(String[] args) {
[Link](new Runnable() {
public void run() {
try {
Mainmodule window = new Mainmodule();
[Link](true);
} catch (Exception e) {[Link]();} }});}
/** * Create the application. */
public Mainmodule() {
initialize();
}
/** * Initialize the contents of the frame.*/
private void initialize() {
frame = new JFrame();
[Link]().setBackground(Color.LIGHT_GRAY);
[Link]().setFont(new Font("Tahoma", [Link], 15));
[Link](100, 100, 761, 341);
[Link](JFrame.EXIT_ON_CLOSE);
JcomboBox Myprofile = new JComboBox();
[Link](new Font("Tahoma", [Link], 11));
[Link](true);
[Link](new DefaultComboBoxModel(new String[] {"Cat 1", "Cat 2", "Cat 3"}));
JcomboBox semmarks = new JComboBox();
[Link](new Font("Tahoma", [Link], 11));
[Link](true);
[Link](new DefaultComboBoxModel(new String[] {"Sem 1","Sem 2","Sem
3","Sem 4","Sem 5","Sem 6","Sem 7","Sem 8"}));
JComboBox Document = new JComboBox();
[Link](new Font("Tahoma", [Link], 11));
[Link](true);
[Link](new DefaultComboBoxModel(new String[] {"Aadhar Card",
"Transfer Certficate", "Birth Certificate","AttendanceCertificate","Conduct Certificate","12th
Marksheet","10th Marksheet"}));
Jbutton btnNewButton = new JButton("MY PROFILE");
[Link](new ActionListener() {
public void actionPerformed(ActionEvent e) {}});
[Link](new Font("Tahoma", [Link], 15));
JButton btnNewButt0n_1 = new JButton("RESET PASSWORD");
btnNewButton_1.setFont(new Font("Tahoma", [Link], 15));
JButton btnNewButton_2 = new JButton("ATTENDANCE");
btnNewButton_2.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
}
});
btnNewButton_2.setFont(new Font("Tahoma", [Link], 15));
JButton btnNewButton_3 = new JButton("LOGOUT");
btnNewButton_3.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {}});
btnNewButton_3.setFont(new Font("Tahoma", [Link], 15));}}
(9)TESTING:
Test priority
(Low/Medium/High):Medium
2 Provide valid User should be The user is able Success Incase of wrong
password
Able to To login Password was
given an error
Login Successfully
Message box
was
displayed
3 Click login User should be User name and Success Incase user gives
able to navigate to password is wrong entry the
next page after validated and next sign in page
validation page is displayed remains active
(10)RESULT
The Student marks analyzing system was designed and implemented successfully.