SCHOOL OF COMPUTING

DEPARTMENT OF SOFTWARE ENGINEERING,

INFORMATION TECHNOLOGY, COMPUTER SCIENCE
AND ENGINEERING
FACULTY OF ENGINEERING & TECHNOLOGY

MINI PROJECT REPORT

SUBJECT TITLE: OBJECT ORIENTED ANALYSIS AND DESIGN

SUBJECT CODE: 15SE203

PROJECT TITLE:-

SMART HOME AUTOMATION

TEAM MEMBERS:-

SHARAD KUMAR SINGH–RA1611003010564

PRAJJWAL PANDEY-RA1611003010460

SAMARTH SINGH - RA1611003010815

COMPUTER SCIENCE AND ENGINEERING

Acknowledgment
It is a great pleasure to present this report on the
project titled "Media content
classifier/Recommendation system undertaken by me
in Object Oriented Analysis and Design.
First and foremost, I would like to express my gratitude
towards Ms. P. Mahalakshmi for placing complete faith
and confidence in my ability to carry out this project
and for providing us time, inspiration, encouragement,
help, valuable guidance and constant interest. Without
the sincere and honest guidance of my respected
ma'am I would have not been able to reach the present
stage.
 List of Diagrams

S.No Diagram Name Page No

1 Use Case Diagram 4
2 Class Diagram 8
3 Sequential Diagram 11
4 Interaction Diagram 14
5 State Chart Diagram 18
6 Activity Diagram 21
7 Component Diagram 25
8 Deployment Diagram 28
9 Package Diagram 30
1.1 Introduction
1.1.1 Purpose

This document details the software requirements specification for the SMARTHOME project.

Home automation systems provide certain functionalities for variety of devices, but
many of them cannot extend their ability to respond technology which changes very
quickly. In order to achieve this, a generic set of functionality and support for various
home appliances needs to be generated. An easy to use, easy to deploy system with
an ability to learn and predict home owners’ and residents’ activities based on
previous knowledge will provide a more intelligent way of handling our homes.

SMARTHOME project is intended to serve this purpose and project details will be
provided in the following sections.

1.1.2 Document conventions

SMARTHOME project’s aims are currently not strictly defined. Many of the requirement
specifications and use cases provided in the version 1.0 of this document are merely a
starting point and will provide a perspective for the intended purpose of this project.

1.1.3 Intended audience and Reading Suggestions

This Software Requirements document is intended for:

− Developers who can review project’s capabilities and more easily understand
where their efforts should be targeted to improve or add more features to it.
− Project testers who can use this document as a base for their testing
strategy as some bugs are easier to find using a requirements document. This
way testing becomes more methodically organized.
− End users of this application who wish to read about what this project can do.

1.1.4 Project Scope

SMARTHOME is a simple but quite versatile home automation system which

consists of various connected subsystems.

Environment and device sensors

collection Wireless network
Coordinator Box
User Interface
As home appliances provide various data from their own work conditions and
status, sensor collection provided as a generic device analyzes the data and
sends it through wireless network to coordinator box.
Receiving the data through local wireless system, coordinator box collects and stores the data on an online
server. According to users’ choices or previous statistics, it can act as a smart agent to provide certain
reflexes in case of emergencies and possible threats.

All scenarios of actions and status information can be viewed through internet (web server) in which
statistical data are accumulated. As well as viewing, user can send orders to the coordinator box in order
to change home appliances’ activities in real time.
USE CASE DIAGRAMS
 USE CASE DIAGRAM

A use case diagram at its simplest is a representation of a user's interaction

with the system that shows the relationship between the user and the
different use cases in which the user is involved. A use case diagram can
identify the different types of users of a system and the different use cases
and will often be accompanied by other types of diagrams as well.

While a use case itself might drill into a lot of detail about every possibility, a
use-case diagram can help provide a higher-level view of the system. It has
been said before that "Use case diagrams are the blueprints for your
system".[1] They provide the simplified and graphical representation of what
the system must actually do.

Due to their simplistic nature, use case diagrams can be a good

communication tool for stakeholders. The drawings attempt to mimic the real
world and provide a view for the stakeholder to understand how the system is
going to be designed. Siau and Lee conducted research to determine if there
was a valid situation for use case diagrams at all or if they were unnecessary.
What was found was that the use case diagrams conveyed the intent of the
system in a more simplified manner to stakeholders and that they were
"interpreted more completely than class diagrams".[2]

The purpose of the use case diagrams is simply to provide the high-level view
of the system and convey the requirements in layman's terms for
the stakeholders. Additional diagrams and documentation can be used to
provide a complete functional and technical view of the system.
 Control

Scope For a home automation system

Pre-Condition The user should be logged in and the selected appliance should be present

Post-Condition The user is able to control the appliance

Order of Events - The user logs in.

- The user selects an appliance to be controlled
- The user controls the appliance

Restart

Scope For a home automation system

Pre-Condition The user is unable to control the appliance

Post-Condition The system restarts

Order of Events - The user logs in

- The user selects an appliance to control
- The system is unable to respond to the request

Operate

Scope For a home automation system

Pre-Condition The user successfully is able to control

Post-Condition The appliance is available

Order of Events - The user selects an appliance to control

- The system allows the user to control is

Operate microwave

Scope For a home automation system

Pre-Condition The user selects microwave

Post-Condition The user controls it

Order of Events The user selects the microwave option and controls it

Operate TV

Scope For a home automation system

Pre-Condition The user selects TV

Post-Condition The user control it

Order of Events The user selects the TV option and controls it

Operate Door

Scope For a home automation system

Pre-Condition The user selects Door

Post-Condition The user controls it

Order of Events The user selects the Door option

Emergency

Scope For a home automation system

Pre-Condition There is a fire or a break in attempt

Post-Condition The system stops it action.

Order of Events - Attempt to break in or fire

- System sends message

Stop Action

Scope For a home automation system

Pre-Condition There is a fire or a break in attempt

Post-Condition The system stops it action.

Order of Events - Attempt to break in or fire

- System prevents any further access to it until physically restarted
CLASS DIAGRAM
CLASS DIAGRAM
In software engineering, a class diagram in the Unified Modelling
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.

The class diagram is the main building block of object-oriented modelling. It is

used for general conceptual modelling of the systematic of the application,
and for detailed modelling translating the models into programming code.
Class diagrams can also be used for data modelling.[1] The classes in a class
diagram represent both the main elements, interactions in the application, and
the classes to be programmed.
In the diagram, classes are represented with boxes that contain three
compartments:

 The top compartment contains the name of the class. It is printed in bold
and cantered, and the first letter is capitalized.
 The middle compartment contains the attributes of the class. They are left-
aligned and the first letter is lowercase.
 The bottom compartment contains the operations the class can execute.
They are also left-aligned and the first letter is lowercase.
In the design of a system, many classes are identified and grouped together
in a class diagram that helps to determine the static relations between them.
With detailed modelling, the classes of the conceptual design are often split
into many subclasses.
SEQUENTIAL DIAGRAMS
SEQUENCE DIAGRAM
A sequence diagram is an interaction diagram that shows how
objects operate with one another and in what order. It is a
construct of a message sequence chart.
A sequence diagram shows object interactions arranged in time
sequence. It depicts the objects and classes involved in the scenario
and the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario. Sequence
diagrams are typically associated with use case realizations in the
Logical View of the system under development. Sequence diagrams
are sometimes called event diagrams or event scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines),
different processes or objects that live simultaneously, and, as
horizontal arrows, the messages exchanged between them, in the
order in which they occur. This allows the specification of simple
runtime scenarios in a graphical manner.
COLLABORATION DIAGRAM
COLLABORATION DIAGRAM
A collaboration diagram, also called a communication diagram or
interaction diagram, is an illustration of the relationships and
interactions among software objects in the Unified Modelling
Language (UML). The concept is more than a decade old although it
has been refined as modelling paradigms have evolved.

A collaboration diagram resembles a flowchart that portrays the

roles, functionality and behaviour of individual objects as well as
the overall operation of the system in real time. Objects are shown
as rectangles with naming labels inside. These labels are preceded
by colons and may be underlined. The relationships between the
objects are shown as lines connecting the rectangles. The messages
between objects are shown as arrows connecting the relevant
rectangles along with labels that define the message sequencing.

Collaboration diagrams are best suited to the portrayal of simple

interactions among relatively small numbers of objects. As the
number of objects and messages grows, a collaboration diagram can
become difficult to read. Several vendors offer software for creating
and editing collaboration diagrams.
ACTIVITY DIAGRAM
Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and
actions[1] with support for choice, iteration and concurrency. In the Unified Modelling
Language, activity diagrams are intended to model both computational and
organizational processes (i.e. workflows). Activity diagrams show the overall flow of
control.

Activity diagrams are constructed from a limited number of shapes, connected with
arrows.[4] The most important shape types:

 rounded rectangles represent actions;

 diamonds represent decisions;
 bars represent the start (split) or end (join) of concurrent activities;
 a black circle represents the start (initial node) of the workflow;
 an encircled black circle represents the end (final node).

Arrows run from the start towards the end and represent the order in which activities
happen.

Activity diagrams may be regarded as a form of flowchart. Typical flowchart techniques

lack constructs for expressing concurrency.[5]However, the join and split symbols in
activity diagrams only resolve this for simple cases; the meaning of the model is not clear
when they are arbitrarily combined with decisions or loops.
While in UML 1.x, activity diagrams were a specialized form of state diagrams, [6] in UML
2.x, the activity diagrams were renormalized to be based on Petri net-like semantics,
increasing the scope of situations that can be modelled using activity diagrams. These
changes cause many UML 1.x activity diagrams to be interpreted differently in UML 2.x.
UML activity diagrams in version 2.x can be used in various domains, e.g. in design of
embedded systems. It is possible to verify such a specification using model checking
technique.
STATECHART DIAGRAM
STATE CHART DIAGRAM

The name of the diagram itself clarifies the purpose of the diagram and other details.
It describes different states of a component in a system. The states are specific to a
component/object of a system.

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.

However, the main purpose is to model the reactive system.

Following are the main purposes of using State chart 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.

COMPONENT DIAGRAM
COMPONENT DIAGRAM

Component diagrams are different in terms of nature and

behaviour. Component diagrams are used to model the physical
aspects of a system. Now the question is, what are these physical
aspects? Physical aspects are the elements such as executables,
libraries, files, documents, etc. which reside in a node.
Component diagrams are used to visualize the organization and
relationships among components in a system. These diagrams are
also used to make executable systems.
Component diagram is a special kind of diagram in UML. The
purpose is also different from all other diagrams discussed so far. It
does not describe the functionality of the system but it describes
the components used to make those functionalities.
Thus from that point of view, component diagrams are used to
visualize the physical components in a system. These components
are libraries, packages, files, etc.
Component diagrams can also be described as a static
implementation view of a system. Static implementation represents
the organization of the components at a moment.
A single component diagram cannot represent the entire system but
a collection of diagrams is used to represent the whole.
DEPLOYMENT DIAGRAM
DEPLOYEMENT DIAGRAM
A deployment diagram in the Unified Modelling Language models
the physical deployment of artefacts on nodes. To describe a web site,
for example, a deployment diagram would show what hardware
components ("nodes") exist (e.g., a web server, an application server,
and a database server), what software components ("artefacts") run on
each node (e.g., web application, database), and how the different
pieces are connected (e.g. JDBC, REST, RMI).
The nodes appear as boxes, and the artefacts allocated to each node
appear as rectangles within the boxes. Nodes may have sub nodes,
which appear as nested boxes. A single node in a deployment diagram
may conceptually represent multiple physical nodes, such as a cluster of
database servers.

There are two types of Nodes:

Device Node
Execution Environment Node
Device nodes are physical computing resources with processing
memory and services to execute software, such as typical computers or
mobile phones. An execution environment node (EEN) is a software
computing resource that runs within an outer node and which itself
provides a service to host and execute other executable software
elements.
PACKAGE DIAGRAM
 PACKAGE DIAGRAM

Package diagram, a kind of structural diagram, shows the

arrangement and organization of model elements in middle to large
scale project. Package diagram can show both structure and
dependencies between sub-systems or modules, showing different
views of a system, for example, as multi-layered (aka multi-tiered)
application - multi-layered application model.
Package diagrams are used to structure high level system elements.
Packages are used for organizing large system which contains
diagrams, documents and other key deliverables.
 Package Diagram can be used to simplify complex class

diagrams, it can group classes into packages.

 A package is a collection of logically related UML elements.

 Packages are depicted as file folders and can be used on any of

the UML diagrams.

Package diagram is used to simplify complex class diagrams, you
can group classes into packages. A package is a collection of
logically related UML elements.
The diagram below is a business model in which the classes are
grouped into packages:
 Packages appear as rectangles with small tabs at the top.

 The package name is on the tab or inside the rectangle.

 The dotted arrows are dependencies.

 One package depends on another if changes in the other could

possibly force changes in the first.

 CONCLUSION

The project has proposed the idea of smart homes that

can support a lot of home automation systems. A smart
home contains a connection between wireless
communication, sensors, monitoring and tracking. Smart
homes are a huge system that includes multiple
technologies and applications that can be used to
provide security and control of the home easily.
Smart homes will one day be the way all homes are lived
in. This however will take time. Similar to the introduction
of electricity in the turn of the century, the smart home
business needs time to grow and mature before it
becomes main-stream. There are, however, many
benefits to owning a smart home due to the security and
convenience it can provide. As more and more items,
such as alarm systems, are introduced to the home, and
items begin to work together, the rise of smart homes is
definite.