We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byPhoebe Truss
Modified over 2 years ago
The Unified Systems Engineering Process Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ (520) Copyright © Bahill
© 2009 Bahill 2 5/31/2014
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 © 2009 Bahill 3 5/31/2014
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 4 5/31/2014
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 5 5/31/2014
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 6 5/31/2014
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 7 5/31/2014
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 8 5/31/2014
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 9 5/31/2014
USS Zumwalt © 2009 Bahill 10 5/31/2014
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 Martins proposal was substantially superior in this aspect. The JSF is now called the F-35. © 2009 Bahill 11 5/31/2014
The UML tools are graphical* © 2009 Bahill 12 5/31/2014
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 13 5/31/2014
Unified Systems Engineering Process Iterative, incremental elaborations Vertical requirements development Dont 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 14 5/31/2014
© 2009 Bahill 15 5/31/2014
Comparison of life cycle phases © 2009 Bahill 16 5/31/2014
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 17 5/31/2014
Baseline models © 2009 Bahill 18 5/31/2014
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 19 5/31/2014
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 20 5/31/2014
The slots of a use case © 2009 Bahill 21 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 at 5/31/2014
Use cases Describe required functional behavior Identify requirements Provide test cases Give a skeleton for the users manual May be used by sales and marketing 5/31/2014 © 2009 Bahill 22
Case study Design a heating, ventilation and air conditioning (HVAC) system for a typical Tucson family house Lets start in the first iteration of the Inception life- cycle phase and explore the business model. © 2009 Bahill 23 5/31/2014
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 24 5/31/2014
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 25 5/31/2014
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 26 5/31/2014
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 27 5/31/2014
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 28 5/31/2014
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 29 5/31/2014
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 30 5/31/2014
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 31 5/31/2014
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 32 5/31/2014
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 33 5/31/2014
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 34 5/31/2014
Use-case diagram* © 2009 Bahill 35 5/31/2014
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 36 5/31/2014
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 37 5/31/2014
© 2009 Bahill 38 5/31/2014
Model mapping We must create mappings to transition between models. A few slides are available at MappingsBetweenModels © 2009 Bahill 39 5/31/2014
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 40 5/31/2014
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 41 5/31/2014
© 2009 Bahill 42 5/31/2014
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 43 5/31/2014
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 44 5/31/2014
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 45 5/31/2014
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 46 5/31/2014
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 47 5/31/2014
Analysis model use-case diagram © 2009 Bahill 48 5/31/2014
Communication diagram © 2009 Bahill 49 5/31/2014
Class diagram © 2009 Bahill 50 5/31/2014
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 51 5/31/2014
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 52 5/31/2014
Other parts of the analysis model Candidate architecture Piggyback system* Alternatives Glossary Risk analysis Business case Lessons learned © 2009 Bahill 53 5/31/2014
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 54 5/31/2014
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 55 5/31/2014
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 56 5/31/2014
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 57 5/31/2014
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 58 5/31/2014
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 59 5/31/2014
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 60 5/31/2014
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 61 5/31/2014
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 62 5/31/2014
Design model use-case diagram* © 2009 Bahill 63 5/31/2014
Sequence diagram for Heat House © 2009 Bahill 64 5/31/2014
Sequence diagram for the alternate flow Owner smells gas of Heat House use case © 2009 Bahill 65 5/31/2014
Design model class diagram © 2009 Bahill 66 5/31/2014
State machine diagram for HVAC Controller © 2009 Bahill 67 5/31/2014
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 68 5/31/2014
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 69 5/31/2014
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 70 5/31/2014
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 71 5/31/2014
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 72 5/31/2014
Activity diagram The following activity diagram is Figure 12.3 of Booch, Jacobson and Rumbaugh (1999). © 2009 Bahill 73 5/31/2014
Workflows © 2009 Bahill 74 5/31/2014
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 75 5/31/2014
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 76 5/31/2014
Test vectors 2* © 2009 Bahill 77 5/31/2014
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 78 5/31/2014
Test using system experiments* © 2009 Bahill 79 The system passes this test only if it produces the above output trajectory 5/31/2014
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 80 5/31/2014
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 81 5/31/2014
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 82 5/31/2014
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 83 5/31/2014
Levels 2 © 2009 Bahill 84 5/31/2014
Levels 3 © 2009 Bahill 85 5/31/2014
Activity diagram © 2009 Bahill 86 5/31/2014
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 87 5/31/2014
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 88 5/31/2014
Links between UML things © 2009 Bahill 89 5/31/2014
© 2009 Bahill 90 5/31/2014
Slide 3.1 © The McGraw-Hill Companies, 2007 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Topics covered l Functional and non-functional requirements l User requirements.
Chapter 7 – Design and Implementation 1Chapter 7 Design and implementation Note: These are a modified version of Ch 7 slides available from the authors.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter 2 Computer-Based System Engineering.
10-1 McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005.
Chapter 4 Requirements Engineering Slide 1 Chapter 4 Requirements Engineering.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Alter – Information Systems 4th ed. © 2002 Prentice Hall 1 Understanding Systems From a Business Viewpoint.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 4 Slide 1 Requirements Engineering u Establishing what the customer requires from a software.
1 PROJECT MANAGEMENT Using Microsoft Project 2000.
ISBN Prentice-Hall, 2006 Chapter 5 Designing the System Copyright 2006 Pearson/Prentice Hall. All rights reserved.
Dec 2005 UMT Portfolio Manager Builder User Training.
1 Resource Limited Project Management Vladimir Liberzon
Berling Associates, Inc. 1 T.E.A.M. EFFORT A Primer on Process Management (A View From The Improvements Team Perspective)
2011 NYCECC June CHAPTER 5 COMMERCIAL ENERGY EFFICIENCY 2011 New York City Energy Conservation Code Effective from December 28, 2010 BUILDING HVAC.
Page 1 R Copyright © 1997 by Rational Software Corporation Analysis and Design with UML.
All Q & A Issued by PMI 1 1. A project is: A. A set of sequential activities performed in a process or system. B. A revenue-generating activity that needs.
1 ©2006, Stanley Associates. All rights reserved. 1 U.S. Marine Corps Parts Inventory Management Garrison Mobile Equipment (GME) Fleet Management System.
Training on Cost Estimation & Analysis Karen Richey Jennifer Echard Madhav Panwar.
Copyright 2011 John Wiley & Sons, Inc Business Data Communications and Networking 11th Edition Jerry Fitzgerald and Alan Dennis John Wiley & Sons, Inc.
Chapter 7 / Slide 1 Copyright © 2008 Pearson Education Canada Part 3 Groups and Teamwor Copyright © 2008 Pearson Education Canada Social Behaviour and.
Performance Evaluation HR Training Sessions May , 2013.
©2006 Barbara C. McNurlin. Published by Pearson Education. 2-1 The Top IS Job Chapter 2 Information Systems Management In Practice 7E McNurlin & Sprague.
1 SAS #70 (as Amended by SAS #88) Service Organizations NSAA IT Conference September 28, 2006 Nashville, TN Presented by: Michael A. Billo, CISA, CGAP.
UNIT-l Conceptual foundation of Business Process reengineering 1.
The Whirlwind Tour Chapter 1a. 2 Transactions: Where It All Started [Cuneiform] documents now number about half a million, three- quarters of them more.
Android 11: Google Play for Education Kirk Scott 1.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 1 Chapter 29 Configuration Management.
© 2016 SlidePlayer.com Inc. All rights reserved.