Conference Management System .3 Su

MOHAN BABU UNIVERSITY
SREE SAINATH NAGAR, TIRUPATI - 517 102, ANDHRA PRADESH
DEPARTMENT OF COMPUTER APPLICATIONS
CERTIFICATE
This is to certify that the Mini Project Work entitled
“EVENT MANAGEMENT SYSTEM”

is the Bonafede work done by
G.SURESH 22102D020030
In the Department of Computer applications, Mohan Babu university in partial

fulfillment of the requirements for the award of Master of Computer Applications
during 2023-2024.
This is work has been carried out under my guidance and supervision.
The results embodied in this Project report have not been submitted in any
University or Organization for the award of any degree or diploma.
Internal Guide Head
Ms. P. Neeraja Dr. M. Sunil Kumar

Assistant Professor Professor & Head
Dept of CA Dept of CSE
MBU, Tirupati MBU, Tirupati
INTERNAL EXAMINER EXTERNAL EXAMINER
1
“EVENT MANAGEMENT SYSTEM”
A Mini Project Report submitted to
MOHAN BABU UNIVERSITY , TIRUPATI.

In Partial Fulfillment of the Requirements for the Award of the degree of
MASTER OF COMPUTER APPLICATIONS
IN
COMPUTER APPLICATIONS
BY
G SURESH 22102D020030
Under the Guidance of

Ms.P.Neeraja,
Assistant Professor
Dept of CA, MBU
Department of Computer Applications

MOHAN BABU UNIVERSITY
Sree Sainath Nagar, Tirupati – 517 102
2
2023-2024
3
DECLARATION
We hereby declare that this Mini project report titled “EVENT
MANAGEMENT SYSTEM” is a genuine project work carried out by me, in
Master of computer applications degree course of Mohan Babu
University, Tirupati and has not been submitted to any other course or
University for the award of any degree by us.
Signature of the
student
G.SURESH
4
ACKNOWLEDGEMENT
We are extremely thankful to our beloved Chairman and founder
Dr. M. MOHAN BABU Garu who took keen interest to provide us the
infrastructural facilities for carrying out the project work.
We are highly indebted to Dr. B. M. Satish, Dean ,School of

Computing of Mohan Babu University for his valuable support and guidance
in all academic matters.
We are very much obliged to Dr. M. Sunil Kumar, Head, Department

of Computer Science of Engineering, for providing us the guidance and
encouragement in completion of this project.
We would like to express our deep sense of gratitude to Ms. P.Neeraja

Assistant Professor, Department of CA, for the constant guidance, support
and invaluable guidance provided for the successful completion of the
project.
We are also thankful to all the faculty members of CA Department, who

have cooperated in carrying out our project. We would like to thank our
parents and friends who have extended their help and encouragement either
directly or indirectly in completion of our project work.
5
ABSTRACT
The Event Management System is a website
in which candidate can submit the paper and register
themselves and then attend the confere nce. The paper will
be reviewed The details of conference date and time

will be made available to them through the website.
After getting the confirmation details the candidate
should submit the revised and camera ready paper if
their paper is selected. Then the presentation takes
place and valedictory function is held to distribute the
prizes to the winners.
This system eases the process of
attending a conference and making the best out of it.
It provides a hassle free and seamless communication
between organizer and participants and easy access to
the information. It can accommodate the participants
without any problems as most of the process is
automated.
6
S.no Chapter Name Page.no
1 Introduction 9-13
2 Uml views and Diagrams 14-15
3 Project description 16-18
4 Use case diagrams 19-28
5 Class diagram 29-40
6 Object diagram 41-47
7 Sequence diagram 48-53
8 Collaboration diagram 54-59
9 Activity diagram 60-68
10 State chart diagram 69-74
11 Component diagram 75-82
12 Deployment diagram 83-90
13 Conclusion 91-92
14 Bibliography 93-94
7
Table.no Description Page.no
2.1 Uml views and diagrams 14
4.6.3.1 Description for the 28

Use case define feature

Use case define product

Use case generate product bundle

Use case generate runtime installer

Use case generate branded RUS

Use case manage & product entitlements

Use case generate product key

Use case manage customer

Use case product activation
5.6
Description table for class diagram 40
8
FIGURE OF INDEX
Fig.no Fig.name Page.no
4.5 Use case diagram 19
5.5 Class diagram 29
6.5 Object diagram 41
7.5 Sequence diagram 48
8.5 Collaboration diagram 54
9.5 Activity diagram 60
10.5 State chart diagram 69
11.5 Component diagram 75
12.5 Deployment diagram 83
9
Chapter - 1
INTRODUCTION
9
1. INTRODUCTION
UNIFIED MODELING LANGUAGE:
The Unified Modeling Language (UML) is a graphical language for visualizing,

specifying, constructing and documenting the artifacts of a software intensive system.
A successful software organization is one that consistently deploys a quality software that
meets the needs of its users . An organization that can deploy that software in a timely
and predictable fashion, with an effective use of resources, is one that has a sustainable
business.
Modeling is a central part of all the activities that lead up to the deployment of good
software. We build models to communicate the desired structure and behavior of our
system.
Unsuccessful software projects fail in their unique way, but all successful projects are
alike in many ways. There are many elements that contribute to a successful software
organization; one common thread is the use of modeling.
The UML gives us the standard way to write system’s blue prints that covers the
conceptual things, such as business processes and system functions as well as concrete
things, such as classes written in a specific programming language, database schemas,
and reusable software components.
The UML addresses the documentation of a system’s architecture and all of its details.
The UML also provides a language for expressing requirements and for tests.
The UML is appropriate for modeling systems ranging from enterprise information
systems to distributed web-based applications and even to the hard real time embedded
systems. UML also provides a language for modeling the activities of project planning
and release management.
10
Models consist of objects that interact by sending message. Think an object as alive.
Objects have things they know (attributes) and the things they can do (methods or
operations). The values of an object’s attributes determine its state.
Classes are the blue prints for objects. A class wraps attributes and methods into a single
distinct entity. Objects are instances of classes. UML is process independent, although it
should be used in a process that is use case driven, architecture-centric and iterative and
incremental.
The vocabulary of UML encompasses three kinds of building blocks:

1. Things
2. Relationships
3. Diagrams
THINGS:
Things are abstractions that are first-class citizens in a model; relationships tie these
things together; diagram group interesting collections of things. There are four kinds of
things in UML. They are:
1. Structural things
2. Behavioral things
3. Grouping things
4. An notational things
RELATIONSHIPS:
A Relationship is a connection among things. In object-oriented modeling, the four most
important relationships are dependencies, generalizations, associations and realizations.
These relationships are the basic relational building blocks of the UML. We use them to
write well- formed models.
DEPENDENCY:
A Dependency is a using relationship specifying that a change in the
specification of one thing may affect another thing that uses it, but not necessarily the
reverse.
11
Fig: Dependency
GENERALIZATION:
A Generalization is a relationship between a general thing (super class or
parent) and a more specific kind of that thing (subclass or child).
▷
Fig: Generalization
ASSOCIATION:
An Association is a structural relationship, specifying that objects of one thing are
connected to objects of another.
0…1
*
Employer
Employee
Fig: Association
REALIZATION:
A Realization is a semantic relationship between classifiers in which one
classifier specifies a contract that another classifier guarantees to carry out. We will
encounter these relationships in two places: between interfaces and the classes or
components that realize them.
Fig: Realization
DIAGRAMS:
A Diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and arcs (relationships). We draw diagrams to
visualize a system from different perspectives, so a diagram is a projection into a system.
12
UML includes 9 such diagrams. They are:
1. Use Case diagram
2. Class diagram
3. Object diagram
4. Sequence diagram
5. Collaboration diagram
6. Activity diagram
7. State Chart diagram
8. Component diagram
9. Deployment diagram
Each diagram is described in the project regarding “CONFERENCE MANAGEMENT

SYSTEM”
13
Chapter – 2
UML VIEWS AND
DIAGRAMS
14
2. UML VIEWS AND DIAGRAMS
Major area View Diagrams Main concepts

Class,
Static view Class diagram association,
Generalization,
dependency,
realization,
interface
Structural
Use case view Use Use case, actor,
case association,
diagra extend, include,
m use case
generalization
Deployment Deployme Node, component,

view nt dependency,
diagram location
Implementati Compone Component,

on View nt interface,
diagram dependency,
realization
Dynamic view Statech State, event,

art transition, action
diagra
m
Behaviour Dynamic view Activity State, activity,

diagram completion transition,
fort, join, swim lanes
Interaction view Sequen Interaction,

ce object, message,
diagra activation
m
Collaborati Collaboration,
on diagram interaction, object,
message, collaboration
role, activation
15
Model Model Class diagram Package,
Manageme manageme subsystem, model
nt nt View
Table 2.1: UML VIEWS AND DIAGRAMS
16
Chapter – 3
PROJECT DESCRIPTION
17
3. PROBLEM STATEMENT
A conference management system is essential for the efficient organization and execution of conferences,
seminars, and similar events. However, existing systems often lack the versatility, user-friendliness, and scalability
required to meet the evolving needs of event organizers and participants.
The problem statement focuses on addressing the following challenges:
1. Complexity and Inefficiency: Current conference management systems are often complex to set up and
use. Event organizers require extensive training to navigate these systems, resulting in inefficiency and
errors.
2. Limited Scalability: Many existing systems are not designed to handle the increasing scale of events.
They lack the capacity to manage large numbers of attendees, sessions, and speakers effectively.
3. User Experience: User interfaces of current systems are not always user-friendly. Participants and
organizers often struggle to navigate through registration, schedule management, and communication
features, leading to a subpar user experience.
4. Integration: Compatibility issues with other tools, such as payment gateways, virtual meeting platforms,
and data analytics tools, often hinder the seamless integration of a conference management system.
5. Data Security: Ensuring the security and privacy of sensitive information, including attendee data,
payment details, and intellectual property, is a significant concern in the current landscape.
6. Lack of Customization: Event organizers often have unique requirements for their conferences. Existing
systems do not always offer the flexibility needed to tailor the system to specific event needs.
7. Accessibility and Inclusivity: The accessibility features for participants with disabilities are often
overlooked in current systems, making it challenging for all attendees to fully engage with the event.
8. Support and Maintenance: Adequate customer support and system maintenance are critical for the
smooth operation of conference management systems. Many systems fall short in providing timely
support and regular updates.
The proposed solution is to develop a state-of-the-art conference management system with a user-centric
approach. This system will address the challenges mentioned above by providing a user-friendly interface,
scalability, robust data security, customization options, accessibility features, and seamless integration with other
event tools. Additionally, it will offer comprehensive support and regular updates to ensure the system's
longevity and efficiency.
This new conference management system aims to empower event organizers to create and manage successful,
accessible, and inclusive conferences, enhancing the overall experience for both organizers and participants
Design and develop a Conference Management System (CMS) that facilitates the organization, management, and participation of
conferences, seminars, and similar events. The system should address the various challenges faced by conference organizers and
attendees, providing a seamless and efficient experience.
Key Features of the Conference Management System:
User Registration and Profile Management:

18
Allow users to register as participants, speakers, or organizers.
Collect and store user information, including contact details and affiliations.
Event Creation and Management:
Enable organizers to create and configure conference events.

Define event details, such as date, time, location, and themes.
Set up registration processes and pricing options.
Abstract and Paper Submission:
Provide a platform for authors to submit abstracts and research papers.

Support peer review and selection of accepted submissions.
Notify authors of submission status and feedback.
Registration and Ticketing:
Offer online registration and ticketing options.

Support multiple payment methods.
Generate digital tickets and receipts for attendees.
Agenda and Program Management:
Display event schedules, sessions, and speakers.

Allow attendees to customize their personal agendas.
Notify participants of any schedule changes or updates.
Speaker and Presenter Management:
Manage information about speakers and presenters.

Enable speakers to upload presentation materials.
Facilitate communication between speakers and organizers.
Attendee Communication:
Implement discussion forums, chat systems, and messaging features.

Facilitate networking opportunities among attendees.
Live Streaming and Recording:
Provide live streaming of sessions and keynote speeches.

Archive and make recordings available for on-demand viewing.
Evaluation and Feedback:
Collect attendee feedback through surveys and rating systems.

Utilize feedback to improve future events.
Sponsorship and Exhibitor Management:
Allow sponsors and exhibitors to book space and promote their products.
Track sponsorship packages and deliverables.
Analytics and Reporting:
Offer insights into event performance and attendee engagement.

Provide organizers with data for informed decision-making.
Security and Privacy:
Implement robust security measures to protect user data.

Ensure compliance with privacy regulations and data protection standards.
19
Chapter - 4
USE CASE DIAGRAM
20
3. USE CASE DIAGRAM
A Use Case Diagram shows a set of use cases and actors and their relationships. Use
case diagrams address the static use case view of a system. For the most part, this
involves modeling the context of a system, subsystem, or class, or modeling the
requirements of the behavior of these elements. These diagrams are especially important
in organizing and modeling the behaviors of a system. These diagrams are important for
visualizing, specifying and documenting the behavior of an element.
COMMON PROPERTIES:
A Use Case Diagram is a just a special kind of diagram and shares the same
common properties as do all other diagrams. A use case diagram differs from all other
kinds of diagrams in its particular content.
CONTENTS:
Use case diagram commonly contains the following things:
♦ Use Case
♦ Actor
♦ Relationships
USE CASE:
Use Case is a description of set of sequence of actions that a system performs that yields
an observable result of value to a particular actor. A use case is used to structure the
behavioral things in a model. A use case is realized by collaboration. Graphically a Use
Case is rendered as an ellipse with solid lines, usually including only its name, as shown
below.
Place
order
Fig: Use case
21
ACTOR:
Actor is the user of the system, who performs action on the system and to whom
the system yields an observable result of value. Graphically, Actor is rendered as Stick
Figure.
Fig: Actor
RELATIONSHIPS:
Dependency is a semantic relationship between two things in which a change to

one thing may affect the semantics of the other thing. Graphically, a Dependency is
rendered as a dashed line, possibly directed, and occasionally including a label.
Fig: Dependency
An Association is a structural relationship that describes a set of links, a link

being a connection among objects. Aggregation is a special kind of association,
representing a structural relationship between a whole and its parts. Graphically, an
Association is rendered as a solid line, possibly directed, occasionally including a
label.
0….1 *
Employer Employee
Fig: Association
A Generalization is a specialization / generalization relationship in which

objects of the specialized element (child) are substitutable for objects of the
generalized element (parent). Graphically, a Generalization relationship is rendered
as a solid line with a hollow arrow head pointing to the parent.
▷
Fig: Generalization
22
● Like all other diagrams, use case diagram may contain notes and constraints. Use
case diagram may also contain packages, which are used to group elements of your model
into larger chunks.
COMMON USES:
TO MODEL THE CONTEXT OF A SYSTEM:
Modeling the context of a system involves drawing a line around the whole system and
asserting which actor lie outside the system and interacts with it. Here, use case diagrams
are used to specify the actors and the meaning of their roles.
TO MODEL THE REQUIREMENTS OF A SYSTEM:

Modeling the requirements of a system involves specifying what that system should do
independent of how that system should do it. Here, use case diagrams are used to specify
the desired behavior of the system.
COMMON MODELING TECHNIQUES

MODELING THE CONTEXT OF A SYSTEM:
To model the contents of a system,
⮚ Identify the actors that surround the system by considering the system by considering
which groups require help from the system to perform their tasks; which groups are
needed to execute the system’s functions; which groups interact with external hardware or
other software systems; and which groups perform secondary functions for administration
and maintenance.
⮚ Organize actors that are similar to one another in a generalization/specialization
hierarchy.
⮚ Where it aids understandability, provide a stereotype for each such actor.
⮚ Populate a use case diagram with these actors and specify the paths of
communication from each actor to the systems use cases.
MODELING THE REQUIREMENT OF A SYSTEM:
23
To model the requirements of a system,
⮚ Establish the context of the system by identifying the actors that surround it.
⮚ For each actor, consider the behavior that each expects or requires the system to
provide.
⮚ Name this common behavior as use cases.
⮚ Factor common behavior into new use cases that are used by others.
⮚ Model these use cases, actors, and their relationships in a use case diagram.
FORWARD AND REVERSE ENGINEERING:

Forward engineering is the process of transforming a model into a code through a
mapping to an implementation language. A use case diagram can be forward engineered
to form tests for the elements o which it applies.
To forward engineer a use case diagram:
❖ For each use case in the diagram, identify its flow of events and its exceptional
flow of events.
❖ Depending on how deeply you choose to test, generate a test script for each flow,
using the flow’s preconditions as the test’s initial state and its post conditions as its
success criteria.
❖ As necessary, generate test scaffolding to represent each actor that interacts with the
use case. Actors that push information to the element or are acted on by the element may
either be simulated or substituted by its real-world equivalent.
❖ Use case tools to run these tests each time you release the element to which the
use case diagram applies.
Reverse engineering is the process of transforming code into a model through a mapping
from a specific implementation language.
To reverse engineer a use case diagram:
❖ Identify each actor that interacts with the system.
❖ For each actor consider the manner in which that actor interacts with the system,
changes the state of the system or its environment, or responds to some event.
❖ Trace the flow of events in the executable system relative to each actor. Start with
primary flows and only later consider alternative paths.
24
❖ Cluster related flows by declaring a corresponding use case. Consider modeling
common flows by applying include relationships.
❖ Render these actors and use cases in a use case diagram, and establish their
relationships
25
USE CASE DIAGRAM
25
USE CASE DIAGRAM DESCRIPTION
FOR CONFERENCE MANAGEMENT
SYSTEM:
ACTORS:
♦ participant
♦ volunteer
♦ panelists
♦ organization
USE CASES:
♦ Registration
♦ Abstract submission
♦ Email alert
♦ Confirmation
♦ Mail entry pass
♦ Final round
♦ Result decision
♦ Asian time slot
♦ Valedictory
USE CASES DESCRIPTION:
Table 4.6.3.1: Description for the use case registration
Use Case
Registration
Actors Participant
Purpose To the registration
Description When registration to the participants.
Table 4.6.3.2: Description for the use case abstraction submission
Use case Abstraction submission

Actors Participant, panelists
Purpose To view the abstraction
Description When customer wants to view the abstraction.
26
Table 4.6.3.3: Description for the use case email alert
Use case Email alert

Actors panelists
Purpose To create an E-mail account.
Descriptio Customer creates an E-mail account to access the website.
n
Table 4.6.3.4: Description for the use case conformation
Use case conformation

Actors panelists
Purpose To access the panelists.
Descriptio required to access the conformation
n
Table 4.6.3.5: Description for the use case mail entry pass
Use case Mail entry pass

Actors panelists
Purpose To know the available entry pass
Descriptio All the available mail pass.
n
Table 4.6.3.6: Description for the use case Select final round
Use case Final round

Actors Participant, panelists
Purpose To choose the decision
Descriptio The final round is can be show the result
n
Table 4.6.3.7: Description for the use case result decision
Use case Result decision

Actors organization
Purpose To submit an result
Descriptio Organization can finals the result
n
Table 4.6.3.8: Description for the use case Asian time slot
Use case Asian time slot

Actors organization
Purpose Organizers Asian time
Descriptio Organization is time slot.
n
27
Table 4.6.3.9: Description for the use case valedictory
Use case valedictory

Actors Participant, panelists, organization
Purpose To the valedictory
Descriptio Main thing of the valedictory
n
28
Chapter – 5
CLASS DIAGRAM
29
4. CLASS DIAGRAM
A Class Diagram shows a set of classes, interfaces and collaborations and their
relationships. These diagrams are the most common diagram found in modeling object-
oriented systems.
COMMON PROPERTIES:
A Class Diagram is just like as special kind of diagram and shares the same properties as
all other diagrams. But it differs from all other diagrams in its contents.
CONTENTS:
Class diagram commonly contains the following things
♦ Classes
♦ Interfaces
♦ Collaborations
♦ Dependency, generalization and association relationships.
CLASSES:
Class is a description of a set of objects that share the same attributes, operations,
relationships and semantics. A class implements one or more interfaces. Graphically, a
Class is rendered as a rectangle, usually including its name, attributes and operations.
Window
Origin: char
Size: int
close()
move()
display
()
Fig: Class
30
The above class name is Window which is represented at the top segment in the rectangle
and its attributes in the middle compartment and its operations in the last compartment.
INTERFACES:
Interface is a collection of operations that specify a service of a class or component. An
interface describes the externally visible behavior of that element. An interface might
represent the complete behavior of a class or component. Graphically, an Interface is
rendered as a circle together with its name.
ISpelling
Fig: Interface
COLLABORATION:
Collaboration defines an interaction and is a society of roles and other elements that
work together to provide some cooperative behavior. So collaborations have structural as
well as behavioral, dimensions. Graphically, Collaboration is rendered as an ellipse with
dashed lines, usually including only its name.
Ch
ain of
responsibili
Fig: Collaboration
DEPENDENCY:
Dependency is a semantic relationship between two things in which a change to
one thing may affect the semantics of the other thing. Graphically, a Dependency is
rendered as a dashed line, possibly directed, and occasionally including a label.
Fig: Dependency
31
GENERALIZATION:
A generalization is a specialization / generalization relationship in which objects of the
specialized element (child) are substitutable for objects of the generalized element
(parent). In this way, the child shares the structure and the behavior of the parent.
Graphically, a Generalization relationship is rendered as a solid line with a hollow
arrow head pointing to the parent.
Fig: Generalization
ASSOCIATION:
An association is a structural relationship that describes a set of links, a link being
a connection among objects. Graphically, an Association is rendered as a solid line,
possibly directed, occasionally including a label.
0….1 *
Employer Employee
Fig: Association
COMMON USES:
Class diagram has mainly three uses when we model the static design view. They are:
⮚ To model the vocabulary of a system.

⮚ To model simple collaborations.
⮚ To model the logical database schema.
COMMON MODELING TECHNIQUES:

MODELING SIMPLE COLLABORATIONS:
When we create a class diagram, we have to model a part of the things and
relationships that make up our system’s design view. So, each class diagram should focus
on one collaboration at a time.
The steps involved to model simple collaboration are:
32
♦ Identify the mechanism we would like to model. A mechanism represents some
function or behavior of the part of the system.
♦ For each mechanism identify the classes, interfaces and other collaborations that
participate in this collaboration. Also, identify the relationship among these things.
♦ Use scenarios to walk through these things to discover the missing parts of our
model and parts that are semantically wrong.
♦ Be sure to populate these elements with their contents.
For example the following diagram shows the set of classes drawn for the implementation
of an autonomous robot. The figure focuses on the classes involved in the mechanism for
moving robot along the path. We will find an abstract class (motor) with two concrete
children, Steering motor and Main motor. Both of these classes inherit the five operations
of their parent, Motor. The two classes are in turn shown as parts of another class, Driver.
1
Path Collision
Agent Sensor
Responsibiliti 1
es D
--seek path rive
1 1
Sterigmatu Main
m Motor
Mot
or
move(d:Direction;s:spe
ed)
stop()
resetCount()
Status status()
33
MODELING A LOGICAL DATABASE SCHEMA:
The class diagrams are superset of the E-R diagrams, a common modeling tool for logical
database design. In E-R diagrams we focus only on data where as in class diagrams we go
a step further by the modeling of behavior. The steps involved to model logical
database schema are:
♦ Identify the classes of our model whose state must transcend the lifetime of their
applications.
♦ Create the class diagram that contains all these classes and mark them as persistent.
♦ Expand the structural details of these classes i.e., specify the details of their
attributes and focusing on the associations and their cardinalities.
♦ Watch for common patterns that complicate physical database design, such as
cyclic associations, one-to-one associations and n-array associations.
♦ Consider the behavior of these classes by expanding operations that are important
for data access and data integrity.
♦ Use tools to transform our logical design into a physical design.
Departm
ent
{Persistent}
name: Name
addInstructor()
removeInstructor
()
Instructor
{persistent}
name: Name
School Course
{Persistent} {persistent}
name: Name name: Name

address: String courseID :
phone:
Number
add Student()
remove
Student() get
Student()
34
getAllStudents()
Student
{persistent}
name: Name
studentID:Num
b
Fig: Modeling a logical database schema
35
For example, the above figure shows a set of classes drawn from an information system
of a school .The classes Student and Course are related to one another by association,
specifying that every student may attend any number of courses and every courses may
have any number of students. Similarly, the classes Course and Instructor are related by
association. All six of these classes are marked as persistent, indicating that their
instances are intended to live in a database or in some other form of persistent store. This
diagram also exposes the attributes of all six of these classes. Two of these classes expose
operations for manipulating their parts. These operations are included because they are
important to maintain data integrity.

Forward Engineering is the process of transforming a model into code through a
mapping to an implementation language. Forward engineering results in the loss of
Information because models written in the UML are semantically richer than any other
object-oriented programming Language.
The steps involved to forward engineer a class diagram are:

♦ Identify the rules for mapping to our implementation language or language of our
choice.
♦ Depending on the semantics of the languages we choose, we may have to
constrain our use of certain UML features.
♦ Use tagged values to specify our target language.
♦ Use tools to forward engineer our models.
36
For example the following diagram illustrates a simple class diagram specifying an
instantiation of the chain of responsibility pattern. This particular instantiation involves
three classes Client, Event Handler and GUI Event Handler. Client and Event Handler are
abstract classes, whereas GUI Event Handler is concrete.
Client
GUIEventHandl
{java}
er
{java}
Fig: Forward Engineer
Reverse Engineering is the process of transforming code into a model through a

mapping from a specific implementation language. It is an incomplete process. It results
in a flood of information which is at lower level of detail.
The steps involved to reverse engineer a class diagram are:

♦ Identify the rules for mapping from our implementation language or languages of
choice.
♦ Using a tool, point to the code for which we would like to reverse engineer.
♦ Using our tool create a class diagram by querying the model.
37
38
Class Diagram for CONFERENCE MANAGEMENT SYSTEM
 class name
 attribute name
 operations
39
CLASS DIAGRAM DESCRIPTION FOR
SI.NO CLASS NAME ATTRIBUTE NAME OPERATION
1 Participant reference no, Verify(),

Username Score(),
Password : char Pays amount(),
Score : int Delete details()
2 Register name , Enter details()

branch Enter details(),
delete details()
3 Reviewer paper name, Send selected paper,

marks selects paper
4 Organizer payment, Handle payment,

feedback gives feedback
5 Payment account no :int get account no()

cheque no :int send payment details()
DD no :int
6. Result Name: string send email()
6
Database topics :string,
total amount: string access details()
payment :int
CONFERENCE MANAGEMENT SYSTEM:
40
Chapter - 6
OBJECT DIAGRAM
41
5. OBJECT DIAGRAM
An Object Diagram is a diagram that shows a set of objects and their relationships at a
point in time. Graphically, an Object Diagram is a collection of vertices and arcs.
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.
STATIC VIEW: An aspect of a system that emphasizes its structure.
COMMON PROPERTIES:
An Object Diagram is a special kind of diagram and shares the same common properties
as all other diagrams-that is, a name and graphical contents that are a projection into a
model. What distinguishes an object diagram from all other kinds of diagrams is its
particular content.
CONTENTS:
Object diagrams commonly contain
♦ Objects
♦ Links
Like all other diagrams, object diagrams may contain notes and constraints. Object
diagrams may also contain packages or subsystems, both of which are used to group
elements of your model into larger chunks.
COMMON USES:
You use object diagrams to model the static design view or static process view of a
system just as you do with class diagrams. This view primarily supports the functional
requirements of a system. Object diagram has one use to model the static view of a
system. That is:
TO MODEL OBJECT STRUCTURES:
42
Modeling object structures involves taking a snapshot of the objects in a system at a given
moment in time. An object diagram represents one static frame in the dynamic storyboard
represented by an interaction diagram. You use object diagrams to visualizing, specify,
construct, and documenting the existence of certain instances in your system, together
with their relationships to one another.

MODELING OBJECT STRUCTURES:
If you freeze a running system or just imagine a moment of time in a modeled system,
you’ll find a set of objects, each in a specific state, and each in a particular relationship to
other objects. You can use object diagrams to visualize, specify, construct, and
documenting the structure of these objects. Object diagram are especially useful for
modeling complex data structures.
To model an object structure,
♦ Identify the mechanism you'd like to model. A mechanism represents some
function or behavior of the part of the system you are modeling that results from the
interaction of a society of classes, interfaces, and other things.
♦ For each mechanism, identify the classes, interfaces, and other elements that
participate in this collaboration; identify the relationships among these things, as well.
♦ Consider one scenario that walks through this mechanism. Freeze that scenario at
a moment in time, and render each object that participates in the mechanism.
♦ Expose the state and attribute values of each object, as necessary, to understand
the scenario.
♦ Similarly, expose the links among these objects, representing instances of
associations among them.
For example, below figure shows a set of objects drawn from the implementation of an
autonomous robot. This figure focuses on some of the objects involved in the mechanism
used by robot to calculate a model of the world in which it moves.
43
As this figure indicates, one object represents the robot itself(r, an instance of Robot), and
r is currently in the state marked moving. This object has a link to w, an instance of
world, which represents an abstraction of the robot's world model. This object has a link
to a multi object that consists of instances of Element, which represent entities that the
robot has identified but not yet assigned in its world view. These elements are marked as
part of robot's global state.
At this moment in time, w is linked to two instances of Area. One of them (a2) is shown
with its own links to wall and one Door object. Each of these walls is marked with its
current width, and each is shown linked to its neighboring walls. As this object diagram
suggests, the robot has recognized this enclosed area, which has walls on three sides and a
door on the fourth.
Fig: Modeling an Object Structure
44
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 can't exactly instantiate these objects from the outside.
Reverse engineering (the creation of a model from code) an object diagram is a very
different thing. In fact, while you are debugging your system, this is something that you
or your tools will do all the time.
To reverse engineering an object diagram,

♦ Choose the target you want to reverse engineer. Typically, you'll set your context
inside an operation or relative to 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
♦ A necessary to understand their semantics, identify the links that exist among
these objects.
♦ 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
simplistic, expand the neighbors of certain interesting objects and expose each object's
more deeply.
45
OBJECT DIAGRAM
Fig 6.5: Object Diagram for CONFERENCE MANAGEMENT SYSTEM
46
OBJECT DIAGRAM DESCRIPTION FOR CONFERENCE
MANAGEMENT SYSTEM:
OBJECTS:
 Participate
 Register
 Review
 Payment
 Organizer
 Database
47
Chapter - 7
SEQUENCE DIAGRAM
48
6. SEQUENCE DIAGRAM
The Sequence Diagram is an interaction diagram that emphasizes the time ordering of
messages. Graphically, a Sequence Diagram is a table that shows objects arranged
along the X axis and messages, ordered in increasing time, along the Y axis.
Interaction Diagram describes sequences of messages exchanged among roles that

implement behavior of a system. A Classifier role is the description of an object that
plays a particular part within an interaction, as distinguished from other objects of the
same class. This diagram provides a holistic view of behavior in a system that is; it shows
the flow of control across many objects. The interaction diagram is of two types:
Sequence Diagram and Collaboration Diagram.
COMMON PROPERTIES:
The Sequence Diagram is just like as special kind of diagram and shares the same
properties as all other diagrams. But it differs from all other diagrams in its contents.
CONTENTS:
Sequence Diagram commonly contains the following things:
1. Objects
2. Links
3. Messages
OBJECTS:
Objects are typically named or anonymous instances of class. But may also represent
instances of other things such as components, collaboration and nodes. Graphically,
Object is rendered as a rectangle with underlining its name.
c: company
Fig: Object
49
LINKS:
A Link is a semantic connection among objects i.e., an object of an association is
called as a link. A Link is rendered as a line.
Fig: Link
MESSAGE:
A Message is a specification of a communication between objects that conveys the
information with the expectation that the activity will ensue.
COMMON USES:
Sequence Diagram has mainly one use when we model the dynamic aspects of a
system. That is:
7.3.1: TO MODEL FLOWS OF CONTROL BY TIME ORDERING:
Modeling a flow of control by time ordering emphasizes the passing of messages as
they unfold over time, which is a particularly useful way to visualize dynamic
behaviour in the context of a use case scenario. Sequence diagrams do a better job of
visualizing simple iteration and branching than do collaboration diagrams.

MODELING FLOWS OF CONTROL BY TIME
ORDERING: To model flows of control by time ordering,
⮚ Set the context for the interaction, whether it is a system, subsystem, operation, or
class, or one scenario of a use case or collaboration.
⮚ Set the stage for the interaction by identifying which objects play a role in the
interaction. Lay them out on the sequence diagram from left to right.
⮚ Set the lifeline for each object. In most of the cases, object will persist through the
entire interaction.
⮚ Starting with the message that initiates the interaction, lay out each subsequent
message from top to bottom between the lifelines, showing each message’s properties.
50
⮚ If we need to visualize the nesting of messages or the points in time when actual
computation is taking place, adorn each object’s lifeline with its focus of control.
⮚ If we need to specify time or space constraints, adorn each message with a timing
mark and attach suitable time or space constraints.
⮚ If we need to specify this flow of control more formally, attach pre and post
conditions to each message.

mapping to an implementation language. It is possible for both sequence and
collaboration diagrams, especially in the context of the diagram are an operation. It is
straightforward.
Reversing Engineering is the process of transforming code into a model through a

mapping from a specific implementation language. It is possible for both sequence and
collaboration diagrams, especially if the context of code is the body of operation. It is
hard.
51
SEQUENCE DIAGRAM
Fig 7.5: Sequence Diagram for CONFERENCE MANAGEMENT SYSTEM
52
SEQUENCE DIAGRAM DESCRIPTION FOR CONFERENCE
MANAGEMENT SYSTEM:
7.6.1. INTERACTIONS:
 Register and Payment
Confirmation
 Submit Abstract
 Forward the Abstraction
 Review Abstracts
 Selected Papers
 Intimate Selection
 Reporting
 Allott Seats
 Presentation
 Allot Panelists
 Paper Review
 Review Report
 Shortest List
 Feedback
53
Chapter - 8
COLLABORATION DIAGRAM
54
7. COLLABORATION DIAGRAM
The Collaboration Diagram is an interaction diagram that emphasizes the structural

organization of objects that send and receive messages. Graphically, a Collaboration
Diagram is a collection of vertices and arcs.
Interaction Diagram describes sequences of messages exchanged among roles that

implement behavior of a system. A Classifier role is the description of an object that
plays a particular part within an interaction, as distinguished from other objects of the
same class. This diagram provides a holistic view of behavior in a system that is; it shows
the flow of control across many objects. The interaction diagram is of two types:
Sequence Diagram and Collaboration Diagram.
COMMON PROPERTIES:
The Collaboration Diagram is just like as special kind of diagram and shares the same
properties as all other diagrams. But it differs from all other diagrams in its contents.
CONTENTS:
Collaboration Diagram commonly contains the following things
1. Objects
2. Links
3. Messages
OBJECTS:
Objects are typically named or anonymous instances of class. But may also represent
instances of other things such as components, collaboration and nodes. Graphically,
Object is rendered as a rectangle with underlining its name.
c: company
Fig: object
55
LINKS:
A Link is a semantic connection among objects i.e., an object of an association is
called as a link. A Link is rendered as a line.
Fig: Link
MESSAGES:
A Message is a specification of a communication between objects that conveys the
information with the expectation that the activity will ensue.
COMMON USES:
Collaboration Diagram has mainly one use when we model the dynamic aspects of a
system. That is,
8.3.1: TO MODEL FLOWS OF CONTROL BY ORGANIZATION:
Modeling a flow of control by organization emphasizes the structural relationships among
the instances in the interaction, along which messages may be passed. Collaboration
diagram do a better job of visualizing complex iteration and branching and of visualizing
multiple concurrent flows of control than do sequence diagram.

MODELING FLOWS OF CONTROL BY
ORGANIZATION: To model flows of control by organization,
♦ Set the context for the interaction, whether it is a system, subsystem, operation, or
class, or one scenario of a use case or collaboration.
♦ Set the stage for the interaction by identifying which objects play a role in the
interaction. Lay them out on the collaboration diagram as vertices.
♦ Set the initial properties of each of these objects such as attribute values, tagged
values, state, or role of any object, which change over the duration of interaction.
♦ Specify the links among these objects, along which messages may pass.
✔ Lay out the association links first.
56
✔ Lay out other links next, and adorn them with suitable path stereotypes.
♦ Starting with the message that initiates the interaction, attach each subsequent
message to the appropriate link, setting its sequence number.
♦ If we need to specify time or space constraints, adorn each message with a timing
mark and attach suitable time or space constraints.
♦ If we need to specify this flow of control more formally, attach preconditions and
post conditions to each message.

mapping to an implementation language. It is possible for both sequence and
collaboration diagrams, especially in the context of the diagram are an operation. It is
straightforward.
Reversing Engineering is the process of transforming code into a model through a

mapping from a specific implementation language. It is possible for both sequence and
collaboration diagrams, especially if the context of code is the body of operation. It is
hard.
57
COLLABORATION DIAGRAM
Fig 8.5: Collaboration Diagram for CONFERENCE MANAGEMENT SYSTEM
58
COLLABORATION DIAGRAM DESCRIPTION FOR
Objectives:
 Participant
 Organizers
 Confirmation System
 Panelist
Messages:
 1:Register and Payment
 2:Confirmation
 3:Submit Abstract
 4:Forward the Abstract
 5:Review Abstract
 6:Selected Papers
 7:Iintimate Selection
 8:Reporting
 9:Allot Seats
 10:Presentation
 11:Allot Panelists
 12:Paper Review
 13:Review Report
 14:Short List
 15:Feedback
 16:Prizes
 17:Award Giving
59
Chapter – 9
ACTIVITY DIAGRAM
60
9. ACTIVITY DIAGRAM
An Activity Diagram shows the flow from activity to activity. The activity diagram
emphasizes the dynamic view of a system.
An Activity Diagram is a variant of a state machine that shows the computational

activities involved in performing a calculation. An activity state represents an activity: a
workflow step or the execution of an operation. An activity graph describes both
sequential and concurrent groups of activities.
COMMON PROPERTIES:
An Activity Diagram is just a special kind of diagram and shares the same common
properties as do all other diagrams but they in their content.
CONTENTS:
Activity Diagram commonly contains three things.
1. Activity states and action states
2. Transitions
3. Objects
ACTIVITY STATES AND ACTION STATES:

An Activity States is a kind of states in activity diagram; it shows an ongoing non-atomic
execution within a state machine. An activity states can be further decomposed. An
Action States are States of the system, each representing the execution of an Action. An
action states can’t be further decomposed. The Activity and Action States are rendered
as
Lozenge shape.
ProcessBi
Fig: Activity State
61
TRANSITIONS:
A Transition specifies the path from one action or activity state to the next action
or activity state. The Transition is rendered as a simple directed line.
Fig: Transition
OBJECTS:
An Object is a concrete manifestation of an abstraction; an entity with a well defined
boundary and identity that encapsulates state and behavior; an instance of a class. Objects
may be involved in the flow of control associated with an activity diagram. The Object is
rendered as a rectangle.
c:company
Fig: Object
COMMON USES:
Activity Diagram has mainly two uses when we model the dynamic aspects of a system.
They are,
TO MODEL A WORKFLOW:
Here we will focus on activities as viewed by the actors that collaborate with the
system. Workflows often lie on the fringe of software-intensive systems and are used to
visualize, specify, construct and document business processes that involve the system we
are developing. In this use of activity diagrams, modeling object flow is particularly
important.
TO MODEL AN OPERATION:
Here we will use activity diagrams as flowcharts, to model the details of a
computation. In this use of activity diagrams, the modeling of branch, fork and join states
is particularly important. The context of an activity diagram used in this may involves the
parameters of the operation and its local objects.
62
MODELING A WORKFLOW:
To model a workflow,
♦ Establish a focus for the workflow. For nontrivial systems, it’s impossible to show
all interesting workflows in one diagram.
♦ Select the business objects that have the high –level responsibilities for parts of the
over all workflow. These may be real things from the vocabulary of the system, or they
may be more abstract. In either case, create a swim lane for each important business
object.
♦ Identify the preconditions of the workflow’s initial state and the post conditions of
the final state. This is important in helping you mode the boundaries of the workflow.
♦ Beginning at the workflow’s initial state, specify the activities actions that take
place over time and render them in the activity diagram as either activity states or action
states.
♦ For complicated actions, or for sets of actions that appear multiple times, collapse
these into activity states, and provide a separate activity diagram that expands on each.
♦ Render the transitions that connect this activity and action states. Start with the
sequential flows in the workflow first, next consider branching, and only then consider
forking
and joining.
♦ If there are important objects that are involved in the workflow, render them in the
activity diagram, as well. Show their changing values and state as necessary to
communicate
the intent of the object flow.
MODELING AN OPERATION:
To model an operation,
♦ Collect the abstractions that are involved in this operation. This includes the
operation’s parameters (including its return type, if any), the attributes of the enclosing
class, and certain
neighboring classes.
♦ Identify the preconditions at the operation’s initial state and post conditions at the
operation’s final state. Also identify any invariants of the enclosing class that must hold
during the execution of the operation.
♦ Beginning at the operation’s initial state, specify the activities and actions that
take place over time and render them in the activity diagram as either activity states or
63
action states.
64
♦ Use branching as necessary to specify conditional paths and iteration.
♦ Only if this operation is owned by an active class, use forking and joining as
necessary to specify parallel flows of control.

Forward engineering is possible for activity diagrams, especially if the context of the
diagram is an operation.
Reverse engineering is also possible for activity diagrams, especially if the context of the
code is the body of an operation.
65
ACTIVITY DAIAGRAM
66
Fig 9.5: Activity Diagram for CONFERENCE MANAGEMENT SYSTEM
67
ACTIVITY DIAGRAM DESCRIPTION FOR
9.6.1. ACTIVITIES:
 Idle(start stage)
 Register
 Accet the payment
 Confirmation
 Send panelists abstract
 Send to panelists
 Review-selected papers
 Mail selected papers
 Mail paper presence
 Selected top papers
 Valedictory function
 Idle(end stage)
68
Chapter - 10
STATECHART DIAGRAM
69
10. STATECHART DIAGRAM
A State chart Diagram shows a state machine, consisting of states, transitions, events,
and activities. The state chart diagram emphasizes the dynamic view of a system.
A State Machine models the possible life history of an object of a class. A state machine
contains states connected by transitions. Each state models a period of time during the life
time of an object during which it satisfies certain conditions. When an event occurs, it
may cause the firing of a transition that takes the object to a new state .When transition
fires, an action attached to the transition may be executed. State Machines are shown as
State Chart Diagrams.
COMMON PROPERTIES:
A State chart Diagram is just a special kind of diagram and shares the same common
properties as do all other diagrams but they differ in terms of contents.
CONTENTS:
Statechart Diagram commonly contains two things:
1. States
2. Transitions, including events and actions.
STATES:
A State is a condition or situation in the life of an object during which it satisfies some
condition, performs some activity, or waits for some event. Graphically, a State is
rendered as a rectangle with rounded corners.
Fig: State
70
TRANSITIONS:
A Transition is a relationship between two states indicating that an object in the first
state will perform certain actions and enter the second state when a specified event occurs
and specified conditions are satisfied. Graphically, a Transition is rendered as a solid
directed line.
Fig: Transition
EVENTS:
An Event is the specification of a significant occurrence that has a location in time
and space.
ACTIONS:
An Action an executable atomic computation that results in a change in state of the model
or the return of a value.
COMMON USES:
State Chart Diagram has mainly one use when we model the dynamic aspects of a
system. That is,
10.3.1. TO MODEL REACTIVE OBJECTS:
To model the behavior of a reactive object, we essentially specify three things: the stable
states in which that object may live, the events that trigger a transition from state to state,
and the actions that occur on each state change. Modeling the behavior of a reactive
object also involves modeling the lifetime of an object, starting at the time of the objects
creation and continuing until its destruction, highlighting the stable states in which the
object may be found.

MODELING REACTIVE OBJECTS:
To model reactive objects,
⮚ Choose the context for state machine, whether it is a class, a use case, or the
system as a whole.
⮚ Choose the initial and final states for the object. To guide the rest of your model,
possibly state pre- and post conditions of the initial and final states, respectively.
71
⮚ Decide on the stable states of the object by considering the conditions in which the
object may exist for some identifiable period of time. Start with the high-level states of
the
object and only then consider its possible sub states.
⮚ Decide on the meaningful partial ordering of stable states over the life time of the
object.
⮚ Decide on the events that may trigger a transition from state to state. Model these
events as triggers to transitions that move from one legal ordering of states to another.
⮚ Attach actions to these transitions (as in a Mealy machine) and/or to these states
(as in a Moore machine).
⮚ Consider ways to simplify your machine by using sub states, branches, forks,
joins, and history states.
⮚ Check that all states are reachable under some combination of events.
⮚ Check that no state is a dead end from which no combination of events will
transition the object out of that state.
⮚ Trace through the state machine, either manually or by using tools, to check it
against expected sequences of events and their responses.

Forward engineering is possible for state chart diagrams, especially if the context of the
diagram is a class. The forward engineering tool must generate the necessary private
attributes and final static constants.
Reverse engineering is theoretically possible, but practically not very useful. Reverse
engineering tools have no capacity for abstraction and therefore cannot automatically
produce meaning full state chart diagrams.
72
STATECHART DIAGRAM
Fig 10.5: State Chart Diagram for CONFERENCE MANAGEMENT SYSTEM

7
73
STATECHART DIAGRAM DESCRIPTION FOR
STATES:
 Idle
 Accept Payment
 Confirmation Mail
 Sent to Panelists
 Reviewed Selected Papers
 Mail Selected Papers
 Rate Presentation
 Selected Top Papers
 Valedictory Function
 Idle(Final stage)
EVENTS:
 Start the confirmation

 Accept the payment method
 Confirmation to mail
 Sent to panelists
 Reviewed the selected papers
 Mail selected the papers
 Rate the presentation
 Selected top papers
valedictory function
 Confirmation is ready management
74
Chapter - 11
COMPONENT DIAGRAM
75
11. COMPONENT DIAGRAM
A Component Diagram shows the organizations and dependencies among a set of

components. The component diagram emphasizes the static implementation view of a
system. The implementation view of a system encompasses the components and files
that are used to assemble and release the physical system. This involves modeling the
physical things that reside on a node, such as executables, libraries, tables, files and
documents. These are related to class diagrams in that a component typically maps to one
or more classes, interfaces, or collaborations.
COMMON PROPERTIES:
A Component Diagram is just a special kind of diagram and shares the same common
properties as all the diagrams but they in terms of contents.
CONTENTS:
Component Diagram commonly contains three things:
1. Components
2. Interfaces
3. Dependency, Generalization, Association and Realization relationships
COMPONENTS:
A Component is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces. Graphically, a Component is rendered as a
rectangle with tabs.
F
ind.exe
Fig: Component
76
INTERFACES:
An Interface is a collection of operations that are used to specify a service of a class or
component. Graphically, an Interface is rendered as a circle.
ISpelling
Fig: Interface
RELATIONSHIPS:
❖ A Dependency is a using relationship that states that a change in specification of
one thing may affect another thing that uses it, but not necessarily the reverse.
Graphically, a Dependency is rendered as a dashed line.
Fig: Dependency
❖ A Generalization is a relationship between a general thing i.e., (called the super
class or parent) and a more specific kind of that thing i.e., (called the subclass or
child). Generalization is sometimes called an “is-a-kind-of” relationship.
Graphically, Generalization is rendered as a solid directed line with open

arrowhead.
Fig: Generalization
❖ An Association is a structural relationship that specifies that objects of one thing
are connected to objects of another. Graphically, an Association is rendered as a

solid line. 0 *
Emplo Emplo
Fig: Association
77
❖ A Realization is a semantic relationship between classifiers in which one
classifier specifies a contract that another classifier guarantees to carry out.

Graphically, a Realization is rendered as a dashed directed line with a large
open arrowhead.
78
Fig: Realization
COMMON USES:
Component Diagram has mainly four uses when we model the static aspects of a
system. They are,
TO MODEL SOURCE CODE:
With most contemporary object oriented programming languages, you’ll cut code using
integrated development environments that store your source code in files. You can use
component diagrams to model the configuration management of these files, which
represent work-product components.
TO MODEL EXECUTABLE RELEASES:

A release is a relatively complete and consistent set of artifacts delivered to an internal or
external user. In the context of components, a release focuses on the parts necessary to
deliver a running system.
TO MODEL PHYSICAL DATABASES:

Think of a physical database as the concrete realization of a schema, living in the world of
bits. The model of the physical database represents the storage of that information in the
tables of a relational database or the pages of an object-oriented database.
TO MODEL ADAPTABLE SYSTEMS:

Some systems are quite static; their components enter the scene, participate in an
execution, and then depart. Other systems are dynamic, involving mobile agents or
components that migrate for purposes of load balancing and failure recovery.

MODELING SOURCE
CODE: To model source code,
79
♦ Either by forward or reverse engineering identifies the set of source code files of
interest and model them as components stereotyped as files.
♦ For larger system, use packages to show groups of source code files.
♦ Consider exposing a tagged value indicating such information as the version number
of the source code file, its author, and the date it was last changed. Use tools to manage
the value of this tag.
♦ Model the compilation dependencies among these files using dependencies.
Again, use tools to help generate and manage these dependencies.
MODELING AN EXECUTABLE RELEASE:

To model an executable release,
♦ Identify the set of components you’d like to model. Typically, this will involve some
or all the components that live on one node or the distribution of these sets of components
across all the nodes in the system.
♦ Consider the stereotype of each component in this set. For most systems, you’ll
find a small number of different kinds of components (such as executables, libraries,
tables, files, and
documents). You can use the UML extensibility mechanisms to provide visual cues for
these stereotypes.
♦ For each component in this set, consider its relationship to its neighbors. Most
often, this will involve interfaces that are exported (realized) by certain components and
imported
(used) by others. If you want to expose the seams in your system, model these interfaces
explicitly. If you want your model at a higher level of abstraction, elide these
relationships by showing only dependencies among the components.
MODELING A PHYSICAL DATABASE:

To model a physical database,
♦ Identify the classes in your model that represent your logical database schema.
♦ Select a strategy for mapping these classes to tables. You will also want to consider the
physical distribution of your databases. Your mapping strategy will be affected by the
location in which you want your data to live on your deployed system.
80
♦ To visualize, specify, construct, and document your mapping, create a component
diagram that contains components stereotyped as tables.
♦ Where possible, use tools to help you transform logical design into a physical design.
MODELING ADAPTABLE
SYSTEMS: To model an adaptable system,
♦ Consider the physical distribution of components that may migrate from node to node.
You can specify the location of component instance by marking it with a location tagged
value, which you can then render in a component diagram (although, technically
speaking, a diagram that contains only instances is an object diagram).
♦ If you want to model the actions that cause a component to migrate, create a
corresponding interaction diagram that contains component instances. You can illustrate a
change of location by drawing the same instance more then once, but with different
values for its location tagged value.

To forward engineer a component diagram,
♦ For each component, identify classes or collaborations that the component implements.
♦ Choose the target for each component. Your choice is basically between source code
(a form that can be manipulated by development tools) or a binary library or executable (a
form that can be dropped into a running system).
♦ Use tools to forward engineer your models.
To reverse engineer a component diagram,
♦ Choose the target you want to reverse engineer. Source code can be reverse
engineered to components and then classes. Binary libraries can be reverse engineered to
uncover their
interfaces. Executables can be reverse engineered the least.
♦ Using a tool, point to the code you’d like to reverse engineer. Use your tool to
generate a new model or to modify an existing one that was previously forward
engineered.
♦ Using your tool, create a component diagram by querying the model. For example, you
might start with one or more components then expand the diagram by following
relationships or neighboring components. Expose or hide the details of the components of
this component diagram as necessary to communicate your intent.
81
COMPONENT DIAGRAM
Fig 11.5: Component Diagram for CONFERENCE MANAGEMENT SYSTEM
82
COMPONENT DIAGRAM DESCRIPTION FOR
COMPONENTS:
 Mailing services
 Messaging services

RELATIONSHIPS:
 Association
83
Chapter - 12
DEPLOYEMENT DIAGRAM
84
12. DEPLOYMENT DIAGRAM
A Deployment Diagram shows the configuration of run-time processing nodes and the
components that live on them. Deployment Diagram addresses the static deployment
view of architecture. These are related to component diagrams.
The Deployment View of a system encompasses the nodes that form the system’s
hardware topology on which the system executes. This view primarily addresses the
distribution, delivery and installation of the parts that make up the physical system. The
static aspects of this view are captured in deployment diagrams; the dynamic aspects of
this view are captured in interaction diagrams, state chart diagrams and activity diagrams.
COMMON PROPERTIES:
A Deployment Diagram is a just a special kind of diagram and shares the same common
properties as do all other diagrams. A deployment diagram differs from all other kinds of
diagrams in its particular content.
CONTENTS:
Deployment Diagrams commonly contain these things:
1. Node
2. Relationships
NODE:
A Node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and often, processing capability.
Graphically, a Node is rendered as a cube, usually including only its name.
ser
Fig: Node
85
RELATIONSHIPS:
❖ A Dependency is a semantic relationship between two things in which a change
to one thing may affect the semantics of the other thing. Graphically, a
dependency is rendered as a dashed line, possibly directed, and occasionally

including a label.
Fig: Dependency
❖ An association is a structural relationship that describes a set of links, a link being
a connection among objects. Aggregation is a special kind of association,

representing a structural relationship between a whole and its parts. Graphically,
an association is rendered as a solid line, possibly directed, occasionally including
a label. 0 *
Emplo Emplo
Fig: Association
❖ Like all other diagrams, deployment diagrams may contain notes and constraints.
Deployment diagrams may also contain components, each of which must live on some
node. Deployment diagram may also contain packages, which are used to group elements
of your model into larger chunks.
COMMON USES:
Deployment Diagram has mainly three uses when we model the static aspects of a
system. They are,
TO MODEL EMBEDDED SYSTEMS:

An embedded system is a software intensive collection of hardware that interfaces with
the physical world. Embedded systems involve software that controls devices such as
motors, actuators, and displays and that in turn, is controlled by external stimuli such as
sensor input, movement, and temperature changes. You can use deployment diagrams to
model the devices and processors that comprise an embedded system.
86
TO MODEL CLIENT/SERVER SYSTEMS:
A client/server system is a common architecture focused on making a clear separation of
concerns between the system’s user interface and the system’s persistent data.
Client/server systems are one end of the continuum of distributed systems and require you
to make decisions about the network connectivity of clients to servers and about the
physical distribution of your system’s software components across the nodes. You can
model the topology of such systems by using deployment diagrams.
TO MODEL FULLY DISTRIBUTED SYSTEMS:

At the other end of the continuum of distributed systems are those that are widely, if not
globally, distributed, typically encompassing multiple levels of servers. Such systems are
often hosts to multiple versions of software components, some of which may even
migrate from node to node. Crafting systems requires you to make decisions that enable
the continuous change in the system’s topology. You can use deployment diagrams to
visualize the system’s current topology and distribution of components to reason about
the impact of changes on that topology.

MODELING AN EMBEDDED SYSTEM:
To model an embedded system,
⮚ Identify the devices and nodes that are unique to your system.
⮚ Provide visual cues, especially for unusual devices, by using the UML
extensibility mechanisms to define system-specific stereotypes with appropriate icons. At
the very least,
you’ll want to distinguish processors and devices.
⮚ Model the relationships among these processors and devices in a deployment diagram.
Similarly, specify the relationship between the components in your system’s
implementation view and the nodes in your system’s deployment view.
⮚ As necessary, expand on any intelligent devices by modeling their structure with a
more detailed deployment diagram.
87
MODELING A CLIENT/SERVER SYSTEM:
To model a client/server system,
⮚ Identify the nodes that represent your system’s client and server processors.
⮚ Highlight those devices that are germane to the behavior of your system. For example,
you’ll want to model special devices, such as credit card readers, badge readers, and
display devices other than monitors, because their placement in the system’s hardware
topology are likely to be architecturally significant.
⮚ Provide visual cues for these processors and devices via stereotyping.
⮚ Model the topology of these nodes in a deployment diagram. Similarly, specify
the relationship between the components in your system’s implementation view and the
nodes in
your system’s deployment view.
MODELING A FULLY DISTRIBUTED SYSTEM:

To model a fully distributed system,
⮚ Identify the system’s devices and processors as for simpler client/server systems.
⮚ If you need to reason about the performance of the system’s network or the impact of
changes to the network, be sure to model these communication devices to the level of
detail sufficient to make these assessments.
⮚ Pay close attention to logical groupings of nodes, which you can specify by using
packages.
⮚ Model these devices and processors using deployment diagrams. Where possible,
use tools that discover the topology of your system by walking your system’s network.
⮚ If you need to focus on the dynamics of your system, introduce use case diagrams
to specify the kinds of behavior you are interested in, and expand on these use cases with
interaction diagrams.
88
To reverse engineer a deployment diagram,
⮚ Choose the target that you want to reverse engineer.
⮚ Choose also the fidelity of your reverse engineering.
⮚ Use a tool that walks across your system, discovering its hardware topology.
Record that topology in a deployment model.
⮚ Along the way, we can use similar tools to discover the components that live on
each node, which we can also record in a deployment model.
⮚ Using modeling tools create a deployment diagram by querying the model. For
example, we might start with visualizing the basic client/server topology, and then
expand on
the diagram by populating certain nodes with components of interest that live on them.
89
DEPLOYMENT DIAGRAM
Fig 12.5: Deployment Diagram for CONFERENCE MANAGEMENT SYSTEM
90
DEPLOYMENT DIAGRAM DESCRIPTION FOR CONFERENCE
MANAGEMENT SYSTEM:
NODES:
 CONFERENCE MANAGEMENT SYSTEM
 Client workstation
 Server System
 Device
 Server
 Database
RELATIONSHIPS:
 Association
91
Chapter - 13
CONCLUSION
92
13. CONCLUSION
The contents of this “MINI PROJECT” explain how to model real time project with the
help of OOA through UML.
Any project or event given to be implemented in real world to be modeled in order to:
♣ Visualize the system as it is or we want it to be.

♣ Specify the behavior or the structure of the system.
♣ Construct the system with the help of templates.
♣ Document the decision we have made.
93
Chapter - 14
BIBLIOGRAPHY
94
14. BIBLIOGRAPHY
BOOKS:
❖ Object Oriented Analysis and Design with Applications- Pearson Edition Asia,
Grady Booch 2nd Edition.
❖ The Unified Modeling Language user guide-Addison Wesley, 1999. Grady
Booch, James rum baugh, Ivar Jacobson.
❖ Fundamentals of Object Oriented Design in UML, Addison Wesley, 2000. Meilir
Page-Jones.
❖ Object Oriented Analysis and Design, Andrew Haigh, Tata McGraw-Hill, 2001,
ISBN: 0-07-047277-7.
❖ Software Engineering, A practitioner’s Approach-Roger S. Pressman, 6th edition,
McGraw-Hill International Edition.
❖ Software Engineering-Sommerville, 7th edition, Pearson education.
WEBSITES:
♦ https://www.geeksforgeeks.org/class-diagram-for-hotel-management-system/
♦ https://www.grin.com/document/384237
♦ https://itsourcecode.com/uml/restaurant-management-uml-system-activity-diagram/
♦ https://creately.com/diagram/example/i2m765nf/restaurant-management-system - classic
♦ http://iaetsdjaras.org/gallery/14-jaras-327-december.pdf
♦ https://itsourcecode.com/uml/component-diagram-for-restaurant-management-system/
95

Conference Management System .3 Su

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Conference Management System .3 Su

Uploaded by

Copyright:

Available Formats

MOHAN BABU UNIVERSITY

SREE SAINATH NAGAR, TIRUPATI - 517 102, ANDHRA PRADESH

DEPARTMENT OF COMPUTER APPLICATIONS

This is to certify that the Mini Project Work entitled

“EVENT MANAGEMENT SYSTEM”

In the Department of Computer applications, Mohan Babu university in partial

Internal Guide Head

Ms. P. Neeraja Dr. M. Sunil Kumar

INTERNAL EXAMINER EXTERNAL EXAMINER

A Mini Project Report submitted to

MOHAN BABU UNIVERSITY , TIRUPATI.

MASTER OF COMPUTER APPLICATIONS

Under the Guidance of

Department of Computer Applications

We hereby declare that this Mini project report titled “EVENT

MANAGEMENT SYSTEM” is a genuine project work carried out by me, in

Master of computer applications degree course of Mohan Babu

University for the award of any degree by us.

We are extremely thankful to our beloved Chairman and founder

We are highly indebted to Dr. B. M. Satish, Dean ,School of

We are very much obliged to Dr. M. Sunil Kumar, Head, Department

We would like to express our deep sense of gratitude to Ms. P.Neeraja

We are also thankful to all the faculty members of CA Department, who

be reviewed The details of conference date and time

2 Uml views and Diagrams 14-15

3 Project description 16-18

4 Use case diagrams 19-28

5 Class diagram 29-40

6 Object diagram 41-47

7 Sequence diagram 48-53

8 Collaboration diagram 54-59

9 Activity diagram 60-68

10 State chart diagram 69-74

11 Component diagram 75-82

12 Deployment diagram 83-90

4.6.3.1 Description for the 28

4.6.3.2 Description for the 29

4.6.3.3 Description for the 29

4.6.3.4 Description for the 29

4.6.3.5 Description for the 29

4.6.3.6 Description for the 29

4.6.3.7 Description for the 29

4.6.3.8 Description for the 30

4.6.3.9 Description for the 40

5.5 Class diagram 29

6.5 Object diagram 41

7.5 Sequence diagram 48

8.5 Collaboration diagram 54

9.5 Activity diagram 60

10.5 State chart diagram 69

11.5 Component diagram 75

12.5 Deployment diagram 83

UNIFIED MODELING LANGUAGE:

The Unified Modeling Language (UML) is a graphical language for visualizing,

The vocabulary of UML encompasses three kinds of building blocks:

parent) and a more specific kind of that thing (subclass or child).

Each diagram is described in the project regarding “CONFERENCE MANAGEMENT

Major area View Diagrams Main concepts

Deployment Deployme Node, component,

Implementati Compone Component,

Dynamic view Statech State, event,

Behaviour Dynamic view Activity State, activity,

Interaction view Sequen Interaction,