Ppms PROJECT REPORT
Ppms PROJECT REPORT
Ppms PROJECT REPORT
PROBLEM STATEMENT
The REGD.NO for the students is a unique number through which admin or
hod will able to track the status the student placement details from any location
using internet.
Student updates their placement details by uploading the offer id, company
name, package, offer letter. These uploaded details can be tracked by HOD by
entering the student regd.no in the hod portal. The administrator and hod can
check the eligibility criteria of the students for selection in a company.
1
2. PPMS documentation – Requirements Elicitation
ID DETAILS FUNCTIONALITIES PRIORITIES
2
R20 PPMS must be able to give the selection Functional Must have
criteria of the company requirement.
R21 PPMS must be able to check the entered Functional Must have
student placement details.
R22 PPMS must be able to display all the Non-functional Must have
placement details of the student.
R24 PPMS must be able to display all the Functional Must have
students who are eligible for the
company.
R26 PPMS must be able to display the about Functional Must have
details.
3
Software Requirements:
DataBase: MySQL
HardwareRequirements:
Processor : Intel®core™i5
Hard Disc:40GB
4.REQUIREMENTS MODELING
The most important factor for the success of an IS project is whether the
4
software product satisfies its users' requirements. Models constructed from an
analysis perspective focuses on determining these requirements. This means
Requirement Model includes gathering and documenting facts and requests.
The use case model gives a perspective on many user requirements and
models them in terms of what the software system can do for the user. Before
the design of software which satisfies user requirements, we must analyze both
the logical structure of the problem situation, and also the ways that its logical
elements interact with each other. We must also need to verify the way in
which different, possibly conflicting, requirements affect each other. Then we
must communicate this understanding clearly and unambiguously to those who
will design and build the software.
Use-case diagrams graphically represents system behavior (use
cases).These diagrams present a high level view of how the system is used as
viewed from an outsider’s (actor’s) perspective. A use-case diagram may
contain all or some of the use cases of a system.
A use-case diagram can contain:
·actors ("things" outside the system)
.use cases (system boundaries identifying what the system should do)
interactions or relationships between actors and use cases in the system
including the associations, dependencies, and generalizations.
Use-case diagrams can be used during analysis to capture the
system requirements and to understand how the system should work. During
the design phase, you can use use-case diagrams to specify the behavior of the
system as implemented.
Identification of ACTORS:
5
Actors represent system users. They are NOT part of the system. They
represent anyone or anything that interacts with the system.
An actor is someone or something that:
Interacts with or uses the system
Provides input to and receives information from the system
Is external to the system and has no control over the use cases
The needs of the actor are used to develop use cases. This in sure that the
system will be what the user expected.
Graphical depiction:
An actor is a stereotype of a class and is depicted as a “stickman” on a use-case
diagram. For example,
Actors identified in the information system are:
1) STUDENT
2) ADMIN
3) HOD
6
And he has to logout the account after the desired actions complete.
7
perspective.A more detailed description might characterize a use case as:
A pattern of behavior the system exhibits
A sequence of related transactions performed by an actor and the
system.
TheUML notation for usecase is:
Login
Login
8
3. Use-case name: CHANGE PASSWORD
This use case allows user or admin or hod to change their login password.
Change Password
4. Use-case name: JOB DETAILS
This use case allows the actor to update their job details and these details
will be uploaded to database.
Job Details
5.Use-casename: UPDATION
This use case allows admin to update the details which are already existed and
make changes in the database.
Updation
6. Use-casename: INSERTION
This use case allows the actor to insert the new data into the database.
Insertion
Eligibility Criteria
9
Student Placement Details
9.Use-case name: STUDENT ELIGIBILITY
This use case allows the hod to view the list of the students who are
eligible.
Student Eligibility
Identification of RELATIONS
Association Relationship:
An association provides a pathway for communication. The communication
can be between use cases, actors, classes or interfaces. If two objects are
usually considered independently, the relationship is an association.
Login
Dependency Relationship:
A dependency is a relationship between two model elements in which a change
to one model element will affect the other model element. Use a dependency
relationship to connect model elements with the same level of meaning. We
can provide here
1. Include relationship:
It is a stereotyped relationship that connects a base use case to an inclusion use
case .An include relationship specifies how the behavior in the inclusion use
case is used by the base use case.
<<include>>
10
2. Extend relationship:
<<extend>> is used when you wish to show that a use case provides additional
functionality that may be required in another use case.
<<extend>>
11
present a high level view of how the system is used as viewed from an
outsider’s perspective.
Use-case diagrams can be used during analysis to capture the system
requirements and to understand how the system should work. During the design
phase, you can use use-case diagrams to specify the behavior of the system as
implemented.
FLOW OF EVENTS:
12
typically created in the elaboration phase.
Each use case is documented with flow of events
A description of events needed to accomplish required behaviour
Written in terms of what the system should do, NOT how it should do it
Written in the domain language, not in terms of the implementation
The flow of events for a use case is contained in a document called the use
case specification. Each project should use a standard template for the creation
of the use case specification. Includes the following
1. Use case name– Brief Description
2. Flow of events –
1. Basic flow
2. Alternate flow
3. Special requirements
4. Pre conditions
5. Post conditions
6. Extension points
13
Brief Description:
This use case is started by the user. It provides the capability for the user to
upload their placement details.
2.FLOW OF EVENTS BY STUDENT:
2.1 BASIC FLOW:
This use case begins with user logging in into the system by entering his/her
username and password
The system verifies that the password is valid(If the password is invalid,
Alternate flow 2.2.1 is executed)
The system prompts the user to check their register number.
The system prompts the screen containing fields like offer id, company name,
package, offer letter. We have to upload the offer letter into the database.
To confirm the placement details, we must submit.
The system prompts the screen that file uploaded successfully.
2.2 ALTERNATE FLOWS:
2.2.1 Invalid password: An Invalid password is entered, The user can re-enter a
password or terminate the use case
2.2.2 Missing details: All fields on the screen must be entered or terminate the
use case
3. SPECIAL REQUIREMENTS:
There are no special requirements for this use case
4. PRECONDITIONS:
The user must register before logging in
5. POST CONDITIONS:
There are no post conditions
14
6.EXTENSION POINTS:
There are no extension points.
This use case begins with admin logging in into the system by entering his/her
username and password
The system verifies that the password is valid(If the password is invalid,
Alternate flow 2.2.1 is executed)
The system prompts the admin to select the desired activity:
Updation of the data into the database.
Insertion of the data into the database.
If the activity selected is UPDATE, the admin can make changes into database
by uploading a new csv file.
If the activity selected is INSERT, then the admin can insert the new data into
the database by uploading a csv file.
If the activity selected is ELIGIBILITY CRITERIA, then the system displays
fields like company name, backlogs and cgpa. After entering the above fields
the system displays the list of the students who are eligible for the above
criteria.
2.2 ALTERNATE FLOWS:
2.2.1 Invalid password: An Invalid password is entered, The admin can re-
enter a password or terminate the use case
2.2.2 Missing details: All fields on the screen must be entered or terminate the
15
use case
3. SPECIAL REQUIREMENTS:
There are no special requirements for this use case
4. PRECONDITIONS:
The admin details must be maintained before this use case begins.
5. POST CONDITIONS:
There are no post conditions
6. EXTENSION POINTS:
There are no extension points.
This use case begins with hod logging in into the system by entering his/her
username and password
The system verifies that the password is valid(If the password is invalid,
Alternate flow 2.2.1 is executed)
The system prompts the hod to select the desired activity:
There displays the activities like SELECTION CRITERIA and PLACEMENT
DETAILS.
16
If the activity selected is selection criteria, the hod can enter the criteria to
check student eligibility. This contains fields like company name, cgpa, no.of
backlogs. After entering the system displays the list of students eligible for
above criteria.
If the activity selected is placement details, then the hod need to enter the
student register number inorder to access the student placement details. Also
the hod can download the student job offer letters.
2.2.1 Invalid password: An Invalid password is entered, The hod can re-enter
a password or terminate the use case
2.2.2 Missing details: All fields on the screen must be entered or terminate the
use case
3. SPECIAL REQUIREMENTS:
There are no special requirements for this use case
4. PRECONDITIONS:
The HOD details must be maintained before this use case begins.
5. POST CONDITIONS:
There are no post conditions
6. EXTENSION POINTS:
There are no extension points.
17
the states are activities representing the performance of operations and the
transitions are triggered by the completion of the operations. The purpose of
Activity diagram is to provide a view of flows and what is going on inside a
use case or among several classes. You can also use activity diagrams to model
code-specific information such as a class operation.
Activity diagrams are very similar to a flowchart because you can model a
work flow from activity to activity. An activity diagram is basically a special
case of a state machine in which most of the states are activities and most of the
transitions are implicitly triggered by completion of the actions in the source
activities.
Activity Diagrams also may be created at this stage in the life cycle. These
diagrams represent the dynamics of the system. They are flow charts that are
used to show the work flow of a system; that is, they show the flow of control
from activity to activity in the system, what activities can be done in parallel,
and any alternate paths through the flow.
At this point in the life cycle, activity diagrams may be created to represent the
flow a cross use cases or they may be created to represent the flow within a
particular use case.
Later in the life cycle, activity diagrams may be created to show the work flow
for an operation.
The following tools are used on the activity diagram tool box to model activity
diagrams:
Activities:
An activity represents the performance of some behavior in the work flow.
NewActivity
Transitions:
Transitions are used to show the passing of the flow of control from activity to
activity. They are typically triggered by the completion of the behavior in the
18
originating activity.
Decision Points:
When modeling the work flow of a system it is often necessary to show where
the flow of control branches based on a decision point. The transitions from a
decision point contain a guard condition, which is used to determine which
path from the decision point is taken.
Decisions along with their guard conditions allow you to show alternate paths
through a work flow.
Decision point
Start state:
A start state explicitly shows the beginning of a work flow on an activity
diagram or the beginning of the execution of a state machine on a state chart
diagram.
End state:
An End state represents a final or terminal state on an activity diagram or state
chart diagram. Place an end state when you want to explicitly show the end of a
work flow on an activity diagram or the end of a state chart diagram.
Transitions can only occur into an end state; however, there can be any number
of end states per context.
ACTIVITY DIAGRAM FOR STUDENT
19
ACTIVITY DIAGRAM FOR ADMINISTRATOR:
20
ACTIVITY DIAGRAM FOR HOD:
21
8.CONSTRUCTION OF PROTOTYPES
22
As the requirements for a system emerge in the form of use cases, it is
sometimes helpful to build simple prototypes of how some of the use cases will
work. A prototype is a working model of part of the system usually a program
with limited functionality that is built to test out some aspect of how the system
will work. Prototypes can be used to help elicit requirements. Showing users
how the system might provide some of the use cases often produces a stronger
reaction than showing them a series of abstract diagrams. Their reaction may
contain useful information about requirements.
23
24
25
26
27
28
29
30
31
32
33
9.CONSTRUCTION OF SEQUENCE DIAGRAMS.
1.An object is shown as a box at the top of a dashed vertical line. Object names
can be specific (e.g., Algebra 101, Section 1) or they can be general (e.g., a
course offering).Often, an anonymous object (class name may be used to
represent any object in the class.)
2. Each message is represented by an Arrow between the lifelines of two
objects. The order in which these messages occur is shown top to bottom on the
page. Each message is labeled with the message name.
There are two main differences between sequence and collaboration diagrams:
sequence diagrams show time-based object interaction while collaboration
diagrams show how objects associate with each other. A sequence diagram has
two dimensions: typically, vertical placement represents time and horizontal
placement represents different objects.
ELEMENTSOFSEQUENCEDIAGRAM:
Objects
Links
Messages
Focus of control
34
Object life line
Collaboration diagrams are the second kind of interaction diagram in the UML
diagrams. They are used to represent the collaboration that realizes a use case.
The most significant difference between the two types of interaction diagram is
that a collaboration diagram explicitly shows the links between the objects that
participate in a collaboration, as in sequence diagrams, there is no explicit time
dimension.
Message labels in collaboration diagrams:
35
Messages on a collaboration diagram are represented by a set of symbols that
are the same as those used in a sequence diagram, but with some additional
elements to show sequencing and recurrence as these cannot be inferred from
the structure of the diagram. Each message label includes the message
signature and also a sequence number that reflects call nesting, iteration,
branching, concurrency and synchronization within the interaction.
The formal message label syntax is as follows:
[predecessor] [guard-condition] sequence-expression [return-value ':=']
message-name' ('[argument-list]')'
A predecessor is a list of sequence numbers of the messages that must occur
before the current message can be enabled. This permits the detailed
specification of branching pathways. The message with the immediately
preceding sequence number is Assumed to be the predecessor by default, so if
an interaction has no alternative path ways the predecessor list may be omitted
without any ambiguity. The syntax for a predecessor is as follows:
sequence-number{ ','sequence-number}'I'
The 'I' at the end of this expression indicates the end of the list and is only
included when an explicit predecessor is shown.
Guard conditions are written in Object Constraint Language (OCL),and are
only shown where the enabling of a message is subject to the defined condition.
A guard condition may be used to represent the synchronization of different
threads of control.
A sequence-expression is a list of integers separated by dots ('.') optionally
followed by a name (a single letter), optionally followed by a recurrence term
and terminated by a colon .A sequence-expression has the following syntax:
integer{'.'integer} [name][recurrence]':'
In this expression integer represents the sequential order of the message. This
may be nested within a loop or a branch construct, so that, for example,
message 5.1occurs after message5.2 and both are contained within the
activation of message5.
The name of a sequence-expression is used to differentiate two concurrent
messages since these are given the same sequence number. For example,
messages 3.2.1 and 3.2.1b are concurrent within the activation of message3.2.
Recurrence reflects either iterative or conditional execution and its syntax is as
36
follows:
Branching: '[ 'condition-clause‘ ] ,
Iteration:‘* ‘ ‘ [ ‘ iteration-clause ‘ ] '
Elements:
Objects Messages, Path ,Sequence Numbers, Links
CLASS:
A Class a description of a group of objects with common properties
(attributes),common behavior(operations), common relationships to other
objects, and common semantics.
Thus,a class is a template to create objects. Each object is an instance of some
class and objects cannot be instances of more than one class.
Classes should be named using the vocabulary of the domain.
For example, the enter details class may be defined with the following
characteristics :
Attributes –name, address, mobile number etc.
Operations-retrieve login information
Each object would have a value for the attributes and access to the operations
specified by the Course Offering class.
In the UML, classes are represented as compartmentalized rectangles. The top
compartment contains the name of the class.
The middle compartment contains the structure of the class(attributes).
The bottom compartment contains the behavior of the class (operations)as
shown below.
OBJECT:
37
AN OBJECT IS a representation of an entity, either real-world or conceptual.
An object is a concept, abstraction, or thing with well defined boundaries and
meaning for an application.
Each object in a system has three characteristics: state, behavior, and identity.
STATE :
THE STATE OF an object is one of the possible conditions in which it may
exist. The state of an object typically changes over time, and is defined by a set
of properties (called attributes), with the values of the properties, plus the
relationships the object may have with other objects.
For example, a course offering object in the login system may be in one of two
states: open and closed. It is available in the open state if registration details is
valid otherwise closed.
BEHAVIOR:
Behavior determines how an object responds to requests from other objects.
ATTRIBUTES:
Attributes are part of the essential description of a class. They belong to the
class, unlike objects, which instantiate the class. Attributes are the common
structure of what a member of the class can 'know'. Each object will have its
own, possibly unique, value for each attribute.
Guidelines for identifying attributes of classes are as follows:
Attributes usually correspond to nouns followed by prepositional phrases
Keep the class simple; state only enough attribute to define object state.
Attributes are less likely to be fully described in the problem statement.
Omit derived attributes.
Do not carry discovery attributes to excess.
38
STEREOTYPES AND CLASSES:
As like stereotypes for relationships in use case diagrams. Classes can also
have stereotypes. Here a stereotype provides the capability to create a new kind
of modeling element. Here, we can create new kinds of classes. Some common
stereotypes for a class are entity Class, boundary Class, control class, and
exception.
Entity Classes
An entity class models information and associated behavior that is generally
long lived.
This type of class may reflect areal-world entity or it may be needed to
perform tasks internal to the system.
They are typically independent of their surroundings; that is, they are not
sensitive to how the surroundings communicate with the system.
Boundary Classes:
Control Classes:
Control classes model sequencing behavior specific to one or more use case
Control classes coordinate the events needed to realize the behavior specified
in the use case.
Control classes typically are application-dependent classes.
39
In the early stages of the Elaboration Phase, a control class is added for each
actor/use case pair. The control class is responsible for the flow of events in
the use case.
In the early stages of the Elaboration Phase, a control class is added for each
actor/use case pair. The control class is responsible for the flow of events in
the use case.
All systems are made up of many classes and objects. System behaviour is
achieved through the collaborations of the objects in the system. Two types of
relationships in CLASS diagram are:
1. Association Relationship
2. Aggregation Relationship
➢ Association Relationship:
2. Aggregation Relationship:
These allow objects to be build from other objects. The super-sub class
hierarchy is a relationship between classes, where one class is the parent class
40
of another class.
NAMING RELATIONSHIP:
ROLE NAMES:
The end of an association where it connects to a class is called an association
role.
Role names can be used instead of association names.
A role name is a noun that denotes how one class associates with
another. The role name is placed on the association near the class that it
modifies, and may be placed on one or both ends of an association line.
MULTIPLICITY INDICATORS:
41
1 Exactly one
0... * Zero or more
1... * One or more
0... 1 Zero or one
5... 8 Specific range (5, 6, 7, or 8)
4... 7, 9 Combination (4, 5, 6, 7, or 9)
42
CLASS DIAGRAM FOR ADMIN:
43
12.Analyzing the object behavior by constructing
the UML State Chart diagram
Use cases and scenarios provide a way to describe system behavior; in the form
of interaction between objects in the system. Sometimes it is necessary to
consider inside behavior of an object.
A state chart diagram shows the states of a single object, the events or
messages that cause a transition from one state to another, and the actions that
result from a state change. As in Activity diagram , state chart diagram also
contains special symbols for start state and stop state.
State chart diagram cannot be created for every class in the system , it is
only for those class objects with significant behavior.
State chart diagrams are closely related to activity diagrams. The main
difference between the two diagrams is state chart diagrams are state centric,
while activity diagrams are activity centric. A state chart diagram is typically
used to model the discrete stages of an object’s lifetime, whereas an activity
diagram is better suited to model the sequence of activities in a process.
STATE:
44
diagram. In an ESU the object for Course Offering may have in the following
states, initialization, open and closed state. These states are obtained from the
attribute and links defined for the object. Each state also contains a
compartment for actions.
Actions:
Actions on states can occur at one of four times:
• on entry
• on exit
• do
• on event.
on entry :What type of action that object has to perform after entering into the
state.
on exit : What type of action that object has to perform after exiting from the
state.
Do :The task to be performed when object is in this state, and must to continue
until it leaves the state.
on event : An on event action is similar to a state transition label with the
following
syntax: event(args)[condition] : the Action
State Transition:
A state transition indicates that an object in the source state will
perform certain specified actions and enter the destination state when a
specified event occurs or when certain conditions are satisfied. A state
transition is a relationship between two states, two activities, or between an
activity and a state. You can show one or
You can show one or more state from a state as long as each transition is
unique. Transitions originating from a state cannot have the same event, unless
there are conditions on the event.
Transitions are labeled with the following syntax:
event (arguments) [condition] / action ^ target. send Event (arguments)
45
Only one event is allowed per transition, and one action per event.
State Details :
Actions that accompany all state transitions into a state may be placed
as an entry action within the state. Like wise that accompany all state
transitions out of a state may be placed as exit actions within the state.
Behavior that occurs within the state is called an activity.
An activity starts when the state is entered and either completes or is
interrupted by an outgoing state transition. The behavior may be a simple
action or it may be an event sent to another object.
UML notation for State Details:
StateName
entry/ simple action
entry/ ^class name.eventname
do/ simple action
do/ ^class name.event name
exit/ ^class name.event name
Component diagrams:
In a large project there will be many files that make up the system. These
files will have dependencies on one another. The nature of these dependencies
will depend on the language or languages used for the development and may
exist at compile-time, at link-time or at run-time. There are also dependencies
between source code files and the executable files or byte code files that are
46
derived from them by compilation. Component diagrams are one of the two
types of implementation diagram in UML. Component diagrams show these
dependencies between software components in the system. Stereotypes can be
used to show dependencies that are specific to particular languages also.
47
COMPONENT DIAGRAM FOR ADMIN:
48
Deployment diagrams:
49
14. SAMPLE APPLICATION CODE AND DATABASE
Various modules in the system are
1.Student Registration
2.Student Login
3.Student placement uploadation
4.Admin login
5.Admin data updation
6.Admin data insertion
7.Admin eligibility criteria
8.HOD login
9.HOD selection criteria
10.HOD placement details
50
CODE FOR MAIN PAGE: (PPMS)
51
CODE FOR STUDENT LOGIN:
52
CODE FOR ADMIN LOGIN:
53
CODE FOR HOD LOGIN:
54
CODE FOR STUDENT DETAILS:
55
56
57
CODE FOR ADMIN ACCESS:
58
59
CODE FOR HOD ACCESS:
60
61
62
CODE FOR DATABASE CONNECTION:
63
15. TESTING
The main purpose of testing PPMS is to ensure that all the activities and
functionalities of this software run smoothly with no errors and it remains
protected.
FOR STUDENT :
FOR ADMIN :
64
Test case no Functionality to be Actual input Actual Expected Status
checked output output
3. Verify admin update Given invalid data Generates Deny Request Fail
/insert data report with
warning
65
4
66
COMPANY’S TABLE:
MARKS TABLE:
67
PACKAGE TABLE:
STAFF TABLE:
STUDENT TABLE:
68
69
PPMS MAIN PAGE:
70
PPMS STUDENT ACCESS:
71
PPMS ADMIN LOGIN:
72
PPMS ADMIN SELECTION CRITERIA:
73
PPMS HOD LOGIN:
74
PPMS HOD VIEWING STUDENT PLACEMENT DETAILS:
75
PPMS HOD VIEWING LIST OF ELIGIBLE STUDENTS:
76
17. CONCLUSION
Maximum work goes manually in the present placement system which makes it take
time to avail changes. This includes main problems like searching for the data of
students and sorting them along with it. Also, updating student data is a cumbersome
job and does not have a method to notify the student in time which makes the
management of the placements very difficult. In the proposed system, all of these
problems become automated. The registration of the student for an upcoming
placement, the addition of a new user, notifying students, sharing information, the
privacy of the student, etc is all met. The admin validates the information and gives
the student list based on the criteria required which otherwise would have been very
difficult to manage.
>This system provides us the easy access to the job details of the
students.
>This system helps in checking the eligible students according to the
given criteria.
77
REFERENCES
1) Object Oriented Analysis and Design 2005 by Mike O’docherty.
2) Visual Modeling with Rational Rose 2002 by Teny Quatran.
3) Applying UML and patterns: An Introduction to Object Oriented
Analysis and Design, Third Edition 2005 by Craig Larman.
4) Using UML: Software Engineering with objects and components,
Second Edition 2006 by Perdita Stevens, R. J. Pooley.
5) The elements of UML style by Scott W. Ambler.
6) The Unified Modelling Language User Guide by Grady Booch, James
RumbaughIvar Jacobson.
Web Links:
78