CSC 301H, Introduction to Software Engineering Fall 2009 TA Golnaz Elahi

Slides:



Advertisements
Similar presentations
500 for 2 Enjoy your favourite card game with only 2 players 500 for 2
Advertisements

Use-Cases.
Use cases Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself A set.
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.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Chapter 15: System Modeling with UML
Chapter 4, Requirements Elicitation
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.
1 Real-time requirements  Intro to Software Engineering  Software Development Process Models  Formal methods in software specification  Structured.
CIS101 Introduction to Computing Week 11. Agenda Your questions Copy and Paste Assignment Practice Test JavaScript: Functions and Selection Lesson 06,
Sharif University of Technology1 Design and Use-case Realization Software Engineering Laboratory Fall 2006.
VOCABULARY  Deck or pack  Suit  Hearts  Clubs  Diamonds  Spades  Dealer  Shuffle  Pick up  Rank  Draw  Set  Joker  Jack 
The chapter will address the following questions:
Sequence Diagram Tutorial
Starting Chapter 4 Starting. 1 Course Outline* Covered in first half until Dr. Li takes over. JAVA and OO: Review what is Object Oriented Programming.
System Sequence Diagrams
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
Systems Analysis and Design in a Changing World, Fifth Edition
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Functional Modeling.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Business Analysis and Essential Competencies
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
Using UML, Patterns, and Java Object-Oriented Software Engineering Functional Modeling.
Learning to Play KardKuro Goals: Have Fun while Practicing Addition and Subtraction. Improve Social Learning Opportunities with Classmates. Become familiar.
Math Games Compiled By: Joan Bartlett and Heather Bartlett.
Object-Oriented Software Development F Software Development Process F Analyze Relationships Among Objects F Class Development F Class Design Guidelines.
For accurate communication, since a project can have several participants, each from different background. Represent a given aspect of the system We will.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
UML January 26, 2011 CSE 403, Winter 2011, Brun UML Sequence Diagrams.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
©2009, Tom McKendree Biplanes ©2009, Tom McKendree.
CSC172 Class Design Pepper. Goals How to design classes How to think in terms of objects StarUML Code Generation.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
5 Systems Analysis and Design in a Changing World, Fifth Edition.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
Use Cases Use Cases are employed to describe the functionality or behavior of a system. Each use case describes a different capability that the system.
CSC480 Class Design Pepper. Goals How to design classes StarUML Code Generation.
Design Model Lecture p6 T120B pavasario sem.
 Week08.  Review Schedule Weeks 8-14  This week o Review last class o Introduce Class Diagrams o ICE-03 Sheridan SYST Engineering Quality Systems.
ITEC324 Principle of CS III Chapter 2 (Horstmann’s Book) – Part 1 The Object-Oriented Design Process Hwajung Lee.
CMSC 202 A Design Exercise. 2 OO design activities Finding the Objects Defining the responsibilities –Services –Attributes Discovering relationships.
Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design,
CSE 403 Lecture 8 UML Sequence Diagrams Reading: UML Distilled, Ch. 4, M. Fowler slides created by Marty Stepp
Rules for Mini Bridge Lesson 5 Place board correct orientation (NSEW) Count cards (face down) Sort hand Count points Dealer to announce point count Clockwise.
Terms and Rules II Professor Evan Korth New York University (All rights reserved)
Use Case Diagrams. Introduction In the previous Lecture, you saw a brief review of the nine UML diagrams. Now that you have the clear, you'll start to.
1 BEGINNERS’ LESSONS Welcome Teacher: Your Name Here Telephone: © Copyright Reserved New Zealand Bridge Inc Prepared.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Distributed Java Programming Distributed Java Programming Class #1 August 20, 2002.
Chapter 2 (Horstmann’s Book) – Part 1 The Object-Oriented Design Process Hwajung Lee.
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.
CHAPTER 6 OBJECT ANALYSIS.
Bernd Bruegge and Allen Dutoit Requirements Process The requirements process consists of two activities: Requirements Elicitation: Definition of the system.
Chapter 4: Business Process and Functional Modeling, continued
Functional Modeling.
BEGINNERS’ LESSONS Welcome
Chapter 4, Requirements Elicitation: Functional Modeling
Functional Modeling.
UML UML Sequence Diagrams CSE 403
@NAMEOFEVENTORBRIDGECLUB
Week 10: Object Modeling (1)Use Case Model
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 4, Requirements Elicitation: Functional Modeling
15 things in 30 minutes 15 new activities to strengthen number work
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Chapter 4, Requirements Elicitation: Functional Modeling
Presentation transcript:

CSC 301H, Introduction to Software Engineering Fall 2009 TA Golnaz Elahi

Outline Course Assignments and Project Review Expectations for the Assignments Office Hour UML Diagrams

Assignments You are going to submit 6 exercises (Electronically) You will go through the steps in the Software Engineering process The course project and assignments are based on the card game Oh Hell

Oh Hell specification Oh, Hell is a card game with any number of players, usually 3 to 7 players. The object of the game is to accumulate points--at the end of the game the highest score wins. To get started choose a dealer to deal the first hand. Depending on the number of players the maximum number of cards in each hand is different. For three players the maximum is 17 cards per hand. For four players the maximum number is 12. For five players 10 cards, six 8 and seven 7 cards. For each hand you shuffle the cards and deal them card by card to each player. The number cards for each hand varies. For the first hand one card is dealt to each player. The next hand 2 cards for each player, the next 3 cards. And so on until the maximum number of cards for the number of players in this game is reached. The process is then repeated in reverse until you reach one card per player. At this point the game is over and the player with the highest score wins.

Assignment 1: Marking Schema Problems in the specification 90 Your mark All ambiguities, problems, and contradictions are covered. Comments: 60 Problems are clearly referred to the specification Comments: 30 Journal10

Assignments: Roadmap Exercise 2 Requirements Elicitation:  Find an experienced Oh Hell player maybe in your FaceBook account or in residence and quiz them about the rules of the game.  Rewrite the specifications as completely and correctly as possible.  Do not just transcribe the experienced player's description. Fit the corrections and additions into the current specification.  Provide use case diagrams for the functionality of the game. Compression of asking an expert or reading a document, eliciting the requirements and use cases are the key points

Assignment 2: Marking Schema Problems in the specification 90 Your mark Clarity and completeness of the new specification Comments: 60 Corrections and additions are clearly linked to the previous specification30 Journal10

Assignments: Roadmap Exercise 3 (week 7) Identify Classes and Objects Exercise 4 (week 8) Team Building and Communication Exercise 5 (week 10) Complete Coding and Testing Exercise 6 (week 12) Preparation for the Competition

Expectations Keep a journal that describes the process you went through to complete each of the exercises:  The process.  Where there were problems.  How they were overcome. For example in Exercise 1,  Describe how you played the game.  Did you read the specification and then put it away and try to play?  Did you read the specification step by step and apply each step?

Submission of the Exercises Ask your questions: Office hours are electronically by . You also can reach me at U of T, St. George campus. Update your reports to the submit page only: If you are submitting your assignment after the deadline, remind me to download your files too.

Use Case Diagrams In Requirements Engineering, we aim to  Share our vision and view of the system  Bridge the gap between the domain problem and the software  Communicate  Define the capabilities of the software Use Case Diagram is a modeling tool in Requirements Engineering

Use Case Diagrams A use case is a flow of events in the system, including interaction with actors It is initiated by an actor Each use case has a name Each use case has a termination condition

How to find use cases? Select a narrow vertical slice of the system  Discuss it in detail with the user Select a horizontal slice to define the scope of the system.  Discuss the scope with the user What are the main functionalities? What users do or want to do?

Oh Hell specification Oh, Hell is a card game with any number of players, usually 3 to 7 players. The object of the game is to accumulate points--at the end of the game the highest score wins. To get started choose a dealer to deal the first hand. Depending on the number of players the maximum number of cards in each hand is different. For three players the maximum is 17 cards per hand. For four players the maximum number is 12. For five players 10 cards, six 8 and seven 7 cards. For each hand you shuffle the cards and deal them card by card to each player. The number cards for each hand varies. For the first hand one card is dealt to each player. The next hand 2 cards for each player, the next 3 cards. And so on until the maximum number of cards for the number of players in this game is reached. The process is then repeated in reverse until you reach one card per player. At this point the game is over and the player with the highest score wins.

Oh Hell specification Once the dealer has dealt the cards for a hand, the remaining cards are placed face down in the middle of the table and the top card is turned up to reveal the suit of the card. The suit of the top card is the trump suit. For each hand starting with the player to the left of the dealer bid the number of tricks you think you will win. The next player to the left bids. The bid can be any value from zero if you expect to win no tricks to the number of cards in this hand if you expect to win all the tricks. The final bid comes from the dealer. The dealer must bid a number of tricks that with the total of the other bids does not equal the total number of tricks that are possible for a hand. It must be greater or less than the number remaining tricks. The player to the left of the dealer plays the first card in the first trick. For successive tricks the winner of the previous trick leads. In each trick the cards are played clockwise.

Oh Hell specification The highest card in a suit is the Ace; the lowest card is the Two. You must play a card from the suit that was led if you have one. Otherwise, you can play any card. A trump card beats the cards from any other suit. You win the trick if you play the highest card in the suit led or the trump suit. Once all the cards are played the hand is scored as follows: If you make the exact number of tricks you bid you score that number plus ten. If you make more or less tricks than you bid you score the number of tricks you won.

Use Case Modeling Let’s do an exercise Develop use case model based on description I give for the Oh Hell simulation game.

Use Case Associations A use case association is a relationship between use cases:  Include A use case uses another use case (“functional decomposition”)  Extends A use case extends another use case  Generalization  An abstract use case has different specializations

>: Functional Decomposition Problem:  A function in the original problem statement is too complex to be solvable immediately Solution:  Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases HandleIncident CloseIncident > ManageIncident CreateIncident

>: Reuse of Existing Functionality Problem:  There are already existing functions. How can we reuse them? Solution:  The include association from a use case A to a use case B indicates that an instance of the use case A performs all the behavior described in the use case B ViewMap OpenIncident AllocateResources > Base Use Case Supplier Use Case

> Association for Use Cases Problem:  The functionality in the original problem statement needs to be extended. Solution:  An extend association from a use case A to a use case B indicates that use case B is an extension of use case A ReportEmergency FieldOfficerf Help >

Generalization in use cases Problem:  You have common behavior among use cases and want to factor this out. Solution:  The generalization association among use cases factors out common behavior. The child use cases inherit the behavior and meaning of the parent use case and add or override some behavior. ValidateUser CheckPassword CheckFingerprint Parent Case Child Use Case >

Example Use Case Diagram for a Euchre Game

Use Case Description Use case name Actors Preconditions Triggers (Begin condition) Basic path Exception paths End conditions Post conditions

Classes How to identify classes? What are the properties of classes? What are the relationships among classes? What are methods of the classes? What are the objects?

Classes, Properties, and Methods Every noun in the specification can be a class or property of a class. Then, every verb could be a method.  Oh, Hell is a card game with any number of players, usually 3 to 7 players. The object of the game is to accumulate points--at the end of the game the highest score wins.  To get started choose a dealer to deal the first hand. Depending on the number of players the maximum number of cards in each hand is different. For three players the maximum is 17 cards per hand. For four players the maximum number is 12. For five players 10 cards, six 8 and seven 7 cards.  For each hand you shuffle the cards and deal them card by card to each player. The number cards for each hand varies. For the first hand one card is dealt to each player. The next hand 2 cards for each player, the next 3 cards. And so on until the maximum number of cards for the number of players in this game is reached.  The process is then repeated in reverse until you reach one card per player. At this point the game is over and the player with the highest score wins.

Classes, Properties, and Methods  Once the dealer has dealt the cards for a hand, the remaining cards are placed face down in the middle of the table and the top card is turned up to reveal the suit of the card. The suit of the top card is the trump suit.  For each hand starting with the player to the left of the dealer bid the number of tricks you think you will win. The next player to the left bids. The bid can be any value from zero if you expect to win no tricks to the number of cards in this hand if you expect to win all the tricks. The final bid comes from the dealer. The dealer must bid a number of tricks that with the total of the other bids does not equal the total number of tricks that are possible for a hand. It must be greater or less than the number remaining tricks.  The player to the left of the dealer plays the first card in the first trick. For successive tricks the winner of the previous trick leads. In each trick the cards are played clockwise.  The highest card in a suit is the Ace; the lowest card is the Two. You must play a card from the suit that was led if you have one. Otherwise, you can play any card. A trump card beats the cards from any other suit. You win the trick if you play the highest card in the suit led or the trump suit.  Once all the cards are played the hand is scored as follows: If you make the exact number of tricks you bid you score that number plus ten. If you make more or less tricks than you bid you score the number of tricks you won.

Classes (first draft)

Java Interfaces As interfaces are implicitly abstract, they cannot be directly instantiated except when instantiated by a class which implements the said interface. One benefit of using interfaces is that they simulate multiple inheritance.

Java Interfaces Interfaces is used to encode similarities which classes of various types share, but do not necessarily form a class relationship.  Humans and dogs both run, but they are not subclasses of runners !  They could be both subclasses of Animal (extends Animal class)  But both of them implement the interface Runner!

Java Interfaces Another use of interfaces is being able to use an object without knowing its type of class, but rather only that it implements a certain interface So we pass an object of the type of runner instead human or dog to another class.

UML Activity Diagram

UML Sequence Diagram CallerPhoneRecipient Picks up Dial tone Dial Ring notificationRing Picks up Hello

UML Sequence Diagram Message