15.1.2003software engineering 2003 jyrki nummenmaa 1 object analysis although there is some...
TRANSCRIPT
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
1
OBJECT ANALYSIS
• Although there is some variance, most methods are based on what is called OMT (Object Modeling Technique).
• I present a simplified technique, which follows the main ideas of most of these methods.
• I will present the technique using an example, which I have modified from ”Oliokirja” by Kai Koskimies.
• The example is a simplified version of the famous Finnish board game ”Afrikan tähti” (African Star).
• I will explain the various types of diagrams as they are needed.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
2
Object Analysis Goals/Phases
1. Identify classes.2. Create a vocabulary, which is updated
continuously.3. Identify associations.4. Identify responsibilities.5. Identify operations (methods)6. Identify attributes7. Create inheritance structure8. Check and clean-up
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
3
Example Board Game Requirement Specification / 1
The game shall be implemented as a computer application with a graphical user interface. The game is played by two or more players. Each player has a playing piece, which all look different. The pieces are moved on the playing board. When the game starts, all pieces are in starting place and each player recieves a sum of game money. The game has a set of places, on which the pieces can be positioned. The places are either ordinary places or special places. Some pairs of these places are connected by a connection. Graphically, the connections form paths on the board. There are flight connections for some pairs of places.
The players take turns to play. The game includes a dice, which shows how many steps each playing piece is to be moved in each turn. With each step, the players’ piece is moved from one place to another place using a connection on condition that these places are connected. A player may use a flight connection by paying one unit game money, assuming he is at one end of the flight connection when his/her turn comes.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
4
Example Board Game Requirement Specification / 2
At the start of the game, each special place has a card face down. When a player arrives to a special place, he/she may pay one unit game money to take the card (which can only be taken once). Alternatively, the player may stay on a special place, and instead of moving, throw the dice for trying to take the card: dice values 4,5, and 6 mean the player gets the card.
The card may be a bandit, meaning the player loses all money, a jewel with a value, meaning that the player receives money for that value, or a treasure. The treasure may not be sold, but if another player arrives to a place which has a player with the treasure, the arriving player gets the treasure. When a player with the treasure arrives to the starting place, that player wins the game and the game ends. The game boards, places, pieces, labels, connections, etc. each have a graphical representation in the user interface, but that representation is not specified here.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
5
Use Case ”Start”
Name: StartVersion: 1.0Summary: The game is initialisedFrequency: Once per every game playedUsability Requirements:Actors: Players, the game applicationPreconditions:.Descriptions: The game application shows a dialogue, where all player’s names are typed in. The game application randomly chooses the game pieces for the players and the order in which players take turns. The game starting position is initialised by putting the pieces in the start place and randomly choosing the cards for the special places. Postconditions:Exceptions:
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
6
Sequence Diagrams for Use Cases
• Sequence Diagrams show interaction between actors.• The use cases may be drawn into sequence diagrams, which
show the interaction between users and the system.• The sequence diagrams are fairly self-evident at this point:
we have two actors (the official term is ”classifier role” for sequence diagrams) and the arrows show the communication.
• The arrows represent (asynchronous) message passing or (synchronous) method calls.
• Based on the sequence diagrams, it is possible to identify a set of tasks, which the system is to perform.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
7
User
Application
Choose start
Ask player names
Player names
Show pieces
Show initialised board
Sequence Diagram for ”Start”
- Vertical lines stand for actors (here ”User” and ”Application”)- Time runs down in the diagram- Arrows show interaction/operations
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
8
Use Case ”Take Card”
Name: Take CardVersion: 1.0Summary: A player takes a cardFrequency: Probably not as often as once every roundUsability Requirements:Actors: A player, the game applicationPreconditions: It is the player’s turn, the player has money, and the player is in a special place with a card that has not been taken.Descriptions: The player chooses to take the card. One unit money is taken from the player. The card is a jewel, and the player’s funds are increased with the respective amount of money. Postconditions:Exceptions:
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
9
User
Application
Choose to take card
Show player’s funds with one unit taken
Show Card
Show player’s funds with jewel value added
Sequence Diagram for ”Take Card”
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
10
Use Case ”Flight”
Name: FlightVersion: 1.0Summary: A player flies from one place to anotherFrequency: Probably not as often as once every roundUsability Requirements:Actors: A player, the game applicationPreconditions: It is the player’s turn, the player has money to fly, and the player is in a place, where there are flight connections.Descriptions: The player chooses to fly. The player is shown the possible destinations, of which the player chooses one. The game application moves player’s piece to the chosen destination, and his funds are decremented by one unit. Postconditions:Exceptions:
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
11
User
Application
Choose to fly
Show possible destinations
Choose destination
Show position
The flow continues in usecase ”Take card”
Sequence Diagram for ”Flight”
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
12
Use Case ”Stepping”
Name: SteppingVersion: 1.0Summary: A uses a playing turn to move with the diceFrequency: Most players do this on most roundsUsability Requirements:Actors: A player, the game applicationPreconditions: It is the player’s turn.Description: The player uses the dice. The game application shows
the result and the possible places to move to. The player chooses one, which is a special place with a card that has not been taken. The game application moves player’s piece to the new place. ”Take Card” use case follows.
Postconditions: Exceptions:
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
13
User
Application
Choose to use the dice
Show result and possible destinations
Choose destination
Show position
The flow continues in usecase ”Take card”
Sequence Diagram for ”Stepping”
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
14
StartStart
FlightFlight
SteppingStepping
Take cardTake card
Board Game
Player
<<include>>
<<include>>
Board Game Use Case Diagram
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
15
Analysis model: Classes
• Text analysis• Go through the text, and pick nouns
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
16
Nouns from Requirement Spec. (let’s hope I got them right :)
The game shall be implemented as a computer application with a graphical user interface. The game is played by two or more players. Each player has a playing piece, which all look different. The pieces are moved on the playing board. When the game starts, all pieces are in starting place and each player recieves a sum of game money. The game has a set of places, on which the pieces can be positioned. The places are either ordinary places or special places. Some pairs of these places are connected by a connection. Graphically, the connections form paths on the board. There are flight connections for some pairs of places.
The players take turns to play. The game includes a dice, which shows how many steps each playing piece is to be moved in each turn. With each step, the players’ piece is moved from one place to another place using a connection on condition that these places are connected. A player may use a flight connection by paying one unit game money, assuming he is at one end of the flight connection when his/her turn comes.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
17
Nouns from Requirement Specification / 2
At the start of the game, each special place has a card face down. When a player arrives to a special place, he/she may pay one unit game money to take the card (which can only be taken once). Alternatively, the player may stay on a special place, and instead of moving, throw the dice for trying to take the card: dice values 4,5, and 6 mean that the player gets the card.
The card may be a bandit, meaning the player loses all money, a jewel with a value, meaning that the player receives money for that value, or a treasure. The treasure may not be sold, but if another player arrives to a place which has a player with the treasure, the arriving player gets the treasure. When a player with the treasure arrives to the starting place, that player wins the game and the game ends. The game boards, places, pieces, labels, connections, etc. each have a graphical representation in the user interface, but that representation is not specified here.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
18
Nouns from Use Case ”Start”
Name: StartVersion: 1.0Summary: The game is initialisedFrequency: Once per every game playedUsability Requirements:Actors: Players, the game applicationPreconditions:.Descriptions: The game application shows a dialogue, where all player’s names are typed in. The game application randomly chooses the game pieces for the players and the order in which players take turns. The game starting position is initialised by putting the pieces in the start place and randomly choosing the cards for the special places. Postconditions:Exceptions:
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
19
Nouns from Use Case ”Take Card”
Name: Take CardVersion: 1.0Summary: A player takes a cardFrequency: Probably not as often as once every roundUsability Requirements:Actors: A player, the game applicationPreconditions: It is the player’s turn, the player has money, and the player is in a special place with a card that has not been taken.Descriptions: The player chooses to take the card. One unit money is taken from the player. The card is a jewel, and the player’s funds are increased with the respective amount of money. Postconditions:Exceptions:
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
20
Potential classes
game computer player(game) piece (game) board path(game) money dice stepturn place dice valuespecial place card banditjewel treasure starting placerepresentation user interface flight connectionconnection (jewel) value unitconnection pair (of places) amount (of
money) (computer) application
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
21
Reasons for rejecting potential classes
• irrelevant• in essence same as some other class• a likely attribute or a value• a likely method• a control-related concept• a role of another class• an association between classes• vague• implementation-specific
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
22
Alternatively: Conditions For Accepting a Class
These are typicallychecked by examining an object of that class.1. Retained information – the system needs some information
about object to function.2. Needed services – the object has operations, which change its
attribute values.3. Multiple attributes (a single-attribute class seems like a
”minor” thing at this stage).4. Common attributes (a set of attributes, which apply to all
objects of the class.5. Common operations (like with attributes above)6. Essential requirements – external entities, which consume or
produce information will almost always be modeled as objects in the analysis model.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
23
Rejected classes
• computer, computer application (irrelevant)• board (represents the same thing as path) ->
in fact, we choose to use ”map” for both of them• amount, amount of money (a likely attribute)• game money, dice value (a likely value for an attribute: a
class is probably not needed)• step (a likely operation)• turn (control-related)• starting place (a role for place)• representation (irrelevant)• jewel value (a likely attribute)• pair of places (represents the same thing as connection)• unit (irrelevant)• bandit, jewel (value) – treasure is a bit of a question mark!
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
24
Classes
card connection diceflight connection map piece place player special placetreasure game
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
25
PiecePiece
GameGameSpecial placeSpecial place
TreasureTreasurePlayerPlayer
DiceDice
MapMap CardCardPlacePlaceFlight
connectionFlight
connection
An Initial Class Diagram
The classes are drawn as rectangles.However, we do not have any associations between classes.Nor do we have any operations or attributes.
ConnectionConnection
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
26
A Model Vocabulary
• The names are not generally that descriptive.• It is a good idea to make a model vocabulary for all
words that appear in the model as names.• It will be natural to start from the class names
once they have been identified.• The vocabulary should be updated, when new
names are identified.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
27
Initial Vocabulary (actually just a part of it, but you get the idea)
Bandit A possible symbol to appear on a card. If a player takes a card, and the card is found to have a bandit, the player loses all of his/her funds.
Dice Randomly returns one of values 1, 2, 3, 4, 5 or 6. The return value is used to showing how many steps a player may advance or, alternatively, if a player gets to take card for free, in which case at least 4 is required.
Game piece Each player has a game piece, which is used to show the position of the player. Every game piece looks different.
…
…
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
28
Task list
• Once the use case sequence diagrams have been produced, they are analysed for forming a task list.
• Each arrow from the user to the application represents a service requested from the application.
• Each arrow from the appliction to the user represents an output from the application.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
29
Task List For The Game Application
• Initialise game• Showing board, piece positions, funds, and game status• Showing dice result• Showing a set of destination places• Choose to use the dice• Choosing to fly• Choosing to start a game• Choosing to open a card• Choosing a destination from a set of places • Ask player names• Input player names
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
30
Associations
• Associations are relationships, references, and dependencies between classes.
• In practice, they can be found in sentences, which represent relationships between classes.
• Examples of types of associations:– location – control – communication– inclusion– and so on…
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
31
Potential Associatons / 1
The game shall be implemented as a computer application with a graphical user interface. The game is played by two or more players. Each player has a playing piece, which all look different. The pieces are moved on the playing board. When the game starts, all pieces are in starting place and each player recieves a sum of game money. The game has a set of places, on which the pieces can be positioned. The places are either ordinary places or special places. Some pairs of these places are connected by a connection. Graphically, the connections form paths on the board. There are flight connections for some pairs of places.
The players take turns to play. The game includes a dice, which shows how many steps each playing piece is to be moved in each turn. With each step, the players’ piece is moved from one place to another place using a connection on condition that these places are connected. A player may use a flight connection by paying one unit game money, assuming he is at one end of the flight connection when his/her turn comes.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
32
Example Board Game Requirement Specification / 2
At the start of the game, each special place has a card face down. When a player arrives to a special place, he/she may pay one unit game money to take the card (which can only be taken once). Alternatively, the player may stay on a special place, and instead of moving, throw the dice for trying to take the card: dice values 4,5, and 6 mean the player gets the card.
The card may be a bandit, meaning the player loses all money, a jewel with a value, meaning that the player receives money for that value, or a treasure. The treasure may not be sold, but if another player arrives to a place which has a player with the treasure, the arriving player gets the treasure. When a player with the treasure arrives to the starting place, that player wins the game and the game ends. The game boards, places, pieces, labels, connections, etc. each have a graphical representation in the user interface, but that representation is not specified here.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
33
Some potential associations
(1) The game is played by players(2) Player has a playing piece(3) Pieces are in starting place -> Piece is in a place(4) Pieces are moved on the playing board(5) Game has (a set of places) -> map(6) Places are connected by a connection(7) Connections form paths on the board(8) Places are either ordinary places or special places(9) Game includes a dice(10) Player may use a flight connection (11) Player is at one end of the flight connection (12) Special place has a card (13) Player throws the dice(14) Player has the treasure
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
34
Reasons for rejecting associations
• An association may be trivial.• An association may be irrelevant.• An association may be follow from other
associations.• An association may turn out to be a momentary
action. In this case we may find an operation.• An assocation may relate several classes, and it
should be split into binary associations.• We may have an inheritance instead of
association.• Common sense should be used.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
35
Rejecting Associations
(1) The game is played by players(2) Player has a playing piece(3) Piece is in a place(4) Pieces are moved on the playing board - activity(5) Game has a map(6) Places are connected by a connection –>
map contains places and connections(7) Connections form paths on the board – map info(8) Places are either ordinary places or special places
- inheritance(9) Game includes a dice(10) Player may use a flight connection - activity (11) Player is at one end of the flight connection (3)(12) Special place has a card (13) Player throws the dice - activity(14) Player has the treasure
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
36
Association names
(1) The game is played by players -> play(2) Player has a playing piece -> uses (3) Piece is in a place -> located(4) Game has a map -> has(5) Places are connected by a connection
connect(6) Map contains places and connections
-> contains(7) Game includes a dice -> includes(8) Special place has a card -> Card covers
special place(9) Player has the treasure -> owns
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
37
Association names
(1) player–play–game(2) player-use-piece -> uses (3) piece-located-place -> are(4) game-has-map -> has(5) connection-connect-places -> we decide to
to make connection an association betweenplace and place: place-connected-place
(6) map-contain-places (7) game-include-dice(8) card-cover-special place(9) player-own-treasure
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
38
Association details
• Find good and short names for associations.• Add extra specifications, such as
- Navigation direction,- Aggregation information,- Ordering information,- Multiplicity specifications, and- Qualifiers (used to identify objects of target end of the association)
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
39
uses owns
located
include
contains
play
{ordered}
cover end
0..1 0..1
0..1
2
*
*
*
**
*
connected
PiecePiece
GameGame Special placeSpecial place
TreasureTreasurePlayerPlayer
DiceDice
MapMap CardCardPlacePlaceFlight
ConnectionFlight
Connection
1
1
11
1
0..10..1
1
Classes And Associations
The little numbers at the ends of associations are cardinalities.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
40
Some Observations This Far
• This is not a deterministic process: two analysts may well – and probably will – come up with two different analysis models.
• We use common sense in many places.• There are no strict rules, only guidelines. The
better you know what you are doing, the less you are bound by the guidelines.
• At any time, we may find that it is better to change something in the model. Just be aware of the consequences.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
41
Class Responsibilities
• Now it may be a good time to have a thought about why the classes are there.
• In other words, what is the role of each class in the analysis model of the system.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
42
Example Class Responsibilities
Piece Maintains player’s position on the map.
Dice Gives a random number from {1,2,3,4,5,6}, where each value
has equal probability.
……
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
43
Applying Classes to Sequence Diagrams
• Now it will be a good time to edit our sequence diagrams.
• The sequence diagrams are to use the classes in the class diagram.
• We specify the flow of operations from class to class (actually, of course, it will be from object to object).
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
44
User Player
Choose to take card
Show funds
Card Value
Sequence Diagram for ”Take Card”
Game
Pay (1)
Updated funds
Place Card
Turn Card
Value
Get Value
Show card value
Add Funds (Value)
Show funds
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
45
Identify Operations
• Operations now come primarily from three sources:- The sequence diagram (since we have no asynchronous message passing here, each arrow represents a call).- The requirement specification: the potential operations are likely to be verbs.- The task lists collected earlier on (This one is actually just a double check – all of these should be in the sequence diagrams.)
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
46
Some Operations For Class Player
• From the previous sequence diagram we get : Pay(value: Integer):Integer and AddFunds(value:Integer):Integer.
• From the requirement specifications we get:getPlace():Place, hasMoney(value:Integer):Boolean,moveTo(p:Place), hasTreasure():Boolean, takeTreasure(t:Treasure), giveTreasure(t:Treasure),isWinner():Boolean,canFly():Boolean
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
47
Identify Attributes For Classes
• Attributes now come from various sources.• We may find from the requirement specification,
that some attribute is vitally important for some class, like the amount of money for a player.
• Also the sequence diagrams may imply a need for an attribute, like the name of a player.
• At this point we want to record the attributes that are clearly important for the model.
• We may want to avoid such implementation-specific attributes, which may well change, once we make a more detailed model.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
48
More Detailed Representation For Class In A Class Diagram
• A box with three compartments: Header, Attributes, and Operations. We are still missing some details.
Player
name: Stringmoney: Integer
Pay(value: Integer):Integer AddFunds(value:Integer):Integer getPlace():Place hasMoney(value:Integer):BooleanmoveTo(p:Place)hasTreasure():Boolean takeTreasure(t:Treasure)giveTreasure(t:Treasure)isWinner():BooleancanFly():Boolean
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
49
Inheritance Structure
• Is some class a special case of another class?• Do we have some kind of a division into different
subtypes?• A compound noun (consisting of more than one
words) may indicate inheritance.• Do we have classes, which seem to share
properties?• Would it be useful to use some generally known
wider concept? (Like bandit -> criminal – in this case the answer is no, we do not need this generalisation.)
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
50
Example Inheritance
• In our example, Special Place is clearly a Place.
Place
Special Place
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
51
User Interface Specification
• Now would be a good time to make a first version of the user interface specification, unless it already exists.
• Nowadays the user interface is typically graphical.• In fact, many books just talk about GUI (Graphical
User Interface) in the understanding that by default the user interfaces are graphical.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
52
Final Check-Ups / 1
• Is everything necessary?• Do we need more classes?
If, for instance, the classes and attributes in a class do not all seem to belong together, it might be good to split the class.
• Is everything consistent? Have we taken care of all the knock-on effects that our changes have created.- As an example, if we have split a class into two, have we updated the sequence diagrams accordingly? And if so, do these changes imply more changes, and have these changes been done accordingly?
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
53
Final Check-Ups / 2
• Does the model seem sufficient? (Does it include all relevant concepts and associations?)
• Does the model seem understandable?• Is the model easy to read? Are the names chosen
correctly?• Have we avoided redundancy? (One thing only
done once.)• Does the model really describe the target system?• If all of the above is fine, then we have created the
analysis OO model of our system!