Sie sind auf Seite 1von 9

October 18

USE-Cases
2009
Use Case analysis for developing Interactive Dashboards for a Assignment 2
Greener Built environment. Terry Fernandez
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

Contents
1 Use-Case Identification & Prioritization .................................................................... 3
1.1 Use-case name: UC1: Dashboard to visualize Electrical usage ........................... 3
1.1.1 Actor Brief Descriptions ............................................................................... 3
1.1.2 Event Flow .................................................................................................... 3
1.1.3 Priority Rationale .......................................................................................... 3
1.2 Use-case name: UC2: Dashboard to interact and modify Electrical usage .......... 3
1.2.1 Actor Brief Descriptions ............................................................................... 3
1.2.2 Event Flow .................................................................................................... 4
1.2.3 Priority Rationale .......................................................................................... 4
2 Use-Case Diagrams ..................................................................................................... 5
3 Use-Case: UC1: Dashboard to visualize Electrical usage .......................................... 7
3.1 Brief Description .................................................................................................. 7
3.2 Actor Brief Descriptions ...................................................................................... 7
3.3 Actor 1: Joe Smith (JS) ........................................................................................ 7
3.4 Actor 2: Program 1 - Data mining algorithm (DM) ............................................. 7
3.5 Actor 3: Program 2 – Sensor (SR) ....................................................................... 7
3.6 Trigger .................................................................................................................. 7
3.7 Preconditions ........................................................................................................ 7
3.8 Incoming Information (optional).......................................................................... 7
3.9 Event Flow ........................................................................................................... 7
3.10 Alternate Event Flows ...................................................................................... 7
3.11 Alternate flow 1 ................................................................................................ 8
3.12 Results .............................................................................................................. 8
3.13 Post conditions.................................................................................................. 8
3.14 Post-condition 1 ................................................................................................ 8
4 Use-Case: UC2: Dashboard to interact and modify Electrical usage ......................... 8
4.1 Brief Description .................................................................................................. 8
4.2 Actor Brief Descriptions ...................................................................................... 8
4.3 Actor 1: Joe Smith (JS) ........................................................................................ 8
4.4 Actor 2: Program 1 - Data mining algorithm (DM) ............................................. 8
4.5 Actor 3: Program 2 – Sensor (SR) ....................................................................... 8
4.6 Actor 4: Appliances (APL) .................................................................................. 8
4.7 Trigger .................................................................................................................. 8
4.8 Preconditions ........................................................................................................ 8
4.9 Incoming Information (optional).......................................................................... 8
4.10 Event Flow ........................................................................................................ 9
4.11 Alternate Event Flows ...................................................................................... 9
4.12 Alternate flow 1 ................................................................................................ 9
4.13 Results .............................................................................................................. 9
4.14 Post conditions.................................................................................................. 9
4.15 Post-condition 1 ................................................................................................ 9
4.16 Post-condition 2 ................................................................................................ 9

Page 2 of 9
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

1 Use-Case Identification & Prioritization


1.1 Use-case name: UC1: Dashboard to visualize Electrical usage
1.1.1 Actor Brief Descriptions
Actor 1: Joe Smith. Active member of a household could be a parent or an adult (JS)

Actor 2: Program 1. Data mining computer algorithm that gathers data from external research
Repositories and compares it to the usage in the household and makes intelligent suggestions.
(DM)

Actor 3: Program 2. Sensor - “State” storing computer algorithm takes input from Actor 1 and
Actor 2 and develops a baseline based on automated discovery of appliances, input from Actor 1
and data gathered through Actor 2. (SR)

1.1.2 Event Flow


1. Use case begins when Actor 1 - JS, decides to monitor electrical usage with the intent
making incremental improvements in energy use. The first step in the process is
establishing a baseline.
2. Flow step 1. Actor 1 - JS requests Actor 3 SR to start storing state of current usage based
on discovery, input from the other Actors.
3. Flow step 2. Actor 1 - JS requests a baseline of usage from Actor 3 - SR
4. Flow step 3. Actor 3 - SR invokes data collection algorithm - an automated discovery
process for a predetermined amount of time.
5. Flow step 4. Actor 3 - SR invokes Actor 2 - DM to collect usage and efficiency data from
external repositories.
6. Flow step 5. Actor 3 - SR requests Actor 1 - JS to validate data on discovered devices and
add/modify appliances and functional groupings.
7. Flow step 6. Actor 3 - SR generates a preliminary validated baseline and displays it
8. Flow step 7. Actor 1 - JS accepts the initial baseline
9. Use case ends when Actor 3 - SR displays the accepted baseline with the current usage
overlay.
1.1.3 Priority Rationale
A baseline is the starting point. It is the first step in the process of incremental improvement. The
primary goal for Use-case 1 is to establish a baseline of electrical usage from an automated
discovery of appliances, data collection from various external sources on appropriate and efficient
usage and human input/override.

1.2 Use-case name: UC2: Dashboard to interact and modify Electrical usage
1.2.1 Actor Brief Descriptions
Actor 1: Joe Smith. Active member of a household could be a parent or an adult (JS).

Actor 2: Program 1. Data mining computer algorithm that gathers data from external research

Page 3 of 9
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

Repositories and compares it to the usage in the household and makes intelligent suggestions
(DM).

Actor 3: Program 2. Sensor - “State” storing computer algorithm takes input from Actor 1 and
Actor 2 and interacts with appliances individually or on the functional groups created with the
intent to improve efficiency of usage (SR).

Actor 4: Appliances (APL) – These are end devices and includes any electrical appliance that
consumes power in the domain of interaction

1.2.2 Event Flow


1. Use case begins when Actor 1 - JS, decides to interact with current electrical usage with
the intent making incremental improvements in energy use. The interaction is based on
suggested improvements from Actor 3 – SR who in turn interacts with Actor 2 – DM and
Actor 4 - APL. The first step in the process is modifying usage of individual or grouping
of appliances.
2. Flow step 1. Actor 3 – SR provides suggestions of interaction to Actor 1 JS, to modify
current usage of appliances or groupings of appliances
3. Flow step 2. Actor 1 – JS validates the actions are acceptable
4. Flow step 3. Actor 3 - SR interacts with Actor 4 – APL consisting of appliances or
groupings of appliances to modify pattern of usage based on the validation provided by
Actor 1 - JS.
10. Use case ends when Actor 3 - SR displays the new baseline with the revised usage
overlay.
1.2.3 Priority Rationale
To achieve incremental improvements, it is necessary to invoke a iterative process, where the
feedback loop is engaged, based on which changes are implemented to achieve a desired level of
efficiency.

Page 4 of 9
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

2 Use-Case Diagrams
1. UC1: Dashboard to visualize Electrical Energy

Page 5 of 9
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

2. UC2: Dashboard to interact and Modify Electrical usage.

Page 6 of 9
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

3 Use-Case: UC1: Dashboard to visualize Electrical usage


3.1 Brief Description
The Dashboard to visualize electrical usage is a software appliance that has a visual display
providing Actor 1 statistics of current and historical usage of electricity. Usage is categorized by appliances
and grouped by functions. Functional groupings of activities are related to Kitchen, Bathrooms, Living
areas, utility areas, storage and external to the house are over laid to facilitate an organized approach to
visualization and cognition.
3.2 Actor Brief Descriptions
3.3 Actor 1: Joe Smith (JS)
3.4 Actor 2: Program 1 - Data mining algorithm (DM)
3.5 Actor 3: Program 2 – Sensor (SR)
3.6 Trigger
The need to establish a baseline of current usage by appliance using taxonomy based on functional
usage.
3.7 Preconditions
The household must use electricity to for lighting, power appliances and predominant functions in
the household.
3.8 Incoming Information (optional)
See Event flow for inputs and outputs. Inputs are a combination of automated discovery of
appliances within the domain, data mined from repositories available externally to the program
and grouping information provided by Actor 1 defining the current environment.
3.9 Event Flow
1. Use case begins when Joe Smith, decides to monitor electrical usage with the intent making
incremental improvements in energy use. The first step in the process is establishing a
baseline.
2. Flow step 1. Actor 1 - JS activates Actor 3 SR to start storing state of current usage based on
discovery, input from Actor 2 DM
3. Flow step 2. Actor 1 - JS requests a baseline of usage from Actor 3 SR.
4. Flow step 3. Actor 3 – SR invokes data collection algorithm - an automated discovery process
for a predetermined amount of time.
5. Flow step 4. Actor 3 - SR invokes Actor 2 DM to collect usage and efficiency data from
external repositories.
6. Flow step 5. Actor 3 - SR requests Actor 1 JS to validate data on discovered devices. The
process includes a manual override - adding/modifying appliances and functional groupings.
7. Flow step 6. Actor 3 – SR requests Actor 1 – JS, to validate suggested optimization
parameters for appliances and or functional grouping of appliances.
8. Flow step 7. Actor 3 - SR generates a preliminary baseline and displays it
9. Flow step 8. Actor 1 - JS reviews and accepts the initial baseline
10. Use case ends when Actor 3 - SR displays the accepted baseline with the current usage
overlay.
3.10 Alternate Event Flows

Page 7 of 9
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

3.11 Alternate flow 1


If in Flow step 6 (see 3.9.7) of the basic flow, Actor 1 does not accept the initial baseline, then
1. Actor 1 – JS modifies/overrides discovery information of appliances and functional
grouping of appliances.
2. The use case resumes at Flow step 5 (see 3.9.6)
3.12 Results
The result of UC1: Dashboard to visualize electrical usage, is a validated baseline, customized for
the environment, based on data mined from external repositories and current usage patterns.
3.13 Post conditions
3.14 Post-condition 1
UC2: Dashboard to interact and modify Electrical usage is a crucial post condition. This goal of
achieving incremental improvements is rooted in iteration and the feedback loop. The ultimate
goal is to use data mining to provide automatic usage optimization similar to what we see in
routing algorithms prevalent today.

4 Use-Case: UC2: Dashboard to interact and modify Electrical usage


4.1 Brief Description
The Dashboard to interact and modify electrical usage is a module of the overall software
appliance that has a visual display providing Actor 1 a user interface to provide feedback to the system. To
achieve incremental improvements, it is necessary to invoke an iterative process, where the feedback loop
is engaged, based on which changes are implemented to achieve a desired level of efficiency.
4.2 Actor Brief Descriptions
4.3 Actor 1: Joe Smith (JS)
4.4 Actor 2: Program 1 - Data mining algorithm (DM)
4.5 Actor 3: Program 2 – Sensor (SR)
4.6 Actor 4: Appliances (APL)

4.7 Trigger
Once the base line in UC1 is established Actor 1 JS interacts with Actor 3 SR to revise usage of
appliances or grouping of appliances.
4.8 Preconditions
A baseline must be established and validated as specified in use-case UC1: Dashboard to visualize
Electrical usage. A validated baseline, customized for the environment, based on data mined from
external repositories and current usage patterns is critical to interact and modify electrical usage
4.9 Incoming Information (optional)
See Event flow for inputs and outputs. Inputs are a combination of automated discovery of
appliances within the domain, data mined from repositories available externally to the program
and grouping information provided by Actor 1 JS defining the current environment.

Page 8 of 9
Interactive Dashboard for a Greener Built Environment Author: Terry
Fernandez
Use-Case Document Date: 10/17/2009

4.10 Event Flow


1. Use case begins when Actor 1 JS decides to interact with current electrical usage with the
intent making incremental improvements in energy use. The interaction is based on suggested
improvements from Actor 3 SR. The first step in the process is modifying usage of individual
or grouping of appliances.
2. Flow step 1. Actor 3 – SR provides suggestions of interaction to modify current usage of
appliances or groupings of appliances based on the baseline established in UC1: Dashboard
for visualizing electrical usage.
3. Flow step 2. Actor 1 – JS validates the actions are acceptable
5. Flow step 3. Actor 3 - SR interacts with Actor 4 – APL. Consisting of appliances or
groupings of appliances to modify pattern of usage based on the validation provided by
Actor 1 - JS.
4. Use case ends when Actor 3 - SR displays the baseline with the revised usage overlay.
4.11 Alternate Event Flows
4.12 Alternate flow 1
If in Flow step 1 (see 4.9.1) of the basic flow, Actor 1 does not accept the suggestions, then
5. Actor 1 – JS modifies/overrides the suggestions of interactions to modify current usage of
appliances or functional grouping of appliances.
6. The use case resumes at UC1: Dashboard to visualize electrical usage - Flow step 4 (see
3.9.6)
4.13 Results
The result of UC2: Dashboard to interact and modify electrical usage, is an incremental
improvement process that uses iteration and a feedback loop, customized for the environment,
based on data mined from external repositories and current usage patterns and validate by Actor 1.
4.14 Post conditions
4.15 Post-condition 1
Periodic review and validation of overlay data of current usage over the baseline is a necessary
post condition, since the goal of incremental improvement in electrical energy usage is rooted in
iteration.
4.16 Post-condition 2
Periodic review and validation of overlay data of current usage as compared to that of other
households in the neighborhood and communities is a necessary post condition.

Page 9 of 9

Das könnte Ihnen auch gefallen