Contact person: Rikard Land, 021-107035, 0735-636260 Responsible: Rikard Land Yue Lu Kristian Sandström Aneta Vulgarakis [This version of the file contains suggested answers, that should give highest points on each assignments. There may be many other ways to solve the assignments and get full point. In general, your answers must be realistic (for example, a project plan should contain realistic time allocated for project management, system integration & testing/validation even if this is not explicit in the assignment), you must also master the syntax used (for example, don t mix signals and conditions in a state chart!), and not incorrect (for example, a state chart that does not solve the problem stated in the assignment cannot give very many points), and that assumptions made are explicit or very easily understandable. ] All written material is allowed, e.g. text books, printouts of lecture slides, earlier exams (and solutions), and all own notes Max points: 40 Approved: Minimum 20 points Final Course Marks will be combined from the examination and the project: (40 points from examination + 40 points from the project) /2 Grade 5: 34 40p Grade 4: 28 33p Grade 3: 20 27p Observe, please: Write your name and personal number on every sheet Write on one side of the sheet only. Assumptions must be made when there is not enough information provided to solve an assignment, and all assumptions must be specified and explained in order to achieve full point. Page 1(12)
Assignment 1. Requirements/Use Case modelling (6p) In this assignment, you should model an aircraft boarding system by using UML Use- Case diagram. The following are the requirements on the system. 45 minutes before take-off, one channel is opened in the boarding gate for the business / 1 st class passengers. These passengers are informed by broadcasting by both airport TV and radio 30 minutes before take-off, an economy class channel is opened. and notify the boarding message to the economy class passengers by using both airport TV and radio. Meanwhile, keep the business / 1 st class channel open If all of the business / 1 st class passengers, who have already checked in their luggage, finish the boarding, that channel should be opened for the economy class passengers as well The passengers tickets and passports should be controlled, both in 1 st / business class channel and economy class channel. If there is something wrong, the problem should be solved without stopping boarding for the other passengers The number of passengers should never exceed the capacity of aircraft It is allowed to disembarking during the boarding Before the gate is closed and the aircraft takes off, passengers who have already checked in the luggage but not shown up at the boarding gate 15 minutes before take-off should be called for by broadcasting by both airport TV and radio The boarding gate should be closed 10 minutes before take-off. There are no set numbers; passengers are allowed aboard on a first-come-firstserved basis. Your task is to create a use case diagram with at least two actors (passenger, airways staff) and six scenarios. Please note that many use cases are probably not supported by a computerized system, you just need to describe who does what. No text description is needed, only a use case diagram (with descriptive names of the use cases). Page 2(12)
Suggested answer: Passenger boarding use case Page 3(12)
Airways staff use-case Page 4(12)
Assignment 2. Project Management (10p) You work in a project that will develop software for a series of washing machines. You have, together with your customer (the dishwasher manufacturer) defined the overall system requirements. You have agreed what buttons and displays there will be on the front of the washing machine, and you have defined a hardware abstraction layer is also defined to ensure portability to new hardware in the future (only one layer will need to be modified if the hardware is replaced). See the figure. There are three people (including yourself) working full-time in the project. Everyone can do any task in the project. Up to today (March 26 th ) you and your team have spent four weeks on agreeing on the system requirements with the customer, and you have estimated the development time for each part as follows is described in the notes in the figure. User Interface Internal design: 8 manweeks Implementation: 8 manweeks Test & Verification: 8 manweeks Control System Internal design: 8 manweeks Implementation: 8 manweeks Test & Verification: 8 manweeks Hardware Abstraction Layer Internal design: 8 manweeks Implementation: 8 manweeks Test & Verification: 8 manweeks You now have the option of selecting a development model for the rest of the project. For each of the following development models, define milestones and deliverables (with dates). Also describe briefly how each development model influence project risks and affects the ways you can collaborate with the customer. a) iterative (5p) b) incremental (5p) (Please note that no Gantt chart or resource allocation diagram is required, only lists of milestones and deliverables, plus discussions of risks and customer contact.) Hint for full points: also assume reasonable time estimates for other tasks not listed! Page 5(12)
Suggested Answer: Assumptions: We will consider that all the people are always working together on same task We assume that there will be spent 2 days monthly meeting on project management (in total 2 weeks for the whole project) We assume documentation of each task is included in the numbers given ITERATIVE DEVELOPMENT MODEL Assumptions for the iterative model: We will divide each task into 2 subtasks, e.g. Implementation consists of Implementation 1 and 2 Each subtask takes 4/3 calendar weeks (rounded in the list of milestones below) We will also assume that we need 6 manweeks (i.e. 2 calendar weeks) for integration testing, error corrections and validation for the whole system We perform two iterations, the first ending with a delivery of the basic functionality of each component (called version 0.5) and the last ending with delivery of the complete, validated system (called version 1.0) Milestones and deliverables: 4 th week: finished design 1 of UI and design 1 of CS and Implementation 1 of CS 8 th week: finished design1 of HAL, implemention1 of UI, testing1 of CS 13 th week: finished implementation 1 and testing 1 of HAL, testing 1 of UI Deliverable: System version 0.5 (subtask 1 finished for all components) 16 th week: finished design 2 of UI, CS, HAL 21 th week: finished implementation 2 of CS, HAL, testing 2 of CS 26 th week: finished testing 2 of HAL, implementation 2 of UI, testing 2 of UI. Deliverable: System version alfa (subtask 2 finished for all components) 28 th week: finished integration testing, user validation, correction Deliverable: System version 1.0 INCREMENTAL DEVELOPMENT MODEL Assumptions for the incremental model: Each task takes 8/3 calendar weeks, when multiplied with We assume that there will be spent 2 days monthly meeting on project management Page 6(12)
We assume that there is needed 2 weeks for integration testing and because the risk is very high at this development model, we will also add 2 weeks for debugging We argue that it is good to build the system bottom-up, i.e. the HW abstraction layer first; otherwise we would need to build some stubs in order to perform even the simplest tests of the upper layers. Milestones and deliverables: 8 th week: finished HW v 1.0 (design, implementation and testing of HW) Deliverable: HW v 1.0 17 th week: finished CS v 1.0 (design, implementation and testing of CS) Deliverable: CS v 1.0 26 th week: finished UI v 1.0 (design, implementation and testing of UI) Deliverable: System version alfa 28 th week: finished integration testing, user validation, correction Deliverable: System version 1.0 Risks In the iterative model we deliver the whole system halfway through the project, which makes it possible to show a complete system to the customer (although in prototype stage, i.e. without all functionality and not yet properly tested). This allows for feedback if the customer wants to change something (i.e. early customer validation); also, if the project is late after the first iteration the customer has the possibility to either drop some planned functionality for version 1.0, or allow a later delivery. With the incremental model, if the project is late nothing useful at all will be delivered by week 28, or we need to cut features of the components built in later phases (i.e. the UI and possibly the CS) but perhaps this is not the prioritization the customer would make. Another risk with the incremental model is that we might find in later stages that we need to change things in lower layers (e.g. the HW) because we need it in a higher layer (e.g. the CS). This means we have spent the time for e.g. the HW in a less than optimal way. At the end, we can perform a sanity check for the total time: 3 components * 3 tasks/components * 8 manweeks/task / 3 persons + 2 weeks for project management + 2 weeks validation & correction 28 weeks Summary: Both models should take ca 28 weeks, but the milestones/deliveries defined along the way are different, and the ways we can interact with the customer are different, which leads to different types of project risks and enable different ways to handle these risks. Page 7(12)
Assignment 3. Statechart Modelling & Safety Analysis (8p) In this assignment, you will model the behavior of the control system that lowers and raises the gate where a road crosses a railway. CT CT Far Train Passed Near Road Near Train Passed Far There are two sensors, e.g. Sensor One (left) and Sensor Two (right) respectively, telling the gate that a train is passed. This is a classical example of a real-time system, which we will only model very coarsely here, assuming that there is only a single track with only one train at a time and one gate in this assignment. However, a train could go in either direction. There are some specifications of the scenario following. When a sensor detects that a train passes, it will emit the signal Train Passed to the gate controller system, in order to make the gate start moving to the opposite direction to the previous one, e.g. from state up to state down We assume that the gate needs between 20 and 30 seconds to be lowered (to go from the state up to the state down) or be raised (to go from the state down to the state up) or to come down The gate cannot be moved when the train is passing. Otherwise, it will lead to tragedy Your task is to: a) model the system behavior by using UML State chart diagram. (4p) b) construct a fault-tree and use it to point out weaknesses of the system, and describe how the system could be improved to be more safe. (4p) Page 8(12)
Hints for Answer: a) You have two strong hints in the text: the two states up and down are mentioned, and the (only) signal in the system is specified: train passed. You could assume there is an overall train controlling system that will not allow two trains too close to each other. It is therefore possible to make a very simple state chart. Just make sure you use the correct syntax! b) The fault-tree should be syntactically correct and cover things such as power failure, sensor failure, communication failure, software failure, mechanical failure in gate. The resulting suggestions for improvements should be derived from the fault-tree (but some extra points were given if there were also separate suggestions for additional alarm systems and traffic signs). Page 9(12)
Assignment 4. Testing (8p) You are given a program that accepts 3 numbers as input (length of sides of triangle). The program output is taken from the set {Equilateral, Isosceles, Scalene, Invalid}. The program is supposed to choose the most specific descriptor. (i.e 2,2,2 should return Equilateral and 2,2,1 should return Isosceles.) You do not have the source code for this program. a) Is this a white box or black box testing? Explain. b) Name at least one advantage and one disadvantage of each approach. c) Why are both approaches necessary? Suggested Answers: a) It is a black-box testing since the tester only knows the legal inputs and what the expected results should be, but since there is no source code he doesn t know how the program arrives at those outputs. b) Advantages Disadvantages Black-box testing Efficient when used on larger systems The tester can be non-technical (doesn t need to have knowledge of any programming language) The tester doesn t need to have detailed functional knowledge of the system Test cases can be designed as soon as the functional specification is complete Writing test cases is slow and difficult (Difficult to identify all possible inputs in limited testing time) Chance of repetition of the tests that are already done by the programmer It is difficult to test all possible input streams, so many program paths will go untested White box testing Efficient when used on units Developer can reason carefully about implementation Reveals errors in hidden code Helps removing extra lines of code which can bring in hidden defects Expensive since a skilled tester is needed to carry out this type of testing It is almost impossible to look into every bit of code to find out hidden errors Page 10(12)
c) The black box testing is a testing against specification, and will discover faults which are result of not completely fulfilled specification On the other hand; white box testing is testing against the implementation and will discover faults if part of the implementation is faulty. In order to fully test the software product both black and white box testing are required. It is best to start with black box testing the product as soon as the specification is available. White box testing should commence as soon as all black box tests have been successfully passed. A failure of a white-box test may result in a change which requires all black-box testing to be repeated and white-box paths to be redetermined. Page 11(12)
Assignment 5. Real-Time System Design (8p) Most real-time systems control physical systems by observing (sampling) the system, calculating an appropriate response and output that response to the system (actuate). The resulting control performance will partly depend on the precision of the timing of sampling and actuation. Hence, timing is an important property is these systems. Consider the following questions regarding timing in real-time systems. a) Why it is necessary to consider timing variations in sampling and actuation respectively? Specify details about why and how control performance is affected by timing variations in sampling and actuation respectively. (4p) b) What in a computer system can cause these variations? Give three examples. (2p) c) What can be done to deal with variations in sampling and actuation? Do not repeat the answer to question b), but give details about how to actually make improvements. (2p) Suggested Answer not provided Page 12(12)