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.

Slides:



Advertisements
Similar presentations
Requirements Elicitation Labs Discussion p2 T120B pavasario sem.
Advertisements

Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 ECE.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Winter 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 2 due today. Assignment 3 is a GUI – posted soon. Due the end of next week. Project work.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Chapter 4, Requirements Elicitation
Requirements Elicitation Chapter 4. Establishing Requirements Two questions –What is the purpose of the system –What is inside and what is outside the.
Use Cases Chapter 4. After Scenarios Find all the use cases in the scenario that specifies all possible instances of how to report a fire –Ex: “Report.
CS 201 Functions Debzani Deb.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
An Introduction to Use-Case Modeling
INTROSE Introduction to Software Engineering Raymund Sison, PhD College of Computer Studies De La Salle University Analysis Modeling.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Functional Modeling.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
Requirements Elicitation Labs Discussion p2 T120B pavasario sem.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
Using UML, Patterns, and Java Object-Oriented Software Engineering Functional Modeling.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
ADTs and C++ Classes Classes and Members Constructors The header file and the implementation file Classes and Parameters Operator Overloading.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
Copyright © 2002 W. A. Tucker1 Chapter 10 Lecture Notes Bill Tucker Austin Community College COSC 1315.
Chapter 10: Classes and Data Abstraction. Objectives In this chapter, you will: Learn about classes Learn about private, protected, and public members.
EGR 2261 Unit 11 Classes and Data Abstraction  Read Malik, Chapter 10.  Homework #11 and Lab #11 due next week.  Quiz next week.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 1 due today, 7pm. RAD due next Friday in your Wiki. Presentations week 6. Today: –Continue.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 RAD due Friday in your Wiki. Presentations week 6 – next week. Schedule on next slide. Today: –Operator.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Project Wikis are private again. Assignment 3 is posted. Due Nov. 6. SDD framework must be in place.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 1 due tomorrow, 7pm. RAD due next Friday in your Wiki. Presentations week 6. Tomorrow’s lecture.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Lecture Videos will no longer be posted. Assignment 3 is due Sunday, the 8 th, 7pm. Today: –System Design,
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Today: –Review declaration, implementation, simple class structure. –Add an exception class and show.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Managers and “mentors” identified on projects page. All member accounts created and projects populated.
Slide 1 Chapter 6 Structures and Classes. Slide 2 Learning Objectives  Structures  Structure types  Structures as function arguments  Initializing.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 3 is due Sunday, the 8 th at 7pm. Problems with assn 3? Discuss at your team meeting tonight.
Chapter 10: Classes and Data Abstraction. Classes Object-oriented design (OOD): a problem solving methodology Objects: components of a solution Class:
Today… Modularity, or Writing Functions. Winter 2016CISC101 - Prof. McLeod1.
1 After the scenarios are formulated Find all the use cases in the scenario Describe each of these use cases in more detail Participating actors Describe.
Today Encapsulation. Build a fully encapsulated Halloween class, going from Halloween1 to Halloween6 (eventually!): –The final version will have overloaded.
ENCAPSULATION. WHY ENCAPSULATE? So far, the objects we have designed have all of their methods and variables visible to any part of the program that has.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Functional Modeling.
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 4, Requirements Elicitation: Functional Modeling
Functional Modeling.
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CMPE212 – Stuff… Exercises 4, 5 and 6 are all fair game now.
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 4, Requirements Elicitation: Functional Modeling
Fall 2018 CISC124 12/3/2018 CISC124 or talk to your grader with questions about assignment grading. Fall 2018 CISC124 - Prof. McLeod Prof. Alan McLeod.
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 4, Requirements Elicitation: Functional Modeling
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
CISC/CMPE320 - Prof. McLeod
Fall 2018 CISC124 2/24/2019 CISC124 Quiz 1 marking is complete. Quiz average was about 40/60 or 67%. TAs are still grading assn 1. Assn 2 due this Friday,
CISC/CMPE320 - Prof. McLeod
Chapter 4, Requirements Elicitation: Functional Modeling
CMPE212 – Reminders Assignment 3 due next Friday.
CMPE212 – Reminders Quiz 1 marking done. Assignment 2 due next Friday.
Chapter 4, Requirements Elicitation: Functional Modeling
CMPE212 – Reminders Assignment 2 due next Friday.
Presentation transcript:

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