UML-Based Design Process
Contents
1. 41 Notes On Design We ll talk more about statecharts in the next lecture Rules for good design Use flowcharts for sequential actions Almost none in our system we aren t using flow charts for first half of course Use statecharts for mode dependent behavior Every non trivial module in the elevator will have a statechart Avoid pseudo code Generally it devolves into implementation Comments aren t a design Comments are an explanation of implementation Fit a design diagram on a single sheet of letter sized paper f it doesn t fit break the design down into smaller components that do fit What s the difference between design amp implementation Implementation is executable code A good design doesn t have any code in it 42 Implementation Java Code Elevator implemented in Java with a course supplied simulation framework e We give you the software to implement the environmental objects e g people We give you some example code based on last year s project t is simpler but it gives you a starting point Youcreate Java code to implement the Statecharts and any algorithms required 43 Testing Checking It Actually Works Some possible types of testing Exercise all arcs of statecharts one way to do untt test Exercise each sequence diagram one way to do integration test Exercise concurrent use cases with passengers one way to do acceptance test But need to addre2. Keep copies of last value received for each message and periodically set outgoing message values for next periodic transmission Permits using multiple received messages We ll see this later in more detail EVERY VERB GETS A NUMBER e Numbers are used to tracing requirements to implementation amp tests later on 39 Time Triggered v Event Triggered in the Project Project 3 Create event triggered requirements Each incoming message triggers actions when it is received Asynchronous state machine one transition per incoming message Think interrupts Project 4 Change to time triggered requirements Most recent message value continually polled for current value Synchronous state machine zero or one transitions per period But Provided materials are all time triggered Don t worry about inconsistencies between provided materials and your materials for project 3 Don t get distracted or confused by this We decided it was more confusing to change provided stuff after project 3 40 Design State Charts Describes finite state machine behaviors it s an FSM transition diagram emphasizes how object achieves its behaviors Look a lot like finite state machine state transition diagrams Example Passenger state chart 2 WAITING IN HALL 9 OVERWEIGHT BACKOFF i PT2 8 OVERWEIGHT_EXITING 7 EXIT_BACKOUT 6 EXITING PT14 10 DONE
3. In general use cases are intended to capture a transaction e E g request a bank balance on an automated teller machine Usually a user session has multiple transactions request balance withdraw money In elevator case it should be a situation that is a nice building block e For example approach elevator and tell it you want to go up down Or make a hall call for short e Names should be 2 5 words long and relatively descriptive with emphasis on VERBS actions These are about how users want to use the system not how the system is built Let s talk about scenarios so you can see how size affects the next step 24 Scenarios what happens inside the use case Nominal ways in which user and system interact e Often multiple alternate scenarios for each use case e Each scenario is the same size as a particular use case from end to end Off nominal exceptional and failure situations Informal Example a scenario for Enter Elevator use case e Initial condition user is waiting for elevator to arrive in desired direction The car reaches the floor stops and opens its door The car illuminates appropriate direction lantern User enters The car clears the hall call that was just serviced pe 15 qo des The car closes doors and extinguishes direction lantern Note that multiple scenarios are invoked for end to end service e Commonly scenarios are independent in toy problems and ba
4. Sequence Diagram Constructing sequence diagram should just be a matter of connecting messages from your scenario in the right order NOTE Taken from on line soda machine example on course web page Sequence Diagram 3A customer conetum CoinControl VendControl I I i I 1b mCoihiRetum true I I I 1a Press Coin Return I 1c mCoirlReturn false l p M O i I l 2a CoinOut true l w l I 2b CoinOut false l l r 3 l l l l l I I 2c mCoinCount 1 l l l l l l I l l l l 2d CoinOut true I I I l 2e CoinOut false l 4 3 l 2f mCoinCount 0 POST CoinCount 0 l I I I 18649 Spring 2010 I Group 7 Justin Ray justinr2 I I I Messages Vs Physical Actions We use a discrete event simulator for the project e Everything is an event at a specific time e Including simulated sensors and actuators Some of the messages in the sequence diagram are not messages at all but represent interaction between control system and environment When doors begin to close the DoorOpen sensor transitions from True to False The passenger does not read this sensor he she simply sees the doors begin to close When the passenger indicates a car call he she actually presses the physical button Weusean m prefix to keep track of things with color coding backup mDo
5. bon SOURCE CODE Usually architecture amp requirements co evolve Lecture flows better with architecture first so that is today s discussion Review This lecture concentrates on the pieces e What the pieces really are e How they fit together e Next lecture is end to end example 5 Why UML Or Any Other Notation UML Unified Modeling Language e Itisn t actually Unified it s all the best known ideas tossed into the same sack e And it s more a set of graphical techniques than a textual language UML isn t novel it s just a common representation Gives a way to exchange ideas via standardized set of diagrams Gives a standard way to document thoughts for later access e UML is NOT a design methodology there are many ways to use UML in a methodology and we re just now figuring out the better ways to do this There is not yet any best process Best varies depending on size of team complexity novelty and company culture But it s better to have some process than no process And the ability to follow an arbitrary but specified process is important amp UML Based Process Lite For Our Course System level requirements Use cases e High level text requirements Architecture emphasis on nouns e Class Diagrams amp object descriptions sensors actuators controllers nterfaces network message dictionary Software Requi
6. not always understood e Once requirements are really understood the client realizes they re wrong e Vendor supplied components are imperfect Get over it Our provided materials are very good but probably imperfect You ve got source code 3 Almost doesn t cut it e 90 right or just a little late can still get an A in school 90 working means 10 not working and any percent of not working means broken 10 wrong or missing a shipping date can mean losing your job in the real world For the course project you ll do some of 1 and 2 e You ll be using a process that is lightweight but not bad for industry e 90 is still an A so I guess we re just softies 46 Outputs Product Definition Design amp Development Verification gt Production Project Plans amp Confidence In Sustained High Level Design Detaled Design sofware Implementation Performance Marketing amp Engineering Specification Product goals Functionality Performance Reliability Migration plan Schedule Suggested Reviews Software Architecture Review 1 Requirements SRR Functional requirements Nonfunctional requirements Software process plan complexity staffing schedule budget V amp V and test plans Deployment plan Maintenance upgrade plan Human interface requirements Risk issues Traceability matrices
7. pre amp post conditions Related question how detailed is a scenario e Stay tuned for answer but first we have to talk about Sequence Diagrams 27 Sequence Diagrams Shows which objects do what to implement a scenario Emphasizes interaction communication among components Feels closer to a design at the system interaction level In our course every arc is a message within the simulation framework This is not the same as the preceding scenario What are a b c Sequence Diagram 1B DoorControl DoorClosed Hall Call HallButtonControl HallLight la EN r Close 2 Passenger Arrives 3a Ep d true 3b HallCall f b d true 4 HallLight f b d On PANAO mDoorClosdd b r True 5b pig r Stop 28 Sequence Diagram Shows a sequenced set of messages illustrating a specific example of object interaction Object1 in t poca Object2 Object3 Class name rd van ma NEN LL NS event 0 1 0 2 0 3 optional optional timing ruler iptive text Barta 05 aanak ais shows object 2 operation state 0 6 3 operation parameter list 0 7 0 8 0 9 4 operation parameter list Sequence diagrams have two dimensions The vertical dimension usually represents _ time the horizontal represents different objects These may be reversed Rational optional 1 0 shows focus of control 5 0peration parameter list 1 2 13
8. 4 UML Based Design with an emphasis on course project survival Distributed Embedded Systems Philip Koopman September 9 2015 Carnegie Copyright 2000 2015 Philip Koopman Mellon Figure 23 displays the software recall causes for medical device recalls FY 2008 FY 2012 Figure 23 Number of Software Cause Recall Events by Fiscal Year 2008 2012 2008 2009 2010 2012 Sum Overall The majority of recalls with primarily software causes are associated with one of four Software Software Design of all Change Software manufacturing CDRH Control Design process Recalls device panels radiology cardiovascular clinical chemistry and general hospital The http www fda gov downloads AboutFDA CentersOffices OfficeofMedicalP roductsandTobacco CDRH CDRHTransparency UCM388442 pdf Where Are We Now Where we ve been Embedded system intro amp foundations Elevator domain knowledge Requirements Did you notice the lessons learned from last semester in the handouts last lecture also available on line Where we re going today e UML overview amp design process for course project Where we re going next Pepsi vending machine example Distributed Embedded system concepts Case studies Boeing 777 Toyota Electronic Throttle Control System Reviews amp Inspections Preview Design process e A set of steps to get you from requirements to design e Specifically the des
9. Call Hall Button Control 2 FH BH 3 a TC 4 DU Smart Actuator FH BH Car Button Control Hall Light apang OO Oooo BLUE BOX Sensors Actuators E BLACK BOX Controllers BLUE ARC Physical Connection BLACK ARC Network Message f total of floors FH of front hall entries BH of back hall entries 4 Emergency Brake Hoistway Limit Sensor Actuator Sensor Car Position Indicator o E Qa Car Call 19 Message Dictionary part of architecture mAtFloor f b v Floor proximity sensor v True False e True if the elevator is at the floor f and there is a door on hall h front or back of elevator or both false otherwise mDrive s d 3 speed main elevator drive s is speed s Fast Slow Level Stop d is direction d Up Down Stop The commanded speed and direction of the car 2 fields e Speed one of STOP SLOW FAST e Direction one of STOP UP DOWN For our type of system it is a list of system level state variables that describe state of objects For example each AtFloor sensor periodically broadcasts its own mAtFloor 20 Detailed Object Descriptions part of architecture Poor pnr r Door Opened switches One per Door b r for b Front Back and r Left Right total four sensors for two pairs of doors Indicates True when the Door b r is fully open e Set to False at initialization e m
10. DoorOpened b r shall be True if and only if mDoorPosition b r has a value greater than 490 Interpretation notes e b r means there are four doors LeftFront LeftRear RightFront RightRear v means that the object broadcasts the value v which in this case is True means door is fully open False means door is not fully open might be partway open does not imply closed We have intentionally designed the elevator so messages broadcast the internal state of each architectural object There are other ways to do things in other approaches 21 System Level Requirements Use Cases Useful for identifying different things system must do Actor initiates a Use Case Represents the system from the actor s point of view e System can act on environment too REQUEST ELEVATOR ENTER IL ELEVATOR OPEN pa DOORS CLOSE DOORS Problems e Who are the actors In general must include machines as well as people e Usually end up assuming a single centralized system control actor 22 An Example Soda Machine U1 Customer inserts a quarter U2 Customer pushes a soda button U3 Customer pushes coin return button Customer U4 Observe soda availability U5 Collect Money U6 Refill Machine Vendor How Big Should A Use Case Be There is some art to sizing the use cases End to end ride on elevator is too big Oneline of code is too small
11. Guidelines for Conducting Software Reviews July 2001 pa Weekly Course Project Phases Warm up Exercise Elevator scenarios amp sequence diagrams Event triggered behaviors amp statecharts e Arrival of a single message triggers some response Time triggered behaviors amp statecharts e Modify so responses are based on state variables and last received copy of messages Implementation amp test Implementation amp test Run time Monitor Acceptance Tests mid semester working elevator Improved dispatcher requirements amp initial design Finish improved dispatcher design create unit tests Testing and network scheduling More complete run time monitoring Implement faster drive commit point 5 1 floor away Final acceptance tests final project completed finals week 48 Review Unified Modeling Language A standardized set of graphical representations A convenient communication medium we re not too fussy about semantics But there will be a few rules we will give that must be followed Important pieces of real projects represented in course System level requirements Architecture Software Requirements Design Verification amp Validation Engineering Test Acceptance Test Process monitoring e g traceability Reminder solid methodical engineering process is important Read all the assignment Follow all the directions If we suggest you use a checklist use it It will sa
12. Supplier Strategy Operating system Libraries Development tools Communication network protocol Interface descriptions Detailed design of each Performance resource Failure mode safety Documentation Standards User Interface Standards Reuse Standards Unit test results Internal code inspection budgets results Traceability matrices unit UML is a best practice analysis Traceability matrices Risk areas Development Process Guidance E CAM Requirements Management Software Project Plan Software Troubleshooting amp Oversight SW Subcontract Management SW Quality Assurance Performance usability stability Safety Traceability matrices Configuration Management Testing Inter group coordination Peer Review SCMPR Subsystem object definitions Im SVVPR Interface definitions M ftwar IV amp V Architectural descriptions for CDR mise HW SW communications Module object Code Documentation V amp V audits Field trials control descriptions Design Test plans Production Dependency User Manual Test results Configuration Management descriptions Coding Standards Test against configurations Problem reporting Configuration management Defect tracking Upgrade releases Traceability of defects features to upgrades Major Review Stages as defined in IEEE Std 730 1998 Emerson SCOE
13. are they created default is permanent e Lanterns are Off at initialization Assumptions What do you need to assume to meet constraints given listed behaviors CarLanterns d are never commanded to be On at the same time Input Interface e What inputs are available e mDoorClosed b r e mDesiredFloor e mAtFloor f b 36 Example Elevator Behavioral Requirements 2 LanternControl d continued Output Interface e What outputs are available e CarLantern d physical interface to light bulbs e mCarLantern d network message that sends state to the rest of the system Internal State What private state variables are maintained What notational macros are used DesiredDirection Up Down Stop computed desired direction based on comparing CurrentFloor with Floor desired by Dispatcher This is implicitly computed and used as a macro in the behavior descriptions Note CurrentFloor is a shorthand notation for the value of whichever AtFloor f Stop is True if any If CurrentFloor is invalid it has a mnemonic value of None Constraints e What invariants must hold passive requirements 7 Both CarLanterns d shall not be On at the same time Example Elevator Behavioral Requirements 3 LanternControl d continued Event Triggered BEHA VIORS e What active behaviors must be implemented 7 2 Any mDoorClosed j k false shall set CarLantern DesiredDirection t
14. ated SD arcs Scenario should be in terms of what is happening use case more than in terms of messages being sent Scenario should be mostly in terms of everyday English But be specific when referring to defined objects such as saying AtFloor sensor Detailed scenarios can be used if they help you get to a SD One line of text for each arc on SD Probably most people will skip this and just draw the SDs from high level scenarios In general this is too detailed to look at and understand in terms of how it fits to the use case 33 Use Cases Scenarios SDs revisited Use cases are general types of interactions e Set of use cases covers all interactions More than one use case often invoked in sequence Scenario is a list of actions within a Use Case Generally each Use Case completely owns multiple Scenarios Each Use Case has one or more scenarios e Scenario is one way a Use Case is performed Pre conditions which situations must be true for scenario to execute Scenarios need mutually exclusive pre conditions within a use case Actions list of things to do Post conditions conditions summarizing situation after actions take place Sequence Diagram is a picture of objects and messages Each Scenario has exactly one Sequence Diagram This is a more rigorous notation that shows how to make objects behave 34 Textual Software Behaviors Text based specification written per module of a
15. e Soda vending machine template is an example of how to do things Elevator template is the starting point you should build on for the project Portfolio Overview e Design o Architecture Diagram The architecture diagram describes the objects present in the system the replication of di O Use Cases The use case diagram describes the ways that agents in the system can interact with the elevator anc O Scenarios and Sequence Diagrams Scenarios describe user interaction with the system Sequence diagrams de o Requirements I System Object Descriptions and Message Dictionary A list of the sensors and actuators in the o Requirements II Distributed Controller Requirements Detailed specifications for the all controllers in the syste1 Traceability Sequence Diagrams to Requirements Traceability Event Triggered forward and backward traceability from se m Note in the elevator project you will only have one Sequence Diagrams to Requirements Traceability do Proj4 are both inchided here in the example project to help make the complete process clear Sequence Diagrams to Requirements Traceability Time Triggered forward and backward traceability from se Requirements to Contstraints Traceability lt description here gt Statecharts to Code Traceability lt description here gt e Implementation o Elevator Control Package description here gt e Test Unit Test Log description here gt O Unit Test Summary File
16. ign process we ll be using for the course project Intro to Unified Modeling Language A standard representation for designs and implementations t s not perfect but it gets a lot of the job done Note we re not grading on nitty gritty language lawyer stuff but this helps give a uniform representation for class work Acomplete end to end example in the next lecture This lecture has some informalities to simplify things next lecture looks amp feels like project notation Important this course is about teaching survival skills not being an all encompassing tutorial on UML or many other subjects Note you are going to see some things multiple times These are the things some students struggled with in previous years we are only repetitive where we have good reason to be General Process Flow We re going to assume an iterated Vee process REQUIREMENTS S VALIDATION amp TRACEABILITY p ACCEPTANCE e Top down refinement KU WA p VERIFICATION amp SYSTEM e Front to back flow SPECIFICATION 7 777 aa a ka cried Review a RS Repeat cycle with MOE complex l Ecc VERIFICATION amp gs requirements after mid semester point 3g oso 77777 0007 TEST e icu Review EN VERIFICATION amp PROGRAM IRACEABILTY el PROGRAM SPECIFICATION TEST Real projects vary Review Reus p VERIFICATION amp e But the same representations are useful EDU ee eT UNIT TEST regardless of the sequencing
17. ments l pa 3 4 All passengers shall eventually be delivered to their intended destination floor Any unsafe condition shall cause an emergency stop An emergency stop should never occur Performance shall be optimized to the extent possible where performance is defined by the formula 4 average passenger delivery time maximum passenger delivery time Performance is improved by reducing that value short delivery times are better Delivery time is counted from the time a passenger arrives at a floor to begin a trip and ends when that passenger exits the elevator car Note this is an arbitrary formula for this project but the general idea holds true for real elevators What s an Architecture Architecture definitions e System The structure in terms of components connections and constraints of a product process or element Rechtin96 For our purposes an architecture is A set of objects Sensors Actuators Controllers The interfaces between those objects Network messages Analog interface pseudo messages Hardware Architecture Pattern For This Project Highly Distributed Networked System e Abstraction principle One sensor actuator or servo pair per CPU on a network e Bus interconnect Bus hierarchy may be needed to overcome bandwidth limits Pro doesn t prevent mapping to other architectures Can simply co locate code for multiple CPUs on a si
18. ngle hardware CPU Pro teaches you how to think distributed as you do the project Con bus can be a bottleneck CPU A SA SA O HA Software Architecture Pattern For This Project Object oriented Federated e Abstraction principle partition by data types hide data behind methods Note flow of control is completely obscured Pro helps with multi vendor mult subsystem integration compatible with CORBA Con can have high overhead to access data OBJECT BUS METHODS METHODS METHODS DATA DATA DATA Communication Architecture Pattern For This Project Global priority e Abstraction principle highest priority message delivered first Does NOT require a physical node to act as a queue fully distributed implementations are commonly used Represents CAN protocol Pro priority helps meet deadlines Con priority interferes with fairness NODE PRIORITY QUEUE NODE Control Architecture Pattern For This Project Federated Agents Blackboard e Abstraction principle each object has a control agent agents monitor and transmit global state information for coordination e Blackboard has shared state variables cd n BLACKBOARD SHARED GLOBAL lt STATE INFORMATION n LS N a Software Architecture UML Class Diagrams Used to show system in terms of objects attributes and relationships Objects are
19. nk ATMs But NOTE standard UML does not have any notion of Use Case order 2 A More Complete Example Scenario Summary Description e Open doors from within car Pre conditions e Passenger is in the car e Elevator has arrived at the desired floor but the passenger has not yet exited the car e Doors are fully open e The car call button for the current floor is not lit Scenario actions 1 Doors begin to close which will prevent passenger from exiting the car 2 Passenger s brain turns back on and s he presses car call button for current floor before doors are fully closed 3 Doors stop closing and reopens fully Post conditions e Passenger is still in the car e The doors are fully open e The car call button for the current floor is not lit a How Big Is A Use Case Revisited Using an elevator is a series of use cases Example hall call elevator moves to start floor doors open enter elevator car call doors close elevator moves to destination floor doors open exit elevator doors close Each use case has multiple scenarios almost always more than 1 e Scenarios within use case must have compatible pre amp post conditions Post conditions of one scenario need to match pre conditions of next scenario Thus use cases should be sized to manage complexity e Big enough use case to have a handful of reasonable scenarios e Split at natural breaking points to minimize of
20. nouns in the system Attributes are local state data within an object e This is sort of an architectural diagram Multiplicity Symbol Meaning patak 1 Exacily 1 widreciona o V 0 1 bidirectional is Build na ili T dani inclusive a b c Only specific values of a b and c T 0 or more 1 1 or more Rational For our purposes composition amp aggregation are the same thing Difference has to do with class instance dependencies that don t affect us Example Elevator Class Diagram Car Level Position Emergency 1 1 Sensor Brake x Safety Elevator Control System AtFloor Sensor 1 1 a 1 1 i 4 vv Hoistway Lirnit Sensor eodeni 1 Car Vveight Alarm all Button Contro ar Button Contra ar Position Contro Dispatcher 1 Drive pi ub Hall Button Car Button Car Lantern Car Position Indicator Poorconirfi Prive Conta 1 1 4 1 4 1 4 1 Door 1 4 1 1 Drive Speed Door Open Sensor Sensor 4 Door Closed Sensor Door Reversa Sensor ah ah Our Architecture Diagram Elevator Architecture Diagram revised 1 24 2011 Elevator Control System Co oor Reversa 4 3 Door Closed D 4 Door Opened 1 4 E CA 2 4 Car Position Control 1 1 4 kp r4 aaa pu FH BH At Floor CK Coriamem LaemCowa ee I 1 Car Level Position Ea 4 Car Weight Sends DesiredFloor f d and DesiredDwell b n kaan 1 Car Weight Alarm Hall
21. o On 7 2 If DesiredDirection is Stop both lanterns shall be set to Off Note this is a more convenient way to write two parallel cases for DesiredDirection Stop and not Stop for 7 2 It implicitly assumes that the triggering condition of mDoorClosed j k being False has been met 7 3 Any mDoorClosed j k true shall set CarLantern d to Off e Is there a behavior problem with above These requirements superficially seem to be contradictory Philosophical notes These requirements are really half way to implementation but that s good for our purposes because it makes them concrete You need detailed object interfaces amp message dictionary to do this Magic Formula for Behavioral Requirements Event driven system think interrupts e ZID message received shall result in messages transmitted and or variable values assigned Account for all possible messages received Account for all possible messages that need to be transmitted Make sure all variables are set as required OK to transmit multiple messages OK to set multiple variables OK to also use message received and variable X on left hand side of shall statement OK to use multiple variables on left hand side ONLY ONE received message per requirement network serializes messages simultaneous reception of multiple messages is impossible Time triggered system is different think polled I O
22. orMotor Close is a network message saying DoorMotor ordered to close DoorOpen False is a physical action saying passenger saw the door go to non Opened n the project we use nearly identical mechanisms to represent both keeps software environment simple a How Detailed Is A Scenario You can have a scenario that is a text version of the SD Hereis a very detailed scenario for the preceding SD L 2 S SS Door controller commands doors to close mDoorMotor Close message Doors begin to close DoorOpen sensor becomes False Passenger presses car call button for current floor before doors are fully closed CarCall f h button Pressed Car call button sends sensor CarCall message to car call button controller mCarC all f h Pressed message Car call button controller sends CarCall message to door controller mCarC all f h Pressed message Door controller commands doors to open mDoorMotor Open message Doors become fully open triggering mDoorOpen True message Passenger observes door fully open DoorOpen True Door controller commands doors to stop mDoorMotor Stop message 32 High Level Vs Low Level Scenarios You can use both high amp low level scenarios if you want High level scenarios are mandatory for project Each scenario step should have perhaps 1 to 3 arcs in SD Each scenario step typically involves a different actor or object initiating a set of rel
23. parseable list of unit test files Integration Test Log description here gt Integration Test Summary File parseable list of integration test files Acceptance Test Log lt description here gt Fault Tolerance Test Log omitted from example Log Files Issue Log lt description here gt Improvements Log lt description here gt e Scheduling Network Schedule description here gt Marketing Business Context Goal Build an elevator using distributed embedded system approach Note there is a lot of historical precedent for what it means to be an elevator e High level spec 1s make it act like the HH primary elevator except better In our role as the customer we require you to use e Our set of predefined components buttons lights etc Ourembedded network message types you can add some later e Our simulation framework in Java as the implementation platform Our design process General guidance e f in doubt make it act like the Hamerschlag Hall main elevator Butas long as satisfies project requirements OK to deviate from this Youcan add extra features later in project You can add network messages with our permission only n general you can NOT add extra system objects until after mid term because everyone in the past got themselves into trouble doing it 10 Top Level Product Requirements Elevator Top Level Require
24. rchitecture e English psuedocode behaviors of each architectural component Discussed in detail in the next lecture Usually in terms of how module or actuator behaves given a sensor input But we can abstract this as saying behavior in response to input messages Why this extra step It s not a UML diagram e Sequence diagrams look from the outside in Often there is a simpler way to do implementation than a case statement that handles each different scenario sequence diagram Think of this as looking from the inside out What software behaviors are required so that all the sequence diagrams work Sometimes simple behaviors suffice for complex interactions But we need this bridging step before jumping to design to also catch Things that it is supposed to not do or guarantee never happen Situations where order is unimportant or there are timing constraints Assumptions made in design that other modules have to respect Yes you can use ad hoc text boxes in UML diagrams but that s a mess 35 Example Elevator Behavioral Requirements 1 LanternControl d Replication How many are there and where are they Two controllers one for each lantern Up Down mounted in the Car Fach controller controls two lightbulbs in parallel one by each of the Car s front and back doors and actuates each front back pair of bulbs as a single actuator Instantiation What are settings at initialization when
25. rements emphasis on verbs Text Based Scenarios different scenarios for each use case e Sequence Diagrams graphical scenarios with emphasis on interaction messages Design Textual software requirements specification per module behaviors e State Charts state transitions Test Design Failure analysis covered later in semester Verification amp Validation Traceability Unittesting Integration testing Acceptance testing Why Not Just Write The Code That can work for up to perhaps 100 lines of code e Most embedded systems are a lot bigger e Most embedded systems have to be nearly perfect and on time e Problems tend to become exponentially worse with complexity program size e Chapter 2 in text talks about this The stakes are too high to get it wrong e But there are countless projects that do get it wrong With resultant loss of money jobs lives Example In July 1999 General Motors had to recall 3 5 million vehicles because of an anti lock braking software defect Stopping distances were extended by 15 20 meters Federal investigators received reports of 2 111 crashes and 293 injuries e http autopedia com html Recall GM072199 html Other care companies have recalls too GM is just an example Since then GM has been working on software quality and so have the others Project Template We provide you with a structured template for project information
26. ss things like performance as well for acceptance testing Short description of the environment of the test includes What level unit subsystem simulation What units included What resources needed simulation input files etc What setup is to be done for the test The test itself description of inputs actions in actual test Expected results Requirements verified Can more or less use this approach at each level of abstraction but no rigorous process available to do that 44 Three Types of Testing We ll Use Unit Test e Send messages at one object alone in simulation framework e See if response messages match expectations based on Statecharts Integration Test e Set initial conditions amp send messages to whole elevator e See if responses match expectations based on Sequence Diagrams Acceptance Test e Run elevator with passenger workload e See if responses match Use Cases amp end to end passenger delivery Quick Check What is the indirect relationship between Integration Tests and Use Cases e More than one At least one Exactly one integration test per use case 45 How The Real World Differs From Classwork 1 You have to create your own requirements e You aren t creating an answer you re solving an ill specified problem e Blaming the client for a defective problem statement is not an acceptable option 2 The world is not a tidy place e Requirements are imperfect and
27. ve you grief I forgot or I didn t read the assignment aren t acceptable excuses Neither is I ran out of time We strongly suggest your group meets on Friday after recitation to divide up work 49
Download Pdf Manuals
Related Search