Skip navigation
The Australian National University

Lab Announcements
  • Thursday tutorials will be held in N115
  • Labs/Tutorial Information

    (Labs and Tutorials are the same thing)

    (Week 12/13) Lab 4: Architecture

    In this lab, you will look at the component level architecture for the crystal game. In class, we went over the MVC pattern as a nice way to capture user interface and underlying behavior. Feel free to use that as the central design pattern in your Crystal Game architecture design.

    In week 13 you will give the usual presentation about your work.

    (Week 9/10) Lab 3: Specifying Detailed design

    In this lab you will draw out the detailed design for the crystal game, based on your high level model. If you don't still have your high-level model from last tutorial, I can supply one done by another group (randomly chosen!). In this detailed design process you will have to do two things:

  • Construct a detailed class diagram, including subclasses, and associations
  • Choose two use case scenarios, and construct their sequence diagrams.

    In week 10 you will give the usual presentation about your work.

    (Week 6/7) Lab 2: Deriving Design from Requirements

    In this tutorial you will be following the process we went through in class to derive high-level design from requirements. The requirements you will be using are those for a game called "The Crystal Game". You can download the requirements here. They will also be provided to you in hard copy in your lab session.

    Week 6 activities

    Overall: Create a class diagram for the crystal game, and also an association diagram (or conceptual model) for the game design.

    Step 0: This is, once again, a group lab activity. Your groups can be the same as last time, but they don't have to.

    Step 1: Decide how you will approach the task of getting from the requirements to a high level design -- it is up to you whether you construct a set of use case diagrams, or state transition diagrams, rethink the vision, add new requirements, etc etc.

    Step 2: Prioritize! Remember your time is limited. It is possible you will not be able to get through the whole set of requirements -- decide how you will prioritize the requirements to address, if you don't have time to address all of them.

    Step 3: Decide how to divide up the work. Not everyone has to do everything! A good division of labor can get you farther towards a complete design.

    Step 4: Carry out your plan!

    Week 7 presentation

    Give a 5-7 minute presentation indicating:
  • How you approach the problem of getting the design from the requirements?
  • Whether you had to make any modifications to the requirements? Did you have to augment them in any way? Which ones did you ignore due to lack of time or for some strategic reason?
  • Any artifacts you created to help make the transition
  • The behaviors in the game
  • The entities in the game
  • The resultant class diagram
  • The resultant association diagram

    (Week 4/5) Lab 1: Requirements Reverse/Re-Engineering

    [instructions][SRS form]

    In this tutorial, you will be gathering requirements based on your recommendations of changes to an existing application.

    Step 0: Form into groups - make sure one member of your group has an iPhone-like phone (a phone for which free applications can be downloaded).

    Step 1: Download a FREE application for your phone. It should be a simple application -- two or three screens only.

    Step 2: Write down what your expectations of the app are BEFORE you launch it. This will be based on the name of the application, and the descriptions you've read. Imagine how it will work, and what features it will have. What functions will it provide? Keep track of all these thoughts.

    Step 3: Launch the application, and use it. BEFORE each button press, note what you expect to have happen. AFTER each button press, note the difference between what you expected to happen (or wanted to happen) and what actually happened. Note any inadequacies on the screens.

    Step 4: Gather together a list of all the "failures" of the product. If there are no failures, imagine extra features that would enhance the product.

    Step 5: Write a new set of requirements for a new product that includes your changes. This includes: User interface screens, with transitions indicated as arrows pointing out from the buttons/widgets

  • Use case diagrams
  • State transition diagrams
  • Software Requirements Specification

    Step 6: Give a 5-7 minute presentation in Week 5's tutorial class!! Make sure that everyone in the group talks (only people who talk get credit for giving the presentation!)

    Presentation Instructions

  • You will have 10 minutes at the beginning of the tutorial to prepare your presentation
  • It does not matter how you do your presentation, as long as you get your points across and the marker can see the materials to which you refer. Powerpoint/Whiteboard/Etc -- up to you.
  • You will be told next week what to submit along with your presentation. Probably we'll want some record of the whole presentation (the powerpoint, for instance, if you used that), but at least we'll want the artifacts you created.

  • Updated:  18 October 2010 / Responsible Officer:   JavaScript must be enabled to display this email address. / Page Contact:   JavaScript must be enabled to display this email address.