+ All Categories
Home > Documents > Final Report of OOAD (1).docx

Final Report of OOAD (1).docx

Date post: 28-Jan-2016
Category:
Upload: jaganadhavan
View: 289 times
Download: 7 times
Share this document with a friend
Popular Tags:
54
UNIFIED LIBRARY MANAGEMENT SYSTEM TABLE OF CONTENTS Chapters Contents Page No. 1 Introduction 1.1 Applications 02 1.2 Analysis 03 1.3 Objectives 03 2 List of UML Diagrams 2.1 Class Diagram 04-09 2.2 Object Diagram 09-11 2.3 Use Case Diagram 11-14 2.4 Sequence Diagram 14-17 2.5 Collaboration Diagram 18-20 2.6 Activity Diagram 21-24 2.7 State Chart Diagram 25-28 2.8 Deployment Diagram 29-30 2.9 Component Diagram 31-33 3 Data Bases Used in Library Management 34-35 4 Forward and Reverse Approach 36-38 5 Future Scope 40 6 Conclusion 40 1
Transcript
Page 1: Final Report of OOAD (1).docx

UNIFIED LIBRARY MANAGEMENT SYSTEM

TABLE OF CONTENTS

Chapters Contents Page No.

1 Introduction1.1 Applications 021.2 Analysis 031.3 Objectives 03

2 List of UML Diagrams2.1 Class Diagram 04-092.2 Object Diagram 09-112.3 Use Case Diagram 11-142.4 Sequence Diagram 14-172.5 Collaboration Diagram 18-202.6 Activity Diagram 21-242.7 State Chart Diagram 25-282.8 Deployment Diagram 29-302.9 Component Diagram 31-33

3 Data Bases Used in Library Management 34-354 Forward and Reverse Approach 36-385 Future Scope 406 Conclusion 40

1

Page 2: Final Report of OOAD (1).docx

ONLINE JOB PORTAL MANAGEMENT SYSTEM

TABLE OF CONTENTS

Chapters Contents Page No.

1 Introduction1.1 Purpose 42

2 Modules2.1 Admin 422.2 Company 432.3Job Seeker 43

3 Databases Used in Job Portal 444 List of UML Diagrams

4.1 Class Diagram4.2 Object Diagram4.3 Use Case Diagram4.4 Sequence Diagram4.5 Collaboration Diagram4.6 Activity Diagram4.7 State Chart Diagram4.8 Deployment Diagram4.9 Component Diagram

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. Using this application the member can reserve any book from anywhere in the world. Library management system is a project which aims in developing a computerized system to maintain all the daily work of library .This project has many features which are generally not available

2

Page 3: Final Report of OOAD (1).docx

in normal library management systems like facility of user login and a facility of teachers login .It also has a facility of admin login through which the admin can monitor the whole system. It 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 request the librarian to add new books by filling the book request 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 us just have an overview of the unified library application system:

Librarian lends books and magazines

Librarian maintains the list of all the members of library

Borrower makes reservation online

Borrower can remove reservation online

Librarian issues books to the borrower

Librarian calculates dues to be paid by the borrower

Borrower issues/returns books and/or magazines

Librarian places order about the requirements to the publisher librarian

Librarian updates system

TEXTUAL ANALYSIS

(a) ACTORS

i. Librarian

ii. Borrower

(b) VERBS

i. Borrower:

1. Logs into the system

2. Browses/searches for books or magazines

3. Makes/removes reservation

4. Views results and reports from the unified library application system

3

Page 4: Final Report of OOAD (1).docx

ii. Librarian:

1. Manages and validates members

2. View reports from the system

3. Issues books

4. Calculates dues

5. Takes books

6. Maintains list of books and magazine

AIMS AND OBJECTIVES OF UNIFIED LIBRARY MANAGEMENT

Online book issue Request 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 DIAGRAMS:

1. Class Diagram

2. Object Diagram

3. Use case Diagram

4. Sequence Diagram

5. Collaboration Diagram

6. Activity Diagram

7. State chart Diagram

8. Deployment Diagram

9. component Diagram

4

Page 5: Final Report of OOAD (1).docx

CLASS DIAGRAM:

Class diagrams is the main building block of any object oriented solution. It shows the classes in a system, attributes and operations of each class and the relationship between each class. In most modeling tools a class has three parts, name at the top, attributes in the middle and operations or methods at the bottom. In large systems with many related classes, classes are grouped together to create class diagrams. Different relationships between classes are shown by different types of arrows. Class diagrams are the most common diagram found in modeling object-oriented systems. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. You use class diagrams to model the static design view of a system. For the most part, this involves modeling the vocabulary of the system, modeling collaborations, or modeling schemas.

Class diagrams are also the foundation for a couple of related diagrams: component diagrams & deployment diagrams. Class diagrams are important not only for visualizing, specifying, and documenting structural models, but also for constructing executable systems through forward and reverse engineering.

The components are:

a) Classb) Relationship:

The forms of relationship are:

1. Association2. Generalization3. Dependency

1. Association

• Association is a structural relationship where objects of one class are connected to ob-jects of another class.

• Navigation is bi-directional by default.

• Binary association connects exactly two classes.

• N-array connects many classes.

5

Page 6: Final Report of OOAD (1).docx

• Graphically, 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 four adornments that apply to associations :

– Name

– Role

– Multiplicity

– Aggregation.

2. Generalization

Generalizations are "is-a-kind-of" relationship. It connect generalized classes to more-specialized ones in what is known as subclass/super class or child/parent relationships.

• Generalization is a relationship between general thing (parent) and specific kind of thing (child)

• Generalization is rendered as a solid directed line with a large open arrowhead, point-ing to the parent.

• A child inherits the properties of its parents, their attributes and operations. Often, the child has attributes and operations in addition to those found in its parents.

3. Dependency

Dependencies are “using relationships”.

• A relationship in which a change in specification of one thing may affect another.

• A dependency is rendered as a dashed directed line.

• Dependencies are used to show one thing using another.

• Dependencies are used to show that one class uses another class as an argument in the signature of an operation.

• Dependencies are very much a using relationship - if the used class changes, the oper-ation of the other class may be affected, because the used class may now present a dif-ferent interface or behavior.

6

Page 7: Final Report of OOAD (1).docx

Types of Relationships:

1. One to One Relationship2. One to Many Relationship3. Many to One Relationship4. Many to Many Relationship

1. One to One Relationship:One to many relationship is represented using the symbol (1..1).

2. One to Many Relationship:One to Many Relationship can be represented using the symbol (1..*).

3. Many to One Relationship:One to Many Relationship can be represented using the symbol (*..1).

4. Many to Many Relationship:Many to Many Relationship can be represented using the symbol (*..*).

Drawing Classes

Classes define the attribute values carried by each symbol instance and the operations that each symbol performs or undergoes. When representing a class, you:

Draw a class symbol Name the classes Enter class attributes Enter class operations Add links and associations Add notations

VISIBILITY

7

Page 8: Final Report of OOAD (1).docx

To specify the visibility of a class member (i.e., any attribute or method), these notations

must be placed before the member's name

NOTATIONS USED IN CLASS DIAGRAM:

Notation Description

Class nameA class is a classifier which describes a set of objects that share the same

Class name

Attributes

Operations

When 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 justified in plain face, with the first letter of the names in lower case. 

CLASS DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM:

8

+ Public

- Private

# Protected

/ Derived (can be combined with one of the others)

~ Package

Page 9: Final Report of OOAD (1).docx

Functionalities of Class Diagram :

Librarian: To maintain and update the records and also to cater the needs of the users Reader: Need books to read and also places various requests to the librarian. Vendor: To provide and meet the requirement of the prescribed books.

Classes identified:1. Library2. Librarian3. Books Database4. User5. Vendor

OBJECT DIAGRAM:

Object Diagrams, sometimes referred as Instance diagrams are very similar to class diagrams. As class diagrams they also show the relationship between objects but they use real world ex-

9

Page 10: Final Report of OOAD (1).docx

amples. They are used to show how a system will look like at a given time. Because there is data available in the objects they are often used to explain complex relationships between ob-jects. Object diagrams model the instances of things contained in class diagrams. An objectDiagram shows a set of objects and their relationships at a point in time. You use object dia-grams to model the static design view or static process view of a System. This involves mod-elling a snapshot of the system at a moment in time and rendering a set of objects, their state, and their relationships. Object 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.

Object diagrams commonly contain

• Objects

• Links

NOTATIONS USED IN OBJECT DIAGRAM:

Object name Object is an instance of a class or an interface.

Object name: class of the instance is unknown or not specified

Instance name, (package) specified.

OBJECT DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM:

10 B1: Book

B_name=””

Booked=””

B2: Book

B_name=””

Booked=””

Manages Manages

Librarian

Lib_name=”ABC”

Search=”10”

ManagesManages

Page 11: Final Report of OOAD (1).docx

Functionalities of Object Diagram:

1. Library2. Librarian3. Books Database4. User5. Vendor

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 in-

teracted. Use case diagram comprises of use cases and actors such that there would

be various kinds of relationships among the use cases and the actors. A use case

11

Page 12: Final Report of OOAD (1).docx

diagram shows all the actions that a particular actor needs to perform throughout

the system at every and any point of time. There would be only one use case dia-

gram 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 sequences 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 case diagrams commonly contain:

• Use cases

• Actors

• Dependency, generalization, and association relationships

• Notes and constraints.

• Packages, which are used to group elements of the model into larger chunks.

• Instances of use cases to visualize a specific executing system.

NOTATIONS USED IN USE CASE DIAGRAM:

Notation Description

Subject is presented by a rectangle with subject name in upper corner with applicable use cases inside the rectangle and actors - outside of the system boundaries.

Use cases visually located inside the system boundaries are

the use cases applicable to the subject

 (but not necessarily owned by the subject).

12

Page 13: Final Report of OOAD (1).docx

The nesting (ownership) of a use case by a classifier is represented using the standard notation for nested classifiers.

The names of abstract actors should be shown in italics. All actors must have names.

actors is rendered as a solid directed line with a large arrowhead (the same as for generalization between classes).

Extend is a directed relationship 

An include relationship is a directed relationship 

USE CASE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM:

13

Page 14: Final Report of OOAD (1).docx

Functionalities of Use Case Diagram :

Actors vs Use Cases:

1. Librarian • Issue a book• Update and maintain records• Request the vendor for a book• Track complaints

2. User• Register• Login• Search a book• Request for isse• View history• Request to the Librarian

14

Page 15: Final Report of OOAD (1).docx

• Unregister

3. Books Database• Update records• Show books status

4. Vendors• Provide books to the library• Payment acknowledgement

SEQUENCE DIAGRAM

This diagram, as the name suggests, contains the sequence of flow of actions that are

processed through a system and the life lines of the entities, when and how are they accessed.

It also contains the security features like which entity can process which entity and which one

is visible, etc. There can be many number of sequence diagrams per each activity being done.

The components are:

a) Actorb) Objectc) Messagesd) Lifelinee) Focus of Control

Sequence diagrams show some information:

Objects/classes

Messages

Sequence

Conditional

Repetition

Messages to self

15

Page 16: Final Report of OOAD (1).docx

NOTATIONS USED IN SEQUENCE DIAGRAM :

Notation Description

Selector could be used to specify some lifeline from collection.

Execution

Overlapping executions on the same lifeline are represented by overlapping rectangles.

Overlapping execution specifications on the same lifeline - callback message.

16

Page 17: Final Report of OOAD (1).docx

Synchronous call typically represents operation call .

Create message is sent to lifeline to create itself.

Delete message .

Reply message to an operation call as a dashed line.

SEQUENCE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM:

17

Page 18: Final Report of OOAD (1).docx

Functionalities of Sequence Diagram :

Register Login Search a book Request for issue book View history Request to the Librarian Unregister

COLLABORATION DIAGRAM

18

Page 19: Final Report of OOAD (1).docx

This diagram is a polymorphic form of the sequence diagram in which the representation is different but application is the same. If we are able to create one sequence 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 sequence diagrams. Collaboration diagram displays object interactions organized around objects and their links to one another.

The Components are:

a) Actor

b) Object

c) Link

Uses of Collaboration Diagram

• Multi object

• Conditional messages - Conditional messages mean that under certain conditions the message will be sent and under other conditions it won’t - The message is sent when the condition in the square brackets is true

• Repetitive messages - The message repeats while the condition in the square brackets is true

• Notation

Collaboration diagrams show some information:

19

Title:

Page 20: Final Report of OOAD (1).docx

Objects/classes

Messages

Sequence

Conditional

Repetition

Messages to self

NOTATIONS USED IN COLLABORATION DIAGRAM:

Element and its description Symbol

Object: The objects interacting with each other in the system. Depicted by a rectangle with the name of the object in it, preceded by a colon and underlined.Relation/Association: A link connecting the associated objects. Qualifiers can be placed on either end of the association to depict cardinality.Messages: An arrow pointing from the commencing object to the destination object shows the interaction between the objects. The number represents the order/sequence of this interaction.

COLLABORATION DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM:

20

Page 21: Final Report of OOAD (1).docx

Functionalities of Collaboration Diagram :

User Login and Authentication Search book operation for Reader Acknowledge and Issue books to the users by the Librarian Provide books requested by the Librarian from the Vendor

21

Page 22: Final Report of OOAD (1).docx

ACTIVITY DIAGRAM:

This diagram denotes the structural flow of the activities in the form of flow chart with decision boxes enhanced and hence is also used for troubleshooting like raising exceptions 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. Check out this wiki article to learn about symbols and usage of activity diagrams. Activity diagram shows the flow of events within our system.

The components are:

a) Start Stateb) End Statec) Transitiond) Decision Boxe) Synchronization Barf) Swim Lane

NOTATIONS USED IN ACTIVITY DIAGRAM :

The start symbol represents the beginning of a process or workflow in an activity diagram. It can be used by itself or with a note symbol that explains the starting point.

The activity symbol is the main component of an activity diagram. These shapes in-dicate the activities that make up a modeled process.

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;

once the step is completed, the flow continues with the outgoing arrow

The join symbol, or synchronization bar, is a thick vertical or horizontal line. It combines two concurrent activities and re-introduces them to a flow where only one activity occurs at a time.

A fork is symbolized with multiple arrowed lines from a join. It splits a single activity flow into two concurrent activities.

22

Page 23: Final Report of OOAD (1).docx

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 don't 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 sequence within the option loop symbol.

The flow final symbol shows the ending point of a process' flow. While 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.

The end symbol represents the completion of a process or workflow.

ACTIVITY DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM:

Issue Book

23

Page 24: Final Report of OOAD (1).docx

Return Book

24

Page 25: Final Report of OOAD (1).docx

Functionalities of Activity Diagram :

User Login and Authentication Search book operation for Reader Acknowledge and Issue books to the users by the Librarian Provide books requested by the Librarian from the Vendor Bill payment from the Librarian to the Vendor  Status of the books updated in the Books Database

25

Page 26: Final Report of OOAD (1).docx

STATE CHART DIAGRAM:

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 objects that act different according to the state they are at the moment. Below 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 ob-ject may be in. States are represented by rectangles with rounded corners. Each state is la-belled with a state name. States may also be labelled with an activity.

The components are:

a) Start state

b) End state

c) State

d) Transition

Typical system states might be any of the following:

* Waiting for user to enter password

* Heating chemical mixture

* Waiting for next command

* Accelerating engine

* Mixing ingredients

* Waiting for instrument data

* Filling tank

* Idle

NOTATIONS USED IN STATE CHART DIAGRAM:

1. An initial pseudo state is shown as a small solid filled circle.

Initial pseudo state transitions to Waiting for User Input state

26

Page 27: Final Report of OOAD (1).docx

2. A terminate pseudo state is shown as a cross.

Transition to terminate pseudo state

3. Entry point 

Entry point user entry

4. Exit point

Exit point user exit

5. A choice pseudo state is shown as a diamond-shaped symbol.

Select outgoing transition based on condition.

6. A transition string may be shown near the bar.

Fork splits transition into two transitions

27

Page 28: Final Report of OOAD (1).docx

7. Source states to the bar. A transition string may be shown near the bar.

Join merges transitions into single transition

8. Final state.

Transition to final state.

28

Page 29: Final Report of OOAD (1).docx

STATE CHART DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM:

Functionalities of State Chart Diagram :

Authentication1. Successfully logged on or re-login2. Search for a book (user) / request the vendor (librarian) / provide the requested book (vendor)3. Receive acknowledgement4. Logged off / re-search / new function

Transitions:

1. Authenticate ---> Logged in2. Logged in ---> Search <---> Acknowledgement3. Logged in ---> Request Vendor <---> Provide Book <---> Acknowledgement4. Logged in ---> Provide Book <---> Acknowledgement5. Acknowledgement ---> Logged off

29

Page 30: Final Report of OOAD (1).docx

DEPLOYMENT DIAGRAM

• A deployment diagrams shows the hardware of your system and the software in

those hardware. Deployment diagrams are useful when your software solution is

deployed across multiple machines with each having a unique configuration. Be-

low is an example deployment diagram. Deployment diagram is employed when

we need to deploy the application we developed. A single deployment diagram is

possible for a single system. A deployment diagram shows the configuration of

run-time processing nodes and the components that live on them.

• Deployment 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 DIAGRAM:

Notation Description

An artifact is a classifier that represents some physical entity,

The UML Standard Profile defines several standard stereotypes that apply to artifacts:Standard stereotypes - subclasses of «file»:Standard UML 1.x stereotypes that is now obsolete:

Node is a deployment target.

A device is a subclass of node.

30

Page 31: Final Report of OOAD (1).docx

A communication path

Deployed artifacts

DEPLOYMENT DIAGRAM FOR LIBRARY MANAGEMENT SYSTE

Functionalities of Deployment Diagram:

1. Local Consoles / Computers for login and search purposes by users, librarian and vendors.2. Library LAN Server interconnecting all the systems to the Database.3. Internet to provide access to Vendors’ to supply the requested books by the Librarian

31

Page 32: Final Report of OOAD (1).docx

4. Vendor Server to maintain the records of the requests 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 complex systems that has many com-

ponents. Components communicate with each other using interfaces. The interfaces are

linked using connectors. Below images shows a component diagram.Component diagram

represents the components in which the particular application needs to be installed or im-

plemented on. It also shows the type of relation that exists among the various components

that are represented. Hence, only a single component diagram representing all the com-

ponents and their relations is needed for the entire system.

NOTATIONS USED IN COMPONENT DIAGRAM:

1. A component is shown as a classifier rectangle with the keyword «component».

Component Weather Service

2. Optionally component icon

Component User Service

3. Component Customer EJB in UML 1.x notation

32

Page 33: Final Report of OOAD (1).docx

4. Interface

5. Required Interface

6. Delegation connector from the delegating port to the UserServlet part

7. Delegation connector from the delegating port to the simple port of Search Engine

8. Delegation connector from the simple port of Authentication component to the delegating port

33

Page 34: Final Report of OOAD (1).docx

9. Assembly connector is notated as a connector between two or more parts or ports on parts.

COMPONENT FOR LIBRARY MANAGEMENT SYSTEM:

Functionalities of Component Diagram:

1. Register Page (visitor / vendor)2. Login Page (user / librarian / vendor) 

34

Page 35: Final Report of OOAD (1).docx

3. Search Page (user / librarian / vendor)4. Request Vendor Page (librarian)5. Request Book Issue Page (user / vendor)6. Issue Status Page (librarian)7. Make Payment Page (librarian / vendor)8. Provide Books Page (librarian)9. Logout Page (user / librarian / vendor)

DATA BASES USED IN UNIFIED LIBRARY MANAGEMENT SYSTEM:

Book

Field Name DataType DescriptionBook_code CharField Primary keyBook_name CharField -Author CharField -Price IntegerField -Book_available IntegerField -No_of_Pages IntegerField -Books_issues IntegerField -Shelf_number IntegerField -

Members

Field Name DataType DescriptionMember_Id CharField Primary keyMember_Name CharField -Department CharField -Address TextField -Date_of_issue Date/TimeField -Date of Expiry Date/TimeField -Status TextField -

35

Page 36: Final Report of OOAD (1).docx

Librarian

Field Name DataType DescriptionLibrarian_id IntegerField Primary keyLibrarian_name CharField -Password CharField -

Add Books

Field Name DataType DescriptionBook_code CharField Primary keyBook_name CharField -Author CharField -Date_of_arrival Date/TimeField -Price IntegerField -No_of_books IntegerField -Subject_code IntegerField -

Issue Book

Field Name DataType DescriptionBook_code CharField Primary keyBook_name CharField -Author CharField -Date_of_issue Date/TimeField -Due_date Date/TimeField -

36

Page 37: Final Report of OOAD (1).docx

FORWARD AND REVERSE ENGINEERING

Modelling is important, but you have to remember that the primary product of a development team is software, not diagrams. Of course, the reason for creating models is to be able to de-liver software that satisfies the evolving goals of its users and the business at the right time.

For this reason, it's 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.

For some uses of the UML, the models you create will never map to code. For example, if you are modelling a business process using activity diagrams, many of the activities you model will involve people, not computers.

In other cases, you'll want to model systems whose parts are, from your level of abstraction, just a piece of hardware (although at another level of abstraction, it's a good bet that this hardware contains an embedded computer and software).

In most cases though, the models you create will map to code. The UML does not specify a particular mapping to any object-oriented programming language, but the UML was designed with such mappings in mind. This is especially true for class diagrams, whose contents have a clear mapping to all the industrial-strength object-oriented languages, such as Java, C++, Smalltalk, Eiffel, Ada, Object Pascal, and Forte. The UML was also designed to map to a variety of commercial object-based languages, such as Visual Basic.

Forward engineering is the process of transforming a model into code through a mapping to an implementation language. Forward engineering results in a loss of information, because models written in the UML are semantically richer than any current object-oriented program-ming language. In fact, this is a major 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 UML, but not so clearly from raw code

Forward engineering

Forward engineering is the process of transforming a model into code through a mappingto an implementation language. Forward engineering results in a loss of information, becauseModels written in the UML are semantically richer than any current object-orientedProgramming language. In fact, this is a major reason why you need models in addition to code. Structural features, such as collaborations, and behavioural features, such as interac-tions, can be visualized clearly in the UML, but not so clearly from raw code.

37

Page 38: Final Report of OOAD (1).docx

• Forward engineering is the process of transforming a model into code through a map-ping to an implementation language.

– A use case diagram can be forward engineered to form tests for the element to which it applies.

• Each use case in a use case diagram specifies a flow of events (and variants of those flows), and these flows specify how the element is expected to behave.

• A well-structured use case will even specify pre- and post conditions that can be used to define a test's initial state and its success criteria.

For 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 required before other elements rely on it.

To forward engineer a class diagram,

• Identify the rules for mapping to your implementation language or languages of choice. This is something you'll want to do for your project or your organization as a whole.

• Depending on the semantics of the languages you choose, you may want to constrain your use of certain UML features.

For example, the UML permits you to model multiple inheritance, but Smalltalk permits only single inheritance. We can choose to prohibit developers from modeling with multiple inheritance (which makes your models language-dependent), or you can develop idioms that transform these richer features into the implementation language (which makes the mapping more complex).

• Use tagged values to guide implementation choices in your target language. You can do this at the level of individual classes if you need precise control. You can also do so at a higher level, such as with collaborations or packages.

• Use tools to generate code.

Reverse engineering

Reverse engineering is the process of transforming code into a model through a mappingFrom a specific implementation language. Reverse engineering results in a flood of informa-tion, some of which is at a lower level of detail than you'll 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 can't completely recreate a model from code unless your tools encode information in the source comments that goes beyond the semantics of the implementation language.

38

Page 39: Final Report of OOAD (1).docx

• Reverse engineering is the process of transforming code into a model through a map-ping from a specific implementation language.

• 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 specifi-cation of how an element behaves to how it is implemented.

• However, we can study an existing system and discern its intended behavior by hand, which we can then put in the form of a use case diagram.

• Indeed, this is pretty much what we have to do anytime we are handed an undocu-mented body of software.

• The UML's use case diagrams simply give us a standard and expressive language in which to state what we discover.

To reverse engineer a class diagram,

Identify the rules for mapping from your implementation language or languages of choice. This is something you'll want to do for your project or your organization as a whole.

Using a tool, point to the code you'd like to reverse engineer. Use your tool to gener-ate a new model or modify an existing one that was previously forward engineered. It is unreasonable to expect to reverse engineer a single concise model from a large body of code. You need to select portion of the code and build the model from the bottom.

Using your tool, create a class diagram by querying the model. For example, you might start with one or more classes, then expand the diagram by following specific relationships or other neighboring classes. Expose or hide details of the contents of this class diagram as necessary to communicate your intent.

Manually add design information to the model to express the intent of the design that is missing or hidden in the code.

Forward engineering ( the creation of code from a model) an object diagram: Forward engineering ( the creation of code from a model) an object diagram is theoretically possible but pragmatically of limited value. In an object-oriented system, instances are things that are created and destroyed by the application during run time. Therefore, you cannot exactly instantiate these objects from the outside.

Although this is true of most typical object diagram (which contain instances of classes), it is not true of object diagrams containing instances of components and of nodes. Both of these are special cases of component diagrams and deployment dia-grams, respectively.

39

Page 40: Final Report of OOAD (1).docx

Reverse engineering (the creation of a model from code) an object diagram object diagram can be useful. In fact, while you are debugging your system, this is some-thing that you or your tools will do all the time. For example, if you are chasing down a dangling link, you'll want to literally or mentally draw an object diagram of the affected objects to see where, at a given moment in time, an object's state or its relationship to other objects is broken.

To reverse engineer an object diagram, • Chose the target you want to reverse engineer. Typically, you'll set your context inside an operation or relative to an instance of one particular class.

• Using a tool or simply walking through a scenario, stop execution at a certain moment in time.

• Identify the set of interesting objects that collaborate in that context and render them in an object diagram.

• As necessary to understand their semantics, expose these object's states.

• As necessary to understand their semantics, identify the links that exist among these ob-jects.

• If your diagram ends up overly complicated, prune it by eliminating objects that are not germane to the questions about the scenario you need answered. If your diagram is too

40

Page 41: Final Report of OOAD (1).docx

FUTURE SCOPE OF APPLICATION:

This application can be easily implemented under various situations.We can add new fea-tures as and when we require. Reusability is possible as and when require in this application. There is flexibility in all the modules.

SOFTWARE SCOPE:

• Extensibility: This software is extendable in ways that its original developers may not ex-pect. The following principles enhances extensibility like hide data structure, avoid traversing multiple links or methods, avoid case statements on object type and distinguish public and private operations.

• Reusability: Reusability is possible as and when require in this application. We can update it next version. Reusable software reduces design, coding and testing cost by amortizing ef-fort over several designs. Reducing the amount of code also simplifies understanding, which increases the likelihood that the code is correct. We follow up both types of reusability

• Understandability: 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 lapse). We use the method, which small and coherent helps to accomplish this.

•Cost-effectiveness: Its cost is under the budget and make within given time period. It is de-sirable to aim for a system with a minimum cost subject to the condition that it must satisfy the entire requirement.

CONCLUSION

From a proper analysis of positive points and constraints on the component, it can be safely concluded that the product is a highly efficient GUI based component. This application is working properly and meeting to all user requirements. This component can be easily plugged in many other systems.

41

Page 42: Final Report of OOAD (1).docx

ONLINE JOB PORTAL MANAGEMENT SYSTEM

Introduction:

Viewing available jobs, or applying for the job at the agency can be done for which job seekers has to go to the agency and check the available jobs at the agency. Job seekers check the list of jobs available and apply the job. Then the agency will show available jobs for the job seeker for his qualifications and then updates the jobs database.

Purpose:

The purpose of designing the online job portal is to give the job seekers a platform for finding a right and a satisfactory job according to their qualification. It also connects the job seekers with the major agencies.

Scope:

The Online job Portal System that is to be developed provides the members with jobs information, online applying for jobs and many other facilities. The basic scope of the project is given as under

Job Seekers Area

Administrator's panel

Application

Application will provide the separate user account which are used to upload resume, Update profile and apply for multiple jobs. Provide easy and quick search of job 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 job category.

MODULE’S AVIALABLE:

1. Admin2. Company3. Job Seeker

ADMIN MODULE:

42

Page 43: Final Report of OOAD (1).docx

Manage a Package or plan for Jobseeker. View Register member and Manage Register Member in our site. View Jobseeker Details. Company Details. View Job alert. View Apply job. Manage Compose message Details. View Inbox. View Feedback.

COMPANY MODULE:

Login in our site. Update company profile. Create job criteria. View Compose message by Jobseeker and Admin. View inbox.

JOBSEEKER MODULE:

Login in our site. View different job plan. View company information. Update his/her profile information. Apply for suitable job plan. Cancel member registration. View his/her Inbox.

43

Page 44: Final Report of OOAD (1).docx

DATA BASES USED IN UNIFIED LIBRARY MANAGEMENT SYSTEM:

Job Seeker Details:

Field Name DataType DescriptionUser Name CharField Primary keyPassword CharField -Qualification CharField -Experience CharField -

Company:

Field Name DataType DescriptionCompany_code CharField Primary keyCompany_name CharField -Place CharField -Email CharField -Web site EmailField

Admin:

Field Name DataType DescriptionUser_Name CharField Primary keyPassword CharField -Email CharField -

44

Page 45: Final Report of OOAD (1).docx

45


Recommended