Workshop/Tutorial Information
(Workshops and Tutorials are the same thing)The workshops are held in the following rooms:
Mon 2p-4p: Room N101 CSIT
Tue 12p-2p: Room N101 CSIT
Tue 3p-5p: Room N101 CSIT
Wed 1p-3p: Room N101 CSIT
Thu 9a-11a: Room N101 CSIT
Friday 12p-2p: Room R221, Ian Ross Building
Workshop 5: Executable Specifications
In class we went over how sequence diagrams are used to examine interactions that involve multiple active objects. In this workshop you will create sequence diagrams based on the state models of the Player and HostileNPC classes specified below. Please note these are not complete state models; they just show the relevant states and transitions for this workshop.
Click here to view pdf version of models
Note: Implicit in the state models above is that every state transitions to “end” when the game ends. The moveButtonPressed, moveButtonReleased, and attackButtonPressed transitions are triggered by an external source (e.g. mouse or keyboard).
YOUR TASK
Your task is to accurately integrate the state models above to create 3 sequence diagrams, one for each of the following situations:
- Player is resting; User moves Player for 2 steps; The game ends
- Player and HostileNPC are resting; User moves Player; After 1 step Player encounters and challenges HostileNPC; HostileNPC rejects challenge
- Player is being moved by user and HostileNPC is resting; Player encounters HostileNPC and they start fighting; The fight ends with the HostileNPC being destroyed
Where you think there might be confusion, please indicate your rationale for choices.
Workshop 4: Modeling States
In class we went over state diagrams: diagrams that describe the transitions between states of a system. The figure below shows the basic syntax for state diagrams. The internal behaviour of states can be expressed informally (like in the figure) or through more formal comments as shown in microwave oven diagram in the lecture. In this workshop, you can use either.
GROUP TASK PART 1
Create a single state diagram and associated transition table that models a player going on and completing a quest in the dungeon game. Here are a few relevant requirements to get you started:
- When players encounter NPCs is the city, the NPC might ask the player to go on a quest.
- When players complete a quest, they return to the NPC they obtained the quest from for a reward.
- When a player encounters hostile NPCs in the dungeons, they fight.
- The game supports two basic type of quests: Retrieval (of objects or friendly NPCs) and elimination (of particular hostile NPCs).
You can cover additional situations, and 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.
GROUP TASK PART 2
Go through your state transition table and analyse any empty cells to identify potential missing states and transitions. If missing states and transitions are discovered, add them to the table and circle them. You can add them to the diagram as well, if you have time and there is any space left.
If you encounter an empty cell and nothing is missing, please state if the event is ignored or can’t happen.
INDIVIDUAL TASK
Please take a few minutes to answer the following reflective questions on a separate sheet of paper. Note that this is an individual task, and make sure to write down your name and student id.
How would you compare the contribution of each member of your group over the past few workshops?
How does your contribution compare with others in the group?
What have you learned about software analysis and design in the last 5 weeks?
Workshop 3: Class Diagrams
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 a discussion on whether you have a good class by looking at cohesion, a concept 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. In the second part of the lecture, we talked about two kinds of specialization 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).
Class diagrams have this basic syntax:
YOUR TASK
Draw a class model for the requirements below. Make sure to include associations, at least one information specialization, and one behavior/strategy specialization (more specializations are fine if you have time). It’s fine to add extra classes to give design context to your model.
- When a player or team of players encounters hostile NPCs (non-player characters) in the game they fight. If the players win, they take equipment and gold from the NPCs.
- Players can encounter various friendly NPCs in the city and interact with them to trade or obtain quests.
- When players complete a quest, they return to the NPC they obtained the quest from for a reward.
- The game provides a map of the dungeons that shows the position of players.
Note
When working on this task, you might consider splitting the workload by having each member of the group pick a particular requirement (or requirements) and spend some time thinking about possible classes, associations and specialization. Once this is done, you can share your ideas and start composing the diagram as a group.
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.
- Associations are inherited too
- Get those arrow-heads correct
Workshop 2:
Requirements, Architecture and Design
YOUR TASK PART 1
Rewrite the following requirements to make them unambiguous and verifiable. Then rank them for importance (separate rankings for functional and non-functional requirements are fine):
Non-Functional
- The system should run fast
- The game should keep information from being lost
- Recovery time must be short
- The program must be extensible
Functional
- Players fight enemies when they meet
- Retrieve objects from the dungeons and sell them in the city
- Someone wins when enough quests have been completed
YOUR TASK PART 2
Choose one non-functional requirement, and come up with a very high-level architecture that would cater for that requirement.
The use of a 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 the one above.
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 Dungeon Game – please don’t hand this architecture in as your own.
The goal of this task 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.
YOUR TASK PART 3
As we did in class, please compose a high level design that takes into account the three functional requirements from Task 1. 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.
Workshop 1: Requirements
YOUR TASK: Construct a requirements specification for a system with the following characteristics:
This is a game, in which players control heroes that explore a series of dungeons, collecting equipment, gold, and fighting enemies. A small town is located next to the entrance to the to dungeons, where players can buy and sell items and obtain quests. For example, a quest can be something like finding an item in the dungeons and bringing it back, or defeating a particularly nasty enemy. Players can form teams with other players or attempt quests on their own. The goal of the game is to complete a certain number of quests, and the player or team that first reaches that number wins the game.
Remember from the IEEE Standard that requirements contain:
- Functionality. What is the software supposed to do?
- External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software?
- Performance. What is the speed, availability, response time, recovery time of various software functions, etc.?
- Attributes. What are the portability, correctness, maintainability, security, etc. considerations?
- 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:
- Correct (in this case this means that they should logically fit within the realm of the game)
- Unambiguous
- 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.)
- Consistent
- Ranked for importance and/or stability
- Verifiable
- Modifiable (let’s not worry too much about this one right now)
- 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 and write down any assumptions you make. You do not need to produce a “good copy” of your work - but please write legibly. Just circle the bits you want to submit, or cross out the bits you do not.
