Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Today: –Being Agile! –Part of the RAD – Use...

Fall 2015 CISC/CMPE320 - Prof. McLeod 1

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.


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.


Your Team

From this:


To this!:

See:

http://taswar.zeytinsoft.com/2011/01/25/starting-an-agile-team-to-become-the-a-team/

(Another) Cute Video

• Being Agile is Our Favourite Thing:

http://www.youtube.com/watch?v=ALWHCUNU8Nw



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.


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).


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.


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.


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.


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.


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:


• 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)


• 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.


• 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.


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.


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


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).


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 #included!).


textfileio.h, Cont.

• Note the use of const in the member function declaration:

vector<string> readFile() const;

• This contract promises that the member function will not change member variables (attributes).

• Optional, but good programming practice, particularly for accessors.


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!


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!


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.


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.


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.



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.


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. McLeod1 CISC/CMPE320 Today: –Being Agile! –Part of the RAD – Use...

Documents

Transcript of Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Today: –Being Agile! –Part of the RAD – Use...