1 / 39

CSC 301H, Introduction to Software Engineering

CSC 301H, Introduction to Software Engineering. Fall 2009 TA Golnaz Elahi e-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)

quemby-raymond
Download Presentation

CSC 301H, Introduction to Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSC 301H, Introduction to Software Engineering Fall 2009 TA Golnaz Elahi e-mail: gelahi@gmail.com

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

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

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

  5. Assignment 1:Marking Schema

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

  7. Assignment 2:Marking Schema

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

  9. 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?

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

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

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

  13. 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?

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

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

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

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

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

  19. <<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 ManageIncident <<include>> <<include>> <<include>> HandleIncident CloseIncident CreateIncident

  20. <<include>> OpenIncident ViewMap <<include>> AllocateResources <<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 Base Use Case Supplier Use Case

  21. FieldOfficer f ReportEmergency <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 Help <<extend>>

  22. CheckPassword ValidateUser CheckFingerprint 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. <<extend>> Parent Case Child Use Case <<extend>>

  23. Example Use Case Diagram for a Euchre Game

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

  25. 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?

  26. 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 accumulatepoints--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.

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

  28. Classes (first draft)

  29. Classes (first draft)

  30. Classes (first draft)

  31. Classes (first draft)

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

  33. 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!

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

  35. UML Activity Diagram

  36. UML Sequence Diagram Caller Phone Recipient Picks up Dial tone Dial Ring notification Ring Picks up Hello

  37. UML Sequence Diagram Message

More Related