Iteration 1 pt. 3

[spratt]

Due March 19th

[spratt]

Deliverables:

• requirements
• use case diagram
• use cases
• responsibilities
• bound and unbound use case maps
• design decisions
• UML class diagrams
• object specifications
• UML 2.0 interaction diagrams
• running game

[spratt]

Note that the code either needs to run on the lab computers, or we need to include a VM image. Also, all files required to run the system should be in the bin folder.

[spratt]

See: http://people.scs.carleton.ca/~jeanpier//304W13/Iteration1Part%203.pdf

[cdelahousse]

Feedback from WebCT:

Some comments on Iteration 1 part 1

1-LOGISTICS

• I will NOT issue team-specific comments: I have gone through the submissions and find that most suffer from one or more of the problems described below. The onus is on you to understand these problems and see if they apply to you.
• unless everyone in your group did a relatively equivalent share of the work, you should email me peer evaluations. You have until Friday 8AM.

2- REQUIREMENTS

• functional requirements are OBSERVABLE/VERIFIABLE small units of functionality. Something like "There are 3 sets of cards, one for each age. There are 49 cards in age 1 and 2, and 50 cards in age 3." has NO functionality. Similarly, "Players are only allowed to play ...." is NOT good. If the intention is to say that the system will block a certain action, then state it explicitly (eg "System must prevent....") . Similarly, "support for 4 players" is vague: what is meant by 'support'? How do we know this requirement is meant or not? That's what I mean by verifiable...
• The number of functional requirements varies greatly from one team to another. The more complete submissions consider not only game play for one player, but game creation and game joining, synchronization of play per turn over several players, exceptional situations (eg player not responding in time, connection to player lost, game destruction, etc.)
• A requirement such as "Players are only allowed to play a card if they have resources that satisfy the cost required to build it. There are exceptions though." is problematic because of the second sentence, which is vague. It's even more so if such exceptions are not discussed anywhere else :-)
• very very few teams did what I mentioned in class and which is illustrated in some of the posted case studies: have interface requirements as a subset of FRs. These interface requirements spell out WHAT a GUI must be able to show (not HOW). For example, it must be possible to see all played cards very clearly? Neighbors want to know what cards you have and what chains these cards enable!
• non functional requirements are also meant to be OBSERVABLE/VERIFIABLE (typically in terms of some measure/metric). So "UI must be responsive and simple" is not good: 'responsive' and 'simple' are not well defined. Try to say how one would know a GUI is responsive, that is, how to measure that. The number of NFRs varies considerably from one submission to another: don't invent them for the sake of having a large number.
• "Administrator stored player’s resources in memory. " is quite problematic as a NFR: this sounds like a design decision and is quite vague in its wording ('resources'??)
• assumptions are meant to be FRs or NFRs that cannot be easily traced (eg to the rules of the game). So... assumptions HAVE to be written like FRs and NFRs... And avoid things like "All players understand the rules of the game"... Also, like FRs, NFRs, and Use cases, assumptions need to be black box.

3- UC diagram and UCs The Use Case diagrams vastly differ and most indicate problems with the Use cases... So, regardless of the mark you got on the use case part of Assignment 1, please try to address the following observations:

• wrt viewpoint, few submissions managed to convey that 1 player creates the game, others join, then there are 3 ages, each age involving several turns + some end of age resolution (including scoring after age 3), each turn involving all players individually selecting a card and playing it at specific point in time (after a timeout for selection). By the way, adopting the perspective of a single game is perfectly valid since a player participating simultaneously in a several games is a nightmare to model...
• wrt relations between uses cases, very few submissions had good relationships between their Use cases. Most submissions used only <<includes>> and/or <<uses>>. Few submissions captured any temporal relationship (eg creating of the game before joining in the game). Some did use <<mutex>> but this is not as desirable as saying one UC must precede another.
• the vast majority of submissions did NOT use the REQUIRED <Actor> <Verb> syntax to start the titles of their use cases. "Setup" is a bad UC title. "System setup" is not as good as "System sets up game".
• "Server" and "AI player" were used as actors, as well as "Players" (or "Player", which does not convey there are several). "Server" and "AI player" can be actors but several teams used them to describe design decisions more than requirements inherent to the problem...
• Several submissions had steps of UCs with NO actor: eg. "Shuffle cards", "change direction", "player's turn is over". This is bad...
• wrt alternatives in use cases, most teams understood that one must state where an alternative takes place (which could involve several points of the original UC where steps of the alternative 'hook up' to the main scenario). This being said, a lot of the alternatives I saw had to do with variations in cards and/or rules. This is not good: Alternatives in UCs must correspond to alternative functionality.

These observations are meant for everyone to improve their requirements and use cases. I will be posting Iteration 1 part 2 by Wednesday night: it will be a milestone with probably NO feedback and no marking. Its purpose will be to assess who has what in terms of modeling AND RUNNING behavior. Failure to submit what you have at that point (with screen shots if available) will result in deductions on the grade for Iteration 1.

Iteration 1 part 3, models and code will be due March 15th in early morning (with no possibility of extension). Code that does not run in the lab will have to be submitted on a stick as a virtual image (ie sandbox). Demos may likely be organized for that day.

Iteration 2 requires that I know what everyone achieved in Iteration 1, which is why Iteration 1 part 2 is crucial as a heads-up.

[spratt]

Did we send that peer evaluation? Although, I'm going with we did an equal amount of work so it shouldn't matter.

[Gankra]

I thought the peer evaluation was optional?

[cdelahousse]

Yep. Optional. I haven't sent any.

[spratt]

Executive Summary of JP's Comments

Requirements

• FRs are verifiable units of functionality
• should consider:
  • game creation
  • game joining
  • sync of play per turn over several players
  • player not responding in time
  • connection to player lost
  • game destruction
• separate out interface requirements like:
  • necessary to display all played cards
  • necessary to see neighbour resources
• NFRs should have verifiable metrics
• assumptions are FRs or NFRs that can't be traced
  • assume single game perspective

UC Diagrams and UCs

• should convey:
  • 1 player creates game, others join
  • 3 ages of several turns
  • age resolution (including scoring after age 3)
  • turn involves
  • selecting a card
  • playing a card after a timeout
• relations between use cases should include
  • temporal relationship
  • create game before joining game
  • don't use <<mutex>> just say one use case must precede another
• use cases should use <Actor> <Verb> naming syntax
• "Server," "AI player" actors should not be used to convey design decisions
• should user "Players" actor to convey that there are several

[cdelahousse]

UPDATED For Iteration 1 part 3, now due March 19th at 8AM, you are to submit a single zip file named Team<#>Iteration1P3. (Deductions will apply for EACH violation of the naming conventions of this assignment.) In that zip file you need to include the following files:

1) a .doc or .docx Word document named Team<#>It1Model that contains the following: • a title page with student names and ids • a glossary (if deemed necessary) • a section for functional requirements, non-functional ones, and assumptions. You can further break down requirements per subsystems (eg GUI, networking, etc.). • a section for the Use Case Diagram followed by the description of each use case of this diagram (using the template discussed in class) • a section for the list of responsibilities and the unbound Use Case Maps corresponding to the use cases (not forgetting to deal with the UC diagram) • a section on the design decisions you have taken with respect to your choice of classes/objects for the system (see the poker documents for examples). This section must include a UML class diagram (also known as a structural model, see Grocery example documents). • a section for the Object Specifications (again see Grocery examples) • a section for the bound UCMs (corresponding to the unbound ones) • a section for the UML 2.0 Interaction Diagrams (using MSC-like syntax/semantics) corresponding to your bound UCMs (These models will be evaluated, in part, wrt their traceability to each other and, most importantly, to your code!)

2) the pdf equivalent of the Word file

3) if necessary, in a folder called Images, files for all figures of your document not made in Word (eg vision, jpeg, etc.)

4) in a folder called bin, an executable file called 7Wonders with the proper extension for the language you are using (eg., .jar for JAVA). In the same folder, a readMe Word file that 1) explains what environment you are using and 2) details what your code can and cannot do.

5) In a folder called src, all necessary files to compile and run your game.

6) In a folder called logs, all team logs for iteration 1.

In addition, ALL TEAMS are to give me a stick containing an Oracle VirtualBox image. (This virtual image should be as small as it can!!) On the desktop of this virtual image, I must see your executable (named <Team#>7WonderIt1) and I must be able to run it by simply double-clicking on it. This should eliminate the all-too-frequent risk of having a TA not manage to run your code...

The virtual image must also have the icon of your SDE on the desktop. I must be able to start it and see your source code ready for compilation and running.

You should also include the above zip file on it.

Finally, be sure to have a .txt file on your desktop called <TEAM#>.txt so that we know which team the stick belongs to!

This stick is due to ME at the very BEGINNING of the lecture on March 19th at 8:40.