Smarthouse - Paul Mc Kevitt · Jeopardy Game Application ... 11 User Interface Requirements ... The purpose of this chapter is to provide outline of the requirements that need to

Intelligent Multimedia

25/05/2010

Smarthouse An interactive multimodal application focusing

on possible domestic implementations

Scott Hulme, Anthony McLaughlin

Contents Introduction ............................................................................................................................................ 5

Aims and objectives ............................................................................................................................ 5

Rationale ............................................................................................................................................. 5

What is a Smart Home? ...................................................................................................................... 6

Literature review ..................................................................................................................................... 7

About the CLSU ................................................................................................................................... 7

Audio Tools ..................................................................................................................................... 7

Display Tools ................................................................................................................................... 8

Animated Avatars ............................................................................................................................ 8

Development Tools ............................................................................................................................. 9

Requirements Analysis .......................................................................................................................... 10

Introduction ...................................................................................................................................... 10

Similar Systems ................................................................................................................................. 10

Jeopardy Game Application .......................................................................................................... 10

Chameleon .................................................................................................................................... 10

What are Requirements .................................................................................................................... 10

Smart House Requirements .............................................................................................................. 11

Functional Requirements .............................................................................................................. 11

Non-Functional Requirements ...................................................................................................... 11

User Interface Requirements ........................................................................................................ 11

Hardware Requirements ............................................................................................................... 12

Software Requirements ................................................................................................................ 12

Methodology ..................................................................................................................................... 12

Waterfall ....................................................................................................................................... 12

Prototyping ................................................................................................................................... 13

Agile .............................................................................................................................................. 13

Project Methodology .................................................................................................................... 13

Design .................................................................................................................................................... 14

Introduction ...................................................................................................................................... 14

System Architecture .......................................................................................................................... 14

HCI ..................................................................................................................................................... 14

User Interface Layout ........................................................................................................................ 15

Layout 1 – Main Menu .................................................................................................................. 15

Layout 2 – Room Selection ............................................................................................................ 15

Layout 3 – Item Selection .............................................................................................................. 16

Database ........................................................................................................................................... 16

Use Case ............................................................................................................................................ 17

Activity Diagram ................................................................................................................................ 18

Implementation .................................................................................................................................... 19

Smart House Implementation ........................................................................................................... 20

Overall ........................................................................................................................................... 20

Initialise Subdialogue .................................................................................................................... 21

Kitchen Subdialogue ..................................................................................................................... 21

Living Room Subdialogue .............................................................................................................. 22

Study Subdialogue......................................................................................................................... 22

Bedroom Subdialogue ................................................................................................................... 23

Bathroom Subdialogue ................................................................................................................. 23

Entertainment Room Subdialogue ................................................................................................ 24

Lights Subdialogue ........................................................................................................................ 24

Temperature Subdialogue ............................................................................................................ 25

Cooker Subdialogue ...................................................................................................................... 25

TV Subdialogue ............................................................................................................................. 26

PC Subdialogue ............................................................................................................................. 26

Plumbed Fixtures Subdialogue...................................................................................................... 27

Testing ................................................................................................................................................... 28

Functional Testing ............................................................................................................................. 28

Performance Testing ......................................................................................................................... 28

System Testing .................................................................................................................................. 28

System Test 1 ................................................................................................................................ 28

System Test 1 Results .................................................................................................................... 29

System Test 2 ................................................................................................................................ 30

System Test 2 Results .................................................................................................................... 30

UI testing ........................................................................................................................................... 32

Summary ........................................................................................................................................... 32

Appendix 1 Object List .......................................................................................................................... 33

Main Section Object List ................................................................................................................... 33

Initialise Subdialogue Object List ...................................................................................................... 33

Kitchen Subdialogue Object List ....................................................................................................... 33

Living Room Subdialogue Object List ................................................................................................ 34

Study Subdialogue Object List .......................................................................................................... 34

Bedroom Subdialogue Object List ..................................................................................................... 34

Bathroom Subdialogue Object List ................................................................................................... 35

Entertainment Room Subdialogue Object List .................................................................................. 35

Lights Subdialogue Object List .......................................................................................................... 35

Temperature Subdialogue Object List .............................................................................................. 36

Cooker Subdialogue Object List ........................................................................................................ 37

TV Subdialogue Object List ............................................................................................................... 38

PC Subdialogue Object List ............................................................................................................... 40

Plumbed Fixtures Subdialogue Object List........................................................................................ 41

Introduction Moore’s law states that computers will continue to get small and more powerful with every year

that passes and Moore was right but he left out one key element. The way we interact with

computers also changes thanks to new and different software, hardware interfaces and Operating

Systems being released every year. This is all thanks to two different areas of research that work

closely together HCI – Human Computer Interaction and IntelliMedia, HCI deals with way computer

interfaces and software packages are designed and created, it also plays a key part in the

development of most computer research projects around the world. The area of IntelliMedia

operates to research and create new ways to make computers more interactive and productive.

As the computing world continues to grow so does the world of personal computing and social

interaction applications get better and better. As computers become more powerful each year

software developer companies have the chance to create even more powerful software applications

than they may have previously created.

In this group project we intend to explore the world of both HCI and IntelliMedia and product a

Smart Home application. To create this Smart Home application we intend to use the CLSU Toolkit

software to effectively create an interactive application with voice and picture output. By using the

CLSU Toolkit to complete this project the application will allow the user to interface simply using

their voice.

Aims and objectives No project can be successfully completed without preset Aims and Objectives which help steer any

project in the right direction. This project however aims to successfully create a working application

which will allow a user to interact with the software using only voice commands and answers. A

successful application will able to allow the user to control certain functions of the house and each

of the rooms inside.

To successfully complete this project we aim to successfully complete a working interactive

application which can also provide additional help for disabled people in their home. As also aim to

explore the areas of HCI and IntelliMedia and we believe that creating a working interactive Smart

Home would provide the more effective and efficient learning outcomes.

Rationale For this project we decided that we wanted to create an application that was not only useful but also

very original. Most of the example applications provided were games or educational related and

none of them really seemed to be useful other than the “Magee Campus Location Finder”

application but this wouldn’t be an application that could be used somewhere else outside of the

Magee campus setting.

For this project we decided that creating a Smart House application we would be able to create an

application that was not only original but also very practical. The application in question could also

be possibly released for public use which would make the application more user practicality sound.

We intend to aim this project towards people with disabilities that would greatly benefit them in

their home. As a result the application could improve their living standard and possibly reducing the

amount of external care they may require. This application is also aimed towards people who wish

to make their home more automated so that it will allow them to control aspects of their daily living.

What is a Smart Home? A smart home is a home or building that is equipped with technology to make living more

comfortable for the occupant [A1]. A smart home or building is also able to automatically control

certain aspects of the home or building which are normally set to the user’s preference. An example

of this would be a smart home being able to turn the lights on automatically without the user having

to turn or flip a switch. Most smart homes are able to control these features with users preset

parameters such as ‘only turn lights on if the light level get to a certain level’ or ‘turn lights on if a

person walks into the room after a certain time of the day’.

For this project we intend to build a smart home application that would take voice commands from

the user. This way we can make the home more interactive for the occupants and also give them the

control of an actual smart home. In the application we intend to make will include multiple rooms

which will have different features depending on the room, the features that the Smart home

application will employee will also be based on real home functions.

Also in the application the user will have the ability to control features in other rooms throughout

the house. The user will have the ability to interact with the application using only their voice, an

added advantage of the application is that the Smart Home application will also have a 3D avatar

which will add personality to the home making it easier for the user to relate to the application and

their home.

Some of the features of each room will also require the user to set or change the level or setting, this

level or setting will then be stored in a database which the Smart Home application will be able to

read. The next time the user goes to change said setting or level the Smart Home application will let

the user know the current value.

Literature review For this section we have provided an over view of the software used to create the Smart Home

application and the tools that are present within this software.

About the CLSU The CSLU toolkit software was developed in the Centre for Spoken Language Understanding in 1992

and has been growing ever since to meet the needs of its users. The CSLU Toolkit is essentially a

software library package which is made up of many different tools that was developed for “learning

and research into speech and human computer interaction”. [A2]

The CSLU Toolkit application is a Graphical User Interface (GUI) based programming software with

several different tools that help make this software and this project. The tools in which the CSLU

Toolkit has integrated include: Audio Tools, Display Tools, Animated Avatars and Development Tools.

Below I Explain each of the Tools and what they can be used for:

Audio Tools

The audio tools that the toolkit comprises of both Speech Recognition and synthesis, the toolkit then

using both of these to effectively create a unique software package that gives the user the ability to

explore the world of HCI and IntelliMedia all in one package.

The toolkit utilises its ability to use Speech Recognition, which is the ability to understand a user’s

spoken commands and responses. This is the most important tool of the Toolkit as it effectively

allows the user to interact with the application.

Speech Synthesis is another tool which the Toolkit utilises, this tool however has the ability to

convert written text based input. The process of Text to Speech conversion is also another very

important tool that is incorporated into the toolkit which makes use of a large library of recorded

phonics spoken by both genders. [A3]

Fig.1

Fig.1 Sounds and example of how the Speech Recognizer understands language, as you can see the

words are broken down in to set groups of phonics. You may also notice that not every word will

have the next expected letter, this is because each symbol or letter that makes up the broken down

word is pre-programmed into the toolkit as a certain sound. There are not enough letters on a

keyboard to reference all of the sounds so symbols are also used to achieve the brake down

Display Tools

The CSLU Toolkit application allows the user to make useful applications using a GUI control system

that the user can simple drag and drop the required features to complete their application. Part of

these features is the ability to place an image map on the users display. Using this image map

feature provide the creator with the ability to create applications that can have speech and input

based inputs. [A2]

Animated Avatars

One of the best parts of using the CSLU toolkit is the on screen 3D talking Avatar. Any application

that is created using the toolkit will have the 3D avatar available on the screen, any of the outputted

speech which is provided for the users benefit especially for explanation purposes, the avatar will

move its mouth to mimic the way a human mouth would move when a person is speaking. Having

the avatar built into the system can give any application created with the toolkit can make the

application feel more interactive and give the application a more human interface.

blue {bc b l u}

Red {9r E dc d}

Green {gc g 9r i: n}

Yellow {j E l oU}

Orange {> 9r & n dZc dZ}

Black {bc b l @ kc kh}

White {[h] w aI tc th}

Development Tools The main development tool provided in the Toolkit is the Rapid Application Developer (RAD) which

provides the user with the GUI drag and drop system which is used to create most of the

applications. The RAD tool is a fast and very easy way to create applications which involves very little

to no programming for the user depending on the size and type of the application they intend to

create. Below I have included an image which shows the RAD tool in use. (Fig.2 – [A2])

Fig.2

Tool palette

Define Activities by placing objects on the canvas

Assign sequence of activities with arrows

Canvas

Requirements Analysis

Introduction The purpose of this chapter is to provide outline of the requirements that need to be met when

designing and implementing the project. Firstly this chapter will look at other systems which exist in

the software based smart house domain. The chapter will then move on to look into what exactly is

meant by requirements and the different types of requires. This is then followed by a section which

outlines the actual requires of the smart house application. Finally this section looks into software

development methodologies and describes why the agile methodology is the best fit for this

particular project.

Similar Systems The following section looks at examples of other intelligent multimedia applications which have

been developed using the CSLU toolkit.

Jeopardy Game Application

The paper by Michael Mc Tear was a CSLU created application inspired by the American TV show

game Jeopardy in which the host gives the answer and the player much guess the question. Mc Tear

created the application using CSLU and utilises many of the RAD features found on the Tool Palette

that can be seen in Fig.2.

Chameleon

Although this project doesn’t use the CLSU toolkit directly the project does provide a speech input

and output like the Jeopardy application and the application that this project intends to create. The

Chameleon system utilises not only speech input but also makes use of gesture input and laser

based location output. The system was designed to provide users the ability to locate their current

position and find routes and locations of other people and offices.

What are Requirements System requirements simply put are a list of essential components which need to be present on the

computer in order for a system to work efficiently. In this case the system is the smart house

application. Many different categories of system requirements exist and each focus on a particular

part of a system.

Function Requirements – refers to functionality which a particular system should exhibit. This

functionality can be the inputs, outputs and general behaviour of the desired system. Functional

requirements can refer to behaviour that the application should exhibit and also behaviour that it

should not exhibit.

Non-Functional Requirements – unlike functional requirements which are usually either met or not

met, a non-functional requirement is some which can be measured. Functional requirements are

generally broken down into 5 main categories, including, usability, reliability, scalability, security and

interoperability.

User Interface Requirements – refers directly to requirements regarding any interface within the

system which is intended for use by a system user. These kinds of requirements refer to aspects like

the colour schemes, layout, fonts, ease of use etc.

Hardware Requirements – refers directly to the hardware which comprises the machine which is

being used to host the application. Aspects generally taken into consideration here are the

computers CPU, HDD space, RAM available and any other critical components required.

Software Requirements – refers to the software prerequisites which need to exist on the host

machine in order to provide full functionality of the system. An example of this would be, a Java

based application requires that some form of Java is install on the system, usually a compatible JRE

but normally a JDK would suffice.

Smart House Requirements The following section looks at the functional, non-functional, user interface, hardware and software

requirements of the smart house application.

Functional Requirements

See appendix for detailed use case specifications

FR1: The system should allow a user to manipulate household elements using speech transactions.

FR2: The system should store the state of each of the household elements in a back end data source.

FR3: The system should where appropriate accept multiple keywords to use execute the same

functionality. For example when the system asks for a room name a user should be able to say

‘Study’ and ‘Office’ to achieve the end result.

FR4: The system should readily accept both speech and mouse clicking gestures as valid input

methods.

FR5: All interfaces used within the system should be consistent in terms of layout, size and display

position.

Non-Functional Requirements

NFR1: The system should be developed in a modular fashion in order to aid reusability and the

overall extensibility of the application.

NFR2: The system should be easily modified in order to add/remove components in order to suit

another homes layout.

NFR3: The system should be usable by anyone with basic speech and dexterity abilities.

NFR4: The system should run smoothly without pauses or breaks in order to give the users a more

pleasurable experience.

User Interface Requirements

UI should be intuitive

Valid user input should be obvious

Images should be clear and not cluttered

Fonts should be easily read

Error messages should be informative

Colour scheme should be pleasing to the eye

Hardware Requirements

A computer with the following recommended requirements:

CPU - >200MHz

Free HDD Space – 700MB

RAM – 128Mb

Video card with Open GL

Additional Audio peripherals requirements:

Audio Out – Speakers

Audio In – Noise Cancelling Microphone

Software Requirements

The following software is required on the computer:

Operating System – Windows XP

CSLU Toolkit

Microsoft Access

GIMP (GNU Image Manipulation Program)

Methodology There are a number of development methodologies that can be used to develop a speech based

application, these include:

Waterfall

The waterfall methodology involves a

phased progression of activities which

ultimately leads to the release of a piece of

software. The phases involved are,

Planning, Analysis, Design and

Implementation. The planning phase

investigates into why the system should be

built, identifying feasibility and business

value. The analysis phase looks into

information gathering, process and data

modelling. The design stage is where designs for the architectures, interfaces, databases and the

general program are developed. The implementation stage involves the construction and installation

of the system. The waterfall method best when all system functionality and requirements can be laid

out early in development.

Prototyping

Prototyping is another commonly used software development methodology. This methodology

again involves the planning, analysis, design and implementation stages, however each is utilised in a

different order than seen in the waterfall.

In the prototyping methodology an initial

phase of planning is carried out. After this

planning, Analysis, Design and

Implementation of system prototypes is

carried out concurrently. Once the system

prototype has been completed the process

loops back around to the Analysis, Design

and Implementation stages, keeping the

best parts from the current prototype and

building on top of them. Once the prototype illustrates all desired functionality the prototype is

implemented as the final system. This approach works best when a piece of software can be

developed in modules.

Agile

The Agile methodology is the process of developing a piece

of software, by splitting up the functionality into modules

and developing each module within separate timeframes

called sprints. For example sprint 1 may be to get the base

of a system up and running, sprint 2 may be to add some

extra functionality. Each sprint will run through the process

of development, internal testing, development, client

testing and then the modules is either signed off if

completed or runs through the process again until it is

complete. This process continues for every module. This

methodology is best used in situations where functionality,

requirements or system architecture may change

throughout the development process.

Project Methodology

This project will be using the agile development methodology as its chosen methodology. The reason

behind this is because the functional requirements have been laid down early in the development

cycle, however due to the development team’s limited knowledge of the CSLU toolkit some

functionality may need to be altered. The agile development process allows for the occurrence of

such events and therefore is the best methodology available for the situation.

Design

Introduction This section looks into the action design of the smart house application. The initial section looks at

the system stack. This then moves onto the HCI and the UI intended to be used throughout the

project. The next section goes onto look at use case diagrams and activity diagrams which into the

tasks which the user can perform and also the execution flow of the application.

System Architecture The following diagram illustrates the architecture of the smart house application in a system stack

format.

The user will initially be prompted with an image and text asking them to select an option via an

image output and speech synthesiser. The system will then wait for the user’s speech input which is

picked up and processed by the speech recogniser. The recognised speech will then trigger a specific

action to occur according to the available paths of execute. Commands that involve data access or

variable getting and setting are performed using TCL. If TCL requires to query the database it

establishes communication via the ODBC connector. The Access database will respond any incoming

queries.

HCI In general there are 8 main HCI development guidelines in regard to application UI. These include,

consistency, compatibility, flexibility and control, structure, error handling, continuous feedback,

clarity and user support.

The smart house application will include a consistent UI as floor plans will all be created in the same

format using the same labelling for user input options. The UI will also control the users input, as

they will only be able to input values which have been pre approved. This will also help prevent

Smart House Application

ODBC

CLSU Toolkit CU Animate

TCL

Microsoft Access Database

Speech Recogniser Speech

Synthesiser

Image Output

errors that may occur if dynamic data were allowed to be entered into the database. All the UIs used

within the application are clear and large enough to be made out by most people.

User Interface Layout This section looks into the general layout that is used for the smart house’s user interface. The

interface will remain consistent throughout the entire application as this helps users to operate the

system more smoothly and increases a user’s comfort levels with the system. There will be three

main layouts implemented in the system. The first layout is used for the basic main menu and will

consist of an image component and also a CU Animated avatar window. The second layout will be

used during room selection and once again will have 2 components, a floor plan image and a CU

Animate avatar window. The final view will be used for all other scenarios and will generally consist

of between 2 – 3 components. The first component will be an image of a room, the second will be

the selected item within the room and the third will be the CU Animated avatar.

Layout 1 – Main Menu

Layout 2 – Room Selection

CU Animate Avatar

Image of Floor Layout

First Floor

Second Floor

Exit

Main Menu and

available options

CU Animate Avatar

Layout 3 – Item Selection

Database It is very important that the smart house application is able to save state, as this adds to the realism

of the scenario. A Microsoft Database and the Access DBMS were used to create and perform initial

data entry. The advantages of using a database include:

Data redundancy could be minimised as much as possible, however this was minimal in this case

as the application deals with a number of entities which all contain differing attributes.

Database consistency means that attributes will either be change or not, which means in the

event of a crash an attribute will not remain in a limbo state and continuously crash the system.

State can be maintained between reboots as the database is stored on the non-volatile HDD

storage medium, rather than simple variables which get flushed when power is cut.

Using the database as a storage medium also allows for an extra level of abstraction to be

attained and thus making dynamic data easier to maintain as it is separate from the actually

application.

CU Animate

Avatar

Image of selected item

Image of Room Layout

Use Case

Activity Diagram

Implementation

Start Object

The start object is used to tell the application where the entry point is. This is much like the main method a standard application. There is only one start point in any application.

Generic Object

The generic object is used for a number of functions. The first function is to provide the speech synthesiser with

Media Object

The media object is used to output media to the user. This can be in the form of text, an image, an image map or even sound.

Action Object

The action object is used for a number of reasons in the smart house application. It was used for creating, setting and getting variables. Another use for this object is to establish a link with the backend database. Finally it is also used to populate an array list of variables which comprised of database query results.

Login Object

The login object is used by the user to log into the application and have the user variable set to reflect the current user’s name. This allows the application to refer to the user by name.

Conditional Object

The conditional object is used as a method of flow control, where each branch has a different Boolean expression statement.

Subdialogue Object

The subdialogue object is used for two main reasons. The first is to modularise code to increase its usability. The second is it allows for the general clean up of the workspace as it can quickly become cluttered and unsightly.

Exit Object

The exit object is used to exit the flow of a Subdialogue and resume flow of the main system.

Stop Object

The stop object is used as a marker for the end of the problem. Execute will finish once this object has been hit.

Smart House Implementation

Overall

This diagram shows the overall system design. Here we see the user can select a floor, hear

information regarding the project or exit the application.

Initialise Subdialogue

The initialise subdialogue firstly connects with the data source, asks the user to login, and then plays

the welcome message.

Kitchen Subdialogue

The kitchen subdialogue allows the user to select any of the available items which are available in

the kitchen.

Living Room Subdialogue

The living room subdialogue allows the user to select any of the available items which are available

in the living room.

Study Subdialogue

The study subdialogue allows the user to select any of the available items which are available in the

study.

Bedroom Subdialogue

The bedroom subdialogue allows the user to select any of the available items which are available in

the bedroom.

Bathroom Subdialogue

The bathroom subdialogue allows the user to select any of the available items which are available in

the bathroom.

Entertainment Room Subdialogue

The entertainment room subdialogue allows the user to select any of the available items which are

available in the entertainment room.

Lights Subdialogue

The lights subdialogue allows users to manipulate the state of the lights in any of the rooms within

the house.

Temperature Subdialogue

The temperature subdialogue allows users to manipulate the temperature in any of the rooms in the

house.

Cooker Subdialogue

The cooker subdialogue allows the user to work with any of the items available on the cooker,

including the power, rings and oven.

TV Subdialogue

The TV subdialogue allows the user to manipulate the attributes available on the television, these

include the power, channel and volume.

PC Subdialogue

The PC subdialogue allows the user to manipulate the attributes available on the PC, these include

the power and operating system.

Plumbed Fixtures Subdialogue

The plumbed fixture subdialogue allows the user to manipulate the state and temperature of any of

the plumbed fixtures available within the house.

Testing

Functional Testing Functional testing investigates whether the application is meeting the functional requirements

which were set during the requirements phase of the project development life cycle. The following

section outlines the functional requirements outlined in the requirements section of the smart

house application and tests whether these function where met or not.

Functional Requirement Result

FR1: The system should allow a user to manipulate household elements using speech transactions.

Pass

FR2: The system should store the state of each of the household elements in a back end data source.

Pass

FR3: The system should where appropriate accept multiple keywords to use execute the same functionality. For example when the system asks for a room name a user should be able to say ‘Study’ and ‘Office’ to achieve the end result.

Pass

FR4: The system should readily accept both speech and mouse clicking gestures as valid input methods.

Pass

FR5: All interfaces used within the system should be consistent in terms of layout, size and display position.

Pass

Performance Testing The performance testing sections looks whether or not the non-functional requirements of the

smart house application were met. The following section outlines the non-functional requirements

and determines whether they passed or failed.

Functional Requirement Result

NFR1: The system should be developed in a modular fashion in order to aid reusability and the overall extensibility of the application.

Pass

NFR2: The system should be easily modified in order to add/remove components in order to suit another homes layout.

Pass

NFR3: The system should be usable by anyone with basic speech and dexterity abilities.

Pass

NFR4: The system should run smoothly without pauses or breaks in order to give the users a more pleasurable experience. The system on occasion pauses for a number of seconds when retrieving a number of fields from the database.

Fail

System Testing A number of test cases have been drawn up to test that the application is working as expected.

These test cases involve running through behaviour that the system should be able to deal with.

System Test 1

This test will see a user login, proceed to the living room and switch the TV and change the channel

to BBC2.

Step 1: Launch Application

Step 2: Login System

Step 3: Select First Floor

Step 4: Select Living Room

Step 5: Select TV

Step 6: Turn on TV

Step 7: Change Channel to BBC2

System Test 1 Results


Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

Step 7:

System Test 2

This test will see the user enter the kitchen and turn on the cookers left ring to a high setting.


Step 2: Login

Step 3: Select First Floor

Step 4: Select Kitchen

Step 5: Select Cooker

Step 6: Select Left Ring

Step 7: Select High Temperature

System Test 2 Results

Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

Step 7:

UI testing This testing was carried out by asking volunteers to run through the system and perform certain

tasks. Excluding some initial problem with speech recognition the users were able to launch and

begin using the application almost immediately.

Summary This chapter has tested the systems functional and non-functional requirement by running tests

against each requirement. The application has performed well and passes on all but the smooth

running of the application when reading from a data source. Sadly there will be a performance hit

when having to establish a connection and retrieve results from a backend database.

Appendix 1 Object List

Main Section Object List

Object Name Type Purpose TCL

Display main menu Media Opens the main menu image.

Select Floor Generic Allows users to select a floor, hear the about section or exit the application.

About Generic Informs the user about the system.

Goodbye Stop Stops execution of the application.

Display first floor Media Opens the image of the first floor plan.

Select room 1fl Generic Allows the user to select a room, go upstairs or exit the application.

Display second floor Media Opens the image of the second floor plan

Select room 2fl Generic Allows the user to select a room, go downstairs or exit the application.

Initialise Subdialogue Object List


Datasource connect Action Establishes a connection with the backend database via the TCLODBC package

cd "E:/smarthouse/datasource/" package require tclodbc database db smarthouse

System login Login Allows the user to login and sets the user variable. User names are pulled from a text list.

Welcome Generic Welcomes the user to the system

Kitchen Subdialogue Object List


Display kitchen Media Displays the kitchen floor plan image to the user.

Set kitchen Action Sets the room variable to kitchen

set room "Kitchen"

Kitchen options Generic Allows the user to select an item to focus on, or go back to previous

page.

Set kitchen lights Action Sets item variable to Lights

set item "Lights"

Set kitchen basin Action Sets fixture variable to Basin

set fixture "Basin"

Living Room Subdialogue Object List


Display living room Media Displays the living room floor plan image to the user.

Set living room Action Sets the room variable to living room

set room "LivingRoom"

Living room options Generic Allows the user to select an item to focus on or go back to the previous page.

Set living room lights Action Sets the item variable to Lights

set item "Lights"

Study Subdialogue Object List


Display study Media Displays the study floor plan to the user

Set study Action Sets the room variable to the study

set room "Study"

Study Options Generic Allows the user to select an item to focus on or go back to the previous menu

Set study lights Action Sets the item variable to Lights

set item "Lights"

Bedroom Subdialogue Object List


Display bedroom Media Displays the bedroom floor plan to the user

Set bedroom Action Sets the room variable to the bedroom

set room "Bedroom"

Bedroom options Generic Allows the user to select an item to focus on or go back to the previous menu

Set bedroom lights Action Sets the item variable to Lights

set item "Lights"

Bathroom Subdialogue Object List


Display bathroom Media Displays the bathroom floor plan to the user

Set bathroom Action Sets the room variable to the bathroom

set room "Bathroom"

Bathroom options Generic Allows the user to select an item to focus on or go back to the previous menu

Set bathroom lights Action Sets the item variable to Lights

set item "Lights"

Set bath Action Sets the fixture variable to Bath

set fixture "Bath"

Set shower Action Sets the fixture variable to Shower

set fixture "Shower"

Set bathroom basin Action Sets the fixture variable to Basin

set fixture "Basin"

Entertainment Room Subdialogue Object List


Display entertainment room

Media Displays the floor plan of the entertainment room to the user

Set entertainment room

Action Sets the room variable to Entertainment room

set room "EntertainmentRoom"

Entertainment Room options

Generic Allows the user to select an item to focus on or go back to the previous page.

Lights Subdialogue Object List


Get current state Action Used to pull the current state of the lights from the database

set currentState [db "select $item from Common where Room = '$room'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set state [lindex $currentState 0]

Current state Conditional Used to control the flow of the application depending on the lights state

On Generic Informs the user that

the lights are current on and would they like to switch them off

Turn off Action Updates the lights state in the database to off

db "update Common set $item = 'Off' where Room = '$room'"

Off Generic Informs the user that the lights are currently off and asks would they like to switch them on

Turn on Action Updates the lights state in the database to on

db "update Common set $item = 'On' where Room = '$room'"

Change state Action Is used to update the state variable to reflect any changes


Temperature Subdialogue Object List


Set temperature Action Sets the item variable to temperature

set item "Temperature"

Get current temp Action Gets the current temperature for the room


Current temp Generic Informs the user of the current temperature and asks the user whether they would like to change it

Get new temp Generic Asks the user for new temperature and provides the possibilities between 0 and 70 degrees.

$temp = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 ...

Set new temp Action Updates the database with the new temperature

set newTemp [lindex $get_new_temp(recog) 0] db "update Common set

Temperature = $newTemp where Room = '$room'"

Cooker Subdialogue Object List


Get cooker state Action Gets the current state of the cooker from the database

set currentState [db "select Power from Cooker where Room = '$room'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set state [lindex $currentState 0]

Cooker state Conditional Controls the flow of execution depending on the cookers state

Turn cooker on Generic If the cooker is off, the user needs to turn it on before it can be used.

Turn on Action Updates the cookers state in the database to on

db "update Cooker set Power = 'On' where Room = '$room'"

Get properties Action Gets the current state of all attributes of the cooker from the database

set currentState [db "select Power, Ring1Setting, Ring2Setting, OvenSetting from Cooker where Room = '$room'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set state [lindex $currentState 0] set ring1s [lindex $currentState 1] set ring2s [lindex $currentState 2] set oven1s [lindex $currentState 3]

Select an option Generic Allows the user to select an item to focus on or to turn the cooker off

Set ring1 Action Sets the item variable to ring 1

set item "Ring1Setting"

Set ring2 Action Sets the item variable to ring 2

set item "Ring2Setting"

Set oven Action Sets the item variable to oven

set item "OvenSetting"

Turn off Action Updates the cookers state and other attributes in the database to Off

db "update Cooker set Power = 'Off' where Room = '$room'" db "update Cooker set Ring1Setting = 'Off' where Room = '$room'" db "update Cooker set Ring2Setting = 'Off' where Room = '$room'" db "update Cooker set OvenSetting = 'Off' where Room = '$room'"

New setting Generic Asks the user what new setting should be used for the item. The user has 4 choices.

$setting = Off | Low | Medium | High;

Set new state Action Updates the attribute in the database with the new state.

set newSetting [lindex $new_setting(recog) 0] db "update Cooker set $item = '$newSetting' where Room = '$room'"

TV Subdialogue Object List


Get TV state Action Gets the initial state of the TV

set currentState [db "select Power from TV where Room = '$room'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set state [lindex $currentState 0]

TV state Conditional Controls the flow of execution depending on whether the TV is On or Off

Display tv off Media Displays the TV off image

Turn TV on Generic Asks the user whether they would like to turn the TV on

Turn on Action Updates the state of the TV in the database to ON

db "update TV set Power = 'On' where Room = '$room'"

Get properties Action Gets all of the attributes for the TV from the database

set currentState [db "select Power, Channel, Volume from TV where Room =

'$room'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set state [lindex $currentState 0] set channel [lindex $currentState 1] set volume [lindex $currentState 2]

Select TV image Conditional Controls the flow of execution and decides which image file should be loaded depending on the TV channel

Bbc1, bbc2, utv, channel 4, channel 5, RTE1 and RTE2

Media Loads the specific image for each of the channels

Select an option Generic Allows the user to select new channels, volumes, turn the TV off or go back

New volume Generic Asks the user what the volume should be set to. This accepts a value between 0 – 100

$vol = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | ...

Set new volume Action Updates the database to reflect changes made to volume

set newVolume [lindex $new_volume(recog) 0] db "update TV set Volume = $newVolume where Room = '$room'"

New channel Generic Asks the user which channel they would like to turn the TV to. This accepts predefined channels

$channel = BBC1 | BBC2 | UTV | Channel4 | Channel5 | RTE1 | RTE2;

Set new channel Action Updates the database to reflect changes made to the channel

set newChannel [lindex $new_channel(recog) 0] db "update TV set Channel = '$newChannel' where Room = '$room'"

Turn off Action Updates the TVs status in the database to Off

db "update TV set Power = 'Off' where Room = '$room'"

PC Subdialogue Object List


Get state Action Gets the current state of the TV

set currentState [db "select State from PC where Room = '$room'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set state [lindex $currentState 0]

Current state Conditional Controls the flow of execution depending on the PCs state

Turn on? Generic Asks whether the user wishes to switch the computer on or not.

Turn on Action Updates the PCs state in the database to On

db "update PC set State = 'On' where Room = '$room'"

Operating system Generic Asks the user which operating system they would like to use. This accepts 2 values

$os = Windows | Ubuntu;

Set OS Action Updates the database with the chosen operating system

set os [lindex $operating_system(recog) 0] db "update PC set OperatingSystem = '$os' where Room = '$room'"

Get properties Action Gets all the current attributes for the PC from the database

set currentState [db "select State, OperatingSystem from PC where Room = '$room'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set state [lindex $currentState 0] set os [lindex $currentState 1]

Set image Conditional Controls the flow of execution depending on the operating system chosen

Ubuntu, windows Media Displays the desktop image of whichever system is picked

Options Generic Allows the user to turn the PC off again or go back

Turn off Action Updates the database

to reflect that the PC has been turned off

Plumbed Fixtures Subdialogue Object List


Get current state Action Gets the current state of the fixture

set currentState [db "select WaterState from PlumbedFixture where Room = '$room' AND Fixture = '$fixture'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set waterState [lindex $currentState 0]

Current state Conditional Controls the flow of execution depending on the fixtures state

Turn on Generic Asks the user whether or not they want to turn the fixture on

Turn on Action Updates the database to reflect that the fixture has been turned on

db "update PlumbedFixture set WaterState = 'On' where Room = '$room' AND Fixture = '$fixture'"

Get properties Action Gets all the properties available for the fixture

set currentState [db "select WaterState, WaterTemperature from PlumbedFixture where Room = '$room' AND Fixture = '$fixture'"] regsub {\{} $currentState {} currentState regsub {\}} $currentState {} currentState set waterState [lindex $currentState 0] set waterTemp [lindex $currentState 1]

Fixture options Generic Allows the user to select and focus on an item of the fixture

Get new temp Generic Asks the user for a new temperature. This can be a value between 0 and 60.

$temp = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | ...

Set new temp Action Updates the database to reflect the changes

set newTemp [lindex $get_new_temp(recog) 0]

that have been made db "update PlumbedFixture set WaterTemperature = $newTemp where Room = '$room' AND Fixture = '$fixture'"

Turn off Action Updates the database to reflect that the fixtures state has been changed to Off

db "update PlumbedFixture set WaterState = 'Off' where Room = '$room' AND Fixture = '$fixture'"

Empty Generic Informs the user that the water is draining from the fixture

Warning Generic Warns the user that they are about to leave the room while water is running

Documents

Smarthouse - Paul Mc Kevitt · Jeopardy Game Application ... 11 User Interface Requirements ... The purpose of this chapter is to provide outline of the requirements that need to