UNIFIED LIBRARY MANAGEMENT SYSTEM
TABLE OF CONTENTS Chapters 1
&
( 3 5
Contents Intro!"t#on 1.1 App$#"at#ons 1.& Ana$'s#s 1.( O)*e"t#+es L#st o, UML D#agra-s &.1 C$ass D#agra&.& O)*e"t D#agra&.( Use Case D#agra&. Se!en"e D#agra&.3 Co$$a)orat#on D#agra&.5 A"t#+#t' D#agra&.2 State Chart D#agra&.4 Dep$o'-ent D#agra&.0 Co-ponent D#agraData Bases Use #n L#)rar' Manage-ent For6ar an Re+erse Approa"h F!t!re S"ope Con"$!s#on
Page No. %& %( %( %/%0 %0/11 11/1 1/12 14/&% &1/& &3/&4 &0/(% (1/(( (/(3 (5/(4 % %
1
ONLINE 7OB PORTAL MANAGEMENT SYSTEM
TABLE OF CONTENTS Chapters 1
Contents Intro!"t#on 1.1 P!rpose Mo!$es &.1 A-#n &.& Co-pan' &.(7o) See8er Data)ases Use #n 7o) Porta$ L#st o, UML D#agra-s .1 C$ass D#agra.& O)*e"t D#agra.( Use Case D#agra. Se!en"e D#agra.3 Co$$a)orat#on D#agra.5 A"t#+#t' D#agra.2 State Chart D#agra.4 Dep$o'-ent D#agra.0 Co-ponent D#agra-
&
(
Page No. & & ( (
UNIFIED LIBRARY MANAGEMENT SYSTEM
INTRODUCTION Unified Library Application System emphasizes on the online reservation, issue and return of books. This system globalizes the present library system. system. Using this application the member can reserve any book from anywhere in the world. Library management system is a proect which aims in developing a computerized system to maintain all the daily work of library .This proect has many features which are generally not available 2
in normal library management systems like facility of user login and a facility of teachers login .!t also has a facility of admin login through which the admin can monitor the whole system. !t has also a facility where student after logging in their accounts can see list of books issued and its issue date and return date and also the students can re"uest the librarian to add new books by filling the book re"uest form. The librarian after logging into his account i.e. admin account can generate various reports such as student report, issue teacher and book report.
Let !s *!st ha+e an o+er+#e6 o, the !n#,#e $#)rar' app$#"at#on s'ste-9 •
Librarian lends books and magazines
•
Librarian maintains the list of all the members of library
•
#orrower makes reservation online
•
#orrower can remove reservation online
•
Librarian issues books to the borrower
•
Librarian calculates dues to be paid by the borrower
•
#orrower issues$returns books and$or magazines
•
Librarian places order about the re"uirements to the publisher librarian
•
Librarian updates system
TE:TUAL ANALYSIS ANALYSIS ;a< ;a< ACTO ACTORS RS
i.
Librarian
ii. #orro rrower
;)< ;)< =ERB =ERBS S #.
Borro6er9
%. Logs Logs into into the the syst system em &. #rowses #rowses$sea $search rches es for book bookss or magaz magazine iness '. (ake (akes$ s$rem remov oves es reser reserva vati tion on 3
). *iews *iews results results and reports reports from the the unified unified library library applica application tion system system ##. ##. L#)r L#)ra ar#an r#an99
%. (ana (anage gess and vali valida dates tes mem membe bers rs &. *iew *iew repo report rtss from from the the syste system m '. !ssu ssues bo books ). +alcu alcula late tess dues dues . Takes kes book bookss -. (ainta (aintains ins list of book bookss and and magazi magazine ne
AIMS AND OB7ECTI=ES OF UNIFIED LIBRARY MANAGEMENT • • • • • •
nline book issue /e"uest column for librarian for providing new books A separate column for digital library Student login page where student can find books issued by him$her and date of return. A search column to search availability of books A teacher login page where teacher can add any events being organized in the college and important suggestions regarding books.
LIST OF UML DIAGRAMS9
%. +lass lass 0iag iagram ram &. be bect ct 0iag 0iagra ram m '. Use Use cas casee 0ia 0iagr gram am ). Se"u Se"uen ence ce 0iag 0iagra ram m . +olla +ollabo bora ratio tion n 0iag 0iagram ram -. Acti Activi vity ty 0iag 0iagra ram m 1. Stat Statee cha chart rt 0iag 0iagra ram m 2. 0epl 0eploy oyme ment nt 0ia 0iagr gram am 3. comp compon onen entt 0ia 0iagr gram am
4
CLASS DIAGRAM9
+lass diagrams is the main building block of any obect oriented solution. !t shows the classes in a system, attributes and operations of each class and the relationship between each class. !n most modeling tools a class has three parts, name at the top, attributes in the middle and operations or methods at the bottom. !n large systems with many related classes, classes are grouped together to create class diagrams. 0ifferent relationships between classes are shown by different types of arrows. +lass diagrams are the most common diagram found in modeling obect4oriented s ystems. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. 5ou use class diagrams to model the static design view of a system. 6or the most part, this involves modeling the vocabulary of the system, modeling collaborations, or modeling schemas.
C$ass #agra-s are a$so the ,o!nat#on ,or a "o!p$e o, re$ate #agra-s9 component diagrams 7 deployment diagrams. +lass diagrams are important not only for visualizing, specifying, and documenting structural models, but also for constructing e8ecutable systems through forward and reverse engineering.
The "o-ponents are9
a9 +lass b9 /elationship:
The ,or-s o, re$at#onsh#p are9
%. Assoc sociat iation &. ;ene ;enera rali liza zati tion on '. 0ependency 1. Asso"#at#on •
•
•
•
Association is a structural relationship where obects of one class are connected to obects of another class.
5
•
;raphically, an association is rendered as a solid line connecting the same or different classes.
•
An instance of an association is called a link.
•
There are ,o!r aorn-ents that app$' to asso"#at#ons 9
&.
–
–
/ole
–
(ultiplicity
–
Aggregation.
Gene Ge nera ra$# $#>a >at# t#on on
;eneralizations are =is4a4kind4of= relationship. !t connect generalized classes to more4 specialized ones in what is known as subclass$super class or child$parent relationships. •
•
•
;eneralization is a relationship between general thing >parent9 and specific kind of thing >child9 ;eneralization is rendered as a solid directed line with a large open arrowhead, pointing to the parent. A child inherits the properties of its parents, their attributes and operations. ften, the child has attributes and operations in addition to those found in its parents.
(. Depe Depen nen" en"' '
0ependencies are ?using relationships@. •
A relationship in which a change in specification of one thing may affect affect another.
•
A dependency is rendered as a dashed directed line.
•
0ependencies are used to show one thing using another.
•
•
0ependencies are used to show that one class uses another class as an argument in the signature of an operation. 0ependencies are very much a using relationship 4 if the used class changes, the operation of the other class may be affected, because the used class may now present a different interface or behavior. 6
T'pes o, Re$at#onsh#ps9
%. &. '. ).
ne ne to to ne ne /ela /elatio tions nshi hip p ne ne to (any (any /elat /elatio ionsh nship ip (any (any to ne ne /elat /elatio ions nshi hip p (any (any to to (any (any /el /elati ation onsh ship ip
1. One One to One One Re$ Re$at at#o #ons nsh# h#p9 p9 ne to many relationship is represented using the symbol >%..%9. &. One to Man' Man' Re$at# Re$at#ons onsh#p h#p99 ne to (any /elationship can be represented using the symbol >%..9. (. Man' Man' to to One One Re$a Re$at# t#on onsh sh#p #p99 ne to (any /elationship can be represented using the symbol >..%9. . Man' Man' to Man' Man' Re$a Re$at#o t#onsh nsh#p9 #p9 (any to (any /elationship can be represented using the symbol >..9.
Dra6#ng C$asses
+lasses define the attribute values carried by each symbol instance and the operations that each symbol performs or undergoes. Bhen representing a class, you: • • • • • •
0raw a class symbol
=ISIBILITY
7
To specify the visibility of a class member >i.e., any attribute or method9, these notations must be placed before the memberDs name E
Fublic
4
Frivate
G
Frotected
$
H
NOTATIONS USED IN CLASS DIAGRAM9
Nota>can t#onbe combined with Des"one r#ptof #onthe 0erived others9 +lass name Fackage A class is a classifier classifier which which describes a set of obects that share the same
+lass name Attributes perations
Bhen class is shown with three compartments, the middle compartment holds a list of attributes and the bottom compartment holds a list of operations. Attributes and operations should be left ustified in plain face, with the first letter of the names in lower case.
CLASS DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM9
8
F!n"t#ona$#t#es o, C$ass D#agra- 9 • • •
Librarian: To maintain and update the records and also to cater the needs of the users /eader:
OB7ECT DIAGRAM9
bect 0iagrams, sometimes referred as !nstance diagrams are very similar to class diagrams. As class diagrams they also show the relationship between obects but they use real world e8amples. They are used to show how a system will look like at a given time. #ecause there
9
is data available in the obects they are often used to e8plain comple8 relationships between obects. bect diagrams model the instances of things contained in class diagrams. An obect 0iagram shows a set se t of obects and their relationships at a t a point in time. 5ou 5ou use obect diagrams to model the static design view or static process view of a System. This involves modelling a snapshot of the system at a moment in time and rendering a set of obects, their state, and their relationships. bect diagrams are not only important for visualizing, specifying, and documenting structural models, but also for constructing the static aspects of systems through forward and reverse engineering.
O)*e"t #agra-s "o--on$' "onta#n
I bects I Links
NOTATIONS USED IN OB7ECT DIAGRAM9
bect name
bect is an instance of instance of a class or class or an interface an interface..
bect name:
class of the instance is unknown or not specified !nstance name, >package9 specified.
OB7ECT DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM9 Manages
Manages
L#)rar#an
L#)?na-e@ABC Sear"h@1%
Manage
B19 Boo8 F9 Sear"h B?na-e@ Sear"h#ng@ Boo8e@ Issue/return book ID@
Manages
B&9 Boo8 S19 St!ent B?na-e@ St!ent?na-e@ Boo8e@
Issue/return St! St!en entt #@ #@
10
F!n"t#ona$#t#es o, O)*e"t D#agra-9
%. Library &. Librarian '. #ooks 0atabase ). User . *endor
USE CASE DIAGRAM •
Use case diagrams gives a graphic overview of the actors involved in a system, different functions needed by those actors and how these different functions are interacted. Use case diagram comprises of use cases and actors such that there would be various kinds of relationships r elationships among the use cases and the actors. A use case diagram shows all the actions that a particular actor needs to perform 11
throughout the system at every and any point of time. There would be only one use case diagram per each system. A use case specifies the behaviour of a system or a part of a system •
Use case is a description of a set of se"uences of actions and variants that a system performs to yield an observable result of value to an actor.
•
Use cases focus on the issues of highest risk.
Use "ase #agra-s "o--on$' "onta#n9
•
Use cases
•
Actors
•
0ependency, generalization, and association relationships
•
•
Fackages, which are used to group elements of the model into larger chunks.
•
!nstances of use cases to visualize a specific e8ecuting system.
NOTATIONS USED IN USE CASE DIAGRAM9 Notat#on
Des"r#pt#on
12
Subect is presented by a rectangle with subect name in upper corner with applicable use cases inside the rectangle and actors 4 outside of the system boundaries. Use cases visually located inside the system bound the use cases applicable to the subect >but not necessarily owned by the subect9.
The nesting >ownership9 of a use case by a classifie nested classifiers.
The names of abstract actors should be shown in it All actors must have names.
actors is rendered as a solid directed line with a lar between classes9.
C8tend is a directed relationship
13
An include relationship is a directed relationship
USE CASE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM9
14
F!n"t#ona$#t#es o, Use Case D#agra- 9 A"tors +s Use Cases9
1. L#)rar#an I !ssue a book I Update and maintain records I /e"uest the vendor for a book I Track complaints
&. User I /egister I Login I Search a book I /e"uest for isse I *iew history I /e"uest to the Librarian I Unregister (. Boo8s Data)ase I Update records I Show books status . =enors I Frovide books to the library I Fayment acknowledgement
SEUENCE DIAGRAM
This diagram, as the name suggests, contains the se"uence of flow of actions that are processed through a system and the life lines of the entities, when and how are they accessed. !t also contains the security features like which entity can process which entity and which one is visible, etc. There can be many number of se"uence diagrams per each activity being done.
15
The "o-ponents are9
a9 b9 c9 d9 e9
Actor bect (essages Lifeline 6ocu 6ocuss of +ont +ontro roll
Se!en"e #agra-s sho6 so-e #n,or-at#on9 •
bects$classes
•
(essages
•
Se"uence
•
+onditional
•
/epetition
•
(essages to self
NOTATIONS USED IN SEUENCE DIAGRAM 9 Notat#on
Des"r#pt#on
Selector could be used to specify some lifeline fro collection.
C8ecution
16
verlapping e8ecutions on the same lifeline are represented by overlapping rectangles.
verlapping e8ecution specifications on the same l
Synchronous call typically represents operation cal
+reate message is sent to lifeline to create itself.
0elete message .
/eply message to an operation call as a dashed line
SEUENCE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM9
17
F!n"t#ona$#t#es o, Se!en"e D#agra- 9 • • • • • • •
/egister Login Search a book /e"uest for issue book *iew history /e"uest to the Librarian Unregister
COLLABORATION DIAGRAM 18
This diagram is a polymorphic form of the se"uence diagram in which the representation is different but application is the same. !f we are able to create one se"uence diagram, then its very simple to create its collaboration diagram with a single key click that varies from software to software. There can be many number of collaboration diagrams per each activity being done because there can be many number of se"uence se"uence diagrams. +ollaboration diagram displays obect interactions organized around obects and their links to one another.
The Co-ponents are9
a9 Actor b9 bect c9 Link Uses o, Co$$a)orat#on D#agra•
M!$t# o)*e"t
Title:
Con#t#ona$ -essages 4 +onditional messages mean that under certain conditions the message will be sent and under other conditions it wonJt 4 The message is sent when the condition in the s"uare brackets is true
•
•
•
Repet#t#+e -essages 4 The message repeats while the condition in the s"uare brackets is true Notat#on
Co$$a)orat#on #agra-s sho6 so-e #n,or-at#on9
19
•
bects$classes
•
(essages
•
Se"uence
•
+onditional
•
/epetition
•
(essages to self
NOTATIONS USED IN COLLABORATION DIAGRAM9
E$e-ent an #ts es"r#pt#on
S'-)o$
O)*e"t9 The obects interacting with each other in the system. 0epicted by a rectangle with the name of the obect in it, preceded by a colon and underlined. Re$at#onAsso"#at#on9 A link connecting the associated obects. Kualifiers can be placed on either end of the association to depict cardinality. Messages9 An arrow pointing from the commencing obect to the destination obect shows the interaction between the obects. The number represents the order$se"uence of this interaction.
COLLABORATION DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM9
20
F!n"t#ona$#t#es o, Co$$a)orat#on D#agra- 9
• • • •
User Login and Authentication Search book operation for /eader Acknowledge and !ssue books to the users by the Librarian Frovide books re"uested by the Librarian from the *endor *endor
21
ACTI=ITY DIAGRAM9
This diagram denotes the structural flow of the activities in the form of flow chart with decision bo8es enhanced and hence is also used for troubleshooting like raising e8ceptions when a particular action is done and the alternative to be done when something abnormal is done. There can be only one activity diagram for the entire system including all the activities that a system can perform. Activity diagrams represent workflows in an graphical way. They can be used to describe business workflow or the operational workflow of any component in a system. Sometimes activity diagrams are used as an alternative to State machine diagrams. +heck diagrams. +heck out this wiki article to article to learn about symbols and usage of activity diagrams. Activity diagram shows the flow of events within our system.
The "o-ponents are9
a9 b9 c9 d9 e9 f9
Start State Cnd State Transit sition 0eci 0ecisi sio on #o #o8 Synch Synchro roni nizat zatio ion n #ar #ar Swim Lane
NOTATIONS USED IN ACTI=ITY DIAGRAM 9
The start symbol represents the beginning of a process or workflow in an activity diagram. !t can be used by itself or with a note symbol that e8plains the starting point.
The activity symbol is the main component of an activity diagram. These shapes indicate the activities that make up a modeled process.
22
The connector symbol is represented by arrowed lines that show the directional flow, or control flow, of the activity. An incoming arrow starts a step of an activity act ivity once the step is completed, the flow continues with the outgoing arrow
The oin symbol, or synchronization bar, is a thick vertical or horizontal line. !t combines two concurrent activities and re4introduces them to a flow where only one activity occurs at a time.
A fork is symbolized with multiple arrowed lines from a oin. !t splits a single activity flow into two concurrent activities.
The decision symbol is a diamond shape it represents the branching or merging of various flows with the symbol acting as a frame or container.
The note symbol allows the diagram creators or collaborators to communicate additional messages that donDt fit within the diagram itself.
The receive signal symbol demonstrates the acceptance of an event. After the event is received, the flow that comes from this action is completed.
The send signal symbol means that a signal is being sent to a receiving activity, as seen above. The shallow history pseudostate symbol represents a transition that invokes the last active state.
The option loop symbol allows the creator to model a repetitive se"uence within the option loop symbol.
The flow final symbol shows the ending point of a processD flow. Bhile a flow final symbol marks the end of a process in a single flow, an end symbol represents the completion of all flows in an activity. a ctivity.
The end symbol represents the completion of a process or workflow. 23
ACTI=ITY DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM9
Iss!e Boo8
Ret!rn Boo8 24
F!n"t#ona$#t#es o, A"t#+#t' D#agra- 9 • • • • • •
User Login and Authentication Search book operation for /eader Acknowledge and !ssue books to the users by the Librarian Frovide books re"uested by the Librarian from the *endor *endor #ill payment from the Librarian to the *endor *endor Status of the books updated in the #ooks 0atabase
STATE STATE CART DIAGRAM9
25
State machine diagrams are similar to activity diagrams although notations and usage changes a bit. They are sometime known as state diagrams or start chart diagrams as well. These are very useful to describe the behavior of obects that act different according to the state they are at the moment. #elow State machine diagram show the basic states and actions. State chart diagram show a life cycle of a single class. The state is a condition where the obect may be in. States are represented by rectangles with rounded corners. Cach state is labelled with a state name. States may also be labelled with an activity. The "o-ponents are9
a9 Start sta state b9 Cnd state c9 State d9 Transi ansiti tion on
T'p#"a$ s'ste- states -#ght )e an' o, the ,o$$o6#ng9
Baiting Baiting for user to enter password Meating chemical mi8ture Baiting for ne8t command Accelerating engine (i8ing ingredients Baiting for instrument data 6illing tank
!dle
NOTATIONS NOTATIONS USED IN STATE STATE CART CA RT DIAGRAM9
1. An #n#t#a$ #n#t#a$ pse!o pse!o state state #s sho6n sho6n as a s-a$$ s-a$$ so$# so$# ,#$$e ,#$$e "#r"$e. "#r"$e.
26
Initial pseudo state transitions to aiting !or "ser Input state
&. A ter ter-#nate -#nate pse!o pse!o state state #s #s sho6n sho6n as a "ross. "ross.
Transition to terminate pseudo state
(. Entr' ntr' po#nt o#nt
Cntry point user entry
. E#t po po#nt
C8it point user e8it
3. A "ho#"e "ho#"e pse! pse!o o state state #s sho6n sho6n as a #a-on/ #a-on/shap shape e s'-)o$. s'-)o$.
27
Select outgoing transition based on condition.
5.
A trans#t#on str#ng -a' )e sho6n near the )ar.
6ork splits transition into two transitions
2. So!r"e states to the the )ar. )ar. A trans#t#on str#ng str#ng -a' )e sho6n sho6n near the )ar. )ar.
Noin merges transitions into single transition
4. F#na$ #na$ stat tate.
Transition to final state.
28
STATE CART DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM9
29
F!n"t#ona$#t#es o, State Chart D#agra- 9 A!thent#"at#on %. Successfully logged on or re4login &. Search for a book >user9 $ re"uest the vendor >librarian9 $ provide the re"uested book >vendor9 '. /eceive acknowledgement ). Logged off $ re4search $ new function Trans#t#ons9
%. Authenticate 444O Logged in &. Logged in 444O Search Searc h P444O Acknowledgement '. Logged in 444O 44 4O /e"uest *endor *endor P444O Frovide #ook P444O Acknowledgement ). Logged in 444O Frovide #ook P444O P 444O Acknowledgement . Acknowledgement Acknowledgement 444O Logged off
DEPLOYMENT DIAGRAM
•
A deployment diagrams shows the hardware of your system and the software in those hardware. 0eployment diagrams are useful when your software solution is deployed across multiple machines with each having a uni"ue configuration. #elow is an e8ample deployment diagram. 0eployment diagram is employed when we need to deploy the application we developed. A single deployment deployment diagram is possible for a single system. A deployment deployment diagram shows the configuration of run4time processing nodes and the components that live on them.
•
0eployment diagrams address the static deployment view of an architecture.
•
They are related to component diagrams in that a node typically encloses one or more components.
NOTATIONS USED IN DEPLOYMENT DIAGRAM9
30
Notat#on
Des"r#pt#on
An artifact is a classifier that that represents some physical entity,
The U(L Standard Frofile defines several standard stereotypes that apply to artifacts: Standard stereotypes 4 subclasses of QfileR: Standard U(L %.8 stereotypes that is now obsolete
A device is a subclass of node. node.
A communication path
0eployed artifacts
31
DEPLOYMENT DIAGRAM FOR LIBRARY MANAGEMENT SYSTE
F!n"t#ona$#t#es o, Dep$o'-ent D#agra-9
%. Local +onsoles $ +omputers for login and search purposes by users, librarian and vendors. &. Library LA< Server interconnecting all the systems to the 0atabase. '. !nternet to provide access a ccess to *endorsJ *endorsJ to supply the re"uested books by the Librarian ). *en *endor dor Server to maintain mai ntain the records of the re"uests made by the librarian
COMPONENT DIAGRAM
A component diagram displays the structural relationship of components of a software system. These are mostly used when working with comple8 systems that has many components. +omponents communicate with each other using interfaces. interfaces. The interfaces are linked using connectors. #elow images shows a component diagram.+omponent diagram represents the components in which the particular application needs to be 32
installed or implemented on. !t also shows the type of relation that e8ists among the various components that are represented. Mence, only a single component diagram representing all the components and their relations is needed for the entire system.
NOTATIONS USED IN COMPONENT DIAGRAM9
1. A "o-pone "o-ponent nt #s sho6n as a "$ass "$ass#,#er #,#er re"ta re"tang$e ng$e 6#th the the 8e'6or 8e'6or "o-ponent "o-ponent..
+omponent Beather Beather Service &. Opt Opt#on #ona$$ a$$' ' "o-po "o-ponen nentt #"on #"on
+omponent User Service (. Co-ponent Co-ponent C!sto-er C!sto-er E7B #n #n UML UML 1. notat#on notat#on
. Inter,a"e
33
3. Re! Re!#r #re e Inte Inter, r,a" a"ee
5. De$egat#o De$egat#on n "onne"tor "onne"tor ,ro,ro- the e$egat#n e$egat#ng g port to the UserSer UserSer+$et +$et part part
2. De$egat#o De$egat#on n "onne"tor "onne"tor ,ro,ro- the e$egat#n e$egat#ng g port to the s#-p$e s#-p$e port o, Sear"h Sear"h Eng#ne
4. De$egat#on "onne"tor ,ro- the s#-p$e port o, A!thent#"at#on A!thent#"at#on "o-ponent "o-ponent to to the e$egat#ng port
0. Asse-)$' "onne"tor "onne"tor #s notate as a "onne"tor "onne"tor )et6een t6o t6o or -ore -ore parts parts or ports on parts.
34
COMPONENT FOR LIBRARY MANAGEMENT SYSTEM9
F!n"t#ona$#t#es o, Co-ponent D#agra-9
%. /egister Fage >visitor $ vendor9 &. Login Fage >user $ librarian $ vendor9 '. Search Fage >user $ librarian $ vendor9 ). /e"uest *endor endor Fage >librarian9 . /e"uest #ook !ssue Fage >user $ vendor9 -. !ssue Status Fage >librarian9 1. (ake Fayment Fage >librarian $ vendor9
35
2. Frovide #ooks Fage >librarian9 3. Logout Fage >user $ librarian $ vendor9
DATA BASES USED IN UNIFIED LIBRARY MANAGEMENT SYSTEM9
Boo8 F#e$ Na-e #ookcode #ookname Author Frice #ookavailable
DataT'pe +har6ield +har6ield +har6ield !nteger6ield !nteger6ield !nteger6ield !nteger6ield !nteger6ield
Des"r#pt#on Frimary key 4 4 4 4 4 4 4
DataT'pe +har6ield +har6ield +har6ield Te8t6ield 0ate$Time6ield 0ate$Time6ield Te8t6ield
Des"r#pt#on Frimary key
Me-)ers F#e$ Na-e (ember!d (ember
4 4 4 4 4 4
L#)rar#an 36
F#e$ Na-e Librarianid Librarianname Fassword
DataT'pe !nteger6ield +har6ield +har6ield
Des"r#pt#on Frimary key 4 4
DataT'pe +har6ield +har6ield +har6ield 0ate$Time6ield !nteger6ield !nteger6ield !nteger6ield
Des"r#pt#on Frimary key 4 4 4 4 4 4
DataT'pe +har6ield +har6ield +har6ield 0ate$Time6ield 0ate$Time6ield
Des"r#pt#on Frimary key 4 4 4 4
A Boo8s F#e$ Na-e #ookcode #ookname Author 0ateofarrival Frice
Iss!e Boo8 F#e$ Na-e #ookcode #ookname Author 0ateofissue 0uedate
37
FORHARD FORHARD AND RE=ERSE ENGINEERING ENGINEERIN G
(odelling is important, but you have to remember that the primary product of a development team is software, not diagrams. f course, the reason for creating models is to be able to deliver software that satisfies the evolving goals of its users and the business at the right time. 6or this reason, itDs important that the models you create and the implementations you deploy map to one another and do so in a way that minimizes or even eliminates the cost of keeping your models and your implementation in sync with one another. 6or some uses of the U(L, the models you create will never map to code. 6or e8ample, if you are modelling a business process using activity diagrams, many of the activities you model will involve people, not computers. !n other cases, youDll want to model systems whose parts are, from your level of abstraction, ust a piece of hardware >although at another level of abstraction, itDs a good bet that this hardware contains an embedded computer and software9. !n most cases though, the models you create will map to code. The U(L does not specify a particular mapping to any obect4oriented programming language, language, but the U(L was designed with such mappings in mind. This is especially true for class diagrams, whose contents have a clear mapping to all the industrial4strength obect4oriented languages, such as Nava, +EE, Smalltalk, Ciffel, Ada, bect Fascal, and 6orte. The U(L was als o designed to map to a variety of commercial obect4based languages, such as *isual #asic.
6orward engineering is the process of transforming a model into code through a mapping to an implementation language. 6orward engineering results in a loss of information, because models written in the U(L are semantically richer than any current obect4oriented programming language. !n fact, this is a maor reason why you you need models in addition to code. Structural features, such as collaborations, and behavioural features, such as interactions, can be visualized clearly in the U(L, but not so clearly from raw code
For6ar eng#neer#ng
6orward engineering is the process of transforming a model into code through a mapping to an implementation language. 6orward engineering results in a loss of information, because (odels written in the U(L are semantically richer than any current obect4oriented Frogramming language. !n fact, this is a maor reason why you need models in addition to code. Structural features, such as collaborations, and behavioural features, such as interactions, can be visualized clearly in the U(L, but not so clearly from raw code. •
6orward engineering is the process of transforming a model into code through a mapping to an implementation language. –
A use case diagram can be forward engineered to form tests for the element to which it applies. 38
•
•
Cach use case in a use case diagram specifies a flow of events >and variants of those flows9, and these flows specify how the element is e8pected to behave. A well4structured use case will even specify pre4 and post conditions that can be used to define a testDs initial state and its success criteria.
6or each use case in a use case diagram, you can create a test case that you can run every time you release a new version of that element, thereby confirming that it works as re"uired before other elements rely on it. To ,or6ar eng#neer a "$ass #agra-
I !dentify the rules for mapping to your implementation language or languages of choice. This is something youDll want to do for your proect or your organization as a whole. I 0epending on the semantics of the languages you choose, you may want to constrain your use of certain U(L features. 6or e8ample, the U(L permits you to model multiple inheritance, but Smalltalk permits only single inheritance. Be can choose to prohibit developers from modeling with multiple inheritance >which makes your models language4dependent9, or you can develop idioms that transform these richer features into the implementation language >which makes the mapping more comple89. I Use tagged values to guide implementation choices in your target language. 5ou 5ou can do this at the level of individual classes if you need precise control. 5ou can also do so at a higher level, such as with collaborations or packages. I Use tools to generate code.
Re+erse eng#neer#ng
/everse engineering is the process of transforming code into a model through a mapping 6rom a specific implementation language. /everse engineering results in a flood of information, some of which is at a lower level of detail than youDll need to build useful models. At the same time, reverse engineering is incomplete. There is a loss of information when forward engineering models into code, and so you canDt completely recreate a model from code unless your tools encode information in the source comments that goes beyond the semantics of the implementation language.
•
/everse engineering is the process of transforming code into a model through a mapping from a specific implementation language.
39
•
•
•
•
Automatically reverse engineering a use case diagram is pretty much beyond the state of the art, simply because there is a loss of information when moving from a specification of how an element behaves to how it is implemented. Mowever, we can study an e8isting system and discern its intended behavior by hand, which we can then put in the form of a use case diagram. !ndeed, this is pretty much what we have to do anytime we are handed an undocumented body of software. The U(LDs use case diagrams simply give us a standard and e8pressive language in which to state what we discover.
To re+erse eng#neer a "$ass #agra- •
!dentify the rules for mapping from your implementation language or languages of
•
choice. This is something youDll want to do for your proect or your organization as a whole. Using a tool, point to the code youDd like to reverse engineer. Use your tool to
•
generate a new model or modify an e8isting one that was previously forward engineered. !t is unreasonable to e8pect to reverse engineer a single concise model from a large body of code. 5ou 5ou need to select portion of the code and build the model from the bottom. Using your tool, create a class diagram by "uerying the model. 6or e8ample, you
•
might start with one or more classes, then e8pand the diagram by following specific relationships or other neighboring classes. C8pose or hide details of the contents of this class diagram as necessary to communicate your intent. (anually add design information to the model to e8press the intent of the design that is missing or hidden in the code.
For6ar eng#neer#ng ; the "reat#on o, "oe ,ro- a -oe$< an o)*e"t #agra-9 6orward engineering > the creation of code from a model9 an obect diagram • is theoretically theoretically possible but pragmatically of limited value. value. !n an obect4oriented system, instances are things that are created and destroyed by the application during run time. Therefore, you cannot e8actly instantiate these obects from the outside. •
Although this is true of most typical obect diagram >which contain instances of classes9, it is not true of obect diagrams containing instances of components and of nodes. #oth of these are special cases of component diagrams and deployment diagrams, respectively. res pectively.
Re+erse eng#neer#ng ;the "reat#on o, a -oe$ ,ro- "oe< an o)*e"t #agra-
40
obect diagram can be useful. !n fact, while you are debugging your system, this is something that you or your tools will do all the time. 6or e8ample, if you are chasing down a dangling link, youDll want to literally or mentally draw an obect diagram of the affected obects to see where, at a given moment in time, an obectDs state or its relationship to other obects is broken. To re+erse eng#neer an o)*e"t #agra- I +hose the target you want to reverse engineer. Typ Typically, ically, youDll set your conte8t inside an operation or relative to an instance of one particular class.
I Using a tool or simply walking through a scenario, stop e8ecution at a certain moment in time. I !dentify the set of interesting obects that collaborate in that conte8t and render them in an obect diagram. I As necessary to understand their semantics, e8pose these obectDs states. I As necessary to understand their semantics, identify the links that e8ist among these obects. I !f your diagram ends up overly complicated, prune it by eliminating obects that are not germane to the "uestions about the scenario you need answered. !f your diagram is too
FUTURE SCOPE OF APPLICATION9 APPLICATION9
41
This application can be easily implemented under various situations.Be can add new features as and when we re"uire. /eusability is possible as and when re"uire in this application. There is fle8ibility in all the modules. SOFTHARE SOFTHARE SCOPE9 SC OPE9 J Etens#)#$#t'9 This software is e8tendable in ways that its original developers may not e8pect. The following principles enhances e8tensibility like hide data structure, avoid traversing multiple links or methods, avoid case statements on obect type and distinguish public and private operations. J Re!sa)#$#t'9 /eusability is possible as and when re"uire in this application. Be can update it ne8t version. /eusable software reduces design, coding and testing cost by amortizing effort over several designs. /educing the amount of code also simplifies understanding, which increases the likelihood that the code is correct. Be follow up both types of reusability J Unerstana)#$#t'9 Unerstana)#$#t'9 A method is understandable if someone other than the creator of the method can understand the code >as well as the creator after a time lapse9. Be use the method, which small and coherent helps to accomplish this. JCost/e,,e"t#+eness9 !ts cost is under the budget and make within given time period. !t is desirable to aim for a system with a minimum cost subect to the condition that it must satisfy the entire re"uirement.
CONCLUSION
6rom a proper analysis of positive points and constraints on the component, it can be safely concluded that the product is a highly efficient ;U! based component. This application is working properly and meeting to all user re"uirements. This component can be easily plugged in many other systems.
42
ONLINE 7OB PORTAL MANAGEMENT SYSTEM
Intro!"t#on9 *iewing *iewing available obs, or applying for the ob at the agency can be done for which ob seekers has to go to the agency and check the available obs at the agency. Nob seekers check the list of obs available and apply the ob. Then the agency will show available obs for the ob seeker for his "ualifications and then updates the obs database.
P!rpose9 The purpose of designing the online ob portal is to give the ob seekers a platform for finding a right and a satisfactory ob according to their "ualification. !t also connects the ob seekers with the maor agencies.
S"ope9 The nline ob Fortal System that is to be developed provides the members with obs information, online applying for obs and many other facilities. The basic scope of the proect is given as under •
Nob Seekers Area
•
AdministratorDs panel
App$#"at#on
• • • •
Application will provide the separate user account which are used to upload resume, Update profile and apply for multiple obs. Frovide easy and "uick search of ob from this application. This application provide user on criteria that is alone by specific user account. User can update profile and resume for different types of ob category.
MODULEKS A=IALABLE9
%. Admin &. +ompany '. Nob Se Seeker
43
ADMIN MODULE9 • • • • • • • • •
(anage a Fackage or plan for Nobseeker. *iew /egister member and (anage /egister (ember in our site. *iew Nobseeker 0etails. +ompany 0etails. *iew Nob alert. *iew Apply ob. (anage +ompose message 0etails. *iew !nbo8. *iew 6eedback.
COMPANY MODULE9 • • • • •
Login in our site. Update company profile. +reate ob criteria. *iew +ompose message by Nobseeker and Admin. *iew inbo8.
7OBSEEER MODULE9 • • • • • • •
Login in our site. *iew different ob plan. *iew company information. Update his$her profile information. Apply for suitable ob plan. +ancel member registration. *iew his$her !nbo8.
44
DATA BASES USED IN UNIFIED LIBRARY MANAGEMENT SYSTEM9
7o) See8er Deta#$s9 F#e$ Na-e User
DataT'pe +har6ield +har6ield +har6ield +har6ield
Des"r#pt#on Frimary key 4 4 4
DataT'pe +har6ield +har6ield +har6ield +har6ield Cmail6ield
Des"r#pt#on Frimary key 4 4 4
DataT'pe +har6ield +har6ield +har6ield
Des"r#pt#on Frimary key 4 4
Co-pan'9 F#e$ Na-e +ompanycode +ompanyname F la c e Cmail Beb site
A-#n9 F#e$ Na-e User
45
46
