MSO Lecture 2. Wouter Swierstra (adapted by HP) September 14, 2017

Transcription

1 1 MSO Lecture 2 Wouter Swierstra (adapted by HP) September 14, 2017

2 2 LABS No lab partner? Speed dating in front of the blackboard during the break.

3 3 LAST LECTURE Overview of course: object oriented analysis and design. Recap: remind you of some object oriented terminology: inheritance polymorphism abstract classes interfaces

4 4 THIS LECTURE How can I manage the process of constructing complex software? How do I know what the customer wants?

5 5 SCIENTIFIC PROCESS In areas such as physics, there are fixed methodologies for experiments and measurements. This translates into concrete processes for in engineering disciplines, such as architecture. But what about Computer Science?

6 WATERFALL MODEL (ROYCE, 1970) 6

7 7 CRITICISM ON THE WATERFALL MODEL Traditionally, the waterfall model aims to complete every phase before moving on to the next. Critics complain that the waterfall model is not robust against change: A client can change his mind halfway through the project; The money can run out; A design can prove costly too implement; Many of the [system s] details only become known to us as we progress in the [system s] implementation. Some of the things that we learn invalidate our design and we must backtrack. David Parnas

8 8 ALTERNATIVE SOFTWARE DEVELOPMENT PROCESSES The spiral model (Boehm, 1988); Rapid Application Development; The (Rational) Unified Process; Agile development; extreme Programming;.. and many others. All these methods aim for a more incremental or evolutionary approach to software construction.

9 9 ABOUT SOFTWARE DEVELOPMENT PROCESSES Managing software development is a hard problem. But choosing a methodology is a bit like choosing an operating system or text editor: Each system is slightly different. There is no clear winner. There are zealous advocates for each system. My advice: Learn to apply one methodology really well. Don t get stuck in a rut stay hungry! Always choose the right tool for the job. More about software development processes in Software Project

10 10 THE UNIFIED PROCESS In this course, I want to focus mostly on one methodology and how it meshes with the ideas of object orientation; I will focus on the Unified Process (Jacobson, Booch and Rumbaugh, 1999) It is one of the most popular philosophies used today,... but it is not as cool as the more recent Agile/Scrum methodologies. Although it can be adapted to work together with such other methodologies.

11 11 THE UNIFIED PROCESS The Unified Process emphasises iterative software development. Develop software in time-boxed mini-projects called iterations. Each iteration has clearly defined milestones, including a tested, integrated, executable system.

12 12 ITERATIVE DEVELOPMENT PHILOSOPHY The iterative lifecycle is based on the successive enlargement and refinement of a system though multiple iterations with feedback and adaptation. The system grows incrementally over time, iteration by iteration. The system may take many iterations to be production ready (or ready for deployment).

13 13 ITERATIVE DEVOLPMENT IMPLEMENTATION The output of an iteration is not (just) an experimental prototype but a production subset of the final system. Each iteration tackles new requirements and incrementally extends the system. An iteration may occasionally revisit existing software and improve it.

14 14 EMBRACING CHANGE Stakeholders usually have changing requirements. End users; Project management; Upper management; Implementors; Testers;... Each iteration involves choosing a small subset of the requirements and quickly design, implement and testing them. This leads to rapid feedback, and an opportunity to modify or adapt understanding of the requirements or design.

15 15 UNIFIED PROCESS PHASES UP defines four different phases, each split into multiple iterations: Inception Define the scope of the project Elaboration Plan the project, specify features, baseline architecture Construction Finish the construction Transition Hand over the project to end users Each phase overlaps with some elements of the waterfall model, but the balance between them shifts as time passes.

16 16

17 17 THE UNIFIED PROCESS: BEST PRACTICES Develop software iteratively involve users early! Manage requirements Use component-based architectures Visually model software (UML) Verify software quality test, code reviews, release in every iteration Embrace change

18 18 THE UNIFIED PROCESS Today: I ll try to give an overview of the UP but applying the UP to your own projects is your responsibility. This session is mostly focused on the first two stages of the UP: Inception and Elaboration.

19 INCEPTION 19

20 20 INCEPTION Envision the product scope, vision, and business case. Upon completion, the stakeholders have a basic agreement on the vision of the project and are able to decide whether to continue or not. It typically only lasts a few weeks.

21 21 INCEPTION: ARTIFACTS A vision document what is the general vision of the project? What are the key features and constraints? A initial list of use-cases how will end-users interact with the system? An initial project glossary what is some of the domain specific lingo? An initial business case how will we make money? An initial risk assessment what might go wrong? A project plan, showing phases and iterations how will we move forward? One or several prototype experiments.

22 22 WHAT INCEPTION IS AND IS NOT It s not about deciding how many weeks feature X will take to implement. You need a ballpark estimate: 1 month or 1 year? 1M or 10K euros?

23 23 WHAT INCEPTION IS AND IS NOT It s not about identifying every possible interaction that every imaginable user can have with your system. You want to have an idea of which people will end up using the system. You should have a few carefully thought out use cases.

24 24 WHAT INCEPTION IS AND IS NOT It s not about choosing the color of the icon, which GUI library to use, or which operating system to support. You do want to think about whether it will run on tablets, mobile phones, desktops, or in the cloud.

25 25 ABOUT RISK It can be very hard to identify where the risk lies in any project: Example: changing the limit on a creditcard. Example: restaurant matching website;

26 ELABORATION 26

27 27 ELABORATION: GOALS Analyze the problem domain, establish an architectural foundation, develop a project plan, and eliminate highest risks. You need to develop a mile high and inch deep view of the system; Now is the time to make architectural decisions. Build an executable architecture prototype, thereby eliminating critical risk, for the central use cases developed in the Inception phase. Note: you should start building a prototype early, even if the requirements have not been finalized yet.

28 28 ELABORATION: ARTIFACTS A use-case model describing how users will interact with the system; Supplementary requirements capturing the non-functional requirements; A Software Architecture Description. An executable architectural prototype. A revised risk list and a revised business case. A development plan for the overall project, including the coarse-grained project plan, showing iterations and evaluation criteria for each iteration.

29 29 ELABORATION OUTCOMES A stable vision of the software system and its architecture; Minimized the risks that could cause the project to fail if you choose to continue. Better estimates for project costs and planning.

30 CONSTRUCTION 30

31 31 CONSTRUCTION: GOALS The main goal of the construction phase is to develop and test a baseline product. Upon completion, there should be a clear description of the product status, together with user manuals. The tool should be ready to be deployed even if not all features are fully implemented.

32 TRANSITION 32

33 33 TRANSITION The transition aims to deliver the first version of the software to its users. Beta testing; Training of new users and maintainers; Operating in parallel with existing legacy systems; Conversion of data bases;... This process usually involves a lot of tuning, bug-fixing, processing enhancement requests, and implementing unfinished features.

34 34 TRANSITION: GOALS Enabling users to use your product; Achieving consensus with all stakeholders that the baseline product is complete; Iteratively refining the baseline until the final product is implemented.

35 35 WORKFLOWS UP identifies six distinct kinds of engineering activity : 1. Business modeling 2. Requirements 3. Analysis & Design 4. Implementation 5. Test 6. Deployment And three kinds of supporting activity: 1. Project Management workflow 2. Configuration and Change Management 3. Environment: development kit, tools for building and process control I want to focus on the first three engineering activities.

36 36 Business Modeling aims to document existing business processes to establish a common understanding between various stakeholders about how the organization works. Requirements Engineering aims to describe what the system should do, allowing customers and developers to agree on that description. Analysis and Design aims to describe how the system should be implemented, in accordance with the requirements it should satisfy.

37 37 REQUIREMENTS WHY? Software errors cost the American economy about $60 billion each year. 84% of all software projects are unsuccessful (late, over budget, cancelled, etc.) Three of the top reasons for failure: Poor user input 13% Incomplete requirements 12% Changing requirements 7% Requirements are really important!

38 38 STAKEHOLDERS AND CONCERNS Requiremenst should identify relevant stakeholders and concerns. A stakeholder is a person, group, or entity with an interest in or concerns about the realization of the architecture. A concern is a requirement, an objective, an intention, or an aspiration a stakeholder has for that system.

39 REQUIREMENTS 39

40 40 REQUIREMENTS DEFINITION A requirement is a feature that a system must have or a constraint it must satisfy to be accepted by the client. Requirements engineering is the process of identifying and defining the requirements of a software system. Requirements engineering is a cyclic process: 1. Elicitation 2. Specification (e.g. use cases, scenarios) 3. Validation and verification 4. Negotiation

41 41 REQUIREMENTS EXAMPLES Requirements come in all kinds of shapes and sizes: Functional features, capabilities Usability help, documentation Reliability frequency of failure, uptime, recoverability Performance response time, accuracy, throughput Supportability adaptibility, maintainability But also sub-factors such as: Implementation languages and tools, hardware Legal licensing Interface constraints arising from other systems

42 42 REQUIREMENTS HOW? Many customers have little technical skill. Or they may not even know what they want themselves. How can you figure out what they want? Eliciting clear requirements is not as easy as you may think... (Example from O Reilly s Head First Object-Oriented Analysis and Design).

43 43

44 44

45 45

46 46 EASY SPEC Push the button on the remote to open the door; Push the button on the remote to close the door.

47 47 INITIAL DESIGN DogDoor class method Open method Close method WaitForRemote Remote class tell the DogDoor to open and close knows when the button is pressed.

48 public class DogDoor { private boolean open; public DogDoor() { this.open = false; } public void open() { Console.WriteLine("The dog door opens."); open = true; } public void close() { Console.WriteLine("The dog door closes."); open = false; } } public boolean isopen() { return open; } 48

49 public class Remote { private DogDoor door; public Remote(DogDoor d) {... } } public pressbutton () { if door.isopen() { door.close() } else { door.open() } } 49

50 50 WHAT ELSE? This defines the core class files; (I m ignoring the interface to the door s hardware.) Perhaps we should write some tests?

51 public class DogDoorSimulator { public static void main(string[] args) { DogDoor door = new DogDoor(); Remote remote = new Remote(door); Console.WriteLine("Fido barks to go out."); remote.pressbutton(); Console.WriteLine("\nFido has gone."); remote.pressbutton(); Console.WriteLine("\nFido's all done."); remote.pressbutton(); } Console.WriteLine("\nFido's back inside."); remote.pressbutton(); 51

52 52 SO WE RE DONE! We ve talked to our customer to establish some requirements; We have implemented a system that satisfies these requirements; We ve tested that our system behaves as expected.

53 53

54 54 WHAT WENT WRONG? We implemented what we were asked; The hardware works; The software works; Our testsuite passes. Getting the requirements right is not just the customer s responsibility!

55 55

56 56 BUT WHAT IF... Question: What else could possibly go wrong?

57 57 BUT WHAT IF... Fido does not bark to go outside? Todd and Gina don t hear Fido barking? Fido is barking, but does not want to go outside? the door is closed before Fido returns? the door jams? the door closes as Fido is going outside?...

58 58 WHY THIS EXAMPLE IS IMPORTANT The implementation of the DogDoor is super simple it is essentially a single boolean. But figuring out what the customers want is really hard! How can we figure out what the customer wants?

59 59 FINDING REQUIREMENTS Elicitation talk to clients and end-users; gather existing documentation; observe how future users work now. But be careful: Customers can check bank balances but only their own! A grade above 6.0 is a pass but so is a 6.0! Every telephone number starts with an area code unless it s for a cell phone.

60 60 ELICITATION TECHNIQUES - I Asking: What do you expect from the system? Interview, brainstorm, questionnaire,... Task analysis: Which subtasks can you identify? How can you organize tasks into a hierarchy?

61 61 ELICITATION TECHNIQUES - II Scenario-based analysis How do you do Y? But what happens if...? Ethnography Actively observing users do their work May be more reliable than asking them.

62 62 ELICITATION TECHNIQUES - III Analyzing existing documents and systems What problems do the existing systems have? Prototyping is this what you had in mind? Domain analysis - how are other systems in this domain built?

63 63 WHAT MAKES A GOOD SET OF REQUIREMENTS? Correctness: it accurately captures the client s views Consistency: it does not contradict other requirements Completeness: all possible scenarios are accounted for Clarity: unambiguously formulated Realism: it can be implemented and delivered Verifiability: it can be (automatically) tested

64 64 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people.

65 65 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear.

66 66 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear. Better: All text should be in at least 14pt font.

67 67 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear. Better: All text should be in at least 14pt font. Upon completion, the final product shall not have any errors.

68 68 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear. Better: All text should be in at least 14pt font. Upon completion, the final product shall not have any errors. Not verifiable and not realistic.

69 69 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear. Better: All text should be in at least 14pt font. Upon completion, the final product shall not have any errors. Not verifiable and not realistic. Better: give specific test criteria.

70 70 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear. Better: All text should be in at least 14pt font. Upon completion, the final product shall not have any errors. Not verifiable and not realistic. Better: give specific test criteria. The product shall respond rapidly.

71 71 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear. Better: All text should be in at least 14pt font. Upon completion, the final product shall not have any errors. Not verifiable and not realistic. Better: give specific test criteria. The product shall respond rapidly. Not verifiable and unclear.

72 72 EXAMPLES OF POOR REQUIREMENTS The system should be usable by elderly people. Not verifiable and unclear. Better: All text should be in at least 14pt font. Upon completion, the final product shall not have any errors. Not verifiable and not realistic. Better: give specific test criteria. The product shall respond rapidly. Not verifiable and unclear. Better: The system shall respond in less than 2s.

73 73 NOT ALL REQUIREMENTS ARE CREATED EQUALLY Everyone wants a system that is up 24/7, is easy to take down for maintainence, cheap to implement, immediately responsive, and that looks pretty. Trying to identify what is really important can save you a lot of development time down the road.

74 74 REQUIREMENTS ARE NOT A WISH LIST In the Software Project that CS students do in to complete their BSc, many students make the same mistake: Requirements are not a wish list Requirements are a contract for the minimal functionality that you can promise to deliver.

75 75 TRY DIFFERENT TECHNIQUES The more information you have, the better you understand the domain, the better you can write and prioritize your scenarios, the greater the chance of success.

76 76 SCENARIOS AND USE CASES One of the most popular way to establish (functional) requirements is through writing scenarios and use cases. These document the system s behaviour from the users point of view, in a way that customers can understand what the system does how does the system add value to the user? Use cases and scenarios are crucial if you want to agree on what the system does.

77 77 SCENARIOS: DEFINITION A narrative description of what people do and experience as they try to make use of computer systems and applications (M. Carroll, 1995)

78 78 SCENARIO: EXAMPLE Alice goes to the cash machine; She enters her card and PIN; She requests to see her bank balance and withdraws 20 euro. She takes her money, card and a printed receipt. Note that: This only describes a single transaction it does not capture all possible interactions or all possible outcomes. The actors involved may be people, systems, or even organizations.

79 79 USE CASES DEFINITION A use case is more general than a scenario. It documents an interaction between users and the system that yields an observable result or value. When writing use cases, many authors distinguish different levels: Brief a one paragraph summary of the main success scenario; Casual a few paragraphs that cover various scenarios; Full dressed a detailed account of all possible steps and variations, including entry conditions, exit conditions and special requirements.

80 80 USE CASES: BRIEF Bank Customers should be able to go to the ATM and withdraw money from their account. To do so succesfully, they start by identifying themselves using their PIN and bank card. After selecting the account from which they wish to withdraw money, the necessary information is transmitted to the bank. Once the bank verifies that there is sufficient money in the account, the money is dispensed, together with the bank card and a receipt.

81 81 USE CASES: CASUAL Give a brief account several different scenarios: What if the PIN number is wrong? What if the ATM is out of money? Or cannot dispense the requested amount? What if the user does not have enough money on his account?...

82 82 WHAT TO WRITE? A fully dressed use case consists of: A unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements This general format was originally suggested by Alistair Cockburn and is used throughout Larman s Applying UML and Patterns.

83 83 EXAMPLE: WITHDRAWING MONEY 1 Brief Description This use case describes how the Bank Customer uses the ATM to withdraw money to his/her bank account. 2 Actors Bank Customer and Bank 3 Entry conditions There is an active network connection to the Bank. The ATM has cash available.

84 84 EXAMPLE BASIC FLOW OF EVENTS 1. Bank Customer inserts their Bank Card. 2. Use Case: Validate User is performed. 3. The ATM displays the different alternatives that are available on this unit. In this case the Bank Customer always selects Withdraw Cash. 4. Card ID, PIN, amount and account are sent to Bank as a transaction. The Bank Consortium replies with a go/no go reply telling if the transaction is ok. 5. The Bank Card is returned. 6. The money is dispensed. 7. The receipt is printed. 8. The use case ends successfully.

85 85 ALTERNATIVE FLOWS 1 Invalid User If in step 2 of the basic flow Bank Customer the use case: Validate User does not complete this successfully, then: 1. The use case ends with a failure condition. 2 Insufficient cash If in step 5 in the basic flow, the Bank Customer enters an amount that exceeds the amount of cash available in the ATM, then 1. The ATM will display a warning message, and ask the Bank Customer to reenter the amount. 2. The use case resumes at step 5.

86 86 3 No response from Bank If in step 6 of the basic there is no response from the Bank within 3 seconds, then 1. The ATM will re-try, up to three times. 2. If there is still no response from the Bank, the ATM shall display the message Network unavailable try again later. 3. The ATM shall return the card. 4. The ATM shall indicate that it is Closed. 5. The use case ends with a failure condition.... and lots more can go wrong

87 87 EXIT CONDITIONS 7 Post-conditions 7.1 Successful Completion The user has received their cash and the internal logs have been updated. 7.2 Failure Condition The logs have been updated accordingly. 8 Special Requirements [SpReq:WC-1] The ATM shall support localizations for all major European languages. [SpReq:WC-2] The ATM shall keep a log, including date and time, of all complete and incomplete transactions with the Bank.

88 88 USE CASES ADVICE Don t think about implementation or user interfaces; Do think about user experience. Keep the writing as simple as possible you re not writing a novel or academic textbook, but a piece of text that should be as unambiguous as possible.

89 89 USE CASES DIAGRAMS Sometimes it can be useful to visualize which actors interact during certain use cases. In that case, it can help to draw UML use case diagrams.

90 90 UML USE CASE EXAMPLE Withdraw Client

91 91 Web shop Client Process sale Authorization server VAT Calculator Change password

92 92 ELEMENTS OF UML USE CASE DIAGRAMS System Actor Use Case <uses> <extends>

93 93 DIAGRAMS Actors may be users, other stakeholders, or even software systems; You may want to organize actors or use cases into system boxes. You can re-use use cases using the <<uses>> arrows for instance, both cash withdrawal and changing your PIN code require some form of authentication. You may want to identify special cases of a given use case, using <<extends>> arrows for example, to distinguish Assign Window Seat and Assign Aisle Seat are both extensions of the Assign Seat use case.

94 94 Airline system Check in Customer Ticket clerk Book tickets

95 95 DETAILED VIEW Check in Assign aisle seat <uses> <uses> <extends> Weigh luggage Assign seat <extends> Assign corridor seat

96 96 REQUIREMENT VERIFICATION AND VALIDATION Requirements validation is concerned with checking the requirements document for consistency, completeness, and accuracy. Requirements verification is a mathematical analysis, possibly automated, of formal specifications for consistency

97 97 TECHNIQUES You need to interact with users and customers to validate your requirements. Reviews, checklists, discussion Prototypes Animations

98 98 REQUIREMENTS NEGOTIATION Usually, there are constraints that limit the functionality that can be delivered (time, money, resources,... ) Or there are conflicting requirements between different stakeholders. To establish a sensible set of requirements requires negotiation with your customer.

99 99 BACK TO UP EXAMPLE PLANNING Inception start with a two day workshop with all stakeholders aimed at inventorizing use cases, and writing a brief description of each one. Elaboration (first iteration) work out key use cases in greater detail and discuss these with the client. design high-risk architectural components start implementation. As iterations proceed, more use cases are developed, together with the prototype system. There are regular checks with the customer to check that they agree with existing requirements and the prototype system.

100 100 THIS LECTURE How can I manage the process of constructing complex software? Use the Rational Unified Process, or any other software development process. How do I know what the customer wants? Write use cases and requirements documents.

101 101 UP VS AGILE The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

102 AGILE SOFTWARE DEVELOPMENT WITH SCRUM 102

103 103 MATERIAL COVERED Rational Unified Process Whitepaper available on the MSO website. Craig Larman. Applying UML and Patterns. Pearson Education Chapters 1 7.

104 104 LAB EXERCISE Write a requirements document for the Submit System that allows students to submit their code to the University servers. Study relevant sections of Larman s Applying UML and patterns. Identify actors and stakeholders involved; Identify key use cases and giving a casual description; Write a fully-dressed specification for the Submit use case; Write non-functional requirements in a Supplementary Specification. All lab assignments should be done in pairs.