Exp.

no:7 STATE CHART DIAGRAM

Date:

Aim:
To draw the State Chart Diagram for Hostel Management system.

Theory:

A State chart diagram describes a state machine. State machine can be defined as a machine which
defines different states of an object and these states are controlled by external or internal events.

State chart diagram is one of the five UML diagrams used to model the dynamic nature of a system.
They define different states of an object during its lifetime and these states are changed by events.
State chart diagrams are useful to model the reactive systems. Reactive systems can be defined as a
system that responds to external or internal events.

State chart diagram describes the flow of control from one state to another state. States are defined as
a condition in which an object exists and it changes when some event is triggered. The most important
purpose of State chart diagram is to model lifetime of an object from creation to termination.

Statechart diagrams are also used for forward and reverse engineering of a system. However, the main
purpose is to model the reactive system.

Following are the main purposes of using Statechart diagrams −

 To model the dynamic aspect of a system.

 To model the life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model the states of an object.

Basic Notations:

 State Chart Diagrams provide away to model the various states in which an
object an exist.
 There are two special states:
 The start state and
 the stop state.
 The Start state is represented by a block dot.
 The Stop state is represented by a bull’s eye.
 A condition enclosed in square brackets is called a guard condition, and controls
when a transition can or cannot occur.
 Process that occurs while an object is in certain state are called actions.
STATE CHART DIAGRAM FOR HOSTEL MANAGEMENT DIAGRAM:

Result:
The State Chart diagram was created successfully for Hostel Management System
Exp.no:8 SEQUENCE DIAGRAM
Date:

Aim:
To draw the Sequence diagram for Hostel Management system..

Theory:

UML sequence diagrams model the flow of logic within the system in a visual
manner, enabling the user both to document and validate the logic, and are commonly
used for both analysis and design purposes.Sequence diagrams are the most popular UML
artifact for dynamic modeling, which focuses on identifying the behavior within your
system. Sequence diagrams, along with class diagrams and physical data models are the
most important design-level models for modern application development.Sequence
diagrams are a popular dynamic modeling solution in UML because they specifically
focus on lifelines, or the processes and objects that live simultaneously, and the messages
exchanged between them to perform a function before the lifeline ends.

Sequence diagrams are typically used to model:

1. Usage scenarios.A usage scenario is a description of a potential way the system is

used.The logic of a usage scenario may be part of a use case, perhaps an alternate
course. Itmay also be one entire pass through a use case, such as the logic described by
the basic course of action or a portion of the basic course of action, plus one or more
alternate scenarios.The logic of a usages cenario may also be a pass through the logic
contained in several use cases. For example, a student enrolls in the university, and then
immediately enrolls in three seminars.
2. The logic of methods. Sequence diagrams can be used to explore the logic of a complex
operation, function, or procedure. One way to think of sequence diagrams, particularly
highly detailed diagrams,is as visual object code.
3. The logic of services. A service is effectively a high-level method, often one that can
be invoked by a wide variety of clients.This includes web-services as well as business
transactions implemented by a variety of technologies such as CICS/COBOL or
CORBA-compliant object request brokers (ORBs).
Basic Notations:

Actor
 a type of role played by an entity that interacts with the subject (e.g., by
exchanging signals and data)
 external to the subject (i.e., in the sense that an instance of an actor is not a
part of the instance of its corresponding subject).
 represent roles played by human users, external hardware, or
other subjects.

Note that:
 An actor does not necessarily represent a specific physical entity but merely
a particular role of some entity
 A person may play the role of several different actors and, conversely, a
given actor may be played by multiple different person.

Lifeline
 A lifeline represents an individual participant in the Interaction.

Activations
 A thin rectangle on a lifeline) represents the period during which an
element is performing an operation.
 The top and the bottom of the of the rectangle are aligned with the initiation
and the completion time respectively
Call Message
 A message defines a particular communication between Lifelines of an
Interaction.
 Call message is a kind of message that represents an invocation of
operation of target lifeline.

Return Message
 A message defines a particular communication between Lifelines of an
Interaction.
 Return message is a kind of message that represents the pass of information
back to the caller of a corresponded former message.

Self-Message
 A message defines a particular communication between Lifelines of an
Interaction.
 Self-message is a kind of message that represents the invocation of message
of the same lifeline.

Recursive Message
 A message defines a particular communication between Lifelines of an
Interaction.
 Recursive message is a kind of message that represents the invocation of
message of the same lifeline. It's target points to an activation on top of the
activation where the message was invoked from.

Create Message
 A message defines a particular communication between Lifelines of
an Interaction.
Destroy Message
 A message defines a particular communication between Lifelines of an
Interaction.
 Destroy message is a kind of message that represents the request
of destroying the lifecycle of target lifeline.

Duration Message
 A message defines a particular communication between Lifelines of an
Interaction.
 Duration message shows the distance between two time instants for a
message invocation.

Note

A note (comment) gives the ability to attach various remarks to elements. A

comment carries no semantic force, but may contain information that is useful to a

modeler.
SEQUENCE DIAGRAM FOR HOSTEL MANAGEMENT SYSTEM:

Result:
The Sequence diagram was created successfully for Hostel Management System
Exp.no:9 COLLABORATION DIAGRAM
Date:

Aim:
To draw the Collaboration Diagram for Fast Food Billing System

THEORY:

Collaboration diagrams are also relatively easy to draw.They show the relationship
between objects and the order of messages passed between them.The objects are listed as
icons and arrows indicate the messages being passed between them. The numbers next to
the messages are called sequence numbers.As the name suggests, they show the sequence of
the messages as they are passed between the objects.There are many acceptable sequence
numbering schemes in UML.A simple 1, 2, 3... format can be used, as the example below
shows, or for more detailed and complex diagrams a 1, 1.1,1.2, 1.2.1... scheme can be used.

Collaboration diagrams (known as Communication Diagram in UML 2.x) are used

to show how objects interact to perform the behavior of a particular use case, or a part of a
use case. Along with sequence diagrams, collaboration is used by designers to define and
clarify the roles of the objects that perform a particular flow of events of a use case. They
are the primary source of information used to determining class responsibilities and
interfaces.Unlike a sequence diagram, a collaboration diagram shows the relationships
among the objects. Sequence diagrams and collaboration diagrams express similar
information, but show it in different ways.Basic Notations:

Objects

An object is represented by an object symbol showing the name of the object and its class
underlined, separated by a colon:

Object_name :class_name

You can use objects in collaboration diagrams in the following ways:

 Each object in the collaboration is named and has its class specified
 Not all classes need to appear
 There may be more than one object of a class
 An object’s class can be unspecified. Normally you create a collaboration
 diagram with objects first and specify their classes later.
 The objects can be unnamed, but you should name them if you want to
discriminate different objects of the same class.
Actors

Normally an actor instance occurs in the collaboration diagram, as the invoker of the
interaction. If you have several actor instances in the same diagram, try keeping them in the
periphery of the diagram.

 Each Actor is named and has a role

 One actor will be the initiator of the use case
Links

Links connect objects and actors and are instances of associations and each link corresponds
to an association in the class diagram

Links are defined as follows:

 A link is a relationship among objects across which messages can be sent. In

collaboration diagrams, a link is shown as a solid line between two objects.
 An object interacts with, or navigates to, other objects through its links to these
objects.
 A link can be an instance of an association, or it can be anonymous, meaning that
its association is unspecified.
 Message flows are attached to links, see Messages.
Messages

A message is a communication between objects that conveys information with the

expectation that activity will ensue. In collaboration diagrams, a message is shown as a
labeled arrow placed near a link.

 The message is directed from sender to receiver

 The receiver must understand the message
 The association must be navigable in that direction
COLLABRATION DIAGRAM FOR HOSTEL MANAGEMENT SYSTEM:

Result:
The collaboration Diagram was created successfully for Hostel Management system
Exp.no:10 CLASS DIAGRAM
Date:

Aim:
To draw the Class Diagram for Hostel Management System.

THEORY:
A class diagram is a type of static structure diagram that describes the structure of a system by
showing the system's classes, their attributes,and the relationships between the classes.

The UML Class diagram is a graphical notation used to construct and visualize object-oriented
systems. A class diagram in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's:

 classes,
 their attributes,
 operations (or methods),
 and the relationships among objects.

UML Class Notation

A class represent a concept which encapsulates state (attributes) and behavior (operations). Each

attribute has a type. Each operation has a signature. The class name is the only mandatory

information.

Class Name:
 The name of the class appears in the first partition.

Class Attributes:
 Attributes are shown in the second partition.
 The attribute type is shown after the colon.
 Attributes map onto member variables (data members) in code.

Class Operations (Methods):

 Operations are shown in the third partition. They are services the class provides.
  The return type of a method is shown after the colon at the end of the method signature.
 The return type of method parameters is shown after the colon following the parameter
name. Operations map onto class methods in code


Class Visibility

The +, - and # symbols before an attribute and operation name in a class denote the visibility of the

attribute and operation.

 + denotes public attributes or operations

 - denotes private attributes or operations
 # denotes protected attributes or operations

Parameter Directionality

Each parameter in an operation (method) may be denoted as in, out or inout which specifies its

direction with respect to the caller. This directionality is shown before the parameter name.
Perspectives of Class Diagram

The choice of perspective depends on how far along you are in the development process. During the

formulation of a domain model, for example, you would seldom move past the conceptual

perspective. Analysis models will typically feature a mix of conceptual and specification

perspectives. Design model development will typically start with heavy emphasis on

the specification perspective, and evolve into the implementation perspective.

A diagram can be interpreted from various perspectives:

 Conceptual: represents the concepts in the domain
 Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the software
 Implementation: describes how classes will implement their interfaces

The perspective affects the amount of detail to be supplied and the kinds of relationships worth

presenting. As we mentioned above, the class name is the only mandatory information.

Relationships between classes

UML is not just about pretty pictures. If used correctly, UML precisely conveys how code should be

implemented from diagrams. If precisely interpreted, the implemented code will correctly reflect the

intent of the designer. A class may be involved in one or more relationships with other classes. A

relationship can be one of the following types:

CLASS DIAGRAM FOR HOSTEL MANAGEMENT SYSTEM:

Result:
The Class Diagram was created successfully for Hostel Management system.
.