CSC 301H, Introduction to Software Engineering

CSC 301H, Introduction to Software Engineering

Fall 2009

TA Golnaz Elahie-mail: [email protected]

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:

[email protected] 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.


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.


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


+Bid()+PlayCard()+ViewTablsCards()+ViewTrumpSuit()+GetHand()

-PlayingHand : Hand-PlayerID-PlayerLocation-TotalTricksWon-HandTricksWon

Player

+AddCardtoHand()+RemoveCardfHand()+CountNumofCards() : int

-Cards : Card

Hand

+Beat() : bool

-Rank-Suit

Card


+DealCards() : Hand+ShuffleCards() : Hand+ShowTableCardstoPlayers()+GetBidsFromPlayers()+AddTricksWontoPlayer()+CalculateTotalScores()

-Players : Player-TricksBidArray : int-TricksWonArray : int-ScoresArray : int-HandCounter : int-NumCardsDealt : int

GameModerator


+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

Documents

CSC 301H, Introduction to Software Engineering