Your SlideShare is downloading. ×
0
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Hvac
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Hvac

2,162

Published on

hvac

hvac

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,162
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
193
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • There were three big evaluation items. Systems Engineering, Boeing said did they did OK. Boeing’s JSF gave vertical lift by directing jet exhaust downward. LM blew air with a fan. But the biggest different was LM’s use of UML tools.
  • The bottom figure is on the state flag of Alaska.
  • Use cases should be named with verb phrases given in the active present tense form, from the point of view of the system or of the primary actor (depending on whose book you are reading). If you are using the view point of the primary actor, then the name should reflect the goal of that actor. Use case names should not relate to any particular solution. The verb should be in the imperative mood. Use case names are usually written with the first letter of each word capitalized and spaces between the words. It is helpful to set use case names in a different font. You should have a Goal or an Added value, but probably not both.
  • For the primary actor of BICS, Name: Sell HVAC Equipment and Services For the primary actor of Home Owner, Name: Buy and Operate HVAC System to Heat and Cool my House. Övergaard and Palmkvist (2005) state that use cases should be named from the perspective of the system. That is, they should state what the system is supposed to do. Thus, they would state that the Home Owner is the primary actor, and the name of the use case is “Sell HVAC Equipment and Services.” I don’t put the article “the” in front of the primary actor. Because, when the use case is instantiated with a person’s name, you would not want the “the.” For example, Pat Harris owns a house in Tucson.
  • This is a deliberate mistake. You cannot write requirements are things outside of your system, like the primary actor, the Home Owner.
  • The highest risk systems are most likely to change, forcing changes in other systems. If the highest risk systems cannot be completed successfully, cancel the project and save the money on developing the rest. In this mode of thinking, in the beginning also work on the optional functions. The contractor may back off.
  • In this presentation I am listing the creation date. You might prefer the last time it was changed.
  • The use case text is often called the use case specification. A use case model contains use case specifications, the use cases diagrams and perhaps other diagrams (e.g. flow charts, activity diagrams) and enclosures.
  • An important task is investigating alternative designs. For our HVAC system, we will also consider electric heat, wood, oil, coal, heat pumps, solar panels, three-phase electricity, steam, blankets, coats, hot or chilled water systems, fans, ice farms and cooling towers. According to the Regulate Temperature use case, depending upon which threshold is exceeded first, the system will sit at 70 or 73 degrees and turn the heater or AC on and off, maybe every second. If the system turns on and off every minute it would be very distracting to the people. So let’s require that it be on or off for at least 15 minutes at a time.
  • The goal is very much like the added value. You should use one or the other, not both.
  • Ethyl mercaptan = gas
  • The Nonfunctional performance requirement is new.
  • Supplemental entities that may be in the analysis model include functional flow block diagrams and object (context) diagrams.
  • The risk analysis shows that Ac air conditioning might cost as much as $7 per day. This may be too much for poor graduate students. Therefore we propose a piggyback system. On March 21 the Home Owner turns the Heater off and Evaporative Cooler on. For the next few months Tucson is very dry and the evaporative cooler cools the house very well. On June 21 the Home Owner turns the Evaporative Cooler off and Air Conditioner on. July and August are the monsoon season. It is humid and the evaporative cooler does work well, so we use the air conditioner. On September 21 the Home Owner turns the Air Conditioner off and Evaporative Cooler on. On November 21 the Home Owner turns the Evaporative Cooler off and Heater on.
  • The flag systemStatus would be system status in the business and requirements models.
  • In the Business Model the use-case diagram could be used as an outline for use cases you plan to develop. But in the Design Model it should be used as a table of contents for the use cases you have already written.
  • The title is purple, because this is a header slide.
  • Each row is a test specification. You can select any row, in any order.
  • State-based testing is the best. In state-based testing you start with an initial state and an input trajectory (a series of test vectors), then you run the experiment and observe the state trajectory.
  • When a use case is filled with specific names, dates, temperatures, etc. it is called an instantiation (based on the word instance).
  • The title is purple, because this is a header slide.
  • Transcript

    • 1. The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 (520) 621-6561 http://www.sie.arizona.edu/sysengr Copyright © 2001-2010 Bahill
    • 2. © 2009 Bahill 09/19/11
    • 3. References
      • Terry 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 at
      • http:/www/sie.arizona.edu/sysengr/slides/template.doc
      • My guidance for naming UML things may also be useful
      • http:/www/sie.arizona.edu/sysengr/sie277/names.doc
      © 2009 Bahill 09/19/11
    • 4. Evolution
      • 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 Bahill 09/19/11
    • 5. Adopt 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 Bahill 09/19/11
    • 6. The 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 Bahill 09/19/11
    • 7. What the UML is not
      • The tools of the UML do not replace all other tools.
      • A fool with a tool is still a fool.
      © 2009 Bahill 09/19/11
    • 8. Commercial 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 Bahill 09/19/11
    • 9. 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 Bahill 09/19/11
    • 10. USS Zumwalt © 2009 Bahill 09/19/11
    • 11. Joint Strike Fighter
      • In 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 now
      • called the F-35.
      © 2009 Bahill 09/19/11
    • 12. The UML tools are graphical* © 2009 Bahill 09/19/11
    • 13. Using 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 Bahill 09/19/11
    • 14. Unified 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 Bahill 09/19/11
    • 15. © 2009 Bahill 09/19/11
    • 16. Comparison of life cycle phases © 2009 Bahill 09/19/11
    • 17. Baselines
      • 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 Bahill 09/19/11
    • 18. Baseline models © 2009 Bahill 09/19/11
    • 19. Black 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 09/19/11
    • 20. Design should be use case driven
      • A 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 Bahill 09/19/11
    • 21. The slots of a use case © 2009 Bahill My template for writing use cases is available at http:/www/sie.arizona.edu/sysengr/slides/template.doc 09/19/11 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:
    • 22. Use 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
      09/19/11 © 2009 Bahill
    • 23. Case 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 Bahill 09/19/11
    • 24. HVAC Business use case 1
      • Name:* Sell HVAC Equipment and Services
      • Name:* Buy and Operate HVAC System
      • Iteration: 1.0
      • Brief 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 house
      • Primary actor:* Home Owner or BICS
      • Supporting actors: HVAC Company
      • Precondition: * Home Owner owns a house in Tucson .
      © 2009 Bahill 09/19/11
    • 25. HVAC Business use case 2
      • 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 Bahill 09/19/11
    • 26. HVAC Business use case 3
      • Unanchored Alternate Flow:
      • Home Owner performs repairs on the HVAC system whenever a component fails.
      • Specific Requirements
      • Functional 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 Bahill 09/19/11
    • 27. HVAC Business use case 4
      • 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 Bahill
      • Date: September 6, 2005
      © 2009 Bahill 09/19/11
    • 28. Work 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 Bahill 09/19/11
    • 29. Requirements 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 Bahill 09/19/11
    • 30. Regulate Temperature use case 1
      • Iteration: 2.0
      • Brief 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 house
      • Primary actor: Home Owner
      • Supporting actors: Heater and Air Conditioner
      • Precondition: The system is turned on
      • and the roomTemp is between
      • lowerThreshold and upperThreshold .
      © 2009 Bahill 09/19/11
    • 31. Regulate Temperature use case 2
      • 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 Bahill 09/19/11
    • 32. Regulate Temperature use case 3
      • Specific Requirements
      • Functional 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 Bahill
      • Date: September 2, 2005*
      © 2009 Bahill 09/19/11
    • 33. Display System Status use case 1
      • Name: Display System Status
      • Brief description: Indicate the health of the system
      • Added value: Home Owner knows if the system is working properly.
      • Scope: An HVAC controller for a Tucson house
      • Primary actor: Home Owner
      • Frequency: Typically once a day
      • Main 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 Bahill 09/19/11
    • 34. Display System Status use case 2
      • Alternate flows go here.
      • Specific Requirements
      • Functional 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 Bahill
      • Date: July 20, 2005
      © 2009 Bahill 09/19/11
    • 35. Use-case diagram* © 2009 Bahill 09/19/11
    • 36. 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 Bahill 09/19/11
    • 37. Other parts of the requirements model
      • Candidate architecture
      • Alternative concepts*
      • Glossary
      • Risk analysis
        • Capacity
        • Expense
        • Disturbance*
      • Business case
        • AC $7/day
        • Heater $3/day
      © 2009 Bahill 09/19/11
    • 38. © 2009 Bahill 09/19/11
    • 39. Model mapping
      • We must create mappings to transition between models.
      • A few slides are available at
      • http://www.sie.arizona.edu/sysengr/slides /
      • “ MappingsBetweenModels”
      © 2009 Bahill 09/19/11
    • 40. Analysis 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 Bahill 09/19/11
    • 41. Cool House use case
      • Iteration: 2.0
      • Brief 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 house
      • Primary actor: Home Owner
      • Supporting actor: Air Conditioner
      • Frequency: 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 Bahill 09/19/11
    • 42. © 2009 Bahill 09/19/11
    • 43. Heat House use case 1
      • 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 temperature
      • Scope: An HVAC controller for a Tucson house
      • Primary actor: Home Owner
      • Supporting actor: Heater
      • Frequency: The system operates continuously.
      • Precondition: The heating system is on and the roomTemp is between heaterLowerLimit and heaterUpperLimit.
      © 2009 Bahill 09/19/11
    • 44. Heat House use case 2
      • 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 Requirements
      • Functional 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 Bahill 09/19/11
    • 45. Heat House use case 3 *
      • 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 Bahill
      • Date: September 2, 2005
      © 2009 Bahill 09/19/11
    • 46. Display System Status use case 1
      • Iteration: 2.0
      • Brief 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 house
      • Primary actor: Home Owner
      • Frequency: 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 Bahill 09/19/11
    • 47. Display System Status use case 2
      • 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 Requirements
      • Functional 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 Bahill
      • Date: September 2, 2005
      © 2009 Bahill 09/19/11
    • 48. Analysis model use-case diagram © 2009 Bahill 09/19/11
    • 49. Communication diagram © 2009 Bahill 09/19/11
    • 50. Class diagram © 2009 Bahill 09/19/11
    • 51. Work products of the analysis model 1
      • 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 Bahill 09/19/11
    • 52. Work products of the analysis model 2
      • 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 Bahill 09/19/11
    • 53. Other parts of the analysis model
      • Candidate architecture
        • Piggyback system*
      • Alternatives
      • Glossary
      • Risk analysis
      • Business case
      • Lessons learned
      © 2009 Bahill 09/19/11
    • 54. Design 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 Bahill 09/19/11
    • 55. Cool House use case
      • Brief 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 house
      • Level: Low
      • Primary actor: Home Owner
      • Supporting actor: Cooler
      • Frequency: 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 Bahill 09/19/11
    • 56. Heat House use case 1
      • 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 house
      • Level: Low
      • Primary actor: Home Owner
      • Supporting actor: Heater
      • Frequency: 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 Bahill 09/19/11
    • 57. Heat House use case 2
      • 2. 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 off
      • Functional 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 Bahill
      • Date: January 31, 2002
      © 2009 Bahill 09/19/11
    • 58. Display System Status use case 1
      • Brief 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 house
      • Level: Medium
      • Primary actor: Home Owner
      • Frequency: 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 Bahill 09/19/11
    • 59. Display System Status use case 2
      • 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 Bahill
      • Date: January 31, 2002
      © 2009 Bahill 09/19/11
    • 60. Set Temperature Limits use case
      • Brief description: Home Owner changes the HVAC temperature limits
      • Scope: An HVAC controller for a Tucson house
      • Level: Medium
      • Primary actor: Home Owner
      • Frequency: Daily
      • Precondition: 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 Bahill
      • Date: January 31, 2002
      © 2009 Bahill 09/19/11
    • 61. Configure Equipment use case 1
      • Brief description: Home Owner chooses which equipment to turn on: heater, air conditioner, or evaporative cooler.
      • Added value: Necessary for operation and maintenance
      • Scope: An HVAC controller for a Tucson house
      • Level: High
      • Assumption: 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 Owner
      • Frequency: Once a year
      • Precondition: systemStatus* is “ready.”
      © 2009 Bahill 09/19/11
    • 62. Configure Equipment use case 2
      • 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 Bahill
      • Date: January 31, 2002
      © 2009 Bahill 09/19/11
    • 63. Design model use-case diagram* © 2009 Bahill 09/19/11
    • 64. Sequence diagram for Heat House © 2009 Bahill 09/19/11
    • 65. Sequence diagram for the alternate flow “Owner smells gas” of Heat House use case © 2009 Bahill 09/19/11
    • 66. Design model class diagram © 2009 Bahill 09/19/11
    • 67. State machine diagram for HVAC Controller © 2009 Bahill 09/19/11
    • 68. The design model 1
      • 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 Bahill 09/19/11
    • 69. The design model 2
      • 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 Bahill 09/19/11
    • 70. COTS
      • 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 Bahill 09/19/11
    • 71. Implementation 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.4  humidity then Tin < 70  F
      © 2009 Bahill 09/19/11
    • 72. The 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 Bahill 09/19/11
    • 73. Activity diagram
      • The following activity diagram is Figure 12.3 of Booch, Jacobson and Rumbaugh (1999).
      © 2009 Bahill 09/19/11
    • 74. Workflows © 2009 Bahill 09/19/11
    • 75. Verification 1
      • 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 Bahill 09/19/11
    • 76. Test vectors 1
      • Heating System Test Vector
      • Inputs
      • Normal
      • heaterUpperLimit = 71  F and heaterLowerLimit = 70  F
      • Extremes
      • heaterUpperLimit = 80  F and heaterLowerLimit = 78  F
      • heaterUpperLimit = 36  F and heaterLowerLimit = 34  F
      • Mistakes
      • heaterUpperLimit = 70  F and heaterLowerLimit = 72  F
      © 2009 Bahill 09/19/11
    • 77. Test vectors 2* © 2009 Bahill 09/19/11
    • 78. Test vectors 3
      • Test Procedure for the Heater
      • 1. 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 Bahill 09/19/11
    • 79. Test using system experiments* © 2009 Bahill The system passes this test only if it produces the above output trajectory 09/19/11
    • 80. Test using use-case scenarios*
      • Use Case Name: Heat House
      • Scenario:
      • 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 Bahill 09/19/11
    • 81. Verification 2
      • 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 Bahill 09/19/11
    • 82. Operations phase
      • The 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 Bahill 09/19/11
    • 83. Levels 1
      • 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 Bahill 09/19/11
    • 84. Levels 2 © 2009 Bahill 09/19/11
    • 85. Levels 3 © 2009 Bahill 09/19/11
    • 86. Activity diagram © 2009 Bahill 09/19/11
    • 87. SysML
      • 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 Bahill 09/19/11
    • 88. Challenges 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 Bahill 09/19/11
    • 89. Links between UML things © 2009 Bahill 09/19/11
    • 90. © 2009 Bahill 09/19/11

    ×