OBJECT-ORIENTED Object Analysis And Design ANALYSIS Earlier, we - - PDF document

1

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

OBJECT-ORIENTED ANALYSIS

• Earlier, we saw a number of different software lifecycle

models.

• Similarly, there exists different ways to develop object
• riented (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 University of Tampere, CS Department Jyrki Nummenmaa

Object Analysis And Design

• 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 University of Tampere, CS Department Jyrki Nummenmaa

Object Analysis

• 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

• r other existing systems.

– Possibly separate analysis of the domain (e.g. banking). Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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
• f 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 University of Tampere, CS Department Jyrki Nummenmaa

Object Design - Architecture

• 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 University of Tampere, CS Department Jyrki Nummenmaa

Object Design

• 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.

2

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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 attributes 7. Create inheritance structure 8. Check and clean-up

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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

• rdinary 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

• ne end of the flight connection when his/her turn comes.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Use Case ”Start”

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 University of Tampere, CS Department Jyrki Nummenmaa

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. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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”)
• Tim e runs dow n in the diagram
• Arrow s show interaction/ operations

3

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Use Case ”Take Card”

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 University of Tampere, CS Department Jyrki Nummenmaa

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”

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Use Case ”Flight”

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 University of Tampere, CS Department Jyrki Nummenmaa

User Application Choose to fly Show possible destinations Choose destination Show position The flow continues in use case ”Take card”

Sequence Diagram for ”Flight”

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Use Case ”Stepping”

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 University of Tampere, CS Department Jyrki Nummenmaa

User Application Choose to use the dice Show result and possible destinations Choose destination Show position The flow continues in use case ”Take card”

Sequence Diagram for ”Stepping”

4

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Start Flight Stepping Take card Board Game Player <<include>> <<include>>

Board Game Use Case Diagram

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Analysis model: Classes

• Text analysis
• Go through the text, and pick nouns

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Nouns from Requirement

• Spec. (hope they’re 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

• n 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 University of Tampere, CS Department Jyrki Nummenmaa

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. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Nouns from Use Case ”Start”

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 University of Tampere, CS Department Jyrki Nummenmaa

Nouns from Use Case ”Take Card”

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:

5

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Potential classes

game computer player (game) piece (game) board path (game) money dice step turn place dice value special place card bandit jewel treasure starting place representation user interface flight connection connection (jewel) value unit connection pair (of places) amount (of money) (computer) application

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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

• bject 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 University of Tampere, CS Department Jyrki Nummenmaa

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!

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Classes

card connection dice flight connection map piece place player special place treasure game

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa Piece Game Special place Treasure Player Dice Map Card Place Flight connection

An Initial Class Diagram

The classes are draw n as rectangles. How ever, w e do not have any associations betw een classes. Nor do w e have any operations or attributes. Connection

6

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

A part of initial vocabulary

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 University of Tampere, CS Department Jyrki Nummenmaa

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
• utput from the application.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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… Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.

7

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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 Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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 between place and place: place-connected-place (6) map-contain-places (7) game-include-dice (8) card-cover-special place (9) player-own-treasure

8

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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
• f the association)

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

uses

• wns

located include contains play {ordered} cover end 0..1 0..1 0..1 2 * * * * * * connected

Piece Game Special place Treasure Player Dice Map Card Place Flight Connection

1 1 1 1 1 0..1 0..1 1

Classes And Associations

The little num bers at the ends of associations are cardinalities.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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. … …

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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,
• f course, it will be from object to object).

9

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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
• perations 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 University of Tampere, CS Department Jyrki Nummenmaa

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

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

More Detailed Representation For Class

• A box with three compartments: Header, Attributes, and
• Operations. We are still missing some details.

Player

nam e: String m oney: I nteger Pay( value: I nteger) :I nteger AddFunds( value:I nteger) :I nteger getPlace( ) :Place hasMoney( value:I nteger) :Boolean m oveTo( p:Place) hasTreasure( ) :Boolean takeTreasure( t:Treasure) giveTreasure( t:Treasure) isW inner( ) :Boolean canFly( ) :Boolean Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.)

10

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Example Inheritance

• In our example, Special Place is clearly a Place.

Place Special Place

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

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-
• n 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 University of Tampere, CS Department Jyrki Nummenmaa

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!