Post on 01-Jan-2016
description
CSC 301H, Introduction to Software Engineering
Fall 2009
TA Golnaz Elahie-mail: gelahi@gmail.com
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
Journal 10 10
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 specification 30
Journal 10 10
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:
gelahi@gmail.com Office hours are electronically by e-mail. You also can reach me at U of T, St. George
campus. Update your reports to the submit page only:
https://endor.utm.utoronto.ca/submit/ 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
<<Include>>: 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
<<include>><<include>> <<include>>
ManageIncident
CreateIncident
<<Include>>: 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
ViewMapOpenIncident
AllocateResources
<<include>>
<<include>>
Base UseCase
SupplierUse Case
<Extend>> 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
<<extend>>
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
ParentCase Child
Use Case
<<extend>>
<<extend>>
Example Use Case Diagram for a Euchre Game
Player
Get a hand
Dealer
deal hand
Make Trump
Pass
Call the Trump
lay down card
Make points
Order it up
Order it up
Turn it down
Take it up
extends
extends
extends
extends
extends
include
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)
-PlayingHand : Hand
Player-Cards : Card
Hand
-Rank-Suit
Card
Classes (first draft)
+Bid()+PlayCard()+ViewTablsCards()+ViewTrumpSuit()+GetHand()
-PlayingHand : Hand-PlayerID-PlayerLocation-TotalTricksWon-HandTricksWon
Player
+AddCardtoHand()+RemoveCardfHand()+CountNumofCards() : int
-Cards : Card
Hand
+Beat() : bool
-Rank-Suit
Card
Classes (first draft)
+DealCards() : Hand+ShuffleCards() : Hand+ShowTableCardstoPlayers()+GetBidsFromPlayers()+AddTricksWontoPlayer()+CalculateTotalScores()
-Players : Player-TricksBidArray : int-TricksWonArray : int-ScoresArray : int-HandCounter : int-NumCardsDealt : int
GameModerator
Classes (first draft)
+Bid()+PlayCard()+ViewTablsCards()+ViewTrumpSuit()+GetHand()
-PlayingHand : Hand-PlayerID-PlayerLocation-TotalTricksWon-HandTricksWon-TrumpSuit
Player+AddCardtoHand()+RemoveCardfHand()+CountNumofCards() : int
-CardsArray : Card
Hand +Beat() : bool
-Rank-Suit
Card
+DealCards() : Hand+ShuffleCards() : Hand+ShowTableCardstoPlayers()+GetBidsFromPlayers()+AddTricksWontoPlayer()+CalculateTotalScores()
-Players : Player-DeckofCards : Hand-HandCounter : int-NumCardsDealt : int-TrumpSuit-TricksBidArray : int-TricksWonArray : int-ScoresArray : int
GameModerator
1..11..*
1..1
*
1..1
1..1
1..1
1..1
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
Caller Phone Recipient
Picks up
Dial tone
Dial
Ring notification Ring
Picks up
Hello
UML Sequence DiagramUser Catalog Reservations
1: look up ()
2: title data ()
3: [not available] reserve title ()
4 : title returned ()
5: hold title ()
5 : title available ()
6 : borrow title ()
6 : rem ove reservation ()
Message