Many times, two or more analysis classes are related to one another in some fashion or another. In UML this is called associations.
With Object Oriented code, we often ask if two classes are related or associated through a is-a or has-a type relationship.
For example: a car (and object) has a(n) engine (an other object). This shows that there is an association between the engine and the car. The engine helps make the car, but it isn’t a car.
On the other hand a car (an object) is a vehicle (another object). The vehicle is a more abstract object, that the car will inherit from showing a parent child type relationship, not an attribute relationship.
If an association has multiple objects related to another, it is referred to as multiplicity. Consider a college class as an object. It has a teacher object, as well as student objects. But multiple students make up the class, thus is it a multiplicity situation.
You can also consider a house. In it you will have a variety of rooms that will make it up – showing a multiplicity situation.
When building your classes, you need to know if there will be other classes that make it up, and if so, how. You also need to know how many, sometimes the exact number isn’t known, so you can leave it open ended.
When you have classes dependent upon one another, you need to specify how they will interact. Look at Fig 10.6 to see an example.
Requirements Modeling: Class-Based Methods was originally found on Access 2 Learn
