The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 (520) 621-6561 .

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


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


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


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


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


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


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

http://www.sie.arizona.edu/sysengr/slides/

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


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


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


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


Air Con diti oner

coolAir()


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()


Air Conditioner

coolAir()


Fan

turnOn()turnOff()

The Heater and AC Interfaces should also have functions that turn the Fan on and off.

Home Owner


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


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


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()


AC Interface

turnOnAC()turnOffAC()BiT()

Evaporative Cooler

coolAir()


Evaporative Cooler Interface

turnOnEvapCooler()turnOffEvapCooler()BiT()

Heater

heatAir()


Heater Interface

turnOnHeater()turnOffHeater()BiT()

Controller

systemStatus : Boolean = fault

BiT()setSystemStatus()

<<active>>

Fan

blowAir()


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

The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 (520) 621-6561 .

Documents

bahill slide

design model

systems engineers

systems engineering

uml tools

software design

requirements model

modeling systems