Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Today: –Being Agile! –Part of the RAD – Use Cases. –(If we have time) Review what we did last time and add an exception class. (Which completes all you need to know for the first assignment.)

Agile Teams – Important Characteristics Small team, skilled, experienced, able to co-exist. Minimal management. Strange work hours! Coding, design, testing all at the same time. Frequent (nightly?) builds. Many short efficient meetings (SCRUMs). Absolute reliance on CASE tools. Rapid prototyping to demonstrate to client/user. Frequent input/changes from client/user who may even be a team member. Fall 2015CISC/CMPE320 - Prof. McLeod2

Agile Teams, Cont. Compared to earlier, classical project teams: –Smaller. –Less formal. –Less time spent on documentation. –More effective in a shorter time – more people coding. But: –When an Agile team goes wrong – they go really wrong! –Results from a lack of all the formal checks and balances of a more “formal” approach. –Difficult to tell when things go wrong. Little accountability. Often have to start again. Fall 2015CISC/CMPE320 - Prof. McLeod3

Your Team From this: Fall 2015CISC/CMPE320 - Prof. McLeod4 To this!: See: /25/starting-an-agile-team-to- become-the-a-team/

(Another) Cute Video Being Agile is Our Favourite Thing: Fall 2015CISC/CMPE320 - Prof. McLeod5

Fall 2015CISC/CMPE320 - Prof. McLeod6 Getting Started on Design At first, don’t worry about implementation details! Get a vision of what you want to do. Can you describe your project in a couple of sentences – that everyone agrees on? (A “Vision Statement”). Next, imagine you are using your “whatever-it-is”: –What is it going to do? Keep the “big picture” in mind. –Any ideas on how to handle the “but-what-ifs”? Document these scenarios. If you can, sketch the operation or look of your thing.

Fall 2015CISC/CMPE320 - Prof. McLeod7 Identify the Actors An Actor is the type of user who is using your “thing”. Does your “thing” require different kinds of users (players, admin, maintenance, for example).

Fall 2015CISC/CMPE320 - Prof. McLeod8 Collect Scenarios A scenario is just a “vision” (a story!) of how the user will interact with the system –You could have a whole bunch of these things, like plots for commercials. –Written in plain English.

Fall 2015CISC/CMPE320 - Prof. McLeod9 Next Step Once all agree on a complete set of scenarios: Identify use cases. A use case is a more abstract description that can cover an entire set of the more concrete scenarios. Still written in plain English. All scenarios should be included in use cases – this determines the scope of the system.

Fall 2015CISC/CMPE320 - Prof. McLeod10 Next Refine the use cases: –Add detail. –Make sure they are complete. –Add error conditions and exceptional circumstances. Identify relationships between use cases: –Identify dependencies. –Factor out common functionality.

Fall 2015CISC/CMPE320 - Prof. McLeod11 Next Everyone agrees on the non-functional requirements: Not directly related to the functionality of the system. Things like: performance constraints, documentation, resources, security and quality.

Fall 2015CISC/CMPE320 - Prof. McLeod12 An Example FRIEND – a “distributed information system for accident management”. Ref: Brugge, O’Toole & Rothenburger in Proc. Second Int. Conf. on Cooperative Information Systems, pp 90 – 100, (May, 1994) Used by emergency response personnel (policemen, firefighters, etc.) to communicate an incident to a dispatcher. The system also records the incident and response. Show a scenario, then a use case:

Fall 2015CISC/CMPE320 - Prof. McLeod13 Scenario Name: WarehouseOnFire Participating Actors: –Bob, Alice:FieldOfficer –John:Dispatcher Flow of Events: 1.Bob, driving down Main St. in his patrol car notices smoke coming out of a warehouse. Alice, his partner activates the “Report Emergency” function from her FRIEND laptop. 2.Alice enters the building description and location as well as the emergency level. She requests fire response and paramedics, since there seems to be many people in the area. She confirms her inputs and waits for a response. 3.John hears a beep at his workstation, views Alice’s submission and sends an acknowledgment. He allocates a fire “unit” and 2 ambulances to the Incident site and sends their ETA to Alice. 4.Alice receives the ETA and sends an acknowledgement. (John is an “instance” of Dispatcher)

Fall 2015CISC/CMPE320 - Prof. McLeod14 Use case name: ReportEmergency Participating Actors: –Initiated by FieldOfficer –Communicates with Dispatcher Flow of Events: 1.FieldOfficer activates “Report Emergency” function on her laptop. 2.FRIEND responds by presenting a form to the FieldOfficer. 3.FieldOfficer provides a description of the situation, the emergency level, location, and the type of emergency, along with possible responses. Once complete, the FieldOfficer submits the form. 4.FRIEND receives the form and notifies the Dispatcher. 5.Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher selects a response and acknowledges the report. 6.FRIEND displays the acknowledgement and response to the FieldOfficer.

Fall 2015CISC/CMPE320 - Prof. McLeod15 Entry Condition: –The FieldOfficer is logged into FRIEND. Exit Conditions: –The FieldOfficer has received an acknowledgement and the selected response from the dispatcher, OR –The FieldOfficer has received an explanation of why the transaction could not be processed. Quality Requirements: –The FieldOfficer’s report is acknowledged within 30 seconds. –The selected response arrives no later than 30 seconds after it is sent by the Dispatcher.

Fall 2015CISC/CMPE320 - Prof. McLeod16 Use Case Example This use case could cover many different emergencies from WarehouseFire to FenderBender. A more dire emergency (like Earthquake) might merit some additional notifications by the FieldOfficer, so it might need a different use case. Other possible use cases: OpenIncident, AllocateResources, ViewMap and ConnectionDown.

Fall 2015CISC/CMPE320 - Prof. McLeod17 Use Cases A use case is initiated by an actor, and should be described from the perspective of the actor. The name of the use case should be a verb/noun combination. The “Quality Requirements” section gives you a chance to collect non-functional requirements. Many other sections could be used. Should be less than 2 or 3 pages in length, or else create relationships (“include” or “extend”) to break a large use case into smaller use cases.

Last Time - File I/O Demo as a Class Restrucure TextIODemo.cpp by separating out a header file and an implementation file. Might as well make a simple class out of the result. See: –textfileio.h –textfileio.cpp –TestFileIOClass.cpp Fall 2015CISC/CMPE320 - Prof. McLeod18

Header File - textfileio.h This header file only contains the declaration of the TextFileIO class, but it could also have contained: –enums –structs –non-member function prototypes –other class declarations –constants –documentation Putting any implementation in the header file is poor structure (and poor style). Fall 2015CISC/CMPE320 - Prof. McLeod19

Declaration in Separate File Now, the implementation can be completely hidden from anyone using your class. You should be able to use the class without knowing anything about the implementation! Provided your structure does not change, changing implementation minimizes build time as only that file needs to be re-compiled (the implementation file is not #include d!). Fall 2015CISC/CMPE320 - Prof. McLeod20

textfileio.h, Cont. Note the use of const in the member function declaration: vector readFile() const; This contract promises that the member function will not change member variables (attributes). Optional, but good programming practice, particularly for accessors. Fall 2015CISC/CMPE320 - Prof. McLeod21

textfileio.h, Cont. #pragma once ensures that the declarations in this file will only be made once. The *.h file will be included in any file that is going to use this class using: #include "textfileio.h" You can have as many of these #includes as you want in a project without worry! Fall 2015CISC/CMPE320 - Prof. McLeod22

Class Declaration The public: and private: sections control access to class members from instantiations. As you would expect, encapsulation dictates that your attributes are declared in the private: section! Fall 2015CISC/CMPE320 - Prof. McLeod23

Implementation File – textfileio.cpp Has the same name (different extension) as the header file, by convention. Implements member and non – member functions. Few comments, or just comments for the developer. Users are not going to see this file. Fall 2015CISC/CMPE320 - Prof. McLeod24

textfileio.cpp, Cont. The constructor: TextFileIO::TextFileIO(const string& fname) : filename(fname) {} Note the “shortcut” notation in the initialization section. You can still do things the old-fashioned way, especially if you are going to check the arguments for legality. Fall 2015CISC/CMPE320 - Prof. McLeod25

textfileio.cpp, Cont. Also note the membership operator :: It allows you to associate the member with the class. You can implement members or non-member functions for any header file that you have included. Fall 2015CISC/CMPE320 - Prof. McLeod26

Fall 2015CISC/CMPE320 - Prof. McLeod27 Aside - private Members Member function definitions and their implementations can access private members – even if this is in a different file. Non-member functions cannot access private members, only public ones.

TestFileIOClass.cpp Some class in your project must have a main function, or your application will not run. (But only one main function per project!) TextFileIO is instantiated on the run-time stack (more about this later) in the usual way. You can only access public: members from here. Fall 2015CISC/CMPE320 - Prof. McLeod28

Default Constructors Invoked without parameters. If we had one for TextFileIO it would be invoked as: TextFileIO test; No round brackets! What does: TextFileIO test(); look like to you? Fall 2015CISC/CMPE320 - Prof. McLeod29