OBJECT-ORIENTED
ANALYSIS
University of Tampere, CS Department
Jyrki Nummenmaa
• Earlier, we saw a number of different software lifecycle
models.
• Similarly, there exists different ways to develop object
oriented (OO) software.
• We will start with a very basic OO waterfall model as given in
the textbooks. That model is ok, if there is no (relational)
database and the software is not that big.
• Later, we will study why this is typically only good for small
non-database software.
• We will also study how large-scale database-driven OO
software should be developed.
Software Engineering – http://www.cs.uta.fi/se
Object Analysis And Design
University of Tampere, CS Department
Jyrki Nummenmaa
• The goal is to start from the requirements, and to come up
with a description of the software (classes with their attributes
and methods) which can be implemented in a fairly
straightforward way.
• Usually we talk about “analysis model” and “design model”.
• Analysis model is something which, in principle, describes the
system in OO terms, but we would not want to implement it as
such, for reasons such as efficiency and maintainability.
• Design model is something we want to implement.
Software Engineering – http://www.cs.uta.fi/se
Object Analysis
University of Tampere, CS Department
Jyrki Nummenmaa
• Goal: Start from the requirement specification and come up
with
– A description of the classes (commonly a class diagram, to be
introduced later)
– A description on how the use cases are to be executed using
these classes (with some other UML diagrams such as
sequence diagrams, also to be introduced later).
• Methods:
– “Meditation” which more or less means “no methods”.
– Requirement specification text analysis. <- In these slides!
– Analysis of all possible technical documentation of an old system
or other existing systems.
– Possibly separate analysis of the domain (e.g. banking).
Software Engineering – http://www.cs.uta.fi/se
OBJECT ANALYSIS
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
Object Design - Architecture
University of Tampere, CS Department
Jyrki Nummenmaa
• This typically starts with something called “architectural
design”, which in a way describes the basic solutions and or
models, which the design is going to follow.
• Here, we identify different processes, which possibly run on
different computers.
• There is a number of “design styles”, which may be applied.
• The technology and the software development tools may
probably have a major impact on the architectural solutions.
Software Engineering – http://www.cs.uta.fi/se
Object Design
University of Tampere, CS Department
Jyrki Nummenmaa
• Once the architectural decisions have been made, the
analysis model is developed into a model describing the
classes that we are actually going to implement.
• The UML diagram types are probably mostly the same as in
analysis, but new classes, methods and attributes are
introduced for the implementation.
Software Engineering – http://www.cs.uta.fi/se
Object Analysis Goals/Phases
University of Tampere, CS Department
Jyrki Nummenmaa
1.
2.
3.
4.
5.
6.
7.
8.
Identify classes.
Create a vocabulary, which is updated continuously.
Identify associations.
Identify responsibilities.
Identify operations (methods)
Identify attributes
Create inheritance structure
Check and clean-up
Software Engineering – http://www.cs.uta.fi/se
Example Board Game
Requirement Specification / 1
University of Tampere, CS Department
Jyrki Nummenmaa
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.
Software Engineering – http://www.cs.uta.fi/se
Example Board Game
Requirement Specification / 2
University of Tampere, CS Department
Jyrki Nummenmaa
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.
Software Engineering – http://www.cs.uta.fi/se
Use Case ”Start”
University of Tampere, CS Department
Jyrki Nummenmaa
Name: Start
Version: 1.0
Summary: The game is initialised
Frequency: Once per every game played
Usability Requirements:
Actors: Players, the game application
Preconditions:.
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:
Software Engineering – http://www.cs.uta.fi/se
Sequence Diagrams for Use
Cases
University of Tampere, CS Department
Jyrki Nummenmaa
•
•
•
•
•
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.
Software Engineering – http://www.cs.uta.fi/se
Sequence Diagram for
”Start”
University of Tampere, CS Department
Jyrki Nummenmaa
Application
User
Choose start
Ask player names
Player names
Show pieces
Show initialised board
- Vertical lines stand for actors (here ”User” and ”Application”)
- Time runs down in the diagram
- Arrows show interaction/operations
Software Engineering – http://www.cs.uta.fi/se
Use Case ”Take Card”
University of Tampere, CS Department
Jyrki Nummenmaa
Name: Take Card
Version: 1.0
Summary: A player takes a card
Frequency: Probably not as often as once every round
Usability Requirements:
Actors: A player, the game application
Preconditions: 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:
Software Engineering – http://www.cs.uta.fi/se
Sequence Diagram for
”Take Card”
University of Tampere, CS Department
Jyrki Nummenmaa
Application
User
Choose to take card
Show player’s funds with one unit taken
Show Card
Show player’s funds with jewel value added
Software Engineering – http://www.cs.uta.fi/se
Use Case ”Flight”
University of Tampere, CS Department
Jyrki Nummenmaa
Name: Flight
Version: 1.0
Summary: A player flies from one place to another
Frequency: Probably not as often as once every round
Usability Requirements:
Actors: A player, the game application
Preconditions: 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:
Software Engineering – http://www.cs.uta.fi/se
Sequence Diagram for
”Flight”
University of Tampere, CS Department
Jyrki Nummenmaa
Application
User
Choose to fly
Show possible destinations
Choose destination
Show position
The flow
continues in use
case ”Take card”
Software Engineering – http://www.cs.uta.fi/se
Use Case ”Stepping”
University of Tampere, CS Department
Jyrki Nummenmaa
Name: Stepping
Version: 1.0
Summary: A uses a playing turn to move with the dice
Frequency: Most players do this on most rounds
Usability Requirements:
Actors: A player, the game application
Preconditions: 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:
Software Engineering – http://www.cs.uta.fi/se
Sequence Diagram for
”Stepping”
University of Tampere, CS Department
Jyrki Nummenmaa
Application
User
Choose to use the dice
Show result and possible destinations
Choose destination
Show position
The flow
continues in use
case ”Take card”
Software Engineering – http://www.cs.uta.fi/se
Board Game Use Case
Diagram
Board Game
University of Tampere, CS Department
Jyrki Nummenmaa
Start
Flight
<<include>>
Player
Take card
<<include>>
Stepping
Software Engineering – http://www.cs.uta.fi/se
Analysis model: Classes
University of Tampere, CS Department
Jyrki Nummenmaa
• Text analysis
• Go through the text, and pick nouns
Software Engineering – http://www.cs.uta.fi/se
Nouns from Requirement
Spec. (hope they’re right :)
University of Tampere, CS Department
Jyrki Nummenmaa
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.
Software Engineering – http://www.cs.uta.fi/se
Nouns from Requirement
Specification / 2
University of Tampere, CS Department
Jyrki Nummenmaa
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.
Software Engineering – http://www.cs.uta.fi/se
Nouns from Use Case ”Start”
University of Tampere, CS Department
Jyrki Nummenmaa
Name: Start
Version: 1.0
Summary: The game is initialised
Frequency: Once per every game played
Usability Requirements:
Actors: Players, the game application
Preconditions:.
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:
Software Engineering – http://www.cs.uta.fi/se
Nouns from Use Case ”Take
Card”
University of Tampere, CS Department
Jyrki Nummenmaa
Name: Take Card
Version: 1.0
Summary: A player takes a card
Frequency: Probably not as often as once every round
Usability Requirements:
Actors: A player, the game application
Preconditions: 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:
Software Engineering – http://www.cs.uta.fi/se
Potential classes
University of Tampere, CS Department
Jyrki Nummenmaa
game
(game) piece
(game) money
turn
special place
jewel
representation
connection
connection
(computer) application
computer
player
(game) board
path
dice
step
place
dice value
card
bandit
treasure
starting place
user interface
flight connection
(jewel) value
unit
pair (of places) amount (of money)
Software Engineering – http://www.cs.uta.fi/se
Reasons for rejecting
potential classes
University of Tampere, CS Department
Jyrki Nummenmaa
•
•
•
•
•
•
•
•
•
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
Software Engineering – http://www.cs.uta.fi/se
Alternatively: Conditions For
Accepting a Class
University of Tampere, CS Department
Jyrki Nummenmaa
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.
Software Engineering – http://www.cs.uta.fi/se
Rejected classes
University of Tampere, CS Department
Jyrki Nummenmaa
•
•
•
•
•
•
•
•
•
•
•
•
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!
Software Engineering – http://www.cs.uta.fi/se
Classes
University of Tampere, CS Department
Jyrki Nummenmaa
card
flight connection
place
treasure
connection
map
player
game
dice
piece
special place
Software Engineering – http://www.cs.uta.fi/se
An Initial Class Diagram
University of Tampere, CS Department
Jyrki Nummenmaa
Piece
Dice
Place
Treasure
Player
Game
Connection
Map
Card
Special place
Flight
connection
The classes are drawn as rectangles.
However, we do not have any associations between classes.
Nor do we have any operations or attributes.
Software Engineering – http://www.cs.uta.fi/se
A Model Vocabulary
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
A part of initial vocabulary
University of Tampere, CS Department
Jyrki Nummenmaa
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.
…
…
Software Engineering – http://www.cs.uta.fi/se
Task list
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
Task List For The Game
Application
University of Tampere, CS Department
Jyrki Nummenmaa
•
•
•
•
•
•
•
•
•
•
•
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
Software Engineering – http://www.cs.uta.fi/se
Associations
University of Tampere, CS Department
Jyrki Nummenmaa
• 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…
Software Engineering – http://www.cs.uta.fi/se
Potential Associatons / 1
University of Tampere, CS Department
Jyrki Nummenmaa
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.
Software Engineering – http://www.cs.uta.fi/se
Example Board Game
Requirement Specification / 2
University of Tampere, CS Department
Jyrki Nummenmaa
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.
Software Engineering – http://www.cs.uta.fi/se
Some potential associations
University of Tampere, CS Department
Jyrki Nummenmaa
(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
Software Engineering – http://www.cs.uta.fi/se
Reasons for rejecting
associations
University of Tampere, CS Department
Jyrki Nummenmaa
•
•
•
•
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.
Software Engineering – http://www.cs.uta.fi/se
Rejecting Associations
University of Tampere, CS Department
Jyrki Nummenmaa
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
The game is played by players
Player has a playing piece
Piece is in a place
Pieces are moved on the playing board - activity
Game has a map
Places are connected by a connection –>
map contains places and connections
Connections form paths on the board – map info
Places are either ordinary places or special places
- inheritance
Game includes a dice
Player may use a flight connection - activity
Player is at one end of the flight connection (3)
Special place has a card
Player throws the dice - activity
Player has the treasure
Software Engineering – http://www.cs.uta.fi/se
Association names
University of Tampere, CS Department
Jyrki Nummenmaa
(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
Software Engineering – http://www.cs.uta.fi/se
Association names
University of Tampere, CS Department
Jyrki Nummenmaa
(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 between
place and place: place-connected-place
(6)
map-contain-places
(7)
game-include-dice
(8)
card-cover-special place
(9)
player-own-treasure
Software Engineering – http://www.cs.uta.fi/se
Association details
University of Tampere, CS Department
Jyrki Nummenmaa
• 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)
Software Engineering – http://www.cs.uta.fi/se
Classes And Associations
University of Tampere, CS Department
Jyrki Nummenmaa
The little numbers at the ends of associations are cardinalities.
owns
uses
Piece
0..1
0..1
Player
0..1
0..1
Treasure
* {ordered}
play
1
*
located
include
Dice
1
1
Game
Special place
1
2
end
cover
0..1
1
contains
Place
*
*
1
Map
Card
*
Flight
Connection
*
connected
Software Engineering – http://www.cs.uta.fi/se
Some Observations This Far
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
Class Responsibilities
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
Example Class
Responsibilities
University of Tampere, CS Department
Jyrki Nummenmaa
Piece
Dice
Maintains player’s position on the map.
Gives a random number from
{1,2,3,4,5,6}, where each value has
equal probability.
…
…
Software Engineering – http://www.cs.uta.fi/se
Applying Classes to
Sequence Diagrams
University of Tampere, CS Department
Jyrki Nummenmaa
• 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).
Software Engineering – http://www.cs.uta.fi/se
Sequence Diagram for
”Take Card”
University of Tampere, CS Department
Jyrki Nummenmaa
User
Game
Choose to take card
Show funds
Player
Card
Pay (1)
Updated funds
Turn Card
Show card value
Place
Card Value
Get Value
Value
Add Funds (Value)
Show funds
Software Engineering – http://www.cs.uta.fi/se
Identify Operations
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.)
Software Engineering – http://www.cs.uta.fi/se
Some Operations For Class
Player
University of Tampere, CS Department
Jyrki Nummenmaa
• 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
Software Engineering – http://www.cs.uta.fi/se
Identify Attributes For
Classes
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
More Detailed
Representation For Class
University of Tampere, CS Department
Jyrki Nummenmaa
• A box with three compartments: Header, Attributes, and
Operations. We are still missing some details.
Player
name: String
money: Integer
Pay(value: Integer):Integer
AddFunds(value:Integer):Integer
getPlace():Place
hasMoney(value:Integer):Boolean
moveTo(p:Place)
hasTreasure():Boolean
takeTreasure(t:Treasure)
giveTreasure(t:Treasure)
isWinner():Boolean
Software Engineering
– http://www.cs.uta.fi/se
canFly():Boolean
Inheritance Structure
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.)
Software Engineering – http://www.cs.uta.fi/se
Example Inheritance
University of Tampere, CS Department
Jyrki Nummenmaa
• In our example, Special Place is clearly a Place.
Place
Special Place
Software Engineering – http://www.cs.uta.fi/se
User Interface Specification
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
Final Check-Ups / 1
University of Tampere, CS Department
Jyrki Nummenmaa
• 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 knockon 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?
Software Engineering – http://www.cs.uta.fi/se
Final Check-Ups / 2
University of Tampere, CS Department
Jyrki Nummenmaa
• 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!
Software Engineering – http://www.cs.uta.fi/se