Page 222 -

OO-METHOD 207
Figure 11.2 Associations Between “Vehicle” and “VehicleType,” and “RetiredVehicle”
and “Buyer”
Vehicles Type
«dynamic» «static»
Vehicle Vehicle Type
* 1..1
«Id» PlateNumber : String «Id» VehicleTypeId: Autonumber
CreationDate: Date Description: String
Make: String
Model: String
Fuel: String «new» CreateType()
Kilometers: Real «destroy» DeleteType()
Status: String EditDescription()
Notes: String
«new» Create()
«destroy» Delete()
Rent()
Return()

Vehicle.Retire /

Vehicles Buyer
«dynamic» «static»
Retired Vehicle Buyer
* 1..1
RetirementReason: String «Id» BuyerId: Autonumber
Name: String

«new» NewBuyer()
«destroy» Delete()

Note: Class “Vehicle” specializes into “Retired Vehicle” when event “retire” is executed.

In addition to generalization and association/aggregation relationships, OO-Method allows for
the definition of agent relationships. An agent relationship is a directed relationship between two
classes (one playing the role of agent class, the other acting as server class) that defines:

• which attributes in the signature of the server class the agent class is allowed to query,
• which roles (the equivalent to association ends in UML) in the signature of the server class
the agent class is allowed to navigate, and
• which services in the signature of the server class the agent class is allowed to execute.

As illustrated in Figure 11.3, the graphical notation for the agent relationship is a dashed arrow
from the agent class to the server class stereotyped with “agent.”
This allows the modeler to specify a conceptual schema as a client-server model, where it is
properly stated which services are provided to the system by classes, and what kind of permissions
(agent) classes have to observe other classes’ properties or activate other classes’ services.