Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Unified Systems Engineering Process

Similar presentations


Presentation on theme: "The Unified Systems Engineering Process"— Presentation transcript:

1 The Unified Systems Engineering Process
Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ (520) Copyright © Bahill

2 3/31/2017 © 2009 Bahill

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, My template for writing use cases is available at My guidance for naming UML things may also be useful 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

10 USS Zumwalt 3/31/2017 © 2009 Bahill

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. 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. 3/31/2017 © 2009 Bahill

12 The UML tools are graphical*
The bottom figure is on the state flag of Alaska. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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). 3/31/2017 © 2009 Bahill

15 3/31/2017 © 2009 Bahill

16 Comparison of life cycle phases
3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

18 Baseline models 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

21 The slots of a use case 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: 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. My template for writing use cases is available at 3/31/2017 © 2009 Bahill

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 3/31/2017 © 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. 3/31/2017 © 2009 Bahill

24 HVAC Business use case1 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. 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. 3/31/2017 © 2009 Bahill

25 HVAC Business use case2 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. 3/31/2017 © 2009 Bahill

26 HVAC Business use case3 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]. This is a deliberate mistake. You cannot write requirements are things outside of your system, like the primary actor, the Home Owner. 3/31/2017 © 2009 Bahill

27 HVAC Business use case4 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 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

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. 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. 3/31/2017 © 2009 Bahill

30 Regulate Temperature use case1
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. 3/31/2017 © 2009 Bahill

31 Regulate Temperature use case2
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]. 3/31/2017 © 2009 Bahill

32 Regulate Temperature use case3
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* In this presentation I am listing the creation date. You might prefer the last time it was changed. 3/31/2017 © 2009 Bahill

33 Display System Status use case1
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]. 3/31/2017 © 2009 Bahill

34 Display System Status use case2
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 3/31/2017 © 2009 Bahill

35 Use-case diagram* 3/31/2017 © 2009 Bahill
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. 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

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 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. 3/31/2017 © 2009 Bahill

38 3/31/2017 © 2009 Bahill

39 Model mapping We must create mappings to transition between models.
A few slides are available at “MappingsBetweenModels” 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

42 3/31/2017 © 2009 Bahill

43 Heat House use case1 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. The goal is very much like the added value. You should use one or the other, not both. 3/31/2017 © 2009 Bahill

44 Heat House use case2 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]. Ethyl mercaptan = gas 3/31/2017 © 2009 Bahill

45 Heat House use case3* 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 The Nonfunctional performance requirement is new. 3/31/2017 © 2009 Bahill

46 Display System Status use case1
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. 3/31/2017 © 2009 Bahill

47 Display System Status use case2
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 3/31/2017 © 2009 Bahill

48 Analysis model use-case diagram
3/31/2017 © 2009 Bahill

49 Communication diagram
3/31/2017 © 2009 Bahill

50 Class diagram 3/31/2017 © 2009 Bahill

51 Work products of the analysis model1
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 Supplemental entities that may be in the analysis model include functional flow block diagrams and object (context) diagrams. 3/31/2017 © 2009 Bahill

52 Work products of the analysis model2
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. 3/31/2017 © 2009 Bahill

53 Other parts of the analysis model
Candidate architecture Piggyback system* Alternatives Glossary Risk analysis Business case Lessons learned 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. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

56 Heat House use case1 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]. 3/31/2017 © 2009 Bahill

57 Heat House use case2 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 3/31/2017 © 2009 Bahill

58 Display System Status use case1
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. 3/31/2017 © 2009 Bahill

59 Display System Status use case2
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 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

61 Configure Equipment use case1
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.” The flag systemStatus would be system status in the business and requirements models. 3/31/2017 © 2009 Bahill

62 Configure Equipment use case2
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 3/31/2017 © 2009 Bahill

63 Design model use-case diagram*
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. 3/31/2017 © 2009 Bahill

64 Sequence diagram for Heat House
3/31/2017 © 2009 Bahill

65 Sequence diagram for the alternate flow “Owner smells gas” of Heat House use case
3/31/2017 © 2009 Bahill

66 Design model class diagram
3/31/2017 © 2009 Bahill

67 State machine diagram for HVAC Controller
3/31/2017 © 2009 Bahill

68 The design model1 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 3/31/2017 © 2009 Bahill

69 The design model2 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 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

73 Activity diagram The following activity diagram is Figure 12.3 of Booch, Jacobson and Rumbaugh (1999). 3/31/2017 © 2009 Bahill

74 Workflows 3/31/2017 © 2009 Bahill

75 Verification1 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. The title is purple, because this is a header slide. 3/31/2017 © 2009 Bahill

76 Test vectors1 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 3/31/2017 © 2009 Bahill

77 Test vectors2* 3/31/2017 © 2009 Bahill
Each row is a test specification. You can select any row, in any order. 3/31/2017 © 2009 Bahill

78 Test vectors3 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. 3/31/2017 © 2009 Bahill

79 Test using system experiments*
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. The system passes this test only if it produces the above output trajectory 3/31/2017 © 2009 Bahill

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]. When a use case is filled with specific names, dates, temperatures, etc. it is called an instantiation (based on the word instance). 3/31/2017 © 2009 Bahill

81 Verification2 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. The title is purple, because this is a header slide. 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

83 Levels1 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. 3/31/2017 © 2009 Bahill

84 Levels2 3/31/2017 © 2009 Bahill

85 Levels3 3/31/2017 © 2009 Bahill

86 Activity diagram 3/31/2017 © 2009 Bahill

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 3/31/2017 © 2009 Bahill

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. 3/31/2017 © 2009 Bahill

89 Links between UML things
3/31/2017 © 2009 Bahill

90 3/31/2017 © 2009 Bahill


Download ppt "The Unified Systems Engineering Process"

Similar presentations


Ads by Google