Hvac
-
Upload
mohammed-siddiqui -
Category
Technology
-
view
2.084 -
download
3
description
Transcript of Hvac
The Unified Systems The Unified Systems Engineering ProcessEngineering Process
Terry BahillSystems and Industrial EngineeringUniversity of ArizonaTucson, AZ 85721-0020(520) 621-6561http://www.sie.arizona.edu/sysengrCopyright © 2001-2010 Bahill
© 2009 Bahill204/10/23
ReferencesReferencesTerry Bahill and Jesse Daniels, Using object-oriented and UML tools for hardware design: a case study, Systems Engineering, 6(1): 28-48, 2003.
My template for writing use cases is available athttp:/www/sie.arizona.edu/sysengr/slides/template.docMy guidance for naming UML things may also be usefulhttp:/www/sie.arizona.edu/sysengr/sie277/names.doc
© 2009 Bahill304/10/23
EvolutionEvolution•20th century systems were mechanical
hardware systems. •21st century systems are electronic
software systems. •Systems engineering tools are also
evolving. •These new tools are being used by both
systems and software engineers. •Systems and software engineers are
speaking the same language.
© 2009 Bahill404/10/23
Adopt the new toolsAdopt the new tools•Software engineers have been about five
years ahead of systems engineers.
•Our tools have their origins in the 1950s and 1960s: they have improved our tools.
•The Unified Modeling Language (UML) is a standard for using these tools.
•(Previously this was called object-oriented analysis and design.)
•The Systems Modeling Language (SysML) has extensions specifically created for system design.
•We should use UML and SysML.
© 2009 Bahill504/10/23
The deficiencyThe deficiency•Systems engineering design tools
are old fashioned do not link together are used differently by different
people•Systems and software engineers do
not communicate well. •Some systems engineers are still
using waterfall processes. •Flow-down of requirements causes
excess design margins and expensive redesigns.
•Late changes in requirements cause costly redesign.
© 2009 Bahill604/10/23
What the UML is notWhat the UML is notThe tools of the UML do not replace all other tools.
A fool with a tool is still a fool.
© 2009 Bahill704/10/23
Commercial productsCommercial products• IBM Rational Rose
• I-Logix Rhapsody
•Telelogic Tau UML Suite
•DOORS Rose Link
•Enterprise Architect I have a site license for Enterprise
Architect
© 2009 Bahill804/10/23
UML helped Raytheon win DD(X)UML helped Raytheon win DD(X)•Brain Wells and Paul Weeks said they used object-
oriented analysis (OOA) at the system level.
•Of their preproposal, their customer said use of OOA was a “weakness.” When they won the contract in 2003 it was said to be a “major strength.”
•Creating a common language and a common vision for all engineers helped them to win this $1.36 billion contract.
•On DD(X) they are using UML for Systems Architecture, System Design and System Analysis, as well as Software Design.
•The DD(X) is now called DDG1000 Zumwalt class
© 2009 Bahill904/10/23
USS ZumwaltUSS Zumwalt
© 2009 Bahill
10
04/10/23
Joint Strike FighterJoint Strike FighterIn 2001, Lockheed Martin beat Boeing in the Joint Strike Fighter (JSF) competition. Early on, they noted a government suggestion in the RFP that object-oriented design and UML tools be used for the system design. Lockheed Martin’s proposal was substantially superior in this aspect. The JSF is nowcalled the F-35.
© 2009 Bahill1104/10/23
The UML tools are graphical*The UML tools are graphical*
© 2009 Bahill12
2+2= ?
A2 + B2 = ?
A
B
C
?
A
I = ?6 V. R = 6
04/10/23
Using UML improves communicationsUsing UML improves communications•The UML is an engineering method
for communicating and modeling systems.
• It helps software and hardware engineers to communicate.
• It helps software and systems engineers to communicate.
• It improves communications with our NATO partners.
© 2009 Bahill1304/10/23
Unified Systems Engineering ProcessUnified Systems Engineering Process• Iterative, incremental elaborations•Vertical requirements development
Don’t throw it over the wall. Requirements are developed,
not passed off.•Five major themes:
(1) requirements (get them early and get them right, but plan for change),
(2) architecture (design the interfaces early),
(3) design is use case based, (4) plan frequent small iterations and (5) manage risk (start risk analysis
early and develop high-risk subsystems first).
© 2009 Bahill1404/10/23
© 2009 Bahill15
Inception Elaboration Construction Transition Operation,Retirement &Replacement
Life Cycle Phases
Iterations
Time
Iter.#1
Iter.#2
Iter.#3
Iter.#n
Iter.#n-1
Requirements
Analysis
Design
Implementation
Verification
Activities
Operations
ReviewsSRR CDRPDR TSTTRRMCR
04/10/23
Comparison of life cycle phasesComparison of life cycle phasesPhase of the System Life-cycle, (Wymore, 1993) (waterfall)
Phase of the Unified Systems Engineering Process (spiral)
Define Requirements Inception Investigate Alternatives Inception Full-scale Design Elaboration Implementation Construction Integration & Test Transition Operation, Maintenance & Evaluation
Operation
Retirement, Disposal & Replacement
Retirement & Replacement
© 2009 Bahill1604/10/23
BaselinesBaselines• In industry baselines often have names
such as, business model, requirements model, logical model, analysis model, design model, implementation model, component model, deployment model, run time model, etc.
•These models are roughly associated with a system life cycle phase, as shown in the next slide.
© 2009 Bahill1704/10/23
Baseline modelsBaseline modelsLife Cycle Phase of the Unified Systems Engineering Process
Model
Inception iteration 1 Business model Inception iteration 2 Requirements model Elaboration iteration 1 Analysis model Elaboration iteration 2 Design model Construction Implementation model Transition Operation Run time model Replacement Operations model
© 2009 Bahill1804/10/23
Black box --- white boxBlack box --- white box•The requirements model is often called a
black box model, because we see only input and output behavior, not the inner workings of the black box.
•The analysis model is often called a grey box model, because we have hints of what is inside the box.
•The design model is often called a white box model, because we not only see the components inside the box, but we also design them.
© 2009 Bahill
19
04/10/23
Design should be use case drivenDesign should be use case drivenA use case is an abstraction of required functions of a system. A use case produces an observable result of value to the user. Each use case describes a sequence of interactions between one or more actors and the system.
© 2009 Bahill2004/10/23
The slots of a use caseThe slots of a use case
© 2009 Bahill21
Name:* Precondition:
Iteration: Trigger:
Brief description:
Main Success Scenario:
Added value:* Alternate Flows:
Goal: * Postcondition:
Level: Specific Requirements
Scope: Functional Requirements:
Primary actor: Nonfunctional Requirements:
Supporting actor:
Author/owner:
Frequency: Date:My template for writing use cases is available athttp:/www/sie.arizona.edu/sysengr/slides/template.doc
04/10/23
Use casesUse cases•Describe required functional behavior
• Identify requirements
•Provide test cases
•Give a skeleton for the user’s manual
•May be used by sales and marketing
04/10/23 © 2009 Bahill
22
Case studyCase study•Design a heating, ventilation and air
conditioning (HVAC) system for a typical Tucson family house
•Let’s start in the first iteration of the Inception life-cycle phase and explore the business model.
© 2009 Bahill2304/10/23
HVAC BusinessHVAC Business use case use case11
Name:* Sell HVAC Equipment and ServicesName:* Buy and Operate HVAC System Iteration: 1.0Brief description: Our company sells Heating,
Ventilation and Air Conditioning (HVAC) equipment and services to home owners in Tucson.
Added value: The house is comfortable, therefore Home Owner is more productive.
Scope: A Tucson housePrimary actor:* Home Owner or BICSSupporting actors: HVAC CompanyPrecondition: *Home Owner owns a house in
Tucson.
© 2009 Bahill2404/10/23
HVAC BusinessHVAC Business use case use case22
Main Success Scenario: 1. Home Owner buys an air
conditioning system on average every ten years.
2. Home Owner buys a heating system on average every 15 years.
3. Home Owner performs maintenance on the air conditioner in May.
4. Home Owner performs maintenance on the heater in November.
© 2009 Bahill2504/10/23
HVAC BusinessHVAC Business use case use case33
Unanchored Alternate Flow: Home Owner performs repairs on the HVAC
system whenever a component fails.Specific RequirementsFunctional Requirement:Home Owner shall buy, maintain and repair
an HVAC system [from HVAC Business use case].*
Nonfunctional Requirement:Home Owner desires maintenance services
when scheduled and repair services within 48 hours [from customer interviews].
© 2009 Bahill2604/10/23
HVAC BusinessHVAC Business use case use case44
Rules:Rule1: There are 200,000 houses in the
Tucson area. Rule2: Each maintenance service costs
about $70.Rule3: Each repair service costs about $300.Author: Terry BahillDate: September 6, 2005
© 2009 Bahill2704/10/23
Work products of the business modelWork products of the business model•A context model (an object or data
flow diagram) showing how the system fits into its overall environment
•High-level business requirements (essential use cases)
•A glossary
•A domain model (a class diagram) depicting major business classes
•A business process model (an activity diagram) depicting a high-level overview of the business process
© 2009 Bahill2804/10/23
Requirements modelRequirements model• In the second iteration of the Inception
phase we investigate the requirements model.
•*Start with a skeleton of the highest priority (highest-risk) subsystems.
© 2009 Bahill2904/10/23
Regulate TemperatureRegulate Temperature use case use case11
Iteration: 2.0Brief description: Maintain the room temperature
(roomTemp) between lowerThreshold (see Rule1) and upperThreshold (see Rule2) degrees Fahrenheit using a Heater and an Air Conditioner (AC).
Added value: The House is comfortable, therefore Home Owner is more productive.
Scope: An HVAC controller for a Tucson housePrimary actor: Home OwnerSupporting actors: Heater and Air ConditionerPrecondition: The system is turned on
and the roomTemp is between lowerThreshold and upperThreshold.
© 2009 Bahill3004/10/23
Regulate TemperatureRegulate Temperature use case use case22
Main Success Scenario: 1. The system senses roomTemp.2a. The roomTemp exceeds upperThreshold.3. The system turns on the Air Conditioner.4. The roomTemp drops below upperThreshold.5. The system turns off the AC [repeat at step 1].Anchored Alternate Flow: 2b. The roomTemp drops below lowerThreshold.2b1. The system turns on the Heater.2b2. The roomTemp exceeds lowerThreshold.2b3. The system turns off the Heater [repeat at step
1].
© 2009 Bahill3104/10/23
Regulate TemperatureRegulate Temperature use case use case33
Specific RequirementsFunctional Requirements:1. The system shall be capable of turning the AC on and
off [from Regulate Temperature use case, steps 3 and 5].
2. The system shall be capable of turning the Heater on and off [from Regulate Temperature use case, steps 2b1 and 2b3].
3. The system shall be capable of sensing room temperature [from Regulate Temperature use case, step 1].
Rules:Rule1: lowerThreshold default value is 70 degrees F.Rule2: upperThreshold default value is 73 degrees F.Author: Terry BahillDate: September 2, 2005*
© 2009 Bahill3204/10/23
Display System StatusDisplay System Status use case use case11
Name: Display System StatusBrief description: Indicate the health of the
systemAdded value: Home Owner knows if the
system is working properly.Scope: An HVAC controller for a Tucson housePrimary actor: Home OwnerFrequency: Typically once a dayMain Success Scenario: 1. Home Owner asks the system for its status.2. Each component in the system reports its
status to the Controller.3. The system accepts this information and
updates the System Status display.4. Home Owner observes the System Status
[exit use case].
© 2009 Bahill3304/10/23
Display System StatusDisplay System Status use case use case22
Alternate flows go here.Specific RequirementsFunctional Requirements:1. Each component shall have the capability to
report its status to the Controller [from Display System Status use case, step 2].
2. The system shall be capable of displaying System Status [from Display System Status use case, step 3].
Author: Terry BahillDate: July 20, 2005
© 2009 Bahill3404/10/23
Use-case diagram*Use-case diagram*
© 2009 Bahill35
Heater
heatAir()
Air Conditioner
coolAir()
Regulate Temperature
Display System Status
Home Owner
04/10/23
Work products of the requirements model Work products of the requirements model •System requirements specification (SRS)
•Requirements traceability
• Interface requirements specification
•Operation concept description
•Technical performance measures
•High-priority, high-risk use case models
•Alternative concepts
•Preliminary risk analysis
• Incipient architectural description
•Glossary
© 2009 Bahill3604/10/23
Other parts of the requirements modelOther parts of the requirements model•Candidate architecture
•Alternative concepts*
•Glossary
•Risk analysis Capacity Expense Disturbance*
•Business case AC $7/day Heater $3/day
© 2009 Bahill3704/10/23
© 2009 Bahill3804/10/23
Model mappingModel mapping•We must create mappings to
transition between models.
A few slides are available athttp://www.sie.arizona.edu/
sysengr/slides/“MappingsBetweenModels”
© 2009 Bahill3904/10/23
Analysis modelAnalysis model• In the first iteration of the Elaboration
phase we create the analysis model.
•Start with the skeleton use cases derived in the requirements model.
•Add muscle to those skeletons
•Create more skeleton use cases.
•Start to develop the classes.
•Accommodate the newly discovered requirement that the system should not continuously cycle on and off.
© 2009 Bahill4004/10/23
Cool HouseCool House use case use caseIteration: 2.0Brief description: When it is hot outside, use an Air
Conditioner (AC) to maintain the room temperature (roomTemp) between ACLowerLimit and ACUpperLimit degrees Fahrenheit.
Added value: The House is comfortable, therefore Home Owner is more productive.
Scope: An HVAC controller for a Tucson housePrimary actor: Home OwnerSupporting actor: Air ConditionerFrequency: The system operates continuously.Precondition: Home Owner has turned on the cooling
system and the roomTemp is between ACLowerLimit and ACUpperLimit.
Main Success Scenario: … etc.
© 2009 Bahill4104/10/23
© 2009 Bahill4204/10/23
Heat HouseHeat House use case use case11
Brief description: When it is cold outside maintain the roomTemp between heaterLowerLimit (see Rule2) and heaterUpperLimit (see Rule3) degrees Fahrenheit using a Heater.
Added value:* The house is comfortable, therefore Home Owner is more productive.
Goal:* Maintain house at a comfortable temperatureScope: An HVAC controller for a Tucson housePrimary actor: Home OwnerSupporting actor: HeaterFrequency: The system operates continuously. Precondition: The heating system is on and the
roomTemp is between heaterLowerLimit and heaterUpperLimit.
© 2009 Bahill4304/10/23
Heat HouseHeat House use case use case22
Main Success Scenario: 1. The system is sensing roomTemp.2. The roomTemp falls below heaterLowerLimit.3. The system turns on the Heater [in accordance with
Rule1].4. The roomTemp rises to heaterUpperLimit.5. The system turns off the Heater [Rule1] [go to step 1].Unanchored Alternate Flow:1. Home Owner smells “gas.”*2. Home Owner turns off Heater [exit use case].Specific RequirementsFunctional Requirements:1. The system shall turn the Heater on and off [from steps 3
and 5 of the Heat House use case].2. The system shall sense room temperature [from step 1
of the Heat House use case].
© 2009 Bahill4404/10/23
Heat HouseHeat House use case use case33**Nonfunctional performance requirement: On-off cycles should last at least 15 minutes [from
interview with Chief Systems Engineer].Rules:Rule1: When the Heater is on, turn the Fan on.
When the Heater is off, turn the Fan off.Rule2: heaterLowerLimit default value is 70 degrees F.Rule3: heaterUpperLimit default value is 71 degrees F.Author/owner: Terry BahillDate: September 2, 2005
© 2009 Bahill4504/10/23
Display System StatusDisplay System Status use case use case11
Iteration: 2.0Brief description: The system shall monitor the health
of each object in the system and display the status of the complete system. The display could be a simple go/no-go or it might be more sophisticated.
Added value: Home Owner knows if the system is working properly.
Scope: An HVAC controller for a Tucson housePrimary actor: Home OwnerFrequency: The system shall display system status
continuously.Main Success Scenario: 1. The Fan reports status to the Controller.2. The Air Conditioner reports status to the Controller.3. The Heater reports status to the Controller.
© 2009 Bahill4604/10/23
Display System StatusDisplay System Status use case use case22
4. The Thermostat reports status to the Controller.5. The Controller computes the System Status and sends
results to the Display.6. The Displays shows the System Status.7. Home Owner observes the System Status periodically
[repeat at step 1].Specific RequirementsFunctional Requirements:1. Each component shall report its status to the
Controller [from steps 1 to 5 of the Display System Status use case].
2. The system shall display System Status.Nonfunctional requirement: System Status shall be
displayed within 2 seconds of request.Author/owner: Terry BahillDate: September 2, 2005
© 2009 Bahill4704/10/23
Analysis model use-case diagramAnalysis model use-case diagram
© 2009 Bahill48
Heater
heatAir()
(from Business Use-Case Model)
Display System Status
(f rom Business Use-Case Model)
Heat House
Home Owner
(from Business Use-Case Model)
Air Con diti oner
coolAir()
(from Business Use-Case Model)
Cool House
04/10/23
Communication diagramCommunication diagram
© 2009 Bahill49
: Thermostat
: AC Interface
: Air Conditioner
: Controller
1: set(tooHot)4: reset(tooHot)
3: turnOn6: turnOff
2: turnOnAC5: turnOffAC
04/10/23
Class diagramClass diagram
© 2009 Bahill50
Heater
heatAir()
(f rom Business Use-Case Model)
Air Conditioner
coolAir()
(f rom Business Use-Case Model)
Fan
turnOn()turnOff()
The Heater and AC Interfaces should also have functions that turn the Fan on and off.
Home Owner
(f rom Business Use-Case Model)
Heater Interface
turnOnHeater()turnOffHeater()
AC Interface
turnOnAC()turnOffAC()
Controller
tooHot : Boolean = NotooCold : Boolean = No
set()reset()
Thermostat
ACupperThreshold : Integer = 73AClowerThreshold : Integer = 72roomTemperature : IntegerheaterUpperThreshold = 71heaterLowerThreshold = 70
04/10/23
Work products of the analysis modelWork products of the analysis model11
•Elaborations of entities of requirements model •Analysis packages composed of
high-level use cases analysis classes interface definitions
•Use case realizations with textual descriptions class diagrams communication diagrams
•Special Requirements sections containing formal shall statement functional requirements identification of the nonfunctional
requirements
© 2009 Bahill5104/10/23
Work products of the analysis modelWork products of the analysis model22
•Supplemental entities functional flow block diagrams object (context) diagrams
•The analysis model is a static model, because it shows objects and their interrelationships, but not time dependent dynamics.
© 2009 Bahill5204/10/23
Other parts of the analysis modelOther parts of the analysis model•Candidate architecture
Piggyback system*
•Alternatives
•Glossary
•Risk analysis
•Business case
•Lessons learned
© 2009 Bahill5304/10/23
Design modelDesign model• In (roughly) the second iteration of the
Elaboration phase we create the design model.
•Add muscle to the skeleton use cases of the analysis model.
•Develop the muscularized skeletons of the analysis model.
•Create more skeleton use cases.
•Develop the classes.
•Accommodate the new piggyback architecture.
© 2009 Bahill5404/10/23
Cool HouseCool House use case use caseBrief description: When it is hot outside maintain the
room temperature (roomTemp) between coolerLowerLimit and coolerUpperLimit degrees Fahrenheit using a Cooler (either an Evaporative Cooler or an Air Conditioner).
Scope: An HVAC controller for a Tucson houseLevel: LowPrimary actor: Home OwnerSupporting actor: CoolerFrequency: The system operates continuously.Precondition: Home Owner has selected the Cooler,
systemStatus is ready, systemState is Cooler Off, and the roomTemp is below coolerUpperLimit.
Trigger: The roomTemp exceeds coolerUpperLimit.Main Success Scenario: … etc.
© 2009 Bahill5504/10/23
Heat HouseHeat House use case use case11
Brief description: When it is cold outside maintain the roomTemp between heaterLowerLimit and heaterUpperLimit degrees Fahrenheit using a Heater.
Scope: An HVAC controller for a Tucson houseLevel: LowPrimary actor: Home OwnerSupporting actor: HeaterFrequency: The system operates continuously. Precondition: Home Owner has selected the Heater,
systemStatus is ready, system state is Heater Off, and roomTemp is above heaterLowerLimit.
Trigger: The roomTemp falls below heaterLowerLimit.Main Success Scenario: 1. The system turns on the Heater [in accordance with
Rule1].
© 2009 Bahill5604/10/23
Heat HouseHeat House use case use case222. The roomTemp rises to heaterUpperLimit.3. The system turns off the Heater [Rule1] [exit use
case].Unanchored Alternate Flow:1. Home Owner smells gas.2. Home Owner turns off Heater [exit use case].Postcondition: Heater is offFunctional requirements…Nonfunctional performance requirement: On-off cycles
should last at least 15 minutes.Rules:Rule1: When the Heater is on, turn the Fan on.
When the Heater is off, turn the Fan off.Rule2: heaterLowerLimit default value is 70 degrees F.Rule3: heaterUpperLimit default value is 71 degrees F.Author/owner: Terry BahillDate: January 31, 2002
© 2009 Bahill5704/10/23
Display System StatusDisplay System Status use case use case11Brief description: The system shall monitor the health of
each object in the system and display the status of the complete system. This display should indicate ready or fault.
Scope: An HVAC controller for a Tucson houseLevel: MediumPrimary actor: Home OwnerFrequency: The systemStatus shall be computed
periodically (e.g. every minute) or it may be event driven (e.g. on each state transition). The system shall display the systemStatus continuously.
Main Success Scenario: 1. The Fan Interface executes its Built-in Self-Test (BiST) for
the Fan and the Fan Interface and reports the results to the Controller.
2. The Air Conditioner Interface executes its BiST and reports the results to the Controller.
© 2009 Bahill5804/10/23
Display System StatusDisplay System Status use case use case22
3. The Evaporative Cooler Interface executes its BiST and reports the results to the Controller.
4. The Heater Interface executes its BiST and reports the results to the Controller.
5. The Thermostat executes its BiST and reports the results to the Controller.
6. The Controller executes its BiST and computes the systemStatus.
7. The Controller sends the systemStatus to the Thermostat.
8. The Thermostat displays the systemStatus.9. Home Owner observes the systemStatus periodically
[repeat at step 1].Specific requirements …Author: Terry BahillDate: January 31, 2002
© 2009 Bahill5904/10/23
Set Temperature LimitsSet Temperature Limits use case use caseBrief description: Home Owner changes the HVAC
temperature limitsScope: An HVAC controller for a Tucson houseLevel: MediumPrimary actor: Home OwnerFrequency: DailyPrecondition: Home Owner has selected the
equipment and systemStatus is ready.Main Success Scenario: 1. Home Owner sets coolerUpperLimit.2. Home Owner sets coolerLowerLimit.3. Home Owner sets heaterUpperLimit.4. Home Owner sets heaterLowerLimit.5. Exit Set Temperature Limits use case.Postcondition: All four limits are set.Author/owner: Terry BahillDate: January 31, 2002
© 2009 Bahill6004/10/23
Configure EquipmentConfigure Equipment use case use case11
Brief description: Home Owner chooses which equipment to turn on: heater, air conditioner, or evaporative cooler.
Added value: Necessary for operation and maintenanceScope: An HVAC controller for a Tucson houseLevel: HighAssumption: If the Home Owner wants heating and
cooling on the same day, then he or she will switch back and forth manually.
Primary actor: Home OwnerFrequency: Once a yearPrecondition: systemStatus* is “ready.”
© 2009 Bahill6104/10/23
Configure EquipmentConfigure Equipment use case use case22
Main Success Scenario: 1. March 21 Home Owner turns Heater off and
Evaporative Cooler on.2. June 21 Home Owner turns Evaporative Cooler off
and Air Conditioner on.3. September 21 Home Owner turns Air Conditioner
off and Evaporative Cooler on.4. November 21 Home Owner turns Evaporative
Cooler off and Heater on [cycle back to step 1].Postcondition: One of the three systems is active.Specific requirements …Author/owner: Terry BahillDate: January 31, 2002
© 2009 Bahill6204/10/23
Design model use-case diagram*Design model use-case diagram*
© 2009 Bahill63
HeatHouse
SetTemperature
Limits
CoolHouse
Select Equipment
DisplaySystemStatus
HVAC Control System
HomeOwner
Heater
EvaporativeCooler
AirConditioner
04/10/23
Sequence diagram for Sequence diagram for Heat HouseHeat House
© 2009 Bahill64
: Thermostat : Heater Interface
: Heater: Controller
roomTemp=<heaterLowerLimit
turnOnHeater
turnOn
roomTemp>=heaterUpperLimit
turnOffHeater
turnOff
Time runs from top to bottom.
04/10/23
Sequence diagram for the alternate flow “Owner Sequence diagram for the alternate flow “Owner smells gas” of smells gas” of Heat HouseHeat House use case use case
© 2009 Bahill65
: Thermostat : Controller :Heater Interface : Heater: Home Owner
Time runs from top to bottom
roomTemp=<heaterLowerLimit
turnOnHeater
turnOn
turnOffHeater
turnOffHeaterturnOff
Home Owner smells gas.
04/10/23
Design model class diagramDesign model class diagram
© 2009 Bahill66
Home Owner
(f rom Use Case View)
Thermostat
coolerUpperLimit : Integer = 73coolerLowerLimit : Integer = 72heaterUpperLimit : Integer = 71heaterLowerLimit : Integer = 70roomTemp : Integer
compareRoomTempToLimits()BiT()displaySystemStatus()
Air Conditioner
coolAir()
(f rom Use Case View)
AC Interface
turnOnAC()turnOffAC()BiT()
Evaporative Cooler
coolAir()
(f rom Use Case View)
Evaporative Cooler Interface
turnOnEvapCooler()turnOffEvapCooler()BiT()
Heater
heatAir()
(f rom Use Case View)
Heater Interface
turnOnHeater()turnOffHeater()BiT()
Controller
systemStatus : Boolean = fault
BiT()setSystemStatus()
<<active>>
Fan
blowAir()
(f rom Use Case View)
Fan Interface
turnOnFan()turnOffFan()BiT()
Notes: The bottom third of each class box lists the functions, which are also called operations or responsibilities.BiT stands for Built in Test.
04/10/23
State machine diagram for HVAC ControllerState machine diagram for HVAC Controller
© 2009 Bahill67
sm Statecharts
HVAC Controller
Heater CoolerOn
Heater On
+ On Entry / turnOnHeater
Heater Off
+ On Entry / turnOffHeater
Cooler On
+ On Entry / turnOnCooler
Cooler Off
- On Entry / turnOffCooler
InitialInitial
roomTemp<=heaterLowerLimit
roomTemp>=heaterUpperLimitOR homeOwnerSmellsGas roomTemp<=coolerLowerLimit
roomTemp>=coolerUpperLimit
04/10/23
The design modelThe design model11
•May be 5 times bigger than analysis model
•Elaborates entities of the analysis model•Contains subsystems composed of
design classes interfaces use case realizations
textual descriptions class diagrams sequence diagrams
•Special Requirements sections contain formal shall statement functional
requirements nonfunctional requirements
© 2009 Bahill6804/10/23
The design modelThe design model22
•Supplemental entities state machine diagrams deployment diagrams
• Is a dynamic model because, using sequence diagrams and state machine diagrams, it shows the timing of the functions being performed and the messages being passed
© 2009 Bahill6904/10/23
COTSCOTS•We have just been given a new
requirement: everything should be commercial off the shelf (COTS).
•This greatly simplifies the models, as is shown in the following implementation specification for the evaporative cooler subsystem.
© 2009 Bahill7004/10/23
Implementation specificationImplementation specification•Aerocool PH6800A 117-volt cooler with 1 hp
motor and Phoenix Pro-Stat thermostat
•Cooler to thermostat interface: 66 foot 6 conductor cable. Do not cut or splice.
•Cooler to duct interface : barometric damper 20" by 20", bottom of duct is 22" off the roof
• Infrastructure: 117-volt, 15-amp receptacle and a quarter-inch copper water tube
•Cost: $1890
•Schedule: Install March 18, 2003
•Performance: 6800 cfm •Test: If Tout < 100 – 0.4humidity then Tin
< 70 F © 2009 Bahill7104/10/23
The implementation modelThe implementation model•May be 10 times bigger than design model
•Elaborates entities of the design model•Contains
components interfaces integration build plan unit test cases and procedures
•Supplemental entities dependencies between components
© 2009 Bahill7204/10/23
Activity diagramActivity diagramThe following activity diagram is Figure 12.3 of Booch, Jacobson and Rumbaugh (1999).
© 2009 Bahill7304/10/23
WorkflowsWorkflows
© 2009 Bahill7404/10/23
VerificationVerification11
•There are three common techniques for testing systems test vectors (input/output
behavior) system experiments (state-
based) instances of use cases (scenario-
based)
•State-based testing is the best.
© 2009 Bahill7504/10/23
Test vectorsTest vectors11
Heating System Test VectorInputsNormal
heaterUpperLimit = 71 F and heaterLowerLimit = 70 FExtremes
heaterUpperLimit = 80 F and heaterLowerLimit = 78 FheaterUpperLimit = 36 F and heaterLowerLimit = 34 F
MistakesheaterUpperLimit = 70 F and heaterLowerLimit = 72 F
© 2009 Bahill7604/10/23
Test vectorsTest vectors2*2*
© 2009 Bahill77
Initial state Event (Inputs) Resulting output
Any roomTemp > coolerUpperLimit Cooler On Cooler Off roomTemp < coolerUpperLimit Cooler Off Cooler Off roomTemp = coolerUpperLimit Cooler On Cooler On roomTemp > coolerLowerLimit Cooler On Cooler On roomTemp = coolerLowerLimit Cooler Off Any roomTemp < coolerLowerLimit Cooler Off Any coolerUpperLimit coolerLowerLimit SignalError
04/10/23
Test vectorsTest vectors33
Test Procedure for the Heater1. Choose a cold day, e.g. outside
temperature is less than 60 F.2. Set Heater On/Off switch to On.3. Set heaterUpperLimit and
heaterLowerLimit according to the Test Vector [ ].
4. Observe room temperature for one hour.5. If it goes outside the heaterLimits, record
a defect.
© 2009 Bahill7804/10/23
Test using system experiments*Test using system experiments*Time Events (Input Trajectory) State 0 roomTemp < coolerUpperLimit Cooler Off 1 roomTemp = coolerUpperLimit Cooler Off 2 roomTemp > coolerUpperLimit Cooler On 3 roomTemp = coolerUpperLimit Cooler On 4 roomTemp < coolerUpperLimit Cooler On 5 roomTemp = coolerLowerLimit Cooler On 6 roomTemp < coolerLowerLimit Cooler Off 7 roomTemp = coolerLowerLimit Cooler Off 8 roomTemp > coolerLowerLimit Cooler Off 9 Cooler Off
Time Events (Input Trajectory) State 0 coolerUpperLimit coolerLowerLimit Cooler Off 1 Error
© 2009 Bahill79
The system passes this test only if it produces the above output trajectory
04/10/23
Test using use-case scenarios*Test using use-case scenarios*Use Case Name: Heat HouseScenario: 1. Pat Harris starts this scenario on January 8
with the outside temperature = 40 F, the heater off, systemStatus = ready, the roomTemp = 70.5 F and the heaterLowerLimit and heaterUpperLimit at their default values.
2. The roomTemp falls below 70 F.3. The system turns on the Heater and the Fan.4. The roomTemp rises to 71 F.5. The system turns off the Heater and the Fan.6. To pass this test, the roomTemp must remain
greater than heaterLowerLimit for the next 15 minutes, [end of test].
© 2009 Bahill8004/10/23
VerificationVerification22
•Test vectors: Select a variety of inputs, some normal, some extreme and some mistakes. For each input vector, describe the acceptable output vector. Write a test procedure that will invoke each test vector. Describe conditions need to pass or fail the test.
•State-based system experiments. Define an initial state for time equal zero. Create an input trajectory. Show the state trajectory that is required in order to pass the test.
•Scenarios. Select a use case that has already been written for the system. Instantiate it with particular people, places and conditions. Describe behavior that is necessary in order to pass the test. Run the system with this instantiation.
© 2009 Bahill8104/10/23
Operations phaseOperations phaseThe operations model (usually a computer simulation) should be built from the implementation model. It should reflect the structure of the system as it was actually built. It will be used to manage and improve the operational system. It will be updated anytime the operational system is changed. Most importantly, it will used to help with retirement of the system. Another UML tool called an activity diagram will be used to show the workflows, that is who does which tasks during the operations phase.
© 2009 Bahill8204/10/23
LevelsLevels11
•Most systems are impossible to study in their entirety, but they are made up of hierarchies of smaller subsystem that can be studied.
•User level - thermostat, controller, heater, air conditioner and evaporative cooler.
•Low level - colors of the wires and electrical voltages.
•High level - brown outs or heating of the city caused by operation of a million air conditioners.
•Consider use cases one level above or below, but not use cases two levels above or below.
© 2009 Bahill8304/10/23
LevelsLevels22
Operations Aspect Level Use cases City (high) Heat the City, Cause Brown Outs Architect Choose and Install Equipment and Insulation, Specify Architecture
of the House User Heat House, Cool House, Display System Status, Set Temperature
Limits, Choose Equipment Equipment Turn Equipment On and Off, Open and Close Windows and Vents Electricity Specify Colors of Wires Interconnecting Equipment, Choose
Electrical Voltages Element (low)
Freon Changes Phases, Helical Spring Expands, Mercury Capsule Tilts
Maintenance Aspect Level Use cases Generational Freon Depletes Ozone Layer Multi year Vacuum Ducts, Caulk Small Openings, Sweep Chimney, Bleed
Radiators Seasonal Light Pilot, Dust Fans, Add Freon, Oil Motors, Change Cooler
Pads, Adjust Storm Windows Periodic Clean or Replace Filters, Replace Fuses Continuous Circulate Oil, Pump Water
© 2009 Bahill8404/10/23
LevelsLevels33
OperationsAspect
MaintenanceAspect
Generational
Mulltiyear
UserPeriodic
City
Architect
Equipment
Electricity
Element
Seasonal
Continuous
© 2009 Bahill8504/10/23
Activity diagramActivity diagram
© 2009 Bahill86
Write specification and request bids
Select contractor
Pay bill
Exit to Seasonal Level
Submit bid 1
Install cooler
Test OK
Submit bid 2
Cooler, Maintenance Aspect, Multiyear Level
Fork
Join
Contractor2Contractor1Home Owner
04/10/23
SysMLSysML•SysML is the systems engineering
extensions to the UML
•SysML has diagrams for showing the hierarchical relationships of requirements
•SysML has diagrams for representing equations
•SysML uses activity diagrams much like enhanced functional flow block diagrams
© 2009 Bahill8704/10/23
Challenges for old engineersChallenges for old engineers•Changing from functional thinking
to object orientation
•Progressing from use cases to classes
•Changing from waterfall processes to incremental iterations
•Discovering classes that are not based on physical objects, e.g. an algorithm for selecting equipment.
© 2009 Bahill8804/10/23
Links between UML thingsLinks between UML things
© 2009 Bahill89
UMLFocus question: What are the links between Unified
Modeling Language (UML) things?
Use case
Sequencediagram
Classdiagram Statechart
Defines
Def
ines Defines
Defines
Messages Commands
Labe
l arr
ows
into
obje
cts
Lab
el arrow
s
ou
t of o
bjects
Operations
ResponsibilitiesH
as o
utp
uts
Activities
Events
Has
o
utp
uts H
as inputs
EnterExitDoOn transition
Wh
en is
specified
by
Des
crib
es
inst
ance
s o
f al
l th
ese
Become
Concept Mapping
Become
Become
Become
States
Iden
tifie
s
Trace to
Relationships
Implie
s
Has
04/10/23
© 2009 Bahill9004/10/23