Workshop/Tutorial Information

(Workshops and Tutorials are the same thing)

(Week 12) Workshop 9: Evolving a Design

Last week you worked on designing and specifying a simple web-phone application. The goal of that tutorial was to give you practice carefully creating artefacts that could be used by others. In this tutorial, you will take the product of another group's work from last week, and evolve the design, adding two new features. The goal of this workshop is to give you practice altering an existing system, and to let you continue thinking about designing for ease of change.

YOUR TASK is to evolve a skype-like phone system to include two new features (listed below). Once again, your design must demonstrates high cohesion of individual modules, and has minimal coupling between modules. The features that must be included in the design are:

• Contact List (searching the list, adding contacts, removing contacts, selecting contacts to make a call)
• Conference Calling (ability to call multiple people at once, ability to add someone in the middle of a call)

Please provide the following design artefacts:

• A new class diagram for each class in the system (do not merely mark on the old one - make a whole new one, incorporating the old design)
• A new list methods for each class
• For each method, provide the method signature (its parameter list, and return value), and pseudo code indicating its behaviour

Please provide the following discussions about the task:

• How did coupling and cohesion of the existing system influence the ease/difficulty of your task?
• What did you have to do to accommodate the design changes? (how did you need to alter the underlying system, and why)
• Discuss the coupling and cohesion of the final system

Note: The focus in this task is not on the design of the artefacts themselves - it is on your ability to reflect on the change. Please pay most attention to the discussion points, rather than spending a lot of time on the re-design.

For additional credit, after you've completed the rest of the tutorial, you can attempt this bonus question (2 additional points on workshop marks!):

• Add a logging feature to the system (all actions/events in the system are logged to a file)
• Discuss how adding logging would affect system coupling
• Discuss how adding logging would affect system cohesion

(Week 11) Workshop 8: Designing for Evolution

In class we went over how to plan for ease of design change (design evolution). We looked at two principles that help ease changes "down the road" to software systems: high cohesion of individual modules, and low coupling between modules.

In this tutorial, you will be designing a system such that the design demonstrates these two principles. In the subsequent tutorial, your system will be given to another group, and that group will need to understand and evolve the system.

YOUR TASK is to design a skype-like phone system that demonstrates high cohesion of individual modules, and has minimal coupling between modules. The features that must be included in the design are:

• Establishing and carrying phone calls between two parties
• The ability for a user to place a call on "mute"
• The inclusion of video transmission over active calls

Please provide:

• A class diagram for each class in the system
• List methods for each class
• For each method, provide the method signature (its parameter list, and return value), and pseudo code indicating its behaviour
• A discussion (1-3 sentences) of the level of cohesion of each class
• A discussion (1-3 sentences) of the degree of coupling between each connected pair of classes

For coupling and cohesion hints, see the wikipedia reprint handout here.
Also remember: high cohesion=good, high coupling=bad.

NOTE: Don't write your names directly on your work this week (your work will be given to another group next week, and we want this done anonymously). Luke and Nandita will provide you with post-its to write your group details on and attach.

(Week 10) Workshop 7: Sequences of States

In class we went over sequence diagrams and how they pull together state models for different active objects. In this workshop, you will perform 3 of these integrations.

Here are sample state models for the Player and the NPC classes. Please note that thee are not complete state models for these classes; they just show the relevant states and transitions for this workshop.

YOUR TASK is to accurately integrate the state models to create a 3 sequence diagrams, one for each of the following situations:

• Player is still; User moves Player; The game ends
• Player is still; User moves Player; Player moves onto a Crystal
• Player and NPC are both still; User moves player; Player meets NPC; Player requests challenge;

Where you think there might be confusion, please indicate your rationale for choices.

(Week 9) Workshop 6: State Diagrams

In class we went over state diagrams: diagrams that describe the transitions between states of a system (refer to the lecture notes for details on syntax).

YOUR TASK is to create a single state transition diagram, and associated state transition table for the following situations:

• two players meet and fight for crystals
• a player meets a Non-Player-Character, who issues a challenge to the player, and then provides a reward if the challenge is completed
• players move around the maze
• players collect a crystal from the maze

Where you think there might be confusion, please indicate your rationale for choices.

Remember:

• states are usually present tense verbs (going, thinking, walking)
• transitions are usually past tense events (message received, plane landed), or conditions (code==true)
• start and end states are not "real" states -- they are pseudo states: start is just a way into the first real state of the system, and the end state is just the way out of the last real state.
• state transition table cells which do not correspond to a valid transition are labelled either ÒignoredÓ (the transition signal can occur, but the state model does not respond) or Òcannot happenÓ (the transition signal cannot occur), depending on whichever is most appropriate.

(Week 7) Workshop 6: Modeling Specialisation

In class we went over how to "zoom in" to the high level design to look at how to use specialisation to enhance cohesion. We talked about two kinds of hierarchies that might be natural design choices: specialisation of information (a cat is a type of animal), or specialisation of behavior (a queen's gambit is an opening chess move).

YOUR TASK is to create two class hierarchies in the Crystal Game, one that specialises information, and one that specialises behavior or strategy. It is fine if you devise two hierarchies that each do a bit of each, but one should be predominantly a behavioral breakdown, and the other should be predominantly an informational breakdown. Provide a description of your hierarchy, and indicate your rationale for choices.

Remember:

• associations are inherited too
• get those arrow-heads correct
• it's fine to have a few extra classes to give design context to your hierarchies (to show the associations that must also be passed down)
• it's fine if the two class hierarchies relate to one another (they don't have to be isolated from one another)

(Week 6) Workshop 4: Modeling Classes

In class we went over how to "zoom in" to the high level design to look at classes and their associations with one another. We also looked at class attributes, and (to a small extent) discussed their behavior. We also began the discussion on whether you have a good class. We discussed the concept of cohesion, in which all the parts of a class relate to one another. If some portions of a class exist essentially independently from other portions, then a good design principle is to work out a way to represent them as separate classes. This week, we used simple splitting to accomplish an improvement in cohesion. Next week we'll look at using specialisation to get there.

Class diagrams have this basic syntax:

YOUR TASK is to draw the class model (according to the above syntax, and without worrying about inheritance/specialisation) for the following requirements:

• Crystals must be scattered throughout the maze before the game begins
• When players encounter one another in the maze they engage in a battle for crystals. The winner gets some number of crystals from the loser.
• When players encounter an NPC in the game, the NPC gives them a task to carry out. When the player completes the task, they return to the NPC for a reward of some number of crystals.
• Once the time runs out on the game, the player with the most crystals wins.

Remember:

• Class names are almost always nouns, and are almost always shown in CamelCase
• Attributes are typically also nouns, but can have lower case names
• Attributes need types
• Operations can be provided without types; Operations are almost always named as verbs
• All three of these (Classes, Attributes and Operations) need descriptions that make sense
• The associations between classes should be carefully thought out and make sense. The descriptions of how one class affects another should be intuitively sensible
• Classes should be cohesive, meaning that they should be essentially "about" one thing.

(Week 5) Workshop 3: Functional Requirements & High Level Design

YOUR TASK PART 1: Rewrite the following requirements to bring them into compliance with the IEEE standard (described in workshop 1):

• scatter crystals around maze
• players fight when they meet
• time runs out and someone wins

Like last week: You may need to make certain decisions about what the underlying intent is of those requirements, but that's okay. Just as long as the requirements are unambiguous, clear, verifiable, etc etc (as stated in the standard).

YOUR TASK PART 2: As we did in class, please compose a high level design that takes into account these three requirements. The steps we used in class were:

• Look for behaviors
• Work out which entity/element will be responsible for those behaviors
• Look for additional elements needed
• Describe the relationship between the elements

And remember that the elements/entities are typically (almost without exception) named as nouns. Usually they are linked by some kind of behavior (one "uses" another, or "checks" another, etc), but that those behaviors should really be "owned" by the destination entity. If the behavior on the link between two entities is too complicated or wide-reaching for that destination entity to be responsible for, then you might need an intermediate entity to "own" that behavior.

It is also fine to have sub elements (one entity sitting right inside another) to break down the different behaviors that might all be bundled into one larger component.

Remember to write your design assumptions on the sheet you pass in to the tutor.

(Week 4) Workshop 2: Non Functional Requirements & Architecture

YOUR TASK PART 1: Rewrite the following requirements to bring them into compliance with the IEEE standard (described in last week's workshop notes, still visible below):

the system should run fast

the game should keep information from being lost

recovery time must be short

the program must be extensible

utilize memory efficiently

You may need to make certain decisions about what the underlying intent is of those requirements, but that's okay. Just as long as the requirements are unambiguous, clear, verifiable, etc etc (as stated in the standard).

YOUR TASK PART 2: Rank the clarified non-functional requirements. Explain (in a couple of sentences) your ranking.

YOUR TASK PART 3: Choose the top non-functional requirement (the most important one), and imagine a very high-level architecture that would cater for that requirement.

The use of metaphor can be very helpful when thinking about ways to address non-functional requirements -- for instance, in class, we discussed that if data security is an issue, you might start to imagine the data being locked away, behind a high wall or some kind of enormous obstacle. You might come up with a picture like this:

A picture like that is fine. But it should be accompanied by some explanation. For instance, in this case, I'd perhaps say "The fortress walls indicate security measures that must be passed to be able to get to the data. The doors are small because I don't want there to be too much access, and I don't mind if only one small request can get through at once (speed is not an issue for me). The little windows indicate ways that my system actively watches all requests, so that it can shoot them back and deny them access to the door if they are harmful."

Please note: I picked this example on purpose, because security isn't really the most pressing issue in the Crystal Game -- please don't hand this architecture in as your own.

The goal of this workshop is not to figure out how to come up with the very best ever software architecture. It's to get you started thinking strategically about system design.

(Week 3) Workshop 1: Requirements

YOUR TASK: Construct a requirements specification for a system with the following characteristics:

This is a game, in which multiple players move their avatars around a maze. The maze has crystals scattered throughout it. The goal is to collect these crystals before time runs out on the game. Multiple players are in the maze at the same time. There are also computer-run characters who sometimes hold stockpiles of crystals. To access their stockpile, the player needs to complete a challenge set by the character. The challenge can be something like "find an item and bring it back", or get to a certain location within a certain amount of time, and then return. Players can also fight one another for crystals when they meet in the maze. When the timer runs out, the player with the most crystals wins.

Remember from the IEEE Standard that requirements contain:

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system's hardware, other hardware, and other software?

c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.?

d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations?

e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

And that they should be:

a) Correct (in this case this means that they should logically fit within the realm of the game)

b) Unambiguous

c) Complete (clearly, in less than 2 hours you are not going to come up with a fully complete set of requirements. However, they should cover all the major scenarios you can foresee, such as the features included in the description.)

d) Consistent

e) Ranked for importance and/or stability

f) Verifiable

g) Modifiable (let's not worry too much about this one right now)

h) Traceable (or this one).

There is no set number of requirements you need to produce (after all, requirements greatly differ in scope, so quantifying them is nearly impossible). Instead, aim for the qualities listed above.

Do all your work on the common sheet of paper. You do not need to produce a "good copy" of your work. Just circle the bits you want to submit, or cross out the bits you do not.

Just to let you know: The top marked requirements sets (probably merged, and with some modifications) will be used as a basis for the subsequent workshop's work. We will not indicate which group(s) contributed to this set.

General Feedback for Requirements Workshop

As you know, you will receive marks for the work you handed in. That will give you a sense individually of how well you did. However, even before getting that feedback, we wanted to give general feedback on things we saw as problem spots for everyone. Here are the most common errors for this lab:

Vague requirements: Requirements like "the system should run", or "reliable!" are just too vague. Imagine that you (the developer) could be sued by the customer for not meeting these requirements. How would you prove you met them, or hadn't met them? Vague requirements like this break several of the rules given by the IEEE standard: Unambiguity, Clarity, Verifiability and Traceability.

Incomplete sets of requirements: Many groups failed to give requirements that accounted for all the bits of functionality listed in the description paragraph. These missing behaviours included scattering crystals around the maze (you have to actually put them there before they can be picked up!), and governing how the game ends. A helpful technique for making sure you've got all the listed behaviours is to number the ones that are indicated explicitly in the description, and then brainstorm about what other behaviours might be implied by the description. Then when you create your requirements, go through that list of behaviours as a checklist.

Not to worry though: next week you'll get another chance to write requirements, focusing on making them industrial quality!