OO120 - Object-Oriented Analysis & Design Lab Solution - 1095

Lab Solutions 1
This file contains possible solutions to the course lab exercises.
Note – Other solutions to the exercises are possible.
1-1
Copyright 1997 Sun Microsystems, Inc. All Rights Reserved. SunService October 1995
1
Lab: Context Diagrams, Use Cases, and Key Abstractions

1. A context diagram for the skating league is shown below.
League
director Judge
Skating league
application
Meet
director
2. Possible use cases based on the context diagram are shown below.
● League director
- Add new team
- Delete team
- Add skater to team
- Schedule a meet
- Get season standings
● Meet director
- Assign judge to event
- Get meet results
- Get competition results
- Enter a team in a meet
● Judge
- Enter score
1-2 Object-Oriented Analysis and Design

1
Lab: Context Diagrams, Use Cases, and Key Abstractions
3. The key abstractions for the skating league are:
- Meet
- Competition
- Event
- Judge
- Skater
- Team
Notes
● Score is not a key abstraction. To find out why, try to define it. You
will eventually come to the conclusion that score is an attribute of
a performance. This is one of the three way that you can find the
Performance class.
● League would be a key abstraction if there were more than one

league that you were tracking.
● The season would be a key abstraction if you were going to keep

data from previous seasons.
Lab Solutions 1-3

1
Lab: Static Models
1. The static model for the skating league problem is shown below.
Team Meet
Competition
Skater Judge
Event

1
Lab: Static Models
2. The associations have been named in the static model as shown

below.
Entrant
Team Meet
Host
Member
Competition
Skater Judge
Contest
Assigned
Performer Qualified
Event
Notice the difficulty that you have in defining the association

between Judge and Event. Being qualified for an Event is a pre-
cursor to being assigned to it, but does not guarantee an
assignment.
The fact that you cannot name this association without ambiguity
is an indicator that you have missed a class in the initial analysis.
In this case, a Judge is not qualified for a single event, but rather
for all events of a given type. You will have to add EventType to
the static model.
The revised static model is shown on the next page.
Lab Solutions 1-5

1
Lab: Static Models
Revised static model:
Entrant
Team Meet
Host EventType
Member
Competition Qualified
Characterizes
Skater Judge
Contest
Assigned
Performer
Event
3. The multiplicity of each association is shown below.
Entrant
Team Meet
Host EventType
Member
Competition Qualified
Characterizes
Skater Judge
Contest
Assigned
Performer
Event

1
Lab: Static Models
4. The attributes for each class in the static model are shown below.
Meet
Team
Name
Name Entrant Date
maxSize Location
Host
EventType
Member
Competition Type
Gender Qualified
ageRange
Skater Characterizes
Name Contest
Address Judge
phoneNumber Name
datOfBirth
Performer Address
Gender phoneNumber
Event Assigned
startTime
Lab Solutions 1-7

1
Lab: Advanced Static Models
1. The diagrams below shows inheritance and aggregation added to

the static model.
Participant
Meet
Name
Address
phoneNumber
Competition
Skater Judge
datOfBirth
Gender Event

1
Lab: Advanced Static Models
2. The diagram below shows the many-to-many associations broken

up.
Team Skater Judge Judge
Membership Performance Qualification RawScore
beginDate dateObtained
Score expiration Value
endDate
Skater Event Event Performance
Judge
Team
Registration Assignment
dateReceived
Status
Event
Meet
There were no meaningful attributes for the Assignment class, so it

will not be used. The many-to-many association between the
Judge and the Event classes will remain in the model.
Lab Solutions 1-9

1
Lab: Dynamic Models
A dynamic model of the turnstile is shown below.
Fail
Unlocking
Pass
/Alarm
Coin
Coin /thankYou
/Unlock Unlocked
Locked
Pass
/Lock
Locking
Fail
Broken
Notice the use of several lambda transitions. (Recall that a lambda

transition is a transition in which the trigger is a “when done”
condition in the previous state, and there are no operations or events
as a result of the transition.)

1
Lab: Managing Complexity
1. Subsystems for the skating league problem are shown below.
Skater GUI
Skater
league
Persistent
date
Notice that in a company that had some OO experience, there

would be two more subsystems. One would be the library of the
GUI items; the Skater GUI would import classes from this
subsystem. The other subsystem would by the company library,
which would probably contain multiple classes that would be
used in the application. The Skater league subsystem would
depend on this subsystem.
2. The diagram below shows the dependencies between the

subsystems.
Skater GUI
Skater
league
Persistent
date
Note – The Skater league depends on the other two subsystems. You
could also have built it so that there were peer-to-peer associations
between the subsystems, rather than the client-server model shown.
Lab Solutions 1-11

1
Lab: Functional Models
The diagram below shows event schema for a commuter passing

through the subway turnstile. The three scenarios considered are the
following:
● (A) Commuter inserts coin; turnstile successfully unlocks.
● (B) Commuter inserts coin; turnstile is unable to unlock.
● (C) Commuter passes without inserting a coin.
A:
Coin
Coin
Unlock
Pass
Pass
Lock
Coin box Turnstile Gate Lock

1
B:
Coin
Coin
Unlock
Fail
On
Return coin
Coin box Turnstile Out of Lock

service light
Lab Solutions 1-13

1
C:
Pass
Pass
Turn on
Coin box Turnstile Gate Alarm

1
Lab: Class Design
1. The interface for the Turnstile class is given below.

class Turnstile {
public:
void pass();
void coin();
void fix();
void fail();
}
2. The interface for the Skater class is given below:

class Skater {
public:
char* getName();
bool setName(char* theName);
char* getAddress();
bool setAddress(char* theAddress);
int getAge();
date getBirthDay();
bool setBirthDay(date theBirthDay);
char* getPhoneNumber();
bool setPhoneNumber(char* theNumber);
enum getGender();
bool joinTeam(team* t);
bool quitTeam();
team* teamIs();
}
Lab Solutions 1-15

1
Lab: Operation Design
The design for the getCost() operation for a part is shown below.
Part
Costing policy
getCost()
Electrical Mechanical Location Other

part part policy policy
Rollup Rollup
factor factor

1
Lab: Designing Attributes and Associations
1. The design of the attributes of the Skater class are shown below.
class Skater {
private:
Name myName;
Address myAddress;
Date myBirthDay;
PhoneNumber myPhoneNumber;
enum myGender;
}
You could have used a char* for both the name and address
attributes. Here, classes were used for these attributes in case there
were come complex manipulations involved. For example, if the
names were to be alphabetized.
The phone number was stored as a class in case there were

instances where the area code was needed.
2. The design of the associations of the Skater class are shown below.
class Skater {
private:
set <Membership>* my Memberships;
set <Performances>* my Performances;
}
This assumes that you have a set object in the library that can be
parameterized with whatever type you want. A set was chosen
because a set automatically eliminates duplications. If you had
wanted to allow duplications, you could have selected some other
structure.
It is also possible to us something like a linked list for this

application. This would be beneficial because you are probably
interested in the most recent Performance or Membership.
However, this structure is difficult if you want to rebuild the
results from a previous meet.
Lab Solutions 1-17

1
Lab: Reification
The diagram below shows a reified event as the communication

mechanism between the coin box and the turnstile.
CoinEvent Turnstile
Coin box Date

Time coin()
class CoinEvent {
public:
CoinEvent(Turnstile* theTurnStile) {
myTurnstile = theTurnStile;
myTurnstile.coinEvent();
}
private:
Turnstile* myTurnstile;
}

1
Lab: Designing Behavior
The expanded static model for the garage door opener is shown below.
Garage door
opener Garage door state
depress()
fullOpen() depress(motor* theMotor)
closed()
Open Closed Stopped
Opening Closing
class GarageDoorOpener {
public:
void depress();
void fullOpen();
void closed();
private:
OpenState* open;
ClosedState* closed;
OpeningState* opening;
ClosingState* closing:
StoppedState* stopped;
GarageDoorState* myState;
motor* myMotor;
}
Lab Solutions 1-19

1
GarageDoorOpener::depress() {
myState.depress();
if (myState == open) myState = closing;
else if (myState == opening) myState = stopped;
else if (myState == closed) myState = opening;
else if (myState == closing) myState = stopped;
else myState = opening;
}
GarageDoorOpener::fullOpen() {
myMotor.off();
myState = open;
}
GarageDoorOpener::closed() {
myMotor.off();
myState = closed;
}
class GarageDoorState{
public:
virtual void depress(motor* theMotor) = 0;
}
class OpenState is puplic GarageDoorState {

public:
depress(motor* theMotor)
{ theMotor.rev();}
}
class ClosedState is public GarageDoorState {

public:
{ theMotor.fwd();}
}
class StoppedState is public GarageDoorState {

public:
{ theMotor.rev();}
}

1
class OpeningState is public GarageDoorState {

public:
{ theMotor.stop();}
}
class ClosingState is public GarageDoorState {

public:
{ theMotor.stop(); }
}
Lab Solutions 1-21

1


OO120 - Object-Oriented Analysis & Design Lab Solution - 1095

Uploaded by

Copyright:

Available Formats

You might also like

OO120 - Object-Oriented Analysis & Design Lab Solution - 1095

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OO120 - Object-Oriented Analysis & Design Lab Solution - 1095

Uploaded by

Copyright:

Available Formats

Lab Solutions 1

This file contains possible solutions to the course lab exercises.

Note – Other solutions to the exercises are possible.

Lab: Context Diagrams, Use Cases, and Key Abstractions

- Add new team

- Add skater to team

- Get season standings

- Assign judge to event

- Get meet results

- Get competition results

- Enter a team in a meet

1-2 Object-Oriented Analysis and Design

Lab: Context Diagrams, Use Cases, and Key Abstractions

3. The key abstractions for the skating league are:

● League would be a key abstraction if there were more than one

● The season would be a key abstraction if you were going to keep

Lab Solutions 1-3

Lab: Static Models

1-4 Object-Oriented Analysis and Design

Lab: Static Models

2. The associations have been named in the static model as shown

Notice the difficulty that you have in defining the association

The revised static model is shown on the next page.

Lab Solutions 1-5

Lab: Static Models

Revised static model:

3. The multiplicity of each association is shown below.

1-6 Object-Oriented Analysis and Design

Lab: Static Models

Lab Solutions 1-7

Lab: Advanced Static Models

1. The diagrams below shows inheritance and aggregation added to

1-8 Object-Oriented Analysis and Design

Lab: Advanced Static Models

2. The diagram below shows the many-to-many associations broken

Team Skater Judge Judge

Membership Performance Qualification RawScore

Skater Event Event Performance

There were no meaningful attributes for the Assignment class, so it

Lab Solutions 1-9

Lab: Dynamic Models

A dynamic model of the turnstile is shown below.

Notice the use of several lambda transitions. (Recall that a lambda

1-10 Object-Oriented Analysis and Design

Lab: Managing Complexity

1. Subsystems for the skating league problem are shown below.

Notice that in a company that had some OO experience, there

2. The diagram below shows the dependencies between the

Lab Solutions 1-11

Lab: Functional Models

The diagram below shows event schema for a commuter passing

● (A) Commuter inserts coin; turnstile successfully unlocks.

● (B) Commuter inserts coin; turnstile is unable to unlock.

● (C) Commuter passes without inserting a coin.

Coin box Turnstile Gate Lock

1-12 Object-Oriented Analysis and Design

Lab: Functional Models

Coin box Turnstile Out of Lock